From nobody Fri Dec 3 15:58:47 2021 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 6F06218BB6D9; Fri, 3 Dec 2021 15:58:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 4J5HYl1S23z3hw2; Fri, 3 Dec 2021 15:58:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id p65so4311079iof.3; Fri, 03 Dec 2021 07:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JtnYamK5EINneJgn39csNR5ivJjfVMEFy2DyjPAeaQo=; b=ZiJN/RsUwdBWNB8RgfYadbHAT/BUWritGh+nV8bDIoxnz101rjQ/LRf8M0WTZxy0Yh tVhrbqUoP4g3Y58IdRw2EPEzzCdlJkr7REMLm46v96Hvd8lvn61bA7+h8CIwAjR9ipSZ XfKMPhAJUYVDt3mJZFZbp51Zt09ByISwWifob2BJPtCmS49tvQPo40P9dEq9pf6DaYyS GVURKAAuUTQYjLrN1sMALqlulnS0rkos6zy7dhghZhdOp7SPmhRXMKoiceGmLzN/ubeK N5yZbaje5MC7LjElqV2iuILdV85vzTMUkELJN6srsl+fMcWQjxjujUSgm77jmHU7TgfR GgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=JtnYamK5EINneJgn39csNR5ivJjfVMEFy2DyjPAeaQo=; b=ImSIF+EZs4NgvjYdzVL2aE5i9aMjdFhD1ygThYyk4qXdVMlEWVHjG4OGP+Zt858Akh zhS0BVtNBztQWq92WhlAJi5QkYkScdfvrYxUT9JzvV9Sox4NznHh3CYZb3eSol6hB59d cSpTkFH1gubM0ppiEzbBp8OVxLAD3Rl5KVAbgBbHL8Oj7PX1umMysGIgR0a6OvxVnkhB 5r4EW5rk6p4zHXZtVRjE5jPx2ypzTXyPb/egrUdUCaok31dsyQaMPTWHbMv79eELd0pz a4gnzRqgwtK40PmSbHp3bK495YKXsvWnzywNsnsharCshIPJmHJUH6IWYh1mF1vKYMMZ FTag== X-Gm-Message-State: AOAM532wEu6tLO2nN1f4gH9sjk7ohaJ6o97xeBAspHCS6meSKintxre2 UWxmpQGWG6rg+ErylyxKmhN1+HTb4e13YQ== X-Google-Smtp-Source: ABdhPJzyFLGjLe1FxGaW5uvRrf4v7qO6U7vYUnjF7dCuWUhp8VyHfnwK9btiLFktxLkaE3DSmzCEoA== X-Received: by 2002:a05:6602:26d3:: with SMTP id g19mr19125009ioo.100.1638547130342; Fri, 03 Dec 2021 07:58:50 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id r18sm1753041ilh.59.2021.12.03.07.58.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 07:58:49 -0800 (PST) Date: Fri, 3 Dec 2021 10:58:47 -0500 From: Mark Johnston To: marklmi@yahoo.com Cc: Free BSD , freebsd-current Subject: Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Message-ID: References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> <47D56092-308F-42DD-94A7-5CA9F3ED6997@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: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> X-Rspamd-Queue-Id: 4J5HYl1S23z3hw2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ZiJN/RsU"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.57)[0.572]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2f:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 664 Lines: 14 On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm wrote: > For: > > uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 > > building a variant of itself (producing a debug build instead of a > non-debug), it generated a bunch of messages of the form: > > ctfconvert: failed to get mapping for tid ????? > > in the buildkernel part of the build. Can you share the kernel configuration GENERIC-NODBG-CA72? From nobody Fri Dec 3 17:19:00 2021 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 2612818C4CB6 for ; Fri, 3 Dec 2021 17:19:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5KLX61vMz4kl6 for ; Fri, 3 Dec 2021 17:19:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638551949; bh=XY9CV9tXosZPKcG9dPY8pz80mYluSLT2amSBP26KTnE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p5fpkfyCiL3KU4Mjh/cIEOIXwdTnBiglEcZKQKrJbY9Mz3iTm4wN+uZQTk5AMiYqqDvYCDxtvoqP9LlWyOo94/DzDhOgBZF4hr6HWg4PgmzWbiOzlu1tfZt1Bnkk1e66A0kamRBEzxslikqX0K2Pg+n0dBvmexQNR4RUa6EQamRIztFaCD5Klhy4gfvivSaLgRfZoZ3znR90Rgjf92peCmWMEeMQvhxnOOaNoZ1m8MCRjxwp7uIxTtoitmB8CKaT7PL9aXX4oblQKfDvuLBwiC3XkOrrzuz+mh/7cxepkN8U76ocCwrVwwvI2ZiDVPe4TDOt+B3/LgGJY3tmpppbjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638551949; bh=8csRG4VMsrJ0Zc5c4iPjTPATRB82180NKiMZ63mEti4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=L31NV7NjVRk9+tzxCbeqGmvCErvKemb8QIZQ56Nb0m/yRGWnoYVLHPs6YLMnqBEzsmXx0lZ9aRGRwbGyelb/MNGu4mSF90rkO5kCeJy36V7PSAYJk7PFzxfxVTOe9faSdar1eJhgpNysm6B2gbr7tZ/qSlOPKVhG0e2J1pjishk6sse9v1YMFtn0oy54ATifhUzT2w7Pups6ec70+c20j5EGDrlDKNPpvuTEQhvDNNf8oAvMbo2M3uXzVpKq3gOiqh101APcLis0E6PriJ3/4Tzd20uW1dJblBe0c4ve7DQHx4Q33ns93WmLrTj+1aYjlzgVZACOKHGilwkmDyAF0g== X-YMail-OSG: Eyg0lwEVM1mzdoKYSXwJyn9zZszsBKtRqJcmW8BGYPl1CX71Bj28wpDEfYfkamv dV.bkI5CX76L5yr06sNWxqPnBu3WEGKchB.uRnCP.6Yg_HCzcqrSF.4Z.su23QR7zapz_atq9.Th I3U7Dhvlr7O8RoKh8rR6owmyksye4Vr08mX3SZUUmlIFSaNh7FVrc1T0.vRJaQ8_CDX_Fes6dg4S prGBFd.Ywvw3jLOQHyAoEfXOnsln01JlmqELFUKfFQGYbzcmvnfL3YTb2Tmdjbm_SnqtEY5y8ATC v5khNfpxo5rObD79jW7u_c8coJC8yCJJdmIhv24Lj0Z6Q5csh.3nK2FKAwfsykLF6EHx1m7JKqSY wkO1faSd5WEsDnLB5syja6gcKatXZmtuFGhUuPRIsrOoTJirNWhiY6ARblvOaIjH2dnMW5C0qa_o Z6DXl1I0Ax7RPkAmXkNgJZL05xIStlZZuSpMND4AIbfZij9d_jm30J5uR4w.2jd91P1EshGD7rTN uLOyIKBS41QxFJ4xkWnbb1KNS86RR3GEOPVmkQXWuMCzGfBmSn9UcBNp.M.xGEnRyRtdebXBlDrk g5hGZvrkNkykOFnr1QnZcCpKUoginxfgj.liYZGy7eRDPSRrzy2W7itCkYw7WXg1myLXCAgXDQDI TtgxKAjohoxBPirLpWX_qMrQGHY6SIwGyI5pNlZFRbGHSrS6jdEAiR1pbSpt_Um0oWrtiomwxkpa Z1rV4aE1tXQDHMYJOQrnxXYg2w54lWOGbH25dh7rkYo01ncyN6rXpPHIqsNTwQG3lZQ137UB8dbQ SbHI1e9_Fs6q0yH.2UCzWO_OPydmTWjF8wZGuazaA14xm.rLJlkXof1HQNMZTl1dbhFumBCUHlCa YcqNT2YBfqXlahnwvFAYzrsvM9DYwEl9ebHLuUJqB.bckxlijr_vkTrCExaSkt_bGKhG2yRW7jAk d_qTuiY6heVtv_rMRAMkUPEcPS6FHlVkZUOXveRhn3SHL5YwvxUv3cxIGC0vzUijK4NlVMtGW_pq ZNewMk_aD49jEWMIFORWzzT31rSPgL56JE3cRgKGPCUz8gEf2I_C4dsNZ4f87M3xN5CwO.x02EjL A7I9Fm0fG7alJCq47QOmItbBOS3udS1wBpiCI1mx_E1f6ZfFg7xa6c9MBaygUcIb2sQamtVIFSKI GVQY9MrygCSFg2ZtQY9hz8Pn759dxpq9yPyQAH1WXezv59rwS7MUsVAGw.HMlelFymSyVheCF1YT 3VwqavL1ZPuHZk9vyMovQvc4cZfVaZBgDfYhMTS3f5bM7i81I9h7Ccyt1SPUltQwYtwaaEBo3HQk HCHo11Dle_BzTq52.55zAg8SKx5jMWWsuBwomkXrW_crzOgQ3C2wvdf2bnH49INaR0N.qZ98eO89 5Lr1K.qLtsB9xLeD4MbgHwn6Lu230wX06BDSsP0EjxnJmNmanGBFuX.fBISyWS2299dyDfW3eNeL vBHhRrdWBI.kCfKLGIp3ZuICsGCta3b3V0QyTYP44LKPKqrF.xs9U4hjiot35PLmGebXMUXK67Lr bDbqsJfVxWOP.qSU9kF3YmwjwQx8jI0hMS.LO_ksPvXZWCyw2Z0YE7vntn9_SVqExD9dR1ZVAlL0 T_QRP9RpDAqM7QkI5zYGUYEyvbhCBYfzn8G.zYODlv28MegLZxMxJBT_FfPOW.MDSzJB1oRM8u_i 9v_Is6kRFe3uAHAPLx0f2dpgplIqJnzyhCxl4tYKR9YLTA5MdXr4sAsydFEzeyhkHFWw6Lbsbu_v J3OcR0.VCL2OVbsVooHNhzXlK15nkjkTSTKuMz2SsuQFEmYRNXgxY5LMg7zNTUSTi9eUo7T_gdR2 SorNhZBsnl7y27f5hYI7sQF87Lr1cKSV4vzWFllYh37sBqBh.WKI.HUKB1w1h8MpXYc63EzqX.6k aANSq2bJi9RtEy7HIc9RuhwxSDwDtUOmwO8j400tzfpZAAuTmDf5ddjL1ZIp7VGwkKtZ39Ecqrxv 8O6BRgSHP3ss9Oi6RIkEvSlw4oSFL0nY3cj32BPUlD9FZmUPHZWebAKDYeaXNW1XHPTjC2tj3l4A k29Z1uhBeDuvfCUj2bH3Uz5JLHF5IE2HKxwIy_tpJMz1EbiPz2LkLuRRSWjzugiPMs6I7C0hfaDl PjuneuxW0GyxjDtZYgOyHF.84utbO.pbUewGpBNCIoi_a1AO5OrEaPHexE.Y5DWaaRyC9caaliuq IMhkiLlb7m7o0U9JQcRO523vJq.4GM104jQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Dec 2021 17:19:09 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4fc935d7ace6d512ba6713a0b6bc5976; Fri, 03 Dec 2021 17:19:02 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? In-Reply-To: Date: Fri, 3 Dec 2021 09:19:00 -0800 Cc: Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <4F851A07-46F6-40E3-B1F2-D18BD873E4E3@yahoo.com> References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J5KLX61vMz4kl6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4220 Lines: 142 On 2021-Dec-3, at 07:58, Mark Johnston wrote: > On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm = wrote: >> For: >>=20 >> uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>=20 >> building a variant of itself (producing a debug build instead of a >> non-debug), it generated a bunch of messages of the form: >>=20 >> ctfconvert: failed to get mapping for tid ????? >>=20 >> in the buildkernel part of the build. >=20 > Can you share the kernel configuration GENERIC-NODBG-CA72? >=20 Sure. The environment doing the building was built using: # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72 include "GENERIC-NODBG" ident GENERIC-NODBG-CA72 makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" and . . . # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING As for the variant being built: # more /usr/main-src/sys/arm64/conf/GENERIC-DBG-CA72 include "GENERIC-DBG" ident GENERIC-DBG-CA72 makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" # more /usr/main-src/sys/arm64/conf/GENERIC-DBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-DBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP|KTR_PROC ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Enable any extra checking for. . . options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC options MALLOC_DEBUG_MAXZONES=3D8 # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Dec 3 18:38:32 2021 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 9EB0B18C2414 for ; Fri, 3 Dec 2021 18:38:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4J5M6G3tsxz3Q08 for ; Fri, 3 Dec 2021 18:38:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 03808260511; Fri, 3 Dec 2021 19:38:38 +0100 (CET) Message-ID: <7b83599e-5b38-b669-fcac-93ad328c22f4@selasky.org> Date: Fri, 3 Dec 2021 19:38:32 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14-CURRENT Kernel Panic due to USB hub? Content-Language: en-US From: Hans Petter Selasky To: Andrew Turner Cc: freebsd-arm@freebsd.org References: <2b555ef9-12fe-6214-79a0-cebce1933771@selasky.org> <5bfb1865-8033-0da6-27e4-3c25fb067cee@morante.net> <6F2AD5E1-5AB1-4D08-97F4-84E2905D592B@fubar.geek.nz> <45534c79-311b-d1df-c412-5bd782678cfb@selasky.org> <78ed0a6e-2ef0-46a4-f494-8eeef326d15e@selasky.org> <3E44BF3B-9181-480E-8D40-09B66203ADB6@fubar.geek.nz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J5M6G3tsxz3Q08 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-0.37 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-0.18)[-0.176]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.10)[0.101]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 873 Lines: 34 On 12/1/21 17:32, Hans Petter Selasky wrote: > On 12/1/21 12:39, Andrew Turner wrote: >> I have. I’m hitting the KASSERT at [1]. Looking at the memory around >> td->td_pcb->pcb_fpflags makes me think the memory has been trashed as >> there are bits set that could never be so in the flags fields, and >> kernel pointer values that point to user memory. >> >> Andrew >> >> [1]https://cgit.freebsd.org/src/tree/sys/arm64/arm64/trap.c?id=6e9309bd3b04501b69593900a14e01114c7f2404#n627 >> >> > > Hi, > > Could you also dump: > > td->td_name > > Exactly which thread is this? > > We do have a user-space build for XHCI at stand/usb/test . It won't > attach, but maybe there is some compiler warning there? > > Did you try do build a kernel with -O0 I.E. no optimization options? > > --HPS > One more thing: The XHCI hardware in question is little-endian? --HPS From nobody Sun Dec 5 21:00:18 2021 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 EBA0418BFF39 for ; Sun, 5 Dec 2021 21:00:20 +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 4J6f8g2nthz3H5P for ; Sun, 5 Dec 2021 21:00:19 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 DFC391EEA4 for ; Sun, 5 Dec 2021 21:00:18 +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 1B5L0IUS014704 for ; Sun, 5 Dec 2021 21:00:18 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1B5L0IMC014703 for freebsd-arm@FreeBSD.org; Sun, 5 Dec 2021 21:00:18 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202112052100.1B5L0IMC014703@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, 5 Dec 2021 21:00:18 +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="16387380182.87a1E.13704" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638738019; 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=d2GpiQRAUNKgVLTGJLAhnUsCfhfFN5VIFmlndwk6Ji4=; b=j/77G91O+Cop8clUDhMDqJaXcZQ/NhI0b0ltOKLc3yIi+8OdhjxWP7N2UYHWDh5WKghDid FY5gTYPXJJs8jh5Ct2gAs4x8Y0hs7tcfNlfjSZLbZWJ/mUbT8S/hOlcgizLUnZL1ozRA2/ 30ULLculQm37PUgbO7NxF5gY6ePMU3LB5pJJdarJlaNaqWQ6X7vV4KKbCIpIWrKjiNQxrd 5ZiGC/dqtq95coTIgxLtgMNpd6p/yoxd9B82nG323tc1hKxFvlHphsWyjQLqq7IYRefy6j UteoglNzPBPS+TS13BB2B6zF7mOhmNS0ZeBuuTKKl0Laf3d7zaj74Rp+ozUBeg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638738019; a=rsa-sha256; cv=none; b=NyWtULhDgXPITetJQf8Sz1SK6tOsn28w4SXc8t3VePXyi+LA/Tj1cyF7k5+KKiz0EQJNfo Op9oKXstEEWyS3ps2ZqvIa/65bFA43OmA9l2oOX03AkMrPi+rJUQFztdDkSi2jst/w/Ylo 7tB073VVl8rQ9e0fWqz5dOTtkhQ2NTtNo0oVXgdcTptZinlnRjxaG8x0WkBtsvG8dx3pwy k4FX5bYpmChFCJP9Bc9EDjgevnMQWthx/GzNyw9X1KHXKWjKh9+jrnZ17tt9RDsx6BKCcK Hp5PDVlfhSKDm2p9vwUiGjmhH0iZ54cSJddxh0ofibXEbRw+NAlZm19YxI+VFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y Status: O Content-Length: 869 Lines: 22 --16387380182.87a1E.13704 Date: Sun, 5 Dec 2021 21:00:18 +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 | 239673 | Spurious Interrupt message from /dev/led/led1 Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 3 problems total for which you should take action. --16387380182.87a1E.13704-- From nobody Thu Dec 9 04:36:20 2021 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 F0DAF18CAA43 for ; Thu, 9 Dec 2021 04:36:32 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8h7g4bHRz4RWS for ; Thu, 9 Dec 2021 04:36:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639024584; bh=2M2qdLcclsuuDgi+/dDvi8J4HkaTIU4PoEKDicTg4uc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=KRsN5Q0FaKHrUGxdtxnM0fVJq5G2357GKAvPNrBlLfdU+opTpwktP3xihZZ16+M1jW7PMizC1cmKp8eArx10b8THlzYlly/L36h0eMGa6OX5msZfDIwmlLoRuEeVvoo7qZh8z3wsFEusLhkz8grz/H8fzVrUH53ZQwkyb+cxbbYPOXpqN8+7fqUWTFikqf1TnCBIr2q6xT8hiFg1Z+1XG97I+SVKlc8BqUzveBZzSEC9pFnriR2BRza4YDNuD57gBZL49olsCQgD9ywlrFkn9hAcZB+rUAzc8TiUpU4NXRBjo2RwJwMVw/vV3KA3ZYwCVe9UoXSiSICKyFJMC1SfCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639024584; bh=Nocr4LHPYnnbsCeXB2UwVE/xI4d+A0ARSd++4lDTzNP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ej5kzXsh1QUB03p0i4M9Lgaznje5kixvVYPAhuOPyNItpeYLlsQ7h3/I5QMcZ95gemeXJSXhsP9iB4QEcuHYuJ06IYEw6DfGVbQXwVzVyPZARm/7Dn0gUb3SsK7TJoQMcP9DXNMQSeJb6JhXQLI1hBzwEE4oSg6Qp8JcE8LacCofFvQHerlKvuetjU56fDxftcu5FpOkY669bJOOdygymsK7GeZz65zJum1oORG9eV+s5UKcVIquaEEPmNcm/idjhPCvHHFXAFMRKFKrtlCMtqBe2BIMbIy46melNpLNJEM+ryldNWclr2GID5XZg8/hLS0eEO/ZhhiZa+vKXyGdDg== X-YMail-OSG: 4sbKzEEVM1novzWYNMeTgoegMESay40lRGfFVUQFBu7wUJfVtlrppOXrNA3pYjn R_ofSWRIC0uNJ_Pj.fVOHF2A4ICG3Q5Kl160S8BPbVJnOinC9jemBYTwl1cN_8Om0dF52c2Ac0Di UBh_7Q1m_UPTsesGUfqHBJa69p6b85hl31Xtlp8ZSU1RPOgv1dVPoFXMwet_OwjkHkW_qvpQ1l45 hxiR70gV_kIm2kZc_G6dZs0.VPW2lH8fA5vhP3.45Rhel6n3Se1w8yH3KSG0CHbt6YkdglLCquhA REhARtu.jydnTyPEuhTH8LoJNXHaBc1BtNyxL9kEvstuBgSRdGfMCJVxaqDJlWIFgRW0YewIRUSd QvDZU.dI9QM_16cKxAZBP2ysqNfeEl8ihY1O2XLZLZgfGKoNTRFws.bi8Ure7Ocxwv3VLy64VbRf T9mHRVP7IjX8gXwPxAlcQ6dLxgrPdD7Tu8kqIKTQ9hsHPqXqB6wfYCVa1aO3W2S5sOFmPwyWOx2G CX09gG0Yy_6dBlRgeVMxhkD4RKqm8jSHsxQADUZ._NbsNqnAjvLwc4NaYc8._CpI9u2YtNYzgfLD fCXBIE7x2Kqxur1CpkH2DvSnuZww9WM.5knuHX6tXsq3xlSKDT2SqnlKsifLkQBHQrHhsCpiZ.CK 3AdQlKNjcYn1HhJCZl.XFkhAn3kETFBD6C0CJy5HOHElkjL5cR.nJqNf1SGfLPg17dHNiTILZQNB FPAeZVQZei0phZKzfMrXpy9rb85_LFxGlwVuZszetGeL2g9Pd8QBBZach_dykKyJ3iNRrChy61f7 j_uUc9jnae39fZIv01r0SvmdVfK0rPa7KCGK3D7x8pqTeY8kpIlI2aI3VQz0CNWp9NgicVvWtLN. QgIJpfgBDku7.C593XUAk1Q9DDP_uxmtIN0D2Y7wLC7YWzHh5yhu33Y77sKx0hEaIGPLKoXstz6M PYH8qH3jSyUDBXSyCpFD3rokJUWC1Tz6m3cm3VBHYrNJQAbObjYhSJlrjOxTWVqE.EHpUKh.zudM Bq0W9.pRz2aYogxVQrVWEXSHJgHWWrQ6lRkWW1F.4lYRgO00.NSpjlZHWBKNsgyuAOjRtLdZPVFR NubRnYBd0D0dOVgE4iU5rgc6RQWltzasL4s47DsN6NM67yK9IB8rMhyilknbUZ39b_nGCa._8ay. dC0aCqHdcU3Pa7he0oifeddd6A1910neXM9lBhNrHo5I7Y1QsdCT4P0AJOzfHZJ59WsIJ4nZauU6 niS6uzxOMpZBt6wjNg7shCRwLaxKufLytDAp_np5_wqQMexEyzVeGMDJDZiATHkn6wL0IC4bb4is wU5kHvVq.mu_D3nVIfo4oJlHgeu9Hbbvwrz_WgWkDiFb8IuvO0Zw83N6gPGlX0cLflTBnOJ8rotu uXvHHmNmzK7MCyc._88tX8XCN0SA2OvHcNOZ4mrYCENXwC.ohX7mSrFzjMz0lKDHyXiBldrEDDpW _TNGA9A1FBVMIRY.GMa0cayZfCRUpquXzTJGBOdCpTcVgwzW27Gr0LaF1Fc46o6ekXSYYyjUHFXN _v0siAhOiI0qwU937QjppXdyKLQMH3GJofcVtt3cFkbXTLwwmC63RAB3RHwVCu6g_7Yqb.jImI5I rH6iCLs1rbFO5Y.jgJBMetzFr0qnIOsv9vq_SNU6M8Knam7UUUDcGiBZh7hmjzj0cXM8JWpA52z5 JPvo3ufVo4DQlIBe5iV3MRnPPzaAgAQGkpcV83i7OQOholMfoBs6RxGVtiXxIw1qCduIcMIswAlq rJ94Pw01YXbnTmyRwag3w0Un5Gs1UOj1SJ1zbAtBY81FRgUkV2cCuxqY46rurHHPPRf0_xDi8ZYl iF6BkEtc6dWF5Q4VADUY_CiVdDryZccd5kNvVBR0GjZ7hRgc1CGAqHWPB64ZO06EAe6nKDBwWOxx vdP4hj89zX7Au7bWtImXd1XuzYrONpddtjTtNiO_SpjROnTfGXRFaKNokbi0aVwO_mtO_bgZtnmA UWsHzWngIgtpdnL5RYBKsGMz_hjk2EUe0SKmKwPZXPzQpfcuh.nw3C0QuUXbHxFCDTyCSJw4i7iB G2gajIgdZG2cgmbzep8ko0L0Qptttq3MYpwfn_Viz3QxNjGS8Gq7mciVBv4b5PhA.PkBGjNcIis3 s46Ckl_Y19tRm_vCXOGZXI6zkeq303v1zE2fdF3H2TymZX51DsgoqpP.6AGONEuml7EFq9ZMbbJw KJHdTA6YhIJGNCEf_v9QavAd1U5FKnS5cSvOLQzpSlCStTmap2yIaeZdz_89QQ66CjEAIK4Q6.kV eXqrevdRpv0NP099n_0QuYt8aKD5QvQJ6TeyDNxK607LiSvG_Reu7RSc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 04:36:24 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 89169ce0427b25631466466fdb204c8d; Thu, 09 Dec 2021 04:36:21 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-Id: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> Date: Wed, 8 Dec 2021 20:36:20 -0800 Cc: "wma@freebsd.org" To: freebsd-current , Free BSD X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> X-Rspamd-Queue-Id: 4J8h7g4bHRz4RWS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KRsN5Q0F; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6159 Lines: 185 [ Note: wma@FreeBSD.org is only a guess, based on: = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] Attempting to update to: main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 resulted in boot failure (showing some boot -v output): . . . mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 150.000MHz (HS200 timing) mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at = mmc0 150.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Trying to mount root from ufs:/dev/gpt/Rock64root []... Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy mmcsd0: Error indicated: 4 Failed Note the the above line. It seems to be unique to the failure. Continuing the output . . . uhub2: 1 port with 1 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub1 umass0: = on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0: Attached to scbus0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: Nothing more after that. An older kernel (1400042) that happened to be available boots the same configuration when used instead (same world) . . . main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 52.000MHz (high speed timing) Note the lack of trying "150.000MHz (HS200 timing)". Continuing the output . . . mmc0: setting bus width to 8 bits high speed timing mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at = mmc0 52.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 Note: The media is actually an e.MMC . Continuing the output . . . . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... Trying to mount root from = ufs:/dev/gpt/Rock64root []... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM uhub1: 1 port with 1 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub0 umass0: = on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: random: unblocking device. Warning: bad time from time-of-day clock, system time will not be set = accurately Dual Console: Serial Primary, Video Secondary start_init: trying /sbin/init . . . (I'll stop with that.) So I end up with a 1400042 kernel and a 1400043 world in order to boot. The e.MMC has only: # ls -FTld * -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ where the etc/ has only: # find etc/ -print etc/ etc/hostid World comes from the USB3 SSD that is attached but the kernel comes from the e.MMC instead. (The kernel can deal with the USB3 SSD just fine, unlike the U-Boot that is involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 9 07:19:30 2021 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 CA21618CA872; Thu, 9 Dec 2021 07:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8lls2f6Xz4pj9; Thu, 9 Dec 2021 07:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639034375; 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=dYIm2IvNtGD8uFElzq79bEp/+XXQs/acxNGY94xfjRU=; b=Bwie8Ujg7TXZmBkI7FV1tDPKXRQNzr/FuEuKF0q4wUoegSXMeKJ8eNiTrvKZ7j4M9Jps/Q ldnpgBHidfnmvXOIfcVULQu5zxJucQbdpkluJD18WsBZWpqRHz2qY4+v5LTvEMiAQQ9mBb GNWQirljogjwvFJAU2NkqHeyIndjOys= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id bd1b18cb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Dec 2021 07:19:35 +0000 (UTC) Date: Thu, 9 Dec 2021 08:19:30 +0100 From: Emmanuel Vadot To: marklmi@yahoo.com Cc: Mark Millard via freebsd-current , Free BSD , "wma@freebsd.org" Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-Id: <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> In-Reply-To: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@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: 4J8lls2f6Xz4pj9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6802 Lines: 193 Hi Mark, On Wed, 8 Dec 2021 20:36:20 -0800 Mark Millard via freebsd-current wrote: > [ Note: wma@FreeBSD.org is only a guess, based on: > https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html ] > > Attempting to update to: > > main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 > > resulted in boot failure (showing some boot -v output): > > . . . > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 150.000MHz (HS200 timing) > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Trying to mount root from ufs:/dev/gpt/Rock64root []... > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > mmcsd0: Error indicated: 4 Failed > > Note the the above line. It seems to be unique to > the failure. Continuing the output . . . > > uhub2: 1 port with 1 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub0: 1 port with 1 removable, self powered > uhub3: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub1 > umass0: on usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0: Attached to scbus0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > > Nothing more after that. > > An older kernel (1400042) that happened to be available boots > the same configuration when used instead (same world) . . . > > main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: > > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 52.000MHz (high speed timing) > > Note the lack of trying "150.000MHz (HS200 timing)". Continuing > the output . . . > > mmc0: setting bus width to 8 bits high speed timing > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > > Note: The media is actually an e.MMC . Continuing the output . . . > > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... Trying to mount root from ufs:/dev/gpt/Rock64root []... > GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM > uhub1: 1 port with 1 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub3: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub0 > umass0: on usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0: Attached to scbus0 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > GEOM: new disk da0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > random: unblocking device. > Warning: bad time from time-of-day clock, system time will not be set accurately > Dual Console: Serial Primary, Video Secondary > start_init: trying /sbin/init > . . . > > (I'll stop with that.) > > So I end up with a 1400042 kernel and a 1400043 world in order to > boot. > > The e.MMC has only: > > # ls -FTld * > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ > drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ > drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ > > where the etc/ has only: > > # find etc/ -print > etc/ > etc/hostid > > World comes from the USB3 SSD that is attached but the kernel > comes from the e.MMC instead. (The kernel can deal with the > USB3 SSD just fine, unlike the U-Boot that is involved.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > Could you try reverting 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 capability check" and let me know ? Thanks, -- Emmanuel Vadot From nobody Thu Dec 9 07:56:04 2021 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 2D2CE18D2FFB; Thu, 9 Dec 2021 07:56:12 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4J8mZ36W6Nz3Bv6; Thu, 9 Dec 2021 07:56:11 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 38EB54CEF; Thu, 9 Dec 2021 07:56:10 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Thu, 9 Dec 2021 18:56:04 +1100 From: Peter Jeremy To: Emmanuel Vadot Cc: marklmi@yahoo.com, Mark Millard via freebsd-current , Free BSD , "wma@freebsd.org" Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-ID: References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J6+/LmI2UsdAzFcT" Content-Disposition: inline In-Reply-To: <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639036571; 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: in-reply-to:in-reply-to:references:references; bh=4pbVLCEhWLw5S1+g0maESBGGdmeJJlcWjzblgNS6L3g=; b=mWzyOtaaNEfwfjY6r/lJfjK8L8NP6YaabcKBbvQnkEuozhEebBMdVld1hARyMXA2EkHyc1 S+Gw3QEZiyMccR6QMEEzl5j5sxwHV7rFHIlqLc9cgNc13WQ60kRhEc+Bfv7B4sUPc2CCgo 3EuEun1iGiJg7ptt+WAc1xzhhlX0h21Wd21gfQZHZrGiDly+SBeawRgnzOFQQF7pJLZ6/Q T9XPWIVK/wtfCiGBF3R9d0NunzxCLe/lKt8K7TSm6eshJ6ik2/Ts7vDFfz7wiZ4zBiZI3V RLCmUKX97/5NdCI6ihgMaggtWnoYthFS7otniMva29Swn4gbKNd2dOZ0FpMNaA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639036571; a=rsa-sha256; cv=none; b=V7jHe5MD6XsfMNsiNYsVX1vr8vkZIG2k9NdqpPG/Qbi6F6dX3BEMrlAak6hrvqWhtm5Fou I76pFQonjkHGOuMf5zV1J01AXZaenbGFocWbvs4DyzOFI60dImflVTkJN4Xwh+IXcs+RvB MAwVA2S4uxYX1SrRfnyFK+edKa6MEhFAw2o6fX8hpyq6IvA/DVFN4dJU83gWHMELwbbU4O unzkBiL1ml6+LiwJ5A1eyOBXa1ZbAjbj7vKwyeZ3Yb+qjjeQOveuXdkJKityZQf4i/l+Z5 CeuRx04rm0kSCM1x2f9YOHtmNxeC3HNfwlbWaDN8/Y8CIpNkE8I88AK6cOmK5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2833 Lines: 72 --J6+/LmI2UsdAzFcT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Dec-09 08:19:30 +0100, Emmanuel Vadot wrote: > > Hi Mark, > >On Wed, 8 Dec 2021 20:36:20 -0800 >Mark Millard via freebsd-current wrote: > >> [ Note: wma@FreeBSD.org is only a guess, based on: >> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/00= 1931.html ] >>=20 >> Attempting to update to: >>=20 >> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>=20 >> resulted in boot failure (showing some boot -v output): [hang just before root is mounted] > Could you try reverting=20 >8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >capability check" and let me know ? I had exactly the same boot failure but was still working backwards through the root mount code trying to isolate the issue. Reverting 8661e085fb953855dbc7059f21a64a05ae61b22c solves the problem for me. I'd noticed the mmc1 difference and mmcsd1 error: mmc1: bus: 8bit, 200MHz (HS200 timing) mmc1: memory: 30310400 blocks, erase sector 1024 blocks mmc1: setting transfer rate to 150.000MHz (HS200 timing) bud I didn't think it was the cause. I had tracked down that the hang was somewhere between https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n779 and https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n1008 which led me to suspect that the problem might be in the geom layer (eg g_waitidle()) but was still considering where to add my next tranche of printf's when I saw Mark's mail. --=20 Peter Jeremy --J6+/LmI2UsdAzFcT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmGxtotfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRyaw/+O2tvQyhKuY1h8uEf9bI1ovNWl8g6tLm4cIMotRcsvcsfmi4HgCAxZqTJ 0FYhYvU/kIe+8zWnjHEaHhPnbUYKiy52NB+VAGI2hyGSrA/TGNaxQytrrw/2jIQ8 /IfyCeYjBZHEPlncl59PzjZe3EPyy4ALd8ucQbChCTbpB1CSXIXMKtshWKsdvSen a+vNsUP/W74LTQ7tA3mbP6KnpVJS1aTUSULC2CrpvBugCL+UBziY4bUqFEi1gSAX yZ2DfeUI2aYHJ2ax/HqHIeFjAMEP5RC29v6oKqfpA013TnKFQgSxwZxPet/cpmpu Xq+qwMnfOsq4J8wVmP79uIfgEWOCZWiORZcYhac/0zHwbJoZo39BWMqqNr8YB9ma 4b84QV+wPMyCsTFIjWG5St5d0TYD31/eaHxNv614FNSbZKY+Cycg+xTkIPZI0caB XIfDjDKggeApufKQ2kpzNMH0RmqXWnXaoVfIt7fByR33E4J2za0MDDWBqXS5OGHl CXXtvKGG5cHCDnITC8ljb4Ao8x/Rut3utktQVqtARNu9AwGRpej8VoUi+AbaL6FR xtYGfrAY5VPZ9fCfprc9U/9WeFQ7tA5EHqmj5EBFWzjECHzE8EPHGGutwexIsNPo fT1TQi426eFX+TNjylh8w3/oKuWw6NSrjw2UGfEXBdOX5qlBCfc= =8yfU -----END PGP SIGNATURE----- --J6+/LmI2UsdAzFcT-- From nobody Thu Dec 9 08:43:30 2021 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 C102C18DC2E7 for ; Thu, 9 Dec 2021 08:43:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8nct3YwKz3KFJ for ; Thu, 9 Dec 2021 08:43:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639039415; bh=OHf/eIGk2HKlfNHvy3eK0m2JQS74LODSz/7yWhiu1cs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LJXE+0y74Y6xFAFeZOKFMSTjEBBGeqiBCJx9XoWiXb5WkzRGLyvQioDURR2iglpz6JAxC4ZhZi/Y6WJI/n/mUYwgZINQcOi/sVjkTLJ2skvU5vfByuea6Kn0jwf7Ak3ouWNMo4QUqQ0yPOBTnMl+OXADLbrNisuEK7dqBtLDcppegnEoL8dDnxlDa1i78CTU/VrJqPmIpgEBrj4d1IWLSp7E6dHaByzevySBicLk8c7TzrJnKILQJHItn1l88sY5sevJL4c2frurwC7FqG3a4LGzzyW1EKR9Y3oyCU3qc1jqvOrzpGinljpzGMn4pe5sZXsknaGXbwHI8qLj+cUJxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639039415; bh=slj+LTsuRQ7D27TQV9KHnxqtkEKGPF7wYSa/ro31uXX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sR+9e2LcaI/jBX3tI5QcCRgvICxbLZnTHeYiE4Wr6XRA6mKsEyt0q9HODSETTUg8IkmzPGLoo7jwIPhpIGVYhPY1AlADo8EEO9ryFFypIk65ksKGBLVTx21FWRZjybU3ZKG2QZb8cVkd2fCNXpP9e+BE9V+cyZBP5olHeYauvOppSS2XdbyTo2HSRC0S8w2myHRKILn9M33Kpv1l47xC2HP3i23RfJhnerjeI5bUpi24bq6JoQ+vaYEZddRNvpoac8SFO6S0wNOyIWZ9eZUgVquWIr5IX4wgoPJ8pUP1ognABSRGNtEB0NoaDt1RtrFtEG7s9w100bM56IHQmRLdaw== X-YMail-OSG: CSYlqmgVM1myKV2eXUc6Km9UGd0XMpEZuQo4U69AfVRhVnFzQHdb5orPZ8Hi6RI EuwSQdFMWOz7pHz8WKpzmReTnsgKANcaOzox6LKpWII2vriOCF9z0XcdicBHjF3wE58.HncpqD69 bYaLas28fXhULa8vlhW9xvo1W0WVVZcvl3CH1HasyU77dC0erQTfLmcosJL13AHFkVzG7PvKdT_Q Co_VuRBTbpZD2Dhxdhsz2F9XnNjuIikrVnYx85lRdioo40cOo7Z07zECurkRs26bTE6.Usod1lhj 5JRvsgKM5gxxLxAdnEG61BqpaOi2nTRHIXdTi_xZ6ZszdppH.xD2gY9lhp.H_CH2ooI.6S7wnV4K K3EnCgvY7VQMjgkJqHsCT.M71IWkdDTmE1E4CEzXXdO1saNO1siDC3Lv3GF6rH8_I_1AX4JQSMMM 83OGe9GAJm5hjPEF_heqMy14TBcki4wImzKAetUtGRQf9UrVdqYD0hdTjgIYFctqFV3TINIGSL4X tTs_7F.Rceoh9RCHF0W7SVy2P1mNQViUrXouE9mkHAcKNvpkYZIbOj6MIUdYcsku7jKRwyLJrLpK efHAmMjOFoELtLfzODQ0HVyeNx4WS3ZMBFfIgLCAHMFN81djDCD9Be5zQnjBESAzuEQjOyfQVdjV MGc2BsjBEmcElb5osiC8pxiwYwT8hRt1nMHHr7iVTRdN4ompbBh2K8Mt6QbJlHvHKvHo0qfISBCE Q9ExM_KJA6WQEy4kszbWizCtOTnjlRGHOc8cSZ_5UTwqM0CAqkhRAcfn2mXHUxOEzF.C.JI2xMlL 5ZUGJZN9ujgB7nsSUW1quxYa4FS0bHfLlB4FTOEULHr22aIdzABM8t3G7.7Z8ajfyGk6UtfxpsLr dF08yBLxw0h_PyLfJdFUnVLSxWxLi7oE2JLiohS09jyzoL2s9rk8XKVLm7yon7ntUo.Wc89eGyHQ CHxlLJPOCq6gLLqceEqHxSKnd6n3nqCzbp2Pn_QyPM5qiJ.ESaftVUS5_iBfv9zMqOQ4tYj.YpeX Qv3VNS6eYG3.w6L2SYaKspoVATxUTPOry.WhCgxeo65hgVN71.usEm.9UKjFFJwxGgLQgyfU7Z4v bhCvsu06lHGkynYPedHRUxiI4.dVCLLdLrLWbzr1m5rDyNvDC14dEVc0G9irwtpNmhWoYrLtotmD tRbE3yuMzxY4j7e2jqdylHPpri.6eaM4spqHj9NDH2rewXZPNLwg8caAzYVSWc3aoz3YJdaXPUW7 ZT8wXbtZ4VTnI7mw7rCTFVeweSQsKb2_GkYlOf_CDMDCr2TlfU_mkP4iqYPbJ2ZbY_KtyF_iZT8l aVStHUmQkNht7sPwQ00emDayAozc4J7c2Qa_HWJD7INEg3iJ3feSFz5rMpljRB_pl.duokrGoXZp 8foKilk_qlvjME8jVSoPiG00KfKs_lUZXELmCvL4c__ZSaPGdCFlorXiMWQOQsYIm6.mdDEpB8ws SwcE5P9M7hcIZ40qCH4Bieo_o4OjGsSHlOq3GRTC3YwYXfLzLfuqMv8ulr5w0UK5hNZa0ngfY.3X CtoOfyzv.t5GmMRSi7ti0uWCHRNdg.KbBwNadM5WGMHw0rjE5yRdY_PgvINmUfut6MVsh9nqvHBo .uMCGPAcYVrQCfravcC0jADUyRiSF4lIC57EI2Z8K3GIFQ8Smbz.lcOUB16IbJN90445mFVLLFV0 zLZqQeHLKcRiRGaEXceVWV.Fp0Gy2yRR.xWCIfh1MBZNwiJPYmhqFKMXFS1N4ZZKCnXhabkxailw DSVWx6HRu63IQvwdhfV2giNVKPxIx0xQv9VtO_hkFhXPHQ2XkeabCHb3J4nS0jNqR0129qpF2XXU 6u6DePqRSqXRyl2XzwTdHvoaVdEGG9BF7QvEOcUIbF1zoJZZ_OfsO4H3UaGf50N5mLLe9MfhKf1Z Pp6grBVxV9WIrkd.KpzpI_4wiXVA_HhJxegM9BMolPX0_agf1PhRFCV4uyxMk4_nLCDWKej7s6Da LEc0LPYVRB6dddSddvJ_nR7OYhwSmgsdnWS6x_Vp_KvJMnAqXXyCn9q5GMmx_yUOwvXo4r6xY9Wq A.u3gAtfIlUcNhFwzbOn3XmIdlkQ2H_bl1C5_SqTkKa8S2MOBA2e8OCH6zBxMBARsJOsIy8nJpjG bGwbI9OE8XHb0exELRHo72Ic5_NznjY_SNhpJmpoTThltDazqtbQzLn8GyMDFxGgcKxwRD9iSQmI mqDbyvGka0_RKDdAC57btPdsA6op.qIbPMaOKaXyGpgWcuWlovd5HC8pD84VqMeTe3CTmLUNJHNE 8b5LJS4uy6lzAMzoFgDvDUFV7RQDcpOt_0L5m_YGxuN1CEWjAcNWtfKWBT7JAJmBAJUxOwMsdmnx HeehE1HizU5DJNydnOAzUnFq7.A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 08:43:35 +0000 Received: by kubenode516.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8b58202c2e79b1a94e1342e8390950c1; Thu, 09 Dec 2021 08:43:31 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> Date: Thu, 9 Dec 2021 00:43:30 -0800 Cc: Free BSD , "wma@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J8nct3YwKz3KFJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 8288 Lines: 238 On 2021-Dec-8, at 23:19, Emmanuel Vadot wrote: > Hi Mark, Hello. > On Wed, 8 Dec 2021 20:36:20 -0800 > Mark Millard via freebsd-current wrote: >=20 >> [ Note: wma@FreeBSD.org is only a guess, based on: >> = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] >>=20 >> Attempting to update to: >>=20 >> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>=20 >> resulted in boot failure (showing some boot -v output): >>=20 >> . . . >> mmc0: Probing bus >> . . . >> mmc0: SD probe: failed >> mmc0: MMC probe: OK (OCR: 0x40ff8080) >> mmc0: Current OCR: 0x00ff8080 >> mmc0: Probing cards >> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >> mmc0: Card at relative address 0x0002 added: >> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >> mmc0: quirks: 0 >> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >> mmc0: setting transfer rate to 150.000MHz (HS200 timing) >> mmcsd0: taking advantage of TRIM >> mmcsd0: cache size 65536KB >> mmcsd0: 125GB = at mmc0 150.0MHz/8bit/1016-block >> mmcsd0boot0: 4MB partition 1 at mmcsd0 >> mmcsd0boot1: 4MB partition 2 at mmcsd0 >> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >> . . . >> Release APs...done >> regulator: shutting down unused regulators >> GEOM: new disk mmcsd0 >> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 >> busy >> GEOM: new disk mmcsd0boot1 >> Trying to mount root from ufs:/dev/gpt/Rock64root []... >> Unresolved linked clock found: hdmi_phy >> Unresolved linked clock found: usb480m_phy >> mmcsd0: Error indicated: 4 Failed >>=20 >> Note the the above line. It seems to be unique to >> the failure. Continuing the output . . . >>=20 >> uhub2: 1 port with 1 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub0: 1 port with 1 removable, self powered >> uhub3: 1 port with 1 removable, self powered >> ugen4.2: at usbus4 >> umass0 on uhub1 >> umass0: on usbus4 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >> umass0:0:0: Attached to scbus0 >> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> pass0: Fixed Direct Access SPC-4 SCSI = device >> pass0: Serial Number REPLACED >> pass0: 400.000MB/s transfers >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number REPLACED >> da0: 400.000MB/s transfers >> da0: 953869MB (1953525168 512 byte sectors) >> da0: quirks=3D0x2 >> da0: Delete methods: >>=20 >> Nothing more after that. >>=20 >> An older kernel (1400042) that happened to be available boots >> the same configuration when used instead (same world) . . . >>=20 >> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: >>=20 >> mmc0: Probing bus >> . . . >> mmc0: SD probe: failed >> mmc0: MMC probe: OK (OCR: 0x40ff8080) >> mmc0: Current OCR: 0x00ff8080 >> mmc0: Probing cards >> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >> mmc0: Card at relative address 0x0002 added: >> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >> mmc0: quirks: 0 >> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >> mmc0: setting transfer rate to 52.000MHz (high speed timing) >>=20 >> Note the lack of trying "150.000MHz (HS200 timing)". Continuing >> the output . . . >>=20 >> mmc0: setting bus width to 8 bits high speed timing >> mmcsd0: taking advantage of TRIM >> mmcsd0: cache size 65536KB >> mmcsd0: 125GB = at mmc0 52.0MHz/8bit/1016-block >> mmcsd0boot0: 4MB partition 1 at mmcsd0 >> mmcsd0boot1: 4MB partition 2 at mmcsd0 >> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >>=20 >> Note: The media is actually an e.MMC . Continuing the output . . . >>=20 >> . . . >> Release APs...done >> regulator: shutting down unused regulators >> GEOM: new disk mmcsd0 >> regulator: shutting down vcc_sd... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >> GEOM: new disk mmcsd0boot0 >> busy >> GEOM: new disk mmcsd0boot1 >> Unresolved linked clock found: hdmi_phy >> Unresolved linked clock found: usb480m_phy >> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM >> uhub1: 1 port with 1 removable, self powered >> uhub0: 2 ports with 2 removable, self powered >> uhub3: 1 port with 1 removable, self powered >> uhub2: 1 port with 1 removable, self powered >> ugen4.2: at usbus4 >> umass0 on uhub0 >> umass0: on usbus4 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >> umass0:0:0: Attached to scbus0 >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> GEOM: new disk da0 >> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> pass0: Fixed Direct Access SPC-4 SCSI = device >> pass0: Serial Number REPLACED >> pass0: 400.000MB/s transfers >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number REPLACED >> da0: 400.000MB/s transfers >> da0: 953869MB (1953525168 512 byte sectors) >> da0: quirks=3D0x2 >> da0: Delete methods: >> random: unblocking device. >> Warning: bad time from time-of-day clock, system time will not be set = accurately >> Dual Console: Serial Primary, Video Secondary >> start_init: trying /sbin/init >> . . . >>=20 >> (I'll stop with that.) >>=20 >> So I end up with a 1400042 kernel and a 1400043 world in order to >> boot. >>=20 >> The e.MMC has only: >>=20 >> # ls -FTld * >> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >> drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ >> drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ >> drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ >>=20 >> where the etc/ has only: >>=20 >> # find etc/ -print >> etc/ >> etc/hostid >>=20 >> World comes from the USB3 SSD that is attached but the kernel >> comes from the e.MMC instead. (The kernel can deal with the >> USB3 SSD just fine, unlike the U-Boot that is involved.) >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >>=20 >>=20 >=20 > Could you try reverting=20 > 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 > capability check" and let me know ? I'm in the middle of something on the systems so it may be a while before I do that. (I think it will be my first individual revert of some specific old change via the git context. Hmm.) Also, I do not know enough to tell the difference between: that test being wrong vs. mishandling of the combination (presuming it is supposed to be valid) So I may end up just reporting if it reverts to the old settings being in use vs. not. But . . . I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on it that is on the same type of e.MMC device and the e.MMC is used to boot. That old NetBSD reports for the ODroid C2 during booting: [ 1.8295810] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x000> [ 1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect = x 244277248 sectors [ 1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz So it appears that some form of HS200 is a possibility as far as the e.MMC device is concerned. (I make no claims about related Rock64 vs. ODroid hardware capability differences --or FreeBSD's intent for the Rock64 in this area.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 9 13:03:56 2021 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 1384818C9D4D for ; Thu, 9 Dec 2021 13:04:09 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8vPN04yqz4blN for ; Thu, 9 Dec 2021 13:04:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639055039; bh=uF78KNlz6lqx7XwNsnyRLo05q2htVMOmnfsXWIQ6mVk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EocBMID0q45fCen+zxzKRcfXDqRGikvTwod2GDobqgevi2mCWOWe++oqRt/2eNHamS6hv9z4r3g4nXdanKes2kc6Mf86pyvd9Zxb6wM2xZ5m+4Knz2f4vFh/nwN9RlPNAlCTYHmhBiUfhMIZ3n8yKtayxb2NugicfUIdnEYdbH7jgY3y2RRrdvIXjMWD2clX/TxEKFcM35jz+NAfy1CpBKput7YmOvkDM2CQST7B1sVYe4ttecGgYcO1jD1JAAQ0zEygs9g2yAH8QyCvhM+gGHstZC+8Qsa+Qsvk2feel2sWYreMpRJt5St2cWOekow3VHKpibGK0cZH53hXtjkoBQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639055039; bh=IYnyw7eSX8SqjbNmQrD3bWP6y8CYhbrHSd0c0C/s1SX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OzwHfA99CKl+h37Tq8qhz7fZrBr1lRrFUezHw4ExaqbxynZgvyC/iRo8gyhD/RP41KFS4cO1EqECGiNgLqd5c3EaGNrQD7qFYnWvBxCJeiJL+1/m/Cw/UYKH10DEHR4sEj0fChgQBc/aKrnIwLUqGGw67ytZQr5KRcMNuDNt1bl7b7uytOktj4NwTj3BP0tbl07+K7WSqXczhj1rF2GC+hpIbz5aTkaF66HLyHATVoMATJv2V6pjTl09IjtKSgBPpl4fUWLX9RmTJK3yuMuRHM6xzmGVtbHWlFjR7lFU5DWSjSd49Zk4nvWNm9uMgF5smzNoRLjLxzr43h6zW1sPSA== X-YMail-OSG: 9SdxpswVM1lyjvLUfR8hSwzWt48tdHzvwNexK7EMGrAwKljWJ8sh9bMmGvjOHPS YopugmN6q.i5w8FluDvm2507BWDRlCYiT_3DjUKXedG8rUE_Z5YnEZTx7EjM8j4.C.C45zrq2onz S1r_g8uQ73wC6YE9D2h.a8j4H9x4uyz.DXT30SAdX7.TCEJLUs0sTHAGlL9Q9beSuBhbsAE31JDh VownvC5TZXDurmWIIREhIRBU6PvDNUcsuZGKZdsVr9ASI_k0pDYsn6uFe1HAkj9HsV9Y7742bda. hW8IbDNBohFORuIy7BSHYbfinvozuiIGxgMNN6UmfnzFXws.M.ZaCc0Itec_wTNyBk0MoEejzM11 khfpPay6gvEf2mnHA.5dyt01oDAn9ZaptI3KYdb7ODnxB4r6M_12xplYF2_LKeXkK7R.OSJSoIb. Iyg4_CUuV7KdaniTrIipjKChFm28MyJoqv_OfWwirdYTbD3a69MjbYPBztTqpgAknDvm4nLVdVrT VRt7Ym9m7Hc36dHN8J3BYV9SAIBgLyxO5q0q8BkVWW6g.ukaxptR13wmCnZnBGftK65kbxv4ef3e iFFAstRukwDcExSNmznFsQwty.Ezp_2bOHVCM.dRCX5HmYeDn1PVosyoRmYT5Xw5_w_eSfCH2t8R S8f8JC3zfPDz.a1eFJpbKVRvzHZToTa1_rPAaBiJYrx7pAqIXClk4G6JwW3NjkamEY_VByssSmp4 2H_1NaPPtvE4kermED86HTAAVWeVfryCoGU6jw4AG8AOvX1k2P_4NVVzsfOfZg6lEvomaXYerW37 73OLklFg.To_.kcvxf1UPTh7TI.7F_0_5Jqm96ETFqSll4hYPte_x9t943ZeHjX2UKvFJgtnUmZJ fXhIHCELATTemCJOT3T3lhpp.YIA3fLY_JUjTTtgI1_TRBvXxtmNgtVkilklCvCBEz31BzlbW7c1 x6W8guiGYH1rokMA07zm8nVautxNLhtjG0TX.vwt6mDJoAqcB2OZ9YwpMdPOIAsuRUt_G5V5QAJv m3ilCV_Q13k6J.Fe5jyterbizg9JDON52EMWS2wYGkoJafn_z1YexduGzCTAeYlU_NUxvcGtPrFc PudQOZmmBECAsbKwiQSaqi65s0ByURQyvX0N8qSCinUDs1E8GQ66V5SG0JZE6Z9O8WFxFJol53We JeAMX9aA3gpyAZrg.L78ZHtPdhUO1CZiMunigXZ4SiZ91FLki9UvlYsYSEWak5dZ5zNWegKXm4R5 EYyPiLZtdmACxSzjGwAX2nd9OMkx.MJ7mZxly7iYrQiHGnESPFmfecMAUrWh.wikrrHsTclUje5L vXBj7h6iLdTmcX3AONBHqOiHYgwt90mai7iHViO5u0_PXS3ifaiRwO6dxt.vm9BALjpIEsy9H69K 06ZPaA61gTzIjnUkpeh0VIQsoiEMTqGdLV1RQvh7xYSRCscACuCnI_Hfpg.SDJCTBQcgesE64aoe G58IaQZOVcSUcIC.ThvchqMtvhx2CRWsUpFBnjRljE_bK6TNt981xeP5ciDp7af.j9rbN3eQIRAQ PbI8KNtgLJM__v5m6eq4QsivNQNLX5mh3qJHoUgYjc0oddJC_.XLlro4AK16ISTjh_Bv2c4h8BcE CReu8bR8hZf85YwVCZn7cAK59IZkyZiJ3Bn2aSwOjGV2NUEhPs8LrL6Jr_S9sji9zBWGWS3V4YxG YaENTzLgZfpugIH9INW7zW_hhYKO13889CXljy2IaNM3bVurmDxSftB7_JSRrhF7JguWtpu4OjFn E_JAwLfD6JGvsFkqVdQtizzdvHTglgbhDwY5wwtaAB8o4Q8pdfF.ibc45ueE1JhI2qXrNejcQBZD H_7sKlM4cCYyCDuBQTcwWLRTEYdngQEsIXHmGUFBf9HTO15_mPNyMepD.ivQI0TBfd2Z_79IwQ3J dWuVtgVMDV87y6Vj8JPXg2Db.Uiv.BnsGIxcLRTZkEFw762QS0IlAp_DcxA68h0gHGfPxy7tb6Th JnDtrgJpASHu8DdMzQjnwIFqW97Qm9d3h26stI43noEonbl9vE7o8qlukD7f0G6SNWG.bXFOEgXZ o6QLb_fe6dHTmLa1rgaWUGM2kF1_Ay0Vdy8hyn9drJ6uHZaZGC3Sty7pEHyo2ithUbDbnCENHmbn 0kmx0BX2NYSw9177ULx5M0Jn8vc9YLWUc_hcD9Q081iNMZp7aTJJhxhRw0cg5y_0DQ9T9pYAjxdQ hgc2Rd.mdU9S06mRp3cMyZYfKFDoQa7f2hKagwn7hscmFvNJbESaKO0byj96EYgoFrDy0Z4EAGMK keLn7oxPdQPebr.Sh.UPTzk43Z8Oz8B1waGHQhnIvo2H4b.V5QR4QcbHAwH17fe5a_L9_YtFFQn0 2qFz0Sz537ZFQ6lNUY8vjSXvD056XB2Q- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 13:03:59 +0000 Received: by kubenode519.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 50df20579072100774b613f18f07d9cf; Thu, 09 Dec 2021 13:03:58 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> Date: Thu, 9 Dec 2021 05:03:56 -0800 Cc: Free BSD , "wma@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J8vPN04yqz4blN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EocBMID0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9298 Lines: 258 Hello again. On 2021-Dec-9, at 00:43, Mark Millard wrote: > On 2021-Dec-8, at 23:19, Emmanuel Vadot wrote: >=20 >> Hi Mark, >=20 > Hello. >=20 >> On Wed, 8 Dec 2021 20:36:20 -0800 >> Mark Millard via freebsd-current wrote: >>=20 >>> [ Note: wma@FreeBSD.org is only a guess, based on: >>> = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] >>>=20 >>> Attempting to update to: >>>=20 >>> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>>=20 >>> resulted in boot failure (showing some boot -v output): >>>=20 >>> . . . >>> mmc0: Probing bus >>> . . . >>> mmc0: SD probe: failed >>> mmc0: MMC probe: OK (OCR: 0x40ff8080) >>> mmc0: Current OCR: 0x00ff8080 >>> mmc0: Probing cards >>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >>> mmc0: Card at relative address 0x0002 added: >>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >>> mmc0: quirks: 0 >>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>> mmc0: setting transfer rate to 150.000MHz (HS200 timing) >>> mmcsd0: taking advantage of TRIM >>> mmcsd0: cache size 65536KB >>> mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block >>> mmcsd0boot0: 4MB partition 1 at mmcsd0 >>> mmcsd0boot1: 4MB partition 2 at mmcsd0 >>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >>> . . . >>> Release APs...done >>> regulator: shutting down unused regulators >>> GEOM: new disk mmcsd0 >>> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 >>> busy >>> GEOM: new disk mmcsd0boot1 >>> Trying to mount root from ufs:/dev/gpt/Rock64root []... >>> Unresolved linked clock found: hdmi_phy >>> Unresolved linked clock found: usb480m_phy >>> mmcsd0: Error indicated: 4 Failed >>>=20 >>> Note the the above line. It seems to be unique to >>> the failure. Continuing the output . . . >>>=20 >>> uhub2: 1 port with 1 removable, self powered >>> uhub1: 2 ports with 2 removable, self powered >>> uhub0: 1 port with 1 removable, self powered >>> uhub3: 1 port with 1 removable, self powered >>> ugen4.2: at usbus4 >>> umass0 on uhub1 >>> umass0: on usbus4 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>> umass0:0:0: Attached to scbus0 >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> pass0: Fixed Direct Access SPC-4 SCSI = device >>> pass0: Serial Number REPLACED >>> pass0: 400.000MB/s transfers >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number REPLACED >>> da0: 400.000MB/s transfers >>> da0: 953869MB (1953525168 512 byte sectors) >>> da0: quirks=3D0x2 >>> da0: Delete methods: >>>=20 >>> Nothing more after that. >>>=20 >>> An older kernel (1400042) that happened to be available boots >>> the same configuration when used instead (same world) . . . >>>=20 >>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: >>>=20 >>> mmc0: Probing bus >>> . . . >>> mmc0: SD probe: failed >>> mmc0: MMC probe: OK (OCR: 0x40ff8080) >>> mmc0: Current OCR: 0x00ff8080 >>> mmc0: Probing cards >>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >>> mmc0: Card at relative address 0x0002 added: >>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >>> mmc0: quirks: 0 >>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>> mmc0: setting transfer rate to 52.000MHz (high speed timing) >>>=20 >>> Note the lack of trying "150.000MHz (HS200 timing)". Continuing >>> the output . . . >>>=20 >>> mmc0: setting bus width to 8 bits high speed timing >>> mmcsd0: taking advantage of TRIM >>> mmcsd0: cache size 65536KB >>> mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block >>> mmcsd0boot0: 4MB partition 1 at mmcsd0 >>> mmcsd0boot1: 4MB partition 2 at mmcsd0 >>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >>>=20 >>> Note: The media is actually an e.MMC . Continuing the output . . . >>>=20 >>> . . . >>> Release APs...done >>> regulator: shutting down unused regulators >>> GEOM: new disk mmcsd0 >>> regulator: shutting down vcc_sd... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >>> GEOM: new disk mmcsd0boot0 >>> busy >>> GEOM: new disk mmcsd0boot1 >>> Unresolved linked clock found: hdmi_phy >>> Unresolved linked clock found: usb480m_phy >>> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM >>> uhub1: 1 port with 1 removable, self powered >>> uhub0: 2 ports with 2 removable, self powered >>> uhub3: 1 port with 1 removable, self powered >>> uhub2: 1 port with 1 removable, self powered >>> ugen4.2: at usbus4 >>> umass0 on uhub0 >>> umass0: on usbus4 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>> umass0:0:0: Attached to scbus0 >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> GEOM: new disk da0 >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> pass0: Fixed Direct Access SPC-4 SCSI = device >>> pass0: Serial Number REPLACED >>> pass0: 400.000MB/s transfers >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number REPLACED >>> da0: 400.000MB/s transfers >>> da0: 953869MB (1953525168 512 byte sectors) >>> da0: quirks=3D0x2 >>> da0: Delete methods: >>> random: unblocking device. >>> Warning: bad time from time-of-day clock, system time will not be = set accurately >>> Dual Console: Serial Primary, Video Secondary >>> start_init: trying /sbin/init >>> . . . >>>=20 >>> (I'll stop with that.) >>>=20 >>> So I end up with a 1400042 kernel and a 1400043 world in order to >>> boot. >>>=20 >>> The e.MMC has only: >>>=20 >>> # ls -FTld * >>> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >>> drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ >>> drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ >>> drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ >>>=20 >>> where the etc/ has only: >>>=20 >>> # find etc/ -print >>> etc/ >>> etc/hostid >>>=20 >>> World comes from the USB3 SSD that is attached but the kernel >>> comes from the e.MMC instead. (The kernel can deal with the >>> USB3 SSD just fine, unlike the U-Boot that is involved.) >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>> ( dsl-only.net went >>> away in early 2018-Mar) >>>=20 >>>=20 >>=20 >> Could you try reverting=20 >> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >> capability check" and let me know ? >=20 > I'm in the middle of something on the systems so it may be a while > before I do that. (I think it will be my first individual revert > of some specific old change via the git context. Hmm.) >=20 > Also, I do not know enough to tell the difference between: >=20 > that test being wrong > vs. > mishandling of the combination (presuming it is supposed to be valid) >=20 > So I may end up just reporting if it reverts to the old settings > being in use vs. not. >=20 > But . . . >=20 > I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on > it that is on the same type of e.MMC device and the e.MMC is used > to boot. That old NetBSD reports for the ODroid C2 during booting: >=20 > [ 1.8295810] ld1 at sdmmc1: = <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x000> > [ 1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 = bytes/sect x 244277248 sectors > [ 1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz >=20 > So it appears that some form of HS200 is a possibility as far > as the e.MMC device is concerned. (I make no claims about related > Rock64 vs. ODroid hardware capability differences --or FreeBSD's > intent for the Rock64 in this area.) >=20 So, I tried NetBSD 9.2_STABLE on the Rock64 with a e.MMC as the boot media: it does not use HS200 mode (so it uses 52 MHz, not 100 MHz). [ 1.8672737] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0x9f43b223:0x000> [ 1.8773160] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect = x 244277248 sectors [ 1.8773160] ld1: 8-bit width, 64 MB cache, 52.000 MHz Not that I know any details about why, but it does suggest that the issue may be Rock64 specific, given what NetBSD 9.2_STABLE does with HS200 on the ODroid C2 . (I updated the C2's NetBSD vintage to match the Rock64 experiment so comparison/contrast results would be more reasonable.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 9 16:01:54 2021 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 AB27818CB87F for ; Thu, 9 Dec 2021 16:05:28 +0000 (UTC) (envelope-from mindal@semihalf.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 4J8zQc443jz52F1 for ; Thu, 9 Dec 2021 16:05:28 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: by mail-ed1-x529.google.com with SMTP id x10so3949936edd.5 for ; Thu, 09 Dec 2021 08:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dNHYvo27Tb887sgDlhvZL8qFxFU+J3ZKdstfq57pviI=; b=70yXonqwsLL2i61oyFnz88mCauqNCBh7M/yAwbHGlafbu/e4Fg/cNsyCQuoqbh4Jtq hoe4XrEuNbsBdQTfQjGUjuLf0kruKsbm1JSD4xFq7jJUPoie773rCWJd9uCA8vqVOmxb F85Hlofx0yZY8rSGLG5lygLt9uQqxDArx1MJFGYkLB4Y5qHEehXhXyOuUge4j+DlqYDr dcPL7fnEKkb3Sp+UG13ER71GjrXh0yzbJwujZDfKgsHLrmfYFO7s7V8/r/19SlMo2+tR YW9/pAinX6evq+BVL3+ErLim0zqvi1UXxHTo9SzMFRy6egX4F0TfZdGMm6/dZquUNaUd mDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dNHYvo27Tb887sgDlhvZL8qFxFU+J3ZKdstfq57pviI=; b=Pk7t+tuK4hG/a83VsVuL3J5zMAqwyTaQ7gM6jevMFYQCLM1zc/weCyP/u2aEWR50/7 /pOHwpYtdl6JyUnqw/se27U/DvBjMkzFxGLn2QcBf1Fe7tLFw617SMspjLPDx+zRWQJx xpV7TfeqtwQOFh7eJ/eaR7d4txseyx/TkOQKK5xc4kclQ2uqxjZbTSmIGxsR351Y8Fw4 O7sqI+Iq5wjaFCKXuh+nGJO1TFTz6ZbPLk1vM40TD4Mhdlcm86w3REXuYq59H5cb7BfH NG+FmfHEzdR5bqTdZESQ3w4BlLTimuKj01PlO1K+MT6OUxVZjB8Ei6Gor76NUTAAWT+1 4rGQ== X-Gm-Message-State: AOAM5336AcyTB37TpoZHiSpRL2+1UGXbuqZy//ybILqc76u7yYzt1LD6 qkT7NpVx1PDQmzR1+cjC3L3F+fGFs+VtRB3yKABFCkZANNOcJA== X-Google-Smtp-Source: ABdhPJzAcoHsZ9+JbvSPKP7AHukHvaoSNZnLxcDGQjAH/6n3CPJOag5ZRsR7gzfkQxrx5CpKnABn1KRl4p7z1AhO0aM= X-Received: by 2002:a05:6402:27cf:: with SMTP id c15mr25793387ede.128.1639065725726; Thu, 09 Dec 2021 08:02:05 -0800 (PST) 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: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> In-Reply-To: <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> From: =?UTF-8?Q?Kornel_Dul=C4=99ba?= Date: Thu, 9 Dec 2021 17:01:54 +0100 Message-ID: Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? To: marklmi@yahoo.com Cc: Emmanuel Vadot , Free BSD , "wma@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J8zQc443jz52F1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10119 Lines: 254 Hi, On Thu, Dec 9, 2021 at 2:04 PM Mark Millard via freebsd-arm wrote: > > Hello again. > > On 2021-Dec-9, at 00:43, Mark Millard wrote: > > > On 2021-Dec-8, at 23:19, Emmanuel Vadot wrote: > > > >> Hi Mark, > > > > Hello. > > > >> On Wed, 8 Dec 2021 20:36:20 -0800 > >> Mark Millard via freebsd-current wrote: > >> > >>> [ Note: wma@FreeBSD.org is only a guess, based on: > >>> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html ] > >>> > >>> Attempting to update to: > >>> > >>> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 > >>> > >>> resulted in boot failure (showing some boot -v output): > >>> > >>> . . . > >>> mmc0: Probing bus > >>> . . . > >>> mmc0: SD probe: failed > >>> mmc0: MMC probe: OK (OCR: 0x40ff8080) > >>> mmc0: Current OCR: 0x00ff8080 > >>> mmc0: Probing cards > >>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > >>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > >>> mmc0: Card at relative address 0x0002 added: > >>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > >>> mmc0: quirks: 0 > >>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks > >>> mmc0: setting transfer rate to 150.000MHz (HS200 timing) > >>> mmcsd0: taking advantage of TRIM > >>> mmcsd0: cache size 65536KB > >>> mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block > >>> mmcsd0boot0: 4MB partition 1 at mmcsd0 > >>> mmcsd0boot1: 4MB partition 2 at mmcsd0 > >>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 > >>> . . . > >>> Release APs...done > >>> regulator: shutting down unused regulators > >>> GEOM: new disk mmcsd0 > >>> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 > >>> busy > >>> GEOM: new disk mmcsd0boot1 > >>> Trying to mount root from ufs:/dev/gpt/Rock64root []... > >>> Unresolved linked clock found: hdmi_phy > >>> Unresolved linked clock found: usb480m_phy > >>> mmcsd0: Error indicated: 4 Failed > >>> > >>> Note the the above line. It seems to be unique to > >>> the failure. Continuing the output . . . > >>> > >>> uhub2: 1 port with 1 removable, self powered > >>> uhub1: 2 ports with 2 removable, self powered > >>> uhub0: 1 port with 1 removable, self powered > >>> uhub3: 1 port with 1 removable, self powered > >>> ugen4.2: at usbus4 > >>> umass0 on uhub1 > >>> umass0: on usbus4 > >>> umass0: SCSI over Bulk-Only; quirks = 0x0000 > >>> umass0:0:0: Attached to scbus0 > >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> pass0: Fixed Direct Access SPC-4 SCSI device > >>> pass0: Serial Number REPLACED > >>> pass0: 400.000MB/s transfers > >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> da0: Fixed Direct Access SPC-4 SCSI device > >>> da0: Serial Number REPLACED > >>> da0: 400.000MB/s transfers > >>> da0: 953869MB (1953525168 512 byte sectors) > >>> da0: quirks=0x2 > >>> da0: Delete methods: > >>> > >>> Nothing more after that. > >>> > >>> An older kernel (1400042) that happened to be available boots > >>> the same configuration when used instead (same world) . . . > >>> > >>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: > >>> > >>> mmc0: Probing bus > >>> . . . > >>> mmc0: SD probe: failed > >>> mmc0: MMC probe: OK (OCR: 0x40ff8080) > >>> mmc0: Current OCR: 0x00ff8080 > >>> mmc0: Probing cards > >>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > >>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > >>> mmc0: Card at relative address 0x0002 added: > >>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > >>> mmc0: quirks: 0 > >>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > >>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks > >>> mmc0: setting transfer rate to 52.000MHz (high speed timing) > >>> > >>> Note the lack of trying "150.000MHz (HS200 timing)". Continuing > >>> the output . . . > >>> > >>> mmc0: setting bus width to 8 bits high speed timing > >>> mmcsd0: taking advantage of TRIM > >>> mmcsd0: cache size 65536KB > >>> mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block > >>> mmcsd0boot0: 4MB partition 1 at mmcsd0 > >>> mmcsd0boot1: 4MB partition 2 at mmcsd0 > >>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 > >>> > >>> Note: The media is actually an e.MMC . Continuing the output . . . > >>> > >>> . . . > >>> Release APs...done > >>> regulator: shutting down unused regulators > >>> GEOM: new disk mmcsd0 > >>> regulator: shutting down vcc_sd... Trying to mount root from ufs:/dev/gpt/Rock64root []... > >>> GEOM: new disk mmcsd0boot0 > >>> busy > >>> GEOM: new disk mmcsd0boot1 > >>> Unresolved linked clock found: hdmi_phy > >>> Unresolved linked clock found: usb480m_phy > >>> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM > >>> uhub1: 1 port with 1 removable, self powered > >>> uhub0: 2 ports with 2 removable, self powered > >>> uhub3: 1 port with 1 removable, self powered > >>> uhub2: 1 port with 1 removable, self powered > >>> ugen4.2: at usbus4 > >>> umass0 on uhub0 > >>> umass0: on usbus4 > >>> umass0: SCSI over Bulk-Only; quirks = 0x0000 > >>> umass0:0:0: Attached to scbus0 > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> Root mount waiting for: CAM > >>> GEOM: new disk da0 > >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> pass0: Fixed Direct Access SPC-4 SCSI device > >>> pass0: Serial Number REPLACED > >>> pass0: 400.000MB/s transfers > >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> da0: Fixed Direct Access SPC-4 SCSI device > >>> da0: Serial Number REPLACED > >>> da0: 400.000MB/s transfers > >>> da0: 953869MB (1953525168 512 byte sectors) > >>> da0: quirks=0x2 > >>> da0: Delete methods: > >>> random: unblocking device. > >>> Warning: bad time from time-of-day clock, system time will not be set accurately > >>> Dual Console: Serial Primary, Video Secondary > >>> start_init: trying /sbin/init > >>> . . . > >>> > >>> (I'll stop with that.) > >>> > >>> So I end up with a 1400042 kernel and a 1400043 world in order to > >>> boot. > >>> > >>> The e.MMC has only: > >>> > >>> # ls -FTld * > >>> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > >>> drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ > >>> drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ > >>> drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ > >>> > >>> where the etc/ has only: > >>> > >>> # find etc/ -print > >>> etc/ > >>> etc/hostid > >>> > >>> World comes from the USB3 SSD that is attached but the kernel > >>> comes from the e.MMC instead. (The kernel can deal with the > >>> USB3 SSD just fine, unlike the U-Boot that is involved.) > >>> > >>> === > >>> Mark Millard > >>> marklmi at yahoo.com > >>> ( dsl-only.net went > >>> away in early 2018-Mar) > >>> > >>> > >> > >> Could you try reverting > >> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 > >> capability check" and let me know ? > > > > I'm in the middle of something on the systems so it may be a while > > before I do that. (I think it will be my first individual revert > > of some specific old change via the git context. Hmm.) > > > > Also, I do not know enough to tell the difference between: > > > > that test being wrong > > vs. > > mishandling of the combination (presuming it is supposed to be valid) > > > > So I may end up just reporting if it reverts to the old settings > > being in use vs. not. > > > > But . . . > > > > I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on > > it that is on the same type of e.MMC device and the e.MMC is used > > to boot. That old NetBSD reports for the ODroid C2 during booting: > > > > [ 1.8295810] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x000> > > [ 1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect x 244277248 sectors > > [ 1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz > > > > So it appears that some form of HS200 is a possibility as far > > as the e.MMC device is concerned. (I make no claims about related > > Rock64 vs. ODroid hardware capability differences --or FreeBSD's > > intent for the Rock64 in this area.) > > > > So, I tried NetBSD 9.2_STABLE on the Rock64 with a e.MMC as the > boot media: it does not use HS200 mode (so it uses 52 MHz, not > 100 MHz). > > [ 1.8672737] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0x9f43b223:0x000> > [ 1.8773160] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sect x 244277248 sectors > [ 1.8773160] ld1: 8-bit width, 64 MB cache, 52.000 MHz > > Not that I know any details about why, but it does suggest that > the issue may be Rock64 specific, given what NetBSD 9.2_STABLE > does with HS200 on the ODroid C2 . (I updated the C2's NetBSD > vintage to match the Rock64 experiment so comparison/contrast > results would be more reasonable.) I don't think de9c000cedfe has anything to do with it as it only modifies the Freescale sdhci driver. The Rock64 MMC controller doesn't use that code. In 8661e085fb95 I fixed the HS200/HS400 capability detection primarily for DT based controllers. Rock64 controller declares HS200 support with "mmc-hs200-1_8v;" property in the eMMC node in rk3328-rock64.dts. I guess that since it doesn't work the quickest WA for this would be to add SDHCI_QUIRK_BROKEN_MMC_HS200 to sc->quirks in sdhci_fdt.c. From nobody Thu Dec 9 22:54:29 2021 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 04AF218E4B46 for ; Thu, 9 Dec 2021 22:54:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J98Vm436Zz3rcY for ; Thu, 9 Dec 2021 22:54:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639090472; bh=wg65Lk8c/IBbEMk65EwrzMixKLEpYRnKzcnFHMeLjj8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T77Xb09Ssw3HkGNOzEeS+rG6cKlzM0vI/sqzSUd3JoGJWbKXxZNoXnODELKgOdPGdfKAPBBNndwaS6RE3Rnvz54jUgpKcubRaHQASjlLheIxNSwvXiSj2X96P7thLAgIuWTVzX1UMCzUcoii5hNJI6gODj/e+kLp6D49TtJyxp+B6mcAfcv6Ae47U9knwWOhWxKSdDtwc4L1oZS8kO1wqDZpyISz+k1IkpkSZM8786pvisBvte4DYmFcMYUqqGoM3Vmg4BmUXf3hgWLihzcNLOxGD5b/sgPtxMkIO0hMuuebEAJJhwynME0niCNzzVb3jIEv5cV95KC3o3J6xREdFQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639090472; bh=nehem5Jb+pGyiWIbpXjfVCS+sw7o2YeQa0dgTTouANi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Sigpbd26sXBXj5Dkxf+xPCyk7HpavDVgQB/iNBK6LaamXEdI+zqwXaO/vYL2vkeZQIW4KAEIP3k+CezYhA/V8wF7GQ2Sc6Ev+dE/i5kST62ydcjfxQKDojASeiaa2zTZ7Q0uTCT4grfTcuzOt8CdqXBUMuXquxSUSgJ5TszlRLEcIrv51kOg4xrnBdh+wy+y8MMzTgElUEqAHsd3D4B8Y/lLqEBfPZIfsbOljYtLaKQtyzGbL5foPkEmPapi0DTQt+bsGEKhRvO3+W/kwbzamQwCl81gYGGu1p0rUPEinDARKWDYrmi6bdoGvUV7L2n1JRotgQU5VNrGcoDMR+9xQg== X-YMail-OSG: bFTEUQQVM1lFMg6y6cdbtRhw7PNCukcKfYdFq4oX18IVPhPohgl7h1Pk3Hk.CI8 Mjha_u8JhwX0vS4Ts8egq5K0Jd.wY7Tt_nXpJvW_pH1vMjOCML89JFrBzKO2y3DUDGGV8fr6_W6t fzICSn8JPNmDtCBmPVfUiv0cxHYuepDbh7ufh5824rHl46SJzdXc4y.qmWTYREUDqbzrJNhRqhmP wPmkYaRD7QBmiCGOlT7YztD7nJze0qtTIo.1.M80Fbt_RTf1qHERFVeGDBoDeFD69MLlhoP66f17 MAdBOCLQ7P1dmA1dXVc3Cdtb929IKfHc78J3VsGmfBFjPTgmbGASuxm3sjOaKPJJjlB_Yp2uZPk1 tsuRZKYGTxXtoGgzh4hlh7jEG2VJeHfPVjWBLWnP_U98Z7lS8BCEcO2GniiFBkZcFceXNDihujtZ RslOnlRI6JxmKJ1wIvGpIo9i7ZyDHGknIWlumO.eKsmzucdjN.lfdFuZQgLNqrU33fIl8.id7Jff vjgla8z7UYQ4oHEFDZg8wzSPZuRNHlZaAiqcqg2V5uZ3uya9gWVitUjGeYh5XwGAOYQXvVkJFmie RscmOOjIY_gcwA_Ts_ZeEiuJOlerEiQv66WltXtAc80zuKciYWwlK5OHqO9.j4nKKMxrAmGylcYC pXXb2X7h9RLcMB2qRkLP6xW7nLOditjHjXQ0V5.dvuiT1mmXVIgMBbqNqT3j.CjP9u3YPIYwvAHX fJxkjmHyUdnTVMT2.Vdr1ZrT9fSL_pRjy_Hau2uYNzDV8O9P3Kx32JzxmaE6CtepdaLHV6Io42SB rR97NJ3Sr7G8VeniSrImBDxY6.D1mtNZgFEmUHKX_nfyktXdrAa18lnR0kXDwkM688PKC.EBgQlU xHw8WKoH5_2z.grGvpX6dB66i_qurMnqZxd3CMmloLNOb3CaRCt6svFzr0AYuEYarP_nUJBHVRlp l85Wch4181sNkhx6FvWJUQlsTuKcS9TLoMAA_jK237_NhGiH32kNH8Q2uQdZE.QGZ4Ywog_tOBvB HF9u2xueUoxHsKdHJLrs7lk6p8n.KvFTJQ7gHBE.Eis5qmnsywKXeAEvexsftlYqgpd2cW.OR1Is 8SU2SktzjIEbKbA42jOI4F9vdFan7hRLEodkPYi32M_lzg40RkQcybWpHrOV.3DO.DiIS0twoJhL PBDH1INXFDn8Coi5daa5lsYGziaPOzXCkhnLFRCrqaWr_q.JJcYdJLKAwYp_hCDHR8e2ZVkMz1Js Z4oymBtfxkAdpXCZ8DZ1uAzImsJffgacaDe0tt1YqRIu9rN.p_7df5gXdlnIzBPV6exyVhOlHEgO dJ7iyrSIiQj.iDZZ0KgoXbQUuDFiLsB9wuFFAwmowxfb_NhQ1l17_t3RwfDCk06b1eP7_BuMreSd cz.V31DqsO_plgICK4NxXz1UBJmUS7nmr1BV3DQA6_MQu9Aoi2alSwZ18DZ4_xVou1c6gtCc8Ia2 GF5FpCgDnzKtqBqIo67m_UFKKfRlYeR3WTUStKTme9ZfeGt3.eW6Juod_0k2pfZbRKBXjuy.m.Xf uX21_giTjWcLs_gMNDP9Eo6H3tvM3QtOQh780ALBrB1OiuxXsjgKO7Ke67kfHj0o_JM.s1PIFaFY UP78N1okW3EqggkL04BQKDoiWrKKVmtGcFoq4AEmk0PFJyf.Iq2dUMWcfHuiKVmG645xHD8IHFs8 krpRgcJC8W8wBoFWgt4IHk.LvSnIK3BgZISfzba3ql_Cc8dyByh_XcnLv0mjkdmRXgZmGUQBMBBj Bh7EiwOm5a_b3J0_t1331YbPpXddKSSx9cL_mBJ5j0mZ4l9DD71qrsBwbX38gEdMX8eqnWGj3oTP 1_MJq99XI.8JE9KUcTjNZejd0K.A_YYqOAVOw2s_BMzqKq3ZXEUUATl0ZzXJQONCILbQGOBaHkWu mQ6KAnhPTDtMbNOhDufyhOP1CY_yhJZRPkDePQllYN_umcM6T0z9A6deePvDVAzxYkEJL8p3xC5Z pU4cU2J_YCU4sPk2eYD3hv437h4zaC0JYEBCbUmeQSPeYd0KF_NgKEFLcYvgoKUWX6SBKoaPXrzw xwKooSnRihVmRVpI2XUU9zjyap_bRdqNv5WitvzxOAZGVUl3atkCZPbxKvhNa7p4uniMF13dZOpo xcY6AH4LHf_Bsf53ZwRCou79XCrbKaUvLP3XEYToYzcQaDHgBkPx8TgtWbemaTX2B7G1ERRb_hhn tWVHmJ15qentlxCHP9iUOoAhHhGxiRJn8p_Abk4K7ZGscU8qI0D_c19QJOYK1LklV5PuIdtKAzwb 05eFfj5Hy7.X8RdyiZ7Do73YEZxx4YwHCP33zPyEQJGi8cb7A30wnZsFu_g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 22:54:32 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 47e69ff75d61196a85e78f6822aad1a0; Thu, 09 Dec 2021 22:54:30 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: Date: Thu, 9 Dec 2021 14:54:29 -0800 Cc: Free BSD , "wma@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot , Peter Jeremy X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J98Vm436Zz3rcY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 14937 Lines: 385 On 2021-Dec-9, at 08:01, Kornel Dul=C4=99ba wrote: > Hi, >=20 > On Thu, Dec 9, 2021 at 2:04 PM Mark Millard via freebsd-arm > wrote: >>=20 >> Hello again. >>=20 >> On 2021-Dec-9, at 00:43, Mark Millard wrote: >>=20 >>> On 2021-Dec-8, at 23:19, Emmanuel Vadot = wrote: >>>=20 >>>> Hi Mark, >>>=20 >>> Hello. >>>=20 >>>> On Wed, 8 Dec 2021 20:36:20 -0800 >>>> Mark Millard via freebsd-current = wrote: >>>>=20 >>>>> [ Note: wma@FreeBSD.org is only a guess, based on: >>>>> = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] >>>>>=20 >>>>> Attempting to update to: >>>>>=20 >>>>> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>>>>=20 >>>>> resulted in boot failure (showing some boot -v output): >>>>>=20 >>>>> . . . >>>>> mmc0: Probing bus >>>>> . . . >>>>> mmc0: SD probe: failed >>>>> mmc0: MMC probe: OK (OCR: 0x40ff8080) >>>>> mmc0: Current OCR: 0x00ff8080 >>>>> mmc0: Probing cards >>>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >>>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >>>>> mmc0: Card at relative address 0x0002 added: >>>>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >>>>> mmc0: quirks: 0 >>>>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >>>>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>>>> mmc0: setting transfer rate to 150.000MHz (HS200 timing) >>>>> mmcsd0: taking advantage of TRIM >>>>> mmcsd0: cache size 65536KB >>>>> mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block >>>>> mmcsd0boot0: 4MB partition 1 at mmcsd0 >>>>> mmcsd0boot1: 4MB partition 2 at mmcsd0 >>>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >>>>> . . . >>>>> Release APs...done >>>>> regulator: shutting down unused regulators >>>>> GEOM: new disk mmcsd0 >>>>> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 >>>>> busy >>>>> GEOM: new disk mmcsd0boot1 >>>>> Trying to mount root from ufs:/dev/gpt/Rock64root []... >>>>> Unresolved linked clock found: hdmi_phy >>>>> Unresolved linked clock found: usb480m_phy >>>>> mmcsd0: Error indicated: 4 Failed >>>>>=20 >>>>> Note the the above line. It seems to be unique to >>>>> the failure. Continuing the output . . . >>>>>=20 >>>>> uhub2: 1 port with 1 removable, self powered >>>>> uhub1: 2 ports with 2 removable, self powered >>>>> uhub0: 1 port with 1 removable, self powered >>>>> uhub3: 1 port with 1 removable, self powered >>>>> ugen4.2: at usbus4 >>>>> umass0 on uhub1 >>>>> umass0: on usbus4 >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>>>> umass0:0:0: Attached to scbus0 >>>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> pass0: Fixed Direct Access SPC-4 SCSI = device >>>>> pass0: Serial Number REPLACED >>>>> pass0: 400.000MB/s transfers >>>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>>> da0: Serial Number REPLACED >>>>> da0: 400.000MB/s transfers >>>>> da0: 953869MB (1953525168 512 byte sectors) >>>>> da0: quirks=3D0x2 >>>>> da0: Delete methods: >>>>>=20 >>>>> Nothing more after that. >>>>>=20 >>>>> An older kernel (1400042) that happened to be available boots >>>>> the same configuration when used instead (same world) . . . >>>>>=20 >>>>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: >>>>>=20 >>>>> mmc0: Probing bus >>>>> . . . >>>>> mmc0: SD probe: failed >>>>> mmc0: MMC probe: OK (OCR: 0x40ff8080) >>>>> mmc0: Current OCR: 0x00ff8080 >>>>> mmc0: Probing cards >>>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) >>>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) >>>>> mmc0: Card at relative address 0x0002 added: >>>>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 >>>>> mmc0: quirks: 0 >>>>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) >>>>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks >>>>> mmc0: setting transfer rate to 52.000MHz (high speed timing) >>>>>=20 >>>>> Note the lack of trying "150.000MHz (HS200 timing)". Continuing >>>>> the output . . . >>>>>=20 >>>>> mmc0: setting bus width to 8 bits high speed timing >>>>> mmcsd0: taking advantage of TRIM >>>>> mmcsd0: cache size 65536KB >>>>> mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block >>>>> mmcsd0boot0: 4MB partition 1 at mmcsd0 >>>>> mmcsd0boot1: 4MB partition 2 at mmcsd0 >>>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 >>>>>=20 >>>>> Note: The media is actually an e.MMC . Continuing the output . . . >>>>>=20 >>>>> . . . >>>>> Release APs...done >>>>> regulator: shutting down unused regulators >>>>> GEOM: new disk mmcsd0 >>>>> regulator: shutting down vcc_sd... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >>>>> GEOM: new disk mmcsd0boot0 >>>>> busy >>>>> GEOM: new disk mmcsd0boot1 >>>>> Unresolved linked clock found: hdmi_phy >>>>> Unresolved linked clock found: usb480m_phy >>>>> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM >>>>> uhub1: 1 port with 1 removable, self powered >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> uhub3: 1 port with 1 removable, self powered >>>>> uhub2: 1 port with 1 removable, self powered >>>>> ugen4.2: at usbus4 >>>>> umass0 on uhub0 >>>>> umass0: on usbus4 >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>>>> umass0:0:0: Attached to scbus0 >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> Root mount waiting for: CAM >>>>> GEOM: new disk da0 >>>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> pass0: Fixed Direct Access SPC-4 SCSI = device >>>>> pass0: Serial Number REPLACED >>>>> pass0: 400.000MB/s transfers >>>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>>> da0: Serial Number REPLACED >>>>> da0: 400.000MB/s transfers >>>>> da0: 953869MB (1953525168 512 byte sectors) >>>>> da0: quirks=3D0x2 >>>>> da0: Delete methods: >>>>> random: unblocking device. >>>>> Warning: bad time from time-of-day clock, system time will not be = set accurately >>>>> Dual Console: Serial Primary, Video Secondary >>>>> start_init: trying /sbin/init >>>>> . . . >>>>>=20 >>>>> (I'll stop with that.) >>>>>=20 >>>>> So I end up with a 1400042 kernel and a 1400043 world in order to >>>>> boot. >>>>>=20 >>>>> The e.MMC has only: >>>>>=20 >>>>> # ls -FTld * >>>>> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT >>>>> drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ >>>>> drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ >>>>> drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ >>>>>=20 >>>>> where the etc/ has only: >>>>>=20 >>>>> # find etc/ -print >>>>> etc/ >>>>> etc/hostid >>>>>=20 >>>>> World comes from the USB3 SSD that is attached but the kernel >>>>> comes from the e.MMC instead. (The kernel can deal with the >>>>> USB3 SSD just fine, unlike the U-Boot that is involved.) >>>>>=20 >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> marklmi at yahoo.com >>>>> ( dsl-only.net went >>>>> away in early 2018-Mar) >>>>>=20 >>>>>=20 >>>>=20 >>>> Could you try reverting >>>> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >>>> capability check" and let me know ? >>>=20 >>> I'm in the middle of something on the systems so it may be a while >>> before I do that. (I think it will be my first individual revert >>> of some specific old change via the git context. Hmm.) >>>=20 >>> Also, I do not know enough to tell the difference between: >>>=20 >>> that test being wrong >>> vs. >>> mishandling of the combination (presuming it is supposed to be = valid) >>>=20 >>> So I may end up just reporting if it reverts to the old settings >>> being in use vs. not. >>>=20 >>> But . . . >>>=20 >>> I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on >>> it that is on the same type of e.MMC device and the e.MMC is used >>> to boot. That old NetBSD reports for the ODroid C2 during booting: >>>=20 >>> [ 1.8295810] ld1 at sdmmc1: = <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x000> >>> [ 1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 = bytes/sect x 244277248 sectors >>> [ 1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz >>>=20 >>> So it appears that some form of HS200 is a possibility as far >>> as the e.MMC device is concerned. (I make no claims about related >>> Rock64 vs. ODroid hardware capability differences --or FreeBSD's >>> intent for the Rock64 in this area.) >>>=20 >>=20 >> So, I tried NetBSD 9.2_STABLE on the Rock64 with a e.MMC as the >> boot media: it does not use HS200 mode (so it uses 52 MHz, not >> 100 MHz). >>=20 >> [ 1.8672737] ld1 at sdmmc1: = <0x15:0x0100:DJNB4R:0x00:0x9f43b223:0x000> >> [ 1.8773160] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 = bytes/sect x 244277248 sectors >> [ 1.8773160] ld1: 8-bit width, 64 MB cache, 52.000 MHz >>=20 >> Not that I know any details about why, but it does suggest that >> the issue may be Rock64 specific, given what NetBSD 9.2_STABLE >> does with HS200 on the ODroid C2 . (I updated the C2's NetBSD >> vintage to match the Rock64 experiment so comparison/contrast >> results would be more reasonable.) >=20 > I don't think de9c000cedfe has anything to do with it as it only > modifies the Freescale sdhci driver. > The Rock64 MMC controller doesn't use that code. >=20 > In 8661e085fb95 I fixed the HS200/HS400 capability detection primarily > for DT based controllers. > Rock64 controller declares HS200 support with "mmc-hs200-1_8v;" > property in the eMMC node in rk3328-rock64.dts. > I guess that since it doesn't work the quickest WA for this would be > to add SDHCI_QUIRK_BROKEN_MMC_HS200 to sc->quirks in sdhci_fdt.c. Well, I've tried Armbian 21.08 (Linux 5.10.60-rockchip64) and its first boot reports the sequence ended up using HS200 at 150 MHz: # dmesg | grep mmc [ 3.195642] vcc18_emmc: supplied by vcc_io [ 3.227180] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit = address mode. [ 3.227187] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit = address mode. [ 3.227225] dwmmc_rockchip ff520000.mmc: Using internal DMA = controller. [ 3.227234] dwmmc_rockchip ff500000.mmc: Using internal DMA = controller. [ 3.227244] dwmmc_rockchip ff520000.mmc: Version ID is 270a [ 3.227259] dwmmc_rockchip ff500000.mmc: Version ID is 270a [ 3.227342] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq = 42,32 bit host data width,256 deep fifo [ 3.227390] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq = 41,32 bit host data width,256 deep fifo [ 3.229762] mmc_host mmc0: card is non-removable. [ 3.241627] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot req = 400000Hz, actual 400000HZ div =3D 0) [ 3.241860] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot req = 400000Hz, actual 400000HZ div =3D 0) Note the below 3 lines: [ 3.327640] mmc_host mmc0: Bus speed (slot 0) =3D 150000000Hz (slot = req 150000000Hz, actual 150000000HZ div =3D 0) [ 3.730166] dwmmc_rockchip ff520000.mmc: Successfully tuned phase to = 245 [ 3.730397] mmc0: new HS200 MMC card at address 0001 Note the "tuned phase to 245" as part of that. [ 3.732538] mmcblk0: mmc0:0001 DJNB4R 116 GiB=20 [ 3.733510] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB [ 3.734513] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB [ 3.734917] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB, = chardev (243:0) [ 3.746005] mmcblk0: p1 [ 4.880861] EXT4-fs (mmcblk0p1): mounted filesystem with writeback = data mode. Opts: (null) [ 6.686795] EXT4-fs (mmcblk0p1): re-mounted. Opts: = commit=3D600,errors=3Dremount-ro [ 12.767622] EXT4-fs (mmcblk0p1): resizing filesystem from 479232 to = 30224384 blocks [ 22.791358] EXT4-fs (mmcblk0p1): resized to 16252928 blocks [ 31.531320] EXT4-fs (mmcblk0p1): resized filesystem to 30224384 So, as far as I can tell, if FreeBSD wants to support HS200 at 150 MHz on the Rock64, it can be done, voltage changing and tuning apparently involved. That is not to say that any FreeBSD developer wants to be supporting = such. Sticking to 52 MHz and possibly 3V for the Rock 64 eMMC use would again make things operational. I'll note that Armbian's U-Boot reports itself as: U-Boot 2020.10-armbian (Aug 08 2021 - 18:02:43 +0200) I'll also note that rebooting swapped which was mmc0 vs. mmc1: # dmesg | grep mmc [ 3.198267] vcc18_emmc: supplied by vcc_io [ 3.229498] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit = address mode. [ 3.229547] dwmmc_rockchip ff500000.mmc: Using internal DMA = controller. [ 3.229566] dwmmc_rockchip ff500000.mmc: Version ID is 270a [ 3.229665] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq = 41,32 bit host data width,256 deep fifo [ 3.229762] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit = address mode. [ 3.229799] dwmmc_rockchip ff520000.mmc: Using internal DMA = controller. [ 3.229817] dwmmc_rockchip ff520000.mmc: Version ID is 270a [ 3.229896] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq = 42,32 bit host data width,256 deep fifo [ 3.231547] mmc_host mmc1: card is non-removable. [ 3.243883] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot req = 400000Hz, actual 400000HZ div =3D 0) [ 3.244767] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot req = 400000Hz, actual 400000HZ div =3D 0) [ 3.327505] mmc_host mmc1: Bus speed (slot 0) =3D 150000000Hz (slot = req 150000000Hz, actual 150000000HZ div =3D 0) [ 3.834347] dwmmc_rockchip ff520000.mmc: Successfully tuned phase to = 251 [ 3.834477] mmc1: new HS200 MMC card at address 0001 [ 3.836188] mmcblk1: mmc1:0001 DJNB4R 116 GiB=20 [ 3.837140] mmcblk1boot0: mmc1:0001 DJNB4R partition 1 4.00 MiB [ 3.838155] mmcblk1boot1: mmc1:0001 DJNB4R partition 2 4.00 MiB [ 3.838599] mmcblk1rpmb: mmc1:0001 DJNB4R partition 3 4.00 MiB, = chardev (243:0) [ 3.841290] mmcblk1: p1 [ 4.876902] EXT4-fs (mmcblk1p1): mounted filesystem with writeback = data mode. Opts: (null) [ 6.614516] EXT4-fs (mmcblk1p1): re-mounted. Opts: = commit=3D600,errors=3Dremount-ro =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Dec 10 09:51:12 2021 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 D3C1318CBB9D for ; Fri, 10 Dec 2021 09:51:24 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 4J9R4X5P9Rz4mfx for ; Fri, 10 Dec 2021 09:51:24 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: by mail-ed1-x533.google.com with SMTP id x10so10808507edd.5 for ; Fri, 10 Dec 2021 01:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hT6ffrbFdy90A75RHqw+f4Lg3/Ldo+jD1nJPMmpVVDQ=; b=1Yo0Cx7ORATiFXtPXEojtHodIEYG8uUBkvQ+wMogcZWPQPTFaFLhtKJvsi6C96p9An SZlvbz+oYW2zQXuyI35USxswsrKcD7krT1ZnFaxWpoE11+2+Vee8zlORpeN5kmhexCLq 0ouTS/DVDLNJMJiZt87nE3w5Cslq20MzLFZ3Q+DVk42gTsR/rZAkvgkWioKbSKTVg/Ij 2yt3Pqv51dUX2GhJy3x9zCJaBvOLLd03YptqTX907A/Mhi9bsb71Uch6pC//F1JVQ+sZ rW0hjPeEyYnvfVT+kmRdOgZJZ1+ZpDGUgWMzMV/YJG1mj59le9qQ1rTH/5I0wKpZOxPJ VsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hT6ffrbFdy90A75RHqw+f4Lg3/Ldo+jD1nJPMmpVVDQ=; b=O9u43/OjZKXKV/fDlu2dozt22xzucZWSHi8Yg3qyzxXKPMsss6paoU4nX+hjTOryuD IwgACjyD2lKJengpd+AUHHEudXU5c1JtVeAwvcwiCOfT3uASMKXhgtTZf1IPN4shjl4h xuVzJOlAEEvXsWZAkQfnubUIn8U93dpBinXdbYXmIUpH0blUS0xTRqnMrM6KSb38YZwl 3grB9uDXUZH4COFJcCj4Vd5eHqBzxVnKaUT/JxMEzAP0OAaOzNP2YFB5VpMjgcZs7w9e Cc2PV+9gOwsPBwG9pA5dMRm8p7LN3bMAalFMUrHX7TE5ydCgVeR+nneQsn+7x/22e/0T HaHg== X-Gm-Message-State: AOAM530tO1RbNOzYnmql4k4QdQSBzjpW4lVvRh6hfErxT0/7aUYxK/zD EaE3R4JP6tiF/0CH/97GiLxuNfv2xeJXGEfPaGf4NznGI9EbxQ== X-Google-Smtp-Source: ABdhPJz57S7L0apO0Vz8qCBqFNeEKKv4Go7ld6Xo6LpK2L+PZgaWe0kUOFXP73AKGu15FFmVG2NmTxy1LJf2XD6rIQM= X-Received: by 2002:aa7:dc07:: with SMTP id b7mr36361147edu.327.1639129883570; Fri, 10 Dec 2021 01:51:23 -0800 (PST) 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: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> In-Reply-To: <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> From: =?UTF-8?Q?Kornel_Dul=C4=99ba?= Date: Fri, 10 Dec 2021 10:51:12 +0100 Message-ID: Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? To: Mark Millard Cc: Emmanuel Vadot , Peter Jeremy , Free BSD , "wma@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J9R4X5P9Rz4mfx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 15814 Lines: 395 On Thu, Dec 9, 2021 at 11:54 PM Mark Millard wrote: > > On 2021-Dec-9, at 08:01, Kornel Dul=C4=99ba wrote: > > > Hi, > > > > On Thu, Dec 9, 2021 at 2:04 PM Mark Millard via freebsd-arm > > wrote: > >> > >> Hello again. > >> > >> On 2021-Dec-9, at 00:43, Mark Millard wrote: > >> > >>> On 2021-Dec-8, at 23:19, Emmanuel Vadot wrote= : > >>> > >>>> Hi Mark, > >>> > >>> Hello. > >>> > >>>> On Wed, 8 Dec 2021 20:36:20 -0800 > >>>> Mark Millard via freebsd-current wrote= : > >>>> > >>>>> [ Note: wma@FreeBSD.org is only a guess, based on: > >>>>> https://lists.freebsd.org/archives/dev-commits-src-main/2021-Decemb= er/001931.html ] > >>>>> > >>>>> Attempting to update to: > >>>>> > >>>>> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 > >>>>> > >>>>> resulted in boot failure (showing some boot -v output): > >>>>> > >>>>> . . . > >>>>> mmc0: Probing bus > >>>>> . . . > >>>>> mmc0: SD probe: failed > >>>>> mmc0: MMC probe: OK (OCR: 0x40ff8080) > >>>>> mmc0: Current OCR: 0x00ff8080 > >>>>> mmc0: Probing cards > >>>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > >>>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > >>>>> mmc0: Card at relative address 0x0002 added: > >>>>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > >>>>> mmc0: quirks: 0 > >>>>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > >>>>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks > >>>>> mmc0: setting transfer rate to 150.000MHz (HS200 timing) > >>>>> mmcsd0: taking advantage of TRIM > >>>>> mmcsd0: cache size 65536KB > >>>>> mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block > >>>>> mmcsd0boot0: 4MB partition 1 at mmcsd0 > >>>>> mmcsd0boot1: 4MB partition 2 at mmcsd0 > >>>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 > >>>>> . . . > >>>>> Release APs...done > >>>>> regulator: shutting down unused regulators > >>>>> GEOM: new disk mmcsd0 > >>>>> regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 > >>>>> busy > >>>>> GEOM: new disk mmcsd0boot1 > >>>>> Trying to mount root from ufs:/dev/gpt/Rock64root []... > >>>>> Unresolved linked clock found: hdmi_phy > >>>>> Unresolved linked clock found: usb480m_phy > >>>>> mmcsd0: Error indicated: 4 Failed > >>>>> > >>>>> Note the the above line. It seems to be unique to > >>>>> the failure. Continuing the output . . . > >>>>> > >>>>> uhub2: 1 port with 1 removable, self powered > >>>>> uhub1: 2 ports with 2 removable, self powered > >>>>> uhub0: 1 port with 1 removable, self powered > >>>>> uhub3: 1 port with 1 removable, self powered > >>>>> ugen4.2: at usbus4 > >>>>> umass0 on uhub1 > >>>>> umass0: on usbus4 > >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > >>>>> umass0:0:0: Attached to scbus0 > >>>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>>>> pass0: Fixed Direct Access SPC-4 SCSI dev= ice > >>>>> pass0: Serial Number REPLACED > >>>>> pass0: 400.000MB/s transfers > >>>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>>>> da0: Fixed Direct Access SPC-4 SCSI devic= e > >>>>> da0: Serial Number REPLACED > >>>>> da0: 400.000MB/s transfers > >>>>> da0: 953869MB (1953525168 512 byte sectors) > >>>>> da0: quirks=3D0x2 > >>>>> da0: Delete methods: > >>>>> > >>>>> Nothing more after that. > >>>>> > >>>>> An older kernel (1400042) that happened to be available boots > >>>>> the same configuration when used instead (same world) . . . > >>>>> > >>>>> main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: > >>>>> > >>>>> mmc0: Probing bus > >>>>> . . . > >>>>> mmc0: SD probe: failed > >>>>> mmc0: MMC probe: OK (OCR: 0x40ff8080) > >>>>> mmc0: Current OCR: 0x00ff8080 > >>>>> mmc0: Probing cards > >>>>> mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > >>>>> mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > >>>>> mmc0: Card at relative address 0x0002 added: > >>>>> mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > >>>>> mmc0: quirks: 0 > >>>>> mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > >>>>> mmc0: memory: 244277248 blocks, erase sector 1024 blocks > >>>>> mmc0: setting transfer rate to 52.000MHz (high speed timing) > >>>>> > >>>>> Note the lack of trying "150.000MHz (HS200 timing)". Continuing > >>>>> the output . . . > >>>>> > >>>>> mmc0: setting bus width to 8 bits high speed timing > >>>>> mmcsd0: taking advantage of TRIM > >>>>> mmcsd0: cache size 65536KB > >>>>> mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block > >>>>> mmcsd0boot0: 4MB partition 1 at mmcsd0 > >>>>> mmcsd0boot1: 4MB partition 2 at mmcsd0 > >>>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0 > >>>>> > >>>>> Note: The media is actually an e.MMC . Continuing the output . . . > >>>>> > >>>>> . . . > >>>>> Release APs...done > >>>>> regulator: shutting down unused regulators > >>>>> GEOM: new disk mmcsd0 > >>>>> regulator: shutting down vcc_sd... Trying to mount root from ufs:/d= ev/gpt/Rock64root []... > >>>>> GEOM: new disk mmcsd0boot0 > >>>>> busy > >>>>> GEOM: new disk mmcsd0boot1 > >>>>> Unresolved linked clock found: hdmi_phy > >>>>> Unresolved linked clock found: usb480m_phy > >>>>> Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM > >>>>> uhub1: 1 port with 1 removable, self powered > >>>>> uhub0: 2 ports with 2 removable, self powered > >>>>> uhub3: 1 port with 1 removable, self powered > >>>>> uhub2: 1 port with 1 removable, self powered > >>>>> ugen4.2: at usbus4 > >>>>> umass0 on uhub0 > >>>>> umass0: on usbus4 > >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > >>>>> umass0:0:0: Attached to scbus0 > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> Root mount waiting for: CAM > >>>>> GEOM: new disk da0 > >>>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>>>> pass0: Fixed Direct Access SPC-4 SCSI dev= ice > >>>>> pass0: Serial Number REPLACED > >>>>> pass0: 400.000MB/s transfers > >>>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>>>> da0: Fixed Direct Access SPC-4 SCSI devic= e > >>>>> da0: Serial Number REPLACED > >>>>> da0: 400.000MB/s transfers > >>>>> da0: 953869MB (1953525168 512 byte sectors) > >>>>> da0: quirks=3D0x2 > >>>>> da0: Delete methods: > >>>>> random: unblocking device. > >>>>> Warning: bad time from time-of-day clock, system time will not be s= et accurately > >>>>> Dual Console: Serial Primary, Video Secondary > >>>>> start_init: trying /sbin/init > >>>>> . . . > >>>>> > >>>>> (I'll stop with that.) > >>>>> > >>>>> So I end up with a 1400042 kernel and a 1400043 world in order to > >>>>> boot. > >>>>> > >>>>> The e.MMC has only: > >>>>> > >>>>> # ls -FTld * > >>>>> -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > >>>>> drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ > >>>>> drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ > >>>>> drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ > >>>>> > >>>>> where the etc/ has only: > >>>>> > >>>>> # find etc/ -print > >>>>> etc/ > >>>>> etc/hostid > >>>>> > >>>>> World comes from the USB3 SSD that is attached but the kernel > >>>>> comes from the e.MMC instead. (The kernel can deal with the > >>>>> USB3 SSD just fine, unlike the U-Boot that is involved.) > >>>>> > >>>>> =3D=3D=3D > >>>>> Mark Millard > >>>>> marklmi at yahoo.com > >>>>> ( dsl-only.net went > >>>>> away in early 2018-Mar) > >>>>> > >>>>> > >>>> > >>>> Could you try reverting > >>>> 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 > >>>> capability check" and let me know ? > >>> > >>> I'm in the middle of something on the systems so it may be a while > >>> before I do that. (I think it will be my first individual revert > >>> of some specific old change via the git context. Hmm.) > >>> > >>> Also, I do not know enough to tell the difference between: > >>> > >>> that test being wrong > >>> vs. > >>> mishandling of the combination (presuming it is supposed to be valid) > >>> > >>> So I may end up just reporting if it reverts to the old settings > >>> being in use vs. not. > >>> > >>> But . . . > >>> > >>> I've an old Odroid C2 with an old NetBSD 9.0_STABLE (GENERIC64) on > >>> it that is on the same type of e.MMC device and the e.MMC is used > >>> to boot. That old NetBSD reports for the ODroid C2 during booting: > >>> > >>> [ 1.8295810] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0xddebe217:0x0= 00> > >>> [ 1.8295810] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/se= ct x 244277248 sectors > >>> [ 1.8439125] ld1: 8-bit width, HS200, 64 MB cache, 100.000 MHz > >>> > >>> So it appears that some form of HS200 is a possibility as far > >>> as the e.MMC device is concerned. (I make no claims about related > >>> Rock64 vs. ODroid hardware capability differences --or FreeBSD's > >>> intent for the Rock64 in this area.) > >>> > >> > >> So, I tried NetBSD 9.2_STABLE on the Rock64 with a e.MMC as the > >> boot media: it does not use HS200 mode (so it uses 52 MHz, not > >> 100 MHz). > >> > >> [ 1.8672737] ld1 at sdmmc1: <0x15:0x0100:DJNB4R:0x00:0x9f43b223:0x00= 0> > >> [ 1.8773160] ld1: 116 GB, 15205 cyl, 255 head, 63 sec, 512 bytes/sec= t x 244277248 sectors > >> [ 1.8773160] ld1: 8-bit width, 64 MB cache, 52.000 MHz > >> > >> Not that I know any details about why, but it does suggest that > >> the issue may be Rock64 specific, given what NetBSD 9.2_STABLE > >> does with HS200 on the ODroid C2 . (I updated the C2's NetBSD > >> vintage to match the Rock64 experiment so comparison/contrast > >> results would be more reasonable.) > > > > I don't think de9c000cedfe has anything to do with it as it only > > modifies the Freescale sdhci driver. > > The Rock64 MMC controller doesn't use that code. > > > > In 8661e085fb95 I fixed the HS200/HS400 capability detection primarily > > for DT based controllers. > > Rock64 controller declares HS200 support with "mmc-hs200-1_8v;" > > property in the eMMC node in rk3328-rock64.dts. > > I guess that since it doesn't work the quickest WA for this would be > > to add SDHCI_QUIRK_BROKEN_MMC_HS200 to sc->quirks in sdhci_fdt.c. > > Well, I've tried Armbian 21.08 (Linux 5.10.60-rockchip64) and its first > boot reports the sequence ended up using HS200 at 150 MHz: > > # dmesg | grep mmc > [ 3.195642] vcc18_emmc: supplied by vcc_io > [ 3.227180] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit address= mode. > [ 3.227187] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit address= mode. > [ 3.227225] dwmmc_rockchip ff520000.mmc: Using internal DMA controller= . > [ 3.227234] dwmmc_rockchip ff500000.mmc: Using internal DMA controller= . > [ 3.227244] dwmmc_rockchip ff520000.mmc: Version ID is 270a > [ 3.227259] dwmmc_rockchip ff500000.mmc: Version ID is 270a > [ 3.227342] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq 42,3= 2 bit host data width,256 deep fifo > [ 3.227390] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq 41,3= 2 bit host data width,256 deep fifo > [ 3.229762] mmc_host mmc0: card is non-removable. > [ 3.241627] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot req 4= 00000Hz, actual 400000HZ div =3D 0) > [ 3.241860] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot req 4= 00000Hz, actual 400000HZ div =3D 0) > > Note the below 3 lines: > > [ 3.327640] mmc_host mmc0: Bus speed (slot 0) =3D 150000000Hz (slot re= q 150000000Hz, actual 150000000HZ div =3D 0) > [ 3.730166] dwmmc_rockchip ff520000.mmc: Successfully tuned phase to 2= 45 > [ 3.730397] mmc0: new HS200 MMC card at address 0001 > > Note the "tuned phase to 245" as part of that. Yep, it looks like in Linux they're doing some custom tuning logic specific to this controller. FreeBSD only executes generic tuning code, which apparently is not enough. > > [ 3.732538] mmcblk0: mmc0:0001 DJNB4R 116 GiB > [ 3.733510] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB > [ 3.734513] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB > [ 3.734917] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB, charde= v (243:0) > [ 3.746005] mmcblk0: p1 > [ 4.880861] EXT4-fs (mmcblk0p1): mounted filesystem with writeback dat= a mode. Opts: (null) > [ 6.686795] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=3D600,errors= =3Dremount-ro > [ 12.767622] EXT4-fs (mmcblk0p1): resizing filesystem from 479232 to 30= 224384 blocks > [ 22.791358] EXT4-fs (mmcblk0p1): resized to 16252928 blocks > [ 31.531320] EXT4-fs (mmcblk0p1): resized filesystem to 30224384 > > So, as far as I can tell, if FreeBSD wants to support HS200 at 150 MHz > on the Rock64, it can be done, voltage changing and tuning apparently > involved. > > That is not to say that any FreeBSD developer wants to be supporting such= . > Sticking to 52 MHz and possibly 3V for the Rock 64 eMMC use would again > make things operational. Yes, imho marking HS200 in this controller as broken is the right choice, unless someone(TM) writes the missing code. > > I'll note that Armbian's U-Boot reports itself as: > > U-Boot 2020.10-armbian (Aug 08 2021 - 18:02:43 +0200) > > I'll also note that rebooting swapped which was mmc0 vs. mmc1: > > # dmesg | grep mmc > [ 3.198267] vcc18_emmc: supplied by vcc_io > [ 3.229498] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit address= mode. > [ 3.229547] dwmmc_rockchip ff500000.mmc: Using internal DMA controller= . > [ 3.229566] dwmmc_rockchip ff500000.mmc: Version ID is 270a > [ 3.229665] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq 41,3= 2 bit host data width,256 deep fifo > [ 3.229762] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit address= mode. > [ 3.229799] dwmmc_rockchip ff520000.mmc: Using internal DMA controller= . > [ 3.229817] dwmmc_rockchip ff520000.mmc: Version ID is 270a > [ 3.229896] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq 42,3= 2 bit host data width,256 deep fifo > [ 3.231547] mmc_host mmc1: card is non-removable. > [ 3.243883] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot req 4= 00000Hz, actual 400000HZ div =3D 0) > [ 3.244767] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot req 4= 00000Hz, actual 400000HZ div =3D 0) > [ 3.327505] mmc_host mmc1: Bus speed (slot 0) =3D 150000000Hz (slot re= q 150000000Hz, actual 150000000HZ div =3D 0) > [ 3.834347] dwmmc_rockchip ff520000.mmc: Successfully tuned phase to 2= 51 > [ 3.834477] mmc1: new HS200 MMC card at address 0001 > [ 3.836188] mmcblk1: mmc1:0001 DJNB4R 116 GiB > [ 3.837140] mmcblk1boot0: mmc1:0001 DJNB4R partition 1 4.00 MiB > [ 3.838155] mmcblk1boot1: mmc1:0001 DJNB4R partition 2 4.00 MiB > [ 3.838599] mmcblk1rpmb: mmc1:0001 DJNB4R partition 3 4.00 MiB, charde= v (243:0) > [ 3.841290] mmcblk1: p1 > [ 4.876902] EXT4-fs (mmcblk1p1): mounted filesystem with writeback dat= a mode. Opts: (null) > [ 6.614516] EXT4-fs (mmcblk1p1): re-mounted. Opts: commit=3D600,errors= =3Dremount-ro > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > From nobody Fri Dec 10 10:35:58 2021 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 B5DD718D5653 for ; Fri, 10 Dec 2021 10:36:01 +0000 (UTC) (envelope-from avg@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 4J9S4105Wfz4vVB; Fri, 10 Dec 2021 10:36:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 04BE1223B9; Fri, 10 Dec 2021 10:35:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <5aea5440-2191-dd65-c2f1-2b4e1750e088@FreeBSD.org> Date: Fri, 10 Dec 2021 12:35:58 +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:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.0 Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Content-Language: en-US To: =?UTF-8?Q?Kornel_Dul=c4=99ba?= , Mark Millard Cc: Emmanuel Vadot , Peter Jeremy , Free BSD , "wma@freebsd.org" References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639132561; 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=udhAb44CLuOH9zvbznAwYoma2FEG67AvvNF3TYK71Xk=; b=goUQTCrLLLLj7ETzPgNhRA9PGk27VMio43s/kNhh/20UIDDRes5S25qNmbcA7FPtY/UfT8 DWl72dNW8aa33p4dvgKLyGGJWT+QG6KLadbHCjBPAoIcQ4TJ0L3VVb2UXa0JqAtsWiTNUw I4GTYdspqYvKRF7KJL+dcmpkyNqO9WotacDx6MmKHeLNVt3vWk84+DJQJyjcsFQs5qbeEY TdyjVNd1CmuTCAZT3KLK6qvN5nsVSk2zidH/Zx+CHkE1nQluAWh6NREmbfzNZw9d9PsNZ0 SDdXE3TpD/NBVNX3r76Z2atLR1Q3UghkuqflBgGt6Rvx8m65jCyAeVu0o7lxVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639132561; a=rsa-sha256; cv=none; b=xJhDtkS1xsdTvBjNNd/vKYx3hKagkO7UEFWPvMkAtdtZ7jBm7mixlK+i6Neu/j8gWazGEg OZxmM3B0OjknVQabdbUdV5DTvfUfaz5yzo5UdkW26Pnu2aSp+slnGDx+A9lZqTn3BHBo5M SGUBYQUJAbqKK2Q69p1C+J0aVbaqdZyUW8kkwOEyMYGzwX5wA7JF7CQmEQXvHJ/J+MNd5M zvF3QTOGwpDIxyBOTWPmX/IYceb46IufSQVaamrdBj7a6AmC3SmdRoHR+yciBYmzLVAHdk IJV71Ccp1H/gTtlN58S2rx6dZ/YHN88o+ZTzKCVIX9BROA5fGHdOchmr6kTTSQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 436 Lines: 13 On 10/12/2021 11:51, Kornel Dulęba wrote: > On Thu, Dec 9, 2021 at 11:54 PM Mark Millard wrote: >> Note the "tuned phase to 245" as part of that. > Yep, it looks like in Linux they're doing some custom tuning logic > specific to this controller. > FreeBSD only executes generic tuning code, which apparently is not enough. > AFAICS, we do not have any support for setting clock phases at all. -- Andriy Gapon From nobody Fri Dec 10 11:46:39 2021 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 2454018E5639 for ; Fri, 10 Dec 2021 11:46:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9Tdl3fNfz3j3C for ; Fri, 10 Dec 2021 11:46:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639136804; bh=gNcVXAQy+mrNK+XHMQQeVxsbmKHlFuRfvELnLzonMAE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X3tk4jUExLAIX1XF/gSizxeQMlqKjqWoTl7HMvRxG+MU5RYT0/4bFwBErD6+qVRcBiqOU61JFPKehjPoIfHQWo2rz4wkVjp6pd9O/KI9aUoEQoq4pB65eEZxQiN4oJdZ91C24ibS/o9C+XzUt3cewCXkfRkAlAEPlVNqXJEKPDzdOJLWtCn+wnQ/aIMfCz0cEi7TqZjqrQng2DNho36ag4/bSUVbnnp3MgJ1kqhiHC25phRb2j9B0m6Kt6urAtpYwftgB8WQilmWQ0eiJ2goSBRO8XM47hmyMEIR76Byo9iV/9m/csK/B6iwjBY+1ZHR1UZuJARo1MXH8mSnE4XouQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639136804; bh=c23LjZI8qP9jx0QLOjkbwBzOAPYbi0352COAgafRLYA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tj7nrwRCdES06S+VdAA3g/EHm3IBHfcPA6xdeSUE0RqoLFjMPY8GkPbNKO8Nae0+qVMB9Er/iXWHwhkBynCsMEAfvPaDUEVaxHAas8oyBQf/maNe4Sg2mHbH+cckppduZ+7FUj9/CxHHkc/gtDXP/956Dc/5D11BYYxvg56W1KCyTTfksXt+09OvyJtImIXVf4Y4qN/RCMWDOpGUpaueotUpSwXDAzR5i0HosL4IxbiBy7s9Mxq4aRcKP8ecE1Kb96hP1YhQPv6L6DeOayumYhBnj4nbue4DtHWor32iysPatOrk3+idCEDFX7RZ4qHipJeY+Yg/ijypHzC+tE/v2A== X-YMail-OSG: BRsrDIUVM1kciS5abLWq8NmbHFn8INCNhdLkA7FNu5dfjwL6bNQgvwEmUoLjOO9 AwxJV2ShyS5XfH7qFTVB9vAczmvVqpNfUqRDB4ZtZvBU2LSWJzg08bOymZahwpt2Z1Zg18MqPG4H NQLmvkgLyQS4PTtiFnq5ZfDe2eypIdwH18alWpWmFBRiCUP09J7wOJYfCUo9rMGH6om7Vyh9znJ2 WM9vSPAA0BIDuFsPD.3xPndvZxHwy.loZrLCdpPs5eveh.GymTD.1uJuEneYVB638_BoGdW2i90c _sSWo1pNRCVsT3A7tR9tbjX0M8269g8zIAhr33T1LRYHAkeUrXmiQsXW3u7mXwNpDX5bny70TjEH Y2f2wQS1Vw6vDI2fKYFypJljOU49cy04MBYGhdLMgDMvpB_N5h9wSkHlhII0Ci7Wxb4MVMmLw7gJ i.ntgK_HVCJeM.DnhCKoYoPNK2oGvy3tRT8r1SVfXXIjyAG5e_gfEaPHtATyiS97gYCKf3JEcpfQ QWt.Qz4NAj9Yv4E0sELRlh._ekReCVXzzxi24hEsOFVtJ8sXoMru6ohEu6YgsWRHto.ofcel.ShU agQXA7W4Ji6LHqmvC4BP7ozsfSLoPhotVeqwUBvZz71rMwSJzMqATRoVpZ0PM0onPpbVbnijJzXE rArTFO.ZjaAbBRzeamLaFoh5UWF9I9EhdsV_B2RYVn54UxaV.jd2ke3Ysu633A1J3y0sZla2Ey0w aRv.A6cVCMYMlxfrW._qBzO2yIr7slVJw7cZmLmyzzicDcZSOBL8i74IXXIhmJ23zKOz9isFk27l DyyWxwG5cbTlU.IYc.1d_PbnaVp1Mq2d5rq7FGaAET6Y2BVq1qdrQY1PHje3G8i3G0kjBwCUizY3 iTP_c8Qei9rJGhE8uq6hk.QK5_sg4aKvGD6uNnw.vWIvb1SPaVflooAS1MeFcJwepSl1eOhGDFpP 96XNbOh.kbQjzSGTBhj9nY_uPdfwYLB.PfakvWZGBqJpqhp_2uiXmBUahm7eAmPLTmhBXyPpAdTa AMiMrldp_8RNr6HpkG9FCZmOz0SdR0hG.pkYzzD0xpkEAx07tXQv3Ad012YcFRcqhUeyInGMXIhN plzCOM9t1c_vwC.Qcw0vyf_WsfCL3TRr_tT8WKbe1fH_ZQi_vEN7UeuDwV0QQ3p0vLVQcxeMJ7ic BmXRU8niDKsxu.xEam9zPJjXO5mbexOEw2np45SCSTFutgU2aYYPAhTgFlmIB2n5ZeoEzeQKCL8a zs9tN5qzkVDnXUX.Ngad.2mCVg7EDiofdhBWZ9_01sWj4KUD7GW4ztu_53zA.wnP5d1vzcYSqdt. ljPwxf7Av2LCYKExOEMj6K_PPTYWZPxnDeID4vaRRO6OINcIX8xv2lrsI6.h0cesBitWSEColbtc ya5CY9loPheEh8qpWDXY9bbdMWGg.jCEPqItEAcz85EAbn8qtzCL0dKT3euRgfbcwb2F6kNAD.2M I.kvssYxkIzSci2jfETC6wydH7aRitnfk.0NqDAWoxIAUDQCjbprhWENicrZcMRuplWRqEQuzJYL Rl_m6FrFL2jfCWHKfm3hhVKoYvJpgcpC1bsm31xV70O5HPBYFOsJAjn5AuqOx.TmBInA7voBE_YO NCzEoi4HozoSn92rXx5N9yQxHZ3LwRKaTnffxGq4c9oM.Hn2O3wg_u.7_fGtN2K0o5KhUz3A3o1K nesbr415MmhZHIsZdrSIQmC_ewAoXXRHVKPkpgWWQT9SG.6utU4nFRmLMThFsoT4jwNNpUTB8zHJ sbCwnILCQBXXv2xkoBW4iu4DUp4WzA_AHOy7Z66uhF_8KHzZI1dPhviIdi6j_EvgI6MstpFICcX4 Dp4j_ugz8A78BVMhep1Jy0fVbHptQfbuYGpyCJRBrDBOhoitUK.C9tzRQd_XgjlhJqo2mwtGHEOL GUxGrpW6BaLRjf1r3.gZ7DvHLvIxs8bVxh1UwNo99deZsohGNDRPn5olFuGnbwO6Tg.5s4CTeWFj bVGFocTAVvyAIlRw0rQSijXDGHYaeoOFGLeEtfVgUPQW_vlCz4pBXpT60dVqA7c.6K_OZjcKsvXN 3F4OqCvl.aP8xsg0aAIRyY50O80j_ITQSW9ckV5uu1yqowz8iEmmFVKdEGRY_Qw.SFLeuN_N6AIR FWREGvaQzrBOBJlr.D6_tkz1pyCqyyfbSm_uveqFKa_lSkyezPzrli6p0vrsyvG13UqyrkQZJMvY G5WIz9TS0hfq9tr7RSHYUcciV_XKqUKARn1mnbR.w2BLdS2rkfct5LWJEJP3x_fTPnvyFohoH6jh w33bTyNK_LocT3x1SJwAT27M- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Dec 2021 11:46:44 +0000 Received: by kubenode516.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65d08d09aca8dfceb06564a95ffea10b; Fri, 10 Dec 2021 11:46:42 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <5aea5440-2191-dd65-c2f1-2b4e1750e088@FreeBSD.org> Date: Fri, 10 Dec 2021 03:46:39 -0800 Cc: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot , Peter Jeremy , Free BSD , "wma@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0CE1A670-FC3C-49F9-B1A0-9F2C1CCA368A@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <5aea5440-2191-dd65-c2f1-2b4e1750e088@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J9Tdl3fNfz3j3C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1573 Lines: 44 On 2021-Dec-10, at 02:35, Andriy Gapon wrote: > On 10/12/2021 11:51, Kornel Dul=C4=99ba wrote: > > On Thu, Dec 9, 2021 at 11:54 PM Mark Millard = wrote: >>> Note the "tuned phase to 245" as part of that. >> Yep, it looks like in Linux they're doing some custom tuning logic >> specific to this controller. >> FreeBSD only executes generic tuning code, which apparently is not = enough. >=20 >=20 > AFAICS, we do not have any support for setting clock phases at all. >=20 Interesting, if true: =46rom what I've read MMC 4.5 added CMD21 (SEND_TUNING_BLOCK) for this tuning operation when it added HS200. CMD21 is also used in MMC 5.0 for its HS400 addition, from what I've read. As I understand it, tuning via CMD21 is expected to be required for HS200 mode read operations (and HS400?) to be well behaved: the clock vs. data directions of travel are opposite (instead of synchronous) and the specific timing is not mandated but must instead be measured/observed. HS200 does not have a data strobe traveling in the direction of the data. HS400 needs CMD21 use for synchronizing the command responses on the CMD line to the CLK (a temporary use of HS200 mode to do the tuning). (There is also a Drive Strength setting involved for HS200 --and HS400 has possibly one more Drive Strength alternative by count.) In other words, if you are correct, then it seems that FreeBSD simply does not support HS200 or HS400 (in a reliable manor, anyway). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Dec 10 20:59:04 2021 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 E413618CF4CD for ; Fri, 10 Dec 2021 21:00:16 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9jwJ3zllz4m5n for ; Fri, 10 Dec 2021 21:00:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639170009; bh=Fvv2+2AulA67sy7Jgv4xhbBkRisCuWBBtblVf/K3RSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ujmuh+wrXonJZaHfVWcEXRreHZOsr0oGmfHwH2qZkJxXhKjErX72gqjngKXyuQGvURPm/QGSJ8ucacSqvqPErZUN5/VMLpKZvht3iL8TvQ5JuPgvBEALjXj5V5t83/IAH//fZ7MmuxcQC7CoSftnVs4XqzevQZfdf16TTekwDjNEZa5s4F+9LMPnt9AXZ1sYfpjfVzclGQ5/EhBN03TCtpUnpduF/TlyJsH281zW9kqzyCLmAyNbdWlJrp0IFNqvH5+/jF8AGNLHwsiFzn9HFlpsep3TFH5nKH8baXb9dGajpUMqo5ryClJ/KUy6ib89nilwYZb20VIp6PajFh89Rg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639170009; bh=gE5uetAxIytZDemk/C4mDex5NuKEWWrBFbKKUAJY6lf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ofTPsQ86uyOOgZipKZz3BEe3xDV6aWF3oLxD8lPnGlH7hrj88EI71KOGhpogzRHZon6o55Z20Fd16NUyhZQ5WlMxMoKU4oCE2rIrtTCUlQwQSYi+J04bTIl7/FNKobQoXh/++X6yvVgOWeP5dEtKqgrsjAnHNLp/DWapXrQ5xn6AfuFPinpdFUBg9BdpD+8+RZl/9fqw69HJbca8yTH35OoLTX9CBclhq09U54Cl53BErKh0cycDSE+/JsyFY0o+JjWoqtgSZjTUxxx5FNpUlBZQsJuuzftoU8BzqaAfviCzqOQYDV8p8/rq0zAJf3RTkEJudwqJoaPBtz9VoEyPuQ== X-YMail-OSG: _9DvZR8VM1nr.H759uHKao9ZZfFKAYcTDJRz0e2uUo27vHtZUu_L8OoEQWGLsWW fxb6aSJidLSxseh2uOGxtTEKTa4QQbxtqHZjpZMGUPAXFJG2ie0bDIEvcm06smm6aVZHniyA1Tsi 7dW2nnDh8oA4xR491s8apTeG1fayNagrFDaeYGfZqQf_5P8ET5T.Q_OC5NXjKtjiejfL.m1ddBRE Y.sMy7KFcD4JPiVH4KeeFhnHwDSVX6fl0SgXqzzOcOW3gCTarSwtIJ9KHrKjAaXWmur8tQdSth2O hmG1Ks6UOHRIZfKtBm4UrmEbQFo_D0uU4ldugFunMCMDF5DEeUNtToEtdZGZ.EnmJTyJ.7A5I6HV Ht8TgZstWOn1hl0EWW3BkBj38v7kK70AlJfrn2Rsi_bjKFBJ24bw9hKyYdZeib1OupzRqMg6ak67 2r5eN5fXM4k9LF9Yf0oJ19rd62XIscpeDZzXvcBvzs3tLNtRICBvbyoR7LiBycKsBmALDQLP86yu QWZH5MWGW_pkohzHODLJIUt56y32vaiE7gDCDmfMH8ZzLFSgTldMp28Geksx14dFgmr3_j.4kgVK HXt8qRvbiIQIOed2dkjxOKWWHuPFEY698tNVuHwhEXEeTx_3yFt97tcB.hseTk7P6ykxtce7Nz3g H9EDdLSOUlQe_hsAn3oEomBbFDs2HAIpkC0sdgrd_EK_uU5Zb0NIbfi5IcPsxiyMy4GaCrkEOHsh 4aZ02Yi_0b1pW6Z8Do6ZVHNtY6ijbiloTViU4aQXhD.wcREjX8hgWehGUZsn0okSeFL8LY1Ejw5R 8.y2On5Ypt1NiVm8k_6zdWYGzj0jvlropPd42BAUf.jzK7Mg4TF2xK3jWhdOZpubmO2gDQ3hmXLX 7FmYdYFghXdtOPjW_DPOsHcB6egMbxp44nW8iUJTMUEoO3G7yNvk00XnGdzGEZ4cFbjBNtKxAO10 x6KMa728vjQW7EKP4KWZ8QBEx5TVuyBFTwaBUvGGNSBDSN28GmYW62kGBTeqAi8EzUzwokNSdII6 KOiXWEY5oPZwSjKGCzZviETbM1dKXoS1tElcG5eBN_hxM2C5kAR_ZdfxnNHTpvsVjFPIyrTiiqxq Y.QQ3i.T9HEPBe9KdKBRVexRcApVEUmu6pE7fwiyZecX.Mdyff7ym4zquKG6Lb7SKdv9XaV5_k7W pBWFXhbx0K.cV0gaMBhYd1XGtaAWgI6V9UmVGfH7YUPxdPk.Rv5HqzE4zBsVRQdOQdyR0YM0c_9i siHS8W8La1bccXR8EeqicACmgxrNXcmzXlhk7xalnLffLggYq6D3bCmkAu2T48DwbB5RXJv2KV5E QwWwkch0wJKedRomdpodIz8eh9hbnuX53V4IvbAOjrAA4uhNn7bPRhUJv73j5Tdy3hubITkl6.hi RvInsHh5D9EVgHtB0uAOGE39XCKIzbJ2Gcemo9sY3sx4.IFbNMwoPsKP3PeAn7rED65NnEvyRY4L DDe0SiB7VQtaa855DJh2bYeSSMbn2_ck6Zp8iW6lSkwIDjYf1lfN4qbnpkSX8acCOTCWFgXyaDci mBtoRuSIeYrshGaPvqiSlnrAyPO6BwP0OLnHB5qV13gdvcr.JZyF7YODx.ZfzxTTV9FbGFHoAxD_ kOMHf80XUp6zrsgb6m4rn8_iuSDsFjMZNTy.0V66a4yhfQk22VZczBt8Lqf_KkzWJqGPCtzWNoP0 kT3J5RlmxGr.sJtKQ6Q0opYWpMM9hFpNjbcpMyTUXY_6MCe3gGP7FoMEGoIUN0riRD1PAjP..IH1 6.FEdvkjl_p80CqWm2scIwDq2pwQbo189jZa5hynMxkgOWJJfUwLJvdy24SNkWlFfNSlws4.5LBl lPQfZ5rhxoivTbXxqYPuomthYmRI6HsVHubuoe6zq._nThPhK5UOI4U80u.b5VubYAu55zEFS5Yx z8Klk8APUocyClbKHPSv.EaiY0NI8OC7N7c0AS0dXC637ItNjdkH8h76sK.XbDkuTp6q4_LL5vWH LaLw68dJYeuEo3pCWQ8leJAd5GpsAWjvZyUo1xwB16g1N37FE1rEre1Lq6iGvbSCPj9sS8zqa7EW gbW1HLcTgyuRyTP8FxJPM93RTS95kF4pyMzoJj3YdR3zcBVFBzsqOH7ZgkqR6ILYzEtajWMY.ZNx hTx.YiG5t7XkivvWvvyp_8_jFCMRFO2Hn15ZzAShr6ewAhpM47xoL66wqQDIz9H4dH.K1QR7wx49 vAZOluSpDva0uH7lGH1qwh1rcYyoiT2pZuaJxKJH2D5i6P02mVF4m.YgnSc8H1v.L8gzBTFpX47S IoQphcNllrd3n5kM0kg6SVyMXiQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Dec 2021 21:00:09 +0000 Received: by kubenode529.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 272e5b15e8ef8c86b07a2d25ce83737b; Fri, 10 Dec 2021 20:59:10 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: Date: Fri, 10 Dec 2021 12:59:04 -0800 Cc: Emmanuel Vadot , Peter Jeremy , Andriy Gapon , Free BSD , "wma@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J9jwJ3zllz4m5n X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6169 Lines: 156 On 2021-Dec-10, at 01:51, Kornel Dul=C4=99ba = wrote: > On Thu, Dec 9, 2021 at 11:54 PM Mark Millard = wrote: >>=20 . . . [History deleted] . . . >> Well, I've tried Armbian 21.08 (Linux 5.10.60-rockchip64) and its = first >> boot reports the sequence ended up using HS200 at 150 MHz: >>=20 >> # dmesg | grep mmc >> [ 3.195642] vcc18_emmc: supplied by vcc_io >> [ 3.227180] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit = address mode. >> [ 3.227187] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit = address mode. >> [ 3.227225] dwmmc_rockchip ff520000.mmc: Using internal DMA = controller. >> [ 3.227234] dwmmc_rockchip ff500000.mmc: Using internal DMA = controller. >> [ 3.227244] dwmmc_rockchip ff520000.mmc: Version ID is 270a >> [ 3.227259] dwmmc_rockchip ff500000.mmc: Version ID is 270a >> [ 3.227342] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq = 42,32 bit host data width,256 deep fifo >> [ 3.227390] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq = 41,32 bit host data width,256 deep fifo >> [ 3.229762] mmc_host mmc0: card is non-removable. >> [ 3.241627] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot = req 400000Hz, actual 400000HZ div =3D 0) >> [ 3.241860] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot = req 400000Hz, actual 400000HZ div =3D 0) >>=20 >> Note the below 3 lines: >=20 >>=20 >> [ 3.327640] mmc_host mmc0: Bus speed (slot 0) =3D 150000000Hz = (slot req 150000000Hz, actual 150000000HZ div =3D 0) >> [ 3.730166] dwmmc_rockchip ff520000.mmc: Successfully tuned phase = to 245 >> [ 3.730397] mmc0: new HS200 MMC card at address 0001 >>=20 >> Note the "tuned phase to 245" as part of that. >=20 > Yep, it looks like in Linux they're doing some custom tuning logic > specific to this controller. > FreeBSD only executes generic tuning code, which apparently is not = enough. Based on this and some more exchanges with Andriy off list, I went looking in Linux source, something I'd been avoiding. Sure enough: dw_mci_rk3288_execute_tuning explores, looking for the widest range of phase settings that work and picking the middle of the range as the value to leave in place. That code is what generates the "Successfully tuned phase to" notice that Linux was reporting. (There is a default used if all settings work.) The code for doing this uses CMD21 to evaluate the phase settings. If this sort of thing is (sometimes?) normal (to have some context-specific implicit parameter assignment involved for the CMD21 use), I've not yet noticed how FreeBSD allows for getting to device-specific code that establishes the assignment.=20 But, clearly, I'm far from knowledgable about how things work/fit. I've just been reading understand some about the problem. >>=20 >> [ 3.732538] mmcblk0: mmc0:0001 DJNB4R 116 GiB >> [ 3.733510] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB >> [ 3.734513] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB >> [ 3.734917] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB, = chardev (243:0) >> [ 3.746005] mmcblk0: p1 >> [ 4.880861] EXT4-fs (mmcblk0p1): mounted filesystem with writeback = data mode. Opts: (null) >> [ 6.686795] EXT4-fs (mmcblk0p1): re-mounted. Opts: = commit=3D600,errors=3Dremount-ro >> [ 12.767622] EXT4-fs (mmcblk0p1): resizing filesystem from 479232 = to 30224384 blocks >> [ 22.791358] EXT4-fs (mmcblk0p1): resized to 16252928 blocks >> [ 31.531320] EXT4-fs (mmcblk0p1): resized filesystem to 30224384 >>=20 >> So, as far as I can tell, if FreeBSD wants to support HS200 at 150 = MHz >> on the Rock64, it can be done, voltage changing and tuning apparently >> involved. >>=20 >> That is not to say that any FreeBSD developer wants to be supporting = such. >> Sticking to 52 MHz and possibly 3V for the Rock 64 eMMC use would = again >> make things operational. >=20 > Yes, imho marking HS200 in this controller as broken is the right > choice, unless someone(TM) writes the missing code. Seems appropriate to me. >> I'll note that Armbian's U-Boot reports itself as: >>=20 >> U-Boot 2020.10-armbian (Aug 08 2021 - 18:02:43 +0200) >>=20 >> I'll also note that rebooting swapped which was mmc0 vs. mmc1: >>=20 >> # dmesg | grep mmc >> [ 3.198267] vcc18_emmc: supplied by vcc_io >> [ 3.229498] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit = address mode. >> [ 3.229547] dwmmc_rockchip ff500000.mmc: Using internal DMA = controller. >> [ 3.229566] dwmmc_rockchip ff500000.mmc: Version ID is 270a >> [ 3.229665] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq = 41,32 bit host data width,256 deep fifo >> [ 3.229762] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit = address mode. >> [ 3.229799] dwmmc_rockchip ff520000.mmc: Using internal DMA = controller. >> [ 3.229817] dwmmc_rockchip ff520000.mmc: Version ID is 270a >> [ 3.229896] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq = 42,32 bit host data width,256 deep fifo >> [ 3.231547] mmc_host mmc1: card is non-removable. >> [ 3.243883] mmc_host mmc0: Bus speed (slot 0) =3D 400000Hz (slot = req 400000Hz, actual 400000HZ div =3D 0) >> [ 3.244767] mmc_host mmc1: Bus speed (slot 0) =3D 400000Hz (slot = req 400000Hz, actual 400000HZ div =3D 0) >> [ 3.327505] mmc_host mmc1: Bus speed (slot 0) =3D 150000000Hz = (slot req 150000000Hz, actual 150000000HZ div =3D 0) >> [ 3.834347] dwmmc_rockchip ff520000.mmc: Successfully tuned phase = to 251 >> [ 3.834477] mmc1: new HS200 MMC card at address 0001 >> [ 3.836188] mmcblk1: mmc1:0001 DJNB4R 116 GiB >> [ 3.837140] mmcblk1boot0: mmc1:0001 DJNB4R partition 1 4.00 MiB >> [ 3.838155] mmcblk1boot1: mmc1:0001 DJNB4R partition 2 4.00 MiB >> [ 3.838599] mmcblk1rpmb: mmc1:0001 DJNB4R partition 3 4.00 MiB, = chardev (243:0) >> [ 3.841290] mmcblk1: p1 >> [ 4.876902] EXT4-fs (mmcblk1p1): mounted filesystem with writeback = data mode. Opts: (null) >> [ 6.614516] EXT4-fs (mmcblk1p1): re-mounted. Opts: = commit=3D600,errors=3Dremount-ro >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Dec 12 00:19:15 2021 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 CB5E918E722D for ; Sun, 12 Dec 2021 00:19:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBQHk5Dhfz3mTJ for ; Sun, 12 Dec 2021 00:19:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639268363; bh=U1DnYM/xiG2HhiFvAOw9BCkRNJQIsusuQN2nKu73sq8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OjCX1XIlGLEptxe3TR07rPqHxodPdSp8USA6enNMFepRj7//inZtTNjYsJbpyQoxDvIl8nbytm59GKBTprdQAhd/enkQ6Ih6naJg9i9rGrWHXXUPCotV25TiSWT4OERFL9wiqqF80Uc1/hMI37NJRQ8O2E/Iho9jT54CSDodErYT2+dabpvcT07p3s/uyN1D6GZzqCmyOu4zKMR0cGyvWCjaP71HjbqQW1DpEvrf5HBgMvKD2+B/26N3+Z9h9KsLNfNBPKiDcDFLE0j1kBuxYcD8HcN2/QBiOjlsQFgGJeVOOhog+kdA/Qk1y4O2dEwF2f7S+WpOmY7Sk8wo3tyi2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639268363; bh=hLGlkPQxwa0cGzdYnuuESTvKTxDEFFSPlJ5HcfR0sji=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GJpzYr0Hqt/DrwPYPWafVYw1cDBvhuh46jf7EsrlSnbDXowPrnzenTBzTE+m+yidh61QAA/hiPR89I8hPBaUnD8KqoXrp3CnQdfdxBvhCiRFf7ZD6YkyQvh2pniljUvrA4cFWzpowWRjS/kp3bxlMBwO6vf2Wl+9X2KL6bGzzUj40rUrpn2bECluCYfTOb6og7KDzMUPiehNWRpVL18LllOFJ318u269l8iAdcR5qXLIbpc/3yFN53AdSk2zIf065fDKbPZYYmVQI48e5OmHXpVa3D95vwe5/foYIHGi5ZJ2mM8BhacC3fF6xak9VFrb+if0Jo9Jen4pZPnxDkYpPQ== X-YMail-OSG: x82_vnAVM1n4TKYnFL6Q.zijdOu5XlWwmL6RP3PGCW558kc2IaoQHNWepjCVnj_ wRz8FSKH_MAUw5o9uCXRcnzr.iS3NN7D3XJpzvRNmvi4ICJxy9yd6Gb9W8ZfzKnHHBtDDVIKoTVf 1o9jGueaeqHvjqAEZIajoz8I5QSwlZER8A7Ldb_mTburv7.KXj5E.BjMIO2hoHA8HpRCCz6uHy_h F6EBspMrjtZyYo75wCWdD.KxVXF_j9F0E_XWeACNcByfl7L3s3ogvov0WgtrTfZDuyhXOvT.Kb.U 43EOg7vDL0Fdg.j3vfz6HJkbA2ZqjUAdg8WaLobo2JqCe2pn99jw8bFsASoolxx7UWBqDb6TZDYH izC7g_zNnCgY5kQJRhpAdDsihyMui4fXGICNRtKJMuCfjfTGrzVcHoxUTGkU3sJNzDJ1VxXVzDkR JrhoUdyV7ejvx0WJKp7Tu8iRugYFFl3niqpbqMQ1fGH_LF58xrRA9pWnes_YgQY9y_R_I3Y6Nmi_ RE8snUsgtLrP6ca8N6jtvyVFddXWo.EEgTNz5Vl68H9fsknwlHeL1PGHZfyhovsiFk3aY9gc_78b v_mHrTEFnqD_lji3AWO7oEYdeTk.hnTqXjKVwdI7rOOBZT8wfn3g077CeQXHGXXWenxmBgO1tclF gM6sz_HI1fcTRWC2_QsV15mUQsO5._kcWVBiM3aG.cPm2iZcXP2lZARMyTTqhBeMhNKTO4Nm1lPf UoNSMIkxRTKJcj_WcywuC2XYTSpenHArwAONaLyz.6oaZLfyZ3yApeF_qVAwPHzUoy7lh32iP4kx RVuhuTtSTCS34x8t.XrPXv1J.HL3LmB9Fvjtb9tDjgud9JH6BITGiKr4oplIMQ_jlo9i7ZSiV_bI urVg0FL._NcsOROKPCIOH1RPR53AX8LPTFdNTLgSNagG95AFb6jq.Uu0_zC2SUqyJHeWUBg4w_oH oxskXhz75pjNuA3EU6FsaR2D0JlgDvnQG.Tmd4GegmqRxcFs8itAVu_Anes8gEkLYqVQKDYusWNv Qz6h2rzjIrFdqQlrwJcJcTcSvSdgUb34GnglXUcMpeE6.vQgwSLp2b2iVDxFAbDtGkwaKUjQb4m5 GtP_ZYmizroi3Bg7kk.QjadLjVVO_oQ3GVCXG036x8UFQKqttSdlN3g1z3sOE3EWaJc7nX9aFMaG CmYiQig1g7eBNOHAUz1ghh57dPCZPFIw87iIpDMYMLRueWAQ.HqOf9ySdjAD1flx7kyxih0egkVX yl6hMmAl4g.pOONJCi4VyIaDLTdZeJJ28BdGf9HmbEBXjx5mqjVL5qYPWwF7lsXEeb9L3g2BUE10 1kS5AwUsYMbiomykAL7Jsk4rg.Y66.HgyDfjSGHSy8SoqbBSlChHQvgzsgh3OyPbM27NURI6JsTU jXpMWvZQT7I80pi3VSp4WeDG8aIMA59tw5magBeVBRoJyBLMFtQI9RMYQmf5oH6BwsMDszYuWcDS ArUIJPzLvlBs9lSRv0knZk6.8GTqy_5n9UPBd1ug.DssraM4dIwqn.qtsCVnjAlrqJSDyuK8gI.2 EaI.17U4ECJjfd4EbrGqUTdhh3tWFcmZjWvjRprYNs1C3pVPnf5zEzJOgWIZi4WKyKvpiRmpJAk6 b6AkRmWZOF0RQHqVv3QkIUUYBqR1nnRxV1l1Z8.DRvlJ8mm0B4YTyeDC38SxPIgri2Jt5Mym9ZfV vkgpil8MHyNFXGUFcvzZs7hIthg5_AzeYKZnrmXnXRla9DCc37rqgG_HWhP16LrOxHYUJz7FOyEG Ew3OBZQhTap0nVJiYl_C4xux68CqnVNJojSTUyxSnDDw7JfBZc6PNos65kRQMpaQuvJ3ph3yDwTo .w8EBHbayNEWKPd9aqOYxPgmyrnX0rqMF0P70TaSPUmuCZdbPNtXcAgolr3HG1r7TX.PpgG4z6rB Hd0DKHMM_IhOO8Xjzu6t9UEFiQZ_VvQUCxIhNxNujzkTQT71iRAdfTTQc8945276fgGumGvDX40O G5e5rNelfmElWelVtXe_PZG68gRdm6.rOwqG0s142UoazcL1tzmWUx.dm4namOGpIP.iVswjZHI7 dX1DJ.RAE8AQlEJ0UDZcj4HAyFHyrhC_g38OXDvgQWiXidLVnhgsqsOVtJjOsA9BfJgom299bojo 9oBKnrf724UHrgnHRpxYFzKDYD4brb60OZsH56v5jWGIIyadtNKcLUa0IgmjRfTKz.wykV6K6Zsk ndpFgiSj6cvDQFhmjTzrMBlX5fNWBl1enAfU71qc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 00:19:23 +0000 Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 16d71f55615f10c8571ccdd7233f3d84; Sun, 12 Dec 2021 00:19:18 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: Date: Sat, 11 Dec 2021 16:19:15 -0800 Cc: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot Content-Transfer-Encoding: quoted-printable Message-Id: <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> To: Free BSD X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JBQHk5Dhfz3mTJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OjCX1XIl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.66 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.78)[-0.781]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.62)[0.621]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5198 Lines: 149 [I've cut out the history: just presenting some new evidence.] First, a little context from getting to the db> prompt. db> ps pid ppid pgrp uid state wmesg wchan cmd 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] 16 0 0 0 DL (threaded) [bufdaemon] 100089 D qsleep 0xffff000000ec9478 [bufdaemon] 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] 8 0 0 0 DL (threaded) = [pagedaemon] 100087 D psleep 0xffff000000ee2b38 [dom0] 100094 D launds 0xffff000000ee2b44 [laundry: = dom0] 100095 D umarcl 0xffff0000007b38d8 [uma] 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] 15 0 0 0 DL (threaded) [usb] . . . and "mmcreq" is from the while loop in: static int mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) { =20 req->done =3D mmc_wakeup; req->done_data =3D sc; if (__predict_false(mmc_debug > 1)) { device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", req->cmd->opcode, req->cmd->arg, req->cmd->flags); = =20 if (req->cmd->data) { printf(" data %d\n", (int)req->cmd->data->len);=20= } else printf("\n"); } MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); MMC_LOCK(sc); while ((req->flags & MMC_REQ_DONE) =3D=3D 0) msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); MMC_UNLOCK(sc); if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && req->cmd->error !=3D MMC_ERR_NONE))) device_printf(sc->dev, "CMD%d RESULT: %d\n", req->cmd->opcode, req->cmd->error); return (0); } So it appears that the error report: mmcsd0: Error indicated: 4 Failed ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying true in the above code: an unbounded loop with MMC_LOCK(sc) active. The "4" in the error report seems to be from: #define MMC_ERR_FAILED 4 It looks like there are some problems with handling errors, problems such that it gets stuck looping (no panic, no progress). That seems to be separate from why the MMC_ERR_FAILED was generated in the first place. So: 2 problems, not just one. Thus it may be a good context for tackling the looping problem with a known example failure to look at. Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 in = place, just to capture and report the tail of the output for the boot failure. . . . subsystem f000000 release_aps(0)... Release APs...done done. intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... done. netisr_start(0)... done. taskqgroup_bind_softirq(0)... done. GEOM: new disk mmcsd0 GEOM: new disk mmcsd0boot0 GEOM: new disk mmcsd0boot1 smp_after_idle_runnable(0)... done. taskqgroup_bind_if_config_tqg(0)... done. taskqgroup_bind_if_io_tqg(0)... done. tmr_setup_user_access(0)... done. subsystem f000001 mmcsd0: Error indicated: 4 Failed epoch_init_smp(0)... done. subsystem f100000 racctd_init(0)... done. subsystem fffffff start_periodic_resettodr(0)... done. oktousecallout(0)... done. clknode_finish(0)... Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy done. regulator_constraint(0)... done. regulator_shutdown(0)... regulator: shutting down unused regulators regulator: shutting down vcc_sd... busy done. uhub0: 1 port with 1 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub2 umass0: on = usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0: Attached to scbus0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: random: unblocking device. No more output after that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Dec 12 08:29:25 2021 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 04EFA18CA431 for ; Sun, 12 Dec 2021 08:29:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBd9G52npz3NlY for ; Sun, 12 Dec 2021 08:29:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639297771; bh=wiDcUPQ7O3TKeizJJYAmHAgzBjsHWbTVwM9ci6K7sHg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Nw7a9ZVaN/c/fGJqqZiZtRuRYT6ZZBrBuF0R/fI5oBNqri0XsuNEFhF3wbjFkzXt0l2LnFQYAUhuvvKg/orlCkZT5t378jlvxrRqxBSYqZ/B6oRGnWzXoEainvOgWHBxt6OV9P2hmfLJiQAWRdP7n0Wtteiw+dg9mX1uNlwI+PdRak/9drI6MmwqbpNj+mXj7KAP26cVRjcS55OJvdQrCwh6ZyMlePiTZ5HJlm/Y6sB0LgRVUdIz3qjPkttK6iK89T1PWHO4lO2gZsF7rs8n2UEUT/71O5F6AGnr2LJvKg+7KMvgaLmyPod/EhbxO+2DB882AqXBzFBh0ZDo5v3KEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639297771; bh=SoSOWO6S2U7m8Hg6ZW1aZq4FTewecqgcw7guMYO7E2y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EyEOJe2GXA9Rq1ZMFym/pCXLnn+qPvTtTUna9PhKuSck8UyuXcpxA2NlaRPWFGOuP8R5NIgOPptlgpKIgrk5xMwH9asMRGedXBMocgMKmabkT/TUrdwo91eVr0m7MMwyBYM5LXt7Ipg5FozCBhAfWsSSutYZGBc1rg3OwSRubwuwzE25ps3tQ8Ogs83DaxZSmyDvcakiOaev7clx8iOYcQ2VzK5MgnayqrLQGGEog7XyAfutE1rOCyzZsp1DaNU7w0KYWosiAcOfMBO7wSqIHdDg/HGd0WbM4dsbS6Rg4J5g/FzHJsFDEtAGYWGvJFfSyMfVo97L86IroLqNsBG/rw== X-YMail-OSG: gpTNmzwVM1nBOsinrh61BFPCpgHqPFe6cakCDwwm1miSVMdSGqaAQhRa6.Y..5y TtWm3kVeZYShypql3WcHqK9ZYA9T6lu2CSZzT.hqu9mDh0zUxu0GwiE3CE8MUvYWDpFoSah0M5KA hLVmCVSS_0UwUNY5iM_eDgC7F3fKF.CrKrDz4MJw3V0hVYkJxGfK7xhFgEkEMc3D6cTxACBQrJx2 9Oh5ziP1LNWmPqp95ohy5EuhOOep5f2fwnXjjtCeAtt31c68vDEWDwuZaP39M3zMh.D5OsJC5pHX IHOVp5.skqD1wkN9NtSM_ekdjDcE7cUQg0088Mi10U9VM7CY2NsoMNJXHJnAoJTPyBvFkZOs1Z.Y 5w_c10bJeHpK2GlRzoR7VaXk2pNTDOgFZfZvm4Lnq.IY_Fh2h0.Jv6F7XKOve2VTEYfdkoOSNa8W wonifBJ2j3B_mp0dFHe2P8Q5JZ1e23j.6r784gtTPgvYeMpmis_YGprzvAftAZ4Mx66P_6HH_EZM oQiTf4BbCu.JvrFor.dhbhWkkB1D4vmBEj2Wt_VHpfUcvLW4_EVxmiqIaeWpOVkqaqazle3lOM7w SdrFvB4MI3WGbOmhC_XOuFBtHg1h7lRNroSA1agSdjZv13gfwQR749C.dsxjFG.jHcIps9Z.FxZq AlAwBnr1SF82KU.KV7MFLz.qtzkeDjzlyLthSjmoIxJFjjNr66EEGvC9_5OYcbA3Sx4MCkYpmAr1 FQyyzvQyzu.baRmeWQV8TYefzEsb1pWwBhyZOSPL4sMDuLpOlvMSMcxq83n0B1FeaxracTyECqMv YvPTeMptW7ieVRNTC2EVBatWes6qZR6n.KnQutjo48E0fj15yU2EvEmuNc7ifyoVpViZeJIua9CN CDXq_VmLs.UyHwk4gq7ICMbj31Nx9YpuezVaYid2HRX9KGs0mo2VUIkYmpXqtjZAQqQ_xCziD9uH l7U3FjfYTAjRxIvzNnaNEyu8ZyQpMpD1cXkHTP5PNzoB2vEtn7CKjt13dnbCV9.FrxRev8YyRrZg paLWfIulXWAuc.ELgO91bkqwDPfKp2Om2p_6jxMWApyV7LSaMQzbGf35SRDOoghzyKzNoYOn6s9A wE8Ft6deIuYJW1Q6i5zWUpmG.a7q355Z9WmzvWdBlcAjb4sytU.SAZytj_MolneRWHm6HhePgm6E UWR42mHlGVWEp1BMUeOQ2Zd0M7koChHB_0BDscMnxkgUQnzLjnGYYAEfupBcAI1wMFbcNtK.Uqe1 owTXdZgq_agoGTLIBxKh5owOzKVtXDJnQl3IF0GifBxF5dlStj3.5wVlQ.FlEFnbJydfxUX.LQJi xutLNs3s4A9EzGfmfps3bCEB8i_Xf3Ojl7ZcDsHaQDQTckxPGGO3rsDlKfV0zaaL3Ulrxv_nnctU 8p.hwYPmMgXny4JETx3R5Cr7IK7A0rGQNNy2EJOATlDCbiB4mBf06IVz3fX4H.qCpnoZv8611NyB OgPycjqrp44A3MuvEHA1FQ_j4OvldwTatNGN5qYd8udq6uwVQdKTzf4rmQe9he5rrarw54Pk8Usu qVNJ4uQTLszYMnv4lnaE5oUL_M_AZUKMsug_wi3RTvEJyUBY8tMEoKaQ7s7MClnIBFjF4LicOq3A c65w4vO9XSFcxeIdRfJQ5aU8LDjlQ5io1FMITg6sEwE5x_QCnmoMsn9FqTa.elju4i1MGRhU4csN QbAYPpDcWBDulzquUkOtqkhwP55129rZXdLQb.OZip9Dz3ibKiYJXOXli1W6dKMN7f1k_4j1phvB oAqYaluF7Bo8XP6uqYkoY2HPMhGjbEWUv2KNQxdtd3l.7m03helaEFVmK6ZrHhe1kVI.WQeMF336 UQLG0gFxC1iRQf76fuARPvs.qz67pGt7jzpVW8GMBiVcuG4NXJkjuI1DB_Y11nMGPw1.J_Sii5UA pTU56mqXbhq8fHSBcL8Q71Q5JHxH2GE9YstcjPWawn.nX9f3HX6VoEDphlg7Ivw8hxVjzqJrWpin DoHgFaMGQzTI1xkDimCdp39jFAD.zTOYp_y_LLywHKG0oWfhowBYcjGETVw.i8vHYhgoEjdSVBBq ix_kdqa2gvfYhvaauvDakcVryhBnEi_aa5715n4T6i9_JZks5Jtw9g40JH3FoYUd5ZABpCK3DXds PWB.jAUJYPmgXhiHydeUaJj9NnTdBE9dPgVRDb8DWG19h54b53AMUIeUC7eeHAUUaHfB5DoWI_A7 QWryk5Gdb1ha77J9LWddUCwMXkCLmTT6zzKhWTonIzjJGU83b X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 08:29:31 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3b3441adc3c3cae74acbccbea9c5b164; Sun, 12 Dec 2021 08:29:27 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> Date: Sun, 12 Dec 2021 00:29:25 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JBd9G52npz3NlY X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Nw7a9ZVa; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9693 Lines: 261 On 2021-Dec-11, at 16:19, Mark Millard wrote: > [I've cut out the history: just presenting some new evidence.] >=20 > First, a little context from getting to the db> prompt. >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] > 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] > 16 0 0 0 DL (threaded) = [bufdaemon] > 100089 D qsleep 0xffff000000ec9478 = [bufdaemon] > 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] > 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] > 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] > 8 0 0 0 DL (threaded) = [pagedaemon] > 100087 D psleep 0xffff000000ee2b38 [dom0] > 100094 D launds 0xffff000000ee2b44 [laundry: = dom0] > 100095 D umarcl 0xffff0000007b38d8 [uma] > 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] > 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] > 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] > 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] > 15 0 0 0 DL (threaded) [usb] > . . . >=20 > and "mmcreq" is from the while loop in: >=20 > static int > mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) > { >=20 > req->done =3D mmc_wakeup; > req->done_data =3D sc; > if (__predict_false(mmc_debug > 1)) { > device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", > req->cmd->opcode, req->cmd->arg, req->cmd->flags); = =20 > if (req->cmd->data) { > printf(" data %d\n", (int)req->cmd->data->len);=20= > } else > printf("\n"); > } > MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); > MMC_LOCK(sc); > while ((req->flags & MMC_REQ_DONE) =3D=3D 0) > msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); > MMC_UNLOCK(sc); > if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && > req->cmd->error !=3D MMC_ERR_NONE))) > device_printf(sc->dev, "CMD%d RESULT: %d\n", > req->cmd->opcode, req->cmd->error); > return (0); > } >=20 > So it appears that the error report: >=20 > mmcsd0: Error indicated: 4 Failed >=20 > ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying > true in the above code: an unbounded loop with MMC_LOCK(sc) active. > The "4" in the error report seems to be from: >=20 > #define MMC_ERR_FAILED 4 >=20 > It looks like there are some problems with handling errors, problems > such that it gets stuck looping (no panic, no progress). >=20 > That seems to be separate from why the MMC_ERR_FAILED was generated > in the first place. So: 2 problems, not just one. Thus it may be a > good context for tackling the looping problem with a known example > failure to look at. >=20 >=20 >=20 > Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 = in place, > just to capture and report the tail of the output for the boot = failure. >=20 > . . . > subsystem f000000 > release_aps(0)... Release APs...done > done. > intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... > done. > netisr_start(0)... done. > taskqgroup_bind_softirq(0)... done. > GEOM: new disk mmcsd0 > GEOM: new disk mmcsd0boot0 > GEOM: new disk mmcsd0boot1 > smp_after_idle_runnable(0)... done. > taskqgroup_bind_if_config_tqg(0)... done. > taskqgroup_bind_if_io_tqg(0)... done. > tmr_setup_user_access(0)... done. > subsystem f000001 > mmcsd0: Error indicated: 4 Failed > epoch_init_smp(0)... done. > subsystem f100000 > racctd_init(0)... done. > subsystem fffffff > start_periodic_resettodr(0)... done. > oktousecallout(0)... done. > clknode_finish(0)... Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > done. > regulator_constraint(0)... done. > regulator_shutdown(0)... regulator: shutting down unused regulators > regulator: shutting down vcc_sd... busy > done. > uhub0: 1 port with 1 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub2 > umass0: on = usbus4 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0: Attached to scbus0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=3D0x2 > da0: Delete methods: > random: unblocking device. >=20 > No more output after that. As for why MMC_ERR_FAILED results, the following code diff is intended to suggest what I think may be incomplete about sticking to what the device-specific code supports vs. does not support (not supporting HS200 here). The code does compile in my context but is untested. The email handling may mess up some leading whitespace --but, again, I'm only trying to suggest a type of change. # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c index 9c73dfd57ce0..dffd1c382684 100644 --- a/sys/dev/mmc/mmc.c +++ b/sys/dev/mmc/mmc.c @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing timing) static bool mmc_host_timing(device_t dev, enum mmc_bus_timing timing) { + kobjop_desc_t kobj_desc; + kobj_method_t *kobj_method; int host_caps; =20 host_caps =3D mmcbr_get_caps(dev); @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) case bus_timing_mmc_ddr52: return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); case bus_timing_mmc_hs200: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); case bus_timing_mmc_hs400: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); case bus_timing_mmc_hs400es: - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 | - MMC_CAP_MMC_ENH_STROBE)); + /* + * Disable eMMC modes that require use of + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the + * tune or re-tune method is the default NULL = implementation. + */ + kobj_desc =3D &mmcbr_tune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) + return (false); + kobj_desc =3D &mmcbr_retune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) { + return (false); + } + + /* + * Otherwise track the host capabilities. + */ + if (timing =3D=3D bus_timing_mmc_hs200) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); + if (timing =3D=3D bus_timing_mmc_hs400) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); + if (timing =3D=3D bus_timing_mmc_hs400es) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | + MMC_CAP_MMC_ENH_STROBE)); } =20 #undef HOST_TIMING_CAP In other words: have mmc_host_timing avoid returning true for some combinations that definitely do not have sufficient software support present at the time. (So far as I can tell, the rk3328's get the NULL-implementations as things are.) I expect that this sort of thing would go back to using MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in a slower mode, the same mode as FreeBSD was previously using. A possible incompleteness in the suggestion is that there is also a drive-strength setting involved. If that also had "kobj" interfacing and NULL-implementation possibilities, then in the future there would be more to test for possibly forcing return-false than I did above. Hopefully this sort of thing would help, possibly more than just for rk3328's. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Dec 12 08:59:13 2021 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 7D38E18CF7EA for ; Sun, 12 Dec 2021 08:59:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBdqd28B9z3RHj for ; Sun, 12 Dec 2021 08:59:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639299558; bh=SaPkxJkFi3A3XzhGx25thMwY6EMg2iRUkpTBzv/l504=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fBlHrF7+IxYSYQmrptWZbxUKNZsB4Pnx2+vWVuf8vquHgnulEit02rC6ZTCvVzR4yh9/3tf6/SNYUOLsdUC7Gv0NHEJSBQhEy4ZcvY8hQ3NuDgXEHaLxJM50jqAapWu3HDNCknFm+ivILhHynrcoYeFqn3C6TZpwbr07lSwPgCpHus+DRwUHRK+yPdNQzkqzwGLmvDixfKXVAT49C1sO3dj4YLaTOn1n5uPAh8rIjPvUKSxcUs8VcyuUslQfqKf2AsRNQihaYTdQ/IG2IfjdQEx5G7fMxVQExUkgEBL2254OetkxPt6xPT9yEcvqc9bPgEmN+CC/r1vZozdga4jbHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639299558; bh=cieuYr4Tt7ymZyTDEyu7S/bA3AMvqZjVTyDWfZQ7y4u=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fhGWCCdYJ6sM8zPsB9/Re1NXjIoEgVPNjMoQlnF1hlqsXWir9eOcvURwLPivCVt7JeFeVdy4D3DMLyyDO9Pmv3r3oWZduyxRxaxcCc2SFzepG0ua3TRrcbj0/HVO/SAyA9TKaCBldbNNSBz0JW/+oKngS43FBy/LOgJaORwPwvxRuAQuLJWPxx6BVoK3d3g5eJNUzXTC7fKUD3nbPpV6WDwxThQ8hiDRtpipW1LM4x/j2gIrc54CIkBCwtOPFe1bN8mNqwWcOdUBlrIr8la/bMzboEVkrkr5bXGpb85zKL1Z3LdgPBY/0WryayPhjlnIPtBpfcIF0uN/Dn6dIvLJOA== X-YMail-OSG: oBMCNtMVM1l2FdZ6QtaLQkw.pKZUCyZ6h1t7HwFsWh.5g7OP0rNbGsIB1zer1Va oVRwfhRCb_7UhmY_AzPbAMFOSHJLmX3hOb2DsiYEGGw2i1BGqX.37PMkhlvFH9mJoAk42TvfkEmr 9uV2ZGiQ4oXbF5ZgeohxHdRVR3fxa4gfGYQhq6Zj8mES3rdJ_MCx97KEfQ8KSgGrTDgZvI_inprL 62b4TCg07IJ0_7zWF1CuGYpmH9vmp6TxSU7BpIviA4j4h6faTbytcIW2RQEQZn8qXvnzkF8ufZEr evtBP2TuzqTNkskyhe7jCE7fDGhKZNWxX0SWf6ijxX8p8WAa3S.UxSicBEX0X8Nv7C5ZLqBoCr9G 2zew55qEpwnMS2K1zotP5M3KxEjfAV8f5BZ4ZRGfgmH39tdCc_4ByCRvKIvKyNGdGadpw.YtPDUN n8OMJiQxlkl1.UZpanY7I17Qh00QN1u.vz09PBaIjGtZCbi432o66NCg7fMu82A6rWv_s2iLlwv1 4..wqm7xJzLNeadB4dFwzkBP4_rvXa.wkNsVOH0JEI4RvQ4VV2aOI80_.0W4uXKWhpuaKs4qzmMD iONG..bITcZxTyuicyUoPL.b.VPuVEaSG0cd7npoDjMGyZut3i1G.bqRyqgceEl3khcHgyfP60I0 zMV7X_USvoHFmv6_hqmVgY.uJTAXP6UQJhoXMzBhxp3JrXqlf0bUFqj6h1zG_4r._ymXkdXaJZO5 AQA2fGKUfYAU4UYnn4ODU6N40l3wsNrkw3A14.083pb55.Q17xYXSTpBn6wdECvYNG.on1c8011T iwAJDyHZxMNxaeQ0WZ3laN1aHioQ813sPYplNuwP9jRFdGvumx17DWzl2J8fVsoglpgQrAam7Ggi VIWFrvwNFIMASl_LUp7CKWWjp5ZA44S5cslP.Ludh9fnQu4cleYMBpNGnXKkdwgKBQ3c7pMIk4OJ 5aKafLa4fneovuYdk55PxaVfmp6okGyYCpRbnG9iDPUu5gSYhe7ABzAX74QaJALl7kUAxhrV6L.z eNDlr5hWUj7BZGXS70zN8j8NeoeoH5fNrk1yNPVCYcWoUnTS.dlhYfTiZdrnoaERP.bTOUFp1gdI ZqOJ6o6SFAKDPSPANjeMTipAHTQC4mPY1izkwPvtp4FtSRkQyaWoHzMq78hgmc9dOpPYvrIj3nlN Yv7T9mHAgB8JhSMVKDjoSBZv6gyT0Nw4vfpIWgeUnYmKB_GE0jTUqtltaJCfvuP14n4pmjIPaJaM 2JAm8w01xW4Z4QhHyfBjmez9MTDhSTC07fZpDg0xFM07mzaDxY5nb9x.gFWuCY7eIpgqfsgzLJ0G VDoAFKNWQWAW_DuCngQYjsuB_N7s75tJ8zKA3gzfTNpJ1YlQsKffYXI6rNF6HJGmgHqdKaWWzcyM tuMpTIiNw5uV1dWYM0fswzzTwb6DGqy9Ze24QQuVrjYfuqt9ctv3zPb_YJFYAHYjG4f9eV7jHJQ8 0hfdKOZnPWjxRYFR_rBOG2CBUUEQNbV6bUids2x2UoLn1fy2bL2KstuUwhLq18tl2dM3.qbOgIo1 5NmCBbR4ZAoGCE8KIWM9TPsjcDcwMx05u8dtclKWX.1KoOFLIx25glCh2UCl2S5LmAx8bJ0nJg97 c21xUXBAnxyY_1v1FgIQppvR6y.Yda_s0d4E8sNdSgZCCUY4EgCxD.JB3VWOQkMKboC.ktogrQTX DZmipUz32YPD14OUTwagjzamKxFEcawXTMRVAHrUesO.RhDk46Kdss9VWd5cO0hbd2.Cj2.DPO47 ip2vs4UDRMVa4zeWC.m0pggFSJRQXSrAwLpL6qG6zAR8j3h6iPE69A_VNyLz1Zr0n2oWtRbapTjC g.CV5KPW928JdWcBIDthFdl2B8Po4JqoaEry4lHfhHPXQ0lM_94d7RhIZybLZfCMfd1zfjA9bbGy MhoezhS1.8CYoaUTCnRFwrIIiN7k8JLJoATsEG1lPUmaCgMjB7UPKgT2X62TxajxDjHF0Mn3ag6s 3_gwmZ5PtBzQ0ugfSjhWz9P64jrKkEFUZ3InsEU0rtFZe2EwuTcpy.5yPBfsA81W9mAxSwXNUeQU zQT6xbmM1dj0CMPTgQW8rW37wT172Gxe6ujSs96.EtdApTDF0xIcSc4LJ1ctFdTxKZbBmbRy3ATY A.ynf1DKEyyGvaGRLu2Q3SvMNysc7ofgmkRoHouLI9QUS.4JEsht_102kLp6o55VJlozRVi.HGJg iE2yuEwKy1dfCYi5kxO5J5AEVY7wcGBc3BlM8rEq4eiLpMvns X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 08:59:18 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7c20201941fc613fa1e8542dbbb437db; Sun, 12 Dec 2021 08:59:15 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> Date: Sun, 12 Dec 2021 00:59:13 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JBdqd28B9z3RHj X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fBlHrF7+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10825 Lines: 291 On 2021-Dec-12, at 00:29, Mark Millard via freebsd-arm = wrote: > On 2021-Dec-11, at 16:19, Mark Millard wrote: >=20 >> [I've cut out the history: just presenting some new evidence.] >>=20 >> First, a little context from getting to the db> prompt. >>=20 >> db> ps >> pid ppid pgrp uid state wmesg wchan cmd >> 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] >> 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] >> 16 0 0 0 DL (threaded) = [bufdaemon] >> 100089 D qsleep 0xffff000000ec9478 = [bufdaemon] >> 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] >> 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] >> 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] >> 8 0 0 0 DL (threaded) = [pagedaemon] >> 100087 D psleep 0xffff000000ee2b38 [dom0] >> 100094 D launds 0xffff000000ee2b44 = [laundry: dom0] >> 100095 D umarcl 0xffff0000007b38d8 [uma] >> 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] >> 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] >> 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] >> 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] >> 15 0 0 0 DL (threaded) [usb] >> . . . >>=20 >> and "mmcreq" is from the while loop in: >>=20 >> static int >> mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) >> { >>=20 >> req->done =3D mmc_wakeup; >> req->done_data =3D sc; >> if (__predict_false(mmc_debug > 1)) { >> device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", >> req->cmd->opcode, req->cmd->arg, req->cmd->flags); = =20 >> if (req->cmd->data) { >> printf(" data %d\n", (int)req->cmd->data->len);=20= >> } else >> printf("\n"); >> } >> MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); >> MMC_LOCK(sc); >> while ((req->flags & MMC_REQ_DONE) =3D=3D 0) >> msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); >> MMC_UNLOCK(sc); >> if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && >> req->cmd->error !=3D MMC_ERR_NONE))) >> device_printf(sc->dev, "CMD%d RESULT: %d\n", >> req->cmd->opcode, req->cmd->error); >> return (0); >> } >>=20 >> So it appears that the error report: >>=20 >> mmcsd0: Error indicated: 4 Failed >>=20 >> ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying >> true in the above code: an unbounded loop with MMC_LOCK(sc) active. >> The "4" in the error report seems to be from: >>=20 >> #define MMC_ERR_FAILED 4 >>=20 >> It looks like there are some problems with handling errors, problems >> such that it gets stuck looping (no panic, no progress). >>=20 >> That seems to be separate from why the MMC_ERR_FAILED was generated >> in the first place. So: 2 problems, not just one. Thus it may be a >> good context for tackling the looping problem with a known example >> failure to look at. >>=20 >>=20 >>=20 >> Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 = in place, >> just to capture and report the tail of the output for the boot = failure. >>=20 >> . . . >> subsystem f000000 >> release_aps(0)... Release APs...done >> done. >> intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >> done. >> netisr_start(0)... done. >> taskqgroup_bind_softirq(0)... done. >> GEOM: new disk mmcsd0 >> GEOM: new disk mmcsd0boot0 >> GEOM: new disk mmcsd0boot1 >> smp_after_idle_runnable(0)... done. >> taskqgroup_bind_if_config_tqg(0)... done. >> taskqgroup_bind_if_io_tqg(0)... done. >> tmr_setup_user_access(0)... done. >> subsystem f000001 >> mmcsd0: Error indicated: 4 Failed >> epoch_init_smp(0)... done. >> subsystem f100000 >> racctd_init(0)... done. >> subsystem fffffff >> start_periodic_resettodr(0)... done. >> oktousecallout(0)... done. >> clknode_finish(0)... Unresolved linked clock found: hdmi_phy >> Unresolved linked clock found: usb480m_phy >> done. >> regulator_constraint(0)... done. >> regulator_shutdown(0)... regulator: shutting down unused regulators >> regulator: shutting down vcc_sd... busy >> done. >> uhub0: 1 port with 1 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> uhub3: 1 port with 1 removable, self powered >> uhub1: 1 port with 1 removable, self powered >> ugen4.2: at usbus4 >> umass0 on uhub2 >> umass0: on = usbus4 >> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >> umass0:0:0: Attached to scbus0 >> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> pass0: Fixed Direct Access SPC-4 SCSI = device >> pass0: Serial Number REPLACED >> pass0: 400.000MB/s transfers >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number REPLACED >> da0: 400.000MB/s transfers >> da0: 953869MB (1953525168 512 byte sectors) >> da0: quirks=3D0x2 >> da0: Delete methods: >> random: unblocking device. >>=20 >> No more output after that. >=20 > As for why MMC_ERR_FAILED results, the following code diff is > intended to suggest what I think may be incomplete about sticking > to what the device-specific code supports vs. does not support > (not supporting HS200 here). The code does compile in my context > but is untested. It is now tested (at least to be a useful hack): no longer am I running an older 1400042 kernel. For reference, # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n251456-22c4ab6cb015-dirty: Sun Dec 12 00:34:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400043 1400043 And it reports during the boot (other than the "REPLACED"): mmcsd0: 125GB at = mmc0 52.0MHz/8bit/1016-block So it no longer sets up a mode that the rk3328-specific-code does not actually support. (Nothing that I've done here deals with the looping issue when there is a MMC_ERR_FAILED or the like.) > The email handling may mess up some leading > whitespace --but, again, I'm only trying to suggest a type of > change. >=20 > # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc > diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c > index 9c73dfd57ce0..dffd1c382684 100644 > --- a/sys/dev/mmc/mmc.c > +++ b/sys/dev/mmc/mmc.c > @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing timing) > static bool > mmc_host_timing(device_t dev, enum mmc_bus_timing timing) > { > + kobjop_desc_t kobj_desc; > + kobj_method_t *kobj_method; > int host_caps; >=20 > host_caps =3D mmcbr_get_caps(dev); > @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) > case bus_timing_mmc_ddr52: > return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); > case bus_timing_mmc_hs200: > - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || > - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); > case bus_timing_mmc_hs400: > - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || > - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); > case bus_timing_mmc_hs400es: > - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 | > - MMC_CAP_MMC_ENH_STROBE)); > + /* > + * Disable eMMC modes that require use of > + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the > + * tune or re-tune method is the default NULL = implementation. > + */ > + kobj_desc =3D &mmcbr_tune_desc; > + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, > + kobj_desc); > + if (kobj_method =3D=3D &kobj_desc->deflt) > + return (false); > + kobj_desc =3D &mmcbr_retune_desc; > + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, > + kobj_desc); > + if (kobj_method =3D=3D &kobj_desc->deflt) { > + return (false); > + } > + > + /* > + * Otherwise track the host capabilities. > + */ > + if (timing =3D=3D bus_timing_mmc_hs200) > + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || > + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); > + if (timing =3D=3D bus_timing_mmc_hs400) > + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || > + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); > + if (timing =3D=3D bus_timing_mmc_hs400es) > + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | > + MMC_CAP_MMC_ENH_STROBE)); > } >=20 > #undef HOST_TIMING_CAP >=20 >=20 > In other words: have mmc_host_timing avoid returning true for some > combinations that definitely do not have sufficient software support > present at the time. (So far as I can tell, the rk3328's get the > NULL-implementations as things are.) >=20 > I expect that this sort of thing would go back to using > MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in a > slower mode, the same mode as FreeBSD was previously using. >=20 > A possible incompleteness in the suggestion is that there is also a > drive-strength setting involved. If that also had "kobj" interfacing > and NULL-implementation possibilities, then in the future there would > be more to test for possibly forcing return-false than I did above. >=20 > Hopefully this sort of thing would help, possibly more than just for > rk3328's. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Dec 12 21:00:12 2021 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 D0F3E18EB4B4 for ; Sun, 12 Dec 2021 21:00:13 +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 4JBxqJ6zLLz4fhL for ; Sun, 12 Dec 2021 21:00:12 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 B605C27D8E for ; Sun, 12 Dec 2021 21:00:12 +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 1BCL0Cp6075390 for ; Sun, 12 Dec 2021 21:00:12 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BCL0Ccb075389 for freebsd-arm@FreeBSD.org; Sun, 12 Dec 2021 21:00:12 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202112122100.1BCL0Ccb075389@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, 12 Dec 2021 21:00:12 +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="16393428121.0D6e.74548" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639342813; 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=fpqVUxfXVrJMy3lCbB1O5HEbR4luG5Re9HDd8mCW+84=; b=V0EvLjHkCKyLfnBxZlV2z2idWIEijbJvpt9jpRGv3XgA0nwUag6kocc+L6rTGOIZkLStzN +ZQ6DzqSlzY+Yqmqgs8i94KvNzKwBGlc0pOs+/1fMnd/9mMrU4H0r42xiS0whlEWbRga6N OHqY/QUW05Gl5tWEQ/eOO8tR/QsugMYd4rY5LGz2Je60Xm7mk5RV30W5ATk5/PJxgTP9bj D2ICqjbgyKV8DJ1F9fysSxf44rAGS1N7tUTZIwJmGAIHiCGb0lXp6M5E8Up/o9ZW6RiO8e fEpazZkptZYFkZ6to4dIZYwgz2iN9bq88BBMmD0kzSnSVDbrLo3dNiBUl6LIuw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639342813; a=rsa-sha256; cv=none; b=q/M70AKttMmELC/uIRk+I0xCyOoXJuKqtm60/gdtKLI6oivEDao26qqwuOriMBTx88IUaP RFEFEYUp/2XlQnNzqokNexs9CqzQmXxJbRW+3Xw9BDTlO59F67zHDCL8iW0EOnlnugGrIn AoG70AjqJQxFLZYDzM115o0SxZRceN2pohNECQ9D8CQKRGrTv3dIFunEboAa/r56zfXh++ bJeXrHRkrE7puHsmIsbBbmkV0+jXuhRH8qrVwWQzl0bguzzMSNMfRvZ2zYTBHgjSuKvudR Qe7UYNlIghmi2tXqMHR3KHw9F7ngBvgZBN4w3t17JH4DpPbOdUBmGGoGze56Pw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y Status: O Content-Length: 868 Lines: 22 --16393428121.0D6e.74548 Date: Sun, 12 Dec 2021 21:00:12 +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 | 239673 | Spurious Interrupt message from /dev/led/led1 Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 3 problems total for which you should take action. --16393428121.0D6e.74548-- From nobody Sun Dec 12 21:38:19 2021 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 65B4418D4D5B for ; Sun, 12 Dec 2021 21:38:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBygZ0Mrbz4pLb for ; Sun, 12 Dec 2021 21:38:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639345106; bh=/JHnhbsIw4UJhFzD2BJi54InuVFSsGe0sl0ng/D8VFk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=R5W0N8hqKi5MANU4ar5JMc43UHZQeKr6OBW+JMqF7TA28Pwj6f/ySYWDPAT0K5dfnk7BkVhhRv7B0nVSChfRVxG7Yn2sR8SEdntbvb6zcU92IA7BrRPuSe5qrhjXfgakdmcKSYAmwdVHkD1aXGIztfATm/SGyrYh4BP3EwfN5BG5hH7ucbbSSqZCIWsscMfBxKCm16WygpweKJNr3UGUHpnqJo+46xhsMwodUAkuXDBnmpspQziAle5GB7ElK0UQ4gxBGDHVsTEjzntnj4Xva5rE8b1S1Bfbe2w6HSUVLB63fWhTHMOXqt0CaLAl0lbesfifvebV+Kyb448QaTylFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639345106; bh=pBhb8ubbxAiy7RcFG0PoGGylUf56AWojSPMlfO/p/zn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G+tXpOvHr94rsO17kzC9dx6BU7fR44kOyAaenyk1NCYH8K4cbT7/n4QJvotRHjVPJGAPdpb6CEXvXJSv3EiWMRckIxeSkSJZZKGoeEgXDebBRZN75BJ4pYlaz0dyVqXx4mIk1a9s6UhRQQgy9JgZcTXCVQW6zY5v8Sp0jYRGF9nVH3vhnqrUqtUc+j0mXs5XJmfnerZclNMtxtjHbh493uUxC8l9QI/urR7FecxXDke5QvG13ykCfx5+qKKfkGV/a0x3VsmBzJxGb3Cc1lpnDgmQ9Y2j1oJ1tip+4iKRnd+ALKVRgmr1wZStVnWf7cLlqx/n8YtW3ouHEz1LS0fIcw== X-YMail-OSG: ctsW4vIVM1l0SrZzcnr572jz3H2EnD1tOJ5XtplmLsE0supg1fLVuWUntWgRqSb L41eMHDyFqufXiKkzdyrJgkNOHXK5Kr3qS1rE5xgd5h49gwbO5gGsOJei3cndteiC11HvHZ4tfyd Y8BCsc5ifY2ue7G6YuYbXin0gk1XAhGhzMa9h83_Q7GknYKB71cv1go.7K0yTvpIWwAveWEcuQ4v AKIPvXCL88AdUxICoVrASAQ663k0vcg9q0bPdMqJWdVu6Lh1XhVhZcI3L2xJczyu2_.dNTK36ejg Md2hUKxGpRt4.X7DVxxvGxnnLVceDWZNWMAY4ThgVdm8UDNTKAHZAV_V_nGf0lDb1PBreDsJXDLJ ZtGx4bmZ6kqxh7yW.2KzvblDo5u1ECx5_ffFEmOT6LxZbNSLcUcW1rDdpxF33.jboz22MLP643gB 9FOiCVGjORllS4j_Eou83Bq9tND3rsfb0FrP1LDYRYg5MXOFEtGRurhMzOEbQVq0Xeod7aP7WyAX JTqX.ZykgAHOE6kVjgwnYVJE83fK65NYmET2D9Dp3h.6cQMa13aSR5Y.1O5zrgup.f4ax9mm7DrS IPj92Bgzer9dHbGseRfc.5IKgGjxOs4rCbHJjcRJOgnxAWbLhAF1c3RohXJDXrEnFezXqXohoe.J ZSBPfavLITRGTHu_hur5_iC9pslNAiihzMlIpDLkzm0iCxbYP5bvySCplJjUws3YT1_8jNovUyJN vSTjCkJmaJzSxV3HVcQTtfKoGf41r8eL31u5IT9XwKreqOEy5vFJSSRNK6sjc3hT7SA6fbI596iW ofrdDyIKF5pXC0o02boDGvt9FJYGGgXw9410Kz8Xp3LyA_66P2O5Vs2mZE7jaAtKGkqpvyHeqGd_ Syc12YfiwluhcC18wq8tYsb3tVtLfdKUfnVPAMOPaY7T_epOSCW._7Ku_0_5XZQRr_qrRPEcvbz5 G9S.Cuz26Axmdb.bMqqj6ph.9l3za4Wktx383bL4jqCbgGdpImpbfuhCaRW9nG6Z1AIOWfUl5gKE 5YJKuRH.VadPNhlrUQpzf3plAbMZiXRuFKLK2uJcGyCZ.Iuo167Uct8DsEdIqryMvSHAoOFywgFD U7KFBnxPCdrnobR0ws1YTXxn4MYw3dazBzWFM7HtIhyK.kAafsW2elejJW3sRYSyWOv2.hQFUhiE 0pv54hoSdu9BXVGISDXBPGUzxAoMOgHfOZCelvr1BiqOo7ouWoyeMFvPSEc_MUmiuD2qjKJBrRVJ Ol_mxZIplg5IiReQSizOvLk0Vh8DlfIXgB74P.pfdnvf.HjJJEgkZZplSIujAFrB7swDaZ3q9nKc OVMGcWT.rAuZ7y7dhjrgbN24fR1TU.8oQ2NJ95IJSdsamRaW4m0MzdTxV.oH0uVEdqU3vu78PvZ9 w0rHW8M7B2nn6TZF5Eus1aVzvVSvVN0qF7SCOqDPhpHwavmdLvaLejFA35gbhRu0cdnMGMBU_6So BbU.P2sCftIOdPFMkPq.zg8ooDfMCmXdIeh6VN9mbGxRkU0HKcZhe9mFqXL7G6XYj6zjTFbnue7I 0vvTa6SNDpDkfeU9mddWoNbV7gkscsMqtxScWW4T2J9.OXBLD7IdeaBnnJqVOcMJ7r4KDSM_lCgg 1tcUy_8wBSsdaGIUyxefB2A3NDJ1vK4mIPLeDSbrs3hBO23MPvxZpQgKQkBF9hYwpqoYghqGo5.G G2dKD4lTYo74oGVk8TRhxAWZ.ldFQzMVS5bkEEZJm7amEYk_YqySUTbSmGCjWrjroZmBu6IpuOMd F0ET5ocqhWFjHqYuMt5xfNvm1n6KkoioCtqnMR4em95l_c0GjLHnpCQi8MQs17UNJm2DwGmBYiRM VYhug8T3Lu41tbuVy0jlZfg7b.BLZ3rt7AN.N7rdWvAwzsKb3aWfZx2g6pAT8BwSLwMZI1mwNzDp QZMKXP.G1tb6.IEOJVNRyKVtfieWMEXbxRnyf1biPZ5XyGsBGF.bHxrNwUQRwqddJgkkaXKgk4Yw X6BprgWethoR.TGGe9r1inurzvjceG.mGNFCe6megZM34VNQN10rHjvpW50iduZXCYoqAthr.RXa tA3x5MiN5wLeyYtK1NPAOPLXra4JTQTmcz9ZBHHfALwqOhaF3qZSeWzMT_cCQ2vhgGL38DJiiAmS bvufSviCK9GMaGyFtPc_EneLJ.5Nf.WGp0HRqY0PWztLyGVK.1XK51GZXf9YXSQXtTpXbdhjLf0W eGfONT0iU_1l7Gf2t6hFtGfT2dVtRtXi.2hPO7WQSy3JBe4INhx5gxdBp4bv6JiKyDsNm3Lm17Tg dqMBDkA_6i6a5hMZleLfaG_1wz93z X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 21:38:26 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4af5f81e35173ada683013ac15b3d8f3; Sun, 12 Dec 2021 21:38:21 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: Date: Sun, 12 Dec 2021 13:38:19 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JBygZ0Mrbz4pLb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=R5W0N8hq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 15124 Lines: 435 On 2021-Dec-12, at 00:59, Mark Millard wrote: > On 2021-Dec-12, at 00:29, Mark Millard via freebsd-arm = wrote: >=20 >> On 2021-Dec-11, at 16:19, Mark Millard wrote: >>=20 >>> [I've cut out the history: just presenting some new evidence.] >>>=20 >>> First, a little context from getting to the db> prompt. >>>=20 >>> db> ps >>> pid ppid pgrp uid state wmesg wchan cmd >>> 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] >>> 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] >>> 16 0 0 0 DL (threaded) = [bufdaemon] >>> 100089 D qsleep 0xffff000000ec9478 = [bufdaemon] >>> 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] >>> 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] >>> 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] >>> 8 0 0 0 DL (threaded) = [pagedaemon] >>> 100087 D psleep 0xffff000000ee2b38 [dom0] >>> 100094 D launds 0xffff000000ee2b44 = [laundry: dom0] >>> 100095 D umarcl 0xffff0000007b38d8 [uma] >>> 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] >>> 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] >>> 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] >>> 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] >>> 15 0 0 0 DL (threaded) [usb] >>> . . . >>>=20 >>> and "mmcreq" is from the while loop in: >>>=20 >>> static int >>> mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) >>> { >>>=20 >>> req->done =3D mmc_wakeup; >>> req->done_data =3D sc; >>> if (__predict_false(mmc_debug > 1)) { >>> device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", >>> req->cmd->opcode, req->cmd->arg, req->cmd->flags); = =20 >>> if (req->cmd->data) { >>> printf(" data %d\n", (int)req->cmd->data->len);=20= >>> } else >>> printf("\n"); >>> } >>> MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); >>> MMC_LOCK(sc); >>> while ((req->flags & MMC_REQ_DONE) =3D=3D 0) >>> msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); >>> MMC_UNLOCK(sc); >>> if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && >>> req->cmd->error !=3D MMC_ERR_NONE))) >>> device_printf(sc->dev, "CMD%d RESULT: %d\n", >>> req->cmd->opcode, req->cmd->error); >>> return (0); >>> } >>>=20 >>> So it appears that the error report: >>>=20 >>> mmcsd0: Error indicated: 4 Failed >>>=20 >>> ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying >>> true in the above code: an unbounded loop with MMC_LOCK(sc) active. >>> The "4" in the error report seems to be from: >>>=20 >>> #define MMC_ERR_FAILED 4 >>>=20 >>> It looks like there are some problems with handling errors, problems >>> such that it gets stuck looping (no panic, no progress). >>>=20 >>> That seems to be separate from why the MMC_ERR_FAILED was generated >>> in the first place. So: 2 problems, not just one. Thus it may be a >>> good context for tackling the looping problem with a known example >>> failure to look at. >>>=20 >>>=20 >>>=20 >>> Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 = in place, >>> just to capture and report the tail of the output for the boot = failure. >>>=20 >>> . . . >>> subsystem f000000 >>> release_aps(0)... Release APs...done >>> done. >>> intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >>> done. >>> netisr_start(0)... done. >>> taskqgroup_bind_softirq(0)... done. >>> GEOM: new disk mmcsd0 >>> GEOM: new disk mmcsd0boot0 >>> GEOM: new disk mmcsd0boot1 >>> smp_after_idle_runnable(0)... done. >>> taskqgroup_bind_if_config_tqg(0)... done. >>> taskqgroup_bind_if_io_tqg(0)... done. >>> tmr_setup_user_access(0)... done. >>> subsystem f000001 >>> mmcsd0: Error indicated: 4 Failed >>> epoch_init_smp(0)... done. >>> subsystem f100000 >>> racctd_init(0)... done. >>> subsystem fffffff >>> start_periodic_resettodr(0)... done. >>> oktousecallout(0)... done. >>> clknode_finish(0)... Unresolved linked clock found: hdmi_phy >>> Unresolved linked clock found: usb480m_phy >>> done. >>> regulator_constraint(0)... done. >>> regulator_shutdown(0)... regulator: shutting down unused regulators >>> regulator: shutting down vcc_sd... busy >>> done. >>> uhub0: 1 port with 1 removable, self powered >>> uhub2: 2 ports with 2 removable, self powered >>> uhub3: 1 port with 1 removable, self powered >>> uhub1: 1 port with 1 removable, self powered >>> ugen4.2: at usbus4 >>> umass0 on uhub2 >>> umass0: on = usbus4 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>> umass0:0:0: Attached to scbus0 >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> pass0: Fixed Direct Access SPC-4 SCSI = device >>> pass0: Serial Number REPLACED >>> pass0: 400.000MB/s transfers >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number REPLACED >>> da0: 400.000MB/s transfers >>> da0: 953869MB (1953525168 512 byte sectors) >>> da0: quirks=3D0x2 >>> da0: Delete methods: >>> random: unblocking device. >>>=20 >>> No more output after that. >>=20 >> As for why MMC_ERR_FAILED results, the following code diff is >> intended to suggest what I think may be incomplete about sticking >> to what the device-specific code supports vs. does not support >> (not supporting HS200 here). The code does compile in my context >> but is untested. >=20 > It is now tested (at least to be a useful hack): no longer am I > running an older 1400042 kernel. For reference, >=20 > # uname -apKU > FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n251456-22c4ab6cb015-dirty: Sun Dec 12 00:34:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400043 1400043 >=20 > And it reports during the boot (other than the "REPLACED"): >=20 > mmcsd0: 125GB = at mmc0 52.0MHz/8bit/1016-block >=20 > So it no longer sets up a mode that the rk3328-specific-code does not > actually support. >=20 > (Nothing that I've done here deals with the looping issue when there > is a MMC_ERR_FAILED or the like.) >=20 >> The email handling may mess up some leading >> whitespace --but, again, I'm only trying to suggest a type of >> change. >>=20 >> # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc >> diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c >> index 9c73dfd57ce0..dffd1c382684 100644 >> --- a/sys/dev/mmc/mmc.c >> +++ b/sys/dev/mmc/mmc.c >> @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing = timing) >> static bool >> mmc_host_timing(device_t dev, enum mmc_bus_timing timing) >> { >> + kobjop_desc_t kobj_desc; >> + kobj_method_t *kobj_method; >> int host_caps; >>=20 >> host_caps =3D mmcbr_get_caps(dev); >> @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) >> case bus_timing_mmc_ddr52: >> return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); >> case bus_timing_mmc_hs200: >> - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || >> - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); >> case bus_timing_mmc_hs400: >> - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || >> - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); >> case bus_timing_mmc_hs400es: >> - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 = | >> - MMC_CAP_MMC_ENH_STROBE)); >> + /* >> + * Disable eMMC modes that require use of >> + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the >> + * tune or re-tune method is the default NULL = implementation. >> + */ >> + kobj_desc =3D &mmcbr_tune_desc; >> + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, >> + kobj_desc); >> + if (kobj_method =3D=3D &kobj_desc->deflt) >> + return (false); >> + kobj_desc =3D &mmcbr_retune_desc; >> + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, >> + kobj_desc); >> + if (kobj_method =3D=3D &kobj_desc->deflt) { >> + return (false); >> + } >> + >> + /* >> + * Otherwise track the host capabilities. >> + */ >> + if (timing =3D=3D bus_timing_mmc_hs200) >> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || >> + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); >> + if (timing =3D=3D bus_timing_mmc_hs400) >> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || >> + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); >> + if (timing =3D=3D bus_timing_mmc_hs400es) >> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | >> + MMC_CAP_MMC_ENH_STROBE)); >> } >>=20 >> #undef HOST_TIMING_CAP >>=20 >>=20 >> In other words: have mmc_host_timing avoid returning true for some >> combinations that definitely do not have sufficient software support >> present at the time. (So far as I can tell, the rk3328's get the >> NULL-implementations as things are.) >>=20 >> I expect that this sort of thing would go back to using >> MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in a >> slower mode, the same mode as FreeBSD was previously using. >>=20 >> A possible incompleteness in the suggestion is that there is also a >> drive-strength setting involved. If that also had "kobj" interfacing >> and NULL-implementation possibilities, then in the future there would >> be more to test for possibly forcing return-false than I did above. >>=20 >> Hopefully this sort of thing would help, possibly more than just for >> rk3328's. >=20 >=20 As for what was happening without my patch . . . sys/dev/mmc/mmcbr_if.m defines: static int null_retune(device_t brdev __unused, device_t reqdev __unused, bool reset __unused) { return (0); } static int null_tune(device_t brdev __unused, device_t reqdev __unused, bool hs400 __unused) { return (0); } . . . # # Called by the mmcbus with the bridge claimed to execute initial = tuning. # METHOD int tune { device_t brdev; device_t reqdev; bool hs400; } DEFAULT null_tune; # # Called by the mmcbus with the bridge claimed to execute re-tuning. # METHOD int retune { device_t brdev; device_t reqdev; bool reset; } DEFAULT null_retune; . . . It is these success-reporting no-op routines that were being used to attempt the tuning: so there was no tuning done. The code that I added detects that these routines would be used and avoids allowing contexts that would involve putting them to use with HS200 mode. I'll note that there is another such null_* routine that the code (even with my patch) does not deal with avoiding the use of: . . . static int null_switch_vccq(device_t brdev __unused, device_t reqdev = __unused) { return (0); } . . . # # Called by the mmcbus to switch the signaling voltage (VCCQ). # METHOD int switch_vccq { device_t brdev; device_t reqdev; } DEFAULT null_switch_vccq; . . . /usr/main-src/sys/dev/sdhci/sdhci.c has somewhat analogous code for somewhat analogous null_* routines. null_set_uhs_timing for that is from sys/dev/sdhci/sdhci_if.m (but the other two are again the above null_tune and null_retune routines, so not repeated here): . . . static void null_set_uhs_timing(device_t brdev __unused, struct sdhci_slot *slot __unused) { } . . . METHOD void set_uhs_timing { device_t brdev; struct sdhci_slot *slot; } DEFAULT null_set_uhs_timing; . . . sdhci_init_slot(device_t dev, struct sdhci_slot *slot, int num) in sdhci.c looks like (in part): . . . /* * Disable UHS-I and eMMC modes if the set_uhs_timing method is = the * default NULL implementation. */ kobj_desc =3D &sdhci_set_uhs_timing_desc; kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) host_caps &=3D ~(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | = MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_DDR52 | MMC_CAP_MMC_HS200 | = MMC_CAP_MMC_HS400); #define SDHCI_CAP_MODES_TUNING(caps2) = \ (((caps2) & SDHCI_TUNE_SDR50 ? MMC_CAP_UHS_SDR50 : 0) | = \ MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_HS200 | = \ MMC_CAP_MMC_HS400) =20 /* * Disable UHS-I and eMMC modes that require (re-)tuning if = either * the tune or re-tune method is the default NULL = implementation. */ kobj_desc =3D &mmcbr_tune_desc; =20 kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) goto no_tuning; kobj_desc =3D &mmcbr_retune_desc; =20 kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) { no_tuning: host_caps &=3D ~(SDHCI_CAP_MODES_TUNING(caps2)); } . . . What I've done in my patch is analogous to what the the code shown after the #define SDHCI_CAP_MODES_TUNING above does, translated to fit the mmc's pre-existing code structure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 16 18:07:04 2021 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 9926418DF129 for ; Thu, 16 Dec 2021 18:07: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 4JFKnk3yRZz4TFp for ; Thu, 16 Dec 2021 18:07:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BGI75fZ004266 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 16 Dec 2021 10:07:05 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BGI75wZ004265 for freebsd-arm@freebsd.org; Thu, 16 Dec 2021 10:07:05 -0800 (PST) (envelope-from fbsd) Date: Thu, 16 Dec 2021 10:07:04 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Saving environment variables in u-boot Message-ID: <20211216180704.GA4173@www.zefox.net> 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-Rspamd-Queue-Id: 4JFKnk3yRZz4TFp X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.20 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[zefox.net]; NEURAL_HAM_SHORT(-0.33)[-0.333]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_MEDIUM(-0.36)[-0.363]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 915 Lines: 30 How does one go about saving environment variables in u-boot on Raspberry Pi 3? For example, Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found U-Boot> editenv usb_pgood_delay edit: 2 U-Boot> usb reset resetting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found U-Boot> saveenv Saving Environment to FAT... Failed (1) U-Boot> It appears that setting usb_pgood_delay to 2 helped, so I'd like to try it without manual intervention. It must be admitted that repeated manual tries of this experiment yield inconsistent results, so this particular test case is mostly an example. Still, how does one change and save settings in u-boot? Thanks for reading, bob prohaska From nobody Thu Dec 16 19:12:01 2021 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 A9DF018EAD55 for ; Thu, 16 Dec 2021 19:12:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFMDt2wlFz4c7T for ; Thu, 16 Dec 2021 19:12:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639681927; bh=TFE6iEqTYKqL4LrrKRuO0UxBKp1LSXMNXbkay3RA4s4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BrkkxXj3VGWH/fCwsaDLMLHWuvulPaUEqjJSdIHt0cF6Vj7L7cc0dIM8Mlz8w5ostOazKYYLeOtnJGiRBFk/1BAkdqQXxoEDvdC67THAWX544iPtQDcHVNg4U9cumUNUTZPhGVolsJ/kjVASe8KYGnn7HiYJWvv1CIb+5XTQmAgsdOrOlJ6YzaH6wCo59NrV8ziWBxmbvU8RHwDa6ojpT61ALMbrT8VgQ0kTXiyVykyU5r2/ZDUhVnq/iTYqpUDxgYM8LcWIoMmTnhu87aVSYJgeigQYl1gE4loLn01Z1kjd3kF7pUj7TK08SSTlOKBwrwPiaeBqhZTIpik+4EamnQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639681927; bh=eVLmr7PldCFi8vW0G2o9S38SLdtw2JpAOr8S1TcFAv0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MbsTY/MCdugjoSa7eEtvdNcSxiRtOW8zWwoQ9UsVyZrSLe2C3efT/06iB762+Q4Zd7AZLZKWrT7YXBF41T/mdLyw09mkBC7qMdKG2Y6pYEjSEj51dziGaJcQUkBQGHdnNQdQji773PGMft0BlzMdOpy6ScTLAZwp5R0uXV59IHo+IWQ9YsVYpuLtZRQx8WV6Qyx2BR5y7q7b4+XZXdiSgAOcW5LxqcruNH55hmGCcBFCL715wzs2qc/Ns91e4ui9E0vpCeJA0BqIlY/ENHKY/w8qfWEBc4cRFZNOoaXTaIOC8pxtxTq+f7XyHwlVNolt/tva2J+z07x2KgHVIr94hA== X-YMail-OSG: jUIwgakVM1mhSeJhJ0QAlKR9Eq8OPC3w792i0OAuvLLTbGm4iwu_6miS.kzxRl0 xZegKBL54lWnNGY4sI43h1CRIUNSRpQIbkT2H3gIiEB5.fb6uLGYINCKLBJnp2N8oWb_Cuo75Wew ehOD8uPkwBqaTpBWvBspEDm_aEDAqGrdRAkLqLkSnQmEywpKGqElq6LEfDYwU1BoMBD561H5KXV. lsX89pETuhlqZpHwNDIQoBrHwoi8xnkZfM92.fLRMKyAwmjFXL26VqdqgUGrRDh96aFeIKlAIcPr CXL562CnLHUg0A_m6PwO4Qa2GrUuNMx_3Gn3beXnpNRvSSqXAy9mtAzG9ussx.5rV7het9fCnAKd N.1Pq8hztgGuQWpJkL0b4EPk7jz1LxlrRFX6DfVXUQ_ONY75QET7KSux8x4h.bns8u7pzvClPCnR .ZaeOaTrKb9VOWLSN0D1kd7NAL4GP8XHrj8ujVWxFD2fupd1gJZxtjUsu.bAAGSBWsj9qsKnlJVL baybHtq.z.SxfuP0xbkoMcpgY4QmTJUP2nbzf3OcXeDGNopqKkHv4WA9Vy1vBOCfEAXLO50.8mLz RG1ln5.Rsk3bIM3nLy7BHRnDklP109sP5ZjdCl6tNbvZAI.fjNsf7Ys9mAKXYPiub8VxoP_uQmW_ EjwA6qDjtdQzJEN1EdGHVS_rLEdDCYq3WuEBkENJ_mXn6eyxIsy6xEuQJrockt6rx_Q69WL6DDur PjF9gpL1rlHX1EicWWaZ.aYkMVAkES4itZVw1ixWN2cUSZgqEdhftoMMq7Ymxh34KU9yrKk667Om OtIs_Aystviv_ARppmoKsRUYrdtSfJr.Pu2kz_.YAEGOX3gIqKKQkn.8CjGcbDZPnIxgHZw7ahX1 AVCyTDfZINSSQLwcUwCmG2AwF15VRUfPQLXm9EgDmq6TPLzK0pkrkseA6mINxmdDKCFZB6ZmEFTG _RKVnhs0JO_bLRcB3R62RicXhP4sQedt8utnqAQqfGpA.vyJNccRog_zfcIlzDmGId1CmAehw7pg GJVfuulmXeg4QRIHq1D9z_LXRihTM63fzEsBg5v9zeyBJoqLUicJ0FGxQ.wxKPFZd9WPcSV0atKc DbhLwMboRfdEtAkzpWpVDs3IXoKzQrWnIdsQHM4NQBuDRTSMT6kdkYLy_M7Ki9V3tk1YfRRC1I7Z Udp.LCxqePqjzdpvKMDaxu_lxMkf74xq3ZqxUY1PUABY9ylDPJUT5fX_d3qfCIpA3VIrh78tB8IW azGqWwrGTpI2OTpDlmK1O45iN82MW6iolebJZwB9cUXsDIfNLC5MZfpuvCkXGkifjhUX7ac83ciw d9k7YN3GtjF1xz1I0wnOQdO3Bb3jDIyo13g29QIFTJYNQqB81l.Vpo029YzX2BoCrc86yNXRiVzM 6FLC6hgdFhtiJ7NfPFxlyCCDoAi8swwiSs1zBiMBXX4YhZ20WfpbRjantU_sUaTuQl8ZBCtaEa7R tI0KF69LxaLuj9jAVMEnrc9XeEW2i7SVjUYNPCB.Phv6ar61Men9DDZpajzZW3xcflpfBuL3E3uN QV3eE.VXOgYwdc71NNiFClt5eqfQVueTjm0h8z0BTml_tzHtagfr6h.J5qykD.uf6ENpKI8PyNDF DRcWPQnIlAFS6Oioq6bBwqLY2.M1jwUS30QM7_imtFHzEReDvybt0JchA4GMZ_sUP0bQt6yRp6OL aeXgkZWYDTqG.Qz0R2zns3LEwj9.7LW0DhEGqYBBbEotK7FB7HUupgsL7IXTwscUKd_ct75sroSU ZKKiz1tJQAh1Mkqo3IE8z_noCr27pg_yMAX9xreve11n40bJA3y40FHpW2fD2I8Xm0WGxWtHybqh xzdESz8sj_0.WE9eTx5mydo6SNChllfBpUYWpERJfWVgoKoce3ehBrgM..X3Oang8Hv87bqUmZxk a2vSBM6Dd5JaMGm8PPfxyOQ.LzBc8ESYQtigU9482DfebeZm.gg92G_hvt7S1CE1q14prns9miXC 2anbKaLCLuCM9F9O0pQV6w7_2136XpVHavILnHJKYg8Kv5YD_RDAr0u4JRoGirNAZuNT21gxKaXB Aeg2KZ_acglNyaxcL1MTfaqlcMj5H4zwFb9VEasv1N6WUN0NrUYIE5PsihBSVIJuOkDfPC20piZj fLiET_YAEkQ7GGyem6qh68PudAu1_Vrq6idaIGzOGry25p_EE_SVUUws9EvlGLho9xOmFdybmy2J bZgMGTCEbb3_dIuXeFp59isEDa5.uFi2GzqtEJG0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Dec 2021 19:12:07 +0000 Received: by kubenode515.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ae70b1e12d40cfc20289e6712a03f195; Thu, 16 Dec 2021 19:12: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: <20211216180704.GA4173@www.zefox.net> Date: Thu, 16 Dec 2021 11:12:01 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JFMDt2wlFz4c7T X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2183 Lines: 67 On 2021-Dec-16, at 10:07, bob prohaska wrote: > How does one go about saving environment variables in u-boot on > Raspberry Pi 3? For example, > > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > U-Boot> editenv usb_pgood_delay > edit: 2 > U-Boot> usb reset > resetting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > U-Boot> saveenv > Saving Environment to FAT... Failed (1) I expect that is based on there being a microsd card with a FAT file system on it, possibly containing the u-boot that is in use. I doubt that it supports saving to a FAT on USB media. Do you have an appropriate microsd card in place? > U-Boot> > > It appears that setting usb_pgood_delay to 2 helped, so I'd like to > try it without manual intervention. > > It must be admitted that repeated manual tries of this experiment yield > inconsistent results, so this particular test case is mostly an example. > > Still, how does one change and save settings in u-boot? > Someone else that had such issues dealt with it by patching the the build instructions for the u-boot port involved and used their own port builds. What they reported was that they tried: QUOTE > # cat files/patch-include_configs_rpi.h > --- include/configs/rpi.h.orig 2021-06-12 23:20:03.061510000 -0000 > +++ include/configs/rpi.h 2021-06-12 23:20:14.131306000 -0000 > @@ -209,6 +209,9 @@ > ENV_DEVICE_SETTINGS \ > ENV_DFU_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > + "usb_pgood_delay=10000\0" \ > + "usb_ready_retry=5\0" \ > + "usb_max_blk=20\0" \ > BOOTENV END QUOTE But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. (They also later mentioned using "usb_pgood_delay=2000\0" instead, a figure they found in a bunch of configrations.) So something somewhat analogous might help if you are willing to build and use your own u-boot port variant. === Mark Millard marklmi at yahoo.com From nobody Fri Dec 17 01:36:13 2021 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 B8D3818E7301 for ; Fri, 17 Dec 2021 01:36:10 +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 4JFWls6YYbz3rBw for ; Fri, 17 Dec 2021 01:36:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BH1aEC5005097 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 16 Dec 2021 17:36:14 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BH1aDDP005096 for freebsd-arm@freebsd.org; Thu, 16 Dec 2021 17:36:13 -0800 (PST) (envelope-from fbsd) Date: Thu, 16 Dec 2021 17:36:13 -0800 From: bob prohaska To: Mark Millard via freebsd-arm Subject: Re: Saving environment variables in u-boot Message-ID: <20211217013613.GA4452@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@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: <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> X-Rspamd-Queue-Id: 4JFWls6YYbz3rBw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.09 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1663 Lines: 46 On Thu, Dec 16, 2021 at 11:12:01AM -0800, Mark Millard via freebsd-arm wrote: > > > On 2021-Dec-16, at 10:07, bob prohaska wrote: > > > U-Boot> saveenv > > Saving Environment to FAT... Failed (1) > > I expect that is based on there being a microsd card with > a FAT file system on it, possibly containing the u-boot that > is in use. I doubt that it supports saving to a FAT on USB > media. Do you have an appropriate microsd card in place? > Yes, the microSD contains a dd of FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img The DOS partition is writeable, AFAIK. > But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. > (They also later mentioned using "usb_pgood_delay=2000\0" > instead, a figure they found in a bunch of configrations.) > The Pi3 in question is capable of booting from solid-state USB storage without any microSD card, but fails to detect a mechanical disk. Which is the appropriate u-boot-rpi3 port to tamper with? I tried sysutils/u-boot-rpi3 as an upgrade but that simply froze. The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds the USB mechanical disk, but erratically. > So something somewhat analogous might help if you are willing > to build and use your own u-boot port variant. Obviously, that's a fraught enterprise at my skill level.... I'm still somewhat hazy on the actual boot sequence when chaining from microSD to USB. Indeed, it's unclear how or if u-boot plays a role in starting RasPiOS. The term u-boot isn't found on the Raspberry Pi doc website, and the Pi isn't mentioned in the Denx manuals. Those discoveries surprised me. Thanks for replying! bob prohaska From nobody Fri Dec 17 07:00:46 2021 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 2888618FE36C for ; Fri, 17 Dec 2021 07:00:58 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFfyd6B01z3Ddl for ; Fri, 17 Dec 2021 07:00:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639724450; bh=JYur/AlsOydKEJWz48CoviwkmUZHSx0wu9Sk44ApcfI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=j8yvIRBSrr3YmrNI92WmCarWb7ivnVNL3QYv+hIHQkAzhlgNVVYUgMha2Bu14DjMCVjCL1KFMcx7uaIXg8xazckEGBpRG3UeA+ZUD4pAT0nIDBbH2b4lQhYLIxuShGxOr3vgbfWoToTomPqwgzrb4B4BqTvwreNnrTTs/udI2M871fk2bGhdDFylIWTJnyuh9jqwNhW5Wwk2DnFV6ZU4IxIXc9m55oj+MBMaZGTFTnbe04ylAvK6h7HsAJB21XGj4WCBhHZeaXN/aIhxuOds8g6KkTe+RS/qgnU714XLLjC9MywdsJw8ScaMPxNZQFpJaG2LcnmsgetRKuttRoDapg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639724450; bh=D5qj8mp4hU66FEndkNqrn87YcYmlb2Lwb6l6TM+YjeE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QxD3GG9tVSLiyL+pn9V8y5p3bQLMSdLM3hawcrf4702X09TcE3O5eTYlN7gygbFWeTI1XVdtABKEPEgc2gT6XX3KMIOlkqmK5leHL+lZ7CLJ1+j8wN5UdvY0VQXocgnSCzQ6/9SPdkPPkLrkpd1ciRcCcD0bjYKdXvQE5Pz2lAJxwbi1cfHDA65beVw66NWYIVfO/lpt5bZQ+9z0z2lZmySQ8KAnU5VOy/a9Amc/PILGnL0x53dryAxoslS8BDd2CY54qXnqzT9D0+nQ7hI44EwBUMJDDniUsQ5VLpAySj9mGxatRYJeACDExX6x06NfmEAMsKAsM1Bdc/60C0C6yA== X-YMail-OSG: P5d8gQwVM1mzVF.kakG6rIAi_X28g55IJeeuM2mwt.RaIjRm0OUjMj2FKX37ibD OOoPxpYFcRjUw2rqWzytgumJASLIuBl1qluuBy85SueUZCdYLgR071a81YLErOod6kCvsXPvviPa rB.8rdL1T8vyjsxxw3TEe4tAXD9Md1mLYZQhyv8mS1CP2WVyGHUQj3QVAEhvjm6DxXV2znpK_En3 PE4tWHsmcwcLKQRFRFBjnUAtam3FhhXSrYO8hCyTqsjRuaMdlpFU39qn4QaEfyArFc2oFA2OJnZv oR8qXRbddBXT8yj.sxTlNJj_nuQyvgn7CJkB.zu7JEX0lKcGp5Er1_03kl5znYJlvj9XO33uu8Z. Fs9SrL.hGMQghsrQ.maXjt49o9_rFXUQ4JQTMZWSIkCzVQDr6P6.5dhHg1v2.BeLtYIlh.9UQhyd 6iCj_ff0LVYGrIWN6Xh6th.mdk2bMkjMUA7Ldlr6WYq8om_73A3.6l8nas5ooSxqgGRg3H.keTQC E.gD3GdR72C7NDg_6dSz_0n4vwD3qkRQpKuEUoXMp7Jvv_gfixmrbppLuW8lPRc9XyMpYmMkCaCS 6SURtlV6rnaOdCEn1cX_D0FS7I1S2.ppMqN23lQWLAIOf.hlC2k2lEMZzGATR4uKo4JW0jrvqJ.3 4qtSMRdwHH9vsBB65riRYUc8JPhmoBYlU.upiBaTAb0fnXHY6DpGON4G6zBkMNS.vmtRp338s1QF amysXYiMCNeGpNGOEXvkJAFFoN3NsBSa0yBnLZnD63nMobl4GjXhjLnzen7zzW0M07EXB38u69ay OTZLThygQJve.IHCbqlc2KMbASN327_K9UzHtbNwZHvvB0JbcSF9uAP2x.8UpltRStWnZ6gKuE1c hkSjaV8TE0bKmXE20WgoDLLaE281PG0tYkBSBzoivp2fWsDvM87jrLMcJZW0fkqAQtaPXK5LYanc 5WYie8fR0tA7U7PSeYh3l0x.YES5.SEEYbuLmfttjJR9xbFv9IU4R7_1V2ocMUxScxzcUSFtdChi IbFukRTRzh59X0ISL_G07tw9SOfhidosm9d0UHBmSyt3bfIlbXHZuuWsl4N7835G8QhpsfjHvKOv W1PRULGZf1_2G5lw9MIQikDH8sivdppCdZ3mZ8qYFmSTPrhwYIqE8JqnEu_a5hR0x_oy.enHKECV LqY9hjsQfcaRFKz7QuXUxBBclThchQX4aTyafJq35rNeah1ozVUL8C_9.z8H0KjvTQx2i9mF0QVj lCfc6zv_rMJPdyK3hbHo7qafgBPgNClDCsLo.fNj.njMVfVHGQaSCU9Cc25EoNuuXX17nS561wzD 4y37PdLZX8_jSA3gOktrPUmtPNarbLUeN.X2pqUOm5G46__jPYzOo5_4zaCM6U9T2yVxHFaelSOG AITtE1iPVmkF4._LtZxaCD6V.S2rIebomqTTGw8MQvZvfO9omJAP1ePnHzSmKbQIs1zbu3d4SaWo yj1kEbQr_OnoZyCPAy6lNqioVwg2UHPtzt2EimEQGzt5LVxZx8mG8Gy3Bgb.ghoTSqWoa8uiuV.Y zxUkNLFpr9PmMlp7kkS7k7cWwwQtMPfDdzV4._cHs4k2uy5q5_lSQ3F9FjyBLg10K15rwbX_Z86N TwE0Vzud2QloDoqCSZm.fEpA4hXC3K2D8qt1G5WuhGme1Q4kP7RW49njUOqYTAJqLT56_HD4a_Vf kfd7ePb512Bq2hnC0lyWhG16iPu8gcNNk8SdU1YpT3_1nStsmwXIUIN1EWGrIsj6X2U9QDhuaQPK 4aX3GIkquQ7a1YOszSwhjO8XHk5Mz_HR50PJGMSDfoOu3IDYI.I76UBIpDhij.pzys_MOLBvAGxd JobJEJnyz0WV82goaVA_KQ0v4x5wwhtLzbGlrjRo2DEoyta4lszKvF3LNXGf0vyfrwcpDTCMq.gZ 6SDu0a43hDeqRw_0j7IYDQBLKLAQzCJMNzV144gmDxPb7LZ.XHK2iYsP92F.7CutVakqFwmBQ0zj jms64YUzIDw8ZkjwimoKwqyhUAnlRnwPITtrEiOPdcu_7I2wnE3SsaesDdPOwoIZZ5WCHSVu4qf6 Drdr_LbnaF_6Vz55JbxkLGUjWrdzYd1qauCozpnZDhkbfMQrMQCbX6d129GkCzywnUiaJMJItgZK aO3Qx4s3pcBh7EJo4THyfMYdPUPtWXPksWuCAjRBgZEaJ6lgu_XSrlUmpTIdyOVupDyvUchOoSid FQRc9Y3Ai8QTPGILLe.r6wBV8KKUmmiYEySv5UzLrThLhFlPtunSTbrAPjJ18iCFX88pv5vestDj yf_zwQa4peeLDjejgxSc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Dec 2021 07:00:50 +0000 Received: by kubenode538.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a4247d77cf4c9110046e27d81c6d4cb7; Fri, 17 Dec 2021 07:00:46 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: <20211217013613.GA4452@www.zefox.net> Date: Thu, 16 Dec 2021 23:00:46 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JFfyd6B01z3Ddl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5686 Lines: 161 On 2021-Dec-16, at 17:36, bob prohaska wrote: > On Thu, Dec 16, 2021 at 11:12:01AM -0800, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2021-Dec-16, at 10:07, bob prohaska wrote: >>=20 >>> U-Boot> saveenv >>> Saving Environment to FAT... Failed (1) >>=20 >> I expect that is based on there being a microsd card with >> a FAT file system on it, possibly containing the u-boot that >> is in use. I doubt that it supports saving to a FAT on USB >> media. Do you have an appropriate microsd card in place? >>=20 >=20 > Yes, the microSD contains a dd of=20 > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img > The DOS partition is writeable, AFAIK. Hmm. That means there is also a UFS root with a kernel and world on the microsd card. Both the microsd card and the USB drive contain contain such, as well as each having an /etc/fstab (and so on). Having multiple such makes for a mess for controlling which is used (and knowing which is used). What is the first stage that you made sure the USB drive was in use and how did you make sure? You also have 2 U-Boot's and 2 sets of RPi* firmware: similar issues for those. What are you doing to control which is used vs. which is not? avoiding extra copies is the simplest way to be sure which started for a stage (once you get a stage to start). The order of activity is: MSDOSFS: (all on one of: microsd card vs. usb drive) RPi* firmware (I do not report the file-level sequencing) U-Boot FreeBSD loader (which uses information from U-Boot) UFS: (both: together on one of: microsd card vs. usb drive) FreeBSD kernel FreeBSD world (I do not specify which MSDOSFS is used when there are multiple viable ones in separate places. Similarly for UFS.) I word the below deliberately avoiding getting into how to control which is used when multiple copies of some things are present in various usable forms/places. (It is technically possible to have kernel vs. world in separate UFS partitions, possibly on separate media. I've an example context that I deal with that way to avoid a U-boot limitation for the device: the kernel can find the world where the U-Boot/FreeBSD-Loader can not. (The FreeBSD loader depends on what USB can find: it does not look elsewhere.) I only mention this in case I need to reference it in the future, avoiding a surprise in such a case. Otherwise ignore the complication.) You might move (not copy) the MSDOSFS material between the microsd card and the usb drive during experiments, avoiding having duplications. There is the possibility of instead renaming things so files are not found on a partition, for example. A similar point goes for UFS materials: avoid having multiple viable-for-booting UFS file systems present. As stands, things seem too hard to track for me to be of much help. Please make things obvious for what was in use by making the material uniquely placed (for the form that can be used). Separate issues/questions: Do you have the file "timeout" in the MSDOSFS, in addition to config.txt and the like? If not, I recommend including it. What other RPi* firmware controls for having various deliberate RPi* firmware delays do you have set up? It is not so much that these would be sufficient, but they do establish some context before U-Boot is even active. It could be important to understand that context. (Unsure at this point.) >> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >> (They also later mentioned using "usb_pgood_delay=3D2000\0" >> instead, a figure they found in a bunch of configrations.) >>=20 > The Pi3 in question is capable of booting from solid-state USB > storage without any microSD card, but fails to detect a mechanical > disk. Which is the appropriate u-boot-rpi3 port to tamper with? I=20 > tried sysutils/u-boot-rpi3 as an upgrade but that simply froze.=20 > The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds > the USB mechanical disk, but erratically.=20 FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 as I remember: it is set up for both the RPI3 and RPI4. Given that it works some, that would be the U-Boot port I would experiment with if I was doing the experiments. >> So something somewhat analogous might help if you are willing >> to build and use your own u-boot port variant. >=20 > Obviously, that's a fraught enterprise at my skill level.... > I'm still somewhat hazy on the actual boot sequence when > chaining from microSD to USB.=20 Having the extra text in the U-Boot build does not really depend on the chaining order question. But, to repeat (sticking to the simpler context), the order is: MSDOSFS: (all on one of: microsd card vs. usb drive) RPi* firmware (I do not report the file-level sequencing) U-Boot FreeBSD loader (which uses information from U-Boot) UFS: (both: together on one of: microsd card vs. usb drive) FreeBSD kernel FreeBSD world > Indeed, it's unclear how or if u-boot plays a role in starting=20 > RasPiOS. The term u-boot isn't found on the Raspberry Pi doc=20 > website, and the Pi isn't mentioned in the Denx manuals. Those > discoveries surprised me. RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some forms of a linux kernel directly and that is what RaspiOS and RaspiOS64 are doing. That is why the config.txt type of content makes no mention of u-boot or of any kernel=3D assignment in RaspiOS and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=3D and an explicit *u-boot*.bin as the value. By contrast to RaspiOS and RaspiOS64, Fedora chooses to use U-Boot and lists kernel=3D assignment(s), each listing a *u-boot*.bin . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 17 11:17:12 2021 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 CD1D218EA390 for ; Fri, 17 Dec 2021 11:17:18 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4JFmfQ1H16z4grt for ; Fri, 17 Dec 2021 11:17:18 +0000 (UTC) (envelope-from mindal@semihalf.com) Received: by mail-ed1-x52c.google.com with SMTP id y13so6328306edd.13 for ; Fri, 17 Dec 2021 03:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h0qsgPokLGQzgknTj23i2fawgFZkkbEUDbTNrhjKbAY=; b=yQTZxgKoUi1ovAG+P2IZqNjiAZA/JtwYc8g46c7WhI4J8F420ukg7SxzV/vcL/Hz6y zpTpjWZiJBoaIj++tKhnhiJwFzFdJrO3lCf9wKxs7uXeQQEi15K8bTx/5fIdWx5Cwk+z qbzQJGHFxU2ZDWLHTqZiXQWO7fLqo6fU318+fcld0Qooy2L1XEYlA/mYrilvcMu1v7j1 WnNdPK0KcfY3e6Z0yFx3IxFUU1DXvyAVyN4R/hnwa+K2RnOgyR05KAYB8tYGk3N/kRjm 7Z6S2O3g7Rel8b0CCWXqi6GKao+FSvl6HTDuJtSkz8C/9O/JHYNQFlqJ80iIZrIJuKnm K6RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h0qsgPokLGQzgknTj23i2fawgFZkkbEUDbTNrhjKbAY=; b=WzuVOiCYxo22f+uuPGPwpafBWsQLCflQEmC90bwj7EdGz/W87PNiRxe5119x2sjFg7 6e8hKXeV2J3N1p0lgsRV0i3B3c7jtmaOAGmx4YiYVn8aQIw8xozpcBiP0INJmz2XgvcZ zkH9cGlNTiyuOay6CcCi8O4n+2qtE6lYO0yH5T8+/BcI/k11Y3wnTP+YsCk3q5OHt4pJ Ntdv8IcTVl+CbgefY20bItatK5gBjprKiGT9n1mvP3j8Q0N0FxJGHOAsNK/KO5jsoEVX kF3ukEPBj8k0bSErcChdqzZDfv4IYDDqt9RyhHbViWcB9H9OlV+5dyuo9XtJXWZVUsP4 8L3A== X-Gm-Message-State: AOAM5331FHYlWPUZTPwOTh1mXaKGvLyojEQaxsERoPmy3npIMfoffnW6 2n7DBQ7zIvHhnUTOGOQf4DHWz7kU1uaiFTvnj98LG+QfJkZ6Fg== X-Google-Smtp-Source: ABdhPJwGe20s4sC4IDd2jyYjOl1Fd04oUzPbpckOVrOqHXYcbN8o7uqXeKSweM4KPldSYyvPBquJcrz60nacsTrxZds= X-Received: by 2002:a17:907:2d0b:: with SMTP id gs11mr2150168ejc.700.1639739836967; Fri, 17 Dec 2021 03:17:16 -0800 (PST) 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: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> In-Reply-To: From: =?UTF-8?Q?Kornel_Dul=C4=99ba?= Date: Fri, 17 Dec 2021 12:17:12 +0100 Message-ID: Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? To: Mark Millard Cc: Emmanuel Vadot , Free BSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JFmfQ1H16z4grt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=yQTZxgKo; dmarc=none; spf=none (mx1.freebsd.org: domain of mindal@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::52c) smtp.mailfrom=mindal@semihalf.com X-Spamd-Result: default: False [-2.24 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 15905 Lines: 421 > >>> [I've cut out the history: just presenting some new evidence.] > >>> > >>> First, a little context from getting to the db> prompt. > >>> > >>> db> ps > >>> pid ppid pgrp uid state wmesg wchan cmd > >>> 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] > >>> 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] > >>> 16 0 0 0 DL (threaded) [bufdaemon] > >>> 100089 D qsleep 0xffff000000ec9478 [bufdaem= on] > >>> 100092 D - 0xffff000000c11100 [bufspac= edaemon-0] > >>> 100093 D - 0xffff000000c21680 [bufspac= edaemon-1] > >>> 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] > >>> 8 0 0 0 DL (threaded) [pagedaemon= ] > >>> 100087 D psleep 0xffff000000ee2b38 [dom0] > >>> 100094 D launds 0xffff000000ee2b44 [laundry= : dom0] > >>> 100095 D umarcl 0xffff0000007b38d8 [uma] > >>> 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 [mmcsd0boot= 1: mmc/sd] > >>> 6 0 0 0 DL mmcsd d 0xffffa00007b71300 [mmcsd0boot= 0: mmc/sd] > >>> 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: mm= c/sd card] > >>> 4 0 0 0 DL - 0xffff000000ccc020 [rand_harve= stq] > >>> 15 0 0 0 DL (threaded) [usb] > >>> . . . > >>> > >>> and "mmcreq" is from the while loop in: > >>> > >>> static int > >>> mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) > >>> { > >>> > >>> req->done =3D mmc_wakeup; > >>> req->done_data =3D sc; > >>> if (__predict_false(mmc_debug > 1)) { > >>> device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags %#x= ", > >>> req->cmd->opcode, req->cmd->arg, req->cmd->flags); > >>> if (req->cmd->data) { > >>> printf(" data %d\n", (int)req->cmd->data->len); > >>> } else > >>> printf("\n"); > >>> } > >>> MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); > >>> MMC_LOCK(sc); > >>> while ((req->flags & MMC_REQ_DONE) =3D=3D 0) > >>> msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); > >>> MMC_UNLOCK(sc); > >>> if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && > >>> req->cmd->error !=3D MMC_ERR_NONE))) > >>> device_printf(sc->dev, "CMD%d RESULT: %d\n", > >>> req->cmd->opcode, req->cmd->error); > >>> return (0); > >>> } > >>> > >>> So it appears that the error report: > >>> > >>> mmcsd0: Error indicated: 4 Failed > >>> > >>> ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying > >>> true in the above code: an unbounded loop with MMC_LOCK(sc) active. > >>> The "4" in the error report seems to be from: > >>> > >>> #define MMC_ERR_FAILED 4 > >>> > >>> It looks like there are some problems with handling errors, problems > >>> such that it gets stuck looping (no panic, no progress). > >>> > >>> That seems to be separate from why the MMC_ERR_FAILED was generated > >>> in the first place. So: 2 problems, not just one. Thus it may be a > >>> good context for tackling the looping problem with a known example > >>> failure to look at. > >>> > >>> > >>> > >>> Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 = in place, > >>> just to capture and report the tail of the output for the boot failur= e. > >>> > >>> . . . > >>> subsystem f000000 > >>> release_aps(0)... Release APs...done > >>> done. > >>> intr_irq_shuffle(0)... Trying to mount root from ufs:/dev/gpt/Rock64r= oot []... > >>> done. > >>> netisr_start(0)... done. > >>> taskqgroup_bind_softirq(0)... done. > >>> GEOM: new disk mmcsd0 > >>> GEOM: new disk mmcsd0boot0 > >>> GEOM: new disk mmcsd0boot1 > >>> smp_after_idle_runnable(0)... done. > >>> taskqgroup_bind_if_config_tqg(0)... done. > >>> taskqgroup_bind_if_io_tqg(0)... done. > >>> tmr_setup_user_access(0)... done. > >>> subsystem f000001 > >>> mmcsd0: Error indicated: 4 Failed > >>> epoch_init_smp(0)... done. > >>> subsystem f100000 > >>> racctd_init(0)... done. > >>> subsystem fffffff > >>> start_periodic_resettodr(0)... done. > >>> oktousecallout(0)... done. > >>> clknode_finish(0)... Unresolved linked clock found: hdmi_phy > >>> Unresolved linked clock found: usb480m_phy > >>> done. > >>> regulator_constraint(0)... done. > >>> regulator_shutdown(0)... regulator: shutting down unused regulators > >>> regulator: shutting down vcc_sd... busy > >>> done. > >>> uhub0: 1 port with 1 removable, self powered > >>> uhub2: 2 ports with 2 removable, self powered > >>> uhub3: 1 port with 1 removable, self powered > >>> uhub1: 1 port with 1 removable, self powered > >>> ugen4.2: at usbus4 > >>> umass0 on uhub2 > >>> umass0: on = usbus4 > >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > >>> umass0:0:0: Attached to scbus0 > >>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> pass0: Fixed Direct Access SPC-4 SCSI devic= e > >>> pass0: Serial Number REPLACED > >>> pass0: 400.000MB/s transfers > >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > >>> da0: Fixed Direct Access SPC-4 SCSI device > >>> da0: Serial Number REPLACED > >>> da0: 400.000MB/s transfers > >>> da0: 953869MB (1953525168 512 byte sectors) > >>> da0: quirks=3D0x2 > >>> da0: Delete methods: > >>> random: unblocking device. > >>> > >>> No more output after that. > >> > >> As for why MMC_ERR_FAILED results, the following code diff is > >> intended to suggest what I think may be incomplete about sticking > >> to what the device-specific code supports vs. does not support > >> (not supporting HS200 here). The code does compile in my context > >> but is untested. > > > > It is now tested (at least to be a useful hack): no longer am I > > running an older 1400042 kernel. For reference, > > > > # uname -apKU > > FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #18 main= -n251456-22c4ab6cb015-dirty: Sun Dec 12 00:34:53 PST 2021 root@CA72_16G= p_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/= GENERIC-NODBG-CA53 arm64 aarch64 1400043 1400043 > > > > And it reports during the boot (other than the "REPLACED"): > > > > mmcsd0: 125GB a= t mmc0 52.0MHz/8bit/1016-block > > > > So it no longer sets up a mode that the rk3328-specific-code does not > > actually support. > > > > (Nothing that I've done here deals with the looping issue when there > > is a MMC_ERR_FAILED or the like.) > > > >> The email handling may mess up some leading > >> whitespace --but, again, I'm only trying to suggest a type of > >> change. > >> > >> # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc > >> diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c > >> index 9c73dfd57ce0..dffd1c382684 100644 > >> --- a/sys/dev/mmc/mmc.c > >> +++ b/sys/dev/mmc/mmc.c > >> @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing timing) > >> static bool > >> mmc_host_timing(device_t dev, enum mmc_bus_timing timing) > >> { > >> + kobjop_desc_t kobj_desc; > >> + kobj_method_t *kobj_method; > >> int host_caps; > >> > >> host_caps =3D mmcbr_get_caps(dev); > >> @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum mmc_bus_tim= ing timing) > >> case bus_timing_mmc_ddr52: > >> return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); > >> case bus_timing_mmc_hs200: > >> - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS200_1= 20) || > >> - HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS200_1= 80)); > >> case bus_timing_mmc_hs400: > >> - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400_1= 20) || > >> - HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400_1= 80)); > >> case bus_timing_mmc_hs400es: > >> - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 | > >> - MMC_CAP_MMC_ENH_STROBE)); > >> + /* > >> + * Disable eMMC modes that require use of > >> + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if eit= her the > >> + * tune or re-tune method is the default NULL implemen= tation. > >> + */ > >> + kobj_desc =3D &mmcbr_tune_desc; > >> + kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops-= >cls, NULL, > >> + kobj_desc); > >> + if (kobj_method =3D=3D &kobj_desc->deflt) > >> + return (false); > >> + kobj_desc =3D &mmcbr_retune_desc; > >> + kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops-= >cls, NULL, > >> + kobj_desc); > >> + if (kobj_method =3D=3D &kobj_desc->deflt) { > >> + return (false); > >> + } > >> + > >> + /* > >> + * Otherwise track the host capabilities. > >> + */ > >> + if (timing =3D=3D bus_timing_mmc_hs200) > >> + return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC= _HS200_120) || > >> + HOST_TIMING_CAP(host_caps, MMC_CAP_MMC= _HS200_180)); > >> + if (timing =3D=3D bus_timing_mmc_hs400) > >> + return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC= _HS400_120) || > >> + HOST_TIMING_CAP(host_caps, MMC_CAP_MMC= _HS400_180)); > >> + if (timing =3D=3D bus_timing_mmc_hs400es) > >> + return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC= _HS400 | > >> + MMC_CAP_MMC_ENH_STROBE)); > >> } > >> > >> #undef HOST_TIMING_CAP > >> > >> > >> In other words: have mmc_host_timing avoid returning true for some > >> combinations that definitely do not have sufficient software support > >> present at the time. (So far as I can tell, the rk3328's get the > >> NULL-implementations as things are.) > >> > >> I expect that this sort of thing would go back to using > >> MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in a > >> slower mode, the same mode as FreeBSD was previously using. > >> > >> A possible incompleteness in the suggestion is that there is also a > >> drive-strength setting involved. If that also had "kobj" interfacing > >> and NULL-implementation possibilities, then in the future there would > >> be more to test for possibly forcing return-false than I did above. > >> > >> Hopefully this sort of thing would help, possibly more than just for > >> rk3328's. > > > > > > As for what was happening without my patch . . . > > sys/dev/mmc/mmcbr_if.m defines: > > static int > null_retune(device_t brdev __unused, device_t reqdev __unused, > bool reset __unused) > { > > return (0); > } > > static int > null_tune(device_t brdev __unused, device_t reqdev __unused, > bool hs400 __unused) > { > > return (0); > } > . . . > # > # Called by the mmcbus with the bridge claimed to execute initial tuning. > # > METHOD int tune { > device_t brdev; > device_t reqdev; > bool hs400; > } DEFAULT null_tune; > > # > # Called by the mmcbus with the bridge claimed to execute re-tuning. > # > METHOD int retune { > device_t brdev; > device_t reqdev; > bool reset; > } DEFAULT null_retune; > . . . > > It is these success-reporting no-op routines that were being > used to attempt the tuning: so there was no tuning done. > > The code that I added detects that these routines would be > used and avoids allowing contexts that would involve putting > them to use with HS200 mode. > > I'll note that there is another such null_* routine that the > code (even with my patch) does not deal with avoiding the use > of: > > . . . > static int > null_switch_vccq(device_t brdev __unused, device_t reqdev __unuse= d) > { > > return (0); > } > . . . > # > # Called by the mmcbus to switch the signaling voltage (VCCQ). > # > METHOD int switch_vccq { > device_t brdev; > device_t reqdev; > } DEFAULT null_switch_vccq; > . . . > > /usr/main-src/sys/dev/sdhci/sdhci.c has somewhat analogous code for > somewhat analogous null_* routines. null_set_uhs_timing for that is > from sys/dev/sdhci/sdhci_if.m (but the other two are again the above > null_tune and null_retune routines, so not repeated here): > > . . . > static void > null_set_uhs_timing(device_t brdev __unused, > struct sdhci_slot *slot __unused) > { > > } > . . . > METHOD void set_uhs_timing { > device_t brdev; > struct sdhci_slot *slot; > } DEFAULT null_set_uhs_timing; > . . . > > sdhci_init_slot(device_t dev, struct sdhci_slot *slot, int num) > in sdhci.c looks like (in part): > > . . . > /* > * Disable UHS-I and eMMC modes if the set_uhs_timing method is t= he > * default NULL implementation. > */ > kobj_desc =3D &sdhci_set_uhs_timing_desc; > kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, > kobj_desc); > if (kobj_method =3D=3D &kobj_desc->deflt) > host_caps &=3D ~(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | > MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_S= DR104 | > MMC_CAP_MMC_DDR52 | MMC_CAP_MMC_HS200 | MMC_CAP_MMC_H= S400); > > #define SDHCI_CAP_MODES_TUNING(caps2) \ > (((caps2) & SDHCI_TUNE_SDR50 ? MMC_CAP_UHS_SDR50 : 0) | \ > MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_HS200 | \ > MMC_CAP_MMC_HS400) > > /* > * Disable UHS-I and eMMC modes that require (re-)tuning if eithe= r > * the tune or re-tune method is the default NULL implementation. > */ > kobj_desc =3D &mmcbr_tune_desc; > kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, > kobj_desc); > if (kobj_method =3D=3D &kobj_desc->deflt) > goto no_tuning; > kobj_desc =3D &mmcbr_retune_desc; > kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, > kobj_desc); > if (kobj_method =3D=3D &kobj_desc->deflt) { > no_tuning: > host_caps &=3D ~(SDHCI_CAP_MODES_TUNING(caps2)); > } > . . . > > What I've done in my patch is analogous to what the the code shown > after the #define SDHCI_CAP_MODES_TUNING above does, translated to > fit the mmc's pre-existing code structure. Good catch. For some reason mmcbr_tune/mmcbr_retune are not implemented in sdhci_fdt.c. This looks like a separate bug/issue. Note that pretty much all other SDHCI drivers (sdhci_pci.c, sdhci_xenon.c, sdhci_fsl_fdt.c, sdhci_acpi.c) provide some implementation of mmcbr_tune/mmcbr_retune. I agree that the logic in sdhci.c should disable HS200 if those methods are implemented. Could you try hooking mmcbr_tune and mmcbr_retune to their generic sdhci implementations? If we're lucky this could be enough to make HS200 work on rock64, though it's unlikely. From nobody Fri Dec 17 15:49:30 2021 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 0500818F5B13 for ; Fri, 17 Dec 2021 15:49:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFthm3LYpz3tnr for ; Fri, 17 Dec 2021 15:49:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639756175; bh=naWhg+xkEidC+x3oVCm4F9VwMwXJan3BlUfShKZg6II=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eDw8MoxUeu+gkbX7LYBc+swHpheD0p57DcHZsDSt1ctWhxG0DmpvefnovNQRAyaW90RJYluigraUlEVIY2IFsmAVQ/qPccriv3sU1Y7UvpFe46v0Dua0KhCfYEGVuDCDG14f0vkdltXIKKN6OeYpCavWnO9MEoxh9qbz0J1lWtLNzbcvJYQ3PACwz+EHauC8CRNpF/jpWNRnP3XBescBVBwaIt2y8/11dEiDqBhPTBZLQYNKQlOS2nF+iWGkZ6fvhuloTnOleVeMZ2UqICnXdmOk0tbQitb8lQB3kPo/fF0sJ/IAFsiDKqkWAuXoShkWMRnIq9i3uC9j/qA2O1TDPA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639756175; bh=mmq8HC0YcBVd5CtLU/VjAh7IGLn2cQD07cibiPQGxXr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e62PPnVMqfONzJAmpNIq3+aqTyzY7PtH0c3txnQNoimMkiJDfFSqscYSnsBEvuB/6aldSLtMw1siZPvc5OrK00G6x7V0KJ/1Ms8SruhuPSeKdnfl6grw43N97utoktZLWjMnqeuAHB7/3WbqgHwnCL378dWBexa7vXvNkJufiBExMtq4SPCIKVuHaBQt3SNdOb1hQBaH0S6LieF83pZryetYps2GKoN/pqM45RAvgJ9i92ZYWbpclNbbvKxeRtL1y3Y/2E3JewQtliI/rKH1N2joTzd7m77WKwITgT2XbiAymL+GpD5ZOTKLmf1QDTfTgy4wGiK1vtErX9TcPNr6AA== X-YMail-OSG: YcVK.vkVM1lqLqLgXQ7S1OUI6UOaML.R3qV5On7Drp40AfHhVI5Z4goz7uP3CTb jjdrbMKqhMlku_fD2PBkzEkgNMIKxhboxDpxQKUvbh7JICOilgSPPWV67xGWjbL_3UakPtJdYszz Yq96P02Ixlm6sifVM26MBhUrDtYQdOCy3TIWPVmLt8EK3UBqsxGoGoWgNxIPU6xamWdpX1fZ7_ft BznetgHa05la0kZFHFq2we4SJxXs4Vr2zMg7tvp5Y7_h65Z97QTdWZ3MwcW.c7TE_8fZ.gttmj_c VEHNgrUl3xAqCsceuAldRMqzx9NkJF2k8iF9UjiTwFbDgAKDa0R5lJVyRHF8UanL8gdJf0GzU0dp u0mCeCdjtPuqOCaBh_enaWKzrCUKodQiKsVSaW7YUWGSB5yMbkCREaiZ52jT1JDS5CDdSaqdx3dB InHlnVdKt.r.pyRMOKIF8XYGlVlmQLiVK532tONXgbPYjlQhjR6h2_j8tAtC6.JV9CNqQEZ1h1nG VLw1z0xNq6uuNk9YNUhPfrg_FRdctlXyQIz._avggWE3zGvZ_DBuMt_h_DYu916LqOw2Dc7rvNBy ggUjBP_m.fh2Bmhg1lDmKtogUB2GaiSxUvLHHVLBf8SI.2StRXde.94aRXTDOd1JzshpgD2kxo8H QxkUPPHkLVTNAHDV5BQ24A3uwL1__eXo71DbUGDjneeNJh7V4rkpXjxa.l5af8X28VXXRP25z_ra z9slotmJ9jef9GZ7_crsiF5fQGSmoayRu.I4.B22UQfvNJzBsgMMon_55UH4_hIb4l.2rHctsShz y9QCsUnDdB0g7tpupexKhjdu18ZRXWuMsEKmT9cUm0ZEJB6pn71l8DVLDue1oaWxHnRrdN2zsOlW RCu4dOuZL6sM.Cy4ppVofBdXWdl_dZfKbMXgiuX.31CZci8XH8I6.aLvEmvLjo1BVVIQdU4xqU7Z QFiyAYjGSak_lA4ld5zYMsRz0jNB.M7b9UHqhqQMr.pCuSd24b6D65fM7oW9PFKbLqs3mO5s2hFR XxdyQ15uZ9XGX2YeBEDJJ.qfIbEUNlkHvBu.c3N0vvpzzVUQbhwOjnQuTd.wjoj4N2BXLHpEAfwe iKRTnsdBz.hgNciGBlR5cqGwCRHKNekxFMACLBUKyB6HIQLDUj3ZOY0LyIW14Cf1K8YLwM7SeMfz 2LIwllre8Dji8h964Q6G.ctY1tYsW5unMkdWZysbzOw0ccV7nZAtHd7z4OJ.5cC6vA7Xk49Jz8Rt jSCy4Pgs13zbfh2RKa_EL2EPH6OcEovIGhI9jezeD_a_zZJwEfk_GbTQOnl8vPBIbOAwt_IZ.iHn kRGG.9s49ONherQ1NxLVUtArw5s2VkR90sWnmlNm8knYWuyHOpkIXa1E6XVfrkyf0dXKTruJEknL .G4Zpx26JLUS0YqH6jX70TK5U4CzCwWurFsHOc2VP8mAZdEdadx51PF9YHS1rrN0h54ZlxRObx2W YWIG6a_UpCIcEd2p_gwfM35fm3I25nudseztT5MEE0tTWCWiIoagrS8beWYikr52Obd0mIjshVq5 viTG41RA1eEn6RSnoBjL069C2Huc2T1waOUQPD9TE4T28zdD7bOXBftqwAYAIINldLcueSuIM.Mv cYLH9Wv2cF5k4tA7vXxTVXZ4iR4w8uefF_9qpSoPUAVKBJdjKSDD62BHGHbhb.2P11ightBQrY.W ysk51OwXkr1wsscwUU4FJL8NeSR2Nzc2JYMx2cbPJNPy_DakY82S8hdTSBp_T9GZRq8NrDYWL881 epL27zII1_NHR53yFI93zEneDQQ7oXJMIxoTvsbj14.iha7aHR39qOuHMx8U3zMrVIvzEBfduCu7 9Q5LuLwsyskIAhbiq0.Wzc5wb5CLGo5PaQ.4ACOUtq94GAtlZ_FLDxDgxNzOgsNJ6eU.2gvD1SeU p_TS42G7atizC_9VvAkIMbUHY_0xL.4A51fni.K9WQ7oJaqEHeXj3lcrgLrU20O6whoj4dVAzFwy LTtJYQe06W_GSx8rRRN8yyiyd_lTnm2yERCTfVKtgjkab4oi_4KRA.np7PhjI2xDEyWA6XYi4Qsj 8VDtAu8HoKelj1xWC71bn9zJBF_MNRH3SLECX19SoHZWkDm7zqAsDyVFPYI2yb5H4exVBec6kmLN dU9SEAdNydWh8XxxTb1HsEIULQZmyOdendsA6YL0.YWSWuHQlt9FJq9RrjpDFDWSgC1Ur6diP6IR 8RGmVpbK108abbbKXAjsg2hQglBLVh8nMjGxS.UWMZGVPh3u.oALDpZFHvdCfgOcWMWWL3cE13._ cxC_bizTReCnkzZ1FEkM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Dec 2021 15:49:35 +0000 Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f25d025290411deee803fdd8ab34476e; Fri, 17 Dec 2021 15:49:32 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: Date: Fri, 17 Dec 2021 07:49:30 -0800 Cc: Emmanuel Vadot , Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <27734923-C09E-429A-B54C-5123AEC37641@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JFthm3LYpz3tnr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 17035 Lines: 474 On 2021-Dec-17, at 03:17, Kornel Dul=C4=99ba = wrote: >>>>> [I've cut out the history: just presenting some new evidence.] >>>>>=20 >>>>> First, a little context from getting to the db> prompt. >>>>>=20 >>>>> db> ps >>>>> pid ppid pgrp uid state wmesg wchan cmd >>>>> 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] >>>>> 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] >>>>> 16 0 0 0 DL (threaded) = [bufdaemon] >>>>> 100089 D qsleep 0xffff000000ec9478 = [bufdaemon] >>>>> 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] >>>>> 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] >>>>> 9 0 0 0 DL psleep 0xffff000000ef0650 = [vmdaemon] >>>>> 8 0 0 0 DL (threaded) = [pagedaemon] >>>>> 100087 D psleep 0xffff000000ee2b38 = [dom0] >>>>> 100094 D launds 0xffff000000ee2b44 = [laundry: dom0] >>>>> 100095 D umarcl 0xffff0000007b38d8 [uma] >>>>> 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] >>>>> 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] >>>>> 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] >>>>> 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] >>>>> 15 0 0 0 DL (threaded) [usb] >>>>> . . . >>>>>=20 >>>>> and "mmcreq" is from the while loop in: >>>>>=20 >>>>> static int >>>>> mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) >>>>> { >>>>>=20 >>>>> req->done =3D mmc_wakeup; >>>>> req->done_data =3D sc; >>>>> if (__predict_false(mmc_debug > 1)) { >>>>> device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", >>>>> req->cmd->opcode, req->cmd->arg, req->cmd->flags); >>>>> if (req->cmd->data) { >>>>> printf(" data %d\n", = (int)req->cmd->data->len); >>>>> } else >>>>> printf("\n"); >>>>> } >>>>> MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); >>>>> MMC_LOCK(sc); >>>>> while ((req->flags & MMC_REQ_DONE) =3D=3D 0) >>>>> msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); >>>>> MMC_UNLOCK(sc); >>>>> if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && >>>>> req->cmd->error !=3D MMC_ERR_NONE))) >>>>> device_printf(sc->dev, "CMD%d RESULT: %d\n", >>>>> req->cmd->opcode, req->cmd->error); >>>>> return (0); >>>>> } >>>>>=20 >>>>> So it appears that the error report: >>>>>=20 >>>>> mmcsd0: Error indicated: 4 Failed >>>>>=20 >>>>> ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 = staying >>>>> true in the above code: an unbounded loop with MMC_LOCK(sc) = active. >>>>> The "4" in the error report seems to be from: >>>>>=20 >>>>> #define MMC_ERR_FAILED 4 >>>>>=20 >>>>> It looks like there are some problems with handling errors, = problems >>>>> such that it gets stuck looping (no panic, no progress). >>>>>=20 >>>>> That seems to be separate from why the MMC_ERR_FAILED was = generated >>>>> in the first place. So: 2 problems, not just one. Thus it may be a >>>>> good context for tackling the looping problem with a known example >>>>> failure to look at. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1= in place, >>>>> just to capture and report the tail of the output for the boot = failure. >>>>>=20 >>>>> . . . >>>>> subsystem f000000 >>>>> release_aps(0)... Release APs...done >>>>> done. >>>>> intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... >>>>> done. >>>>> netisr_start(0)... done. >>>>> taskqgroup_bind_softirq(0)... done. >>>>> GEOM: new disk mmcsd0 >>>>> GEOM: new disk mmcsd0boot0 >>>>> GEOM: new disk mmcsd0boot1 >>>>> smp_after_idle_runnable(0)... done. >>>>> taskqgroup_bind_if_config_tqg(0)... done. >>>>> taskqgroup_bind_if_io_tqg(0)... done. >>>>> tmr_setup_user_access(0)... done. >>>>> subsystem f000001 >>>>> mmcsd0: Error indicated: 4 Failed >>>>> epoch_init_smp(0)... done. >>>>> subsystem f100000 >>>>> racctd_init(0)... done. >>>>> subsystem fffffff >>>>> start_periodic_resettodr(0)... done. >>>>> oktousecallout(0)... done. >>>>> clknode_finish(0)... Unresolved linked clock found: hdmi_phy >>>>> Unresolved linked clock found: usb480m_phy >>>>> done. >>>>> regulator_constraint(0)... done. >>>>> regulator_shutdown(0)... regulator: shutting down unused = regulators >>>>> regulator: shutting down vcc_sd... busy >>>>> done. >>>>> uhub0: 1 port with 1 removable, self powered >>>>> uhub2: 2 ports with 2 removable, self powered >>>>> uhub3: 1 port with 1 removable, self powered >>>>> uhub1: 1 port with 1 removable, self powered >>>>> ugen4.2: at usbus4 >>>>> umass0 on uhub2 >>>>> umass0: = on usbus4 >>>>> umass0: SCSI over Bulk-Only; quirks =3D 0x0000 >>>>> umass0:0:0: Attached to scbus0 >>>>> pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> pass0: Fixed Direct Access SPC-4 SCSI = device >>>>> pass0: Serial Number REPLACED >>>>> pass0: 400.000MB/s transfers >>>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>>>> da0: Fixed Direct Access SPC-4 SCSI = device >>>>> da0: Serial Number REPLACED >>>>> da0: 400.000MB/s transfers >>>>> da0: 953869MB (1953525168 512 byte sectors) >>>>> da0: quirks=3D0x2 >>>>> da0: Delete methods: >>>>> random: unblocking device. >>>>>=20 >>>>> No more output after that. >>>>=20 >>>> As for why MMC_ERR_FAILED results, the following code diff is >>>> intended to suggest what I think may be incomplete about sticking >>>> to what the device-specific code supports vs. does not support >>>> (not supporting HS200 here). The code does compile in my context >>>> but is untested. >>>=20 >>> It is now tested (at least to be a useful hack): no longer am I >>> running an older 1400042 kernel. For reference, >>>=20 >>> # uname -apKU >>> FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n251456-22c4ab6cb015-dirty: Sun Dec 12 00:34:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400043 1400043 >>>=20 >>> And it reports during the boot (other than the "REPLACED"): >>>=20 >>> mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block >>>=20 >>> So it no longer sets up a mode that the rk3328-specific-code does = not >>> actually support. >>>=20 >>> (Nothing that I've done here deals with the looping issue when there >>> is a MMC_ERR_FAILED or the like.) >>>=20 >>>> The email handling may mess up some leading >>>> whitespace --but, again, I'm only trying to suggest a type of >>>> change. >>>>=20 >>>> # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc >>>> diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c >>>> index 9c73dfd57ce0..dffd1c382684 100644 >>>> --- a/sys/dev/mmc/mmc.c >>>> +++ b/sys/dev/mmc/mmc.c >>>> @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); >>>> #include >>>> #include >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing = timing) >>>> static bool >>>> mmc_host_timing(device_t dev, enum mmc_bus_timing timing) >>>> { >>>> + kobjop_desc_t kobj_desc; >>>> + kobj_method_t *kobj_method; >>>> int host_caps; >>>>=20 >>>> host_caps =3D mmcbr_get_caps(dev); >>>> @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) >>>> case bus_timing_mmc_ddr52: >>>> return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_DDR52)); >>>> case bus_timing_mmc_hs200: >>>> - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || >>>> - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); >>>> case bus_timing_mmc_hs400: >>>> - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || >>>> - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); >>>> case bus_timing_mmc_hs400es: >>>> - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | >>>> - MMC_CAP_MMC_ENH_STROBE)); >>>> + /* >>>> + * Disable eMMC modes that require use of >>>> + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the >>>> + * tune or re-tune method is the default NULL = implementation. >>>> + */ >>>> + kobj_desc =3D &mmcbr_tune_desc; >>>> + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, >>>> + kobj_desc); >>>> + if (kobj_method =3D=3D &kobj_desc->deflt) >>>> + return (false); >>>> + kobj_desc =3D &mmcbr_retune_desc; >>>> + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, >>>> + kobj_desc); >>>> + if (kobj_method =3D=3D &kobj_desc->deflt) { >>>> + return (false); >>>> + } >>>> + >>>> + /* >>>> + * Otherwise track the host capabilities. >>>> + */ >>>> + if (timing =3D=3D bus_timing_mmc_hs200) >>>> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || >>>> + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); >>>> + if (timing =3D=3D bus_timing_mmc_hs400) >>>> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || >>>> + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); >>>> + if (timing =3D=3D bus_timing_mmc_hs400es) >>>> + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | >>>> + MMC_CAP_MMC_ENH_STROBE)); >>>> } >>>>=20 >>>> #undef HOST_TIMING_CAP >>>>=20 >>>>=20 >>>> In other words: have mmc_host_timing avoid returning true for some >>>> combinations that definitely do not have sufficient software = support >>>> present at the time. (So far as I can tell, the rk3328's get the >>>> NULL-implementations as things are.) >>>>=20 >>>> I expect that this sort of thing would go back to using >>>> MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in = a >>>> slower mode, the same mode as FreeBSD was previously using. >>>>=20 >>>> A possible incompleteness in the suggestion is that there is also a >>>> drive-strength setting involved. If that also had "kobj" = interfacing >>>> and NULL-implementation possibilities, then in the future there = would >>>> be more to test for possibly forcing return-false than I did above. >>>>=20 >>>> Hopefully this sort of thing would help, possibly more than just = for >>>> rk3328's. >>>=20 >>>=20 >>=20 >> As for what was happening without my patch . . . >>=20 >> sys/dev/mmc/mmcbr_if.m defines: >>=20 >> static int >> null_retune(device_t brdev __unused, device_t reqdev __unused, >> bool reset __unused) >> { >>=20 >> return (0); >> } >>=20 >> static int >> null_tune(device_t brdev __unused, device_t reqdev __unused, >> bool hs400 __unused) >> { >>=20 >> return (0); >> } >> . . . >> # >> # Called by the mmcbus with the bridge claimed to execute initial = tuning. >> # >> METHOD int tune { >> device_t brdev; >> device_t reqdev; >> bool hs400; >> } DEFAULT null_tune; >>=20 >> # >> # Called by the mmcbus with the bridge claimed to execute re-tuning. >> # >> METHOD int retune { >> device_t brdev; >> device_t reqdev; >> bool reset; >> } DEFAULT null_retune; >> . . . >>=20 >> It is these success-reporting no-op routines that were being >> used to attempt the tuning: so there was no tuning done. >>=20 >> The code that I added detects that these routines would be >> used and avoids allowing contexts that would involve putting >> them to use with HS200 mode. >>=20 >> I'll note that there is another such null_* routine that the >> code (even with my patch) does not deal with avoiding the use >> of: >>=20 >> . . . >> static int >> null_switch_vccq(device_t brdev __unused, device_t reqdev = __unused) >> { >>=20 >> return (0); >> } >> . . . >> # >> # Called by the mmcbus to switch the signaling voltage (VCCQ). >> # >> METHOD int switch_vccq { >> device_t brdev; >> device_t reqdev; >> } DEFAULT null_switch_vccq; >> . . . >>=20 >> /usr/main-src/sys/dev/sdhci/sdhci.c has somewhat analogous code for >> somewhat analogous null_* routines. null_set_uhs_timing for that is >> from sys/dev/sdhci/sdhci_if.m (but the other two are again the above >> null_tune and null_retune routines, so not repeated here): >>=20 >> . . . >> static void >> null_set_uhs_timing(device_t brdev __unused, >> struct sdhci_slot *slot __unused) >> { >>=20 >> } >> . . . >> METHOD void set_uhs_timing { >> device_t brdev; >> struct sdhci_slot *slot; >> } DEFAULT null_set_uhs_timing; >> . . . >>=20 >> sdhci_init_slot(device_t dev, struct sdhci_slot *slot, int num) >> in sdhci.c looks like (in part): >>=20 >> . . . >> /* >> * Disable UHS-I and eMMC modes if the set_uhs_timing method = is the >> * default NULL implementation. >> */ >> kobj_desc =3D &sdhci_set_uhs_timing_desc; >> kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, >> kobj_desc); >> if (kobj_method =3D=3D &kobj_desc->deflt) >> host_caps &=3D ~(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 = | >> MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | = MMC_CAP_UHS_SDR104 | >> MMC_CAP_MMC_DDR52 | MMC_CAP_MMC_HS200 | = MMC_CAP_MMC_HS400); >>=20 >> #define SDHCI_CAP_MODES_TUNING(caps2) = \ >> (((caps2) & SDHCI_TUNE_SDR50 ? MMC_CAP_UHS_SDR50 : 0) | = \ >> MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_HS200 | = \ >> MMC_CAP_MMC_HS400) >>=20 >> /* >> * Disable UHS-I and eMMC modes that require (re-)tuning if = either >> * the tune or re-tune method is the default NULL = implementation. >> */ >> kobj_desc =3D &mmcbr_tune_desc; >> kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, >> kobj_desc); >> if (kobj_method =3D=3D &kobj_desc->deflt) >> goto no_tuning; >> kobj_desc =3D &mmcbr_retune_desc; >> kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, >> kobj_desc); >> if (kobj_method =3D=3D &kobj_desc->deflt) { >> no_tuning: >> host_caps &=3D ~(SDHCI_CAP_MODES_TUNING(caps2)); >> } >> . . . >>=20 >> What I've done in my patch is analogous to what the the code shown >> after the #define SDHCI_CAP_MODES_TUNING above does, translated to >> fit the mmc's pre-existing code structure. >=20 > Good catch. For some reason mmcbr_tune/mmcbr_retune are not > implemented in sdhci_fdt.c. > This looks like a separate bug/issue. > Note that pretty much all other SDHCI drivers (sdhci_pci.c, > sdhci_xenon.c, sdhci_fsl_fdt.c, sdhci_acpi.c) provide some > implementation of mmcbr_tune/mmcbr_retune. > I agree that the logic in sdhci.c should disable HS200 if those > methods are implemented. > Could you try hooking mmcbr_tune and mmcbr_retune to their generic > sdhci implementations? What valid generic sdhci implementations? There is no such thing as far as I can tell. JESD84-B51 (e.MMC v5.1's standard) does nothing to standardize how adjustments are made during HS200 tuning, beyond how to get a known-pattern to test against (via: CMD21). That, of itself, does not make any adjustments. Also, as far as I can tell, the mmc that I changed and the sdhci code quoted above are independent at run-time. One or the other is used, not both. Otherwise the above quoted code would have prevented HS200 from being attempted. > If we're lucky this could be enough to make HS200 work on rock64, > though it's unlikely. I do not see that there is any generic sdhci tuning code to enable the use of: just avoiding use of code that is a no-op that falsely indicates success by avoiding needing HS200 tuning. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 18 00:59:46 2021 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 2E40A18F44BC for ; Sat, 18 Dec 2021 00:59:49 +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 4JG6vS59NLz4j14 for ; Sat, 18 Dec 2021 00:59:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BI0xlqi008840 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 16:59:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BI0xl90008839; Fri, 17 Dec 2021 16:59:47 -0800 (PST) (envelope-from fbsd) Date: Fri, 17 Dec 2021 16:59:46 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Saving environment variables in u-boot Message-ID: <20211218005946.GA7670@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> 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: 4JG6vS59NLz4j14 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9617 Lines: 273 On Thu, Dec 16, 2021 at 11:00:46PM -0800, Mark Millard wrote: > On 2021-Dec-16, at 17:36, bob prohaska wrote: > > > > > Yes, the microSD contains a dd of > > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img > > The DOS partition is writeable, AFAIK. > > Hmm. That means there is also a UFS root with > a kernel and world on the microsd card. Both > the microsd card and the USB drive contain > contain such, as well as each having an > /etc/fstab (and so on). > > Having multiple such makes for a mess for > controlling which is used (and knowing which > is used). What is the first stage that you > made sure the USB drive was in use and how > did you make sure? > I installed a microSD containing only the FAT slice from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img, the FreeBSD slice being deleted using gpart. There is a timeout file. A hands-off warm boot reports resetting system ... U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) DRAM: 948 MiB RPI 3 Model B (0xa02082) MMC: mmc@7e300000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... 5 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk mmc@7e300000.blk... Found 2 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 1259212 bytes read in 125 ms (9.6 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi [whitespace deleted] Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0x39e03000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f,0x18fa8) Setting currdev to disk0p1: ERROR: cannot open /boot/lua/loader.lua: no such file or directory. Type '?' for a list of commands, 'help' for more detailed help. OK AIUI, disk0p1 is the microSD, which has no /boot/lua/loader.lua That makes sense. If u-boot finds the USB mass storage device then running run bootcmd_usb0 starts the system successfully. It does appear that the FAT partition on the USB disk is involved. If I hide the contents of da0s1 by placing them in a subdirectory the boot fails, even if u-boot has found the USB disk: Hit any key to stop autoboot: 0 U-Boot> usb reset resetting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found [Note that the six devices include the disk, it can be seen in usb tree. For some reason it isn't recognized as a mass storage device.] U-Boot> editenv usb_pgood_delay edit: 2 U-Boot> usb reset resetting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found U-Boot> run bootcmd_usb0 Device 0: Vendor: SABRENT Rev: 1214 Prod: Type: Hard Disk Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512) ... is now current device Scanning usb 0:1... U-Boot> and there it stops. Looks like both FAT partitions have a role to play. An earlier experiment tried booting the microSD card in a USB adapter, That worked correctly with nothing in the microSD slot, so the internal "boot from USB" feature might work if it could be slowed down sufficiently. > > The order of activity is: > > MSDOSFS: (all on one of: microsd card vs. usb drive) > RPi* firmware (I do not report the file-level sequencing) > U-Boot > FreeBSD loader (which uses information from U-Boot) > > UFS: (both: together on one of: microsd card vs. usb drive) > FreeBSD kernel > FreeBSD world > > (I do not specify which MSDOSFS is used when > there are multiple viable ones in separate places. > Similarly for UFS.) > >From the experiment today it seems both are required. The first discovers the USB disk, the second uses that information to proceed further. > > (It is technically possible to have kernel vs. > world in separate UFS partitions, possibly on > separate media. I've an example context that I > deal with that way to avoid a U-boot limitation > for the device: the kernel can find the world > where the U-Boot/FreeBSD-Loader can not. (The > FreeBSD loader depends on what USB can find: it > does not look elsewhere.) I only mention this > in case I need to reference it in the future, > avoiding a surprise in such a case. Otherwise > ignore the complication.) > Are you referring to a case where the root is on microSD but /usr and friends is on a USB device? > You might move (not copy) the MSDOSFS material > between the microsd card and the usb drive during > experiments, avoiding having duplications. There > is the possibility of instead renaming things so > files are not found on a partition, for example. > A similar point goes for UFS materials: avoid > having multiple viable-for-booting UFS file > systems present. > > As stands, things seem too hard to track for me > to be of much help. Please make things obvious for > what was in use by making the material uniquely > placed (for the form that can be used). > I believe the experiment above (deleting UFS on microSD, hiding the DOS files on USB) has been an equivalent configuration. It looks like control passes in some way between the DOS slices, though how is unclear. > Separate issues/questions: > > Do you have the file "timeout" in the MSDOSFS, in > addition to config.txt and the like? If not, I > recommend including it. > Yes, it's been tried on both microSD and USB devices. Seems like the only one that can matter is on microSD. > What other RPi* firmware controls for having > various deliberate RPi* firmware delays do you > have set up? > The Raspberry Pi config.txt description lists several delay commands that can be placed in config.txt. None seem related to USB discovery, might any come into play early enough to be useful? They're named bootcode_delay boot_delay boot_delay_ms I tried them casually and didn't notice much change. Are they worth revisiting more carefully? > It is not so much that these would be sufficient, > but they do establish some context before U-Boot > is even active. It could be important to > understand that context. (Unsure at this point.) > > > >> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. > >> (They also later mentioned using "usb_pgood_delay=2000\0" > >> instead, a figure they found in a bunch of configrations.) > >> > > The Pi3 in question is capable of booting from solid-state USB > > storage without any microSD card, but fails to detect a mechanical > > disk. Which is the appropriate u-boot-rpi3 port to tamper with? I > > tried sysutils/u-boot-rpi3 as an upgrade but that simply froze. > > The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds > > the USB mechanical disk, but erratically. > > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 > as I remember: it is set up for both the RPI3 and RPI4. Given that > it works some, that would be the U-Boot port I would experiment > with if I was doing the experiments. > > >> So something somewhat analogous might help if you are willing > >> to build and use your own u-boot port variant. > > > > Obviously, that's a fraught enterprise at my skill level.... > > I'm still somewhat hazy on the actual boot sequence when > > chaining from microSD to USB. > > Having the extra text in the U-Boot build does not really > depend on the chaining order question. > > But, to repeat (sticking to the simpler context), > the order is: > > MSDOSFS: (all on one of: microsd card vs. usb drive) > RPi* firmware (I do not report the file-level sequencing) > U-Boot > FreeBSD loader (which uses information from U-Boot) > > UFS: (both: together on one of: microsd card vs. usb drive) > FreeBSD kernel > FreeBSD world > > > > Indeed, it's unclear how or if u-boot plays a role in starting > > RasPiOS. The term u-boot isn't found on the Raspberry Pi doc > > website, and the Pi isn't mentioned in the Denx manuals. Those > > discoveries surprised me. > > RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some > forms of a linux kernel directly and that is what RaspiOS and > RaspiOS64 are doing. That clears up a major misunderstanding, thank you! > That is why the config.txt type of content > makes no mention of u-boot or of any kernel= assignment in RaspiOS > and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel= > and an explicit *u-boot*.bin as the value. Without thinking about it very carefully I tried to use the "bootcode.bin-only" method for booting an older Pi2 from a usb hard disk, as described in https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#special-bootcode-bin-only-boot-mode It worked on the Pi2 but failed on the Pi3, causing an immediate hang. Might that avenue be worth pursuing? In hindsight, that it worked on a Pi2 is quite surprising. With my thanks! bob prohaska From nobody Sat Dec 18 03:02:00 2021 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 C520E18E1F75 for ; Sat, 18 Dec 2021 03:02:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JG9cm34n0z3FSL for ; Sat, 18 Dec 2021 03:02:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639796529; bh=CJYB8LeDaJdjSyCe/6hO4l6Rkfl1RNygZ1+00Pn9B6c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y1AKqCZoLkE4/0OL4b+IM6uyd8R/MoZ365H+bG/NKAd5osoEa+VUp25Z5COcRbtxH65q19Kl6ymsPegHftHL1fVyAMR8bJERMnXc0H2BVCEDHzSOOn6mMcBmqJB0kjJeyhnt//S6+Ykqrx+XJvg2kYu7WXEJj4YGEOToQyiL8titNOGpDG/QrBf515nSDH+fc3TMc1ol/AU6eTI9sG13cKPo0RumzRKH0w7pC8ZB9A7vF8cjyqjdkkteha3fE+YpfykNUwEcNQFSASFf19G7lRodIaqj0zLw/DHt/f4GFYFVqABaZXHA2ANZhNsKzuF7GB4DfNl8bxcVzORZ+6ZXMA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639796529; bh=+28t0Vn15Dq96tf9fbMP1yh1GhRwwfnRHEZzZh/iLbw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XjOYZ2aGytUccvcYWu2AYBrLxdbO39yYZxcRDt+AngNaN3nbGXGsf0Ih2mqjUZqABd+1G+zhTe698N5jyJb12TyJLFTOpYukkcA57NCMQ7fpOGhVaIEjc5MlQJcJDm6S4nfJfmBGxjzjAc1bqajrICYg605j/X3HnZAPKj7X6pOQXgWUOxz6hrCZOYv5yR4Hnjix+AOxnAJvU+6LCEX0Tn74Z359AqjtZQH8QkdH1jO9k6grg9w7Z7Te49Qr/ZqKKwHcOq7ycCzKfYqbnSRzDO1q+048cB987REqxzDHWCOsNgAAGlKa/BEfHz00I5D07mbSRUUqYkL15TuQ0rxiqw== X-YMail-OSG: 6weD_qsVM1mO3RZE5.OLbnjeqdoODDk4pxnPlUrCdGSNl0Dsaj_CvGWLHrczbMU FZD3t1Et0O_mPGepwlIKn.Dl7LIfmnMc81r.Okp0XKKRLePGnWAGHDwiIQ6HvMZH0RBBQ9R4zml4 D9F74eFH5fu8hW3Iq5PxTavNSev.E9BJJ_mlcx.t9POaF3NhYQKoY_rDBsUwVMVliYZXwleqg7my pspR2cGVfvvt1zB5IczVHI9B7ZbNzXriiezRBgm_TPKERZSKxd9cYI6ImBcO4tGASzKqGjSxSEFb jZKcCpGOcvJlpjEhh_AnmCSQ5.82HIQFmHu2uAWtoBMdsiu21l9S.EfuWwIKfeEpJRN1lHRG7BOt xX7h1Yo8mBOfrbEv3EpeaoX.qbtrsXAB0JhxKRaJIpurowvidg2g8lQ8snz71fM11Xgg9Rz1hMNg 4eCheUtmvFMYQSRvwspmno8sOyqM3lsGKvnetgq9RtN5A2AkoAiKEcPoCBp8MGlHAGtPpi8vQchr oVslS1a3UA_h2MtBDhLXAEiguagr0pwhQxZQqA4t8yVxP5hkSk3L3H9xTcje_QSyXfMHAcjzWZD6 H.mZOA5i2KUolSemP68_sxwo5Z.43khv800XguEnwoAlue5aaQ1E1u4IJz6e9sBp9WmQ75n7Hp6Z 8m5MY_.GPKtTDmGABQiHaNAvO09puuD3tiJCT.ADF5h8_DxzvAXTfO2rs8_3n7uL16uMP598Kz7K pIkFhp6gGOD9byOlp_2XEHAVg.lwpK95rWaK_dLzzjY581DPQEZIbp2rnor.U8B6poLHIedh_lm5 gVK.uXfPjEMIr7MAUKAFYoMr.EJymySZf2CODIQJVSV1.WomI8XakMcBPU2ddTj5SGyDl2WCGsBn UvwMpA9PaDQJTlRSi6Wo2RFA83EMQrHKOiFJ5vVx.q1shhyW6SyHZRC3Wi_PDLfhv8QVOoUBwR1N uwrtIrT6LQaK62.DCeIfbl7ABS0sIsfBhe0dSefu1Rx3ewHoIxdQTlvwfPKBzDRR0BvBw_W7e0Zi 3DopMqBfD.A1Zib8ie2_S.yW0GBh5OLe8V7l50RnRrhQZWua7bqpoSgQ63XDQcpixB5N_X9RwN5E baJuL.51UPkbR6Fk4PLANKHcxOmaWiXkdKrYzWwqgXroO.4yP7zG92LTN.jhel8AYibKEGfXyZpy d.NTbKfOFScWjqFzF0DZmHc3QKOoXYBbEbtU46dVEX6hMg6q3tkPDp7LjF9CKnnM3ZYC3HqoUQt8 j69Mv_wZGm9TclOoeH8..nojMYZz3xZ9jMbkNxugLXfypwcp1oRO59WEUViLwDVaEig5NNoRSlfw Ww981tHnkZQMH9JsxO0.BbjrL2jFrgKghBGC6jHjJ9BvQac_l5fFC9cyry_MS4JgIceqlKVmPw9b VyjX4lk6oVVdruCuv4jgxD6frSjt3W9oKEZVqbMUeLCs_i73UFLzVyy6l9SjC4j5BFKM2wsxpeQn VsHW0QwEhoO8BF3DyyDXi_5it7Wdlf3uXHFIMAyoJAUaE0.SzHAlffU4szYHV8Et7wB3CDBOA4eG 51yHomf2iG0vGQ._X6GGZ21LGgUbnfBs.YvkhMlqkKdbqlNOdR8_QZJev2suxdbnRKALC_opRoEK 8YyTjZAZQhV4eqtUO.Yxyq7iLq.2EXws51dEvdXAUCCmqCS.pJDgns8IB8Aj7NFImF58Xg7uh7pc MSyllRif.M6rLI68GFyctA1JHGFQMNtVbX5Es5.kzpYmtx5uP_TKCWIAB9AMNCRRl39NS3WRqdsm O.ZEG6L4VbvHLs2j.WAHSodXEp.L1vO2RB0nfs.nNjQ1T86NBr_08G2x2h28jPnWkfv7G3LVfjBh 3tnkCD8wFEVne_ELSxGrqhSNPiBDSxH38ry6EqjAmwjo0sCTcGyyjhKhb4._g.9qZqf9TSV7ONos TkZTtsfTzoVI3DzbEKkRavcfbXlR7XKRPoW9H2wAeJdqlTivFVpm8jND1NHDjfYs.Ed00npnhgds sICQrr6LvMD_fxDJzUtngadA_.onZ8vf2aIyJUkSPpnXCzAcbPhofPtAxOWvtd4X1K8Gq9JALOx0 ZKHGlvQgmYh5rU66X9bDl8ldgXxWVtSoYqTpgrZLUdj3wK1mABPIWDHD9aXBXErdsuoLOJDhvQ1R NfVfgVAwIX8mXHu.c2j7xm_tMH2NKZaj42MP9DbMx2EZvkUTRAHf2u4b0SWaChI_cQG60Rkbr7bg BIX0a.2sjxMLUBm6NLce2_hevNeJtkHe3gA8vPN50jTlJMw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Dec 2021 03:02:09 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cf8276c701630664d3eaa808317f0cb5; Sat, 18 Dec 2021 03:02:02 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: <20211218005946.GA7670@www.zefox.net> Date: Fri, 17 Dec 2021 19:02:00 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JG9cm34n0z3FSL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 18535 Lines: 551 On 2021-Dec-17, at 16:59, bob prohaska wrote: > On Thu, Dec 16, 2021 at 11:00:46PM -0800, Mark Millard wrote: >> On 2021-Dec-16, at 17:36, bob prohaska wrote: >>=20 >>>=20 >>> Yes, the microSD contains a dd of=20 >>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img >>> The DOS partition is writeable, AFAIK. >>=20 >> Hmm. That means there is also a UFS root with >> a kernel and world on the microsd card. Both >> the microsd card and the USB drive contain >> contain such, as well as each having an >> /etc/fstab (and so on). >>=20 >> Having multiple such makes for a mess for >> controlling which is used (and knowing which >> is used). What is the first stage that you >> made sure the USB drive was in use and how >> did you make sure? >>=20 >=20 > I installed a microSD containing only the FAT slice from=20 > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img, the FreeBSD > slice being deleted using gpart. There is a timeout file. Ultimately, you may need to publish a full capture of the debug output that goes to the serial console when such debug output has been fully enabled. This could end up being for each of several variations tried. Did you still have the MSDOSFS material on the USB in a viable form as well? https://www.raspberrypi.com/documentation/computers/config_txt.html reports that there are boot options that can go in config.txt : bootcode_delay boot_delay boot_delay_ms Quoting . . . QUOTE bootcode_delay The bootcode_delay command delays for a given number of seconds in = bootcode.bin before loading start.elf: the default value is 0. END QUOTE QUOTE boot_delay The boot_delay command instructs to wait for a given number of seconds = in start.elf before loading the kernel: the default value is 1. The = total delay in milliseconds is calculated as (1000 x boot_delay) + = boot_delay_ms. This can be useful if your SD card needs a while to get = ready before Linux is able to boot from it. boot_delay_ms The boot_delay_ms command means wait for a given number of milliseconds = in start.elf, together with boot_delay, before loading the kernel. The = default value is 0. END QUOTE (So boot_delay_ms is only for smaller scale adjustments and can be ignored here.) Here "loading the kernel" means what config.txt was told was the kernel: some *u-boot*.bin for the FreeBSD context. So one experiment is to have only bootcode.bin and a config.txt on the microsd card's MSDOSFS, specifying a significantly large value for bootcode_delay . The hope would be to be able to get the start*.elf file and the rest from the USB drive. If that does not work, then the next is to have the RPi* firmware only on the microsd card's MSDOSFS and have config.txt also specify a significantly large value for boot_delay . This first variation would not have a *u-boot*.bin or the FreeBSD loader on the microsd card's MSDOSFS but only on the USB drive's MSDOSFS. If that does not work, then the next variation moves just the *u-boot*.bin file to the microsd card. (If that fails then controlling U-Boot's delays can be involved. For now I only list the path of leaving U-Boot's delays as they are: one short branch of the exploration.) If that does not work, then the next variation moves just the FreeBSD loader file to the microsd card. With that I'll stop listing things to test, pending results on what I've listed. > A hands-off warm boot reports > resetting system ...=20 >=20 > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >=20 > DRAM: 948 MiB > RPI 3 Model B (0xa02082) > MMC: mmc@7e300000: 0 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: No ethernet found. > starting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 5 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found I would need to also see the RPi* firmware's prior debug output to be able to interpret this. I can not tell for sure which device's U-Boot copy is operating for the above. I'd guess that is the the micrsd card's MSDOSFS one. > Hit any key to stop autoboot: 0=20 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... This looks to be getting a copy of the FreeBSD loader from the microsd card's MSDOSFS. The FreeBSD loader will only see the same Storage Devices that U-Boot did: it gets the information from U-Boot. > Found EFI removable media binary efi/boot/bootaa64.efi There was a FreeBSD loader in the microsd card's MSDOSFS. > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Scanning disk mmc@7e300000.blk... > Found 2 disks > No EFI system partition > BootOrder not defined > EFI boot manager: Cannot load any image > 1259212 bytes read in 125 ms (9.6 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Booting /efi\boot\bootaa64.efi That FreeBSD loader is what it is using, not one from the USB drive. > [whitespace deleted] > Consoles: EFI console =20 > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk0p1: "disk0p1" is U-Boot terminology for a drive, despite this being the FreeBSD loader's output. The FreeBSD loader uses the U-Boot information, not FreeBSD's information. > FreeBSD/arm64 EFI loader, Revision 1.1 >=20 > Command line arguments: loader.efi > Image base: 0x39e03000 > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8224.4096) > Console: comconsole (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) This is reporting where the FreeBSD loader was found. It indicates that disk0p1 was the microsd card's MSDOSFS. > Setting currdev to disk0p1: The microsd card's MSDOSFS again. > ERROR: cannot open /boot/lua/loader.lua: no such file or directory. There is no FreeBSD directory-tree there to find things like /boot/lua/loader.lua in. Currently we are trying to have the /boot/lua/loader.lua come from the USB drive's UFS file system, not the microsd card. > Type '?' for a list of commands, 'help' for more detailed help. > OK=20 >=20 > AIUI, disk0p1 is the microSD, which has no /boot/lua/loader.lua > That makes sense. If u-boot finds the USB mass storage device > then running=20 > run bootcmd_usb0 starts the system successfully. >=20 > It does appear that the FAT partition on the USB disk is involved. I see no evidence of that above. (Below is a different context.) > If I hide the contents of da0s1 by placing them in a subdirectory > the boot fails, even if u-boot has found the USB disk: >=20 > Hit any key to stop autoboot: 0=20 > U-Boot> usb reset > resetting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found >=20 > [Note that the six devices include the disk, it can be seen in usb = tree. > For some reason it isn't recognized as a mass storage device.] >=20 > U-Boot> editenv usb_pgood_delay > edit: 2 > U-Boot> usb reset > resetting USB... > Bus usb@7e980000: USB DWC2 > scanning bus usb@7e980000 for devices... 6 USB Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > U-Boot> run bootcmd_usb0 >=20 > Device 0: Vendor: SABRENT Rev: 1214 Prod:=20 > Type: Hard Disk > Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512) > ... is now current device > Scanning usb 0:1... > U-Boot>=20 > and there it stops. Looks like both FAT partitions have a role to = play. That is not clear to me. But I'd rather be lookning into earlier stages at this point, so that "1 Storage Device(s) found" hopefully ends up being automatic. If we get that to be automatic, then what is happening here becomes the next area to investigate. But the investigation is not far enough along to justify investigating this now. > An earlier experiment tried booting the microSD card in a USB adapter, > That worked correctly with nothing in the microSD slot, so the = internal > "boot from USB" feature might work if it could be slowed down = sufficiently.=20 Agreed, that the first thing is to get it to start up the disk and wait for it. There may be more at issue after that. >> The order of activity is: >>=20 >> MSDOSFS: (all on one of: microsd card vs. usb drive) >> RPi* firmware (I do not report the file-level sequencing) >> U-Boot >> FreeBSD loader (which uses information from U-Boot) >>=20 >> UFS: (both: together on one of: microsd card vs. usb drive) >> FreeBSD kernel >> FreeBSD world >>=20 >> (I do not specify which MSDOSFS is used when >> there are multiple viable ones in separate places. >> Similarly for UFS.) >>=20 > =46rom the experiment today it seems both are required. I do not get such an interpretation from your experiment. Until "1 Storage Device(s) found" happens automatically the context is not nicely comparable for the later stages. > The first discovers the USB disk, the second uses that > information to proceed further.=20 >=20 >>=20 >> (It is technically possible to have kernel vs. >> world in separate UFS partitions, possibly on >> separate media. I've an example context that I >> deal with that way to avoid a U-boot limitation >> for the device: the kernel can find the world >> where the U-Boot/FreeBSD-Loader can not. (The >> FreeBSD loader depends on what USB can find: it >> does not look elsewhere.) I only mention this >> in case I need to reference it in the future, >> avoiding a surprise in such a case. Otherwise >> ignore the complication.) >>=20 >=20 > Are you referring to a case where the root is on > microSD but /usr and friends is on a USB device?=20 Again: I suggest ignoring the details of this for now. It would just confuse things. But if you insist: On the Rock64 I have a e.MMC in use instead of a microsd card, and in the end the world is on a USB3 SSD. But the U-Boot involved can not access the USB3 --os neither can the FreeBSD loader. The FreeBSD kernel is the first stage that can access USB3. The e.MMC has the MSDOSFS. It has an partial copy of what would normally be some of the USB3 drive's content. (I named the mount point microsd_ufs before I switched to the e.MMC .) It has only (much hidden in ". . ."s). # find /microsd_ufs -print | sort | less /microsd_ufs /microsd_ufs/.snap /microsd_ufs/COPYRIGHT /microsd_ufs/boot /microsd_ufs/boot/beastie.4th /microsd_ufs/boot/boot1.efi /microsd_ufs/boot/brand-fbsd.4th /microsd_ufs/boot/brand.4th /microsd_ufs/boot/check-password.4th /microsd_ufs/boot/color.4th /microsd_ufs/boot/copy_boot_to_microsd.sh /microsd_ufs/boot/defaults /microsd_ufs/boot/defaults/loader.conf /microsd_ufs/boot/delay.4th /microsd_ufs/boot/dtb . . . /microsd_ufs/boot/kernel /microsd_ufs/boot/kernel/accf_data.ko /microsd_ufs/boot/kernel/accf_dns.ko . . . /microsd_ufs/boot/kernel/kernel . . . /microsd_ufs/boot/loader.4th /microsd_ufs/boot/loader.conf /microsd_ufs/boot/loader.conf.d /microsd_ufs/boot/loader.efi /microsd_ufs/boot/loader.help /microsd_ufs/boot/loader.rc /microsd_ufs/boot/loader_4th.efi /microsd_ufs/boot/loader_lua.efi /microsd_ufs/boot/loader_simp.efi /microsd_ufs/boot/logo-beastie.4th /microsd_ufs/boot/logo-beastiebw.4th /microsd_ufs/boot/logo-fbsdbw.4th /microsd_ufs/boot/logo-orb.4th /microsd_ufs/boot/logo-orbbw.4th /microsd_ufs/boot/lua /microsd_ufs/boot/lua/cli.lua /microsd_ufs/boot/lua/color.lua /microsd_ufs/boot/lua/config.lua /microsd_ufs/boot/lua/core.lua /microsd_ufs/boot/lua/drawer.lua /microsd_ufs/boot/lua/gfx-beastie.lua /microsd_ufs/boot/lua/gfx-beastiebw.lua /microsd_ufs/boot/lua/gfx-fbsdbw.lua /microsd_ufs/boot/lua/gfx-orb.lua /microsd_ufs/boot/lua/gfx-orbbw.lua /microsd_ufs/boot/lua/hook.lua /microsd_ufs/boot/lua/loader.lua /microsd_ufs/boot/lua/menu.lua /microsd_ufs/boot/lua/password.lua /microsd_ufs/boot/lua/screen.lua /microsd_ufs/boot/menu-commands.4th /microsd_ufs/boot/menu.4th /microsd_ufs/boot/menu.rc /microsd_ufs/boot/menusets.4th /microsd_ufs/boot/modules /microsd_ufs/boot/screen.4th /microsd_ufs/boot/shortcuts.4th /microsd_ufs/boot/support.4th /microsd_ufs/boot/uboot /microsd_ufs/boot/version.4th /microsd_ufs/boot/zfs /microsd_ufs/etc /microsd_ufs/etc/hostid /microsd_ufs/lost+found Almost no world content. /microsd_ufs/boot/loader.conf has (in part): vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root" kern.cam.boot_delay=3D10000 vfs.mountroot.timeout=3D10 vfs.root_mount_always_wait=3D1 That vfs.root.mountfrom notation redirects to the USB3 drive for world but the /boot/loader.conf and /boot/kernel/kernel and /etc/hostid were first loaded from the e.MMC media, not the USB drive. As I have it, the USB3 drive also has a copy of the same /boot/... and such materials and load module activity is from the USB3 copy. I have to keep the two places tracking so nothing ends up mismatching. >> You might move (not copy) the MSDOSFS material >> between the microsd card and the usb drive during >> experiments, avoiding having duplications. There >> is the possibility of instead renaming things so >> files are not found on a partition, for example. >> A similar point goes for UFS materials: avoid >> having multiple viable-for-booting UFS file >> systems present. >>=20 >> As stands, things seem too hard to track for me >> to be of much help. Please make things obvious for >> what was in use by making the material uniquely >> placed (for the form that can be used). >>=20 > I believe the experiment above (deleting UFS on microSD,=20 > hiding the DOS files on USB) has been an equivalent=20 > configuration. It looks like control passes in some way=20 > between the DOS slices, though how is unclear. I do not agree to that specific interpretation of the sequence you did (on the evidence currently available). Until "1 Storage Device(s) found" is automatic this later-stage material is too late to yet be relevant or to have an appropriate context. I'm staying focused on getting the "1 Storage Device(s) found" to be automatic. Absent that you are likely stuck with doing something similar to be Rock64 e.MMC way of working --where /boot/loader.conf and /boot/kernel/kernel and /etc/hostid for early activity is from a UFS partition on the microsd card. >> Separate issues/questions: >>=20 >> Do you have the file "timeout" in the MSDOSFS, in >> addition to config.txt and the like? If not, I >> recommend including it. >>=20 > Yes, it's been tried on both microSD and USB devices.=20 > Seems like the only one that can matter is on microSD. >=20 >=20 >> What other RPi* firmware controls for having >> various deliberate RPi* firmware delays do you >> have set up? >>=20 >=20 > The Raspberry Pi config.txt description lists several delay commands > that can be placed in config.txt. None seem related to USB discovery, > might any come into play early enough to be useful? They're named > bootcode_delay > boot_delay > boot_delay_ms >=20 > I tried them casually and didn't notice much change. Are they worth > revisiting more carefully?=20 See my earlier notes. >> It is not so much that these would be sufficient, >> but they do establish some context before U-Boot >> is even active. It could be important to >> understand that context. (Unsure at this point.) >>=20 >>=20 >>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >>>> (They also later mentioned using "usb_pgood_delay=3D2000\0" >>>> instead, a figure they found in a bunch of configrations.) >>>>=20 >>> The Pi3 in question is capable of booting from solid-state USB >>> storage without any microSD card, but fails to detect a mechanical >>> disk. Which is the appropriate u-boot-rpi3 port to tamper with? I=20 >>> tried sysutils/u-boot-rpi3 as an upgrade but that simply froze.=20 >>> The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds >>> the USB mechanical disk, but erratically.=20 >>=20 >> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 >> as I remember: it is set up for both the RPI3 and RPI4. Given that >> it works some, that would be the U-Boot port I would experiment >> with if I was doing the experiments. >>=20 >>>> So something somewhat analogous might help if you are willing >>>> to build and use your own u-boot port variant. >>>=20 >>> Obviously, that's a fraught enterprise at my skill level.... >>> I'm still somewhat hazy on the actual boot sequence when >>> chaining from microSD to USB.=20 >>=20 >> Having the extra text in the U-Boot build does not really >> depend on the chaining order question. >>=20 >> But, to repeat (sticking to the simpler context), >> the order is: >>=20 >> MSDOSFS: (all on one of: microsd card vs. usb drive) >> RPi* firmware (I do not report the file-level sequencing) >> U-Boot >> FreeBSD loader (which uses information from U-Boot) >>=20 >> UFS: (both: together on one of: microsd card vs. usb drive) >> FreeBSD kernel >> FreeBSD world >>=20 >>=20 >>> Indeed, it's unclear how or if u-boot plays a role in starting=20 >>> RasPiOS. The term u-boot isn't found on the Raspberry Pi doc=20 >>> website, and the Pi isn't mentioned in the Denx manuals. Those >>> discoveries surprised me. >>=20 >> RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some >> forms of a linux kernel directly and that is what RaspiOS and >> RaspiOS64 are doing.=20 >=20 > That clears up a major misunderstanding, thank you! >=20 >> That is why the config.txt type of content >> makes no mention of u-boot or of any kernel=3D assignment in RaspiOS >> and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=3D >> and an explicit *u-boot*.bin as the value. >=20 > Without thinking about it very carefully I tried to use the > "bootcode.bin-only" method for booting an older Pi2 from a > usb hard disk, as described in > = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#spec= ial-bootcode-bin-only-boot-mode > It worked on the Pi2 but failed on the Pi3, causing an immediate hang. This gets back into the use of a config.txt with a bootcode_delay assignment also being in the MSDOSFS on the microsd card and the file timeout also being in the MSDOSFS on the microsd card. Only if those delays together can lead to the USB drive being accessible will it get any farther. I'd suggest such experiments. The vintage of bootcode.bin matters as I understand. > Might that avenue be worth pursuing? In hindsight, that it worked on a > Pi2 is quite surprising. =20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 18 03:12:32 2021 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 7BBD618E439C for ; Sat, 18 Dec 2021 03:12:42 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JG9rn3G1Tz3Gx2 for ; Sat, 18 Dec 2021 03:12:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639797159; bh=bzBAzesE7Ry4a0Ss/z6ApCFglA4fjlhYrIkVRBgIWV4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SxJuD2pZBvS9c4SgjJxucl5qv5rkA4YvHCX6kjzqDQE0qSYUFvxeIQy5kFvaQvegJ7q7WcpoxxHAnJX/Szqo4Dr0dn5qa+2iOvW4g39COkiWJpHo129rfgugU8lcHHkfJDANutKv/RO/DsT0ewLf1+5XK53ca1QqoDPxDxj6zLZUwdhgzBy/m4VE8cc0RPIRn/QO4/PS1TjxKhIwM3h9rJKu+SWiMN3yG16yshuq/pnfQBagjw5rzlzSHApxERq9QrT7Mx0BWRB6ZYG1BU9A1hqrGC6TrZeK2ul2LCGYvJqZMAp7cB7ZtUJvPdREzdmYJ7SaJ3fr8ERs0z9RvPPv9g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639797159; bh=H+Uwh+/ePf2zmH0ikN1LxA2XCZWYMU6cQC4ofUH2OCs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cvnLoAyieatRdRbywBI6QzFdzfAQr4ZeJOHERaJtI0iW07i6UONCcn7dRz4B3Lp51ZtRo+wTv0SwEZQrAp/drdJLv7m2fQAlRq3HG+KunjdUBDieGbikxWVjKDkSQkvrPcYNVP1Pgq/Sb2DG8vxE9CwoRr6afN6QYWjr3705yT76puhdPgSMwmy29QmZCMhIjN/Q/MA/Xjlt+FEZilWQFaTFiLOAekrXRFrqvHJzzTW7oTRpUfc0G3aEOSr5NbWR1BSVnkWhd4vc8PMlY7JKJl0XsFMpagNOiAGCN+q+oNyOsPDuikoeSfH1Fm1BTTYnfeHi+xQqF5T0EAGSHD/jHg== X-YMail-OSG: u_i41.gVM1mK4yoq9Amo7vhphDJCn5492lbFMCDKWgTKMsL4otet3JoPpKWrFS4 DWZVI.R9HY2v9YrwVrmq1Dv46n9dr8Y_SLLy5QlzuafQx.ZAAreRDaT9F040DPvGwBduIjRmbctr _Fm04nUgLS98POtX3wVXgkbt8_XoAY6X.2YcCprB76YDxrmRebNQ3MsFrQaZexLkv.dH883zj5aJ ntfh0wP0qWiI12M0q2cMTpdeMdrsqavSLQsklSpz_xb8YP9RIEqfN6hBbMhfNwLeTa_JWwBJhH3G Id4pmyNBNCEJK4TTBU1y3qqGy6k619eQeppLS17xlgazw2g2_yo1BGpy8I4mw96Zok4PlDlXGcr4 VMZO8OlZoHEi9mL78asXFxsjnrYV.RmppFogwcYz7tRfjCSBemiwNWjKCPtrNVQxQDBZK8xZKWW6 9JBBVzaj.hmTHgXYzena0naFJjE_pdHty6DNZUjYM.VPWa2oTHH8NIR8tXZCpaD7gh5Q3TmspbfR R.4o4vX4ABQYWySiuwclR9R54yk3nrN3mPw8lmHHxCo2ygo7.7UNoxLjOGdUcoqsiJ6OBO4CndBV KLU8zDwzVg4mwm0BzFofAWSz4psMcS555JeOzqyyMstO.RBg7su54HIdEiIh.n455uzHu8Vrzbff Sc_iCOcat.0hjMWgF5Cee1ryOuimQh.7EUWWq4naTizT8J6rYVK8eqtwjIy2M7xFRAIyu14Oa4yD 8ueSvGv4XnH10qiWZjNN8kPOAfYZ1hhXR66tGKMb31MiIejKZA25M7V.0CMf4suSTv0WYtXLy2j4 kMB_d2DWIORTewhEPNGANId_ObfayVHXRXnZMOzB2hR1C7ZdK94WB8igCz2rpKUeFSK8GKPLihwg Sn5RjHZl_jy28YECLvpWto6uwN0TpKtsg0sipn8VcduUGozTluxUn.VMYBMvtnnSv2i9CbP0rzhH 9jc_7wXo3EvcUvlLmR2cJsfNWMpMCCn6dQMAfu7NK9rrheybGM4ET8M_vJqfmedN8HzgYYpoXBjL gYHzFMcQAVrYtVY6OWmXOM7TNPT9cQsIAjtWtfxdE8qCx.qciFjkwPpLsijCgyrlqX8KThgthZjT AD6hohn_CKJzdCD_OKrWXtHiABNG5RTW1dMVl_oemt4EPQS4KrmUA1IZqrzfOdwS2vpBxioypeYW 3.9wmIJfmpTPShdOx8ZjJw3vnGkdK81OL9rFTYCGiLBT5pHMK61cSLfCPuSLwwlUMAvshYopdSD0 oLnk4ZHrGUaMErz3ik559FZPEMD5XD6HvuhUXh7tog2rYsSWFhyZkD5zSaAhSevvRzYt_eRotGDJ kqq.psv2gMmDidGXk3k8ty3ZRzGNb6s8jn6Tu.J2AStJEzknvvMFUdBtAgiXlO0lBv3U6jqHUdat 7nSuzhT9cOy_qhaqdyCRIHjeelnzSBnXtkK619oQssyoe_5V_spqx6Ona8jVcwLAS0XV9T658Daj CI3IAxuaRY3DY95l9qPzPgixONkVQo5u8TPncw9Z_HG4bIpLhVMLB4FbaQuSk63kaB.SsJA6QPo1 G1ZLJibeNKLarM_56F1GR2F.rrYUsrHNaWdTYBO8UOzHi31Wuv0HbRYIZEvIouKMrkqQwU2wHpYI X3ZPZJTaK8VD40PHelLQnMcIb90yL0G6K3cexO8tJTmnM.3R_QxQ_EMGtuBQmMWJ38S8ckuEKCBf nztCxB7jJk1VX.ib7MXHz5XBHay2mOk.SFoaJN3s95Yx5Z9SzJk8MrLLj9ubXWlBsxVxtIunB7Rc R3QGiMMWwUBN1aFlwYJANfvlqm4R8vpfbysAi8_uvaRbGZpD90DoVBXaxZBWCa8EYyi5H1wfxAqR sIKl1HJYBCEUyfm9uDbysxe1IhdgKiweD5MviaW0.VsF_6YwsXrfs6Ny2ys6vMgMqpdY6PTXn6zL f_B92SOCoCziP10Di5KN.QPvCLy66RY9e3JZDGJO5AtUGo0a0pIBABt3ZetoVslNFzg2GMzOG1Pd gAG1EhMbQTzPXKewhKilMTcWo1pCuwR1L9LMRM6pOjMZ3JNeVotv3Es8hd1BRaXfM4z_Hntd_fZ4 Zm9mjQXbteyzsrniPlerrvUrBrAahbv6pTX9wWCf0DtMNuu5M5_O7J4ShQIttHAVbyIEm.hPn7lm 1lPhSWEiAb6l2x_DbTZykmTsPjDnmYPKDFuNNHZ7ib_bo4fkQ69iGn8uZyL_kchOzlr3RAJehOjK vDIZv2deajGKMBXV_YKNhXSW.F.3i.7ibtvGLZTH2TuXXMywDTawbmTTB.sxYSipNuwShhHuGLSp yMln6wGBTBZ0fPOA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Dec 2021 03:12:39 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fd659f7710d8a12e8e7f9c4dbd108a9d; Sat, 18 Dec 2021 03:12:35 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> Date: Fri, 17 Dec 2021 19:12:32 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JG9rn3G1Tz3Gx2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SxJuD2pZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.18 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; NEURAL_HAM_SHORT(-0.68)[-0.680]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 19785 Lines: 563 On 2021-Dec-17, at 19:02, Mark Millard via freebsd-arm = wrote: > On 2021-Dec-17, at 16:59, bob prohaska wrote: >=20 >> On Thu, Dec 16, 2021 at 11:00:46PM -0800, Mark Millard wrote: >>> On 2021-Dec-16, at 17:36, bob prohaska wrote: >>>=20 >>>>=20 >>>> Yes, the microSD contains a dd of=20 >>>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img >>>> The DOS partition is writeable, AFAIK. >>>=20 >>> Hmm. That means there is also a UFS root with >>> a kernel and world on the microsd card. Both >>> the microsd card and the USB drive contain >>> contain such, as well as each having an >>> /etc/fstab (and so on). >>>=20 >>> Having multiple such makes for a mess for >>> controlling which is used (and knowing which >>> is used). What is the first stage that you >>> made sure the USB drive was in use and how >>> did you make sure? >>>=20 >>=20 >> I installed a microSD containing only the FAT slice from=20 >> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img, the FreeBSD >> slice being deleted using gpart. There is a timeout file. >=20 > Ultimately, you may need to publish a full capture of the > debug output that goes to the serial console when such > debug output has been fully enabled. This could end up > being for each of several variations tried. >=20 > Did you still have the MSDOSFS material on the USB in a > viable form as well? >=20 > https://www.raspberrypi.com/documentation/computers/config_txt.html > reports that there are boot options that can go in config.txt : >=20 > bootcode_delay > boot_delay > boot_delay_ms >=20 > Quoting . . . >=20 > QUOTE > bootcode_delay >=20 > The bootcode_delay command delays for a given number of seconds in = bootcode.bin before loading start.elf: the default value is 0. > END QUOTE >=20 > QUOTE > boot_delay >=20 > The boot_delay command instructs to wait for a given number of seconds = in start.elf before loading the kernel: the default value is 1. The = total delay in milliseconds is calculated as (1000 x boot_delay) + = boot_delay_ms. This can be useful if your SD card needs a while to get = ready before Linux is able to boot from it. >=20 > boot_delay_ms >=20 > The boot_delay_ms command means wait for a given number of = milliseconds in start.elf, together with boot_delay, before loading the = kernel. The default value is 0. > END QUOTE >=20 > (So boot_delay_ms is only for smaller scale adjustments and can > be ignored here.) >=20 > Here "loading the kernel" means what config.txt was told was > the kernel: some *u-boot*.bin for the FreeBSD context. >=20 >=20 > So one experiment is to have only bootcode.bin and a config.txt > on the microsd card's MSDOSFS, specifying a significantly > large value for bootcode_delay . The hope would be to be able > to get the start*.elf file and the rest from the USB drive. >=20 > If that does not work, then the next is to have the RPi* firmware > only on the microsd card's MSDOSFS and have config.txt also > specify a significantly large value for boot_delay . This > first variation would not have a *u-boot*.bin or the FreeBSD > loader on the microsd card's MSDOSFS but only on the USB > drive's MSDOSFS. >=20 > If that does not work, then the next variation moves just the > *u-boot*.bin file to the microsd card. >=20 > (If that fails then controlling U-Boot's delays can be involved. > For now I only list the path of leaving U-Boot's delays as they > are: one short branch of the exploration.) >=20 > If that does not work, then the next variation moves just the > FreeBSD loader file to the microsd card. For the above one I missed a word, making things unclear. So, instead: If that does not work, then the next variation ALSO moves just the FreeBSD loader file to the microsd card. ( *u-boot*.bin stays on the microsd card from the prior step. ) > With that I'll stop listing things to test, pending results on > what I've listed. >=20 >> A hands-off warm boot reports >> resetting system ...=20 >>=20 >> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >>=20 >> DRAM: 948 MiB >> RPI 3 Model B (0xa02082) >> MMC: mmc@7e300000: 0 >> Loading Environment from FAT... In: serial >> Out: vidconsole >> Err: vidconsole >> Net: No ethernet found. >> starting USB... >> Bus usb@7e980000: USB DWC2 >> scanning bus usb@7e980000 for devices... 5 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >=20 > I would need to also see the RPi* firmware's prior > debug output to be able to interpret this. I can not > tell for sure which device's U-Boot copy is operating > for the above. I'd guess that is the the micrsd card's > MSDOSFS one. >=20 >> Hit any key to stop autoboot: 0=20 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >=20 > This looks to be getting a copy of the FreeBSD loader > from the microsd card's MSDOSFS. >=20 > The FreeBSD loader will only see the same Storage Devices > that U-Boot did: it gets the information from U-Boot. >=20 >> Found EFI removable media binary efi/boot/bootaa64.efi >=20 > There was a FreeBSD loader in the microsd card's > MSDOSFS. >=20 >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Scanning disk mmc@7e300000.blk... >> Found 2 disks >> No EFI system partition >> BootOrder not defined >> EFI boot manager: Cannot load any image >> 1259212 bytes read in 125 ms (9.6 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Booting /efi\boot\bootaa64.efi >=20 > That FreeBSD loader is what it is using, not one > from the USB drive. >=20 >> [whitespace deleted] >> Consoles: EFI console =20 >> Reading loader env vars from /efi/freebsd/loader.env >> Setting currdev to disk0p1: >=20 > "disk0p1" is U-Boot terminology for a drive, despite > this being the FreeBSD loader's output. The FreeBSD > loader uses the U-Boot information, not FreeBSD's > information. >=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >>=20 >> Command line arguments: loader.efi >> Image base: 0x39e03000 >> EFI version: 2.80 >> EFI Firmware: Das U-Boot (rev 8224.4096) >> Console: comconsole (0) >> Load Path: /efi\boot\bootaa64.efi >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) >=20 > This is reporting where the FreeBSD loader was found. > It indicates that disk0p1 was the microsd card's > MSDOSFS. >=20 >> Setting currdev to disk0p1: >=20 > The microsd card's MSDOSFS again. >=20 >> ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >=20 > There is no FreeBSD directory-tree there to find things > like /boot/lua/loader.lua in. >=20 > Currently we are trying to have the /boot/lua/loader.lua come > from the USB drive's UFS file system, not the microsd card. >=20 >> Type '?' for a list of commands, 'help' for more detailed help. >> OK=20 >>=20 >> AIUI, disk0p1 is the microSD, which has no /boot/lua/loader.lua >> That makes sense. If u-boot finds the USB mass storage device >> then running=20 >> run bootcmd_usb0 starts the system successfully. >>=20 >> It does appear that the FAT partition on the USB disk is involved. >=20 > I see no evidence of that above. (Below is a different context.) >=20 >> If I hide the contents of da0s1 by placing them in a subdirectory >> the boot fails, even if u-boot has found the USB disk: >>=20 >> Hit any key to stop autoboot: 0=20 >> U-Boot> usb reset >> resetting USB... >> Bus usb@7e980000: USB DWC2 >> scanning bus usb@7e980000 for devices... 6 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >>=20 >> [Note that the six devices include the disk, it can be seen in usb = tree. >> For some reason it isn't recognized as a mass storage device.] >>=20 >> U-Boot> editenv usb_pgood_delay >> edit: 2 >> U-Boot> usb reset >> resetting USB... >> Bus usb@7e980000: USB DWC2 >> scanning bus usb@7e980000 for devices... 6 USB Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> U-Boot> run bootcmd_usb0 >>=20 >> Device 0: Vendor: SABRENT Rev: 1214 Prod:=20 >> Type: Hard Disk >> Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512) >> ... is now current device >> Scanning usb 0:1... >> U-Boot>=20 >> and there it stops. Looks like both FAT partitions have a role to = play. >=20 > That is not clear to me. But I'd rather be lookning into > earlier stages at this point, so that "1 Storage Device(s) found" > hopefully ends up being automatic. >=20 > If we get that to be automatic, then what is happening here > becomes the next area to investigate. But the investigation > is not far enough along to justify investigating this now. >=20 >> An earlier experiment tried booting the microSD card in a USB = adapter, >> That worked correctly with nothing in the microSD slot, so the = internal >> "boot from USB" feature might work if it could be slowed down = sufficiently.=20 >=20 > Agreed, that the first thing is to get it to start up > the disk and wait for it. There may be more at issue > after that. >=20 >>> The order of activity is: >>>=20 >>> MSDOSFS: (all on one of: microsd card vs. usb drive) >>> RPi* firmware (I do not report the file-level sequencing) >>> U-Boot >>> FreeBSD loader (which uses information from U-Boot) >>>=20 >>> UFS: (both: together on one of: microsd card vs. usb drive) >>> FreeBSD kernel >>> FreeBSD world >>>=20 >>> (I do not specify which MSDOSFS is used when >>> there are multiple viable ones in separate places. >>> Similarly for UFS.) >>>=20 >> =46rom the experiment today it seems both are required. >=20 > I do not get such an interpretation from your experiment. > Until "1 Storage Device(s) found" happens automatically > the context is not nicely comparable for the later stages. >=20 >> The first discovers the USB disk, the second uses that >> information to proceed further.=20 >>=20 >>>=20 >>> (It is technically possible to have kernel vs. >>> world in separate UFS partitions, possibly on >>> separate media. I've an example context that I >>> deal with that way to avoid a U-boot limitation >>> for the device: the kernel can find the world >>> where the U-Boot/FreeBSD-Loader can not. (The >>> FreeBSD loader depends on what USB can find: it >>> does not look elsewhere.) I only mention this >>> in case I need to reference it in the future, >>> avoiding a surprise in such a case. Otherwise >>> ignore the complication.) >>>=20 >>=20 >> Are you referring to a case where the root is on >> microSD but /usr and friends is on a USB device?=20 >=20 > Again: I suggest ignoring the details of this for > now. It would just confuse things. But if you > insist: >=20 > On the Rock64 I have a e.MMC in use instead of a > microsd card, and in the end the world is on a > USB3 SSD. But the U-Boot involved can not access > the USB3 --os neither can the FreeBSD loader. > The FreeBSD kernel is the first stage that can > access USB3. >=20 > The e.MMC has the MSDOSFS. It has an partial > copy of what would normally be some of the USB3 > drive's content. (I named the mount point > microsd_ufs before I switched to the e.MMC .) > It has only (much hidden in ". . ."s). >=20 > # find /microsd_ufs -print | sort | less > /microsd_ufs > /microsd_ufs/.snap > /microsd_ufs/COPYRIGHT > /microsd_ufs/boot > /microsd_ufs/boot/beastie.4th > /microsd_ufs/boot/boot1.efi > /microsd_ufs/boot/brand-fbsd.4th > /microsd_ufs/boot/brand.4th > /microsd_ufs/boot/check-password.4th > /microsd_ufs/boot/color.4th > /microsd_ufs/boot/copy_boot_to_microsd.sh > /microsd_ufs/boot/defaults > /microsd_ufs/boot/defaults/loader.conf > /microsd_ufs/boot/delay.4th > /microsd_ufs/boot/dtb > . . . > /microsd_ufs/boot/kernel > /microsd_ufs/boot/kernel/accf_data.ko > /microsd_ufs/boot/kernel/accf_dns.ko > . . . > /microsd_ufs/boot/kernel/kernel > . . . > /microsd_ufs/boot/loader.4th > /microsd_ufs/boot/loader.conf > /microsd_ufs/boot/loader.conf.d > /microsd_ufs/boot/loader.efi > /microsd_ufs/boot/loader.help > /microsd_ufs/boot/loader.rc > /microsd_ufs/boot/loader_4th.efi > /microsd_ufs/boot/loader_lua.efi > /microsd_ufs/boot/loader_simp.efi > /microsd_ufs/boot/logo-beastie.4th > /microsd_ufs/boot/logo-beastiebw.4th > /microsd_ufs/boot/logo-fbsdbw.4th > /microsd_ufs/boot/logo-orb.4th > /microsd_ufs/boot/logo-orbbw.4th > /microsd_ufs/boot/lua > /microsd_ufs/boot/lua/cli.lua > /microsd_ufs/boot/lua/color.lua > /microsd_ufs/boot/lua/config.lua > /microsd_ufs/boot/lua/core.lua > /microsd_ufs/boot/lua/drawer.lua > /microsd_ufs/boot/lua/gfx-beastie.lua > /microsd_ufs/boot/lua/gfx-beastiebw.lua > /microsd_ufs/boot/lua/gfx-fbsdbw.lua > /microsd_ufs/boot/lua/gfx-orb.lua > /microsd_ufs/boot/lua/gfx-orbbw.lua > /microsd_ufs/boot/lua/hook.lua > /microsd_ufs/boot/lua/loader.lua > /microsd_ufs/boot/lua/menu.lua > /microsd_ufs/boot/lua/password.lua > /microsd_ufs/boot/lua/screen.lua > /microsd_ufs/boot/menu-commands.4th > /microsd_ufs/boot/menu.4th > /microsd_ufs/boot/menu.rc > /microsd_ufs/boot/menusets.4th > /microsd_ufs/boot/modules > /microsd_ufs/boot/screen.4th > /microsd_ufs/boot/shortcuts.4th > /microsd_ufs/boot/support.4th > /microsd_ufs/boot/uboot > /microsd_ufs/boot/version.4th > /microsd_ufs/boot/zfs > /microsd_ufs/etc > /microsd_ufs/etc/hostid > /microsd_ufs/lost+found >=20 > Almost no world content. /microsd_ufs/boot/loader.conf > has (in part): >=20 > vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root" > kern.cam.boot_delay=3D10000 > vfs.mountroot.timeout=3D10 > vfs.root_mount_always_wait=3D1 >=20 > That vfs.root.mountfrom notation redirects to the > USB3 drive for world but the /boot/loader.conf and > /boot/kernel/kernel and /etc/hostid were first > loaded from the e.MMC media, not the USB drive. >=20 > As I have it, the USB3 drive also has a copy of > the same /boot/... and such materials and load > module activity is from the USB3 copy. I have to > keep the two places tracking so nothing ends up > mismatching. >=20 >>> You might move (not copy) the MSDOSFS material >>> between the microsd card and the usb drive during >>> experiments, avoiding having duplications. There >>> is the possibility of instead renaming things so >>> files are not found on a partition, for example. >>> A similar point goes for UFS materials: avoid >>> having multiple viable-for-booting UFS file >>> systems present. >>>=20 >>> As stands, things seem too hard to track for me >>> to be of much help. Please make things obvious for >>> what was in use by making the material uniquely >>> placed (for the form that can be used). >>>=20 >> I believe the experiment above (deleting UFS on microSD,=20 >> hiding the DOS files on USB) has been an equivalent=20 >> configuration. It looks like control passes in some way=20 >> between the DOS slices, though how is unclear. >=20 > I do not agree to that specific interpretation of the > sequence you did (on the evidence currently available). > Until "1 Storage Device(s) found" is automatic this > later-stage material is too late to yet be relevant > or to have an appropriate context. >=20 > I'm staying focused on getting the "1 Storage Device(s) > found" to be automatic. Absent that you are likely stuck > with doing something similar to be Rock64 e.MMC way of > working --where /boot/loader.conf and /boot/kernel/kernel > and /etc/hostid for early activity is from a UFS > partition on the microsd card. >=20 >>> Separate issues/questions: >>>=20 >>> Do you have the file "timeout" in the MSDOSFS, in >>> addition to config.txt and the like? If not, I >>> recommend including it. >>>=20 >> Yes, it's been tried on both microSD and USB devices.=20 >> Seems like the only one that can matter is on microSD. >>=20 >>=20 >>> What other RPi* firmware controls for having >>> various deliberate RPi* firmware delays do you >>> have set up? >>>=20 >>=20 >> The Raspberry Pi config.txt description lists several delay commands >> that can be placed in config.txt. None seem related to USB discovery, >> might any come into play early enough to be useful? They're named >> bootcode_delay >> boot_delay >> boot_delay_ms >>=20 >> I tried them casually and didn't notice much change. Are they worth >> revisiting more carefully?=20 >=20 > See my earlier notes. >=20 >>> It is not so much that these would be sufficient, >>> but they do establish some context before U-Boot >>> is even active. It could be important to >>> understand that context. (Unsure at this point.) >>>=20 >>>=20 >>>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >>>>> (They also later mentioned using "usb_pgood_delay=3D2000\0" >>>>> instead, a figure they found in a bunch of configrations.) >>>>>=20 >>>> The Pi3 in question is capable of booting from solid-state USB >>>> storage without any microSD card, but fails to detect a mechanical >>>> disk. Which is the appropriate u-boot-rpi3 port to tamper with? I=20= >>>> tried sysutils/u-boot-rpi3 as an upgrade but that simply froze.=20 >>>> The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds >>>> the USB mechanical disk, but erratically.=20 >>>=20 >>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 >>> as I remember: it is set up for both the RPI3 and RPI4. Given that >>> it works some, that would be the U-Boot port I would experiment >>> with if I was doing the experiments. >>>=20 >>>>> So something somewhat analogous might help if you are willing >>>>> to build and use your own u-boot port variant. >>>>=20 >>>> Obviously, that's a fraught enterprise at my skill level.... >>>> I'm still somewhat hazy on the actual boot sequence when >>>> chaining from microSD to USB.=20 >>>=20 >>> Having the extra text in the U-Boot build does not really >>> depend on the chaining order question. >>>=20 >>> But, to repeat (sticking to the simpler context), >>> the order is: >>>=20 >>> MSDOSFS: (all on one of: microsd card vs. usb drive) >>> RPi* firmware (I do not report the file-level sequencing) >>> U-Boot >>> FreeBSD loader (which uses information from U-Boot) >>>=20 >>> UFS: (both: together on one of: microsd card vs. usb drive) >>> FreeBSD kernel >>> FreeBSD world >>>=20 >>>=20 >>>> Indeed, it's unclear how or if u-boot plays a role in starting=20 >>>> RasPiOS. The term u-boot isn't found on the Raspberry Pi doc=20 >>>> website, and the Pi isn't mentioned in the Denx manuals. Those >>>> discoveries surprised me. >>>=20 >>> RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some >>> forms of a linux kernel directly and that is what RaspiOS and >>> RaspiOS64 are doing.=20 >>=20 >> That clears up a major misunderstanding, thank you! >>=20 >>> That is why the config.txt type of content >>> makes no mention of u-boot or of any kernel=3D assignment in RaspiOS >>> and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=3D >>> and an explicit *u-boot*.bin as the value. >>=20 >> Without thinking about it very carefully I tried to use the >> "bootcode.bin-only" method for booting an older Pi2 from a >> usb hard disk, as described in >> = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#spec= ial-bootcode-bin-only-boot-mode >> It worked on the Pi2 but failed on the Pi3, causing an immediate = hang. >=20 > This gets back into the use of a config.txt with a > bootcode_delay assignment also being in the MSDOSFS > on the microsd card and the file timeout also being > in the MSDOSFS on the microsd card. Only if those > delays together can lead to the USB drive being > accessible will it get any farther. >=20 > I'd suggest such experiments. The vintage of bootcode.bin > matters as I understand. >=20 >> Might that avenue be worth pursuing? In hindsight, that it worked on = a >> Pi2 is quite surprising. =20 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 18 05:20:36 2021 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 8E34718F9354 for ; Sat, 18 Dec 2021 05:20:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGDhc24Z4z3lcK for ; Sat, 18 Dec 2021 05:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639804841; bh=i1o+lQmhnqub6tnDwg88Jd+lBRCavvD51lD9SYQsYOI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Da8ra1eIhQGSiGOEsjNb3qjomrRnmKPoeLa1Feh8JyvbbkZX/7idLh77gTud3RsX/6v7Sz04BIMwhK3GK49Ul9bBwFvqiTtBLhhicocgv+vYXKkb5fGxo5PzgqGYeNWlLGhe82EFt5iVpDFKaES7drBG8ZajTq8gvq3HRU0CGKXUuNNRsfQBr3xQ+QB+sEEwSIMgSJFdRzBGFj59EHLDnF4sqKrkt6uEai9beGhvHnwPpagX4RKIqjm5fBH+O2R//V/scbzBZ2F+35bv0CHdV+5bSkKCsJNSeQGEqWdqnRCl/ThZeQOTUFsqlZBgaQTQkst0DzmEYmwn5CRo7GyN4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639804841; bh=V+fyLugztNXwjJrxCZeOaFNOu1h8NHN3TYFhyX2JCfC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lZesA2lv9QKNa/SkrljCfuJuxa0C17M/WJ4aNnZRHG8O+yEkM8/jGqjVWReGoEDnRgZZ7igOt7kZBtIX85xxKQ3+avGv/pU3Jc8qn9+s8XcArpJI3WEr5jKZ44HBfijMn/Kke6ls5cvuUNDkQ90n8CqUffwrnDfX6Da+yScnMKCcMrTwTpkcKk1Ffe1qOVId1KyOsoZy/GfaMRKeE1SCxnmHHUa/GcHltOPSFyU/MvVCQWEf++IPhT+ahWlfnUNuuQ8UPhFIT+Os/Tr/IbX+h2vPD4/tAS7qLak+susprnqsx+xfM3z0GirOVT2/qF289b2MMLakfckz9H8UIi6hMQ== X-YMail-OSG: rcMXTKkVM1kc9Rx_DRZgc4uUlCuJ07VMjl07oYXmtwufdC0IhFeiMbGmm5aLa5q CufG.oPVgjwnYi7YqtjDXldrev8IwDucMTX_NiIpJtCG8KMoiE8F3vWLE2RJfc8MeD0Pfkp_j1vl QQPZ7Pt2zN2SNOInIcWEH533CK72iUrcrV9q2RzqUqPQMYLgq16NompQDz6e_JZrRmWawzQupa8U j22lyKJCkmrHJqttKlB8XG9I_g9ouowSHWsmgLUJhaJ2Fu0wSAJ6TqYXqxNJAjAZ1ySLplMqYr1x Xfi0n77ams8RFWfe30qBUABo.oltnuEdz3aN5FG4bPUaXNZj4GNk9oPRe.MgN7dqWv_uyY.gFfqN hGiONqTs32BFz7ipjMoHp2YtB0vLvAwU5v.HUFmmLijeg3.c2eSf7vLsYJpZZsFNWzBHlftrCBHg Agu0GvtMP.Swr_tQx6DLCJKBXlrwMInZ7Y5LLgfEOZgguL_OuJAeduarVaoB8t3LjFxPWAe3GZ5z 6DjtiN829XSDSEgil4WUSE3oKnYTzSlWxrUoLXxBNjaFdBH73Q0e_ni7pIAtSkGWrAlS6l8cn3Oe gMUESDLo0k2RpWVDRKyN1yXLvw.YR7Iuy1ElgRebkf3bZY66RJHW_Bd31pLYOs_iC3kV5nWjIMkL 5SbkNaCvofRtP8ZIfuL_SYH5nOOVcWNj2eGvIHyMocp_3jM6_uFwI4a2ja8DGIW4ND_n5krFlrj3 oRktT3ms06si2V4mGYSlP.92r31y9EddNcjUFW0.IHnjcJtbFR.9L8x7QJ9hpunuXLG6waI0B7yf zeDR8QGMFGbO_emEDcaI.rU_crounA1BDSyiq3KAWI7zdcnbRSDuiyiqIC3xSZ2_zzBSSgyc1fWb auy0yFRYmxnH9GdHr.ABUsMUpSt.XMUby0Y4pI3HY.Ue82nKLUgzWzfVdlOdhUWKxoqf6GsHPyta JWJzwdSJWq4twwum321lSmKkEpZ4P9_h_TFc2FVRQ60S54ZYiCeK9cGm_cYZRw_uT1B16ZdkGZ84 Dvl4KjU7QJyfdxIMPQ5Qfe5W84Nh5uEwLat3Mr5ACRJbb0eluY8RUWRcXkOrnHyKtLNWG5waKcR_ 0xF7GDks1Od2g_.QEMeGc_ONmiL0myu21s3BDGdFA_ttZi7vglcuHq7PcQR2c6Xf4gEzmeoeZkOr 9GNkjjCgUcRif_yOtT0g64ajRk_0x_E0A70i1xvX6ffkzdlqCfLBugVbYqJyFiKYI48untKBpO.B H3_46gFXHQiR5HyZBunB8RJE851fiIDh3ZC2lyh2uxlcXIw6KbhLb.gMC0QOAXUJ_um52AGBehM7 4zLzXTptNyzHwGAwfJBjsgpp1vYrQ6BV801GtbkbjPjC2iDgUuFOnD1.YkxY56QjsdemU7c3Wm__ Gg34lEH.FZLb.jIuRSp8pTBnWgHbJRmxqqmgCNiAiI2vcHTPqVmSLiHSnOYKZKfntkcQrZEfDnTX 5vgi0i8Yp1tWNmy5tgedg.MryQWHl_4Vi2nItNlfJLVkupQZn7jtPgGBcC4pMMFbO4pqOVjXQZJa IqgDRPxrPIJ3dYOYRBTTOp5UwPR1U_OhBt.WoKc8lhTeriGeM4IgoMOw4JOkZUwfJ37._Qh3mHmx 5.oN6Ez0eOwgFUCGdlm6foMhQz.BSqtTSwmJ1XNEnSCKe4PElxDPkDFH9dqdnGCYftF9WpANOa2i .2WA7T3QxTWxpiG2U9bqDX.AKeQvGD8tVsnIncg6T.IzjHnym4QTYn5PDmH4gFsR.tcypHSCd7Y. nblMuozLNvi0OSab9S7J0DVHb_5g9AS6ysAYvEwA3ANWvjU6BJ3QKKLI0i7ZTel8YpLc9uTYcZs5 Tg9TK7Bm_Vgrol2huE72BKbLnx78YgDKXaV2OByhIHIDvCdqt14Y7Zrt5pT_VlvEs6f9XONIY0XE 27NWWXmx0RfaVA9yXK8GK22RCcMQurza7ZZ75v86LNL.kthoPPJyP8jIT17XM5hpDpt1tA7paEsm 2tlV6gtAyY19T36nauY52kjpsMaT.n5AZ41XEIhrJIcK5hj9MczUvVg.BGx3B2sOCKA.99BwBAqS TiT.3.kRhpi7c7qjihJ5JSk09Ah5Tm_splOzBqD1Sa7jYDFeRzHgBhXmf8NiawB1tKPWP6sp.IOC ZLkDeJB1aDWPV7UPd848swvtpNbAqN.Sfl2R4iG3n6xAPOmG4Hn9ZmHIUKoFgXQNb0FxKz0bCUp8 Tbsv1I2y70gMZAlSo3f8qe21oNnxiSW7NQDe97g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Dec 2021 05:20:41 +0000 Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5dd41b61a63f4e4b49e0dd47611ee932; Sat, 18 Dec 2021 05:20:38 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> Date: Fri, 17 Dec 2021 21:20:36 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGDhc24Z4z3lcK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Da8ra1eI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.47 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; NEURAL_HAM_SHORT(-0.97)[-0.968]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 21462 Lines: 592 On 2021-Dec-17, at 19:12, Mark Millard wrote: > On 2021-Dec-17, at 19:02, Mark Millard via freebsd-arm = wrote: >=20 >> On 2021-Dec-17, at 16:59, bob prohaska wrote: >>=20 >>> On Thu, Dec 16, 2021 at 11:00:46PM -0800, Mark Millard wrote: >>>> On 2021-Dec-16, at 17:36, bob prohaska wrote: >>>>=20 >>>>>=20 >>>>> Yes, the microSD contains a dd of=20 >>>>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img >>>>> The DOS partition is writeable, AFAIK. >>>>=20 >>>> Hmm. That means there is also a UFS root with >>>> a kernel and world on the microsd card. Both >>>> the microsd card and the USB drive contain >>>> contain such, as well as each having an >>>> /etc/fstab (and so on). >>>>=20 >>>> Having multiple such makes for a mess for >>>> controlling which is used (and knowing which >>>> is used). What is the first stage that you >>>> made sure the USB drive was in use and how >>>> did you make sure? >>>>=20 >>>=20 >>> I installed a microSD containing only the FAT slice from=20 >>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img, the FreeBSD >>> slice being deleted using gpart. There is a timeout file. >>=20 >> Ultimately, you may need to publish a full capture of the >> debug output that goes to the serial console when such >> debug output has been fully enabled. This could end up >> being for each of several variations tried. >>=20 >> Did you still have the MSDOSFS material on the USB in a >> viable form as well? >>=20 >> https://www.raspberrypi.com/documentation/computers/config_txt.html >> reports that there are boot options that can go in config.txt : >>=20 >> bootcode_delay >> boot_delay >> boot_delay_ms >>=20 >> Quoting . . . >>=20 >> QUOTE >> bootcode_delay >>=20 >> The bootcode_delay command delays for a given number of seconds in = bootcode.bin before loading start.elf: the default value is 0. >> END QUOTE >>=20 >> QUOTE >> boot_delay >>=20 >> The boot_delay command instructs to wait for a given number of = seconds in start.elf before loading the kernel: the default value is 1. = The total delay in milliseconds is calculated as (1000 x boot_delay) + = boot_delay_ms. This can be useful if your SD card needs a while to get = ready before Linux is able to boot from it. >>=20 >> boot_delay_ms >>=20 >> The boot_delay_ms command means wait for a given number of = milliseconds in start.elf, together with boot_delay, before loading the = kernel. The default value is 0. >> END QUOTE >>=20 >> (So boot_delay_ms is only for smaller scale adjustments and can >> be ignored here.) >>=20 >> Here "loading the kernel" means what config.txt was told was >> the kernel: some *u-boot*.bin for the FreeBSD context. >>=20 >>=20 >> So one experiment is to have only bootcode.bin and a config.txt >> on the microsd card's MSDOSFS, specifying a significantly >> large value for bootcode_delay . The hope would be to be able >> to get the start*.elf file and the rest from the USB drive. >>=20 >> If that does not work, then the next is to have the RPi* firmware >> only on the microsd card's MSDOSFS and have config.txt also >> specify a significantly large value for boot_delay . This >> first variation would not have a *u-boot*.bin or the FreeBSD >> loader on the microsd card's MSDOSFS but only on the USB >> drive's MSDOSFS. >>=20 >> If that does not work, then the next variation moves just the >> *u-boot*.bin file to the microsd card. >>=20 >> (If that fails then controlling U-Boot's delays can be involved. >> For now I only list the path of leaving U-Boot's delays as they >> are: one short branch of the exploration.) >>=20 >> If that does not work, then the next variation moves just the >> FreeBSD loader file to the microsd card. >=20 > For the above one I missed a word, making things unclear. So, > instead: >=20 > If that does not work, then the next variation ALSO moves just > the FreeBSD loader file to the microsd card. ( *u-boot*.bin > stays on the microsd card from the prior step. ) >=20 >> With that I'll stop listing things to test, pending results on >> what I've listed. >>=20 >>> A hands-off warm boot reports >>> resetting system ...=20 >>>=20 >>> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >>>=20 >>> DRAM: 948 MiB >>> RPI 3 Model B (0xa02082) >>> MMC: mmc@7e300000: 0 >>> Loading Environment from FAT... In: serial >>> Out: vidconsole >>> Err: vidconsole >>> Net: No ethernet found. >>> starting USB... >>> Bus usb@7e980000: USB DWC2 >>> scanning bus usb@7e980000 for devices... 5 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) found >>=20 >> I would need to also see the RPi* firmware's prior >> debug output to be able to interpret this. I can not >> tell for sure which device's U-Boot copy is operating >> for the above. I'd guess that is the the micrsd card's >> MSDOSFS one. >>=20 >>> Hit any key to stop autoboot: 0=20 >>> switch to partitions #0, OK >>> mmc0 is current device >>> Scanning mmc 0:1... >>=20 >> This looks to be getting a copy of the FreeBSD loader >> from the microsd card's MSDOSFS. >>=20 >> The FreeBSD loader will only see the same Storage Devices >> that U-Boot did: it gets the information from U-Boot. >>=20 >>> Found EFI removable media binary efi/boot/bootaa64.efi >>=20 >> There was a FreeBSD loader in the microsd card's >> MSDOSFS. >>=20 >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> Scanning disk mmc@7e300000.blk... >>> Found 2 disks >>> No EFI system partition >>> BootOrder not defined >>> EFI boot manager: Cannot load any image >>> 1259212 bytes read in 125 ms (9.6 MiB/s) >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>> Booting /efi\boot\bootaa64.efi >>=20 >> That FreeBSD loader is what it is using, not one >> from the USB drive. >>=20 >>> [whitespace deleted] >>> Consoles: EFI console =20 >>> Reading loader env vars from /efi/freebsd/loader.env >>> Setting currdev to disk0p1: >>=20 >> "disk0p1" is U-Boot terminology for a drive, despite >> this being the FreeBSD loader's output. The FreeBSD >> loader uses the U-Boot information, not FreeBSD's >> information. >>=20 >>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>=20 >>> Command line arguments: loader.efi >>> Image base: 0x39e03000 >>> EFI version: 2.80 >>> EFI Firmware: Das U-Boot (rev 8224.4096) >>> Console: comconsole (0) >>> Load Path: /efi\boot\bootaa64.efi >>> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) >>> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)/HD(1,0x01,0,0x81f= ,0x18fa8) >>=20 >> This is reporting where the FreeBSD loader was found. >> It indicates that disk0p1 was the microsd card's >> MSDOSFS. >>=20 >>> Setting currdev to disk0p1: >>=20 >> The microsd card's MSDOSFS again. >>=20 >>> ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >>=20 >> There is no FreeBSD directory-tree there to find things >> like /boot/lua/loader.lua in. >>=20 >> Currently we are trying to have the /boot/lua/loader.lua come >> from the USB drive's UFS file system, not the microsd card. >>=20 >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK=20 >>>=20 >>> AIUI, disk0p1 is the microSD, which has no /boot/lua/loader.lua >>> That makes sense. If u-boot finds the USB mass storage device >>> then running=20 >>> run bootcmd_usb0 starts the system successfully. >>>=20 >>> It does appear that the FAT partition on the USB disk is involved. >>=20 >> I see no evidence of that above. (Below is a different context.) >>=20 >>> If I hide the contents of da0s1 by placing them in a subdirectory >>> the boot fails, even if u-boot has found the USB disk: >>>=20 >>> Hit any key to stop autoboot: 0=20 >>> U-Boot> usb reset >>> resetting USB... >>> Bus usb@7e980000: USB DWC2 >>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) found >>>=20 >>> [Note that the six devices include the disk, it can be seen in usb = tree. >>> For some reason it isn't recognized as a mass storage device.] >>>=20 >>> U-Boot> editenv usb_pgood_delay >>> edit: 2 >>> U-Boot> usb reset >>> resetting USB... >>> Bus usb@7e980000: USB DWC2 >>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found >>> scanning usb for storage devices... 1 Storage Device(s) found >>> U-Boot> run bootcmd_usb0 >>>=20 >>> Device 0: Vendor: SABRENT Rev: 1214 Prod:=20 >>> Type: Hard Disk >>> Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512) >>> ... is now current device >>> Scanning usb 0:1... >>> U-Boot>=20 >>> and there it stops. Looks like both FAT partitions have a role to = play. >>=20 >> That is not clear to me. But I'd rather be lookning into >> earlier stages at this point, so that "1 Storage Device(s) found" >> hopefully ends up being automatic. >>=20 >> If we get that to be automatic, then what is happening here >> becomes the next area to investigate. But the investigation >> is not far enough along to justify investigating this now. >>=20 >>> An earlier experiment tried booting the microSD card in a USB = adapter, >>> That worked correctly with nothing in the microSD slot, so the = internal >>> "boot from USB" feature might work if it could be slowed down = sufficiently.=20 >>=20 >> Agreed, that the first thing is to get it to start up >> the disk and wait for it. There may be more at issue >> after that. >>=20 >>>> The order of activity is: >>>>=20 >>>> MSDOSFS: (all on one of: microsd card vs. usb drive) >>>> RPi* firmware (I do not report the file-level sequencing) >>>> U-Boot >>>> FreeBSD loader (which uses information from U-Boot) >>>>=20 >>>> UFS: (both: together on one of: microsd card vs. usb drive) >>>> FreeBSD kernel >>>> FreeBSD world >>>>=20 >>>> (I do not specify which MSDOSFS is used when >>>> there are multiple viable ones in separate places. >>>> Similarly for UFS.) >>>>=20 >>> =46rom the experiment today it seems both are required. >>=20 >> I do not get such an interpretation from your experiment. >> Until "1 Storage Device(s) found" happens automatically >> the context is not nicely comparable for the later stages. >>=20 >>> The first discovers the USB disk, the second uses that >>> information to proceed further.=20 >>>=20 >>>>=20 >>>> (It is technically possible to have kernel vs. >>>> world in separate UFS partitions, possibly on >>>> separate media. I've an example context that I >>>> deal with that way to avoid a U-boot limitation >>>> for the device: the kernel can find the world >>>> where the U-Boot/FreeBSD-Loader can not. (The >>>> FreeBSD loader depends on what USB can find: it >>>> does not look elsewhere.) I only mention this >>>> in case I need to reference it in the future, >>>> avoiding a surprise in such a case. Otherwise >>>> ignore the complication.) >>>>=20 >>>=20 >>> Are you referring to a case where the root is on >>> microSD but /usr and friends is on a USB device?=20 >>=20 >> Again: I suggest ignoring the details of this for >> now. It would just confuse things. But if you >> insist: >>=20 >> On the Rock64 I have a e.MMC in use instead of a >> microsd card, and in the end the world is on a >> USB3 SSD. But the U-Boot involved can not access >> the USB3 --os neither can the FreeBSD loader. >> The FreeBSD kernel is the first stage that can >> access USB3. >>=20 >> The e.MMC has the MSDOSFS. It has an partial >> copy of what would normally be some of the USB3 >> drive's content. (I named the mount point >> microsd_ufs before I switched to the e.MMC .) >> It has only (much hidden in ". . ."s). >>=20 >> # find /microsd_ufs -print | sort | less >> /microsd_ufs >> /microsd_ufs/.snap >> /microsd_ufs/COPYRIGHT >> /microsd_ufs/boot >> /microsd_ufs/boot/beastie.4th >> /microsd_ufs/boot/boot1.efi >> /microsd_ufs/boot/brand-fbsd.4th >> /microsd_ufs/boot/brand.4th >> /microsd_ufs/boot/check-password.4th >> /microsd_ufs/boot/color.4th >> /microsd_ufs/boot/copy_boot_to_microsd.sh >> /microsd_ufs/boot/defaults >> /microsd_ufs/boot/defaults/loader.conf >> /microsd_ufs/boot/delay.4th >> /microsd_ufs/boot/dtb >> . . . >> /microsd_ufs/boot/kernel >> /microsd_ufs/boot/kernel/accf_data.ko >> /microsd_ufs/boot/kernel/accf_dns.ko >> . . . >> /microsd_ufs/boot/kernel/kernel >> . . . >> /microsd_ufs/boot/loader.4th >> /microsd_ufs/boot/loader.conf >> /microsd_ufs/boot/loader.conf.d >> /microsd_ufs/boot/loader.efi >> /microsd_ufs/boot/loader.help >> /microsd_ufs/boot/loader.rc >> /microsd_ufs/boot/loader_4th.efi >> /microsd_ufs/boot/loader_lua.efi >> /microsd_ufs/boot/loader_simp.efi >> /microsd_ufs/boot/logo-beastie.4th >> /microsd_ufs/boot/logo-beastiebw.4th >> /microsd_ufs/boot/logo-fbsdbw.4th >> /microsd_ufs/boot/logo-orb.4th >> /microsd_ufs/boot/logo-orbbw.4th >> /microsd_ufs/boot/lua >> /microsd_ufs/boot/lua/cli.lua >> /microsd_ufs/boot/lua/color.lua >> /microsd_ufs/boot/lua/config.lua >> /microsd_ufs/boot/lua/core.lua >> /microsd_ufs/boot/lua/drawer.lua >> /microsd_ufs/boot/lua/gfx-beastie.lua >> /microsd_ufs/boot/lua/gfx-beastiebw.lua >> /microsd_ufs/boot/lua/gfx-fbsdbw.lua >> /microsd_ufs/boot/lua/gfx-orb.lua >> /microsd_ufs/boot/lua/gfx-orbbw.lua >> /microsd_ufs/boot/lua/hook.lua >> /microsd_ufs/boot/lua/loader.lua >> /microsd_ufs/boot/lua/menu.lua >> /microsd_ufs/boot/lua/password.lua >> /microsd_ufs/boot/lua/screen.lua >> /microsd_ufs/boot/menu-commands.4th >> /microsd_ufs/boot/menu.4th >> /microsd_ufs/boot/menu.rc >> /microsd_ufs/boot/menusets.4th >> /microsd_ufs/boot/modules >> /microsd_ufs/boot/screen.4th >> /microsd_ufs/boot/shortcuts.4th >> /microsd_ufs/boot/support.4th >> /microsd_ufs/boot/uboot >> /microsd_ufs/boot/version.4th >> /microsd_ufs/boot/zfs >> /microsd_ufs/etc >> /microsd_ufs/etc/hostid >> /microsd_ufs/lost+found >>=20 >> Almost no world content. /microsd_ufs/boot/loader.conf >> has (in part): >>=20 >> vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root" >> kern.cam.boot_delay=3D10000 >> vfs.mountroot.timeout=3D10 >> vfs.root_mount_always_wait=3D1 >>=20 >> That vfs.root.mountfrom notation redirects to the >> USB3 drive for world but the /boot/loader.conf and >> /boot/kernel/kernel and /etc/hostid were first >> loaded from the e.MMC media, not the USB drive. >>=20 >> As I have it, the USB3 drive also has a copy of >> the same /boot/... and such materials and load >> module activity is from the USB3 copy. I have to >> keep the two places tracking so nothing ends up >> mismatching. >>=20 >>>> You might move (not copy) the MSDOSFS material >>>> between the microsd card and the usb drive during >>>> experiments, avoiding having duplications. There >>>> is the possibility of instead renaming things so >>>> files are not found on a partition, for example. >>>> A similar point goes for UFS materials: avoid >>>> having multiple viable-for-booting UFS file >>>> systems present. >>>>=20 >>>> As stands, things seem too hard to track for me >>>> to be of much help. Please make things obvious for >>>> what was in use by making the material uniquely >>>> placed (for the form that can be used). >>>>=20 >>> I believe the experiment above (deleting UFS on microSD,=20 >>> hiding the DOS files on USB) has been an equivalent=20 >>> configuration. It looks like control passes in some way=20 >>> between the DOS slices, though how is unclear. >>=20 >> I do not agree to that specific interpretation of the >> sequence you did (on the evidence currently available). >> Until "1 Storage Device(s) found" is automatic this >> later-stage material is too late to yet be relevant >> or to have an appropriate context. >>=20 >> I'm staying focused on getting the "1 Storage Device(s) >> found" to be automatic. Absent that you are likely stuck >> with doing something similar to be Rock64 e.MMC way of >> working --where /boot/loader.conf and /boot/kernel/kernel >> and /etc/hostid for early activity is from a UFS >> partition on the microsd card. >>=20 >>>> Separate issues/questions: >>>>=20 >>>> Do you have the file "timeout" in the MSDOSFS, in >>>> addition to config.txt and the like? If not, I >>>> recommend including it. >>>>=20 >>> Yes, it's been tried on both microSD and USB devices.=20 >>> Seems like the only one that can matter is on microSD. >>>=20 >>>=20 >>>> What other RPi* firmware controls for having >>>> various deliberate RPi* firmware delays do you >>>> have set up? >>>>=20 >>>=20 >>> The Raspberry Pi config.txt description lists several delay commands >>> that can be placed in config.txt. None seem related to USB = discovery, >>> might any come into play early enough to be useful? They're named >>> bootcode_delay >>> boot_delay >>> boot_delay_ms >>>=20 >>> I tried them casually and didn't notice much change. Are they worth >>> revisiting more carefully?=20 >>=20 >> See my earlier notes. >>=20 >>>> It is not so much that these would be sufficient, >>>> but they do establish some context before U-Boot >>>> is even active. It could be important to >>>> understand that context. (Unsure at this point.) >>>>=20 >>>>=20 >>>>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >>>>>> (They also later mentioned using "usb_pgood_delay=3D2000\0" >>>>>> instead, a figure they found in a bunch of configrations.) >>>>>>=20 >>>>> The Pi3 in question is capable of booting from solid-state USB >>>>> storage without any microSD card, but fails to detect a mechanical >>>>> disk. Which is the appropriate u-boot-rpi3 port to tamper with? I=20= >>>>> tried sysutils/u-boot-rpi3 as an upgrade but that simply froze.=20 >>>>> The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds >>>>> the USB mechanical disk, but erratically.=20 >>>>=20 >>>> FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 >>>> as I remember: it is set up for both the RPI3 and RPI4. Given that >>>> it works some, that would be the U-Boot port I would experiment >>>> with if I was doing the experiments. >>>>=20 >>>>>> So something somewhat analogous might help if you are willing >>>>>> to build and use your own u-boot port variant. >>>>>=20 >>>>> Obviously, that's a fraught enterprise at my skill level.... >>>>> I'm still somewhat hazy on the actual boot sequence when >>>>> chaining from microSD to USB.=20 >>>>=20 >>>> Having the extra text in the U-Boot build does not really >>>> depend on the chaining order question. >>>>=20 >>>> But, to repeat (sticking to the simpler context), >>>> the order is: >>>>=20 >>>> MSDOSFS: (all on one of: microsd card vs. usb drive) >>>> RPi* firmware (I do not report the file-level sequencing) >>>> U-Boot >>>> FreeBSD loader (which uses information from U-Boot) >>>>=20 >>>> UFS: (both: together on one of: microsd card vs. usb drive) >>>> FreeBSD kernel >>>> FreeBSD world >>>>=20 >>>>=20 >>>>> Indeed, it's unclear how or if u-boot plays a role in starting=20 >>>>> RasPiOS. The term u-boot isn't found on the Raspberry Pi doc=20 >>>>> website, and the Pi isn't mentioned in the Denx manuals. Those >>>>> discoveries surprised me. >>>>=20 >>>> RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some >>>> forms of a linux kernel directly and that is what RaspiOS and >>>> RaspiOS64 are doing.=20 >>>=20 >>> That clears up a major misunderstanding, thank you! >>>=20 >>>> That is why the config.txt type of content >>>> makes no mention of u-boot or of any kernel=3D assignment in = RaspiOS >>>> and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=3D >>>> and an explicit *u-boot*.bin as the value. >>>=20 >>> Without thinking about it very carefully I tried to use the >>> "bootcode.bin-only" method for booting an older Pi2 from a >>> usb hard disk, as described in >>> = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#spec= ial-bootcode-bin-only-boot-mode >>> It worked on the Pi2 but failed on the Pi3, causing an immediate = hang. >>=20 >> This gets back into the use of a config.txt with a >> bootcode_delay assignment also being in the MSDOSFS >> on the microsd card and the file timeout also being >> in the MSDOSFS on the microsd card. Only if those >> delays together can lead to the USB drive being >> accessible will it get any farther. >>=20 >> I'd suggest such experiments. The vintage of bootcode.bin >> matters as I understand. >>=20 >>> Might that avenue be worth pursuing? In hindsight, that it worked on = a >>> Pi2 is quite surprising. =20 >>>=20 >>=20 One point for testing that could be a simplification initially: booting just from a microsd card with the USB drive powered and attached already, even though the USB drive is not boot-media for this kind of test. The goal would be to get the boot to report something other than than the 0 in: scanning usb for storage devices... 0 Storage Device(s) found That line is not a count of bootable USB storage devices, but a count of all the accessible USB storage devices found. it reports useful information even for booting from a microsd card, including reporting if the USB device was not accessible. This could be used to learn what controls the issue without moving things between the USB media and the microsd card. (Once learned, there could be more to do.) I should have noted: so far the only option that has evidence for being sufficient is having a build of *u-boot*.bin that has usb_pgood_delay already assigned. I'm not aware of UEFI style U-Boot's reading in any configuration files or executing any scripts to control usb_pgood_delay from the outside. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 18 12:06:36 2021 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 9F1D118F3C2A for ; Sat, 18 Dec 2021 12:06:36 +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 4JGPhr22spz4vwk for ; Sat, 18 Dec 2021 12:06:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 2667B7393 for ; Sat, 18 Dec 2021 12:06:36 +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 1BIC6aPD025537 for ; Sat, 18 Dec 2021 12:06:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BIC6aJg025536 for freebsd-arm@FreeBSD.org; Sat, 18 Dec 2021 12:06:36 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 260514] How to get Office 365 help? Date: Sat, 18 Dec 2021 12:06:36 +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: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: davidjones64619@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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639829196; 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=yUjB80L9+qT5Be2bvQVdx28IWeP/6YH4L7urur6cdq8=; b=w3U0J8OVrHVbAyKnI1aQ1fCXT/eGqBZzJdGESuhTRM58S7cz2uIE/izSIWb7RNuUNizyaO wlQvTMGXWAF+vyHqEIBMvq35uqCF1/AuC7Gex5ZMMoINFV46CgsSEi7nqbNEr43rybxZVZ +hk5ZKpeqfSNAa3G1s2o8UMDzI5zST93dGH4ehdOFlcS9ZHdGCrKWGoDSwvq8eewiiqkBI vOHMXYU9xET0g2yCvlaPyF7oBPYk4tnSVNZhXOK7aEdEKnlgpS1Rk19F+VLqPkFyJe9cDf LJxLAhXTfghFDyAeafNbZJfu6Jw+48lZTHeBRDIC2MxEIsXZ6y+opx2Dyz7c6g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639829196; a=rsa-sha256; cv=none; b=rf6cPpt05/DNmhoa2kUYf2rY4cMvOZo62GZRi1uoDs5s4KZ4WfGJCB15i8dDCBhith0HJk KwwaT7HFmGSHvKAYgY5/6lLFTv+tGDBrcuvasmVuWCppjJQXfEct0b8WGaDcJ9/RBIhB9k u5JMjWfX/rVcOmvW/jM/DYfd2D0QnkVGFRu/EkLtkwxOGuFvCGM4oTpzD58tP1hsxou3de KUpQtXvKQWGmjonr3PktsgaqkAAjSd6QSOC/x3uXj68u9h7Xx2daiW5ji53BzhpVgihDdC yqK2BCmlZXrmZrUvZsY3iHOihcgyjHr//zTf/w2JgAyAT396y3VpGSRQaAyfeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 923 Lines: 29 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260514 Bug ID: 260514 Summary: How to get Office 365 help? Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: davidjones64619@gmail.com You can either get an answer to your query in the community forum of Micros= oft 365. Or you can also submit your service request. For Office 365 help, do t= he following. Login to Microsoft 365 and tap =E2=80=98Support.=E2=80=99 Now choose =E2=80=98New service request.=E2=80=99 You can also call the toll free number for seeking support. https://www.emailsupport.us/microsoft-office-365-support --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Dec 18 22:35:43 2021 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 92E941900C46 for ; Sat, 18 Dec 2021 22:35:39 +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 4JGgfg2NVWz3sps for ; Sat, 18 Dec 2021 22:35:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BIMZhFG012230 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 14:35:44 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BIMZhQj012229; Sat, 18 Dec 2021 14:35:43 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Dec 2021 14:35:43 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211218223543.GA9484@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@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: 4JGgfg2NVWz3sps X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4105 Lines: 108 [subject modified to reflect changed emphasis, much snippage] On Fri, Dec 17, 2021 at 09:20:36PM -0800, Mark Millard wrote: > >> Until "1 Storage Device(s) found" is automatic this > >> later-stage material is too late to yet be relevant > >> or to have an appropriate context. > >> > >> I'm staying focused on getting the "1 Storage Device(s) > >> found" to be automatic. Absent that you are likely stuck > >> with doing something similar to be Rock64 e.MMC way of > >> working --where /boot/loader.conf and /boot/kernel/kernel > >> and /etc/hostid for early activity is from a UFS > >> partition on the microsd card. Agreed entirely. > >>>> It is not so much that these would be sufficient, > >>>> but they do establish some context before U-Boot > >>>> is even active. It could be important to > >>>> understand that context. (Unsure at this point.) > >>>> > >>>> > >>>>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. > >>>>>> (They also later mentioned using "usb_pgood_delay=2000\0" > >>>>>> instead, a figure they found in a bunch of configrations.) > >>>>>> It does appear that usb_pgood_delay is in milliseconds, not seconds as I initially thought. At present I don't think it helps. > >> > >> This gets back into the use of a config.txt with a > >> bootcode_delay assignment also being in the MSDOSFS > >> on the microsd card and the file timeout also being > >> in the MSDOSFS on the microsd card. Only if those > >> delays together can lead to the USB drive being > >> accessible will it get any farther. > >> > >> I'd suggest such experiments. The vintage of bootcode.bin > >> matters as I understand. > >> > > One point for testing that could be a simplification > initially: booting just from a microsd card with the > USB drive powered and attached already, even though > the USB drive is not boot-media for this kind of test. > So far all experiments have been done with the USB drive on a powered hub which is kept on. Until the USB drive is discovered it's hard to imagine how what's on the disk can matter, no? > The goal would be to get the boot to report something > other than than the 0 in: > scanning usb for storage devices... 0 Storage Device(s) found > > That line is not a count of bootable USB storage devices, but > a count of all the accessible USB storage devices found. it > reports useful information even for booting from a microsd > card, including reporting if the USB device was not accessible. Still, it was surprising to see the disk recognized by the usb-sata adapter name but not seen as a disk. Might there be a SMART control parameter that needs to be tweaked? The same disks and adapters work fine on two Pi4's without microSD. I've turned on bootcode.bin's uart and placed a diary of the experiments at http://www.zefox.net/~fbsd/slow_usb_notes The only configuration that makes any progress at all seems to be a fully-populated microSD FAT slice. > I should have noted: so far the only option that > has evidence for being sufficient is having a build > of *u-boot*.bin that has usb_pgood_delay already > assigned. I'm not aware of UEFI style U-Boot's > reading in any configuration files or executing any > scripts to control usb_pgood_delay from the outside. I'm becoming sceptical that usb_pgood_delay is relevant, after many reboots this morning. Indeed, I can't detect that the delays have a useful (or harmful) effect. They do seem to be active, in that pauses in serial console output change roughly in proportion to values set. I even tried putting usb_pgood_delay=20000 in config.txt, hoping that the firmware might pass on the value. No luck. Usb reset finds the disk after one to about six tries, seemingly at random, regardless of usb_pgood_delay bootcode.bin_delay or boot_delay So far, the disk has never been recognized as a mass storage device on the first try. I also tried putting program_usb_boot_timeout=1 in config.txt, to no avail. The line seemed to help on a Pi3 with a different usb-sata adapter and the same kind of disk. If you got this far, thanks for reading! bob prohaska From nobody Sat Dec 18 23:56:04 2021 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 7BE7B18E5E6F for ; Sat, 18 Dec 2021 23:56:13 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 4JGjRc4Tp8z4WKx for ; Sat, 18 Dec 2021 23:56:12 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pf1-x432.google.com with SMTP id k64so5381111pfd.11 for ; Sat, 18 Dec 2021 15:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tN9Xv7vfsHxqOOajFmmKsfsVoYpcktPWY9lNXKSG1mo=; b=eWncEGU2oVS4amIQZ6fpCGCrppIX31jbT5N5ghBE/XEpLXQlbVZCep3Qc9kUzCv7+b mQJdNQtc074S+mcfafVXp20E3t4m0ZaH/PDU+3BqBhmL3oL2ELkhN1u8TxSHEnwcVb3U M0LbsXbteoOofyAhR2wqfYiJ9HdXrrpDmOFHtaJOTKgADVHLUZZZqtZcMFCgb+0GPNVJ 4TKS43WUUcYKsOckakrqzoC21IXJvcZqqRQeNud+4dX2i6bn8SVzbAkCenJ/Gh9CLoEW /MCPs4GATA4qs+IYVl0mBfnb8QT1Pp3FMWFpjoLNrVqp1OFX9h6XMQpiymWAmn04c8K6 rA3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tN9Xv7vfsHxqOOajFmmKsfsVoYpcktPWY9lNXKSG1mo=; b=jYvQ1xrznSI1yyoLdQnexNG4D/ipcXSyYxw0aP7+W+xwYbUoaekbJqxgOvPxavgBtr SvqRY+pl8E1DVNApIkkZoTV2o3SqA3TxeaUNqVCMv7w45/45bIaZeChuiCT+xj6bzwvY WZ92ekQjeceTjok4wcc15YNuIheR81Tmv/TJrNxkoS2/K11ZOIVY/NchLErUzafCex4k GHbtcNhdsfc9loo628FFr5cR22V+5bYtNmw6+rrEeaAc1PNf1ilIQOJcyZSAkcTTnX30 1+nNxx3Rh6aULXVh7kWRncS3gzjI4llhkQLRiAfgLbAjcBKX9pRND9HHvdAzk2Rt99GC 0FrQ== X-Gm-Message-State: AOAM533Wr1RwK4zGCzikHMmEhiPbeWbUM63el2kE5/+QMIxowQZf/UUj LChZZtYCXC9TiVaN2cniqcC/z4/xmp86IQ== X-Google-Smtp-Source: ABdhPJyo3Q+++dkAvx250kjOLCOuf4+zqUoJxzC2YMK9BeaJIz1OdYafdfpHKs2DFjptYKTOCJGiIg== X-Received: by 2002:a63:dc0b:: with SMTP id s11mr8888722pgg.272.1639871771529; Sat, 18 Dec 2021 15:56:11 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id m10sm11982511pgv.75.2021.12.18.15.56.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Dec 2021 15:56:11 -0800 (PST) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot To: freebsd-arm@freebsd.org References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> From: MJ Message-ID: <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> Date: Sun, 19 Dec 2021 10:56:04 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20211218223543.GA9484@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JGjRc4Tp8z4WKx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eWncEGU2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::432 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-1.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::432:from]; NEURAL_HAM_SHORT(-0.98)[-0.976]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2548 Lines: 65 On 19/12/2021 9:35 am, bob prohaska wrote: > [subject modified to reflect changed emphasis, much snippage] > > On Fri, Dec 17, 2021 at 09:20:36PM -0800, Mark Millard wrote: >>>> Until "1 Storage Device(s) found" is automatic this >>>> later-stage material is too late to yet be relevant >>>> or to have an appropriate context. >>>> >>>> I'm staying focused on getting the "1 Storage Device(s) >>>> found" to be automatic. Absent that you are likely stuck >>>> with doing something similar to be Rock64 e.MMC way of >>>> working --where /boot/loader.conf and /boot/kernel/kernel >>>> and /etc/hostid for early activity is from a UFS >>>> partition on the microsd card. > > Agreed entirely. > >>>>>> It is not so much that these would be sufficient, >>>>>> but they do establish some context before U-Boot >>>>>> is even active. It could be important to >>>>>> understand that context. (Unsure at this point.) >>>>>> >>>>>> >>>>>>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >>>>>>>> (They also later mentioned using "usb_pgood_delay=2000\0" >>>>>>>> instead, a figure they found in a bunch of configrations.) >>>>>>>> > > It does appear that usb_pgood_delay is in milliseconds, not seconds > as I initially thought. At present I don't think it helps. > > >>>> >>>> This gets back into the use of a config.txt with a >>>> bootcode_delay assignment also being in the MSDOSFS >>>> on the microsd card and the file timeout also being >>>> in the MSDOSFS on the microsd card. Only if those >>>> delays together can lead to the USB drive being >>>> accessible will it get any farther. >>>> >>>> I'd suggest such experiments. The vintage of bootcode.bin >>>> matters as I understand. >>>> >> >> One point for testing that could be a simplification >> initially: booting just from a microsd card with the >> USB drive powered and attached already, even though >> the USB drive is not boot-media for this kind of test. >> > > So far all experiments have been done with the USB drive > on a powered hub which is kept on. Until the USB drive is > discovered it's hard to imagine how what's on the disk can > matter, no? My suggestion: Have you tried directly connecting the USB into the RPI4? I've had previous run-ins with RPI3B and powered hubs where it seems to be very slow to enumerate the hub and therefore the devices attached. Having said that, I have a RPI2 with 13R and two USB flash drives attached and it's a pure lottery for one of them to be recognized at boot (always the same one, an old transcend 16GB). Mark From nobody Sun Dec 19 00:51:34 2021 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 E716018F1182 for ; Sun, 19 Dec 2021 00:51:30 +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 4JGkgQ3Q6xz4cxv for ; Sun, 19 Dec 2021 00:51:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BJ0pZqk012486 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 16:51:35 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJ0pZVf012485; Sat, 18 Dec 2021 16:51:35 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Dec 2021 16:51:34 -0800 From: bob prohaska To: MJ Cc: freebsd-arm@freebsd.org Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219005134.GA12292@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.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: <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> X-Rspamd-Queue-Id: 4JGkgQ3Q6xz4cxv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 912 Lines: 26 On Sun, Dec 19, 2021 at 10:56:04AM +1100, MJ wrote: > > > > My suggestion: Have you tried directly connecting the USB into the RPI4? > I've had previous run-ins with RPI3B and powered hubs where it seems to be > very slow to enumerate the hub and therefore the devices attached. > The same disk and enclosure boot without issue on the Pi4, so I've little doubt it'd work. I tried removing the USB hub and plugging the disk straight into the Pi3, expecting it to fail on low voltage. To my surprise it warm-booted ok, but the disk still doesn't enumerate. Five tries at usb reset finally revealed the disk, run bootcmd_usb0 brought the disk and FreeBSD up without visible hiccups. The serial console output has been added to http://www.zefox.net/~fbsd/slow_usb_notes. Five usb resets _isn't_ an improvement, but at least it now seems the trouble isn't the hub. Thanks for the suggestion! bob prohaska From nobody Sun Dec 19 01:19:49 2021 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 8EB6718F5DF5 for ; Sun, 19 Dec 2021 01:20:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGlJN24MSz4h1g for ; Sun, 19 Dec 2021 01:20:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639876796; bh=+zI+ZXinLZrBv9eQjbOEAZA/Pa44NscLz+Qa9KNXCSk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AGluc2GaYJvnMCEmy2c/pwaYsjwaxpD54ITIdWMLDKc65tZlhU+5j4DrBfkFN05MDRWvmMi9SQKiWiryF4hkwZouj5zqQ2FpO76C/SxA3+wgkOJ3y4br/MFwGTxphAMlJITn0rhnv/vZjXmwDHgAN3szEZQcrdFjXpF6VRp5I6MIg1xVSnl167DWt+LSN7xKCWfr4duE9wY7fZOwm5Z00n6GscV1rd3iht+JeBaZxBGry+RpX7VGU4wujPV7pC/5cpXjeC93IxITRrjEX8QetX3MiA+XT5pji8Ev4R43tYdt1ywX2PvBeS7jQuDPKagBqdbXsaxppULBwvBS+x38KA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639876796; bh=1OJBN8i1TUDHcZZWd+oRTi3hzHtNJKOm8Emh8A9cose=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=suf3xcUbxtEu1QQmVsZcdskCggTSj+ChJ0Qm8IbvUlOxgGZm4hAPI6dd2LHMFnrj5Bj36sPQQViPgRbQG3ZvM++rZhwG6u0MIrxpz1xwBo0PomfsrehylbB+P2PLUKk3QMf6vF5LSXrKuMEYjDYGz46mq9af4Fu26hXWSwfGicg3oK/9hMs7yhqa6h7PFJrVrB6LX477JcSYArH+o6CQU4zhqYYG5lwVb89c50UaCxkp0Zb3pNVKCpkTBuSTmLpNP3ZSITGVV1Z6eI00qPV6g2L4RYBYOo+8rzmDIlubaLx3buswFs3oF2fEcVVNEObdPr+6RzDx6rhjML0GytOLPQ== X-YMail-OSG: F9qjdEUVM1l.kJtu1yZ.bN08CxqMwN5B56ICndTwoy8PTzJyjBZTBbisLy_vb6x 6wdUC11KsyJY4NCN5zt9tHS97FMXuIT2FGjrZG1u_4JEd80svTbPViz_YiUwmQ04zjTx1VroJs5M W1JxIGWweqxZL.KToKRW_iVLFlHjh_8APgw2S1zU5OXTOnWjmLoKeZpPhfWSPc0rCgKDkwGHQMBK mtGTU77b4lLpPvKS5e7j8WCzc8aRhCgIrK0D_Pl714wRYB9dt.lNlU.QAm8rpwWC.0AgYV4S1ZWX yk_Ob3px2Ia4a.JL9otgWsU2j7w4rdSP_a6nwLvu0juOKwch_T69VdbdhGrchCmNN8.oNQvEWbZn nswMkRcupq2rILd7.rrKQsSzfnAKjx7bX0djlSQAvzoSSpUWpZV354qp1D50izNNduZfV7O02cUq qWudtEGk.CWBPbCSOWgTy9rSOIuLezk9WkIHC8oRa9TotT4MRzNfV76M6WdHsOce5F_UChQJh6x7 oppzuD3CCpGDLrrb7QfXxaemuf6ijIYV6RVDrX8.f2hfU8TSFpgrI_PWYy8p8egoYacddoo4gCab BjBJwi7VyCUPyeqxew7Q1iE1aau5yyddw2qTKOy_rSErPJ3REP64vJYAlsm2.iYHgP1U.z6LRi_P Kub_sy_IEaLs39mT4fSfU2LOZkL8VJPLJl4tyONPYhGVdb5K._dBvK1XLXg.ksEBLyLbm8pcFPdD KmNA0oBgoL6Mn7mcuZUgKtTc6PiGmu7sKAGKlWUXE9vSSH.UPpYl1JGkSKKZfveeTgUnkqxjOQLF dJUmDTvHs6XVTneMUCg0HgkzEg5_JQj5RU7iKSo5QEL0FOIcau8KYsjfckK4ku8SnKxC8uunBD1A BBX8Mg5bhFSWNhoV_SYdScl0qtVRck.6lzavnYYWONxXbdm1Yvut6KP77YnI8aOYnW25SAaFpVA9 gUg_.mR9jmFe_3oUMzWYD8dkeRXkddMkSkTJNKGYy3x60fNSLTboezev_PRXdMD.zuz1gcpp.kB_ qJe4n1bDql2jLYsBYgVYew7HyO75duNbmW0cEQ1uJpr_Ae9iTD7xklL.57ivrTfi5bsWjwd1Mr8W MsenCgjxTneEbx01SJRl03yjQTh9FeiUh8xLgAgFlAtA0O1y03M9DuKQhVHGirr4g99j_RB_yedS 6kZRoTE7bfHvuyGO952YsO3tsmZhyugEGgLDxFl8B2AiyAlain9gvvbl3_RMPNHso28SNHAaNa0z qQgez5sjdRQjTbRbbbcvMAFZnJ2HsomQegdHWV2qz9KlTUzpHv5_pxB.Jh6M2qvmNTnD.UebPwXj 5PvQHJ4qznUiLi7dPQdWKyqnExGHBrlV0Htfhv4iEx1nIERavI93kGcD7_u1Rw9XLIpMdQnoYQOW uTagRMvP1bHBrqa5piHXsZayZAZGy2Deyq171VUuQwTonDeK6mmN70MCX8y4G8USAugBzZ0Tuyct hD.pCFO7VhKLFQW9OQ0kcusNUAG8EvgfaSGy4jEmFg8Rsy.Q3W36VzPpy.sTLxZgSeFSt1Rw8pCb 33RHD4WjE.iEYIah1oRDC.PqFJ2zngwmDt0SwS6sdfKEWe9F411KT1j_Nyt8biShsuWDGs2T8nnX pI_JFss1v7oRGn0CKUsL3PwM7Xpw7Yrt6bc11K2oAsn6jPp5piji.dTg3YejBxjsr9IsG0ZMDZ5M X_nN2FtZzif8u.7ZXQYPzP70kHiqlXVV7YGpshGg0uzjJ0U0CJDHcvV0qyTI3AgoRWNIPXErwVfe 7jaG52Yq6TsR_ssk4N9_6nMGYNYDQrfkjzD5LrMFdb6YeJYyvFZpluInHrh8Nal5ik21yGUdMBFt CZS6Lw8DRVtKma5EEKfZYBrqDVQmt8E3cgVefkqk_2o1t21BQ7bXfpG5YURoJQEJWQpF_qzhzNqi CLOXeN80nIUTEMSSMe5h.DyaGMHUrhTCH5Qr4AEgIyVRFTLre4Ira1zxxQSn62id3dUuGZaLEbJU qW9k2uMqkLBCXiUHdvpgm7d9Ry4l_z.bSx553HZLN_EfBoE0Q0JgB2.LJ3KQhjFZWLPASgMTX3pd 0ZBQgN34SAwHYEk0FPsO8fblbnoaTGmKN.8tzk3OlRswY7lsIdxHubBuVhLHRVtQnkNhLyhO5fpU Av8PBAdu7kj3QOUBvMnV0wuLCH29usRtcjG6CV8dPdhXJsZ12zM9TABgYmWNQZvxUoX.MfQ1nZ6R 01cSdHUqDJtWghTOjx07ODTRggEgZHR60jU5pS_82rp576w5.S.zWq4gVso.g_zhRnxx5Fn618dR 5z.FOfJSs2D.IbFFptotG X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 01:19:56 +0000 Received: by kubenode526.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 04f0c1d055954fa4919ca0359d31e60a; Sun, 19 Dec 2021 01:19:50 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211218223543.GA9484@www.zefox.net> Date: Sat, 18 Dec 2021 17:19:49 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGlJN24MSz4h1g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1848 Lines: 62 On 2021-Dec-18, at 14:35, bob prohaska wrote: > . . . > I'm becoming sceptical that usb_pgood_delay is relevant, > after many reboots this morning. Indeed, I can't detect > that the delays have a useful (or harmful) effect. > They do seem to be active, in that pauses in serial console > output change roughly in proportion to values set. > I even tried putting usb_pgood_delay=20000 in config.txt, Wrong place: usb_pgood_delay is only for U-Boot, not the RPi* firwmare. It does nothing useful in config.txt on an RPi* . As stands the only ways I know to supply usb_pgood_delay to U-Boot are: A) Type its assignment into the U-Boot prompt. B) Build the *u-boot*.bin in question with the value assigned at build time. To my knowledge (B) has yet to be tried. Any test of usb_pgood_delay that did not involve (A) was a wrong-context test and does not apply. That includes any testing about seconds vs. milliseconds. I expect that usb_pgood_delay is in milliseconds in U-Boot. > hoping that the firmware might pass on the value. No luck. > > Usb reset finds the disk after one to about six tries, seemingly > at random, regardless of > usb_pgood_delay > bootcode.bin_delay ".bin"? Wrong name. use: bootcode_delay= > or > boot_delay > So far, the disk has never been recognized as a mass storage device > on the first try. > > I also tried putting > program_usb_boot_timeout=1 in config.txt, to no avail. The line seemed > to help on a Pi3 with a different usb-sata adapter and the same kind of > disk. It will probably be a while before I look at http://www.zefox.net/~fbsd/slow_usb_notes but it may be that some experiments need to be replaced/re-run based on usb_pgood_delay being provided in the wrong place and the bootcode.bin_delay wrong name being used. === Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 01:33:21 2021 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 562AA18F89A5 for ; Sun, 19 Dec 2021 01:33:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGlbr1GQ5z4jqm for ; Sun, 19 Dec 2021 01:33:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639877606; bh=j5oc2U0hcn7HqNGA5/Js5MHaK8vhRJgPB9BSx4xviHw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AlCmsxuqkyecCFUMrWVALEol6VSs+WjANbtZ8WJup1qrM6CqLIZaUqHEiVwMbaqPVhKGgysTsOFtajdfTV5WQ2rsRddZDdKsoGZWhPkpkqPuCpu8qV8YH1R1Cq1MypggC1caEG//fQ4cU7lkK3pNtYsXw+Uz32BMLZGP1fNupZfhgTzMovdtev9IlDkP/OQY0zW4dXUe9zw6tMdm79X75pUfoqA4lIg8RdfMPjErr0ZPELH5KqLNSBMzku9w4RKQ5NQAWGBt3gTdwF8zxzkscZqHls4qweSSoGmi0SkYDSQ1L/o0iVFYhXo9Yp8npFEq1S7Yg441u5EZ/lyZ1QKN9w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639877606; bh=mImPBRSrMxdaLy2VGPN4JWcR3ycphC+L/1cuINE+wQE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ex2QoRmscU+NBJNIOlqW3ijdRNhjkqqb0MR9SUooD0uj2mnFRHSm1U7rmozRZ599Zz/utEcv6VOjR3JiIrOn7izrn0S5vBVMxLgiKcOEU8ATPcbwX4VkYv5YxKF2T4m4iHRdZ/6WkmPbKNyu8cvFCOY0FToYkh4GcuUz1mpABGadvJh61pAD0TgtBMNhPM90W8hoC0HdQtzn4LvlN3m7LGxoySMC5+mk1qo4pfbUnq0cTP0JWCzo8duxDuKF6le/cz54hjhEfXPKzmierlwBvnYu5ePbx6a1mbWlN2fTJLwu0ofd9CMzEMcDJ+9ssH2hplD9OFKQzTr0Ja87XeDF8w== X-YMail-OSG: yBCXN0AVM1nYrqQJWFYGIPBV9Zj1fXJ37dpoxn860.lgYk2q.WZl86OJRU_GBEA 3rA1cPQTHpoGPqiH_WBM887D3lIcMarIpO4pOQCy1DKkGEbOA2jv.TFRos0h8fpfG3D9cOnX5KUy DppJjPLATb_oE1BGjSrZhgQzeqR.xuPRxoqlmHaB7tl7CQ7iYN1aIW1V4A.10xyIYko9v4z0da6C LeiODgYzqShaZNfBVVRPs6ml4tZjzmK7QY95ilYCR0w9yh.DPbIZD.v9.NTMzSYWRPH4xID4wpJ0 cC0DyqNC123T0SlLqje1lk34EXhtYUvlUg3CkV15keFcLiN7RoSZH_CNC88OerbfDGrhxvxH_Ri. 8fY9jj3owZDRgiMdX3MeI1m8pYZZlBpA9YtbIGkOILmCLHzXUthISbPr21p_vu4lKn4TNJvEJRuy np.Z3ZVMJselNm2lFaPiDeYykDgZw6s8girBdziyjbSrzlH3UbaErP4C30OPgCBmvr2tzJ1_j4iC bGcAIEso.xTSvmvVCiLwjvLxxSwE5suD6H.0elkdIfDoJ197YilR3ednXhElEkPLzAcziHs6BuRx y_duJof1r7vNg14Q9IPciS9Php5JRzXUQRl585l6W4XDXfDtEO6Ggs2KYlRqftiQjSqfL9XIkUBu J.udbfE0nwRfO2zjaOiGiOGTaL5kegfPmKSNRM7i6KL74ZDH0T4nAZ4PT9ALTEOuDYWpOGD.Svz6 Hcnm3a_gtSB7G0LmRG1DCVz.p8_ho9DrZxIBnUvzsCprVrdHUbtPPYYsUufk7rzzRBnQWRd5rzp3 kPreAVdjsj3WAjyAjPab_jVSy1p6bPaS6dxF2TyVoLne6RWcP_SjeBwHtc3z0xw6KtgmlZjq6Zb3 EZkr5ke8o03a3W5TFuiVf9dmwYgAbqSwuI8AmoH3CNpwARSa.71PQ5sHyjCNN9yKTqQ_tKbifRdT 7yM8rEEA6f1sUPNmuv9nJ3pv7gMSK3n1u2ZKSk1TbFAN4XsraAlGcZPOWu778iUM24EF8Ur_MYtX aNC3MMLH0TgE9MYjcO1X6IzQc0syChRNZUhme6gCJvatZ6O2usRVT8re3pZOutodweyAwK8VcZ4l 2VwJfzW_Ip7zL0qVDjU3.DMmWKchdXB5HUM8s3xbXeiq1athYhsKvoBE83Sp4XG10WqhSru2cwbh H9lj19Ln1hJ8oXboN_78VP0P2xpkjlfEQqFjmud.O2ejxrVLWZa2IibNhAkyY5Kz6SyPtCWKaL5c QbCuKnL7Iwl3iwAfvU_bquC4TJw73I.cGiXnLnfpJLOhzxuEz.btR_rlU8iuGXl.a74kUs8UNB_B ENET2Ish_30lTXwfJ3djfd_xnyaZg6thYgc3DUobGtjJ2NQVvDIpsWg_E_SNZdd3TfgfT_KOPpuu msxL9_Y8wqhPIhP1cZCBoS3M.KK4T5w9ytXbRgKSWn8FLD8_6Him5pCHdAjsYjolBYIpRWGKCrQM JfS8Z7TRnFSmz2V.XR8HTT2LYmhG.NaaxrY4jksBKsuK8VHU3crWmXHuh5gQnwwMzUd3uOksPPh9 JPAEUT18.Nhy2oMl0xes08aw_x5Hpd5oetz.HlofLoDuxOFsF._4ZTuds.1I7IVuLZInnCvaNH0X FPU.1X0wJPXvvsFHDabpjoyR0oA09RFz24z5nmr5kQd3ud73CL7eKc3wol5aiV8p57Z32jIFInPm zDmNaeklSS1A_8EzpuP6SDqbtt_My0dCaACRox8DMVaO6egSZK_rMIjhe_HkEpRpGjAm1ncrGBvJ qmeEHg3yTcFn71dYq6I3_Y0iF39ORZRcCM9ukx38CSQ1tLhfFDLyibUOdd4G4_Jmqoqb9nWEZbgZ OUVkdG3OFdBXgoB2TQdyRge8rsEWo3WeKgJm1HDQLQqaB.zy1pD3taqOkFHgdgxWZw8vErfF0PWv XTta.RkAChycPfLuCk0tePY0ONv.tAFuPYa9I8XfNojoBgUfH_8XyTNCfle4P.8LEeNGiEh5YKCj iI_k9x1rK.qCroNvybf7SWpRYwYyUFWoUVZnYO1r64lIP67ZGZ8oVNSqhI8rSvvPGPaJ64W8BwNH UcEa5MOJM5NiVnXicc8drDDvobQy3rwDKiTglLPO5gDcRFd50rKgUDfz2xhzWPV1j2Q3Yt1UiGYZ H0tuYFab4kmpGBdGTw5j4T7vLaeKtKdx.s7see9HhLlzG_3ykDZCLt.ZxfumCUUIQOBTM1ettm2K YcViKZT7J4Jq50OijNKl5LUT5yqxhrC.ZrUqB9nqQfcv3vp1a1AkT.P4.pjh8MNW2sMajbp6tknD CNdCEPNmFyBmy26vuHg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 01:33:26 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 25250f2600ab4c74748e70e80c9091a1; Sun, 19 Dec 2021 01:33:23 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: Date: Sat, 18 Dec 2021 17:33:21 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGlbr1GQ5z4jqm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AlCmsxuq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.63 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.87)[0.868]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 878 Lines: 41 [I decided to have this specific message still under the old Subject line.] Hmm. I just tried a Fedora 35 server install on a RPi4B (8 GiByte) using a bus-powered USB3 SSD. It did fine until it did a around of downloading and installing= updates to the original image install. On reboot it got the: scanning usb for storage devices... 0 Storage Device(s) found But: . . . U-Boot> editenv usb_pgood_delay edit: 2000 U-Boot> usb reset . . . (found this time) . . . U-Boot> boot got past that. I'll note that, looking around with printenv in U-Boot showed a: bootdelay=2 (That I've not adjusted.) Repeated testing has usually booted just fine but on occasion gets the: scanning usb for storage devices... 0 Storage Device(s) found The same sequence involving usb_pgood_delay has always managed to find the drive and boot so far. === Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 03:46:11 2021 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 0E9BC18F0979 for ; Sun, 19 Dec 2021 03:46:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGpYG72mPz508l for ; Sun, 19 Dec 2021 03:46:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639885579; bh=Oed77GlCz69uMwr+Sz2Kf26I9LJeRbwAu2IGlPYSBlA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lmJJpYPidDxALlrV6K9RbewMGKvDIkjTt/k0IP69KRs6Vd6Ju5AMB3OG14ILUY37LR9433bmuyFNDStQtG7hYX8+reVgM+o2wFOQm8tr66XjqJBhigjR4dYFzgqVsOSv4eBt3QhCdTj95hmkzrX9Egt9QXuxfXkTrUYtIYvsGq0hAy7r8t65/ITyjrRdZifTtNVsTMw/Adw8eL52uwDbpynDeO16cAy1I0cTVpD0SDOSI934IpVw7ALwA+uBulv2QsovYIYk4QS3X3pImwoZqpBoUXL5T+RhIgtao6C8QFuBLKQSYUYi+9UU5J5FlRcJLkelb+DZSBF3ArKk5kigiQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639885579; bh=m+9XvVaO43aI4QmvIjtvvAOeJYAilsQkrH6gO8FASrM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mbl5OX07pr875qZb4SUuPeHlcJV9tBpOMn8ntPeGYpR2+sV9KkWBMEbWifJGy7tvbtBPbF2Mjdix9XayrjWXrcGzFKAL0wXEhcvGjaiFm03EPUzA5VVZmP02JHMFmjl8XsnLitwvs8ZtV9SZ1JxPezBkVlyqE3x+Mh6M9wvcy+vP8QB5F9kAy+f8soDGxQoK853l+Vm9/BFqzNn/StDs/fhnyDN0tsQIj08p0gK3B47bs4TivmcKoc5NLk7CzWoIA3M7raFheRPm6FxFnaFydhLR0NTvr5VGVemWR+MbHQORFpVl3A/96F0SqEVp77vjgR/nGy2ivWx6U8eY2/ZRPw== X-YMail-OSG: 7VAavn0VM1lYkVlD2tiJKH1ZBBW4iwZjcRSN8icY5ijhH_Lfn8neyiW.JnlmTAg aEOnR_h287ArOb2t225beUNLbQH6W9Rd2fzMVrYwOU_pdhGugon2_wk.7LSZFAo6ADuXIyjcvZva .JIxWpRzNoOCaSm6KZFclw5Z2.925XilF5U_Lkl6m4aphSyPEANxWHpGDds7OqrNIbIumEJhq.nX na5YuiOaG0ZdxmH6Wrt4zU.KMV85IrhINO7zGjkNRDs67Q8.EglhDl3fZPtdC_rSRxotcdtVURxZ 3ndBixdry7q.x6wBMRXvO6zeZBsCxBVXrCxs94tsy4OJzF9B.z7XRvsFViHplIz3nYLDOqFagAMb FzIsHeMndRiImY6vr3NwbQT1FVNMAm.AVRmVbIfM0hyTsUkDejjhlUoBnE1RDj4qejj.QzI4.Ok. czMt01M3CNNfiisjJFDdj82U7V9VA958KXTCNKnvVi3Wo0ldaQj8I2od2TdoOYRcL4o7A7tDRPuF gKYGxYvLZ9Q.OcVwvdKNZ9_BZoThm8xin8eOt9y3Xd518l5bmcXmEzJ2my81zbaBYOsUhPOKafTl FARC0R4fmqQ6NWzaFyKT74u_QqWXqcxeIWZmYfCkeA4A3sJgPmSJwEjhsrymVYhWjR0iyzOO.Eps KJcgLuDBgir4WN6lVQlA5PcHZLwqkUQlTwZnm70Eccw8vGWzMWvyvu8pkz.geJiz0S6IWbm0gYQz jGL2GW.iREW_7oobowRkfw6Tnem6Pah6rKX92y3_x6VkFuTC6W9oTGm0Yw.Bvgpth5ubY.I08oO5 VAMbKZPFlj79jobH8zDoq9o8B4ZxlzNf7D7gXsKOpHzj0JuCtc8DzIoAuBhU673RdF1MacAX0s.o cg3sDmpukvLL.emRU68imuqwHCIb88CIbwdteJmEcQuaXEwfNIgq5kt4r4YMx0VXR4Y3Hv.O2Ub9 mXWcymceoFI9f8jdkFjZLN2t3NFMjwWRYpCXtluR5R9bryR1SV8TST.MAezyk96kSd8X7AT2nBBD mFPC7cBs91ixbwAKv_bRPCN1uI6dtNrM8P2_LWOFtOTWy.p0l8emdFdhKzWQiBmbP87R2hev4poX sQRC4QoAyN_2w_KTIZ0U1tb.7VjwffCjJ0FeyqvNfli4cpH1Tc.899Io_InbLSTzm.Cg2XSnSJq0 j6j_tPvSkh.A01NwdIqDxHytCo8eRXBu3TEyIiLkzCMWNfVOkC1UM8TNN0ReNjQQpsx0CYvYbXN8 vleH.1OQsCdBswKcfdIHzczcvSM62TuhWHCP4n9uGdzRN0MOCdX.NlK2J9TJP5P8edfPyR3etwCf 5gIcN6OwlLS_PE9uRXioPaXnpd3_qFOAsigDJdcWOoPkO2CwPLF1nwctDUzI1YWCkpYMJaZiWoTI N8eMi_cnyForziyFSP90a0.5Uew48U9Y2n85e.6SNjfNwPWiUHS3lk0lbDjg7YtbzSTo6dwQVwFG ZiIkA2NQbb0Tz1VEA3rCp1gXoAuKIIPTHcJb2Dw5ZKNR0EG3k677qlADAh5rkTXcvo09zOuSrmP8 uiQXCvRwHK7zQv_KPKXKtXSWTf0CuTnBqPeA5bHvHmsQmthLeEZ75qHFDpztZS.GhBW5U6Llaht4 4vwNeMwC9SyjRVe0U.w1t7c7NWjU4RKyiSKEWGoK_9.rV8PgWggLUo3a01Qj5vreKZwHETX_A4uS lXxVP_1KTA8xUhj0XAqMn5Xf66As2XRV5alxWgPhkmO.Jmfe4mxHPSMv6Y2uv09y7T4cqhMTJc1U Doml2BxfgXIp0ttCx1iJBXf08F6jGvVDV5I7yLwJbCqluk_2noantJ2W5X1qyNi9oseqVyLjm6g4 .BNkVDBO.yEGQFRhO3i3iCvFgbhQyo7ZlyNnbDu1XbPr_SkGQyE4N0xhnn4DEWYL_sUyKH2A8CTu FFF6k5QwICJzlJTaj9mFS52OlCT7R6X1mb04H9D.kwXqwpdzHSyYoiIX4xlTBHKe6SnKxZP480q6 vtnIcoMY_UtZRplaNpMdBA3omtZXhJBiXSHxitBHX4LltZCw65S73hhjYBvz7GfKLN9H8ulK7Cql bTnOP8L74LcOVPJTj4qKmXZ82UWQ06hsXIuXf2Z2b5Sk3YDUO1lYKrmJUd_zNSlQJkXprq12qWqt duY78H7VbgB4.JEa0TqxbO9PcQfB9Rkt7eQOMi6reNlxNovG8Gvnwi5c1_T5lyNaeqEa4EorgoxE kW2C1Lj.1Z4WuBVVXeMa7dQpI_mQZeNKweotVIzflSDjP4kpw5VB5Kv7wZKsHlvMYG6_HAeorxlU 6S.N_wOBjPRW9hYVJ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 03:46:19 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5466e0ba08876bae52ef747cb2b4af77; Sun, 19 Dec 2021 03:46:13 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Saving environment variables in u-boot In-Reply-To: Date: Sat, 18 Dec 2021 19:46:11 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGpYG72mPz508l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lmJJpYPi; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.01 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.75)[-0.748]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.92)[-0.924]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; NEURAL_HAM_SHORT(-0.83)[-0.835]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3267 Lines: 140 [This eventually suggests that the vintage of U-Boot used in the default Fedora 35 is the problem: a later version of U-Boot does not get the problem (so far).] On 2021-Dec-18, at 17:33, Mark Millard wrote: > [I decided to have this specific message still under > the old Subject line.] > > Hmm. > > I just tried a Fedora 35 server install on a RPi4B (8 GiByte) > using a bus-powered USB3 SSD. It did fine until it did a around > of downloading and installing= updates to the original image > install. On reboot it got the: > > scanning usb for storage devices... 0 Storage Device(s) found > > But: > > . . . > U-Boot> editenv usb_pgood_delay > edit: 2000 > U-Boot> usb reset > . . . (found this time) . . . > U-Boot> boot > > got past that. I'll note that, looking around with > printenv in U-Boot showed a: > > bootdelay=2 > > (That I've not adjusted.) > > Repeated testing has usually booted just fine but > on occasion gets the: > > scanning usb for storage devices... 0 Storage Device(s) found > > The same sequence involving usb_pgood_delay has always > managed to find the drive and boot so far. > Note: This context is (so far) with no microsd card in use at all: Pure USB3 based booting. I ended up with an example of the USB3 SSD being in a state that none of the parameters helped usb reset or usb stop then usb start (many tries). What did finally work was: U-Boot> usb stop U-Boot> Then: leave the RPi4B powered but unplug the USB3 SSD from it (so it lost power) and then plug it back in. Finally: U-Boot> usb start (at the same prompt), which finally found the drive. This had: usb_max_blk=20 usb_pgood_delay=2000 usb_ready_retry=5 in U-Boot at the time, but I can not tell what of that might have been necessary. With the drive found, U-Boot> boot worked fine. This is a context in which there is no external hub and no option for non-bus power to the drive. Question: Does your USB drive allow direct/external power (no hub)? Fedora uses a different U-Boot than I've been using with FreeBSD. But I do not know if that is contributing. The type of USB3 SSD is the same as I've been using with FreeBSD for some time. So far my experiments indicate that having uEnv.txt or: uboot.env does not contribute to the U-Boot environmental settings. I'll note that there is another error message sequence involved in my sequence, "cannot reset port 2!?" and then "cannot reset port 1!?": . . . U-Boot> usb reset resetting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... cannot reset port 2!? cannot reset port 1!? 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found . . . Sometimes repeating: U-Boot> usb stop . . . U-Boot> usb start does lead to finding the drive in only a few tries. I'll note that the rpi4-u-boot.bin that Fedora 35 is using reports their build as: U-Boot 2021.10 (Oct 14 2021 - 00:00:00 +0000) Tracking the development/test builds ends up with: U-Boot 2021.04-rc3 (Mar 13 2021 - 00:00:00 +0000) instead. Hmm. I replaced rpi4-u-boot.bin with the newer one and so far, no problems finding the USB SSD or booting in general. === Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 04:34:22 2021 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 2398018F7F6B for ; Sun, 19 Dec 2021 04:34:25 +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 4JGqcc4cTRz53VP for ; Sun, 19 Dec 2021 04:34:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BJ4YN9X012912 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 20:34:23 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJ4YNTL012911; Sat, 18 Dec 2021 20:34:23 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Dec 2021 20:34:22 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219043422.GA12811@www.zefox.net> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@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: <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> X-Rspamd-Queue-Id: 4JGqcc4cTRz53VP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2032 Lines: 61 On Sat, Dec 18, 2021 at 05:19:49PM -0800, Mark Millard wrote: > > > On 2021-Dec-18, at 14:35, bob prohaska wrote: > > > I even tried putting usb_pgood_delay=20000 in config.txt, > > Wrong place: usb_pgood_delay is only for U-Boot, not the RPi* > firwmare. It does nothing useful in config.txt on an RPi* . > I was hopeful that maybe u-boot might pick up the environment from the earlier-running firmware. Evidently not. > As stands the only ways I know to supply usb_pgood_delay > to U-Boot are: > > A) Type its assignment into the U-Boot prompt. > B) Build the *u-boot*.bin in question with the value assigned > at build time. > > To my knowledge (B) has yet to be tried. Any test of > usb_pgood_delay that did not involve (A) was a > wrong-context test and does not apply. > > That includes any testing about seconds vs. milliseconds. I > expect that usb_pgood_delay is in milliseconds in U-Boot. > > > Usb reset finds the disk after one to about six tries, seemingly > > at random, regardless of > > usb_pgood_delay > > bootcode.bin_delay > > ".bin"? Wrong name. use: bootcode_delay= > Sorry, misreported. The actual line in config.txt on microSD is bootcode_delay=10 > > It will probably be a while before I look at > > http://www.zefox.net/~fbsd/slow_usb_notes > > but it may be that some experiments need to be replaced/re-run > based on usb_pgood_delay being provided in the wrong place > and the bootcode.bin_delay wrong name being used. Experiments using editenv usb_pgood_delay from 0 to 20 s while in u-boot were tried. I could not detect any _consistent_ improvement. Sometimes the disk enumerated on the next usb reset, but often enough it made no difference. More confusingly, simply repeating usb reset without doing anything else has always enumerated the disk within (so far) six tries. I'll keep playing with it, especially now that the hub has been removed, but if the timing is fussy a persistent loop seems more dependable. Thanks for writing! bob prohaska From nobody Sun Dec 19 08:55:12 2021 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 CCC0818F82FF for ; Sun, 19 Dec 2021 08:55:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGxPq3s20z3hS9 for ; Sun, 19 Dec 2021 08:55:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639904119; bh=U6NX2F3PuGyzheDNOTSjrwTLTgBIMVPK07zC1Q2wFuU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WM9sPYvLcgcG8RRIddkVOgMjlls+dRBNwN0pxaezHeGtNgmb/rQ23PL8QQAf7HDrJSom06SnnGO6zoGgrx/iRB7zmjcNQEvhHpnPvJ+IdtLsy/1EvHOARB2QV9c2Wur4aKk2TBZ++8zmnPLRyTUZNPlJZICjh4VZzb8Ow+BExERHz6WZIemyoWhflHzqE/PuwWqOLq/AhLtUWoyDr0H2Kv0xX/jtry+dUZslpjdHuh9Bm5cfXJRz6damM/Nh2WYpaH3MAD/nEsYXDRbMIdnai2rhaEXydHsVgc1l8jZcylNXLIwvKcaXjxpsotXlQLvxq4CRq9hcwmmzcdcN+Mljpw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639904119; bh=AQREA5sbWFY8GpASdsQ1i339l2RPXkUyNR01CAnlEeG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YhLuofVgwknBa/lXf6uHnsJtHNkHJVZVq7iYYFtIAO0F78/Kfo2WhG+eT/rXmu0lO/PaMNLXJcKdOEHgemtyrL553RuVlUPQPYRDGe8Yso88slNkuomTyiRqD7vd13no7tGjSVtEOWe0CN2MaMAzmDZoZKw+Pkh+2oIw5ddH6ty2ic0HorPsvfFQGWcHNQXHmCQlqIM1gMOl1qV5GL9PTGeeMdyCPufXu/74vz5HH/taf7l8iRfuUYqd2b3Fs50OdzSYV9IspI/IDmRSXVtEKeDTpZMUIrLhlpDZiQfko8E8MF2yKoJc6mGAggRM+Akm551xWEV92frrT7H6XyrCwQ== X-YMail-OSG: yp9Tz7sVM1ngEELJOoootCnGY300JP7FzyuiKwQ.tQCVgMrUQi24xrJ4XwFJqjh gqsRu5R_9ml1xP1VbtLQS0T1tIsaFFcoJMOO5HCAufBsB0nA3VNZIkNqUnPUAumHv0d6Zy6V4mgX MtNVxtn.bXzGNaPu373rM2KSRb8sw.DeMN3QN0JKoZLw.91BguvWTNBIs__Gf7h0oA.PYnvH0lRX M3jFv_WeH74q2HRffuj.1plmxFZoJPTo.H9XMoZhA1co1WYsAf9npOI7cwpF9UJkmIRMvqXZ4mS5 GU6N.0SBWSYuKf8l28KSWh2SqLuGHvhOhH6LyFVhPeEz9ZFS2OQIuOLPN75orCk_.lyIikA9TcOj w2LqqxGJH6j_52dPAqv.Lo3c9gGw5HMYuIwmKOYt0HsmRLByPTPZU5R4OkhUAVcWT3g9vHJzf5i5 7WNy1yMK160FJba.7L8pNtoVRe8wFGkuQyRwMltYd.9PDlkK9UiGicWjWBaZeKHK2CBafW.7SAZp Yqbr1P5JXGW8Noa1yWL0C8NI9zVjmYgtft9UGW.jSsKkwkzBd8QfkH3obfdStaAheMea.UN6pMcW yuvKsab77iMgDRYhhm8.OqQy740lBi_0sOb7tMzaHeqbx4EzX_QOrniGO8QheDtoe56PoJY7pEkP vqjXUpwWX2Ku7Ex0_n2aGUDyinGY5XPw9gs31lueVYLIr9iDrBql3ZZFgKAwYYdCLjORUu1IU.hB a16.gbiOIRD9W0hREKnIrjFqpZRmXoH0AUyZXqwv62KdgRustP4tt78FrBxLSaMH0fAFX3rknnA. EcC_ALKO9ZiBGrq2H2xw_9_R3XOyz6r0W2bImhHGIU8itJN4fLm0jcMuWVYZGsOaxa14rUtpvl2x BdCQ4tBivguwaHvHM9zXKVrpdXZMFK.zVJEpWL7HSDUZeEKXvI9SThF7QBDjCsDPz3tNBNe9lTUn 9ZzGlzSPUXYkMuIu1UtnSABF1JqUKHYUwwYzSnLQqmNvTIWLfm.QolCIqfl7PFZr9ddOGNIqNcUV h2FcHtFvc4_XZL13ZwjfI9DA4hBg5XhthhWtMgsk_qfhaQkWw_YQL9syZrtCFxdiw1A7I7M9ZtQZ FTB8hYK.yjzDjXhqnKwAELHzw6SxcD7SlDewl.9DqbtZ..qGKuIGXCKAHlUwamxtL8JnHURdQKXV 4bSxeRogC7v8tHhZixG6f0EDKKLEVi3EJII5ZPN3eXwqgX3gO.nsKlbFeeH34LER_DsRkq7QCvgI fZ1kutWdTbP3a..2LnrAg7gl3Okp2hS7cKISIYbfB4oH1.akpxBvMXgz0WBqLPg0yOMh8.ekzMfb ATycnM1H8xpvwRYEjFjrsP_JAZsL4THyef09UYr8XyeGNdWqfHmi2lBTEVV4tdCf3Y838T9iHxuE 0ys8cvfDo0yP0vUHuZ8TgBHHUf18dPqbCJs1166Vi9sU.5fFW3rbkkYee9i04foJGxpWeLbKiN3p haafNbAeI3LzY05YgAOf5q8SV7sR3z9roaXeKvVVbquTh.HAXxh96SB89yGPOGTerEMDqyR79xuy DmBIdkxewXYN1xplakCKQHRno_ulmWV2CKoJ6VTXK82JAoq7aK8qkDaMrfIfzRanzRxHYUp5cUig nPJ25eEP3cPkhdIYHQrFyCOB0OmQAUSU1AmsgdDj.pOMNQknpWbOH9r3aqd.bZGRKv40cYejWyOF MEbZcktkfcY__h6rkjeRhnAlFmBFkXyVqgHqzLEPydnzmbkaJbiwAXlpEDxt6kawmomRsXVhYI.V sFR9DfZxmvWy1p5JJFSMCtou3.aOEa.qxnJGPUm.6Ydu7EJhOUOG6f94lrJEg0Ug9PELZL8HzXdg TM.73NpsHKwWBTwynwYAOuyauNqozUdFlQhscmlAgi1QVa9YEVa_SucIHxXh25nXlHn3yMlIAudK 1byTdj2XtQSw9LBPQScMiHYRo1yJVhDvZqa5lpnh8zt3TRHoPfXWjDcHETO76TxW.KRIuX9prMmh 0S04cQkHBxSxoZXVZgC667lpA4EdIwR1Ak5MkAhBi.d2mIiWNuUHK2WQFZNy8gOeB8MTdN50kNv9 c_sY6rNQo2ex8XqXg1d6FibnoR2hjfCvObK4p4fck.YtjwjmfX2xpSXVa4MPBJo6llX5xptsme_C Av8osEsBH_tczIZfAogTxXxRKvIiHPcA7p0ZfLyT8U2wKsPPOYYrh0V13RIbxQV8xEQYpTjZOMES 2BSiLo6eg4ktaCS6dn8ne4NHHcoda.mrccsqIgm7Puv_N.Q0vyds02U2X4v9wvejP3UjjRWf0P.L W1HfiM34FanZjwG_wDg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 08:55:19 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7762c003f31dcd5495a872e3b8a8e9bf; Sun, 19 Dec 2021 08:55:14 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211219043422.GA12811@www.zefox.net> Date: Sun, 19 Dec 2021 00:55:12 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGxPq3s20z3hS9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4237 Lines: 144 On 2021-Dec-18, at 20:34, bob prohaska wrote: > On Sat, Dec 18, 2021 at 05:19:49PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2021-Dec-18, at 14:35, bob prohaska wrote: >>=20 >>> I even tried putting usb_pgood_delay=3D20000 in config.txt, >>=20 >> Wrong place: usb_pgood_delay is only for U-Boot, not the RPi* >> firwmare. It does nothing useful in config.txt on an RPi* . >>=20 >=20 > I was hopeful that maybe u-boot might pick up the environment > from the earlier-running firmware. Evidently not. >=20 >> As stands the only ways I know to supply usb_pgood_delay >> to U-Boot are: >>=20 >> A) Type its assignment into the U-Boot prompt. >> B) Build the *u-boot*.bin in question with the value assigned >> at build time. >>=20 >> To my knowledge (B) has yet to be tried. Any test of >> usb_pgood_delay that did not involve (A) was a >> wrong-context test and does not apply. >>=20 >> That includes any testing about seconds vs. milliseconds. I >> expect that usb_pgood_delay is in milliseconds in U-Boot. >>=20 >>> Usb reset finds the disk after one to about six tries, seemingly=20 >>> at random, regardless of=20 >>> usb_pgood_delay >>> bootcode.bin_delay >>=20 >> ".bin"? Wrong name. use: bootcode_delay=3D >>=20 >=20 > Sorry, misreported. The actual line in config.txt on microSD is > bootcode_delay=3D10 >=20 >>=20 >> It will probably be a while before I look at >>=20 >> http://www.zefox.net/~fbsd/slow_usb_notes I got around to looking there. Note are later below. >> but it may be that some experiments need to be replaced/re-run >> based on usb_pgood_delay being provided in the wrong place >> and the bootcode.bin_delay wrong name being used. >=20 > Experiments using > editenv usb_pgood_delay from 0 to 20 s while in u-boot were tried.=20 > I could not detect any _consistent_ improvement. Sometimes the disk=20 > enumerated on the next usb reset, but often enough it made no=20 > difference. More confusingly, simply repeating usb reset without doing=20= > anything else has always enumerated the disk within (so far) six = tries.=20 > I'll keep playing with it, especially now that the hub has been = removed,=20 > but if the timing is fussy a persistent loop seems more dependable.=20 >=20 http://www.zefox.net/~fbsd/slow_usb_notes shows: umass0 on uhub1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks =3D 0x8100 umass0:0:0: Attached to scbus0 . . . a0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 000000000000A da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ has material about SABRENT adapters: QUOTE Sabrent and Orico both have the worst track records for working storage = adapters for the Pi. I don=E2=80=99t recommend them at all but they can = sometimes be fixed. END QUOTE (Not that all models are bad.) I've not found anything to identify the specific product that you are using. He lists some specific ones as problematical but possibly fixable: =E2=80=A2 EC-SSHD* =E2=80=A2 EC-UASP* =E2=80=A2 EC-UK30* =E2=80=A2 EC-UM3W* =E2=80=A2 EC-DFLT* =E2=80=A2 EC-NVME* =E2=80=A2 EC-TFNE* =E2=80=A2 EC-TFNB* (The above are JMicro based.) Can you identify your adapter type? EC-SNVE* (unsure) It is also not clear what drive is being used with the adapter. That could contribute its own issues. Looking at old messages: QUOTE 1 TB Seagate Barracuda with a JMicron USB-SATA bridge END QUOTE but, even if that is right, the above is not explicit about models and such. Hmm, more history that might be the same hardware: QUOTE The hub is=20 Bus /dev/usb Device /dev/ugen1.4: ID 05e3:0610 Genesys Logic, Inc. = 4-port hub The disk adapter is=20 Bus /dev/usb Device /dev/ugen1.5: ID 152d:1561 JMicron Technology Corp. = / JMicron USA Technology Corp. JMS561U two ports SATA 6Gb/s bridge END QUOTE Looking around I found evidence suggesting that EC-SSHD has such a part in use. So I'm guessing that EC-SSHD is what you have. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 11:03:47 2021 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 B2E0018E5297 for ; Sun, 19 Dec 2021 11:03:59 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 4JH0G66yNfz3vyv for ; Sun, 19 Dec 2021 11:03:58 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pf1-x433.google.com with SMTP id c2so6188007pfc.1 for ; Sun, 19 Dec 2021 03:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qW/EgBiBol1Qzpz72TnfRu4C+7oZiFoVGYUZC0W8s+U=; b=RPDWIU0VV6yXM4wVKHowYqu1MZx3hDkaYqGiMjITjM3Mcr7yq3nhGLhsDpiNH4F5aa OUTJQyhxlJtzKnXBEMC4jQhmU1NfRw2l6RADWedM8EZpCLmJ/RB7GyhJiIiznIKQwB84 b+60Kfi7VRYDvgo0cJb4XfAn0toe7MBTU1gT8C6ePHGgVqOwg7ecfLhLC5dGcz9BpsY+ /EAHMWLW76r1SYVNsT+gdut3Xgs1R/uKEDCYWuUOvyBtWLX9/sUoN9l4kIcegHZI8LyK Jt7NuGC00cxXAPkWIShaAWsXeCWTg25HE3WWRnzOIw3Yh1HZ0sS2SMerZcMjLM2Sp44U CF/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qW/EgBiBol1Qzpz72TnfRu4C+7oZiFoVGYUZC0W8s+U=; b=GHjK8yXw8pXizbtSKvSvFD1xVVjWQL8MsG3ZwtBDKMgyxxGgJ9L1y30pyFPQsJndlK dhmLivOOoHItokexs7naRJPbFQXgq0gF16bjKo26HquieluDHp0AE+RauZw8Y7YT4wd9 8Xd0jW+7MA/XdxHvULMAQ0Q9VcbtBDxtOZPQCC9PVbXSkV7nOi6oHVpAcvYixq3N/wOY UjEY1fflDGB6PXmpTKFo+nueDouMHnUbeEJ1nAHsPRGv2ojyuShoQhTK/UgMS6yIBuGq Uc6K3h3QHMNLkSkPCCSjK6tjsFj3EtB5di6FF77bunk8aN/DPk690xT5HhV6dSMK3KKp WbPQ== X-Gm-Message-State: AOAM533CDudIVTBD75MQZym6iTp/T2FN/IN5dYgClWMko+jq+6FbRzBI FvDUlh2UFaEe/acqS7iYUIoeHgLPIrFDbw== X-Google-Smtp-Source: ABdhPJw4su3c63/MDXyRRTxx/Z7i929wY31mELKl22NIRc5efMYS+NtHEHu6VJpK2mBqmyxO2BXSFQ== X-Received: by 2002:a63:8448:: with SMTP id k69mr4817099pgd.268.1639911832020; Sun, 19 Dec 2021 03:03:52 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id oj9sm10960519pjb.0.2021.12.19.03.03.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Dec 2021 03:03:51 -0800 (PST) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Cc: freebsd-arm@freebsd.org References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> From: MJ Message-ID: <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> Date: Sun, 19 Dec 2021 22:03:47 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20211219005134.GA12292@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JH0G66yNfz3vyv X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=RPDWIU0V; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::433:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1060 Lines: 26 On 19/12/2021 11:51 am, bob prohaska wrote: > On Sun, Dec 19, 2021 at 10:56:04AM +1100, MJ wrote: >> >> >> >> My suggestion: Have you tried directly connecting the USB into the RPI4? >> I've had previous run-ins with RPI3B and powered hubs where it seems to be >> very slow to enumerate the hub and therefore the devices attached. >> > > The same disk and enclosure boot without issue on the Pi4, so I've little > doubt it'd work. Forgive me if this was asked/mentioned before, but is the hub USB 2 or 3? I couldn't get a Kingston 128GB SSD to work with a USB to SATA adapter (single usb cable) until I got one of those SATA to USB adapters where the USB has two cables to supply enough power to the drive. This was then connected to a USB 2 Hub. That 2x500mA got it running. I would think a mechanical USB is going to pull a "lot" of power when beginning spin-up, but once rotating should be easily powered by a USB hub. Though this would not explain how it works on RPI4 unless the powered hub you're using is USB2. Apologies if this is just noise. From nobody Sun Dec 19 16:18:16 2021 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 EA8211908012 for ; Sun, 19 Dec 2021 16:18:11 +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 4JH7Dg4nTJz3P02 for ; Sun, 19 Dec 2021 16:18:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BJGIGwR014941 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Dec 2021 08:18:16 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJGIGva014940; Sun, 19 Dec 2021 08:18:16 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Dec 2021 08:18:16 -0800 From: bob prohaska To: MJ Cc: freebsd-arm@freebsd.org Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219161816.GA14873@www.zefox.net> References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.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: <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> X-Rspamd-Queue-Id: 4JH7Dg4nTJz3P02 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1099 Lines: 27 On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: > > I would think a mechanical USB is going to pull a "lot" of power when beginning spin-up, but once rotating should be easily powered by a USB hub. Though this would not explain how it works on RPI4 unless the powered hub you're using is USB2. > That's what I thought too. I certainly didn't expect the disk to work without a powered hub. The Pi4 is a different animal; it has USB3 ports and more power available. That the mechanical disk works at all on the Pi3's USB2 ports without assistance is quite surprising. There's a table at https://hddfaqs.com/seagate-st1000lm048/ listing power requirements for the drive: Required Power For Spinup: 1000 mA Power Required (Seek): 1.7 W Power Required (Idle): 1.6 W Power Required (Standby): 0.18 W So far I haven't tried to power cycle the combo, that might not work. Still, it's been an informative exercise. Getting rid of the hub is a welcome simplification. The machine is still up after standing overnight. Thanks for writing and motivating me to try the experiment! bob prohaska > From nobody Sun Dec 19 17:11:26 2021 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 A018918E4ECB for ; Sun, 19 Dec 2021 17:11:37 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH8QK2fpjz3rrn for ; Sun, 19 Dec 2021 17:11:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639933890; bh=l7YFNPGX5A0iCuUrByhF2btVDV7Yf3KrcKouhLrJIeQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EcMSDN96sM1G8ai1k8BPUY2iYdIV4XKd2Y8arTEDJH/10n0Yf+SDZYbrFyHCqJeMDkpH0ZCQszuz1SsG+8BFHesXfXwfAOsTnjCJhJacnpv4H8d3oOfvqiGqzBTJLAeQG1enoktbS8Uu+dbgpy/S8+5tGwd6cBFOnzMs7KB/NNaoMoC9k4JE9st0YtcF5vJIkdjBOlWrXiA4INXNOsHfnmYiuDTXrSXc6yz9JEB+keblvwR+VswsgS8irk9Ffwt+6znSbVM1Rc9wKieWzjZo1HAiJr0797Xe34Hz07UhC0FyvZQARgyRTNDPTrZ0ifnR/OYKMmUN9j1B/eR8ZGLgTw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639933890; bh=jm22VaWJuDVm29oFAWtkWw4rJ33nLR9ug02e4YjSeka=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PPWjCvRpuz9ZJW+3iCG/Iuyx8gBHA4t32AwRydio2lS1B7uj+Gk/9ZjoZQuFMX+WXRM6/dHxAPrcx50fMjgfOo5yyX878nWFOWuceuM5PpL9iZuSf83Uzt52OzIsuPXQyv+LhxBdZ4EPwbpLOJ8g+jup+WJlL7vyF2NQAVX1H7vlDnB4juOLn6sZLRX7zIoMyfuwmTXv58AcIZ7OVBZp2/jzWmAexbxVa/5VDjlzeOpVUBI8orqSbdDTcyUjAzTw6gDKATcR6C2FHdgEehe7ZUvW4fsenakDWdh8ARLFlFDDAxlskAxFa6fqAIWsisWg3/QjnYIwaZ9cI1diarOsbA== X-YMail-OSG: B0XpAzIVM1mv4bbtdnzY.OROonr8cyjpt_Yp41CHkznQYJ4uo1gHFXyBJMmU_H_ qJwDx5M9hwIQjdT1kZEeXnSMLmG5Qh7OVxs3BKLjq4pKEnMV3uSZ...mvYAeHyaihEvDT0SbimGQ U.Dr3DHbE1k87Zs1qrTYnNqfLJcb6KvpJ8ecn8pfmAwxLuiDawRMz3RFLfj2GnCWKpJjObQY3ZLo GTXFmhahp9RDlX4K.w1cM8DeNF5oATQbA61q7eYotKHxzisjPHm4Ob_nMTGNTe5ILaVeWyYuGSnU 4i9YUKuwvwYh5kE00Hvp4XMm38dgjKFe.cF8o6axQM3VkpbFfntPvuRN.um4.R1osNGskEHTCPx1 uNSiTmV1oBvHToh59MvMu.uJhwGBkOsi3TebW93Sb9W5YlDtUlQB2u5cP9x90rVUNoUGekaZM.dv mtzGl.z_To5EAKwKsQI.vcWoX5jpoxNxVBdactvGfeH6qaXXMG_eGhkm9_6BbN_4OgbcIjI5I9ud evQg4S2wfwWv9ORcXzpjkwx7sQ2KTFwhn3cXGbSrLbjmNz6SHKsZtE.kCd5UatmSkX40j_N4YgOf wJdrJqIggiivrymr.zyDwa.EDZI2G_LJ7Nky5gjf5FNGkWxinxbNXciTqgKm7lqoGk5nDmHCo3kc vxRRT19CQgQU4M.StkI1z7J7dHRoNjeDzcHE5LH2rTvIeZ_bW1S0.wBnWDYejWVbtQb6i5VNd7jN jSwgoQTXzEqUzmydW.fkWgKqKtdP8NMro9dw0nSZQNdRpEYRoxpIl0bZVltnL78wQZ.ex8mULhhT buCBGuYN22L8yg6zkBRVrEV8l1FxHrUSx2Md3wG7f86KtJkzw0l_kdn2QcZFjzkdUza.rseKhuPz vh00BHtcjPbxWJZ043cZ006wn1u54m4h1JUNmIohAcxKz3nre8lQYWIiDFSuDY6uGzJFIIOmEZKh JvD.bjIfmP2NeftSrIRaMESjExyAL_xg5ePZPO.cgbABCQoUUhAh1e40_2.tVHZLFV_v7EiTfhoh 7pafXfxLcAcvVpV2IWndJeiJZ5tWPtjF.ZkTw3N3hw7K0JQ1bzA5BPYIOa3P4SgU4BvcuLa6qRP2 tfW5DTuDD5T9Hqlo44Pdl21oVRO.kmmrh44F3dx18tv_9iby3AeZiaMhfR9U4axw.WhkJxDZZmhb .HM2hmncQcv8x6wiv2EV7P8HL_rHyizjJXzNtBaxVsOQH3mDs7NxDqBRcwC0dE6P9P1RlSxxZRJZ HETSGfkeY_YNDjp_KXORDliiFozSmyoma7xBo5aRP1pZZ1SqS6_UHyB6CpYUnWNR9NjOiWi1h5x4 9Z9R3TK0sfKx_gRT2x5IaGarivJGNZluRbAuRFK7YuE5iINt.Ls6t81gyPBJ2YXSH_jo0mpDiBem 0RYurmsp6glW5Zj4MNlWqQ8CbB57QG4Q6fbGKlMp2ytVixmdSe1jlkEM6OiW6fvKqomL8vsGKwwQ RE5Qrqm.oh6t2CGQnZfxXRfw1jLKaIfAxOw3wRdZS00fJkCMNYhPuPCslRbzhZJhttqZsj9lXFfD knW8UyqwYYNyt_zMeUWtd3bJA3rXLZiJTrEiA5LsGPEOFebXoApPRQAj08pSd3KTqnGrDd1g86nW RKZB4jHiKoHQY_8_i1gdCVR6P4rq3Tz9m__tqkBoZshfAYVl.zad2DS40IS.qIF7lvtWrJ2k9F3G tch9JgX8XTwaGaknkXR15hFkxes6w9Ou_UCzsibtuoWLwLnYbHmnviGfe60k.02WIvlxH84kLF8T EzkAHUUaxQCsxQ_OLa4T3te0tTvk9SCw8iHwCnKSYgOlOnHLEdb5uPiVBio5DJslcwdYiWciwN0o kN9nPna9OHaDYbulqKjoZBdLrCK3hbVNZ4tzA6BpyE1RMkxqk.YMaQc9HnMZ.d0qcH8mNtLoVSY9 hqVf539ngFpB3Bil0Lhuf4QyIxJL.XWOe3v6Y8SKBjznV23VLpMdL5bV2Zk8CHP8clv8RoSJLa2V reMcgoD6vrDXbGQGhYgbym3NWhzTLIya5p4ULjOJYTdMIn6XrFyIt0LO65Cit8lcHdKVa09dh9hL 5x.kdggRoZxJgXeg49azM6ufDujIRsltywyAiTacBFbln72JeV8RX3RZM2LXYGaNNO4O5TdZPPZH H85n7C.UsEaHGrEcXuyldxnwi20.Vy4FGZh5THcTFqbMpFdsSlaTW4Zstfx.WmEKfnj_lhUTn6Dk AYJRMfMvDHDWhrEpaiOzj.d.Jnz5J5pTOgw4- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 17:11:30 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dd9ce508703ae807f045cc18c2c16b5a; Sun, 19 Dec 2021 17:11:28 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211219161816.GA14873@www.zefox.net> Date: Sun, 19 Dec 2021 09:11:26 -0800 Cc: MJ , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F624D6C-1A78-4F08-8AF2-A3959476F86F@yahoo.com> References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JH8QK2fpjz3rrn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2152 Lines: 65 On 2021-Dec-19, at 08:18, bob prohaska wrote: > On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >>=20 >> I would think a mechanical USB is going to pull a "lot" of power when = beginning spin-up, but once rotating should be easily powered by a USB = hub. Though this would not explain how it works on RPI4 unless the = powered hub you're using is USB2. >>=20 >=20 > That's what I thought too. I certainly didn't expect the disk to work > without a powered hub. The Pi4 is a different animal; it has USB3 = ports > and more power available. That the mechanical disk works at all on the=20= > Pi3's USB2 ports without assistance is quite surprising.=20 >=20 > There's a table at > https://hddfaqs.com/seagate-st1000lm048/ > listing power requirements for the drive: > Required Power For Spinup: 1000 mA (I'm guessing they list that as the largest surge current. But they do not list figures for READ or WRITE activity.) = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typi= cal-power-requirements lists the "Maximum total USB peripheral current draw" as: 1.2A (so 1200 mA) for the B+, 2B, 3B, 3B+, 4B, and Pi400. The 3B and 3B+ list a "Recommended PSU current capacity" of 2.5A, the 4B lists 3.0A. Some keyboards or other such could lead to problems if also connected at power up: Having both a keyboard and mouse at power up, in addition to the drive, could be a problem: QUOTE keyboards and mice can take as little as 100mA or as much as 1000mA END QUOTE So stick to a low total power for your other USB devices that are to be already connected at power up. You might have to carefully pick what keyboards/mice/whatever to fit the 200mA budget that is left --or plug some things in only after the drive has spun up. > Power Required (Seek): 1.7 W > Power Required (Idle): 1.6 W > Power Required (Standby): 0.18 W >=20 > So far I haven't tried to power cycle the combo, that might not work.=20= > Still, it's been an informative exercise. Getting rid of the hub is a > welcome simplification. The machine is still up after standing = overnight. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 17:27:48 2021 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 0B4E418E80C2 for ; Sun, 19 Dec 2021 17:28:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH8nH0q0kz3tKH for ; Sun, 19 Dec 2021 17:28:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639934875; bh=LR+8cT25LFW6Uf3iNwibJcQvHgRK377P9k1blwwPUng=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Q32q665dL2Aq2Y0PueMoRm6bu2Z9wo1ozkPBvxszuRB512XTdRJLA2ijkaC8TQG21d86wCbKI9lESrh1+ycHNTvhgnevyZ4/Pbg++9Ukdr/UzKz8quazZz6DbPOFUaRlDw8Wik7syuRXHo5LdOOtlPNsZnuqPK83d5fTFy1wQez6MfNQk8e0LiI//isn8Y6tUikd/rtMVcFHQMnZ/wgqPfQBIWXdGxXOg7LiZuzVGUDTJQBQOYxKwuTHWkgSkoV1jkzA/rez/4e39tSAdyS72gxjP7GJDPAGxSbaby0Aj2OEPTk/isLWKtcMd3nLa0BFHEKZFllgZdlo48YrHV0Dlg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639934875; bh=1YOjBVmepPv6i54zDsgJ0bAHh6c+u1idr2G1uKjN+rV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dwvfksRVadjiXuNVANYZQkcJJ9XVJCkZT94xR+cDv0VFz7kVQXG31RuaFgAXpHW+vs58gKcN6Ob5KBShEsWzXsyrnvFCHpGPncyT8K3oZaqgSz4y6HJJkfSHEnUpqJifDsgzvucmXBIIor5CGiL1Oe0w9JEHktjeRohmPRCKfvHAW4jKUahCaI5v5eRe9wns02Jfrq4ASiHxw3qERENTsrjcj94YyC9emYW9LHSll1T4g4+wllqRnQ1pZ23auF8jKDOhmx4HQZg2Hq9FqGv7z2tOLVYq1CQAYfcIwGxTasuE6hBrVjGyc9eEkci5QfBGf0+UENZjEwkxqqE0Qe83oQ== X-YMail-OSG: pbJia_YVM1lnFhPOcNXNS.1V8mvN3TbHKK9AdIhUN_j5rWnw0zSbAtd8ktKuB3W c4wcwSAjywTlFDXQBEbo06THKUyzgdbaNOKFvOUqsIuYgeQw21cz9WI8QueV9SL9p9Y1wphtJFrD nrAu6iQvuLL1IBYolx2viE5OD.rQYrtChdFfLZzOERaZTdzIWsKm0wKRe6e1LTM0eZ3yRGZylUN. AmLWouF6V81J6NF.6cE73vATx6bj.lsoHba8O9uATd2_IoyMTjx1WFntZBykZlZL7g2VuL5skINI JVjtMc7HVUKypURvXXbD78mxN5aNHdzgKKZnwceJNhzJjNEdq56JQgxHunTXRUnCVVJMJwDWuPQa ardORKgyr8mXs_pl1bF8uF_vPU_r_LZLfjF_4R_v2Rtz98TB1G.j6NFnrsqhZlzUKcU5qvpT87nW ikUJq5fvy6qNplFEMIQmbw7RHJjNgZjznweO_iNpQ_4usp0Cztbmj8DF7hi9V.jyoAswLtvnyrYY UzBNqpvdjIbnNPWPD9m.HgYvXq78s00h4SDAhR472nGrSeCsiCP2LtE.85TLPFr6RMDgAsUkYI67 tmyULNzZNPwlxTQnjC_MJCiIcLYybojYYALdfkaO2pqXF0nK7guSH_fG7JaD.E47TnE9ux5qY1y2 sDabZFbT7aMhZr5KDCszWyrTWcKKhUbYobztiR_k29Yt4HdnFKBN1H303cfwRceZpvc6UC4hXhUe 4Bs2kGCwdgudXFEummNR98294BtUgrzhCjr4jMtYa_P9wNTN4o3xC6VoWQ78QpBNO41fNJZ3YZ7e BbHWI8kpZOSLzt7qTUxEDFG4aliVDfCV1ZtQYCKq7lC465CVE0zody3oAxdr2nXyinGO7NCV5wBo aRlTUCfK_7wlVIxuwQU.629h99O8s7jaBOoTWfkOXLOMd0X6.VKjnomIdvhtBsLR9rEBMSkvNqyJ TV6qg.fJFAMiOTMKc4mozi.LX.TK2oqC3KD78VnM3hB2ZeUmOZMhf42Pmb4sYzbq0RsQEOx7HNBU yFiqBbHjBQExPXXKZ2oSe6oKNh29g_HV9TZEkeWLnpr4hROlSVCBWRki8aHEtJX0zfsuUwfUg6Z7 GjbqRm.21cH4gTeCzccjBM__QXb4ZE8odAnhRKQdesqeCX8zqk0xl_cJfHLh0BYyF3vejUnzCEFI ScGr4qIroPdr_t.W3rOBg2xhBjFNdzb_ISeR.p.oqnA2xfDs6yU0EAQbaWE7lPcdgeDaHZ5y4AZw ytzLDTr0p8h6NmaEvFlpZUMiOOmiRXZU8Iyfy3E8Cdf4OjivpE_njflt5I89oOmELUyUd0snHFf9 SID.nXXDV3hD_Zejgszs0Dv9bRuiaypkYaNn9P3Hk7u2CGwmogmGE7e.2DJishWXwdgBCNsCb4PS 09BCerFgmMY42JuNNQzTztatG5QPn3t0rbnSFn.8_TmQ_mHmOlNGzIHN0O1_LRBZZyBS7RWJ99CF XyB1LZzBTj1cVN4RhFMaMlgaIPxuI6gxwefO_h7NUdsHo8Ua9W0sJBExbiKMKRqU1PlUT.wCzRkQ S0sXITadFxJt2.EZixK8MWrb.G7aoIXWSlpbXB3vjXf7G9uLuW6sh46AedJKO0uMMFjrvckoigy1 OqJbnzQ8tDgLVHCYQlcObPCG.nlDeF2utv7uOo4l5RL.cfQ4PkmCjawzxwbu4ljiVcIjnPtarsYn sT8thfyTcgxPVxAJV5OEeXVe51zBvzna_CRJVJRXuNJg2tj0FOqGwumILzB6Af7rjqslaCwu2rhS 398fEe1My.E.XSMi06fvjQEv5BINVercmWuLtw8_HSLvsxV7Uz.TAGx.MTjRs_Fi4OIzf0EPw5rb fLmNE1d56cqxroHx9VHvkork_FNbf3K4ekoOB7hzvXz2LQndSA8I2UcOCVN3WsxdiquMxYszcVPf 7U8jjXERLJEUiS1mjCk6SPYELIuuCj2Y6nhV1gaj5FSGkg0RKYpJUOxtqBI8uLd9eU.mIJ04uC_C QcCj75mEYdgx2rFqusAQI0EJLrBfDe.ZVyKZ8nKqs33KtKJfCd0GcLjtemH2SHun8.7R4GnOAvh7 7JfHUywY4U3D.mRIWvQt2ggZw6dIVVc69OjITV1p29QMLPoPQ.vrKRtIVYUf.ZKaUo7l6RYoEWK5 kq9vQG4Pix3AEbb3ULM2oKjmNURUClJtiQpQ8SiozLIxKN7yq4Lyu4LEq.kJy1j3tfphx75LlExP lH3wO4p40O9SflTntp8gqU1inbyppTF3LhEtkMw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 17:27:55 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7225ba03912f83a657faec5fa46e7ab9; Sun, 19 Dec 2021 17:27:49 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <3F624D6C-1A78-4F08-8AF2-A3959476F86F@yahoo.com> Date: Sun, 19 Dec 2021 09:27:48 -0800 Cc: MJ , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> <3F624D6C-1A78-4F08-8AF2-A3959476F86F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JH8nH0q0kz3tKH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Q32q665d; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.60 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.89)[0.894]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3093 Lines: 91 On 2021-Dec-19, at 09:11, Mark Millard wrote: > On 2021-Dec-19, at 08:18, bob prohaska wrote: >=20 >> On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >>>=20 >>> I would think a mechanical USB is going to pull a "lot" of power = when beginning spin-up, but once rotating should be easily powered by a = USB hub. Though this would not explain how it works on RPI4 unless the = powered hub you're using is USB2. >>>=20 >>=20 >> That's what I thought too. I certainly didn't expect the disk to work >> without a powered hub. The Pi4 is a different animal; it has USB3 = ports >> and more power available. That the mechanical disk works at all on = the=20 >> Pi3's USB2 ports without assistance is quite surprising.=20 >>=20 >> There's a table at >> https://hddfaqs.com/seagate-st1000lm048/ >> listing power requirements for the drive: >> Required Power For Spinup: 1000 mA >=20 > (I'm guessing they list that as the largest surge current. > But they do not list figures for READ or WRITE activity.) >=20 > = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typi= cal-power-requirements >=20 > lists the "Maximum total USB peripheral current draw" as: 1.2A > (so 1200 mA) for the B+, 2B, 3B, 3B+, 4B, and Pi400. The 3B and > 3B+ list a "Recommended PSU current capacity" of 2.5A, the 4B > lists 3.0A. >=20 > Some keyboards or other such could lead to problems if also > connected at power up: Having both a keyboard and mouse at > power up, in addition to the drive, could be a problem: >=20 > QUOTE > keyboards and mice can take as little as 100mA or as much as 1000mA > END QUOTE >=20 > So stick to a low total power for your other USB devices that > are to be already connected at power up. You might have to > carefully pick what keyboards/mice/whatever to fit the 200mA > budget that is left --or plug some things in only after the > drive has spun up. There is a separate issue of the USB standards for maximum power for one USB2 port. Quoting: = https://resources.pcb.cadence.com/blog/2020-what-are-the-maximum-power-out= put-and-data-transfer-rates-for-the-usb-standards QUOTE In general, the specifications for a USB 1.0 and 2.0 standard downstream port, delivers up to 500 mA or 0.5A. END QUOTE This means that your drive requires more current (power) than one USB2 port has as a maximum. Using an adapter that gets power from 2 USB2 ports instead of just one would be appropriate if what you are using gets power from only one USB2 port. FYI: USB3.0 provides up to 900mA (0.9A, 4.5W) for non-charging ports (still insufficient) and 1500mA (1.5A, 7.5W) for special charging ports (dedicated to charging or charging downstream). >> Power Required (Seek): 1.7 W >> Power Required (Idle): 1.6 W >> Power Required (Standby): 0.18 W >>=20 >> So far I haven't tried to power cycle the combo, that might not work.=20= >> Still, it's been an informative exercise. Getting rid of the hub is a >> welcome simplification. The machine is still up after standing = overnight. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 19:28:54 2021 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 9E92118FC54A for ; Sun, 19 Dec 2021 19:28:50 +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 4JHCSf2pDnz4ZXh for ; Sun, 19 Dec 2021 19:28:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BJJStVg015322 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Dec 2021 11:28:55 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJJSs47015321; Sun, 19 Dec 2021 11:28:54 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Dec 2021 11:28:54 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219192854.GB14873@www.zefox.net> References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@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: <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> X-Rspamd-Queue-Id: 4JHCSf2pDnz4ZXh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2899 Lines: 87 On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: > > http://www.zefox.net/~fbsd/slow_usb_notes shows: > > umass0 on uhub1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x8100 > umass0:0:0: Attached to scbus0 > . . . > a0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number 000000000000A > da0: 40.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > > https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/ > > has material about SABRENT adapters: > > QUOTE > Sabrent and Orico both have the worst track records for working storage adapters for the Pi. I don???t recommend them at all but they can sometimes be fixed. > END QUOTE > > (Not that all models are bad.) > > I've not found anything to identify the specific product > that you are using. He lists some specific ones as > problematical but possibly fixable: > > ??? EC-SSHD* > ??? EC-UASP* > ??? EC-UK30* > ??? EC-UM3W* > ??? EC-DFLT* > ??? EC-NVME* > ??? EC-TFNE* > ??? EC-TFNB* > > (The above are JMicro based.) Can you identify your adapter > type? > The enclosure is simply marked SABRENT EC_UASP, The usb-sata bridge is marked JMS576 2026 QH8A3A A E76H20013 The "product brief" is at https://www.jmicron.com/file/download/1015/JMS576_Product+Brief.pdf but it's more advertising than technical. It claims Windows and Mac support, the omission of linux/bsd isn't surprising. I've tried power-cycling the disk, it doesn't seem to have any effect on discovery using usb reset. There is one slightly odd thing: Once the disk is found, it does not stay found. Left sitting at the u-boot prompt after discovery a subsequent usb reset frequently fails to find the disk and it's durably lost. A total system reset seems required to find it. One other observation... I tried smartctl on both Pi3 and P4. On the Pi3 it failed: root@pelorus:/usr/ports/sysutils/smartmontools # smartctl -a /dev/da0 smartctl 7.2 2021-09-14 r5236 [FreeBSD 13.0-STABLE arm64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org Read NVMe Identify Controller failed: scsi error unsupported field in scsi command On the Pi4 it worked: root@nemesis:/usr/local/poudriere # smartctl -a /dev/da0 smartctl 7.2 2021-09-14 r5236 [FreeBSD 14.0-CURRENT arm64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 2.5 5400 Device Model: ST1000LM048-2E7172 Serial Number: ZDEM543B ....[voluminous output snipped] Might the difference in behavior be significant? Thanks for reading! bob prohaska From nobody Sun Dec 19 21:00:50 2021 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 5854C18F5EA4 for ; Sun, 19 Dec 2021 21:00:52 +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 4JHFVp6WG5z4lhw for ; Sun, 19 Dec 2021 21:00:50 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 3F4891831 for ; Sun, 19 Dec 2021 21:00:50 +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 1BJL0ojQ045482 for ; Sun, 19 Dec 2021 21:00:50 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BJL0os7045481 for freebsd-arm@FreeBSD.org; Sun, 19 Dec 2021 21:00:50 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202112192100.1BJL0os7045481@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, 19 Dec 2021 21:00:50 +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="16399476501.1b36c69E.43452" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639947651; 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=QzThDvaKgLmwNmAga07x/BMiNuV1iNKRW9xRdrzEnEg=; b=kET34nWlc9a8zg4KHx55ZJ9TUAnkymE0qe5S2ljm5DzEEJ7C3bLHowz46PCytslMj1KI+a l49dV7thBSau9yrQgtr6SFuxGw29h4Jer99Sr0BoL/qHQ8X281ZTvGz75e95ycZd/J1ytI BorhUx5GyF01k8S4B0ADSmkaExQmnAClddFzGkEE+H6Yg7KR0D0Cly0/ENndbSCpAOZAD/ I9rAzH+wysHA7LYPsQ9CfV0A+CKLHZKjm1AQ2F6PvOdzTtVPKanSF77efd4j29QP6Tf/TU U9obpDuztMGGHlsJfaXB2GT8EVXQqBLZtserlUxd/U9lbLoKtcHOg7OOzJSemQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639947651; a=rsa-sha256; cv=none; b=W3fJx6UfemhSsX8I5A6zYKJYvjCPLMtLDU9EeTm7Bu627dMp0UDeRnXXTVs/b97QYwLHqh TkiZfQIzkDg0op1k9K0rakMOH3ABhURMPz4yZTF9kEHKIMZB1nkTgrzBPzWEBtVOkJNzm1 k8m6rbxEpUrOHI+jDlWSBOVFqwhxF2Ci4g6p6FH8Qyk40sNoxpnjn6dvr7UIiHSAmIkdh0 weujTa2iuNBMaJU1QTms/r1JTIy4Lkaw5XVEJVsV6ZljtHYhvQRDghnJ8Kd2+Ot/wguN+P PR4Ej3nvjOUhClRLg1BKRbS2oSWlH8b6P+/F6l1ZBrLV7AluLA7JCENJMCjp3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2098 Lines: 40 --16399476501.1b36c69E.43452 Date: Sun, 19 Dec 2021 21:00:50 +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 | 239673 | Spurious Interrupt message from /dev/led/led1 Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 3 problems total for which you should take action. --16399476501.1b36c69E.43452 Date: Sun, 19 Dec 2021 21:00:50 +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        |    239673 | Spurious Interrupt message from /dev/led/led1
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

3 problems total for which you should take action.
--16399476501.1b36c69E.43452-- From nobody Sun Dec 19 21:13:12 2021 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 25D7218FADE6 for ; Sun, 19 Dec 2021 21:13:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHFnN5T7mz4skL for ; Sun, 19 Dec 2021 21:13:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639948400; bh=jZP4lRvHeOrPdIa8nKFcepii9aAalz5lqMUhqofDAHw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IXYZp2/6n/z98w/mcj+IFCXVatNpK0basIlGKm8w0mIBlmBN16D/IntZ8EgkkzlOsxPdUIf3WSJS+J+7lahsmXDo+1y3RgiQj2IRuuuB/FZIPqbBuBpKDTbiTemJ5rgtm0AzWSLuiVd07GicR5oaAXBn43RuOaDie/a24g5qapdCeQG/l6Y2t/DBCGEAflDPDNx+kWI6p3LUNTn4GPHAe9I/D+MTgZMkgZWqbvgtH1wd9DETrqYKYJC6jWqFLhaLcZxWTcH3RG5EA7IuijfvdpiuzXk11uNs+eQFMS4n5LAqZKhudFGRPQDUFZSAgQUBP6I6yUowAZjGPrTUIzVdnQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639948400; bh=grH9sB8xHaFW5Mt11zT/3bT+DX8Wdts809BVppbUN+m=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G0Rxut26XoPIZZZeH3OHW9LuXmvTt3Lvl+B1J55fyPPUfhqGu6VtaTSwyHN8YvJwK+O8ccaWkhZVb3aAOO2nzA5aUPNpanm2bVXjd209R3C1wbTDSwUOCte+wSsIz7ZHDNFyU5MDSGdXTKm9ElJPAlgqvgcuU4qOnCxAc7lasICaRcm0rA8CpzGsavkXgirbGMzTrHkDzr6P/4Lxc5l08H8MM3QFVKxduZEDrg0WRWWuYAb36+QPqOjTiwdkMvuEnOpDjuTxZ+cbahPjOBh0Cg6Ay4CCN23a5530SZJZY6gBQGgsIaEDTsil3rnl19SvbVyMuRwmPydJw/IBKliQ3Q== X-YMail-OSG: f4Rc9nUVM1lCl3tRwhvngTC9uBjnEK2tON0QyOQUgB8pu2t6kB5u1_DGL3bpzvo vIqOU74O7y3X8OELUuSZ9XB3a5MLwahul16TriV4o1ARYIBfcOkB8eNFKKDH4ZNChKtoi8QbMXo3 QT1yT7YzM0q4ki50iBHXNFN154mYCLpPJCH4HkBxykHGHeFTmdv1ogn3Ixif729at7gMMxOB28zX 4HlGR9gPI6x7yQ_0mKrJwiwhvfoN.E1FToqNiP_.7jCVaxjpkPIDM5YwJvxnvpuAND6BacNgw24. 0lwvjwuAvUxQ0pl884xwsYT.cwmNOjkY7ZDrPiOAy.zQ6bD1m2XzbvSG.ReVjr93QmwJEeytwkJJ Ui3Pyhkql4pyPg_D8phxbmIpkoUPbHaRui9RPTIV5Mnfw2ZfTK8lb7obryGzQzf3AjaEfA1Pg948 NFNAzpDawZAYfg7ATBHFLUudhOFU7_CxSqX1SI7kgstN8hvwSV_4FQ4Fe_4oXrGQxnKBZZiNwgd0 yIkJ6Ih8GA18GflvHaOjMYbSTJNYknBouPwHBUV5s3hEOy1N1ipoVswY9BoBTv9fIGCb6m44EJCB jhMAh7KSNG58PoAifKaTHMAObTEyKzrKh2cjIehBlk2QM_aZF7VyF8V3OjcLhOJOVDgMgJ7gYqTq 3N_Dduz6dJOX9drfqAGkfqRH4ANcS11Jgu14wbc3kHHYrecz88lyjQHolRYvc3aGJmkoaH31p61a fYAxH1Us7jh0.650_btHuNgXDfjLkDxye.rfHXPW6T.RQZ9I9Jy7TzrmX.3CnpfYWrvrD4Ux5lg2 r.u7weVYoApsCrrT4cOY3vkMp1_1NPksdkMaqdyNMizPzhd1bf65s1stXqYwdkCskfNqEHroPz.C oWeWuxJpAiRKEyFSQ.4iGghlWUmpTKOndx4n8buQu_ltHYQ5oH4gLec2EkE3TVmCN4q.aVR9R6QJ mHXpeUvdr53ftIiyer6BePNVjkOoqBSPYfOsJ.gsE5otWMJet0gxzQge9fub5gi0CQ1qn9K5BEAR mz2wApjcp7gXPSuPsTjjAVwghFofJjA5Plj6pUk12vr_pGcpVx5Z82wYDDm07u2zvgZcd0KEdYnA 6EnPX4NPgr.MW6Ah8Q72ICnyTUGOJI_qWBEtf31.tdN1P5FtbHlY.Pi20dREIvt270PldS9yMSbh .1Fm9VADDVQ_IkkLMv1jcLXAe81xKI5woEYgvHTTaCXlYsR54zYt4b1rm8frRqeT_S5jcQXLsQiF ukQoIMFCMlTw2DRpJ7gEBjsV7MdwB9SvyI4wMHklnWLbu.NrRzxbauuETO1S1SMDORo7fHyzRj84 EJF7Z1VPQu9wlQoM39xVGBFUVW4BQ51elbRZCokpvg16tSpJOIfUXhf5A1Elh0hkFq9V5pqgqbKJ hW_IEun3eBTsfHJjO5DSmd.0Jxj03bFyc6HRDiz0tHFDjn.VHYZoSTasNBVmthQ1xsT1lfRlQqd3 u9Jh83LQXodAfa4cb4XNUZJ3G6tv1yT7EgGqoAsRwwX1_aOR6.8crf5yjc9AkkNxq7ta87S9eenz kWAH1xcZT1Trf2YmL83TIf3uBGyxe99S520vLTg3OlGhZNcGQk0A2X5OsKbogdaudWyuXNufAQGH xU3o1UUKff3dQj3SthEdL8fQYV6zzx_syHqBR6n.nevrI742wFTl4GJdBeqrrNpJxK_z8ht6eciA L6BohFN14RyOaBZCPa.fxL4TDruNdYLU4fmrnqR2.Q4NzIAlraXoLAkkKc7ztT9l58HXVMXFGHw6 OKLava_D1XfZEI9ldK_GCUVSpdw6r05vChhcg.a.r2ASI4iDjkOlEgS.h61NNv_wU2BsQdDc1Yj. lmSyoKsIwnk.zVWXvyCP1ksgIRIFr3lkS_bhIFw2gUT75ASNnDuJQ30vF_ugumT93yjpMkpPoac8 hUwNeQXhxUlJEgEipALNRVgAPmhPs4sQSOPLAfSW0bTxl5twBTBXcPERkWSXm_9p_7blQtozfHAp .2UiZNG8x0EiqM_.VpHFhSdsZ6QxYnguORzdN38hFqQpyg2nB3GcNkT0q7Tx0mQUBcGxLyOEizGa dALU0NiFzp0g.bSO0tJe7JguaLyVCIF_FXcT_tLFp.7UlUasyBQk5DnVqofecFY9JdIBPxZcycwN 9zsi_8nWVeEU1NCv1d4OzGZEBXAQ9Z1CJsI5gSXCfNYY43mxsj7qpEOVDeYHG6a0eO5iyiBEg8Fz x.f5ahhzY1Sp0kz5yeGp4wqzKiNasOgiKUkwuETnsIkevd_GYCyQAbaOkLy0hV0.NX.UUxdIArRN VlfbODRUniSyc5wzR X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 21:13:20 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1ecc0b9644d1622cb38999c345c6c526; Sun, 19 Dec 2021 21:13:15 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211219192854.GB14873@www.zefox.net> Date: Sun, 19 Dec 2021 13:13:12 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JHFnN5T7mz4skL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4721 Lines: 141 On 2021-Dec-19, at 11:28, bob prohaska wrote: > On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: >>=20 >> http://www.zefox.net/~fbsd/slow_usb_notes shows: >>=20 >> umass0 on uhub1 >> umass0: on = usbus1 >> umass0: SCSI over Bulk-Only; quirks =3D 0x8100 >> umass0:0:0: Attached to scbus0 >> . . . >> a0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Fixed Direct Access SPC-4 SCSI device >> da0: Serial Number 000000000000A >> da0: 40.000MB/s transfers >> da0: 953869MB (1953525168 512 byte sectors) >> da0: quirks=3D0x2 >>=20 >> = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ >>=20 >> has material about SABRENT adapters: >>=20 >> QUOTE >> Sabrent and Orico both have the worst track records for working = storage adapters for the Pi. I don???t recommend them at all but they = can sometimes be fixed. >> END QUOTE >>=20 >> (Not that all models are bad.) >>=20 >> I've not found anything to identify the specific product >> that you are using. He lists some specific ones as >> problematical but possibly fixable: >>=20 >> ??? EC-SSHD* >> ??? EC-UASP* >> ??? EC-UK30* >> ??? EC-UM3W* >> ??? EC-DFLT* >> ??? EC-NVME* >> ??? EC-TFNE* >> ??? EC-TFNB* >>=20 >> (The above are JMicro based.) Can you identify your adapter >> type? >>=20 >=20 > The enclosure is simply marked SABRENT EC_UASP,=20 > The usb-sata bridge is marked JMS576 > 2026 QH8A3A A > E76H20013 THat is one of the ones listed on = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ as potentially fixable (with quirks possibly involved). See: https://www.sabrent.com/download/jmicron-sabrent-update-tool/ for SABRENT's Firmware-Update Tool. Looks like Windows7+ is a required context for doing the firmware update. I've not checked if FreeBSD has any quirks in place. The quirks material on the https://jamesachambers.com/. . . page is not for FreeBSD, but RaspiOS (and similar). > The "product brief" is at > https://www.jmicron.com/file/download/1015/JMS576_Product+Brief.pdf > but it's more advertising than technical. It claims Windows and Mac > support, the omission of linux/bsd isn't surprising.=20 >=20 > I've tried power-cycling the disk, it doesn't seem to have any > effect on discovery using usb reset. >=20 > There is one slightly odd thing: Once the disk is found, it does > not stay found. Left sitting at the u-boot prompt after discovery > a subsequent usb reset frequently fails to find the disk and it's > durably lost. A total system reset seems required to find it. >=20 > One other observation... I tried smartctl on both Pi3 and P4. On > the Pi3 it failed: >=20 > root@pelorus:/usr/ports/sysutils/smartmontools # smartctl -a /dev/da0 > smartctl 7.2 2021-09-14 r5236 [FreeBSD 13.0-STABLE arm64] (local = build) > Copyright (C) 2002-20, Bruce Allen, Christian Franke, = www.smartmontools.org >=20 > Read NVMe Identify Controller failed: scsi error unsupported field in = scsi command >=20 > On the Pi4 it worked: >=20 > root@nemesis:/usr/local/poudriere # smartctl -a /dev/da0 > smartctl 7.2 2021-09-14 r5236 [FreeBSD 14.0-CURRENT arm64] (local = build) > Copyright (C) 2002-20, Bruce Allen, Christian Franke, = www.smartmontools.org >=20 > =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D > Model Family: Seagate Barracuda 2.5 5400 > Device Model: ST1000LM048-2E7172 > Serial Number: ZDEM543B > ....[voluminous output snipped] >=20 > Might the difference in behavior be significant?=20 >=20 Unsure. But . . . The power (current) requirements to get this drive spinning is double what a USB2 port has for a maximum in the USB2 standard: The drive is problematical unless power is being drawn from 2 USB2 ports for the one drive. EC-UASP does not seem to support such dual-USB2-port use. (The RPi*'s are not designed to provide extra power on a USB2 port as far as I know.) That things do not work well for USB2 port use is not surprising. The startup current requirement is nearly as large as the total current for USB on the RPi*'s. (The RPi*'s support less of a total than the sum of the individual ports maximums: only 1200mA total.) SSD's are a better match to RPi* power than spinning rust is, unless the spinning rust has its own power supply and is already powered before the RPi* is powered. There are types of cases that have such independent power instead of being bus-powered. Bus-powered spinning rust is a problem for single-port USB2 (and possibly even single-port USB3). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 21:39:34 2021 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 0D86E18FF5A1 for ; Sun, 19 Dec 2021 21:39:49 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4JHGMm6cpjz3C3s for ; Sun, 19 Dec 2021 21:39:48 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x102d.google.com with SMTP id rj2-20020a17090b3e8200b001b1944bad25so2642789pjb.5 for ; Sun, 19 Dec 2021 13:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FskXSKjH50BAR3o4T954sJIAm/nVz3YRhe94cNJvB88=; b=iONfZoJRNqaT0T2NWAxsei/sY0xh355qlm7UNAx5YkQrMeRZ0C8vnOtsOaRCeX61nT b9smhZ20AZkCF2PM7k926TiuZKO0MogrhSRYyTa9/CIDvv5hgLtj/Q3kj7Ogn+FW1Jzl WSUX9ghHQClmMPBEWbAzKiKrVgWiNVVG8fFQSWUsNaRXB2oQ36GFgZm5vcOh8PVXy8Gw 1RzCurV4RreWJU0Z1TjnaR8LKryiqDKwWlWrsfo3qO2oDpvvUexeq5c4vI+kIHUwnTpf PWlcnCkq9DzHWP97pVUWnRxDsnX1FagYq8J6DP9Pajp5dN06RSJ1htYUXmG7J3EbQuZh 6GaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FskXSKjH50BAR3o4T954sJIAm/nVz3YRhe94cNJvB88=; b=38PxP48tE2Vzy0saZmKa+xAbzjBNm8AKcwQaAilUULRlTBMvQQGCom0blYf5KyBlxh fjrFm6zI/QsWLQkVG0H0AuEK75TlY7fmubNaHJvfnGySdDixGbfCfkYttXFTKgqYATIx RTPxEkVuQQVyfREst/meztYyC6z5W4LS28co5KuEAU9UmUKOJTtGL+1w+1NUlc3id3P7 8iJlMjemXm0S/2KyFoCqXHz8j1ahmpusZJv2nEBOAJdQU4+kEIwPtzCPU2rFSjIbZHcs DnMLrpkUW1dqddQP6ba5yjf9HFmPTEU+2w+8hZp0mZnAiahXWCP6cdYavK/oZ3ewJ4Oq epVA== X-Gm-Message-State: AOAM5339ZLnDqOShn7DI+P8Ij84bGcjG7IV3bPg+NwhXHsVGri6xbb3a kLR3Qxr+XDwksBpSnBDW7Myc3JW24gSZJQy1 X-Google-Smtp-Source: ABdhPJznTqqSFW13OskbyoZypvhCg1/CzarBDFX43YoBkdHL8dLpB4fl3VTKilLEsxKNSA+3RfXnyg== X-Received: by 2002:a17:90b:1d02:: with SMTP id on2mr3724184pjb.204.1639949981894; Sun, 19 Dec 2021 13:39:41 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id m3sm14462124pgj.25.2021.12.19.13.39.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Dec 2021 13:39:41 -0800 (PST) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot To: bob prohaska Cc: freebsd-arm@freebsd.org References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> From: MJ Message-ID: <6edfdb4a-8ed3-7ef3-c3b2-7d2d7fd3206c@gmail.com> Date: Mon, 20 Dec 2021 08:39:34 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20211219161816.GA14873@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JHGMm6cpjz3C3s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1323 Lines: 29 On 20/12/2021 3:18 am, bob prohaska wrote: > On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >> >> I would think a mechanical USB is going to pull a "lot" of power when beginning spin-up, but once rotating should be easily powered by a USB hub. Though this would not explain how it works on RPI4 unless the powered hub you're using is USB2. >> > > That's what I thought too. I certainly didn't expect the disk to work > without a powered hub. The Pi4 is a different animal; it has USB3 ports > and more power available. That the mechanical disk works at all on the > Pi3's USB2 ports without assistance is quite surprising. See here: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typical-power-requirements It mentions 1.2A, which covers your load, but, I would suspect if you attached, for example, a USB 'thumb' drive or other devices you would cause problems. > > There's a table at > https://hddfaqs.com/seagate-st1000lm048/ > listing power requirements for the drive: > Required Power For Spinup: 1000 mA > Power Required (Seek): 1.7 W > Power Required (Idle): 1.6 W > Power Required (Standby): 0.18 W The total draw capable will inevitably come down to the power supply unless, as you know, you use a powered hub (and even then, it depends on the hub's power output abilities). M From nobody Sun Dec 19 21:40:41 2021 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 ECEEE18FF904 for ; Sun, 19 Dec 2021 21:40:54 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4JHGP265cMz3C0k for ; Sun, 19 Dec 2021 21:40:54 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id 205so2845890pfu.0 for ; Sun, 19 Dec 2021 13:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uVZdU1Oq/9Tb/VqGe/9RME9TP2iH44rk10tpNlLc++U=; b=W5qLLy68oLWVTrmbIOzQBsrqq1Y4eLrmy7nz2//b802tTyf6gblQkktiib1W4BtSve zeH1YwAuSGXiXdcRoPSS2qzbZk6Alx4Mi3/ifeYMm92LLJniaKwQ5QazhY4xu3DI3fDC z93Auxsn1AfifrP2oQYE752sFWpfH9E+o1lXF/9L0mkeqMT5IaTJw8mUB5kodxGZYkQA heT48EPGeJG8LbNxoXE7TaIQ+tiWrfR2At4Tq7gz1n4mjNFgW/VMapuFB48Ri6tegYaF iYtkI+qfLB5v2N93J5VQFGajoZ8gAPWSzQlI7138W/mp/iUcuCxvjHIjxPAwdhdjWCAw UU8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uVZdU1Oq/9Tb/VqGe/9RME9TP2iH44rk10tpNlLc++U=; b=lpq4Mzxd+imFwava+Lf0AVFpN49Hk8Kd1/moQzhHXW5nzf8sikdeESCxpa3FQo3lJw EYZA/eJFGrysjhHINEitYl2wrOme8zPlT07d1j3xnNMltcFIdDMdtKhjyPT51IFpuUpG sxCL3ItB7IYcloPUY8QniIR22f824kUXaovCMkGazr/sm9NQlRepPYQPGvvEPNyJT9SW KJ4FeUxCtdABTtlIuwNL/i28j5e7yu+H3IhDvRe1M0+rOwH8uZZw7pmGMA8m7/pPhyvV aQ9fE5sYjR3mWxvRtIh3D+8kjB/yrHs/cZgZlQJNOHmSoB+ugQ6MZsRnwA5evScH8tXm aGjA== X-Gm-Message-State: AOAM531Hf5h1TyIntcwcLJL8AtkU3wp78NPBrTdw4H/clHJuqZLr9NBC tJ5AKjcpSoP9UW00qVCaoKl1nPNoU8iZg9Qg X-Google-Smtp-Source: ABdhPJwAm8RGaVb35QIb9dzujZ1CF5aUZ+vG11q8IMbU75heef+YVH/WvXdy9CsWViMdtImUqgkxCg== X-Received: by 2002:a05:6a00:22ce:b0:4b1:39d2:bc7c with SMTP id f14-20020a056a0022ce00b004b139d2bc7cmr13152429pfj.27.1639950047823; Sun, 19 Dec 2021 13:40:47 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id m2sm9455523pjh.36.2021.12.19.13.40.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Dec 2021 13:40:47 -0800 (PST) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot To: bob prohaska Cc: freebsd-arm@freebsd.org References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> From: MJ Message-ID: Date: Mon, 20 Dec 2021 08:40:41 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20211219161816.GA14873@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JHGP265cMz3C0k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 177 Lines: 7 On 20/12/2021 3:18 am, bob prohaska wrote: > bob prohaska > Oops, apologies, I didn't read Mark Millard's reply later which basically says what I wrote. Sorry for the noise. From nobody Sun Dec 19 22:55:30 2021 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 CED30190C7E7 for ; Sun, 19 Dec 2021 22:55:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHJ3P3zydz3NXD for ; Sun, 19 Dec 2021 22:55:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639954537; bh=UYXtW7RtT3bgMZQnZtyb6mkK5+bgahcVbV+bAjbShnc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=adYIjRL27id3Ow52bVdSymcxF3/KL9Kq/kGTs/ZPv9T7P2Usi7PB6JXJ2bWmRG0Sx0CZqtiN2NflUBN6Euh55v3zERAjQJSO/DdT3lxP6JPjHSi+ccH6qfEaxZKZrokt+OMm72lfBGCQPO/G1ug7bUUTf8kJzMHYQmolajIXO5xHeVEYIp2uBX6ssjIhoYYY2+X10XXwm+/imhX5QVD1QgIXitzZ4+LLzzV/BfPriIcSsLio/D2+6xicEiuk04kOaRVlcXfada5aEHSGREOULBZVZTjKo7PbMu2fppHi3sEHxaZJvqYrF2shDkjJ/7cB77cULdvU1tG7UZ7SAoXjyg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639954537; bh=qyC3o3UqR7ZlOBoywn2blnvRe8QkouAz3AjYQP3FNQc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JtSt6686SaLiIeVxfusdvbqMDax3TDC5UHZIyrtbWYgv0Wjy/TSe4zyYhuSqGHLvcKboiHKtto2dvIdXn2RisGKU4Mskyricxl+4U9k8xcCAiZwx4+HJaslxHlnkgmvG4RwcmoRf/5+UCvGTlBvLigB8ImRT9k+jZuVrA/gO2cYzOiFShgkfP0IvQvqA7bnsd3EETOBk7zjjz2hN9mWuUkC15k/IrWZyYJjuB8KYX6scWqLyntIdeMOtCu4AdpIgP2cOHsG5dyjgoeb8DWVzHfXToki6ReclxthTGPZN9Vn3aO/PpKw1h2MnlApDPG3mtvZj92XCDw/iNzvjQgD1iw== X-YMail-OSG: fGFP4tMVM1lUmVmv_N1djeLW85BZD5s.GPweKZUqv6IlpAO8Fx34usHT7bpJKR0 S9EdgV3Gd9l1YvZT_4E4veXVlRT7xVPpM2cC9WRwogb2C3wzbgyNP2dorhOpsrNKG2uGNPCE.RqK t1XgSaay7rADxT5Wtwbru3WFVBpMBcZo22waduPFQmdibiYt2.sOA_FimxvZ6cuPCe9pc0hetVxb 9O5pp3hhuxMJdtG9dmZQz_EApnTw1.pTy8eQgDv69GU_nyXFQGw2dp2iO31jfi.K9SsD5p66mAHu IXxe_3RqFMJlOHzbZfCWzIGmr5uuHP9_EhEVFEMXbybHWbCfcV5BO8gUOyuFjCp4zAS3RCByQZn3 mVaoro.sGWyf3XboKbqbqb7V2e7pcS1DHXUbd4FkFtvwfCnr4_MY9nUQdJmooN9q3.gZGQ5tM9Cd HCPKDowqmKUiLKeeX8ssNKWrrclJ4gD5dIJKoMXJMe0tEG_zSQcVocqA_FhgjQcPIQE354ncRK4L oPTIVna0EOZ7CqUhSZAKf7_7PHkRihgc.UazmfeWzJvtpHJRHmsLApoFRijyal3SpR8G5e60En5. FQnbwDN919H2ihqFPHPfxiE2ZwsrHUB6FIbBriPx5LXm7rKVy85KkanEmCav8WiY5Qu0POoDJyKx mrbdpYSBxOENqHgDhUv0QnC5CxXK5Xcu4dMnDRVWGmxt.l1K_QM9.yjeiEep0P_qLUFDm3SckZl1 qRLGvaL0u4v75KscLAVjyAKkZlif4CmcQ7JHHIUd1ZJVV3CvxkvHKHYoKe_k2a1T0HbuUQkiIhpz q4t3ocgt26JBPP3C5bIYbZX2UD4muj_p_XssVf9HiSxmJDGqJD8Jsfgfw0zAiK_gVl48gfGWSzZe GA7p4QNTI5abtOfGVEgwy_WnBy8W_7ocZI8FnBpE8W.3xzzL8xno0_m_H8b7p9jGE7AQk1vzjERS 30Ut9NX6Qk0Vo.FGQyccAzDdUUH.Z3DF4nDr1_J5YI3kYqQxJUqeOaP04OLl_B5ae8cU844F7VX5 XnPmEUEBFI4AyCx_4y80G3tHBjufU3eYD1g09RcH85JOx1o.McBq1EDNUSnYeaZf4ahx.GvDB3.f JidBvSZzZt0aMqxs1dAYfooi893k8iktKup6qZm5OeJA066ySlk3GHtpYfsmuq.SQMfqJONL6YA1 .xXH2JgDDJO64laqpuu6eiw1ROuFvEOuYKhnAMLp3Lv8HeXHHk4QOOWJpL7nT6kioG4D07eGpvV_ CdJ3mCix36Pa.ggHWLA48phXMWbupTf6MpU8eKsSRMlFxZwKGZlFuPgqVT2YX..q445U2XclyvIE TftKO7a7O5HZm0.sJ_o3SrjV7pI7ZbP2OvUxEuIUuwQgVZaXr0t1X.oQETkaXlwN9I3pyxIT4p0s 2yXYzw0CSa170RhXn9SGypzbs8KD5VDCAs_3rUx08VA9y2RD_R8wbRf8k8YgTCJYWv7YEOUWxaWH TAxGGuKaBOedKneG.MBGoN2kFBnswg1kp_8N56IzmcJrpurxFHDKwcDlHyszWVsVlxwK.286945L mVGgbLXoeqF4FjRsQpfBgNa7k0BLVYQ2ouhGZuv9gnRBKdevO_2plaE91znPzYDF2CiCOhYcBZMI E4Njng5lFbREtyZ98ZzUfxTNg6Ty0a7tCjywqfcurjdcINUNhmxLrT_DNJyTpNks1r.3k2jDiqTn mOTtO3NNSYsvNBondNAUFTaslZvv1bNTd7cLvrhhbIqYvYh8VCKCFl.wL71c20bsa1QMi1IDf744 WeEAoTUMYS5aB2wwlwBWiBsMWr0xMxAhzu0SJbT40PrGWlX3mKFHQK0eq1Bl3quNbaejil5TDwtr 2f7ow3W8pTFPpgGZBGnDeYRW23faWWAaF5LSgdNj.52tx_zQFvXoKH1e7Mz_tsStu06rWExO3X0n vAJlH6We9YDq_R20IXXzM3XiSsn.rEfBONbFY0vH.KpE_aXLbhEJmvTd4O9bPCU0a14GAXjXZJwj ry.fy1fO4jcI9oNfRQpi4ZLtIGTaqpMeRuBAoMQH.sI110.JwY7I5lfOnq7ipN12Zf50ywq4cHLT vMx2ZKT5mxjiCjEAgi0rCRHvND2TntN7hldkSVYglhl9ezqo9tlOWEKfxv2fEX1UMtQQb097OWUd 8Rw5PpV9Nl4ld2Fr3Xwer3GfS2V8gs5lDQLJM65s5BPBkvZpAnWvUSERTjee6yvPgk3pLsyQwKTn IQubYa4h7.DHGjCCvcrd7.sW71j9FKgrhL5tKtjPtnXQqjGUzg.xudv.6HeLYViIpKb89_Kdm3X7 cUcxlD6PYqZ3jEKsjNA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Dec 2021 22:55:37 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 506391ccf1e8f1c4a306c233227ee85e; Sun, 19 Dec 2021 22:55:33 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <6edfdb4a-8ed3-7ef3-c3b2-7d2d7fd3206c@gmail.com> Date: Sun, 19 Dec 2021 14:55:30 -0800 Cc: bob prohaska , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1387CAB3-CFE7-4C47-8A9C-24D6E56D8C3C@yahoo.com> References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> <6edfdb4a-8ed3-7ef3-c3b2-7d2d7fd3206c@gmail.com> To: MJ X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JHJ3P3zydz3NXD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2501 Lines: 68 On 2021-Dec-19, at 13:39, MJ wrote: > On 20/12/2021 3:18 am, bob prohaska wrote: >> On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >>>=20 >>> I would think a mechanical USB is going to pull a "lot" of power = when beginning spin-up, but once rotating should be easily powered by a = USB hub. Though this would not explain how it works on RPI4 unless the = powered hub you're using is USB2. >>>=20 >> That's what I thought too. I certainly didn't expect the disk to work >> without a powered hub. The Pi4 is a different animal; it has USB3 = ports >> and more power available. That the mechanical disk works at all on = the >> Pi3's USB2 ports without assistance is quite surprising. >=20 > See here: = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typi= cal-power-requirements > It mentions 1.2A, which covers your load, but, I would suspect if you = attached, for example, a USB 'thumb' drive or other devices you would = cause problems. Unfortunately there is more involved: USB2's standard indicates 500mA (0.5A) at maximum on 1 standard USB2 port. It takes 2 USB2 ports to get to a total of 1000mA (1A) (unless a port is designed to go beyond the standard). To my knowledge most RPi*'s are not designed to support more than the standard USB2 power on any of its USB2 ports. (The 3A+, Zero W/WH, and Zero are apparently exceptions, depending on the power supply used and such.) There are drive cases with support for external power supplies that could be used, so long as the drive is powered before the RPi*. There may be adapters that plug into more than one USB2 port in order to draw extra power. Then there is the use of SSD's instead of spinning rust: they tend to not have the large surge currents involved. But the combination of spinning rust, bus power only, and a single USB2 port for power is fairly generally unreasonable due to the 500mA limitation. This is true even if the total USB power that the system provides is much larger. >> There's a table at >> https://hddfaqs.com/seagate-st1000lm048/ >> listing power requirements for the drive: >> Required Power For Spinup: 1000 mA >> Power Required (Seek): 1.7 W >> Power Required (Idle): 1.6 W >> Power Required (Standby): 0.18 W >=20 >=20 > The total draw capable will inevitably come down to the power supply = unless, as you know, you use a powered hub (and even then, it depends on = the hub's power output abilities). >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 19 23:48:38 2021 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 7FE8318E5A18 for ; Sun, 19 Dec 2021 23:48:51 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 4JHKDf5xQbz3jbb for ; Sun, 19 Dec 2021 23:48:50 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pg1-x535.google.com with SMTP id r138so7784663pgr.13 for ; Sun, 19 Dec 2021 15:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qO/X0/K6HPUhTWuc7GmS1Zq2lYdVypwzoVmYR8g8O+0=; b=UBHG93dZXw7XYytBUN5+7gpcXq+mY4WtfHb9hQbc/6pwV6qZ95D7GC2hkotyHPI29R u/XiuKObDTe/QLWQA0AB6zh9wqxfT0IIin+5lF1v9sXo3fgWvxjE3aAGE+JR4H/Ijz5h 68wqfsLoyHqKO5Z5KBHoTv83DsHgNKOmUN1XmTm7vOlJx9D+ImO24yvxPrsWtHGFkHwW 8hhF6iva8D7unams0mtv7JCI9j+ZqYCQWBzsQIyFYZDB5AUbt/TxDKToybw5Px1InQwy sGgniJpjKxemN8y+F3dKVPt3nHUYoz5eGaY6EFZx0xqWao2fc534v2M481AoHlNVmEm2 hEWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qO/X0/K6HPUhTWuc7GmS1Zq2lYdVypwzoVmYR8g8O+0=; b=gVPwQEfcWreXpEIQi7ePYMBYekifedaU4PCBlhf2tQPUzqJj55nxkMCqNjCmuLV5Kl ljM5cRYsUPYacdFQbPY98pOQG+iqPQFdy2Ua7jcYDC3wu1T5wwalsFpkzhkGwa5vfDeM JueAJsHA0Rrkw8vGcmNYgXpPSacGfZlAZ4f/bUMDuHUvYsZe/QZmTFvrwvpbbBT+89UO NeahM1xLHD0VX/DikMW1Xj/pfHMmvBAwmx2TxcTprKf5i5aqsZDbZbKrAUhjVm/BLKtt YvfiJbau7YqL/NVE2NOUJPCdywK6iMi35ycJ5+8idspkOkw06vMHqD3cMtWz2rMFoFz1 P2DQ== X-Gm-Message-State: AOAM531Djh/uYXoYqcrRDLAiHDPpHUWvVCvh6U96ZQOxKlsGkTh3q8uV wV+F+u98r7RB0rFS++EzraIR/CEGXrDb52lj X-Google-Smtp-Source: ABdhPJxlwMtzKfld9qcqiUJzhh5FGQ8rzfHOCbC00Zs06tRKV0CWC2WszND00ZbedKJmDzvqPNoF8w== X-Received: by 2002:a05:6a00:b8e:b0:4ba:cbf2:516e with SMTP id g14-20020a056a000b8e00b004bacbf2516emr3530461pfj.72.1639957724422; Sun, 19 Dec 2021 15:48:44 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id u22sm15898401pfi.187.2021.12.19.15.48.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Dec 2021 15:48:44 -0800 (PST) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Cc: freebsd-arm@freebsd.org References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> <6edfdb4a-8ed3-7ef3-c3b2-7d2d7fd3206c@gmail.com> <1387CAB3-CFE7-4C47-8A9C-24D6E56D8C3C@yahoo.com> From: MJ Message-ID: Date: Mon, 20 Dec 2021 10:48:38 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <1387CAB3-CFE7-4C47-8A9C-24D6E56D8C3C@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JHKDf5xQbz3jbb X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=UBHG93dZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.990]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::535:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1749 Lines: 35 On 20/12/2021 9:55 am, Mark Millard wrote: > On 2021-Dec-19, at 13:39, MJ wrote: > >> On 20/12/2021 3:18 am, bob prohaska wrote: >>> On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >>>> >>>> I would think a mechanical USB is going to pull a "lot" of power when beginning spin-up, but once rotating should be easily powered by a USB hub. Though this would not explain how it works on RPI4 unless the powered hub you're using is USB2. >>>> >>> That's what I thought too. I certainly didn't expect the disk to work >>> without a powered hub. The Pi4 is a different animal; it has USB3 ports >>> and more power available. That the mechanical disk works at all on the >>> Pi3's USB2 ports without assistance is quite surprising. >> >> See here: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typical-power-requirements >> It mentions 1.2A, which covers your load, but, I would suspect if you attached, for example, a USB 'thumb' drive or other devices you would cause problems. > > Unfortunately there is more involved: USB2's standard > indicates 500mA (0.5A) at maximum on 1 standard USB2 > port. It takes 2 USB2 ports to get to a total of 1000mA > (1A) (unless a port is designed to go beyond the > standard). To my knowledge most RPi*'s are not designed > to support more than the standard USB2 power on any of > its USB2 ports. (The 3A+, Zero W/WH, and Zero are > apparently exceptions, depending on the power supply > used and such.) You are correct, however, it seems the RPI foundation violates the "standard" and creates their own for Bs: https://raspberrypi.stackexchange.com/questions/51615/raspberry-pi-power-limitations (Section: How much current can be drawn from the USB ports?) M From nobody Sun Dec 19 23:54:09 2021 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 EFFBE18E7A0F for ; Sun, 19 Dec 2021 23:54:04 +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 4JHKLh5FzBz3lQb for ; Sun, 19 Dec 2021 23:54:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BJNs9l3015917 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Dec 2021 15:54:09 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BJNs9HG015916; Sun, 19 Dec 2021 15:54:09 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Dec 2021 15:54:09 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211219235409.GA15576@www.zefox.net> References: <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@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: <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> X-Rspamd-Queue-Id: 4JHKLh5FzBz3lQb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3040 Lines: 81 On Sun, Dec 19, 2021 at 01:13:12PM -0800, Mark Millard wrote: > On 2021-Dec-19, at 11:28, bob prohaska wrote: > > > On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: .... > >> (The above are JMicro based.) Can you identify your adapter > >> type? > >> > > > > The enclosure is simply marked SABRENT EC_UASP, > > The usb-sata bridge is marked JMS576 > > 2026 QH8A3A A > > E76H20013 > > THat is one of the ones listed on > > https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/ > > as potentially fixable (with quirks possibly involved). See: > > https://www.sabrent.com/download/jmicron-sabrent-update-tool/ > > for SABRENT's Firmware-Update Tool. Looks like Windows7+ is > a required context for doing the firmware update. > Yes, I'm searching for a Windows machine to give it a try. I wonder how new the update is; running strings on the .exe finds Borland C++ - Copyright 2002 Borland Corporation > I've not checked if FreeBSD has any quirks in place. > My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report umass0: SCSI over Bulk-Only; quirks = 0x8100 da0: quirks=0x2 A second Pi3 that uses the same Seagate drive through an ASMT bridge reports umass0: SCSI over Bulk-Only; quirks = 0x0100 da0: quirks=0x2 It has no trouble finding the disk in repeated attempts. > > The power (current) requirements to get this drive spinning is double > what a USB2 port has for a maximum in the USB2 standard: The drive is > problematical unless power is being drawn from 2 USB2 ports for > the one drive. EC-UASP does not seem to support such > dual-USB2-port use. (The RPi*'s are not designed to provide extra > power on a USB2 port as far as I know.) > It's clear that I'm pushing limits quite hard at startup. Still, by the time of disk discovery the initial surge is over. There's no mouse or keyboard on either Pi3. The Pi3 that finds the disk is running -current, the Pi3 that can't find the disk is stable/13. > That things do not work well for USB2 port use is not surprising. > > The startup current requirement is nearly as large as the total > current for USB on the RPi*'s. (The RPi*'s support less of a total > than the sum of the individual ports maximums: only 1200mA total.) I'm _just_ under the limit at spinup, but well under once running. > > SSD's are a better match to RPi* power than spinning rust is, unless > the spinning rust has its own power supply and is already powered > before the RPi* is powered. There are types of cases that have such > independent power instead of being bus-powered. Bus-powered spinning > rust is a problem for single-port USB2 (and possibly even single-port > USB3). > I don't plan to run the disk without an auxiliary power supply long term. In fact, since removing the powered hub doesn't seem to help with the enumeration problem it could be put back. Thanks for writing! bob prohaska From nobody Mon Dec 20 00:48:58 2021 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 5C57A18F3D79 for ; Mon, 20 Dec 2021 00:49:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHLZ80c8lz3vSs for ; Mon, 20 Dec 2021 00:49:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639961342; bh=q02SdwrbFquUZ7xZMtzGsokQEt5QZh+jH6YuFdaVy6M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TvKyeemO16C+GJfvOX3DS9OXiTCltDRAfnLIaRxV4cSiGIYFclu0jqA19lLA/FIZ6Ey6APvhE7J55pTUrs6NgFtjSRGq1TIzk8kz56k4DBJQH3PxZ8Po9nVM+1MbuX8fTKCKrhQlucn8tfQa7VDRlYRU22qa5yg3dsXaTru6FOZhKycWoi3UglfOR5tMEo0OguJVdEqyuK+RZ4IOpZUXO+UBH8KXdr+hJxwgqA5vO6TT/GHDr345gXOT09Trh0p0tNoF4Nck2xZHXtrtu19XiOQhBsFW5mB8KjgXaRndYWgZ0P3qZrB5yQyEfylRfL3dkuIMEU7K9PUovlDFrCplwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639961342; bh=506Zyqwt6tQvL4m+9PTrtNjXkhpRDtXGD1LHOgk+CAi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tROw+kZ6MIEWmhPxdajALOFy8E/JkjnDxxIW17M2BDl2Qemhk4wN6+pEFFNCTqitqd5RSwoBtwMIpfm5/D+d1w1DN5dWIFrL6n0QjT43cxLuxGu1vT4sPC79y2iYo9gHZmdD0h36+Ez97hemYeZdtngUfO26fpBUFlEToUkdlbcS3bHAcldSH9+rq1ZWPXipGQfqTFC/qcS2IVIy0hs8NYDfnZvHfSjuHPDCG6uiLyzo9i7+djJF22IYJzPStK6xbAfEXzYLLkqS/ZGLE0oTIITuOOaHaIhy8X+nkMGQOWG8DP2ns+qH4iWRpmiCw47RpzF8CRbWS+gTKn/9Tlf1Dw== X-YMail-OSG: O2yWULAVM1lZjHDlWqDBiDXd5GoJ_XKDyZmp6z5L.gRw.jf5v1C5beJ.gZYZBaI A6lmMoGxb1WKZyMPktifcYQmubKpw.N._c8B9otjEO5RnTrSzxbf6x.DJ6wHUotl3zImmeZpbOix vFdp63SXi5Pr.jY6nAv8SFwTaw1C6V7c6fWujrJjzU3taVa_UnNpJnzLJoNbnWhuRbkrzy0JqgOd ZqugkZ6K9xjZcRUz57SnkXk3OJcoPQECi.FzGrWarvEwXyWoipTfV6JKY2iLTm9VOZMoaClmSBmN SxnVUXkzS7xn.p87PdrA9z4gWksenKKkr_ogU9_bvcfL2MUDzSUTuGfoYE6aV0aUc5cPGSzSK7x1 xMY8z0R3Uj73YIiio6xBc8Pgg3HM8k6iMgBBWbPN_Kf3tSbLApXFkEMSV6Kmh1EDEEnyeVAxBMJ0 jika92IVHSB0IJD8k9qwNfxuaaFtmS4jIPUoiYu5Lk9zrU3BKlE2vpXeGf6zP7KWLlJAvpPnQJRl h.DNaihoVuZ3RYqqXwbGAT9UT8gvRxUSbXoHOWFb52shm0K_7__cmb9BKO33c1cCoJMI1gQxcIuO 9CVOFbWci4XAdDP1trjE59vMpgyhO8z7vj9dhgBNia4Za0qhTObVPs.svJcOME5LRTTrZUH2EDtD eDRjs_4HLBfaE2z2deqjqRWUTeDeOM14iobmlSSUErYLkuzxWZrtvXzyu_UIJqcx.mj3FDPeyCQ5 bvTHG4d5lG7yrpjLTnKhXvuQPfzZdkeZ3blQD7A80Bzp.lZz.evsnp3OsSEvKsPxZ8RCPj3sxXP6 5MUo85xbxJoeXpPOjUqSGVDaqR60Ju58rDTVo8scyUNjmaGjx4XRvB7i3QflVly.XTStGLoTdBTR PhaHqOQ7doiaZ6.t_MIOv7OOIfgOiUqhBpcj.cbO8F.yukwgKuqfUD_pJUCS3h2_dMLPdkj2AzFG 8JYJyh_eZOtXqk8H6bMBemaJugCNoso7n2UypGK1PDpLNHPen6s1ZcO2XbsfOL_iX_SOkkZNtCqS btJERE9UHy7a_MJJmyE978Ed1R0oYAFFnH4c4Trkfs_Yb7fJz_bCAt5tidqia9UxEuJl8vsy7Sva LlZhzOHEgeE2uVsXyjrGuB48Z4IaU59mJcAvGs0p2baewQpQrBw4ne6wnnyRNE667lYpYm5YajW8 aaW2dAKo.qiImvYZSykpdJ4MhZwCkR81UWHRQcBZTZWjAUtDd7RIZsvle.Ep8YZ9mlqzBt9Eim9B 2eSZFdwn_.MJB_ab9LveZWrAQk5bGMoPssNLi2K5ye7k4ec.0pCDlbpTtQ5r8bFLr1KvMohUefWE iNvnOMD2VQw.GeDp6FeB5PKk3c3jI83cUb4DZxw5xT1FwERKLMjRQgML2jc_Qlp.t7w8qFcgWADG Ih6QH2Uh92WZ2dQv.UJ2ttHELlK7PxfEghGPaW6xTgJa_XH4Qmrgii6H5gAzwAwy8Vy7rzWUQzDu C03bv..cdP40bX2I1bR0bEz3FVstX984pbKTBpCNf8qnE7ZRq3zeleI8HcRHNtFP.p6l.TXvFAvN N23Ijk7CMEx0tXfW32SOk_nZCrt7SfkD_5m4yVoGopt1L63ZPdoJVKY9jidJsPCjMzy93TIMrCZs HOAVJyh7iZm3JKeEmqbZX9gom__m1W_pdkCLWtWZrHZqObbjiqi1i0q6vut6nf2m6vQHtgSoK6Qr MJRtVu3jD0I2t6B2eKFbSMNyQ3RKwXE_MQ.0KjuK1UHPYvozXkAfAHeP3fUFtUd39TlQeWj45QTw 2j7qjaIr_F4FBF8MmVvYmGWr6Sa6UN_JlDIRUJkDV2dnqPkrE1bseFaRXBy0mL3OgsKS7sdSVr9w j4vgphtj5C4V2Pg6y94dQyIUrAobaWep7WTH5Ong.YAGp2VA3hqDjs3CIq0oQXqmyNGek0G.0Tlj FZ4JfKnz3gORRdmCjgxnK2mZMbTMP8ARSLB.jMVxFLPunhzAJ5aF65_iZAft6njI7fkkFq.ePL_h iM5bic.5XGfwSgQXe012x7N.XAocUUUI_Har2j_km_4llsFwWtj4iH380FdEt7PVkgfFf4BHF4Ig xCFR2jej_Zy9YTAudhozZetvOGuKnVRbBj6L5BYLDneLYBCf0JM6SWDzbraeu_Dln7uNmgP.pOa0 PPWUurnQmofDrNeVim0yaiuG1OYLbWWZOW1BduHieXTrawXPSgPaWlyF55rWah0YnMHhMPUYrlEt t4St8YyK5vwcEndZHWUUfPIQNQuMn.RlU.KcJ.IwEgq6dAPoEarZPr6fMElV8v5ZlSu9G9iuz7Y_ ctOzyUgsPeZ_xkHQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Dec 2021 00:49:02 +0000 Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6ad4a0763ae0224336b677da2657b384; Mon, 20 Dec 2021 00:48:59 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211219235409.GA15576@www.zefox.net> Date: Sun, 19 Dec 2021 16:48:58 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JHLZ80c8lz3vSs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4579 Lines: 135 On 2021-Dec-19, at 15:54, bob prohaska wrote: > On Sun, Dec 19, 2021 at 01:13:12PM -0800, Mark Millard wrote: >> On 2021-Dec-19, at 11:28, bob prohaska wrote: >>=20 >>> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: > .... >>>> (The above are JMicro based.) Can you identify your adapter >>>> type? >>>>=20 >>>=20 >>> The enclosure is simply marked SABRENT EC_UASP,=20 >>> The usb-sata bridge is marked JMS576 >>> 2026 QH8A3A A >>> E76H20013 >>=20 >> THat is one of the ones listed on >>=20 >> = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ >>=20 >> as potentially fixable (with quirks possibly involved). See: >>=20 >> https://www.sabrent.com/download/jmicron-sabrent-update-tool/ >>=20 >> for SABRENT's Firmware-Update Tool. Looks like Windows7+ is >> a required context for doing the firmware update. >>=20 > Yes, I'm searching for a Windows machine to give it a try. > I wonder how new the update is; running strings on the .exe finds > Borland C++ - Copyright 2002 Borland Corporation >=20 >> I've not checked if FreeBSD has any quirks in place. >>=20 > My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report > umass0: SCSI over Bulk-Only; quirks =3D 0x8100 > da0: quirks=3D0x2 FreeBSD version(s)? (The quirks lists can be distinct.) U-Boot versions(s)? RPi* firmware version(s)? The RPi4 could well have distinct results on USB3 vs. USB2 ports: The USB2 ports are likely limited to 500mA but the USB3 ports support 900mA (so: near the spin-up requirement). > A second Pi3 that uses the same Seagate drive through=20 > an ASMT bridge reports > umass0: SCSI over Bulk-Only; quirks =3D 0x0100 > da0: quirks=3D0x2 > It has no trouble finding the disk in repeated attempts. FreeBSD version? (The quirks lists can be distinct.) U-Boot versions? RPi* firmware version? And are the RPi3's the same model (B vs. B+)? >>=20 >> The power (current) requirements to get this drive spinning is double >> what a USB2 port has for a maximum in the USB2 standard: The drive is >> problematical unless power is being drawn from 2 USB2 ports for >> the one drive. EC-UASP does not seem to support such >> dual-USB2-port use. (The RPi*'s are not designed to provide extra >> power on a USB2 port as far as I know.) >>=20 >=20 > It's clear that I'm pushing limits quite hard at startup. Still, by > the time of disk discovery the initial surge is over. Being mismatched for power could have non-time-local consequences to either the drive or the adapter or the RPi*. (Avoiding USB Hub protocol activity is a separate/additional distinction.) > There's no > mouse or keyboard on either Pi3. The Pi3 that finds the disk is=20 > running -current, the Pi3 that can't find the disk is stable/13. What specific current and stable/13 commits? What of U-Boot versions? What of RPi* firmware versions? >> That things do not work well for USB2 port use is not surprising. >>=20 >> The startup current requirement is nearly as large as the total >> current for USB on the RPi*'s. (The RPi*'s support less of a total >> than the sum of the individual ports maximums: only 1200mA total.) >=20 > I'm _just_ under the limit at spinup, No, you are not. 1 (standard) USB2 port does not supply anywhere near 1000mA, only 500 mA or less. It takes using 2 (standard) USB2 ports to get 1000mA. Some adapters provide for making such double connections to get the extra power. This is true no matter how much total power for USB that there is: per-port is normally far less than that total. (The total is also commonly less than the sum of the per-port maximums, such as 1200 mA instead of 4*500mA [2000mA] for the RPi3*'s.) > but well under once running. >=20 >>=20 >> SSD's are a better match to RPi* power than spinning rust is, unless >> the spinning rust has its own power supply and is already powered >> before the RPi* is powered. There are types of cases that have such >> independent power instead of being bus-powered. Bus-powered spinning >> rust is a problem for single-port USB2 (and possibly even single-port >> USB3). >>=20 >=20 > I don't plan to run the disk without an auxiliary power supply=20 > long term. In fact, since removing the powered hub doesn't=20 > seem to help with the enumeration problem it could be put back. There are cases with external power allowed that avoid adding the USB Hub protocol to the activity. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 20 01:13:42 2021 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 2922F18F761F for ; Mon, 20 Dec 2021 01:13:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHM6h5rBwz4RZK for ; Mon, 20 Dec 2021 01:13:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639962826; bh=g7Q7X1JRLEhmRwLakpY17mh5No0TIHLzeiqfoXqop9k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cB093MXrL6jAShYyD8oGCIYWSJQ7RMelRU+cfVVx2upGWUIfrdQgP2/xIqbMEpQ/2mL5RUmBGPlVXYZsggGoiiVymcE6uZN4Ec9/U1azHoqCB56NVYCgiKczmYDvHS1uQBoCJK2CGJZzxC0HGVe2YtfwJQScORyf0GbEDjqSB0EN7pnTmRaHT6zG18f1sp1fn9SJpXAMLfFDvjq8RpDB7YKb9FG4lC0E67kWsXwx444ui8ManYvfzS+ICl9voyWGFYgLbZ9nP+ievj8xTD4BWR+AkoZTPne9z6kHnpZx9pPjbrbgNC97iK3kwKJV8LHfaB8S3Jqgr7w8m33Iz3hsFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639962826; bh=MCdzCmATCanVso8ISDdAfYM3wrotJ70y9riPntGiGBG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KrzcRYRf9s124FkU8BDnEAQ7rCwP0CceocZTYC0Js/KgwBJ7cLq0PZKC3m5fXXNE8bGcBTf/KL29Gs9MvcBpnYRHvk1T2oR9QrWxDnYfHPmbU+43xvMkcKEBzc32oWllAOCllN/yIH8YKNiF1IKVNHrBtagZhiOb//N6ToUo43ZwPJ0ZU7PeMBFAlFebbehFJ9w29gb9vHXutqi2ag4XlkFynwIP8yZdHaSVtJcl5lthGmI0wd9nJg49I9SIzrLAl8sNE378t83WIGPi77+0aNS0in3PbhMd4ofLs6RMatwnTHwB3y+x46ooKwKzEr8XbZOcYTr7HlkEirkTjCCg+g== X-YMail-OSG: JGRK7hEVM1lo_cRFRRy43PeIz_eB3wZ7NgCMVuUmMLymIG2W92H9IuXqc.YdeR4 dnFS.9nNTxC8EPsJmoPiU5pLnH5fgYBPg_vZpn1L8v2FN1gf0rL5Wd49j4psh0uYvVBb2H6x7Jaf daXRX7TG0byeFVt4kYMQdKqJAwwVjDdCf0qU2ZdIoS1GWYOYwXGiJTd9_4gFhWZACDW3qtBbwM2Q ivHIXIAZ8Rp.lz6ZszTtE6HOrC8zvbzcLRrrbLi7TnAWJHuuL_EdyyAGQ9DCfaSZL7xWBQr38Del 8hO7EMNMg2sxV46AluyVZ0_YeFB0B7.aRTvOlGMamswROiz8S0BxsVRY9sXeL40AxdxpcyZTTHoo hU6npFc3FjRfrcDTjp7LwNmNqwsPaDez9nx2Uh96tJFB6OR6hu5EYgy_RMaUq5QjCcgiFn_vcri6 WOZ7pb7lcyDB0wradqyEEmQjUCIBH699bDgV9eZ3OPjUN3P5hUP10fl8vIZozQu3OEOBu2d0YkNL D8Mr17.4AE273gTuxiFbOmcdre.iU500BBrf1Phhe8ZhFheUyUBNJn2ZdHub5PgegCU86ptwxPGA 1TOtDWfqcn.tkHzKGMbvt3ZmNM4GYl8Ea_vg.Sj1h87X8muniSOazZBfIHF6pQzRSvsoT8Uf7us4 Zjddk3I9qxNJlqWomDMyxdDyDC0CfkHGJK9urywF8oSGTtd..HT6BvM6dHc1Y2H_K3X5MVB5gblw vz2yueWm2Z_xkGUTowEAx23cQYmnOHkP6ugd5IfLelI0NB0ObvRiHubd3MLMQ0P.kdPYGlwkMvZs V5PEDxjzTyXteSClgxwQ14auTPhPm2YuyEp_Z7tSOBXDjbpFIlKuEXGvRlFFKLHuxED4hND3ChlZ eh8CLH.yE8domTos9TW7BjYHP4rL52.WeZ9fjF.sAZ3oOm22FeTF0um0kqykbm8oSszzW3ll6Fan tRS.pUvF6OYIy0LEk9Y7nLdUpICtHoqVi8XVJ55eAbbv.FLN1VZLZ2clUuIZC5UeJIof7O.K0FpD LKjwclJWek8rJC2b2v9xHVmFsd1T32BqlE3eFUMfGRiw1IEGYwqUxVYMmSkkA7lAYsaDwIalql17 gkiT_SzXAPhJX0o6frGggy0Ls3hX6r4QCoA8.SzPca.7Y7Zv1Tt7rcgCI1pKe95UQU3u1J52aqCJ drVhCorhSYVnOTNXRf8iJpzm_iJ836Izw1OEp9AND0G3_9eG7iSRNqwB87QT8jQ6Iq2byRrAOuhM Qk9msyktI3HtqY0Gw_MlLqRK8jKoKwz2zrcfTCQayVdYEkbe5pF4bqJZ0nERHcyZTVv_KOWLweq8 P0wCeBN.I10zFgo77zhTQh5CO8PtPwkqDZwQkB8VeiZaCRIc6oa8c_uqT69e8rsE7Ac3o55MH8Es VwSVVCjStbVQp2rUUXsccFVAiPp5VKbCsd9UkYtLpcvv1rPd.JXJEw6sRVmqX7S.B5V_zhqUAuJP aQ5MEHidWA3e9oSEzCACWXgQZuOCH4jf11_S8gDk0LNGQ3M2V1lFPMHvbAy5JbFqs87lCBUjsVLi hOSaeiQuiKsNvDor81qDRP0d0lqTYC1eRsXvd3hf1rakq5sb5xfHOz3i1L5B.rL7Z.hOGCUZ.jJo GOsZ.ZIhf1j_CKrBnVi7nQPSU4Msme_tf0weaIeVXIgY9icN6daoz3eQAJCErNLcq7lSiXwHSSFK YUQJFMSft0L8S77VKzKxfj8rR4K62RUWiLbKtzWIYaIe2RNM.zue5HBhdbFvSE15jvfV4g4dFrRZ 4kfpTKncBkYmGnKIFwJyrN_ZV.d01YNhaRVeU3eE_aQuhbiQotNTP6pI0EA.V4RTpsf2amQqwHh9 zNozNiUPi2hYRxIKzsK42os5OYwRllyS.xoUFqQ14xwgkuoiUm6ZLlcBJcqoOVReNRlE.9hWqtmA cWhSGTcS9CuYUvf.9yd.yAshLDgQXRMg7UAruj5BKev4Jt51M3bkp.Ks7QV6BBbQvtvBNnemBSCT wxrqkGNaAIkY5QBzfc8eN24KLwsRqehPxuzy9HGrrjBKg9DVOf5FQh9JVZWCoSRKklZA1jry3MGW ePiUINXikXPpGlrCcGKH5BKtQFgXGe2H0deu7__li_BDD.6_k4M.VJaxne3kQJcH8M80JM2a7s33 cU_3YZkjag4tviTAGmv66AY46FAyp2d_uP924sTiy7CcQfcqMjZ1X8FgJwZ7Ou3wxmNyPeJrHsBS _4XVNX89hsrb_OqWb1FMfT0whTEGw6d_JAftFUxGsoy_zqA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Dec 2021 01:13:46 +0000 Received: by kubenode507.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 82fa1c84ca766ce5265086548c34a0a1; Mon, 20 Dec 2021 01:13: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: Date: Sun, 19 Dec 2021 17:13:42 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211217013613.GA4452@www.zefox.net> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <6105a8a6-e760-2183-72fd-92e5a60aa8df@gmail.com> <20211219005134.GA12292@www.zefox.net> <4910504f-3051-9a95-d8e4-95434042196d@gmail.com> <20211219161816.GA14873@www.zefox.net> <6edfdb4a-8ed3-7ef3-c3b2-7d2d7fd3206c@gmail.com> <1387CAB3-CFE7-4C47-8A9C-24D6E56D8C3C@yahoo.com> To: MJ , bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JHM6h5rBwz4RZK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2817 Lines: 73 On 2021-Dec-19, at 15:48, MJ wrote: > On 20/12/2021 9:55 am, Mark Millard wrote: >> On 2021-Dec-19, at 13:39, MJ wrote: >>> On 20/12/2021 3:18 am, bob prohaska wrote: >>>> On Sun, Dec 19, 2021 at 10:03:47PM +1100, MJ wrote: >>>>>=20 >>>>> I would think a mechanical USB is going to pull a "lot" of power = when beginning spin-up, but once rotating should be easily powered by a = USB hub. Though this would not explain how it works on RPI4 unless the = powered hub you're using is USB2. >>>>>=20 >>>> That's what I thought too. I certainly didn't expect the disk to = work >>>> without a powered hub. The Pi4 is a different animal; it has USB3 = ports >>>> and more power available. That the mechanical disk works at all on = the >>>> Pi3's USB2 ports without assistance is quite surprising. >>>=20 >>> See here: = https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#typi= cal-power-requirements >>> It mentions 1.2A, which covers your load, but, I would suspect if = you attached, for example, a USB 'thumb' drive or other devices you = would cause problems. >> Unfortunately there is more involved: USB2's standard >> indicates 500mA (0.5A) at maximum on 1 standard USB2 >> port. It takes 2 USB2 ports to get to a total of 1000mA >> (1A) (unless a port is designed to go beyond the >> standard). To my knowledge most RPi*'s are not designed >> to support more than the standard USB2 power on any of >> its USB2 ports. (The 3A+, Zero W/WH, and Zero are >> apparently exceptions, depending on the power supply >> used and such.) >=20 >=20 > You are correct, however, it seems the RPI foundation violates the = "standard" and creates their own for Bs: >=20 > = https://raspberrypi.stackexchange.com/questions/51615/raspberry-pi-power-l= imitations > (Section: How much current can be drawn from the USB ports?) >=20 Quoting that material: QUOTE The USB hub on the B models does not appear to be compliant to the USB specification and does not limit current. Individual ports can supply in excess of 500 mA independent of negotiation, subject to the overall maximum limit and adequate power supply. END QUOTE That such is not documented by the RPi* materials suggests that they consider it unsafe/unreasonable to depend on the behavior on at least some RPi*'s (if it is indeed as described). Still, it may explain why the bus-poered single-USB2 port spin-ups have gone as well as they have. There is also a claim there of a part present but not documented on the published schematics. This might mean that the status relative to that part has varied in time without the model number(s) changing. Depending on the part's behavior without checking for its existence on the specific RPi* might be a risk. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 20 04:39:56 2021 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 0F942190073B for ; Mon, 20 Dec 2021 04:39:59 +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 4JHRhZ565tz4lr7 for ; Mon, 20 Dec 2021 04:39:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BK4dvc9024164 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Dec 2021 20:39:57 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BK4dvmk024163; Sun, 19 Dec 2021 20:39:57 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Dec 2021 20:39:56 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211220043956.GA16208@www.zefox.net> References: <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> 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: 4JHRhZ565tz4lr7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4863 Lines: 137 On Sun, Dec 19, 2021 at 04:48:58PM -0800, Mark Millard wrote: > On 2021-Dec-19, at 15:54, bob prohaska wrote: > > > On Sun, Dec 19, 2021 at 01:13:12PM -0800, Mark Millard wrote: > >> On 2021-Dec-19, at 11:28, bob prohaska wrote: > >> > >>> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: > > .... > >>>> (The above are JMicro based.) Can you identify your adapter > >>>> type? > >>>> > >>> > >>> The enclosure is simply marked SABRENT EC_UASP, > >>> The usb-sata bridge is marked JMS576 > >>> 2026 QH8A3A A > >>> E76H20013 > >> > >> THat is one of the ones listed on > >> > >> https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/ > >> > >> as potentially fixable (with quirks possibly involved). See: > >> > >> https://www.sabrent.com/download/jmicron-sabrent-update-tool/ > >> > >> for SABRENT's Firmware-Update Tool. Looks like Windows7+ is > >> a required context for doing the firmware update. > >> > > Yes, I'm searching for a Windows machine to give it a try. > > I wonder how new the update is; running strings on the .exe finds > > Borland C++ - Copyright 2002 Borland Corporation > > > >> I've not checked if FreeBSD has any quirks in place. > >> > > My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report > > umass0: SCSI over Bulk-Only; quirks = 0x8100 > > da0: quirks=0x2 > > FreeBSD version(s)? (The quirks lists can be distinct.) > U-Boot versions(s)? > RPi* firmware version(s)? For the Pi4 that works I find FreeBSD 14.0-CURRENT (GENERIC) #18 main-aee99ab4fe: Wed Dec 15 23:45:26 PST 2021 U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000) The start* files are all from March 4 or March 7, 2021 The files haven't been altered manually, but possibly by installworld/kernel. The Pi3 with problems runs FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n248556-0848451a2ee: Wed Dec 15 19:54:57 PST 2021 bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 The start* files are dated March 3, 2021, u-boot.bin on the microSD card seems to be U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) and all are from the original -release image. > > The RPi4 could well have distinct results on USB3 vs. > USB2 ports: The USB2 ports are likely limited to 500mA > but the USB3 ports support 900mA (so: near the spin-up > requirement). I probably shouldn't compare the Pi4 with the Pi3, they're very different in the USB department. > > > A second Pi3 that uses the same Seagate drive through > > an ASMT bridge reports > > umass0: SCSI over Bulk-Only; quirks = 0x0100 > > da0: quirks=0x2 > > It has no trouble finding the disk in repeated attempts. > > FreeBSD version? (The quirks lists can be distinct.) FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n249322-ae87a08c410: Mon Sep 13 14:44:29 PDT 2021 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > U-Boot versions? On the microSD: U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) > RPi* firmware version? Quite old also. 2018 and 2019, but I'm not sure the dates are right. There's a file named uboot.env that is dated Dec. 30 1979, that can't be right. > > And are the RPi3's the same model (B vs. B+)? > Probably not, they were bought some time apart. I'd be hard pressed to say which is which without disconnecting them. > >> > >> The power (current) requirements to get this drive spinning is double > >> what a USB2 port has for a maximum in the USB2 standard: The drive is > >> problematical unless power is being drawn from 2 USB2 ports for > >> the one drive. EC-UASP does not seem to support such > >> dual-USB2-port use. (The RPi*'s are not designed to provide extra > >> power on a USB2 port as far as I know.) > >> > > > > It's clear that I'm pushing limits quite hard at startup. Still, by > > the time of disk discovery the initial surge is over. > > Being mismatched for power could have non-time-local > consequences to either the drive or the adapter or > the RPi*. > > (Avoiding USB Hub protocol activity is a separate/additional > distinction.) > > > There's no > > mouse or keyboard on either Pi3. The Pi3 that finds the disk is > > running -current, the Pi3 that can't find the disk is stable/13. > > What specific current and stable/13 commits? No custom changes. > What of U-Boot versions? > What of RPi* firmware versions? > The best summary I can come up with is: Not able to find the USB disk, all dated 2021. Able to find the USB disk, dated 2020 and older. > There are cases with external power allowed that avoid > adding the USB Hub protocol to the activity. > I've got a powered usb-sata adapter on my shopping list. Thanks for writing! bob prohaska From nobody Mon Dec 20 06:08:29 2021 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 DD942190E21A for ; Mon, 20 Dec 2021 06:08:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHTg04Q0zz4vc8 for ; Mon, 20 Dec 2021 06:08:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639980516; bh=g21hpF6ds0mV/E9DdItH7dqeBIOB83roItMiTC2Om/Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=a3VgdIrFKeDYy4Ou6rtcQ70am03zEDbkY9myWpvURGeiJI8pm4KDHmSb4u/c2CHf7j2nq/CNKoqlvC/m2XRPJuSpQYGPjK9E65lDn4ckSL9We9kZWFAGZzSKIk39VhsYcy58WFm40/wvUkBQcsJrYaZxE0lSincfakUCTS+mf8ZbTem9Dp81iamFpqj/kCl2uQR0uB4UgkBDagEjAE9B+mIXhDCyrYym15ejLVkgK7/YgkS5vQCFsDTb/IGD0kDTzjrivCnIxpqM7nyyppmDxwqeFhGelGKOfovGIh6zSlUwjLYQVti/AMoJFEc/qNRubNFEINa7blzeWrYdL4W/Dw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639980516; bh=g+We2Z04pv6eM/fa4SByTnue5hahkpi7nE4JsJrzDNd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OXh5bnJuDdvajrMPEYD1RSKxGO4BbJ71mE6v7Ja5gq8vJD1/1VQR8Ca9kTJ5RbttmEAIm9SyVy67sqXb/ASfrRUhQi12Wxizrr8DtcyR42Vq/xsJuKMq0VtsXjj2mVCldxcGjjw9GhSf55WtSTX4Juh0RI3Tix58z6ak+N1TzGMo2huGtNGCix6Wj1mMw1MkVMA/NaYe+JPIhG3LOvFkA9JY3USeKMBW5Pl0ulxIC7HA5N6s6jXWEleT4nx3Nk6Yd64zt1HD6hfC+tGYxFXK49Znk9dG6MbGf4j6rQnmoqVqfyTKJBB8yVIbflnF5gIeNaiHGmlYQZ1jKF4RN/LHgw== X-YMail-OSG: 15socnoVM1lg_OE_WTMz63JV10_rZZsDZzVHVO5jSy7e9ghKn4fjnKOsIb2z92i A0AY4GD9Kblk9uYuIDXrWfW8QrrUcZZNfSs94lLI0AfRzOj5QTjnzKLxTIN05SIi6Ymf7N34xz5B D4M8dqzWTWtKlc3m2vlORZ3qZjhzEWSGQ26pwD8JHkg.tYVtc7qYW0xFh1U.ZKoLxEbTMBgN7hzG Rw13449HjscBN7l8vFzphe2A3N9WdnVR.4gG4oyS_viswG0bDImWVbfOjsWbEo_Ed3CClkwbm8WB ctSmPuSM88cTWQFdMDt7g9Ka22LVrFhOOjiH6wP6r4aXGWVG_EnacwWEESQuWHJZ.fkFEomrbdho lAXNIzFCNftM5cWngaO9abK2fJsxZ3hE4nXCKzJD.EfXeqWKyaTd995nvgqc44BQJSvZs.l2FTTV ASsr_o9yt2zcPfJ.6sXdRTFiUq63Cj6FzuZjKhtVzgTYDjKbp2eSO.GY1FjvZiaQIunuS6wq.ral 986qRpPiLOeJrz0d4LODh5.YNK8GEs9T3kiri1DdQVHS94mT_VCQp5q2VdFkGzVtDlFxgFW9IMvX n4o6oixcZvLN8EWvQK97j.nzvJmoD65GXXAsgeAYgPXtGtwX0ZsCR82Kh9aIOwtSb1XERA7TJSMR xi4fe2FmHeEpeA_aEKotm.P5_uB3cQdsLS7QOjqHr36wlSKdm0rvSI5._37fiGL0EAt8gA7z5Ajv v_j8Ev9nL_KxOYScN6NXcCPNhVgZ4kCi2Nt4BCPWsCrB0DwqDQ2cCvj5XoDtQvUSGDdU5VGTjWs6 v6BXQU4rP6w2feo3ez2HXVPVXTJS5Rmrcrb_XwojJrwuCT7.xYDlJNCwMqatosNwciPOK5wDRH2U 1Aw5whtFwtgtp1FxMW_wSCTEOqxi1XxpKR2h4SFUzgM8l5mSqqtWznWRtaVqMNUULPVeR8r0QiGO XEoUAE5o2tezNgitRQVRlQFi.yTr0QU7Q33dsDDayAOLzftjiJLWo2BRFGTPZeCDY6zqSTlEMaQM I2_Owu7QntwWUAcdNMxK5ARv2YglVbOyR.kNfxIKinKslcJAd99JSI8abtL8HuXL1xeWbDYu0tB2 PDYsbvps5reLLbpa_IO0sgqQdKRCecPqMgmnVMO8ectulWJ2ksaYQrGJRbMZn47ph15D41JaN1pH wtn8.aaddKDBRtPOXYHOGeR5UmBRkQY24.iyLmiysfkILmNcyVMraYm08VhKKYnZM4TKHuNUF7N0 z1iac4mSFXN06w4kS6PCDy.AT0mBUgKMAQeg6mz5kJEZ4anyKsgOwt0Mrf.y6w5qG.pHJaSflYdO Qw52h3GzdvJOgz4eR681uApgT0_2g8FXRVJOMEkTg3g_mVF8viYReoeZQ0kcW5gnbDs9c4gdJN63 kYYrDEFNl2m9df_xrRy_K4xsvYLSOn3YYyqeUo85ZJ2BMX1lAMZRQCXptBW3kMQ6s_5jfdvLB8wU u0UNVrUWq12nu5RygOihY9hwSm4NGTtD78varAkHXgayrI_tNkbkSMovyDFhnVf0_o6oXa29jvjU riuWcc_Nb.lU2etuNrwEzqX0Uw5bhSjymtJQs4jcB.2iVMEPF9MvAi6AI103CwPhLM1tI9eB0MB9 DMx69v754oO3MK_l8O6kE9vI5siLGw9LNi_iwutIcWg.LK_ED5qMDxFvOENLOIG5LyqOvW6qZBPb DP0KmvZWMoOsznoDPz1To50A2BF_T7EO5Snl1GqQNsys5CABi83yKROGPKNT_c6LwZW_7s6cCjau Z.BivY_QVDWE6rmPuGOMvc3KFyZPFmVi.lYsRUQg1KV8gP2vOHDyPJ3AhZh24jRKLZ0sXqcIC4fM 8QJvUX0vKQb3Sw5FOR8v8y0zL6Zcirzf1Awatyj1Gx62Qnq2xqVGmqgnx3M_UoD7t_VUT.9F5v1B gIhii9dGsyqblCWgQ9ePP.EokiIsjgSbWcGYxIas2YguVFZniC5kS6BLEK9dBlMUgcmkiXd7odeA 0Ehak2A2hffGgdtts9fRTeqhOhRtDdmKfgsEefHT.FFXdW.opTcCq8R68AlTqeWlRn59lVh6aPgy YbMtGYxUhfjne149i53MM1Hd9Z.XeBl89YVdMr8kgIzz9.jmKiisAnpGP24jytyQxOHO4p4qmwiT Q8P801snqPr5sis377z4bYX4Zo6Nnr3E5t1NtNekLlW.gIx.HXni7oDK6_kkJXZ4r0.ujsrFFaKa wDNgD1DzYcSZ2T2Om3IR01DcvO5Z.IKclv89kS6u2sbPx6tOhXiceOhVogT_kQcngpFdtl5g7Kc4 IYYi.wJMpr61UjyL7BgiCGm6UnGpHIIWcQ96lN7.vxPsvcUSoYkq5Yi._EsixRDSh7lK1eWcpZA- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Dec 2021 06:08:36 +0000 Received: by kubenode515.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 706fa83a8c677adc792c12882f52473a; Mon, 20 Dec 2021 06:08:30 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20211220043956.GA16208@www.zefox.net> Date: Sun, 19 Dec 2021 22:08:29 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> References: <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JHTg04Q0zz4vc8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 8725 Lines: 257 On 2021-Dec-19, at 20:39, bob prohaska wrote: > On Sun, Dec 19, 2021 at 04:48:58PM -0800, Mark Millard wrote: >> On 2021-Dec-19, at 15:54, bob prohaska wrote: >>=20 >>> On Sun, Dec 19, 2021 at 01:13:12PM -0800, Mark Millard wrote: >>>> On 2021-Dec-19, at 11:28, bob prohaska = wrote: >>>>=20 >>>>> On Sun, Dec 19, 2021 at 12:55:12AM -0800, Mark Millard wrote: >>> .... >>>>>> (The above are JMicro based.) Can you identify your adapter >>>>>> type? >>>>>>=20 >>>>>=20 >>>>> The enclosure is simply marked SABRENT EC_UASP,=20 >>>>> The usb-sata bridge is marked JMS576 >>>>> 2026 QH8A3A A >>>>> E76H20013 >>>>=20 >>>> THat is one of the ones listed on >>>>=20 >>>> = https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi= rmware-updates/ >>>>=20 >>>> as potentially fixable (with quirks possibly involved). See: >>>>=20 >>>> https://www.sabrent.com/download/jmicron-sabrent-update-tool/ >>>>=20 >>>> for SABRENT's Firmware-Update Tool. Looks like Windows7+ is >>>> a required context for doing the firmware update. >>>>=20 >>> Yes, I'm searching for a Windows machine to give it a try. >>> I wonder how new the update is; running strings on the .exe finds >>> Borland C++ - Copyright 2002 Borland Corporation >>>=20 >>>> I've not checked if FreeBSD has any quirks in place. >>>>=20 >>> My troublesome Pi3 and trouble-free Pi4 with JMicron bridge report >>> umass0: SCSI over Bulk-Only; quirks =3D 0x8100 >>> da0: quirks=3D0x2 >>=20 >> FreeBSD version(s)? (The quirks lists can be distinct.) >> U-Boot versions(s)? >> RPi* firmware version(s)? >=20 > For the Pi4 that works I find > FreeBSD 14.0-CURRENT (GENERIC) #18 main-aee99ab4fe: Wed Dec 15 = 23:45:26 PST 2021 > U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000) I pay attention to the "2020.10" part. The build time makes no obvious distinction on its own about the content. > The start* files are all from March 4 or March 7, 2021 The file system dates need not track the RPi* firmware build dates: they could be any later time. More appropriate to report is the likes of: # strings start4.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) > The files haven't been altered manually, but possibly by = installworld/kernel. >=20 > The Pi3 with problems runs > FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #2 = stable/13-n248556-0848451a2ee: Wed Dec 15 19:54:57 PST 2021 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 I'll note that the stable/* use sys/*/config/GENERIC files that build non-debug kernels but main uses sys/*/config/GENERIC files that build debug kernels. > The start* files are dated March 3, 2021,=20 Again: something like the following is better to report: # strings start4.elf | grep "VC_BUILD_ID_" . . . > u-boot.bin on the microSD card seems to be=20 > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) > and all are from the original -release image. Then, for example, start4.elf would likely have the: VC_BUILD_ID_TIME: Feb 25 2021 type of VC_BUILD_ID_ material as shown above (if I remember correctly). >> The RPi4 could well have distinct results on USB3 vs. >> USB2 ports: The USB2 ports are likely limited to 500mA >> but the USB3 ports support 900mA (so: near the spin-up >> requirement). >=20 > I probably shouldn't compare the Pi4 with the Pi3, they're > very different in the USB department.=20 But using the USB2 ports on the RPi4B's could be more analogous to the RPi3*'s in some respects. Using USB3 ports is definitely not analogous to the RPi3*'s in various ways that need not be different. >>> A second Pi3 that uses the same Seagate drive through=20 >>> an ASMT bridge reports >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> da0: quirks=3D0x2 >>> It has no trouble finding the disk in repeated attempts. >>=20 >> FreeBSD version? (The quirks lists can be distinct.) > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #3 = main-n249322-ae87a08c410: Mon Sep 13 14:44:29 PDT 2021 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >=20 >> U-Boot versions? > On the microSD: > U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700)=20 Definitely older, so different in various ways. >> RPi* firmware version? > Quite old also. 2018 and 2019, but I'm not sure the dates are right. Again: something like the following is better to report: # strings start4.elf | grep "VC_BUILD_ID_" . . . > There's a file named uboot.env that is dated Dec. 30 1979, that > can't be right. Probably just established when the RPi*'s time was not set correctly. It is a script file that predates the UEFI style of U-Boot builds being used. >>=20 >> And are the RPi3's the same model (B vs. B+)? >>=20 >=20 > Probably not, they were bought some time apart. I'd be hard pressed=20 > to say which is which without disconnecting them. The debug boot output reports what is necessary for identifciation ( from http://www.zefox.net/~fbsd/slow_usb_notes ): MESS:00:00:21.547594:0: dtb_file 'bcm2710-rpi-3-b.dtb' MESS:00:00:21.554836:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb MESS:00:00:21.559497:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x4000 size = 0x6ee8 Example .dtb names are (grabbed from a RaspiOS64 context): -rwxr-xr-x 1 root root 27441 Nov 30 13:14 /boot/bcm2710-rpi-2-b.dtb -rwxr-xr-x 1 root root 29558 Nov 30 13:14 /boot/bcm2710-rpi-3-b-plus.dtb -rwxr-xr-x 1 root root 28939 Nov 30 13:14 /boot/bcm2710-rpi-3-b.dtb -rwxr-xr-x 1 root root 27429 Nov 30 13:14 /boot/bcm2710-rpi-cm3.dtb -rwxr-xr-x 1 root root 49833 Nov 30 13:14 /boot/bcm2711-rpi-4-b.dtb -rwxr-xr-x 1 root root 49877 Nov 30 13:14 /boot/bcm2711-rpi-400.dtb -rwxr-xr-x 1 root root 50555 Nov 30 13:14 /boot/bcm2711-rpi-cm4.dtb The correct bcm*.dtb will show up in the debug output. So, the http://www.zefox.net/~fbsd/slow_usb_notes file shows the debug output for a RPi3B (not a RPi3B+). Looks like you have a context where substitution tests might be possible, at least if machines can be down for a time. For example, swap just the 2 adapters and see if the problem follows the adapter vs. stays with the drive/RPi3* combination. A separate test: swapping just drives to see if the problem follows the drive vs. stays with the adapter/RPi3* combination. And: swapping just RPi3*'s to see if the problem follows the RPi3* vs. stays with the adapter/drive combination. Doing all 3 checks for some interaction effects. Hopefully only one of the 3 gets a "follows" result. >>>> The power (current) requirements to get this drive spinning is = double >>>> what a USB2 port has for a maximum in the USB2 standard: The drive = is >>>> problematical unless power is being drawn from 2 USB2 ports for >>>> the one drive. EC-UASP does not seem to support such >>>> dual-USB2-port use. (The RPi*'s are not designed to provide extra >>>> power on a USB2 port as far as I know.) >>>>=20 >>>=20 >>> It's clear that I'm pushing limits quite hard at startup. Still, by >>> the time of disk discovery the initial surge is over. >>=20 >> Being mismatched for power could have non-time-local >> consequences to either the drive or the adapter or >> the RPi*. >>=20 >> (Avoiding USB Hub protocol activity is a separate/additional >> distinction.) >>=20 >>> There's no >>> mouse or keyboard on either Pi3. The Pi3 that finds the disk is=20 >>> running -current, the Pi3 that can't find the disk is stable/13. >>=20 >> What specific current and stable/13 commits? > No custom changes. Your text like "main-aee99ab4fe", "stable/13-n248556-0848451a2ee", and "main-n249322-ae87a08c410" answered what commits are in use for each. (The one missing "-n??????" text is odd by the text being missing. But the aee99ab4fe part should fully identify the commit in main.) >> What of U-Boot versions? >> What of RPi* firmware versions? >>=20 > The best summary I can come up with is:=20 > Not able to find the USB disk, all dated 2021. > Able to find the USB disk, dated 2020 and older. Your earlier material above answered the U-Boot version question. The RPi* firmware one needs the outputs from the likes of doing: # strings start4.elf | grep "VC_BUILD_ID_" . . . >> There are cases with external power allowed that avoid >> adding the USB Hub protocol to the activity. >>=20 >=20 > I've got a powered usb-sata adapter on my shopping list. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 20 20:53:43 2021 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 A38771900DD7; Mon, 20 Dec 2021 20:53:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JHsJL6y8tz3D8j; Mon, 20 Dec 2021 20:53:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 883D9D1D4; Mon, 20 Dec 2021 20:53:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F1DEB54E2A; Mon, 20 Dec 2021 21:53:52 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 15.0 \(3693.40.0.1.81\)) Subject: Re: /stable/12 future From: Dimitry Andric In-Reply-To: <5CA8FE25-F46A-4902-9FFC-266347C88021@FreeBSD.org> Date: Mon, 20 Dec 2021 21:53:43 +0100 Cc: toolchain@freebsd.org, freebsd-arm@freebsd.org Message-Id: References: <5CA8FE25-F46A-4902-9FFC-266347C88021@FreeBSD.org> To: Jan Beich X-Mailer: Apple Mail (2.3693.40.0.1.81) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640033635; 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: in-reply-to:in-reply-to:references:references; bh=ptq0RhsJHvZVlj9sSCVsvzuJwGPDw8PiHuMA6ZssNS8=; b=iDRSaGz6AKBACQBoMsasrA/jhjmf1t7vHxDLvX0qPrnwpBviOW5P3R56qyQTk/YGeOQsvr +aPZduObCp5axnmID92Wuti4Dq7mwbIXt+QhlRrsuhPRnXYASLXlRBtDrsmsfZ/v2GjJNv A4Grn8E26Xmfj5n1olDwlwUEvaNHVynxEzrh+N4AIScU87A5TKX2sCMEMa7ZPQdfu7sxTx /FbnnPygP0VyeAP6clP2SWiQfXlsuykev1dBz8E0c/rw1LY9wCS4WzC9X71gDSIC0mkqnQ rbhK03DiDU5feTSTvg1sNoQsiu23fWHXGfm98Fe5OIRYu95o4v16NC+dX7yYiA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640033635; a=rsa-sha256; cv=none; b=Yex39JikFHVV3ByPXcHsxatpO+/aHWmF3zilHrq7iIjFZxT1SUHNfvX1Egy52doy2GWLKl 7ncAT8keXFGKdL/KnCjtzn5c0Ct4p0pqCJl6c3zvNqM59PO6mTH5249oUsP7wscakrljw7 7Wnq6nMRwO9vyc33XCBrl1HHKNcCIDKjuWzq4QhhvioTchJn2KTsn4pa2tfmogoZIzISHv h+HVcy4vLOJxifCO5rVpFFhb7XmVNMAxn4kAzUEtOVyj/x5dG8c6IJmept72NCc+yzbrEx 77Kd+HtGd8pZemSLWYeMrYwp28Ut6ciMrQ44OhpODBxDHfsevNgnqLtSjLY3iQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5122 Lines: 115 --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 8 Dec 2021, at 21:58, Dimitry Andric wrote: > > On 8 Dec 2021, at 20:47, Jan Beich wrote: >> >> 12.3-RELEASE still uses Clang/libc++ 10 from 1 year ago. Do you plan >> to update in future as /stable/12 is supported until 2024-06-30? >> >> libc++ lags behind libstdc++ on C++20 features and sticking to an old >> version puts the entire branch on a deathbed. Given drm-kmod on >> /stable/12 is stuck with Linux 4.16 era (discontinued after 2018-06-26) >> /stable/12 is already mostly dead from desktop POV. >> >> See also >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215193 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260139` > > I'd rather merge llvm-project 13.0.0 to stable/12, but I didn't want to > do this just before 12.3 wrapped, and it's also a bit of a hassle to > figure out all the cherry-pickings... Since stable/12 lags behind on > many other build infrastructure improvements, some commits don't apply > cleanly. So I'm working on this now, and making some progress. The first steps have been to merge everything up to llvm-project 11.0.1. While almost everything in "make universe" works, I have hit one pretty annoying snag: the arm.arm target (aka "armv4"). This has been dropped in FreeBSD 13 and later, due to it being old and missing lots of features, in favor of armv6 and armv7. I have been able to work around things such as missing atomic support, and some other issues. But the big problem with this target is that it was frankenstein'd into using clang as its compiler, while still using the ancient BFD ld 2.17.50! With clang 11 and higher, I quickly ran into issues that this ancient version of BFD ld chokes on ELF files with more than 64k sections, and these are now produced pretty often, especially if you are using -ffunction-sections -fdata-sections. However, C++ programs also emit lots of comdat sections, and due to some arm specific shenanigans, this costs 4 sections per symbol! So any largish C++ program goes over 64k sections, for example clang and lld themselves, but also the googletest suite we have in-tree. I did some spelunking in the binutils git repository, and I found that there is an upstream commit that fixes the 64k sections limit. Unfortunately, this is a big commit that is also under GPLv3, so we cannot import it as-is. And even if we got permission from the original author to use it under GPLv2, it would still not solve the problem that the old BFD ld is *extremely* slow on these files. Case in point, linking clang.full with it took >60 minutes, even on a fairly fast machine! The obvious solution would seem to be to switch to lld as the default linker, however that also runs into a snag. Since lld uses the blx instruction for interworking, it prints a warning "lld uses blx instruction, no object with architecture supporting feature detected". And because we link with the --fatal-warnings option, this stops buildworld dead in its tracks. Obviously, this warning could be ignored (by removing --fatal-warnings, or patching it out), but I think this might result in issues when the actual binaries are run. Unfortunately I have no way to verify whether this is the case, so my current working solution is to switch arm.arm back to good old gcc 4.2.1, which should work fine in combination with the equally ancient BFD ld 2.17.50. Since this combination has bitrotted a little in mean time, it was required to add a few minor patches to the tree to make it build. But I expect the produced binaries should run OK on actual armv4 hardware. So the executive summary is: * clang 11 and higher (up to 13) can most likely be backported to stable/12 * except for arm.arm (armv4) which will have to choose between: 1. clang/ld.lld >11 with possible blx instructions, no idea if this will work on actual hardware 2. gcc/ld.bfd which should always have worked, but no shiny new clang or lld That last option would also mean that many ports can't be built of course. But it seems hardly relevant, as nobody is going to natively build Chromium or Firefox on those low-powered machines? In any case, I would like to solicit some feedback about this, so I can continue merging. Personally my preferred solution would be to switch arm.arm to gcc, so it can deorbit in peace. Otherwise somebody with access to this hardware should verify that a world linked with lld actually runs; that might not be trivial. -Dimitry --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYcDtVwAKCRCwXqMKLiCW o9ixAJ4hh7kgoAlYR0Vr1odqGIuzyq0GAgCgh+P56nJim8+bX0EjHpTqT/8jSKg= =Yn87 -----END PGP SIGNATURE----- --Apple-Mail=_D10A660A-733F-4735-B61F-04522ADBD240-- From nobody Tue Dec 21 18:00:41 2021 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 71F1219050C3 for ; Tue, 21 Dec 2021 18:00:43 +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 4JJPQ23GJmz4jcV for ; Tue, 21 Dec 2021 18:00:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BLI0g93029732 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 21 Dec 2021 10:00:42 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BLI0g7X029731 for freebsd-arm@freebsd.org; Tue, 21 Dec 2021 10:00:42 -0800 (PST) (envelope-from fbsd) Date: Tue, 21 Dec 2021 10:00:41 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: ld: error: bzlib.pico:147: unclosed quote Message-ID: <20211221180041.GA29679@www.zefox.net> 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-Rspamd-Queue-Id: 4JJPQ23GJmz4jcV X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [1.51 / 15.00]; RCVD_TLS_ALL(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.86)[0.862]; DMARC_NA(0.00)[zefox.net]; NEURAL_HAM_MEDIUM(-0.75)[-0.751]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 610 Lines: 17 A try at buildworld on a Pi4 from sources updated this morning stoped with Building /usr/obj/usr/src/arm64.aarch64/lib/libelf/elf_update.o --- lib/libbz2__L --- ld: error: bzlib.pico:147: unclosed quote ld: error: compress.pico:108: unclosed quote --- lib/libcom_err__L --- Building /usr/obj/usr/src/arm64.aarch64/lib/libcom_err/libcom_err.so.5.debug --- lib/libbz2__L --- ld: error: decompress.pico: section header table goes past the end of the file: e_shoff = 0xc388 cc: error: linker command failed with exit code 1 (use -v to see invocation) Anybody else seeing this? Thanks for reading, bob prohaska From nobody Tue Dec 21 19:57:27 2021 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 92742190EFC4; Tue, 21 Dec 2021 19:58:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (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 4JJS1Y6Y8Jz58qx; Tue, 21 Dec 2021 19:58:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f180.google.com with SMTP id r2so83315ilb.10; Tue, 21 Dec 2021 11:58:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G5+PkD+J48qk9v5vFxoSVH4yJ5UVfQ8tWMir/O/L8mk=; b=nq9kunY0oSWGiIF8gskpdhM+RuPMvARBEcYA6R4FcA139RVWZxaFkmXoEl6RstCQRi mpFJ2HW0QrWyAwpFMHs53VOrhVRAqz/obE20Ti+08Ce7RzL0wmpautU/8MliQccDLPct 4vXxih1/TrZYD8Bk7qhRaDo/s8jUJsGKM5hK64XMlec+2+Kbr8ao/X+UE/sOSAuFuCJG oSjd1BKSTSAFONhEHdsaRznHGMZKtxWmbgpZo7moaOYjpCe3iQYDp/vX8zoUzBngJwVU /BbWTfreiC8XZQmAwI2WJ5eJD58WNtvH3Nmo8McmVgnydiWVhLZ8iThADEvr/UsQkwGC BK+g== X-Gm-Message-State: AOAM533ln0y2tTOhd2US2f7SSACKr5oaPFnLODFBUYOo5b0xdgE+6fuP u6/MWZ595+6fKqhH0wgsprq2jnsrrSvGmIf+kDj+O6Ewa8g= X-Google-Smtp-Source: ABdhPJwG78GNQEzEt0BTncoyxMjRg4nKXNnGmSjr8UjDU7SwOJtsfkdrzF71larf+AK0Gn1V3fnoY8Z4QEW4XdxrFqU= X-Received: by 2002:a05:6e02:1528:: with SMTP id i8mr2639517ilu.312.1640116682455; Tue, 21 Dec 2021 11:58:02 -0800 (PST) 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: <5CA8FE25-F46A-4902-9FFC-266347C88021@FreeBSD.org> In-Reply-To: From: Ed Maste Date: Tue, 21 Dec 2021 14:57:27 -0500 Message-ID: Subject: Re: /stable/12 future To: Dimitry Andric Cc: Jan Beich , "freebsd-toolchain@FreeBSD.org" , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JJS1Y6Y8Jz58qx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1302 Lines: 25 On Mon, 20 Dec 2021 at 15:54, Dimitry Andric wrote: > > The obvious solution would seem to be to switch to lld as the default > linker, however that also runs into a snag. Since lld uses the blx > instruction for interworking, it prints a warning "lld uses blx > instruction, no object with architecture supporting feature detected". > > And because we link with the --fatal-warnings option, this stops> buildworld dead in its tracks. Obviously, this warning could be ignored > (by removing --fatal-warnings, or patching it out), but I think this > might result in issues when the actual binaries are run. I believe this warning is emitted in any environment that a blx instruction might be necessary, not that the instruction is actually used. >From ELF/InputFiles.cpp: // The ARM support in lld makes some use of instructions that are not available // on all ARM architectures. Namely: // - Use of BLX instruction for interworking between ARM and Thumb state. // - Use of the extended Thumb branch encoding in relocation. // - Use of the MOVT/MOVW instructions in Thumb Thunks. I wonder if we could remove the warning from ELF/Driver.cpp in the case that config->armHasBlx == false, and replace it with an error in ELF/Arch/ARM.cpp if we actually need to emit a blx instruction? From nobody Tue Dec 21 21:18:51 2021 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 BCE4B18FD0F2 for ; Tue, 21 Dec 2021 21:19:03 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4JJTpt6KVXz4svd for ; Tue, 21 Dec 2021 21:19:02 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pl1-x630.google.com with SMTP id j13so237516plx.4 for ; Tue, 21 Dec 2021 13:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UVNt3JvJQ6QeFyZER0IPGVjNa2RbNMjRRsaUNI2EHcs=; b=m1y1sN+ncgi5mzDmEVOu7tdqeeuSk6Pa4R/MeR6Iab+APr9b+9MxPUYJkMPzgxPEZ2 j0TF/REAL3DZq18+CqqpZrSNzJd2HE5UdPgtlT0c7Utgl3RBZZWFUvYKfMBhXysZhTmv pBHcQ1+IHccoFgc8ByHyxowiN/M4nMDDrfs1r5AIZb2X9AQkx1EY2mag6d1IlbArqMOJ boyaL1GlZxhpSAE8NiUpORLkZ+WMwSCIWBnIfWPnc/cgVv8kextLfHTnCrR9+eGLNWZU A8l39BrwnACUaMxwZGt/B0g6W4MUmYoFdC6qtlBiatT7zmuI4Sa7qCZFpJjxdmLzGAot MsGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UVNt3JvJQ6QeFyZER0IPGVjNa2RbNMjRRsaUNI2EHcs=; b=ZvINKTIKIjaU67oECdLEJ061E2BotPSnUkx3H05fpyKKxkpIE3fdkbF1VwEOM0eOxA UTBvtg+fY0x+vJVl2PKzExqThpLxU7stzoSlyQqh5eGr8pe9O/i//dxZMKDPbpkmNo4L Qw13xNFknKeqmFpcwVUg35yrC07nRQHxLB1AaQaV7kmlkv2CTEXhR2Df9eo/pVmT1xFL Ghx1uJGHfZngnb6qOH0G3ARyaL1VtZYtadTayXySEbWD+YKd0LKrwBinZ3pK4i/Q85no b4ydH/sCx+oCMg1mYyncgci4aaW7bWKdb3CojdYSFhf9ngi1oc7kdFJ231LRM88QjDfx 6ZHQ== X-Gm-Message-State: AOAM530p/9OK/uR+j1N31ERGMcLg6OED2ROA+fYuD6iL6A+Jmht+Aib0 teU8eyojY+6bPx7bWodRcFZpQe5YsrcxOA== X-Google-Smtp-Source: ABdhPJzbINNrV8IMSZd5iQHtIBfMOAbYO6ESNazOX27dWDDCDArA89x0trB1hv1MqMcEN4B5G4M/xA== X-Received: by 2002:a17:90b:3145:: with SMTP id ip5mr363164pjb.94.1640121535812; Tue, 21 Dec 2021 13:18:55 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id a21sm22315pfg.204.2021.12.21.13.18.54 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Dec 2021 13:18:55 -0800 (PST) Subject: Re: ld: error: bzlib.pico:147: unclosed quote To: freebsd-arm@freebsd.org References: <20211221180041.GA29679@www.zefox.net> From: MJ Message-ID: Date: Wed, 22 Dec 2021 08:18:51 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20211221180041.GA29679@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JJTpt6KVXz4svd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=m1y1sN+n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::630:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 767 Lines: 23 On 22/12/2021 5:00 am, bob prohaska wrote: > A try at buildworld on a Pi4 from sources updated this morning stoped with > > Building /usr/obj/usr/src/arm64.aarch64/lib/libelf/elf_update.o > --- lib/libbz2__L --- > ld: error: bzlib.pico:147: unclosed quote > ld: error: compress.pico:108: unclosed quote > --- lib/libcom_err__L --- > Building /usr/obj/usr/src/arm64.aarch64/lib/libcom_err/libcom_err.so.5.debug > --- lib/libbz2__L --- > ld: error: decompress.pico: section header table goes past the end of the file: e_shoff = 0xc388 > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > Anybody else seeing this? > Thanks for reading, > > bob prohaska > > > It probably helps to nominate what you're building? 13/14? Current etc? From nobody Tue Dec 21 21:50:24 2021 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 C417A190468B for ; Tue, 21 Dec 2021 21:50:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJVWM1XLmz3HST for ; Tue, 21 Dec 2021 21:50:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640123431; bh=tdbNIlYXb9P52y2s7eZv031T2Hw1WU7Ho6e8q3gKLpA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Q7pGAy5a9KQV+a0VZDRW0I4CIlR33b644onZnXAT22V8GJu66e+44xPD/SjzeROUm7Z5PrAA6mLDqi6XP4plrOw1DAXxRdDN9F38+IwyhD0BQa8xqdE7n4PXHTnbfQVhaSisX2SPFGn7wlmKz2AnQdDfS5Z3oVpkT2R3Zr8nyJthkU3qJ8pUROm3MsDbD8dUkAXP+k/cpo0oM3/uMcLlvkH/kXBc5QwTtV37ihLp2UPpQYUlgk39DUF2LYUrm9u+GUT92kW9Ypr2z1TtvD2zWQOCRK9n6zf48UYJ1Vx5043ey1a6BZuwNk9qIjYsGmGjfYSxknel24v2Z0a4wl/9Gg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640123431; bh=BItV7zfOWiIs4TY+xrTn8aVVoHy12IkvfN899+H5i/H=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oPFPLGJCRzqyhIRhCkw3od2FVXaO9R6hyWeifqNkNWTJNAj/whI88Sw/I1givO6ELf5R2t9TXMHO5toS3q9jcOsIsi1cWeVY69YO4S3afWHng/iR/c2s5iysIMm65Di0ReQ8Sql/u0qGjUsktQ7aRYuek6GgxZFfNTGPGzP77DwTdEj+Ny+di80Gh0ka9k4aWm2jgXE6bROc6J/7mZP/0Bc9ArGySmsT3N+in70wwrISLSRZP/KiCxCqU6wOZfEOu6R9C3lMw3kwsYO7g56a6ioX9OoObLTFle3UosQJno+X17wO911kSDTX/042JwtbBwbWMqddrhEHfmQdN4dlKw== X-YMail-OSG: DZspXgoVM1lP3jND21W2qbnoV_cPIOUUEvrHCW5tN0RARWuiY8DDi7xthpWZi_y q48j3izW.c9PGdJqB6z3dhydZ8uXipmVtpKYrUppbR5tWXTqEru5M6iwjTI4h.UAKUcPrNBbSLh8 RKMuh2wy70Xe8V5Nds.bCMShM4uYN0Zyo5CboZi2wXfd5L4n.GX092jRRK9R3I.nXz1dilQw7h2t IxVbrKLvTqEj9s5ZYhr908hdYUa.UgLNibG78mgWWGBZWvMMktemPRr3oZUCt8XIQuNShb.FCLSO R7kdJcVwPuBO6OdXAsmB_dzRw4OY9ZuDPOhM6vyRrTBu2MuWAp8ILXkCQHUmJ759wV7rt1M06Mso cvJcQooBKDtM8H3syhlRSu1ZEX.V4HMlEIaT0lWYjKx.pwrVM0QMFKUnxjiq8O31PvqhKunYTIpu cOIkRjdCINHJeSKVtj8cQNiIsgrA3o8W04DSgodvy6O.dmyjKnXOI4u.iEUL1I40Ts9nC1vxZUFs dijRFv3L2eDs.63Ui.Srq650ndhoFVdHB3_KxjFKsITzSOP76BPahhOlhqA3qas.NxLZKegJ9pPh FUS2VvwKT5Z.UrSdsHH.FLyviJtWFaA9EMrJSvi5cX2Yx6N2aciy3wNIIuQ5fvUriMcBHKA8Lk1l Vp9NBaaT3XcwTNZRRgE9olFtjomtFqUfXTmGEHyZr5hbn2sdSk8eWZ2BPfPn9S1Un.CrAhPOJ7fQ XK6tIDMQMnPAJoKsbNHFnn.h4scRm5s1c2ZC6mOipyGr.aWPCU_nfn8SYj_hocLN3T_RvoTZfOT6 LwV6kPl7Dh9SgKGxZdKhBdymw1MJOfFB5QBaPBnUZs24AJP.1P1ZH4UezqbHK_M7ig6fWofU0jMl 2GWGLu5im1xv7fUu5Rwj_oc7wAHaG9uspoeGMR0FttN3KXEWOO9mc4vZbVJYis2SVFy6IuIQxxV4 6hCpKOq2e9jX5kDRbLZhqcG1QRID0jH0WJkmq7bsGxFw_QFy2p1o3vlsXJ0UGvF3LiFmshvQZp1s aKciqWBHeuUNDNlrmU0Ma47fjse87Ph9FiJSACP2X8PDF0o0J3EUITjGPp1Y15Sf9fswJdNwZHMa Y4EX4_LwbQrhfGQ9ON7R9lY4EMEC4.aIzI6Zm733icfKFW1y79VygeEBOuab5XQ9foMEZk0Z3x2w YdynfYKc0zTeCCdBEzOw.4lPhdnHgtd07xKIYNkLtu2_fRqLYerdxd3186C3wRo5OF9ELmDlH9uZ 0PXBzDB2XmVjd7t.tbuboMDXxKYEW1.PDnWg3jct5WJFohZHPD6innknBDbzdXTLpwDPw66EcoPg ej61G3g9qzK2qEGTSH.VVhSto6WWO4Jr7A3jiRTyhkwGPcU4FJ4_TEvfYZLguigu1xD06jI6DPY. 7R5wHhWsG1nCR2QpUc4jH5YkzUGZjR.lO7BpTY1X8z4.zm_4uKoC2I1w0tLq432YJPIU6ZVMdqj1 vF95hEeASriFMr0jFKHGYK2CALSs9BpkSQMTI0AQKeNRpqRfUXO49EylZuwHAbbqRExgkFTCG58Q cGJ0nO6DLabuIxcyiyki5Av4VHh6srzPgCvtAaGlQRkTtnAZxlWw8RDWCCkBEsQlUzXiqqxqxCcX IP.ENv0561k1RUqRYvnre.xGWQZ0.CNvTunueE2mI9GiUik_LgX6ZtpQIyexoCQq1zFbAChPO9Y4 PXT8wt_01lRtAKOs3LJHo7gMIF3MFejfEpZQK1RyNAZ73rQby4qAavahJL9HQWGmBHjrvFQHr7sU jxi33sTfNkgFZKtxAhqx3X6Vu0HCuGqVExBWdRnwXtBQiQ2RxkfE6DuFuK3pZrEVmu1nQ7F8.60O kSvl0oQIk2lNg0R_IWrS2tIIYanA1VodCwsKAT_YULKG8bRBvEVyfH2pQQT2obyvF2nqQTuiiqeU TnsYVme8QRuZhpi0OtPfW6EGDLCyK4gcBRt_moRwZE3DikOt6uQcAdASzR79v3hm0_E0gFloYB.0 lJ.iwYn5dbH.ODMDX5uYVsiomUAH0yzbr_3cEM8xkzzfrfCJ6gxIZUD15NVXegKRWaO3FnDnswyx n2r7p.5p_45B5Gnk5oHceYAID6wqjw24q5K47XukpA0z2gSUY89_9AaBaGFeQfpm6Vp1tqIYiCx6 3iZTtOHgsHj931TvaUvWD4GvguD5VUoctwGapTouA6Ia5dQJ4MHoFzri.b5mBkeaBt0SZkEiOyAS 7apYx1ubQtykG.opc.l5h0iKM3soUJv9MCnWv23c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Dec 2021 21:50:31 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ca6109dab55c2308b1c4042a313ef54; Tue, 21 Dec 2021 21:50:27 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: ld: error: bzlib.pico:147: unclosed quote In-Reply-To: <20211221180041.GA29679@www.zefox.net> Date: Tue, 21 Dec 2021 13:50:24 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211221180041.GA29679@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JJVWM1XLmz3HST X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6772 Lines: 178 On 2021-Dec-21, at 10:00, bob prohaska wrote: > A try at buildworld on a Pi4 from sources updated this morning stoped = with >=20 > Building /usr/obj/usr/src/arm64.aarch64/lib/libelf/elf_update.o > --- lib/libbz2__L --- > ld: error: bzlib.pico:147: unclosed quote > ld: error: compress.pico:108: unclosed quote > --- lib/libcom_err__L --- > Building = /usr/obj/usr/src/arm64.aarch64/lib/libcom_err/libcom_err.so.5.debug > --- lib/libbz2__L --- > ld: error: decompress.pico: section header table goes past the end of = the file: e_shoff =3D 0xc388 > cc: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > Anybody else seeing this? Providing the following sort of context information could help folks in figuring out if it appropriate to reply (examples are just from my context): 1) What vintage is doing the buildworld buildkernel activity? # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 = main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 That can give an idea what range over which something might have changed that contributes to the problem. Otherwise there would be more to report about this end of the range. (Imagine if te world and the kernel did not match, for example.) 2) What specific commit from "this morning"? (I've not actually updated in that time so my example below shows the same commit as above.) # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ branch: main merge-base: 22c4ab6cb015dc99eb82504e5fd957662cded3c3 merge-base: CommitDate: 2021-12-07 19:29:26 +0000 22c4ab6cb015 (HEAD -> main, freebsd/main, freebsd/HEAD) sys/_bitset.h: = Fix fall-out from commit 5e04571cf3c n251456 (--first-parent --count for merge-base) That gives the other end of the range. For reference for the report from the git area: # more ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ #! /bin/sh branch=3D"`git $* branch --show-current`" \ && echo "branch: $branch" \ && base=3D"`git $* merge-base freebsd/$branch HEAD`" \ && git $* log --oneline --no-color $base..HEAD \ && base_date=3D"`TZ=3DUTC git $* log --format=3Dfuller --date=3Diso-local = --no-color $base^..$base | grep CommitDate:`" \ && echo "merge-base: $base" \ && echo "merge-base: $base_date" \ && git $* log --oneline --no-color $base^..$base \ && echo "n`git $* rev-list --first-parent --count $base` (--first-parent = --count for merge-base)" (I'm not doing my own commits or using my own branches and the above procedure is depending on that.) I've not been updating/building recently so I've no direct comments about that. But there may be evidence around that you could report. The messages: QUOTE ld: error: bzlib.pico:147: unclosed quote ld: error: compress.pico:108: unclosed quote END QUOTE read like binary files are being read as text files. My existing (META_MODE) build has a .meta file that reports, for example, # head = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libbz= 2/bzlib.pico.meta # Meta data file = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libbz= 2/bzlib.pico.meta CMD cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch= 64/tmp = -B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr= /bin -fpic -DPIC -O2 -pipe -fno-common -I/usr/main-src/contrib/bzip2 = -DNDEBUG -g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-length = -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -mcpu=3Dcortex-a72 -Qunused-arguments = -c /usr/main-src/contrib/bzip2/bzlib.c -o bzlib.pico CMD=20 CWD = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libbz= 2 TARGET bzlib.pico -- command output -- -- filemon acquired metadata -- # filemon version 5 # Target pid 82738 If there was an error, it should also be recorded in the .meta file that had the command that got the error. (head might not report enough text in such a case?) If you use META_MODE builds, looking at *.meta files involved in the generation if the files being used and in the command(s) using those files might point in some direction for what is going on. You might want to report those. In my context the reference to bzlib.pico are (I added blank lines for readability): # cd = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libbz= 2/ # grep bzlib.pico *.meta bzlib.pico.meta:# Meta data file = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libbz= 2/bzlib.pico.meta bzlib.pico.meta:CMD cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch= 64/tmp = -B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr= /bin -fpic -DPIC -O2 -pipe -fno-common -I/usr/main-src/contrib/bzip2 = -DNDEBUG -g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-length = -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -mcpu=3Dcortex-a72 -Qunused-arguments = -c /usr/main-src/contrib/bzip2/bzlib.c -o bzlib.pico bzlib.pico.meta:TARGET bzlib.pico bzlib.pico.meta:M 83530 'bzlib-c42071da.pico.tmp' 'bzlib.pico' libbz2.so.4.full.meta:CMD cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch= 64/tmp = -B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr= /bin -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libbz2.so.4.full -Wl,-soname,libbz2.so.4 = bzlib.pico blocksort.pico compress.pico crctable.pico decompress.pico = huffman.pico randtable.pico=20 libbz2.so.4.full.meta:R 81954 bzlib.pico That gives an idea what *.meta files to look at for bzlib.pico generation and usage. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 21 22:07:05 2021 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 447451907385 for ; Tue, 21 Dec 2021 22:07:01 +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 4JJVtD6ym0z3Kkh for ; Tue, 21 Dec 2021 22:07:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BLM76xA030487 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 14:07:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BLM76Mw030486; Tue, 21 Dec 2021 14:07:06 -0800 (PST) (envelope-from fbsd) Date: Tue, 21 Dec 2021 14:07:05 -0800 From: bob prohaska To: MJ Cc: freebsd-arm@freebsd.org Subject: Re: ld: error: bzlib.pico:147: unclosed quote Message-ID: <20211221220705.GA30154@www.zefox.net> References: <20211221180041.GA29679@www.zefox.net> 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: 4JJVtD6ym0z3Kkh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 226 Lines: 11 On Wed, Dec 22, 2021 at 08:18:51AM +1100, MJ wrote: > > On 22/12/2021 5:00 am, bob prohaska wrote: > > > It probably helps to nominate what you're building? 13/14? Current etc? Oops, sorry. It's -current. bob prohaska > From nobody Wed Dec 22 01:28:09 2021 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 7EA9318F6323 for ; Wed, 22 Dec 2021 01:28:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJbLc1lmTz4cm0 for ; Wed, 22 Dec 2021 01:28:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640136496; bh=5rXo8qLJOB62AyAo+bo8LcXEv+Nx+TdYuC6PF8M2AoQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kAa2m9+LGwUaTmcYyOQrx068XiXE6T29dagrxxM0XrQWFf2MUogW3633G5YlQw8GAFes5a8/YTmsgk5QDo9nlOyht2gco48lx7ASVrGC/Y00Wv9Raon0rYK8t3xNkTm88S9xkpGbUQh23J/Ad47CKhLK0LPz9OS44uGSXwFahqMCL104cV+l08Hv1ih7rbsQnjH1pspArMcTSg7NBrqkGeCuq+129Fv+gi6LhE5wrLswGswi9gFyHxV4jjgbbK8YjMPb06BfJ7S0Yd6+m/lzw0I0fqcWBfK8dNwpUA2z3fvezjDWFZcy9K0Uvm/ENJtYvpjoxLSr2e0EHJiFhauMEw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640136496; bh=5zZ/ky5vcWsUgru0X1wpP9Ghb2cgJ4O1Pmqcj7cj1xo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bJhXIBo7xiB3SY2u5I9pC0OOEwlxOPmP6wvC5cfJ+tH7aBz/qiWdT4+gldZBDcwfqstB5lQGW1hLZNuYWJS1NS9L4bdN7s1FFTCOisMbD3R3a31c55oTX9kHag2OXvdWNgUEW0QJhsokIChyxai+11jVpsimVMn88+4mme2x0UhRycX2GAbeA9R4CkKdEqeFS5f7TA1o8aYeYjVwRGU2tAKKhFnL/cbWdKJbpCTXwuJmQ5aiOlA0kqD1SS8YBWMZKTCxO5ZMtXLYoafUuJVgitnkpVw6HVuPXXvOOchSBAjgU3uO+jHuabVSDxOu/cuX8eH60+zra0MOTY/eVyVirQ== X-YMail-OSG: _KhzMT0VM1kWM8b56AUWT5VAjunHNAPh4rA0zQEs0oDi9.wKvn62nlpvN2t5Ibn SvzDwk_MyxDj9J6ekRIaor__gXSrBO7l0FtjE62XmPMy4.C1tgm4uL0M2WpSUMTqKi9AVEsRgFZS 80udQomesg7fx7n9F7.4gBqoZvLfzP1VXaR7BoOUHpxZQPNZWhftHwj8WSqv_sKmj0rBft17Z.jg nXBWmDGpM0_5ccnlQbzjpRvDCTltYEoIG3_L.LEZD7jBFmQHu.WW_xr3J9bw9hk15Y5zpE5Ay1pg ySidKfNl7tLkzKSJcco9VbrwvnSOby88WSBz9_duHAIegHZQw78XCVR6sPvDIOoktpRkKk6eM_lg H1MuTW4WCjtpwtCEqj3lHQHSgS0t5pkBnboZ.XpsH1wiHm2f3OYbbtWJSMo3Y5PwAI_Yh8c3j9d1 rM0kMnbdwC26GQ7rlEuQBIfBLm1SdJJCJCwI8BX1S1BmwjVyA2hE7v4SnQDA8nHpIITPIIuSEMmw AVde0TqVAQuC5fQPzu29pkIQVBn551GE20Qv5a67hCVbq3LnZs0Wo9yVVsUR63CgFkoU0oWww70p ZRuhcPu0lsk7v2PZeOLBgsoUr8q5d1z9Li2kRS3dygn0RNSbfni2ktxqa1o26zdzifjEDVEvU9eK MQEFgq5O0vGhQc6F9F1S.AGFQ6GezzA5aT5iUU._oQOvp07_8sVsUK4VdfuPx98PZt75KI.uBdVb cKkYHKO8_JP.biuenG7LLkD1k6JE8EuBZWfNm5saq5Ga9sTVZLTFMj0OE7NU.jJcujWALAJRaj6A xl5IcezWsCiEFFu.CQ9YGtmnIWh.z8FCgWRB0OSgc6RS0LlPA_wuSdvaL7fV5Px1mGpvp9YTIxlM 1KiYLMZ8HH98aVUkGj90wEwPK65JypprQVfFi0SgJmmgnptNnkIyRenZk2Mx1mVds77eehur2WhQ PPhT30RUVMftrj_5UlCr6p1T0xyIyNVf65RGhCcjkLeawTrH3bAGI7ruNqfdWaru0NldQMVbMC.T hu5mTGqxK2R1c2qQL1HhT2SOqtUfpaxSs0yh3ZGIlJKB6VxYxqi820xkNcILA0c9BzKIGsKgH3RF Faor1S1O._PZEMwnTocR1rpO7pI4ZnqYKwYSdzl_V_f.ihMkXlK0Ksl2Tb26pnKy7H7b8XZC9W_1 R8NavXRgLUmJhVm6ldToSUPnqnT1LM948u.gjHIjUE5voMWjCfTlCEHhlEMr7be07Hh3Q4vCgPHk bgvVkrhgUz5eEjy2ShOvA6fmEljRuB1hVuXi1UrpfKLo7bTlGZA9piKs8H1vT1krHvJUZywm4LW4 sQGlbbYNOS4_qJOZb0F0WQkocrO8ikUrZrxAtSUAGV3uVS9Su__HuHdG7M1yFvHxl3a8XNmVAYWS fDC3gR5jcWJPUDCqKD2HZ4aFX28wvWAA6Ro4hPvI_Ekq8oVSmmMNJQxh8_l46SjvkMf6tNoJ5xi2 SVQzzjm5tp3G6AOWvZLBsswZgerYYEqyEW_uyRWKMnj0dIs0l98vWQYi74soknSJ9V42_jQRUVml clOjra5A4NYBip0haLcaubk1XUcgKj0dMi7PApWj1Qlcbeorjyr6lAUyAzH32uHxJo2qGTMzY9FZ nmaGaZh3klnJpUYmiV1ZDJ.85.MQYKwtYkl2WE2xYhnpk52aiLfLDGtnMtN5qlD9o8RxoZtPUAu6 WYe0Saf55hUDJzStDkJDztTdxizmVHtqT6t0DAAMVcGdx5PqITTK7PjOMCQUivT2HF_9Eax1CWDm Xbilnx0l3DZl7Ql0uuovSByK8P9jBRMXObh6JfHh.jgI1HNcOjG0AvODW3Ko6G_SGqq7zIziKp_h 46ZzmR5AS3wA61DrkUwyACXrm3TOVqib21mlRwaKVK67fOZwRaB7R0I3GQkjdcKqA3MLi_fpgwIF BJ5gk8u5MFXfcPlDlaQXove.PqsirFJ2UF5sK_UJDqABkRKl3YiTvrFSViNQvMMesgUEgqjQcM85 SyOdLfIiUX8q0bqufVCR9BM4MaFne3PwB.vhll8Vz_YwKdEo_yg1DtI3qcGPAZuzsQAgg8tNe.Lm 3WDsooTkvT419DXtuXYFNu7nkMKNNdIXRpWL5OqAld7e8_Yie7Vke80kKn0oppOBEBT..rdqqyxD .vCZ77E25KZ6KVPtDGF2Oy6vwgm0kl9k1dG8Gbxtd_QF6FwhIvorgZ95x0g.phixMY2Fc_oDuGD_ mHJr0q8oLk5K3tU3WvfZz6QgZEfR1NTHoIZx0gAeOqA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Dec 2021 01:28:16 +0000 Received: by kubenode523.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 872c164120a78ecf5abc8be588cb9985; Wed, 22 Dec 2021 01:28:11 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: ld: error: bzlib.pico:147: unclosed quote In-Reply-To: <20211221180041.GA29679@www.zefox.net> Date: Tue, 21 Dec 2021 17:28:09 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> References: <20211221180041.GA29679@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JJbLc1lmTz4cm0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1976 Lines: 67 On 2021-Dec-21, at 10:00, bob prohaska wrote: > A try at buildworld on a Pi4 from sources updated this morning stoped = with >=20 > Building /usr/obj/usr/src/arm64.aarch64/lib/libelf/elf_update.o > --- lib/libbz2__L --- > ld: error: bzlib.pico:147: unclosed quote > ld: error: compress.pico:108: unclosed quote > --- lib/libcom_err__L --- > Building = /usr/obj/usr/src/arm64.aarch64/lib/libcom_err/libcom_err.so.5.debug > --- lib/libbz2__L --- > ld: error: decompress.pico: section header table goes past the end of = the file: e_shoff =3D 0xc388 > cc: error: linker command failed with exit code 1 (use -v to see = invocation) Going in a different direction in this note: The "unclosed quote" messages seem to be from: contrib/llvm-project/lld/ELF/ScriptLexer.cpp in its: // Split S into linker script tokens. void ScriptLexer::tokenize(MemoryBufferRef mb) { std::vector vec; mbs.push_back(mb); StringRef s =3D mb.getBuffer(); StringRef begin =3D s; =20 for (;;) { s =3D skipSpace(s); if (s.empty()) break; // Quoted token. Note that double-quote characters are parts of a = token // because, in a glob match context, only unquoted tokens are = interpreted // as glob patterns. Double-quoted tokens are literal patterns in = that // context. if (s.startswith("\"")) { size_t e =3D s.find("\"", 1); if (e =3D=3D StringRef::npos) { StringRef filename =3D mb.getBufferIdentifier(); size_t lineno =3D begin.substr(0, s.data() - = begin.data()).count('\n'); error(filename + ":" + Twine(lineno + 1) + ": unclosed quote"); return; } . . . code. That code suggests that bzlib.pico and compress.pico were being treated as linker scripts for some reason. (I've no clue why at this point.) Seeing some parts of the content of the related *.meta files might give a clue why, if you were using META_MODE. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 22 01:51:59 2021 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 1D94D18FA8E6 for ; Wed, 22 Dec 2021 01:52:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJbt46fj1z4fVt for ; Wed, 22 Dec 2021 01:52:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640138012; bh=JUTQmG7OjAg7nvlHPnX20R2cKuBpJM3bWDOyYtt2x8E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=h3KJlQfqDY8VG443MXEsV7vURDdW0C/LU729fhBurc+W7Js+JIIjAm+RpU0GT2vu2nrMXfkJtVPyHcVUqSwa+LNIwwITjK87Ot0Kdg+aQbe53rPIS7TEHh9zoggaRo9POSIyihkvyqzFFTyMaZtLkThnHCJVUumzkI+FJoNCUYuQPHrqM7R9N436K711fH5Jrr3gC1pfFtJhF+KVceGu19ZFi5LcJx/zTDqX1niW5IqnhRTpGivmYHqrduxNgNc5J1gvow1OXNhIbXTgd1UZzufz6gXWDBiTmPvWXPQKuz3ZLysEDPDwYX5+XT8aGq36zAA5k7W7fAIb/7EJcsw/dg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640138012; bh=xY33biCzMhy6A1ejtXk37FKgOaZUPLpcAzwPPnzH2Xp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gFLAGeHbCAxboeZQ/I2LDsK9Y6lB2iG63ZetCeyUiQRfQlgos1GUar2kfklsa4T9ALdBd2W6YF9D48uMRXGkO+ztbUuYGRNRK3a7sWeoJAbKUCndrjPYenbs6+krYtlV6pMxOZ8HIQC9dTpVkvOnato4CgXaM4qtdgd2zIQqi5um5zFFpOi7GmdsbvNB2e9QxkDLvo+Y9RhQP0vSCbs4bwEF2TW8m8/Zp4dMUXrtvYLshh+ec5gKDHj5ZFOv2Hf+i0eClUmRXfCjKIhcAZEHTcNjj1LOfKgQLnEArzroOMpC87cKeTgGdFXA6uteJpnkMcXVs/XDiHymhGZj8uKBJA== X-YMail-OSG: 7JThg3QVM1mNyTJ37Puw2YECT8upUVxU0sBkOuKO99qivRO4LC.B9rmrSUJi.Xu O4wB.ZAcT5J0Ln5T8zvawVzPl7OYaYABdQf1gzl0f2w4shiiKoRta7sTdejWhv2ZTS4A31QyG5yw 4Wn92XsFVb0IVhpDO_giH_WQvmXMo8ojGpKIGtTMef0v.N5Zgx1mKT6sdT2fncWi1yML.9MdkZWf w1xX8XhTjwfF7KgcVCneCux.ckSY0X.9ZtR_9JABSe9Axjn_HPRhoHMzAYeNyAtDRuE2oFdR_dLl K_XEs18UVQMvcI4vnhks8fZ63e9acCRmrTTMpnePWnvdXj4EryJfMm0M1RYD.5N3NV61MT0BJD0U GfTNieHLCIi6e2Xj50BsmW0iMJZyqSRWdvXDMhgI2qknE6eEMw8EIGZtA0xqJSpNq.PikcWcMhAv 9p38tPxv6.tOmUAz0jLNJnobOy9Ag_37pstP0J593irLG6WL8AVJyGM2XMObnYkY7qmGFjOk7TY8 f6ojHQNxyOGgGHz1sdF78fzwCnctsqlehPjlji309n5H3hwne9hdR5u4_PiVreMCnU0LTN1bobGg stwHnJslMsn6dERiTSRdyYp2c2Na.wg0zh_VmjOr39zqTyd7Q3vGllY8LqHD9g3HqdB2w31CMODp pMXNBqrnthALZgVXQfWk1FuI0iuJFxMkuRvqViEyLm8PXNPdX2JHLNOPYf_MrtdKOljEBTpcHwRm bY7BwefMX85Ux_.eFgwazqgW8zGpBZm1WGCEOG8Y9LqMPrMAWbRSekkGrqVcDItEb6tigWgSNxng wVwyP3zVXIa_U9P_mF1eGLwS_mVzRsKKrBS_As5izgdWa5qs7QjNmZSxHj.jn5.P7oWsc4zESR6w 7zb2Hbh21.nkKBuVgVLEOIkCbyyJ5UGWcUWGQDuDsVzSbrUudzVBzjMSALZC_gSurHvHTiHfv8EI .ZiZGCh39xOK4nAHcc5nPwMCn99g5lAS2uRwq3U1uS0NRmIJKcY3Eb3i2TGfDjN14zmq2bGmM.Cz e7knHimkV7MjdrJJkGOwlMADcI2YTbg09pHttvvqjuQ.Nqz2AUzO4PxXPf_HHLxN_2xCHejoo90W JffKna6u_caqzazTFW20ZbxO1n6swMwom6L5qk05Pg20sd0rqz29CI_WpEq8ax9FL_CIuovNcKW4 6yu13itsUg94loKQrKTKyFbgSnqTEEHS14Z6gEcLV.nbmYQK94l1E5_kBe7NoL1s5L6Allomtc2w c1dmUADmuH8aRM.38Mf.5aeyNQ6nqWZY88MJY0ZL3motGbDBb.cpfFYERsjESleiL4mzTOQTboas yZD9t3ar27LMApOsQl3dZjy1bjXnc1OdB1Ce3NDrtZzxfdv2dLu5NVjaMEEfeoQAWqjponOHzCqm 3Wmsdnwzu.uvUSMaMd4lo.lnCuqO8u1.39Ao_YHyM10jCjIpl2GjoRrdd8BorC.UIlNmWgBfYikd GgD34ax.jNO3bcd3487XsbfyBRqihH_dmsRiA.WldUx5D8N1UhDrENHI9NgbSH4JBP1sm4sb_fBa eFbXnYnaxokOns.q918V2BwV47FohFId9j2PVJbhoNBQ1W6yUInOH193Kwx0Ab3vEXlHNPMRt_qO bi_pkB0lck8Ww6zQOP7nhtXsEM3oaZOdzykqND9lRkyy6YW5mZ4nzXdL4h1D1CwQCYjdpp6R34yf BpOqmCNCBD7dL0jrgDq2wCvopbgAIaIaKZMsH3K.bDc_6yRt8Jg0iUEUDmC1Jp1Qo_TEjrofJDeO RITFMMC.AKb7vey796PGhhmE_bC2CZhO.HRhFR9WhmO4DeTdhGArRIeIjHPg9Wrl91ov3TNjGUBh CXYo05Fka451NqKg6vHMRod4dPH.s4t7yssJI6AeNUVopamscgfsAygnlKy6W7ERmWfUFl8xjQCl 3qggf5bSCdwwdWg00fRWGcdyEYhda6jvYDh2K6857hbAA7tquOdpM2.tzOfwYjC27nm5.Qiayq.F uC1m7Qf1Us9mnutBaUU2LxrIT29b4qMZkWT5UcGpcdhaoGOByFTJqVhlsWmg99BkWpWBjFrRL8qe SNrsYBD993HaEngp65tOTQwr6qJQvu6vLzNwopls9Ty0v_vdjSgxfpNsUp3_eGs0hyAJSQ5f._p7 bL2DKEMNR39dz8f8if1wqUBLdTS_.aHX6qjaoOgzQlUIXQefZ8vyNOdmJg4heS4aMasnQcwgA82x LkGNzeCRncVTOsRIPRfLbg3IQDELL63W1w0KYa6UaH3j4yQnR8IIzFJH112u_9JHdk5zpNT6DvlJ YeOAbkTyuzYbOdzLbuLtTgYrfChnitAXrkX.Uez2bi_3.24uT8HASXun0xHIsSafG X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Dec 2021 01:53:32 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bc3e2395a0f5043b5be1a265a09c62b9; Wed, 22 Dec 2021 01:52:01 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: ld: error: bzlib.pico:147: unclosed quote In-Reply-To: <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> Date: Tue, 21 Dec 2021 17:51:59 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@yahoo.com> References: <20211221180041.GA29679@www.zefox.net> <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JJbt46fj1z4fVt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=h3KJlQfq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2381 Lines: 80 On 2021-Dec-21, at 17:28, Mark Millard wrote: > On 2021-Dec-21, at 10:00, bob prohaska wrote: >=20 >> A try at buildworld on a Pi4 from sources updated this morning stoped = with >>=20 >> Building /usr/obj/usr/src/arm64.aarch64/lib/libelf/elf_update.o >> --- lib/libbz2__L --- >> ld: error: bzlib.pico:147: unclosed quote >> ld: error: compress.pico:108: unclosed quote >> --- lib/libcom_err__L --- >> Building = /usr/obj/usr/src/arm64.aarch64/lib/libcom_err/libcom_err.so.5.debug >> --- lib/libbz2__L --- >> ld: error: decompress.pico: section header table goes past the end of = the file: e_shoff =3D 0xc388 >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > Going in a different direction in this note: The > "unclosed quote" messages seem to be from: >=20 > contrib/llvm-project/lld/ELF/ScriptLexer.cpp >=20 > in its: >=20 > // Split S into linker script tokens. > void ScriptLexer::tokenize(MemoryBufferRef mb) { > std::vector vec; > mbs.push_back(mb); > StringRef s =3D mb.getBuffer(); > StringRef begin =3D s; >=20 > for (;;) { > s =3D skipSpace(s); > if (s.empty()) > break; >=20 > // Quoted token. Note that double-quote characters are parts of a = token > // because, in a glob match context, only unquoted tokens are = interpreted > // as glob patterns. Double-quoted tokens are literal patterns in = that > // context. > if (s.startswith("\"")) { > size_t e =3D s.find("\"", 1); > if (e =3D=3D StringRef::npos) { > StringRef filename =3D mb.getBufferIdentifier(); > size_t lineno =3D begin.substr(0, s.data() - = begin.data()).count('\n'); > error(filename + ":" + Twine(lineno + 1) + ": unclosed quote"); > return; > } > . . . >=20 > code. That code suggests that bzlib.pico and compress.pico were > being treated as linker scripts for some reason. (I've no clue > why at this point.) >=20 > Seeing some parts of the content of the related *.meta files > might give a clue why, if you were using META_MODE. >=20 I'll also note that: https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/ shows the most recent failed build as happening a little under 6 days ago and lots of builds since then, including 10 or so builds each, both today and yesterday. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 22 04:03:34 2021 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 1F64E190D8B6 for ; Wed, 22 Dec 2021 04:03:36 +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 4JJfng5cyQz4r9k for ; Wed, 22 Dec 2021 04:03:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BM43eKo031445 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 20:03:41 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BM43YTS031444; Tue, 21 Dec 2021 20:03:34 -0800 (PST) (envelope-from fbsd) Date: Tue, 21 Dec 2021 20:03:34 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: ld: error: bzlib.pico:147: unclosed quote Message-ID: <20211222040334.GB30154@www.zefox.net> References: <20211221180041.GA29679@www.zefox.net> <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@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: <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@yahoo.com> X-Rspamd-Queue-Id: 4JJfng5cyQz4r9k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 895 Lines: 33 On Tue, Dec 21, 2021 at 05:51:59PM -0800, Mark Millard wrote: > > I'll also note that: > > https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/ > > shows the most recent failed build as happening a little > under 6 days ago and lots of builds since then, including > 10 or so builds each, both today and yesterday. > It looks like a simple make cleandir has (so far) brought things back to normal. Buildworld is past where it stopped before but isn't done yet... I'm afraid this mishap was self-inflicted. Tried this disk on the Pi3 that was having trouble enumerating USB disks. The experiment was a decisive failure. Returning the disk to the Pi4 and rebooting it revealed what looked like file system corruption. Single user and fsck brought it back up, but buildworld reported the error in the title. Thanks for responding, and my apologies for the noise! bob prohaska , From nobody Wed Dec 22 04:14:58 2021 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 9EE9E190FC13 for ; Wed, 22 Dec 2021 04:15:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJg342V01z4sSK for ; Wed, 22 Dec 2021 04:15:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640146504; bh=UTLSv7we579dsxuORnQv68kx26A//n4LwQ+9eRqeNbk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VsbiYs+TcynLMBnL3YbhkOCNiVJgPDNUyBsGknou1iZrJBxKUyCcfRnn5lFxjlCnAtu5LrW8sJyhx0w1sabkcj/s/4kgQgM2ys1jKZiM8OMhxFdtBXOyGeJkCULsfsJEsNAfDq8wizTQerWMU1wxIlCvijpGTzyvYIL22Q+lP1dNBDyjLJxN1xOuAWlw/lYvSU/gXzPh624L8R6cN6o6u0tXjnAJ54WGS5rBkutUqdt+sqaqgH0SeRVFGMHKcZhHU7vCnJ4UBFzg4cZYCweX+6TdxR1pjKNVYjlDT3e7BWxY3NhM6xbtbieoL1umQIK1G8dXXeMKwtJHJu1N3nSIxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640146504; bh=ban7exfhbLhWw4THW0tS5ipuFHYFqaHa71GPPqpa7O2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rdxJhinORVP3bgO0GWHzGgstQS6KoCjU00QHc8py3a/OPnm8YF7KG1PcMbkVx7t6mm3AOYYke88h+v5ZsKr4D6UJaB3YGHyl3xhIPFETWc0+/CUq0Xvh1oawP9u4YxrnRgZm9GBEjEWEgoi/j7/jtwHkDnKNG8s6bp/4TOR2/zG3ZLnoA3v0NcRWTyFqnANavYczyaj/118r6QeaGikUY/pC4zoT584H6KqtDRauHXNgOdMvkhw9XVMNvLwDRbGqLkzCeb1bnWPGcMhENQEZGdiX5RP8lu+xiqO3rTrSBkMfVePKCPKQhYHj4ApL2MwBGUgyXySvf0CXxLaMhu7oPA== X-YMail-OSG: gX0wH38VM1kOGNbe9qArDPiz30ZZnad7EAHPYTQ5QzYxLn9SSxtNhwcKxLRTbY3 jvMSqHguvznae7YusA7NAJ22TmFbf0hOtccbENFJ.yNRrJSV3VWUCT9eGopQjBnTX7bXM.qcQf7t pvL0hoQIrElt_snME8lNLQ9BGHzZQHw6.p7G9iZuQ22vxcxg6G5s9rVGAx7jEbkUElGG.rcyXS1G 7kQMVw.HQAXrFdbTPFc3Rouv_DCQ54gs6gkhSkX3fnTAd79W_F6HHE00eK8SZyJ0xuAGFiCFKXp8 IaC10dWtbDNepjCwueohkmq9qrxZmPTg.4QHF0h7GwXblCyhAkJZ4caKw4KTV.vaPjzd6OHNTPcr aD3I.t.JvgqrdH6Xnag.TJTK_5IHkM7RbGefGIXL2L9Kkoq1BcKI.4ZTboiIW6rF73OXDh0mfuf2 Ha_wmT8vheROAH4CJB2umPOhOKMa3ZQdPFSCtXfn1zly_k9nJT54_RBc6KauoBIju5C9NH4RNouo dqo6L_QYiEs2Tk9ZA9lMXeChG85EfC.oJjDRlN7BsGeInT0OgFKI0jEDAE2yXcLCQEihZKXaIRIn LaqLEs0iR_jDUMV1q1kJgDhgMGSxjgu5NDGnqZAfpG8MRnQLAerLLSFI.RHUVCfha9Qv79JoNjjB sO2YxtH1Kxuri5jYhDFKCFcCJ6iG4x1B7iosGBDtZuPp6pcslRh8YARop8Dlp8qs.sTK9bziZzxS XAOQy3UI2Wvhyh_ofr2ReYLcWw1fr0ywTBwWON5qS1.rNOyPST8C_Y80n1zqJkfskLLhjjBMlWK. L3ISTKc._uGj3KyoqmLMA.e2C8Ig9uc_yI4gCyOrrZP761LLEPvRmvHspOMKTTiBgOKihEJEZbnN Ij05pTp6_KtXfrnSJwgLtMO81a2K2JJDJt2uWuRaniKw8R_WoZPZu8Or7j_ApEsiI6zMjDq88PDk Y8N3aUTlHNzJulHHE1vQZlgSUMmN5dtdpEmZQTtIEoEND3bjjU6Oy6OzPr5olgUWqoNcCrDBT8v0 Q9sBVKix32vveyetKu_f4iXfZumzuRQHt2v95pf3HpGHDRauNKpnkOLj26UQxH6b_DzzVJEiz.7m HXgqZ3YD24qr6AGMh2VQuKvaIVF6N_o7exL26mWn7AvJhH3z46OmzZHDQ18PEtCWibAxYtki8br5 ZQ3OtvKknkIbW7BKdl69aXVQXVSBsWXZImxLuiGPuWW7LUQ1pFXO37WxxAFYBZ9NNy.HBWgijVh4 68hjRGQ7xA1r3DDUDY.6_c2ICeB0.2tQIIJe.Ck_UxK8X_MVYBK.ynmd4BT9FeDGJpTmv54jP4rw ROLxAD0YGMR.0U1R10CSMZLdovXU6.Qm0Ee52T06THH.SRpC3TZACX7ZwIJ2gPL0j9VQTnpOfua1 7kZIV0nSvcB4XTuKAeNF8Fbbp.BFhc.zDBDjUeKqcmfsGmWxLXcVaGiXFNZNpudhAtXEGrPqN8vq klElCBRKnu_lV3y2x.IIcH51rnUAMyIBuFePaHfWorCgSJ5qMF9VWUJT6DlkuqUqX5Yo14c24UWI thGy.xChNbwyaoSGMyBT2S_aq2tMmyVXUevNqULs3zSyMkCIENJ3AgEnEwZTzq3iwa0ctNg7SjyV RisHjY4f7KYoZytDQGUKFV0CNBdKb2isii_wSswC4nghfJjZ89wWdle3DrHl6MjbUy.0e9gvG.zc Nc3JPL6kbDhPuRefM6lT12o3i5Dl6LK6e_PYyEUFKF2DKDv7aV92WVr6EiMlRs3r5CGeHW1OHneh hW7PmhXq_CH5yUBlV3yGzNkJGiMqdLh9AOshYwFrtfg2Yb45vhlUkDe6Ww.Xt6lmu8oKRdAe1D_M ljl74afa0FANM5dzoKxYcAfJ7xqggL7EB1lPKzUmA6dGxLprCyQ9Y4tNF5IKHh5V1aMhxZj_Va2F z88C4qdVHUBHoskz.CnK_kJNYq1iL_WcGWGPoxqdkVpgTfc8UeEY3RCOLfevYzfWF2qNxbUEHp2T XNjhrg6_wN6I41rRypqF6199qvE4QpDWAVKdglJGdr4l8CC4u8FUVybrzsyq1bkVKnkIJtW95YDZ JyGwB.rVSz7d0E8RrNJp9.Z0C9YQ72yj06W4_lWHCzGPg1GSMwe8WDOUvPMZ2dNGN1SePWUnbcVJ oE57ZruPGHl28iKmniRzzH.dySJt9ghGfltk8BKzB5YhloIEyZtHwYdOF_g9iD00pp7sTV.3FacT B6TQepRj62A712SAVCiK6zoaMEO2naF7p63_5RXkPYq27s5X7He.QZSaYMavGn.ai9jOKE7_.C2X 2KZH6BprDpqng X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Dec 2021 04:15:04 +0000 Received: by kubenode502.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5186c0696e3c49cb18196bf3d6b835ea; Wed, 22 Dec 2021 04:15:01 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: ld: error: bzlib.pico:147: unclosed quote In-Reply-To: <20211222040334.GB30154@www.zefox.net> Date: Tue, 21 Dec 2021 20:14:58 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <17ED22E1-E08E-47FF-85A7-16DA8303C8A3@yahoo.com> References: <20211221180041.GA29679@www.zefox.net> <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@yahoo.com> <20211222040334.GB30154@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JJg342V01z4sSK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1317 Lines: 39 On 2021-Dec-21, at 20:03, bob prohaska wrote: > On Tue, Dec 21, 2021 at 05:51:59PM -0800, Mark Millard wrote: >> >> I'll also note that: >> >> https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/ >> >> shows the most recent failed build as happening a little >> under 6 days ago and lots of builds since then, including >> 10 or so builds each, both today and yesterday. >> > > It looks like a simple make cleandir has (so far) brought > things back to normal. Buildworld is past where it stopped > before but isn't done yet... > > > I'm afraid this mishap was self-inflicted. Tried this disk > on the Pi3 that was having trouble enumerating USB disks. > The experiment was a decisive failure. Returning the disk > to the Pi4 and rebooting it revealed what looked like file > system corruption. Single user and fsck brought it back up, > but buildworld reported the error in the title. > > Thanks for responding, and my apologies for the noise! Not noise? Which adapter was in use during the corruption? Does this mean that you have showed 2 disks to have issues using the same adapter on the same RPi3* (but with different firmware/U-Boot/Loader/kernel/World's on the 2 disks)? Whatever the details, such would be good information to know. === Mark Millard marklmi at yahoo.com From nobody Wed Dec 22 11:33:52 2021 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 026F818FB6C8 for ; Wed, 22 Dec 2021 11:33:53 +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 4JJrnD5Zpjz3j4y for ; Wed, 22 Dec 2021 11:33:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 A055C1C0F5 for ; Wed, 22 Dec 2021 11:33:52 +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 1BMBXqe2009821 for ; Wed, 22 Dec 2021 11:33:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BMBXqR4009820 for freebsd-arm@FreeBSD.org; Wed, 22 Dec 2021 11:33:52 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 239673] Spurious Interrupt message from /dev/led/led1 Date: Wed, 22 Dec 2021 11:33:52 +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: 12.0-STABLE X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: phk@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: mfc-stable12? mfc-stable11? 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640172832; 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=ZFECVvc1sfbOvotyKupU4D0+fjuZU5ggVywlHyqwkt8=; b=V7v0qXBMMcRsTEKVLO8F+flukbNqnLVgsAXMC8nNAv5ar1PyAOs2y4JyRXDq4zWGHNTIW3 f8tIaqQr3/I1vmj0ZLYEjCvLcB+gYbV/3OjkjbpYFZk7zGUx+NJvQTbyqCMsHjFdxIjaK3 wn+kt4fmJgjkCuLoIRwHESTk6GAkBKGSmwgtVy2qXE+tzEt61GSk5NCOYAo49IhtyCPZxz paeM18VFSYb3I07pK9OsnNufYhRC3I6nVK651nk6VIoE6YhA0aJVTZ/uTpY7s2mdAOzKwE UUKThKV8cokHg0Ecg2Jl26R2knCQJP06baCv4eu/uMPwHGifGn41haGvF6W4Pw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640172832; a=rsa-sha256; cv=none; b=dcLPXCazAFBZut++89bikgYpj+t/1ZqYykwrobMbCIUQPOLX6CuKR9lKTKUMb4e0jWk89T ul70BynmFKIKyje2Pf7IXLsxwvzCp93rmhf/50/og1DbOBFxk3g7oWFbqfxiKnc5wFI4fK lNn9K3gaThZobTs2iPdTindXn5AksIXD5ZkLZrbNpz7xQunAnoVA/H3KoHCCyskO2exap1 6qQCN5B6oLk0ZARpcgsEH717ZtIDxJLBXgM2zOb/ihTWJDNDSiducOIl512okB+NYkUMgG BuYbjSpSESEA+ZmZB0eo0CoRMkF/2vMFAxoIlqZcFXERhTDvb5b6gtBi6E33xg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 513 Lines: 15 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239673 Poul-Henning Kamp changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Open |Closed --- Comment #1 from Poul-Henning Kamp --- Time out my own ticket. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Dec 22 13:53:55 2021 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 7A0CA18E73B1 for ; Wed, 22 Dec 2021 13:54:04 +0000 (UTC) (envelope-from SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JJvtz2C5Pz4Ytl for ; Wed, 22 Dec 2021 13:54:03 +0000 (UTC) (envelope-from SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl) Date: Wed, 22 Dec 2021 14:53:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1640181236; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=LFLditZOUd2fjgCBgJ+zQbbI/lKYbz3KbGITb0JtWfc=; b=h4cEeBYKatUKdFlVL+G2iEJQt4JXyLZG2CT9l/D/E0qZ/3Hfjnr5lfUvykF71WThsOUl4W Iw6Y60pYNStgalyJyW24w1y3O1hWT9trTyHBg605ZZ0eFdCa2sUInO9TL35IlEYu0Hx499 MyMrRl40vP3eSHPjnGzgEa51JjfqYp3Z5dXINt1z0uZyBcb5UjFchKf2NkLVvvw0yw82k9 i+DP1KAv56F2Csb4dhoYfITrVtilna7+AnRhTj/FK0KrgaPBioUpZOAs41MrwEmAUYQ2Wn JVHwTggshBkEgPHfjP48bRDIaBR+aQFqT/529o2HATy9zV3AIUqMgRQlOJJL/A== To: freebsd-arm@freebsd.org Message-ID: <297610586.526.1640181235676@localhost> Subject: ipv6 on genet0 + bridge not configuring 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="----=_Part_525_337538973.1640181235578" X-Mailer: Realworks (589.200.e94892b) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JJvtz2C5Pz4Ytl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=h4cEeBYK; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.98)[-0.984]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=zwTi=RH=klop.ws=ronald-lists@realworks.nl] Reply-To: ronald-lists@klop.ws From: Ronald Klop via freebsd-arm X-Original-From: Ronald Klop X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3283 Lines: 87 ------=_Part_525_337538973.1640181235578 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, My RPI4 is running pretty happy with some VNET jails on it. # uname -a FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #15 main-9c0287e092: Fri Nov 5 10:48:20 CET 2021 ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 # cat /etc/rc.conf hostname="rpi4" cloned_interfaces="bridge0" ifconfig_bridge0="addm genet0 SYNCDHCP" ifconfig_genet0="up" I now added this line to rc.conf: ifconfig_bridge0_ipv6="inet6 accept_rtadv" This does trigger some ipv6 negotiation on start up, but also some errors. bridge0: Ethernet address: 58:9c:fc:00:3e:aa Created cloe interfaces: bridge0. lo0: link state changed to UP genet0: link state changed to DOWN genet0: promiscuous mode enabled bridge0: link state changed to DOWN rtsol: cap_llflags_get() failed, anyway I'll try rtsol: sendmsg on bridge0: Can't assign requested address genet0: link state changed to UP bridge0: link state changed to UP rtsol: sendmsg on bridge0: Can't assign requested address rtsol: sendmsg on bridge0: Can't assign requested address Starting dhclient. Dhclient for ipv4 works well and assigns an address. Similar setup on another FreeBSD 14 works well with ipv6. But that does not have a bridge. It just enables IPv6 on the interface. What am I missing? Something obvious? Regards, Ronald. ------=_Part_525_337538973.1640181235578 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

My RPI4 is running pretty happy with some VNET jails on it.
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #15 main-9c0287e092: Fri Nov  5 10:48:20 CET 2021     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG  arm64

# cat /etc/rc.conf
hostname="rpi4"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm genet0 SYNCDHCP"
ifconfig_genet0="up"

I now added this line to rc.conf:
ifconfig_bridge0_ipv6="inet6 accept_rtadv"

This does trigger some ipv6 negotiation on start up, but also some errors.
bridge0: Ethernet address: 58:9c:fc:00:3e:aa
Created cloe interfaces: bridge0.
lo0: link state changed to UP
genet0: link state changed to DOWN
genet0: promiscuous mode enabled
bridge0: link state changed to DOWN
rtsol: cap_llflags_get() failed, anyway I'll try
rtsol: sendmsg on bridge0: Can't assign requested address
genet0: link state changed to UP
bridge0: link state changed to UP
rtsol: sendmsg on bridge0: Can't assign requested address
rtsol: sendmsg on bridge0: Can't assign requested address
Starting dhclient.

Dhclient for ipv4 works well and assigns an address.

Similar setup on another FreeBSD 14 works well with ipv6. But that does not have a bridge. It just enables IPv6 on the interface.

What am I missing? Something obvious?

Regards,
Ronald.
  ------=_Part_525_337538973.1640181235578-- From nobody Wed Dec 22 17:35:14 2021 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 1487718FD4F0 for ; Wed, 22 Dec 2021 17:35:10 +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 4JK0p55hsMz3l2n for ; Wed, 22 Dec 2021 17:35:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BMHZFMX094352 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 22 Dec 2021 09:35:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BMHZEs2094351; Wed, 22 Dec 2021 09:35:14 -0800 (PST) (envelope-from fbsd) Date: Wed, 22 Dec 2021 09:35:14 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: ld: error: bzlib.pico:147: unclosed quote Message-ID: <20211222173514.GA93415@www.zefox.net> References: <20211221180041.GA29679@www.zefox.net> <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@yahoo.com> <20211222040334.GB30154@www.zefox.net> <17ED22E1-E08E-47FF-85A7-16DA8303C8A3@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: <17ED22E1-E08E-47FF-85A7-16DA8303C8A3@yahoo.com> X-Rspamd-Queue-Id: 4JK0p55hsMz3l2n X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1236 Lines: 34 On Tue, Dec 21, 2021 at 08:14:58PM -0800, Mark Millard wrote: > On 2021-Dec-21, at 20:03, bob prohaska wrote: > > > On Tue, Dec 21, 2021 at 05:51:59PM -0800, Mark Millard wrote: > > Not noise? Which adapter was in use during the corruption? > Does this mean that you have showed 2 disks to have issues > using the same adapter on the same RPi3* (but with different > firmware/U-Boot/Loader/kernel/World's on the 2 disks)? > No, I don't think so. I expected the enumeration problem to move with the disks. Instead neither disk enumerated readily when moved. The disks have different bridge chips. > Whatever the details, such would be good information to > know. I've been offered a Windows 7 machine that can be used to apply the Sabrent firmware updater. That seems like the obvious thing to try next in light of the error reported on the Pi3: Read NVMe Identify Controller failed: scsi error unsupported field in scsi command No clue if it'll help, but it's a relatively easy experiment. The observations will be added to http://www.zefox.net/~fbsd/slow_usb_notes I'll try to keep them somewhat more coherent if others are trying to follow the story. Thanks for your help and attention! bob prohaska From nobody Wed Dec 22 18:40:58 2021 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 9E3C219085FC for ; Wed, 22 Dec 2021 18:41:09 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JK2GF2WVmz3tv3 for ; Wed, 22 Dec 2021 18:41:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640198462; bh=J0pbasSuSDwr5z0G8dZLq6z4wcEU6lr5ZO/1lyBWGpY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JrNyMjsgW7pgxCj46zU8YpQl39tERR7emtFwd6cxhDisZOL3lwcem8FqLryJC9EMTxC4jEgiXcsMtqbvaR4rXWcuHnwy7V8rYeleKISoO+SmypD0m2m9/mdTtDoguc7J/Jk9hc9FpR4YVedSmrfg+LCN+gKun7YM7t63Jory+/k8x2Xul+KJ6QyJRBIlVaF70tvcKUd3DS57Ew/9CYru8BGQZwASqqYsb/dfDU0gVcEdK3DBXjZ9LAnSd13wq5oLw1SpLr1LOWhSS82krxceJpA++pAIjaJGE1GGTw2NjRMt5GObJijuaPiuUWXw+v353cCK1e0d+11IBJdXQEKhAA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640198462; bh=kTe1gu6kYJYscS2091ANB7N/mdZks2FtwLtXg9WxWWn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FdwpgDuwHfq+pELHUnKN5ihlRzqumUch355M0WqMI7rro20m0cZLs652t1vfF/I5JuP+vNrQRRTkVqJuK0JtdrfL/kjQM1cGuJ8Ypu3YzIL2gFBkOUNMExKOc0tFQ81jrfPRwtx+QmagGWvKS62zgGsRNKklyj24t5MG11Za9rPVCB/VvrWLLhc/QTxYwEg9hRIM3dXHgOUKOPfnpK93rd+xLAhom2uLQ8b6IO/o0q8I4tXtF/H80w9+OcpYQ8Zeql6snssUI4god7To7y94RRnFFQeRMDKtKEuDPgy3Zxs1xcDhuv+qN9QmURp9I82hP3vIJdnmhGOLV9pu4vP1cg== X-YMail-OSG: zU87QQIVM1kiliX3k35JD0Lw208BkjY4DjsCBfiK2OB27DEFJldYBRQGfFI3A4A MxCHnp7CC2cJOb66jrcdwCEpn.ZIwHO37c6_61vU8EQqmzx_3eA0KJRB9R6yJHf7IGJgPTx8vlTE 2Nc1FbdsAc3ot_oxr32zXX.CMxeqbJe.KH.7ydPF5g2BGpo2XFDLgt6w4AKDFO2o72wh.XQ8YNZ1 WqOeeCXTaXn6CAuqIEiumAADWO.GRysDD.Rq1uH_oHwQoy_tpTE0eDN0i7KIUmB6xkrSLRZGHjBg FwRURKVRk9x.jx5RZ1r9LxZqQqgIcyNYNDiRLYDPh_PZeBwHbS.dtsQFU6DNZE9sCsz53HgN_Cc1 .k7qhWsutSnO8fvkA8HFsZBePetlIcTfnso3Aku8Chl5hZBTtmdjXvMAdO_TH8A4e13NX3Ers8M8 ws2xmaVSvZBVanTUuiTCmdi.PyJ3V7T80h1uvc6MYAkqF7Lh5Mi0jKSDQ2YiN948l6Mp_hjDhbvH jawQKqb9kI1ZSOsq.V3iaqulk2Vq8J.Zp9REvw1RLm5OAC3iSa5K88nwy.SZlhEukt48ny6UyIlu csrDxVOJ2PwLkvQWn2d.hgTAx81FqWmwi4Nk4MEm_hAEf5N7yDX._XlUQkpS6pWn4fZwdTdkIkV4 2XuFRTR7XFQb0kF1QraEgLUHvWsUnktgTj3d6mQGcoFm9.W0Ep68JuzQJtUJb0UWFmK_IFidP9uH 8HoKk6ASx41Pguw_iJPgaLP5T6JnsbYUDey8HEvWZYgpicrYxEXCsU4eYMFnkWw95DtDCQ.e0dPe 2maVQtkR4UYSqT2Kp0S2DAX13qevPhtHOD_Liz.s4OgClEMvjpOVASdrtg3RIViPMNxm21zJa0PZ yqaH2fdAFFf3xFSLt.hGTHpVHmLIwjsk1LTfOrQR5hZfAxmNwXyZE8eAyit_owhySTFAuwRIUC4V AXT1GvIahStUY9VdxLzKiytxE5xakHkEFjEngUA7CIgcZn4lkWWRscj79Z2PRHnYdsRy3Eo11e_Y WwE8kLAwKGRni7fa.GY.mSloEDULnbUIJ94GgJjcOU0J3hChKr.jwXllxb5Q3n2JM9Y5Zm5.kYuW 65qPR0rvMKnq3kKi.W76Q5rFoERL1MdNK3tAB_sZc7iSXSMKJA_Le6TD8PaacIpKmeaqThJ29dMB l2kAQLU3.qJ0MuUnVjeWLGsc.cFUViqKSiom_98woOFq_7Lt8_OhnFL1sngFc3dC46ZayGEbociD jVd8WiB4AQd42Uf8ZliCGJnykGGstCFdB6hv3rVU1ntp0JC4kvVXo5ArX5GtPf_5Co_wTzIdk4Si .URqGTm.N_4C7LqFXCqpOfbUP36i3qBEATcciRSftcEq4pAQzmwRn4Mr8Gry9yo1BwRmTqrfvow4 yR8llfsyEGMZLZY9mYEyG_.4TOswhRAs331vLZyGLNS4j4_lR8xqUsA1k4YCuD5_1HyWUkfLUbXi XgncC0KcermNN0lu5NVHcObyO.Dp9x9obvTvgqq1u9zLLBUOPG8wuWrbSBz51Y_LRLruM3dNAgWI DbUIu1KGcvsLds9vKbjUHXBugqJ11wWFVBU76T8Ajl67Iyr.uAaXOx.E8dp4KNgiNzTvvN.OaE7D JAwz9Qvf2qpJP5janFQpHPjPt5Z7yCwGitYuxwlaVuJdvuKV_p7vyE7xRQ5Z8e63fBwq6RzSbqGT Q_nO1NMHDXdY6tWQ2uAoSN58yWbnqmwxGYmJItRb.bEAbIuBjbnkGZrfxNDCw16UPlHsGxSmnNYx QpFSEEyoHw9P8k8SMN_YSLq5Ezn7qoDFVTALBlrf.if_afQsgcAO2s3K9WMkGdT9mw1YHl_zwLZr tlIQxuNPvydTeJV3N6yWMFYARwu.YaTXRNVpRPLVHMbD7A0JexQKQ_IAdW1TbhZtzKgXVH8dWkdP o3yYwaJc3eTxlw9R6gF1TOPpkVb7S7tDVkLms_p4tkez.LHXFHzyWINT8Fy47TdDWK_AFOI2pLYM QHq03J0xAnIYQxBb.AUyJ6YBTNXblxmbs5amcqFRXvTi5W7Rgmme.g3ztZ21thPkLuYZh6Q43gcd 1H9QxhINmtYhkMgbZV43BySHlMlzA49Be86F..1_B15hF.vbON3zJBzy7fsxYpE8FslF4BDwBK1n pAhpvd0vxI98.JF_2w1dvcwaLnEZLMxpi3ZkltKb5wndrTGpoqZwzbG_vyY06YaXjG_NqYW_rNw7 s0RPH3zcYPKQ4xNhquPXx2qEkaAO8roCaX49ZqVqAGQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Dec 2021 18:41:02 +0000 Received: by kubenode517.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1ee4f56ce3bc688d4bad9307724e7fc4; Wed, 22 Dec 2021 18:41:00 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: ld: error: bzlib.pico:147: unclosed quote In-Reply-To: <20211222173514.GA93415@www.zefox.net> Date: Wed, 22 Dec 2021 10:40:58 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E237306-32A7-4BA4-82D8-268174409C73@yahoo.com> References: <20211221180041.GA29679@www.zefox.net> <0E4548B1-B8F6-45D8-AB30-634E47511688@yahoo.com> <4349F44D-C77B-44DD-9A96-0E8C4E7EA046@yahoo.com> <20211222040334.GB30154@www.zefox.net> <17ED22E1-E08E-47FF-85A7-16DA8303C8A3@yahoo.com> <20211222173514.GA93415@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JK2GF2WVmz3tv3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2605 Lines: 69 On 2021-Dec-22, at 09:35, bob prohaska wrote: > On Tue, Dec 21, 2021 at 08:14:58PM -0800, Mark Millard wrote: >> On 2021-Dec-21, at 20:03, bob prohaska wrote: >>=20 >>> On Tue, Dec 21, 2021 at 05:51:59PM -0800, Mark Millard wrote: >>=20 >> Not noise? Which adapter was in use during the corruption? >> Does this mean that you have showed 2 disks to have issues >> using the same adapter on the same RPi3* (but with different >> firmware/U-Boot/Loader/kernel/World's on the 2 disks)? >>=20 > No, I don't think so. I expected the enumeration problem > to move with the disks. Instead neither disk enumerated > readily when moved. The disks have different bridge chips. So, it sounds like you moved each disk with its adapter between RPi*'s. If I gather right: The RPi4B had problems with enumerating the disk/adapter combination that has been under discussion (but used on a RPi3). Presuming use of a USB3 port, power is less likely to be a big deal for this test. For the RPI4B, the adapter firmware and the status of FreeBSD's quirks for the adapter seem more likely to be what is at issue. That in turn indicates that those are likely involved for the RPi3* use as well (but power could be involved as well). The RPi3 had problems with enumerating the disk/adapter combination that works on the RPi4B. This suggests a power problem but not an adpater-firmware/FreeBSD-quirks problem for this context. I'd say, that is not just noise. (I do not remember the information about the normally-on-RPI4B drive and adapter combination being listed.) >> Whatever the details, such would be good information to >> know. >=20 > I've been offered a Windows 7 machine that can be used to apply > the Sabrent firmware updater. That seems like the obvious thing > to try next in light of the error reported on the Pi3: > Read NVMe Identify Controller failed: scsi error unsupported field in = scsi command Sounds like you did not see that for the RPi4B with the drive/adapter combination that is usually on the RPi3*? If it was a adapter-firmware/FreeBSD-quirks problem, I'd expect that you would see it on both RPi*'s. If you do not see it on the RPi4B, then likely power on the RPi3* is involved and a firmware/quirks update would not fix the problem. Again: not just noise. > No clue if it'll help, but it's a relatively easy experiment. > The observations will be added to=20 > http://www.zefox.net/~fbsd/slow_usb_notes > I'll try to keep them somewhat more coherent if others are > trying to follow the story.=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 22 20:02:35 2021 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 01D131917F63 for ; Wed, 22 Dec 2021 20:02:36 +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 4JK44C5nqJz4cHx for ; Wed, 22 Dec 2021 20:02:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 A790B234A5 for ; Wed, 22 Dec 2021 20:02:35 +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 1BMK2ZI3081711 for ; Wed, 22 Dec 2021 20:02:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BMK2Zjd081710 for freebsd-arm@FreeBSD.org; Wed, 22 Dec 2021 20:02:35 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 256822] arm64/rockpro64/13-Rp2/mmc: Instapanic with recoverdisk(1) Date: Wed, 22 Dec 2021 20:02:35 +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: 13.0-RELEASE X-Bugzilla-Keywords: panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: phk@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: bug_status resolution 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640203355; 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=tv64eHrxUYr8Hvlfnr4wqdeueE0DSPgDehRXUHtrWRg=; b=j+ALKLpvCKdj6bSEogeWOLDhqzfmljlaHqchWreeaDc1MDmYUBs//ZAp6u/MPgUYmJqrm8 V3JdD1/9MHydwM+FllZ3MfPStFbMNkKACdASwgxmtcBHMY6B0KcDXptgO8+468m+InMAVO 5yaW0fbNM3Yq04wkTboz7hjmeESzlFLDxfwqqqERhP5rpIc4Wcw7BRlgH3SdE6aBS8JX3l Tb0JjJ0JvJ3oR2Om95Gw977uj0/v8uexBF4VIzk6XAIHL6rAQ8liyX+fmYk9jLJ4S1ZVpB jnjlE7sErsbBMAvWoHNwnwDMaYqVFPCjlXpq/BHfjUVrs7/SuXA3e8GnZx3P8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640203355; a=rsa-sha256; cv=none; b=mIpwmOPph8JAE9JbSoAzX7EvBpwAifGfYXp8Zsn6BYqCXLE8dG8eZ8nyzlD/9ue6THQiSy PUYl+5PCfnrCJMbK1awHSMTGnqZQLMx90fRoxA0w2DPERwWr0BZoV7lc/K6uzHmyx0VzCD HUuETSyGT9FQdf6lB3WhetVTafYQDPUUDB3WhwDEn/XczuDJHil+Apl+LpBu7IHIm8fcxX WQmSp+YxREqdgyhcye1gM/HxOkcfBfQhd/0QC/FmpUaIpCfJVml7O03t875USqrdPwM4Hf ZP9K5UQL6NzVH9s6eg4YerVbWCsDxPwsHKksqMB2+prZjlMfzeyCUHhj2L5r4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 428 Lines: 12 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256822 Poul-Henning Kamp changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Dec 23 13:06:13 2021 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 18F9D191344D for ; Thu, 23 Dec 2021 13:06:25 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4JKVnX2Tq1z4fR3 for ; Thu, 23 Dec 2021 13:06:24 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id y22so21259261edq.2 for ; Thu, 23 Dec 2021 05:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=4hTD7i07UtSZsK4Yhua0ZIhsAqY4FvzgrwVNz8iGHGY=; b=BY5oR2bC88XIok+XDFzi8l1tbcjLfMRKizrt0gfhsS49jJf+hUUohJeijj+t7JBXMh R0plL0ZVnxewSz67jN/AXij1MfTMZ+ltnAJRqfJMW8/vEZzEJPnuqzdeUtBL4VA0aK34 Ioz+HGrp6FABCsftVbfj5rRXk8c7uWrb+JLc4YoMo0aQ4D06uuqmBaq8/mdHZ3+cNpoa cC+EHyPKpr5A7aXKrsULPB3GGKkM7eLDtGM8RqnQaYBX5w8Z1y10VyX2hBLVIZFqKeFM V+/6+GLxt5Xffm5xbjkE4dGVgLbiuFIzuWn1c0tzopy5ubY1TAzHJ7EuQ0HYTMQbJ5DA /6+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4hTD7i07UtSZsK4Yhua0ZIhsAqY4FvzgrwVNz8iGHGY=; b=ZZCFlYmNaMPKx9qSpQ6nLBbDoBTabk4Nfi87Ex5jv0ONkC+u5VgYcXuoKxbeTMDs2I pMWbsIGk8bCxlcNMMcuGSqmp8667EkDCwKoTZ1xrVilClt4HoERc/JsZAnPqxV39bace daJLV4pp8DlZpTzeELZ//mNdftj86TRfvBXMdtfz6faLp/1/mbSRy56IDH3fDzIJQQwW hMvodNpvv19Kk8ggd0f1CGfVkeNbXDvGrfoBnKoYeVqwHMalQ5S4SJC1EmbQFTXaQ6Wv MqVZhBdzvDJ5XdYG9hnZPUfiIFSf0VlNTmekMP1MhzajXCgiVuPRtwhh3jOW0tHvSZBG doEw== X-Gm-Message-State: AOAM532Irp8D59IxWUsixAavd1kGZBM1grvO2YuC1uZlPYicIHgDNIY/ tBU7w+3iXLwmThKQ7DmimgJWF95+LDP0VCPUw/zzb0cQyZw= X-Google-Smtp-Source: ABdhPJxOAmhVP3HiPk4N/KK5fvRn5+OpB4qBO61T+dDstLcEwLlxSxQUYipP+f+VDMEsORk+Pprv7H8os9Fm9r5kO9Y= X-Received: by 2002:a17:906:fc9:: with SMTP id c9mr1797018ejk.728.1640264782561; Thu, 23 Dec 2021 05:06:22 -0800 (PST) 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 From: Archimedes Gaviola Date: Thu, 23 Dec 2021 21:06:13 +0800 Message-ID: Subject: Raspberry Pi 4B does not detect devices in USB 3.0 To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="000000000000b3d4d405d3cfe73c" X-Rspamd-Queue-Id: 4JKVnX2Tq1z4fR3 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BY5oR2bC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [2.09 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.991]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 22363 Lines: 317 --000000000000b3d4d405d3cfe73c Content-Type: multipart/alternative; boundary="000000000000b3d4d205d3cfe73a" --000000000000b3d4d205d3cfe73a Content-Type: text/plain; charset="UTF-8" Hi, I have successfully installed FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f in Raspberry Pi 4B with 2GB RAM. USB devices work well and get detected with the USB 2.0 ports however when tried with USB 3.0 ports all these devices can't be detected thus will not work. My config.txt has the following contents. Anything I missed? I also attached the dmesg output. freebsd@freebsd13:/boot/msdos % cat config.txt [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 Thanks and best regards, Archimedes --000000000000b3d4d205d3cfe73a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have successfully inst= alled FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f in Raspberry Pi 4B with 2GB RAM. USB devices work well and get detected wi= th the USB 2.0 ports however when tried with USB 3.0 ports all these device= s can't be detected thus will not work. My config.txt has the following= contents. Anything I missed? I also attached the dmesg output.

freebsd@freebsd13:/boot/msdos % cat config.txt
[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

Thanks and best regar= ds,
Archimedes

--000000000000b3d4d205d3cfe73a-- --000000000000b3d4d405d3cfe73c Content-Type: text/plain; charset="US-ASCII"; name="freebsd-13.0-dmesg.txt" Content-Disposition: attachment; filename="freebsd-13.0-dmesg.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kxiz1nvz0 LS0tPDxCT09UPj4tLS0NCkNvcHlyaWdodCAoYykgMTk5Mi0yMDIxIFRoZSBGcmVlQlNEIFByb2pl Y3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5 OTEsIDE5OTIsIDE5OTMsIDE5OTQNCiAgICAgICAgVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNp dHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCkZyZWVCU0QgaXMgYSByZWdp c3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLg0KRnJlZUJTRCAxMy4w LVJFTEVBU0UgIzAgcmVsZW5nLzEzLjAtbjI0NDczMy1lYTMxYWJjMjYxZjogRnJpIEFwciAgOSAw NjowNjo1NSBVVEMgMjAyMQ0KICAgIHJvb3RAcmVsZW5nMS5ueWkuZnJlZWJzZC5vcmc6L3Vzci9v YmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3N5cy9HRU5FUklDIGFybTY0DQpGcmVlQlNEIGNsYW5n IHZlcnNpb24gMTEuMC4xIChnaXRAZ2l0aHViLmNvbTpsbHZtL2xsdm0tcHJvamVjdC5naXQgbGx2 bW9yZy0xMS4wLjEtMC1nNDNmZjc1ZjJjM2ZlKQ0KVlQ6IGluaXQgd2l0aG91dCBkcml2ZXIuDQpt b2R1bGUgZmlybXdhcmUgYWxyZWFkeSBwcmVzZW50IQ0KcmVhbCBtZW1vcnkgID0gMjA2NzU0MjAx NiAoMTk3MSBNQikNCmF2YWlsIG1lbW9yeSA9IDE5OTM4NDI2ODggKDE5MDEgTUIpDQpTdGFydGlu ZyBDUFUgMSAoMSkNClN0YXJ0aW5nIENQVSAyICgyKQ0KU3RhcnRpbmcgQ1BVIDMgKDMpDQpGcmVl QlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMNCnJhbmRvbTog dW5ibG9ja2luZyBkZXZpY2UuDQpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGludGVy ZmFjZQ0KTUFQIDM5ZjM4MDAwIG1vZGUgMiBwYWdlcyAxDQpNQVAgMzlmM2MwMDAgbW9kZSAyIHBh Z2VzIDMNCk1BUCAzOWY0MDAwMCBtb2RlIDIgcGFnZXMgNA0KTUFQIDNiMzUwMDAwIG1vZGUgMiBw YWdlcyAxNg0KTUFQIGZlMTAwMDAwIG1vZGUgMCBwYWdlcyAxDQpXQVJOSU5HOiBEZXZpY2UgIm9w ZW5maXJtIiBpcyBHaWFudCBsb2NrZWQgYW5kIG1heSBiZSBkZWxldGVkIGJlZm9yZSBGcmVlQlNE IDE0LjAuDQpXQVJOSU5HOiBEZXZpY2UgImtiZCIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUg ZGVsZXRlZCBiZWZvcmUgRnJlZUJTRCAxNC4wLg0Ka2JkMCBhdCBrYmRtdXgwDQpvZndidXMwOiA8 T3BlbiBGaXJtd2FyZSBEZXZpY2UgVHJlZT4NCnNpbXBsZWJ1czA6IDxGbGF0dGVuZWQgZGV2aWNl IHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3YnVzMA0Kb2Z3X2Nsa2J1czA6IDxPRlcgY2xvY2tzIGJ1 cz4gb24gb2Z3YnVzMA0KY2xrX2ZpeGVkMDogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMA0K Y2xrX2ZpeGVkMTogPEZpeGVkIGNsb2NrPiBvbiBvZndfY2xrYnVzMA0KY2xrX2ZpeGVkMjogPEZp eGVkIGNsb2NrPiBvbiBvZndidXMwDQpjbGtfZml4ZWQzOiA8Rml4ZWQgY2xvY2s+IG9uIG9md2J1 czANCnNpbXBsZWJ1czE6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3 YnVzMA0Kc2ltcGxlYnVzMjogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBv ZndidXMwDQpyZWdmaXgwOiA8Rml4ZWQgUmVndWxhdG9yPiBvbiBvZndidXMwDQpyZWdmaXgxOiA8 Rml4ZWQgUmVndWxhdG9yPiBvbiBvZndidXMwDQpyZWdmaXgyOiA8Rml4ZWQgUmVndWxhdG9yPiBv biBvZndidXMwDQpzaW1wbGVidXMzOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+ IG9uIG9md2J1czANCnNpbXBsZV9tZmQwOiA8U2ltcGxlIE1GRCAoTXVsdGktRnVuY3Rpb25zIERl dmljZSk+IG1lbSAweDdkNWQyMDAwLTB4N2Q1ZDJlZmYgb24gc2ltcGxlYnVzMA0KYmNtMjgzNV9m aXJtd2FyZTA6IDxCQ00yODM1IEZpcm13YXJlPiBvbiBzaW1wbGVidXMwDQpvZndfY2xrYnVzMTog PE9GVyBjbG9ja3MgYnVzPiBvbiBiY20yODM1X2Zpcm13YXJlMA0KcHNjaTA6IDxBUk0gUG93ZXIg U3RhdGUgQ28tb3JkaW5hdGlvbiBJbnRlcmZhY2UgRHJpdmVyPiBvbiBvZndidXMwDQpnaWMwOiA8 QVJNIEdlbmVyaWMgSW50ZXJydXB0IENvbnRyb2xsZXI+IG1lbSAweDQwMDQxMDAwLTB4NDAwNDFm ZmYsMHg0MDA0MjAwMC0weDQwMDQzZmZmLDB4NDAwNDQwMDAtMHg0MDA0NWZmZiwweDQwMDQ2MDAw LTB4NDAwNDdmZmYgaXJxIDMwIG9uIHNpbXBsZWJ1czANCmdpYzA6IHBuIDB4MiwgYXJjaCAweDIs IHJldiAweDEsIGltcGxlbWVudGVyIDB4NDNiIGlycXMgMjU2DQpncGlvMDogPEJDTTI3MDgvMjgz NSBHUElPIGNvbnRyb2xsZXI+IG1lbSAweDdlMjAwMDAwLTB4N2UyMDAwYjMgaXJxIDE0LDE1IG9u IHNpbXBsZWJ1czANCmdwaW9idXMwOiA8T0ZXIEdQSU8gYnVzPiBvbiBncGlvMA0KZ3BpbzE6IDxS YXNwYmVycnkgUGkgRmlybXdhcmUgR1BJTyBjb250cm9sbGVyPiBvbiBiY20yODM1X2Zpcm13YXJl MA0KZ3Bpb2J1czE6IDxHUElPIGJ1cz4gb24gZ3BpbzENCnJlZ2ZpeDA6IENhbm5vdCBzZXQgR1BJ TyBwaW46IDYNClJFR05PREVfSU5JVCBmYWlsZWQ6IDYNCnJlZ2ZpeDA6IENhbm5vdCByZWdpc3Rl ciByZWd1bGF0b3IuDQptYm94MDogPEJDTTI4MzUgVmlkZW9Db3JlIE1haWxib3g+IG1lbSAweDdl MDBiODgwLTB4N2UwMGI4YmYgaXJxIDEzIG9uIHNpbXBsZWJ1czANCmdwaW9yZWd1bGF0b3IwOiA8 R1BJTyBjb250cm9sbGVkIHJlZ3VsYXRvcj4gb24gb2Z3YnVzMA0KZ2VuZXJpY190aW1lcjA6IDxB Uk12OCBHZW5lcmljIFRpbWVyPiBpcnEgNCw1LDYsNyBvbiBvZndidXMwDQpUaW1lY291bnRlciAi QVJNIE1QQ29yZSBUaW1lY291bnRlciIgZnJlcXVlbmN5IDU0MDAwMDAwIEh6IHF1YWxpdHkgMTAw MA0KRXZlbnQgdGltZXIgIkFSTSBNUENvcmUgRXZlbnR0aW1lciIgZnJlcXVlbmN5IDU0MDAwMDAw IEh6IHF1YWxpdHkgMTAwMA0KdXNiX25vcF94Y2VpdjA6IDxVU0IgTk9QIFBIWT4gb24gb2Z3YnVz MA0KZ3Bpb2MwOiA8R1BJTyBjb250cm9sbGVyPiBvbiBncGlvMA0KdWFydDA6IDxQcmltZUNlbGwg VUFSVCAoUEwwMTEpPiBtZW0gMHg3ZTIwMTAwMC0weDdlMjAxMWZmIGlycSAxNiBvbiBzaW1wbGVi dXMwDQp1YXJ0MDogY29uc29sZSAoMTE1MjAwLG4sOCwxKQ0Kc3BpMDogPEJDTTI3MDgvMjgzNSBT UEkgY29udHJvbGxlcj4gbWVtIDB4N2UyMDQwMDAtMHg3ZTIwNDFmZiBpcnEgMTggb24gc2ltcGxl YnVzMA0Kc3BpYnVzMDogPE9GVyBTUEkgYnVzPiBvbiBzcGkwDQpzcGlidXMwOiA8dW5rbm93biBj YXJkPiBhdCBjcyAwIG1vZGUgMA0Kc3BpYnVzMDogPHVua25vd24gY2FyZD4gYXQgY3MgMSBtb2Rl IDANCmlpY2hiMDogPEJDTTI3MDgvMjgzNSBCU0MgY29udHJvbGxlcj4gbWVtIDB4N2U4MDQwMDAt MHg3ZTgwNGZmZiBpcnEgMjYgb24gc2ltcGxlYnVzMA0KYmNtX2RtYTA6IDxCQ00yODM1IERNQSBD b250cm9sbGVyPiBtZW0gMHg3ZTAwNzAwMC0weDdlMDA3YWZmIGlycSAzMSwzMiwzMywzNCwzNSwz NiwzNywzOCwzOSw0MCw0MSBvbiBzaW1wbGVidXMwDQpiY213ZDA6IDxCQ00yNzA4LzI4MzUgV2F0 Y2hkb2c+IG1lbSAweDdlMTAwMDAwLTB4N2UxMDAxMTMsMHg3ZTAwYTAwMC0weDdlMDBhMDIzLDB4 N2VjMTEwMDAtMHg3ZWMxMTAxZiBvbiBzaW1wbGVidXMwDQpncGlvYzE6IDxHUElPIGNvbnRyb2xs ZXI+IG9uIGdwaW8xDQpzZGhjaV9iY20wOiA8QnJvYWRjb20gMjcwOCBTREhDSSBjb250cm9sbGVy PiBtZW0gMHg3ZTMwMDAwMC0weDdlMzAwMGZmIGlycSA3MyBvbiBzaW1wbGVidXMwDQptbWMwOiA8 TU1DL1NEIGJ1cz4gb24gc2RoY2lfYmNtMA0KZmIwOiA8QkNNMjgzNSBWVCBmcmFtZWJ1ZmZlciBk cml2ZXI+IG9uIHNpbXBsZWJ1czANCmZiMDogY2hhbmdpbmcgZmIgYnBwIGZyb20gMCB0byAyNA0K bWJveDA6IG1ib3ggcmVzcG9uc2UgZXJyb3INCmZiMDogYmNtMjgzNV9tYm94X2ZiX2luaXQgZmFp bGVkLCBlcnI9NQ0KZGV2aWNlX2F0dGFjaDogZmIwIGF0dGFjaCByZXR1cm5lZCA2DQpzZGhjaV9i Y20xOiA8QnJvYWRjb20gMjcwOCBTREhDSSBjb250cm9sbGVyPiBtZW0gMHg3ZTM0MDAwMC0weDdl MzQwMGZmIGlycSA3OSBvbiBzaW1wbGVidXMxDQptbWMxOiA8TU1DL1NEIGJ1cz4gb24gc2RoY2lf YmNtMQ0KcG11MDogPFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgVW5pdD4gaXJxIDAsMSwyLDMgb24g b2Z3YnVzMA0KY3B1bGlzdDA6IDxPcGVuIEZpcm13YXJlIENQVSBHcm91cD4gb24gb2Z3YnVzMA0K Y3B1MDogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KYmNtMjgzNV9jcHVmcmVxMDog PENQVSBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MA0KY3B1MTogPE9wZW4gRmlybXdhcmUgQ1BV PiBvbiBjcHVsaXN0MA0KY3B1MjogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1 MzogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KcGNpYjA6IDxCQ00yODM4LWNvbXBh dGlibGUgUENJLWV4cHJlc3MgY29udHJvbGxlcj4gbWVtIDB4N2Q1MDAwMDAtMHg3ZDUwOTMwZiBp cnEgODAsODEgb24gc2ltcGxlYnVzMg0KcGNpYjA6IGhhcmR3YXJlIGlkZW50aWZpZXMgYXMgcmV2 aXNpb24gMHgzMDQuDQpwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8UENJLVBDSSBi cmlkZ2U+IGlycSA5MSBhdCBkZXZpY2UgMC4wIG9uIHBjaTENCnBjaTI6IDxQQ0kgYnVzPiBvbiBw Y2liMQ0KYmNtX3hoY2kwOiA8Vkw4MDUgVVNCIDMuMCBjb250cm9sbGVyIChvbiB0aGUgUmFzcGJl cnJ5IFBpIDRiKT4gaXJxIDkyIGF0IGRldmljZSAwLjAgb24gcGNpMg0KYmNtX3hoY2kwOiAzMiBi eXRlcyBjb250ZXh0IHNpemUsIDY0LWJpdCBETUENCnVzYnVzMCBvbiBiY21feGhjaTANCnBjaTA6 IDxQQ0kgYnVzPiBvbiBwY2liMA0KcGNpMDogZmFpbGVkIHRvIGFsbG9jYXRlIGJ1cyBudW1iZXIN CmRldmljZV9hdHRhY2g6IHBjaTAgYXR0YWNoIHJldHVybmVkIDYNCmdlbmV0MDogPFJQaTQgR2ln YWJpdCBFdGhlcm5ldD4gbWVtIDB4N2Q1ODAwMDAtMHg3ZDU4ZmZmZiBpcnEgODIsODMgb24gc2lt cGxlYnVzMg0KZ2VuZXQwOiBHRU5FVCB2ZXJzaW9uIDUuMCBwaHkgMHgwMDAwDQptaWlidXMwOiA8 TUlJIGJ1cz4gb24gZ2VuZXQwDQpicmdwaHkwOiA8QkNNNTQyMTNQRSAxMDAwQkFTRS1UIG1lZGlh IGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMA0KYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQt RkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULW1hc3Rl ciwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIGF1dG8NCmdlbmV0MDogRXRo ZXJuZXQgYWRkcmVzczogZGM6YTY6MzI6MzY6YjY6NzANCmdwaW9sZWQwOiA8R1BJTyBMRURzPiBv biBvZndidXMwDQpjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4NCmFybXY4Y3J5cHRvMDog Q1BVIGxhY2tzIEFFUyBpbnN0cnVjdGlvbnMNClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAw IG1zZWMNCmlpY2J1czA6IDxPRlcgSTJDIGJ1cz4gb24gaWljaGIwDQppaWMwOiA8STJDIGdlbmVy aWMgSS9PPiBvbiBpaWNidXMwDQp1c2J1czA6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNCIHYzLjAN CnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMwMDAwLCBidXQg dGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09 PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBTeXMg YWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9iY20wLXNsb3Qw OiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20w LXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDFhYSB8IFRybiBtb2RlOiAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAweDAwMDAwMDAx DQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6ICAweDAw MDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENsb2NrOiAg ICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAwMCB8IElu dCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjogMHgwMWZmMDBi YiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVycjogMHgw MDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBDYXBzOiAg ICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBN YXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNs b3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp1 Z2VuMC4xOiA8MHgxMTA2IFhIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMA0Kc2RoY2lfYmNtMC1zbG90 MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAwMDAsIGJ1dCB0aGVyZSBpcyBubyBhY3Rp dmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09IFJFR0lTVEVSIERV TVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IFN5cyBhZGRyOiAweDAwMDAwMDAw IHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2JjbTAtc2xvdDA6IEJsayBzaXplOiAweDAw MDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEFyZ3VtZW50 OiAweDAwMDAwMWFhIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFBy ZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAwMDENCnNkaGNpX2JjbTAtc2xv dDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdhcDogIDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6ICAgIDB4MDAwMDM5NDcNCnNk aGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwgSW50IHN0YXQ6IDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAweDAxZmYwMGJiIHwgU2lnIGVuYWI6IDB4 MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIgZXJyOiAweDAwMDAwMDAwIHwgSG9zdCBj dGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IENhcHM6ICAgICAweDAwMDAwMDAwIHwg Q2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IE1heCBjdXJyOiAweDAwMDAw MDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEFETUEgYWRkcjow eDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnVodWIwIG9uIHVzYnVzMA0K dWh1YjA6IDwweDExMDYgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMA0Kc2RoY2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0 IDB4MDAwMzAwMDAsIGJ1dCB0aGVyZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAt c2xvdDA6ID09PT09PT09PT09PT09IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNp X2JjbTAtc2xvdDA6IFN5cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDIN CnNkaGNpX2JjbTAtc2xvdDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAw MDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEFyZ3VtZW50OiAweDAwMDAwMWFhIHwgVHJuIG1vZGU6 IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9z dCBjdGw6IDB4MDAwMDAwMDENCnNkaGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBm IHwgQmxrIGdhcDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAw MDAwMDAwIHwgQ2xvY2s6ICAgIDB4MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6 ICAweDAwMDAwMDAwIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IElu dCBlbmFiOiAweDAxZmYwMGJiIHwgU2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xv dDA6IEFDMTIgZXJyOiAweDAwMDAwMDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IENhcHM6ICAgICAweDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNk aGNpX2JjbTAtc2xvdDA6IE1heCBjdXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4 MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAw eDAwMDMwMDAwLCBidXQgdGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNs b3QwOiA9PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9i Y20wLXNsb3QwOiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpz ZGhjaV9iY20wLXNsb3QwOiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAw MDAwDQpzZGhjaV9iY20wLXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDFhYSB8IFRybiBtb2RlOiAw eDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3Qg Y3RsOiAweDAwMDAwMDAxDQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8 IEJsayBnYXA6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAw MDAwMCB8IENsb2NrOiAgICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAg MHgwMDAwMDAwMCB8IEludCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQg ZW5hYjogMHgwMWZmMDBiYiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3Qw OiBBQzEyIGVycjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20w LXNsb3QwOiBDYXBzOiAgICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBNYXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAw DQpzZGhjaV9iY20wLXNsb3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAw MDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgw MDAzMDAwMCwgYnV0IHRoZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90 MDogPT09PT09PT09PT09PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNt MC1zbG90MDogU3lzIGFkZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2Ro Y2lfYmNtMC1zbG90MDogQmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAw MA0Kc2RoY2lfYmNtMC1zbG90MDogQXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBUcm4gbW9kZTogMHgw MDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0 bDogMHgwMDAwMDAwMQ0Kc2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBC bGsgZ2FwOiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAw MDAgfCBDbG9jazogICAgMHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4 MDAwMDAwMDAgfCBJbnQgc3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVu YWI6IDB4MDFmZjAwYmIgfCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDog QUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1z bG90MDogQ2FwczogICAgIDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogTWF4IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0K c2RoY2lfYmNtMC1zbG90MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAw MDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAw MzAwMDAsIGJ1dCB0aGVyZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6 ID09PT09PT09PT09PT09IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAt c2xvdDA6IFN5cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNp X2JjbTAtc2xvdDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDAN CnNkaGNpX2JjbTAtc2xvdDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAw MDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6 IDB4MDAwMDAwMDENCnNkaGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxr IGdhcDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAw IHwgQ2xvY2s6ICAgIDB4MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAw MDAwMDAwIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFi OiAweDAxZmYwMGJiIHwgU2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFD MTIgZXJyOiAweDAwMDAwMDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xv dDA6IENhcHM6ICAgICAweDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IE1heCBjdXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNk aGNpX2JjbTAtc2xvdDA6IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMw MDAwLCBidXQgdGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9 PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNs b3QwOiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9i Y20wLXNsb3QwOiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpz ZGhjaV9iY20wLXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDAwMCB8IFRybiBtb2RlOiAweDAwMDAw MDAwDQpzZGhjaV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAw eDAwMDAwMDAxDQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBn YXA6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8 IENsb2NrOiAgICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAw MDAwMCB8IEludCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjog MHgwMWZmMDBiYiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEy IGVycjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3Qw OiBDYXBzOiAgICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20w LXNsb3QwOiBNYXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAw DQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAw MCwgYnV0IHRoZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09 PT09PT09PT09PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90 MDogU3lzIGFkZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNt MC1zbG90MDogQmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2Ro Y2lfYmNtMC1zbG90MDogQXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBUcm4gbW9kZTogMHgwMDAwMDAw MA0Kc2RoY2lfYmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgw MDAwMDAwMQ0Kc2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2Fw OiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBD bG9jazogICAgMHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAw MDAgfCBJbnQgc3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4 MDFmZjAwYmIgfCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBl cnI6IDB4MDAwMDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDog Q2FwczogICAgIDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1z bG90MDogTWF4IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0K c2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KbW1jMDogTm8gY29tcGF0aWJsZSBjYXJkcyBmb3VuZCBvbiBidXMNCm1tY3NkMDogMzJH QiA8U0RIQyBTUDMyRyA4LjAgU04gNkVFOUI5NEMgTUZHIDAxLzIwMjEgYnkgMyBTRD4gYXQgbW1j MSA1MC4wTUh6LzRiaXQvNjU1MzUtYmxvY2sNCmJjbTI4MzVfY3B1ZnJlcTA6IEFSTSA2MDBNSHos IENvcmUgMjAwTUh6LCBTRFJBTSA0MDBNSHosIFR1cmJvIE9GRg0KUmVsZWFzZSBBUHMuLi5Ucnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L3Vmcy9yb290ZnMgW3J3XS4uLg0KZG9uZQ0K Q1BVICAwOiBBUk0gQ29ydGV4LUE3MiByMHAzIGFmZmluaXR5OiAgMA0KICAgICAgICAgICAgICAg ICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2FjaGVsaW5l LFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJHLDY0IGJ5dGUgQ1dHPg0KIEluc3RydWN0aW9uIFNldCBB dHRyaWJ1dGVzIDAgPSA8Q1JDMzI+DQogSW5zdHJ1Y3Rpb24gU2V0IEF0dHJpYnV0ZXMgMSA9IDw+ DQogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMCA9IDxBZHZTSU1ELEZQLEVMMyAzMixFTDIg MzIsRUwxIDMyLEVMMCAzMj4NCiAgICAgICAgIFByb2Nlc3NvciBGZWF0dXJlcyAxID0gPD4NCiAg ICAgIE1lbW9yeSBNb2RlbCBGZWF0dXJlcyAwID0gPFRHcmFuNCxUR3JhbjY0LFNOU01lbSxCaWdF bmQsMTZiaXQgQVNJRCwxNlRCIFBBPg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDEgPSA8 OGJpdCBWTUlEPg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDIgPSA8MzJiaXQgQ0NJRFgs NDhiaXQgVkE+DQogICAgICAgICAgICAgRGVidWcgRmVhdHVyZXMgMCA9IDwyIENUWCBCS1BUcyw0 IFdhdGNocG9pbnRzLDYgQnJlYWtwb2ludHMsUE1VdjMsRGVidWd2OD4NCiAgICAgICAgICAgICBE ZWJ1ZyBGZWF0dXJlcyAxID0gPD4NCiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0gPD4N CiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAxID0gPD4NCkNQVSAgMTogQVJNIENvcnRleC1B NzIgcjBwMyBhZmZpbml0eTogIDENCkNQVSAgMjogQVJNIENvcnRleC1BNzIgcjBwMyBhZmZpbml0 eTogIDINCkNQVSAgMzogQVJNIENvcnRleC1BNzIgcjBwMyBhZmZpbml0eTogIDMNCnVodWIwOiA1 IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KV2FybmluZzogbm8gdGltZS1v Zi1kYXkgY2xvY2sgcmVnaXN0ZXJlZCwgc3lzdGVtIHRpbWUgd2lsbCBub3QgYmUgc2V0IGFjY3Vy YXRlbHkNCkR1YWwgQ29uc29sZTogU2VyaWFsIFByaW1hcnksIFZpZGVvIFNlY29uZGFyeQ0KdWdl bjAuMjogPHZlbmRvciAweDIxMDkgVVNCMi4wIEh1Yj4gYXQgdXNidXMwDQp1aHViMSBvbiB1aHVi MA0KdWh1YjE6IDx2ZW5kb3IgMHgyMTA5IFVTQjIuMCBIdWIsIGNsYXNzIDkvMCwgcmV2IDIuMTAv NC4yMCwgYWRkciAxPiBvbiB1c2J1czANCnVodWIxOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUs IHNlbGYgcG93ZXJlZA0KbG8wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmdlbmV0MDogbGlu ayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04NCmdlbmV0MDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQ --000000000000b3d4d405d3cfe73c-- From nobody Thu Dec 23 14:39:03 2021 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 B2F3618FC420; Thu, 23 Dec 2021 14:39:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JKXrV2Nspz4qsY; Thu, 23 Dec 2021 14:39:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 18074CD39; Thu, 23 Dec 2021 14:39:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 6610243B3D; Thu, 23 Dec 2021 15:39:04 +0100 (CET) From: Kristof Provost To: freebsd-arm Cc: freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: pf cannot allocate memory after a time Date: Thu, 23 Dec 2021 15:39:03 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: <1CEFA3DA-2D46-45B3-ADE6-881A94A4D2E2@FreeBSD.org> In-Reply-To: References: 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="=_MailMate_44FD825A-A4A3-4FF5-A5A9-8E209A467CEF_=" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640270346; 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=rcGL2FhY3AT4HxuXziDCXzcBVhWzlgT0Lmq/cgo4RzE=; b=s16NLDqvWo8BTDsooyxtW25c70mGuxXlVHjP+2YvlP8YI+vId94Lsa5V9QLlijtWlq8eMT GFpisSOG1kSa2s4HMMsMxjfjRUsN6c38Ovl1XqowiW/q3a7Bdb8PAk9nTth4NVd0Nz7WOv Om47LAlM2MOE6SSbAVnEc03jUpM067IrFyzAdj+8p8KCScLqoIE9gmZJywdYqEWi6IgNCu Ak8GoAdldNLdG7fT67ka0PDJyzVrcWvDounefxtt/BMh9V6/kDvNtgsqEKZSzDkZsN+PEv zh7ofz7srtm5A8dyFqdIf8x1yGkqmOgyY4N6+/VcIyfnxxBDRXuDHgNfqi1vTw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640270346; a=rsa-sha256; cv=none; b=kNhj1SrIw4hngntKe4te345sCvz+l/A3bu5JYoVi0rNJLvs4+yrEXEsLwbGZ0K042uROdV vygMVPwRzB3JngflAMw/wlJKqUcilR2TLJZ/EWMmsILL2QlcEvxTbmz2l1DZg5Sn1Roqsu WofbOYkCcKCwQcRy86+3KweQ3NBcrm7rqmaEKFMlfubeLIX8cUdzb7QowME0JsVwOGUboX hNORHy5pZRfYoQponh6JmDkduLSUOeAynspiuCutAER+heVMY11ZfBxr0hsU2Wr5EsfJlF jBsISKjS/cKBza4FNu9ciRwZPWsNRhGE05k7+Q+ZAfv8f2rikZ6/Pn4xNxoB7g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4286 Lines: 104 --=_MailMate_44FD825A-A4A3-4FF5-A5A9-8E209A467CEF_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11 Dec 2021, at 17:14, tech-lists wrote: > context: main-n251261-25d0ccbe101 on arm64.aarch64 (raspberry > pi4b/8GB) … > pfctl: Cannot allocate memory. > See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406 Tl;dr: pfctl fails to add addresses to a table because an uma_zalloc() call fails). vmstat -z output: ITEM SIZE LIMIT USED FREE REQ FAILSLEEP XDOMAIN pf table entries: 160, 400000, 15196, 1604, 36039, 9, 0, 0 We can clearly see the memory allocation failure there, but no obvious reason why. It appears that there’s plenty of free memory, and we’re also clearly far away from the configured limit. Nevertheless the uma_zalloc() call returns NULL. I’ve tried to dtrace that, but ran into impossible results from dtrace (the uma_zalloc_args:return probe did not fire, but the pfr_create_kentry:return did. pfr_create_kentry() unconditionally calls uma_zalloc_args(), so that shouldn’t be possible). Right now the suspicion is that there’s something strange going on with the arm64 allocator (because it’s not been seen on amd64 so far), but I’m generally uncertain of everything, other than it’s not actually pf’s fault that it’s not getting memory. Best regards, Kristof --=_MailMate_44FD825A-A4A3-4FF5-A5A9-8E209A467CEF_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 11 Dec 2021, at 17:14, tech-lists wrote:

context: main-n251261-25d0ccbe101 o= n arm64.aarch64 (raspberry pi4b/8GB)

=E2=80=A6

pfctl: Cannot allocate memory.


<long story snipped>

See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D= 260406

Tl;dr: pfctl fails to add addresses to a table because an= uma_zalloc() call fails).

vmstat -z output:

ITEM                   SIZE  LIMIT     USED     FREE      =
REQ     FAILSLEEP XDOMAIN
pf table entries:       160, 400000,   15196,    1604,   36039,   9,   0,=
   0

We can clearly see the memory allocation failure there, b= ut no obvious reason why.
It appears that there=E2=80=99s plenty of free memory, and we=E2=80=99re = also clearly far away from the configured limit. Nevertheless the uma_zal= loc() call returns NULL.

I=E2=80=99ve tried to dtrace that, but ran into impossibl= e results from dtrace (the uma_zalloc_args:return probe did not fire, but= the pfr_create_kentry:return did. pfr_create_kentry() unconditionally ca= lls uma_zalloc_args(), so that shouldn=E2=80=99t be possible).

Right now the suspicion is that there=E2=80=99s something= strange going on with the arm64 allocator (because it=E2=80=99s not been= seen on amd64 so far), but I=E2=80=99m generally uncertain of everything= , other than it=E2=80=99s not actually pf=E2=80=99s fault that it=E2=80=99= s not getting memory.

Best regards,
Kristof

--=_MailMate_44FD825A-A4A3-4FF5-A5A9-8E209A467CEF_=-- From nobody Thu Dec 23 15:00:15 2021 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 628161900D9D for ; Thu, 23 Dec 2021 15:00:18 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4JKYJx3PLlz4v9R for ; Thu, 23 Dec 2021 15:00:17 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 1BNF0G3B014694 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Dec 2021 09:00:16 -0600 (CST) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 1BNF0FgX014693; Thu, 23 Dec 2021 09:00:15 -0600 (CST) (envelope-from mike) Message-Id: <202112231500.1BNF0FgX014693@mail.karels.net> To: Archimedes Gaviola cc: freebsd-arm@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 In-reply-to: Your message of Thu, 23 Dec 2021 21:06:13 +0800. 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-ID: <14691.1640271615.1@mail.karels.net> Date: Thu, 23 Dec 2021 09:00:15 -0600 X-Rspamd-Queue-Id: 4JKYJx3PLlz4v9R X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.70 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[karels.net]; MIME_GOOD(-0.10)[text/plain]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1058 Lines: 41 > Hi, > I have successfully installed FreeBSD 13.0-RELEASE #0 > releng/13.0-n244733-ea31abc261f in Raspberry Pi 4B with 2GB RAM. USB > devices work well and get detected with the USB 2.0 ports however when > tried with USB 3.0 ports all these devices can't be detected thus will not > work. My config.txt has the following contents. Anything I missed? I also > attached the dmesg output. > freebsd@freebsd13:/boot/msdos % cat config.txt > [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 Is that all? The standard config.txt for RPI on 13.0 looks like this: [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 I am running -current on an RPI4 with a USB3 SSD with that config.txt except that hdmi_safe is commented out. Are you using the boot files that came with 13.0 (dtb, etc)? Mike > Thanks and best regards, > Archimedes From nobody Thu Dec 23 15:55:54 2021 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 7907E190BCCA for ; Thu, 23 Dec 2021 15:56:04 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4JKZYJ2mGJz3KsR for ; Thu, 23 Dec 2021 15:56:04 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x531.google.com with SMTP id x15so23203139edv.1 for ; Thu, 23 Dec 2021 07:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WShFiQz8BHpQUXqVk+upr0JjpEZf0g5MhPMKajUjDvA=; b=IAjMm/ws6EvbNUaHbbMrxLX09EGNY/b0MPb2XiTOOHE1yPR94K4M/UOr5WBco0C6vk cbFVSOclH26RhNgGN/zm/r7JXjpNFCRm+8I070gt6w7oBER9LL7xCvSiJB3+bPjncDqJ y3Il3JAUt/7zZsfUGOlBek0k7RzjZF1lUTuFtwj/jyBSr6+FMwjP0fM566KSoOWeBWoz 8BEDjA9R6zgzbje4zSwvbwWC/yHZMW7aNKPsUxYRwvaRW1MSvRSD3VI2+QcjCnWj6BbK JI3YWqdxAuiEH+eIfFE/7RfNxr+4QyInzLx+8TBR1EGkggAAx88Of98z5koe2WriHiDr Ycfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WShFiQz8BHpQUXqVk+upr0JjpEZf0g5MhPMKajUjDvA=; b=JAnAd/hGJG+90+0wRFUBXb1tcrGyWKCdsn6+Smaj2vEvgjqvl3dHF11Qu3DeEwc3SI JlgpOODAnF5d/K0rJAkr19/h7YKvsa6vcplwyD4leUcHiPrnjCZ8NH3GJRlK+NKYkGl0 A803Mxl/mPSxDhwtnEy8wXSHvgUhEPc338HlovJe2+p1g4Q/hqr2kACDmhyw1XV5Vl9/ tHyfj2Pao7IxB1UcEmeFm/aQ1XVlT4PDTeVdiXkBwgSAHQsOi7YlOH+2JGUFg+XuyZzZ GSy0csqCA4pF/wzrD8ve7KLuyqWIi2m6DmHpytxiSUgXUvyiedeUd3agBKft8xr3sFZY xvkg== X-Gm-Message-State: AOAM5309TM9m7xrUEwr/OQLu+LpmaA/9Rt4eeedSIAOt4fu1g4tmJeqk k+6+LPIerr1P5owI2DsyDYa2rz0ml1osSBjfg/tZdqIdM2E= X-Google-Smtp-Source: ABdhPJwncMDBYpWheREYAAWAfOHbtthmBU0SRXe03U2MM7cBLUFmqT2lAzA0Oy2w35vQ/IpjC597OPvIH8mlej442v0= X-Received: by 2002:aa7:cb81:: with SMTP id r1mr2536679edt.352.1640274963427; Thu, 23 Dec 2021 07:56:03 -0800 (PST) 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: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: <202112231500.1BNF0FgX014693@mail.karels.net> From: Archimedes Gaviola Date: Thu, 23 Dec 2021 23:55:54 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: mike@karels.net Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000087745905d3d24665" X-Rspamd-Queue-Id: 4JKZYJ2mGJz3KsR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6059 Lines: 172 --00000000000087745905d3d24665 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 23, 2021 at 11:00 PM Mike Karels wrote: > > Hi, > > > I have successfully installed FreeBSD 13.0-RELEASE #0 > > releng/13.0-n244733-ea31abc261f in Raspberry Pi 4B with 2GB RAM. USB > > devices work well and get detected with the USB 2.0 ports however when > > tried with USB 3.0 ports all these devices can't be detected thus will > not > > work. My config.txt has the following contents. Anything I missed? I also > > attached the dmesg output. > > > freebsd@freebsd13:/boot/msdos % cat config.txt > > [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 > > Is that all? The standard config.txt for RPI on 13.0 looks like this: > > [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 > > I am running -current on an RPI4 with a USB3 SSD with that config.txt > except that hdmi_safe is commented out. > Sorry, here's the complete config.txt file that I have. I removed hdmi_safe=1 into hdmi_group=2 and hdmi_mode=14 since I used the tty console for display. [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_group=2 hdmi_mode=14 armstub=armstub8-gic.bin > > Are you using the boot files that came with 13.0 (dtb, etc)? > Yes, I am. I have not changed anything that came from 13.0 files, it's all intact since I wrote the image to the microSD card. To be specific with my USB devices, this is an input and an output device. I have an RFID card reader and an Epson TM-U22B USB printer (self-powered) which are detected and work well with USB 2.0. Below dmesg log shows the drivers of my printer and RFID card reader. As soon as these devices are transferred to the blue-colored USB 3.0 ports these drivers will no longer show up in the dmesg. ugen0.3: at usbus0 ugen0.4: at usbus0 ukbd0 on uhub1 ukbd0: on usbus0 kbd1 at ukbd0 uhid0 on uhub1 uhid0: on usbus0 > Mike > > > Thanks and best regards, > > Archimedes > --00000000000087745905d3d24665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Dec 23, 2021 at 11:00 PM Mike Kar= els <mike@karels.net> wrote:
> Hi,

> I have successfully installed FreeBSD 13.0-RELEASE #0
> releng/13.0-n244733-ea31abc261f in Raspberry Pi 4B with 2GB RAM. USB > devices work well and get detected with the USB 2.0 ports however when=
> tried with USB 3.0 ports all these devices can't be detected thus = will not
> work. My config.txt has the following contents. Anything I missed? I a= lso
> attached the dmesg output.

> freebsd@freebsd13:/boot/msdos % cat config.txt
> [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

Is that all?=C2=A0 The standard config.txt for RPI on 13.0 looks like this:=

[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

I am running -current on an RPI4 with a USB3 SSD with that config.txt
except that hdmi_safe is commented out.

Sorry, here's the complete config.txt file that I have. I removed=20 hdmi_safe=3D1 into=20 hdmi_group=3D2 and hdmi_mode=3D14 since I used the tty console for display.

[all]
arm_64bit=3D1
dtparam=3Daudio=3Don,i2= c_arm=3Don,spi=3Don
dtoverlay=3Dmmc
dtoverlay=3Ddisable-bt
device_= tree_address=3D0x4000
kernel=3Du-boot.bin

[pi4]
hdmi_group=3D2=
hdmi_mode=3D14
armstub=3Darmstub8-gic.bin
=C2=A0

Are you using the boot files that came with 13.0 (dtb, etc)?

Yes, I am. I have not changed anything that came from= 13.0 files, it's all intact since I wrote the image to the microSD car= d.

To be specific with my USB devices, this is an = input and an output device. I have an RFID card reader and an Epson TM-U22B USB printer (self-powered) which are detected and work wel= l with USB 2.0. Below dmesg log shows the drivers of my printer and RFID ca= rd reader. As soon as these devices are transferred to the blue-colored USB= 3.0 ports these drivers will no longer show up in the dmesg.

ugen0.3: <EPSON EPSON UB-U03II> at usbus0
ugen0.4:= <Sycreader RFID Technology Co., Ltd SYC IDIC USB Reader> at usbus0ukbd0 on uhub1
ukbd0: <USB Standard Keyboard> on usbus0
kbd1 = at ukbd0
uhid0 on uhub1
uhid0: <USB Vender Hid> on usbus0
=



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike

> Thanks and best regards,
> Archimedes
--00000000000087745905d3d24665-- From nobody Fri Dec 24 02:48:27 2021 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 D575D191B94D for ; Fri, 24 Dec 2021 02:49:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (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 ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JKs2z2CKhz3MpQ for ; Fri, 24 Dec 2021 02:49:14 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1BO2mcXC022505 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 24 Dec 2021 13:18:57 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1640314141; bh=dFRv00/YmUK1EZEvpSTwUvvYrdocp606wf75ETWuQ8M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UPCAw8LbAed7u7iwAqYnpRH2HfEoQ9yRbF86GZcK/h0qlrjIksYBjFBybmpK5rrm8 hJVaR5eC4nenYOnU87D4daE2u4aagZgdimoA767ZUa1vpLrUo4gZCS1iyzVJZYklR6 RKR9BU1rdr1qs/sTpFcG6IjNbeZfmuVgRHzCR+3c= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 1BO2mSjt022486 for ; Fri, 24 Dec 2021 13:18:28 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:58eb:98d1:dc78:fecf Received: from smtpclient.apple (2403-5800-5200-4700-58eb-98d1-dc78-fecf.ip6.aussiebb.net [2403:5800:5200:4700:58eb:98d1:dc78:fecf]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1BO2mSJG022479; Fri, 24 Dec 2021 13:18:28 +1030 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 In-Reply-To: Date: Fri, 24 Dec 2021 13:18:27 +1030 Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202112231500.1BNF0FgX014693@mail.karels.net> To: Archimedes Gaviola X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 0.8 () No, score=0.8 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JKs2z2CKhz3MpQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via freebsd-arm X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1764 Lines: 53 > On 24 Dec 2021, at 02:25, Archimedes Gaviola = wrote: > Are you using the boot files that came with 13.0 (dtb, etc)? >=20 > Yes, I am. I have not changed anything that came from 13.0 files, it's = all intact since I wrote the image to the microSD card. >=20 > To be specific with my USB devices, this is an input and an output = device. I have an RFID card reader and an Epson TM-U22B USB printer = (self-powered) which are detected and work well with USB 2.0. Below = dmesg log shows the drivers of my printer and RFID card reader. As soon = as these devices are transferred to the blue-colored USB 3.0 ports these = drivers will no longer show up in the dmesg. >=20 > ugen0.3: at usbus0 > ugen0.4: at = usbus0 > ukbd0 on uhub1 > ukbd0: on usbus0 > kbd1 at ukbd0 > uhid0 on uhub1 > uhid0: on usbus0 For what it's worth I have successfully used USB devices on the USB3 = ports with FreeBSD 13 on an RPi4: ugen0.1: <0x1106 XHCI root HUB> at usbus0 ... uhub0 on usbus0 uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on = usbus0 ... uhub1 on uhub0 uhub1: on = usbus0 uhub1: 4 ports with 4 removable, self powered ugen0.3: at usbus0 ugen0.4: at usbus0 ukbd0 on uhub1 ukbd0: = on usbus0 kbd1 at ukbd0 I have also used a custom Cypress FX2 based board on it with no = problems. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Dec 24 04:32:41 2021 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 094EB19048DD for ; Fri, 24 Dec 2021 04:32:52 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4JKvLW6bhRz3nLS for ; Fri, 24 Dec 2021 04:32:51 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x534.google.com with SMTP id z29so29018519edl.7 for ; Thu, 23 Dec 2021 20:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yNBR9KNKT6svpQi1JBgLnSbtontEoGKwz+drMdfoiN4=; b=XPGK4PqrUmoa3X3HT3O3vaPWNPR1RZnnMNIRfDEWmHT+qD7V+USKBw1dkOM3rAhohd LnDqSSXjJBR0bdw9IEhTDtGemolsT5YAqldabW91KBhfM9ZkB4AVQI11nP6JspcNk+AB 6ghB1d6gPmndrmz1QzT22UDv5xM9+/YyKnrnetNE0D5GSISCK10NK6oy7dw09GjhIOh5 j3dWvRFWffZCzSIEnr6NhrK/sFHrAkjzFhx0CR/ayFLR8WhuHGuslTLTKN3qKi6kU3oL 9S614RWcOfhDnMrtb02HF0afQr9gruqcSLkAHKDvZwgcCWZ7Hdc793aFkXZNYLQmAT3G SsRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yNBR9KNKT6svpQi1JBgLnSbtontEoGKwz+drMdfoiN4=; b=vySc0m/GRDUrMrD5WXwBzGY9xT2EnuMEYl0OszdJ6cUhSlw34pOYIwhYqL43cDLYxz 3n3cbz+wVlgs441tc3iX7n5alDMbYiqlKZoE4DPtARHSXKH6d2hxChiVJ9YqU9YYLT1W ra+VY6HZMo1ormGWsj487meg1ux/Y1iBjca6B3n2nB+6AmsLQxWpn9T15P9NnTUuA26S mTQVZgz3DB8GWDMrX8u5YACpLJM4Z+e7lPyL6BI+Rdh7zDQrtmZAGR77MZIE4Sq/5Rt0 iaLwBRhoq/m5l7129IoNOFvkdQYjVhQDphoNhxeePUGbUbMNKQzOhJVzEIMBwkGThQfn /POA== X-Gm-Message-State: AOAM531nXkfEcyh6ET+haR4V1B7ZJtYbAaUxyDucaG8eFfa4P4l7Pe6s /l8V8IPVjIfh5o3+iOEd/sPtHtxvNZeBkfHfrn2iSeZYub4= X-Google-Smtp-Source: ABdhPJx2tcekVHe5taQYrXoPLUN8Br73+/vFpxN+opDhcIqWiLriYZmZVpRNwB4XpGDz/OWlFczBrpf3GB8ectEQ/as= X-Received: by 2002:a17:906:990c:: with SMTP id zl12mr3963715ejb.370.1640320369227; Thu, 23 Dec 2021 20:32:49 -0800 (PST) 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: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: From: Archimedes Gaviola Date: Fri, 24 Dec 2021 12:32:41 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: "Daniel O'Connor" Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ecfa7a05d3dcd87a" X-Rspamd-Queue-Id: 4JKvLW6bhRz3nLS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5190 Lines: 130 --000000000000ecfa7a05d3dcd87a Content-Type: text/plain; charset="UTF-8" On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor wrote: > > > > On 24 Dec 2021, at 02:25, Archimedes Gaviola < > archimedes.gaviola@gmail.com> wrote: > > Are you using the boot files that came with 13.0 (dtb, etc)? > > > > Yes, I am. I have not changed anything that came from 13.0 files, it's > all intact since I wrote the image to the microSD card. > > > > To be specific with my USB devices, this is an input and an output > device. I have an RFID card reader and an Epson TM-U22B USB printer > (self-powered) which are detected and work well with USB 2.0. Below dmesg > log shows the drivers of my printer and RFID card reader. As soon as these > devices are transferred to the blue-colored USB 3.0 ports these drivers > will no longer show up in the dmesg. > > > > ugen0.3: at usbus0 > > ugen0.4: at > usbus0 > > ukbd0 on uhub1 > > ukbd0: on usbus0 > > kbd1 at ukbd0 > > uhid0 on uhub1 > > uhid0: on usbus0 > > For what it's worth I have successfully used USB devices on the USB3 ports > with FreeBSD 13 on an RPi4: > ugen0.1: <0x1106 XHCI root HUB> at usbus0 > ... > uhub0 on usbus0 > uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > ... > uhub1 on uhub0 > uhub1: on > usbus0 > uhub1: 4 ports with 4 removable, self powered > ugen0.3: at usbus0 > ugen0.4: at usbus0 > ukbd0 on uhub1 > ukbd0: on > usbus0 > kbd1 at ukbd0 > > I have also used a custom Cypress FX2 based board on it with no problems. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > Thanks Daniel for sharing your experience with your RPi4! My next step will be to secure another board (with the same specs) and check if it behaves the same. I'll burn another 13.0 image to further verify just in case it still fail. --000000000000ecfa7a05d3dcd87a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 24, 2021 at 10:49 AM Dani= el O'Connor <darius@dons.net.a= u> wrote:


> On 24 Dec 2021, at 02:25, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
> Are you using the boot files that came with 13.0 (dtb, etc)?
>
> Yes, I am. I have not changed anything that came from 13.0 files, it&#= 39;s all intact since I wrote the image to the microSD card.
>
> To be specific with my USB devices, this is an input and an output dev= ice. I have an RFID card reader and an Epson TM-U22B USB printer (self-powe= red) which are detected and work well with USB 2.0. Below dmesg log shows t= he drivers of my printer and RFID card reader. As soon as these devices are= transferred to the blue-colored USB 3.0 ports these drivers will no longer= show up in the dmesg.
>
> ugen0.3: <EPSON EPSON UB-U03II> at usbus0
> ugen0.4: <Sycreader RFID Technology Co., Ltd SYC IDIC USB Reader>= ; at usbus0
> ukbd0 on uhub1
> ukbd0: <USB Standard Keyboard> on usbus0
> kbd1 at ukbd0
> uhid0 on uhub1
> uhid0: <USB Vender Hid> on usbus0

For what it's worth I have successfully used USB devices on the USB3 po= rts with FreeBSD 13 on an RPi4:
ugen0.1: <0x1106 XHCI root HUB> at usbus0
...
uhub0 on usbus0
uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on us= bus0
...
uhub1 on uhub0
uhub1: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> o= n usbus0
uhub1: 4 ports with 4 removable, self powered
ugen0.3: <PixArt Microsoft USB Optical Mouse> at usbus0
ugen0.4: <BTC USB Multimedia Keyboard> at usbus0
ukbd0 on uhub1
ukbd0: <BTC USB Multimedia Keyboard, class 0/0, rev 1.10/1.00, addr 3>= ; on usbus0
kbd1 at ukbd0

I have also used a custom Cypress FX2 based board on it with no problems.
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
=C2=A0-- Andrew Tanenbaum

--000000000000ecfa7a05d3dcd87a-- From nobody Sun Dec 26 19:23:38 2021 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 846131918B28 for ; Sun, 26 Dec 2021 19:23:47 +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 4JMW1Z2svTz3pmS for ; Sun, 26 Dec 2021 19:23:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BQJNdCI016257 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 26 Dec 2021 11:23:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BQJNdco016256 for freebsd-arm@freebsd.org; Sun, 26 Dec 2021 11:23:39 -0800 (PST) (envelope-from fbsd) Date: Sun, 26 Dec 2021 11:23:38 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Hot-plugging microSD on Raspberry Pi under FreeBSD Message-ID: <20211226192338.GA16188@www.zefox.net> 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-Rspamd-Queue-Id: 4JMW1Z2svTz3pmS X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.97)[0.971]; DMARC_NA(0.00)[zefox.net]; NEURAL_HAM_SHORT(-0.91)[-0.913]; NEURAL_SPAM_LONG(1.00)[0.998]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 489 Lines: 13 Are there any special protocols to observe when hot-plugging microSD cards on Raspberry Pi when FreeBSD is up and running? Electrically it's claimed to be ok in this thread by one "jdb": https://forums.raspberrypi.com/viewtopic.php?t=281249 so I'm asking about how the FreeBSD software might react. Obviously filesystems have to be gracefully unmounted, but is that all? Can the kernel be "aware" of an unused device and get confused if it goes away? Thanks for reading, bob prohaska From nobody Sun Dec 26 21:00:38 2021 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 C2369190C8EB for ; Sun, 26 Dec 2021 21:00:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JMY9Y0Hjcz4XPl for ; Sun, 26 Dec 2021 21:00:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640552528; bh=rMsNC8vE+dgO6VAN9H/E6GRCO80Sue9earSQA086fGE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GnyXwRtkfHr7V56L6NRTuGSFn4D2GRXU3tnh630wIeX6OuMvwl3juDrdJPapyGt4o3742nxNYw6hLnDRT2sKOd2qEl3R5a4Mwh2rkscSmQT2UyLKBwoGZ2nH0NrnOAEyASoXJ9oSsqNe3P7t8+JmvZv3Nr8YGGhuNMhyznF8shftJAY6dmy5kIBVDcaxnhjRGMf1C/f+uvmBAzxQ5s4SBSaIUSCxwq0PqGOUGA3+GPUQ1tBKbokzCl1m3Nz+cCKUnEzwxXX0nUFFvF6IvbM5wVvbRCnOJH0MHZUNMudzZQDim97yCEFSdWmW6qZWgwuuLhm5RyjD/y8/UHARJ9kT6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640552528; bh=wu9MeiD0mLmkd3+GuMDxwGgWU3OFH3Br4oyAnNQLzA1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=g4pSJ/HitTmZGuaMVSLxmlJXjui/LnvhwA8Or8YvN4+5G2PgMYuCD9qfljSlGWd1j7TsfBSxYh2pDITMuVDBJ9n6s2op5O3ZYGnnR2f8a8zQP8hC20nTKzkod5KPE9USkz7/3wrPpb2jnuIXGWrPN5JgNiuGdFj5LoKryXYPmWpjiDGIonIV9hkGbJtrtyFHTRPj1wWAtmR0+/wtknhObJBNR0LmEWksuuY2AtzQJ5yDIe4cHtT8YZm6ie+EwjE8RhsP5i05sjg6eHeV3BdAjm4IdJgjMP8QOUlU9sjqcNLq5BcSu0mt3Yk2VHlqKrzzf3JgvvjadfvnrBH7WW06Pw== X-YMail-OSG: rQaZqeYVM1lYAWP7csqLYl_ylFdaoLNj2zJVytM8xNlBBPOSk6w3vYHY8ENy.aT 9OI3xBnDl9gGeReB_EkILgordVfTjDixlkpqbItaHJeg9mq5kZEmp6HJEJWpzbQDapgYVi6MS3Yc syJd7as.i9TMtt2XuTCiv612G1TwwHGQlWqfJ8sT2soAYG97LgWkudDK9XnRWNOE5FhOcH1b4jyh FiBRovF4FuxqycRUnLSwFgRfBF3ZPHOSj5NsAHx0NrUWD1X8lKKsvuG7Ebz6Pui1uB0Wpvmp6SKs 2Tr0OUsfhS7GvxUv66A0GSN9u6cC2WjIDE.ePkwFun9rkhuJbrw8KbdT8lkxjDngkm94FgSImu02 y94cpMFxLlsGOoQoInKa6ISnrmNmRLfNiuVL45jbTnfYwETw0f10YhAdAu5TMMXvT7KgugDhhpYc 7ujZeqrx3H1zV8UPHWJtJ2zSXlSxY89Tb7gA63EXDEcpW.fwUoxRTSyJvGGnfdNfFeCOwKntfb7K ufQwXVVMAbYS8iYu9AobzVfk6SuhI23IShLVt7stQbZzCIUr0cCrgY1PdOMd.2.JVbd3kPjS0Bj6 uID3Aq812xJ3Ue3C5IOHqdixbsufartKehgSnDH9tZvNK0U2PpTlz6Mf.wHCNoQhVbImMVAiHffH B2XlOezDqrjl4J7Rp7d_WKsMk7DA2aWlAajnh1k6QkBpWPIzk6YZkYA7fKRfiF6HH9aBxjP55oC4 3eVmD3_1QzTTARCSSQ4o.88n92K0Nz_TH0Ibc7xG58UpA86_LGRvxABRzFIX18iWlAtd4WuJQkUp vKkQOfBbZBiZOyspOFQXz9IKzmmCH5yM55gYzXbPF0ixs8FTm3S9zWVwnpMlH75B9kiBIqNnDUcr bMUZhs7zK4f10dA00n3X8hQXZERhcSeq4sFPdVZZHfwIndCiRjjc7e5uL3MW3dNxdEUbwI9do5Vx dSSDSpPHalimL89BCMCxw9_ai6ZxuzfVx_M.dk.BXLBiK7zeKJYcWW7zGGHDLNk66Dq7YzoqMykv jMfsbxu2tVBypWqkvVUoIyPH6wjKgVWoEOPp76aOKQZxDYz.E_svyamNP6JxM2JOrvEJtDB6IHNp V7i23OG71rvncodzSQNQQ77nr67_IBHcJDYk2ICkL.AqStZZUp_6FCIprnS3HADcPp9cnGOvujnw Lq4YZizh09xCYx6A4ygrqWJMsPxM1CJU.T26P7y_M26v8CA8q5BC3Le6xRPhHu8qAy57YavGP0Jv cu5G5TTsnzvjU2NedzLQCp0HA2gQrtCeY2nl4EXptSomb.y8VDaF94lJJjv6LqE2wC0tIquCPfGC UWdRC0GXRzoIUIZkDn_6XlDzXn6_u.cTtQnRZad_GtjcIw3xCoPLTuvq7pwl6j7o5sTNORGU4jd. yLE2jYD1LMCyAEgtWco6zMpb1c3ztGkmoo2ypcOSznwevRaHAx8NRRTEFJ4y_unqCPaERNEBVJCa SZfW5y1DZSJANKN8CfhizkROVcjtWAuQoNvqH0yo14BCjB.wd29S0dVlh1nlDLj72uaaIOiuUf74 lJg9hZmz7.VfTLznsMHyfEi9oAo9qXk8ZdS4Q0uCXBfuN2FOIOKDLxzGzx1UzCkigy9xRFlwwE5d NZBvWBqupbr.OEsbN0zm.Y.Kh2jVZKnMV2_gjqvXJNU.aEv1PwlwfmNXz8QRwOKgNa5iOT2f2wM7 910lPANHKOHsc3gB2yVKzobvWkiGHITbtdLkNe.B9uKulQ4RrGUPNoPiZlpn8r5f1Pm55sdr.sxg FMzleyjTiD8om1r.qmTomehWQL.bHKqZ1eEMt15vXpbXKEwK6YpmIQispx8duQzFVQAatO1Pu5_C amEfN0kJs76B8j_ZFgYFyX_OT2zIyqNj2lM9lbFaENb3SoxRDRVR9SMjqgEa7UyTcU2qsqlCpnq. m2SkdS7ZdmieI3IZxOsDSYIygzhK478ROny2v0545V4OK4D.9H71HkV4lHXckF4Rd8SdNJCb3vfW bNR0X79rYwVFEPixuf_d3AB.V6ccsSFAOiZhWD0ISGRBoHW3hLdONGORXHyIsUF_XOjgFmCZl7w6 irnvWvxBbkkmep37bfjNULFwxB.MEWmH83_31PfsQ7VPb7jQerbXZFK8FzKflg9SVelpMGsXQuvu 7bCgsuT2E6ePiWZ7_jq7k6t069.zysd2YUpJkNmqdciA_epdPKgCxlfTbFt3LoN_iaA07k5InnJY 8wI_dnGs8E2ONt.umhQe5kOcNyHzq4asL7AtbD_LLVODIKv2no5.XcF5791T29QRaIg6jXdtOdIb GidDi2E7uENcl0XXyOw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Dec 2021 21:02:08 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 82ed07590b77e0ee06c29858134227b9; Sun, 26 Dec 2021 21:00:39 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD In-Reply-To: <20211226192338.GA16188@www.zefox.net> Date: Sun, 26 Dec 2021 13:00:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> References: <20211226192338.GA16188@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMY9Y0Hjcz4XPl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4889 Lines: 111 On 2021-Dec-26, at 11:23, bob prohaska wrote: > Are there any special protocols to observe when hot-plugging > microSD cards on Raspberry Pi when FreeBSD is up and running? > Electrically it's claimed to be ok in this thread by one "jdb": > https://forums.raspberrypi.com/viewtopic.php?t=3D281249 > so I'm asking about how the FreeBSD software might react.=20 >=20 > Obviously filesystems have to be gracefully unmounted, but is > that all? Can the kernel be "aware" of an unused device and > get confused if it goes away? As I remember, for FreeBSD, A) The built-in microsd card slot works fine for swapping media that are not mounted at the time. but, for example (no mounts involved, RPi4B 8GiByte test context), B.0) Plug-in the USB reader, no media present. (USB3 example here.) B.1) Insert a 128 GiByte media to the reader. B.2) Remove that media. B.3) Insert a 32 GiByte media to the reader (same slot in the reader). Result: (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af c1 00 00 04 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af fe 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af fe 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20 (da4:umass-sim1:1:0:3): CAM status: SCSI Status Error (da4:umass-sim1:1:0:3): SCSI status: Check Condition (da4:umass-sim1:1:0:3): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical = block address out of range) (da4:umass-sim1:1:0:3): Error 22, Unretryable error GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert = them. GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert = them. GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert = them. GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert = them. GEOM_PART: da4 was automatically resized. Use `gpart commit da4` to save changes or `gpart undo da4` to revert = them. If you do the 32 GiByte first instead, then for the 128 GiByte you get notices from GEOM_PART about "was automatically resized" but it does not "address out of range". I expect that swapping two media of the same capacity would be less likely to generate any messages, but that does not mean that such a swap would be handled fully correctly. So I unplug the whole reader to swap media. This is messier if multiple slots are in use (more unmounts and later remounts). I expect that this is a FreeBSD issue, not a RPi4B issue. But I've not tested such under Fedora or the like or (recently) on a Rock64 or other such. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Dec 26 21:01:45 2021 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 0562F190E045 for ; Sun, 26 Dec 2021 21:01:48 +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 4JMYBf2dTyz4YhL for ; Sun, 26 Dec 2021 21:01:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 E98BD11A8F for ; Sun, 26 Dec 2021 21:01:45 +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 1BQL1jH3023173 for ; Sun, 26 Dec 2021 21:01:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BQL1jPm023170 for freebsd-arm@FreeBSD.org; Sun, 26 Dec 2021 21:01:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202112262101.1BQL1jPm023170@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, 26 Dec 2021 21:01:45 +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="16405525051.c60F0.18344" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640552507; 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=eWsP+La7Nbzgc+/Yjvzq9HzSyyRqsVCSqqsKprjonk8=; b=tNjhNmzAygBC/I/Nwd4wqucyvjojItp2Hnf8ZBRx+5FC4pNjExmDGdmsrsk3fkVgrJgDAa vg+EQqy5HqoMZHrkTKY3l4M2G+mBFl+aWfmGpJ3Udb6PDLljbBsTJ4FQ8HK5a3Y8ZawRAw 0WpkXTeGoup2TDwFzhVWuEjK98ZFLXeVld/LZDQ/49AULoohfzTTQECFWGf0lV5K5rpuP6 8d6VtYFYIHGvzHwsYMpY8B9YDH8qkZ1Vs9WnbYPP0kr0CUaeB0iNG0fpGnY3r7+Rx/4XTb D+3IsFdHYW0dM+R2cmksUwB+oOHUxwZmkDmBs5REG+x5blUF1lkvsKV10Xuvxg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640552507; a=rsa-sha256; cv=none; b=QDSXNKGjcdpEoiMkgXzxshrRvgtGvRo0vuhRYYbfNoy8zR1qyb4kFFONBRgnwr+mvpo80B dKAImWQtYPIlW6v9217cd64N7lnaxAeHrnUcPUcQUKVemMRKXmpSS4NWvSwhgVSHfx02F+ EBE0DfLFHTNgviZi2Inx9RKw+pDcQv/rma0XYhcBCxempoorawN8ov138jeZJFmEBjs6Te LrYdhh1Hlif9L4shxns81xNLyQTaZ9sbNdbGfjUXpdB+WpxPTGq3orosKY3/5P37kWRsfz S98Osx8OG+PMPejQpbtpO6pQMSuMPw6p+tIpsUgcUx58RlKUHOr6Cbi/AUBoQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1798 Lines: 38 --16405525051.c60F0.18344 Date: Sun, 26 Dec 2021 21:01:45 +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. --16405525051.c60F0.18344 Date: Sun, 26 Dec 2021 21:01:45 +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.
--16405525051.c60F0.18344-- From nobody Sun Dec 26 22:47:09 2021 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 EEC921920F26 for ; Sun, 26 Dec 2021 22:47:11 +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 4JMbXH4gp1z4pKc for ; Sun, 26 Dec 2021 22:47:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 1BQMlAvx016907 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 26 Dec 2021 14:47:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 1BQMlABS016906; Sun, 26 Dec 2021 14:47:10 -0800 (PST) (envelope-from fbsd) Date: Sun, 26 Dec 2021 14:47:09 -0800 From: bob prohaska To: marklmi@yahoo.com Cc: freebsd-arm@freebsd.org Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD Message-ID: <20211226224709.GB16188@www.zefox.net> References: <20211226192338.GA16188@www.zefox.net> <91D4CF6B-5690-413D-A873-2DB50CAF9637@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: <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> X-Rspamd-Queue-Id: 4JMbXH4gp1z4pKc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2069 Lines: 61 On Sun, Dec 26, 2021 at 01:00:38PM -0800, Mark Millard via freebsd-arm wrote: > On 2021-Dec-26, at 11:23, bob prohaska wrote: > > > > > Obviously filesystems have to be gracefully unmounted, but is > > that all? Can the kernel be "aware" of an unused device and > > get confused if it goes away? > > As I remember, for FreeBSD, > > A) The built-in microsd card slot works fine for swapping > media that are not mounted at the time. Ok, that's reassuring. I observed corruption of microSD card FAT partitionss and wondered if hot-plugging might be the cause. > > but, for example (no mounts involved, RPi4B 8GiByte test context), > > B.0) Plug-in the USB reader, no media present. (USB3 example here.) > B.1) Insert a 128 GiByte media to the reader. > B.2) Remove that media. > B.3) Insert a 32 GiByte media to the reader > (same slot in the reader). > > Result: > > (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00 [...disk errors snipped....] Was the Pi4 running from a USB hard disk? I ask because plugging in a USB reader to my RasPiOS Pi4 while booted from a USB hard disk seems to disrupt communication with the boot drive. It doesn't crash immediately but can't be gracefully rebooted. > If you do the 32 GiByte first instead, then for the 128 GiByte you > get notices from GEOM_PART about "was automatically resized" > but it does not "address out of range". That seems like the "confusion" I was wondering about. The kernel notices the first card insertion, fails to notice the removal and then mis-attributes the change to a partition resize. > I expect that swapping two media of the same capacity would > be less likely to generate any messages, but that does not > mean that such a swap would be handled fully correctly. > > So I unplug the whole reader to swap media. This is messier > if multiple slots are in use (more unmounts and later > remounts). That chain of events crashes my RasPiOS Pi4, at least when it's also booted from a USB drive. Thanks for writing! bob prohaska From nobody Mon Dec 27 00:40:23 2021 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 98D4B190C89E for ; Mon, 27 Dec 2021 00:40:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JMf382WBYz53KT for ; Mon, 27 Dec 2021 00:40:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640565629; bh=p/aixQiPZmidCpIUtTZ4EqwH8FqoUkIJjDH3ZwnAI8E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Qt3FSpcdSd8g/DzLNAHexYTCbrlK8Abc8xPUfJmLc78kkkJ/Cmz6mlkahe1EFiFGbZZyJPHQgnHdDVp1w+iX94MMjZ1rrE6gnQZvZdWGZ3E9f/xEPoZrxS3phTM0hronNjEjjBDwb3BhdNDc98l5jT2xpXq7NH4GwojSf1Z5JiKCHsvLFVdHIFnrM/uVwntUUXB9AbSlmq7WZYo/15bqiRlH/GFVrjWRvGrfQl8R1hs5QBYYZ3jf5Qw5aBf7XLjCPFgRLV+8BBCb489kwdh8QhjTAms087gb20wiKJliElgW9HiPGq5UA7AqUs6TVECSvljDz8qFDfMW2jCSi/FZ4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640565629; bh=uKEthgV0WvTjxeFnAABz+rG02x2GjJlWoVcaEvZb0tx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r2+P/5oxJ2mMNlPb3ZxOuNmXkMl6vR9xYS544Qw4BxJQbKwdVOk1Lu2E1NsU9Vk4FklBh1i73Lbj0Q1zU5DaWe/eGUEvARj2SEYYhxIoEnlxEn4MlYz8aiaDtFsdWuahEO+GVy68vTY3jDfBnhIyw92Z7xFt2WpgeTNal2kMw0f2IIXe44ZIoyFcHZi/byGHoANGYi9L+TNzrejmFj4MriUP6VJN3jDOKBZ65b50+/gTVBnDAAc3oOI68pnClXb77w+0HWRptfQAR7kANGkkbD9404QnqCdA8wijSunmK6TfPQI1f1dzH6x6fpsHxdjIgUwqHua3T4XvfposkXamUQ== X-YMail-OSG: 2z6YXRMVM1migW7xa4CDEysEmd8fb8jU3qw7sDwGs1ihfWsSCIY9vy3Ws3PbHEZ F7Uw3jDj02AnLPc.Ussb.xsKBMesh_D1nI76Va1VbnqPVDEvnR2kK0MqjU_tuRLvkkf47Q7EuFY1 L3SDq1c3ErwjO94mumt83O0RAR8Exhymyexz46Ior3fQDNybjEtCD3ZbEvaICbtM2AVTw1eKkGb9 uhegst3lm.5iOlvEESUhSl9lnVI75vjXkUQ73VZpJzzZPbxijCH4UAixmpOjEZ.YwqObYZ53PXL2 ogedaYmsl1LmmKmTyAFw6ZuAmLn6lx249F0eFE0QgDSgcrZgg4PdYBFXyo211bat00wqiHBIR6mz 8U_KXCyycFMM7VjIxVoJ5GHmhpX3OnOigM4fyXu8l2P91UJclxGN6FxgscoiykAy7I8Q36eXsaDF ZCKGgCkWErXzfygA.i6H.LgOiu3fXyFyC7X4JaGnqWCSgZOyEB7QoHeY6UW7ZsekTyX85Jq4798K c8l0NqR9LkaV6YEb.pHy.uYG7ERm5hlyfXlnfkcrAwOjli2j.yn97kxYT2c1cluS_jVY2N05GPSh HbmQSMLjkw9_EbV38iafHslVEZW_pqDLk3HnA1zcYrtasREHCmDM2WKznsShvoPa7oMVsNxb8nHK x3HDXs0dXFkYFMji8W7yVMxMh914sryHlWt8ykYcdI._uHtJaghLF81dsxL9PaNRCrGHmbG_Agc7 _zS2.3mSrUdAvdh5Bp4j0NY7d.huP99S1ITeyIanXIYISbdlpwXE6grSoxyie7S.sANVKUmNjl1X tWnGBJRoyA8eSpJOdzkVOoHdPITsMYCx1Abzs6qaS9LQiVw1gA0k4ny0UVJbZQNQxYnmehb6jJ7d ROpjhc9emFd.euKxj0NWtB0vbN854nAuIxPp79P4ngfCsbLR43wFBCOvY0qQRZ9F4m_pe3rV_2kR xi0cG.eVi_IVy4jizipj64XXeVMj_bD0NIDVl3KbeOOsMrG88PpcPiHhmXKGqP6DyiDsQjb7eSPk LjGEt2KHzInd8tW.2hNZ_hDyoFwZv3Ckin7qC0U14m48PQZjm7kv6V7x3oG6sMAe6dO4nVY6h5SO dTG_hE7UKomB6ddjIxUMAfRLin0JS.3ibTXjU2YRKgFOMzg.f13aEXfzTxxQn7mdMxsucyqJeFG8 InxkoRlvGhqrSXWZYHmsNdJOIarxAQT2YNOJzivLrYFuphaOaxy9BLXyggfoAsoKqxdre.DFeT0v CWYJAgt_NvbTZXP.FQTTD1ycfB6bYvru1a1ELz.Lk0vUePcPC_jTwlXcJeyxriXTKcJyHYk3DDvY 3tHXt.cMpcCfp2PquMtVv1VgD8_HpKKyrvDFqxXCuPK1uSFRHunqCERMytmbew4n2QTwCvQAx1U8 o9YQOyjti3TKaB8XLm9n1as_HhTe9gNwxiRLBL0Dc3l.GxZiiJYA62tTP6wuvwrr2pOMPneFD0fj pqEB0Up8EJ.JoYCD3VLV5.zlyUK6Gg5e8X4mxw4yYmcNjI48r2wBzIC2TTOd5SWjzYodSf0i_Xjz G8UtRLoIBpHImg2cDrjvk4Y_0gaHRLS_XF6JBfHFaEMRKvLWR_mq2JHCUlDw1YpdA7BOl_iCVFMo Dnm5kGy7FZYNGuoqx6TS36RcPNw7ny0Y7FHRiipwGkE7LBNJxG777rTW_Tcj5n1GYsO3yHVC5xpi ySg4ufaOWKftFT8BryMWVR0EyUfQEN7zfhFf3h4kMLVCptJqS.isZaXFpquSLMWxSprKN_CmSoZy 75Ox2Raajv6GAuiZ1K5E0DhtlHEWPUQ.yybOraq79fVaKHba1fQqhfn7ywnbmN5oPYpteYdHzoWG bv.twxG9GYGj4HCDHaWvzkK38pwjxWduw__K8aUHTy5pSAI4BiZs8aEarzlCBnVClR4mnD7uAKuy QtqcZwaVuLCIgUAC07Pq1ynF2ZswgeTVcnTYsrl0pAe.T6mic_Hw.NFXqe7CZtPPgOB_ZAEu5Gny IvW_9qrzCJP80bdefimHEcmBWXcZSeFGcAfKUYEi3e51WkjCDJM5tZiPn2NrrA7wGPSrdce7x.k_ dWVSv.yHYdeGrbVSemllo2njeukw8wcWAWftdeFc2xvojKaRT8hkEihJVL3xhjTLs9AN_8ohbTVM UK1XQmybXWWGNAPvgQvGrWPeKkb0A0IYtbpuGcn0kyrSGc7w7zsSag_OiUIXiOXb.7VQdB13Xtdr f.A4P1ouk638UfARBzv.HC3dipmdY23f50WOfhoA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Dec 2021 00:40:29 +0000 Received: by kubenode531.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0b36ccde2af49b07ddd6506515ca7e25; Mon, 27 Dec 2021 00:40:25 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD In-Reply-To: <20211226224709.GB16188@www.zefox.net> Date: Sun, 26 Dec 2021 16:40:23 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> References: <20211226192338.GA16188@www.zefox.net> <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> <20211226224709.GB16188@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMf382WBYz53KT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2647 Lines: 87 On 2021-Dec-26, at 14:47, bob prohaska wrote: > On Sun, Dec 26, 2021 at 01:00:38PM -0800, Mark Millard via freebsd-arm = wrote: >> On 2021-Dec-26, at 11:23, bob prohaska wrote: >>=20 >>>=20 >>> Obviously filesystems have to be gracefully unmounted, but is >>> that all? Can the kernel be "aware" of an unused device and >>> get confused if it goes away? >>=20 >> As I remember, for FreeBSD, >>=20 >> A) The built-in microsd card slot works fine for swapping >> media that are not mounted at the time. >=20 > Ok, that's reassuring. I observed corruption of microSD card FAT=20 > partitionss and wondered if hot-plugging might be the cause. I could do a similar check of this context later. >>=20 >> but, for example (no mounts involved, RPi4B 8GiByte test context), >>=20 >> B.0) Plug-in the USB reader, no media present. (USB3 example here.) >> B.1) Insert a 128 GiByte media to the reader. >> B.2) Remove that media. >> B.3) Insert a 32 GiByte media to the reader >> (same slot in the reader). >>=20 >> Result: >>=20 >> (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20= >=20 > [...disk errors snipped....] >=20 > Was the Pi4 running from a USB hard disk? USB3 SSD. I do not have the marginal/insufficient power issues that you have. > I ask because plugging in a USB reader to my RasPiOS Pi4 while booted=20= > from a USB hard disk seems to disrupt communication with the boot = drive.=20 You have described having a marginal/insufficient power context in other messages. > It doesn't crash immediately but can't be gracefully rebooted. >=20 >> If you do the 32 GiByte first instead, then for the 128 GiByte you >> get notices from GEOM_PART about "was automatically resized" >> but it does not "address out of range". >=20 > That seems like the "confusion" I was wondering about. The kernel > notices the first card insertion, fails to notice the removal and > then mis-attributes the change to a partition resize. I disconnect the reader, swap media, and reconnect. That handles things fine. >> I expect that swapping two media of the same capacity would >> be less likely to generate any messages, but that does not >> mean that such a swap would be handled fully correctly. >>=20 >> So I unplug the whole reader to swap media. This is messier >> if multiple slots are in use (more unmounts and later >> remounts). >=20 > That chain of events crashes my RasPiOS Pi4, at least when it's also > booted from a USB drive.=20 >=20 You have described having a marginal/insufficient power context in other messages. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 27 02:25:26 2021 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 8B7A7191EFE2 for ; Mon, 27 Dec 2021 02:25:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JMhNM3p0Kz3Jl9 for ; Mon, 27 Dec 2021 02:25:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640571932; bh=UfUNQ8/RZpq4r4qKeA9vHCd+L5+38HnvPC7zg7zQexk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GPOa/L8n57BHJZXpAvL6bYgXG6Qq958vj3NaR9S+7auCkT5JL3rqfmp5NkVFj5wJb9DzQ/WAYncsx+ursVM/HHlEYVmYlFXs0vqJQ2nLc3g26wgvCCTFXR2DFgOcw67kYoQeof/F4ftNLon0s+rxM0FRLTcFO5rU7TM90iVWnh9yrjMSI+F4NRdoyGVnDgA3f7OZebGrFRv0Q4R+k+cw7GWgnB0xnXfuMjN75bTtOTZxwgDOv5/rYq++qURGTl5+qxo66hrIQvR3tgky7cQJiW3LHIFY+rK9N3Bbgrm94yExKZ3LeKd69ojj/9aHdN3LyqwQO5UmSVfy+qyqdKdvXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640571932; bh=nj/kh0+42uTsfshyMHB1x+g12I6dLJmghd+2B+iaIAW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oDDhBQcFv6IjAfBbSBYZpPAkaO+bv2qMis64Q4w2imqXGAQ3V7TSaFRMJXxhtSugUJzR5M7nQVcZ23T5lfVi5Vm5WfRk4nj0pNqf9+WVfPMwijMr9iGg3xLULU76Ho9TZxXXhgwZvDipy5qNzBuXKbOUvdZsY/9vTHeGr0FoLGiaEtDIgSrb287m6Vy78lsZ2asIpNB5xZAeGHQl2ljgqet+ne6FdZ7rx0x1rYJC4eJLJrurN3SQ/MNC8uGdwfWwr/aY4g01kLGwtcScWIex0NX27x8L33J2ru30Q4CiuDJF8N15PMVe6CCoAJUPMSP5J65b4jV3vC0MHtLowb85EA== X-YMail-OSG: dSSYZ.IVM1nTRofUdC1nq6.aOVdTtizelwGbihJF_ML8PlEnkMnC_dJOMrCdpQE 1KTP.miKFPQz1jjhLlC0KRJ5WCjLbFjUDrZ80uiF.e0YFVl4hcTo1g5WkvxDFzt2T2hk0zsXtsvL v08oVi_52q0ZkcH2Hmrqo7.6wOGhyG_CH6tQSvLxSSUfKaIget.__mbagW_mnRRRJ66G.uED02HZ lSBBoD4j9xY8UIQEmlQqUYpYqsgmPC.7xttjU2ggIKdgK16qI44X0AN.ftebfLRoHfL4tawbeHly eeH8vIvzgupf5uqxs97zfNCrXWhBwaJ5azmbypA2tCX5.cQxDtxb0KFMTF0u9.._Iu_SsMTtjqUa z8deQzbeplEtTlc5qfSZraHs_RZnst0gu6T0H94zyVQr4tCk7imoJKWtBGjACtQscxgcSi1km.0O ygsf3ydPdDuxpnZ.cPVPDkqE7T1E_.fq9jQW0S_5vgrkHOdKjdJC6BQjHNoLzuC1l3UJaV3JXEy5 3DUHYsI8TqlnCFD2wwxFVcbF9iAI_mXleScOGUL0JY4tmNN.jH88N0ua3kiwAjMs3iOiOyA8bYJ. Z7f8coOMdWEx_cDA9rjV3UKa7.ngi_2kFzYyfLtsk.7s5zcNU5OI8uPJpa35bRTT.5xZev6wBGSD g21K5sCmBiDPXykhDTxN6lOMoykgoj.obeRXzkLBEUEdGt.niE8nM29Yws4ePqzXxUPYST9ebw_S EiNYsRMNiy3uOR4Dq1Dc_6cyPpfIHjo6EXs1Yl1FjpZgsB8DsVg__Ib8Gby6ea10XNO3dCTjJHLd _hs40LuqdvBXEU15Uk2KszTOL5kIMvsBpixEAdxSS5C6AhNweC6doMbTnDR0bszRJuwvQKco3dfC yCq88JkXRbDcCHKDDSDUsIk8pfATsKUJLWPU5.YesDaMHjDQAaOn18cX.NZeXE4fMyuKefWE41S9 3gR61qncEhMK3xgwVoWnop1iXvk22v_1C1L9EQSQHtV0EtO50powE9Y9szrqEu64PqVm1PzyLtxE WhyVgJcIfCfzIXOFPcyEX14T8Hj1SGnpHTUvkBd0prDQtcUj8hIGHgpgjnObNsJtQFmIQV_LuBY2 ZYz_3JQD6dX0MAj0fRCahpMblXK43u43e0iCh0gS_DkOcxQXA9X6R3STgdlTZxfklT1xAW_Qmtct qgAEDemSrD8ZAalkCh9axXAN7yOPpp9398fIZ50MWbNkA23JvXhf8HSdmfRov6Q3O.0.NB4ekCYD RMdjTjYY7q6tfT3YQbhdEjrytK9XszcLGfssNPNsJKkJIwF5iIfHJ8CbaSCQ6rNCL8FNxxTQ3XD4 igI6r7lbCthEYSulTdRNhvp8c2PJ2uP8v.Jx.Nn04UiNvoax40ICJvTFep_3MLcLJxroMMgIdA2i 6VSnaFm7V2xSSGo5o35ziz7CufFJfyA0MOaf2bBm.2qeHIsatO55mwVoN6SZyECqM_E9sTXf.5.Z Dshe9CHhMNSBmfdXU2jfvsNBB2orBnRZfCy.HME0oBZ6mSMxIapoBOwdfYaH03V5B_1VpFFht1Zn mUVtXyuQB_QoGLO830SZcQldPZFb6OTq4KT4l6Rjzy2eQRPudcYwSYqBIhdr_uzzlrl3Oev7Cqy4 ZzUSxM5eIHknO4zt16Q37QhWXiv_xlNSFJ24CYNj14p5rzElUcqvTt5PdrfPoouUPzbO3Lypj8xo OL7Jot72Gnw8_7NOxaaZKkY_UjZQCvsvVDIRMppSNe5IEb4KQBD3Eg4CGGbTmjhpJ6N7X5Xhg4R_ pgqMBQazdQfpqV29C3lE03t6VgKVWkgskWpg2sSG10l5Dm36MP8hlpzZ2_hMqsn4mO.vm.QH6lNj pnRb9KbJVTaoqRc9iFz6XZFuG2TZ1G0scgKEBu2NzaPvHJTjwh9.4vt27i0e.bqKnegFLfGitcab NsTz2VBU0MFteIchRmRcJi2TraupSdKdf1MLHjk1yUvF8xQxcWIZIX7Zd0v9HwKnDiZOU2FWSZt1 TGAoqOkQhFoDHQ1vZHv91EfDFa5ESeF.0yAgiRC48DlfUVKDQwA.dmtCxftGe4nuHuHvSjdp8eP3 mFJX9mkJHWgeJJqeIgGhXidfBKFea9gCsavsi0KsAaHGw7OkRz0y1grpcrswRT58oZ8fPppuHJcI zeQSVnAwtb.tDoMQnF0JieISbw9udnen24NTpA4eeKHz_4PAx.nvWISQtDayyirnP2gW4oaZTwZA P3DHLJJqGZAV4HQ5mOADLxIayplQhRtxqks_ropA_j7Ju_oesJV55pLaaLteFfSLkeQk0Pe08lFM gMtdS2tyHJrTa5QCK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Dec 2021 02:25:32 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12d8e60665cdf771a664f192f8a2c988; Mon, 27 Dec 2021 02:25: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD In-Reply-To: <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> Date: Sun, 26 Dec 2021 18:25:26 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211226192338.GA16188@www.zefox.net> <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> <20211226224709.GB16188@www.zefox.net> <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMhNM3p0Kz3Jl9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="GPOa/L8n"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.99)[0.992]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4532 Lines: 138 On 2021-Dec-26, at 16:40, Mark Millard via freebsd-arm = wrote: > On 2021-Dec-26, at 14:47, bob prohaska wrote: >=20 >> On Sun, Dec 26, 2021 at 01:00:38PM -0800, Mark Millard via = freebsd-arm wrote: >>> On 2021-Dec-26, at 11:23, bob prohaska wrote: >>>=20 >>>>=20 >>>> Obviously filesystems have to be gracefully unmounted, but is >>>> that all? Can the kernel be "aware" of an unused device and >>>> get confused if it goes away? >>>=20 >>> As I remember, for FreeBSD, >>>=20 >>> A) The built-in microsd card slot works fine for swapping >>> media that are not mounted at the time. >>=20 >> Ok, that's reassuring. I observed corruption of microSD card FAT=20 >> partitionss and wondered if hot-plugging might be the cause. >=20 > I could do a similar check of this context later. I misremembered. Rock64's vs. RPi4B's: they behave differently (booted with no microsd card media). The Rock64 reports each insertion to and each removal from the internal microsd card slot. For example: mmc1: on rockchip_dwmmc0 mmcsd1: 128GB at mmc1 = 50.0MHz/4bit/1016-block mmc1: detached mmc1: on rockchip_dwmmc0 mmcsd1: 32GB at mmc1 = 50.0MHz/4bit/1016-block But the RPi4B built-in slot handling reports nothing and gpart show does not show the media (which has a FreeBSD installation on each). In addition, for a microsd card with: =3D> 63 62333889 mmcsd1 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) that has the msdosfs empty that is put in the RPi4B microsd card slot before power-on, the Ri4B boots off the USB3 SSD. After the boot it shows: # gpart show =3D> 63 62333889 mmcsd0 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) . . . Removal produces no messages, nor does insertion of a 128 GiByte microsd card (that has a FreeBSD installtion on it). And at this point: # gpart show =3D> 63 62333889 mmcsd0 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) As you can see, it is still showing the old information from the microsd card it was booted with (that has been removed and replaced). >>> but, for example (no mounts involved, RPi4B 8GiByte test context), >>>=20 >>> B.0) Plug-in the USB reader, no media present. (USB3 example here.) >>> B.1) Insert a 128 GiByte media to the reader. >>> B.2) Remove that media. >>> B.3) Insert a 32 GiByte media to the reader >>> (same slot in the reader). >>>=20 >>> Result: >>>=20 >>> (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20= >>=20 >> [...disk errors snipped....] >>=20 >> Was the Pi4 running from a USB hard disk? >=20 > USB3 SSD. I do not have the marginal/insufficient > power issues that you have. The "power issues" reference actually has more context than just power. I did not want to write a description of all the adapter issues and such that might be involved. >> I ask because plugging in a USB reader to my RasPiOS Pi4 while booted=20= >> from a USB hard disk seems to disrupt communication with the boot = drive.=20 >=20 > You have described having a marginal/insufficient > power context in other messages. >=20 >> It doesn't crash immediately but can't be gracefully rebooted. >>=20 >>> If you do the 32 GiByte first instead, then for the 128 GiByte you >>> get notices from GEOM_PART about "was automatically resized" >>> but it does not "address out of range". >>=20 >> That seems like the "confusion" I was wondering about. The kernel >> notices the first card insertion, fails to notice the removal and >> then mis-attributes the change to a partition resize. >=20 > I disconnect the reader, swap media, and reconnect. That > handles things fine. >=20 >>> I expect that swapping two media of the same capacity would >>> be less likely to generate any messages, but that does not >>> mean that such a swap would be handled fully correctly. >>>=20 >>> So I unplug the whole reader to swap media. This is messier >>> if multiple slots are in use (more unmounts and later >>> remounts). >>=20 >> That chain of events crashes my RasPiOS Pi4, at least when it's also >> booted from a USB drive.=20 >>=20 >=20 > You have described having a marginal/insufficient > power context in other messages. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Dec 27 02:42:46 2021 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 CDAF619028BE for ; Mon, 27 Dec 2021 02:42:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JMhmD5zqrz3LsP for ; Mon, 27 Dec 2021 02:42:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640572971; bh=bUAAKISjf1xOlho+z9VuNrVGvrOrr6LYtxVvfiWIk7A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lZsonhR9hvXL6cL4SO5HestI1UW/L9DzZdZou9cwFOyg8PvjkeF27GXV1J2+izM0hl8zKQ9uscd5B7qHA7QMTyPlBHJtqJiObzhUhdpJ104YgJRCVAvDEG07RLnBvuzYw9ZaF6LlYhAIEKvZvJkvYUS9FU5zu1PtB3jT8V4pSK6uSp396uTypiFPwS7kBoTn7F8Qxq6MacqPNbLJfHQu6fUT/P+QjI+/XgToIbsiB1KHZ9tM+Ip8W7N016G7M57a3Fc/Wv8CKwzMfFdyVoxHP3EPSFMRqtc9+nEio3+WP8CJW95fSKLZFzDQxx0wGAJ4H1SDwracp1+aUQfPJSlkow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640572971; bh=AL3XoqGjiqOzXcPDJxOeoFc2d+xoXZJeSxT9HqchxPE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=C+AZpmae+wkjoVeta1cuhaL6gmb0m97So5opC2i4DZ7MRfGRu+YBRzNcgDlx6OIo28Ay5POsrzwegtE5y23tIma1sLe0FVTduqu80z1hTLcacGgDvwJICU1CqHNO822+msSQvUIPWCvp1kIInKD0wfN1UU9NX8MFypll59OJPNPpOjmVhiw875YqpsID+MVmVehSB7BgCZOy6WCveD79u0e6Kp9HBkqCljRu5hKoyatE4Ph1Y6L13RLDme00vgSHcSGU6gD5bJKVTUzkPNbn/XDHPEuiqf6KiAFLIwSqEyhzGgwPw4JStN/KPA0aHeA2Qa0GrR+l0u4ftse6Mcx/oA== X-YMail-OSG: rjbh.IwVM1n8tEwkcFy_ECzkVCVL9uJwZfiTPQXOxR95ulZfwpSelLuLUUwTWap 7YhLCSXt7rrep5kNf3zF5eA8shBvp.QtmmXso3hYVrgxz_q.sHpMqtZs_wvVlyYQy9w6QLqG7551 lyURPmPwiTOLEX7gAvAu2eAlWHb9wSncVm_5Y_RSRuc8mGgPlqiGvxCph5hVknRSf1ICyGF5A.W0 CC7SI1tuVgzH9z.S.1EvpwV83KNudVNaRTkj4JKe6d5N6Vx9iie1oX9cZQmrJBD2FX_whtyUkgok I_3KiHrfa.2lqesE2gAO23onKYcT6NQUPvEov84G2is07k20.9cFYJ6ZdcgurPkyWTIVmqLvURKE 8V5msgyr3xY_aKnlxj_QC8L8wfDIFXW_wfGGxMlR3WlSIk_3ITHEQYcsiIj_hxxviu3c3x2mfb7l fgbZPzhlkffhgmWU5Q9Tka.LgMXPbpDvYw_laCNBXukFwBDqfHzCtPAFPeKs3IoU0RuWteWEY9KL 4B.9aH6q7yMXQc2Q_jIJNfmr8lr.WeGqdjWDFSc.Qu4q5UO8AzaLqtR3Dc7_SD0G25LkXGhpsQ_M ypm2k.mbtb9dG1NO216IZ71h.rZsvOuAAP6jAftRe9Zo95MuXvcrtjLFSJEo3D3G2ZZ0O4DEJumD 7mVNDk6mOyQjNDxHOwTSEOn0wJaCXjHjWIPWGbFJbCknZuWhFRFSa_Kth70owwCtqTXUQ9TW.YZE cpVDjk7TYugTT7SWA5PVKXQU0DofcIs_sUEVzSWNWFitIhN34ep9N765wNfpxE23ov9ExWCrJ0eI 7cDlNmA1PTiqbf6f_iDyl9PQb79DT4kdzTIYCV.Ou9XwFA.BQludzfUU6sO5ukX89iRzWmJwEsxS wXmxnROjDupO_.LLnhZs6emnfIFCGN9hm35j_s4TfRGSBr8VPtOqApGlKcTiWtmlqq70b5bzhzZ0 FSDspAH9JKoJlee_aIxvZfeovm_dYDPCb5Ilp.nZc2FPFccRz93rkyQMFHdSeToIGtaIHSrsgpEN V7_77c2IyvpTk4KLgp66EM0tGawMWPRFtlgZxo.IlS_usVN1qAAJffNTAQjjizHfMufS9fFIDAx5 bMdQ.yUFH4MVXyvb4y7LnpD1k4V55ZhEHWN53rms0O7VsXBIms9tPFzRoRWVTmpZoRinHzTom_tG r.x6qhF1Ge5UvwN4Jq.Q7XX5xy_XdGcwg0NDyRLLX2Hu3TQjQV0BmrGUa2rknHoKvncXsNubvuxJ bQSmojkmfLjOZRG.grZxASt1qYtZLjxMTEKYE_cMLDSQ7.f7ygp5wx_bjadTS1TOvA81kdhQyH93 AJ_Po0__w5GvPGV3YVi41hdkJGtiwbsgc_Ywggae7jUK3gjF2KKBbTUT4DDVDy1qPksp4Nk2QfDY dmGCR9P2Xy.raBvldnnkY3Qu06QTeGdLEY8aUunJBJmnk8x8.VlxnLYq6kCdMK61CwxmAuKZqFes mbEVRm2abI5ch8RMT6VzHwnrYPFiypRWIE2weZ.3dbcj2O.uPIoUblIkYNnnoS58ObbpKvuCgg54 nGbURxnzJjzZjFC449dxUBg7usA8CnVyAXyu.aTNy2wTvLOq2gQ1U2rZCLGmCpKgpnIsRgB.u5eq LY4p.K87zzh60xThfuDcjn5KQrx4F9oqrSxjbT6hQJmTg8K2JlYlBvePy00j7h22t9hQBOUzE1lW iedTi65XtUgHd4PUqxnES_nYtUyQzyboiGLWzAgv9DsWJBNvunn4M6KtCnkpID.g8t715bQ4QWqI DzSSUJHdgJ.yCDh5zdb8XvO_JgDP3eIwncIQHek6E4JjDUsoYkN6Uy5cK9aQjnr6AYoXiyqcBz4G nNtSQdQ1J5JR5j7CgkYsy2f0ozG2SdlTHYigOk2HiVfBsvxnWQZchiGPBFQAyKOcNWZoftN7rNkb bhiHdL_S9e3UPlw6IvO8MvWZq_Ap7LPi6nwSdxRMAjNlbaK8oMMNWMKAaC6W9_WGGVsimxlQB5Qw 0Wk2jzppslQsI3WmR66YpfVwPdEerBF0uCjH4i04sEIggweimjCbNBt_jNrreJELtVjjQVJy8he4 Heyi94xLZfXaYQ2zWuwBMp17ML.Wqp3CDQwIG5ngxjnfjrn73cTcgWYLeJSEVuCuhmQDIHPGGAuH 6QGkwFl00lr4MYPBqfNAqpdEVcmS6TjwoPGTsZZ7kaqiP70J2iLqAmCpmTwcB4gpJ0OXRMK0TH34 Wp_tdDN3YHWpdisa8WXBAODdzbtdPsTQyXRzwA03e4NW7vmA9jYpppmP9DhTiRJGrfM22zRS5wGn Ouvwhq_pJI2u2f.8dNw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Dec 2021 02:42:51 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 374e383100e6f67a61488114aa7bbd45; Mon, 27 Dec 2021 02:42:49 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD In-Reply-To: Date: Sun, 26 Dec 2021 18:42:46 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <3C4AFB1B-467D-455B-A1A7-2A77AC87E4D4@yahoo.com> References: <20211226192338.GA16188@www.zefox.net> <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> <20211226224709.GB16188@www.zefox.net> <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMhmD5zqrz3LsP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lZsonhR9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6077 Lines: 182 On 2021-Dec-26, at 18:25, Mark Millard wrote: > On 2021-Dec-26, at 16:40, Mark Millard via freebsd-arm = wrote: >=20 >> On 2021-Dec-26, at 14:47, bob prohaska wrote: >>=20 >>> On Sun, Dec 26, 2021 at 01:00:38PM -0800, Mark Millard via = freebsd-arm wrote: >>>> On 2021-Dec-26, at 11:23, bob prohaska wrote: >>>>=20 >>>>>=20 >>>>> Obviously filesystems have to be gracefully unmounted, but is >>>>> that all? Can the kernel be "aware" of an unused device and >>>>> get confused if it goes away? >>>>=20 >>>> As I remember, for FreeBSD, >>>>=20 >>>> A) The built-in microsd card slot works fine for swapping >>>> media that are not mounted at the time. >>>=20 >>> Ok, that's reassuring. I observed corruption of microSD card FAT=20 >>> partitionss and wondered if hot-plugging might be the cause. >>=20 >> I could do a similar check of this context later. >=20 > I misremembered. Rock64's vs. RPi4B's: they behave differently > (booted with no microsd card media). >=20 > The Rock64 reports each insertion to and each removal from the > internal microsd card slot. For example: >=20 > mmc1: on rockchip_dwmmc0 > mmcsd1: 128GB at mmc1 = 50.0MHz/4bit/1016-block > mmc1: detached > mmc1: on rockchip_dwmmc0 > mmcsd1: 32GB at mmc1 = 50.0MHz/4bit/1016-block >=20 > But the RPi4B built-in slot handling reports nothing and gpart > show does not show the media (which has a FreeBSD installation > on each). >=20 >=20 > In addition, for a microsd card with: >=20 > =3D> 63 62333889 mmcsd1 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) >=20 > that has the msdosfs empty that is put in the RPi4B > microsd card slot before power-on, the Ri4B boots > off the USB3 SSD. After the boot it shows: >=20 > # gpart show > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) > . . . >=20 > Removal produces no messages, nor does insertion of > a 128 GiByte microsd card (that has a FreeBSD > installtion on it). And at this point: >=20 > # gpart show > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) >=20 > As you can see, it is still showing the old > information from the microsd card it was booted > with (that has been removed and replaced). >=20 >=20 >>>> but, for example (no mounts involved, RPi4B 8GiByte test context), >>>>=20 >>>> B.0) Plug-in the USB reader, no media present. (USB3 example here.) >>>> B.1) Insert a 128 GiByte media to the reader. >>>> B.2) Remove that media. >>>> B.3) Insert a 32 GiByte media to the reader >>>> (same slot in the reader). >>>>=20 >>>> Result: >>>>=20 >>>> (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 = 00=20 >>>=20 >>> [...disk errors snipped....] >>>=20 >>> Was the Pi4 running from a USB hard disk? >>=20 >> USB3 SSD. I do not have the marginal/insufficient >> power issues that you have. >=20 > The "power issues" reference actually has more context > than just power. I did not want to write a description > of all the adapter issues and such that might be involved. >=20 >>> I ask because plugging in a USB reader to my RasPiOS Pi4 while = booted=20 >>> from a USB hard disk seems to disrupt communication with the boot = drive.=20 >>=20 >> You have described having a marginal/insufficient >> power context in other messages. >>=20 >>> It doesn't crash immediately but can't be gracefully rebooted. >>>=20 >>>> If you do the 32 GiByte first instead, then for the 128 GiByte you >>>> get notices from GEOM_PART about "was automatically resized" >>>> but it does not "address out of range". >>>=20 >>> That seems like the "confusion" I was wondering about. The kernel >>> notices the first card insertion, fails to notice the removal and >>> then mis-attributes the change to a partition resize. >>=20 >> I disconnect the reader, swap media, and reconnect. That >> handles things fine. >>=20 >>>> I expect that swapping two media of the same capacity would >>>> be less likely to generate any messages, but that does not >>>> mean that such a swap would be handled fully correctly. >>>>=20 >>>> So I unplug the whole reader to swap media. This is messier >>>> if multiple slots are in use (more unmounts and later >>>> remounts). >>>=20 >>> That chain of events crashes my RasPiOS Pi4, at least when it's also >>> booted from a USB drive.=20 >>>=20 >>=20 >> You have described having a marginal/insufficient >> power context in other messages. >=20 I did a little Fedora testing for the USB3 reader handling: Plugging in the reader with no media reported the insertion reporting a bunch of information I'll not repeat here. Inserting the 128 GiByte microsd card reported: [674787.789768] sd 1:0:0:3: [sde] 249737216 512-byte logical blocks: = (128 GB/119 GiB) [674787.798729] sde: detected capacity change from 0 to 249737216 [674787.809873] sde: sde1 sde2 [674787.809873] sde2: Removal reported: [674796.646095] sde: detected capacity change from 249737216 to 0 Inserting the 32 GiByte microsd card reported: [674814.378393] sd 1:0:0:3: [sde] 62333952 512-byte logical blocks: = (31.9 GB/29.7 GiB) [674814.387473] sde: detected capacity change from 0 to 62333952 [674814.400235] sde: sde1 sde2 [674814.400235] sde2: Removal reported: [674816.959997] sde: detected capacity change from 62333952 to 0 So that such tracking does not happen on FreeBSD (when there there is no removal of the reader itself) seems to be FreeBSD specific. But inserting and removing microsd cards from the built-in slot reported nothing under Fedora. (It had been booted with nothing in the slot.) So this sort of thing for this type of context seems to not be FreeBSD specific. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 28 03:40:06 2021 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 D9D151911A6B for ; Tue, 28 Dec 2021 03:40:08 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 4JNKzq62P2z4SMd for ; Tue, 28 Dec 2021 03:40:07 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-qt1-x82f.google.com with SMTP id j17so15155092qtx.2 for ; Mon, 27 Dec 2021 19:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=GGUMg0xBrbPO7Ytsgwcg1dc3EPqA8k2+rpXEjX6qTdk=; b=Wkqc/pSCSfN12wZ0uo4baf9K9iFwxPldz7inZhb7yCVAvQqAzYF5xBpV+ASplxQn8p fJ2Yky7q91ZtR5MvxbQwOWvHh/DNcZdla9F/bbK+IQFDvOEOVZc3uPbb2Bx7wDRG3RLQ XkOvs3h6wN1AD+IkM6IrqN2DTEz0+w9Dc7/Oy4TZwo1mlLaJaVS1JFMwOOppJeW/u75h dbDrSUrvdJO7iuz9fELbqBcp3spn5Rkvckg8MGDenFJNzuHg4Zd9WckNNnkqGZUeSlRe vGzgGz/v/dllctbcLb7GmUreuFshHI7CC+QtYwtHXlpUakhok1Sbyc7YqeVO3bdNg/gg +kPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=GGUMg0xBrbPO7Ytsgwcg1dc3EPqA8k2+rpXEjX6qTdk=; b=iYQQRgZkkQ3h0WqQLiuryS1zVpfp+sdDKIRu3ddvqp5adz1v07bvsHG68ptKCELHIK PWBvBB/vuqeNN/Z74NlvQRPHrdlUJCGvbmhmsNJbDRzBrwE1UC0G6nC5Uuhmm7vEpOGj 4/2TIBB0XcmNRGSZEQ3cSGoyQX6F52kMV+OuZoFNYeT/2ldxeYHL9WRpxf7QWCea8etM XqE74Azi47IQYpRMwOpr/KIa1rRC+vU8lFCGEu1SwSMotKhs7FIpgmYk051hAN3nCQej +n3yzhVZz0SjWRJEpylrG0787LtJloOq8RZEujF5Jjcu9GHnxxCOgPTmxDHUUa2/BD/+ gw2Q== X-Gm-Message-State: AOAM531867RxUBSeerwlArjqVnkPLCjDYbly9+Z6gBZVhIbwd1PGrc1T gj+nS1lNyn7xq1IVZWicRYjirtYYIxaGAt3cuvs= X-Google-Smtp-Source: ABdhPJxniToGF6yLidNxrcHUdjsuDBWUQCN+56e55fk6tA8uYIvHtSEBNcZ/fbhUt+UmU6X5u0Btmw== X-Received: by 2002:ac8:7d47:: with SMTP id h7mr17491700qtb.486.1640662807260; Mon, 27 Dec 2021 19:40:07 -0800 (PST) Received: from [172.26.26.1] (ip69-17-228-34.vif.net. [69.17.228.34]) by smtp.gmail.com with ESMTPSA id t3sm14680087qtc.7.2021.12.27.19.40.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 19:40:07 -0800 (PST) Message-ID: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> Date: Mon, 27 Dec 2021 22:40:06 -0500 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:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: petru garstea Subject: FreeBSD13.0 on Pine ROCK64 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JNKzq62P2z4SMd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ambient-md-com.20210112.gappssmtp.com header.s=20210112 header.b="Wkqc/pSC"; dmarc=none; spf=none (mx1.freebsd.org: domain of peter.garshtja@ambient-md.com has no SPF policy when checking 2607:f8b0:4864:20::82f) smtp.mailfrom=peter.garshtja@ambient-md.com X-Spamd-Result: default: False [0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ambient-md-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[ambient-md.com]; DKIM_TRACE(0.00)[ambient-md-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(1.00)[0.998]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[69.17.228.34:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 792 Lines: 39 Greetings, Hope all is well. I burned on emmc drive a FBSD13 version for pine rock64 SOC however the system doesn't boot. The command I used dd if=FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img of=/dev/da0 bs=1m conv=sync status=progress Then I validate the partition tables gpart show =>     40  6291376  da0  GPT  (29G) [CORRUPT]        40    32728       - free -  (16M)     32768   102400    1  efi  (50M)    135168  6156160    2  freebsd-ufs  (2.9G)   6291328       88       - free -  (44K) I tried to boot as is but no luck, then since the GPT is corrupted I ran gpt recover da0 But the result is the same, the system doesnt boot. I tested an armbian image and that worked well. Please advise. Cheers, Petru From nobody Tue Dec 28 04:12:54 2021 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 50EFC1917C7F for ; Tue, 28 Dec 2021 04:13:02 +0000 (UTC) (envelope-from peterj@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 4JNLjn6hYTz4XV2; Tue, 28 Dec 2021 04:13:01 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id E3EB424FA; Tue, 28 Dec 2021 04:13:00 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Tue, 28 Dec 2021 15:12:54 +1100 From: Peter Jeremy To: petru garstea Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD13.0 on Pine ROCK64 Message-ID: References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aTVpy1H65MMomjOm" Content-Disposition: inline In-Reply-To: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640664781; 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: in-reply-to:in-reply-to:references:references; bh=LKtCSLgkVOfWwqYfE31dPBrz2evKXTH6ciZDF9bBWOI=; b=nxzyNJQ23LHQ8uz2AiePZfyOEvBFtK06JOp98ExOol5qdCM6UTjd3b06HlhSRAcKSp/SxZ 5wz/yxf9JTsD8R7tQqtFuR49MIqI9+aQH8PhQE++bb1dmMRrFYFo6wqdbV7plf/Mew+/uA GZY2nVDJTMxZaQe8jGD8fIqwh1NuPAvQBpUMidlPKvfpmNqnb4SU9IneIlEei5FgJyU4w8 hhXJqgjxFKXvtkbWXkO9Uh5eiq/SwiGG1aAdDjdrFn5MkQWvqqHRPzp6rWGGkG4Znf9z3b v6WTMqBlFmIFPUUpVDSIff/htXzpYYd83U02E+yW5gVCnBpFuF+FlNfhSgvXQg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640664781; a=rsa-sha256; cv=none; b=gPNxvbs+pQV04K+0FRbPAMwyGGkhcUy61HrJdH8dl+sZ0UccG9wovJyi+Pon9mZzgfKvVB 31zZK70VkYk6FEKMI6vkZMCdqDXErXZRrvzjClDKz6zEp35DbskiQjHZBK93/rkRwrZ0aC a4XW2TQi3OY9GFyVjWg4MC479DoC5a0lcOQmeO4DApbl0EJ6OnNIcIdCWsTywU5h9DpOyp K1fhdrjgpfNxb3hgnYOYMzdQdlVBEmGCxG9saVD5cpbam5uf7Gly+3hbLN09EoFk0ksR2A uyJ4X1mQ7NaaaRQXnn1LcBtsOApkdc6HNbWFrYTGVMrIUT96GI2owJL3DuiLWg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1885 Lines: 49 --aTVpy1H65MMomjOm Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Dec-27 22:40:06 -0500, petru garstea wrote: >I burned on emmc drive a FBSD13 version for pine rock64 SOC however the=20 >system doesn't boot. Can you share the output from the serial console? The usual configuration would be to boot from a MicroSD card and it's possible that U-Boot isn't automatically failing over to the eMMC card. The serial console is 1500000 bps 8N1 at 3.3V. The pinouts are e.g. https://forum.pine64.org/attachment.php?aid=3D986 >=3D>=A0=A0=A0=A0 40=A0 6291376=A0 da0=A0 GPT=A0 (29G) [CORRUPT] This is normal - it just means that the backup GPT labels aren't in the last physical sector. --=20 Peter Jeremy --aTVpy1H65MMomjOm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmHKjsJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzT/GQ//b+tqKSnMsc0mYuiAVyH3BYel1i1/Y1LQ18f9A8a1IRGV9nrGORCR8/ca a9wvPJc/VNmvGIp8y3P/A95VzDIlRvcTJWFMbPB4QuyKiawsbt/d1viam6xXfkd/ WFs/NY3jLquPLVaRggWo/bXpwcZ1UZbdorA9zaVkaqbAADJ/YttHFZ8QJ9xRvGz8 UQrPEUqHJHPIEhARfcb1lf7E6aHq+42ylizRkYkSMyQ+/6QhMsejCxb2/oxzyidr a1PsDHeJwm7SmyWI1M4BTDl31mEGU9pSlDf3pkd1HT/j+m0RV5BpBmOM+q94q8DQ cC1WriV9z8k3NnJ4fU32+Ph5czuaj+LoPH9/skzTauGaTSAHbH6OPHeBFR4xl/h8 1r9sFwsaTMBABH9OoS6gDbRD/yMafXdIrkD7GdDUobVqeAtESVqGfrPB9s0nRPSP uSrS4VvDLMsfJwVBsVIoCck1JfHJ9kBIJPdmUe3tsacZ3Es9GiSIhheht8Bsf+Q8 sKmI84+Z5Ck4RDFsG2ikZaMEPYJzve8S7CjslRXb6bTOnOqjigk0pych4auNzaxy Rxdnd0d1Xh2mVPJK/Q5HwngV7nUYE6fQL8IYjFkV6LsvWJ4NciRZcgjw1XOS/oZX qQWru3vAJ87A6Q/Icr3cF1DiZGiY4wSDvxdgusXjK2iqVhYQiQ8= =XyXj -----END PGP SIGNATURE----- --aTVpy1H65MMomjOm-- From nobody Tue Dec 28 04:27:09 2021 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 C7E9B191AA2F for ; Tue, 28 Dec 2021 04:27:11 +0000 (UTC) (envelope-from roboman7811@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 4JNM274ML6z4Zfn for ; Tue, 28 Dec 2021 04:27:11 +0000 (UTC) (envelope-from roboman7811@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id 131so16140989qkk.2 for ; Mon, 27 Dec 2021 20:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version; bh=UEGx/u1saAZ+ISlBSlfVAgJGRa3CJcA37mEnfaHx4+I=; b=bDlJ8iUCzMWQlif1u3eI2gus6u5mW0NqNemgj3rAO7qFrHqhDt3uu/mU3NHw6YgPoD S5gs24X3GvnuaSmDrwVl4u/vGL1glJKD3vSW3BC+4eIDK2ggmgMXXpr3rsHVQpCdPHWb sXomAzuaOdkwxMBc03k8S70vPfhcURhe+CYeDfTFtKdfHK5/Y8VaVCSDuMCI4Z+NxPcb CvCw2I0OaG5IzF1LjHiQjha6dVQOseBlowdU9fqhL5U+8QcZyr8JoRoRza8Dy0vVeq8Z T1fTSUFKoBhP04fMmpNBrICNUr6hhiG6nAhNI2vIYrGzmRDmMERHb6rg4ADEjy3YginE Hujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=UEGx/u1saAZ+ISlBSlfVAgJGRa3CJcA37mEnfaHx4+I=; b=gUt3O9Cuw6BZSbarBFwsbfIparRWMm8ZPue8fw4x4g5slXFLU8OoCGh9AXu4ees2ME wOXOpVzt36eubVrCN1I1wq4JI2Y1mSUghFnSxAhK9rA2eplt46sPf/8Of3MfMaBrStoj s8kpsBq6gY/RnZpno2QwV2w63YytKswMihElGBQZwX1ewlvo2bR81XslJW5aR1cP+XM4 TZu5QnfSlrVMT7LWLQlOmmkTzLd7BsZ4QjTTEUQHp7/2WaRXXHHLcmL4wLs9YEkjTyWy BruzQ4J5D3fz8S6aKNgTltFppYjpFB0LIn5LV2JGIfp89LjfAAX4wDXP5f2aOSX0t02V 4GbQ== X-Gm-Message-State: AOAM530Ul702rlyzjTiKHykh8WvZl+6ClsVdtERLY0bYG7Dy2tMJyMsP TrvNmQqLMWCo+BMKc1RdW7aolHlv2zxNTw== X-Google-Smtp-Source: ABdhPJwoE2KF3q/vzZDgpN749ym9WEB57NuxpUE4MupN7H3w9LqziFW4aZHKlgP+4o9PcjYORw7dyw== X-Received: by 2002:a05:620a:85e:: with SMTP id u30mr13925963qku.765.1640665630829; Mon, 27 Dec 2021 20:27:10 -0800 (PST) Received: from PI4.lan ([74.215.23.187]) by smtp.gmail.com with ESMTPSA id o10sm15186296qtx.33.2021.12.27.20.27.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Dec 2021 20:27:10 -0800 (PST) Message-ID: <03aeb8fbc817d0370f999f70faa167674105940b.camel@gmail.com> Subject: Re: FreeBSD13.0 on Pine ROCK64 From: roboman To: petru garstea , freebsd-arm@freebsd.org Date: Mon, 27 Dec 2021 23:27:09 -0500 In-Reply-To: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> Content-Type: multipart/mixed; boundary="=-jKzLovg2U01HuPe6g5ID" User-Agent: Evolution 3.30.5-1.1 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-Rspamd-Queue-Id: 4JNM274ML6z4Zfn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9552 Lines: 230 --=-jKzLovg2U01HuPe6g5ID Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Petru, I have 4 Rock64 devices. I'm just using sdcards instead of eMMC (FYI). I followed a similar path to yours below. I "burned" an image for device #1. It didn't boot immediately. There is a lot of online documentation on creating a serial console to view the boot output; but they all require more than what I had available at my house (custom USB cables, messing with wires, etc.). At the time, I was accustomed to single board computers outputing to HDMI during boot but came to realize from my research that the Rock64 devices do not output to HDMI until/unless the kernel boots 3/4 of the way. I followed some documentation to flash the U-boot code to the SPI flash. U-boot appears to be similar to Linux "Grub" and the SPI is similar to an old fashioned BIOS. After messing with it several times, it worked on device#1. I flashed the SPI and the FreeBSD 13 boot image worked fine. I used the same 'dd' command you did below. What you did is correct. Then I moved on to Rock64 device #2. On this device I tried burning an SDCard just like the 1st device. Wouldn't boot.... no surprise... I didn't "flash" the SPI yet; but I wanted to test it 1st. I then proceeded to 'flash' the SPI with U-boot.... still didn't boot. At this point I switched sdcards between working device #1 and device #2. Still didn't work. I switched the sdcards back to their original device and verified device #1 booted fine with either microSD card. I assumed it MUST be that SPI, so I proceeded to "factory wipe" and reload the FreeBSD-13 'friendly' U-boot code. no luck. I moved device #2 to a troubleshooting bench of my basement which happened to have a older 100 MB switch instead of a 1 GB switch. To my surprise, the device started pinging on the network!!!! Here's where I accidentally found something weird!!! Turns-out, some (not all) of these Rock64s will not connect to a 1 gig switch port. If I hard-code my primary switch port to 100 MB, the Rock64 booted to the network no problem. If I switch the switch port back to "auto" [10/100/1000], it won't connect. I proceeded to "U-boot" flash the SPI of the other two devices (3 &4) and create sdcards for all of them. My result: Device 1 works perfectly Device 2 only works 100 MB Device 3 only works 100 MB Device 4 only works 100 MB I reloaded devices 2-4 w/Armbian and they all work fine at 1 GB. It appears to be a FreeBSD NIC driver-related issue. I posted details on this forum and didn't get any solutions. I ended up moving to Armbian for all 4 devices due to this problem being unresolved. Recommend: Test on a 100 MB switch port and see if you are having the same problem. If yes, see attached response I received from a fellow FreeBSD-ARM member. -Jeff On Mon, 2021-12-27 at 22:40 -0500, petru garstea wrote: > Greetings, > > Hope all is well. > > I burned on emmc drive a FBSD13 version for pine rock64 SOC however > the > system doesn't boot. > > The command I used > > dd if=FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img of=/dev/da0 > bs=1m > conv=sync status=progress > > Then I validate the partition tables > > gpart show > => 40 6291376 da0 GPT (29G) [CORRUPT] > 40 32728 - free - (16M) > 32768 102400 1 efi (50M) > 135168 6156160 2 freebsd-ufs (2.9G) > 6291328 88 - free - (44K) > > > I tried to boot as is but no luck, then since the GPT is corrupted I > ran > > gpt recover da0 > > But the result is the same, the system doesnt boot. > > > I tested an armbian image and that worked well. > > > Please advise. > > > Cheers, > > Petru > > --=-jKzLovg2U01HuPe6g5ID Content-Disposition: inline Content-Description: Attached message - Re: Rock64 1Gb Ethernet not working, 100 MB okay Content-Type: message/rfc822 Delivered-To: roboman7811@gmail.com Received: by 2002:a17:907:7051:0:0:0:0 with SMTP id ws17csp667046ejb; Fri, 22 Oct 2021 11:35:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcbI3Ic42inYXJjN4rtP5dEaNMHUNSdsdQWQ/yluG3Bk6xjckZsvpjWO69kRe4uV7mf7xw X-Received: by 2002:a05:6402:5189:: with SMTP id q9mr2186243edd.94.1634927720955; Fri, 22 Oct 2021 11:35:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634927720; cv=none; d=google.com; s=arc-20160816; b=FakXfpWZwCGuLIJg/chu0Vd4H1uBnSsQiLuN+TU0MnME1Mg3tsXmZNFbyDkL47XSTu K9xeFdmQ2x9a5zXZ+0almaOPqquIYxBH1ziaHFpKCJgaHlpKjHou5ONTC8nuFaAz6saj S1VtjomWNfLtrb+IyItSMTAklsaZoi2U7i9ft+QIVAlbnP8jYgq2//q2lElIMxL0ma2H 4pXLlvSdoShREjDVoxNB2oz77Sg3qOhpWKyuO1YykXXnqaMchnTInzp1/dJgu9cRL6r0 D8XY2RMXSFXz4gTeh37WbwfsfgccynFsYHTZDYk91+LGLrCA35LfFhfTrtkrXZAmGEcI xnxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:organization:message-id:date :subject:cc:to:from; bh=GXsJ0FBF5vtep8YTGEHEX4cVYbFdSpSpWz6BdFGiIcE=; b=jjs9rjjirdvfy1AnNhL+imQRi/sE+tB9T3yhXREDP9/+u2bJFpeMqqaylEuKFJpOGH 1PPwbJCCtr38xGsipKCCKjj414PVFU1M7z3/kQcRbUgyhl3nM0aYunJb32J69xetvmAX A/BvWViGSUtEUySZGXVKxBCmQV81U+QxoiLodS7pWtCkke5RvJXL1snxaBky38616Kaq gI5iYLGPGzXphN3Af2BiR34q4paDBCPOezPKi44ljWBjsJNENFQQ02oFROp49EbDVwzy M3YDG1JVp7r7s/wfV+ylCVdRfbg29Wxiw4M2k82cmfE8/6UatF6kDn+GJmD9bAduMjNu uuEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning adridg@freebsd.org does not designate 194.109.24.25 as permitted sender) smtp.mailfrom=adridg@freebsd.org Return-Path: Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net. [194.109.24.25]) by mx.google.com with ESMTPS id r2si12365844eja.442.2021.10.22.11.35.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Oct 2021 11:35:20 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning adridg@freebsd.org does not designate 194.109.24.25 as permitted sender) client-ip=194.109.24.25; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning adridg@freebsd.org does not designate 194.109.24.25 as permitted sender) smtp.mailfrom=adridg@freebsd.org Received: from cust-d4a83f22 ([IPv6:fc0c:c11d:cecc:f58a:eaa1:c0:9d8f:c143]) by smtp-cloud8.xs4all.net with ESMTPA id dzNtm2cFPFfMidzNvmR3wf; Fri, 22 Oct 2021 20:35:20 +0200 From: Adriaan de Groot To: "freebsd-arm@freebsd.org" Cc: roboman Subject: Re: Rock64 1Gb Ethernet not working, 100 MB okay Date: Fri, 22 Oct 2021 20:35:17 +0200 Message-ID: <2902939.hHqAuc6tWs@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2302286.THHZn3L5Ee"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4xfOq+FXdWsbitWTtGWhv6S7Av/enM11J+UTcWqatC5w6qHjnwh6atOHg7lWyzmBclRZ8aDUalgeOulLFNmwIryPfBjX4lvXRYgaHHhOhUThP9PFMGQ9j+ VDCGI3WJlh2iPpftrZSDpvfMbn4CcN64vBGJHuhlB1+TMclVukebh3WieXnOlEHqnvkf/4YDlsvwdNDlPbjxrRxApTog7smptNR95nTzjSyrOjtY7Qc0TYkZ w1V7U20FtdSwHtWLT5xHTo+ETjkoYALzbfVNkUSIaQ6qyIdq14bWqO1/VSyGgn1T X-Evolution-Source: ec1a921a6e17257d5a4bd2aabc6110ded3dcfd40 --nextPart2302286.THHZn3L5Ee Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Adriaan de Groot To: "freebsd-arm@freebsd.org" Cc: roboman Subject: Re: Rock64 1Gb Ethernet not working, 100 MB okay Date: Fri, 22 Oct 2021 20:35:17 +0200 Message-ID: <2902939.hHqAuc6tWs@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: On Friday, 22 October 2021 08:22:21 CEST roboman wrote: > One is running 13-Release at 1GB and is operating 100% stable @ 1Gb as > a NFS server w/several active clients. > > Three fail to connect either via static or DHCP @ 1 Gb. There was a lengthy thread "Rock64 flaky ethernet?" back in May on this list. Yout can find blog-posts about it -- not necessarily FreeBSD-related though -- at places like https://forum.pine64.org/showthread.php?tid=7545 https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ I was unsuccessful at finding the "right" timings to improve performance and gave up on that particular board (not Rock64 overall, just the specific one on my desk). [ade] --nextPart2302286.THHZn3L5Ee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEhrjttu2OP5apuuy1z93JbxKxkVwFAmFzBGUACgkQz93JbxKx kVwx2wv/cA6CBwDIQ6eMu6L1WE0onbkcMTcpHwaAolIiwbe0QSCIFglslB1IueO3 vyvMTHsvxWTBfJ5LH8gXUZXAurexaoidSMraFkPdxsB1wNZKCWoebO4EqWSHecdP nfXetZ8be2hrJVPUbKWdDDYcqNTAb8WI0dVE8KrTRecctRvMAMl3eLb278bNprub OSqnldnvr2/RJcExohJ1rSc+q6u/1XkTmyTK2xTZ/BYEMUKRmEjePbzKkD13910B X7qQGMZpMn1xUFGC3ej+icbDHv76gfWHJmH03t53+ZSHragfDTo1lvFMw16aeBmc C79rKEwIEvt1dp3ooUNrXr55cuzHlLoVFa+cRuHf6WzvDndBk7HKDQOeNoXdL1Jt hcnc8ii0hPdxFXpwmJ76CF2cZGBWut53IuVOZpCP85W2ycNyrsgo5Ns54Vgk97iM 2ItnV084QSnJ9BVQCxuAr6x93Qkof19VULN6v0BGBImKqObRZuSorSOXGYZhPSDw 93Vz1f3C =ESF4 -----END PGP SIGNATURE----- --nextPart2302286.THHZn3L5Ee-- --=-jKzLovg2U01HuPe6g5ID-- From nobody Tue Dec 28 13:14:53 2021 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 93CEF192613C for ; Tue, 28 Dec 2021 13:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JNZlK2Pd7z4Qnk for ; Tue, 28 Dec 2021 13:15:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640697301; bh=n3/bxf1U3PRAEToh/PEKiflzh0uBNMh64EDIbdEf4Z8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AFVDaRfn8lXBeMfAk8OX9+J/wUjRBp8FsIwT0afwLjXPQZishZVyB3BlP8dFJfBaeqYaveJI1rIXjaLyws4YxHYf1KfxwISEAOKYWe8yyQ4uSg9PAr0lDUeUVBYXJcOdfqFMGLcC7sPJXorxZplMNyPi1XjEjGJcymAwbljhcKHo1ts6NCkrPbwNNqJAj7yyYgnSPwYkClHMk1nNmsdGhSp3WhdzJKX9DUz1kccRMvr0hl5QDipvqKDZMjApMQeMWCKOy1SV5algoo+m8GIyyhs3KAUKm0l0Bpzs/h3YYd/c8s44D/jZ6eVNc3HDVnDMm53YTKcexVcN4zAB6FrusA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640697301; bh=Ts4NxqAdw1cIdtfFxbk0F780Y/nQedDjsyFF7/PaN9z=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cNuQ2hUY4CdMf4Qu5jMiRxqWjgHFgVKyyNrpsqjoqGiNSPASlsGbGTWmm7kEFoKslvY9KbdD3yEHTvC1V0HTomFlYcs5TLe2Phx+3CLpabq+O9sFNEt9WY00C+ppYLAz1nZoXO3tgXZAHZRMgG1g9XTvJ8GShHEdqNGI++n1m4sGBodc7Mqzff7ZUTm5JaKFlVr/IFPGNy7kCOWvXg8ukD5QR3AFN7DpNPd1/ZtCHI7FuOA+bPKQ+vetvcysKmjbTOl/j6hB4wC9/7NguZFfFO6IEhnbGVmOZRoJH/Gk1gStqdQQB+Ze3HQX3TM5K3gDt2xlAZh1XP+3KEKuQEaw9g== X-YMail-OSG: qtbbq2kVM1nCMSHJZppiFKz.i0dQFalkfixf_HttYEHromHyymFgLIIeh8p.atV VVqTHh.iPyzMrz3_EwyJTCv7xcoXzevAtd7QJ1HkKHBCD2YTYmS2.B0u2nh15GNTh69RVe8m5MsC R7QNYHY.sY32GRSck.NWwINGeXC_02WKaDDlhmf_zPAgGOYFNsdCU1Dc2svMUa6wkGYb1WdNCRpB z_hFEur6ciepMoOEQwDbEmuT1tOAS2Meg0OncojYjmOSYwmSfYLZuejMf0JhpssuO6UgjvHYwodc ipE_179hEg1aYpv0Nu9RT0cUhaBcjIeFN3L2L.y1ha0HKp1Jia_6oRPDU8KN4hmrpwgI7OVfq_wk __4dHgZIr0LGZUELgqjKQ65oHSSQ71sZUod9XlRCP5uigBQG_IBVEYIWbyw4HggSko6T6v8skClB wbJymdz0cD_d2cehBAN9lCq0p3GYyXs.p8guwmc5PJnC4lkTY5pYdMWrSL.SWCJa9Mm2Tq74rfCJ cmJe_UXK4wZLNcUGbmJF9EwGlaboSF5iKhVUWlxhfvS5k66MLt4JS_q3tXG05Ggibv9gA.mDscPl CPSrUu88YOEK2D.Heqx1H6Gx5eAhV5zaSAlPea3vOHiuaxxoahQiBV1c_C4CbvF3sgUP_9SolbPT TXQ819jgSfLttXWG1oUJkll4F_L1mu9V0g44BdvaEOQ8Sx2ednqCGk3DffLAq8Uja4C5scDOPwGA m61aGNzCWKEnfDXMqHNQgALSjX1jqP.q7DA44OUlNtVzSBi8RB2Wi_xtQhpxBPr_JOJM1ZvgekjO MP30xrKZ6kVQ7jNF1w7dqKOcAfYwbbNamXWkNP6vwfNBYG_5vUWDK5wyxAXXASfy42KvGz8k3Tyf iJv4riU8gGWDn3yfBEygNJ8nIzbd1YMi1oI7i.iHT2oW3ejM99RK7W5v0Wp2werejNYOt4E5NMFC Le0ND.c.OsQFLuTqfYIxbTA2zJjFlnTM1jTUS_S37DdpPufRRQFxjjOaFdzSnagS1ORPB4S98NIN hEQmwDFIs6_JVT3j3OHSBKc98AGsNiNRpKglKGEMuzE5qJceY49U2xPa.g2ZayPzO4wfMoAgdtxe AA_ymNeKqA4BsEseSlRl.V_gF7.Vloc_cK8Cs1vqGqE_UYIxwCm42ylkJjDkj5lhrArRbFidbkhR oKGaTxXYNEM2stZ1.W4xz1sDHS6wFsS1NM5JMhZczjgSEVp1qyCNz6P4gPWxXg6BzNDuzPlccyFR Z99VNHFYd1e0M.1Z5WOCwA2VSOduw6TGkGtMyDAYYrepnLa5sDdWyHpk_x04KjhubjBSpgtY8jzU X5nwaEUZWVr9t1liPOOL0cuWy2mwGpJew6zt8SxcpEO8i7OtaDB9rZR7TEosub03VhmbNqmn1gdk Y66QkjhDkHv3x8z62WvZsHrtRM51xMYgJJNPalO2IyzUKoGAe8BX.q9y2kTHvXukbQVzFUfIOTU2 XRChFrobtBCX9SUoTJ.u.gia8a0ZjWvmHU_heE4tszDFFmhvf7f4IvSYjz2W.T9kIjinoi91q9hW xb4uFMSqMN1S256gdciXBGfIeOhEG80WI2IkWgry80KWruE9bJoGeOfHUfUbP2Z9P1WQYvD2DRI7 DTh8lnYV.xxky_ZhJrXrHhO2UvkSMUWWeT.FvGvmGkrUCoBW04LPEEQ7.r7n1WGycQROfK5RWYj6 RMw3YHmQFbid41F2_PshMq0fNBgKXPqOeo5BOWyjNgRTj.JPKPwFuEu2SK9OSMYruToIAgSdLolZ QuL7cuW.euW_3cYTRFK0_rAdF5QPUf6PSAjtT9xVj1O1.V3a.52S8yo8mcZXap7yiy5.dexTblM1 JyMTS6eTipszwJNKFbbkErlqxEFSoKul.nDhhr_C83K3pHfZOkvSfh8Gh5ZZbev71mLeamob8cuT _V_iTtod59QaQGSsolewKFHOIuu9.WOJmtnsC1gSrcutf7lriwrBElAVsDq0MUb.xbx2o.VGJIgm mCnfX.cM_TEecblErGlj7V0YwCoLEaaQhqFRCsncUQRmiXARjBp4hqg3z.Lon1BGrKKyEe6QrbC1 4odbHiuFexEq3bfm6ZxxlSnyUZz3cg7IwPPhP7H0O.g56z2vMRgugQzzghjPf1O.rzOknPa3DJkq A0tD6k4LtsuT0a1X8yWJiq4IjW19phJY9IbhZkJyrzsKqOEYU0gapHmoegkygrCgAcmvhBDMPYfO cIohhMMpuiMhueyTwr.V2GwSu0qDAudp.g.5d9vc9Aw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Dec 2021 13:15:01 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 60910404529c8a7a8c5087f6ae45d7b8; Tue, 28 Dec 2021 13:14:55 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FreeBSD13.0 on Pine ROCK64 In-Reply-To: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> Date: Tue, 28 Dec 2021 05:14:53 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> To: petru garstea X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JNZlK2Pd7z4Qnk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2856 Lines: 96 On 2021-Dec-27, at 19:40, petru garstea = wrote: > Greetings, >=20 > Hope all is well. >=20 > I burned on emmc drive a FBSD13 version for pine rock64 SOC however = the system doesn't boot. >=20 > The command I used >=20 > dd if=3DFreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img of=3D/dev/da0 = bs=3D1m conv=3Dsync status=3Dprogress >=20 > Then I validate the partition tables >=20 > gpart show > =3D> 40 6291376 da0 GPT (29G) [CORRUPT] > 40 32728 - free - (16M) 40+32768 =3D=3D 32808, which overlaps with [32768..32768+102400) > 32768 102400 1 efi (50M) > 135168 6156160 2 freebsd-ufs (2.9G) > 6291328 88 - free - (44K) >=20 >=20 > I tried to boot as is but no luck, then since the GPT is corrupted I = ran >=20 > gpt recover da0 >=20 > But the result is the same, the system doesnt boot. >=20 >=20 > I tested an armbian image and that worked well. My configuration uses the e.MMC through loading the kernel (but the kernel gets the world from USB3). (I do my own FreeBSD builds.) # gpart show =3D> 63 244277185 mmcsd0 MBR (116G) 63 32705 - free - (16M) 32768 102312 1 fat32lba [active] (50M) 135080 28760 - free - (14M) 163840 241172480 2 freebsd (115G) 241336320 2940928 - free - (1.4G) =3D> 0 241172480 mmcsd0s2 BSD (115G) 0 230686720 1 freebsd-ufs (110G) 230686720 10485760 - free - (5.0G) . . . The Rock64 boots just fine, no microsd card present. For reference, my Rock64 Armbian installation on e.MMC is shown as (gpart show output): =3D> 63 244277185 da3 MBR (116G) 63 32705 - free - (16M) 32768 241795072 1 linux-data (115G) 241827840 2449408 - free - (1.2G) Similarly, my Rock64 NetBSD installation on e.MMC is shown as (again gpart show output): =3D> 63 244277185 da3 MBR (116G) 63 32705 - free - (16M) 32768 163840 1 fat32lba [active] (80M) 196608 244080640 2 !169 (116G) (These were accessed via a USB3 reader, not via the Rock64. The Rock64 was otherwise engaged. I did not build Armbian or NetBSD. I just used an image from a standard place for each.) All these start at 63 and avoid having the initial free space overlapping the [32768.. 32768+???) area. All these are MBR instead of GPT. As I remember, the Rock64 has a jumper configuration that can force microsd card booting, something I avoid on the Rock64. I've no clue of any of he above happens to have touched on you actual problem. But at least I've got an FreeBSD system that does the steps through loading the kernel via using the e.MMC. So that much is possible. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 28 16:19:26 2021 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 70F4D191DFFC for ; Tue, 28 Dec 2021 16:19:34 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 4JNfr62Wz6z4mSH for ; Tue, 28 Dec 2021 16:19:34 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-qt1-x831.google.com with SMTP id z9so16584943qtj.9 for ; Tue, 28 Dec 2021 08:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=KnwRtlxvWqCTXNvc10tns3IyzpJ0r0LJSQcZyx3te1E=; b=ZoQodfWE8Z5ElsUHB8Sg9mqhBoOWnjDW5XLvPt3iTajBn9x6vA0nzUqkORn42cX0xf a8n28aFfBdqCRi5vYyRglYN0A31+2BF4Dc5hNyefTI9MfIhaN3xZ4x7QsEvkLgOmlygx f/uHR8r7TyhSuARM5qP7V6UF42mnv1OIzRaQzM0JXk4Ey17mQX0XoVhAca2nIcRD6O2o nbwwBaO3lS1UtiJbY4BA//QV5In2+FJtSiFK0zHAxADszXJxiJGqqrn9mJLcjZWrS/nN biEr6RsC7WSn2w0U9pSarecIviHNzV4a0GvEqx5YYqq9p7620q0FKkHKC5N0C0giPDVg B1Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=KnwRtlxvWqCTXNvc10tns3IyzpJ0r0LJSQcZyx3te1E=; b=tdzjKvh0zqg/gbuMrGHsZPG8jfLjlk2oCerhWWVWshLQK25JuGXSx9qe2oTjTSxpU2 hE0mEs9rRIrokgCDwF0IM14fxHO96bIEBxVx7NQ8QIGQrk1hVhGJbMpgiTX23ovZvHCf NjQXYjxFJ0OmSSFR5ZzA0IuPjGEypB1VjM9AYZI20/7XtSCub/83PF4gjOI4ZgIbanW0 ajOCy7xbqgyROiPLbiBtQGiObSLmbFaZMcgUC/VewddLbWdGmmJn7PEnXXsG/52KpHjF 4cHFzG1FKozKNu/2bW0Ru9ndQ+teB7+2diKpj62NBUFxMVe49D3H+UMfnbdFdabPpJVB XB+Q== X-Gm-Message-State: AOAM533d2xUAEkdD66ZvDIm57ybZtRsRPeBOeZqHFp0geNc+1IPBhGJC hDeNOU0+zGyOem3evkeiIbPsYg== X-Google-Smtp-Source: ABdhPJzAoONV+lhMkdw59xl2BlvweMp0rRyu0LjUYch15jjN4a463TG+0jCpEWIsMjlnHKLt/LpP2g== X-Received: by 2002:a05:622a:3c7:: with SMTP id k7mr19388530qtx.307.1640708367854; Tue, 28 Dec 2021 08:19:27 -0800 (PST) Received: from [172.26.26.1] (ip69-17-228-34.vif.net. [69.17.228.34]) by smtp.gmail.com with ESMTPSA id q21sm10869672qtw.26.2021.12.28.08.19.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Dec 2021 08:19:27 -0800 (PST) Message-ID: <923e6062-52da-7e6f-6bd6-673557a1d66a@ambient-md.com> Date: Tue, 28 Dec 2021 11:19:26 -0500 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:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: FreeBSD13.0 on Pine ROCK64 Content-Language: en-US To: Mark Millard Cc: freebsd-arm@freebsd.org References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> From: petru garstea In-Reply-To: <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JNfr62Wz6z4mSH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 202 Lines: 12 Greetings, I will try to flash the SPI with FreeBSD`s u-boot and will keep posted. Also, does anybody have any ideas whether it is possible to connect NVME drive to the board ? --- Petru Garstea From nobody Tue Dec 28 18:52:58 2021 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 2876A191C386 for ; Tue, 28 Dec 2021 18:53:07 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 4JNkFF2Dmwz3QQx for ; Tue, 28 Dec 2021 18:53:05 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-qt1-x82a.google.com with SMTP id m25so16920310qtq.13 for ; Tue, 28 Dec 2021 10:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:cc:references:in-reply-to:content-transfer-encoding; bh=Mel5+FkLQl6itb35nb7pOofpQrgjf5BOJGwTQJwwOxo=; b=wLlgTFAX8q5/4ug+URTfQSIuA5Ml4yxhXyYui4FSz+PL3OZBfVV25aNnqoYHoLq6ri h7q3JWHIU8aIg/1AsXVX9kt4OAOgZq3CZSfJjDJRIrbdoBhFbjwGGOtqU+ICk09gNKYP x4x7jGrDU3a7cp1w3xehoSXvs9ZjVAur1jCXhXJX16Re9wVEpM6ejiIngZzXmROZyPn6 b6FfgmzlMJ2iy2edP/gVNNv4DfIpXGN8mJyqCTH9Mypfu7SwFVOpIdF3jqkeORLm5dyD yJbGyUzs8jI+UX1iZoeCtCC7t+hcTu6FJuRUMvy94ylHXb8BCmNkTAuqD+4v8vYAoD2n aMug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=Mel5+FkLQl6itb35nb7pOofpQrgjf5BOJGwTQJwwOxo=; b=u/SkgcZJaZnFXngZwz0I2Rbx8Lt+oWW4VMkRsEGRns89ZPmJlpz/wB/ayFyxDdXGpD DwK78svnqODEws2CCH7MFMOlA909f62DMJz4F6FddlcuT1RDKR26+DR3Q3smqwn3gQhS cfeqoa+rQ94rHwDAnpubmOMnbi+QquYzznuYiyaPoblk29TA8fzHi25QCaOp7BbvFH3o urwiBrinZABgH7hZLT1f+AxCm1mPyG6MwxSqJEDhwjuw+gqTZvyXNdSp/xOAIP6QBgDo KjzdI3zzPLkg1TMx1bJWjbUEE4n42s3G+Nc2Cch/SCwzFGDWgfTPNppUCRnD/atNlCtY UqZg== X-Gm-Message-State: AOAM531SFM6EESSmL/DC3yupKqsiHnfwbBxjpwxyMzEd5qvtRdRY/sgF R3vXgTZ406Rrbm5GDCWMQmtrT82wioa+dgYN2u8= X-Google-Smtp-Source: ABdhPJwx4C+muJXrZTMy3nBUBSd2KyFoEib5n3B+LLvYl4wdkqz8OdO3lkcIe9gKvGwKl/ohJsJ+9Q== X-Received: by 2002:a05:622a:19a3:: with SMTP id u35mr19343987qtc.303.1640717579407; Tue, 28 Dec 2021 10:52:59 -0800 (PST) Received: from [172.26.26.1] (ip69-17-228-34.vif.net. [69.17.228.34]) by smtp.gmail.com with ESMTPSA id bl8sm16372074qkb.38.2021.12.28.10.52.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Dec 2021 10:52:59 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2021 13:52:58 -0500 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:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: FreeBSD13.0 on Pine ROCK64 Content-Language: en-US From: petru garstea To: Mark Millard Cc: freebsd-arm@freebsd.org References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> <923e6062-52da-7e6f-6bd6-673557a1d66a@ambient-md.com> In-Reply-To: <923e6062-52da-7e6f-6bd6-673557a1d66a@ambient-md.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JNkFF2Dmwz3QQx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ambient-md-com.20210112.gappssmtp.com header.s=20210112 header.b=wLlgTFAX; dmarc=none; spf=none (mx1.freebsd.org: domain of peter.garshtja@ambient-md.com has no SPF policy when checking 2607:f8b0:4864:20::82a) smtp.mailfrom=peter.garshtja@ambient-md.com X-Spamd-Result: default: False [-2.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[ambient-md-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.81)[-0.811]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.952]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[ambient-md.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ambient-md-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from]; NEURAL_HAM_SHORT(-0.32)[-0.323]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[69.17.228.34:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 381 Lines: 17 Finally, I sorted out. Actually the board boots with no issues and the Ethernet is 1 Gb/s. The issue was that I kept an eye on the boards` leds(I dont have the serial cable), and the leds are showing red and white colors that made me to think there are no activities and it is stuck. In near future are any plans to support HDMI output ? Thanks in advance. Cheers, Petru From nobody Wed Dec 29 07:38:55 2021 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 6A70F190AAEE for ; Wed, 29 Dec 2021 07:39:05 +0000 (UTC) (envelope-from peterj@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 4JP3F51K3bz4Vv0; Wed, 29 Dec 2021 07:39:05 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 24EE320BFA; Wed, 29 Dec 2021 07:39:03 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Wed, 29 Dec 2021 18:38:55 +1100 From: Peter Jeremy To: marklmi@yahoo.com Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD13.0 on Pine ROCK64 Message-ID: References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> <4DD2481B-282F-47C8-843D-D3121D042259@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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8H03BqMS834461cc" Content-Disposition: inline In-Reply-To: <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640763545; 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: in-reply-to:in-reply-to:references:references; bh=4P7v2gsJdmrgmjBEoDbWYsxgvZX0Yo/OBBTo2UljCLY=; b=yXWOpz9Kl6K55gTNY3fwrnt20aEWJptcUwLiCgJyNw4q+ia0lxOcVLhgaV1IyZ0NBrbVyf M1IgwifzQhuZTif9AwX9x+hNxVbDrJ+bYwFx7fgZjbGZhFKiXpbyqcwtcj4x+4dTjpfNAy kLtAdeIsT2wiE70+TWc8CyRtW4788QotvrIGRfDsdptt10WKVTxKEaQDGFUcPsRf0vif2y SFb9so0VAXFswBiGjhB8XLK0LZvPX0QQDtkvEqOw9/DAIsERbEHxPuRcQBVv6AJq4HqinS hE1mKqUiAiDLiJtqlr1/79scz/yHf5COO050p9lVctDWnCoHBFJc49pdvLWxDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640763545; a=rsa-sha256; cv=none; b=Rhhc5VaQk3/m7khsfSe3KK2M0kFQ4sclPEvhu6io3sdEFois+HFCl2zQIRnmQnEy7/XM/w ykJ/izixjHynwecy9vuSbP9sJCSDDnpXHZj2diREW1JuDeKgvpYgL+PBH+sXbKL2BstYMz 4Y6pi2CCipP7/QyCCMB7aUwLppvsclU9t6oU7UArJNpbUh/SMX+GxRtral+45/9OU6cxak /qCXx3eWK7IGkgI1ZEuLeBhTp+SV6he2Mf6G5fdFLxT6aV8GW4GrQ2z9svr8sPgHWSsk6h 9R3sEuSjmbVZ7QSkC0IHzhFc6I+Cr+xs8CJIcHaATIJct75zYhH+7WAApzYKVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1734 Lines: 47 --8H03BqMS834461cc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Dec-28 05:14:53 -0800, Mark Millard via freebsd-arm wrote: >On 2021-Dec-27, at 19:40, petru garstea wr= ote: >> gpart show >> =3D> 40 6291376 da0 GPT (29G) [CORRUPT] >> 40 32728 - free - (16M) > >40+32768 =3D=3D 32808, which overlaps with [32768..32768+102400) > >> 32768 102400 1 efi (50M) Where do you get "40+32768"? The "free" partition is 32728 sectors and 40+32728 =3D 32768 (the beginning of p1). --=20 Peter Jeremy --8H03BqMS834461cc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmHMEItfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzTwbQ/9HYh9z2AR4MLzYjaE8yXO/bDBBvXVkgNLwxxvk7i3BCF/sFFEzHCaWmMh W/cbr4n76nfltNi8bSSZm9PCCIfo3DD61/7Hw043+oSJ2T4BXt9ocv3R7CHSh75O 2jvkiSeZc6k0Pz0NFXMFmQOLnR8/Y3lvLKEXOELTY7kYfSKwJZO4Oo+a/O7zCnsL Wh42CA4otPILqftvMLewKKfQkIpbNUfGSCV4jRVkKypvASjeAnCFE0oQhtBcOmH0 noiqQTCvkaPzpUCzpGW5Dsgh0JPujl3kvVZtVzQNfcpmsDFJ7xN52H+fQj7oEW+2 iCQTXO7AAzqzuicIfIPaklH4h6O/smF8qlEz032qPVSnEXsC8r5TEUpeNmt6ePbk YzRz/w/YrnPMSKIlGTPRgIKccxojFh0HE6m6axxQJJVYDcdya42lYcZtDfuzi4Fr NaEOSCVOKn7fQZmdytSy0EL+dawnt3ROpQt6015g+OyZPBtlz5oIYXr83gld3RVI uJ7MS+mJnaenXpS+FQIun3EYr0oyc89wU56c16QP9RE9RpZcPYJrNDGS+Uxogx4i OTHka/8eTY+2+TujEV7CDnAjOT2MdX7iUksSYC0mfEHYJ2KhoFwcqq1xRVjOJsbt K0xB5syt737D0IqdcCu78+8psw7guaiykjrCtdBpXT1BxTet1go= =j5Cc -----END PGP SIGNATURE----- --8H03BqMS834461cc-- From nobody Wed Dec 29 09:39:49 2021 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 20235191E684 for ; Wed, 29 Dec 2021 09:40:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JP5wc60K7z4jRT for ; Wed, 29 Dec 2021 09:40:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640770793; bh=jzCVN6J23EtgTkgnobb5ZzkCowjO1zl7gMJVcUzUW4g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=E54oa4kufR3ikgSvR+0v30NQtp4WdiCcXeCBdCge2vPkSU0FjQ6N+6WS/jat662YJAtrm3zTWMeBDAacCgot2O9R+TfFKVtD2sSSQoyZSy9dK6TBaGfVBjSFtChuHyFUADqJWLcmd/iskeHe+/BXv/Y7V8yIJqpnQzCR2rBH+Zoz6fdVW/Lj9Lo5cJJ+YMJD3vbTLNdrA3TGJveQmTxBifSlIsmvEgEOAHfLx/y06+V8zMXpzim4w5JxiXrr2yLCPR81a3Q3Wg18F8gw2hPTkrOCBokJfjND/M9QDY+B09I726bEAFep6J4gGUU4DFiQnMa4M0FrWa4Kf7+C0ipE6Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640770793; bh=qPoC7UZv+7I8YpEb4+L3Zo3kFP5ojbkuPhymHys7ezF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YimDRDpYS9fjB8rwSvHriKp0KDL+KsxxyB6NT8ZZjBakWfxpQ1ngcA7PaoMZlNAY23RydZkOeGBw2pSTQ7cVoocnpz8xXXCsXQu0egyHX9BaJXNN1eKPHRXuzd+oaa2dBhU2TUmY7R/BWJWhEFXbmXqVxL/yeAdl1vwfk2KIIrTCU7UDLRmQ8gFZoTyVp5wmgU1gjUcETWAV+zyEBv2sF4K3RzZKyFy4m6m+0dm4LYmS/autsbwVl/XFR4GTuSmF4Qq+HrU3ArOd8ntf+aejUHJYQXV65eCWcGMKOkxPf3Tne8lupawAekG6jsINxC81sRBoC3pdDDbQgqQ7PEqGzA== X-YMail-OSG: npdPZlQVM1kcfhjORjvIr0c3kWNYZ5qJVwTvBDsqhc5ym_JFlGKXMmIGwAdJkwO ZUatN7hQST9GTDLqrzVgMnLT8no3qSnJOID2zoJ4GWvCkTWLzDxQGKzbyH3fDgispL.lQ1cOXIy1 SVg1VyjBELzn_sWV_B6PGQqQ3HshcwzDGMfvm50Y9.AT48c07dCqn0_1jsXNJJXMdoVTrT9g0H9_ iqrf6bOvTw4Ifzx1J7TaEgvGLY3AISj_5yjJrWYZFMVPNxg1QfiPuHhnPa1CeegVcsBqLY740CCG 7YaCDeQ8lZImQKfoJtJzOX1NpSWI8K9VjHCXUBzAJs.6E381Kub2vxsnj2DDYMs34Dc31OXekFWV WgCPMbRQfL8JWGist9p2cbGrW3Oy97V0re_MhZsq4MKC0X8v1uvDDScxZ_SRag4bSf1sx1PX4a8l o.Q8rtmRUpdMfxG2MuDJPKYjNNUHazWoHv91XtJ6bIqaM3SysUcZAXIGEVu4yYnDegNPlN6ul7an VlEiiiP0_ykgu2sPgn4kL94Xf51WDctOdkt1JKexzWhGWZJjcb71hwpQ2cl6JoyJSS6t2WVlEi0K o0IQz8SfrZdUoEBJwc25LLsj.h6WmbMY4_vQBx2GZOHv1jJXYx4nXY5fB9ZUSMDic8.9pGu68e6_ K8qXMgLxMqRyen2HCz.LoqONXzUKSXqAfJeV8p4ofkpKLm7E0WXNmBSn66wtw59aZ1kr6_QCVVwK 5u2guPAnhADdhHQuux.w4LNLjvTBw5gpI02tY07Y6p3Lb0CejRubxYFk4FTZf.ypMro24HvQJMtp aQ..AqRWyNa9sn_vznpqJv1gl4cRUu3btRToGpYsvs6UaUQfcP.BLovq1Bn3s7BWj9sPbKkaANTK ZnnmtE7Jt8dcZjEfeTrLXSdxwK0D8xmXS39aSC1NWA9prFVtIirk6vHBjaFBs2N0.9V_67Xeaxcc QUsmCoVs.lF06RfrM1ruReFfY0nqVIY35p3A2M3oH2E.VgfQLNM97vV8TLg3MY8uvGpzfnZDXQ5L Q0xarxfYXLig7vUo3L.hUwEhVX6i6RT0BS3ATTfj6knlvlGzkeURVSdScHFoW84audm_r.NX8jZk VBlAz41NmgABMWTTmuDLL1TqrRQ4worWliitWaV2AlDBZDDuuJ6uTIGRo2hToCA09gc.wRVgWWYS pMBbWATp_2UAPG1tu8Dzb0fr8bJDyC3fXAsk_AiiWLyWh5R4rGgLu8t9HZZtET5SUIz8EKSPEa8i lAz8B.Os_ve6fGchErO9snfGA4HMM5lj25eUfCteVtxiJwDzgixQP1SmnWCYapVKbyW25ve7.aHy CCfLE0gmXkCxPr0Nzrj_y3MkcbgeM_xQws8QWPtAv0dr9SqqBVWerS9_sNtBZ7hZYvvPO.cZ7RQA oLKtLlzoOGdMF1tm5R9sXa5iiKU17CwveH5rbMTky.laK1mgBULMx9FnI10fCKgji9ARreNGCpXx Q.ITEKGBRoShASsb922ZWz367nmn55mN2mOiMB6G_.JZIicj4F0zuMiMh.sR8vqu5LmIejTZGMXZ MDir3JnGyKafcuV70OaNh5tUbInntiONs5KPA7U6GeoItpKWjzz6HGcDxs7im4oTE86gTeg4bjpZ AE.3C444Iu_DQvHRDJEO.gYt.EgV4_Z2juI8mVOwUJT5XiPe.rG55B6m8FKOCkVEa8aoN6OZ4tW9 h0s8814EwJwr3b5DBcjXBcPY01Ufi6P8.WpqVeYCqYlQ2GZbAC5g3zXGHvV5.HkdgBpybRTjlqLh OPHKLtoKqWECKiEa7hKTqOfbaKZUsnw4y0d1Bs66IgwoJUKvS83UtSosjau7iJdnAckwdvq3h0GN C6w.gRajPQQv43b7tMBx9mS47sQgAW7k_KfEDF_2u9fIOm2B95ThC46Cglc6NSjHS.dy1QIByJMO HgdAguA_F7gKUwfa.j.Tn8B7AMHuTQXJBnLT41xUAe4WVmE9i7UeNbEpyE.mHTDpXhY_xvTZzpG4 yq0jOIaA_oeKXQAF2Ki0zUxfnBVGusuAFvRq0tleZy2dIrvWMzBjxDNQC0I1WAG35akT6YDi6UOu i4sCv3H8vQpmKZBdhoBuHxmxQALdJejLX3F8C34WIsznTi6TEjmCIXZ8PsJV4OjeXQ.7XMPdRPnU PIMhK5yHrDnuTMmJdNJLQk_thxW6gwfaulY1RIQtx6KCt.m2PxKavDVL0iJKPrUNxkOkgnTpWrjM FtM2kZ306cj_DWpsCaho3lQMc.9s0ceHItO4ca8xVwnazgX3vlX5_rtQb5GPRP6xA5SxvIIkBWrI DrFqvqZCszEaSOrG2 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Dec 2021 09:39:53 +0000 Received: by kubenode522.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dd4ba907955a4011b43ecc7c0e1a65b5; Wed, 29 Dec 2021 09:39:50 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FreeBSD13.0 on Pine ROCK64 In-Reply-To: Date: Wed, 29 Dec 2021 01:39:49 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C22A273-16A8-43FE-B393-93C7B4D678AA@yahoo.com> References: <64ec1bf0-4eea-2499-f728-83f093e95027@ambient-md.com> <4DD2481B-282F-47C8-843D-D3121D042259@yahoo.com> To: Peter Jeremy X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JP5wc60K7z4jRT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 681 Lines: 23 On 2021-Dec-28, at 23:38, Peter Jeremy wrote: > On 2021-Dec-28 05:14:53 -0800, Mark Millard via freebsd-arm = wrote: >> On 2021-Dec-27, at 19:40, petru garstea = wrote: >>> gpart show >>> =3D> 40 6291376 da0 GPT (29G) [CORRUPT] >>> 40 32728 - free - (16M) >>=20 >> 40+32768 =3D=3D 32808, which overlaps with [32768..32768+102400) >>=20 >>> 32768 102400 1 efi (50M) >=20 > Where do you get "40+32768"? The "free" partition is 32728 sectors > and 40+32728 =3D 32768 (the beginning of p1). Stupid error on my part. Sorry. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 11:59:02 2021 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 AF7A7192A4E4 for ; Fri, 31 Dec 2021 11:59:29 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQNwc4Pq0z3vpf for ; Fri, 31 Dec 2021 11:59:25 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id DCC671654; Fri, 31 Dec 2021 11:59:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk DCC671654 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1640951963; bh=gRsANya+5sTSPspxIeQLKnD6xyrH2m8YHdOuGzZGpIo=; h=Date:To:From:Subject:From; b=tNVAEVXTkgH8xBqKLu3mPSj4sA9+jC9U2qD3oX+3+M0rGmyE9bXLnzffZR8D4QYRg PNYpCHa6SowzsculWc+sjCNG2MnZiOYHd8+b3vNVob3zgcR3gqlTbJetSMgCXZUMmU K0yv2OYEWEVKolDzkBgqCM/CVVshZ3iq8pQJeLwU= Message-ID: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> Date: Fri, 31 Dec 2021 11:59:02 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: freebsd-arm@FreeBSD.org Content-Language: en-US From: Andrew Haley Subject: Call for testing: OpenJDK 11 on Arm64 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JQNwc4Pq0z3vpf X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=tNVAEVXT; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [2.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[0.999]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(0.85)[0.855]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 893 Lines: 30 Is anyone testing OpenJDK on FreeBSD/Arrm64? We're about to commit a great big patch for MacOS/AArch64, and it would be nice if someone with a FreeBSD/Arm64 system could kick the tyres to make sure we didn't break anything. Please forgive me, but I have no idea of OpenJDK even runs on FreeBSD/Arm64. I've never seen it. If anyone is interested, The PR is https://github.com/openjdk/aarch64-port/pull/14 The tree is https://github.com/openjdk/aarch64-port Checkout this PR locally: $ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 $ git checkout pull/14 Update a local copy of the PR: $ git checkout pull/14 $ git pull https://git.openjdk.java.net/aarch64-port pull/14/head Thanks, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Fri Dec 31 13:32:51 2021 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 54BFC191C857 for ; Fri, 31 Dec 2021 13:33:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JQR0X2sTtz4dbX for ; Fri, 31 Dec 2021 13:33:00 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 27F665C00A9 for ; Fri, 31 Dec 2021 08:32:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 31 Dec 2021 08:32:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=MOyI22QUdtAbIQ547/vPO5RhTRQ AYhXyb3Ay2BT8/E0=; b=okPAtxCMMa5VHbtkSwl0vKeTxD28E7+SZTOGfiLohaw fjg66grX8cinMdVuD2ZVC6s1w0D96gs0SiOTZVJVv3tlbg8apbDHVyf5FfN1dMDj XPul6/iyVwEiLfZFlhq2Uf40bb9u7Apn8mpWebwaS+RIP69nHmCPqxOiZCv7Qyzn 5PtDgWtHJGZtIqB13Js2U33d9n/j8AKWAnfcZuEWF82rB8rxR5JYSjZQtA4rKt4F rmD43MxSxO9DoHqhdszmzpHv356j4rrQz4/2YMHwKn7Xw+oKoDlGvzc9fpIdHlf6 U5J6n+JCjQfEh5xO3TSvyFEjS5BEsStic2MA+sjBBNQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=MOyI22 QUdtAbIQ547/vPO5RhTRQAYhXyb3Ay2BT8/E0=; b=IoHdzaMsDLqnmR+sgTxQc9 tkxe7iuYvGYHzfMEhNt1X4gkQfTywomnTABamZZ1JyLPow1rr8F2sLpfBnXCZDrF gO94PwocjSIaeAJXFpI9iqpJEMqoZImCemN721AvlgrOYdcHTZznZHS/Dhzo84eS yDQiYl+fjx5X05mgQd+UQIiZh9SfIX9W5KzDa9XRxK0UA6jBpvK0p6/FBynLMnVG CpoUwP3VELynXbWQUbZuF6lUSwahabk8Yc5ZUT4H++nwy0s4In0hEaxgnIX1KK4t eryJn5akf1PkJpceDVDTasmoC76egWSkXPtxouGlF2+zOhdQJ6vbRpU0LCoBdnlQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvhedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefggedtheetgeelgeevtdfggeejtd dukefgueehvdevgefgjeejjeekvdeifeefudenucffohhmrghinhepghhithhhuhgsrdgt ohhmpdhjrghvrgdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 31 Dec 2021 08:32:53 -0500 (EST) Date: Fri, 31 Dec 2021 13:32:51 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Call for testing: OpenJDK 11 on Arm64 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J9Gm0/92Dye/GcaE" Content-Disposition: inline In-Reply-To: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> X-Rspamd-Queue-Id: 4JQR0X2sTtz4dbX X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=okPAtxCM; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=IoHdzaMs; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.29:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1565 Lines: 48 --J9Gm0/92Dye/GcaE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: > >The PR is https://github.com/openjdk/aarch64-port/pull/14 >The tree is https://github.com/openjdk/aarch64-port > >Checkout this PR locally: >$ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 >$ git checkout pull/14 > >Update a local copy of the PR: >$ git checkout pull/14 >$ git pull https://git.openjdk.java.net/aarch64-port pull/14/head I'll try testing this thanks, --=20 J. --J9Gm0/92Dye/GcaE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHPBnoACgkQs8o7QhFz NAWjFBAAoSSMXk0/fNENq4mNQTlv47i7oDZ2XaeQPMf1xgIeh1YToH6PpMIIUdu2 XVEhQqYTHavAGkAsEkVm4O0UPD0fxavkyKkL7fiFXbHcOboH6RL5vKnw4eHBhmeD pE4Ms19vtYWFJJL8RiA21aQukCynIMaXluTW9H5p7yjsZUo54ClrOjA8sIOhz5dV 5VdMUo533vca0gtMv7gV6azGvLmZusYloxFcaeejxw6ZWHBaR7PovrDwJzEgfBYT zhcjCgXQCTDVTULpcosaUSRkL6HtKULcbQC5ssrjLuOKYQ3ST7lheDQd7uxoL6Ow YwH8RsL0o3YEpnuQmm8mSPxcD2G8hUG8bypy/9y2U2WWmPQeznHLWPlZuYcme4NZ Vq4QCiX5j6FCNTpZRm3AgWjVo7tl6z8uFrMxi4acDuiLE4eXLlTbSy8ylcTjsgsL vSLUwwBUCMZAcYyG2SkHw5+8YHu1I8l7mumn6vferDsjLJql+YHEss1+jDDWu7Eb dTuropy4eBCtJ3nGbHiotdEOth8p+G46FLHze6nO1byo37aeIN4xYHqpLza6SADz sBJv/G6gx+vA3hHslExi3TEA1CJW5YM9YYkYxEQXTpryA9zEiS2zMClSx71Lj9US uGpK3QLoke5ky31viXFX5Ou4re9RcZGNymwearqk+kGMR5uHKKI= =CVAG -----END PGP SIGNATURE----- --J9Gm0/92Dye/GcaE-- From nobody Fri Dec 31 16:24:16 2021 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 9976C19360A6 for ; Fri, 31 Dec 2021 16:24:16 +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 4JQVp80t5lz4vJk for ; Fri, 31 Dec 2021 16:24:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 F35226C55 for ; Fri, 31 Dec 2021 16:24:15 +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 1BVGOF7N004602 for ; Fri, 31 Dec 2021 16:24:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BVGOFNd004601 for freebsd-arm@FreeBSD.org; Fri, 31 Dec 2021 16:24:15 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 260849] dwc_attach fails on cubiboard2 Date: Fri, 31 Dec 2021 16:24:16 +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: sg2342@googlemail.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640967856; 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=9zJWe/Txkn3vzO10aTHYWzIz6TB6GZKdWbaCR2Hprxk=; b=ltrdMEwNl18Dl3mg5eizQeGRFGijY7B7W/fPH23yCIh+4x01Oc51207lj8CKARvPRLPzo3 rDrdp4zvF0FqJzseqOqyq78X3hoaSaCLqMUkR8IG0OZJR3Tgt6tLr+b1THUQs60NKirDAb 0Pp4LokGlU+zNCqW72FAyQpv1kxTinTcktuDi3TkxtfD6zkTk9X4BrcdKozoyWudi/4lpV 7Va2WKPkL2n07SnQVyAuTu7qTxtgzSr6PKQHQfGVAVgg8sPF6b+BIPLNTmOFxSf5A3yZ45 bzq+UtAXYDDU4WCynJZnN0MgUPzcaZWS1y/RmbyWzBHFYFPph35jJrWX8WW+Iw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640967856; a=rsa-sha256; cv=none; b=L3SKWq1vPx51wZHPxGeVn8zwt/QV4sIAR79F/twQj+FxAfXmMfTE0QlXf4vUkEYXT5cFgT 7B58FJicjBmse3tw0POub/+ZHXBd79Mx7WW2kfLzlWvu8144iA40UcxloDDyPhTWzCuF+2 VKNyPya2FV192HTbLNtXgKbUmuIQH61XBH6hnKDMq4p/pqREqlCeTnq3L94Ji42cBl3+Gc rmnCCtCbXMqqU9L9MeSUeobA5fjVVKTUG1krj0zxgvb0HZHNs+1t+E9Hvco0hbrjzlYdMv pqeLWtHp7gPOf7hhS6SGiP/ydU3C9Jg6FcTcDztI+xYH1uwBtVmlhacYovuyoQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1043 Lines: 36 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260849 Bug ID: 260849 Summary: dwc_attach fails on cubiboard2 Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sg2342@googlemail.com my comment in review R10:f77d8d10115b0863cc3dfd6e1746c02847d6569d This commit changed the behavior of dwc_attach() in a way that broke ethern= et on my Allwinner A20 based cubieboard2: root@cubieboard2:~ # ofwdump -P 'phy-mode' /soc/ethernet@1c50000 Node 0x5354: ethernet@1c50000 phy-mode: 6d 69 69 00 'mii' before this commit; dwc_attach() on the cubieboard2 would leave set sc->phy_mode alone (which is fine since sys/arm/allwinner/aw_if_dwc. c does not need this information). now it fails with ENXIO. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 31 16:24:16 2021 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 9979D1935DF8 for ; Fri, 31 Dec 2021 16:24:16 +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 4JQVp80p6rz4vB7 for ; Fri, 31 Dec 2021 16:24:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 F0A4C6E1C for ; Fri, 31 Dec 2021 16:24:15 +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 1BVGOF2E004600 for ; Fri, 31 Dec 2021 16:24:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BVGOFMK004599 for freebsd-arm@FreeBSD.org; Fri, 31 Dec 2021 16:24:15 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 260848] dwc_attach fails on cubiboard2 Date: Fri, 31 Dec 2021 16:24:16 +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: sg2342@googlemail.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640967856; 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=44lezojH1ORq9OXRbmcs+tw82bAp3DjFzUHDDRDQz5c=; b=FtybGFTw93QcOD1ps6JBRPlkVjjXgg3AJ/NJRkagzR+sATcpJL5O4jm+4T3jjUAc6ZtdlB rjU8rPTusV4GbJ8UJ/klLFCVEyssQ0QPYer3Ug2+u7cfm9XRVhHAq/fTF+KJL/ME8Q1e/f FJhmyvLM2q9wmrT20H1E6cAWHYJW/hEu3VfbzET9xNwKxNXsQDClDNxk2IL9cE/KWPr1Jg re+7mUckyxOReaEoEoPKZy9D+qOnSVwfVmRrSQUS8T1nSLRGKjVO4zEyCFkuVX3gmVoHpy 1kDCuRNGfkt2t/F9CVl6igdxjYIBwX1n9TADkRI+wW7m5Mn6yZ/iYrwIE8txJg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640967856; a=rsa-sha256; cv=none; b=ovVht055/ULzKvLpcwbTfNgdbhbCyxi3VDH9bocCR9E2Jy6BpZNhwATQDyvX7r/bGyttHV rGLX3Xkc1qgS7+QQV2SHM43wb3Hauu6FGSN07D1zkJEQcSBOgYM4mxOj2o1XEa12kiF5e8 2Pj5nsNahjfuUhndIv1+aA2phKQb/wDAQ9xnDsYUX0cGqAjUZ1dvC2D1WaEuMPTAzAdBg6 gr2lr49yKmkEqcQNups0gHLq4H1C7a1f9R0ZnrtuzrqpqV+06mO02CA3SG+xDnD8UHxoWu YZSpGa/jbac/WrA7tWl6KpsQ+K9UYGU/A2hFUdL/+HAMlU6G6VjAIfL+64XfHg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1043 Lines: 36 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260848 Bug ID: 260848 Summary: dwc_attach fails on cubiboard2 Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sg2342@googlemail.com my comment in review R10:f77d8d10115b0863cc3dfd6e1746c02847d6569d This commit changed the behavior of dwc_attach() in a way that broke ethern= et on my Allwinner A20 based cubieboard2: root@cubieboard2:~ # ofwdump -P 'phy-mode' /soc/ethernet@1c50000 Node 0x5354: ethernet@1c50000 phy-mode: 6d 69 69 00 'mii' before this commit; dwc_attach() on the cubieboard2 would leave set sc->phy_mode alone (which is fine since sys/arm/allwinner/aw_if_dwc. c does not need this information). now it fails with ENXIO. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 31 16:30:09 2021 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 2F8FC19371CD for ; Fri, 31 Dec 2021 16:30:13 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQVx01GpKz3Btk for ; Fri, 31 Dec 2021 16:30:12 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 14CA61EF1; Fri, 31 Dec 2021 16:30:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 14CA61EF1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1640968210; bh=jeDH+FA2Mm22fFd3qWyYtHwjFNFKjMgQSJUAlB1mEFY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=cvBq9YEUAqS6rtpzjeVo909pbyCrnaeaMtega6Z8NF8OauJkwYfBckhqjCAVU3yIp FLOAdyqC30abU+Rzzvt6wBVax5GMOQ421myj7vu7Wf7Z6Ugj1PrwdU5gmnGIq6ncaV l9gyJzrlIuhbeO3OF/H4hy8Wo3Kcl7me6sGQyOpg= Message-ID: <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.com> Date: Fri, 31 Dec 2021 16:30:09 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> From: Andrew Haley In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JQVx01GpKz3Btk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=cvBq9YEU; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [-1.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.39)[-0.394]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(0.84)[0.844]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 786 Lines: 27 On 12/31/21 13:32, tech-lists wrote: > Hi, > > On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: >> >> The PR is https://github.com/openjdk/aarch64-port/pull/14 >> The tree is https://github.com/openjdk/aarch64-port >> >> Checkout this PR locally: >> $ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 >> $ git checkout pull/14 >> >> Update a local copy of the PR: >> $ git checkout pull/14 >> $ git pull https://git.openjdk.java.net/aarch64-port pull/14/head > > I'll try testing this Thanks. It may be that OpenJDK hasn't been ported to FreeBSD/Arm64, but we'll see. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Fri Dec 31 16:50:20 2021 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 68B9A191363D for ; Fri, 31 Dec 2021 16:50:20 +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 4JQWND0h57z3G05 for ; Fri, 31 Dec 2021 16:50:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 E555A7284 for ; Fri, 31 Dec 2021 16:50:19 +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 1BVGoJhH013495 for ; Fri, 31 Dec 2021 16:50:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1BVGoJ6l013494 for freebsd-arm@FreeBSD.org; Fri, 31 Dec 2021 16:50:19 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 260849] dwc_attach fails on cubiboard2 Date: Fri, 31 Dec 2021 16:50:20 +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: sg2342@googlemail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640969420; 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=3biv3QlMnOJM+VIJ0MY6lJ+wyWP5uUhcVe0T8dSgtwU=; b=VMrvVL5Dwf41w8VpIHHorcoCC/MDbmea7JJwbtxZUq0ZRuKSVjYhhNjDkkyoWrALF5I2J9 QHW7b5tLoi/DHOsqnWuQwLSqB6Cas+a7cZA2R4VqjDesyzSXuWl5nfeTJ/x7hW8wEGxudf eLLeKZKznJLoilLOiBX3bAjOV2rlAs9bkZbFuA+0UmXOo+K2eQi47oRsqVJPinhg3BhUdS lxO09fltzqFBGMJ9W3KhWKslanNpk7LH1l7tomFWKjj2aPx0VQFc0naBLAil9Gh9fMQKN7 FmRHRojhYheHKaXdlHP7AH6QYdHSFIoGT0enDwt/CpyHJSw7objpEs0mUiHwEQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640969420; a=rsa-sha256; cv=none; b=qVKR8WdAr44LKVdpL5OvfiQa+AMv/NLI4vVtVC6POcEpNZ/JXLO4K3xPKHeA+TbMFqwyE0 NoiTcPLKh7g2CLxgeCqm0j883DyzLW1tGE+5jr+W5I3Ek/uLhg8hMC0Xe/j75yACfYULNc GHAWfc0iw3drmSmXBaBiv0soIeAAUEH8oKC/i41VBzPHi4uTPBY0ejGO4eAelRIYIeeDu1 5Krk5xxlo9if6JqGceK14GR0rvZfTr+0Sh8Qv/nZfju/a5cSFeu2OwEn7/+IZNfh/xTLbV i9Z/Qhvp/Y/9//MGSXq+Sn/wqjzTZ/8mBCiKhPrD2fAFIGID16YVDM6cRYkVdg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 567 Lines: 17 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260849 Stefan Grundmann changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |DUPLICATE --- Comment #1 from Stefan Grundmann --- *** This bug has been marked as a duplicate of bug 260848 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 31 17:09:01 2021 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 0131019163FD for ; Fri, 31 Dec 2021 17:09:11 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JQWnz0827z3HY0 for ; Fri, 31 Dec 2021 17:09:10 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8A0A15C0083 for ; Fri, 31 Dec 2021 12:09:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 31 Dec 2021 12:09:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=RXSxjm6Kil40am3aCQ5ON6/yVwM nwU/g4B4eg/W9siE=; b=Wlb7RNuhtYMJ3vVPO45lCBHuG5Lp45azC8b0EDlZcrB lVsS3baHnTiplSL6xlSWGPsbrH0GBerjD0aoW9Wy8NcjObO2k0bHcjl4HxDTZMeY o+I4wStyYWxNSRJvXO3dayegh7UcD9Ld8cCUtsPmbxJnvca53zK45Jn/h8AkO1YU Ev0nPPYkHm75EbhZrdnzlqWoDTT54b0rxi50xySwetb59B6T0e3ypQswyugwV5a1 LihbDZPeZnWFS4qdtzp68y6zy8uUbjDe83Csfg/dTl9RAXKNOAtx3+Fr3VMgrpOk e7GSbde7SIVSrjM0rZQvFl5a62iyg/KnzIF0zamsIDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RXSxjm 6Kil40am3aCQ5ON6/yVwMnwU/g4B4eg/W9siE=; b=jN1ZxMdkd8fpHJrfKz6CBa hPWSKiwfsouvJUwjJD3kiUkt4hge6vj0yoBQKTC+AYWpE9jDn4+ccgcBbBW4VIB2 78DZD21uowevhJFL7HDVIoutiGzmCCYYAndXe5AFUW5wT8iG0itccpD/Q0cU8rlr OxseZ4uWP2qm/eELD9H3USVurgVNt1tr6gPKHQIZU8JcTUYXqmzJ4mkocv9VWVH4 lPNGOpnwcK8kW/aKtcS9MeawiFuM0c2YGAh1jddTfgEEPy2SYgwJDG4uipofDsCQ /3CZj0T7u8EqdHS1IUQ2gUv4JThC0O6wC5mtkEy7OMreL3mGImyZcSWX0ssb39VQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvhedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefggedtheetgeelgeevtdfggeejtd dukefgueehvdevgefgjeejjeekvdeifeefudenucffohhmrghinhepghhithhhuhgsrdgt ohhmpdhjrghvrgdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 31 Dec 2021 12:09:03 -0500 (EST) Date: Fri, 31 Dec 2021 17:09:01 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Call for testing: OpenJDK 11 on Arm64 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IxNCgNd5Td1LUgMj" Content-Disposition: inline In-Reply-To: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> X-Rspamd-Queue-Id: 4JQWnz0827z3HY0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=Wlb7RNuh; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=jN1ZxMdk; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3464 Lines: 106 --IxNCgNd5Td1LUgMj Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: >The PR is https://github.com/openjdk/aarch64-port/pull/14 >The tree is https://github.com/openjdk/aarch64-port > >Checkout this PR locally: > $ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 These instructions don't work, as far as I can tell. paste error? my error? I make a dir called ~/projects 1. cd ~/projects 2. ~/projects % git fetch https://git.openjdk.java.net/aarch64-port pull/14= /head:pull/14 fatal: not a git repository (or any parent up to mount point /usr) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). If I presume you meant 'git clone' rather than 'git fetch', this happens: ~/projects % git clone https://git.openjdk.java.net/aarch64-port pull/14/he= ad:pull/14 Cloning into 'pull/14/head:pull/14'... warning: redirecting to https://github.com/openjdk/aarch64-port/ remote: Enumerating objects: 1255843, done. remote: Counting objects: 100% (18712/18712), done. remote: Compressing objects: 100% (6840/6840), done. remote: Total 1255843 (delta 12183), reused 15395 (delta 10923), pack-reuse= d 1237131 Receiving objects: 100% (1255843/1255843), 516.32 MiB | 8.62 MiB/s, done. Resolving deltas: 100% (938788/938788), done. Updating files: 100% (64433/64433), done. ~/projects % If I then run > $ git checkout pull/14 this happens: fatal: not a git repository (or any parent up to mount point /usr) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). If I just clone like this: git clone https://git.openjdk.java.net/aarch64-p= ort then do this: cd aarch64-port/ % make You are not using GNU Make/gmake, this is a requirement then % gmake Please run 'bash configure' to create a configuration. then % bash configure it runs configure, if zip isn't installed, it'll fail there. Install zip, i= t fails=20 later if java isn't already installed like so: checking for javac... [not found] checking for java... [not found] configure: Could not find a valid Boot JDK. OpenJDK distributions are avail= able at http://jdk.java.net/. configure: This might be fixed by explicitly setting --with-boot-jdk configure: error: Cannot continue configure exiting with result code 1 OK, so I'll need to install a bootstrap. Has what I've downloaded so far in= cluded=20 the changes you want me to test? --=20 J. --IxNCgNd5Td1LUgMj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHPOSMACgkQs8o7QhFz NAUXWg//bmKsaaRPr/PIOjOSG+dF9rCbyF6uSvJHdQ/7rwb/OwS1bDMiZ+D+vgEb zb8QgtCBRiP2/LtlXgtiVkeY/6Ls/JPPWXPwBdMIfuHgabWdxd/tXu4MEa1DRSa2 sg+dOixdgFNdg81stjH69nW3EXfLMiryLZp2JK0gptjJtWfaMOcNwXdIUBiEDZl5 /rSeF6Bc6UEJ+ertt63GmDImX2nD+JIvMGKjI9Nz719sIiK50p25QHsTWA+sUq/x /kC98/3lcR/Uf/KIZPf1pE0zTmcKZ65eok1ZVXiIDSyRUOPjFRYo+z120Z4NcsHZ PdnqseON1o5RgcpHIiZcUJfPV3capMr5ynhvsSjJIA9BEY5PD1pGCaWobmxxJrCb x/fC6bA0/A6OT0XoJfB9QkhW8llk8zIhAGe/K7LN2UpsIXM+7fArZbaxQd+a0Cap LifeuWseOhtD8qnDc0+9qSVrEl9nVcnzg0g1/NQc0exedKhfIAD1E69tLxgPLaS/ 0lo7tdnf9TmwU5ZBIqSjfbZfyDbracg1wTzilY7guULcCNCdIg/ft1I1FsqPn/+f y8MVgYnSAsnXW1YWmyEIyRBuJY41clVzk54lqjzhPmF660kZaY1HPAgVov/VhreW PMufmI3WE329Ocro+xfAD2oBrbY9rcWrETI1/EKGaJslJSusOJk= =uBxr -----END PGP SIGNATURE----- --IxNCgNd5Td1LUgMj-- From nobody Fri Dec 31 17:12:06 2021 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 47AC2191848D for ; Fri, 31 Dec 2021 17:12:09 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQWsN4vssz3JtQ for ; Fri, 31 Dec 2021 17:12:08 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 96F235C0079 for ; Fri, 31 Dec 2021 12:12:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 31 Dec 2021 12:12:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=0/SydJaX4VgnLmvliLSjWEleW7L bkHlC5qq4RXY0vN4=; b=MyWbjFPHoiRFVWuxFEWpz3ewYSRnwqzNfX8xcnp/ef0 tfn/UDTG2mK0Lk6yNFwUPSBmH2V1rpmgle+QwCk1pS3Ztv6ApPbyv9kgUAkCyQup uTi1aspkuR4htEPEw48wYJhOJow17s4y2KTGVL4Ao+TChb/LvQdYA9MDZS3S+o8G P88FtPmYv6GsWIioNjl78NeIkZh8qjegsZIL4YL/bG3gLO6rEg2i2LD/ARmLYKte wpkVh4HLSqwHS/sr12dMnelexmrZQMWibvKSfULRBxDafnUU6CjUC2AZHwX86TDC Pcf2HCNPHAlf/rt2HbWKXQjLU4TALLBMaCrQifQMz2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0/SydJ aX4VgnLmvliLSjWEleW7LbkHlC5qq4RXY0vN4=; b=LVHxQIWtl8lZ6r2ipZM6FS ZZhQm6uTASmIoVKuM54YL/3k+r/ULkwP34Atv1nVwTOKA5P8dqy1YjKddPzg259s PsxZNyrQSQxjTHbZWRklGDUi/E6LQsbRJF1lXvzX+00zGiCJViqUr69Oyjh8qkq5 zHQmRNZxZc6vgr0GT9YFksxOPiAiGbpfc97MecK6RaX1i/zlK+MzPChPtl1vnfMG vW8BkX7ce/MPFHLFOT/Tc5u6FqM53YgzZJ6ZFDwDhIaWN9boOoVA018PPlsmJqii 3Zh+sh3zs6hGKwrePep5/ul6Y+XyWItThwlmZk8e5olwFtQ41JlCNL1YhvWHC5IA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvhedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnhepueefkeeljefffeehheektdejhf ehfeegvdehhefgfeehveffvdevtedvgfeukeefnecuffhomhgrihhnpehfrhgvshhhphho rhhtshdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 31 Dec 2021 12:12:08 -0500 (EST) Date: Fri, 31 Dec 2021 17:12:06 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Call for testing: OpenJDK 11 on Arm64 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6/3wkmUGJLEvVHO8" Content-Disposition: inline In-Reply-To: <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.com> X-Rspamd-Queue-Id: 4JQWsN4vssz3JtQ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=MyWbjFPH; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=LVHxQIWt; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1370 Lines: 38 --6/3wkmUGJLEvVHO8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2021 at 04:30:09PM +0000, Andrew Haley wrote: >Thanks. It may be that OpenJDK hasn't been ported to FreeBSD/Arm64, but >we'll see. https://www.freshports.org/java/bootstrap-openjdk11/ ONLY_FOR_ARCHS: amd64 i386 powerpc64 powerpc64le aarch64 armv6 armv7 --=20 J. --6/3wkmUGJLEvVHO8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHPOeYACgkQs8o7QhFz NAVk/xAAqDQpCaSv3zdc+TDbT70zXuIjq15d+TLY41yALdrpQGCP8TbPfMqziW0f hPQo56GO0ixRZX4cr0j/5OXoueuY2t5nk6n4Q8RHOryFnTEosHu8V5rdDuDyoKz6 DWrK9veRj/e+pPOJFtOOYyVA0pbvLy+pIgcW4g5p8mRdwo219HndAtWdnGBe+KGN s5q3ba42cF6GHEjXdkgl2ok3hg+u1VqEcN+jdI2urI5UfxUKcQFdJvkjjxWRTiEv upqsyW4/MfSpomP0etjQZdaEfxip5ikU+rcWj7Q0hbZCOkxPjkH/P9Fz04q/mP+S VIwDj5X13v44Ct8f+6cToPWiNDmd3zkCnUoOQSohqoeHynQRc/O6LymMKB1v1zL9 DEZ0xoo+dL27/CeOOqm0TB2gJQuSOpXL0/ipY+FOqELWEVcs5/F6GLDzQSO5f58w SpOhB2uKbpF0QyaYB/MWGZ5IA4gYP8KmBAXTTuFMFzGxxYZT8Us17AhXx+DkyPln c5diYC5QJOds3jpd/wTgJGCCFXnKaRsNcV67YleEs6IVV3sLHLOw0xAmofbudGaf MRRT41U2ryhAH52r4aE8iVB5mH0DkL3+pvYAVNDwCfcGL9kSejFUd6mbzJZh8ImR fcWP2Zv0v/Eih/XALCBVRvcd/piVfhvcRFkaFHmBjEuQt+5TLys= =DQ+o -----END PGP SIGNATURE----- --6/3wkmUGJLEvVHO8-- From nobody Fri Dec 31 17:32:00 2021 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 7E256191B85F for ; Fri, 31 Dec 2021 17:32:09 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (littlepinkcloud.com [IPv6:2a00:1098:86:20::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQXJS2zZMz3Mxg for ; Fri, 31 Dec 2021 17:32:08 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 184551654; Fri, 31 Dec 2021 17:32:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 184551654 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1640971921; bh=pKpFKQ82u57zS6mGCWbnMgUfdikICliOH0bnJdIlk2U=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ZmyENMvgdOPc0gISyyCiZnd9dq448d3PqCLeP8QUq+m0Rsd/I7ayEnPYpQGIReiNV zzvB1WpgJOGuwMhzSESFtdNbwFkrZ0hrVUsRlTy6K+JnS77ZuREYWvMrNXmd2E23QS Tmf10xllaFZvgrr61x4EVQtRBWNq75woBE+/7+Zk= Message-ID: Date: Fri, 31 Dec 2021 17:32:00 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.com> From: Andrew Haley In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JQXJS2zZMz3Mxg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=ZmyENMvg; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 2a00:1098:86:20::3 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [-0.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.39)[-0.385]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 565 Lines: 18 On 12/31/21 17:12, tech-lists wrote: > On Fri, Dec 31, 2021 at 04:30:09PM +0000, Andrew Haley wrote: > >> Thanks. It may be that OpenJDK hasn't been ported to FreeBSD/Arm64, but >> we'll see. > > https://www.freshports.org/java/bootstrap-openjdk11/ > > ONLY_FOR_ARCHS: amd64 i386 powerpc64 powerpc64le aarch64 armv6 armv7 OK, so it should work. Please let me know what you discover. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Fri Dec 31 17:33:57 2021 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 78E52191CEC2 for ; Fri, 31 Dec 2021 17:34:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQXLc4x3sz3NFL for ; Fri, 31 Dec 2021 17:34:00 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 96C1C5C00A6 for ; Fri, 31 Dec 2021 12:34:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 31 Dec 2021 12:34:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=Mn1T/dlUTG0rLkJchLTCR7utCER 2GiQ3BVHVyjW+HVU=; b=eJLZ8Nwx0cCBUpLy8icT8mq4BzQy0ye93HFnGiKT8kH W6+O5ZO8331XSwhi8SLB+wBWNXroG84M4p2Zmy21cVmH34vE7Rc23QIV9PFnZ3ou y1bCRlKsYXt5h2aD1WW094ShpzPhpNNurlSCfZ3x5D9s023PdQY/vdQQT2hG+279 EpeSNqD5wSxhh1hFjHDQ8/cf1xPr0XcUss23QIZYfwkVtebVhbkSU1X5ln9whA5l jQnnOgPX9Wxl2xZ3VMVQ5UMRV8rlsfUIzW63COSOvf58bAnCBdTK93lswWJVz4ZX Wvc3FJSWblb5rwos8fPrcXXn2dSRT2rWhlDquw1UAIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Mn1T/d lUTG0rLkJchLTCR7utCER2GiQ3BVHVyjW+HVU=; b=kNXLpLiIwOT+PPkIs5TJx+ /OzFIeFhU6ZhQ6MDda8MhrmbWkZfd9qjAnrN20lqzUZqjHoltcOu14aZgYaaMVpJ 58F8BrrQOKWnvwlM6ViRYNij2RMZuvbbeEoRkiYdulQY7WNaAN/tJjWzodxGFCMA y1WbJbxTk556pVKa/Ktcsdhjj+O2UEA8zxn0yz2GpNnJAlKoDWw8tnfVr+JF1BfW JNCcAuFTm54Pud75z4OMjdVMqhZIvgfE7yMMPv97srKWH+1aGfW9l+QDbe71UBUG vQa/syEsKVbd+Zp8v1afE4xfyoDFd4okLemISj60qhFYfELxgF2MwMdYUXxFI/Mw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvhedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnhepueefkeeljefffeehheektdejhf ehfeegvdehhefgfeehveffvdevtedvgfeukeefnecuffhomhgrihhnpehfrhgvshhhphho rhhtshdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 31 Dec 2021 12:34:00 -0500 (EST) Date: Fri, 31 Dec 2021 17:33:57 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Call for testing: OpenJDK 11 on Arm64 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ID4Vn+4PcfI5XuYT" Content-Disposition: inline In-Reply-To: <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.com> X-Rspamd-Queue-Id: 4JQXLc4x3sz3NFL X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=eJLZ8Nwx; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=kNXLpLiI; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1540 Lines: 47 --ID4Vn+4PcfI5XuYT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2021 at 04:30:09PM +0000, Andrew Haley wrote: >Thanks. It may be that OpenJDK hasn't been ported to FreeBSD/Arm64, but >we'll see. I'm confused, because I read the subject line and thought "openjdk latest"= =20 but if you're talking about openjdk11 it's already in ports, in fact=20 there is openjdk15 https://www.freshports.org/java/openjdk15/ and it's marked ONLY_FOR_ARCHS: aarch64 amd64 i386 powerpc64 powerpc64le ? --=20 J. --ID4Vn+4PcfI5XuYT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHPPvkACgkQs8o7QhFz NAXyJg/9HCWdCi/kNtFxG+3euEtVqx1Qp4BV/c+fWSpUug/E2fV21L5wDbYfmAgv H0ICeKAlckXKVFVzHX8lYy/mgWRBukPS/8bJharxYd9R4HmBouGi3hkchX9Ff2xg N0rIl4342xucqfjrHHHT8ID2dea4nb6n7BmXGICAqU99ippY70l8D78A7EcUgIR1 lRqYQ0V+gAjL0Yr/9/MkoMPaObp56QUSprSjO338PVVOF45vmuq6HCx45pxmRHM2 A5O88nRueVnLgpQWP93w4j2jJTua5PbrkKofiqn+QlGngCYQ8uhHj3y2SIGQEoaa psY9XuFkN+Gp6QjE05XFv1tfeYJvDATffnfa38shZ3XKnXE7jHaxqI+UJCpNjA1e zPvi12C3+xUbrfbGHrRqtzqCeq2oEzphFF/BHXUG3z4miWboV6jyEBzhQK00Zk59 OvL0+1vWT+EFbhbcbcDrNQdQim/l23pSE5qU9WCadsV/K+l0fggFX6e0PCupFM4t YAn4730ILQVHYXjEXo9N2okO/KBCM97h6BtW+LdwnaZUwO1J3ayQRgyYO1ZccEfR qY39W7tx/dMlmj9/hPom6CNx7ei0UUUPEmVSC6y0sCJd+bkFiqtux3Tu2N6eD5Ji EJcQpSraEWBumeqVFRVY2rLEOI2DoxKOrOdX2qQkdUQnr4xShhU= =aT4y -----END PGP SIGNATURE----- --ID4Vn+4PcfI5XuYT-- From nobody Fri Dec 31 17:41:53 2021 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 83D73191E4E1 for ; Fri, 31 Dec 2021 17:41:55 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQXWk6d4Vz3PNc for ; Fri, 31 Dec 2021 17:41:54 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id DBC0526A3; Fri, 31 Dec 2021 17:41:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk DBC0526A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1640972513; bh=bCqMtJsnkCcOogLTFQnJLrTuZfQEcbwvEosuD6X1+Lk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=miM9SY4NJzYw0Slhz6ZwRZAteqlLSySCo0ubDmFyQiUI7860OA/BNIXgp9IUM8kU2 RJxnipWgIzRxe9oHDPVXJALQJTlsx/fahtCHt8MMgP4/CCu8LTtX/2dPqPAMBkETdZ uHW+ZamTvHKGJoJnM2wRlXZDfp1gTodPW2KAxNDw= Message-ID: Date: Fri, 31 Dec 2021 17:41:53 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> From: Andrew Haley In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JQXWk6d4Vz3PNc X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=miM9SY4N; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [1.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.37)[-0.367]; NEURAL_SPAM_SHORT(0.92)[0.923]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1759 Lines: 60 On 12/31/21 17:09, tech-lists wrote: > Hi, > > On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: > >> The PR is https://github.com/openjdk/aarch64-port/pull/14 >> The tree is https://github.com/openjdk/aarch64-port >> >> Checkout this PR locally: >> $ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 > > These instructions don't work, as far as I can tell. paste error? my error? Sorry. First git clone https://github.com/openjdk/aarch64-port cd aarch64-port then git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 git checkout pull/14 > cd aarch64-port/ > % make > You are not using GNU Make/gmake, this is a requirement > > then > % gmake > Please run 'bash configure' to create a configuration. > > then > % bash configure > > it runs configure, if zip isn't installed, it'll fail there. Install zip, it fails > later if java isn't already installed like so: > > checking for javac... [not found] > checking for java... [not found] > configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. > configure: This might be fixed by explicitly setting --with-boot-jdk > configure: error: Cannot continue > configure exiting with result code 1 > > OK, so I'll need to install a bootstrap. Has what I've downloaded so far included > the changes you want me to test? I think so. Unfortunately OpenJDK has a lot of deps. If there is already a FreeBSD package for OpenJDK, I would build that first, which would (I guess) pull in all of the deps that OpenJDK needs. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Fri Dec 31 19:19:08 2021 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 CEE92192EF02 for ; Fri, 31 Dec 2021 19:19:10 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQZgx4cffz3rNJ for ; Fri, 31 Dec 2021 19:19:09 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 9ECC71EF1; Fri, 31 Dec 2021 19:19:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 9ECC71EF1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1640978348; bh=pLGg+vVjViGHC4En6Z6K07psUwb54jfhyNuYblNGcAs=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GArFU856tDrmijzH7L8VYI3IZ6ZHZAHl9Nj0cQxMmx7IKvNND1cpg5Qs1QAhsKC4t xnhDJHd/ERT3iWTEYA9iMh9I3MiYsOAT0VitQUtku0L+y+UvI5p8NK5524biVQJ/Zm aLSw5OAzKtVcCnegO4KzUYGG5vNbHE1UQ2ToXr+s= Message-ID: Date: Fri, 31 Dec 2021 19:19:08 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <20cac8df-eff3-9685-f6a6-66c998159e99@littlepinkcloud.com> From: Andrew Haley In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JQZgx4cffz3rNJ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=GArFU856; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [1.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.16)[-0.158]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 830 Lines: 27 On 12/31/21 17:33, tech-lists wrote: > On Fri, Dec 31, 2021 at 04:30:09PM +0000, Andrew Haley wrote: > >> Thanks. It may be that OpenJDK hasn't been ported to FreeBSD/Arm64, but >> we'll see. > > I'm confused, because I read the subject line and thought "openjdk latest" > but if you're talking about openjdk11 it's already in ports, in fact > there is openjdk15 > > https://www.freshports.org/java/openjdk15/ > > and it's marked > > ONLY_FOR_ARCHS: aarch64 amd64 i386 powerpc64 powerpc64le Yes, I'm very pleased that you have told me that: I didn't know. The thing I'd like to make sure is that this new proposed patch doesn't break BSD/Arm64. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Sun Jan 2 02:58:18 2022 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 76458191D938 for ; Sun, 2 Jan 2022 02:58:25 +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 4JRNqN36SDz4bRF for ; Sun, 2 Jan 2022 02:58:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2022wJki042741 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 1 Jan 2022 18:58:19 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2022wJB2042740 for freebsd-arm@freebsd.org; Sat, 1 Jan 2022 18:58:19 -0800 (PST) (envelope-from fbsd) Date: Sat, 1 Jan 2022 18:58:18 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20220102025818.GA42622@www.zefox.net> References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@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: <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> X-Rspamd-Queue-Id: 4JRNqN36SDz4bRF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.87 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[zefox.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.87)[0.866]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:~]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2431 Lines: 70 Coming back to the saving of u-boot environment variables, backing down to a much older set of FAT files seems to help. The machine now has a DOS-only microSD with an old set of files: root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dc4 VC_BUILD_ID_TIME: 15:31:38 VC_BUILD_ID_BRANCH: master VC_BUILD_ID_TIME: Jun 7 2018 With this suite of bootfiles it's possible to save a value for usb_pgood_delay of 19000, which in most cases results in a hands- off detection of the usb hard disk (via a powered hub): MMC: mmc@7e300000: 1 Loading Environment from FAT... OK In: serial Out: vidconsole Err: vidconsole Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 Intervention with run bootcmd_usb0 gives a successful boot from USB. If nothing is touched, the console displays: MMC Device 0 not found no mmc device at slot 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found EFI removable media binary efi/boot/bootaa64.efi BootOrder not defined libfdt fdt_check_header(): FDT_ERR_BADMAGIC Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0x39e91000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8217.4096) Console: comconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x 01,0,0x81f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0 ,0x81f,0x18fa8) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 97c7,0x7726839) Setting currdev to disk0p2: Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. Type '?' for a list of commands, 'help' for more detailed help. It looks like the root device is still the microSD card, even though the USB disk has been found. Any suggestions appreciated. There's a complete and recent ports tree if it's helpful, attempts to use it on my own have caused more trouble than they've solved, in particular that's what lead to the "saving to FAT....FAILED" messages. . Thanks for reading, bob prohaska From nobody Sun Jan 2 06:54:02 2022 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 A45DB18FF85C for ; Sun, 2 Jan 2022 06:54:21 +0000 (UTC) (envelope-from aaegic@gmail.com) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 4JRV3c5Xb5z3H2W for ; Sun, 2 Jan 2022 06:54:20 +0000 (UTC) (envelope-from aaegic@gmail.com) Received: by mail-ed1-f53.google.com with SMTP id b13so123882820edd.8 for ; Sat, 01 Jan 2022 22:54:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rOOgj9b7BVMG6XB0Zg67zkRc0FPOLGp8iu7WBRixxHk=; b=0ephWvCQ4vM1UPvfvWrdTUMEeG85x9qD3ABe0gCGmgJ1xEs7yNiVUh0qOaagOh7CCw c8vIsWiv3ZA909Gd3qqJLT/1wlZ+5WydD5DGBpB2jEpk/6NOij3NLC0xqisCWX7++Swm HmZbDd/cUK0LraxkklKEfyE+Ar1Y3QcyPM95YMCIdjQ5sdsKGvVBIBf2LBRFPapnx66W jll2+5t1hNvaIOrM/AL+bGCPhoNrlMLbAZKC0fuAz+xlfaLhC75AGEkJFef4eTvUw6PA ohTU5n+TmLl0qnZfAgIsuO0oXj9MLd1OEouprwF7y9TQn6J2iHPbdWlAx1d39t2ZebKk IQ3A== X-Gm-Message-State: AOAM5333ICTP0Yr+20luJaVzX1AbkzGJ7yL/0K7WKoJQg7ru2/oYb4xg xUOg2mJ6ev3lr1v12y6m9jMBRVl01lKDQw== X-Google-Smtp-Source: ABdhPJxUIxudnES2+kgspB/cTDafg2EmfyYIPGrCIEMt5A3CZlHOrOm2xIJfyw2veVnJiWyZDFKATw== X-Received: by 2002:a17:907:9726:: with SMTP id jg38mr34374334ejc.149.1641106453461; Sat, 01 Jan 2022 22:54:13 -0800 (PST) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41]) by smtp.gmail.com with ESMTPSA id qt5sm9575866ejb.214.2022.01.01.22.54.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Jan 2022 22:54:13 -0800 (PST) Received: by mail-ed1-f41.google.com with SMTP id w16so123999671edc.11 for ; Sat, 01 Jan 2022 22:54:13 -0800 (PST) X-Received: by 2002:a05:6402:2787:: with SMTP id b7mr34375375ede.362.1641106452926; Sat, 01 Jan 2022 22:54:12 -0800 (PST) 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 From: Adrian Maliszewski Date: Sun, 2 Jan 2022 01:54:02 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Elasticsearch / OpenJDK8 fails to start on 13.0-RELEASE on arm64 To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="0000000000002a722505d493df53" X-Rspamd-Queue-Id: 4JRV3c5Xb5z3H2W X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of aaegic@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=aaegic@gmail.com X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.90)[-0.903]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[aftre.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.53:from,209.85.208.41:received]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FORGED_SENDER(0.30)[adrian@aftre.net,aaegic@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.53:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[adrian@aftre.net,aaegic@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 23275 Lines: 358 --0000000000002a722505d493df53 Content-Type: multipart/alternative; boundary="0000000000002a722205d493df51" --0000000000002a722205d493df51 Content-Type: text/plain; charset="UTF-8" Hello freebsd-arm, Trying to start elasticsearch installed from packages on 13.0-release arm64 FreeBSD devbox 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:38:07 UTC 2021 root@arm64-builder.daemonology.net:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 results in message from openjdk8 [root@develk /usr/ports/java/openjdk8]# service elasticsearch onestart Starting elasticsearch. # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000000004224b9a0, pid=14774, tid=0x0000000000018807 # # JRE version: (8.0_302-b08) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.302-b08 mixed mode bsd-aarch64 compressed oops) # Problematic frame: # v ~BufferBlob::native signature handlers # # Core dump written. Default location: //java.core # # An error report file with more information is saved as: # /tmp/hs_err_pid14774.log # # If you would like to submit a bug report, please visit: # https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Ports%20%26%20Packages&component=Individual%20Port(s)&short_desc=java/openjdk8%3A%20 # /usr/local/lib/elasticsearch/bin/elasticsearch-env: line 88: 14774 Abort trap "$JAVA" "$XSHARE" -cp "$ES_CLASSPATH" org.elasticsearch.tools.java_version_checker.JavaVersionChecker /usr/local/etc/rc.d/elasticsearch: WARNING: failed to start elasticsearch Best regards, happy new year, AM --0000000000002a722205d493df51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello freebsd-arm,
Trying to start elasticsearch inst=
alled from packages on 13.0-release arm64

FreeBSD devbox 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:38=
:07 UTC 2021     root=
@arm64-builder.daemonology.net:/usr/obj/usr/src/arm64.aarch64/sys/GENER=
IC  arm64

results in message from openjdk8


[root@develk /usr/ports/java/openjdk8]# service elasticsearch onestart
Starting elasticsearch.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=3D0x000000004224b9a0, pid=3D14774, tid=3D0x0000000000=
018807
#
# JRE version:  (8.0_302-b08) (build )
# Java VM: OpenJDK 64-Bit Server VM (25.302-b08 mixed mode bsd-aarch64 comp=
ressed oops)
# Problematic frame:
# v  ~BufferBlob::native signature handlers
#
# Core dump written. Default location: //java.core
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid14774.log
#
# If you would like to submit a bug report, please visit:
#   https://bugs.freebsd.org/bugzilla/enter_bug.cgi?produc=
t=3DPorts%20%26%20Packages&component=3DIndividual%20Port(s)&short_d=
esc=3Djava/openjdk8%3A%20
#
/usr/local/lib/elasticsearch/bin/elasticsearch-env: line 88: 14774 Abort tr=
ap              "$JAVA" "$XSHARE" -cp "$ES_CLASSPA=
TH" org.elasticsearch.tools.java_version_checker.JavaVersionChecker
/usr/local/etc/rc.d/elasticsearch: WARNING: failed to start elasticsearch
Best regards, happy new year,
AM

--0000000000002a722205d493df51-- --0000000000002a722505d493df53 Content-Type: application/octet-stream; name="hs_err_pid14774.log" Content-Disposition: attachment; filename="hs_err_pid14774.log" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kxwwadlk0 IwojIEEgZmF0YWwgZXJyb3IgaGFzIGJlZW4gZGV0ZWN0ZWQgYnkgdGhlIEphdmEgUnVudGltZSBF bnZpcm9ubWVudDoKIwojICBTSUdJTEwgKDB4NCkgYXQgcGM9MHgwMDAwMDAwMDQyMjRiOWEwLCBw aWQ9MTQ3NzQsIHRpZD0weDAwMDAwMDAwMDAwMTg4MDcKIwojIEpSRSB2ZXJzaW9uOiAgKDguMF8z MDItYjA4KSAoYnVpbGQgKQojIEphdmEgVk06IE9wZW5KREsgNjQtQml0IFNlcnZlciBWTSAoMjUu MzAyLWIwOCBtaXhlZCBtb2RlIGJzZC1hYXJjaDY0IGNvbXByZXNzZWQgb29wcykKIyBQcm9ibGVt YXRpYyBmcmFtZToKIyB2ICB+QnVmZmVyQmxvYjo6bmF0aXZlIHNpZ25hdHVyZSBoYW5kbGVycwoj CiMgQ29yZSBkdW1wIHdyaXR0ZW4uIERlZmF1bHQgbG9jYXRpb246IC8vamF2YS5jb3JlCiMKIyBJ ZiB5b3Ugd291bGQgbGlrZSB0byBzdWJtaXQgYSBidWcgcmVwb3J0LCBwbGVhc2UgdmlzaXQ6CiMg ICBodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvZW50ZXJfYnVnLmNnaT9wcm9kdWN0 PVBvcnRzJTIwJTI2JTIwUGFja2FnZXMmY29tcG9uZW50PUluZGl2aWR1YWwlMjBQb3J0KHMpJnNo b3J0X2Rlc2M9amF2YS9vcGVuamRrOCUzQSUyMAojCgotLS0tLS0tLS0tLS0tLS0gIFQgSCBSIEUg QSBEICAtLS0tLS0tLS0tLS0tLS0KCkN1cnJlbnQgdGhyZWFkICgweDAwMDAwMDAwNDIwNjEwMDAp OiAgSmF2YVRocmVhZCAibWFpbiIgW190aHJlYWRfaW5fSmF2YSwgaWQ9MTAwMzU5LCBzdGFjaygw eDAwMDBmZmZmYmZkZmUwMDAsMHgwMDAwZmZmZmJmZmZlMDAwKV0KCnNpZ2luZm86IHNpX3NpZ25v OiA0IChTSUdJTEwpLCBzaV9jb2RlOiA0IChJTExfSUxMVFJQKSwgc2lfYWRkcjogMHgwMDAwMDAw MDQxODAwMDAwCgpSZWdpc3RlcnM6ClIwID0weDAwMDAwMDAwNDIwMmM5ODAgaXMgYW4gdW5rbm93 biB2YWx1ZQpSMSA9MHgwMDAwMDAwMDAwMDAwMDAwIGlzIGFuIHVua25vd24gdmFsdWUKUjIgPTB4 MDAwMDAwMDAwMDAwMDAxOCBpcyBhbiB1bmtub3duIHZhbHVlClIzID0weDAwMDAwMDAwMDAwMDAw MDAgaXMgYW4gdW5rbm93biB2YWx1ZQpSNCA9MHgwMDAwMDAwMDQyMjUzYTE4IGlzIGF0IGNvZGVf YmVnaW4rMjQgaW4gCltDb2RlQmxvYiAoMHgwMDAwMDAwMDQyMjUzOTkwKV0KRnJhbWVzaXplOiAw CkJ1ZmZlckJsb2IgKDB4MDAwMDAwMDA0MjI1Mzk5MCkgdXNlZCBmb3IgU2lnbmF0dXJlIEhhbmRs ZXIgVGVtcCBCdWZmZXIKUjUgPTB4MDAwMDAwMDA0MjI0YjliOCBpcyBhdCBjb2RlX2JlZ2luKzU2 IGluIApbQ29kZUJsb2IgKDB4MDAwMDAwMDA0MjI0YjkxMCldCkZyYW1lc2l6ZTogMApCdWZmZXJC bG9iICgweDAwMDAwMDAwNDIyNGI5MTApIHVzZWQgZm9yIG5hdGl2ZSBzaWduYXR1cmUgaGFuZGxl cnMKUjYgPTB4Zjg1ZjgzMDI5MTAwMDMwMSBpcyBhbiB1bmtub3duIHZhbHVlClI3ID0weGYyYTg0 NDIwZDI4MTdlMDAgaXMgYW4gdW5rbm93biB2YWx1ZQpSOCA9MHgwMDAwMDAwMDAwMDAwMDAwIGlz IGFuIHVua25vd24gdmFsdWUKUjkgPTB4ZWUxZmI2NmUwNzQyYjQ2OCBpcyBhbiB1bmtub3duIHZh bHVlClIxMD0weDAwMDAwMDAwMDAwMDAwMDcgaXMgYW4gdW5rbm93biB2YWx1ZQpSMTE9MHgwMDAw MDAwMDAwMDAwMDA2IGlzIGFuIHVua25vd24gdmFsdWUKUjEyPXttZXRob2R9IHsweDAwMDAwMDAw NGJlMzA3NDB9ICdzZXRQcmlvcml0eTAnICcoSSlWJyBpbiAnamF2YS9sYW5nL1RocmVhZCcKUjEz PTB4ZDY1ZjAzYzBmMmMwMDAwMCBpcyBhbiB1bmtub3duIHZhbHVlClIxND0weDAwMDAwMDAwNDIw NmYxMDAgaXMgYW4gdW5rbm93biB2YWx1ZQpSMTU9MHgwMDAwMDAwMDRiZTJiZTIwIGlzIHBvaW50 aW5nIGludG8gbWV0YWRhdGEKUjE2PTB4MDAwMDAwMDA0MWJiNjcyODogZ0hvdFNwb3RWTUxvbmdD b25zdGFudHMrMHhhYTggaW4gL3Vzci9sb2NhbC9vcGVuamRrOC9qcmUvbGliL2FhcmNoNjQvc2Vy dmVyL2xpYmp2bS5zbyBhdCAweDAwMDAwMDAwNDEwMDAwMDAKUjE3PTB4MDAwMDAwMDA0MjI0Yjlh MCBpcyBhdCBjb2RlX2JlZ2luKzMyIGluIApbQ29kZUJsb2IgKDB4MDAwMDAwMDA0MjI0YjkxMCld CkZyYW1lc2l6ZTogMApCdWZmZXJCbG9iICgweDAwMDAwMDAwNDIyNGI5MTApIHVzZWQgZm9yIG5h dGl2ZSBzaWduYXR1cmUgaGFuZGxlcnMKUjE4PTB4MDAwMGZmZmZiZmZmYzJmOCBpcyBwb2ludGlu ZyBpbnRvIHRoZSBzdGFjayBmb3IgdGhyZWFkOiAweDAwMDAwMDAwNDIwNjEwMDAKUjE5PTB4MDAw MDAwMDAwMDAwMDBiNyBpcyBhbiB1bmtub3duIHZhbHVlClIyMD0weDAwMDBmZmZmYmZmZmQ3NjAg aXMgcG9pbnRpbmcgaW50byB0aGUgc3RhY2sgZm9yIHRocmVhZDogMHgwMDAwMDAwMDQyMDYxMDAw ClIyMT0weDAwMDAwMDAwNDFjMDIyMzA6IGdIb3RTcG90Vk1Mb25nQ29uc3RhbnRzKzB4NGM1YjAg aW4gL3Vzci9sb2NhbC9vcGVuamRrOC9qcmUvbGliL2FhcmNoNjQvc2VydmVyL2xpYmp2bS5zbyBh dCAweDAwMDAwMDAwNDEwMDAwMDAKUjIyPTB4MDAwMDAwMDAwMDAwMDAwMCBpcyBhbiB1bmtub3du IHZhbHVlClIyMz0weDAwMDAwMDAwNDIyMDAzN2MgaXMgYXQgYmVnaW4rMCBpbiBhIHN0dWIKU3R1 YlJvdXRpbmVzOjpjYWxsX3N0dWIgWzB4MDAwMDAwMDA0MjIwMDM3YywgMHgwMDAwMDAwMDQyMjAw NDhjWyAoMjcyIGJ5dGVzKQpSMjQ9MHgwMDAwZmZmZmJmZmZkN2Q4IGlzIHBvaW50aW5nIGludG8g dGhlIHN0YWNrIGZvciB0aHJlYWQ6IDB4MDAwMDAwMDA0MjA2MTAwMApSMjU9MHgwMDAwZmZmZmJm ZmZkZGE4IGlzIHBvaW50aW5nIGludG8gdGhlIHN0YWNrIGZvciB0aHJlYWQ6IDB4MDAwMDAwMDA0 MjA2MTAwMApSMjY9MHgwMDAwMDAwMDRiZWI2OGMwIGlzIHBvaW50aW5nIGludG8gbWV0YWRhdGEK UjI3PTB4MDAwMDAwMDAwMDAwMDAwMCBpcyBhbiB1bmtub3duIHZhbHVlClIyOD0weDAwMDAwMDAw NDIwNjEwMDAgaXMgYSB0aHJlYWQKUjI5PTB4MDAwMGZmZmZiZmZmZDdiMCBpcyBwb2ludGluZyBp bnRvIHRoZSBzdGFjayBmb3IgdGhyZWFkOiAweDAwMDAwMDAwNDIwNjEwMDAKClRvcCBvZiBTdGFj azogKHNwPTB4MDAwMGZmZmZiZmZmZDc2MCkKMHgwMDAwZmZmZmJmZmZkNzYwOiAgIDAwMDAwMDAw NDIyMTRlZWMgMDAwMDAwMDA0YmUzMDc0MAoweDAwMDBmZmZmYmZmZmQ3NzA6ICAgMDAwMGZmZmZi ZmZmZDc3MCAwMDAwMDAwMDAwMDAwMDAwCjB4MDAwMGZmZmZiZmZmZDc4MDogICAwMDAwZmZmZmJm ZmZkN2Q4IDAwMDAwMDAwNGJlYjY4YzAKMHgwMDAwZmZmZmJmZmZkNzkwOiAgIDAwMDAwMDAwMDAw MDAwMDAgMDAwMDAwMDA0YmUzMDc0MAoweDAwMDBmZmZmYmZmZmQ3YTA6ICAgMDAwMDAwMDAwMDAw MDAwMCAwMDAwZmZmZmJmZmZkN2EwCjB4MDAwMGZmZmZiZmZmZDdiMDogICAwMDAwZmZmZmJmZmZk ODIwIDAwMDAwMDAwNDIyMDg0OTgKMHgwMDAwZmZmZmJmZmZkN2MwOiAgIDAwMDAwMDAwMDAwMDAw MDAgMDAwMDAwMDAwMDAwMDAwMAoweDAwMDBmZmZmYmZmZmQ3ZDA6ICAgMDAwMDAwMDAwMDAwMDAw NSAwMDAwMDAwMGY1ODA1ZDM4CjB4MDAwMGZmZmZiZmZmZDdlMDogICAwMDAwZmZmZmJmZmZkN2Uw IDAwMDAwMDAwNGJlMmYwYTQKMHgwMDAwZmZmZmJmZmZkN2YwOiAgIDAwMDBmZmZmYmZmZmQ4NDgg MDAwMDAwMDA0YmViNjhjMAoweDAwMDBmZmZmYmZmZmQ4MDA6ICAgMDAwMDAwMDAwMDAwMDAwMCAw MDAwMDAwMDRiZTJmMGI4CjB4MDAwMGZmZmZiZmZmZDgxMDogICAwMDAwZmZmZmJmZmZkN2QwIDAw MDBmZmZmYmZmZmQ4MTAKMHgwMDAwZmZmZmJmZmZkODIwOiAgIDAwMDBmZmZmYmZmZmQ4OTAgMDAw MDAwMDA0MjIwODQ5OAoweDAwMDBmZmZmYmZmZmQ4MzA6ICAgMDAwMGZmZmZiZmZmZDg5MCAwMDAw MDAwMGY1ODA1ODM4CjB4MDAwMGZmZmZiZmZmZDg0MDogICAwMDAwMDAwMDAwMDAwMDA1IDAwMDAw MDAwZjU4MDVkMzgKMHgwMDAwZmZmZmJmZmZkODUwOiAgIDAwMDBmZmZmYmZmZmQ4NTAgMDAwMDAw MDA0YmUyZGNmNAoweDAwMDBmZmZmYmZmZmQ4NjA6ICAgMDAwMGZmZmZiZmZmZDhlOCAwMDAwMDAw MDRiZWI2OGMwCjB4MDAwMGZmZmZiZmZmZDg3MDogICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw NGJlMmRkNDgKMHgwMDAwZmZmZmJmZmZkODgwOiAgIDAwMDBmZmZmYmZmZmQ4NDAgMDAwMGZmZmZi ZmZmZDg5MAoweDAwMDBmZmZmYmZmZmQ4OTA6ICAgMDAwMGZmZmZiZmZmZDkzMCAwMDAwMDAwMDQy MjA4NDk4CjB4MDAwMGZmZmZiZmZmZDhhMDogICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwZjU4 MDVkMzgKMHgwMDAwZmZmZmJmZmZkOGIwOiAgIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAw MDAwMAoweDAwMDBmZmZmYmZmZmQ4YzA6ICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAw MDAwCjB4MDAwMGZmZmZiZmZmZDhkMDogICAwMDAwMDAwMGY1ODA1ZWIwIDAwMDAwMDAwMDAwMDAw MDAKMHgwMDAwZmZmZmJmZmZkOGUwOiAgIDAwMDAwMDAwZjU4MDU4MzggMDAwMDAwMDBmNTgwNWQz OAoweDAwMDBmZmZmYmZmZmQ4ZjA6ICAgMDAwMGZmZmZiZmZmZDhmMCAwMDAwMDAwMDRiZTJkYmIw CjB4MDAwMGZmZmZiZmZmZDkwMDogICAwMDAwZmZmZmJmZmZkOTY4IDAwMDAwMDAwNGJlYjY4YzAK MHgwMDAwZmZmZmJmZmZkOTEwOiAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA0YmUyZGJjMAow eDAwMDBmZmZmYmZmZmQ5MjA6ICAgMDAwMGZmZmZiZmZmZDhiMCAwMDAwZmZmZmJmZmZkOTIwCjB4 MDAwMGZmZmZiZmZmZDkzMDogICAwMDAwZmZmZmJmZmZkOWIwIDAwMDAwMDAwNDIyMDg0OTgKMHgw MDAwZmZmZmJmZmZkOTQwOiAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA0MjIwODQ5OAoweDAw MDBmZmZmYmZmZmQ5NTA6ICAgMDAwMDAwMDBmNTgwNWViMCAwMDAwMDAwMDAwMDAwMDAwIAoKSW5z dHJ1Y3Rpb25zOiAocGM9MHgwMDAwMDAwMDQyMjRiOWEwKQoweDAwMDAwMDAwNDIyNGI5ODA6ICAg MDAgN2UgODEgZDIgMjAgNDQgYTggZjIgMDAgMDAgYzAgZjIgYzAgMDMgNWYgZDYKMHgwMDAwMDAw MDQyMjRiOTkwOiAgIDgwIDdmIDgxIGQyIDIwIDQ0IGE4IGYyIDAwIDAwIGMwIGYyIGMwIDAzIDVm IGQ2CjB4MDAwMDAwMDA0MjI0YjlhMDogICAwMSAwMyAwMCA5MSAwMiA4MyA1ZiBmOCAwMCA3ZSA4 MSBkMiAyMCA0NCBhOCBmMgoweDAwMDAwMDAwNDIyNGI5YjA6ICAgMDAgMDAgYzAgZjIgYzAgMDMg NWYgZDYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgCgpSZWdpc3RlciB0byBtZW1vcnkgbWFwcGlu ZzoKClIwPTB4MDAwMDAwMDA0MjAyYzk4MApSMT0weDAwMDAwMDAwMDAwMDAwMDAKUjI9MHgwMDAw MDAwMDAwMDAwMDE4ClIzPTB4MDAwMDAwMDAwMDAwMDAwMApSND0weDAwMDAwMDAwNDIyNTNhMTgK UjU9MHgwMDAwMDAwMDQyMjRiOWI4ClI2PTB4Zjg1ZjgzMDI5MTAwMDMwMQpSNz0weGYyYTg0NDIw ZDI4MTdlMDAKUjg9MHgwMDAwMDAwMDAwMDAwMDAwClI5PTB4ZWUxZmI2NmUwNzQyYjQ2OApSMTA9 MHgwMDAwMDAwMDAwMDAwMDA3ClIxMT0weDAwMDAwMDAwMDAwMDAwMDYKUjEyPTB4MDAwMDAwMDA0 YmUzMDc0MApSMTM9MHhkNjVmMDNjMGYyYzAwMDAwClIxND0weDAwMDAwMDAwNDIwNmYxMDAKUjE1 PTB4MDAwMDAwMDA0YmUyYmUyMApSMTY9MHgwMDAwMDAwMDQxYmI2NzI4ClIxNz0weDAwMDAwMDAw NDIyNGI5YTAKUjE4PTB4MDAwMGZmZmZiZmZmYzJmOApSMTk9MHgwMDAwMDAwMDAwMDAwMGI3ClIy MD0weDAwMDBmZmZmYmZmZmQ3NjAKUjIxPTB4MDAwMDAwMDA0MWMwMjIzMApSMjI9MHgwMDAwMDAw MDAwMDAwMDAwClIyMz0weDAwMDAwMDAwNDIyMDAzN2MKUjI0PTB4MDAwMGZmZmZiZmZmZDdkOApS MjU9MHgwMDAwZmZmZmJmZmZkZGE4ClIyNj0weDAwMDAwMDAwNGJlYjY4YzAKUjI3PTB4MDAwMDAw MDAwMDAwMDAwMApSMjg9MHgwMDAwMDAwMDQyMDYxMDAwClIyOT0weDAwMDBmZmZmYmZmZmQ3YjAK CgpTdGFjazogWzB4MDAwMGZmZmZiZmRmZTAwMCwweDAwMDBmZmZmYmZmZmUwMDBdLCAgc3A9MHgw MDAwZmZmZmJmZmZkNzYwLCAgZnJlZSBzcGFjZT0yMDQ1awpOYXRpdmUgZnJhbWVzOiAoSj1jb21w aWxlZCBKYXZhIGNvZGUsIGo9aW50ZXJwcmV0ZWQsIFZ2PVZNIGNvZGUsIEM9bmF0aXZlIGNvZGUp CnYgIH5CdWZmZXJCbG9iOjpuYXRpdmUgc2lnbmF0dXJlIGhhbmRsZXJzCmogIGphdmEubGFuZy5U aHJlYWQuc2V0UHJpb3JpdHkoSSlWKzUyCmogIGphdmEubGFuZy5UaHJlYWQuaW5pdChMamF2YS9s YW5nL1RocmVhZEdyb3VwO0xqYXZhL2xhbmcvUnVubmFibGU7TGphdmEvbGFuZy9TdHJpbmc7Skxq YXZhL3NlY3VyaXR5L0FjY2Vzc0NvbnRyb2xDb250ZXh0O1opVisxNzIKaiAgamF2YS5sYW5nLlRo cmVhZC5pbml0KExqYXZhL2xhbmcvVGhyZWFkR3JvdXA7TGphdmEvbGFuZy9SdW5uYWJsZTtMamF2 YS9sYW5nL1N0cmluZztKKVYrOApqICBqYXZhLmxhbmcuVGhyZWFkLjxpbml0PihMamF2YS9sYW5n L1RocmVhZEdyb3VwO0xqYXZhL2xhbmcvU3RyaW5nOylWKzQ1CnYgIH5TdHViUm91dGluZXM6OmNh bGxfc3R1YgpWICBbbGlianZtLnNvKzB4NmNiM2ZjXSAgQXN5bmNHZXRDYWxsVHJhY2UrMHhkZmVm NApWICBbbGlianZtLnNvKzB4NmM5ZjU4XSAgQXN5bmNHZXRDYWxsVHJhY2UrMHhkZWE1MApWICBb bGlianZtLnNvKzB4NmNhMzIwXSAgQXN5bmNHZXRDYWxsVHJhY2UrMHhkZWUxOApWICBbbGlianZt LnNvKzB4YTcxZDg0XSAgSlZNX2hhbmRsZV9ic2Rfc2lnbmFsKzB4MTFjMmQ4ClYgIFtsaWJqdm0u c28rMHg3Mzk4MTBdICBKTklfQ3JlYXRlSmF2YVZNKzB4ODgKQyAgW2xpYmpsaS5zbysweDE1ZjM0 XSAgSkxJX0xhdW5jaCsweDE3NjQKQyAgW2xpYnRoci5zby4zKzB4MWVmZTBdICBwdGhyZWFkX2Ny ZWF0ZSsweDgyYwpDICBbbGlidGhyLnNvLjMrMHgxZWIzOF0gIHB0aHJlYWRfY3JlYXRlKzB4Mzg0 CgoKLS0tLS0tLS0tLS0tLS0tICBQIFIgTyBDIEUgUyBTICAtLS0tLS0tLS0tLS0tLS0KCkphdmEg VGhyZWFkczogKCA9PiBjdXJyZW50IHRocmVhZCApCj0+MHgwMDAwMDAwMDQyMDYxMDAwIEphdmFU aHJlYWQgIm1haW4iIFtfdGhyZWFkX2luX0phdmEsIGlkPTEwMDM1OSwgc3RhY2soMHgwMDAwZmZm ZmJmZGZlMDAwLDB4MDAwMGZmZmZiZmZmZTAwMCldCgpPdGhlciBUaHJlYWRzOgogIDB4MDAwMDAw MDA0MjAyYTgwMCBWTVRocmVhZCBbc3RhY2s6IDB4MDAwMGZmZmZiZjNmOTAwMCwweDAwMDBmZmZm YmY1ZjkwMDBdIFtpZD0xMDAzNjRdCgpWTSBzdGF0ZTpub3QgYXQgc2FmZXBvaW50IChub3JtYWwg ZXhlY3V0aW9uKQoKVk0gTXV0ZXgvTW9uaXRvciBjdXJyZW50bHkgb3duZWQgYnkgYSB0aHJlYWQ6 IE5vbmUKCmhlYXAgYWRkcmVzczogMHgwMDAwMDAwMGUwNjAwMDAwLCBzaXplOiA1MDYgTUIsIENv bXByZXNzZWQgT29wcyBtb2RlOiAzMi1iaXQKTmFycm93IGtsYXNzIGJhc2U6IDB4MDAwMDAwMDAw MDAwMDAwMCwgTmFycm93IGtsYXNzIHNoaWZ0OiAzCkNvbXByZXNzZWQgY2xhc3Mgc3BhY2Ugc2l6 ZTogMTA3Mzc0MTgyNCBBZGRyZXNzOiAweDAwMDAwMDAxMDAwMDAwMDAKCkhlYXA6CiBQU1lvdW5n R2VuICAgICAgdG90YWwgODE5MkssIHVzZWQgMTIySyBbMHgwMDAwMDAwMGY1ODAwMDAwLCAweDAw MDAwMDAwZjYyMDAwMDAsIDB4MDAwMDAwMDEwMDAwMDAwMCkKICBlZGVuIHNwYWNlIDYxNDRLLCAy JSB1c2VkIFsweDAwMDAwMDAwZjU4MDAwMDAsMHgwMDAwMDAwMGY1ODFlYjkwLDB4MDAwMDAwMDBm NWUwMDAwMCkKICBmcm9tIHNwYWNlIDIwNDhLLCAwJSB1c2VkIFsweDAwMDAwMDAwZjYwMDAwMDAs MHgwMDAwMDAwMGY2MDAwMDAwLDB4MDAwMDAwMDBmNjIwMDAwMCkKICB0byAgIHNwYWNlIDIwNDhL LCAwJSB1c2VkIFsweDAwMDAwMDAwZjVlMDAwMDAsMHgwMDAwMDAwMGY1ZTAwMDAwLDB4MDAwMDAw MDBmNjAwMDAwMCkKIFBhck9sZEdlbiAgICAgICB0b3RhbCAyMjUyOEssIHVzZWQgMEsgWzB4MDAw MDAwMDBlMDYwMDAwMCwgMHgwMDAwMDAwMGUxYzAwMDAwLCAweDAwMDAwMDAwZjU4MDAwMDApCiAg b2JqZWN0IHNwYWNlIDIyNTI4SywgMCUgdXNlZCBbMHgwMDAwMDAwMGUwNjAwMDAwLDB4MDAwMDAw MDBlMDYwMDAwMCwweDAwMDAwMDAwZTFjMDAwMDApCiBNZXRhc3BhY2UgICAgICAgdXNlZCA4MzRL LCBjYXBhY2l0eSA0NDgwSywgY29tbWl0dGVkIDQ0ODBLLCByZXNlcnZlZCAxMDU2NzY4SwogIGNs YXNzIHNwYWNlICAgIHVzZWQgODNLLCBjYXBhY2l0eSAzODRLLCBjb21taXR0ZWQgMzg0SywgcmVz ZXJ2ZWQgMTA0ODU3NksKCkNhcmQgdGFibGUgYnl0ZV9tYXA6IFsweDAwMDAwMDAwNGE0MDAwMDAs MHgwMDAwMDAwMDRhNGZlMDAwXSBieXRlX21hcF9iYXNlOiAweDAwMDAwMDAwNDljZmQwMDAKCk1h cmtpbmcgQml0czogKFBhck1hcmtCaXRNYXAqKSAweDAwMDAwMDAwNDFiZmI3NzgKIEJlZ2luIEJp dHM6IFsweDAwMDAwMDAwNGE4MDAwMDAsIDB4MDAwMDAwMDA0YWZlODAwMCkKIEVuZCBCaXRzOiAg IFsweDAwMDAwMDAwNGFmZTgwMDAsIDB4MDAwMDAwMDA0YjdkMDAwMCkKClBvbGxpbmcgcGFnZTog MHgwMDAwMDAwMDQwMTM3MDAwCgpDb2RlQ2FjaGU6IHNpemU9MTMxMDcyS2IgdXNlZD0zMzdLYiBt YXhfdXNlZD0zMzdLYiBmcmVlPTEzMDczNEtiCiBib3VuZHMgWzB4MDAwMDAwMDA0MjIwMDAwMCwg MHgwMDAwMDAwMDQyNjAwMDAwLCAweDAwMDAwMDAwNGEyMDAwMDBdCiB0b3RhbF9ibG9icz03NSBu bWV0aG9kcz0wIGFkYXB0ZXJzPTUyCiBjb21waWxhdGlvbjogZW5hYmxlZAoKQ29tcGlsYXRpb24g ZXZlbnRzICgwIGV2ZW50cyk6Ck5vIGV2ZW50cwoKR0MgSGVhcCBIaXN0b3J5ICgwIGV2ZW50cyk6 Ck5vIGV2ZW50cwoKRGVvcHRpbWl6YXRpb24gZXZlbnRzICgwIGV2ZW50cyk6Ck5vIGV2ZW50cwoK Q2xhc3NlcyByZWRlZmluZWQgKDAgZXZlbnRzKToKTm8gZXZlbnRzCgpJbnRlcm5hbCBleGNlcHRp b25zICgwIGV2ZW50cyk6Ck5vIGV2ZW50cwoKRXZlbnRzICgxMCBldmVudHMpOgpFdmVudDogMC4w MjIgbG9hZGluZyBjbGFzcyBqYXZhL2xhbmcvUnVudGltZVBlcm1pc3Npb24KRXZlbnQ6IDAuMDIy IGxvYWRpbmcgY2xhc3MgamF2YS9zZWN1cml0eS9CYXNpY1Blcm1pc3Npb24KRXZlbnQ6IDAuMDIy IGxvYWRpbmcgY2xhc3MgamF2YS9zZWN1cml0eS9QZXJtaXNzaW9uCkV2ZW50OiAwLjAyMiBsb2Fk aW5nIGNsYXNzIGphdmEvc2VjdXJpdHkvR3VhcmQKRXZlbnQ6IDAuMDIyIGxvYWRpbmcgY2xhc3Mg amF2YS9zZWN1cml0eS9HdWFyZCBkb25lCkV2ZW50OiAwLjAyMiBsb2FkaW5nIGNsYXNzIGphdmEv c2VjdXJpdHkvUGVybWlzc2lvbiBkb25lCkV2ZW50OiAwLjAyMiBsb2FkaW5nIGNsYXNzIGphdmEv c2VjdXJpdHkvQmFzaWNQZXJtaXNzaW9uIGRvbmUKRXZlbnQ6IDAuMDIyIGxvYWRpbmcgY2xhc3Mg amF2YS9sYW5nL1J1bnRpbWVQZXJtaXNzaW9uIGRvbmUKRXZlbnQ6IDAuMDIyIGxvYWRpbmcgY2xh c3MgamF2YS9zZWN1cml0eS9BY2Nlc3NDb250cm9sbGVyCkV2ZW50OiAwLjAyMiBsb2FkaW5nIGNs YXNzIGphdmEvc2VjdXJpdHkvQWNjZXNzQ29udHJvbGxlciBkb25lCgoKRHluYW1pYyBsaWJyYXJp ZXM6CjB4MDAwMDAwMDAwMDEwMDAwMCAJL3Vzci9sb2NhbC9vcGVuamRrOC9iaW4vamF2YQoweDAw MDAwMDAwNDAxOWMwMDAgCS91c3IvbG9jYWwvb3BlbmpkazgvYmluLy4uL2xpYi9hYXJjaDY0L2ps aS9saWJqbGkuc28KMHgwMDAwMDAwMDQwMWQ4MDAwIAkvbGliL2xpYnouc28uNgoweDAwMDAwMDAw NDAyMWUwMDAgCS9saWIvbGlidGhyLnNvLjMKMHgwMDAwMDAwMDQwMjdhMDAwIAkvbGliL2xpYmMu c28uNwoweDAwMDAwMDAwNDEwMDAwMDAgCS91c3IvbG9jYWwvb3BlbmpkazgvanJlL2xpYi9hYXJj aDY0L3NlcnZlci9saWJqdm0uc28KMHgwMDAwMDAwMDQwNjkyMDAwIAkvbGliL2xpYm0uc28uNQow eDAwMDAwMDAwNDA2ZmQwMDAgCS91c3IvbGliL2xpYmMrKy5zby4xCjB4MDAwMDAwMDA0MWMyMzAw MCAJL2xpYi9saWJjeHhydC5zby4xCjB4MDAwMDAwMDA0MWM2ZjAwMCAJL2xpYi9saWJnY2Nfcy5z by4xCjB4MDAwMDAwMDA0MWNmYTAwMCAJL3Vzci9sb2NhbC9vcGVuamRrOC9qcmUvbGliL2FhcmNo NjQvbGlidmVyaWZ5LnNvCjB4MDAwMDAwMDA0MWQzODAwMCAJL3Vzci9sb2NhbC9vcGVuamRrOC9q cmUvbGliL2FhcmNoNjQvbGliamF2YS5zbwoweDAwMDAwMDAwNDFkOGUwMDAgCS91c3IvbG9jYWwv b3BlbmpkazgvanJlL2xpYi9hYXJjaDY0L2xpYnppcC5zbwoweDAwMDAwMDAwNDAxMzAwMDAgCS9s aWJleGVjL2xkLWVsZi5zby4xCgpWTSBBcmd1bWVudHM6Cmp2bV9hcmdzOiAtWHNoYXJlOmF1dG8g CmphdmFfY29tbWFuZDogb3JnLmVsYXN0aWNzZWFyY2gudG9vbHMuamF2YV92ZXJzaW9uX2NoZWNr ZXIuSmF2YVZlcnNpb25DaGVja2VyCmphdmFfY2xhc3NfcGF0aCAoaW5pdGlhbCk6IC91c3IvbG9j YWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2VsYXN0aWNzZWFyY2gtNy4xNC4wLmphcjovdXNyL2xv Y2FsL2xpYi9lbGFzdGljc2VhcmNoL2xpYi9lbGFzdGljc2VhcmNoLWNsaS03LjE0LjAuamFyOi91 c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2VsYXN0aWNzZWFyY2gtY29yZS03LjE0LjAu amFyOi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2VsYXN0aWNzZWFyY2gtZ2VvLTcu MTQuMC5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJjaC9saWIvZWxhc3RpY3NlYXJjaC1s YXVuY2hlcnMtNy4xNC4wLmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGljc2VhcmNoL2xpYi9lbGFz dGljc2VhcmNoLXBsdWdpbi1jbGFzc2xvYWRlci03LjE0LjAuamFyOi91c3IvbG9jYWwvbGliL2Vs YXN0aWNzZWFyY2gvbGliL2VsYXN0aWNzZWFyY2gtc2VjdXJlLXNtLTcuMTQuMC5qYXI6L3Vzci9s b2NhbC9saWIvZWxhc3RpY3NlYXJjaC9saWIvam5hLTAuMC4wLmphcjovdXNyL2xvY2FsL2xpYi9l bGFzdGljc2VhcmNoL2xpYi9qb2RhLXRpbWUtMi4xMC4xMC5qYXI6L3Vzci9sb2NhbC9saWIvZWxh c3RpY3NlYXJjaC9saWIvbHVjZW5lLWFuYWx5emVycy1jb21tb24tOC45LjAuamFyOi91c3IvbG9j YWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2x1Y2VuZS1iYWNrd2FyZC1jb2RlY3MtOC45LjAuamFy Oi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2x1Y2VuZS1jb3JlLTguOS4wLmphcjov dXNyL2xvY2FsL2xpYi9lbGFzdGljc2VhcmNoL2xpYi9lbGFzdGljc2VhcmNoLXgtY29udGVudC03 LjE0LjAuamFyOi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2hwcGMtMC44LjEuamFy Oi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2phY2tzb24tY29yZS0yLjEwLjQuamFy Oi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gvbGliL2phY2tzb24tZGF0YWZvcm1hdC1jYm9y LTIuMTAuNC5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJjaC9saWIvamFja3Nvbi1kYXRh Zm9ybWF0LXNtaWxlLTIuMTAuNC5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJjaC9saWIv amFja3Nvbi1kYXRhZm9ybWF0LXlhbWwtMi4xMC40LmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGlj c2VhcmNoL2xpYi9qYXZhLXZlcnNpb24tY2hlY2tlci03LjE0LjAuamFyOi91c3IvbG9jYWwvbGli L2VsYXN0aWNzZWFyY2gvbGliL2pvcHQtc2ltcGxlLTUuMC4yLmphcjovdXNyL2xvY2FsL2xpYi9l bGFzdGljc2VhcmNoL2xpYi9qdHMtY29yZS0xLjE1LjAuamFyOi91c3IvbG9jYWwvbGliL2VsYXN0 aWNzZWFyY2gvbGliL2xvZzRqLWFwaS0yLjExLjEuamFyOi91c3IvbG9jYWwvbGliL2VsYXN0aWNz ZWFyY2gvbGliL2xvZzRqLWNvcmUtMi4xMS4xLmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGljc2Vh cmNoL2xpYi9sdWNlbmUtam9pbi04LjkuMC5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJj aC9saWIvbHVjZW5lLW1lbW9yeS04LjkuMC5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJj aC9saWIvbHVjZW5lLW1pc2MtOC45LjAuamFyOi91c3IvbG9jYWwvbGliL2VsYXN0aWNzZWFyY2gv bGliL2x1Y2VuZS1xdWVyaWVzLTguOS4wLmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGljc2VhcmNo L2xpYi9sdWNlbmUtcXVlcnlwYXJzZXItOC45LjAuamFyOi91c3IvbG9jYWwvbGliL2VsYXN0aWNz ZWFyY2gvbGliL2x1Y2VuZS1zdWdnZXN0LTguOS4wLmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGlj c2VhcmNoL2xpYi9zbmFrZXlhbWwtMS4yNi5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJj aC9saWIvc3BhdGlhbDRqLTAuNy5qYXI6L3Vzci9sb2NhbC9saWIvZWxhc3RpY3NlYXJjaC9saWIv dC1kaWdlc3QtMy4yLmphcjovdXNyL2xvY2FsL2xpYi9lbGFzdGljc2VhcmNoL2xpYi9IZHJIaXN0 b2dyYW0tMi4xLjkuamFyOi91c3IvbG9jYQpMYXVuY2hlciBUeXBlOiBTVU5fU1RBTkRBUkQKCkVu dmlyb25tZW50IFZhcmlhYmxlczoKUEFUSD0vc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2Jpbjov dXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW46Ly9iaW4KSE9TVFRZUEU9RnJlZUJTRApPU1RZ UEU9RnJlZUJTRApNQUNIVFlQRT11bmtub3duCgpTaWduYWwgSGFuZGxlcnM6ClNJR1NFR1Y6IFts aWJqdm0uc28rMHhhYzliYzBdLCBzYV9tYXNrWzBdPTExMTExMTExMTExMTExMTExMTExMTExMTEx MTExMTEwLCBzYV9mbGFncz1TQV9SRVNUQVJUfFNBX1NJR0lORk8KU0lHQlVTOiBbbGlianZtLnNv KzB4YWM5YmMwXSwgc2FfbWFza1swXT0xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMCwg c2FfZmxhZ3M9U0FfUkVTVEFSVHxTQV9TSUdJTkZPClNJR0ZQRTogW2xpYmp2bS5zbysweDk1Mjg4 MF0sIHNhX21hc2tbMF09MTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTAsIHNhX2ZsYWdz PVNBX1JFU1RBUlR8U0FfU0lHSU5GTwpTSUdQSVBFOiBbbGlianZtLnNvKzB4OTUyODgwXSwgc2Ff bWFza1swXT0xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMCwgc2FfZmxhZ3M9U0FfUkVT VEFSVHxTQV9TSUdJTkZPClNJR1hGU1o6IFtsaWJqdm0uc28rMHg5NTI4ODBdLCBzYV9tYXNrWzBd PTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEwLCBzYV9mbGFncz1TQV9SRVNUQVJUfFNB X1NJR0lORk8KU0lHSUxMOiBbbGlianZtLnNvKzB4OTUyODgwXSwgc2FfbWFza1swXT0xMTExMTEx MTExMTExMTExMTExMTExMTExMTExMTExMCwgc2FfZmxhZ3M9U0FfUkVTVEFSVHxTQV9TSUdJTkZP ClNJR1VTUjE6IFNJR19ERkwsIHNhX21hc2tbMF09MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAsIHNhX2ZsYWdzPVNBX1JFU1RBUlQKU0lHVVNSMjogW2xpYmp2bS5zbysweDk1MzM5OF0s IHNhX21hc2tbMF09MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAsIHNhX2ZsYWdzPVNB X1JFU1RBUlR8U0FfU0lHSU5GTwpTSUdIVVA6IFNJR19ERkwsIHNhX21hc2tbMF09MDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAsIHNhX2ZsYWdzPW5vbmUKU0lHSU5UOiBTSUdfREZMLCBz YV9tYXNrWzBdPTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLCBzYV9mbGFncz1ub25l ClNJR1RFUk06IFNJR19ERkwsIHNhX21hc2tbMF09MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAsIHNhX2ZsYWdzPW5vbmUKU0lHUVVJVDogU0lHX0RGTCwgc2FfbWFza1swXT0wMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMCwgc2FfZmxhZ3M9bm9uZQoKCi0tLS0tLS0tLS0tLS0t LSAgUyBZIFMgVCBFIE0gIC0tLS0tLS0tLS0tLS0tLQoKT1M6QlNECnVuYW1lOkZyZWVCU0QgMTMu MC1SRUxFQVNFLXA0IEZyZWVCU0QgMTMuMC1SRUxFQVNFLXA0ICMwOiBUdWUgQXVnIDI0IDA3OjM4 OjA3IFVUQyAyMDIxICAgICByb290QGFybTY0LWJ1aWxkZXIuZGFlbW9ub2xvZ3kubmV0Oi91c3Iv b2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvR0VORVJJQyBhcm02NApybGltaXQ6IFNUQUNL IDEwNDg1NzZrLCBDT1JFIGluZmluaXR5LCBOUFJPQyA2NjcwLCBOT0ZJTEUgNTgyMTIsIEFTIGlu ZmluaXR5CmxvYWQgYXZlcmFnZTowLjExIDAuMjMgMC4yMQoKQ1BVOnRvdGFsIDQgKGluaXRpYWwg YWN0aXZlIDQpIAoKTWVtb3J5OiA0ayBwYWdlLCBwaHlzaWNhbCAyMDcwMDE2aygxNTI3NzkyayBm cmVlKSwgc3dhcCAxMDQ4NTc2aygxMDQ4NTc2ayBmcmVlKQoKdm1faW5mbzogT3BlbkpESyA2NC1C aXQgU2VydmVyIFZNICgyNS4zMDItYjA4KSBmb3IgYnNkLWFhcmNoNjQgSlJFICgxLjguMF8zMDIt YjA4KSwgYnVpbHQgb24gTm92ICA2IDIwMjEgMDU6MzI6MzIgYnkgInJvb3QiIHdpdGggZ2NjIEZy ZWVCU0QgQ2xhbmcgMTEuMC4xIChnaXRAZ2l0aHViLmNvbTpsbHZtL2xsdm0tcHJvamVjdC5naXQg bGx2bW9yZy0xMS4wLjEtMC1nNDNmZjc1ZjJjM2ZlKQoKdGltZTogU3VuIEphbiAgMiAwMToyMzox NCAyMDIyCnRpbWV6b25lOiBFU1QKZWxhcHNlZCB0aW1lOiAwLjAyNDM3MyBzZWNvbmRzICgwZCAw aCAwbSAwcykKCg== --0000000000002a722505d493df53-- From nobody Sun Jan 2 21:00:22 2022 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 80FE0191A6B1 for ; Sun, 2 Jan 2022 21:00:23 +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 4JRrqp3zP8z3D8s for ; Sun, 2 Jan 2022 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 2B42B18F0B for ; Sun, 2 Jan 2022 21:00:22 +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 202L0Mvv033374 for ; Sun, 2 Jan 2022 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 202L0MDD033373 for freebsd-arm@FreeBSD.org; Sun, 2 Jan 2022 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202201022100.202L0MDD033373@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, 2 Jan 2022 21:00:22 +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="16411572221.fF94.32244" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641157222; 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=u8hdfS7ZLXKoflNH1K9sxMa//Xe5XwL8w6VmIun+Rhw=; b=Hr+C/KFVpuBFRGRtMvyzLgYFUgrq2O3WV72ZNUKA8CUiRsRIAcm18jJTyMwMBbxGh39QUl g4XsbWux+hfTXg7WY8Ebcw9+SpoZkqzPIMPMeaKlwKPcON+LYFSF2MFvZs+SEgrdkv7iSD 1REOtGLtXoueNu+0ls1noFQ1auBvWKBaFjCh2HLeYbTbLMS00cJPrF++rSKsHo7Kp8f5Ne F7CfXF0wAQ/RNMzdLQPgF2ey1CdT7dJkaJELEopgXUwQWPm2eJmuq7HrV858lGXboOmerq JO6VdssF76Ge/02dhi4o9Qu+DgZAkg3GG0O/B8g4KMHaWLCX5Qy1n7FrQDSiqg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641157222; a=rsa-sha256; cv=none; b=NvfgWy0WCk+Pc/gmKQVd9EhsrT0GUa372IGZXZVsLlIsVtq7kcmIFIsJSS98dRe9wr1DKY XEQnscTAg/T9fPXA0eGXq7kLYv53E8svo7TvFBjp9BfFtR53oyHSijTew93DGcqTXnmfj1 FwBRL+83Gl+hHx+6WTYSieMEY6W6rLHXDiYUerVCw3WNrrYW/hKCVnZ6ZAT/lZjBrLU2/y 2q4HH/S+f9axEdVYutvsIbhoCyMQZRpHDhRzvbbkD9TgA4FqoozDCsfowG6DzCDhiSOpYq hpx5qrUy2w+rivLZlAZcOxLXOM4khKXbfASmbBnoM9apZecgDrsz8+oguzZoQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1793 Lines: 38 --16411572221.fF94.32244 Date: Sun, 2 Jan 2022 21:00:22 +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. --16411572221.fF94.32244 Date: Sun, 2 Jan 2022 21:00:22 +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.
--16411572221.fF94.32244-- From nobody Mon Jan 3 10:23:43 2022 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 3C4FB192C0EA for ; Mon, 3 Jan 2022 10:23:53 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (littlepinkcloud.com [IPv6:2a00:1098:86:20::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSBfv4pcCz4ny2 for ; Mon, 3 Jan 2022 10:23:51 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 4215726A3; Mon, 3 Jan 2022 10:23:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 4215726A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1641205424; bh=jR7bJOnsveIOsJg8p0c7Q3tvnu76uCeQOUbUQLOvJc8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=STyYx1qByGP5iavO5doNO64VMOWUldSF0Tq075OLvZoKRXPRdiS3waDh2/RAc2PJ3 eArZrE02OOrym7nqk2m5TPn65FYwuCcS70sjCpJBFpnMWjayTONWb7A0mDFzZo8lrV rCpez8V0g9QDT532W+tBN24JQ1Vujapf17JAz6io= Message-ID: <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> Date: Mon, 3 Jan 2022 10:23:43 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: Greg Lewis Cc: Kurt Miller , Mikael Urankar , freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> From: Andrew Haley In-Reply-To: <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSBfv4pcCz4ny2 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=STyYx1qB; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 2a00:1098:86:20::3 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [2.47 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.994]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(0.93)[0.934]; NEURAL_HAM_MEDIUM(-0.45)[-0.454]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; FREEMAIL_CC(0.00)[intricatesoftware.com,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2577 Lines: 74 On 1/1/22 20:24, Greg Lewis wrote: > Hi Andrew, > > [Adding Mikael and Kurt] > > I'm not subscribed to freebsd-arm, so please include me in any replies > > On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: >> Is anyone testing OpenJDK on FreeBSD/Arrm64? > > Yes, aarch64 is a fully supported architecture for the BSD java port and > OpenJDK 11 is supported on both FreeBSD/aarch64 and OpenBSD/aarch64. > >> We're about to commit a great big patch for MacOS/AArch64, and it would be >> nice if someone with a FreeBSD/Arm64 system could kick the tyres to make sure >> we didn't break anything. > > Is this based on the MacOS/aarch64 port introduced in OpenJDK 17? If so, > yes the patch will break things but we have an idea of how to resolve > that breakage since we had to do it for OpenJDK 17. OK. It'd be nice to have that committed. >> Please forgive me, but I have no idea of OpenJDK even runs on FreeBSD/Arm64. >> I've never seen it. > > I'm not sure what your interest level is here, I'm the project lead of the AArch64 OpenJDK port. > but the current port is > currently based at at https://github.com/battleblow/jdk11u, although I am > a few weeks behind with merging changes. Interesting. So OpenJDK from the upstream source doesn't build on FreeBSD, you have to patch it? > If you want to see what > architectures are currently supported then the FreeBSD ports tree lists > supported architectures at > > https://cgit.freebsd.org/ports/tree/java/openjdk11/Makefile#n14 > >> If anyone is interested, >> >> The PR is https://github.com/openjdk/aarch64-port/pull/14 >> The tree is https://github.com/openjdk/aarch64-port >> >> Checkout this PR locally: >> $ git fetch https://git.openjdk.java.net/aarch64-port pull/14/head:pull/14 >> $ git checkout pull/14 >> >> Update a local copy of the PR: >> $ git checkout pull/14 >> $ git pull https://git.openjdk.java.net/aarch64-port pull/14/head > > Is that against an up to date openjdk11u? If so I can take a look in the > next couple of days. What are you looking for in terms of response? Ideally: I'd like all BSD fixes to be in the 11u source tree, so that everything in there builds on all BSDs. I don't want to approve a patch that breaks BSDs, or any other system. I think it would be better for OpenJDK committers to be able to see BSD changes. And I'd like to say "Hi, thanks!" to BSD maintainers. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Mon Jan 3 10:24:46 2022 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 59B70192C6C3 for ; Mon, 3 Jan 2022 10:24:55 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSBh62YGsz4pRg for ; Mon, 3 Jan 2022 10:24:54 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 32B2546FA; Mon, 3 Jan 2022 10:24:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 32B2546FA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1641205487; bh=cTQBvmBzAeNJa9fM4VOhT84FsjUYGaGFxTgNRO1wbfI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=mLQfMnu100vMvz2BbAPcxb6yhLRw5VhR1uG14EJyN7606YLpPEYdvfp46KGLxJt/I pN3HOMSNdFib2Da8GBSUGJZZVq+g4GDn/2IMTIBy3ICs6fP+jKDi5h1kSOmj4t7umI DET2QfYEkA0LrdNHxc0EedHI6zJvVUhXZVuk1YEs= Message-ID: <7e4ac77f-2bf5-d3c6-f744-63555ed4c3a0@littlepinkcloud.com> Date: Mon, 3 Jan 2022 10:24:46 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US From: Andrew Haley To: Greg Lewis Cc: Kurt Miller , Mikael Urankar , freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> In-Reply-To: <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSBh62YGsz4pRg X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=mLQfMnu1; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [2.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx:c]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[littlepinkcloud.com]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.993]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(0.97)[0.968]; NEURAL_HAM_MEDIUM(-0.42)[-0.420]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; FREEMAIL_CC(0.00)[intricatesoftware.com,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 273 Lines: 11 On 1/3/22 10:23, Andrew Haley wrote: > OK. It'd be nice to have that committed. ... upstream. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Mon Jan 3 11:54:08 2022 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 B101E193C3D1 for ; Mon, 3 Jan 2022 11:54:33 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (littlepinkcloud.com [IPv6:2a00:1098:86:20::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSDgY0xsKz3FL6 for ; Mon, 3 Jan 2022 11:54:33 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id E55064794; Mon, 3 Jan 2022 11:54:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk E55064794 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1641210850; bh=3y3VzmLcA76VDweyukCS8bZP+WbZdcmuE/e/yHR0wGc=; h=Date:Subject:To:References:From:In-Reply-To:From; b=YuoOR+aRHzZqZm/bCzsUFD5byW2a553cFA3s+J6KcFiTXdSZiFG2d2Pu3V1W3+5E5 vriGbnjOw/D/JrQ78QLvn6zotRqooFb4+QVOfHcKCN6kXGiETefj+iSp7SACLPoIUS Ri3DiTKik7LTkk4ZrUKAxw2zclp1E31IpofoYjb0= Message-ID: <8585e917-bee3-9be3-faf8-6b863d624b6a@littlepinkcloud.com> Date: Mon, 3 Jan 2022 11:54:08 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> From: Andrew Haley In-Reply-To: <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSDgY0xsKz3FL6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=YuoOR+aR; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 2a00:1098:86:20::3 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [0.88 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:2a00:1098::/32, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.55)[-0.547]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.926]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[littlepinkcloud.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[0.999]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 592 Lines: 17 On 1/3/22 10:23, Andrew Haley wrote: > I'd like all BSD fixes to be in the 11u source tree, so that everything in > there builds on all BSDs. I don't want to approve a patch that breaks BSDs, > or any other system. I think it would be better for OpenJDK committers to be > able to see BSD changes. I should have said: But of course, if you prefer to be independent and do your own merges, that's fine by me too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Tue Jan 4 09:03:45 2022 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 3E35C191C6BB for ; Tue, 4 Jan 2022 09:03:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSmrD0vjyz3Qkn for ; Tue, 4 Jan 2022 09:03:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641287027; bh=paNmKIoD3e+O54Y4YmhYQQOSkJjDFIVpihqIWH4rulM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dF0+BBDNhqVBlog3s9fJp1g6/agF4gULJ8ByS+uCS4We09ctSDORn6o93WmWunejNRTYztNFB8ORm7RTjLkVwXaIT0mWdygWqxomUzZWRA4/ekGc5Jy5G/3zrjQz3DumHg4JawXTdsmDw4/vJgtJ6wSCDDTqZxkst1zVDAvC3nSpoLDUf+NKjYRwaQjAGQPLO9iUWmBoCszDLZHgi79VdfzxxnYCd/GV6SNeYS3SajaLmxx9Moe9YVFnfvXECSdHL6EwCnhTEDcDhQDP2mReyq8PbaA6Kn8fBtL+gxQbkFrDeDawq0ZTuCvd7+WrJHJkunkOnEZ1S60tU1ngvcQG4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641287027; bh=Iv36SljwCs0uHHC33ZJq/y5WFts1PN9TQENqKhupk3c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XzAy4j+bDwbGEaghLRbxbbsP62DNeREVJ2Z0zmbXiONs8v3VnvvzZC244OzlKVWt1PcPLx1gIKK5YvUAehvU+7XRBb845d7zg7o5A+yfqFUJ60wLyK5CAONzkWdLSx5hEXCXK8M26vkbHMbwZ/medvuRAd+Z1QVqJQLI0z8u37sLrIPPu1N9bnee/SWQPs0OzxTe4Z1i6Buz9Z/H+5UY9uBZ4aRKyzwvfadXMWTqXF3Hts11Im05P9XvqLkMd7jdAIV1xxbqHkqXyZt+4czUgdHIWYoMkTqkhhvlRHGtDp6QR1ZsR/cMKWoo3DZ57b9XZLOypJ0nihtMaDILttlWXg== X-YMail-OSG: BCdGiVgVM1muAmQ9Og67OySz5nZUuKnbRKNBxnhxHOk_kkaFiY.EDifPkXSlvSB XUi5aohOJ9A8FwHtrGMkIPXfN5tysDFlIJEAs06FNxf7_neKa6UcmpoxaH02QBajPRxi.6891dhn t66.CLfsHW2dv9MOxgMC_0byw811oZnxaLt25bv0_hx0l5ZsP4r1SGdQYwvyE7lq7lc9gc3IwJ3b LQqdNEV2jHI66RWFRY_XgQu6gcHvvIM63RpvHDxH2tmJ4UwnM4jgfu1H2ZU25zbZKVA5KGYX0iOc 86Hm9GEFDEJv1KocuGcjX01ZXykfy8.qCtGbMR.3DRDroI0sfkISADMT0uHT8p09HMVwRSpVPkVa ts5neZiawqFZ.3atPUxmZquQccI2vktAN5BkHrD5AKictsybf3UatCuKkP8BGK.OhummYgZBvmAz 70GYPv2ycimKNe1fBUqdFpdrCXj0kctYL.oPkcizsDOAFU799Fi6.PMzPR0nIJBUd1S0KLSjgS37 9SN5rvAfLK4eoFk.ncgmtf6lp_0P3twryObg.WxKzZxc4c.FQaic92YhH10k93nHTlOMAxZVjLT5 kulJTygBQgumrLHSGiMl.HvhSgEXdNGhyEV0hbt7yea9CsUvh7es79pU_Wzev8E_zuFRGtypjPw3 HLDCaKnz2sY_C.rFq43Qg04UtNDyj5jEy5CBMQeWpWOcoAHuCC_O4nrxVKv2Cj2TDP_G.svy2J2e keWZ2d1RynS8hUbO_NIgGOjapXGfsSWL52Dr.W.ZiZF5TBo6ohomqYyJRCq44AC8Ntv.K53sX3nS 4WEyxwp3Zf_xQL6JMecoeavoivJDQxkJouGuDVNq6PFJffK1OLaUtQvDyWqA9qVl5iDHlLYjoEDS lk1W.vgmZxrLaDBE0zqD_uGGnNLh.zwdLVOlKfk1qZGacQJCBUthwPlWZZhvVboqFR1OEu0fdLy8 GRqb8Yni24zj8e24895.cmhNB_RBmflxHfRgGl98srjztS5GC8qdSLC_aPpTMi_1QXPUv1xObHK6 cPeBmh0f4hTahiZTLWMAPEA9RQzk8LfhrTwcCOhwVJlOF7REhUMh6T8O9_Wi1r0HYfNq4eixXi2T gy.ggn5_t4k2r_UD8F2_2LCG5CkmXjCZB0gSCOrFj0lCPZOreKNMQMr4ZcIu2Fe.QeuVUGHTSnJn brje9L04Q409T1dV.uFL8t13ojeP6DsFkxo1kc9BrRlIWRQcZk7_sm8fKB4Zq__e3z4T4Q2WSQc5 kbalga_0hkqfCDLmt.OHzojm0pd7UGRHN.0vf_rTq64QREHktWIcHdbOl9TUZMyUo918.UsBAOr_ r9qAHD2zOpfsma7RRUad0PBat01K6KTi8nc9e53_wUb1yYXEnD9B23JK.WN8xo3RckcYnu9hGDir ExFPqoptBsCl7oeHvoqkLimox1y7TGn6iwKKRSPknYdQavV.7W.ClYuJHVuFjA08HX6TkJKzn1zv ZUB_YeRVpAW62wLL9r9Ps33NIJbgH3viwXIGVlKgrhYwTDLeTnOeWBWQ2iGn8Q89OjpYPfB8Vol2 iI1Bb4P6BMEyePe5emiQc6ZQ.ItBASu2Q_q115agdjVoS40yXKx1IlBOAsfYpmYtHAkmTTkC.PaQ xeYIAxVTE.3gV3rCeP2D8nhFpaXW.GYM9CtNdFmfgoH7JHWKNuk6HRtXvIFA9.NggX7ekA3I.Yxl ZMCUc4AXDfcdPH9kQ9sSTvvvvizb.I5EiZL54VhvpmXqhOn81BWEgGRsNYiau9A5Uv8GCcROB95N yiR6J8w7Xxv_7QHNqwObC.tKHL3S71HMwCZ3V9APEdXoHX7tAuO2pYK2u95KWWlxCoz.EnK6BoMo AJ.0fuRqD1jE5E32V1aj7eDrmqDRyOOdJ_dj3HqBoipTc_grfjAos48gKDqQeyDOu1BdD94q22CD rLgdhHcI4Uob6TW1ybzOj8GPBo_jHjdJcBnmnwt2SZfoK4xKidZ6yyODm9tDnqLbX_dLnDPKL_Cx CPk_s1.UWC0PC7G9CQ5L0Zv.Q31_AnZMf2w3nmYXzILSu.Auo4YYOOj3eCU0HdWg9.t26R1KZt2Q bQmYMYg3LMuDA3guQToeZh5j0k5SNycdmbLy8YuUXh3fpe4wIrQ1D2rGiX.3rbQo0gBX2XYivoEk nYZu5ND7cA1jBg13A6E_K0InZ2xjSXi_sPqHhIHZuaLW7WZ.rZQn8RLfCf7Zw0MOAx8vNUuz2rBM wYWlZwQVD2awlsoeXL4hTDCLLUQqpblH4VA7_uE7aXgtMLPXHzautmDeLBDI96g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Jan 2022 09:03:47 +0000 Received: by kubenode538.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 355267d4262039637ef5348e38d7a548; Tue, 04 Jan 2022 09:03:45 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <20220102025818.GA42622@www.zefox.net> Date: Tue, 4 Jan 2022 01:03:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> <20220102025818.GA42622@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JSmrD0vjyz3Qkn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dF0+BBDN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.81 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_MEDIUM(0.58)[0.585]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4556 Lines: 139 On 2022-Jan-1, at 18:58, bob prohaska wrote: > Coming back to the saving of u-boot environment variables, > backing down to a much older set of FAT files seems to help. >=20 > The machine now has a DOS-only microSD with an old set of > files: >=20 > root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_" > VC_BUILD_ID_USER: dc4 > VC_BUILD_ID_TIME: 15:31:38 > VC_BUILD_ID_BRANCH: master > VC_BUILD_ID_TIME: Jun 7 2018 I've no clue what the status is for this vintage of RPi* firmware. But it is not obvious that the RPi* firmware is what enabled saving u-boot environment variables: the U-Boot vintage may be what made the difference. (It would not be the FreeeBSD loader that makes the difference: not involved until too late to contribute to the issue.) > With this suite of bootfiles it's possible to save a value for > usb_pgood_delay of 19000, which in most cases results in a hands- > off detection of the usb hard disk (via a powered hub): I do not see anything here identifying the U-Boot vintage used. But the vintage may be tied to the save working. > MMC: mmc@7e300000: 1 > Loading Environment from FAT... OK > In: serial > Out: vidconsole > Err: vidconsole > Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB = Device(s) found > scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 >=20 > Intervention with run bootcmd_usb0 gives a successful boot from USB.=20= > If nothing is touched, the console displays:=20 >=20 > MMC Device 0 not found > no mmc device at slot 0 > switch to partitions #0, OK > mmc1 is current device > Scanning mmc 1:1... > Found EFI removable media binary efi/boot/bootaa64.efi > BootOrder not defined > libfdt fdt_check_header(): FDT_ERR_BADMAGIC I do not see anything here identifying the FreeBSD loader.efi vintage used. Likely it need not be old? > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env It might be possible to tell the FreeBSD loader to use the USB drive via the content of the /efi/freebsd/loader.env file on the microsd card's msdos file system. Likely this file would need to be created. For all I know setting rootdev ( or currdev ?) to the appropriate disk?p?: text might do such. (That notation presumes UFS, ZFS. ZFS uses zfs:DATASETNOTATION: I've never tried using /efi/freebsd/loader.env and I've never found documentation in the system. But there are notes in: https://reviews.freebsd.org/rS346879 Given that wording, I'm not sure just where /efi/freebsd/loader.env ends up being relative to in the msdos file system. I've not done much analysis of the code that is also listed. There also is a loaddev that seems to be involved. I expect that in some respects part of what is described in: # man loader_simp applies to the contents of /efi/freebsd/loader.env . But Other things may not, such as rootdev being used to initialize currdev . > Setting currdev to disk0p1: > FreeBSD/arm64 EFI loader, Revision 1.1 >=20 > Command line arguments: loader.efi > Image base: 0x39e91000 > EFI version: 2.80 > EFI Firmware: Das U-Boot (rev 8217.4096) > Console: comconsole (0) > Load Path: /efi\boot\bootaa64.efi > Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x > 01,0,0x81f,0x18fa8) > Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0 > ,0x81f,0x18fa8) > Setting currdev to disk0p1: /efi/freebsd/loader.env content might be able to control the above? > Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 > 97c7,0x7726839) > Setting currdev to disk0p2: /efi/freebsd/loader.env content might be able to control the above? > Startup error in /boot/lua/loader.lua: > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or = directory. >=20 > Type '?' for a list of commands, 'help' for more detailed help. >=20 > It looks like the root device is still the microSD card, /efi/freebsd/loader.env content might be able to control the kernel load device (via indirectly or directly controlling the currdev value), possibly via assigning the rootdev value so that it will be copied to currdev ? > even though > the USB disk has been found. Any suggestions appreciated. There's a > complete and recent ports tree if it's helpful, attempts to use it=20 > on my own have caused more trouble than they've solved, in particular > that's what lead to the "saving to FAT....FAILED" messages. . =20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 4 09:31:14 2022 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 578001923B3B for ; Tue, 4 Jan 2022 09:31:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSnRy1QGqz3lMj for ; Tue, 4 Jan 2022 09:31:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641288679; bh=ODU9uP4cLaCmbbGpS65nrGhUrqn7h8EZUf+qdF1RZzg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pTBRq4Gy0SeyxLRLrBkKub1gY8zBeoMc6qy3iEwwgzUdOxsjktEB6cS+MkgDbk6Y7vQh9CRPzot0hxbEGanJ4M4QF7prAEsiztYffHt79CzpuLaTlRbJMyYS9Usaox1b95+uYNvbxsuyzHgZytXsocfQ5lf2opBD6wc4J0SyrBRF3kDYcOZIjJI4SwkSvZ5FidpA3Wpb1R8gIJQVcAUGWSZ68//wUjlZabGhLPtwDSNFoIybKYRf/t2D0IVRvG35YjBqae6pleYzmjRGQkgrQPG8oeYOQBuNE85ibz9wOfTjz4jIzfHxMgjb7JhqP/bwGpzGistWAbTveJk4CZs8HA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641288679; bh=785EiFz3Ngr5RIZYzELx8jSPVQD0AsS0+UVdxncp9QH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VrnOtLBh19q2FOy3dnVjAW3E1F7r2wc7z5+RbXCNgb/y8jl+qdS/u2ZNdF8OH0TLB0v9whK2qqWy4YOH/bIL5C0cyQPn9AwgUtJeeeAIrvdfn/ftGoh+/tudAz/T4IxYBVCVIGqYAjlI5WS/+KkhJJNOmoWQCClFFWo/UY2BTkD8z8fK7C39YIT3Vkcx325hJeCr6gDBfBX7cIpLZvOCd7+5DaFyuc5SxJHEhgSWe85MBv1nDVIiwZieQVGpVg+R02YCaoB2qs3zcxkF3u5+WYJMPOjlgEzqLF7t4/BT5Jj3bDfMsz8zxG85ZvPsDn4QtJu0NvakoZFclup0yfM9rQ== X-YMail-OSG: iO10DqUVM1n4gdRZpXc.glnLk3_mwNPTK.ZJ6ldRj6eca.0SuoSsRIOyix5sFHT rXuqsVXQYemkhKpfQU4Jo3u.wjznhi5dvmr6E9EONCtyD4Fs3Mf4W4D_yFnEE3Gvm8.L.w7T7kGA 15ltAdn6jtu4.6eOP7EbxEz4WbKPh.v4PENHOGTOOXSjjjiv3iHa8FbOWjF3qWZKZ9bCn7m2FA8c vqFDJ.eCrYlvbvi7YaHjsGUsQx.sDSCfAQkAsphidUneZT2rI7hdp5Y6bclYbeChp6O3UDU9S4qm 8WywF191zDjxSYaGEVui1ZphOpSrDT12.fqlkUGLWVfZMqWpJ6yKfG3axTpT4BRv11WirFz5cUXR AsbmAzkpbmBC.ZuNl3JJU7n8LLmfiSLyPNzMCvS9ocKn3aOCoBV1mD4_0nSf9mhbnNDM092wsC0U _jrhU_DhknjWq.hNAef8IW1lMx68JivmGb.cw9oyaji_5T4iAOBhbmAgJLFXMyMac3I3xR2jFNDb AJ52qlJbvvWUlK1Cuu2RwPnYdoPYBanf1Tj5JCGfBv49jIxDMBCInamwVGItsPTr2tug4RM_yDIX Byy4KZLClP8cddX6F3PIE05Yv3aIXKU6.WGFgjDG.gxV0YRqj7yy.5Mb49vvYbFWtP0g60kQJSW8 _HuJ5m9aWdxpWEdBqy24yXlO6IfOGt6M.b9nNxvrZhNGuIqjGOarbtwgxaQTYbTaDL2FzTyAm_gk JZE6j3ryhaw3vvSBkVUwHW.sn_x671KS5lcb_thggM9wqNmwy2QWfRTxwNb2IEi6E_YYHiVZ6fjV ojNfy0jxZS4ixF1Sjgr3tLo2bwoCNz0ghdR_M7tl5ekkb2QSGTbbtbqEMf0zMLm8TkJkz_OMV9kU 8jZ.JexCMdYV_O9vwBw1eH1Yg8ZExpHr6NvheqtbVQ1aTYnMHGh8WzrOPv_tWgK7mPy9v4W0Ihe0 3CxEvdjTDd5HSAlQUia8KJdlEkZtx9LvDJWKRhwkUx0GUta4n0eAcbKR8FMvcKPk_3gNliBQ_hrh oIyB6FVcZM_lWs2JqSJeZgCeHudizGxXdaEADdDK5mPO9LroAYbtR6CXEtHKMIZcBtWLogHrK2Pp EQ9B3_K65DNqhPZmg8muCkI0veGxshPE8ZcoVTumkQleduAV0eC0YN3MZ5bstDqoJuzmixPqS9DY qs8c9pNbhDmnO0dONZmbmU9vQEPp_bCogEfrqFTj9IRRHvCUM5bBM4oz9cB6b0xhg3Y9zFHbN8VE wGgBTrTTT797e3_.rUk9IPAU67mgC21ncSVxofhKvquifEBdhfj01RyIkcB5hSxQaY1iwsCBNOJP qtpno6R5xzJOhC987.2arkUUP0dqIzxffDDdsmh9iU6RlyWh1ZOo0ananX4Sy6pTtYdapPvMgBHX 0ZHNasBgE9Sx9dEBAFO93A_qa12BW0aAjCQrEEjuJ82wpui83vusoiLB1edpVRKmjDPfun_qEwje nZy3Uj_fOBaZFODRtD11sdx6sOR8GKRiEVa935avXSVbm1B6b5UoGtwemQDDHrF.C5nXbM9nlIyn .nLpb4X.PH2F3BigwWWK3uy4myGsxtrh7eWFOz.2d0ePwR2f8JsxXcZ0D1H5Mb76ZEAs4HT104Ml qWuetvJt02bmPQpLCYR.wQQ0VScFBh9aN4eMcFQDTNgNx4CJB0MI36mwzP2_k.R_B961Ogq87Ijb ckX2slm1rqmzXiQuXYm_t4AEiEk0Fi9UCvuifk2rvHePeGWKiNobqFiJ20FWo1pSAWTurJVSLR5u ly50SqaReqj2PFRnJjqTOymECv1bsQKBelgFFy1TklmZSYcSIgjPd5hiam.CHBrprluL1MVEM3NC sDpD6reTr3t4dxbheZy_rUfDGrGcE6voR.flS6etdr3a7yA3yVb4k0gxXQBHzD6EUHuajr9fokLm oa6VdGk2uPNbbAjraMRxXyeYn6R1fqtWMTN0lAyOEMLjZrkDvOnxmuvMMA4MBTYR3zfopaQ1XxcA 8kEu7vtwfv.OTnGGlzgKyiD2PBcKAsn.iUYWkzQ374qeOqJyOfamU..gwLtHZWkeLqhMx_eLddn2 xel8qZm2p_GDy4oFSkFWrMzQWFP0OBcUteCfzXirts7i_.05t.It5EZwZTgx03bQMe2W9FqGP_ia Wx62lFdDYIeO5PSAtdABZz.Oc.GuI9s9y71CbmyioJG7MrjqEED10qYjbfpnFHWx_Vdgm6rIm0W_ ldbQFoZVD6ezXz0CviTiQ73edV6_RbWUCUXjlgncpo9hwGvHEdE4v6711 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Jan 2022 09:31:19 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2449902ac428a9af9d58eb56270f3b2; Tue, 04 Jan 2022 09:31:16 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> Date: Tue, 4 Jan 2022 01:31:14 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <8551EF27-BF69-44E5-BC32-FB7E1752FDD6@yahoo.com> References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> <20220102025818.GA42622@www.zefox.net> <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JSnRy1QGqz3lMj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pTBRq4Gy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.93)[0.934]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5635 Lines: 157 On 2022-Jan-4, at 01:03, Mark Millard via freebsd-arm = wrote: > On 2022-Jan-1, at 18:58, bob prohaska wrote: >=20 >> Coming back to the saving of u-boot environment variables, >> backing down to a much older set of FAT files seems to help. >>=20 >> The machine now has a DOS-only microSD with an old set of >> files: >>=20 >> root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_" >> VC_BUILD_ID_USER: dc4 >> VC_BUILD_ID_TIME: 15:31:38 >> VC_BUILD_ID_BRANCH: master >> VC_BUILD_ID_TIME: Jun 7 2018 >=20 > I've no clue what the status is for this vintage of RPi* firmware. > But it is not obvious that the RPi* firmware is what enabled > saving u-boot environment variables: the U-Boot vintage may be > what made the difference. (It would not be the FreeeBSD loader > that makes the difference: not involved until too late to > contribute to the issue.) >=20 >> With this suite of bootfiles it's possible to save a value for >> usb_pgood_delay of 19000, which in most cases results in a hands- >> off detection of the usb hard disk (via a powered hub): >=20 > I do not see anything here identifying the U-Boot vintage used. > But the vintage may be tied to the save working. I may have implicitly presumed that the U-Boot vintage supports presenting a UEFI interface. I've no clue what vintage such was first good in. Thus, I may be implicitly indicating requirements on the U-Boot vintage used when I suggest FreeBSD loader related material. >> MMC: mmc@7e300000: 1 >> Loading Environment from FAT... OK >> In: serial >> Out: vidconsole >> Err: vidconsole >> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB = Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> Hit any key to stop autoboot: 0 >>=20 >> Intervention with run bootcmd_usb0 gives a successful boot from USB.=20= >> If nothing is touched, the console displays:=20 >>=20 >> MMC Device 0 not found >> no mmc device at slot 0 >> switch to partitions #0, OK >> mmc1 is current device >> Scanning mmc 1:1... >> Found EFI removable media binary efi/boot/bootaa64.efi >> BootOrder not defined >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >=20 > I do not see anything here identifying the FreeBSD loader.efi > vintage used. Likely it need not be old? >=20 >> Consoles: EFI console >> Reading loader env vars from /efi/freebsd/loader.env >=20 > It might be possible to tell the FreeBSD loader to use the > USB drive via the content of the /efi/freebsd/loader.env > file on the microsd card's msdos file system. Likely this > file would need to be created. >=20 > For all I know setting rootdev ( or currdev ?) to the > appropriate disk?p?: text might do such. (That notation > presumes UFS, ZFS. ZFS uses zfs:DATASETNOTATION: I've > never tried using /efi/freebsd/loader.env and I've never > found documentation in the system. But there are notes > in: >=20 > https://reviews.freebsd.org/rS346879 >=20 > Given that wording, I'm not sure just where > /efi/freebsd/loader.env ends up being relative to in the > msdos file system. I've not done much analysis of the > code that is also listed. >=20 > There also is a loaddev that seems to be involved. >=20 > I expect that in some respects part of what is described > in: >=20 > # man loader_simp >=20 > applies to the contents of /efi/freebsd/loader.env . But > Other things may not, such as rootdev being used to > initialize currdev . >=20 >> Setting currdev to disk0p1: >> FreeBSD/arm64 EFI loader, Revision 1.1 >>=20 >> Command line arguments: loader.efi >> Image base: 0x39e91000 >> EFI version: 2.80 >> EFI Firmware: Das U-Boot (rev 8217.4096) >> Console: comconsole (0) >> Load Path: /efi\boot\bootaa64.efi >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x >> 01,0,0x81f,0x18fa8) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0 >> ,0x81f,0x18fa8) >> Setting currdev to disk0p1: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 >> 97c7,0x7726839) >> Setting currdev to disk0p2: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or = directory. >>=20 >> Type '?' for a list of commands, 'help' for more detailed help. >>=20 >> It looks like the root device is still the microSD card, >=20 > /efi/freebsd/loader.env content might be able to control the > kernel load device (via indirectly or directly controlling > the currdev value), possibly via assigning the rootdev value > so that it will be copied to currdev ? >=20 >> even though >> the USB disk has been found. Any suggestions appreciated. There's a >> complete and recent ports tree if it's helpful, attempts to use it=20 >> on my own have caused more trouble than they've solved, in particular >> that's what lead to the "saving to FAT....FAILED" messages. . =20 I'll note that the code from https://reviews.freebsd.org/rS346879 that added reading /efi/freebsd/loader.env if it exists was not committed until 2019-Apr-28, well after "Jun 7 2018" (the only date I have for your context). The FreeBSD loader in the msdos file system would need to be from after the 2019-Apr-28 commit involved. My guess is that a modern one would be fine, but it is just a guess. Setting rootdev via U-Boot may be another alternative that might not have such a vintage-tie involved. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 4 09:47:56 2022 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 121151927DDB for ; Tue, 4 Jan 2022 09:48:00 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSnq26Jmbz3mxn for ; Tue, 4 Jan 2022 09:47:58 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 21A4F26A3; Tue, 4 Jan 2022 09:47:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 21A4F26A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1641289677; bh=DYtzdN5AnPil0UxinfV2tvmUQuddLn6W43NXGvfzGVM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=P1C1//aZg5MdxzkyBEYdlM/BBZ9Te9mqQc7/lF0bzCcb2zDdoBNIZy+HeYXKAi9ES +TITS9fYJMVWvoe4hn+q5S2+pIhR0XWcGBOzIQzFZ2sXdD8M//YH0QEECDuih6JtbC oXk4XQHQBASdokDjiF8FzkkMbyZlFzWHqBcK4u5I= Message-ID: <66e0e5b5-3d68-5b38-4c45-ff2e3df461ee@littlepinkcloud.com> Date: Tue, 4 Jan 2022 09:47:56 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: Greg Lewis Cc: Kurt Miller , Mikael Urankar , freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> <0101017e21d9a517-3be68617-c362-4814-9ca7-24f26cf406ed-000000@us-west-2.amazonses.com> From: Andrew Haley In-Reply-To: <0101017e21d9a517-3be68617-c362-4814-9ca7-24f26cf406ed-000000@us-west-2.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSnq26Jmbz3mxn X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b="P1C1//aZ"; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [2.09 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DMARC_NA(0.00)[littlepinkcloud.com]; NEURAL_HAM_LONG(-0.90)[-0.899]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.990]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; FREEMAIL_CC(0.00)[intricatesoftware.com,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3171 Lines: 74 On 1/3/22 21:30, Greg Lewis wrote: > On Mon, Jan 03, 2022 at 10:23:43AM +0000, Andrew Haley wrote: >> On 1/1/22 20:24, Greg Lewis wrote: >>> Hi Andrew, >>> >>> [Adding Mikael and Kurt] >>> >>> I'm not subscribed to freebsd-arm, so please include me in any replies >>> >>> On Fri, Dec 31, 2021 at 11:59:02AM +0000, Andrew Haley wrote: >>>> Is anyone testing OpenJDK on FreeBSD/Arrm64? >>> >>> Yes, aarch64 is a fully supported architecture for the BSD java port and >>> OpenJDK 11 is supported on both FreeBSD/aarch64 and OpenBSD/aarch64. >>> >>>> We're about to commit a great big patch for MacOS/AArch64, and it would be >>>> nice if someone with a FreeBSD/Arm64 system could kick the tyres to make sure >>>> we didn't break anything. >>> >>> Is this based on the MacOS/aarch64 port introduced in OpenJDK 17? If so, >>> yes the patch will break things but we have an idea of how to resolve >>> that breakage since we had to do it for OpenJDK 17. >> >> OK. It'd be nice to have that committed. > > It would be! However my understanding is that this is conditional on BSD > passing the JCK tests and committing to future maintenance. That ends up > being difficult to manage on volunteer time. I see. I don't think that there's any link between whether a downstream build passes the JCK and and whether a patch for that build may be pushed, though. And there's no contract (explicit or implied) that requires the author of a patch to commit to maintaining it long term. I mean, of course it would be nice. >> Ideally: >> >> I'd like all BSD fixes to be in the 11u source tree, so that everything in >> there builds on all BSDs. I don't want to approve a patch that breaks BSDs, >> or any other system. I think it would be better for OpenJDK committers to be >> able to see BSD changes. >> >> And I'd like to say "Hi, thanks!" to BSD maintainers. :-) > > I appreciate your desire to have all the BSD changes upstream, because that > would certainly make things easier for us. I think that is unlikely > without someone to sponsor the changes through though. > > Even this heads up is useful though! I'd be happy to discuss further about > how to get changes upstreamed if you have thoughts. > > I'll try to complete updating our repo this evening with the latest upstream > and then look at whether the change in your pull request applies and what > we'll need to do for the merge. Sure. I've been thinking about how this might get done, and it depends on how extensive the changes are. If it's just things like missing #include lines, that's easy. If it's more complicated than that then there's some thinking to do. But this discussion is productive, because I wasn't aware that there were downstream ports to think about. I guess it should have been obvious. Also, we've made contact, which is useful. I see that there are FreeBSD AWS images, which will at least give me a way to try things. When you test, please let me know which version you use, and I could kick the tyres. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Tue Jan 4 09:49:44 2022 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 59E6B1929378 for ; Tue, 4 Jan 2022 09:49:46 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSns55VCGz3ngy for ; Tue, 4 Jan 2022 09:49:45 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id AC602320F; Tue, 4 Jan 2022 09:49:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk AC602320F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1641289784; bh=zub3ZmSdFysKgi8ogQ4O8KnKKxBef+r/AUkCpfcu8BE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Q4l5dXVvyXxmo2WPZlGRTFujGHXVvSv2yYVnCqDJB6tyVsNou8L744gleB7SfOB8j 7mbho8ChGLoMoe+IeiwivLzL/yoot99pDfG/vTHEEG8tcG36MrclPrFkBJ/W9BXnoD iZR+Woub8Zcpe7hikLIzGQJwIYjflYBAC2DWSiKk= Message-ID: <8aa3459d-6d82-f913-04de-0e570e8002eb@littlepinkcloud.com> Date: Tue, 4 Jan 2022 09:49:44 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Call for testing: OpenJDK 11 on Arm64 Content-Language: en-US To: Greg Lewis Cc: Kurt Miller , Mikael Urankar , freebsd-arm@freebsd.org References: <015b381f-d4f6-6088-6474-9add5d9a14c3@littlepinkcloud.com> <0101017e17510bbf-2afcf100-ab72-4117-a02a-b59bf0ad73d6-000000@us-west-2.amazonses.com> <9dfcc136-231f-692d-cde4-9c7d17bac3b9@littlepinkcloud.com> <0101017e239ef152-a2b202c3-e42a-4c51-8465-f317349b43d2-000000@us-west-2.amazonses.com> From: Andrew Haley In-Reply-To: <0101017e239ef152-a2b202c3-e42a-4c51-8465-f317349b43d2-000000@us-west-2.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSns55VCGz3ngy X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=Q4l5dXVv; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [2.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx:c]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[littlepinkcloud.com]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_LONG(-0.90)[-0.900]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.990]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; FREEMAIL_CC(0.00)[intricatesoftware.com,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 397 Lines: 13 On 1/4/22 05:45, Greg Lewis wrote: > That will likely need to wait > until after work tomorrow. Sure. I guess, given that the BSD patches aren't upstream, there's not much need to hold the upstream MacOS patch anyway. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Wed Jan 5 23:58:24 2022 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 1B3A0193736E for ; Wed, 5 Jan 2022 23:58:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 4JTmf40pL2z4SJW for ; Wed, 5 Jan 2022 23:58:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id o63so1400195uao.5 for ; Wed, 05 Jan 2022 15:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=jzni5fV+/78HVglEZNxDnLL2eYfTEZ+d5APjatKyw+w=; b=fseG0ILzuLKKJPvssfW+8yvd06lKqESEu/eHRilHt8S6ieYvsRmENOBuSAWKWi9zH6 Lju8z3/46McAXYEgu6VQjV7Q2ZC6GDMcqt5TyhClIP5vuVjLPGU/ukK0skYfoIKvkAjn qq4VrJjx6UtvpThNuhbbJgnBZgoct4/mZk+//8AxeAY9uwhDvCLcaueEd8uaCNN4OYSs m66Hq9/LDfEE3DkGAUaaVcHEeyvt5xiE1b0zgI+bkQ0TiDw3aPA9peVz/ZW3E/m1osIk MD/E+MlwZW5Z+QyUr0gsYQUpV802wEmaJKyFoy1h1GZOFeQ2O7Xv45m/MGG/UE1Jk2sX IPzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jzni5fV+/78HVglEZNxDnLL2eYfTEZ+d5APjatKyw+w=; b=fw+ggGujfThhqg4C6Asx4XRricoSWpqho59DezK+zI2KSYArOYXfPEWawCnb5WE7/M yCdoa8Ij99uR+lQbR2FYj5Iej6BSdHnWdSn4Y3K0xoSVmC6h9MDtS9WRreQ1u6Wt8gKw d/wthZy6faF+JVFP2KbmOXcameeWTcjmC4ruFZ8tb+uP0rS9cSPPP072WWgnYqOfFLMM GX6EhmavBfBfoNUs5ynBhQeUNMu1ysgNmAOUBUFkyF9ZYrKeWFw9A5+sKoqet1wM5ZtY pa0HnPlnprQxHQEez4MYIs40vmnn34mb6o3rvwJmaX9dlpKUBv25Koe3Htxhg2izfV/R XyJg== X-Gm-Message-State: AOAM530dmBXbjlX81ubgAOr/c3EVsIhB9v1F/J3YQCEUihS+80YXuJ3E A0moop61bmdSbi6woSZktX+odt3YD5An/N6ViB+LRg== X-Google-Smtp-Source: ABdhPJxFC+Lv1faZPl2isd3MVNE/afTAHF3p+VpnE5k2H+gEZBUnzZGkOJ0EfrnifQFfIhou9EXzaxVhnZDY4mTTxcg= X-Received: by 2002:a05:6102:ed3:: with SMTP id m19mr18865424vst.68.1641427115500; Wed, 05 Jan 2022 15:58:35 -0800 (PST) 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 From: Warner Losh Date: Wed, 5 Jan 2022 16:58:24 -0700 Message-ID: Subject: libsoft retiring To: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000024faf805d4de882b" X-Rspamd-Queue-Id: 4JTmf40pL2z4SJW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=fseG0ILz; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.901]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92a:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1767 Lines: 39 --00000000000024faf805d4de882b Content-Type: text/plain; charset="UTF-8" Greetings, I implemented libsoft on arm for the FreeBSD 10 -> FreeBSD 11 transition from using the 'softfp' ABI (where hardware float was used, but registers were passed in integer registers) to the 'hardfp' ABI we've used ever since. libsoft has been turned off since I added it as an option in 2016 6 months before the 11.0 release. Several people used it at the time to transition their 32-bit armv6 FreeBSD 10 (or 11-current) boards to armv7 FreeBSD 11. Since then I know of nobody that's used it. I think that it's time to retire the option entirely. https://reviews.freebsd.org/D33761 has the bits to remove it. Comments? Warner --00000000000024faf805d4de882b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I implemented libsoft on= arm for the FreeBSD 10 -> FreeBSD 11 transition from using the 'sof= tfp' ABI (where hardware float was used, but registers were passed in i= nteger registers) to the 'hardfp' ABI we've used ever since.

libsoft has been turned off since I added it as an o= ption in 2016 6 months before the 11.0 release. Several people used it at t= he time to transition their 32-bit armv6 FreeBSD 10 (or 11-current) boards = to armv7 FreeBSD 11. Since then I know of nobody that's used it.
<= div>
I think that it's time to retire the option=C2=A0ent= irely.=C2=A0https://reviews.= freebsd.org/D33761 has the bits to remove it.

= Comments?

Warner
--00000000000024faf805d4de882b-- From nobody Thu Jan 6 08:46:15 2022 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 6E895192B83A for ; Thu, 6 Jan 2022 08:46:15 +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 4JV0Lv0qwTz4rgr for ; Thu, 6 Jan 2022 08:46:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 F12EF1CF15 for ; Thu, 6 Jan 2022 08:46:14 +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 2068kEEB073044 for ; Thu, 6 Jan 2022 08:46:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2068kEXx073043 for freebsd-arm@FreeBSD.org; Thu, 6 Jan 2022 08:46:14 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 260972] get an error when building base system: `boot1.sym: error: PHDR segment not covered by LOAD segment` Date: Thu, 06 Jan 2022 08:46:15 +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: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: shenleidi1993+freebsd@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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641458775; 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=YvLZk0NqNAfGuOfSluvxy2F271edG6imnzFWeCn8rt8=; b=AhLuMPMjL1GnbTC0PBLF7l5ehFzFzZjdo36oI6J/FvRzgvYZ4ECaH8mrk9iyPZQ7Avdbu4 d6INinNnSnvNVyv3g3RyS7FaUY04rFW9dRIQrX02n3iHGO0SKmxZRkvyQ574cUY1F/yu6V WFXJwBt7tmvoOoUi0XvyirV72a66OezzD3BLQgdujo/tiHa5wMPnt63OCJQVpC0gkQo5UN 8W4M874YbUJNiJzl7ych0ox6dTuplfz/PeOzmD2NXdFklL1RA/4FIlL5oVPCpWJ1Ry4VKI tc/Pp+G+NB3ipemIpwCkYnYThK9/WUOT0ISaFizwiA2HgrjleBFrfqsFEBnnEg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641458775; a=rsa-sha256; cv=none; b=CzS0bogOeb1qRyeWIr4R9Icm6w0WN4s+9t7jWp/ItvL8Cyhb5zQwhEIsL6nQg9ZYt2xyRg Kn1MZJDI7ngXszyND4KWrpdJ+XyppA1xboBcz9qxjniitVjPYHtDCT5EzybQ+v9CfLam/F wKsS5HRREGAumJLcHjvfvHklCZ1QN91UwIL6nSnNcN0Q9QKUm28UsL8NoXegA8t151HXYx zpi+mWD9fu42xKPiaGB5Bj0r8H21svK+YsIybL8bFMqI3eSWYhW/QCCwWbBYaiDfi1Myw5 sojbO4XkMacweQBdL0qBb6Y3sRpIcsFZopCMVuJKbK761sK05tPmelLzA8EFFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1088 Lines: 34 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260972 Bug ID: 260972 Summary: get an error when building base system: `boot1.sym: error: PHDR segment not covered by LOAD segment` Product: Base System Version: 13.0-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: shenleidi1993+freebsd@gmail.com Created attachment 230753 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D230753&action= =3Dedit build log I am trying to build the base system for the ARM64 target and get an error: `/usr/local/aarch64-unknown-freebsd13.0/bin/ld: gptboot.sym: error: PHDR segment not covered by LOAD segment` I am using `stable/13` branch on source tree, and building it on FreeBSD13 AMD64 and ARM64. Please see also https://github.com/opnsense/tools/issues/258 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jan 7 12:37:07 2022 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 EC1021931951 for ; Fri, 7 Jan 2022 12:37:16 +0000 (UTC) (envelope-from SRS0=f5+T=RX=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JVjQz5Lzfz4VpP for ; Fri, 7 Jan 2022 12:37:15 +0000 (UTC) (envelope-from SRS0=f5+T=RX=klop.ws=ronald-lists@realworks.nl) Date: Fri, 7 Jan 2022 13:37:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1641559028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=xDhppdkW3guwbbhGmFEJtTzU67fMAQ/LrcurZH4x208=; b=DCSjdz4N4vtb4pxnACjJ8SjeLyd4vOrNba+7JU7dLauU70yZ/1cipY1cRTBBOYIT38jAWE ZiJ6vQtml0T4SZBs40q9K3KwgOwON2opQbs5Feg5TmTwX7Q0G/P32PSGZfAq4GOQVdeRGh XwZGrjOaVNa5HCBOxbE6/v3pKsHQVf67S06JXsCqGEqJOEjj0DbwZJBDpLFq/chz9kG8Q1 3P8vbBI4C1X1fAQfPkW38ib7jPk79ChNSXsRXEFFkAwRStq49Hy/uaRUMCElS4/NhZP068 ykrdoVQHU9C/jfgOKGw0oQl5UF9dh/iPgfD6lP8Ed4d75Gt122/Taqgocrf6BA== From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <956434876.180.1641559027925@localhost> Subject: snapshots 13 and 14 are gone 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="----=_Part_179_980323414.1641559027901" X-Mailer: Realworks (590.208.5ce459b) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JVjQz5Lzfz4VpP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=DCSjdz4N; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=f5@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=f5@realworks.nl" X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=f5@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[T=RX=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=f5@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1177 Lines: 31 ------=_Part_179_980323414.1641559027901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ . Is this a known issue? Can I help putting them back? I can switch my ports build infra to https://artifact.ci.freebsd.org/snapshot/14.0-CURRENT/latest/arm64/aarch64/, but I expect that to break more often and I want to use a little bit more "official" snapshots. Regards, Ronald. ------=_Part_179_980323414.1641559027901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ .

Is this a known issue? Can I help putting them back?

I can switch my ports build infra to https://artifact.ci.freebsd.org/snapshot/14.0-CURRENT/latest/arm64/aarch64/, but I expect that to break more often and I want to use a little bit more "official" snapshots.

Regards,
Ronald.
  ------=_Part_179_980323414.1641559027901-- From nobody Fri Jan 7 12:55:21 2022 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 C7D3B1935D03 for ; Fri, 7 Jan 2022 12:55:23 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVjqv5HbQz4YSV; Fri, 7 Jan 2022 12:55:23 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641560123; 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: in-reply-to:in-reply-to:references:references; bh=ZSRnUUWoZKrhTgLtgPucDE0o6Txack21TxZLej6lynM=; b=NkEm5szGPeSTJFA2dQoepWqQHzBrHu0zfEGd9EUG6e2+Kq3vNjH8ySvxotPkCXRRxRqW2G XLFySfMTrY2Sxpx4fM6J4fIRjgV8XND04nei9Yur/d9t6qBUe4ZDnebE4u/LaV56KImpkF oL9seWdm6dKemFv6fCLf/XtDvCkQeIKt6kJH7TJnyCeOI0pFgRmRLtOSlVFw90WkGV+ON1 iHYZw+7OG0QcvthWxb5al3MI8mOakFsS2hPHyp0qnOcUmGSQTKqW9bUVjLO9RLqqfvOYD3 uCfH+Gh127fW04Ei0B1gp+93pe5dRKlkmEMvgIR3Cy+yCxk4NDJmsoRVL8abFQ== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4A21C635C; Fri, 7 Jan 2022 12:55:23 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 7 Jan 2022 12:55:21 +0000 From: Glen Barber To: Ronald Klop Cc: freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-ID: <20220107125521.GR75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yLfVvEQOBD/VeTNx" Content-Disposition: inline In-Reply-To: <956434876.180.1641559027925@localhost> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641560123; 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: in-reply-to:in-reply-to:references:references; bh=ZSRnUUWoZKrhTgLtgPucDE0o6Txack21TxZLej6lynM=; b=TCNOHatFlfAWSWFEOVV8sQcUqQ2rbKyVt/NiNRhQXVNvYMTpsv90EDaIIDYxhMYoBB0lu2 ujtfTBQrnXLPXRHORtb/W8/BLzaS2jAoSVTszoISPLW++a/sj+dIrgP+ocnu0/9OdTy/NH jhObp3uuUqMFG8v7PyoGiWdvLIQz7FBHyHdaP0a6Bt487/QDAefnZxzkJmSMDsyCjXY2P6 JNxWihX98j9a8j+zRCbheAOMZyhlDr5TGYZRa6PL/HY5jMGeAIGdA66JgE6MoNr2fRXzuk 9bK9s1eImXEOInLkhINtM5pFu3BqmU08taPcV5UPU/CS3S+GOsPVr9IwVTCdfg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641560123; a=rsa-sha256; cv=none; b=cMUlejeGQryTrkIChr5zyz/0T9o4bWJTjCz3WhsPt4HkUwYlx2avD/igq5W1/H2uePcQRf JkJheRUudPFtPUmVoEpxXOCFTWPSSaIpbwE5st0Sei51RwQsSXlUH2tEx7jH8XUUswFTOd 3nlH7M8OCovvYfcgOJHdATEsUg2E8yWDdPe+R7gC4Ec4zjdc34NAgqtNp4jzlR8nuMS0TN XaG6n8DohLEOI70GwXZin6cx58mZJEnKUH0HREyXxuHLZqFamjwpLKCXeEXBu1qK7wZ6Ks CHF9cDCXytm87s3cJiYyexkQg8RI9FKbLAMgraah2y/TcGXboj27np42xFIcxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1715 Lines: 48 --yLfVvEQOBD/VeTNx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > Hi, >=20 > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/= ftp/snapshots/arm64/ . >=20 > Is this a known issue? Can I help putting them back? >=20 Yes, this is a known issue. The qemu-user-static port had been failing to build on main and stable/13. A commit to address that failure had been added yesterday, so we should have arm64 snapshots next week. Note, if you traverse the directories on the download site, you will find some older snapshots for embedded boards: https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/ Glen --yLfVvEQOBD/VeTNx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmHYODgACgkQAxRYpUeP 4pNu1w//dOw3rZBHxSRoUXSiPh2AyWfgC8RRucbzHgfXMgxFK3Ffd7E+N+ZqKpyp cJaDtsSvcmKba/YohnvrqkunJvR7jH24ive96PqKX5E5hBTHT/hgeL7hH6xSauz1 1fP7nF8uTLMV9jkD0ukhFRjthHBxEr6u1NrxDUbC1d+iQZ6MnzT+vUMSruBqbSJJ mL/q2p5POQ3YcyI9rCw4Xg5XbewyliznLnpZQ7B6NSSIHDDzfmurfmFx5Nsd9095 4N1QSdcdW033WxZrfFjuLYf3dip+TcCUCiGL38L+Mtv8z5CtxFRld01L8RI9Jikq zAreriaasvEyteNBJ1j2wkA+m2WR+e9un1j/I+e0A+q9LOzz/+v+nSfzdcMTZfwP mEULp/WAcXPJk51pTZq7UBbYdORYXoC5L+XwoutAL3kCWEVk3GaaDJjMytpOIRLc J0ZO2jGp5r3/R4dBK5EV4mgZ2AZ3d9NHDStYV7A83wVp9wQRMay2gtzdeq6oK5/D PiYXWSFKBpP2ff59n//GDjBz02X6n8fLu4Em55CwsJAI+EaUvgTTV9vPsyfYZIYG mcIJotf1ynLmuzy1+UZ8CxD4LEN5CHNLCUEfGhNlEh2EMBBJaX1gj4qxfps0uLku mCo1CK0OenL4p+TFNkkVzDza7DZUgMRPgiHQ9zq4Hu/1RTr/QtU= =QnZA -----END PGP SIGNATURE----- --yLfVvEQOBD/VeTNx-- From nobody Fri Jan 7 17:07:34 2022 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 691C8193FA9A for ; Fri, 7 Jan 2022 17:07:43 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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 4JVqR271fBz4SM3; Fri, 7 Jan 2022 17:07:42 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1641575255; 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=bqpy1iUppWKLKq7+ehUKAKYfhEN280bUVUquEtTmDmw=; b=G1xqGVtihemAi0XZ7R6vgit9yYTWfdxFLhpsGgCTWiPNPB2IuDYljCzpC0alsbxKEDShW7 sJPlSFdjAg5KdSPPqrgzQkKEIThZ2F+eLP/vbnPPOGDgmA36u3T1Xxs7oEChvKKayF+5eo HtwBVm4y17unTFQALjevFwwJ/33OwE0= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e7f915a1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 7 Jan 2022 17:07:35 +0000 (UTC) Date: Fri, 7 Jan 2022 18:07:34 +0100 From: Emmanuel Vadot To: Glen Barber Cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-Id: <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> In-Reply-To: <20220107125521.GR75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> 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: 4JVqR271fBz4SM3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 913 Lines: 29 On Fri, 7 Jan 2022 12:55:21 +0000 Glen Barber wrote: > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > > Hi, > > > > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ . > > > > Is this a known issue? Can I help putting them back? > > > > Yes, this is a known issue. The qemu-user-static port had been failing > to build on main and stable/13. A commit to address that failure had > been added yesterday, so we should have arm64 snapshots next week. But qemu is only needed for VM images, so why other thing like snapshots and memstick image are missing ? > Note, if you traverse the directories on the download site, you will > find some older snapshots for embedded boards: > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/ > > Glen > -- Emmanuel Vadot From nobody Fri Jan 7 17:13:11 2022 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 D53E7194105D for ; Fri, 7 Jan 2022 17:13:14 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVqYQ5kTXz4TFm; Fri, 7 Jan 2022 17:13:14 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641575594; 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: in-reply-to:in-reply-to:references:references; bh=c2uDCh0ZX0X+IoEvgQPZqWG/sV8YvhPW4OpsKDXxp8g=; b=yP4G1ODUwsJirpkXF6BbxEqqkX8KTXZkbXqSwND2V+O5E8cEQMUYqAU66ae/+u8C+o1bYN 5oiH6YwiiH9PTzretMaaAsSLKofgTioVncAbruaQf2K35iXIRCNB2FpYxYqrhn8n1Llrkn yEHyPQ4PhpuDgG5l6DSb4Cj99LfTBgv83rJsNEvIzMNjEBaUaN8TzG5URzm4HtxspBJwUX LbMjd1zfwq7wjLKkuElL94haTqr+Gvh/RHduKpRSYoeULek0iQF21cDsQxaBL21dUE+1Z0 je7EsPJHX0trvy78fyUbvtQ9mLPegw7qfDhkPIfHkxHN0PpHpYIGdOkD2GGjnA== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 520E774B3; Fri, 7 Jan 2022 17:13:14 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 7 Jan 2022 17:13:11 +0000 From: Glen Barber To: Emmanuel Vadot Cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-ID: <20220107171311.GT75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aZ/0/p6gSDXwzas7" Content-Disposition: inline In-Reply-To: <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641575594; 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: in-reply-to:in-reply-to:references:references; bh=c2uDCh0ZX0X+IoEvgQPZqWG/sV8YvhPW4OpsKDXxp8g=; b=Im9itb3FucIu2FX6czh5rOn4vq3yOyJNUPDHKVJUHAsFv28tlVzFiDrQ1hJKpNYFEKc5yE qeryLUogKwJan2sMaW03Yt7X/NJYsisCiwMEY7UaIN88cbqu+xZGMQgnlZuPC5GEwL6EFc V4GXlFvmNe5znjBN+SlLSZR6a97tjdIKs7octAbz4tG3gFGDCX2X7VDmqowKmGNw17iCEu ObxZ3/6eun4M3P671P9DlbKM3knl97ybM3d8WJfx/0AJacIGwZ9zIpY9fLviHNhXWvWeBO mAGVpx8ec+zyYv853qPZS/c1HfnqeEfq5EPJhlmhFkSqgPoLwyIbxyDuW4ny/g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641575594; a=rsa-sha256; cv=none; b=b8kwvoquJg+Zcpc4IWqcraRKQsSQzKF18WFK7xilMcSPxBLlTPnKUwZZtkHUNaUUCt85ai rEIXVweBeKMJsl1FBh1JWXVmmmpLtiAKxA4x0D39rsZXsM+BbCkFbc9STg3CRcA6y7CKPm a38YMOO8SWmXjjvUkkF79OGjHENGHKcTJ1ehk3P+2AgosdyLLbAUxd8l3LY8A1HOWtJw9j bG77qv3fDAvttHrefm1TNUPMDBiDRfxMhzOjbB3vpeiZEbKVloNDUZbI5FfC6aUFb1gcST Ah+wzc3nBdYce6ON2pUFmd5K3Xd9nvPMUz83r1LGTCl5PsKtqsWPLB6KqgfW7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2089 Lines: 59 --aZ/0/p6gSDXwzas7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: > On Fri, 7 Jan 2022 12:55:21 +0000 > Glen Barber wrote: >=20 > > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > > > Hi, > > >=20 > > > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.= org/ftp/snapshots/arm64/ . > > >=20 > > > Is this a known issue? Can I help putting them back? > > >=20 > >=20 > > Yes, this is a known issue. The qemu-user-static port had been failing > > to build on main and stable/13. A commit to address that failure had > > been added yesterday, so we should have arm64 snapshots next week. >=20 > But qemu is only needed for VM images, so why other thing like > snapshots and memstick image are missing ? >=20 Hmm. They're there, just not at the top-level directory Ronald pointed to. https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ I'll have to take a look at why that top-level directory does not have the appropriate symlinks. Glen --aZ/0/p6gSDXwzas7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmHYdKIACgkQAxRYpUeP 4pN2rA//ekTtUHifVrq87ugeN2EcdYKXLu2Glp3JR0R8Xhr/yiGf8HBrLOhHXrbD aiJNG9vNYyiOdoyCfs1F4BJKTSAxbfCQcuKs5VLF1voWtByZWHvLSNdsI5WqTHfV m6OjNuDBW7uqex3AGRUt9sOHntM3LOYevEoWTHlhnbppKwVD4t9M5LppBZjuxKC4 ERkC6vabDWB/criYYvqaNjAc+Bu32RcjWRRlfLLMYRusXZeSwqXwoBHdbXKMo3Nh 7oP4IaMxYpodePY645VEHAh8TO7tEqYfMsNwi5WZDjQ3N79G5Ab5ngSX2PmAcsBy ByWZq3osIyPcgaApxqHvA9CikgP2G/a4UJteloH9fm5PGD4X+x+kCdwHOcldEPyf WD8aRHqT5iyQPbOPtSnAbg22BHQf4vIKVQdhKMkU5ICo6t1TCVLK2OU3K50OMic4 BaEJVEXArEilZ/A+L+yOKkP11voJFdeKHlRjIW38+H9mzEbHY802ZY7N3Pu9gJ1v VBHyB1Jaq7zGyrtQwq4AB2fK1qdNV+thodn3ptULWnXFhnZR23ywdAZ32tAZhLR6 EkacR/xaL/TgZGrkRLMQpDiVkoUAm28dY9BurtdxVKYQqnaXW1Zj2PBfFaQd1aP0 T+w0dGJzfoQutnlpsdyUeHmbvIWr9tasEorBRe3zhQSZW/r2pIs= =pf9i -----END PGP SIGNATURE----- --aZ/0/p6gSDXwzas7-- From nobody Fri Jan 7 17:16:15 2022 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 464A619415A0 for ; Fri, 7 Jan 2022 17:16:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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 4JVqcw6J9nz4Trp; Fri, 7 Jan 2022 17:16:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1641575775; 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=PIPX3l1Mh+sStcQl0xyLQP73lqzutGFNmszbkES9G9Y=; b=Iknf+O7dzV6G0cMF0IhuZlMKn3I8R6n3YnMnK0O9W2pVpalyLlCXW8wv1PqorIZYvGB82I d1IYqf6wkapSB+MtEFSGgBO086Z1bEpF1nCY8I2bYEuaswyLIR+fcx1XrRwK5QTUTmRLy0 2UCOH088CBfa5QThvI4/QCSj6Av47EY= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6e61d5ce (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 7 Jan 2022 17:16:15 +0000 (UTC) Date: Fri, 7 Jan 2022 18:16:15 +0100 From: Emmanuel Vadot To: Glen Barber Cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-Id: <20220107181615.e8965709af86a255b954dde6@bidouilliste.com> In-Reply-To: <20220107171311.GT75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> <20220107171311.GT75344@FreeBSD.org> 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: 4JVqcw6J9nz4Trp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1251 Lines: 38 On Fri, 7 Jan 2022 17:13:11 +0000 Glen Barber wrote: > On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: > > On Fri, 7 Jan 2022 12:55:21 +0000 > > Glen Barber wrote: > > > > > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > > > > Hi, > > > > > > > > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ . > > > > > > > > Is this a known issue? Can I help putting them back? > > > > > > > > > > Yes, this is a known issue. The qemu-user-static port had been failing > > > to build on main and stable/13. A commit to address that failure had > > > been added yesterday, so we should have arm64 snapshots next week. > > > > But qemu is only needed for VM images, so why other thing like > > snapshots and memstick image are missing ? > > > > Hmm. They're there, just not at the top-level directory Ronald pointed > to. > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ > > I'll have to take a look at why that top-level directory does not have > the appropriate symlinks. > > Glen > There is no memstick images here, only the SBC images. -- Emmanuel Vadot From nobody Fri Jan 7 17:20:45 2022 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 5DCEB194296D for ; Fri, 7 Jan 2022 17:20:48 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVqk826rhz4VYN; Fri, 7 Jan 2022 17:20:48 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641576048; 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: in-reply-to:in-reply-to:references:references; bh=OWjmQk8AJYKznHir2L02qjSTtRDsXRI/UZxuLUUsiCE=; b=kDAmgWs6O6xueSpNoER94FfnOpnB8qOQlWtCviQZdzmJhr6DiWOddY0NVVXIvWMsWauyRM gzTLetgnEDsBa8BLOu4eQ8kNCCB3HfcbC0KuesrOcK1B4CyOPm4UrzzoidzQGl7AA2iH64 t0LPrEYcsxHrNlFIlYmN7StWZMu0BwqZl25jg8X9cbOJKQgr7uwhbLVd7yGgm7xk5owAxf NOqOkbwAVOGr8zksCNv9QwVXUL+FnMuN5fYuc3nzreb0FsyjNX9m1Q9PH+vA/hZbGo28M4 YoUsw5BoMFNghffi4gs5sbueMKDRoZKLX7r3vcAP1aCiIGjvIYGv3iRJnUDUwg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id DF59C752D; Fri, 7 Jan 2022 17:20:47 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 7 Jan 2022 17:20:45 +0000 From: Glen Barber To: Emmanuel Vadot Cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-ID: <20220107172045.GU75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> <20220107171311.GT75344@FreeBSD.org> <20220107181615.e8965709af86a255b954dde6@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G9m07da55tKJni3T" Content-Disposition: inline In-Reply-To: <20220107181615.e8965709af86a255b954dde6@bidouilliste.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641576048; 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: in-reply-to:in-reply-to:references:references; bh=OWjmQk8AJYKznHir2L02qjSTtRDsXRI/UZxuLUUsiCE=; b=YcR2BRqvxVENyZbRvjTwdb2c/yDu0WsH72kwe5ieDG7GfVXt+y1IY6MrBgU0eEtbMrDOgP w/Q7ovecTZ7VcK8BPJEMN1Q0R2FOlYFQkUecfG6Ckel7qMuCB4TdYOpLSveaRTbi9fQ/T2 oT/DN+Tg93MmzyyRTgtrh2u/li+IrmJCNwmzMZuPTuRHrz4pJiGiSfyhNCt5DeRxCB0/PN gXLjlJfOqkdoaXfQTo1cj8kBp15opsOVZ08lEoHdhAzE0FLUEJDyb1DzEacimYJl9ecJm7 Sb6Ftn9tfsPRIENk3oP511UB5Owe0WUNoSSZScZ9sl+jNPDyRFhPcni+mGYjMA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641576048; a=rsa-sha256; cv=none; b=uMzFbfTQ/7Lklz/rJGwaoZ4PFQ9mmvGu0xSV6ka0FK6kciVtV6iG2N7yFptT/o4OUReXqn MAnJD6yAhtcNJlk937QV+zdhmUyyMxkyYAgYHrNOvJRDw888/zb2LPyzgJrwOMmA3fl1Ar 6FuTP/FVUReCi5nErHZNdBBfuJLqwG5tnemGrKDi+MT4gZf59vVXLRDGPFjGuJQE0b+tnt fye4qoMSJwxJ9y2bflif+X3pqolIsZP6fxYvgXhVuU/kfgnd/1ZDbghxRap2TcsPwm3gI0 PERddPg/FUJNJcp2XQ7dWY0amZH8EZdIfOjdmv2cNt0jEeWrzUI4++qaH058Kg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2614 Lines: 74 --G9m07da55tKJni3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote: > On Fri, 7 Jan 2022 17:13:11 +0000 > Glen Barber wrote: >=20 > > On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: > > > On Fri, 7 Jan 2022 12:55:21 +0000 > > > Glen Barber wrote: > > >=20 > > > > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > > > > > Hi, > > > > >=20 > > > > > The FreeBSD 13 and 14 snapshots are gone at https://download.free= bsd.org/ftp/snapshots/arm64/ . > > > > >=20 > > > > > Is this a known issue? Can I help putting them back? > > > > >=20 > > > >=20 > > > > Yes, this is a known issue. The qemu-user-static port had been fai= ling > > > > to build on main and stable/13. A commit to address that failure h= ad > > > > been added yesterday, so we should have arm64 snapshots next week. > > >=20 > > > But qemu is only needed for VM images, so why other thing like > > > snapshots and memstick image are missing ? > > >=20 > >=20 > > Hmm. They're there, just not at the top-level directory Ronald pointed > > to. > >=20 > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.= 0/ > >=20 > > I'll have to take a look at why that top-level directory does not have > > the appropriate symlinks. > >=20 >=20 > There is no memstick images here, only the SBC images. >=20 Ah, I see what is going on. Since the VM image builds failed, the rest of the build fails, even though the memstick images are created. I'll look into the logic in this failure case. Glen --G9m07da55tKJni3T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmHYdm0ACgkQAxRYpUeP 4pP3RA/9EAcRqEHjHJuepYZXocFWP8b6HG+cEiK+Im4woS+cVN6kK2GFEcudgYW/ t9nfrTylK6FZ1J0VOmmB+va9cO6PgXti/MpQcet90MOIUPJ8jTA3xyORrg1ogcYM OjVt4/dATX3clSe1IUHY3FHwwkFSvu9c8MKID2lVMHtI2yxikzcH8iypgTtUWrV/ CJyymMugiMe7aJ1bIQmWa3fD02+xsctUmWyU5sizqt960GsTBmj7gKrfq1WdJbdN dhSsMmQOp2YZQRlA5Fk4EwT0LIcnlDSCbBklgt5Znm6iZHm51Asir6sRr54olRkY Lxu0+doDAIr0+7u6pEVDpAWkDQGeelB7VPdvy2H58wnaZS1i7uHDhYfPZHtr3TUy 9LTDmvcbKlbXHv9XU7QramltTJxiE1z3r+AO0IF0lANRIPhrQPEh6GPu64iWyUFe 3lCHd9s7PQaz776ds27XoJDHi4xnVFun8oDbhQlNz3WM+gxk+Kr808Nn8fKgMUj4 tcqUI6X1zlH239tQNMv5zGWA5I/qYkcw6AglUqc6FP/Olq8XHYsmuENXnMSceX6n 3K/m7yeY/7HQeGZ51GMLb54ScooNmivGnGwENlozfgR9I5kuXiHjHbmaWa+w8ZGP xFqtaDaENtoEf+HtVpkGUiXzbis3LImYASMox2Y9QezMD1tmfhY= =y1n9 -----END PGP SIGNATURE----- --G9m07da55tKJni3T-- From nobody Fri Jan 7 23:13:40 2022 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 91AF31928D43 for ; Fri, 7 Jan 2022 23:13:48 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 4JVzYR5Xm8z3QXH for ; Fri, 7 Jan 2022 23:13:47 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pf1-x42a.google.com with SMTP id u20so6369545pfi.12 for ; Fri, 07 Jan 2022 15:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=StfHvtS4w9JWOoXawQ0vp35v8N8ZCYqsLhkP+4CXog8=; b=cRbDyuUNgitKO33P3dlmNAKDOWYY5tPNaWh44dgCLf8YIgj8W4teDkvDyluCAu+9tT xjlKB/Q8XMOLF3w/JZAfgWJlUE+fPtVlB/QzI/Wl7FzpkLgEqisf6My8C+dZ3rMm1ThA MZmbJJTm5dRNu3+SkcaK6vsJQJ7GED3RvFb94xHU8FcyBaI8ct1KRpoxvOZLHdAWHROJ c3GwTlPiDCS//lcMuTDY5jDveagHzbbFU9FQ1/+1hA207ay6mwANh3IVPH7UAetzHCDx WYlCG6wR+pgOonif561f1GXOC7wtOaF5/f2GKymZZ3uPauYw15u8WTj6guFj36g3or9A bvkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=StfHvtS4w9JWOoXawQ0vp35v8N8ZCYqsLhkP+4CXog8=; b=BlayeXGkVt6DVrQ56tXBw32hRWrBEoQMStzXTTL+ODBMl5/wZLWoZ696a4z0qqgg8i brr5DdR3RMOBCgur5tGQbNpTMGE3b38FhSUNOTEpJeomHB2d9gIyVQlwG+qlbxDfLNeN qsvUzKtDRutleHd/UtIIgsdDsDVzhi4sS7y4jwPIknEzKNQMuK+WpK99ZV9KwBPcXc3b SAft7rRsV9mct6u5T6OlS1GqFrI8tGNps+5NSriIGcfIrxUnD1ZmNjMe0iSeJgyzmqXY kX5jQcagShFNvBdHN3ltwpLlDZo0eDBPG/m4JDIUNGTR/QuMV/PxtTdNl9Sp2GnJbwPZ b1/A== X-Gm-Message-State: AOAM531Xo9FKREKWUy0N+/bmhLykO4EhD05xAsODapOIqUZ+QjBy7s1R X70LWAOOb4K6SFvnaQ/hQtEt5dAAFUBYlmeu X-Google-Smtp-Source: ABdhPJwyKbqmdDvStDVBtHYLPLm1L+yO2cvnEp0Cwxk6fotgwZvvy9gQ0FVURHO145aMI4Qlp+cmvQ== X-Received: by 2002:a63:33cf:: with SMTP id z198mr55591074pgz.344.1641597226658; Fri, 07 Jan 2022 15:13:46 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id f20sm9400pfe.166.2022.01.07.15.13.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jan 2022 15:13:46 -0800 (PST) Subject: Re: snapshots 13 and 14 are gone To: freebsd-arm@freebsd.org References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> <20220107171311.GT75344@FreeBSD.org> <20220107181615.e8965709af86a255b954dde6@bidouilliste.com> <20220107172045.GU75344@FreeBSD.org> From: MJ Message-ID: Date: Sat, 8 Jan 2022 10:13:40 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20220107172045.GU75344@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JVzYR5Xm8z3QXH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cRbDyuUN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42a:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1631 Lines: 48 On 8/01/2022 4:20 am, Glen Barber wrote: > On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote: >> On Fri, 7 Jan 2022 17:13:11 +0000 >> Glen Barber wrote: >> >>> On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: >>>> On Fri, 7 Jan 2022 12:55:21 +0000 >>>> Glen Barber wrote: >>>> >>>>> On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: >>>>>> Hi, >>>>>> >>>>>> The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ . >>>>>> >>>>>> Is this a known issue? Can I help putting them back? >>>>>> >>>>> >>>>> Yes, this is a known issue. The qemu-user-static port had been failing >>>>> to build on main and stable/13. A commit to address that failure had >>>>> been added yesterday, so we should have arm64 snapshots next week. >>>> >>>> But qemu is only needed for VM images, so why other thing like >>>> snapshots and memstick image are missing ? >>>> >>> >>> Hmm. They're there, just not at the top-level directory Ronald pointed >>> to. >>> >>> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ >>> >>> I'll have to take a look at why that top-level directory does not have >>> the appropriate symlinks. >>> >> >> There is no memstick images here, only the SBC images. >> > > Ah, I see what is going on. Since the VM image builds failed, the rest > of the build fails, even though the memstick images are created. I'll > look into the logic in this failure case. > > Glen > Does this also include Armv7 images? I haven't looked for a while but I can find none now (for current). MJ From nobody Fri Jan 7 23:19:00 2022 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 A7708192A797 for ; Fri, 7 Jan 2022 23:19:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 4JVzgh47Y4z3RGF for ; Fri, 7 Jan 2022 23:19:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x935.google.com with SMTP id b26so12951775uap.6 for ; Fri, 07 Jan 2022 15:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zWDM5IP9mgz2FJGgaxMQnqWqW1a3rT7lFy+a4cyZe1k=; b=2B4LroM2VDEV7Cwy/RihxiJVPg3qKSMlhXfBL/frlbiRO3TR/fftTEcLKeEgec4tur 3hMPIZxjfrFz3gGZ2/szvH718WB2zDi6pdNMU5KoYutOCob9AuePTiAaO0a5FNibyDBg oVfhk0yUCM8AxF3tVJIqxZS0glLLgQFhdYgx7tWmoBK2QsR+W2xX5ful2zFDwjXf2TFK zN2RaT0BXC/7SvG0FyLKEvcQL/PZyFOZsCrstL36PBYVM1xuwn+JrvZtu+VGtPXksLmQ Lxa5v+jmS2woNZ1byVU3dcHlzXvB0kzeVOXw6Em4I4oNshHI8iBkTyev8RJvTjOZVvV5 vkpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zWDM5IP9mgz2FJGgaxMQnqWqW1a3rT7lFy+a4cyZe1k=; b=IW3e9LxkqhVTVG7FowS6m9yMjVZFHZ9/Mdwayw9H6aH0fErh5N5HlJmssAkNRrvxVD SwbmRsBcnir66YsteN2ah668LTvX0kO5ELrVtECkJ85LeHe7LvVOkBjxdPlGT5Eoc4fQ JuwnwjsJEvaPlAkBlwMDy519/jc+mOiuVaJajRqHr2O2ugjOHfK2Q83fWKFH/1JSl2c2 CX2wXbNBxhpntyUj4aUZ7bGWzYF7hbFA/RL4VkfEFkDtcATppZzuSZMLB8hY2RRcxqgu 17zpG+5KqlmEET0HJ9JxvClbmRE0YHqHfkt+ii/FxPeea1XlMH7VujkpLLvyqj+N6x1M 66Qw== X-Gm-Message-State: AOAM531mrHAQfnchAmdLxHfqYTz+8VMbr5+RQcUIbUL5qjsAwCa+JRmK 5/aXnj/n0NIzogNZNlfwZjDwn28LftSsA2+3XrPSO2Q6wq8= X-Google-Smtp-Source: ABdhPJxSnmjhN4hi5ctzdTfe9IN9j+JZSQ934CjcuyLUAyqQmm3u04BsWgnse/Ae/yGfTEf9i86Zqkh4PEJo6D+6mk4= X-Received: by 2002:a05:6102:3e86:: with SMTP id m6mr12820589vsv.77.1641597551634; Fri, 07 Jan 2022 15:19:11 -0800 (PST) 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: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> <20220107171311.GT75344@FreeBSD.org> <20220107181615.e8965709af86a255b954dde6@bidouilliste.com> <20220107172045.GU75344@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Fri, 7 Jan 2022 16:19:00 -0700 Message-ID: Subject: Re: snapshots 13 and 14 are gone To: MJ Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000edfe7905d5063688" X-Rspamd-Queue-Id: 4JVzgh47Y4z3RGF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5587 Lines: 148 --000000000000edfe7905d5063688 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 7, 2022, 4:13 PM MJ wrote: > > > On 8/01/2022 4:20 am, Glen Barber wrote: > > On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote: > >> On Fri, 7 Jan 2022 17:13:11 +0000 > >> Glen Barber wrote: > >> > >>> On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: > >>>> On Fri, 7 Jan 2022 12:55:21 +0000 > >>>> Glen Barber wrote: > >>>> > >>>>> On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > >>>>>> Hi, > >>>>>> > >>>>>> The FreeBSD 13 and 14 snapshots are gone at > https://download.freebsd.org/ftp/snapshots/arm64/ . > >>>>>> > >>>>>> Is this a known issue? Can I help putting them back? > >>>>>> > >>>>> > >>>>> Yes, this is a known issue. The qemu-user-static port had been > failing > >>>>> to build on main and stable/13. A commit to address that failure had > >>>>> been added yesterday, so we should have arm64 snapshots next week. > >>>> > >>>> But qemu is only needed for VM images, so why other thing like > >>>> snapshots and memstick image are missing ? > >>>> > >>> > >>> Hmm. They're there, just not at the top-level directory Ronald pointed > >>> to. > >>> > >>> > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ > >>> > >>> I'll have to take a look at why that top-level directory does not have > >>> the appropriate symlinks. > >>> > >> > >> There is no memstick images here, only the SBC images. > >> > > > > Ah, I see what is going on. Since the VM image builds failed, the rest > > of the build fails, even though the memstick images are created. I'll > > look into the logic in this failure case. > > > > Glen > > > > Does this also include Armv7 images? I haven't looked for a while but I > can find none now (for current). > I suspect that it does. I just updated both the qemu-user-static ports. Warner > --000000000000edfe7905d5063688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 7, 2022, 4:13 PM MJ <mafsys1234@gmail.com> wrote:


On 8/01/2022 4:20 am, Glen Barber wrote:
> On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote:
>> On Fri, 7 Jan 2022 17:13:11 +0000
>> Glen Barber <gjb@freebsd.org> wrote:
>>
>>> On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote= :
>>>> On Fri, 7 Jan 2022 12:55:21 +0000
>>>> Glen Barber <gjb@freebsd.org> wrote:
>>>>
>>>>> On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop = wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm= 64/ .
>>>>>>
>>>>>> Is this a known issue? Can I help putting them bac= k?
>>>>>>
>>>>>
>>>>> Yes, this is a known issue.=C2=A0 The qemu-user-static= port had been failing
>>>>> to build on main and stable/13.=C2=A0 A commit to addr= ess that failure had
>>>>> been added yesterday, so we should have arm64 snapshot= s next week.
>>>>
>>>>=C2=A0 =C2=A0But qemu is only needed for VM images, so why = other thing like
>>>> snapshots and memstick image are missing ?
>>>>
>>>
>>> Hmm.=C2=A0 They're there, just not at the top-level direct= ory Ronald pointed
>>> to.
>>>
>>> htt= ps://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/<= br> >>>
>>> I'll have to take a look at why that top-level directory d= oes not have
>>> the appropriate symlinks.
>>>
>>
>>=C2=A0 =C2=A0There is no memstick images here, only the SBC images.=
>>
>
> Ah, I see what is going on.=C2=A0 Since the VM image builds failed, th= e rest
> of the build fails, even though the memstick images are created.=C2=A0= I'll
> look into the logic in this failure case.
>
> Glen
>

Does this also include Armv7 images? I haven't looked for a while but I= can find none now (for current).

I suspect that it does. I just updated bot= h the qemu-user-static ports.

Warner=C2=A0
--000000000000edfe7905d5063688-- From nobody Sat Jan 8 10:27:54 2022 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 6171019426BC for ; Sat, 8 Jan 2022 10:27:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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 4JWGWJ04Wyz4spd; Sat, 8 Jan 2022 10:27:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1641637674; 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=tAiRguR39L20MxELIx2uexxG2xnryJvZ6LZ2IPDQvLE=; b=P5bb0ZaWgw6abpqHjY7iDifboNAYy/uCmq6N1IXFQZM7nWsqftCAh+0EWREhfoFq8o8jDh huklJn5QBv4ILQDv8OR4C/IYboCtL6EiyDu07yUNQlnaf4Br9B1cLZRYlXfS1fNAe7EKRW vbbOG4nsvkrCXE2+SrL3I2L3t00v1CM= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id cce30db0 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 8 Jan 2022 10:27:54 +0000 (UTC) Date: Sat, 8 Jan 2022 11:27:54 +0100 From: Emmanuel Vadot To: Glen Barber Cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: snapshots 13 and 14 are gone Message-Id: <20220108112754.b404400987c1b3e3b9094779@bidouilliste.com> In-Reply-To: <20220107172045.GU75344@FreeBSD.org> References: <956434876.180.1641559027925@localhost> <20220107125521.GR75344@FreeBSD.org> <20220107180734.49f5effd06e57b2cf4f66b5e@bidouilliste.com> <20220107171311.GT75344@FreeBSD.org> <20220107181615.e8965709af86a255b954dde6@bidouilliste.com> <20220107172045.GU75344@FreeBSD.org> 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: 4JWGWJ04Wyz4spd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3166 Lines: 80 On Fri, 7 Jan 2022 17:20:45 +0000 Glen Barber wrote: > On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote: > > On Fri, 7 Jan 2022 17:13:11 +0000 > > Glen Barber wrote: > > > > > On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: > > > > On Fri, 7 Jan 2022 12:55:21 +0000 > > > > Glen Barber wrote: > > > > > > > > > On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: > > > > > > Hi, > > > > > > > > > > > > The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd.org/ftp/snapshots/arm64/ . > > > > > > > > > > > > Is this a known issue? Can I help putting them back? > > > > > > > > > > > > > > > > Yes, this is a known issue. The qemu-user-static port had been failing > > > > > to build on main and stable/13. A commit to address that failure had > > > > > been added yesterday, so we should have arm64 snapshots next week. > > > > > > > > But qemu is only needed for VM images, so why other thing like > > > > snapshots and memstick image are missing ? > > > > > > > > > > Hmm. They're there, just not at the top-level directory Ronald pointed > > > to. > > > > > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ > > > > > > I'll have to take a look at why that top-level directory does not have > > > the appropriate symlinks. > > > > > > > There is no memstick images here, only the SBC images. > > > > Ah, I see what is going on. Since the VM image builds failed, the rest > of the build fails, even though the memstick images are created. I'll > look into the logic in this failure case. > > Glen > Honestly this isn't acceptable to not have images because of one failure. This is also not acceptable as it's not the first time that someone reports that some images are missing and each time you don't seems to be aware of the problems, isn't there some verification that all the images are built and published at the end of the re@ script and if not a report is sent ? I've offered my help in the past and still do. I've talked with Colin this week and said to him that using qemu-user-static was a big mistake. It was an absolute nice thing to have when all we had was small armv7/arm64 SBC but now we have some big iron thing that can build things natively fast. Using pkg(8) -r here is the solution, it works fine even when the arch is different as long as the packages don't have postexec thing, and all the packages that we need for VMs don't. And even if they have some those could be converted to use pkg triggers for most of the case. There is only two calls to chroot which aren't pkg(8) related in the script : chroot ${DESTDIR} ${EMULATOR} /usr/bin/newaliases chroot ${DESTDIR} ${EMULATOR} /bin/sh /etc/rc.d/ldconfig forcestart The ldconfig is not necessary as we do it on boot, and the newaliases I don't think it's needed too (and if it is we could always do a /etc/rc.d/newaliases that is run on firstboot). The other easy solution would be to build the release images for arm64 on arm64. Cheers, -- Emmanuel Vadot From nobody Sat Jan 8 11:25:00 2022 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 C9A28194EF47 for ; Sat, 8 Jan 2022 11:25:12 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4JWHnM5sHjz3H2m for ; Sat, 8 Jan 2022 11:25:11 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x1033.google.com with SMTP id c14-20020a17090a674e00b001b31e16749cso13491509pjm.4 for ; Sat, 08 Jan 2022 03:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qLpHZejvZo5T0DiKjj21EakYHHvtEd9Sgkp6V3kZpc0=; b=RfowIXU/8qToWdmo5TOXAw1l/BkjYFCGG6Dbkv7Dn7OTjoI5iEArzn2yp1eCWi8t7p g3csBn8MV2oY1HUpfUQ54ZYP4e6ifT6K4qIQ2gksV15ACq1uzM8gyYOdlQF8rQU09X31 5EWZH9jN8BHrw2tEHgZC9vsHblec9E+Om+6vAjBOtWJk3IAW+SXMIpEkTDRsA/yyXcks 4K83Z2FvHt7eFrv7DM0AR9hQ47zRXZvZHy+Q8rpR9vX5KzpEh7Aemk7ql9/OkBDZgrdF EwzuaJSDIzTHMT/o5NmJ1Sj0ep70T7Xz8OlzWlGe6vulrl+ATm5A3ug5gWFYnUfbvCRH obcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qLpHZejvZo5T0DiKjj21EakYHHvtEd9Sgkp6V3kZpc0=; b=GnJ6DIGJHe4HObti0ialDZeWXPhmMz3Uzn1sRhWGLpsyqY1XcQLN6rwVNMzgC9uzjb rKy26EmTx8UDvra9zebSRqObvJlikM3wK2nsyVsA+kMCFzMwgYQRFhFSSfpsELCdnrkX FHoEKDyLQfb7EDmCDU6RkCYLKAFn7V52RIM9NR878qsKrdgREOWdpKA+fJ4Bpck4HJlq 7dLYhZKnL/PUhoItGGa+0mA4Nc7qSMAQ9yn296YpZFvv9gX1G8S2MG0Lnb0Zu596dzk9 rYfR020J6yEE+ybScoR0bRCezYlR+bjWiIhUWhvRd8gWft1RYIrVrJGe+eA+tBN0N76x NfQQ== X-Gm-Message-State: AOAM532DOtdOyizU0PWIpjtm106wxE53SXR5qf3RYqFeME90cHE1J38I pm/ii1yXPjYzwcWoJI5VamtyP2Z169eV27g3 X-Google-Smtp-Source: ABdhPJzThOkX8Me/DhUFCLNrtZ8HSS1sqOsmKvEDLm1c0/HVkCif7PfBKs/7JWmrB5qGdPhrdKq7EQ== X-Received: by 2002:a17:90b:3b8e:: with SMTP id pc14mr20337705pjb.217.1641641104569; Sat, 08 Jan 2022 03:25:04 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id t7sm1720106pfj.168.2022.01.08.03.25.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jan 2022 03:25:04 -0800 (PST) Subject: Re: libsoft retiring To: freebsd-arm@freebsd.org References: From: MJ Message-ID: Date: Sat, 8 Jan 2022 22:25:00 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JWHnM5sHjz3H2m X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="RfowIXU/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 891 Lines: 18 On 6/01/2022 10:58 am, Warner Losh wrote: > Greetings, > > I implemented libsoft on arm for the FreeBSD 10 -> FreeBSD 11 transition from using the 'softfp' ABI (where hardware float was used, but registers were passed in integer registers) to the 'hardfp' ABI we've used ever since. > > libsoft has been turned off since I added it as an option in 2016 6 months before the 11.0 release. Several people used it at the time to transition their 32-bit armv6 FreeBSD 10 (or 11-current) boards to armv7 FreeBSD 11. Since then I know of nobody that's used it. > > I think that it's time to retire the option entirely. https://reviews.freebsd.org/D33761 has the bits to remove it. > > Comments? > > Warner Somewhat related, does anything happen to wiki pages referencing this? Deleted, updated to show deprecation, remain static for posterity, etc? https://wiki.freebsd.org/arm/hardabi MJ From nobody Sat Jan 8 12:19:14 2022 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 D1C801935682 for ; Sat, 8 Jan 2022 12:19:22 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (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 4JWJzt5RYNz3QKt; Sat, 8 Jan 2022 12:19:22 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from smtpclient.apple (24.102.164.36.res-cmts.swb2.ptd.net [24.102.164.36]) (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 62B61175BB; Sat, 8 Jan 2022 12:19:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us 62B61175BB 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: snapshots 13 and 14 are gone From: Glen Barber In-Reply-To: <20220108112754.b404400987c1b3e3b9094779@bidouilliste.com> Date: Sat, 8 Jan 2022 07:19:14 -0500 Cc: Ronald Klop , freebsd-arm@freebsd.org Message-Id: <15369369-FB96-42DA-86AB-5E7149C1B6BE@freebsd.org> References: <20220108112754.b404400987c1b3e3b9094779@bidouilliste.com> To: Emmanuel Vadot X-Mailer: iPhone Mail (19B81) X-Rspamd-Queue-Id: 4JWJzt5RYNz3QKt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3403 Lines: 96 On Jan 8, 2022, at 5:27 AM, Emmanuel Vadot wrote: >=20 > =EF=BB=BFOn Fri, 7 Jan 2022 17:20:45 +0000 > Glen Barber wrote: >=20 >>> On Fri, Jan 07, 2022 at 06:16:15PM +0100, Emmanuel Vadot wrote: >>> On Fri, 7 Jan 2022 17:13:11 +0000 >>> Glen Barber wrote: >>>=20 >>>> On Fri, Jan 07, 2022 at 06:07:34PM +0100, Emmanuel Vadot wrote: >>>>> On Fri, 7 Jan 2022 12:55:21 +0000 >>>>> Glen Barber wrote: >>>>>=20 >>>>>> On Fri, Jan 07, 2022 at 01:37:07PM +0100, Ronald Klop wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> The FreeBSD 13 and 14 snapshots are gone at https://download.freebsd= .org/ftp/snapshots/arm64/ . >>>>>>>=20 >>>>>>> Is this a known issue? Can I help putting them back? >>>>>>>=20 >>>>>>=20 >>>>>> Yes, this is a known issue. The qemu-user-static port had been faili= ng >>>>>> to build on main and stable/13. A commit to address that failure had= >>>>>> been added yesterday, so we should have arm64 snapshots next week. >>>>>=20 >>>>> But qemu is only needed for VM images, so why other thing like >>>>> snapshots and memstick image are missing ? >>>>>=20 >>>>=20 >>>> Hmm. They're there, just not at the top-level directory Ronald pointed= >>>> to. >>>>=20 >>>> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.= 0/ >>>>=20 >>>> I'll have to take a look at why that top-level directory does not have >>>> the appropriate symlinks. >>>>=20 >>>=20 >>> There is no memstick images here, only the SBC images. >>>=20 >>=20 >> Ah, I see what is going on. Since the VM image builds failed, the rest >> of the build fails, even though the memstick images are created. I'll >> look into the logic in this failure case. >>=20 >> Glen >>=20 >=20 > Honestly this isn't acceptable to not have images because of one > failure. > This is also not acceptable as it's not the first time that someone > reports that some images are missing and each time you don't seems to > be aware of the problems, isn't there some verification that all the > images are built and published at the end of the re@ script and if not > a report is sent ? > I've offered my help in the past and still do. >=20 > I've talked with Colin this week and said to him that using > qemu-user-static was a big mistake. It was an absolute nice thing to > have when all we had was small armv7/arm64 SBC but now we have some big > iron thing that can build things natively fast. > Using pkg(8) -r here is the solution, it works fine even when the arch > is different as long as the packages don't have postexec thing, and all > the packages that we need for VMs don't. And even if they have some > those could be converted to use pkg triggers for most of the case. > There is only two calls to chroot which aren't pkg(8) related in > the script : > chroot ${DESTDIR} ${EMULATOR} /usr/bin/newaliases > chroot ${DESTDIR} ${EMULATOR} /bin/sh /etc/rc.d/ldconfig > forcestart >=20 > The ldconfig is not necessary as we do it on boot, and the newaliases > I don't think it's needed too (and if it is we could always do > a /etc/rc.d/newaliases that is run on firstboot). >=20 > The other easy solution would be to build the release images for arm64 > on arm64. >=20 > Cheers, >=20 > --=20 > Emmanuel Vadot >=20 Noted. Glen Sent from my phone. Please excuse my brevity and/or typos. From nobody Sun Jan 9 21:01:01 2022 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 39CD71935989 for ; Sun, 9 Jan 2022 21:01:05 +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 4JX8WM3gdMz3w3k for ; Sun, 9 Jan 2022 21:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 454AD18F48 for ; Sun, 9 Jan 2022 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 209L11VD043538 for ; Sun, 9 Jan 2022 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 209L11Vp043537 for freebsd-arm@FreeBSD.org; Sun, 9 Jan 2022 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202201092101.209L11Vp043537@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, 9 Jan 2022 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="16417620612.dACEA.40544" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641762064; 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=6X8D5KbIi72vrNrYNBSUPJLakFSyyBrVKkv1D8LvcNc=; b=AGEZJne7/qAAyUnQvqbUHCHVaaE5jLdO9bzX8Xwd6Q+SYI5tTBgm7p2Hyfp2xF4jh0JM6Y J2GUDp2pSZPRDxJ8ynVgNy8+ZmFpSDKWvNUPsUjuXhYbJiZnUmymlxCndktLJZhwatuACI BH+XmTZ2ESGvQ8KcdpXTnPRIBcHMnRk4GQM00e1RFtzy6GTisPugqd9mmjQF84fFOCLwqq DtxS50n+oUElx+94lIa+RYlrnbq7QaJT7DBXSL9UIFoMaxWAI5TK9gZG8Mmjsr/mOcYQMg WeaPq+YasntuWOEDfXp35n2ggp8FBqWEzPKp8ydZ8QdaMWgE3mfCWP4gpJadTw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641762064; a=rsa-sha256; cv=none; b=Ei9tTCNPmRLknslTDyKcnlNpsjlLIQjCEfyLdVNnp0JaDpH8ys8WynQsKIze9YcYrr53CS qsWuB0LGOhxFqqfDxo6o3gwW2ORFtBT0mll/7S16KrzeWGz7V6WYTvcnEIlTyGWqSwfyof UVMT9cS/oEiyjvjVQ1fZO3BztGd2cKIv5j1BC73pV5ePhc6rFH7adwBubdVLdyPZ7Yx/0q cQWI/jMd5ILdEioI0g6kHiN5BpjOh7nkxl8m4YaqDrw33fbmaGll2/skqtOsH8w92D/z4P 9iFoOZuzEM9/fvx4UyU/9QaOXj8LIgIWBpqGAOYL6nnQsmkDiRsDiFO4J0jMGA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1796 Lines: 38 --16417620612.dACEA.40544 Date: Sun, 9 Jan 2022 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. --16417620612.dACEA.40544 Date: Sun, 9 Jan 2022 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.
--16417620612.dACEA.40544-- From nobody Mon Jan 10 19:39:17 2022 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 59CDE1951748 for ; Mon, 10 Jan 2022 19:39:22 +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 4JXkfd3Lmcz3M3N for ; Mon, 10 Jan 2022 19:39:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20AJdHtY074143 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 10 Jan 2022 11:39:17 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20AJdH1h074142; Mon, 10 Jan 2022 11:39:17 -0800 (PST) (envelope-from fbsd) Date: Mon, 10 Jan 2022 11:39:17 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: SSH login failing on stable/13 Message-ID: <20220110193917.GA74116@www.zefox.net> 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-Rspamd-Queue-Id: 4JXkfd3Lmcz3M3N X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1055 Lines: 30 A Pi3 running stable/13 updated yesterday has stopped accepting ssh logins. The problem appeared after an update a couple days ago. The update was repeated yesterday in hopes of catching some missing details, but no luck. A session originated from RaspiOS with -vvv ends showing only debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug3: send packet: type 50 debug2: we sent a keyboard-interactive packet, wait for reply debug3: receive packet: type 60 debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password for bob@pelorus.zefox.org: debug3: send packet: type 61 Connection closed by 50.1.20.24 port 22 The "connection closed" took a couple of minutes to appear. Other ssh connections to older versions of FreeBSD seem to work normally. I looked at bugzilla, nothing recent about ssh. I'm baffled, any suggestions appreciated! bob prohaska From nobody Mon Jan 10 20:34:57 2022 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 D965E193E4E5 for ; Mon, 10 Jan 2022 20:35:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXlv12g7Pz3vwX for ; Mon, 10 Jan 2022 20:35:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641846902; bh=0umFBCq9gZpVi826BkxoS6iIfpt715l0Svy0X8OpwJ0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=e0kgAAMaVFWQ9aHvAQEetBQEyciBOvFW79aNEp32RFpKRrACd+hYled3q81eM6I32hUVd7XmPOg3eoNGQN7IzuQaBpxfN7iuGQyHpqqraPgw0NxD/mqls08srRV/XdfIFg226P/nlg1PmOLHfbTfOZQT/ELsg11QTyiMRvveHBCbnEK4HiRFRPi/T+1Q8VrL0QCiJ6Oa3ia0FZBcSEGJ+6c0oFk1690b5p3ESDEwT0Bg2PEoGxXlnUTNHAKdnQI1JWXlJIzA/AvB7d/b2kMSOXHsi88oH3mQere3dWidY/OQCci7O10PkKQJOexiqnOrcOPW2/e+rkWB6PokUkT9Iw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641846902; bh=jGtOMLOyCmQPWTEW626HOSaZI7lT4hMnxegt7cZNLaE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KZmIvod7jkdNTEKO7d0xKs9Qd/nkY0CKFdvC+XWVpbzgdg26AR5mHdmggYZciSGvJHEUPoO1r+tOj0cvhyIx41n1rDtX04V7IbYVRCF98HdAB/wCd29EAJk3Z0O8g6yMQZhdPxVrHDU2rx1k23k945z7F/k6lzWWpORn1SMsTReRh5d7SvFHLUkpSeieA4HM2g3YehUsfiJYdkBp89zPh9Oi+/GsiQo+ur5ZQoAMVxe3dOLVWEwePTP2jBJYifN5seRMsttJo/i8xCuBqDAeLOWbaRMUVpHOBPqKLLNTXzeove9VMgcauRI/5Tkew+Lr0So4AMjgcbC7CI91HoxDcA== X-YMail-OSG: YZ2lJcoVM1n_vCN4OeJZ.YZWwnwSxPe8z3F.by32UxP7XiOdmV7MQLmUdqMB.gz ZmDWTM1J9YTUu5_5AtB..iEt_YWJHtm0XeNVc5h1bs_lyVK42bRDnM7rqyOhCtl0HHXeQRP6wNYB iowcJ_rOScMK1h3a1HsfmO5JBfxWvkal3FIT1CUiX6pz4exVeqpqwp8b0pWTqqP_TemU8xi8Fxdj 6ty6hmqrVf7vW5lzy9ZSGOpvNi1IsJaUgc7FIdsFBuRajPnlOCbUplztHPGBQOjCOZpGb4dG1eBc ASxySgIwbqY7f7yC4CqS8lS2iKPLFWYEQHz2wlc5jIKfC1xNIpO_VG.lzHS93CRkS3nUmzKjAjcz 0R2bPiSaW1hKXAFQBQHaU15xTqOiL58A4w8zHnJv9nytQ14nlmJv4f.RMi22ycm3_59EaAP2pvl2 d7qddClW7UvlnESkDt6SiIAyiUux9lcK50ULW7H_npBGnXsyeaUUQQcaKps60xWOxY99FyKnqnk0 fXx2iI0zn9OzEPiZ6JtIRc94FaaFiTQmV5WKt9TZkvCukoo.vRSdwTh968UELExrrVzJoiGcvbzw kNKi2mQuPpcgOiWnWrOyBGKSxrWkXPRw5bELsHblmDLijz2VAZlqvXMMhtv1KgRB.HxfnEJaOboU 9IJM0YfwrO8mIVpMcs7dJ.YPbPKVcpBTi9MkENo4A3Q45lU6AFImArBOZoeTxMSTF6g3Vm1wJwNS fXAxEfaMW0ZUCZGvULTT6uuvHvGk1HUEFzaWUKX4K435QhcCqqAZN6SfN6L.U8NErxw_pqzw.Ucy nxG2Gr7ApNAU6aselXvr9skAuH1VwRSY.3lTb1YxkcsFH1dARacK30ox8qdl8BzcpQXVTY90qhxE qhXF37R4koqdKQa83oIIcnDVelCb1OeXxwiKv2lo7l2Vkk4XOXzKf8NVdFpyKIbQd1s.qWihxlJS 1t0TQs2OMP5PdJ2rrqKpzn1VwHTr9_xfW7ueNkYJTgRweB02IJm4hTkrMCW6o.cbx08iK4B.1pBF lh.XupGNFSsixYDxWHErkt2Bl_INCtqpP36fVblM3Ost4EsUXvEZ07aq9_kBOk1ROir7uZ_10qaj i07JhflqnOrt.N7neY_KzqnMdCd2ngOjt78JTbZgeiLX1lVlejScoP8dK68p8uox2xVZDMZ2N85j UQQzrH5_lSsXD2TwUi.l2CZ.qNoXa8.xn7Ap1rd9N9qMxFVOxoZREeJDmnfNOlOs2R4WZa8wi4Ox ScAU30YfLKArLwdYTC1suqoyVRaO5kLYCuCUqRWAQsuxJqOWp84gm1Y7CKKwpqSl8ct4GALjQfDW cLWFN1q.pXqZ0gOykuVMSVvYjSbJP8MwNd3xsy4kx59I7v8fPG7gsw78SyiKdf6nMzuhXugvsRr2 _V_WGOit_ufRpFGaTIM3JX8nswtgGkfFLdfbAxYbn2rW.JwOL7kAqJG7IejjIHu83pyaIYKE5.Rz tFtbb5Etrf4Le9QgIEDcE_6pcuR.PVSS4SqPpXXC_YjrNF7DGc3Txad2WKt59zgMppLSyjRM6wQ. L_NOxyV2dwokVfEEtbfytFeVKKt4ofW2W8tmCemPs5YSuKJdNrPgO1gkuEW6xztyUs.ftCGy33_d e05a.Kz9t83wHIkpnCtEDGi5jE.FY7Vwagw3T4HapbICgaxuNJ.iQsTO_2gZfhgNNYGisxZtc5K_ lytBJr3QfE4CxV_fZpvyL_Y9pp9zr3wMRRgnJIff7vrGT3NYtnr6ItzMt8gprsVXJptOd873mR6L a9ZhiPI8GiLE6J8Vb7HHYhSXMOGsHvsqXpXtWO5kq3J3dNxCUr1lL3hSUTMhORt01NC4jsoc1Eyu ClnCdrAnWEBCHtqBfnXWiNccs2KNsH01CNEEsAyX9NPHqKc_VyL1Q2DdlAlAAe6g4v7lLVDIon8Q OC.F5shfwJ0qChhm.aLQID.XQmCQFWOMTzUGFsoMup173I6bJfJS7sVdBBUR_x4wgIxo_SvR5BSb Fy04nP6_6B664qHFObYlG_qNX58.pPMIZ2FLFlHcUNE4GdtTr_9WiQCZZGCne9bcF_wKa7jkAY7c 9piCbLPnZStuemDeP6VPrgsCeL4OO0pOOnJQmRJd5jNPXHzua.Rj83qBAXJVWqg3ZViljX0wAIMy WA7zpXOdAUY_1RspFU5K0xDqrZJgYmR5el0f5RbJx6zLi64IJA08IXngQ2s1oQTNfRFEp_AjWR72 i9iPwTnlRKZr7JNJ9sRZefTHjtOUBhuuWhn64QIE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Jan 2022 20:35:02 +0000 Received: by kubenode541.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 03b8dd44e676531f7abc4968752395d2; Mon, 10 Jan 2022 20:35:00 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: SSH login failing on stable/13 From: Mark Millard In-Reply-To: <20220110193917.GA74116@www.zefox.net> Date: Mon, 10 Jan 2022 12:34:57 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@yahoo.com> References: <20220110193917.GA74116@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JXlv12g7Pz3vwX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1969 Lines: 50 On 2022-Jan-10, at 11:39, bob prohaska wrote: > A Pi3 running stable/13 updated yesterday has stopped accepting ssh logins. > The problem appeared after an update a couple days ago. The update was > repeated yesterday in hopes of catching some missing details, but no luck. > > A session originated from RaspiOS with -vvv ends showing only > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug3: send packet: type 50 > debug2: we sent a keyboard-interactive packet, wait for reply > debug3: receive packet: type 60 > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > Password for bob@pelorus.zefox.org: > debug3: send packet: type 61 61 is, apparently, SSH_MSG_USERAUTH_INFO_RESPONSE (No surprise.) > Connection closed by 50.1.20.24 port 22 > > The "connection closed" took a couple of minutes to appear. > Other ssh connections to older versions of FreeBSD seem to > work normally. I looked at bugzilla, nothing recent about > ssh. As a means of information gathering, when the RPi3 is running and older FreeBSD, can you try the -vvv activity and report the debug output, going a few packets past the type 61 notice to see what would normally be next? Also, do you have an alternative to using RaspiOS (or, even, avoiding Linux) for such a test?: checking if it is somehow specific to FreeBDS vs. RaspiOS/Linux or not? (Another FreeBSD or NetBSD or . . . For FreeBSD, trying having both machines using the problematical FreeBDS version could be interesting if that is the only combination that works, for example.) Have you checked for any console messages, dmesg -a output, or less /var/log/messages output that might be related? (This likely would require serial console access.) === Mark Millard marklmi at yahoo.com From nobody Tue Jan 11 05:34:43 2022 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 7E0BE1934DD7 for ; Tue, 11 Jan 2022 05:34:42 +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 4JXzsZ1rYtz3F4Z for ; Tue, 11 Jan 2022 05:34:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20B5Yi5u075437 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 10 Jan 2022 21:34:44 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20B5YiTE075436; Mon, 10 Jan 2022 21:34:44 -0800 (PST) (envelope-from fbsd) Date: Mon, 10 Jan 2022 21:34:43 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: SSH login failing on stable/13 Message-ID: <20220111053443.GA73926@www.zefox.net> References: <20220110193917.GA74116@www.zefox.net> <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@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: <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@yahoo.com> X-Rspamd-Queue-Id: 4JXzsZ1rYtz3F4Z X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3652 Lines: 91 On Mon, Jan 10, 2022 at 12:34:57PM -0800, Mark Millard wrote: > On 2022-Jan-10, at 11:39, bob prohaska wrote: > > > A Pi3 running stable/13 updated yesterday has stopped accepting ssh logins. > > The problem appeared after an update a couple days ago. The update was > > repeated yesterday in hopes of catching some missing details, but no luck. > > > > A session originated from RaspiOS with -vvv ends showing only > > debug3: authmethod_lookup keyboard-interactive > > debug3: remaining preferred: password > > debug3: authmethod_is_enabled keyboard-interactive > > debug1: Next authentication method: keyboard-interactive > > debug2: userauth_kbdint > > debug3: send packet: type 50 > > debug2: we sent a keyboard-interactive packet, wait for reply > > debug3: receive packet: type 60 > > debug2: input_userauth_info_req > > debug2: input_userauth_info_req: num_prompts 1 > > Password for bob@pelorus.zefox.org: > > debug3: send packet: type 61 > > 61 is, apparently, SSH_MSG_USERAUTH_INFO_RESPONSE > (No surprise.) > > > Connection closed by 50.1.20.24 port 22 > > > > The "connection closed" took a couple of minutes to appear. > > Other ssh connections to older versions of FreeBSD seem to > > work normally. I looked at bugzilla, nothing recent about > > ssh. > > As a means of information gathering, when the RPi3 is running > and older FreeBSD, can you try the -vvv activity and report > the debug output, going a few packets past the type 61 notice > to see what would normally be next? > Alas, no. I updated both of my Pi3's recently, and both seem to have similar problems. > Also, do you have an alternative to using RaspiOS (or, even, > avoiding Linux) for such a test?: checking if it is somehow > specific to FreeBDS vs. RaspiOS/Linux or not? (Another FreeBSD > or NetBSD or . . . For FreeBSD, trying having both machines > using the problematical FreeBDS version could be interesting > if that is the only combination that works, for example.) > Yes, I've tried a Pi2 running 12.3, which ends with debug2: we sent a keyboard-interactive packet, wait for reply debug3: receive packet: type 60 debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password for bob@pelorus.zefox.org: debug3: send packet: type 61 Connection closed by 50.1.20.24 port 22 Also tried 14-current, same outcome. > Have you checked for any console messages, dmesg -a output, > or less /var/log/messages output that might be related? > (This likely would require serial console access.) Yes, I have serial console access and there's been nothing on the console. One oddity, however. If I send pings to the troublesome host one or two packets make it back with normal round trip time. Then silence. Then a few more packets: bob@nemesis:~ % ping pelorus.zefox.org PING pelorus.zefox.org (50.1.20.24): 56 data bytes 64 bytes from 50.1.20.24: icmp_seq=0 ttl=63 time=2.976 ms 64 bytes from 50.1.20.24: icmp_seq=1 ttl=63 time=2.073 ms 64 bytes from 50.1.20.24: icmp_seq=58 ttl=63 time=1.662 ms 64 bytes from 50.1.20.24: icmp_seq=117 ttl=63 time=1.519 ms 64 bytes from 50.1.20.24: icmp_seq=118 ttl=63 time=1.555 ms 64 bytes from 50.1.20.24: icmp_seq=176 ttl=63 time=1.570 ms 64 bytes from 50.1.20.24: icmp_seq=177 ttl=63 time=1.586 ms 64 bytes from 50.1.20.24: icmp_seq=235 ttl=63 time=1.528 ms I'll let it run overnight, perhaps a pattern will emerge. Bootup is normal, time setting is successful and outgoing connections seem normal. I'm trying to finish an update to the Pi3 running -current (via serial console) and will shortly see if that works any better. Thanks for writing! bob prohaska From nobody Tue Jan 11 06:03:33 2022 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 B09B3193C158 for ; Tue, 11 Jan 2022 06:03:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JY0W638jVz3J3r for ; Tue, 11 Jan 2022 06:03:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641881019; bh=Mr8j36cNmn5GZWv3ratnXIRBc4fOnHLaoPibmFL3r8M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ueeBooQMjdfJ87esUoi0EKk1jZC/eO/6b3RB85Zr8/QDHZPhJrtVOQxLNhom9SmoGauzBdC+qn93poPqRNVkaQTn7P06ScRKRCCxEp6DfALRwSO3ZccFAKGKvCvSUGsjJPFQ9/jbYbZ3qg9jx/gw01yRDrkrwd045s4VR3C0sjHF4evv1xhFZZiaoqIgis+7T/QD4uwWfjEi6UZ5PSMpMp2wHnSdSS6s0kMz2Qff3kUKfJ+7Qz1Y6/VVIoxmzMW/b05PWJuY5CDZgd4a1LWOF2PiSGtw8p6Y2K7qFskb201kejK69tY5TCX+4BXMi6wxFjFMH4TtFSqB6M7dy9U0sg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641881019; bh=DLl8f2+NNGrCbRmk1RPtMmSuk7iTiNMI5h2tV/++yok=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=exadNB2Lw90x1dFhWlIKSoKvKVLsJWs26h+Fcq1Z4sJyUN094bYLpgcIG6SEX6M3d1Cnh716m7hmUJiYCN3WYZWylSu9XmUDOnbvfBLmH+GdrF0+L+wEbqLLGh7MgPSZCSQNpbmEiWhsmrX7ZivAIaX1r9gLU4nYhOIiiUZzqs3i2N3KsZAsSyR449Jqyt+aX6H1G7JBOWwiusAqugH7Cd0QUYUxLrreYpEVIwbkCRFXQXZ/p5CCIx38fFj4wZWW74CBS8heZIj8u16Ki1TPyDI1W2LKtm+rXsZK5GNfTOX1m9d4aZR76/8wFjmaRQF3TY37kFTJ5o5tzPzcAb3LAg== X-YMail-OSG: lq2jofIVM1nPFgDIiTLOaVZjKztqb8Dhd_5dLMj5cEhLqGh5hlcatnOUOn0O9i4 mGEFwWO1fEonTyjVz4JsaqbzFaRHEk1RkgBBC.rk3k0_dhXeGijsJkySfAfysGxV8UrrhWSjttLi ceMFaZxXVSlgcXXnXgAETUvlTMvKrJyr9CuHC4uR.8WscBjvmTJqQGUlbIsEABigxWBDavv0jWjr o0weAdoGevz_iIh4q54_uUWe8CXnK1fmcZMo5wTTJV5bcUFGv_NqOcjIhMH0Fr2krbFfcT.BUrdz EdcpppKo5s1daklmbBkZaWPuPzrUuO0_Lk9FwZFvv.F1tkY2kwy3TlW.lvTji1ZYjLSSZG.FuiL_ b8H6RQNf1Cwjvk2qOJGKe6fn7LfmR.j7AZnfLW.0ZY6uBtaDvUqL7VlSZPMFdAswKNF.UjyrGz.e DUUDecejr7QWRXO0yU7259mJXREAd2CrKfM7ichgtXaBCKFXUiRWrNyFFPbAkN.HVi6enjAboZq7 scJfpx5A.PfVkm1AkkyPoWx72fbrztHtFmzNuHCr9EV__UtaXmbmwRq9FvYVXBRVahMjlA9559Qp pwEQb9OXIYBrVfFKqgkJSkDbY.f.rP0Q29PvhChW2I.Z6znLtyLtP5wISuz8ZN7MZOfiAuQHzvmS 14cBAguXvz3e08UWZce6r7qKvU7OnKJL6X2PkhX6OUxc476FQfL9Ojza7t2Qf9B0OY7jKP_0TY0j TBMdjFBzqi6xr5X6mWvPAhzwvTxLPyvwute5G1yFagth79708MUNIWs8VZU9MDymOyp.rHrFc8Pc oI3ZtlpowOhU6GrgpcYiXgd1Jq1UI3IyfscfFEgVAWHcVwVmRt_1EOZ.X4y1.dwwrG0Uu2jefhz5 vey2zxtKzCf47Uwp_WCEtEZwaPteAAXIHSlKxyt3NK4MXeRoatkhDGk5AYgp4fB9yuk4GyDmFys7 G.7e32Afx9bcwsIT1J02P6XKedBdGyk10VhX.h0twBMLlt4ITA43C_SODIZ6NcX1_80sTYX4Mep9 BYbt9dMiRllgeXBy3YIJ2_dyTT7C3axgs49scIFDB8BW0QBK7w58MnOy.WmBUKH0WHom0c1zemW7 CqciVQnN.2sVUnqbczcuLUXS3VCEHIetQ.2LrPCBI5J4hFcCzqAWd9NmkxjJQNC.32gJM3c6RocF V4oT4DoBXN9kdGJP7x4AyN42tC8kLEoPlkGqhlh96a6Zu6VVElMRJl4m2rx6rIGItoATgAdP2fJN FKjbnMK6.si5bvAlU_ry8eccl2XFdmjwx2T4NSlvK4wT3ZK.9pu9PfMffGwmY0bYKp_voXqlUjdM gWfCQFwsH4XB28wWX8s0f.939mVl_byiUvaOyIUJaukiNbGRr_hD2MPvi2zk7MI7recBHnocqfqI epcDmC0oxt.rC8_WIG3EL4_1rZUqIKXwiCbWnPAtXq55aV78g0a2rGDt_by446JpHJt5eUbPLIR6 paryzrfuGg.M4522bGVprSiuwHGGMnuvheMCC7u1w.KRFm90GitHfqwZFoAKVhKwlrjqe1hrlGF_ j.cmQ45LHt7eDlC8Gx.0lEpe6s3i4MP7JMnlpUbXqJbdcq41C7UZWhqpIWO7odiD_fOrf_20LApJ NZUFyay8BBnejAgYeYBBQkV.A82KohB.ysIhPTBRsow7k6p_2yikphkpTyKNtKT.anvAEiK3PwN6 GX99S_ZTV69XVNFECeDK_qmzlr9_VvLTPtpFL7bIq5CyGlyYlZ1xsIq6tMSLemHYhEwUuhcrTZPp J9gNzna03ipl9lNa.fqz7AE8XGaU86VHoUonCsK_EKy3_RIPf3pSZpmJD0IZV3gamItgFihErZ8j PXaE2YO3Psmw0ScY.UkCsEgFhakiE3cFURMr8NIkhiEHI1SfVEGFFXVbD3Te_FwoQdrp_497D1UH 7bDvPhbKxeMiZBf7FDFb.67D21LXFquT7qZfJeK8z2NwOOYEHZQyaE.HvEH4dkPJ3faxx4t0D9A2 uivq7S_07g_mN0Hda7nUdfuO0lvvSLLMTvOQT2w82R_evXqUqD2kSl2pe_eHzqsTt5aJGgdBN7yn z2I418CMcOAr1kA7kkHfaNC3JrTPQbFyEdH7U25z0wTSCatExOqa7XQY40Hv8w5RRvnIXowLcesT XDPGACMyIG1AY1MU2UU7M2QFT3J2BUx94U1R1ErNKXFbHPjJe5o.gKo0BMxBpytbdtmkZKJLw.0t G1iCPEnRXZ_rFBBN9VkMnl9hMmU7579AWB7wBu2nk.tb3uRwjNLhR3SBqHzKBQHuGVuC8Oe8bgsQ XMpNJwQNGClMWJYV. X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Jan 2022 06:03:39 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 77655850f2482800ad3abe29399d0d82; Tue, 11 Jan 2022 06:03:35 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: SSH login failing on stable/13 From: Mark Millard In-Reply-To: <20220111053443.GA73926@www.zefox.net> Date: Mon, 10 Jan 2022 22:03:33 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220110193917.GA74116@www.zefox.net> <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@yahoo.com> <20220111053443.GA73926@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JY0W638jVz3J3r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4835 Lines: 130 On 2022-Jan-10, at 21:34, bob prohaska wrote: > On Mon, Jan 10, 2022 at 12:34:57PM -0800, Mark Millard wrote: >> On 2022-Jan-10, at 11:39, bob prohaska wrote: >>=20 >>> A Pi3 running stable/13 updated yesterday has stopped accepting ssh = logins. >>> The problem appeared after an update a couple days ago. The update = was=20 >>> repeated yesterday in hopes of catching some missing details, but no = luck. >>>=20 >>> A session originated from RaspiOS with -vvv ends showing only=20 >>> debug3: authmethod_lookup keyboard-interactive >>> debug3: remaining preferred: password >>> debug3: authmethod_is_enabled keyboard-interactive >>> debug1: Next authentication method: keyboard-interactive >>> debug2: userauth_kbdint >>> debug3: send packet: type 50 >>> debug2: we sent a keyboard-interactive packet, wait for reply >>> debug3: receive packet: type 60 >>> debug2: input_userauth_info_req >>> debug2: input_userauth_info_req: num_prompts 1 >>> Password for bob@pelorus.zefox.org: >>> debug3: send packet: type 61 >>=20 >> 61 is, apparently, SSH_MSG_USERAUTH_INFO_RESPONSE >> (No surprise.) >>=20 >>> Connection closed by 50.1.20.24 port 22 >>>=20 >>> The "connection closed" took a couple of minutes to appear. >>> Other ssh connections to older versions of FreeBSD seem to >>> work normally. I looked at bugzilla, nothing recent about >>> ssh.=20 >>=20 >> As a means of information gathering, when the RPi3 is running >> and older FreeBSD, can you try the -vvv activity and report >> the debug output, going a few packets past the type 61 notice >> to see what would normally be next? >>=20 > Alas, no. I updated both of my Pi3's recently, and both seem > to have similar problems.=20 Why not put a recent snapshot or artifacts build on a microsd card and try just that? Similarly for checking an older release, from a time frame you know your build(s) for your context were working? No need to mess up your normal-use context. If only your normal-use contexts fail, that would be interesting information as well. >> Also, do you have an alternative to using RaspiOS (or, even, >> avoiding Linux) for such a test?: checking if it is somehow >> specific to FreeBDS vs. RaspiOS/Linux or not? (Another FreeBSD >> or NetBSD or . . . For FreeBSD, trying having both machines >> using the problematical FreeBDS version could be interesting >> if that is the only combination that works, for example.) >>=20 > Yes, I've tried a Pi2 running 12.3, which ends with > debug2: we sent a keyboard-interactive packet, wait for reply > debug3: receive packet: type 60 > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > Password for bob@pelorus.zefox.org: > debug3: send packet: type 61 > Connection closed by 50.1.20.24 port 22 >=20 > Also tried 14-current, same outcome. Intersting. >> Have you checked for any console messages, dmesg -a output, >> or less /var/log/messages output that might be related? >> (This likely would require serial console access.) >=20 > Yes, I have serial console access and there's been nothing > on the console. >=20 > One oddity, however. If I send pings to the troublesome host > one or two packets make it back with normal round trip time.=20 > Then silence. Then a few more packets: The way I read the below, icmp_seq=3D0 and icmp_seq=3D1 took more time than icmp_seq=3D58 and icmp_seq=3D117 and the like. But lots of icmp_seq values did not complete a round trip. Also: 58-1 =3D=3D 57 176-118 =3D=3D 58 235-177 =3D=3D 58 It looks like the start of a pattern already. > bob@nemesis:~ % ping pelorus.zefox.org > PING pelorus.zefox.org (50.1.20.24): 56 data bytes > 64 bytes from 50.1.20.24: icmp_seq=3D0 ttl=3D63 time=3D2.976 ms > 64 bytes from 50.1.20.24: icmp_seq=3D1 ttl=3D63 time=3D2.073 ms > 64 bytes from 50.1.20.24: icmp_seq=3D58 ttl=3D63 time=3D1.662 ms > 64 bytes from 50.1.20.24: icmp_seq=3D117 ttl=3D63 time=3D1.519 ms > 64 bytes from 50.1.20.24: icmp_seq=3D118 ttl=3D63 time=3D1.555 ms > 64 bytes from 50.1.20.24: icmp_seq=3D176 ttl=3D63 time=3D1.570 ms > 64 bytes from 50.1.20.24: icmp_seq=3D177 ttl=3D63 time=3D1.586 ms > 64 bytes from 50.1.20.24: icmp_seq=3D235 ttl=3D63 time=3D1.528 ms=20 > I'll let it run overnight, perhaps a pattern will emerge. Intersting. I wonder what various statistics are like over such activities on both sides of the communications. Dropped packets? Other types of error counts? (I do not claim to know much about what statistics are available or the implications of what might be reported.) > Bootup is normal, time setting is successful and outgoing > connections seem normal.=20 >=20 > I'm trying to finish an update to the Pi3 running -current > (via serial console) and will shortly see if that works any > better. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 11 07:11:34 2022 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 8B032194C98C for ; Tue, 11 Jan 2022 07:11:47 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 4JY21Z5S5Wz3hqd for ; Tue, 11 Jan 2022 07:11:46 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pl1-x62b.google.com with SMTP id t18so6253967plg.9 for ; Mon, 10 Jan 2022 23:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PiWkv11GJjKei8LtHxwPSOgXOO8LeVgG19cOFPFvpSg=; b=H1i4uZtTALETueiDf/DE5J/1qC7Qc5qAKlFQ2HYXoyeZkvvKXa5BRDbYJQznjVREbM dT9lg0ptPmGqe6ecPhkW4aD9/zACMZs7Cq6fiuS3qkVFO/JklYt0l8aAiIT8wUWyPtbv uEiKBwhE0OqZ/OondI9GTrFcA+6/g6WgDXYr9eOJ88CgMuJBOZgeXc+Sud+1f/ile1pe KxqBmiqaB2Z3Suptx8YeRM0fZbtBJ9JMLKGIpYHHaPwsBzeP3VZZMYdSBQ6XwA4WneIS NN/SrcssFXtqksv+e5Lm3uWZOI3GwrcejcmfaTJFq7+RoyUX3t3DhfWXXc/WWAq3r+Vg n/pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PiWkv11GJjKei8LtHxwPSOgXOO8LeVgG19cOFPFvpSg=; b=5ndeG9/qO0NSNLVdv1OOB+WMDYFJaalkpcon9ac+tzvDx6LBVMmu0XTf6awPYuK/f1 ES+XeZG+HFIWHkYOyPoFzBDqs27SK0qSeAqv0yPjZ+zXuR5NCYvC5AsNOYPvBtHbF50W utZjD55GoRZK/qbBTkC9PBJh8HRdzOJBg4IYxv+2ufW8iK+36Mn96/EvvNSHaf/Ht9aL GdgaKgFPE0jF/RhXtHDohDNqcw9qN/AUBdSJlaJq8Y7/rufe4v5oR1JMS5/yY/OrZ2MX 7Ka1KEM3ajPkREW8SOrsj4MkP0mXWacFwMjeEc9nmKmfI4ZptAj2QdQcwylOoPQ+KKmo Ci3A== X-Gm-Message-State: AOAM531nslFn3dnTNDVv62qe/UjFKLGv5v3beMSNzMWQzsj2hq/X/vzZ hU8v+EdB1x7aIRpNbCw7G/hk5idBck5nWkVy X-Google-Smtp-Source: ABdhPJzNvCRby+rL/qNoQyDoYBAWn4U9eb6XfY88AE5tAYnFXavy8SLiBQ3STDrGAfU/BQbEKy0Xbg== X-Received: by 2002:a17:90b:314e:: with SMTP id ip14mr1701730pjb.171.1641885100060; Mon, 10 Jan 2022 23:11:40 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id h4sm9306842pfi.79.2022.01.10.23.11.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jan 2022 23:11:39 -0800 (PST) Subject: Re: SSH login failing on stable/13 To: freebsd-arm@freebsd.org References: <20220110193917.GA74116@www.zefox.net> <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@yahoo.com> <20220111053443.GA73926@www.zefox.net> From: MJ Message-ID: Date: Tue, 11 Jan 2022 18:11:34 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20220111053443.GA73926@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JY21Z5S5Wz3hqd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=H1i4uZtT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-3.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.60)[-0.603]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62b:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2116 Lines: 45 On 11/01/2022 4:34 pm, bob prohaska wrote: [...snip...] > > bob@nemesis:~ % ping pelorus.zefox.org > PING pelorus.zefox.org (50.1.20.24): 56 data bytes > 64 bytes from 50.1.20.24: icmp_seq=0 ttl=63 time=2.976 ms > 64 bytes from 50.1.20.24: icmp_seq=1 ttl=63 time=2.073 ms > 64 bytes from 50.1.20.24: icmp_seq=58 ttl=63 time=1.662 ms > 64 bytes from 50.1.20.24: icmp_seq=117 ttl=63 time=1.519 ms > 64 bytes from 50.1.20.24: icmp_seq=118 ttl=63 time=1.555 ms > 64 bytes from 50.1.20.24: icmp_seq=176 ttl=63 time=1.570 ms > 64 bytes from 50.1.20.24: icmp_seq=177 ttl=63 time=1.586 ms > 64 bytes from 50.1.20.24: icmp_seq=235 ttl=63 time=1.528 ms > I'll let it run overnight, perhaps a pattern will emerge. Sorry to be presumptuous but I just pinged your system, I get continual returns. Ok, it's a long way away from you but it looks, to me, like there's something internal to your network. Are you sure this IP is not in an arp cache or being used by something else? 13 ~> ping -c 15 50.1.20.24 PING 50.1.20.24 (50.1.20.24): 56 data bytes 64 bytes from 50.1.20.24: icmp_seq=0 ttl=46 time=198.378 ms 64 bytes from 50.1.20.24: icmp_seq=1 ttl=46 time=199.968 ms 64 bytes from 50.1.20.24: icmp_seq=2 ttl=46 time=200.883 ms 64 bytes from 50.1.20.24: icmp_seq=3 ttl=46 time=196.515 ms 64 bytes from 50.1.20.24: icmp_seq=4 ttl=46 time=207.787 ms 64 bytes from 50.1.20.24: icmp_seq=5 ttl=46 time=196.934 ms 64 bytes from 50.1.20.24: icmp_seq=6 ttl=46 time=197.065 ms 64 bytes from 50.1.20.24: icmp_seq=7 ttl=46 time=225.672 ms 64 bytes from 50.1.20.24: icmp_seq=8 ttl=46 time=197.933 ms 64 bytes from 50.1.20.24: icmp_seq=9 ttl=46 time=202.677 ms 64 bytes from 50.1.20.24: icmp_seq=10 ttl=46 time=201.935 ms 64 bytes from 50.1.20.24: icmp_seq=11 ttl=46 time=199.196 ms 64 bytes from 50.1.20.24: icmp_seq=12 ttl=46 time=199.852 ms 64 bytes from 50.1.20.24: icmp_seq=13 ttl=46 time=197.222 ms 64 bytes from 50.1.20.24: icmp_seq=14 ttl=46 time=199.437 ms --- 50.1.20.24 ping statistics --- 15 packets transmitted, 15 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 196.515/201.430/225.672/7.054 ms MJ From nobody Tue Jan 11 10:50:45 2022 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 E51A7194D926 for ; Tue, 11 Jan 2022 10:51:04 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmse01.mailcluster.com.au (vmse01.mailcluster.com.au [IPv6:2401:fc00:2:13f::6]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JY6tZ3bgKz3Fwg for ; Tue, 11 Jan 2022 10:51:01 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmcp43.digitalpacific.com.au ([101.0.119.58]) by vmse01.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1n7Ejo-0004FQ-5d for freebsd-arm@freebsd.org; Tue, 11 Jan 2022 21:50:50 +1100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: Subject:From:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+3aKdazOKe/wLBEXiRapYkKVpbVGXBKaCoHq6ESzn+w=; b=DuTEoPip41wOKd/De2ng492I0w a8WIqItsfPnoL2vhNknvDaHqOqqb/MbLZ0PNwXOXXpxq54CEtJrnH2imXOq4VnWo5rY8imrPGaQfv tbhk5k1X+qFalNBhBkRZ+VH8dm/frxq8+NBkS/BHvEmV63EeJtE35rLzi0RwcILM9pHmMBH/F1MLc dIrZwiGu4G+3vh8rvDIvmwysK9NbEPFJoyErn88AwcFm7ORKBRRAuxc7/NodUI/XFluPkqvby2y4E 1fqTPb7W5ZCnZv9SmjaBjgBHVrYfvF4IOqMKb7FXJD0I0ZvLkWf6G8GMmR0Vo7YeWnlF+mCtWivPf SdJLMG1g==; Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:53475 helo=[10.0.1.106]) by vmcp43.digitalpacific.com.au with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n7Ejm-007bzx-GW for freebsd-arm@freebsd.org; Tue, 11 Jan 2022 21:50:46 +1100 Message-ID: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> Date: Tue, 11 Jan 2022 21:50:45 +1100 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 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: freebsd-arm@freebsd.org From: Brian Scott Subject: RPi4B, POE+. Fan Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: bscott@bunyatech.com.au X-Authenticator: dovecot_plain X-Originating-IP: 101.0.119.58 X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au X-SpamExperts-Username: 101.0.119.58 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4YRap+fLHCtiOMd9YrIX/RDABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyqRBrz0yacPB+Vpb1pvfg9Ep8Gnm YnDDwZLHsvD3pj+LAFDzNQBFf2eJwTI6seviroj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC4H lza800dwJYdFHiSd6z64Xq3WCPVb9Sx+m7pFDPv6ThKudUlZNJsHnGAk8cphlbbF4DEPUxAkEvKE S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbtnrSZKBVVGtARFAPPtdvpAASOtvf/+xtvbFr8w LHfAT1z1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE= X-Report-Abuse-To: spam@vmse01.mailcluster.com.au X-Rspamd-Queue-Id: 4JY6tZ3bgKz3Fwg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bunyatech.com.au header.s=default header.b=DuTEoPip; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:2:13f::6 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bunyatech.com.au]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[bunyatech.com.au:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 837 Lines: 26 Hi List, Is there a known method to get the fan running on the rpi-poe+ board under FreeBSD? It looks like it is controlled completely by the kernel in Linux land. Adding the rpi-poe dtb overlay has no effect on FreeBSD so I'm guessing there is no driver for it. From what I've read, its controlled by something on the iic bus used for HAT identification. Beyond that, information seems to get very scarce. The Linux driver operates it by sending messages to the firmware. This would be a lot more tricky than just sending commands to an iic device from userland and beyond my hacking skills. CPU temperature currently is: dev.cpu.0.temperature: 86.6C so I would quite happy if I could just turn it on. Running FreeBSD 13 Stable with a snapshot from 16 December 2021. System is loosely based on nanobsd. Cheers, Brian From nobody Tue Jan 11 21:32:27 2022 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 006F7196755D for ; Tue, 11 Jan 2022 21:32:39 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JYP6t0TQPz4Wwh for ; Tue, 11 Jan 2022 21:32:38 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9EFCA3200BF9 for ; Tue, 11 Jan 2022 16:32:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 11 Jan 2022 16:32:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm1; bh=uNYq4EwCQvOD623ydUCWvU26cwsJYklvoH7zYVGob5k=; b=It+m7iXi vrSrC4zGfQz6m/Rg8UPxq9+IyzPgqJ6xEow7AHu8DhubduhhnNVN7LH82EVzTKFE /SLbGxsH8F1nhz0OD0gchqBluASpkxWlS1QOIAWCIxGmIelAC2KiDpGVzFIvA8NL Fc2mKGGdPGW9iFXPbi1vS11Ha7Tfl3zfMhoqYruz82Ju028089fGAPp0hGePkzNS affOAdw07Qn6vnPpTfSHCbW1Rdj2HqeY9PmN87qVFSkRFBvVMnTICt0232Z/q16f KJz5BSCSPzAZ/Pgk6diSrLIG3yyATXD/1JVkqk9rG4ri64rKQC8vSbglTCVTTUo4 6vRAAMH04Vnc4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=uNYq4EwCQvOD623ydUCWvU26cwsJY klvoH7zYVGob5k=; b=d4QEe2oFFA6NJEw6Ak0eRQLqTfhkOnivUqvG4KS/y0qkT WBvxR5gUhuOBDoTjOngRJY6Q6bLsrbCoJ2SUG2HgACqrKFbN9zeb7oOO+85eieQ5 9mdA70+jSUeEPHN1Dde8ejUjRMzq6vJCJd/UYU5VaFANJHTT+Mj/2sm6OannDrjr aJP7dK5qQ0/daZV/pTUk1wr84g3dzowuHdGNykbw6imd5c+pvfoZNJpFE9ZSLPsy M8JaBy8m8YujqX6SfpQ2vNOfyqoKmWsaPeslRaKmcO53r09yg2bEv3VYHU7ALvCB 8iGs5KZmbS3L5SYJkiBPFsGfojIA8Chg25sUbRXtw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehfedgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnhepvefghffftdefkeelleehtdejledvhf dvgeeijeevfffguddvhfetgeejueejueeinecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 11 Jan 2022 16:32:29 -0500 (EST) Date: Tue, 11 Jan 2022 21:32:27 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: graphical performance for rpi4/8GB and stable/13 or -current Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ghDHy8s0zbINPxBX" Content-Disposition: inline X-Rspamd-Queue-Id: 4JYP6t0TQPz4Wwh X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=It+m7iXi; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=d4QEe2oF; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.25:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.60:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; DBL_PROHIBIT(0.00)[0.0.0.60:email] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1493 Lines: 40 --ghDHy8s0zbINPxBX Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=20 As subject: has anyone used rpi4/8GB yet as a desktop? What=20 resolution do you get. Does it do 1920x1080 on freebsd? Is=20 kde5/plasma usable? I'd just be using the one monitor. I know=20 (at least under linux) it can do 3840x2160@60 on one screen, but that=20 might be linux-only I guess. just wondering if it's been done yet on=20 freebsd, as a search doesn't turn up much. thanks, --=20 J. --ghDHy8s0zbINPxBX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHd92EACgkQs8o7QhFz NAVjihAAgt3182jp+OExyfFkl3rZ9L7xqHxRukdlHlv2CKq9qMJOt4msdBBv52Mm ccKOsipfR5riy/C5PRc5bWIb7GNvkKl+6Vwunxpicfyj2bN6u5BsTJF7iyz6bhV+ tNSUldtwC8aUrUX/XLOo6gir3kkOqrggDVYkG2d3q00ZButQ22Y5Vf4wU0+hn/ao wnbRvLGesoy5o4piosc7RfeRbfMjL8WBqZv8Moun/K9z2PgkIojSwIFit2cA8rJo +ElBJ2aO99mZcYzBqBUNWtYxawelxM5BdmcFVNI2AnWcO/x6fIkbb49B/bTGnV/t Yma2m/XrQqoR4bwke/ylHdUgRxUCyuDbJvNzS9aGZ3cDbcnGHCbEt6FkowXdcv+u YbClSFu1Xt1wwqOUJwu+jhyE6u797SRSRExq5WSQEdPoNDj2XXIWoalIRlu/OuZx Y85jAnYUEA6jpbjz29avogstVCgIW2cJiYVQp4G/MLkluwsQ5T91N7u9yWsxof/Q DiX1cAQJt/iy2pPlaz9VKGlEqpIGzOWSHbW5Q4g4cqlcBMODc2bsvB/OMZ2Cr4VF EtMDcypJ6+Ga8FKE2lJhebN/FAWAyKsytAAmJLVqcgMjpLLljfLFpNlOy+7kTN7G TsWrjp7DAjkLxnMftn1zI/+0yP0An25iXWzgCTt2DR+UG6nok1A= =1AvL -----END PGP SIGNATURE----- --ghDHy8s0zbINPxBX-- From nobody Wed Jan 12 00:23:31 2022 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 B2353194495B for ; Wed, 12 Jan 2022 00:23:44 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4JYSwH5lVdz3RDl for ; Wed, 12 Jan 2022 00:23:43 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x102e.google.com with SMTP id oa15so1758766pjb.4 for ; Tue, 11 Jan 2022 16:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=j2QDQDca8kGhMKPozXmG5n8APwRDYrZ7FjdiY2W/Ezo=; b=mBOVXkVU4avecwKBYxrQd0JwVgEe/9FyWMGl/kwLflu8BDh6hN6AiVMdO0DpqZWvmO kNk+4XfKnT1phIcDI/IVjTWe1ADSmF/QPjPxircw6IZZyvBG+QGSEPA0IIm2+PTqZ5gN HfOd19nUtSDEmm3JdMI+5XCODlbyaDon2aKAK8TrpxV27uY4jBsgKmq6L9coDfDTDkJm 62OpTXXt+5s5fC8gRZbHPyqYKPajzg56w1QiR64o8AQ8qZf56qTRN0mK4DMsBP/BiZju jrAKF8AWA9UyZB0N/cAqZac3/FSs9PjCjwmHDEiS/XkD9+o/aAyPjjXo5af7m8oRgwsf ylDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j2QDQDca8kGhMKPozXmG5n8APwRDYrZ7FjdiY2W/Ezo=; b=wH8loCKbR3I00NA4ly2Tbpn5IXahqXrvCbGGNaIkerTdeSomAoulKy+88tNB/F4gNX Q8wrfj7pQvhjN8bTkOANntw4ng5oQv/LAH5ldzudU7EsEyUvachQRX6YO2DYXenV+Tam T9J3ZbdUN7x/d3oyK22C3c+hCGuMTk13E7QCaL0Fae2YJwSIzhNf8DJccODS3qkLy9KS 2uH1/9r8o4qTZi/E9FgfuDFA7MHFDwwmFEQ9ZOovQSm7L2/G2E5j8rHSUWSA21eLA+mV 72+aAWmZbVP6JpGYeT3PgcDJjfu7Evaa1MZrSyliP7BxRkxRyKVvUmJ+wH+vOgb4rFvH M4Ow== X-Gm-Message-State: AOAM533RjhfICo3VvKhGBtOTMPBwgGwruf36wro5LspNyBvjqPwgq3Gn hANBLG4hogjBtwy900KKr85/pwumXE3nJE8h X-Google-Smtp-Source: ABdhPJwfT/rFaEBF97QYKq4n3wxtWaAfYTrA/RRFrvTjKOLIo7M9jRgpDxQ0FwZmzak4jxfh2GtcOQ== X-Received: by 2002:a17:90a:8c0e:: with SMTP id a14mr5845357pjo.111.1641947016608; Tue, 11 Jan 2022 16:23:36 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id 20sm3828998pfh.71.2022.01.11.16.23.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 16:23:36 -0800 (PST) Subject: Re: RPi4B, POE+. Fan To: freebsd-arm@freebsd.org References: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> From: MJ Message-ID: <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> Date: Wed, 12 Jan 2022 11:23:31 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JYSwH5lVdz3RDl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mBOVXkVU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1092 Lines: 21 On 11/01/2022 9:50 pm, Brian Scott wrote: > Hi List, > > Is there a known method to get the fan running on the rpi-poe+ board under FreeBSD? > I would assume this depends on the board. You've not specified anything. > It looks like it is controlled completely by the kernel in Linux land. Adding the rpi-poe dtb overlay has no effect on FreeBSD so I'm guessing there is no driver for it. > > From what I've read, its controlled by something on the iic bus used for HAT identification. Beyond that, information seems to get very scarce. The Linux driver operates it by sending messages to the firmware. This would be a lot more tricky than just sending commands to an iic device from userland and beyond my hacking skills. If it is i2c rather than some n-channel FET, then you have a few options: 1. Look on the design specifications or data sheet for the address of the i2c. 2. Build an i2c scanner using an arduino. This will scan for the address on the bus. Once you have the address it's trivial to program i2c.There's lots of examples of how to do this out in the internet. MJ From nobody Wed Jan 12 03:59:13 2022 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 7FAEF19666A1 for ; Wed, 12 Jan 2022 03:59:35 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmse01.mailcluster.com.au (vmse01.mailcluster.com.au [IPv6:2401:fc00:2:13f::6]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JYYjK36CXz4p9x for ; Wed, 12 Jan 2022 03:59:32 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmcp43.digitalpacific.com.au ([101.0.119.58]) by vmse01.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1n7Un5-000843-N3 for freebsd-arm@freebsd.org; Wed, 12 Jan 2022 14:59:27 +1100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ODjZEnMb5dPdfAP9W5EEEzLQgaAeYhJ7kvACAt1kiU4=; b=YVUsjOGsXcUU/5i0yo3PA/0R9Q QuKyElxMPb4wIwvFnaAimZSmpa1tiAcEeHs2vH79ki43QCBBwqUVs6k103Fxe6kjrP0vhobIkySyA eg3g2+9JLP//fV5IUlYWFhQ3Rz114BR3CNWxiKlSt/7B6RNgohRoE6qWTG07/sbAUo5hMLikxXdTB Y9vUl5gei04KkSwOF9NsJ2J6SXMz1+ld9UnwqR75na7PHG5uwf4j9qlhwKnU6H4gdU32zlOmNqbPJ Lzpdu6fnbtyQgAZsIIVAnMXO31d7fMZsnKN5bIaL5/ir7CkVGWN24awkGcCiR7kxnYAPjLfUW+8Dn YAA6XaXw==; Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:38708 helo=[10.0.1.106]) by vmcp43.digitalpacific.com.au with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n7Un3-00CPrc-TQ for freebsd-arm@freebsd.org; Wed, 12 Jan 2022 14:59:13 +1100 Message-ID: <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> Date: Wed, 12 Jan 2022 14:59:13 +1100 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 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: RPi4B, POE+. Fan To: freebsd-arm@freebsd.org References: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> From: Brian Scott In-Reply-To: <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: bscott@bunyatech.com.au X-Authenticator: dovecot_plain X-Originating-IP: 101.0.119.58 X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au X-SpamExperts-Username: 101.0.119.58 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8TVgss02ve6CVraySds+s6PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4YMy1/2SssDpHy5zbs3dr0yABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyqRBrz0yacPB+Vpb1pvfg9Ep8Gnm YnDDwZLHsvD3pj+LAFDzNQBFf2eJwTI6seviroj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC4H lza800dwJYdFHiSd6z64Xq3WCPVb9Sx+m7pFDPv6ThoUaIf7jV7EkdaQS8Iac53F4DEPUxAkEvKE S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbtnrSZKBVVGtARFAPPtdvpArgj6s7IO79Yg2u4H JtZwslz1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE= X-Report-Abuse-To: spam@vmse01.mailcluster.com.au X-Rspamd-Queue-Id: 4JYYjK36CXz4p9x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bunyatech.com.au header.s=default header.b=YVUsjOGs; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:2:13f::6 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bunyatech.com.au]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[bunyatech.com.au:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2265 Lines: 63 Hi, On 12/1/22 11:23 am, MJ wrote: > > > On 11/01/2022 9:50 pm, Brian Scott wrote: >> Hi List, >> >> Is there a known method to get the fan running on the rpi-poe+ board >> under FreeBSD? >> > > I would assume this depends on the board. You've not specified anything. Sorry, I should have been more explicit. The board is the 'official' rpi-poe+ board from the raspberry pi foundation. I should have underlined that. https://www.raspberrypi.com/products/poe-plus-hat/ >> It looks like it is controlled completely by the kernel in Linux >> land. Adding the rpi-poe dtb overlay has no effect on FreeBSD so I'm >> guessing there is no driver for it. >> >>  From what I've read, its controlled by something on the iic bus used >> for HAT identification. Beyond that, information seems to get very >> scarce. The Linux driver operates it by sending messages to the >> firmware. This would be a lot more tricky than just sending commands >> to an iic device from userland and beyond my hacking skills. > > If it is i2c rather than some n-channel FET, then you have a few options: > 1. Look on the design specifications or data sheet for the address of > the i2c. > 2. Build an i2c scanner using an arduino. This will scan for the > address on the bus. All of the official documentation seems to revolve around enabling the device in the Linux kernel. I have found schematics for the power handling side of the board but nothing for the fan side. I'm happy scanning the i2c bus from the Pi directly. The FreeBSD i2c command has worked well in the past. Knowing the address of the device doesn't tell me what it is since many i2c addresses are shared between many different device types. > > Once you have the address it's trivial to program i2c.There's lots of > examples of how to do this out in the internet. > > MJ Thanks. As I said, knowing the address doesn't tell me what it is, only how to address it. The only example of code that I've found for this device is in the Linux kernel and uses an interface to the firmware rather than directly through i2c. I'll follow your advice and do some bus probing to see what is there since I believe it's possible to access the second i2c bus with the right config.txt entries. Thanks Brian From nobody Wed Jan 12 06:46:39 2022 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 BE345194A2C0 for ; Wed, 12 Jan 2022 06:46:49 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JYdQJ6djQz3lms for ; Wed, 12 Jan 2022 06:46:48 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 264293201591 for ; Wed, 12 Jan 2022 01:46:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 12 Jan 2022 01:46:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=9Ni9Yiwqwlb3gaTYfr7rayLn2Ic RtAbSumFTSnhglno=; b=MhioGu9VFoHW0ZDrLFOwm8/QS4l2lgTQlIkh2vKrGnV CwxmNVOT2amA+4ZsJqnr7hLI0oYzb7adaDN7/GPo4HGdLvbOWgfBW4ZS7d+3R66R OFmoWmsPFGEUDEA73/7qgAd0rNKFnpjN4bzjHEx0pEMKus6t5VtuxzjnR2S4tiVz cMAkDu+55+TnmpCRunyNMpDWIyWQapTbaGwBLJPo+04/3emDn5VBI7NhOMX4g/k/ 5XNoLxhElheeQCxHbVH7OkQZ/oWOFHBsoWAnNHGdT3sknGGIG9PqbL76+xlpMtPa x+80uiuDNmunO1OZlCuQsKPWYlq3D9dPiZCP3vJiX3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9Ni9Yi wqwlb3gaTYfr7rayLn2IcRtAbSumFTSnhglno=; b=lPFUunaE0n9FY1SdDYqh+Z kfAOBlPMDaLIWO35YbkP4Teg+cyqtDLdQh5qWlFGjQHsJ8fbu8g+WUF+blq8wNIO spsqYQRwUtQ+A2uJqCnJEljXMEFmGsvIcC4m6LPwmhXi766fubYbWPPU1YMgae8a 81Q7HFAD7U3x8n/3SN6r0GG+YebCfkOclkOkkKs72driCFIry0UWY4zcS7FgKGEX ZTXhPRb08fI9Kk++5gTbYC21T9ri7oWUgaMPBbdRsbHYtYEyGh0rkoVCwN6WL/Y1 zCW3ptHHSGhe6yrhtDtBJElNktXjpdNm4CA1TiXHFJx11dxWhSEGVrvFijoR8qDQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehgedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvd ettddtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvg ht X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 12 Jan 2022 01:46:41 -0500 (EST) Date: Wed, 12 Jan 2022 06:46:39 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: graphical performance for rpi4/8GB and stable/13 or -current Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EqR1gk5qU7ESFp+4" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JYdQJ6djQz3lms X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=MhioGu9V; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=lPFUunaE; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.20 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.95)[-0.952]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.01)[-0.014]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.60:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; DBL_PROHIBIT(0.00)[0.0.0.60:email]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.20:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1846 Lines: 46 --EqR1gk5qU7ESFp+4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2022 at 09:32:27PM +0000, tech-lists wrote: >Hi, > >As subject: has anyone used rpi4/8GB yet as a desktop? What >resolution do you get. Does it do 1920x1080 on freebsd? Is >kde5/plasma usable? I'd just be using the one monitor. I know >(at least under linux) it can do 3840x2160@60 on one screen, but that >might be linux-only I guess. just wondering if it's been done yet on >freebsd, as a search doesn't turn up much. It seems to work great with xfce4 and gpu split 1024M. With=20 kde5/plasma it would get as far as the mouse pointer on a black=20 screen and sit there. I think better performance would be had with=20 usb3 spinning rust though. A usb3 key still isn't fast enough. =20 (clocked to 2.2GHz with excellent cooling) --=20 J. --EqR1gk5qU7ESFp+4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHeeUUACgkQs8o7QhFz NAW8Tg/+OAj/LfLr+qJ1NRNSvuGZzaSu016ccf9v2bat3RtTHIJUCUu2Nev/ckb3 b6Av11v+W3PKZtU+rUYYtkqC+LE0Y0QrxCEKhZR+nMw7BQHp2E+h4EWNwi/ee0UL QnQ8PstKJEK7hsfjHg8N9SuSHzivdH/NLs4SE1ycVxlOK1vRf8KAlFyXo19GX5Cg ncDMA0U38zoIjzm9VCDfLCBKMlpiHUwITTzWNbYbD0Aq6gV/jfXALu65NJwbIrN1 vrq1uUOko752b4hB59dxxHYZmV5AeX6uHYkXe4elR+a2zrF0FFQAHaX5ShOZJKqn 5haBAzBh25WusGjrlrjHducMg/N5B201p+Hl8azW0tUhSGXP6AnhEBiKLfbIcovt 3YrAjJbobqDEV4Gfn/RKGTDQp5RyiV5gMGe29SbH8d1c+QVB+E1y/oH2hQnU5FFL kRkYqgT81S5SdyMMz47caFbI3CqZDEcEghZbEfIZb9tFguhIFoJh0C+xUPD8jrbC y5oB2Xo9xul5RRFtKM1esYGuc4aMdGqRNpzyCtUdzseJ94NAYH3wL8k/thQhQU7l gow96hrZWk4hXsbtBQVEVaywhlszk+IHOpOTWxB3jnU6UeYEFDZM7oUznrWCr/LT 1d2AYZWffTQPdZTHkzk9SSVAA2VS1NZMTrsNm4VOqN4M/QgoAZI= =TPdr -----END PGP SIGNATURE----- --EqR1gk5qU7ESFp+4-- From nobody Thu Jan 13 02:35:45 2022 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 6F5E1194AC55 for ; Thu, 13 Jan 2022 02:35:50 +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 4JZ7pF3NfYz4jtf for ; Thu, 13 Jan 2022 02:35:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20D2Zjda000658 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 12 Jan 2022 18:35:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20D2Zj3X000657; Wed, 12 Jan 2022 18:35:45 -0800 (PST) (envelope-from fbsd) Date: Wed, 12 Jan 2022 18:35:45 -0800 From: bob prohaska To: MJ Cc: freebsd-arm@freebsd.org Subject: Re: SSH login failing on stable/13 Message-ID: <20220113023545.GA616@www.zefox.net> References: <20220110193917.GA74116@www.zefox.net> <19F80CC0-B7B0-4929-9FA0-460BBF35AADE@yahoo.com> <20220111053443.GA73926@www.zefox.net> 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: 4JZ7pF3NfYz4jtf X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 762 Lines: 20 On Tue, Jan 11, 2022 at 06:11:34PM +1100, MJ wrote: > > > > Sorry to be presumptuous but I just pinged your system, I get continual returns. Ok, it's a long way away from you but it looks, to me, like there's something internal to your network. > Are you sure this IP is not in an arp cache or being used by something else? > In fact you're correct. There was an internal misconfiguration, but it was between my ears. It only affected my reporting, far as I can tell.... This errata report looks like it might have some bearing on the issue: https://www.freebsd.org/security/advisories/FreeBSD-EN-22:06.libalias.asc Most of the trouble was observed over a NAT conection. Upgrades are in progress, perhaps they'll help. Thanks for writing! bob prohaska From nobody Thu Jan 13 18:45:56 2022 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 AE02D195E5F7 for ; Thu, 13 Jan 2022 18:46:07 +0000 (UTC) (envelope-from solo_public@protonmail.com) Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.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 (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZYKp4xgWz3jYd for ; Thu, 13 Jan 2022 18:46:06 +0000 (UTC) (envelope-from solo_public@protonmail.com) Date: Thu, 13 Jan 2022 18:45:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1642099558; bh=5ukxXH598ja+VeVDHZDSZ1+j+9m2/GcEW4dbIOX+kHM=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc; b=ZRYAaorOniVm0EG5hWr8QuXdrjifBW/w+v+izWTUV28Etnf5LaxDH/TEZY/akmEYK VUMoK5VjfsIMV4nzLemoty1mtynCQg6BfBdyaSTpETn3c3KWyiovIAQD71dQT773HS Dsf6zthqbUCSYcro33m8AHTskfJetywS/EuFfrRVVVbrsf8iVQVor+2XLJo8wH/KLy E5/dA1uNLFzTGrPvTFqcWOENs9RyqgZK8kd6TIh8wXnxLSw6rTbuRm2o3LR8np3chs QnQUDZXAmQctLlJ4C59QYVe0uakZ+WCriTTiB2rXLr9Dsbgvytj6NBDgjmXFX9xFrN +ZslKN5MvkXnw== To: "freebsd-arm@freebsd.org" From: Soeren Lorenz Reply-To: Soeren Lorenz Subject: OpenZFS still stable on armv7? 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JZYKp4xgWz3jYd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=ZRYAaorO; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of solo_public@protonmail.com designates 185.70.43.18 as permitted sender) smtp.mailfrom=solo_public@protonmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; HAS_REPLYTO(0.00)[solo_public@protonmail.com]; RWL_MAILSPIKE_GOOD(0.00)[185.70.43.18:from]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 937 Lines: 21 Hi all, I'm having a hard time to get FreeBSD-13 running on a Helios4. It's a quite= well equipped SBC with 2GB RAM and four SATA channels. I know the issues w= ith ZFS on 32 bit platforms and fiddled already with the suggestions from h= ttps://wiki.freebsd.org/ZFSTuningGuide#i386. Still I just don't get it runn= ing. No matter what kmem_size or how small the ARC - it only extends the time ZF= S works until the whole machine hangs. There are no OOM warnings or any err= or messages at all. First the ZFS processes stop working while everything e= lse still seems to respond, then no new processes can be started until ever= ything just freezes. I tried 13/release and 13/stable - no difference. I think the memory management was considerably changed with OpenZFS. So wha= t of this old vm adjustment stuff is still relevant? What could be the next= debugging steps? Could anybody with insights lend me a hand? Regards, Soeren From nobody Fri Jan 14 00:38:57 2022 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 C843219426FF for ; Fri, 14 Jan 2022 00:39:24 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmse04.mailcluster.com.au (vmse04.mailcluster.com.au [IPv6:2401:fc00:4:1::6]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JZj9P0mxRz4f40 for ; Fri, 14 Jan 2022 00:39:20 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from vmcp43.digitalpacific.com.au ([101.0.119.58]) by vmse04.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1n8AcN-0003oX-4O for freebsd-arm@freebsd.org; Fri, 14 Jan 2022 11:39:08 +1100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T+sGaJ44evCfiRK0u8KHBavHTVo7YHef0dy2i717JDA=; b=cnsf8V3D+CS5lbgic/ZWHvPcFN 3dda2WM7T60NQ3H0yqeGJooJuNnoJyRk2z3gTUnlK3ojkgJ0GC1aET5W6bWY03fluB8M3uyDWsMi6 WAKWgoaJpUUHUBOxbowZJXeqM0YXDJcIFRjVk9OgBAZQR9YPTLUfG6/yYsGJ8XM2nvAB3p4LV3ib7 HAQs5JI2RbZhexlvFkANKSkUXvmfzX8B+Yb7uwCkDMmu0qvmTJirjl8Xj/Dg4XYfuMXTd5UtYBELR orudB/5AngILDZP3H8ewRhGsaPnmE5ovjTorlL/gMFTnXmEcnLpS7/JzqayobZLd1ItdRw3rAhe4U fpx/gjWQ==; Received: from 203-113-203-135-static.tcs.netspace.net.au ([203.113.203.135]:6337 helo=[10.153.14.100]) by vmcp43.digitalpacific.com.au with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n8AcL-007TKI-I1 for freebsd-arm@freebsd.org; Fri, 14 Jan 2022 11:38:57 +1100 Message-ID: <590ae9e7-095d-9269-6ec1-54dc403e0440@bunyatech.com.au> Date: Fri, 14 Jan 2022 11:38:57 +1100 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 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: RPi4B, POE+. Fan To: freebsd-arm@freebsd.org References: <7ddec2da-b22a-9d3d-b64b-6c8137ff8f6d@bunyatech.com.au> <5a2db808-d90a-cebd-51d2-7b4ee9953a75@gmail.com> <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> From: Brian Scott In-Reply-To: <4b24de3a-0124-50d6-e1bc-cc45785e3755@bunyatech.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: bscott@bunyatech.com.au X-Authenticator: dovecot_plain X-Originating-IP: 101.0.119.58 X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au X-SpamExperts-Username: 101.0.119.58 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8l/yLJ0Sqxdhy5JNIBIKHCPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH zJ6mVE7ewsipSVIfs4Yx/owv2FAzm7Y56pBI5zAuABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyqRBrz0yacPB+Vpb1pvfg9Ep8Gnm YnDDwZLHsvD3pj+L6FeN7H3/w7GNoXC45RpOKoj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC6v 12zNU5FHE/848hPLR1NYJla5IMQxwODSBUvv4iU63ukMT1XB043+JMyRJb1r5cd51HO6Firt88BV o4G3txy5xc8zPwPk/btDEg7yakhCkffQsJMjVuaCfq+S2F3DJOIRFZ4oobg8BBg3Jq+ntzj0NT70 kg2R2AKhDFzLC6np7U+Md/gsArzQL2xycpCDCvGkBJTycjSXYBbCRRLP/dzFGZvgVYfsK2EFAO2J yl68xeQJyPsBMRItmV2XMBZo/xvBcCqAIZodttem9i8KPHD+drySbwSPPFfZ0IrAVj3Tw2Kom956 CMNJENTxvHFc+CYnIrUaXo9oAQiaJUfHr8RdDkAjKCmcD+WP58n3ucKpsOwZrS0DLzSls2xwT68s ll0AUPM1AEV/Z4nBMjqx6+Ku85fPBYtEyP9wDgCiat7XFq2oD4F3wvnFD1nsYpfi92UulJUd6p/S u0x6qJLP8ZJcWEwQPAv2fxf3s0iIhEk0C9A6WFpTPd8WVXqUqH9xpi0= X-Report-Abuse-To: spam@vmse01.mailcluster.com.au X-Rspamd-Queue-Id: 4JZj9P0mxRz4f40 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bunyatech.com.au header.s=default header.b=cnsf8V3D; dmarc=none; spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:4:1::6 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au X-Spamd-Result: default: False [0.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bunyatech.com.au]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.90)[0.905]; DKIM_TRACE(0.00)[bunyatech.com.au:+]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5490 Lines: 135 On 12/1/22 2:59 pm, Brian Scott wrote: > Hi, > > On 12/1/22 11:23 am, MJ wrote: >> >> >> On 11/01/2022 9:50 pm, Brian Scott wrote: >>> Hi List, >>> >>> Is there a known method to get the fan running on the rpi-poe+ board >>> under FreeBSD? >>> >> >> I would assume this depends on the board. You've not specified anything. > > Sorry, I should have been more explicit. The board is the 'official' > rpi-poe+ board from the raspberry pi foundation. I should have > underlined that. https://www.raspberrypi.com/products/poe-plus-hat/ > >>> It looks like it is controlled completely by the kernel in Linux >>> land. Adding the rpi-poe dtb overlay has no effect on FreeBSD so I'm >>> guessing there is no driver for it. >>> >>>  From what I've read, its controlled by something on the iic bus >>> used for HAT identification. Beyond that, information seems to get >>> very scarce. The Linux driver operates it by sending messages to the >>> firmware. This would be a lot more tricky than just sending commands >>> to an iic device from userland and beyond my hacking skills. >> >> If it is i2c rather than some n-channel FET, then you have a few >> options: >> 1. Look on the design specifications or data sheet for the address of >> the i2c. >> 2. Build an i2c scanner using an arduino. This will scan for the >> address on the bus. > > All of the official documentation seems to revolve around enabling the > device in the Linux kernel. I have found schematics for the power > handling side of the board but nothing for the fan side. > > I'm happy scanning the i2c bus from the Pi directly. The FreeBSD i2c > command has worked well in the past. Knowing the address of the device > doesn't tell me what it is since many i2c addresses are shared between > many different device types. > >> >> Once you have the address it's trivial to program i2c.There's lots of >> examples of how to do this out in the internet. >> >> MJ > > Thanks. As I said, knowing the address doesn't tell me what it is, > only how to address it. The only example of code that I've found for > this device is in the Linux kernel and uses an interface to the > firmware rather than directly through i2c. > > I'll follow your advice and do some bus probing to see what is there > since I believe it's possible to access the second i2c bus with the > right config.txt entries. Hi, Just following up my previous post. The PoE+ HAT seems to almost follow the rules for HATs have a storage device at address 51 on the normally hidden iic0 controller. The HAT specifications require the device to be at address 50 but I'm guessing that would make it incompatible with other devices on the same controller/bus. Using the i2c command to dump the contents of the device (note: it repeats after 256 bytes so presumably has an 8 bit address internally): # i2c -f /dev/iic0 -m tr -w 16 -d r -c 256 -a 51 gives: 52 2d 50 69 01 00 04 00 8a 00 00 00 01 00 00 00 2c 00 00 00 e9 50 f6 3f c3 47 81 a4 5c 40 7d 07 c5 d1 6f 7f 04 00 03 00 0c 08 52 61 73 70 62 65 72 72 79 20 50 69 50 6f 45 2b 20 48 41 54 c2 6c 02 00 01 00 20 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 6d 03 00 02 00 0f 00 00 00 72 70 69 2d 70 6f 65 2d 70 6c 75 73 00 be d8 04 00 03 00 03 00 00 00 00 45 c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 80 07 00 ff 30 41 50 52 38 32 f9 3f 0f 40 (apologies if this is rendered in a variable width font) Using the specification for the id of a HAT, this looks quite straight forward. There is a header and 4 'atom's of information. Significantly, the device doesn't claim any GPIO pins (nice), and the required dtoverlay is 'rpi-poe-plus'. The raspberry pi firmware port doesn't include the 'rpi-poe-plus' overlay but the upstream repository does. Tracking down the source files (rpi-poe-plus-overlay.dts and rpi-poe-overlay.dts), the FreeBSD dtc tool complains because they use a '#include' statement to include the non-plus version into the plus version's code. This is easily overcome by editing the file to actually include the other contents and now it compiles cleanly. I Haven't done a test run with this overlay yet. My earlier tests were using the non-plus version of the overlay from the firmware port. I don't expect it to make any difference from FreeBSD's perspective but it may trigger something in the video core firmware. The really interesting thing about this dump is the last 16 bytes. They are past the end of the defined contents for the HAT id structure. I presume they are from another part of the device and are used to control the fan speed as well as return some telemetry from the device (temperature, voltage in/out, power draw, actual fan speed, ... just guessing here). Unfortunately, the only example code that deals with this mystery device is inside the video core firmware and therefore unavailable. This I imagine, will also include the hack to check address 51 on the iic bus specifically for the PoE HAT. Apart from trying the new dtoverlay, I expect my next step will be to unplug the fan and wire it directly to power. It would probably run at full speed most of the time anyway. Cheers, Brian From nobody Fri Jan 14 14:20:45 2022 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 B6769195DCE0 for ; Fri, 14 Jan 2022 14:20:47 +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 4Jb3PB0kNJz3Lxk for ; Fri, 14 Jan 2022 14:20:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 B082115059 for ; Fri, 14 Jan 2022 14:20:45 +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 20EEKjdo050893 for ; Fri, 14 Jan 2022 14:20:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20EEKjD8050892 for freebsd-arm@FreeBSD.org; Fri, 14 Jan 2022 14:20:45 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 249937] armv7 with PIE/ASLR enabled: buildworld fail on jemalloc Date: Fri, 14 Jan 2022 14:20:45 +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: emaste@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: bug_status resolution 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642170046; 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=7hpT9XrzbKdjigdI+PFGOjbaaLLoS+GIuJzw/ArA05U=; b=x2gJe/rKxhTTHofJgz+bWM3QqrCb1EQ/bg5kMqvcHEZm1VaPVuRQ8MoalPCWZXV35TkQsK gIRvz7qlT4yHI1EZn4n+XfNTHbnTEQcBMRJviZdg+nR7z39eZ/r3pZCxq+l596otf0ED4v ZbV7dVECpAW+Sl4O8TiE2Tv3O5cwLLkAhL0PIWbM2G1rAXeY+n52U0Tm4iYgmRu/2Z1pNX 1MNqvsb0ImobBkPZoE1p+MTlh0VeMPf7qe6zpHrf+zsFhAjdNEAIET/lxdPNQaEY8CA/3x gXRXRde0UOzqizKnNyDkpxkIYvlonqu+i251JbIwnCzLtigLgszvMoNhn5OGyA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642170046; a=rsa-sha256; cv=none; b=OJgMfBtMhVk3k0by3ckHNVihXQfL6yGz8CBvvh3n5spibfJ0t0BfhanJpDhKPB6QVtBr6p 45y/Xp+4hg+OwnB65sRuuXZV15aDZBD33Mg1MSAisOav0uR72zNSubVrVQ+E35c3NQEkvV QnyoQiBPMkXdXwbE1xtMU5JBCQ9Gr2Cl+6FJ8Ruln7TaZbPBuLV4GEUpJHLt/a6j/soeFX CU3s2VKNhz/CmYYYQ8pTLSZEOUth9gN4M+xLH0K2MtTlMR/Yr20EczE0Am+znYq76TO06W 0i+3E7ySdAJm2Vrfeia/sLZybz5ri2rHf9JWSmdzzKBomXmuezD6hxaLsbJFog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 620 Lines: 17 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D249937 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #3 from Ed Maste --- I agree. As mw@ reported in the commit message the build still failed, but = due to an OOM condition and not related to jemalloc specifically. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jan 14 22:45:15 2022 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 302651945D52 for ; Fri, 14 Jan 2022 22:45:25 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JbGbR3zVHz4qk5 for ; Fri, 14 Jan 2022 22:45:23 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5C8565C015A for ; Fri, 14 Jan 2022 17:45:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 14 Jan 2022 17:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm1; bh=PJzhBUMumFRJJxPfCjDZTgHYznAfdGeYkh8fSIPYoMQ=; b=hbpx1z/G w9Xa/i8+kyryr8ZmQqT/fdKs3Ex7m9G2TRsFvpAHmkcXr4gVVyVjZBlmYG+4FNDZ nyUq6Kw0cBRQcEpAjqldb8CB2x+DW8nAcFql4R96qF+GpR8UXyNwBHGdD2J/Cwph FdMcxDd6Y9DuDp5zo8M2mWWh1as5x0WD8nPy1KtTzwR5VtP11AXYhavon3HG5bWc JrZoNxEnHGBKbgVPdqM2xat9eZ2Wo+6rxbFRhcwyCF8CJsi43qe5KDYA157Kxg9/ Kddee/NrpeWG0jjtK9pup46mWKgUAc9WyJ1/57rGBp+UJUoJnfL8Ylf1qta6fraI LTI6DV7m0S/6+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=PJzhBUMumFRJJxPfCjDZTgHYznAfd GeYkh8fSIPYoMQ=; b=DVO+6EjjCHZj1HPxTi8/MX5VYDgyzM6FTUXdJhmj4Tiuf MYKX1BD0WIv4gD5oaTxlurw+U5vIHo1I9BT9UcAVXauf3PQuBgSEz976Xv/wqt6F 8EYM8mQLO6yGOwKkExHMob0i77hLaN/L6nVIPsk5sZ5MYarUBGGU9mssbCVp+O/f 2yLFEIETld6XSFPHQoz9XNBhz60PnZMZyq+qQx5q9LIk4A7spbduDrXybAxZ4rlU +zFpfG+AORDt/Sj0lt1E3Ax9Tbzp/VgAtS7woMHQk0I/6aGYBhVMDRTtjlJYha9V J8eoXNhy0DaLdJvSQC4n0ogaeh46csi8YsQRk47Wg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdeigddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd dvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiihgihs thdrnhgvtheqnecuggftrfgrthhtvghrnhepvefghffftdefkeelleehtdejledvhfdvge eijeevfffguddvhfetgeejueejueeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 14 Jan 2022 17:45:16 -0500 (EST) Date: Fri, 14 Jan 2022 22:45:15 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: freebsd-update and arm64.aarch64 (rpi4) Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N172hAAMhluzKMvF" Content-Disposition: inline X-Rspamd-Queue-Id: 4JbGbR3zVHz4qk5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b="hbpx1z/G"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=DVO+6Ejj; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.28 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1241 Lines: 37 --N172hAAMhluzKMvF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Now that aarch64 is tier1, is freebsd-update expected to work (following 13-RELENG)? I've not seen anything yet confirming this. thanks, --=20 J. --N172hAAMhluzKMvF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHh/PAACgkQs8o7QhFz NAVkvA/7BhtC+MBI9s5iAIDmnRpB/2/9gsRGc02Gy8fUd8ecPBaT5UcuPQ2mzjZi +r2xOBUyDXzlGwRP3wmgUDExA8/nuWMvLsIk90M1a65TRHPF52EtXF8EbYnAsWmw Owpdl+ayEuH3P4oL8iJ7HjyenHDKuF3WgrlinJ4Q5Q2Dik4Ve/O2hCxIsJqt+7Vr WvCxlgV0fJztvo+1u5yu3s2S+tmAMJhqj5fUEkfaKs0fF4diyolDyYuBRZo1uTiX Xhvj5jf+k/w78Tfk4lZHqkx6cLxikHSZzTTD7AayPl9V9HFW8NUq5pP6Q/TlazgH KGK8KjqAEmLcQKEsc/cLIsL4urdfDMr6DG3wY23txIck7X7M665GNaRcSyufTlwQ BLqxE4MD4MwzOCHS8fuyP9KV1R/8mX7p0p+GfzcJ8IK/CmdWVcN3cppTJltpXYsp hwNIQO7g6UZawIxSjd8akii2yAX7wkUJ1RCkElsJ1vevJJxsVTI9XCfHtWJn7UUm 6Wrfbt/MtoDBXxmnvQnNs/w+CD3/TaVQbE1RZErWcLjdxdMQ7FS/mKZxZqOPSh4B nc23S0kVc2IlxVj6Flwuoj2XUCdQY5RlIqOsZWikcFnfxzLy1IMhN3E/by7GZkx+ fp9qIzZA3jursq9NFllC09LwprlXyP3/AkM4f3AxdMvjDjn5hLE= =lit0 -----END PGP SIGNATURE----- --N172hAAMhluzKMvF-- From nobody Sat Jan 15 01:21:03 2022 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 33F9A19654FA for ; Sat, 15 Jan 2022 01:21:14 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JbL3F18mKz3Ff8 for ; Sat, 15 Jan 2022 01:21:13 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 5FC453201E78 for ; Fri, 14 Jan 2022 20:21:06 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 14 Jan 2022 20:21:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=+5XgMBR70CHZC2XqRIlSpm10tI9 mBJEaL6zylAAz6dc=; b=Sj42B2xk3v+2FSFxhNVgYqwrhl7R9IjU6KMccjXGG9d FxHFDhFkQqds84H/Fjbye4FULcyrpyxFhICLKfMWq8WnTzeuSWrdKo2nOr+mpUWU xXR0jZmTheShl/r86LHJiENvdFeVCPLZOEtd4wUfx0Z5sDzoMfpSB7Dk1zDgIPwO sMEXTBSg34bSH5XmWmbSX5qPCvVuKa3mUU6lVjuQsq/kMrK1RJ0gOraVzkz7Y7fL VwZd7g73hO2E4DqhB0TfbuNurMH4F4uPZLP+XDXKJhTzeM6xVvA+pFEzh90tzDVJ f9etXPAc2B4Fwv6hQCm36uxJS0WjYR67xBehXIL0GAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+5XgMB R70CHZC2XqRIlSpm10tI9mBJEaL6zylAAz6dc=; b=KdPGyNJ1ZxEXUFh0cokzKF kr1dY91eC+PvgUXFmxCqm+eoDF4eXnn5Hwuw/siuYv4xBGuhmKAL4li5AUwx0tVQ CYcw8RKFvjouaJjact+eEUvwW8OLnWByyWLjKB3fUQ3U4/yxnJjRdO8G0EwtNNfL 7QJgU+2QQWYgbH3CECnHU+e6AYYcRKUgt6ynL009ibn9VloZ6BbDzCHeTAshyAgV 3H92gOE0koxU+pXSe8Pu07Se9QbceZfNBrSt4QTj7ijVV21S3JpLdCcQU1O1Nqom WPtNr8pDtIuaDc+emS7G0lQwKsFFkSAMpYYzQHtkd/3j/V/HsExlaTN4lXDcj+Ow == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdeigdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 14 Jan 2022 20:21:05 -0500 (EST) Date: Sat, 15 Jan 2022 01:21:03 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: SSH login failing on stable/13 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <20220110193917.GA74116@www.zefox.net> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="19hOJj7PBT1fFT3W" Content-Disposition: inline In-Reply-To: <20220110193917.GA74116@www.zefox.net> X-Rspamd-Queue-Id: 4JbL3F18mKz3Ff8 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=Sj42B2xk; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=KdPGyNJ1; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.21:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1723 Lines: 49 --19hOJj7PBT1fFT3W Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jan 10, 2022 at 11:39:17AM -0800, bob prohaska wrote: >A Pi3 running stable/13 updated yesterday has stopped accepting ssh=20 >logins. >The "connection closed" took a couple of minutes to appear. >Other ssh connections to older versions of FreeBSD seem to >work normally. I looked at bugzilla, nothing recent about >ssh. If you're still baffled, you might want to see whether this sysctl: security.bsd.unprivileged_proc_debug is set to 0 or 1. I had a similar issue (on rpi4), but on -current,=20 and it affected sftp but *not* ssh. I have found that if this sysctl is set to 0, it stops sftp from working. --=20 J. --19hOJj7PBT1fFT3W Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHiIXMACgkQs8o7QhFz NAWPfw//a43i1FmNnD/nordv1x0xcHpW0L55Aq3/DR5Six9EYNTLirv+a5Xq6A6g QKLqDoDa5TurCxGcgBLwsaPNLAW4TPNfVaCy3J9/lGThLHfaAtlyYtAhJYmIH9sp UH3okoV+JrXs2n9sd5vqtJr/bC4QWtumcOdrbiy97eZHluIE6jx1CxKALn0j41ap 6TzTpADGfcQzwI3XvgOuCG8PjxMbvQzZLMUinHg6ePGm5mKlWvp6+bcX1IQ+AXFX 380yBIsX/eZ/6f33s4h8vgHxJH04REOhGwInX6EYB8AznxP5WEX1BMJrX6SgUeca OiF9JCPkb4XYuDR7gDXq+UXCuGkfksrR0FQxFC8p6oM6K25+5j2dFo2ohHTP2Lvw ZmvEQL1DDz5InEwu4hgbME7jewwmf/Di4+V8Oaf8nou4j6t9t6WnbI5G7f/OyJl0 GsPl29BcnNetnf9rxcR3BQ4EOzBrPcDm0fpw1yxxxnDbiQpyenTPmVqdsrc19VRA cWsg+IxobmG86e67JCpLvdBwb+nS1ki5sEASyoFyFUXQtmLfw9dH5JWO+pCSMWvH frHk7celL+OqGGebphU5v9McHjioPzxSxwvTOjit9QDtCs9GJB8Ox0yfbrYaRFk9 AQtMkrRpAvL92/h0dTvmB4puT0GfUvs+eOS0lVN40XisZb4zHZ0= =n0a3 -----END PGP SIGNATURE----- --19hOJj7PBT1fFT3W-- From nobody Sat Jan 15 06:31:10 2022 X-Original-To: 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 9665D19463E8 for ; Sat, 15 Jan 2022 06:31:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbSx675Tyz4tkj for ; Sat, 15 Jan 2022 06:31:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642228275; bh=Rep5VCH6BpdVDDBiaoqK3LNZX/gMhGvirI2CfwSopR8=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=lwVUFsaLAzCEMGYxR1noz3rQssDMgsRwsDgac9/H4COE+/mNZ5A5rNCPDhFMXMWxmJN2tMJq3y59T7exsKuYa0sGlme4PhxSIzQcxUSN06f2PPjedYORq3pboPwxO9vE86TkoSowhrs9OP7DAWQdPXuEGloqNolowblSrJ0VmY19AwqHO8bbsE8c//3bSXAtHtB0a3Z3b3GMFUmk99Ju1d3K8QN9pUvZqjvbc3Gs6RnG6jQduWJLY92AOIhD9BrWZh3TvuO89lSFtPspHkEEvu/vpOKb1p4pgjSB6Sfv7PFIdNNKUCg/Yd5Ka2AyIPsS7phSJ/MxeVV45y3kyFe+4A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642228275; bh=u1xDP+EcIpDGrEnHYTp+TlscGtV0cwVfe0CzO4t4qzR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HfvsniFjG/Sf/taxhYSMsZ0MRtutADGTjzaZffmsgZvP0hhrCFfrxuJ+xYs0Vn09IHEj11AK4GVO13avF8KfN8lx1gaMMa86lKeOyVLAbnJDuq1O67BQgcAE0+5rFOlw1mjji9cFkENFfCTNNgs0b76jtNtSi7K4fLYVyRHGFkxXjSYmbpOrohFO7Od/kPM4vaRo0CG8Flf2ViwdaWU/uPH3hkRAtHVVmktTDpPG2TZLnNgKznDg4nZBmAP+JQOk+Pk7BiClTLyzMzE7NEmD1t2ZOmpLF4EbayyWy+Cm0VAwHVR6mXjV3k51cvWXUglGcvS/dICpwIFwOx0zGaqvnQ== X-YMail-OSG: RM6UEaEVM1nLhEb09xH3ldVmICq6PNAxjdXSv34HGqPyTpNCHghFzRobshgWjdc cvZfsQdZSUoy2aHQ866M2d2GvSG4FQu9ec332R4vqaVoIhcNt6Q77PbqV2WVTztgiiyLIfFLlv22 xsJSyMlDjwnp.c5FNP2w7LwCRrfLdDJTAvctMWgbmJps9VVwIcwBETIsUBKjgPJLY_GMCxUO1dhe Fy4WkSTrwzAWiL00QXY9wYrabIwO5rf17ipmTT9AM9Yzby03zRQkNlRe1iAcFKwuQlOI11e0s2Zx ul6fWLNtILECMwZQZHBU_CUVn3zkjMB2Lp0ilQWU6.W52NTypY6V9XZ5bvyytauNzG7P_KwzepoN 9.A3ZHqu6rh7hg9coTP5Gfq78NbMvV0iB587KafJzleFWa23mqTNYl2lYeUH.isrohtHh6qxyN5Q F.rFTfnr3odrtwH9DLx7R_92ckqgyIacFHxB_RU.NNrscLrbivlNdu4wYmbGrR2ow76I_qg4Va_2 ua53mznAu8gCWOSzDilHdeEji_IBkeikpta9TH0tZiS29I.Xnfl5yw_pPzBTuPnQz4jNebohXT9R VPyndQAJJwTQR2txoxzav6YigzzYVSSIN2Pb87v0H1U2nxADkTh949jS1AxlkiDp9sBL5UfXnlFu 6VJtxnY1mx6CqNTzNXIM2Sw3s57ze2FmHlt.MTA9s2F4a8ijRYnqUOFUx.dJFYWktTSwSaW0qIes Gf1NhpZxm2M6XD_qvNCsNnmQyGhyAE5mX_b.QIQ.pQ3BDunEPh_HzLQ6kKY9gIBFquHIYwAn.e9y y1J9e8ixCtZWYKV7roe.wPBCzvgV0aYC6Ok5E9bOlTkPs_ZpK3gXuL4LrkOe_LnKlVOneOvj2CgJ slscrbl.rLuj5FZ21ulLkzld0TKKMR1PEEv8Ryiic1kLR5NVN_zCHW7TnG7TxyIXdki.vLO1j1zu XcJmi1ZSrMyVqBP4I5muuBYqWUx7OnTj5_IuWKb6z8yxOK7FEbGCtUxQtlSGHPEAm.OrlKly94QB w9zKdC.DpcWxx.tIkZ4P_RoMtjM5lt55IECmm.HZVyH6SJhL6KqsywHXaBG1m20qff8S8phYfqXh 02k9nGlzDoYa7Yyl2qSR9OyiNBU1oGg1zBy4rj_Do0Poli07s4Alwqo13Yb2eQku6CFWG7TDHPv. 26TzRtGBjtOwkvOiLQ6BhEFy9bUnFJ0mJaBBCu.vs1lDTHD7XT5Jj9Uqj2rjThHABR9RC6EZ4cJc QBx9eQ_w.Cq4qygG76kxNBtIdj31MM0uR7YM8ilNamh5Wilo5VlN5bDqOkNDnlMnSZ7yChVn28ZL 1jBzUAvfxEswlMojk58YFf40Btr7f949TH9dvpyiAMTisTpcy_yUDFxUnziIXWxV72RH3eLJiNqX 3G8x29Pg3GO8Ep8Mb8eBrF.DKzqpPLAZ3qu8_01xQsybGdl3GJdy6OQoHubjKIhCaTBCBCC8VzLc LFjlKs4GaZdkHEEOml78Avujbf.j5UI.tXdonrQ7P0IAkWGecFmsMxEKMN4qHO6hmQyuoiRokORj f93p5k7Lucr0WfKRnfX9_kZqFb7j955QY1YowpbaYtH1s.9oJFK0NLjjP7dPdBKfDjCjoPism_JO P5WIZlAcT8bJxzR0vs4OsQudYcJQNxRwfipZW68Z_Dv2Zp3AxLUx3QJlfxPHJs1Kbtat3iEMKI6A U3waOYFfA_NJXAU1xSeIbsgI48JwEnMpNa8W9Yga69YT51xnvsAxCQBLlsvIVhG7qGTPrcGWDr6Q C9re4ZYDUdpRvGT4CmncwU21A6Dp9Ag3pStUVvVF0lLyhkBBC9wci4me3qsuBL.qu2X50gD8D3MW nJgUmrTapdGTDsxU1v6o5Ox02PzUi6PjFd.llZvjxxbYfwOcXTg.xOK0ZMyRMmXCYtIGYM1DRS_Y 1nVGaamaKqlC6RSLH7WymXGZXVVJME60G6cO9Dt9qUH3KA74dxdaCLmIE7i6Te2X39LgcVlMfhsF 4jqJ6SZ9H6u5Zt.JuGfpKxPPjxiScq0fq8SdntA5EO9LZjhKurdwAqRkt5v0x4K2BB26efqNijo3 nzULyIuC8dmgIu5_9zTDakY0rHTSyEOuYcOBMcmH79YQvrXzXhIMKJEQq8cWYliweG_3HKwd2xbM Scit8SQB5.r5dBXLgn9xO9Os0UqhaZwyj6PR5Fx9WsqFSZuEQ9xqQc_EFFSvAar4bhyuNc3as.dP DSFa2h361VeO5O1ojrZsmP8aNpGx5JYYqaekIxL.KXU5E19af9KGlsmtMOh4r9lFWO0YNjH7W6ax POaXcbViOxw227jy7Yv_p9O4PzIqvlB_D12Qt3d51BCub6Dqg9qYLSKYJhbLGiiehsgpP_E8WO9. N X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 06:31:15 +0000 Received: by kubenode521.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1d966bfccee5629f1409864530f53840; Sat, 15 Jan 2022 06:31:11 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: freebsd-update and arm64.aarch64 (rpi4) Message-Id: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E@yahoo.com> Date: Fri, 14 Jan 2022 22:31:10 -0800 Cc: Ed Maste To: tech-lists , "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E.ref@yahoo.com> X-Rspamd-Queue-Id: 4JbSx675Tyz4tkj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lwVUFsaL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; MLMMJ_DEST(0.00)[arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3463 Lines: 102 tech-lists wrote on Date: Fri, 14 Jan 2022 22:45:15 +0000 : > Hi, >=20 > Now that aarch64 is tier1, is freebsd-update expected > to work (following 13-RELENG)? I've not seen anything > yet confirming this. Looks documented to me. But one has to find and follow the definitions/reference-material. There are places that reference having "binary security and errata updates to FreeBSD" or such wording that do not mention the tool(s) used for such. But . . . https://docs.freebsd.org/en/books/handbook/cutting-edge/ has a "24.2 FreeBSD Update" section that reports: QUOTE Applying security patches in a timely manner and upgrading to a newer release of an operating system are important aspects of ongoing system administration. FreeBSD includes a utility called freebsd-update which can be used to perform both these tasks. This utility supports binary security and errata updates to FreeBSD, without the need to manually compile and install the patch or a new kernel. Binary updates are available for all architectures and releases currently supported by the security team. The list of supported releases and their estimated end-of-life dates are listed at https://www.FreeBSD.org/security/ . This utility also supports operating system upgrades to minor point releases as well as upgrades to another release branch. END QUOTE (Admittedly, https://www.freebsd.org/releases/13.0R/installation/ makes no mention of arm64/aarch64 but mentions only i386 and amd64. But there is material elsewhere that indicates arm64/aarch64 has such as of 13.0-RELEASE+, given its Tier 1 status for 13.0-RELEASE+, see later below.) So with that as context, there is . . . https://docs.freebsd.org/en/articles/committers-guide/#archs section 21.3. Tier 1: Fully-=3DSupported Archtectures that says, in part: QUOTE The FreeBSD Project provides the following guarantees to consumers of Tier 1 platforms: . . . =E2=80=A2 Binary updates and source patches for Security = Advisories and Errata Notices will be provided for supported releases. . . . =E2=80=A2 Binary updates and source patches for cross-platform = Security Advisories will typically be provided at the time of the announcement. . . . =E2=80=A2 Official binary packages for third party software will = be provided by the ports team. For embedded architectures, these packages may be cross-built from a different architecture. . . . =E2=80=A2 Tier 1 platforms should be self-hosting either via the = in-tree toolchain or an external toolchain. If an external toolchain is = required, official binary packages for an external toolchain will be provided. . . . END QUOTE (There are limitations for embedded/SmallBoard/Computer issues like U-Boot or the like that are involved but are not part of FreeBSD itself.) https://www.freebsd.org/platforms/ lists "64-bit ARMv8 aarch64" under "13.x Support Tier" as "Tier 1". So, under section 21.3. Tier 1's material, the binary updates are supposed to be available (and are in the usual way going forward). There was also the material in Ed Maste's announcement: = https://lists.freebsd.org/pipermail/freebsd-announce/2021-April/002030.htm= l One thing that I've not seen explicit material for, that was referenced in Ed's announcement, is: QUOTE We will also be suggesting one or more low-cost reference platforms for FreeBSD/arm64. END QUOTE I've no clue where to find such suggestions. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 15 07:18:06 2022 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 011C01964EFD for ; Sat, 15 Jan 2022 07:18:10 +0000 (UTC) (envelope-from SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JbTz51KWYz3hv4 for ; Sat, 15 Jan 2022 07:18:09 +0000 (UTC) (envelope-from SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl) Date: Sat, 15 Jan 2022 08:18:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1642231087; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=bLvAv+LRNUKLbJRJ0baaV+PxuEreM51zPsMq0EL3+LM=; b=ZVpwkJ1dHqexktXI0LLhtiqKvlUtjv78vmlF0U1P7t6nhuas5BL3jY2Gc5g6U+goJfOYjl Dz8XXj4nb//06pg3XVH0lxM2FgJ+45xsjX439D0WMwW0D2ADyJ3IVa1OzRVnaWJbh0MzXa 2L4DAk4FTf5AB3qIIkC1RsEicRmRxUcBgOgFpDLAfDeyzWGj330PuCCGGACVII4fnmogD0 zEXdP0Ylwj8BGjhBox3CPJQmBXMl0LnJdiSdgl9dvJ3xOGshhy+69HZjJlFi5tXfSefCCo +dvNb3VSViu5s0qPYEBjFqGoM+W7AryAkKm4ERsXyhQlstZgv01h/ABi2UygJg== From: Ronald Klop To: tech-lists , freebsd-arm@freebsd.org Message-ID: <1454203050.2487.1642231086632@localhost> In-Reply-To: Subject: Re: freebsd-update and arm64.aarch64 (rpi4) 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="----=_Part_2486_352394976.1642231086628" X-Mailer: Realworks (590.253.ec54157) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JbTz51KWYz3hv4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ZVpwkJ1d; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-0.81)[-0.813]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1763 Lines: 54 ------=_Part_2486_352394976.1642231086628 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yes. I use it. Van: tech-lists Datum: 14 januari 2022 23:50 Aan: freebsd-arm@freebsd.org Onderwerp: freebsd-update and arm64.aarch64 (rpi4) > > > > Hi, > > Now that aarch64 is tier1, is freebsd-update expected > to work (following 13-RELENG)? I've not seen anything > yet confirming this. > > thanks, > -- > J. > > > > > > > ------=_Part_2486_352394976.1642231086628 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Yes. I use it. 

Van: tech-lists <tech-lists@zyxst.net>
Datum: 14 januari 2022 23:50
Aan: freebsd-arm@freebsd.org
Onderwerp: freebsd-update and arm64.aarch64 (rpi4)

Hi,

Now that aarch64 is tier1, is freebsd-update expected
to work (following 13-RELENG)? I've not seen anything
yet confirming this.

thanks,
-- 
J.



------=_Part_2486_352394976.1642231086628-- From nobody Sat Jan 15 07:31:18 2022 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 E501E19441E2 for ; Sat, 15 Jan 2022 07:31:21 +0000 (UTC) (envelope-from SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JbVGJ4GhDz3mPJ for ; Sat, 15 Jan 2022 07:31:20 +0000 (UTC) (envelope-from SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl) Date: Sat, 15 Jan 2022 08:31:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1642231878; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=UpWxjSlJ9piFmOj9v9rXBuWCIzsURTREMZ71qXRz+Dc=; b=hs476emJ5BPoZIRm+EI5DNAkf6iYmY/ptYyIxeBdiLDhGuf9yZia/kh1vDTzWdzVlxlDSl yVpFhrhhm5Ou24jkpAAP6ykVBsKyqsqrWUyRi5+XTQ/pTxrzY8MlLVzi3PgJgTsce89ZzT emKb3mqpDMA90rDpyiF9dGqs9jiaw/+YYRLdWQwF6HkqdE8SvpOcXhGfiUAyQJzUUhm7q1 ATq1+yDNvIrioIVqOPoRfgyzA2aIOfXJA1MrBXplmGda/8T266vwDf8M2To+XvMWTd0n6Q W7hOtbRoSXAMxfVLvuzP4FYwcYUBL7yQGmdcyL8HgIIYdmpK2Wf3kg4yfZ1jug== From: Ronald Klop To: tech-lists , freebsd-arm@freebsd.org Message-ID: <1726339166.2813.1642231878969@localhost> In-Reply-To: <1454203050.2487.1642231086632@localhost> Subject: Re: freebsd-update and arm64.aarch64 (rpi4) 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="----=_Part_2812_1458802041.1642231878964" X-Mailer: Realworks (590.253.ec54157) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JbVGJ4GhDz3mPJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=hs476emJ; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-0.87)[-0.869]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=NeFn=R7=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3585 Lines: 107 ------=_Part_2812_1458802041.1642231878964 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the command I have in cron on my rpi3b+. @daily freebsd-update cron && freebsd-update updatesready > /dev/null && freebsd-update install This is silent if nothing happens and generates an email if updates are installed. Only a manual reboot needed, but I first read the announcements before doing that. Works pretty fine since 13.0. Regards, Ronald Van: Ronald Klop Datum: 15 januari 2022 08:18 Aan: tech-lists , freebsd-arm@freebsd.org Onderwerp: Re: freebsd-update and arm64.aarch64 (rpi4) > > > > Yes. I use it. > > > Van: tech-lists > Datum: 14 januari 2022 23:50 > Aan: freebsd-arm@freebsd.org > Onderwerp: freebsd-update and arm64.aarch64 (rpi4) > >> >> Hi, >> >> Now that aarch64 is tier1, is freebsd-update expected >> to work (following 13-RELENG)? I've not seen anything >> yet confirming this. >> >> thanks, >> -- >> J. >> >> >> >> >> > > > > > > ------=_Part_2812_1458802041.1642231878964 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
This is the command I have in cron on my rpi3= b+.

@daily freebsd-update cron && freebsd-upd= ate updatesready > /dev/null && freebsd-update install

This is silent if nothing happens and generates an email if upd= ates are installed. Only a manual reboot needed, but I first read the annou= ncements before doing that.

Works pretty fine si= nce 13.0.

Regards,
Ronald

Van: Ronald Klop <ronald-lists@klop.ws>= ;
Datum: 15 januari 2022 08:18
Aan: tech-lists <tech-lists@zyxst.net>, freebsd-arm@freebsd.org
= Onderwerp: Re: freebsd-update and arm64.aarch64 (rpi4)

Yes. I use it. 

Va= n: tech-lists <tech-lists@zyxst.net>
Datum: 14 januari 2022 23:50
Aan: freebsd-arm@freebsd.= org
Onderwerp: freebsd-update and arm64.aarch64 (rpi4= )

Hi,

Now that aarch64 is tier1, is freebsd-update expected
to work (following 13-RELENG)? I've not seen anything
yet confirming this.

thanks,
-- 
J.






------=_Part_2812_1458802041.1642231878964-- From nobody Sat Jan 15 10:01:09 2022 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 B1346195FC75 for ; Sat, 15 Jan 2022 10:01:19 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JbYbL657Jz3G11 for ; Sat, 15 Jan 2022 10:01:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 082235C009C for ; Sat, 15 Jan 2022 05:01:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 15 Jan 2022 05:01:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=hfD77gbQrumSVTqHQU79H4dpOIK XyvODqTxTMj6HFC4=; b=spYaz2a9klQwSnOL+yn8LJIibFKVudBxltzw/oHsmn4 jGC0OZgZuLxh7WsoUXi63hYp4sI8CG3S7VMhpALyOuqlcj/DuzuHJF1vsXiYsJN/ fBIsyF5y0Hj5gqymiY9iSlN2WbDm3Yznh4tRPu63Y0m3Tu7LeBawVPANrNIkAAjB o6efalOly5/730wHhq2RpisjiuL0FSgWJ0jEb2V4xieu/zhwmpGq7BlbnzFwq+7P JaOeKPh3Bnu8YeaYb6BZKBcXcHW4fPLE4LZgMwZ9j1oUXhnimg5NlIhHZJzO40Mv VxSTlfm7l+kIaSON5X9f4P3Iy8Wa8GbMmX5v5foIkaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hfD77g bQrumSVTqHQU79H4dpOIKXyvODqTxTMj6HFC4=; b=j7dXCs/I72ucq3EyowyaS7 rLc8eXLpaCn2eX3VXjzhUEAKQK9GMsJ/CEMvFLaJVKtMk+Uip8rQx9349FY2UVK3 bDbxCPjrdURAiTmrKP64qXQ6RXe83lOifrcdV7XPIBsarxzkuO3xFFy+32XfBUIv qX+DQH4nFPbbgKBZvRUNi8mkCaIA3ca2vOzkEFVipxCiKn/TLyiBeFIaiBIC9jiR wkQByfXDuSFPYrjtkdm861ot+hXyLHRSoge++YkNXmUKu8uQUcmUWKOBnhVSnB5F oAdLko+N7SphsGcxkdvdUo88to87N3dFTTH8e4MPGiYQZDQC+bjXM9e3ulTMRRuw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdejgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptedttdduuefggeeghfekkeetkeejle efffelheejfffgffdtfeeftdejgeeuieffnecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepth gvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 15 Jan 2022 05:01:11 -0500 (EST) Date: Sat, 15 Jan 2022 10:01:09 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: freebsd-update and arm64.aarch64 (rpi4) Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E.ref@yahoo.com> <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="noSp3CwYr0m/AFB/" Content-Disposition: inline In-Reply-To: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E@yahoo.com> X-Rspamd-Queue-Id: 4JbYbL657Jz3G11 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=spYaz2a9; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="j7dXCs/I"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2347 Lines: 68 --noSp3CwYr0m/AFB/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 14, 2022 at 10:31:10PM -0800, Mark Millard wrote: >Looks documented to me. But one has to find and follow >the definitions/reference-material. > >There are places that reference having "binary security >and errata updates to FreeBSD" or such wording that do >not mention the tool(s) used for such. But . . . [snip] >(Admittedly, https://www.freebsd.org/releases/13.0R/installation/ >makes no mention of arm64/aarch64 but mentions only i386 and >amd64. But there is material elsewhere that indicates arm64/aarch64 >has such as of 13.0-RELEASE+, given its Tier 1 status for >13.0-RELEASE+, see later below.) This illustrates the point I'm trying to make. It can be inferred =66rom the overall tier1 status, but given the sheer number of boards on this arch it would be best I think if, rather than an inference, the supported boards (for freebsd-update) were listed explicitly, in order to provide clarity. This should be obvious and easy to find. [snip] >One thing that I've not seen explicit material for, that was >referenced in Ed's announcement, is: > >QUOTE >We will also be suggesting one or more low-cost reference >platforms for FreeBSD/arm64. >END QUOTE > >I've no clue where to find such suggestions. neither do I! --=20 J. --noSp3CwYr0m/AFB/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHim1kACgkQs8o7QhFz NAWraQ/9ET6GeXW3yYMtJWaG85TLxJmxcTbabIa2O6su4rgLxYsIFxFGsfklSIFC 0OfYPWRXPZkBcziC6MyfwZCYaxajR3G9rI/OOsEDVne/AEs4kP3nO7tI00Pyyeqg 43EJvrqCxKN/pCmmoUEFEmMnGPfCYMRJ/bezXwrQhE3I/46q1RgQW38f4z5poVAE ShB0+jUMwefPTAC6pQPMfKvyypxy3uZGiQwatsI5Lgr/NPzvLSE2H4DAmH8Tccnj kiUqU3XekNe9juGewwL1OFEsqp0G2N8c827ZmaKfg++Rscb/jJPhd8PYECQm3ID7 7Z3JIHI+FCawMeDCtAIslguBajp5wKIWa6gjnYdfMK7YEpkPdTkX6GVd9blgkHc3 uEHEaeJMTmNL7O8NDdlQRkPIZDkpjDqP2l9wUi8F1o7jiPmgaU/aBKoj1QmWFG1O o59jBWNOyTvDsQvXnvUrPXLDjHfJvB6IRPJchvc7hVYdwL4Vh+aIeHeS1GhvmAwX ZuMsfV4OAXuHU5cWXUzCm84u9C/Jx9udN+3BxvJxAfvDS3F5wPDqqTAUyA1bAiJs NsmXkQlBaegtUIa+aeEtsMgtxu1xpLzXPACWiq4oqAUI4ErMdWvPaDU0wiEv9p3c gcTwt5+rg83hvciQyus0QPysE1gsvrL4loZ1lGJo4uwes8xKxEE= =o8RH -----END PGP SIGNATURE----- --noSp3CwYr0m/AFB/-- From nobody Sat Jan 15 10:02:27 2022 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 66C1419600AF for ; Sat, 15 Jan 2022 10:02:30 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbYcj4knKz3GHd for ; Sat, 15 Jan 2022 10:02:29 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8FDB75C00D1 for ; Sat, 15 Jan 2022 05:02:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 15 Jan 2022 05:02:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=cfuBYCsgmMeq39PV08+cz3IxyEL BM+zj9s2tno9xBm0=; b=RFOjBxWezn86pL42F3LmY38J9lWwNmT4d9qSkh6UBaM L3b6HggmkSk2KTHuCTag0tBQAsVMg4yvUyP2ik05Zs89iy3yJUxAWbNbkaXISPFZ w4+OqiYpCuSNeeoTyh50uCnQAnZ7J07+YgnVCkp3Xe6m7Or8NcMLS9MSVyvalUV9 fqYQkVr+Qx5/prJAFYuoMAvhoiLS3Gd7bIUVmA4OXJTZI+76yLYdFq3+0lXBPw4w D1DupPoH/W1wWPRQirMoWELyKID1akrujospopjc4vwlffNNMUGA5Ck1yizVdn3G 79fsmwXDDZOw6RfanOSahR8mlRFgK9p5O+bEkKRckSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cfuBYC sgmMeq39PV08+cz3IxyELBM+zj9s2tno9xBm0=; b=fVPoJobBHQxznrr3cL7zDC 2tPYGQriR4zFYiI+MxQcNGbmiepsmBcBWQbam0QeJq+RNjRt0VNgm+dz4dJba0C+ mM3ONCNOrZbkmbq1KamiPM5UPYHfq8ET7rYvBykzfSLN+yuNnVAKZZXjxsFQ95S2 XFyRwt3q2CR9qmNl1egtbpqXOvvKtug1TNQqMZ33FjWXLhQGNUqjAcX6MsKkA0Of TSh8/WzHSMD4N7OP8yoz8kQMpEMviGm1xZ1Mo/neNmc4L6G3Ucbaq28rOEZwKiGT iGcNzSBaDbDt4jjhV+iA2FaWJZd6q4LAV+Jad7aR9OxdKAgMX3TjKQTro3dzRC7A == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdejgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 15 Jan 2022 05:02:29 -0500 (EST) Date: Sat, 15 Jan 2022 10:02:27 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: freebsd-update and arm64.aarch64 (rpi4) Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <1454203050.2487.1642231086632@localhost> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cu4trEuPcroNW3k/" Content-Disposition: inline In-Reply-To: <1454203050.2487.1642231086632@localhost> X-Rspamd-Queue-Id: 4JbYcj4knKz3GHd X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=RFOjBxWe; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=fVPoJobB; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1201 Lines: 34 --Cu4trEuPcroNW3k/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 15, 2022 at 08:18:06AM +0100, Ronald Klop wrote: >Yes. I use it. Thank you for confirming --=20 J. --Cu4trEuPcroNW3k/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHim7MACgkQs8o7QhFz NAVX1Q//YDmDpaZz3YLU8mFwG7e51i0a5rCDXSnr7ADv+q3jVmPb4Mk3MRlkLVa2 mQmqjWZ30Y0PjAPxyN+5wNNP040kOj43LPBUl0/4YpsHp80Mi+mAA4LCuPu2IEy7 kdh21/dUopR5StYwzNGKM1ndR8WHsFdYFOOZ0sE3iVYoRCaFTKWSuX2vm21j2biO K5w9F1e+tglhR8NnfXdVH1MFkpy6L6fb3JDpw1+Ft5Kt/Oy5CloDP/v0lxzY44/J gwKnUP2f9UckDDY26KToMPr6UJeOFgNrz8s56RNTP2gRg65yArBW1KSx8km3Db/H HMx6vza3361ZrR6N2Km45rZRZEVoxesp4xEqggKo6n2E+lLcddR6i4KVJ89MLrV+ wjGY/5ahHa90yqjhqATr+feYY1N1ogooXnhblSBJ67i6ybkmZUiJETxm4A2eIb8k OIEgju6LsRR22BZEJkKA8FBXDuUdk3g2kHl8QjqcYhd/P98XvNyvUcTKRhgclZ5i SG/xPk6grGWN7qE97pQO5Bo6weE+a5PLgbfEqNWvUoqh04qXI+093fPfTX+B7txK z6LRafYoi1zyN2gX9RSWuX2CPh1MCe2K8s3OLtLteuRn8jGTIzv9WY/SlaH4Wnvb JmlCbfSftNXagtt9fkbK1CaqMGTohSWRrIey6gCMNgWg4gsV22Q= =oriI -----END PGP SIGNATURE----- --Cu4trEuPcroNW3k/-- From nobody Sat Jan 15 12:16:08 2022 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 F02C11946145 for ; Sat, 15 Jan 2022 12:16:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbcbB6kSkz4qqG for ; Sat, 15 Jan 2022 12:16:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642248975; bh=VRph2MqMIExxGA2Wi+5Gggx7Ma62J0Jdn5/41ApPFR8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=thv33m4mcH07IeZUcAOh1xQ6HkAFz0q2jykXdKTz85QVAPkh1PnsehCqC4CpCDr9wQj99MF4Y2qfCZuXHCfIfPiJ7GQjXkkrRSwH9AHm5xaR7Dd3kJ4xx6AAv1YV9YHxyDefM6X6ezsws/5K/P7d7R2aZBb0h8EYcPZOmvsN0udLH23v4xeUfy+HvZtFrOYmlIVVc6t6uY+9xYYcmYDTq+oAreVl7KkA2exuA4TD5wT/KY/J91BlQN4atEgHqLSaBVIHQjB7khsqICsBoq3HbYt+V9MWNIM5So/KVwN5lIj9jaZGkdJHnKWeuzjU4cQrQd3SLopH7jruSpnO3IuAYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642248975; bh=0b23KlP22HYS1B9Cdzr0PEsARlu6ywXeJshle3vgKRT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ROAQn1cyCCPa3a38ZqhR7mZvNWvdS2HLIW4CAVDChgN1HpTd3X2Wg3yvMKPYDdizPZOBNJZ+GiBgJ2xOIy3ZBdsru2R7fo7G0BAGBN3GsWIrNV77GEBRdMLp4otBQtpd8qn8EKMJpvBz7i2hROm/ld/AdpmK22EEt7vA1NE4he+xxiJ4u8o6pZyx2qRHbNGVEqf8NzVctwCQ0lZJBds8uthnVMHqpJyMc9O3Qj2c0aDJ6I6qVfyXZBNQINNMvoNRGXBORr5QympKhomxJhkjp2CLSVR2PtoUKTMk/1DU0dWFS1+QuctzPG+boJszj5E8LIZlj37qcd12meXXl0zKSg== X-YMail-OSG: 7EjgKmoVM1mo1jEgdTTCR2iauk9xaSvhXVhqAo41_irvBLyABbK1GpEvPTSVkZE Ta0E0kgvmzLeycr2gCRN3.FZW1w10s037BirfBG8voGPU1iXRxW3vESt0NKwJt_9JUWso.OsFZTm U7RqKFidvFq3ulxHCXGJNdGW3cP2PFsY9EliwXhhCqNKgGT05xamppk4WuXEk0l7hs6r5uD392lY EdzgAmoPHlvLCF8cMFIXApuAmd9l0HSVZwFvHrD.3gkRENvuwihrgmI8AWxeYsWrfRDwbETM7FdO iHoMRBxQOufNK3sIyTYD9kja7DMPdIQjPahKRn2GeyV6S9IXcqf9gPFqq9i6aBoWbNImSn6s.wiv D8PpI9OCsx7GW.7kKTCXM8IXmaFXQBS4Z02HsYDX8Nyb6P4qEY7.xrUP1J.vrT2fhse_AKVEDqkb jMUT0t77MK2blWb2f9dZziAxQOyH3FP6Yg8u4Io5vhgt_obZGDg364rALlABqbL9p3fEoBmMefMF v0mQspJHmtxgLF6MEQpoKQRe54Ocg9xsiAWRHcjqJ4aPtezRFQw7Jkw5_.OsDlLsCyORsLiRocAb 3vX9TiLeq6IOZeO.2J9ssnM7cgo7ciZheg49t3ulInmAGYXIY7vBk.AWdPaHhlakniOwx0aUZbDI kLPfzHx7E7ZlR9SI0tNFfHKY4.xWuZ928WlMhKQ6192k6oMrbyoNO_aqbGfsdurnyXtENGoc9pj3 NgBmSHJ4QtU8pexX0H3.LiyoXsDleAwC_a_MJmgmRzOP79vA9QOAD7ZV7TQspId4JluAEwlL01TP xK3lEzuKUi42rqgE5fPKsJfCjicHfEurum3oaI9jA1p.jz26_jVltUV_f45ku8wcAL9bNfCNzFOQ gRXgX7gZZQjXjQT_dTYyK.Z5tj9Ki0bDPSyJv2._7iVFGCreSp7UO9T9r6CGyPtOJvk2iax0MGmO ousgSZJWUqzSTyb_SbcRQnuHnA02Fdg8gU5fg59MoxRW7q1XGvOeVLUQFeEUZpe3Fal.kKuIQrEh B_4Wi6jd.GFJVnGQ8XvlXpvKjRTpn5z10AMAXne1b7Gx2ldTDJaSVLXxM8zgFNtyLvginKvaMsg4 DmvQiBIPRxfzDHfH0m_Ia4Cv83AQR4UY12qXOgqGGC3TBZ_n0FoCdVifrZudM9jxDGfIu9KWd34J .bU0cqDEump9yzoo9aERSxbh43.2qKQEeJPluqcPe29BwKcWThZ2zLhTOnfJBuksjfFzy_c1vhMx u.1Lz3.wOi3.jcDh1Jq.Rf.xixHAHlqHexLA9ZrdcdK4L4JvPskk3C5UuWlAtjmVffo0bUl7xxAK tt7chRURnDXMPuNxTqiFQN8FFfTFDdWjSLj8QrTVA99.rqZDQVAG2MdGTcRnFXhfLNVrl0EvT8jz ju1Re2RwF8QCuRCwc3.hyuJqKUlOveLC3FW1vzxPywyshXSPaa_uHE0m9Iy5rvF9GsbLxE7UKdu1 BfjGP7971eBq_o.B5lywYQJZh5yXd.VyJJUIIc4n_Gwv4SEgXctj0y8CX4i4hBeKs0saa_zXzIVZ iuRN0sh4uwa654JFBhSZuDKy2kVybEP6sijUGLpZLRdrbEW6sItdG_P.1jmjGsacF5XbIKL7ujN3 YZTMlmvxkkpa1bFaQ1LgXy.2G3N5gaUjpaei1bsOe6SHG8IqmnE9Gl44HBrNDIt0m9O2p.q0Hqo4 svvgcIO11kT9yFoy9alWTYeRotNQzRF4s6S4eGurx.hzMmbuWtXgNYHIryxT9uTJk2YzSBKctD7H JLX47MZsXzdJzuxdIPTkGzNZ5euD_087jB.crjYr0e1Hb9BS48r3vDaQ6P6P3lRyWDO7fRKUPu04 Fu9SjylZFj9Z4h7YNM7QB1_fahWgULVekYX9rT6skPxXJVhZBgvxnKZGflNcrpxT_P9pc.vt_cNP Cb7XUkNUReLr9mgCoFwJIeTvlPIXyVbV7EjfnDV5bshkboe.o1i1WCEb1SrjiKaSBJs4RrPLsMU_ 6fDMyxAN2VkuMR_cyuWXRQMH1UXT2Pb_GVfXemG69_ZTFSzZbteIqTryvxNhzHtXC9n1kGL7lJ5q hunQ18CZPFZIE9aqQyFgjYoFcFwJSiJpqy0phUTYBhS8cfhJqpC2YQ8yPpZKsQ_OAVNrJfvDBEcv t5QdCtID5gvowyAdROdIQWJM4fR8L5htrD4vDaAzS6YzMLxgpycdK2AMjrQodqArT0gcRGNuR99r txHDYpSlDhbnBA6VS0jideaYH5zVGz0U5aHZ8SlXVRTH81caVAK77kHZo87w.UMg98MiCbBdhWkA azfreL_choJKypNBxNLpA.aYYbDZALPKYWzuMVzHt6YkC7u.lp0TU0SM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 12:16:15 +0000 Received: by kubenode506.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9f7b42cfe32c151c6592fde52ada3cb0; Sat, 15 Jan 2022 12:16: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 14.0 \(3654.120.0.1.13\)) Subject: Re: freebsd-update and arm64.aarch64 (rpi4) From: Mark Millard In-Reply-To: Date: Sat, 15 Jan 2022 04:16:08 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <27ED08A4-C263-4D33-B5C3-A5B6B1834C15@yahoo.com> References: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E.ref@yahoo.com> <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JbcbB6kSkz4qqG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=thv33m4m; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3355 Lines: 87 Hello. On 2022-Jan-15, at 02:01, tech-lists wrote: > On Fri, Jan 14, 2022 at 10:31:10PM -0800, Mark Millard wrote: > >> Looks documented to me. But one has to find and follow >> the definitions/reference-material. >> >> There are places that reference having "binary security >> and errata updates to FreeBSD" or such wording that do >> not mention the tool(s) used for such. But . . . > > [snip] > >> (Admittedly, https://www.freebsd.org/releases/13.0R/installation/ >> makes no mention of arm64/aarch64 but mentions only i386 and >> amd64. But there is material elsewhere that indicates arm64/aarch64 >> has such as of 13.0-RELEASE+, given its Tier 1 status for >> 13.0-RELEASE+, see later below.) > > This illustrates the point I'm trying to make. It can be inferred > from the overall tier1 status, but given the sheer number of boards > on this arch it would be best I think if, rather than an inference, > the supported boards (for freebsd-update) were listed explicitly, > in order to provide clarity. This should be obvious and easy to find. Given the "sheer number of boards" they will never be generally explicitly tested with freebsd-update over time and listed individually as the official ones that will have freebsd-update kept working "for sure". (Any more than there has been an explicit list for amd64 or i386.) I think part of the answer is probably something more like: Supported are boards with (working) UEFI/ACPI firmware, supporting what ACPI supports. (Over simplified, but I expect you get the idea.) (The RPi*'s with https://github.com/pftf/RPi4 materials not counting.) The boards that get explicit snapshots and release builds are probably only ones the beyond-UEFI/ACPI ones that might be explicitly listed as kept-working-with-freebsd-update, subject to changes in that what boards have such builds at any time. But even for those, U-Boot, RPi* firmware, etc. would likely not be updated by freebsd-update. (This is like freebsd-update not updating UEFI/ACPI firmware either.) It is also the case that some of those boards have no one claiming to be actively supporting the boards if/when things break for them. They keep working as they have been so long as special (significant) effort is not required to undo breakage. It is less obvious what would happen if a significant breakage taking significant effort happened. (In some respects, my response is driven by what I read into your request for what purposes it might serve --and sticking to that presumed context. I may well also have guessed wrong in various other respects and folks actually involved may well correct my guesses.) > [snip] > >> One thing that I've not seen explicit material for, that was >> referenced in Ed's announcement, is: >> >> QUOTE >> We will also be suggesting one or more low-cost reference >> platforms for FreeBSD/arm64. >> END QUOTE >> >> I've no clue where to find such suggestions. > > neither do I! I also expect that something like, say, a HoneyComb based system might count as "low-cost" here. (There is no general agreement on what "low-cost" identifies.) Small Board Computers are probably not what is being referenced by the terminology. Given the lack of an active supporter, no RPi*'s are likely to be listed even if some SBC's are referenced. === Mark Millard marklmi at yahoo.com From nobody Sun Jan 16 21:00:13 2022 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 8D1F119533AB for ; Sun, 16 Jan 2022 21:00:21 +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 4JcS9D6y3rz3nj6 for ; Sun, 16 Jan 2022 21:00:16 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 6CA6D21079 for ; Sun, 16 Jan 2022 21:00:13 +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 20GL0D2Q040411 for ; Sun, 16 Jan 2022 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20GL0DG5040410 for freebsd-arm@FreeBSD.org; Sun, 16 Jan 2022 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202201162100.20GL0DG5040410@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, 16 Jan 2022 21:00:13 +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="16423668134.feDB.39460" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642366817; 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=Ri87pWioNSG9c238Lcixhfw2BJI5WSOc/gjuD8eziHA=; b=TuEynp8lkh+oazdNMIpPAnXg+NvHDB6cGPHb2Pgior9dT6rbUnjCZfmaO11vXTw2dItxyA CwWlp4bdTuU+ksp4xxUNT8eOZS18j77NHe9T00QzpVhwtsB+wLqZlN/TSLBowN1ORSiTK/ H6TKJiNnMHwoJTteqJm0vTG++dxtEc6X87IGGn1pDRTYi4iMCV2V/kp6uR9RW7Tvis1suh AviaWiyAMt+5tV5uF7NRxUzrmekE6kKqK93xHXBwgaKFrX04BxVEM6cXC6W/OxoRCWEksk ui6cluqYL4rSkz0KTQ1i3heL2xGAgdzGCEn/qo7cdkJtRwFtP9ELIe53XCLnoQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642366818; a=rsa-sha256; cv=none; b=Nu/rPTuSuuN31Py5E0Pjx7cI40uekWXXC5HdVhu6hbzhAgXa6Ix3wtgke+z2K8DtC7m9Mm iuVib8Vgv0NTj3sfd/TYTBjAeLlf3geUI/Ue/06lmhKfhAtSIQOySxs9e3KnagpxHtqeJr u5I4048cF4/PtC65wxFcSQJHEwR6ed9Rk4nONpL+Wt0B+ETEPCPzC9ysk1hIL6pHWo9M37 loVcJurThnyV04/fij3kxfkJw56VTguoyDqi4MMM2f6v+8bBD4xVYPjgn9bURtKVUND5oO 3XxF0q9/5TWbnNhfusFX26BWknIm45XS4vwlde+tisYYA+oE9rZj2fw+IuPkHQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1795 Lines: 38 --16423668134.feDB.39460 Date: Sun, 16 Jan 2022 21:00:13 +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. --16423668134.feDB.39460 Date: Sun, 16 Jan 2022 21:00:13 +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.
--16423668134.feDB.39460-- From nobody Wed Jan 19 01:08:07 2022 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 0396F197029C for ; Wed, 19 Jan 2022 01:08:08 +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 4JdnZH5C9Hz3Fst for ; Wed, 19 Jan 2022 01:08:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 8ED643BA5 for ; Wed, 19 Jan 2022 01:08:07 +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 20J187R5090879 for ; Wed, 19 Jan 2022 01:08:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20J187p7090878 for freebsd-arm@FreeBSD.org; Wed, 19 Jan 2022 01:08:07 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 261324] xhci1 resets on ROCKPro64 when reading from ZFS pool Date: Wed, 19 Jan 2022 01:08:07 +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: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@toyingwithfate.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642554487; 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=anMgiXM7dWa9fmlM9TD+wifu23wDaXyGh/iH3GeZMRs=; b=Oun8jYfcfVxqNG/K1VrlP5lCaH7KxVw3yFLAkhBeSbP6jcp+bmm0864fk/BT/FvOaeL6E4 GpfWNZUqPsVfcUtS1Mu98NWpNdduC8261eOJ+cxz8v8Gk1dII0Y1i4JlhzGXw3o/SoBvwR ABctTFcchuTlQyOZKI4l9Fhj1IZ9o/BOdIAne1XCnWkvI/YigmRLy/C1VUCA31tpY+zssY QYL2p2eBOqWvERP/7oZHNwFQqG8u47qVdvo3wMKYC2zNlVIV4BnoDecHErKYp3rjgGPLp3 aFNElb4syB8iHinxm45tmLKK8UNjMdTo7FT2kcaF6s3EIRCLzhBTN6eChDdrbQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642554487; a=rsa-sha256; cv=none; b=skD0+Jb7e3wWxogUOZqzH8lgn5DvzNiU/y6TqL9GsM8+khXaQatFKpgZMljDtpV+ckEKLF HvF85ofZ4//L1hnp5jcwTgrdxtKLoGJZrMcxDgiQhoAQIWqj5xhE9yyIKSwSHTmg+rW9/7 Cplt5npnqHnZJUoaLYDyBLmKgCBCp65Q7nnmWbthh2+jAjvX2qP48yf+zLUV9PFq5wU8g1 caKojAfPXl/ioInZq34WnOi4o3AXw8t06CbQr2mJSEOi/CzuMzynQeVd7vFwQSG4/62SqE zHjlNeXYH5zyJFFv96mvTZM6J4cqF9sxdjIP7RgKeI27w7VdMIjBaLMPuUwQYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 15961 Lines: 370 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261324 Bug ID: 261324 Summary: xhci1 resets on ROCKPro64 when reading from ZFS pool Product: Base System Version: 13.0-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: freebsd@toyingwithfate.com I have a ROCKPro64 single board computer with 4GB of RAM that I am attempti= ng to use as a small NAS. The storage consists of an encrypted (OpenZFS native, not GELI) RAID-Z pool using three 8TB SATA spinning disks and one 512GB SATA SSD (used as cache) in a simple 4-disk JBOD USB enclosure (the "OWC Mercury Elite Pro Quad"). My understanding is that it contains a USB 3 hub with four SATA-to-USB bridges in it. The issue I run into is that after reading ~40GB of data from the ZFS filesystem, disk I/O stops and I get the following messages in dmesg: xhci1: Resetting controller uhub4: at usbus5, port 1, addr 1 (disconnected) ugen5.7: at usbus5 (disconnected) uhub7: at uhub4, port 1, addr 6 (disconnected) uhub7: detached ugen5.2: at usbus5 (disconnected) uhub6: at uhub4, port 2, addr 1 (disconnected) ugen5.3: at usbus5 (disconnected) (da0:umass-sim0:0:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5c f8 00 00 = 00 80 00 00=20 umass0: at uhub6, port 1, addr 2 (disconnected) (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5c f8 00 00 = 00 80 00 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5c f8 00 00 = 00 80 00 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: s/n 123456789004 detached (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5a 00 00 00 = 00 80 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 3 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5d 78 00 00 = 00 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 3 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 61 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 3 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5a 00 00 00 = 00 80 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 2 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5d 78 00 00 = 00 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 2 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 61 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 2 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5a 00 00 00 = 00 80 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 1 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5d 78 00 00 = 00 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 1 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 61 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 1 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5a 00 00 00 = 00 80 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 0 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5d 78 00 00 = 00 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 0 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 61 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 0 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5a 00 00 00 = 00 80 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Error 5, Retries exhausted (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5d 78 00 00 = 00 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Error 5, Retries exhausted (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 61 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Error 5, Retries exhausted (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5b 80 00 00 = 08 00 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 3 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5e f8 00 00 = 01 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 3 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 63 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 3 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5b 80 00 00 = 08 00 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 2 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5e f8 00 00 = 01 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 2 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 63 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 2 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5b 80 00 00 = 08 00 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 1 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5e f8 00 00 = 01 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 1 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 63 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 1 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5b 80 00 00 = 08 00 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command, 0 more tries remain (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5e f8 00 00 = 01 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Retrying command, 0 more tries remain (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 63 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Retrying command, 0 more tries remain (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5b 80 00 00 = 08 00 00 00=20 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Error 5, Retries exhausted Jan 1 05:47:13 generic ZFS[5395]: vdev probe failure, zpool=3Dzraid-v5 path=3D/dev/da1 Jan 1 05:47:13 generic ZFS[5399]: vdev probe failure, zpool=3Dzraid-v5 path=3D/dev/da1 (da2:umass-sim2:2:0:0): READ(16). CDB: 88 00 00 00 00 01 01 89 5e f8 00 00 = 01 80 00 00=20 (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (da2:umass-sim2:2:0:0): Error 5, Retries exhausted Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Solaris: WARNING: Pool 'zraid-v5' has encountered an uncorrectable I/O fail= ure and has been suspended. Jan 1 05:47:14 generic ZFS[5423]: vdev probe failure, zpool=3Dzraid-v5 path=3D/dev/da2 Jan 1 05:47:14 generic ZFS[5447]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5495]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5499]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5503]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5507]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5511]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5515]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5519]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5523]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5527]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5531]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5535]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5539]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5543]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5547]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5551]: catastrophic pool I/O failure, zpool=3Dzraid-v5 Jan 1 05:47:15 generic ZFS[5555]: catastrophic pool I/O failure, zpool=3Dzraid-v5 (da3:umass-sim3:3:0:0): WRITE(10). CDB: 2a 00 2d 5d 63 31 00 01 00 00=20 (da3:umass-sim3:3:0:0): CAM status: CCB request completed with an error (da3:umass-sim3:3:0:0): Error 5, Retries exhausted ...and so on, including further complaints from Solaris, ZFS, and CAM. The system is still operable, and I can SSH in, but the ZFS pool is unresponsiv= e. I can tell FreeBSD to shut down, and although it will start to do so (disconnecting me from SSH), it will not complete powering off: SSH connect= ions are refused and it still responds to pings. If I unplug the SBC's power, disconnect the enclosure's USB cable (since the ROCKPro64 won't boot with it connected, another issue I'll report separately), then boot the SBC and reconnect the USB, things will start working again. (The ZFS pool will sometimes complain about errors that I need to clear, but if I scrub the po= ol it confirms that no data was corrupted.) Interestingly, I seem to be able to scrub the pool fine: despite the pool having several TB of data, the issue hasn't appeared then. Additionally, I = can use dd to read from the individual block devices for many hours without iss= ue, and can even do so from all the disks simultaneously (averaging ~100MB/s per disk, so ~400MB/s total) without seeing the issue. But if I mount the ZFS filesystem (I do so read-only during my tests to try to reduce risk to the data) and start making a tarball of said filesystem (writing said tar strea= m to /dev/null), it gets about 40GB in and then the issue appears. The exact amo= unt of data it's able to read (as measured by piping the stream through pv) var= ies a bit: my last three tests have failed at 43.3, 40.6, and 54.2 GiB, respectively. The issue is 100% repeatable: although the amount of data it's able to read before failing varies, it always fails. I've tried both the FreeBSD-13.0-RELEASE-arm64-aarch64-ROCKPRO64.img.xz and FreeBSD-13.0-STABLE-arm64-aarch64-ROCKPRO64-20211230-3684bb89d52-248759.img images, but they both have the issue. I've tried Linux on the same SBC with= the same ZFS pool, and it had no issue. I tried a Raspberry Pi 4 running FreeBSD 13.0 RELEASE with the same ZFS pool, and it had no issue. I should note that both the Linux and Raspberry Pi tests lacked hardware crypto support (Linux because Linux apparently doesn't support ARM crypto in ZFS yet, and Raspber= ry Pi because those have no crypto hardware), so they both relied on software crypto which constrained performance to tens of MB/s, rather than hundreds = as FreeBSD on the ROCKPro64 does in my problem case. To that end I also used t= he ZFS pool with an Intel system running FreeBSD 13, which has working hardware crypto and it was able to work with the disks even faster than the ROCKPro6= 4, with no issues. So my suspicion is the enclosure is not the culprit, since = it worked fine on RPi and Intel systems. I also suspect the SBC itself is not = the culprit since it worked fine with Linux, though it's possible the issue only shows up when reading from the disks at a particular speed and Linux's constrained crypto performance just didn't reach that speed. I'm also able = to work with other disks just fine with FreeBSD on the ROCKPro64: it's only th= is multi-disk enclosure that has trouble. I can create an encrypted ZFS pool o= n a USB 3 SSD connected directly to the SBC (no intermediary hub) and it works fine, no trouble at all. Initially I suspected that my SBC or enclosure might be at fault, but throu= gh this testing I've come to instead suspect there is some sort of issue in the xhci driver for the ROCKPro64, perhaps somehow related to the enclosure hav= ing a USB hub in front of the disks. But I am only speculating! Could someone h= elp me troubleshoot this issue further, to see why xhci1 is resetting unexpecte= dly? Thank you for your help! --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 19 01:30:23 2022 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 245421956F35; Wed, 19 Jan 2022 01:30:35 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (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 "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jdp49729cz3PQK; Wed, 19 Jan 2022 01:30:33 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 20J1UNVP058297; Wed, 19 Jan 2022 10:30:23 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202201190130.20J1UNVP058297@kx.truefc.org> Date: Wed, 19 Jan 2022 10:30:23 +0900 From: KIRIYAMA Kazuhiko To: ports@freebsd.org Cc: freebsd-arm@freebsd.org, kiri@truefc.org Subject: Can't build 5 ports in arm64/aarch64 on PBP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jdp49729cz3PQK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-1.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[truefc.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm,ports]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 14105 Lines: 296 Hi, lists I've tried to build arm64/aarch64 packages on Pinebook Pro (PBP). 15 ports out of 80 were failed. Besides ports which could not be built in arm64/aarch64 in the first place, 9 ports remained. 4 ports out of the 9 are textproc/smartdoc-devel, print/pdftk, japanese/libreoffice, java/icedtea-web. These could be built by upgrade Jave version from 8 to 12. Eventually, followng 5 ports remained with CANNOT BUILD PORTS : 1) japanese/tgif, graphics/inkscape, japanese/xv These were failed with linker error at graphics/jasper : ld: error: undefined symbol: glutSetWindowTitle >>> referenced by jiv.c >>> src/appl/CMakeFiles/jiv.dir/jiv.c.o:(loadimage) ld: error: undefined symbol: glutTimerFunc >>> referenced by jiv.c >>> src/appl/CMakeFiles/jiv.dir/jiv.c.o:(loadimage) cc: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure = to the maintainer. *** Error code 1 Stop. make[4]: stopped in /var/ports/lpbpkx/graphics/jasper 2) www/firefox Failed at devel/llvm13 : [ 65% 4725/7265] /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACR= OS -D__STDC_LIMIT_MACROS -I/var/ports/work/usr/ports/devel/llvm13/work/.bui= ld/tools/flang/lib/Evaluate -I/var/ports/work/usr/ports/devel/llvm13/work/l= lvm-project-13.0.0.src/flang/lib/Evaluate -I/var/ports/work/usr/ports/devel= /llvm13/work/llvm-project-13.0.0.src/flang/include -I/var/ports/work/usr/po= rts/devel/llvm13/work/.build/tools/flang/include -I/var/ports/work/usr/port= s/devel/llvm13/work/.build/include -I/var/ports/work/usr/ports/devel/llvm13= /work/llvm-project-13.0.0.src/llvm/include -isystem /var/ports/work/usr/por= ts/devel/llvm13/work/llvm-project-13.0.0.src/llvm/../mlir/include -isystem = /var/ports/work/usr/ports/devel/llvm13/work/.build/tools/mlir/include -isys= tem /var/ports/work/usr/ports/devel/llvm13/work/.build/tools/clang/include = -isystem /var/ports/work/usr/ports/devel/llvm13/work/llvm-project-13.0.0.sr= c/llvm/../clang/include -O2 -pipe -DNDEBUG -fstack-protector-strong -isyste= m /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem /usr/local/inc= lude -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror= =3Ddate-time -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused= -parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedant= ic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovere= d-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual= -dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdia= gnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-copy -Wn= o-string-conversion -Wno-unused-command-line-argument -Wstring-conversion = -Wcovered-switch-default -Wno-nested-anon-types -O2 -pipe -DNDEBUG= -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing = -DNDEBUG -isystem /usr/local/include -fno-exceptions -std=3Dc++17 -MD -MT= tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expressi= on.cpp.o -MF tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/ch= eck-expression.cpp.o.d -o tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEv= aluate.dir/check-expression.cpp.o -c /var/ports/work/usr/ports/devel/llvm13= /work/llvm-project-13.0.0.src/flang/lib/Evaluate/check-expression.cpp ninja: build stopped: subcommand failed. =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure = to the maintainer. *** Error code 1 Stop. make[3]: stopped in /var/ports/lpbpkx/devel/llvm13 *** Error code 1 Stop. make[2]: stopped in /var/ports/lpbpkx/devel/wasi-libc *** Error code 1 Stop. make[1]: stopped in /var/ports/lpbpkx/devel/wasi-libcxx *** Error code 1 Stop. make: stopped in /usr/ports/www/firefox 3) www/chromium Failed with "'__CPUELT' is invalid in C99" at sysutils/flock : libtool: compile: cc -DHAVE_CONFIG_H -I. -include config.h -I./include -DL= OCALEDIR=3D\"/usr/local/share/locale\" -D_PATH_LOCALSTATEDIR=3D\"/var\" -I/= usr/local/include -fsigned-char -fno-common -Wall -Werror=3Dsequence-point = -Wextra -Wextra-se mi -Wembedded-directive -Wmissing-declarations -Wmissing-prototypes -Wno-mi= ssing-field-initializers -Wredundant-decls -Wsign-compare -Wtype-limits -Wu= ninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-= parameter -W unused-result -Wunused-variable -Wnested-externs -Wpointer-arith -Wstrict-p= rototypes -Wformat-security -Wimplicit-function-declaration -O2 -pipe -fsta= ck-protector-strong -fno-strict-aliasing -MT lib/libcommon_la-parse-date.lo= -MD -MP -MF lib/.deps/libcommon_la-parse-date.Tpo -c lib/parse-date.c -o lib/libcommon= _la-parse-date.o >/dev/null 2>&1 mv -f lib/.deps/libcommon_la-parse-date.Tpo lib/.deps/libcommon_la-parse-da= te.Plo /bin/sh ./libtool --tag=3DCC --mode=3Dcompile cc -DHAVE_CONFIG_H -I. -i= nclude config.h -I./include -DLOCALEDIR=3D\"/usr/local/share/locale\" -D= _PATH_LOCALSTATEDIR=3D\"/var\" -I/usr/local/include -fsigned-char -fno-comm= on -Wall -Werror=3Dseq uence-point -Wextra -Wextra-semi -Wembedded-directive -Wmissing-declaration= s -Wmissing-prototypes -Wno-missing-field-initializers -Wredundant-decls -W= sign-compare -Wtype-limits -Wuninitialized -Wunused-but-set-parameter -Wunu= sed-but-set- variable -Wunused-parameter -Wunused-result -Wunused-variable -Wnested-exte= rns -Wpointer-arith -Wstrict-prototypes -Wformat-security -Wimplicit-functi= on-declaration -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT= lib/libcomm on_la-path.lo -MD -MP -MF lib/.deps/libcommon_la-path.Tpo -c -o lib/libcomm= on_la-path.lo `test -f 'lib/path.c' || echo './'`lib/path.c libtool: compile: cc -DHAVE_CONFIG_H -I. -include config.h -I./include -DL= OCALEDIR=3D\"/usr/local/share/locale\" -D_PATH_LOCALSTATEDIR=3D\"/var\" -I/= usr/local/include -fsigned-char -fno-common -Wall -Werror=3Dsequence-point = -Wextra -Wextra-se mi -Wembedded-directive -Wmissing-declarations -Wmissing-prototypes -Wno-mi= ssing-field-initializers -Wredundant-decls -Wsign-compare -Wtype-limits -Wu= ninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-= parameter -W unused-result -Wunused-variable -Wnested-externs -Wpointer-arith -Wstrict-p= rototypes -Wformat-security -Wimplicit-function-declaration -O2 -pipe -fsta= ck-protector-strong -fno-strict-aliasing -MT lib/libcommon_la-path.lo -MD -= MP -MF lib/. deps/libcommon_la-path.Tpo -c lib/path.c -fPIC -DPIC -o lib/.libs/libcommo= n_la-path.o In file included from lib/path.c:31: In file included from ./include/path.h:24: ./include/cpuset.h:80:7: error: expected expression if (CPU_ISSET_S(cpu, setsize, ary[i])) { ^ ./include/cpuset.h:41:25: note: expanded from macro 'CPU_ISSET_S' ? ((((__cpu_mask *) ((cpusetp)->__bits))[__CPUELT (__cpu)] = \ ^ ./include/cpuset.h:80:7: error: use of undeclared identifier '__cpu_mask' ./include/cpuset.h:41:13: note: expanded from macro 'CPU_ISSET_S' ? ((((__cpu_mask *) ((cpusetp)->__bits))[__CPUELT (__cpu)] = \ ^ ./include/cpuset.h:80:7: warning: implicit declaration of function '__CPUEL= T' is invalid in C99 [-Wimplicit-function-declaration] ./include/cpuset.h:41:48: note: expanded from macro 'CPU_ISSET_S' ? ((((__cpu_mask *) ((cpusetp)->__bits))[__CPUELT (__cpu)] = \ ^ ./include/cpuset.h:80:7: warning: implicit declaration of function '__CPUMA= SK' is invalid in C99 [-Wimplicit-function-declaration] ./include/cpuset.h:42:6: note: expanded from macro 'CPU_ISSET_S' & __CPUMASK (__cpu))) !=3D 0 = \ ^ ./include/cpuset.h:80:3: error: statement requires expression of scalar typ= e ('void' invalid) if (CPU_ISSET_S(cpu, setsize, ary[i])) { ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 warnings and 3 errors generated. *** Error code 1 Stop. make[2]: stopped in /var/ports/work/usr/ports/sysutils/flock/work/util-linu= x-2.30.1 *** Error code 1 Stop. make[1]: stopped in /var/ports/lpbpkx/sysutils/flock *** Error code 1 Stop. make: stopped in /usr/ports/www/chromium Is there any suggetions ? My package build machine environments are as follows : Ports branch is 7216c1d263e8 and others are : root@kazu:~ # uname -a FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n251838-90c89dc67099-= dirty: Mon Jan 3 15:41:32 JST 2022 root@tbedfc:/usr/obj/usr/src/arm64.= aarch64/sys/GENERIC-DRM arm64 root@kazu:~ # df -h Filesystem = Size Used Avail Capacity Mounted on /dev/mmcsd0p3 = 105G 889M 96G 1% / devfs = 1.0K 1.0K 0B 100% /dev tmpfs = 11G 52K 11G 0% /tmp linprocfs = 4.0K 4.0K 0B 100% /compat/linux/proc tmpfs = 11G 4.0K 11G 0% /compat/linux/dev/shm linsysfs = 4.0K 4.0K 0B 100% /compat/linux/sys devfs = 1.0K 1.0K 0B 100% /compat/linux/dev fdescfs = 1.0K 1.0K 0B 100% /compat/linux/dev/fd 192.168.1.17:/.dake = 12T 965G 11T 8% /.dake 192.168.1.17:/ds/src/freebsd/current/14.0/90c89dc67099.generic_drm = 11T 70G 11T 1% /usr/src 192.168.1.17:/ds/obj/freebsd/current/14.0/90c89dc67099.generic_drm = 11T 410G 11T 4% /usr/obj 192.168.1.17:/ds/ports/freebsd/7216c1d263e8 = 11T 107G 11T 1% /usr/ports 192.168.1.17:/ds/distfiles = 11T 53G 11T 0% /var/ports/distfiles 192.168.1.17:/ds/packages/freebsd/arm64/aarch64/14.0C/90c89dc67099/7216c1d2= 63e8 11T 114G 11T 1% /var/ports/packages root@kazu:~ # cat /etc/make.conf PORTSDIR=3D /var/ports/lpbpkx INDEXDIR=3D /var/ports/lpbpkx WRKDIRPREFIX=3D /var/ports/work PACKAGES=3D /var/ports/packages DISTDIR=3D /var/ports/distfiles BATCH=3D yes DEFAULT_VERSIONS=3D perl5=3D5.34 ruby=3D2.7 java=3D12 COMPILER_TYPE=3D clang USE_PACKAGE_DEPENDS=3D yes DISABLE_VULNERABILITIES=3Dyes root@kazu:~ #=20 GENERIC-DRM kernel was built by `git subtree add' to 14.0-CURRENT (08ff54dc5b5d) for Panfrost driver [1] : First `git subtree add' to 14.0-CURRENT (08ff54dc5b5d) in src server : root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git checkou= t 08ff54dc5b5d HEAD is now at 08ff54dc5b5d aw_spi: improve I/O stability root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git remote = add drm-subtree https://github.com/jsm222/drm-subtree.git root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git subtree= add --prefix sys/dev/drm/ drm-subtree pinebookpro-test git fetch drm-subtree pinebookpro-test remote: Enumerating objects: 794, done. remote: Counting objects: 100% (794/794), done. remote: Compressing objects: 100% (518/518), done. remote: Total 794 (delta 370), reused 685 (delta 264), pack-reused 0 Receiving objects: 100% (794/794), 1.14 MiB | 5.09 MiB/s, done. Resolving deltas: 100% (370/370), done. =46rom https://github.com/jsm222/drm-subtree * branch pinebookpro-test -> FETCH_HEAD * [new branch] pinebookpro-test -> drm-subtree/pinebookpro-= test Added dir 'sys/dev/drm' root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM= .patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git apply s= ys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # git rev-par= se --verify --short HEAD 90c89dc67099 root@vm:/ds/src/freebsd/current/14.0/08ff54dc5b5d.generic_drm # cd .. root@vm:/ds/src/freebsd/current/14.0 # mv 08ff54dc5b5d.generic_drm 90c89dc6= 7099.generic_drm and then build GENERIC-DRM in PBP : =20 # cd /usr/src # make buildworld TARGET=3Darm64 # make buildkernel TARGET=3Darm64 KERNCONF=3DGENERIC-DRM Best regards [1] https://github.com/jsm222/drm-subtree --- Kazuhiko Kiriyama From nobody Thu Jan 20 14:02:33 2022 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 31C6E1969C06 for ; Thu, 20 Jan 2022 14:02:34 +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 4JfkjP6B1rz55B1 for ; Thu, 20 Jan 2022 14:02:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 AB4EE190A for ; Thu, 20 Jan 2022 14:02:33 +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 20KE2X30092480 for ; Thu, 20 Jan 2022 14:02:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20KE2Xt7092479 for freebsd-arm@FreeBSD.org; Thu, 20 Jan 2022 14:02:33 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 261355] dwc(4) fails to attach on BananaPi A20 Date: Thu, 20 Jan 2022 14:02:33 +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: marentoy@protonmail.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642687353; 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=d4TjoViIwsytkCprT45nm61geou4CbjTSCwY6twnyn4=; b=a/XyRAHf9+S6+UD8nF8R1atKTX80DAB/clmcz3HHie5sXNki/PbhYsMlI9ymOHogcOLyiU 9WMuwS7t3MrVH7iaPo2CZvMjkaCth9cSq/pbRokvKbdK2UTsrVFF3YZN/vNvVcfcwVI/to u90XjPlruY9p1S5ICh9lhD1w0LO76EYhAbdk/dszT5kXRjfyuGTXp8EmpjhRsLJAgW0Eir LQmeimdHjTM+m7uy0oj2hmBgQrOIeb/X6GfEnke57SLK+f/lITJj2qgaK/d3rXX7X2gmjo tiFvolwcD+h+5Gu3kBLhZzNLtiWrbUKyPZ1ZRro6aIHWHaLxpjvKOnSdH7KmrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642687353; a=rsa-sha256; cv=none; b=ylxjaKsDEHY66c8ZzdzJqZtvnz76aEwZgsVyqo7ETcLTw4YZst7R6W+uAIWKS6jJZC4xdX vJ8R+jdXkuLNx6WpV0w7c70uOaoRrdSjm09LDuD0bT3Pcc9mqnkpecBx/fKRlEWZnNFH1Q ZBqGC8dieES2ey6LD/oTeNiOczjUpNZgvW+/UMpSjYuF4TcbFingGw18G3ZS/9b4OjANmS 66eD/nF2d4MjhKqcxaOnDwVdDnE8OyeqSOLRRf2MU6tab6OAZZeVWdHJ7QSh50bMZlnx5a KPllzOP52xIU9isNU6VU6xXQFAkOJva7Eg9kCD2DnPaekLAL2W8Sihpd5KYFrw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2103 Lines: 58 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261355 Bug ID: 261355 Summary: dwc(4) fails to attach on BananaPi A20 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: marentoy@protonmail.com It's running 14.0-CURRENT d106f982a54cd299671ccad58bc456138a22ae7b dwc0: mem 0x1c50000-0x1c5ffff irq 72 on simplebus0 dwc0: MAC clock(ahb-gmac) freq: 160000000 dwc0: Can't reset DWC. device_attach: dwc0 attach returned 6 after changing phy-mode back to rgmii in sun7i-a20-bananapi.dts, it works again. diff --git a/sys/contrib/device-tree/src/arm/sun7i-a20-bananapi.dts b/sys/contrib/device-tree/src/arm/sun7i-a20-bananapi.dts index 9d792d7a0f92..87cef1fc7dfd 100644 --- a/sys/contrib/device-tree/src/arm/sun7i-a20-bananapi.dts +++ b/sys/contrib/device-tree/src/arm/sun7i-a20-bananapi.dts @@ -132,7 +132,7 @@ pinctrl-names =3D "default"; pinctrl-0 =3D <&gmac_rgmii_pins>; phy-handle =3D <&phy1>; - phy-mode =3D "rgmii-id"; + phy-mode =3D "rgmii"; phy-supply =3D <®_gmac_3v3>; status =3D "okay"; }; dwc0: mem 0x1c50000-0x1c5ffff irq 72 on simplebus0 dwc0: MAC clock(ahb-gmac) freq: 160000000 miibus0: on dwc0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 5 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on miibus0 rgephy1: OUI 0x00e04c, model 0x0011, rev. 5 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto dwc0: bpf attached --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Jan 20 19:41:10 2022 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 BE9D41960C0F for ; Thu, 20 Jan 2022 19:41:47 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 4JftDp75NQz3PlN for ; Thu, 20 Jan 2022 19:41:46 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi1-x22c.google.com with SMTP id s127so10466916oig.2 for ; Thu, 20 Jan 2022 11:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=pif7GKzQYDzYJ/D5jBaZ2pwO18KWE8ZnrBIfmKCawUc=; b=R8+FrU6yoSBK6Ev3Flb1Il57VG7RqIk0V6MvKJbmABvqe32sT5X6NmTJ90HHkZ51Q8 xX2E7e9rnJQBS/qq+9iEsZ1CQ4Ueqy6AWr5Y2eMG7Ob52rrDWia4EsYCQth4MZf6To5b +4x9NYXv/cLt3ygX0WP+0RWp5YGBfBfN54W+hSAF7cSzbV08ouf1AZP3fYVXv3rVBmVp U023XTO1fc0NAC4w6HRa3eieSD2yg5ztWZvj+JH0LYLO0F94bKI1PfbQ5sMWt3yCesLO wgIR8LLuXCKB8FDvUlM0hWujFT43EsSlZWzRI+hdLiInCOr8Z0K/ky0+15Gv+LXiikCh xqSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pif7GKzQYDzYJ/D5jBaZ2pwO18KWE8ZnrBIfmKCawUc=; b=eSpkjNk//GnmoB7/aFjw0/nclK59UKhIKKM602ydn429IfzhMP4F3nMDOmiMFJf0gz GcoQjHCKP3wIffZlUrBoZaxF11PoQiM6XEHDTR4ZSS5d9JDY9nQEGzDD7GrPUgFOeZwq ri9MrJ3g+OJ2JbuYCDfZNnV05zAzguTAC3NjdFown33GdN6aO2ZLkyfIq5GoKjv592lB ateXBlYevkaqR7wv5LdsIKEtj3k/o7AD/da7pfEXq2+R2Euk/+VEgaNL2MDz5ZIiUCkl +IMdr/yhcS9GSEABAGYlPqCUrzSZ4D+bM3Q446ZFRqUMAEnFFVXQXFNNBGKIWfK+yuQD EmNQ== X-Gm-Message-State: AOAM530EQQqbjC0jJIva/1yBC7s0q/dtPCWjJzIlF8MXDAwK7IseM3b8 BHxUrribeTV5V3aHdKahsgDB+qfWDtQzMZU+6DFHX+7B6fw6VA== X-Google-Smtp-Source: ABdhPJyen+L/7krD4nXmROnzXqq/y2ENy7FGmmY6uTH9X98i9PSEciqwQLc2yU0eKnyZQMbXr+vO7Mnk51OkUQEZYtY= X-Received: by 2002:a05:6808:bcc:: with SMTP id o12mr416738oik.66.1642707706080; Thu, 20 Jan 2022 11:41:46 -0800 (PST) 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 From: Lee D Date: Thu, 20 Jan 2022 14:41:10 -0500 Message-ID: Subject: Trouble booting RELENG 13.0 on a Zynq XC7Z010 (Zybo-like) board To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JftDp75NQz3PlN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=R8+FrU6y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of embaudarm@gmail.com designates 2607:f8b0:4864:20::22c as permitted sender) smtp.mailfrom=embaudarm@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22c:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1115 Lines: 31 Hi Everyone, I am trying to get FreeBSD RELENG 13.0 to boot on a custom Xilinx Zynq (XC7Z010) board, based loosely on a Zybo. I am using a custom boot loader that loads and launches the kernel. I figured out how to do this back in 2016 with FreeBSD 10 and 11, and the product that uses this load has been working well ever since. Back then I used Thomas Skibo's examples as a reference, but those have not been updated for 13.0. Just to start with, I have compiled a 13.0 kernel using a slightly modified ZEDBOARD config, and am attempting to boot that with my existing 11.0.1-compatible bootloader, and 11.0.1 dtb file. I modified the bootloader to jump to 0x02000200 instead of 0x02000100. Tracing through, I can see that it is panicking in platform_probe_and_attach(), with the message "No platform module found!". Also, incidentally, it doesn't seem to be printing messages to the serial port like it used to. Could anyone tell me what a platform module is and where it is set? Also, where is the ubldr (or equivalent) code that sets up the environment for the kernel launch now located? Thanks, Lee From nobody Thu Jan 20 20:46:02 2022 X-Original-To: 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 EE6DA1962A01 for ; Thu, 20 Jan 2022 20:46:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jfvg75PL1z4ZfD for ; Thu, 20 Jan 2022 20:46:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642711564; bh=xmVtpaueQrpaHEDUY8uXcJh3j4sFQ5uMpJ92uA9kb5E=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nfmD5E8wQfxCNLK3Xddqy/e4FLHi8TgyWrqjhNF+5+D3A0e+ZyP07oCXSu6WkmJi25wd66vUR84HJ19Kcym4RpJQ0VTbaPoMH2YmXYnmmlfsFF22DlMcXra9iZlVueMiLahEdcQwGntiG7jsjZ9AkGN3iZHtZoiLszzdHVZtvcP1bny7M4gTgZD8glmka54VNB2y2TLvp7PW12IbJHsCkoISy/D2JHiiL/WljWe1z/VID/NkNLxWs1NrR0OuvIdPs2PEuK3Lny/uA4hGMd/YWfFiW4WuV9/xqcOhT4jsUCGW9Apgq1junJ4zSjCoBgLLIGHZQ3ORrnR58UyM1NdMgw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642711564; bh=c1d1Fxmhr9c1eIBWUOWZdD+Uc1BTUA4WyvMhflVsPKa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kh94XdzYTWYPBsGgmXdqUPSHvEIpUI8+/uZxejIPoXHkl2W4GYx9rFBwqYhPRfb3aXRXtotdaJ3i4oii0khGutgO0Cb34eP7aeyejUZ+Rd0x75AHDHuf59Kbx5l/8QNBjWNthBSZGCB+gOkGc8OExsKvVagitv3XPqgBAYFQYm4q5J3HY1/KcLNtw3ryC8X95AGKT0uhfRjPEP6xo5X+LiF6+Lgqs1zAZUVEjduB0K8atafmt461g4WjxXer8AYIa+TMaKqVeibAEKm8rlJzfRVeRZ3T+TDajzGalzOlkop1473vsXLYl504un3YHRZVQNJItjD10dydUGTDRqibzg== X-YMail-OSG: .Sq.n8AVM1nc78ZjMj2FNCvQLlQvaExcxv9N29xGpEiJ4R_lJ.FnoSMRkEsBNSg veN_v1OD9etZym1XpoH3jFiEGaV.oLWDs3WH5GWCsxmdmi9mVIpTYODV9Pl_DmGG22MQZE0E1usX YBpaZxxZeyFSqXmsGzbma2YoJ9BWmu8uCGQ.OhtSb7SxgG7hjqZQVLVIHFtFcClSD9JMfMRGdNjJ xKxGjIAEBmsmaX2iojjg7G6RzCnew7a8iqt2ZeV27lPhGdSuiNDjFRyw3ovRzmdHprIdp9avouau leZqe2X_.Wn_iIQTGRqx3er_Olv4XzRzxsW5Zxq4IDx_eQwb.6N.PD0YWVVjdW1l9Fl3lv.Xrjk. jlqQHnNjC8g435xUbz1DIxauc9lqbQQFXbTuAgteer.rp2BcMCpVg99WKj49L0.XRFu_LFA42cD1 oO28vYXuNdfL._xW1tFo4gSAojTJbaUhu8JyofgwTIJozrS04fIq25aAJJsyfvUJzcsQaHFmkJb8 tccz9gDmsbxGRp.NZ0MfAaBkrSeFhOn4.KK9lVfkESBuANZ7VtM0vX2U1tw0_dpbl9A9TuEs2TMx GDjbh46LdH8S21AxjyzafkUs8o6tXP1o5G06gGGS8NlDtZWTpdndvhyXHX1gk1aLzjF6df_bVPzC xgehQLH7KWOgWBOmXD6j9FrVlbyLtI2ppm6Amd9maAcg8ZZ2FwVkA2kFfbHCFFNL8OTozfYNwCeD FsdmmPuZwH6QQoYdmeXGQbZHYp3RhyfH4iFOlAhLjiczhBuCp.VRcDFGv6Z9nswSAo06RxOIe0.W PutoVsLq.h9CUquls4z3h6QPNvlRBiDcgb1hl8KcX2ntTcielr85ZWteP7cMGpr_PrhrlG7Uz5N9 7B6wAvgYDWYD5wSNNjsQbu5vebqdlAg7S.FyY8yeerT8wmy6hYPnJF8etnZk6QyywoIaecfGRhe3 8xsTE6RQjvsmwEcmLt5aMd9GdmqLmGsDqwEnh2n5ep9OKejUH2Nm6ivkNKfPh_fpLhEYaGl_ERxJ 9KOepgyiJkC5dCuPKfB3ama2Fejy3Fb559bXwkHYDUjjRiFh3.zgQUWoMQMcNvlWx6mCnEi8tcMv PeFo.3FjlG.nwINWlDjzo5RnvpyPiSq8OvGxyIz3z1LjIxg8S3b1jfmkB54TmiDmNsg1GtAqZAaj NIfzciD8KQDmtVYa9KKTlKpSsToa9RfDSymhby3VB7j.Vfr5DR4Ioyn58DXBtYe9F100rYBAIaz3 glPVhMpVCrZGtBQUJsX5gLhiu8GTXcDQFB5HAm8pbkQkWQCirDArmvToKRnFREnUquyC4SlWM062 K1DkPFgFxprDVXIya9swARr_8G7P1MaQnPnT6VG8kbw7VgYAEEz6TWOaL0AWKSXB.StCGFiW288h jVv_AdGXdafFNZ.6f60j.DYcY2n_07CF527NHchQ13rkk.cswrESvKc0EINakaSgDNXkbQTh80TJ cTOk7hIDYgmZVviwExHqO5LljsJmzWwXY5iSEUuRbr7tqoB2B5bzfzzerSTI9cYx.3s_5IgNUIqm 2rUo5cbIF3f0kjJjVH6wgnD58b5l6iAPgTmGVMhK6duSGxFak_Fayd_PBZAbO2TCr2howUpyMhl1 BcYIWbv375YHF6poKMiUMLx.E39z_5Bb4JYZbG0Qcz6OtfAbJ6wN5eS8rcRGggvmgyxafCapZ9SE 2Na.Qp3xGPpY7N2LKIEKJaxeaMEFyfxtXT9_21IKCMiScbhU8lOlW5IfyGLiuFNH9m.Tc8.I8uHE 1CqpmwEGGFnQENi.AF_xZxbmBAMPOUtHx737l02YoOlBkdmWRMi5Xa1BdmwKC4eSFMaYpY0X51kM 689h7BmxS4XW3c4coFeK_mjTzHh0om8a_g4t2t1qXa6iXrdz8AK8xLxmx0JS89IWw2m9Py7tCPfi lc3vX3HQioGIie2ovpwFGeeaONz6wiVIv91LQhCiEEy0PmEh10uqL0v_LMTJ.IAX6YhzjHQz18w0 fXiE9zz3wRcWrXU2TbgTaUm9NxR6X.t17_qXv3I2OJ6JtlLkyj8qlaeLbvyUbbdjf9iQ8Xk49Umk JDnnnxAaFKA5u0VEmjiU2Es5FH_EzUtgrK8hHigCvW1fD3NqWVGRTw8RR_CqEhRP9i4YrqVDdHnT _tUvokreEDS2PFNCQ9KwtKk8PwQAuNKKAnN6ByAJpSKVbqZpjGDe3CfE4WHaDErDGln3h7055zcN t1uXE7kqNzdzdFFCWl4gLh3POwBiHyspvAM_MS8w6ZccPa3xX.BmanN_oTS2lHU_.txwQosc19H5 rUU5QS4pFYObrHeAZxIlEEdignFfYswsqYKAcHDGlZWQ7Ae67dI5sxDlj X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Jan 2022 20:46:04 +0000 Received: by kubenode517.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2d9ad9fd5c9c463b32217b2e5e86e2e; Thu, 20 Jan 2022 20:46:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work Message-Id: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> Date: Thu, 20 Jan 2022 12:46:02 -0800 To: Wojciech Puchar , "freebsd-arm@freebsd.org" , FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jfvg75PL1z4ZfD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nfmD5E8w; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.32 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.18)[0.179]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; MLMMJ_DEST(0.00)[arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 445 Lines: 17 Wojciech Puchar wrote on Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) : > tried RPI image for 13.0 and RPI3 image 12.3 > both does not boot at all. nothing on serial console at all. > What image should i use for this computer? The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W units. That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 relevant. === Mark Millard marklmi at yahoo.com From nobody Thu Jan 20 22:51:28 2022 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 C40121970A8A for ; Thu, 20 Jan 2022 22:51:40 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfyRv0bk7z4RhY for ; Thu, 20 Jan 2022 22:51:38 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Thu, 20 Jan 2022 23:51:30 +0100 id 00DD63AD.61E9E772.00001561 Date: Thu, 20 Jan 2022 23:51:28 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Trouble booting RELENG 13.0 on a Zynq XC7Z010 (Zybo-like) board Message-ID: <20220120235128.0e7fb82d@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0git329 (GTK+ 2.24.33; i386-portbld-freebsd11.4) 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: 4JfyRv0bk7z4RhY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-1.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.988]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1945 Lines: 55 On Thu, 20 Jan 2022 14:41:10 -0500 Lee D wrote: > Hi Everyone, > > I am trying to get FreeBSD RELENG 13.0 to boot on a custom Xilinx Zynq > (XC7Z010) board, based loosely on a Zybo. I am using a custom boot > loader that loads and launches the kernel. > Hi, how is this boot loader made? All Zynq based boards I know about use U-Boot customized according the board's design. > I figured out how to do this back in 2016 with FreeBSD 10 and 11, and > the product that uses this load has been working well ever since. > Back then I used Thomas Skibo's examples as a reference, but those > have not been updated for 13.0. > > Just to start with, I have compiled a 13.0 kernel using a slightly > modified ZEDBOARD config, and am attempting to boot that with my > existing 11.0.1-compatible bootloader, and 11.0.1 dtb file. I > modified the bootloader to jump to 0x02000200 instead of 0x02000100. > I am not sure, but I think there was some change in boot process, so your 11-compatible bootloader is probably no longer compatible with 13.0 kernel. Also, you may need to create new dtb, some modification is probably necessary. > Tracing through, I can see that it is panicking in > platform_probe_and_attach(), with the message "No platform module > found!". > > Also, incidentally, it doesn't seem to be printing messages to the > serial port like it used to. > Could you verify your serial port settings? If I am not mistaken, some critical board setup is expected to be done in bootloader, FreeBSD kernel just uses what is already set. This is valid especially for serial port used as console. > Could anyone tell me what a platform module is and where it is set? > > Also, where is the ubldr (or equivalent) code that sets up the > environment for the kernel launch now located? > There is some push towards using efiloader for loading kernel. I have no specific answer on kernel environment... Regards, Milan From nobody Fri Jan 21 00:22:33 2022 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 428261951EE8 for ; Fri, 21 Jan 2022 00:23:17 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 4Jg0Tc3p7xz3FqH for ; Fri, 21 Jan 2022 00:23:16 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot1-x32b.google.com with SMTP id c3-20020a9d6c83000000b00590b9c8819aso9749873otr.6 for ; Thu, 20 Jan 2022 16:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k7YgpIgmhXx7aYASjRX8mVE0+inpHlhD1ROwFlrNiWU=; b=LO9C3fJow4E2pAI0jQDYbLuO/Tzpjw+CKIqMuKaipveip3qzU7WcemdRPrlNssnvMB nABhS54utJWy4G+LRrgtLlmm8KX/n2C4QzF4z3kXeT8OjgvhbvlZRuSQEwjicHjUjZBh KndgOwDgIxjobVvNgDEZD7FtEzZhvPMx8GB9I0S2QaGxhefOAALOFxnmerlYD8m49151 FEEGNscLZnvkv9C1cpIy6jhw5qTsCwc6I+l9kxRmIDxIKaRV3u4IUSctzy223qbVYcyQ 9tZNx6WyHrW7hkjPYcUQjHgI+xYnZU0egE8F07nqg3IU3m5LRDL1ojsyzy16T7vkwd67 YuZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k7YgpIgmhXx7aYASjRX8mVE0+inpHlhD1ROwFlrNiWU=; b=an3W7boUOtY9JwHnrORHcbePMKxVp57HtRANsnjdGkjRT+JGtlK5ymKCHCKqPX6Tpt rpuFlgrt1yrSTbJppjvbO9j6kDVNFSc5kZVubHffLXg1Q3pZ2Z16SGd3ZFtetJfB61X7 2m5U9acjHHhYsOyeaQxZSZrPupg6Dfi/CIXTNanCipIxTAufwSjzuhmD24IpmWnNP+vm Zuk4beE2Fy986p7Gcro6oivuQbqDWrI84tfaru/mAwRgHgKQGuk8Mbygj+yplTmPhreF jlyUPDb/z1qRmCc9FCv5MXn4hiOfFu2Rx7XRVlNNna4WCY9mexaszMphUR/wXabfUojh 8Auw== X-Gm-Message-State: AOAM531YRwSvbiy2M86cvxnNga1Wpi3VDRw0YLCuD7aytb7S7cO4WVTs f31T//7bd/aOVp6u9hEPkksyJD2yWDXEaUVFW1QQJ9PdQPo= X-Google-Smtp-Source: ABdhPJzydzO8g9qVt2NuiEyEQ++1+eia0XCbZtIwgcnW/K0uUU6FJpGBBgcp/3xfMJygVZGFXxAcsBECwGbiaDUoDQg= X-Received: by 2002:a9d:f04:: with SMTP id 4mr1017091ott.326.1642724589888; Thu, 20 Jan 2022 16:23:09 -0800 (PST) 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: <20220120235128.0e7fb82d@zeta.dino.sk> In-Reply-To: <20220120235128.0e7fb82d@zeta.dino.sk> From: Lee D Date: Thu, 20 Jan 2022 19:22:33 -0500 Message-ID: Subject: Re: Trouble booting RELENG 13.0 on a Zynq XC7Z010 (Zybo-like) board To: Milan Obuch Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Jg0Tc3p7xz3FqH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LO9C3fJo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of embaudarm@gmail.com designates 2607:f8b0:4864:20::32b as permitted sender) smtp.mailfrom=embaudarm@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32b:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2000 Lines: 54 On Thu, Jan 20, 2022 at 5:52 PM Milan Obuch wrote: > Hi, > > how is this boot loader made? All Zynq based boards I know about use > U-Boot customized according the board's design. Thanks for the response. I've fixed a couple of problems, and gotten a little further, but the kernel is still crashing before it prints the banner. This is a custom bootloader, for a custom PCB, that I wrote from scratch back in 2016. > > I am not sure, but I think there was some change in boot process, so > your 11-compatible bootloader is probably no longer compatible with > 13.0 kernel. Also, you may need to create new dtb, some modification is > probably necessary. > Yes, it turns out that a new dtb was needed. I needed to: 1. update my .dts to reflect the default zybo .dts settings, and include "zynq-7000.dtsi" from the source tree. 2. add the "xlnx,zynq-7000" string to the "compatible" key. That solved the problem with the "No platform module found!" panic. 3. add "freebsd,dts-version = "5.9";" to the dts file, which is something that the FreeBSD build system adds automatically when compiling dts files. > Could you verify your serial port settings? If I am not mistaken, some > critical board setup is expected to be done in bootloader, FreeBSD > kernel just uses what is already set. This is valid especially for > serial port used as console. After I did #2, above, then the serial output started working, so it seems it is still expecting the same settings (uart 1, 115200/8/n/1) as FreeBSD 11. Now I am to the point of getting another crash, with no panic message, that dumps me into the KDB debugger prompt. > > There is some push towards using efiloader for loading kernel. I have > no specific answer on kernel environment... If anyone could point me to the code that sets up the metadata and environment so the kernel can run, that would be super helpful. Right now I am still using the same metadata structures that I used for FreeBSD 11. Thanks, Lee From nobody Fri Jan 21 03:16:01 2022 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 98C5B195F2EC for ; Fri, 21 Jan 2022 03:16:09 +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 4Jg4K43Splz3jZP for ; Fri, 21 Jan 2022 03:16:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20L3G1wU026420 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 20 Jan 2022 19:16:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20L3G1Dm026419; Thu, 20 Jan 2022 19:16:01 -0800 (PST) (envelope-from fbsd) Date: Thu, 20 Jan 2022 19:16:01 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Troubles building world on stable/13 Message-ID: <20220121031601.GA26308@www.zefox.net> 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-Rspamd-Queue-Id: 4Jg4K43Splz3jZP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.96)[0.963]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3843 Lines: 59 The last few attempts to build world on a Pi3 running stable/13 have stopped with something like: --- all_subdir_lib/googletest/gmock --- ===> lib/googletest/gmock (all) Building /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o --- gmock-all.o --- PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -target aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wredundant-decls -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private -I/usr/src/contrib/googletest/googlemock/include -I/usr/src/contrib/googletest/googlemock -I/usr/src/contrib/googletest/googletest/include -g -std=c++11 -Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions -c /usr/src/contrib/googletest/googlemock/src/gmock-all.cc -o gmock-all.o 1. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:1125:53: current parser token '{' 2. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:58:1: parsing namespace 'testing' --- all_subdir_lib/clang --- Building /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenEVEX2VEXTables.inc Building /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenFastISel.inc --- all_subdir_lib/googletest --- #0 0x0000000004112640 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13 #1 0x0000000004110a84 __cxx_atomic_store /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5 #2 0x0000000004110a84 store /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10 #3 0x0000000004110a84 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16 #4 0x00000000040b4f08 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5 #5 0x00000000040b4f08 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:389:51 #6 0x00000000452bad80 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 c++: error: clang frontend command failed with exit code 139 (use -v to see invocation) FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) Target: aarch64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh c++: note: diagnostic msg: ******************** *** [gmock-all.o] Error code 139 make[6]: stopped in /usr/src/lib/googletest/gmock .ERROR_TARGET='gmock-all.o' .ERROR_META_FILE='/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o.meta' .MAKE.LEVEL='6' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' make[4]: stopped in /usr/src/lib --- all_subdir_lib/clang --- FWIW, filemon is enabled in /boot/loader.conf and the build command was make -j2 -DWITH_META_MODE buildworld > buildworld.log This doesn't appear to be ARM-specific in any obvious way, but it might be, so I'm posting here first. Thanks for reading, bob prohaska From nobody Fri Jan 21 06:00:34 2022 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 20B4F1952B8B for ; Fri, 21 Jan 2022 06:00:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jg7z41CD2z3jg4 for ; Fri, 21 Jan 2022 06:00:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642744839; bh=GAOEWxpFVhrTUBKvQp7Q+ZeuPFc4Dc2EJrQVmZqL+6E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FCRLEIjkhkCWHfRIEEymL0HQKZKF2f6XGj6X668BMVsPEAdJSijpQRvkOLLm0rc/IiDAK4uiwsz+9+AWlc3PRj2skonm5/Thb4noift0RX/Z0kWclbdnw89VhILYmLjqfg59xgQflS+bBDGeIzY5fe5ZkGbuYVM6Mmuuh0gTKmT2Nob939oYGtEJ7g2Le8WbhTRghOm+Bur+ipo1JJK8EKf211qtcmtxOZKmKtIPPGlxboj97PaPGIAQbUbloiKpa2Hgzmnm6WVGN4MgW+hxbLRFkEHaXjQ/ArQSCLrfm9kpHqBse/CKZAtM71HZq4TDvHEkrB/pJ7PsUwl1eQAfYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642744839; bh=Y4WxjrL70w2SLXztbaNpnicI8qy/sEFZGZqXMLgq4bF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nk4i5NjjXDZW5bU1QX+72iEbzyVmtp6CNQfFb9raKYr94YtxR6nA1PKDN1biZww6OLqzg3aVZAzIKL3FlDnbZe07i/SESVftGdLYuu058kZa5uicI8eSA84ZX7JpJzEkxvAbsIRB1O0kc/DPxh0h3N3UKVY8D9K0Cd4OgFRI3Fp2jJcVANsdGjNXHDDlIyXM6HA6ecJNL6VByq4J4nikiGB4I32zU7YBmnbpRrj39z2t0M1lWAbVpN+BayBZA3m3BI0eovL0oWuPpYcR7MeH93LI8TOZ4jkIfNla+eLHCJnTnLN1qffnc4ff7thVKWCbX8fiLn8oDf7sOuIAXkK3zg== X-YMail-OSG: M7Hj_0wVM1mxP40f6HFqTDPF8nE5Mz35OdcR8opZDFkAV0QRT4fwqk9LuKL3mSL 9Vm4EDDbpsTXLHQb6ugGLlu6vuaE2AY8485DRN8EMHHqjw9RJTWvELzEBHECYvZIgQs0buVBjpER 052pAc2xtFOCfEBRAgTdGY.e0xEgztAbP81ZQSQBQ7eCARHA7UDz9sh9w_6BoLm3.2WL8p7afNqc XeENYNE42gCZUltPzYysV83POS71jsk.A3YV_0vOSwUmqJSUef81b5IG3AtaMxZ10bL4IvOQulVS SzxLoto9wYIa7M0OrDqwWQ94oGDwQn1E6ewUC75MPLCQ0.p1TpgxjVQyKKzkz6gVIm7Yqw7UM9ZU biNCuTU0VvSilcJu.pI.AExDtiJpKA6XV4IXcJ1pKQVRIhZGUTHGzxSvPgTXHhnym4azj2AoqW1z p9zPKkdVI21Y9Zq2kV339kAw.cN7uIOpMl11pafsxk_w5TXAc1UkVzlaIWdKZ69LxYx4aSX9OFEE oWwmREnis0mW8MlGiDRIeTzGn1GXNQ.JPF_KmirO_gbamkAIJKhYSh7sUk43lzsDA_5pCjO1eavQ Los6qgrd8IggrV9Dnlcytx7DeJ5g672pFFL5y9pcTEVaR41XFDAhP9VAa6sFPqXuWx_WEQAl6NSB 3OWvmh3HF02twmrn.Sh64ufr_3uF3lVtsZXbrtJAExEuHr9X8NHa2wFoU__nGq5zDE7XL4dkHkKb .vVhRGC9NBGMwmgxeuvl0fOPVrapAhCLsMV7_2RN2T2AcKcuf3USG_4vuvX.TJiR7De2qBfOrbCV ZM9m3TbCYXTUEKxkdQ2UIO0l7xr6sIUTosfYvcRqyXTnAwrdgOTa09bR.w1yTDPqzKD1qb8VbpNl 32NnyF2e03GT5vgzFi5OXZMKK1.Koap6CGkG1DxLHb9JkkghSjJiTT5TqyEZ.jQ8a7kUFwT1c3SE wJq8DLGz2gbB74PjLXyxUtlXdPqNQx136ObIgaUCtukjkTwefr51RX.PzQ9F8uPMh1rgDZZt8n.n 507rTyrs6zxhqxuaCa.pPbiGlyidswgq71tErj0LgqVGISNUpFIsknJP.Sc3Pjr6h9Ah8eLizUQ5 gqOU0LWQPkKz8oWpPD7U5HjgHI63DvNEB7BMgBHYUd4TSN98_oRMYTLsro0RHo0Sd_oIEHZK6mF8 WBxA0.hgwo0fTX4xLoazFffqMmLHPun2_4W162Ad3WpxFlSgA2j4mFT3Jun4dQ7JmNVQrbsJMLFt CQcmztSKov90mCH7jX5WiM9tBn41X9ZmuzF7lYzZJITFc3OSacPh2SUS2wo7tMOnweoi6H2EVb_s BmrdVIyFcgmH9vCjAOy6PlKoZ70C70wwmG6RMbbdg0al_zpbTCNUp_AtJZJs1udjk4rBdh.hhpax Csy9wDxuV_aeCAyMQecNyk2Ou1Motnx4FMeWHsvzeHRf9nexChUOE0f.axi54o44PLltEFwYJ6_8 kpvHIUOCsQT7tAOEjXZVxPxV_mh0bbzUAFMFPNL5gBKqcV1zCZFqQeiYJ6n2z2_Sav6Bs1_ttulb LWvcX1fawXloPNcIHQRiG8GpR57_w7D4Z3lq5eOqLn5DOgjZ7FZd29Wa6ivBkpGI4oCmYOW2kt3_ J0Ckuae51tGeTnMyxGeX5fX2Ubz6MUtJ08JMmaebQldIdV5C83fsIecQTm1rG9ASzSuUtkIemUdx Jof6pNhX_n5JpGVbtDlDFpSgliN0CXv35Y7dTFqbOos6zQRgy5gtb1K2k1D69LcbjXzzMGJxvo5j xai_HUZTxPijd1D3CHkehpWKX7PY8ryiAunRQJ8C7n3nn.TzbSFibmAioWPb30re1sKoFzegdyzU IR.2pxkxEkEEzz04MoquSPjgFoBYbUDSRWqwsbH1Xmv0L3Jzk2eq5qxC4ABJ.sGdxOwZ9jUgfsJ6 IAecuoEtFWvEWOLM7HlRYN4vhxbNmEXnOB2D8_y0WVy1WP7itI9mv8E0WqQJrRpV5UID4juryyz9 fPV0J4ybRCTb9bVTY4WSwYR7zsU.i9T.SQ1fD343gwA5FTryYpVUQR_fvhTPShnRxNlOZl1YDMcr uNo3H9uGkQ2b.JIr7X8OEW_9CwJI3VIa46XBGJln7Rkxb__IyIoq8A211P1XjBm3T2ICiMAbDIJO pj5UBH.QRF8LYRxhIpTc70yo.aB3FDIbN82UBPuJxkt.4I82R9Lcro8S.iQnB6frAxrM20Py24j6 tP58n4g.Rr4xCzl_SV1dBBg4I_yQaCb_82hBQxfbu8pNOMm9t0B0KXZ90eJz1l4TMrzyIp0kOk6G iy3oqC3y2FESIEQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Jan 2022 06:00:39 +0000 Received: by kubenode544.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 73c879b6bc2c31308394ef6ce90d3445; Fri, 21 Jan 2022 06:00:34 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220121031601.GA26308@www.zefox.net> Date: Thu, 20 Jan 2022 22:00:34 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220121031601.GA26308@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jg7z41CD2z3jg4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FCRLEIjk; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4639 Lines: 125 On 2022-Jan-20, at 19:16, bob prohaska wrote: > The last few attempts to build world on a Pi3 running stable/13 have > stopped with something like: >=20 > --- all_subdir_lib/googletest/gmock --- > =3D=3D=3D> lib/googletest/gmock (all) > Building = /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o > --- gmock-all.o --- > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. > Stack dump: > 0. Program arguments: c++ -target aarch64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g = -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers = -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith = -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow = -Wunused-parameter -Wcast-align -Wchar-subscripts -Wredundant-decls = -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable = -Qunused-arguments = -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private = -I/usr/src/contrib/googletest/googlemock/include = -I/usr/src/contrib/googletest/googlemock = -I/usr/src/contrib/googletest/googletest/include -g -std=3Dc++11 = -Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions = -c /usr/src/contrib/googletest/googlemock/src/gmock-all.cc -o = gmock-all.o > 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:1125:53: current parser token '{' > 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' > --- all_subdir_lib/clang --- > Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenEVEX2VEXTables.inc > Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenFastISel.inc > --- all_subdir_lib/googletest --- > #0 0x0000000004112640 PrintStackTrace = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13 > #1 0x0000000004110a84 __cxx_atomic_store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5 > #2 0x0000000004110a84 store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10 > #3 0x0000000004110a84 RunSignalHandlers = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16 > #4 0x00000000040b4f08 HandleCrash = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76= :5 > #5 0x00000000040b4f08 CrashRecoverySignalHandler = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:38= 9:51 > #6 0x00000000452bad80 handle_signal = /usr/src/lib/libthr/thread/thr_sig.c:0:3 > c++: error: clang frontend command failed with exit code 139 (use -v = to see invocation) > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg:=20 > ******************** >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp > c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh > c++: note: diagnostic msg:=20 >=20 > ******************** > *** [gmock-all.o] Error code 139 So: SIGSEGV (signal 11) > make[6]: stopped in /usr/src/lib/googletest/gmock > .ERROR_TARGET=3D'gmock-all.o' > = .ERROR_META_FILE=3D'/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gm= ock-all.o.meta' > .MAKE.LEVEL=3D'6' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' >=20 > make[4]: stopped in /usr/src/lib > --- all_subdir_lib/clang --- >=20 > FWIW, filemon is enabled in /boot/loader.conf and the build command = was > make -j2 -DWITH_META_MODE buildworld > buildworld.log >=20 > This doesn't appear to be ARM-specific in any obvious way, but it = might > be, so I'm posting here first. >=20 "uname -apKU" output from the building environment? Commit identification for the /usr/src/ for stable/13 that is being built? Any console messages? dmesg -a output of interest? /var/log/messasges content of interest? Any messages of interest somewhat earlier in the buildworld.log ? Does the problem repeat via using the files: /tmp/gmock-all-836ef8.cpp /tmp/gmock-all-836ef8.sh on that RPi3? Elsewhere that has more resources, such as more RAM? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 21 06:27:46 2022 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 CDC011968861 for ; Fri, 21 Jan 2022 06:27:50 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jg8ZF4wvwz3wWb for ; Fri, 21 Jan 2022 06:27:49 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 21 Jan 2022 07:27:47 +0100 id 00DD6044.61EA5263.00003B0B Date: Fri, 21 Jan 2022 07:27:46 +0100 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Trouble booting RELENG 13.0 on a Zynq XC7Z010 (Zybo-like) board Message-ID: <20220121072746.6e530a87@zeta.dino.sk> In-Reply-To: References: <20220120235128.0e7fb82d@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git329 (GTK+ 2.24.33; i386-portbld-freebsd11.4) 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: 4Jg8ZF4wvwz3wWb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-1.32 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.980]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 704 Lines: 26 On Thu, 20 Jan 2022 19:22:33 -0500 Lee D wrote: > On Thu, Jan 20, 2022 at 5:52 PM Milan Obuch > wrote: > > Hi, > > > > how is this boot loader made? All Zynq based boards I know about use > > U-Boot customized according the board's design. > > Thanks for the response. I've fixed a couple of problems, and gotten > a little further, but the kernel is still crashing before it prints > the banner. > [ snip ] > Now I am to the point of getting another crash, with no panic message, > that dumps me into the KDB debugger prompt. > What about 'bt' output here? Knowing where the crash is occuring along with callstack should help abit... Regards, Milan From nobody Fri Jan 21 19:39:09 2022 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 B3C581969B1E for ; Fri, 21 Jan 2022 19:39:47 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 4JgV825c1Vz3sTC for ; Fri, 21 Jan 2022 19:39:46 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot1-x330.google.com with SMTP id k13-20020a056830150d00b0059c6afb8627so10851430otp.5 for ; Fri, 21 Jan 2022 11:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nShQec5R6OUc0bwN6oHjj+kaehlUXGkGxh+wNtPlq/s=; b=gMDMb9qWG+GvdCW8PZzTUm+HRvPwA9lv3zUmHs55K6bdGSkmx9eHuBxeVW647oG0l5 7npETJJG50tBJyf/oMlJd6pbyvvTgOZBSMmN4jH06OssdKaMZcVatoID0/LsmGuTfezB b1iGd5XlVXNsVzSPSqI+mexlpMUc0fJpyqAangxdmJWzFiRSXkXwLa/8uCAYtcAdj/q5 76hwPx0ZU7qLisXMG8xiYxThJieMDhTGw0cKfP3Bx9LZyCI5d5uAWZCHE3U5JEdAbsKM tNzfvfp2UM3WPoQjkmOZ/14VDypiYVxu8pPDaRBX7l9mYcpO96QyA7qFWM7khCqAiCYq SPkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nShQec5R6OUc0bwN6oHjj+kaehlUXGkGxh+wNtPlq/s=; b=N28V4RWIIlaUFB7JUpz48sULUirxDORrrf4oxXKvd1CEggSl0so3qdaNIPO+Y0GZ8E y5ki0mH9CIz4XI0oxreakC+LmeGbmEny+DRqgvSsEOiGveSnF/c0n/49cT1dOsqQc8iv 0wvfm+B/v8jyT9e7L54makJkh+IzcxvaMd55Vbg7bdvV706KIwryIpP/xkP+OgLIUEcI hE53muEk/qxKtCtCQmDPIuY6JZhkN7nJA9Q3c8X0+beVlp+A7DJAc1cBAQKZXxoCYNav OiyJL9x+Xzx7dBvRfaLytngr5wuQOueswaUCO5rkgvB/A8KcnJ0ht4m15LsVOB5uMT6f uCyg== X-Gm-Message-State: AOAM532yTDKMblWFa4I77cNRT0C/QYp75fxQuPsiTdCHN9MU6fJoQEmu 27GHlTIiwqGYh4jubxrgh9mfLega7cBu7/oHg16+8+hUWFU= X-Google-Smtp-Source: ABdhPJw3nGX5/kQjQdUKPegwZK/t6tjo+9pBRxbCQ/UbZHsSS1VKa0Fnur5DTYeGTImS4t3cmoAclqvN8vkS1nuvHwY= X-Received: by 2002:a9d:53c8:: with SMTP id i8mr3964116oth.166.1642793985898; Fri, 21 Jan 2022 11:39:45 -0800 (PST) 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: <20220120235128.0e7fb82d@zeta.dino.sk> <20220121072746.6e530a87@zeta.dino.sk> In-Reply-To: <20220121072746.6e530a87@zeta.dino.sk> From: Lee D Date: Fri, 21 Jan 2022 14:39:09 -0500 Message-ID: Subject: Re: Trouble booting RELENG 13.0 on a Zynq XC7Z010 (Zybo-like) board To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JgV825c1Vz3sTC X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=gMDMb9qW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of embaudarm@gmail.com designates 2607:f8b0:4864:20::330 as permitted sender) smtp.mailfrom=embaudarm@gmail.com X-Spamd-Result: default: False [1.98 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_SHORT(0.98)[0.984]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::330:from]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-arm]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1432 Lines: 38 On Fri, Jan 21, 2022 at 1:28 AM Milan Obuch wrote: > > What about 'bt' output here? Knowing where the crash is occuring along > with callstack should help abit... > > Regards, > Milan > Typing bt at the KDB prompt does nothing useful. Depending on how I have the kernel options set, it either produces no stack trace or one that is limited to a couple of functions inside the debugger. I was tracing through with xsct this morning, with conflicting results as to where the crash happens. It's somewhere either in the call to dbg_monitor_init() (from initarm()), or shortly after that call. Sometimes I can get it to crash in dbg_reset_state(), but other times it doesn't crash until later. I think there is conflict between running the xsct debugger and FreeBSD trying to configure the hardware debug registers. I think it is wiping out my xsct breakpoints in hardware. It still crashes even if I don't run it under the xsct debugger at all. If I don't include "options DDB" in the kernel config file, and just include KDB and KDB_TRACE, it doesn't crash until much later in the boot process (due to a different issue). For now I am pretty happy just excluding DDB from the config, but I'd like to get it working eventually. As for my earlier questions about boot code, I was looking through the src/stand directory, and found a lot of useful info in there which I am going to explore. Thanks, Lee From nobody Fri Jan 21 20:54:02 2022 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 93A0B1970C98 for ; Fri, 21 Jan 2022 20:54:16 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgWnz0nDgz4qd8 for ; Fri, 21 Jan 2022 20:54:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642798446; bh=AwnNm7W1yORi+Hg/F9Pgo88sOSO2JbyC5KwAQjJbfrs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ECEhKFxerCFAI3QeR/KRknPjlExe9+AEmdQBN/jnH1cRKiO0RRQk+d0W01ENdwdAIEjyDzhzS2mIVS0QZYhDXbSLl1sXOHRbmkfv1KfzayX/jH5YxeHP6zlorKucSZyJrf0Z7wwz/73CFB//SXCRdagxck2OuSHOPtuMiuWAtDFB8+6JZHWBSfX0jFybyB6sYL/TCHyhhN+EQWBEXsQ+jHkI0jG0iYetik4iAdCnhHvHRhe65rTe2SgOaOFvM1yzpVoX8whxxk7uPNEH1Vxcelgim7UW6IEzGGiBkdICjDji6E78/71Rsj3bFtqbWzKsTYWckRQN+qlVg4umAK24NA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642798446; bh=bkhOiDzNMlGbch5Y7z+vyWpHVmrNzC+eAuIXS+wlm2j=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bXVty8P1Ibhm8VW+547Srcb0/afL5H8fo+d+4N0jAK+jEfnvSzIjDQ4VJDG3iUZLvdX3vLmPetJlKbHNwfuve0rba2PmXAR40v3B4D5ML5dmEhye9oz25h2KQhKAyKfMSSU45HLN8gVlwHJFc1mKcRtP5f8HoYgB1qPyblu8qCF5xMnfw3MKMEuZMepwXbnFnAaBG48MMP/Qg3E5vmbCuIwzKeqxvc4CSo4n8CLUEPcUGv9N8w66oGHEcpVtZQt8zkdVMDCBNZgoieTyBB1IORJ5xAmHUbzK1vGZTy9Td/pN685xvjNStqd9K3x8pj6DwaWOpeX7DNnkLVLF+doPpw== X-YMail-OSG: BM7rsUQVM1kPaalwP4tGmHamnO5Dx6iiDM7q1DD5JAX3cwM.xdyLKVzmDDIc7UK ScnH5zy4PmCuFQV7MRyU_YJh1gyes8m_9eFLPB5pP7eHGS3stX6oopdYhb3badsRyAIUf3Xv0iNH GqPrEU9IRmn_yMCERPbY3QILcie8wsmZqk.G8LZE6j.337SFFMgnLzZPUfSUGdtWO0XfQNARgepB .YkLrGBK.vkj_5jVUcTy9ei7n_f1G0Elymv3zLlWtPwh2.WZbxRlB8neHnlPE3xNyI62py1lOWHu _AaxfGcRGD_NDoVbL6xR45g5QE3vVO1rWKKh0z81LvFRUV_u8eszGdJmYHigU4vL6qDs2.xRbNxC rMymQiDbyPAY_jNT9ZJYLBTD1zptTNfAFSIseji3Wt65F47bcXoYiOp2sYjoiAQhQXxhOw1rYSOV u.bQIzNo_jOlGaKPdWzS3GIBzULWgLBHw2XSE.r17339_u.RGDqn1SlIR1mW7YHHqRCdebfM.mu9 IHMluvvFxSp5mZuuvibEJMOTOYRXyynlP4_AKyeXrvEWNt6G0F6sBqOb70h0NTign22NAhAg_QiE UL3IqB_u2kEiCysP2DTetUmQjVDBnU9wm3RCwWHpW5arXM8SfgRzyazs5CRH8maCUlwqyJbnWgkM 67UlteFdfdDtU3iODMblvmN72nuU8QQVuISMeFOI4PgK3fQfiYo2eMqy1uIv4QMxrmDIJKVeHEai Sa2HGUc_kQDteO1JZzD4EcRgYROp0N_GIsaJrAEd6UO3NSQoHyj6HWtWUsSmnMQT9fV0CTe0kHbo HlMgVGtO1lnIEwJjNFZ_ITjx5PGvRS.6MiSqcm2Mhcnsd9Q1QQKa829ktP0wRqAmZwGbqX_xevxU PyyU0kxBOFLGSDgSFJmqOvn0x9q1cATq26sYzvMKipY9PAg_bVonooJBiVSq42.zHh4YA8AgZCAy DmJM8P769a7FRpY5qjMJ8rh5K9jbJbWpJQtxidvTCEUotKaGQvCLc_RhtL_oupjBfPQO0PZJKFlG Ge4p403vRzJrkIGQRbXds9B0DBlp8UF9UmpPDz90vL9dDfLe3Z6bYFVfR0J1oiJmutbrjIrKSAJM eyLjF3SAUOF9IyU19K51EWew9Ma20r2mZdgdVNm_.swt1WXd4H9QSra9ds78jfS7iGbGrM2_j3O2 4vCUHEB8wmGLcUISdJ6.sE4Cp179Kcp0tASkj5aAIWDdBqOZFDWJCKs9lrp2yb68w4HJgYM8G6fL DtnviAMYrFaUfDtuLi7mi044_FEbAc6La_djUPYYCGIPP.ZSql1QJTROR4XP4TRNbejk.co4KSFm x0jyyvLfi1vLmYhe6Z4S_M.XyRn7pa7Q7G1tYlGR4VNxS.NTtgJszY7cXqSmQFMejy_xKKq5YgLW Uj2GfNx_O7TzAtoEr_nYN8C6wxXvthlFe.xWvt_dUVm2obXT7QsRHFFJztAEe17DINfT8M5zKHgX x1vvWJ5KGlqnHswRdaYeHvmV20fWgU.UAs4sHTP8H_NGxSbOZbFLrA3CMjHyg4zPbcDzk7IbA5zn gywYF5j6KYpqhCx_RRbz2reHLnfeNn6zf3JUHVnN0g.ib_f4YtD8owT4GNJh7o7RX_lw_SlaTHyA 6naq67GOunvJ3URVOcW2CofYNWfOW2SDvQfPvcE5PbEkYx2y695sYECNffWgavP_whVciNT_FaLp GQ8pevI4ENDfEk2Pe4zPHMehGD0prv58UQqJ9QyQCbWv0yIKxHOulOl6b.8oIGJydiCeqPXqaamf wShSQ_61QP.KePxUApc.r4JM7Bv4TjhNLQJM0IlmUGp2KiOsO44g.bU4TD77Kq_2w0TkniPgDwf. i0wjHLRKLYq._9vCNDerEJib6oxa6vSwZbMadbeQQtOl.d1_SCSdWnQ1BMGqdxRYcgrGQUnBKrgY .TNFVgbEKQVNFxbp.3exvcud8pBXWzMWBd7YAPsp8osNTwRZcBFMMDY8Jptx_yIIKgRpv84ig3vX CjUgU2jQhSEQRZ0DSj4MbAx3A_gfoSYNx6HnWJ_DMjLi8aTHu8iABA2SA2AVU5rbiY531fgEmW2T Bj3Ibscc.Bv32QFJ2rws1eOKkp2Kam6TOSwf5ZgGZO0amiU.jNwchdte.P8k2poPOl0YXBY_sVvk .A06.hSW6qLTpPfBUKKvT.3k09ntJ8dymA5IVoXol7g6UNUOY9OG_AAOuFPj8U0k_PQoZ565KzKr zI6_QC3jtvvnO9wMZ65NKojiqCZ35BSHR0OjPFCm7s.HksYsq6l42dLBzDkAz0Jg8Hx7p2ykO6Hb cCFCLvfNIhrHv X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Jan 2022 20:54:06 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b921cd52aa36f5b3d3e44b7b4e3769c6; Fri, 21 Jan 2022 20:54: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Ping troubles, was Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220121163445.GA28761@www.zefox.net> Date: Fri, 21 Jan 2022 12:54:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2CABF256-CC55-4449-80CB-A3DFF9B4B7A7@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <20220121163445.GA28761@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JgWnz0nDgz4qd8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ECEhKFxe; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5851 Lines: 182 On 2022-Jan-21, at 08:34, bob prohaska wrote: > On Thu, Jan 20, 2022 at 10:00:34PM -0800, Mark Millard wrote: >> On 2022-Jan-20, at 19:16, bob prohaska wrote: >>=20 >>> ******************** >>>=20 >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> Preprocessed source(s) and associated run script(s) are located at: >>> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp >>> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh >>> c++: note: diagnostic msg:=20 >>>=20 >>> ******************** >>> *** [gmock-all.o] Error code 139 >>=20 >> So: SIGSEGV (signal 11) >>=20 >=20 > Aha! I didn't make the connection at all. >=20 >>> make[4]: stopped in /usr/src/lib >>> --- all_subdir_lib/clang --- >>>=20 >>> FWIW, filemon is enabled in /boot/loader.conf and the build command = was >>> make -j2 -DWITH_META_MODE buildworld > buildworld.log >>>=20 >=20 >>=20 >> "uname -apKU" output from the building environment? >>=20 >=20 > root@pelorus:/usr/src # uname -apKU > FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #6 = stable/13-n248948-9418a626103: Thu Jan 13 12:12:06 PST 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 = aarch64 1300523 1300523 >=20 >> Commit identification for the /usr/src/ for stable/13 >> that is being built? >=20 >=20 > Not sure what's meant by "commit identification, hopefully it's = somewhere in > the uname output. Git status reports: The commit-id 9418a626103 in the uname -apKU output was for what you are already running. I was also after the id for what you are trying to build. I have multiple source trees around, one for stable/13 . I use: # more ~/fbsd-based-on-what-commit.sh=20 #! /bin/sh branch=3D"`git $* branch --show-current`" \ && echo "branch: $branch" \ && base=3D"`git $* merge-base freebsd/$branch HEAD`" \ && git $* log --oneline --no-color $base..HEAD \ && base_date=3D"`TZ=3DUTC git $* log --format=3Dfuller --date=3Diso-local = --no-color $base^..$base | grep CommitDate:`" \ && echo "merge-base: $base" \ && echo "merge-base: $base_date" \ && git $* log --oneline --no-color $base^..$base \ && echo "n`git $* rev-list --first-parent --count $base` (--first-parent = --count for merge-base)" like so (for my stable/13 source tree, your path would likely be /usr/src instead): # ~/fbsd-based-on-what-commit.sh -C /usr/13S-src/ branch: stable/13 merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f merge-base: CommitDate: 2022-01-15 12:55:32 +0000 a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore = debugger-injected signals left after detaching n249004 (--first-parent --count for merge-base) > root@pelorus:/usr/src # git status > On branch stable/13 > Your branch is up to date with 'freebsd/stable/13'. >=20 > Untracked files: > (use "git add ..." to include in what will be committed) > buildkernel.log > buildscript > buildworld.log > installkernel.log > installmmcscript > installscript > installworld.log > mmcscript > poudriereupscript > poudup.log > rpi4script >=20 >=20 > It took 2.17 seconds to enumerate untracked files. 'status -uno' > may speed it up, but you have to be careful not to forget to add > new files yourself (see 'git help status'). > nothing added to commit but untracked files present (use "git add" to = track) That output does not include a commit-id. >> Any console messages? dmesg -a output of interest? >> /var/log/messasges content of interest? >>=20 >=20 > Nothing obvious, in particular no "killed, out of swap" type messages. >=20 >> Any messages of interest somewhat earlier in the >> buildworld.log ? >>=20 >=20 > Not that I can recognize. I started to put the buildworld.log file on = my > public webserver and was surprised to find that sftp didn't connect. > Trying to connect from the server to pelorus so as to use get failed > likewise.=20 >=20 > Next I tried to ping from the webserver to the stable/13 machine, no = answer. > Finally I started a ping from stable/13 to the webserver, at which = point > the opposing ping session woke up. That seems most strange. >=20 > With ping running once per second from webserver to stable/13 usually = a=20 > single packet is returned. Starting a ping in the reverse direction at > 10 second intervals _usually_ results in a single packet reply; = occasionally > none or two. It isn't entirely consistent.=20 >=20 > Both machines are on wired public networks, so between them there is = no > NAT involved. Packet losses correspond roughly to rate; Most of the > 1-second packets are lost, most of the 10-second packets are answered. = =20 >=20 >> Does the problem repeat via using the files: >>=20 >> /tmp/gmock-all-836ef8.cpp >> /tmp/gmock-all-836ef8.sh >>=20 >=20 > Not sure how to try that, but it seems to repeat on a simple repeat of > the buildworld command. The .sh compiles the .cpp using the options involved when the failure happened. Copy the files to an appropriate place and then run the .sh script. >> on that RPi3? Elsewhere that has more resources, such >> as more RAM? >=20 > I've only this one machine running stable/13, but a Pi3 and a Pi4 = running > -current don't seem to be affected, nor do several pi2's running = stable/12 > ARMv7. System-clang is 13 on all those for now. The .sh and .cpp test should be executable on all the machines. > The troublesome machine has been updated many times using git pull = followed > by buildworld -DWITH_META_MODE. Might it be necessary to occasionally = run > one of the cleaning targets? In other words, could META_MODE permit = obsolete=20 > files to persist across builds and reboots?=20 >=20 I only rarely rm -fr in a build tree area to start from scratch. Nothing wrong with such an experiment. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 21 23:32:31 2022 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 B4224196F58F for ; Fri, 21 Jan 2022 23:32:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgbJs4GzGz4qv9 for ; Fri, 21 Jan 2022 23:32:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642807957; bh=7h963wp9bvRsxOhi9Tp35lIqdjYr6vP02eeb9EV13ZM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CzW8IPRv30obbsMM3L1g5PGmptLE8x6NwZk0mHLc4BYezlriuhJmV7Cs/k7ql3mXQkLQ0XrDR5l6pzo1xOILoEzZvN/nzAZ4XavacL19L6uNCNRlc2/ymit0eVut8jxsd2z8Hk0eIR2PRFtN7RjFLrfceZn+G/A7LSluIQHGAYkcNxDb/3mE9Lx8cJxZp7rRI0jX7R6G54/EvWOLiN40YURblF2J1GUZvr8riUI7AHKTEwsBiOANNCkKRWRRkYUGYA6GhkS5yC7Z3jCp6SwZoB+enEOTaGwffSzHm7uwHfdxiFHaMs6bNGDYwWdzGvHfV0Z1AW0zSlLsncJMhebIwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642807957; bh=6+qFLfccbVPmYnXJnK9Ik3PG0TuwKifPIh+cr9O0T/e=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fQpi+4CgL+hREOOsiRQsKjq0OoOrGDvnmbV5q4b5+ACfx6YYeTb9+AF1ghsFBcQACn+EVbyMebf4hA7+SW8CyH/lUNmiPsNOxbn6NScbtaUM57ByW1uNratTxpSfQYrHOrvbJSc6CPgBWHF30zg2CRToe3hXrYkQxj+nhE7ATyB0ojg///4K3YycV23EJ/n7jjoyX2mPIze44R6o7krCxH2ti9JIcxGjLT8z74JX9XpGDFzA4QnMEMKj+c0IjCnc+1y75vonSzeqN3Gp8rJRqFcpKxo3k4sJBzlgaFun6ca1njcvxbSsuVdZxCi7rLIw05idVLCIIy6xWGn9fUiS9A== X-YMail-OSG: oYae6bcVM1lGxV0CnRxr_fWF7eZy6NMegWRLeFopVIXZwbc34_F3pq6Ik7pPULs SYgZ0aLgsKdYx2pHqSyERxNMzr51UdmWNhelGOnBU1dqdxxgbYz353.oBWnr6YNujrIjZVN5d6Jd GeUwD63stjJoFs7cOAzum0_LPPQeogMELuwZmjcNHTSonJyrN3Z3kzY1dqsWR_FS8v7fW0yTO5Nx NehcXSC5amn0gJOAuLRuTlDb8VVrjVNb4_sUAKtred63SvXQSy8EcZ_Xe5YXJXIvHI8AF94xsRHM 5VW3EqtyAggT9XD_64wFenF6sIb9SsYmeI24G.36mqBYKIgoof.7T4marc1T3qu8JX1QvhUWGPuj bfRAttb9.Z9wpgP2Azl852jP4CR6qW2yFjBtsk979JQ.PY6hCbZ3ZvdEykUdAwM82tDHvUB3n4_u qJnN13610kdFvQPoc42sV89RJUhiV9zw2eQvnHsmSEpmd.2jBY27xzaI8noAlAbIF1zcBraf4sv5 eOA5ZktbhXPJ2tfjDFzRO9d492eUhHsZPqYHGxzVZJskFYItjhlfMZb0orGArepPgq1uBod7HOuG LwRbZZGMuXJqc4_m_vFyZVRiBHkpzQi7oUj8u3fnc03odee35j8a_vT6gUA6TVdM1EgdPKlgq2Tg L_p6.584.f7.pbW2R7qtIkKiE3QyckbN7HjejtgzV_3sb4lttFjRw12azujncgKFR10Rl5awIkYr 7uiKrf3SquqU35FRJ5QJicfkovPsT3J31URX61JV5TPorKWEbt0cwyGUXz.wkgmVogCnNdtzcwp0 i2.EpC.ly9JZxsSLp3v_Uua9mfQyTOkfhibjJuvJxSPOusWcl8Vi0DnjfiFsT.ErngFCTyfyYnzn YEwHxwgPJwU3kFD.K8QxkaayZDOFM39QgQOVzaHsAjIGEtXJ1hH.irI149IjTKLi9ACidFkb6w4c vn29P9UVzdTCaDOEiky6SWLzLlFmSTZgnLWun0dMCoNwTNg7Zl03HrbTSZlo_OUMxAykySdl9f_q 5Ovo2Kn2BsB.k1CeESBpYLG2mJwK5BOSWt56ipDxYTUTOS5JynhMBvb3aHVjp85b9tXJWICAwi4G QkQMu.hPGY_asTe_sGOYw_.FFSJyAeXiNVI4CCCK7lNi0dlyC65Ldwiv.WQPawVO._EMr0NF3VPV RWJWj3n6O0syPGJex1deuXgB9T2on8F56W_VuCtiRc8qRQ5FxSpUgNqG4rgOMrppDaQfW9hsTcHa vmFM2B9pQ3rq.tktq88tOC.7OFLjWvulPJXBAurJCX1eujSQwUB8PxzyLk3uYko4dUdHMkxs0cHv q3lrtSp8spdMkFKx5tqFbsI_2wuLES3QHgskxGeXapO_qsFmnwc2Rhvfwecdyy2Ky27x2U.mEZWS vZeCh_fpYNSrIeunWiLaP7IQ9Hc0W0dYDunKfrcsXLXzaWqs1t91EQgYykM10tHXQLnHtzSQeRRN kJrzIzjF3c8VG5q4b5r0I._E3MJjoMPRxhurcqybF2jO80zk7P3MtxblqBPC4nBSqfwTnEymZuuZ .AEIfV53WCZZGN9Y7dGcVKHaWRoscJI820WumPEdG3pAeD1ZjfS522Exp9Pm7XRMPA3xVydPlfGw C9B8nOZKg1X1GTW5GICVgcVAKKE.t_kviNKioQ2jBLoqaBo1WoUtoI.naWVbHFkceJYbA7227HjY kyk64ubAaTbrKklrcYoQWAZRI.J7zaV.XZeSKy3gbdF2qyPGqoahmHSacJwLG25.nWR_s7xFeAog SZuZSdkiaXcCbPukXOc3WujFL0.w5GqA1TXIJtbrTUdpm20l67X7cStZagKW8yt8jlzSPhpPSPxv ONA4SRJ4V4BVc2h1b5NLTO8c2AwvzPaun4lcPQJS.dX4tjUI4Fser3Er1XcQRJOrtW8SyFYZUCBX aGZ53XtUhp2SiH21RQXS8KE4FQLKl7K51feigV4rhuPzMa_qIXlgjQHIuLhJc1DKmN9_KxkDdFgS W_QXSm9GNgClqGafxBll5xllvtSZIbZ1Fyp3UUECsOJcKc730Rf3TOoIuM0zziKGN_nw2XR3zyE. c5f7gaVwt6bAISCdffxmvRL8naqa7d2Z8OJwB7At7PpigPtGCjh8mhdtHeHzudgN_CrGQX2cTK7R lt9HoeBlFpX2.LCbqA_.avBF3YgAriRF.B9R.7k02Mu8S6j0y2le7.T_qQM0UUkMHOxR9aZPHjHJ qzjHH3o7joW3T19tXsli8UAJmkB0rdGyClYkHLKo19hFVaQoXc1Z2xNbV8zSiGlgiGAIOspHjHbo gj4m79d8s9f2F0Ag- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Jan 2022 23:32:37 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 029fcd5885007ae40f9513c2aae8ca7d; Fri, 21 Jan 2022 23:32:34 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Ping troubles, was Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220121215740.GA29220@www.zefox.net> Date: Fri, 21 Jan 2022 15:32:31 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220121031601.GA26308@www.zefox.net> <20220121163445.GA28761@www.zefox.net> <2CABF256-CC55-4449-80CB-A3DFF9B4B7A7@yahoo.com> <20220121215740.GA29220@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JgbJs4GzGz4qv9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CzW8IPRv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4721 Lines: 145 On 2022-Jan-21, at 13:57, bob prohaska wrote: > On Fri, Jan 21, 2022 at 12:54:02PM -0800, Mark Millard wrote: >> after the id for what you are trying to build. >>=20 >> I have multiple source trees around, one for stable/13 . >> I use: >>=20 >> # more ~/fbsd-based-on-what-commit.sh=20 >> #! /bin/sh >> branch=3D"`git $* branch --show-current`" \ >> && echo "branch: $branch" \ >> && base=3D"`git $* merge-base freebsd/$branch HEAD`" \ >> && git $* log --oneline --no-color $base..HEAD \ >> && base_date=3D"`TZ=3DUTC git $* log --format=3Dfuller = --date=3Diso-local --no-color $base^..$base | grep CommitDate:`" \ >> && echo "merge-base: $base" \ >> && echo "merge-base: $base_date" \ >> && git $* log --oneline --no-color $base^..$base \ >> && echo "n`git $* rev-list --first-parent --count $base` = (--first-parent --count for merge-base)" >>=20 >> like so (for my stable/13 source tree, your path would >> likely be /usr/src instead): >>=20 > Thank you, the script reports: > branch: stable/13 > merge-base: d7b156672a48c37e1b8ce9b4ae28a46ecea55412 > merge-base: CommitDate: 2022-01-21 15:58:11 +0000 > d7b156672a4 (HEAD -> stable/13, freebsd/stable/13) zone.9: Remove = documentation of non-existent NUMA configuration flags > n249092 (--first-parent --count for merge-base) >=20 >=20 >>=20 >>>> Any console messages? dmesg -a output of interest? >>>> /var/log/messasges content of interest? >>>>=20 >>>=20 >>> Nothing obvious, in particular no "killed, out of swap" type = messages. >>>=20 >>>> Any messages of interest somewhat earlier in the >>>> buildworld.log ? >>>>=20 >>>=20 >>> Not that I can recognize. I started to put the buildworld.log file = on my >>> public webserver and was surprised to find that sftp didn't connect. >>> Trying to connect from the server to pelorus so as to use get failed >>> likewise.=20 >>>=20 >>> Next I tried to ping from the webserver to the stable/13 machine, no = answer. >>> Finally I started a ping from stable/13 to the webserver, at which = point >>> the opposing ping session woke up. That seems most strange. >>>=20 >>> With ping running once per second from webserver to stable/13 = usually a=20 >>> single packet is returned. Starting a ping in the reverse direction = at >>> 10 second intervals _usually_ results in a single packet reply; = occasionally >>> none or two. It isn't entirely consistent.=20 >>>=20 >>> Both machines are on wired public networks, so between them there is = no >>> NAT involved. Packet losses correspond roughly to rate; Most of the >>> 1-second packets are lost, most of the 10-second packets are = answered. =20 >>>=20 >=20 > I take it the ping behavior doesn't impress you as odd? I thought it=20= > most strange. Odd, but I did not see how it fit with the original problem and I'm unsure what to comment on about it directly beyond our earlier ssh related exchange, where I'd noted for the icmp_seq values in the ping output that you had then listed: QUOTE The way I read the below, icmp_seq=3D0 and icmp_seq=3D1 took more time than icmp_seq=3D58 and icmp_seq=3D117 and the like. But lots of icmp_seq values did not complete a round trip. Also: 58-1 =3D=3D 57 176-118 =3D=3D 58 235-177 =3D=3D 58 It looks like the start of a pattern already. END QUOTE. >>>> Does the problem repeat via using the files: >>>>=20 >>>> /tmp/gmock-all-836ef8.cpp >>>> /tmp/gmock-all-836ef8.sh >>>>=20 >>>=20 >>> Not sure how to try that, but it seems to repeat on a simple repeat = of >>> the buildworld command. >>=20 >> The .sh compiles the .cpp using the options involved when the >> failure happened. Copy the files to an appropriate place and >> then run the .sh script. >>=20 >>>> on that RPi3? Elsewhere that has more resources, such >>>> as more RAM? >>>=20 >>> I've only this one machine running stable/13, but a Pi3 and a Pi4 = running >>> -current don't seem to be affected, nor do several pi2's running = stable/12 >>> ARMv7. >>=20 >> System-clang is 13 on all those for now. The .sh and .cpp test >> should be executable on all the machines. >>=20 >>> The troublesome machine has been updated many times using git pull = followed >>> by buildworld -DWITH_META_MODE. Might it be necessary to = occasionally run >>> one of the cleaning targets? In other words, could META_MODE permit = obsolete=20 >>> files to persist across builds and reboots?=20 >>>=20 >>=20 >> I only rarely rm -fr in a build tree area to start from scratch. >> Nothing wrong with such an experiment. >>=20 >=20 > Cleanout of /usr/obj looks like the next thing to try. There don't > seem to be any folks having similar difficulties so it's probably > some artifact of this machine's history. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 22 00:02:45 2022 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 034F619582D5 for ; Sat, 22 Jan 2022 00:02:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jgbzh3g9Yz3HxG for ; Sat, 22 Jan 2022 00:02:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642809769; bh=q9pZNMhPkW5yt/5eQBzq1IHoov0lzwt+eYpZ8WFzAAc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=t/6qOFa9Z5XrU5yjB421z60U7T2/jPO8OfSfgzQ6eFfehaKIby4Ofh6L4l1RYqBIXD1J2z3tu1vK/MzUqyhHuoipSnN0bixj+KVKqkNqdVgZk0t535tYn5vQmE3/qdtG9H2r4+BgZJkpibktgzIWBHOpCFViSb0WJrCwaVkbbaamOVt6kT1Ng782oIe7dx25fOsQLSYsaVLw4skUNpA2Ue9be3u5j8ZIMacwMU+kjhR9PTSBeiUNZGZo6gcUmtGgFjh8WBiqsmXRjHf2L7VLr3PX+2sg/6mu8GWwtnn+Kyj/wo+pvM/8J1E78aVv/QqdADb0y54VAWxEfLgSJvwVKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642809769; bh=fGnG5/E2xrE1agrgMRr8e5YqqMrZO37GZuATeOacXcA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lloasDIHMMDQV1wlgfnxMzAg3RgtexZYBsjIrck1/6fhnweq3ZsoJMq7iZP3Eq7EIeZ/AzTdewIF7OzTip+2ghFvTvx+Xv2Sf6l4LG3W1ry28TLP7kFp4lJ/8Cufnm/NHfRgvlj50HJ9yFXOfuZh5viTdJNrqb6jvDOHWl60M6yeSR1Z5J5t/K8fBK8Wp4tZogJqrPlyqAGMiMtLWreoJ5OUy63S4qx01Sk0jEsW/bayH7y5bRqV3oElHKGGW1qPamOTIL3hx1Tk8nYcE1GW/fl8RNzrTTpt0qb75tnGLTsKN1CuMl71lQ3xMkI1eI8G30hsVcJfZ1F6C61bhEVFGw== X-YMail-OSG: ca4QS5sVM1kYIqg5QzmkJ.q_50KhrfaX4_FOphjGqTwHnjSVQhfygVlLXfTO8rx ZxU8045uYzXcROnOgmcZUFwO1vp56fI84uQDyJHUt2aioH8sUXAujaNgq_PZDkGN2Lsa9xhHJGsI OL3xOOJOAcX7_PCCQFT41tEi0EemWDe5hsYz4yEChlJLSxCTUxv4FWoAuWPMEvkDPlZ7sxoqy_fC EFz48Qye6ccRiEiTbosrkHPf_F0AY84GWvlGwVO_ZcPODM9ulP7IeoyS4LL_RH2gVdg93Jdac9Pv 1E3D4uXznoJKRMLHPHmeC3RUYOKloBSa6M5slNVRYFPjuwJ9DlyP6f7eEIcUfY5j48p7PFJPb.l_ 7kdqZwAyRHd1wyvswCy3eOtFzGrhqbOlgCQwtUfUh.s6TUjycSa6Wfcp7fWVd9_tnmNOUgplxXza WrzFDnGz6Y1BSMSDZQxlfJO5B69TqKHye0jfs93LTUAv_jOLDe89S5nHdm9QFvI.sYD1JvAN9qEA 6ZRJgQPTlMaZEKllZziw7JGHgAcHBtin8B1gKu700K4uMlFBKLG9w_1Xcbwd7zAJWvaqT3q8H9kp zQ2Q.8J4c4skLvkFgFl0cTx9IeORC1doyJkPL6yd4yEri0xEirjoITFsiZO8EIxAQs_mdFSrc0Sf pzIjchNDj4wvo82vOLu7G68dS5J2Zoyoq.mxDrjB5s2r6.WqW1QClEOOHmv6hKwftjsDTTPg4pLs 9ZZQixH5BIQHLGoCm37jrByHmTrInP4PUJcYIJkTU.srxDYhE4wLHFDjYj1jnjGO10RxmeuGcFNP h_GmoLEtlrljOOIn5sVrOuNWc_.rOzsbBgoq.QSZGdCIh6swskISPz_o5YyrNhOHoVz4rUVao54x p1u9QFX0Ie7UoKNhnzd.Z8vTxxf5Ffk.8EoCy9loL_iTFlohUWepMGibEUADzvlv0u.DLZprHBn9 NIhtqK2FSuhZGKt8AMcXY8w0Esx0uDaJ2_V24_PvfctO4nFvVYLb2EsRSTwDh1ABU4pnxzUM8xt0 k7yDCNZAiEz3B9vrlOC99_sUsX2WAb96GuEHm3BrU539ESiOPMHSSwDweq_IeiEp.buwrEH6iZnu 77245JBuGYpdzgr_.QSdjATsDmoA2EkR74i7NZBq80dh6iXSBgtJ2UmI8IdKFHmm86sJhOkumwsZ 9MgOmr.vmTY_C8Ml7ZCsbgyx2ZyPJd_LlprDOjN8ZCeKUTssH7CwOd_WHfjCThOFTGOZm.cH1KRl OT3cN5RkYu2H_WUlLUhJfTj_UxHuymP_nydkhMLlQhTRHNvt.2fHBiYL43qLMfDIG1nCjrcfmKV9 IKY96_pvAdjtyMYEdCdKmVJ3pK4nepm1RTVztcs7dmtIGXUv3NZdMoicd9YshgNLGwd5myCgfES6 heBqBQXezo2KPY3gmo2sTVPG9PLGpsr5W3z12pkGKElKBOKToBxjP_faERFbYFIL2YeezBIPSrzl igppn8EoQvKh486HFXtQzlYUlxWaraSJh_MZTqmXUQfPrOlT0oITj6QzXl15vkDlsYeu_5F4Rhdc lRw9Oh6Nz4Re9DKadsX9fJJqQkaPwl0Hvh1GR2mCCYxFOYU6nKAyEsKC6oRbrdKTh8ttzgTI3jdz JJvrEFYHVcLvLc2ysci6fXLlE8blAn7dRZGsCw5mG_EYE9HN04lvg_yg9qis3pgURY1RjjJdSsMg gz4zVMHpC2bCrfqPG2Ra21pi3fEDm1j8dYpVOBbNRQuyHlYajbx0RgSKsJX4d7oPeTmQ1ygBiJAg jYj_2BvIa1OjJvWI6dn0BbCsrfOaU2DY9KJqsh6K_tUkWDaxMl1dAAsfvgJ.7qrwJEzyKaB19dIB 6QzQMlfXjkBBilGp6T3Dx1XK9fxmLMcR7QTdypcMp3uaZsssiT2QLoEvPz25_Xg9PUNOWdWrAlHR 4yxc9EiVpbt219mXFdNHdyaAj8kvdnN9GBRJ.Raj3T9x9AFg8Rd241UMqIl0ZY3CvQnaAD7ZfTNJ WNVtHwPQ9BWJn6G06Egk0KJSYE6mVtqOEAIMcSrShnUVnxpq.p3VeThH3vfrN0bJA0JEHQ1h.RD5 nqEgZ4EQp2NkZogkOlrw3Z3lRxwHSaBrIsRRSsjNd1UNPV06k0btkYvMbm4qgDx_uwuDqMsUix_t yVmtEwtqCuqlOXyvPTdKLmdmZxqrY0RqJDTUrHN7q1KKOYchddiYjOyKypsIzpbKoOZbkvyjAhKQ .NJi967DAFaWepzIzMFFYR1rHX.wbnMDPg6hBpDR_Nc5HWerN7vEeBewuRbO1jSjhCRCtwNgSGl6 Dkz6UAuxwK7XL73E- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Jan 2022 00:02:49 +0000 Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 04eb0079c58269465c1743895e8b76d5; Sat, 22 Jan 2022 00:02: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: Date: Fri, 21 Jan 2022 16:02:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220121031601.GA26308@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jgbzh3g9Yz3HxG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="t/6qOFa9"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URIBL_BLOCKED(0.00)[zefox.net:email]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6290 Lines: 173 [I've switched back to messages with the original subject to avoid mixing the issues.] On 2022-Jan-20, at 22:00, Mark Millard wrote: > On 2022-Jan-20, at 19:16, bob prohaska wrote: >=20 >> The last few attempts to build world on a Pi3 running stable/13 have >> stopped with something like: >>=20 >> --- all_subdir_lib/googletest/gmock --- >> =3D=3D=3D> lib/googletest/gmock (all) >> Building = /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o >> --- gmock-all.o --- >> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. >> Stack dump: >> 0. Program arguments: c++ -target aarch64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g = -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers = -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith = -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow = -Wunused-parameter -Wcast-align -Wchar-subscripts -Wredundant-decls = -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable = -Qunused-arguments = -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private = -I/usr/src/contrib/googletest/googlemock/include = -I/usr/src/contrib/googletest/googlemock = -I/usr/src/contrib/googletest/googletest/include -g -std=3Dc++11 = -Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions = -c /usr/src/contrib/googletest/googlemock/src/gmock-all.cc -o = gmock-all.o >> 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:1125:53: current parser token '{' >> 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' >> --- all_subdir_lib/clang --- >> Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenEVEX2VEXTables.inc >> Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenFastISel.inc >> --- all_subdir_lib/googletest --- >> #0 0x0000000004112640 PrintStackTrace = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13 >> #1 0x0000000004110a84 __cxx_atomic_store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5 >> #2 0x0000000004110a84 store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10 >> #3 0x0000000004110a84 RunSignalHandlers = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16 >> #4 0x00000000040b4f08 HandleCrash = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76= :5 >> #5 0x00000000040b4f08 CrashRecoverySignalHandler = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:38= 9:51 >> #6 0x00000000452bad80 handle_signal = /usr/src/lib/libthr/thread/thr_sig.c:0:3 >> c++: error: clang frontend command failed with exit code 139 (use -v = to see invocation) >> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >> Target: aarch64-unknown-freebsd13.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: note: diagnostic msg:=20 >> ******************** >>=20 >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp >> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh >> c++: note: diagnostic msg:=20 >>=20 >> ******************** >> *** [gmock-all.o] Error code 139 >=20 > So: SIGSEGV (signal 11) >=20 >> make[6]: stopped in /usr/src/lib/googletest/gmock >> .ERROR_TARGET=3D'gmock-all.o' >> = .ERROR_META_FILE=3D'/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gm= ock-all.o.meta' >> .MAKE.LEVEL=3D'6' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >>=20 >> make[4]: stopped in /usr/src/lib >> --- all_subdir_lib/clang --- >>=20 >> FWIW, filemon is enabled in /boot/loader.conf and the build command = was >> make -j2 -DWITH_META_MODE buildworld > buildworld.log >>=20 >> This doesn't appear to be ARM-specific in any obvious way, but it = might >> be, so I'm posting here first. >>=20 >=20 > "uname -apKU" output from the building environment? >=20 > Commit identification for the /usr/src/ for stable/13 > that is being built? >=20 > Any console messages? dmesg -a output of interest? > /var/log/messasges content of interest? >=20 > Any messages of interest somewhat earlier in the > buildworld.log ? >=20 > Does the problem repeat via using the files: >=20 > /tmp/gmock-all-836ef8.cpp > /tmp/gmock-all-836ef8.sh >=20 > on that RPi3? Elsewhere that has more resources, such > as more RAM? I do not see anything between your: Thank you, the script reports: branch: stable/13 merge-base: d7b156672a48c37e1b8ce9b4ae28a46ecea55412 merge-base: CommitDate: 2022-01-21 15:58:11 +0000 d7b156672a4 (HEAD -> stable/13, freebsd/stable/13) zone.9: Remove = documentation of non-existent NUMA configuration flags n249092 (--first-parent --count for merge-base) and where I'm at for stable/13: branch: stable/13 merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f merge-base: CommitDate: 2022-01-15 12:55:32 +0000 a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore = debugger-injected signals left after detaching n249004 (--first-parent --count for merge-base) that would seem a likely explanation for why I did not see the problem when I built. The same goes for between your stable/13-n248948-9418a626103 starting point and where my stable/13 environment is at. (In my case, I also build for poudriere and chroot trees, not just booting. So multiple builds are involved in the sequence.) I've not come up with any ideas beyond the 2: A) Trying the two files that failure produced for attempted reproduction of the problem (such as): /tmp/gmock-all-836ef8.cpp /tmp/gmock-all-836ef8.sh but in other system-clang 13 contexts to see if the problem is reproducible off that RPi3*. B) Doing the /usr/obj/. . . cleanout and then a build-from-scratch attempt. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 22 07:14:32 2022 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 249B0195F555 for ; Sat, 22 Jan 2022 07:14:45 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgnYw04RFz4bmM for ; Sat, 22 Jan 2022 07:14:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642835676; bh=VYK2boiJ0RqARyitoTtYaibopbai6B/ZSIFDby+0wJY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=POLbjmNnCSPQQD1UFxRH2+n8+OzwfkpvPJW0QdQticfgba8Tz23RvdDNqfwHnZhSCxxloP2DBTj0tkaqRaNFX+BRuk59eCRkZUeFFWiQoGDgbMIthYSyqHG6bROnydMC7bmf6h86Ywjnu44qWrmHt+eA6orR5y2/3GIya2d2H5yeity/xKk0BToFuYzFTCtt/yXmE7cooALhRQ88jbsjnOAD3q99Fh9WdUYP5BtiYPlkb1buJkAhwL+570zhXru3RK8JhT6cws6tBGmZC9AS3ZP11w3d1wp07DKkTkqWVbrrtr9PmCAI/B8MT55Y3tcgWVpZOk1NPpWuC9fvmInLUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642835676; bh=RR98mO2SiXB77I3+rApwvsmQYYlpEAqv0imY4mEC9V5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=n7W4W4iiUQ2ZxP8QZEccVIPP89n+BvMowtrreanH9NBikkZd/V6llyUklWVt8FHgStYBqMlalqly+azqXTXeSFxAvKsjjTPBhYyd+rmKutlLKWgH7LK3ilEnJl5FivsgZuTDw3ilQ3FMM2rWEH6SIMuAce4MjPHg/g8unObxKW2jTOAgATrjkay+xna+1AEi1PEo3V3pOsnSPXQ/W+MyVw0L6WwbIb9YUPmEHcvnphoddDDIDVM19u1VAn3Onxp+5Hv/MeVLmTxTU0PV08m8EXpkd452PZ6urdgXeIpPsP0yJmXZAelOSUOl0S+M/SY1uc0i/cMtDqlIG5zpesWhlw== X-YMail-OSG: CXvZKoQVM1kD3r3bXU3JVZ1IqsSyWUOsdtUZHGkXubsQZTR4Qj7uL.DXz_1bJcK WDU7PNvQn8NF5MA.KH_0Oz1WHHjnAnrkfsrCvK4N0R_gPLnnWQkHfgP0mIGyQF4drdO7RnBk5Dib DZ1uwQ9Cyk1XSCEyTbk8BQMUV1Ao05YZ30FGLepbl7f6WzZY7GopAlX6_pf0iFcXHB_qYofHojTz yMMVLxIXjffSMcnXTfDKX8NZZ0tmz4ljGAuRD9araHFz0IOZ564mOFYOCkbCfh2_OMw.MIQ31hEO fzZumMQ2nhEUNmJ2R9Fn77h76Ym4fmspRRhBM9lxesxcCOWgWL42RNcWHMvQrSfPV.nNQ2CNAeVa QA6jK2HeVjNtnoC0Ov.RaYbkokZ61KRJ8Hya4rp.oLJY1kAvShRpBKOYx5YHcHSiZrNi27qYaJvV PU_3y6Kt1NMbgtUoTsoLfKEreoaiQP.pkprUZ6Im8E0HrXPJpk7.lA8NZOkcKg7Pz9pNhKcY2bfZ A3TqoKzFFEYxY0kQDF5B6pGkSp.npAjKmJ0ahbA9wsIjHBph7oyhs04f.IEwdxs4vkrhZ9V2RFrR KFz3UABqvg_xMT5P.SbS0zef74XwHMf0dntaOd5agwtCgTD7Q223QEBF3APaS1Wq9iB.RirUudZK 3wwQ8a8afXF2g4.wVWuHJ95Xiy26mChGb4RQu3LRpT_HyTLHQUAaqGG0zYYdC6eNHkyBipgX6bsR dR9LJw7gQOFOVc59l7XZfV.no3c6I3RpYB_SEDHI_rvt5hB8oSk4jFtujZWxJwFsZOhe4PyCPiEV acgJzdAU1YiKxUDr0JW7kZ9TKCB_D_eSVGmgQAd8r0MU3HOR1tNjSbHXtaolqQ82wnNL.yVNbPb2 4O47aLr4u45_kFZBo7iHka_JwDyAMbQgu5wZVtAGjM6rfqPtrm8EP9mdl22ndZsuPR9cBjxPYHt1 6WLw2nDnP9Ay4KZT2jFtUxBLa2rZXt9OIWCL6sp_QEoZ3Ex6EKM8BZSCp1t3YkLEIWZ5e1Rikocr 55IbjgXLeG0qHaI3Uzfck..cOXWTFoz4VFNXvfjFSXK4fwV3asTfO_cRCbLXXVunLpQ6akCwPwlo _RnT1ZwkSroV8G3G151mjlL1PH9dcZAsFMGt.2UYFZ2Im0f5caTZkShFGHcEG.GQPXm00K0O2E_v RgSpHU1FEpgfgrvUIvn4xcOFarJlUMqN2ZQbkj9D9UjFX1pJuuRgxVBivN9kGHZ36xhd3rZ_aSx0 unVmxtWys9iZdUtkK0uTlh.GF2UhO4qGDPa2KEGiOKHM7MYMY6RLNtTtNq4SWAjDT.w4zxTkp.gx 09PhobzvATMiaVb5zu0bpTdp84bBjcWT8sg9qz3d523ri75bEXInfV4hmwuZEdAjFG19Mi76EeMR d9w0J78KtJxp0VxUPOgWs6dffZMYPxJ4TXHS09mrIbq0sD8pwi9ydh2ey.uMsYQgzdWbp3WDOmFF s3XRTN0jB6g4Cb7I9QhqX1Hh99p1dnDhMc77SlStfw_PY6Vr1DJYjjyuIGWmQ5EwlNlVeajQDhNs 8__ACnZ15E59ZIACd.S7kzfnJTniDiXHZabGGGkfubL4mif2_f71b98EEsw9z0dyZyZTCG5Ixq0J OYvT9F3fyKzyI1bbZs0Z28g.TddLVE5K.bglMbYK292Xs6ynSS9849kE3ecxNawMQWB4ViZ3khJh 6wk828BxqaPYMRhcj69q_u4LH6RYvlU0XWGXrnwyw6Udu2KCE3CRBgskDBDozlJKGzBTw1Bup.90 _hSvpc4S_LPsWwZO0vd.2SiBczoCXlCAPLs9Vvwh5_rySeKJkcWaB99qgRY9pFL_pYYKbGN6zRhx SxAFPth2QQs3mj5joU3waYkBl6F70Y05_lVCGXf6me5RuVdH22GJue7UZ7WL_a.fo9U1Gpnez5.8 eMbpSg_GL9XeBPH1YdpvixLTyqUQ0UAYwffWeE77tekYUs3UacxfoU16lcLEhh6bHntjFFqwpT2W tdaYWIY8eUWWjYZpRTlrbBmWW6j119omKGbVFgubekDkjRiSr9AnGR9_tO3FBsG0bkRTh8EjpBNp sQiXIlx0j7W6c48HsGIXJqLlun3H0zQv07dAy8Qip.sPstfBMAv_ffvm2Abg8CZKIaZNDxbjSwsG c.UFKkJOHdYs63bbthDZ9aIgia0ve84uMoUpvQv7_gV2f9j_aUp8vnwTHx4lhXEtIsmOvp3WUylJ NUiyKHYAiEPkT4PcuUGa7wfjsB3MpQ_Y_qqabWPPTvm6J8MnebQVDlTE3ojXrLGGyf4EOvv2_dJ4 EHWtpe6zqBQBpWSI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Jan 2022 07:14:36 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID edb5202e356f358f847ea9f874952af2; Sat, 22 Jan 2022 07:14:34 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: Date: Fri, 21 Jan 2022 23:14:32 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JgnYw04RFz4bmM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=POLbjmNn; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9725 Lines: 258 On 2022-Jan-21, at 16:02, Mark Millard wrote: > [I've switched back to messages with the original subject to > avoid mixing the issues.] >=20 > On 2022-Jan-20, at 22:00, Mark Millard wrote: >=20 >> On 2022-Jan-20, at 19:16, bob prohaska wrote: >>=20 >>> The last few attempts to build world on a Pi3 running stable/13 have >>> stopped with something like: >>>=20 >>> --- all_subdir_lib/googletest/gmock --- >>> =3D=3D=3D> lib/googletest/gmock (all) >>> Building = /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gmock-all.o >>> --- gmock-all.o --- >>> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. >>> Stack dump: >>> 0. Program arguments: c++ -target aarch64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g = -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers = -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith = -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow = -Wunused-parameter -Wcast-align -Wchar-subscripts -Wredundant-decls = -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable = -Qunused-arguments = -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private = -I/usr/src/contrib/googletest/googlemock/include = -I/usr/src/contrib/googletest/googlemock = -I/usr/src/contrib/googletest/googletest/include -g -std=3Dc++11 = -Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions = -c /usr/src/contrib/googletest/googlemock/src/gmock-all.cc -o = gmock-all.o >>> 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:1125:53: current parser token '{' >>> 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' >>> --- all_subdir_lib/clang --- >>> Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenEVEX2VEXTables.inc >>> Building = /usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm/X86GenFastISel.inc >>> --- all_subdir_lib/googletest --- >>> #0 0x0000000004112640 PrintStackTrace = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13 >>> #1 0x0000000004110a84 __cxx_atomic_store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5 >>> #2 0x0000000004110a84 store = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10 >>> #3 0x0000000004110a84 RunSignalHandlers = /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16 >>> #4 0x00000000040b4f08 HandleCrash = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76= :5 >>> #5 0x00000000040b4f08 CrashRecoverySignalHandler = /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:38= 9:51 >>> #6 0x00000000452bad80 handle_signal = /usr/src/lib/libthr/thread/thr_sig.c:0:3 >>> c++: error: clang frontend command failed with exit code 139 (use -v = to see invocation) >>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >>> Target: aarch64-unknown-freebsd13.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>> c++: note: diagnostic msg:=20 >>> ******************** >>>=20 >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> Preprocessed source(s) and associated run script(s) are located at: >>> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp >>> c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh >>> c++: note: diagnostic msg:=20 >>>=20 >>> ******************** >>> *** [gmock-all.o] Error code 139 >>=20 >> So: SIGSEGV (signal 11) >>=20 >>> make[6]: stopped in /usr/src/lib/googletest/gmock >>> .ERROR_TARGET=3D'gmock-all.o' >>> = .ERROR_META_FILE=3D'/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock/gm= ock-all.o.meta' >>> .MAKE.LEVEL=3D'6' >>> MAKEFILE=3D'' >>> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >>>=20 >>> make[4]: stopped in /usr/src/lib >>> --- all_subdir_lib/clang --- >>>=20 >>> FWIW, filemon is enabled in /boot/loader.conf and the build command = was >>> make -j2 -DWITH_META_MODE buildworld > buildworld.log >>>=20 >>> This doesn't appear to be ARM-specific in any obvious way, but it = might >>> be, so I'm posting here first. >>>=20 >>=20 >> "uname -apKU" output from the building environment? >>=20 >> Commit identification for the /usr/src/ for stable/13 >> that is being built? >>=20 >> Any console messages? dmesg -a output of interest? >> /var/log/messasges content of interest? >>=20 >> Any messages of interest somewhat earlier in the >> buildworld.log ? >>=20 >> Does the problem repeat via using the files: >>=20 >> /tmp/gmock-all-836ef8.cpp >> /tmp/gmock-all-836ef8.sh >>=20 >> on that RPi3? Elsewhere that has more resources, such >> as more RAM? >=20 > I do not see anything between your: >=20 > Thank you, the script reports: > branch: stable/13 > merge-base: d7b156672a48c37e1b8ce9b4ae28a46ecea55412 > merge-base: CommitDate: 2022-01-21 15:58:11 +0000 > d7b156672a4 (HEAD -> stable/13, freebsd/stable/13) zone.9: Remove = documentation of non-existent NUMA configuration flags > n249092 (--first-parent --count for merge-base) >=20 > and where I'm at for stable/13: >=20 > branch: stable/13 > merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f > merge-base: CommitDate: 2022-01-15 12:55:32 +0000 > a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore = debugger-injected signals left after detaching > n249004 (--first-parent --count for merge-base) >=20 > that would seem a likely explanation for why I > did not see the problem when I built. >=20 > The same goes for between your stable/13-n248948-9418a626103 > starting point and where my stable/13 environment is at. >=20 > (In my case, I also build for poudriere and chroot trees, > not just booting. So multiple builds are involved in the > sequence.) >=20 > I've not come up with any ideas beyond the 2: >=20 > A) Trying the two files that failure produced for attempted > reproduction of the problem (such as): >=20 > /tmp/gmock-all-836ef8.cpp > /tmp/gmock-all-836ef8.sh >=20 > but in other system-clang 13 contexts to see if the problem is > reproducible off that RPi3*. >=20 > B) Doing the /usr/obj/. . . cleanout and then a build-from-scratch > attempt. >=20 I see that there is: http://www.zefox.net/~fbsd/rpi3/20220121/ with a .cpp and .sh pair (f5c28a). I downloaded the two and tried the .sh under stable/13 and main and got no failures. (But it was not an RPi* at all.) For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 = main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400047 1300524 (The above is a chroot use into an area that can be used with bectl to boot the machine.) # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 = main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400047 1400047 It does no good for me since I do not get a failure, but you might try (instead of exectuing the .sh file) (I used \'s to split the huge line): lldb -- "/usr/bin/c++" "-cc1" "-triple" "aarch64-unknown-freebsd13.0" = "-emit-obj" "--mrelax-relocations" \ "-disable-free" "-disable-llvm-verifier" "-discard-value-names" = "-main-file-name" "gmock_main.cc" \ "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" = "-fno-rounding-math" "-mconstructor-aliases" \ "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" = "-target-abi" "aapcs" \ "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" = "-dwarf-version=3D4" \ "-debugger-tuning=3Dgdb" \ = "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletes= t/gmock_main" \ "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" = "-Wno-format-y2k" "-W" \ "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" "-Wcast-qual" = "-Wwrite-strings" "-Wswitch" \ "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" = "-Wredundant-decls" \ "-Wmissing-variable-declarations" "-Wno-empty-body" = "-Wno-string-plus-int" "-Wno-unused-const-variable" \ "-Wno-error=3Dunused-but-set-variable" "-Wno-deprecated-declarations" = "-Wno-deprecated-copy" \ "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ = "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/g= mock_main" \ "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" = "-fgnuc-version=3D4.2.1" \ "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" = "-faddrsig" \ "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" and then "run" at the (lldb) prompt. It might stop and let you get a backtrace (bt command) in addition to whatever it reports about the stoppage. In my environment the 2 references to: /usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock_main have no such directory available. In my context it would be: = /usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/lib/googlet= est/gmock_main But using the path instances for my context still did not recreate the failure. The command just added "lldb -- " in front of what was in the .sh file, other than my line splits for the email. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 22 14:34:39 2022 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 D6062197FA20; Sat, 22 Jan 2022 14:34:50 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JgzKj6gp6z3Qb6; Sat, 22 Jan 2022 14:34:49 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7867C3200B25; Sat, 22 Jan 2022 09:34:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 22 Jan 2022 09:34:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; bh=g rMmDGBflDhTkQ1dKNL2Z/iZExxar75xUi+zNrWXuI8=; b=YputTSu8Ungh3AN0Z WYeIlXuw57tFGWKpcy84RncQaqIqCkpRMEaZ8aflri3TcW/IQ8PSff+NgMFOqwB3 YMvS/csAT1nxU0M6wlz4ql5D8O7dil9VMfL4lxoeopLqQO/yKW/I9Qx7Pv+/dBRI ky7uNjrms8N6JMvrDpmAOnjDS/lkBqtfnhirxF6NA3cYax7pK9sZ6yceHftLE2Kg oqs0MJRSruDgWfK1/fO5JUHWiJ9elohijF5kNGGsyxhOnWzpiqrkTVF2iQ/REJX4 Hm8p0wPKK+7LDoslbuDpx8WOLFI35EZzU5gAftr8e6Zd82EgvTKRJMme5P0dBKOO +KqmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=grMmDGBflDhTkQ1dKNL2Z/iZExxar75xUi+zNrWXu I8=; b=H2J6EUtrSLNGC9YbfQMoaJP9/3WtTqOWo+HsBHNf7vwcTGfl5TWedgsUB 3Ho63ycPA0YkeX629gd3KesVgY1aprpbFuWDrnyLXJuY/80sUaqVk3owso67d9mk 99UDNJ5sKOgZpa0z5IVEtTF2a40ynNjEabI2g7Ii1L3FQ3DnlHiDlkieAzMIXoT6 qOebaHWGpEps8SJShRUCuwZsfD7NDd1lWbcJokvG/r08MSMP1TjdYAtGzs+bm6TR DqwkbS4lByRCLX7uhtjAr/YcCdtBgbJDLlkAo7EWJMVS37ocyYNB0ionBDqRpuvt eG5skoMcOc+3FVRGuKnr/adPi8Rgg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvddvgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd dvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiihgihs thdrnhgvtheqnecuggftrfgrthhtvghrnhepvefghffftdefkeelleehtdejledvhfdvge eijeevfffguddvhfetgeejueejueeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 22 Jan 2022 09:34:41 -0500 (EST) Date: Sat, 22 Jan 2022 14:34:39 +0000 From: tech-lists To: freebsd-arm@freebsd.org Cc: freebsd-current@freebsd.org Subject: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cN8/Qsv4xgEsS6SG" Content-Disposition: inline X-Rspamd-Queue-Id: 4JgzKj6gp6z3Qb6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=YputTSu8; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=H2J6EUtr; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.20 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2002 Lines: 54 --cN8/Qsv4xgEsS6SG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, context is a usb3-booting rpi4 running main-n252544-7406ec4ea99 I see this in /var/log/daemon.log: Jan 22 13:24:54 redacted zfsd[886]: POLLHUP detected on devd socket. Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. Jan 22 13:24:54 redacted zfsd[886]: ConnectToDevd: Connecting to devd. Jan 22 13:24:54 redacted zfsd[886]: Unable to connect to devd Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. When this happens, several other things happen: 1. the sshd server dies. Already-established sessions still run, but=20 the server itself stops and no new ssh connections can be made. 2. syslogd dies. so does exim, nginx, smartd, sshguard, pf I don't know where to start looking for reasons for this. Is it a known issue? In the meantime I've turned off zfsd as it's not really needed in this machine's context (headless, zfs on single disk), from what I can tell. --=20 J. --cN8/Qsv4xgEsS6SG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHsFfUACgkQs8o7QhFz NAXSLQ//a6StY92eAnZH9yFn3Daqr0KSf3PhHM7y4LJqv5q8T2HNSVmZUst2EKaS IkFSozB9V5CY5qtV0RfRtcvdR+Pv2aN4zp7CuKYp91LGe+Q+gmNAf4D1UOkVnqvc bbCXHBNj22piXsqfpoCxKWLvNV5rqNbGSEPBkFz0y/z50m5hSPwcu9b8A/xY55WG /Ptd7zL1Lv+wZ91E31oPOe3jNHidwoSHah9otMBMhZuJkQXiaLi8c8vT+ChGPRW5 TO/2QKBnBfnNIxiOY1jYS46kSTH14W8snTHnjRRbrc8TCJ+5GRo5MlS0Y0DeXGoP QAh79vrGu3/NqnEcnE8OxMsbPiSpW+pjiyCKCJwKg4WzxUT2UbX8DRL1Dt+uhPjl UqaJ/mX9fvUFTLcIblPNlD5nEmPp9MOuEmXW0O634unN7HUX4BSH5wgljFgUAoSX o/9xN5SFgDbrz9Irns9vvKgJvpKXuGzJzvpEod/20DKThLV8FcFyDcTCNBKVD5PB 33shA+sR/CJTEPHaVa+bUJiuSU3+arO0T2HpcmtXIeivv/obpwrAI4Hev+Dki16e ml4jklzeCl64qdCrPsoXd3avOCv/FXhiQkMyhELRXtE3TPW+8weG45yKQqmjSftC pNgyDFDsNz+LZR/W8ENEeQmIwp372z31uMTk9lf+BssMgCP0yT0= =C4Fm -----END PGP SIGNATURE----- --cN8/Qsv4xgEsS6SG-- From nobody Sat Jan 22 16:07:22 2022 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 DD232197A3A7 for ; Sat, 22 Jan 2022 16:07:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jh1Nn5Ktjz4lx8 for ; Sat, 22 Jan 2022 16:07:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642867650; bh=G5TeCv0BppGXOIYfUxAuyvoLiPFxNpzqdSVrSuOnPQI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rWsNrEctjSy3iw/Hp0lCOsr7y29OyoikZDeI5LubTqGMiSapR1PwqQPspf9Qgo1OT4ZdZO38mfjtRcUzdSWdSp1izFSCwdyDEe5M+xXLGmPhiEeviaOuBkYyH8NLGphI9Kcl19ygU8gureI9r7FRQztw/j76dZpsBHoF2Vlii7hx68AAYqdt9CpR+gnj7eQoTd4qEsesklIoJxbXmyfTdBWS1yHqR+BS7d59SoMjqNAgNwI6VVAiLML4OtOjpY22uy7yEXYNm7fBkiAbOUeSip6RBDWOBJB1Mu9Iojn6jQ0NL28ShUQa7NK33KqLLReKQ8MDgWsMVSZhAsLwhRknIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642867650; bh=j+9dvd2cz4UVvsPShQFhv7X6McjnhexgjhwDZ0DnFvv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RwBoVrnIrnVIx5mHmwFU9qW4fgejC9zsGq8VogCoX9IeJQxoRTPNwD+gyNQPekIhW/evTMmI+eb+YpUwi1byAFpfBeRUqNzMz1hl9a/km8VoNg5iWb3jZsmtZeek8vB5vrQN0ld+PX0gCfgejJ60w3P7wYuRiYf0ApBpCxFmkQqBgit1W+9c3yMJhObEHJBrTdrudR+7CJR1oHlP4RNW03DKh34Z98RzMG+fdBd6xnxULuIvZh2neDYp4hqJvv2dqoy8UB+kmPKJCIEk0SgHfIjKmHHvCM8VRMwfPq+ajVruqqDZKjoTLwUTO1vUEWxCUQhDeam5IAZVJlWe+y/w4Q== X-YMail-OSG: Ecw6vGAVM1kWnfyy7ccSDlLjyh1Y8f5pbCZhssPdClH_MIIdCx1p0oM4sVWx53c E8fI8BaN3veDrxpEyx23qsld9IgTpz1Gn3YnW2mzkILEkAkctDMZLouLFIL_1yZzNqdOXhJMlmhr bf1Y1cnDxPhLt0szko0PMHruPTrSIj.s5MeisYppZqCpUKNSnrjo1hgGXGPvGA_p0.ICVwOiVqLT T1mHPtz.7wIpBNQeF87JFdUIcaAF3cvjEeVDbleg72o3z_qSEEplZUjP17HTOuEFl7.IxY.Y7vi4 mgMEiD6q9bIHrJ9lk3GZ2dxOWPyuxlE_b0IOSWjWHWCco_QRs_Yys.d6gilr0zeKKtdvnbYiaa7A mqIdkgkq79Ju6AHpt5jHOILygERvpFuO39i4gcVWNsOIq8eSd91cS8qyDxpoWGDvvvF6IRbKhjFT 2DwcS.Drfj91cUr7nWoUxE8jZh8UZsMEnIIWJF7wIOrmRZr0nO_u2FvtpH8Xy8o9nOEBCJJH4NmL qBsTiBdUq9ExY_xtnm96IeESZOsR19Q9.kcNzx6aOpZtawPgZy.S.Ge.6BWdGyr6luzuCsQAzkvV G7_9VQn2HRm4G._KNHmp4laiw5MNcWN9Xnx52myg2aR88j5zAVJTm5IIliLbKaZbOK_euGb8da9s 2plYNM4AK15hC0QyZ086sadR4_NEZlc2bg5ARCXaCchOvMiNTTpspgKqoMUL0h9whJ9DOC74UVxs LxwACgiTyDl_swp3ziubEgipspNzAv2bUDVHtAAq98ri1RWnzy5Q31HK6GVeugd1u9QHb9XbAWj5 n4PEzrdSOIwB_0UCiytBCt3auE9qPAju6_HQEnLhdypvGVxMzka9BruGPCg3xkkrA5g6Q_j6D4X7 Xoh.vECqpXYS8onOS.cY9XOAVQE7GLIum_X4oTkJO8yoPMcQ9r4XX5vOeK.StUZrzGI3TPKy3rBb iAOdtNQijbqKU2mU9oaTeqUTs2_t0j3r25s6qN2HORSUxQvMNGLP0FIp7429RbiRdQLfRQgudVKu O.ssj9nY4RHw24C_BrzMN_p4oZUgYtKZ8DMHe3EcYHCfTipdX2pR36t.wt2mGGnzYhq6uIpzQozT 5tXHZHKsk9HkR.6fKAjgCkqp3_KOknw3sNFQkdSeMVIE94abYB7vSsXXBpU3182u1rbHx5F9mG0c mWp0XD91Ft7U49Y5XQZYbHrd2N429jOzdasgpzGAvsh4DLhspAwUhMFGD5g.9z6.EGLFs0BkoAOu qNfRRp9.Lyc6NvEiThyJheXNfwdmtEUzynF7SAgns977W.aJJtvuiHWSrFv4x57f3pjXzx9Den7H B.IPUWiImjzevrfGPKUA6WHT7GXrF3p0Yt18lVrcE3Vqdwgo_bUfmUZqSSPz0ON6n10dz009SSHG r4F5SP339IVMbhGFrPb5mp2HBZvYnoYXIBn.xT.fMJ9WUTTYCIE8wOFf3nPtfvul3BJ3f.UwWmti fgGU7pRf9FSUqUgmgPjA_0dFDnKMbleQQtKZTc4xl88P.23RR9GcVuL50aNgF94nGf9hSkl3Pv0m Qs8lPNSdu2PopJUyQWexWlHv2M0lo0m1_ew1BwaUw3QetbthP_SWEHRptKZFYUEeCPeTc62Y0QG0 iQqKYsmQ.R5EHbAFm5nw7lJnk5a_tvytFRq2RIORlg4ZMBp1P6e9jfu_0WeEj4yx_UMZl23UdIdt 1N.C8qJ0V8HuuuRT_IPP8cpVv1j0FhLB7pct_qT41vMdWwoargnrfLihmud0GLdNtsiMSe4o7tdD 5boiym6gh6OWHie_BQoJ3rnm6XSYS376i9Ybcz5kGNHjuyFhSmMWMx0_B7_sm8EPdomfew52d5d9 CTy.f5uq.jTn9S.oW.RbTuasWcD8JGil.GpbW1l0Oj3oqT9gpdmYuOFdC7xuC2ijcvdbvwn9IcDO 6sq_nol382hsodWNidlUkwgNS6JL6vypXPerdNWGtVG9VaNexIwj58Xn05ggLjsSNDkl090O8xZh CYutiZLY0KbtLTYTqJGHzX.GEgfmOH9CciBR10gUetQ8PCfFTt2k7M_J46R94MoIoUqZJN1a4y_H qkz5bCC39.sKZpdskNsunfzmVxK1dA1792rbY_bCHJGcK9aVokFsI4C0o8UmtJxDQqjl41eAESgg 0tvQiqW0z2xyml1feje1R5CFQD21t9aLleKyeTmXd5b2AY6vqOAQgtLIe_Pheqb3qZtSHke8gjPs J4n17qPLnJnqxSOu_mxvl.SsHg_iNRRvxLBjwvnCmHKxS0wlnYAhJplpIBdxE0Rm0ulCkAlIZRul AXu7Yy9mxtbvR7cEB51Z3flga.v3m6KYmjeV_5w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Jan 2022 16:07:30 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ff5b4e3e9f2400b9d4f2378b4ac7cefd; Sat, 22 Jan 2022 16:07:24 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot From: Mark Millard In-Reply-To: <8551EF27-BF69-44E5-BC32-FB7E1752FDD6@yahoo.com> Date: Sat, 22 Jan 2022 08:07:22 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> <20220102025818.GA42622@www.zefox.net> <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> <8551EF27-BF69-44E5-BC32-FB7E1752FDD6@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jh1Nn5Ktjz4lx8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rWsNrEct; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.47 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.97)[-0.972]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9471 Lines: 246 On 2022-Jan-4, at 01:31, Mark Millard wrote: > On 2022-Jan-4, at 01:03, Mark Millard via freebsd-arm = wrote: >=20 >> On 2022-Jan-1, at 18:58, bob prohaska wrote: >>=20 >>> Coming back to the saving of u-boot environment variables, >>> backing down to a much older set of FAT files seems to help. >>>=20 >>> The machine now has a DOS-only microSD with an old set of >>> files: >>>=20 >>> root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_" >>> VC_BUILD_ID_USER: dc4 >>> VC_BUILD_ID_TIME: 15:31:38 >>> VC_BUILD_ID_BRANCH: master >>> VC_BUILD_ID_TIME: Jun 7 2018 >>=20 >> I've no clue what the status is for this vintage of RPi* firmware. >> But it is not obvious that the RPi* firmware is what enabled >> saving u-boot environment variables: the U-Boot vintage may be >> what made the difference. (It would not be the FreeeBSD loader >> that makes the difference: not involved until too late to >> contribute to the issue.) >>=20 >>> With this suite of bootfiles it's possible to save a value for >>> usb_pgood_delay of 19000, which in most cases results in a hands- >>> off detection of the usb hard disk (via a powered hub): >>=20 >> I do not see anything here identifying the U-Boot vintage used. >> But the vintage may be tied to the save working. >=20 > I may have implicitly presumed that the U-Boot vintage supports > presenting a UEFI interface. I've no clue what vintage such was > first good in. >=20 > Thus, I may be implicitly indicating requirements on the U-Boot > vintage used when I suggest FreeBSD loader related material. >=20 >>> MMC: mmc@7e300000: 1 >>> Loading Environment from FAT... OK >>> In: serial >>> Out: vidconsole >>> Err: vidconsole >>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB = Device(s) found >>> scanning usb for storage devices... 1 Storage Device(s) found >>> Hit any key to stop autoboot: 0 >>>=20 >>> Intervention with run bootcmd_usb0 gives a successful boot from USB.=20= >>> If nothing is touched, the console displays:=20 >>>=20 >>> MMC Device 0 not found >>> no mmc device at slot 0 >>> switch to partitions #0, OK >>> mmc1 is current device >>> Scanning mmc 1:1... >>> Found EFI removable media binary efi/boot/bootaa64.efi >>> BootOrder not defined >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>=20 >> I do not see anything here identifying the FreeBSD loader.efi >> vintage used. Likely it need not be old? >>=20 >>> Consoles: EFI console >>> Reading loader env vars from /efi/freebsd/loader.env >>=20 >> It might be possible to tell the FreeBSD loader to use the >> USB drive via the content of the /efi/freebsd/loader.env >> file on the microsd card's msdos file system. Likely this >> file would need to be created. >>=20 >> For all I know setting rootdev ( or currdev ?) to the >> appropriate disk?p?: text might do such. (That notation >> presumes UFS, ZFS. ZFS uses zfs:DATASETNOTATION: I've >> never tried using /efi/freebsd/loader.env and I've never >> found documentation in the system. But there are notes >> in: >>=20 >> https://reviews.freebsd.org/rS346879 >>=20 >> Given that wording, I'm not sure just where >> /efi/freebsd/loader.env ends up being relative to in the >> msdos file system. I've not done much analysis of the >> code that is also listed. >>=20 >> There also is a loaddev that seems to be involved. >>=20 >> I expect that in some respects part of what is described >> in: >>=20 >> # man loader_simp >>=20 >> applies to the contents of /efi/freebsd/loader.env . But >> Other things may not, such as rootdev being used to >> initialize currdev . >>=20 >>> Setting currdev to disk0p1: >>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>=20 >>> Command line arguments: loader.efi >>> Image base: 0x39e91000 >>> EFI version: 2.80 >>> EFI Firmware: Das U-Boot (rev 8217.4096) >>> Console: comconsole (0) >>> Load Path: /efi\boot\bootaa64.efi >>> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x >>> 01,0,0x81f,0x18fa8) >>> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0 >>> ,0x81f,0x18fa8) >>> Setting currdev to disk0p1: >>=20 >> /efi/freebsd/loader.env content might be able to control the above? >>=20 >>> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 >>> 97c7,0x7726839) >>> Setting currdev to disk0p2: >>=20 >> /efi/freebsd/loader.env content might be able to control the above? >>=20 >>> Startup error in /boot/lua/loader.lua: >>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or = directory. >>>=20 >>> Type '?' for a list of commands, 'help' for more detailed help. >>>=20 >>> It looks like the root device is still the microSD card, >>=20 >> /efi/freebsd/loader.env content might be able to control the >> kernel load device (via indirectly or directly controlling >> the currdev value), possibly via assigning the rootdev value >> so that it will be copied to currdev ? >>=20 >>> even though >>> the USB disk has been found. Any suggestions appreciated. There's a >>> complete and recent ports tree if it's helpful, attempts to use it=20= >>> on my own have caused more trouble than they've solved, in = particular >>> that's what lead to the "saving to FAT....FAILED" messages. . =20 >=20 >=20 > I'll note that the code from https://reviews.freebsd.org/rS346879 > that added reading /efi/freebsd/loader.env if it exists was > not committed until 2019-Apr-28, well after "Jun 7 2018" (the only > date I have for your context). The FreeBSD loader in the msdos file > system would need to be from after the 2019-Apr-28 commit involved. > My guess is that a modern one would be fine, but it is just a guess. >=20 > Setting rootdev via U-Boot may be another alternative that might not > have such a vintage-tie involved. In testing if I could reproduce your system-clang++ buildworld failure, I got ahold of the old RPi3B and tested on it. (FYI: No failure.) But, to get there, I ended up facing the usb_pgood_delay issue for booting the type of USB3 NVMe now in use. Based on my ports tree having sysutils/u-boot-rpi-arm64/ that is based on 2021.07 , the following patch causes the u-boot.bin built to use 2000 for usb_pgood_delay by default: # more files/patch-include_configs_rpi.h=20 --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 @@ -210,6 +210,7 @@ ENV_DEVICE_SETTINGS \ ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ + "usb_pgood_delay=3D2000\0" \ BOOTENV =20 =20 (Some whitespace details might not be preserved via email.) I did not manage to get having just bootcode.bin and config.txt to deal with the USB3 NVMe drive directly. (This might be because of a GPT style of partitioning on the USB3 NVMe drive.) So a full set of RPi* firmware and u-boot was required on the microsd card. Basically U-Boot was the first stage able to deal with the USB3 device (GPT partitioned) --but the FreeBSD loader needed to run on/from the USB3 NVMe drive. I also faced the "automatically find and use the UFS-root-on-USB-drive" issue overall. To make it boot as desired: A) The microsd card msdosfs does not have any of part of the path: EFI/BOOT/bootaa64.efi B) The microsd card msdosfs does have the RPi* firmware files required C) The microsd card msdosfs does have a copy of the u-boot.bin file from share/u-boot/u-boot-rpi-arm64/u-boot.bin (as updated via use of the patch) D) The USB3 NVMe drive msdosfs does have the EFI/BOOT/bootaa64.efi path and content E) The USB3 NVMe drive msdosfs does not need the RPi* firmware F) The USB3 NVMe drive msdosfs does not need the u-boot.bin G) The USB3 NVMe drive UFS has normal content H) Note: The USB3 NVMe drive is GPT partitioned but the microsd card is MBR based: # gpart show -p =3D> 63 62333889 mmcsd0 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 mmcsd0s1 fat32lba (30G) =3D> 40 1953525088 da0 GPT (932G) 40 532480 da0p1 efi (260M) 532520 2008 - free - (1.0M) 534528 7340032 da0p2 freebsd-swap (3.5G) 7874560 1048576 - free - (512M) 8923136 23068672 da0p3 freebsd-swap (11G) 31991808 2097152 - free - (1.0G) 34088960 33554432 da0p4 freebsd-swap (16G) 67643392 1740636160 da0p5 freebsd-ufs (830G) 1808279552 145245576 - free - (69G) (The odd freebsd-swap's are tied to sometimes booting various machines from the same USB3 NVMe drive and the amount of RAM varying widely.) This results in U-Boot looking in partitions with msdosfs file systems until it finds a EFI/BOOT/bootaa64.efi (if it does). By only having that on the USB3 NVMe drive, that drive is where the FreeBSD loader is run from and then it finds the FreeBSD kernel on that same drive (different partition). In turn, the kernel finds the FreeBSD world on that same drive (and the same partition as it found the FreeBSD kernel). Note: This works without involving a powered hub. The USB3 NVMe drive is bus powered, no separate power source. So far, there has been no evidence of power problems. Note: The same files/patch-include_configs_rpi.h content would work in/for sysutils/u-boot-rpi4/ and sysutils/u-boot-rpi3/ (as long as the are all based on 2021.07). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 23 05:40:40 2022 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 E8B1219788C8 for ; Sun, 23 Jan 2022 05:41:31 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (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 ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhMRs07DMz4hj9 for ; Sun, 23 Jan 2022 05:41:28 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 20N5f3Cm010409 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 23 Jan 2022 16:11:15 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1642916479; bh=1mswWN42ByTZdoYQKC5IeHvDNSiSGlIcN0qjuoch+wo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SZVjmTW41DYn9T6zEMOxY87DT6fxfz3cmpsXvGaGAdoB0t2FIsHp4UYlf5xbPS2SD nvSm2+zI/DOSRFow4Md85y6KppXpfN0cT6rSD9elGbHmHgg/b0eBRjfZYF1ORCz0cl x/QLfg+GfqkJD0XSFCmXx9ds8m75i0e9R+Zs0VRg= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 20N5eeDn010383 for ; Sun, 23 Jan 2022 16:10:40 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:1d21:970e:2d9e:8d3e Received: from smtpclient.apple (2403-5800-5200-4700-1d21-970e-2d9e-8d3e.ip6.aussiebb.net [2403:5800:5200:4700:1d21:970e:2d9e:8d3e]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 20N5ee7P010377; Sun, 23 Jan 2022 16:10:40 +1030 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 15.0 \(3693.40.0.1.81\)) Subject: Re: POLLHUP detected on devd socket From: "Daniel O'Connor" In-Reply-To: Date: Sun, 23 Jan 2022 16:10:40 +1030 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> References: To: tech-lists X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.7 () No, score=0.7 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JhMRs07DMz4hj9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=SZVjmTW4; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1479 Lines: 40 > On 23 Jan 2022, at 01:04, tech-lists wrote: > context is a usb3-booting rpi4 running main-n252544-7406ec4ea99 >=20 > I see this in /var/log/daemon.log: >=20 > Jan 22 13:24:54 redacted zfsd[886]: POLLHUP detected on devd socket. > Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. > Jan 22 13:24:54 redacted zfsd[886]: ConnectToDevd: Connecting to devd. > Jan 22 13:24:54 redacted zfsd[886]: Unable to connect to devd > Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. >=20 > When this happens, several other things happen: >=20 > 1. the sshd server dies. Already-established sessions still run, but = the server itself stops and no new ssh connections can be made. >=20 > 2. syslogd dies. so does exim, nginx, smartd, sshguard, pf >=20 > I don't know where to start looking for reasons for this. Is it > a known issue? In the meantime I've turned off zfsd as it's not > really needed in this machine's context (headless, zfs on single > disk), from what I can tell. Is it reproducible? ie can you trigger it post boot? It is very strange that devd dying would kill anything else running - I = have stopped and started it a lot while testing devd scripts and I = haven't seen anything else break. One idea would be to hack up devd's rc.d script and run it under ktrace = and try and get some clues. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Sun Jan 23 09:02:40 2022 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 32A24195A540; Sun, 23 Jan 2022 09:02:52 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JhRwC25zvz3D60; Sun, 23 Jan 2022 09:02:51 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CFC0832007F9; Sun, 23 Jan 2022 04:02:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 23 Jan 2022 04:02:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=gPu/DdcCpUE8Q1T2MguP6EJ3CAsvMHE0hYDW3j DzPCI=; b=JgCo4dTGfLAyuo/UGCSft8iqPlA33eHbzl/yX4X6YbSsJLDAZBQ3j4 8qg+jAAIlrfrwcEsTa9lmaorXacdZENNQ5GoSKT0dER1toRPbl8LAAgsi+DPo7H8 ymoXR8I94bbg8zDQq3FBYdQcuApvkSNlmn5zs0jtU2SgX7s5dO/RIvzRUe3xFVlt WnnFCed9f/NphCB4/C/XMdZ7lu4aG07qBl4rmzSKNMMPxypNp+9SA3YJFSjlTjfh Y7LrDMlXeiJgnK+nSLDU4XbGOWP5lgNbMeUze8z6oyay66B88YDvekIVBd5zKaQw 02VDu898rlM8IXXv7wy3URJ0MFJLX9xA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gPu/DdcCpUE8Q1T2M guP6EJ3CAsvMHE0hYDW3jDzPCI=; b=FgtAuEwZQQw2dN0wS8lu6OIi686LWXQXG Uio0oVod7CpQJRtIKpSEiDbbD240Nt7SYQj8s50XrpJ2G6/eAvkr0fDCKvS/kAt4 IGQHLXcs1z3q1Nt01JQQ0soOgwdeBy+ueQ+ejDa9niY24ifSNF4gaBf/FQIrJHLD bihLhSxeKgnnfOSyc0SjJupJzJp0oBhepUPXrtSOEbcZmjn7K5lv83xno8x4Gtn3 Fl8+lYcFjxcUNJv0FLPzkXI74JgKm0kTwqJVoK4Ryz/HjJ7AwuOdkpYt3s3bo0TT cY+bQM+HI5811FqQAZbr7hAFQ4uJzLdDjL1yP33jBC7qzvc/8oi6A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdegucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvd enucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiigshht rdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvtedttdekud dvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 23 Jan 2022 04:02:42 -0500 (EST) Date: Sun, 23 Jan 2022 09:02:40 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Otv9avpGPrERzERK" Content-Disposition: inline In-Reply-To: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> X-Rspamd-Queue-Id: 4JhRwC25zvz3D60 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=JgCo4dTG; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=FgtAuEwZ; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.21:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1656 Lines: 45 --Otv9avpGPrERzERK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > Is it reproducible? ie can you trigger it post boot? > > It is very strange that devd dying would kill anything else running -=20 > I have stopped and started it a lot while testing devd scripts and=20 > I haven't seen anything else break. > > One idea would be to hack up devd's rc.d script and run it under=20 > ktrace and try and get some clues. I can try that, thanks for the suggestion. Right now I'm thinking it's tied to zfsd, since disabling that service I've not seen the issue. --=20 J. --Otv9avpGPrERzERK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHtGacACgkQs8o7QhFz NAU2Fg/9ELstaa09JFiQRcoaPdpQib+H1JllL+HLpff1lxGrHgP9jU2ClZG5dd19 rdnMOgsNuRrDfz8JaHj5xQyqkvKcrGNAIomO5+MlEqWrrUA64wRgSNuNqJsaaBay 8O6M8BxG5wvRE2+9BR9zuoJGQZJOjHUBwbnX6FD04fH1F5oDolC980LQBZjqGusg 2Yd/7ZcuOCHWd3tcHUbpSeOwy75JOBBeA2gZ7pHY0VBZZRwTd3WDbSAvr4fvHj00 5rI26LdAq/1Wmau2WbCWiMk1XY46kRtgjNVxKBiirjN07u9HJpW+G0UHcuA3EPIX u7DDmgHYasESDZG5wLiYyB0oA1msw4MST5odKnofdFNnGXrtrj/t8bAxblWF3UlY empslyeHZ7TBMU7fnNgqMIqCW5i6akGZT5+fsgluBxBEzjuiFTa9/vLYduiUS1h9 z5LSt9u3NagQrEAigfcxksk5UirCyUgGj1/RnwEgiysJ3B8TW0VJnABivxrs8JBw SfYOJZW3bfXXBoRvrwac3pKj36lXfwDRyDYKrXeYL6TB1O3+iBv9XX5/sHoMeh7g uc5ZE6hNjrqeZhkyrW2Z6Iq3irTpBmDQrgarpGGenKZ/THJCn/whY7MFVb8hic+P HjSy9U3dNrrDa59leAhA7tZpKTwYPKn/D1zk6+h0EpIyWV6lhDs= =3xyV -----END PGP SIGNATURE----- --Otv9avpGPrERzERK-- From nobody Sun Jan 23 19:38:09 2022 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 E2A001975F06; Sun, 23 Jan 2022 19:38:16 +0000 (UTC) (envelope-from fluffy@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 4Jhk1N4T9Jz3klf; Sun, 23 Jan 2022 19:38:16 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642966696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RB1RYEYLpNEAoAw0Jo9G1BKqQjAAB6E7u/hL6CR1GQ0=; b=dhsCu/cFbgtLUgb5UdPJxm6dDiQHVo4AKp6buPpQzeWSCX/UhdZDW0Lg51p3w7dnoI2Bzm XxhmzVB3G4zG6LgCNJiJ4/4Q+U22kZ3b/ZSDnq1bjcUwCgIrE7Ho52R7FRfdTTVaXHxFCF TJjzErFFuLjtTOoPJAw1HYgx4PYBZBbvIUUeyClNEmX1JsO4XrBnj4d0cBJDWX7JCkzY4d 7+yUWrcJKZ7g+/zXD5+iNfCGM/tNCDjTk6MOUjnAN3rt6VEzkuze4ZhMRRrwUgkfud8gUq jy6fwnjzrmQZDh6fgVCihOvcC48WZuu9zEN2A1VtwnYQ3tHRTKt5gb6IKoMMsQ== Received: from [10.100.224.144] (unknown [5.101.143.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id BFB9D25C9C; Sun, 23 Jan 2022 19:38:14 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Date: Sun, 23 Jan 2022 22:38:09 +0300 From: Dima Panov To: freebsd-current@freebsd.org, tech-lists , freebsd-arm@freebsd.org Message-ID: In-Reply-To: References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> Subject: Re: POLLHUP detected on devd socket 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/signed; boundary="61edaea1_12200854_7d7d"; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642966696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RB1RYEYLpNEAoAw0Jo9G1BKqQjAAB6E7u/hL6CR1GQ0=; b=Fjxopk/iEuMKFWqrjX+QHoODV/SBTXNA/38x6DdOGxcbmFqspuVbaEGWaMS5qEmcvxrXdu hiZKGfiPUOa8daSE540Cs+gdzY8+KjjVNFRedWp6Gsb6GRcjkBTtJlrgwxleQYhZxLoqML Q2YY+AnnUDFzKdYb/QlWpmVKHgZ6noiAIEvcLPtk6mEO1UTdGvaIJoGyUJmSUyPYQwM1/D ZCYTNfjIELDkrhHey6t6RfOwjp4LiEGuakBeJfWAr7/rlmgbcXOGYcN3HYXRv4kEEdYNQf q5RpREltb3Ue4z2nBZtDyGgiB5l3Vg3CpCmHJoRzUBZw9536KocHUmVi23Z3Cw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642966696; a=rsa-sha256; cv=none; b=qTew6g2T733lhmRZdR+8izhWb/RR8uHphAP3R1i8HwUn5Y7E5JRKn0ewRhag7BcKz9fd+F 1T/LwO3ResxMoxCj23cqRAuR9qTbal64Pv/cQur2QrtLdEI1oLxVGF5wnTNBHD1/vLvDHp L/0p7IBzKJxz2WfA8GM1UgWRa/c5hXv1HM+wkOFuMbZfH8WQYaMMlh1lriUR8tWK9OePhO ajuujRDS/Z8zOguRts3cUgcQkzPZEO8Q3ylVovd9rfwNRvaycFJfGYCMdZ4s6LOSEq8mZC 1ivjSamghgjwDPPgRg2fAzV5fk1ouWzzqzy9ZZ+CKa4Y9nQBL8SwysHWzoYlSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4829 Lines: 104 --61edaea1_12200854_7d7d Content-Type: multipart/alternative; boundary="61edaea1_5bd062c2_7d7d" --61edaea1_5bd062c2_7d7d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Moin=21 I saw a such issue on amd64, both 13.0-RELEASE and -CURRENT. Both hosts have zfsd enabled, and after devd die by signal 15 all other d= aemons such as sshd, crond, syslogd (almost all runned daemons) stopeed b= y signal 15 too. At least, as it shows by system logs. Will try to play with zfsd disabled, as suggested. -- Dima. (desktop, kde, x11, office, ports-secteam)=40=46reeBSD team (fluffy=40=46reeBSD.org, https://t.me/dima=5Fpanov) > On Sunday, Jan 23, 2022 at 12:03 PM, tech-lists wrote: > On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > > > Is it reproducible=3F ie can you trigger it post boot=3F > > > > It is very strange that devd dying would kill anything else running -= > > I have stopped and started it a lot while testing devd scripts and > > I haven't seen anything else break. > > > > One idea would be to hack up devd's rc.d script and run it under > > ktrace and try and get some clues. > > I can try that, thanks for the suggestion. > > Right now I'm thinking it's tied to zfsd, since disabling that > service I've not seen the issue. > -- > J. --61edaea1_5bd062c2_7d7d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22> 3D=22=22
Moin=21


I saw a s= uch issue on amd64, both 13.0-RELEASE and -CURRENT.=C2=A0
Both = hosts have zfsd enabled, and after devd die by signal 15 all other daemon= s such as sshd, crond, syslogd (almost all runned daemons) stopeed by sig= nal 15 too. At least, as it shows by system logs.

Will try to play with zfsd disabled, as suggested.

--
Dima. (desktop, kde, x11, office, ports-secteam)=40= =46reeBSD team
(fluffy=40=46reeBSD.org, https://t.me/dima=5Fpan= ov)

On Sunday, J= an 23, 2022 at 12:03 PM, tech-lists <tech-lists=40zyxst.net> wrote:
On Sun,= Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote:

Is it reproducible=3F ie can you trigger it post = boot=3F

It is very strange that devd dying would kill anything e= lse running -
I have stopped and started it a lot while testing devd = scripts and
I haven't seen anything else break.

One idea wou= ld be to hack up devd's rc.d script and run it under
ktrace and try a= nd get some clues.

I can try that, thanks for the s= uggestion.

Right now I'm thinking it's tied to zfsd, since disab= ling that
service I've not seen the issue.
--
J.
<= /div> --61edaea1_5bd062c2_7d7d-- --61edaea1_12200854_7d7d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary PGP V3 iQJVBAABCgA/OBxEaW1hIFBhbm92IChGcmVlQlNELk9SRyBDb21taXR0ZXIpIDxm bHVmZnlARnJlZUJTRC5PUkc+BQJh7a6hAAoJEPuLoJ3VOY8peNgP/R0jq+eWgHaU dqZOuRE98wTHP+oEI+Zb0MhSkOFQ/NTHsCDZcLjt6Gt8S/U6pDFAY5gGtHSFXINP vQjiFjVjh5pOiDisInXEzJxIojgoC/Lws3OwTWFgmjVCyG4dre/MxquJv7r3CxSZ Sk4jfhX1nfg0+WsRaVQyOuet/hcrA/AiIfjiFcBhkk1Y5S9rwUcARJyN5s3vS4lc knuKMZHPAKXVPWLKXfV+8sKuUTr4Lkvsv4omXgV2oi+B1eWPaUzmdr9sLjRXohG4 fJojDT1/Di4Ak8I4pqBM1jUfduCxRrkHYa/D50pd4JIL2BAG1xubTpjBLjkAP//f 7VwONwUMuiJGpJCZDrXXHh4NrnTvwTsueotqLWTOL69Kzsw00HuXFEA7G9ITxNp6 tKQyGToOT0qqp4qRbqfIZnb15PsEBv3w3ZY/RgL56BaZe/QHNvb9erF0RpHd1fKk SQA7I+YlAIbQ9BT0WAaIRFvPma7UeMq7GmvyiBOIJJkovwpKlqReK8XqJxF3ddC7 PYaMPIeQ3Ecb1N3sSE/yIudMFKNQ5hb611o36Wo6nprCt5tnrhoRMtKZ5cJuPiVS PHtrYKnF6ixdL6WLzEsaukmYxoZKPZNXkeYTCmltppBUhTVYb4F5cmig7IVgxokP G30/gY/RYXXs1dY1HI0B1U1FTl6d6OvN =OZ4V -----END PGP SIGNATURE----- --61edaea1_12200854_7d7d-- From nobody Sun Jan 23 20:02:26 2022 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 68FB41984321; Sun, 23 Jan 2022 20:02:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JhkYL2Dhpz4cNW; Sun, 23 Jan 2022 20:02:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642968150; 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=JgFRS6huPO4FtmiAp6oABiEwlZduhCaF4Oe5SJQli9s=; b=d7ERgE6HRF95rFRvN7dZj6pto3t3/qmGBZfwKRiXZfCKaDPy5Mq0vdLiRUDUOOdqtGjxIC GNu/kiPK5UF/e81e+KU84rSD5VQOadWmV0rPY9gtyHYpJ5TCNOJTsGYq0lE09fuu8GQkbS Qtqo7OT68Tbp02Po712kDWsjz/RpiztrAfooWZ0XrTyHD5YlZWqsPclaL+pR4xXgeUlzyg Gd8maiMQEIqXGbBW5HITuz6AtqEREzkNG++ZPZj8KfN9ZVDfTXz/PkZqPx7PGQ7JSak+lQ Oy6+QeBPpIYN8v5qcrjGuihS+ZG2DzgBVFOQ9nZGZ3zsjhStVxKiKs2DJATTMw== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 81FBA25DED; Sun, 23 Jan 2022 20:02:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <5e436448-7ab7-8d10-011c-e4e52cbb53aa@FreeBSD.org> Date: Sun, 23 Jan 2022 22:02:26 +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:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: POLLHUP detected on devd socket Content-Language: en-US To: Daniel O'Connor , tech-lists Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> From: Andriy Gapon In-Reply-To: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642968150; 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=JgFRS6huPO4FtmiAp6oABiEwlZduhCaF4Oe5SJQli9s=; b=HVs56aPo1hYFkWRvDExyMH480DQgQdCy7aZzUz2f2ZJbPlfL+w7t737wqkJe6LsETgpv+N 04RlWIzGmS2VlgJoTB9Bt259uz1MO3fO3nzgjjrIH3x5XZp/slS7JtsnTmpdnPlVHpKNXa izE279mYhoNblrE4vgZ6bqf94zqKxfedHzUUUXizt/S1IU7PZb3IeI7bZ4Y8C9FpqOJPZA 1NmJ6onBztIISMCtJrS/hCmJ5TkGdk+30f/SIfIfdpghsucLxguiZGXsHQbitxl+A7UUPA rxNHyMblBgPRSkMi0ckDpZ0TzVUe+cUPw5tTNIpNwIMjWu/NohBFG509mPWLIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642968150; a=rsa-sha256; cv=none; b=Nz8J7L1p1Mq4NTXe+YJszrzZFVH7wt1uKYYoPC49Il1ksvNqQu8mCDqdgvj+Mbo8cJ9inb vvtkvTL9hFx4FWbSO65aXfGhS1vvaafiHMjVxuusWNUHkbqpjHeU+GsAX7SWzBbn3yakSL 9a8AO5JXuiiOn2CSMUC9Je/Ps4kqsdnxgU5aA5k4VpSKjcmXFa8TJsCNq2YIpRodQtfHgp gwBLMKTBafuAmmqrMfMpxZ+ytRcoC0FG7WHBE6HOoqZ8E+9ium8SMC9Omf7KM789gLb2tl 6Etx17DNiu53NTy3x9QmkftVoeu8/6N9Q6L3OOZt2Vz8XWfO1t+k/vZ2B5FkBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 225 Lines: 8 On 23/01/2022 07:40, Daniel O'Connor wrote: > It is very strange that devd dying would kill anything else running Because most likely it's a correlation, not causation. Many things die and among them devd. -- Andriy Gapon From nobody Sun Jan 23 21:00:48 2022 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 762FC1976974 for ; Sun, 23 Jan 2022 21:00:50 +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 4Jhlrd2ctnz3nCw for ; Sun, 23 Jan 2022 21:00:49 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 CEF801157 for ; Sun, 23 Jan 2022 21:00:48 +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 20NL0mfg027641 for ; Sun, 23 Jan 2022 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20NL0mjQ027640 for freebsd-arm@FreeBSD.org; Sun, 23 Jan 2022 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202201232100.20NL0mjQ027640@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, 23 Jan 2022 21:00:48 +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="16429716480.4a3ed.25946" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642971649; 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=nkUj/RBTDvOUg5hfS4Tbe52zb6xtUj/4ZjHm0YuzekY=; b=iEBmiY1/xadsvWOw9SZKkbp1n028VQ7rxMm636hZ49yJLLQuPH8fIANjom/86y/+QsK6iB ke2sJOeNWuwkrC2jVj72gpe4WszRoH5d/yi4FjnbmE6awJi7slddwjnI2mfO+BMfDhFvw1 P3QT9yQoolmUB1JVtrR4s/lmyG56GmEPcZasIiAv9Dw2Xw79vQjSBEb2zBoDpC0WvY1G9K cDCcYAKpXLlxQV5sQXrMqwO8YO4MkZzJ+KNaWpWHU6rwtIxUHmL0012oDC/0mhMY8pTjeV E5H91w46i0m5y3KTy87dUy9wxdfVdbvvo4yuUNWY28QsnX2FN+DpxOhxRxxVrw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642971649; a=rsa-sha256; cv=none; b=lVzlV2OUHpXQ8h712zK+bTaY4njFq0URityAiiYR5vk1xflbkcMiIJVBQJYOUfjgoa2F6P dJrFxepUgZFZplGxiz+7urlQImKk/Vhp73+AwCoEhXfTj6CnGiWdxozH7aEunQ8QxA5Efk 6FQ715V+ZMSFUkcLrajxnf8Bpf56EcI6/ifVdN54n+scsFvNNAlBw294WZsMmAyXRGMk0M C8nYS2bHGfeTMyPbvuVvdi6Cy8z8CR029571URn0KXOLfVNrxsaZj6bVnbSvr+BmrFzPcN AWFUoDUGmQ9sFV5isQQQGKhKROJxZkMM3t8C/0MV6RRuFVBnfoGzMoAScIfd3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1798 Lines: 38 --16429716480.4a3ed.25946 Date: Sun, 23 Jan 2022 21:00:48 +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. --16429716480.4a3ed.25946 Date: Sun, 23 Jan 2022 21:00:48 +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.
--16429716480.4a3ed.25946-- From nobody Sun Jan 23 23:58:27 2022 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 73794196877A for ; Sun, 23 Jan 2022 23:58:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 4Jhqnp5V3lz3lpS for ; Sun, 23 Jan 2022 23:58:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x932.google.com with SMTP id b16so27787835uaq.4 for ; Sun, 23 Jan 2022 15:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nFj+MsrS32BMYy5lHIifMDiR1PbQCF1epl53KH6sjXQ=; b=lnNeEInd6WFw8M8FA3KfCDUN33GDQ7rANX8oMmlJmahWo3QZMR+XSl4WNyjWTJib5d QwN4WPrS/3kmHcC2aJZO0GM/X8btE1KDNvKJFo9UuevciTMjwm69GFH0qjfvKSqbGWB8 rRH3AjVuMbes4b81dO/xlrLXupJqh/QLNQP/MIVL4Td3Ku/HKV+oOfCxTkdI0sFucUbf UcWybe8qfGi1QMucu5nFrmvOwejy+OWe9bzejXFGbFSmV6ubAtpCctoX5uFX2Jwp/G6X QJ+hAbtv2k3m9X62SgOUJw2K9+9YjkEOwofP3ZhQWt2b8cvENnmi8+p7+L7H81cMb590 OOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nFj+MsrS32BMYy5lHIifMDiR1PbQCF1epl53KH6sjXQ=; b=MA8ANZpbJn3doD0rubNjOl6KZbmhzeDgHmpGwb/iRDo7wxhNeAEAMqJ1uyJRjscCmL RoPf3dz/gZny/l1E5GjUcu49PRjjQ2R51QMkg/q4QjLdtKHGKpubdIw9JWB1NfMyjG2o Op451Uc1js/zWbT3THFXG2jmVmVIlbaOZ1SkkdWO5cUytWrngJrM8f4FTsF0nhSOiGCV t0Lknd0zn4h9sKrjaefjRgwdX2KXjk9Hfnf9jeBpM8qwvLH21QIWWNOZ7TR5PMzYfEDL lPizUySIq7OHi49aB6wBx4s+FMH2fa8+nNLbXOtYKyzF0a40VixkcuOEaGDOmotHV1X6 1TOw== X-Gm-Message-State: AOAM532SUO/lXDlQNa1dtC58bugtgAy5uJYcbbLVPJO2V//w1DjILvcm YT+JB5KuLwkYmNmYSjjTF56d1IBXtjv0+fdLcucDaA== X-Google-Smtp-Source: ABdhPJwj9JmLz4cZYeJmi7VTPB42pVh6iCIf3+Ku9IZd+ymOtngUCKcUMaR47WaKi4+j7pc1eXbEJuR7oHOSQKnXNWM= X-Received: by 2002:ab0:23c1:: with SMTP id c1mr4535539uan.11.1642982317823; Sun, 23 Jan 2022 15:58:37 -0800 (PST) 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: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> In-Reply-To: From: Warner Losh Date: Sun, 23 Jan 2022 16:58:27 -0700 Message-ID: Subject: Re: POLLHUP detected on devd socket To: Dima Panov Cc: FreeBSD Current , tech-lists , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000006d2b8105d648a136" X-Rspamd-Queue-Id: 4Jhqnp5V3lz3lpS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=lnNeEInd; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::932) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.83 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.83)[-0.828]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::932:from]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4479 Lines: 93 --0000000000006d2b8105d648a136 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 23, 2022 at 1:07 PM Dima Panov wrote: > Moin! > > > I saw a such issue on amd64, both 13.0-RELEASE and -CURRENT. > Both hosts have zfsd enabled, and after devd die by signal 15 all other > daemons such as sshd, crond, syslogd (almost all runned daemons) stopeed by > signal 15 too. At least, as it shows by system logs. > Signal 15 is SIGTERM, which is the software signal from kill(1).... Warner > Will try to play with zfsd disabled, as suggested. > > -- > Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team > (fluffy@FreeBSD.org, https://t.me/dima_panov) > > On Sunday, Jan 23, 2022 at 12:03 PM, tech-lists > wrote: > On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > > Is it reproducible? ie can you trigger it post boot? > > It is very strange that devd dying would kill anything else running - > I have stopped and started it a lot while testing devd scripts and > I haven't seen anything else break. > > One idea would be to hack up devd's rc.d script and run it under > ktrace and try and get some clues. > > > I can try that, thanks for the suggestion. > > Right now I'm thinking it's tied to zfsd, since disabling that > service I've not seen the issue. > -- > J. > > --0000000000006d2b8105d648a136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 23, 2022 at 1:07 PM Dima = Panov <fluffy@freebsd.org> = wrote:
3D""<= div id=3D"gmail-m_5433901728503372578CanaryBody">
Moin!

I saw a such issue on amd64, both 13.0-RELEASE a= nd -CURRENT.=C2=A0
Both hosts have zfsd enabled, and after devd d= ie by signal 15 all other daemons such as sshd, crond, syslogd (almost all = runned daemons) stopeed by signal 15 too. At least, as it shows by system l= ogs.

Signal 15 is SIGTERM= , which is the software signal from kill(1)....

Warner
=C2=A0
=
Will try to play wit= h zfsd disabled, as suggested.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team<= /div>
(fluffy@FreeBSD.org, https://t.me/dima_panov)

=
On Sun= day, Jan 23, 2022 at 12:03 PM, tech-lists <tech-lists@zyxst.net> wrote:
=
On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: <= br>
Is it reproducible? ie can you trigger it= post boot?

It is very strange that devd dying would kill anything= else running -
I have stopped and started it a lot while testing devd = scripts and
I haven't seen anything else break.

One idea w= ould be to hack up devd's rc.d script and run it under
ktrace and t= ry and get some clues.

I can try that, thanks for the= suggestion.

Right now I'm thinking it's tied to zfsd, sin= ce disabling that
service I've not seen the issue.
--
J.
--0000000000006d2b8105d648a136-- From nobody Mon Jan 24 16:54:49 2022 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 1B5151982746 for ; Mon, 24 Jan 2022 16:54:52 +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 4JjGLM0TJlz3LlX for ; Mon, 24 Jan 2022 16:54:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20OGsoMo040060 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 24 Jan 2022 08:54:50 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20OGsoLQ040057; Mon, 24 Jan 2022 08:54:50 -0800 (PST) (envelope-from fbsd) Date: Mon, 24 Jan 2022 08:54:49 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Troubles building world on stable/13 Message-ID: <20220124165449.GA39982@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@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 Content-Transfer-Encoding: quoted-printable In-Reply-To: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> X-Rspamd-Queue-Id: 4JjGLM0TJlz3LlX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 8197 Lines: 173 On Fri, Jan 21, 2022 at 11:14:32PM -0800, Mark Millard wrote: > > On 2022-Jan-20, at 22:00, Mark Millard wrote: > >=20 >=20 > It does no good for me since I do not get a failure, > but you might try (instead of exectuing the .sh file) > (I used \'s to split the huge line): >=20 > lldb -- "/usr/bin/c++" "-cc1" "-triple" "aarch64-unknown-freebsd13.0" "-e= mit-obj" "--mrelax-relocations" \ > "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-fi= le-name" "gmock_main.cc" \ > "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" "-fno-rounding= -math" "-mconstructor-aliases" \ > "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" "-tar= get-abi" "aapcs" \ > "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" "-dw= arf-version=3D4" \ > "-debugger-tuning=3Dgdb" \ > "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googlete= st/gmock_main" \ > "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" "-Wn= o-format-y2k" "-W" \ > "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" "-Wcast-qual" "= -Wwrite-strings" "-Wswitch" \ > "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" "-Wred= undant-decls" \ > "-Wmissing-variable-declarations" "-Wno-empty-body" "-Wno-string-plus-int= " "-Wno-unused-const-variable" \ > "-Wno-error=3Dunused-but-set-variable" "-Wno-deprecated-declarations" "-W= no-deprecated-copy" \ > "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ > "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/= gmock_main" \ > "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" "-fgnuc-ve= rsion=3D4.2.1" \ > "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" "-f= addrsig" \ > "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" >=20 > and then "run" at the (lldb) prompt. It might stop and let you > get a backtrace (bt command) in addition to whatever it reports > about the stoppage. That seems to have worked, to some extent. Here's the transcript, in single= -user mode: root@pelorus:/usr/src #=20 root@pelorus:/usr/src # lldb -- "/usr/bin/c++" "-cc1" "-triple" "aarch64-un= known-freebsd13.0" "-emit-obj" "--mrelax-relocations" \ > "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-fi= le-name" "gmock_main.cc" \ > "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" "-fno-rounding= -math" "-mconstructor-aliases" \ > "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" "-tar= get-abi" "aapcs" \ > "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" "-dw= arf-version=3D4" \ > "-debugger-tuning=3Dgdb" \ compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/gmock_main"= \ "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" "-Wno-= format-y2k" "-W" \ "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" "-Wcast-qual" "-W= write-strings" "-Wswitch" \ "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" "-Wredun= dant-decls" \ "-Wmissing-variable-declarations" "-Wno-empty-body" "-Wno-string-plus-int" = "-Wno-unused-const-variable" \ "-Wno-error=3Dunused-but-set-variable" "-Wno-deprecated-declarations" "-Wno= -deprecated-copy" \ "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/gm= ock_main" \ "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" "-fgnuc-vers= ion=3D4.2.1" \ "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" "-fad= drsig" \ "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" > "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googlete= st/gmock_main" \ > "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" "-Wn= o-format-y2k" "-W" \ > "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" "-Wcast-qual" "= -Wwrite-strings" "-Wswitch" \ > "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" "-Wred= undant-decls" \ > "-Wmissing-variable-declarations" "-Wno-empty-body" "-Wno-string-plus-int= " "-Wno-unused-const-variable" \ > "-Wno-error=3Dunused-but-set-variable" "-Wno-deprecated-declarations" "-W= no-deprecated-copy" \ > "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ > "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/= gmock_main" \ > "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" "-fgnuc-ve= rsion=3D4.2.1" \ > "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" "-f= addrsig" \ > "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" (lldb) target create "/usr/bin/c++" Current executable set to '/usr/bin/c++' (aarch64). (lldb) settings set -- target.run-args "-cc1" "-triple" "aarch64-unknown-f= reebsd13.0" "-emit-obj" "--mrelax-relocations" "-disable-free" "-disable-ll= vm-verifier" "-discard-value-names" "-main-file-name" "gmock_main.cc" "-mre= location-model" "static" "-mframe-pointer=3Dnon-leaf" "-fno-rounding-math" = "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "generic" "-target-= feature" "+neon" "-target-abi" "aapcs" "-fallow-half-arguments-and-returns"= "-debug-info-kind=3Dstandalone" "-dwarf-version=3D4" "-debugger-tuning=3Dg= db" "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/google= test/gmock_main" "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werro= r" "-Wall" "-Wno-format-y2k" "-W" "-Wno-unused-parameter" "-Wpointer-arith"= "-Wreturn-type" "-Wcast-qual" "-Wwrite-strings" "-Wswitch" "-Wshadow" "-Wu= nused-parameter" "-Wcast-align" "-Wchar-subscripts" "-Wredundant-decls" "-W= missing-variable-declarations" "-Wno-empty-body" "-Wno-string-plus-int" "-W= no-unused-const-variable" "-Wno-error=3Dunused-but-set-variable" "-Wno-depr= ecated-declarations" "-Wno-deprecated-copy" "-Wno-c++11-extensions" "-std= =3Dc++11" "-fdeprecated-macro" "-fdebug-compilation-dir=3D/usr/obj/usr/src/= arm64.aarch64/lib/googletest/gmock_main" "-ferror-limit" "19" "-stack-prote= ctor" "2" "-fno-signed-char" "-fgnuc-version=3D4.2.1" "-fcxx-exceptions" "-= fexceptions" "-vectorize-loops" "-vectorize-slp" "-faddrsig" "-D__GCC_HAVE_= DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" (lldb)=20 (lldb) run Process 58516 launched: '/usr/bin/c++' (aarch64) Process 58516 stopped * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid addres= s (fault address: 0x1) frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined]= getPointer at PointerIntPair.h:59:58 56 =09 57 explicit PointerIntPair(PointerTy PtrVal) { initWithPointer(PtrVa= l); } 58 =09 -> 59 PointerTy getPointer() const { return Info::getPointer(Value); } 60 =09 61 IntType getInt() const { return (IntType)Info::getInt(Value); } 62 =09 (lldb) bt * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid addres= s (fault address: 0x1) * frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined]= getPointer at PointerIntPair.h:59:58 frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined]= isNull at PointerUnion.h:172:43 frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined]= empty at TinyPtrVector.h:166:13 frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() [inlined]= empty at ParsedAttr.h:873:40 frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at SemaDe= clAttr.cpp:8449:16 frame #5: 0x000000000317e784 c++`::ActOnClassTemplateSpecialization() a= t SemaTemplate.cpp:8537:3 (lldb)=20 [repeated bt commands seem to duplicate the same output] I can't make much sense of it, but perhaps others can. It does look as if I've somehow corrupted c++. Is there some way to bootstrap past the defect? All the clean targets I've tried (clean, cleandir,=20 cleanworld, rm -rf /usr/obj, cleandepend) seem to have no effect, singly and in combination.=20 Is it possible to simply delete /usr/src/contrib/llvm-project and=20 let git reconstruct it, then force a compiler rebuild somwhow? Thanks very much for reading and all your help! bob prohaska =20 =20 From nobody Mon Jan 24 18:26:26 2022 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 7687C1974C52 for ; Mon, 24 Jan 2022 18:26:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjJNG2rF7z4ll2 for ; Mon, 24 Jan 2022 18:26:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643048789; bh=9XTNxZQhjjWtp5NL6PrWeeB4+OmN+EPDELte3cwhEAk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Kip4i+JEF0sAwggGmll/1aZRFJi4qRL/CAlQaVVhbOX/jxVwjBtA2Fs071H8uFzkdV1Ww1MpRNI+T/fMXHZ+s5sfys5VBwS1iFhxMPw4lc6KPQSRXfYcaNXncXUwCyuwVC6GGEQ8Wj6YvGHGEhYiUiZh6XIxKuSlf7FO3+OfRuzp74D8g7mhC/LWwS6qaOlqYPTW2uxBiOA1VXpD80JoKjVEpwaN2749Rt1y/7LOUN0fwN9LuySHIU6EzoemVIsWNC1UzPCFpPZsI9HhvThQkmlr+8YkbasbuWL+boMKgwTXGycyoochyD/82vaNqxeKMgr0MnwZq+To0zMiVEX5zw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643048789; bh=h7i4kXyesrKszqMKOthmw//VZdw25M4j0HHcrPFRYTi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BpQQtIk3P4cChAchb5Vqpja8NDrFsyVKoheBoIPcVsN9pgTj0bX+6u5q9k77gQdAVTp/eg77tsI4WEJZNZ+M/pQmflYWhW5W2tJy4EQfZ8NSfTLNDe7oR/yKUog2xuiniHvv39cDlVd58qyvExYiN0Bp+GW+diB9M1fdGx9qZZJ8KlllndmBgIAyV/EAYvOhxCh4CzV1AaxKedO5WKApTMj43ZfqJjJ6Lg5hr1hwp8EW9pXIZT5WiLq03RhC6DlSYEgDOvidEkShuLTjTZbmMdBvaLzY3nvB2e/4rzzbx74ymdo/s5ts2R3uaaeOhAqSKTGdRqXmD5n/7vnnaivUQA== X-YMail-OSG: qVohV6QVM1n3_sN0VSaN_fsnU2WPpGysQoxvL_mORBaRcmm825MB1FS6cmYzEpU c8oZ0mAeylS7VWoDx1cGXQthPXqfJs4GsBqO4_2TzwOu8di_jQA9HvCfunPCRc5Lc4jEgP4YJIyj FB6n1qvi1y8mHrK2WURlM7Uo7VboRVJ0bvvFvDBFskuMKFXyxCzD6pQvnELFyZz.27omOg2i.yQ5 x7PfHtQRGVEBlzA3K7goStK7eYfHF22l.34nqOH3KqPZ7ibD_3kuxRxDg76.qoq3n2Lt74P19Lmb 3qIzsPWBOK1qHfbrUns6fcDD54m3Xq2IYjjWgF4AHBtmkmsH0xedn.xrZOlM7xbG_nKCSQza.IdQ ttqfYTIeBBIvRaOd_wcM93RPOu6TqyxtCQAo15FC1fAb1v0fK4noBK2yne4NEc3Wi5imFgiSLulb B3JKzalzj2_l.XmrpbHcUScVparp43myGgJMifqQF5bNLkHbUwwkW3N5Cg5kSKNkDpsUg0Oc6rX4 gH56BHjCsM0DfZVNuDwf5sdo_AwODzmo2LeLbXBCfNPIdZkRnoCX30yqJ6dpExhVV0RPTr7xpqjo cE7kWmcWojkUDC51pj9BpD5hggSFyxwtNWkbFizKHjvGqUBOw8DHMCXWzkYwgnyiVsvKtyx0gMlk Ix4crjX1vjhlaIysBYFQ9qlsSVONcXnROf5lscTc57HyIxbk4LVrCiDASixpMrhL9iPoNSsETI8T kuuH_W1UYGOt3rCoX6CxRwDYqSBVjJHIulapE.8WfylfcPZcJEFUm7VgAmF2viqtsAzIn6IUphNB 3S.giqTlov0SCcFw_CkBaqkkJEoe6l12QZTdmfEkbVB8165H9PMVn1CJdHOnH3G00DI.sPsE3sMM 5kWIBykYv8KSz9_rCB3lZ06qtuiqj8zuCaPgGSBPGXPFm.WhJaqJNmjXRiOmvhLe4uf9Pbg57LOt KeIbBnG1eiqSjcnaeSo1brSdx6IU3wQfXSetrRSz0KpcznmOsEbiP9aheGssVzks_XKT32dAhLxi v8s5abNRigPSLwX0cnI6zK8yXDtVGikKxOAVrASOv0gFSdrhNmC4Qk6ZHhRzITXECDr.5FQtaFak GSbvJLLjhADU247xaEGV5CDWEmR9ViowPH5XSZ528hg4kg7LFMKH8UhDNN215QzNYqP5gtJUIp.j F8KNpXqH6dfkRteZDN1nyI.AycjhkO3OXWkNMiCw3VSGuaHT1z1yKGtf9Ql0gk7HzwP92eSNYYG2 NLSn58Ewb5SsLWTFvvLfmqe9RYuyJ3FkTLkehW2umj4FN3kwVbO_8TPCyNskJPXoHgvmQSF6zY5q MgWvM6ftJFZqy6DVMCuVgwHjPBvg8BhY94QVnDDu45kxkqze06K9u9jd7TgK.IFUtdlKofQHE2tV 8Br3ldO45oDIxwj6wm29fB2IuhSoMn1FxBIQiRzrZN6mE_v7lPPuqN702RPg6vk6HySVm4r7YdPA NQPD_Yr4zis4Po0MNrn7q3.paZnJLb6SBovGH0TcaS281dHmS7LQmboNdEh2n0ERO23IRE22c.ud cblNUDpiYkIhr2KfVgJoirWnIPFcbNriqUUr4BVIHYBW1ZDuBEwYnhT6OquNzD7BguGRwvEUMQag MlXdOLBeHb.hs4ebzQg8VeKNLkwZ7md8t8sbCBe.nJ2Agl4eztghZuR.U.ccdwjaFCyebEzrFFsF LXgxgc6pkYgwledlEwX6Keya55s7wUkIr_GqQUSe9h.xpezBJMC2_XZ7Xz7FlPo_8Hc.fbnODFqv i84apXI48UEIAIeBRbyrhkBNXBg9fKsowhzDKAXKE88CKlx3ZVh7KP82HIFaTPxbGGZKByRAHOda ZC16SD4kWvsdaciXkJsIoEw3xcnDadjtGGxiIvzR.sJ3ciZ304AvhrnpWTrld2YNXMKieccNtQkF ZMZXxEVJmkcV4Jr43.GDtkbTR5ZnpnELePDupd17IIb0JB34yDIYvuD0fERE7l0Upt27iO8kvJm0 tD9O96nGgrPGq9XYbaBIakvZ_dR4xb1VOm8yAXCwFZpfbNHsm0NvkhBrNnPO6y18KpZY3Tn8LdWI XP_2FHlMspQc5w0F5Xqsw3YkkCa7RrYnDWuMj_fcZbqOalhsAKnz3nGJQkzgpMvCcJnXWhnmE9ox yibG2zHQLVHxG8r.WDUVgtcM6SazAzjsodiL0xPVWkhkSXBSVlZlWfikEUTqu_yURjeVmYllahRx s0ubJqrALpfOjUoJUA11rUgcXIqJmoj0P1JzcV80A6qF8zR7J4AvtNwt_kbLxURV2vXdtqb6AqEZ BAEuSUZJvpYM4 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Jan 2022 18:26:29 +0000 Received: by kubenode512.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 80d7ae90596d8bb0063ede849db057dd; Mon, 24 Jan 2022 18:26:28 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220124165449.GA39982@www.zefox.net> Date: Mon, 24 Jan 2022 10:26:26 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JjJNG2rF7z4ll2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Kip4i+JE; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5375 Lines: 145 On 2022-Jan-24, at 08:54, bob prohaska wrote: > On Fri, Jan 21, 2022 at 11:14:32PM -0800, Mark Millard wrote: >>> On 2022-Jan-20, at 22:00, Mark Millard wrote: >>>=20 >>=20 >> It does no good for me since I do not get a failure, >> but you might try (instead of exectuing the .sh file) >> (I used \'s to split the huge line): >>=20 >> lldb -- "/usr/bin/c++" "-cc1" "-triple" "aarch64-unknown-freebsd13.0" = "-emit-obj" "--mrelax-relocations" \ >> "-disable-free" "-disable-llvm-verifier" "-discard-value-names" = "-main-file-name" "gmock_main.cc" \ >> "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" = "-fno-rounding-math" "-mconstructor-aliases" \ >> "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" = "-target-abi" "aapcs" \ >> "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" = "-dwarf-version=3D4" \ >> "-debugger-tuning=3Dgdb" \ >> = "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletes= t/gmock_main" \ >> "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" = "-Wno-format-y2k" "-W" \ >> "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" = "-Wcast-qual" "-Wwrite-strings" "-Wswitch" \ >> "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" = "-Wredundant-decls" \ >> "-Wmissing-variable-declarations" "-Wno-empty-body" = "-Wno-string-plus-int" "-Wno-unused-const-variable" \ >> "-Wno-error=3Dunused-but-set-variable" "-Wno-deprecated-declarations" = "-Wno-deprecated-copy" \ >> "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ >> = "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/g= mock_main" \ >> "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" = "-fgnuc-version=3D4.2.1" \ >> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" = "-faddrsig" \ >> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" >>=20 >> and then "run" at the (lldb) prompt. It might stop and let you >> get a backtrace (bt command) in addition to whatever it reports >> about the stoppage. >=20 > That seems to have worked, to some extent. Here's the transcript, in = single-user mode: >=20 > root@pelorus:/usr/src #=20 > root@pelorus:/usr/src # lldb -- "/usr/bin/c++" "-cc1" "-triple" = "aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \ >> . . . >> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" "-vectorize-slp" = "-faddrsig" \ >> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" > (lldb) target create "/usr/bin/c++" >=20 > Current executable set to '/usr/bin/c++' (aarch64). > (lldb) settings set -- target.run-args "-cc1" . . . "c++" = "gmock_main-f5c28a.cpp" > (lldb)=20 > (lldb) run > Process 58516 launched: '/usr/bin/c++' (aarch64) > Process 58516 stopped > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] getPointer at PointerIntPair.h:59:58 > 56 =09 > 57 explicit PointerIntPair(PointerTy PtrVal) { = initWithPointer(PtrVal); } > 58 =09 > -> 59 PointerTy getPointer() const { return = Info::getPointer(Value); } > 60 =09 > 61 IntType getInt() const { return = (IntType)Info::getInt(Value); } > 62 =09 > (lldb) bt > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > * frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] getPointer at PointerIntPair.h:59:58 > frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] isNull at PointerUnion.h:172:43 > frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] empty at TinyPtrVector.h:166:13 > frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] empty at ParsedAttr.h:873:40 > frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at = SemaDeclAttr.cpp:8449:16 > frame #5: 0x000000000317e784 = c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3 > (lldb)=20 To look at the different frames: (lldb) up 1 (lldb) bt . . . (output) . . . (lldb) up 1 (lldb) bt . . . (output) . . . and so on until #5 has been displayed. > [repeated bt commands seem to duplicate the same output] >=20 > I can't make much sense of it, but perhaps others can. It does look > as if I've somehow corrupted c++. Is there some way to bootstrap > past the defect? All the clean targets I've tried (clean, cleandir,=20 > cleanworld, rm -rf /usr/obj, cleandepend) seem to have no effect, > singly and in combination.=20 >=20 > Is it possible to simply delete /usr/src/contrib/llvm-project and=20 > let git reconstruct it, then force a compiler rebuild somwhow? Using git status should report on any files that do not match what is in .git . In my context for main [so: 14] that would be: # git -C /usr/main-src status . . . (output --if any) . . . You would likely need /usr/src instead. Using git diff would show the specific differences. In my context for main [so: 14] that would look like (if no differences were found): # git -C /usr/main-src diff . . . (output --if any) . . . You would likely need /usr/src . If these do not show anything, the source code is not likely to be the problem. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 24 18:29:08 2022 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 0B81719777A5 for ; Mon, 24 Jan 2022 18:29:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjJRM15vfz4n7n for ; Mon, 24 Jan 2022 18:29:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643048951; bh=LZUTcLsZaRUrqMqt3MbJqo+/lSq8u/MuoVmYxuIj+N8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DMFdY/zTDYmXFs05vdIMIbgisLPvtNW/L9TiIsOx1rzhkCvEiIiLnJTARzsVKYLxFNxLfHOgTSK7RFfyP2QQKZABWJKSLDbiAVqxAWKunc0Ep/n9TM3Yjbn8gBV6HLJgDsgDgA8++iDhGTjyZSGXTOViir51OHDx17Z7vcgt0NQnom/hin6IJ9tylx/tyAr9JQj9W0pE3wMLXUUbmnb8VHAFRrSJASwYjhG9N9OuaZEFS8KZcpGGVVB+QkcNYChBeza16hr6Hah2WTuz+t4M8sstsOkXHYw8fy9zL1Ec+qZexXM5E8fLRGyHNybHR/zTn6+r56CtlXSjyRcBlHo4tg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643048951; bh=mzorULgZDUZeMibEFvEez2RmIoU6INyj8dm50GkHFU+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=H9tv2/7eyzxgT10aLnRjMYxh14mHQamK2tOvbW/+N8779kJZnTWdToSb3WcRYiE+mCQxR0oC3wZ3Xqhz8OyaopotElgAMve+MBgCRnYdF0zbY/WK1/g1v1YFamiXK2AbAliPdSEaoY3O2P6xd/SmrvmMOyJmzIWZnlmL/V2JMKYrVEVvvJ3aaO/jOFzwhiEGHOH1GmIjMkZL01Zu+vAa5T8NV/ZovCBderWJW/irf+VM0/NzF/MVbvFtiJncX5PORGFbypfRgotvJKnEQYEegQ5zOjFylVrSTIwfqsjWqz3Eyk6JN1mrKGbEqVRDR34J+s5WAplgEehZv7AEKfrHqw== X-YMail-OSG: otf45QcVM1lM2vsdA4NYNnMOSvO_nRYzsV6zjCgMT08m4MxLwkcdm5b4U9oQAeO 54HEfiqIQty0.X2UejHfforRjCvIQcZFS4Y0UbZMBxu3oR2aZfk00z7hFWNVuc3FEV77fG6RsHcW .TpyfZm2Z3hIytvo1cHqyMKHNlS86JeauHRRNiqQzi95sUsDYCfW94W9JL2oyE2RbnLV4NaeTvsn 1MjWthtmAoYVHlZvKaWGt9i0Rxl7uhxDssaE6aqdFOd88orImzOcqVG5DQkl5Lj0BxnOkAqpqV0A xNSa5kPzkNIkls.L1gyGtirGt81Bj8DDuLukI2jUAus5Yye9TcWNebfiK3GqVeA7HFQ72ZiwqPXp 2JAAITCJH1Ten9AiX_E88fiO0PvsnX_swJhQJB73_68EbTy49cmqzJWtRmSawVcnAcIL_FKVDgqP pWmSwt08EpfeEMN_TJ.7zoO996Mxwcf3MnRmoZOtaGSUGFtpDxHxajKZwLJPlW9INULFpd7LxeMa H7tgzgkp5b3fcBnQYMvb05dNUUQT.PNvlGg_gitnaDsb5F.DSaltzr3R0PgKIJlAEAknCLq.knYw 42WXKdPhyFwnseSO0MmzMhvCzD9c8p.lBvBJ4CKAEgrqt9kS66qNvvsIpjf760bcgTDu0pz7rmH_ AUfKyAEGxpGYpkc0c8KoG5Qv2u6kBH.xaCJaw_GwTszbQhy0eGQHKrYQbaoNbQqKkc.nfFKvPvFp 2ECAN.6fJpE_czCqy9fi3DJGo8jzvwc5GThA_XV4EBtKQ5S2dMhVZMv3kHNi9CszT9ymXnl7ok5q vooWOQ8lPlhfpa8N0GiFLRNupR7WeKS.3mZFnXJEQ6z6aqpOLAfAncTbgwk3wWnz.E5Fp1XwVYeX ohj8SSM8QBPA62zssHprkhumH9flsc2oYF5pVTCd.gb8kMliTR_2v6hd0_miWy1pUQqx3i92PKSM ebvBcbJnvkkuiPXg7IIq0nSxhNxx..FrhutbChq8vGVhUJLtlUK_k0_ZEn7bX6kQrpKorxjvK5yU UZ9W8dPaI22.2VLZ2_H2kTPO4yjl.baxGlA3nQED0lBh3_gSto9mR5gJWKYcmIU7T24SDJI_cz2A qMwGD5wcGSDvjuK.vWAlf4NCUskFftH.rRQ4QsIlKtezzHsE3PnC9pM_qhD13EnYM45unkCd1LYs aUlU9pjGOA9HxODrQj6oAsJG6bdun2Y5lz7M39a7dycku1e_qx0vgmuYubY4Qx78AgTYJ4dPyS7T mMA52eK6MtaHIvWlhoYX24_C.6EyqqyrcHha0f_cufpA61j1ztNbtAorxgsOKJLPDq7GYEsgy8vA q1VX0_9DPEhebt63Fms3WUY4ZE4bMl4iLo8aFxEB2Pbk0w9biPTkCkOaF27GRfG97_kI53xl6hPN PnMX9RHRU4DC0qbx24MykuaEVVDvs4pTjBk7qpLvQv_YqZpt1uoqFoun_VqyLCcx8F8y.lzhbTqL 6Fcb8apZSB6AeWqN3ve5pbgn0SR6ryMbbfuknND0c24iojcaoT1HnebiLJPCsPe7mRS7t7oLQ9DM lLBn83n1vDsKbzc4AKcq5ksoHcRt1K6Sb2CXtynnGIiHDNI8p0VWZR4ak.UcJiy9eX.rYqJgQrPe .VZS_NEcxp4ZYTVznqLt7tcCj9JcZcEQY8RT4TKRs7MapuHt8WP0UVtMTGHM4fHTm78ZJh4fSQ5Q xfLuf.XM2DAvZ_unrjlbP.WqS3UY8Ccj8Z1fr0Q1n45UNxfYY8uy3uebCY4DLsWyhLyIAIqSDlHG gpyIAx.Ey8erQH3jeqTrN7GasdY1A96Os6kJIZv9Qt4HnhsyYpUD5UDx7SwR7.vYi20O_mMj809G .fMAb07ZG.4r9L2EhtFUtwJY.28qGzYdCWytF8cHwtQEHomOiVXgym8e7NWxki8JOYmcg.EEwQ.d Kpmq9XZy.7dHq15eyoGWVXO0wd8j52l7PVAB0SXue3M1iFrayruvyVRFgIauRB8Lj1EFA.Ds2N0c 2ClhyvqIVowb7eHYrjQvk.BrpNQ4HETFtPglKR7J7AcuQIaQG8L1pAXIk.v5zhGA6yOUY3Vqx.LP B6uEKmYIHbq2OKplYDIVWLp329Azmxyx9rXGyUnjedeOvfL3Dj.h2G0KYTP5_SDly9xkw9qqr_k7 yCG2lpmxa1xachZaG3eqqg0dgbsNZPRBOCBoqY_Skcj2Oz4kBW5QNTRP6eD16Xsxu97L3.1mPsuj kvFlHo2uGW2RC3mnu00NIX5zKfqfJTMWSr09zIrzfRxiB9BhEQfUDChxSD9h3OGZQt3xUrWxliyf mcJJiZXF4qhngJw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Jan 2022 18:29:11 +0000 Received: by kubenode525.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5bea33f7cb9362769eba4560ed4a8159; Mon, 24 Jan 2022 18:29: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> Date: Mon, 24 Jan 2022 10:29:08 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JjJRM15vfz4n7n X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="DMFdY/zT"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.48 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.982]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5699 Lines: 153 On 2022-Jan-24, at 10:26, Mark Millard wrote: > On 2022-Jan-24, at 08:54, bob prohaska wrote: >=20 >> On Fri, Jan 21, 2022 at 11:14:32PM -0800, Mark Millard wrote: >>>> On 2022-Jan-20, at 22:00, Mark Millard wrote: >>>>=20 >>>=20 >>> It does no good for me since I do not get a failure, >>> but you might try (instead of exectuing the .sh file) >>> (I used \'s to split the huge line): >>>=20 >>> lldb -- "/usr/bin/c++" "-cc1" "-triple" = "aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \ >>> "-disable-free" "-disable-llvm-verifier" "-discard-value-names" = "-main-file-name" "gmock_main.cc" \ >>> "-mrelocation-model" "static" "-mframe-pointer=3Dnon-leaf" = "-fno-rounding-math" "-mconstructor-aliases" \ >>> "-munwind-tables" "-target-cpu" "generic" "-target-feature" "+neon" = "-target-abi" "aapcs" \ >>> "-fallow-half-arguments-and-returns" "-debug-info-kind=3Dstandalone" = "-dwarf-version=3D4" \ >>> "-debugger-tuning=3Dgdb" \ >>> = "-fcoverage-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletes= t/gmock_main" \ >>> "-O2" "-Wno-format-zero-length" "-Wsystem-headers" "-Werror" "-Wall" = "-Wno-format-y2k" "-W" \ >>> "-Wno-unused-parameter" "-Wpointer-arith" "-Wreturn-type" = "-Wcast-qual" "-Wwrite-strings" "-Wswitch" \ >>> "-Wshadow" "-Wunused-parameter" "-Wcast-align" "-Wchar-subscripts" = "-Wredundant-decls" \ >>> "-Wmissing-variable-declarations" "-Wno-empty-body" = "-Wno-string-plus-int" "-Wno-unused-const-variable" \ >>> "-Wno-error=3Dunused-but-set-variable" = "-Wno-deprecated-declarations" "-Wno-deprecated-copy" \ >>> "-Wno-c++11-extensions" "-std=3Dc++11" "-fdeprecated-macro" \ >>> = "-fdebug-compilation-dir=3D/usr/obj/usr/src/arm64.aarch64/lib/googletest/g= mock_main" \ >>> "-ferror-limit" "19" "-stack-protector" "2" "-fno-signed-char" = "-fgnuc-version=3D4.2.1" \ >>> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" = "-vectorize-slp" "-faddrsig" \ >>> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" >>>=20 >>> and then "run" at the (lldb) prompt. It might stop and let you >>> get a backtrace (bt command) in addition to whatever it reports >>> about the stoppage. >>=20 >> That seems to have worked, to some extent. Here's the transcript, in = single-user mode: >>=20 >> root@pelorus:/usr/src #=20 >> root@pelorus:/usr/src # lldb -- "/usr/bin/c++" "-cc1" "-triple" = "aarch64-unknown-freebsd13.0" "-emit-obj" "--mrelax-relocations" \ >>> . . . >>> "-fcxx-exceptions" "-fexceptions" "-vectorize-loops" = "-vectorize-slp" "-faddrsig" \ >>> "-D__GCC_HAVE_DWARF2_CFI_ASM=3D1" "-x" "c++" "gmock_main-f5c28a.cpp" >> (lldb) target create "/usr/bin/c++" >>=20 >> Current executable set to '/usr/bin/c++' (aarch64). >> (lldb) settings set -- target.run-args "-cc1" . . . "c++" = "gmock_main-f5c28a.cpp" >> (lldb)=20 >> (lldb) run >> Process 58516 launched: '/usr/bin/c++' (aarch64) >> Process 58516 stopped >> * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) >> frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] getPointer at PointerIntPair.h:59:58 >> 56 =09 >> 57 explicit PointerIntPair(PointerTy PtrVal) { = initWithPointer(PtrVal); } >> 58 =09 >> -> 59 PointerTy getPointer() const { return = Info::getPointer(Value); } >> 60 =09 >> 61 IntType getInt() const { return = (IntType)Info::getInt(Value); } >> 62 =09 >> (lldb) bt >> * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) >> * frame #0: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] getPointer at PointerIntPair.h:59:58 >> frame #1: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] isNull at PointerUnion.h:172:43 >> frame #2: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] empty at TinyPtrVector.h:166:13 >> frame #3: 0x0000000002df7444 c++`::ProcessDeclAttributeList() = [inlined] empty at ParsedAttr.h:873:40 >> frame #4: 0x0000000002df7444 c++`::ProcessDeclAttributeList() at = SemaDeclAttr.cpp:8449:16 >> frame #5: 0x000000000317e784 = c++`::ActOnClassTemplateSpecialization() at SemaTemplate.cpp:8537:3 >> (lldb)=20 >=20 > To look at the different frames: >=20 > (lldb) up 1 > (lldb) bt > . . . (output) . . . > (lldb) up 1 > (lldb) bt > . . . (output) . . . >=20 > and so on until #5 has been displayed. >=20 >> [repeated bt commands seem to duplicate the same output] >>=20 >> I can't make much sense of it, but perhaps others can. It does look >> as if I've somehow corrupted c++. Is there some way to bootstrap >> past the defect? All the clean targets I've tried (clean, cleandir,=20= >> cleanworld, rm -rf /usr/obj, cleandepend) seem to have no effect, >> singly and in combination.=20 >>=20 >> Is it possible to simply delete /usr/src/contrib/llvm-project and=20 >> let git reconstruct it, then force a compiler rebuild somwhow? >=20 > Using git status should report on any files that do not > match what is in .git . In my context for main [so: 14] > that would be: >=20 > # git -C /usr/main-src status > . . . (output --if any) . . . >=20 > You would likely need /usr/src instead. >=20 > Using git diff would show the specific differences. In my > context for main [so: 14] that would look like (if no > differences were found): >=20 > # git -C /usr/main-src diff > . . . (output --if any) . . . >=20 > You would likely need /usr/src . >=20 > If these do not show anything, the source code is not > likely to be the problem. >=20 That last is a bad wording on my part: corrupted source code is not likely to be the problem. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 25 02:15:28 2022 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 A1D1D198A9D9 for ; Tue, 25 Jan 2022 02:15:38 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (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 "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjVnP40mWz3Cr3 for ; Tue, 25 Jan 2022 02:15:37 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 20P2FSFU038389; Tue, 25 Jan 2022 11:15:28 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202201250215.20P2FSFU038389@kx.truefc.org> Date: Tue, 25 Jan 2022 11:15:28 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm@freebsd.org Cc: kiri@truefc.org Subject: Failed boot at drm_vblank in arm64/aarch64 on PBP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4JjVnP40mWz3Cr3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-2.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.865]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[truefc.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 16273 Lines: 327 Hi, all I've re-made boot image for Pinebook Pro (PBP) of 14.0-CURRENT n252589-ece746877783 which is made by GENERIC-DRM kernel for Panfrost driver [1] : First `git subtree add' to 14.0-CURRENT (f72926eab00c) in src server : root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git checkout f72926eab00c root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git remote add drm-subtree https://github.com/jsm222/drm-subtree.git root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git subtree add --prefix sys/dev/drm/ drm-subtree pinebookpro-test root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git rev-parse --verify --short HEAD ece746877783 root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # cd .. root@vm:/ds/src/freebsd/current/14.0 # mv f72926eab00c.generic_drm ece746877783.generic_drm and then build GENERIC-DRM kernel and boot image on 14.0-CURRENT VM : # cd /usr/src # make buildworld TARGET=arm64 # make buildkernel TARGET=arm64 KERNCONF=GENERIC-DRM # cd /usr/src/release # make clean memstick.img TARGET=arm64 TARGET_ARCH=aarch64 KERNCONF=GENERIC-DRM Then boot from it. Failed : ---<>--- 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 compliance Copyright (c) 1992-2022 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-CURRENT #0 n252589-ece746877783-dirty: Tue Jan 25 03:42:31 JST 2022 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64 FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) VT(efifb): resolution 1920x1080 module firmware already present! real memory = 4150083584 (3957 MB) avail memory = 4022452224 (3836 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) Starting CPU 4 (100) Starting CPU 5 (101) FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. random: entropy device external interface MAP f3f10000 mode 2 pages 4 MAP f3f15000 mode 2 pages 4 MAP f6f30000 mode 2 pages 16 kbd0 at kbdmux0 ofwbus0: clk_fixed0: on ofwbus0 simplebus0: on ofwbus0 rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 regfix6: on ofwbus0 regfix7: on ofwbus0 regfix8: on ofwbus0 regfix9: on ofwbus0 regfix10: on ofwbus0 regfix11: on ofwbus0 simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 psci0: on ofwbus0 rk_drm0: on ofwbus0 gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 its0: mem 0xfee20000-0xfee3ffff on gic0 rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_pinctrl0: on ofwbus0 gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 gpiobus0: on gpio0 gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 gpiobus1: on gpio1 gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 gpiobus2: on gpio2 gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 gpiobus3: on gpio3 gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 gpiobus4: on gpio4 rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 iicbus0: on rk_i2c0 rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 iicbus1: on rk_i2c1 rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 iicbus2: on rk_i2c2 fan53555_pmic0: at addr 0x80 on iicbus2 fan53555_pmic1: at addr 0x82 on iicbus2 rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 iicbus3: on rk_i2c3 rk808_pmu0: at addr 0x36 irq 76 on iicbus2 rk_vop0: mem 0xff8f0000-0xff8f3efb irq 53 on ofwbus0 rk_vop0: VOP version: 3068896 generic_timer0: irq 2,3,4,5 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 mmc_pwrseq0: on ofwbus0 rk_edp0: mem 0xff970000-0xff977fff irq 62 on ofwbus0 rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpufreq_dt0: Found cpu-supply cpu1: on cpulist0 cpufreq_dt1: on cpu1 cpufreq_dt1: Found cpu-supply cpu2: on cpulist0 cpufreq_dt2: on cpu2 cpufreq_dt2: Found cpu-supply cpu3: on cpulist0 cpufreq_dt3: on cpu3 cpufreq_dt3: Found cpu-supply cpu4: on cpulist0 cpufreq_dt4: on cpu4 cpufreq_dt4: Found cpu-supply cpu5: on cpulist0 cpufreq_dt5: on cpu5 cpufreq_dt5: Found cpu-supply pmu0: irq 0 on ofwbus0 pmu1: irq 1 on ofwbus0 pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 pcib0: Gen1 link training timeouted: 0x00080001. pci0: on pcib0 pcib1: at device 0.0 on pci0 pcib0: failed to reserve resource for pcib1 pcib1: failed to allocate initial memory window: 0-0xfffff pci1: on pcib1 rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 rockchip_dwmmc0: Hardware version ID is 270a rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 rockchip_dwmmc1: Hardware version ID is 270a mmc0: on rockchip_dwmmc1 sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 rk_emmcphy0: got emmcclk clock sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. sdhci_fdt0: 1 slot(s) allocated mmc1: on sdhci_fdt0 ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 usbus1 on ohci0 ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 usbus2: EHCI version 1.0 usbus2 on ehci1 ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 usbus3 on ohci1 rk_dwc30: on ofwbus0 xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 xhci0: 64 bytes context size, 32-bit DMA usbus4: trying to attach usbus4 on xhci0 rk_dwc31: on ofwbus0 xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 xhci1: 64 bytes context size, 32-bit DMA usbus5: trying to attach usbus5 on xhci1 es8316codec0: at addr 0x22 on iicbus0 iic0: on iicbus0 iic1: on iicbus1 uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 uart0: debug port (-1,n,8,1) uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 uart1: console (1500000,n,8,1) spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 spibus0: on spi0 spibus0: at cs 0 mode 0 iic2: on iicbus2 iicbus3: at addr 0x44 iic3: on iicbus3 pwm0: mem 0xff420000-0xff42000f on ofwbus0 pwmbus0: on pwm0 pwmc0: channel 0 on pwmbus0 pwm1: mem 0xff420020-0xff42002f on ofwbus0 pwmbus1: on pwm1 pwmc1: channel 0 on pwmbus1 i2s0: mem 0xff890000-0xff890fff irq 51 on ofwbus0 Cannot set frequency for clk: clkin_i2s, error: 34 Cannot set frequency for clk: xin24m, error: 34 pcm0: on ofwbus0 gpioc0: on gpio0 gpioc1: on gpio1 gpioc2: on gpio2 gpioc3: on gpio3 gpioc4: on gpio4 rk_edp_panel0: on ofwbus0 gpioled0: on ofwbus0 pcm1: on ofwbus0 simpleamp0: on ofwbus0 armv8crypto0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 5.0Gbps Super Speed USB v3.0 usbus5: 5.0Gbps Super Speed USB v3.0 rk_drm0: port found <6>[drm] Connector eDP-1: get mode from tunables: <6>[drm] - kern.vt.fb.modes.eDP-1 <6>[drm] - kern.vt.fb.default_mode rk_drm0: Cannot find port with phandle 10 rk_drm_fb_preinit <6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). <6>[drm] No driver support for vblank timestamp query. WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. VT: Replacing driver "efifb" with new "fb". <6>[drm] Initialized rockchip 1.0.0 20201113 for rk_drm on minor 0 rk808_pmu0: registered as a time-of-day clock, resolution 1.000000s ugen3.1: at usbus3 uhub0 on usbus3 uhub0: on usbus3 ugen2.1: at usbus2 uhub1 on usbus2 uhub1: on usbus2 ugen1.1: at usbus1 uhub2 on usbus1 uhub2: on usbus1 ugen5.1: at usbus5 uhub3 on usbus5 uhub3: on usbus5 ugen4.1: at usbus4 uhub4 on usbus4 uhub4: on usbus4 ugen0.1: at usbus0 uhub5 on usbus0 uhub5: on usbus0 mmcsd0: 8GB at mmc0 20.0MHz/4bit/1016-block WARNING cur_vblank != vblank->last failed at /usr/src/sys/dev/drm/core/drm_vblank.c:279 Fatal data abort: x0: ffffa0000091f498 x1: 0 x2: a8 x3: 102 x4: 102 x5: ffff00009a845990GEOM: mmcsd0: the secondary GPT header is not in the last LBA. (_end + 9976a990) x6: 0 x7: 501 x8: ffffa00000d5f000 x9: 2 x10: 2 x11: 0 x12: 0 x13: 0 x14: 0 x15: 10 x16: 400 x17: 0 x18: ffff00009a845810 (_end + 9976a810) x19: ffffa00000d5b600 x20: ffffa0000091f498 x21: 102 x22: 2 x23: ffff000000f10b30 (proc0 + 0) x24: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) x25: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) x26: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) x27: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) x28: 0 x29: ffff00009a845810 (_end + 9976a810) sp: ffff00009a845810 lr: ffff0000007080e8 (linux_alloc_current + 58) elr: ffff000000708360 (linux_alloc_current + 2d0) spsr: 60000045 far: e esr: 96000004 WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:615 WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:660 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 <3>[drm: 0xffff00000090f048] *ERROR* [CRTC:33:crtc-0] hw_done timed out <3>[drm: 0xffff00000090f074] *ERROR* [CRTC:33:crtc-0] flip_done timed out <3>[drm: 0xffff00000090f0fc] *ERROR* [CONNECTOR:35:eDP-1] hw_done timed out <3>[drm: 0xffff00000090f128] *ERROR* [CONNECTOR:35:eDP-1] flip_done timed out <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:31:plane-0] hw_done timed out <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:31:plane-0] flip_done timed out <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:32:plane-1] hw_done timed out <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:32:plane-1] flip_done timed out [CRTC:33:crtc-0] vblank wait timed out Is there any suggetions ? Best regards [1] https://github.com/jsm222/drm-subtree --- Kazuhiko Kiriyama From nobody Tue Jan 25 14:27:17 2022 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 D0C6C197AA3B for ; Tue, 25 Jan 2022 14:27:26 +0000 (UTC) (envelope-from SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4Jjq1n3ryyz4sjk; Tue, 25 Jan 2022 14:27:25 +0000 (UTC) (envelope-from SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl) Date: Tue, 25 Jan 2022 15:27:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1643120837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=u4ujhok3PiO3tQVagwDoNCkKVdYmybudV4KiJp6XDEY=; b=TWpmrIw9XTXwiHOg6L3o79bCJRPlIjQ+HQE+6AoX42cQUA6OwZNaYks8e6I4jo7oEuvtgR yk6d2d67IfBZP8MdgO3oNXE+IY3iAZ9oPWAljILDyi7SbKfQ5437SdBjMisZCvERZwqp2/ kRPqToBwoY1ykxg4so6BlapHecNLv0Rb70ZL8KeuGpWE5bv1wZz5Q3MGfkdasjrX0ZZZqn W22+/Z8Gy9J1p3TdS+ditXyY6zdp1vZr1+fiLv0PCJcu+K0fJj5UmrYaYTM6xAm35asNRR ttVT0TLbOdiv5f/xf3n8uGUKc1mwbHXsjzJYKAOjyW4HMNsafTrhbJukj7M/bg== From: Ronald Klop To: clusteradm@freebsd.org, freebsd-arm@freebsd.org Message-ID: <1365005114.369.1643120837534@localhost> Subject: aarch64 build cluster and linux64.ko 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="----=_Part_368_2039765701.1643120837515" X-Mailer: Realworks (592.233.a9f37dc) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Jjq1n3ryyz4sjk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=TWpmrIw9; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.109.157.24:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=FMyt=SJ=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2922 Lines: 57 ------=_Part_368_2039765701.1643120837515 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Currently the packages depending on linux_base-c7 can not be pre-build on the package cluster because the kernel does not have linux64.ko loaded. See: http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer =================================================== ===> linux-c7-libpng-1.5.13_3 depends on package: linux_base-c7>=7.6.1810_7 - not found ===> Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... Cannot install package: kernel missing 64-bit Linux support pkg-static: PRE-INSTALL script failed Is it possible to have linux64.ko loaded on the pkg builders so the aarch64 packages will be more complete? At least on my rpi4/aarch64 poudriere I could build pkg linux-c7-libpng with linux64.ko loaded. Regards, Ronald. ------=_Part_368_2039765701.1643120837515 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,

Currently the packages depending on linux_base-c7 can not be pre-build on the package cluster because the kernel does not have linux64.ko loaded.

See: http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer 
=======================<phase: run-depends    >============================
===>   linux-c7-libpng-1.5.13_3 depends on package: linux_base-c7>=7.6.1810_7 - not found
===>   Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg
[main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...
Cannot install package: kernel missing 64-bit Linux support
pkg-static: PRE-INSTALL script failed
Is it possible to have linux64.ko loaded on the pkg builders so the aarch64 packages will be more complete?

At least on my rpi4/aarch64 poudriere I could build pkg linux-c7-libpng with linux64.ko loaded.

Regards,
Ronald.
 
------=_Part_368_2039765701.1643120837515-- From nobody Tue Jan 25 16:22:45 2022 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 81927197CF3D for ; Tue, 25 Jan 2022 16:22:52 +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 4JjsZz47HQz4Ry6 for ; Tue, 25 Jan 2022 16:22:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20PGMjRD043674 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Jan 2022 08:22:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20PGMj5l043673; Tue, 25 Jan 2022 08:22:45 -0800 (PST) (envelope-from fbsd) Date: Tue, 25 Jan 2022 08:22:45 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Troubles building world on stable/13 Message-ID: <20220125162245.GA43635@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@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: <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> X-Rspamd-Queue-Id: 4JjsZz47HQz4Ry6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.06 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.959]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 571 Lines: 17 On Mon, Jan 24, 2022 at 10:29:08AM -0800, Mark Millard wrote: > > That last is a bad wording on my part: corrupted source > code is not likely to be the problem. If this is in fact a bug it seems to be private and bites only me. An attempt to build devel/llvm13 using -DBATCH failed in the same way. However, restarting buildworld using -j1 appears to have worked past the former point of failure. It's in the building libraries phase now. Based on log size I'd guess it's about halfway through buildworld. Thanks again for all your help and counsel! bob prohaska From nobody Tue Jan 25 17:13:08 2022 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 9D15F197E49D for ; Tue, 25 Jan 2022 17:13:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjtjF5jHFz4pdF for ; Tue, 25 Jan 2022 17:13:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643130794; bh=K2xHVyfr/Kx3MUhUwi55zSl4+A+wSSMubZKOTVc4Tkg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YaHaTLGn2LQM2X+BKAd+A/4A5x33RoHjLY2CR667+01vjkWjYHxjofyFGwV9wcP/NGtgMEX9USgsgGTVCy3GjB9JRjpP30s8LK6OFVD7+jA4NN/a6vdvu0ZpiIqIxJYYlKhhrFs01DecZsBYAE/gBLhQPnD8zvAuonII3u3v9M5dwJ1cbblQk5vJ4TzZlW9Mu3/asgaqpIJuxt7DMp0NerlZ9fNcQFB3QUEmXHH95SHDOuUTb+VvRYg/g3qVlD7K/zsj2rJoud6tnLLAYOtCk+Bjo39LXu2ZKz80lbm+PT9uszWHVnhQTHIXTGMqKSzMDq0uU57yk5/y51QkytRCqw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643130794; bh=XvkhNx/rHpVrx3dupFA0vtnMx8mn7hX17dfffxz8wrL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=S5n7Uebu44saILHrGoG5ZKW0LQ6PEN22fRoHZQGEXTWI2A1NhGbq6Y2QlXzwf7Fozt9odUSqoaqyPVtD3mnfVn54bQ/csc/PCb/zsSlzLQ6RM9lzQJvmcwdYsVir5z+l8ZBIGVOBB2SZSne+q8x11HTeTgbFK+HLvqhVSEtaxrvKWNe4WjwSLQ8Lc/Ky8OR2CGDOae2dlvbLgm5xhyDYfbS5CejSGvB7KB/G3/pRQGO8d/Oi8xvXi0fg6q49WH/2z7EVK3RrGF7wpBQjNoAgT8rdQk5qFzwozYzjZLJIMeQt5Nufnar+MJmLILfCZlLFTKpqJW4GAfg70OrJwEKlxg== X-YMail-OSG: jWQzqAsVM1lh6M4YCnoRnu2R4H0xkB3LVEvlzdYvIUViOUtwQghygGkg2RmdkJx YRuH42GGUH7x9bIRi_Rrf8hkyuaXL3BWujj2CP1p_D0CfoK3Q5XkCG49HjjdnIhiuh2RSidz8Ae8 Ef.G0aAWKgQdvXS8xxwd8W8akAMExyLFJ7MgPpWmBJvKLbOeCVFb_HbT2BgnrxTcnZdYk4XoM927 MhFYXQHntKAdEGBEorV7fjL6n4uDpnJojPkQ_OwSGysl1MPdo.1FceTGy678gLyS1uuf7NegZ4Yw .mK19jijoTP0hfUlxguNHjuLc4rCl4hsCxEKtvMxz5CuSgLKXXB_nzyDnzOGoia.lT44BZXbM9ki EWh12kkOYw2aaKhBTNZV4QfHJG16DuL7jpY3PnrwRsqrz2vSBaufr4Y716IO87.DyIpzx9YwNRY3 nM9ayfLGnoJs9tvrL4PvKVmos3dDLpdmI4z_6h7veKr.3TndMQhBE04ZU09UIkOr3hyTPYHMEIwr AouTncV3KKlfUWz6XghUOwTGgGfrBLQ5uyDlDE7cwW64Z06B1m5svmW0YHDxoPXgW0.hJGXZdA_h X09wTGuQbquv6nd0MN6y0lYHQsxYYKvYp4is5cyI0L93LzMYWxWVb2aayKOIugtUwYNAK2Lt00uw WAKwugD8sdjfKiPe1z4W4ZzCnxTSkETyT_.NoBqarJ73HrSZUvc4MAlJ8o4C3rC..6KAtIwZOdnC cBKGvAqV0lK1eiEE8onslfxDk9juRQ.RqU2dYmicKnQvYrVgsLTfKP4O6wn5aLLuvmA5mYTMH8QY W55_kZhvp3v22hTgr4EFKvLL.2_bKn7WARHL02UH3qpZ9inxhrRdXgenjyGXVc89ULfa5UrA3rIl bCLpDTy4Uq1tL1_8P_Zpgz8K728cOMCK6uYEvP9.vB3z.8ohh8Bt.4WboEGByODTerDOkepDNGDs BGW5V8GWRnj6Ze9UTK0CEBAaQwNPZRx8Xz7yitBdOJuEP3lUVDiFyfDJE5SOvWryeI5Gy1m1dT4o _a53exE98.5AFxZCFHMpi.36tTgayqet55u5lKBt3pDdm9lAFRhncrWlzunuWyXfv3uAASMmv2eh zWAo1Mj7U9O4A5XhH37040fGj9RrvhtuKdKX9FfTWyKwN727JNT2F5flfM6IcUk2cXXSfjV5Md_r v82780iMUlQ0M2lA2RnQvJZvHg_mDmntg4zHLR9ilaAHTI.cZLK1kfd96oXhJPm5klrx5femh2ai 7zXc5RUJDu3Nkak4c4_62sEm1g2fNHvoYENcR5jbfvdQ8qwK4Rheq9d116pK7ChoVnbQbuL0NqUP Qhlt2pS6KLLwZN_07novt7eznYm1pNx0WC7XjRcGr4unwhyG2lY8MORo_N2U_lbHrPS0qubnyPPe Q6v6olS5MfV0R63fAsFMoOB3Wk4NjMACvi.7e7Hs3gk9dLVFL1AQY9ijnM_mNH1L2EnQxZO6kR6O VQPMzPsO1lJHohFDQ4Y4wXfI6Crw3P_r7CIdELYPDVcyS7GQXQ4EbZOuFt1nWVYnbH6WsLqa5RCf L6E5LUfsV34cHOf29Uc2tX8EhC0eNgeZDVn4xm1teWyOVMhIMIfUjvQidbQsEQL9kna5jC3R2hZT P69g8Orcd9YLgyv7fBnZ8ZUtG7WA84i8GkEk_VzpJP9rEmkxreQ.aFpuTfzuMdVaMfJhMusy3mw5 OkfqAJicF29nOzkUeLPNGX82oGBPw3W2fJXxGnHK9e3gyvzpSjIXllRwAr.TcqTiyNVmHNNyeqK8 hEEpdh.JugPcteccziUz9ItqCf4JGXMdgRhNKj.aJkK0Nju4OrFS7u2iWBGqEOSdG51Ky3PJ2aNs jGxQv0G0jDMXzSPvpMWdB.1kGzpOTwqs7VJ9W4DE1Ivv_cxvXIlcLB4hM4Ka5G8pDK8Igmu13_Ip 6uQqf0LyzhzLcCFrXJG8YBQlzKH6ySUUg6_JU7HjwPA7h.WZoWhPLy7oDJEBZws4aNf0swXisY8P se6bQi1GownKxKJ3Jy88Zy.83yb0J9CJp0gMJQ95OmDRjHFGOzTa0TpdJiuOYqcguynI88r2bQUi hwVx_blbneUknQsjmUfgu1tGN0.dTYdlBBEZzvpVeGuoUxiSBQ4CIUeppFaaBil4btV8t9znmgMt keA3iOD4UM9HUi_xcqW6g81QUhth5d0QE7NWMMY_qbOHPioKRn7e8dvrjUsXD_KsIxeGR4c_5rMF OXBlTpcSuAW.SGvLYmuDnDbB70pjKRr0NBEjniuSzbnMRlqPQPLbpinkmM4LHyWZL4Xsd4QtBhys .8Go2fjFYBt8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Jan 2022 17:13:14 +0000 Received: by kubenode503.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 34e1a109e477e5b982dd5ca3445eba82; Tue, 25 Jan 2022 17:13: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220125162245.GA43635@www.zefox.net> Date: Tue, 25 Jan 2022 09:13:08 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JjtjF5jHFz4pdF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YaHaTLGn; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1250 Lines: 42 On 2022-Jan-25, at 08:22, bob prohaska wrote: > On Mon, Jan 24, 2022 at 10:29:08AM -0800, Mark Millard wrote: >> >> That last is a bad wording on my part: corrupted source >> code is not likely to be the problem. > > If this is in fact a bug it seems to be private and bites only me. > An attempt to build devel/llvm13 using -DBATCH failed in the same > way. -DBATCH ? I'm not aware of there being any use of that symbol. Do you have a documentation reference for it so that I could read about it? > However, restarting buildworld using -j1 appears to have worked past > the former point of failure. Hmm. That usually means one (or both) of two things was involved in the failure: A) a build race where something is not (fully) ready when it is used B) running out of resources, such as RAM+SWAP But, as I understand, you were able to use a .cpp and .sh file pair that had been produced to repeat the problem on the RPi3B --and that would not have been a parallel-activity context. > It's in the building libraries phase now. > Based on log size I'd guess it's about halfway through buildworld. > Well, hopefully you will not be stuck with -j1 builds in the future as well. === Mark Millard marklmi at yahoo.com From nobody Tue Jan 25 18:08:23 2022 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 723AE1976BD2 for ; Tue, 25 Jan 2022 18:08:24 +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 4Jjvwl4sQdz3h1H for ; Tue, 25 Jan 2022 18:08:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20PI8NwB043953 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Jan 2022 10:08:24 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20PI8NxN043952; Tue, 25 Jan 2022 10:08:23 -0800 (PST) (envelope-from fbsd) Date: Tue, 25 Jan 2022 10:08:23 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD , bob prohaska Subject: Re: Troubles building world on stable/13 Message-ID: <20220125180823.GB43635@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@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: <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> X-Rspamd-Queue-Id: 4Jjvwl4sQdz3h1H X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(0.99)[0.991]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2440 Lines: 65 On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: > > -DBATCH ? I'm not aware of there being any use of that symbol. > Do you have a documentation reference for it so that I could > read about it? > It's a switch to turn off dialog4ports. I can't find the reference now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would be easier to understand anyway. On a whim, I tried building devel/llvm13 on a Pi4 running -current with 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: nemesis.zefox.com kernel log messages: +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST 2022 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: 4096 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: 4096 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: 12288 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: 24576 +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory On an 8GB machine, that seems strange. Per the failure message I restarted the build of devel/llvm13 with make -DBATCH MAKE_JOBS_UNSAFE=YES > make.log & It seems to be running with only one thread so far, not sure if that's by design or happenstance. > > However, restarting buildworld using -j1 appears to have worked past > > the former point of failure. > > Hmm. That usually means one (or both) of two things was involved > in the failure: > > A) a build race where something is not (fully) ready when > it is used > > B) running out of resources, such as RAM+SWAP > The stable/13 machine is short of swap; it has only 2 GB, which used to be enough. Maybe that's the problem, but having an error report that says it's a segfault is a confusing diagnostic. > But, as I understand, you were able to use a .cpp and > .sh file pair that had been produced to repeat the > problem on the RPi3B --and that would not have been a > parallel-activity context. > To be clear, the reproduction was on the same stable/13 that reported the original failure. An attempt at reproduction on a different Pi3 running -current ran without any errors. Come to think of it, that machine had more swap, too. > > It's in the building libraries phase now. > > Based on log size I'd guess it's about halfway through buildworld. > > > > Well, hopefully you will not be stuck with -j1 builds in > the future as well. > Indeed! bob prohaska From nobody Tue Jan 25 18:45:05 2022 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 AC4DF19705D9 for ; Tue, 25 Jan 2022 18:45:10 +0000 (UTC) (envelope-from jsm@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 4JjwlB3W5Rz4SbK; Tue, 25 Jan 2022 18:45:10 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643136310; 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=X9rYqq42WEbtV/GLVAYWymulE69Rn7oUKw3AOodThVI=; b=ohcO0kDDq60T36VeK1bo1HPT6SrjHTYNMtUQD7LeUTwYYvzJKwsATLwFNBOe7dMGBRozyK tLUszXfW/MZZwLe+2vCjD7F/qyNJ0UVfM5yAqoSRJ4gceDiEUSovkq3UKf1znpvzI5Ebpp ZHaiIeQtgdYlGi4ZJh+fe1c/5euUpMg7e9QXplI5Z88jeOs0gCxpVSBb4aY14HsIMSLNtD h2EQ7BMw2zRo1hZyiqJl9nfKdnZFOkZpYFyqvlQBxRUnWTuNDE5Z4SEzZHNDOOl3E6AfU4 Qm4O0o72d3GHLw/m/WBLeUIm/x/rB2FuNzfxM1q6AmLEmF4qaqlJtWhzzkJ+Sw== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id D1FBAD0C5; Tue, 25 Jan 2022 18:45:09 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <68641063-f78c-743b-d528-348d6ffdecab@FreeBSD.org> Date: Tue, 25 Jan 2022 19:45:05 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Failed boot at drm_vblank in arm64/aarch64 on PBP Content-Language: en-US To: KIRIYAMA Kazuhiko , freebsd-arm@freebsd.org References: <202201250215.20P2FSFU038389@kx.truefc.org> From: Jesper Schmitz Mouridsen In-Reply-To: <202201250215.20P2FSFU038389@kx.truefc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643136310; 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=X9rYqq42WEbtV/GLVAYWymulE69Rn7oUKw3AOodThVI=; b=WKQD+sVSuUV4dqKGA6RhKEwgQ9ZPJ/JdcLEOpw1dC+4H5pCbbBvsgxSHofhB9hQZjQIV+e 6KlmanSkh3W2cINfWee0sFjSpZjjbi8smzRz0BVYbHbl7wuUHzU0BlhrHwu+1yR+3Owxir ihBTvpPBaTOrKWnd19LhUFeCdV64NeBrlnz8lV4xMPJFoU1Ckkw7WtLH/gGB9cllYbt8YA hDtH9IzNJ+8CI55zVW1iOJhVcRf3HdtC6DQ0wHrYBLB5TA/C/gaPYUMTycQm+txZpElpc/ t5J7JFkqdaT1CmLiHV6NYwZ3AonFOMiuS67rfQ8cto7vGIlPkAHjvL+aXXWYwQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643136310; a=rsa-sha256; cv=none; b=BXR1fBWfk4J/KALzGrLmNe/JatsnSc98YKT9H8fLlnEyUR7e3JRB2w675iQ1eK/4PRV8Lq klhNAOu7A6z1QV83iA1zH9/kVnNeFF8Y6tVtfuEayTjdMSkk/5SkpgbbN/20fRAVQdRDaR 88qQBQYAHNrlHCIkYXpIOmsRNvhFMG/SiLTE7Ck4GDIkv/6rZz+B81eJLWhSKaf6SLj5wR NOBHVz2ZnUqpiRAFx7GhPj1HS/TKCh5QU+wvoc4kY+LLYjX+UOany6+ZFfXezIPMfRNsqO RXGRDjbXbPGUgynm+1yEB6HVhSrZxPfFy9u/+2d0ygBfIlXZBfJLWUCYA2NOSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 17240 Lines: 339 On 25.01.2022 03.15, KIRIYAMA Kazuhiko wrote: > Hi, all > > I've re-made boot image for Pinebook Pro (PBP) of > 14.0-CURRENT n252589-ece746877783 which is made by > GENERIC-DRM kernel for Panfrost driver [1] : > > First `git subtree add' to 14.0-CURRENT (f72926eab00c) in src server : > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git checkout f72926eab00c > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git remote add drm-subtree https://github.com/jsm222/drm-subtree.git > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git subtree add --prefix sys/dev/drm/ drm-subtree pinebookpro-test > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git rev-parse --verify --short HEAD > ece746877783 > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # cd .. > root@vm:/ds/src/freebsd/current/14.0 # mv f72926eab00c.generic_drm ece746877783.generic_drm > > and then build GENERIC-DRM kernel and boot image on > 14.0-CURRENT VM : > > # cd /usr/src > # make buildworld TARGET=arm64 > # make buildkernel TARGET=arm64 KERNCONF=GENERIC-DRM > # cd /usr/src/release > # make clean memstick.img TARGET=arm64 TARGET_ARCH=aarch64 KERNCONF=GENERIC-DRM > > Then boot from it. Failed : > > ---<>--- > 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 compliance > Copyright (c) 1992-2022 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-CURRENT #0 n252589-ece746877783-dirty: Tue Jan 25 03:42:31 JST 2022 > root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64 > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) > VT(efifb): resolution 1920x1080 > module firmware already present! > real memory = 4150083584 (3957 MB) > avail memory = 4022452224 (3836 MB) > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > Starting CPU 4 (100) > Starting CPU 5 (101) > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. > random: entropy device external interface > MAP f3f10000 mode 2 pages 4 > MAP f3f15000 mode 2 pages 4 > MAP f6f30000 mode 2 pages 16 > kbd0 at kbdmux0 > ofwbus0: > clk_fixed0: on ofwbus0 > simplebus0: on ofwbus0 > rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 > rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 > rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 > rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > regfix4: on ofwbus0 > regfix5: on ofwbus0 > regfix6: on ofwbus0 > regfix7: on ofwbus0 > regfix8: on ofwbus0 > regfix9: on ofwbus0 > regfix10: on ofwbus0 > regfix11: on ofwbus0 > simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 > psci0: on ofwbus0 > rk_drm0: on ofwbus0 > gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 > its0: mem 0xfee20000-0xfee3ffff on gic0 > rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 > rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_pinctrl0: on ofwbus0 > gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 > gpiobus0: on gpio0 > gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 > gpiobus1: on gpio1 > gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 > gpiobus2: on gpio2 > gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 > gpiobus3: on gpio3 > gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 > gpiobus4: on gpio4 > rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 > iicbus0: on rk_i2c0 > rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 > iicbus1: on rk_i2c1 > rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 > iicbus2: on rk_i2c2 > fan53555_pmic0: at addr 0x80 on iicbus2 > fan53555_pmic1: at addr 0x82 on iicbus2 > rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 > iicbus3: on rk_i2c3 > rk808_pmu0: at addr 0x36 irq 76 on iicbus2 > rk_vop0: mem 0xff8f0000-0xff8f3efb irq 53 on ofwbus0 > rk_vop0: VOP version: 3068896 > generic_timer0: irq 2,3,4,5 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 > mmc_pwrseq0: on ofwbus0 > rk_edp0: mem 0xff970000-0xff977fff irq 62 on ofwbus0 > rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 > rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpufreq_dt0: Found cpu-supply > cpu1: on cpulist0 > cpufreq_dt1: on cpu1 > cpufreq_dt1: Found cpu-supply > cpu2: on cpulist0 > cpufreq_dt2: on cpu2 > cpufreq_dt2: Found cpu-supply > cpu3: on cpulist0 > cpufreq_dt3: on cpu3 > cpufreq_dt3: Found cpu-supply > cpu4: on cpulist0 > cpufreq_dt4: on cpu4 > cpufreq_dt4: Found cpu-supply > cpu5: on cpulist0 > cpufreq_dt5: on cpu5 > cpufreq_dt5: Found cpu-supply > pmu0: irq 0 on ofwbus0 > pmu1: irq 1 on ofwbus0 > pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 > pcib0: Gen1 link training timeouted: 0x00080001. > pci0: on pcib0 > pcib1: at device 0.0 on pci0 > pcib0: failed to reserve resource for pcib1 > pcib1: failed to allocate initial memory window: 0-0xfffff > pci1: on pcib1 > rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 > rockchip_dwmmc0: Hardware version ID is 270a > rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 > rockchip_dwmmc1: Hardware version ID is 270a > mmc0: on rockchip_dwmmc1 > sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 > rk_emmcphy0: got emmcclk clock > sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. > sdhci_fdt0: 1 slot(s) allocated > mmc1: on sdhci_fdt0 > ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 > usbus1 on ohci0 > ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 > usbus3 on ohci1 > rk_dwc30: on ofwbus0 > xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 > xhci0: 64 bytes context size, 32-bit DMA > usbus4: trying to attach > usbus4 on xhci0 > rk_dwc31: on ofwbus0 > xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 > xhci1: 64 bytes context size, 32-bit DMA > usbus5: trying to attach > usbus5 on xhci1 > es8316codec0: at addr 0x22 on iicbus0 > iic0: on iicbus0 > iic1: on iicbus1 > uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 > uart0: debug port (-1,n,8,1) > uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 > uart1: console (1500000,n,8,1) > spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 > spibus0: on spi0 > spibus0: at cs 0 mode 0 > iic2: on iicbus2 > iicbus3: at addr 0x44 > iic3: on iicbus3 > pwm0: mem 0xff420000-0xff42000f on ofwbus0 > pwmbus0: on pwm0 > pwmc0: channel 0 on pwmbus0 > pwm1: mem 0xff420020-0xff42002f on ofwbus0 > pwmbus1: on pwm1 > pwmc1: channel 0 on pwmbus1 > i2s0: mem 0xff890000-0xff890fff irq 51 on ofwbus0 > Cannot set frequency for clk: clkin_i2s, error: 34 > Cannot set frequency for clk: xin24m, error: 34 > pcm0: on ofwbus0 > gpioc0: on gpio0 > gpioc1: on gpio1 > gpioc2: on gpio2 > gpioc3: on gpio3 > gpioc4: on gpio4 > rk_edp_panel0: on ofwbus0 > gpioled0: on ofwbus0 > pcm1: on ofwbus0 > simpleamp0: on ofwbus0 > armv8crypto0: > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 5.0Gbps Super Speed USB v3.0 > usbus5: 5.0Gbps Super Speed USB v3.0 > rk_drm0: port found > <6>[drm] Connector eDP-1: get mode from tunables: > <6>[drm] - kern.vt.fb.modes.eDP-1 > <6>[drm] - kern.vt.fb.default_mode > rk_drm0: Cannot find port with phandle 10 > rk_drm_fb_preinit > <6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > <6>[drm] No driver support for vblank timestamp query. > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. > VT: Replacing driver "efifb" with new "fb". > <6>[drm] Initialized rockchip 1.0.0 20201113 for rk_drm on minor 0 > rk808_pmu0: registered as a time-of-day clock, resolution 1.000000s > ugen3.1: at usbus3 > uhub0 on usbus3 > uhub0: on usbus3 > ugen2.1: at usbus2 > uhub1 on usbus2 > uhub1: on usbus2 > ugen1.1: at usbus1 > uhub2 on usbus1 > uhub2: on usbus1 > ugen5.1: at usbus5 > uhub3 on usbus5 > uhub3: on usbus5 > ugen4.1: at usbus4 > uhub4 on usbus4 > uhub4: on usbus4 > ugen0.1: at usbus0 > uhub5 on usbus0 > uhub5: on usbus0 > mmcsd0: 8GB at mmc0 20.0MHz/4bit/1016-block > WARNING cur_vblank != vblank->last failed at /usr/src/sys/dev/drm/core/drm_vblank.c:279 > Fatal data abort: > x0: ffffa0000091f498 > x1: 0 > x2: a8 > x3: 102 > x4: 102 > x5: ffff00009a845990GEOM: mmcsd0: the secondary GPT header is not in the last LBA. > (_end + 9976a990) > x6: 0 > x7: 501 > x8: ffffa00000d5f000 > x9: 2 > x10: 2 > x11: 0 > x12: 0 > x13: 0 > x14: 0 > x15: 10 > x16: 400 > x17: 0 > x18: ffff00009a845810 (_end + 9976a810) > x19: ffffa00000d5b600 > x20: ffffa0000091f498 > x21: 102 > x22: 2 > x23: ffff000000f10b30 (proc0 + 0) > x24: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > x25: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > x26: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > x27: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > x28: 0 > x29: ffff00009a845810 (_end + 9976a810) > sp: ffff00009a845810 > lr: ffff0000007080e8 (linux_alloc_current + 58) > elr: ffff000000708360 (linux_alloc_current + 2d0) > spsr: 60000045 > far: e > esr: 96000004 > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:615 > WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:660 > WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 > WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 > <3>[drm: 0xffff00000090f048] *ERROR* [CRTC:33:crtc-0] hw_done timed out > <3>[drm: 0xffff00000090f074] *ERROR* [CRTC:33:crtc-0] flip_done timed out > <3>[drm: 0xffff00000090f0fc] *ERROR* [CONNECTOR:35:eDP-1] hw_done timed out > <3>[drm: 0xffff00000090f128] *ERROR* [CONNECTOR:35:eDP-1] flip_done timed out > <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:31:plane-0] hw_done timed out > <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:31:plane-0] flip_done timed out > <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:32:plane-1] hw_done timed out > <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:32:plane-1] flip_done timed out > [CRTC:33:crtc-0] vblank wait timed out > > Is there any suggetions ? > I am currently building a newer image to try to reproduce, in the mean time did you try my prebuild image here http://build.schmitz.computer/build/pbp/FreeBSD-14.0-CURRENT-arm64-aarch64-PINEBOOKPRO.img.xz ? Thanks /jsm > Best regards > > [1] https://github.com/jsm222/drm-subtree > --- > Kazuhiko Kiriyama > > > > > > > From nobody Tue Jan 25 20:49:02 2022 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 96003197083E for ; Tue, 25 Jan 2022 20:49:17 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjzVN0hD4z4cny for ; Tue, 25 Jan 2022 20:49:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643143749; bh=W824uPDRPdYHBa4GojcB4PuBu5LV23jray3ZUueu2mo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i358Ht7tf0IWFtrVlO0+4JaIVj4r8IT9V1kcapDz5TJeLxWfQSrF9QgYYubYwRxpPLRAHA8qRECg5PUFaajDBz6NNFbFJ8dmElGadDjC/wmYFiFt/LjlsOYcxKw2xfwKEi48blsgl21PY6SSBZVfwHZwUCNdAlAT0+JLS0ShdOEvkncKyQI39SaC7+nQeRfc+FQDybXhnB6O2zXu1idyJv82SMJtxvvkMk4ItArtZ6JLauPaXgmMRstedDxu5ai8MApD3+x0BItmSJqJGckf6KKFdBjfShub5mKdrIXEhqeCDYzVt94m/iscZZ0OyWkI2PfhiolSM6iDMuY7j9bP1A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643143749; bh=Whx5OD+AU/aKso6BS37cfjDnIKB17+QgKGj2ye03Q+R=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rdDp9LKGY1R6cT+nF4E7CR5ywtDG6/aFuXde38RvwXJXr7rAihMnIXJy4ajrEAyTpszC2BVVs7hB8e+CtguYFNw57yk0JaUZHcRs8Ff4mKWN4lRoFV7DW/CMjb3NvmSqxV/kW05g1/98LXsA5b59ij7OOmOyetns6wDh/EVaS298EWnrggd47b6xsmWkNx3U6TAycfJFsXzUksAkwdYqJYDnHFQeplIYkQHudzW2I16SzCLVPGPJHjjBCQSqo+Jg/rCIuKzDH9OTnDpSyPT1+dgZ+0NZwA54Rfq7B5TU0cNvULxZpVQ39Fh3JiBkEoho1v0NOThDWN0RdOFnjIQ+Zg== X-YMail-OSG: a.9.rhoVM1nFT66iVfSqhPVVXkFAg2mP3xbGb5W7LHbMMIfdso83k9sjMGxeiGG 5G6LBkcCkshiTZ1COU1IFoiELFpyU6jsxsi0WUXTrpjzD2QFZ3Hu1_NoxUZYq7hB1.rfaxWWkFPa w2dsC.4.blRjGOC6A2Fglr734aSn2sLDd0BgufS33671hYXsm0WFIINU5BW4RgDOd68Azi1tXG6A acv7xrU94EGanT3zja_2ODIeELEctQbIOHtBkPIfLIVUo1REYq3dqvhXc1bGPBLNF69_5TbKti6R ctKQJqIYyOBjpRoV_7ogSwl86WNwAO4Fx3_P3GW1JBNn7dCfezFQMdiwiQC3BGGq4ApiEyHMW8L3 jIsih_UR8AyIHAR6wy4jAnbGr0kwYk.DVPdYk8.cLjtwHtakfNwPdOCDH9QfM0OErt8h2SqywnBG cjCBnhlIpOHAC383KI_QaCDPd84sGawuWNnLw_CV_bQy3VbLPnBdUYYcfJexbqibztTVvKRf2c6z Wk3NpcLeKX1uXQ0m7uNN.ca2LaRli.NAO7yr22DIQ5ZwQEUMfFduZFaDUJMocioR1Gt0hJkccHk1 iIDqMdZpgGHvPaz2pzG8QBc.JgOSN6GPUpZRo8fH1syw8hxZMESmr4tg3xeX83dbDHvuDrkHlhno _Bg7HvSNN5v1S8a2_JMMt.NBVAtl6yEPURrfWWAFAYNRkbCuFu7ljyGn3uiw65HsQqBzExTAfYvn ZTjQilYt..1i3UoMQG1wRdUCg1Yh6N6bG5zovP_IEUgltcwk5NS5XoWx7yDv6rIrhLs2ieut3XOX 9ed09y9IuPodNOWkwyuVUjateMO0AgOJVggd_aMEy81qlYq9TuUkESUxfq8eol2B8QVENsiROlx2 6lvyr6g0C5n.FZIkCiK6SL.g3oVjMpMYyrXsF0dY2iTS3zsekYKS7gfbfrNSaNaxaDsDQ8EYey0c QxgHAGLdcl2.Q9kmrOe4WIRc4Al808NZ8nEi5ZQytk_aThCxY1ykhbz1YeLqKYpk5.NRsU6GsMPD .94WDQNTEeBl9O7QpcceH9zr4bW14v0BfW_niaqUdef5oiELNh0vj28PYCjNZ8jcVMLmJuxzAu54 KlTf.Xnkzp5VI4mHBiYwRgWE9G1grmJdA0WJ96jkkfOwnFrbKlJRZmXz6oLwIqqOfpUZ_TGZlYHz AENUTPHc0K4CCW1EYL9EWdin6D0N4jVYaN_353NhLLAPMkOgnuLyud7Z468RaBjLRgT_7EUtUd4y D7P73iKvj0dT8UT6qOuKezNSqmA9rqHMVF._QmqFxlvTiWa3I_8a6vIZ5LrBfnuP3kykP5KvIWb5 PQbr2KCCe8aAF3kbJlClg.enoprE8YGD5Wcbj6.avj4XkCqKerkg30lacXJv5eXLIGpvwfNtUFlC E7Xvkw.BctVPUfGm1dL_I__WijI8eoOdaXwRqpJlVo1SqVpMJt2lAcmXWZMoRqohhV8m.z9wNt5R nWhn7eh7oCNZ7kTasQ.WTZjKCGUr0IrkABPPviK9rogFyWvGOcY8x_v6AtAy_HZmOtJsIuAvHVXP ME0nuFAsauSHxAFFohcPBrtC17kxf7Dg.pFGHFgaovx4cj7qeITFGyAT6gBlRidb9UdnVSnqeoCa 1PiBT5nAwEj.9YeQkrhiKN.j5kk5QIo5Vtexh3Cb.gPnPHLPSIG8Zqoy87Mirn5npmsU6AOgrDJJ 5Y9ObC9ldjlJXsUWXtdt1qBPEjMXNNwfCLclLikyIVxuoomDxx3M0YalNGXi7qIFuJ7EWx3hEWhJ osupigLbaq4zWEukNyhe.RAA0eGPznEyRcKFJ6OEiuxMOpjcfUfah.A53zTqS4DIB.8FrofbNzeG mB2fmGkS480ANzrDcMhUGwTNNIKQOoRd9aFPWvHVvTdUusuwO9OoQLJfOB8ayZUYYgB0U_wN4_6. r.kPP9tWPLxb5cX6ju9RbJuPeUiNt5WUjV.ncI4OQ_5FxPvy72r6M7Md8AOuF5jME8Fftc_hq1eI yWTdhy3932qaRotvK0SUf6VN298wBPyP65jy3Yz9J4QJgcfSPxoajKmbcOqGZupUyPaOdRc0bC5J PBNOcQOUXK6f84bVMybjCVztrxg3lTthridpc_imbQp651ni0bhA_Sj2.PdOfVYSLE6FPRCcy.bB BWLIdJxR5PMgpFAT2QRzQmi6Vl4ESuAsOEgZ0QaeG5yIErSuxxJS0kKV2fjOh6JKMXFkpAFqFAbe C4JVxcbjLy1peO94o68zqcwca8eD.r1TWj6OBJjPdigR__aYYdwXFDtFGSs0MGbzqnQcaFnJESWS eQDN9M62eMPpznw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Jan 2022 20:49:09 +0000 Received: by kubenode503.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d0559bb82ce130373eaa6df502402384; Tue, 25 Jan 2022 20:49:04 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220125180823.GB43635@www.zefox.net> Date: Tue, 25 Jan 2022 12:49:02 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JjzVN0hD4z4cny X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=i358Ht7t; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4363 Lines: 125 On 2022-Jan-25, at 10:08, bob prohaska wrote: > On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: >> >> -DBATCH ? I'm not aware of there being any use of that symbol. >> Do you have a documentation reference for it so that I could >> read about it? >> > It's a switch to turn off dialog4ports. I can't find the reference > now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would > be easier to understand anyway. I've never had buildworld buildkernel or the like try to use dialog4ports. I've only had port building use it. buildworld and buildkernel can be done with no ports installed at all. dialog4ports is a port. I think -DBATCH was ignored for the activity at hand. > On a whim, I tried building devel/llvm13 on a Pi4 running -current with > 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: > nemesis.zefox.com kernel log messages: > +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST 2022 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: 4096 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: 4096 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: 12288 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: 24576 > +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory > > On an 8GB machine, that seems strange. -j build? -j4 ? Were you watching the swap usage in top (or some such)? Note: The "was killed" related notices have been improved in main, but there is a misnomer case about "out of swap" (last I checked). An environment that gets "swap_pager: indefinite wait buffer" notices is problematical and the I/O delays for the virtual memory subsystem can lead to kills, if I understand right. But, if I remember right, the actual message for a directly I/O related kill is now different. I think that being able to reproduce this case could be important. I probably can not because I'd not get the "swap_pager: indefinite wait buffer" in my hardware context. > Per the failure message I restarted the build of devel/llvm13 with > make -DBATCH MAKE_JOBS_UNSAFE=YES > make.log & Just like -DBATCH is for ports, not buildworld buildkernel, MAKE_JOBS_UNSAFE= is for ports, not buildworld buildkernel, at least if I understand right. In other words, it probably would have been the same result without the two arguments. > It seems to be running with only one thread so far, not sure if that's > by design or happenstance. > >>> However, restarting buildworld using -j1 appears to have worked past >>> the former point of failure. >> >> Hmm. That usually means one (or both) of two things was involved >> in the failure: >> >> A) a build race where something is not (fully) ready when >> it is used >> >> B) running out of resources, such as RAM+SWAP >> > > The stable/13 machine is short of swap; it has only 2 GB, which > used to be enough. So RAM+SWAP is 1 GiByte + 2 GiByte, so 3 GiByte on that RPi3*? (That would have been good to know earlier, such as for my attempts at reproduction.) -j for the RPi3* when it was failing? Did you havae failures with the .cpp and .sh (so no make use involved) in the RAM+SWAP context? > Maybe that's the problem, but having an error > report that says it's a segfault is a confusing diagnostic. > >> But, as I understand, you were able to use a .cpp and >> .sh file pair that had been produced to repeat the >> problem on the RPi3B --and that would not have been a >> parallel-activity context. >> > > To be clear, the reproduction was on the same stable/13 that > reported the original failure. An attempt at reproduction > on a different Pi3 running -current ran without any errors. > Come to think of it, that machine had more swap, too. How much swap? >>> It's in the building libraries phase now. >>> Based on log size I'd guess it's about halfway through buildworld. >>> >> >> Well, hopefully you will not be stuck with -j1 builds in >> the future as well. >> > Indeed! At this point, I expect that the failure was tied to the RAM+SWAP totaling to 3 GiBytes. Knowing that context we might have a reproducible report that can be made based on the .cpp and .sh files, where restricting the RAM+SWAP use allowed is part of the report. === Mark Millard marklmi at yahoo.com From nobody Tue Jan 25 21:23:51 2022 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 DF7151986F20 for ; Tue, 25 Jan 2022 21:24:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk0GZ4jVDz4sSR for ; Tue, 25 Jan 2022 21:24:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643145837; bh=zDwfMWNYC3xnGCkKfUW52ANzBBKsmYKwVS4x4MkTCGI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eXF7RfrrHPPIDm6B+yOqWNaT84vQGbkiaOmX0Sn1OeKxZUaDHJ87296Fe7AJTAaq+dPMto77J6M9D43V114Nlpnl1LoDZ/zTVw6RbNpAXo53Giz4/cvXy2UT7cXz5mTzIt5tuwJK1h7zDkGiADV6H7e4OB+7i7tUz8LzDvGBJh4TSNdSXPl1EXHS73ri8IuO3CHHc6H0nxhhmpUtU1CEZtjq+xVNdeoDatCOdNE2t+jS3+cm42GKiBOAa3hoUA8GCPWryqpO19/SmvBBlGDMXAGHJNZSaX7qvz1RZ5J3nzVCYiZKanKS1/ERyW2q8qpxmoKzy6FpL78sC8JPlii/Pg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643145837; bh=1lib6Lj9Z8GIO+sbCrC5/s+eDFsftguLDbs1uosRrYH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=je50Q60Topz65NupNXPhIZ4Qi1IhJ3oT9sp9hqKBiHNmVSqYEC8sfJDlXVjUVqJEAHAAV76NL+hEEi1ngQ4wTVl/BeTWNtG4x8CERTceosRIOKN2dOf6oXKdCQGNUnukJNgGplbOtlU8tsdIGl1dFs0F8XOqDK6NEE9hF7zZNzcpUQYj6xDh8b6yQTxg3j/K3rrb7BaotH1Hh3Xbpk6rVha+HmNN66TncQCUAvx/mIe9tzOApRU/31rsYv7rBgpT/USnmtjGwthyQVvRgZUj8ayD1xmho6Ypxqv89OWlJs7QatSrQx7aXZsn0KZ2yz+pccyCxYlfvQwNHPH/U4pYXw== X-YMail-OSG: eqrukj4VM1nEGs6RxLQ1PgmCfZxKnE5WTQ9PHW4Vp6IPB54Z3L9LDUPDH84lN3T eA54s1QMz_Rz1VFRaFY1RMB6AUAdFfh80ctMwIdC2yo4X8yF4OqJTYVLr8IsZ2yjESIHcCdydGVZ VtYGarLdCISR2YZ6f2Z2P4rZxIHqhqYgnfz6mSC9ubvZO.RN8YMOb1ctGPcIcv3wBzWPOGhInmIv OMeD1Rm6vjYhwWseWeqGm7lM2mXtbilnAHQBhRlJWwVZaQRzbp3I1yXOUGTYI4u8I3_VpAbHkfvr 3LAlbwD0sMOBKyFpArJtK7tVw9_1tnAEINg8MrnvCRb2B5nOgMrn9nnXg82hG._1KeEXVtoDniKZ oqO8yb8N2F4sDydIniddCFeno.IxL5oalUPu.ZE8J.ihk3CKf5OGVt6m0zuD.1ZkJZexD9OV3hLR eTBrZRnOs3MnaZdkIFHrRd2.0U6LPCwBNsdgtTKT_MFpJolJHYmNQUeK_wjTv_h7.GN7e2uk8LT0 ksLNOU0EuPj.I12U1RcZMrN8l47c70Hvo_GTOsNS9rWd76NDu_sMkpmZTsSrtGyFAcFIhNj.o5mC 7P6GJHAMKoaHPkjASSwvGAQ12Pd4KK4GsWhOdPT7uBO35Se6g0H2ldOJljsTl2.iLoBH3X5HMy4d 7Rak66Ebb7dci1OkTW_EY_RMqJBV39pakW4hT0E7xO4JhrxZAkDqXtSM6x7TakaR2x6JVabhnwk9 zyQDAZO2hJflU45Uf5bdJkmFEA_mA_WhS7dbyKvjvb1s0Pw5Sjw2zbSHeIRFyHiuWcIIrBlGZgay qkACyBi2Y8B6m_DJRVJgi6HLvrSMyc4TZAwJRyNBkJSvEmaFAnaZ4u...QRGdXRR3DKPx7LDlAnP cM42EyAYq94uO8srBGKgLZfsuUNc0mR9gdmt7kKv6476pDT.fiXOEZ25MRdCAva5QuJF6uuu2ywk jfEIGkejQGxmECAe_KeN85aH.CBaV6mKTSzyGoPLUdVoBpdQy_OHGakaye_L7ZeVKf208HUOny8B dVnuPPcg.YGL03sGr1dMsRqHtrAGWYwFhxHTFMzPuOL4anm_dWqOYxN7XXKx355VWUSHvSos0QEz Jqq1ESl2yT4kIrv_9L0W17UgppXMmyQJDxNUZi1UN04gh5SJo_5iOUbp6gflrHntPGGmp7CiHFfY Oa7AhXYoL9rGR4v8tggiDk04r466Ep7PmbelXefa9R1sF15VRLoH8iQAQeouGJZcI2Uh0zwQcEkf T9b3MeCxdEoF_3biimzzxnga6Kc7XD0pdj_Ju07AwqwU3dYdjNww9ubDoRYtnbzM160fgGube8iB o5I9W605QFuVNhJSZChQl.qTLKpP6qU7qtFJOHqI815hhgFdNwumfS3iOIG9dy4IcAbfeNnOWcbx 9bIFYB6vZ5KGGOSEYj4O9wZCfD6FYoc0tqWYHtUOBX7WsU1CysASd.1B1BqFF1RBMpQ9E8ibXc.t Z5Sm0j_LWyX1txMZkB81nKNIsRALVMqVAsh871ySgvWGcKQC1kUBzV8BTaHBC9mKkRBBfQ42t6jA yvpQx5lP44ot0O9Ymnk0C3Zu4bf2EL8SQUHoRbITAr1LfJh3XQQe8osQF.M7sPbfuqCutZjGq_fK 8siLV9ff6lkZkZ.W0tIKPeb0WCG0M.FOirYmWmzMNdVDsTZ9a6igpgAP4g8nEfFcDX3rOBO0IzHP DksyBcQ4OqFGyGufSTQpjXyI5IIyHvz.k5GEArScu8LWzCuPV5BKJxft3LknBvgi6e2C3Li.anXr llFocsxZ.juHZA78c3YiwXrCVrOuzmnVrz407yUzeoZ5oKWITJlyM6SHP5WThiTy69fIIB0hUyIk qxsdqK8_nQ0ZNvO6b4snMNvUD8LYPA6VRnAhaM3Kz3Vrq.EL0U_w8SbZC9UWV.l2dzvY3KjnrjZJ otyZ.a.7EUAh.c6gcPgdhdyylpIzjZAVUPKpUUGq5U4NXlHql3yzktJvaiSKMI5Bb4fvDQdJ9tkx 63Hv0LBjOsJohCwGe2pwzYb61d0la.LLLUqw9FY4WBCuu5yPiK5PtZNZUWfO6QyZAYkgfhfWH_UY CS3rs.Q_RTW7SM3fEA1WPZqvWUVP3xlM5Vdp0M0FrXo7UkCoRWPigvuwqve75dx8sBmAewtXxxPu lcMldCBzBgUp84r5HoNtLkw9dP3hO6oRuU0Ec.RCmiTuzzRDQD1ZKRCAkp7Rz7GJWx2zi1lRDLv1 GLF3cr67U6ip69wzOKufN.BUrRTBkz63e81US58sJxSfbmN1c6.56P_Utth3ehzFhz.qyg17lGY2 yrmRlLYb69CYdSeM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Jan 2022 21:23:57 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1f543b14c039aa99f9cef7e632c4589a; Tue, 25 Jan 2022 21:23: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> Date: Tue, 25 Jan 2022 13:23:51 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <47B71886-ADDD-43C4-A0E0-0DB066E3E9D2@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jk0GZ4jVDz4sSR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eXF7Rfrr; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6538 Lines: 185 On 2022-Jan-25, at 12:49, Mark Millard wrote: > On 2022-Jan-25, at 10:08, bob prohaska wrote: >=20 >> On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: >>>=20 >>> -DBATCH ? I'm not aware of there being any use of that symbol. >>> Do you have a documentation reference for it so that I could >>> read about it? >>>=20 >> It's a switch to turn off dialog4ports. I can't find the reference >> now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would >> be easier to understand anyway.=20 >=20 > I've never had buildworld buildkernel or the like try to use > dialog4ports. I've only had port building use it. buildworld > and buildkernel can be done with no ports installed at all. > dialog4ports is a port. >=20 > I think -DBATCH was ignored for the activity at hand. Actual evidence for my claim: # grep -r "\" /usr/main-src/Makefile* /usr/main-src/share/mk/ | = more # grep -r "\" /usr/main-src/Makefile* /usr/ports/Mk/ | more /usr/ports/Mk/bsd.licenses.mk:.if ${_LICENSE_STATUS} =3D=3D "ask" && = defined(BATCH) /usr/ports/Mk/bsd.licenses.mk:IGNORE=3D License ${_LICENSE} = needs confirmation, but BATCH is defined /usr/ports/Mk/Uses/perl5.mk:. if defined(BATCH) && = !defined(IS_INTERACTIVE) /usr/ports/Mk/Uses/perl5.mk:. endif # defined(BATCH) && = !defined(IS_INTERACTIVE) /usr/ports/Mk/Uses/cmake.mk:# Default: not set, unless = BATCH or PACKAGE_BUILDING is defined /usr/ports/Mk/Uses/cmake.mk:.if defined(BATCH) || = defined(PACKAGE_BUILDING) /usr/ports/Mk/bsd.port.mk:# to skip this = port by setting ${BATCH}, or compiling only /usr/ports/Mk/bsd.port.mk:.if defined(BATCH) /usr/ports/Mk/bsd.port.mk:.if defined(BATCH) /usr/ports/Mk/bsd.port.mk:SCRIPTS_ENV+=3D BATCH=3Dyes /usr/ports/Mk/bsd.port.mk:# If we're in BATCH mode and the port is = interactive, or we're /usr/ports/Mk/bsd.port.mk:# one might want to leave a build in BATCH = mode running /usr/ports/Mk/bsd.port.mk:.if (defined(IS_INTERACTIVE) && = defined(BATCH)) /usr/ports/Mk/bsd.port.mk: defined(PACKAGE_BUILDING) || = defined(BATCH)) >> On a whim, I tried building devel/llvm13 on a Pi4 running -current = with=20 >> 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: >> nemesis.zefox.com kernel log messages: >> +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST = 2022 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: = 12288 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: = 24576 >> +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory >>=20 >> On an 8GB machine, that seems strange.=20 >=20 > -j build? -j4 ? >=20 > Were you watching the swap usage in top (or some such)? >=20 > Note: The "was killed" related notices have been improved > in main, but there is a misnomer case about "out of swap" > (last I checked). >=20 > An environment that gets "swap_pager: indefinite wait buffer" > notices is problematical and the I/O delays for the virtual > memory subsystem can lead to kills, if I understand right. >=20 > But, if I remember right, the actual message for a directly > I/O related kill is now different. >=20 > I think that being able to reproduce this case could be > important. I probably can not because I'd not get the > "swap_pager: indefinite wait buffer" in my hardware > context. >=20 >> Per the failure message I restarted the build of devel/llvm13 with=20 >> make -DBATCH MAKE_JOBS_UNSAFE=3DYES > make.log & >=20 > Just like -DBATCH is for ports, not buildworld buildkernel, > MAKE_JOBS_UNSAFE=3D is for ports, not buildworld buildkernel, > at least if I understand right. >=20 > In other words, it probably would have been the same result > without the two arguments. Actual evidence for my claim for MAKE_JOBS_UNSAFE : # grep -r MAKE_JOBS_UNSAFE /usr/main-src/Makefile* = /usr/main-src/share/mk/ | more # grep -r MAKE_JOBS_UNSAFE /usr/ports/Mk/ /usr/ports/Mk/bsd.port.mk:# MAKE_JOBS_UNSAFE /usr/ports/Mk/bsd.port.mk:.if defined(DISABLE_MAKE_JOBS) || = defined(MAKE_JOBS_UNSAFE) /usr/ports/Mk/bsd.port.mk:BUILD_FAIL_MESSAGE+=3D Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer. /usr/ports/Mk/bsd.gecko.mk:.if defined(DISABLE_MAKE_JOBS) || = defined(MAKE_JOBS_UNSAFE) >> It seems to be running with only one thread so far, not sure if = that's >> by design or happenstance. >>=20 >>>> However, restarting buildworld using -j1 appears to have worked = past >>>> the former point of failure. >>>=20 >>> Hmm. That usually means one (or both) of two things was involved >>> in the failure: >>>=20 >>> A) a build race where something is not (fully) ready when >>> it is used >>>=20 >>> B) running out of resources, such as RAM+SWAP >>>=20 >>=20 >> The stable/13 machine is short of swap; it has only 2 GB, which >> used to be enough. >=20 > So RAM+SWAP is 1 GiByte + 2 GiByte, so 3 GiByte on that > RPi3*? (That would have been good to know earlier, such > as for my attempts at reproduction.) >=20 > -j for the RPi3* when it was failing? >=20 > Did you havae failures with the .cpp and .sh (so no > make use involved) in the RAM+SWAP context? >=20 >> Maybe that's the problem, but having an error=20 >> report that says it's a segfault is a confusing diagnostic.=20 >>=20 >>> But, as I understand, you were able to use a .cpp and >>> .sh file pair that had been produced to repeat the >>> problem on the RPi3B --and that would not have been a >>> parallel-activity context. >>>=20 >>=20 >> To be clear, the reproduction was on the same stable/13 that >> reported the original failure. An attempt at reproduction >> on a different Pi3 running -current ran without any errors. >> Come to think of it, that machine had more swap, too. >=20 > How much swap? >=20 >>>> It's in the building libraries phase now. >>>> Based on log size I'd guess it's about halfway through buildworld. >>>>=20 >>>=20 >>> Well, hopefully you will not be stuck with -j1 builds in >>> the future as well. >>>=20 >> Indeed! >=20 > At this point, I expect that the failure was tied to the > RAM+SWAP totaling to 3 GiBytes. >=20 > Knowing that context we might have a reproducible report > that can be made based on the .cpp and .sh files, where > restricting the RAM+SWAP use allowed is part of the > report. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 25 22:17:53 2022 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 B8CEC1989FBC for ; Tue, 25 Jan 2022 22:17:54 +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 4Jk1Sd4CTlz3mRd for ; Tue, 25 Jan 2022 22:17:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20PMHrUq044920 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Jan 2022 14:17:53 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20PMHrxS044919; Tue, 25 Jan 2022 14:17:53 -0800 (PST) (envelope-from fbsd) Date: Tue, 25 Jan 2022 14:17:53 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: Troubles building world on stable/13 Message-ID: <20220125221753.GA44654@www.zefox.net> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@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: <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> X-Rspamd-Queue-Id: 4Jk1Sd4CTlz3mRd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6373 Lines: 179 On Tue, Jan 25, 2022 at 12:49:02PM -0800, Mark Millard wrote: > On 2022-Jan-25, at 10:08, bob prohaska wrote: > > > On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: > >> > >> -DBATCH ? I'm not aware of there being any use of that symbol. > >> Do you have a documentation reference for it so that I could > >> read about it? > >> > > It's a switch to turn off dialog4ports. I can't find the reference > > now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would > > be easier to understand anyway. > > I've never had buildworld buildkernel or the like try to use > dialog4ports. I've only had port building use it. buildworld > and buildkernel can be done with no ports installed at all. > dialog4ports is a port. > The attempt to build devel/llvm13 under stable/13 was done under ports. Thus the -DBATCH, to avoid manual intervention. > I think -DBATCH was ignored for the activity at hand. > > > On a whim, I tried building devel/llvm13 on a Pi4 running -current with > > 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: > > nemesis.zefox.com kernel log messages: > > +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST 2022 > > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: 4096 > > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: 4096 > > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: 12288 > > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: 24576 > > +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory > > > > On an 8GB machine, that seems strange. > > -j build? -j4 ? > Since this too was a port build, I let ports decide. It settled on 4. > Were you watching the swap usage in top (or some such)? > Top was running but the failure happened overnight. Not expecting it to fail, I didn't keep a log of swapping activity. The message above was in the next morning's log email. > Note: The "was killed" related notices have been improved > in main, but there is a misnomer case about "out of swap" > (last I checked). > > An environment that gets "swap_pager: indefinite wait buffer" > notices is problematical and the I/O delays for the virtual > memory subsystem can lead to kills, if I understand right. > > But, if I remember right, the actual message for a directly > I/O related kill is now different. > In this case the message was "unable to reclaim memory", a message I've not seen before. > I think that being able to reproduce this case could be > important. I probably can not because I'd not get the > "swap_pager: indefinite wait buffer" in my hardware > context. > If it's relevant, the case of /usr/ports/devel/llvm13 seems like the most expedient test, since it did fail with realistic amounts of memory and swap. I gather that there's a certain amount of self-recompilation in buildworld, is that true of the port version? Does it matter? > > Per the failure message I restarted the build of devel/llvm13 with > > make -DBATCH MAKE_JOBS_UNSAFE=YES > make.log & > > Just like -DBATCH is for ports, not buildworld buildkernel, > MAKE_JOBS_UNSAFE= is for ports, not buildworld buildkernel, > at least if I understand right. > This was a ports build on the Pi4. The restart is running single-thread and quite slow, I'm tempted to stop it unless a failure would be useful. > > >>> However, restarting buildworld using -j1 appears to have worked past > >>> the former point of failure. > >> [this on stable/13 pi3] > >> Hmm. That usually means one (or both) of two things was involved > >> in the failure: > >> > >> A) a build race where something is not (fully) ready when > >> it is used > >> > >> B) running out of resources, such as RAM+SWAP > >> > > > > The stable/13 machine is short of swap; it has only 2 GB, which > > used to be enough. > > So RAM+SWAP is 1 GiByte + 2 GiByte, so 3 GiByte on that > RPi3*? (That would have been good to know earlier, such > as for my attempts at reproduction.) > Correct, 3GB RAM+swap. Didn't realize it would turn out to be important, sorry! > -j for the RPi3* when it was failing? > -j4, but I think it also failed at -j2. > Did you havae failures with the .cpp and .sh (so no > make use involved) in the RAM+SWAP context? > Using the .cpp and .sh file on a Pi3 with 2 GB swap running stable/13 there was a consistent failure. Using the .cpp and .sh files on a Pi3 with 7GB swap there was no failure. Using a build of /usr/ports/devel/llvm13 as a test the build failed even with 8 GB of RAM and 8 GB of swap. > > Maybe that's the problem, but having an error > > report that says it's a segfault is a confusing diagnostic. > > > >> But, as I understand, you were able to use a .cpp and > >> .sh file pair that had been produced to repeat the > >> problem on the RPi3B --and that would not have been a > >> parallel-activity context. > >> > > > > To be clear, the reproduction was on the same stable/13 that > > reported the original failure. An attempt at reproduction > > on a different Pi3 running -current ran without any errors. > > Come to think of it, that machine had more swap, too. > > How much swap? > Two swap partitions, 3.6 GB and 4 GB, both in use. > > At this point, I expect that the failure was tied to the > RAM+SWAP totaling to 3 GiBytes. > That seems likely, or at least a reasonable suspicion. > Knowing that context we might have a reproducible report > that can be made based on the .cpp and .sh files, where > restricting the RAM+SWAP use allowed is part of the > report. > There seem to be some other reports of clang using unreasonable amounts of memory, for example https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261341 A much older report that looks vaguely similar (out of memory reported as segfault) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172576 It's not arm-related and dates from 2012 but is still open. I'll try to repeat some of the tests using the logging script used previously. Right now it contains: #!/bin/sh while true sysctl hw.regulator.5v0.min_uvolt ; do vmstat ; gstat -abd -I 10s ; date ; swapinfo ; tail \ -n 2 /var/log/messages ; netstat -m | grep "mbuf clusters" ; ps -auxd -w -w done Changes to the script are welcome, the output is voluminous. Thanks for reading! bob prohaska From nobody Tue Jan 25 23:44:33 2022 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 4335B197E331 for ; Tue, 25 Jan 2022 23:44:35 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Jk3Ng1Jydz4t9l for ; Tue, 25 Jan 2022 23:44:35 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643154275; 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=610Sp+6N/MCa2Hu4qCb1SK703cbrgCH7tVUvtu5B2EM=; b=X6VaYSf5raeGVFhbquSlhMBFE10ORx5GKy7IwP73yxK1OB3tFAY80Imdu5fmDokQvLoEwF 36rjCsMkuToXMvEw5FPsq3zqkzkTVHju4uEe2apIXLWlachxy9Z+72dwKCk05gAOtCNt6Y OjZqUqK78zx7W5Fo8nXI+clOuzfRJMxMP9cUfZ4Ekh4LI6nP9kSrqgFOUuGosuvzrClMjV gQhE25DpUx46yrX4Gns4IRTC94fwl8c+5LVvagfnuvjKFTs16wOgl7xP35KQum4wsZaAZ6 Q/ltAnbX2fOQ/yGoaaiTN/SwYw+rhhXZMSqnylimG28JAHNVN8kUs0Jf6lDVww== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id C91C8FC05 for ; Tue, 25 Jan 2022 23:44:34 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <4d738da2-28f0-6af2-4213-934244cc95f2@FreeBSD.org> Date: Wed, 26 Jan 2022 00:44:33 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 To: freebsd-arm@freebsd.org Content-Language: en-US From: Jesper Schmitz Mouridsen Subject: pinebook pro video console not active Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643154275; 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=610Sp+6N/MCa2Hu4qCb1SK703cbrgCH7tVUvtu5B2EM=; b=MWmMecbgL+gvFrsRGk+6ZJJko6EgTjIKJS3vNaSRPrbZk5MyCNxfWUd3oBtDclXXfpN7Tk azzWCeQbt2zGIMxrEHMmgEnR405rDfL4oLe8T4JVNoxI29695GzFSdNyPv7ytBTJuXAZQy 6jc6HqiIf3Ra2hDwTXKxSHJe6n3e9Iv9FEnNUjnnZFY71NBJQ8UZTmpL5jiJ4P5xa+PCuW yCzqGIHCKjd/3FCzui+AYb0bqJPZK3iED/Lj9QlMJdZP4/1ZelMFSgOoF0XdIvThu7e7Gb W2PZ/4k2XnaOnzOATbfIPi4wCEQET2/SYyXKbbZ5iAMCnXqevo3/QaN8SRDXSQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643154275; a=rsa-sha256; cv=none; b=IMMyxZyNtKYPUbLCVK5cUmOZTI4k+U/zg7gSFp+YNlaYdAMsemTlVD+Nev45aFbkVyZFCu eQV3xaiRrNF7qMFUYTLqio22fIqFjjPY8wezXnwdRJ6vOAKgAhSQeO1E79Oq2Y2XPrJyU0 b7rkSPRMnSvFSeZVY+4gn09BJhFohomLgh2fm8U5dJItOVEZN0OVV1/Z6HdSftb1jZQ12o xQsiNJICAJt1sC4/EXuWPnCK4qD4Io6a/bHIWXSRgcUML5Y9X9Dr2LD+2NfRWxvjZNx8E/ rLyegOKDcSPBhydwUntdDGJk9Bg+XfLGOW9GAgrBIEoiIywHXh9MVXV9Qp7zMQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 435 Lines: 15 Hi On Pinebook Pro 14-current with console="efi,comconsole" in /boot/loader.conf vidcontrol -i active < /dev/console is not working because serial stays primary. Reverting 123b5b8763778e83b6816ad9db62a9b956055c32 fixes that for me. Can someone share some light on why that is? console kit relies on /dev/console beeing active so it is an annoying bug.. the original review is here https://reviews.freebsd.org/D32992 Thanks /jsm From nobody Wed Jan 26 00:08:15 2022 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 81C9F198C244 for ; Wed, 26 Jan 2022 00:08:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk3w90LB2z3JG9 for ; Wed, 26 Jan 2022 00:08:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643155696; bh=3ycEJlwAvPHArge7s6KMmd+RvVKsd2PqPq24WBlQDKM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mumqSeT+w9PJ8uMBVEUjjLGWLxOH2Sd+er7/2R2nmPQ9KzN6HaKpE04mtpC05z5hdQ5HLT3vgHPxeMdkgUbMzA7+yxyy22bBCCnGBYO2ckHBZI2NimZfv9FfAPvPyAqGWpND6XdRiiTJ6hDQuhNyHfzL3WyRD0Xgl5NVGbAIcPHkND+hD/HEohEPTTDcU5jMngnFTexlYhBQ8DxJCxnCiPUH87r79XqMNJqVaNghMaSetsBLAw7S1iSh5ylfhK1CFAFp5m5AYzruM7o5EAij5du5sn0rjNDIa2GsTlsXj9XP3zSWWJ6dM7WvDzFzA0JSEbMWqLwWeVbqOGyhZfPj2Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643155696; bh=sZKX65+ca6DOOmxyTwEq+sBTYGTOlf6SXuTfGHf2plC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EIzvRJLO7aC2C1IxM5ajrAXGoexNIS8E1FqjO5OIFHsmJ1b7OHEAIR5KnbEmxx2q1Nyb0/okxHsH5CDX/c3MCpGdg9I4myEZbscxmuiuvaTI267YfixhFoyBhgfSRJEvovqUXwXD7BTjcnAlwofM3KVNmXiPdqEoIPcnRzoLBi0vYJK3994x8zL+tXanloXINBxIzc5kZW7wFMcgn6KKPDdR5cKSR8OJ2uQm/N85T8yKss/u7eBZYWGqSbcaoScJBFMu6zhPQABoOjHgmzH/MDWp6ddtc5pak2Xwemd4U7m00Mo4X6ZmZfYYn/e36g5nRk8xxmJoYq82v8+kLhFU8Q== X-YMail-OSG: mTBGkZYVM1lBomuIXoL_4eBbxBcy.EW.UKSXBAYjT2CskE.gbe3qImpp_V8GAgE uQSK5M25rgbd.Q_RK7aBzXZF4mEzuYwaj5tMsY7TB1SN0KKZ_L5uU41W9nGgGtLNOiCYcksD_awO mlXuQAj8uRRuMUghuG3MFD1qITQqnRO5ZFWI6Zup1j3PuN270NQO1sTzHdIA_CfrzXXEvnmgFb5p 3rCfSXprybyJou6nxH7im1c0wtQpZySeOGdqu942ybCA1Am6d405o3RDbdMhagG4je.359_5cPUs HZXyDImqKujRpRr4QHapdOqqAxnp00UtTCiZOBj.RrDTIRHiWH26KCwAvT_ZdVbsPs_6xjjkGgb5 1D9QUBQEThvTUcyaHRIWGz2C3QbVrUyMYK4Xz7xPIcLkXON_tqc.rtllObJUv.ccKktZBw7H7nVt zHJcMDcViPfu_4uCMCgQlXQBbKg1FzPWsXdL.jk9PZzbrKCZ5GXNeRNgaxw7zJZ.WceC0I3c8WLv UBDQlE_0WiD_3rBaPRjyyQWmn06jzaj7UKf2h_eZKcNhRQliUBcdN65XvtCyM3gC9BrUfD3Gdex0 An08QUkexamlbYMwIssNq_VBhJLoyK2YpTGsLTJuNNnC9lbDMwWZFX9O9gG4NQ2ENMHAtEnmwrbl Fe_l7NyPWuoPTYgs7MF6JLKn_HvP5sU0pBT8NJviC3bLjgNVUqC66ozPwSWvADk26YE5yXFoYUWM Mt.XFXrlf_dy5noJVFDmgb72M7pFrB9IHzO8JIymtw9QIZvAVplUMP6bglrtahc.EUSmDKrkLUb9 T_0s0K_ha0gUokPb1Bke8_wv6SjNGYZJcGTFeMCE4f.FNMYcy37hE8p947mmaSv7tPuQ_7lRvBFj aXsFFuRcaw_95NYh5f4WsdBKi.dYKwRa3Sx3hKvusKNCQAvdUJhi1ARMkcDtEtgp1wNww60.BITv rAlKry1jU69k4y1N9FGnYsKoefPgcIKTUQnbpxHYuiwGsfUhE_vtlnSP7P8Iqd.1feD2LAvFH5yT zR2UkAAZ6i0ANcAqUjCg.QnaZIXLijbz87msXd3AMSPJ.ls1fooI8QB9EjFKX9r6KQYeXMfsIrAK yxxEo5k.41d1rVBvAJF.IOnBUYiRt2XipN0SY.nLeOsKtjYDQxLn753K9e2JpF9D0dqWtQSZPEtZ Z.rfFV7G.Lvf0eIYWzEoG2CC5zxXt81ZqF1wNepsncak1zrGoX3rfdPVAjx1Z6BuvsuyJIrTDzPr b648m_b6igAJ_CVNKo..FTHekjcdRfxIs50R6kGWqLIYbi.NtjddmE8LZhn5XM9yHN.e2SzPjJPN HDa.jBuO6ikz2TGWPo173thGAzb8eURIUkJ6NWMEG9EajTZ1WSdBAB0_3hXlrk8fRg6IICBsDxu_ an3R5Z2knZYvc5.rNqcdw2W0Wt3t.i9EwJSA7_FvhVUIMOoxAGpLNzHcm.eRIvZ9tN1HA_k.2.zV GMZDU0qnRfrkfgwSihP3SPS4hHEwSVDKQzNszEm8isbkkjyUDjg3yDjcatqhBpSfK44DFnMtFv2. FsW_gyTAL4.Bi_0mveG_85fTtgOP1xrDUg4cuMF6IDHw9hyfX7qYAj21o7tv.VM30kuWL78N0CSX hx6LY58zkD0zS.Ufyr6nlBPia1PQbkyIeL5fQAxPRcD1o0bdf_TCNE1mdSmJnjaXJTt3_Qz2_vdY q5C60_3uNNmOInC6dTMLAg_c6vbVkGhZnJYUJ_tvyteUxmF5w0Mex3D0x4_H.zmwS7UBHuoLv0Y4 zHR1ZVMzfPlmZf20fn2CDRxH1c.dQXcJoOcKsvyLFQ7ycsRHt_jAFf2y9qDao0E3rlrNYe3fJzVp GZxzowdOcy.KDNe1dz2.U7gkoclGLwKGiV1F22GkNooxvkjM0Q2ewjCBPFABMe_eZTdtLcD5Ivx1 Er1GBw6rWW2PLZeLs2VeXhGG5_MVtWnwgBbcq5pEDhK4uHeDfSnKkmkjBQNewTHcb2HuTRwVLuKJ m00mF5f6s8kk2.N1dsX9s_IJr16F7usqw96h5mRlNaXFjozqMOJ2ZWaR5yBw1pLJFI9M..UyCB3t L9nXF3SY1lnbQk1oMO4zfcSGDDHF5lWHNn0vJIjA_764y.5V82hg15pkajNBWXUlrlqi7D8n3dJL bYi6XFvwWOmbg4sOQ_APQlPrjqjIz3pz4DeGPFxdVCvW7Umg7Bxh5eMxvz0dEgE3xeHUG7y5CiB2 OsJgqLQbU0btQk1wNlXiTjp4AC.8bCace0JcJzEHUnWmcdpz5b7_s6eOjxALh7rY_YmJlKODVe2b iPsJVDrhHzYciOSC1Ab.AkTYdIvRYCNS5RCz.f359r1TjfM10Z5mDfvcnGJaD.xyBhg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 26 Jan 2022 00:08:16 +0000 Received: by kubenode514.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fe717d92b617e3896648c0e149358da9; Wed, 26 Jan 2022 00:08:15 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220125221753.GA44654@www.zefox.net> Date: Tue, 25 Jan 2022 16:08:15 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jk3w90LB2z3JG9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mumqSeT+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7752 Lines: 225 On 2022-Jan-25, at 14:17, bob prohaska wrote: > On Tue, Jan 25, 2022 at 12:49:02PM -0800, Mark Millard wrote: >> On 2022-Jan-25, at 10:08, bob prohaska wrote: >>=20 >>> On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: >>>>=20 >>>> -DBATCH ? I'm not aware of there being any use of that symbol. >>>> Do you have a documentation reference for it so that I could >>>> read about it? >>>>=20 >>> It's a switch to turn off dialog4ports. I can't find the reference >>> now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would >>> be easier to understand anyway.=20 >>=20 >> I've never had buildworld buildkernel or the like try to use >> dialog4ports. I've only had port building use it. buildworld >> and buildkernel can be done with no ports installed at all. >> dialog4ports is a port. >>=20 >=20 > The attempt to build devel/llvm13 under stable/13 was done under = ports. > Thus the -DBATCH, to avoid manual intervention. I missed the later reference to devel/llvm13 as applying to the above and then later confused the contexts, effectively ignoring devel/llvm13 completely. Sorry. >> I think -DBATCH was ignored for the activity at hand. >>=20 >>> On a whim, I tried building devel/llvm13 on a Pi4 running -current = with=20 >>> 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: >>> nemesis.zefox.com kernel log messages: >>> +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST = 2022 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, = size: 4096 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: = 4096 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: = 12288 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, = size: 24576 >>> +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory >>>=20 >>> On an 8GB machine, that seems strange.=20 >>=20 >> -j build? -j4 ? >>=20 > Since this too was a port build, I let ports decide. It settled on 4. >=20 >> Were you watching the swap usage in top (or some such)? >>=20 >=20 > Top was running but the failure happened overnight. Not expecting=20 > it to fail, I didn't keep a log of swapping activity. The message > above was in the next morning's log email. >=20 >> Note: The "was killed" related notices have been improved >> in main, but there is a misnomer case about "out of swap" >> (last I checked). >>=20 >=20 >> An environment that gets "swap_pager: indefinite wait buffer" >> notices is problematical and the I/O delays for the virtual >> memory subsystem can lead to kills, if I understand right. >>=20 >> But, if I remember right, the actual message for a directly >> I/O related kill is now different. >>=20 >=20 > In this case the message was "unable to reclaim memory", a=20 > message I've not seen before.=20 Yea, it is one, more accurate wording of the old out of swap notices --probably covering most occurrences. >> I think that being able to reproduce this case could be >> important. I probably can not because I'd not get the >> "swap_pager: indefinite wait buffer" in my hardware >> context. I was thinking buildworld buildkernel here. I got the context wrong. I'll eventually do a devel/llvm13 build on the 8 GiByte RPi4B with my patched top monitoring various "maximum observed" figures. > If it's relevant, the case of /usr/ports/devel/llvm13 seems like > the most expedient test, since it did fail with realistic amounts > of memory and swap. I gather that there's a certain amount of=20 > self-recompilation in buildworld, is that true of the port version? > Does it matter? >=20 >>> Per the failure message I restarted the build of devel/llvm13 with=20= >>> make -DBATCH MAKE_JOBS_UNSAFE=3DYES > make.log & >>=20 >> Just like -DBATCH is for ports, not buildworld buildkernel, >> MAKE_JOBS_UNSAFE=3D is for ports, not buildworld buildkernel, >> at least if I understand right. >>=20 > This was a ports build on the Pi4. The restart is running = single-thread > and quite slow, I'm tempted to stop it unless a failure would be = useful. Again an example of my not switching context correctly. Sorry. >>>>> However, restarting buildworld using -j1 appears to have worked = past >>>>> the former point of failure. >>>>=20 > [this on stable/13 pi3]=20 >>>> Hmm. That usually means one (or both) of two things was involved >>>> in the failure: >>>>=20 >>>> A) a build race where something is not (fully) ready when >>>> it is used >>>>=20 >>>> B) running out of resources, such as RAM+SWAP >>>>=20 >>>=20 >>> The stable/13 machine is short of swap; it has only 2 GB, which >>> used to be enough. >>=20 >> So RAM+SWAP is 1 GiByte + 2 GiByte, so 3 GiByte on that >> RPi3*? (That would have been good to know earlier, such >> as for my attempts at reproduction.) >>=20 > Correct, 3GB RAM+swap. Didn't realize it would turn out to=20 > be important, sorry! Do not know yet if it would have helped reproduction of the problem. But I now know that I should try for something that would give evidence about getting near or over 3 GiBytes. >> -j for the RPi3* when it was failing? >>=20 > -j4, but I think it also failed at -j2.=20 >> Did you havae failures with the .cpp and .sh (so no >> make use involved) in the RAM+SWAP context? >>=20 > Using the .cpp and .sh file on a Pi3 with 2 GB swap=20 > running stable/13 there was a consistent failure. Ahh, a simpler, quicker test context/case. So that is likely what I'd look into. > Using the .cpp and .sh files on a Pi3 with 7GB swap > there was no failure.=20 >=20 > Using a build of /usr/ports/devel/llvm13 as a test the > build failed even with 8 GB of RAM and 8 GB of swap. >=20 >>> Maybe that's the problem, but having an error=20 >>> report that says it's a segfault is a confusing diagnostic.=20 >>>=20 >>>> But, as I understand, you were able to use a .cpp and >>>> .sh file pair that had been produced to repeat the >>>> problem on the RPi3B --and that would not have been a >>>> parallel-activity context. >>>>=20 >>>=20 >>> To be clear, the reproduction was on the same stable/13 that >>> reported the original failure. An attempt at reproduction >>> on a different Pi3 running -current ran without any errors. >>> Come to think of it, that machine had more swap, too. >>=20 >> How much swap? >>=20 > Two swap partitions, 3.6 GB and 4 GB, both in use. So that is the devel/llvm13 example, not buildworld buildkernel, not the .cpp and .sh combination. >>=20 >> At this point, I expect that the failure was tied to the >> RAM+SWAP totaling to 3 GiBytes. >>=20 >=20 > That seems likely, or at least a reasonable suspicion.=20 >=20 >> Knowing that context we might have a reproducible report >> that can be made based on the .cpp and .sh files, where >> restricting the RAM+SWAP use allowed is part of the >> report. >>=20 >=20 > There seem to be some other reports of clang using unreasonable > amounts of memory, for example=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261341 >=20 > A much older report that looks vaguely similar (out of memory > reported as segfault) > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D172576 > It's not arm-related and dates from 2012 but is still open. >=20 > I'll try to repeat some of the tests using the logging script > used previously. Right now it contains: >=20 > #!/bin/sh > while true > sysctl hw.regulator.5v0.min_uvolt ; do vmstat ; gstat -abd -I 10s ; = date ; swapinfo ; tail \ > -n 2 /var/log/messages ; netstat -m | grep "mbuf clusters" ; ps -auxd = -w -w > done >=20 > Changes to the script are welcome, the output is voluminous. I'll probably not get to experimenting with this for some time. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 26 00:36:29 2022 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 1F5F8196F76E for ; Wed, 26 Jan 2022 00:36:35 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (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 "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk4Xd36zzz3kfm; Wed, 26 Jan 2022 00:36:32 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 20Q0aTcm071987; Wed, 26 Jan 2022 09:36:29 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202201260036.20Q0aTcm071987@kx.truefc.org> Date: Wed, 26 Jan 2022 09:36:29 +0900 From: KIRIYAMA Kazuhiko To: Jesper Schmitz Mouridsen Cc: KIRIYAMA Kazuhiko , freebsd-arm@freebsd.org Subject: Re: Failed boot at drm_vblank in arm64/aarch64 on PBP In-Reply-To: <68641063-f78c-743b-d528-348d6ffdecab@FreeBSD.org> References: <202201250215.20P2FSFU038389@kx.truefc.org> <68641063-f78c-743b-d528-348d6ffdecab@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4Jk4Xd36zzz3kfm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-2.95 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[kiri]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.85)[-0.846]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 18172 Lines: 346 Hi, Jesper On Wed, 26 Jan 2022 03:45:05 +0900, Jesper Schmitz Mouridsen wrote: > > > > On 25.01.2022 03.15, KIRIYAMA Kazuhiko wrote: > > Hi, all > > > > I've re-made boot image for Pinebook Pro (PBP) of > > 14.0-CURRENT n252589-ece746877783 which is made by > > GENERIC-DRM kernel for Panfrost driver [1] : > > > > First `git subtree add' to 14.0-CURRENT (f72926eab00c) in src server : > > > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git checkout f72926eab00c > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git remote add drm-subtree https://github.com/jsm222/drm-subtree.git > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git subtree add --prefix sys/dev/drm/ drm-subtree pinebookpro-test > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # git rev-parse --verify --short HEAD > > ece746877783 > > root@vm:/ds/src/freebsd/current/14.0/f72926eab00c.generic_drm # cd .. > > root@vm:/ds/src/freebsd/current/14.0 # mv f72926eab00c.generic_drm ece746877783.generic_drm > > > > and then build GENERIC-DRM kernel and boot image on > > 14.0-CURRENT VM : > > > > # cd /usr/src > > # make buildworld TARGET=arm64 > > # make buildkernel TARGET=arm64 KERNCONF=GENERIC-DRM > > # cd /usr/src/release > > # make clean memstick.img TARGET=arm64 TARGET_ARCH=aarch64 KERNCONF=GENERIC-DRM > > > > Then boot from it. Failed : > > > > ---<>--- > > 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 compliance > > Copyright (c) 1992-2022 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-CURRENT #0 n252589-ece746877783-dirty: Tue Jan 25 03:42:31 JST 2022 > > root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64 > > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) > > VT(efifb): resolution 1920x1080 > > module firmware already present! > > real memory = 4150083584 (3957 MB) > > avail memory = 4022452224 (3836 MB) > > Starting CPU 1 (1) > > Starting CPU 2 (2) > > Starting CPU 3 (3) > > Starting CPU 4 (100) > > Starting CPU 5 (101) > > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > > arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. > > random: entropy device external interface > > MAP f3f10000 mode 2 pages 4 > > MAP f3f15000 mode 2 pages 4 > > MAP f6f30000 mode 2 pages 16 > > kbd0 at kbdmux0 > > ofwbus0: > > clk_fixed0: on ofwbus0 > > simplebus0: on ofwbus0 > > rk_grf0: mem 0xff320000-0xff320fff on ofwbus0 > > rk3399_pmucru0: mem 0xff750000-0xff750fff on ofwbus0 > > rk3399_cru0: mem 0xff760000-0xff760fff on ofwbus0 > > rk_grf1: mem 0xff770000-0xff77ffff on ofwbus0 > > regfix0: on ofwbus0 > > regfix1: on ofwbus0 > > regfix2: on ofwbus0 > > regfix3: on ofwbus0 > > regfix4: on ofwbus0 > > regfix5: on ofwbus0 > > regfix6: on ofwbus0 > > regfix7: on ofwbus0 > > regfix8: on ofwbus0 > > regfix9: on ofwbus0 > > regfix10: on ofwbus0 > > regfix11: on ofwbus0 > > simple_mfd0: mem 0xff310000-0xff310fff on ofwbus0 > > psci0: on ofwbus0 > > rk_drm0: on ofwbus0 > > gic0: mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0 > > its0: mem 0xfee20000-0xfee3ffff on gic0 > > rk_iodomain0: mem 0-0xff31ffff,0-0xfff on rk_grf0 > > rk_iodomain1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_pinctrl0: on ofwbus0 > > gpio0: mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0 > > gpiobus0: on gpio0 > > gpio1: mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0 > > gpiobus1: on gpio1 > > gpio2: mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0 > > gpiobus2: on gpio2 > > gpio3: mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0 > > gpiobus3: on gpio3 > > gpio4: mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0 > > gpiobus4: on gpio4 > > rk_i2c0: mem 0xff110000-0xff110fff irq 20 on ofwbus0 > > iicbus0: on rk_i2c0 > > rk_i2c1: mem 0xff130000-0xff130fff irq 22 on ofwbus0 > > iicbus1: on rk_i2c1 > > rk_i2c2: mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0 > > iicbus2: on rk_i2c2 > > fan53555_pmic0: at addr 0x80 on iicbus2 > > fan53555_pmic1: at addr 0x82 on iicbus2 > > rk_i2c3: mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0 > > iicbus3: on rk_i2c3 > > rk808_pmu0: at addr 0x36 irq 76 on iicbus2 > > rk_vop0: mem 0xff8f0000-0xff8f3efb irq 53 on ofwbus0 > > rk_vop0: VOP version: 3068896 > > generic_timer0: irq 2,3,4,5 on ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > > rk_tsadc0: mem 0xff260000-0xff2600ff irq 35 on ofwbus0 > > mmc_pwrseq0: on ofwbus0 > > rk_edp0: mem 0xff970000-0xff977fff irq 62 on ofwbus0 > > rk_usb2phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_usb2phy1: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_emmcphy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_pcie_phy0: mem 0-0xff76ffff,0-0xffff on rk_grf1 > > rk_typec_phy0: mem 0xff7c0000-0xff7fffff on ofwbus0 > > rk_typec_phy1: mem 0xff800000-0xff83ffff on ofwbus0 > > cpulist0: on ofwbus0 > > cpu0: on cpulist0 > > cpufreq_dt0: on cpu0 > > cpufreq_dt0: Found cpu-supply > > cpu1: on cpulist0 > > cpufreq_dt1: on cpu1 > > cpufreq_dt1: Found cpu-supply > > cpu2: on cpulist0 > > cpufreq_dt2: on cpu2 > > cpufreq_dt2: Found cpu-supply > > cpu3: on cpulist0 > > cpufreq_dt3: on cpu3 > > cpufreq_dt3: Found cpu-supply > > cpu4: on cpulist0 > > cpufreq_dt4: on cpu4 > > cpufreq_dt4: Found cpu-supply > > cpu5: on cpulist0 > > cpufreq_dt5: on cpu5 > > cpufreq_dt5: Found cpu-supply > > pmu0: irq 0 on ofwbus0 > > pmu1: irq 1 on ofwbus0 > > pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 > > pcib0: Gen1 link training timeouted: 0x00080001. > > pci0: on pcib0 > > pcib1: at device 0.0 on pci0 > > pcib0: failed to reserve resource for pcib1 > > pcib1: failed to allocate initial memory window: 0-0xfffff > > pci1: on pcib1 > > rockchip_dwmmc0: mem 0xfe310000-0xfe313fff irq 10 on ofwbus0 > > rockchip_dwmmc0: Hardware version ID is 270a > > rockchip_dwmmc1: mem 0xfe320000-0xfe323fff irq 11 on ofwbus0 > > rockchip_dwmmc1: Hardware version ID is 270a > > mmc0: on rockchip_dwmmc1 > > sdhci_fdt0: mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0 > > rk_emmcphy0: got emmcclk clock > > sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk. > > sdhci_fdt0: 1 slot(s) allocated > > mmc1: on sdhci_fdt0 > > ehci0: mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0 > > usbus0: EHCI version 1.0 > > usbus0 on ehci0 > > ohci0: mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0 > > usbus1 on ohci0 > > ehci1: mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0 > > usbus2: EHCI version 1.0 > > usbus2 on ehci1 > > ohci1: mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0 > > usbus3 on ohci1 > > rk_dwc30: on ofwbus0 > > xhci0: mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30 > > xhci0: 64 bytes context size, 32-bit DMA > > usbus4: trying to attach > > usbus4 on xhci0 > > rk_dwc31: on ofwbus0 > > xhci1: mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31 > > xhci1: 64 bytes context size, 32-bit DMA > > usbus5: trying to attach > > usbus5 on xhci1 > > es8316codec0: at addr 0x22 on iicbus0 > > iic0: on iicbus0 > > iic1: on iicbus1 > > uart0: mem 0xff180000-0xff1800ff irq 26 on ofwbus0 > > uart0: debug port (-1,n,8,1) > > uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0 > > uart1: console (1500000,n,8,1) > > spi0: mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0 > > spibus0: on spi0 > > spibus0: at cs 0 mode 0 > > iic2: on iicbus2 > > iicbus3: at addr 0x44 > > iic3: on iicbus3 > > pwm0: mem 0xff420000-0xff42000f on ofwbus0 > > pwmbus0: on pwm0 > > pwmc0: channel 0 on pwmbus0 > > pwm1: mem 0xff420020-0xff42002f on ofwbus0 > > pwmbus1: on pwm1 > > pwmc1: channel 0 on pwmbus1 > > i2s0: mem 0xff890000-0xff890fff irq 51 on ofwbus0 > > Cannot set frequency for clk: clkin_i2s, error: 34 > > Cannot set frequency for clk: xin24m, error: 34 > > pcm0: on ofwbus0 > > gpioc0: on gpio0 > > gpioc1: on gpio1 > > gpioc2: on gpio2 > > gpioc3: on gpio3 > > gpioc4: on gpio4 > > rk_edp_panel0: on ofwbus0 > > gpioled0: on ofwbus0 > > pcm1: on ofwbus0 > > simpleamp0: on ofwbus0 > > armv8crypto0: > > Timecounters tick every 1.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 12Mbps Full Speed USB v1.0 > > usbus2: 480Mbps High Speed USB v2.0 > > usbus3: 12Mbps Full Speed USB v1.0 > > usbus4: 5.0Gbps Super Speed USB v3.0 > > usbus5: 5.0Gbps Super Speed USB v3.0 > > rk_drm0: port found > > <6>[drm] Connector eDP-1: get mode from tunables: > > <6>[drm] - kern.vt.fb.modes.eDP-1 > > <6>[drm] - kern.vt.fb.default_mode > > rk_drm0: Cannot find port with phandle 10 > > rk_drm_fb_preinit > > <6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > <6>[drm] No driver support for vblank timestamp query. > > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. > > VT: Replacing driver "efifb" with new "fb". > > <6>[drm] Initialized rockchip 1.0.0 20201113 for rk_drm on minor 0 > > rk808_pmu0: registered as a time-of-day clock, resolution 1.000000s > > ugen3.1: at usbus3 > > uhub0 on usbus3 > > uhub0: on usbus3 > > ugen2.1: at usbus2 > > uhub1 on usbus2 > > uhub1: on usbus2 > > ugen1.1: at usbus1 > > uhub2 on usbus1 > > uhub2: on usbus1 > > ugen5.1: at usbus5 > > uhub3 on usbus5 > > uhub3: on usbus5 > > ugen4.1: at usbus4 > > uhub4 on usbus4 > > uhub4: on usbus4 > > ugen0.1: at usbus0 > > uhub5 on usbus0 > > uhub5: on usbus0 > > mmcsd0: 8GB at mmc0 20.0MHz/4bit/1016-block > > WARNING cur_vblank != vblank->last failed at /usr/src/sys/dev/drm/core/drm_vblank.c:279 > > Fatal data abort: > > x0: ffffa0000091f498 > > x1: 0 > > x2: a8 > > x3: 102 > > x4: 102 > > x5: ffff00009a845990GEOM: mmcsd0: the secondary GPT header is not in the last LBA. > > (_end + 9976a990) > > x6: 0 > > x7: 501 > > x8: ffffa00000d5f000 > > x9: 2 > > x10: 2 > > x11: 0 > > x12: 0 > > x13: 0 > > x14: 0 > > x15: 10 > > x16: 400 > > x17: 0 > > x18: ffff00009a845810 (_end + 9976a810) > > x19: ffffa00000d5b600 > > x20: ffffa0000091f498 > > x21: 102 > > x22: 2 > > x23: ffff000000f10b30 (proc0 + 0) > > x24: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > > x25: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > > x26: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > > x27: ffff000000cb5000 (sdta_vfs_vop_vop_spare1_return0 + 0) > > x28: 0 > > x29: ffff00009a845810 (_end + 9976a810) > > sp: ffff00009a845810 > > lr: ffff0000007080e8 (linux_alloc_current + 58) > > elr: ffff000000708360 (linux_alloc_current + 2d0) > > spsr: 60000045 > > far: e > > esr: 96000004 > > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > > WARNING !list_empty(&lock->head) failed at /usr/src/sys/dev/drm/core/drm_modeset_lock.c:268 > > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:615 > > WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:660 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 > > WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/src/sys/dev/drm/core/drm_atomic_helper.c:865 > > <3>[drm: 0xffff00000090f048] *ERROR* [CRTC:33:crtc-0] hw_done timed out > > <3>[drm: 0xffff00000090f074] *ERROR* [CRTC:33:crtc-0] flip_done timed out > > <3>[drm: 0xffff00000090f0fc] *ERROR* [CONNECTOR:35:eDP-1] hw_done timed out > > <3>[drm: 0xffff00000090f128] *ERROR* [CONNECTOR:35:eDP-1] flip_done timed out > > <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:31:plane-0] hw_done timed out > > <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:31:plane-0] flip_done timed out > > <3>[drm: 0xffff00000090f1b8] *ERROR* [PLANE:32:plane-1] hw_done timed out > > <3>[drm: 0xffff00000090f1e4] *ERROR* [PLANE:32:plane-1] flip_done timed out > > [CRTC:33:crtc-0] vblank wait timed out > > > > Is there any suggetions ? > > > I am currently building a newer image to try to reproduce, in the mean I put my image to [1]. [1] http://www.truefc.org/~kiri/freebsd/pbp/FreeBSD-14.0-CURRENT-GENERIC-DRM-PINEBOOKPRO-20220125-ece746877783-271989-memstick.img > time did you try my prebuild image here > http://build.schmitz.computer/build/pbp/FreeBSD-14.0-CURRENT-arm64-aarch64-PINEBOOKPRO.img.xz > ? > > Thanks > /jsm > > > Best regards > > > > [1] https://github.com/jsm222/drm-subtree > > --- > > Kazuhiko Kiriyama Regards --- Kazuhiko Kiriyama From nobody Wed Jan 26 00:58:20 2022 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 A12BC197C9F7 for ; Wed, 26 Jan 2022 00:58:27 +0000 (UTC) (envelope-from philip@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 4Jk51t6MvXz3rnt; Wed, 26 Jan 2022 00:58:26 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643158707; 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: in-reply-to:in-reply-to:references:references; bh=84NFPz0YC+S/npqdY2ojbY6MlPsDyQ4K6HEzqfzSAGc=; b=kQlDKPRpWlrMk+/VIfghUa1IXv9Pgs1SJVJ3/4XXuV8cGIacEMPxgt2+zaKYlRtP124dWF xmrSKc1Bbi3tdyPbQD4wBxGWOr968K2V4n38qqGcVGRmUxvHGM1XvnJP6eO+/+EVilF/l3 GTj4yRry4Dk+BlhIqPA9dMwNn6ZqN2u/27ekIbpsrkNfrjBuCXhEApQ002FjeZ6OYuMunN qOwNCZ4lv7ozRYtlG2qzZV0b1fRbwVtmareePDLbT6vjNHl5kHYuaAdIIcygxW09FODCSA zV/Oxl9CXzcsp5x0Ni0ouMGX3CuAjpAU5acwiH9fDQu7p7KrNp6QyrpVOVi1Yw== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id AFD7D20455; Wed, 26 Jan 2022 00:58:26 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 5F8FB27C0054; Tue, 25 Jan 2022 19:58:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 25 Jan 2022 19:58:26 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfedtgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkjghfgggtsegrtdhmre ertdejnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcuoehphhhilhhiphesfhhrvggv sghsugdrohhrgheqnecuggftrfgrthhtvghrnhepkedtgeehteekffdvleduhfelgffhhf eftdegudefhedugfeufeetkeegvdfhuedunecuffhomhgrihhnpehiphhviehprhhogiih rdhnvghtpdhfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghsmhhtphgruhhthhhpvghrshho nhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektddtkedqphhhihhlihhppeepfh hrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Jan 2022 19:58:24 -0500 (EST) From: Philip Paeps To: Ronald Klop Cc: clusteradm@freebsd.org, freebsd-arm@freebsd.org Subject: Re: aarch64 build cluster and linux64.ko Date: Wed, 26 Jan 2022 08:58:20 +0800 X-Mailer: MailMate (1.14r5861) Message-ID: <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> In-Reply-To: <1365005114.369.1643120837534@localhost> References: <1365005114.369.1643120837534@localhost> 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="=_MailMate_32EF6FF4-61DA-438D-955A-D0A3CA5B77C7_=" Embedded-HTML: [{"plain":[52,1007],"uuid":"08FC23F0-BE00-4AA6-ABF2-D5499927AA06"}] ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643158707; 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: in-reply-to:in-reply-to:references:references; bh=84NFPz0YC+S/npqdY2ojbY6MlPsDyQ4K6HEzqfzSAGc=; b=OD58v/KQoe4w4QVzW64+Sn+GfhKB8rQo5/N8Op3wUZ1hXpryWVwrjx2TKZv3ZVbXiTrVRX LZasd9z3IyiZBeMpfIYE05al1tz7uejYxbxD/5Nip5WyNQERmROKJC1PlcssG8nrE60R1E N2aZAkgeusEsbONnGSQBHTaZg4Y5huGk32PHxBLiwW0qf9fS8nbRZy9rVZHD3808u1eQcK d1XNxfD6kDxL18yYF5uRRQIXE/86FV34m5+Pff1s60xdDH8I9zxXIKgTtwxMB/fLlLPPdS Z1fe4LzYCNQHPdoAOChsMHOPwylubCipxVz72qBMIP8JUp839083de7wxTQiTQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643158707; a=rsa-sha256; cv=none; b=g+j8ZrUVJGQfN4T7KuDolDScItBBAxCrtj4iVMLu1SMCdeXlW/o9Inq5VhqH6pF4io8T8X 5XdVP7gB4xw8bPt50Cu5O3o0TyZ2mHdrxiOvdcC/fhZzX8GwBhEEmYb7niZHr1rf47dwDw GWBr5RwiiaIQMXt1fDYVntMo2vPVhaNSqs4RcatH/oG0NUv1U5ya3pu165SAbvdIgjETh7 X7N1ijl9KaLsViFwagbvzxiN1UvoTzDos9ij2gJgYatvUYFxVWYgBKgk9gWYT03qcolJpl 6++y0YalDgxLtVaKmanNJW736zTGGodtebv86V+pArmae2gmzceaeqYbuBDZzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4443 Lines: 138 --=_MailMate_32EF6FF4-61DA-438D-955A-D0A3CA5B77C7_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: > Hi, > > Currently the packages depending on linux_base-c7 can not be pre-build = > on the package cluster because the kernel does not have linux64.ko = > loaded. > > See: = > http://www.ipv6proxy.net/go.php?u=3Dhttp%3A%2F%2Fampere2.nyi.freebsd.or= g%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors= %2Flinux-c7-libpng-1.5.13_3.log&b=3D0&f=3Dnorefer > =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> linux-c7-libpng-1.5.13_3 depends on package: = > linux_base-c7>=3D7.6.1810_7 - not found > =3D=3D=3D> Installing existing package = > /packages/All/linux_base-c7-7.9.2009.pkg > [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... > Cannot install package: kernel missing 64-bit Linux support > pkg-static: PRE-INSTALL script failed > > > Is it possible to have linux64.ko loaded on the pkg builders so the = > aarch64 packages will be more complete? > > At least on my rpi4/aarch64 poudriere I could build pkg = > linux-c7-libpng with linux64.ko loaded. > > Regards, > Ronald. We can include linux64.ko in the next cluster build for aarch64. I'll = try to find time for another cluster refresh. It's been a while since = the last one. Philip -- = Philip Paeps Senior Reality Engineer Alternative Enterprises --=_MailMate_32EF6FF4-61DA-438D-955A-D0A3CA5B77C7_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 2022-01-25 22:27:17 (+080= 0), Ronald Klop wrote:

Hi,

Currently the packages depending on linux_base-c7 can not be pre-build on= the package cluster because the kernel does not have linux64.ko loaded.<= br>
See: = http://www.ipv6proxy.net/go.php?u=3Dhttp%3A%2F%2Fampere2.nyi.freebsd.org%= 2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2= Flinux-c7-libpng-1.5.13_3.log&b=3D0&f=3Dnorefer 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
phase: run-depends    >=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>   linux-c7-libpng-1.5.13_3 depends on package: linux_base-c=
7>=3D7.6.1810_7 - not found
=3D=3D=3D>   Installing existing package /packages/All/linux_base-c7-7=
=2E9.2009.pkg
[main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...
Cannot install package: kernel missing 64-bit Linux support
pkg-static: PRE-INSTALL script failed
Is it possible to have linux64.ko loaded on the pkg builders so the aarch= 64 packages will be more complete?

At least on my rpi4/aarch64 poudriere I could build pkg linux-c7-libpng w= ith linux64.ko loaded.

Regards,
Ronald.
 


We can include linux64.ko in the next cluster build for aarch64. I'll tr= y to find time for another cluster refresh. It's been a while since the = last one.

Philip

-- =
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

--=_MailMate_32EF6FF4-61DA-438D-955A-D0A3CA5B77C7_=-- From nobody Wed Jan 26 10:54:53 2022 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 9C71C196E249 for ; Wed, 26 Jan 2022 10:55:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.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 4JkLGh1vwrz3HPP; Wed, 26 Jan 2022 10:55:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1643194514; 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=VFo1of2RLqFkXArVjsTbbl9GIEg5ODko6HQkgXBi4hk=; b=eSWMb4P3sr23jd8ZV7VXIOa0CqwZPJl5zIn8hpSJhbxU83IE0Z0V9i16hXzCbb82v53eqx 7ZND+ooIyTQa2ZkHRY4qZCsmBAuthH53R1S4p54fmybtLS4pAU8p7ZepgUaC5oXRCtblu2 G+L4w9CeSBzDVRZGSPXjw+a/kcCtTv4= Received: from skull.home.blih.net (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6572a2bf (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 26 Jan 2022 10:55:14 +0000 (UTC) Date: Wed, 26 Jan 2022 11:54:53 +0100 From: Emmanuel Vadot To: Jesper Schmitz Mouridsen Cc: freebsd-arm@freebsd.org, Warner Losh Subject: Re: pinebook pro video console not active Message-Id: <20220126115453.255661b2e55f946d11eba1e9@bidouilliste.com> In-Reply-To: <4d738da2-28f0-6af2-4213-934244cc95f2@FreeBSD.org> References: <4d738da2-28f0-6af2-4213-934244cc95f2@FreeBSD.org> 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: 4JkLGh1vwrz3HPP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=eSWMb4P3; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 748 Lines: 27 On Wed, 26 Jan 2022 00:44:33 +0100 Jesper Schmitz Mouridsen wrote: > Hi > > On Pinebook Pro 14-current with console="efi,comconsole" in > /boot/loader.conf > vidcontrol -i active < /dev/console is not working because serial stays > primary. Reverting 123b5b8763778e83b6816ad9db62a9b956055c32 fixes that > for me. Can someone share some light on why that is? You also need boot_multicons=YES in loader.conf for this to work (at least on amd64). Maybe imp@ knows more about this behavior. > console kit relies on /dev/console beeing active so it is an annoying > bug.. > the original review is here https://reviews.freebsd.org/D32992 > > > Thanks > /jsm > -- Emmanuel Vadot From nobody Wed Jan 26 11:35:26 2022 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 1CE401987E30 for ; Wed, 26 Jan 2022 11:35:46 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JkM9G0KLLz3nHY; Wed, 26 Jan 2022 11:35:46 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643196946; 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=vgbXqi9HHAknV1vZEumPaEjzlrx2mEx/3a45RgYcw9M=; b=ECtcbWKMcqThA34g1avkqb/rKKZiUBs97LNzCjK7DlxHaVtlAJZaNr2BgvSKmcQobDZN/5 DK4IcEoQU7Oi5XR0siTdP5F3pTDRtrtqvqSz/+rzq14kqA7eDv5GZMGp1mlyyQaER6Wib0 tjlhskyd57jarkpRuYeXIXzrf1KsuT7EyciZ/0WeSMNNX/z5WaLrDh1kIyWGZjVlyiNJ08 L67/m0DfRrYTWGYWVj8UmrN5FOtIGhSqhLFUb9FyLsekjIS4lBLN0N4CrDfc+Dp7iTHjq2 F6OqIgz/021fKaqdrR4chxnCa/kwDUjyFL11SVFX3Fqb+Eq9vhMuOeevCLv6DA== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 6E5D1258B7; Wed, 26 Jan 2022 11:35:45 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <66042fd4-31fa-408a-3ec8-b911118750ef@FreeBSD.org> Date: Wed, 26 Jan 2022 12:35:26 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: pinebook pro video console not active Content-Language: en-US To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org, Warner Losh References: <4d738da2-28f0-6af2-4213-934244cc95f2@FreeBSD.org> <20220126115453.255661b2e55f946d11eba1e9@bidouilliste.com> From: Jesper Schmitz Mouridsen In-Reply-To: <20220126115453.255661b2e55f946d11eba1e9@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643196946; 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=vgbXqi9HHAknV1vZEumPaEjzlrx2mEx/3a45RgYcw9M=; b=NFyb0LSr83e/Tb7r6kSN6mPnljSjfFeDA+J0cOKq9/BUxdOdZ9MkV0sUoYCf36Wdw/G5tA +uE9r4sqRzZcQumHBE0s2Wy+oIxVa1mQMvzGrk6NnDKZsZZC4VQtF94rCfba0Y2QY9Od+t NSXc0P7lS0ffebV1F5iLzfRvZwPkx6HgE+PixVRG6r+D63MqWNz0hiKCFVIT9A1rXVn40h lM7uVgigiHY7sQpBIjP/Y+sTEhh5XMp2LL7EVDyQB3Lb90EsAPdrOwaLP0ngfRGkPkxigQ 9G5AhovbtSFhhb2boZ2E7DBEqL8fbqmy0TDQeqYn+vfWso2n94++v9emZPpwvw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643196946; a=rsa-sha256; cv=none; b=uEStxZfu6BXtEjVvAPckn7XQAdQjE4Ea4ttLHMYZLggKOLF8PevAC/dTGKbXO0F4IPvR12 xnHQGd4k0WJ4RWCWWXRbVsbFfRL50A/h8L1I7W9O5JVfVfd00KUujD0f84NeR6mPrPZmXF S7fV5SLMb999/3J0ChqCZlCLxkgwolArxOy8Gr1cCB6Ks/rvqzQy97LD5cjSwShVqQ4AkY Gz5abACKfhpu37J7Gnn3PcwOPSjL6pEFVkh0icyJ0j4rjSmMaBEjMyVRFGAreWDfsgdi5T IVJhRhYeoDB04B6dbKt2OAuMJ54ylhaMjPbFZ0KQnT3IUwPgdJfSrwrJmuww8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 934 Lines: 35 Hi On 26.01.2022 11.54, Emmanuel Vadot wrote: > On Wed, 26 Jan 2022 00:44:33 +0100 > Jesper Schmitz Mouridsen wrote: > >> Hi >> >> On Pinebook Pro 14-current with console="efi,comconsole" in >> /boot/loader.conf >> vidcontrol -i active < /dev/console is not working because serial stays >> primary. Reverting 123b5b8763778e83b6816ad9db62a9b956055c32 fixes that >> for me. Can someone share some light on why that is? > You also need boot_multicons=YES in loader.conf for this to work (at > least on amd64). > Maybe imp@ knows more about this behavior. > Yes I have that set as well, my loader.conf is hw.regulator.disable_unused="0" boot_multicons="YES" console="efi,comconsole" beastie_disable="NO" loader_color="YES" ums_load=YES >> console kit relies on /dev/console beeing active so it is an annoying >> bug.. >> the original review is here https://reviews.freebsd.org/D32992 >> >> >> Thanks >> /jsm >> > From nobody Thu Jan 27 09:03:05 2022 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 6DAE91978780; Thu, 27 Jan 2022 09:03:12 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jkvkk59B2z4pYF; Thu, 27 Jan 2022 09:03:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:Subject:From:To:MIME-Version :Date:Message-ID:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tF+t5PtVWsNxDd0zjWAi6qXEIcKRGFz47xQQ3L5ek1M=; b=t+iSbMtvt5cdbTON6b5yqrIMU+ PYnJqVO2tZF0Xpaa92zRNNBdZyVx2kNRqpU8WOcuChbsa/io8Q71lrZGFfaHphAQ3+e9VVClxoTO9 Xe8npYqH3BIO33HItaSLUsws/yUFXvBKz8uBGZIc6jY9E5GHrfVRJoba16bDLccTTrbk=; Message-ID: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> Date: Thu, 27 Jan 2022 10:03:05 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: freebsd-arm@freebsd.org, freebsd-java@freebsd.org From: Ronald Klop Subject: openjdk8 crash on aarch64; guarantee(val < (1U << nbits)) failed: Field too big for insn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: - X-Spam-Score: -1.2 X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=disabled version=3.4.2 X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 X-Rspamd-Queue-Id: 4Jkvkk59B2z4pYF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=t+iSbMtv; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.190.28.88:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1323 Lines: 32 Hi, A lot of java ports are failing in the build cluster since about a week (or two) on arm64. Example output: http://ampere2.nyi.freebsd.org/data/main-arm64-default/pd8f8cc3a8823_s4f0e50b293/logs/errors/jacop-4.8.0.log (ipv6) =================================================== ===> Building for jacop-4.8.0 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=89536, tid=0x00000000000a9630 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_312-b07) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.312-b07 mixed mode bsd-aarch64 compressed oops) # Core dump written. Default location: /wrkdirs/usr/ports/math/jacop/work/jacop-4.8.0/java.core # # An error report file with more information is saved as: # /wrkdirs/usr/ports/math/jacop/work/jacop-4.8.0/hs_err_pid89536.log # # If you would like to submit a bug report, please visit: # https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Ports%20%26%20Packages&component=Individual%20Port(s)&short_desc=java/openjdk8%3A%20 # *** Signal 6 I can reproduce this on my rpi4 and it is "fixed" if I compile openjdk8 using llvm12 from ports instead of llvm13 from base. Is anybody looking into this? Should I file a PR? Regards, Ronald. From nobody Thu Jan 27 09:22:54 2022 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 835011987A54 for ; Thu, 27 Jan 2022 09:23:03 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jkw9f48mDz3GmM for ; Thu, 27 Jan 2022 09:23:02 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 89C1E1654; Thu, 27 Jan 2022 09:22:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 89C1E1654 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1643275375; bh=n7G0SrujQbVfAFzMXsYguVdtWtYnOJd0EJp3F4bJ4R0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=W1eM5OFaWHZ0LMXHWdw9Bh6wlv0abmWrUutouo+aDsNapd9mPsA3vr6XLnMVAyMLT dbMkkG4zz4uf4BdgmtsoLiK+QaOBF/28jzP4cqMFppnL6g4LYcR5+AoPWqOBZZVxvq /j3p54zc9RjKOh0YkcJ6fDV8DfYiL/G0SgrkYR3Y= Message-ID: <4f158e4c-5128-7095-a71d-81375807c42f@littlepinkcloud.com> Date: Thu, 27 Jan 2022 09:22:54 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: openjdk8 crash on aarch64; guarantee(val < (1U << nbits)) failed: Field too big for insn Content-Language: en-US To: freebsd-arm@freebsd.org References: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> From: Andrew Haley In-Reply-To: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jkw9f48mDz3GmM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b=W1eM5OFa; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [1.16 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; NEURAL_SPAM_MEDIUM(0.90)[0.901]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.24)[-0.238]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 489 Lines: 14 On 1/27/22 09:03, Ronald Klop wrote: > I can reproduce this on my rpi4 and it is "fixed" if I compile openjdk8 using llvm12 from ports instead of llvm13 from base. > Is anybody looking into this? Should I file a PR? I can't reach ampere2.nyi.freebsd.org Please send me the hs_err_pidXXX.log; or post it here. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Thu Jan 27 09:37:15 2022 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 2685C19684C9 for ; Thu, 27 Jan 2022 09:37:15 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkwV211bSz3NM1 for ; Thu, 27 Jan 2022 09:37:14 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XliL6RjmVXuMloUgPf0oYXFA5lA1RjcS91KDfT5wowE=; b=k/Ibwnm7p76fGhZ/K/a3CmElaP WyiFa8MK4c9p7M0OPzzvoMOMebA7Tb/LQTlCW9HCXdicoA2ZfWkQB2ZNcn++w98eVJjFlmuVJvKMs w/ooz+tzppH+OSNl1utiT9ihV7xpl1yh8jWSJ6RYDTMm6ZoTyLPS8tCA/dylJJ2K4U6E=; Message-ID: <5b3a3186-e946-91cf-560e-14c6d590d1d9@klop.ws> Date: Thu, 27 Jan 2022 10:37:15 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: openjdk8 crash on aarch64; guarantee(val < (1U << nbits)) failed: Field too big for insn Content-Language: en-US To: freebsd-arm@freebsd.org References: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> <4f158e4c-5128-7095-a71d-81375807c42f@littlepinkcloud.com> From: Ronald Klop In-Reply-To: <4f158e4c-5128-7095-a71d-81375807c42f@littlepinkcloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: / X-Spam-Score: -0.4 X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2 X-Scan-Signature: 964c6a2bc69af72888bec91466701c23 X-Rspamd-Queue-Id: 4JkwV211bSz3NM1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b="k/Ibwnm7"; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.190.28.88:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 712 Lines: 20 On 1/27/22 10:22, Andrew Haley wrote: > On 1/27/22 09:03, Ronald Klop wrote: >> I can reproduce this on my rpi4 and it is "fixed" if I compile openjdk8 using llvm12 from ports instead of llvm13 from base. >> Is anybody looking into this? Should I file a PR? > > I can't reach ampere2.nyi.freebsd.org > > Please send me the hs_err_pidXXX.log; or post it here. > Hi, this makes the log available on ipv4. http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Fjacop-4.8.0.log&b=0&f=norefer I can't get the hs_err_pidXXX.log from that server either. I will try to reproduce the error locally today. Regards, Ronald. From nobody Thu Jan 27 10:10:36 2022 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 3113019804AE; Thu, 27 Jan 2022 10:10:41 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkxDc2QJ7z3tpp; Thu, 27 Jan 2022 10:10:40 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID :Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wtC2wmmEb0zXc/kHUFhvBHKFWGcSbSannSjyOEkYJi0=; b=PPiW4HP8kg0q3YWeLvD94v5cA8 jjPXAS4YZXt4nR00ts0cepAy2v5t1nqEAcb42QIPGFBl+EDM9GdTEYXzGAnMRocUoqRCKebkGWADV dku8CPAcQHD0bLltYsA+m/uVzquAQ7Y2VTssRnE6KY/tu+Z56opivZ7khjjUlzTZXKSU=; Content-Type: multipart/mixed; boundary="------------yw3LJFPqFGvsiE8yMFH6tpoC" Message-ID: <4cba6e57-04be-5a4a-7d74-4c3f6d84adc8@klop.ws> Date: Thu, 27 Jan 2022 11:10:36 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: openjdk8 crash on aarch64; guarantee(val < (1U << nbits)) failed: Field too big for insn Content-Language: en-US To: freebsd-arm@freebsd.org, freebsd-java@freebsd.org References: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> <4f158e4c-5128-7095-a71d-81375807c42f@littlepinkcloud.com> <5b3a3186-e946-91cf-560e-14c6d590d1d9@klop.ws> From: Ronald Klop In-Reply-To: <5b3a3186-e946-91cf-560e-14c6d590d1d9@klop.ws> X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: - X-Spam-Score: -1.2 X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2 X-Scan-Signature: d825756976bdd03eeab7bf7cffb9f8e1 X-Rspamd-Queue-Id: 4JkxDc2QJ7z3tpp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=PPiW4HP8; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.90 / 15.00]; ARC_NA(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.190.28.88:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7593 Lines: 127 This is a multi-part message in MIME format. --------------yw3LJFPqFGvsiE8yMFH6tpoC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/22 10:37, Ronald Klop wrote: > On 1/27/22 10:22, Andrew Haley wrote: >> On 1/27/22 09:03, Ronald Klop wrote: >>> I can reproduce this on my rpi4 and it is "fixed" if I compile openjdk8 using llvm12 from ports instead of llvm13 from base. >>> Is anybody looking into this? Should I file a PR? >> >> I can't reach ampere2.nyi.freebsd.org >> >> Please send me the hs_err_pidXXX.log; or post it here. >> > > > Hi, this makes the log available on ipv4. > > http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Fjacop-4.8.0.log&b=0&f=norefer > > I can't get the hs_err_pidXXX.log from that server either. I will try to reproduce the error locally today. > > Regards, > Ronald. > > It was easier to reproduce than I thought. Just java -version on my rpi4/14-CURRENT. Let's see if the attachment comes through in the ML. Regards, Ronald. --------------yw3LJFPqFGvsiE8yMFH6tpoC Content-Type: text/plain; charset=UTF-8; name="hs_err_pid54456.log" Content-Disposition: attachment; filename="hs_err_pid54456.log" Content-Transfer-Encoding: base64 IwojIEEgZmF0YWwgZXJyb3IgaGFzIGJlZW4gZGV0ZWN0ZWQgYnkgdGhlIEphdmEgUnVudGlt ZSBFbnZpcm9ubWVudDoKIwojICBJbnRlcm5hbCBFcnJvciAoYXNzZW1ibGVyX2FhcmNoNjQu aHBwOjIzNyksIHBpZD01NDQ1NiwgdGlkPTB4MDAwMDAwMDAwMDA0ODY5ZQojICBndWFyYW50 ZWUodmFsIDwgKDFVIDw8IG5iaXRzKSkgZmFpbGVkOiBGaWVsZCB0b28gYmlnIGZvciBpbnNu CiMKIyBKUkUgdmVyc2lvbjogICg4LjBfMzEyLWIwNykgKGJ1aWxkICkKIyBKYXZhIFZNOiBP cGVuSkRLIDY0LUJpdCBTZXJ2ZXIgVk0gKDI1LjMxMi1iMDcgbWl4ZWQgbW9kZSBic2QtYWFy Y2g2NCBjb21wcmVzc2VkIG9vcHMpCiMgQ29yZSBkdW1wIHdyaXR0ZW4uIERlZmF1bHQgbG9j YXRpb246IC8vamF2YS5jb3JlCiMKIyBJZiB5b3Ugd291bGQgbGlrZSB0byBzdWJtaXQgYSBi dWcgcmVwb3J0LCBwbGVhc2UgdmlzaXQ6CiMgICBodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcv YnVnemlsbGEvZW50ZXJfYnVnLmNnaT9wcm9kdWN0PVBvcnRzJTIwJTI2JTIwUGFja2FnZXMm Y29tcG9uZW50PUluZGl2aWR1YWwlMjBQb3J0KHMpJnNob3J0X2Rlc2M9amF2YS9vcGVuamRr OCUzQSUyMAojCgotLS0tLS0tLS0tLS0tLS0gIFQgSCBSIEUgQSBEICAtLS0tLS0tLS0tLS0t LS0KCkN1cnJlbnQgdGhyZWFkICgweDAwMDA0NWIwMDYzOWIwMDApOiAgSmF2YVRocmVhZCAi VW5rbm93biB0aHJlYWQiIFtfdGhyZWFkX2luX3ZtLCBpZD0yOTY2MDYsIHN0YWNrKDB4MDAw MDAwMDAwMDAwMzAwMCwweDAwMDAwMDAwMDAyMDMwMDApXQoKU3RhY2s6IFsweDAwMDAwMDAw MDAwMDMwMDAsMHgwMDAwMDAwMDAwMjAzMDAwXSwgIHNwPTB4MDAwMDAwMDAwMDIwMjBiMCwg IGZyZWUgc3BhY2U9MjA0NGsKTmF0aXZlIGZyYW1lczogKEo9Y29tcGlsZWQgSmF2YSBjb2Rl LCBqPWludGVycHJldGVkLCBWdj1WTSBjb2RlLCBDPW5hdGl2ZSBjb2RlKQpWICBbbGlianZt LnNvKzB4YWM1NjAwXSAgSlZNX2hhbmRsZV9ic2Rfc2lnbmFsKzB4MTY5YTgwClYgIFtsaWJq dm0uc28rMHg1ODExYTRdCltlcnJvciBvY2N1cnJlZCBkdXJpbmcgZXJyb3IgcmVwb3J0aW5n IChwcmludGluZyBuYXRpdmUgc3RhY2spLCBpZCAweGUwMDAwMDAwXQoKCi0tLS0tLS0tLS0t LS0tLSAgUCBSIE8gQyBFIFMgUyAgLS0tLS0tLS0tLS0tLS0tCgpKYXZhIFRocmVhZHM6ICgg PT4gY3VycmVudCB0aHJlYWQgKQoKT3RoZXIgVGhyZWFkczoKCj0+MHgwMDAwNDViMDA2Mzli MDAwIChleGl0ZWQpIEphdmFUaHJlYWQgIlVua25vd24gdGhyZWFkIiBbX3RocmVhZF9pbl92 bSwgaWQ9Mjk2NjA2LCBzdGFjaygweDAwMDAwMDAwMDAwMDMwMDAsMHgwMDAwMDAwMDAwMjAz MDAwKV0KClZNIHN0YXRlOm5vdCBhdCBzYWZlcG9pbnQgKG5vdCBmdWxseSBpbml0aWFsaXpl ZCkKClZNIE11dGV4L01vbml0b3IgY3VycmVudGx5IG93bmVkIGJ5IGEgdGhyZWFkOiBOb25l CgoKW2Vycm9yIG9jY3VycmVkIGR1cmluZyBlcnJvciByZXBvcnRpbmcgKHByaW50aW5nIGNv bXByZXNzZWQgb29wcyBtb2RlLCBpZCAweGJdCgpEZW9wdGltaXphdGlvbiBldmVudHMgKDAg ZXZlbnRzKToKTm8gZXZlbnRzCgpDbGFzc2VzIHJlZGVmaW5lZCAoMCBldmVudHMpOgpObyBl dmVudHMKCkludGVybmFsIGV4Y2VwdGlvbnMgKDAgZXZlbnRzKToKTm8gZXZlbnRzCgpFdmVu dHMgKDAgZXZlbnRzKToKTm8gZXZlbnRzCgoKRHluYW1pYyBsaWJyYXJpZXM6CjB4MDAwMDQ1 YWZiYTM2MDAwMCAJL3Vzci9sb2NhbC9vcGVuamRrOC9iaW4vamF2YQoweDAwMDA0NWFmZmE5 ZjcwMDAgCS91c3IvbG9jYWwvb3BlbmpkazgvYmluLy4uL2xpYi9hYXJjaDY0L2psaS9saWJq bGkuc28KMHgwMDAwNDVhZmZhYTUzMDAwIAkvbGliL2xpYnouc28uNgoweDAwMDA0NWFmZmJj ZWMwMDAgCS9saWIvbGlidGhyLnNvLjMKMHgwMDAwNDVhZmZjN2YzMDAwIAkvbGliL2xpYmMu c28uNwoweDAwMDA0NWIwMDFlMDAwMDAgCS91c3IvbG9jYWwvb3BlbmpkazgvanJlL2xpYi9h YXJjaDY0L3NlcnZlci9saWJqdm0uc28KMHgwMDAwNDVhZmZmYWU2MDAwIAkvbGliL2xpYm0u c28uNQoweDAwMDA0NWIwMDBhNWMwMDAgCS9saWIvbGliYysrLnNvLjEKMHgwMDAwNDViMDAx ODZkMDAwIAkvbGliL2xpYmN4eHJ0LnNvLjEKMHgwMDAwNDViMDA0MTBlMDAwIAkvbGliL2xp YmdjY19zLnNvLjEKMHgwMDAwNDViMDA3ZjFjMDAwIAkvdXNyL2xvY2FsL29wZW5qZGs4L2py ZS9saWIvYWFyY2g2NC9saWJ2ZXJpZnkuc28KMHgwMDAwNDViMDA5MTBmMDAwIAkvdXNyL2xv Y2FsL29wZW5qZGs4L2pyZS9saWIvYWFyY2g2NC9saWJqYXZhLnNvCjB4MDAwMDQ1YjAwOTRm ZjAwMCAJL3Vzci9sb2NhbC9vcGVuamRrOC9qcmUvbGliL2FhcmNoNjQvbGliemlwLnNvCjB4 MDAwMDU3NDA2ZmYzOTAwMCAJL2xpYmV4ZWMvbGQtZWxmLnNvLjEKClZNIEFyZ3VtZW50czoK amF2YV9jb21tYW5kOiA8dW5rbm93bj4KamF2YV9jbGFzc19wYXRoIChpbml0aWFsKTogLgpM YXVuY2hlciBUeXBlOiBTVU5fU1RBTkRBUkQKCkVudmlyb25tZW50IFZhcmlhYmxlczoKSkFW QV9IT01FPS91c3IvbG9jYWwvb3BlbmpkazgKUEFUSD0vc2JpbjovYmluOi91c3Ivc2Jpbjov dXNyL2JpbjovdXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW46L3Jvb3QvYmluClNIRUxM PS91c3IvbG9jYWwvYmluL2Jhc2gKClNpZ25hbCBIYW5kbGVyczoKU0lHU0VHVjogW2xpYmp2 bS5zbysweGFjNjJiNF0sIHNhX21hc2tbMF09MTExMTExMTExMTExMTExMTExMTExMTExMTEx MTExMTAsIHNhX2ZsYWdzPVNBX1JFU1RBUlR8U0FfU0lHSU5GTwpTSUdCVVM6IFtsaWJqdm0u c28rMHhhYzYyYjRdLCBzYV9tYXNrWzBdPTExMTExMTExMTExMTExMTExMTExMTExMTExMTEx MTEwLCBzYV9mbGFncz1TQV9SRVNUQVJUfFNBX1NJR0lORk8KU0lHRlBFOiBbbGlianZtLnNv KzB4OTU4N2Y0XSwgc2FfbWFza1swXT0xMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEx MCwgc2FfZmxhZ3M9U0FfUkVTVEFSVHxTQV9TSUdJTkZPClNJR1BJUEU6IFtsaWJqdm0uc28r MHg5NTg3ZjRdLCBzYV9tYXNrWzBdPTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEw LCBzYV9mbGFncz1TQV9SRVNUQVJUfFNBX1NJR0lORk8KU0lHWEZTWjogW2xpYmp2bS5zbysw eDk1ODdmNF0sIHNhX21hc2tbMF09MTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTAs IHNhX2ZsYWdzPVNBX1JFU1RBUlR8U0FfU0lHSU5GTwpTSUdJTEw6IFtsaWJqdm0uc28rMHg5 NTg3ZjRdLCBzYV9tYXNrWzBdPTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEwLCBz YV9mbGFncz1TQV9SRVNUQVJUfFNBX1NJR0lORk8KU0lHVVNSMTogU0lHX0RGTCwgc2FfbWFz a1swXT0wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMCwgc2FfZmxhZ3M9bm9uZQpT SUdVU1IyOiBbbGlianZtLnNvKzB4OTU5MmY0XSwgc2FfbWFza1swXT0wMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMCwgc2FfZmxhZ3M9U0FfUkVTVEFSVHxTQV9TSUdJTkZPClNJ R0hVUDogU0lHX0RGTCwgc2FfbWFza1swXT0wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMCwgc2FfZmxhZ3M9U0FfUkVTVEFSVApTSUdJTlQ6IFNJR19ERkwsIHNhX21hc2tbMF09 MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAsIHNhX2ZsYWdzPW5vbmUKU0lHVEVS TTogU0lHX0RGTCwgc2FfbWFza1swXT0wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MCwgc2FfZmxhZ3M9bm9uZQpTSUdRVUlUOiBTSUdfREZMLCBzYV9tYXNrWzBdPTAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLCBzYV9mbGFncz1ub25lCgoKLS0tLS0tLS0tLS0t LS0tICBTIFkgUyBUIEUgTSAgLS0tLS0tLS0tLS0tLS0tCgpPUzpCU0QKdW5hbWU6RnJlZUJT RCAxNC4wLUNVUlJFTlQgRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzE5IG1haW4tYzcyZTkxNGNm MTogV2VkIEphbiAxMiAwMzozNDowNCBDRVQgMjAyMiAgICAgcm9uYWxkQHJwaTQ6L2hvbWUv cm9uYWxkL2Rldi9vYmovaG9tZS9yb25hbGQvZGV2L2ZyZWVic2QvYXJtNjQuYWFyY2g2NC9z eXMvR0VORVJJQy1OT0RFQlVHIGFybTY0CnJsaW1pdDogU1RBQ0sgMTA0ODU3NmssIENPUkUg aW5maW5pdHksIE5QUk9DIDEyMDcwLCBOT0ZJTEUgMjMxMTI5LCBBUyBpbmZpbml0eQpsb2Fk IGF2ZXJhZ2U6MC4xNSAwLjIwIDAuMTgKCkNQVTp0b3RhbCA0IChpbml0aWFsIGFjdGl2ZSA0 KSAKCk1lbW9yeTogNGsgcGFnZSwgcGh5c2ljYWwgODIxODA4OGsoMTA0OTE0MGsgZnJlZSks IHN3YXAgMGsoNDI5NDg1OTQ2MGsgZnJlZSkKCnZtX2luZm86IE9wZW5KREsgNjQtQml0IFNl cnZlciBWTSAoMjUuMzEyLWIwNykgZm9yIGJzZC1hYXJjaDY0IEpSRSAoMS44LjBfMzEyLWIw NyksIGJ1aWx0IG9uIEphbiAgMSAyMDIyIDA5OjQ3OjM4IGJ5ICJyb290IiB3aXRoIGdjYyBG cmVlQlNEIENsYW5nIDEzLjAuMCAoZ2l0QGdpdGh1Yi5jb206bGx2bS9sbHZtLXByb2plY3Qu Z2l0IGxsdm1vcmctMTMuMC4wLTAtZ2Q3YjY2OWIzYTMwMykKCnRpbWU6IFRodSBKYW4gMjcg MTE6MDc6MjMgMjAyMgp0aW1lem9uZTogQ0VUCmVsYXBzZWQgdGltZTogMC4xMjgxMTQgc2Vj b25kcyAoMGQgMGggMG0gMHMpCgo= --------------yw3LJFPqFGvsiE8yMFH6tpoC-- From nobody Thu Jan 27 10:23:22 2022 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 EB7EE198630C for ; Thu, 27 Jan 2022 10:23:25 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from mail.littlepinkcloud.com (bookofsand.co.uk [93.93.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkxWJ724Rz4Tg8 for ; Thu, 27 Jan 2022 10:23:24 +0000 (UTC) (envelope-from aph-open@littlepinkcloud.com) Received: from [10.0.0.8] (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net [80.0.22.220]) by mail.bookofsand.co.uk (Postfix) with ESMTPSA id 8B1051302; Thu, 27 Jan 2022 10:23:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.bookofsand.co.uk 8B1051302 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=littlepinkcloud.com; s=default; t=1643279003; bh=26q9JDZDJkhSjfnzzsP/hrJdOo/zlKHzt5mvrhcXXUA=; h=Date:Subject:To:References:From:In-Reply-To:From; b=XIB/wx5DguNS1CkNm+QPf4N+0hiGzZ9oZS2Ti/KiBF6sZVa4R4DT/AoS4uo9lsa6R z6Wp9UDqjGeoc3oQq6gVc9Gp3QqwoipOjOQCY6PI4ply6RZL9/uQaimWHNbRRnt5Gb po70lXuZGjbvpIivm6fSxj8g1ArbKRI2FW4K8Yus= Message-ID: <2bbcbb00-e1be-f11c-ad11-d41b5eb59708@littlepinkcloud.com> Date: Thu, 27 Jan 2022 10:23:22 +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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: openjdk8 crash on aarch64; guarantee(val < (1U << nbits)) failed: Field too big for insn Content-Language: en-US To: freebsd-arm@freebsd.org References: <2aff3ce6-b8d6-33f6-e9d2-1cff75158baf@klop.ws> <4f158e4c-5128-7095-a71d-81375807c42f@littlepinkcloud.com> <5b3a3186-e946-91cf-560e-14c6d590d1d9@klop.ws> <4cba6e57-04be-5a4a-7d74-4c3f6d84adc8@klop.ws> From: Andrew Haley In-Reply-To: <4cba6e57-04be-5a4a-7d74-4c3f6d84adc8@klop.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JkxWJ724Rz4Tg8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=littlepinkcloud.com header.s=default header.b="XIB/wx5D"; dmarc=none; spf=pass (mx1.freebsd.org: domain of aph-open@littlepinkcloud.com designates 93.93.131.130 as permitted sender) smtp.mailfrom=aph-open@littlepinkcloud.com X-Spamd-Result: default: False [-0.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[littlepinkcloud.com:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[littlepinkcloud.com]; NEURAL_SPAM_MEDIUM(0.95)[0.949]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[littlepinkcloud.com:+]; NEURAL_SPAM_LONG(0.51)[0.513]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44684, ipnet:93.93.128.0/21, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.0.22.220:received] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 399 Lines: 13 On 1/27/22 10:10, Ronald Klop wrote: > It was easier to reproduce than I thought. Just java -version on my rpi4/14-CURRENT. > > Let's see if the attachment comes through in the ML. Oh, poo! No backtrace. Thanks anyway, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nobody Thu Jan 27 16:45:12 2022 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 8D3CA1985BC4 for ; Thu, 27 Jan 2022 16:45:19 +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 4Jl5zy3PJlz3vg7 for ; Thu, 27 Jan 2022 16:45:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20RGjDod051248 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 27 Jan 2022 08:45:13 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20RGjCK2051247; Thu, 27 Jan 2022 08:45:12 -0800 (PST) (envelope-from fbsd) Date: Thu, 27 Jan 2022 08:45:12 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current Message-ID: <20220127164512.GA51200@www.zefox.net> 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-Rspamd-Queue-Id: 4Jl5zy3PJlz3vg7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.77 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.86)[0.858]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1438 Lines: 33 Attempts to compile devel/llvm13 on a Pi4 running -current (updated on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two occasions using make -DBATCH > make.log & in /usr/ports/devel/llvm13 using the system compiler. The system is self-hosted. The first failure reported clang error 139, but the second was different, reporting only: FAILED: tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expression.cpp.o along with a console report of +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1258432, size: 4096 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 627221, size: 8192 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240419, size: 4096 +swap_pager: out of swap space +swp_pager_getswapspace(12): failed +pid 61012 (c++), jid 0, uid 0, was killed: failed to reclaim memory Swap use peaked a little over 50%. After the first failure a restart of make using MAKE_JOBS_UNSAFE=yes ran to completion with one thread. A copy of the build log, logging script and other notes is at http://www.zefox.net/~fbsd/rpi4/20220127/ Clang error 139 has been seen several times during make buildworld on a Pi3 running stable/13 with 2 GB of swap as well. Perhaps the two failures are related. The Pi3 failures didn't report out of swap, all were clang error 139 with "failed to reclaim memory". Even with only 1 thread (j1) the failure reproduced. Thanks for reading, bob prohaska 20220127 From nobody Thu Jan 27 19:31:17 2022 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 A9D4319821F3 for ; Thu, 27 Jan 2022 19:31:32 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jl9gl46HMz4mQ7 for ; Thu, 27 Jan 2022 19:31:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643311884; bh=yhZgD+NpPfSMfC5l8LvISuGzmSJ5syvtQqrQbGfbyqk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BB8nVxWtKPMTwWMlh43IzVgOtVXGP0ayerJrwPpkYXdro0CLhl8iH3LyGayAV1F2LV6mElet1jmEPTAkXO9tzKkaFSetpGP9QH1vcMaV7p3Moyr10eLpSLPztQqUvz5R1BaHHyVYy9ek0t3JjwJic2Ru5l/EmfcDnm4sBYo8h6rIg7hNttTgjjPn2iwW4Iy5JXhEkb9YmT4AyiwdWwmbN/TAIVpyzyPEzJQ4e+uUuQopWEIadGP+mT8so1SvGihsNWylS5bmyYm3d9uxTJUAfAX4wTNbAzTysRMKN5gt0RKpmMakQZkNJ9vjoc9KDf/KayuJrBKrbDUfjg9Q9X7BgA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643311884; bh=f1fXoKJSTMNny+wMItKAdSKVU6fWe0Rt4KBhpvasN7u=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DNsMFfx6f8Q/0TSr77a2Cq+hllX/9nfuNH1ZuKB4T5KerwqEPEqqHTedjDteXIe5s6lFrhBTYtJQ3nT9tZk5FOUV7Ikc+PFNNv2LLAZ9Jz2wiViSnJlz+FAmJ/TxLBcRf5YmBXyzDSVWjWR+jc75EJVlXzmh5Xfsh3mlQL4lydCaKrn2Ua7QCGl3tugFPY19YMJt/l62/jP7AqysD30rcbPJt5nlyHfh30QfxMj9bkXFu8kYISIZL82qiaiaok1BS4R403sN7qBGyLahQ+43h/GGltePLQ+V/S7UTemWUrtStCiZuD6WE2cV71xeamfDEYGll0Eu/9trRRSh7jgmeg== X-YMail-OSG: o.z_dHMVM1mYO7jUWSS_zAzLnPZRemgQ8M7OB28dVjSA8kq6zdZ2_OK3.LtsSgI RU8g0ynnG8e0pfBklbcU31kzZxkdZ7l_Ea11I5BvGDiMbonXgDy865LBHKsUCHSGRjnTB56.soWA 66HXT2tPhZze5e103fWKyzlZyMJ50.L.hsh7ZkERkKR.2nzAvT.ZBwP2guIOoI7GoCXrDrMu1pHJ fXbyACqnSY115xA8k.de3OhVVRp3RTow4Mlz3jjx6edzxLskndWi.Zy.hPDWqSRdMlstq2J1.Ztp cIukJW4lLR6hAccbSKtMh31gQWh4KIJkxlRjbuohMI6g.Md0XUExdV1aCTlL3HEtXeSQMqZ62jrK XPWIK_r93a0BM_9rXzcqEZSsPpLIxcwlavj3CjiEYWKMJhxhXQTracCnIbl7lEcY.YBo7xi0FJCM PR1K3ct5KHWxJXx1qM6khFAFON1YZ9lRi54GbpHhhdu21ogd41gDfdHG.pwhyJJqGnmybSct8j4o 5a4g7QL5kdT.xJgKoDg.T9sCwIa3FylETAHku4CEkPPrr5bb6Z_s0Jhkys2rq1hlEICqsAqk1P9M 5dcJj0RpceMJlHC2NVF.YWOmk89i1iFjqkYN4et6Ouv0J1eveAU5cQLCwbAf2aiaFESn77QPQgNF bRORcYzXxOCF8c4HKaB_NZP6Dr9bGHx8yj.oHXKjlS3XrYt_IAJ7ED8V8XbhM.aHU7cq2IwzZ6GH HnlhVS5IpcJ4JbuCmELPChbStqXHLFF9QaqGPynDua47KYdK6e8O5ogv_xD3bMFWJe0dLbiMcmCG u9h5d4f0vIVnH7k_9M8twb8CgYJOUZ6RGxYT0s.hG43b3FgMK7ahmTfbDxbT7qFxMCtJb.8lF7Ne jyaDNwJZvypkBn1zQc64Lqs1NqM1Lu0FnYbtgqX1mW5UGSWZkNWFqjuquDuYY8mv_TD9Hm9MxbMC JjEi5KV6Zv5U7byoDU99Oe66JPdyrHOze17.6Lct6CxOcsZ64lFR4h9xJaEA1QAcjqzPRpjvtINw ygsUuQUdp9rjvEyFR.bEZRj1pXfnoFo5yFASBZaIdq0v9OReUyoPcygSyIxGgmhZBkPIYmcqIL5t .Y2Vc3oyDm5ARYUyNjzLR89UTRyjdNs.npvvNIInQ0mig03.Q6pww3voDP6X2bGb_tMb0GZWBV0p v4SiKuUGlrxkMEiSgaJGKrrqaKJkk.hmiypIvsFsNT4ySDkCm10ko0J5IwbPr3xBjlK.tP7wb4Xs OVr29bwGAo8gwEJoEGY3L6WLEyjHR3Ic1cLlklsG15N2oAzn_4Fr9aptIUMjAZyyXbw3jbbxpkxg xF3L60i2sKpMgwZvnt0EuZtdDjXLNzJynhAI_u.29lcvMrAPjlCaobXB9UEHsVhke1obByQm7LQd 6YlZDt5Hb3gATP5nCcZtNbDpPsACe1pAYatCRTo0NlXWhy0.XutZWKOlX7XN5kjgOIjvJB_44I8U sBZcCzAFRUfLCafckteQi.g6dT_HDc87TybNwbmE0TGdwDEZ.zYW.eCm91.6wNZIXFb6GPIj8aB2 RxrqKQmr6ZrPvKzidPb5G5UFhbPOyb5dw59HA7oGcYvpHVnnB0JpHbDSyovMN2H95ReDddaFFwap Fj2dGCDNU49uJHsbXBKtyVOk1YvGrQMLmybjGVFhyqRR7UW0hqvpdeAUEIqLCg9IOjNE09JPR74B lukcNALU9SH7jxrmQ4y8.cF_S4ydzR9StQ3N.0xsPSBF8o6oDMMO7b1NIJyNWIUjImZGpsnRAOnx x7uPMeNaZwaE.PhZiNNqH8krFIBu4.yxIleRTZ1KySE.F.4DEW5lBBH7xn9j3VdfD4LDqMj5zJ8f rVEfRGrg58e4Oe0CpJ4gSOyZBbbXjyFBXehkwbl.N1EGbsHfz__BJbZvKpeB1fs31.gw3XinlzoG c5cf2lpCz36vS79WM7zvZtYbC5qhkL0T4UTnpmYE9mTmdoVe3f8ayZAIp7HkTUVm_fUSt_CQdIuF 8Vc8IWhs4avwaCobOT.RwFLLkSxtEkyjUqHorvgIeS5.YntUlV9qGJ_byKK31286GOAO4go206jJ _IKmID7EBqNrCD0W6BKgugzwc9D54j9DJgjy7K2HKJhsc2V6magCc7XhGOCDTBkdhp85SB0jz5uC rwuwc79vc1HBm_TQwyZxvftEtB08DTO1UMq8IHDxtUXsPmIt5vwfvhGt5wf8HJXB0ZAOSCdJLRvt grswUMCD73ldX1Cx8If5ZhdfadKmp.mk.hVaFDDi9jrtHTH6AL4IYdMC6WKTmEfdvggALTzduCxK z0.KM0dygrDZs28vnUnfYsOE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 19:31:24 +0000 Received: by kubenode520.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6674841593c6832bc88b93800907ec33; Thu, 27 Jan 2022 19:31:18 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: <20220127164512.GA51200@www.zefox.net> Date: Thu, 27 Jan 2022 11:31:17 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> To: bob prohaska , Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jl9gl46HMz4mQ7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BB8nVxWt; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4187 Lines: 113 On 2022-Jan-27, at 08:45, bob prohaska wrote: > Attempts to compile devel/llvm13 on a Pi4 running -current (updated > on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 > make -DBATCH > make.log &=20 > in /usr/ports/devel/llvm13 using the system compiler. The system is > self-hosted.=20 >=20 > The first failure reported clang error 139, but the second > was different, reporting only: > FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expressi= on.cpp.o > along with a console report of > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1258432, size: = 4096 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 627221, size: = 8192 > +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240419, size: = 4096 > +swap_pager: out of swap space In recent builds, such as yours, the above "out of swap" is a misnomer but is very interesting for what it is actually about. Mark Johnston later wrote on 2022-Jan-15 about his "git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill" that produced the above report of "out of swap space": QUOTE Hmm, those cases should likely be changed from "out of swap space" to "failed to allocate swap metadata" or something like that. END QUOTE Your context proves the metadata problem really happens, so the messaging should be fixed to not be misleading. In my builds I've code that is more explicit: diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c index 01cf9233329f..280621ca51be 100644 --- a/sys/vm/swap_pager.c +++ b/sys/vm/swap_pager.c @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) 0, 1)) printf("swap blk zone exhausted, = " "increase kern.maxswzone\n"); + printf("swp_pager_meta_build: swap blk = uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxb", 10); } else @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) 0, 1)) printf("swap pctrie zone = exhausted, " "increase kern.maxswzone\n"); + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxp", 10); } else The "metadata" is the "swap blk uma zone" and "swap pctrie uma zone". Unfortuantely, which got the failure is not still indicated in the standard builds. > +swp_pager_getswapspace(12): failed > +pid 61012 (c++), jid 0, uid 0, was killed: failed to reclaim memory Abssent being able to swap, it tries to reclaim --and that too failed. That finally leads to the kills. > Swap use peaked a little over 50%. So at around 50% "swap blk uma zone" and/or "swap pctrie uma zone" had problems, probably fragmentation related problems. > After the first failure a restart > of make using MAKE_JOBS_UNSAFE=3Dyes ran to completion with one = thread. >=20 > A copy of the build log, logging script and other notes is at > http://www.zefox.net/~fbsd/rpi4/20220127/ >=20 > Clang error 139 has been seen several times during make buildworld on = a Pi3 running > stable/13 with 2 GB of swap as well. Perhaps the two failures are = related. The Pi3=20 > failures didn't report out of swap, all were clang error 139 with = "failed to reclaim=20 > memory". Even with only 1 thread (j1) the failure reproduced. >=20 Note in your report above: obj.FortranEvaluate.dir If you use the options to disable building flang (a.k.a., the Fortran compiler build), your builds on the RPi4B will likely work in the current configuration. But it looks like you have identified a test context for the "swap blk uma zone" and "swap pctrie uma zone" handling. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 27 20:12:20 2022 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 3C12D1972E55 for ; Thu, 27 Jan 2022 20:12:35 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlBb60Pk9z3LmZ for ; Thu, 27 Jan 2022 20:12:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643314347; bh=BhBUn9y0Ghnghc33Q3v4jnYGPqOUdMh89FgQCq6hh4w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=U7nOtCJCTQXu1LHJoNjWCxYnRkKixCtoaQBYq42TPbYLoNR+tOjiL9zjAvuZ7lh8bSyH8tMyIdufUKBjc3P6ySsyu9aOkGnh6yxUIFO9ocw6mWr5pfNz6HCZb5zNnLIo6RSoWLLQuUjLz/kIm7Hy8EiMFe2uybnVEqsFuJgv9GoEztJXnWRvj03Eww7lZrJfed4qVMWanQUoj/9dtwfTnQoXcGgX58PWJbO5bRjM50sLx3DzumsejQuBlPRCmm5KnJqIySoulLQ2TuTSTqxVtmUnyt73ptP4IRerffVakal0QWaw9el4jIpouAKLqvVbhkjJoebDD4TjY5kaPlxW3A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643314347; bh=h5v++PVQuXIZfZmc5q/pe4+4E17QJJipulSogNEewQ4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=T6D0hqxbqdEekU8Z51t/uyxvPy5cDNnaRb/70KyIRoznUab/qkea8k3t4VKbsGYlE/2Ir3eGQl51TOt7g2xhuy+HGIUKvuBV48kTP6wuJABkgBCJJRig3zCDb/9Bh7Kv+eHdpwnN3HWGwZAbMIOgkKjyHeJH337hiAAc8K3LlcoS0mg8x7bnHC1RoGnqLUjlBzaTVP+ZKeWockj5l6/Pz+uWkV1V6f/cprc1PviOnAM0vhEnr6dIyImQA5Vxq0YMxNPLRv7MrH3yF1Xquw1jTGraJt80XP1wExqBB8hg/EnsgpU4GRR13iGffc2n+GB/V7l/mBu1SJ3tMdw3kx7r6g== X-YMail-OSG: 86dyfagVM1kKjZlDIhPiS.7pzSpq2DKJ9SE7dJu694pRS60593L8ooaiEUQsiUS _0LMZ.Lk2HnVUTeJCkuX0r40HL6KaqIvrPMr5J36aSGZmm4iC2YM9jt99xx_luVp38sO_gH0LHRv rgiBR8.PlruV67ow6JQ1Vlakl8E5ZC9sYIx0DeTqtJ49b7qVqvh_D1XWxP7nqhoo6AEbD9sOlICx Z.6JmNBEkm6MzSi6zU4p3tHNoPZDhM3jddkXvGNacfs412g89XbBXYzM9xFVswpBIl2yLXbjXlKU PEoU4_gW8aXenVrq4oBSR1pubwD0AhgjBZt9Iu927kuyFD.ShwyPDQhg0KJk22xUJ5CNH13f7VL4 upwma9A_YKXwjwhu6SInlzI3fpxhtkW7xYt9Q6sgHF6ieLAaX0afW7S6.4zWM_VoM0yH5nECmaQZ vbgalxUWR9K_5KP3V6LZUsBF8cyhkBMNrpN2Am9QjNkXjeIQZBhl_cYk.BHRltOG5l5hT1dc5eCo LgSn6YzI8UJ7M6dM42R_xZ0c2nOJGKOw51UbN9nYO4B.OuQMDWDQXB.eiAnFSRotNY4G3fWC85f3 3xev4Lj7byljlHtih0cMnG8aF3O8K91wXJAuyBHEGzDt.Ame88OX8wk7u9cRgCsj3LImgqqUsVWn m56MemOOJNP3xgMiFpccnfdEkWLpyLMorjc_NjpIeiiMGbCWXA8UepQadsnwl35wRSAAOaamVO34 yszrWWbgZ7zPH98F4JWOEgoJXtTN7ERaqIIU5w9N2pSB06YSBnU6kAVIUHI541LLmKE5aKEPyG0j v1dfd9Ndk9v3CA0WiGWfkWj.1j_m0njXPPRpyMs7jHYge1c5tL_7yGOwTZ92XNZMZ6gvhrW_1uVQ GYrJLMse7bp4R7tdiwVdMRp2H7Gt5IpgJKnV5x.2WUI4.oEXY.5iNeAauOrcF8eD3AEad30cyDtD M9Ed7imAdciG_4Xb_a5aySEdIDV6EA0of4Z8ESLURx0gu4UN74lgUX0toRQWn1sz.iGYP7jHdB.t ULNHt_711yjqlTpGBxwKD7aWmbzDvcVyYCXcL7rigGQCkY_rkAj5fn6.AIxj8ofR4jK6eYv46xtT 74v6j1thTku6UkTTa6iWIGQ9JBh2XiRFLE5.jppjdc6JaxYjUVv7NpYakdtBhLWs3JoilPGVy4K_ D4evO.CJ73Z97Nppj4wljS0j_AZx9laCiK2j.Lb5sd8id7HEpMCSq6njUfYqp1WOIHDRtxaOg1nh RbfDn7hxaXBSQe3lNdzXWnIsLZkjSaTFWyakBpGlbQT7ZVUzB4pZiCXZWuoJ92_lFCKL6p72t74O _wICNtaHneBSwEDGCGZcFXfjtHzP7OdehEFY_7l8uPPOzpRbZhu0vK5cnJAXj5KHon8GlTI8SeFu 6oDXerQ9NvBNRqYTvxCfPq5itDOYFI43sGPqGXMiYxEk9qt47srxk8iQ7Esa6fDTgdiCAkzsOF1I QZzjE09e_BLq79n8lqoP_uODi0205zqpOgHCowW5i6kxae0OaE7.ETdILTro7ig_.iJKcO6thuiZ jktVbU_vnl9YVOVt67YLCmKNdChfLW7OfHVZ3tz86kYhk7SV0VnnU5EbsAec.gxRTWcKz2xYgvsh s75Y7xvZGgXMTZXYRV8Pv2JMv0jlIhvFvEHXWHptsEjiYSmLGYw5mAl4x_1cB0W_tRosUHQscIn0 cQ5BWW9SwS2Llje1hGUQtA9J8kDHNKjRWYODPMECyMxid_ZIB5ACW6BJUrA6jHjWe8Efu25IT6KV C7.ey8dFdorBZl6kG1C0NZaH1MIttJnEuUrewXFfvWSyRG_kjIZ1hAyfE4PHDxHESl.f9cPOx347 _JxGyq3QkFMNW9NVlRUCyfrf0EHOGk.SC.4XemxfbHh0QKHVaYMiNpvOFK0nT8OhIICw61_bD_S5 DgOm1.a899bGzMM5oSGTlLHPfUVGMv69IkdN8DgXElAQq.UtWeFNIEIpOscS5glWy_K.ZL6yYhX7 CBGkPto0wwlGWdKdQX0IIjDJEzwItJsWXcZaT.0Wx4anoJW3xLUcwSaINqUkPOdAwGiKcTn0E5XX VnYFSuGI5cuuLIlmLkB2fcXtiAguHX17x1SBfrEn_6npYgy3f8EDNl1ZxNTwLO6OMK.yalU18rkL OExUnQ42EWZKCDXUG2yPnqOXw76x_Upfft93vWqNsCxOoFXIiLqAThuiBwbK9fk5M7M2ovwqDzYO CNfGlh_M6UcNAkLADoowOTd7FLRQpxMVXQZE.A9Se7QLKB.lg3XShv07i2XCwiDIk.cXBB41gjjd .tSE9UXfc3z6ENE8SmN5vaQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 20:12:27 +0000 Received: by kubenode507.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c78ab6bab38316f9a6d63bf794595527; Thu, 27 Jan 2022 20:12: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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: Date: Thu, 27 Jan 2022 12:12:20 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> To: bob prohaska , Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlBb60Pk9z3LmZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=U7nOtCJC; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4588 Lines: 126 On 2022-Jan-27, at 11:31, Mark Millard wrote: > On 2022-Jan-27, at 08:45, bob prohaska wrote: >=20 >> Attempts to compile devel/llvm13 on a Pi4 running -current (updated >> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 >> make -DBATCH > make.log &=20 >> in /usr/ports/devel/llvm13 using the system compiler. The system is >> self-hosted.=20 Context question: ZFS? UFS? (In things involving memory usage issues, knowing which is always appropriate because of differences in memory use patterns.) >> The first failure reported clang error 139, but the second >> was different, reporting only: >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expressi= on.cpp.o >> along with a console report of >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1258432, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 627221, size: = 8192 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240419, size: = 4096 >> +swap_pager: out of swap space >=20 > In recent builds, such as yours, the above "out of swap" is a > misnomer but is very interesting for what it is actually about. >=20 > Mark Johnston later wrote on 2022-Jan-15 about his "git: > 4a864f624a70 - main - vm_pageout: Print a more accurate message > to the console before an OOM kill" that produced the above report > of "out of swap space": >=20 > QUOTE > Hmm, those cases should likely be changed from "out of swap space" to > "failed to allocate swap metadata" or something like that. > END QUOTE >=20 > Your context proves the metadata problem really happens, so > the messaging should be fixed to not be misleading. >=20 > In my builds I've code that is more explicit: >=20 > diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c > index 01cf9233329f..280621ca51be 100644 > --- a/sys/vm/swap_pager.c > +++ b/sys/vm/swap_pager.c > @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) > 0, 1)) > printf("swap blk zone exhausted, = " > "increase = kern.maxswzone\n"); > + printf("swp_pager_meta_build: swap blk = uma zone exhausted\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonxb", 10); > } else > @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) > 0, 1)) > printf("swap pctrie zone = exhausted, " > "increase = kern.maxswzone\n"); > + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonxp", 10); > } else >=20 > The "metadata" is the "swap blk uma zone" and "swap pctrie > uma zone". Unfortuantely, which got the failure is not still > indicated in the standard builds. >=20 >> +swp_pager_getswapspace(12): failed >> +pid 61012 (c++), jid 0, uid 0, was killed: failed to reclaim memory >=20 > Abssent being able to swap, it tries to reclaim --and that > too failed. That finally leads to the kills. >=20 >> Swap use peaked a little over 50%. >=20 > So at around 50% "swap blk uma zone" and/or "swap pctrie uma zone" > had problems, probably fragmentation related problems. >=20 >> After the first failure a restart >> of make using MAKE_JOBS_UNSAFE=3Dyes ran to completion with one = thread. >>=20 >> A copy of the build log, logging script and other notes is at >> http://www.zefox.net/~fbsd/rpi4/20220127/ >>=20 >> Clang error 139 has been seen several times during make buildworld on = a Pi3 running >> stable/13 with 2 GB of swap as well. Perhaps the two failures are = related. The Pi3=20 >> failures didn't report out of swap, all were clang error 139 with = "failed to reclaim=20 >> memory". Even with only 1 thread (j1) the failure reproduced. >>=20 >=20 > Note in your report above: obj.FortranEvaluate.dir >=20 > If you use the options to disable building flang (a.k.a., > the Fortran compiler build), your builds on the RPi4B > will likely work in the current configuration. >=20 > But it looks like you have identified a test context > for the "swap blk uma zone" and "swap pctrie uma zone" > handling. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 27 21:35:04 2022 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 849DF197B391 for ; Thu, 27 Jan 2022 21:35:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlDQX3ZKdz4jM5 for ; Thu, 27 Jan 2022 21:35:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643319307; bh=6onsu2dDR3X74q0w9C5YVPzQjBFnI/g8Th7PoQaiRAY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oySXIOUK6z3wUGx5n2Oa4KuWhyhEswhMxUHtLytdaLe/WNtZmYuW1BjPNkbrSXGn932aoRDSkUu56Dpmv5VdPxA+ZzSerO/VqgQYHbDDjsO4w+GO3l+UVbRGPV4MFM6ZGpiv3/CbB4eoXU3ESkjxXWzRUe5S179lK/RNXhP4zooUQRFAbVrRA4+9QvKzgy2isDpQ07LTW7uCXbGE4QRXNMk80shR45qCWMIJ6YfIHoCubl+3oVOdH3D6J9u+RL5bZVpamITgJc1e5kBre7BJW8xjY8v5GRGzA9xC9+arJfl/oxcb4BrjPFOhKndTafxcuNaGs0cPgpFEo4GsCut8fQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643319307; bh=Xk0joRoebPqSgXB2s1QCk/LCIYapHO7l01I5u4j1M11=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Wvb1iqDSE2Mlz/lpbSRhfN8OcJ0MFd4CYsk0hQdMAvnRso//8/3oPewKmKzbTIyKqbFF+rjag0t9P7vXra+it6fl23nXjScEYgxJJAHDmB/icIU39/NdeCuqHuh4S+X9djgcyJ8LRXAg3QaBH0uotfH3a1n/DaKUXRsGzf5SBlq0R0ZilRdegFgdn+pX8OcxAoN3XYhBSe02j4EIqxjLbAkaPji5TQPfhGnNFdIwSuOG+0WfF07alN6IhFBK1PnJ/9WG5UqM1HMFIMTi2R3oPmjBQHnDWLBhrzvVJ/+QMGbrupmT1zetnh8TuKMHt09qj2G770s4OeX7OZHKf1sUPQ== X-YMail-OSG: amu4nQsVM1kdG1H3yBX5FrDLjXi1TaZTEDin0L7650JNEf6QHyzkMEGDkF6zvLB jpAjxsf_THW9VrtY0g7U2eXwQJ7cYRDFci8vnJSjD6XF.dTQ7SSixwWVIxTt8IvLmivU.FVecBnT vL.EGdRcWIZtomMeD2L5aHRSMADkkOkCbpuHDGtLSK4n7AwOpg5C9VD875GhqsDlnu3jkpfBcHvZ ha.Gefg2cOOS9jJflQH4k8i19s4LchSBeG_dkEmrN.kq34tp08Ey5mS5Cg9CItb2WW3ndZNHAdsG __PyE9Mtw88VhayU0AzI1hxV6uJo5Xr2Qa6kC2SOlY9EnFb9Tne8xtCPdaTi2JSH5vPyTArvRJEl oMdlY.NQP7x_J.12ea.fo3VTJ6emF6M5X4qjxgxjxF9chy8IruEw0FWWC_BTKVIdFgpFtoD5eG63 wH4djPJkAaeLdqjLn4XUM2Rj6cS1AsVJIoTPbgrrEaYSTYr5DR9j2PlOzZ_4pi0PFGdbF_Hx6F.9 pUGdXSG2dpHYuC5dz.iaYs5Shr9R93JkD.2mgUUJ70Gjk_40oioisng7IGJMmpe3kKQyTKVyBbBm aQSmiDtKDzN5cqjWaWgUIQMtJBMbyozbHXsCsdbee2fJNmC_5nUe.LSaYhfxf7YMcGzCu8rGxCVo MIArQCzmBFwo44zXa26dDAcF3MkmIu.RlFO0hxztOnNd8EZSZ5AWqyrgSooq_rkTK8VR1mW0OUYE aPRS0aUN.UZjb96Es.uypBG9WKNCWeayEkXlb2AzdMZ_E2DWve5bLJxD3F5M56Km2w2eLJsczNbc cu1sBZhTAOPIvjIvAoQBR0EYAXZO6nD5sfS6uzNpfeEquX9ci8Y8V8f_oKYb5MvmlE9HTO_Y_2vp Fc9k2eOIxQmEXsxk2UYaHFpzDnkNlLTLdskowqOTOB_dfEV8dtMirmnu6G5oNYNSTN7aggx_..kt jari8BNaKIJX_.hldd7SVoDxnmXJW4CUvG0IwOMLSIjmKVdw1n1GkpfYoQkH3fDukXMHvoLpO2ME A_Sgdz5YPfwNp4dMdmhSmljmfhDF.VHcWGN598I_JXQJu3bWKIVEpWM7LnJbXSD4T.6MyOLR_pBX ikAgvhgX.MPx04nVHkviBZGTg9a5Mtlav9OGuQtXFPzR76xNluD477H2MFbK9U1dSCvHMGex7AYv pObOXsI3pf.rnAPkTCVKrqOrUReG0wvONqmnDDNxv8xObIYSgZzdsixN0xAEb0zru35kzvr3SpV0 XdWiUpS_dabrRvEG9TqLgBZZyvwxuwjmooxzy1vJAWqqtjDZd3HtgFTgmZgObHsDmcY85jEbJu8V c86go75TL96iNGaDO.BpxMd7iqTPkqXdQ1TDcYwT50fsQIPmkrmBnLOuoQ7J3mTABIoHMbTVoc1Y pqssPYamq1JfkRySSsLN0ax9RDLcIVbI82dfDfLPbYqvUUum2xmyf2VXllfRZeBsIU1kSWEyPVD5 AkR16zhM7.WQ3L2Kh4nEuQSRSDlVVX9fEdEV7KTeY1SDDdzVLullCye0zGvM6MiOgYPCzHTq4UZA a1V_5SSfmk5yDrvEcRqFdXAbwnrNNukRkJF9bSssmA.rq792tdvdiBs.oNohyUaFGVh9u0a2_TkF QqhbX2nZAY94AhldsLgb2mOa1tdMPH9FqLVjd32IkB.IfDeqyO8LVOaDuDSyCJ_QbpkOMzBA9pwz D_jwROT6_Kkmojp3R11vaFx9.ksQCp6mjvP5NGMMAThdp1JaHKiYztbACAz6i9mUUeHmIYEHvEF. kRvyBlF.HA3LuRgUZ34zNFlpFPpq9WVBe3VbRxttmtswDjGvccaz4PHfKqwIrcFc_zTDIQSUjffB TYkkmdjflgj1YnR.4WCX6ldHTBC7ucUgLet7cdTQGuBQVljMCif5WxTXuABmgGzZA3IY9p7i1KjQ y07WB3qkrsON.Jjtn6J6SVQUjt4CIKNlLMx51H3MZ4ybxA3lCDqz2iFAR.7gAOzxL9L.WdM5aCER 61Z3mRptL4uPS7CgtUCiByzJaoysWREhvJW0V0uhXhwFPyv0ubWZoBlSmQNDNDI81.OrBeJtjjE9 PJ.m8FifTwo_mlIV0A650Vr.j1TmQQShULswc898urnpgEyxuGtruxM4S2eCBUfjlgucz2IY8DNv 5bHWTbW7Lz6sP.zj.YEOiwSEI1OOrI0cd_2EY20SmYo1v1kPg0QK0TZX1srXiNIrOM4cSRvlrLb9 K5SGPGVdpQTQqKb8l2RjWSR5_nxZeBgVqbEMt7Yl7yCLUANxe7vi_sJOlfZfQm92TfVzm3c_3wnK cPkXy6qveBUpYd4c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 21:35:07 +0000 Received: by kubenode543.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8872b5fe25bf85b7396c0319856a9e82; Thu, 27 Jan 2022 21:35: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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> Date: Thu, 27 Jan 2022 13:35:04 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <61BC9C0F-7B43-4022-9D52-571E85F2C2CD@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlDQX3ZKdz4jM5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oySXIOUK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6484 Lines: 173 On 2022-Jan-27, at 12:12, Mark Millard wrote: > On 2022-Jan-27, at 11:31, Mark Millard wrote: >=20 >> On 2022-Jan-27, at 08:45, bob prohaska wrote: >>=20 >>> Attempts to compile devel/llvm13 on a Pi4 running -current (updated >>> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 >>> make -DBATCH > make.log &=20 >>> in /usr/ports/devel/llvm13 using the system compiler. The system is >>> self-hosted.=20 >=20 > Context question: ZFS? UFS? >=20 > (In things involving memory usage issues, knowing which is > always appropriate because of differences in memory use > patterns.) >=20 >>> The first failure reported clang error 139, but the second >>> was different, reporting only: >>> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expressi= on.cpp.o >>> along with a console report of >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1258432, = size: 4096 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 627221, size: = 8192 >>> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240419, size: = 4096 >>> +swap_pager: out of swap space >>=20 >> In recent builds, such as yours, the above "out of swap" is a >> misnomer but is very interesting for what it is actually about. >>=20 >> Mark Johnston later wrote on 2022-Jan-15 about his "git: >> 4a864f624a70 - main - vm_pageout: Print a more accurate message >> to the console before an OOM kill" that produced the above report >> of "out of swap space": >>=20 >> QUOTE >> Hmm, those cases should likely be changed from "out of swap space" to >> "failed to allocate swap metadata" or something like that. >> END QUOTE >>=20 >> Your context proves the metadata problem really happens, so >> the messaging should be fixed to not be misleading. >>=20 >> In my builds I've code that is more explicit: >>=20 >> diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c >> index 01cf9233329f..280621ca51be 100644 >> --- a/sys/vm/swap_pager.c >> +++ b/sys/vm/swap_pager.c >> @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap blk zone exhausted, = " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = blk uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxb", 10); >> } else >> @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap pctrie zone = exhausted, " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxp", 10); >> } else >>=20 >> The "metadata" is the "swap blk uma zone" and "swap pctrie >> uma zone". Unfortuantely, which got the failure is not still >> indicated in the standard builds. >>=20 >>> +swp_pager_getswapspace(12): failed >>> +pid 61012 (c++), jid 0, uid 0, was killed: failed to reclaim memory >>=20 >> Abssent being able to swap, it tries to reclaim --and that >> too failed. That finally leads to the kills. >>=20 >>> Swap use peaked a little over 50%. >>=20 >> So at around 50% "swap blk uma zone" and/or "swap pctrie uma zone" >> had problems, probably fragmentation related problems. >>=20 >>> After the first failure a restart >>> of make using MAKE_JOBS_UNSAFE=3Dyes ran to completion with one = thread. >>>=20 >>> A copy of the build log, logging script and other notes is at >>> http://www.zefox.net/~fbsd/rpi4/20220127/ >>>=20 >>> Clang error 139 has been seen several times during make buildworld = on a Pi3 running >>> stable/13 with 2 GB of swap as well. Perhaps the two failures are = related. The Pi3=20 >>> failures didn't report out of swap, all were clang error 139 with = "failed to reclaim=20 >>> memory". Even with only 1 thread (j1) the failure reproduced. So far as I know stable/13 does not yet have the changes to the messaging about kills for failures to reclaim memory: still like it used to be for so long. ONly main has the=20 This makes an unmodified stable/13 messages not be nearly so interesting when they are produced. It will be this way until something based on "git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill" is in place in stable/13 (or somewhat analogous local changes are in place). I'm updating the media for my 8 GiByte RPi4B configuration to be based on the bectl environment for main being nearly a copy of (line split for readability): # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400047 1400047 That has my variant of Mark Johnston's new messaging and my additional messages as well. So on failure, it should report which metadata got the problem. The update also includes adding a 8 GiByte swap partition as an alternative. I'll temporarily have it configured to boot using just that swap partition. Another thing is that I'll remove my usual options for devel/llvm13 so that just defaults are used, including building of flang. So I hope to reproduce the problem in my context and to be able to report which of the two metadata caused the metadata driven messaging. It does take a while to synchronize the media involved to be based on the CA72_16Gp_ZFS media and building devel/llvm13 on a RPi4B takes a while. But I'll report once I have the console messages (or whatever happens). >> Note in your report above: obj.FortranEvaluate.dir >>=20 >> If you use the options to disable building flang (a.k.a., >> the Fortran compiler build), your builds on the RPi4B >> will likely work in the current configuration. >>=20 >> But it looks like you have identified a test context >> for the "swap blk uma zone" and "swap pctrie uma zone" >> handling. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 27 21:48:01 2022 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 A9FD11986349 for ; Thu, 27 Jan 2022 21:48:01 +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 4JlDjD4NzVz4rGp; Thu, 27 Jan 2022 21:48:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20RLm1dE051917 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 27 Jan 2022 13:48:01 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20RLm1lu051916; Thu, 27 Jan 2022 13:48:01 -0800 (PST) (envelope-from fbsd) Date: Thu, 27 Jan 2022 13:48:01 -0800 From: bob prohaska To: Mark Millard Cc: Mark Johnston , freebsd-arm@freebsd.org Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current Message-ID: <20220127214801.GA51710@www.zefox.net> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@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: <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> X-Rspamd-Queue-Id: 4JlDjD4NzVz4rGp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1322 Lines: 48 On Thu, Jan 27, 2022 at 12:12:20PM -0800, Mark Millard wrote: > > > On 2022-Jan-27, at 11:31, Mark Millard wrote: > > > On 2022-Jan-27, at 08:45, bob prohaska wrote: > > > >> Attempts to compile devel/llvm13 on a Pi4 running -current (updated > >> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two occasions using > >> make -DBATCH > make.log & > >> in /usr/ports/devel/llvm13 using the system compiler. The system is > >> self-hosted. > > Context question: ZFS? UFS? UFS > > (In things involving memory usage issues, knowing which is > always appropriate because of differences in memory use > patterns.) > > > > > Your context proves the metadata problem really happens, so > > the messaging should be fixed to not be misleading. > > I looked for and didn't find any "too much swap" warnings in the boot output, as expected with RAM=SWAP. > > > > But it looks like you have identified a test context > > for the "swap blk uma zone" and "swap pctrie uma zone" > > handling. I was hoping to reproduce the first failure, with clang exiting on error 139. Just for curiosity's sake I restarted the build of devel/llvm13 without cleaning. Looks like the result won't be known until morning. Thanks for reading, and all your help! bob prohaska From nobody Thu Jan 27 22:21:44 2022 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 7D37F1983C77 for ; Thu, 27 Jan 2022 22:22:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlFSS1rsdz3Lxf for ; Thu, 27 Jan 2022 22:22:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643322112; bh=s/XfRClZuMa7vr56/qPot0FI4fagoRCrReIWB7ZKl5I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NnBWxBVZ3UN5U0klhoKagkHuL435ZFC2exA6vwr48+j0QcX93YwxgQJUjO7oFh9WuoNLV46ooGuI8eSZ7p/CQD5bfpjSkyGxUY765Kx/hMfiQ60OGR7V+qv6evK7KtHwZYyc+YsxxjPk3c8S/jdOCXQ1nKR9OS+3WtCkm9Pfq9Xhq0YpDlMN0qpGxbLVO783SoyWq9EyyV14Te6rXwldwf+VpO4bN2jLmNJZRVyhcgVFgEtBLpo7yyec32sNrbbDxQ5K9GWlkCDHHnf8N49oNG9SQO51c5q0Y2rRZxEHhMdOcoD8xiSwSDO0ugnKJvxJb226463qu4X9XSgSXpUq2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643322112; bh=zFO2D7HpJx9yLpZNY1ZUVOiJRi2xtgcwpuYbjcrJKe6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bQTDOeP4svi0ypHIRLRnSUypLehNTrsl4w5nncidyZaQnxJYUrlp8eeryD4nvBkfBKAT+zDYaqVDTIyQuAwVjhVadX7cp0OJdG/o3DX3YAEBLzUmoD0I6ixqAe/JeQv/xgz/eO50eKHsH2ni2ITmKi443FoXm2d8Y04SOpuvF//BlbTdxvQWrE0/0AzYkoZzox/AvOM4Cxzssl7mq+07NrmD97ZWIv9q0Ax7lXF/aH/4B/TTbtq1hD5lknxxDq25PCYzJ2DcAPszgkd/FW9KSetI/dhWAreGmgqTB72UW9FOzb6aNIxYqpBlG+HPWo5TYY8+xTyBQGaxRnZJ9nYcyg== X-YMail-OSG: KIa4.CUVM1kpnaLYx0dIv_xouYxVRIwTKUbnykiECmx0cAwp2G7c4iebYeRI0Bu Q_YJUMaM7jGERrJkInaLbj6A3RLpMLAKR.gX9j7GNgEKpAu0bOyX5brPxoiyuz9_3xZljyTL4BWY lOlwOIHGDpaWjFAldUo1.qiYUQG6Ge4CbA7GAfn9_ofPKqbZMXbWGJAIVN1p.rLbkl4_lfeuj8El aBuSjtLdyOeBPPmMyZPlLEOoI2EKeJNMB10daCWxel7_esPRenEWL8H70Vo886L27.Jtoygbl2l4 GogWL3_qNROkZNvoqm20IlmKy5oi_TB67yVHKwm5ATZ0Nk7AY9KG5hnuQr1UGVCPQwDsdCmahfjl mW_BYHkXOj6HwP.U_.WTd3EzCsdkUEmfhHIADpnVm8Lv8BA1XZ0VWXF2MFKsLR3OeFn3Xn2guY06 4KBX9mmjZekBrrXyRIjlINUkbwbgyX5aBcqn80emA4U999v3BWL.ke53tC8UzBCvrZy91f90kzGW mzmxqn2IX4CJA_qJn6Hj1v7ZrUOw1aSDxwPfg5PV8ZlVAZiPWq45bMJf9jWIFJvM3Iqrk4uffYfl JvVLQkQ3h04t9epkVZrXO7hZ4yw.SuQ28QtayB0dNG4fuhsQgw14NPPcFRPmG3rLN4TVLaM28JnW wzez5OV7TpW0eg9T8unDk5EqMYL0Hy85uLT2rYRiOZdnfZGppgPklnC9AMquYm_ms5TiphkKBD6B fwIOSFf.cqszrbvsJCTSHWgG34CJKk5oM0dwOV3b0_SF3G1r2m9ETwg5vDmyfgRtDp.WM2AVoT4P X9ZHHYv2P3croea29ey_X498Q7lyHhN4CRKrXmiqFQdwQdhNGeErStv.I00f5kTZuKP2oXuebbiP EtKpFZykbhEbslfeHz_9HJlVs9XJzxUixXddGV3_fZnetA7GLdNAqzdJNIyF1Q9CbY44cxdPPHqP Kz2Qg.zh1GdBCmy2xXoxnPqlGUpWwBtbJcfuZ7xPDGzXGnnzegJhZNxe3rIrksRsqXrue3WLYqJm Gy9nhbFVDRBhAqXBkPBl2JaIgjNIBM7_i1_NcoeM6tmo8NFHV4DHknlcbZdi5Qo6BQUiWsRM4BSA m10C0AruZ3keS4Za7ZoxIbFCyIV7kBPOv1sijxq6jZnqTFnhQIdvs9zVjzPKC6CicVLjkXe5aghV 6enyaLEMBR6K8flW7cuWT3HHrxiR5m.ZBDxAE1GzI6lxy015Pltq27vsOcdt2F7J5Eu0IhaL._Ba 7ks4JvZfg6ddktlPAxkvTBioPEQgciqhql8bMghH8wX8gnv9f6Fk_.xHDgKagajz2RAyaONLskoz _UnbJrBOLLvOc.04QR7nTzW4jf2hDVZZxf1gmqingdvPJJ5zVlB5U9qY9ZGkEqL_GMZrbjE9tH6a lNrKiwTQNYTy1axp8D303GFdAlmd6oFznhb5dIoeZlhSzRB7z61ztEcQ7Trf9U7i8xoK9PZ6.4._ 46vrhQKsG4A1NejRc7NwG.D5NaVLZaqUo246DjRjF.OzUzRJd6FS4OcXKfkGxDCbS_7l5ACFn5hx EploDIKwIrYwVGCQoD7PoU6ZaK9jFWrcoKsixNlP1CUCC1QoEr9e.FVl2vi5P7mxhNlfCXBw1_t_ JlKR8H9pEXlzJ82C_dnqQLpu5tqlgdZF_3kNOaj8XEftG9HRAEd191URhSqvD05_AfLyNfQ4k6cs lyXk_MuDU68wojpPFmPGaOx9pEcSu2yvT129Vb5Kzzf7IMJjA9fRaXbVIOBxs95.1DHVKadB9ICh 1g.UaqdImTtSvsgPnwiovf_7yY.0tg_vV1M3UzOoYngXQpMix3bSx9Yf.LfzwRGwZ0xds2sdsb.O Abgdn6l01pLLH9Wam.62fLKenootLm8z7CgtrZ7K_7KLOi9A73pL74GMQGCMCUGNCHZwRgW1Hgjl Ktd8WS03VkIXnLDRKwqknvH0fghhS7pv4FlNWw8zKHZLsseQcQVUBPblB0YqCM4ROiRMceAZR1EV aLbmNiSUYDEwKLq9bpg77Bh3KW2mstHiAmyipoHAjOhVKr3BVIoCM1rLNV9TvmYTeCHwzS.GYa2K lSJwngK4zHbxG2vN74L5S.ll4O1x4qAbCOtf.HFSbBLS.KhbZMbG2nIHILF09dp0kQMbCiM3Z9G9 jZBVqjqBNNyjTJUWWT5u1bpWzO5CEE7p4tmsw8IBhuvMu1W9acfbQWjSPz2em.HNVH.fxpaLKI0S MFwq46P9BkPUG37tsy.RZnfa6dpMNp1Ww7ZA2fwOkBmkyYn_eaE2MIoyjH3BuR.FmGmTU3YkfbnH TGImS8sgibYBLsw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 22:21:52 +0000 Received: by kubenode507.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 181d07918215198296cb5d997326420f; Thu, 27 Jan 2022 22:21:46 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: <20220127214801.GA51710@www.zefox.net> Date: Thu, 27 Jan 2022 14:21:44 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlFSS1rsdz3Lxf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NnBWxBVZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2434 Lines: 74 On 2022-Jan-27, at 13:48, bob prohaska wrote: > On Thu, Jan 27, 2022 at 12:12:20PM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2022-Jan-27, at 11:31, Mark Millard wrote: >>=20 >>> On 2022-Jan-27, at 08:45, bob prohaska wrote: >>>=20 >>>> Attempts to compile devel/llvm13 on a Pi4 running -current (updated >>>> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 >>>> make -DBATCH > make.log &=20 >>>> in /usr/ports/devel/llvm13 using the system compiler. The system is >>>> self-hosted.=20 >>=20 >> Context question: ZFS? UFS? >=20 > UFS Okay. I just started a poudriere bulk devel/llvm13 build in a ZFS context: . . . [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD +BE_WASM = +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP -PYCLANG [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD +BE_WASM = +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP +PYCLANG . . . [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 I have my patched top monitoring and reporting various "Maximum Observed ???" (MaxObs???) figures. May be I can get a 8GiByte RPi4B UFS context updated and going as well. >>=20 >> (In things involving memory usage issues, knowing which is >> always appropriate because of differences in memory use >> patterns.) >>=20 >>>=20 >>> Your context proves the metadata problem really happens, so >>> the messaging should be fixed to not be misleading. >>>=20 >=20 > I looked for and didn't find any "too much swap" > warnings in the boot output, as expected with > RAM=3DSWAP. Good to know that nothing was odd about the boot's swapon activity. >>> But it looks like you have identified a test context >>> for the "swap blk uma zone" and "swap pctrie uma zone" >>> handling. >=20 > I was hoping to reproduce the first failure, with clang=20 > exiting on error 139. Just for curiosity's sake I restarted=20 > the build of devel/llvm13 without cleaning. Looks like the > result won't be known until morning.=20 Note: I dropped Mark Johnston from the TO/CC --at least until we have technical information about the vm subsystem's behavior that might be interesting, such as which metadata caused the messaging. (The context being uFS may have been of interest, for example, but nothing in my reply does him any good.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 27 23:30:48 2022 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 B031C19890AE for ; Thu, 27 Jan 2022 23:30:49 +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 4JlGzr0kfPz4gNH for ; Thu, 27 Jan 2022 23:30:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20RNUmHZ052231 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 27 Jan 2022 15:30:49 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20RNUmCR052230; Thu, 27 Jan 2022 15:30:48 -0800 (PST) (envelope-from fbsd) Date: Thu, 27 Jan 2022 15:30:48 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current Message-ID: <20220127233048.GA51951@www.zefox.net> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@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: <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> X-Rspamd-Queue-Id: 4JlGzr0kfPz4gNH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.78 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.88)[0.881]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 845 Lines: 26 On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: > > Okay. I just started a poudriere bulk devel/llvm13 build > in a ZFS context: > > . . . > [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP -PYCLANG > [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP +PYCLANG > . . . > [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > Is this ARM hardware, or an emulator? I've been using plain old make in /usr/ports/devel, might it be informative to try a poudriere build as well? One would expect the added overhead to increase memory use. > [snip] > > Note: I dropped Mark Johnston from the TO/CC --at least until Point taken, thank you! bob prohaska From nobody Thu Jan 27 23:51:05 2022 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 06919199570F for ; Thu, 27 Jan 2022 23:51:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlHRX0y21z4qLp for ; Thu, 27 Jan 2022 23:51:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643327473; bh=gHpqo0wQqf1te8qTLpkEDS+fZB5bXjsvren3PTsk170=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=D3tBMeuZm1Q9f9PJY9WXgYUrPcm0LSRepiNA5JmeVMn0am03TWndQDCsEIlW1YuF7yppTx0jmCCYRhXAWvvzENRdqc2bnbwzrKmD8cgjnVucmCh2801IN6v0VoL9MsjbdYUE5s9ZB1XjRN9yF5Tu3IiMJ+xf9t2pGoWW5e9P0TgyrAiZEi/L0U6kJm8+NNnRn1geCouOUWd6gaeFBlEKSVZQo2G8s0L/F8Ku+HKyYpkVlojoyieOTN3I05vLW29170bbUDniF/MPwN9xbr7GFzhtRqFjHURRmOG/7v4Y0Xti/8aZGbi7HALKKtefjyceh4yJ+5zd8/vxLMRrOiKRQQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643327473; bh=Saab1kWW4BNRQsbXmyoxSbfI4r0ym5fwizTujFpOwuD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=K+cD3DRrktKj3PUdDaj1xffwImLkciZmeLrZUL8fji8P1zKqDF7S78bMMcdgE77Z7pbpjnAeA9xLzii0PXeGV718/RskqX9X7wEeEpGzE0eC1ndCcICCOJ3ZrC5kM3ELFIdYA3+Iuqh4HLyb7WuezJwuZ2aJpkYiCnG4QpGsY94PkpqdXTzrBC1elx9qKotRchRMouFSHuHONyhcH33mXjLa5dQr5c3UqwUqOIFwWlNbH82IZopoN4rGPG+XA0OlrONOFXlxn7UY3PHqaKlovbs52uQ1hiDFAAiGMKNrEV4nrvy2fCupRE9eyybn3NH27+Ise3WXeDxz/P2P9/evfw== X-YMail-OSG: ZFRimQoVM1mkFbKEiN2IXh856hm8ENYpjFqxHmPRrtA3wZ57aoTgga4iKvDheBa odS4QsG6A2bNNbnceZ8u6BHG6DxZPsK3fihvBYAfRls9PDyVTPGa6Fj4CcBeV4p07iFvRw3rIVya ODg3OV9jcARLGQDj9I1BnVVRWPA9IxFnGaBUWVJRJJGKLJ6gpwPwna2cPBO7pxFIMDIeEJyMEOWB kaYAxVQic6ewLsPvYuW4X3b7HTTWGdgHoeXA19bhSqLtc5UaWYhmIOLPb960IKX6O9wfgKjWzMbz 71JcMx6QEHrDIahi79ThLCXCt3Du_sHFvcB7toPtefbcozw5kIPnXNbcIKrbWyh3kLHTr.I3SAOO drXmgVpH_J5YfIeqS6QOrL4AFC6I9PQ4tIJNVEv17FJo9psa5QS3o0EggmX2l3c2_bQiDYsdMwJc w8c2SMIjeswSSEHizEonQQkmfKqGweAPf7kH9qh_KEUo3Aiqf8SE5osr0wlUZZa4_MRcFfka5rY9 Duxr4FeKp1XPANdaQf0FZwtcqR5KAtwFXpSjyKTTlT.bWVy9Z4ByBqUCAoIWyRM2OzCfHih3vmlg aG86tNOECuyjkwkqkNH3AWiMT6Q1IWd8eyZPIVUNnV_tk7wVn7FSYBYRU1mHWXacRC3n.mZNs2Fu lXJS3OCoy3ZEvpCbYZZjFcUL0SEoaae9EY9e590JeF66Wa8.F8Jrl.Hbwa6nAd2kKMEPCchDQP3Y MHPrCAKZ8bxIAIm7FR5rIlXLpReXNP5XCBqZrjxhxVsoY1G.w7tV1LcLSg1IuM37T8cI4nWYSSbN k_1UWadMzLJMFXMg72nwUtjc0BleeGu_iO9IA5bhPdOE1l77tmWsjfoulFbgV6XfuVo_kumpcjFF 0kAbPp2S09qqKzXAXxLUrx6ggzaJGXxdMUnt3EqB5CKYjiy7gAuC9ibB.yEVdBI0HsK0MLcCddfU ktWFCQ54YtS2SgPlvBBIdcccMMIyFYpyKrLiNZKUWyXVqqrdzC5H0GC3PiLtH2y9hrCbiAdzKzMh USdNntkzNQK7RFNZAAlyL2FFaqeVuBqy4bP5PdorNEPcaiipT5aLE1X8LaM0npk6nSXaGhUuzTj7 xn0J3gRPz2YEyKA.CG2I692t0Wt5Sujq8721FZe7L.aUuA7P.c01ZgLYduo7t_1kyDJeIvKN1tnD mu61Pdz_zlPlKyOsIk5NsZ9YonRQu7UHvCwTUm1Ubbh3qRAZR2lJLl47vlJkdY_TX6xyGcZJoSNY JKrWOLK37OT.1oq43hAhI9sWA_DOJsXS9QFSdBwHSzXLlofioC05W8_TSFWX0pamNsLpG_Z1sj81 RlTqJHGJyMFPRrjYlFMycWQ_gqi349PAmjcYB.1jdnfFAnqhrQfLla7WOMposN3JtKqE100UFXRJ cjSUIOEr1XljKZ9_DLN34urKLN1ILbh9_6ZBB06gzKIrwx1MGv7bPLjRKqTx4n2XAAlRkXYepT.E 16i7p_nTYTf6CAbep0bfD4S8kzYZa7B4TOwxexvPjlYXBGtWsv1U36Veb.n766ieNpg5RQIeJlDo 9kZZ3SsPceNbKdq66Sy79olSx8UP1mIkqCuYwi3na9Z3.lpfOXsOgh5BCLAoYSnxX82ZfaE4O8hs Ze89ieVMBXEBlLt1Q819rHTjVpKtr26B_8engoLDlhDOhxiM9BhReUu.MFbUm7pQ579PdIbdru7y 09ss5zuBpzlZfsDJuLdGlmTyuCfVdO2lkB3HfyqRlLpFVDqegfWanFsgpNmKt6L6FXwOPyYyxGwi 3rsqZErdL8gW0Buavo.6gW7X22Pq5vESmevWgokpPhaNyeGJBnqrRmNjSVNldNbh_iZB4qnViKJM U7GPtkW1SpJmW.ZbmlJDcRjabNchHY9lsM12h5kuWz1SDMc_z7IyE5QO54S869aeMVFQ0haXjvHj uuUdmA8OL9aKnreVmdhuaxjV2050xMZrtW4sGaF08eOIr5REx8QzLDi.toDu13K9DSDKDF09r_jH XXcHPzmroZpo5wp0wdr4g3JNimDhjKBrYn4zDJhfEcL94Zb4pk.g20ACxlGMW.E.R65RVa2KLZwD uzJUueaAlMXCIknpi2KqPTDKni7omvNYOG8YobJd86vS5GWVEW.wLuEPSuu2ua__ZBBcAD.6BEFu gRjgadSs1iMGLskaatolLr._k1HNO1VpnCgyJGUy3InxXQYop0LsZpPh0JQ1bkYgBUyZwvzBdMjl WQLVbaJJBCH52EZ9OMSlz8plswbR9MTzh3ryBEPi4FZbAUCgc1kxenK41rbKjUFHSYWWy5czoge2 sIk1sLWn8JWiNbEs- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Jan 2022 23:51:13 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3c77974896e9fb41811c8a7143aba5bd; Thu, 27 Jan 2022 23:51: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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> Date: Thu, 27 Jan 2022 15:51:05 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <72E71144-DBBD-4611-825B-CCEA4C30A6CE@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlHRX0y21z4qLp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=D3tBMeuZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3649 Lines: 111 On 2022-Jan-27, at 14:21, Mark Millard wrote: > On 2022-Jan-27, at 13:48, bob prohaska wrote: >=20 >> On Thu, Jan 27, 2022 at 12:12:20PM -0800, Mark Millard wrote: >>>=20 >>>=20 >>> On 2022-Jan-27, at 11:31, Mark Millard wrote: >>>=20 >>>> On 2022-Jan-27, at 08:45, bob prohaska wrote: >>>>=20 >>>>> Attempts to compile devel/llvm13 on a Pi4 running -current = (updated >>>>> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 >>>>> make -DBATCH > make.log &=20 >>>>> in /usr/ports/devel/llvm13 using the system compiler. The system = is >>>>> self-hosted.=20 >>>=20 >>> Context question: ZFS? UFS? >>=20 >> UFS >=20 > Okay. I just started a poudriere bulk devel/llvm13 build > in a ZFS context: >=20 > . . . > [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG > [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG > . . . > [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >=20 > I have my patched top monitoring and reporting various > "Maximum Observed ???" (MaxObs???) figures. >=20 > May be I can get a 8GiByte RPi4B UFS context updated and > going as well. I just started a poudriere bulk devel/llvm13 build in a UFS context: . . . [00:00:49] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD +BE_WASM = +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP -PYCLANG [00:00:49] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD +BE_WASM = +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP +PYCLANG . . . [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>=20 >>> (In things involving memory usage issues, knowing which is >>> always appropriate because of differences in memory use >>> patterns.) >>>=20 >>>>=20 >>>> Your context proves the metadata problem really happens, so >>>> the messaging should be fixed to not be misleading. >>>>=20 >>=20 >> I looked for and didn't find any "too much swap" >> warnings in the boot output, as expected with >> RAM=3DSWAP. >=20 > Good to know that nothing was odd about the boot's > swapon activity. >=20 >>>> But it looks like you have identified a test context >>>> for the "swap blk uma zone" and "swap pctrie uma zone" >>>> handling. >>=20 >> I was hoping to reproduce the first failure, with clang=20 >> exiting on error 139. Just for curiosity's sake I restarted=20 >> the build of devel/llvm13 without cleaning. Looks like the >> result won't be known until morning.=20 >=20 > Note: I dropped Mark Johnston from the TO/CC --at least until > we have technical information about the vm subsystem's > behavior that might be interesting, such as which metadata > caused the messaging. (The context being uFS may have been of > interest, for example, but nothing in my reply does him any > good.) For reference (lines split for readability): # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400047 1400047 # uname -apKU FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #37 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:53:08 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400047 1400047 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 01:43:48 2022 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 97EA51972236 for ; Fri, 28 Jan 2022 01:44:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlKxY2qJ0z4Ww2 for ; Fri, 28 Jan 2022 01:44:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643334234; bh=POlbT9tbFhxykurVgTBk72M82vy/Jce5XKYSLeG2dLQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aFD9K1a4w5F+zXksbwUx/uPt5GDuz029lQ/1XKbVHCW/kTFyrh+olfMCwhD5PhICWT2y3cnRYzh23k6CwUrmr4BXONbmSmMvu1CR6RN5cKv1Mn/OCf4Z9XFvQeCZ7aS9RrnNNBRXlFZQYWpCNMgWqnTcxzIr4Itp6tjyNuwljPglhs/XPL8rgGSDNJ3MPgS7vE1gMDxWyi9t3vOjHZ+iu4+phpg6N+bbtUgkL+XIjnWVvUKhlRpQ6kyg/tuZsujrMP7VaWx6Vas2em8VdlOqPmi875cxkkboWZ20c5+yCdYtqOSTapPd6466Eoxwnmeu8mfkGvl1EwHETWdHVtjz8g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643334234; bh=pAAkG09uHD0pC8GocPabWywfFcYYW5kOCvJ22YqO3zc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rc6d9NM4Qwl138duWUF53t+oYcDbPG22M3L4hJVxu5fJv4QXYCxZlB6XKo4hMr6p0NnJLBb3Gu5oelZrmoHZNeEzHFE65Ut6RUYazlsr4MHFpwq/TrzRS74bfOi+bYQLMBbc66MgyeDjQ771FnEDyagRz5FBQqWMCvYXMhPEdn9sXXyFMyLvyyX+QXawCTjsblts4t5UdIZrMzxFWFTyh2vMO2JlA0JksYvbCx/Pt/0+bWYS41aZ9DEW2uDukCq3ngB0NDWglhqWDfssg3xWmHy1KnazMWtta1uEifwNhlyKsY03GROifFkWFjoT1LEL7g3qQ3FUKNWVs+ymD87aug== X-YMail-OSG: wtqF06IVM1nylGRuJ.e.soWA8U6pztXlPWPrXHh.SS8D73cQ8YI1tA0rtBsd4Ce ag_Uv5jtxCrqsC99Vag6r070aM2yWC746tKhHp8EKEn4.6zLYwzlvGStoPLuxB60foF72dov4JIA u6WKr8r6L6l0NcHGN.OV4zsEmynImol4L.p5ytiGsi0K0VN5WgVzbyTFZolkrWYC_qqKS4zJask2 vJQuFsbZq90bmfV_tsSY2atEq1nkCkV.ZewypQ33zeifJQqC3zMwC6R6bwsywqRmk2ga90dH54gg Xyyb3l5HmLqiDL4eYPFyJfAJzt.KIq1P_U8lklgpwU8z1btR4gUOuUuKd6MvoIpJj5ZFTVSpjdrB nxKFACa9AqCaeWGus7eiC2JmVyHVFSuAPhB2WeV7_eHpoYg_F8KPwnWssXqdGsU8XUaDRbKqNDpZ ATtvbGpbgi0TvjV.2z4WkK6oeiApvm2RyjoMi3Stc0IyXGNik1J1r8cLyNskxpwRx0NEWyEoysLZ F8LK3QWzNsGrGrhiuEl7Pg8LGMKDPYgcOCyRm6eyIjZRgP.FH7wNe5N6K48P1aPs8dunLMvENRZY PAKr90NAriAnN1aUM_in.h.4R200BAB7I7QfCF6anY79YOxXkBeSp8eoMmzzyepDPzew99KJIxaM Q6Cij2XsBSbeJZ9ZmLDfF7QcyOMEsDXb3nJORGaERa7scvCo3PLYZGNMbhxA4pzaffkzAcFW3vJx Rgh8pKREBKrirpu63XkQQ0VCf.491naAxKRiIQ7hu37lDcjz_aJS2Gnx9OtvMoHP4vlyUG3CWJ6e BsCS6UKNKTu0H1ZBHIvFHYuQgGuxlVxut_AQw7eutKyz1LaOHzERuDB6apyLmadObEuXcsSs0i8p RLAYvXk5qGXaI6Nh535KvIW99Fvor7CyyU2cjGA1KP_XQYDSKw1k1kqLHvtq47IypVrDB1ztqrbE Ntze5ljpmInm2f3mXBUqCVnpznU2JUEaetMMr53v7gWsESc8tIrahO9.Q6p8FuVJKLc_4.95zHrw OsA4MN.RCWTO7pLLzNgwpVURIxp2cmnlzPIrmiRay2a7cxSLPNfH4YiKNbzsTzltnwIuCTqlF2rz N4kD4qez90rM.OipHJbnorwOFP.snf8tkoMi7CY_HmF2AZDXrkBXvlotVubE6Bh59snXn67UKVJT pPVG5oqae5NcrvgB79nWBKz_7Sx_bYPe0beCnvWGWDD58BpZcH3CA7gOc_SPOekoX9QIjbJ8uo08 KRv2Avuh3RkXZfF9QADzwup95TL1gh_QVTt_eoV8g.SSAO41gLtoD8Apyl33tkVuqvIGkfZdfuHf j9hpcjtvXIg9tKPi47YkjvdUj.yIZYSSxvCDV4km.0e0aTbYmvGHfC66rGq4HuEsUaoo2JJuHsHZ H7EbwnX6i5D6CMqPLiQ5L1FparNLTMp.C9oWySIizCBm8yEXto2gb2rrJwJWnROTd4iLmfBeGJY_ PKyygG8wgUUfUS60W4rBb429pGO7qZ5Jr73pjjQRFBdcF5rbeQZUKYW9glbrjUUKMFc4RLUf3eWe Jd6fXnhZoIoIii7ZNonUzUQ9G581KWhSgweiGVzuTG73N5dw6lDKsM.RFxnF3PJ5C1Im63Bcbfts CvOcZjQL7SlQGNoSTkaKpQS87W8mGlUEGJCLBUaxTYVkjAPr59ulH.0Srk7iWIoYgJZCJL8bHlwg mMDKLB1OK1Db_nSW0ziFtgNzhqQcyYfSfZT4jMwF5oN6oope5A_UYQZv9CBmHryRSgbtsh1vYWqt fVWZz9mZ95Uz7UUV.UvbK2vNH4dGvoh_enY4ycGCvYvDNjVKAWIKbGQcW236u6aczTTl6HRkmjex y2JDWUaZQ5YvZoQ23fgdVSTp_9JMahKQhDi9gqYhr5OD.XkuljemHRPB7bcEYGNqoWkDJEKNAn3I j13AJhDn7a_nfMF188V43zNad0LrTzXYCCWSrh.NGoNQVY0Sp0YW50UbLW2q9gPpED_nAYAxUv.Q 5hmn27y2xzi8pt7SYYMLBY0..OJ75teFVDxpomyj.VV7SPMv.YtMKwzIfgsthT_JbFXqLL._WQnh G8Nc90TXuDfcoA3GKTOXMyjOCBjC2isB4mjtXlTbfLw92J.3TZA_bQwaciquPDgGzw2s715UySM8 TmSFPkNAerL9kPqLHD6f1enLJ.GywSq3tNQlcyfVwq4xC0TmZzGxpiEyWtWUH0PwuFXnwxCL4Z9w 7uO7vHxMJom7mGoenT0HiqkiNyZBTDAklNB2tMO16LiOPQamV27gH1VRlkida4Jvu0iGiUEIvk4n 5zCAcTXnVIjbX4MMb7w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 01:43:54 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9af686dde52f5bb8d36f6425200cac18; Fri, 28 Jan 2022 01:43:50 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current From: Mark Millard In-Reply-To: <20220127233048.GA51951@www.zefox.net> Date: Thu, 27 Jan 2022 17:43:48 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlKxY2qJ0z4Ww2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aFD9K1a4; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3245 Lines: 92 On 2022-Jan-27, at 15:30, bob prohaska wrote: > On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>=20 >> Okay. I just started a poudriere bulk devel/llvm13 build >> in a ZFS context: >>=20 >> . . . >> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >> . . . >> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>=20 >=20 > Is this ARM hardware, or an emulator? 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content is a slightly modified copy of the HoneyComb's PCIe slot Optane media. The UFS-based 8 GiByte RPi4B is also based on copying from the same Optane media, both for the system materials and various ports/packages/pouriere related materials. (Not, necessarily, other things.) > I've been using plain old make in /usr/ports/devel,=20 > might it be informative to try a poudriere build as well? The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D and USE_TMPFS=3D"data" in use. I have a context in which almost all prerequisites had already been built. (The change in options lead to 2 very small ports to build before devel/llvm13's started in a builder.) (You might not have a jail that already has the prerequisites.) > One would expect the added overhead to increase memory use. >=20 Well, from the context I started in, only devel/llvm13 is being built once it starts. Once it gets to the build phase (after dependencies and such are set up), there is not much overhead because the only activity is the one builder and it is only building llvm13 --via make in the builder. At the end there would be extra activity as poudriere finishes up. During the build phase, I only expect minor overhead from poudriere monitoring the build logs and such. I expect that the mere fact that a poudriere jail is in use for the builder to execute in does not contribute to significantly increasing the system's memory use or changing the system's memory use pattern. There are some other differences my context. The instances of main [so: 14] are non-debug builds (but with symbols). The builds are optimized for the RPi4B (and others) via use of -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some personal changes in it. (Some messaging about the kills is part of that.) The RPi4B's are using: over_voltage=3D6=20 arm_freq=3D2000=20 sdram_freq_min=3D3200=20 force_turbo=3D1=20 (There are heat-sinks, fans, and good power supplies.) The media in use are USB3 1 TB Samsung Portable SSD T7 Touch's. I'm unlikely to see "swap_pager: indefinite wait buffer:" notices if the cause was based on the media performance. (You have spinning rust, if I remember right.) I do not have a monitoring script making a huge log file during the build. So less is competing for media access or leading to other overheads. (But, as I remember, you have gotten the problem without having such a script running.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 02:54:25 2022 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 5840F197AD9D; Fri, 28 Jan 2022 02:54:35 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JlMVy1WYrz3L7q; Fri, 28 Jan 2022 02:54:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B2C0C5C0036; Thu, 27 Jan 2022 21:54:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 27 Jan 2022 21:54:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=ZiJhbCEmuCr2q5GuJAZYNl5cOZdGc+2ZLtmBDt 0jgFs=; b=eOH1WSvPIdhivIdbSH8QsHYLIlFGdnh9WOX58rylC/wJ/b3CIOxeed 53hofi15ivO30O/TtqgHHTucb32gM9fLTi2XGnXNU9n9hdtRD4Jk/wX0raDLbm79 4a4Uo57SJCamCH90GdDSW0swGoEF+GYFYMz7DTDEBo0716ywRbBLMO0XSx7CbxSJ mG5GZRW2BzL8HHzD+5w6kbegkueA3RN9xfuzwK+T1Rm5soTRD43viEjKWrwWMsSo /ICPzLO8jnM4iczbjewz7TsqaQh0Q1tLfo+IDqNFnKVVaOxN+BKMQ6axJlYne2SA sbmQjPcsmX6FCFyRf6e/Q45u2pgOeoqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZiJhbCEmuCr2q5GuJ AZYNl5cOZdGc+2ZLtmBDt0jgFs=; b=VVKoljsCvop5r8tfgdCWn4MVSqpA9qHw2 9vMLUgl06viKZ93t7p8Iww0boottNFFoWgAVOEC7fTien+wJdFz0VGB1mMN7ThDf NG2hkGiwykxdBXzML7wpte27dBVsGXMiYrEbSdxCZM5grw3htJDHJ8SbyFM5aBRg IZy0gFO/gWEn7UDEoPMx05HoZY2v6mEiTrkcuJfGktlUXxsCcuUP6TfjHvctBToj KYRA4qwz8MUj6GE1s1x+tnD5DnqFLN9mfNkDKH1N6Lk4X1Ylpn781jH2QzJgeMPe r79DlEJmmIbz1h9fh7paVUv85QWxjHHXbid+ZqyvdLPgSy0oekbxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeeggdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jan 2022 21:54:27 -0500 (EST) Date: Fri, 28 Jan 2022 02:54:25 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="juCUSW30Z3DtYX2A" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JlMVy1WYrz3L7q X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=eOH1WSvP; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=VVKoljsC; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1326 Lines: 37 --juCUSW30Z3DtYX2A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote: > >Will try to play with zfsd disabled, as suggested. since reporting the issue and disabling zfsd, the problem=20 has not re-occurred so far at this time (28th Jan) --=20 J. --juCUSW30Z3DtYX2A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHzWtQACgkQs8o7QhFz NAXUYBAAlvHToI7h3zLmNZcOYceEYn5Tml8PyPRSDhxcVl+aX6D1wRyZUrIXVyyB Tkk5fM613nHxBBKo08LR6J9dqd1fP4MRV1Et8XPAfM9ytgKZQogd0M0TiBRLVv9K LZG8lmpK204GkDZAVB00u8x6o6oaTIGkzqOXGzbcHbkg6hb1Nb/lVaaS23QwgVZO McQj1kTurHrot/azTJGeucPEsBWgBSM/b7tltQTxQc+WTSEnpQrSIBN0cnBBQgPl OPhST3nsFoi32+o9/y2MxwAdVFtnQm3bAKjeZ3I56T/exiDVZHyJeehfwgTWpAvW TCY3GMXf+D+NjCVlVShkz+qjyY3s3KMJUYjtAKkZrQFMYKGatjLJNjg8jhyekqC1 ZYdMMqdOHFMn4e3R9sMHadMGZjZk6vadoh+XK/NslVuKbUF/w1awT8TyX6EtOjTK OhX377EsxejdaTD+AIRIPNIiHNQNFvVLlnvWNCYg7RwMlxkdOimcI8D9weoTO9b3 KJh5gCWfP+nxT+hszyF8SfpexhWFymiBJ1HChN4uby21rgSn87+LwLyfb3gQR5qx RR6UfR+HR9u71I1DSzRZgunnfBgKFBHZVl7EFmiomxGMHxWjvn3paXxJjx4bjqM5 iDe9+ljK/l6qgUipkFop+Di9uqAKy3LF82H0F9Xsermaaha5W+c= =PIWr -----END PGP SIGNATURE----- --juCUSW30Z3DtYX2A-- From nobody Fri Jan 28 05:55:47 2022 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 2BEA1197669F for ; Fri, 28 Jan 2022 05:56:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlRXH6bcyz3pdS for ; Fri, 28 Jan 2022 05:55:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643349352; bh=ntRQ7LJQ4cKIvgdNuJRRqjYJkaxw/ekQ2K7lmSojTpk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=e798nUNaMnXLSfeCyAehTifglvPh75IikBLybGOlpj/wam25juGVbHBNXqkyOH5Zri0h9g5QpfZe8RT8TvaXcUHQ/Y6FiPMePOmQtKg4bPOYR0S23Br+B+DwH38uOyM7kluit0oJFLQsfwE5KUfKNjjZDd21UQJ+/Nz8rjJtWG9Kb9mEcx04VNJjVW0lC3giwj4Vp6xpEb+fAjRZXkGE2MjVlDG8lc4C25ZDoLdn/zprqs4V1Z+S+fqn4l5vMcTA2WUCF+b9Bnxw9YZ2qdh+uiiiho24tVJhxRcXrsubLhiDXQ8UwdeVoebZKDudhHdzx2gyEs9rb846Ud52U3mzhg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643349352; bh=/TbDRL5vrM7t4E6PcsatD1KIbPY6TgUMe95mpiY6rT/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jM0USl7ArS3Be3G/WGIHMmvb8tPNLMJi+D72ni+h9/bxteyy6OgRb15lUdRrfXsZlOz8GTBL1OPUW6zlAO/8w0qKXSfmTCqclKwIFybY17Tmj9VTxW6JD19pJgdFx1+cY8YmcFQigmdhVs/6tCzGK/C8P3rs1ie4I81+3TuzztxLUpVRpLF0iVegQe8s9pTR3EELHOGnKxbDXqGBuBbyTBTCrlQs0teQJkCpXL1TLUjdeLf+HRfZo+tTxkC685dkwUziWS2PvIL/kyJWL+ISdoIEaKRWBuwqbFNRkvXxbHW+uapQOI41ioYdPeBbDLzhD8GVa+gdH+i7WmgHz6H08Q== X-YMail-OSG: .Y_3XAAVM1lsl4VB0rlg6QoclkBD8KMX3o8Gn7pJzHlejeQlPlQySAbNtlAbZ7G dW1_cx0v2BlG1DZD1kebatygEBE7oMlgf1YzHnT2DQqGlLWear4u.d5iWedp0lJtcpbtNtw3XFQu DDxNNC_P9gmQh0PsZsBdYm4_U63n0nE6J0bQxLZ0RskCWSGbn7NHRCzjs.QLF0mo4X8NLuYQ8UD_ Dtc7SQEJd0euX6fPPcnSIe1FFgv0OznyA3J0o0tPcyhpK7mamhDuSSxHZpxz4plM2_HL1Zc9LRkx jXZ.5bNbjfBHFwSuD3jx9TuipEI3StMJLIJKDswFETC2.cEEuOtXQlE6NBN8D.N5zJzv_48fWdoO CU.Qpd2UoFquejH7rZPmh8oDFPzELgIUpZqGrRN4jIYHo03M60Rin9T0uXGpjqReFbnAbKYdOmvS .jrTXrGdQH8Ypsj871tAKJT.KG9pBkYSNqa3d77ySriV_ehsrmjbqSpAZFYl0X_Z2t3Ptf6h62L. uja5.Bdfb18B8vdKJqydU71k9XKktux9wZpPJYcQoK6E0W_7i0vNi6HskpBl4PbhMJWvl3KKu32E PGnjHq4ee6g3vNF9XFmp7GGgVOHQx.e1K.f1YGYpX6d_XdMiZJalVOUwCeZMDHUadw2vJCnX6_OO tPJlsPji5nvfx2ShDYsgyU7pnwZHe9ECRsDeTaHG3NAgnta1jHOYH3Fr_gHymY4FsSrBxldwtvTQ i8RmkmpmHvVIlN2xLjmLtOfM8w96sp4WH68425afxCrx1W7g3b5rhC231shnVCbswsFTpyHNweGu Tlk3jjVWZzLbjev9TZYBdwFHrl8UCLjXaKOqiSoevgzZlcaJIEZnigdUM.BDoX.UGuUn_BAT5TuA BZYiYX9Lf8hgEzcmkeBK8a7NiIiN0JpyujZRifgNdaS04CX3i3.ApLs5s3ICwQB7yB7IZ36iLUbb hN4Y4BO9lgSkyi44WBWBlOBYTEZZGgmHL7p.gUaiGaoXbZSuoTnpnQpw9T8RRMnuHKUvV1lk_XTw .Z65KQV4MZ1SlgXQ2rv27IMru2IhDlSFUtPEbmF5tIgFoiC1v9X5UlBwTUe9U2d.nKLUNy.AOeDQ nTySQacptPnGExk0ksKV7W4lCCOuP67VIQONSklke8KCWNC1zpq23IZgrjUJSDcFzxCL9lWrli5s h20TFk63A0GJR7m92XeH9RhjwTPX5j0vhp1_ScqqvZESz1WLFlnfXiHPQdb.zJnhILj_R7a3qZ1w 38M_PUc3njL6UxsWvnXk5z8hgFcQ8e2X_79cqKkxkgOh.JLiwyVLhlNjTj3XZD9T0Zs5mpTZuZnj _Se39hLTlxC37UmP8bjfe.E_kjmAumtrnpjVBetEt4itH8cfBlkQW9J2wtsogzsBF0mYGpfZpFIB lvjBjwTuWXgr0QtEv3fLAx3v7g2E1VU9OlDMi14YyrL7GH8cwusO.D.a3LVhI8SzSVoDdM.hCumh L593Gt54z.4wInmcTDeBDKk87gWY3UHZu2YWB3gO9_DOJlTOFLvK.nhIEhuIbwsVvkKc4sAhxTDJ __gKXTLnIgTb2mXfULqk1.4iEJ50vl0aEQXzmZbF__cqj.sbENrza2Tqe8yIUFbm64GKwiGpbSfV AcAVmtZ7RMuI2KwdN03PoZINJoRVvxVnz9hpOyHzuYkmz6eDb2oP3DWsBtMgcMw8un1EIHbNkYE_ O9Nnpo6UtZSnOBQZeUXkdPKhIfcSoyYei7EEOLw4KrJJZph1uiKRR32BiYWZlpU4Pxbyp2NRtJvG Wd4T5GT1GD91mirR_W7iWJ0zsPz2i9wcr7HFU1MOtpCU05rWnbHPd9enj9bE7TC_5JitKOUDPQP5 o1EhvSSI5lKJT5rX_RvgotjLFuyeUVsfsxx02ohk9LspIH9_j7WtzyTozL6yhi.Z2QvU6c1pxD8R D_n1BafWcwvVzXcffBZP5yyERLlrXnTLJpFmVrzJ.h484ICcliWfjUKVU6Kw9lgzuHH7aqwZB9gV eWG_pywR8IeumykxO9oXJPPS7XE3iZO395Q9NAtkeJAsWl7bdZs6gom9WJMy7oApHv.aAq0CGKls lohmlHzl2lVlNfXg1tceEAgScYA1VR0Dkk9hWCkdVCy7dkMHv5adqpBC7RYvrZ6oMMurWwh5iEe8 v7r547MysgaBE4rJD4TeZVwNQSUiynz0xB3W6p70ThVEjUHsSwns_UIr.AmsK3AoHZ_2U6gUc5zL hC8Ib.cDS1D0W6wUXtY0yWWYIzeLSerdfkk.NpNQ2p0WpGsqwEInSDUlTIzFooVwai3tJFIMUvXY L4QdE1m_2eph1gzblWQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 05:55:52 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0c7342698c51d073dbc089e98026a5b9; Fri, 28 Jan 2022 05:55:49 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [ZFS context: used the whole swap space] From: Mark Millard In-Reply-To: <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> Date: Thu, 27 Jan 2022 21:55:47 -0800 Cc: Free BSD , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlRXH6bcyz3pdS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=e798nUNa; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7511 Lines: 212 On 2022-Jan-27, at 17:43, Mark Millard wrote: > On 2022-Jan-27, at 15:30, bob prohaska wrote: >=20 >> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>=20 >>> Okay. I just started a poudriere bulk devel/llvm13 build >>> in a ZFS context: >>>=20 >>> . . . >>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>> . . . >>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>=20 >>=20 >> Is this ARM hardware, or an emulator? >=20 > 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content > is a slightly modified copy of the HoneyComb's PCIe slot Optane > media. >=20 > The UFS-based 8 GiByte RPi4B is also based on copying from the > same Optane media, both for the system materials and various > ports/packages/pouriere related materials. (Not, necessarily, > other things.) >=20 >> I've been using plain old make in /usr/ports/devel,=20 >> might it be informative to try a poudriere build as well? >=20 > The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) > output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D > and USE_TMPFS=3D"data" in use. >=20 > I have a context in which almost all prerequisites had already > been built. (The change in options lead to 2 very small ports > to build before devel/llvm13's started in a builder.) >=20 > (You might not have a jail that already has the prerequisites.) >=20 >> One would expect the added overhead to increase memory use. >>=20 >=20 > Well, from the context I started in, only devel/llvm13 is being > built once it starts. Once it gets to the build phase (after > dependencies and such are set up), there is not much overhead > because the only activity is the one builder and it is only > building llvm13 --via make in the builder. At the end there > would be extra activity as poudriere finishes up. During the > build phase, I only expect minor overhead from poudriere > monitoring the build logs and such. >=20 > I expect that the mere fact that a poudriere jail is in use > for the builder to execute in does not contribute to > significantly increasing the system's memory use or changing > the system's memory use pattern. >=20 >=20 > There are some other differences my context. The instances of > main [so: 14] are non-debug builds (but with symbols). The > builds are optimized for the RPi4B (and others) via use of > -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some > personal changes in it. (Some messaging about the kills is > part of that.) >=20 > The RPi4B's are using: >=20 > over_voltage=3D6=20 > arm_freq=3D2000=20 > sdram_freq_min=3D3200=20 > force_turbo=3D1=20 >=20 > (There are heat-sinks, fans, and good power supplies.) >=20 > The media in use are USB3 1 TB Samsung Portable SSD T7 > Touch's. I'm unlikely to see "swap_pager: indefinite > wait buffer:" notices if the cause was based on the > media performance. (You have spinning rust, if I > remember right.) >=20 > I do not have a monitoring script making a huge log file > during the build. So less is competing for media access > or leading to other overheads. (But, as I remember, > you have gotten the problem without having such a script > running.) ZFS context: Well, the ZFS example used up all the swap space, according to my patched top. This means that my setting of vm.pfault_oom_attempts is not appropriate for this context: # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults at the time): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'll need to retest with something more like the commented out vm.pfault_oom_attempts and vm.pfault_oom_wait figures in order to see the intended handling of the test case. What are you using for each of: vm.pageout_oom_seq ? vm.pfault_oom_attempts ? vm.pfault_oom_wait ? For reference, for ZFS: last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: 5.71, = 4.92, 4.76 = up 0+07:23:14 21:23:43 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% idle Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, 40960B = Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, 7820Mi = MaxObs(Act+Wir+Lndry) ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, 5994Ki = Header, 457626Ki Other 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, 3436Ki = Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), 15993Mi = MaxObs(Act+Wir+Lndry+SwapUsed) Console: (Looks like I misremembered adjusting the "out of swap space" wording for the misnomer message.) swap_pager: out of swap space swp_pager_getswapspace(18): failed swap_pager: out of swap space swp_pager_getswapspace(1): failed swp_pager_getswapspace(1): failed swap_pager: out of swap space swp_pager_getswapspace(1): failed swp_pager_getswapspace(7): failed swp_pager_getswapspace(24): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(18): failed swp_pager_getswapspace(17): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(12): failed swp_pager_getswapspace(23): failed swp_pager_getswapspace(30): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(2): failed . . . Then a bunch of time with no messages . . . swp_pager_getswapspace(5): failed swp_pager_getswapspace(28): failed . . . Then a bunch of time with no messages . . . Top again: last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: 5.71, = 4.92, 4.76 = up 0+07:31:26 21:31:55 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% idle Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, 40960B = Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, 7820Mi = MaxObs(Act+Wir+Lndry) ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, 457631Ki = Other 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, 4096B = Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), 15993Mi = MaxObs(Act+Wir+Lndry+SwapUsed) I then used top to kill ninja and the 4 large compiles that were going on. I'll change: vm.pfault_oom_attempts vm.pfault_oom_wait and reboot and start over. I expect that the ongoing UFS test will likely end up similarly and that similar adjustments and restarts will be needed because of actually running out of swap space. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 06:00:15 2022 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 AEE861979859 for ; Fri, 28 Jan 2022 06:00:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlRdM65vPz3rd2 for ; Fri, 28 Jan 2022 06:00:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643349617; bh=Xc/Sjwo55C7wrJUbZsvLfQUUEohHdeptFDoVnforKew=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=f40cQQgjXJ3OtpXmVf4IK8W6urOzUXrZQ5Z4L/7UihgjTon+qZNREzZcGnO914bha6ldZUCtNInmCGIoWysM7b0/ShvFHqmb+iIfkMLr8Uc391b33/tPHlsMxFPJwQ6U6Q/gVoIyDarE1sEPnLH3/sZA0fduSYHZFFTdkVbb7R8FEFxLmfRd+5qimdjHkCmsZZZx30/IRj9OQehaObxl0mOpSPjapLaM9vB26RGb9qMBF5GGiWuAjJ0eEexFYF50HoPbH1ozRKW4fM3viyeNOubCiEbUcVILQMQUrjKp3eHvgpgAqI7YeeVPUOI/xYIr5ch3386JmE65Thu15tk9Wg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643349617; bh=Z2ui3o8IenWMDgEbh1ZFnrekgEtdTSqc1/giaY+8E1h=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=E0OrDo/dbVaaZkaaGMwG9f9UF2Slnv4l5J0AJ3s7NGY6Zfe2F2i6Ui6LRNLcQ139oxCDkKtsjahLnTg2ATU6WErNuxaaN83SiKxAWEj8T4vFENPrHVrsd8jQas0XA+pLckEqinspEkfeR6yxcmobiPmEhAyyDHJG2G++BOVd+39D21y5C5XlUgesXISUg9r1gRcHIAplOhO9GyyIHTluX0s4i4kfUUc+0Bt9k/tCQx+mOvC2NIgoWtvmaz3kbqLuVsu26AobXsKBOy7RQyNL2SJP2vUuxdhfCh/OKEtKVq+eFzj1EY57Wt7GNEXUJDz5HtNSQ/+gZhsqWRl97LoyCg== X-YMail-OSG: QhqM4N4VM1mYmnCrpz83emOnBsRNB7iJVTTHZ9QtZzVVtoGwquS8jLUiVe.1b5a QEbnQuQrKYfmLfO1hcgibYjKcNnVTaK7EgXS8_z182MyjbHKjkAnZKTF5tj_u4R.iJz6oX602oC_ gRSsMZEw76Tyf4Nmem4ZDBrQ9sG78IdWmjoVbAnOWiqQTQ3B4m5hbqxiSfT8nLu5Tofs2fbv0XpY C5wmVLd.IsKrsvPZ.nxfYueLWcNdJeQhafriZoTAO4gGqVnEA4oxXow2SQOe8d1mY9xIajKtAtnJ SotXeDRwqM6cLrbVj_.5DWKez3DuaaUtAse3sglOLVh5Z7NJXSEIbv8hPnB45zE.iBiNI01DsoJU rlopy9m8I5GUIvuomkJaWaW0TdH8zkjXWy9ctmCXhheZkiS.DLb4xZro1tUO.93xP.P5xDzwnyLO Ndnzy06JWDKxXhGheSu07nOHPfisGSEZ2pi3Gjc2XainJql0I8PFZuUzwhOqPbEH_fhM7La3NRUN EvhUQ7zEpctCyB0kBQUSko9qj13wz.CQ4usTxsrqFYoeBhBx3GfaS7uaneqdChANUOusA33wFclP CAirQ_AJy.UK2f8a8xpBJukHbzJfvr5oWYH851k3vOC0aJDhDNbT564pX0ZzwJE4jzOvVpdDRFDb dzd9UXR1FKYRSo1dJ6DrNooe6pmUeLWvKKOLrcUtwFNDmhKSQN4n.isnIxP0FzMS5fvgDz.34MHj 2JEhedKWQbjpk26yBXNT7uPF5Su7bcxySURpVyn1UTHmhfqtdB6UMPRiAeAgvjcCM_jiT_f_KTDo JeG.mvsqhFQiPguBLvPj7dzevHU01.f.z1TgPJICrxJV_fcL0HWedj5Y4aR6.FER0uUHfzBxWuPR 3vpbrcqZIu8Ow2pC3JghOOl_49S5yA2dSijudCkTvO42kAmPgJHbjNJ83t.25nxofQtAgs8Bt1XK lD0TLc7_gM77oS11ySdMiDnL976uAq9YjINRLPbUFA9XhlEEuqjdQysXvnoXWTksAWsYfxr8H7Kr QU314wJ32tRXpj.NalOHFmWZCsGpT7X9xo3W08E.WZFlrUcTkaYU6OfrQJEluYUUcMWbcZphf1EN GVWIk66dcAqfMTCdsBSzMnk7XFS5P.abkkdHMXyLf2P3s2ETzq0hl.WDrPIbJOE5S_VpGB7mZ1cD 25nhdkAKEbOVjbinwmdqQrNPQP2s5N.Q6siEIZSmfMlj07dAVN2coH1Wg9dTojlITGKhKa8uIhLB U1CcyTJuvf78Ug3C3HzlRjxD3WPfywwV3Ggby0fPKg5B2DsURFAbMg5PwfklWXwgVMOi1_7gGqDp PkZ7gphN1Yy8.ctmlS7VLxxlNU4lIdf5kXzW1kceryjR54mfZB54azkqgHfAoZDgGhppSHNGKe2U DprMOYCBnj5r7p.qC7d66DPGdfCPdUYCCYz8Tqela5quimUX2pTefE3ZyCB0v7xo0H5Z4LeEedyI OmghrhtmUIDTIRcG1cz6dvIdOmzhPLVMI3VY8TQkqsDNehF4ZyQFTbt4mtv15Q9vOAbfSKtHClIv 63CnJ7ptz.cdbP1Gi5SWdjN4I7aj6KM2YJJCFyGv2Nv5N1ANAdZDI_Vjo6mD.vqVEl7X1QbHR086 hH7bAurjozo9tSKGgwdDsCn4y_CCwHBdnqtaK8tHGvczXtYarygsY1ZcRwdHP.ouS_lBHFQlBWVN my02Fft6ojpQjb7ix.o3Ses0ChQeHjqcQHZErY7AEsnwCkf0rT7IVNL72FyRk4dNF3tHbBGhyBwF 4jKWaArXvpe6L2QtxF1n_J8YJaohcI.Ra9WDLs17mMje0H__nTpokOiLQWMZ98pzCA01zp3JISjT OWmh7cM6S8hrJG3KomTAVjqXHN1bWcKgiGruSw3ZR2CWqzUUqUzZTWrsRprFOmVb2ZYsFGWbJk7Y 3G88VKoMrcnMsCJNwKP1D0YIiHoRwwdm_UqHKK1d6ygc8HhfXVe3o6u3aOz70cc5_dUZGyil.r8U .L2oOI3UojyoexTYT6tkDIVxV.n_7hBirJdA3VYeSpFXmg7086G5t4lkTZ3C0rPcfWIFKAqU6g6r MlXKfLTG_6u13f30Ft.qlvZxdhzRnAiv1cgFZLkY9oHFmBrMr5c1KUAHVl0keg1w6Txf92jAy41o DwN_T0ppXuQWXa9WXLtApPRw5D5kW.h2TyvUaWRF2Vo9tyC9k7oM7B96svMCwhuWECpaGIm3fMaG GIlFB0Q5tDNpoIFmSIYJUSTnUda5c.WGuxz8367xWFM2h5KpADYIsWWgmvOSS7gqoq.bgbJyIVyg Y1GeGIKJlXLu_bjCEIA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 06:00:17 +0000 Received: by kubenode548.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 82e3c88be288bd77624934644cc343b5; Fri, 28 Jan 2022 06:00:16 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [ZFS context: used the whole swap space] From: Mark Millard In-Reply-To: <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> Date: Thu, 27 Jan 2022 22:00:15 -0800 Cc: Free BSD , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlRdM65vPz3rd2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=f40cQQgj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 8173 Lines: 223 On 2022-Jan-27, at 21:55, Mark Millard wrote: > On 2022-Jan-27, at 17:43, Mark Millard wrote: >=20 >> On 2022-Jan-27, at 15:30, bob prohaska wrote: >>=20 >>> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>>=20 >>>> Okay. I just started a poudriere bulk devel/llvm13 build >>>> in a ZFS context: >>>>=20 >>>> . . . >>>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>>> . . . >>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>>=20 >>>=20 >>> Is this ARM hardware, or an emulator? >>=20 >> 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content >> is a slightly modified copy of the HoneyComb's PCIe slot Optane >> media. >>=20 >> The UFS-based 8 GiByte RPi4B is also based on copying from the >> same Optane media, both for the system materials and various >> ports/packages/pouriere related materials. (Not, necessarily, >> other things.) >>=20 >>> I've been using plain old make in /usr/ports/devel,=20 >>> might it be informative to try a poudriere build as well? >>=20 >> The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) >> output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D >> and USE_TMPFS=3D"data" in use. >>=20 >> I have a context in which almost all prerequisites had already >> been built. (The change in options lead to 2 very small ports >> to build before devel/llvm13's started in a builder.) >>=20 >> (You might not have a jail that already has the prerequisites.) >>=20 >>> One would expect the added overhead to increase memory use. >>>=20 >>=20 >> Well, from the context I started in, only devel/llvm13 is being >> built once it starts. Once it gets to the build phase (after >> dependencies and such are set up), there is not much overhead >> because the only activity is the one builder and it is only >> building llvm13 --via make in the builder. At the end there >> would be extra activity as poudriere finishes up. During the >> build phase, I only expect minor overhead from poudriere >> monitoring the build logs and such. >>=20 >> I expect that the mere fact that a poudriere jail is in use >> for the builder to execute in does not contribute to >> significantly increasing the system's memory use or changing >> the system's memory use pattern. >>=20 >>=20 >> There are some other differences my context. The instances of >> main [so: 14] are non-debug builds (but with symbols). The >> builds are optimized for the RPi4B (and others) via use of >> -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some >> personal changes in it. (Some messaging about the kills is >> part of that.) >>=20 >> The RPi4B's are using: >>=20 >> over_voltage=3D6=20 >> arm_freq=3D2000=20 >> sdram_freq_min=3D3200=20 >> force_turbo=3D1=20 >>=20 >> (There are heat-sinks, fans, and good power supplies.) >>=20 >> The media in use are USB3 1 TB Samsung Portable SSD T7 >> Touch's. I'm unlikely to see "swap_pager: indefinite >> wait buffer:" notices if the cause was based on the >> media performance. (You have spinning rust, if I >> remember right.) >>=20 >> I do not have a monitoring script making a huge log file >> during the build. So less is competing for media access >> or leading to other overheads. (But, as I remember, >> you have gotten the problem without having such a script >> running.) >=20 >=20 > ZFS context: >=20 > Well, the ZFS example used up all the swap space, according > to my patched top. This means that my setting of > vm.pfault_oom_attempts is not appropriate for this context: >=20 > # Delay when persistent low free RAM leads to > # Out Of Memory killing of processes: > vm.pageout_oom_seq=3D120 > # > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > vm.pfault_oom_attempts=3D-1 > # > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes (showing defaults at the time): > #vm.pfault_oom_attempts=3D 3 > #vm.pfault_oom_wait=3D 10 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied, even for nearly the same total.) >=20 > I'll need to retest with something more like the > commented out vm.pfault_oom_attempts and > vm.pfault_oom_wait figures in order to see the > intended handling of the test case. >=20 > What are you using for each of: > vm.pageout_oom_seq ? > vm.pfault_oom_attempts ? > vm.pfault_oom_wait ? >=20 >=20 > For reference, for ZFS: >=20 > last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:23:14 21:23:43 > 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning > CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% idle > Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, = 40960B Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) > ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, 5994Ki = Header, 457626Ki Other > 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio > Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, = 3436Ki Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >=20 > Console: > (Looks like I misremembered adjusting the "out of swap space" > wording for the misnomer message.) >=20 > swap_pager: out of swap space > swp_pager_getswapspace(18): failed > swap_pager: out of swap space > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(1): failed > swap_pager: out of swap space > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(7): failed > swp_pager_getswapspace(24): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(18): failed > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(12): failed > swp_pager_getswapspace(23): failed > swp_pager_getswapspace(30): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(2): failed >=20 > . . . Then a bunch of time with no messages . . . >=20 > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(28): failed >=20 > . . . Then a bunch of time with no messages . . . >=20 >=20 > Top again: >=20 > last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:31:26 21:31:55 > 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning > CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% idle > Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, 40960B = Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, 7820Mi = MaxObs(Act+Wir+Lndry) > ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, = 457631Ki Other > 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio > Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, 4096B = Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), 15993Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >=20 >=20 > I then used top to kill ninja and the 4 large compiles > that were going on. I'll change: >=20 > vm.pfault_oom_attempts > vm.pfault_oom_wait >=20 > and reboot and start over. >=20 >=20 > I expect that the ongoing UFS test will likely end up > similarly and that similar adjustments and restarts > will be needed because of actually running out of > swap space. >=20 I forgot to report: [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 [07:49:17] [01] [07:47:50] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build So the swap space filling happened somewhat before that much time had passed. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 06:35:51 2022 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 9438B197AD17 for ; Fri, 28 Jan 2022 06:36:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlSQZ34xbz4Zfs for ; Fri, 28 Jan 2022 06:36:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643351758; bh=T9GlqcB0Kbu7spTWb5t/067cnmcShKQygVfcW6SjCvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rH33nHmNQFGYFOt+QYdyz1kCguiLknzpYqRDUCuvoa6HlUP0mZKwVjxUfcMmEOYBpWWs7AQKeijIKJm0XRDNAlJxX7XTikxxA41/0mfDicgALw/E8cY2SMNHLYHIqFSWcoomXPhfjZd7NQ2z0ctr67w0PAhdjqQQZ9JfHS9P6QpxEKTfv2qELzZ6KbV7t8S6S+6Xtn1+9yE8S6zsi0DyOFIqhtih4Kr+nQo2CFZbRL/z6gbNX6spoWgPbShIN+hkWtLyomx9YjS3nYKWRo+g3pAOJllOkg67GrqY30d5XtfXNKoQ5YyLFdJXj7qLs7NPfAbGvpkn/kTxW1iwQScViQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643351758; bh=qY5m1zPBY/8Y55Fh9aJuJphQ30pm42365whlsKYaUMg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G4FbbSHUsdWXobi27zzLIQVuXwlUz8yIc2aSMTlUrwHWFiTa/fiBryAJNonNTCZtfhJIAP2Mg3c+dXqizV0ufE12O1kSr2B+VaVbpoduTx+YmVCGhpgLB909tqvGuki2v6jiQmPTlxHmN2JthHA6IOlP7ZiGfWvx2jfTzYC34CHjx09BfRVqSZmQ4GMQoFIZ3Q7lDdDlJabXgrbMqM70BVCv9EXOgBERk41Qde20iGcbpFA2Qjf1QhYGWGegVgPTQ2JxouaST6/IhAWyIUlkGmZKn5QT8oqRe2l4IUZlhiMpNWG8VEvELokb9ycZEqDP/2EcskY+gqbsvmsrns5TgQ== X-YMail-OSG: tOeUBD8VM1kjraXX1YpQQjRAGHbq0Q9kUcjLC7k.u0MpcDMGY2SZcjXmvfInhUz Ut2HT_8BT1idjxcXXThhlJrmSDuWdiMfLwiLHLTrGEhCUvtFJKXzqi3a6x7iYmSDMn4kFUskQ8Lm j7ZlFevDiBDBKMb3pndZEkc0iEj6pKCWdsGT_w6xiHhpk73wA.Hz3l9LNozlimJzcSEYKgToddhK gZZssGaxENWVLTI14628yykFcSnggh9W6ZhIM5Sz5vNWY.ENjN7eXJPTSTCbQp_xtmRjp.2NhVYg 2veISsrwtiNrBan2ccx90W55FYqKyMzwXN_HLpNpWdgi1fyrwbSgixhk3iicdXdqAgvljyyOOp.. .pw08amGBwRBBrpJaVKnExS22V_kru3FI1aO.t94JDR5bQMuzFRWwvehJvCmQ4vcp2gn.LlCWAE4 OGC7csjAi4EKVwNiqIfHtjc2WCOczPQni16ryX22o.d.1qN9sj4UkV5WieIo.mxpw7TvUrAhPNVm BLBzAkIzsXAdHKine2Ou.9VKDyKpMANAWwuUvWAthAQFUyEaEOZ8HNHVVTnRllA4xqdoBmsgAZAA M06o4Zm6gHT_ds47DEUvbW2naK7yS3y0tOE2SpP4HFcxdjs.Art4GkKNwWwOGOYVNKccaCns7kaF toshpDve6CYyaYkdWSYWIbrLv85g5cb0MBzM8o3BTZHlwEnurmwfChHlLBw_OAbqWQI.CHK6lC.x btJHAB2jnDGC_plg3yxjYfcry5vAo6jQSdPqo5B8I5c1mmiy3HU8.S5JEYEoUwHBtIfn0LxmuYc1 TH4gMogigyEB.ZxTLPYQ3XfHMv8chI9os5F2qUTmr4JKGiTfG8YJ6cMmTjEicRNOB3QRAaFKyvBx W7RAbZm5U9YC4j9jv0tw.0ubXbApgSk7cAKxVCZvJorvtgXGF0FxIQY3Y.0mIPiTonk8QsO6oK4t oQ9GVCM4sYvrkHZGrecWSt2OVINL26Fbl1pmT3aIixYvNXj5jnf1.AblIlHkQzVxqi4CFXr2d.S. KUq.zhFHmfzDJceTptTE_NkyR2y0pwHJx7fIor2Mcb_MXXuFv3n8r0MBMoU0XxYs6mprrW2C2d1. O0V_vs3lhwNPcFgGtktzx4v8JSZ53DIMBc0NOMQqkq.HeN9.zMgxYZyyS8ivcAS9p6GZDPtlm2CQ JjuMq8QmVtCjZVcZlt7JyOK9X3klz9TLd2HAsDW0gzYXDF2SStUycRJKlcpYEC81.MUPgDX671Wq _4jemME3acznfsyIXeWVR.7jD07PqsUXJMOSR.rrWQlnLmejND20i_KeLhP17FA8BHpZ7eQdDUxx zkxKjNMPftB.bIKM_aem41ocpIrCP8RLRZ.Ilomf4B72E0gS.5gyo62kZZDHzT1cmWQAaLOvDucD s3S122KMRqvgn_kLuFdkcort9lbcblu4yJ9C7u1xx5dnrLuMFYXxRYttm2o6koITsDIr1RGGzTBs Rn_NvzdQeU9qRi6..XW30TbDOEmhW5uWOEI_rNkpf7PtHTyZhRlReGDPUlAOYrTZCYpeEob.z9.g zwX7_6jQ5oDlafnTGSo8vTMsJEPPlSd38WzqgFTJ.RRcKzhNktuL7PzRxW6dWTmunfsyjhDTY9uJ 1mnAOpP3Lt6lMEvW2gOiwN1vNdwv0aiR_NRrKJy547OMUnZoz7joVCOHVm6tJ_tlFnSJcr7.u8F1 hRTb5qcpY4tRkxYSV6Tgg9Cm0iZMP_ocBnrVQpBTd6x0KgMD9poRZrzykl7IAM7iLfASr5KqWwsv Vcy3GWzlhtMBRUp_NeWz6N7eoS5a9eIDM0UwDyc3iMzU4UQVpIKKTWMC8eLbsF3LvW51sS52i1fU QsEr78bqpWkqrCZGSki3eZTeTk.02QxCSwsVqtH3zMnXRa5Xt0Vy5Pn58yns2Wa6j_eXTjp9qa6_ nYC_FMib.FNhf6ypTN3Rur5Wfrw9oqimhAqkLIB0ydfN6Z.y.nPNc1vVQfq.lMrIA4KGo9qk7spy V3Lxa21FQhP2Pj_hJGGbC5Qmex_qoTCWORQxd4849qVrNwvGesXeaCvJ2U2YUW912Hw6f7r.YyGs mhM0Ux882vG5TDp2k7zulSWnPA_BHnZLwVkyRKvFm01ZiK82hKFRdF68_BUBwaafs43D10.yugsk D6NTuhnVeaTJkosoaBkCdEp6or_jOwi__XxkUmP6MC4t68KIQerS09dJB3Fh06XjQa9SCiUk5WXK chLm0UeIHBfamLx1zGeGvXzNfmmEA4xxHcaCwdlrmzhgi0F2rgJ75layYyKThMW38rZjciUU4sl8 QbvdHZGAS6MRnn_l1 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 06:35:58 +0000 Received: by kubenode503.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e8c3f1cea59068fa4c9a039ee8d39f5b; Fri, 28 Jan 2022 06:35:53 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [ZFS context: used the whole swap space] From: Mark Millard In-Reply-To: <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> Date: Thu, 27 Jan 2022 22:35:51 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlSQZ34xbz4Zfs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rH33nHmN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9157 Lines: 248 [Back to omitting Mark Johnston.] On 2022-Jan-27, at 22:00, Mark Millard wrote: > On 2022-Jan-27, at 21:55, Mark Millard wrote: >=20 >> On 2022-Jan-27, at 17:43, Mark Millard wrote: >>=20 >>> On 2022-Jan-27, at 15:30, bob prohaska wrote: >>>=20 >>>> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>>>=20 >>>>> Okay. I just started a poudriere bulk devel/llvm13 build >>>>> in a ZFS context: >>>>>=20 >>>>> . . . >>>>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>>>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>>>> . . . >>>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>>>=20 >>>>=20 >>>> Is this ARM hardware, or an emulator? >>>=20 >>> 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content >>> is a slightly modified copy of the HoneyComb's PCIe slot Optane >>> media. >>>=20 >>> The UFS-based 8 GiByte RPi4B is also based on copying from the >>> same Optane media, both for the system materials and various >>> ports/packages/pouriere related materials. (Not, necessarily, >>> other things.) >>>=20 >>>> I've been using plain old make in /usr/ports/devel,=20 >>>> might it be informative to try a poudriere build as well? >>>=20 >>> The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) >>> output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D >>> and USE_TMPFS=3D"data" in use. >>>=20 >>> I have a context in which almost all prerequisites had already >>> been built. (The change in options lead to 2 very small ports >>> to build before devel/llvm13's started in a builder.) >>>=20 >>> (You might not have a jail that already has the prerequisites.) >>>=20 >>>> One would expect the added overhead to increase memory use. >>>>=20 >>>=20 >>> Well, from the context I started in, only devel/llvm13 is being >>> built once it starts. Once it gets to the build phase (after >>> dependencies and such are set up), there is not much overhead >>> because the only activity is the one builder and it is only >>> building llvm13 --via make in the builder. At the end there >>> would be extra activity as poudriere finishes up. During the >>> build phase, I only expect minor overhead from poudriere >>> monitoring the build logs and such. >>>=20 >>> I expect that the mere fact that a poudriere jail is in use >>> for the builder to execute in does not contribute to >>> significantly increasing the system's memory use or changing >>> the system's memory use pattern. >>>=20 >>>=20 >>> There are some other differences my context. The instances of >>> main [so: 14] are non-debug builds (but with symbols). The >>> builds are optimized for the RPi4B (and others) via use of >>> -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some >>> personal changes in it. (Some messaging about the kills is >>> part of that.) >>>=20 >>> The RPi4B's are using: >>>=20 >>> over_voltage=3D6=20 >>> arm_freq=3D2000=20 >>> sdram_freq_min=3D3200=20 >>> force_turbo=3D1=20 >>>=20 >>> (There are heat-sinks, fans, and good power supplies.) >>>=20 >>> The media in use are USB3 1 TB Samsung Portable SSD T7 >>> Touch's. I'm unlikely to see "swap_pager: indefinite >>> wait buffer:" notices if the cause was based on the >>> media performance. (You have spinning rust, if I >>> remember right.) >>>=20 >>> I do not have a monitoring script making a huge log file >>> during the build. So less is competing for media access >>> or leading to other overheads. (But, as I remember, >>> you have gotten the problem without having such a script >>> running.) >>=20 >>=20 >> ZFS context: >>=20 >> Well, the ZFS example used up all the swap space, according >> to my patched top. This means that my setting of >> vm.pfault_oom_attempts is not appropriate for this context: >>=20 >> # Delay when persistent low free RAM leads to >> # Out Of Memory killing of processes: >> vm.pageout_oom_seq=3D120 >> # >> # For plunty of swap/paging space (will not >> # run out), avoid pageout delays leading to >> # Out Of Memory killing of processes: >> vm.pfault_oom_attempts=3D-1 >> # >> # For possibly insufficient swap/paging space >> # (might run out), increase the pageout delay >> # that leads to Out Of Memory killing of >> # processes (showing defaults at the time): >> #vm.pfault_oom_attempts=3D 3 >> #vm.pfault_oom_wait=3D 10 >> # (The multiplication is the total but there >> # are other potential tradoffs in the factors >> # multiplied, even for nearly the same total.) >>=20 >> I'll need to retest with something more like the >> commented out vm.pfault_oom_attempts and >> vm.pfault_oom_wait figures in order to see the >> intended handling of the test case. >>=20 >> What are you using for each of: >> vm.pageout_oom_seq ? >> vm.pfault_oom_attempts ? >> vm.pfault_oom_wait ? >>=20 >>=20 >> For reference, for ZFS: >>=20 >> last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:23:14 21:23:43 >> 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning >> CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% = idle >> Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, = 40960B Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >> ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, 5994Ki = Header, 457626Ki Other >> 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio >> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, = 3436Ki Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >> Console: >> (Looks like I misremembered adjusting the "out of swap space" >> wording for the misnomer message.) >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(18): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(1): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(7): failed >> swp_pager_getswapspace(24): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(18): failed >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(12): failed >> swp_pager_getswapspace(23): failed >> swp_pager_getswapspace(30): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(2): failed >>=20 >> . . . Then a bunch of time with no messages . . . >>=20 >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(28): failed >>=20 >> . . . Then a bunch of time with no messages . . . >>=20 >>=20 >> Top again: >>=20 >> last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:31:26 21:31:55 >> 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning >> CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% = idle >> Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, 40960B = Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, 7820Mi = MaxObs(Act+Wir+Lndry) >> ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, = 457631Ki Other >> 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio >> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, = 4096B Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >>=20 >> I then used top to kill ninja and the 4 large compiles >> that were going on. I'll change: >>=20 >> vm.pfault_oom_attempts >> vm.pfault_oom_wait >>=20 >> and reboot and start over. >>=20 >>=20 >> I expect that the ongoing UFS test will likely end up >> similarly and that similar adjustments and restarts >> will be needed because of actually running out of >> swap space. >>=20 >=20 > I forgot to report: >=20 > [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [07:49:17] [01] [07:47:50] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >=20 > So the swap space filling happened somewhat before > that much time had passed. ZFS context: I will not start the next bulk until just before bed. I do not want it to fail while I'm not monitoring it. The last 4 reported compile starts reported in the log are: [ 64% 4725/7265] . . . flang/lib/Evaluate/fold.cpp [ 65% 4726/7265] . . . flang/lib/Evaluate/fold-character.cpp [ 65% 4727/7265] . . . flang/lib/Evaluate/check-expression.cpp [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp But it is possible one or more of these completed and some earlier one(s) was(were) still running. So, if you do not need the Fortran compiler, you can probably avoid the problem by setting the options for devel/llvm13 to not build flang. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 07:40:46 2022 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 B9C001972BA0 for ; Fri, 28 Jan 2022 07:40:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlTsM4HLRz3JNS for ; Fri, 28 Jan 2022 07:40:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643355654; bh=AqXbfveWzq60ydqov7Tll8pFjXiLrmOhXaBnJshgo+U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=H63NWpkicrXvhnmBh7Pap5PkEvcBSDAvNYpgdfHMAgcxFrHUwPb4dRpb5V3b1L96OJ8SfAJOdL/EYNpPtF2dy4CgT5FlZS8NEDU3eLYMzX509mx2+T+ZVBrXMqtfHyjL39rN5lYyJ7pBaSByOhZYWrjRPwMdEyfY7lSJxnH7Z34WxQrq3hd+FdOFurYT22FAMNSWe+RbOFT59jn2SGZOFzlMInnUpwQPLtkRG5u+Sg/JzWx8w9qPI9+ucJkJTYO2poBrhoyYAYz+eZBVZkIkf96mzMtZ0kv3LQ/ht/p51QGc7rK8xkbI6uqUAS3Z9gK2xKWj6lfu1NlrYdvWy9Q4JA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643355654; bh=GE8gnfi8HdxlUmn+Pd/BRSs1jAtoIZyQxHbIqmh6eus=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NpA6A27Bok4pzznnjHPicmjuMfXnX70TuTTlp/romnLmkP493bkAdpFnubqo0Tt9ZuF4RDc2IS4nvqSzxbRbXDDBIXIWElM67dh8vb27aSPDVnpiq2jMxMPDV0aoz2324L0XEUsaF3eiN85jPY9du2+mwNykGPmAS2xQ4hnmv71E5jFVnbDZRDJabdit5uhGY0VDIZT9uriH9Xx84bTCur0+kv4PUg/v8HkTyCryZnrC3eVzKAy1p/GuKi4sogbGc55iIbxLdgeP/g8PFWrCLdO9bNKkUtRyUVu79nXdrR5M0McbtzE2njp3tKhn9hUwpASNMtxNB0neZrW0mBRkUg== X-YMail-OSG: dzGLHY4VM1lOaXltYivZNXvtaNaYy5tEctJ9RgCp2xQfZ3msnPNVItHnpBOeUtn kmWqfi_RLTxcmYpx4QSsrms4fj2z_VoNjmUlWplNWBshEJBZsC6XiXdZNLRqjNHg8d8BB2k2y2Es VZxgj19Q_P_qjcCRUxBU4r4H3ISr7EB7f7UBCm35puN1m7X6S8mMIeNkcvKtYtK8I7SNx3QzUUtl 7GMargfeil7gGdeZVGRAcMj9UUw9pTrl47d5wNCs05Wd1XYl.JiELiAf0tTlvBOvjc3dhghC8In3 Vyw_Oo0xdSK78PkjilaQbQsAdXRW89o2H_12YivfVxlLV43ok69SA8WkAHmwX8jUGdm4QUOHtlpO qUerQEPyROtVLb8Iqx1ppZWV.bv2dcfDB.VOQregBmlYY6fKXIm2IbboXFRKsVHBdriqTN_wflOC U499XNGyHgyc3CfFeTUjK5yoi7MeisRR5sQx9HrjGo.C1cJWDrmLLcj3dhbo_RKyxs7BuEfOc2NH m9og3_H35ePBTAXOX.l2wT4yF.sKJKMNin71YvI_gG4tFGHtn7ryySNbTGEhOAFmvt3RfvAP7HRH z0XZemOspbxTRmeDYKTD4fGkyULnYGi0wMapDwhkAL2KZXubTxRPN_ChFmg0eYG5rCtpg5hFzszU agFWHIhAUMTVaqOJx_dUEvXaH3bbgxwFM7REtsmVBxRaVvVrHaIppNMdz2jVgyqEYP_taUF1fXHS 83qqk.IcS1syJwHltga2tXGT_i46Ph0teC1YEYwzBDU8uL3Uhs8s.h2vi85Q5S3tRP56ZUb0rQZO dhYMDmA6yeVrWv1wFQ5YguymKPPSE37z7ZUPugJuSftHRoMMVSUahukbhc3eVAg3EvKd471wEmRl PfLzA4mNjXC5so7cENHuOS7ZAwNRRBc_R2COhpww3uNJvPo7nYapi2KoiZGAL_qGtDdc6sTRpIxM hDfVF3GEoncAmsW8RjhU.0798FAS1EVnHY54NHDtWXDQLJqmifH3SCJDNn0BehJWSgNJRdLVkBG4 aobAxSucptDM6gVPnCA4OztasBcV6usCKrCCeO6QSS3AQZt1hSVkk05.PODu__KDuXeQhejokBBP qIJfr7H17Lv2gRY4L6fnZapUKCtMgWI71dNdSVy8cFZCawngy9AZ41QPaWds7s.crxIHQVbytXk6 7viAeQ9vS1hiCJLQHnBSS8wfdqturgUgKbpoSQ6QvMstIYp.prbAimroEpkdxojn8RAdt.UX39en qMup7fq3E8KUDI6MxZjtmeW9qDV3SoAmzLsO4Qo.cKme.C7ogQ1_U7s3HRlYkGqJ.PEvBjcyGxyW cCEVsZsiwY9Jrf2RCcsGUTWwHcDN4dsPHuZ8cUxODYARkiG.K9h8NppdB3yLn9vlkSh2xn1aNERz H0qdSW0.IEzVNH41J6X9VAVYDtgOPwSLF_PmJlzmFjUZGokqQb2hKXiOnFBiO7TtFlPJ0R5yP9gm O7g_Id1yJizx8dofslb9ZlUPYH_pBcOXyCoCbvURwc26xbZ8ryTY9whVTfiyonln2e12aKE7doX9 WsshGCO4CdHQqi4lp7ZF96_oj2DGi.95cDAXk3jMF0rnMYzewNpcYBMBEtEfDwgxm7L30GxOaOr3 3MUV0cS0cHdVUTCfYWJkDwmpwNvO9y3c7BsYIajHHcCRzf8.UCm6FG0XwS69FD3DsiZCyiEiJho. XrHdV5DnEnMHI87BI.8U41Gw5K.wLF9G7DXm7DegxkluVQC5jND_3NN1wnwFGfTZXTfzNgUAEwCA bZ6YhEqA.MftZv9Qb3yi98hoe9ZOI6UxZqP4IiFezXW3e.6qCskHsz9xovDEoBJLXPzByoNk4B4X ywzTzPbut4gWFZy5C7Vp9Yu1OJBxtRNwVzaKdtrnHEPazGzxYhiVYPh3x6fXqwZzvjIS18CSb.bq YsG98RHp1OaPtGfIISIcRBkTepZjviwE8bzPOcga.LhLaxoYL7Y98JvitxM9e4kxzYsbnBOQS97i 1oGPK2ijcVxlbpMCV7K2DM8Mq3aAu2jQuKUIgJe.OGq3u4Mz0_TkGmG79TZ7w5zthBlsKYhSJikt lg8OET2o63K3Li_NHhHXGZxO.59xm0toy5Njni7ckB194IAMNdbrcBL_NcAfWlbuX53afZhyc1YC gDM5LoVIifzKMfuDMRwIgNodQ1aYQQMmu_6I2rNzphkCloqdOa.kmdudBx.D7dKeNAIBpyMV4z21 0f71ZkjNraETDFSFqQKqZcGTcfTFNqZijWPwK7Ciw.5cGwVDpx1eOUuOfvxc1rYQOlz3Y6Foqklw cbScQJ8d20n_b0vD_ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 07:40:54 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e745345ca6d9965b1dc0f2d24813e5a1; Fri, 28 Jan 2022 07:40:48 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: Date: Thu, 27 Jan 2022 23:40:46 -0800 Cc: Free BSD , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlTsM4HLRz3JNS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=H63NWpki; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 13589 Lines: 381 [Mark Johnston included: handling was different than under ZFS.] On 2022-Jan-27, at 22:35, Mark Millard wrote: > [Back to omitting Mark Johnston.] >=20 > On 2022-Jan-27, at 22:00, Mark Millard wrote: >=20 >> On 2022-Jan-27, at 21:55, Mark Millard wrote: >>=20 >>> On 2022-Jan-27, at 17:43, Mark Millard wrote: >>>=20 >>>> On 2022-Jan-27, at 15:30, bob prohaska wrote: >>>>=20 >>>>> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>>>>=20 >>>>>> Okay. I just started a poudriere bulk devel/llvm13 build >>>>>> in a ZFS context: >>>>>>=20 >>>>>> . . . >>>>>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>>>>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>>>>> . . . >>>>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | = llvm13-13.0.0_3 >>>>>>=20 >>>>>=20 >>>>> Is this ARM hardware, or an emulator? >>>>=20 >>>> 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content >>>> is a slightly modified copy of the HoneyComb's PCIe slot Optane >>>> media. >>>>=20 >>>> The UFS-based 8 GiByte RPi4B is also based on copying from the >>>> same Optane media, both for the system materials and various >>>> ports/packages/pouriere related materials. (Not, necessarily, >>>> other things.) >>>>=20 >>>>> I've been using plain old make in /usr/ports/devel,=20 >>>>> might it be informative to try a poudriere build as well? >>>>=20 >>>> The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) >>>> output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D >>>> and USE_TMPFS=3D"data" in use. >>>>=20 >>>> I have a context in which almost all prerequisites had already >>>> been built. (The change in options lead to 2 very small ports >>>> to build before devel/llvm13's started in a builder.) >>>>=20 >>>> (You might not have a jail that already has the prerequisites.) >>>>=20 >>>>> One would expect the added overhead to increase memory use. >>>>>=20 >>>>=20 >>>> Well, from the context I started in, only devel/llvm13 is being >>>> built once it starts. Once it gets to the build phase (after >>>> dependencies and such are set up), there is not much overhead >>>> because the only activity is the one builder and it is only >>>> building llvm13 --via make in the builder. At the end there >>>> would be extra activity as poudriere finishes up. During the >>>> build phase, I only expect minor overhead from poudriere >>>> monitoring the build logs and such. >>>>=20 >>>> I expect that the mere fact that a poudriere jail is in use >>>> for the builder to execute in does not contribute to >>>> significantly increasing the system's memory use or changing >>>> the system's memory use pattern. >>>>=20 >>>>=20 >>>> There are some other differences my context. The instances of >>>> main [so: 14] are non-debug builds (but with symbols). The >>>> builds are optimized for the RPi4B (and others) via use of >>>> -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some >>>> personal changes in it. (Some messaging about the kills is >>>> part of that.) >>>>=20 >>>> The RPi4B's are using: >>>>=20 >>>> over_voltage=3D6=20 >>>> arm_freq=3D2000=20 >>>> sdram_freq_min=3D3200=20 >>>> force_turbo=3D1=20 >>>>=20 >>>> (There are heat-sinks, fans, and good power supplies.) >>>>=20 >>>> The media in use are USB3 1 TB Samsung Portable SSD T7 >>>> Touch's. I'm unlikely to see "swap_pager: indefinite >>>> wait buffer:" notices if the cause was based on the >>>> media performance. (You have spinning rust, if I >>>> remember right.) >>>>=20 >>>> I do not have a monitoring script making a huge log file >>>> during the build. So less is competing for media access >>>> or leading to other overheads. (But, as I remember, >>>> you have gotten the problem without having such a script >>>> running.) >>>=20 >>>=20 >>> ZFS context: >>>=20 >>> Well, the ZFS example used up all the swap space, according >>> to my patched top. This means that my setting of >>> vm.pfault_oom_attempts is not appropriate for this context: >>>=20 >>> # Delay when persistent low free RAM leads to >>> # Out Of Memory killing of processes: >>> vm.pageout_oom_seq=3D120 >>> # >>> # For plunty of swap/paging space (will not >>> # run out), avoid pageout delays leading to >>> # Out Of Memory killing of processes: >>> vm.pfault_oom_attempts=3D-1 >>> # >>> # For possibly insufficient swap/paging space >>> # (might run out), increase the pageout delay >>> # that leads to Out Of Memory killing of >>> # processes (showing defaults at the time): >>> #vm.pfault_oom_attempts=3D 3 >>> #vm.pfault_oom_wait=3D 10 >>> # (The multiplication is the total but there >>> # are other potential tradoffs in the factors >>> # multiplied, even for nearly the same total.) >>>=20 >>> I'll need to retest with something more like the >>> commented out vm.pfault_oom_attempts and >>> vm.pfault_oom_wait figures in order to see the >>> intended handling of the test case. >>>=20 >>> What are you using for each of: >>> vm.pageout_oom_seq ? >>> vm.pfault_oom_attempts ? >>> vm.pfault_oom_wait ? >>>=20 >>>=20 >>> For reference, for ZFS: >>>=20 >>> last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:23:14 21:23:43 >>> 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning >>> CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% = idle >>> Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, = 40960B Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>> ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, = 5994Ki Header, 457626Ki Other >>> 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio >>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, = 3436Ki Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>=20 >>> Console: >>> (Looks like I misremembered adjusting the "out of swap space" >>> wording for the misnomer message.) >>>=20 >>> swap_pager: out of swap space >>> swp_pager_getswapspace(18): failed >>> swap_pager: out of swap space >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(1): failed >>> swap_pager: out of swap space >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(7): failed >>> swp_pager_getswapspace(24): failed >>> swp_pager_getswapspace(3): failed >>> swp_pager_getswapspace(18): failed >>> swp_pager_getswapspace(17): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(12): failed >>> swp_pager_getswapspace(23): failed >>> swp_pager_getswapspace(30): failed >>> swp_pager_getswapspace(3): failed >>> swp_pager_getswapspace(2): failed >>>=20 >>> . . . Then a bunch of time with no messages . . . >>>=20 >>> swp_pager_getswapspace(5): failed >>> swp_pager_getswapspace(28): failed >>>=20 >>> . . . Then a bunch of time with no messages . . . >>>=20 >>>=20 >>> Top again: >>>=20 >>> last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:31:26 21:31:55 >>> 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning >>> CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% = idle >>> Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, = 40960B Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>> ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, = 457631Ki Other >>> 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio >>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, = 4096B Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>=20 >>>=20 >>> I then used top to kill ninja and the 4 large compiles >>> that were going on. I'll change: >>>=20 >>> vm.pfault_oom_attempts >>> vm.pfault_oom_wait >>>=20 >>> and reboot and start over. >>>=20 >>>=20 >>> I expect that the ongoing UFS test will likely end up >>> similarly and that similar adjustments and restarts >>> will be needed because of actually running out of >>> swap space. >>>=20 >>=20 >> I forgot to report: >>=20 >> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >> [07:49:17] [01] [07:47:50] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>=20 >> So the swap space filling happened somewhat before >> that much time had passed. >=20 > ZFS context: >=20 > I will not start the next bulk until just before bed. I do not > want it to fail while I'm not monitoring it. >=20 > The last 4 reported compile starts reported in the log are: >=20 > [ 64% 4725/7265] . . . flang/lib/Evaluate/fold.cpp > [ 65% 4726/7265] . . . flang/lib/Evaluate/fold-character.cpp > [ 65% 4727/7265] . . . flang/lib/Evaluate/check-expression.cpp > [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >=20 > But it is possible one or more of these completed and some > earlier one(s) was(were) still running. >=20 > So, if you do not need the Fortran compiler, you can probably > avoid the problem by setting the options for devel/llvm13 to > not build flang. UFS context: . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 . . . threads: . . ., 14 MaxObsRunning . . . Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi MaxObsUsed, = 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) Console: swap_pager: out of swap space swp_pager_getswapspace(4): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(7): failed swp_pager_getswapspace(29): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(10): failed . . . Then some time with no messages . . . vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory swp_pager_getswapspace(2): failed Note: The "vm_pageout_mightbe_oom: kill context:" notice is one of the few parts of an old reporting patch Mark J. had supplied (long ago) that still fits in the modern code (or that I was able to keep updated enough to fit, anyway). It is another of the personal updates that I keep in my source trees, such as in /usr/main-src/ . diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 36d5f3275800..f345e2d4a2d4 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int = page_shortage, * start OOM. Initiate the selection and signaling of the * victim. */ + printf("vm_pageout_mightbe_oom: kill context: v_free_count: %u, = v_inactive_count: %u\n", + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); vm_pageout_oom(VM_OOM_MEM); =20 /* Again, I'd used vm.pfault_oom_attempts inappropriately for running out of swap (although with UFS it did do a kill fairly soon): # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults at the time): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'll change: vm.pfault_oom_attempts vm.pfault_oom_wait and reboot --and start the bulk somewhat before going to bed. For reference: [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. Notably, the specific sources being compiled are different than in the ZFS context report. But this might be because of my killing ninja explicitly in the ZFS context, before killing the running compilers. Again, using the options to avoid building the Fortran compiler probably avoids such memory use --if you do not need the Fortran compiler. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 08:31:17 2022 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 CB9261972CEA for ; Fri, 28 Jan 2022 08:31:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlVzh5tGQz4R5N for ; Fri, 28 Jan 2022 08:31:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643358681; bh=HW1us+hyIrUq7Kqea4r6jVbizeNIAG5ukjavgitzPeQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z2wj8KyMaYLG3k6l1XaPgN6iRi4kQRJB/v6Ul006VtlcXJqShtVX11l4oyWFM9jxe4n45ScBoNFRTGdhSsPgz9bEbD6CKO17qIXkh0de1A8XJ5YjHbh7IQup4XAj1mly9ML4RIkoc+0TGbq6eIoL3x8iBQhXbKyjB6+BqgBHokXErUUwYtBMYlP8E5QFSvagzijSP3XsSdgdSx56FYHNlxvXulKtJ5XJukTpAaGgQjo2mOufGCI28yuRv75Vg0BkCkvFPygcfHZjY0+GBp/NI46b3jqre+IImqhU2dxl+PYOPFtKPZLWgzXXgIu/+2c81teJfWpcK3gJ9b8yqColIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643358681; bh=DF4mf5E+p+HSJ0tm6iIRtqRfOdn9IOATNFhDI4xxwTH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kWGVRDiHQJvPojF0IN04SPbjM7WA/CcHB6IrkTZvXEZl8qOpJaCxN9u8gpf1d8R7dmJg8tFjEFhYIkyZ5VTRVDRO9IC1KYAvG+nEcu2Wv343K3DE5Xum/Iwrk4q8UX1EvHUpPpLzYS3NbkdVVCiLfKfQRYXO5LWpwmCrkNjNvcsLT7W3SW4G2MPcHxfCgNDNI6IvV1K657Lj7tMXE35ZGjzTtwU5xFNZWpKHHnAYVwNZLr/hB9zwv9/3OU8T+OTA4OQv0BkYYjNL1+QDFsvoVBxDUzkOAJ2YC0YjVVljv1IU+0V4EdY3QSphVSavwSW8Hc4PMD8/Eiyu56zLXEzDjg== X-YMail-OSG: IXO1f3oVM1kpLSEY_n2iAt3nmXNNx80h6EyBcSTZZvAHDpeaiLBlWyIAHWHrJ50 I_Nt.KA16H6YYPBaGKBhoa7m8vq5BV9_CSZWM6qhB5uxhroyalShaqg5MTYgCJBdKkAq5Gvz5QEg xaDGCs7Pa8Jpz6WVrWaCNOs6QoOa7SjG8mCVOjER5RU6JhRITLBJNurtmWBBJ6ufjSrRA_1CshUK nHIVCz_dZcB603XofsANbs.eridhUVMeZLJYr2GQsgbnvTgFDAjhJCkTSfmd7My1D4YpTCdx3Ksq _MTUXI2DO0ofPxpvKw3HVHNH65QOrarTCQ12LSfDYs6s3P_zfRcZ_VFITIKfcmbBzaO0iI85hO0F nO7_dBYMd9hzvmTiIH7a_T9Nkicn5wxt3yrSLsXpaYU.hslf2e9IJjpjE5.g7T1tLn3IXMpxfVxh Kg292QsMFOr8ujNU4GpLTyEgn0ToNDf9MFy2rofFLSmecbom9Wqf.UD4FS7Kkeo_uuwmcIP0Ozmd f4eDQl30gQ.A7C.FDmFzX_XObLcV45O5x3Lx2OIDUfua4.YnRHm5FO_YX1OH_rCyjCjmVIz.Q2TS P_PVNw63fBmlFtHx_aH2gC9BeZ2XPIzocctnq0kEn.JDlbjsqQsOz8EI_aYfxm.it4K8rkz4BZlK cry2hicFSlMJdhSy9.Nr1Az.qGECp8gFnFMgfRUrOb.l7CDOjpD2bv9ruFgMZ1qbYi_S5_4Y51ZY VPNhRifuh3TcB2k.W_yERYOmURedmMvTZjxW8bM.Wp2BU9457rBHEG.jleoiB8O0A0YDBrAh250D 1Eu1KlwZsk2gWbKTHuTRqYx5_oSTlCx_zJ7JlQPxi4rvx9X9OeE734tPxc0phMiLntCjz5LBUnEl iaR3Bd0edGoCRGX9XAI_LayH4nejbwG5koC2tdsV1y_6s1wngc7k3gP4z1GASLuwAD.uyxuHwSzV UTJdICG8aQwZplUwbviaxF9P2Kv4673Ymi_CaLVwhecnH_UZgyJpUYKXbQiIvQuyuz14UK.Df34X Vd.k5FXtOJHY60qamx0gyryPxMcwBcGbGoYD0vsz3owYk7Mj1whyzWwrO_miaWTdj4Lakwb5t1KS .eWgGUEyZaj49uwNWcKkUQHS.C4h5OsR5t1WijkHx6IKS6oWjkqt5r2c7h7AjPrRO9EpCjVCLJhZ 6KVgFdI9Wyjes.3ahEWW4zDPrAlBOK3mdbJgdgpi5Ygyuo8l1fU6ZQoXx4LdDomJwb4XBpLKjW91 inV9MlDhtnoyyf34hEQCHMbozNKdEhWUVghv6eMDGPj2ABG0F7k4zVGXCfxAqt8DZVEq._LNBbF6 T2oH7FhIlrQ36irN.Zietli4lj.dA_ZaQVlmTiyDcTeBZ05Hd_CMCI6FdxpN8M38QyPewi2XzQeL EK4j5PKWLlDIwUGexZhuZ0a9hjt3mEIQZ9GapOX3ACSMRA3v5aBSQ_Anc.Vxxyqv.pXJHc4a27Ad lhhweBj7HWjNunWAzQNgyruwHdL_BLPcj43cnl97zhbDlo7h5mThFGKLI5H_t8pFZ_lQ1sEBXljC MxnjrtxguogNrbBV9ssv50bY6Dxa.sT01g1p5aPB3V69tR0MVbTXUuHaeZl.1kFcjiFllShQWXCw czum7pNOunRaKisZXc8MEsPl9Ycoune1VQFWvmMQ7PupCD1098KaJ08QI60wR_5tEA0UE61Iacjz iFuuFT0X6qxKwbHzgM9RLOXbs6k4wq18tJdHwoqPX7OucC1.hivOWCt4Z_R_oX1h7yRA6GpMhxkR RWx.IjFAbazft7Z2R6c5MUZG4j0sBJcTAmIBLuXbnsxMWfoYbBlXtM5bQq0khsq9OI9it86Qeb9i bwIUloyWPFZ6iUDR1ul2_kSiXpQqZ7OogwheWWVsqpacG30yM2dbslgREXHAvQQRAjHQxnfuoemD n.3Le6UMctpS8HyfTGEsBohgG98QeVg2xla5eepZHzbHpCYGfLjHybhj4pAmF4pBmM5K.75bTxPL HzLbI4.l4Flxtmd4dI_PGaWr0vjx1MQ7f6eodpbgqtgOwdef1TYWiK3_mjSU5cvlDHNYF19Hd9no ATwMMMJ7SQ8UD3KSojWL0P5GZ1n9B9IJc2Udd04qxQkkM6_uISxlEqmhfcseN5UdroxEofw2GM6n 9JRLIXwwR15ar_NhsI5bWHGUooFZNs9QcRaUMhA.AxRgu4Uy.pZ0DRQUXj7Zxqd31B0SarKMxiqO DFCq1t3rABLsS4v4NMC2bnWoXhVly8viBsjIcAUovD1eHd7tmdOKLCn6hKkPI4VpRrJPP86zt1BN MNdhuuV07JDm1FOvpj8yS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 08:31:21 +0000 Received: by kubenode532.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 31060fbf1cdb7c6e10c9c83864a016b1; Fri, 28 Jan 2022 08:31:18 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> Date: Fri, 28 Jan 2022 00:31:17 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlVzh5tGQz4R5N X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Z2wj8KyM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 16077 Lines: 447 [Back to omitting Mark Johnston.] On 2022-Jan-27, at 23:40, Mark Millard wrote: > [Mark Johnston included: handling was different than under ZFS.] >=20 > On 2022-Jan-27, at 22:35, Mark Millard wrote: >=20 >> [Back to omitting Mark Johnston.] >>=20 >> On 2022-Jan-27, at 22:00, Mark Millard wrote: >>=20 >>> On 2022-Jan-27, at 21:55, Mark Millard wrote: >>>=20 >>>> On 2022-Jan-27, at 17:43, Mark Millard wrote: >>>>=20 >>>>> On 2022-Jan-27, at 15:30, bob prohaska wrote: >>>>>=20 >>>>>> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>>>>>=20 >>>>>>> Okay. I just started a poudriere bulk devel/llvm13 build >>>>>>> in a ZFS context: >>>>>>>=20 >>>>>>> . . . >>>>>>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>>>>>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>>>>>> . . . >>>>>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | = llvm13-13.0.0_3 >>>>>>>=20 >>>>>>=20 >>>>>> Is this ARM hardware, or an emulator? >>>>>=20 >>>>> 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content >>>>> is a slightly modified copy of the HoneyComb's PCIe slot Optane >>>>> media. >>>>>=20 >>>>> The UFS-based 8 GiByte RPi4B is also based on copying from the >>>>> same Optane media, both for the system materials and various >>>>> ports/packages/pouriere related materials. (Not, necessarily, >>>>> other things.) >>>>>=20 >>>>>> I've been using plain old make in /usr/ports/devel,=20 >>>>>> might it be informative to try a poudriere build as well? >>>>>=20 >>>>> The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) >>>>> output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D >>>>> and USE_TMPFS=3D"data" in use. >>>>>=20 >>>>> I have a context in which almost all prerequisites had already >>>>> been built. (The change in options lead to 2 very small ports >>>>> to build before devel/llvm13's started in a builder.) >>>>>=20 >>>>> (You might not have a jail that already has the prerequisites.) >>>>>=20 >>>>>> One would expect the added overhead to increase memory use. >>>>>>=20 >>>>>=20 >>>>> Well, from the context I started in, only devel/llvm13 is being >>>>> built once it starts. Once it gets to the build phase (after >>>>> dependencies and such are set up), there is not much overhead >>>>> because the only activity is the one builder and it is only >>>>> building llvm13 --via make in the builder. At the end there >>>>> would be extra activity as poudriere finishes up. During the >>>>> build phase, I only expect minor overhead from poudriere >>>>> monitoring the build logs and such. >>>>>=20 >>>>> I expect that the mere fact that a poudriere jail is in use >>>>> for the builder to execute in does not contribute to >>>>> significantly increasing the system's memory use or changing >>>>> the system's memory use pattern. >>>>>=20 >>>>>=20 >>>>> There are some other differences my context. The instances of >>>>> main [so: 14] are non-debug builds (but with symbols). The >>>>> builds are optimized for the RPi4B (and others) via use of >>>>> -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some >>>>> personal changes in it. (Some messaging about the kills is >>>>> part of that.) >>>>>=20 >>>>> The RPi4B's are using: >>>>>=20 >>>>> over_voltage=3D6=20 >>>>> arm_freq=3D2000=20 >>>>> sdram_freq_min=3D3200=20 >>>>> force_turbo=3D1=20 >>>>>=20 >>>>> (There are heat-sinks, fans, and good power supplies.) >>>>>=20 >>>>> The media in use are USB3 1 TB Samsung Portable SSD T7 >>>>> Touch's. I'm unlikely to see "swap_pager: indefinite >>>>> wait buffer:" notices if the cause was based on the >>>>> media performance. (You have spinning rust, if I >>>>> remember right.) >>>>>=20 >>>>> I do not have a monitoring script making a huge log file >>>>> during the build. So less is competing for media access >>>>> or leading to other overheads. (But, as I remember, >>>>> you have gotten the problem without having such a script >>>>> running.) >>>>=20 >>>>=20 >>>> ZFS context: >>>>=20 >>>> Well, the ZFS example used up all the swap space, according >>>> to my patched top. This means that my setting of >>>> vm.pfault_oom_attempts is not appropriate for this context: >>>>=20 >>>> # Delay when persistent low free RAM leads to >>>> # Out Of Memory killing of processes: >>>> vm.pageout_oom_seq=3D120 >>>> # >>>> # For plunty of swap/paging space (will not >>>> # run out), avoid pageout delays leading to >>>> # Out Of Memory killing of processes: >>>> vm.pfault_oom_attempts=3D-1 >>>> # >>>> # For possibly insufficient swap/paging space >>>> # (might run out), increase the pageout delay >>>> # that leads to Out Of Memory killing of >>>> # processes (showing defaults at the time): >>>> #vm.pfault_oom_attempts=3D 3 >>>> #vm.pfault_oom_wait=3D 10 >>>> # (The multiplication is the total but there >>>> # are other potential tradoffs in the factors >>>> # multiplied, even for nearly the same total.) >>>>=20 >>>> I'll need to retest with something more like the >>>> commented out vm.pfault_oom_attempts and >>>> vm.pfault_oom_wait figures in order to see the >>>> intended handling of the test case. >>>>=20 >>>> What are you using for each of: >>>> vm.pageout_oom_seq ? >>>> vm.pfault_oom_attempts ? >>>> vm.pfault_oom_wait ? >>>>=20 >>>>=20 >>>> For reference, for ZFS: >>>>=20 >>>> last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:23:14 21:23:43 >>>> 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning >>>> CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% = idle >>>> Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, = 40960B Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>>> ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, = 5994Ki Header, 457626Ki Other >>>> 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio >>>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, = 3436Ki Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>>=20 >>>> Console: >>>> (Looks like I misremembered adjusting the "out of swap space" >>>> wording for the misnomer message.) >>>>=20 >>>> swap_pager: out of swap space >>>> swp_pager_getswapspace(18): failed >>>> swap_pager: out of swap space >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(1): failed >>>> swap_pager: out of swap space >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(7): failed >>>> swp_pager_getswapspace(24): failed >>>> swp_pager_getswapspace(3): failed >>>> swp_pager_getswapspace(18): failed >>>> swp_pager_getswapspace(17): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(12): failed >>>> swp_pager_getswapspace(23): failed >>>> swp_pager_getswapspace(30): failed >>>> swp_pager_getswapspace(3): failed >>>> swp_pager_getswapspace(2): failed >>>>=20 >>>> . . . Then a bunch of time with no messages . . . >>>>=20 >>>> swp_pager_getswapspace(5): failed >>>> swp_pager_getswapspace(28): failed >>>>=20 >>>> . . . Then a bunch of time with no messages . . . >>>>=20 >>>>=20 >>>> Top again: >>>>=20 >>>> last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:31:26 21:31:55 >>>> 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning >>>> CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% = idle >>>> Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, = 40960B Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>>> ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, = 457631Ki Other >>>> 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio >>>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, = 4096B Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>>=20 >>>>=20 >>>> I then used top to kill ninja and the 4 large compiles >>>> that were going on. I'll change: >>>>=20 >>>> vm.pfault_oom_attempts >>>> vm.pfault_oom_wait >>>>=20 >>>> and reboot and start over. >>>>=20 >>>>=20 >>>> I expect that the ongoing UFS test will likely end up >>>> similarly and that similar adjustments and restarts >>>> will be needed because of actually running out of >>>> swap space. >>>>=20 >>>=20 >>> I forgot to report: >>>=20 >>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>> [07:49:17] [01] [07:47:50] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>>=20 >>> So the swap space filling happened somewhat before >>> that much time had passed. >>=20 >> ZFS context: >>=20 >> I will not start the next bulk until just before bed. I do not >> want it to fail while I'm not monitoring it. >>=20 >> The last 4 reported compile starts reported in the log are: >>=20 >> [ 64% 4725/7265] . . . flang/lib/Evaluate/fold.cpp >> [ 65% 4726/7265] . . . flang/lib/Evaluate/fold-character.cpp >> [ 65% 4727/7265] . . . flang/lib/Evaluate/check-expression.cpp >> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >>=20 >> But it is possible one or more of these completed and some >> earlier one(s) was(were) still running. >>=20 >> So, if you do not need the Fortran compiler, you can probably >> avoid the problem by setting the options for devel/llvm13 to >> not build flang. >=20 > UFS context: >=20 > . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 > . . . threads: . . ., 14 MaxObsRunning > . . . > Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) > Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >=20 >=20 > Console: >=20 > swap_pager: out of swap space > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(7): failed > swp_pager_getswapspace(29): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(10): failed >=20 > . . . Then some time with no messages . . . >=20 > vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 > Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory > swp_pager_getswapspace(2): failed >=20 >=20 > Note: The "vm_pageout_mightbe_oom: kill context:" > notice is one of the few parts of an old reporting > patch Mark J. had supplied (long ago) that still > fits in the modern code (or that I was able to keep > updated enough to fit, anyway). It is another of the > personal updates that I keep in my source trees, > such as in /usr/main-src/ . >=20 > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 36d5f3275800..f345e2d4a2d4 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, > * start OOM. Initiate the selection and signaling of the > * victim. > */ > + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", > + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); > vm_pageout_oom(VM_OOM_MEM); >=20 > /* >=20 >=20 > Again, I'd used vm.pfault_oom_attempts inappropriately > for running out of swap (although with UFS it did do > a kill fairly soon): >=20 > # Delay when persistent low free RAM leads to > # Out Of Memory killing of processes: > vm.pageout_oom_seq=3D120 > # > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > vm.pfault_oom_attempts=3D-1 > # > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes (showing defaults at the time): > #vm.pfault_oom_attempts=3D 3 > #vm.pfault_oom_wait=3D 10 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied, even for nearly the same total.) >=20 > I'll change: >=20 > vm.pfault_oom_attempts > vm.pfault_oom_wait >=20 > and reboot --and start the bulk somewhat before > going to bed. >=20 >=20 > For reference: >=20 > [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >=20 >=20 > [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp > FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >=20 > So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >=20 > Notably, the specific sources being compiled are different > than in the ZFS context report. But this might be because > of my killing ninja explicitly in the ZFS context, before > killing the running compilers. >=20 > Again, using the options to avoid building the Fortran > compiler probably avoids such memory use --if you do not > need the Fortran compiler. >=20 Notes on the 2 types of "out of swap space" notices in the main [so: 14] code: One place that can lead to a variation of such notices is: void vm_pageout_oom(int shortage) { . . . if (bigproc !=3D NULL) { switch (shortage) { case VM_OOM_MEM: reason =3D "failed to reclaim memory"; break; case VM_OOM_MEM_PF: reason =3D "a thread waited too long to allocate = a page"; break; case VM_OOM_SWAPZ: reason =3D "out of swap space"; break; default: panic("unknown OOM reason %d", shortage); } if (vm_panic_on_oom !=3D 0 && --vm_panic_on_oom =3D=3D = 0) panic("%s", reason); PROC_LOCK(bigproc); killproc(bigproc, reason); . . . } It is the VM_OOM_SWAPZ path that produces the misnomer text during killproc(bigproc, reason) . But there is another place that produces an accurate message that does not, of itself, mention kills: static void swp_sizecheck(void) { =20 if (swap_pager_avail < nswap_lowat) { if (swap_pager_almost_full =3D=3D 0) { printf("swap_pager: out of swap space\n"); swap_pager_almost_full =3D 1; } } else { swap_pager_full =3D 0; if (swap_pager_avail > nswap_hiwat) swap_pager_almost_full =3D 0; } } It looks like you were getting the 2nd (accurate) form of message generation. At this point kills have not started and the message is not about kills at all. Thus my initial notes about misnomer messages for your specific context were wrong. Sorry. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 15:16:30 2022 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 691A41975AA6 for ; Fri, 28 Jan 2022 15:16:41 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlgzD2kNXz4TD5 for ; Fri, 28 Jan 2022 15:16:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643382993; bh=oFNwHvgRPm3tLSaoDWoj+lV2MRV/Ok+7r4fawj6Q2QA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UxrilVx9k/AOxOxvY619s4nMu/mcqs9YZqjKedyGLDcFIrlX7MAob6MAimnntEyLCzHwbWLcg2WVV1JFCS9VntOD5Qs6yG6JMOs5PRQnRLkBXgkrNPj5+50ZPY0YZ/GK74hzBSiIqA+m+hGt+RsyZezAcrHnOVMi5xCvfduTVvbWNu7+sY8cy4U+KOYJdOnm1m91pjT60rUHWG7yKmEuqaCY0Izt+VLiVR2/0JdgIdwIoAnc59JGgTxjz9mhWjFNqLpwSV5/O0wHSWfBMwBkcMf3jGPNpfpMiFGLAIUS9rQZTG1l0/oawQVGwSa88ZMnFEueDkN/v7eBLvKmINMfUA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643382993; bh=WPzibjtnrr6O+6/DZZODN/LSalxUakRcTzD7LMUcyss=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=quPE+jvQDdFQ/yjB6A0RoZ4lv/QmxIxGZDfMXspsl4z64iITaZXb5Gmo87ahNCpoNuupfi+t5ZI3fuTjjCX7JBbDUQ9xWaquUICR9VD3rOBOc0fJamSa7EI55gjAJj+2NGRYsCRJPgavzAci7kEDJWHJ+Zc3bCSfn5R0sTGGXR77Q9KAnHTVci8rRQv62w6bwH4dQOFyV6F8TsaNjGsRv/0mKF5UYw9+EUePrD05ZrO37Q5qtV1xOYTYm/aC6vFDqgr2ivcEGO7pfSbY5Zbzl1Wg9/IkQPaaXm94fc5n3zvrEBoPfZp1JPKxHqQUQkh8gSlBhw5jGrvSPGi8l0pJ3w== X-YMail-OSG: .0.BSgIVM1lh_nWuDGheSyPXwHkTEniWLvyduxZd8.dYuw.qFJBH_TdTlZhG7hF sTLxoDQtFdl7KjKmell.aOInOiCXZJbmz_B88OYQ15ft2paDuPmd4bWwfbvlOlno55Ct76lW.EgE wyoFVYEeyLqZH42FpNXFbi8XEj6jwlWs8Slh9roc8CK.ntH2tS.NbhzoN_ISYJWk2aIiyLCVu2Bu MtIWCbNU5dTnzegErWIePNi792Rvh3QKYtB9YRxWwXocIRKbrdCMk6T1_HMDXTFdWopm8u9wixfn kUrkBO4egqkZPMT11yxegqfD6gxK9WYFTxF1y8D2vTVsaWuXe_WaxbcWrLWOS_nFYYlABgx_.GQM lp8O4lOZeDbVuPbT0RKNnZfOraoApLl1myx3m2pG893zJcLayExmnKhoce2xFdet1wofOSuj_.8c Up4Rjdm3TAsziArYTton_pfQkkRgeVlxi9g73tvYmUmF1iprrwUrFaX4ulo2EmIJw0ejkppen20I 7nGTXmCMsLLYzc_MYwLypyCGJNVFgfkBe3ZGQ7RPkBOzWTcfTMCBSYoKXgJ6JWJf7BFoRzAifzTz cmLI_iOnJDhdGShV_6Z_aQljp6IjAH_7OKyXeJh7AVECYQz53ZBh2HUCST5A003uqqWF5HAZhf2X VfBUP4oKaZDmNT8wFIF_0Jm8AtWTLCJwqHJ5BHd30UthYjE9R54Q5WAWgV2ZEKlywcc.Hs333mFo d7VnLaNgpCEaH1WGIccbsae415H2GAy0GR7zGfXFwrb7r3AUqLDbIwKdrL0LvOTuVc7sgBHNDBDA VSXQukx.UFOw_5hkIUhqACKNFBhw74mmSjAqM7PX9biBMSmhZlsz7.w8vXiKR8M_7XePeap8xCY_ 1N6pY_FugnbIYSz9hv3lUdtRkz6Ysjf9590FbY.RNZodh1TzjQZV1zPLDe6UFwug.XjwVdx2YFf8 _sveUnFa6RizmsfpS6Q5K7Nrok73ZHJYKO5DKV8HlFFBX18K.LBDkHPm5QySfTzxvQS8uaANkdu2 urHFyBfsaMuydFED6hzwGtItZJkH0lTZxgNC6zXEFD4B83uowhF8s4bACLjwEunTlMV90xoct4Ih 4y1Vjrg1UxtTNPYObLUeMQXziQiWoWp5mlwT4K.WPk9EbOTyAOB28PmUuaYAMmkbIfYsYbNJ7Cd3 47c_FsJAJNBQCBPZUqiATwq0UCMUiZxeKlUPud4OQwnFdMGHbvcx80QBoihyjAQq_tNzV1IEye9M tN_1VnqsJZGkRc5QytRMDIjSkacwM09GaSgpQMeZre3IclXWq_HWRQ85wCtynYuhOzzWJW4ZkynB aVcc6oA9B4_fXRhZYyOAK3.S3QPGqRkiuZ4KdCy03EA2nfkvMpaOFUXmbGFFA5WuyuRO8ErhhlnU nlhRcMLjSbjWPTCD1.LJ_H0j9pWbvDT9.3x.ikkTCOt4OMgO.1HEEsdV..67ZuP7A.StVdIauciE x1BUUrM5AVH2FujpxH57NuWVe4SqDE7nj1mAbo3M2Ab._Iq6zeOcvH1rMScCvR2y2cIlfmjMlTAo s7YELgpZtnaFubWx69qssr2zk.qT39LtU6Fq7xZwQ0ICFol7aih7MYJ2vI2BFeKAfgMlq_ncqWQM 9rFxRpyg_XOCuGdX1j0W1gTCXYVb6FtMjNpvWP4xYwskPz6QHknlRMBg8p0AJFei3Y66gV4F6lrU QKvMPOTuP1CxwrU4us9eRESRbNxT81624noJvFQeJWigz2jWGQDaqPiyu0PG0oHu4uO0DqMNY1Ld 3ESjh_Wa8Cx9qxSInnlirJqVHVAb1RlVBHY5s9Upk7gL17SG25aWBQpFMpo4OHBmvYgcL5TKsZ5b zvMPv64YBQVb02MD77aCuursz5.5JlIsyGGsqz8a8rpl4_TktcHz5f4dJUhgn1HL0r.O5iVF0dRe AaD.X5Th88MYmmkiXwF29rb0uI8i_65Dk9C3QIySWe9RZcn34idiET3ZDyLd2fxvxoc9xqU5EnI9 Y4ruTvOmy3CjqX8izleKWWhYANWQsxops_3yjb0iutm5yj5gk6WERj6rnppsxcOdjbx14ZcR5Dfv 3O4X2rwq4edUo6hmBOeL7F3qERb3ACdKtzOEKK8oSEQI91H0DrXS8d8mzu5uA9yvgh6wjdzE93Zw Pi4LawQa0_Wy0fNck16kSn3hZsANVuGvJVwpqOOZ7vDESty1oOxPDcZYWJdkbkfL3Ydl4FSXZgLZ EA7kvc5OJOpveT0wPDQW7Df9.vc2gKOEAfwvNubvzKRj2kuPNY0KNWx1HSSl2KesIVoH5yZl9aLA drvaqqXJ3LIr_P54Yvec- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 15:16:33 +0000 Received: by kubenode527.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 55f93c5ffe246bf30fdba9c3435fa7dc; Fri, 28 Jan 2022 15:16:31 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: Date: Fri, 28 Jan 2022 07:16:30 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlgzD2kNXz4TD5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UxrilVx9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.986]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 16780 Lines: 455 On 2022-Jan-28, at 00:31, Mark Millard wrote: > [Back to omitting Mark Johnston.] >=20 > On 2022-Jan-27, at 23:40, Mark Millard wrote: >=20 >> [Mark Johnston included: handling was different than under ZFS.] >>=20 >> On 2022-Jan-27, at 22:35, Mark Millard wrote: >>=20 >>> [Back to omitting Mark Johnston.] >>>=20 >>> On 2022-Jan-27, at 22:00, Mark Millard wrote: >>>=20 >>>> On 2022-Jan-27, at 21:55, Mark Millard wrote: >>>>=20 >>>>> On 2022-Jan-27, at 17:43, Mark Millard wrote: >>>>>=20 >>>>>> On 2022-Jan-27, at 15:30, bob prohaska = wrote: >>>>>>=20 >>>>>>> On Thu, Jan 27, 2022 at 02:21:44PM -0800, Mark Millard wrote: >>>>>>>>=20 >>>>>>>> Okay. I just started a poudriere bulk devel/llvm13 build >>>>>>>> in a ZFS context: >>>>>>>>=20 >>>>>>>> . . . >>>>>>>> [00:00:37] Pkg: +BE_AMDGPU -BE_FREEBSD +BE_NATIVE -BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS -FLANG +LIT +LLD +LLDB +MLIR -OPENMP = -PYCLANG >>>>>>>> [00:00:37] New: +BE_AMDGPU -BE_FREEBSD -BE_NATIVE +BE_STANDARD = +BE_WASM +CLANG +DOCS +EXTRAS +FLANG +LIT +LLD +LLDB +MLIR +OPENMP = +PYCLANG >>>>>>>> . . . >>>>>>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | = llvm13-13.0.0_3 >>>>>>>>=20 >>>>>>>=20 >>>>>>> Is this ARM hardware, or an emulator? >>>>>>=20 >>>>>> 8 GiByte RPi4B, USB3 NVMe media with a ZFS partition. The content >>>>>> is a slightly modified copy of the HoneyComb's PCIe slot Optane >>>>>> media. >>>>>>=20 >>>>>> The UFS-based 8 GiByte RPi4B is also based on copying from the >>>>>> same Optane media, both for the system materials and various >>>>>> ports/packages/pouriere related materials. (Not, necessarily, >>>>>> other things.) >>>>>>=20 >>>>>>> I've been using plain old make in /usr/ports/devel,=20 >>>>>>> might it be informative to try a poudriere build as well? >>>>>>=20 >>>>>> The Pkg:, New:, and llvm13 lines I listed are poudriere(-devel) >>>>>> output. I am doing my builds via poudriere. ALLOW_PARALLEL_JOBS=3D >>>>>> and USE_TMPFS=3D"data" in use. >>>>>>=20 >>>>>> I have a context in which almost all prerequisites had already >>>>>> been built. (The change in options lead to 2 very small ports >>>>>> to build before devel/llvm13's started in a builder.) >>>>>>=20 >>>>>> (You might not have a jail that already has the prerequisites.) >>>>>>=20 >>>>>>> One would expect the added overhead to increase memory use. >>>>>>>=20 >>>>>>=20 >>>>>> Well, from the context I started in, only devel/llvm13 is being >>>>>> built once it starts. Once it gets to the build phase (after >>>>>> dependencies and such are set up), there is not much overhead >>>>>> because the only activity is the one builder and it is only >>>>>> building llvm13 --via make in the builder. At the end there >>>>>> would be extra activity as poudriere finishes up. During the >>>>>> build phase, I only expect minor overhead from poudriere >>>>>> monitoring the build logs and such. >>>>>>=20 >>>>>> I expect that the mere fact that a poudriere jail is in use >>>>>> for the builder to execute in does not contribute to >>>>>> significantly increasing the system's memory use or changing >>>>>> the system's memory use pattern. >>>>>>=20 >>>>>>=20 >>>>>> There are some other differences my context. The instances of >>>>>> main [so: 14] are non-debug builds (but with symbols). The >>>>>> builds are optimized for the RPi4B (and others) via use of >>>>>> -mcpu=3Dcortex-a72 usage. My /usr/main-src/ does have some >>>>>> personal changes in it. (Some messaging about the kills is >>>>>> part of that.) >>>>>>=20 >>>>>> The RPi4B's are using: >>>>>>=20 >>>>>> over_voltage=3D6=20 >>>>>> arm_freq=3D2000=20 >>>>>> sdram_freq_min=3D3200=20 >>>>>> force_turbo=3D1=20 >>>>>>=20 >>>>>> (There are heat-sinks, fans, and good power supplies.) >>>>>>=20 >>>>>> The media in use are USB3 1 TB Samsung Portable SSD T7 >>>>>> Touch's. I'm unlikely to see "swap_pager: indefinite >>>>>> wait buffer:" notices if the cause was based on the >>>>>> media performance. (You have spinning rust, if I >>>>>> remember right.) >>>>>>=20 >>>>>> I do not have a monitoring script making a huge log file >>>>>> during the build. So less is competing for media access >>>>>> or leading to other overheads. (But, as I remember, >>>>>> you have gotten the problem without having such a script >>>>>> running.) >>>>>=20 >>>>>=20 >>>>> ZFS context: >>>>>=20 >>>>> Well, the ZFS example used up all the swap space, according >>>>> to my patched top. This means that my setting of >>>>> vm.pfault_oom_attempts is not appropriate for this context: >>>>>=20 >>>>> # Delay when persistent low free RAM leads to >>>>> # Out Of Memory killing of processes: >>>>> vm.pageout_oom_seq=3D120 >>>>> # >>>>> # For plunty of swap/paging space (will not >>>>> # run out), avoid pageout delays leading to >>>>> # Out Of Memory killing of processes: >>>>> vm.pfault_oom_attempts=3D-1 >>>>> # >>>>> # For possibly insufficient swap/paging space >>>>> # (might run out), increase the pageout delay >>>>> # that leads to Out Of Memory killing of >>>>> # processes (showing defaults at the time): >>>>> #vm.pfault_oom_attempts=3D 3 >>>>> #vm.pfault_oom_wait=3D 10 >>>>> # (The multiplication is the total but there >>>>> # are other potential tradoffs in the factors >>>>> # multiplied, even for nearly the same total.) >>>>>=20 >>>>> I'll need to retest with something more like the >>>>> commented out vm.pfault_oom_attempts and >>>>> vm.pfault_oom_wait figures in order to see the >>>>> intended handling of the test case. >>>>>=20 >>>>> What are you using for each of: >>>>> vm.pageout_oom_seq ? >>>>> vm.pfault_oom_attempts ? >>>>> vm.pfault_oom_wait ? >>>>>=20 >>>>>=20 >>>>> For reference, for ZFS: >>>>>=20 >>>>> last pid: 380; load averages: 1.50, 3.07, 3.93 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:23:14 21:23:43 >>>>> 68 threads: 1 running, 65 sleeping, 2 waiting, 19 MaxObsRunning >>>>> CPU: 13.3% user, 0.0% nice, 4.9% system, 0.9% interrupt, 80.8% = idle >>>>> Mem: 4912Mi Active, 167936B Inact, 1193Mi Laundry, 1536Mi Wired, = 40960B Buf, 33860Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>>>> ARC: 777086Ki Total, 132156Ki MFU, 181164Ki MRU, 147456B Anon, = 5994Ki Header, 457626Ki Other >>>>> 59308Ki Compressed, 254381Ki Uncompressed, 4.29:1 Ratio >>>>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 19572Ki In, = 3436Ki Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>>>=20 >>>>> Console: >>>>> (Looks like I misremembered adjusting the "out of swap space" >>>>> wording for the misnomer message.) >>>>>=20 >>>>> swap_pager: out of swap space >>>>> swp_pager_getswapspace(18): failed >>>>> swap_pager: out of swap space >>>>> swp_pager_getswapspace(1): failed >>>>> swp_pager_getswapspace(1): failed >>>>> swap_pager: out of swap space >>>>> swp_pager_getswapspace(1): failed >>>>> swp_pager_getswapspace(7): failed >>>>> swp_pager_getswapspace(24): failed >>>>> swp_pager_getswapspace(3): failed >>>>> swp_pager_getswapspace(18): failed >>>>> swp_pager_getswapspace(17): failed >>>>> swp_pager_getswapspace(1): failed >>>>> swp_pager_getswapspace(12): failed >>>>> swp_pager_getswapspace(23): failed >>>>> swp_pager_getswapspace(30): failed >>>>> swp_pager_getswapspace(3): failed >>>>> swp_pager_getswapspace(2): failed >>>>>=20 >>>>> . . . Then a bunch of time with no messages . . . >>>>>=20 >>>>> swp_pager_getswapspace(5): failed >>>>> swp_pager_getswapspace(28): failed >>>>>=20 >>>>> . . . Then a bunch of time with no messages . . . >>>>>=20 >>>>>=20 >>>>> Top again: >>>>>=20 >>>>> last pid: 382; load averages: 0.73, 1.00, 2.40 MaxObs: = 5.71, 4.92, 4.76 = up 0+07:31:26 21:31:55 >>>>> 70 threads: 1 running, 65 sleeping, 4 waiting, 19 MaxObsRunning >>>>> CPU: 0.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 94.3% = idle >>>>> Mem: 3499Mi Active, 4096B Inact, 2612Mi Laundry, 1457Mi Wired, = 40960B Buf, 34676Ki Free, 6179Mi MaxObsActive, 6476Mi MaxObsWired, = 7820Mi MaxObs(Act+Wir+Lndry) >>>>> ARC: 777154Ki Total, 135196Ki MFU, 178330Ki MRU, 5995Ki Header, = 457631Ki Other >>>>> 59520Ki Compressed, 254231Ki Uncompressed, 4.27:1 Ratio >>>>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 409600B In, = 4096B Out, 8192Mi MaxObsUsed, 14458Mi MaxObs(Act+Lndry+SwapUsed), = 15993Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>>>=20 >>>>>=20 >>>>> I then used top to kill ninja and the 4 large compiles >>>>> that were going on. I'll change: >>>>>=20 >>>>> vm.pfault_oom_attempts >>>>> vm.pfault_oom_wait >>>>>=20 >>>>> and reboot and start over. >>>>>=20 >>>>>=20 >>>>> I expect that the ongoing UFS test will likely end up >>>>> similarly and that similar adjustments and restarts >>>>> will be needed because of actually running out of >>>>> swap space. >>>>>=20 >>>>=20 >>>> I forgot to report: >>>>=20 >>>> [00:01:27] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>> [07:49:17] [01] [07:47:50] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>>>=20 >>>> So the swap space filling happened somewhat before >>>> that much time had passed. >>>=20 >>> ZFS context: >>>=20 >>> I will not start the next bulk until just before bed. I do not >>> want it to fail while I'm not monitoring it. >>>=20 >>> The last 4 reported compile starts reported in the log are: >>>=20 >>> [ 64% 4725/7265] . . . flang/lib/Evaluate/fold.cpp >>> [ 65% 4726/7265] . . . flang/lib/Evaluate/fold-character.cpp >>> [ 65% 4727/7265] . . . flang/lib/Evaluate/check-expression.cpp >>> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >>>=20 >>> But it is possible one or more of these completed and some >>> earlier one(s) was(were) still running. >>>=20 >>> So, if you do not need the Fortran compiler, you can probably >>> avoid the problem by setting the options for devel/llvm13 to >>> not build flang. >>=20 >> UFS context: >>=20 >> . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 >> . . . threads: . . ., 14 MaxObsRunning >> . . . >> Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) >> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >>=20 >> Console: >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(7): failed >> swp_pager_getswapspace(29): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(10): failed >>=20 >> . . . Then some time with no messages . . . >>=20 >> vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 >> Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >> swp_pager_getswapspace(2): failed >>=20 >>=20 >> Note: The "vm_pageout_mightbe_oom: kill context:" >> notice is one of the few parts of an old reporting >> patch Mark J. had supplied (long ago) that still >> fits in the modern code (or that I was able to keep >> updated enough to fit, anyway). It is another of the >> personal updates that I keep in my source trees, >> such as in /usr/main-src/ . >>=20 >> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >> index 36d5f3275800..f345e2d4a2d4 100644 >> --- a/sys/vm/vm_pageout.c >> +++ b/sys/vm/vm_pageout.c >> @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, >> * start OOM. Initiate the selection and signaling of the >> * victim. >> */ >> + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", >> + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); >> vm_pageout_oom(VM_OOM_MEM); >>=20 >> /* >>=20 >>=20 >> Again, I'd used vm.pfault_oom_attempts inappropriately >> for running out of swap (although with UFS it did do >> a kill fairly soon): >>=20 >> # Delay when persistent low free RAM leads to >> # Out Of Memory killing of processes: >> vm.pageout_oom_seq=3D120 >> # >> # For plunty of swap/paging space (will not >> # run out), avoid pageout delays leading to >> # Out Of Memory killing of processes: >> vm.pfault_oom_attempts=3D-1 >> # >> # For possibly insufficient swap/paging space >> # (might run out), increase the pageout delay >> # that leads to Out Of Memory killing of >> # processes (showing defaults at the time): >> #vm.pfault_oom_attempts=3D 3 >> #vm.pfault_oom_wait=3D 10 >> # (The multiplication is the total but there >> # are other potential tradoffs in the factors >> # multiplied, even for nearly the same total.) >>=20 >> I'll change: >>=20 >> vm.pfault_oom_attempts >> vm.pfault_oom_wait >>=20 >> and reboot --and start the bulk somewhat before >> going to bed. >>=20 >>=20 >> For reference: >>=20 >> [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >> [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>=20 >>=20 >> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >>=20 >> So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >>=20 >> Notably, the specific sources being compiled are different >> than in the ZFS context report. But this might be because >> of my killing ninja explicitly in the ZFS context, before >> killing the running compilers. >>=20 >> Again, using the options to avoid building the Fortran >> compiler probably avoids such memory use --if you do not >> need the Fortran compiler. >>=20 >=20 > Notes on the 2 types of "out of swap space" notices > in the main [so: 14] code: >=20 > One place that can lead to a variation of such notices is: >=20 > void > vm_pageout_oom(int shortage) > { > . . . > if (bigproc !=3D NULL) { > switch (shortage) { > case VM_OOM_MEM: > reason =3D "failed to reclaim memory"; > break; > case VM_OOM_MEM_PF: > reason =3D "a thread waited too long to = allocate a page"; > break; > case VM_OOM_SWAPZ: > reason =3D "out of swap space"; > break; > default: > panic("unknown OOM reason %d", shortage); > } > if (vm_panic_on_oom !=3D 0 && --vm_panic_on_oom =3D=3D = 0) > panic("%s", reason); > PROC_LOCK(bigproc); > killproc(bigproc, reason); > . . . > } >=20 > It is the VM_OOM_SWAPZ path that produces the misnomer > text during killproc(bigproc, reason) . >=20 > But there is another place that produces an accurate message > that does not, of itself, mention kills: >=20 > static void > swp_sizecheck(void) > { >=20 > if (swap_pager_avail < nswap_lowat) { > if (swap_pager_almost_full =3D=3D 0) { > printf("swap_pager: out of swap space\n"); > swap_pager_almost_full =3D 1; > } > } else { > swap_pager_full =3D 0; > if (swap_pager_avail > nswap_hiwat) > swap_pager_almost_full =3D 0; > } > } >=20 > It looks like you were getting the 2nd (accurate) form > of message generation. At this point kills have not > started and the message is not about kills at all. >=20 > Thus my initial notes about misnomer messages for your > specific context were wrong. Sorry. A typo in the commands prevented the poudriere bulk's from starting last night. So I've just started the UFS one (no sleep command first this time). Later I'll start the ZFS one. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 15:34:39 2022 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 AD6C71984928 for ; Fri, 28 Jan 2022 15:34:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlhN81tqQz4f04 for ; Fri, 28 Jan 2022 15:34:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643384081; bh=C7rBfcwEGjF7b+7tggb1VYmyOmU1D6q53MmSs/O8Fbo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d71In8ogUw8JeaDjS4sFHXtGqzJqYAZKU5R9YUl6YjEIA/jOWiX9i+u6pnKZuM9bf07rjG5d6pcZq9K4mQDvBMnTHGZR/qzQDwgF2tUrWAolayqPBxvoUmODEJIkpvMPUngAVbiBXq7qxCpp+sDHE3rDGjTL0KIlLOeWMwP3doOA0kqG9XmF6BKr5+GjuHc1QPEry7okoW5oQfM5uEhbmqNy72VdST3ifLF3uem9tIyVQRnaGLyyW5R77fv+eU9a+jYZ72UMBrr/3/KRKbQloyP1MaPZ/E9IrDRpOAoqdI1Ta+qREeRMeIoCId4jbGDnpVU2X/r2nPwa0BR5b9M1qA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643384081; bh=KEg0wvqvAOavuTdQ9aHOZ7ADxaSnGZXto9hyIDQBmO2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OYTgJrnnf8nD67Hao9Y6PeHYizHzEBNH8L8aXl3V+AKRiexZaxRaeiz+/DmV0Gdw6sa8ycwps6noxaT1OY8mF1f/NmxvWpmpsNZpCrAVDUP7Y0BrrGgh81i4kUFPqyme8NOWA7nF4P4BCWDkEsrbJ2VmCHVs6Go4zlbwx+BmQAx9vh35Cy5nDehXSzdqymnPWYmdp0W00SrT6ilDKkOuFumoIuVOyTlPsSteDQs8mBt/qmQiZiwwKm/wRHu8u0j8oZ4xLHlrAv4XFs7FiMkqCQLOWaYCVjvOXBC5A/9F+7bL08+mQRhwXPlQAgY3xPekRKGwewwhQavwTk30GNlIXg== X-YMail-OSG: vzUrPpUVM1lPorXr44aPJB3ZtsUeiz0B..PgwAxQKQGYkOZqSvUXkzDBrlGIAbu 1N_6C6uedpnC5fO29EEYD1Y4BChEp7yI7xHyfWzZBHouV.K8mqElMDaHillCdzLJeImg7eiCvybz jfLklk6ASrzDwzLk743BLjefyeVVCroJVui90procz57KYMTvUnxHgLDzbk2O6U14K2YnKdpFAMy lcazKjgUWX19QHUVqW.Bd3KKz0YI1mWtAKy2yOVLv7O0d1QsA8mT6Af3YGfvFjohlgHjW5v2Ap5G AwfB3H1d3z4fp23CHrtrxQu4LNgCcHsTAiw9iucqiHMK9SRvSNixhV_ikvxFMN1pLUWVcDd3x0Mx 8TWKcQfeASRR9WTH_bDuMW0yvXqlX98LoGJMDpmZA0I9bLd9d48oReVB1L0IZ9fn5kz_eNvbat4T gzwtKwH9NwXafy6cbdb3xPPLTJGDJKdPzTOJZd9Y0R_9toN01.gYA5NLSFeMjT6QZ70ZCLD1LbV0 6EXzrI0EKz2ix60iv1dlQ7fO7J.TB4Rffol4uGbdRHAlNYT1cF4cx_vP.ugw_LOcSWr_UCM3HU6h 0Ci88XMyWZlz.otHCaOcf5QxVxBHAcpjXPtAl2QeZWM3MEvVLSwJfJ6iYPQY0ZhP_SWjdY9g1cbi V5JuqdUN8zxNOnIu83uAHqRLcoOfw2vXGKf6vfvoyvaLsEQTOeK3ozr9XhWsYIlHo.uOjDU5I0bJ X2D55qzsIf52s6ToyhvqdtUEm8X3jJT5Ivt1gjq3IJh14jJZiiZmKzUle1nT4NIoFI9ELL5bVQ1X NrssxnJD5kplw4wHB9GdxjK.ZuDyX2Bei0hqgCCN_Vbn6rmK5PGR9sU4cWz_ny.i.dVrFRK3X9bX DB8Lv8P6yeFIlEP0BoPIv16hhJv4nZfcBmAM2NeHDoKf4ybM3fZ1FttmYCpt8Ubna5OtkHK2GQ5r fDnq8IclWbzWMsVHIQR1iYvlfKJgt_e2.EZAFH1aF33wCq.M3Ozsl8LqQp_UxSira9YPi9HGZN9w CqpHPBgdp.qvfBynObf5ecB6T37P1hNKiiQ44kT159y6.OmrCnB2nC.6dQkJYSAt5FByMjmogxe6 BN2rbfWmXYRnAY8StgWbJn8JGBjVTokLjpg7Q7whNJ5LnI01yrg9TUPVO.PRBl51nLS55O2Mf7kS rNiI2OhQE3Rndl9AxgNahJpEIrOXbluGahwDuhJlik0emWlBrJxB5BVKZdwjSyNs2vDbt0cwFU1p 9HdqjVQiQ20nRNTZ7VVLjqaYpO6MVsg6JNHiQlKOY_859GtsntA4u3OpjudQmmEcwkKmnsH60JDP n63ED1ACzAm71afYF_m_FMM2Frk95l183FHkdcygHwvzwTYH5yw4oC_dTOhYRvC3ZmQdwZjaAZyQ .gZhhe0gYlapu7k_7Uh_FSiYDDsFbojqXctAVs2gxVYJ90sCdtet7pbsgo2v56GsqjlVdgs1jCUa lsPCeqVaF0h9XXqnTmPAi4t7NS97idReyV6TIq_qrr5qYokL8TbWAv8aH9UUgGo2ibD5GtRKpHxD 7IXqpLqB9jrHstbKkyD5V4e13A4biiIXjqsPoUDg_kxsker4SN2ov0LVgBTd.cQpSYdE4XS9IS3Q vUAfYptTUoY7xO6NIkR_Z.MKBnaV2laEl0FtXnlHAUSZCPUtuMeAc9VvYrI._P.wHGCnSNNsT4fn UtB8A0BoqCt_WM1lxjqO6ORQ8l7B4em6GDFy5t3qrN_ZDE6rno5W3oN4t_R7OoBKgNY_SfuGu8N_ W8pYIgqfR4TzerQkmQyyt4vlcHsXb.ILUfxlsgwS.rZeKE_SG7VirJxfTUTofF0N2KN3D3w3soZ8 EgSR.llYT2kX5CaTIBa0SdtKLwTEH_NiN5_GxBsfD9vweEnSRgWuXobm4IaTFb48Osl2uxb41VjC 8QEpJOOVblvKg.S9hRTKm7j6UZC9QB2BQeKgDNfUpIWey51rWYZiMlsL6spauuR.m9p9sfjC4Hfn vrvvd28eE_C5RQj.ikDLeFKChU3zK6tHaEh.2wOczuPxPfMxzBsV2iqHMBwoGj8_MOb2M5.jgJZ7 J.OQCZymdGqg71jP9Y3UFxYaJg7lSUWj6xRjs3n._1o.drVgF0zGI3jP7NqRS4f1lUG4.U_hYp2O 9NFoFM3gvzMYMR6pDzg7ZPS2JD5uUti5NJ93gHBP94ADwMuCjCLhbDYalneIBouLexNjBOzlVHpT 3KNbWjqmsbUki_NhFLHFbBzPe_YwjmXi8_nluSABMxt76BB2Oo4MC7q7NtWz2sRvbSEmgCztph14 5akT1B1FkGyuUPWYpWzmTTvg4KCA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 15:34:41 +0000 Received: by kubenode533.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e6c868ec6faf66d9613e49c49718d2e5; Fri, 28 Jan 2022 15:34:39 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [correction to early claim] From: Mark Millard In-Reply-To: Date: Fri, 28 Jan 2022 07:34:39 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> To: bob prohaska , Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlhN81tqQz4f04 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=d71In8og; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1900 Lines: 62 [An explicit correction, with Mark Johnston included.] On 2022-Jan-27, at 11:31, Mark Millard wrote: > On 2022-Jan-27, at 08:45, bob prohaska wrote: >=20 >> Attempts to compile devel/llvm13 on a Pi4 running -current (updated >> on 20220126) with 8 GB of RAM and 8 GB of swap has failed on two = occasions using=20 >> make -DBATCH > make.log &=20 >> in /usr/ports/devel/llvm13 using the system compiler. The system is >> self-hosted.=20 >>=20 >> The first failure reported clang error 139, but the second >> was different, reporting only: >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/check-expressi= on.cpp.o >> along with a console report of >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1258432, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 627221, size: = 8192 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240419, size: = 4096 >> +swap_pager: out of swap space >=20 > In recent builds, such as yours, the above "out of swap" is a > misnomer but is very interesting for what it is actually about. Wrong: The message with the "swap_pager: " prefix is valid. The misnomer messages do not have that prefix. > . . . >=20 > Your context proves the metadata problem really happens, so > the messaging should be fixed to not be misleading. >=20 Again wrong: My testing with monitoring every few seconds indicates that the system is running out of swap, matching the specific message that was generated. I'm still running tests of the specific behavior for vm.pfault_oom_attempts=3D -1 # done vs. vm.pfault_oom_attempts=3D 3 vm.pfault_oom_wait=3D 10 After that I intend runs with 30 GiBytes of swap (so RAM+SWAP 38 = GiBytes). Hopefully that will complete and I'll be able to report how much swap = was observed to have been used. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 16:15:45 2022 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 04B1B197EEA0 for ; Fri, 28 Jan 2022 16:15:46 +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 4JljHP0YRhz4vnl for ; Fri, 28 Jan 2022 16:15:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20SGFjic056523 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 28 Jan 2022 08:15:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20SGFj1u056522; Fri, 28 Jan 2022 08:15:45 -0800 (PST) (envelope-from fbsd) Date: Fri, 28 Jan 2022 08:15:45 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] Message-ID: <20220128161545.GA56253@www.zefox.net> References: <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@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: <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> X-Rspamd-Queue-Id: 4JljHP0YRhz4vnl X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.76 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.92)[0.918]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 745 Lines: 29 On Thu, Jan 27, 2022 at 11:40:46PM -0800, Mark Millard wrote: [massive edit for readability] > >>> What are you using for each of: > >>> vm.pageout_oom_seq ? > >>> vm.pfault_oom_attempts ? > >>> vm.pfault_oom_wait ? For the case of devel/llvm13 (Pi4, -current, make) defaults. Those seem to be: vm.pageout_oom_seq: 12 vm.pfault_oom_attempts: 3 vm.pfault_oom_wait: 10 With 8 GB RAM I didn't anticipate memory problems 8-( For the case of practical interest (Pi3, stable/13, buildworld): vm.pageout_oom_seq: 4096 vm.pfault_oom_attempts: 20 vm.pfault_oom_wait: 10 It appears I should increase the latter two for starters. Can the Fortran feature be turned off in buildworld? That's the troublemaker for me. Thanks for writing! bob prohaska From nobody Fri Jan 28 18:56:32 2022 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 2F1A91979CBA for ; Fri, 28 Jan 2022 18:56:47 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlmsB14FYz58LB for ; Fri, 28 Jan 2022 18:56:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643396198; bh=uTq9MPatWE2d+XZOjPKq9L+1Ov1xCpuao3K+nlUeJJ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G1nuUexWFLJkBXeQr7oVri2u3xVqzML82/f+/A1xJAkQ5YQAYgSSCuofQvbesD4uDUuZlapjFcEmlZr1fts2moB/VxjvbZHsurZenzQ+0VSY3GGVc3wfoojxFt0A26mysfpQlfz3aTRKL9k4ElrkMCfE9J2+TY3R/S9tzwLpZ1TvlNoxHtgDprYQhzU7mtDFaHkaqsfdsdK2fDX3cr/ntogazSa57VDMaoxLGEOcgYaUli2AXaDfvuxnDhIGtNJau5Vtcs9vWlwB6ictYRcHuyc3PFZV51g90CGBuZsE/ALWHSL8T43+niIei6Nk99OrgmN3rm2OkUBYWTXa/Zu95g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643396198; bh=blLnzIAGZj4U+Wacb5r+b/5SE+cPHsW3BNG37mzEG/c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=guwq/deB0dINWFMDAg/BP6Uis6wOg84iaHiEwvZlom0MWGxL7TsemgdQ4jyA6NlF7oRLUfgkG6AzyV41IvlK1msPlDd+A7RaQt3QskdA3e9ucqTiQDJ7zdqUOtdCSfVFbZ4p7Ye38vffawqpMEbim+jZkkCzExvkhdCmVBHm6iDhgQYqJUSBsHRKlpZVsGy1AdY+S1qmMOs0jC+tJ8QreD6WJgLB1lkufCk/dxyawYumJFaauyoqim5dgVDcDbT+s4e6fmCUJGqz+StVOs57gc+4y6k9Np97GmvhrclARDlsp4/G6qkt3xZTbd1I8G+LISBr8KMETVtd2QYgJR2QKw== X-YMail-OSG: _7tV7T8VM1nSdBFsINMcbmYHH0O1ae8e3rtrPVwplu2ml0NctQIriv5XJ3JqO05 mYQk7bzdh7uJXQjN7kAR3WEB9xtalCnRUud9RgTs..wa6nKgYCIxfY2U58Jdu4rhTctosZ.gsEOe QtsHrBh9VV04lDxFdPCkOyBgYO.4e.iXRfuy80D._85ZbGRXXi2wBZTmVricQqnrYFo3LUW8QfND gRGK2L6Guu_nfAnzh7ZYHW3yL08d.vDmgHezynq5uHbgXjzrlrHEmd67XU7ZWr9iYkSd9cVdJ_M8 fFedk1OJkjdsUhbLOvw6S1Uu7DAt7q_olftyPlmIfHQlBKkxqMhfp6n3fBRyC4dJMWKXTgg1idyH L7C1i25jC8nx4V5CduqxXI49LMcATehVrJGO_SP6TC9_ShGOcf.rqU4t08iBth9ba5AMpcwIhdje Ls_zG11Zp_EkBq6vIEebpMXToZxwYpJRtJl5eh2pcvCiBf0DBXHqTiOXmueoItW4W31ZQdVccW2f IESpqRIP3IwacBI.3wTk3Qm_MdfcvOXqX3avsjcPWn.RVhZQlx8zJHZjG5qXNzBxX_Q4abxwwB2c 2FvMwywtkZ5j9McB9X5s8Kzl8NR43rrjM5PQ0DnmkgFAq4xFTKwxtlyQhK.ZHhilNoNbL8Sur1F6 EypduGxNxlnLTBMNDdYOOkzxfj.FsHt8HqpBnwTAWvYkEy1IhkYL8B1l93qsTo.6dZ8V1B7hQ9Ig 3J49ufJ617p_8h7LeioW6lOtkoT8ji5Wdnvipy_Qmh2RDWioHeG8dNTp.4WhJ6dQloAVKQNx_5ZG BMgtjBrGJwHkO7F4BXNJWc2yhWUns26xvk71g_XpkR0iuGd60jU465nUZVKc1x5IrhkRFGE16hJV JQr.NNBCl803TlbgZWvPuNJoVRfpemY7D2HsGjugSOXoe5bScfwGpgl.gOW22wfMmblf8THDcAj3 _1PhEQ98HjH56cGvxrGQbtOg_fhnIKSfqaLkQrgGS3gxr4ZID.Ink5Ww9HUNgdSKljqdMREDsic6 Ftg6hwXK5G6i.bSx2qvv81Mmlvf.24keqbQshdVdK1yPtHXWABe.JGkBiwDkH2iwKC.vhcroOuYE UW_JuUOFrZRB0FFKhkrdlAxvziZ1GGTxS9w7.qqqoRIFk0HJuS53HBoJLmejBA629C7pR.h70xk2 n8zX2ODZOyhb4.v4kDmy9WDGYKYPa6eBnY3vYu4lHRH6WcGvsKwnhMauRqiom3VBcyU1RI.hOGfv WUvUsAYnDtSG0iZ44BcEpjYvndiihb0so.DXjBie9wHre5wvmLcBhkubSsEeU2RZQLxiekpX3pYI qK0CCCqv2n2ZUVWnKAkESxYqOwWUh4i11xvPEvRxKwGTDbJueTwujOWhMDrGBbbfwFeKmX3C.OY6 cXSv_10tUGLaoM3WIadvHy6zjjry.TH5xQ2VCJOrDxbNOpy4Eb5qtRJY4eePabCuxj7gmlN3bzdJ ebpzNDRVxy_ql2Fq82DeaJQLfdRt8Sqmok3YD7SO4tzSRijOfWBQrK0b6eWmorHvQj_X46Cx2e86 tb8wqyA3B8fKpBOWuDPPHxqxBqSOio9UJuJM2mF5w7M61nY16RqqLuFCyDRUliOcmyqS08VHsVH0 WxX_EdJ4uokVJ5kxj0B80dSYCE5aRYcyI5Zqxrn8O.JePYisi6YHzhKVKBu_WGwh86XeCYZMmf0P 7U8L6S3d6gfe_DC1ZYxAXWvo4kFsEsWRT93d1cSUXUJMZk70NQeaEn6yHIV.6BoIE2l7bPpssxDD ipQHYgQLONNYEXkt2bu_ASQpQ1YtjfvBaBO06sdg1tLyCZnrxA_BCqvuwEbL6R.NFvha_BCp9ds_ .R17H08wIk.jf3enacGPF5PONbPNAJkgZ38aSFBQwkc6brw9r5BcR5Nr_bLDijh5N8PkE4S1OnHl Xa6_imyHcAsNXb0oHULD20Iagjz0f_IcjGD_OUFT4AA9S0DjJaEnHEf3CCIzDL4LxXXngPhQwXU3 xsqSSIYRjNkzgLKDP.losPH3ZHQZULnacYdUcrUoR6EyQySvN3w3JXOmDoAlIS1pQ.qmtCTn7q1C f3gAIorHlt8yoYo4DaXwWu8MR7iBn3oY10yC24PNtMcSDZX1rLXq.J2WZgNx07EENY_g3jUaxqzG YG0oxv_drpkGb9C_6xG_JlXSev_wKksK19LeFDntfCRILpVXY6M7QVj83jfDRFpFXH9oOsBPaJWF 5vfcYgsAWRWSkr.HVN9HUSeSUxsIeIlSvF.QHPU5ennpQSEcYZU99yAIC.Bd2Cy5eNYxrOSPHHT7 LBdHcHi8kUYLD8ZLkOIc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 18:56:38 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 078ba4d23577297d04d538d3420ca9ac; Fri, 28 Jan 2022 18:56:35 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: <20220128161545.GA56253@www.zefox.net> Date: Fri, 28 Jan 2022 10:56:32 -0800 Cc: Free BSD Content-Transfer-Encoding: 7bit Message-Id: <1A92F2FF-29C3-4CBE-B7C3-34C9CD35A75E@yahoo.com> References: <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <20220128161545.GA56253@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlmsB14FYz58LB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=G1nuUexW; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2369 Lines: 77 On 2022-Jan-28, at 08:15, bob prohaska wrote: > On Thu, Jan 27, 2022 at 11:40:46PM -0800, Mark Millard wrote: > [massive edit for readability] > >>>>> What are you using for each of: >>>>> vm.pageout_oom_seq ? >>>>> vm.pfault_oom_attempts ? >>>>> vm.pfault_oom_wait ? > > For the case of devel/llvm13 (Pi4, -current, make) defaults. > Those seem to be: > vm.pageout_oom_seq: 12 > vm.pfault_oom_attempts: 3 > vm.pfault_oom_wait: 10 > With 8 GB RAM I didn't anticipate memory problems 8-( Well, having a swap space suggests otherwise. On these small board computers, for doing what you do, if you think it appropriate to have a swap space, you probably also want at least something like: vm.pageout_oom_seq=120 This was the original setting that made the difference for your builds, back when Mark Johnston first helped use get buildworld buildkernel working on the arm SBCs. This would make it try more before it classifies the context as having the "failed to reclaim memory" condition, including when the swap is not full. Getting what is now correctly labeled as "failed to reclaim memory" before swap was full was the original problem as I remember. > For the case of practical interest (Pi3, stable/13, buildworld): > vm.pageout_oom_seq: 4096 > vm.pfault_oom_attempts: 20 > vm.pfault_oom_wait: 10 > > It appears I should increase the latter two for starters. vm.pfault_oom_attempts and vm.pfault_oom_wait may be related to what the consequences are assocaited for your indefinite wait buffer notices. I'm unsure of specifics for adjusting these as I've been able to fit in my RAM+SWAP configurations and could use vm.pfault_oom_attempts=-1 validly. Plus, I'm not using spinning rust. So I've never explored setting this pair to non-defaults. > Can the Fortran feature be turned off in buildworld? buildworld does not build devel/llvm13 and does not build flang. flang is not part of FreeBSD and so FreeBSD's llvm materials are not configured to build flang. > That's the troublemaker for me. Not for buildworld. But, it is for building devel/llvm13 . I've not dealt with setting up a 2 GiByte swap test context for a RPi3B. I probably will not do so until after I'm done doing these devel/llvm13 tests with flang involved. (I normally have flang turned off in the devel/llvm13 options.) === Mark Millard marklmi at yahoo.com From nobody Fri Jan 28 23:05:06 2022 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 C6B3319869BA for ; Fri, 28 Jan 2022 23:05:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JltN12c6cz4jqK for ; Fri, 28 Jan 2022 23:05:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643411112; bh=O+bjiF5xJE+NDzLKL6+CbrumnucEUpWTQ357U/m7WhA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y7QNnzZs/VZhbDTEbMTDSmQAEzZZO4V5s7nzf1OC526UvOf3BRfTFoPvNw4q5JOzEdJObqUN7eRoOuwExenCIFBpM/SiKYlbNys8bvivqU9UQBxg46C7RoxPNlaAuINszI+QqV2ugmqkcru9qi7xYwXmYarZ56Hrny8PfZyh5IdAvK7Sq00Cv6Pt3rpocwmpekW0Mg6lUmLQZ/0f9VI6SM+xs+nfgMoB80oml9fqgfLn8RPlZdP6zoT7xVGc5kusHq+UrwIC/hmRQNKaIDf6g3gjkAbOcMFzMizM0+Anq+nc2J8wbRBA3Kq90JOra5KbNCM2EUsHXA3v4/yJ79kbRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643411112; bh=HIagRZlF0ZPNs3wSjvhzdwhg3k31dDhhZl9959qDLDN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tkAjMhWizARoTU0akhRe5C4srAJMXWgBxwRfNQva5WakS3eCcFF2Xt51vt8x9qgChOLtSc5jGhMvL5x6IJxuYe0Myz74dsjjGf+QKUqqyv8Qh19Rr6GzeC9BT8TTC6Pf9svVorQFU8J3uT4Z7uI9rwdQTQ++kfU/ilLihPuJyExZt4AS7hU9vGwnYqF2KsJD2eynDUXKKJFyst8SvjVG+8sdvwHNleVaApMHkO8pten5FqsNOVg5/9vla1NB/W2bzyogqqelExPRxTkvZWU4AUHqZIP5OT2h6EBQY9Pch8ETO3gagL1AfP84RLjvzniy2vy7tAfiR8qNWPbRWtYYtg== X-YMail-OSG: j57Sbu0VM1lHuNbvGIMKfWrHdndl1P.hFl3E8yLJ3ze7ohM0.luQth5EbwC4WgZ 7Fg7zYaba.VIx_98zo4Dh.Urhx5QC2JZHzaqWyJoKp1zRtLvVFPXnLZr5mhwYvrN6eHeVt6R0NC0 s2nuQby4YiaM2deteuYINYBhxInNT41FYKc0RoqBvtkSsisSBWYwDLjzOgTrHtQ1UtgJ5EguNwvW X0xeOea1HPSl.tDsfxnsqme5Fndmi._YFbJ3hpABK4BC6k1j8nuhLX5m0vuNY1w4d09KeaNqKXin IZqp81vxix9If7beP95sX.DwWZ97rdErjeKcmcV8GymDoui.EMBZ.Zd6iyFtQD5bTrWfVvHThxAz Op5g83jEFJq1Fy1AA8XwrDvlDu7dCLdVIUWN4RnHhDuYBhoQFQq6XQY5M_8yY4SWhtfp_kScpKIh BYJvTsWGMph7xyMjDWz979VLrNrBYbVmnoQSBRyXy5bu_CxzBaRKfZ2kdlDFb6_HRF_lwDjIsFmH a17k5vGlXTvPFbzryI.eG7NZS6oJ5vyGGKyIHNPLcCQftBhE4flctdT4DyHW6ZexE7vuLKgBKqz_ l.ue8n9_x7mfj9AndlZRlhAEUbmgai2jTHJcTUyV8mWskslE63M4m.l.OQnhjxiN3gzThQfrlGX7 d3OHeAKPPyCr.ilOUdAbhwZkGGKK2lh_drv_qjnSl1Z5bf1rRE9kLUXJGL3JIi.LlUA_L.amkPAJ TNpA5gGTQuTkIGms_mAZfxj_XijqBx93Sb4KK8wYmYEt5V_4CogV0aSJYLPhFuM2LAKFIA6kg91u Q92wkcNut4ignjEImnk7yXI.iG2ep6MD3hqHZlkYSe99jvt4Ugls3zqOIDcCUtLl7u9.CnJt5kpp OrarBw0Yp1Dn5mEMoqHQ8kRFe_CY.hsHpwY61YtEAxyDq2Mw0GsZHFV8XiyWsMHJmc3SvykeRZdT gT6ATrhsah8sTvsd68RhBi1SRxf7gHnWhew7BRGSNgg0L5qpl7uLGT3xOu0kxrqCdFBFmxV._Aa. tloYtvcDLqszOb1p..ClYbC7k7Ta1qsFPstGKe2pL1NSKOOPDSVcxcLe1LMnAZIh3eJ9AOMIx4sm ywP67djeIMjgRIW5tlN.XErLRf6qpDwFBwgFXCvxdXCG4nft11S3LPUpy6DYbcsCTR3.fEF3e75x PX1SvSwhrstHBftgyZlMQyQCzEZsoyvuIeXoAGhUS5zSyi1C3yGlA3XWnPOPohH2cHJ9hib759AL 8jzAmLbuA9aI8tQC0nP6MAe.orVPnFlDsbwLmLMIoq86obR8bfzwHmJHZIXWjDLdbpfkiL1PEXva ISpDkgUEAsoJHUfCHHqUqBcH3bQNJwZEByG5iHmowIBbsWOdGS4ug5Gftu37tIUoXRI1VVCU1KK7 qqb6gwiJdT5P9RarDnh65I5Jk4rh0M3YDNwbZiXM5ZOWvMMeHZGzFsMEMZC505Vg9dHmG5vPyt_r rYIrGCOZ44khvxFdhF8R.vpiZXmIP.t8nnYjA3DKQtJ_ylnjmpBx9vRtlDXWzC7kkamaa55yinxk ponuKa7ntXcxy2.6MSoRXYf4nis0NLoFqhlTeiDTmejE4.VIfrNHtMX7uudR.YWd7JONFFsATTHf WUib9egzoG3ep3UIff7nQ0COi9dla50VI3oIqF1.N9CASQ3KRP9ShcQhxWdi0QlecRQRJNdddIId TVDvTOFS_3LxQ1ATJ4C8YG6fq9hA.yW2qZOsvKRBbhjKSJxnaGebuIrFtrQOsTd8NkySQue1et6x pwVL41jxbuyXQ_LIhsICRWB2i_SCGVu.drAohZQgApDVViQPHdNqrwYoUuFWsGaB5ev_rj4ljBhY tZqr7yWejp7VIcUt06XrOgxN6L6HFqcwVBy_PXpmBA0QGDWEGgvY3VddN62gzMm4YIUMwCPSZGSL ykN2LgK6I8_ePFao49HaHO_hO8LPvDLrige_ozpDx.YiwdAG6ogcl4Vnp_iBWhOOd29tgSo1HgSV 1MO5Q7Siz_JIR3gXiGypVKznQ9hbMciSzfDN.Ft1snSYFCk7E33VaIoHRH8KFGKUlDHCxukAS2TJ 8WvJ1pf7gNx3aRsujqPVqMB4ywIa64a.104ANl76Zuk6XnG7oJKAdto8YVD84BRNhHA4gdh657oZ .2rhL9h25obeTQxXmHQqGu.y.cwZ53rNWtnAth9hSWp7Ho4Qn.Hf4yuR6rJTFnb_mPNa61dOSmYS rIgTWP2zHwdxYL3MbAxRLWL1CLM1bdYiTRNZ9ZlqyKor_M3b50b74XI2xQAjudCxSWagMJaiDNhg colbfS3sOXmYl8.tcBy1xKw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Jan 2022 23:05:12 +0000 Received: by kubenode525.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 73b0cfa545d461c4e43dd2fa1c178b05; Fri, 28 Jan 2022 23:05:08 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: Date: Fri, 28 Jan 2022 15:05:06 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JltN12c6cz4jqK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y7QNnzZs; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7348 Lines: 230 On 2022-Jan-28, at 00:31, Mark Millard wrote: >> . . . >=20 > UFS context: >=20 > . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 > . . . threads: . . ., 14 MaxObsRunning > . . . > Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) > Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >=20 >=20 > Console: >=20 > swap_pager: out of swap space > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(7): failed > swp_pager_getswapspace(29): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(10): failed >=20 > . . . Then some time with no messages . . . >=20 > vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 > Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory > swp_pager_getswapspace(2): failed >=20 >=20 > Note: The "vm_pageout_mightbe_oom: kill context:" > notice is one of the few parts of an old reporting > patch Mark J. had supplied (long ago) that still > fits in the modern code (or that I was able to keep > updated enough to fit, anyway). It is another of the > personal updates that I keep in my source trees, > such as in /usr/main-src/ . >=20 > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 36d5f3275800..f345e2d4a2d4 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, > * start OOM. Initiate the selection and signaling of the > * victim. > */ > + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", > + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); > vm_pageout_oom(VM_OOM_MEM); >=20 > /* >=20 >=20 > Again, I'd used vm.pfault_oom_attempts inappropriately > for running out of swap (although with UFS it did do > a kill fairly soon): >=20 > # Delay when persistent low free RAM leads to > # Out Of Memory killing of processes: > vm.pageout_oom_seq=3D120 > # > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > vm.pfault_oom_attempts=3D-1 > # > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes (showing defaults at the time): > #vm.pfault_oom_attempts=3D 3 > #vm.pfault_oom_wait=3D 10 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied, even for nearly the same total.) >=20 > I'll change: >=20 > vm.pfault_oom_attempts > vm.pfault_oom_wait >=20 > and reboot --and start the bulk somewhat before > going to bed. >=20 >=20 > For reference: >=20 > [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >=20 >=20 > [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp > FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp > [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >=20 > So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >=20 > Notably, the specific sources being compiled are different > than in the ZFS context report. But this might be because > of my killing ninja explicitly in the ZFS context, before > killing the running compilers. >=20 > Again, using the options to avoid building the Fortran > compiler probably avoids such memory use --if you do not > need the Fortran compiler. UFS based on instead using (not vm.pfault_oom_attempts=3D-1): vm.pfault_oom_attempts=3D 3 vm.pfault_oom_wait=3D 10 It reached swap-space-full: . . .; load averages: . . . MaxObs: 5.42, 4.98, 4.80 . . . threads: . . ., 11 MaxObsRunning . . . Mem: . . ., 6482Mi MaxObsActive, 1275Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 4096B In, 81920B = Out, 8192Mi MaxObsUsed, 14733Mi MaxObs(Act+Lndry+SwapUsed), 16007Mi = MaxObs(Act+Wir+Lndry+SwapUsed) swap_pager: out of swap space swp_pager_getswapspace(5): failed swp_pager_getswapspace(25): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(31): failed swp_pager_getswapspace(6): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(25): failed swp_pager_getswapspace(10): failed swp_pager_getswapspace(17): failed swp_pager_getswapspace(27): failed swp_pager_getswapspace(5): failed swp_pager_getswapspace(11): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(29): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(20): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(21): failed swp_pager_getswapspace(11): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(21): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(20): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(16): failed swp_pager_getswapspace(6): failed swap_pager: out of swap space swp_pager_getswapspace(4): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(17): failed swp_pager_getswapspace(30): failed swp_pager_getswapspace(1): failed . . . Then some time with no messages . . . vm_pageout_mightbe_oom: kill context: v_free_count: 7875, = v_inactive_count: 1 Jan 28 14:36:44 CA72_UFS kernel: pid 55178 (c++), jid 3, uid 0, was = killed: failed to reclaim memory swp_pager_getswapspace(11): failed So, not all that much different from how the vm.pfault_oom_attempts=3D-1 example looked. [00:01:00] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 [07:41:39] [01] [07:40:39] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build Again it killed: FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o So, basically the same stopping area as for the vm.pfault_oom_attempts=3D-1 example. I'll set things up for swap totaling to 30 GiBytes, reboot, and start it again. This will hopefully let me see and report MaxObs??? figures for a successful build when there is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler instance (mean). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 00:20:17 2022 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 59D23198FAA3 for ; Sat, 29 Jan 2022 00:20:18 +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 4Jlw2S6ZLdz3sxk for ; Sat, 29 Jan 2022 00:20:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20T0KHMR058776 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 28 Jan 2022 16:20:18 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20T0KHRl058775; Fri, 28 Jan 2022 16:20:17 -0800 (PST) (envelope-from fbsd) Date: Fri, 28 Jan 2022 16:20:17 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] Message-ID: <20220129002017.GA58768@www.zefox.net> References: <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@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: 4Jlw2S6ZLdz3sxk X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.75)[0.750]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 484 Lines: 16 On Fri, Jan 28, 2022 at 03:05:06PM -0800, Mark Millard wrote: > > I'll set things up for swap totaling to 30 GiBytes, reboot, > and start it again. This will hopefully let me see and > report MaxObs??? figures for a successful build when there > is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler > instance (mean). > Am I mistaken to think there's been a drastic and abrupt increase in memory needed to compile clang13 and friends? Thanks for reading, bob prohaska From nobody Sat Jan 29 00:33:11 2022 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 421A01977BFA for ; Sat, 29 Jan 2022 00:33:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlwKb6W94z4Ssw for ; Sat, 29 Jan 2022 00:33:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643416396; bh=wpiDUSRbbdO/i5EovUgX7eOcMVk4cIxRIesGFdHgQrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EuENBx/eBycG1OpA0kwV1FCE7wY9RPWBnshCfuFYzYphEImAc6oh0W2klvKCkg/+xtJ6FfkbGyO50PwROY1GNqOByyZrOmvqoVqWNG8igQN9ItRv/AU/9dHtxWID5AyyyzfZCKH6p4YEVjc/o/2WZ3TWFjshDn+1bHGrEZwtuBGS+ETOT+7GsAU4J/+N54JpDcG6uurAXXbpHHapS4mDoWioTKiVFSD/aACzZdjvx77huZBmAQ8H8t/B5tipkPx83MTR3zx7IF8r+ZCe9lwwTBHLDUsJoY34CY2nRFb9SPt+m8TGwyrmnFCd8AcmqbKBMmX6fPxsZNk0XyoQWUcDLA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643416396; bh=zgHmTwb+g6U5WWrkwoKR2qxJRgivtuArSvb7IpyPWz3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZVtunJJKOmL3aZqn1DhjfqM1cZbSaZui3woYJkaA+dBHLsoPbVSHyJcdwAQqDBkpkVxhJiNMYilz8EbFrk4miqXYQrkmdegMeOrLa7wHjoc7gU+Zr/lDE97of7Tu5Dj0sT78y7XvXBgar6z95V5wKMRnY0a9bsqNYmYmbJj2IJ3rWscEBk8uTxLUCUwvmZ1Y35hQPQNQwKRZA+f+U7hvsGCoZ+6O07jv/PkNCeKlQ5SeePjSx4sO+5EmXW++71NA1TQwLO0OFwqANBb8JTX7f3kDXy7Av0Ex7RHf9Z6SjzuEXS0M25xh97dgZuXBVmSlJOML+7izmkxxTvYFinBWkA== X-YMail-OSG: mIwT0zUVM1l6N6.B7yB4SFU3ggYIjOwm5EnOw.mlGJAn8Wy2DKmN5dZV1Gj1ua3 Fj2NQobo5IuBuJO_I8mH5XJzTY6F4MRohlPQYYw9SNa0EKY1OFbt5RLCsZ9O8c8X21jR2LDEq.ST GYi4R0hdC2Rhe.LssgR3twRpCe.SNg_vjUC933Bl4UktE5hZP2QzpKQZa4H9lL7BwHFOtl4pM9T1 yYMuPMr8ExxANkJlXSPtRLfAx_uj313bO5RbEVr1D4Qa27z7nHL8jt5DhrFCvZ10xb8K9FAbb97m kDzRhEzrzb6g7ZI1Tsh0zUZD0J8b9Z49Bcn8psrrLOhckeKXJwJPaX45l.bGBUgFkh1pzjL3xbua rQoYqcxADGsJuPYhMFyLkn35QjKlFs.hyfkUiQumE3ricsKnGCX8mjGyV3U50E2WQj3dXUH_21Q8 JueVKL0BJt2YFnMCJmFqdEV_MNglay5bWxhGJOx5bRxllCZRlig5FHfAZtBzHPrWp3zlDV6zCG00 Z.lJymMpbfx6HGDVzgUXV2kmlDDwoV_siBT06wQN7STw68Kb03MVpVfYJovAiFDkz_..oXgNEJOr BzfoC0fNmklDNqAuDE4uhpT_KuJtd_ClLJOfdrAVjID1C1hMCS3J7yw2j7fzAfWWWa.h1Ll8wyYm RauTSsLvvY1Ay18G_0uvtRmiFAZ.pyjhdDIllwX8_B75f.7MEPcFC5Afq6ppYleuZgB1Sbc5tH0n CMFKdSeNWXknW2ObD1w9yROixKGgVSpAKSN3afqWsfdN_MNvV0SBIrtuOsqEk53m5GgSsb_dRRAJ RJHIwME3LenlZi3N3GE3vh_HtcQACfVZ8Cz0Apoy5uOp.qrmfaR8ovRWO.s04LSxIJXNMvC_3vqM uFLSX.IKhzmQAMt6S0HBX3FujFI3X8tUEtsgmg1.Z8za4Kc1TWNo_6948cGXSrWrxZpqIxVNrW_H Xr.qUg5lawOhOi53psApbcofjltAYtMJSN78v22Tkp5T4bLJmvY9ZjdIBLsslBIkZ7FDZlAcRwM1 v3M1lpmg19Z98E9pQGucG.gEo0LE6pfR_Hevsv31HeOao4aPCTaHZHmZ5KKk4Fp5ZwPpvIjixSjn rrf1PDyAS3QJU5fLes4nECzRXa7XxXqGk38r4Xe9t37SHdx1xmUHv0TYu1QtztP6qPpGd9FmfJtS EJgALFNoSlL7YPllq9eGJ6hKzx3NvT1F80IDomorYE2GCSVILsOV9TgzsYVLW6T6UweNTuJHuCFH dKrxFydhY8MDg06HgE2k7.un4ylemhKdyeDCj8ecpL22Yd25w1fd0PxP80UE4lL9fviB.pxZKJsh Zz.0dfbYpIkxM1KeA4GiOSoNJ5TCEVQ6bfBy3vcV98p0Lc4RtzqKc79WlVp6_gHGF_8c9JqJvvYR nzz9Qi98DKU.ZwdIjb7BBcos8sF6__7UgXbEbNN8neaguD9SLRhFxd.DzKBGierY7cOaPOymiTdJ zjuLuAozDhoiry6MUUkcUt_ExyxCY8Ef2iIegCYIDeT33RRkEUlaB.zapSJAwHc9F9UelT9HNW1U uDr.ti6qM8GrxNWC9M.RnUCcINut11r5W1nYiZ5WuAVh1UMg__8tVoJDArcS0ML5b75344aNb0fc VK.VsjYZOZ0vqrjdqlWoneDvlr32sd35uUDDPBdo2CcOMYAVa5i92Ccwb8ScwIDwdUCZx9GjDUde iTaDWAQaWwNooWI7HTE0UQLJoZk07O8Q2.9nV5zv7xJrVdY6DpZhf1Y4EwDynxIc2rGB9p8sv16p HCQzSO8wAzkqq4VIgZDvWNKH073Wl.dEqFV6QIJOFd.ZbQYop1evsrUM9iWLZd8XjQghzVVz4zNq boakZ7nTvPrUfT9O8_tOuXTzzb0jEVGgqcqxBW2Sh7DVM7CXtxKQnc2jJMt0z6CX1kIYJTDAumMe EO6hwINFY0DFtI2zR7Ey7cuXy8palBKSv_GBvVJaA74MrrKvfLk4kFWruQRlg5GAiIXcQau_uXZ9 qSC7i3r3Qsh3RpvlF7dAJccO1dc3HCAxXQ.7WUBh6W6zFrU94OnMLtvLV4KRbxOTS.36nOlqbuE1 IyI8aTLhsJC9VmVyGbKXLrKbYvQOL1gETAa5lRYCIg.DjnYrtNajx9UYEAefKvWYq3sfmGdscO8c kpTPW8b2LAjOqaLrF6nlGMWjgRQ41h8_bpnOAD07flU0sf7puKdztvr7fkEpMf3FKmsE9d.AfCu5 HhPKLjp5BLmhmCdt2ICuGIOBgqZiqn5YP7mfmJobZirkhNvNzZEMqNN9rlhKmAFEEbyEzi8lEv_l _5hVQMw35ZwM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 00:33:16 +0000 Received: by kubenode514.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7767b1d395d075a9dcc219bf45e75b7f; Sat, 29 Jan 2022 00:33:12 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: <20220129002017.GA58768@www.zefox.net> Date: Fri, 28 Jan 2022 16:33:11 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <03306779-68BB-4C87-9B03-81756EFC519C@yahoo.com> References: <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <20220129002017.GA58768@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JlwKb6W94z4Ssw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="EuENBx/e"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2091 Lines: 76 On 2022-Jan-28, at 16:20, bob prohaska wrote: > On Fri, Jan 28, 2022 at 03:05:06PM -0800, Mark Millard wrote: >>=20 >> I'll set things up for swap totaling to 30 GiBytes, reboot, >> and start it again. This will hopefully let me see and >> report MaxObs??? figures for a successful build when there >> is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler >> instance (mean). >>=20 >=20 > Am I mistaken to think there's been a drastic and abrupt increase > in memory needed to compile clang13 and friends?=20 >=20 Not that I know of. I've still never managed to repeat your RPi3B + 2 GiByte SWAP problem (.cpp and .sh example). I'm still trying. At this point I've still no clue what is going on. One thing that you could check is the content of /usr/src/lib/googletest/tests/Makefile.inc . It should look like (up to email whitespace oddities): QUOTE # $FreeBSD$ .include "../Makefile.inc" # Keep the existing tests directory structure (with subdirs per = component) # rather than installing all of them to /usr/tests/lib/googletest TESTSDIR=3D ${TESTSBASE}/lib/googletest/${.CURDIR:T} # Clang's optimizer spends a really long time on these tests at -O2. = Changing # -O2 to -O1 reduces the -j32 time for lib/googletest/test from 131s to = 71s. # Using -O0 further reduces the time to 29s, and also reduces the disk = usage # from 144MB (at -O2) / 92MB (at -O1) to 82MB, so we use -O0. # Note: Building without debug info saves about 10-15% of the build = time, so we # only enable debug info if DEBUG_FLAGS is not empty (71s -> 64s at -O1 = and -j32). CFLAGS.clang+=3D -O0 .if empty(DEBUG_FLAGS) MK_DEBUG_FILES:=3Dno CFLAGS.clang+=3D -g0 .endif END QUOTE The part of it that has: CFLAGS.clang+=3D -O0 .if empty(DEBUG_FLAGS) MK_DEBUG_FILES:=3Dno CFLAGS.clang+=3D -g0 .endif is important to limiting memory use for building googletest. It is also important to not have done anything that forces -O2 for some parts of googletest. As I remember, this issue predates clang13 but still applies. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 01:14:29 2022 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 0848D1994366 for ; Sat, 29 Jan 2022 01:14:30 +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 4JlxF113Mrz4nfq for ; Sat, 29 Jan 2022 01:14:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20T1EUpT059189 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 28 Jan 2022 17:14:30 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20T1EUOR059187; Fri, 28 Jan 2022 17:14:30 -0800 (PST) (envelope-from fbsd) Date: Fri, 28 Jan 2022 17:14:29 -0800 From: bob prohaska To: Mark Millard Cc: Free BSD Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] Message-ID: <20220129011429.GA58988@www.zefox.net> References: <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <20220129002017.GA58768@www.zefox.net> <03306779-68BB-4C87-9B03-81756EFC519C@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: <03306779-68BB-4C87-9B03-81756EFC519C@yahoo.com> X-Rspamd-Queue-Id: 4JlxF113Mrz4nfq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.63 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.73)[0.729]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 455 Lines: 27 On Fri, Jan 28, 2022 at 04:33:11PM -0800, Mark Millard wrote: > > > The part of it that has: > > CFLAGS.clang+= -O0 > .if empty(DEBUG_FLAGS) > MK_DEBUG_FILES:=no > CFLAGS.clang+= -g0 > .endif > > is important to limiting memory use for building > googletest. > The version on my Pi3 running stable/13 contains CFLAGS.clang+= -O0 .if empty(DEBUG_FLAGS) MK_DEBUG_FILES:=no CFLAGS.clang+= -g0 .endif No differences that I can see. bob prohaska From nobody Sat Jan 29 01:52:15 2022 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 83EA41982DE3 for ; Sat, 29 Jan 2022 01:52:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jly4p0Nmzz3KN1 for ; Sat, 29 Jan 2022 01:52:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643421139; bh=bO0PoYRJ3ofHPsk3ZuoR/bOSEHunBa/8aLwhHxqKt0Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dlWU79kIgb2Z6qyylcXUOAC8XIqv1JN8nGoSokBHv6kw26cBuNeP5ZmUlfqFjLQ6cM5r310K8UWLAjT2OF/DS7cAurUfQrJSvi35dR4WVjEe7OLpDKrhDTWvCUkUslmS21MdizjyKxS3Wy8SIhB9H71ISGY77jD3cgT+gmHu9frdlHTk+eqxb/zWgq0EFJZ04doz9sTqIfLevtpreY6gJ6xkYt3Td4HrF/5qH8FhpNwPkz4dE4x1bSETIjDSMHGLybPQ2/lIOvlFpWTqIgNsonSbLS3/QFW31y3AT9gSsYaRkOUQ8Tc6fucr9tRtK3FN1X1viwl3ZAL3eNL/O4ybig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643421139; bh=pgqEmas63UD68mxAzV3TbSPjU72PCMfqKrSOygy7ZmT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bpPl7mXVTIwT9uGBhxYz9jmrvWA6gyZ63nzO7zjhvsKRjtRWsnh5J7d2JvhSTakHQVroisBlaoVnOOCIhmScQtz8HqiGoy44b5hHrSYBTpP4towlxKjm3v4qjQB1boWQM94U9NHVukrzFJEo+gUAQu+SivH1NgSpbx4EBOPGJWh70+0K/6YqiUMNdTvarlX4sVy35dgcdpwNP+QpWyTslTGzkS6p4eNifMiONaUTZtJa9iYrczeGGc9BgLnQflzSjBeMGVehKAx+ZnslW0Xm1p+t431KmEcT+IMP4KqWm8RKu8o082TCk+NywTNgSoETGmMsmOPACYxSWg1ayDgvvw== X-YMail-OSG: j4bZahYVM1lChknqqp6.foVKJAzRNBhH6o5J8fuqbh3.lCwkVrrr1uBpKZrCn5r MWaC3Wtnow3JHsCAEqizvZMQAipBdgiuBFxspoypc_yGaOz3GMPSfXDE4Jb1yEt5ZdlEe.x.Eckc mTEWeIYBmMe.2DwnGiymmMva0.eVAw_SGznghqTL813bm3UWCYjqud.UmzPuliHEPZ6_7EXJYlb3 AACPKehblUndHcaRBWfmVt_V1RJZ1Rw9abqt4_qHiakIikwxoKsIkVHWEAi8qm3PK5I5IkIAHmtg ac90a8cuy6PiziTiFw_PPOLFR8CE6Cd7aLJnRcGnFUAqCun0HAGutbFUcCUhiycKopixyazZOn0y CHfF7SGl3wv.YvxIw78aWWP71hfkLMCBI3NQZnog2YUeUtM.Xqw1pv0NBs0.5xIazhWMMJF7H5mA LT14OEri3Q00SBBVQPyZO4IahIRvEpsZZYkKkan4gkSCuwn6MpNakWdPGrYgDJw524twE9NRyAln y8MetSkBmOtt8_lg0sE8cI7JuZN2uL358m_56U3nINMusxXIH2tORmjJnSqF8K1oPeJSZgoyK6B5 pphaudK_fVp8sKDuHx4xcU1rPEUQ3bMLsBeHA2ReT5VkJo9vMwaA__GtXBpsUxeVFus152lONjDX HxgvdXR9zBJR.q3talP6UUy7wdmw5TXSP4rk.U3Ne89B32Wva9W3P_vDxcUgnyUdS0F9R5t2uogD MV6Zkw6oV6xlf7nz9zoexaxbt_durFBncts0APsjSp.0F4xiXOn5VfH9rPqYmqdB_lNp2I3VNIuy PTS3ABDLBfadk9ep11xg_hQsTwXm2qd6tS3I5556kRQdbgwiGDpkAtLAXGuHUw4xmH5fDTxvQWRF D_SMuuJtkh2QeNlA7S.En08lphFiAqMFaNOKcLegvXPwP8HfNUqIiT_mIDMwzvHcN5g0OOjt6rsR xc6wMvYsWzLT6xff4O7NSkIpi3Au_7j5eqqHyJ5.SM9Pr_azySLJ1BJnV9o5cg8wvLeGW9._qH4V Ub2DS9SHMJVI9zxUCop9amVA5qwb5W9v44Cdj4ZfUCZk7q3iPrIGNu39UNi4rMDM9pNxdV9e9fV1 TfDTDC0yIyOcXtMVHrPkkhyKkJu3XswxC32BqXSlgc3UHH9l.DCNSrg9xD3ROwATq5WNlSS1JJpg C8vti4gWyeJuGbMFodLSsHXglWN.HERkBSwXu4peYtT0fSicPz40Wp.bPFLmxxv..wwcYgKUqrHQ W0sMCuevaw3HbxnTpuJsbr1lJ5ohaHBHz8AHG7WntL_AVrdeCDmRuasKysOpSMUolHx9hZ2.Xit0 blWvC0EHPKEdjh4KUinDPyFQhDwQmfcUJPxtN5FIOTI9QMluxE8Ds8TbxXSFKPjxNDHgUOXHOJfT FcGi10_8b1I5NxlAgLnszik30LTpzw7QvGRpyvg1cwQp36vPOkIZf95pCbjPAvA.grfuFZGWinDY 5mHCyKgjPM6yOO_g2DVSLorZAjOgtAEQm5gTHgRo6vnZRjZiX1DJ41xFsJTXe7aWAvgTP0NPwXzr dLwKeNsNEoEnsn9S1GcVmUSNxxKdBZSx3Vpn480Z_1hlnjYAv.xzJmE4cOsk_evVYjGTCBw0ScX_ i0yIjqVH_bAGBypsW7u6kTyiOOzErmmiK1pB69kMF5M8N7kVYvr1rxMPBxUs0cbWrSYVc6GtuSWd i2uXPYWEJ8GAbEtBIC31enbcArPoq3oRfTxFzLBn_sXwmvH3N.m0di3j5Js4ijqSnJKxWAzrkqWj PgNL_z5sOYzDQTXGesoaZgen_YyK3XPrjK3sj6__lR5QhaDcn9ixa1_dJPjqx.H3LNgftBJKcL8T Uuj22CXyXjfiUEYzea2hlAUBzE8nuufnFnpK3JBwsJ5Ix.2M2bbLGzTE7ogjzSipv87uC84c8Ac6 _3mliyDonkYAuMOykQAwOEcinOJpmeorJTv9miDZ_lMk.0mrW8iWrRC0ESh_N.WNtBGWsqTYIQZd qcs_3FaO4EfFDlzvexQ4kLKJifeQPP.rlDGAEp7NP5PnIpj.dwcnMjWCkl3gGt9xgGxsH5cAvJWp etWZJX1wahnq9HWE6aIVOcVfPOK_N7eAOIpZJ_uvvVo6aqsPGQXQp_pxoVZ4Rkd2nGML9UdpNL.v 18QZLlmPwtHs2Szmct1ug.m6qDo3DTgV_Mmn5CYx8JCYstdHUPY6dTRNVPYQu3x4mpTj2OknOSnj UzQh5NBOrmausHMrnlaUV7NuXxtZQ73F3TEqUv0lSVGHIkoHUfsy7UxIZq0gWJPL5ROJTwAC1AuV MZ.jdMsKXwfc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 01:52:19 +0000 Received: by kubenode507.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cbdeb117bc215b00df562c6c59b85e29; Sat, 29 Jan 2022 01:52:17 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS context: used the whole swap space too] From: Mark Millard In-Reply-To: <20220129011429.GA58988@www.zefox.net> Date: Fri, 28 Jan 2022 17:52:15 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <77D2C785-3C81-46FB-804A-5948F36BA2B0@yahoo.com> References: <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <20220129002017.GA58768@www.zefox.net> <03306779-68BB-4C87-9B03-81756EFC519C@yahoo.com> <20220129011429.GA58988@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jly4p0Nmzz3KN1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dlWU79kI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1889 Lines: 81 On 2022-Jan-28, at 17:14, bob prohaska wrote: > On Fri, Jan 28, 2022 at 04:33:11PM -0800, Mark Millard wrote: >>=20 >>=20 >> The part of it that has: >>=20 >> CFLAGS.clang+=3D -O0 >> .if empty(DEBUG_FLAGS) >> MK_DEBUG_FILES:=3Dno >> CFLAGS.clang+=3D -g0 >> .endif >>=20 >> is important to limiting memory use for building >> googletest. >>=20 >=20 > The version on my Pi3 running stable/13 contains > CFLAGS.clang+=3D -O0 > .if empty(DEBUG_FLAGS) > MK_DEBUG_FILES:=3Dno > CFLAGS.clang+=3D -g0 > .endif >=20 > No differences that I can see. Okay. I'll note that flang is new to devel/llvm13 and, for comparison to historical build-clang memory use, I ignore flang. Building flag is not involved in buildworld. But the failures that you have reported were not building clang or anything from the llvm project. They were building gmock things. An interesting thing that I've noted in your reporting: c++: note: diagnostic msg: /tmp/gmock-all-836ef8.cpp c++: note: diagnostic msg: /tmp/gmock-all-836ef8.sh vs. http://www.zefox.net/~fbsd/rpi3/20220121/ which has: =E2=80=A2 gmock_main-f5c28a.cpp =E2=80=A2 gmock_main-f5c28a.sh Those are different .cpp files and I only have access to the gmock_main-f5c28a.cpp related pair of files. I've never gotten a failure for what I have access to. You have not reported the lldb result for my reply that listed doing: QUOTE To look at the different frames: (lldb) up 1 (lldb) bt . . . (output) . . . (lldb) up 1 (lldb) bt . . . (output) . . . and so on until #5 has been displayed. END QUOTE This was a gmock_main-f5c28a.cpp context. The "up" commands make the sequence more than just "repeated bt commands". It should show the source code of the lines of code in question for the specific frame, much like it did for frame #0 in what you had sent to the list. =20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 03:20:31 2022 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 6234B198E25B for ; Sat, 29 Jan 2022 03:20:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jm02c6WGqz4hty for ; Sat, 29 Jan 2022 03:20:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643426439; bh=jFrfs3cZAUtEdQjAozY8D5sN4ayJPVhzqgY1JWgnqzI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UN3h/aeoRg77asFg071edEad0NhSmF9uEBSdHXoikt3mTcCTl+puyXAGj3nrOamoNad1WCQA44RrGeZmRoAjBKyfAfwVBhIx7JHtk7MbtU90nWVnjD00Cuz53wyCBTOTdRBdJCGlkUx2mpw7OiOulOWskpTCiPFrzYlVLuZKnMHQJMXApZnQwpVDLIXm1rz921eYwennW5pEWQArQ0bT70eFNvXOhBSxtSsVttOSJ20Qvgn98GvdtZYdVkI3miFz+5osajy5zIqNG0iS83VJ3ZGBuwcHcCAhZFP6S1BXzQTagGD0FUgP7jXne69LP6tCDx2aQ+uti9TlefShyXrnRQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643426439; bh=1vpFJDjURXZDUVc5JlkVfI3j2dPLARInKxDzNfNKCqN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WFs3S08fa84Xj3ACsRg9g1veTjh/H1TFm9yOvUCnKZEz4ufOsxVPBy89LDLUNglG6GaUPwivNeq1yaLPzCXwcFs5vIYfK3ONrhN8or4vD9oGaRQlBQnWiDlQtZRpDNwcA3Risn9LCHxKj7o4XB0HwDWEKYrclg95BEgI48ivni9+QR8erGkAwB3M74l7qAAEbF13YbYVhRgQEEnoSVI5nu1jOL54XG+wArFy9yQaP5jhFwSZpEwOrsF+7AAn68nvju3F9uicq1W+/Zs9jt6bRcPm1iVyLyx32Kj9bt59NGKSIkjAj38gnuL9inINHy6IpOuSlR/UUdTj6WQN91Hl2A== X-YMail-OSG: X9eS6U8VM1knOEJStOZ.cD.LVTO2cg0_tfWtWsswrxqEUvOmNEu_CCM1B2m3KkX bAbNC7SCt57XslG6cCPcEo2FEO9UNyVOt0QWjn2abL0QvlzyawkY6o7YGhEiZFsNmQt9Bb9iyZ4t 4l0uu.xIzLomURWC1ru3wN9UrhE_6gNGJ15o3F6INO.P69JreQQDp_Dv0V0zFdX4LkTVutGJmCGm ip7a5oNJmYZ5TBpulqXRJOqiXi7lnn0amEFaKoFJOAdnvwe0FXHBkxnIOE4dgvm4_eSZ.TIYgLXA GkT7VYlrq7K08R9I93EkNo0473Z1fk7cW4z6TbTiJhHkxIwm3FVR6XAio7nMAK4isUCIRIoS0g8l .wqPNUYLaJK4_K4qwsA6RkAPg4CG_TyJ0fBpxGfp24Ygmhb87Q60gV3vxWhJDGadoWSUp4VZsCqM acyiEZuIC7xXxCWUoBE9_.KosgS9pLumFiFOHzm6_VAKpnfkayJkzBQVh8KQHdpzLsK4LNexj.aC laABgza2KIzY3XG5ODO_3_icpU2AhgTYT_CPf0i6mpM0xah5E293HqGsS8ErqtM.mwEA49o72xO2 _1hXLyRrXpodSF1TJLvFP62H4yq46FL81lYbRgiMPcxKfG3lxn1yKBWMJKWWcjeZrFE4g_9vW.Fl UPK1UDFrojgJr44K1BXmgjU8_8ryxCP8Ft5FLUCZp4YhsxTrEjBQDUoXXlFQwyD2d88gj5WEGzW_ zTz1gMBMwbMPQi6ZGhHrk8j781Uk2rYlwy731fk003C3YMs3rN8iEOmfGiY5jz_zdfDZ.Lm6HOPE 85I99qiS0aq2416QBqI3gUIHp1qlbgvh_W1oZxAiufJsbkZHD_m2Rts9pGjtVo7J_lHIX9A6CBUZ dEcz6J3WNXYP0KFM_jSox8igDIJjKDUq11vKx2oKU6OXHUYVtxg6S.wHEdgnmkQBjm9AxHSHCbLt UEuf7rEMbdxEYAR2a9tKP9x5u5cSn3WAygWFv0GL2KyYpF3BP18a9qcwM0CqI3jfCs.L77EhmqBO ervHAhcfTp64MGWBui4IEitnvis8DNEUknrjNEss2JHwlrDngt0vLRNZJqixkWMXvkzh8U2WNo1i MiRhZc3xN_2_kMhoQNG7q2d0F8Mn.wuaNEhHpT7lE6dor8mBUWDDelMRuNLpersYZerjfmHByT8C PxsInnb1SKQObMJReZFW3qP7njT.92L0rXS8oa__MorVKKy6toVmHt8Mv7oTfQ2ppCazRJt885Ag HIqvxh5SfSvrjReRHsw.DAONY2RBQi.7_UKRxejfqxhhWlfzB1kI4cdlQJqDIjDlGJrZyxplxbBG AguIfpANOgwJbDpd_zPY2kVd1u5C7zqW8EZH05VzIlmCzg.zSrgf4tQkRC.23rUevNZompA6Z8zU z26XzoWhYUnRwqyCJmFzaztZaCe1IL60vMQE8ZW66yf7eSAgqJDH..paGW_js16ELQ6d2wIFWg0O qBdbyLaqEZyFvCgWaWEeN9bLOf896XA1rxnfQTIXLtC_sDAg1dx6ATQ._e46Cml6UJAd5JeB3zfQ 5GP0fF4L49uwvU_rp4hCOrJ1uLW1jcLKv069_9olfdQSz51LsnxGWWh4GL7uzEYODM8o6WvsKtVS bvbr0bYxEPKH2UD3B2yrmTNztQR8pSQ7wk.lU0DPwzSCu2cscJzYt0zpDL1tv31z3zNJFwV9H2au yvw.4.GYmh4.SIKNi7Lrto6OwqnsSziAOrQcSwkwhj2N9LzCCcJoOPHRuWMPMuu0.Kwuu_2W.K_y KDWR4oygSB2eWoND8y0hIm4JNOPJFPYd7Q0Zy9V3t3UdeJm3198HOk_18NcMpJwB1Ar56H6BfJAn Hu8qH02ewxbWT5uk_SJM5gEguQbdt9D1LuAUlL..reMegeORrHPbkJOefKjhIOzW4awh9Pnc2787 rkk4Hyocpb1jK3S54tN6Huj4dcqmHwcYNEaK0shFmLRQlUt7Z8zftaNB0hMheq56JrYwFNWjIJUU HEjEJ0t34BOYgVSeHMkT36mb9y8SzEECwxbpDgqjPMMIXuJZPX93fTdDf.upppAzgt_Wp0DZ6iSf DAglW4b1wy1Rb6ixhHh.tyWtlQhHEu5EJ6OhnfnXuN_HJitEg7OP8DR.026LnMYdcb1o_jr8BUK3 yTpLTSkuOWpVdLLg4QZqdpElYjB9hzuiwIXTvawi0SjGGCj49bFlGpDZHgIp2z5znByixrSsXowG WBO2jX.lrG_SJlXyb3.IgpQNErSTTdkHksc5WBTAkrfSdu3D1rUMGNGv14qoi5zfDpa7WS33M9c4 Qr1VLcE7ZButj X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 03:20:39 +0000 Received: by kubenode507.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dee4b9a21438726de1f38eb789b4d731; Sat, 29 Jan 2022 03:20:33 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [ZFS context: similar to UFS] From: Mark Millard In-Reply-To: Date: Fri, 28 Jan 2022 19:20:31 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <6D67BFDF-D786-4BB7-BF2D-CE4D5532D452@yahoo.com> References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jm02c6WGqz4hty X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="UN3h/aeo"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 11642 Lines: 352 On 2022-Jan-28, at 15:05, Mark Millard wrote: > On 2022-Jan-28, at 00:31, Mark Millard wrote: >=20 >>> . . . >>=20 >> UFS context: >>=20 >> . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 >> . . . threads: . . ., 14 MaxObsRunning >> . . . >> Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) >> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >>=20 >> Console: >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(7): failed >> swp_pager_getswapspace(29): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(10): failed >>=20 >> . . . Then some time with no messages . . . >>=20 >> vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 >> Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >> swp_pager_getswapspace(2): failed >>=20 >>=20 >> Note: The "vm_pageout_mightbe_oom: kill context:" >> notice is one of the few parts of an old reporting >> patch Mark J. had supplied (long ago) that still >> fits in the modern code (or that I was able to keep >> updated enough to fit, anyway). It is another of the >> personal updates that I keep in my source trees, >> such as in /usr/main-src/ . >>=20 >> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >> index 36d5f3275800..f345e2d4a2d4 100644 >> --- a/sys/vm/vm_pageout.c >> +++ b/sys/vm/vm_pageout.c >> @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, >> * start OOM. Initiate the selection and signaling of the >> * victim. >> */ >> + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", >> + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); >> vm_pageout_oom(VM_OOM_MEM); >>=20 >> /* >>=20 >>=20 >> Again, I'd used vm.pfault_oom_attempts inappropriately >> for running out of swap (although with UFS it did do >> a kill fairly soon): >>=20 >> # Delay when persistent low free RAM leads to >> # Out Of Memory killing of processes: >> vm.pageout_oom_seq=3D120 >> # >> # For plunty of swap/paging space (will not >> # run out), avoid pageout delays leading to >> # Out Of Memory killing of processes: >> vm.pfault_oom_attempts=3D-1 >> # >> # For possibly insufficient swap/paging space >> # (might run out), increase the pageout delay >> # that leads to Out Of Memory killing of >> # processes (showing defaults at the time): >> #vm.pfault_oom_attempts=3D 3 >> #vm.pfault_oom_wait=3D 10 >> # (The multiplication is the total but there >> # are other potential tradoffs in the factors >> # multiplied, even for nearly the same total.) >>=20 >> I'll change: >>=20 >> vm.pfault_oom_attempts >> vm.pfault_oom_wait >>=20 >> and reboot --and start the bulk somewhat before >> going to bed. >>=20 >>=20 >> For reference: >>=20 >> [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >> [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>=20 >>=20 >> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp >> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >>=20 >> So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >>=20 >> Notably, the specific sources being compiled are different >> than in the ZFS context report. But this might be because >> of my killing ninja explicitly in the ZFS context, before >> killing the running compilers. >>=20 >> Again, using the options to avoid building the Fortran >> compiler probably avoids such memory use --if you do not >> need the Fortran compiler. >=20 >=20 > UFS based on instead using (not vm.pfault_oom_attempts=3D-1): >=20 > vm.pfault_oom_attempts=3D 3 > vm.pfault_oom_wait=3D 10 >=20 > It reached swap-space-full: >=20 > . . .; load averages: . . . MaxObs: 5.42, 4.98, 4.80 > . . . threads: . . ., 11 MaxObsRunning > . . . > Mem: . . ., 6482Mi MaxObsActive, 1275Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) > Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 4096B In, 81920B = Out, 8192Mi MaxObsUsed, 14733Mi MaxObs(Act+Lndry+SwapUsed), 16007Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >=20 >=20 > swap_pager: out of swap space > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(25): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(31): failed > swp_pager_getswapspace(6): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(25): failed > swp_pager_getswapspace(10): failed > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(27): failed > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(11): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(29): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(20): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(21): failed > swp_pager_getswapspace(11): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(21): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(20): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(16): failed > swp_pager_getswapspace(6): failed > swap_pager: out of swap space > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(30): failed > swp_pager_getswapspace(1): failed >=20 > . . . Then some time with no messages . . . >=20 > vm_pageout_mightbe_oom: kill context: v_free_count: 7875, = v_inactive_count: 1 > Jan 28 14:36:44 CA72_UFS kernel: pid 55178 (c++), jid 3, uid 0, was = killed: failed to reclaim memory > swp_pager_getswapspace(11): failed >=20 >=20 > So, not all that much different from how the > vm.pfault_oom_attempts=3D-1 example looked. >=20 >=20 > [00:01:00] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [07:41:39] [01] [07:40:39] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >=20 > Again it killed: >=20 > FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o >=20 > So, basically the same stopping area as for the > vm.pfault_oom_attempts=3D-1 example. >=20 >=20 > I'll set things up for swap totaling to 30 GiBytes, reboot, > and start it again. This will hopefully let me see and > report MaxObs??? figures for a successful build when there > is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler > instance (mean). The analogous ZFS test with: vm.pfault_oom_attempts=3D 3 vm.pfault_oom_wait=3D 10 got: . . .; load averages: . . . MaxObs: 5.90, 5.07, 4.80 . . . threads: . . ., 11 MaxObsRunning . . . Mem: . . ., 6006Mi MaxObsActive . . . Swap: 8192Mi Total, 8192Mi Used, 32768B Free, 99% Inuse, 28984Ki In, = 4792Ki Out, 8192Mi MaxObsUsed, 14282Mi MaxObs(Act+Lndry+SwapUsed), = 16009Mi MaxObs(Act+Wir+Lndry+SwapUsed) (I got that slightly early, before the 100% showed up.) swap_pager: out of swap space swp_pager_getswapspace(10): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(16): failed swp_pager_getswapspace(5): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(8): failed swp_pager_getswapspace(12): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(32): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(17): failed swp_pager_getswapspace(21): failed swp_pager_getswapspace(10): failed swp_pager_getswapspace(18): failed swp_pager_getswapspace(6): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(14): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(5): failed swp_pager_getswapspace(25): failed swp_pager_getswapspace(12): failed swp_pager_getswapspace(5): failed swp_pager_getswapspace(7): failed swp_pager_getswapspace(10): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(24): failed swap_pager: out of swap space swp_pager_getswapspace(11): failed swap_pager: out of swap space swp_pager_getswapspace(17): failed swp_pager_getswapspace(5): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(32): failed swp_pager_getswapspace(15): failed swp_pager_getswapspace(19): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(25): failed swp_pager_getswapspace(11): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(15): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(8): failed swp_pager_getswapspace(31): failed swp_pager_getswapspace(26): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(20): failed swp_pager_getswapspace(4): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(15): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(7): failed swp_pager_getswapspace(8): failed swp_pager_getswapspace(17): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(10): failed swp_pager_getswapspace(6): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(11): failed swp_pager_getswapspace(21): failed swp_pager_getswapspace(1): failed swp_pager_getswapspace(9): failed swp_pager_getswapspace(32): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(32): failed swp_pager_getswapspace(25): failed swp_pager_getswapspace(21): failed swp_pager_getswapspace(22): failed swp_pager_getswapspace(14): failed swp_pager_getswapspace(10): failed swap_pager: out of swap space swp_pager_getswapspace(1): failed swp_pager_getswapspace(28): failed swp_pager_getswapspace(2): failed swp_pager_getswapspace(13): failed swp_pager_getswapspace(3): failed swp_pager_getswapspace(31): failed swp_pager_getswapspace(20): failed swp_pager_getswapspace(2): failed vm_pageout_mightbe_oom: kill context: v_free_count: 8186, = v_inactive_count: 1 Jan 28 18:42:42 CA72_4c8G_ZFS kernel: pid 98734 (c++), jid 3, uid 0, was = killed: failed to reclaim memory [00:00:49] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 [08:06:09] [01] [08:05:20] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-complex.c= pp.o and flang/lib/Evaluate/fold-integer.cpp was one of the compiles going = on. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 06:43:39 2022 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 D428D1985795 for ; Sat, 29 Jan 2022 06:43:52 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jm4Y33gZwz3Cm5 for ; Sat, 29 Jan 2022 06:43:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643438624; bh=NB8P9feHpbvav59O1Tuuj8DDg7rtJCAtU0s3Qqpc4MY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KkJFua5xcouwmVuqzv/3fv7guNvPYbREWkfw7apPv+U8W+9QZYHQ7xW3L6Gxjr1iz2m0PGCHr2WNfKNrM78RWXcywA1aEDE+bt3d+tCTcV0okzv59mUy+Ka9psqfKDcWzUN+f2dMGVylIFMGT9sBsY1T9TQl5uq13n8LBDqg47spqmgZ5ItDsm4UdT7MLyuFf4COwVV8LMKxB+SCnZL64oekvuOtf9IMY0EZOkbo/DlvkOTLBhwcAa3K+aMQWjAh05XSbEf4I1JRc91UclJYJFAYI2V1FiacH2/9mc3EZnvBekkYZFJc1v5IEKCdKr/XuQXK2kmKQYbcDnTd2ELAkg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643438624; bh=fFAHoWupOrgpfc7Fd4SwsMQs01Fn9D9iXkgXoScHxBM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rap942vEnr2esILKzBtf4Fr1Pg5q5w3t7kjNSpJPMAq+x7g7LIWLsG2VwHnzP5GwPklxl4+SX+9ez+zB34fbzYpT9Y92aiuTu0soheF1CjH+DEAjMV6d2eXl9TpG1G16fd+Wc8AY0qZXE3bSFgeU+6t3A4UY7D/19xvRRz2fEYi3qjIOwQZVoLwCKFYvxpJRdykIQno8RzVjat0V1InSFF/08v84YVRDBeTNDSxBkkoBjX1bvkdxm66S1DmJ7u4i7j782JQaTIdv1ZtBTpgz33iEGb9PZhzSHSB4UJMKREl7wvR4sl5pg39Rhl1CXqR/RlyZwHjKnfq4VyEjK0TLqA== X-YMail-OSG: oF_Iki0VM1nirl3f83K16MXuM9mw_5uHeTIzL8tBWXaQ49TsR8t_HHnETyVjwYM TRbh6Mne4ngVDt3InK97f6hjB9HZ1m3qyHqImyla9XJfJRngcxocNrVTU1nM4tZLd6_SUrytDyY0 FSXu7iY4iZmmBXpLtVXolC4yH1NCDr.wz9hZKlvIIcEmMTz4MfU2bBLJY4C8fcE.7kDkEoLLcgyq hQfgzgjjeDg.ZdW_CvLChfj41wGPygH6lutW.y1YndIOx6H.gzFzGGbMESbfvz3cojkx_rq2eZ_T lRs8r8d_Ywf7FApo4lS1xk_6ClI1R8GBUQ9Dvd1JULXXL_gLCfRVWF5wkqPlPARJfWguPVkLrCqd aNKXxJA4JfHpu9QoKH3WpqSFKtxIVqe.4WUjkjUrJVebWm1HsNE68Ijz0j4dJhzaZXiYSOdEHwGo vqyKSvOXT2bBvbu2GVACltPU2Wxfuftayz8MxQPQK6hErzKbZslHDu0xw1OjQFx7dNBMKSZZe5DN VpSZuznl3OVmWVAHe.KENo_cwdzzqEwBDw017fMH52f5OOUodUWmSZs9sXKCIA7b7vQ_ELL.CNWg ZWGEKYTjAwgjmlYuSwW7gDaeD7ExU9QPiI8PiYnY8CSL76bOgUcfMkGWmOq8TH79FlmIUJUhFiRL c.quk8Vkzfy.ZDHugEdRnF7UW31VKGkgIj.rxl1lglj.SZpAmwgiQzimoQgfGygvSf5FvSQmTCfe .7Ily.6bXHOfKFZ82c7S2N_IwQ0oH.1JgFETtcHuLTGbuFoRBoiCPKKVhTPrUDomkQbq55id7WE. PHJh6rrm1PCoHeqA5FwsOC7hjQy82RrxG2H_2gNoUSwjwJIsV6hlWtH7NPyelS_HmcdLNP_POKtZ RCxCbfJfTEf_yzADZI0VK9djNZf88DxAvSsenBkz9jF5l2SRGhY6pkspWjcv9yz8JfzoD5MUEuzY n8KwihXvVuSHaTVbtFt1HIjDMrMGwVhzxViIgylDsvNOeKomrk5FHGbvnPgd22LdJORpmEW5Up1P dxq2aDk06x9m8pfXomGP.RmeZ4ohaq7vkTNqqLVEHTo7CkUc8IAg1Y2rbd_TVm_xHjtNBEBlMkEW BxnymfiUcimn_Bu2gAUEJKz216QcNNlPje_CHFSlP1XIyxqJFwl37LGvdJGtX3_4SCSLwH20xZIz MZaiAqg2PqnMFhyoO9d1OuzhZkwq_Fapo4Cp8hwflLWVLXffMeC1zHishvdaeBezMu4f_Ej71U0M AJW6jrd1Ofr4yEL04fjIxYAEv0D9SIRFjX4qocj_Oj49v4LaO9MsoJfR3uVXfY5blSMCYL1Ry.6z fBymNywSZOzjuoVqNHBV8Wq9xEHnFyZiDrxBW89_akGcS4HIPRxZf4l4iuO6xiLo2v1.X0nWwdsb zeT7jEBdI.5VeaH6xnx.3cx0J6i7VZ7mq0Mpoh8SIkVjmNwYZVYNm1jbVecLiviDEp0TCymr9vHh uLaRdBJWvHG6TxhQ7..Qb.eRPO3PJcNzQVeZyg0Hk3TUD8M0EZTFzbpQ_aSpkZZGXNNic34Jp02W KuHZ6wEesL_eqIjr_Zr_Put2RMAuY6GspBWTATC6.asCrWmKONbj8rZVHa.9wirpkkdE5D28VE20 Ov2V9ZAtwhcbrD4R0O68BMOY5Eex5QtohdlT.bQI2Mn63OgsyGxQOWGKZV_N04JKbulTjzuYXqgs 48jnYKd3hIVSAP4qTzxTX5_Qg5aQ5SEVN.2wN5uisEfhs8OBCaYrRFVzDlrB2u4NLz0cvmSY0Z14 70AvaYj1AcWeDooDvazRDGTQHubQUUI4PRQh70HxOSmu7AMkkuTL8hOq7FEKD9WF4AycLS2LyZRu 0KJKl4O4dxNoQkq6UG2SLsoHpaVOSqdA7B0ysE1ptRtehk9kGJMP4cfSIa1W8NnjjPIxI6kp4ttJ TsirpfpU6tX_glhkwA4HZCDeP.h3EHJGQIXNTvwOoKmZvK1FHtqtq3FjkVZG4XNMY6RQSA.qE078 h9NMCbExbdMT1fJItuGoWMYGD0s5Lwg.wBHfC4S0PPGeEqyah0iGX1nAXKUXDK2Z69LFNAMVORnQ jkE5Tk5L7l8eaUNWi7I0jioxeN0dHkYkE4WxXZLxgTfdo66Lel98WhwEhQV.C_xwPrGYxc1bDX7q YWuILCBNjJwvj__5jzReMtWr8Wcmw9IDRPCKmyyn64m6gQBilFYu5ckTEigHSyBwHfIHv3HhUakb I9r46dlB4FBeGzhL43YPZT6J.cCHpMRZkp1aCXjbomKhprEfMXSBGDQJuXOz7HhntNSy4bESbERz fdiohxizkxw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 06:43:44 +0000 Received: by kubenode533.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID eb40e965ae80ec12bf894b316a0d80e6; Sat, 29 Jan 2022 06:43:40 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> Date: Fri, 28 Jan 2022 22:43:39 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jm4Y33gZwz3Cm5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KkJFua5x; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2656 Lines: 78 An FYI: I do not have problems building gmock_main-f5c28a.cpp --even with no swap at all on an RPi3B: # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% # swapoff /dev/gpt/RPi3Bswp2g # swapinfo Device 1K-blocks Used Avail Capacity # ./gmock_main-f5c28a.sh # ls -Tldt gmock_main-f5c28a* -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp You could try such on other aarch64 RPi*'s and see if any of them require swap space to do the compile. (The same for any other example .cpp and .sh pairs.) My expectation is that you will find that they do not require any swap space be enabled. This is main [so: 14] instead of stable/13 . My only stable/13 environments at this point are bectl (so under ZFS). I do not not try to use ZFS with less than 8 GiBytes of RAM: default configuration instead of tailoring for smaller amounts of RAM. But I've also built under stable/13 (with ZFS involved). top did not show the build of the .o using significant memory under stable/13. Part of the point of the .cpp that the compiler generated is that it uses no include files: everything is expanded inline for the source code. Thus, no other c++ source file should be involved. I got the copy from where you posted it. That it builds in my context indicates that it is unlikely for your or my copy of the source code to be corrupted. That leaves basically compiler binaries (and supporting files) as potential sources of variation, possibly via corruption. (This was only the production of a .o file. Fewer toolchain programs are involved.) For reference . . . Under main [so: 14] (UFS context example): # c++ -v FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) Target: aarch64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin Under stable/13 (ZFS and bectl context example): # c++ -v FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) Target: aarch64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin So, for as much as the compiler identifies its own content, they are supposedly the same, other than having a different default Target FreeBSD variant. (But I do not expect that the compiler identifies something unique to the combination of FreeBSD specific patches or other FreeBSD choices that are involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 11:59:40 2022 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 3837E19759EF for ; Sat, 29 Jan 2022 11:59:49 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmCYb6F7Wz3Lv3 for ; Sat, 29 Jan 2022 11:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643457586; bh=a6nUXhGntzgTw1TyQW0C+grWUXfdz2fVXv1TFdvDSQU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sXlwQC6BwMn7fAjGZL6yJaHOy5NBQvRNvidxIRvi0adsXHM0FUg/V5eqZ2ohv3JlsIEzh3OiBdEhq8W64GMdEvxFLVn5x+1hV5dDfPv/vTb7N9+bT2BQZRHCjPwsZTAUsQMUOaIYSPRYch8UdGbPLXxLGrvLNEi93Pvo6EiYWpTB+KbRJ6xcFAEaKqBCwyTOsEQ7FprVGt1EWtuGnDF8tqAfl191UWF1xi99EFugDWz1fE39/+wJBTUmk2tOaYq2CD5VJP/JZrX3zmDvckmsfz9Fl3p8Gzz+LKPyjZvmGFPei1uLbW+xzZG5UeHFjp4Wx7gpOwTvoGwYQmA2W7UwJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643457586; bh=DXMHGrfQy4yisMrCRTQ0C26lsVeDpfM8cupb3ar4X6T=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DWvF/ehYRHF8XqChdznDw/1aXXySJ2frk4so1MNxwLdJEglLU8hHevancJNdp9QHKFZA3zpz4SOoDZpxVYwrvSUFWOpDwrY4XL/9CwrlFvgxIRkAejQNQgJFOcmnT05n0TLFtt4pICkw7UbVumvfOhQg2oUufQ8RQbzRu0Q2ASCLvgOfHCNapwjs/CoQk7fDFAdzg4KroFeieWAuF3lDmd6RBXlD3pkTmpOfs2iuhmyuJcq3pZ5Ol6w79ye3q5Sm+sroLbHD5/a5Et7anu15JbWFkIGRjA4SNphFXIqCryzLZaGT5M8oVgEgE2sMTSOppsC3nI64rK8zvnwdaAVvZA== X-YMail-OSG: 7KsHNvsVM1mf7rA21jeGp0vhbY2_x0oj8yxUyLbEj_bK81z1uoLd0FCe2wEzWiu C27YYfvs5AgtLnMOLURM8wdGcbjpJoFoxkXRkWGKgn6O1b17nroq4_5W33av2AIy40t1EmvnePZ3 YZtDvitg5Eo4vHGPrOf707tZAb3dKWBn3kA6a5o8fqwb09dcDidQb6fX6FCkx7_cw0Gmy7.ER8Dp fgMy5jQpD6CN_gUm6.m7BYPiJiq6hYzIcBAt74Mrv.FJ3QjIeXh5jJhoyEjQfTkflIqqh.22flCU 0VEaj2HeT8dRw62P_toP9YV0EWofcdfG1YQx.sXI5WvAXuc4O.13tkPRl6.PMvF_QN0l67V0IlJX A7kl8u2bjwxUxsi2pbMb.JH_fCnzBmX8U9P1u9MLOczNWm0eGW.h832C7IjIwFyDoujev7bk7QP7 zvFILoblKqQbFY6fzaLAq_5VoRbupQfTGftIUnORJChMgsJd2MVuGjOX7IZXOsbKgV9bjzuY0hTp unvjb.2zII0gCiuoPewG5YtI.mEXXxcdmZKuz04tR9UVnuHt_Mt44UIG1aV0qTPSBSRaj5ErBbVW i.WyZ_tURVTxipTAw3yr._8qUimuUpgo912GcK9whz62F.vQcib11hWVzn46Qwds39VsybUIuSMv x1Akliqco14Vw136vADCSWM9HqBIcY2duTWW8JGO7wRYHyLq1ZFA2gFheJ0rBCS9NJWMAhVTn2MP 3FcMcIHpXiKzzoew2RYf8Q0fIeUgpHi2qo.QwyilgT21XkAUZ_PKwCyL261Uz.vgQuuC1_K7Nphi cej2wBEVirQZZzYwskVP_s9Sov1i_xe6duva3SLXTajAUaL5G94zTKbZDuOO40BQ_GbBbqU0oipE UhhjjowDQ4lva5j0iP8.gapeN3IgQBPMipeZvCqI7xT4TtX1tToi4RAvSiXXLX_8DGnR1mPzbFac JvHAfoyXkVrLdBP8GBx1XkmjeD1JQIEh_AUtWYA6ix2NmveMLDayu3YJRhNSIE9PvS2Zgcrde5Nv O.gsPFLLhVvusJ.DECA.Dkh2UOJrZYKM8LNaQy3zoijYmIaiSH9Zww7XGyJ.Zz.hH8Q28CBK7BX. FVhnsLrMit77yUTU623mqeH_3WG67vLBPit9KDG3.4xU1YYSZuueS5FSNSFceDDwqGhl1_DGS3G7 bEXlQoLgGqVW1fEMLgDg.ihex4f162pz8cR46pnbdnYPy.VlieA6qZo.2Gt1Y2hZhfOvuuxY6DIl dcxh6_0LP7su6Hz7zAxiB9RiqhH2jZVG5kCqB9nhM1.zugQ9ovadXtg1nMtm_tUg1Rru7hs3PPF8 UI5WAtNTj_t4ePVBR_U7ykB8wtp9l7Y6cy1jSkXePenaa4L5MHVuVEu5CgwjO08TDuvKNWhqfESR 7f_SvYjMoF96QoH06UFYyMiX9q2EPfE3_z0b.A6e6eBTdYMmfpqp1E0SfMphRJLDjTxRkjDpTsWj vOQ0apc97OgR0WIopV9tAPdjFbubL2A3px0715_xajzmE3mP_XbKK_RR7sTui0DeTkzfAWFYBdrf YLNEpGrrwouFZgpqwNItDcE4bdlp2dSRKDRkbdih3iRvPYdy8LnVFTv.Aahks2e8RlPJ20U4_c1p pOGHL_D6yUoMIMd7p4RC.J5Jvr08OGWRtD9xMU9wy8Cgyg9mQKepCWoJRtIt17W0na1mSixEcAp7 iDDExMkvh3JStzp3qH21H1sf2hsgvkbcnfNFzm7epQK9cxzTVtRa7nKOxeIeuACcmqhXlQk9lsag dfS.lBrnnVSS4RBw07mgZZcICDcXc2QZSH.AOOaXi7Fo1pHuyawGhY4WgqpkxZDyfMi3pth.ruUS cekLIypN2Je2xrckPgNTXp0jZaGM0q1utOLyKypIFqjIspqcZSfg4uOIeCtaprfMN9n77GxpIiJt L6Sa.E_kP.3tDWJ3IJVLXnLNdv7pftRGpW2qh6bn5nfFHYBy05aHLumoQSezuCw.yLaIvBXvZ5ls RrrVtC8pFlAu.QYoGLsQrrp5geEIrpNUxmUNtGpQ5bO81SnYYS8l5Zm9YvpsLpjYpefh8JrJJjJ_ mH7vTZuyqx.9d8jN9hAYBmY0axvWq9Lt3FVOyqPTrkWiGVOq1K2wW8wfMdSR6c_v5L4.nPtBUdDo mtYO5IYPLjHOIwObhb89.mSChG2zs9jMVvarJU4FW_wg_McxSjECDC7Vkfjxb858Et.B5SCMsC7J EID_biDg33rIzqeYOWdW3mS8ihhTLlFYHylZCJuYdCUq3LHz_vi7071xXGffRvyD1DGYgijgMA_i OTzthkYyizKikq2aS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 11:59:46 +0000 Received: by kubenode519.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0db57142e414275bdfdc4e7dbd8d36be; Sat, 29 Jan 2022 11:59:40 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [ZFS context: similar to UFS] From: Mark Millard In-Reply-To: <6D67BFDF-D786-4BB7-BF2D-CE4D5532D452@yahoo.com> Date: Sat, 29 Jan 2022 03:59:40 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <6D67BFDF-D786-4BB7-BF2D-CE4D5532D452@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmCYb6F7Wz3Lv3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sXlwQC6B; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 13073 Lines: 379 On 2022-Jan-28, at 19:20, Mark Millard wrote: > On 2022-Jan-28, at 15:05, Mark Millard wrote: >=20 >> On 2022-Jan-28, at 00:31, Mark Millard wrote: >>=20 >>>> . . . >>>=20 >>> UFS context: >>>=20 >>> . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 >>> . . . threads: . . ., 14 MaxObsRunning >>> . . . >>> Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) >>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >>>=20 >>>=20 >>> Console: >>>=20 >>> swap_pager: out of swap space >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(9): failed >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(7): failed >>> swp_pager_getswapspace(29): failed >>> swp_pager_getswapspace(9): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(10): failed >>>=20 >>> . . . Then some time with no messages . . . >>>=20 >>> vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 >>> Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >>> swp_pager_getswapspace(2): failed >>>=20 >>>=20 >>> Note: The "vm_pageout_mightbe_oom: kill context:" >>> notice is one of the few parts of an old reporting >>> patch Mark J. had supplied (long ago) that still >>> fits in the modern code (or that I was able to keep >>> updated enough to fit, anyway). It is another of the >>> personal updates that I keep in my source trees, >>> such as in /usr/main-src/ . >>>=20 >>> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >>> index 36d5f3275800..f345e2d4a2d4 100644 >>> --- a/sys/vm/vm_pageout.c >>> +++ b/sys/vm/vm_pageout.c >>> @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, >>> * start OOM. Initiate the selection and signaling of the >>> * victim. >>> */ >>> + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", >>> + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); >>> vm_pageout_oom(VM_OOM_MEM); >>>=20 >>> /* >>>=20 >>>=20 >>> Again, I'd used vm.pfault_oom_attempts inappropriately >>> for running out of swap (although with UFS it did do >>> a kill fairly soon): >>>=20 >>> # Delay when persistent low free RAM leads to >>> # Out Of Memory killing of processes: >>> vm.pageout_oom_seq=3D120 >>> # >>> # For plunty of swap/paging space (will not >>> # run out), avoid pageout delays leading to >>> # Out Of Memory killing of processes: >>> vm.pfault_oom_attempts=3D-1 >>> # >>> # For possibly insufficient swap/paging space >>> # (might run out), increase the pageout delay >>> # that leads to Out Of Memory killing of >>> # processes (showing defaults at the time): >>> #vm.pfault_oom_attempts=3D 3 >>> #vm.pfault_oom_wait=3D 10 >>> # (The multiplication is the total but there >>> # are other potential tradoffs in the factors >>> # multiplied, even for nearly the same total.) >>>=20 >>> I'll change: >>>=20 >>> vm.pfault_oom_attempts >>> vm.pfault_oom_wait >>>=20 >>> and reboot --and start the bulk somewhat before >>> going to bed. >>>=20 >>>=20 >>> For reference: >>>=20 >>> [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>> [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>>=20 >>>=20 >>> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp >>> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 >>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp >>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp >>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >>>=20 >>> So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >>>=20 >>> Notably, the specific sources being compiled are different >>> than in the ZFS context report. But this might be because >>> of my killing ninja explicitly in the ZFS context, before >>> killing the running compilers. >>>=20 >>> Again, using the options to avoid building the Fortran >>> compiler probably avoids such memory use --if you do not >>> need the Fortran compiler. >>=20 >>=20 >> UFS based on instead using (not vm.pfault_oom_attempts=3D-1): >>=20 >> vm.pfault_oom_attempts=3D 3 >> vm.pfault_oom_wait=3D 10 >>=20 >> It reached swap-space-full: >>=20 >> . . .; load averages: . . . MaxObs: 5.42, 4.98, 4.80 >> . . . threads: . . ., 11 MaxObsRunning >> . . . >> Mem: . . ., 6482Mi MaxObsActive, 1275Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) >> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 4096B In, 81920B = Out, 8192Mi MaxObsUsed, 14733Mi MaxObs(Act+Lndry+SwapUsed), 16007Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(25): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(31): failed >> swp_pager_getswapspace(6): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(25): failed >> swp_pager_getswapspace(10): failed >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(27): failed >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(11): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(29): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(20): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(21): failed >> swp_pager_getswapspace(11): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(21): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(20): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(16): failed >> swp_pager_getswapspace(6): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(30): failed >> swp_pager_getswapspace(1): failed >>=20 >> . . . Then some time with no messages . . . >>=20 >> vm_pageout_mightbe_oom: kill context: v_free_count: 7875, = v_inactive_count: 1 >> Jan 28 14:36:44 CA72_UFS kernel: pid 55178 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >> swp_pager_getswapspace(11): failed >>=20 >>=20 >> So, not all that much different from how the >> vm.pfault_oom_attempts=3D-1 example looked. >>=20 >>=20 >> [00:01:00] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >> [07:41:39] [01] [07:40:39] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>=20 >> Again it killed: >>=20 >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o >>=20 >> So, basically the same stopping area as for the >> vm.pfault_oom_attempts=3D-1 example. >>=20 >>=20 >> I'll set things up for swap totaling to 30 GiBytes, reboot, >> and start it again. This will hopefully let me see and >> report MaxObs??? figures for a successful build when there >> is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler >> instance (mean). >=20 > The analogous ZFS test with: >=20 > vm.pfault_oom_attempts=3D 3 > vm.pfault_oom_wait=3D 10 >=20 > got: >=20 > . . .; load averages: . . . MaxObs: 5.90, 5.07, 4.80 > . . . threads: . . ., 11 MaxObsRunning > . . . > Mem: . . ., 6006Mi MaxObsActive > . . . > Swap: 8192Mi Total, 8192Mi Used, 32768B Free, 99% Inuse, 28984Ki In, = 4792Ki Out, 8192Mi MaxObsUsed, 14282Mi MaxObs(Act+Lndry+SwapUsed), = 16009Mi MaxObs(Act+Wir+Lndry+SwapUsed) >=20 > (I got that slightly early, before the 100% showed up.) >=20 >=20 > swap_pager: out of swap space > swp_pager_getswapspace(10): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(16): failed > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(8): failed > swp_pager_getswapspace(12): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(32): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(21): failed > swp_pager_getswapspace(10): failed > swp_pager_getswapspace(18): failed > swp_pager_getswapspace(6): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(14): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(25): failed > swp_pager_getswapspace(12): failed > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(7): failed > swp_pager_getswapspace(10): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(24): failed > swap_pager: out of swap space > swp_pager_getswapspace(11): failed > swap_pager: out of swap space > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(5): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(32): failed > swp_pager_getswapspace(15): failed > swp_pager_getswapspace(19): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(25): failed > swp_pager_getswapspace(11): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(15): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(8): failed > swp_pager_getswapspace(31): failed > swp_pager_getswapspace(26): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(20): failed > swp_pager_getswapspace(4): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(15): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(7): failed > swp_pager_getswapspace(8): failed > swp_pager_getswapspace(17): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(10): failed > swp_pager_getswapspace(6): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(11): failed > swp_pager_getswapspace(21): failed > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(9): failed > swp_pager_getswapspace(32): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(32): failed > swp_pager_getswapspace(25): failed > swp_pager_getswapspace(21): failed > swp_pager_getswapspace(22): failed > swp_pager_getswapspace(14): failed > swp_pager_getswapspace(10): failed > swap_pager: out of swap space > swp_pager_getswapspace(1): failed > swp_pager_getswapspace(28): failed > swp_pager_getswapspace(2): failed > swp_pager_getswapspace(13): failed > swp_pager_getswapspace(3): failed > swp_pager_getswapspace(31): failed > swp_pager_getswapspace(20): failed > swp_pager_getswapspace(2): failed > vm_pageout_mightbe_oom: kill context: v_free_count: 8186, = v_inactive_count: 1 > Jan 28 18:42:42 CA72_4c8G_ZFS kernel: pid 98734 (c++), jid 3, uid 0, = was killed: failed to reclaim memory >=20 > [00:00:49] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [08:06:09] [01] [08:05:20] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >=20 > FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-complex.c= pp.o >=20 > and flang/lib/Evaluate/fold-integer.cpp was one of the compiles going = on. Finally, what a successful build of devel/llvm13 on UFS was like on the 8 GiByte RPi4B (overclocked, USB3 NVMe based SSD): [00:00:57] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 [12:25:40] [01] [12:24:43] Finished devel/llvm13 | llvm13-13.0.0_3: = Success where its Maximum Observed figures were: . . .; load averages: . . . MaxObs: 6.15, 5.71, 5.31 . . . threads: . . ., 11 MaxObsRunning . . . Mem: . . ., 6465Mi MaxObsActive, 1355Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) Swap: . . ., 10429Mi MaxObsUsed, 16799Mi MaxObs(Act+Lndry+SwapUsed), = 18072Mi MaxObs(Act+Wir+Lndry+SwapUsed) But 18072Mi MaxObs(Act+Wir+Lndry+SwapUsed) =3D=3D 17.6484375 GiByte, so more than 17.6484375 GiByte for RAM+SWAP, depending on how much room for inactive and margin one chooses. Probably 20+ GiBytes, so 12+ GiBytes of swap for 8 GiBytes of RAM. (Reminder: maximum of sum <=3D sum of maximums.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 17:20:11 2022 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 23C991999F9F for ; Sat, 29 Jan 2022 17:20:12 +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 4JmLgH65sqz3GT5 for ; Sat, 29 Jan 2022 17:20:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 ADB3B197A4 for ; Sat, 29 Jan 2022 17:20:11 +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 20THKBPG085143 for ; Sat, 29 Jan 2022 17:20:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 20THKBec085142 for freebsd-arm@FreeBSD.org; Sat, 29 Jan 2022 17:20:11 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 200415] System crashes when copying multiple files from ZFS to UFS Date: Sat, 29 Jan 2022 17:20:11 +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 Only Me X-Bugzilla-Who: rew@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643476811; 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=Fx5/zgAIuJes5qj+WgaJ/M36yFHJvBdlqy8mtE1XFkE=; b=xO+78+4AndRw2W/az2l4CpGIuyyXcNAZSDWE5HmOdqHVJS0pmv7OfU6jYy4pjOvO0jzhWP oluq3cwQdn1zZPPufJr8VfuKRY/jmC/FblMmezKRt2yOLn7IOlDjoAchGp9mc7OiXufNXg KSlAlEwpGU0EieX9nRDSf7KzcvsF/4e8HOghmhAUV4UFDvodW2HsDkRDoqgX3Dhxj/qAhj +hYqNuphI1hXDumTSz6DXIvo8wg+4ADp5X9eKsW+/JcympOd98qYSxaKQE/YVOz9BkPa4t AeoAzTJZnBjhXy9j3uGPwoOgYp0ik4pe+TQ1NIOQWMGjhjTJAThTsVS0GrCJYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643476811; a=rsa-sha256; cv=none; b=WkUG9oIRzWZldM4Ntjps/aHkg5hOA4XTpShUWFeYWnvRspeECLt3rFwzwn4dfMYx9LjHi8 XoddoEFiySgTq3A/KhKig9Ki7yBc1u0ZTT/V/LHHikDN15pIZcigLRpyJC7w2lf5STyz6t JFh9UFoloeX7sDOH2eI/rwwuyJQ9x+e8Xc/pQ/lwFH/+tvLh35oOpovBAO4ybr1AHZAYwl SKmptaivdvg1+6HQopXoLEV8cBeocZYMsrc0ssjdpSF5bLFAvEbYlkzg2dphcV+6NFKqYW rpTaRzmh0uvLvDNQnixQY9rxqCquDo8V/yYD4ZFdH5zIW0iopCQWQChTYM4uQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 500 Lines: 13 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200415 Robert Wing changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rew@FreeBSD.org Resolution|--- |Overcome By Events Status|In Progress |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jan 29 17:35:10 2022 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 061F91973DEC for ; Sat, 29 Jan 2022 17:35:26 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182]) (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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmM0s0VZ6z3Mp1 for ; Sat, 29 Jan 2022 17:35:24 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from smtpclient.apple (87-95-54-93.bb.dnainternet.fi [87.95.54.93]) (authenticated bits=0) by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 20THZGX1071581 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 29 Jan 2022 17:35:17 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 87-95-54-93.bb.dnainternet.fi [87.95.54.93] claimed to be smtpclient.apple From: Stefan Parvu 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 15.0 \(3693.40.0.1.81\)) Subject: RBPI3 for FreeBSD 12.3 Message-Id: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> Date: Sat, 29 Jan 2022 19:35:10 +0200 To: freebsd-arm X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JmM0s0VZ6z3Mp1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [-0.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.94)[0.944]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_NA(0.00)[kronometrix.org]; TO_DN_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MLMMJ_DEST(0.00)[freebsd-arm]; NEURAL_HAM_MEDIUM(-0.24)[-0.244]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 167 Lines: 8 Hi all, Anyone any ideas why we dont have FreeBSD 12.3 images for RBPI3? Sorry = if this has been asked before.=20 There are images for FreeBSD 12.2 Thanks, Stefan= From nobody Sat Jan 29 18:40:40 2022 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 B04DA197F2CB for ; Sat, 29 Jan 2022 18:40:49 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4JmNSJ4780z4YP7 for ; Sat, 29 Jan 2022 18:40:48 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 20TIeeSW061814; Sat, 29 Jan 2022 12:40:42 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id 81V9OyiK9WF08QAA4+wvSQ (envelope-from ); Sat, 29 Jan 2022 12:40:40 -0600 From: Mike Karels To: Stefan Parvu Cc: freebsd-arm Subject: Re: RBPI3 for FreeBSD 12.3 Date: Sat, 29 Jan 2022 12:40:40 -0600 X-Mailer: MailMate (1.14r5818) Message-ID: In-Reply-To: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> 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: 4JmNSJ4780z4YP7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[karels.net]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 362 Lines: 17 On 29 Jan 2022, at 11:35, Stefan Parvu wrote: > Hi all, > > Anyone any ideas why we dont have FreeBSD 12.3 images for RBPI3? Sorry = if this has been asked before. > There are images for FreeBSD 12.2 There was a u-boot change required to boot 12.3 on RPi3, but it didn=E2=80= =99t get checked in before the ports tree was tagged. Mike > > Thanks, > Stefan From nobody Sat Jan 29 19:23:58 2022 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 EB4D31972C24 for ; Sat, 29 Jan 2022 19:24:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmPQf1jc0z4pGf for ; Sat, 29 Jan 2022 19:24:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643484244; bh=OpAZWHo1EE47Rf6q23iMYFr7/5SX3Jxn2Vbsm+HyKU4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pI4B3TEIO5sl4US09HLQucvaJ3incTJUXs4r5nZ2eQ+7hS81C25xVlnEzH9kg08KSvCMoAgCg/PZ9MUuM91DtgPETUBWL0vSUZnsibDwc80gg74X1Z8+RIhMbn2TkjoIeuoWALOedIbUtsbmgt6vZ55H6QGek0wTl42ZDOleUU4KgrWd0+IitQAVSuXDaZgCpQuK1wX7qFL3v9uXsstnEz31hwYPP/KjPXOBfsPd0vFpSO8LYYJfYT9orDvBbIgc9cjfh94w/U9o2E8FNPyA7SXIk1yh0i77yVjxaLn0lNrpc7s/QDXmAP1CODNCwNP7RbQ7AVpGh5/h7G0Vv/Zk/Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643484244; bh=TcW+th+JrX6Kt1bNOM5cBqc9CQRDUsayB0gr8Mxuqfx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rTWNSDg7Oe0g9QTte4DJ4ROwnBiZiwK1HP2Z+CPPoLnHa64Aj+n0DqQGrjDSe91oosrfDXXVMSFHtJdDtKr6KY1ei3x5hfAcJPa2+tlcGE8awSFld/462b2lNd9/IiQzX0CG5TcFs8ZxyBLZBwRUGZlnrwg40s6pxf8YNsqiMUxi3dC2d+MsV908FSJ12X/0WOOCoPZhfC1opMHnWTnSZV73VORXUgHBIKKQU6pY5AKm4pzvZzKg0IWx1T5kDy8UtuGlCExcXO3yWehRuV49j0NyBWoR+vjahTmUMzAwjeYwwOWbyy3SmitK3iYaLOdgWCiVu9gPyZfJUEZyTUczUQ== X-YMail-OSG: NJq1Wl0VM1laETz9TBz9vBwLu8UvH2TpGQt3CDQL.QP.Lg3VfzS4vx1e5Y4NwoA BRipwJ9yEATngPjXD2q.kBgdc_RcxH_Ca7d4PeRCz.s1DLOXaBA.qAHCeT9FVnB3w.sYT3z2Tij9 anFY6qTfqibF0GIkHmIIiwaDqSzcXonFb.3tCAEbuBuxAS.euCwi_7VPHMeCzhqhKHYKaG86PBM9 yMgGGnLRuSM9b3Z2Yfpc0dpiW.vIGYk1rE5LvjyWYc4OgmnqmCB9ep.IhKJjFqsoo393aaBJtoKl LC9lMJqhi5teH8wFiEdscarAI6MqY4PdqurX.lIBeLhzZnJLJsh.RLnHiBfPBVVSeSQX75k1Up5o 7b9SYOFmmOhBmcKu9b071YIO7__2lq9j9AqZ5jZZG51GHKlIaC6417Y74Z0w8cnUrKEtoiPUQvVI TcOrpbTbRa0wCJjCk_dyKA0ZiZdb.jiMBSlMGAlLDrqN92EcYlDFng_w4QSLFPkCbzsmKShj13Sw n6nEBrbtmOu_l7T.iHc5_7_rZ9XxIUKte3VBNI2eUmJA0vT6TcMH1QJc60OuHiwG6HJ.0Qsl9b7. epYTEGztPMVfAfOSuH5tMCVfEsC.8jv01N2Wol6w7vaMQdOgQxmPD1NDQoprsdb8eG_9h9lMUn89 OKu10ljgJ4ssVWE_aNg26B.kB3eCu.8BROqK8axOoqGNI.C90MZbS9mWlJwQqn04RJuoHojcfIWs mh.3IaWMSMwlFls3g8da9AWNEs23uXvJf2Pi3H4fe_RWDXh1Gya5q7MFc0GjY0gMIBvwiKUsYGCn 3Sq4jlZGl5DzsrBJA9vXxcG2xr5_6nYA6I1XhaCjQumVnOY8Xy2BxIvCJLkKRFFtJ6GzOgn4Obai UhFekG.eO59iUGF5KHo7BjLIEWr3lh0OdgLYM1ARRjzkGE10y8gylNlMD1Pd4nQAqGDxZm_ax4hP Otj0a5cZsDW.nOtaqWuEo6n_hoids6Wz96ARXL_c08TZ8FJl0F8s2wU9n5iyW2HEfsCmHMIrhrth _7zUiarcnf1Vs9RcVdPoyzDOhby0tnRova8UZmSDm9mYzTeSI3Gn6WYe9DvuYkZrFkHjrMgNFeeG dUDu9qZEHLYKrw0xwI_d4uM8b07dbGL3ciDgQgB2CfFcpJhMS5ADxMRn0I9rylC..B8yxQhesOde Po3N2SIlrJVbVOOmZmqMCW7iBsxy0KXCyMx7pVozqsVVzhG0_9PtcZoDsi5oycAkkIcTouGWlpiw bAK7QNKG3eYU2nkcWgYvPLHkTyRDUpHj4eI0tbjTQGNxX44kxMTsjlB1ruKDX3mYr0Rn1oEzEtVX dwhrmgQ5cR8xje3vL769VdcJzVYS73tuZ83wsfpsh38kx4E4wm7rUPuiVQ1DntNjtIja1SxNW8Sz VWJejGnL4D6I6gn9sDJO_sRPaEn7TlwzGi77_9HOCbzQrkp4ku.1uk8yCUTps4RKANEMBnFriZ1a t46ekVTCY0vSIId1YBbsYU393C6q.iON.iPDxsKLbb7574uusCdgYwShTbQIPOaB2Nv2jevW6ze0 tjUcW3m0uTFXN6b5VEVc.WPDt211VhCv2978IJxRmQIbv.2wA2Pbsk2WS1FiJFvJ5kGw7SD38Txw HxKCZYzFhReR2KcjKVhpwEetg5cIXzAhQzXz2Rglb0ZYlfXM4wDfmGz5bslNZXWWdMHHrV.pkKOD hTfXnp90DdftRtfa3nSXDdltR5U6Gx2tcHoFvEDmejws.bBASbEbnRtEFnCgSJ3ewDTXqdc_vEc5 U0acXWPyAs3JeBNcMVGG2rKrCF8vmV7Z0SjLgTn9V.FBYa5Jefj44rIlzhn_TX6B5T2Ymvb2zxXZ YjqNnT14lFWL1A.9vklLO1wgy8A_bwpMEcGCfq0afSVrRgxeiw8SyjvIhMHNlJ9BQ8g5KZfBxwlt qRth3N3D7JwC6X5MpTNIzO.qMCuwyyo1C12VpAulJW2SKm62kTg.En_q.KfMFdaLHgoUgsbflbD3 KS.WjtnF7MjJVlYi5GBi2Qog5atyLAdzc7gf6HUvt.tBqwwiKXv1OakF8yvepclwAX2aK1CSQvdk MZRlKOfyTBh07j2VImspr6UQfeRtlVVyZawSu2YgxkVzx782M7tGQ0PN.bpiVFkdGVyLOAlm5j11 ED1M_wG5G4QM5n_8Q1Qy9E58kHBhMjWz3v6sb_Mutf0Pjk4UaUHyg2IxKZParNk.Tm.j_EMbtJDB n8YMPZqY.kXqmqFUd63GwJYRkFweUtCINxABp39DkC6oo3JZOYXkPC.c82ayggoAvn6bGTwr9Ks1 m9g8A0mqg0hgNpAsvRA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 19:24:04 +0000 Received: by kubenode525.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5b42bfc84a8a471531ef84cce0e0a110; Sat, 29 Jan 2022 19:23:59 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running -current [UFS success context for 4 cores, notes added] From: Mark Millard In-Reply-To: Date: Sat, 29 Jan 2022 11:23:58 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220127164512.GA51200@www.zefox.net> <2C7E741F-4703-4E41-93FE-72E1F16B60E2@yahoo.com> <20220127214801.GA51710@www.zefox.net> <5E861D46-128A-4E09-A3CF-736195163B17@yahoo.com> <20220127233048.GA51951@www.zefox.net> <6528ED25-A3C6-4277-B951-1F58ADA2D803@yahoo.com> <10B4E2F0-6219-4674-875F-A7B01CA6671C@yahoo.com> <54CD0806-3902-4B9C-AA30-5ED003DE4D41@yahoo.com> <9771EB33-037E-403E-8A77-7E8E98DCF375@yahoo.com> <6D67BFDF-D786-4BB7-BF2D-CE4D5532D452@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmPQf1jc0z4pGf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pI4B3TEI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 14288 Lines: 402 On 2022-Jan-29, at 03:59, Mark Millard wrote: > On 2022-Jan-28, at 19:20, Mark Millard wrote: >=20 >> On 2022-Jan-28, at 15:05, Mark Millard wrote: >>=20 >>> On 2022-Jan-28, at 00:31, Mark Millard wrote: >>>=20 >>>>> . . . >>>>=20 >>>> UFS context: >>>>=20 >>>> . . .; load averages: . . . MaxObs: 5.47, 4.99, 4.82 >>>> . . . threads: . . ., 14 MaxObsRunning >>>> . . . >>>> Mem: . . ., 6457Mi MaxObsActive, 1263Mi MaxObsWired, 7830Mi = MaxObs(Act+Wir+Lndry) >>>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 8192Mi = MaxObsUsed, 14758Mi MaxObs(Act+Lndry+SwapUsed), 16017Mi = MaxObs(Act+Wir+Lndry+SwapUsed) >>>>=20 >>>>=20 >>>> Console: >>>>=20 >>>> swap_pager: out of swap space >>>> swp_pager_getswapspace(4): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(2): failed >>>> swp_pager_getswapspace(2): failed >>>> swp_pager_getswapspace(4): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(9): failed >>>> swp_pager_getswapspace(4): failed >>>> swp_pager_getswapspace(7): failed >>>> swp_pager_getswapspace(29): failed >>>> swp_pager_getswapspace(9): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(2): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(4): failed >>>> swp_pager_getswapspace(1): failed >>>> swp_pager_getswapspace(10): failed >>>>=20 >>>> . . . Then some time with no messages . . . >>>>=20 >>>> vm_pageout_mightbe_oom: kill context: v_free_count: 7740, = v_inactive_count: 1 >>>> Jan 27 23:01:07 CA72_UFS kernel: pid 57238 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >>>> swp_pager_getswapspace(2): failed >>>>=20 >>>>=20 >>>> Note: The "vm_pageout_mightbe_oom: kill context:" >>>> notice is one of the few parts of an old reporting >>>> patch Mark J. had supplied (long ago) that still >>>> fits in the modern code (or that I was able to keep >>>> updated enough to fit, anyway). It is another of the >>>> personal updates that I keep in my source trees, >>>> such as in /usr/main-src/ . >>>>=20 >>>> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >>>> index 36d5f3275800..f345e2d4a2d4 100644 >>>> --- a/sys/vm/vm_pageout.c >>>> +++ b/sys/vm/vm_pageout.c >>>> @@ -1828,6 +1828,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int page_shortage, >>>> * start OOM. Initiate the selection and signaling of the >>>> * victim. >>>> */ >>>> + printf("vm_pageout_mightbe_oom: kill context: v_free_count: = %u, v_inactive_count: %u\n", >>>> + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); >>>> vm_pageout_oom(VM_OOM_MEM); >>>>=20 >>>> /* >>>>=20 >>>>=20 >>>> Again, I'd used vm.pfault_oom_attempts inappropriately >>>> for running out of swap (although with UFS it did do >>>> a kill fairly soon): >>>>=20 >>>> # Delay when persistent low free RAM leads to >>>> # Out Of Memory killing of processes: >>>> vm.pageout_oom_seq=3D120 >>>> # >>>> # For plunty of swap/paging space (will not >>>> # run out), avoid pageout delays leading to >>>> # Out Of Memory killing of processes: >>>> vm.pfault_oom_attempts=3D-1 >>>> # >>>> # For possibly insufficient swap/paging space >>>> # (might run out), increase the pageout delay >>>> # that leads to Out Of Memory killing of >>>> # processes (showing defaults at the time): >>>> #vm.pfault_oom_attempts=3D 3 >>>> #vm.pfault_oom_wait=3D 10 >>>> # (The multiplication is the total but there >>>> # are other potential tradoffs in the factors >>>> # multiplied, even for nearly the same total.) >>>>=20 >>>> I'll change: >>>>=20 >>>> vm.pfault_oom_attempts >>>> vm.pfault_oom_wait >>>>=20 >>>> and reboot --and start the bulk somewhat before >>>> going to bed. >>>>=20 >>>>=20 >>>> For reference: >>>>=20 >>>> [00:02:13] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>>> [07:37:05] [01] [07:34:52] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>>>=20 >>>>=20 >>>> [ 65% 4728/7265] . . . flang/lib/Evaluate/fold-designator.cpp >>>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-integer.cpp >>>> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o=20 >>>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-logical.cpp >>>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-complex.cpp >>>> [ 65% 4729/7265] . . . flang/lib/Evaluate/fold-real.cpp >>>>=20 >>>> So the flang/lib/Evaluate/fold-integer.cpp one was the one killed. >>>>=20 >>>> Notably, the specific sources being compiled are different >>>> than in the ZFS context report. But this might be because >>>> of my killing ninja explicitly in the ZFS context, before >>>> killing the running compilers. >>>>=20 >>>> Again, using the options to avoid building the Fortran >>>> compiler probably avoids such memory use --if you do not >>>> need the Fortran compiler. >>>=20 >>>=20 >>> UFS based on instead using (not vm.pfault_oom_attempts=3D-1): >>>=20 >>> vm.pfault_oom_attempts=3D 3 >>> vm.pfault_oom_wait=3D 10 >>>=20 >>> It reached swap-space-full: >>>=20 >>> . . .; load averages: . . . MaxObs: 5.42, 4.98, 4.80 >>> . . . threads: . . ., 11 MaxObsRunning >>> . . . >>> Mem: . . ., 6482Mi MaxObsActive, 1275Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) >>> Swap: 8192Mi Total, 8192Mi Used, K Free, 100% Inuse, 4096B In, = 81920B Out, 8192Mi MaxObsUsed, 14733Mi MaxObs(Act+Lndry+SwapUsed), = 16007Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>>=20 >>>=20 >>> swap_pager: out of swap space >>> swp_pager_getswapspace(5): failed >>> swp_pager_getswapspace(25): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(31): failed >>> swp_pager_getswapspace(6): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(25): failed >>> swp_pager_getswapspace(10): failed >>> swp_pager_getswapspace(17): failed >>> swp_pager_getswapspace(27): failed >>> swp_pager_getswapspace(5): failed >>> swp_pager_getswapspace(11): failed >>> swp_pager_getswapspace(9): failed >>> swp_pager_getswapspace(29): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(9): failed >>> swp_pager_getswapspace(20): failed >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(21): failed >>> swp_pager_getswapspace(11): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(21): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(3): failed >>> swp_pager_getswapspace(3): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(20): failed >>> swp_pager_getswapspace(2): failed >>> swp_pager_getswapspace(1): failed >>> swp_pager_getswapspace(16): failed >>> swp_pager_getswapspace(6): failed >>> swap_pager: out of swap space >>> swp_pager_getswapspace(4): failed >>> swp_pager_getswapspace(9): failed >>> swp_pager_getswapspace(17): failed >>> swp_pager_getswapspace(30): failed >>> swp_pager_getswapspace(1): failed >>>=20 >>> . . . Then some time with no messages . . . >>>=20 >>> vm_pageout_mightbe_oom: kill context: v_free_count: 7875, = v_inactive_count: 1 >>> Jan 28 14:36:44 CA72_UFS kernel: pid 55178 (c++), jid 3, uid 0, was = killed: failed to reclaim memory >>> swp_pager_getswapspace(11): failed >>>=20 >>>=20 >>> So, not all that much different from how the >>> vm.pfault_oom_attempts=3D-1 example looked. >>>=20 >>>=20 >>> [00:01:00] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >>> [07:41:39] [01] [07:40:39] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>>=20 >>> Again it killed: >>>=20 >>> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.c= pp.o >>>=20 >>> So, basically the same stopping area as for the >>> vm.pfault_oom_attempts=3D-1 example. >>>=20 >>>=20 >>> I'll set things up for swap totaling to 30 GiBytes, reboot, >>> and start it again. This will hopefully let me see and >>> report MaxObs??? figures for a successful build when there >>> is RAM+SWAP: 38 GiBytes. So: more than 9 GiBytes per compiler >>> instance (mean). >>=20 >> The analogous ZFS test with: >>=20 >> vm.pfault_oom_attempts=3D 3 >> vm.pfault_oom_wait=3D 10 >>=20 >> got: >>=20 >> . . .; load averages: . . . MaxObs: 5.90, 5.07, 4.80 >> . . . threads: . . ., 11 MaxObsRunning >> . . . >> Mem: . . ., 6006Mi MaxObsActive >> . . . >> Swap: 8192Mi Total, 8192Mi Used, 32768B Free, 99% Inuse, 28984Ki In, = 4792Ki Out, 8192Mi MaxObsUsed, 14282Mi MaxObs(Act+Lndry+SwapUsed), = 16009Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >> (I got that slightly early, before the 100% showed up.) >>=20 >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(10): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(16): failed >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(8): failed >> swp_pager_getswapspace(12): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(32): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(21): failed >> swp_pager_getswapspace(10): failed >> swp_pager_getswapspace(18): failed >> swp_pager_getswapspace(6): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(14): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(25): failed >> swp_pager_getswapspace(12): failed >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(7): failed >> swp_pager_getswapspace(10): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(24): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(11): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(5): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(32): failed >> swp_pager_getswapspace(15): failed >> swp_pager_getswapspace(19): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(25): failed >> swp_pager_getswapspace(11): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(15): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(8): failed >> swp_pager_getswapspace(31): failed >> swp_pager_getswapspace(26): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(20): failed >> swp_pager_getswapspace(4): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(15): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(7): failed >> swp_pager_getswapspace(8): failed >> swp_pager_getswapspace(17): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(10): failed >> swp_pager_getswapspace(6): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(11): failed >> swp_pager_getswapspace(21): failed >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(9): failed >> swp_pager_getswapspace(32): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(32): failed >> swp_pager_getswapspace(25): failed >> swp_pager_getswapspace(21): failed >> swp_pager_getswapspace(22): failed >> swp_pager_getswapspace(14): failed >> swp_pager_getswapspace(10): failed >> swap_pager: out of swap space >> swp_pager_getswapspace(1): failed >> swp_pager_getswapspace(28): failed >> swp_pager_getswapspace(2): failed >> swp_pager_getswapspace(13): failed >> swp_pager_getswapspace(3): failed >> swp_pager_getswapspace(31): failed >> swp_pager_getswapspace(20): failed >> swp_pager_getswapspace(2): failed >> vm_pageout_mightbe_oom: kill context: v_free_count: 8186, = v_inactive_count: 1 >> Jan 28 18:42:42 CA72_4c8G_ZFS kernel: pid 98734 (c++), jid 3, uid 0, = was killed: failed to reclaim memory >>=20 >> [00:00:49] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 >> [08:06:09] [01] [08:05:20] Finished devel/llvm13 | llvm13-13.0.0_3: = Failed: build >>=20 >> FAILED: = tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-complex.c= pp.o >>=20 >> and flang/lib/Evaluate/fold-integer.cpp was one of the compiles going = on. The below is about the success case for the 8 GiByte RPi4B: > Finally, what a successful build of devel/llvm13 on > UFS was like on the 8 GiByte RPi4B (overclocked, > USB3 NVMe based SSD): >=20 > [00:00:57] [01] [00:00:00] Building devel/llvm13 | llvm13-13.0.0_3 > [12:25:40] [01] [12:24:43] Finished devel/llvm13 | llvm13-13.0.0_3: = Success >=20 > where its Maximum Observed figures were: >=20 > . . .; load averages: . . . MaxObs: 6.15, 5.71, 5.31 > . . . threads: . . ., 11 MaxObsRunning > . . . > Mem: . . ., 6465Mi MaxObsActive, 1355Mi MaxObsWired, 7832Mi = MaxObs(Act+Wir+Lndry) > Swap: . . ., 10429Mi MaxObsUsed, 16799Mi MaxObs(Act+Lndry+SwapUsed), = 18072Mi MaxObs(Act+Wir+Lndry+SwapUsed) >=20 > But 18072Mi MaxObs(Act+Wir+Lndry+SwapUsed) =3D=3D 17.6484375 GiByte, > so more than 17.6484375 GiByte for RAM+SWAP, depending on > how much room for inactive and margin one chooses. Probably > 20+ GiBytes, so 12+ GiBytes of swap for 8 GiBytes of RAM. >=20 > (Reminder: maximum of sum <=3D sum of maximums.) For folks that might read the above without a lot of prior context . . . I forgot to mention above that the RPi4B has 4 cores and the poudriere ALLOW_PARALLEL_JOB=3D meant that there were 4 jobs (processes) much of the time. (Nightly cron related activity and made the MaxObs load averages bigger than the 4.? or 5.? that would otherwise have showed up.) Having notably more (or fewer) processes active for the build need not use RAM+SWAP proportionally overall. The 20+ GiBytes figure for 4 active hardware threads in use is somewhat context specific. So having 5+ GiBytes of RAM+SWAP per hardware thread that is to be in use may be significant overkill when there are notably more hardware threads involved. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 29 20:43:13 2022 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 5AE10197D7A6 for ; Sat, 29 Jan 2022 20:43:19 +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 4JmR9f2SBSz3nRp for ; Sat, 29 Jan 2022 20:43:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 20TKhEfw063054 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 29 Jan 2022 12:43:14 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 20TKhDKX063053; Sat, 29 Jan 2022 12:43:13 -0800 (PST) (envelope-from fbsd) Date: Sat, 29 Jan 2022 12:43:13 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Should a UFS machine have an ARC entry in top? Message-ID: <20220129204313.GA63030@www.zefox.net> References: <20220128182701.GA57479@www.zefox.net> 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: <20220128182701.GA57479@www.zefox.net> X-Rspamd-Queue-Id: 4JmR9f2SBSz3nRp X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.01 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.88)[-0.884]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 418 Lines: 15 I just noticed a new line in top's output on a Pi3 running 13/stable: ARC: 3072B Total, 2048B MRU, 1024B Header 2048B Compressed, 20K Uncompressed, 10.00:1 Ratio This is on a Pi3 with a UFS filesystem, near as I can tell ARC is something to do with ZFS; have I got something misconfigured? The system was last updated in mid January. Thanks for reading, apologies if it's a dumb question! bob prohaska > From nobody Sat Jan 29 23:30:35 2022 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 652011986C08 for ; Sat, 29 Jan 2022 23:30:55 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmVtx4C80z4XZ1 for ; Sat, 29 Jan 2022 23:30:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643499041; bh=tLem2j6G8Dbm3ZCt8M5/J9hkBJXBcclJSYanw9MfFSw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BGOFDIwb5djSmJKt9JSXMrQ8XiEjQa6NYbJ6boI/Z3bpz5s0pndEkQwGq2lq+hTFfuqPYQPx/Wov2DhX9lpX0LADHxXpUpkmVl90GrMmGkeGipbCSvqE0lbnpO1bpLeg/LwwY0aLmDr9YRNrL5DyByWzX77H0MWR9PK7eLqgluz4jnZylfE2XotE20GVRzaMmwf4XBOjFjBlXSxgsbVCnahFcxIbvYgswj2UVoXUwBVERD7Rq5utmLnAxH1YglEWPsdZ5EECO/emb/k9Lc+hBY09hsAth2VTQj6eqSp7m8ZxU+G5vMvWRRzsapCBcHk9dtLNDZylAnTtG0e2h8pokw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643499041; bh=1kVrT0Tj9xqUIHO5Zs3vP4AmG6nQ/dIVmQlnlUOWHgP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BKCXaSMdnIKUwIkgK1FYfW3DR92Z6F1Eurt6KtXaArhGXtY3qyMxGQNVcxg3hN6M6KXq9ty+PFpLrw5UPd1U7KyldvxjwL96pjlTz3N9HMbWRQ0i9r54rbjQATFzfgT2AOej59DeHLp6eVbE89PMTAoy8ager9W+ZWvLpOm973MfxM5DYagaZ2QgBZiUrrE/ewpD8lAG1ug+xb5aUMN8dlZE3KWdW59FyW8YnlURzFLDO4WOoIE9vNdqB2YYfQb3Z8+9jBNSRexxv5LvX9lYpUdrUlsTqnntZG48oFOdWXdiqgxmQlwSeaIxv/DyxmI00tQlb5mhbCwZTSrFkeDyZg== X-YMail-OSG: Ni6EWVwVM1lWwaQ1mZkgdE.GtBDGRsX4gxQZKBLwJiEhd899uWThO21GrWzq8bP k9hNuDpPViN9DrG_QlD6uJQxE8eZVLtmrqh6PULTjd752H82y5hs7hkWor7L4H3GgVi93AV2I3rG .KDef3xfYdYUw0cF5Emlsx4AfXX9mJnqjEAc0HUKKGA05XogOLbf7L.bqwZYwcnryCl3cFCqKruH szb_WUJIr3XjzMG24h2W5o85uNLuhN2vbR4JvIwXh2FS9bAEBN74mnay0ep9nZN3ZP5WsP9v5j5O .E8Ufdoy3zAMSPdfD7stGqy56YWj_c6Hu_JQph9tOO4gG0z8fSmw.xjAtXdKQnXAZI6DxOSjetPQ qPyrRJ4abdv9e7ZFSFSFmF.Uq69BKAyd2q2Uwsx.In265f1lm_VPPLfiO8jZdbf6dWsuNMT6VDGM r0KLeDiBHNnQJP0PTSE5HAEF9AeOQIGsufZZlBRGT9GW9BAATBuoWgewOkmK3LNgWATTaKswd_LS YKJmyIC2rU777vAlDK8xs3Xzi55qmsRGxQZINT2c7uOhRj.53Qq5p0eqmrDGYO3jTMTaagPqo5Zm BExaY_QpCFVejn2fkdleXjZra58l5JdG75o1.FvPbjXfE6tVGeg9TN3l7l06M.TBiaaaHtb4fXR8 XdNkXpWhzCVWq.1hglrrLBgr5n40QAVnFaDbg_xOJ3wnL3rzbxwbN_dc.foqxiYSvx1ALxhAs0UT HJ8Y5xS7Kb3Va1s6.jOgI8ZPpFsJqYio3fgGGd.GDysGHIQXbQFNAYALXeYULN37ycPqbwX7MRA2 ms1KigBijB2qvzO8erte0z_XHnn2F_dwzbIj9OYTXGpcer3jEP7FaCiw2uJ0Qpi3n0ThG7fSbAbd 4pBV3IMf0qsAgkEQHobjUFMpY_VXgPDC.vVq.bL4jgLDok7WbDWkYUBCNfOQP3sxJKhO_aVggzoR 78Zymn7ZPSE9a6n849EhYss5lncRR__vFWaTuv5whuWJDNratBSSbP3YPZhRQtTr7o05Iy8d10X. AmLcKam6a27.QTklPwl.9zEKZSA8M.ZmV3fkbDL7WweL6STdDp3740_SJkGr5M.VpbovodssSDmj S81zhJLJ.wQS2xL9zZh18m0VKGRSpju2SfeYbMZ6KKJusGoFLZN8Hnz108AggfbTf2RACsuQ7V2p ctXQrXHFuGgnd5KQbDgRO_cVTvh.Jr_l93.NSpFlDYk3122WKAAKeiTyi4ui2u8nGfF3tIO3YD3n Z_C6sLkWA6aVwVTx_lmJ9jNpvONB8LLe5Ro6cWjtVxJybxaZnYemAYCw7pDVimOAKskSFEDLwQmB WB9h7HhGW.Xqbz4gFJ_AmuGdSmSdQ2QDKkBVxAsHA3l5sEqtoHfl4GXT9evF48MTka8tJ4LtNoCk DElJlmUfrqmKLWTk_KJxlDmPVhOSqDW8dNgn6O.6TlNVhmjJngLxdNIL80ZG.XGxZ90NH5n36BBA 4OuwxDkXhG_TodwCZt3an3Vyt2GQOQqYwM7xd9Y7B.M84qHVhyOClsdy4gFimMIeW5PsX22pnH0h G3Dz2HE4RARPQ9A32wcJvrkKD2V_RIddH.W7aiVAwjGZx5vptJf41HAGOwtRwQaQvjtxF6ctw9j9 trL9uq01R_xhVxz_hC7A4auttDqme0aLxwLIt6ITMKM2U7zVE9yjG2.b3uIMIDey.KdQOVFk8V0M 35MffU4SsXQKVG8E0ZZ2lS2flycXwdDrCLZBDjJxLfvjNpSxV2KGNpcFwt4JwJztTm9G6fgGE_WA AWAJi6.867_s.oulrHkLhCv2W5jm5z9bV5nCWbiAODjTm8uYkPTzsFIzgCb214jE8JzawcCKpRI4 x5kG7BA.zQsF_st0lTN5Me7bltTUailJmGQgIVDCOQUOMZOGoSeZVRxx4P1LnNP.ajoLFDsMTWrR zzkS.re3dq4PV07wdcH8gu2Om0trPzkLrn2lkndAuQuyf7n_robiuIHr61Sqd0asW7.kwD6DoLd7 DRNYmjP4RkZta3MQmyDT.8vAjrisLVUak0RQCnnM63p_PR72DX0Wy0KSOvWard5jjkgFmh9pcFzs 8VIPaU9n7kDTabJIB1LmRQwJHkZt.jr93oGvDt0eMu4YIPL3q8nge_MosYBk8fVMA5_1Gzwr8wk9 HQqN8Ag0K8du_v7h9B9LJyB742Go4nNpec6KNpCbNaoqjTB1IaWdPqwz.nlqz5Di4AJdZp0Zqdgs 9XCDh8RQo_kyfGXFm5mqKo0e2KgWpU4bYFCPQK6.gMpR5nroV9nvnZIP.2P6qjNjWnliLMpG07gp BEDYxNKsfXBR3bFxC X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Jan 2022 23:30:41 +0000 Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 01560994b95d37a55ad48dede05eb6fb; Sat, 29 Jan 2022 23:30:37 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Should a UFS machine have an ARC entry in top? From: Mark Millard In-Reply-To: <20220129204313.GA63030@www.zefox.net> Date: Sat, 29 Jan 2022 15:30:35 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D29091D-AC99-4D8D-AC3C-646A05529E26@yahoo.com> References: <20220128182701.GA57479@www.zefox.net> <20220129204313.GA63030@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmVtx4C80z4XZ1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BGOFDIwb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[98.137.69.83:query timed out]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4087 Lines: 135 On 2022-Jan-29, at 12:43, bob prohaska wrote: > I just noticed a new line in top's output on a Pi3 running 13/stable: >=20 > ARC: 3072B Total, 2048B MRU, 1024B Header > 2048B Compressed, 20K Uncompressed, 10.00:1 Ratio >=20 > This is on a Pi3 with a UFS filesystem, near as I can > tell ARC is something to do with ZFS; have I got something > misconfigured? >=20 > The system was last updated in mid January.=20 >=20 A system can have multiple types of file systems, even on the same media (e.g., separate partitions). It can boot from either and have the other in use. Note: zpools (and ZFS) do not require partitioned drives. But my example context only uses partitioned drives to hold an zpool. ARC is for ZFS and its being in use suggests a ZFS file system is (or was?) at least slightly accessed at some point. What does: # gpart show -p show? For example, with 2 USB3 NVMe SSD drives plugged in, one being the boot drive, I get: # gpart show -p =3D> 40 1953525088 da0 GPT (932G) 40 532480 da0p1 efi (260M) 532520 2008 - free - (1.0M) 534528 29360128 da0p2 freebsd-swap (14G) 29894656 4194304 - free - (2.0G) 34088960 33554432 da0p6 freebsd-swap (16G) 67643392 58720256 da0p3 freebsd-swap (28G) 126363648 8388608 - free - (4.0G) 134752256 394264576 da0p4 freebsd-swap (188G) 529016832 8388608 - free - (4.0G) 537405440 1405091840 da0p5 freebsd-ufs (670G) 1942497280 11027848 - free - (5.3G) =3D> 40 1953525088 da1 GPT (932G) 40 532480 da1p1 efi (260M) 532520 2008 - free - (1.0M) 534528 515899392 da1p2 freebsd-swap (246G) 516433920 20971520 - free - (10G) 537405440 1342177280 da1p3 freebsd-zfs (640G) 1879582720 73942408 - free - (35G) Notice the freebsd-ufs at da0p5 (boot context) and the freebsd-zfs at da1p3 (just plugged in). Merely having plugged in da1 does not lead to ARC showing up in a new, temporary instance of top. But merely doing a: # zpool import to show what pools can be imported was enough for ARC to show up in yet another new instance top. For reference: # zpool import pool: zextu id: 7086474838335519206 state: ONLINE status: Some supported features are not enabled on the pool. (Note that they may be intentionally disabled if the 'compatibility' property is set.) action: The pool can be imported using its name or numeric identifier, = though some features will not be available without an explicit 'zpool = upgrade'. config: zextu ONLINE gpt/CA72zfs64GU ONLINE Having done the zpool import command, zfs.ko shows up in the kldstat output: # kldstat Id Refs Address Size Name 1 18 0xffff000000000000 12c5ee8 kernel 2 1 0xffff0000012c7000 423b70 zfs.ko 3 1 0xffff0000016eb000 256e0 cryptodev.ko 4 1 0xffff0000ffc00000 27000 nullfs.ko 5 1 0xffff0000ffc27000 24000 fdescfs.ko Merely unplugging da1 will not make zfs.ko go away. A new, temporary instance of top still shows the ARC at this point. Since the pool had not been imported, I unplugged da1 and then did the following: # kldunload zfs.ko # kldstat Id Refs Address Size Name 1 9 0xffff000000000000 12c5ee8 kernel 3 1 0xffff0000016eb000 256e0 cryptodev.ko 4 1 0xffff0000ffc00000 27000 nullfs.ko 5 1 0xffff0000ffc27000 24000 fdescfs.ko Starting another new, temporary instance of top no longer shows the ARC at this point. Booting with a freebsd-zfs partition present, for example, would likely lead to zfs.ko loading and the ARC showing up in a new, temporary instance of top. So a reboot's result is dependent on what the boot finds, so far as I know. Another relevant command if one or more pools have been imported is: # zpool list For reference for when no zpool has been imported: # zpool list no pools available =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 30 00:15:18 2022 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 28C661980AB1 for ; Sun, 30 Jan 2022 00:15:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmWtW6jNCz4nbK for ; Sun, 30 Jan 2022 00:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643501724; bh=3x43zmM99cYAnspFgmg99Fvi2Iy6DtlR4TP/YtSibAM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OfE4AoEKfZr4nJSkvQJuo+sMNWVIDcge1AtHb2wI0WqbLGyul9K1jp8H44GDB/7TvSCN8rDxn1Y3OcPZ8rv+w2MpUDDOMui2cP2JJebSjj8PIj/6vYkU50ZJO/zLHcpDNZfqixPER5ig3vF2CKHxhCMGEKqKWGUFNKedG/lDc/Y21aLCAztgL9QjyzBgqHoYoN90hnQFyzp+WD5oORiaO1e9QunpE/oyCzCSmIYWVY8TmscTIUsqWNIhoAKArHJBdtQUDuHSQr/t09ZDvXoOHQoVUHkN+H9NfBJy1ipUNo/Qa2c51lwjlTvrjnIhqkulsIrwbI2kXWwhJqUcmiDP1w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643501724; bh=iE/jaEMq0eMvgzBndXRmJwMQ/XBhmITzBaT/c39kdkL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=k3Ej8As9ueZjP2r1b+nt18aJsrUwM8PrNmhAH9ik56mmrXEcOw4OEyGOfQnbaGS4uyKnbYr7GC8pyHvFvWrxadDgMGS/KLnN8nTiIrdjQFQIitmIlYw83O5xIgdaE+gcyhTTihRAjTRXdKSeN5WPnacXI9C+FfbkJhs50dpSXoSaSjmBkFouKuGXFtv8AcmZitILGHBJj1f6z9tBzmRXjLND4JYtctV4+M1xBtkm3+wh4vpqGvA5bbWzjhmi/lrxwIfajKx4wJ77N2uylbYyMd0MYlrue3aXqMHBZt659iZWeWmK6Muz3Wlrtk4OJwpu9TZiKLwJ1U4NCfmuBIIdUQ== X-YMail-OSG: Q7css18VM1kELolCf3rV0zMrzFZ4o_9qB7DFy09w8Qv56qzIpnPrwAPoy3vN8P1 7R9f6OqGOnTLSED.J8Bq_RV_fw52CWd83U5YtvPJx1E0HIBQ8.efhOttWYRajk6A3QXjXNvFGGSp UcORWzC7ZoYRuEsso7UFrM7I.mrtkz.UHqC6ZFQ_BjnRB5Mhs2p1VYUPBF9.jM.fyNAT9LboBrRC bnBEoRxG1iAx5Zd0cijHvEGWo_KlzOJ12gDZkrHK1aa4azDSz7KgVWRDsoO1HMSkYaPST8vZRebY I7BQtCZjctcTMJZPNtvcF4DOC4AZadK0k7zp7m_gHcId6zSauhR6_OXAZRW_fJDExJ0JmXZc2JPp XUCBA6InfkW5EgSVT1Ya_28qwRrqYjPOShwOc0FUwZ0LbI_VDEMvsuTOqqVBPGgUFumLs_U0BJAH BA.WeSGvC2SqgTa58SHD98QLijeKJaNz3DJZzyjDp0mRhXw3NiVwYjfm_WaKVOHbQMWdfmQkrkFf X4h35QhG0DkwLeR7Z1Pfns0Uuzo7WB4WvZpgdN1kSaB2lycWRUyUYORfa7NHXPtQ.vQeA_6204MZ oEGgsZoSqSX6MhAn3visEWA8F0zx5pP7C6u8RrVD6L9.tlN4ipVHg9Y08zWp7eB3FyF1YYREuaN7 LbMA07B_s9CNa7Q2Le0Rg48tp7VqD2BhxFjz.6UXRu1hN4HJPvnAj4PQNiVm1NECZcrDkJ8..oWR GxiSndD2chNAPoiAxmtLvXhlkzmlKAhm1_U1YFIuSNn6Au8vbv4bsHSm6acnbK0D2XH29zUXkBiW 7EkJlwO.wGO1nXcbWo_bb0fhidjn1E8rD29RQirC8WkKH2RKHFzf9GtIgC14GgcI5bB1czi2OzxW hZvy06Rmx3ozHgJHw.dlpByOsRK72_fiqHoQ.kRT7LhCmFmeY1hHcxgLovA10mmKcunGCz2Io4F0 bfiM01UvmemlgzflegKNELJkQVkWSL8aSceAw2Qonz19S5KtCOqF6X2dUOQ5IFxpaloUZgmV871F 7PUu4DqZR_H.2sug2MSbS6U_RHP30d3YC5GoDeFmM_tPq.QWBq_napZ6OYX2Ku_Uh.gW294v255T DBMn6pXzrkhopiIRxDncUI_csZYUY58iP7Rl6Mbo9ca7OaupqhaGZUXTyhORjJjYmwCXLoAA6xd8 v1cXzee.pyrWiADF1TU275roJGJhP4VGcPi..1ep_zcDcs0fM8b7p3VsInFBReQrSQ_RXTnLP4N1 oechs51I7PvBqyROD_BgSQIiZS6eWtxUo4hY.Ea0bwpVvr5VOVmiPNgqVBPZonWC1qdiFrh10jwl KgDp55bZBaOV5qM2hukN2ZSLbP5yIHVeMH0UAdUaXoo925XqZ9TbzHFfhoGz80v7ohPoeJDkeLz4 i2RdZhdpJiGNKz8q12Z9wqkmkuOS4hRPPlnlkKTd8..NiljWF0dLFx2tyda4W8PyqkwWjq2IW1NF HzT9gchVCqW.UUvApEbCdTH9KbJOIlyjBu9xpGyD8zxbpFRMRZQ4upYMx2DGwKlK6zP7pmt_g2Ei A7tQo8A02qL.WH4WF.oqW9QLBBeW.g_B7a3YBnGGkB_3Xq0SbSL0c8Xej.dsD9iEZtgAH.hst4Hy 1t3Bm9c0.3HNQLFCUjaHUN8lh5VZlaGJLp3rThYq9WFKSgyiUUiw3TVhopDMuHmgm.o8aRB91zG0 l7LqyyNuwBSjLjAG8vliKUd6R3qjiHIOTc9MZTW8hQaZ4TpQCRt10LnSKd0xxoJDCiEhV36mDjIc 38NibugKqgo4ar5tm5PNSocA6tYXGpYW7tTl9MTOldMLD_SXBPsetEGrkuYdGaXp4uOAEAMuMJjR FN4S7hHTSI41wVVI8rDohguOp0yoM30lQKYjd9TVDxdEJLfCyWyp7nwapS3jQOm5XiO1Wd2RqaLO diqwfIf98WWTHSyZtkVX7eEmnFNRAMqBYh8G8obbY3SEYrpxFpJO9lA11bdUQHqFGmFJNXuN6nFg UUH1KO6QKtYOL5xqxZs0pTU18zGpmNSurQctgF6On2TGym26.s0s.7wP9x.jbJlCU3Lk3ZzaN1mx pnDuxf6kv0bg4cNoMSzqNXQb2iX12vlpnJfBXvzhOfhcqN2sLSTrSwT1yr.f82iYVxii2bkaMfmp 1tpzpAa.ArU7HDJGu0NedHa4eItP3qhSkhQl_m7OH7E8zU8fjBEbCllfOFN8qSCSYTdCYyDPNkGf I0AeymMeLHOlsqklN4TS2ZKDADTMiFC3TJPS1Uxid1QqD4u6C15JdPb14EO36PLN7SgIU5MXehNh ZzQSb9hCezAlBnw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 00:15:24 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b82c1ca1036730db1eed890c5d80df1c; Sun, 30 Jan 2022 00:15:20 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> Date: Sat, 29 Jan 2022 16:15:18 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmWtW6jNCz4nbK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OfE4AoEK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3583 Lines: 101 On 2022-Jan-28, at 22:43, Mark Millard wrote: > An FYI: I do not have problems building gmock_main-f5c28a.cpp --even > with no swap at all on an RPi3B: >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% > # swapoff /dev/gpt/RPi3Bswp2g > # swapinfo > Device 1K-blocks Used Avail Capacity > # ./gmock_main-f5c28a.sh > # ls -Tldt gmock_main-f5c28a* > -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o > -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh > -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp >=20 > You could try such on other aarch64 RPi*'s and see if > any of them require swap space to do the compile. (The > same for any other example .cpp and .sh pairs.) My > expectation is that you will find that they do not > require any swap space be enabled. >=20 > This is main [so: 14] instead of stable/13 . My only > stable/13 environments at this point are bectl (so > under ZFS). I do not not try to use ZFS with less than > 8 GiBytes of RAM: default configuration instead of > tailoring for smaller amounts of RAM. >=20 > But I've also built under stable/13 (with ZFS involved). > top did not show the build of the .o using significant > memory under stable/13. >=20 > Part of the point of the .cpp that the compiler generated is that > it uses no include files: everything is expanded inline for > the source code. Thus, no other c++ source file should be involved. > I got the copy from where you posted it. That it builds in my > context indicates that it is unlikely for your or my copy of the > source code to be corrupted. >=20 > That leaves basically compiler binaries (and supporting files) as > potential sources of variation, possibly via corruption. (This > was only the production of a .o file. Fewer toolchain programs > are involved.) >=20 >=20 > For reference . . . >=20 > Under main [so: 14] (UFS context example): >=20 > # c++ -v > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) > Target: aarch64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin >=20 > Under stable/13 (ZFS and bectl context example): >=20 > # c++ -v > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin >=20 > So, for as much as the compiler identifies its own content, they > are supposedly the same, other than having a different default > Target FreeBSD variant. (But I do not expect that the compiler > identifies something unique to the combination of FreeBSD specific > patches or other FreeBSD choices that are involved.) A potential source of variability in the llvm part of buildworld results is if LLVM assertions are enabled vs. disabled. My buildworlds are based, in part, on: MALLOC_PRODUCTION=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D But you report a mix of results on your systems. Might you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your systems where you tried the .sh on the .cpp file? Similar points could be questioned in other buildworld results for (implicit?) WITH_ASSERT_DEBUG=3D vs. WITHOUT_ASSERT_DEBUG=3D use for the builds. But this seems unlikely to lead to llvm-specific behavioral differences. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 30 01:10:42 2022 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 C30CB1973311 for ; Sun, 30 Jan 2022 01:10:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmY6S1mvlz3hLM for ; Sun, 30 Jan 2022 01:10:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643505049; bh=0JMathyNV3tXJj3seTBHBM9GY6H6PcrpTPagw56g46g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g7M6iGwTg2Q9cOYe9CVh3oP2BHYCWgDaublpmu7IqEICFDMcSnx2o/1hEmGQn1Ndc0OiizYhXW3fSUlm+Eu5NVxQ55IJrRirJdrSh6EeIXiojMdKHwmEmsCkqp5e1frUCHGTT0ikhASetwX7F+GGiJiR4g1eHgDuNotu7kCLcRJukP4xzbAO4/qrlOtvkMTOSpeBLVfwzGGk2cj5rQlkTG+BhwVzQMmAZA6Oen9QrDyHmGONwFgBkzw5zdgu+popoTyeeEYGxbL53Plz7XbhWkUUF/sxP7YqgVAa/k0NJSI9/ESoMV+rIy/xJmur/WCtGixja7Nclff5dKFN9bBWrw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643505049; bh=1bnKkmqWxHbMY9CWhQkBOVNFWjDS7ecmeV+N8AWFt1k=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iNjVvQyWuxKnZlW+dGERBVMIPLZt2P908mqioKc39X04LMyn16iPwcoPfzIxtPihhHZqZ0vCiC2POgrxL6NaHKe7oMN4gUHK1YOBAlzLyPM3YUZe4HAhA0bsupgS8nIryKGu7paDFPSh2LWEOSpZU57tm//VQIi9wQw/7hcGGPGcw1fJoEBDALdlo3oPf/JGX9V9XlAg4lREYhsPuUHxAbcrwTskobyJeMUYGh8de0W2C5IDs8OPs1tK6sSg6QqsjpFBA/8V/ccTIDGUg/wWdC478z7gQ0/PJpjGsD6RwAk69twyJrunDBfnQVKq82Oek0/KDzWDq593XXpHC/koLA== X-YMail-OSG: xl.AzGsVM1lprJtIe9nSbCFdZpQrc1cVBfUXUxe1.Oj8GFXNwaBmvSmUDi4f3VH KXAMOVgVTPKDWBnBl8_dRjetuwhu8wwLs9Jwjm6t5ukzMXMQ05N7nG04Rv07A.bSQnBSiqu8aypL 8Wfo8jnc9KdXXfV7l5B4Ev5zb32WD0pEJjjNVnZNaI2D8xE06aPOJKIyleWfIIBcmUBdSUNsegY_ g.2AJqoj1qLcfekgUWeVBXpOptQqUWmi.IvwmFCrNF8us.h_wmAcBXUfhqiJNoR.RcG7ejD3a5e2 XmePujgArhEeLBmxJ5MPMRY14IOGs8CjoxMAN6z7j31YGdeBxoMlIEuRHh9TUa8Wpav29bNgNc1N OacxwKCKIEFLCWV9Mu1SQPQVvmTJtbJzHcJpB32Uou28YntpJvNG1mLYFfaRLlZVy8iY9rroBjxT DMpOJ64CaraVEtxZ7_MtcrtrBhgBQkcBxXT.rxIk0OmSAhwi3L6ILDjcRmo70dcXxXpR2k8VKW3e 5DKd10hJ86nICw8YMyTdj_.N34b2qtba9GlenGyKEimSQ3XOWTtKcnoS2SD.hxJf14R8FhyFFQYA BZmo4liylkhFl1vSMlnegwbHO9H6vIqAVlkouMbvnVEW.BlLEWA3eXweWGjDhg7HnUZlvvGDS4MM tmvBs6tyUXtFZp7yEO7GxQLqjTCW_kraOJl0pq29wU9KlnDjF1echNhaAn2FrK.X7i61YPv4N0rR OZ_9c27eQCCfllIBt2D7qkbRfXhJbQioyiwNByet0oN2tW22WStE1IljzSfSk7eXzQz5nh2KxOA7 nfjLSyEItTOX.Yr__vxyzHjhM05JL4UaK7NOKu74PKwl7hHX_iH5oluv39mkAifO0p17pVAPhKvl 06OreCycw3mi0aaQyOlfXRnEVxSEkMF693lEcqs_b9Exxr4oTa76iqQBide.NPT4LZi6mZzgVlew QAZM4XIhIxkH1rdQZKzUlYNm6Fq9V8C8JE6r.mz82tWrhUokwGxcCJCZpcXkGnf816vnc9IImQ9v a.Fl34iNm4WSrNq10VFuvZrrQlLRmZ0oSXji8rhIIUvtrRgObYHAPKpd2dqyAvmzNgor5TwYjt8I or7JL2ywKuAM4_RPk6huEa1PTPohMByClawd04ajk1t5YszdE_pf97Dokfxe9c.SecdDWetyDwvz SauVSNEIGWn7g9YaUu3nn31D3RPth6uFU32V23YF2rPCr10zCLns49r554mPaVvioprt0wmyOxXF H2pAmCKF8Gadu35ISxIPMFD7KjTxbb9X08s.tMWUDRRiQXh8lJu4SgxgFqr6Dyd0WHt7z0KiEMYx a82rv_TWiFFMMazSO.8GSGG0cUu66EQP_wzEC6MFmQ1oKHJF1j88pnefx0c1hA3HRKYZ_BXIzflA ODVWkzOOtePa_XqXinbH0wY3IDmtq.5o9so1yZYdPh54FMoB3QJnFjieExjOq7ZvOHdVPvd4_p47 3Sqt2FkQsllt95Z0HzqE92zRYUc0MClmDFwAG.0qoIg8.GpFpgFvfYG057yJNZOmIOrZhCmwWYAn Heg3VzeanfhdrR0Xq9SlZMT1SjYTYQMICpoBu0QAqhsXHoCZKVgiV9jjvZf.OlBhkorRzma8tCDd vx73U01PSQY8Iw_hH3hpcIRM0kgbnw21vDvZxCofWav3gxZXeY18s25XGWmkw.2pg6z3Nl.2BBfM 4sEQwubLQp8Tn63ScQTleJCdAm8BYeulx.s8AI4ZR9Owics7nJSyei19ny0u3zD_4YrkpmoOmYxV ZWehsGfpklwjHV5PvDDQZmjtKA5I5zz0.EAHszuvsQEY9F2LHAjXOO4qPDNhlrNpx9VZF80t0hQb mGC3RxyBUmr41aWNSTKTOvwG0XwnPBJQjQGyS0KWj0iNOZ6yYim2gtQEKt4C0O8plu1EXwwPZizB 1HggpTyaSDjbay1Ope.N_Wo_qLZC_xIVZT9LwyKgtqcbYR_W5SOrq.GyBrKvFpa_r67ZTcqu33iY .wbx4yzxPJvc1UG3WQuEI5Jw4F0XT33qZCF9MaeHfwpMxXMchbHYOZebbhmwrY6MgBTZKWn393g2 mhzQqgQfawaQawMW8s8KivkiYI6V5WR24.08uT_iqtmU7sji7G5UOkNSTpclhKzmDlrDqiq4GoM9 FI3fMpfmdcar.qiyOdIRp8P4vNI0Bi0UFEVTpwt9fvulshI2x_0BUKreB8UzW_MkR3Odhmw08kYq Lqp2mUYk1QOwk.KHMXGdZTF6v.J.tqF1O3P8lrxyaw6nv5tiP3ByMIElnlXEMDr7ec2xWX3oge_q OrCmiYeqvZH5rtjY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 01:10:49 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 876fa21ded261a605871eacbd2b48fef; Sun, 30 Jan 2022 01:10:45 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> Date: Sat, 29 Jan 2022 17:10:42 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmY6S1mvlz3hLM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g7M6iGwT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3923 Lines: 109 On 2022-Jan-29, at 16:15, Mark Millard wrote: > On 2022-Jan-28, at 22:43, Mark Millard wrote: >=20 >> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even >> with no swap at all on an RPi3B: >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% >> # swapoff /dev/gpt/RPi3Bswp2g >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> # ./gmock_main-f5c28a.sh >> # ls -Tldt gmock_main-f5c28a* >> -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o >> -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh >> -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp >>=20 >> You could try such on other aarch64 RPi*'s and see if >> any of them require swap space to do the compile. (The >> same for any other example .cpp and .sh pairs.) My >> expectation is that you will find that they do not >> require any swap space be enabled. >>=20 >> This is main [so: 14] instead of stable/13 . My only >> stable/13 environments at this point are bectl (so >> under ZFS). I do not not try to use ZFS with less than >> 8 GiBytes of RAM: default configuration instead of >> tailoring for smaller amounts of RAM. >>=20 >> But I've also built under stable/13 (with ZFS involved). >> top did not show the build of the .o using significant >> memory under stable/13. >>=20 >> Part of the point of the .cpp that the compiler generated is that >> it uses no include files: everything is expanded inline for >> the source code. Thus, no other c++ source file should be involved. >> I got the copy from where you posted it. That it builds in my >> context indicates that it is unlikely for your or my copy of the >> source code to be corrupted. >>=20 >> That leaves basically compiler binaries (and supporting files) as >> potential sources of variation, possibly via corruption. (This >> was only the production of a .o file. Fewer toolchain programs >> are involved.) >>=20 >>=20 >> For reference . . . >>=20 >> Under main [so: 14] (UFS context example): >>=20 >> # c++ -v >> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >> Target: aarch64-unknown-freebsd14.0 >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >> Under stable/13 (ZFS and bectl context example): >>=20 >> # c++ -v >> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >> Target: aarch64-unknown-freebsd13.0 >> Thread model: posix >> InstalledDir: /usr/bin >>=20 >> So, for as much as the compiler identifies its own content, they >> are supposedly the same, other than having a different default >> Target FreeBSD variant. (But I do not expect that the compiler >> identifies something unique to the combination of FreeBSD specific >> patches or other FreeBSD choices that are involved.) >=20 > A potential source of variability in the llvm part > of buildworld results is if LLVM assertions are > enabled vs. disabled. My buildworlds are based, in > part, on: >=20 > MALLOC_PRODUCTION=3D > WITH_MALLOC_PRODUCTION=3D > WITHOUT_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D >=20 > But you report a mix of results on your systems. Might > you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. > WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your > systems where you tried the .sh on the .cpp file? >=20 > Similar points could be questioned in other buildworld > results for (implicit?) WITH_ASSERT_DEBUG=3D vs. > WITHOUT_ASSERT_DEBUG=3D use for the builds. But this > seems unlikely to lead to llvm-specific behavioral > differences. I set up and tried a context that was using WITH_LLVM_ASSERTIONS=3D and the .sh based build of the .cpp I have still worked (no swap space active). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 30 01:34:37 2022 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 1A8881985244 for ; Sun, 30 Jan 2022 01:34:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmYf55SXtz3s0n for ; Sun, 30 Jan 2022 01:34:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643506486; bh=ZSjwINergdKWPLnSbVax330jJDdVWTaMTmLeEXe2zJI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FCvtUMTid96EpTNeCrhb+EpfedSFQ1CXlVI5KZxs/leGF5uFl/169Bu5PCCaf3IehvWqeujuhVQ+PbKZQGSodNGP0i8yzV1A/peEXGYxeljJEx4q7pq/EuCnEMQ6M7eGCljrlVwUJS3L6Wa6ocUUn5w/My226IrXG/nhLBd3abwlogYMYMghEPbGjnK7xHeFXrWuqy6Lo1CGbtwW264a5TWpYJtr/LgupqoEQIn2rxrggZXKWPKxUalne4o9xshzaedeWJZeqXJYDyIIOIe3lD5Ue3ONC4ZwhiqmvPZn6mzvtD7kYF1DpRiPf3ENAJVanldaxdZKS2QyUN7P0N+v/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643506486; bh=giwtskccE3+7MM0LAV4rIN10fbOvrcrkDDucGYQe0jg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GkhhyAGrDNNuXKcg71zdOUrb1nlxJ5jEpBPjGa9jJSUT8cMrzYQ5nKg8iyRTpuD8lwqdwhysxm7u6Zva2wbpwZrsJeijoPTs1k/1eU/kMSyw1B7R/N44YlLlo8KSrmlM5TyCZdK8C2jk1TK+YqInnLwOgIdANo+g86inG/CcvRVVBaqBNkc1NeIff7h2eiI6UULThpDP3jQ+6H7BvTykCX9BldykN4b0TcbgDUiqn/ajssMN6BYX6EvCbrOZmQx14oGbfp2buVU9ANrx9z9kNNdQmyBM0+nItKOUsqY5nKSWfEpiI/jfNg/z8y/xDtIDl9gRXiRMkOnK7EnBTDTyRQ== X-YMail-OSG: iTfkrTAVM1lQ_2dq0TmChIWavkeCjUY3WWux1BXDr0u4CR0VxZE2quZBmKDGpYb cFE6Oy5XWbX2iEZyqaX0JboLAY9xx_Y2eJUEwVCafr_LsjvW3igOJiD.AzKtN25PrLl62_Yl0xqU z52M22WEEd36qFlm2QIAHUmYIh8LylX5biWsqW2oaZ_DgLI0nGW3jRg6LmJJp63lKQZF1XmKSjvk 3VwLrCjsG.gOuuZ.jo1B_.5cVgVq4ELcll_S_1SE7i0QUFCp5VE0fwXMBZyISLOBcfz_y8FzI9FY 090HJCWv4OVIsQYv1HXWX9wIVm3MYmA0C3XhppNWucINO.kj8qOkvsYSKIdcexQNzVq6Q6JqITFH 4NzgR9GrgmIitRBAUydGWotLWJK4eQhzxLvdRgyCdqDCrmii0lsYNj9aTZ6T._9dCZydBDp0gmai weyjuRTKqY3PGlUXol_EcUTXw_5FhJtnf6qF9yIkk1KTX5s.UbDp6ZMl9TxsW1wAaNHfPFDeBSG2 URgUHoS_FW8N5rhus_eRLsC0e3n8wGIXWxXXuDzIdwCUM8MWCie_RS3fjzgzxn1dt2aSfVDmDatz mHiCTeVj4og2rwJeTq3RvpNe8mRP7AprX0j56YfbwgGGL5_DwNRL0vU_nL55dRMA_vi6uz7_TsIW 5agMxFMYoD_QJJdABLRPQpminp9aw3clNuIlpHZFT9vkwO.yUkeWyOKYA9SgvVYV8lCMDuATkbgQ MFuvv0hjEpXro7XCrTKEZ6Hfg5yhob1o43oFkrc130zbQpPfNup0tsLXVm0mfifyJ6PWejd7ArYR zTmG_Z13ZOIuPM5CCp2JTKslm2ykjY9Sju2OaDCkXUXWSsHO2SgztXyLDBxJ5VAK3RII.c1T.EQj 2ZzZyqvCnUhwS6DWEl0Oqw0ZFSgzvgDFL00uuyqo17ltgLlPZ7iEUqLBm_.wdTws.xdXZTZzJEZl 3lekgMLczTfuScQ7MCs6mdPwKM94ZBuiB.TLswsvT8enFN9DcBDyxF7HaAx97Rk.uER9bvQV2ZWs 4qUOg7k2gLbu0vLLLSe47juBD.fSkrUpq935G7y.Zg5rrUAWCC_QQLro2cE_zI4TNBRiFWSfLtOs YLUw9PIsh2B0aVoCcYEE7i9QpnRBQhBnRQy42C_UyL5SvJrS6JFb7IkdkihYVLCWWreQfKNsnnoa Eq2uPO3pT4L0M3cKy_nTgC0p_jAcBtL2YSbe3UM5O5mlp3Wr55YqjUGNq9vLRSGbWCa8az81xEAI pEXptUoP3oaefvEdRk9PH2Px7Pj8A9PyVMVRzkrnyEnO_3QiDQzwxOfqTEn8MXCLeA5TC87QW7LZ B4Uw4v4isCxFJ7ePeDrBih3uOKNX3TbbpNu3VCA2HNb2wUU0enapV_qKXhtttFCEAmKlul0QEBMr Ooqpc7GzEbKlyXE7pNj170ZjBxgxkjMG7kwZwRxIsZIlDscu0zoia_s.ZMRu208CXT96Wjlv4C2c N0UH8sxak4TDoC_JkP5nuZEIylmRR7GL4S2cW_6i9Hab8BKMZWMaC2DPnIpFjSjcdIVUN2sacMy7 5s9GGXRc.St2AIYZV84pFe.FdxBRL3QcPl4UBRwFrZ0jCt9GY4HJ1zlLN7ByUq_BLxqCpx1CXowC 4Eqn5rQzT47dZxwzzOQ59hC1ki4jqAO4EeI2K8juNun_swZQs.cRbIqs2NEFfTqJpzQQS10CFmiI hEy_ow5VVHXJRoUXKEBs7XjofqPHRM0IYv_yq8SUU4Fgo8qVjjugk89B7qk5ltYClWIIlhTErPu6 mwezgiakXYm5ObfNIbOZc4SRjAZ.SfZVMrxdqjh0IsPa35fqalnKY.oL1Ja59Vkxasb1FsCP4djA ECXsjad2Zl82qWjmZIQOHCjEcv1AmPx8a4.NOFcgAa1Dpi6V7uTK0TNPMYCr.WNvc41MQWP7mPeo JNVbT.n9b19rFawDS_Qye3EipCFlRhSFLvEiVYSS6vNKd_CvKniFCheljciYrvr4leSXRYp5av9Y 7qGR3s6LX4uSFq988hhT4CiYeDilRQuadpzUuqZsRAqosHEPNG7uSCsZFc23M47EnJVNyQyHX8dz nEnFExUR74cyYwC.viTZ3Qr0SKCN8sR.GBskxo6NTEIB843HwMAkrzoQsa64svJGPDaK8qLT2vfL V.mEN_HUXTacCxbHWy096REbU8rY8L3UB5tgw5ViB.p6LdHJFh8Vb7mbtG7xZwBDu4fKJTwkQZCT oFNpFypdhPmHytEdFU2ueX2svYmNfKI.1uqotzMaw5_.2XwoqzZO1_ykx7Do4QtzcbLzA7_Gmwmv ye8ETYYkSYPXniQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 01:34:46 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2679683ce30c5c44dcc66be4e6716f2f; Sun, 30 Jan 2022 01:34:40 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Should a UFS machine have an ARC entry in top? From: Mark Millard In-Reply-To: <20220130001829.GA63427@www.zefox.net> Date: Sat, 29 Jan 2022 17:34:37 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220128182701.GA57479@www.zefox.net> <20220129204313.GA63030@www.zefox.net> <4D29091D-AC99-4D8D-AC3C-646A05529E26@yahoo.com> <20220130001829.GA63427@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmYf55SXtz3s0n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FCvtUMTi; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5422 Lines: 174 On 2022-Jan-29, at 16:18, bob prohaska wrote: > On Sat, Jan 29, 2022 at 03:30:35PM -0800, Mark Millard wrote: >> On 2022-Jan-29, at 12:43, bob prohaska wrote: >>=20 >>> I just noticed a new line in top's output on a Pi3 running = 13/stable: >>>=20 >>> ARC: 3072B Total, 2048B MRU, 1024B Header >>> 2048B Compressed, 20K Uncompressed, 10.00:1 Ratio >>>=20 >>> This is on a Pi3 with a UFS filesystem, near as I can >>> tell ARC is something to do with ZFS; have I got something >>> misconfigured? >>=20 >> ARC is for ZFS and its being in use suggests a ZFS >> file system is (or was?) at least slightly accessed >> at some point. >=20 > Not knowingly, just ufs and fat32.=20 >=20 >=20 >> What does: >>=20 >> # gpart show -p >>=20 >> show?=20 >=20 > root@pelorus:/usr/src # gpart show -p > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 2016 - free - (1.0M) > 2079 102312 mmcsd0s1 fat32lba [active] (50M) > 104391 62229561 - free - (30G) >=20 > =3D> 63 62333889 diskid/DISK-29ED3EF6 MBR (30G) > 63 2016 - free - (1.0M) > 2079 102312 diskid/DISK-29ED3EF6s1 fat32lba [active] (50M) > 104391 62229561 - free - (30G) >=20 > =3D> 63 1953525105 da0 MBR (932G) > 63 2016 - free - (1.0M) > 2079 102312 da0s1 fat32lba [active] (50M) > 104391 1953420777 da0s2 freebsd (931G) >=20 > =3D> 0 1953420777 da0s2 BSD (931G) > 0 57 - free - (29K) > 57 6186880 da0s2a freebsd-ufs (2.9G) > 6186937 4194304 da0s2b freebsd-swap (2.0G) > 10381241 1943039536 da0s2d freebsd-ufs (927G) >=20 > It turns out kldstat reports=20 > 6 1 0xffff0000c9a00000 3ba000 zfs.ko >=20 > but /etc/defaults/rc.conf contains: >=20 > # ZFS support > zfs_enable=3D"NO" # Set to YES to automatically mount ZFS file = systems > zfs_bootonce_activate=3D"NO" # Set YES to make successful bootonce BE = permanent >=20 > # ZFSD support > zfsd_enable=3D"NO" # Set to YES to automatically start the ZFS = fault > # management daemon. >=20 > There's nothing related to zfs in /etc/rc.conf, either.=20 > Any other places to look? /boot/loader.conf The FreeBSD loader supports zfs and will detect zpools as well. That is part of why booting can initiate a zfs.ko load. > The GENERIC kernel config doesn't contain it, could it be included = from elsewhere?=20 zfs is not normally built into the kernel but loaded from a external zfs.ko file as needed. > Perhaps more to the point, does it matter? I've read some claims that > ZFS is a memory hog, consistent with the trouble seen on this machine, > but the extent to which the claims apply in this case is unclear since > ZFS isn't in use, only the module is loaded. =20 The ARC is present and active and using memory. How well behaved that is with a default configuration but only 1 GiByte of RAM I do not know. You may well want to avoid any extra use of more RAM. I suggest you do a reboot of the RPi3* and see if it automatically ends up with zfs.ko loaded by the time you can log in. If it does, then we need to figure out why and fix it. (But you might want to read the notes towards the end of this reply first.) >> For reference for when no zpool has been imported: >>=20 >> # zpool list >> no pools available >=20 > Same result here. I'll not unload the module just yet, > for sake of finishing what's been started. =20 >=20 > Maybe this is another red herring, but I do wonder=20 > how zfs.ko got loaded. "How" but also "when" is important. What else was going on at the time that lead to zfs.ko loading? > I did use Windows 10 diskpart > to format one of the fat32 usb flash drives used,=20 > but it seems a stretch to think that's the cause. Agreed. There is a command that might have to be used on some device that at one time had a zpool on it but now does not. . . # man zpool-labelclear ZPOOL-LABELCLEAR(8) FreeBSD System Manager's Manual = ZPOOL-LABELCLEAR(8) NAME zpool-labelclear =E2=80=93 remove ZFS label information from device SYNOPSIS zpool labelclear [-f] device DESCRIPTION Removes ZFS label information from the specified device. If the = device is a cache device, it also removes the L2ARC header (persistent = L2ARC). The device must not be part of an active pool configuration. -f Treat exported or foreign devices as inactive. SEE ALSO zpool-destroy(8), zpool-detach(8), zpool-remove(8), = zpool-replace(8) FreeBSD 14.0-CURRENT May 31, 2021 FreeBSD = 14.0-CURRENT There are also places like: # ls -Tld /etc/zfs/* drwxr-xr-x 2 root wheel 2 Apr 28 01:41:23 2021 = /etc/zfs/compatibility.d -rw------- 1 root wheel 3736 Jan 27 13:42:23 2022 /etc/zfs/exports -rw------- 1 root wheel 0 Apr 30 06:31:09 2021 = /etc/zfs/exports.lock -rw-r--r-- 1 root wheel 1416 Dec 14 16:03:49 2021 = /etc/zfs/zpool.cache Another directory that can look similar is (as I remember): # ls -Tld /boot/zfs/ drwxr-xr-x 2 root wheel 2 May 20 20:57:00 2021 /boot/zfs/ (But mine is empty.) There may be things to delete from such places on the RPi3* if the directories are not basically empty. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 30 02:03:43 2022 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 8DF9B1996F4C for ; Sun, 30 Jan 2022 02:03:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmZHY4YByz4YBf for ; Sun, 30 Jan 2022 02:03:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643508226; bh=W291r65kTFEd6sknYqHwZ74pKQsjloVGC05hCkF1E/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KHLUGJhUL72rXQNyOiofIo99tD0D8I8TP2m+v5ashn0qji99EGBqz5R4E0UYNlwkybqSofaIS0esRx/B6NQ+WM7lfITcLKMQLGjI0g9vEklP3yjaIFGDpWGlHqFvSuZHeeF9XnIsYL68hF1GouzAXKANvnOhQqWX6Xemt6YiCjJAwSdwpQQ92fnYeJimNW4jkidGXkyP9W09KBnTbTDw0UfsKDnlpmbUXGrEejKiZTuLgmZ8YWzuORCHNGw03V5fg0jYNUhqTuOopTeN4TtwSkWWSHV54FRKpBxzNOEBcpQWrkgg2uzZ2EcoEX7m0WxLso7A3N5VpLu8ZU+YCuNPxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643508226; bh=6uHApRA6iinf/64jC0Icqdv4HdybtlLhNPs/pMnpImD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZDvXGWmPLULF7DzQfPamHQz4/n67RJc9iWbQok7a3xJBVC4Nl+uVESYjxFVM2OWjovS7EqA0i0UZ7aC8i34vO/wQfG9jJfEq9K9kA2gc2Pa9xWv2S3mfhnq+g3y6satsu7MtAGsIGsVCZLZBKr+3kpONptF0IlHmAHdLmT7CycHh7auC3DrXXM0kp+CvspA+SqtuzHLMStPB4++HCIxmyy4UTwWx0EsvGmumS3VyrHl06Jr+e2V6wrKg7yvCLVos/qxsiXxjNxDQcKAI/uhk6Y4zazRBbjKaI4HcpPpX84Awl9Jnr2I02tbFiAuAvVr/ouhtfjnyYk5uW+JzHrUbLg== X-YMail-OSG: BNLXH.EVM1n6xjr2CzfXxk4nMJwXmbf1.bp.f2Kye7s0yv.SOvVXEiEOnprLBYB CZi_scVHPQwzUMTTvyuBPC7Ch2FnHO8LTSkcI5vAE7IOJJ78oF3vYQAU6CojgTFKbTOCckBsflHG QaA5__4e58wZ0qcrAaDr9iFFyUJVYNUlViE.LKIjGs_Xm.bYdtjba32wg6rZlrqOzlw_lh4SCfuP cOWRldgC3Sp14WQkaDtDQfd0u_ecAorHi7rUUtJReDWpStW02hPfdkLJTAH17IoR.l4SHquUiHV8 JEgO_ZwCjeHzeUuAlLWVqPWqfB6GUB3Nq2Xttp_1Fnjr63evt5VCt_aFpEbTsyAhp3QquRZWBJxC utUPM.jUrxhvFnvh9swCFdMEjC7mTc86qv5MGNk89k8CS0f_2b_iPx73nrAroJ3arKsSRIhqviQi wiEM2WZwfbRv.HbDENvsviVZNOMaanmG23BpOZ.S_bikIjJMLzjaxyBIHRMcOdHa0Ffedp7XdwIT pXneMSNiHxjY4v4GREXZi086HGFbGCLd7MAP0tXUmy8V1aOvs15KIgrkGuUobTzFuLIqV_du04I2 5pEvQ8Yc0sI4nGBsLLcsI8joaZpGdUBWZvD_DczKCmU.TN5ENhtB1d_KI2HOnSqUnaD7sr2vP2kC VesmeEPCXiXcFzJ9LePJCjCmKUdGqPZa7f6vY1CyZOBDNsznj193Ag8_bX55OtZl3MYQEqSPeObR W6kVSNLqtGh9quss4uw1un3pSnFdIXi4WsQombwbqmKPKIunVgbeELaZTB3dtpmDylCnn2EJxkx3 zc746mXFA7i2Js4e02MPEGuYg3lqwVj8f1yqgNX0QScvxF3B59mGcDtojmLxWjh.wer0L7MsTVrt x46mjMxOCaZ_e.zGE6KUrTZNW9nayoIVb.1fpTa8jjNAOeaFTykXjT9ebIfnXzuDU56L2ghU2VPF 8uYvNouAPWNZG9F7ATdS.ktHBY4i5WFW8ax0MleDbeBpXBVPzoKkWl4iOZMFa9LUct9.VIiAQCOW 0MDCqDaTegHqcW_WZowrRgK0_yWK8th.OQLoXUDxTaGDGs.obYzOLYIHf1f3WtjJEuiU_Kq42dYt qGXzSPYZXbEiDqt7nwbSNnwtB0ECjH_1gIg7tpdx9n0goyD4GHal9uAUGwdCw6r8fEt8hpyPpO9X cCv2ap0rLRNzC0VVqbXiqPp7K241mqgzFZgteefAqeBZ.mbtfgDuIA4OLggn0rSGmVpg2IxkXK8X BT26BSqIBSebaJA8XzTCWhJtz1wXah8sgYGriLBh7aqmMI56l84dURpT.m_WGBFHjwj2qOWeXD8r 2CPwEv4RkGARCjjOMyUY.b7HLW0yxydPc8YxF5bYsrr98bOzmXw1N9NKa4_Wz.oREVLXnbkJNAIr y7a.RLONFMDqq7bQt4xmULe6eRZv5LqNNEjT8vIllySdKO4wcn1gdooOBnf70ebArm_Kl5aBniW1 Q7Rm_aU57O.al9g_zAhhWC9i_KOo2ZpmJuv8fCPi_4cRINFg3vIL9_OCcFjU9fNo9ndrgmyaLdmT 3YTS2Ii0AzY3YamCWJcZ5jvajL7I9Jl7dwfrvfC4dezeTpMVodFc1c4w.SIHkGGhwy6a7NHk6mOA YAdHNqwRbFKp1dpldN.6APLKnpA3T2FdTOb.PxGXdUzCoRZnaOz._osq57KjnJgW6E7v9litUIVR Y.00eMOVyNsGtwPhTvai4kvX_UG4Y5_LHPeF9FJgTynFDyddMtRWOwdGbNFH6GLrJUMS7gaivtXR bhM2lHPYdQRqmt0K2w4BN6CByJhZ.K9yqw28yhAB6Clm_nS63NTB0Qwph.gG4S2flt9o.ynfGPMa TaEiluJPnGfEIfYQYy99CRkZTKzpeWmrfVVrrFaJbD8QJvwmJ70YGcVdwqmabVd1dXP3axc0Q2zY xEWj5or3SdCLabPrG_uCOgmfCFw7NU_mOkICvaZlrkZSkAee9170cofoJ9MRgMXefrYY9Cz9CUyq 9Ii9UQ14AzX10EBSTUyP.DrAunezy1lLiOtBitnfYSli0AGtgyeLhbv5tQ5ZhWAlYLsG7qYy2L99 _OxBcsTlb_vkSHNJluXGXI3hVG_TtmqYMq2r5kqv6LGafDP3rCCkD_zsvfZ3Lxj5znxPsED6mKOQ sh8kEUa7FPKUaciDQj8wB8BJPnmu.JnlADfzGnFOLvbyIQ6S3u8w4W6SKW_OFnAlpTX.NZ_oXKxy 03heV6ruxS8LEYD_3ZdY4kp0xCWoHeh1X7CxdFSUY9cEXHgL.CKpnre0S2iBz4ZUAOGLm5j2VFmw zO_DaJXieXaahPJ._MWjyyS2gdtjmcIyWKlrybgdfNNyfEuAuqg95nOYpwsWN3UJuRH0xh00znWM ShM8Bqw36hSUzXYyytpoo4jy9f4.WGZ.oP6pSDn1WnX7VpqlHcV74.ISfSez4uUDeS0SQDA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 02:03:46 +0000 Received: by kubenode533.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3a9cf4c12eab749c7393f32cccff8586; Sun, 30 Jan 2022 02:03: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> Date: Sat, 29 Jan 2022 18:03:43 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <6041A6CC-BBD9-48BD-92B5-243959301A3D@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmZHY4YByz4YBf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KHLUGJhU; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5611 Lines: 158 On 2022-Jan-29, at 17:10, Mark Millard wrote: > On 2022-Jan-29, at 16:15, Mark Millard wrote: >=20 >> On 2022-Jan-28, at 22:43, Mark Millard wrote: >>=20 >>> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even >>> with no swap at all on an RPi3B: >>>=20 >>> # swapinfo >>> Device 1K-blocks Used Avail Capacity >>> /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% >>> # swapoff /dev/gpt/RPi3Bswp2g >>> # swapinfo >>> Device 1K-blocks Used Avail Capacity >>> # ./gmock_main-f5c28a.sh >>> # ls -Tldt gmock_main-f5c28a* >>> -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o >>> -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh >>> -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp >>>=20 >>> You could try such on other aarch64 RPi*'s and see if >>> any of them require swap space to do the compile. (The >>> same for any other example .cpp and .sh pairs.) My >>> expectation is that you will find that they do not >>> require any swap space be enabled. >>>=20 >>> This is main [so: 14] instead of stable/13 . My only >>> stable/13 environments at this point are bectl (so >>> under ZFS). I do not not try to use ZFS with less than >>> 8 GiBytes of RAM: default configuration instead of >>> tailoring for smaller amounts of RAM. >>>=20 >>> But I've also built under stable/13 (with ZFS involved). >>> top did not show the build of the .o using significant >>> memory under stable/13. >>>=20 >>> Part of the point of the .cpp that the compiler generated is that >>> it uses no include files: everything is expanded inline for >>> the source code. Thus, no other c++ source file should be involved. >>> I got the copy from where you posted it. That it builds in my >>> context indicates that it is unlikely for your or my copy of the >>> source code to be corrupted. >>>=20 >>> That leaves basically compiler binaries (and supporting files) as >>> potential sources of variation, possibly via corruption. (This >>> was only the production of a .o file. Fewer toolchain programs >>> are involved.) >>>=20 >>>=20 >>> For reference . . . >>>=20 >>> Under main [so: 14] (UFS context example): >>>=20 >>> # c++ -v >>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >>> Target: aarch64-unknown-freebsd14.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>>=20 >>> Under stable/13 (ZFS and bectl context example): >>>=20 >>> # c++ -v >>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >>> Target: aarch64-unknown-freebsd13.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>>=20 >>> So, for as much as the compiler identifies its own content, they >>> are supposedly the same, other than having a different default >>> Target FreeBSD variant. (But I do not expect that the compiler >>> identifies something unique to the combination of FreeBSD specific >>> patches or other FreeBSD choices that are involved.) >>=20 >> A potential source of variability in the llvm part >> of buildworld results is if LLVM assertions are >> enabled vs. disabled. My buildworlds are based, in >> part, on: >>=20 >> MALLOC_PRODUCTION=3D >> WITH_MALLOC_PRODUCTION=3D >> WITHOUT_ASSERT_DEBUG=3D >> WITHOUT_LLVM_ASSERTIONS=3D >>=20 >> But you report a mix of results on your systems. Might >> you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. >> WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your >> systems where you tried the .sh on the .cpp file? >>=20 >> Similar points could be questioned in other buildworld >> results for (implicit?) WITH_ASSERT_DEBUG=3D vs. >> WITHOUT_ASSERT_DEBUG=3D use for the builds. But this >> seems unlikely to lead to llvm-specific behavioral >> differences. >=20 >=20 > I set up and tried a context that was using > WITH_LLVM_ASSERTIONS=3D and the .sh based build > of the .cpp I have still worked (no swap space > active). >=20 I tried the .sh after having zfs.ko loaded. It still compiled the .cpp fine. (main [so: 14] context.) Unfortunately: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/?C=3DM&O=3DD= does not have any RPi3* supporting images to try. (RPi*'s are not the only aarch64 things missing.) Anything else requires dealing with Paritioning, RPi* firmware, U-Boot, and the FreeBSD loader separately from getting FreeBSD itself in place on media (after partitioning). = https://artifact.ci.freebsd.org/snapshot/stable-13/037fe75b38c1f177087076a= 1027f6b035db8859f/arm64/aarch64/?C=3DM&O=3DD has files that can be used put down a debug-build copy of FreeBSD. (There likely is a better match to your boot media's version available too. I just picked a recent example.) If the likes of: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/?C=3DM&O=3DD= had an appropriate image, one test would be to put the image on a microsd card and also get the .sh / .cpp pair in place were it would be accessible, and boot and try the test just with the micrsd card in use, no other media. (Remember that no swap need be active.) If it worked, then the RPi3*'s normally in use media would have been likely the source of the problem. (Points a direction for further investigation.) But if it failed, that would have shown a general problem for stable/13 . (Picking an image as near to your existing boot's version as was reasonable would have likely been a good thing for this kind of testing.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 30 07:33:15 2022 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 3EF1019913A1 for ; Sun, 30 Jan 2022 07:33:28 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182]) (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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jmjbq2Gp1z4bNT for ; Sun, 30 Jan 2022 07:33:27 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from smtpclient.apple (87-95-54-93.bb.dnainternet.fi [87.95.54.93]) (authenticated bits=0) by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 20U7XKOv027782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 30 Jan 2022 07:33:25 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 87-95-54-93.bb.dnainternet.fi [87.95.54.93] claimed to be smtpclient.apple 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 15.0 \(3693.40.0.1.81\)) Subject: Re: RBPI3 for FreeBSD 12.3 From: Stefan Parvu In-Reply-To: Date: Sun, 30 Jan 2022 09:33:15 +0200 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> To: Mike Karels X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4Jmjbq2Gp1z4bNT X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.77)[0.769]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 239 Lines: 9 > There was a u-boot change required to boot 12.3 on RPi3, but it = didn=E2=80=99t > get checked in before the ports tree was tagged. I see. Do we expect to have ready images anyway published or we move fwd = to 13.1 ? Thank you Stefan= From nobody Sun Jan 30 13:21:41 2022 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 F39911994240 for ; Sun, 30 Jan 2022 13:21:44 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4JmsKh1DPmz4m7Y for ; Sun, 30 Jan 2022 13:21:44 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 20UDLgc2065198; Sun, 30 Jan 2022 07:21:43 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id EfXKEOaQ9mGs/gAA4+wvSQ (envelope-from ); Sun, 30 Jan 2022 07:21:42 -0600 From: Mike Karels To: Stefan Parvu Cc: freebsd-arm Subject: Re: RBPI3 for FreeBSD 12.3 Date: Sun, 30 Jan 2022 07:21:41 -0600 X-Mailer: MailMate (1.14r5818) Message-ID: <7C430492-002B-42A5-BD3E-2FA6B6A92D17@karels.net> In-Reply-To: <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> 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-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 20UDLgc2065198 X-Rspamd-Queue-Id: 4JmsKh1DPmz4m7Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-1.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[karels.net]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 395 Lines: 17 On 30 Jan 2022, at 1:33, Stefan Parvu wrote: >> There was a u-boot change required to boot 12.3 on RPi3, but it didn=E2= =80=99t >> get checked in before the ports tree was tagged. > > I see. Do we expect to have ready images anyway published or we move fw= d to 13.1 ? I haven=E2=80=99t heard of modified images being made later. But 13.0 is= available now. Mike > > Thank you > Stefan From nobody Sun Jan 30 20:58:04 2022 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 7D4B4199CDF4 for ; Sun, 30 Jan 2022 20:58:06 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Jn3SG37hyz4cNh; Sun, 30 Jan 2022 20:58:06 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643576286; 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=W0/q5/v2+1w8oggw8BmTb9M0EuSLbnxzjKRw0J10SNo=; b=CvGZ5rWZfN1zxeAuDlQOhFHWfDyLwFXwzBeiqEdzDcIcUt592VKutDQW0HpG2RG27G5jTK bMYq7/VGnPXZEf/B0Shks2JbXZgJuo90qrlKzM3xC1xZ3QJwODWe5csOkTOBEmciNgKneB EOyfnoCnw0DNjjj6vlvZgJIW/Q37f1oCimIgE0HIIh3SD6/QmuZgDPTwRwRUdHgxqsW1vh K8C/uu03789YfqSPTXvIsJL8C3DTgDKIzU9IEIBXK5go6s867KceSAeSCuUqorHilwNg55 JJV/jc76KLR4rcEt+pNQ3ZcX3iQAw/rQIOeIGqnET6ETz7mJUUWJSufOvDChUQ== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id D80C69931; Sun, 30 Jan 2022 20:58:05 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: Date: Sun, 30 Jan 2022 21:58:04 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: pinebook pro video console not active Content-Language: en-US From: Jesper Schmitz Mouridsen To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org, Warner Losh References: <4d738da2-28f0-6af2-4213-934244cc95f2@FreeBSD.org> <20220126115453.255661b2e55f946d11eba1e9@bidouilliste.com> <66042fd4-31fa-408a-3ec8-b911118750ef@FreeBSD.org> In-Reply-To: <66042fd4-31fa-408a-3ec8-b911118750ef@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643576286; 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=W0/q5/v2+1w8oggw8BmTb9M0EuSLbnxzjKRw0J10SNo=; b=MsO1zP5aI78kjBF0pQSFWHdFREbdlLKPBEdsYDnBIukwcMjjEWKLNppYm/0m7qodxW6S4o bCHztm/zC0bBHY+7WIMzMFtvEQGHryUG01iDt1VcoQsCJM4ph5FB0/PJzWdJYA7/jyCXah WihZHHYmay6pTZguLoWb1iRPgd8WLVBWrta+Xq7u7GyjcSxfH6GWAnMwPRfn/6mhiuxjfL xOvpN7n4wUSKXUHy2sDQWUSxe3ELthHUDtWsxuWOD9PORyy6yT1OH0IA3H0rbZ7Dz80NI8 pf0ZfKFWGL1lp1nec/Fu1uXggk3Ve4Pos0LPVtqWSUUNv4e+yNGol815v9qsnw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643576286; a=rsa-sha256; cv=none; b=VKznN0DDViY0j/TthrTh2Ez1wVPLXrehjL4PXwxvu6zRkPs4g2cgVl4fUJYhmMXIMMxrNX 8m9rU9g5Y3cMyIbKhOC8cqSaMM6s5RqDnytlbU3A4/p+GM42dfYi2ZSvBBbWseVWznu39i nsLSRkufUVt18lO51IiK2Ky5hcmIGL6P19LiRfzQKYIwcJbBIn2K9aDD7zMz10UpkWYRhF VyiNV0YUhrDEcwHNIOjyNr0CWZmU5NsGQYZEo3SmaZSqjwH2IGx0Rj+qR2sxUE4Lez6mZT ETUXZdl9RCPfLr1OpOBmA72jTpG1GMdYa0tmRWWu9JZ5u7JZGcGcFtp3VQEsTQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2358 Lines: 79 On 26.01.2022 12.35, Jesper Schmitz Mouridsen wrote: > Hi > > On 26.01.2022 11.54, Emmanuel Vadot wrote: >> On Wed, 26 Jan 2022 00:44:33 +0100 >> Jesper Schmitz Mouridsen wrote: >> >>> Hi >>> >>> On Pinebook Pro 14-current with console="efi,comconsole" in >>> /boot/loader.conf >>> vidcontrol -i active < /dev/console is not working because serial stays >>> primary. Reverting 123b5b8763778e83b6816ad9db62a9b956055c32 fixes that >>> for me. Can someone share some light on why that is? >>   You also need boot_multicons=YES in loader.conf for this to work (at >> least on amd64). >>   Maybe imp@ knows more about this behavior. >> > Yes I have that set as well, my loader.conf is > > hw.regulator.disable_unused="0" > boot_multicons="YES" > console="efi,comconsole" > beastie_disable="NO" > loader_color="YES" > ums_load=YES > >>> console kit relies on /dev/console beeing active so it is an annoying >>> bug.. >>> the original review is here https://reviews.freebsd.org/D32992 >>> >>> >>> Thanks >>> /jsm >>> >> > A little more information, with above with with frame_style ascii and 123b5b8763778e83b6816ad9db62a9b956055c32 reverted, I see both on efi and audio jack serial printing "console comconsole failed to initialize." From line 268.. 263 if (active != 0) { 264 /* 265 * If no consoles have initialised we 266 * wouldn't see this. 267 */ 268 printf("console %s failed to initialize\n", 269 consoles[cons]->c_name); 270 } in efi/loader/efiserialio.c line 489 comc_port->sio is NULL in my testing. My u-boot is from freebsd ports unmodified. I have not read all the code but could it be an explanation that comconsole fails and falls back to efi, but that serial is actually initial primary despite the setting console="efi,comconsole"...? when reverted the commit does set comconsole as console... Just thinking out loud, not sure it makes sense... efiserialio.c: comc_setup(void) { EFI_STATUS status; UINT32 control; /* port is not usable */ if (comc_port->sio == NULL Thanks /jsm From nobody Sun Jan 30 21:01:01 2022 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 AC127199E819 for ; Sun, 30 Jan 2022 21:01:06 +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 4Jn3Wj0dRFz4dbc for ; Sun, 30 Jan 2022 21:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 0D26C7D4C for ; Sun, 30 Jan 2022 21:01:02 +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 20UL11nY076304 for ; Sun, 30 Jan 2022 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 20UL112e076303 for freebsd-arm@FreeBSD.org; Sun, 30 Jan 2022 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202201302101.20UL112e076303@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, 30 Jan 2022 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="16435764618.2d8E.73407" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643576465; 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=AyiNcNUpuV88qP19GiB7mznC/XdHTYbye2iUYR9K/4Q=; b=dsrC2CiQ3YuQdeMk5aRkNLp84/Qu9WRB9jSpVKm+w9+dNw16tvoJ+zeEm4j1QOermQQKwN maZLZvK6LG4ysazi7PVUZaHL+OdesiE8fmq8rBmV6RKD1fmJ/xU1vF6NQ25LmNn4n3VFXS MSvrUFCZyyr7wDXZrjNuiCpNseafMcO17gSTeu00BZQ14fT76S2wqFS3DoK8Tuq3b8eL+k KLnOIehySAakvJ92Fg1afNSSgpDiAyHiEbYjbpZtFA9R3nspZy4tykn0CFNyma707BrK5h ej88m2Yuu09LTcn+A2yAw8y+F/8qNcKI5IHDSGQtkIRGKKkeT4fB9mRDbgjrEw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643576465; a=rsa-sha256; cv=none; b=uLyYbHugRnn/Vf0nyOuBludVXzMd6C1Zk9d7F+U1/CAfOcytFBj26ShgJ2RhmMIXRxzPjQ W7um5e0NDbosMaIHq62cLawFlxyngHu9Qx14jE4ezf2UDUxI46bbRH0cxBmefuOQXmFky9 YXOkzx3jOID7biDxQjjT50oVXKd6SMdy/5rQg1saBzC39/6SdIIWlmnAm/4ouPdVD44AL6 cqbNz/zdtgUJDzFUnotxi7S2VWQV9scB1E01UaUE63kIIzYUGRSDY6oLTQq/IEqqNKGloQ 3p5du8dW7/oM4QfpqGPZlvGq/dWVitBa34dYakMKk3ZneflIPqSgDc8DKYGgRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1795 Lines: 38 --16435764618.2d8E.73407 Date: Sun, 30 Jan 2022 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. --16435764618.2d8E.73407 Date: Sun, 30 Jan 2022 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.
--16435764618.2d8E.73407-- From nobody Mon Jan 31 03:15:49 2022 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 33A441994025 for ; Mon, 31 Jan 2022 03:15:57 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JnCrD0YTNz3jGj; Mon, 31 Jan 2022 03:15:55 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643598956; 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=n6c23ewBm2ke//JvESSAzlzJj/fgyq/XTA1p8B7f/lI=; b=tGFcfKezpLBQ4Y1jxLK6rLCzkwQ0Z5OXVCfeFaPVH+EyKzwLKp0ex4Z6dTYyl5Q+SGrdNF FmUWKbCyvqxI4QduqK01X0MTE8oWXuZfnxrqVZacYYpIvl4Opy7i9iv6frrzkf5l4Kyxvx jsz8IxGLXPMAAqSgRxxGHDUj6BZ2K/AC7ZCfHW9zqWPcZdREk3YqxTreyuvNnN5Rqsli1+ boPmYuu0bGzAaTs86MNHnjdeqFu+dAAHO0P2OS4RLWUsEpHHO8It2GP6yA1P+8tauJ3ubs Nz8N7ow69m9DM+Feoxqtkn+l720L4Y/rpV24/x5iHMhTpHszGkBx0COL9Ct+eg== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A9DA7C9AD; Mon, 31 Jan 2022 03:15:55 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 8D63027C0054; Sun, 30 Jan 2022 22:15:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 30 Jan 2022 22:15:55 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgedtgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkjghfgggtgfesthhqmh dtredttdenucfhrhhomheprfhhihhlihhpucfrrggvphhsuceophhhihhlihhpsehfrhgv vggsshgurdhorhhgqeenucggtffrrghtthgvrhhnpeevledvkeetleektefffeffffegue ffveduheekudduveetgfekheeffeegieffvdenucffohhmrghinhepihhpvheiphhrohig hidrnhgvthdpfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehphhhilhhiphdomhgvshhmthhprghuthhhphgvrhhs ohhnrghlihhthidqudduieeivdeivdegkedqvdefhedukedttdekqdhphhhilhhipheppe hfrhgvvggsshgurdhorhhgsehtrhhouhgslhgvrdhish X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 30 Jan 2022 22:15:53 -0500 (EST) From: Philip Paeps To: Ronald Klop Cc: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team Subject: Re: aarch64 build cluster and linux64.ko Date: Mon, 31 Jan 2022 11:15:49 +0800 X-Mailer: MailMate (1.14r5864) Message-ID: <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> In-Reply-To: <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> References: <1365005114.369.1643120837534@localhost> <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> 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 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643598956; 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=n6c23ewBm2ke//JvESSAzlzJj/fgyq/XTA1p8B7f/lI=; b=o3epk0OUSEUbThZHeNe58o6FeU9ejIgHODe8W4QaaPCgrxuQYUSTfitzahWbA9Tysm7oE9 L4ttImywB/i00BoDeaiccXP4yhe1VpCUsCCP9PDRx7Q5mgNS+iXnFdTG0COwWNBj857kUI 95kurGCNk623h7z+VM6XTrCqoPS8ux0WVAwCw3HUWKpQ40HZyVHpHGEMx2tgUhY+ihw94o iA36sSJOeLCRU+BjnEzTIsB6pbd6ARGp+JtfSGoT/yV9mg14m/DEa0xdrI5nI17j43qU3L yPlLEnE/k0HUJGmZBpn2JFIWtwI10CPxhtgtCat2cIJ+3x751mXYdbd1tsDbxA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643598956; a=rsa-sha256; cv=none; b=P1QnD9QHkMkG+i3km8OwtSK0Xr45LoCxY/HQ7348f78o5mc3/Dxhs30MhIgHam1azYqDYc PM6/TFl+jYlRQ+9czU99BZvLBaE+wD1SakRluQHnvDATPI4Kbv/rbNYlIRd8Qu6ZOmDKOV +cisx2q6gxHu5BSEYmCtrZST4f57YJ5OqHwYfQWUk1Cdva97aOaX7ExszQrhbYY8gzdgGW p6K4AUbQt5SnUSQ/aP0UHoiiSxM8OXQ7PgBcAZli5nr/imkV5VSrANdmtt3JG3if9h2UYB BQjuXSSel8yCFMmD9yhjP9Tt1F3G0Cd8YjoNklMyr1UtIR4NAfTm3mDw8yXajA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1820 Lines: 60 On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: > On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: >> Currently the packages depending on linux_base-c7 can not be = >> pre-build on the package cluster because the kernel does not have = >> linux64.ko loaded. >> >> See: = >> http://www.ipv6proxy.net/go.php?u=3Dhttp%3A%2F%2Fampere2.nyi.freebsd.o= rg%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferror= s%2Flinux-c7-libpng-1.5.13_3.log&b=3D0&f=3Dnorefer >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= phase: run-depends = >> >=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> linux-c7-libpng-1.5.13_3 depends on package: = >> linux_base-c7>=3D7.6.1810_7 - not found >> =3D=3D=3D> Installing existing package = >> /packages/All/linux_base-c7-7.9.2009.pkg >> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... >> Cannot install package: kernel missing 64-bit Linux support >> pkg-static: PRE-INSTALL script failed >> >> >> Is it possible to have linux64.ko loaded on the pkg builders so the = >> aarch64 packages will be more complete? >> >> At least on my rpi4/aarch64 poudriere I could build pkg = >> linux-c7-libpng with linux64.ko loaded. > > We can include linux64.ko in the next cluster build for aarch64. I'll = > try to find time for another cluster refresh. It's been a while since = > the last one. I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with = a build including linux64.ko. The module seems to load. portmgr might = need to do something to the builds to actually use it though. I'll upgrade the other aarch64 package builder when it finishes its = current build. Philip -- = Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Mon Jan 31 14:52:53 2022 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 785DB1993C1B for ; Mon, 31 Jan 2022 14:53:03 +0000 (UTC) (envelope-from SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JnWJZ1K9yz4RfK for ; Mon, 31 Jan 2022 14:53:02 +0000 (UTC) (envelope-from SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl) Date: Mon, 31 Jan 2022 15:52:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1643640773; 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: in-reply-to:in-reply-to:references:references; bh=xiNRc6JFomt4tfCglRK9GF0T8JLMl9ngvFm5fpifaVY=; b=Xy88LtbQANTuJ12MjRL5Vg0fwU027VQhD8vIUOtWuq76eypUA3Urk6pIQHku9F3CTvWlLv SWbDDKQuNpFfMVLCUXXOpiyrgulFV/kHFwHDg90EEpbILARjIRVhnA589+Re/EWD3HyTMz bOnxQoZcN0qjOvdwQd65Yvr3uXeokMdoE27RUrtQEg0zkjApTEMFifo/clcrBKcpTXHfgC 5Ejihc9QqxqZduQaVPi8XDeTd+5qnEbO33tLgQ++Cg6D5970pPtlDaDuCU3umaK4y9XJ8/ Zoac1mX3hcp8DIX2UwmKdf8TNFaadjs4OMP8b5I38FN4qlSJ3QLYC7hvQxoXAw== From: Ronald Klop To: Mike Karels Cc: Stefan Parvu , freebsd-arm Message-ID: <208103706.383.1643640773365@localhost> In-Reply-To: <7C430492-002B-42A5-BD3E-2FA6B6A92D17@karels.net> References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> <7C430492-002B-42A5-BD3E-2FA6B6A92D17@karels.net> Subject: Re: RBPI3 for FreeBSD 12.3 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="----=_Part_382_2061704107.1643640773290" X-Mailer: Realworks (593.5.8d33753) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JnWJZ1K9yz4RfK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=Xy88LtbQ; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.109.157.24:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2904 Lines: 97 ------=_Part_382_2061704107.1643640773290 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =20 Van: Mike Karels Datum: zondag, 30 januari 2022 14:21 Aan: Stefan Parvu CC: freebsd-arm Onderwerp: Re: RBPI3 for FreeBSD 12.3 >=20 >=20 > On 30 Jan 2022, at 1:33, Stefan Parvu wrote: >=20 > >> There was a u-boot change required to boot 12.3 on RPi3, but it didn= =E2=80=99t > >> get checked in before the ports tree was tagged. > > > > I see. Do we expect to have ready images anyway published or we move fw= d to 13.1 ? >=20 > I haven=E2=80=99t heard of modified images being made later. But 13.0 is= available now. >=20 > Mike > > > > Thank you > > Stefan > =20 >=20 >=20 >=20 Hi, Might a snapshot help? It is not a release version, but it is more up-to-da= te than 12.2. https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.3/ NB: Running 13.0 on RPI3 gives freebsd-update support. Which is a very reso= urce friendly way of keeping it up-to-date. My rpi3 runs it. Regards, Ronald. =20 ------=_Part_382_2061704107.1643640773290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

Van: Mike Karels <mike@karels.net>
Datum: zondag, 30 januari 2022 14:21
Aan: Stefan Parvu <sparvu@kronometrix.org>
CC: freebsd-arm <freebsd-arm@freebsd.org>
Onderwerp: Re: RBPI3 for FreeBSD 12.3


On 30 Jan 2022, at 1:33, Stefan Parvu wrote:

>> There was a u-boot change required to boot 12.3 on RPi3, but it di= dn=E2=80=99t
>> get checked in before the ports tree was tagged.
>
> I see. Do we expect to have ready images anyway published or we move f= wd to 13.1 ?

I haven=E2=80=99t heard of modified images being made later.  But 13.0= is available now.

        Mike
>
> Thank you
> Stefan
 


Hi,

Might a snapshot help? It is not a release version, but it is more up-to-da= te than 12.2.
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.3/
NB: Running 13.0 on RPI3 gives freebsd-update support. Which is a very reso= urce friendly way of keeping it up-to-date. My rpi3 runs it.

Regards,
Ronald.
  ------=_Part_382_2061704107.1643640773290-- From nobody Mon Jan 31 18:28:11 2022 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 9ED60198C326 for ; Mon, 31 Jan 2022 18:28:15 +0000 (UTC) (envelope-from SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4Jnc4t2FC8z4s5N for ; Mon, 31 Jan 2022 18:28:14 +0000 (UTC) (envelope-from SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl) Date: Mon, 31 Jan 2022 19:28:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1643653692; 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: in-reply-to:in-reply-to:references:references; bh=7MMuxGIL3anS0zsAfoVnbfaAqqOmNzpORvofD28AcsU=; b=Yg/rBtkT5ntypaVeUwttrp8IasGjVSScunq04aW+S1vjOtMb1im8XP6fVH1/w8x4OjbFP6 1X4HwWLxKuyxEdCyeA4YxabEh+Ou7P8TS2IOQF7H4F2KlTOHP9ukGyhcA0jic6+SRMO3+U xFAVUe808swNsMl00wY7TMqQA1ZGDEzYdPq8xp3FlxCXrLMGlJGikyKv2qJaGz7KANcXGK d8jzraFQU6WjUys+Cs3Gz27hHOCeGaPHz/UCfVVvI3cucN149d/kUNqxuKDvblZG8FDBZ7 VsATxP9ElDl54KeYfocIckqD0USakhVzLiRk1wJvJedX3oULUVmT/W8Te0WfTg== From: Ronald Klop To: Stefan Parvu Cc: Mike Karels , freebsd-arm Message-ID: <2015775661.591.1643653691830@localhost> In-Reply-To: <6ACE9B58-1F80-4F5C-AAD7-529A844D074B@kronometrix.org> References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> <7C430492-002B-42A5-BD3E-2FA6B6A92D17@karels.net> <208103706.383.1643640773365@localhost> <6ACE9B58-1F80-4F5C-AAD7-529A844D074B@kronometrix.org> Subject: Re: RBPI3 for FreeBSD 12.3 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="----=_Part_590_1090091011.1643653691775" X-Mailer: Realworks (593.5.8d33753) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Jnc4t2FC8z4s5N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b="Yg/rBtkT"; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.109.157.24:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=a6zr=SP=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3024 Lines: 77 ------=_Part_590_1090091011.1643653691775 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Stefan Parvu Datum: maandag, 31 januari 2022 18:36 Aan: Ronald Klop CC: Mike Karels , freebsd-arm Onderwerp: Re: RBPI3 for FreeBSD 12.3 > > > Might a snapshot help? It is not a release version, but it is more up-to-date than 12.2. > > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.3/ > > > Thank you. Yep but I think will stick with 13.0. > > > NB: Running 13.0 on RPI3 gives freebsd-update support. Which is a very resource friendly way of keeping it up-to-date. My rpi3 runs it. > > Right. Any ideas when should we expect 13.1 ? > > Thanks, > Stefan > > > Hi, Disclaimer: I'm not involved in the releases of FreeBSD. But every point release of 11.X and 12.X was supported for about a year. So as 13.0 was released in April 2021 I'd expect 13.1 around April 2022. Maybe a little bit earlier, maybe a little bit later. Just out of curiosity. Are there specific features of 13.1 you would like to use? Regards, Ronald. ------=_Part_590_1090091011.1643653691775 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Stefan Parvu <sparvu@kronometrix.org>
Datum: maandag, 31 januari 2022 18:36
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: Mike Karels <mike@karels.net>, freebsd-arm <freebsd-arm@freebsd.org>
Onderwerp: Re: RBPI3 for FreeBSD 12.3

> Might a snapshot help? It is not a release version, but it is more up-to-date than 12.2.
> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.3/


Thank you. Yep but I think will stick with 13.0.

> NB: Running 13.0 on RPI3 gives freebsd-update support. Which is a very resource friendly way of keeping it up-to-date. My rpi3 runs it.

Right. Any ideas when should we expect 13.1 ?

Thanks,
Stefan


Hi,

Disclaimer: I'm not involved in the releases of FreeBSD.
But every point release of 11.X and 12.X was supported for about a year. So as 13.0 was released in April 2021 I'd expect 13.1 around April 2022. Maybe a little bit earlier, maybe a little bit later.
Just out of curiosity. Are there specific features of 13.1 you would like to use?

Regards,
Ronald.
  ------=_Part_590_1090091011.1643653691775-- From nobody Mon Jan 31 18:39:02 2022 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 C24391994526 for ; Mon, 31 Jan 2022 18:39:12 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182]) (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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JncKW52jrz3FF0 for ; Mon, 31 Jan 2022 18:39:11 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from smtpclient.apple (87-95-54-93.bb.dnainternet.fi [87.95.54.93]) (authenticated bits=0) by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 20VId8QT000418 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Jan 2022 18:39:09 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 87-95-54-93.bb.dnainternet.fi [87.95.54.93] claimed to be smtpclient.apple Content-Type: multipart/alternative; boundary="Apple-Mail=_98DC4130-2CB0-438A-BD83-84D201D6C87B" 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 15.0 \(3693.40.0.1.81\)) Subject: Re: RBPI3 for FreeBSD 12.3 From: Stefan Parvu X-Priority: 3 (Normal) In-Reply-To: <2015775661.591.1643653691830@localhost> Date: Mon, 31 Jan 2022 20:39:02 +0200 Cc: freebsd-arm Message-Id: References: <091FE5A0-9304-4780-AC9C-8712742D3D35@kronometrix.org> <0544C75F-7B46-4D80-96EC-E898B2B8DD1D@kronometrix.org> <7C430492-002B-42A5-BD3E-2FA6B6A92D17@karels.net> <208103706.383.1643640773365@localhost> <6ACE9B58-1F80-4F5C-AAD7-529A844D074B@kronometrix.org> <2015775661.591.1643653691830@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JncKW52jrz3FF0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [-1.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_HAM_LONG(-0.22)[-0.220]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.893]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.13)[-0.133]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1995 Lines: 30 --Apple-Mail=_98DC4130-2CB0-438A-BD83-84D201D6C87B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > Right. Any ideas when should we expect 13.1 ? April. thanks. Thats ok. Planning the next update for our own products, the IoT Gateway (ARM = RBPI3) and the data analytics platform.=20 Our products right now are based on 12.1 / 12.2 . We always wait for the = next release after a major update=20 like 12.1 or 13.1 and develop on that.=20 On ARM and RBPI3 for us the most important part right now is to finally = have the wifi built-in support for RBPI3. =20 Stefan= --Apple-Mail=_98DC4130-2CB0-438A-BD83-84D201D6C87B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Right. Any ideas when should we expect 13.1 ?

April. thanks. Thats ok.

Planning the next update for our own products, the IoT Gateway (ARM RBPI3) and the data analytics platform. 
Our products right now are based on 12.1 / 12.2 . We always wait for the next release after a major update 
like 12.1 or 13.1 and develop on that. 

On ARM and RBPI3 for us the most important part right now is to finally have the wifi built-in support for RBPI3.  

Stefan
--Apple-Mail=_98DC4130-2CB0-438A-BD83-84D201D6C87B-- From nobody Tue Feb 1 00:57:37 2022 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 AD3871987B46; Tue, 1 Feb 2022 00:57:47 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JnmkL3y14z4fNB; Tue, 1 Feb 2022 00:57:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1F3E55C012A; Mon, 31 Jan 2022 19:57:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 31 Jan 2022 19:57:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=pUsD90Ob4/bClRK66ab97l5KpxKwwQfoU7Nxle svA5Q=; b=mvnAx48uOPLjpXFdK7L5ACeGJhrHvg5kbXRcBG9cW0lP9GPgdYYGfT Yjv4MqXCOExD3GPZZYc/0fSamABo5CeM/1D+BP/tRdxOxLuR6wP6hCnXC4iO/bBM ptLVkYQ5iGn0TW6P2Ct4k6Ziu4mQHXRn5sJJijQW1O/U3U/RGKtpg/+O04Pm7KVC D0aknGFLuhjExwL30CU3xCIuAmguu/NSKM75AwJSj/N4U+zF/h8ag7sM+blw3k5H UbcmWN3N7+7lG8e/jpWyVVlhMpA5sAcYLp7zyE9ApS6ikZSADQ6my/tHnHvOAyWu Ukk+Sui/41fK4Sq+6rzEp1Q8gUKUBdXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pUsD90Ob4/bClRK66 ab97l5KpxKwwQfoU7NxlesvA5Q=; b=Dg0RFg+9RGYQueToQaTUjOqdqngL4NuN8 OnbDldxVSH63sKyElM7Z/sw/3EJsG/Ym9h9YM1+0D1lgca+c7GMi9gRYZ0LGb8Lb +1I9l6+bmgcRs9y/Xq259qnmWBgVXDmktGy4tn1E1rs4VZWXQsVqthB5jAia1vc9 s1/zE/qRa/oR3GoX8W7djOZqv6cqWsR6aYkZsXuDuO2i6AElAeOQeRNSDRvqfb96 dk8kgcweoRAT5usj3RIYPNF119E9YeTHhIQybL2AOjTu2wQXxLMc5auwt94rQ47W Vq0ImkAFqqmjmBLw+XgTw7y19rBn/X8J9tLpoLKm5vCfg+LC/Jsgg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgedvgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 Jan 2022 19:57:39 -0500 (EST) Date: Tue, 1 Feb 2022 00:57:37 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0HnNK0L8r1/DIyKV" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JnmkL3y14z4fNB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=mvnAx48u; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Dg0RFg+9; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm2]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1936 Lines: 58 --0HnNK0L8r1/DIyKV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 28, 2022 at 02:54:25AM +0000, tech-lists wrote: > On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote: >> >> Will try to play with zfsd disabled, as suggested. > > since reporting the issue and disabling zfsd, the problem > has not re-occurred so far at this time (28th Jan) It's happened again. But with zfsd being disabled, it meant I wasn't detecting the problem except by indirect=20 means. Like "hm why isn't nginx working". The problem is, one of the things that stops first is syslogd.=20 So it's not recorded anywhere. syslogd is loaded with these flags: syslogd_enable=3D"YES" syslogd_flags=3D"-ss" syslogd_oomprotect=3D"YES" context is main-n252544-7406ec4ea99 on a rpi4b/8GB. zfs-on-root. There is no microsd; it boots from usb3. How would I debug this? In the meantime, I'm re-enabling zfsd. thanks, --=20 J. --0HnNK0L8r1/DIyKV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmH4hXYACgkQs8o7QhFz NAWVCQ/+K0IZPz9OduFx6uRM5VAoxDznvhY/5H9e3+vGaiL3Wzc/tlP/+iFyOYTZ xKXcRND9Zckdwc7IeaKgRoBjyO7a4K0DMxVD4BnfZ3Fvh1cOOU0eYQ+a8kDUeCeL LlIsRjAbsRR3qVFN/pifKm2YWbXOgSbSfod3+dDdyf/HWiQfRFIS+BmY2tHy2MiQ pd7kHmZHhvXmk2kOz1Gk2Rk3kAB/Ysf1DrKu1QgiRt87fHoesf/7RyXh1wVVmPFL wUbm2XHJ2E1FbxI2ATAfeol9lB2jDWiU4AAYe+whKTWVaTWOtHXUUiK+arHV4KWu 8cqh2sVZtIQ/voTNrW2G0gjiltpHhZ58+dsKqARRugNA+Ph37ggJ7FAf5rPrRcLd fvUJ8CaJiUtNQyQVnBv+DUJcT2iKJ7tMxek8I7Qw0nw8s92xw7pEFvpuVD5zYPbi 3CNNqvzkOoqv0UfISSuTAASS9A8R+3VcRNKuEqEtbeZC0L/71ANmnEX5O1QS5lk+ wWu0GhExvVfMORyXaIqrd1edoypFL7+PA2oRsEx7XaOnsit0vwL2iuAkVWoXKczn eAJ6vEzNHmCjWRUNEElGHnlFxC5yMMOoO+LPxJW9U5KmMGb9FHRBc6K+D856fMqm YqDv5nYmeDnJ1X1Is2B+3sTgbGrWguS3w4T7y6Y7Gt+b0xCOD+s= =YmK5 -----END PGP SIGNATURE----- --0HnNK0L8r1/DIyKV-- From nobody Tue Feb 1 16:18:08 2022 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 5168419A0F70 for ; Tue, 1 Feb 2022 16:18:18 +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 4Jp98N4qPHz4WCp for ; Tue, 1 Feb 2022 16:18:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 211GI99q074075 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 1 Feb 2022 08:18:09 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 211GI9FS074074; Tue, 1 Feb 2022 08:18:09 -0800 (PST) (envelope-from fbsd) Date: Tue, 1 Feb 2022 08:18:08 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Error detection for microSD-based swap, buildworld failures on pi3 Message-ID: <20220201161808.GA73977@www.zefox.net> References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@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: <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> X-Rspamd-Queue-Id: 4Jp98N4qPHz4WCp X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [1.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.995]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:query timed out]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.08)[0.076]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1484 Lines: 39 [new subject, different emphasis, old problem] On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: > > One thing that could fit the behavior is if small part(s) > of the system c++ compiler (or libraires it uses) were > corrupted on that specific media. In that case, nothing > elsewhere would replicate the failures but a lot might > work without using the corrupted part(s), making the > failures not random. [spaced for emphasis] > Checking on that is part of why > I'd hoped to get a lldb report for a .sh/.cpp pair > leading to failure on your RPi3* in question. > If/when the stable/13 Pi3 finishes its -j1 single-user build/install cycle I'll make a point of trying the .sh/.cpp test under lldb. For most of their operational history both troublesome Pi3 systems have had some of their swap on microSD. If there is no error detection at all for microSD-based storage then undetected corruption of data from swap is a real possibility. I expected that storage errors would be reported but maybe not, especially outside file systems. Mechanical disks have some internal error detection and report explictly when data can't be retrieved. As I think back on it at least one flash device (a USB thumb drive) failed silently, no reported errors but also no-write. That was on a filesystem, so the OS noticed and so did I. Is there any error detection/correction employed by the virtual memory system as it reads and writes mass storage? Thanks for reading! From nobody Tue Feb 1 17:58:38 2022 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 A102619BB021 for ; Tue, 1 Feb 2022 17:58:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpCNT4vkhz3jJc for ; Tue, 1 Feb 2022 17:58:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643738322; bh=h5cctThHFge5aOjX0MWdm3h3SJYsJXlYgmujCm3Q0bU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tmdKCorqyRpD5kyonB3rJq9tcv0bDFwfISV6oJNjJLCC+AlrmlwAfmuj+zdkg709uojp3Bs4mVKUkx1mfRV9EhJH25lAbcEusH5Fgm/2/hNijoVIp3NW0adgYCl5Ng8MKv2XISpufUaN+82wI7QwwIkoBlMNog2VOsDXuk51z34l9HCKRSM+WlvNPVrcbx7bz953Vk8bJeIlFLgLjLZWa0b7q3xSZeSk4mQJEPHf89iLj0lmWW0hDFTya1ShgzrwsgS9xpDHCke5u7YiP4Ek25gcUZyzk0dKLwZDAw+WZSH9Iy0Bub9VCibFQlNUyYGUOe2INI5CFOBSNxtfbWy+Fw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643738322; bh=shZIlDOPBIk8RXIRRRUCNLQN6AJzZHmDG2OVm+OQNBh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fMfh4y0kTG8zRVi4bZ3CJY0OzAjWkUq0Zf6EZx5yXqj33StXa9R8vapQ+r6bVm8zaRIbCiGuvydknigTv1zjxT7SkBMsZg1fNmhunoKxDNJ9+NoI8hwSgWjBt+w/HP0YP41uVolj6lDpkVKl8hgkoifOnRt1QS6Z4Z5rQmFyQlOy5ynM1wxP2lzM78i0pXbgfG16908zrXkrMiQkYRdHcDF5VjLWZnVUCnGGHu1cYeXEEvpZaVE7/t+ojj4qKmtWTOiIJEzKh1gojJ5ro2eqVE2Rliri6QfimXc8yXGejsj6SpPb7zGzydUZt54/q/5zD8Smjxig/oWd3n3JsqDGpQ== X-YMail-OSG: jZawnV0VM1msDq2VE1utG6cxvg7Y1oKJVt4vjqck7aCx94.WobAKXHQhVTPE1Uo 3_P9NbvrByaJL7AL.Xv11WMN0861GNcx7pBqsxYX8tV1UUHEloIq4_NVyTNG3wzfd1hiz6p3vqt4 1YycFuFStxPygJh.gGUeNthtebaM.ZMOvnMGDu.Jez_G6Np7AmuTKdtExsSTnP_WmvKVfLaFESWG aex1eZ13OGO3KBR7lB8SdujsRXWp9eDnK8LqTcGGqCris4EaHJTB0tpC8y1ParnbJ_euuAGHs7BU oHQhFTmKyNBB3bw2mK31mGhHrHfaDCKZuVAhObKfF8daQ4L.TKejV9Cv2hiGJB_oqwH2Hmce.kV8 d4TCHuald056rVn5YNi5.IBa6ODEOtrOxdSaNA9i9br4lFAxJ0ej1AbcPuRbQZ1p74zVWSERT_e9 cdc9QRaIOEMioMvYGWxyDSAoR2QUs_ZiwgWGg.w0JE.XhPQtais.BGelrmugpcu753YXkBchVHU3 iOnVyUfXGhUOwHOeGq0NQo_R67KUJNMc5Gjq1w4c4giQXcsvM1nNmpOdvIBkXuoylQ90oVcHWovL p7pWal1T5Mlz0lAH4soNUy6b6UBQ6stNce69C74uQdkBs9CmSvsMqXGKGjWaUU2P9UvLkW7thitd JugDinyp3ZFJTxMqUne0uJP.wGDJ5gYJY8T.SFFjyETGC7l76FTs6._mVMBJKszCkJA8lVaYUq9c Z.Uy.p3tjQB7m2ds_DjknQu3stH4qMhenhw4fOdTxCLNasJLnuiFYKgzx46iK_uKD1VltqeyoHSr dLAx44UCS4KCUnFm6maRjRoGBg6xv_83IUr5c7mqNmXjkiz4WQwyevr5YaxBbDxBwd0eDMnOvQAP OuVxBoutxL2uJ7d5Dk5wWILE14kbvBP5FtHY7Shz1vdx4PM0HaRoiRS_XNR4uecYqk2ioql7O_Np _NBpWTkL8.ae79jBPitr9ZjlgnDpssj3bgFJxmVE9SSoX5VTp.y1ox___TB5NOylRT5lP4EtVO6w gF9ADcX_I0j4yBGigjqDVi0hXJHoDFWRJ9147B3xnHJuDidw26qsjS35muyeag123XC_OjXFbgdR wfkVV69k8Zql6nnx7KoOY855RTbjWR0se5QROXzNz9vTkov7YXk5Gg.R7pjEqv4yREGAzw0tlFV_ 6lR.GUep9F7Tev.WO5zuSmaKJnYblVPJONqiedud65JoAbDBCo1JQAvtsfzL5c1_xnIXVrQqHDMh REBUtjBEy21S2N67jMPkf32U7K6IVQP8ogo7qw0gY1XqUdbKVjgdzYUFgN_f9cdQx9o8WE2BHIpj Azy13ef7i9GHJ6dvWNSHlCk_DFn2raRuQ3zJZ5aUKHKgdJgEFPl8cJ72rZMvkNz0ezGqRGG5uDy. cpZbsXM3.Fy0g3ulUAs5Gpg9YriCJyaVliHuwbjZRKWqqnJPtrS1Ok0FVghONAvPPKbArmMw_.hJ FBUobXKfyk8_fCCnQvvzwGPlr8iLbZoky54by6t762bXxu0T9bK1dz4VT6uDaGbw2tNlCZPDM2gy 1yq_4zDuYitKNWUBLdHvTw8Evji1HxBFkkMaD_whlan4TY3PvaVgXOEIMRGQCqz.Hw_ipPYpZQwp w.P4dXCAYoMxBkJxfXlCoR50TdMo6lnzPNVLiiFPddVG0xtHI_oQWK334SzmpPdFZ6ECdlYZPz2A ECPx3B3W3_FS6nB92YbN9JS7f0xpS_3aDEJ3S98FchQumS26yhfiFMNic14fZ.hIBNE448hSeA6. G8ol1cF77LbPDL4qUYbMOvJhctt95daUvc0gdo8ZstftPXDSp8KIHbR3KFrWs9rg6jZy7R2rE4Z8 I2L.oGN3xS3Z4bYRgAu0uhZcCt2NyXf51r9nlXVG0lJL_pk0zjF.qjUVIPRTG8HInC8dY0w.UAq0 GjOoJV6M6bg0YB94cU0Qgv6v9Igwgo6K7GEu.O6gBcZvCqyr3RLlxMF0.xdnWKr6U0BV0wk1lY1Q 74Ki3LIx12LwCJl1BgQQAK7QfXle812FvNuuJzknh6jhPwdFVMpn2uQPfltHGB25rEP6Gvp4aoh. hYMwy_iJd6454t6T3iJJYldJzMGD1NPFoPZbP2bmzBjsJgLaFM2cYHI.Q6y2_P_ITXRWdy.VzHqY DjH.rO_9feJ8dbqkyNLlTAtgzvvrxtD6CXMKA.x4Q4QGMGYPOkXxNOLjyjQ3CbcEHVT8XFfF12nN OnMp0t6F0K1XOLU5ZF3Uy78Q5e94YIxiFiovhoNUgiPsFeTJuPE29v7XS8lMyf7LpWsKDqVBjDD2 0Pvz0HW_Eg9U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 1 Feb 2022 17:58:42 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b7e4f4c1c303c428331870815c762a94; Tue, 01 Feb 2022 17:58:39 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 From: Mark Millard In-Reply-To: <20220201161808.GA73977@www.zefox.net> Date: Tue, 1 Feb 2022 09:58:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <304EFD6E-2D92-42F6-AB13-285BE0B15363@yahoo.com> References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpCNT4vkhz3jJc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tmdKCorq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3524 Lines: 98 On 2022-Feb-1, at 08:18, bob prohaska wrote: > [new subject, different emphasis, old problem] >=20 > On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>=20 >> One thing that could fit the behavior is if small part(s) >> of the system c++ compiler (or libraires it uses) were >> corrupted on that specific media. In that case, nothing >> elsewhere would replicate the failures but a lot might >> work without using the corrupted part(s), making the >> failures not random.=20 >=20 > [spaced for emphasis] >=20 >> Checking on that is part of why >> I'd hoped to get a lldb report for a .sh/.cpp pair >> leading to failure on your RPi3* in question. >>=20 >=20 > If/when the stable/13 Pi3 finishes its -j1 single-user > build/install cycle I'll make a point of trying the=20 > .sh/.cpp test under lldb. =20 >=20 > For most of their operational history both troublesome Pi3 > systems have had some of their swap on microSD. If there > is no error detection at all for microSD-based storage > then undetected corruption of data from swap is a real > possibility. Getting a systematic error (SEGV) at a specific point in a compile across many attempts with various prior histories, reboots, etc. involved is not likely to be from somehow hitting the same bad page in the swap space each time. This variety has varying -jN figures, which can lead to variations in which compile get an error first. But when it is a specific file that gets the failure, the detail seems repeatable. This is true of the .sh/.cpp pairs that fail reliably for you as well --especially given that they work for me, even without swap enabled: the 1 GiBytes of RAM is enough. (Swap required for running under lldb.) If the problem is a corruption, it would most likely be in some file in use by the compiler (possibly its own file): a file in the UFS file system. > I expected that storage errors would be > reported but maybe not, especially outside file systems. =20 Not likely to be a swap space issue. > Mechanical disks have some internal error detection and > report explictly when data can't be retrieved. As I think > back on it at least one flash device (a USB thumb drive) > failed silently, no reported errors but also no-write. > That was on a filesystem, so the OS noticed and so did I. Storage media can not generally detect if the data being written is already corrupt before it is written. > Is there any error detection/correction employed by the > virtual memory system as it reads and writes mass storage?=20 >=20 No separate one that I know of. But getting a systematic error at a systematic point across a wide variety of histories is not likely to be a swap I/O problem. If I understand correctly, the normal recommendation is to avoid using microsd card for a heavily used swap space, reliability over time being an issue. (But I'm no expert.) For reference, as I understand the following is a repeatable part of the failure notice for compiling contrib/googletest/googletest/src/gtest-all.cc : 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:806:37: current parser token '{' 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' But we know that when I make a copy of the .cpp/.sh pair and execute the .sh the compile works fine. This is evidence against the source code being compiled being corrupt. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 2 00:47:48 2022 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 F407F198FD79 for ; Wed, 2 Feb 2022 00:48:02 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 4JpNSf0LZsz57lS for ; Wed, 2 Feb 2022 00:48:02 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id j10so16932303pgc.6 for ; Tue, 01 Feb 2022 16:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=31rx4jxUw5W70eBWo0o/65WfgnoK/AqkD+qJz/agU54=; b=CnerIUw7EkpLdPqNuGlODYBOh8BQQ/Vb5JO9Yo+vifdxmkIAWJdPPY/6w9ll+RFKTC SSPUJ+ZpG9cLA0KHWzCj/TN7dUpfu7UJWw3r3z5faxd+reKRtBX5NtziWwv35GHB6iP8 vnXbbb0oRlyATTMtEdPBZqWqX21xLwp4WDzKKtI/C4et5nZ/CVkJclWQlp8PeoR4ahc8 0xYOKI3Ludu4Cx2800ncOzu7Jlwn3txLqOw074svYQz8sB0jJELCZlm9HExrATpVwi/R DCmInVRT45ugLFVAWdXF7WsY02F7S0D8wBOSlLVseEvbV3nv7uyI2yTnmE+37zlDf3Gr lh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=31rx4jxUw5W70eBWo0o/65WfgnoK/AqkD+qJz/agU54=; b=2yflmJsECxdAmC2CcHKMXfE8wQhBoGrzUnCu/SEehd7XREtgNZRGh2dKmEAFFrpvJx t9cBqjCHX3f/KhGLX6L5oa+zl7VUYBmr+rl2iLug71KQ942YXneC+zL5PCnb+37rw3R8 HtOBq7tx4ZOcbGBK3BrXeIVxGv/+Tba28GYqLhinBKxnNmV6AgwKGhn3NShX2K8LEKSc IsNLjJoUv5A+j7XDazyz+uYLammwk4J2Gw052ELAZFvKkxdwoR1JHaiAALcNTUQEEIWm HSQqHvNNm4+qbatcU6reHCGyASAy2aM+30RJk9e8U5T0eAm0JdKlWrgwho3rlEgSyV29 KkFQ== X-Gm-Message-State: AOAM532av7mYkIkRRTnTmCh8sHV1HXke81LXsxxkjHyspu78HbmMY1Ef t8OrHme/XOwB8b5lIH6mnsu/2sp3ZRpD5w== X-Google-Smtp-Source: ABdhPJwgScSJlhgFdkPd38h8+fgD7AoiEbyP1jIs5piZxTyS5n4Ubbjv2p2ouFqwiXqGS876V30ykw== X-Received: by 2002:a63:e818:: with SMTP id s24mr22676063pgh.21.1643762874716; Tue, 01 Feb 2022 16:47:54 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id ck21sm3723632pjb.51.2022.02.01.16.47.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 16:47:54 -0800 (PST) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 To: freebsd-arm@freebsd.org References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> From: MJ Message-ID: <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> Date: Wed, 2 Feb 2022 11:47:48 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: <20220201161808.GA73977@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpNSf0LZsz57lS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CnerIUw7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2131 Lines: 60 On 2/02/2022 3:18 am, bob prohaska wrote: > [new subject, different emphasis, old problem] > > On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >> >> One thing that could fit the behavior is if small part(s) >> of the system c++ compiler (or libraires it uses) were >> corrupted on that specific media. In that case, nothing >> elsewhere would replicate the failures but a lot might >> work without using the corrupted part(s), making the >> failures not random. > > [spaced for emphasis] > >> Checking on that is part of why >> I'd hoped to get a lldb report for a .sh/.cpp pair >> leading to failure on your RPi3* in question. >> > > If/when the stable/13 Pi3 finishes its -j1 single-user > build/install cycle I'll make a point of trying the > .sh/.cpp test under lldb. > > For most of their operational history both troublesome Pi3 > systems have had some of their swap on microSD. If there > is no error detection at all for microSD-based storage Is this true? I would have thought it used some form of error detection in the firmware or in the controller. > then undetected corruption of data from swap is a real > possibility. I expected that storage errors would be > reported but maybe not, especially outside file systems. If indeed your suppositions are correct, would a file for swap be more prudent as it has to go through the file system (UFS/VFS) to read/write to swap? > > Mechanical disks have some internal error detection and > report explictly when data can't be retrieved. As I think > back on it at least one flash device (a USB thumb drive) > failed silently, no reported errors but also no-write. > That was on a filesystem, so the OS noticed and so did I. But this could "simply" be because one of the NAND blocks has failed, not that it could not detect an error. Is there a lack of error detection in the driver handling USB thumb drives and reported back to the kernel? I do not know. > > Is there any error detection/correction employed by the > virtual memory system as it reads and writes mass storage? You would think there should be. > > Thanks for reading! > > MJ From nobody Wed Feb 2 01:25:33 2022 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 23F1119B58E9 for ; Wed, 2 Feb 2022 01:25:46 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpPJ84hXlz3PYV for ; Wed, 2 Feb 2022 01:25:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643765136; bh=sbQdHWX72+RR/x0pM/PGXuvQva5aU25JTYb2A4c2ND0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i/X3zcTkOnSNmHjFu0QEBaDOFL5HMIUsUXadYjhGog4fONcTFcaNA/uUQrB4fWHhQnoN2cRthAbRShKCw3ug6bkuMvZhXEBZnFLaOybAFeiSF3cNGcLcKQXNaCMDvAJHvaaw4PhmkCf+JnMV+0MgVeeV478L3C/Lwl7Oc1UBXVbxazkGDMXYFV+whpEDeEndPvS6seBx/YV+3J8yy0/njJHz76bD/mZ98zaE2ybRehL4tnTLOt9SYXzLkoyJCkECTtz2o6yAxPUSOUQUtz0/RsCPFSl9VknwSTqGoSYe7AZurqIIiEE9Z/+oIpXLuujwgt4GKeyhqp9WXrn4sEp6wA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643765136; bh=yW0c9OrVIKEECMf2bhlJvOb46LobUFj2kHo3T+k4AuQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=o7ne0cS+jN/1CcBOjbyE/Rz2D6cxkDpsLSkVmY0lQWMscPXM7wuuur1PxYc9auTYFqyR93pDVSD0Kof/nTuNumuZKO7USStw3ul6TaoGphQevdrx7/BuQNRHQi7hHsIpkAE+q/ow5PZbcQvzoR2lVbMICEy0Hn7fHAG2iQqnH37WEdqG0CgTyRHdw73qi/f04+2KREztYBqRYM0B0Cvl05SrgQlpRG9WovvKeZnc64nPvf4JfG1znIkWG6KyDUDm6tJPoKf1dQARmTXsc4nHWRdo2sVrTwNLCuj7Bwp9DdCuvubk1lyo6ymLFMUmE9WRl1K5ordeI2IHXcr43/5QdA== X-YMail-OSG: doFJjBYVM1mwaod8DqslsAgi8M0bokJSCmODwv0C2UZlGpqVMb2L9ZRuysMhrLx PLC5Nrfv_aBcQTc3N3iWIFCqCMPnNQOEpWwVTerjyGFoQYoBm743ZVLUq5wQiN3ixdPJc1rR3fzA UHsTHLGBKHQXEd1gKo6w612r5OpXZU22Elip1apCjXr9P5qbBLctm3QMMPqNvVecQDyRayxMyRWI HLKm4dfxKL.cu6ANg0PM2ArInJfhlcLMZep1X7JD3qdR_NFH5IUU1ni6iUBTmmy4vjg5o10oJdq7 Xq7yiHr3l9CNlcKFfxe5x_CWC6P96wef4njZxC296Nc_tDYccuuu96fAc4Ox9ONKcJyXMXwk5RzR y0TMeaOwqoKkI3cV27neLQRcMUEVYsLk2WIf8U1Qnnu4F4uQbK6faHYjJNwiARy8juBjVy7blE5X 0g1qbu8fZ5tdc1jwLS_Eti96pfzsC0slxkA3.Hv7NZJwUKNjmZMXKf9AbuKGFfyPb0cI4ykwXNee 0A1YqsYm65yo8ZIL58Tn.kobE5ksvkrHYjdvmj62H3l0fNnJ31CR9OOyzWKSxrSDsW6y84fWfCy_ rgcHqEyano9qaaCMb._td1NlJD7Nvcb56lIv22igCht890Es5DWdmtyVFlnXg_KP_movug_.TgzV .pH.P4gPW1C0Yk303JA_czqYfMyhTAke1EdSagJZlXblRofu7kRT8RKXoW0Q8PsUnc6uWgFacoE3 AL2MQGn1UbHky5K1iCvMwlNDxHWhHxbcRFR3ffpy3tL5NQliG5lQ8OODlHT6a5WTLWpEClAYjH9S 2DMDcQd4.cI5tHxSzA0relH74wxrkzeDH_i9.qU2BaKpNc8jOwWgq0tzm7vwcML1_ZZDxD7ctgWO 0Liiotnqd3e8X3GmCFTk_MRShU1l8AxcdUt_2KXd3sUVcAIPdhCpZ5oOLxjM0_jhTfGDMtrcws8t 0AmafdoGtxf.to3ibDjC721osDqHbimNbvCtF3cFjidw.qV1KcWuVZYOmKQxkAHxFoOw1qsMla81 GGBf0E1OwBOIPCDFLP.Z4Zrnhunhw6OLEa3cbbLOY0wNiOZ7K_e51i5Y5cNqf6_w4pLKu6tKOSDC q8Vbg7Yg81YC4QvR7WTfQie6b9RlvxcHISAPoXreiUUHkyFaJwnsZDWEjC_xqbn2e2oWPI0YFaME GlyGQAWcZd480lY2Oak5ySOo10dSQl8dhpD550DRBlDBkeyaFFhCinbkVhuZrUh3TpFnnmLBYwhY od5ORC.Z6FUUU1nvEla3GmD93kV.vRag9BOBfRjjjD.d7foTopazgdHXLeIJ7RGpjv1YIuvBdkVN 9grW8ksmrNdznLSolVzFWJJJH3OAxUb7WQgcjfkW4Za_NOUqhF6mPQ3Cy.e8lQHXGPiwBU_GPjE4 wgZBVC2vlxYyXOew2pm.SymK336gsQBrlweaVcCkN_gQjh1e3.0zhyqvP4sQYUqhkkSqcIrn0yK8 XXzNFEHqwFAdust35PX9ssal__5M.l577gYX90JGVmFvndcI7NINLPztYbr498.dfLXGfE7wlZzs n9kfT.tpJq5kSRyAMuzE9hOBD3BzKvyHjadbdfxB7q2Zl0hNLs5U9rk.wjkLPhclJwFNa4nullbn yKXHyLL4cdh6El5gzB9j6JzPCQJKfMSwJVdnx4apYjqya5DI31cAPysBWP2yTX4QZ9Ah1Z1jbisM O3Z7cgT_LzgotMYR3AOrTxyN4t1mGeM_aQ2PGrzyj5TZFulAE9L3kt7R9WuRE.cs.uGKZBmXVuu4 PSTbBsBwgaXJXpdDXk3kolq1vil5VuyQhsa5EFu44W_0YvWgZGmVKAEiiChcFVIBjlvl3h.iEka. UYzz6sAq2RPSlgRQwpGjkYH35XDKT8gN.enxS4SYX2R6tkulZbK28XxtL4SNYSFmcm6FzWQY5jU0 JvxEXyqZWlZOb9v5apIeZ99_MwYC5cOlXgafK0L1u2cPSL33exMDtHAgJLjg9XYblVILAwDJxYd4 UiCv8sJEOB.VU07xgD8Eo0li8ntjiLBHJGLaQZGbvycoCgexONgX7Q8TNykI7g9TMgswF7mH5nRJ 1QF.G7WodcNIt4zo4iIU4xDM_zM8V.XSfIQWDvhssKhn9jpU_VuEBGoq23Qof3hIWjrse_kG_Pen KmOXM3bYk8IwXKOeKpwoZrjn2QQrCtOaMOzfCNUXSZxzAg6i8bJ6j0a8bZTic0q.mgYkYqhT2QlG GhbhMRh9qAXEh1hvZiVI6IXz.cY87Xkgtm54z3W40oAwoBl59ypOGA192fSXHH.UFq2adB7r3d0y JsvPFlO7Q9gCL X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Feb 2022 01:25:36 +0000 Received: by kubenode502.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ac14ce952261fb7ef9399afbc7281a14; Wed, 02 Feb 2022 01:25:35 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 From: Mark Millard In-Reply-To: <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> Date: Tue, 1 Feb 2022 17:25:33 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> To: MJ X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpPJ84hXlz3PYV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="i/X3zcTk"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3227 Lines: 83 On 2022-Feb-1, at 16:47, MJ wrote: > On 2/02/2022 3:18 am, bob prohaska wrote: >> [new subject, different emphasis, old problem] >> On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>>=20 >>> One thing that could fit the behavior is if small part(s) >>> of the system c++ compiler (or libraires it uses) were >>> corrupted on that specific media. In that case, nothing >>> elsewhere would replicate the failures but a lot might >>> work without using the corrupted part(s), making the >>> failures not random. >> [spaced for emphasis] >>> Checking on that is part of why >>> I'd hoped to get a lldb report for a .sh/.cpp pair >>> leading to failure on your RPi3* in question. >>>=20 >> If/when the stable/13 Pi3 finishes its -j1 single-user >> build/install cycle I'll make a point of trying the >> .sh/.cpp test under lldb. >> For most of their operational history both troublesome Pi3 >> systems have had some of their swap on microSD. If there >> is no error detection at all for microSD-based storage >=20 > Is this true? I would have thought it used some form of error = detection in the firmware or in > the controller. The type of error and stage at which the error occurs matters. The firmware can not cover all issues that lead to corrupted content on media. >> then undetected corruption of data from swap is a real >> possibility. I expected that storage errors would be >> reported but maybe not, especially outside file systems. >=20 > If indeed your suppositions are correct, would a file for swap be more = prudent as it has to > go through the file system (UFS/VFS) to read/write to swap? No. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 and its comments #7 and #8. >> Mechanical disks have some internal error detection and >> report explictly when data can't be retrieved. As I think >> back on it at least one flash device (a USB thumb drive) >> failed silently, no reported errors but also no-write. >> That was on a filesystem, so the OS noticed and so did I. >=20 > But this could "simply" be because one of the NAND blocks has failed, = not that it could not > detect an error. Is there a lack of error detection in the driver = handling USB thumb drives and reported back to the kernel? I do not = know. Bob's context is reproducible at the same places in compiling the same files across buildworld with varing -jN figures, prior history since boot, use of the .sh/.cpp files that the compiler saves, and across reboots. Such is unlikely for hitting the same problem page(s) in the swap space each way things are run. >> Is there any error detection/correction employed by the >> virtual memory system as it reads and writes mass storage? >=20 > You would think there should be. Any corruption on media would more likely be in the compiler's file(s) for Bob's context. (Source code that fails to compile in Bob's specific RPi3* context compile fine when copied to other machines.) If there is such a corruption (unknown), the memory content to be written might have already been corrupt before it was queued to be written out. At this point we do not know if there is any corruption involved. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 2 02:52:10 2022 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 DFE3719A4290 for ; Wed, 2 Feb 2022 02:52:24 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 4JpRD76Yw6z4h7s for ; Wed, 2 Feb 2022 02:52:23 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x1033.google.com with SMTP id o64so18987316pjo.2 for ; Tue, 01 Feb 2022 18:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AYRcSmvBO32GDjiIzIRpmw04mzYSpQeRA4kvs45d5Io=; b=C1452iDQSIkcktnKUNBh8wtHAsQY7YkTzSRqnhCCvP2IgCxKl8KTBZi047GvrOejxj eF4QlOhhwgUYBk77zjTMmqSyt2oPPmaP5ASQPjfprDcoMTCrzNG/XukzuHUIpAKQvle4 yWjAih+GYk/gqvdWf5KedtkJPagOp/KYdth4eI/vIIC29CXX1JLHwf7ingIDV8ijVV3r JwlEu8Gq68Cbi6BZJdkOB1+Dv7gdMJvAdsZHQR9n1+yZk8xFlNOQMTxwz5ld37P1g6FO l99FnT+eue6nIEj2VoD+JgAHgiLEW+RXcMdWm17FQIZOdjvzRanODikQYLfMKQ1SvYSy jn/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AYRcSmvBO32GDjiIzIRpmw04mzYSpQeRA4kvs45d5Io=; b=5aCKcMzaiz0419gNuDJPqpQ3OsrnWUXujAmmXGxjH3879WT3DPsUzEC3LsEMYUKG+K 3Xo7PCqANYdGqBlmInuL1RmOhjnT2A8DDu41IiJGTscpVkM0FyASfYjsXDQjfaMrzVPV 2LKWxqAvWPeLb9GdtuCiu3VIH9psr3ZN5GtmXyrqnNPVe000zN1/CF6wE42+TwIBhArX cCGkPYlGJz0+F+14mXOb8T9wLrAYh3ekhcYJ4hHs6jypEDZ90+v+VQNQIqAzrRGLcXXT GpJ2K70HepqvEXL3xX9DfHejZjUee2Ff+yVQfwCuqSNFHfPxmYskh1DvyjK9+dFDk1/Q vErQ== X-Gm-Message-State: AOAM532oJX36UBpQxnmbYrNbDlCSQeqoqDlEKx2ZKKm6KgJhUbvQSI+O yOj8XlsrgmklDbZ+2SSLKFEFhgtRgfbbzQ== X-Google-Smtp-Source: ABdhPJz1fd+rgBz05DZKQE3pivt25upypAC/AwsHWB6ZuN7N6A/u7EaEGyD0HE1bmcaZYevmQNvr2w== X-Received: by 2002:a17:902:da87:: with SMTP id j7mr27870185plx.57.1643770336371; Tue, 01 Feb 2022 18:52:16 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id x17sm21756842pfu.135.2022.02.01.18.52.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 18:52:15 -0800 (PST) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 To: "freebsd-arm@freebsd.org" References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> From: MJ Message-ID: <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> Date: Wed, 2 Feb 2022 13:52:10 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpRD76Yw6z4h7s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=C1452iDQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3503 Lines: 76 On 2/02/2022 12:25 pm, Mark Millard wrote: > On 2022-Feb-1, at 16:47, MJ wrote: > >> On 2/02/2022 3:18 am, bob prohaska wrote: >>> [new subject, different emphasis, old problem] >>> On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>>> >>>> One thing that could fit the behavior is if small part(s) >>>> of the system c++ compiler (or libraires it uses) were >>>> corrupted on that specific media. In that case, nothing >>>> elsewhere would replicate the failures but a lot might >>>> work without using the corrupted part(s), making the >>>> failures not random. >>> [spaced for emphasis] >>>> Checking on that is part of why >>>> I'd hoped to get a lldb report for a .sh/.cpp pair >>>> leading to failure on your RPi3* in question. >>>> >>> If/when the stable/13 Pi3 finishes its -j1 single-user >>> build/install cycle I'll make a point of trying the >>> .sh/.cpp test under lldb. >>> For most of their operational history both troublesome Pi3 >>> systems have had some of their swap on microSD. If there >>> is no error detection at all for microSD-based storage >> >> Is this true? I would have thought it used some form of error detection in the firmware or in >> the controller. > > The type of error and stage at which the error occurs matters. > The firmware can not cover all issues that lead to corrupted > content on media. I did not state it covers all corruption. However, I would be totally surprised if the controller in ALL SD cards does not do error checking, whether ECC or even BCH. That remains my point. > >>> then undetected corruption of data from swap is a real >>> possibility. I expected that storage errors would be >>> reported but maybe not, especially outside file systems. >> >> If indeed your suppositions are correct, would a file for swap be more prudent as it has to >> go through the file system (UFS/VFS) to read/write to swap? > > No. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 and > its comments #7 and #8. > This seems to address potential memory over-use because of a swapfile, not the safety of it over a swap partition. I still contend the UFS file system has better protection against corruption than a raw partition labelled swap. If Bob's requirement is a "safer" swap, then a file would be the answer. Whether there are other issues to contend with are likely out of context in this particular discussion. >>> Mechanical disks have some internal error detection and >>> report explictly when data can't be retrieved. As I think >>> back on it at least one flash device (a USB thumb drive) >>> failed silently, no reported errors but also no-write. >>> That was on a filesystem, so the OS noticed and so did I. >> >> But this could "simply" be because one of the NAND blocks has failed, not that it could not >> detect an error. Is there a lack of error detection in the driver handling USB thumb drives and reported back to the kernel? I do not know. > > Bob's context is reproducible at the same places in No, he was talking about a "failed silently" event and this is what I was replying to. I am not up-to-date with the previous discussion on the failure of llvm/clang. > > Such is unlikely for hitting the same problem page(s) > in the swap space each way things are run. I couldn't agree more. The chances would seem remote, unless that partition is on a part of the SD card/USB drive that is failing and the USB driver is not detecting these as reported by the controller. MJ From nobody Wed Feb 2 04:10:35 2022 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 C9BD619B26CE for ; Wed, 2 Feb 2022 04:10:51 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpSyf75TMz3jnh for ; Wed, 2 Feb 2022 04:10:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643775043; bh=sMgAG9FHVqZPQqWmlzNZEfKu3wpEtJ0I7hs+O6/F17g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WWychSpR9uYwWEnq6qXQLIK0VqO6qTaKtlLLbETspCo7OkAkLj9LR6VGs2JUL2JkcimEpd2BS+H1b3UsQB6ZQVu87ZtqBGjnUZhfzyckwFUrqJGiLftHSG3DgNxRyMR5CU+l2PfNWhYMfi40Lv4jjTpIWIyRuBWmuaJyeGXt7JxWOIZxS9c30wWXxp6803YZ8jZep8PyT8S3ulkSC/k1rUkC+mZ1YQkjkRhUhY45/aB4q9gcPgCgYgBBqsEZdnl1WfDxc8mmOe4HgXY8tAAAt/DbveOtfuF+lfYhHK+Nf7SHuanxVhYIuhE7WjDGvipAczpW3x1U4CFxybpUber7Wg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643775043; bh=Vr1uZiRWq0dAgm1R/jIbiR5UG4BgXVvXroJcY1q2IoV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lujaedzziWlvlvZXkz8UuVgVKMO+wMEBUTCasESTqyhA5BRxL9/y9UUzO0Kr1+g+WL+8BdpyN28SI28K/oX5+hVRk0kvqh1qmoPo2LLJPvYY7uv5Q3JT2F5rmKnROIH1HCYs3GQ6ha8ib56xA1Dy7rftdYbtbB++vIrxjXe+cs7r58vLIZLbG7xU87VyPSV+bhUOtm6lDXfAyuch4sJnTaGKWZJ6+BgJLnjPw7g1ABykxs5WeE6keo1KNiZhDt6cHGNiT2WqAkvzfgfyOp0ZtqZ3asVV+utzjzY3wDdhHFKyb+XtAvP6t6u+kRKD4ci+OnCCkHpjJ+PnilpZ80C/+A== X-YMail-OSG: hLWhpM0VM1m5XZpwnZb3MFvx5ryPc672E6AQTD8zQlWNs1ywrt2sac4xJeVxEbU N0uhwq4krXyYLcf93.m7hcy8MhFRnyj4OyP4fMU4iVCdaqawnrIYjl78IwOsVgu_wb9Jb0TeSs4y iPXdQ5dr24w7wiVWSeSMvKbMMF2mkne4axP5Wo1peEp.cXhaY7ALaoPlxmTg1S7z0Nf8j.015C8U bHA6Z8Tc3M.2uxP56MYJ1Oyj6KblCwRvaQx_isx70nQCRGg5OHmlk6nscIP5WjridFJBIHo._AZp WFPdGEyZd0dVADXGwoC7KztVkrVuPhmBHs3vShoeLWTZ1DSMx9CPnogErX2HjmUwFjovYtFRYSmM UtFSo4Vs_sSf.LKYc_vJTtw1Ris9gvZjz5aE38ebM7hIW3HvgytAv8L7j6Kyn5ufNlSVt_V6e6Ey sNUwOZ3nls10XqXYrm4ixij4rvS8YPYzkWWbAbMIYXmZie4y5JsY5LFb6ZaKHz8HC.eg4lk10Ux1 25Ax4j8kG8WEyO1JUhBrWLO3.z34q2IeLe3uItK53clR1osMRwJskOn81.jky4zfblK2zPYzv_L5 Zp3KvAncxi6pjmEE38ub4qX1BrwAgESDzw2rRzel0CqYzAKdgSk3t5ZG312Hij.na0xh7ysixgpZ 3E4NyNw2Yt3PY4j.rzMlX_KSTrD4NA2VwI4dgSQBcc53sHBiSZLIirTOIyJ038ty4NSq02yL9zex GpPfvb._X.KByCjx.zmoqss.F7Zutv67b_bc1wUcB7hVQ9Nw6Ad1T38yBXo9h78PT_vMBKyMBxp5 9qWlAhvLMCHaRutDnfK7G7KxgJrusAKRhf9LwgXOwE7RQmjc2lOkeOJVkQDcHa35xY0EvD82eiRA VVjP1sMP6KJFp8ofz3kyO0KuvsZ4Os.Pt8ouMZViVFntSiN7oAlS_Qdn4a14gRq0x9AHj_pM4uYA LDDevAVk0AfAv0aAt5OtUQeiYsoJgUTQmrue7UNqvtu_f8r9NW6Zj4zKyMDlDyMNCdfjhOTg5cCv nujiGRjTzl8QcBECm8uPPko6cQ2fnCYPHmDr.Ml1pb9ajEFJq7iRo1cj76KGxxE6UF3zpjaNll4T suLCqrS7.NCLhO7jJQ7rczkXvzfB.Fqr2nKws.XMJWePC_yuAfNI89bFnLBE1MAWohhaBybdU_xP gnCtelTDtgQf1qvkzU8GOwsOiTV_vI6ym68egPn7BpwhsvpjEla.V2_Q402PEJLYBA7zVrHU.FpG QSCX6Qgim960pTsX3uLgojEnQ_yAPRfZEpb_7iP8hmvvBhUrk.niBu3zYRDCXMc2bn5XkvjmQPA3 g3IdxqxPiZg3J0AbgGVMXIi1gNQg_wAxrrMeeoa3ZizVUKkhw.Z0G9hYCpVABvE4rvBF0752Y8aB yBmQrM.yM9lmUbMaFaKLMIBZSU5wIXOcVt1QosU9v4aPVSBGfYSZ6eCaJsWKWAYesGMWd9945_2H zOZmclDA7KbTmgbTeyTOIWAmaTh9zTPkDA4xNzpQE00KXWU_mKuexc8ohwjjH1ccJQs3egmWkYlt u7ZsdgUHE.Y8Hfv6sxbd8xa1.9VPif4Kr6c5wwxhpwMTK74Zr8Io7TwxsveP0Er9QtQAzQUgiPZ0 oNwzFDkpz8_cVDslQ.cKLV05eKwuwfmP4cKFhFtkuFZ8mdHWfuyY_.aCtXDJX_yXQhE0uzfVDacc eXV9chbr7QFqJ5Emr6EuX7p9O8aA5eF7TqGhEFNZ2z7jbvcmwTekjoaqB4lunqP9l9FlStGwwH14 Q_4WLC9g5zw_5bFW1RqA0lhRtDqXQy3Np2Dt8d7wwJREmpLeyVupvKU45_k9XHKd9Bg98xtFa.Sy QsbW84oKKbRfo3n7y3U0itFr5ACNBr72pd2EOzc6ct80kbEIaZbZz6z3NjHVEb1oUZqIuoAFAg6A q_vUhBltMbXJfjhUiFVIIMRln_T3cm1Ni6IcLZ4KbKthcFNxbXM1K05LWSt_Ktq8p4wyWdzMbQXQ .TLx1oZPC40fJAApLbQRPHDZ2waHCUm4ksVd92tvwpcr0g0N85v.aYAjt0mK7_eoAKiJhHEM8kG. Yc1uLjh_6nPU7NKhf3isS5Vo9hVIlW69dKnNgcbQ1C3ysFO1Bs7NGLiew1cHGZonQ5QACHgR0o2f 8uCmJ0EBNMlucLqAhptNylmk7VlpPLN7qz1_g.rPQgnH5vtN7_QsXNI_B0cbtT.ySRHf0v4.TxC8 K1VCTeha9cSe3N7wUhBBD3whTJXD.B7bJkvb0zDu2ksPTj36ZduxcLxYCWBir26qa9CnCjc4mtSB kMv9bez54eA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Feb 2022 04:10:43 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cdc74e4583088d1172f905d65300b943; Wed, 02 Feb 2022 04:10:37 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 From: Mark Millard In-Reply-To: <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> Date: Tue, 1 Feb 2022 20:10:35 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> To: MJ X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpSyf75TMz3jnh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WWychSpR; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; INTRODUCTION(2.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6128 Lines: 155 On 2022-Feb-1, at 18:52, MJ wrote: > On 2/02/2022 12:25 pm, Mark Millard wrote: >> On 2022-Feb-1, at 16:47, MJ wrote: >>> On 2/02/2022 3:18 am, bob prohaska wrote: >>>> [new subject, different emphasis, old problem] >>>> On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>>>>=20 >>>>> One thing that could fit the behavior is if small part(s) >>>>> of the system c++ compiler (or libraires it uses) were >>>>> corrupted on that specific media. In that case, nothing >>>>> elsewhere would replicate the failures but a lot might >>>>> work without using the corrupted part(s), making the >>>>> failures not random. >>>> [spaced for emphasis] >>>>> Checking on that is part of why >>>>> I'd hoped to get a lldb report for a .sh/.cpp pair >>>>> leading to failure on your RPi3* in question. >>>>>=20 >>>> If/when the stable/13 Pi3 finishes its -j1 single-user >>>> build/install cycle I'll make a point of trying the >>>> .sh/.cpp test under lldb. >>>> For most of their operational history both troublesome Pi3 >>>> systems have had some of their swap on microSD. If there >>>> is no error detection at all for microSD-based storage >>>=20 >>> Is this true? I would have thought it used some form of error = detection in the firmware or in >>> the controller. >> The type of error and stage at which the error occurs matters. >> The firmware can not cover all issues that lead to corrupted >> content on media. >=20 > I did not state it covers all corruption. However, I would be totally = surprised if the controller in > ALL SD cards does not do error checking, whether ECC or even BCH. That = remains my point. I've a lot more context on Bob's problem and was mostly giving more context than he supplied. (My name is on the most nested text that he sent. I've been working with him for a while on this.) The corrupted-data hypothesis is a potential explanation for the compiler "139" (SEGV) failures on the RPi3* configuration in question for a few specific files being compiled during buildworld. But we have no specific evidence of a corruption at any specific place at this point. We have no specific evidence of a media-error type of corruption either. The symptoms make it unlikely that the swap partition pages are involved, block(s) in the compiler's file(s) would be more likely. But, again, no specific evidence identifying any specific block on the media. >>>> then undetected corruption of data from swap is a real >>>> possibility. I expected that storage errors would be >>>> reported but maybe not, especially outside file systems. >>>=20 >>> If indeed your suppositions are correct, would a file for swap be = more prudent as it has to >>> go through the file system (UFS/VFS) to read/write to swap? >> No. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 = and >> its comments #7 and #8. >=20 > This seems to address potential memory over-use because of a swapfile, = not the safety of it over a > swap partition. The problem is system deadlocks and such. A deadlock and having to cut power and reapply power is a file system safety issue. > I still contend the UFS file system has better protection against = corruption than > a raw partition labelled swap. Not when the likely result is system deadlocks. I speak from experience with trying the file system (v-node) based page files. > If Bob's requirement is a "safer" swap, then a file would be the = answer. My experience with the deadlocks and their consequences indicate otherwise. That is why I added comments #7 and #8 to that bugzilla submittal. > Whether there are other issues to contend with are likely out of = context in this particular discussion. The deadlock consequences I suffered would most definitely matter: starting over from scratch from something that could not readily be recovered after the deadlock. The deadlocks violate what guarantees file system update coherency. (UFS for me back then and for Bob now.) buildworld and the like tend to have a lot of pending I/O around and a deadlock during this has not gone well in my experience. >>>> Mechanical disks have some internal error detection and >>>> report explictly when data can't be retrieved. As I think >>>> back on it at least one flash device (a USB thumb drive) >>>> failed silently, no reported errors but also no-write. >>>> That was on a filesystem, so the OS noticed and so did I. >>>=20 >>> But this could "simply" be because one of the NAND blocks has = failed, not that it could not >>> detect an error. Is there a lack of error detection in the driver = handling USB thumb drives and reported back to the kernel? I do not = know. >> Bob's context is reproducible at the same places in >=20 > No, he was talking about a "failed silently" event and this is what I = was replying to. I've been working with Bob for some time on the issue and have a lot of context on how to interpret things that are not clear from what he extracted and sent out of our off-list exchanges. At this point it is hard for me to write notes without using that context. This likely makes for an odd read and unintended implications relative to only having what Bob sent to the list. We have no specific evidence of a media error at any specific block/page. We have had no evidence of random variations in the behavior beyond the expected sorts of things from the likes of a -j4 buildworld : which file was processed first being the one to get the report of the compiler problem. > I am not up-to-date with the previous discussion on the failure of = llvm/clang. I am. Some of it has been off-list. The corrupted data hypothesis is a potential explanation for the compiler "139" (SEGV) failures on the RPi3* configuration in question. >> Such is unlikely for hitting the same problem page(s) >> in the swap space each way things are run. >=20 > I couldn't agree more. The chances would seem remote, unless that = partition is on a part of the SD card/USB drive that is failing and the = USB driver is not detecting these as reported by the controller. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 2 06:46:26 2022 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 BC5B319A4D8E for ; Wed, 2 Feb 2022 06:46:40 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4JpXQQ0ywVz3PL2 for ; Wed, 2 Feb 2022 06:46:38 +0000 (UTC) (envelope-from mafsys1234@gmail.com) Received: by mail-pj1-x1036.google.com with SMTP id o64so19413285pjo.2 for ; Tue, 01 Feb 2022 22:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QxsRMBxHGFu0DxKlgeSr6FPbj/GszCjoWuW3fHFyac0=; b=IMFrEaK+YPvERTWAsUCcfMPJReWC/kTGCVofkxwgX/5mTdjdEJNFiANXqoZUm6+OAo pn27S8F9tMVGPzxJH8pNcyd+NtLZdsfpvd4rrzkpHGJVkEisih/TfDqrNOwfnVEm8l5N R74JBb+lBuA/Q8hzFHm/NTk3SmJTNcLIb8oemBz9RYKhYzDij7eIRGW63thavR2Y9gKE ocmRjN8X9TRwNA5cIeqJMhPQLchy6R33utyMeBYX6d1d09HQAndoHQ9Mj2GkxmfNAY7W NVppouK0sJUw85m1Ag7MqhNP9EVUHlpMKg7d7XyzyTBcTnDBYGqSYjit+q/+swkb65WB 8W+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QxsRMBxHGFu0DxKlgeSr6FPbj/GszCjoWuW3fHFyac0=; b=4gHXwCksdSTkwnUxzhvB+0aYgorDhiqiosf9mRLglz0w3xcinS6Kg4GUKipXRoSSR/ Q+tiH/4FdYx0dKFvLNuhBculASTAvTExqHmgwmrWPQW/dTCxngh7ZV9vwX/6S34un6Pv ys9lBe2ormQbINU78yXrDPnLNeQK/hRcIfhyMdLna4bWTzkl0pBZHB+McB1AxaUo7iUR u8TfEZ4pWWvA3QvEpMc7A+uBB6W6AR1jD5trk+BuKhCyMFRQtVLjjb8gtRiO6pFMBGrB TDd7aVMUgeb3ZZzSn+A1SfsU32XkxFNHGWteKP7s0Jk/QWbhpA4G/Ts8AVGC3xpz/uNz YTkw== X-Gm-Message-State: AOAM530GkQH1jaMLMk3UQ67ZCCPyBccPX6HwqV6S0kCC8QG3mYNbK4/B Jd5AtNjQLEUV26hyRVUVnoednkBuePGgqQ== X-Google-Smtp-Source: ABdhPJytoQN3hnYOHnUmnZO9rn2jYCz171yQ08qm1JS5zwsufIcuHp849HU8ukUWMHHs7pwU2keKgA== X-Received: by 2002:a17:902:758c:: with SMTP id j12mr29345425pll.79.1643784390436; Tue, 01 Feb 2022 22:46:30 -0800 (PST) Received: from [192.168.1.10] ([115.69.53.183]) by smtp.gmail.com with ESMTPSA id mq3sm5499747pjb.4.2022.02.01.22.46.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Feb 2022 22:46:30 -0800 (PST) Subject: Re: Error detection for microSD-based swap, buildworld failures on pi3 To: "freebsd-arm@freebsd.org" References: <20220129022255.GA59340@www.zefox.net> <6B822440-6F01-4578-803C-20A51DADF10C@yahoo.com> <20220130020546.GA63792@www.zefox.net> <1964F2B7-EC41-42C8-9C18-5E2B79EE0271@yahoo.com> <5B3DF910-23B1-4246-999E-0196E90269F2@yahoo.com> <20220131165333.GA69543@www.zefox.net> <9E0510D2-9FAC-4F01-89A3-E6D8C7C21FDA@yahoo.com> <20220131221405.GA70251@www.zefox.net> <14716537-6E22-44F5-B6AA-841E3EB2AD04@yahoo.com> <20220201161808.GA73977@www.zefox.net> <0e61e2d8-c65f-eb23-473f-69403e33da9e@gmail.com> <9b604f9e-45bf-b197-562f-1f6381ee5515@gmail.com> From: MJ Message-ID: <4f915aa6-4382-217e-d0b8-28346e5bb8f5@gmail.com> Date: Wed, 2 Feb 2022 17:46:26 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpXQQ0ywVz3PL2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IMFrEaK+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mafsys1234@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=mafsys1234@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; INTRODUCTION(2.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::1036:server fail,115.69.53.183:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2007 Lines: 48 On 2/02/2022 3:10 pm, Mark Millard wrote: > On 2022-Feb-1, at 18:52, MJ wrote: > >> On 2/02/2022 12:25 pm, Mark Millard wrote: >>> On 2022-Feb-1, at 16:47, MJ wrote: >>>> On 2/02/2022 3:18 am, bob prohaska wrote: >>>>> [new subject, different emphasis, old problem] >>>>> On Mon, Jan 31, 2022 at 03:06:01PM -0800, Mark Millard wrote: >>>>>> >>>>>> One thing that could fit the behavior is if small part(s) >>>>>> of the system c++ compiler (or libraires it uses) were >>>>>> corrupted on that specific media. In that case, nothing >>>>>> elsewhere would replicate the failures but a lot might >>>>>> work without using the corrupted part(s), making the >>>>>> failures not random. >>>>> [spaced for emphasis] >>>>>> Checking on that is part of why >>>>>> I'd hoped to get a lldb report for a .sh/.cpp pair >>>>>> leading to failure on your RPi3* in question. >>>>>> >>>>> If/when the stable/13 Pi3 finishes its -j1 single-user >>>>> build/install cycle I'll make a point of trying the >>>>> .sh/.cpp test under lldb. >>>>> For most of their operational history both troublesome Pi3 >>>>> systems have had some of their swap on microSD. If there >>>>> is no error detection at all for microSD-based storage >>>> >>>> Is this true? I would have thought it used some form of error detection in the firmware or in >>>> the controller. >>> The type of error and stage at which the error occurs matters. >>> The firmware can not cover all issues that lead to corrupted >>> content on media. >> >> I did not state it covers all corruption. However, I would be totally surprised if the controller in >> ALL SD cards does not do error checking, whether ECC or even BCH. That remains my point. > > I've a lot more context on Bob's problem and was mostly > giving more context than he supplied. (My name is on the > most nested text that he sent. I've been working with him > for a while on this.) > Ok, understood, I will refrain. No more noise from me. MJ From nobody Wed Feb 2 12:23:36 2022 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 39C461895C04 for ; Wed, 2 Feb 2022 12:23:48 +0000 (UTC) (envelope-from devesas.campos@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 4JpgvR1xsLz3qn0 for ; Wed, 2 Feb 2022 12:23:47 +0000 (UTC) (envelope-from devesas.campos@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id n8so15134644wmk.3 for ; Wed, 02 Feb 2022 04:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=WXnt8mF/9w0fg27bOcWCiGEn0P8Lt3RvBXka8VMJ11k=; b=PRXCu2VDIf+/T4TFk0Vb202G87BVvmmDfrzX1oIVvS/XxW59JkpeFoAOCn98CzZRgn fWoSUhRy6UaDCS2DwwS6WjmZr7GUb8OQN3PN+Ba3bCIeyqfHL84Ep/OG8MCYwfbZ1oeW Z6OkG05sOWqrIsJdFoqQn7onYiXxLbuv1Jt/4Y43q52N6AY2Mf24dbiDbEyYpapATuRA E0BBiIos87vvvM5HlAAQWKsuRZ9F5u5zWBHD0NCJJv5hJhLyYPlp3kGxc6HZnulIsJdC DXnKoNgyrkTaSa8alz2SoaO1T1aiX+sof7aoJaJcJrxibMLn+6kte+WCTwe2m28pFjEN 9QrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=WXnt8mF/9w0fg27bOcWCiGEn0P8Lt3RvBXka8VMJ11k=; b=PKk/5cvOABEUWWQSXLfPzQWB28QHVMgagdOpKUovJjhUuuft4lu9vikkVFvVbLxhVd tsTk3G6/EKrLKrNLbRL6nd+Hm9gbSTLEsJM7KlFPyCmmQaJWHXQQl3jmIoD2S0CtLJ7T foh4AD+XUdVnrTtGyWM7O2k9bUC9+IADkqWqZXuBjZmwoCwwWc7YMuRudLmN4uDDDFnQ WHUxt5ZIMaVDLo8xIkra4SNNRsK2wyOgKKUOxfUtzMrS+GPrKQ0oGap4xKPZFcE65FY8 UKi4Fijp2K/KniMSwQmjiFd6P6CXw3N4OcnCD1N13If5RiKxzKx5BAua/irCNQVk7npR +fiA== X-Gm-Message-State: AOAM533fIrRwDSZiUqTa4EY50l5WMNJ3003kyHOXv05i9zyLoAAUKxIR 1KCrfk8lejKMTDF2lufb1mFJvYXvF0I7og== X-Google-Smtp-Source: ABdhPJy8MHeL1VYR8dBZwi88NrmOEpp861awCCv35AOAAyG5cDTI13JXx+rBKgb4yFr1mM5HeotjKQ== X-Received: by 2002:a7b:c40a:: with SMTP id k10mr5821219wmi.179.1643804619194; Wed, 02 Feb 2022 04:23:39 -0800 (PST) Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181]) by smtp.gmail.com with ESMTPSA id a18sm17582446wrw.5.2022.02.02.04.23.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Feb 2022 04:23:38 -0800 (PST) From: Marco Devesas Campos 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 14.0 \(3654.120.0.1.13\)) Date: Wed, 2 Feb 2022 12:23:36 +0000 Subject: [PATCH] Experimental vchiq and bcm2835_audio support for arm64 Message-Id: To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JpgvR1xsLz3qn0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PRXCu2VD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of devesascampos@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=devesascampos@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[213.22.242.181:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32a:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 56258 Lines: 1893 Hi List, Below is a very experimental patch, against stable/13, that brings = bcm2835_audio to the 64bit era -- and with it, the vchiq driver (only to = the extent required by audio -- no promises anything will work beyond = that). There's work and more testing to be done (again, it=E2=80=99s = experimental) but it seems to work quite nicely on my system so I = thought I'd post it here so that (1) people could test it out -- only tried it in an rpi-zero2 and I'd = been keen to hear from people with access to rpis-3; and (2) I could hear from people with actual experience in writing = drivers, since this this is my first foray into kernel and arm = programming, on possible issues with the code. One particular concern is = that call to arm64_dcache_wbinv_range in the code that does DMA.=20 To compile, just add `device vchiq` to your kernel config or use the = GENERIC-VCHIQ config file included in the patch. (If you want any shot = at building it on an rpi without swap, read the comments there) Best, Marco diff --git a/sys/arm/broadcom/bcm2835/bcm2835_audio.c = b/sys/arm/broadcom/bcm2835/bcm2835_audio.c index ae2c9a14fc62..5cd3f4bfd804 100644 --- a/sys/arm/broadcom/bcm2835/bcm2835_audio.c +++ b/sys/arm/broadcom/bcm2835/bcm2835_audio.c @@ -27,6 +27,10 @@ #include "opt_snd.h" #endif =20 +/* + For the PRIu64 identifier +*/ +#include #include #include =20 @@ -116,6 +120,12 @@ struct bcm2835_audio_chinfo { uint64_t retrieved_samples; uint64_t underruns; int starved; + struct bcm_log_vars { + unsigned int bsize ; + int slept_for_lack_of_space ; + } log_vars; +#define DEFAULT_LOG_VALUES \ + ((struct bcm_log_vars) { .bsize =3D 0 , .slept_for_lack_of_space = =3D 0 }) }; =20 struct bcm2835_audio_info { @@ -135,6 +145,7 @@ struct bcm2835_audio_info { =20 uint32_t flags_pending; =20 + int verbose_trace; /* Worker thread state */ int worker_state; }; @@ -143,6 +154,35 @@ struct bcm2835_audio_info { #define BCM2835_AUDIO_LOCKED(sc) mtx_assert(&(sc)->lock, = MA_OWNED) #define BCM2835_AUDIO_UNLOCK(sc) mtx_unlock(&(sc)->lock) =20 +/* things that really have to be reported */ +#define REPORT_ERROR(sc,...) \ + do{ device_printf((sc)->dev,__VA_ARGS__); }while(0) +/* things that shouldn't clobber the output */ +#define INFORM_THAT(sc,...) \ + do { \ + if(sc->verbose_trace>0){ \ + device_printf((sc)->dev,__VA_ARGS__); \ + } \ + }while(0) +/* things that might clobber the output */ +#define WARN_THAT(sc,...) \ + do { \ + if(sc->verbose_trace>1){ \ + device_printf((sc)->dev,__VA_ARGS__); \ + } \ + }while(0) +/* things that are expected to (will) clobber the output */ +#define TRACE(sc,...) \ + do { \ + if(sc->verbose_trace>2){ \ + device_printf((sc)->dev,__VA_ARGS__); \ + } \ + }while(0) + +/* Useful for circular buffer calcs */ +#define MOD_DIFF(front,rear,mod) (((mod) + (front) - (rear)) % mod) + + static const char * dest_description(uint32_t dest) { @@ -214,10 +254,21 @@ bcm2835_audio_callback(void *param, const = VCHI_CALLBACK_REASON_T reason, void *m m.type); } } else if (m.type =3D=3D VC_AUDIO_MSG_TYPE_COMPLETE) { - struct bcm2835_audio_chinfo *ch =3D m.u.complete.cookie; + unsigned int signaled =3D 0; + struct bcm2835_audio_chinfo *ch ; +#if defined(__aarch64__) + ch =3D (void *) ((((size_t)m.u.complete.callback) << 32) + | ((size_t)m.u.complete.cookie)); +#else + ch =3D (void *) (m.u.complete.cookie); +#endif + =20 int count =3D m.u.complete.count & 0xffff; int perr =3D (m.u.complete.count & (1U << 30)) !=3D 0; + + TRACE(sc,"in:: count:0x%x = perr:%d\n",m.u.complete.count,perr); + ch->callbacks++; if (perr) ch->underruns++; @@ -237,18 +288,51 @@ bcm2835_audio_callback(void *param, const = VCHI_CALLBACK_REASON_T reason, void *m device_printf(sc->dev, = "available_space =3D=3D %d, count =3D %d, perr=3D%d\n", ch->available_space, count, = perr); device_printf(sc->dev, - "retrieved_samples =3D %lld, = submitted_samples =3D %lld\n", + "retrieved_samples =3D = %"PRIu64", submitted_samples =3D %"PRIu64"\n", ch->retrieved_samples, = ch->submitted_samples); } - ch->available_space +=3D count; - ch->retrieved_samples +=3D count; } - if (perr || (ch->available_space >=3D = VCHIQ_AUDIO_PACKET_SIZE)) + /* + EXPERIMENTAL + two lines were before that + close bracket [ed: ftb of the {} matcher] + */ + ch->available_space +=3D count; + ch->retrieved_samples +=3D count; + /* + EXPERIMENTAL + Experimental: if VC says it's empty, believe = it + Has to come after the usual adjustments + */ + if(perr){ + ch->available_space =3D = VCHIQ_AUDIO_BUFFER_SIZE; + perr =3D ch->retrieved_samples; // shd = be !=3D 0 + } + /* + EXPERIMENTAL + Throttle things a bit, so as to not + tire VC out (TBR) + */ + =20 + if ((ch->available_space >=3D = 2*VCHIQ_AUDIO_PACKET_SIZE)){ cv_signal(&sc->worker_cv); + signaled =3D 1; + } } BCM2835_AUDIO_UNLOCK(sc); + if(perr){ + WARN_THAT(sc, + "VC starved; reported %u for a total of = %u\n" + "worker %s\n" , + count,perr, + (signaled ? "signaled": "not signaled") + ); + } } else - printf("%s: unknown m.type: %d\n", __func__, m.type); + WARN_THAT(sc, + "%s: unknown m.type: %d\n", + __func__, m.type + ); } =20 /* VCHIQ stuff */ @@ -260,13 +344,13 @@ bcm2835_audio_init(struct bcm2835_audio_info *sc) /* Initialize and create a VCHI connection */ status =3D vchi_initialise(&sc->vchi_instance); if (status !=3D 0) { - printf("vchi_initialise failed: %d\n", status); + REPORT_ERROR(sc,"vchi_initialise failed: %d\n", status); return; } =20 status =3D vchi_connect(NULL, 0, sc->vchi_instance); if (status !=3D 0) { - printf("vchi_connect failed: %d\n", status); + REPORT_ERROR(sc,"vchi_connect failed: %d\n", status); return; } =20 @@ -298,7 +382,7 @@ bcm2835_audio_release(struct bcm2835_audio_info *sc) if (sc->vchi_handle !=3D VCHIQ_SERVICE_HANDLE_INVALID) { success =3D vchi_service_close(sc->vchi_handle); if (success !=3D 0) - printf("vchi_service_close failed: %d\n", = success); + REPORT_ERROR(sc,"vchi_service_close failed: = %d\n", success); vchi_service_release(sc->vchi_handle); sc->vchi_handle =3D VCHIQ_SERVICE_HANDLE_INVALID; } @@ -328,7 +412,10 @@ bcm2835_audio_start(struct bcm2835_audio_chinfo = *ch) &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); + REPORT_ERROR(sc, + "%s: vchi_msg_queue failed (err %d)\n", + __func__, ret + ); } } =20 @@ -343,11 +430,15 @@ bcm2835_audio_stop(struct bcm2835_audio_chinfo = *ch) m.type =3D VC_AUDIO_MSG_TYPE_STOP; m.u.stop.draining =3D 0; =20 + INFORM_THAT(sc,"sending stop\n"); ret =3D vchi_msg_queue(sc->vchi_handle, &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); + REPORT_ERROR(sc, + "%s: vchi_msg_queue failed (err %d)\n", + __func__, ret + ); } } =20 @@ -363,7 +454,10 @@ bcm2835_audio_open(struct bcm2835_audio_info *sc) &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); + REPORT_ERROR(sc, + "%s: vchi_msg_queue failed (err %d)\n", + __func__, ret + ); } } =20 @@ -385,7 +479,10 @@ bcm2835_audio_update_controls(struct = bcm2835_audio_info *sc, uint32_t volume, ui &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); + REPORT_ERROR(sc, + "%s: vchi_msg_queue failed (err %d)\n", + __func__, ret + ); } } =20 @@ -405,7 +502,10 @@ bcm2835_audio_update_params(struct = bcm2835_audio_info *sc, uint32_t fmt, uint32_ &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); + REPORT_ERROR(sc, + "%s: vchi_msg_queue failed (err %d)\n", + __func__, ret + ); } } =20 @@ -413,18 +513,26 @@ static bool bcm2835_audio_buffer_should_sleep(struct bcm2835_audio_chinfo *ch) { =20 + ch->log_vars.slept_for_lack_of_space =3D 0; if (ch->playback_state !=3D PLAYBACK_PLAYING) return (true); =20 /* Not enough data */ - if (sndbuf_getready(ch->buffer) < VCHIQ_AUDIO_PACKET_SIZE) { - printf("starve\n"); + /*=20 + EXPERIMENTAL + Take unsubmitted stuff into account + */ + if (sndbuf_getready(ch->buffer) + - = MOD_DIFF(ch->unsubmittedptr,sndbuf_getreadyptr(ch->buffer), + sndbuf_getsize(ch->buffer)) + < VCHIQ_AUDIO_PACKET_SIZE) { ch->starved++; return (true); } =20 /* Not enough free space */ if (ch->available_space < VCHIQ_AUDIO_PACKET_SIZE) { + ch->log_vars.slept_for_lack_of_space =3D 1; return (true); } =20 @@ -445,22 +553,27 @@ bcm2835_audio_write_samples(struct = bcm2835_audio_chinfo *ch, void *buf, uint32_t m.type =3D VC_AUDIO_MSG_TYPE_WRITE; m.u.write.count =3D count; m.u.write.max_packet =3D VCHIQ_AUDIO_PACKET_SIZE; - m.u.write.callback =3D NULL; - m.u.write.cookie =3D ch; +#if defined(__aarch64__) + m.u.write.callback =3D (uint32_t)(((size_t) ch) >> 32) & = 0xffffffff; + m.u.write.cookie =3D (uint32_t)(((size_t) ch) & 0xffffffff); +#else + m.u.write.callback =3D (uint32_t) NULL; + m.u.write.cookie =3D (uint32_t) ch; +#endif m.u.write.silence =3D 0; =20 ret =3D vchi_msg_queue(sc->vchi_handle, &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); =20 if (ret !=3D 0) - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, = ret); + REPORT_ERROR(sc,"%s: vchi_msg_queue failed (err %d)\n", = __func__, ret); =20 while (count > 0) { int bytes =3D MIN((int)m.u.write.max_packet, = (int)count); ret =3D vchi_msg_queue(sc->vchi_handle, buf, bytes, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); if (ret !=3D 0) - printf("%s: vchi_msg_queue failed: %d\n", + REPORT_ERROR(sc,"%s: vchi_msg_queue failed: = %d\n", __func__, ret); buf =3D (char *)buf + bytes; count -=3D bytes; @@ -492,6 +605,10 @@ bcm2835_audio_worker(void *data) while ((sc->flags_pending =3D=3D 0) && bcm2835_audio_buffer_should_sleep(ch)) { cv_wait_sig(&sc->worker_cv, &sc->lock); + if((sc-> flags_pending =3D=3D 0) + && ch->log_vars.slept_for_lack_of_space) { + TRACE(sc,"slept for lack of space\n"); + } } flags =3D sc->flags_pending; /* Clear pending flags */ @@ -518,16 +635,32 @@ bcm2835_audio_worker(void *data) BCM2835_AUDIO_LOCK(sc); bcm2835_audio_reset_channel(&sc->pch); ch->playback_state =3D PLAYBACK_IDLE; + long sub_total =3D ch->submitted_samples; + long retd =3D ch->retrieved_samples; BCM2835_AUDIO_UNLOCK(sc); + INFORM_THAT(sc, + "stopped audio. submitted a total of %lu = " + "having been acked %lu\n", + sub_total, retd + ); continue; } =20 /* Requested to start playback */ if ((flags & AUDIO_PLAY) && (ch->playback_state =3D=3D PLAYBACK_IDLE)) { + INFORM_THAT(sc, + "starting audio\n" + ); + unsigned int bsize =3D = sndbuf_getsize(ch->buffer); BCM2835_AUDIO_LOCK(sc); ch->playback_state =3D PLAYBACK_PLAYING; + ch->log_vars.bsize =3D bsize; BCM2835_AUDIO_UNLOCK(sc); + INFORM_THAT(sc, + "buffer size is %u\n", + bsize + );=09 bcm2835_audio_start(ch); } =20 @@ -536,20 +669,75 @@ bcm2835_audio_worker(void *data) =20 if (sndbuf_getready(ch->buffer) =3D=3D 0) continue; + uint32_t i_count ;//, size, readyptr; =20 - count =3D sndbuf_getready(ch->buffer); + /* + EXPERIMENTAL + Take unsubmitted stuff into account + */ +/* + count =3D i_count =3D sndbuf_getready(ch->buffer) ; + readyptr =3D sndbuf_getreadyptr(ch->buffer); +*/ + count + =3D i_count + =3D sndbuf_getready(ch->buffer) + - MOD_DIFF(ch->unsubmittedptr, + sndbuf_getreadyptr(ch->buffer), + sndbuf_getsize(ch->buffer)); size =3D sndbuf_getsize(ch->buffer); - readyptr =3D sndbuf_getreadyptr(ch->buffer); + readyptr =3D ch->unsubmittedptr; =20 + int size_changed=3D0; + unsigned int available; BCM2835_AUDIO_LOCK(sc); - if (readyptr + count > size) + if(size !=3D ch->log_vars.bsize){ + ch->log_vars.bsize =3D size; + size_changed =3D 1; + } + available =3D ch->available_space; + /* + EXPERIMENTAL + On arm64, got into situations where=20 + readyptr was less than a packet away + from the end of the buffer, which led + to count being set to 0 and, inexorably, starvation. + Code below tries to take that into account. + The problem might have been fixed with some of the = other changes + that were made in the meantime, but for now this = works fine. + */ + if (readyptr + count > size){ count =3D size - readyptr; - count =3D min(count, ch->available_space); - count -=3D (count % VCHIQ_AUDIO_PACKET_SIZE); + } + //count =3D min(count, ch->available_space); + //count -=3D (count % VCHIQ_AUDIO_PACKET_SIZE); + if(count > ch->available_space){ + count =3D ch->available_space; + count -=3D (count % VCHIQ_AUDIO_PACKET_SIZE); + }else if (count > VCHIQ_AUDIO_PACKET_SIZE){ + count -=3D (count % VCHIQ_AUDIO_PACKET_SIZE); + }else if (size > count + readyptr) { + count =3D 0; + } BCM2835_AUDIO_UNLOCK(sc); - - if (count < VCHIQ_AUDIO_PACKET_SIZE) + if(count % VCHIQ_AUDIO_PACKET_SIZE !=3D 0){ + WARN_THAT(sc, + "count: %u initial count: %u " + "size: %u readyptr: %u available: %u" + "\n", + count,i_count,size,readyptr, available); + } + if(size_changed) INFORM_THAT(sc,"bsize changed to %u\n",size); + =09 + //if (count < VCHIQ_AUDIO_PACKET_SIZE){ + if (count =3D=3D 0){ + WARN_THAT(sc, + "not enough room for a packet: count = %d," + " i_count %d, rptr %d, size %d\n", + count, i_count, readyptr, size + ); continue; + } =20 buf =3D (uint8_t*)sndbuf_getbuf(ch->buffer) + readyptr; =20 @@ -558,8 +746,17 @@ bcm2835_audio_worker(void *data) ch->unsubmittedptr =3D (ch->unsubmittedptr + count) % = sndbuf_getsize(ch->buffer); ch->available_space -=3D count; ch->submitted_samples +=3D count; + long sub =3D count; + long sub_total =3D ch->submitted_samples; + long retd =3D ch->retrieved_samples; KASSERT(ch->available_space >=3D 0, = ("ch->available_space =3D=3D %d\n", ch->available_space)); BCM2835_AUDIO_UNLOCK(sc); + + TRACE(sc, + "submitted %lu for a total of %lu having been acked %lu; = " + "rptr %d, had %u available \n", + sub, sub_total, retd, readyptr, available); + } =20 BCM2835_AUDIO_LOCK(sc); @@ -578,7 +775,9 @@ bcm2835_audio_create_worker(struct = bcm2835_audio_info *sc) sc->worker_state =3D WORKER_RUNNING; if (kproc_create(bcm2835_audio_worker, (void*)sc, &newp, 0, 0, "bcm2835_audio_worker") !=3D 0) { - printf("failed to create bcm2835_audio_worker\n"); + REPORT_ERROR(sc, + "failed to create bcm2835_audio_worker\n" + ); } } =20 @@ -611,6 +810,8 @@ bcmchan_init(kobj_t obj, void *devinfo, struct = snd_dbuf *b, struct pcm_channel * return NULL; } =20 + ch->log_vars =3D DEFAULT_LOG_VALUES; + BCM2835_AUDIO_LOCK(sc); bcm2835_worker_update_params(sc); BCM2835_AUDIO_UNLOCK(sc); @@ -831,6 +1032,9 @@ vchi_audio_sysctl_init(struct bcm2835_audio_info = *sc) SYSCTL_ADD_INT(ctx, tree, OID_AUTO, "starved", CTLFLAG_RD, &sc->pch.starved, sc->pch.starved, "number of starved = conditions"); + SYSCTL_ADD_INT(ctx, tree, OID_AUTO, "trace", + CTLFLAG_RW, &sc->verbose_trace, + sc->verbose_trace, "enable tracing of = transfers"); } =20 static void @@ -862,6 +1066,7 @@ bcm2835_audio_delayed_init(void *xsc) bcm2835_audio_open(sc); sc->volume =3D 75; sc->dest =3D DEST_AUTO; + sc->verbose_trace =3D 0; =20 if (mixer_init(sc->dev, &bcmmixer_class, sc)) { device_printf(sc->dev, "mixer_init failed\n"); diff --git a/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h = b/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h index 143c54385916..04292df1c261 100644 --- a/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h +++ b/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h @@ -114,8 +114,8 @@ typedef struct typedef struct { uint32_t count; /* in bytes */ - void *callback; - void *cookie; + uint32_t callback; + uint32_t cookie; uint16_t silence; uint16_t max_packet; } VC_AUDIO_WRITE_T; @@ -131,8 +131,8 @@ typedef struct typedef struct { int32_t count; /* Success value */ - void *callback; - void *cookie; + uint32_t callback; + uint32_t cookie; } VC_AUDIO_COMPLETE_T; =20 /* Message header for all messages in HOST->VC direction */ diff --git a/sys/arm64/conf/GENERIC-VCHIQ b/sys/arm64/conf/GENERIC-VCHIQ new file mode 100644 index 000000000000..422ed425894c --- /dev/null +++ b/sys/arm64/conf/GENERIC-VCHIQ @@ -0,0 +1,23 @@ +# +# GENERIC-VCHIQ +# +# Custom kernel for arm64 plus VCHIQ +# +# $FreeBSD$ + +#NO_UNIVERSE + +include GENERIC +ident GENERIC-VCHIQ + +device vchiq + +# If you want to have any chance of compiling this in a RPI Zero 2 +# uncomment the stuff below + +# nomakeoptions DEBUG +# nomakeoptions WITH_CTF +# nooptions DDB_CTF +# makeoptions MALLOC_PRODUCTION=3D1 + + diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c index 279aacd0880a..6d05b35006f0 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c @@ -171,7 +171,7 @@ vchiq_platform_init(VCHIQ_STATE_T *state) goto failed_load; } =20 - WARN_ON(((int)g_slot_mem & (PAGE_SIZE - 1)) !=3D 0); + WARN_ON(((size_t)g_slot_mem & (PAGE_SIZE - 1)) !=3D 0); =20 vchiq_slot_zero =3D vchiq_init_slots(g_slot_mem, = g_slot_mem_size); if (!vchiq_slot_zero) { @@ -204,8 +204,8 @@ vchiq_platform_init(VCHIQ_STATE_T *state) bcm_mbox_write(BCM2835_MBOX_CHAN_VCHIQ, (unsigned = int)g_slot_phys); =20 vchiq_log_info(vchiq_arm_log_level, - "vchiq_init - done (slots %x, phys %x)", - (unsigned int)vchiq_slot_zero, g_slot_phys); + "vchiq_init - done (slots %zx, phys %zx)", + (size_t)vchiq_slot_zero, g_slot_phys); =20 vchiq_call_connected_callbacks(); =20 @@ -393,13 +393,15 @@ pagelist_page_free(vm_page_t pp) ** from increased speed as a result. */ =20 + + static int create_pagelist(char __user *buf, size_t count, unsigned short type, struct proc *p, BULKINFO_T *bi) { PAGELIST_T *pagelist; vm_page_t* pages; - unsigned long *addrs; + uint32_t *addrs; unsigned int num_pages, i; vm_offset_t offset; int pagelist_size; @@ -453,7 +455,7 @@ create_pagelist(char __user *buf, size_t count, = unsigned short type, } =20 vchiq_log_trace(vchiq_arm_log_level, - "create_pagelist - %x (%d bytes @%p)", (unsigned = int)pagelist, count, buf); + "create_pagelist - %zx (%zu bytes @%p)", = (size_t)pagelist, count, buf); =20 if (!pagelist) return -ENOMEM; @@ -523,8 +525,12 @@ create_pagelist(char __user *buf, size_t count, = unsigned short type, (fragments - g_fragments_base)/g_fragment_size; } =20 +#if defined(__aarch64__) + arm64_dcache_wbinv_range((vm_offset_t)buf,count); +#else pa =3D pmap_extract(PCPU_GET(curpmap), (vm_offset_t)buf); dcache_wbinv_poc((vm_offset_t)buf, pa, count); +#endif =20 bus_dmamap_sync(bi->pagelist_dma_tag, bi->pagelist_dma_map, = BUS_DMASYNC_PREWRITE); =20 @@ -550,7 +556,7 @@ free_pagelist(BULKINFO_T *bi, int actual) pagelist =3D bi->pagelist; =20 vchiq_log_trace(vchiq_arm_log_level, - "free_pagelist - %x, %d (%lu bytes @%p)", (unsigned = int)pagelist, actual, pagelist->length, bi->buf); + "free_pagelist - %zx, %d (%u bytes @%p)", = (size_t)pagelist, actual, pagelist->length, bi->buf); =20 num_pages =3D (pagelist->length + pagelist->offset + PAGE_SIZE - 1) / diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c index 763cd9ce9417..9c0ef541ab08 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c @@ -442,8 +442,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, #define _IOC_TYPE(x) IOCGROUP(x) =20 vchiq_log_trace(vchiq_arm_log_level, - "vchiq_ioctl - instance %x, cmd %s, arg %p", - (unsigned int)instance, + "vchiq_ioctl - instance %zx, cmd %s, arg %p", + (size_t)instance, ((_IOC_TYPE(cmd) =3D=3D VCHIQ_IOC_MAGIC) && (_IOC_NR(cmd) <=3D VCHIQ_IOC_MAX)) ? ioctl_names[_IOC_NR(cmd)] : "", arg); @@ -745,8 +745,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, break; } vchiq_log_info(vchiq_arm_log_level, - "found bulk_waiter %x for pid %d", - (unsigned int)waiter, current->p_pid); + "found bulk_waiter %zx for pid %d", + (size_t)waiter, current->p_pid); args.userdata =3D &waiter->bulk_waiter; } status =3D vchiq_bulk_transfer @@ -776,8 +776,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, list_add(&waiter->list, = &instance->bulk_waiter_list); = lmutex_unlock(&instance->bulk_waiter_list_mutex); vchiq_log_info(vchiq_arm_log_level, - "saved bulk_waiter %x for pid %d", - (unsigned int)waiter, current->p_pid); + "saved bulk_waiter %zx for pid %d", + (size_t)waiter, current->p_pid); =20 memcpy((void *) &(((VCHIQ_QUEUE_BULK_TRANSFER_T *) @@ -860,9 +860,9 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, if (args.msgbufsize < msglen) { vchiq_log_error( = vchiq_arm_log_level, - "header %x: = msgbufsize" + "header %zx: = msgbufsize" " %x < msglen = %x", - (unsigned = int)header, + (size_t)header, args.msgbufsize, msglen); WARN(1, "invalid message = " @@ -1031,8 +1031,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, ret =3D -EFAULT; } else { vchiq_log_error(vchiq_arm_log_level, - "header %x: bufsize %x < size %x", - (unsigned int)header, args.bufsize, + "header %zx: bufsize %x < size %x", + (size_t)header, args.bufsize, header->size); WARN(1, "invalid size\n"); ret =3D -EMSGSIZE; @@ -1093,7 +1093,7 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t = arg, int fflag, } break; =20 case VCHIQ_IOC_LIB_VERSION: { - unsigned int lib_version =3D (unsigned int)arg; + size_t lib_version =3D (size_t)arg; =20 if (lib_version < VCHIQ_VERSION_MIN) ret =3D -EINVAL; @@ -1342,9 +1342,9 @@ vchiq_close(struct cdev *dev, int flags __unused, = int fmt __unused, list); list_del(pos); vchiq_log_info(vchiq_arm_log_level, - "bulk_waiter - cleaned up %x " + "bulk_waiter - cleaned up %zx " "for pid %d", - (unsigned int)waiter, = waiter->pid); + (size_t)waiter, waiter->pid); = _sema_destroy(&waiter->bulk_waiter.event); kfree(waiter); } @@ -1435,9 +1435,9 @@ vchiq_dump_platform_instances(void *dump_context) instance =3D service->instance; if (instance && !instance->mark) { len =3D snprintf(buf, sizeof(buf), - "Instance %x: pid %d,%s = completions " + "Instance %zx: pid %d,%s = completions " "%d/%d", - (unsigned int)instance, = instance->pid, + (size_t)instance, instance->pid, instance->connected ? " = connected, " : "", instance->completion_insert - @@ -1465,8 +1465,8 @@ vchiq_dump_platform_service_state(void = *dump_context, VCHIQ_SERVICE_T *service) char buf[80]; int len; =20 - len =3D snprintf(buf, sizeof(buf), " instance %x", - (unsigned int)service->instance); + len =3D snprintf(buf, sizeof(buf), " instance %zx", + (size_t)service->instance); =20 if ((service->base.callback =3D=3D service_callback) && user_service->is_vchi) { diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c index 2e30dd7dc3de..ca848e6e9016 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c @@ -31,6 +31,9 @@ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ =20 +/* For the PRIu64 format identifier */ +#include + #include "vchiq_core.h" #include "vchiq_killable.h" =20 @@ -392,9 +395,9 @@ make_service_callback(VCHIQ_SERVICE_T *service, = VCHIQ_REASON_T reason, VCHIQ_HEADER_T *header, void *bulk_userdata) { VCHIQ_STATUS_T status; - vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %x, = %x)", + vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %tx, = %tx)", service->state->id, service->localport, = reason_names[reason], - (unsigned int)header, (unsigned int)bulk_userdata); + (size_t)header, (size_t)bulk_userdata); status =3D service->base.callback(reason, header, = service->handle, bulk_userdata); if (status =3D=3D VCHIQ_ERROR) { @@ -417,13 +420,15 @@ vchiq_set_conn_state(VCHIQ_STATE_T *state, = VCHIQ_CONNSTATE_T newstate) vchiq_platform_conn_state_changed(state, oldstate, newstate); } =20 +#define ACTUAL_EVENT_SEM_ADDR(ref,offset)\ + ((struct semaphore *)(((size_t) ref) + ((size_t) offset))) static inline void -remote_event_create(REMOTE_EVENT_T *event) +remote_event_create(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) { event->armed =3D 0; /* Don't clear the 'fired' flag because it may already have been = set ** by the other side. */ - _sema_init(event->event, 0); + _sema_init(ACTUAL_EVENT_SEM_ADDR(ref,event->event), 0); } =20 __unused static inline void @@ -433,13 +438,18 @@ remote_event_destroy(REMOTE_EVENT_T *event) } =20 static inline int -remote_event_wait(REMOTE_EVENT_T *event) +remote_event_wait(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) { if (!event->fired) { event->armed =3D 1; +#if defined(__aarch64__) + dsb(sy); +#else dsb(); +#endif + if (!event->fired) { - if (down_interruptible(event->event) !=3D 0) { + if = (down_interruptible(ACTUAL_EVENT_SEM_ADDR(ref,event->event)) !=3D 0) { event->armed =3D 0; return 0; } @@ -453,26 +463,30 @@ remote_event_wait(REMOTE_EVENT_T *event) } =20 static inline void -remote_event_signal_local(REMOTE_EVENT_T *event) +remote_event_signal_local(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) { +/* + As per = https://github.com/raspberrypi/linux/commit/a50c4c9a65779ca835746b5fd79d3d= 5278afbdbe +*/ + event->fired =3D 1; event->armed =3D 0; - up(event->event); + up(ACTUAL_EVENT_SEM_ADDR(ref,event->event)); } =20 static inline void -remote_event_poll(REMOTE_EVENT_T *event) +remote_event_poll(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) { if (event->fired && event->armed) - remote_event_signal_local(event); + remote_event_signal_local(ref,event); } =20 void remote_event_pollall(VCHIQ_STATE_T *state) { - remote_event_poll(&state->local->sync_trigger); - remote_event_poll(&state->local->sync_release); - remote_event_poll(&state->local->trigger); - remote_event_poll(&state->local->recycle); + remote_event_poll(state , &state->local->sync_trigger); + remote_event_poll(state , &state->local->sync_release); + remote_event_poll(state , &state->local->trigger); + remote_event_poll(state , &state->local->recycle); } =20 /* Round up message sizes so that any space at the end of a slot is = always big @@ -553,7 +567,7 @@ request_poll(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T = *service, int poll_type) wmb(); =20 /* ... and ensure the slot handler runs. */ - remote_event_signal_local(&state->local->trigger); + remote_event_signal_local(state, &state->local->trigger); } =20 /* Called from queue_message, by the slot handler and application = threads, @@ -640,8 +654,8 @@ process_free_queue(VCHIQ_STATE_T *state) =20 rmb(); =20 - vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=3D%x = %x %x", - state->id, slot_index, (unsigned int)data, + vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=3D%tx = %x %x", + state->id, slot_index, (size_t)data, local->slot_queue_recycle, = slot_queue_available); =20 /* Initialise the bitmask for services which have used = this @@ -675,13 +689,13 @@ process_free_queue(VCHIQ_STATE_T *state) = vchiq_log_error(vchiq_core_log_level, "service %d " "message_use_count=3D%d = " - "(header %x, msgid %x, " + "(header %tx, msgid %x, = " "header->msgid %x, " "header->size %x)", port, service_quota-> = message_use_count, - (unsigned int)header, = msgid, + (size_t)header, msgid, header->msgid, header->size); WARN(1, "invalid message use = count\n"); @@ -704,24 +718,24 @@ process_free_queue(VCHIQ_STATE_T *state) = up(&service_quota->quota_event); vchiq_log_trace( = vchiq_core_log_level, - "%d: pfq:%d = %x@%x - " + "%d: pfq:%d = %x@%tx - " "slot_use->%d", state->id, port, header->size, - (unsigned = int)header, + (size_t)header, count - 1); } else { vchiq_log_error( = vchiq_core_log_level, "service = %d " = "slot_use_count" - "=3D%d = (header %x" + "=3D%d = (header %tx" ", msgid = %x, " = "header->msgid" " %x, = header->" "size = %x)", port, count, - (unsigned = int)header, + (size_t)header, msgid, header->msgid, header->size); @@ -735,9 +749,9 @@ process_free_queue(VCHIQ_STATE_T *state) pos +=3D calc_stride(header->size); if (pos > VCHIQ_SLOT_SIZE) { vchiq_log_error(vchiq_core_log_level, - "pfq - pos %x: header %x, msgid = %x, " + "pfq - pos %x: header %tx, msgid = %x, " "header->msgid %x, header->size = %x", - pos, (unsigned int)header, = msgid, + pos, (size_t)header, msgid, header->msgid, header->size); WARN(1, "invalid slot position\n"); } @@ -885,17 +899,16 @@ queue_message(VCHIQ_STATE_T *state, = VCHIQ_SERVICE_T *service, int slot_use_count; =20 vchiq_log_info(vchiq_core_log_level, - "%d: qm %s@%x,%x (%d->%d)", + "%d: qm %s@%tx,%x (%d->%d)", state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), - (unsigned int)header, size, + (size_t)header, size, VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid)); =20 BUG_ON(!service); BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK | QMFLAGS_NO_MUTEX_UNLOCK)) !=3D 0); - for (i =3D 0, pos =3D 0; i < (unsigned int)count; pos +=3D elements[i++].size) if (elements[i].size) { @@ -951,9 +964,9 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T = *service, VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size); } else { vchiq_log_info(vchiq_core_log_level, - "%d: qm %s@%x,%x (%d->%d)", state->id, + "%d: qm %s@%tx,%x (%d->%d)", state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), - (unsigned int)header, size, + (size_t)header, size, VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid)); if (size !=3D 0) { @@ -1017,7 +1030,7 @@ queue_message_sync(VCHIQ_STATE_T *state, = VCHIQ_SERVICE_T *service, (lmutex_lock_interruptible(&state->sync_mutex) !=3D 0)) return VCHIQ_RETRY; =20 - remote_event_wait(&local->sync_release); + remote_event_wait(state, &local->sync_release); =20 rmb(); =20 @@ -1036,9 +1049,9 @@ queue_message_sync(VCHIQ_STATE_T *state, = VCHIQ_SERVICE_T *service, int i, pos; =20 vchiq_log_info(vchiq_sync_log_level, - "%d: qms %s@%x,%x (%d->%d)", state->id, + "%d: qms %s@%tx,%x (%d->%d)", state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), - (unsigned int)header, size, + (size_t)header, size, VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid)); =20 @@ -1065,9 +1078,9 @@ queue_message_sync(VCHIQ_STATE_T *state, = VCHIQ_SERVICE_T *service, VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size); } else { vchiq_log_info(vchiq_sync_log_level, - "%d: qms %s@%x,%x (%d->%d)", state->id, + "%d: qms %s@%tx,%x (%d->%d)", state->id, msg_type_str(VCHIQ_MSG_TYPE(msgid)), - (unsigned int)header, size, + (size_t)header, size, VCHIQ_MSG_SRCPORT(msgid), VCHIQ_MSG_DSTPORT(msgid)); if (size !=3D 0) { @@ -1368,26 +1381,26 @@ resolve_bulks(VCHIQ_SERVICE_T *service, = VCHIQ_BULK_QUEUE_T *queue) "Send Bulk to" : "Recv Bulk from"; if (bulk->actual !=3D VCHIQ_BULK_ACTUAL_ABORTED) vchiq_log_info(SRVTRACE_LEVEL(service), - "%s %c%c%c%c d:%d len:%d = %x<->%x", + "%s %c%c%c%c d:%d len:%d = %tx<->%tx", header, VCHIQ_FOURCC_AS_4CHARS( service->base.fourcc), service->remoteport, bulk->size, - (unsigned int)bulk->data, - (unsigned = int)bulk->remote_data); + (size_t)bulk->data, + (size_t)bulk->remote_data); else vchiq_log_info(SRVTRACE_LEVEL(service), "%s %c%c%c%c d:%d ABORTED - tx = len:%d," - " rx len:%d %x<->%x", + " rx len:%d %tx<->%tx", header, VCHIQ_FOURCC_AS_4CHARS( service->base.fourcc), service->remoteport, bulk->size, bulk->remote_size, - (unsigned int)bulk->data, - (unsigned = int)bulk->remote_data); + (size_t)bulk->data, + (size_t)bulk->remote_data); } =20 vchiq_complete_bulk(bulk); @@ -1522,8 +1535,8 @@ parse_open(VCHIQ_STATE_T *state, VCHIQ_HEADER_T = *header) =20 fourcc =3D payload->fourcc; vchiq_log_info(vchiq_core_log_level, - "%d: prs OPEN@%x (%d->'%c%c%c%c')", - state->id, (unsigned int)header, + "%d: prs OPEN@%tx (%d->'%c%c%c%c')", + state->id, (size_t)header, localport, VCHIQ_FOURCC_AS_4CHARS(fourcc)); =20 @@ -1661,7 +1674,7 @@ parse_rx_slots(VCHIQ_STATE_T *state) =20 header =3D (VCHIQ_HEADER_T *)(state->rx_data + (state->rx_pos & VCHIQ_SLOT_MASK)); - DEBUG_VALUE(PARSE_HEADER, (int)header); + DEBUG_VALUE(PARSE_HEADER, (size_t)header); msgid =3D header->msgid; DEBUG_VALUE(PARSE_MSGID, msgid); size =3D header->size; @@ -1695,20 +1708,20 @@ parse_rx_slots(VCHIQ_STATE_T *state) remoteport); if (service) = vchiq_log_warning(vchiq_core_log_level, - "%d: prs %s@%x (%d->%d) = - " + "%d: prs %s@%tx (%d->%d) = - " "found connected service = %d", state->id, = msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, service->localport); } =20 if (!service) { vchiq_log_error(vchiq_core_log_level, - "%d: prs %s@%x (%d->%d) - " + "%d: prs %s@%zx (%d->%d) - " "invalid/closed service %d", state->id, msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, = localport); goto skip_message; } @@ -1734,12 +1747,12 @@ parse_rx_slots(VCHIQ_STATE_T *state) min(16, size)); } =20 - if (((unsigned int)header & VCHIQ_SLOT_MASK) + = calc_stride(size) + if (((size_t)header & VCHIQ_SLOT_MASK) + = calc_stride(size) > VCHIQ_SLOT_SIZE) { vchiq_log_error(vchiq_core_log_level, - "header %x (msgid %x) - size %x too big = for " + "header %tx (msgid %x) - size %x too big = for " "slot", - (unsigned int)header, (unsigned = int)msgid, + (size_t)header, (unsigned int)msgid, (unsigned int)size); WARN(1, "oversized for slot\n"); } @@ -1758,8 +1771,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) service->peer_version =3D = payload->version; } vchiq_log_info(vchiq_core_log_level, - "%d: prs OPENACK@%x,%x (%d->%d) v:%d", - state->id, (unsigned int)header, size, + "%d: prs OPENACK@%tx,%x (%d->%d) v:%d", + state->id, (size_t)header, size, remoteport, localport, = service->peer_version); if (service->srvstate =3D=3D VCHIQ_SRVSTATE_OPENING) { @@ -1776,8 +1789,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) WARN_ON(size !=3D 0); /* There should be no data = */ =20 vchiq_log_info(vchiq_core_log_level, - "%d: prs CLOSE@%x (%d->%d)", - state->id, (unsigned int)header, + "%d: prs CLOSE@%tx (%d->%d)", + state->id, (size_t)header, remoteport, localport); =20 mark_service_closing_internal(service, 1); @@ -1794,8 +1807,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) break; case VCHIQ_MSG_DATA: vchiq_log_info(vchiq_core_log_level, - "%d: prs DATA@%x,%x (%d->%d)", - state->id, (unsigned int)header, size, + "%d: prs DATA@%tx,%x (%d->%d)", + state->id, (size_t)header, size, remoteport, localport); =20 if ((service->remoteport =3D=3D remoteport) @@ -1819,14 +1832,19 @@ parse_rx_slots(VCHIQ_STATE_T *state) break; case VCHIQ_MSG_CONNECT: vchiq_log_info(vchiq_core_log_level, - "%d: prs CONNECT@%x", - state->id, (unsigned int)header); + "%d: prs CONNECT@%tx", + state->id, (size_t)header); state->version_common =3D ((VCHIQ_SLOT_ZERO_T *) = state->slot_data)->version; up(&state->connect); break; case VCHIQ_MSG_BULK_RX: - case VCHIQ_MSG_BULK_TX: { + case VCHIQ_MSG_BULK_TX: + WARN_ON(1); + break; +/* Appaz this isn't needed = +https://github.com/raspberrypi/linux/commit/14f4d72fb799a9b3170a45ab80d4a= 3ddad541960 +{ VCHIQ_BULK_QUEUE_T *queue; WARN_ON(!state->is_master); queue =3D (type =3D=3D VCHIQ_MSG_BULK_RX) ? @@ -1854,12 +1872,12 @@ parse_rx_slots(VCHIQ_STATE_T *state) wmb(); =20 vchiq_log_info(vchiq_core_log_level, - "%d: prs %s@%x (%d->%d) %x@%x", + "%d: prs %s@%tx (%d->%d) = %x@%tx", state->id, msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, bulk->remote_size, - (unsigned = int)bulk->remote_data); + (size_t)bulk->remote_data); =20 queue->remote_insert++; =20 @@ -1888,9 +1906,11 @@ parse_rx_slots(VCHIQ_STATE_T *state) lmutex_unlock(&service->bulk_mutex); if (resolved) notify_bulks(service, queue, - 1/*retry_poll*/); + 1//retry_poll + ); } } break; +*/ case VCHIQ_MSG_BULK_RX_DONE: case VCHIQ_MSG_BULK_TX_DONE: WARN_ON(state->is_master); @@ -1912,10 +1932,10 @@ parse_rx_slots(VCHIQ_STATE_T *state) if ((int)(queue->remote_insert - queue->local_insert) >=3D 0) { = vchiq_log_error(vchiq_core_log_level, - "%d: prs %s@%x (%d->%d) = " + "%d: prs %s@%tx (%d->%d) = " "unexpected = (ri=3D%d,li=3D%d)", state->id, = msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, queue->remote_insert, queue->local_insert); @@ -1932,11 +1952,11 @@ parse_rx_slots(VCHIQ_STATE_T *state) queue->remote_insert++; =20 vchiq_log_info(vchiq_core_log_level, - "%d: prs %s@%x (%d->%d) %x@%x", + "%d: prs %s@%tx (%d->%d) = %x@%tx", state->id, msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, - bulk->actual, (unsigned = int)bulk->data); + bulk->actual, = (size_t)bulk->data); =20 vchiq_log_trace(vchiq_core_log_level, "%d: prs:%d %cx li=3D%x ri=3D%x = p=3D%x", @@ -1958,14 +1978,14 @@ parse_rx_slots(VCHIQ_STATE_T *state) break; case VCHIQ_MSG_PADDING: vchiq_log_trace(vchiq_core_log_level, - "%d: prs PADDING@%x,%x", - state->id, (unsigned int)header, size); + "%d: prs PADDING@%tx,%x", + state->id, (size_t)header, size); break; case VCHIQ_MSG_PAUSE: /* If initiated, signal the application thread = */ vchiq_log_trace(vchiq_core_log_level, - "%d: prs PAUSE@%x,%x", - state->id, (unsigned int)header, size); + "%d: prs PAUSE@%tx,%x", + state->id, (size_t)header, size); if (state->conn_state =3D=3D = VCHIQ_CONNSTATE_PAUSED) { vchiq_log_error(vchiq_core_log_level, "%d: PAUSE received in state = PAUSED", @@ -1988,8 +2008,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) break; case VCHIQ_MSG_RESUME: vchiq_log_trace(vchiq_core_log_level, - "%d: prs RESUME@%x,%x", - state->id, (unsigned int)header, size); + "%d: prs RESUME@%tx,%x", + state->id, (size_t)header, size); /* Release the slot mutex */ lmutex_unlock(&state->slot_mutex); if (state->is_master) @@ -2010,8 +2030,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) =20 default: vchiq_log_error(vchiq_core_log_level, - "%d: prs invalid msgid %x@%x,%x", - state->id, msgid, (unsigned int)header, = size); + "%d: prs invalid msgid %x@%tx,%x", + state->id, msgid, (size_t)header, size); WARN(1, "invalid message\n"); break; } @@ -2051,7 +2071,7 @@ slot_handler_func(void *v) while (1) { DEBUG_COUNT(SLOT_HANDLER_COUNT); DEBUG_TRACE(SLOT_HANDLER_LINE); - remote_event_wait(&local->trigger); + remote_event_wait(state, &local->trigger); =20 rmb(); =20 @@ -2141,7 +2161,7 @@ recycle_func(void *v) VCHIQ_SHARED_STATE_T *local =3D state->local; =20 while (1) { - remote_event_wait(&local->recycle); + remote_event_wait(state, &local->recycle); =20 process_free_queue(state); } @@ -2165,7 +2185,7 @@ sync_func(void *v) int type; unsigned int localport, remoteport; =20 - remote_event_wait(&local->sync_trigger); + remote_event_wait(state, &local->sync_trigger); =20 rmb(); =20 @@ -2179,10 +2199,10 @@ sync_func(void *v) =20 if (!service) { vchiq_log_error(vchiq_sync_log_level, - "%d: sf %s@%x (%d->%d) - " + "%d: sf %s@%tx (%d->%d) - " "invalid/closed service %d", state->id, msg_type_str(type), - (unsigned int)header, + (size_t)header, remoteport, localport, localport); release_message_sync(state, header); continue; @@ -2213,8 +2233,8 @@ sync_func(void *v) service->peer_version =3D = payload->version; } vchiq_log_info(vchiq_sync_log_level, - "%d: sf OPENACK@%x,%x (%d->%d) v:%d", - state->id, (unsigned int)header, size, + "%d: sf OPENACK@%tx,%x (%d->%d) v:%d", + state->id, (size_t)header, size, remoteport, localport, = service->peer_version); if (service->srvstate =3D=3D = VCHIQ_SRVSTATE_OPENING) { service->remoteport =3D remoteport; @@ -2228,8 +2248,8 @@ sync_func(void *v) =20 case VCHIQ_MSG_DATA: vchiq_log_trace(vchiq_sync_log_level, - "%d: sf DATA@%x,%x (%d->%d)", - state->id, (unsigned int)header, size, + "%d: sf DATA@%tx,%x (%d->%d)", + state->id, (size_t)header, size, remoteport, localport); =20 if ((service->remoteport =3D=3D remoteport) && @@ -2248,8 +2268,8 @@ sync_func(void *v) =20 default: vchiq_log_error(vchiq_sync_log_level, - "%d: sf unexpected msgid %x@%x,%x", - state->id, msgid, (unsigned int)header, = size); + "%d: sf unexpected msgid %x@%tx,%x", + state->id, msgid, (size_t)header, size); release_message_sync(state, header); break; } @@ -2282,7 +2302,7 @@ get_conn_state_name(VCHIQ_CONNSTATE_T conn_state) VCHIQ_SLOT_ZERO_T * vchiq_init_slots(void *mem_base, int mem_size) { - int mem_align =3D (VCHIQ_SLOT_SIZE - (int)mem_base) & = VCHIQ_SLOT_MASK; + int mem_align =3D (int)((VCHIQ_SLOT_SIZE - (long)mem_base) & = VCHIQ_SLOT_MASK); VCHIQ_SLOT_ZERO_T *slot_zero =3D (VCHIQ_SLOT_ZERO_T *)((char *)mem_base + mem_align); int num_slots =3D (mem_size - mem_align)/VCHIQ_SLOT_SIZE; @@ -2334,8 +2354,8 @@ vchiq_init_state(VCHIQ_STATE_T *state, = VCHIQ_SLOT_ZERO_T *slot_zero, if (slot_zero->magic !=3D VCHIQ_MAGIC) { vchiq_loud_error_header(); vchiq_loud_error("Invalid VCHIQ magic value found."); - vchiq_loud_error("slot_zero=3D%x: magic=3D%x (expected = %x)", - (unsigned int)slot_zero, slot_zero->magic, = VCHIQ_MAGIC); + vchiq_loud_error("slot_zero=3D%tx: magic=3D%x (expected = %x)", + (size_t)slot_zero, slot_zero->magic, = VCHIQ_MAGIC); vchiq_loud_error_footer(); return VCHIQ_ERROR; } @@ -2348,9 +2368,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, = VCHIQ_SLOT_ZERO_T *slot_zero, if (slot_zero->version < VCHIQ_VERSION_MIN) { vchiq_loud_error_header(); vchiq_loud_error("Incompatible VCHIQ versions found."); - vchiq_loud_error("slot_zero=3D%x: VideoCore version=3D%d = " + vchiq_loud_error("slot_zero=3D%tx: VideoCore version=3D%d = " "(minimum %d)", - (unsigned int)slot_zero, slot_zero->version, + (size_t)slot_zero, slot_zero->version, VCHIQ_VERSION_MIN); vchiq_loud_error("Restart with a newer VideoCore = image."); vchiq_loud_error_footer(); @@ -2360,9 +2380,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, = VCHIQ_SLOT_ZERO_T *slot_zero, if (VCHIQ_VERSION < slot_zero->version_min) { vchiq_loud_error_header(); vchiq_loud_error("Incompatible VCHIQ versions found."); - vchiq_loud_error("slot_zero=3D%x: version=3D%d = (VideoCore " + vchiq_loud_error("slot_zero=3D%tx: version=3D%d = (VideoCore " "minimum %d)", - (unsigned int)slot_zero, VCHIQ_VERSION, + (size_t)slot_zero, VCHIQ_VERSION, slot_zero->version_min); vchiq_loud_error("Restart with a newer kernel."); vchiq_loud_error_footer(); @@ -2375,25 +2395,25 @@ vchiq_init_state(VCHIQ_STATE_T *state, = VCHIQ_SLOT_ZERO_T *slot_zero, (slot_zero->max_slots_per_side !=3D = VCHIQ_MAX_SLOTS_PER_SIDE)) { vchiq_loud_error_header(); if (slot_zero->slot_zero_size !=3D = sizeof(VCHIQ_SLOT_ZERO_T)) - vchiq_loud_error("slot_zero=3D%x: = slot_zero_size=3D%x " + vchiq_loud_error("slot_zero=3D%tx: = slot_zero_size=3D%x " "(expected %zx)", - (unsigned int)slot_zero, + (size_t)slot_zero, slot_zero->slot_zero_size, sizeof(VCHIQ_SLOT_ZERO_T)); if (slot_zero->slot_size !=3D VCHIQ_SLOT_SIZE) - vchiq_loud_error("slot_zero=3D%x: slot_size=3D%d = " + vchiq_loud_error("slot_zero=3D%tx: slot_size=3D%d = " "(expected %d", - (unsigned int)slot_zero, = slot_zero->slot_size, + (size_t)slot_zero, slot_zero->slot_size, VCHIQ_SLOT_SIZE); if (slot_zero->max_slots !=3D VCHIQ_MAX_SLOTS) - vchiq_loud_error("slot_zero=3D%x: max_slots=3D%d = " + vchiq_loud_error("slot_zero=3D%tx: max_slots=3D%d = " "(expected %d)", - (unsigned int)slot_zero, = slot_zero->max_slots, + (size_t)slot_zero, slot_zero->max_slots, VCHIQ_MAX_SLOTS); if (slot_zero->max_slots_per_side !=3D = VCHIQ_MAX_SLOTS_PER_SIDE) - vchiq_loud_error("slot_zero=3D%x: = max_slots_per_side=3D%d " + vchiq_loud_error("slot_zero=3D%tx: = max_slots_per_side=3D%d " "(expected %d)", - (unsigned int)slot_zero, + (size_t)slot_zero, slot_zero->max_slots_per_side, VCHIQ_MAX_SLOTS_PER_SIDE); vchiq_loud_error_footer(); @@ -2478,24 +2498,24 @@ vchiq_init_state(VCHIQ_STATE_T *state, = VCHIQ_SLOT_ZERO_T *slot_zero, state->data_use_count =3D 0; state->data_quota =3D state->slot_queue_available - 1; =20 - local->trigger.event =3D &state->trigger_event; - remote_event_create(&local->trigger); + local->trigger.event =3D offsetof(VCHIQ_STATE_T, trigger_event); + remote_event_create(state, &local->trigger); local->tx_pos =3D 0; =20 - local->recycle.event =3D &state->recycle_event; - remote_event_create(&local->recycle); + local->recycle.event =3D offsetof(VCHIQ_STATE_T, recycle_event); + remote_event_create(state, &local->recycle); local->slot_queue_recycle =3D state->slot_queue_available; =20 - local->sync_trigger.event =3D &state->sync_trigger_event; - remote_event_create(&local->sync_trigger); + local->sync_trigger.event =3D offsetof(VCHIQ_STATE_T, = sync_trigger_event); + remote_event_create(state, &local->sync_trigger); =20 - local->sync_release.event =3D &state->sync_release_event; - remote_event_create(&local->sync_release); + local->sync_release.event =3D offsetof(VCHIQ_STATE_T, = sync_release_event); + remote_event_create(state, &local->sync_release); =20 /* At start-of-day, the slot is empty and available */ ((VCHIQ_HEADER_T *)SLOT_DATA_FROM_INDEX(state, = local->slot_sync))->msgid =3D VCHIQ_MSGID_PADDING; - remote_event_signal_local(&local->sync_release); + remote_event_signal_local(state, &local->sync_release); =20 local->debug[DEBUG_ENTRIES] =3D DEBUG_MAX; =20 @@ -2775,18 +2795,18 @@ release_service_messages(VCHIQ_SERVICE_T = *service) if ((port =3D=3D service->localport) && (msgid & VCHIQ_MSGID_CLAIMED)) { = vchiq_log_info(vchiq_core_log_level, - " fsi - hdr %x", - (unsigned int)header); + " fsi - hdr %tx", + (size_t)header); release_slot(state, slot_info, = header, NULL); } pos +=3D calc_stride(header->size); if (pos > VCHIQ_SLOT_SIZE) { = vchiq_log_error(vchiq_core_log_level, - "fsi - pos %x: header = %x, " + "fsi - pos %x: header = %tx, " "msgid %x, header->msgid = %x, " "header->size %x", - pos, (unsigned = int)header, + pos, (size_t)header, msgid, header->msgid, header->size); WARN(1, "invalid slot = position\n"); @@ -3360,10 +3380,10 @@ vchiq_bulk_transfer(VCHIQ_SERVICE_HANDLE_T = handle, wmb(); =20 vchiq_log_info(vchiq_core_log_level, - "%d: bt (%d->%d) %cx %x@%x %x", + "%d: bt (%d->%d) %cx %x@%tx %tx", state->id, service->localport, service->remoteport, dir_char, - size, (unsigned int)bulk->data, (unsigned int)userdata); + size, (size_t)bulk->data, (size_t)userdata); =20 /* The slot mutex must be held when the service is being closed, = so claim it here to ensure that isn't happening */ @@ -3382,7 +3402,12 @@ vchiq_bulk_transfer(VCHIQ_SERVICE_HANDLE_T = handle, (dir =3D=3D VCHIQ_BULK_TRANSMIT) ? VCHIQ_POLL_TXNOTIFY : = VCHIQ_POLL_RXNOTIFY); } else { - int payload[2] =3D { (int)bulk->data, bulk->size }; + /* + EXPERIMENTAL + Makes more sense to me to have these as unsigned = things + even if size is an int (?) + */ + uint32_t payload[2] =3D { (uint32_t)(size_t)bulk->data, = bulk->size }; VCHIQ_ELEMENT_T element =3D { payload, sizeof(payload) = }; =20 status =3D queue_message(state, NULL, @@ -3710,12 +3735,12 @@ vchiq_dump_state(void *dump_context, = VCHIQ_STATE_T *state) vchiq_dump(dump_context, buf, len + 1); =20 len =3D snprintf(buf, sizeof(buf), - " tx_pos=3D%x(@%x), rx_pos=3D%x(@%x)", + " tx_pos=3D%x(@%tx), rx_pos=3D%x(@%tx)", state->local->tx_pos, - (uint32_t)state->tx_data + + (size_t)state->tx_data + (state->local_tx_pos & VCHIQ_SLOT_MASK), state->rx_pos, - (uint32_t)state->rx_data + + (size_t)state->rx_data + (state->rx_pos & VCHIQ_SLOT_MASK)); vchiq_dump(dump_context, buf, len + 1); =20 @@ -3817,8 +3842,8 @@ vchiq_dump_service_state(void *dump_context, = VCHIQ_SERVICE_T *service) vchiq_dump(dump_context, buf, len + 1); =20 len =3D snprintf(buf, sizeof(buf), - " Ctrl: tx_count=3D%d, tx_bytes=3D%llu, = " - "rx_count=3D%d, rx_bytes=3D%llu", + " Ctrl: tx_count=3D%d, = tx_bytes=3D%"PRIu64", " + "rx_count=3D%d, rx_bytes=3D%"PRIu64"", service->stats.ctrl_tx_count, service->stats.ctrl_tx_bytes, service->stats.ctrl_rx_count, @@ -3826,8 +3851,8 @@ vchiq_dump_service_state(void *dump_context, = VCHIQ_SERVICE_T *service) vchiq_dump(dump_context, buf, len + 1); =20 len =3D snprintf(buf, sizeof(buf), - " Bulk: tx_count=3D%d, tx_bytes=3D%llu, = " - "rx_count=3D%d, rx_bytes=3D%llu", + " Bulk: tx_count=3D%d, = tx_bytes=3D%"PRIu64", " + "rx_count=3D%d, rx_bytes=3D%"PRIu64"", service->stats.bulk_tx_count, service->stats.bulk_tx_bytes, service->stats.bulk_rx_count, diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h index 38ede407f4f4..4e3f41203bc4 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h @@ -184,12 +184,21 @@ enum { #if VCHIQ_ENABLE_DEBUG =20 #define DEBUG_INITIALISE(local) int *debug_ptr =3D (local)->debug; +#if defined(__aarch64__) +#define DEBUG_TRACE(d) \ + do { debug_ptr[DEBUG_ ## d] =3D __LINE__; dsb(sy); } while (0) +#define DEBUG_VALUE(d, v) \ + do { debug_ptr[DEBUG_ ## d] =3D (v); dsb(sy); } while (0) +#define DEBUG_COUNT(d) \ + do { debug_ptr[DEBUG_ ## d]++; dsb(sy); } while (0) +#else #define DEBUG_TRACE(d) \ do { debug_ptr[DEBUG_ ## d] =3D __LINE__; dsb(); } while (0) #define DEBUG_VALUE(d, v) \ do { debug_ptr[DEBUG_ ## d] =3D (v); dsb(); } while (0) #define DEBUG_COUNT(d) \ do { debug_ptr[DEBUG_ ## d]++; dsb(); } while (0) +#endif =20 #else /* VCHIQ_ENABLE_DEBUG */ =20 @@ -265,7 +274,7 @@ typedef struct vchiq_bulk_queue_struct { typedef struct remote_event_struct { int armed; int fired; - struct semaphore *event; + uint32_t event; } REMOTE_EVENT_T; =20 typedef struct opaque_platform_state_t *VCHIQ_PLATFORM_STATE_T; diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c index 1f849a09d854..22b988dcf436 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c @@ -151,9 +151,9 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T = instance) list); list_del(pos); vchiq_log_info(vchiq_arm_log_level, - "bulk_waiter - cleaned up %x " + "bulk_waiter - cleaned up %tx " "for pid %d", - (unsigned int)waiter, = waiter->pid); + (size_t)waiter, waiter->pid); _sema_destroy(&waiter->bulk_waiter.event); =20 kfree(waiter); @@ -454,8 +454,8 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T = handle, void *data, list_add(&waiter->list, &instance->bulk_waiter_list); lmutex_unlock(&instance->bulk_waiter_list_mutex); vchiq_log_info(vchiq_arm_log_level, - "saved bulk_waiter %x for pid %d", - (unsigned int)waiter, current->p_pid); + "saved bulk_waiter %tx for pid %d", + (size_t)waiter, current->p_pid); } =20 return status; diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c index 53d1819c6cde..dc18678b99a3 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c @@ -47,7 +47,7 @@ __FBSDID("$FreeBSD$"); #include =20 #include -#include +//#include =20 #include "vchiq_arm.h" #include "vchiq_2835.h" @@ -118,13 +118,24 @@ bcm_vchiq_intr(void *arg) void remote_event_signal(REMOTE_EVENT_T *event) { +/* + TODO: Linux puts a wmb() here. most calls to this func are + preceded by a wmb(). Refactor? +*/ event->fired =3D 1; - /* The test on the next line also ensures the write on the = previous line has completed */ + /* UPDATE: not on arm64, it would seem... */ +#if defined(__aarch64__) + dsb(sy); +#endif if (event->armed) { /* trigger vc interrupt */ +#if defined(__aarch64__) + dsb(sy); +#else dsb(); +#endif vchiq_write_4(0x48, 0); } } diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h index 72c362464cc2..d1cb9f1e1658 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h @@ -42,10 +42,10 @@ #define PAGELIST_READ_WITH_FRAGMENTS 2 =20 typedef struct pagelist_struct { - unsigned long length; - unsigned short type; - unsigned short offset; - unsigned long addrs[1]; /* N.B. 12 LSBs hold the number of = following + uint32_t length; + uint16_t type; + uint16_t offset; + uint32_t addrs[1]; /* N.B. 12 LSBs hold the number of = following pages at consecutive addresses. */ } PAGELIST_T; =20 diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c = b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c index cc8ef2e071f8..f33c545cea45 100644 --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c @@ -398,7 +398,7 @@ EXPORT_SYMBOL(vchi_msg_queuev); ***********************************************************/ int32_t vchi_held_msg_release(VCHI_HELD_MSG_T *message) { - vchiq_release_message((VCHIQ_SERVICE_HANDLE_T)message->service, + = vchiq_release_message((VCHIQ_SERVICE_HANDLE_T)(size_t)message->service, (VCHIQ_HEADER_T *)message->message); =20 return 0; @@ -444,7 +444,7 @@ int32_t vchi_msg_hold(VCHI_SERVICE_HANDLE_T handle, *msg_size =3D header->size; =20 message_handle->service =3D - (struct opaque_vchi_service_t *)service->handle; + (struct opaque_vchi_service_t *)(unsigned = long)service->handle; message_handle->message =3D header; =20 return 0; From nobody Thu Feb 3 00:18:07 2022 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 6A3CB198A3C1 for ; Thu, 3 Feb 2022 00:18:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jpzlt27Crz4djT for ; Thu, 3 Feb 2022 00:18:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643847491; bh=BKJgkjelQ+x3oRBFdzBxLqB0vQDdRYeLNjDepomMOqQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SZemhPimWJcEgFHM6mRRcx6+PSdZnJcV5Kf+NbxUMP9FeBHDH8s3JfBvnU0lVGaq7WLQtQ2kqDHfmD+oKo7RiS3DLKd+e8Ys3Ejmaa2vme6nTzsgvZLxDC417PLgPYqfh8o4gmpuVyMNBjO758qJK1ARTp7TiAOe1opwfvC25nRCnC48a9Oqj3zls6GHuzXsJH+3y98pKFPZ3ecECBI52lCSZ1ohxfIsqClDsmZ42oJBlzOBZepZGSvSIw3OYAi7p0H3M3TFwFxuTIQSJ5dctZPINZGupIdwkOG2DkEXyjcGDXWanV2xc7sHv12kMX7R+bIV8Ea7lsmuus71MOs2hw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643847491; bh=y7tkxRdBXFIYCBp8SGNO1OrQzL0ffP01Josuxf9utks=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OSm2I1aZQ06h0mtpqWPOVcrt3CK/p1YL13DTHTtGkSJ8ooUSiqqosSFzUz4wqDgQqceb3qv2eiC+8zd1GMKZENf7Heh6VDTSCtyhSCqCW3duso1GsXPy+k9sRWOHdb95Lu7h3zL7buTgvT6WgH4Lwgzp6jtIvdldna+xrbxGZKmHHbUw6PZt/eKyWHU7tIIub8H29iBSP91bTpcBE2j9ln62dxyErJGINnVWRd+6XvZ4I0JHuYMcgklh2uEP/ZaFxrFxVF5qqBym9ZTwen5IqZoXA+x9O+BS7g+9iSlXvBkd754lvj4tjUH2Z+yP1T5ronAbmGsyb0YtEhKqaQTxWQ== X-YMail-OSG: brMSYIcVM1lNzNs5raJcy0S4TslabX_eM2xShwiu0z5Oh5lltNIc3eNT5Mhk8h7 KVuI2jmGHK6AieMIxxdIky.fl4fDE.XaxkiQrsddSkLrzUmZuQZtYcho_z_qR_BoGC0j4szGskH6 _Z1Q8irXwnRR7U0xxL64WBX7MSZE9wAVMeKXDuKuQ2tdejgXKKKWeH8zyOn5h0uqD.pmIWgeN6em EYyBnfcmB_cecyY1rb3J.VEOV6cmrNiM0xfknvZtl.26ZB8VD5E9.QIcZxgHcwr0qvgMmakQSpGz .4.yMqv6WyC8nnSTTZCHAuxpOPX1oHSdxvuwY_cCxxv8d5KqvYE_J3j4C8yheuvyPadzG.3gt8bB GhFpA79x772mmYORm.Jk.y0jH0KS2DNO0gP_LKPE8ai5bbbDhsEgRUgpYrPher5LAUhvRophdRHx J3WAoGhn.GKDmOIkeb6MtOC0KhSc.OADqMUUe0YMCsIuUpjqbwgPW8ybXRh28BF.L5VPK472R5Bh G0yJ8IiTeQSSD9TYjm6n_zPIqUKBONrfVewFQO9_IE0KVCpJCINuvWtjZExJeyiA0QvOgJ.SJAuu n7XqxJxfNsda2.e8ujwqEB4N54Egmr5x0gojvUixqpsgg1.UPc6I86U0n6eWAarNH988l1vFWsCb NImUYTd85UEH_2XCkMSCcflObJEdyRTKRMNgNNQ8RliguK5ZkLhkGtg7NdP6W1UON.8sQR0XUm2I rU1o2k7Nbs.bDcNWzHxmDBCuTLhf1M0wD8kc2d238aH.F8e3.UK2F0yPTLQMf0kXDaEbkDQ7Tr.M ttR5e2uFkEh9YhhrIh.lzmAEOHNp8Ixridss5TzAsfuTZ1mVFu1UDYBuREwgqXhCdb1YbrcCebnX SZXu3h.ioEzc_11CewWeKdbU8Oevx.bhVRG7WZheVTNshW2j388pT1I3.3O5K87FlsfwNCLYy0rh CmqMYsb1ZfUpcVRCdaL8F5f4RoVleJL9sP9MIyOIwnSAtpyq20uNe.mGHv8A.JXSWBBVuzMJbvtL P7oG0y4hjNxGQRfaUeNFIxGnbOTKVu0L5RicnDks8TcgQp6kSs0_zfIAxIcWpZVc9Kd85Qr00MFh Qxft7l_xIv_c4tQ3uPUE.oddwA5Y.5qW0_2Msn_Z4i96h_O8ZkfDUy4pQzzBu.y3JMIE7KhNrJs8 U.k7VeVffjiAynWXTMIdjOfQ584hQpy41RgYbW10wSRgar7oneOxZDiEf3GoRR45T4xUmSG_xEfr ROAW8ryw7fSTU0fr6gO.pbyvbNTH01dc8fFJk_OPe4C1O1kXD8Z6r0BYCp32AMNzqGpSUiPrNpBd uvonc9LrUf633HGLJXb2LM.dYNkuP6QIgksq_OTZ0OT7R_Wl0XDDTtjnM5PPtZmEFvwKNE1Om27f TY8yVOo1XMXYdUrvNsKY1dDUCu1TA5z0e8QDDAIt9V4xNpiqaHvJR1eKhaJ.do8yL2IU6KXxdU9E 5sSsKJUvG31ybjUTpBOMeCOBaZaqxtADJJow700FyTJugftEScUNiKz4HpWH8.VuaWpE4ejK2OsY OcosqWcp24LyHfUIQ1IRpo.eeSEhLsc9AMsgXjote1mRXLP8n2D9BOmHU2Cx4LYrqWLLvl.SBIFD xqGF3ztgkQHvjNkIZPV2Z0q928V3imSVdMo2K5ZXIX.IyJfG.OCoOiWklfIbQroMGhiLhQMiDF1r goWndJxk0kqUI3h0cag9SVgeC_hRd9DWk2Hito14.tD3FkTlKFreISrvfqgd95D2961yQ9vC5sE3 nU9tWde5tgpu0M4uVYA06WGPkefu5WG6W7fjSDyLvGaVvLCyyF05TfNryD8CDCqauh3Qf2jP7j9j mQ4nBuOGhDXugYKyECvrnYg2x06ho4.0wUazotRnzuetLkFHPeFOnSCGVo.coXIcxbhqodguOdyK rUDb_dwWmETYkSBT4S_7LwjykvbAqw2IVEX6gd5RmGRWzC0FlX9Bdwf5b4_zsii9NoDhwQz42_rk 5CNB5EjaO61H77tBf8C.UtYwZzfBJsGutfj2wSQQz0XohrlofeIiU3T9nWk_YKyHw3V.Xn8nUkoE cY5m7TWLyHjh3zX7wddGkyLeD8kc2e5VjTEhkSUvCQ.nM_rE4pAzoexdC3PataWiZynA.WvTcL6N qyyGjh4zo3OlRA25u1NqYLfaQYkVK2MUtJmwfSi6VeZRe_3ZRbWVL1uh0mHNeXxj.L1Kis_jlymm ibxrvP4jFbmSWc7XpDN6HUO_4MdoI7QHpUwRgSY7BM4KPXtuxmTlFqQCOcM2JhHdqlGeoCXMINZm 8ucb6OAhoYz95uDMP X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 00:18:11 +0000 Received: by kubenode531.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 488bf3b7ef2755c8719911c42f977953; Thu, 03 Feb 2022 00:18: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220202223208.GA78110@www.zefox.net> Date: Wed, 2 Feb 2022 16:18:07 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jpzlt27Crz4djT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SZemhPim; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3575 Lines: 107 On 2022-Feb-2, at 14:32, bob prohaska wrote: > The latest Pi3 single-user -j1 buildworld stopped with clang error = 139. > Running the .sh and .cpp files produced an error. The .sh was > re-run under lldb and backtraced. I'll see if I can find any interesting information based on the "fault address: 0x5" and source code related to the backtrace reporting . > The output is at > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/lldb_session > along with the buildworld log and related files in the same directory. Your 20220202/readme reports: QUOTE The first attempt to run lldb-gtest-all-fe760c.sh finished with exit code zero. A subsequent try produced the expected output reported here in lldb_session. END QUOTE (You had also reported (off list) a recent prior failure where the .sh/.cpp pair did not repeat the failure when you tired it.) Well: = http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o seems to be a possibly valid compile result to go along with the run (under lldb) that finished normally (exit code zero). I can not see the dates/times on the files over the web interface. Can you report the output of something like a # ls -Tla that lists the dates from the original *gtest-all* files (if they have been preserved in some copies some place)? As stands I'm making guesses based on not knowing the time order of the files. > Hopefully it sheds a glimmer of light. We will see if I notice anything intersting looking at source code related to the frames of the backtrace for the lldb based failure reporting. The variable results for the (lldb) .sh/.cpp runs for the same file pair suggests possibilities like race conditions, use of uninitialized memory, use of deallocated-and-reused memory (now in-use for something else), flaky hardware. (That failure only sometimes happened with the .sh/cpp pair means that no processing of include files was involved: the .cpp of the pair is self contained.) I'll note that the buildworld.log 's : 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:899:21: current parser token '{' 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' is the exact same places in the original source code as was reported in other such logs for failures while processing gtest-all.cc . > Not sure what to try next. It is possible to build kernel-toolchain = and > new kernels, kernel-toolchain builds a subset of the toolchain that buildworld builds. I'm unsure if the buildworld completed building what kernel-toolchain builds or not. > if that might be useful. For now, I need to explore source code. > At present the machine reports > bob@pelorus:/usr/src % uname -apKU > FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #0 = stable/13-n249120-dee0854a009: Sat Jan 22 23:32:23 PST 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 = aarch64 1300525 1300523 Thanks for the reference to stable/13 's dee0854a009 . (This was still the "boot -s" single user context for the testing. Note is for anyone reading this.) FYI: the variable result makes the corrupted-block hypothesis less likely. You have seen the failure via the original files and via the .cpp of the .sh/.cpp pair. You appear to have had a successful build with the .cpp pair --and an unsuccessful one. Also no stage under lldb reported illegal instructions or the like. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 3 01:51:49 2022 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 26C2F198F1B0 for ; Thu, 3 Feb 2022 01:51:49 +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 4Jq1ql6wlzz3lRK for ; Thu, 3 Feb 2022 01:51:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2131poE7078817 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 2 Feb 2022 17:51:50 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 2131poID078816; Wed, 2 Feb 2022 17:51:50 -0800 (PST) (envelope-from fbsd) Date: Wed, 2 Feb 2022 17:51:49 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 Message-ID: <20220203015149.GA78722@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@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: <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> X-Rspamd-Queue-Id: 4Jq1ql6wlzz3lRK X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.59 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.01)[-0.007]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.28)[-0.283]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.98)[0.979]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4089 Lines: 105 On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: > On 2022-Feb-2, at 14:32, bob prohaska wrote: > > > The latest Pi3 single-user -j1 buildworld stopped with clang error 139. > > Running the .sh and .cpp files produced an error. The .sh was > > re-run under lldb and backtraced. > > I'll see if I can find any interesting information based on > the "fault address: 0x5" and source code related to the > backtrace reporting . > > > The output is at > > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/lldb_session > > along with the buildworld log and related files in the same directory. > > Your 20220202/readme reports: > > QUOTE > The first attempt to run lldb-gtest-all-fe760c.sh finished with exit > code zero. A subsequent try produced the expected output reported > here in lldb_session. > END QUOTE > > (You had also reported (off list) a recent prior failure where the > .sh/.cpp pair did not repeat the failure when you tired it.) > > Well: > > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o > > seems to be a possibly valid compile result to go along with the > run (under lldb) that finished normally (exit code zero). > > I can not see the dates/times on the files over the web interface. > Can you report the output of something like a > > # ls -Tla Done and added to the web directory as file_dates: root@pelorus:/usr/src # ls -Tla *76* -rw-r--r-- 1 root wheel 0 Feb 2 13:52:42 2022 gtest-all-fe760c-d2733764.o.tmp -rw-r--r-- 1 root wheel 7339473 Feb 2 13:18:34 2022 gtest-all-fe760c.cpp -rw-r--r-- 1 root wheel 5246192 Feb 2 13:48:41 2022 gtest-all-fe760c.o -rw-r--r-- 1 root wheel 4527 Feb 2 13:18:34 2022 gtest-all-fe760c.sh -rw-r--r-- 1 root wheel 1448 Feb 2 13:35:26 2022 lldb-gtest-all-fe760c.sh > > We will see if I notice anything intersting looking at > source code related to the frames of the backtrace for > the lldb based failure reporting. > > The variable results for the (lldb) .sh/.cpp runs for the > same file pair suggests possibilities like race conditions, > use of uninitialized memory, use of deallocated-and-reused > memory (now in-use for something else), flaky hardware. > > (That failure only sometimes happened with the .sh/cpp > pair means that no processing of include files was involved: > the .cpp of the pair is self contained.) > > I'll note that the buildworld.log 's : > > 1. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:899:21: current parser token '{' > 2. /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest-type-util.h:58:1: parsing namespace 'testing' > > is the exact same places in the original source code > as was reported in other such logs for failures while > processing gtest-all.cc . > > > Not sure what to try next. It is possible to build kernel-toolchain and > > new kernels, > > kernel-toolchain builds a subset of the toolchain that > buildworld builds. I'm unsure if the buildworld > completed building what kernel-toolchain builds or not. > > > if that might be useful. > > For now, I need to explore source code. > Ok, I'll refrain from idle tampering. > > At present the machine reports > > bob@pelorus:/usr/src % uname -apKU > > FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n249120-dee0854a009: Sat Jan 22 23:32:23 PST 2022 bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1300525 1300523 > > Thanks for the reference to stable/13 's dee0854a009 . > > (This was still the "boot -s" single user context for > the testing. Note is for anyone reading this.) > > FYI: the variable result makes the corrupted-block > hypothesis less likely. You have seen the failure via > the original files and via the .cpp of the .sh/.cpp > pair. You appear to have had a successful build > with the .cpp pair --and an unsuccessful one. Also > no stage under lldb reported illegal instructions or > the like. > > === > Mark Millard > marklmi at yahoo.com > > From nobody Thu Feb 3 08:05:42 2022 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 D011119B1311 for ; Thu, 3 Feb 2022 08:05:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqB7Q6f38z4ZY2 for ; Thu, 3 Feb 2022 08:05:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643875547; bh=ZzRCUVcw7zAW5ZPKS6VIZOU7qrA10niJx523tibii38=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mMs5/5OnzRyLONoZKiAuV5QXDqo0chrSNYM6XGyrM20tnnr/xL0fZlBPw140Z80HkiOgcv2+Q7u++aJ6A4bEuxbFA3z/ttI1YRF5b1W0Pv5S3BiQiU8paLrYyU3zLVxBvuL99OXY8dEtXdK4NihaR9EQzej29priXuI3XLs138wJMswfE2u3vpNsQYS2q56y8o7NhDfasoiaNqKph0bkfNHqdYwVF4253N3qGKVjRj5BBQlJ/LcEYhgl+dvZ7Qx/aLwO6Acqzft6BYKv3wtNNE80Jf1c3g6rGYCmeux8I9FBT+bVj3ZJTWCT6oLRSyk+geZhRkdIes1tCbdJDNqzBw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643875547; bh=ffc3CDFB9aNQjTfUMvpdz63iD7vuG2laSZLBbGNg/SQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cUxyK1E0d+1jXL5ahWDHBih+clOCk0P4gkCnXIbeOXiY5zcbeXgPatPENZsGTiT4xHKpdvDfy4XB/9J+Vh07czXsXhS8f3A8atJ11rPteOPgEA7+LbWCshzRODUoYinvpzeDCL75oVP6qeQwDdSaFDHDMLW3iBo4L4gxCn6hQUmonNT2IIzczQbsgBIyqxHmia/czDjKCnz/9/ptM+goVnahIQ8E1QhzZnWh0/7UWxX22DjS4Gu1bmmbA69xcE95QT88hVdI5sh8tsQKX5l9YkCZxRw5aIBMBPAta/8902jwPOxgL9P9g8nqI++Ti0+RDmfHy2exN+y5B3dvtTvqaw== X-YMail-OSG: Cy5Yj3QVM1m6c_stMC_xcHoi9HGB5kueuTbGXiYieHxUTpWSbsjCUmsz6XIRCpQ 5z8JbgZGVKuTkR7joLB6byUJaokgzmtnoDN6Au.BNXMjKYzNpaSvIUUZuvMjrfmQp9UH.ONjQHDN HReGE9xiPpihOtsLwn8d5WYXSBy3lqMh1QW4mpdugtrtv6B1gr7SLBhsJdm5yTve_AkFIHGcf0G7 emkA44pqvO5ftFMgQOb2YlhQJEuRFnyZditL33ZGyR07Cbn0JTz86XPFfGmlHHh50Ctz2xnVMHYi 5Mybi81CMz2hAHd0Nj4RhQtiWQIc9EE47InkYlss_1tEWusUYT6ViGD7idEGnBhkjT.zVCSoVIr6 _e7NRE7hKTH8vGDDkKqubHIPGukGojQe2sJFleJRDqi.fJYpz3P1JFkgyXbbpdW8bDCIUY3lE_rE Z41YMlp9SSijtOQz6cT.IsjHO_9Tqnz4C6oQi9oSb4GSHWAmTVd1EQSdhG5.kRXmYppsTX8TAFbK Xczp2AhOgIMzYP27hynOubWCcHM4CBsnM7yWQc1hjeM86cQClJZoSDLnJV.ZpoIAX9ecPIWFX0Eh 9PrSZIP9Z3_akvZHPVuX3HIHFtV5H72G5iQIIMS.mabQnrPPAYSXpyKuS51xJiE_b55RckylHPml T4AAwO2G3IDG6h57Iw4_8Jq0EbnfeAQeMKTwwSaRh7PRGHDCWwH2yvikGICkB133Wxor_uO2u5II teoiWKurS7zXWo_YQNvLgik8DnW73nBBGz.RWWsAAtiblLdP9F5V4PjheIst3HkbveXjcLOOS_6z hxn1_lKmHPsVnWUduE5tUBqOjm8SJKeUrX3MjpY9_hd9cXL1IWnzJK58yf2GC.IV7T3LyQZsryDA jbGUqPyvZdOkDNx0UJQuV65qIqYVqOxbBATtn9eZL397rSql8.Y1v_wn3cgdZOQazAbVX0WFBikv Z8zRtpHEyU0SwVMGzHFIH2_zeLEZWkEjBP9WEzkdtGTMPDw9ILsb0qfSLXN.T3zyMdg9j5USZ2Ck oOG9j2C3A2.kJgXlsp6dKFhXuQni8GLAmaYbviQkEk8LpsIsGfBolvv0_zU87pXBjp8G6EUdYE2L biHeBKhxpR16ZqGGTJeHTVdsClgiGvZyxvqMzSEfSb_Q3sr.w5BQHPNRZdcNz0XsQS11JiBBafan Yx8w5wLnnVXh9WsvxHYccOrX.VFieT8d9fF53O2m9gMVg3qq_skKKVdIWxMoZ26tPlhfWJqEujkk V0AqIE_21X_U938HpaULbaFVJ5eFKI635yHl7vgYeppzXwUTdAeB1FSjUrqLauLgIMShPzYkKaaL tZL74Edf9Ibdl0fg9FBbw0oSUC9RDLrrPkBuhO0bZKTWP23eLhgFj3RYSSEZVKemeQIL4.zn_1D1 xvGJiCeXXiXjlR77W1qanBQCRMJ9K3wpl6iLk1CgjZTRi8mqRmJEdcT9Qw8KYb8wb9nc79ptBN3B iCeOICBuzilGY9nC9QIw0h2MiOZTfL2DSMWggzy6DT5WTi53LSJp4vucH5LMUw7khV.T_.keZpLr fTvu8CdfhcvXH8FuussmYpWlDw3HXIgREf_mxoEZky6Dze4.WTRGnhdzR9De8RY_GZJV306ZV_2C V9I_KW6Do.h3z.PzIXYvn2oo7URXiuZkpFbbXZAXgvzjBOSVwOD0VPjHKVxm61TOyr2NGU7RyPzF ORfcresECQPMFlTlruod_8yomfEJIrtNolopcKJhXaqIcLn8EmZKCI98onA5CVKunYOUiVYsluUC Ev89Cg1IMGW0S3Lx2p32bjcv3NteOy0NJE.R8omipuQA6H7gCiEpwYlkVXi_wdvjVjEWNsWiTcjL E3xNaDzh_tO0B.U231SF_qg__dGJeKzZTETxTbqFu2aXGv2ulthG5dW7rk_QcVmufNg_vADR.V6I 0ZORMe4ce8PpAMV9gHD_xv1ZlFkIl3vmHj7MBPVMklLorF.bMCWgxkEAHdsYN4uJ1dKZqUG.plUq tjFUf7Vi_clEnh9rw2kXYGLB0UXwFLgnNqk815HIeFiBttSzkt3Ez2i8045.afREVnNwZr5IY4Bg lYcbkwoZBmUvH1Xa5Dh8QRov2EOeiom0U7o0ojvI0J5uoEWoQgGFQHiYBrQTmx3C7pXBfO0ulSKG nxsFivhcyfO_UbbVoPaMgRw_gLY5qC9ZV_6plNPVbBimDl.bRzFhb9iQF5wPZCkpfSTQ3.bm.uX8 mv5vuRB1hDrGCVpVXpMG2LC3BsYBsVlDegbaYchmI8G9T8iuUrNcmweQRsIA9ch0ZJCWfhM5RyeZ mdSonlfD3iAhp X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 08:05:47 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0132c7e51728facae89cff915a1ba730; Thu, 03 Feb 2022 08:05:42 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220203015149.GA78722@www.zefox.net> Date: Thu, 3 Feb 2022 00:05:42 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqB7Q6f38z4ZY2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="mMs5/5On"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.44 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.941]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5202 Lines: 148 On 2022-Feb-2, at 17:51, bob prohaska wrote: > On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: >> On 2022-Feb-2, at 14:32, bob prohaska wrote: >>=20 >>> The latest Pi3 single-user -j1 buildworld stopped with clang error = 139. >>> Running the .sh and .cpp files produced an error. The .sh was >>> re-run under lldb and backtraced. >>=20 >> I'll see if I can find any interesting information based on >> the "fault address: 0x5" and source code related to the >> backtrace reporting . Between the source code and the assembler, I've yet to see how the value 0x5 ended up as the address used. >>> The output is at >>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/lldb_session >>> along with the buildworld log and related files in the same = directory. >>=20 >> Your 20220202/readme reports: >>=20 >> QUOTE >> The first attempt to run lldb-gtest-all-fe760c.sh finished with = exit >> code zero. A subsequent try produced the expected output reported >> here in lldb_session. >> END QUOTE >>=20 >> (You had also reported (off list) a recent prior failure where the >> .sh/.cpp pair did not repeat the failure when you tired it.) >>=20 >> Well: >>=20 >> = http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o >>=20 >> seems to be a possibly valid compile result to go along with the >> run (under lldb) that finished normally (exit code zero). >>=20 >> I can not see the dates/times on the files over the web interface. >> Can you report the output of something like a >>=20 >> # ls -Tla >=20 > Done and added to the web directory as file_dates: > root@pelorus:/usr/src # ls -Tla *76* > -rw-r--r-- 1 root wheel 0 Feb 2 13:52:42 2022 = gtest-all-fe760c-d2733764.o.tmp > -rw-r--r-- 1 root wheel 7339473 Feb 2 13:18:34 2022 = gtest-all-fe760c.cpp > -rw-r--r-- 1 root wheel 5246192 Feb 2 13:48:41 2022 = gtest-all-fe760c.o > -rw-r--r-- 1 root wheel 4527 Feb 2 13:18:34 2022 = gtest-all-fe760c.sh > -rw-r--r-- 1 root wheel 1448 Feb 2 13:35:26 2022 = lldb-gtest-all-fe760c.sh Thanks. That is the order for having a successful gtest-all-fe760c.o generation when the lldb ran the compile to completion with a zero status result and later having the failing run. The gtest-all-fe760c.o content is probably good. >> We will see if I notice anything intersting looking at >> source code related to the frames of the backtrace for >> the lldb based failure reporting. One of the odd things is that the bt command should have reported a lot more frames than just #0..#5. It should have gone all the way back to main and __start and rtld_start . Another oddity that I've no clue about at this point. >> The variable results for the (lldb) .sh/.cpp runs for the >> same file pair suggests possibilities like race conditions, >> use of uninitialized memory, use of deallocated-and-reused >> memory (now in-use for something else), flaky hardware. >>=20 >> (That failure only sometimes happened with the .sh/cpp >> pair means that no processing of include files was involved: >> the .cpp of the pair is self contained.) >>=20 >> I'll note that the buildworld.log 's : >>=20 >> 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:899:21: current parser token '{' >> 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' >>=20 >> is the exact same places in the original source code >> as was reported in other such logs for failures while >> processing gtest-all.cc . >>=20 >>> Not sure what to try next. It is possible to build kernel-toolchain = and >>> new kernels, >>=20 >> kernel-toolchain builds a subset of the toolchain that >> buildworld builds. I'm unsure if the buildworld >> completed building what kernel-toolchain builds or not. >>=20 >>> if that might be useful. >>=20 >> For now, I need to explore source code. >>=20 >=20 > Ok, I'll refrain from idle tampering.=20 Without being able to replicate the problem and explore the context, I may well not get anywhere useful. And nothing about this is suggesting any sort of work around beyond building on a context that is not having the issue and then installing from there to the media that would be used on the RPi3* . >>> At present the machine reports >>> bob@pelorus:/usr/src % uname -apKU >>> FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #0 = stable/13-n249120-dee0854a009: Sat Jan 22 23:32:23 PST 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 = aarch64 1300525 1300523 >>=20 >> Thanks for the reference to stable/13 's dee0854a009 . >>=20 >> (This was still the "boot -s" single user context for >> the testing. Note is for anyone reading this.) >>=20 >> FYI: the variable result makes the corrupted-block >> hypothesis less likely. You have seen the failure via >> the original files and via the .cpp of the .sh/.cpp >> pair. You appear to have had a successful build >> with the .cpp pair --and an unsuccessful one. Also >> no stage under lldb reported illegal instructions or >> the like. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 3 10:52:48 2022 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 74DAE19B0A28; Thu, 3 Feb 2022 10:53:08 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JqFrN2TjXz4cYs; Thu, 3 Feb 2022 10:53:08 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643885588; 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; bh=Cf+BmybanCN5X1ZvHlYzfpUEtBPjlr+uQyQvoEVPxVw=; b=YgcfC5OkJD++sODrlHaGvRxVK0v7FhMvKO8Eo819FZD262vLMujtR2IMuLb29kMhKUJi94 LtQWIcpF4BKRAbP+faWeqdD0Yf8HSUCxF8hUgYZXFZNUkg/76AirvrEcwebjj4ZHUyjIFX vwXkBgTJIhlInLbdbF5Xsu+vu+qTYlyuElbzFu46tuPCDvdzhBkaeUYd7eE3WCfgynBGLi KqUXms1B8yj4xNpDtpndaxeTMPXTNC3Dd7qC/ENqRsyDjk35FGa8tsqTZJFYhbwZb10qxm ctkjSLquQpQKGQAsbE9sObkzGKa9YIKe/Yt7P/EuCV8+ytwIBrWLZwazXdDpeQ== Received: from [IPV6:2a06:4000:c189:1:1::2] (unknown [IPv6:2a06:4000:c189:1:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id CED3C242A2; Thu, 3 Feb 2022 10:53:07 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> Date: Thu, 3 Feb 2022 11:52:48 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 To: freebsd-current Content-Language: en-US Cc: freebsd-arm From: Jesper Schmitz Mouridsen Subject: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643885588; 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; bh=Cf+BmybanCN5X1ZvHlYzfpUEtBPjlr+uQyQvoEVPxVw=; b=RWWAw25JGTye8ILWRtt7o4raTLGYPGGQVrQS1KIyVw9noS81hqn2KIBoQKUkN/cdudUWHn /GUPAE1KVf9sRnqsW/02mOho4YcVIRcRRanE5ZM6A2Kt7yeDc368Pd0WcWvRZGHaW1YzvV ya/Z8sQMSRk5q8TLmBzYNTnb+QwflRxA6QNnFWIPPcQFRI0djDN6xW8eG3V7GhCL+OzRGI eTo2yUd/knKwnFnmzZW28N0CxvqIj5PPIiKtafBvoobvX05BerpHYD37v9mYhU+cFHXo5a heVpmM06sAVvUrfACAdKW291G80YkwNjuHZ1NzSaQCcLjVIfsg3iIDystKf0vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643885588; a=rsa-sha256; cv=none; b=BvP9qIIX60NhaZ7DLyTNmxZt5jDNbRHjH0EIBBGGKP6slPT5vtY7ixH/VentLH34ChXxqp FkvqCl1E83DC5u+I5oB/XOmzJPxqkx9DpRU3uGkgfVSO95OCbaT88PtdUoEXqwLNfQKQi9 K7TQhaivHpr6V2hJIlHEkv3ujRU0tGcXPJnmjwtuJAkST9IDhdm3+46XZ/+DJNeerAFafk gdeRbWddXFx84ORqeyI2K96TN3ig2Dry71RHF/tC9NZBO9QXc5rHU76t+W8ynmmwMHmyvl i3Cq+uBfJOOEZslOdc+6s3oF+vRaiZkILdDA4G8FfazIK/m/+79CgjA6eDo2ug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 702 Lines: 21 Hi d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c sys/arm64/iommu/iommu_pmap.c:50:#include /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of function 'UINT64_C' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) ^ ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' #define ATTR_MASK_H UINT64_C(0xfffc000000000000) How best to fix this? #include in iommu_pmap.c? Thanks /jsm From nobody Thu Feb 3 10:59:42 2022 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 8B8C219B296A; Thu, 3 Feb 2022 10:59:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JqG071Y0Yz4ffQ; Thu, 3 Feb 2022 10:59:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 213AxgJX016879 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Feb 2022 12:59:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 213Axgf0016878; Thu, 3 Feb 2022 12:59:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Feb 2022 12:59:42 +0200 From: Konstantin Belousov To: Jesper Schmitz Mouridsen Cc: freebsd-current , freebsd-arm Subject: Re: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Message-ID: References: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> 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: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JqG071Y0Yz4ffQ X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [2.73 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.945]; NEURAL_SPAM_SHORT(0.79)[0.787]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 989 Lines: 25 On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote: > Hi > d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. Which kernel config is it? Or is it your custom config? If the later, please provide it to me. > > grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c > sys/arm64/iommu/iommu_pmap.c:50:#include > > > /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of > function 'UINT64_C' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' > #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) > ^ > ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' > #define ATTR_MASK_H UINT64_C(0xfffc000000000000) > > > How best to fix this? #include in iommu_pmap.c? If the issue is with UINT64_C() only, perhaps something like sys/stdint.h inclusion is enough. From nobody Thu Feb 3 11:16:38 2022 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 8CEDF19BD2D7; Thu, 3 Feb 2022 11:16:40 +0000 (UTC) (envelope-from jsm@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 4JqGMX1sX4z4nDt; Thu, 3 Feb 2022 11:16:40 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643887000; 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=fLHhk3UuyXgerRlQwp1wBDR3QYvf4jqYaPqsSKpq9Qk=; b=TFU1szCT0xLTHvXncCu51HCTd4O07znBE+f4/oRclZQKyYudZDIwmbKPlGaIjWBq7LvSq3 /v5umwATUFKvZ1+A7MYtoFa5vCOCM42GJLS0u+IcNZPyVWlYkxo2IjoCITjj3hRe3j0TJL VRJhUelmkOsMi/PXKo+p0HIXE88/s8v05mJ3MQR/aNIScBD4iwHzaZByvu0079iFNF5Dxd agEbnAAfTph+D8DDiTgpJsVQL3OA4aaOY+nSxMAhPzE3tNw1pYtWoGwE+xV10MC9hDKzuh 3dTBHyg4mSFhljcyfr2d7UhqYarq8VZ9jqzKXD1C8OAJAfwJuxrzn3ARuUcrjw== Received: from [IPV6:2a06:4000:c189:1:1::2] (unknown [IPv6:2a06:4000:c189:1:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 92AA0239C4; Thu, 3 Feb 2022 11:16:39 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <42609179-f079-02c9-c57b-263467f70814@FreeBSD.org> Date: Thu, 3 Feb 2022 12:16:38 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Content-Language: en-US To: Konstantin Belousov Cc: freebsd-current , freebsd-arm References: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643887000; 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=fLHhk3UuyXgerRlQwp1wBDR3QYvf4jqYaPqsSKpq9Qk=; b=Mj7DzrR8gUnp/968UzIpxub8yJ/66JDlaBIpnhK3AKMkKIY1v7+wUGEr2k3PoSRIKXPFOR SfaPc1iYUrNJDQgjNsy9Lb9wUF1MbkxpP16XG93VQPmCMpX+CNb3DAl1WP2HPpK7C5Utf/ nFRLUn7OEKL9eh694eDSN50HYnBYbNbhBBQXXSX46v8VEmpsvK+FPY9s6aVBT+4n0oecK4 5wU452s1SBl+2/8jHWzp0MzEBTOIxEbvniL7NG628fTjwoubLw6JwYRKL68anuuVrx7ehH JUTgAwFviZAVkFr8h1gFn6PDLs4jXrUGDeP/6JODqt+JC++zcgfsI9b2jwH0Pw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643887000; a=rsa-sha256; cv=none; b=bu3v+l1hAuY+Ou5vaDhw9tF90JEhYw3W07iWGdALwtHONTZZn7wDbd/JUB/CWsiKcxgAF7 0Mk/Ya3DabXClQSLYD+pZpwbEMsZwTJtgCvyj89EDnQdtBpyDGEr6qel8yjWbmHUsBGvTw tBblA7Jkrq8XSsDVyPbtUOqQ1tp5uQRI8gGbAXwE1gCw0c7qkEhmyqax7C5XmqpHIDUdLk pPU7hDUF1VMAivv1SxI4TWwnfk3Y65YwaYSz6yQuaQnRltxgaPQLP6eZSg853nZy3WWobc 2BJ5h9wieVFCDwNd7JOhIdij8Uo93FWECjtPFiK+Dx1uRbMLefk7ZURw1MxVqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1128 Lines: 34 On 03.02.2022 11.59, Konstantin Belousov wrote: > On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote: >> Hi >> d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. > Which kernel config is it? Or is it your custom config? > If the later, please provide it to me. > >> grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c >> sys/arm64/iommu/iommu_pmap.c:50:#include >> >> >> /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of >> function 'UINT64_C' is invalid in C99 >> [-Werror,-Wimplicit-function-declaration] >> ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' >> #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) >> ^ >> ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' >> #define ATTR_MASK_H UINT64_C(0xfffc000000000000) >> >> >> How best to fix this? #include in iommu_pmap.c? > If the issue is with UINT64_C() only, perhaps something like sys/stdint.h > inclusion is enough. That was enough. https://reviews.freebsd.org/D34155 Thanks /jsm From nobody Thu Feb 3 17:17:06 2022 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 B936C19AB5FE for ; Thu, 3 Feb 2022 17:17:18 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqQMd4ZpKz3HgK for ; Thu, 3 Feb 2022 17:17:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643908630; bh=Oj5NkX73fOkLeaCYnXFzIpfVumNBTwyfWinXhgqVXmg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=K+Nc8Wid5V6j50CFAhntW4Gh/GWV6ZhMTEeBQVUAobI8EX2v8wkmNN6ednQP8zioktCK9KruiUbw3xl32IVqbeslctQL/+T70gXhqc6QhklmMjM9Qg87BDrdxnk40IqAPCt9Z0RUuU4TQ+UsgX2jSZFSzlewsym/oj09kc7OdH9Pjk/2SnH7J9xuXZqoU2nDHR7jQdnKywaRV5hCfB57+ngJKxKvtUqpWqljCamzPxfQ9Y9aTWIT3+08jQw1LmbofuK6ymSsEg3bhKBDZDAECprBDmSc/praiYufRVHWHMjtrb6b1kFndiaDw6p1NQ+HJu/dNDvYEnj9+YASpKopog== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643908630; bh=qRQboE/DJwmck9OHfyr3ctC2VdXdHPWhrj3hjDAl5uB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sMSu+gCDbFX10EvWxiMvUFBCjh3tCW+L8S7+KJ8vmhEXJKOyP+1f+E00cCSgDnWhk3SQveZ85umFtYOfsUSDQGzTlLJOC2NSyWXDFCho8Xupf9oTodntH4ReUiGL/MNNEkEN2PYq7V+iIOSYYjbEciCUAJfiFac9ehYPPzPb2C1ZcBGsrfu1Wo1SItmZb4X6nZ9RbXLRBpbBOEi0sRiQOdJDXANph5Nuwr3DpopLbsiMPdi4V6OUC3waddO5xc4vz4a+lJpa4afj30Q4rgj9nJHbczixl/sKpNK3Lz1ePzUBL+VjdBZsK61eG8nX9LnvKH34345Ri4iDbYraykiKAQ== X-YMail-OSG: iApgMhQVM1m9tYEwPK6VfWLZxA9SY2ygxiQxfFuR.rrvKMLTvdUQ248xMRzxhgl keMZJCg5zi9cYZdsuELCXM2_q5tGWIv4WfBVREtWfMHt1pqhBYtQSuth2S.ZY5eDzCHSHj6SRHpM u6ttimr9H9nFlF0ug5hxjM4kTbCafzhQoHz3V0qwyouPBSp_OoSGfMbhfNTaJqgCc9unS9EPtOJU AOzC0Aym5MzlPtcOGOo7Qo2F0Vj1QzZEuRsl0dNnA3565DlLCDqEIR.ueRCd3jJa3geP5_nNisGh lVNZMIy3iyP8_K6d.fUqWorFKX8hUG_7XO6EUaC_34z.75eIGNzsJ3HysssF5h11b__1FlDyQkI0 0hDXt.BCemx86x0XZpbDMqnXF0hQpECLO0_bTY_q4JgxJglTKdSeDeN2c_acjGPC8rmyZ6MqMEys zSmfmVELLpqm74_ffmouIq.xSnCuJsbn6iL_K4uke8Wtjn14lG7gIrJ9NpqtFPNivuBxbLZAi8Kx 8WvTf5BDX4VTUqEGQjdg0IfUcNOag4IJcl.qRbX9kUTEN9NJDYOEB29YCikFx5th9kEzgG4Rx2Q4 RYdia2H.JvTzpj_m8hfGmVlG90nZJaIvgtRWQu.DiOfOngLA0efMdctlpAP.H2jWS6XVx8eLfv43 q2Jgch6y.TIzmDU2BIZ8kwjRm4nY0XDLTjO4jU1UTT45L7fpdEiuB3CFCJdhC7YvLm4y5fQlPqhv iemd8yxE1V3oI2yM5FvMgA0dpC3YzcUdfRLp81JYB3svqJHd27FPpQV.ANhQSv2tjPTRfuBroogZ xFwKYMi0tk45XSESfRNq2SmkM7O3rdm21RT07Y.MeWvYj5RzE96By3pIf43A3.Z.PuNGHaa8FfcH .oP_DZxSvoGdIzRP15TOfP1PuNjGjzr1ykgINEhPrJjF5DUYPfbz41Yv1ZKzeftX6nbvpOGy11BC lTWy1RDBjC6.u6KQrsVawc5DWlbXwGgV99SsFYHKBs3sCOj2CafebN_4snU6rlMolSQ8U5WELmeS _ju0f5T.LMOF3i1FpBHSJJgUqU.m74kAGUTF5SQuXC4ZjdEUKpz7x4wHanqCCdh8OAWO.95xxLEV VP1cPbG1vfNCia26bKpUNhSqxtHrEHiqUbzWdf_d.gVNpf3.3QQqczDTKU9QV_sDxEyT5TcFHHBP zyWin9iytNgi5v1zRoD5cNQFuVexWimzPXkWHRu7lg3tcecUVdlDDLpqzwjlZXvYUbO.CH7kI2zX r5urlWEZ1EYS8yzfvDiLwz4m9G5rKA0Zuzl3ujJivsvaP49GFfgSeTOng_xALzGvzkrK.JcWQ52g mYlBAWfaktncve3m.9DS3erN4Crl4iVLyRFs9fZqscFOJfr3MWu788bke89jnreqUZnsGBRVfj93 _Cvx8iDub1Y..pUYK1I2C67Zt1jEe4GKDo_ZzuGV_5IT4h3hYpvcv8PzFkFyPgz8srhitDTUvlgN nyKuEhZMAkR_nG4nh4jQaP8kB4OLX6rddmaEbIOtgeIzfRrnVWVxywifqX13gaYcFutRcYqwGa3I .Ym4Hdhsp88rioB4IKZRbk38Zu7ENzKfGwliqi5zjn297A6lfemyocCvT5wewcdYvH_qhvi0B_RV TVarHgKbi.EOlvrNbt2.Z7dcsTjmVrQEz.zWY_pKbznxZSUDKGGkCgAzsY8YmJ9FoArebWuE6dTp TZXghQ3LxWk72v.fluIe7jHAFVif6VziXlF7hOmDwWkXTMxjT.Fn68VdUugBPqsD1s4xUi4Apxpb 1h.MvILHQqsJGCFkt9CrqDSn99ux3iZn53DPpvebZXXQWw7fYJfOMYIFH86Vn_sat3MbI2nEk9mC nAAQvUOr_hqDlQiYE8p_noe6kLHBSEj0tsHFz3na_4JvRzBWXTph1YDECmQwEp24SV44f2V40Yz. BLwzwnvbGeKg_bGEmNmwnJvBIa0yhNSJ_x5w5UwDGYOcjkpiwRzBZqt3snZfsMKYNrAPNBo6VX73 SiRmZSNeCsFLdusgcbgcAJIzugArGJya8NE9HfTujk2iGmVSgw.lPGuXfUR.u5sg43Zi59zYJ5ih yyyfbrSIqXWOosGGewagUmNQ0noLPWpGAYjB_M9kRUCkaZZLFlS32BPNfGUPHLv0c6U_NXTrnZ3D L3et.PEvkI8fE1rhkipoCfa9kC.ePUbH_JsRlpaCVdBBiKHLaV7jGHw0tycdAr2M7V01xQ14.5Pe qfzw_3IuZ.E_wJ.c3Az31u09uW273Koka2WcIkmXaZt3g5ocvx0Bin10etki.zYTgkS_S9ei4N.a uzPdXbsVwOx0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 17:17:10 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cc5ba7bccb206c0e551ee531618cbead; Thu, 03 Feb 2022 17:17: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> Date: Thu, 3 Feb 2022 09:17:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqQMd4ZpKz3HgK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=K+Nc8Wid; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.45 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.95)[-0.949]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5596 Lines: 157 On 2022-Feb-3, at 00:05, Mark Millard wrote: > On 2022-Feb-2, at 17:51, bob prohaska wrote: >=20 >> On Wed, Feb 02, 2022 at 04:18:07PM -0800, Mark Millard wrote: >>> On 2022-Feb-2, at 14:32, bob prohaska wrote: >>>=20 >>>> The latest Pi3 single-user -j1 buildworld stopped with clang error = 139. >>>> Running the .sh and .cpp files produced an error. The .sh was >>>> re-run under lldb and backtraced. >>>=20 >>> I'll see if I can find any interesting information based on >>> the "fault address: 0x5" and source code related to the >>> backtrace reporting . >=20 > Between the source code and the assembler, I've yet > to see how the value 0x5 ended up as the address > used. >=20 >>>> The output is at >>>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/lldb_session >>>> along with the buildworld log and related files in the same = directory. >>>=20 >>> Your 20220202/readme reports: >>>=20 >>> QUOTE >>> The first attempt to run lldb-gtest-all-fe760c.sh finished with = exit >>> code zero. A subsequent try produced the expected output reported >>> here in lldb_session. >>> END QUOTE >>>=20 >>> (You had also reported (off list) a recent prior failure where the >>> .sh/.cpp pair did not repeat the failure when you tired it.) >>>=20 >>> Well: >>>=20 >>> = http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/gtest-all-fe760c.o >>>=20 >>> seems to be a possibly valid compile result to go along with the >>> run (under lldb) that finished normally (exit code zero). >>>=20 >>> I can not see the dates/times on the files over the web interface. >>> Can you report the output of something like a >>>=20 >>> # ls -Tla >>=20 >> Done and added to the web directory as file_dates: >> root@pelorus:/usr/src # ls -Tla *76* >> -rw-r--r-- 1 root wheel 0 Feb 2 13:52:42 2022 = gtest-all-fe760c-d2733764.o.tmp >> -rw-r--r-- 1 root wheel 7339473 Feb 2 13:18:34 2022 = gtest-all-fe760c.cpp >> -rw-r--r-- 1 root wheel 5246192 Feb 2 13:48:41 2022 = gtest-all-fe760c.o >> -rw-r--r-- 1 root wheel 4527 Feb 2 13:18:34 2022 = gtest-all-fe760c.sh >> -rw-r--r-- 1 root wheel 1448 Feb 2 13:35:26 2022 = lldb-gtest-all-fe760c.sh >=20 > Thanks. That is the order for having a successful > gtest-all-fe760c.o generation when the lldb ran > the compile to completion with a zero status result > and later having the failing run. The gtest-all-fe760c.o > content is probably good. >=20 >>> We will see if I notice anything intersting looking at >>> source code related to the frames of the backtrace for >>> the lldb based failure reporting. >=20 > One of the odd things is that the bt command should > have reported a lot more frames than just #0..#5. > It should have gone all the way back to main and > __start and rtld_start . Another oddity that I've > no clue about at this point. >=20 >>> The variable results for the (lldb) .sh/.cpp runs for the >>> same file pair suggests possibilities like race conditions, >>> use of uninitialized memory, use of deallocated-and-reused >>> memory (now in-use for something else), flaky hardware. >>>=20 >>> (That failure only sometimes happened with the .sh/cpp >>> pair means that no processing of include files was involved: >>> the .cpp of the pair is self contained.) >>>=20 >>> I'll note that the buildworld.log 's : >>>=20 >>> 1. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:899:21: current parser token '{' >>> 2. = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes= t-type-util.h:58:1: parsing namespace 'testing' >>>=20 >>> is the exact same places in the original source code >>> as was reported in other such logs for failures while >>> processing gtest-all.cc . >>>=20 >>>> Not sure what to try next. It is possible to build kernel-toolchain = and >>>> new kernels, >>>=20 >>> kernel-toolchain builds a subset of the toolchain that >>> buildworld builds. I'm unsure if the buildworld >>> completed building what kernel-toolchain builds or not. >>>=20 >>>> if that might be useful. >>>=20 >>> For now, I need to explore source code. >>>=20 >>=20 >> Ok, I'll refrain from idle tampering.=20 >=20 > Without being able to replicate the problem and explore > the context, I may well not get anywhere useful. >=20 > And nothing about this is suggesting any sort of work > around beyond building on a context that is not having > the issue and then installing from there to the media > that would be used on the RPi3* . >=20 >>>> At present the machine reports >>>> bob@pelorus:/usr/src % uname -apKU >>>> FreeBSD pelorus.zefox.org 13.0-STABLE FreeBSD 13.0-STABLE #0 = stable/13-n249120-dee0854a009: Sat Jan 22 23:32:23 PST 2022 = bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 = aarch64 1300525 1300523 >>>=20 >>> Thanks for the reference to stable/13 's dee0854a009 . >>>=20 >>> (This was still the "boot -s" single user context for >>> the testing. Note is for anyone reading this.) >>>=20 >>> FYI: the variable result makes the corrupted-block >>> hypothesis less likely. You have seen the failure via >>> the original files and via the .cpp of the .sh/.cpp >>> pair. You appear to have had a successful build >>> with the .cpp pair --and an unsuccessful one. Also >>> no stage under lldb reported illegal instructions or >>> the like. >>>=20 >=20 Could you make a copy of the /usr/bin/c++ involved accessible via: http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ (possibly compressed)? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 3 22:05:38 2022 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 57D6E19AE656 for ; Thu, 3 Feb 2022 22:05:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqXmc0K0mz4YwJ for ; Thu, 3 Feb 2022 22:05:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643925944; bh=MtSBukTYZa2CNJIBpbZEPs1KWZJwIbf77YrI9RW3MV0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TttBiZnZsp/Zeo4hhxI9q//9LDsK2fqYQR2lhWyWlSUZXkZqcWouOfyYh/L3X/B4ADyCZdELcbQRLo4TtKV0W9dqz3Lc10pxemkk1LkC6Hw391emJ8K3gO8z0CE36aHByuyTjWapjAh85dxeORLo+WJX9aNzfxKJbzYuTfjChFNLNvxAUogxfW9l5h4Wkofmnw556VGR+QvWzdB+9d3vau80F7WQnoL5LfjELlVIJhaM3aApScvPl1IUBrUUe+5PBfL+Mb/9hNrzEwH7rRIe/rpW2HapXi4TCtv5UZq5IK6mDc/AAL9x8aUUfi/51XdGJLBzj6JvgVX9sOkbIytVVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643925944; bh=W+ItHyyIWB899fA7Hw5+B5Yai8p11rYaRbXOIqDpQ+/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ggJf2z6m8CIzEb5HnJ6VxhDZmkWAMqXofHqc/U9NcdqNclOhruF4KFXLmu1aHXaMY3QdvxJIfLuS8BMrlbtr7noDLCpxFPqALHb6Sjw1lEPDGhae/GcShHzUJBLf3op1geMrNB6S7C0r/SwekBN2p7vybxYWwLLrHkQfVwOHEU6IjMLMW9SPBgqFXscDyieiBA8GaZaKykm2euvegLjQPRwMaoxj3AEY6PtN7BN59u3PhyhX7I9GsP5GvzehWdMTRxCy0UzY9124GybYqbCafu1VF6ZoESSCSkBwMo2omAQNSUZt0J/snDL5xPc7ENNMUqBaqZ8owCnZsOrkUBnCVg== X-YMail-OSG: 5Rh2_EQVM1lBUvOtnU1DBIlMdoBLe1igC14ThUN7f202DkBRIVcOrxYjdC6F1G6 YOdUAf1fUL4m6rCl1OIGJs8jUjhP.G2BcSrPgQWQWIb6GWOMHWJ_4NEjyF5.Ijm0zmT35dIXVGig mYkZ6vQfVseTjs0v6asopLaZ6_Tqf67L4FoA_QTbKayCdEsTk2imsgV.5KLYbAOPuJ.uf7WLUnDC 9GCbaRqIpSesUjCzyhNxwdQovtdtddXZcM69BqjOFCoWvhAQVLMPd10I2S.aE.yK9yOBkSY_1S.6 VG.dcuOqtIthqGcb7etnG0avA0dQrWjYu5wrpRSBuc5dvSwY.Mvs8ZUqzheoBXh4PzSYU4.i5Ma8 duERgXBzb7r75vlwcQ_G5Ee3iBlqWk.ExWswhEgoKRXud1vncir8a0Zvxks_dHp3cn0auhIrAltR K4D0uIcuH8925bqOD1fN06WD4cXobGIqDi2CM8Ynpz17zgtWKKXR4q3k0V6RkYIodEahw9JIay5d DFQcRMd.6DaFP5X.HCrUTPaJCfInLTTayVgVX.5Ijd2n0dGPAch7icJbUDrCKHIibjy3Tps.c4b6 qcUSZHWVXLo_MjD9s8JJythi4GZmZf3ALXj_vukNM.SgHScwZSKtCjKM5aQYUllkXNewW8TqW7wj MhiZBfIypELesUv28u_phVmLOaziSwn1Po3OO7w0I3bWF_smvdZ8BouYyoW_NhfZ8g5mjNjFZuOE D5zd.TfH_UgFhqbuYjkutIBsa4B02izYl7B1GL_ByVqqxmiRysvKrUzDpg7quqHyd_yeqKWYYwiY PE2EMCMeJMIj_x5FoxyvtwBs93tETR5RT.1UZbpOyXsMtZoeHg53S7eyHi6qc1BKbUgES1YC26Jj FM843s06nG.hXQsHGLTep0p6bJR6Oqo0Pww77eJ4YGuCgKVWwQmrPqaaAEPiL94Af.lyZSZjO9WQ nqBQ032.OeEp4eXJigNzcE_hmBdJ3RrKh.mHj2quN5iBNxNHvr8WjHNcupEKYzSGISQrdItf_2pn AFy7T52IRhFak4GRizn7icIXJXNwEXMt0dad.An97fLjDdFRUVWtpCXCZWEaEdhgYRIZYM4guzis Tpw8zX1Vkj2oi4cC4C9tnLPvsYUvCakFOYf7B4fsaSMzEfOn6u6FHv6pKa8uhCPBWfFAkC8mZzMO 6RiBCGvDm.4oc77dRJuJqLlZHP7NSeZuXLTx_Vs.Gwiqz6X_mxfC2zIEPBDpaZ..KHxMvk_LFDOO .pL7RQJDkeNx80MbwGDye7EGS6jOtM6fwYsX2Wk6h3gAaG62QyaWmZrTj5oM9s47vfFR5LAI8usx EBPhgenPmHqr6Ox1tuwIPhhRBFFk2pt7kSUYE.xXfCKFLSDStZmfQ4y4PsMirnmR_C_Ro2P2qvk0 EvyE1RN8WZYdWfSs7LPT9E3WuT67sBPGdwyLt0TvTzw4sjdVz5tpgtYBnaIleYYGwuUI5vyQfNZM Bh.ybppgNKRO5JzCjD1kaRhUWPYFybcXex6CzynJr.x0Fre6TbjKFRIQ2Xo0azHHv6y6o66toxU. AS22QB4E2VvhaYgdWfMHuGVYQttpbixSCshgC0ga_9xD4cNhbRKbmZS.i4zTpPezjyDSOBEirBz_ NoZ_Nk1dOKI39HW0_nCs.Cf6ERvaJ2q8NzLumBevcqNrb8si1QbxWUYlK_wzzBNnFHlXsknZJd7i MqIJb8lL8Vn.U7LNZ56iKi2nfis13m3xy9psEACfEIJZhpWnQ0rxZDT7QxnZ9D4BsS5ToePT.SxP g2fB0RncFjJjIiirAtijGphBTWG4fQ2bkWIg81xSzkxzWAKvtH8s47iHRkRMuiMshwgyIqhXWW9F SeYMUtgabWho7LLrueLHaZqg1Hz7_g1Sq9uiRDxLIu__i9FlCprc2_b31NBDdxS9rEdG4Zcg0Pad VroBY0jHQZINk.aV02bB4DCe8_IkqBGwPGZFJm9VnkuXhMaYKveSBIP2cBAQFUxZAlJScgVMXxac yrhUB1hOrYrTa35Bn.x6HOuY8FDdWxgcd06mT1LlDQWr884nyClK4kopeT0xA0Zcg7AgjDIsxoEQ Lx6sl60qsWgbCLtISatCPg4mx_OoCVWsdhpT9YA8NjYk_DTYm1dlpeVMzlgMcHdXEe_KXmATyz7b jsSGwn_YGaXmqmOC6ERy6ZZrEg.CaQgqF.7udP4R9iii8ky7KukVFLYnHVBL9LXtIDNh0nb7yZBe qAQy2adeKLC_GSGYeMkI6ciIshM15MkveddA1jOc3wEQd6E6iT..yrCwJvaehdzHXISAhszBRRBK w2HODP6lBo25eDgMSQzFWzIPj0E2dJQBUBQnAh5S6a9b1gguJ2WmzyRstq18k_3rfsHFL0j_fPDC e6G1AG2i0ewGKOIM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Feb 2022 22:05:44 +0000 Received: by kubenode505.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 870a423e36fe7f386c688318942364bf; Thu, 03 Feb 2022 22:05:41 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: Date: Thu, 3 Feb 2022 14:05:38 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqXmc0K0mz4YwJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TttBiZnZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4779 Lines: 135 Note: I happen to use wget below. You might use something else. Also: where I copy the gtest-all-f3760c* from is specific to my environment. Note: The later steps presume that the running kernel and the content of base.txz that are used are compatible. Otherwise, more steps would allow setting up to boot a matching kernel under an alternate name in order to allow the experiments. It would be good to know if you get failures vs. successes vs. a mix via the following sort of experimental setup. The notes below are about setting up the experiment and exiting the experimental environment. The text is from doing an example sequence in my environment and so some details will be different for your environment. # mkdir ~/13-snapshot-txz-files/ # cd ~/13-snapshot-txz-files/ # wget -nd -nH -r -np = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz --2022-02-03 13:26:17-- = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz Resolving ftp3.freebsd.org (ftp3.freebsd.org)... 204.15.11.67, = 2620:11c:5001:1099:1337::4 Connecting to ftp3.freebsd.org (ftp3.freebsd.org)|204.15.11.67|:80... = connected. HTTP request sent, awaiting response... 200 OK Length: 170624152 (163M) [application/octet-stream] Saving to: =E2=80=98base.txz=E2=80=99 base.txz = 100%[=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=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>] 162.72M 9.71MB/s in 17s =20 2022-02-03 13:26:34 (9.67 MB/s) - =E2=80=98base.txz=E2=80=99 saved = [170624152/170624152] FINISHED --2022-02-03 13:26:34-- Total wall clock time: 17s Downloaded: 1 files, 163M in 17s (9.67 MB/s) # wget -nd -nH -r -np = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base-dbg.t= xz --2022-02-03 13:27:04-- = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base-dbg.t= xz Resolving ftp3.freebsd.org (ftp3.freebsd.org)... 204.15.11.67, = 2620:11c:5001:1099:1337::4 Connecting to ftp3.freebsd.org (ftp3.freebsd.org)|204.15.11.67|:80... = connected. HTTP request sent, awaiting response... 200 OK Length: 208227180 (199M) [application/octet-stream] Saving to: =E2=80=98base-dbg.txz=E2=80=99 base-dbg.txz = 100%[=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=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>] 198.58M 10.0MB/s in 21s =20 2022-02-03 13:27:25 (9.56 MB/s) - =E2=80=98base-dbg.txz=E2=80=99 saved = [208227180/208227180] FINISHED --2022-02-03 13:27:25-- Total wall clock time: 21s Downloaded: 1 files, 199M in 21s (9.56 MB/s) # mkdir ~/13S-chroot/ # tar -xpf base.txz -C ~/13S-chroot/ # tar -xpf base-dbg.txz -C ~/13S-chroot/ # du -xsAm ~/13S-chroot/ 2167 /root/13S-chroot/ # mount -tdevfs devfs ~/13S-chroot/dev # cp -aRx ~/c_tests/*gtest-all-fe760c* ~/13S-chroot/root/ # chroot ~/13S-chroot/ NOTE: As of here (until the exit), files outside 13S-chroot are not accessible and / references ~/13S-chroot . ALTERNATE-PROMPT# cd root/ ALTERNATE-PROMPT# ls -Tla total 12424 drwxr-x--- 2 root wheel 512 Feb 3 21:38:42 2022 . drwxr-xr-x 18 root wheel 512 Feb 3 21:28:45 2022 .. -rw-r--r-- 2 root wheel 1023 Feb 3 03:41:57 2022 .cshrc -rw-r--r-- 1 root wheel 80 Feb 3 03:49:23 2022 .k5login -rw-r--r-- 1 root wheel 328 Feb 3 03:41:57 2022 .login -rw-r--r-- 2 root wheel 507 Feb 3 03:41:55 2022 .profile -rw-r--r-- 1 root wheel 865 Feb 3 03:41:55 2022 .shrc -rw-r--r-- 1 root wheel 0 Feb 2 22:08:08 2022 = gtest-all-fe760c-d2733764.o.tmp -rw-r--r-- 1 root wheel 7339473 Feb 2 22:08:10 2022 = gtest-all-fe760c.cpp -rw-r--r-- 1 root wheel 5246192 Feb 2 22:08:10 2022 = gtest-all-fe760c.o -rw-r--r-- 1 root wheel 4527 Feb 2 22:08:10 2022 = gtest-all-fe760c.sh -rw-r--r-- 1 root wheel 1448 Feb 2 22:08:10 2022 = lldb-gtest-all-fe760c.sh ALTERNATE-PROMPT# #EXPERIMENT WITH USAGE OF THE .sh FILES HERE ALTERNATE-PROMPT# exit # umount ~/13S-chroot/dev #=20 It would be good to know what experiments produce relative to failures vs. successes: all one? the other? a mix? Part of the point here is to test builds from official FreeBSD build servers instead of personal builds. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 3 23:04:28 2022 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 C554F198F473 for ; Thu, 3 Feb 2022 23:04:33 +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 4JqZ4J5GHNz4vT2 for ; Thu, 3 Feb 2022 23:04:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 213N4TO0081845 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Feb 2022 15:04:29 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 213N4Tnu081844; Thu, 3 Feb 2022 15:04:29 -0800 (PST) (envelope-from fbsd) Date: Thu, 3 Feb 2022 15:04:28 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 Message-ID: <20220203230428.GA81336@www.zefox.net> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@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: 4JqZ4J5GHNz4vT2 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [1.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.73)[-0.732]; NEURAL_HAM_LONG(-0.19)[-0.189]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(0.99)[0.995]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 271 Lines: 16 On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: > > Could you make a copy of the /usr/bin/c++ involved accessible > via: > > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ > > (possibly compressed)? > Done. Thanks for writing! bob prohaska From nobody Fri Feb 4 03:31:40 2022 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 5699119B51F1 for ; Fri, 4 Feb 2022 03:31:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jqh0m1N9Xz4VYB for ; Fri, 4 Feb 2022 03:31:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643945504; bh=VGpX4O155J/X1fbMVuFmCzndqbWoghjBeOrY3Bd6JwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bX5+oXnOUQHmYNM8zGazs5nKYoPxJd74EVhdnM058g8tjFgsr2YPP2F82ifm1qOiQ46iRcF5pw96xeUXUQV3cHMG/X98d/weOZc1eJcqUH0xExaDR99wHGMPCz/vjx3RRleOEOTI4IrqSQA060lsd2fgVBT4BdA5lerJLvWw3buK4lVZFZIKzbu/qoZwreZEHKOI+kwBKqGrafHRWqtMlE3DgKAwkanTmiNdtJEWoTsQAzp4U1zhCFUevqVKpxmhkr9zNaUQWueMx0GILeMn3F6ItbVgmribj3C+GYibwMyrqqHEd8REZlLhqNzfPC4ghLtOKYAU9MmDPDT52lnuSQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643945504; bh=psh6nitOSJxYakGE5U93cVkXVd3pdWscwFAQYkHn0kg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SsVW+naZ1S8AC2GGxOzdMZJbacQd9p3oumybszRBwV8ls0logvBkr7JmdjuCuOVR/+P4uqpGbs3p2MlFMa4e5vmSAYQRtSSv38DBFFPWDaCg86bBHNI64j3wunG3uhqsENGAgXMO0euI7eCajjqTfYck5Mov6HKgTspIGRAd6a0G5wC2XmxBOqTUcH51EwsHLDI/jfRywBs8CzC/xo1XbFSezvYvxq3cp66hKnMuF9/cJeR7PECaQbsY+Rmyw4pQi5J8/1LGlAgXGIpY7DJMe3+Ie3P7/GfUW7zxXYuk/gyGQXwBzoxdRlflC3a2b+lladK9hjl3cDGj3Y6Yh6N+VQ== X-YMail-OSG: TdTwktoVM1mTTd45IGi7NISJtnRhRYQzt9mfCgAHSXjGaj9T_l9TCz1plGBA98C BbsuvC9Aq0CXKuEht8rU2V6OXjnA2xsDq.mmJtQTGMnfct33560.kWwI_wn80bMpODY2R4KVzXyS YIcw5Q9YsrsZtBtGFCgUMIfXxYKrWo5L8aGdI5PUcBVZJdtC6kv4gYKPPpk9EBTXorRC69rY9qqH bsZNEVKw4AERtECC0FSkPxMefCzGy04ZKNaT4eEntj.gUUZckWK.39WYRkh0ugH5K0ObkuEjRnId xF9UlCC5FHhOJyf3HqoTIs0C_58SPH5pOLtz0gnWDmZJ3ueHlNGJ96vRiwONPKa6V_kTBBl7eUX6 .y9HRA1ZlaFzJHm3izM1MmLxu1wbbWBXngw_ZMv5YpTfnzd5JjrZlYGxqmU_bfhCwRCcI0Kt4T9F Z4Q9qvIxfQU2LNgR1AtDqNuKMixNld4CWrhXqAY8f.yNZMXteVX0lpg4BDn4bl9mwuaYIQtqW5ZS GUA7VF_klYa7ncVEtyJjUg_dbHrEPxfWNwxxSZXO4xFgVsNvoSpCZhzmkg20XfkMLWpBRbQecrwm 4ut5AEzRc3dMk71dahuKmEfMnfzBBxhemgp2dsKq.sFZpK99unCVZw27sIg_iyWS28bNI5.FIkpu 6RqnBD_n2SoJP2H6T4u5zKp8DQPYbaaAyrFEoQEECQpKRrhbjjmnKi4C5INthVh1rP5Oo0CZHlQY QZbliRq4mX7wab2SR4yQHXr6j_F_DaylbHZVVU3ppk2MvVXVtONhblBnYJH5o9nep0L_13X4mOh3 BRFSJ4DUOg9n71vvzI4WA5WyXEPwjVygHmPtT.NyCZ1rITRpqzTYXs5SbPiQIKmPMDkhUfu9atIc 3CxkTptjVR0tCUtBzYTE3NYThPE2imhOhyvvcQLzRD5_doam4WlWboSmuxC.9Es8dtN3yz8TPEDj JIMeZqMqq70S3fyXdyDWwhlNfBuLwpj0P5.a4FqdJj3JWLkTrXaEhTjxuHU4OQwhSiK6q7CM3dv7 EL1f2O2_FkqbaDgA7ecu6Mi6hOv7Fyv4qBNd54Paq6cVzUEGCoCjyf_u0tHJl8A0tM91SnJJRJdZ astmvsA23JBH69rHEVmJqTXj87L1Jf0hBmL0BckOEtitR9aDCS0w3RGPmS3XRsNQ1YoUn.A2b8L0 wGmELn7DtiIKNqgdd31mt3vzKgeImmM.0NpZyN8CYB7NZufpfoZF1syr2mw4bDPQdy8n.d3_wD5x xP63ghsZVRmLULanuwHGgDp6buuYnE4oIm7BpWA4HPVgLupwoLt3byInCHie9LaMY3wqm8p80.yy rTnlYnhMeYjsUjJy1awpBhgKceueYbaW0Fdn2KNGMxZifbgSmUT9upCILsaoPATwFjJudP5CkJHe Y4Ga3aPuIAjoXI5N3xX5pZQLUAqGQ4PmlsYgM0i8x_U945idcC5hbGhgosId6CTSScTFbJ_gk7c4 829sJMFosRWq1dG6MvYaXZpNhh1c_dcRPh6m6YqIs31vncpsBKlJh7ThQYq5Q4_JT6Q0TffVu8T6 FvOZNdHWdv_LHykUlNV1zgJVzxll96ArgnTp0cb0ME09kV_si14FhaYcc.gtwJL44l2Pz4qjVl1q pz0pfyB8BSu6juj9fXMd2clu.Whqmedw15Hj8I1b_IUxCuzm2baynAkk1ggI8SssWOIfDh5rWGng sC0oCYKxFIhaxr9ujtxx4n4exakOqNV3VJOyVq8SqPmPAQN3Vd6Prze07JaOguLJelwfIpD.z1We AENblw4.vm7tzY7Sx7Hpb0MLKzecAeHskNMJEeQz5PjByfJsxy7Jjexp8gC0B3n322t6_nOxwYKF L0smTG.aaQTWeWyQcxz6aTY.3qAuIKyDhjBdk1PBhQ3IyIxlYuJghYHtgsDG_1MG497wAu1MjImR sG6tdP6EVycG0pH.2bTgNp6ZRrst0..neFAH7Gn6f5js2ndQH3gGckKraif29ewEDOUP9_uyaNFs 0AcJCbc8Q9tMxPtRv6pMnTV.3JLOdWCm_vtKieNFoxpwjx69ZBRpnUQkvq4n_GcZY3E8uv79Td7p obQGUfCCg_VVNv06kJ4hYNzXeLc1IeYtovQbD7nv1D8APwP7c3dvEjlY9W3WInigpbgB4S1XjHwV LTe1VSWZ3dHI_QAyoWwYRi32SuBddBbhkYo_9BsPL46FgYsk8W403DU2tj2b8_n1nn9aVDFUnsXk Bj5Aa4IRMgKmaN2a9gL.RcGalUCs9HSDo3AXUXQA7uizRZNsyM741ttDoNdrswWA_fKSZt7hvN0A ZTsfA0LvHfBDY5Lf9qNj_wm6aDcYtMp74Pp0a1Fmv6MHtJVXCBxPviIxC8EjDYyCZj3TAq2dyAI4 KCNAPlgOnG3nTDzSB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 03:31:44 +0000 Received: by kubenode505.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0683511115c27a6d6b00b9c3366547a3; Fri, 04 Feb 2022 03:31:42 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [problem replicated at last, not analyzed] From: Mark Millard In-Reply-To: <20220203230428.GA81336@www.zefox.net> Date: Thu, 3 Feb 2022 19:31:40 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jqh0m1N9Xz4VYB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bX5+oXnO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.28 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.82)[-0.820]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5716 Lines: 176 > On 2022-Feb-3, at 15:04, bob prohaska wrote: >=20 > On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: >>=20 >> Could you make a copy of the /usr/bin/c++ involved accessible >> via: >>=20 >> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ >>=20 >> (possibly compressed)? >>=20 >=20 > Done. I was not able to replicate the problem on a RPi4B with total_mem=3D991 with 2 GiBytes of swap via a copy of Bob's c++ compiler file. BUT . . . Using such a c++ copy, I was able to replicate the problem on the RPi3B with 2 GiBytes of swap. It had "fault address: 0x1" instead of 0x5 but was at the same instruction. It was the same FreeBSD media for both attempts, just moved between machines. (The RPi4B uses the msdosfs on the USB3 NVMe SSD for the RPi* firmware and U-Boot, not just the FreeBSD UEFI loader. The RPi3B uses the msdosfs on a microsd card for the RPi* firmware and U-Boot but uses the FreeBSD UEFI loader from the USB3 NVMe SSD.) The builds of FreeBSD (mine vs. Bob's) are different and the specific versions are different. In my tests, Bob's c++ is using the libraries from my build. In my environment, I've replicated the problem using Bob's c++ in 3 kinds of contexts: A) Use of that c++ under main [so: 14]. and: B) Use of that c++ in a stable/13 chroot that I built. and: C) Use of that c++ in a stable/13 chroot made via expansion of the files: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base-dbg.t= xz I used the main [so: 14] context for generating the notes below. Bob's c++ does not have symbols (is stripped) and I've no debug info for Bob's c++. So the failure for a run under lldb looks like: (lldb) run Process 1094 launched: '/root/c_tests/c++' (aarch64) Process 1094 stopped * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 c++`___lldb_unnamed_symbol39489: -> 0x2df7444 <+40>: ldr x9, [x3] 0x2df7448 <+44>: cmp x9, #0x8 ; =3D0x8=20 0x2df744c <+48>: b.lo 0x2df7ac0 ; <+1700> 0x2df7450 <+52>: mov x21, x3 (lldb) bt * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) * frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 (Absent debug information, the inline information is not shown. What is shown matches what Bob has reported.) For reference: (lldb) reg read General Purpose Registers: x0 =3D 0x000000004d769800 x1 =3D 0x0000000050320700 x2 =3D 0x00000000568aa8c8 x3 =3D 0x0000000000000001 x4 =3D 0x0000000000000001 x5 =3D 0x0000ffffffff9a58 x6 =3D 0x0000000000000000 x7 =3D 0x0000000000000000 x8 =3D 0x238f5fc5e23f2d85 x9 =3D 0x0000000000000002 x10 =3D 0x000000000007ffff x11 =3D 0x0000000000000000 x12 =3D 0x0000000000000001 x13 =3D 0x000000004d6f5de0 x14 =3D 0x0000000000000013 x15 =3D 0xffffff6bffffffff x16 =3D 0x0000000005116e70 =20 x17 =3D 0x0000000049a60dd0 libc.so.7`__free [inlined] = tsd_state_get at tsd.h:212:9 libc.so.7`__free [inlined] tsd_fast at tsd.h:337:15 libc.so.7`__free [inlined] free_fastpath at jemalloc_jemalloc.c:2793:6 libc.so.7`__free at jemalloc_jemalloc.c:2851:7 x18 =3D 0xffffffffffffe000 x19 =3D 0x000000004d769800 x20 =3D 0x0000000000517f9b =20 x21 =3D 0x00000000568a9da0 x22 =3D 0x0000000000000000 x23 =3D 0x00000000568a8f92 x24 =3D 0x00000000568aa8c8 x25 =3D 0x0000000000000002 x26 =3D 0x00000000568a9da0 x27 =3D 0x0000000000000001 x28 =3D 0x0000000000517f94 =20 fp =3D 0x0000ffffffffa0a0 lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 sp =3D 0x0000ffffffff9f90 pc =3D 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 cpsr =3D 0x60000200 (x17's information varied across my various experiments. So it is not obvious that __free being mentioned above implies much.) (lldb) up frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 c++`___lldb_unnamed_symbol47720: -> 0x317e784 <+3712>: cbz x23, 0x317e790 ; <+3724> 0x317e788 <+3716>: ldrb w8, [x23] 0x317e78c <+3720>: cbnz w8, 0x317e7a8 ; <+3748> 0x317e790 <+3724>: ldr x1, [sp, #0xc0] (That actually points to the line after the jump to drame #0's subroutine: the return place.) (lldb) reg read General Purpose Registers: x19 =3D 0x000000004d769800 x20 =3D 0x0000000000517f9b =20 x21 =3D 0x00000000568a9da0 x22 =3D 0x0000000000000000 x23 =3D 0x00000000568a8f92 x24 =3D 0x00000000568aa8c8 x25 =3D 0x0000000000000002 x26 =3D 0x00000000568a9da0 x27 =3D 0x0000000000000001 x28 =3D 0x0000000000517f94 =20 fp =3D 0x0000ffffffffa550 lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 sp =3D 0x0000ffffffffa0f0 pc =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 20 registers were unavailable. For some reason lr was not updated to the next level of return-place. I might see about if we can get a build of c++ on Bob's machine that has symbols not stripped and has debug information and that also shows the problem, probably not chaining the optimization selection. But I'll not deal with that in this note. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 4 04:07:56 2022 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 A535119AAF01 for ; Fri, 4 Feb 2022 04:08:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jqhpg4SZlz4jN0 for ; Fri, 4 Feb 2022 04:08:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643947684; bh=IUJN2HmaoqoRyQQpl6wGMfUzxIyQdiv+KMm4O8j4DtY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iPqZxUo2jawLfQ+KSQix28eGAhxjW4fwjlAIwMwp90ejxyLRItkI1QSdEzWUanmoNeUNKH16FqzY60OKZtZLQY4RA9UcI41mO7YlikUleKTGo0Y74w3mCdrZY9Xe+PAUYLp1OLICOkMRNnYBW9ycuHeYTj79mF5FOo7Cvz7B/FoUf1kQdLmnp4u4p7jc6u397cQ1dNHfjEOK/8UhwClEuNNTjqJ+8bcnkqFaWzDUJmnwhIrHNi8rOt2pheVGjw+tHEWMEVvDGbx7ESd2HYCOK5XELt/7HAtk4nCUp49Gt47cm/9JxHtWwtuU/5NC60nYNc5RIvs4pIUn0JGeIdA9xw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643947684; bh=up3WKhbePd2w8myAgRp7rH/TJ+vEo1Qgcp4W8Dl17R+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D1OxPfNMlCY3Edf1wAR9mkLvlEVpskrDKTQ+yVAtLRV7yHBCsd4uwuO3gv1c9efW/difVSpLyxJY8zGOePjGJ2Axw4KUxoc63UscD1TRhR8qS1NLf1IsmSHFESWGoaS8EqIXvGW7VQ3migC6z+Xr2G3vEds0EOoP/+65WZuzxyQrXCOOPNSLS9CwVpSdth7x3cR3uppfcCo2tsZ1Q+m5xiYkzpFfdodywGNOZqNnz2o6IIGXk/xXJ3LoZ9XNquITAZcD+u6+ol0FGzhOm4CwqLisYiTjEgiPVt1xj23hXiJSPCrneXtwI6SiXbFNTM25YEDLr15b9/Kcx1LNo8VHbA== X-YMail-OSG: dwTFomsVM1mwlo6v1wP.1S375YKxZE8DnRcA7MQ9WitI_oBuIvRFpTKWPvRRonQ ewYJ5F4_1Gu0b9pl2Xst2WOswAaaYrMzs2dYGMtqwFi3fE7mE0uOF2DSWYm4CbxCtLXpLHdYjz2H vR.f9.vN85zIaW6Cz05JdjN0lOj31MxkYJGs6ivSaK14MKw0oJdNY5.Iy3Ofh4iuyXXMiAXluuEn pzWaJR8NBa9ydiG89oRrI3rxCerfm8UIgTm_K1A.w7NbHq7fWrkwPIp4YLVJwhFitBq7mOVq7MJk tHw2AfruqbyVUwsDtMh4XVFjIBVaSAqYcEoJ3XBL2k6xx38Id923rB7lz.XoIuAPz.WbU60lIDpA plcve3BzENSHv2rNK_MDDbnJHzsxqaAz8averVk2xQMy43.z1oADBaghe7HmVh_AeTG2wgGjzjEp .Owcyr7ncqyYRI3u4jGcLbDJW8EwGKiCzWJ727XzyJGXTpv60lbXM05xjiEcDzA90EhDasfbj2Ai pJzbLy.Iir6NpBZP3n0obmiE5h2_cLVJmHzFN_rQyi_Xww3Xiygo8ihld.aZJ2zzPNjKeQG8Gj9O R.WPT0BUetDIRX1ujq5LC7XijspbnYnmS2X22_EyQkywtNsjy5beo0EgXMnE1Aj_jNLqzqW_B.zm s3HMikrmZuj7I6sJ5fXXL373AB1TVuRRruvqYVXt74C.wPT8IBDxyCTjQd5O7OJM5sL1Bh56fuCt Th2DiosxPV4CftPfnQDdTgTATFONRyiuQortbakQSbd7y.AmEsgMhTuQ6Py080xOeUUBpxLMYeK8 oxpCLoqXjqPEzhoZuAVEYcM.X8s.LidKn4xvwHS24zSTBl4iAYKCr.NDciJkAbWWZi3tukT2S82r T1wrlYYg9knYEmtAf3DeCojATfGBzwL6mTv5Mn.ApMchAUEXPI1T00CDsI2V0.wPx7JbOrCCHjOV O3CJ1txeH853xpDEw6JQDvj9kuuhEwM9q8SBafjsdm4doiqxoSFnPqOw7NhG8PDYWvbAeA4XhmX_ CPu0eNJRqcWUJA9z12CtqwcU.c1UPLPM0n5i0fib2A30d6n6Xf2IM8pGpi4Ua5ZjVCfxUwgptpQL VSFC9gT9fXPD.bU_F0UfKmMbUDY9.wuGYTPTJ0Ai7hOnrM1sIrBT9r9exHIGyAu0HSSIE58KCj9O Eb0nB4FN9QpMN80sUoSvbBIjyFB1rv4fOj7YBAmEIZ1Y3HQW3O1uvT0rTNaUuOovy7X9WO21zNrS rMvne8YA2Y6xvgvlVnWJKCI5G6GgLZSPQyu3yiAxUsqW6ukOqJly3NZyX9y0F3m2Tt5SMkTWUIaR iA4Hmu6XKrBCu5BlFKUXX41YG_Ynh02bkciKbzh4dLahl28EBwKjRigyT5BE79.hrkFJDko48gZR U1cjWrb2cC8j1DgSEioPD1TbZ9NmG9doYhFqPP6Kl7nESIgytbx9iFlu8LhVoWCr3SiHQAx_VpTm NW9xs8oDYH1qfhZQX06N7KxDB5Sv2in5.AqhtXqbuBxm0myK2uz0.a9fb36nZtal8nP4dvwWRgf5 F_i__z6.iS2.chOZEeu4hsQq5PCS5OhURHZW41kpETJF16aF5H9B5t8Ue2MBepfPG_0bSh9YAl2K .d.mHNjpjmk40x3ckBtfq5sayJW8XAAOZvO6TlxgTG5eKqFK02T9L9A1byvnJBnqlK_X.BnNgGyj LJYt3YR0Uh4j2ldj61Iwvd8K7uWGUZONKkOwXKuu1naLX53UJ9.Ka1T5gtckduYkswsvm7WFkIdw DGNjBmFK5WTtrOwzlQLOE6_JT6ApQQxmH2V3hzJ.IebBWqnhFHs4d8GtwPZP25G_ecokBDFv8f8N nVDBUjOMPSfXrmsThTJLj_NIwMuQ5j47bt7QSB9sJLvCikOZBK2pF4plH21zTlXyYNxVgiS_bHyH mqgMYF_w2GM7.y7vtSfttL_zUGkNvKvNOJGzDKVKV8CwbB3ElGxlP0guK.0Qszkve7ELPHwKpMRG TkgOSfikv4_7y.pOaRloOXDoQSjYkQC..kN90iSzJpK.wzImRwBXByiQxKWxryAEEnTbwJnXR2Ur NkM.K0D_Aam4SFG7Xf9aqdci.6AodL5CclYJLEjvjGPfediLSMUNay7MGb76qK9oJcqQKpHuFm2z 9gPTfeiiBt0M_eoHYfuV_azlL65_eETi6JcBYCsK4THxJq2I87V9TnosmnJZNTB10PwpYrb4Jznh B7lXOtMYZ0IGDRzRn6mTfSwC_3IAXKaDHg6N7L9F46kZXWCAScFPJedabGr.ezoQny1G6kUYiEyd x6utwjcmDqPkF X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 04:08:04 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ac836916f70751e75e224f4b7fcc19be; Fri, 04 Feb 2022 04:07:58 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [problem replicated at last, not analyzed] From: Mark Millard In-Reply-To: <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> Date: Thu, 3 Feb 2022 20:07:56 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F69B8AC-EE36-4FAE-BB46-30127C41E1E4@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jqhpg4SZlz4jN0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=iPqZxUo2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.08 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.61)[-0.613]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.965]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6260 Lines: 190 On 2022-Feb-3, at 19:31, Mark Millard wrote: >> On 2022-Feb-3, at 15:04, bob prohaska wrote: >>=20 >> On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: >>>=20 >>> Could you make a copy of the /usr/bin/c++ involved accessible >>> via: >>>=20 >>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ >>>=20 >>> (possibly compressed)? >>>=20 >>=20 >> Done. >=20 > I was not able to replicate the problem on a RPi4B > with total_mem=3D991 with 2 GiBytes of swap via a > copy of Bob's c++ compiler file. >=20 > BUT . . . >=20 > Using such a c++ copy, I was able to replicate the > problem on the RPi3B with 2 GiBytes of swap. It > had "fault address: 0x1" instead of 0x5 but was > at the same instruction. >=20 > It was the same FreeBSD media for both attempts, > just moved between machines. (The RPi4B uses > the msdosfs on the USB3 NVMe SSD for the RPi* > firmware and U-Boot, not just the FreeBSD > UEFI loader. The RPi3B uses the msdosfs on > a microsd card for the RPi* firmware and > U-Boot but uses the FreeBSD UEFI loader from > the USB3 NVMe SSD.) >=20 > The builds of FreeBSD (mine vs. Bob's) are different > and the specific versions are different. In my tests, > Bob's c++ is using the libraries from my build. >=20 > In my environment, I've replicated the problem using > Bob's c++ in 3 kinds of contexts: >=20 > A) Use of that c++ under main [so: 14]. I should have mentioned that main was a non-debug build (but with symbols: not stripped). > and: > B) Use of that c++ in a stable/13 chroot that I built. I should have mentioned that stabale/13 was a debug build (also: not stripped). > and: > C) Use of that c++ in a stable/13 chroot made via > expansion of the files: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base-dbg.t= xz >=20 > I used the main [so: 14] context for generating the notes > below. >=20 > Bob's c++ does not have symbols (is stripped) and I've > no debug info for Bob's c++. So the failure for a run > under lldb looks like: >=20 > (lldb) run > Process 1094 launched: '/root/c_tests/c++' (aarch64) > Process 1094 stopped > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > c++`___lldb_unnamed_symbol39489: > -> 0x2df7444 <+40>: ldr x9, [x3] > 0x2df7448 <+44>: cmp x9, #0x8 ; =3D0x8=20 > 0x2df744c <+48>: b.lo 0x2df7ac0 ; <+1700> > 0x2df7450 <+52>: mov x21, x3 > (lldb) bt > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > * frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 >=20 > (Absent debug information, the inline information is > not shown. What is shown matches what Bob has reported.) >=20 > For reference: >=20 > (lldb) reg read > General Purpose Registers: > x0 =3D 0x000000004d769800 > x1 =3D 0x0000000050320700 > x2 =3D 0x00000000568aa8c8 > x3 =3D 0x0000000000000001 > x4 =3D 0x0000000000000001 > x5 =3D 0x0000ffffffff9a58 > x6 =3D 0x0000000000000000 > x7 =3D 0x0000000000000000 > x8 =3D 0x238f5fc5e23f2d85 > x9 =3D 0x0000000000000002 > x10 =3D 0x000000000007ffff > x11 =3D 0x0000000000000000 > x12 =3D 0x0000000000000001 > x13 =3D 0x000000004d6f5de0 > x14 =3D 0x0000000000000013 > x15 =3D 0xffffff6bffffffff > x16 =3D 0x0000000005116e70 =20 > x17 =3D 0x0000000049a60dd0 libc.so.7`__free [inlined] = tsd_state_get at tsd.h:212:9 > libc.so.7`__free [inlined] tsd_fast at tsd.h:337:15 > libc.so.7`__free [inlined] free_fastpath at = jemalloc_jemalloc.c:2793:6 > libc.so.7`__free at jemalloc_jemalloc.c:2851:7 > x18 =3D 0xffffffffffffe000 > x19 =3D 0x000000004d769800 > x20 =3D 0x0000000000517f9b =20 > x21 =3D 0x00000000568a9da0 > x22 =3D 0x0000000000000000 > x23 =3D 0x00000000568a8f92 > x24 =3D 0x00000000568aa8c8 > x25 =3D 0x0000000000000002 > x26 =3D 0x00000000568a9da0 > x27 =3D 0x0000000000000001 > x28 =3D 0x0000000000517f94 =20 > fp =3D 0x0000ffffffffa0a0 > lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > sp =3D 0x0000ffffffff9f90 > pc =3D 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > cpsr =3D 0x60000200 >=20 > (x17's information varied across my various experiments. > So it is not obvious that __free being mentioned above > implies much.) >=20 > (lldb) up > frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 > c++`___lldb_unnamed_symbol47720: > -> 0x317e784 <+3712>: cbz x23, 0x317e790 ; <+3724> > 0x317e788 <+3716>: ldrb w8, [x23] > 0x317e78c <+3720>: cbnz w8, 0x317e7a8 ; <+3748> > 0x317e790 <+3724>: ldr x1, [sp, #0xc0] >=20 > (That actually points to the line after the jump to > drame #0's subroutine: the return place.) >=20 > (lldb) reg read > General Purpose Registers: > x19 =3D 0x000000004d769800 > x20 =3D 0x0000000000517f9b =20 > x21 =3D 0x00000000568a9da0 > x22 =3D 0x0000000000000000 > x23 =3D 0x00000000568a8f92 > x24 =3D 0x00000000568aa8c8 > x25 =3D 0x0000000000000002 > x26 =3D 0x00000000568a9da0 > x27 =3D 0x0000000000000001 > x28 =3D 0x0000000000517f94 =20 > fp =3D 0x0000ffffffffa550 > lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > sp =3D 0x0000ffffffffa0f0 > pc =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > 20 registers were unavailable. >=20 > For some reason lr was not updated to the > next level of return-place. >=20 >=20 >=20 > I might see about if we can get a build of c++ on > Bob's machine that has symbols not stripped and > has debug information and that also shows the > problem, probably not chaining the optimization > selection. But I'll not deal with that in this > note. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 4 04:40:41 2022 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 24C0B194CAF6 for ; Fri, 4 Feb 2022 04:40:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqjXP46Vpz4tDw for ; Fri, 4 Feb 2022 04:40:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643949646; bh=DJN8KyEKQxqBH2LjedufMQ9yxVZBG22E2HmzbQEk6ZY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YFY5e9iwQueD69QUanCsEKHsd97IioGuXvf1mahqXZRG2s2+nCXecOEi9Npoutfv2ZEs0DD86F59oKxcOwUBgaztLRVJN3J6sjbiV2Ge5Bw8bTHwzt59EiIUq6nlEFzAcY+gtB1FtbZ2AdrUdFPBcNfE2jmJINTQNcILiBj50ZhsOoDzmeQvKWVeYz0ysshbeHpVdC5hw2J2jx4Nj5H/bvNdrTgqWMLbwg4fKbPJb9C05AYxLE7Vk2iHD4A7g4MaNtzkA67vvlV7yaw19eEUHKAPPFqy0Vol2Bka83KklfIruR0hGVa+Zurymu5XoKJbz00nSKH4XUjC29dpGjcKzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643949646; bh=sA5ZHOQYkM2IFL47F4dWOAopUH4dleQWZf+ihjXCljB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iYGQgyLVNg7P3CvU9FHcAf6cBW5WgJsdLwhDHO+XcGRq23XvtDu/jRGAEE2dad5y2NRHEvV8H5pXqp1OzJ4pWM1jmlLD+RSPhHk74WvoaI+qdI+l9BRROORgTyV2Td0MUtLRAHC1UV6j0BTfD/ZV15OdL+1kqHgw4PsiLMa9/x5FDUEM4Wciat8RzgpUDmd8yV3xO512Y6KTnCZTrzIlEQV7KfX9b2WrDZrSKhRju4i59NoPI0ihmhTuOSlLrdAGXZrhOGB8+ISZgYbNR60+ZPLQotWlmTJjjn6sKFBSJPiKjgJpCj5Ligr/VChnnBH4GPxDhHxSD5ZXvtdH51wVSw== X-YMail-OSG: jzguRdkVM1nGdcUoxUnHi_Xw1U2.L_ZzlTQ1MXqAbxUprGWM1Y28JjDO3xbHEQ9 TaUAGsawWu3tJtAJ4bVZN0CGzQ3CuJU17TSkWQ.vAKxCfXPLYOUbtQdGbyRT8nAGAIXSS7TlsXM5 84bDKOF9xX_Ap_BcIj0_HKFEFSfekzofrPooy4J16UT2xuZwepSgT.KLjo_drCejVmw2y.uzjZHy g6.6YDKwA9IlPjV5Y0a1E58gpZh.ojRq_uDtv4elmYJKrt4uHSdcoFZm5ZmQYr4d4nv8UlilAuVZ aHbhvkSIC_g4_EFPb3QXh6yfAN4SU3R9MuAS8jpl55wD9mCqxreieAatK27t5Gsgkh9jT4t7lYFe dv2AteAigwQM2lVYg4mnSkFcH5rb_HGxKZrXkdB5t41AqwyfvZ7NPH8Un6cSCCKzapK86m4la1el TQpAdYsolhSpQvRvc0Fr5x0hda5liJwfV1AcDhngQhpzy7JjM78j9akj1RBJcUS.5SrYMHUury.5 Qkgc9Dgo5TCIhijc9cBnM2vOWhutJTz50cuUJTmiOSET0CjjEVzWpyasiO9wvG_GtCBR_Dsvfi.c Mu7tql4zYP41PGQFVpqxbrwP7pak_w8ESfPINrH5gACLLgItHRRpPNGwYNOII5otY6p2pFGQYYzL swRGFw_P1HLhsFJMMlyhDOQMhGyskRs7A5xxknzeeq0VxQNfQICmiNbGMxfYANQy3tw2CJsjAj4o UBy0qDkBdXOZFu9Un09lDJZ.nL9rdxBPHXdy8ENFm2wVjcB_Re8lB0WEpHMme8NHBki2.sbxnm7G D_SL6ELRiKpJTx5OPXmAP7abRUtxEoO_Li3tOC.04XwplbuhnIwiE7RNAzinYdClaRgFuPaK_xEK XV_WsAwnScOtK397uTZhRuU5qyZwi.lCvI1oOeNjHyfIUHG_Ac60pJkLzWNLF4iJPGOyhor1wuGs 6zP75_eimea5yXyKt0suQz8Ml18s.kAxMYmatcgDFJoucxJjan8kOKJOS7QbsTWKgY8RscVMWbv1 97_phm.1nzbKNplW8BUPtCu2dZ9vvlzszL219QARDdK72MJvL07qhgmPvM6hlAViF3VMA5n2iYgH 85czswvKcwmOO1c37sB9Jiq3Vd0W0va5XcyzUufq_EpbLz6NYbEvqHie3f5ULz5xgM.WoO6zGVIu vS8MhdXx4peM8DSjD0nJSO95IH1qX2ZkYuqS5lGyUVWv5cqeRdbM_Eg7Ik53IsKY0sn4El63urw7 4Hu4yLmyiGQFSIwni_ldkoUEFc0g1LMa3CeOF5wvi7cyN8kLVt0NXG_6ijQLifUTdIj_8ghpcvQe jSnVcU9xTMlKH6NJB2KH42NZJpjEqdWnMnuQR4w3q3tJyYwratxbjlr.fuD4RnlOveKetXzz12m. g6xJ9Xu2tu.M_VljCNuftt3HkNHhpsdeXiPNLuUqE4Wrz1LwHNoqdFzF7AzWBycEJGxEm6fY4vgS DNoYjUbdXptJ7hBQ4GhV8Iv_jZEwDSniCVNLwWVK.4DAlZS7KCxU2muEjpVHxRXNRJWTCBcjuF1E orxy87DU1Y2ZICb4fnh1f0c2NtlONZ1PwLV4Mcruk6xYaMWPzdm3UUq3mfxs1VX5s6lsn0pN9xQf dONHxk3XbW8zc160F3wnfaWcLINgvGRV._SgC1ueQepHXvGSB0v74c3ipJ763rGSDvFCU7KwcwrF NlcqEXp_1Zb7P9YF6PXY9Oos2Ogf.4ijaElTQHl2EOE.YS.LnyA2GS13waroV1.6ZtatcD51bSX4 TicPPlk1timay9PA7Qe49h.hZiejfnCXtso5SoqfqkhjEKasM.jwRwL5YhegeV_EBiSDn_4xKjlA 9kqLHr75mYHOZ8Sh7RAWq34dxu8bw7Ud.umQ96aiZtW09fMxYK0oEHeyf8srjKH_B7NRqK_b8x4a h._NZOFejsiHkB7bkAj.yRZPg4coC4uP51KUF4zCANqkOOZSNQSfw14G2DlhnfBkTGOoCp1rqd90 g5iqSKAwQ5_JXV61wrmVf9T2ai9oaUfVeArZAewRESrIrk_bhyr.b8aFpXOBageAlzQXnwa6MNTS b5V2twIgRp9nB7nRPTAeb9ZfB4bBK9Buic9HE5teCdSxdmniET_SJ.MI_LrRJK.lDsA8sXB9VF2X uAYU_yGs6kmOTkffKtSPHm5wEOmNrfeXEudIhqziTWUSBe3PVu4_FIcMDegU8OyHvjoPKquSQj54 L5gnAMFiVBdKudTsRGXsvZ.atDO_Lj6rBc1VShlSQcgAcHaYTaz_8AedrW6HdpFJJuIe_YsTIjHe Gxhl2Gtjf24oC X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 04:40:46 +0000 Received: by kubenode529.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1b9d5ee4301e754df082cde51fb0afb1; Fri, 04 Feb 2022 04:40: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <20220203230428.GA81336@www.zefox.net> Date: Thu, 3 Feb 2022 20:40:41 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqjXP46Vpz4tDw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YFY5e9iw; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1054 Lines: 52 On 2022-Feb-3, at 15:04, bob prohaska wrote: > On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: >> >> Could you make a copy of the /usr/bin/c++ involved accessible >> via: >> >> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ >> >> (possibly compressed)? >> > > Done. > Thanks. If you have a: /usr/lib/debug/usr/bin/clang.debug could you make a copy of it accessible via: http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ (possibly compressed)? Also, could you publish make.conf and src.conf and the like? --Any tailoring that contributes to how your builds run? Note: clang.debug is limited in its content to/by: DEBUG_FILES_CFLAGS= -gline-tables-only in . . . /usr.bin/clang/Makefile.inc . Otherwise the file would probably be GiBytes in size or some such --and building in the limited RPi3* context likely would not fit RAM+SWAP being (1+2) GiBytes at all. Still, the information lldb has available to it is limited, even with clang.debug . === Mark Millard marklmi at yahoo.com From nobody Fri Feb 4 07:59:12 2022 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 3E4DC19A0240 for ; Fri, 4 Feb 2022 07:59:20 +0000 (UTC) (envelope-from SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JqnxM36R3z3Gvx; Fri, 4 Feb 2022 07:59:19 +0000 (UTC) (envelope-from SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl) Date: Fri, 4 Feb 2022 08:59:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1643961551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=ny2QsfZ3q42+Rsh40GyQE0YTLDWl3v8+vZ7nIdJcgcE=; b=NgMECyYaF1s7qdjrcNsda+DXwTofW8S4TUMtI4NLeLQaTIGMF3qoO6FiEBDs/CvH+PHj3f pTc0oTg3J9971dEpd8e0Ois7uugo8riHlmWpunTUj81LCTn1R28AJeiqVtnzNrULpX859D Kuufx18/rh8ImP5iYcD7hIyY3PgAP0m2xEss0MOnj5q4H7oTHsIVOfE4iIsEgl7wB43Pd1 HUB3thJDHzZ6g8wwdaaaMcMsU3fxDX8Tr41k9xRrNphW0Wg3G11imUK0596BQxcnNja8D7 pEhqBk/K9ZvhBp0njzK5la1tdwKo+vqv5iA8GFq0iM8aeo19DQgLsVtXH8vGtQ== From: Ronald Klop To: Ports Management Team , freebsd-arm@freebsd.org, clusteradm@freebsd.org, Philip Paeps Message-ID: <1041004715.975.1643961552511@localhost> In-Reply-To: <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> Subject: Re: aarch64 build cluster and linux64.ko 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="----=_Part_974_807334264.1643961552505" X-Mailer: Realworks (593.17.fcaaf23) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JqnxM36R3z3Gvx X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=NgMECyYa; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.22 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.955]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.93)[0.929]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5792 Lines: 97 ------=_Part_974_807334264.1643961552505 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Philip Paeps Datum: 31 januari 2022 04:16 Aan: Ronald Klop CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team Onderwerp: Re: aarch64 build cluster and linux64.ko > > > On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: > > On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: > >> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded. > >> > >> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer > >> ======================= >> >============================ > >> ===> linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found > >> ===> Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg > >> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... > >> Cannot install package: kernel missing 64-bit Linux support > >> pkg-static: PRE-INSTALL script failed > >> > >> > >> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete? > >> > >> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded. > > > > We can include linux64.ko in the next cluster build for aarch64. I'll > try to find time for another cluster refresh. It's been a while since > the last one. > > I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko. The module seems to load. portmgr might need to do something to the builds to actually use it though. > > I'll upgrade the other aarch64 package builder when it finishes its current build. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > > > > Hi Philip, Thank you. 122arm64 quarterly build fine. 130arm64 quarterly is hanging in :sanity: for 48 hours already. I think it is stuck. Would you have time to check? Regards, Ronald ------=_Part_974_807334264.1643961552505 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Philip Paeps <philip@freebsd.org>
Datum: 31 januari 2022 04:16
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team <portmgr@freebsd.org>
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote:
> On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote:
>> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded.
>>
>> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer
>> =======================<phase: run-depends    
>> >============================
>> ===>   linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found
>> ===>   Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg
>> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...
>> Cannot install package: kernel missing 64-bit Linux support
>> pkg-static: PRE-INSTALL script failed
>>
>>
>> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete?
>>
>> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded.
>
> We can include linux64.ko in the next cluster build for aarch64.  I'll > try to find time for another cluster refresh.  It's been a while since > the last one.

I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko.  The module seems to load.  portmgr might need to do something to the builds to actually use it though.

I'll upgrade the other aarch64 package builder when it finishes its current build.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises


Hi Philip,

Thank you. 122arm64 quarterly build fine. 130arm64 quarterly is hanging in :sanity: for 48 hours already. I think it is stuck. Would you have time to check?

Regards,
Ronald


------=_Part_974_807334264.1643961552505-- From nobody Fri Feb 4 09:19:39 2022 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 24BDA19AC028 for ; Fri, 4 Feb 2022 09:19:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqqkL1fb4z4TB5 for ; Fri, 4 Feb 2022 09:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643966386; bh=3aBFvr6yfTB/HIvZwAKFOjf1OYsuURluo6FNAfo82rY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=r0erANS1ViwfYren+yKPiNnlJsqTHu7sqntragQ1w45e2utNJo2RvsBzqp13azYF0p5PBWlFih6QzG4Ea5A0A2vICrco7qE5MDIv8qOLx8JKF5L5kkSVPyWDJKcELRJfh4XZFb2XwiGSvQjOQkPHYHHh86x6eNg58l1TxkunEeVrBWaeVZxjVB5QTedrQcjbwdgLi/3bYRRYmYlykM/w5JLnOHouvXJkhEwDOgY7aUNAYV1myunvztoewcuzBv+u8tyNj3stIhlFerdCfvdKa/GZL58FEdxG6bntjAkg6L1RxQs8/BEkEXIztp3ne4n09J0ynnNkwnSX97hG3S0Szw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643966386; bh=RDnaD/vbjX03OzGsR7ACwIGL8uCeeGeXYeJFV+kMgLR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IpQ2jFsUX2H+b/BcS8uL8qEdum7ICSXWsuObIa2HVYGft9BO/Fv284W19fZINWGGOqf3d4QoU9a8uBC5nX2/8a+OqEcj8hK6KOgaS4QYK07nlgQWfF5L8SWldblIzISKbw/aiQr8Aoq7GOt+B4ymWLZOtO3jDVavBkQjDM5fA4RfJ3Q3fqP1IVuLpPG/4vRj5HucgkomiAuHBHFkolXmhI3w+v6yGCQ1zms8eC/okPH/UTuzI666NgIOI5hyOXtihyctvItF2pB5qaV2oBiwkaVdD+utK04VfOYJnsXdyF+VOJa8Gfo62WPU2jJ1lpwrjccX2yXPVSw5DxAoNpcjcg== X-YMail-OSG: hajUvsoVM1m61ptRiFLiBUJIjAEu0xwZc6dwQMeapzouW0b4ndlxA3GeE.78t9E SgMPVwr4siCxzoxPUV1kMlD2DooEDgaIyAkJ5sudzURzp4bgpOksQmkNct2JMIb3HaGM.ObHrrDY r_SDFNa58VcSZGCHj6ey.nAYiYp9VPxQSDqBcjR3eNY0uxOfmrWSL7bAEsmd61bbVlRQcpIb6Fvx JlP23jMjQQJLbO6i3yb0fdUTfRj6vlP8puvsTD_AAHHXgWa.HlrtsVoDUzXgUh4dYopLglWagKXR H9lVVOIG4sIf_NoKrX_7NkDXyQASuVz6.Nk9lsby6Ivnuq_LCyibUVPGU163UJjupLU10JCUf5Ml lPF1hUZnyBLULTVZ5Ffx1fQe3BhkV3JLW_LboaxYJcmPiY7CJZ1XphvMJ8feRt.NqC28LyCdZq7d cRG1WF5Yn7ge11mPSCdLggGURnYKdahn2fpxFK21FQ2JPAEFGCNxSLWC5opKSLoLi8q3QMwmU5_L o9A5klh.Ig6Hz9tzvq8TNbs5FIGQvGvl_AIakU9t7iFugi3rJ9M2TrVYEsLKlkbc4AZ5YpVtEylC oJEbcbT3X5yMhLAJyKngZ1DIn4Ckw55gNWngL9943Dc2dQxrlFm8jha7Atg_f25dNKfVrrjYdQDR m706HxTKdq_YxCH2xb_IVU_UbiIl.6_.lu.n3Dzfas15lbD_ETrNaae06H2lVZVEDPYKY8cod9km OfrnIhOEcti.Efed4jxjjdszWjXNC97SZV8fzDM7JsWu9ZRo3QfyCwsZ_VYPmAOoYJwSiAlvvjEp CkGTeVPc05BDVSDkYk67EkxgeBREAIHAQB5SDR5Wfuw.ChQpwqbkFy7QKkZALvrijaVTkQ1blGOG vEFPrj6sApPfp_EUKhOgD53m9l4vbTBw4iUfs.z4KMFiJrdS04wm38hQQteDfzQjqoxfHEfjdNu0 ZmzFhUzKPmGsNaXGFWqIZuDXXDQgnYoD2FxeWhOAaE48JxW0.H0n5BtnUQn0tgm3pNoSMXG2JKNw CSC0i1hJ1bdKwP.cCP_OsFxS19YhwHexHGne8R33rRrXCEPQyYJaGqGLrHcA4LqYTgsyqpfLf.2A Cvg5TAUMgdStiBiPrIz5ctqCuKa7tLq4R694UFNSg5YkgYAxX7ULnyTCN8G1YoO3OdrKeoMDJ.Zg J5ML1M3K77LDBkxCqYwJlM9DWCFK2x8OBG1zAGintfeZwYSnQPUkFJbknVst5GNApS_OBRHrKRC4 glNEyV9Y8mPpchrQLDCn68.TgQBVHan1xgv_hEnYC5HDz_6YtXBaI21r6ElEDAIxc3Mc4SKBwi8h sRZomClwhatLTAEJICyY1xIB5Xt7O8270.rB40AJsA5mlRSDsGvP5m0knbIdTL31jrAuC18N3alk 5KmEmk5kVxCI_Dx_V5uXDz0HZHza59v3TuiLqqMkbDpC6C.uJp8z02iacxByIwZBTWzTwPOBmgzQ KZ2DikLwvhsr8IbXCdtthdq72fI1B0sLteMERq0_2983nBIcHEL_iBlQpQbnhAlG776CrjPwCfM0 ivbUFRtFuhI.XTIsd8.MR.dJy4kNz.xOkrmbRECvoqnUUIloKpe.cQGGkRhx_woN5YirNRdkfNRi eWKND0PYbJNXnyBF7agrjN9XCTY2x3jFGOHgHd26HFlxGm20FCKUuG5uzfGI5VVpW8Qr04JL4_W8 Zu1VwrmQY9MnF5GKgHj7lR_NPaxvqA6h4zzscvRRJG1.UXTF97wxMuwDck87Q6muApETLs8lj8ni veZKYIoeWVspbkIWsGaB27CnemagwdFjiIMtE_77PMBXu7H0d9if8IVUf1ZkYmAeSnD6oRx4fiSY txfOoYkB.l7rgM5Gn59X1z7TJPyB_Usbmz7A6iawdBI70DcM2XGOknWu7KJCzxSxM87aPpAcv4WC p2XVoy6Pr40HjG8Mdf2k8Yfl0k09FeVjyV0wocqzXIanFUyesFjSuXrQQxA.scHA4un0DeVPnBmh Dan.TIBKSP02Lt.edpGk6j1tEt.au8W0vLNZBE76E5NyEu2..Vvw2JCKZO9JzUQWq9CjSvTj2UiT 11DoG5N6Z9cfKGOkDaU39y1PtuByX1gytj8AHH63NCRRszqYa25wD7frUGWimUWJiJl3jgEyuloM Gp9eoYj5xnw71lf4vS8R6AjAZje5Al0hYXHmSsiQgvAGfh3Uve8hb82A_hP8ssrQg6JL4zracso5 NX2nkYSb6ZBtOJIjL_LQ.iHEgaIfXI.bo0qkPbRUC74lX4LFnWuiz8WKoCBJfq8q8CoEJS9Jfw.1 89M9ZtT_iXs4P X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 09:19:46 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f2b0f969ab3954cbf220cc4574b08d87; Fri, 04 Feb 2022 09:19: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [Try sysctl kern.elf64.aslr.enable=0 for avoiding SIGSEGV using your stable/13 c++ compiler on RPi3*] From: Mark Millard In-Reply-To: <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com> Date: Fri, 4 Feb 2022 01:19:39 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JqqkL1fb4z4TB5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=r0erANS1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.02 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.367]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.847]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1563 Lines: 66 Note: The experiments reported are from a .sh/.cpp pair produced by system clang++ (a.k.a. c++) that is used to repeat the problem without doing a buidlworld . In my context, using a main [so: 14] kernel and your stable/13 c++ (system clang++), I get: A) sysctl kern.elf64.aslr.enable=3D1 leads to later tries = sometimes/usually failing vs. B) sysctl kern.elf64.aslr.enable=3D0 has so far lead to later tries = working This is with kern.elf64.aslr.stack_gap being 0 without my having set it. WARNING: Doing (B) may have security implications. stable/13 also has kern.elf64.aslr.enable and the like from what I can tell. You can let me know if you get any .sh/.cpp pair(s) failing vs. if all tries work. I found this by noticing that: sysctl -a vm.aslr_restarts was usually incrementing by 2 during the .sh/.cpp runs. For reference: # sysctl -ad vm.aslr_restarts vm.aslr_restarts: Number of aslr failures Something like: # ./c++ -v it got an increment of 1. Something like: # date it got no increment. I suspect only large processes would get failures, especially double failures (or more). It might be that a debug kernel would panic, reporting a try count that was no longer <=3D 2 if some of the code I saw is currently in use in the kernels. I'm running a non-debug kernel and, so, do not see the KASSERT related behavior. I do not have detailed knowledge of how the failure works. I'd guess some sort of stack-growth related problem that is leading to corrupted register content afterwards. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 4 11:05:44 2022 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 18A5119A5247 for ; Fri, 4 Feb 2022 11:05:50 +0000 (UTC) (envelope-from philip@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 4Jqt4Z01Yfz3hZB; Fri, 4 Feb 2022 11:05:50 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643972750; 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: in-reply-to:in-reply-to:references:references; bh=NIvun3QJ35cNLRf5dNRzh+2jANXJaO/k5szopZu5I5Y=; b=VRL4BjaFRtwdJGk2qMPiO2QZTcR7wuPtK+m7wGThjoagnwvoV3RJWJeZ+2SU2GT0jhf64C P4roNIWagKXMuaxFrzgXRGsR4D4t/Fce/6+UYIQxKjJqy91yJuDekQARMh3vCTUIEaNFYn jpx6syAq9JSqlxHrOq+YJ4Jf8ExLd4GuNe8jVOTC14Z4efAeOCUmw/NQBGcPbBlgWAjp+4 WIukeRKKF6NAcHfu26GjOZeNZIQfi+iL+MrIfVZnAbsLTrogCebgUeZ+US0hbMA7PiqWDI oPYM4YHFg+SPiTOBq+pohTFVP9h8jePMoJons738V6WFMhUUqrEdkIisG+1s8A== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id CAF0D2FE6F; Fri, 4 Feb 2022 11:05:49 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id AA00D27C0054; Fri, 4 Feb 2022 06:05:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 04 Feb 2022 06:05:49 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgeelgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkjghfgggtsehttdhmtd ertddtnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcuoehphhhilhhiphesfhhrvggv sghsugdrohhrgheqnecuggftrfgrthhtvghrnhepjeeluefhjeekteetgffhveeftdeitd ehkeeuvdeuveefvdfghfegffffheejtddunecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepph hhihhlihhpodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiiedviedv geekqddvfeehudektddtkedqphhhihhlihhppeepfhhrvggvsghsugdrohhrghesthhroh husghlvgdrihhs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 4 Feb 2022 06:05:47 -0500 (EST) From: Philip Paeps To: Ronald Klop Cc: Ports Management Team , freebsd-arm@freebsd.org, clusteradm@freebsd.org Subject: Re: aarch64 build cluster and linux64.ko Date: Fri, 04 Feb 2022 19:05:44 +0800 X-Mailer: MailMate (1.14r5864) Message-ID: In-Reply-To: <1041004715.975.1643961552511@localhost> References: <1041004715.975.1643961552511@localhost> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643972750; 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: in-reply-to:in-reply-to:references:references; bh=NIvun3QJ35cNLRf5dNRzh+2jANXJaO/k5szopZu5I5Y=; b=yAq3UEuQkLDfER0hgJqj7u9t/3dB/EDl0wM65fVpE2J9WvcIMTUEWRrffXTjLBRZXCWe1v UMotm//RELonhPRmYRW/vAaB1DXsmsvd8Fz9ERxL1pCtsV5j/YGVWRLm9bAh7zK1JCFh0m 5BX0srIh+LqGfyY9Xl6iIhr8KkF6f6KEDIt6JWmEeaxjRj5QAW/zbj/GqUHVYKGqf/lZpr y+2fTBaUxIxIf67Jg7D8izrtKg+uKusYFgObnKJY8IKgLVoSQWGrxmJ6ZOOu9CE2ohtuII 8tEL4HSlnyDs7u6g8+FnPRAU/Pi1IWA4QWCW5Ut4ppRNJ7cYUlotrEKlVGqwiQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643972750; a=rsa-sha256; cv=none; b=FZfKfnqZ51E6m+C9UJlIcoYJzCcMYQd2j/ZTgHc2fn4uv3yJCN9WsrkrVOxpqJSBgNhf+O nNgRXf+TCo4xiBxOYcKZJ1qBx7cn6T1e/DF9fvqpj42WxQ958uyKxkAoQ97mQy010BKs7A SmFIjhKBy5nvOfLduY2gUCjs9LeivWztxZWI2hJ+7b4jaVlCKwikKixXk50CQ63RPXkU1d WzKrwAyl91JahkXC0mnp3e9xU4Rv+hMm4UwXBk0oN78dXYx9sCo65/yizNe90FNeRJI2Xj yPwj9v+jCFx0g2Zmu/9lYkuNx7dcCcojVLjVZ7xGPDHZxbtCw3G91HMYDkM1GQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1003 Lines: 27 On 2022-02-04 15:59:12 (+0800), Ronald Klop wrote: > Philip Paeps wrote: >> On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: >> I've upgraded one of the package builders (ampere1.nyi.freebsd.org) >> with a build including linux64.ko. The module seems to load. >> portmgr might need to do something to the builds to actually use it >> though. >> >> I'll upgrade the other aarch64 package builder when it finishes its >> current build. > > Thank you. 122arm64 quarterly build fine. 130arm64 quarterly is > hanging in :sanity: for 48 hours already. I think it is stuck. Would > you have time to check? If I understand the automation/scheduling correctly, ampere1 started a new 130arm64 quarterly build while I was upgrading it. That build got stuck in :sanity:. After being upgraded, it started on the next build in the queue, which is still running now. I believe it should start on a 130arm64 build after this. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises From nobody Fri Feb 4 11:49:56 2022 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 ADEC519BEB8C for ; Fri, 4 Feb 2022 11:49:58 +0000 (UTC) (envelope-from SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4Jqv3T483Fz4VSJ; Fri, 4 Feb 2022 11:49:57 +0000 (UTC) (envelope-from SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl) Date: Fri, 4 Feb 2022 12:49:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1643975395; 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: in-reply-to:in-reply-to:references:references; bh=Tr59TTsMV0bY6DyXrqGV9si7t/CBKkuY9VygdWf5i1g=; b=zznSqZ8/5hyT1DuEXdsp0ukSuhABmY2CfxOWoMpmOnEIm3YL9sVXymlpf0/cjGoSTUE7xQ jgkzhcnZg3lWHFtOgwjqI6xe2ZvCcOUBOFZsCEd2m3M7fLxwDsOBEiGTpuuQLpDnO5P5zq tftqi5fKsBqBWqHWa7HVQzQxEQSGIEiXYFVKfo9+TSiHq+6iN+jDb/h53hyvpqH4SLWLgF TK67CtscTDhq89tY2H2vG3K9EThJf8NxkzOfQPdQzmW1pi41Xjg8eYRcYeFcKqGhlXrbII VEvLGvUhh5lzgvphJecWI/8KeJqaPHaVfQLLcqOLqiZW09iAh2R+SiR4QYZIEQ== From: Ronald Klop To: Philip Paeps Cc: clusteradm@freebsd.org, Ports Management Team , freebsd-arm@freebsd.org Message-ID: <1414783579.189.1643975396033@localhost> In-Reply-To: References: <1041004715.975.1643961552511@localhost> Subject: Re: aarch64 build cluster and linux64.ko 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="----=_Part_188_1079252898.1643975395742" X-Mailer: Realworks (594.12.ee219b8) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Jqv3T483Fz4VSJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b="zznSqZ8/"; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=vdMV=ST=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4420 Lines: 89 ------=_Part_188_1079252898.1643975395742 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Philip Paeps Datum: vrijdag, 4 februari 2022 12:05 Aan: Ronald Klop CC: Ports Management Team , freebsd-arm@freebsd.org, clusteradm@freebsd.org Onderwerp: Re: aarch64 build cluster and linux64.ko > > On 2022-02-04 15:59:12 (+0800), Ronald Klop wrote: > > Philip Paeps wrote: > >> On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: > >> I've upgraded one of the package builders (ampere1.nyi.freebsd.org) >> with a build including linux64.ko. The module seems to load. > >> portmgr might need to do something to the builds to actually use it >> though. > >> > >> I'll upgrade the other aarch64 package builder when it finishes its >> current build. > > > > Thank you. 122arm64 quarterly build fine. 130arm64 quarterly is > hanging in :sanity: for 48 hours already. I think it is stuck. Would > you have time to check? > > If I understand the automation/scheduling correctly, ampere1 started a new 130arm64 quarterly build while I was upgrading it. That build got stuck in :sanity:. After being upgraded, it started on the next build in the queue, which is still running now. I believe it should start on a 130arm64 build after this. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > > > Hi, Thanks for your reply. I was looking at https://pkg-status.freebsd.org/builds?type=package&all=1 which might have some stale data. Although it also mentions a succesful 122arm64 build with "Host OSVERSION: 1400050" in the build log of a pkg. This site: http://ampere1.nyi.freebsd.org/ shows what you are telling. Sorry for the noise and thanks for all this maintenance. If can help I would be happy to. Regards, Ronald. ------=_Part_188_1079252898.1643975395742 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Philip Paeps <philip@freebsd.org>
Datum: vrijdag, 4 februari 2022 12:05
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: Ports Management Team <portmgr@freebsd.org>, freebsd-arm@freebsd.org, clusteradm@freebsd.org
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-02-04 15:59:12 (+0800), Ronald Klop wrote:
> Philip Paeps wrote:
>> On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote:
>> I've upgraded one of the package builders (ampere1.nyi.freebsd.org) >> with a build including linux64.ko.  The module seems to load.  
>> portmgr might need to do something to the builds to actually use it >> though.
>>
>> I'll upgrade the other aarch64 package builder when it finishes its >> current build.
>
> Thank you. 122arm64 quarterly build fine. 130arm64 quarterly is > hanging in :sanity: for 48 hours already. I think it is stuck. Would > you have time to check?

If I understand the automation/scheduling correctly, ampere1 started a new 130arm64 quarterly build while I was upgrading it.  That build got stuck in :sanity:.  After being upgraded, it started on the next build in the queue, which is still running now.  I believe it should start on a 130arm64 build after this.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises


Hi,

Thanks for your reply.
I was looking at https://pkg-status.freebsd.org/builds?type=package&all=1 which might have some stale data. Although it also mentions a succesful 122arm64 build with "Host OSVERSION: 1400050" in the build log of a pkg.
This site: http://ampere1.nyi.freebsd.org/ shows what you are telling. Sorry for the noise and thanks for all this maintenance. If can help I would be happy to.

Regards,
Ronald.
  ------=_Part_188_1079252898.1643975395742-- From nobody Fri Feb 4 16:28:54 2022 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 5DEE819AD4CA for ; Fri, 4 Feb 2022 16:28:53 +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 4Jr1FJ2TRvz3ngg for ; Fri, 4 Feb 2022 16:28:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 214GStDt084866 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 4 Feb 2022 08:28:55 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 214GStj7084865; Fri, 4 Feb 2022 08:28:55 -0800 (PST) (envelope-from fbsd) Date: Fri, 4 Feb 2022 08:28:54 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 Message-ID: <20220204162854.GA82619@www.zefox.net> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> <9787056B-D173-460A-821C-1386F7F2D5EC@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: <9787056B-D173-460A-821C-1386F7F2D5EC@yahoo.com> X-Rspamd-Queue-Id: 4Jr1FJ2TRvz3ngg X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [1.93 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.95)[0.952]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.08)[0.075]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1284 Lines: 42 On Thu, Feb 03, 2022 at 08:40:41PM -0800, Mark Millard wrote: > > /usr/lib/debug/usr/bin/clang.debug > > could you make a copy of it accessible via: > > http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ > > (possibly compressed)? Done. > Also, could you publish make.conf and src.conf and > the like? --Any tailoring that contributes to how > your builds run? I've uploaded /etc/rc.conf and /boot/loader.conf. The others are not present. As an aside, probably unrelated but maybe not: All the stable/13 machine's ssh connections dropped overnight, though the serial console retained its login session. It silently failed to establish an sftp connection to upload to the webserver. No errors, disconnect or timeout. Control-c was required. However, when I started a ping session to the webserver and placed it in the background the sftp connection opened and worked as normal. This has been going on for some days now, and it doesn't seem to matter where the pings are going. It's as if something is getting stuck on the stable/13 side, with the ping "rattling it loose". This has been fairly consistent and develops some time after boot, tens of minutes at most. I hope this helps, the experiments described earlier with chroot (?) are next. bob prohaska From nobody Fri Feb 4 22:44:01 2022 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 7A75D19B3F65 for ; Fri, 4 Feb 2022 22:44:15 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jr9ZQ0GP8z3tm2 for ; Fri, 4 Feb 2022 22:44:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644014646; bh=a61cxHmX8H/0tHV6qO+N24qd97SudQAGDfEkjU1Blr4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=F35KAkOjhTcoJn0xB/i//D73SBMNrxDl9cpK17KJhcG/n7tA94VVi9VttLFQ5eoaE8W0KlZbb+Gla4ennGo0VF5BarqBitBLLswGBBNE/JYBADI/N3pipur9I6fryLqxZiG75Nq+XiZl7LDBDaj5JUmQ6fJIdvYcEZfgk5xTg+q+V3iY8qJdAgNsrf8LqRXex+GGC5DasAlsutlSIH4JnmeURTHTcH+QfiuVXWte/SZJl03hKtz8FfzARwyf7e8BEuisKv4HDIoJb6FIyQPoiS9/fhZE3gtzwi+jOWtctQCl22RF/m4/4E1pSzFqcnqgC1ClVC6geOhJ9GfZqvff3g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644014646; bh=u/dL2r+QUOwPGHFvIsUtUoxhGxGO1/yobZw9bLsg2/K=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sSsWmqv3E3AhHqFW8DhfWfEaoYzjaZo8BvYJ+0zNCWKBpqH4Bov4qAbeEHUyj7dLc8AGU8qhRl8aXoAXPJhBcBl3pjRr9u6tvS9j6R4f+3MruN2Xl8m3LAcyqvfnzZBb1Lf2SXIfZBIiIrfyNMLdsRf2p8gycuuC1hZdgcpqyLddyv/PXExPDtQyW7wZIV9NU+nD1QJPhD5clcwEaF1l9aI7x+FtOKQPoSXiZSUcm5JbA/5rE/M13zlkAf3JYb1fhh1fOJGKfI3oU3Sz6pu0c41QCAhVe8AjEgCkelAgeXxxcWD8hMQ2XEqVI3NRl1vsY/kNQBpMlgEl+R6ZA2Gz4g== X-YMail-OSG: XWPGFJsVM1llQXF2vv5gCfZ8ZkG_ybaPsm7FvBFlQqE3aZTcLglbHg3QkpVKJct _f7VhItXEMlnoHGtouxwuXV581j9luzZutnPv80SY8_JatGIrtaH3JLJufBGcvf7xrRIqLucUZnK UlUicPYyPS1urK35D5r5fkKnXzrbYcKUPZFqpKa7_eBfShMVsyLyRcyVCw6tGizblt3wodE6JPoM kUrFcfax0d008sVnhjK.0aEUOwK_5mUMU1bgYx6alvxAbW9_c4GO3243NZYZbyXrenveo28RHBfF 1kKmdst92i7sV181t_QOu_c41BC_mkgbS2I0YIb.sTCpbi1WjxwcDhnbCerPmZcn5fN4bs1k_kNl KYGHl9PdoQbekf9oZEg7aXtzhbiBERgB8kNvznpWscbwH..Ud7jMt..sa58i5QShImuwgnIVf0VE PaacOofjowxmons3Uz63ZRKm6mzGV3vqnTmMGXg8uroJxI79W06UIlcpZEfiy8pSUrJr0uGUpfT7 nr4W9jD2dN673iKLgmHw3YFn1slmOBQcvqPV0JfYhYi3PLW54V3XNWOuMDNAqbVpvj9cEyHSVB2r 01EUb9zgitZA6bGR6WaNN9sxyzSETUS0r_goqS7j7Ma1.blKrsX3xLGjRUF0e.Aahly9jsphlziA sDQC5rw5MH7bY.Yfx.Eaw1.robOHp8e2o5wferoKN92yJDtAPx4s2qs2i8IwNHrRt5UCOXV1MTyt 5h_GhxZPpn0vB4qEx549iUZBT3cLEQIX7lAhPh9l1ilTz0myW4amKZmYrayaNo3cC3kjpyWQ1TF7 2ayQK7tF.GzbCoakh_UWKKmM9tvgmHN3QJHj2U2eQMW4kmiIJZeJb6CMn0HSvNB_Dke7GyLYPM1v YH8UDDwvAcUz7688ud6xkRy5z8bw1vCimm662Yh.WgyiecIdFoQH0ROTyE5z.w3sS9F79znM7No5 YNH5ZU244WGWsU1QMaJlJkWSp0kx1ggctRCmU.n22aBOLX_K5JZuGySL0kT4GaANRpTUDkGvuu_I I_SJph.eL_2v3zhjcTxxdyLIsrXNJ1ksh6mZjUju8V.uq9CkJy13V6AC6UWXR2.Scg5hOl8yr8dd 731nmuA_H0t06gTalaMMh0OIYMxIo67AHOgSs5nFmNB7mb16cW3qJ8DtukdWMltu_m7z3qGjT7fB kSvdwp7zBJMKzzPobC6TdbfVVds_9hLoeq5LsTldvIbGJzcTOmyL07QbwF0.SsOT_KOu02NV9FYw oM2XVRo24rvPxl3xrWhwM3vUXYmKCPk2h5M5JygWdso5Irk09DIBbJNoOB.1UQhS9UkoDr07oDVc VRZ9zN2Z_v4rh6_tj.vanhYsRGe_q_syYO8aE_WywfW_QnBCMdc3tDZdWXpRE1FYncKr7tf7l9OB pUF_XoWJl7S41kqPqFNCMPK5xVBEYpiH4zXfxMblriRseyytE2nA2N.URsSPgJLL42XffEZmnNlw G6DMhCmPM07xpIWAdeGEqDG2E3HrWcB4d5_TGMNupGFbQrHtuFkepFr250DeMmpoLHz8tB7HLCeW HlVpg7M020_AlFOOHfMU3.4bNmxBa4QNKdyCgMnyATseTA2PWLYlH1Se3H94m2mUFcy5JPLbmkJO _xNPDPJwwqV9.XsCiSDM60OLqstip95ei55GSM2xgVE.Hg.xpfgWbqel31jiprZZ184Wf9R5iwYc 7dqee239vYnKaphmxCyk8__dIphRd1MV507DLFT3HtXWNUB_sUQf_BwL_XRvyG5NXmYensA9spz9 dr04VBQ8pgfvZ8RMHItHx4FeAEt80hzDtXuwExOxOV5eGXySscfh.1stGt0YMhGZJbSwlZXs_bmj hAS8sMGbvzoFd5A6CTHjo10bsoBKcDNPQ96JcVeH87ywkD52qyIL63f7PdBh7ZgMWwmjwsLZShrE bDnao1h2ZjYvUx6PeNDiwTUHNB5k689Cr4asaqIkxkSC731aH2N0mLtbyO.IljyM7Jk0n9NH1gF9 TIduv.JoywUAHCww5wTOOoSZY55Vu.igU_uSiw70dhO3abYXVJsOlbAJGaKOh18qfMUPETAM34Ed V8Aa.K5txNUUugRLm_d9ctGT75qSUGBRThZ3092COGPWlPIAQ5MqVAr7fbEcFr0Q_0evx3fgyoGJ f6FFx2F__yV21BJ.d5tT6xFMAHmNXs_ZL.SR5m_n7_mmmCopcvVP.N8qFvscPReyqAqkd17.iyY5 bxf3TNZY75mhUYn3OVnWPmZzDJKDu0W.RRKi6x_OMvFzNDlEhQfqSOxRdxwRcOsESsxLsfvuOGqV E2LmxhFpkCoSc X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 22:44:06 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6d7f601eedce32458d9a81000d5f5590; Fri, 04 Feb 2022 22:44:02 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: <20220204214403.GA85107@www.zefox.net> Date: Fri, 4 Feb 2022 14:44:01 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jr9ZQ0GP8z3tm2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=F35KAkOj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2712 Lines: 78 On 2022-Feb-4, at 13:44, bob prohaska wrote: > On Thu, Feb 03, 2022 at 02:05:38PM -0800, Mark Millard wrote: > [chroot setup snipped] >> >> It would be good to know what experiments produce relative to >> failures vs. successes: all one? the other? a mix? Part of the >> point here is to test builds from official FreeBSD build >> servers instead of personal builds. >> > > I placed the chroot directory under a regular (wheel group) login, > but otherwise followed the instructions successfully, I think. > Since all the installed files were owned by root, I used the > root login to work in the chroot. > > Five attempts to run the .sh/.cpp file produced all successful > results. Interesting. Currently it looks like your specific compiler build and the ASLR (Address Space Layout Randomization) somehow interact, leading to sometimes getting the SIGSEGV's. I have only reproduced the problem with the copy of your c++ -- but it stops reproducing in my environment when I disable the system's ASLR mode of operation. You got later messages about the ASLR disabling experiments that I did. > Next I tried to use lldb. That produced the usual > preliminary output. However, on issuing the run command I got > > error: DupDescriptor-open failed: No such file or directory > That message happens when devfs has not been set up for the dev directory inside the chroot. In my instructions, before the chroot command, there was: # mount -tdevfs devfs ~/13S-chroot/dev that set up the dev that was in 13S-chroot/ . It does not survive reboots and needs to be done again after a reboot --from outside any chroot session. In my context, the following shows some checkable consequences of a correct, active devfs mount: # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 823229 194087 563283 26% / devfs 0 0 0 100% /dev # mount -t devfs devfs ~/13S-chroot/dev # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/gpt/Rock64root 823229 194087 563283 26% / devfs 0 0 0 100% /dev devfs 0 0 0 100% /root/13S-chroot/dev Of course, you did not use a /root/ base for where you put your equivalent of 13S-chroot/ and may not have had a context where ~/ referenced where you put your equivalent of 13S-chroot/ . So adjust notation as possibly required. You can use df -m to confirm the devfs status before doing the chroot command into the chroot area. I do not know if there are any consequences to the ownership of your equivalent of 13S-chroot/ . === Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 01:00:05 2022 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 7D0CC198D2B4 for ; Sat, 5 Feb 2022 01:00:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrDbQ3tfLz3lwt for ; Sat, 5 Feb 2022 01:00:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644022810; bh=w4nc2zA2cK5vMcRGf/z75nF8pJvvT9QxbKdDay9MVEA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i/55nxEkLkew1YLG5gTYDYMzZupTLcFsXsvg6bz9chcwhqlKkD7HFHgUBOuw7fdE80e8/yIH6paVKGJA/rMDfvk6eHT86si+1c5PCZ6L1X5HlupRYKJqUIF+NnT6ffNRhkgI29eZCLc2WbzGsHGZ05bCEUCcbpxEOGBJ29heBp0gzWN5ISoaoL+nlq1JvM1R5w3vcs0RTp9f5glaJB1U0Xw4xsyNpZyNx4QY7BWRlczjQOz3yzBIcSyhAOo+LsOyQjHtB9c4kSSnYEv48iA9UIzCbxkKT4u/jLw/nnahEHpd5nWZmUJDa6BX0JQ5gNVupKHC6IMkSCm60ZEtI9UVKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644022810; bh=bg8Nd6BvwMPMPFtjaqxP1RP7BcZxqjFAuHuIbojK2wH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Gus4iTrlclUmkHUU37KifJa1DN7r2c0LXz2J2gBbRq1T4nc6Z12YxU5J00gPQdX6gfE5+DmBllhpuRb2SZ/eGdYEugu0u5nuXhzIZWooWQ6XsnmiFu5FkeXHHwMuOkUx+b+XhvbuJh0AREXjiFhPCUnOwU6OR6xhG3XZV4A8r3V9Y9h23YDHtT0bRxKfrgeDL/PJDVvr8J5OwzXtUHOSQThSAH0+xQ80/HP+bfyzpfYAWHIuwPjMbzsx8mA0amuWmaA3uOElAE80bE3P56mQn/Noo0U0a0xGe43quYmWGqcqhUEd28506UYF5h/GBMrTmCF6trHD9evL6ev/U69WtA== X-YMail-OSG: .zpRz3sVM1mzDaA7MBPjiieObPKQoFmeiizPztE5M.f53sfaI2cF6Pekqzfeu6A 7UnBlbFwKYp0UE8KBdmLxr8B_C33PgO2MoiEcp7cfCNzOuxQcjKciLDKS.YKFGZ1dn5Ano.VWBaY KvClti.7urP4XgJmil96fFHkoicw8XXazlF_1wzaz6TX.qNAKFsUd7Lzs52U5ttn3LBo5Q8MnojD UFRK3dTuUYG_K9BccbRQ0FCsOHZaqO37UeVT6f_zXaRqvQ9oLhFTPy3QILDXxQhvHVrBaHavDhI3 0FOskrZAdNduPY.HxlevXsb9RHi7XPyXNENcGGmnzV6Bf1Vd4zo0WFZ7OIeh5hk2xCd8R0RZaKw1 sfUJNIPwY1iV__Ro9XS0OBeVZuzom8AOH9mILNeTYCHKLnBPAdedG3MpqYO6VmqqUETGghI9n1Hj yDRcHQVcfoaUtlzGjcQHrTDk6AhzMYFl.sZeWmBNeqUHdk22hiTVIHiCIDdnyIJpRMzspmyf75qv LCVGzU5b7zOr9YQ5K16QPYobe3qpOAgXNt7.PwnO2v09O7nwReuUyevNWyPSV0CkL7pkuP7Qaq3R JrgHw0y1G5wBdMzp4KCEib6pBsKY_trSLOKQZOs9v.M_fwesCCQFGJmHoj5rJ_kML47ssG4DLTq4 dTisvjIeRpK5A9XullR0zIw5qWfsDQFvkH8Af4qPBbkw5iBU1Li9yN5WBD9nur0HqvN_fWauhbVa rtFYtnv9sSjtlsm0W8_IYd5TW5ifh3Ypz.9RKMHG8ON1Ygb23Z3LCweMd23lCG66APl_Ktr46Non RTtbWlU23LgRAvgP7KX4uzUsta0FTfarZ2H_gbepgHcGgfTB933A5LVb951e3nn4S3p1.54ljYuP uTJQ__5st0PaK038g39JmTFIZ5ldrHjPEmqI2vqxjJU.LwGYGAsqq4KB944Kr4eT7e8fbCJBsLuL o0OviMvC0aAm1lYmK7GxYzN9KmveoS_ug2bLPLe7vH5H16.3uvRxNCRYQZ2T0v4mP_V20NBfFejB SbHOL48aXmvLTxlQBm2MKT89ALMhEyJYVjPc7Wwx7MzeK3WTtO_wn8vZI4sKf_RPzUagAh4irqzt EWuCkNrB5c_EH2POzaEFY3zjbeRIpRGhrE0IBT3tKkTsbuhBEehdwkC1AdLwfVb14249ZucB.IRW QzPTotXnKFeLeIV85Ymq1Hm4158pwGmPKG8U7ViGM1np8luavbW9yx.3mpScdtOgYecKpoZ6QXt. NvbmTIQfZ8cCt8W_EPfT.URUWDqGhHT_RhdrqiiVfNLq3mTF4_Oqq4_aRmjDAcc9JGzZJcSgvFcW EdXk6ZUDwKKKSnLUBUpRNagm9lGsZKzIHBGBjuvCYQw4sipGWY72yKp8Ry3d7QEjVr_9ilX5VLn4 cXsh4MC.QF0vBmaPcbFLtPtrsOKTdQ_MUXVHHO49sOB1RfRG3UNIYFfyyt_b2oxy.PZ0WxTz4V95 MkGkWQCvZ8ngH.KXX3c2Q5.OEQbnOaSr5MWk9gjvG4_O1jeXZ9BrKnPRHcP1QUFW_UM6j.q3UJsS .9I9RV5pSAMHCkzONdyGfzORc5dp4Jz2_H7YgWeDuAqo5_eWSqvCDZXvBLcELV5UmYtlMKDcN86P F.uj__flIkAUXyflodw3404FzU2Ubl5SdLTujulcvNxrHgAq63zCcQsXE1F3XJXoDFuQk2vmgdTF MgP65nOT.NUSX3ikfLdk1bjuIwhMntyDo8SxcpeVBJ0tes4LyPNEv45NgoqE6Vqh_G2hig3BxkL2 sJBDFGbJXOa4QBeEilDbsEpPiBAy9bGwczzB8a_hMfH3evBNEzS4Ah0GzY7W76DTe7rM0.TKChHV r8dPGlboEIJ26QoA0I.o9snC2G7M6lLp1c13UuAtP7zKOHX1.IAXppJ49MWKlE2dGTxpmE261Yy8 O77W8qVi7GMhHOQaQkyI4.9NqdXN0nL40C2ZXQrnL26r4Nbdnmh.SxxYYdUyNXfHyBNCElNmJjKI W9j.dLuN5J3owfEIym0Zsfm0HlLAOF.2f3zMrc2pDo6PVWX0urLaD0XLTr23WU8QK5aA3lvP1svu _hUwyrV9B.vjZ15oaoVPYGcPMIlP2JGBKvGVqdO0ZqzVmaatEZjq0SCswGgbehFMAwe84GwMIhdw uq3qokMQKnYhoOWwM0lm15SsCDUopiFnf7wCdrsL7brNvYv6p2GHLtgwWafib6nyO75QOcpdRoQY D04Z1jNrCPysiW7Xo_4ZE5geur_FGA8DKTqqbYe40IUufty7HveOuTnCEahdjY_6XPm7NFnTQsa6 gBQwkYt71b4gzWBlj X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 01:00:10 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 44d554cc74e436763e7ecba47c6b52c5; Sat, 05 Feb 2022 01:00: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: <20220205000800.GA85644@www.zefox.net> Date: Fri, 4 Feb 2022 17:00:05 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> References: <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrDbQ3tfLz3lwt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="i/55nxEk"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4644 Lines: 129 On 2022-Feb-4, at 16:08, bob prohaska wrote: > On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >> On 2022-Feb-4, at 13:44, bob prohaska wrote: >> >>> On Thu, Feb 03, 2022 at 02:05:38PM -0800, Mark Millard wrote: >>> [chroot setup snipped] >>>> >>>> It would be good to know what experiments produce relative to >>>> failures vs. successes: all one? the other? a mix? Part of the >>>> point here is to test builds from official FreeBSD build >>>> servers instead of personal builds. >>>> >>> >>> I placed the chroot directory under a regular (wheel group) login, >>> but otherwise followed the instructions successfully, I think. >>> Since all the installed files were owned by root, I used the >>> root login to work in the chroot. >>> >>> Five attempts to run the .sh/.cpp file produced all successful >>> results. >> >> Interesting. Currently it looks like your specific compiler build >> and the ASLR (Address Space Layout Randomization) somehow >> interact, leading to sometimes getting the SIGSEGV's. >> >> I have only reproduced the problem with the copy of your c++ >> -- but it stops reproducing in my environment when I disable >> the system's ASLR mode of operation. >> > > It sounds like I simply have a corrupted c++. Perhaps just > set the old version aside and copy from the chroot directory > to /usr/bin ? Granted, other things might be wrong as well. I'm not so sure. My expectation is that if you first do (presuming not already in place at the time): # sysctl kern.elf64.aslr.enable=0 and then to your buildworld buildkernel it will just work -- using your exising c++ compiler (system clang/clang++). Note: There may be a way to set a specific file like your your c++ to force ASLR to not be enabled for it when it runs. But I've not researched that (yet?). So far I've not had any example of failure with that setting in place. It seems very odd that such a setting would "uncorrupt" your clang/clang++ build (used under the name c++). I'm not aware of the compiler doing anything like the ntpd did, for which having ASLR enabled as a problem. For far as I can tell, the setting changes the detailed behavior of mmap calls (including implicit ones in library code and such). I've not found a way to look at the context just before the failure (without disturbing things enough via debugger activity that the failure does not happen). It is likely that I'll not manage to get such evidence that includes the failure. I worry that the failures seen with your c++ involves a kernel bug but I do not see a way to investigate that. >> You got later messages about the ASLR disabling experiments >> that I did. >> >>> Next I tried to use lldb. That produced the usual >>> preliminary output. However, on issuing the run command I got >>> >>> error: DupDescriptor-open failed: No such file or directory >>> >> >> That message happens when devfs has not been set up >> for the dev directory inside the chroot. In my >> instructions, before the chroot command, there was: >> >> # mount -tdevfs devfs ~/13S-chroot/dev >> >> that set up the dev that was in 13S-chroot/ . It >> does not survive reboots and needs to be done again >> after a reboot --from outside any chroot session. >> In my context, the following shows some checkable >> consequences of a correct, active devfs mount: >> >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 823229 194087 563283 26% / >> devfs 0 0 0 100% /dev >> >> # mount -t devfs devfs ~/13S-chroot/dev >> >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/gpt/Rock64root 823229 194087 563283 26% / >> devfs 0 0 0 100% /dev >> devfs 0 0 0 100% /root/13S-chroot/dev >> > When repeated with the instructions followed correctly lldb works, > the result is exit with status 0, success. Nothing to see here.... Good to know. Thanks. I expect that you can use: # sysctl kern.elf64.aslr.enable=0 to make progress (buildworld buildkernel). You might be lucky enough that after installing the update the problematical combination will not happen. Another option might be to use a copy of the compiler from the chroot area to replace the normal system's copies, possibly renaming the old ones first (various names), including deal with clang.debug as well. This presumes that the 2 stable/13 builds are sufficiently compatible for such a substitution to work. === Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 01:34:13 2022 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 1F3C919B367E for ; Sat, 5 Feb 2022 01:34:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrFLg1LWdz4V52 for ; Sat, 5 Feb 2022 01:34:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644024857; bh=hHVvGoZX1F4txkixWaghao2QX6uHhbpjFn00fIQ4ISY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T1gt/o5A6wvUF4mmNj+0qAVLkBFEgA3pcIwEOTOqyt87nh9znm9LzsiyXZG1Q6LOz1ajAcsF8+1j7zOyU9x3Sck9eWuhTintdCSCu0NucwXErINQ1hvGvvKpVN4TXJCTqDdM8pT6mIQuZkzAFBb+OMJ4YZzjrGaHQiXM2mRy/uHHqnyq7wagPEfIpZFQ1b6rv1U1K3MfDA70rhJW19voMNv+6OvfaIJhBYTd5pV6CwORq2Jaz3wMWDa1tr2AiOyodo7unCpd1UhKCSeSB6W+f56rpGgrGur0YLvwUuvLLe559Uj76CbmwdjulwDHwBiMTd9+jTvxrHulgidbV/cRlw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644024857; bh=rGJa74YcoomA8to8xh0CUFo7ga7YRIxoJvpsLClEFMv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GiSmGgIwtfNM28NlXRCenvtR8mPeDCTgzq2R3BsrAJRWmYJ4o/1tAikZ8E6e37wzw03kLplmaGefYEwHlhHYQLYj6peDPmm1Fe4kY7aDq2e75gci7D4ESVE/S7iKu7/9bkYh2DeWaMUrjogPDG6gJIfSh+lN7ErBzC+YG+UbRyDFvsoNJBmIiJD/Lb1EnQIeVFF+MqmUeXI9zCjLPCa/iCt+qla5Yi5/YdqvdCMZu5hgAGeWWM19gGqZ0kXEkT4hNB8N3Ts24+N2eqcfg5fGZhoPpKc7gaOW2CAjswE4wxGZhTYIdxNpMqwpelxynsB1jk2axVEXadbTQ1cUotVUPg== X-YMail-OSG: .I47pNAVM1micrx3TBkFq4MRWOeI3r.fFfuDK8pACNwkjr9dalWjToj4_4OTwTm WEdHfAeUJWulJ4SjuEdnqiVWsEDK4bp0Vsr4eQxMDT6eC5QUr3Mg8TfguvryRvw3BQs1klDMpuHJ mqI8J0WeiQEOO.SJd7D0LeoaxSZ5uA92mU4EkGEKebq2B5j3cU4ttCHjZNkYkNvr7V.Ru8mJF85t Il8Gyhtp1RpB4w2mR_NIFCvAO47Dd4UNkXzzzNsnBRhtRbI4lEzmGNMUqVVdAfp83btv.SW8ziaT X3BSW3qw4Yxfaz0_4KWvzb.OzrqHzg4f7iwnG9iAKAk_0a6HelQsrvVkNONV5RwKdjKWSFPBovb5 j_w7xeKGrm_RkU8Tuyp_2tWfYLqzaIxp5XZR..JGNxu4.hlP293nO9SdYNqUFpYn0dLLsJOTzFi5 _Gz80UR97UfgiHNqtUd0DNG..lXUN_fXRL1J.RXI111s3nSpwfHBr8KslOncq7nyotR.5ZyE_ekS _0lOV5PU9Pn6n0xeUSxJneQWSt5mWxGZa8hoV3U.zS57gcwYUcAeUsdF6xZC7g_lzA2c9Rwf1OXi 6sCiQHRVF12PbqYWPK6BdfCZmFlc2EPVC2DRcbFhCf4kR8GB2Jw5OztMeGnddI6xDES3mdZWSfW1 ukav0pJrSv0J__JiEI6m61kKpWiQQ_rerRdlR.hA3M0la3kEhqNcqUZf3GptK1nmelOeCiW8GEuC euujHD5oZ1pNYgfo6NHJQ7R1IiKnd_eDyqs1BQ1dvlVmC0oaRYMxebrsK.iVXu6HYfD6qp7MbQfF .3XLvz6LmdZEFM6NM5dzzDJL77QR_dB4hHJFOPW7yrxqbWvR8Zn3lVHH7gRRZW.sgHAW4QFbs_.N 7drODNXNH6ADZzQAtBPElVzKCRR0sq_CyvHzP5ccnn84eYdF.EaivhDEm9q.e8t5EoGW40An7ekw i87NbsX5BOZXxhvtQTmvsMQMdP08ljMUIqlNVlPapMFwaGZZ0Oaz16UbFgTgPNtMg0byMTjAoIrL VL6Bx6.o1QpuCuL5HJDWw38_ZXbxyAmNBcfZfm5PJjVXEp1KoeVMcX4MfimmRxlEbssrdggEEVJw mWcdw48w1WQCv16g0HJKNG4YWstfuscvYAyFENVKLPCXOI6b69Bq.IKBLXIEa2McZWttrnhI6crq ej7GxzK1OygSagyzuKufQUwgOoLge6Y8WoYb0Aby1456oDkf.BJAXT60oRVsjDXIc4RzqVVSXQ4b GXSXUvyRru43IXCrTqblS29McRMMAQU2HPoyXuCEQeFIOi1oqXcKr2A5aKqr1qd5QOlDMZOz66df 8iNw9BVsDqT6oiqNwZJXzvPbtQrAzD9K5zxCViFWR_VzCtyz7MRMGmZ1Jv5HSaViVfyDgiIZ40O2 wwvtF8YD7ogbqu60Q_P27HvTTfMOZ5eL3NbAd6xFzuSFTBxbzMjFkKLY9mDZW.VCJ7.LFoAFgaTK vGKJc5u07RiDfphuAKd9y4m9pomVCIDlTU_B4jR8f.CLLK2g7S5lo5QCLp8gwULlz3GqVpDQgdzO M67hGIKJjn5KqBMA_p.n5goDElbT2PESvGxwFukg3jprH4FUkjSZHaNimOtWIJQXmZKYqIsLHdBv TIsLttlqjYnfBmbPxHQasH8LxDb5dAkHxKza3qguN_kUrxvcaHUEQZfXs_l5o9j4hjinfLEd1y97 tLYkHHtr0lOJQtGhtumgjeqJElWH_l4G8kh9f8YN1dbr0RBqzIv6XWtzwKShGGWNFYWWtZ8Vys3T 2koTegV5REwsCa8IFuiAwj4lnRxTc8Cf7qbdbDZ1Prjf290h8zh7s_AOYNVkE1O5zbTJw2rKIBfE Yfgqxc10Ulbf_JpU0jIferx2IEAANn7pzgaiZqdtIQgMJczxt4LGSz2Hfcjwf60TVH7L8m7VPg_b z4WjIx11pwDdlQOdZsQvtM90v2XzM7CZTOriKFfQ9gyRdGvW4yGR4JmcX0.LoC2P84BVmWYLzSBn Bg8dvDtwoBQpstuAM1Y4_QjXk8qIdp7uAC93ta3kOlBUiR_uGFg7nvLxmfsAA9C4LkHjLcDTwU_6 sFHvopQQ_CF3zanD0.iyp5xfq.CwjcRztfdKveSOgZLOw4qF_px0XErVEQVsMpK4D8_2.JIw8mNI vQtYuRZODCpwoOv72BGOb4FuDzV3c.92SYO9kZ1x35WOJHr_Z1CsJtppKMEI5oQnVRBR40M01kEh 1ky75Eo7VcXtUEWPcpsPuG_peEo.hUGN6yi46qP1rfuBLDU8.9QEDZpgRQq3UE9qLDM3UtCUUTiY eiRI4OCbxWXJP X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 01:34:17 +0000 Received: by kubenode518.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 53bad5f26baf459c3bfd8cc0c760001b; Sat, 05 Feb 2022 01:34:14 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [How to set just the compiler to avoid ASLR being enabled for it] From: Mark Millard In-Reply-To: <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> Date: Fri, 4 Feb 2022 17:34:13 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <0E1C03AD-7600-4680-A27A-985E6DC64B0C@yahoo.com> References: <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrFLg1LWdz4V52 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="T1gt/o5A"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1209 Lines: 41 The following shows how to examine and control the compiler's ASLR status (notation shown presumes first cd'ing to where the c++ file is): # elfctl c++ File 'c++' features: noaslr 'Disable ASLR' is unset. noprotmax 'Disable implicit PROT_MAX' is unset. nostackgap 'Disable stack gap' is unset. wxneeded 'Requires W+X mappings' is unset. la48 'amd64: Limit user VA to 48bit' is unset. noaslrstkgap 'Disable ASLR stack gap' is unset. # elfctl -e +noaslr c++ # elfctl c++ File 'c++' features: noaslr 'Disable ASLR' is set. noprotmax 'Disable implicit PROT_MAX' is unset. nostackgap 'Disable stack gap' is unset. wxneeded 'Requires W+X mappings' is unset. la48 'amd64: Limit user VA to 48bit' is unset. noaslrstkgap 'Disable ASLR stack gap' is unset. (noaslrstkgap may be fairly specific to the vintage of main [so: 14] that I'm at and so might not show up.) Being tied to the file, this survives reboots. This should avoid needing the system wide disable that I'd previously listed. In other words: no need for: # sysctl kern.elf64.aslr.enable=0 (which would not survive a reboot). === Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 01:40:25 2022 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 8813C19B67E1 for ; Sat, 5 Feb 2022 01:40:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrFTx22n3z4Wwr for ; Sat, 5 Feb 2022 01:40:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644025230; bh=qgA6DjriH87dZp05zWaLIaUkB6V86RDuYwRCjL8BNuw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=orc6tM/UmuEzqtGn47Ym2HV/J7Lt1/T0tNbdGwquom1xWuLdBPGRijv55w0vRhhcFrLqcy43YfAP8Fl7cCMXTEIuujPID+YyAJ2NX2zqdEcxl5g/31NHzeN29OcOjDzS5y2QUhbY9Aq1zfhiZ40ngXC6pIuKQInoSo20WfRJ2jo1v9RA2uArMoWKVkICWXd/RBnONdp7Jn+/l8I3MtI1AOvG78FnmGHdm+GgmsXkyUDf7oA5dfjTGR8LpLwGaBYBJcCcof5ja8kkjOJgZ7dYDFpGOBaD1DzaR/3J/IsXnyb3gbzJBQYYQPgODK3zXQS/wMc3qPio2XxeW48UudZ+Gw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644025230; bh=6f27TDYWScYxB1tBWQQ51OmaxD+esuNvZI8yzZcRGS/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PeoGLhI/JNxKkXzlo4rphkSBG6/Wyv7D5aoyiNyxigGvbHA56+lJ1IQq4t21ZcJ3zgFeH5uHPCj/ojNpx5isTSzexar7qgOUSlsfLUEzPP82C4gBU9IHhs3GxJAup/R5BNy96xDknNPye3308QYxEaZxAWYaRwo0xW/cWKZgIrY9t9imSj3joLV7pqkpAiN4DaeBXr1OR26ZNnOfPwAJTQOYmphyIMIKcqOo4EtdnYguF0uNTSFW9g8ONsZE4H8ZfLpTTa4yo+Zs64FpN/gKhUsKtaajs9zJ9pOyNAuX0IDE2eXzdYe+wE9sxQAnyz2m5kT2GIcNxOpdOBtAXIaofA== X-YMail-OSG: 617wUPwVM1lmhOucYdfyQQ6Eby7LyIBgtYLQHEIWX7K1IB_WODfYkMZxOQuv7EM 4tfxALZ9QVfI8F762QXLweEW6sbxlkUwoyFJbKdMtaeHxGad3wzJNlMWNwiBgUCkSY2SN7JKIzPw hHIa7lMRfJfP83uvwicilDAzIfWjaNN65QVfwqI61EOjp08i9qZWrD72FCEg2wzhg05q7q9.duYX CWw3_g4HJKVHfR9pKDmBvqspc4Tckekl5lBeZqcoJXVNwzcDePLKAipAi8eq4Y9QdoBVZgH6GgLi JhnTGtuzHBIrlBcnEDHyCTFWWbxDHg.lcbfOlmFNnBeNrZtYTIWU36uQpBUeUQgOavANCHGq8JWD _D9Xa5A9gZlaosKWQhfqA0axGX_dws9Eshs43I5894iyqE1Qt6abTeauKJ3csJzD1zCadsLKdRlx .Y5Or886pPgMyqTs3XVBnGoUa0IlygXHTErxMSMWkbaPzeF6Z5SFTQbJxtYACd9p7Be.zvGNmTst 8zVaqH0Lx2UfBxNAe5_N.mLnhyMl6rAOPcVPlxDezTgkABD1CO7Xxa_bk4IA9ZNBv4fsCsy6zeD1 cU4QKq5jBPOXc.houc.EPfzUw_2LS2dJo6_72NACXKj4YivKzQ5GifhFms.oI9J.BtyD.AOfHufp JaJcUM8FSzU1hpj9oLfv5H8Xl_c_StbmPgKnw3MsdQ4I2KdfM6aC.p4ry6Y_.WX2iCjx6hTud2cf LCauzvc7tSvc4TNxJFjNqyEQPmUteGrjEXLxy9OwLnqiNrUH01AbTzrf1Pvi289NpzgkchCU97QA xjaYfl.2wEisR2sWbrlLbsKCnKjQnH2z7ZS_.cm4Gr6_mTlw5Kw_tbtSN9FAC.AJyAL3n9Gf6q3W DCt4Tae51xTEHFN4HMFcrUq2p499XD9aDSZ4cguF9ATlCK18nVq8YLBUsd4fWX9Mw5v88B4ZBbEl Mq7TwIl20tdZI73Pm.nPkSeKMR1wD4eq0PFBwddFrVCO1kWNEwE4CF6x.U6CMofNw20kUAFVFlQO DIGlQbzlGZV6uAWoMnPGLollMD9JK3n1fcPJ0EjZPxMYZADpe3BN0yL5NdRq__hVNhy9BEYp9QVr C4Hy8VSxSbakyRQ9m.ZAvdwkMQvSSMn69EpK9wTUBqXv5SZ2CdG0vDyd6owOirobqLH6CyPoULGi HrqZbhKT.3WUaj_pgrhj81BkoT_SQFLX_Wg7lKkHz7lBi6atSywpE0gD_gGVnY3nI6Ot1pURVA8g PvYWwQqDVOxSliaVIhiUe8wCh1f8G0cyYqKK5Ee42LaNqWqgvf2r14AMl27kqpYxOjmtQVWwxdhg ZWbkMkgxeHVPZKNiIKDPv3ky_0PZw6Fh8bUFnEBpPpwwWuMFIWrYwlg9sVk6DtOWuvGFzBjMZzRH 5YJcX_cnmndXcs0Uc9xaj4gIR76JMbhWtAUSvYRANmNMKdU0iZlUQcJj7OwSq7sjBZa7SPGYeL9n vDnDgrA2zuB3uqbVSgZ8.MDH9yPfyoS4qZ._nA7ZrHH0VGhpTt6tB127d.MEu634.9Ib35AV_cyY hs9pLHvVkpmMRz6L2RmAx7fDCMxOj785ftzEdswbizGplwWzYrm5FNn2E6sBS9T0q2YRQ78zIZ5g A406cLrS2_IIimaDeKaxVwFYTgVh8m0K7A5h5EjwADq6w.IhmV6ztcZQqsBblvUSqWnQo455LTSl InCfnev.tETtDavIjo7WC9aUWK0udx8psfY0lw8i70KkUsOrpXYvH03Ws7BlViT_e.nTQb9swF.n FfIYol_z5vyDwRwE9VK7FIP4IsbbmQxD_IX6Fhs59U4.Ki6c61AJsLS5MaK.QXMXyLkU5aYL6cGZ clhPtefqjJTZH2vKHhpBJTetzASVOeMpTM6ywdNeF7Kp.02vPnCj_Q.jnDYxwvl9xDdsWzhK85f9 DQ4ZxMICIH0N1cgRrblTUra.od50OXHnd_osU2NyWD6o1cST5_2D0EVMjS4r4E7HEAo2vROyUfxb 4iqFOtcbkq3EAH97Yn1Eccq8StBtYlsZwyhqUQguhT28I.VhYvJswtlxlO0BnzFRYJ2yjH4RREQU kH2QKJde2cDPu_zH8YANFN_67.zLpxT9naE8cJwPuzfgRjaReJUK_wSHtP_q9NKLGjJJIOuFGgIN L.Z3JWBTA491EkVbekQ3HFtfd5fqB4HNu4f80VnJ9TT5wtjK9FoDjD0.w2kZGOip405w2f5cYOTI 2wNdTpOms1UrT_4eUvDGm6lYg0tp83xaISdokU7zRFDJzcZ4Y82vnowinsPk78lPZ92.PF5vB2UW PUOREbyVmjL5EMkhx X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 01:40:30 +0000 Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 53316e02faf43f8d87d4a70f90e6ff3d; Sat, 05 Feb 2022 01:40:27 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [How to set just the compiler to avoid ASLR being enabled for it: DOES NOT WORK] From: Mark Millard In-Reply-To: <0E1C03AD-7600-4680-A27A-985E6DC64B0C@yahoo.com> Date: Fri, 4 Feb 2022 17:40:25 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1B332BCA-B296-4DB6-96E5-272B6062ECA6@yahoo.com> References: <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <0E1C03AD-7600-4680-A27A-985E6DC64B0C@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrFTx22n3z4Wwr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="orc6tM/U"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1631 Lines: 54 On 2022-Feb-4, at 17:34, Mark Millard wrote: > The following shows how to examine and control the compiler's ASLR > status (notation shown presumes first cd'ing to where the c++ file > is): > > # elfctl c++ > File 'c++' features: > noaslr 'Disable ASLR' is unset. > noprotmax 'Disable implicit PROT_MAX' is unset. > nostackgap 'Disable stack gap' is unset. > wxneeded 'Requires W+X mappings' is unset. > la48 'amd64: Limit user VA to 48bit' is unset. > noaslrstkgap 'Disable ASLR stack gap' is unset. > > # elfctl -e +noaslr c++ > > # elfctl c++ > File 'c++' features: > noaslr 'Disable ASLR' is set. > noprotmax 'Disable implicit PROT_MAX' is unset. > nostackgap 'Disable stack gap' is unset. > wxneeded 'Requires W+X mappings' is unset. > la48 'amd64: Limit user VA to 48bit' is unset. > noaslrstkgap 'Disable ASLR stack gap' is unset. > > (noaslrstkgap may be fairly specific to the vintage of > main [so: 14] that I'm at and so might not show up.) > > Being tied to the file, this survives reboots. > > This should avoid needing the system wide disable > that I'd previously listed. In other words: no need > for: > > # sysctl kern.elf64.aslr.enable=0 > > (which would not survive a reboot). > Well, on testing, this did not work in my context: still can fail and still shows vm.aslr_restarts increasing the same way as before I updated the c++ file: success increments by 1 and failure increments by 2. So I'm back to indicating to use: # sysctl kern.elf64.aslr.enable=0 === Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 02:54:03 2022 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 200B4198C347 for ; Sat, 5 Feb 2022 02:54:17 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrH6v6tqFz3JnZ for ; Sat, 5 Feb 2022 02:54:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644029648; bh=QLDobadEgml3RFFqgh85jn/ZfXc/34cYmhHXBfKeBic=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LN2lVWZOliPlmphn7xn0Pms2o0j7GDyHtDg5Zk/uUdA74ZR+rwwD89oBQHnUX18WgLzXPLD3P2ZRz9Ja9KIN3Mnfkrwmdex1auZOGWSEqjkp6wIaZvciVokIuxKdrsRv4JBxNxSJDfUbqkxO7tLg99cVzRRFvXdaloP4opL4kAeRBmhiHbgN2dhsJFyJF3UpwKEAYhH8WCkpoeFqw03vLH+jVwHddxG0NwRpwVPRrhIpiCjzf/YfJSU0OeplY+2va8Q35IUan6ONV6qY8+FnniBbvbnFbuiyNd7ycC3q/BekgoqaS/C1UUM6SekoyG17zSQW7owB3qZw4fFoG0/PYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644029648; bh=2rjwg5+fUa24DRvPs9CbgYTJ9BaVtdnXXgnFFSFyens=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CLTxl9i+nycGciLctz+8+fJV/Edp5r2eBJ61B6/wFF5kHXyhQGyUvrQ8XKosKU2+mPTOKBFIjE4hdOZi3NbEexNvDDoIZKfQLbY8mtMC1saG1H7VDSKTsub4i80rwxECUfXPeXe6b2maUz8X3legb98uy2GZhOKnaP85a3z6dN6DWM9gWOybCJx9OH0uj6KzNywtdPHQ6H7RjPPMgFvgQZOUbeTRWvkFzUpQyRhzhuocXv5z/sBmbiKoeWJUgsHb9B9eP/g6elANsGn3dbjbl1FS2SOAXJD37IjrmNbDbODtqMID2lBIn/9RYKgKBM7GmQvbjNpys8Bo/KfbCZvj1w== X-YMail-OSG: 1iibdCYVM1k136JBLA6bdCNdhiTpW9RKgMjv72.cEO9jj2ezq1YLjQXcx7v4_ms PGruWcaAo_alIv4Ttqt3.udZnMIaBuekwbLI_FMB.VmBej4vd1zMHOe2_0lAZZlO.7qhTsyZKx8R KHNPBH3c.NtcyZ5kFOua3DiWwi61O2ihHhLI_A1nlN2kwBU2is8fO8w_b5qqwHMArtW7Gnacjbgz p2BfHDamb.sVXvJICtizpTcWHcrq8GW9s6Rrq30Us5T9iY4X20cReUBNO7JE_X2mXUrjreMrHwI1 9FwdG4oDEjijw31.pQcFX_dS1u3zA3kcBI1Cj_bWGSvTqYl6guPErmocqDlHwkXjQk5WV8ivreGw EzqCc3uoiUKKH4Y6GDxUNOmH7NyxeWFHTubI1QGM2QiyB6TFeG2PnZfaPTQRGszPQaZsUIhh2_Rr jptpMCHEWPC9bQU9HGkbcnEUZYjcggGhMz4S.YHF4O7XREGhabHNMuFBWkSZUUdPrJ.UPORMnofk 4JB07EMsxGr.DCOfwLvpLRRYoVrODj9eohnRrM6S4u1TdHjOQjXCmkuwUMcxRfbpLTWCqX4rJtKw WgAqjmzOZUxT.R057El_Uz9T_Ceh6VSZKoueeS5s8E29JzsgIJ5usSKS1dMSO6FzLYDCZAwcdWRR h6l2L7dotY2TNyevGN3Z93h4cZeU1fB72RGILKMIhIYFS.XMlzkTleuDhPsfdkt_Y3tU_wxLUrnH p2NeL6vXLjJUyLR8Y8fCPe8DTFafyTDKJuOWXfl_pp7aR.3F66AROZqIgcNmV1wdDU6Rh5_eEkK6 _m0_6RopN3J7O6MUl3ITKVBuR9MJBCECBGNL78xoBH_gw4i_Kqq48Nuh.q_lpiQBLSW9czGzPIG8 4fGkK7CQ.bG6.uz9VHKnoe9l5iQgd.e6gORCAAzk6rEOuN3YotB1uPsbdSDcp3nKyhNs5YFktEWq I285siRPa80gLfezskTVoK5KPdpgheVo6nAjbYjY0aOzPzEPN8JkM2FVM9MQWgUt4u.CuCX9iQg4 oP2_h2GaZBb6jnkNrOliiFzezjc5z5BTUVJHAXKYW.h0uCbs7fdpMW7aKuuebQzscSfJSOBail2q I35H.7t9cHQoVoVW.adALBFZyt5URgXAguacbOu4OfMgBH5bQXdh7C1lro_3u87VnqHQsGJmfIna CZeB9tmkUAbiVdBLnQCH8cBFY1p9is2H6qEn6UmcDXqo9skwPe0vHFoKFqKJB3y4vwN05pQTy_g3 SsyGgDLSd.Ny7KsCGB9rjoecuAk4lYM6DJ9Y7dyGWnaNH32reLySXpDvRFkomkADhUMAJ8btB0FK YEPCfrfCejYQKRwrEoDNS7XwIkyj44E1dB5P.J5_piSGGhmx2WyzV8qTOon6iPfjD2f.8UgGk2zS Q2TLl.KZbtZEm2AinrPWd1Aa57s3Vf2JUpiT5JhkSAsDW_7Figu3REqQeX9HszWcLeFYtaEBx2Ws Mio1swS0SGyqQgCJc3TUFh9kDqeDZRwKAPD7YOMhF1qB3h79rkmyXwcJ_g69AClB4FMkoZCyVHmi DkI.TLJru7o.cEUcI9br59bTMY.lQ4XP1LXM6n0WZee0U3QlftlhqukzHBiOsidW6CcCnlVs3A.L 6pjno_50MqO_X4NIHVS3YiLj.y3SlCi7_Ii3tFhUJY12jCsF0X1U6BFx8q3xQrSozeHfZmHvBOf. urjQfcd3ykT.T1isYUACdjN6c0m8VWicOof8yUPYNfUuUO.LpozZzaOTOsnbhwN1G4nMOgtAj0I4 B7LeWaTtnHM_hfrF3gx0nQyeK.AhN5ZzISS3PuNpkHNN6EG3c_MCDq3rKbBEMNKSmvwqFfUgDmHA es8BHXqMI9hpLff5TrKgirvy7zVTq2VyihkYTCKqCiMS.mrsj0KaXh3HXt4_5UzqAYmoHMT8GT8x klw7SdHLvlPUgtUIjJY64UeGx0CyqgIL73Odih4HEdOlrzBkBFnPuJYs1jtFpUJNeVM7_p8kHpdz JDcHKSrMOU0RLQbvfysavUpUiQaurjPrXh8qYi3eJzCDZuR5SZGk7Po92GfUtZpimWQE.IibtYOc vOFuA4gezuQuYJLPP4FlPpE7Byvx_VWKhlNRDgfFBl69wq3jmpuDchO2c58EDAqatzfr__hqqg_V QskQKPWKqUpyiqSZIBAo8srJ9cY_EfyxpFOArk_PFA71qMXJdXSwNxJXf0KumHU8Ls_ES70uHkKP Nz_LaFsA7EBt95qGbyhk2cWGcUmxga0qDQ6H09G46HLDXFp5owCO0xd19a0fVk1hpZo5CE0B5gek bhBIyB8l3k8ZXYuee X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 02:54:08 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 677891c309ea9c7715e4aff065ee9f11; Sat, 05 Feb 2022 02:54: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: <20220205020612.GA85996@www.zefox.net> Date: Fri, 4 Feb 2022 18:54:03 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrH6v6tqFz3JnZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LN2lVWZO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3777 Lines: 116 On 2022-Feb-4, at 18:06, bob prohaska wrote: > On Fri, Feb 04, 2022 at 05:00:05PM -0800, Mark Millard wrote: >> On 2022-Feb-4, at 16:08, bob prohaska wrote: >>=20 >>> On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >>>> On 2022-Feb-4, at 13:44, bob prohaska wrote: >>>>=20 >>>=20 >>> It sounds like I simply have a corrupted c++. Perhaps just >>> set the old version aside and copy from the chroot directory >>> to /usr/bin ? Granted, other things might be wrong as well.=20 >>=20 >> I'm not so sure. My expectation is that if you first >> do (presuming not already in place at the time): >>=20 >> # sysctl kern.elf64.aslr.enable=3D0 >>=20 > On checking, that's already the case. I didn't change it > knowingly, likely it's been zero all along. So you get the failures even when: # sysctl kern.elf64.aslr.enable kern.elf64.aslr.enable: 0 ? That is different than in my context. I've never gotten the failure for the above type of context. It may be that for stable/13 's kernel the default is 0 . I did test and one can actually set: kern.elf64.aslr.enable from inside a chroot context, at least when one generally works as root. It changed the system's overall kern.elf64.aslr.enable status. >> and then to your buildworld buildkernel it will just work >> -- using your exising c++ compiler (system clang/clang++). >>=20 > Well, that hasn't happened yet. On the theme that if a > problem won't get better find out what makes it worse, > I've set it to 1 and am re-running buildworld with -j1. Okay. That you get the failures even when kern.elf64.aslr.enable is 0 means that my existing context for investigation is still problematical. >>=20 >> It seems very odd that such a setting would "uncorrupt" >> your clang/clang++ build (used under the name c++). I'm >> not aware of the compiler doing anything like the ntpd >> did, for which having ASLR enabled as a problem. >>=20 >> For far as I can tell, the setting changes the detailed >> behavior of mmap calls (including implicit ones in >> library code and such). >>=20 >> I've not found a way to look at the context just before >> the failure (without disturbing things enough via debugger >> activity that the failure does not happen). It is likely >> that I'll not manage to get such evidence that includes >> the failure. >>=20 >> I worry that the failures seen with your c++ involves a >> kernel bug but I do not see a way to investigate that. >=20 > I share your feeling that something isn't right but am > utterly ill equipped to posit what that might be. The=20 > most obvious recent strangeness with outbound network > traffic not working unless accompanied by an outbound > ping is most peculiar.=20 >=20 >=20 > Might this be a reason to try Peter Holm's stress2 suite? I > haven't played with it in a long time, not sure it'll even > compile now. "Success" in stress2 terms is a kernel panic. main [so: 14] has: # ls -Tld /usr/main-src/tools/test/stress2/ drwxr-xr-x 8 root wheel 33 Apr 28 15:20:54 2021 = /usr/main-src/tools/test/stress2/ But I'm not sure if it would be of any help or not. It may not have tests for causing vm.aslr_restarts to increment during operation and then seeing what works vs. what does not. stable/13 and before do not seem to have stress2/ . >> Another option might be to use a copy of the >> compiler from the chroot area to replace the >> normal system's copies, possibly renaming the >> old ones first (various names), including >> deal with clang.debug as well. This presumes >> that the 2 stable/13 builds are sufficiently >> compatible for such a substitution to work. >=20 > That sounds worth a try if no better ideas emerge. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 03:18:06 2022 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 977C019AAD0F for ; Sat, 5 Feb 2022 03:18:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrHff4znRz3jRD for ; Sat, 5 Feb 2022 03:18:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644031091; bh=ucpW3iCBw+ADL+Vro2bPbPlWCeN+DdWNNDR8+dSCeQI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nYUOX00r/rVQt5JUETAO/5nnbc/rDcz+7r7QcEA2+UqM2Fc6MSBlYIBpXbDKVJpVc4nm1jqDslIIW851RUN+L573smfn2YHHz5qlvRLzOrS+haFz3Lz3qFFbjJtAsOMhT+qaqiavFLSG0csaI4KBqjTCBMaWTL4cpy8IAdXP1d/5/qNUN/kd4dpBYRTZRjHiVo2SOfdcjr9bVLfPbjaNszXADsmCO+6BBcToCEGPDcKQTW/gUaFhw2ByIVHIYAvpsgAhLU8OfGEwEzXOhRVl/yIvoRxWiw20WQXf5P/axf7tP9hNuo6n+9sTHX3y/ZseBOiWuWRp6LTizEIka5aV5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644031091; bh=OAKPsu/dHu5hH9fXB9wERMyHfA3o2mz1vI9fg+5GLzJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sZYz9q5b+I9Hy9nrKcbNDcMIsG0lgl9P8OM1uPrYNDuOCTSNd6gIkx97dbuyopRGe499BRhVXOC6L6sFBf55CTUpZrv0iGkCnXQBwaPRmUh+T2SRQYxAfj6u3snormn4PqTYQ1iLx7oBmD/JfkpJgFo9Pexw8n+dgRsNvZSpz4Hx7aXxTXO6Yf2YKi+cFJJ7CWd4sDH8piEK6AajPgvPYpW6kbf4eWT+73wqI71kaeuvhDxjaKSMbo68p6kAi+jW/RoF+93gXG6BhgswFYew3wrnztyvvuW5RSTDZomfKV1DZXSdsaGGsdC4SWVGVBr4k9B5GO+wtRLcijQ8jpNQUQ== X-YMail-OSG: 6Z090YgVM1kqEBCPAVZLpeNrTjSpt28vm5w3y4oZoMcNA2K5KA1O.FpoMxVkrS1 3phrLdPsSHjI9TaQvlj4RVeSQCLKB9Fmzv1CFy5x461KYkl0JSHGpnRcLRr1rxYti4EZLJTTRO.G POJ94_t5H0yGjNebXsFH.qbR0IG4tVzApgSvcXAHKlK6fr4vmqshlSrqqrMdZhIFkvBXi2SDnvSD HCyXBs0tjR7kdnls0kmldn5jUFWgU.QSKExSXaCXq1CUlEXMhnGr1KD4NMHYv8RQvPi8aZr5iAm5 4iczeEb6Ln_Vw6pukez7ZMUGuZfSWU1BrigMSBi2dyvPp9oUevwKbzCm_riIpvO1Xbr7SHA5Zyxl SsiGb9eEoaG2.5xr.yiSlHqylpQ0GkAuYjxVqauZhpx5mtHxQvQY0WMfpdNk1XRdKnAvPMm7ueJ1 lB5WMD_zBl1radfrNjSGKzA6xU4BlzjN8H4vg9hnWf86fCAZNEKVNWyOVz77a6gT5PchCh2jUgHc tVGM7qho9q.3FrVJ31Xzi89sHNB14sbzbd3LCg3FJb7.v_NEsVL0qVanA7req3O.mc3hepUb_6n4 bX8ZFgeV3.1Q06O_agWBHIDtMLuHEiOaPsPbawEs9u5c8LL0i6yfZJZkhp_RvvEpQLUJXOSASOMt qynSFlg7d.uk0UplApxzu.SPQiPuRdNixDYsGj7XPjBa98W_Qyf.yaYUshzQgZQsBeKe8uSmawOx MLMn41ZfGTjIWe98bLMi.sWFMTQr9_NRtNvDB0X6rmdw2XfULLXIqbZ.7eQqeL0RWhHhWxSJDkth NSKchI9VEgX0jz7TsfFytRLh.X5erCLfozPqgRUn81Tc5Mi0vDpxty6a9H8hB7jLF_.1UDdms8we 9qdihB7yIxfblApj0JRAq5az8a89pU5S1ybbUXL7f5gneGaxbRtYpUvHANt8EWmAEhiyTD1Msgii go1mdAUyz8CxhTI_g2_JlDCBsvaUNSHVObr0x0CXK2FNLjOBmAH6HSreIIaItIufF_kz.GIeh3Zn hRg7wzLGq4WYHaaBbBHU5RDVpqF8tSLzRBqr6O1uUL50W8kWtFC4WDSrPBVRJtiWq5ZPaxZQk0Os N4U0KWfqu5q3ZMzR4jkHPclSvprhOnrvovXa.yRv0zPUxEkcD_PB0eYu6jemjqMN37XMuLX5xgnS JCRsYOiPS4_8kQ8LzmER_RTotOPn2rMnFmeEqsLd8Sf_xxtxkg_f8mpUp.vhkdQjc8ftPYXWB6dS z3RIZR8.JGXAdxyiJ.0KWOODlcT4p3PYF77wPZxkUTUt4.QNa1CKvEYHeNQvezyjXAmmgrRvGDhK UObi24BaydllDTmsEFLLJ5cowkm0_hnW9zpqYONR6YfxNgMGm_EkIA_4KNWWr6gxYm8Fi2TKaiP. gGRO_UpeM35TjCMY_gkladLPCgonpRnZo_zbhtk7jEaXS4OXHOv_rZsEPWPDQ_QnA4KSTeWs5AEB uWyzS492j5I708KibV2r.HX0UgI2q9MfWzyqddCuV_f88aQDgrkFveqSnXv9SdE34vqBkUdyaYGT hu67kAjDBQk_3LtLHI499WrlUYBk7xQSNAeRWO7vHaV2PbTC5yVS3hlLMVY4P7S8revB4NWJIdrv ouk9jBIZbrmyghLy2kbdVfbm3op7y7gX1JgJ0ao4AFGsYyGhsbYw4U4eRqoFvv4UCA7Xt_zX_bWE 5PYl.0d10KWcGH9me91i0qjaLy9GzeYGxRCv0q8CKchh8wip.YPaNi1LkzK4iG1ZWM54xJn5tLzm UwaNtjglH8jVnl0RZZq3vIhrc4YHbzY25yk.n40YifaHxCVren_1UhvDTpZEQDkrGJkKJHN2ZIPc tKOONpEVOkHdxzhJtWja55qdDBI07IQxnqhgeatqAaXBNGGkk787aE7vRY76airLepa_tU4ljG.P _oazkD6b2n0R7IcGYInHLaAvrUQC5amJZx3Z7WghzEqEDE_zWJKkVvURz5q0mXGrrT1UekohPi_T _JP7dVf_0qWaV2q4axRHr5NfOQ17.gswnbqtLV0G20KfnO1nMBYhrZ5UAIR9CUw9ddbW4XAybjSo aNg4RalzMgfSXbTRtvEYfYwWjUqOW7fGllzy1iftfAT3uU.vnFMrQmbWmtQbPP7acOjx9JBI060x EIda4o22CAARpabYtrQNAXh.opcAfITDx4bNLb_eaHUsVrJZ5ftF_QPAIAxPj_NjMdAoYBXPxz_Y cU2tHzHzDLeFOaZMxOOO3eTAnaWGUDJ5aAGKpkmq7zjtAnKewhqBAUOr.QU68uZolSFaqrJoxFIB l0VekIfwo5SVHr5xp X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 03:18:11 +0000 Received: by kubenode500.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e6d5c9b873b835a5aaefa42a733a44fb; Sat, 05 Feb 2022 03:18:08 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [an experiment-environment that leaves existing things alone] From: Mark Millard In-Reply-To: Date: Fri, 4 Feb 2022 19:18:06 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> References: <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JrHff4znRz3jRD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nYUOX00r; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4475 Lines: 133 On 2022-Feb-4, at 18:54, Mark Millard wrote: > On 2022-Feb-4, at 18:06, bob prohaska wrote: >=20 >> On Fri, Feb 04, 2022 at 05:00:05PM -0800, Mark Millard wrote: >>> On 2022-Feb-4, at 16:08, bob prohaska wrote: >>>=20 >>>> On Fri, Feb 04, 2022 at 02:44:01PM -0800, Mark Millard wrote: >>>>> On 2022-Feb-4, at 13:44, bob prohaska wrote: >>>>>=20 >>>>=20 >>>> It sounds like I simply have a corrupted c++. Perhaps just >>>> set the old version aside and copy from the chroot directory >>>> to /usr/bin ? Granted, other things might be wrong as well.=20 >>>=20 >>> I'm not so sure. My expectation is that if you first >>> do (presuming not already in place at the time): >>>=20 >>> # sysctl kern.elf64.aslr.enable=3D0 >>>=20 >> On checking, that's already the case. I didn't change it >> knowingly, likely it's been zero all along. >=20 > So you get the failures even when: >=20 > # sysctl kern.elf64.aslr.enable > kern.elf64.aslr.enable: 0 >=20 > ? >=20 > That is different than in my context. I've never > gotten the failure for the above type of context. >=20 > It may be that for stable/13 's kernel the > default is 0 . I looked at the source and it does default to 0 for stable/13 's source vintage that I have. It is too late now for an immediate test, but at some point after a reboot that has the value 0 in kern.elf64.aslr.enable still, try looking at: # sysctl vm.aslr_restarts before and after the .sh/.cpp testing that shows failures. If the value becomes non-zero at any point then some ASLR activity was attempted despite the 0 in kern.elf64.aslr.enable . > I did test and one can actually set: >=20 > kern.elf64.aslr.enable >=20 > from inside a chroot context, at least > when one generally works as root. It > changed the system's overall > kern.elf64.aslr.enable status. >=20 >>> and then to your buildworld buildkernel it will just work >>> -- using your exising c++ compiler (system clang/clang++). >>>=20 >> Well, that hasn't happened yet. On the theme that if a >> problem won't get better find out what makes it worse, >> I've set it to 1 and am re-running buildworld with -j1. >=20 > Okay. That you get the failures even when > kern.elf64.aslr.enable is 0 means that my > existing context for investigation is > still problematical. >=20 >>>=20 >>> It seems very odd that such a setting would "uncorrupt" >>> your clang/clang++ build (used under the name c++). I'm >>> not aware of the compiler doing anything like the ntpd >>> did, for which having ASLR enabled as a problem. >>>=20 >>> For far as I can tell, the setting changes the detailed >>> behavior of mmap calls (including implicit ones in >>> library code and such). >>>=20 >>> I've not found a way to look at the context just before >>> the failure (without disturbing things enough via debugger >>> activity that the failure does not happen). It is likely >>> that I'll not manage to get such evidence that includes >>> the failure. >>>=20 >>> I worry that the failures seen with your c++ involves a >>> kernel bug but I do not see a way to investigate that. >>=20 >> I share your feeling that something isn't right but am >> utterly ill equipped to posit what that might be. The=20 >> most obvious recent strangeness with outbound network >> traffic not working unless accompanied by an outbound >> ping is most peculiar.=20 >>=20 >>=20 >> Might this be a reason to try Peter Holm's stress2 suite? I >> haven't played with it in a long time, not sure it'll even >> compile now. "Success" in stress2 terms is a kernel panic. >=20 > main [so: 14] has: >=20 > # ls -Tld /usr/main-src/tools/test/stress2/ > drwxr-xr-x 8 root wheel 33 Apr 28 15:20:54 2021 = /usr/main-src/tools/test/stress2/ >=20 > But I'm not sure if it would be of any help or not. > It may not have tests for causing vm.aslr_restarts > to increment during operation and then seeing > what works vs. what does not. >=20 > stable/13 and before do not seem to have stress2/ . >=20 >>> Another option might be to use a copy of the >>> compiler from the chroot area to replace the >>> normal system's copies, possibly renaming the >>> old ones first (various names), including >>> deal with clang.debug as well. This presumes >>> that the 2 stable/13 builds are sufficiently >>> compatible for such a substitution to work. >>=20 >> That sounds worth a try if no better ideas emerge. >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 17:53:26 2022 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 151FB19B13A9 for ; Sat, 5 Feb 2022 17:53:24 +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 4Jrg4M1VVRz4jd0 for ; Sat, 5 Feb 2022 17:53:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 215HrQiY088888 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 5 Feb 2022 09:53:26 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 215HrQ9X088887; Sat, 5 Feb 2022 09:53:26 -0800 (PST) (envelope-from fbsd) Date: Sat, 5 Feb 2022 09:53:26 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Trying stress2 on RPi3 -current Message-ID: <20220205175326.GA88672@www.zefox.net> References: <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@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: <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> X-Rspamd-Queue-Id: 4Jrg4M1VVRz4jd0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-0.18 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.09)[-0.085]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 736 Lines: 23 On Fri, Feb 04, 2022 at 07:18:06PM -0800, Mark Millard wrote: > > > > main [so: 14] has: > > > > # ls -Tld /usr/main-src/tools/test/stress2/ > > drwxr-xr-x 8 root wheel 33 Apr 28 15:20:54 2021 /usr/main-src/tools/test/stress2/ > > > > But I'm not sure if it would be of any help or not. > > It may not have tests for causing vm.aslr_restarts > > to increment during operation and then seeing > > what works vs. what does not. > > > > stable/13 and before do not seem to have stress2/ . Just for curiosity's sake I've started stress2 on the Pi3 running -current. So far it seems to be running, causing the console to emit GEOM_ELI: md10 has been killed. GEOM_ELI: Device md10.eli destroyed. stress2: newblk leak: 17432/17436. From nobody Sun Feb 6 13:05:03 2022 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 9E7DE194B073 for ; Sun, 6 Feb 2022 13:05:17 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Js8dS3NFlz4Rd0 for ; Sun, 6 Feb 2022 13:05:16 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BKr6b5shzIYGngzY6Fdsk+iE7XS+2fKA+u4atIp7b/o=; b=DoUvOxcDCk1V4qTL/9bPagwMcc DPPzqvH8Rz5Zc8lLbICFX0rGJqQhel9prRFDdgsd3NNXgjJScIafSC0iG3+K+K+L8fE6GNiHb9p9A 3Hh+ik+PEgZHWIwBEoqvfuBuDd0EhNbKF42Pn+x8vZwBoiZHqksy7wzcsre8qSLj6Hgk=; Message-ID: Date: Sun, 6 Feb 2022 14:05:03 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64 Content-Language: en-US To: Marco Devesas Campos , freebsd-arm@freebsd.org References: From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: / X-Spam-Score: -0.4 X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2 X-Scan-Signature: f3964cfcdced09c670b81b4ffccb98ca X-Rspamd-Queue-Id: 4Js8dS3NFlz4Rd0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=DoUvOxcD; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 59265 Lines: 1653 On 2/2/22 13:23, Marco Devesas Campos wrote: > Hi List, > > Below is a very experimental patch, against stable/13, that brings bcm2835_audio to the 64bit era -- and with it, the vchiq driver (only to the extent required by audio -- no promises anything will work beyond that). > > There's work and more testing to be done (again, it’s experimental) but it seems to work quite nicely on my system so I thought I'd post it here so that > (1) people could test it out -- only tried it in an rpi-zero2 and I'd been keen to hear from people with access to rpis-3; and > (2) I could hear from people with actual experience in writing drivers, since this this is my first foray into kernel and arm programming, on possible issues with the code. One particular concern is that call to arm64_dcache_wbinv_range in the code that does DMA. > > To compile, just add `device vchiq` to your kernel config or use the GENERIC-VCHIQ config file included in the patch. (If you want any shot at building it on an rpi without swap, read the comments there) > > Best, > Marco > > > diff --git a/sys/arm/broadcom/bcm2835/bcm2835_audio.c b/sys/arm/broadcom/bcm2835/bcm2835_audio.c > index ae2c9a14fc62..5cd3f4bfd804 100644 > --- a/sys/arm/broadcom/bcm2835/bcm2835_audio.c > +++ b/sys/arm/broadcom/bcm2835/bcm2835_audio.c > @@ -27,6 +27,10 @@ > #include "opt_snd.h" > #endif > > +/* > + For the PRIu64 identifier > +*/ > +#include > #include > #include > > @@ -116,6 +120,12 @@ struct bcm2835_audio_chinfo { > uint64_t retrieved_samples; > uint64_t underruns; > int starved; > + struct bcm_log_vars { > + unsigned int bsize ; > + int slept_for_lack_of_space ; > + } log_vars; > +#define DEFAULT_LOG_VALUES \ > + ((struct bcm_log_vars) { .bsize = 0 , .slept_for_lack_of_space = 0 }) > }; > > struct bcm2835_audio_info { > @@ -135,6 +145,7 @@ struct bcm2835_audio_info { > > uint32_t flags_pending; > > + int verbose_trace; > /* Worker thread state */ > int worker_state; > }; > @@ -143,6 +154,35 @@ struct bcm2835_audio_info { > #define BCM2835_AUDIO_LOCKED(sc) mtx_assert(&(sc)->lock, MA_OWNED) > #define BCM2835_AUDIO_UNLOCK(sc) mtx_unlock(&(sc)->lock) > > +/* things that really have to be reported */ > +#define REPORT_ERROR(sc,...) \ > + do{ device_printf((sc)->dev,__VA_ARGS__); }while(0) > +/* things that shouldn't clobber the output */ > +#define INFORM_THAT(sc,...) \ > + do { \ > + if(sc->verbose_trace>0){ \ > + device_printf((sc)->dev,__VA_ARGS__); \ > + } \ > + }while(0) > +/* things that might clobber the output */ > +#define WARN_THAT(sc,...) \ > + do { \ > + if(sc->verbose_trace>1){ \ > + device_printf((sc)->dev,__VA_ARGS__); \ > + } \ > + }while(0) > +/* things that are expected to (will) clobber the output */ > +#define TRACE(sc,...) \ > + do { \ > + if(sc->verbose_trace>2){ \ > + device_printf((sc)->dev,__VA_ARGS__); \ > + } \ > + }while(0) > + > +/* Useful for circular buffer calcs */ > +#define MOD_DIFF(front,rear,mod) (((mod) + (front) - (rear)) % mod) > + > + > static const char * > dest_description(uint32_t dest) > { > @@ -214,10 +254,21 @@ bcm2835_audio_callback(void *param, const VCHI_CALLBACK_REASON_T reason, void *m > m.type); > } > } else if (m.type == VC_AUDIO_MSG_TYPE_COMPLETE) { > - struct bcm2835_audio_chinfo *ch = m.u.complete.cookie; > + unsigned int signaled = 0; > + struct bcm2835_audio_chinfo *ch ; > +#if defined(__aarch64__) > + ch = (void *) ((((size_t)m.u.complete.callback) << 32) > + | ((size_t)m.u.complete.cookie)); > +#else > + ch = (void *) (m.u.complete.cookie); > +#endif > + > > int count = m.u.complete.count & 0xffff; > int perr = (m.u.complete.count & (1U << 30)) != 0; > + > + TRACE(sc,"in:: count:0x%x perr:%d\n",m.u.complete.count,perr); > + > ch->callbacks++; > if (perr) > ch->underruns++; > @@ -237,18 +288,51 @@ bcm2835_audio_callback(void *param, const VCHI_CALLBACK_REASON_T reason, void *m > device_printf(sc->dev, "available_space == %d, count = %d, perr=%d\n", > ch->available_space, count, perr); > device_printf(sc->dev, > - "retrieved_samples = %lld, submitted_samples = %lld\n", > + "retrieved_samples = %"PRIu64", submitted_samples = %"PRIu64"\n", > ch->retrieved_samples, ch->submitted_samples); > } > - ch->available_space += count; > - ch->retrieved_samples += count; > } > - if (perr || (ch->available_space >= VCHIQ_AUDIO_PACKET_SIZE)) > + /* > + EXPERIMENTAL > + two lines were before that > + close bracket [ed: ftb of the {} matcher] > + */ > + ch->available_space += count; > + ch->retrieved_samples += count; > + /* > + EXPERIMENTAL > + Experimental: if VC says it's empty, believe it > + Has to come after the usual adjustments > + */ > + if(perr){ > + ch->available_space = VCHIQ_AUDIO_BUFFER_SIZE; > + perr = ch->retrieved_samples; // shd be != 0 > + } > + /* > + EXPERIMENTAL > + Throttle things a bit, so as to not > + tire VC out (TBR) > + */ > + > + if ((ch->available_space >= 2*VCHIQ_AUDIO_PACKET_SIZE)){ > cv_signal(&sc->worker_cv); > + signaled = 1; > + } > } > BCM2835_AUDIO_UNLOCK(sc); > + if(perr){ > + WARN_THAT(sc, > + "VC starved; reported %u for a total of %u\n" > + "worker %s\n" , > + count,perr, > + (signaled ? "signaled": "not signaled") > + ); > + } > } else > - printf("%s: unknown m.type: %d\n", __func__, m.type); > + WARN_THAT(sc, > + "%s: unknown m.type: %d\n", > + __func__, m.type > + ); > } > > /* VCHIQ stuff */ > @@ -260,13 +344,13 @@ bcm2835_audio_init(struct bcm2835_audio_info *sc) > /* Initialize and create a VCHI connection */ > status = vchi_initialise(&sc->vchi_instance); > if (status != 0) { > - printf("vchi_initialise failed: %d\n", status); > + REPORT_ERROR(sc,"vchi_initialise failed: %d\n", status); > return; > } > > status = vchi_connect(NULL, 0, sc->vchi_instance); > if (status != 0) { > - printf("vchi_connect failed: %d\n", status); > + REPORT_ERROR(sc,"vchi_connect failed: %d\n", status); > return; > } > > @@ -298,7 +382,7 @@ bcm2835_audio_release(struct bcm2835_audio_info *sc) > if (sc->vchi_handle != VCHIQ_SERVICE_HANDLE_INVALID) { > success = vchi_service_close(sc->vchi_handle); > if (success != 0) > - printf("vchi_service_close failed: %d\n", success); > + REPORT_ERROR(sc,"vchi_service_close failed: %d\n", success); > vchi_service_release(sc->vchi_handle); > sc->vchi_handle = VCHIQ_SERVICE_HANDLE_INVALID; > } > @@ -328,7 +412,10 @@ bcm2835_audio_start(struct bcm2835_audio_chinfo *ch) > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc, > + "%s: vchi_msg_queue failed (err %d)\n", > + __func__, ret > + ); > } > } > > @@ -343,11 +430,15 @@ bcm2835_audio_stop(struct bcm2835_audio_chinfo *ch) > m.type = VC_AUDIO_MSG_TYPE_STOP; > m.u.stop.draining = 0; > > + INFORM_THAT(sc,"sending stop\n"); > ret = vchi_msg_queue(sc->vchi_handle, > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc, > + "%s: vchi_msg_queue failed (err %d)\n", > + __func__, ret > + ); > } > } > > @@ -363,7 +454,10 @@ bcm2835_audio_open(struct bcm2835_audio_info *sc) > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc, > + "%s: vchi_msg_queue failed (err %d)\n", > + __func__, ret > + ); > } > } > > @@ -385,7 +479,10 @@ bcm2835_audio_update_controls(struct bcm2835_audio_info *sc, uint32_t volume, ui > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc, > + "%s: vchi_msg_queue failed (err %d)\n", > + __func__, ret > + ); > } > } > > @@ -405,7 +502,10 @@ bcm2835_audio_update_params(struct bcm2835_audio_info *sc, uint32_t fmt, uint32_ > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc, > + "%s: vchi_msg_queue failed (err %d)\n", > + __func__, ret > + ); > } > } > > @@ -413,18 +513,26 @@ static bool > bcm2835_audio_buffer_should_sleep(struct bcm2835_audio_chinfo *ch) > { > > + ch->log_vars.slept_for_lack_of_space = 0; > if (ch->playback_state != PLAYBACK_PLAYING) > return (true); > > /* Not enough data */ > - if (sndbuf_getready(ch->buffer) < VCHIQ_AUDIO_PACKET_SIZE) { > - printf("starve\n"); > + /* > + EXPERIMENTAL > + Take unsubmitted stuff into account > + */ > + if (sndbuf_getready(ch->buffer) > + - MOD_DIFF(ch->unsubmittedptr,sndbuf_getreadyptr(ch->buffer), > + sndbuf_getsize(ch->buffer)) > + < VCHIQ_AUDIO_PACKET_SIZE) { > ch->starved++; > return (true); > } > > /* Not enough free space */ > if (ch->available_space < VCHIQ_AUDIO_PACKET_SIZE) { > + ch->log_vars.slept_for_lack_of_space = 1; > return (true); > } > > @@ -445,22 +553,27 @@ bcm2835_audio_write_samples(struct bcm2835_audio_chinfo *ch, void *buf, uint32_t > m.type = VC_AUDIO_MSG_TYPE_WRITE; > m.u.write.count = count; > m.u.write.max_packet = VCHIQ_AUDIO_PACKET_SIZE; > - m.u.write.callback = NULL; > - m.u.write.cookie = ch; > +#if defined(__aarch64__) > + m.u.write.callback = (uint32_t)(((size_t) ch) >> 32) & 0xffffffff; > + m.u.write.cookie = (uint32_t)(((size_t) ch) & 0xffffffff); > +#else > + m.u.write.callback = (uint32_t) NULL; > + m.u.write.cookie = (uint32_t) ch; > +#endif > m.u.write.silence = 0; > > ret = vchi_msg_queue(sc->vchi_handle, > &m, sizeof m, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > > if (ret != 0) > - printf("%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > + REPORT_ERROR(sc,"%s: vchi_msg_queue failed (err %d)\n", __func__, ret); > > while (count > 0) { > int bytes = MIN((int)m.u.write.max_packet, (int)count); > ret = vchi_msg_queue(sc->vchi_handle, > buf, bytes, VCHI_FLAGS_BLOCK_UNTIL_QUEUED, NULL); > if (ret != 0) > - printf("%s: vchi_msg_queue failed: %d\n", > + REPORT_ERROR(sc,"%s: vchi_msg_queue failed: %d\n", > __func__, ret); > buf = (char *)buf + bytes; > count -= bytes; > @@ -492,6 +605,10 @@ bcm2835_audio_worker(void *data) > while ((sc->flags_pending == 0) && > bcm2835_audio_buffer_should_sleep(ch)) { > cv_wait_sig(&sc->worker_cv, &sc->lock); > + if((sc-> flags_pending == 0) > + && ch->log_vars.slept_for_lack_of_space) { > + TRACE(sc,"slept for lack of space\n"); > + } > } > flags = sc->flags_pending; > /* Clear pending flags */ > @@ -518,16 +635,32 @@ bcm2835_audio_worker(void *data) > BCM2835_AUDIO_LOCK(sc); > bcm2835_audio_reset_channel(&sc->pch); > ch->playback_state = PLAYBACK_IDLE; > + long sub_total = ch->submitted_samples; > + long retd = ch->retrieved_samples; > BCM2835_AUDIO_UNLOCK(sc); > + INFORM_THAT(sc, > + "stopped audio. submitted a total of %lu " > + "having been acked %lu\n", > + sub_total, retd > + ); > continue; > } > > /* Requested to start playback */ > if ((flags & AUDIO_PLAY) && > (ch->playback_state == PLAYBACK_IDLE)) { > + INFORM_THAT(sc, > + "starting audio\n" > + ); > + unsigned int bsize = sndbuf_getsize(ch->buffer); > BCM2835_AUDIO_LOCK(sc); > ch->playback_state = PLAYBACK_PLAYING; > + ch->log_vars.bsize = bsize; > BCM2835_AUDIO_UNLOCK(sc); > + INFORM_THAT(sc, > + "buffer size is %u\n", > + bsize > + ); > bcm2835_audio_start(ch); > } > > @@ -536,20 +669,75 @@ bcm2835_audio_worker(void *data) > > if (sndbuf_getready(ch->buffer) == 0) > continue; > + uint32_t i_count ;//, size, readyptr; > > - count = sndbuf_getready(ch->buffer); > + /* > + EXPERIMENTAL > + Take unsubmitted stuff into account > + */ > +/* > + count = i_count = sndbuf_getready(ch->buffer) ; > + readyptr = sndbuf_getreadyptr(ch->buffer); > +*/ > + count > + = i_count > + = sndbuf_getready(ch->buffer) > + - MOD_DIFF(ch->unsubmittedptr, > + sndbuf_getreadyptr(ch->buffer), > + sndbuf_getsize(ch->buffer)); > size = sndbuf_getsize(ch->buffer); > - readyptr = sndbuf_getreadyptr(ch->buffer); > + readyptr = ch->unsubmittedptr; > > + int size_changed=0; > + unsigned int available; > BCM2835_AUDIO_LOCK(sc); > - if (readyptr + count > size) > + if(size != ch->log_vars.bsize){ > + ch->log_vars.bsize = size; > + size_changed = 1; > + } > + available = ch->available_space; > + /* > + EXPERIMENTAL > + On arm64, got into situations where > + readyptr was less than a packet away > + from the end of the buffer, which led > + to count being set to 0 and, inexorably, starvation. > + Code below tries to take that into account. > + The problem might have been fixed with some of the other changes > + that were made in the meantime, but for now this works fine. > + */ > + if (readyptr + count > size){ > count = size - readyptr; > - count = min(count, ch->available_space); > - count -= (count % VCHIQ_AUDIO_PACKET_SIZE); > + } > + //count = min(count, ch->available_space); > + //count -= (count % VCHIQ_AUDIO_PACKET_SIZE); > + if(count > ch->available_space){ > + count = ch->available_space; > + count -= (count % VCHIQ_AUDIO_PACKET_SIZE); > + }else if (count > VCHIQ_AUDIO_PACKET_SIZE){ > + count -= (count % VCHIQ_AUDIO_PACKET_SIZE); > + }else if (size > count + readyptr) { > + count = 0; > + } > BCM2835_AUDIO_UNLOCK(sc); > - > - if (count < VCHIQ_AUDIO_PACKET_SIZE) > + if(count % VCHIQ_AUDIO_PACKET_SIZE != 0){ > + WARN_THAT(sc, > + "count: %u initial count: %u " > + "size: %u readyptr: %u available: %u" > + "\n", > + count,i_count,size,readyptr, available); > + } > + if(size_changed) INFORM_THAT(sc,"bsize changed to %u\n",size); > + > + //if (count < VCHIQ_AUDIO_PACKET_SIZE){ > + if (count == 0){ > + WARN_THAT(sc, > + "not enough room for a packet: count %d," > + " i_count %d, rptr %d, size %d\n", > + count, i_count, readyptr, size > + ); > continue; > + } > > buf = (uint8_t*)sndbuf_getbuf(ch->buffer) + readyptr; > > @@ -558,8 +746,17 @@ bcm2835_audio_worker(void *data) > ch->unsubmittedptr = (ch->unsubmittedptr + count) % sndbuf_getsize(ch->buffer); > ch->available_space -= count; > ch->submitted_samples += count; > + long sub = count; > + long sub_total = ch->submitted_samples; > + long retd = ch->retrieved_samples; > KASSERT(ch->available_space >= 0, ("ch->available_space == %d\n", ch->available_space)); > BCM2835_AUDIO_UNLOCK(sc); > + > + TRACE(sc, > + "submitted %lu for a total of %lu having been acked %lu; " > + "rptr %d, had %u available \n", > + sub, sub_total, retd, readyptr, available); > + > } > > BCM2835_AUDIO_LOCK(sc); > @@ -578,7 +775,9 @@ bcm2835_audio_create_worker(struct bcm2835_audio_info *sc) > sc->worker_state = WORKER_RUNNING; > if (kproc_create(bcm2835_audio_worker, (void*)sc, &newp, 0, 0, > "bcm2835_audio_worker") != 0) { > - printf("failed to create bcm2835_audio_worker\n"); > + REPORT_ERROR(sc, > + "failed to create bcm2835_audio_worker\n" > + ); > } > } > > @@ -611,6 +810,8 @@ bcmchan_init(kobj_t obj, void *devinfo, struct snd_dbuf *b, struct pcm_channel * > return NULL; > } > > + ch->log_vars = DEFAULT_LOG_VALUES; > + > BCM2835_AUDIO_LOCK(sc); > bcm2835_worker_update_params(sc); > BCM2835_AUDIO_UNLOCK(sc); > @@ -831,6 +1032,9 @@ vchi_audio_sysctl_init(struct bcm2835_audio_info *sc) > SYSCTL_ADD_INT(ctx, tree, OID_AUTO, "starved", > CTLFLAG_RD, &sc->pch.starved, > sc->pch.starved, "number of starved conditions"); > + SYSCTL_ADD_INT(ctx, tree, OID_AUTO, "trace", > + CTLFLAG_RW, &sc->verbose_trace, > + sc->verbose_trace, "enable tracing of transfers"); > } > > static void > @@ -862,6 +1066,7 @@ bcm2835_audio_delayed_init(void *xsc) > bcm2835_audio_open(sc); > sc->volume = 75; > sc->dest = DEST_AUTO; > + sc->verbose_trace = 0; > > if (mixer_init(sc->dev, &bcmmixer_class, sc)) { > device_printf(sc->dev, "mixer_init failed\n"); > diff --git a/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h b/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h > index 143c54385916..04292df1c261 100644 > --- a/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h > +++ b/sys/arm/broadcom/bcm2835/vc_vchi_audioserv_defs.h > @@ -114,8 +114,8 @@ typedef struct > typedef struct > { > uint32_t count; /* in bytes */ > - void *callback; > - void *cookie; > + uint32_t callback; > + uint32_t cookie; > uint16_t silence; > uint16_t max_packet; > } VC_AUDIO_WRITE_T; > @@ -131,8 +131,8 @@ typedef struct > typedef struct > { > int32_t count; /* Success value */ > - void *callback; > - void *cookie; > + uint32_t callback; > + uint32_t cookie; > } VC_AUDIO_COMPLETE_T; > > /* Message header for all messages in HOST->VC direction */ > diff --git a/sys/arm64/conf/GENERIC-VCHIQ b/sys/arm64/conf/GENERIC-VCHIQ > new file mode 100644 > index 000000000000..422ed425894c > --- /dev/null > +++ b/sys/arm64/conf/GENERIC-VCHIQ > @@ -0,0 +1,23 @@ > +# > +# GENERIC-VCHIQ > +# > +# Custom kernel for arm64 plus VCHIQ > +# > +# $FreeBSD$ > + > +#NO_UNIVERSE > + > +include GENERIC > +ident GENERIC-VCHIQ > + > +device vchiq > + > +# If you want to have any chance of compiling this in a RPI Zero 2 > +# uncomment the stuff below > + > +# nomakeoptions DEBUG > +# nomakeoptions WITH_CTF > +# nooptions DDB_CTF > +# makeoptions MALLOC_PRODUCTION=1 > + > + > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c > index 279aacd0880a..6d05b35006f0 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c > @@ -171,7 +171,7 @@ vchiq_platform_init(VCHIQ_STATE_T *state) > goto failed_load; > } > > - WARN_ON(((int)g_slot_mem & (PAGE_SIZE - 1)) != 0); > + WARN_ON(((size_t)g_slot_mem & (PAGE_SIZE - 1)) != 0); > > vchiq_slot_zero = vchiq_init_slots(g_slot_mem, g_slot_mem_size); > if (!vchiq_slot_zero) { > @@ -204,8 +204,8 @@ vchiq_platform_init(VCHIQ_STATE_T *state) > bcm_mbox_write(BCM2835_MBOX_CHAN_VCHIQ, (unsigned int)g_slot_phys); > > vchiq_log_info(vchiq_arm_log_level, > - "vchiq_init - done (slots %x, phys %x)", > - (unsigned int)vchiq_slot_zero, g_slot_phys); > + "vchiq_init - done (slots %zx, phys %zx)", > + (size_t)vchiq_slot_zero, g_slot_phys); > > vchiq_call_connected_callbacks(); > > @@ -393,13 +393,15 @@ pagelist_page_free(vm_page_t pp) > ** from increased speed as a result. > */ > > + > + > static int > create_pagelist(char __user *buf, size_t count, unsigned short type, > struct proc *p, BULKINFO_T *bi) > { > PAGELIST_T *pagelist; > vm_page_t* pages; > - unsigned long *addrs; > + uint32_t *addrs; > unsigned int num_pages, i; > vm_offset_t offset; > int pagelist_size; > @@ -453,7 +455,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type, > } > > vchiq_log_trace(vchiq_arm_log_level, > - "create_pagelist - %x (%d bytes @%p)", (unsigned int)pagelist, count, buf); > + "create_pagelist - %zx (%zu bytes @%p)", (size_t)pagelist, count, buf); > > if (!pagelist) > return -ENOMEM; > @@ -523,8 +525,12 @@ create_pagelist(char __user *buf, size_t count, unsigned short type, > (fragments - g_fragments_base)/g_fragment_size; > } > > +#if defined(__aarch64__) > + arm64_dcache_wbinv_range((vm_offset_t)buf,count); > +#else > pa = pmap_extract(PCPU_GET(curpmap), (vm_offset_t)buf); > dcache_wbinv_poc((vm_offset_t)buf, pa, count); > +#endif > > bus_dmamap_sync(bi->pagelist_dma_tag, bi->pagelist_dma_map, BUS_DMASYNC_PREWRITE); > > @@ -550,7 +556,7 @@ free_pagelist(BULKINFO_T *bi, int actual) > pagelist = bi->pagelist; > > vchiq_log_trace(vchiq_arm_log_level, > - "free_pagelist - %x, %d (%lu bytes @%p)", (unsigned int)pagelist, actual, pagelist->length, bi->buf); > + "free_pagelist - %zx, %d (%u bytes @%p)", (size_t)pagelist, actual, pagelist->length, bi->buf); > > num_pages = > (pagelist->length + pagelist->offset + PAGE_SIZE - 1) / > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c > index 763cd9ce9417..9c0ef541ab08 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c > @@ -442,8 +442,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > #define _IOC_TYPE(x) IOCGROUP(x) > > vchiq_log_trace(vchiq_arm_log_level, > - "vchiq_ioctl - instance %x, cmd %s, arg %p", > - (unsigned int)instance, > + "vchiq_ioctl - instance %zx, cmd %s, arg %p", > + (size_t)instance, > ((_IOC_TYPE(cmd) == VCHIQ_IOC_MAGIC) && > (_IOC_NR(cmd) <= VCHIQ_IOC_MAX)) ? > ioctl_names[_IOC_NR(cmd)] : "", arg); > @@ -745,8 +745,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > break; > } > vchiq_log_info(vchiq_arm_log_level, > - "found bulk_waiter %x for pid %d", > - (unsigned int)waiter, current->p_pid); > + "found bulk_waiter %zx for pid %d", > + (size_t)waiter, current->p_pid); > args.userdata = &waiter->bulk_waiter; > } > status = vchiq_bulk_transfer > @@ -776,8 +776,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > list_add(&waiter->list, &instance->bulk_waiter_list); > lmutex_unlock(&instance->bulk_waiter_list_mutex); > vchiq_log_info(vchiq_arm_log_level, > - "saved bulk_waiter %x for pid %d", > - (unsigned int)waiter, current->p_pid); > + "saved bulk_waiter %zx for pid %d", > + (size_t)waiter, current->p_pid); > > memcpy((void *) > &(((VCHIQ_QUEUE_BULK_TRANSFER_T *) > @@ -860,9 +860,9 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > if (args.msgbufsize < msglen) { > vchiq_log_error( > vchiq_arm_log_level, > - "header %x: msgbufsize" > + "header %zx: msgbufsize" > " %x < msglen %x", > - (unsigned int)header, > + (size_t)header, > args.msgbufsize, > msglen); > WARN(1, "invalid message " > @@ -1031,8 +1031,8 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > ret = -EFAULT; > } else { > vchiq_log_error(vchiq_arm_log_level, > - "header %x: bufsize %x < size %x", > - (unsigned int)header, args.bufsize, > + "header %zx: bufsize %x < size %x", > + (size_t)header, args.bufsize, > header->size); > WARN(1, "invalid size\n"); > ret = -EMSGSIZE; > @@ -1093,7 +1093,7 @@ vchiq_ioctl(struct cdev *cdev, u_long cmd, caddr_t arg, int fflag, > } break; > > case VCHIQ_IOC_LIB_VERSION: { > - unsigned int lib_version = (unsigned int)arg; > + size_t lib_version = (size_t)arg; > > if (lib_version < VCHIQ_VERSION_MIN) > ret = -EINVAL; > @@ -1342,9 +1342,9 @@ vchiq_close(struct cdev *dev, int flags __unused, int fmt __unused, > list); > list_del(pos); > vchiq_log_info(vchiq_arm_log_level, > - "bulk_waiter - cleaned up %x " > + "bulk_waiter - cleaned up %zx " > "for pid %d", > - (unsigned int)waiter, waiter->pid); > + (size_t)waiter, waiter->pid); > _sema_destroy(&waiter->bulk_waiter.event); > kfree(waiter); > } > @@ -1435,9 +1435,9 @@ vchiq_dump_platform_instances(void *dump_context) > instance = service->instance; > if (instance && !instance->mark) { > len = snprintf(buf, sizeof(buf), > - "Instance %x: pid %d,%s completions " > + "Instance %zx: pid %d,%s completions " > "%d/%d", > - (unsigned int)instance, instance->pid, > + (size_t)instance, instance->pid, > instance->connected ? " connected, " : > "", > instance->completion_insert - > @@ -1465,8 +1465,8 @@ vchiq_dump_platform_service_state(void *dump_context, VCHIQ_SERVICE_T *service) > char buf[80]; > int len; > > - len = snprintf(buf, sizeof(buf), " instance %x", > - (unsigned int)service->instance); > + len = snprintf(buf, sizeof(buf), " instance %zx", > + (size_t)service->instance); > > if ((service->base.callback == service_callback) && > user_service->is_vchi) { > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c > index 2e30dd7dc3de..ca848e6e9016 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c > @@ -31,6 +31,9 @@ > * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > +/* For the PRIu64 format identifier */ > +#include > + > #include "vchiq_core.h" > #include "vchiq_killable.h" > > @@ -392,9 +395,9 @@ make_service_callback(VCHIQ_SERVICE_T *service, VCHIQ_REASON_T reason, > VCHIQ_HEADER_T *header, void *bulk_userdata) > { > VCHIQ_STATUS_T status; > - vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %x, %x)", > + vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %tx, %tx)", > service->state->id, service->localport, reason_names[reason], > - (unsigned int)header, (unsigned int)bulk_userdata); > + (size_t)header, (size_t)bulk_userdata); > status = service->base.callback(reason, header, service->handle, > bulk_userdata); > if (status == VCHIQ_ERROR) { > @@ -417,13 +420,15 @@ vchiq_set_conn_state(VCHIQ_STATE_T *state, VCHIQ_CONNSTATE_T newstate) > vchiq_platform_conn_state_changed(state, oldstate, newstate); > } > > +#define ACTUAL_EVENT_SEM_ADDR(ref,offset)\ > + ((struct semaphore *)(((size_t) ref) + ((size_t) offset))) > static inline void > -remote_event_create(REMOTE_EVENT_T *event) > +remote_event_create(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) > { > event->armed = 0; > /* Don't clear the 'fired' flag because it may already have been set > ** by the other side. */ > - _sema_init(event->event, 0); > + _sema_init(ACTUAL_EVENT_SEM_ADDR(ref,event->event), 0); > } > > __unused static inline void > @@ -433,13 +438,18 @@ remote_event_destroy(REMOTE_EVENT_T *event) > } > > static inline int > -remote_event_wait(REMOTE_EVENT_T *event) > +remote_event_wait(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) > { > if (!event->fired) { > event->armed = 1; > +#if defined(__aarch64__) > + dsb(sy); > +#else > dsb(); > +#endif > + > if (!event->fired) { > - if (down_interruptible(event->event) != 0) { > + if (down_interruptible(ACTUAL_EVENT_SEM_ADDR(ref,event->event)) != 0) { > event->armed = 0; > return 0; > } > @@ -453,26 +463,30 @@ remote_event_wait(REMOTE_EVENT_T *event) > } > > static inline void > -remote_event_signal_local(REMOTE_EVENT_T *event) > +remote_event_signal_local(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) > { > +/* > + As per https://github.com/raspberrypi/linux/commit/a50c4c9a65779ca835746b5fd79d3d5278afbdbe > +*/ > + event->fired = 1; > event->armed = 0; > - up(event->event); > + up(ACTUAL_EVENT_SEM_ADDR(ref,event->event)); > } > > static inline void > -remote_event_poll(REMOTE_EVENT_T *event) > +remote_event_poll(VCHIQ_STATE_T *ref, REMOTE_EVENT_T *event) > { > if (event->fired && event->armed) > - remote_event_signal_local(event); > + remote_event_signal_local(ref,event); > } > > void > remote_event_pollall(VCHIQ_STATE_T *state) > { > - remote_event_poll(&state->local->sync_trigger); > - remote_event_poll(&state->local->sync_release); > - remote_event_poll(&state->local->trigger); > - remote_event_poll(&state->local->recycle); > + remote_event_poll(state , &state->local->sync_trigger); > + remote_event_poll(state , &state->local->sync_release); > + remote_event_poll(state , &state->local->trigger); > + remote_event_poll(state , &state->local->recycle); > } > > /* Round up message sizes so that any space at the end of a slot is always big > @@ -553,7 +567,7 @@ request_poll(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, int poll_type) > wmb(); > > /* ... and ensure the slot handler runs. */ > - remote_event_signal_local(&state->local->trigger); > + remote_event_signal_local(state, &state->local->trigger); > } > > /* Called from queue_message, by the slot handler and application threads, > @@ -640,8 +654,8 @@ process_free_queue(VCHIQ_STATE_T *state) > > rmb(); > > - vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=%x %x %x", > - state->id, slot_index, (unsigned int)data, > + vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=%tx %x %x", > + state->id, slot_index, (size_t)data, > local->slot_queue_recycle, slot_queue_available); > > /* Initialise the bitmask for services which have used this > @@ -675,13 +689,13 @@ process_free_queue(VCHIQ_STATE_T *state) > vchiq_log_error(vchiq_core_log_level, > "service %d " > "message_use_count=%d " > - "(header %x, msgid %x, " > + "(header %tx, msgid %x, " > "header->msgid %x, " > "header->size %x)", > port, > service_quota-> > message_use_count, > - (unsigned int)header, msgid, > + (size_t)header, msgid, > header->msgid, > header->size); > WARN(1, "invalid message use count\n"); > @@ -704,24 +718,24 @@ process_free_queue(VCHIQ_STATE_T *state) > up(&service_quota->quota_event); > vchiq_log_trace( > vchiq_core_log_level, > - "%d: pfq:%d %x@%x - " > + "%d: pfq:%d %x@%tx - " > "slot_use->%d", > state->id, port, > header->size, > - (unsigned int)header, > + (size_t)header, > count - 1); > } else { > vchiq_log_error( > vchiq_core_log_level, > "service %d " > "slot_use_count" > - "=%d (header %x" > + "=%d (header %tx" > ", msgid %x, " > "header->msgid" > " %x, header->" > "size %x)", > port, count, > - (unsigned int)header, > + (size_t)header, > msgid, > header->msgid, > header->size); > @@ -735,9 +749,9 @@ process_free_queue(VCHIQ_STATE_T *state) > pos += calc_stride(header->size); > if (pos > VCHIQ_SLOT_SIZE) { > vchiq_log_error(vchiq_core_log_level, > - "pfq - pos %x: header %x, msgid %x, " > + "pfq - pos %x: header %tx, msgid %x, " > "header->msgid %x, header->size %x", > - pos, (unsigned int)header, msgid, > + pos, (size_t)header, msgid, > header->msgid, header->size); > WARN(1, "invalid slot position\n"); > } > @@ -885,17 +899,16 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, > int slot_use_count; > > vchiq_log_info(vchiq_core_log_level, > - "%d: qm %s@%x,%x (%d->%d)", > + "%d: qm %s@%tx,%x (%d->%d)", > state->id, > msg_type_str(VCHIQ_MSG_TYPE(msgid)), > - (unsigned int)header, size, > + (size_t)header, size, > VCHIQ_MSG_SRCPORT(msgid), > VCHIQ_MSG_DSTPORT(msgid)); > > BUG_ON(!service); > BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK | > QMFLAGS_NO_MUTEX_UNLOCK)) != 0); > - > for (i = 0, pos = 0; i < (unsigned int)count; > pos += elements[i++].size) > if (elements[i].size) { > @@ -951,9 +964,9 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, > VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size); > } else { > vchiq_log_info(vchiq_core_log_level, > - "%d: qm %s@%x,%x (%d->%d)", state->id, > + "%d: qm %s@%tx,%x (%d->%d)", state->id, > msg_type_str(VCHIQ_MSG_TYPE(msgid)), > - (unsigned int)header, size, > + (size_t)header, size, > VCHIQ_MSG_SRCPORT(msgid), > VCHIQ_MSG_DSTPORT(msgid)); > if (size != 0) { > @@ -1017,7 +1030,7 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, > (lmutex_lock_interruptible(&state->sync_mutex) != 0)) > return VCHIQ_RETRY; > > - remote_event_wait(&local->sync_release); > + remote_event_wait(state, &local->sync_release); > > rmb(); > > @@ -1036,9 +1049,9 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, > int i, pos; > > vchiq_log_info(vchiq_sync_log_level, > - "%d: qms %s@%x,%x (%d->%d)", state->id, > + "%d: qms %s@%tx,%x (%d->%d)", state->id, > msg_type_str(VCHIQ_MSG_TYPE(msgid)), > - (unsigned int)header, size, > + (size_t)header, size, > VCHIQ_MSG_SRCPORT(msgid), > VCHIQ_MSG_DSTPORT(msgid)); > > @@ -1065,9 +1078,9 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service, > VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size); > } else { > vchiq_log_info(vchiq_sync_log_level, > - "%d: qms %s@%x,%x (%d->%d)", state->id, > + "%d: qms %s@%tx,%x (%d->%d)", state->id, > msg_type_str(VCHIQ_MSG_TYPE(msgid)), > - (unsigned int)header, size, > + (size_t)header, size, > VCHIQ_MSG_SRCPORT(msgid), > VCHIQ_MSG_DSTPORT(msgid)); > if (size != 0) { > @@ -1368,26 +1381,26 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue) > "Send Bulk to" : "Recv Bulk from"; > if (bulk->actual != VCHIQ_BULK_ACTUAL_ABORTED) > vchiq_log_info(SRVTRACE_LEVEL(service), > - "%s %c%c%c%c d:%d len:%d %x<->%x", > + "%s %c%c%c%c d:%d len:%d %tx<->%tx", > header, > VCHIQ_FOURCC_AS_4CHARS( > service->base.fourcc), > service->remoteport, > bulk->size, > - (unsigned int)bulk->data, > - (unsigned int)bulk->remote_data); > + (size_t)bulk->data, > + (size_t)bulk->remote_data); > else > vchiq_log_info(SRVTRACE_LEVEL(service), > "%s %c%c%c%c d:%d ABORTED - tx len:%d," > - " rx len:%d %x<->%x", > + " rx len:%d %tx<->%tx", > header, > VCHIQ_FOURCC_AS_4CHARS( > service->base.fourcc), > service->remoteport, > bulk->size, > bulk->remote_size, > - (unsigned int)bulk->data, > - (unsigned int)bulk->remote_data); > + (size_t)bulk->data, > + (size_t)bulk->remote_data); > } > > vchiq_complete_bulk(bulk); > @@ -1522,8 +1535,8 @@ parse_open(VCHIQ_STATE_T *state, VCHIQ_HEADER_T *header) > > fourcc = payload->fourcc; > vchiq_log_info(vchiq_core_log_level, > - "%d: prs OPEN@%x (%d->'%c%c%c%c')", > - state->id, (unsigned int)header, > + "%d: prs OPEN@%tx (%d->'%c%c%c%c')", > + state->id, (size_t)header, > localport, > VCHIQ_FOURCC_AS_4CHARS(fourcc)); > > @@ -1661,7 +1674,7 @@ parse_rx_slots(VCHIQ_STATE_T *state) > > header = (VCHIQ_HEADER_T *)(state->rx_data + > (state->rx_pos & VCHIQ_SLOT_MASK)); > - DEBUG_VALUE(PARSE_HEADER, (int)header); > + DEBUG_VALUE(PARSE_HEADER, (size_t)header); > msgid = header->msgid; > DEBUG_VALUE(PARSE_MSGID, msgid); > size = header->size; > @@ -1695,20 +1708,20 @@ parse_rx_slots(VCHIQ_STATE_T *state) > remoteport); > if (service) > vchiq_log_warning(vchiq_core_log_level, > - "%d: prs %s@%x (%d->%d) - " > + "%d: prs %s@%tx (%d->%d) - " > "found connected service %d", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, > service->localport); > } > > if (!service) { > vchiq_log_error(vchiq_core_log_level, > - "%d: prs %s@%x (%d->%d) - " > + "%d: prs %s@%zx (%d->%d) - " > "invalid/closed service %d", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, localport); > goto skip_message; > } > @@ -1734,12 +1747,12 @@ parse_rx_slots(VCHIQ_STATE_T *state) > min(16, size)); > } > > - if (((unsigned int)header & VCHIQ_SLOT_MASK) + calc_stride(size) > + if (((size_t)header & VCHIQ_SLOT_MASK) + calc_stride(size) > > VCHIQ_SLOT_SIZE) { > vchiq_log_error(vchiq_core_log_level, > - "header %x (msgid %x) - size %x too big for " > + "header %tx (msgid %x) - size %x too big for " > "slot", > - (unsigned int)header, (unsigned int)msgid, > + (size_t)header, (unsigned int)msgid, > (unsigned int)size); > WARN(1, "oversized for slot\n"); > } > @@ -1758,8 +1771,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) > service->peer_version = payload->version; > } > vchiq_log_info(vchiq_core_log_level, > - "%d: prs OPENACK@%x,%x (%d->%d) v:%d", > - state->id, (unsigned int)header, size, > + "%d: prs OPENACK@%tx,%x (%d->%d) v:%d", > + state->id, (size_t)header, size, > remoteport, localport, service->peer_version); > if (service->srvstate == > VCHIQ_SRVSTATE_OPENING) { > @@ -1776,8 +1789,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) > WARN_ON(size != 0); /* There should be no data */ > > vchiq_log_info(vchiq_core_log_level, > - "%d: prs CLOSE@%x (%d->%d)", > - state->id, (unsigned int)header, > + "%d: prs CLOSE@%tx (%d->%d)", > + state->id, (size_t)header, > remoteport, localport); > > mark_service_closing_internal(service, 1); > @@ -1794,8 +1807,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) > break; > case VCHIQ_MSG_DATA: > vchiq_log_info(vchiq_core_log_level, > - "%d: prs DATA@%x,%x (%d->%d)", > - state->id, (unsigned int)header, size, > + "%d: prs DATA@%tx,%x (%d->%d)", > + state->id, (size_t)header, size, > remoteport, localport); > > if ((service->remoteport == remoteport) > @@ -1819,14 +1832,19 @@ parse_rx_slots(VCHIQ_STATE_T *state) > break; > case VCHIQ_MSG_CONNECT: > vchiq_log_info(vchiq_core_log_level, > - "%d: prs CONNECT@%x", > - state->id, (unsigned int)header); > + "%d: prs CONNECT@%tx", > + state->id, (size_t)header); > state->version_common = ((VCHIQ_SLOT_ZERO_T *) > state->slot_data)->version; > up(&state->connect); > break; > case VCHIQ_MSG_BULK_RX: > - case VCHIQ_MSG_BULK_TX: { > + case VCHIQ_MSG_BULK_TX: > + WARN_ON(1); > + break; > +/* Appaz this isn't needed > +https://github.com/raspberrypi/linux/commit/14f4d72fb799a9b3170a45ab80d4a3ddad541960 > +{ > VCHIQ_BULK_QUEUE_T *queue; > WARN_ON(!state->is_master); > queue = (type == VCHIQ_MSG_BULK_RX) ? > @@ -1854,12 +1872,12 @@ parse_rx_slots(VCHIQ_STATE_T *state) > wmb(); > > vchiq_log_info(vchiq_core_log_level, > - "%d: prs %s@%x (%d->%d) %x@%x", > + "%d: prs %s@%tx (%d->%d) %x@%tx", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, > bulk->remote_size, > - (unsigned int)bulk->remote_data); > + (size_t)bulk->remote_data); > > queue->remote_insert++; > > @@ -1888,9 +1906,11 @@ parse_rx_slots(VCHIQ_STATE_T *state) > lmutex_unlock(&service->bulk_mutex); > if (resolved) > notify_bulks(service, queue, > - 1/*retry_poll*/); > + 1//retry_poll > + ); > } > } break; > +*/ > case VCHIQ_MSG_BULK_RX_DONE: > case VCHIQ_MSG_BULK_TX_DONE: > WARN_ON(state->is_master); > @@ -1912,10 +1932,10 @@ parse_rx_slots(VCHIQ_STATE_T *state) > if ((int)(queue->remote_insert - > queue->local_insert) >= 0) { > vchiq_log_error(vchiq_core_log_level, > - "%d: prs %s@%x (%d->%d) " > + "%d: prs %s@%tx (%d->%d) " > "unexpected (ri=%d,li=%d)", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, > queue->remote_insert, > queue->local_insert); > @@ -1932,11 +1952,11 @@ parse_rx_slots(VCHIQ_STATE_T *state) > queue->remote_insert++; > > vchiq_log_info(vchiq_core_log_level, > - "%d: prs %s@%x (%d->%d) %x@%x", > + "%d: prs %s@%tx (%d->%d) %x@%tx", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, > - bulk->actual, (unsigned int)bulk->data); > + bulk->actual, (size_t)bulk->data); > > vchiq_log_trace(vchiq_core_log_level, > "%d: prs:%d %cx li=%x ri=%x p=%x", > @@ -1958,14 +1978,14 @@ parse_rx_slots(VCHIQ_STATE_T *state) > break; > case VCHIQ_MSG_PADDING: > vchiq_log_trace(vchiq_core_log_level, > - "%d: prs PADDING@%x,%x", > - state->id, (unsigned int)header, size); > + "%d: prs PADDING@%tx,%x", > + state->id, (size_t)header, size); > break; > case VCHIQ_MSG_PAUSE: > /* If initiated, signal the application thread */ > vchiq_log_trace(vchiq_core_log_level, > - "%d: prs PAUSE@%x,%x", > - state->id, (unsigned int)header, size); > + "%d: prs PAUSE@%tx,%x", > + state->id, (size_t)header, size); > if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) { > vchiq_log_error(vchiq_core_log_level, > "%d: PAUSE received in state PAUSED", > @@ -1988,8 +2008,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) > break; > case VCHIQ_MSG_RESUME: > vchiq_log_trace(vchiq_core_log_level, > - "%d: prs RESUME@%x,%x", > - state->id, (unsigned int)header, size); > + "%d: prs RESUME@%tx,%x", > + state->id, (size_t)header, size); > /* Release the slot mutex */ > lmutex_unlock(&state->slot_mutex); > if (state->is_master) > @@ -2010,8 +2030,8 @@ parse_rx_slots(VCHIQ_STATE_T *state) > > default: > vchiq_log_error(vchiq_core_log_level, > - "%d: prs invalid msgid %x@%x,%x", > - state->id, msgid, (unsigned int)header, size); > + "%d: prs invalid msgid %x@%tx,%x", > + state->id, msgid, (size_t)header, size); > WARN(1, "invalid message\n"); > break; > } > @@ -2051,7 +2071,7 @@ slot_handler_func(void *v) > while (1) { > DEBUG_COUNT(SLOT_HANDLER_COUNT); > DEBUG_TRACE(SLOT_HANDLER_LINE); > - remote_event_wait(&local->trigger); > + remote_event_wait(state, &local->trigger); > > rmb(); > > @@ -2141,7 +2161,7 @@ recycle_func(void *v) > VCHIQ_SHARED_STATE_T *local = state->local; > > while (1) { > - remote_event_wait(&local->recycle); > + remote_event_wait(state, &local->recycle); > > process_free_queue(state); > } > @@ -2165,7 +2185,7 @@ sync_func(void *v) > int type; > unsigned int localport, remoteport; > > - remote_event_wait(&local->sync_trigger); > + remote_event_wait(state, &local->sync_trigger); > > rmb(); > > @@ -2179,10 +2199,10 @@ sync_func(void *v) > > if (!service) { > vchiq_log_error(vchiq_sync_log_level, > - "%d: sf %s@%x (%d->%d) - " > + "%d: sf %s@%tx (%d->%d) - " > "invalid/closed service %d", > state->id, msg_type_str(type), > - (unsigned int)header, > + (size_t)header, > remoteport, localport, localport); > release_message_sync(state, header); > continue; > @@ -2213,8 +2233,8 @@ sync_func(void *v) > service->peer_version = payload->version; > } > vchiq_log_info(vchiq_sync_log_level, > - "%d: sf OPENACK@%x,%x (%d->%d) v:%d", > - state->id, (unsigned int)header, size, > + "%d: sf OPENACK@%tx,%x (%d->%d) v:%d", > + state->id, (size_t)header, size, > remoteport, localport, service->peer_version); > if (service->srvstate == VCHIQ_SRVSTATE_OPENING) { > service->remoteport = remoteport; > @@ -2228,8 +2248,8 @@ sync_func(void *v) > > case VCHIQ_MSG_DATA: > vchiq_log_trace(vchiq_sync_log_level, > - "%d: sf DATA@%x,%x (%d->%d)", > - state->id, (unsigned int)header, size, > + "%d: sf DATA@%tx,%x (%d->%d)", > + state->id, (size_t)header, size, > remoteport, localport); > > if ((service->remoteport == remoteport) && > @@ -2248,8 +2268,8 @@ sync_func(void *v) > > default: > vchiq_log_error(vchiq_sync_log_level, > - "%d: sf unexpected msgid %x@%x,%x", > - state->id, msgid, (unsigned int)header, size); > + "%d: sf unexpected msgid %x@%tx,%x", > + state->id, msgid, (size_t)header, size); > release_message_sync(state, header); > break; > } > @@ -2282,7 +2302,7 @@ get_conn_state_name(VCHIQ_CONNSTATE_T conn_state) > VCHIQ_SLOT_ZERO_T * > vchiq_init_slots(void *mem_base, int mem_size) > { > - int mem_align = (VCHIQ_SLOT_SIZE - (int)mem_base) & VCHIQ_SLOT_MASK; > + int mem_align = (int)((VCHIQ_SLOT_SIZE - (long)mem_base) & VCHIQ_SLOT_MASK); > VCHIQ_SLOT_ZERO_T *slot_zero = > (VCHIQ_SLOT_ZERO_T *)((char *)mem_base + mem_align); > int num_slots = (mem_size - mem_align)/VCHIQ_SLOT_SIZE; > @@ -2334,8 +2354,8 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero, > if (slot_zero->magic != VCHIQ_MAGIC) { > vchiq_loud_error_header(); > vchiq_loud_error("Invalid VCHIQ magic value found."); > - vchiq_loud_error("slot_zero=%x: magic=%x (expected %x)", > - (unsigned int)slot_zero, slot_zero->magic, VCHIQ_MAGIC); > + vchiq_loud_error("slot_zero=%tx: magic=%x (expected %x)", > + (size_t)slot_zero, slot_zero->magic, VCHIQ_MAGIC); > vchiq_loud_error_footer(); > return VCHIQ_ERROR; > } > @@ -2348,9 +2368,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero, > if (slot_zero->version < VCHIQ_VERSION_MIN) { > vchiq_loud_error_header(); > vchiq_loud_error("Incompatible VCHIQ versions found."); > - vchiq_loud_error("slot_zero=%x: VideoCore version=%d " > + vchiq_loud_error("slot_zero=%tx: VideoCore version=%d " > "(minimum %d)", > - (unsigned int)slot_zero, slot_zero->version, > + (size_t)slot_zero, slot_zero->version, > VCHIQ_VERSION_MIN); > vchiq_loud_error("Restart with a newer VideoCore image."); > vchiq_loud_error_footer(); > @@ -2360,9 +2380,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero, > if (VCHIQ_VERSION < slot_zero->version_min) { > vchiq_loud_error_header(); > vchiq_loud_error("Incompatible VCHIQ versions found."); > - vchiq_loud_error("slot_zero=%x: version=%d (VideoCore " > + vchiq_loud_error("slot_zero=%tx: version=%d (VideoCore " > "minimum %d)", > - (unsigned int)slot_zero, VCHIQ_VERSION, > + (size_t)slot_zero, VCHIQ_VERSION, > slot_zero->version_min); > vchiq_loud_error("Restart with a newer kernel."); > vchiq_loud_error_footer(); > @@ -2375,25 +2395,25 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero, > (slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE)) { > vchiq_loud_error_header(); > if (slot_zero->slot_zero_size != sizeof(VCHIQ_SLOT_ZERO_T)) > - vchiq_loud_error("slot_zero=%x: slot_zero_size=%x " > + vchiq_loud_error("slot_zero=%tx: slot_zero_size=%x " > "(expected %zx)", > - (unsigned int)slot_zero, > + (size_t)slot_zero, > slot_zero->slot_zero_size, > sizeof(VCHIQ_SLOT_ZERO_T)); > if (slot_zero->slot_size != VCHIQ_SLOT_SIZE) > - vchiq_loud_error("slot_zero=%x: slot_size=%d " > + vchiq_loud_error("slot_zero=%tx: slot_size=%d " > "(expected %d", > - (unsigned int)slot_zero, slot_zero->slot_size, > + (size_t)slot_zero, slot_zero->slot_size, > VCHIQ_SLOT_SIZE); > if (slot_zero->max_slots != VCHIQ_MAX_SLOTS) > - vchiq_loud_error("slot_zero=%x: max_slots=%d " > + vchiq_loud_error("slot_zero=%tx: max_slots=%d " > "(expected %d)", > - (unsigned int)slot_zero, slot_zero->max_slots, > + (size_t)slot_zero, slot_zero->max_slots, > VCHIQ_MAX_SLOTS); > if (slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE) > - vchiq_loud_error("slot_zero=%x: max_slots_per_side=%d " > + vchiq_loud_error("slot_zero=%tx: max_slots_per_side=%d " > "(expected %d)", > - (unsigned int)slot_zero, > + (size_t)slot_zero, > slot_zero->max_slots_per_side, > VCHIQ_MAX_SLOTS_PER_SIDE); > vchiq_loud_error_footer(); > @@ -2478,24 +2498,24 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero, > state->data_use_count = 0; > state->data_quota = state->slot_queue_available - 1; > > - local->trigger.event = &state->trigger_event; > - remote_event_create(&local->trigger); > + local->trigger.event = offsetof(VCHIQ_STATE_T, trigger_event); > + remote_event_create(state, &local->trigger); > local->tx_pos = 0; > > - local->recycle.event = &state->recycle_event; > - remote_event_create(&local->recycle); > + local->recycle.event = offsetof(VCHIQ_STATE_T, recycle_event); > + remote_event_create(state, &local->recycle); > local->slot_queue_recycle = state->slot_queue_available; > > - local->sync_trigger.event = &state->sync_trigger_event; > - remote_event_create(&local->sync_trigger); > + local->sync_trigger.event = offsetof(VCHIQ_STATE_T, sync_trigger_event); > + remote_event_create(state, &local->sync_trigger); > > - local->sync_release.event = &state->sync_release_event; > - remote_event_create(&local->sync_release); > + local->sync_release.event = offsetof(VCHIQ_STATE_T, sync_release_event); > + remote_event_create(state, &local->sync_release); > > /* At start-of-day, the slot is empty and available */ > ((VCHIQ_HEADER_T *)SLOT_DATA_FROM_INDEX(state, local->slot_sync))->msgid > = VCHIQ_MSGID_PADDING; > - remote_event_signal_local(&local->sync_release); > + remote_event_signal_local(state, &local->sync_release); > > local->debug[DEBUG_ENTRIES] = DEBUG_MAX; > > @@ -2775,18 +2795,18 @@ release_service_messages(VCHIQ_SERVICE_T *service) > if ((port == service->localport) && > (msgid & VCHIQ_MSGID_CLAIMED)) { > vchiq_log_info(vchiq_core_log_level, > - " fsi - hdr %x", > - (unsigned int)header); > + " fsi - hdr %tx", > + (size_t)header); > release_slot(state, slot_info, header, > NULL); > } > pos += calc_stride(header->size); > if (pos > VCHIQ_SLOT_SIZE) { > vchiq_log_error(vchiq_core_log_level, > - "fsi - pos %x: header %x, " > + "fsi - pos %x: header %tx, " > "msgid %x, header->msgid %x, " > "header->size %x", > - pos, (unsigned int)header, > + pos, (size_t)header, > msgid, header->msgid, > header->size); > WARN(1, "invalid slot position\n"); > @@ -3360,10 +3380,10 @@ vchiq_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, > wmb(); > > vchiq_log_info(vchiq_core_log_level, > - "%d: bt (%d->%d) %cx %x@%x %x", > + "%d: bt (%d->%d) %cx %x@%tx %tx", > state->id, > service->localport, service->remoteport, dir_char, > - size, (unsigned int)bulk->data, (unsigned int)userdata); > + size, (size_t)bulk->data, (size_t)userdata); > > /* The slot mutex must be held when the service is being closed, so > claim it here to ensure that isn't happening */ > @@ -3382,7 +3402,12 @@ vchiq_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, > (dir == VCHIQ_BULK_TRANSMIT) ? > VCHIQ_POLL_TXNOTIFY : VCHIQ_POLL_RXNOTIFY); > } else { > - int payload[2] = { (int)bulk->data, bulk->size }; > + /* > + EXPERIMENTAL > + Makes more sense to me to have these as unsigned things > + even if size is an int (?) > + */ > + uint32_t payload[2] = { (uint32_t)(size_t)bulk->data, bulk->size }; > VCHIQ_ELEMENT_T element = { payload, sizeof(payload) }; > > status = queue_message(state, NULL, > @@ -3710,12 +3735,12 @@ vchiq_dump_state(void *dump_context, VCHIQ_STATE_T *state) > vchiq_dump(dump_context, buf, len + 1); > > len = snprintf(buf, sizeof(buf), > - " tx_pos=%x(@%x), rx_pos=%x(@%x)", > + " tx_pos=%x(@%tx), rx_pos=%x(@%tx)", > state->local->tx_pos, > - (uint32_t)state->tx_data + > + (size_t)state->tx_data + > (state->local_tx_pos & VCHIQ_SLOT_MASK), > state->rx_pos, > - (uint32_t)state->rx_data + > + (size_t)state->rx_data + > (state->rx_pos & VCHIQ_SLOT_MASK)); > vchiq_dump(dump_context, buf, len + 1); > > @@ -3817,8 +3842,8 @@ vchiq_dump_service_state(void *dump_context, VCHIQ_SERVICE_T *service) > vchiq_dump(dump_context, buf, len + 1); > > len = snprintf(buf, sizeof(buf), > - " Ctrl: tx_count=%d, tx_bytes=%llu, " > - "rx_count=%d, rx_bytes=%llu", > + " Ctrl: tx_count=%d, tx_bytes=%"PRIu64", " > + "rx_count=%d, rx_bytes=%"PRIu64"", > service->stats.ctrl_tx_count, > service->stats.ctrl_tx_bytes, > service->stats.ctrl_rx_count, > @@ -3826,8 +3851,8 @@ vchiq_dump_service_state(void *dump_context, VCHIQ_SERVICE_T *service) > vchiq_dump(dump_context, buf, len + 1); > > len = snprintf(buf, sizeof(buf), > - " Bulk: tx_count=%d, tx_bytes=%llu, " > - "rx_count=%d, rx_bytes=%llu", > + " Bulk: tx_count=%d, tx_bytes=%"PRIu64", " > + "rx_count=%d, rx_bytes=%"PRIu64"", > service->stats.bulk_tx_count, > service->stats.bulk_tx_bytes, > service->stats.bulk_rx_count, > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h > index 38ede407f4f4..4e3f41203bc4 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h > @@ -184,12 +184,21 @@ enum { > #if VCHIQ_ENABLE_DEBUG > > #define DEBUG_INITIALISE(local) int *debug_ptr = (local)->debug; > +#if defined(__aarch64__) > +#define DEBUG_TRACE(d) \ > + do { debug_ptr[DEBUG_ ## d] = __LINE__; dsb(sy); } while (0) > +#define DEBUG_VALUE(d, v) \ > + do { debug_ptr[DEBUG_ ## d] = (v); dsb(sy); } while (0) > +#define DEBUG_COUNT(d) \ > + do { debug_ptr[DEBUG_ ## d]++; dsb(sy); } while (0) > +#else > #define DEBUG_TRACE(d) \ > do { debug_ptr[DEBUG_ ## d] = __LINE__; dsb(); } while (0) > #define DEBUG_VALUE(d, v) \ > do { debug_ptr[DEBUG_ ## d] = (v); dsb(); } while (0) > #define DEBUG_COUNT(d) \ > do { debug_ptr[DEBUG_ ## d]++; dsb(); } while (0) > +#endif > > #else /* VCHIQ_ENABLE_DEBUG */ > > @@ -265,7 +274,7 @@ typedef struct vchiq_bulk_queue_struct { > typedef struct remote_event_struct { > int armed; > int fired; > - struct semaphore *event; > + uint32_t event; > } REMOTE_EVENT_T; > > typedef struct opaque_platform_state_t *VCHIQ_PLATFORM_STATE_T; > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c > index 1f849a09d854..22b988dcf436 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c > @@ -151,9 +151,9 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance) > list); > list_del(pos); > vchiq_log_info(vchiq_arm_log_level, > - "bulk_waiter - cleaned up %x " > + "bulk_waiter - cleaned up %tx " > "for pid %d", > - (unsigned int)waiter, waiter->pid); > + (size_t)waiter, waiter->pid); > _sema_destroy(&waiter->bulk_waiter.event); > > kfree(waiter); > @@ -454,8 +454,8 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data, > list_add(&waiter->list, &instance->bulk_waiter_list); > lmutex_unlock(&instance->bulk_waiter_list_mutex); > vchiq_log_info(vchiq_arm_log_level, > - "saved bulk_waiter %x for pid %d", > - (unsigned int)waiter, current->p_pid); > + "saved bulk_waiter %tx for pid %d", > + (size_t)waiter, current->p_pid); > } > > return status; > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c > index 53d1819c6cde..dc18678b99a3 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c > @@ -47,7 +47,7 @@ __FBSDID("$FreeBSD$"); > #include > > #include > -#include > +//#include > > #include "vchiq_arm.h" > #include "vchiq_2835.h" > @@ -118,13 +118,24 @@ bcm_vchiq_intr(void *arg) > void > remote_event_signal(REMOTE_EVENT_T *event) > { > +/* > + TODO: Linux puts a wmb() here. most calls to this func are > + preceded by a wmb(). Refactor? > +*/ > event->fired = 1; > - > /* The test on the next line also ensures the write on the previous line > has completed */ > + /* UPDATE: not on arm64, it would seem... */ > +#if defined(__aarch64__) > + dsb(sy); > +#endif > if (event->armed) { > /* trigger vc interrupt */ > +#if defined(__aarch64__) > + dsb(sy); > +#else > dsb(); > +#endif > vchiq_write_4(0x48, 0); > } > } > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h > index 72c362464cc2..d1cb9f1e1658 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_pagelist.h > @@ -42,10 +42,10 @@ > #define PAGELIST_READ_WITH_FRAGMENTS 2 > > typedef struct pagelist_struct { > - unsigned long length; > - unsigned short type; > - unsigned short offset; > - unsigned long addrs[1]; /* N.B. 12 LSBs hold the number of following > + uint32_t length; > + uint16_t type; > + uint16_t offset; > + uint32_t addrs[1]; /* N.B. 12 LSBs hold the number of following > pages at consecutive addresses. */ > } PAGELIST_T; > > diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c > index cc8ef2e071f8..f33c545cea45 100644 > --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c > +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c > @@ -398,7 +398,7 @@ EXPORT_SYMBOL(vchi_msg_queuev); > ***********************************************************/ > int32_t vchi_held_msg_release(VCHI_HELD_MSG_T *message) > { > - vchiq_release_message((VCHIQ_SERVICE_HANDLE_T)message->service, > + vchiq_release_message((VCHIQ_SERVICE_HANDLE_T)(size_t)message->service, > (VCHIQ_HEADER_T *)message->message); > > return 0; > @@ -444,7 +444,7 @@ int32_t vchi_msg_hold(VCHI_SERVICE_HANDLE_T handle, > *msg_size = header->size; > > message_handle->service = > - (struct opaque_vchi_service_t *)service->handle; > + (struct opaque_vchi_service_t *)(unsigned long)service->handle; > message_handle->message = header; > > return 0; > > Hi, I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no difference in available devices. I can try to boot it on a RPI3B+ on another time. What would be the expected outcome? Where should I look at (or listen to)? Ronald. From nobody Sun Feb 6 13:46:38 2022 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 AF4F119B6677 for ; Sun, 6 Feb 2022 13:46:42 +0000 (UTC) (envelope-from devesas.campos@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 4Js9YF3T2xz4kv4 for ; Sun, 6 Feb 2022 13:46:41 +0000 (UTC) (envelope-from devesas.campos@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id f17so20382045wrx.1 for ; Sun, 06 Feb 2022 05:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=cMk4T+7SS4VWKvltla3ZNgFaP5ZfkJSCoaRY80ch4so=; b=KZVe39ZLrwhYO3J8WDN5XvIBOLOOeWW4Er792kIpoLMPY6VtRQc+GBp5qpIStAZhkm FJ1Y8MuQxyI4Va1KleQCV8Wys+FbhBb0XnmQkdgop0UT99SwhzR606uitOLRnZKVnISh 3EJsgAl9dAygtcic6mbYquacdQMO3SScYwgu6lt52TTE14mLEKC6KMwWm1ssaevSZsuh lYSbYGk7VdzINNUz0KECRBli9Sa38h5gEdzpvcujwaaICDhlMKH0VgNygASFUB1kz+Ka zZO/1rx/D/7IERgLgRJIYmHhjkEo9bZ8X2UkDg+g+Q1bZHisd2yycg7hU3ehmFvLCAwy ppnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=cMk4T+7SS4VWKvltla3ZNgFaP5ZfkJSCoaRY80ch4so=; b=eq/HBEEfZbiUYQuzNbgLCTtfBg/t5apvIvqi0Fhz+fMYJ0iWiWOJnehyBiHKxSZD9+ BZ89z8UgWQrT1V/IWSJgdgvG4MyJoebNKck+RJ4JfHIi8D/JSzR6somPjiKle8CH7VSA /LMJCvrZCk2TBN6pYCM5TvJWpZ8jdqVzRNp1Med8ZsFgFZtqYZNg8xT4VZhcFcJLjnNT wvgPETodSnD5V2XSRCDiCDuaQY4k3UqN8TFgYjTPLYkvh0Yme2J7TrAg24SBVKaTNbtc By7lcsYICbB4vYf6aaryoZ+w4upBHOpfc+YDT+OqxW2etYfIPB9Tt4ub02vMm76J6KCA p79w== X-Gm-Message-State: AOAM531JQKu+KFM+FU+lcatOM4jKy95zo5rlIDWfMX8SECE7Q4xd0x+y c/6BCaThAetCc42pE/YjWms= X-Google-Smtp-Source: ABdhPJy8lgkGM2sD33RcSfltxB8V94WFGxSQwBFb1VzOVGBb2qwDcveVZE16vsVi49bPJWdXZkCDyQ== X-Received: by 2002:adf:e281:: with SMTP id v1mr6352596wri.308.1644155200410; Sun, 06 Feb 2022 05:46:40 -0800 (PST) Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181]) by smtp.gmail.com with ESMTPSA id j12sm7075139wru.38.2022.02.06.05.46.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Feb 2022 05:46:39 -0800 (PST) From: Marco Devesas Campos 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 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64 Date: Sun, 6 Feb 2022 13:46:38 +0000 References: To: Ronald Klop , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Js9YF3T2xz4kv4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KZVe39ZL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of devesascampos@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=devesascampos@gmail.com X-Spamd-Result: default: False [0.86 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[213.22.242.181:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.77)[0.774]; NEURAL_HAM_LONG(-0.25)[-0.252]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.83)[0.833]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1263 Lines: 52 Hi Ronald, Thanks so much for trying out the patch out. > On 6 Feb 2022, at 13:05, Ronald Klop wrote: >=20 > Hi, >=20 > I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no = difference in available devices. > I can try to boot it on a RPI3B+ on another time. I *think* the GPU/VC in RPI-4 is a very different beast from the others. = I'll look into it, but if you could give it a try on the 3+ I'd be much = obliged. >=20 > What would be the expected outcome? Where should I look at (or listen = to)? >=20 You should see something like=20 vchiq0: mem 0x7e00b840-0x7e00b87b irq 54 on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 in your dmesg output. The file /dev/vchiq should exist, as well as the following sysctl-s (I'm assuming no other audio devices are attached) % sysctl dev.pcm dev.pcm.0.trace: 0 ...=20 dev.pcm.0.dest: 0 ...=20 dev.pcm.0.%parent: vchiq0 ...=20 dev.pcm.0.%driver: pcm dev.pcm.0.%desc: VCHIQ audio =E2=80=A6 Then if you `cat < /dev/random > /dev/dsp` you should hear some static = coming out of whatever is connected to hdmi (maybe headphones too? otherwise = try setting `sysctl dev.pcm.0.dest=3D1`) Best, Marco= From nobody Sun Feb 6 20:08:40 2022 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 974FA19AD063 for ; Sun, 6 Feb 2022 20:08:43 +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 4JsL223P6Wz3LD5 for ; Sun, 6 Feb 2022 20:08:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 216K8eHb095840 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Feb 2022 12:08:41 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 216K8eN9095839; Sun, 6 Feb 2022 12:08:40 -0800 (PST) (envelope-from fbsd) Date: Sun, 6 Feb 2022 12:08:40 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Rpi3, -current, panic: data abort with spinlock held Message-ID: <20220206200840.GA95801@www.zefox.net> 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-Rspamd-Queue-Id: 4JsL223P6Wz3LD5 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.52 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.985]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.941]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.58)[0.578]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3118 Lines: 84 [repost, apologies if duplicate] While running -current on a Pi3, up to date as of a few days ago, an invocation of stress2 triggered the following panic: 20220205 10:25:26 all (7/809): arp.sh panic: data abort with spinlock held cpuid = 0 time = 1644085599 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2a0 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000007 generic_bs_rr_4() at generic_bs_rr_4+0xc dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130 intr_event_handle() at intr_event_handle+0xf0 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm2835_intc_intr() at bcm2835_intc_intr+0xa4 intr_event_handle() at intr_event_handle+0xf0 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm_lintc_intr() at bcm_lintc_intr+0x1d8 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0xc --- interrupt pcpu_cache_drain_safe() at pcpu_cache_drain_safe+0x2dc uma_reclaim_domain() at uma_reclaim_domain+0x1e4 uma_reclaim_worker() at uma_reclaim_worker+0x68 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 6 tid 100076 ] Stopped at kdb_enter+0x44: undefined f901c11f db> bt Tracing pid 6 tid 100076 td 0xffffa000012dc000 db_trace_self() at db_trace_self db_stack_trace() at db_stack_trace+0x11c db_command() at db_command+0x368 db_command_loop() at db_command_loop+0x54 db_trap() at db_trap+0xf8 kdb_trap() at kdb_trap+0x1cc handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0xf2000000 kdb_enter() at kdb_enter+0x44 vpanic() at vpanic+0x1b0 panic() at panic+0x44 data_abort() at data_abort+0x2a0 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000007 generic_bs_rr_4() at generic_bs_rr_4+0xc dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130 intr_event_handle() at intr_event_handle+0xf0 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm2835_intc_intr() at bcm2835_intc_intr+0xa4 intr_event_handle() at intr_event_handle+0xf0 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm_lintc_intr() at bcm_lintc_intr+0x1d8 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0xc --- interrupt pcpu_cache_drain_safe() at pcpu_cache_drain_safe+0x2dc uma_reclaim_domain() at uma_reclaim_domain+0x1e4 uma_reclaim_worker() at uma_reclaim_worker+0x68 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 db> Thanks for reading, if more details are wanted I'll try to supply them. I have tried to update and rebuild, but the builds stop with: /usr/src/contrib/llvm-project/llvm/lib/Target/X86/MCTargetDesc/X86ATTInstPrinter.cpp:38:6: error: expected '(' for function-style cast or type construction void X86ATTInstPrinter::printRegName(raw_ostream &OS, unsigned RegNo) const { ~~~ ^ bob prohaska ----- End forwarded message ----- From nobody Sun Feb 6 21:00:45 2022 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 3954D19A56B9 for ; Sun, 6 Feb 2022 21:00:48 +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 4JsMB70FPGz3vnX for ; Sun, 6 Feb 2022 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 CFC8A195B5 for ; Sun, 6 Feb 2022 21:00:45 +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 216L0jNi006956 for ; Sun, 6 Feb 2022 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 216L0jtx006955 for freebsd-arm@FreeBSD.org; Sun, 6 Feb 2022 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202202062100.216L0jtx006955@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, 6 Feb 2022 21:00:45 +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="16441812456.29eBB1.4269" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644181247; 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=6jqaGB2Pzw/ubwuvESRhyVbJe+XN1h3wi1onGXIikK4=; b=ER0nx1MqyHW0spJcG/n5WzZq86Zd/lfqjsjlcnh30qRUvPkQN/ee4UeH1e+RMvRPGw5vO4 HGRMQTFEXveqWWHDfh7dKpD6o4SqozgDtRk0ZJ19YOsP5dvTnFIaPaCql1QXE1+Httl5dx g3iO/k/rbbnYEQl8ENmJ07E6MmIrMD+GQQOR5SUe4uFbVh7ZrDI2PzI9Te5kuqiCbDtScQ j8CSLVAAoJOAdkbMx/JOoJgnMNBJ0lgwRqFb3/DdwDhJIK7Po6edg4M/NacKygE+MdsOse pXASFAFdaqYOhAW0R86V1Sr6+7rJhobwh479w2gp1N9HuQGFooueJfVS6s5f0g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644181247; a=rsa-sha256; cv=none; b=I9ByeBhimuceoNxKz/gxz/ClWhtbcCa6dUacIHFPROCOTQZ1KebH4pTRrRR9YZGRzc1c3i WpKTqPf5E4WmMZV68ZMQvUg1FqiyUMCGqcmo8nhI2zh3FoNzbL+v3M3pyZjuyORamuTM2B 0mHrmo/WrjOs9NeuOVqDS9Cd+SBO78jwu8buqGl9sEJTOEPQRHzTNssz6au9fooB1mQQdO JRY57vLIwnWThtTRj+Fx+62AyVBwqdhebL9OOolYODrtTXRsaxuftUhi8CyGenXQ4QjIWB h3hyDmnH7iiyxWtoYX3P/EaCL9g6mPwPXli5hQiwgpl7h8XElnpf4atbTXce9A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1796 Lines: 38 --16441812456.29eBB1.4269 Date: Sun, 6 Feb 2022 21:00:45 +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. --16441812456.29eBB1.4269 Date: Sun, 6 Feb 2022 21:00:45 +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.
--16441812456.29eBB1.4269-- From nobody Mon Feb 7 20:05:09 2022 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 72DF719A2017 for ; Mon, 7 Feb 2022 20:05:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsxvX3R5Fz3tsw for ; Mon, 7 Feb 2022 20:05:12 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5K7DThdV5LGsVGtz73prNzPkMLAYnIQkjMBAs2lkHb4=; b=pBllir3Kdat2JrIffyvCFM2uqv uz66G2nosAKTAHTPi4RWLQwj7X+XTIDy43RWW3JWgs93GOMfM5yxQWk4QlvFGlvrffk4lpHrCQAfR 3iDrk6KqRYQ0ET+ODseuPtvJ2rCV1NkoWCE0QWoetLjWe4dGLTnZG4a4cAw6xgZbukFw=; Message-ID: <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws> Date: Mon, 7 Feb 2022 21:05:09 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64 Content-Language: en-US To: Marco Devesas Campos , freebsd-arm@freebsd.org References: <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com> From: Ronald Klop In-Reply-To: <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: - X-Spam-Score: -1.2 X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2 X-Scan-Signature: 6c56b5a68734eff3bb82063186e8a5cf X-Rspamd-Queue-Id: 4JsxvX3R5Fz3tsw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=pBllir3K; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2306 Lines: 90 On 2/6/22 14:46, Marco Devesas Campos wrote: > Hi Ronald, > > Thanks so much for trying out the patch out. > >> On 6 Feb 2022, at 13:05, Ronald Klop wrote: >> >> Hi, >> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no difference in available devices. >> I can try to boot it on a RPI3B+ on another time. > > I *think* the GPU/VC in RPI-4 is a very different beast from the others. I'll > look into it, but if you could give it a try on the 3+ I'd be much obliged. > >> >> What would be the expected outcome? Where should I look at (or listen to)? >> > > You should see something like > > vchiq0: mem 0x7e00b840-0x7e00b87b irq 54 on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > > in your dmesg output. > > The file /dev/vchiq should exist, as well as the following sysctl-s (I'm > assuming no other audio devices are attached) > > % sysctl dev.pcm > dev.pcm.0.trace: 0 > ... > dev.pcm.0.dest: 0 > ... > dev.pcm.0.%parent: vchiq0 > ... > dev.pcm.0.%driver: pcm > dev.pcm.0.%desc: VCHIQ audio > … > > Then if you `cat < /dev/random > /dev/dsp` you should hear some static coming > out of whatever is connected to hdmi (maybe headphones too? otherwise try > setting `sysctl dev.pcm.0.dest=1`) > > Best, > Marco Hi, Booted the patched 14-CURRENT on the RPI3B+. dmesg diff: +vchiq0: mem 0x7e00b840-0x7e00b87b irq 54 on simplebus0 +vchiq: local ver 8 (min 3), remote ver 8. +pcm0: on vchiq0 [root@rpi3 ~]# cat /dev/sndstat Installed devices: pcm0: (play) default No devices installed from userspace. [root@rpi3 ~]# sysctl dev.pcm dev.pcm.0.trace: 0 dev.pcm.0.starved: 0 dev.pcm.0.freebuffer: 40000 dev.pcm.0.underruns: 0 dev.pcm.0.retrieved: 0 dev.pcm.0.submitted: 0 dev.pcm.0.callbacks: 0 dev.pcm.0.dest: 0 dev.pcm.0.mode: 3 dev.pcm.0.bitperfect: 0 dev.pcm.0.buffersize: 0 dev.pcm.0.play.vchanformat: s16le:2.0 dev.pcm.0.play.vchanrate: 48000 dev.pcm.0.play.vchanmode: fixed dev.pcm.0.play.vchans: 1 dev.pcm.0.%parent: vchiq0 dev.pcm.0.%pnpinfo: dev.pcm.0.%location: dev.pcm.0.%driver: pcm dev.pcm.0.%desc: VCHIQ audio dev.pcm.%parent: To play some audio I need to search some headphones first. :-) Ronald. From nobody Mon Feb 7 23:16:31 2022 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 3C97B19A7B98 for ; Mon, 7 Feb 2022 23:16:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jt28V4BRMz4lSp for ; Mon, 7 Feb 2022 23:16:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644275795; bh=mhPQvh0pdrODV9FSWL/2GFN78vLg1i9eNw105odoD6M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qxZKYm1F0E3Loyf6udyulAh0aylph9eyAaRRaiC3sJVjaOQL8i0W3AWlX+EU1bXxySup04hV75kKueFpz0bIe2/fiEd195LAnQvjiDzLlCpPCb3EjLiCkkAD9yxjvXLXyjvmZCG+B/k1ISbI8tNQ1FAgRNF6OQPBedOBDejUqALOIbbjT3MweBSijWk1IyYYYxnAw/GQpZ+RVEXU2IFQJBxtSI/bQXvKxO0zWc008D7mYOocN1M3H5WFo9JT1YtAytcSCbAuLxj0EDMYypKKr5FqYMC26pwKHZ9TQkmS45msNh/dLjfWBGJ7vXvC5aBOsheu7F/aETiByn9DD2XJvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644275795; bh=VX4ETLsASk+HT0Re0FMqk6DLox2OgOg3Wfgk75s04tI=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JSoKtfTQi5qgmrzWc3cszgEcwt85RY43ur2sLVuWRw3ch+mgb2q5GXnZpeSbsON48JAlKk2ilE974t2xwSAdmsNwTRX2k1krnjCuECo+aXEvJ7C8Yej3oZIY3cMnguKVy7YBXHkKCJYco90Bi3T5GW4ujTXvnrONtq+MtYcHahJbFNxoVYfxzRCyGNxycwExhIOQ6dCelnjFywidP5p9S2yy1AmNahWa1zy7Tgf8RLw1tahfFR4NkMivki8ZkUdRozfaIsBnd5gIE90lFwS/nZPZVHTGvYliNBtPP42/IaI5grN4KCxI/IIQ2sUQuV17yywkYPKqgvq0oCAozLb0yA== X-YMail-OSG: r4miil4VM1n7k22IT6AsmSiCShZUlCWQxMt9datKGE9kpfS49gCi99Ku6Vu3VY5 9Q_D07ke.XBdmIrVXNmzkTT3p8CAFsXhbBppOS74UZBCSsalkOuAwTdsO1L5GDAulNaREjiq4I7Y 5VW29I.PDuSWH_8gNfeDFQM2fho0qsOiu0puBQMds7EdVZsKf8CZ7CxsUGunhSR8fLcVvgLbRKNp sQyJLETPGj_HMtiFoSgo30DcmF1owzyHyJJY2EN3M5NtwntTdxOlCRZRIISRqTLayVwBH5Xl3W_7 p6IREWHcEfktp67nRylvyzcexbrEgzft_bnyf5uInTRdCryoTfGuSh8XSAin0ySpNoj4MGbsdgYP S.KQgeonx8WaMX4noWz_V65UdWXnlxyiKKkJ378CQ5npbf8oqlEV8m4KJNFhGqvFo3BwkOoFUVgD NoBRZt0l1w40XCg4e.7G.0H2eTjhmGzBbkBb.LUf15E9XiXl0gIItVIVdTDZ02TjnvrUS6EUbPTJ KUnusku5a5ak7A._3dNBvR0Q8wYmzXsASfF7ZwpyHx0a2_AfYxyBoqbnVCoeMItFQ.5ukyI._o7h 7wjXUsZjZ04.2n4xJvMxsF6Furgup_KN6IpjocXDR2R5VigCEEuWdZs6hVrPUuhTZehaBhmTDQ.K RyURzNqG2kYomsQU4e_cowcpyMAY5QJk9j0vgwh7XNobgQlhkRLQt9pEPd0smGuJLVvSke5290gs 3FnY5L_7FVW5C.hR.AaIHY5JrA3FZ8h19uORndFhtKjMVtN8wBiqvkog1UyF_xZZ58LDIKrEkapN IQLakf29j5GXStJ9aNO8vtAU32XRQcdfwGvmn09.WpCPS6.LGUC4XCSFYpTHAUfr_PL8BNRq0Kmg qd3pf_QUK51U.Wsm.tFwLmIzUdkmLeRGc.hM9plQJUAHj7FmFtTCnu.7GLrFgHyLksymIJxwCwMu xtbbLh1eIgzCBSLDx3n5yvYezENtmpkdMJwPEdBkAm2JP9kg6z83jpifD5AHBbRN0TtyF75pivmt yF3yCq4Ex5sLkXe8F_c9by8FwuPGGrdpkh.aOby9LX42_8qcifgkbFiota.eFSZVdv3jlJbI6jOM Jm3vKVUl0FEfX87fTeWT4ECmn.NsmcwNLLZSF8zpUwfTjTt6C3uHr7azorcTALjG1fNQ5NOgm3GR q.B56._synP9I_KJQCREDH.j3dFaR2z86adS0pQNlJJDRvYo_7IVpnif66iGmYWgItEvSfyGgENJ BSVLAGyg7_21fjMhmcPuyG9T1o8YoQ7k4a8tAplTikTYD5rRR5v8KO6YzdzbcfsDaTV4czF.NFI7 BpQPSZ8ORoCmCIyH_nVDIR7uFacQoy4E31KkJR7AdrJVv6c6OdAWzUffsKNBrafew72N2GQEsyHi k8qTzZWqBEMwAI9ziTaI_hK4KWE29bIXrH8oiW7aMxB0ox7KhVxV4swca265gftBqXjuqMO7Le2a N_Sl6IfnRmJHRWv4mKDoCZFjMt5nNuDz2aD9bPZK.X9yOsA1xZVZBQvVkH7sETWWLfK9mMO8GcMl cxR0_GDWrrs2YCp59DD0.6mTkylOh8JjOiU9jsys972gO6nYj5zMJxH1MzyP5PqgrSxB0sUTsb8e GMlKybcvvt50DFHu9VNnN5Ji6Ad5.fae5xXOedSARbGTE306ffGMNx91rToW8zhpwwUobOAiO7X9 Ht0mFjvje5Z4GEyfTmBJ7wfZAfHpHSosl9KvTy_jOVtTKV6nyDbIjEnYiu0g8j.Q4XNziRJ0h_Ii p2_SE3RhDVPps848ivI.fO3riOeG8nrhGRz0oCbh27j9T10djp5LNYNJqyYjT8S1Yw61x2FWfur_ N3BqZHXU3Hoord8Oa7n6xT8VisK2uPE8lHcKTBsJDp9jN_7AcQFNbBggTta5E4rtazZEmCBZobZo SQASu4R3gcZ2wdCHUP4GrYy5thfgL8jepE5QvGroJfBSgLtynNdpeWmTw.cSjXZ0ney7GrmXrFGK ZyqPvw4mJna8kmhEVhqcNeXXonSep7tWc6vd5wxRfrtY00meBHCoNj6c3oZJdq_513mNdeHmWD5g BTHCkna28wYAGIgAkl9WuN8x8WrAkIOwHOs10i.I6SwBCyCqyDdnsWra3QAeffGJ3WIvv6DlJ1IM oF964hTBrpy2EaDCYs9TVx9scSm_nC5x1Ac7Tmh06Qc4GOkNyfu.U.8crd21ti1Wn.Sjy3i6IqkQ mcyrvRJHlTfrfSzJaXrkWCLFZemgnPzX1dFUlfbW_UZfgfQfrYVUyPZFV4bMZWyKZLCQ_Grh7n.F u5GvCJMzF8aaBKQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Feb 2022 23:16:35 +0000 Received: by kubenode524.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 98c090baffbeae86c5386226890028c9; Mon, 07 Feb 2022 23:16:33 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 [the little bit of evidence about the compiler failures: a jemalloc-tie/ASLR-tie?] From: Mark Millard In-Reply-To: <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> Date: Mon, 7 Feb 2022 15:16:31 -0800 Cc: Free BSD , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220204214403.GA85107@www.zefox.net> <20220205000800.GA85644@www.zefox.net> <51D494E4-6D8D-49C7-8F0C-FD53311264A5@yahoo.com> <20220205020612.GA85996@www.zefox.net> <22832BFB-D1A2-4964-B7C0-3E8F97E9C5E0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jt28V4BRMz4lSp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qxZKYm1F; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 13859 Lines: 371 The primary evidence that I have gotten is dumps of part of the stack spanning the failure in the stable/13 c++ compiler. [Bob does his own buildworld buildkernel activities on the RPi3* in question, but normally absent the likes of make.conf and src.conf (or equivalents).] The following did lead to such a stack dump showing 8 bytes of 0xa5 that otherwise was 0x00. [The "junk:true" is a means of having jemalloc fill allocated memory with 0xa5 on allocation and 0x5a on deallocation (when jemalloc is built to allow such).] # ls -Tld /etc/malloc.conf=20 lrwxr-xr-x 1 root wheel 20 Feb 4 03:47:13 2022 /etc/malloc.conf -> = junk:true,abort:true It was around the beginning of the region that looked to have been stomped on: 0xffffffffa360: 00 00 00 00 00 00 00 00 a5 a5 a5 a5 a5 a5 a5 a5 = ................ Elsewhere in the dumped subregion of the stack (smaller addresses), there was also an example of "a5 a5 a5" : 0xffffffffae20: b8 3f 53 00 00 00 00 00 02 22 71 01 c1 a5 a5 a5 = .?S......"q..... There were no examples of "5a 5a" in the region and only the above examples of back to back a5's. (I did not check for back-to-back across lines.) What looks to be a valid fp/lr pair is: 0xffffffffa2d0: 70 a5 ff ff ff ff 00 00 6c 2b b7 02 00 00 00 00 = p.......l+...... But in the dump what the left part (fp part) refers to is: 0xffffffffa570: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... For reference for lr's "6c 2b b7 02": (lldb) disass -c 10 -a 0x2b72b6c c++`::ParseOptionalCXXScopeSpecifier(): 0x2b723fc <+0>: stp x29, x30, [sp, #-0x60]! 0x2b72400 <+4>: stp x28, x27, [sp, #0x10] 0x2b72404 <+8>: stp x26, x25, [sp, #0x20] 0x2b72408 <+12>: stp x24, x23, [sp, #0x30] 0x2b7240c <+16>: stp x22, x21, [sp, #0x40] 0x2b72410 <+20>: stp x20, x19, [sp, #0x50] 0x2b72414 <+24>: mov x29, sp 0x2b72418 <+28>: sub sp, sp, #0x250 ; =3D0x250=20 0x2b7241c <+32>: adrp x8, 9734 0x2b72420 <+36>: ldr x8, [x8, #0xe60] Most failures have the 0x01 after the ": ", but on occasion I've gotten one with 0x05 instead. The surrounding lines for the example at hand, that follow a simple, similarity-pattern, look like: 0xffffffffa450: 01 00 00 00 00 00 00 00 80 32 b2 55 00 00 00 00 = .........2.U.... 0xffffffffa460: 00 00 00 00 00 00 00 00 e2 34 b2 55 00 00 00 00 = .........4.U.... 0xffffffffa470: 01 00 00 00 00 00 00 00 00 33 b2 55 00 00 00 00 = .........3.U.... 0xffffffffa480: 00 00 00 00 00 00 00 00 f2 34 b2 55 00 00 00 00 = .........4.U.... 0xffffffffa490: 01 00 00 00 00 00 00 00 80 33 b2 55 00 00 00 00 = .........3.U.... 0xffffffffa4a0: 00 00 00 00 00 00 00 00 02 35 b2 55 00 00 00 00 = .........5.U.... 0xffffffffa4b0: 01 00 00 00 00 00 00 00 00 34 b2 55 00 00 00 00 = .........4.U.... 0xffffffffa4c0: 00 00 00 00 00 00 00 00 12 35 b2 55 00 00 00 00 = .........5.U.... 0xffffffffa4d0: 01 00 00 00 00 00 00 00 80 34 b2 55 00 00 00 00 = .........4.U.... 0xffffffffa4e0: 00 00 00 00 00 00 00 00 22 35 b2 55 00 00 00 00 = ........"5.U.... 0xffffffffa4f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa500: 00 00 00 00 00 00 00 00 5a 35 b2 55 00 00 00 00 = ........Z5.U.... 0xffffffffa510: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa520: 00 00 00 00 00 00 00 00 a2 35 b2 55 00 00 00 00 = .........5.U.... 0xffffffffa530: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa540: 00 00 00 00 00 00 00 00 ea 35 b2 55 00 00 00 00 = .........5.U.... 0xffffffffa550: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa560: 00 00 00 00 00 00 00 00 32 36 b2 55 00 00 00 00 = ........26.U.... 0xffffffffa570: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa580: 00 00 00 00 00 00 00 00 7a 36 b2 55 00 00 00 00 = ........z6.U.... 0xffffffffa590: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa5a0: 00 00 00 00 00 00 00 00 c2 36 b2 55 00 00 00 00 = .........6.U.... 0xffffffffa5b0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa5c0: 00 00 00 00 00 00 00 00 0a 37 b2 55 00 00 00 00 = .........7.U.... 0xffffffffa5d0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa5e0: 00 00 00 00 00 00 00 00 52 37 b2 55 00 00 00 00 = ........R7.U.... 0xffffffffa5f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa600: 00 00 00 00 00 00 00 00 9a 37 b2 55 00 00 00 00 = .........7.U.... 0xffffffffa610: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa620: 00 00 00 00 00 00 00 00 e2 37 b2 55 00 00 00 00 = .........7.U.... 0xffffffffa630: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa640: 00 00 00 00 00 00 00 00 2a 38 b2 55 00 00 00 00 = ........*8.U.... 0xffffffffa650: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa660: 00 00 00 00 00 00 00 00 72 38 b2 55 00 00 00 00 = ........r8.U.... 0xffffffffa670: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa680: 00 00 00 00 00 00 00 00 ba 38 b2 55 00 00 00 00 = .........8.U.... 0xffffffffa690: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa6a0: 00 00 00 00 00 00 00 00 02 39 b2 55 00 00 00 00 = .........9.U.... 0xffffffffa6b0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa6c0: 00 00 00 00 00 00 00 00 4a 39 b2 55 00 00 00 00 = ........J9.U.... 0xffffffffa6d0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa6e0: 00 00 00 00 00 00 00 00 92 39 b2 55 00 00 00 00 = .........9.U.... 0xffffffffa6f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa700: 00 00 00 00 00 00 00 00 da 39 b2 55 00 00 00 00 = .........9.U.... 0xffffffffa710: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa720: 00 00 00 00 00 00 00 00 22 3a b2 55 00 00 00 00 = ........":.U.... 0xffffffffa730: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa740: 00 00 00 00 00 00 00 00 6a 3a b2 55 00 00 00 00 = ........j:.U.... 0xffffffffa750: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa760: 00 00 00 00 00 00 00 00 b2 3a b2 55 00 00 00 00 = .........:.U.... 0xffffffffa770: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa780: 00 00 00 00 00 00 00 00 fa 3a b2 55 00 00 00 00 = .........:.U.... 0xffffffffa790: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa7a0: 00 00 00 00 00 00 00 00 42 3b b2 55 00 00 00 00 = ........B;.U.... 0xffffffffa7b0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa7c0: 00 00 00 00 00 00 00 00 8a 3b b2 55 00 00 00 00 = .........;.U.... 0xffffffffa7d0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa7e0: 00 00 00 00 00 00 00 00 d2 3b b2 55 00 00 00 00 = .........;.U.... 0xffffffffa7f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa800: 00 00 00 00 00 00 00 00 1a 3c b2 55 00 00 00 00 = .........<.U.... 0xffffffffa810: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa820: 00 00 00 00 00 00 00 00 62 3c b2 55 00 00 00 00 = ........b<.U.... 0xffffffffa830: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa840: 00 00 00 00 00 00 00 00 aa 3c b2 55 00 00 00 00 = .........<.U.... 0xffffffffa850: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa860: 00 00 00 00 00 00 00 00 f2 3c b2 55 00 00 00 00 = .........<.U.... 0xffffffffa870: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa880: 00 00 00 00 00 00 00 00 3a 3d b2 55 00 00 00 00 = ........:=3D.U.... 0xffffffffa890: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa8a0: 00 00 00 00 00 00 00 00 82 3d b2 55 00 00 00 00 = .........=3D.U.... 0xffffffffa8b0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa8c0: 00 00 00 00 00 00 00 00 ca 3d b2 55 00 00 00 00 = .........=3D.U.... 0xffffffffa8d0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa8e0: 00 00 00 00 00 00 00 00 12 3e b2 55 00 00 00 00 = .........>.U.... 0xffffffffa8f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa900: 00 00 00 00 00 00 00 00 5a 3e b2 55 00 00 00 00 = ........Z>.U.... 0xffffffffa910: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa920: 00 00 00 00 00 00 00 00 a2 3e b2 55 00 00 00 00 = .........>.U.... 0xffffffffa930: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa940: 00 00 00 00 00 00 00 00 ea 3e b2 55 00 00 00 00 = .........>.U.... 0xffffffffa950: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa960: 00 00 00 00 00 00 00 00 32 3f b2 55 00 00 00 00 = ........2?.U.... 0xffffffffa970: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa980: 00 00 00 00 00 00 00 00 7a 3f b2 55 00 00 00 00 = ........z?.U.... 0xffffffffa990: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa9a0: 00 00 00 00 00 00 00 00 c2 3f b2 55 00 00 00 00 = .........?.U.... 0xffffffffa9b0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa9c0: 00 00 00 00 00 00 00 00 0a 40 b2 55 00 00 00 00 = .........@.U.... 0xffffffffa9d0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffa9e0: 00 00 00 00 00 00 00 00 52 40 b2 55 00 00 00 00 = ........R@.U.... 0xffffffffa9f0: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffaa00: 00 00 00 00 00 00 00 00 9a 40 b2 55 00 00 00 00 = .........@.U.... 0xffffffffaa10: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffaa20: 00 00 00 00 00 00 00 00 e2 40 b2 55 00 00 00 00 = .........@.U.... 0xffffffffaa30: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffaa40: 00 00 00 00 00 00 00 00 2a 41 b2 55 00 00 00 00 = ........*A.U.... 0xffffffffaa50: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffaa60: 00 00 00 00 00 00 00 00 72 41 b2 55 00 00 00 00 = ........rA.U.... 0xffffffffaa70: 01 00 00 00 00 00 00 00 c0 0d b1 55 00 00 00 00 = ...........U.... 0xffffffffaa80: 00 00 00 00 00 00 00 00 ba 41 b2 55 00 00 00 00 = .........A.U.... When the 0x05's show up they are instead of the 0x01's, just after the ": ". After that the pattern is different. But quickly something looks like another fp/lr pair in memory, and tha, in turn, it references another: 0xffffffffaa90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = ................ 0xffffffffaaa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = ................ 0xffffffffaab0: 00 00 00 00 00 00 00 00 44 c4 95 07 0e 02 46 57 = ........D.....FW 0xffffffffaac0: 10 ab ff ff ff ff 00 00 8c c6 aa 02 00 00 00 00 = ................ . . . 0xffffffffab10: 90 ac ff ff ff ff 00 00 e0 18 ab 02 00 00 00 00 = ................ . . . But after that the following does not seem to fit the pattern: 0xffffffffac90: 00 ac ff ff ff ff 00 00 44 c4 95 07 0e 02 46 57 = ........D.....FW and: 0xffffffffac00: 01 00 00 00 00 00 00 00 18 ae ff ff ff ff 00 00 = ................ The a5 sequences make me wonder if jemalloc assigned a memory allocation to stack space or was told to handle a stack address as if it was an assigned address for some aspects of an allocation (if that can even be requested). I wonder if there is any chance of ASLR being involved with the stack and memory allocation possibly overlapping. But I've really no clue. I've given up on trying to isolate what is going on for the compiler failures. I've only been able to see after the failure, not just before: debugger interactions with the compiler process in times close to the failure point in the code prevent the failure. I've not found any alternative that avoids such. This is on top of the issue that the plain-runs (no debugger) vary in behavior, sometimes running to completion, sometimes stopping at similar but varying places in the source code being processed. There is still no known way to get a full reproduction of failure details each time. (Which instance of the example type of source code being compiled at the point of failure does vary.) For reference: I've been using .sh/.cpp pairs that Bob published and a copy of the c++ from his system to investigate. The .cpp is large. Bob's RPi3* is a RAM+SWAP context of: 1 GiBYTe + 2 GiByte and I made such a context on a RPi3* as well. But I ran his stable/13 c++ on a system with a non-debug main [so: 14] kernel and either a main world or a stable/13 chroot. From the chroot: # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #28 = main-n252475-e76c0108990b-dirty: Sat Jan 15 23:39:27 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400047 1300524 # freebsd-version -ru 14.0-CURRENT 13.0-STABLE # ~/fbsd-based-on-what-commit.sh -C /usr/13S-src/ branch: stable/13 merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f merge-base: CommitDate: 2022-01-15 12:55:32 +0000 a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore = debugger-injected signals left after detaching Bob's recent stable/13 context (kernel too) is more recent than mine. So the problems has been observed over a range of contexts. But, as I said, I've given up on finding a way to isolate whatever is going on. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 8 08:49:10 2022 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 5015219B235F for ; Tue, 8 Feb 2022 08:49:19 +0000 (UTC) (envelope-from SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JtGsB348yz3s5M for ; Tue, 8 Feb 2022 08:49:18 +0000 (UTC) (envelope-from SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl) Date: Tue, 8 Feb 2022 09:49:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1644310151; 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: in-reply-to:in-reply-to:references:references; bh=2yCPdD44X+yDMzrSySzYkRRSbbvePa6N9O9/BKMEY1Q=; b=N6+xdBzHB9kp7T/wa5U59kukuIKlCK9H2ViWfZCedFuzxcJILz0sgmTLgbXJQU2q4LP+Rh 8zgz8wMMK4C3lO3GmXxQIbV5eeawfRt4StD0suHMT/R1TGpo4+GD22YfZ9jKwfQiHNyjOs 6gGII7J4C7st1tpK9GOkcA5k0mh0MrAfCJyC1PoZX2ryMW5unA4+Tm0V6ykkz9Fi9yhBU6 UmI7Qq7opcOTgSurd4P5loCvEML+i2XqAcvRH/OBArdsd4B5yfpFMA7UudZSA/FptDHD66 CbXWQLs40U4IVWeF2TWYxwbgk+qCfT7L7RRFsSxQ4lNRxcpDv5FN1GGySnh/fA== From: Ronald Klop To: Ronald Klop Cc: Marco Devesas Campos , freebsd-arm@freebsd.org Message-ID: <106195874.50.1644310150579@localhost> In-Reply-To: <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws> References: <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com> <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws> Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64 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="----=_Part_49_814679107.1644310150512" X-Mailer: Realworks (594.13.3083cc2) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JtGsB348yz3s5M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=N6+xdBzH; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=O5G7=SX=klop.ws=ronald-lists@realworks.nl]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7347 Lines: 255 ------=_Part_49_814679107.1644310150512 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =20 Van: Ronald Klop Datum: maandag, 7 februari 2022 21:05 Aan: Marco Devesas Campos , freebsd-arm@freebsd.o= rg Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm= 64 >=20 > On 2/6/22 14:46, Marco Devesas Campos wrote: > > Hi Ronald, > > > > Thanks so much for trying out the patch out. > > > >> On 6 Feb 2022, at 13:05, Ronald Klop wrote: > >> > >> Hi, > >> > >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no differe= nce in available devices. > >> I can try to boot it on a RPI3B+ on another time. > > > > I *think* the GPU/VC in RPI-4 is a very different beast from the others= . I'll > > look into it, but if you could give it a try on the 3+ I'd be much obli= ged. > > > >> > >> What would be the expected outcome? Where should I look at (or listen = to)? > >> > > > > You should see something like > > > > vchiq0: mem 0x7e00b840-0x7e00b87b irq 54 on simplebu= s0 > > vchiq: local ver 8 (min 3), remote ver 8. > > pcm0: on vchiq0 > > > > in your dmesg output. > > > > The file /dev/vchiq should exist, as well as the following sysctl-s (I'= m > > assuming no other audio devices are attached) > > > > % sysctl dev.pcm > > dev.pcm.0.trace: 0 > > ... > > dev.pcm.0.dest: 0 > > ... > > dev.pcm.0.%parent: vchiq0 > > ... > > dev.pcm.0.%driver: pcm > > dev.pcm.0.%desc: VCHIQ audio > > =E2=80=A6 > > > > Then if you `cat < /dev/random > /dev/dsp` you should hear some static = coming > > out of whatever is connected to hdmi (maybe headphones too? otherwise t= ry > > setting `sysctl dev.pcm.0.dest=3D1`) > > > > Best, > > Marco >=20 >=20 > Hi, >=20 > Booted the patched 14-CURRENT on the RPI3B+. >=20 > dmesg diff: > +vchiq0: mem 0x7e00b840-0x7e00b87b irq 54 on simplebus0 > +vchiq: local ver 8 (min 3), remote ver 8. > +pcm0: on vchiq0 >=20 > [root@rpi3 ~]# cat /dev/sndstat > Installed devices: > pcm0: (play) default > No devices installed from userspace. >=20 > [root@rpi3 ~]# sysctl dev.pcm > dev.pcm.0.trace: 0 > dev.pcm.0.starved: 0 > dev.pcm.0.freebuffer: 40000 > dev.pcm.0.underruns: 0 > dev.pcm.0.retrieved: 0 > dev.pcm.0.submitted: 0 > dev.pcm.0.callbacks: 0 > dev.pcm.0.dest: 0 > dev.pcm.0.mode: 3 > dev.pcm.0.bitperfect: 0 > dev.pcm.0.buffersize: 0 > dev.pcm.0.play.vchanformat: s16le:2.0 > dev.pcm.0.play.vchanrate: 48000 > dev.pcm.0.play.vchanmode: fixed > dev.pcm.0.play.vchans: 1 > dev.pcm.0.%parent: vchiq0 > dev.pcm.0.%pnpinfo: > dev.pcm.0.%location: > dev.pcm.0.%driver: pcm > dev.pcm.0.%desc: VCHIQ audio > dev.pcm.%parent: >=20 >=20 > To play some audio I need to search some headphones first. :-) >=20 > Ronald. > =20 >=20 >=20 >=20 Good morning, Found headphones with a cable on the attic. Plugged it into the audio jack = and played an mp3. Amazing! Regards, Ronald. =20 ------=_Part_49_814679107.1644310150512 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: maandag, 7 februari 2022 21:05
Aan: Marco Devesas Campos <devesas.campos@gmail.com>= , freebsd-arm@freebsd.org
Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audi= o support for arm64

On 2/6/22 14:46, Marco Devesas Ca= mpos wrote:
> Hi Ronald,
>
> Thanks so much for trying out the patch out.
>
>> On 6 Feb 2022, at 13:05, Ronald Klop <ronald-lists@klop.ws> = wrote:
>>
>> Hi,
>>
>> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no dif= ference in available devices.
>> I can try to boot it on a RPI3B+ on another time.
>
> I *think* the GPU/VC in RPI-4 is a very different beast from the other= s. I'll
> look into it, but if you could give it a try on the 3+ I'd be much obl= iged.
>
>>
>> What would be the expected outcome? Where should I look at (or lis= ten to)?
>>
>
> You should see something like
>
>    vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b= 87b irq 54 on simplebus0
>    vchiq: local ver 8 (min 3), remote ver 8.
>    pcm0: <VCHIQ audio> on vchiq0
>
> in your dmesg output.
>
> The file /dev/vchiq should exist, as well as the following sysctl-s (I= 'm
> assuming no other audio devices are attached)
>
>    % sysctl dev.pcm
>    dev.pcm.0.trace: 0
>    ...
>    dev.pcm.0.dest: 0
>    ...
>    dev.pcm.0.%parent: vchiq0
>    ...
>    dev.pcm.0.%driver: pcm
>    dev.pcm.0.%desc: VCHIQ audio
>    =E2=80=A6
>
> Then if you `cat < /dev/random > /dev/dsp` you should hear some = static coming
> out of whatever is connected to hdmi (maybe headphones too? otherwise = try
> setting `sysctl dev.pcm.0.dest=3D1`)
>
> Best,
> Marco


Hi,

Booted the patched 14-CURRENT on the RPI3B+.

dmesg diff:
+vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b87b irq 54 on simplebu= s0
+vchiq: local ver 8 (min 3), remote ver 8.
+pcm0: <VCHIQ audio> on vchiq0

[root@rpi3 ~]# cat /dev/sndstat
Installed devices:
pcm0: <VCHIQ audio> (play) default
No devices installed from userspace.

[root@rpi3 ~]# sysctl dev.pcm
dev.pcm.0.trace: 0
dev.pcm.0.starved: 0
dev.pcm.0.freebuffer: 40000
dev.pcm.0.underruns: 0
dev.pcm.0.retrieved: 0
dev.pcm.0.submitted: 0
dev.pcm.0.callbacks: 0
dev.pcm.0.dest: 0
dev.pcm.0.mode: 3
dev.pcm.0.bitperfect: 0
dev.pcm.0.buffersize: 0
dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.play.vchanrate: 48000
dev.pcm.0.play.vchanmode: fixed
dev.pcm.0.play.vchans: 1
dev.pcm.0.%parent: vchiq0
dev.pcm.0.%pnpinfo:
dev.pcm.0.%location:
dev.pcm.0.%driver: pcm
dev.pcm.0.%desc: VCHIQ audio
dev.pcm.%parent:


To play some audio I need to search some headphones first. :-)

Ronald.
 


Good morning,

Found headphones with a cable on the attic. Plugged it into the audio jack = and played an mp3. Amazing!

Regards,
Ronald.
  ------=_Part_49_814679107.1644310150512-- From nobody Tue Feb 8 11:33:50 2022 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 D85C219A60D0 for ; Tue, 8 Feb 2022 11:34:01 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtLWD731Rz3j6f for ; Tue, 8 Feb 2022 11:34:00 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644320034; bh=yySC1lsf2Z6Zf4a8P5umXGg5Vu5HlAygdsfeT1On414=; h=Date:From:To:Subject:Cc:References:From:Subject:Reply-To; b=D9LsIjuNOFMNsQRM30MOUgC9sQUnqO/pPW2E92IU88SENn/vtWcEDnQpfB88t+GhOFe0+Mw7Vp94kyHREWBeRJay+JIDUDpafwyuE4hhKg6tKIaJ1+f3lNrY51kKvN4t3N9/p6rwyHmQUHvMohe/26LIMtmXWLVyE34TkTlOSudrEIwkOjjw3Bb6SFP6C80/AeejLj34ghhSaylzeoO1PEMP+SrpV81tuPXwgYlH5q+SNPw65RfWRH/7e8Ge3EP2/Eym1/hBOxAvlwILWqUeXOyCOqzkmuK2ss8pyLRov5FDzHSv6hmX4BRRQc8OgJ14T6f7vEFU3QDbcWoVEqh6dA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644320034; bh=mskJUb/IxqXWJqpgP2dPHb1xyGNFZj4dzzOZhrvC2ku=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=SLIRJcwzeUoNr1hlWDG4OqPoRT6ibgkzn46W45Wwyvante6mDuFFL/jwcJGQS3BQTMBfn/gan8pFSzgzJpC0RjAzg0trbX35q/rgAmPApqHrm8G9ZntDBvdr3D7yTDUBdKQNKptSd/tzzNq8k+xjYJ7wVVpDV0Ye/BByKLAoaScS3SGkKCeD/s66KzezFgooBxUXoCkh2ZN498mGqb0axOBbAbh9WBiz+XyWYyFQGjA9D4oQYCbNtgR6rBQqJJcQfd+zXTXLOBWhfvNfGBCO0938072Iwgsni4vqH5dcMbDelNLQc5Nf3Qa8Mx4DxJS5TaS0bkKbXFDqCNlkmpPPsw== X-YMail-OSG: M2DDV7oVM1ldiFLEzytKv48K9iFIBDzdHE7w6OjMrWKd0V5EjmF_0W5XjMetN9k gXjwCk5.WKruFCOWGPQ2ByI6ITaZZziWtpqjLlQmYxuLbRPeGKiVQurAoVtxMjNfvYOBw.OTolK8 c7fATYtvJtfUdsBtVPuuox6X4PLmr2T_UgXSVBLLyeT3kNx.R74vlJxtG0Huod3TP1VtFA2_S96g F69utuyX9X7aH9ppQm7OIET3WpJ4ND9UGVt7QNAnHTDKjqCFujHJWOiMLa3sbs47uI3Z3r4cFjuU gDwgH7EjNuufOufTlgl2g2l2HJrrIDU2pRoRXmLGXf9QV3KYOYkH8DtJUUYGWRF8tnNxKsR7IjTE lyi.BkP9uJsGiijWbbQyty3vs9s5pDuLFvQ_5alN0mPgcvqcDjyLsORHMgNAqE7B6ky6isCWcKHG 5Dby_tfPwvmdLzdstlo61idv93AiTTm0LGSLJ9gvnGn4ArGRQ1xssub.xI.JYdklcO.Wg5ACQH1J vqbsEVZYONmddc7pB0YqwKFFfhpBMPyLBvCbyc6BK2N14vTSzvcyWPpC1KjZMLJO80K5a.Qahpd. MuDzdCzogL1l.UXBlOLz4uUz7GzAG7MLXjmyDuUZFpgVmVchKste6p027_A1eUiADOMkM9d.dlLv DpjlVlFOd7wXyw0gByUGIqsnRfTcp_etlPuseA2fmLw70e.FGVSP6Yq3FfEONnkANuN9SnTZ12lX zzFfad5mhIO_KFlqVZ6nZhCIZZbs98WB7uP.f7ThQjnJ0oauNIeQPQp2rNAxWygwRGtyGm70Ss6f JC35G0Q90Ny_8CsoTY9m2uXkS665cMvqgmgwOaF1oDyHMuJECfgjU_7ErhCQX6GkKX8Sg90RvmKX dFuOFn.I.1RMazExtn9uiXlFQ6gjDgar_QNZMeffwqgUvxsbPztFUnazURgznvDS_YGftd04zEAg R.u7vcR6hFmnj2ji7Zw6jiMXoYlvBVfRPOIaiBHEepd8x2NQCk12tEK1T5Uob.NnFKDXT2RiNkKz JxVE1USESlOOt1mLaLpAPKNJSvgqmbt5ld3STwkU3GEOJ8XU14IYiJM2uNggXcTfTQsv.qC2k96G j.jEcOWQzE_7W1dVR5DWnQ1YouSBUU_2DGlZD_5WtXztC9Gnaz_2AuuLod.C74ie2gGvKawW8IGL MMuSXK7kxbBwqSqTMf77K.JMF15Ujeq.2I0O31lhrtmcxdMQ7WOuBUqv5ddihbaSFzTGpVvF83OJ yLddOZ_TdCXEMs68igUaWKb.J0Jc1wJCzfxY5KSUlBIIyfCCwfvFPpSXfA0qYp1KnKMwkf7SAydW aGcNfOF2q_.5kthYDNpwN5qO00DjnDiJzjFwyPrvoJ9lzPL10DPv5JE2hHBbIMw33GJqnDwoQPI5 2ylqI1xhCnV6wmczshp.du2IND1KZgw7hNbiCuHYDdeVvsTlXDzPCsDLlCCQ.7fbnkeRic.4Ci0L sPd9Ez3J3ZNqLE9lVz.ITOa5NUV3Cn3xHt4gaZe1PLGaaxsG82IHSi4xg.QYWkbj_dGz2ajdMhU8 FXlpi5sl5oG3R3j_LTg6s0Xeo_ncNp6BO5XQRsqeRlFpkIXHi.W6s0OnDyKKzS9zPsdFpqK7zUQL KkU2Zkc8wSW3mTpIZjKz7xCkhW.aHF5U4r5AJCz93K_UMHzJ64uGg_jFVU_oq8JE_KViNFz4LbBI huMYwwN7AdLEXnFX7YYvnnqunSHFhSOAKNHCDPnJfEB9Cg9fOVwYwBLz5BIR2FJpRSL_vKRNGe7v jteMCcnngjAmXumeAE_q9PD_q2E5raOKSRt.o.vetmcqpYm3fNjZNsMOxfb9DQdjhH3AFuXdEaC2 yPlzO2UfOTCDNqCPRDEV.taw4PoAb_aiY.cxpt14eiEQ_uOzF_yCED3c.E2Fie0fOcDxiqNKHn2p UwxcHszu3bXxC.xELChKnhjdVcOKsW.lOutm8.wmmDgPO72o_f4.C9Z1_5i6PVXY6DVOqBrCQwbY P48eCVj_JHATamu5o7.bRRfXbbafnQC8ICQ3641Bj1cU7qKT8IzpnDcxuz7UtexOjh2w6vXFOHof DdMg.uZwtaI3b2y2wOx7gT2b3GJU5LVeumbMErJ1_NUegofLjVnK78vtB3N7ZcVVXcByKn2W0yLb aSne_9KcESL4tWPV4XawCe_PogdLBFa.16Awq0YRRIn0ZFOXwIl8LYeoJUApL6BYSTzKuEVjXpJx F5h3qgZepFNI_27SAtGFCdVRS6JvB.uO7RPEyD1xcoLkC7R3sHTJpOegtq8ozJYo3hhz2ETc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 8 Feb 2022 11:33:54 +0000 Received: by kubenode539.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 138e249b9a94d24b12e40c6f28cb1c28; Tue, 08 Feb 2022 11:33:52 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------8CJO0Pe5ymtCU0v0PyR8HtR5" Message-ID: <17693697-ba5d-7b09-4bcb-c7e5e43a6f01@yahoo.com> Date: Tue, 8 Feb 2022 03:33:50 -0800 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US From: Fred Finster Organization: Kliktel To: freebsd-arm@freebsd.org Subject: SSD 500GB, has several slices, FreeBSD-ARM64 Snapshot 14, installed to a slice. Cc: fbsd@www.zefox.net, Fred.Suyimazu@theGalacticZoo.com References: <17693697-ba5d-7b09-4bcb-c7e5e43a6f01.ref@yahoo.com> X-Mailer: WebService/1.1.19711 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Rspamd-Queue-Id: 4JtLWD731Rz3j6f X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=D9LsIjuN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of wb7odyfred@yahoo.com designates 74.6.128.32 as permitted sender) smtp.mailfrom=wb7odyfred@yahoo.com X-Spamd-Result: default: False [-3.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[5]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.128.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.128.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9406 Lines: 182 This is a multi-part message in MIME format. --------------8CJO0Pe5ymtCU0v0PyR8HtR5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I will post details and pictures to https://ghostbsd-arm64.blogpost.com to better explain my confusion I want to thank  Bob Prohaska for his little notes on setting up Raspberry Pi 4B at http://www.zefox.net/~fbsd/u-boot_cheatsheet for booting from a USB SSD disk. http://www.zefox.net/~fbsd/ Check his other notes on booting Raspberry Pi 3+ and 4B SBCs. I am searching and looking for using EFIBOOTMGR to setup the SSD to boot from a slice.  There is an error about NO BootOrder setup and missing ubootefi.var value. So I can boot from a USB 2.0 Flash drive with the FreeBSD 14.0 RPI3 snapshot installed.  I did  install same image to a slice on the 500GB SATA SSD , but did not make any other changes or settings.  Still looking for the Instructions, Dance Steps, what ever it takes to make the SSD boot for a self contained system. I document here the steps, so others can follow. Install FreeBSD 14.0 Snapshot RPI3 to USB Flash Drive: download from freebsd.org/where https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220127-2c449a4c5a3-252673.img.xz 2022 01 27 date snapshot Note:  unxz FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220127-2c449a4c5a3-252673.img.xz dd if=./FreeBSD-ARM64-RPI3.img of=/dev/da1  bs=1m conv=notrunc status=progress Install FreeBSD 14.0 Snapshot RPI3 to USB 3.0 500GB SSD in an external HornetTek metal case Drive enclosure: dd if=./FreeBSD-ARM64-RPI3.img of=/dev/da1p4  bs=1m conv=notrunc status=progress Look at the location difference between  a single USB Flash drive stick  /dev/da1   and the SDD /dev/da1p4  into a slice (linux primary partition ) versus if  I used /dev/da1 for the whole disk.  So does the U-Boot have logic to do both to boot from a SSD (1.) boot whole drive and then 2.0 boot a single Slice that has 2 partitions 1.) MSDOS FAT32 2.) BSD with a label. ) So I am missing  efibootmrg on  aarch64 FreeBSD 14.0 snapshot to set the "boot order".  Missing ubootefi.var  variables? So  look at more details here at https://ghostbsd-arm64.blogspot.com {not like a web page with text files, yet I can display pictures I took with a camera here }.AR  I have not made the post "Booting 500 GB SSD on FreeBSD-ARM64-14.0 January 27, 2022  snapshot". yet. Simply,  I am asking:  1.)  Can U-BOOT and UEFI handle booting from an image installed to a  slice or does it have to be an image installed to a full disk?  How do you point the UEFI loader to select this one slice? Which tools accomplish that?  Are those tools already loaded inside the snapshot image downloaded from FreeBSD.org/where ??  I don't have ethernet access here and the internal wifi device does not have a working device driver for the Broadcom wifi.  2.)  Is there a method, to boot Rod Smiths rEFInd aaarch64 boot manager to allow FreeBSD 14 ARM64, POP!_OS ARM64, Manjaro Linux ARM64, Raspup 8.2.1 (ARM32) from the same disk?   Is there a UEFI work around using EFIBOOTMGR, EFI commands: printenv , setenv, run bootcmd  ?? URLS to read are good resource, that I would read. pss. Hard when you are starting out, to now what commands to issue in which sequence for the desired effect, unless you follow a pattern worked out by someone else. If I run eifbootmgr on my FreeBSD developer machine with the SSD plugged in. It sees the other devices and proceeds to setup the boot order for the development machine, not the SSD disk that has be plugged in termporarily. The answer is something simple, that I have not read about using before. Or so obvious a child could do it. -- Fred Finster email:Fred.Suyimazu@theGalacticZoo.com 971-718-9144 ghostbsd-arm64.blogspot.com --------------8CJO0Pe5ymtCU0v0PyR8HtR5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I will post details and pictures to  https://ghostbsd-arm64.blogpost.com to better explain my confusion

I want to thank  Bob Prohaska for his little notes on setting up Raspberry Pi 4B at http://www.zefox.net/~fbsd/u-boot_cheatsheet for booting from a USB SSD disk.  http://www.zefox.net/~fbsd/  Check his other notes on booting Raspberry Pi 3+ and 4B SBCs.

I am searching and looking for using EFIBOOTMGR to setup the SSD to boot from a slice.  There is an error about NO BootOrder setup and missing ubootefi.var value.

So I can boot from a USB 2.0 Flash drive with the FreeBSD 14.0 RPI3 snapshot installed.  I did  install same image to a slice on the 500GB SATA SSD , but did not make any other changes or settings.  Still looking for the Instructions, Dance Steps, what ever it takes to make the SSD boot for a self contained system.

I document here the steps, so others can follow. 

Install FreeBSD 14.0 Snapshot RPI3 to USB Flash Drive:

download from  freebsd.org/where   https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220127-2c449a4c5a3-252673.img.xz  2022 01 27 date snapshot  

Note:  unxz  FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220127-2c449a4c5a3-252673.img.xz

dd if=./FreeBSD-ARM64-RPI3.img of=/dev/da1  bs=1m conv=notrunc  status=progress

Install FreeBSD 14.0 Snapshot RPI3 to USB 3.0 500GB SSD in an external HornetTek metal case Drive enclosure:

dd if=./FreeBSD-ARM64-RPI3.img of=/dev/da1p4  bs=1m conv=notrunc  status=progress

Look at the location difference between  a single USB Flash drive stick  /dev/da1   and the SDD /dev/da1p4  into a slice (linux primary partition ) versus if  I used /dev/da1 for the whole disk.  So does the U-Boot have logic to do both to boot from a SSD (1.) boot whole drive and then 2.0 boot a single Slice that has 2 partitions 1.) MSDOS FAT32 2.) BSD with a label. )

So I am missing  efibootmrg on  aarch64 FreeBSD 14.0 snapshot to set the "boot order".  Missing ubootefi.var  variables?

So  look at more details here at https://ghostbsd-arm64.blogspot.com {not like a web page with text files, yet I can display pictures I took with a camera here }.AR  I have not made the post "Booting 500 GB SSD on FreeBSD-ARM64-14.0 January 27, 2022  snapshot".  yet.

Simply,  I am asking:

 1.)  Can U-BOOT and UEFI handle booting from an image installed to a  slice or does it have to be an image installed to a full disk?  How do you point the UEFI loader to select this one slice?  Which tools accomplish that?  Are those tools already loaded inside the snapshot image downloaded from FreeBSD.org/where ??  I don't have ethernet access here and the internal wifi device does not have a working device driver for the Broadcom wifi.

 2.)  Is there a method, to boot Rod Smiths rEFInd aaarch64 boot manager to allow FreeBSD 14 ARM64, POP!_OS ARM64, Manjaro Linux ARM64, Raspup 8.2.1 (ARM32) from the same disk?   Is there a UEFI work around using EFIBOOTMGR, EFI commands: printenv , setenv, run bootcmd  ??

URLS to read are good resource, that I would read.

pss.  Hard when you are starting out, to now what commands to issue in which sequence for the desired effect, unless you follow a pattern worked out by someone else.  
If I run eifbootmgr on my FreeBSD developer machine with the SSD plugged in.  It sees the other devices and proceeds to setup the boot order for the development machine, 
not the SSD disk that has be plugged in termporarily.   The answer is something simple, that I have not read about using before.  Or so obvious a child could do it.

-- 
Fred Finster 
email:  Fred.Suyimazu@theGalacticZoo.com
971-718-9144
ghostbsd-arm64.blogspot.com
--------------8CJO0Pe5ymtCU0v0PyR8HtR5-- From nobody Thu Feb 10 07:48:25 2022 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 963CE19AFCCD; Thu, 10 Feb 2022 07:48:35 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (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 "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvTQB2TnQz3n60; Thu, 10 Feb 2022 07:48:34 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 21A7mPTM037482; Thu, 10 Feb 2022 16:48:25 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202202100748.21A7mPTM037482@kx.truefc.org> Date: Thu, 10 Feb 2022 16:48:25 +0900 From: KIRIYAMA Kazuhiko To: ports@freebsd.org Cc: freebsd-arm@freebsd.org, KIRIYAMA Kazuhiko Subject: Can't build audio/jack in arm64/aarch64 on PBP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) 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 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4JvTQB2TnQz3n60 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,ports]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 13398 Lines: 143 Hi, lists I've tried to build arm64/aarch64 packages on Pinebook Pro (PBP). audio/jack failed to build at build/common/memops.c : 2 errors generated. In file included from ../common/JackDebugClient.cpp:21: ../common/JackEngineControl.h:67:5: error: requested alignment is less than minimum alignment of 8 for type 'Jack::JackTransportEngine' alignas(UInt32) JackTransportEngine fTransport; ^ ../common/JackEngineControl.h:89:5: error: requested alignment is less than minimum alignment of 8 for type 'Jack::JackFrameTimer' alignas(UInt32) JackFrameTimer fFrameTimer; ^ 2 errors generated. * Node /var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/build/common/memops.c.7.o is created more than once (full message on 'waf -v -v'). The task generators are: 1. 'audioadapter' in /var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/common 2. 'oss' in /var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20 If you think that this is an error, set no_errcheck_out on the task instance Waf: Leaving directory `/var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/build' Build failed -> task in 'serverlib' failed with exit status 1: {task 2825605856: cxx JackTransportEngine.cpp -> JackTransportEngine.cpp.2.o} ['c++', '-O2', '-pipe', '-fPIC', '-fstack-protector-strong', '-fno-strict-aliasing', '-Wall', '-Wno-invalid-offsetof', '-std=gnu++11', '-fPIC', '-Ifreebsd', '-I../freebsd', '-Iposix', '-I../posix', '-Icommon', '-I../common', '-Icommon/jack', '-I../common/jack', '-I.', '-I..', '-I../compat/alloca', '-I/usr/local/include/opus', '-I/usr/local/include', '-I/usr/local/include/dbus-1.0', '-I/usr/local/lib/dbus-1.0/include', '-DEXECINFO=1', '-DHAVE_LIBSYSINFO=1', '-DHAVE_DOXYGEN=0', '-DHAVE_ALSA=0', '-DHAVE_FIREWIRE=0', '-DHAVE_IIO=0', '-DHAVE_PORTAUDIO=0', '-DHAVE_WINMME=0', '-DHAVE_CELT=0', '-DHAVE_EXAMPLE_TOOLS=0', '-DHAVE_OPUS_OPUS_CUSTOM_H=1', '-DHAVE_OPUS_PKG=1', '-DHAVE_OPUS=1', '-DHAVE_SAMPLERATE=1', '-DHAVE_SNDFILE=0', '-DHAVE_READLINE=0', '-DHAVE_SYSTEMD=0', '-DHAVE_DB_H=1', '-DHAVE_DB=0', '-DHAVE_ZALSA=0', '-DHAVE_PPOLL=1', '-DHAVE_EXECINFO_H=1', '-DJACK_VERSION="[]"', '-DHAVE_DBUS_1=1', '-DHAVE_EXPAT=1', '-DUSE_LIBDBUS_AUTOLAUNCH=1', '-DCLIENT_NUM=256', '-DPORT_NUM_FOR_! CLIENT=2048', '-DADDON_DIR="/usr/local/lib/jack"', '-DJACK_LOCATION="/usr/local/bin"', '-DUSE_POSIX_SHM=1', '-DJACKMP=1', '-DJACK_DBUS=1', '-DHAVE_CONFIG_H', '-DSERVER_SIDE', '../common/JackTransportEngine.cpp', '-c', '-o/var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/build/common/JackTransportEngine.cpp.2.o', '-I/usr/local/include'] -> task in 'serverlib' failed with exit status 1: {task 2825606192: cxx JackEngineProfiling.cpp -> JackEngineProfiling.cpp.2.o} ['c++', '-O2', '-pipe', '-fPIC', '-fstack-protector-strong', '-fno-strict-aliasing', '-Wall', '-Wno-invalid-offsetof', '-std=gnu++11', '-fPIC', '-Ifreebsd', '-I../freebsd', '-Iposix', '-I../posix', '-Icommon', '-I../common', '-Icommon/jack', '-I../common/jack', '-I.', '-I..', '-I../compat/alloca', '-I/usr/local/include/opus', '-I/usr/local/include', '-I/usr/local/include/dbus-1.0', '-I/usr/local/lib/dbus-1.0/include', '-DEXECINFO=1', '-DHAVE_LIBSYSINFO=1', '-DHAVE_DOXYGEN=0', '-DHAVE_ALSA=0', '-DHAVE_FIREWIRE=0', '-DHAVE_IIO=0', '-DHAVE_PORTAUDIO=0', '-DHAVE_WINMME=0', '-DHAVE_CELT=0', '-DHAVE_EXAMPLE_TOOLS=0', '-DHAVE_OPUS_OPUS_CUSTOM_H=1', '-DHAVE_OPUS_PKG=1', '-DHAVE_OPUS=1', '-DHAVE_SAMPLERATE=1', '-DHAVE_SNDFILE=0', '-DHAVE_READLINE=0', '-DHAVE_SYSTEMD=0', '-DHAVE_DB_H=1', '-DHAVE_DB=0', '-DHAVE_ZALSA=0', '-DHAVE_PPOLL=1', '-DHAVE_EXECINFO_H=1', '-DJACK_VERSION="[]"', '-DHAVE_DBUS_1=1', '-DHAVE_EXPAT=1', '-DUSE_LIBDBUS_AUTOLAUNCH=1', '-DCLIENT_NUM=256', '-DPORT_NUM_FOR_! CLIENT=2048', '-DADDON_DIR="/usr/local/lib/jack"', '-DJACK_LOCATION="/usr/local/bin"', '-DUSE_POSIX_SHM=1', '-DJACKMP=1', '-DJACK_DBUS=1', '-DHAVE_CONFIG_H', '-DSERVER_SIDE', '../common/JackEngineProfiling.cpp', '-c', '-o/var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/build/common/JackEngineProfiling.cpp.2.o', '-I/usr/local/include'] -> task in 'serverlib' failed with exit status 1: {task 2825606304: cxx JackDebugClient.cpp -> JackDebugClient.cpp.2.o} ['c++', '-O2', '-pipe', '-fPIC', '-fstack-protector-strong', '-fno-strict-aliasing', '-Wall', '-Wno-invalid-offsetof', '-std=gnu++11', '-fPIC', '-Ifreebsd', '-I../freebsd', '-Iposix', '-I../posix', '-Icommon', '-I../common', '-Icommon/jack', '-I../common/jack', '-I.', '-I..', '-I../compat/alloca', '-I/usr/local/include/opus', '-I/usr/local/include', '-I/usr/local/include/dbus-1.0', '-I/usr/local/lib/dbus-1.0/include', '-DEXECINFO=1', '-DHAVE_LIBSYSINFO=1', '-DHAVE_DOXYGEN=0', '-DHAVE_ALSA=0', '-DHAVE_FIREWIRE=0', '-DHAVE_IIO=0', '-DHAVE_PORTAUDIO=0', '-DHAVE_WINMME=0', '-DHAVE_CELT=0', '-DHAVE_EXAMPLE_TOOLS=0', '-DHAVE_OPUS_OPUS_CUSTOM_H=1', '-DHAVE_OPUS_PKG=1', '-DHAVE_OPUS=1', '-DHAVE_SAMPLERATE=1', '-DHAVE_SNDFILE=0', '-DHAVE_READLINE=0', '-DHAVE_SYSTEMD=0', '-DHAVE_DB_H=1', '-DHAVE_DB=0', '-DHAVE_ZALSA=0', '-DHAVE_PPOLL=1', '-DHAVE_EXECINFO_H=1', '-DJACK_VERSION="[]"', '-DHAVE_DBUS_1=1', '-DHAVE_EXPAT=1', '-DUSE_LIBDBUS_AUTOLAUNCH=1', '-DCLIENT_NUM=256', '-DPORT_NUM_FOR_! CLIENT=2048', '-DADDON_DIR="/usr/local/lib/jack"', '-DJACK_LOCATION="/usr/local/bin"', '-DUSE_POSIX_SHM=1', '-DJACKMP=1', '-DJACK_DBUS=1', '-DHAVE_CONFIG_H', '-DSERVER_SIDE', '../common/JackDebugClient.cpp', '-c', '-o/var/ports/work/usr/ports/audio/jack/work/jack2-1.9.20/build/common/JackDebugClient.cpp.2.o', '-I/usr/local/include'] ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/audio/jack Is there any suggetions ? My package build machine environments are as follows : Ports branch is 47d8fb3af3f0 and others are : admin@kazu:~ % uname -a FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64 admin@kazu:~ % df -h Filesystem Size Used Avail Capacity Mounted on /dev/mmcsd0p3 82G 15G 61G 19% / devfs 1.0K 1.0K 0B 100% /dev tmpfs 34G 4.0K 34G 0% /tmp linprocfs 4.0K 4.0K 0B 100% /compat/linux/proc tmpfs 34G 4.0K 34G 0% /compat/linux/dev/shm linsysfs 4.0K 4.0K 0B 100% /compat/linux/sys devfs 1.0K 1.0K 0B 100% /compat/linux/dev fdescfs 1.0K 1.0K 0B 100% /compat/linux/dev/fd 192.168.1.17:/.dake 12T 973G 11T 8% /.dake 192.168.1.17:/ds/src/freebsd/current/14.0/3f106af0cd92.generic_drm 11T 81G 11T 1% /usr/src 192.168.1.17:/ds/obj/freebsd/current/14.0/3f106af0cd92.generic_drm 11T 442G 11T 4% /usr/obj 192.168.1.17:/ds/ports/freebsd/47d8fb3af3f0 11T 111G 11T 1% /usr/ports 192.168.1.17:/ds/distfiles 11T 54G 11T 0% /var/ports/distfiles 192.168.1.17:/ds/packages/freebsd/arm64/aarch64/14.0C/3f106af0cd92/47d8fb3af3f0 11T 117G 11T 1% /var/ports/packages admin@kazu:~ % uname -a FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022 root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64 admin@kazu:~ % df -h Filesystem Size Used Avail Capacity Mounted on /dev/mmcsd0p3 82G 15G 61G 19% / devfs 1.0K 1.0K 0B 100% /dev tmpfs 34G 4.0K 34G 0% /tmp linprocfs 4.0K 4.0K 0B 100% /compat/linux/proc tmpfs 34G 4.0K 34G 0% /compat/linux/dev/shm linsysfs 4.0K 4.0K 0B 100% /compat/linux/sys devfs 1.0K 1.0K 0B 100% /compat/linux/dev fdescfs 1.0K 1.0K 0B 100% /compat/linux/dev/fd 192.168.1.17:/.dake 12T 973G 11T 8% /.dake 192.168.1.17:/ds/src/freebsd/current/14.0/3f106af0cd92.generic_drm 11T 81G 11T 1% /usr/src 192.168.1.17:/ds/obj/freebsd/current/14.0/3f106af0cd92.generic_drm 11T 442G 11T 4% /usr/obj 192.168.1.17:/ds/ports/freebsd/47d8fb3af3f0 11T 111G 11T 1% /usr/ports 192.168.1.17:/ds/distfiles 11T 54G 11T 0% /var/ports/distfiles 192.168.1.17:/ds/packages/freebsd/arm64/aarch64/14.0C/3f106af0cd92/47d8fb3af3f0 11T 117G 11T 1% /var/ports/packages admin@kazu:~ % cat /etc/make.conf PORTSDIR= /var/ports/lpbpkx INDEXDIR= /var/ports/lpbpkx WRKDIRPREFIX= /var/ports/work PACKAGES= /var/ports/packages DISTDIR= /var/ports/distfiles BATCH= yes DEFAULT_VERSIONS= perl5=5.34 ruby=2.7 java=12 COMPILER_TYPE= clang USE_PACKAGE_DEPENDS= yes DISABLE_VULNERABILITIES=yes admin@kazu:~ % GENERIC-DRM kernel was built by `git subtree add' to 14.0-CURRENT (e35816c1c909) for Panfrost driver [1] : First `git subtree add' to 14.0-CURRENT (e35816c1c909) in src server : root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git checkout e35816c1c909 HEAD is now at e35816c1c909 aw_spi: improve I/O stability root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git remote add drm-subtree https://github.com/jsm222/drm-subtree.git root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git subtree add --prefix sys/dev/drm/ drm-subtree pinebookpro-test git fetch drm-subtree pinebookpro-test remote: Enumerating objects: 794, done. remote: Counting objects: 100% (794/794), done. remote: Compressing objects: 100% (518/518), done. remote: Total 794 (delta 370), reused 685 (delta 264), pack-reused 0 Receiving objects: 100% (794/794), 1.14 MiB | 5.09 MiB/s, done. Resolving deltas: 100% (370/370), done. From https://github.com/jsm222/drm-subtree * branch pinebookpro-test -> FETCH_HEAD * [new branch] pinebookpro-test -> drm-subtree/pinebookpro-test Added dir 'sys/dev/drm' root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git rev-parse --verify --short HEAD 3f106af0cd92 root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # cd .. root@vm:/ds/src/freebsd/current/14.0 # mv e35816c1c909.generic_drm 3f106af0cd92.generic_drm and then build GENERIC-DRM in PBP : # cd /usr/src # make buildworld TARGET=arm64 # make buildkernel TARGET=arm64 KERNCONF=GENERIC-DRM Best regards [1] https://github.com/jsm222/drm-subtree --- Kazuhiko Kiriyama From nobody Thu Feb 10 08:05:18 2022 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 C61F819BD20C for ; Thu, 10 Feb 2022 08:05:23 +0000 (UTC) (envelope-from jsm@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 4JvTnb52L1z4QyY; Thu, 10 Feb 2022 08:05:23 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644480323; 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=a4dpF+gVfZfilaQVWDw9SOqBUvNZuF0FgD/SJvHoAK0=; b=DsBJAvREtktOtD2qwGtD52C0sQ+uY1nsGUpucBw2/wzV9JPbuGK3E4C/sWMhrEXDkg0GRI kyqrYAyDSxyPcRinmAOQKw+xl0ME6Te8xpPBAWjLLpPJMLPMYOjZvpf06QDoE+BKWr+H8F oHF/uScgb+6Pjwg7Z4065m6mKjN0a07cNpXs0J7ddtMwgIeLXDGOsoMsHsCxvW33H0OZWW dmmlaDfVmo+9vtOUUs5Fm6VvBLXNs1FNHvc/Oj8vksqW80rNyL8siAxeBhH4z+JjRG8Y9Q 8XwBD0gISPZ+MRr7K/1BmKZ71weSstJJALHv+t2g3GL0ouXO+kF27IuuCuzDOg== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 1C4CA2D7C9; Thu, 10 Feb 2022 08:05:22 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: Date: Thu, 10 Feb 2022 09:05:18 +0100 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:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Can't build audio/jack in arm64/aarch64 on PBP Content-Language: en-US To: KIRIYAMA Kazuhiko Cc: freebsd-arm@freebsd.org References: <202202100748.21A7mPTM037482@kx.truefc.org> From: Jesper Schmitz Mouridsen In-Reply-To: <202202100748.21A7mPTM037482@kx.truefc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644480323; 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=a4dpF+gVfZfilaQVWDw9SOqBUvNZuF0FgD/SJvHoAK0=; b=P0yI0k/uwzNSkqio6FDnoDVyjywNCPe9guX4xx4HVrV2m6qa7pPLqikuBBbxNmT9U/+uz4 XaLo4GGRxGK52QUk79/V0PtzNau9UssYjjtIfpcST7+Euuldv3PYfxxSfwn6NC7+0GSWVf pE3d5+q8D+u2ihhkCTq9HjOt6YtF5+7ZAwMGHSB+6JXd2Rlv1jzKh0MbgHhXpWTl8qJm16 ahIUSc7/6hwN+NFG/4GXbtiikKAFGfJSmKOPLjaE2rq0JlL3XjMEFMzt8MO48sYN7GZJ/N +nn3o29hI6/wL+p4d7w6pvho6uzIhU5XpNetcMvNpH6W/xGMi/GT2G7fBYzREA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644480323; a=rsa-sha256; cv=none; b=tin6g9Ru40APoyvY+RntWs65qPqm9orllyLAvtkP94hZ/mxAk3ohbPIXM+SPeIPWD4dMZk eRRFO3Vw5ytAADCo1aILB0UYYkkDIOtypNL7hOTqLlMfnrBdBs5nWiYHBobKQgNqsE4LYZ 9WNprhp1P57KB1jF7pOFkokYFgu6J+4K4VcDCdLASHjDKN5zF8UZTwd4epGwt7ApGjUMHx t6xnv0+kdKFDj195P+ekQk7gMTHiOpgR4/KoHUtAhhHH3HQh1+MjMt9jXj4HTKyqGpsgTB wJLhl5EWbPLwpNV8/RVfrvHzhXl6lPbK5jc2UXMK29F16KmcqdN5lT4DBIK34Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 18883 Lines: 259 DQpPbiAxMC4wMi4yMDIyIDA4LjQ4LCBLSVJJWUFNQSBLYXp1aGlrbyB3cm90ZToNCj4gSGks IGxpc3RzDQo+IA0KPiBJJ3ZlIHRyaWVkIHRvIGJ1aWxkIGFybTY0L2FhcmNoNjQgcGFja2Fn ZXMgb24gUGluZWJvb2sgUHJvDQo+IChQQlApLiBhdWRpby9qYWNrIGZhaWxlZCB0byBidWls ZCBhdCBidWlsZC9jb21tb24vbWVtb3BzLmMgOg0KPiANCj4gMiBlcnJvcnMgZ2VuZXJhdGVk Lg0KPiANCj4gSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC4uL2NvbW1vbi9KYWNrRGVidWdDbGll bnQuY3BwOjIxOg0KPiAuLi9jb21tb24vSmFja0VuZ2luZUNvbnRyb2wuaDo2Nzo1OiBlcnJv cjogcmVxdWVzdGVkIGFsaWdubWVudCBpcyBsZXNzIHRoYW4gbWluaW11bSBhbGlnbm1lbnQg b2YgOCBmb3IgdHlwZSAnSmFjazo6SmFja1RyYW5zcG9ydEVuZ2luZScNCj4gICAgICBhbGln bmFzKFVJbnQzMikgSmFja1RyYW5zcG9ydEVuZ2luZSBmVHJhbnNwb3J0Ow0KPiAgICAgIF4N Cj4gLi4vY29tbW9uL0phY2tFbmdpbmVDb250cm9sLmg6ODk6NTogZXJyb3I6IHJlcXVlc3Rl ZCBhbGlnbm1lbnQgaXMgbGVzcyB0aGFuIG1pbmltdW0gYWxpZ25tZW50IG9mIDggZm9yIHR5 cGUgJ0phY2s6OkphY2tGcmFtZVRpbWVyJw0KPiAgICAgIGFsaWduYXMoVUludDMyKSBKYWNr RnJhbWVUaW1lciBmRnJhbWVUaW1lcjsNCj4gICAgICBeDQo+IDIgZXJyb3JzIGdlbmVyYXRl ZC4NCj4gDQo+ICogTm9kZSAvdmFyL3BvcnRzL3dvcmsvdXNyL3BvcnRzL2F1ZGlvL2phY2sv d29yay9qYWNrMi0xLjkuMjAvYnVpbGQvY29tbW9uL21lbW9wcy5jLjcubyBpcyBjcmVhdGVk IG1vcmUgdGhhbiBvbmNlIChmdWxsIG1lc3NhZ2Ugb24gJ3dhZiAtdiAtdicpLiBUaGUgdGFz ayBnZW5lcmF0b3JzIGFyZToNCj4gICAgMS4gJ2F1ZGlvYWRhcHRlcicgaW4gL3Zhci9wb3J0 cy93b3JrL3Vzci9wb3J0cy9hdWRpby9qYWNrL3dvcmsvamFjazItMS45LjIwL2NvbW1vbg0K PiAgICAyLiAnb3NzJyBpbiAvdmFyL3BvcnRzL3dvcmsvdXNyL3BvcnRzL2F1ZGlvL2phY2sv d29yay9qYWNrMi0xLjkuMjANCj4gSWYgeW91IHRoaW5rIHRoYXQgdGhpcyBpcyBhbiBlcnJv ciwgc2V0IG5vX2VycmNoZWNrX291dCBvbiB0aGUgdGFzayBpbnN0YW5jZQ0KPiBXYWY6IExl YXZpbmcgZGlyZWN0b3J5IGAvdmFyL3BvcnRzL3dvcmsvdXNyL3BvcnRzL2F1ZGlvL2phY2sv d29yay9qYWNrMi0xLjkuMjAvYnVpbGQnDQo+IEJ1aWxkIGZhaWxlZA0KPiAgIC0+IHRhc2sg aW4gJ3NlcnZlcmxpYicgZmFpbGVkIHdpdGggZXhpdCBzdGF0dXMgMToNCj4gCXt0YXNrIDI4 MjU2MDU4NTY6IGN4eCBKYWNrVHJhbnNwb3J0RW5naW5lLmNwcCAtPiBKYWNrVHJhbnNwb3J0 RW5naW5lLmNwcC4yLm99DQo+IFsnYysrJywgJy1PMicsICctcGlwZScsICctZlBJQycsICct ZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcnLCAnLWZuby1zdHJpY3QtYWxpYXNpbmcnLCAnLVdh bGwnLCAnLVduby1pbnZhbGlkLW9mZnNldG9mJywgJy1zdGQ9Z251KysxMScsICctZlBJQycs ICctSWZyZWVic2QnLCAnLUkuLi9mcmVlYnNkJywgJy1JcG9zaXgnLCAnLUkuLi9wb3NpeCcs ICctSWNvbW1vbicsICctSS4uL2NvbW1vbicsICctSWNvbW1vbi9qYWNrJywgJy1JLi4vY29t bW9uL2phY2snLCAnLUkuJywgJy1JLi4nLCAnLUkuLi9jb21wYXQvYWxsb2NhJywgJy1JL3Vz ci9sb2NhbC9pbmNsdWRlL29wdXMnLCAnLUkvdXNyL2xvY2FsL2luY2x1ZGUnLCAnLUkvdXNy L2xvY2FsL2luY2x1ZGUvZGJ1cy0xLjAnLCAnLUkvdXNyL2xvY2FsL2xpYi9kYnVzLTEuMC9p bmNsdWRlJywgJy1ERVhFQ0lORk89MScsICctREhBVkVfTElCU1lTSU5GTz0xJywgJy1ESEFW RV9ET1hZR0VOPTAnLCAnLURIQVZFX0FMU0E9MCcsICctREhBVkVfRklSRVdJUkU9MCcsICct REhBVkVfSUlPPTAnLCAnLURIQVZFX1BPUlRBVURJTz0wJywgJy1ESEFWRV9XSU5NTUU9MCcs ICctREhBVkVfQ0VMVD0wJywgJy1ESEFWRV9FWEFNUExFX1RPT0xTPTAnLCAnLURIQVZFX09Q VVNfT1BVU19DVVNUT01fSD0xJywgJy1ESEFWRV9PUFVTX1BLRz0xJywgJy1ESEFWRV9PUFVT PTEnLCAnLURIQVZFX1NBTVBMRVJBVEU9MScsICctREhBVkVfU05ERklMRT0wJywgJy1ESEFW RV9SRUFETElORT0wJywgJy1ESEFWRV9TWVNURU1EPTAnLCAnLURIQVZFX0RCX0g9MScsICct REhBVkVfREI9MCcsICctREhBVkVfWkFMU0E9MCcsICctREhBVkVfUFBPTEw9MScsICctREhB VkVfRVhFQ0lORk9fSD0xJywgJy1ESkFDS19WRVJTSU9OPSJbXSInLCAnLURIQVZFX0RCVVNf MT0xJywgJy1ESEFWRV9FWFBBVD0xJywgJy1EVVNFX0xJQkRCVVNfQVVUT0xBVU5DSD0xJywg Jy1EQ0xJRU5UX05VTT0yNTYnLCAnLURQT1JUX05VTV9GT1JfIQ0KPiAgIENMSUVOVD0yMDQ4 JywgJy1EQURET05fRElSPSIvdXNyL2xvY2FsL2xpYi9qYWNrIicsICctREpBQ0tfTE9DQVRJ T049Ii91c3IvbG9jYWwvYmluIicsICctRFVTRV9QT1NJWF9TSE09MScsICctREpBQ0tNUD0x JywgJy1ESkFDS19EQlVTPTEnLCAnLURIQVZFX0NPTkZJR19IJywgJy1EU0VSVkVSX1NJREUn LCAnLi4vY29tbW9uL0phY2tUcmFuc3BvcnRFbmdpbmUuY3BwJywgJy1jJywgJy1vL3Zhci9w b3J0cy93b3JrL3Vzci9wb3J0cy9hdWRpby9qYWNrL3dvcmsvamFjazItMS45LjIwL2J1aWxk L2NvbW1vbi9KYWNrVHJhbnNwb3J0RW5naW5lLmNwcC4yLm8nLCAnLUkvdXNyL2xvY2FsL2lu Y2x1ZGUnXQ0KPiAgIC0+IHRhc2sgaW4gJ3NlcnZlcmxpYicgZmFpbGVkIHdpdGggZXhpdCBz dGF0dXMgMToNCj4gCXt0YXNrIDI4MjU2MDYxOTI6IGN4eCBKYWNrRW5naW5lUHJvZmlsaW5n LmNwcCAtPiBKYWNrRW5naW5lUHJvZmlsaW5nLmNwcC4yLm99DQo+IFsnYysrJywgJy1PMics ICctcGlwZScsICctZlBJQycsICctZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcnLCAnLWZuby1z dHJpY3QtYWxpYXNpbmcnLCAnLVdhbGwnLCAnLVduby1pbnZhbGlkLW9mZnNldG9mJywgJy1z dGQ9Z251KysxMScsICctZlBJQycsICctSWZyZWVic2QnLCAnLUkuLi9mcmVlYnNkJywgJy1J cG9zaXgnLCAnLUkuLi9wb3NpeCcsICctSWNvbW1vbicsICctSS4uL2NvbW1vbicsICctSWNv bW1vbi9qYWNrJywgJy1JLi4vY29tbW9uL2phY2snLCAnLUkuJywgJy1JLi4nLCAnLUkuLi9j b21wYXQvYWxsb2NhJywgJy1JL3Vzci9sb2NhbC9pbmNsdWRlL29wdXMnLCAnLUkvdXNyL2xv Y2FsL2luY2x1ZGUnLCAnLUkvdXNyL2xvY2FsL2luY2x1ZGUvZGJ1cy0xLjAnLCAnLUkvdXNy L2xvY2FsL2xpYi9kYnVzLTEuMC9pbmNsdWRlJywgJy1ERVhFQ0lORk89MScsICctREhBVkVf TElCU1lTSU5GTz0xJywgJy1ESEFWRV9ET1hZR0VOPTAnLCAnLURIQVZFX0FMU0E9MCcsICct REhBVkVfRklSRVdJUkU9MCcsICctREhBVkVfSUlPPTAnLCAnLURIQVZFX1BPUlRBVURJTz0w JywgJy1ESEFWRV9XSU5NTUU9MCcsICctREhBVkVfQ0VMVD0wJywgJy1ESEFWRV9FWEFNUExF X1RPT0xTPTAnLCAnLURIQVZFX09QVVNfT1BVU19DVVNUT01fSD0xJywgJy1ESEFWRV9PUFVT X1BLRz0xJywgJy1ESEFWRV9PUFVTPTEnLCAnLURIQVZFX1NBTVBMRVJBVEU9MScsICctREhB VkVfU05ERklMRT0wJywgJy1ESEFWRV9SRUFETElORT0wJywgJy1ESEFWRV9TWVNURU1EPTAn LCAnLURIQVZFX0RCX0g9MScsICctREhBVkVfREI9MCcsICctREhBVkVfWkFMU0E9MCcsICct REhBVkVfUFBPTEw9MScsICctREhBVkVfRVhFQ0lORk9fSD0xJywgJy1ESkFDS19WRVJTSU9O PSJbXSInLCAnLURIQVZFX0RCVVNfMT0xJywgJy1ESEFWRV9FWFBBVD0xJywgJy1EVVNFX0xJ QkRCVVNfQVVUT0xBVU5DSD0xJywgJy1EQ0xJRU5UX05VTT0yNTYnLCAnLURQT1JUX05VTV9G T1JfIQ0KPiAgIENMSUVOVD0yMDQ4JywgJy1EQURET05fRElSPSIvdXNyL2xvY2FsL2xpYi9q YWNrIicsICctREpBQ0tfTE9DQVRJT049Ii91c3IvbG9jYWwvYmluIicsICctRFVTRV9QT1NJ WF9TSE09MScsICctREpBQ0tNUD0xJywgJy1ESkFDS19EQlVTPTEnLCAnLURIQVZFX0NPTkZJ R19IJywgJy1EU0VSVkVSX1NJREUnLCAnLi4vY29tbW9uL0phY2tFbmdpbmVQcm9maWxpbmcu Y3BwJywgJy1jJywgJy1vL3Zhci9wb3J0cy93b3JrL3Vzci9wb3J0cy9hdWRpby9qYWNrL3dv cmsvamFjazItMS45LjIwL2J1aWxkL2NvbW1vbi9KYWNrRW5naW5lUHJvZmlsaW5nLmNwcC4y Lm8nLCAnLUkvdXNyL2xvY2FsL2luY2x1ZGUnXQ0KPiAgIC0+IHRhc2sgaW4gJ3NlcnZlcmxp YicgZmFpbGVkIHdpdGggZXhpdCBzdGF0dXMgMToNCj4gCXt0YXNrIDI4MjU2MDYzMDQ6IGN4 eCBKYWNrRGVidWdDbGllbnQuY3BwIC0+IEphY2tEZWJ1Z0NsaWVudC5jcHAuMi5vfQ0KPiBb J2MrKycsICctTzInLCAnLXBpcGUnLCAnLWZQSUMnLCAnLWZzdGFjay1wcm90ZWN0b3Itc3Ry b25nJywgJy1mbm8tc3RyaWN0LWFsaWFzaW5nJywgJy1XYWxsJywgJy1Xbm8taW52YWxpZC1v ZmZzZXRvZicsICctc3RkPWdudSsrMTEnLCAnLWZQSUMnLCAnLUlmcmVlYnNkJywgJy1JLi4v ZnJlZWJzZCcsICctSXBvc2l4JywgJy1JLi4vcG9zaXgnLCAnLUljb21tb24nLCAnLUkuLi9j b21tb24nLCAnLUljb21tb24vamFjaycsICctSS4uL2NvbW1vbi9qYWNrJywgJy1JLicsICct SS4uJywgJy1JLi4vY29tcGF0L2FsbG9jYScsICctSS91c3IvbG9jYWwvaW5jbHVkZS9vcHVz JywgJy1JL3Vzci9sb2NhbC9pbmNsdWRlJywgJy1JL3Vzci9sb2NhbC9pbmNsdWRlL2RidXMt MS4wJywgJy1JL3Vzci9sb2NhbC9saWIvZGJ1cy0xLjAvaW5jbHVkZScsICctREVYRUNJTkZP PTEnLCAnLURIQVZFX0xJQlNZU0lORk89MScsICctREhBVkVfRE9YWUdFTj0wJywgJy1ESEFW RV9BTFNBPTAnLCAnLURIQVZFX0ZJUkVXSVJFPTAnLCAnLURIQVZFX0lJTz0wJywgJy1ESEFW RV9QT1JUQVVESU89MCcsICctREhBVkVfV0lOTU1FPTAnLCAnLURIQVZFX0NFTFQ9MCcsICct REhBVkVfRVhBTVBMRV9UT09MUz0wJywgJy1ESEFWRV9PUFVTX09QVVNfQ1VTVE9NX0g9MScs ICctREhBVkVfT1BVU19QS0c9MScsICctREhBVkVfT1BVUz0xJywgJy1ESEFWRV9TQU1QTEVS QVRFPTEnLCAnLURIQVZFX1NOREZJTEU9MCcsICctREhBVkVfUkVBRExJTkU9MCcsICctREhB VkVfU1lTVEVNRD0wJywgJy1ESEFWRV9EQl9IPTEnLCAnLURIQVZFX0RCPTAnLCAnLURIQVZF X1pBTFNBPTAnLCAnLURIQVZFX1BQT0xMPTEnLCAnLURIQVZFX0VYRUNJTkZPX0g9MScsICct REpBQ0tfVkVSU0lPTj0iW10iJywgJy1ESEFWRV9EQlVTXzE9MScsICctREhBVkVfRVhQQVQ9 MScsICctRFVTRV9MSUJEQlVTX0FVVE9MQVVOQ0g9MScsICctRENMSUVOVF9OVU09MjU2Jywg Jy1EUE9SVF9OVU1fRk9SXyENCj4gICBDTElFTlQ9MjA0OCcsICctREFERE9OX0RJUj0iL3Vz ci9sb2NhbC9saWIvamFjayInLCAnLURKQUNLX0xPQ0FUSU9OPSIvdXNyL2xvY2FsL2JpbiIn LCAnLURVU0VfUE9TSVhfU0hNPTEnLCAnLURKQUNLTVA9MScsICctREpBQ0tfREJVUz0xJywg Jy1ESEFWRV9DT05GSUdfSCcsICctRFNFUlZFUl9TSURFJywgJy4uL2NvbW1vbi9KYWNrRGVi dWdDbGllbnQuY3BwJywgJy1jJywgJy1vL3Zhci9wb3J0cy93b3JrL3Vzci9wb3J0cy9hdWRp by9qYWNrL3dvcmsvamFjazItMS45LjIwL2J1aWxkL2NvbW1vbi9KYWNrRGVidWdDbGllbnQu Y3BwLjIubycsICctSS91c3IvbG9jYWwvaW5jbHVkZSddDQo+ID09PT4gQ29tcGlsYXRpb24g ZmFpbGVkIHVuZXhwZWN0ZWRseS4NCj4gVHJ5IHRvIHNldCBNQUtFX0pPQlNfVU5TQUZFPXll cyBhbmQgcmVidWlsZCBiZWZvcmUgcmVwb3J0aW5nIHRoZSBmYWlsdXJlIHRvDQo+IHRoZSBt YWludGFpbmVyLg0KPiAqKiogRXJyb3IgY29kZSAxDQo+IA0KPiBTdG9wLg0KPiBtYWtlOiBz dG9wcGVkIGluIC91c3IvcG9ydHMvYXVkaW8vamFjaw0KPiANCj4gDQo+IElzIHRoZXJlIGFu eSBzdWdnZXRpb25zID8NCj4gDQo+IE15IHBhY2thZ2UgYnVpbGQgbWFjaGluZSBlbnZpcm9u bWVudHMgYXJlIGFzIGZvbGxvd3MgOg0KPiANCj4gUG9ydHMgYnJhbmNoIGlzIDQ3ZDhmYjNh ZjNmMCBhbmQgb3RoZXJzIGFyZSA6DQo+IA0KPiBhZG1pbkBrYXp1On4gJSB1bmFtZSAtYQ0K PiBGcmVlQlNEIGthenUudGZjIDE0LjAtQ1VSUkVOVCBGcmVlQlNEIDE0LjAtQ1VSUkVOVCAj MCBuMjUyNjQxLTNmMTA2YWYwY2Q5Mi1kaXJ0eTogV2VkIEphbiAyNiAyMjo0MTo0MSBKU1Qg MjAyMiAgICAgcm9vdEB0YmVkZmM6L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3N5 cy9HRU5FUklDLURSTSAgYXJtNjQNCj4gYWRtaW5Aa2F6dTp+ICUgZGYgLWgNCj4gRmlsZXN5 c3RlbSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTaXplICAgIFVzZWQgICBBdmFpbCBDYXBhY2l0eSAg TW91bnRlZCBvbg0KPiAvZGV2L21tY3NkMHAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA4MkcgICAgIDE1 RyAgICAgNjFHICAgIDE5JSAgICAvDQo+IGRldmZzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MS4wSyAgICAxLjBLICAgICAgMEIgICAxMDAlICAgIC9kZXYNCj4gdG1wZnMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMzRHICAgIDQuMEsgICAgIDM0RyAgICAgMCUgICAgL3RtcA0KPiBs aW5wcm9jZnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQuMEsgICAgNC4wSyAgICAgIDBCICAgMTAw JSAgICAvY29tcGF0L2xpbnV4L3Byb2MNCj4gdG1wZnMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMzRHICAgIDQuMEsgICAgIDM0RyAgICAgMCUgICAgL2NvbXBhdC9saW51eC9kZXYvc2ht DQo+IGxpbnN5c2ZzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNC4wSyAgICA0LjBLICAgICAgMEIg ICAxMDAlICAgIC9jb21wYXQvbGludXgvc3lzDQo+IGRldmZzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMS4wSyAgICAxLjBLICAgICAgMEIgICAxMDAlICAgIC9jb21wYXQvbGludXgvZGV2 DQo+IGZkZXNjZnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMS4wSyAgICAxLjBLICAgICAgMEIg ICAxMDAlICAgIC9jb21wYXQvbGludXgvZGV2L2ZkDQo+IDE5Mi4xNjguMS4xNzovLmRha2Ug ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEyVCAgICA5NzNHICAgICAxMVQgICAgIDglICAgIC8uZGFrZQ0KPiAxOTIu MTY4LjEuMTc6L2RzL3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC8zZjEwNmFmMGNkOTIuZ2Vu ZXJpY19kcm0gICAgICAgICAgICAgICAgICAxMVQgICAgIDgxRyAgICAgMTFUICAgICAxJSAg ICAvdXNyL3NyYw0KPiAxOTIuMTY4LjEuMTc6L2RzL29iai9mcmVlYnNkL2N1cnJlbnQvMTQu MC8zZjEwNmFmMGNkOTIuZ2VuZXJpY19kcm0gICAgICAgICAgICAgICAgICAxMVQgICAgNDQy RyAgICAgMTFUICAgICA0JSAgICAvdXNyL29iag0KPiAxOTIuMTY4LjEuMTc6L2RzL3BvcnRz L2ZyZWVic2QvNDdkOGZiM2FmM2YwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAxMVQgICAgMTExRyAgICAgMTFUICAgICAxJSAgICAvdXNyL3BvcnRzDQo+IDE5 Mi4xNjguMS4xNzovZHMvZGlzdGZpbGVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExVCAgICAgNTRHICAgICAxMVQgICAgIDAl ICAgIC92YXIvcG9ydHMvZGlzdGZpbGVzDQo+IDE5Mi4xNjguMS4xNzovZHMvcGFja2FnZXMv ZnJlZWJzZC9hcm02NC9hYXJjaDY0LzE0LjBDLzNmMTA2YWYwY2Q5Mi80N2Q4ZmIzYWYzZjAg ICAgIDExVCAgICAxMTdHICAgICAxMVQgICAgIDElICAgIC92YXIvcG9ydHMvcGFja2FnZXMN Cj4gYWRtaW5Aa2F6dTp+ICUgdW5hbWUgLWENCj4gRnJlZUJTRCBrYXp1LnRmYyAxNC4wLUNV UlJFTlQgRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzAgbjI1MjY0MS0zZjEwNmFmMGNkOTItZGly dHk6IFdlZCBKYW4gMjYgMjI6NDE6NDEgSlNUIDIwMjIgICAgIHJvb3RAdGJlZGZjOi91c3Iv b2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC9zeXMvR0VORVJJQy1EUk0gIGFybTY0DQo+IGFk bWluQGthenU6fiAlIGRmIC1oDQo+IEZpbGVzeXN0ZW0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2l6 ZSAgICBVc2VkICAgQXZhaWwgQ2FwYWNpdHkgIE1vdW50ZWQgb24NCj4gL2Rldi9tbWNzZDBw MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgODJHICAgICAxNUcgICAgIDYxRyAgICAxOSUgICAgLw0KPiBk ZXZmcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuMEsgICAgMS4wSyAgICAgIDBCICAgMTAw JSAgICAvZGV2DQo+IHRtcGZzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM0RyAgICA0LjBL ICAgICAzNEcgICAgIDAlICAgIC90bXANCj4gbGlucHJvY2ZzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA0LjBLICAgIDQuMEsgICAgICAwQiAgIDEwMCUgICAgL2NvbXBhdC9saW51eC9wcm9jDQo+ IHRtcGZzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM0RyAgICA0LjBLICAgICAzNEcgICAg IDAlICAgIC9jb21wYXQvbGludXgvZGV2L3NobQ0KPiBsaW5zeXNmcyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDQuMEsgICAgNC4wSyAgICAgIDBCICAgMTAwJSAgICAvY29tcGF0L2xpbnV4L3N5 cw0KPiBkZXZmcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEuMEsgICAgMS4wSyAgICAgIDBC ICAgMTAwJSAgICAvY29tcGF0L2xpbnV4L2Rldg0KPiBmZGVzY2ZzICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDEuMEsgICAgMS4wSyAgICAgIDBCICAgMTAwJSAgICAvY29tcGF0L2xpbnV4L2Rl di9mZA0KPiAxOTIuMTY4LjEuMTc6Ly5kYWtlICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMlQgICAgOTczRyAgICAg MTFUICAgICA4JSAgICAvLmRha2UNCj4gMTkyLjE2OC4xLjE3Oi9kcy9zcmMvZnJlZWJzZC9j dXJyZW50LzE0LjAvM2YxMDZhZjBjZDkyLmdlbmVyaWNfZHJtICAgICAgICAgICAgICAgICAg MTFUICAgICA4MUcgICAgIDExVCAgICAgMSUgICAgL3Vzci9zcmMNCj4gMTkyLjE2OC4xLjE3 Oi9kcy9vYmovZnJlZWJzZC9jdXJyZW50LzE0LjAvM2YxMDZhZjBjZDkyLmdlbmVyaWNfZHJt ICAgICAgICAgICAgICAgICAgMTFUICAgIDQ0MkcgICAgIDExVCAgICAgNCUgICAgL3Vzci9v YmoNCj4gMTkyLjE2OC4xLjE3Oi9kcy9wb3J0cy9mcmVlYnNkLzQ3ZDhmYjNhZjNmMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTFUICAgIDExMUcgICAgIDEx VCAgICAgMSUgICAgL3Vzci9wb3J0cw0KPiAxOTIuMTY4LjEuMTc6L2RzL2Rpc3RmaWxlcyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxMVQgICAgIDU0RyAgICAgMTFUICAgICAwJSAgICAvdmFyL3BvcnRzL2Rpc3RmaWxlcw0K PiAxOTIuMTY4LjEuMTc6L2RzL3BhY2thZ2VzL2ZyZWVic2QvYXJtNjQvYWFyY2g2NC8xNC4w Qy8zZjEwNmFmMGNkOTIvNDdkOGZiM2FmM2YwICAgICAxMVQgICAgMTE3RyAgICAgMTFUICAg ICAxJSAgICAvdmFyL3BvcnRzL3BhY2thZ2VzDQo+IGFkbWluQGthenU6fiAlIGNhdCAvZXRj L21ha2UuY29uZg0KPiBQT1JUU0RJUj0gICAgICAgICAgICAgICAvdmFyL3BvcnRzL2xwYnBr eA0KPiBJTkRFWERJUj0gICAgICAgICAgICAgICAvdmFyL3BvcnRzL2xwYnBreA0KPiBXUktE SVJQUkVGSVg9ICAgICAgICAgICAvdmFyL3BvcnRzL3dvcmsNCj4gUEFDS0FHRVM9ICAgICAg ICAgICAgICAgL3Zhci9wb3J0cy9wYWNrYWdlcw0KPiBESVNURElSPSAgICAgICAgICAgICAg ICAvdmFyL3BvcnRzL2Rpc3RmaWxlcw0KPiBCQVRDSD0gICAgICAgICAgICAgICAgICB5ZXMN Cj4gREVGQVVMVF9WRVJTSU9OUz0gICAgICAgcGVybDU9NS4zNCBydWJ5PTIuNyBqYXZhPTEy DQo+IENPTVBJTEVSX1RZUEU9ICAgICAgICAgIGNsYW5nDQo+IFVTRV9QQUNLQUdFX0RFUEVO RFM9ICAgIHllcw0KPiBESVNBQkxFX1ZVTE5FUkFCSUxJVElFUz15ZXMNCj4gYWRtaW5Aa2F6 dTp+ICUNCj4gDQo+IEdFTkVSSUMtRFJNIGtlcm5lbCB3YXMgYnVpbHQgYnkgYGdpdCBzdWJ0 cmVlIGFkZCcgdG8gMTQuMC1DVVJSRU5UDQo+IChlMzU4MTZjMWM5MDkpIGZvciBQYW5mcm9z dCBkcml2ZXIgWzFdIDoNCj4gDQo+IEZpcnN0IGBnaXQgc3VidHJlZSBhZGQnIHRvIDE0LjAt Q1VSUkVOVCAoZTM1ODE2YzFjOTA5KSBpbiBzcmMgc2VydmVyIDoNCj4gDQo+IHJvb3RAdm06 L2RzL3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDkuZ2VuZXJpY19kcm0g IyBnaXQgY2hlY2tvdXQgZTM1ODE2YzFjOTA5DQo+IEhFQUQgaXMgbm93IGF0IGUzNTgxNmMx YzkwOSBhd19zcGk6IGltcHJvdmUgSS9PIHN0YWJpbGl0eQ0KPiByb290QHZtOi9kcy9zcmMv ZnJlZWJzZC9jdXJyZW50LzE0LjAvZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJtICMgZ2l0IHJl bW90ZSBhZGQgZHJtLXN1YnRyZWUgaHR0cHM6Ly9naXRodWIuY29tL2pzbTIyMi9kcm0tc3Vi dHJlZS5naXQNCj4gcm9vdEB2bTovZHMvc3JjL2ZyZWVic2QvY3VycmVudC8xNC4wL2UzNTgx NmMxYzkwOS5nZW5lcmljX2RybSAjIGdpdCBzdWJ0cmVlIGFkZCAtLXByZWZpeCBzeXMvZGV2 L2RybS8gZHJtLXN1YnRyZWUgcGluZWJvb2twcm8tdGVzdA0KPiBnaXQgZmV0Y2ggZHJtLXN1 YnRyZWUgcGluZWJvb2twcm8tdGVzdA0KPiByZW1vdGU6IEVudW1lcmF0aW5nIG9iamVjdHM6 IDc5NCwgZG9uZS4NCj4gcmVtb3RlOiBDb3VudGluZyBvYmplY3RzOiAxMDAlICg3OTQvNzk0 KSwgZG9uZS4NCj4gcmVtb3RlOiBDb21wcmVzc2luZyBvYmplY3RzOiAxMDAlICg1MTgvNTE4 KSwgZG9uZS4NCj4gcmVtb3RlOiBUb3RhbCA3OTQgKGRlbHRhIDM3MCksIHJldXNlZCA2ODUg KGRlbHRhIDI2NCksIHBhY2stcmV1c2VkIDANCj4gUmVjZWl2aW5nIG9iamVjdHM6IDEwMCUg KDc5NC83OTQpLCAxLjE0IE1pQiB8IDUuMDkgTWlCL3MsIGRvbmUuDQo+IFJlc29sdmluZyBk ZWx0YXM6IDEwMCUgKDM3MC8zNzApLCBkb25lLg0KPiAgIEZyb20gaHR0cHM6Ly9naXRodWIu Y29tL2pzbTIyMi9kcm0tc3VidHJlZQ0KPiAgICAqIGJyYW5jaCAgICAgICAgICAgICAgICAg ICAgICBwaW5lYm9va3Byby10ZXN0IC0+IEZFVENIX0hFQUQNCj4gICAgKiBbbmV3IGJyYW5j aF0gICAgICAgICAgICAgICAgcGluZWJvb2twcm8tdGVzdCAtPiBkcm0tc3VidHJlZS9waW5l Ym9va3Byby10ZXN0DQo+IEFkZGVkIGRpciAnc3lzL2Rldi9kcm0nDQo+IHJvb3RAdm06L2Rz L3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDkuZ2VuZXJpY19kcm0gIyBn aXQgYXBwbHkgc3lzL2Rldi9kcm0vZXh0cmFfcGF0Y2hlcy8wMDAxLUhvb2stRFJNLXRvLXRo ZS1idWlsZC5wYXRjaA0KPiByb290QHZtOi9kcy9zcmMvZnJlZWJzZC9jdXJyZW50LzE0LjAv ZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJtICMgZ2l0IGFwcGx5IHN5cy9kZXYvZHJtL2V4dHJh X3BhdGNoZXMvMDAwMi1BZGQtR0VORVJJQy1EUk0tZm9yLWFybXY3LnBhdGNoDQo+IHJvb3RA dm06L2RzL3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDkuZ2VuZXJpY19k cm0gIyBnaXQgYXBwbHkgc3lzL2Rldi9kcm0vZXh0cmFfcGF0Y2hlcy8wMDAzLWRybS1BZGQt cm9ja2NoaXAtYW5kLWJyaWRnZXMtaW50by1HRU5FUklDLURSTS5wYXRjaA0KPiByb290QHZt Oi9kcy9zcmMvZnJlZWJzZC9jdXJyZW50LzE0LjAvZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJt ICMgZ2l0IGFwcGx5IHN5cy9kZXYvZHJtL3BicC1rZXJuZWwtZXh0cmEtcGF0Y2hlcy9naWN2 M19pdHMuYy1wYXRjaA0KPiByb290QHZtOi9kcy9zcmMvZnJlZWJzZC9jdXJyZW50LzE0LjAv ZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJtICMgZ2l0IGFwcGx5IHN5cy9kZXYvZHJtL3BicC1r ZXJuZWwtZXh0cmEtcGF0Y2hlcy9taXhlci5jLnBhdGNoDQo+IHJvb3RAdm06L2RzL3NyYy9m cmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDkuZ2VuZXJpY19kcm0gIyBnaXQgYXBw bHkgc3lzL2Rldi9kcm0vcGJwLWtlcm5lbC1leHRyYS1wYXRjaGVzL3N5c19kZXZfaWljYnVz X2VzODMxNi5jDQo+IHJvb3RAdm06L2RzL3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4 MTZjMWM5MDkuZ2VuZXJpY19kcm0gIyBnaXQgYXBwbHkgc3lzL2Rldi9kcm0vcGJwLWtlcm5l bC1leHRyYS1wYXRjaGVzL0dFTkVSSUMtRFJNLnBhdGNoDQo+IHJvb3RAdm06L2RzL3NyYy9m cmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDkuZ2VuZXJpY19kcm0gIyBnaXQgYXBw bHkgc3lzL2Rldi9kcm0vcGJwLWtlcm5lbC1leHRyYS1wYXRjaGVzL3N5c19tb2R1bGVzX2R0 Yl9yb2NrY2hpcF9NYWtlZmlsZS5wYXRjaA0KPiByb290QHZtOi9kcy9zcmMvZnJlZWJzZC9j dXJyZW50LzE0LjAvZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJtICMgZ2l0IGFwcGx5IHN5cy9k ZXYvZHJtL3BicC1rZXJuZWwtZXh0cmEtcGF0Y2hlcy9tbWMuYy5wYXRjaA0KPiByb290QHZt Oi9kcy9zcmMvZnJlZWJzZC9jdXJyZW50LzE0LjAvZTM1ODE2YzFjOTA5LmdlbmVyaWNfZHJt ICMgZ2l0IHJldi1wYXJzZSAtLXZlcmlmeSAtLXNob3J0IEhFQUQNCj4gM2YxMDZhZjBjZDky DQo+IHJvb3RAdm06L2RzL3NyYy9mcmVlYnNkL2N1cnJlbnQvMTQuMC9lMzU4MTZjMWM5MDku Z2VuZXJpY19kcm0gIyBjZCAuLg0KPiByb290QHZtOi9kcy9zcmMvZnJlZWJzZC9jdXJyZW50 LzE0LjAgIyBtdiBlMzU4MTZjMWM5MDkuZ2VuZXJpY19kcm0gM2YxMDZhZjBjZDkyLmdlbmVy aWNfZHJtDQo+IA0KPiBhbmQgdGhlbiBidWlsZCBHRU5FUklDLURSTSBpbiBQQlAgOg0KPiAg ICANCj4gIyBjZCAvdXNyL3NyYw0KPiAjIG1ha2UgYnVpbGR3b3JsZCBUQVJHRVQ9YXJtNjQN Cj4gIyBtYWtlIGJ1aWxka2VybmVsIFRBUkdFVD1hcm02NCBLRVJOQ09ORj1HRU5FUklDLURS TQ0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBbMV0gaHR0cHM6Ly9naXRodWIuY29tL2pz bTIyMi9kcm0tc3VidHJlZQ0KPiAtLS0NCj4gS2F6dWhpa28gS2lyaXlhbWEgPGtpcmlAdHJ1 ZWZjLm9yZz4NCj4gDQpQbGVhc2Ugc2VlIGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6 aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjYxNTA4DQovanNtDQo= From nobody Thu Feb 10 09:03:49 2022 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 05AD819BF926; Thu, 10 Feb 2022 09:03:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4JvW586h2dz4p6X; Thu, 10 Feb 2022 09:03:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644483837; 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: in-reply-to:in-reply-to:references:references; bh=OjhHTlFz7q7zbu06pdUzdTSR+XelOfXKogO8u4GRuTA=; b=IM6bsA8HLRJkrbXlQ4LfgR2rhR58JjLmlE/XCKniC9vNMx/cpsBsCFrXEOOYWEZQ0U9kAC QTZStGJR8cjDabdaugwgYKo49obp9d8ifFmI1ohkb7WMz1HDB+pcFIyR/YeQb2aXsYWZeE WMcY7WauYHE2GDSRHgfwb+lvba+xhB7eWFKZKAGx5c1DLSIMIn7KGweO1CbsO6kPCRqpsA lVb4+T+4AQvkZpqFSmJhjdSVdARapDL6fL5mxjmcx+sTK1oJUzNr8TQjFGbGOhmbkHkd57 jvuTDfJGyCL5Q/SiWbHBPirLRbPddtlwczLe68r3oLJP0WdETglK768KbJPCOg== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id A85C82D967; Thu, 10 Feb 2022 09:03:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow-wifi.home.andric.com [192.168.0.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3638A6748C; Thu, 10 Feb 2022 10:03:55 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1FEDF63A-D46F-4EC2-9AB2-369149D6CA45"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 15.0 \(3693.60.0.1.1\)) Subject: Re: Can't build audio/jack in arm64/aarch64 on PBP From: Dimitry Andric In-Reply-To: <202202100748.21A7mPTM037482@kx.truefc.org> Date: Thu, 10 Feb 2022 10:03:49 +0100 Cc: ports@freebsd.org, freebsd-arm@freebsd.org Message-Id: <2B03CBA1-2232-4CB2-A9FA-A7A36DEF64AE@FreeBSD.org> References: <202202100748.21A7mPTM037482@kx.truefc.org> To: KIRIYAMA Kazuhiko X-Mailer: Apple Mail (2.3693.60.0.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644483836; 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: in-reply-to:in-reply-to:references:references; bh=OjhHTlFz7q7zbu06pdUzdTSR+XelOfXKogO8u4GRuTA=; b=JcJ7Aj1GpQOSDuD+5/k7mEQZeruIPityZ0ea1GJoU0xLCV/GPkXB0P9tld8P5PqN8FSz/7 LSXMzXeTR2M7/iVjzjSKhewxZodf9+xjIoqxw6fvtwGlTMJ+GCuYAo5ZO0IX+sqlhSWCoL aViUbSWMfRi913kNGzCDQ1pGrSpwXZ52TtW4zwiuEZqZwNODUYXsZWxsgQTwKKu7+1BzWL IqVC/I4skdCEESXn+BAPh4+C6ger/ikTZNRy64Qxv84FU5CAKMrxGWahMge9SaXd5lp/GE VYO99tbW1F0RVjFCzZOeL2uJlPhU4vT3RHYCpShlrMuQ+enSTqWuom/0p2FunA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644483836; a=rsa-sha256; cv=none; b=mxMNCOMND5+48gwZHA2HJS5E0wW54FsLqM9fSQiK8ecDBS+qUDhHLRTK2zXa1CAjad2tL9 EoIgj2406G/HO5sd+D2AWaq6ujvw9foRUudxfTbDuphUU30PaEuqrl2pRh4c2Z/KfO2+AI MNSyjvMdKBi4NU4u4OcgDLllrvqfOzHqh1rueLrR9D2UsaBC7g1QWgW/hnV1WC/e2QUJqe 5/F62pEEDZxwWO8lRE6yqZPhvz+NWB8zMHiVMBDWXsT1aQ3vyoMJnANaH3sv3HjpnhC1TV 8kj7fSzdOG5AYMEYZ4zJMthZuVKZ26vGqc9v6kHB/poe3FcJvhTVOcVldbttNw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1538 Lines: 50 --Apple-Mail=_1FEDF63A-D46F-4EC2-9AB2-369149D6CA45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Feb 2022, at 08:48, KIRIYAMA Kazuhiko wrote: >=20 > Hi, lists >=20 > I've tried to build arm64/aarch64 packages on Pinebook Pro > (PBP). audio/jack failed to build at build/common/memops.c : >=20 > 2 errors generated. >=20 > In file included from ../common/JackDebugClient.cpp:21: > ../common/JackEngineControl.h:67:5: error: requested alignment is less = than minimum alignment of 8 for type 'Jack::JackTransportEngine' > alignas(UInt32) JackTransportEngine fTransport; > ^ > ../common/JackEngineControl.h:89:5: error: requested alignment is less = than minimum alignment of 8 for type 'Jack::JackFrameTimer' > alignas(UInt32) JackFrameTimer fFrameTimer; > ^ > 2 errors generated. Please see https://bugs.freebsd.org/261508, and = https://cgit.freebsd.org/ports/commit/?id=3D22c0c4f2a6e599c4530dc47025f9f7= 153262f381. -Dimitry --Apple-Mail=_1FEDF63A-D46F-4EC2-9AB2-369149D6CA45 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYgTU9QAKCRCwXqMKLiCW o/tPAJ0dvhgPJci4klxK9xHK3DJWEPaYIgCg+s1Wq3d6dBPfwQpC8AapU6xhz6w= =9qBD -----END PGP SIGNATURE----- --Apple-Mail=_1FEDF63A-D46F-4EC2-9AB2-369149D6CA45-- From nobody Thu Feb 10 09:06:05 2022 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 B975819C0139; Thu, 10 Feb 2022 09:06:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JvW7y61vSz4qB2; Thu, 10 Feb 2022 09:06:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A2DBA2600D0; Thu, 10 Feb 2022 10:06:14 +0100 (CET) Message-ID: Date: Thu, 10 Feb 2022 10:06:05 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Can't build audio/jack in arm64/aarch64 on PBP Content-Language: en-US To: KIRIYAMA Kazuhiko , ports@freebsd.org Cc: freebsd-arm@freebsd.org References: <202202100748.21A7mPTM037482@kx.truefc.org> From: Hans Petter Selasky In-Reply-To: <202202100748.21A7mPTM037482@kx.truefc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JvW7y61vSz4qB2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-1.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_SPAM_MEDIUM(0.99)[0.989]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,ports]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 796 Lines: 24 On 2/10/22 08:48, KIRIYAMA Kazuhiko wrote: > Hi, lists > > I've tried to build arm64/aarch64 packages on Pinebook Pro > (PBP). audio/jack failed to build at build/common/memops.c : > > 2 errors generated. > > In file included from ../common/JackDebugClient.cpp:21: > ../common/JackEngineControl.h:67:5: error: requested alignment is less than minimum alignment of 8 for type 'Jack::JackTransportEngine' > alignas(UInt32) JackTransportEngine fTransport; > ^ > ../common/JackEngineControl.h:89:5: error: requested alignment is less than minimum alignment of 8 for type 'Jack::JackFrameTimer' > alignas(UInt32) JackFrameTimer fFrameTimer; > ^ > 2 errors generated. > Is this after: https://cgit.freebsd.org/ports/commit/?id=22c0c4f2a6e599c4530dc47025f9f7153262f381 --HPS From nobody Thu Feb 10 21:19:44 2022 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 520D019BD193 for ; Thu, 10 Feb 2022 21:19:48 +0000 (UTC) (envelope-from SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JvqQC2jCXz4gb3; Thu, 10 Feb 2022 21:19:47 +0000 (UTC) (envelope-from SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl) Date: Thu, 10 Feb 2022 22:19:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1644527984; 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: in-reply-to:in-reply-to:references:references; bh=qtCidS8VIGRuWn7g8OYa31iTH5+E+Ou/sRUlDbgUGL0=; b=jp55IjW8uG2ugzRDMIMNzpKyarBZ7FkGZaI/OQ1iqRMjvIaeMAtO6lD0UYaOF2zkIz1a21 5EXwlEbXdQJPfJ8OSS/zIAmK9C6a9xSq6LNQcFkFKebUPdfYxyG7sdpfNLwNjMK3oDSaFF vPOJSVMHsl0aisckTyXmjdiM6rLsuAUg9aMfTvsNzAPhVd7xEgAjvxjmgGkrOksTzuHzX2 fFmMhgaR4oeD5K7wI7JeER6XWVuiL1Vxho8SilP2QRWOwBDkCtX4cR+X58q6X3w4ouot3o ekuvLIzqeTpY0B7nyVIh6Jov66Ua4fsRWUAMK9jLJovGHvdUFMYd+aNjdJevhg== From: Ronald Klop To: Philip Paeps Cc: clusteradm@freebsd.org, Ports Management Team , freebsd-arm@freebsd.org Message-ID: <787825862.6.1644527984584@mailrelay> In-Reply-To: <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> References: <1365005114.369.1643120837534@localhost> <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> Subject: Re: aarch64 build cluster and linux64.ko 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="----=_Part_5_1780688122.1644527984500" X-Mailer: Realworks (596.80.96c7f06) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JvqQC2jCXz4gb3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=jp55IjW8; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=wOOK=SZ=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 7127 Lines: 133 ------=_Part_5_1780688122.1644527984500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Philip Paeps Datum: maandag, 31 januari 2022 04:15 Aan: Ronald Klop CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team Onderwerp: Re: aarch64 build cluster and linux64.ko > > On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: > > On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: > >> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded. > >> > >> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer > >> ======================= >> >============================ > >> ===> linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found > >> ===> Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg > >> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... > >> Cannot install package: kernel missing 64-bit Linux support > >> pkg-static: PRE-INSTALL script failed > >> > >> > >> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete? > >> > >> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded. > > > > We can include linux64.ko in the next cluster build for aarch64. I'll > try to find time for another cluster refresh. It's been a while since > the last one. > > I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko. The module seems to load. portmgr might need to do something to the builds to actually use it though. > > I'll upgrade the other aarch64 package builder when it finishes its current build. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > > > Hi, Ampere1 as well as ampere2 are upgraded but I do not see the effect of linux64.ko being loaded. e.g. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c_s511b83b167/logs/errors/linux-c7-lz4-1.8.3.log : =================================================== ===> linux-c7-lz4-1.8.3 depends on package: linux_base-c7>=7.6.1810_7 - not found ===> Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg [main-arm64-default-job-13] Installing linux_base-c7-7.9.2009... Cannot install package: kernel missing 64-bit Linux support pkg-static: PRE-INSTALL script failed I can easily reproduce this error on my local poudriere by not loading the module linux64.ko. If it is loaded the linux-c7-* ports build fine. Having this fixed will give quite a lot less failed+skipped ports on aarch64. Who can I ask to check this? Regards, Ronald. ------=_Part_5_1780688122.1644527984500 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Philip Paeps <philip@freebsd.org>
Datum: maandag, 31 januari 2022 04:15
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team <portmgr@freebsd.org>
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote:
> On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote:
>> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded.
>>
>> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer
>> =======================<phase: run-depends    
>> >============================
>> ===>   linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found
>> ===>   Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg
>> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...
>> Cannot install package: kernel missing 64-bit Linux support
>> pkg-static: PRE-INSTALL script failed
>>
>>
>> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete?
>>
>> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded.
>
> We can include linux64.ko in the next cluster build for aarch64.  I'll > try to find time for another cluster refresh.  It's been a while since > the last one.

I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko.  The module seems to load.  portmgr might need to do something to the builds to actually use it though.

I'll upgrade the other aarch64 package builder when it finishes its current build.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

Hi,

Ampere1 as well as ampere2 are upgraded but I do not see the effect of linux64.ko being loaded.

e.g. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c_s511b83b167/logs/errors/linux-c7-lz4-1.8.3.log : 
=======================<phase: run-depends    >============================
===>   linux-c7-lz4-1.8.3 depends on package: linux_base-c7>=7.6.1810_7 - not found
===>   Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg
[main-arm64-default-job-13] Installing linux_base-c7-7.9.2009...
Cannot install package: kernel missing 64-bit Linux support
pkg-static: PRE-INSTALL script failed

I can easily reproduce this error on my local poudriere by not loading the module linux64.ko. If it is loaded the linux-c7-* ports build fine.
Having this fixed will give quite a lot less failed+skipped ports on aarch64.
Who can I ask to check this?

Regards,
Ronald.
  ------=_Part_5_1780688122.1644527984500-- From nobody Fri Feb 11 01:25:13 2022 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 770F319B0714 for ; Fri, 11 Feb 2022 01:25:17 +0000 (UTC) (envelope-from philip@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 4JvwsT2cd2z3H2q; Fri, 11 Feb 2022 01:25:17 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644542717; 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: in-reply-to:in-reply-to:references:references; bh=5Boq2f4FgxJ02DOC00zN4JpLY2Crw0oFClOYXI4+b6M=; b=OFyB9L37WUAS0LieerB2pn9ZCTRJlHWV5gSC3yo4S0yO94ifjFlL0OWyRve19UnK9Qr2EK Fj4tKYKLupnA6oZWaiGq2gc4xVzX1Ew8kYFFIw5r+pWftduqjNVWTA2A2H1eyeBLKy9jwz K4esJJsM1DPpGBfLGfXmtPIqWBg47zFJXr4GgkLw0qZFaYF9oTqTXb1aSv7EVARB+Vvk87 8OAiL9J/222DkzjBmWWdlUobWX2jWcpV0wauN5kBbke/+ZGK/BYIzGdwr05dCw3Y68/axB FsPvCQ60uwbzvKcaeIyCpSNS3nttR3POxzjEur+nbSIwyC3iXMRwnGtLD1v/RA== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 30482648B; Fri, 11 Feb 2022 01:25:17 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 200C527C0054; Thu, 10 Feb 2022 20:25:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 10 Feb 2022 20:25:17 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedvgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddutddmnecujfgurhephffvuf ffoffkjghfgggtsegrtdhmreertdejnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcu oehphhhilhhiphesfhhrvggvsghsugdrohhrgheqnecuggftrfgrthhtvghrnhepkedtge ehteekffdvleduhfelgffhhfeftdegudefhedugfeufeetkeegvdfhuedunecuffhomhgr ihhnpehiphhviehprhhogiihrdhnvghtpdhfrhgvvggsshgurdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghs mhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektd dtkedqphhhihhlihhppeepfhhrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Feb 2022 20:25:14 -0500 (EST) From: Philip Paeps To: Ronald Klop Cc: clusteradm@freebsd.org, Ports Management Team , freebsd-arm@freebsd.org Subject: Re: aarch64 build cluster and linux64.ko Date: Fri, 11 Feb 2022 09:25:13 +0800 X-Mailer: MailMate (1.14r5869) Message-ID: <1666CD64-2A90-4BBC-9DEF-C9BCED4738FF@freebsd.org> In-Reply-To: <787825862.6.1644527984584@mailrelay> References: <1365005114.369.1643120837534@localhost> <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> <787825862.6.1644527984584@mailrelay> 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="=_MailMate_FD889266-A938-4762-AFCB-F7BF76969485_=" Embedded-HTML: [{"plain":[52,2930],"uuid":"1CD4FC1F-5F7F-4A46-B2A7-CB223D1AF1D9"}] ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644542717; 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: in-reply-to:in-reply-to:references:references; bh=5Boq2f4FgxJ02DOC00zN4JpLY2Crw0oFClOYXI4+b6M=; b=WRprFbC+xFzGTqoZz0OjQL/8SlsLVP/gmKP2uMAGL0DQpEIZMiIc52UhHqNIaJKVkrNF82 7dAvCGWqG/2yCl6nJ8XaQJuqqjmvzBCnb+wTCoUjs2e9hCAw5Bkqxrg38gmsMiGOUNgPnR QSylphdCl0+nF8QNecgZMdlz6uQMt4JzRPnx+D54k9vlkOH1BgTqeC1efNEepV2hUk2+xw OkFCcbLqQB47z4QE6zPM0EpPz+zleT4zlRADEquahxKbm1z3LWm8rDA20gL3PUSmvOsMXG IQd8cYHj13DLd263WbMLDxwG5tool10eWbK0romCm7GWniDk41esiAeFXpokKA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644542717; a=rsa-sha256; cv=none; b=cjX0ByWJVBoiKsnj5MkzVXjhDf9VYJJNH4tfXuiz9q6akmREMHF0e0vRNkxfet/5V1r/V4 X06IUHYnmse8Gyu4Jw0bKzX1SFq7uqxneQ3Umke9WAzZICA+PulQrtvpcy9naGn4zWMBEk S7WE+s0TTJsYnAuKdfr7YXVHcSCEOalzwuH4aDpJjW2kIm5ELnpy29ucaKhX+PM2SUiOjI uws9vTbZ9F6Y9fU42aoPPfdwVYxV5cu/kp6pgm+0zy8Cx9aG+FiwgaXHs4EEmy3lUCDUE1 jnwhuZdJvPK78m8k2GQ2L2wTDoU7YteM0GsC/zAmlpPssEnRySC3TzkVxHZi5w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 9479 Lines: 277 --=_MailMate_FD889266-A938-4762-AFCB-F7BF76969485_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable On 2022-02-11 05:19:44 (+0800), Ronald Klop wrote: > Van: Philip Paeps > Datum: maandag, 31 januari 2022 04:15 > Aan: Ronald Klop > CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management = > Team > Onderwerp: Re: aarch64 build cluster and linux64.ko >> >> On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: >>> On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: >>>> Currently the packages depending on linux_base-c7 can not be >> = >>>> pre-build on the package cluster because the kernel does not have = >>>> >> linux64.ko loaded. >>>> >>>> See: >> = >>>> http://www.ipv6proxy.net/go.php?u=3Dhttp%3A%2F%2Fampere2.nyi.freebsd= =2Eorg%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Fe= rrors%2Flinux-c7-libpng-1.5.13_3.log&b=3D0&f=3Dnorefer >>>> =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> linux-c7-libpng-1.5.13_3 depends on package: >> = >>>> linux_base-c7>=3D7.6.1810_7 - not found >>>> =3D=3D=3D> Installing existing package >> = >>>> /packages/All/linux_base-c7-7.9.2009.pkg >>>> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... >>>> Cannot install package: kernel missing 64-bit Linux support >>>> pkg-static: PRE-INSTALL script failed >>>> >>>> >>>> Is it possible to have linux64.ko loaded on the pkg builders so the = >>>> >> aarch64 packages will be more complete? >>>> >>>> At least on my rpi4/aarch64 poudriere I could build pkg >> = >>>> linux-c7-libpng with linux64.ko loaded. >>> >>> We can include linux64.ko in the next cluster build for aarch64. = >>> I'll > try to find time for another cluster refresh. It's been a = >>> while since > the last one. >> >> I've upgraded one of the package builders (ampere1.nyi.freebsd.org) = >> with a build including linux64.ko. The module seems to load. = >> portmgr might need to do something to the builds to actually use it = >> though. >> >> I'll upgrade the other aarch64 package builder when it finishes its = >> current build. >> >> Philip >> >> -- = >> Philip Paeps >> Senior Reality Engineer >> Alternative Enterprises >> >> >> > > Hi, > > Ampere1 as well as ampere2 are upgraded but I do not see the effect of = > linux64.ko being loaded. > > e.g. = > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c_s5= 11b83b167/logs/errors/linux-c7-lz4-1.8.3.log = > : > =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> linux-c7-lz4-1.8.3 depends on package: = > linux_base-c7>=3D7.6.1810_7 - not found > =3D=3D=3D> Installing existing package = > /packages/All/linux_base-c7-7.9.2009.pkg > [main-arm64-default-job-13] Installing linux_base-c7-7.9.2009... > Cannot install package: kernel missing 64-bit Linux support > pkg-static: PRE-INSTALL script failed > > I can easily reproduce this error on my local poudriere by not loading = > the module linux64.ko. If it is loaded the linux-c7-* ports build = > fine. > Having this fixed will give quite a lot less failed+skipped ports on = > aarch64. > Who can I ask to check this? > > Regards, > Ronald. I have loaded the module on ampere1 and ampere2 and added = linux64_load=3D"YES" to their /boot/loader.conf files. I have also done = this on the new ampere3 machine portmgr hasn't taken into production yet = (I only installed that one yesterday). If that's all it takes, it should be picked up in the next build. If = poudriere needs to be taught something ... that's really a portmgr task. Philip -- = Philip Paeps Senior Reality Engineer Alternative Enterprises --=_MailMate_FD889266-A938-4762-AFCB-F7BF76969485_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 2022-02-11 05:19:44 (+080= 0), Ronald Klop wrote:

 

Van: Philip Paeps <philip@freebsd.org>
Datum: maandag, 31 januari 2022 04:15
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Por= ts Management Team <portmgr@freebsd.org>
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-01-26 08:58:20 (+0800),= Philip Paeps wrote:
> On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote:
>> Currently the packages depending on linux_base-c7 can not be >= ;> pre-build on the package cluster because the kernel does not have &= gt;> linux64.ko loaded.
>>
>> See: >> http://www.ipv6proxy.net/go.php?u=3Dhttp%3A%2F%2Fampere= 2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293= %2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=3D0&f=3Dnorefer=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<phase: run-depends    
>> >=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>   linux-c7-libpng-1.5.13_3 depends on pa= ckage: >> linux_base-c7>=3D7.6.1810_7 - not found
>> =3D=3D=3D>   Installing existing package >> /= packages/All/linux_base-c7-7.9.2009.pkg
>> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...=
>> Cannot install package: kernel missing 64-bit Linux support
>> pkg-static: PRE-INSTALL script failed
>>
>>
>> Is it possible to have linux64.ko loaded on the pkg builders so = the >> aarch64 packages will be more complete?
>>
>> At least on my rpi4/aarch64 poudriere I could build pkg >>= linux-c7-libpng with linux64.ko loaded.
>
> We can include linux64.ko in the next cluster build for aarch64. &nb= sp;I'll > try to find time for another cluster refresh.  It's bee= n a while since > the last one.

I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with = a build including linux64.ko.  The module seems to load.  portm= gr might need to do something to the builds to actually use it though.
I'll upgrade the other aarch64 package builder when it finishes its curre= nt build.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

Hi,

Ampere1 as well as ampere2 are upgraded but I do not see the effect of li= nux64.ko being loaded.

e.g. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c= _s511b83b167/logs/errors/linux-c7-lz4-1.8.3.log : 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
phase: run-depends    >=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>   linux-c7-lz4-1.8.3 depends on package: linux_base-c7>=3D=
7.6.1810_7 - not found
=3D=3D=3D>   Installing existing package /packages/All/linux_base-c7-7=
=2E9.2009.pkg
[main-arm64-default-job-13] Installing linux_base-c7-7.9.2009...
Cannot install package: kernel missing 64-bit Linux support
pkg-static: PRE-INSTALL script failed

I can easily reproduce this error on my local poudriere by not loading th= e module linux64.ko. If it is loaded the linux-c7-* ports build fine.
= Having this fixed will give quite a lot less failed+skipped ports on aarc= h64.
Who can I ask to check this?

Regards,
Ronald.
 


I have loaded the module on ampere1 and ampere2 and added linux64_load=3D= "YES" to their /boot/loader.conf files. I have also done this on the new= ampere3 machine portmgr hasn't taken into production yet (I only install= ed that one yesterday).

If that's all it takes, it should be picked up in the nex= t build. If poudriere needs to be taught something ... that's really a p= ortmgr task.

Philip

-- =
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

--=_MailMate_FD889266-A938-4762-AFCB-F7BF76969485_=-- From nobody Fri Feb 11 17:17:14 2022 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 AABA819C2D36 for ; Fri, 11 Feb 2022 17:17:19 +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 4JwKzv6Vmxz4kt8 for ; Fri, 11 Feb 2022 17:17:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 21BHHFDr033682 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 11 Feb 2022 09:17:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 21BHHFsH033681; Fri, 11 Feb 2022 09:17:15 -0800 (PST) (envelope-from fbsd) Date: Fri, 11 Feb 2022 09:17:14 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Loader pauses on Pi4 without input Message-ID: <20220211171714.GA33662@www.zefox.net> 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-Rspamd-Queue-Id: 4JwKzv6Vmxz4kt8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [-1.07 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:server fail]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1460 Lines: 40 A Pi4 running -current updated yesterday boots fine from a USB hard disk, but for some reason pauses at the loader prompt despite not getting any input on the serial console. There is a monitor/keyboard connected, but the monitor is powered off and the keyboard is out of reach, so I didn't bump it. Is there a software switch somewhere that controls this behavior? Eventually I'll want the machine to come up hands-off, though for now there's no harm in typing the boot command. Here's a snippet of serial console output: Loading kernel... /boot/kernel/kernel text=0x2a8 text=0x84ad60 text=0x247fd4 data=0x1b92a8 data=0x0+0x40d000 syms=[0x8+0x1331a0+0x8+0x15a6c1] Loading configured modules... /boot/kernel/filemon.ko text=0x1867 text=0x2558 data=0x510+0x20 syms=[0x8+0xd08+0x8+0x7c9] /etc/hostid size=0x25 /boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6d8+0x10 syms=[0x8+0xf18+0x8+0xb5c] loading required module 'ucom' /boot/kernel/ucom.ko text=0x2590 text=0x2f00 data=0x8e0+0x858 syms=[0x8+0x1290+0x8+0xbd5] /boot/entropy size=0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. OK boot Using DTB provided by EFI at 0x7ef0000. EFI framebuffer information: addr, size 0x3e22c000, 0x8ca000 dimensions 1920 x 1200 stride 1920 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 Thanks for reading, and any hints. bob prohaska From nobody Sat Feb 12 18:56:18 2022 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 CAC9A19B26B5 for ; Sat, 12 Feb 2022 18:56:20 +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 4Jx07l6pzQz3HHR for ; Sat, 12 Feb 2022 18:56:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 21CIuIiG037466 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Feb 2022 10:56:19 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 21CIuI8D037465; Sat, 12 Feb 2022 10:56:18 -0800 (PST) (envelope-from fbsd) Date: Sat, 12 Feb 2022 10:56:18 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <20220212185618.GA37391@www.zefox.net> 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-Rspamd-Queue-Id: 4Jx07l6pzQz3HHR X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [2.93 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-0.93)[-0.932]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.959]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2854 Lines: 59 For a few weeks now a Pi3 running -current will not respond to an incoming ssh connection unless an outbound ping process is running. Once the outbound ping is started via the serial console, incoming ssh connections are answered normally. Uname -a reports FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #10 main-n253073-6db44b0158c: Sat Feb 12 04:30:21 PST 2022 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 A Pi4 running -current of a few days ago exhibits no such problems. Another Pi3 running stable/13 has been behaving in the same way. Both Pi3s successfully set time via ntp on reboot and will very briefly (one or two minutes) prompt for an ssh password, but no further progress is made and the login attempt times out. If the ssh login is attempted a second time, not even a password prompt comes back. Ping times (to an adjacent machine on the same subnet are 64 bytes from 50.1.20.26: icmp_seq=2 ttl=64 time=0.978 ms 64 bytes from 50.1.20.26: icmp_seq=3 ttl=64 time=0.967 ms 64 bytes from 50.1.20.26: icmp_seq=4 ttl=64 time=1.088 ms 64 bytes from 50.1.20.26: icmp_seq=5 ttl=64 time=0.983 ms 64 bytes from 50.1.20.26: icmp_seq=6 ttl=64 time=1.007 ms 64 bytes from 50.1.20.26: icmp_seq=7 ttl=64 time=1.075 ms 64 bytes from 50.1.20.26: icmp_seq=8 ttl=64 time=1.020 ms 64 bytes from 50.1.20.26: icmp_seq=9 ttl=64 time=1.044 ms 64 bytes from 50.1.20.26: icmp_seq=10 ttl=64 time=1.026 ms 64 bytes from 50.1.20.26: icmp_seq=11 ttl=64 time=0.908 ms That might be considered slow, but the correspondent machine is only a Pi2 running FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-71d2d5adfe: Tue Dec 21 00:23:51 PST 2021 bob@www.zefox.com:/usr/obj/usr/freebsd-src/arm.armv7/sys/GENERIC arm If the outbound ping is started, an incoming ssh connection established and the outbound ping subsequently stopped the running ssh connection silently freezes; no disconnect, but no response, not even echo. Some tens of seconds later, all inputs were responded to. Tried a second time, the stoppage recurred, restarting the outbound ping eventually restored responsiveness. With the outbound ping stopped, an inbound ssh attempt silently failed: bob@raspberrypi:~ $ ssh -vvv 50.1.20.28 OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolve_canonicalize: hostname 50.1.20.28 is address debug2: ssh_connect_direct debug1: Connecting to 50.1.20.28 [50.1.20.28] port 22. [enter key echoed] debug1: connect to address 50.1.20.28 port 22: Connection timed out ssh: connect to host 50.1.20.28 port 22: Connection timed out bob@raspberrypi:~ $ Thanks for reading and any insights. If I've omitted useful details or tests please indicate. bob prohaska From nobody Sat Feb 12 21:32:25 2022 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 780961957849 for ; Sat, 12 Feb 2022 21:32:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jx3c440vWz3q17 for ; Sat, 12 Feb 2022 21:32:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644701549; bh=tGUZy8QXjEFyNiXMeCyCzPGBHqhq1udZ4LQJfi6nNn0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eWYaSi2/gZ690zkLepMGFP0ncqPYpKpECrVAxIBHlCBk1+uhUInl81pj7nc6xJtwJZmpcSwoO9IwNGOeRr02gwgwwZThfpZskIkYFl0S9GWiRTHEMDMYvv2G7iHalc6D93OsxrH1bVgUb8mp9qPm4khVsR9nf/T5gte/1r9OqoPNd3mN2Zc2vHZDFoXMH/FoJQB9fle9zd26/d2mr2vtG+IEPwMqPqrxSpMS8+jZG87Uq36EFFM2bjU3wHD2Tt+9TqRG1pZ60jfZlLKunef00C0nW+ClUFcpMtioWFp4WlnvuZQBJ7SQ7ARaYD1Twhk65zEVSidJ+SkOFgaF8W8qCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644701549; bh=kJdt0WKLtIfgTMLom26e8t9SKPejTKc3m5ND0VS2QoJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AMUvQBQTGfznhg6phoZpdzXZP2THQFzVhj0+0XPTAU1i20TrqjCzbiqGQoJ1y9urgQwTBTzXlhkLyZFsAq6Gr+D1yHoJYmsQHd9EwkLEAkvKi7BZ4qTTn2Ekm/OLCdJkaV6NtqAMEi6gpJKZ1/djdAvk1QaJHX4mhtEQYIaMsMOIWb5WHGmeQYRhOZy7AT2fKpDqBvNWnMBggkFAavZ1d6yeQhRK6++GIfu9613c5SIqPi/Cu7nGgGn8RlHz5fxlSdUv980/+ZPUq4lIB6QpXf5IVyUfCmRpLnrCxTN2f6MCPGgCRg3grL+9DpRAOCRBAS7esXOrFrolNujMPn7WiA== X-YMail-OSG: l8Wmo0sVM1lXPIgmUN9K2B.S2l3Yj_CDDJpB4c1docVRElDkZhetVjRUPPvxpPk 5FR5FoQnCFMP2AC3oS9csBdINJOrYm9QO0rAzL_XoDy_3FT.xE1qEqT1xeclkBQ1t60rcohvDgd8 qRcMNYl702EPuczY_W1WfuIzQV.WaYYxoN47cYyT5_HEUZnNliX0yjCw9e_Mkp5KyyxvtAa8Ner5 yuHdQwjmygzzDzI6QPYYqOc48yAgsYKETusXQl8x.2ukkQLIcdtXj2GcJ61mc87JrpIia_fUCle3 Yr4qms2XctW6zmklbE.6EIkQ6p41jd77HlhZ_nEhX6KNR4uP5X7443oRsAYmlm7grNHA_8uJTgAL Fo7RLz5R0fPuQgEzJto6y06P4A7IdFQaMSGFQmfbXgDSa87c.Tj1S64SL21oEKj0N6ZA5uaEVOqK nsXRLXGbmtDsH5JEUuDCkKoRWaNfBcr34Q9AELqtA_fUDV6ZMUbZr6JukjgvCs3gJFC6LHybMhGI .iKioyVhGbElCTNCtorSINWKv1mK6OgUw8cT4yaV0mk37Rm5qMutqgq.L3XJ3y8W64Bxk7.QTDCd Wd4kdn07GiG.wJ2P4lBL.DEVCmErEWCND0DCn9Ni58D5KgxTJG5Uts.Fv5ycVSlgzMVfhiJtYJ5T UG_6zFw0t6Th2q2Jtgh0w1x2OMefcK4tGPmqcJv9iOylXiF41JkDGD7j_btXzMRMkmJByNb1sQja jjxIkfQoaWK.1XoDJuXcHBTRP3tXekayP0hmmeaBMCJllgtXYa6nNiRLmvSsNiBfTCuUm2vgdwzV EQaZz4Lsnk1oiggPkpZVNtlrXk3xHBmCXrKgMuMYeOpk1xXBLwHwv8yEffF4HLVOID1qBpmQdUTx RMPcB_1.RApEgXXamGH5GOZnPvXF3UawonaZ5G33RwtR67w.GI68aEB_W51t.t70pVz4pM.FOgRx C41Ar9wniHRhhCIUJ9ewAA0ctHNCbayEI1za1GRw0fUMCIH7s7ImwQoIGT9znjJeWz9eB9MaDI5B bR9hyfQcniYkVEHWcH94NeG51MVglc48GAFe8aIpU4SZw2yCfOycJs5iHVY5Eux.KeMvwjNNbINL w4dWUMI.5wTUYjggBtL8rYF1jMeRzqPP_B044aviSfk4zvwNMXiPORz5sm3xHWWne.MjQJobb8Xo EJJDomWYutQMJUleE0nbD2S2bghKTAaXIMFZ9KTlyfzqPSsvY0YHedotebkB5bWiOgbcG_Mv3pk. Zu1DTvxO.CLC5_TjYVomBpbPB2gFimWPjESTMClPwAmCG99ujucQ8kfhqIOSjl9O9mq4y4G6..AH rXkAo_Q.vhSHm3sBJNBC5DWQLpYcak53tSD7WlsuhG8Q7t.OCVvALkcWfZzlBCJEvDsBhZPYV3o_ PHSgjMkjJ9aLH_MMCwwxZx9m2QVdUMpenwwFoYHFFx6kY.NQ05gWGFWBw59rHNfMilbnW14UR5WO AMiMiC9w.OyIrGV7.bYLYmEDatVWs9rGyXs0tal9qwx7RUrk9E.8JATQxe6gHpAYbD_C2stSWcTS 0myAF93Dl3mXa9vwOweHLcP3aclWsfXi_5CzxoCAqb7tIChoQ.0SDz3dLFFgV0R5YkZiZmjsSQAD 6JnCAaor4hQEijS5vRKeVFN9rbb1BjM9tX_LCC2rt45T33dQcq4IM1vCJoef1fISoKuB27zd3Cbg xV7eYCn0k1_83ioxWhzFIdCC74rTTTSXKcO5It_2Hc1LkGTLnVGGrzT8haQXW8NEg83OinuK34VQ Vl4edS2eT1Eu8u.XNdZqSTiqs6Gtb6kg9Cbtv.x75jCLSURSQ6tgY_iZtq50Q3V5BiHD.8PGPefY jrGgyvvwmAJYC8aA.gSvcJSxq9B7bVT5xL3hwRfKJKB06q.ymLbpo8YOvmRaGSk6PcJu7rrTr0YB zpKCTmou34deFyX2uxpBc7UOpUJKB.OQ_MrVQThYR.SgtonBDDY1qZ8_RVksPMN5PPn2ymW3VzV_ z_iI6A_XsM74iJ2GYserUF8u5zxlqJG8txOfvS013JejGu1OawOkYrIpefsA4J00fAEGPup29t8Y _YXp017i4hVHUeWYk1st.ANStj.7m_sQssYufs4tRoHG10XOcKqkCKtpQ.BOkB4xrajkgkvfwIKh BAClxIayB1pzqElFXv65Vcf.MgrfZwyZnxzRMd0z_PpkvrY7ZbqHkOPL270uHzfwv_qTJJGPz0au IxiWxJYApWo1V0EhwHeo7t03UPT6mhUV0SmvmZx3nYu6fWk3NXSoHxyquZuLkRjt0MGh.q6aG68Y eUyQHgPKdUykXIwxIOE9Lv6Dwkid9mDOAc8aCUlhn22E- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Feb 2022 21:32:29 +0000 Received: by kubenode513.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2026682897702a4b34e84159cbb72ff1; Sat, 12 Feb 2022 21:32:25 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <20220212185618.GA37391@www.zefox.net> Date: Sat, 12 Feb 2022 13:32:25 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jx3c440vWz3q17 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="eWYaSi2/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5652 Lines: 133 On 2022-Feb-12, at 10:56, bob prohaska wrote: > For a few weeks now a Pi3 running -current will not respond to > an incoming ssh connection unless an outbound ping process is = running. >=20 > Once the outbound ping is started via the serial console, incoming > ssh connections are answered normally. Uname -a reports > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #10 = main-n253073-6db44b0158c: Sat Feb 12 04:30:21 PST 2022 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >=20 > A Pi4 running -current of a few days ago exhibits no such problems. >=20 > Another Pi3 running stable/13 has been behaving in the same way. >=20 > Both Pi3s successfully set time via ntp on reboot and will > very briefly (one or two minutes) prompt for an ssh password, > but no further progress is made and the login attempt times out. > If the ssh login is attempted a second time, not even a password > prompt comes back. >=20 > Ping times (to an adjacent machine on the same subnet are > 64 bytes from 50.1.20.26: icmp_seq=3D2 ttl=3D64 time=3D0.978 ms > 64 bytes from 50.1.20.26: icmp_seq=3D3 ttl=3D64 time=3D0.967 ms > 64 bytes from 50.1.20.26: icmp_seq=3D4 ttl=3D64 time=3D1.088 ms > 64 bytes from 50.1.20.26: icmp_seq=3D5 ttl=3D64 time=3D0.983 ms > 64 bytes from 50.1.20.26: icmp_seq=3D6 ttl=3D64 time=3D1.007 ms > 64 bytes from 50.1.20.26: icmp_seq=3D7 ttl=3D64 time=3D1.075 ms > 64 bytes from 50.1.20.26: icmp_seq=3D8 ttl=3D64 time=3D1.020 ms > 64 bytes from 50.1.20.26: icmp_seq=3D9 ttl=3D64 time=3D1.044 ms > 64 bytes from 50.1.20.26: icmp_seq=3D10 ttl=3D64 time=3D1.026 ms > 64 bytes from 50.1.20.26: icmp_seq=3D11 ttl=3D64 time=3D0.908 ms >=20 > That might be considered slow, but the correspondent machine > is only a Pi2 running=20 > FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #3 = main-71d2d5adfe: Tue Dec 21 00:23:51 PST 2021 = bob@www.zefox.com:/usr/obj/usr/freebsd-src/arm.armv7/sys/GENERIC arm >=20 > If the outbound ping is started, an incoming ssh connection = established > and the outbound ping subsequently stopped the running ssh connection > silently freezes; no disconnect, but no response, not even echo. Some > tens of seconds later, all inputs were responded to. Tried a second = time, > the stoppage recurred, restarting the outbound ping eventually = restored > responsiveness. >=20 > With the outbound ping stopped, an inbound ssh attempt silently = failed: >=20 > bob@raspberrypi:~ $ ssh -vvv 50.1.20.28 > OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d 10 Sep 2019 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug2: resolve_canonicalize: hostname 50.1.20.28 is address > debug2: ssh_connect_direct > debug1: Connecting to 50.1.20.28 [50.1.20.28] port 22. > [enter key echoed] > debug1: connect to address 50.1.20.28 port 22: Connection timed out > ssh: connect to host 50.1.20.28 port 22: Connection timed out > bob@raspberrypi:~ $ =20 >=20 > Thanks for reading and any insights. If I've omitted useful=20 > details or tests please indicate. >=20 You have made multiple reports to the arm list for this issue without anyone having managed to help. This report does have more comparative context, which might help someone help. It may be time to try other lists like freebsd-net and, possibly, freebsd-hackers or freebsd-stable or freebsd-current . However, the best thing no matter where you go would be to (approximately) bisect toward the back-to-back FreeBSD version-pair on, say, stable/13 at which the the problem goes from not-there to happening. ( stable/13 changes slower and so has fewer versions to deal with. Also its KBI may grow but is constrained to otherwise be more stable [ relative to releng/13.0 ]. So you are less likely to run into version compatibility problems for the below suggestion.) I'd recommend using kernel and world materials from: https://artifact.ci.freebsd.org/snapshot/stable-13/?C=3DM&O=3DD on a separate microsd card updated from a normal context, avoiding builds. Remember that older stable/13 worlds can run on newer kernels generally. So you might only need to update the kernel after getting an initial, somewhat older context in place. (It is not obvious if it is a kernel-only problem or not.) If it is a kernel problem, you might be able to put down a releng/13.0 world and never change it during the approximate bisect activity. For what https://artifact.ci.freebsd.org/snapshot/ has available, this avoids having to build the versions. It also allows checking if your builds are behaving differently than the official snapshots do. https://artifact.ci.freebsd.org/snapshot/ may not be able to get you to the back-to-back FreeBSD version-pair: the range might be wider. Sometimes the wider range is enough by inspection of the types of commmits in the range. So I'd report whatever range you find wihtout having done any builds. I'll note that I have no problem with connecting via ssh to a RPi3B running my build of (line split for readability): # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #28 main-n252475-e76c0108990b-dirty: Sat Jan 15 23:39:27 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400047 1400047 I have no stable/13 context set up for a RPi3B, only stable/13's that have an untuned ZFS context. Still, I wonder if that might operate well enough to test the issue, despite the 1 GiByte of RAM limitation. I may test that later today. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 13 00:50:21 2022 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 9D3CD194B9CC for ; Sun, 13 Feb 2022 00:50:37 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jx80X3Ymmz4gfB for ; Sun, 13 Feb 2022 00:50:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644713428; bh=ZzU0lW+e3SDAMJ77Bfcj9fefML85XPlBc40hOFUYloU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jmCnRPmOlj/Q+cvovdTaDAQMD6yoDG8lBpy6TeP+7lHecciNmHBFCAjklrAU54U7jn8rQVvk2poJ7yfD6pUaavMlptg7fFA/xdirm4Isl9nQsVrdZ2K0tj8MD9S57utNdyzsxlPWN08sRI/R89JtAJ8T8DzJ75I5/hUrNaNQe+oXLWcdg113A3iRYQJ9SLdUCFeVPkOPhF7A2O/J/xqwN2jAZbzmmwsnELZf/4NZrfF+AJnGRNnkrMdHWeiBCmF+IRkxDLVhPiR2xinZk7Ur1BKd0vrefn+JFI5wDqBAXI4ib9MH6KO0vJxrcbkDLmj4a7Kx/KyINSfz/vXwUdgo6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644713428; bh=b0GJ2rSE+Qy0lgg5v9pP12qDQRZgLJU4dUk/z9K86ng=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dx1X66dMhE2oJG2QgHsuFRl8K3HqUxn97Tci9Oft4ePP+k8n2+LDKKU7YNv2AnnVo548Ixt+zTTsuJTMoa60UvYaBeyZEroiqHE6mm9BNiELJqB3gw/aStrF1iTCbHeBB8XOgae8XmdVZfcwWo1JMvG2Kk/Htc2QlYWYQGa6xtFtRFSWTg7MWrZl3o4qBHLVvix//BAaoWMWVh34WXuv2n2a8rbHw+lGa6HNXKZCh8oQPuR0BBlmqK+AJ5Ulfh+G8CVQQ0kaXuoP8RKG8YkJU47UfLI5H/yxg8bIgQMz4i0J3/5SSl6DI8mNPdaIGzLEUCiX3Al771dpwXoBrF/niw== X-YMail-OSG: Oo4QfHAVM1nKmsrms9fwglMzzRPMUWbP1gH78on4j.D5vIeqgiYO81BZ3H0oTBg gSgKcXl9B7wUYLIMcj2P6Grj8Ep0E0JfPMk6fFo.0EV7kU9um1WX1QdtMGB_XN1.Xn35evq0Hgn0 ORXKCbqSnew6nPnpxgCxVcGTUbalxL7tVU_g3fgeAvCkGVhEwVwWqCPIYFCRuFAoX3vZuL0x_Zn3 XFh4.gMwRkC0FcEL2g_hNDRxGscKt2lSjDholN_iKpq7m90UN31SHVVEJlQ5gZEfbZYwofNrZO9y mu6uQZa4A0T7_SGaUsTzmBki1Wz6r_oh7s2aIK9.N2h7thCWuIDjsYeC8IFklLWhbU6VfWCW5sQB y9RZZT8i3YgWbdoC7tfQL80hwsU3mokkIxqsBzcHMG4FK5cPMGXOdxuwDhLRzDofuSdFOmts.OXk KbTotgcCjFEwSyJYqNCTl1HeNjIWg7sBxkhrJ0N4OsR_T2DchMJbGTvFddUSUUXY.Hra7k2tNqsU sX5yoVHfNav_liyhvy3PrpJZc8sBwF813EvROq3_stlK0tbemupqyINyx1JtLmtsaMrAnrAQ5QEM Ode_c.ol.rJIrtuIo6QuumS3IFeZUJV3U.mRp01.XY4PJ9v1DRvaMxydBzv3S_UeKy9ihFx_tIPG Uf25WKxQBYYfwRiC0nftmO8Z53XvKSIim67EH61wYem1p66x6cO.q7TOg92TFFZXjqEitNGDJnLR nq_tcghNTfb5GCTzVEUJgnf1jBJ.UgLb_pgkB8pPdYo3mfFS6e3pp5DzOkZpdPWlO7xPAzOIHVrb wSvSdPjzQ_h53t.J4iSUDAkmLovL8X5eO4E3uQem_GxNiOnnNTtjpEuqjTerBUfrKZvOXLOCNhFg l2e3QzzXA4ITOLKmcmGiL1FiQreD1tpsZ020QnQGzes3u5Q5_wYj0A0gpQWX4X2l_VclCUVjuZS5 g0LSiQIsk74nKvI1hUm6RUoNgBUqYG5iC16_HO5TYeVY5n2cSMyEjZ8MdZc.Q3LGdj0xJYAQPnie Rw7fJsFTV7C7xsK_DpMPTamBuK3j2Gb_jvSXaRV7Z9DJT_63ceDncZMxZJsjkO2wJPEEQUGOP_2o YWFlAx5.0ccseOsGDIp8UTp_f_zYBkgANGxd8lXi3VGXHxF7ZdS0m2J2ftZQGiI98xdPjSG0Ob4p FICIa6cVz3aVZgA6IV6duAuOw8UD.zOtHEgEaCRcXVzdxLNy4nx7WrnSh0sn3pyOyw1lzgbVYfq1 ha8sTcXO3cV1FCvoUQu70D8uinKD.NJ6974usZQE_OmMhARl_zSiACxifsh0EQJ34iY1cdJBVTfs IIyzXM1.wJ6NVKE0OSgaf3IfsUpOQy34DOKZ5Mht01scNLfAIg_GgGqMuqriK4HVBOGvVxy8p4EM eTIiKWsvYFnLk_l2x3gDAOZWORzN0Wqq.boE3LBv_9.Kf0Vjm66vWLuZ3ok3LtCbesSPRLAFFwPr u_umEEBpaxqgxbpdp81_1LWo7OtI.ivbXqpH1bFa0hgEaTrJhNiAQ.Y8yVn7vFpyrEbiowLRPJrl I.tIcyf3OsV8GbOmnqEhXRSMq.Rw4KG6q.ztSQkK4P7462QcRCafOwInUrHwUYYlybfXmIx3Uuba bJif2Q2GgoTpzJIFS9CyKnG69HgisKmzEr3EC83gb7H1WHm4_q8_1ugA_szzp7bm0ekS7SY1wOWP WHTpuC8mQGa3pSUwKNLN4oHMVudbiyYg9d5TgFYfK3MEKbi295CZ_4xPOBzg6BM07KFSZS.aN.Lb 9.9jBC0nfwVYmVxRG8FWO7ZKE8RQqTYrDONz.KC_WkOKGS9oqSBOQ2zqNEYQZH3otHduOydA00OU tTb90te6OsyIF0tUaAH7k34x1Z08es60lA5t_ckJAPAXrL264vNPqD0hlq8nAYQcCxc9lRt4dVJ0 9sMPpC65A0pAUqqLiyWTsxGH8PKD0aBi0xSixlfXzk.pICbKweWz_V4rcPvIJbhkmwnaGGeZMvyu fk7Eui_AVrOHdWXDos27_BVvaD40fgfd3W63R2IRULz2KsEMIKoVhB8Wx5qjwAEYzLapruWOUajJ PU4bgKldsIpX2imVVOEKVOHGb8lFm5engl9tNCoj0XuEONTifsWsY0h.gmt4LgJ2XTpFFExdlfMh r.Tu4oObGFO_aACa1ljiycPT8DOx4aN7AZtVI0OlLcJ4PHMCOmMIMDwnM3kjC8aLhNkN287Ue2.o INfcxj7ZFKO72DB2YTCQ.FU.dImggOtE_8QI.Nht0AiOj0Jp1mzNin6QKPxxoc9fT0BkTBbY0ggb bsTQfUgSl6Pfi5mRNfiW7vqfk0oMSWQAXquOhYhVgHAevkQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Feb 2022 00:50:28 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 610d5e8c6eb6651d1b47202bc370ae40; Sun, 13 Feb 2022 00:50:23 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> Date: Sat, 12 Feb 2022 16:50:21 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jx80X3Ymmz4gfB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jmCnRPmO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10702 Lines: 271 On 2022-Feb-12, at 13:32, Mark Millard wrote: > On 2022-Feb-12, at 10:56, bob prohaska wrote: >=20 >> For a few weeks now a Pi3 running -current will not respond to >> an incoming ssh connection unless an outbound ping process is = running. >>=20 >> Once the outbound ping is started via the serial console, incoming >> ssh connections are answered normally. Uname -a reports >> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #10 = main-n253073-6db44b0158c: Sat Feb 12 04:30:21 PST 2022 = bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >>=20 >> A Pi4 running -current of a few days ago exhibits no such problems. >>=20 >> Another Pi3 running stable/13 has been behaving in the same way. >>=20 >> Both Pi3s successfully set time via ntp on reboot and will >> very briefly (one or two minutes) prompt for an ssh password, >> but no further progress is made and the login attempt times out. >> If the ssh login is attempted a second time, not even a password >> prompt comes back. >>=20 >> Ping times (to an adjacent machine on the same subnet are >> 64 bytes from 50.1.20.26: icmp_seq=3D2 ttl=3D64 time=3D0.978 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D3 ttl=3D64 time=3D0.967 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D4 ttl=3D64 time=3D1.088 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D5 ttl=3D64 time=3D0.983 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D6 ttl=3D64 time=3D1.007 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D7 ttl=3D64 time=3D1.075 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D8 ttl=3D64 time=3D1.020 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D9 ttl=3D64 time=3D1.044 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D10 ttl=3D64 time=3D1.026 ms >> 64 bytes from 50.1.20.26: icmp_seq=3D11 ttl=3D64 time=3D0.908 ms >>=20 >> That might be considered slow, but the correspondent machine >> is only a Pi2 running=20 >> FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #3 = main-71d2d5adfe: Tue Dec 21 00:23:51 PST 2021 = bob@www.zefox.com:/usr/obj/usr/freebsd-src/arm.armv7/sys/GENERIC arm >>=20 >> If the outbound ping is started, an incoming ssh connection = established >> and the outbound ping subsequently stopped the running ssh connection >> silently freezes; no disconnect, but no response, not even echo. Some >> tens of seconds later, all inputs were responded to. Tried a second = time, >> the stoppage recurred, restarting the outbound ping eventually = restored >> responsiveness. >>=20 >> With the outbound ping stopped, an inbound ssh attempt silently = failed: >>=20 >> bob@raspberrypi:~ $ ssh -vvv 50.1.20.28 >> OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d 10 Sep 2019 >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: /etc/ssh/ssh_config line 19: Applying options for * >> debug2: resolve_canonicalize: hostname 50.1.20.28 is address >> debug2: ssh_connect_direct >> debug1: Connecting to 50.1.20.28 [50.1.20.28] port 22. >> [enter key echoed] >> debug1: connect to address 50.1.20.28 port 22: Connection timed out >> ssh: connect to host 50.1.20.28 port 22: Connection timed out >> bob@raspberrypi:~ $ =20 >>=20 >> Thanks for reading and any insights. If I've omitted useful=20 >> details or tests please indicate. >>=20 >=20 > You have made multiple reports to the arm list for this issue > without anyone having managed to help. This report does have > more comparative context, which might help someone help. >=20 > It may be time to try other lists like freebsd-net and, > possibly, freebsd-hackers or freebsd-stable or > freebsd-current . >=20 > However, the best thing no matter where you go would be > to (approximately) bisect toward the back-to-back FreeBSD > version-pair on, say, stable/13 at which the the problem > goes from not-there to happening. ( stable/13 changes > slower and so has fewer versions to deal with. Also its > KBI may grow but is constrained to otherwise be more > stable [ relative to releng/13.0 ]. So you are less > likely to run into version compatibility problems > for the below suggestion.) >=20 > I'd recommend using kernel and world materials from: >=20 > https://artifact.ci.freebsd.org/snapshot/stable-13/?C=3DM&O=3DD >=20 > on a separate microsd card updated from a normal context, > avoiding builds. Remember that older stable/13 worlds can > run on newer kernels generally. So you might only need to > update the kernel after getting an initial, somewhat older > context in place. (It is not obvious if it is a kernel-only > problem or not.) If it is a kernel problem, you might be > able to put down a releng/13.0 world and never change it > during the approximate bisect activity. >=20 > For what https://artifact.ci.freebsd.org/snapshot/ has > available, this avoids having to build the versions. > It also allows checking if your builds are behaving > differently than the official snapshots do. >=20 > https://artifact.ci.freebsd.org/snapshot/ may not be able > to get you to the back-to-back FreeBSD version-pair: the > range might be wider. Sometimes the wider range is enough > by inspection of the types of commmits in the range. So > I'd report whatever range you find wihtout having done > any builds. >=20 > I'll note that I have no problem with connecting via ssh > to a RPi3B running my build of (line split for readability): >=20 > # uname -apKU > FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #28 > main-n252475-e76c0108990b-dirty: Sat Jan 15 23:39:27 PST 2022 > = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 > arm64 aarch64 1400047 1400047 >=20 > I have no stable/13 context set up for a RPi3B, only > stable/13's that have an untuned ZFS context. Still, > I wonder if that might operate well enough to test > the issue, despite the 1 GiByte of RAM limitation. I > may test that later today. Other than needing to put in place my u-boot.bin build that has usb_pgood_delay=3D2000 built-in, I had no trouble with booting and ssh'ing in to (line split for readability): # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #25 stable/13-n249004-a5f698599560-dirty: Sun Jan 16 15:07:11 PST 2022 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300524 1300524 # ~/fbsd-based-on-what-commit.sh -C /usr/13S-src/ branch: stable/13 merge-base: a5f69859956049b5153b0e1b67f8f4a99622dc6f merge-base: CommitDate: 2022-01-15 12:55:32 +0000 a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore = debugger-injected signals left after detaching n249004 (--first-parent --count for merge-base) SIDE NOTE After the above, my patched top reports: Mem: 32504Ki Active, 214888Ki Inact, 393248Ki Wired, 40960B Buf, = 321468Ki Free, 75516Ki MaxObsActive, 394108Ki MaxObsWired, 469624Ki = MaxObs(Act+Wir+Lndry) ARC: 316408Ki Total, 201575Ki MFU, 111090Ki MRU, 143360B Anon, 1024Ki = Header, 2551Ki Other 259140Ki Compressed, 346379Ki Uncompressed, 1.34:1 Ratio Swap: 3584Mi Total, 3584Mi Free, 75516Ki MaxObs(Act+Lndry+SwapUsed), = 469624Ki MaxObs(Act+Wir+Lndry+SwapUsed) So it is not an environment I'd want to do buildworld buildkernel on. But it looks to be usable for less memory intensive activities. END SIDE NOTE So I've looked and found (from today): = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz and downloaded it. Then I decided to try it with my normal boot media, leaving world as it is. So: # ls -Tld /boot/ker* drwxr-xr-x 2 root wheel 680 Jan 16 16:49:24 2022 /boot/kernel drwxr-xr-x 2 root wheel 680 Jan 4 23:08:57 2022 /boot/kernel.old # mv /boot/kernel /boot/kernorm # tar -xpf kernel.txz -C / # ls -Tld /boot/ker* drwxr-xr-x 2 root wheel 679 Feb 12 11:14:27 2022 /boot/kernel drwxr-xr-x 2 root wheel 680 Jan 4 23:08:57 2022 /boot/kernel.old drwxr-xr-x 2 root wheel 680 Jan 16 16:49:24 2022 /boot/kernorm (I choose to not replace the system's debug information --that is not stored under /boot/ but in with world files. So I did not download or install kernel-dbg.txz .) So now a reboot with loader defaults (for that boot environment in my context) will use the kernel that I got from: https://artifact.ci.freebsd.org/snapshot/stable-13/. . . [Hmm. Looks like the u-boot.bin is not sufficient to be sure that shutdown -r now will boot the RPi3B. =46rom power-on seems to boot so far. I might need another built-in setting added (or more) in order to allow the RPi3B to shutdown -r now well for the USB3 NVMe based SSD media that I'm using.] Still no trouble connecting and logging-in via ssh. For reference (line split for readability): # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #0 371633e: Sat Feb 12 19:06:49 UTC 2022 = root@FreeBSD-stable-13-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/= arm64.aarch64/sys/GENERIC arm64 aarch64 1300525 1300524 (I do not have matching source at this point.) Recommended experiment . . . Since I have a context working based on the kernel in: = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz I recommend that you try that exact same kernel in your stable/13 context. I recommend renaming the existing /boot/kernel before expanding the kernel.txz into / and so causing a new /boot/kernel/ to be filled in. If that makes things work after rebooting, then your kernel can be blamed. (More investigation to know more about what is going on in your kernel build.) But if the above does not make things work, that points to investigating alternate worlds from: https://artifact.ci.freebsd.org/snapshot/stable-13/. . . That is a messier context. I only do that with media that I can delete everything on, such as an independent microsd card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various tar -xpf ???.txz -C /mnt/ commands --while not booted from the microsd card. Repeat for each snapshot tried. There is a bias to the world not being newer than the kernel. But since stable/13 's 371633ece3ae seems to work in my context, you might be able to hold the kernel invariant and just try different world versions in this messier context. Also: You might be be to find: https://artifact.ci.freebsd.org/snapshot/stable-13/. . . materials for the specific builds that you have been working with and do comparison/contrast with the behavior of your builds that had issues. Note: The above does not consider other networking configuration issues --that might not even be on RPi* devices. I'm not networking literate overall. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 13 21:00:40 2022 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 2EAB719B3347 for ; Sun, 13 Feb 2022 21:00:41 +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 4Jxfrm4bV2z3JSB for ; Sun, 13 Feb 2022 21:00:40 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 513192229A for ; Sun, 13 Feb 2022 21:00:40 +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 21DL0eS3049036 for ; Sun, 13 Feb 2022 21:00:40 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21DL0eq4049035 for freebsd-arm@FreeBSD.org; Sun, 13 Feb 2022 21:00:40 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202202132100.21DL0eq4049035@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 Feb 2022 21:00:40 +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="16447860401.949ABb.47454" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644786040; 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=j8ghep57WFStOwp/CUoFCEgknv0XEtaLd7c/X3qtFtU=; b=UWOkeDoOuYeNG+IbNqp+Ol51HAv8Qtr43ivaP8CZlqh5NCRKtdA+HIyuiiv11WLFTxkfKJ Qsx+k+RwdHjhvILQt/+y8NRPVc2rSap0fI8guvWP7cFQOYkS36Na6QP3KsF2lfF3J7b/br r+GWHdBdcRiU6Dm5wq8hmIUkXtaMDnwLb1lDqceZWIwbHy5um2L6CFpi0cgyTxzOVQm3Nt lXswo6nkHq5soz7jlW8aGhv8gqLG/yEaiKl6AfnP0Gk6jEp+QB8ulwepOMRP5Ho2Vl7Od5 0X8yGXu8J7TA5eGaL0BSXmd1jox6fsnqCBiGQwq3IYsUOg67yBa+xepMEStDUg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644786040; a=rsa-sha256; cv=none; b=Ug0DrxjJIusjL+b9f48x9hEkZzqjBWZQOhImtKk1ncltW41rgz3o6UsAgmq9D/4vCIlrvx GDk3fzw0fi6rATfSlIjnoiWGjAXYBzkXH2Nbl+td4LYt7y81Ciubc6QShRT9ILDEVmLdYG ZptmliaQZwGTkGa4bPUUTYh89l/rl+/ltYdp8oVGTvDjUPQtw+amkIuwJNbmsq3gAiC38v RU8rKg5bMTQaUQB1y9nb6cnsEYNNr5nUiRXeFuSLTLZbpq010AcErPJyYK9YS2fh+trCjj F1FOuC9hNYxIxjI53nYVgvs4A882aipR/WRfaur25ycpYpkNKGgzjqX0BxLUdQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1801 Lines: 38 --16447860401.949ABb.47454 Date: Sun, 13 Feb 2022 21:00:40 +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. --16447860401.949ABb.47454 Date: Sun, 13 Feb 2022 21:00:40 +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.
--16447860401.949ABb.47454-- From nobody Sun Feb 13 21:51:55 2022 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 B7E4A19BFCCB for ; Sun, 13 Feb 2022 21:52:07 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jxh066P4Bz3ltK for ; Sun, 13 Feb 2022 21:52:06 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [10.0.1.27] (hs-nc-6b363c0412-470382-1.tingfiber.com [64.99.197.86]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id 21DLq0tg073752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 13 Feb 2022 21:52:06 GMT (envelope-from swills@FreeBSD.org) Message-ID: Date: Sun, 13 Feb 2022 16:51:55 -0500 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: Steve Wills Subject: RockPro64 snapshot boot failure Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 13 Feb 2022 21:52:06 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=KHOP_HELO_FCRDNS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4Jxh066P4Bz3ltK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:fc50:0:4400:216:3eff:fe69:33b3 is neither permitted nor denied by domain of swills@FreeBSD.org) smtp.mailfrom=swills@FreeBSD.org X-Spamd-Result: default: False [-2.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; FREEFALL_USER(0.00)[swills]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.87)[-0.873]; DMARC_NA(0.00)[FreeBSD.org]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1182 Lines: 29 Hi, I recently got a RockPro64 board and have tried to boot it using these snapshots: https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-ROCKPRO64-20220210-8dc42f98047-253065.img.xz https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-ROCKPRO64-20220127-2c449a4c5a3-252673.img.xz https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-ROCKPRO64-20220127-2c449a4c5a3-252673.img.xz to try to boot it. All fail with: Mounting from ufs:/dev/ufs/rootfs failed with error 19 I'm currently awaiting delivery of a USB serial adapter which supports the boards default 1.5Mbaud serial speed, so right now I'm using it directly via HDMI to a monitor with USB keyboard. I was worried it might have gotten damaged due to having been dropped once, so I tested booting and installing another OS on it without issue. If anyone has advice or pointers or can confirm if this snapshot works or point to one they know works, that would be helpful and appreciated. In the mean time I will try building an image myself. Thanks, Steve From nobody Sun Feb 13 22:48:02 2022 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 9258719CB63A for ; Sun, 13 Feb 2022 22:48:14 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JxjDs6mCSz3vvV for ; Sun, 13 Feb 2022 22:48:13 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [10.0.1.27] (hs-nc-6b363c0412-470382-1.tingfiber.com [64.99.197.86]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id 21DMm76V078414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 13 Feb 2022 22:48:13 GMT (envelope-from swills@FreeBSD.org) Message-ID: <0e326860-efdb-7678-a0fa-0060221663bd@FreeBSD.org> Date: Sun, 13 Feb 2022 17:48:02 -0500 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: RockPro64 snapshot boot failure Content-Language: en-US To: freebsd-arm@freebsd.org References: From: Steve Wills In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 13 Feb 2022 22:48:13 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=KHOP_HELO_FCRDNS,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4JxjDs6mCSz3vvV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:fc50:0:4400:216:3eff:fe69:33b3 is neither permitted nor denied by domain of swills@FreeBSD.org) smtp.mailfrom=swills@FreeBSD.org X-Spamd-Result: default: False [-3.09 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[swills]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 154 Lines: 10 Hi, Of course, since I tasked, it turned out to be the SD card. It seems it likes one SD card but not the other. Sorry for the noise. Cheers, Steve From nobody Mon Feb 14 12:40:56 2022 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 A554419C10E2 for ; Mon, 14 Feb 2022 12:41:24 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4Jy3kC4pBTz4trC for ; Mon, 14 Feb 2022 12:41:23 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id f17so26859743edd.2 for ; Mon, 14 Feb 2022 04:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e7G4JOp0wK3eosRuoeydSoj80so5j35B7D4uG1uXV08=; b=CbYoFM4038U3PnE/O8ZJ4n5rHfAcaI8ZLWWYhgnx4y0E09++jP/nEb0VcqGPHP1ODz ctYMbkFsPNdQFvjChu1o3l/6c+VE/ttiLwNUlkJRGvImmsCdP2drenAXrOo9AWpSoFx4 DcI26sLE1i4vZ+XyZDdfZP9AzxrxjhvfzZleK+CEBbJJjbiLcx05jjHDAnhlQ0t3sam6 avxd+rCQGuUrIsP3cjoFZN4cSrRrqOGbyOVz20tvFMcYYdmKLH2k5cq9dukX66qiX17s iQhlzdTDlzmufUAfuQVV1j6ZNpDEp+hUU7PLa78GhbH1oKxwVof1VbbuYWlB6D/rwc2K WwpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e7G4JOp0wK3eosRuoeydSoj80so5j35B7D4uG1uXV08=; b=SBTXbnaSJ4UsXsozKMPoZjmefIV8yndZIcUq3+6b6Xcq78qDUEefcmN6wEVrinhQWN zV7/tCvJpcAW/uXJX6OCN/TKuMafaukbCo+SdgzG5/mq2A2PACMrTT2J9K4c/rl41oUU hPRlanzArixhj7M5woh0+buxZsO3d5dis6yGGM8xrKkYnb6ijs7BWbQr1zcmuVb5YjlJ qKGOpiw2I5YRniPwiSeOVAE5EIxPBpFfpqR+2skgXyxOfIqlAK2sLGhu61B57zbo47zI z33/0//lAfhET+1+IX10tShA1w6bmabF0Qzxk6PH2cKIM/NUOsCIqgIhCVny4Gf2sxHg sOiA== X-Gm-Message-State: AOAM533vfU3tcFQ33MhYofUSCpfNurl0t6Sn2NxVu/8JuEw23E6FGNN6 p2dDcTgl6kh+5doUBneNPijwQynECgKPo8s4sDNklwdb1Z8= X-Google-Smtp-Source: ABdhPJxCZAefEjF3JlyGxrcH+zcmHLEjCzBBhjSw6LaTLpiGBiywIT8gtPZgm+swtUD+5KHgZbX1whMF0LOzsjXvn38= X-Received: by 2002:a05:6402:368e:: with SMTP id ej14mr15424843edb.279.1644842476084; Mon, 14 Feb 2022 04:41:16 -0800 (PST) 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: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: From: Archimedes Gaviola Date: Mon, 14 Feb 2022 20:40:56 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: "Daniel O'Connor" Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="0000000000008012d005d7f9bbc4" X-Rspamd-Queue-Id: 4Jy3kC4pBTz4trC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CbYoFM40; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-1.84 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.938]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+,5:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DBL_PROHIBIT(0.00)[0.0.0.0:email]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 61889 Lines: 888 --0000000000008012d005d7f9bbc4 Content-Type: multipart/alternative; boundary="0000000000008012cd05d7f9bbc2" --0000000000008012cd05d7f9bbc2 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola < archimedes.gaviola@gmail.com> wrote: > > > On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor > wrote: > >> >> >> > On 24 Dec 2021, at 02:25, Archimedes Gaviola < >> archimedes.gaviola@gmail.com> wrote: >> > Are you using the boot files that came with 13.0 (dtb, etc)? >> > >> > Yes, I am. I have not changed anything that came from 13.0 files, it's >> all intact since I wrote the image to the microSD card. >> > >> > To be specific with my USB devices, this is an input and an output >> device. I have an RFID card reader and an Epson TM-U22B USB printer >> (self-powered) which are detected and work well with USB 2.0. Below dmesg >> log shows the drivers of my printer and RFID card reader. As soon as these >> devices are transferred to the blue-colored USB 3.0 ports these drivers >> will no longer show up in the dmesg. >> > >> > ugen0.3: at usbus0 >> > ugen0.4: at >> usbus0 >> > ukbd0 on uhub1 >> > ukbd0: on usbus0 >> > kbd1 at ukbd0 >> > uhid0 on uhub1 >> > uhid0: on usbus0 >> >> For what it's worth I have successfully used USB devices on the USB3 >> ports with FreeBSD 13 on an RPi4: >> ugen0.1: <0x1106 XHCI root HUB> at usbus0 >> ... >> uhub0 on usbus0 >> uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 >> ... >> uhub1 on uhub0 >> uhub1: on >> usbus0 >> uhub1: 4 ports with 4 removable, self powered >> ugen0.3: at usbus0 >> ugen0.4: at usbus0 >> ukbd0 on uhub1 >> ukbd0: on >> usbus0 >> kbd1 at ukbd0 >> >> I have also used a custom Cypress FX2 based board on it with no problems. >> >> -- >> Daniel O'Connor >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> > > Thanks Daniel for sharing your experience with your RPi4! My next step > will be to secure another board (with the same specs) and check if it > behaves the same. I'll burn another 13.0 image to further verify just in > case it still fail. > Hi, I just tried my new RPI4 board and it seems to work fine the same as my old board. I just observed that the problem is when my VFD (vacuum fluorescent display) device is connected to either of the two USB 3.0 ports, this device having uplcom(4) driver is not detected. It's a Prolific USB-serial device having PL2303 chipset. However, when plugged-in to USB 2.0 ports, this device is detected and functioning. I can send characters with the echo command and redirect it to /dev/cuaU0 for display without any problem. Other observations when this VFD device is connected to either 3.0 ports, the 2.0 ports will not function i.e. plugging-in any USB devices like my keyboard or my EMV reader. When this device is also connected to either of the 2.0 ports, the other 2.0 port is functioning for other USB devices while 3.0 ports are not. I attached two dmesg outputs when the device is detected with 2.0 ports and undetected with 3.0. I also include kldstat and usbdump. --0000000000008012cd05d7f9bbc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 24, 2021 at 12:32 PM Arch= imedes Gaviola <archimed= es.gaviola@gmail.com> wrote:


On Fri, Dec 24, 2= 021 at 10:49 AM Daniel O'Connor <darius@dons.net.au> wrote:


> On 24 Dec 2021, at 02:25, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
> Are you using the boot files that came with 13.0 (dtb, etc)?
>
> Yes, I am. I have not changed anything that came from 13.0 files, it&#= 39;s all intact since I wrote the image to the microSD card.
>
> To be specific with my USB devices, this is an input and an output dev= ice. I have an RFID card reader and an Epson TM-U22B USB printer (self-powe= red) which are detected and work well with USB 2.0. Below dmesg log shows t= he drivers of my printer and RFID card reader. As soon as these devices are= transferred to the blue-colored USB 3.0 ports these drivers will no longer= show up in the dmesg.
>
> ugen0.3: <EPSON EPSON UB-U03II> at usbus0
> ugen0.4: <Sycreader RFID Technology Co., Ltd SYC IDIC USB Reader>= ; at usbus0
> ukbd0 on uhub1
> ukbd0: <USB Standard Keyboard> on usbus0
> kbd1 at ukbd0
> uhid0 on uhub1
> uhid0: <USB Vender Hid> on usbus0

For what it's worth I have successfully used USB devices on the USB3 po= rts with FreeBSD 13 on an RPi4:
ugen0.1: <0x1106 XHCI root HUB> at usbus0
...
uhub0 on usbus0
uhub0: <0x1106 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on us= bus0
...
uhub1 on uhub0
uhub1: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> o= n usbus0
uhub1: 4 ports with 4 removable, self powered
ugen0.3: <PixArt Microsoft USB Optical Mouse> at usbus0
ugen0.4: <BTC USB Multimedia Keyboard> at usbus0
ukbd0 on uhub1
ukbd0: <BTC USB Multimedia Keyboard, class 0/0, rev 1.10/1.00, addr 3>= ; on usbus0
kbd1 at ukbd0

I have also used a custom Cypress FX2 based board on it with no problems.
--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
=C2=A0-- Andrew Tanenbaum


I just tried my new RPI4 board and it seems to work fine the= same as my old board. I just observed that the problem is when my VFD (vac= uum fluorescent display) device is connected to either of the two USB 3.0 p= orts, this device having uplcom(4) driver is not detected. It's a Proli= fic USB-serial device having PL2303 chipset. However, when plugged-in to US= B 2.0 ports, this device is detected and functioning. I can send characters= with the echo command and redirect it to /dev/cuaU0 for display without an= y problem. Other observations when this VFD device is connected to either 3= .0 ports, the 2.0 ports will not function i.e. plugging-in any USB devices = like my keyboard or my EMV reader. When this device is also connected to ei= ther of the 2.0 ports, the other 2.0 port is functioning for other USB devi= ces while 3.0 ports are not. I attached two dmesg outputs when the device i= s detected with 2.0 ports and undetected with 3.0. I also include kldstat a= nd usbdump.

--0000000000008012cd05d7f9bbc2-- --0000000000008012d005d7f9bbc4 Content-Type: text/plain; charset="US-ASCII"; name="freebsd13_rpi4b_uplcom0_usb2.0_detected.txt" Content-Disposition: attachment; filename="freebsd13_rpi4b_uplcom0_usb2.0_detected.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzmo7fno0 ZnJlZWJzZEBmYnNkMTM6fiAlIGRtZXNnDQotLS08PEJPT1Q+Pi0tLQ0KQ29weXJpZ2h0IChjKSAx OTkyLTIwMjEgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwg MTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBU aGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJl c2VydmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNE IEZvdW5kYXRpb24uDQpGcmVlQlNEIDEzLjAtUkVMRUFTRSAjMDogVHVlIEZlYiAgOCAwMzoyNTow NyBQU1QgMjAyMg0KICAgIHJvb3RAZmJzZDEzOi91c3Ivc3JjL3N5cy9hcm02NC9jb21waWxlL0dF TkVSSUMgYXJtNjQNCkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAxMS4wLjEgKGdpdEBnaXRodWIuY29t Omxsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZtb3JnLTExLjAuMS0wLWc0M2ZmNzVmMmMzZmUpDQpW VChlZmlmYik6IHJlc29sdXRpb24gNTkyeDQ0OA0KbW9kdWxlIGZpcm13YXJlIGFscmVhZHkgcHJl c2VudCENCnJlYWwgbWVtb3J5ICA9IDIwNjc1NDIwMTYgKDE5NzEgTUIpDQphdmFpbCBtZW1vcnkg PSAxOTk1MzQxODI0ICgxOTAyIE1CKQ0KU3RhcnRpbmcgQ1BVIDEgKDEpDQpTdGFydGluZyBDUFUg MiAoMikNClN0YXJ0aW5nIENQVSAzICgzKQ0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5 c3RlbSBEZXRlY3RlZDogNCBDUFVzDQpyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLg0KcmFuZG9t OiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UNCk1BUCAzOWYzODAwMCBtb2RlIDIg cGFnZXMgMQ0KTUFQIDM5ZjNjMDAwIG1vZGUgMiBwYWdlcyAzDQpNQVAgMzlmNDAwMDAgbW9kZSAy IHBhZ2VzIDQNCk1BUCAzYjM1MDAwMCBtb2RlIDIgcGFnZXMgMTYNCk1BUCBmZTEwMDAwMCBtb2Rl IDAgcGFnZXMgMQ0KV0FSTklORzogRGV2aWNlICJrYmQiIGlzIEdpYW50IGxvY2tlZCBhbmQgbWF5 IGJlIGRlbGV0ZWQgYmVmb3JlIEZyZWVCU0QgMTQuMC4NCmtiZDAgYXQga2JkbXV4MA0KV0FSTklO RzogRGV2aWNlICJvcGVuZmlybSIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBi ZWZvcmUgRnJlZUJTRCAxNC4wLg0Kb2Z3YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNlIFRyZWU+ DQpzaW1wbGVidXMwOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1 czANCm9md19jbGtidXMwOiA8T0ZXIGNsb2NrcyBidXM+IG9uIG9md2J1czANCmNsa19maXhlZDA6 IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czANCmNsa19maXhlZDE6IDxGaXhlZCBjbG9jaz4g b24gb2Z3X2Nsa2J1czANCmNsa19maXhlZDI6IDxGaXhlZCBjbG9jaz4gb24gb2Z3YnVzMA0KY2xr X2ZpeGVkMzogPEZpeGVkIGNsb2NrPiBvbiBvZndidXMwDQpzaW1wbGVidXMxOiA8RmxhdHRlbmVk IGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1czANCnNpbXBsZWJ1czI6IDxGbGF0dGVu ZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3YnVzMA0KcmVnZml4MDogPEZpeGVkIFJl Z3VsYXRvcj4gb24gb2Z3YnVzMA0KcmVnZml4MTogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVz MA0KcmVnZml4MjogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVzMA0Kc2ltcGxlYnVzMzogPEZs YXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwDQpzaW1wbGVfbWZkMDog PFNpbXBsZSBNRkQgKE11bHRpLUZ1bmN0aW9ucyBEZXZpY2UpPiBtZW0gMHg3ZDVkMjAwMC0weDdk NWQyZWZmIG9uIHNpbXBsZWJ1czANCmJjbTI4MzVfZmlybXdhcmUwOiA8QkNNMjgzNSBGaXJtd2Fy ZT4gb24gc2ltcGxlYnVzMA0Kb2Z3X2Nsa2J1czE6IDxPRlcgY2xvY2tzIGJ1cz4gb24gYmNtMjgz NV9maXJtd2FyZTANCnBzY2kwOiA8QVJNIFBvd2VyIFN0YXRlIENvLW9yZGluYXRpb24gSW50ZXJm YWNlIERyaXZlcj4gb24gb2Z3YnVzMA0KZ2ljMDogPEFSTSBHZW5lcmljIEludGVycnVwdCBDb250 cm9sbGVyPiBtZW0gMHg0MDA0MTAwMC0weDQwMDQxZmZmLDB4NDAwNDIwMDAtMHg0MDA0M2ZmZiww eDQwMDQ0MDAwLTB4NDAwNDVmZmYsMHg0MDA0NjAwMC0weDQwMDQ3ZmZmIGlycSAzMCBvbiBzaW1w bGVidXMwDQpnaWMwOiBwbiAweDIsIGFyY2ggMHgyLCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQz YiBpcnFzIDI1Ng0KZ3BpbzA6IDxCQ00yNzA4LzI4MzUgR1BJTyBjb250cm9sbGVyPiBtZW0gMHg3 ZTIwMDAwMC0weDdlMjAwMGIzIGlycSAxNCwxNSBvbiBzaW1wbGVidXMwDQpncGlvYnVzMDogPE9G VyBHUElPIGJ1cz4gb24gZ3BpbzANCmdwaW8xOiA8UmFzcGJlcnJ5IFBpIEZpcm13YXJlIEdQSU8g Y29udHJvbGxlcj4gb24gYmNtMjgzNV9maXJtd2FyZTANCmdwaW9idXMxOiA8R1BJTyBidXM+IG9u IGdwaW8xDQpyZWdmaXgwOiBDYW5ub3Qgc2V0IEdQSU8gcGluOiA2DQpSRUdOT0RFX0lOSVQgZmFp bGVkOiA2DQpyZWdmaXgwOiBDYW5ub3QgcmVnaXN0ZXIgcmVndWxhdG9yLg0KbWJveDA6IDxCQ00y ODM1IFZpZGVvQ29yZSBNYWlsYm94PiBtZW0gMHg3ZTAwYjg4MC0weDdlMDBiOGJmIGlycSAxMyBv biBzaW1wbGVidXMwDQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+ IG9uIG9md2J1czANCmdlbmVyaWNfdGltZXIwOiA8QVJNdjggR2VuZXJpYyBUaW1lcj4gaXJxIDQs NSw2LDcgb24gb2Z3YnVzMA0KVGltZWNvdW50ZXIgIkFSTSBNUENvcmUgVGltZWNvdW50ZXIiIGZy ZXF1ZW5jeSA1NDAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCkV2ZW50IHRpbWVyICJBUk0gTVBDb3Jl IEV2ZW50dGltZXIiIGZyZXF1ZW5jeSA1NDAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCnVzYl9ub3Bf eGNlaXYwOiA8VVNCIE5PUCBQSFk+IG9uIG9md2J1czANCmdwaW9jMDogPEdQSU8gY29udHJvbGxl cj4gb24gZ3BpbzANCnVhcnQwOiA8UHJpbWVDZWxsIFVBUlQgKFBMMDExKT4gbWVtIDB4N2UyMDEw MDAtMHg3ZTIwMTFmZiBpcnEgMTYgb24gc2ltcGxlYnVzMA0KdWFydDA6IGNvbnNvbGUgKDExNTIw MCxuLDgsMSkNCnNwaTA6IDxCQ00yNzA4LzI4MzUgU1BJIGNvbnRyb2xsZXI+IG1lbSAweDdlMjA0 MDAwLTB4N2UyMDQxZmYgaXJxIDE4IG9uIHNpbXBsZWJ1czANCnNwaWJ1czA6IDxPRlcgU1BJIGJ1 cz4gb24gc3BpMA0Kc3BpYnVzMDogPHVua25vd24gY2FyZD4gYXQgY3MgMCBtb2RlIDANCnNwaWJ1 czA6IDx1bmtub3duIGNhcmQ+IGF0IGNzIDEgbW9kZSAwDQppaWNoYjA6IDxCQ00yNzA4LzI4MzUg QlNDIGNvbnRyb2xsZXI+IG1lbSAweDdlODA0MDAwLTB4N2U4MDRmZmYgaXJxIDI2IG9uIHNpbXBs ZWJ1czANCmJjbV9kbWEwOiA8QkNNMjgzNSBETUEgQ29udHJvbGxlcj4gbWVtIDB4N2UwMDcwMDAt MHg3ZTAwN2FmZiBpcnEgMzEsMzIsMzMsMzQsMzUsMzYsMzcsMzgsMzksNDAsNDEgb24gc2ltcGxl YnVzMA0KYmNtd2QwOiA8QkNNMjcwOC8yODM1IFdhdGNoZG9nPiBtZW0gMHg3ZTEwMDAwMC0weDdl MTAwMTEzLDB4N2UwMGEwMDAtMHg3ZTAwYTAyMywweDdlYzExMDAwLTB4N2VjMTEwMWYgb24gc2lt cGxlYnVzMA0KZ3Bpb2MxOiA8R1BJTyBjb250cm9sbGVyPiBvbiBncGlvMQ0Kc2RoY2lfYmNtMDog PEJyb2FkY29tIDI3MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4N2UzMDAwMDAtMHg3ZTMwMDBm ZiBpcnEgNzMgb24gc2ltcGxlYnVzMA0KbW1jMDogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2JjbTAN CmZiMDogPEJDTTI4MzUgVlQgZnJhbWVidWZmZXIgZHJpdmVyPiBvbiBzaW1wbGVidXMwDQpmYjA6 IGtlZXBpbmcgZXhpc3RpbmcgZmIgYnBwIG9mIDMyDQpmYmQwIG9uIGZiMA0KV0FSTklORzogRGV2 aWNlICJmYiIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBiZWZvcmUgRnJlZUJT RCAxNC4wLg0KVlQ6IFJlcGxhY2luZyBkcml2ZXIgImVmaWZiIiB3aXRoIG5ldyAiZmIiLg0KZmIw OiA1OTJ4NDQ4KDU5Mng0NDhAMCwwKSAzMmJwcA0KZmIwOiBmYnN3YXA6IDEsIHBpdGNoIDIzNjgs IGJhc2UgMHgzZWFmNTAwMCwgc2NyZWVuX3NpemUgMTA2MDg2NA0Kc2RoY2lfYmNtMTogPEJyb2Fk Y29tIDI3MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4N2UzNDAwMDAtMHg3ZTM0MDBmZiBpcnEg Nzkgb24gc2ltcGxlYnVzMQ0KbW1jMTogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2JjbTENCnBtdTA6 IDxQZXJmb3JtYW5jZSBNb25pdG9yaW5nIFVuaXQ+IGlycSAwLDEsMiwzIG9uIG9md2J1czANCmNw dWxpc3QwOiA8T3BlbiBGaXJtd2FyZSBDUFUgR3JvdXA+IG9uIG9md2J1czANCmNwdTA6IDxPcGVu IEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDANCmJjbTI4MzVfY3B1ZnJlcTA6IDxDUFUgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTANCmNwdTE6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlz dDANCmNwdTI6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDANCmNwdTM6IDxPcGVuIEZp cm13YXJlIENQVT4gb24gY3B1bGlzdDANCnBjaWIwOiA8QkNNMjgzOC1jb21wYXRpYmxlIFBDSS1l eHByZXNzIGNvbnRyb2xsZXI+IG1lbSAweDdkNTAwMDAwLTB4N2Q1MDkzMGYgaXJxIDgwLDgxIG9u IHNpbXBsZWJ1czINCnBjaWIwOiBoYXJkd2FyZSBpZGVudGlmaWVzIGFzIHJldmlzaW9uIDB4MzA0 Lg0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBpcnEg OTEgYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQpwY2kyOiA8UENJIGJ1cz4gb24gcGNpYjENCmJjbV94 aGNpMDogPFZMODA1IFVTQiAzLjAgY29udHJvbGxlciAob24gdGhlIFJhc3BiZXJyeSBQaSA0Yik+ IGlycSA5MiBhdCBkZXZpY2UgMC4wIG9uIHBjaTINCmJjbV94aGNpMDogMzIgYnl0ZXMgY29udGV4 dCBzaXplLCA2NC1iaXQgRE1BDQp1c2J1czAgb24gYmNtX3hoY2kwDQpwY2kwOiA8UENJIGJ1cz4g b24gcGNpYjANCnBjaTA6IGZhaWxlZCB0byBhbGxvY2F0ZSBidXMgbnVtYmVyDQpkZXZpY2VfYXR0 YWNoOiBwY2kwIGF0dGFjaCByZXR1cm5lZCA2DQpnZW5ldDA6IDxSUGk0IEdpZ2FiaXQgRXRoZXJu ZXQ+IG1lbSAweDdkNTgwMDAwLTB4N2Q1OGZmZmYgaXJxIDgyLDgzIG9uIHNpbXBsZWJ1czINCmdl bmV0MDogR0VORVQgdmVyc2lvbiA1LjAgcGh5IDB4MDAwMA0KbWlpYnVzMDogPE1JSSBidXM+IG9u IGdlbmV0MA0KYnJncGh5MDogPEJDTTU0MjEzUEUgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+ IFBIWSAxIG9uIG1paWJ1czANCmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFz ZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNl VC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvDQpnZW5ldDA6IEV0aGVybmV0IGFkZHJl c3M6IGRjOmE2OjMyOjM2OmI2OjcwDQpncGlvbGVkMDogPEdQSU8gTEVEcz4gb24gb2Z3YnVzMA0K Y3J5cHRvc29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+DQphcm12OGNyeXB0bzA6IENQVSBsYWNrcyBB RVMgaW5zdHJ1Y3Rpb25zDQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQppaWNi dXMwOiA8T0ZXIEkyQyBidXM+IG9uIGlpY2hiMA0KaWljMDogPEkyQyBnZW5lcmljIEkvTz4gb24g aWljYnVzMA0KdXNidXMwOiA1LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wDQpzZGhjaV9iY20w LXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwgYnV0IHRoZXJlIGlzIG5v IGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT0gUkVHSVNU RVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDogU3lzIGFkZHI6IDB4MDAw MDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1zbG90MDogQmxrIHNpemU6 IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQXJn dW1lbnQ6IDB4MDAwMDAxYWEgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAwMDAwMQ0Kc2RoY2lfYmNt MC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAwMDAwMA0Kc2Ro Y2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAgMHgwMDAwMzk0 Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAgfCBJbnQgc3RhdDogMHgw MDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFmZjAwYmIgfCBTaWcgZW5h YjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBI b3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2FwczogICAgIDB4MDAwMDAw MDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogTWF4IGN1cnI6IDB4 MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQURNQSBh ZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDog PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KdWdlbjAuMTogPDB4 MTEwNiBYSENJIHJvb3QgSFVCPiBhdCB1c2J1czANCnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21t YW5kIGludGVycnVwdCAweDAwMDMwMDAwLCBidXQgdGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQu DQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09 PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246 ICAweDAwMDA5OTAyDQpzZGhjaV9iY20wLXNsb3QwOiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJs ayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDFh YSB8IFRybiBtb2RlOiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgw MDBmMDAwMCB8IEhvc3QgY3RsOiAweDAwMDAwMDAxDQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjog ICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBX YWtlLXVwOiAgMHgwMDAwMDAwMCB8IENsb2NrOiAgICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNs b3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAwMCB8IEludCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiBJbnQgZW5hYjogMHgwMWZmMDBiYiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpz ZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVycjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAw MDAwDQpzZGhjaV9iY20wLXNsb3QwOiBDYXBzOiAgICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAw eDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBNYXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEg ZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8 IFNsb3QgaW50OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp1aHViMCBvbiB1c2J1czANCnVodWIwOiA8MHgx MTA2IFhIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDMuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czANCnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMwMDAw LCBidXQgdGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09 PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3Qw OiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9iY20w LXNsb3QwOiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDFhYSB8IFRybiBtb2RlOiAweDAwMDAwMDAw DQpzZGhjaV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAweDAw MDAwMDAxDQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6 ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENs b2NrOiAgICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAw MCB8IEludCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjogMHgw MWZmMDBiYiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVy cjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBD YXBzOiAgICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNs b3QwOiBNYXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwDQpz ZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpzZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwg YnV0IHRoZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09 PT09PT09PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDog U3lzIGFkZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1z bG90MDogQmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogQXJndW1lbnQ6IDB4MDAwMDAxYWEgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0K c2RoY2lfYmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAw MDAwMQ0Kc2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAg MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9j azogICAgMHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAg fCBJbnQgc3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFm ZjAwYmIgfCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6 IDB4MDAwMDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2Fw czogICAgIDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogTWF4IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNt MC1zbG90MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2Ro Y2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0Kc2RoY2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAwMDAsIGJ1 dCB0aGVyZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09 PT09PT09IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IFN5 cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2JjbTAtc2xv dDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDANCnNk aGNpX2JjbTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAw MDENCnNkaGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdhcDogIDB4 MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6 ICAgIDB4MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwg SW50IHN0YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAweDAxZmYw MGJiIHwgU2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIgZXJyOiAw eDAwMDAwMDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IENhcHM6 ICAgICAweDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6 IE1heCBjdXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAt c2xvdDA6IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDANCnNkaGNp X2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMwMDAwLCBidXQg dGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09 PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBTeXMg YWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9iY20wLXNsb3Qw OiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20w LXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDAwMCB8IFRybiBtb2RlOiAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAweDAwMDAwMDAx DQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6ICAweDAw MDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENsb2NrOiAg ICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAwMCB8IElu dCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjogMHgwMWZmMDBi YiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVycjogMHgw MDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBDYXBzOiAg ICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBN YXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNs b3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpz ZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwgYnV0IHRo ZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09 PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDogU3lzIGFk ZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1zbG90MDog QmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1z bG90MDogQXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAwMDAwMQ0K c2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAw MDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAg MHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAgfCBJbnQg c3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFmZjAwYmIg fCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6IDB4MDAw MDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2FwczogICAg IDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogTWF4 IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNt MC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kc2Ro Y2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAwMDAsIGJ1dCB0aGVy ZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09 IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IFN5cyBhZGRy OiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2JjbTAtc2xvdDA6IEJs ayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xv dDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAwMDENCnNk aGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdhcDogIDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6ICAgIDB4 MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwgSW50IHN0 YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAweDAxZmYwMGJiIHwg U2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIgZXJyOiAweDAwMDAw MDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IENhcHM6ICAgICAw eDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IE1heCBj dXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6 IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAt c2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCm1tYzA6 IE5vIGNvbXBhdGlibGUgY2FyZHMgZm91bmQgb24gYnVzDQptbWNzZDA6IDMyR0IgPFNESEMgU1Az MkcgOC4wIFNOIEY3RTQ5MUE4IE1GRyAwMy8yMDIxIGJ5IDMgU0Q+IGF0IG1tYzEgNTAuME1Iei80 Yml0LzY1NTM1LWJsb2NrDQpiY20yODM1X2NwdWZyZXEwOiBBUk0gNjAwTUh6LCBDb3JlIDIwME1I eiwgU0RSQU0gNDAwTUh6LCBUdXJibyBPRkYNClJlbGVhc2UgQVBzLi4uVHJ5aW5nIHRvIG1vdW50 IHJvb3QgZnJvbSB1ZnM6L2Rldi91ZnMvcm9vdGZzIFtyd10uLi4NCmRvbmUNCkNQVSAgMDogQVJN IENvcnRleC1BNzIgcjBwMyBhZmZpbml0eTogIDANCiAgICAgICAgICAgICAgICAgICBDYWNoZSBU eXBlID0gPDY0IGJ5dGUgRC1jYWNoZWxpbmUsNjQgYnl0ZSBJLWNhY2hlbGluZSxQSVBUIElDYWNo ZSw2NCBieXRlIEVSRyw2NCBieXRlIENXRz4NCiBJbnN0cnVjdGlvbiBTZXQgQXR0cmlidXRlcyAw ID0gPENSQzMyPg0KIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDEgPSA8Pg0KICAgICAgICAg UHJvY2Vzc29yIEZlYXR1cmVzIDAgPSA8QWR2U0lNRCxGUCxFTDMgMzIsRUwyIDMyLEVMMSAzMixF TDAgMzI+DQogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMSA9IDw+DQogICAgICBNZW1vcnkg TW9kZWwgRmVhdHVyZXMgMCA9IDxUR3JhbjQsVEdyYW42NCxTTlNNZW0sQmlnRW5kLDE2Yml0IEFT SUQsMTZUQiBQQT4NCiAgICAgIE1lbW9yeSBNb2RlbCBGZWF0dXJlcyAxID0gPDhiaXQgVk1JRD4N CiAgICAgIE1lbW9yeSBNb2RlbCBGZWF0dXJlcyAyID0gPDMyYml0IENDSURYLDQ4Yml0IFZBPg0K ICAgICAgICAgICAgIERlYnVnIEZlYXR1cmVzIDAgPSA8MiBDVFggQktQVHMsNCBXYXRjaHBvaW50 cyw2IEJyZWFrcG9pbnRzLFBNVXYzLERlYnVndjg+DQogICAgICAgICAgICAgRGVidWcgRmVhdHVy ZXMgMSA9IDw+DQogICAgICAgICBBdXhpbGlhcnkgRmVhdHVyZXMgMCA9IDw+DQogICAgICAgICBB dXhpbGlhcnkgRmVhdHVyZXMgMSA9IDw+DQpDUFUgIDE6IEFSTSBDb3J0ZXgtQTcyIHIwcDMgYWZm aW5pdHk6ICAxDQpDUFUgIDI6IEFSTSBDb3J0ZXgtQTcyIHIwcDMgYWZmaW5pdHk6ICAyDQpDUFUg IDM6IEFSTSBDb3J0ZXgtQTcyIHIwcDMgYWZmaW5pdHk6ICAzDQp1aHViMDogNSBwb3J0cyB3aXRo IDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCldhcm5pbmc6IG5vIHRpbWUtb2YtZGF5IGNsb2Nr IHJlZ2lzdGVyZWQsIHN5c3RlbSB0aW1lIHdpbGwgbm90IGJlIHNldCBhY2N1cmF0ZWx5DQpEdWFs IENvbnNvbGU6IFNlcmlhbCBQcmltYXJ5LCBWaWRlbyBTZWNvbmRhcnkNCnVnZW4wLjI6IDx2ZW5k b3IgMHgyMTA5IFVTQjIuMCBIdWI+IGF0IHVzYnVzMA0KdWh1YjEgb24gdWh1YjANCnVodWIxOiA8 dmVuZG9yIDB4MjEwOSBVU0IyLjAgSHViLCBjbGFzcyA5LzAsIHJldiAyLjEwLzQuMjAsIGFkZHIg MT4gb24gdXNidXMwDQp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQNCmxvMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQpnZW5ldDA6IGxpbmsgc3RhdGUgY2hh bmdlZCB0byBET1dODQp1Z2VuMC4zOiA8UHJvbGlmaWMgVGVjaG5vbG9neSBJbmMuIFVTQi1TZXJp YWwgQ29udHJvbGxlcj4gYXQgdXNidXMwDQp1cGxjb20wIG9uIHVodWIxDQp1cGxjb20wOiA8UHJv bGlmaWMgVGVjaG5vbG9neSBJbmMuIFVTQi1TZXJpYWwgQ29udHJvbGxlciwgY2xhc3MgMC8wLCBy ZXYgMi4wMC8zLjAwLCBhZGRyIDI+IG9uIHVzYnVzMA0KZ2VuZXQwOiBsaW5rIHN0YXRlIGNoYW5n ZWQgdG8gVVANCg0KZnJlZWJzZEBmYnNkMTM6fiAlIGtsZHN0YXQNCklkIFJlZnMgQWRkcmVzcyAg ICAgICAgICAgICAgICBTaXplIE5hbWUNCiAxICAgIDkgMHhmZmZmMDAwMDAwMDAwMDAwICAxMTAx ZDIwIGtlcm5lbA0KIDIgICAgMSAweGZmZmYwMDAwMDExMDIwMDAgICAgMjVjMDggdXBsY29tLmtv DQogMyAgICAzIDB4ZmZmZjAwMDAwMTEyODAwMCAgICAyODY5OCB1Y29tLmtvDQogNCAgICAxIDB4 ZmZmZjAwMDAwMTE1MTAwMCAgICAyNTgwOCB1bW9kZW0ua28NCg0Kcm9vdEBmYnNkMTM6fiAjIHVz YmR1bXANCjAxOjQwOjM2LjgxNzYxNSB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BE PUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDE6NDA6MzYuODE3ODAzIHVzYnVzMC4yIERPTkUt Q1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0 MDozNi44MTc4NDYgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0y LFNMRU49OCxJVkFMPTANCjAxOjQwOjM2LjgxODE0NCB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAw MDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6MzYuODE4MTgy IHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZB TD0wDQowMTo0MDozNi44MTg1MjggdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1I SUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjAxOjQwOjM2LjgxODU2NiB1c2J1czAuMiBT VUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDE6NDA6 MzYuODE4OTE4IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixT TEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0MDo0MC44MTcyNDQgdXNidXMwLjIgU1VCTS1DVFJMLUVQ PTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjAxOjQwOjQwLjgxNzQzOCB1 c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9 MCxFUlI9MA0KMDE6NDA6NDAuODE3NDgwIHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxT UEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowMTo0MDo0MC44MTc4MTkgdXNidXMwLjIgRE9O RS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjAx OjQwOjQwLjgxNzg1NyB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZS PTIsU0xFTj04LElWQUw9MA0KMDE6NDA6NDAuODE4MjA2IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0w MDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0MDo0MC44MTgy NDUgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJ VkFMPTANCjAxOjQwOjQwLjgxODU5MiB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BE PUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6NDQuNzkxNDgzIHVzYnVzMC4z IFNVQk0tSU5UUi1FUD0wMDAwMDA4MSxTUEQ9RlVMTCxORlI9MSxTTEVOPTAsSVZBTD0xDQowMTo0 MDo0NC43OTE1MDIgdXNidXMwLjMgU1VCTS1CVUxLLUVQPTAwMDAwMDgzLFNQRD1GVUxMLE5GUj0x LFNMRU49MCxJVkFMPTANCjAxOjQwOjQ0Ljc5MTUyOCB1c2J1czAuMyBTVUJNLUNUUkwtRVA9MDAw MDAwMDAsU1BEPUZVTEwsTkZSPTEsU0xFTj04LElWQUw9MA0KMDE6NDA6NDQuNzkyMjE2IHVzYnVz MC4zIERPTkUtQ1RSTC1FUD0wMDAwMDAwMCxTUEQ9RlVMTCxORlI9MSxTTEVOPTAsSVZBTD0wLEVS Uj0wDQowMTo0MDo0NC43OTIyNTcgdXNidXMwLjMgU1VCTS1DVFJMLUVQPTAwMDAwMDAwLFNQRD1G VUxMLE5GUj0xLFNMRU49OCxJVkFMPTANCjAxOjQwOjQ0Ljc5NDQyNCB1c2J1czAuMyBET05FLUNU UkwtRVA9MDAwMDAwMDAsU1BEPUZVTEwsTkZSPTEsU0xFTj0wLElWQUw9MCxFUlI9MA0KMDE6NDA6 NDQuNzk0NDYwIHVzYnVzMC4zIFNVQk0tQ1RSTC1FUD0wMDAwMDAwMCxTUEQ9RlVMTCxORlI9MSxT TEVOPTgsSVZBTD0wDQowMTo0MDo0NC43OTQ5MjAgdXNidXMwLjMgRE9ORS1DVFJMLUVQPTAwMDAw MDAwLFNQRD1GVUxMLE5GUj0xLFNMRU49MCxJVkFMPTAsRVJSPTANCjAxOjQwOjQ0Ljc5NDk2NiB1 c2J1czAuMyBTVUJNLUNUUkwtRVA9MDAwMDAwMDAsU1BEPUZVTEwsTkZSPTIsU0xFTj0xNixJVkFM PTANCjAxOjQwOjQ0Ljc5NTMwMCB1c2J1czAuMyBET05FLUlOVFItRVA9MDAwMDAwODEsU1BEPUZV TEwsTkZSPTEsU0xFTj0xMixJVkFMPTEsRVJSPTANCjAxOjQwOjQ0Ljc5NTMxMiB1c2J1czAuMyBT VUJNLUlOVFItRVA9MDAwMDAwODEsU1BEPUZVTEwsTkZSPTEsU0xFTj0wLElWQUw9MQ0KMDE6NDA6 NDQuNzk1NjY5IHVzYnVzMC4zIERPTkUtQ1RSTC1FUD0wMDAwMDAwMCxTUEQ9RlVMTCxORlI9MixT TEVOPTAsSVZBTD0wLEVSUj0wDQowMTo0MDo0NC43OTU3MDMgdXNidXMwLjMgU1VCTS1DVFJMLUVQ PTAwMDAwMDAwLFNQRD1GVUxMLE5GUj0xLFNMRU49OCxJVkFMPTANCjAxOjQwOjQ0Ljc5NjE2OCB1 c2J1czAuMyBET05FLUNUUkwtRVA9MDAwMDAwMDAsU1BEPUZVTEwsTkZSPTEsU0xFTj0wLElWQUw9 MCxFUlI9MA0KMDE6NDA6NDQuODMyNDYzIHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxT UEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowMTo0MDo0NC44MzI2NDAgdXNidXMwLjIgRE9O RS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjAx OjQwOjQ0LjgzMjY4MSB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZS PTIsU0xFTj04LElWQUw9MA0KMDE6NDA6NDQuODMzMDIxIHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0w MDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0MDo0NC44MzMw NjAgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJ VkFMPTANCjAxOjQwOjQ0LjgzMzQwMyB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BE PUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6NDQuODMzNDQyIHVzYnVzMC4y IFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowMTo0 MDo0NC44MzM5MTQgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0y LFNMRU49NCxJVkFMPTAsRVJSPTANCjAxOjQwOjQ0LjkwMTkyOCB1c2J1czAuMyBTVUJNLUJVTEst RVA9MDAwMDAwMDIsU1BEPUZVTEwsTkZSPTEsU0xFTj0xMixJVkFMPTANCjAxOjQwOjQ0LjkwMjI0 NCB1c2J1czAuMyBTVUJNLUNUUkwtRVA9MDAwMDAwMDAsU1BEPUZVTEwsTkZSPTEsU0xFTj04LElW QUw9MA0KMDE6NDA6NDQuOTAyMzYwIHVzYnVzMC4zIERPTkUtQlVMSy1FUD0wMDAwMDAwMixTUEQ9 RlVMTCxORlI9MSxTTEVOPTAsSVZBTD0wLEVSUj0wDQowMTo0MDo0NC45MDI2ODggdXNidXMwLjMg RE9ORS1DVFJMLUVQPTAwMDAwMDAwLFNQRD1GVUxMLE5GUj0xLFNMRU49MCxJVkFMPTAsRVJSPTAN CjAxOjQwOjQ0LjkwMjcyNyB1c2J1czAuMyBTVUJNLUNUUkwtRVA9MDAwMDAwMDAsU1BEPUZVTEws TkZSPTEsU0xFTj04LElWQUw9MA0KMDE6NDA6NDQuOTAzMTg3IHVzYnVzMC4zIERPTkUtQ1RSTC1F UD0wMDAwMDAwMCxTUEQ9RlVMTCxORlI9MSxTTEVOPTAsSVZBTD0wLEVSUj0wDQowMTo0MDo0NC45 MDQxMzYgdXNidXMwLjMgRE9ORS1JTlRSLUVQPTAwMDAwMDgxLFNQRD1GVUxMLE5GUj0wLFNMRU49 MCxJVkFMPTEsRVJSPUNBTkNFTExFRA0KMDE6NDA6NDQuOTA0NTA1IHVzYnVzMC4zIERPTkUtQlVM Sy1FUD0wMDAwMDA4MyxTUEQ9RlVMTCxORlI9MCxTTEVOPTAsSVZBTD0wLEVSUj1DQU5DRUxMRUQN CjAxOjQwOjQ4Ljg0MDk5NSB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gs TkZSPTIsU0xFTj04LElWQUw9MA0KMDE6NDA6NDguODQxMjIwIHVzYnVzMC4yIERPTkUtQ1RSTC1F UD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0MDo0OC44 NDEyNjIgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49 OCxJVkFMPTANCjAxOjQwOjQ4Ljg0MTU4OCB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAs U1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6NDguODQxNjI3IHVzYnVz MC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQow MTo0MDo0OC44NDE5NzYgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5G Uj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjAxOjQwOjQ4Ljg0MjAxNSB1c2J1czAuMiBTVUJNLUNU UkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDE6NDA6NDguODQy MzYwIHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQs SVZBTD0wLEVSUj0wDQowMTo0MDo1Mi44OTMyNTEgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAw MDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjAxOjQwOjUyLjg5MzQ2MyB1c2J1czAu MiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9 MA0KMDE6NDA6NTIuODkzNTA1IHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElH SCxORlI9MixTTEVOPTgsSVZBTD0wDQowMTo0MDo1Mi44OTM4MzYgdXNidXMwLjIgRE9ORS1DVFJM LUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjAxOjQwOjUy Ljg5Mzg3NiB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xF Tj04LElWQUw9MA0KMDE6NDA6NTIuODk0MjI1IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4 MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowMTo0MDo1Mi44OTQyNjQgdXNi dXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTAN CjAxOjQwOjUyLjg5NDYxMCB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gs TkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6NTYuOTEyNDgxIHVzYnVzMC4yIFNVQk0t Q1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowMTo0MDo1Ni45 MTI3MTAgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49 NCxJVkFMPTAsRVJSPTANCjAxOjQwOjU2LjkxMjc1MSB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAw MDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDE6NDA6NTYuOTEzMDk0IHVzYnVz MC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVS Uj0wDQowMTo0MDo1Ni45MTMxMzIgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1I SUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjAxOjQwOjU2LjkxMzQ3NyB1c2J1czAuMiBET05FLUNU UkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDE6NDA6 NTYuOTEzNTE1IHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixT TEVOPTgsSVZBTD0wDQowMTo0MDo1Ni45MTM4NjQgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAw MDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCl5DDQo3MCBwYWNrZXRzIGNh cHR1cmVkDQo3MCBwYWNrZXRzIHJlY2VpdmVkIGJ5IGZpbHRlcg0KMCBwYWNrZXRzIGRyb3BwZWQg Ynkga2VybmVsDQpyb290QGZic2QxMzp+ICMNCg== --0000000000008012d005d7f9bbc4 Content-Type: text/plain; charset="US-ASCII"; name="freebsd13_rpi4b_uplcom0_usb3.0_notdetected.txt" Content-Disposition: attachment; filename="freebsd13_rpi4b_uplcom0_usb3.0_notdetected.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzmo7fq61 ZnJlZWJzZEBmYnNkMTM6fiAlIGRtZXNnDQotLS08PEJPT1Q+Pi0tLQ0KQ29weXJpZ2h0IChjKSAx OTkyLTIwMjEgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwg MTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBU aGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJl c2VydmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNE IEZvdW5kYXRpb24uDQpGcmVlQlNEIDEzLjAtUkVMRUFTRSAjMDogVHVlIEZlYiAgOCAwMzoyNTow NyBQU1QgMjAyMg0KICAgIHJvb3RAZmJzZDEzOi91c3Ivc3JjL3N5cy9hcm02NC9jb21waWxlL0dF TkVSSUMgYXJtNjQNCkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAxMS4wLjEgKGdpdEBnaXRodWIuY29t Omxsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZtb3JnLTExLjAuMS0wLWc0M2ZmNzVmMmMzZmUpDQpW VChlZmlmYik6IHJlc29sdXRpb24gNTkyeDQ0OA0KbW9kdWxlIGZpcm13YXJlIGFscmVhZHkgcHJl c2VudCENCnJlYWwgbWVtb3J5ICA9IDIwNjc1NDIwMTYgKDE5NzEgTUIpDQphdmFpbCBtZW1vcnkg PSAxOTk1MzQxODI0ICgxOTAyIE1CKQ0KU3RhcnRpbmcgQ1BVIDEgKDEpDQpTdGFydGluZyBDUFUg MiAoMikNClN0YXJ0aW5nIENQVSAzICgzKQ0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5 c3RlbSBEZXRlY3RlZDogNCBDUFVzDQpyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLg0KcmFuZG9t OiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UNCk1BUCAzOWYzODAwMCBtb2RlIDIg cGFnZXMgMQ0KTUFQIDM5ZjNjMDAwIG1vZGUgMiBwYWdlcyAzDQpNQVAgMzlmNDAwMDAgbW9kZSAy IHBhZ2VzIDQNCk1BUCAzYjM1MDAwMCBtb2RlIDIgcGFnZXMgMTYNCk1BUCBmZTEwMDAwMCBtb2Rl IDAgcGFnZXMgMQ0KV0FSTklORzogRGV2aWNlICJrYmQiIGlzIEdpYW50IGxvY2tlZCBhbmQgbWF5 IGJlIGRlbGV0ZWQgYmVmb3JlIEZyZWVCU0QgMTQuMC4NCmtiZDAgYXQga2JkbXV4MA0KV0FSTklO RzogRGV2aWNlICJvcGVuZmlybSIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBi ZWZvcmUgRnJlZUJTRCAxNC4wLg0Kb2Z3YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNlIFRyZWU+ DQpzaW1wbGVidXMwOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1 czANCm9md19jbGtidXMwOiA8T0ZXIGNsb2NrcyBidXM+IG9uIG9md2J1czANCmNsa19maXhlZDA6 IDxGaXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czANCmNsa19maXhlZDE6IDxGaXhlZCBjbG9jaz4g b24gb2Z3X2Nsa2J1czANCmNsa19maXhlZDI6IDxGaXhlZCBjbG9jaz4gb24gb2Z3YnVzMA0KY2xr X2ZpeGVkMzogPEZpeGVkIGNsb2NrPiBvbiBvZndidXMwDQpzaW1wbGVidXMxOiA8RmxhdHRlbmVk IGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1czANCnNpbXBsZWJ1czI6IDxGbGF0dGVu ZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3YnVzMA0KcmVnZml4MDogPEZpeGVkIFJl Z3VsYXRvcj4gb24gb2Z3YnVzMA0KcmVnZml4MTogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVz MA0KcmVnZml4MjogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVzMA0Kc2ltcGxlYnVzMzogPEZs YXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwDQpzaW1wbGVfbWZkMDog PFNpbXBsZSBNRkQgKE11bHRpLUZ1bmN0aW9ucyBEZXZpY2UpPiBtZW0gMHg3ZDVkMjAwMC0weDdk NWQyZWZmIG9uIHNpbXBsZWJ1czANCmJjbTI4MzVfZmlybXdhcmUwOiA8QkNNMjgzNSBGaXJtd2Fy ZT4gb24gc2ltcGxlYnVzMA0Kb2Z3X2Nsa2J1czE6IDxPRlcgY2xvY2tzIGJ1cz4gb24gYmNtMjgz NV9maXJtd2FyZTANCnBzY2kwOiA8QVJNIFBvd2VyIFN0YXRlIENvLW9yZGluYXRpb24gSW50ZXJm YWNlIERyaXZlcj4gb24gb2Z3YnVzMA0KZ2ljMDogPEFSTSBHZW5lcmljIEludGVycnVwdCBDb250 cm9sbGVyPiBtZW0gMHg0MDA0MTAwMC0weDQwMDQxZmZmLDB4NDAwNDIwMDAtMHg0MDA0M2ZmZiww eDQwMDQ0MDAwLTB4NDAwNDVmZmYsMHg0MDA0NjAwMC0weDQwMDQ3ZmZmIGlycSAzMCBvbiBzaW1w bGVidXMwDQpnaWMwOiBwbiAweDIsIGFyY2ggMHgyLCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQz YiBpcnFzIDI1Ng0KZ3BpbzA6IDxCQ00yNzA4LzI4MzUgR1BJTyBjb250cm9sbGVyPiBtZW0gMHg3 ZTIwMDAwMC0weDdlMjAwMGIzIGlycSAxNCwxNSBvbiBzaW1wbGVidXMwDQpncGlvYnVzMDogPE9G VyBHUElPIGJ1cz4gb24gZ3BpbzANCmdwaW8xOiA8UmFzcGJlcnJ5IFBpIEZpcm13YXJlIEdQSU8g Y29udHJvbGxlcj4gb24gYmNtMjgzNV9maXJtd2FyZTANCmdwaW9idXMxOiA8R1BJTyBidXM+IG9u IGdwaW8xDQpyZWdmaXgwOiBDYW5ub3Qgc2V0IEdQSU8gcGluOiA2DQpSRUdOT0RFX0lOSVQgZmFp bGVkOiA2DQpyZWdmaXgwOiBDYW5ub3QgcmVnaXN0ZXIgcmVndWxhdG9yLg0KbWJveDA6IDxCQ00y ODM1IFZpZGVvQ29yZSBNYWlsYm94PiBtZW0gMHg3ZTAwYjg4MC0weDdlMDBiOGJmIGlycSAxMyBv biBzaW1wbGVidXMwDQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+ IG9uIG9md2J1czANCmdlbmVyaWNfdGltZXIwOiA8QVJNdjggR2VuZXJpYyBUaW1lcj4gaXJxIDQs NSw2LDcgb24gb2Z3YnVzMA0KVGltZWNvdW50ZXIgIkFSTSBNUENvcmUgVGltZWNvdW50ZXIiIGZy ZXF1ZW5jeSA1NDAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCkV2ZW50IHRpbWVyICJBUk0gTVBDb3Jl IEV2ZW50dGltZXIiIGZyZXF1ZW5jeSA1NDAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCnVzYl9ub3Bf eGNlaXYwOiA8VVNCIE5PUCBQSFk+IG9uIG9md2J1czANCmdwaW9jMDogPEdQSU8gY29udHJvbGxl cj4gb24gZ3BpbzANCnVhcnQwOiA8UHJpbWVDZWxsIFVBUlQgKFBMMDExKT4gbWVtIDB4N2UyMDEw MDAtMHg3ZTIwMTFmZiBpcnEgMTYgb24gc2ltcGxlYnVzMA0KdWFydDA6IGNvbnNvbGUgKDExNTIw MCxuLDgsMSkNCnNwaTA6IDxCQ00yNzA4LzI4MzUgU1BJIGNvbnRyb2xsZXI+IG1lbSAweDdlMjA0 MDAwLTB4N2UyMDQxZmYgaXJxIDE4IG9uIHNpbXBsZWJ1czANCnNwaWJ1czA6IDxPRlcgU1BJIGJ1 cz4gb24gc3BpMA0Kc3BpYnVzMDogPHVua25vd24gY2FyZD4gYXQgY3MgMCBtb2RlIDANCnNwaWJ1 czA6IDx1bmtub3duIGNhcmQ+IGF0IGNzIDEgbW9kZSAwDQppaWNoYjA6IDxCQ00yNzA4LzI4MzUg QlNDIGNvbnRyb2xsZXI+IG1lbSAweDdlODA0MDAwLTB4N2U4MDRmZmYgaXJxIDI2IG9uIHNpbXBs ZWJ1czANCmJjbV9kbWEwOiA8QkNNMjgzNSBETUEgQ29udHJvbGxlcj4gbWVtIDB4N2UwMDcwMDAt MHg3ZTAwN2FmZiBpcnEgMzEsMzIsMzMsMzQsMzUsMzYsMzcsMzgsMzksNDAsNDEgb24gc2ltcGxl YnVzMA0KYmNtd2QwOiA8QkNNMjcwOC8yODM1IFdhdGNoZG9nPiBtZW0gMHg3ZTEwMDAwMC0weDdl MTAwMTEzLDB4N2UwMGEwMDAtMHg3ZTAwYTAyMywweDdlYzExMDAwLTB4N2VjMTEwMWYgb24gc2lt cGxlYnVzMA0KZ3Bpb2MxOiA8R1BJTyBjb250cm9sbGVyPiBvbiBncGlvMQ0Kc2RoY2lfYmNtMDog PEJyb2FkY29tIDI3MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4N2UzMDAwMDAtMHg3ZTMwMDBm ZiBpcnEgNzMgb24gc2ltcGxlYnVzMA0KbW1jMDogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2JjbTAN CmZiMDogPEJDTTI4MzUgVlQgZnJhbWVidWZmZXIgZHJpdmVyPiBvbiBzaW1wbGVidXMwDQpmYjA6 IGtlZXBpbmcgZXhpc3RpbmcgZmIgYnBwIG9mIDMyDQpmYmQwIG9uIGZiMA0KV0FSTklORzogRGV2 aWNlICJmYiIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBiZWZvcmUgRnJlZUJT RCAxNC4wLg0KVlQ6IFJlcGxhY2luZyBkcml2ZXIgImVmaWZiIiB3aXRoIG5ldyAiZmIiLg0KZmIw OiA1OTJ4NDQ4KDU5Mng0NDhAMCwwKSAzMmJwcA0KZmIwOiBmYnN3YXA6IDEsIHBpdGNoIDIzNjgs IGJhc2UgMHgzZWFmNTAwMCwgc2NyZWVuX3NpemUgMTA2MDg2NA0Kc2RoY2lfYmNtMTogPEJyb2Fk Y29tIDI3MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4N2UzNDAwMDAtMHg3ZTM0MDBmZiBpcnEg Nzkgb24gc2ltcGxlYnVzMQ0KbW1jMTogPE1NQy9TRCBidXM+IG9uIHNkaGNpX2JjbTENCnBtdTA6 IDxQZXJmb3JtYW5jZSBNb25pdG9yaW5nIFVuaXQ+IGlycSAwLDEsMiwzIG9uIG9md2J1czANCmNw dWxpc3QwOiA8T3BlbiBGaXJtd2FyZSBDUFUgR3JvdXA+IG9uIG9md2J1czANCmNwdTA6IDxPcGVu IEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDANCmJjbTI4MzVfY3B1ZnJlcTA6IDxDUFUgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTANCmNwdTE6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlz dDANCmNwdTI6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDANCmNwdTM6IDxPcGVuIEZp cm13YXJlIENQVT4gb24gY3B1bGlzdDANCnBjaWIwOiA8QkNNMjgzOC1jb21wYXRpYmxlIFBDSS1l eHByZXNzIGNvbnRyb2xsZXI+IG1lbSAweDdkNTAwMDAwLTB4N2Q1MDkzMGYgaXJxIDgwLDgxIG9u IHNpbXBsZWJ1czINCnBjaWIwOiBoYXJkd2FyZSBpZGVudGlmaWVzIGFzIHJldmlzaW9uIDB4MzA0 Lg0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBpcnEg OTEgYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQpwY2kyOiA8UENJIGJ1cz4gb24gcGNpYjENCmJjbV94 aGNpMDogPFZMODA1IFVTQiAzLjAgY29udHJvbGxlciAob24gdGhlIFJhc3BiZXJyeSBQaSA0Yik+ IGlycSA5MiBhdCBkZXZpY2UgMC4wIG9uIHBjaTINCmJjbV94aGNpMDogMzIgYnl0ZXMgY29udGV4 dCBzaXplLCA2NC1iaXQgRE1BDQp1c2J1czAgb24gYmNtX3hoY2kwDQpwY2kwOiA8UENJIGJ1cz4g b24gcGNpYjANCnBjaTA6IGZhaWxlZCB0byBhbGxvY2F0ZSBidXMgbnVtYmVyDQpkZXZpY2VfYXR0 YWNoOiBwY2kwIGF0dGFjaCByZXR1cm5lZCA2DQpnZW5ldDA6IDxSUGk0IEdpZ2FiaXQgRXRoZXJu ZXQ+IG1lbSAweDdkNTgwMDAwLTB4N2Q1OGZmZmYgaXJxIDgyLDgzIG9uIHNpbXBsZWJ1czINCmdl bmV0MDogR0VORVQgdmVyc2lvbiA1LjAgcGh5IDB4MDAwMA0KbWlpYnVzMDogPE1JSSBidXM+IG9u IGdlbmV0MA0KYnJncGh5MDogPEJDTTU0MjEzUEUgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+ IFBIWSAxIG9uIG1paWJ1czANCmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFz ZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNl VC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvDQpnZW5ldDA6IEV0aGVybmV0IGFkZHJl c3M6IGRjOmE2OjMyOjM2OmI2OjcwDQpncGlvbGVkMDogPEdQSU8gTEVEcz4gb24gb2Z3YnVzMA0K Y3J5cHRvc29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+DQphcm12OGNyeXB0bzA6IENQVSBsYWNrcyBB RVMgaW5zdHJ1Y3Rpb25zDQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQppaWNi dXMwOiA8T0ZXIEkyQyBidXM+IG9uIGlpY2hiMA0KaWljMDogPEkyQyBnZW5lcmljIEkvTz4gb24g aWljYnVzMA0KdXNidXMwOiA1LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wDQpzZGhjaV9iY20w LXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwgYnV0IHRoZXJlIGlzIG5v IGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT0gUkVHSVNU RVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDogU3lzIGFkZHI6IDB4MDAw MDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1zbG90MDogQmxrIHNpemU6 IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQXJn dW1lbnQ6IDB4MDAwMDAxYWEgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAwMDAwMQ0Kc2RoY2lfYmNt MC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAwMDAwMA0Kc2Ro Y2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAgMHgwMDAwMzk0 Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAgfCBJbnQgc3RhdDogMHgw MDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFmZjAwYmIgfCBTaWcgZW5h YjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6IDB4MDAwMDAwMDAgfCBI b3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2FwczogICAgIDB4MDAwMDAw MDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogTWF4IGN1cnI6IDB4 MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQURNQSBh ZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDog PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KdWdlbjAuMTogPDB4 MTEwNiBYSENJIHJvb3QgSFVCPiBhdCB1c2J1czANCnVodWIwIG9uIHVzYnVzMA0KdWh1YjA6IDww eDExMDYgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzMA0Kc2RoY2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAw MDAsIGJ1dCB0aGVyZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09 PT09PT09PT09PT09IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xv dDA6IFN5cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2Jj bTAtc2xvdDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNk aGNpX2JjbTAtc2xvdDA6IEFyZ3VtZW50OiAweDAwMDAwMWFhIHwgVHJuIG1vZGU6IDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4 MDAwMDAwMDENCnNkaGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdh cDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwg Q2xvY2s6ICAgIDB4MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAw MDAwIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAw eDAxZmYwMGJiIHwgU2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIg ZXJyOiAweDAwMDAwMDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6 IENhcHM6ICAgICAweDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAt c2xvdDA6IE1heCBjdXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNp X2JjbTAtc2xvdDA6IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDAN CnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMwMDAw LCBidXQgdGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09 PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3Qw OiBTeXMgYWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9iY20w LXNsb3QwOiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDFhYSB8IFRybiBtb2RlOiAweDAwMDAwMDAw DQpzZGhjaV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAweDAw MDAwMDAxDQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6 ICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENs b2NrOiAgICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAw MCB8IEludCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjogMHgw MWZmMDBiYiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVy cjogMHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBD YXBzOiAgICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNs b3QwOiBNYXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwDQpz ZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpzZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwg YnV0IHRoZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09 PT09PT09PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDog U3lzIGFkZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1z bG90MDogQmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogQXJndW1lbnQ6IDB4MDAwMDAxYWEgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0K c2RoY2lfYmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAw MDAwMQ0Kc2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAg MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9j azogICAgMHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAg fCBJbnQgc3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFm ZjAwYmIgfCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6 IDB4MDAwMDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2Fw czogICAgIDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogTWF4IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNt MC1zbG90MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2Ro Y2lfYmNtMC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0Kc2RoY2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAwMDAsIGJ1 dCB0aGVyZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09 PT09PT09IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IFN5 cyBhZGRyOiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2JjbTAtc2xv dDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDANCnNk aGNpX2JjbTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAw MDENCnNkaGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdhcDogIDB4 MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6 ICAgIDB4MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwg SW50IHN0YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAweDAxZmYw MGJiIHwgU2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIgZXJyOiAw eDAwMDAwMDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IENhcHM6 ICAgICAweDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6 IE1heCBjdXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAt c2xvdDA6IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDANCnNkaGNp X2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CnNkaGNpX2JjbTAtc2xvdDA6IEdvdCBjb21tYW5kIGludGVycnVwdCAweDAwMDMwMDAwLCBidXQg dGhlcmUgaXMgbm8gYWN0aXZlIGNvbW1hbmQuDQpzZGhjaV9iY20wLXNsb3QwOiA9PT09PT09PT09 PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09DQpzZGhjaV9iY20wLXNsb3QwOiBTeXMg YWRkcjogMHgwMDAwMDAwMCB8IFZlcnNpb246ICAweDAwMDA5OTAyDQpzZGhjaV9iY20wLXNsb3Qw OiBCbGsgc2l6ZTogMHgwMDAwMDAwMCB8IEJsayBjbnQ6ICAweDAwMDAwMDAwDQpzZGhjaV9iY20w LXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDAwMCB8IFRybiBtb2RlOiAweDAwMDAwMDAwDQpzZGhj aV9iY20wLXNsb3QwOiBQcmVzZW50OiAgMHgwMDBmMDAwMCB8IEhvc3QgY3RsOiAweDAwMDAwMDAx DQpzZGhjaV9iY20wLXNsb3QwOiBQb3dlcjogICAgMHgwMDAwMDAwZiB8IEJsayBnYXA6ICAweDAw MDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8IENsb2NrOiAg ICAweDAwMDAzOTQ3DQpzZGhjaV9iY20wLXNsb3QwOiBUaW1lb3V0OiAgMHgwMDAwMDAwMCB8IElu dCBzdGF0OiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBJbnQgZW5hYjogMHgwMWZmMDBi YiB8IFNpZyBlbmFiOiAweDAxZmYwMGJiDQpzZGhjaV9iY20wLXNsb3QwOiBBQzEyIGVycjogMHgw MDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBDYXBzOiAg ICAgMHgwMDAwMDAwMCB8IENhcHMyOiAgICAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNsb3QwOiBN YXggY3VycjogMHgwMDAwMDAwMSB8IEFETUEgZXJyOiAweDAwMDAwMDAwDQpzZGhjaV9iY20wLXNs b3QwOiBBRE1BIGFkZHI6MHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwDQpzZGhjaV9i Y20wLXNsb3QwOiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpz ZGhjaV9iY20wLXNsb3QwOiBHb3QgY29tbWFuZCBpbnRlcnJ1cHQgMHgwMDAzMDAwMCwgYnV0IHRo ZXJlIGlzIG5vIGFjdGl2ZSBjb21tYW5kLg0Kc2RoY2lfYmNtMC1zbG90MDogPT09PT09PT09PT09 PT0gUkVHSVNURVIgRFVNUCA9PT09PT09PT09PT09PQ0Kc2RoY2lfYmNtMC1zbG90MDogU3lzIGFk ZHI6IDB4MDAwMDAwMDAgfCBWZXJzaW9uOiAgMHgwMDAwOTkwMg0Kc2RoY2lfYmNtMC1zbG90MDog QmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1z bG90MDogQXJndW1lbnQ6IDB4MDAwMDAwMDAgfCBUcm4gbW9kZTogMHgwMDAwMDAwMA0Kc2RoY2lf YmNtMC1zbG90MDogUHJlc2VudDogIDB4MDAwZjAwMDAgfCBIb3N0IGN0bDogMHgwMDAwMDAwMQ0K c2RoY2lfYmNtMC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMGYgfCBCbGsgZ2FwOiAgMHgwMDAw MDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogV2FrZS11cDogIDB4MDAwMDAwMDAgfCBDbG9jazogICAg MHgwMDAwMzk0Nw0Kc2RoY2lfYmNtMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAgfCBJbnQg c3RhdDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogSW50IGVuYWI6IDB4MDFmZjAwYmIg fCBTaWcgZW5hYjogMHgwMWZmMDBiYg0Kc2RoY2lfYmNtMC1zbG90MDogQUMxMiBlcnI6IDB4MDAw MDAwMDAgfCBIb3N0IGN0bDI6MHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogQ2FwczogICAg IDB4MDAwMDAwMDAgfCBDYXBzMjogICAgMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90MDogTWF4 IGN1cnI6IDB4MDAwMDAwMDEgfCBBRE1BIGVycjogMHgwMDAwMDAwMA0Kc2RoY2lfYmNtMC1zbG90 MDogQURNQSBhZGRyOjB4MDAwMDAwMDAgfCBTbG90IGludDogMHgwMDAwMDAwMA0Kc2RoY2lfYmNt MC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kc2Ro Y2lfYmNtMC1zbG90MDogR290IGNvbW1hbmQgaW50ZXJydXB0IDB4MDAwMzAwMDAsIGJ1dCB0aGVy ZSBpcyBubyBhY3RpdmUgY29tbWFuZC4NCnNkaGNpX2JjbTAtc2xvdDA6ID09PT09PT09PT09PT09 IFJFR0lTVEVSIERVTVAgPT09PT09PT09PT09PT0NCnNkaGNpX2JjbTAtc2xvdDA6IFN5cyBhZGRy OiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDk5MDINCnNkaGNpX2JjbTAtc2xvdDA6IEJs ayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xv dDA6IEFyZ3VtZW50OiAweDAwMDAwMDAwIHwgVHJuIG1vZGU6IDB4MDAwMDAwMDANCnNkaGNpX2Jj bTAtc2xvdDA6IFByZXNlbnQ6ICAweDAwMGYwMDAwIHwgSG9zdCBjdGw6IDB4MDAwMDAwMDENCnNk aGNpX2JjbTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDBmIHwgQmxrIGdhcDogIDB4MDAwMDAw MDANCnNkaGNpX2JjbTAtc2xvdDA6IFdha2UtdXA6ICAweDAwMDAwMDAwIHwgQ2xvY2s6ICAgIDB4 MDAwMDM5NDcNCnNkaGNpX2JjbTAtc2xvdDA6IFRpbWVvdXQ6ICAweDAwMDAwMDAwIHwgSW50IHN0 YXQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IEludCBlbmFiOiAweDAxZmYwMGJiIHwg U2lnIGVuYWI6IDB4MDFmZjAwYmINCnNkaGNpX2JjbTAtc2xvdDA6IEFDMTIgZXJyOiAweDAwMDAw MDAwIHwgSG9zdCBjdGwyOjB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IENhcHM6ICAgICAw eDAwMDAwMDAwIHwgQ2FwczI6ICAgIDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6IE1heCBj dXJyOiAweDAwMDAwMDAxIHwgQURNQSBlcnI6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAtc2xvdDA6 IEFETUEgYWRkcjoweDAwMDAwMDAwIHwgU2xvdCBpbnQ6IDB4MDAwMDAwMDANCnNkaGNpX2JjbTAt c2xvdDA6ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCm1tYzA6 IE5vIGNvbXBhdGlibGUgY2FyZHMgZm91bmQgb24gYnVzDQptbWNzZDA6IDMyR0IgPFNESEMgU1Az MkcgOC4wIFNOIEY3RTQ5MUE4IE1GRyAwMy8yMDIxIGJ5IDMgU0Q+IGF0IG1tYzEgNTAuME1Iei80 Yml0LzY1NTM1LWJsb2NrDQp1aHViMDogNSBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQNCmJjbTI4MzVfY3B1ZnJlcTA6IEFSTSA2MDBNSHosIENvcmUgMjAwTUh6LCBTRFJBTSA0 MDBNSHosIFR1cmJvIE9GRg0KUmVsZWFzZSBBUHMuLi5UcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9t IHVmczovZGV2L3Vmcy9yb290ZnMgW3J3XS4uLg0KZG9uZQ0KQ1BVICAwOiBBUk0gQ29ydGV4LUE3 MiByMHAzIGFmZmluaXR5OiAgMA0KICAgICAgICAgICAgICAgICAgIENhY2hlIFR5cGUgPSA8NjQg Ynl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2FjaGVsaW5lLFBJUFQgSUNhY2hlLDY0IGJ5dGUg RVJHLDY0IGJ5dGUgQ1dHPg0KIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDAgPSA8Q1JDMzI+ DQogSW5zdHJ1Y3Rpb24gU2V0IEF0dHJpYnV0ZXMgMSA9IDw+DQogICAgICAgICBQcm9jZXNzb3Ig RmVhdHVyZXMgMCA9IDxBZHZTSU1ELEZQLEVMMyAzMixFTDIgMzIsRUwxIDMyLEVMMCAzMj4NCiAg ICAgICAgIFByb2Nlc3NvciBGZWF0dXJlcyAxID0gPD4NCiAgICAgIE1lbW9yeSBNb2RlbCBGZWF0 dXJlcyAwID0gPFRHcmFuNCxUR3JhbjY0LFNOU01lbSxCaWdFbmQsMTZiaXQgQVNJRCwxNlRCIFBB Pg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDEgPSA8OGJpdCBWTUlEPg0KICAgICAgTWVt b3J5IE1vZGVsIEZlYXR1cmVzIDIgPSA8MzJiaXQgQ0NJRFgsNDhiaXQgVkE+DQogICAgICAgICAg ICAgRGVidWcgRmVhdHVyZXMgMCA9IDwyIENUWCBCS1BUcyw0IFdhdGNocG9pbnRzLDYgQnJlYWtw b2ludHMsUE1VdjMsRGVidWd2OD4NCiAgICAgICAgICAgICBEZWJ1ZyBGZWF0dXJlcyAxID0gPD4N CiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0gPD4NCiAgICAgICAgIEF1eGlsaWFyeSBG ZWF0dXJlcyAxID0gPD4NCkNQVSAgMTogQVJNIENvcnRleC1BNzIgcjBwMyBhZmZpbml0eTogIDEN CkNQVSAgMjogQVJNIENvcnRleC1BNzIgcjBwMyBhZmZpbml0eTogIDINCkNQVSAgMzogQVJNIENv cnRleC1BNzIgcjBwMyBhZmZpbml0eTogIDMNCldhcm5pbmc6IG5vIHRpbWUtb2YtZGF5IGNsb2Nr IHJlZ2lzdGVyZWQsIHN5c3RlbSB0aW1lIHdpbGwgbm90IGJlIHNldCBhY2N1cmF0ZWx5DQpEdWFs IENvbnNvbGU6IFNlcmlhbCBQcmltYXJ5LCBWaWRlbyBTZWNvbmRhcnkNCnVnZW4wLjI6IDx2ZW5k b3IgMHgyMTA5IFVTQjIuMCBIdWI+IGF0IHVzYnVzMA0KdWh1YjEgb24gdWh1YjANCnVodWIxOiA8 dmVuZG9yIDB4MjEwOSBVU0IyLjAgSHViLCBjbGFzcyA5LzAsIHJldiAyLjEwLzQuMjAsIGFkZHIg MT4gb24gdXNidXMwDQp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQNCmxvMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQpnZW5ldDA6IGxpbmsgc3RhdGUgY2hh bmdlZCB0byBET1dODQpnZW5ldDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KDQpmcmVlYnNk QGZic2QxMzp+ICUga2xkc3RhdA0KSWQgUmVmcyBBZGRyZXNzICAgICAgICAgICAgICAgIFNpemUg TmFtZQ0KIDEgICAgOSAweGZmZmYwMDAwMDAwMDAwMDAgIDExMDFkMjAga2VybmVsDQogMiAgICAx IDB4ZmZmZjAwMDAwMTEwMjAwMCAgICAyNWMwOCB1cGxjb20ua28NCiAzICAgIDMgMHhmZmZmMDAw MDAxMTI4MDAwICAgIDI4Njk4IHVjb20ua28NCiA0ICAgIDEgMHhmZmZmMDAwMDAxMTUxMDAwICAg IDI1ODA4IHVtb2RlbS5rbw0KDQpyb290QGZic2QxMzp+ICMgdXNiZHVtcA0KMDk6MzU6MDUuODY1 Njc1IHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgs SVZBTD0wDQowOTozNTowNS44NjU4NjUgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQ RD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjA5OjM1OjA1Ljg2NTkwOSB1c2J1czAu MiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDk6 MzU6MDUuODY2MTg3IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9 MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowOTozNTowNS44NjYyMjcgdXNidXMwLjIgU1VCTS1DVFJM LUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjA5OjM1OjA1Ljg2NjU0 OSB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElW QUw9MCxFUlI9MA0KMDk6MzU6MDUuODY2NTg4IHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4 MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowOTozNTowNS44NjY5MTEgdXNidXMwLjIg RE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTAN CjA5OjM1OjA5Ljg3MDg5OCB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gs TkZSPTIsU0xFTj04LElWQUw9MA0KMDk6MzU6MDkuODcxMDgwIHVzYnVzMC4yIERPTkUtQ1RSTC1F UD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowOTozNTowOS44 NzExMjEgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49 OCxJVkFMPTANCjA5OjM1OjA5Ljg3MTM3MiB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAs U1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDk6MzU6MDkuODcxNDEyIHVzYnVz MC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQow OTozNTowOS44NzE3MzIgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5G Uj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjA5OjM1OjA5Ljg3MTc3MCB1c2J1czAuMiBTVUJNLUNU UkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDk6MzU6MDkuODcy MDk3IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQs SVZBTD0wLEVSUj0wDQowOTozNToxMy44OTQzODggdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAw MDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjA5OjM1OjEzLjg5NDU2OSB1c2J1czAu MiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9 MA0KMDk6MzU6MTMuODk0NjExIHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElH SCxORlI9MixTTEVOPTgsSVZBTD0wDQowOTozNToxMy44OTUwMTUgdXNidXMwLjIgRE9ORS1DVFJM LUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCjA5OjM1OjEz Ljg5NTA1NCB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xF Tj04LElWQUw9MA0KMDk6MzU6MTMuODk1MjY4IHVzYnVzMC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4 MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVSUj0wDQowOTozNToxMy44OTUzMTMgdXNi dXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49OCxJVkFMPTAN CjA5OjM1OjEzLjg5NTYyMSB1c2J1czAuMiBET05FLUNUUkwtRVA9MDAwMDAwODAsU1BEPUhJR0gs TkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDk6MzU6MTcuOTgzODc2IHVzYnVzMC4yIFNVQk0t Q1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTgsSVZBTD0wDQowOTozNToxNy45 ODQwNTYgdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1ISUdILE5GUj0yLFNMRU49 NCxJVkFMPTAsRVJSPTANCjA5OjM1OjE3Ljk4NDA5NyB1c2J1czAuMiBTVUJNLUNUUkwtRVA9MDAw MDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj04LElWQUw9MA0KMDk6MzU6MTcuOTg0NDIxIHVzYnVz MC4yIERPTkUtQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixTTEVOPTQsSVZBTD0wLEVS Uj0wDQowOTozNToxNy45ODQ0NjAgdXNidXMwLjIgU1VCTS1DVFJMLUVQPTAwMDAwMDgwLFNQRD1I SUdILE5GUj0yLFNMRU49OCxJVkFMPTANCjA5OjM1OjE3Ljk4NDc3NCB1c2J1czAuMiBET05FLUNU UkwtRVA9MDAwMDAwODAsU1BEPUhJR0gsTkZSPTIsU0xFTj00LElWQUw9MCxFUlI9MA0KMDk6MzU6 MTcuOTg0ODEzIHVzYnVzMC4yIFNVQk0tQ1RSTC1FUD0wMDAwMDA4MCxTUEQ9SElHSCxORlI9MixT TEVOPTgsSVZBTD0wDQowOTozNToxNy45ODUxMzggdXNidXMwLjIgRE9ORS1DVFJMLUVQPTAwMDAw MDgwLFNQRD1ISUdILE5GUj0yLFNMRU49NCxJVkFMPTAsRVJSPTANCl5DDQozMiBwYWNrZXRzIGNh cHR1cmVkDQozMiBwYWNrZXRzIHJlY2VpdmVkIGJ5IGZpbHRlcg0KMCBwYWNrZXRzIGRyb3BwZWQg Ynkga2VybmVsDQpyb290QGZic2QxMzp+ICMNCg== --0000000000008012d005d7f9bbc4-- From nobody Mon Feb 14 13:39:51 2022 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 BC58B19CBF32 for ; Mon, 14 Feb 2022 13:40:01 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4Jy51r4fLBz521R for ; Mon, 14 Feb 2022 13:40:00 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 603E25C00D9 for ; Mon, 14 Feb 2022 08:39:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 14 Feb 2022 08:39:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=YW4vlihnivfeKVcW219uy4w5mM+Al/00OLLQH6 ZE4vY=; b=TdZO/hKwv31CZx77xtTCG+dDcnO2nEralo1KL9/kDel4bx3kGIkIGu l0glCbn1VyUjm9xbfksJ9/GXmnwmfJSwJNS69xM3GWZBahIuXDsLh/P8PTdOhcau 6O0NNE4n52kRrnJL2kA4lqj6cSXEJ/z1ZIVJBIdSLK7PQaX+0V4SgWW3Y55eKMDZ oQsnKDXHzYreDL+d37q94RTauRs6Y/fEsq0fKxi/GrGvW5EHyN/rGZmcTZE5JJ/+ vTDCumuEIyda5Rc3SS1bmQMdVEx31BDYzqTZoz2JQRff3BXy9rPGuBrkeNvMV+JU AOP1gZ3vlGRwHsUlCty+0gntatgNKnmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=YW4vlihnivfeKVcW2 19uy4w5mM+Al/00OLLQH6ZE4vY=; b=PrKsjnEMpGzjxtwL4u+XgrmaP9Vc/f11a cp+7Fb1zCtLN1JdP+jl+lMXb099qU3hlvvT1ScUSaw7jceQr9cH5hPOTX1733gdR 1tda/JZCVnlKN5bBjK8lpd7YRlA83yovnG55kxVqJQ4CGN52ULZtJ7dToqGbvXO2 2zheGA9S3rdNh0Ir+bpbiSbDwlErc4Tbxt1Nqgb608Df/xKvH8Ww3db1l7xBjuQQ 8oUaevgZuT8xXZvPqsrVfagQZf02QAv/6tFOTyUMp+6+1ukvCibO1FTQkCkc7viS yA5Tq3htybLU+RXJJLogUW1EM3B4ImoSp4tAWVkS5Da6Zde6S6/zw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjedvgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 14 Feb 2022 08:39:53 -0500 (EST) Date: Mon, 14 Feb 2022 13:39:51 +0000 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: <202112231500.1BNF0FgX014693@mail.karels.net> 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/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yvbsGnUqa/0Ioxb+" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Jy51r4fLBz521R X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b="TdZO/hKw"; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=PrKsjnEM; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.28 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 2296 Lines: 65 --yvbsGnUqa/0Ioxb+ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola wrote: >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola < >archimedes.gaviola@gmail.com> wrote: > >> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor >> wrote: >>> >>> > On 24 Dec 2021, at 02:25, Archimedes Gaviola < >>> archimedes.gaviola@gmail.com> wrote: >>> > Are you using the boot files that came with 13.0 (dtb, etc)? >>> > >>> > Yes, I am. I have not changed anything that came from 13.0 files, it's >>> all intact since I wrote the image to the microSD card. I might be wrong here - but I seem to recollect that there was some=20 issue with the pi4 and 13.0-RELEASE. I have only ever used snapshots=20 of that branch. If you go to the msdos partition of your installation and run strings on=20 start4.elf, what do you see? I saw this (from the last time installed 13-STABLE) # strings start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) --=20 J. --yvbsGnUqa/0Ioxb+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmIKW54ACgkQs8o7QhFz NAW6hA/+IAzdpqVvjOuZc/H2ZXXt5DLxBlQ1fTzn0kwW6LFBmQCsBZyEbha3stFb bU5byVP8JGX1j5VAbH+IGOuJSNQ5eJqkVSaFbbg1ExYQ5RBSRfmcU5SkrDv6IM8L g0EMwBuZdUrij6TkhfM7yQboXqtILzl0lX2lFT8ZIqegP7IdnOc3GWzwNIQ3mOT3 fORrxdlfC4VJrF8rKADuv90gbUXreT9Tw6aLbeVzJNzlgFwo+XNXOBKCiT329Lil 1ay9iHvm8T4V/zjPdsLpsp4GRY72FfU0zrMeUUMDzYhWu1688kxTY1C0jZIH6Jul uHDyfrv7FKCWElTcn1xz24TKBeJbF5tl0Z5w3xb+SrRT2/SgzClaHuLuoVdaatNF L8AgWS3SVIwMP2rMLV/aUTl3kU2Wn+U27i0SRjpKCfZOmkLat4WFfqjyC3pawR7f 9Gl5AX/N6mXcWjcgAjx7x3P4TlOGQGuQ0GV1MaAADb/uHcKnVo1y5sjY0Z65ZwVx YxP/nZJp4ptxtreajE8kCdnsayUeBJRn0GoFkvnIDdz+Enl58jIu7wCdtX9DmQZJ ccm9oItcPcv3lbpNNOCoC5aP1kPcCr30BYdjkUxR6DZ36JIg+nEka7NM0NsxNK2V r/SxiJHjUMIQxglBKeFApuaVoGLJPjiTJCZFklD8pN19kVUPlpg= =vNn5 -----END PGP SIGNATURE----- --yvbsGnUqa/0Ioxb+-- From nobody Mon Feb 14 13:58:28 2022 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 1364819CEEF8 for ; Mon, 14 Feb 2022 13:58:59 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 4Jy5Rk0L6hz54PR for ; Mon, 14 Feb 2022 13:58:58 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id u18so27127045edt.6 for ; Mon, 14 Feb 2022 05:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eaeJ+yUgDR7/AP9dvVoHA/zpDTRH0gHqJaQ1k2allXo=; b=dNF6/MOsPMXGErSQRhz3zLJLv/ig6xdmLGuw1RfTb5xpC5wSd373F4/7dRuzXCNt3V dcCG/PUxRSvVccFg5yVIF5v8VxgNIWGgM9sXyrxTnvPM+e6Q9qPjCQtBHKjZUNYQ2Ppv lLnvMtK4W85J7HmpxjImTxavqhBp6AbBzMn8/LIAjoo7MRrsbLLVTNQujaIbnLUgucOp +/W7LJbwXQ8hiIRejOp05dDhH6xvfEtjxCiNtOxYCptpQUdaKcMWJrp1IraKCh/0HPIn KwLxCUMbMHMLu5pcs27JXpH38od3iMdf2uAldaXuRMtffoLsNAcGkxqg9xqUUnmKrFQL suEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eaeJ+yUgDR7/AP9dvVoHA/zpDTRH0gHqJaQ1k2allXo=; b=qNOIoqZLDbKdg8KFpDkwKA74Ufrmo7I4etmg12q/ibTnJrwmO+VDsfGGglBwS2squM pFRMI2gIj3RKfsQLStVxNUA0NTZh2NZFNPYmRrB9vRe2eBPJwD3YpggXuYaflBJ1kt+H t7eJ0LUY+jPpGqE/74Mbf1NvZNNW79tgUZNPIRVxgeDnsudODpQSGbKKD/U5EhqB8wT0 GF61g3jgcAdhOJfpVabzr1Yy3n+hGTZenYVa6uzizopLmi9tcLExZ+tVhd2sdmfOp7ob eezdenoYl7PzjLwx1hkPDy6vja6v+rC12FgzfZAbQm5s+AlrV+2Kx7gEqoDKYfBaUlk2 qrtw== X-Gm-Message-State: AOAM531Ko4/I1qxGdhHxXHnQXdrl3HXLvYsOtn6/nqxF1ocE4GiX4Gp3 0SVYR1lw6VppK4cIMeuGDB5RViKsHiwJE+IcFx1B4lize3JvTQ== X-Google-Smtp-Source: ABdhPJxHZQnqjC8Szh3GpYtWFOLicq2rPKKU3GOD5QJB4Lii0QqEBZnYnr6v+gP+BG9j1rMlvYiGipPh+wei5J3BNok= X-Received: by 2002:a50:e701:: with SMTP id a1mr15239912edn.110.1644847131112; Mon, 14 Feb 2022 05:58:51 -0800 (PST) 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: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: From: Archimedes Gaviola Date: Mon, 14 Feb 2022 21:58:28 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000f5b7c005d7fad02a" X-Rspamd-Queue-Id: 4Jy5Rk0L6hz54PR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="dNF6/MOs"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-3.87 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.87)[-0.871]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4673 Lines: 125 --000000000000f5b7c005d7fad02a Content-Type: text/plain; charset="UTF-8" On Mon, Feb 14, 2022 at 9:40 PM tech-lists wrote: > Hi, > > On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola wrote: > >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola < > >archimedes.gaviola@gmail.com> wrote: > > > >> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor > >> wrote: > >>> > >>> > On 24 Dec 2021, at 02:25, Archimedes Gaviola < > >>> archimedes.gaviola@gmail.com> wrote: > >>> > Are you using the boot files that came with 13.0 (dtb, etc)? > >>> > > >>> > Yes, I am. I have not changed anything that came from 13.0 files, > it's > >>> all intact since I wrote the image to the microSD card. > > I might be wrong here - but I seem to recollect that there was some > issue with the pi4 and 13.0-RELEASE. I have only ever used snapshots > of that branch. > > If you go to the msdos partition of your installation and run strings on > start4.elf, what do you see? > > I saw this (from the last time installed 13-STABLE) > > # strings start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 12:10:40 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) > > -- > J. > Hi J, Here, it's the same with your output. freebsd@fbsd13:/boot/msdos % strings start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) Thanks and best regards, Archimedes --000000000000f5b7c005d7fad02a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 14, 2022 at 9:40 PM tech-= lists <tech-lists@zyxst.net&= gt; wrote:
Hi,
On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola wrote:
>On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola <
>archi= medes.gaviola@gmail.com> wrote:
>
>> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor <darius@dons.net.au>=
>> wrote:
>>>
>>> > On 24 Dec 2021, at 02:25, Archimedes Gaviola <
>>> archimedes.gaviola@gmail.com> wrote:
>>> > Are you using the boot files that came with 13.0 (dtb, et= c)?
>>> >
>>> > Yes, I am. I have not changed anything that came from 13.= 0 files, it's
>>> all intact since I wrote the image to the microSD card.

I might be wrong here - but I seem to recollect that there was some
issue with the pi4 and 13.0-RELEASE. I have only ever used snapshots
of that branch.

If you go to the msdos partition of your installation and run strings on start4.elf, what do you see?

I saw this (from the last time installed 13-STABLE)

# strings start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

--
J.

Hi J,

Here,= it's the same with your output.

freebsd@fbsd1= 3:/boot/msdos % strings start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER:= dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUIL= D_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOST= NAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VE= RSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
=C2= =A0
Thanks and best regards,
Archimedes
=
--000000000000f5b7c005d7fad02a-- From nobody Mon Feb 14 15:40:47 2022 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 8503C19BD644 for ; Mon, 14 Feb 2022 15:40:47 +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 4Jy7jC1lqsz3LmN for ; Mon, 14 Feb 2022 15:40:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 1C73B11880 for ; Mon, 14 Feb 2022 15:40:47 +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 21EFelYV043233 for ; Mon, 14 Feb 2022 15:40:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21EFelXN043232 for freebsd-arm@FreeBSD.org; Mon, 14 Feb 2022 15:40:47 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 261948] [boot] Loop of "Root mount waiting for: usbus0 CAM" on Oracle OCI Cloud Ampere A1 Compute instance Date: Mon, 14 Feb 2022 15:40:47 +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: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: szczepan@szczepan.net 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644853247; 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=kcOMLunzculDxe0e242sKSd6bQW02ZZQ+SmgdvTb6CM=; b=xc2cIlxNGhOrOL85GeZ3kp0UoJl0C2Hq70dVyQNdKNnWRsgwLWmUKmxqRAJvzCqlCF38bZ P1tjr5/JX6fIMlgxB0mZsuX/tezSv4KS/K0lu549O88gqyFCe14QRggJwDfG5D538bCmN6 4KQ9VirRki3zKV/8hw3HACcrdtsXJtcoxF3fCUjnV1WDAj2xTw5347Pcx8KZG0sZL6x6+/ rridaHBj3DtuQqby2CyHy2X4STba4oCZLpWFd3/HubTL4DxAmKlOZaL8rbY2ZGyIJETzwz S8fZfaekIispy/R0TyvdSz8F8CM5ZJppwQXgOqpZO4FCBaeoADauQi/QuOy/AQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644853247; a=rsa-sha256; cv=none; b=eYe7WPkyNWHCMkXQ1bz3NPuwl+FWMg6pkJ5CowtH7mDOdC5OU3VBOOJiPvmY4wpH+D+1hj a9J3XFqyuInlaXF0sKSEJV3bcEkfyEtxeMsdmRsyMcWu5fNSldcZq1Z1CH/1phQRnh0P6E GZMaJhVcPOw2W7QAISWLR0K1yPNSf9D87PAc1Znnr2Atjgkgcp126zvGpufTJtrd9RTz5Y nmvak9D3rtMWUHagpwhlLpxkW9GnoJQ7ykUOEpJYPuBuI92cPQcXJ+BYDGk+nB0j57HDK3 tE9CeJljFLYJba+en6ZoB2nZSsfs5cyMfnAeXlj4Ot2mPSYxoWZ8JRh0VoXLww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10201 Lines: 252 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261948 Bug ID: 261948 Summary: [boot] Loop of "Root mount waiting for: usbus0 CAM" on Oracle OCI Cloud Ampere A1 Compute instance Product: Base System Version: 13.0-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: szczepan@szczepan.net Trying to boot FreeBSD 13-STABLE / 14-CURRENT (also tried 13-RELEASE) - eff= ect is the same, after booting kernel, there's a stuck loop: Loading kernel... /boot/kernel/kernel text=3D0x2a8 text=3D0x84ad60 text=3D0x247f14 data=3D0x1= b92a8 data=3D0x0+0x40d000 syms=3D[0x8+0x133158+0x8+0x15a65a] Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! EFI framebuffer information: addr, size 0x0, 0x0 dimensions 0 x 0 stride 0 masks 0x00000000, 0x00000000, 0x00000000, 0x00000000 ---<>--- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2022 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-CURRENT #0 main-n253065-8dc42f98047: Thu Feb 10 06:40:36 UTC 2= 022 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. module firmware already present! real memory =3D 25766789120 (24573 MB) avail memory =3D 25096417280 (23933 MB) Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: WARNING: initial seeding bypassed the cryptographic random devi= ce because it was not yet seeded and the knob 'bypass_before_seeding' was enab= led. random: entropy device external interface MAP 6386b0000 mode 2 pages 80 MAP 638700000 mode 2 pages 80 MAP 638750000 mode 2 pages 80 MAP 6387a0000 mode 2 pages 80 MAP 6387f0000 mode 2 pages 192 MAP 6388b0000 mode 2 pages 96 MAP 638910000 mode 2 pages 160 MAP 6389b0000 mode 2 pages 80 MAP 638a00000 mode 2 pages 80 MAP 638a50000 mode 2 pages 240 MAP 63be20000 mode 2 pages 144 MAP 63bec0000 mode 2 pages 288 MAP 4000000 mode 0 pages 16384 MAP 9010000 mode 0 pages 1 kbd0 at kbdmux0 acpi0: acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: Could not update all GPEs: AE_NOT_CONFIGURED psci0: on acpi0 gic0: iomem 0x8000000-0x801ffff,0x80a0000-0x8ffffff on acpi0 its0: on gic0 generic_timer0: irq 34,35,36 on acpi0 Timecounter "ARM MPCore Timecounter" frequency 25000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 25000000 Hz quality 1000 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s pmu0: on acpi0 cpu0: on acpi0 uart0: iomem 0x9000000-0x9000fff irq 0 on acpi0 uart0: console (9600,n,8,1) pcib0: on acpi0 pci0: on pcib0 virtio_pci0: mem 0x10119000-0x10119fff,0x8000100000-0x8000103fff at device 1.0 on pci0 xhci0: mem 0x8000108000-0x800010bfff at device 2.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0 on xhci0 virtio_pci1: mem 0x10118000-0x10118fff,0x8000104000-0x8000107fff at device 3.0 on pci0 vtnet0: on virtio_pci1 vtnet0: Ethernet address: 02:00:17:00:1b:78 pcib1: mem 0x10117000-0x10117fff at device 16.0 on pci0 pci1: on pcib1 pcib2: mem 0x10116000-0x10116fff at device 16.1 on pci0 pci2: on pcib2 pcib3: mem 0x10115000-0x10115fff at device 16.2 on pci0 pci3: on pcib3 pcib4: mem 0x10114000-0x10114fff at device 16.3 on pci0 pci4: on pcib4 pcib5: mem 0x10113000-0x10113fff at device 16.4 on pci0 pci5: on pcib5 pcib6: mem 0x10112000-0x10112fff at device 16.5 on pci0 pci6: on pcib6 pcib7: mem 0x10111000-0x10111fff at device 16.6 on pci0 pci7: on pcib7 pcib8: mem 0x10110000-0x10110fff at device 16.7 on pci0 pci8: on pcib8 pcib9: mem 0x1010f000-0x1010ffff at device 17.0 on pci0 pci9: on pcib9 pcib10: mem 0x1010e000-0x1010efff at device 17.1 on pci0 pci10: on pcib10 pcib11: mem 0x1010d000-0x1010dfff at device 17.2 on pci0 pci11: on pcib11 pcib12: mem 0x1010c000-0x1010cfff at device 17.3 on pci0 pci12: on pcib12 pcib13: mem 0x1010b000-0x1010bfff at device 17.4 on pci0 pci13: on pcib13 pcib14: mem 0x1010a000-0x1010afff at device 17.5 on pci0 pci14: on pcib14 pcib15: mem 0x10109000-0x10109fff at device 17.6 on pci0 pci15: on pcib15 pcib16: mem 0x10108000-0x10108fff at device 17.7 on pci0 pci16: on pcib16 pcib17: mem 0x10107000-0x10107fff at device 18.0 on pci0 pci17: on pcib17 pcib18: mem 0x10106000-0x10106fff at device 18.1 on pci0 pci18: on pcib18 pcib19: mem 0x10105000-0x10105fff at device 18.2 on pci0 pci19: on pcib19 pcib20: mem 0x10104000-0x10104fff at device 18.3 on pci0 pci20: on pcib20 pcib21: mem 0x10103000-0x10103fff at device 18.4 on pci0 pci21: on pcib21 pcib22: mem 0x10102000-0x10102fff at device 18.5 on pci0 pci22: on pcib22 pcib23: mem 0x10101000-0x10101fff at device 18.6 on pci0 pci23: on pcib23 pcib24: mem 0x10100000-0x10100fff at device 18.7 on pci0 pci24: on pcib24 virtio_pci2: mem 0x10000000-0x10000fff,0x8000000000-0x8000003fff at device 0.0 on pci24 vtscsi0: on virtio_pci2 acpi_button0: on acpi0 armv8crypto0: Timecounters tick every 1.000 msec CPU 0: ARM Neoverse-N1 r3p1 affinity: 0 Cache Type =3D <64 byte D-cacheline,64 byte I-cacheline,= PIPT ICache,64 byte ERG,64 byte CWG,IDC> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D Processor Features 0 =3D Processor Features 1 =3D Memory Model Features 0 =3D Memory Model Features 1 =3D Memory Model Features 2 =3D <32bit CCIDX,48bit VA,UAO,CnP> 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 Neoverse-N1 r3p1 affinity: 1 CPU 2: ARM Neoverse-N1 r3p1 affinity: 2 CPU 3: ARM Neoverse-N1 r3p1 affinity: 3 Release APs...usbus0: 5.0Gbps Super Speed USB v3.0 done Trying to mount root from ufs:/dev/gpt/rootfs [rw]... WARNING: WITNESS option enabled, expect reduced performance. ugen0.1: <(0x1b36) XHCI root HUB> at usbus0 uhub0 on usbus0 uhub0: <(0x1b36) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub0: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 CAM ... ... ... usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT ugen0.2: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 CAM ... This is VM running on Oracle Cloud, using Arm processor from Ampere. Tried setting diffrent variables before booting kernel, ex.: kern.cam.boot_delay=3D10000 vfs.root_mount_always_wait=3D1 hw.usb.no_boot_wait=3D1 No change. I have working Linux on this machine, so can provide more info if needed.=20 Any way to get this to boot somehow? A cut from dmesg from another VM, this one is running on amd64 host: WARNING: WITNESS option enabled, expect reduced performance. ugen0.1: at usbus0 Trying to mount root from ufs:/dev/da0p2 [rw]... uhub0 on usbus0 uhub0: on usbus0 pass0 at vtscsi0 bus 0 scbus2 target 0 lun 0 pass0: Fixed Uninstalled SPC-3 SCSI device (offline) pass0: 300.000MB/s transfers pass0: Command Queueing enabled da0 at vtscsi0 bus 0 scbus2 target 0 lun 1 da0: Fixed Direct Access SPC-4 SCSI device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 47694MB (97677312 512 byte sectors) (da0:vtscsi0:0:0:1): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. uhub0: 2 ports with 2 removable, self powered ugen0.2: at usbus0 This one also got similar loop problem when using 13-RELEASE, but tried 13-STABLE and 14-CURRENT (both latest) and they work fine without any issue= s - so maybe it's qemu related? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Feb 14 21:41:22 2022 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 E7FC719B92CC for ; Mon, 14 Feb 2022 21:41:39 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyHjb1chTz4pyg for ; Mon, 14 Feb 2022 21:41:39 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [10.0.1.27] (hs-nc-6b363c0412-470382-1.tingfiber.com [64.99.197.86]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id 21ELfRVe008540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Feb 2022 21:41:32 GMT (envelope-from swills@FreeBSD.org) Message-ID: Date: Mon, 14 Feb 2022 16:41:22 -0500 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: Steve Wills Subject: RockPro64 PCI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 14 Feb 2022 21:41:32 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=KHOP_HELO_FCRDNS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4JyHjb1chTz4pyg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2607:fc50:0:4400:216:3eff:fe69:33b3 is neither permitted nor denied by domain of swills@FreeBSD.org) smtp.mailfrom=swills@FreeBSD.org X-Spamd-Result: default: False [-3.07 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[swills]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_SHORT(-0.97)[-0.969]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 694 Lines: 24 Hi, Having gotten past my U1 SD card issue, I've now booted the 14-CURRENT snapshot from Feb 10 successfully. But the PCI doesn't seem to be working right: pcib0: mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0 pcib0: Gen1 link training timeouted: 0x00080001. pci0: on pcib0 pcib1: at device 0.0 on pci0 pcib0: failed to reserve resource for pcib1 pcib1: failed to allocate initial memory window: 0-0xfffff pci1: on pcib1 Is this expected? I'm trying to use a fairly generic Intel NIC with it, but I notice the wiki only lists some odd IBM and Fujitsu NIC that have been tested. Cheers, Steve From nobody Mon Feb 14 22:22:33 2022 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 287A419C23ED for ; Mon, 14 Feb 2022 22:23:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (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 ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyJdF5rRqz3D2w for ; Mon, 14 Feb 2022 22:22:57 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21EMMbNv001308 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 15 Feb 2022 08:52:37 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1644877363; bh=DyH/6cOrBvFNicySGUjkRHSS+bJ9Pa6loAdwkNBrXbE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EBN7aYbAvYIP3qHyIX0o1nvkE+Ksram4mu0g35KKEnJ+6nOQRk3TDSa0b0QFTlCns a1QUStCowwLmzgqjegxWmJ68KZpMnLzbpkHJhfzHCFy7Qjxx+PtJ+R3YIVq+AW3Td3 QglcqI037Cscr4Odj7lZ8m81ijUcbQrxBdD1Vlcc= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21EMMYRx001305 for ; Tue, 15 Feb 2022 08:52:34 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:71db:5efa:17ee:434c Received: from smtpclient.apple (2403-5800-5200-4700-71db-5efa-17ee-434c.ip6.aussiebb.net [2403:5800:5200:4700:71db:5efa:17ee:434c]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21EMMYao001298; Tue, 15 Feb 2022 08:52:34 +1030 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 15.0 \(3693.40.0.1.81\)) Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 From: "Daniel O'Connor" In-Reply-To: Date: Tue, 15 Feb 2022 08:52:33 +1030 Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202112231500.1BNF0FgX014693@mail.karels.net> To: Archimedes Gaviola X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.6 () No, score=0.6 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JyJdF5rRqz3D2w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=EBN7aYbA; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1572 Lines: 35 > On 14 Feb 2022, at 23:10, Archimedes Gaviola = wrote: > I just tried my new RPI4 board and it seems to work fine the same as = my old board. I just observed that the problem is when my VFD (vacuum = fluorescent display) device is connected to either of the two USB 3.0 = ports, this device having uplcom(4) driver is not detected. I wonder if the VFD is causing interference - it likely has a high = voltage supply and those are notorious for generating electrical noise. > It's a Prolific USB-serial device having PL2303 chipset. However, when = plugged-in to USB 2.0 ports, this device is detected and functioning. I = can send characters with the echo command and redirect it to /dev/cuaU0 = for display without any problem. Other observations when this VFD device = is connected to either 3.0 ports, the 2.0 ports will not function i.e. = plugging-in any USB devices like my keyboard or my EMV reader. When this = device is also connected to either of the 2.0 ports, the other 2.0 port = is functioning for other USB devices while 3.0 ports are not. I attached = two dmesg outputs when the device is detected with 2.0 ports and = undetected with 3.0. I also include kldstat and usbdump. I would be curious if putting the VFD on a longer cable, or wrapping the = cable through a ferrite, or using an external hub fixes it. Any of those would give a bit more isolation between the VFD and USB3 = hardware. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Tue Feb 15 02:22:06 2022 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 DA82219C85AC for ; Tue, 15 Feb 2022 02:32:49 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyQ9W6xrXz4SYF; Tue, 15 Feb 2022 02:32:47 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: from relay7-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::227]) by mslow1.mail.gandi.net (Postfix) with ESMTP id 16502C6107; Tue, 15 Feb 2022 02:22:18 +0000 (UTC) Received: (Authenticated sender: daniel.engberg@pyret.net) by mail.gandi.net (Postfix) with ESMTPA id 9B3F420003; Tue, 15 Feb 2022 02:22:06 +0000 (UTC) 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 Date: Tue, 15 Feb 2022 03:22:06 +0100 From: Daniel Engberg To: freebsd-arm@FreeBSD.org Cc: swills@FreeBSD.org Subject: Re: RockPro64 PCI Message-ID: X-Sender: diizzy@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JyQ9W6xrXz4SYF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 217.70.178.240 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; FREEFALL_USER(0.00)[diizzy]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_TLS_LAST(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:4b98:dc4:8::227:server fail,217.70.178.240:server fail]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 356 Lines: 10 Hi, I've seen some reports on Linux that especially older NICs can be a bit troublesome so can you have a look at what you exactly have? Even if it doesn't work I'd like to add it to the wiki. Cards based on i340 and i350 usually works fine though. I also have a snapshot of 13-STABLE from November if you want to give it a try. Best regards, Daniel From nobody Tue Feb 15 03:49:24 2022 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 8A4F4194C09D for ; Tue, 15 Feb 2022 03:49:26 +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 4JyRsx4rFyz4bbV for ; Tue, 15 Feb 2022 03:49:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 21F3nP7M046197 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Feb 2022 19:49:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 21F3nPV3046196; Mon, 14 Feb 2022 19:49:25 -0800 (PST) (envelope-from fbsd) Date: Mon, 14 Feb 2022 19:49:24 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Pi3 answers ssh only if outbound ping is running on -current Message-ID: <20220215034924.GA46139@www.zefox.net> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@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: 4JyRsx4rFyz4bbV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=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 X-Spamd-Result: default: False [0.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-arm]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 3271 Lines: 77 On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote: > > Recommended experiment . . . > > Since I have a context working based on the kernel in: > > https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a028c372d4ac4f72b503/arm64/aarch64/kernel.txz > > I recommend that you try that exact same kernel in your > stable/13 context. I recommend renaming the existing > /boot/kernel before expanding the kernel.txz into / and > so causing a new /boot/kernel/ to be filled in. > > If that makes things work after rebooting, then your > kernel can be blamed. (More investigation to know more > about what is going on in your kernel build.) > Replacing first the kernel and then the dtb directory didn't change the machine's response to incoming pings. The stable/13 machine does answer ping sporadically during boot, but falls silent once it's up to multi-user. Starting an outbound ping seems to allow incoming pings to be answered, but only very briefly. With inbound pings coming at 1 per second and outbound pings at 1 per ten seconds less than ten percent of incoming pings get an answer. There's a superficially similar situation described in https://forums.freebsd.org/threads/strange-tunnel-behavior.27804/ except that I'm not (knowingly) using any sort of tunnel, and in my case single pings do occasionally get answered on their own. The misbehavior in that case is attributed to packet filtering. Near as I can tell it isn't present on my machine, with one hesitation: By default, FreeBSD supports DHCP, which I believe once used bpf. I've never explicitly turned DHCP off, merely commented out the ifconfig line in /etc/rc.conf and added an ifconfig line to bring up a static address. Is it possible there's a packet filter running in the background? Perhaps under another, newer name? There's no /dev/pf, but there is a /dev/pfil, described as a packet filter interface. The man page notes "In FreeBSD 13.0 the interface was significantly rewritten." The man page is dated January 28, 2019, so it's old news. /etc/defaults/rc.conf contains ipfilter_enable="NO", so it's unclear why there's a /dev/pfil present at all. Perhaps via some other service? Making sure packet filtering is turned off seems like a good thing to try. Can't find a way to do that via looking in /etc/defaults/rc.conf > But if the above does not make things work, that points > to investigating alternate worlds from: > > https://artifact.ci.freebsd.org/snapshot/stable-13/. . . > > That is a messier context. I only do that with media that Indeed, I'm not sure I'm up to that level of messing...... It looks clear that mine is a local problem, doubtless self- inflicted, most probably from using removable flash media as swap. It'd be comforting to know for sure, of course. > I can delete everything on, such as an independent microsd > card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various > tar -xpf ???.txz -C /mnt/ commands --while not booted from > the microsd card. Repeat for each snapshot tried. At this point it's tempting to try the oldest stable/13 kernel available on artifact.ci.freebsd.org, if that makes no difference it's time to start with a fresh install image. Thanks for reading, and all your help! bob prohaska From nobody Tue Feb 15 05:21:02 2022 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 619D519BD21C for ; Tue, 15 Feb 2022 05:21:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyTvt3Xlbz4lND for ; Tue, 15 Feb 2022 05:21:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644902467; bh=pPWE4TrizQQzFlK4mXHMqkyXf1d55eBVtfeXEmU7BFI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dKeCndzt6UAqOKUUBe6nEJG225FLb8wXzihAeiEFTgtBulEm5n2n2HkLj2eZMlQauE6U/aI2l3kJaSuwffrPWOe4lVXWpmy5MPIYHeaNqOGcefubz8X3r15ETeRr25ZTWoAwjLUiFgSvAWdeAyvYgnHZPhMF0TFbOMu2OOV0coGB0A+UXk4LFUpd53W13sh96w7vZixvlU/sLr5aU18vDmuM1bjwiCRodMyGrzh1G5Bc3aEsRjkb2Bo1o4CkiIYid0KSuT2p4+FN2OFVvQdcB5ZFOhP2GC1HbsIGrixjqRVgAeYGnFsCYrAcKNF1SreMiwL+RxOyNhmNY10NRM8jYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644902467; bh=bh6g8LqtFC5hLt8fcaBb+R9/Z2lTRYkjGYaGdj/MFE0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=T4H7aK880FEuqRfRsUBgZpHFUNhqOzcbeZXukV8MYE4xOCHJSN4WZQCp756QbciTbY6Z95GUYO6CDcDa4ZpiGu2hxDYz5wVRObvlesPTymiWr0CRzPwNfwiQDt3iIGxNt9rbbbAYYOx7rJPo2smb1FYGk045Vzj8VZiVCVbtqU8B7IsVCVbtQFvvClJyFdJOh/ApJ2D1NLiMbOQcRbIZX7mFa0+y8SF7Li04vmdzyunMngAcdsdSFGXB3Tbsx0Gj2hbl2ZKob3kMZL4CLW8Ku4RaetgJLjpDGAQjhcofvKMjWGVhPAtfgomal3AXvG9BFpnHbixPWqwttfB7IStE8w== X-YMail-OSG: 8sHd7WEVM1mpcZ.tn5LCzrR1Tx5AoJFFOfkQzgk_3jtaRzsas.KM5BeEwkNmnI7 IKbW_z96FKoK_RsDTI7TeexSTZREDoVpEZ2uVXekN7rFib0ET6a2W0JWoBRiO9bp_DgsdSu2SkUv oWJqMd79C0sdnQnTheGt_jSdhYky1huh8dYludK9Q.ugqKY8Pgv518ZH7UxEDuuJ_y3G5D1zqvrk tYqzivzpcttpTgoajnPopTx4jMHruJnGtvm1KjhH4IHtRC8.3DXKQgbmikHbTLwEDZJ0OGbfq3Fp qK9iBhbNU15y2FMv_ENnewXNXYyv7CIUP8LM9l08I7SkH9XIrv4baT.GmFP4LAwCNfQ1_pI.686o 3lBFJT3DstjhinFRl8ouOubc_RkQIN6.uP3pAvkBDERZYRaeQDZnqhFE8hZTMk6b_WpPAf.sRQVD yb6S6aylGPU6CfD5uKBcssIxvxLorWmlFE4vQobt0abE.Q6Jr525guYpCimag4b2GerY4ntDTYTZ j4LbsM5OUuQgpAGCph6MGvc9OhWnBXLXzYjk61im7z.90tsiulSSKYlY_MVGUzTwd0TSUU_cJ5N9 cIjpLWrkeuBsDf6UeqHBGd89og0lSARal8TdjrbeWVWPLTFUf8Z4v2z.vayJJQksubLXVopg1kbA 03dBw8kvbInob0Q0XiSnopl7lBjgs43SUvFa44mcJLXSIp9ApaD66swwfZ3q5Okq_WkuiEc0E1Z5 F9LniBRDkOlFO1XwHNsyGVX6Sq5.tuMsvjDkpDA_IHKmHu9IdnZDhTFGw93KhteSZswde_8dC5JQ 1nznA465Auj_y9smBrsEXqTnwiiyqDVYKdHWzj6L3lJtYmCOXiGbaZ8xEIlN3C5vbgkkIalIHdN4 DNGaA8KOWU5oNRQa1mWSlDvJacHrRbfOuEwS4M6BY40FjsXy6hTUCYR5WqA4uPXpTcAboR5WFWvY KokjNext4MIeF1w.BQwOaQNYu_QcFFeXsYzuks2X5SiODidrF_qyrJDVTvHy43FRoc6Mlcm3RRXR Kfvsh2_jF0vrKURFl47TAl7trBDav04q0yE2DU39E3WfC.srGRmjaDmAdTEZcNL7rIYrZBZ9JReE zS4z9T9p6qxW28aosbuHbcj4jlpCrcEEm8SeMRm.uU7asIcYcKBiRQ4Ycx8K3vtFs1a4F5TIhYN9 d8CkJDWeoF8kCTwo3.UvaqZgbjnUXLRD_sAr_HL1gCUzxPWjAK2f6efOatYJ8bruEZJyigkIG8Tl A82bCdvxWblpsexz8g1MLUzq4swoa8MuTvGfyj6SM8G9BeAG5ElP50SsTEwc4oEwqbXFsDfC4.g8 PTtF9VsSEqWirvRUOWpKPzX7vWN0vz3vI6wasPPAXgjeovYsQ5PV6gkz_lpYJXig9geigDhjoCL8 92Vc_inYumZ3Nvr.lhMeKYXkZCq85vKXcQL4THfuZVADXXA_7guuV1geCm4PjR.siyimeUcPiEz6 fEG7gQJwJaT99zkXYWs6yDCfWMJ_TgEBzERpTvWsE86G_DsQxvJY23.f9upWeu8XoxsSmTfbNCRX M035CvU4oD.DEBtm6Es1VJjnBz1IAiBdKHW_v9.1Ywi7wAQJEp2nqb2Kl2WaJip_RTq8sdfE25CL zfXX100yurIsNV7Dk9dlvgKlNd6JLSj3GBnFi0jdV8Qed4PO69qbipmXVHVBRADb60c6dOxeOUMl a_WpispK.3_FMEY0xBcos4aRbUlOueTg3bLnxVxzNbZCDLVSi85BIFtMLh38isfKmplB7Y2rxFCj 0HERfiTWXz7FAjc9tdUA7dWzSzhOy0aT3pGzRdmqELoM5NGODViCBQR6PYhz06vs6KEQIvdbkdtj vKGISucNHKzqwIa9DvRIazicG15p_FahrNhRkbc5ATdt_39.4a5oclqJjadzwv.lOiYdWNjmQpzG jXo7_YKKMCAnCQPqEJwcByo9mPLE1vSLz4f7nrbGTSE6SeMnJbiDSErPjrMVj1KhYdoa5tIYn5d5 DU5FkE8t8ugUw1GaG4ZjmYxfSToCECZp6FDxc0pFXOitNtFMV.F3ejYYyTauyrhk9Qi8r1VL1gWG hsG634ey6BrwvSpGwiG.16x8mET3BkblTIOzW3vjtzQkiAsq3DSWvaVslg8xpGEIipLzTs4FN.H_ 9GKZKSuBuX55MXG0PMc.R8ozuzA3wT9lS_IRUGKHXSBmRiRqTjnZvzeONbZBbnd7MbvrCs3wJ_jn RPhfCQUe8jBUBr1JJmgP9mNKjSTQPhOwB0bipC9A2flPcJ83_sxqtQeEdietc47QK2._nqQ9IKTV 5DNUJgyfwZ71M4ODPna.mwLhGZKojeJoOM2mOofnBWm6W_XIXj.wp0THS1G2x1yWL1Z1N X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Feb 2022 05:21:07 +0000 Received: by kubenode520.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b9751899b9bd999c8233374309fc5a4b; Tue, 15 Feb 2022 05:21:04 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <20220215034924.GA46139@www.zefox.net> Date: Mon, 14 Feb 2022 21:21:02 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyTvt3Xlbz4lND X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dKeCndzt; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5394 Lines: 138 On 2022-Feb-14, at 19:49, bob prohaska wrote: > On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote: >>=20 >> Recommended experiment . . . >>=20 >> Since I have a context working based on the kernel in: >>=20 >> = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz >>=20 >> I recommend that you try that exact same kernel in your >> stable/13 context. I recommend renaming the existing >> /boot/kernel before expanding the kernel.txz into / and >> so causing a new /boot/kernel/ to be filled in. >>=20 >> If that makes things work after rebooting, then your >> kernel can be blamed. (More investigation to know more >> about what is going on in your kernel build.) >>=20 >=20 > Replacing first the kernel and then the dtb directory > didn't change the machine's response to incoming pings.=20 Intersting. > The stable/13 machine does answer ping sporadically during > boot, but falls silent once it's up to multi-user. Starting > an outbound ping seems to allow incoming pings to be answered, > but only very briefly. With inbound pings coming at 1 per=20 > second and outbound pings at 1 per ten seconds less than > ten percent of incoming pings get an answer.=20 >=20 > There's a superficially similar situation described in=20 > https://forums.freebsd.org/threads/strange-tunnel-behavior.27804/ > except that I'm not (knowingly) using any sort of tunnel, and in > my case single pings do occasionally get answered on their own. >=20 > The misbehavior in that case is attributed to packet filtering. > Near as I can tell it isn't present on my machine, with one=20 > hesitation: By default, FreeBSD supports DHCP, which I believe > once used bpf. I've never explicitly turned DHCP off, merely > commented out the ifconfig line in /etc/rc.conf and added an > ifconfig line to bring up a static address. Static addressing. Hmm. Could you configure an independent network with no router for a test, such as just an EtherNet cable between the 2 RPi*'s, no use of your normal network? (I've no clue what all this involves, if it is even possible. It would be good to know how to set up such a minimal-context test.) The point is to side step as much equipment as possible in order to see if something outside the RPi*'s is contributing. There may be a more reasonable approximation than the specifics I've suggested. > Is it possible there's a packet filter running in the background? > Perhaps under another, newer name? Besides the RPi*'s, what devices are processing the network packets? > There's no /dev/pf, but there > is a /dev/pfil, described as a packet filter interface. The man > page notes "In FreeBSD 13.0 the interface was significantly = rewritten." > The man page is dated January 28, 2019, so it's old news. >=20 > /etc/defaults/rc.conf contains ipfilter_enable=3D"NO", so it's > unclear why there's a /dev/pfil present at all. Perhaps via > some other service? Making sure packet filtering is turned > off seems like a good thing to try. Can't find a way to do > that via looking in /etc/defaults/rc.conf=20 Long ago I technically had an externally-static address but I still just used DHCP locally: The router had the static address but I'd set up to not expose the network. I'm not going to be any help with the things that you are referencing. >> But if the above does not make things work, that points >> to investigating alternate worlds from: >>=20 >> https://artifact.ci.freebsd.org/snapshot/stable-13/. . . >>=20 >> That is a messier context. I only do that with media that >=20 > Indeed, I'm not sure I'm up to that level of messing...... > It looks clear that mine is a local problem, doubtless self- > inflicted, most probably from using removable flash media as > swap. It'd be comforting to know for sure, of course. Part of the point of using a separate microsd card is to have an environment where blasting away the content and starting over is okay. I've been lucky for most of my testing: I could boot a fresh install and test without any significant configuration: defaults from installation were nearnly sufficient. But I've no clue if you could have that kind of test. Testing with defaults, instead of your normal configuration is also part of the point, sort of like avoiding other networking devices being involved. >> I can delete everything on, such as an independent microsd >> card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various >> tar -xpf ???.txz -C /mnt/ commands --while not booted from >> the microsd card. Repeat for each snapshot tried. >=20 > At this point it's tempting to try the oldest stable/13 > kernel available on artifact.ci.freebsd.org, Well that would be when 13-CURRENT was first branched to make stable/13 and 14-CURRENT, before releng/13.0 existed. ( stable/13 predates releng/13.0 .) I'd not try a modern world going back that far: I'd also use an old world. Again, I suggest an independent media, such as a microsd card that is then separately booted and used for the testing. Well, 2 microsd cards so both systems are using defaults. > if that makes > no difference it's time to start with a fresh install image. I'd test such on separate media first. If it still has the problem, why destroy the original context and deal with the extra associated activity? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 15 05:56:28 2022 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 02A0519C3095 for ; Tue, 15 Feb 2022 05:56:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyVhf60mlz4p6P for ; Tue, 15 Feb 2022 05:56:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904592; bh=2oPLYfHDtCoxWAD06hCdm6XJ21Sy72aflt3+z/xK7ng=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CvJ2aIEx9Qxd7YTHARdiLtR6UrdvAEoksWQe0KH9sVrZqYy2JgFWKZ7UdTLzqjdVERykeQ+FHs90NFJdjLPVKzvUCEUtm0Td7hWIiNPX5ZV9H94cA4IXpbuFkaKUcMROroxjTddY7mMPCe4qaliC7QjDhcSSsmxl+L1cllanoI4jzUYxD9yfPVqXAoOBjU/R8tzbLsixDrlTrH2bPOQVlTOTGSirGzlU9F8tZg+jg0QirgtER9o9gzAb47kH7dkmyUFRNYNIhlZjfOXDCuOMI945H6w3/aPlFe1PXl77KlvQ5v3/nIWhlbtRCNTJUNOJYmDzjCzxdiiz+QpM5Jq7Nw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904592; bh=Q1ri8vGIXHBbRNyCqMX6x1oN40DksZqqINdj7LGeaAl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=J1Mj2Lsfkp+D+EjIhIHGFFwyDjBnPiMnC9d04KyI1fQL40WLLAz+ZomajBWv8Q/T+9c2Y61lwA/DYK9se8Ub9qasxGnU+m4TiJHood1C6Slhn7vgSSlFEHMeKOGD76wgiWvv2jMokz38Scd32HnpiA7+slAYC+BSPPsE9L9cJ+8kMZJI6eMU1lN/yzBqe2vorWNlMJCYvidyvVnyXPz8qLhkjtegzeQ/9BXuFPr3A+Ul3dekOfrfY7gX3jb1uX/2IrgynwQ84zbOdpxIPJOEOTaOd0JrtOn13vHCSYzrqDQyMNL+ZR0nDnM8Y54+YL+VP0vBZPsfECYUI7PeeGOSPw== X-YMail-OSG: yEbSgvgVM1nhOzCNAPg7xm62dZtTR2E7bTjxOcXSF4a6AeJMcWg_i0P2JAXfPFv nsxvgXyu38Kq_r3rlB60jS3SEkA0br4P1YAv5jCfZSowaNI8.imKK_UyiD6xKf5yWxHmtp_P5tZ5 Rzp7zeQ.HcIU4fnLKOSGbAnFUJXyhwgcrxM30_IwKBJWfphLte2Qp6oZ.iIFGoZZxTF4MnVFvxD3 Lp60PQy91dL4caG0Eo6HTry4BjISSVT_wsbm6hBDw39ddvtFUWJsdMcKSLejyCq_PJ_nWL1Gw7ku B0t_5n.FGwEhlHeoksvh3PNnZq.nHW0tXil3i56qhLjtmIHuQeU0Cm0zTkviCuU81oU3eXabDFbD Ylh_IPtqRPh_XJYwED8mweBmAzvH26HmdSVZa166Q4gux3v6ziY3_DCO.DOKc1vzsVPrLWg6etgN k4gky4.8VG5uKn1FW4ykmG3csZNlzGa94kQDMEfXMq.EIlmXr6j73T2kwYHh6t6CG2uqvkim2KfN Xx_.yZijNUeQJaKQ1I1iBkWQ3wRXSOfxo45pOw6nqaAWUNJ__8DQ1v5PhHzz89W6S9SDpzGjNaEQ nFmiHGeO.9pBOTA0FZn3sxcF6cDvyJZfa9hV1P_XRVlyHmNGu82jWjjgt2v1RouWly6EC65dknXw NB0rleZJtXONI7CnKJYOAKHLdvCkSu_htQwnFCbVMzrnaxVBhAZw2GD94kjwwpewr9nneQkzudPk pkO5UU2bxhRsIGpNmQFuOFS_lbf_egQm042JhrEpICdHfOPfmHj1EEzY1qClKxnxLuq22uuctNW8 q.SmBeOTHbvIai5uYsFzxfvLcT.dy3G1ZQSlGX4x32XcK7fLKzPJXYP72I27q1zPDyVFh04G8g51 ZV3YR1nwZO_o94M1_y2INM77e2RmsH0zM6Cac8RjG6pv2Zv2iUK3RQ1lQwxhipwD01MgRx3uZga8 9Vv6myFlCoYG5TKuS6eMLXAtOQgee3cdGmigAm6ibtOCjW_zYdrJfSUUhMHKEAR_TnbiL1aQKX8z VyhCmsICF70E2gPBov7WITpN3P6j4vWi1ouG0t2TihuPXpAUpgaLQRl63oc0CeK9rbiyurEsde_l xRZ29PtQBRJOQUXMAC6Hd6ayfDVMhnvWopQ1J40Ewipbl3otWWGLC1juKqVC1pt59XdCBY9Fq.s3 .6ub.JI9W_7HRuVvTBHkCQ49d8YsY7Tky3Gxz9e63SO2wufSnwEPqFIUXWi0s8.OrwUwIRvCdgpp W0vWkPYgv36ZlKDt_a8OBMRbumaXM__byGpd5lEoumbXdZmCALzlXXkQ81mj7Rc.SCtZqS7zK3Uy kn6Ddn87BFEQCdFPcxPhnEJSe962Ngn7auIN5LXCqlS3iRlXROy4N9jrntjEB6aDw7Ik2VqeoM3f mrcrDDx6zfRXRjP9L0a5tkEItKSWbYYxrrVX3xpYpj8vmzASRRY9JhI0UdtH_EyotctTRxu6L8q3 GWXxUK84EtcU.ovHWHPJyAmx7FOlxcWLzSm6VC9ZbvXSiUYGl3wKUfP_xMkNxb0RqIYBIT8kouer O5own802uYRd6ihi2AEJaQMoDHuRb_KDKN09AaYyIv1JpGDQdp63.IEJ5uAhLoOraaI67NzFl3tT kzwVxYg7xQyobaOVtvdnCjr3N5AqeVd_v9hItCLrDYG5xKVV4Xvdvb5utt.GF7CxhqyvsMWoB1HI ej02qmUOb785Wel4BewrZOhhYctVvwLiXcgSbeb5FSH845UJ6CBKaBsfivltWQWwi0JONtNAEvNl Ifyo5abLC1qvwZufFAeNmvyYfYccsaWpthBQtDMdYGxiP9i94GgN5a_Oe7jCdIBsCn4AG9BHl8Au .hZhftUZAiOLst132igrxqfCp4CqlNGvMOvi6rLB0BBENCDVzmfi425XJJav.Mh_t5_vMtGRQWjp 3kG8BB0idHk.mrEYbn4CX04CJxW41m5Cpkpdf2YCZIyJzYljOx9_V38LdiUIJsySYbnd_EkkXe79 vhQvORfH4NnawOIq0bk3esjJRPHbBzILL8lJaS9BJB6R.U_83rn3Hd092p_JPpgTDrFanzpbIJwx 3FI9RxCE4lkkAHmN1nM3gizdjxI8m8SC11UGLrAum_IYFtA.QxgUPFCZA7O5yobxJ1bxfaw2lDyP 1LtkEipTcf1L57GHyLgJBl62yHJ6Chq1wtEV_9C3ItSmjBrf.PwxvW5E2OTyzS9P_wLuTfBCb3vb stsCezEPgc63HZhBkp5YxTbcqFu1TlG8IazyyDpHuC9P9_7d6D8fBehkVVCKcSNlnpLc3nye.25V XOvKv6yENJZBAkx9frH_ovMZMaPKg2InvFg51wqHGNAzGLqccGOYMBUy4vAT52OJElsCEdQ4l X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Feb 2022 05:56:32 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5d0b2449b0876b67e509121cd7f14a4c; Tue, 15 Feb 2022 05:56:30 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> Date: Mon, 14 Feb 2022 21:56:28 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyVhf60mlz4p6P X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CvJ2aIEx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6411 Lines: 164 On 2022-Feb-14, at 21:21, Mark Millard wrote: > On 2022-Feb-14, at 19:49, bob prohaska wrote: >=20 >> On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote: >>>=20 >>> Recommended experiment . . . >>>=20 >>> Since I have a context working based on the kernel in: >>>=20 >>> = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz >>>=20 >>> I recommend that you try that exact same kernel in your >>> stable/13 context. I recommend renaming the existing >>> /boot/kernel before expanding the kernel.txz into / and >>> so causing a new /boot/kernel/ to be filled in. >>>=20 >>> If that makes things work after rebooting, then your >>> kernel can be blamed. (More investigation to know more >>> about what is going on in your kernel build.) >>>=20 >>=20 >> Replacing first the kernel and then the dtb directory >> didn't change the machine's response to incoming pings.=20 >=20 > Intersting. >=20 >> The stable/13 machine does answer ping sporadically during >> boot, but falls silent once it's up to multi-user. Starting >> an outbound ping seems to allow incoming pings to be answered, >> but only very briefly. With inbound pings coming at 1 per=20 >> second and outbound pings at 1 per ten seconds less than >> ten percent of incoming pings get an answer.=20 >>=20 >> There's a superficially similar situation described in=20 >> https://forums.freebsd.org/threads/strange-tunnel-behavior.27804/ >> except that I'm not (knowingly) using any sort of tunnel, and in >> my case single pings do occasionally get answered on their own. >>=20 >> The misbehavior in that case is attributed to packet filtering. >> Near as I can tell it isn't present on my machine, with one=20 >> hesitation: By default, FreeBSD supports DHCP, which I believe >> once used bpf. I've never explicitly turned DHCP off, merely >> commented out the ifconfig line in /etc/rc.conf and added an >> ifconfig line to bring up a static address. >=20 > Static addressing. Hmm. Could you configure an independent > network with no router for a test, such as just an EtherNet > cable between the 2 RPi*'s, no use of your normal network? > (I've no clue what all this involves, if it is even possible. > It would be good to know how to set up such a minimal-context > test.) >=20 > The point is to side step as much equipment as possible > in order to see if something outside the RPi*'s is > contributing. There may be a more reasonable approximation > than the specifics I've suggested. >=20 >> Is it possible there's a packet filter running in the background? >> Perhaps under another, newer name? >=20 > Besides the RPi*'s, what devices are processing the > network packets? >=20 >> There's no /dev/pf, but there >> is a /dev/pfil, described as a packet filter interface. The man >> page notes "In FreeBSD 13.0 the interface was significantly = rewritten." >> The man page is dated January 28, 2019, so it's old news. >>=20 >> /etc/defaults/rc.conf contains ipfilter_enable=3D"NO", so it's >> unclear why there's a /dev/pfil present at all. Perhaps via >> some other service? Making sure packet filtering is turned >> off seems like a good thing to try. Can't find a way to do >> that via looking in /etc/defaults/rc.conf=20 >=20 > Long ago I technically had an externally-static address > but I still just used DHCP locally: The router had the > static address but I'd set up to not expose the network. >=20 > I'm not going to be any help with the things that you > are referencing. >=20 >>> But if the above does not make things work, that points >>> to investigating alternate worlds from: >>>=20 >>> https://artifact.ci.freebsd.org/snapshot/stable-13/. . . >>>=20 >>> That is a messier context. I only do that with media that >>=20 >> Indeed, I'm not sure I'm up to that level of messing...... >> It looks clear that mine is a local problem, doubtless self- >> inflicted, most probably from using removable flash media as >> swap. It'd be comforting to know for sure, of course. >=20 > Part of the point of using a separate microsd card is > to have an environment where blasting away the content > and starting over is okay. >=20 > I've been lucky for most of my testing: I could boot a > fresh install and test without any significant configuration: > defaults from installation were nearnly sufficient. But I've > no clue if you could have that kind of test. >=20 > Testing with defaults, instead of your normal configuration > is also part of the point, sort of like avoiding other > networking devices being involved. >=20 >>> I can delete everything on, such as an independent microsd >>> card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various >>> tar -xpf ???.txz -C /mnt/ commands --while not booted from >>> the microsd card. Repeat for each snapshot tried. >>=20 >> At this point it's tempting to try the oldest stable/13 >> kernel available on artifact.ci.freebsd.org, >=20 > Well that would be when 13-CURRENT was first branched to > make stable/13 and 14-CURRENT, before releng/13.0 existed. > ( stable/13 predates releng/13.0 .) I'd not try a modern > world going back that far: I'd also use an old world. I got that wrong: the artifacts history does not go back that far. Looking just now, I found: author Konstantin Belousov 2021-10-19 21:25:19 = +0000 committer Konstantin Belousov 2021-10-26 = 02:26:27 +0000 commit 485cc5549c3b383c6158bf47ac40c8002e276666 (patch) tree 162311b2a8e477f078823137491e30110671bd90 parent 59447a02f1a9083f37d8e1e0d75bbb76ccb669d6 (diff) download src-485cc5549c3b383c6158bf47ac40c8002e276666.tar.gz src-485cc5549c3b383c6158bf47ac40c8002e276666.zip = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D485cc5549c3b383c61= 58bf47ac40c8002e276666 but it might not last long as old is dropped (when new is added?). It looks to go back somewhat over a year. > Again, I suggest an independent media, such as a microsd > card that is then separately booted and used for the > testing. Well, 2 microsd cards so both systems are using > defaults. >=20 >> if that makes >> no difference it's time to start with a fresh install image. >=20 > I'd test such on separate media first. If it still > has the problem, why destroy the original context > and deal with the extra associated activity? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 15 05:59:23 2022 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 58DC619C3D48 for ; Tue, 15 Feb 2022 05:59:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyVm92zKnz4pkR for ; Tue, 15 Feb 2022 05:59:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904770; bh=unaom/DynDZRFsKTic1XWSqunhgZ0yLn6p6pkTLE9tA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gS41CaEgvdA9hPqMlizQWXGXwqN7ZPU26LHN4AUpXf3tPjUqrK0v+j1t9PLvXUENawT6/so/BgxiDIglSIUTIKZ9G1duocQuWdvrgUfgv5cXHoBooQq7ih8iPL3Es3zyoNHNm8jxJdhymKxL8S6c+PHjBLrqDwwgXOU/hheFaP0WLU8xmm55Th79us9CaQNLlOKSmYJGimK8g1ee8YOFUIrjZGjS9QQ5gY1oPZ/SmsTZk6oviJgrfcofXFTIA7BDDZDaItWy45fJ+74iUCVyFVIsj0x7apzoX620Q/3EzmecpEvmy4DsGHA3bCHrObW1SAMSOeKz1MxNY4MkVT2sYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644904770; bh=kkJlA5tLhFMaUtnOaYh2B8vgouYLnGvaG5uKZmdqbgJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e+IDUVe2Iz92b5mHzdtKKVaUhjQxhmk/GzLjVRuDKNlYdWCuLe1m0fYnb6aCDyP5XjW66NGFBI+RDOnN/lCZ2xSx7PexUtXMlizRsEizhG/Qy97+5/7IEQy7TsoMTHkRxIxAMazunO5FWBTt4wo7R6+hzOXo5ACITzwKNh9JrbCZbOt4Je+8SHAk+SIpfrLf6iIYycYpTtJUxHLRfQ/sGInQmEDA4bZnMZJZT0HF9oBWWIA1qN0ZgbfYdaJil7vMcOcZKLdFOM2sYulSvg9wD+jcw1d6l51A3ixTBm+OiBpeFmEaY3um59OK0GHIqL0/i28E2DqE2SZXD5nA2ihZwg== X-YMail-OSG: DghqqXMVM1nJ4KWJO6C4LXy0zlfaxSqC5hGlafjZ0JOZVmjXY74zEDApr0eb05P KeImwSZ0RPDd0EPev.zT5IfDAFFvro4RUlbMh5xdEsTUkUqLJnLecQLDMl34GmJ8voBQrkKzJ2mO mRXIEwg3fRkd.JkmUZNPVCV00h8qX4RdcGeLJK2jd0n6KLDi6nMJZr2SoVxmSuR90AuqK_bd3W6v jYUufwPunaxTGKRy.ZhYBri3HdNMifxGa6HqFr6GQ8RT2jLyJQ_x.NSqUHI2hDrRXl89xLgLsaR6 oWcXDrVEoT6ShyR9vRuk9lAOMBcfXv3uc_.soHUNKg_OXrdfYw1KbPOZ8KMJtXL.cFGcfqqSs2kb iOYRzFwCiuZ5pt1IxtjDfY07yX5MW2B7Gsis8m.KQWsT7j1S8IbAijUaLQn_Jhe4W9_Rt8UpPRYh OZlDPE5KSmqUohpbC9FG4q1ot73EU27J7jAKjPPdLEj4WoIi_fEIJf31HlXyD872AVWUIKVX0p85 IuyP2ApNrT5.X.y4.Dh.HP3zQGCDHeHpdvy8JtvirrJshCjZSN81IuGeDIb8vELxka13m54KESN2 xYotXEh_b.iFSbyUhv.Gbs1tT_Omc0hMGf5syYZjNG90rroCqjdY2BTpG6OI5AgBkimhOun.Q_tl iuTfZ3ATQiVml.CzzYoNTyC7UWIFI_OUnJYnLJSyRY58BMvDGkEDnVViYYtmn6InjTUL4apfXDS1 htaYNhN2EOGXwOqjgb5YQ3YbB7vbTG.hek6mNv1bKOfGixMIP385SQwTlYzPdYH1mZc3tbR29Ddo _HfSwVmNXQkGB86qXpOvAcnkx9N9Wy82NNFG9OMm6dJcpS5495Ry_VKNVf9TEc38LDW4qdQWAaL9 SjPz3SLrQO1hlSwQkk0ZRXtDbNGTVlQTmjkfPdZ3fX_tBj7em5IrgRYGZbce4fhSr2LrEqEMJT30 RO5DlNOHkDftk2SVm4f2nePv5GmmxIRV4Z4rX1ZDoqhAFhpjn9HkTwy9Zx7PEmIk0YB2TcWVM8mT bVbuUKM6shx5c63snxzErpLP9aK2tAwYPakJJ8rSvR_hbywVU2q794xFLKBGAINFxVnKA23At2M1 vQB4Q4WC6QutxtfXpK8RM83UpV303K0d4sztWra4hknYok1y6E7vxoJnuvivvCV4jA6l2UbBXijV ylrKnzlEWVZ0ynEw_0pvARfTXXXpuF2PnJ7wJgzKKwdxzQ27lorem3iCMa1CUACOUW2I3ksrh8_W o8Vj_HMoiM1vmE0PPpH8wGSY.MbOfGHypXCr2zGzB_kLzOAos3LQWHCQCiqXuMWvSyOUE1bTE2iR _97Q5MqAUeCLqNEuXPqyIYGRzK_8yNm1Mfe3QWHiPN5diMBb0_MlPAc_pGaAhvViD9nWZ0hXLJPc jtQxaJXbTT79f75h4iP_fIo26LSTz6aw7B.zSXEUT6stNHiHpENxaRLJkhIcZfBygXuFC7FyrfOM DgU9K7qqMEVFvhYC0otg2OpGUkPPEBSO4_FhGk37SsvntUnJ4CT6HYfrzJ4r5bNOtOWxLOfr6FoY qiCtgZG7qIwwm0FUtHvjil1QE_41EAyBV5wughtWnYnzTIdtSyRW7K8eB0Lp9xggQq2YAydnoh9u qZcT1EPrJTZa.m7v6BnZy1lZaDRQ.WAcuw6iyDpQ5ehxI8qZXtPC2PyZxdhbWPAQT1WJ7XqgEFfa XXYPl7h_fc0M6UHl1.uxd30gCCvRMna2mCiRAXlNKJ6hSnAl9Jc2tlT4GCsMGATg7JnAIQqYneZj I5u8kSWTvyS2khktPa.w23fhDPr2M_T6Q13mM7lxGuADbmIXx9IGP8Fpjv4bDGyweZE9sG3fdfMv rG8LS8X1UvkJ1cFuWaStlePx4E.M0HI3PAtMsBu0vdjzMS5TYoXCFxzIYQIBcIwBf.O841aevqfd 3_cpdAV7zO.Q7pLFlvxve50hWa8vgutRFMQBnEv0nsVm3L5Mho1OrZjQ8siSn.nrn6hD8oVfmqQs _ontrLZH..RDhob9rwsTiIleVGwdtqodT_RUgK4JwkAgqmuSokyv1PNSQCK4fsW.MMvZijDfUWPO nEGPVBoS.xV9fuBAhzlK2Le7IR3FCOTcjeVnj5Ky9Nhq_M3DSVobBvtnNFQjB9b105v.TqoQCX7e SDZK2iy2fOvhowOBi51LpwTn0NC6A6Asq4EcQQ5hCt0ftHY5Ev8Z4GREQFyGznBCjooR0Pbyf4If eUmJK05TgTgKaXFaW0uhi9W3YxTrHx2DsxCoDc5wA6plD78HJI8HYD7GDBnKvTm9mPSvqUYnFDpl 6ThsARNs7poYldaORh7brK6yhxUmR4QJcdYKAtXDBq0tpeLYsVZf4E8pt4QIWX9v.I9RU6ArkMw- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Feb 2022 05:59:30 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a5e37becaa31f5ae61b4c0740a8f335f; Tue, 15 Feb 2022 05:59:25 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Pi3 answers ssh only if outbound ping is running on -current From: Mark Millard In-Reply-To: <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> Date: Mon, 14 Feb 2022 21:59:23 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220212185618.GA37391@www.zefox.net> <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com> <20220215034924.GA46139@www.zefox.net> <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com> <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JyVm92zKnz4pkR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gS41CaEg; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6700 Lines: 169 On 2022-Feb-14, at 21:56, Mark Millard wrote: > On 2022-Feb-14, at 21:21, Mark Millard wrote: >=20 >> On 2022-Feb-14, at 19:49, bob prohaska wrote: >>=20 >>> On Sat, Feb 12, 2022 at 04:50:21PM -0800, Mark Millard wrote: >>>>=20 >>>> Recommended experiment . . . >>>>=20 >>>> Since I have a context working based on the kernel in: >>>>=20 >>>> = https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02= 8c372d4ac4f72b503/arm64/aarch64/kernel.txz >>>>=20 >>>> I recommend that you try that exact same kernel in your >>>> stable/13 context. I recommend renaming the existing >>>> /boot/kernel before expanding the kernel.txz into / and >>>> so causing a new /boot/kernel/ to be filled in. >>>>=20 >>>> If that makes things work after rebooting, then your >>>> kernel can be blamed. (More investigation to know more >>>> about what is going on in your kernel build.) >>>>=20 >>>=20 >>> Replacing first the kernel and then the dtb directory >>> didn't change the machine's response to incoming pings.=20 >>=20 >> Intersting. >>=20 >>> The stable/13 machine does answer ping sporadically during >>> boot, but falls silent once it's up to multi-user. Starting >>> an outbound ping seems to allow incoming pings to be answered, >>> but only very briefly. With inbound pings coming at 1 per=20 >>> second and outbound pings at 1 per ten seconds less than >>> ten percent of incoming pings get an answer.=20 >>>=20 >>> There's a superficially similar situation described in=20 >>> https://forums.freebsd.org/threads/strange-tunnel-behavior.27804/ >>> except that I'm not (knowingly) using any sort of tunnel, and in >>> my case single pings do occasionally get answered on their own. >>>=20 >>> The misbehavior in that case is attributed to packet filtering. >>> Near as I can tell it isn't present on my machine, with one=20 >>> hesitation: By default, FreeBSD supports DHCP, which I believe >>> once used bpf. I've never explicitly turned DHCP off, merely >>> commented out the ifconfig line in /etc/rc.conf and added an >>> ifconfig line to bring up a static address. >>=20 >> Static addressing. Hmm. Could you configure an independent >> network with no router for a test, such as just an EtherNet >> cable between the 2 RPi*'s, no use of your normal network? >> (I've no clue what all this involves, if it is even possible. >> It would be good to know how to set up such a minimal-context >> test.) >>=20 >> The point is to side step as much equipment as possible >> in order to see if something outside the RPi*'s is >> contributing. There may be a more reasonable approximation >> than the specifics I've suggested. >>=20 >>> Is it possible there's a packet filter running in the background? >>> Perhaps under another, newer name? >>=20 >> Besides the RPi*'s, what devices are processing the >> network packets? >>=20 >>> There's no /dev/pf, but there >>> is a /dev/pfil, described as a packet filter interface. The man >>> page notes "In FreeBSD 13.0 the interface was significantly = rewritten." >>> The man page is dated January 28, 2019, so it's old news. >>>=20 >>> /etc/defaults/rc.conf contains ipfilter_enable=3D"NO", so it's >>> unclear why there's a /dev/pfil present at all. Perhaps via >>> some other service? Making sure packet filtering is turned >>> off seems like a good thing to try. Can't find a way to do >>> that via looking in /etc/defaults/rc.conf=20 >>=20 >> Long ago I technically had an externally-static address >> but I still just used DHCP locally: The router had the >> static address but I'd set up to not expose the network. >>=20 >> I'm not going to be any help with the things that you >> are referencing. >>=20 >>>> But if the above does not make things work, that points >>>> to investigating alternate worlds from: >>>>=20 >>>> https://artifact.ci.freebsd.org/snapshot/stable-13/. . . >>>>=20 >>>> That is a messier context. I only do that with media that >>>=20 >>> Indeed, I'm not sure I'm up to that level of messing...... >>> It looks clear that mine is a local problem, doubtless self- >>> inflicted, most probably from using removable flash media as >>> swap. It'd be comforting to know for sure, of course. >>=20 >> Part of the point of using a separate microsd card is >> to have an environment where blasting away the content >> and starting over is okay. >>=20 >> I've been lucky for most of my testing: I could boot a >> fresh install and test without any significant configuration: >> defaults from installation were nearnly sufficient. But I've >> no clue if you could have that kind of test. >>=20 >> Testing with defaults, instead of your normal configuration >> is also part of the point, sort of like avoiding other >> networking devices being involved. >>=20 >>>> I can delete everything on, such as an independent microsd >>>> card: chflags -R noschg /mnt/ ; rm -fr /mnt/ ; various >>>> tar -xpf ???.txz -C /mnt/ commands --while not booted from >>>> the microsd card. Repeat for each snapshot tried. >>>=20 >>> At this point it's tempting to try the oldest stable/13 >>> kernel available on artifact.ci.freebsd.org, >>=20 >> Well that would be when 13-CURRENT was first branched to >> make stable/13 and 14-CURRENT, before releng/13.0 existed. >> ( stable/13 predates releng/13.0 .) I'd not try a modern >> world going back that far: I'd also use an old world. >=20 > I got that wrong: the artifacts history does not go back that > far. Looking just now, I found: >=20 > author Konstantin Belousov 2021-10-19 = 21:25:19 +0000 > committer Konstantin Belousov 2021-10-26 = 02:26:27 +0000 > commit 485cc5549c3b383c6158bf47ac40c8002e276666 (patch) > tree 162311b2a8e477f078823137491e30110671bd90 > parent 59447a02f1a9083f37d8e1e0d75bbb76ccb669d6 (diff) > download src-485cc5549c3b383c6158bf47ac40c8002e276666.tar.gz > src-485cc5549c3b383c6158bf47ac40c8002e276666.zip >=20 > = https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D485cc5549c3b383c61= 58bf47ac40c8002e276666 >=20 > but it might not last long as old is dropped (when new > is added?). It looks to go back somewhat over a year. Trying again: somewhat over 3 months. >> Again, I suggest an independent media, such as a microsd >> card that is then separately booted and used for the >> testing. Well, 2 microsd cards so both systems are using >> defaults. >>=20 >>> if that makes >>> no difference it's time to start with a fresh install image. >>=20 >> I'd test such on separate media first. If it still >> has the problem, why destroy the original context >> and deal with the extra associated activity? >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 15 08:13:38 2022 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 0643D19BC8E0 for ; Tue, 15 Feb 2022 08:13:58 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from out2106.sparkbusinessmail.co.nz (out2106.sparkbusinessmail.co.nz [122.56.84.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyYl80Lgtz3kr9 for ; Tue, 15 Feb 2022 08:13:54 +0000 (UTC) (envelope-from mjl@luckie.org.nz) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sparkbusinessmail.co.nz; s=alpha; t=1644912821; bh=LnYO/zv3o783cC3lCbjy52F+/wDBHP/WwDYx3rJry2I=; h=Date:From:To:Subject:Message-ID; b=eresd4XSTvjqEEAvVcMTN/TuCzqfhFc6xex5s1VdPmDC6noHse79gUmg3db8N5ssW eX2Ma0MG//UPVG+0rjMRuESVaMMR3lLrT2L+aOplTNMOopJ6darCmayPmXeqsZaFCG ZKUNtf/PE/Ny/ejJhc1WKm98w6qYePNSwpO1WZRs= SMX-Results: classifications=clean SMX-S1C: gggruggvucftvghtrhhoucdtuddrgedvvddrjeefgdduudeiucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuuffoigeuuhhsihhnvghsshenuceurghilhhouhhtmecufedttdenucenucfjughr peffhffvuffkgggtuggfsehttddttddtredvnecuhfhrohhmpeforghtthhhvgifucfnuhgtkhhivg cuoehmjhhlsehluhgtkhhivgdrohhrghdrnhiiqeenucggtffrrghtthgvrhhnpedtueetuddtjeff tddvtefhheetffeghfetvedtieffheefgfetgffhvdeihfehtdenucfkphepuddukedrleefrdduje elrdduieehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddukedrleef rddujeelrdduieehpdhmrghilhhfrhhomhepmhhjlheslhhutghkihgvrdhorhhgrdhniidpnhgspg hrtghpthhtohepuddprhgtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhg pdhmohguvgepshhmthhpohhuthdpshhpfhepnhgvuhhtrhgrlh SMX-S1V: clean SMX-S1S: 0 Received: from spandex.luckie.org.nz ([118.93.179.165]) by smtp.sparkbusinessmail.co.nz with ESMTP (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) id 620B60B3-2A952A55@mta2103.omr; Tue, 15 Feb 2022 08:13:41 +0000 Received: from mjl by spandex.luckie.org.nz with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nJsxu-000NwY-G9 for freebsd-arm@freebsd.org; Tue, 15 Feb 2022 21:13:38 +1300 Date: Tue, 15 Feb 2022 21:13:38 +1300 From: Matthew Luckie To: freebsd-arm@freebsd.org Subject: DLink DWM-222 revision A2 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 User-Agent: Mutt/2.1.5 (2021-12-30) X-Rspamd-Queue-Id: 4JyYl80Lgtz3kr9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sparkbusinessmail.co.nz header.s=alpha header.b=eresd4XS; dmarc=none; spf=none (mx1.freebsd.org: domain of mjl@luckie.org.nz has no SPF policy when checking 122.56.84.53) smtp.mailfrom=mjl@luckie.org.nz X-Spamd-Result: default: False [-4.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[sparkbusinessmail.co.nz:s=alpha]; RECEIVED_SPAMHAUS_PBL(0.00)[118.93.179.165:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[luckie.org.nz]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[sparkbusinessmail.co.nz:dkim]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[sparkbusinessmail.co.nz:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4648, ipnet:122.56.84.0/24, country:NZ]; RCVD_IN_DNSWL_LOW(-0.10)[122.56.84.53:from] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1581 Lines: 42 Hi, I purchased a DLink DWM-222 4G LTE USB stick, which is at revision A2 and requires new device IDs. I embed a patch below that has the new IDs. Its been more than 10 years since I've done make buildworld, and I would prefer not to buildworld -- the CPU is a low-powered Intel atom running an i386 kernel. Can someone let me know what the minimum set of steps I require to get a new u3g kernel module plus anything else necessary? If I have to buildworld, let me know. Thanks, Matthew --- usbdevs.orig 2022-01-12 20:35:11.417935000 +1300 +++ usbdevs 2022-02-15 20:54:11.843014000 +1300 @@ -1749,10 +1749,12 @@ product DLINK DWM157_2 0x7d0e DWM-157 product DLINK DWR510 0x7e12 DWR-510 product DLINK DWM222 0x7e35 DWM-222 +product DLINK DWM222_2 0x7e3d DWM-222 product DLINK DWM157_CD_2 0xa407 DWM-157 CD-ROM Mode product DLINK DWM157_CD 0xa707 DWM-157 CD-ROM Mode product DLINK DWR510_CD 0xa805 DWR-510 CD-ROM Mode product DLINK DWM222_CD 0xab00 DWM-222 CD-ROM Mode +product DLINK DWM222_CD_2 0xac01 DWM-222 CD-ROM Mode product DLINK DSB650 0xabc1 10/100 Ethernet product DLINK DUBH7 0xf103 DUB-H7 USB 2.0 7-Port Hub product DLINK2 RTL8192SU_1 0x3300 RTL8192SU --- u3g.c.orig 2022-01-12 20:35:08.878410000 +1300 +++ u3g.c 2022-02-15 20:55:30.705116000 +1300 @@ -242,6 +242,8 @@ U3G_DEV(DLINK, DWM157_2, 0), U3G_DEV(DLINK, DWM222_CD, U3GINIT_SCSIEJECT), U3G_DEV(DLINK, DWM222, 0), + U3G_DEV(DLINK, DWM222_CD_2, U3GINIT_SCSIEJECT), + U3G_DEV(DLINK, DWM222_2, 0), U3G_DEV(DLINK3, DWM652, 0), U3G_DEV(HP, EV2200, 0), U3G_DEV(HP, HS2300, 0), From nobody Tue Feb 15 08:32:33 2022 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 8BD2C19C000A for ; Tue, 15 Feb 2022 08:32:41 +0000 (UTC) (envelope-from SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JyZ8m33WZz3mjD; Tue, 15 Feb 2022 08:32:40 +0000 (UTC) (envelope-from SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl) Date: Tue, 15 Feb 2022 09:32:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1644913952; 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: in-reply-to:in-reply-to:references:references; bh=tY8hKhVLsS8HmSUTZZK7UMPNniZkzV5X+/Qk5uw7NcU=; b=w4D15h98QscjT+VEYq2MeWwGTpOlJpIQqWV3i4HNE6Qw9C1w0mFiXvhA0Ml5CumWMK7sGd 8C0qusYrcJxzJXpx0Lb1DXWrqoQLdmsjfRxOAUHXuBotvnvZtF2kch0kkuRZ+4omfsG+V1 QAKendQvL1fv0s3Bnpx/FSGxg+HDsKYQDRECM/8i2x6oKKIb1vlZ+QTG003zi4F8suVECj AHAOC8tVEhPPdkg2EQ0xFyhq4KnVaBY4Qp0wBaoXuxa5HVo8uM9Yv3zCiT3Ml4+9eJVSaX ahGqmvSiZmix1+Wi29a4TKExF9dWrrMpsoOJiPXsF7HjSVvJkmLW6XNBe6KOJw== From: Ronald Klop To: Philip Paeps Cc: clusteradm@freebsd.org, Ports Management Team , freebsd-arm@freebsd.org Message-ID: <180462427.61.1644913953734@mailrelay> In-Reply-To: <1666CD64-2A90-4BBC-9DEF-C9BCED4738FF@freebsd.org> References: <1365005114.369.1643120837534@localhost> <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org> <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org> <787825862.6.1644527984584@mailrelay> <1666CD64-2A90-4BBC-9DEF-C9BCED4738FF@freebsd.org> Subject: Re: aarch64 build cluster and linux64.ko 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="----=_Part_60_451488938.1644913953666" X-Mailer: Realworks (596.92.9412d29) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JyZ8m33WZz3mjD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=w4D15h98; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=6I0k=S6=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 10773 Lines: 223 ------=_Part_60_451488938.1644913953666 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Philip Paeps Datum: vrijdag, 11 februari 2022 02:25 Aan: Ronald Klop CC: clusteradm@freebsd.org, Ports Management Team , freebsd-arm@freebsd.org Onderwerp: Re: aarch64 build cluster and linux64.ko > > On 2022-02-11 05:19:44 (+0800), Ronald Klop wrote: > >> >> >> Van: Philip Paeps >> Datum: maandag, 31 januari 2022 04:15 >> Aan: Ronald Klop >> CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team >> Onderwerp: Re: aarch64 build cluster and linux64.ko >>> >>> On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote: >>> > On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote: >>> >> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded. >>> >> >>> >> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer >>> >> =======================>> >> >============================ >>> >> ===> linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found >>> >> ===> Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg >>> >> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009... >>> >> Cannot install package: kernel missing 64-bit Linux support >>> >> pkg-static: PRE-INSTALL script failed >>> >> >>> >> >>> >> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete? >>> >> >>> >> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded. >>> > >>> > We can include linux64.ko in the next cluster build for aarch64. I'll > try to find time for another cluster refresh. It's been a while since > the last one. >>> >>> I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko. The module seems to load. portmgr might need to do something to the builds to actually use it though. >>> >>> I'll upgrade the other aarch64 package builder when it finishes its current build. >>> >>> Philip >>> >>> -- >>> Philip Paeps >>> Senior Reality Engineer >>> Alternative Enterprises >>> >>> >>> >> >> Hi, >> >> Ampere1 as well as ampere2 are upgraded but I do not see the effect of linux64.ko being loaded. >> >> e.g. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c_s511b83b167/logs/errors/linux-c7-lz4-1.8.3.log : >> =================================================== >> ===> linux-c7-lz4-1.8.3 depends on package: linux_base-c7>=7.6.1810_7 - not found >> ===> Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg >> [main-arm64-default-job-13] Installing linux_base-c7-7.9.2009... >> Cannot install package: kernel missing 64-bit Linux support >> pkg-static: PRE-INSTALL script failed >> >> I can easily reproduce this error on my local poudriere by not loading the module linux64.ko. If it is loaded the linux-c7-* ports build fine. >> Having this fixed will give quite a lot less failed+skipped ports on aarch64. >> Who can I ask to check this? >> >> Regards, >> Ronald. >> > > > I have loaded the module on ampere1 and ampere2 and added linux64_load="YES" to their /boot/loader.conf files. I have also done this on the new ampere3 machine portmgr hasn't taken into production yet (I only installed that one yesterday). > > If that's all it takes, it should be picked up in the next build. If poudriere needs to be taught something ... that's really a portmgr task. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > Thanks Philip, Aarch64 packages for linux-c7-* are being build now! I like this a lot. One more question. Do you know why the arm64 package builds are not registered on https://pkg-status.freebsd.org/builds?type=package anymore? Because the pkg-status page has a nice way to compare two builds and spot regression (or progression). https://pkg-status.freebsd.org/builds/default:default:main-arm64:pbd2412a3b974_sac678b4aaf:ampere2 Regards, Ronald. ------=_Part_60_451488938.1644913953666 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Philip Paeps <philip@freebsd.org>
Datum: vrijdag, 11 februari 2022 02:25
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: clusteradm@freebsd.org, Ports Management Team <portmgr@freebsd.org>, freebsd-arm@freebsd.org
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-02-11 05:19:44 (+0800), Ronald Klop wrote:

 

Van: Philip Paeps <philip@freebsd.org>
Datum: maandag, 31 januari 2022 04:15
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: clusteradm@freebsd.org, freebsd-arm@freebsd.org, Ports Management Team <portmgr@freebsd.org>
Onderwerp: Re: aarch64 build cluster and linux64.ko

On 2022-01-26 08:58:20 (+0800), Philip Paeps wrote:
> On 2022-01-25 22:27:17 (+0800), Ronald Klop wrote:
>> Currently the packages depending on linux_base-c7 can not be >> pre-build on the package cluster because the kernel does not have >> linux64.ko loaded.
>>
>> See: >> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fpd8f8cc3a8823_s4f0e50b293%2Flogs%2Ferrors%2Flinux-c7-libpng-1.5.13_3.log&b=0&f=norefer
>> =======================<phase: run-depends    
>> >============================
>> ===>   linux-c7-libpng-1.5.13_3 depends on package: >> linux_base-c7>=7.6.1810_7 - not found
>> ===>   Installing existing package >> /packages/All/linux_base-c7-7.9.2009.pkg
>> [main-arm64-default-job-01] Installing linux_base-c7-7.9.2009...
>> Cannot install package: kernel missing 64-bit Linux support
>> pkg-static: PRE-INSTALL script failed
>>
>>
>> Is it possible to have linux64.ko loaded on the pkg builders so the >> aarch64 packages will be more complete?
>>
>> At least on my rpi4/aarch64 poudriere I could build pkg >> linux-c7-libpng with linux64.ko loaded.
>
> We can include linux64.ko in the next cluster build for aarch64.  I'll > try to find time for another cluster refresh.  It's been a while since > the last one.

I've upgraded one of the package builders (ampere1.nyi.freebsd.org) with a build including linux64.ko.  The module seems to load.  portmgr might need to do something to the builds to actually use it though.

I'll upgrade the other aarch64 package builder when it finishes its current build.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

Hi,

Ampere1 as well as ampere2 are upgraded but I do not see the effect of linux64.ko being loaded.

e.g. http://ampere2.nyi.freebsd.org/data/main-arm64-default/p4970d39a547c_s511b83b167/logs/errors/linux-c7-lz4-1.8.3.log : 
=======================<phase: run-depends    >============================
===>   linux-c7-lz4-1.8.3 depends on package: linux_base-c7>=7.6.1810_7 - not found
===>   Installing existing package /packages/All/linux_base-c7-7.9.2009.pkg
[main-arm64-default-job-13] Installing linux_base-c7-7.9.2009...
Cannot install package: kernel missing 64-bit Linux support
pkg-static: PRE-INSTALL script failed

I can easily reproduce this error on my local poudriere by not loading the module linux64.ko. If it is loaded the linux-c7-* ports build fine.
Having this fixed will give quite a lot less failed+skipped ports on aarch64.
Who can I ask to check this?

Regards,
Ronald.
 


I have loaded the module on ampere1 and ampere2 and added linux64_load="YES" to their /boot/loader.conf files. I have also done this on the new ampere3 machine portmgr hasn't taken into production yet (I only installed that one yesterday).

If that's all it takes, it should be picked up in the next build. If poudriere needs to be taught something ... that's really a portmgr task.

Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises



Thanks Philip,

Aarch64 packages for linux-c7-* are being build now! I like this a lot.

One more question.
Do you know why the arm64 package builds are not registered on https://pkg-status.freebsd.org/builds?type=package anymore?

Because the pkg-status page has a nice way to compare two builds and spot regression (or progression).
https://pkg-status.freebsd.org/builds/default:default:main-arm64:pbd2412a3b974_sac678b4aaf:ampere2

Regards,
Ronald.
  ------=_Part_60_451488938.1644913953666-- From nobody Tue Feb 15 08:56:21 2022 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 5947419C563F for ; Tue, 15 Feb 2022 08:56:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4JyZhQ4Brpz3qkh for ; Tue, 15 Feb 2022 08:56:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6AA0A2601F5; Tue, 15 Feb 2022 09:56:31 +0100 (CET) Message-ID: <97a0e1ee-85ec-7f78-2093-938466be0b75@selasky.org> Date: Tue, 15 Feb 2022 09:56:21 +0100 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:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: DLink DWM-222 revision A2 Content-Language: en-US To: Matthew Luckie , freebsd-arm@freebsd.org References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JyZhQ4Brpz3qkh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 1792 Lines: 48 On 2/15/22 09:13, Matthew Luckie wrote: > Hi, > > I purchased a DLink DWM-222 4G LTE USB stick, which is at revision A2 > and requires new device IDs. I embed a patch below that has the new > IDs. > > Its been more than 10 years since I've done make buildworld, and I > would prefer not to buildworld -- the CPU is a low-powered Intel atom > running an i386 kernel. Can someone let me know what the minimum set > of steps I require to get a new u3g kernel module plus anything else > necessary? If I have to buildworld, let me know. > > Thanks, > > Matthew > > --- usbdevs.orig 2022-01-12 20:35:11.417935000 +1300 > +++ usbdevs 2022-02-15 20:54:11.843014000 +1300 > @@ -1749,10 +1749,12 @@ > product DLINK DWM157_2 0x7d0e DWM-157 > product DLINK DWR510 0x7e12 DWR-510 > product DLINK DWM222 0x7e35 DWM-222 > +product DLINK DWM222_2 0x7e3d DWM-222 > product DLINK DWM157_CD_2 0xa407 DWM-157 CD-ROM Mode > product DLINK DWM157_CD 0xa707 DWM-157 CD-ROM Mode > product DLINK DWR510_CD 0xa805 DWR-510 CD-ROM Mode > product DLINK DWM222_CD 0xab00 DWM-222 CD-ROM Mode > +product DLINK DWM222_CD_2 0xac01 DWM-222 CD-ROM Mode > product DLINK DSB650 0xabc1 10/100 Ethernet > product DLINK DUBH7 0xf103 DUB-H7 USB 2.0 7-Port Hub > product DLINK2 RTL8192SU_1 0x3300 RTL8192SU > --- u3g.c.orig 2022-01-12 20:35:08.878410000 +1300 > +++ u3g.c 2022-02-15 20:55:30.705116000 +1300 > @@ -242,6 +242,8 @@ > U3G_DEV(DLINK, DWM157_2, 0), > U3G_DEV(DLINK, DWM222_CD, U3GINIT_SCSIEJECT), > U3G_DEV(DLINK, DWM222, 0), > + U3G_DEV(DLINK, DWM222_CD_2, U3GINIT_SCSIEJECT), > + U3G_DEV(DLINK, DWM222_2, 0), > U3G_DEV(DLINK3, DWM652, 0), > U3G_DEV(HP, EV2200, 0), > U3G_DEV(HP, HS2300, 0), > Can you send this as an attachment to me, and I'll take it? --HPS From nobody Tue Feb 15 10:47:29 2022 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 7CD3119BD436 for ; Tue, 15 Feb 2022 10:47:45 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 4Jyd8Y0b0Xz4Ydb for ; Tue, 15 Feb 2022 10:47:41 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id jg20so18365190ejc.3 for ; Tue, 15 Feb 2022 02:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPM/RDQWgMGO5YQkF2tChWodNuqzKuphiIi9YECE53g=; b=jEoRaReFhBZpWNK7Ci9KBm07A5tzjhFFFdGDKQGaBL+xvAempFc067y/COie7zqvUD IDy2gtPKfHQZMwl2LUJEshZbetv2xZPLhJtj2Bf2hU9/TA2zLPRVE/DcjsQWEFobHx0M qEwOzWJOrkK2jnsBtadBC9OOcnJ2Vibjh/TZul0wQFB5ST89eL+1HeJrahjDJyGUGOJT NhAnPLgWeJX/8taLIT9RQDiIXu0PcZeOI6WYi1asI3znNzkJNoYORDAe5SMhxLtUDghr h+MlTUFsmaXM05pVJdrP6GRaAUL4qwUG7xfRH8Wr8SGAe8VDM0E/lA8EuDXdZkcwVXx4 wgcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPM/RDQWgMGO5YQkF2tChWodNuqzKuphiIi9YECE53g=; b=Ynj8B/nL5ePxu5f70ZrYBFaNt3qHC86d1ujxZRRn174zuRIhZIvLaTzsmCjNZ1NQfk nG0kpu77BGWUDTcloccjfBDQK1WQlN0I7Zwit4TOuI9pwrc3que046/5SY9P/KIW/PxM lO6yYenBsP9F0RJ7VhchD3eMVC2Eltsd0GwkppmByq9ERd0G4cUloPl7q8W3C246ia9u 284UodQEu7yZA5QYcV4kHi446aw0rXR8DeoGi2FE9CvW8atdZCyDW3cBaLYfEAXBp5mx TMjOHrX/8sIud9T3kdoI+r0fKIQHZFP/pxpVPw+FqRrh+HXGyQCccpd2olKSpN+EwC+W tKWQ== X-Gm-Message-State: AOAM531n2WWcH2f2JD9IQFRYZCfMruQi96U1SrRvjyHDohPrCfrEv47C EvYGvGpyyYoXNW8IW9Y3/gWrwiJUB7JM8INts7UR566uPoCP8Q== X-Google-Smtp-Source: ABdhPJzwYFxAljaJB1gwoR5n9s3wY113+T7XeKH94dEpSrz6DO/ARhGGtu6cX0RnqfvZgv1/lJeLTS1q6d4NT+hbLq8= X-Received: by 2002:a17:906:3f5b:: with SMTP id f27mr2538210ejj.62.1644922060033; Tue, 15 Feb 2022 02:47:40 -0800 (PST) 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: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: From: Archimedes Gaviola Date: Tue, 15 Feb 2022 18:47:29 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: "Daniel O'Connor" Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000012548405d80c4324" X-Rspamd-Queue-Id: 4Jyd8Y0b0Xz4Ydb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jEoRaReF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::62c:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5015 Lines: 96 --00000000000012548405d80c4324 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 15, 2022 at 6:22 AM Daniel O'Connor wrote: > > > > On 14 Feb 2022, at 23:10, Archimedes Gaviola < > archimedes.gaviola@gmail.com> wrote: > > I just tried my new RPI4 board and it seems to work fine the same as my > old board. I just observed that the problem is when my VFD (vacuum > fluorescent display) device is connected to either of the two USB 3.0 > ports, this device having uplcom(4) driver is not detected. > > I wonder if the VFD is causing interference - it likely has a high voltage > supply and those are notorious for generating electrical noise. > > > It's a Prolific USB-serial device having PL2303 chipset. However, when > plugged-in to USB 2.0 ports, this device is detected and functioning. I can > send characters with the echo command and redirect it to /dev/cuaU0 for > display without any problem. Other observations when this VFD device is > connected to either 3.0 ports, the 2.0 ports will not function i.e. > plugging-in any USB devices like my keyboard or my EMV reader. When this > device is also connected to either of the 2.0 ports, the other 2.0 port is > functioning for other USB devices while 3.0 ports are not. I attached two > dmesg outputs when the device is detected with 2.0 ports and undetected > with 3.0. I also include kldstat and usbdump. > > I would be curious if putting the VFD on a longer cable, or wrapping the > cable through a ferrite, or using an external hub fixes it. > > Any of those would give a bit more isolation between the VFD and USB3 > hardware. > Thanks Daniel for your recommendations, I've tried extending it to a long cable and using an external USB hub however the outcomes were still the same, it cannot be detected. As per checking, this device has a default ferrite bead clamped over its USB cable. Using the same RPI 4B hardware, this VFD device has been tested as well with OpenBSD 6.9 and CentOS 8. They both work with USB 3.0 except OpenBSD system will panic the first time you plug-in the device but will work fine after a forced reboot or when you unplug and plug back the power. Thanks, Archimedes --00000000000012548405d80c4324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 15, 2022 at 6:22 AM Daniel O&= #39;Connor <darius@dons.net.au= > wrote:


> On 14 Feb 2022, at 23:10, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
> I just tried my new RPI4 board and it seems to work fine the same as m= y old board. I just observed that the problem is when my VFD (vacuum fluore= scent display) device is connected to either of the two USB 3.0 ports, this= device having uplcom(4) driver is not detected.

I wonder if the VFD is causing interference - it likely has a high voltage = supply and those are notorious for generating electrical noise.

> It's a Prolific USB-serial device having PL2303 chipset. However, = when plugged-in to USB 2.0 ports, this device is detected and functioning. = I can send characters with the echo command and redirect it to /dev/cuaU0 f= or display without any problem. Other observations when this VFD device is = connected to either 3.0 ports, the 2.0 ports will not function i.e. pluggin= g-in any USB devices like my keyboard or my EMV reader. When this device is= also connected to either of the 2.0 ports, the other 2.0 port is functioni= ng for other USB devices while 3.0 ports are not. I attached two dmesg outp= uts when the device is detected with 2.0 ports and undetected with 3.0. I a= lso include kldstat and usbdump.

I would be curious if putting the VFD on a longer cable, or wrapping the ca= ble through a ferrite, or using an external hub fixes it.

Any of those would give a bit more isolation between the VFD and USB3 hardw= are.


--00000000000012548405d80c4324-- From nobody Tue Feb 15 12:35:50 2022 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 4C784194AD2F for ; Tue, 15 Feb 2022 12:36:04 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JygYZ2MjXz4mvx for ; Tue, 15 Feb 2022 12:36:02 +0000 (UTC) (envelope-from wb7odyfred@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644928555; bh=JOHtF3RzrLTvhspxBDiAtJEm4LmprZwsVl6Kq3x7tB8=; h=Date:To:Cc:From:Subject:References:From:Subject:Reply-To; b=mpx0hUTD4tVScGEFRvEez5yyODtVZh93F1vqKH6N97VlkLEOUb4TYMZfXWnZ1QZVU/XE03HXqgKSw5ib5nQg7rldmBp2DcOWeEbuTaZ/2xW3txlLMkNfMkPdhCWVnatbyrdh1GNoQvOMHj2fthdZqCGCppj3B25gb2u2Kzh00NGUhaHiYsrB7wJlNbDajVYkNwqtDWiELRnnbssevO6tEM6TXitWWMxoLiPlVRg8rZWoIKq7N1FMYaoATtYf5Wp4QcF63EbmggFS7Idma3TAdkBkezRJwk8BBNtnhNKUQY075GPHLPwlHxSlouTRIkHiXZqK7kUmsViX2CjSQVkL7w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644928555; bh=V/NAWlLf5baHfDA7YCF7TATE/gbqGzVF1wUPaTQSueq=; h=X-Sonic-MF:Date:To:From:Subject:From:Subject; b=lp/TNL1xAOc/OjQmD0N8HUxDREzWQcM+4UlrObB7m/goWxGgozoQPxl6MNc4Qj+SLPHVsufTecfcKiSoDkvfSqi9Zhx3iJvrB81ufZNfa205yl1mm1HMyAnutR4k8+12bGAs/Jf3UV85d8UXr+aXLQhlE2HvfzVIoIqY0xhMxQg+4zluadZSvWIyBRTFPX7mKAxEd/THsEJaaCMAd33eyuLAeEvFW/aO/uqUbS4UncZSdUqnv8POk92bljwEdAY23+zxNdFahs5tz+qzhvxBN+IdijJovqxXQZCQAWRBJNl1aQjAIytgfp1UAsGba+Ck15xeBA+SPcJvDh+Sw/aF1Q== X-YMail-OSG: 5tCZd2QVM1mMglvI7IzAOduMEOj_tD.UeVaDtSsGh1ABHl.R0mHWNA3xAP9p096 AgghoCB9iqGuhXm8iQlvbBF4Rjh9d_ZR_mZT3FcY2MtedJsVaBFgHhNsYexksi2tu8fUJrw1YWzJ cNbkaHcOSOEVl0TUHMu7gsC2229fRveH_NtXPOpd1taid.xXPhq_wXhVO3YoasTxDxexU52npx6n AiMGgCS5TMJ1PpEeFRQEx_hkAN8bBGdb8Vw0m_J32jJpiyLg1N3TWwIyWWr4LE9PC5iQurs9TqgQ Um.p3T84wcTEh4PrOVG5Ps.dVzVB2JRpPLGFjO1.KGE1MbrsA64Ea6NiCwRvd1Gcntj0_eFgr5m. oMSJ1XtmYdjueWekGF2WVtOejSOAU4QMImoEznyLEjMbGpsSVU5MBUEqfgnFL07JujyEt_dAjBWT MTvPs4zlQjTSogdGz_NxP0gqBjYixB3Wj8Xj9GShxh._XkHuFm0Eu0rYlJHexi22G1v.a3lpX5Sf IZUsY5yj6QG2TPAfSqiSnGuMR86HVhQ07ai36AEgQaOIxT09Q2xPxUumklzSi6T.PzJAxYCepIN6 brsfXh9DFamlImpaozB1_Er5gXapO7blgY1lkmcoPcIqKPK1FiX17Qe3N0Ewtwt8Ati.nJmwRqB9 f2FZ_q_j3RV31ly8ldlCJ1qLfpLXVYdKii1fJT3BfpqMEkPFNq8RvgGL7bevDG5hRwgxhWblvXfH wnphEoqtozmUnWH59d6UdCm0Df8QuQRRlTHKHfXDnkcJUpsL8MultwrYcSi7SOsBR3l5hHwdi234 k_jw.xcozUrLGxtInXBEkzmKGbEIYJvsmxlmgJbWev9Zc5SmK33.RbQrT1NpJilp3hnczcSTsEjy nL.bSPuN.0qQtxxocBUlQgr3aQQpwgRStA4tuKdkoi2Vw6aoNb1NXigSw4BuPS.ESnaJXAoXfIeB YAfQNkvrEmx98SPgKORDfkGJ4W15XD5IlYIRJVDgv0EH4vuu2g7C6N7mVYKUHJA1fDQ6maCpT6cl R1j221nAX2oo30929hbNaDNkKMuAZPX7Lo4mmqheZyeXvOopYPuV81udO4U5PK1zT6xboWYoPf3_ QlUuet_0_w9G142F0w8nHoW6OePnh_jwQrBHhTrwQzcPO25jwX5IAs8n9uiKfTcRQLljYKxB5uDO s8_iOvcdz345WpgzGgYMqUq9s9YAtNAcqSX_.llxOFG2uFV9OAXNJM6TPywY8yg_IC438DjAVL6h 8S_MTnN87dxsTVizj.oUsDKV3lZX2d7EqABptQNFbPM0OIaBLmgJIBdMedL6UTgnJmZ4F08ltzfC eU0Uv0EJNZFop3wVvHdntKEn5ZIzvCifkHFhAh3MDyIN6xkIhV3_CD9ZJ41l5_V7BJd.WgiTG48Z a2P5Ctn.636L3n4StZVMCAuvI335d.5VJZUXRWAggnxCdaCKPJyDc.7NHxUojPRBCUeHuCl8TwXu HMWhoWTpKGZDdqZBbJh_TcNFDvLxLWjdafAWEvXeK3Ti2Ug7kMJaUfjGU4QpwwN6WoiWahjR70BC 9H4RSAkIrRs1qFcyZv31Dz6qSMoIA1eotACAISIKdyUO_Dk49rSGPZkGkcugJ4.oYoTJulcRrbYV xw4Zh_u414TElVkWy2Q2QS2XcCkRQMKpSVJ._l0DERvaKM1OMr8olXC8R1qHDozRum7iJkcz8GaV TTy3lLjM3SAqJ4MTrEKt25V3kMFIPzh9vEDZL3jf76Zomy0WH.VzbwH9Raso3iuhfmBqVQC4Ige5 UL31NKTQ..NaWKUqvlifKjH2Mq0czcLILki96wvhOyOYLuGg_TRD9lr3zQKKJRrh57zMRqq3fLcp 8_InOAoHuuhVu33GCAjMhODwlOXdPfoEMpQY9y9ugSl2bPqfUDdkmriWeHK1rMKglc8Ct8te3MOz NQgdX6SsbdoWOVJO6CHkJQr65w07Oddd5PLuHY13rLw.IdKwPGSJU5TR0B1aXtq7B8W_NYOqY4Zv M9SBInTQeOnV_cquvbgJOZ_q77MUCaRoFj4E6CE.j.I54Z9T6KpwOLT27Nx9.I7f0_GMJLzyrDEu uF5m8EaDemY4k_aZiT7SE1w5A_TNZ81mGRtkPLPVfTP.5YHI6gYlwk.o_y2qfqATxvoifaD8GPIn r_T8UCGdjP80nkx2L.kns3PgGAQB5YQrcQiZlXp.YVpA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 15 Feb 2022 12:35:55 +0000 Received: by kubenode517.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 75ab58ce959db3666bbf50a42f36403a; Tue, 15 Feb 2022 12:35:52 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------GdlOlxsV1kNIZuoUv9U5qehf" Message-ID: <92b4a81e-5b86-2ece-bb75-f26230ec0992@yahoo.com> Date: Tue, 15 Feb 2022 04:35:50 -0800 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:91.0) Gecko/20100101 Thunderbird/91.6.0 To: archimedes.gaviola@gmail.com, freebsd-arm@freebsd.org Cc: fred@thegalacticzoo.com Content-Language: en-US From: Fred Finster Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use after April 1, 2021 version; or use 14.0 Current Organization: Kliktel References: <92b4a81e-5b86-2ece-bb75-f26230ec0992.ref@yahoo.com> X-Mailer: WebService/1.1.19724 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Rspamd-Queue-Id: 4JygYZ2MjXz4mvx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mpx0hUTD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of wb7odyfred@yahoo.com designates 74.6.135.41 as permitted sender) smtp.mailfrom=wb7odyfred@yahoo.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.135.41:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.135.41:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 15114 Lines: 250 This is a multi-part message in MIME format. --------------GdlOlxsV1kNIZuoUv9U5qehf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Use after April 1, 2021 version; Re: Raspberry Pi 4B does not detect devices in USB 3.0 Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use after April 1, 2021 13,0 stable version;  or use 14.0 Current From: Archimedes Gaviola > Date: Mon, 14 Feb 2022 21:58:28 +0800 On Mon, Feb 14, 2022 at 9:40 PM tech-lists wrote: > Hi, > > On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola wrote: > >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola < > >archimedes.gaviola_at_gmail.com> wrote: > > > >> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor > >> wrote: > >>> > >>> > On 24 Dec 2021, at 02:25, Archimedes Gaviola < > >>> archimedes.gaviola_at_gmail.com> wrote: > >>> > Are you using the boot files that came with 13.0 (dtb, etc)? > >>> > > >>> > Yes, I am. I have not changed anything that came from 13.0 files, > it's > >>> all intact since I wrote the image to the microSD card. > > I might be wrong here - but I seem to recollect that there was some > issue with the pi4 and 13.0-RELEASE. I have only ever used snapshots > of that branch. > > If you go to the msdos partition of your installation and run strings on > start4.elf, what do you see? > > I saw this (from the last time installed 13-STABLE) > > # strings start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 12:10:40 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) > > -- > J. > Hi J, Here, it's the same with your output. freebsd_at_fbsd13:/boot/msdos % strings start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) Thanks and best regards, Archimedes Use after April 1, 2021 version; Re: Raspberry Pi 4B does not detect devices in USB 3.0 I had a nonfunctional keyboard for 2 months, before I figured out, to try a different version. I, mean, They must have tested that version up in the snapshot and NOT HAD ANY PROBLEMS with running that version.? Rghtt? I mean they would have saw something run with the USB Keyboard for they released that image to be placed up there for every one to grab and use? Correct? Well NO! Can have any kind of problems with the software. https://ghostbsd-arm64.blogspot.com/2021/02/download-freebsd-140-current-version.html I took a different version of the file startx4.elf and over wrote the buggy version startx4.elf in the MSDOS ESP EFI Fat32 partition of 50Megabytes. Then my keyboard started working again. I could figure out how to email you directly, Archimedes. But not what to click to create a proper reply email from the email archives to answer properly with a copied lines of your original email. Can you tell me procedure to read HTML email from archives, and then click and open up a reply mail in your Thunderbird email program.? I am old , so a couple simple straight suggestions to know the dust loose in my brain, is helpful. *Try a newer version of FreeBSD 14.0 Current for the raspberry Pi board 4B is good. (or the 3+ version) https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220210-8dc42f98047-253065.img.xz xzcat FreeBSD14.0 | dd bs=1m conv=sync status=progress of=/dev/da1 I have a TP-Link TL-WN725N version 3.8,0x0bda:0x8179 P/N 0152802283 UPC 8 45973 05071 9 ; RTL8188eu chipset working with my raspberry pi 4B. https://forums.ghostbsd.org/viewtopic.php?f=64&t=526 EDIMAX EW-7811un if_rtwn.ko ; if_rtwn_usb.ko device drivers *https://forums.ghostbsd.org/viewtopic.php?f=64&t=570 RTL8188CE PCI rtwn chip set if_rtwn.ko ; if_rtwn_pck.ko device drivers Have a tiny little telegram group Arm Open-SourceARM Open-Source Telegram https://t.me/+ST6N61pnu3Di8zgk You are welcome to pop in and say hello. Archimedes and others. My little goal, Have the Raspberry Pi 4B, running FreeBSD 14.0 self hosting a compile station, using a 500GB SSD Sata external USB drive case. pkg install xorg MATE has the Desktop Environment (DE) running. Have an external USB Wifi dongle working to connect to internet and download software. Getting close to booting straight up from the 500 GB SSD, with many GPT partitions actuvated on it. Refind EFI boot manager running in ARM64 ( aarch64 armv8 64 bit) to select FreeBSD 14.0 arm64; Manjaro arm64; POP!_OS arm64; Fedora 35 arm64; https://ghostbsd-arm64.blogspot.com/2022/02/booting-500-gb-ssd-on-freebsd-arm64-140.html Any howtos booting FreeBSD straight up from a USB SSD drive. ( Can already boot up from a single USB flash drive ). *Share what goals* you have and what documents you have created to help the next guy out. See you on Telegram and I appreciate your answers shared here FreeBSD-arm mailing list. I have many url links to documents like U-BOOT at the booting-500-gb-ssd URL above. What nice URLS that you read documents from have you used lately to go from scratch to bringing up your Raspberry Pi with FreeBSD? or other Linuxes? Share on my blog post in a comment or mention here on your next posts ___________________________________________________________________________________________________ -- Fred Finster email: fred @ thegalacticzoo dot com 971-718-9144 --------------GdlOlxsV1kNIZuoUv9U5qehf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Use after April 1, 2021 version; Re: Raspberry Pi 4B does not detect devices in USB 3.0

Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use after April 1, 2021 13,0 stable version;  or use 14.0 Current


    
From: Archimedes Gaviola <archimedes.gaviola_at_gmail.com>

      Date: Mon,
        14 Feb 2022 21:58:28 +0800

        

        

      

    On
      Mon, Feb 14, 2022 at 9:40 PM tech-lists
      <tech-lists_at_zyxst.net> wrote:
      > Hi,
      >
      > On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola
      wrote:
      > >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola <
      > >archimedes.gaviola_at_gmail.com> wrote:
      > >
      > >> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor
      <darius_at_dons.net.au>
      > >> wrote:
      > >>>
      > >>> > On 24 Dec 2021, at 02:25, Archimedes
      Gaviola <
      > >>> archimedes.gaviola_at_gmail.com> wrote:
      > >>> > Are you using the boot files that came with
      13.0 (dtb, etc)?
      > >>> >
      > >>> > Yes, I am. I have not changed anything that
      came from 13.0 files,
      > it's
      > >>> all intact since I wrote the image to the
      microSD card.
      >
      > I might be wrong here - but I seem to recollect that there
      was some
      > issue with the pi4 and 13.0-RELEASE. I have only ever used
      snapshots
      > of that branch.
      >
      > If you go to the msdos partition of your installation and run
      strings on
      > start4.elf, what do you see?
      >
      > I saw this (from the last time installed 13-STABLE)
      >
      > # strings start4.elf | grep VC_BUILD_ID_
      > VC_BUILD_ID_USER: dom
      > VC_BUILD_ID_TIME: 12:10:40
      > VC_BUILD_ID_VARIANT: start
      > VC_BUILD_ID_TIME: Feb 25 2021
      > VC_BUILD_ID_BRANCH: bcm2711_2
      > VC_BUILD_ID_HOSTNAME: buildbot
      > VC_BUILD_ID_PLATFORM: raspberrypi_linux
      > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0
      (clean)
      >
      > --
      > J.
      >
      Hi J,
      Here, it's the same with your output.
      freebsd_at_fbsd13:/boot/msdos % strings start4.elf | grep
      VC_BUILD_ID_
      VC_BUILD_ID_USER: dom
      VC_BUILD_ID_TIME: 12:10:40
      VC_BUILD_ID_VARIANT: start
      VC_BUILD_ID_TIME: Feb 25 2021
      VC_BUILD_ID_BRANCH: bcm2711_2
      VC_BUILD_ID_HOSTNAME: buildbot
      VC_BUILD_ID_PLATFORM: raspberrypi_linux
      VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0
      (clean)
      Thanks and best regards,
      Archimedes
    


    

    
Use after April 1, 2021 version; Re:
        Raspberry Pi 4B does not detect devices in USB 3.0

    

    
I had a nonfunctional keyboard for 2 months, before I figured out, to try a different version.  I, mean,  They must have tested that version up in 
the snapshot and NOT HAD ANY PROBLEMS with running that version.?  Rghtt?  I mean they would have saw something run with the USB Keyboard for 
they released that image to be placed up there for every one to grab and use?  Correct?   Well NO!  Can have any kind of problems with the software.
https://ghostbsd-arm64.blogspot.com/2021/02/download-freebsd-140-current-version.html

I took a different version of the file startx4.elf and over wrote the buggy version startx4.elf in the  MSDOS ESP EFI Fat32 partition of 50Megabytes.  
Then my keyboard started working again.

I could figure out how to email you directly, Archimedes.  But not what to click to create a proper reply email from the email archives to answer properly with 
a copied lines of your original email.  Can you tell me procedure to read  HTML email from archives, and then click and open up a reply mail in your Thunderbird email program.?  
I am old ,  so a couple simple straight suggestions to know the dust loose in my brain, is helpful.

Try a newer version of FreeBSD 14.0 Current for the raspberry Pi board 4B is good. (or the 3+ version)
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/

https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220210-8dc42f98047-253065.img.xz
xzcat FreeBSD14.0 | dd bs=1m conv=sync status=progress of=/dev/da1 

I have a TP-Link TL-WN725N version 3.8,0x0bda:0x8179  P/N 0152802283  UPC 8 45973 05071 9 ;  RTL8188eu chipset working with my raspberry pi 4B.
https://forums.ghostbsd.org/viewtopic.php?f=64&t=526  EDIMAX EW-7811un  if_rtwn.ko  ; if_rtwn_usb.ko  device drivers
https://forums.ghostbsd.org/viewtopic.php?f=64&t=570  RTL8188CE  PCI rtwn chip set   if_rtwn.ko   ; if_rtwn_pck.ko  device drivers


Have a tiny little telegram group   Arm Open-Source  ARM Open-Source Telegram https://t.me/+ST6N61pnu3Di8zgk  You are welcome to pop in and say hello. Archimedes and others.

My little goal,  Have the Raspberry Pi 4B, running FreeBSD 14.0 self hosting a compile station, using a 500GB SSD Sata external USB drive case.
pkg install xorg MATE  has the Desktop Environment (DE) running.  Have an external USB Wifi dongle working to connect to internet and download software.
Getting close to booting straight up from the 500 GB SSD, with many GPT partitions actuvated on it.
Refind EFI boot manager running in ARM64 ( aarch64 armv8 64 bit) to select FreeBSD 14.0 arm64; Manjaro arm64; POP!_OS arm64; Fedora 35 arm64;
https://ghostbsd-arm64.blogspot.com/2022/02/booting-500-gb-ssd-on-freebsd-arm64-140.html

Any howtos booting FreeBSD straight up from a USB SSD drive.  ( Can already boot up from a single USB flash drive ).

Share what goals you have and what documents you have created to help the next guy out.  See you on Telegram and I appreciate your answers shared here FreeBSD-arm mailing list.
I have many url links to documents like U-BOOT at the booting-500-gb-ssd URL above.  What nice URLS that you read documents from have you used lately to go from scratch to bringing 
up your Raspberry Pi with FreeBSD? or other Linuxes?  Share on my blog post in a comment or mention here on your next posts

___________________________________________________________________________________________________
-- 
Fred Finster 
email:  fred @ thegalacticzoo dot com
971-718-9144




  


--------------GdlOlxsV1kNIZuoUv9U5qehf--

From nobody Wed Feb 16 03:42:58 2022
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 06A2119A09CB
	for ; Wed, 16 Feb 2022 03:43:19 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4Jz3hQ1Z39z3HCJ
	for ; Wed, 16 Feb 2022 03:43:18 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x534.google.com with SMTP id h18so1644692edb.7
        for ; Tue, 15 Feb 2022 19:43:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=BpSzJVCn+M3ixxzQ0XIjONsjJ3hfKEuut+QMVlO/3Fs=;
        b=GHVlJRRoNd3LGrYqfbKsYPdAwJ7Emn9o7Vho5F3wJJDEKNo6KJX22ZH9QvuMdRgtbh
         Ry7JBCEtpaStx8ahDu119rzOF9sIMZbezU9kcJ0haAlEgc4zFcDjFMHZdqMFRi0eWgE3
         v/a7i9RIqQreyyREI5KbKQ/C0CzbpWm6esnGlVHCmRewHV5+alxL9TDLsGF4HkMPs9R+
         Zl6jHG0OBOBS9HDZq1PF8Pl+LgD7OWrlVogdN6CZImNhmI/8ZRAg8WsApSNs66d/1SHf
         kW2R8TsIoGqvJ6dsbuIqkbbRiPFEnygPDV4idvjrmkkydoBkOben7lB/RxHJ9M3Intx3
         qYWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=BpSzJVCn+M3ixxzQ0XIjONsjJ3hfKEuut+QMVlO/3Fs=;
        b=nnBiVMSVDoZSoVm6MhDj9yskQp8GCpdUQXGX/yXj+DJn4MUErn9rnV3PBe2kKMAqKy
         X5/1/SPHKFT+qTTsJzEjW0qWd8imUbYifirlCNRUPOqNw6ar9kAK4oRV9zAzq6Urycqn
         D44coKq5Py4x6HIjy5l+D8TVup3slWA+b/OfBg0/afQxOtzNoGBHc+3E+Wfc6qnwzf9P
         6PXbUkLkys6PzPpp4axakt+hTIOrUZMShd1mjfarBdYdHSUi0g8vfU7rTQPpZv7vzFP3
         2j3+ZWm5Fb/vTFQYwc9+gv/GhrWyJqFMjKXRIu0RBiT9dB5XQQ1SQFL0sDxC/tZRXBWZ
         fvIg==
X-Gm-Message-State: AOAM531x9hnc2Z+Squq8XfCkFPZ2/BHciX0rWnXGi/o0FjyPkrlSwJki
	zNJrA59A7z+88ySJGqHZ7TFcrx1lmiWvr50oou4=
X-Google-Smtp-Source: ABdhPJykL45+8zK6Ak6wXOC9OMtwdYnTqHGODta5KOFRiY4X1+ePTHRFB1Y9baDhabVfqiRfjVzIEISPxjpuglRoxrE=
X-Received: by 2002:a50:c056:0:b0:40f:9c6d:7701 with SMTP id
 u22-20020a50c056000000b0040f9c6d7701mr928468edd.110.1644982990825; Tue, 15
 Feb 2022 19:43:10 -0800 (PST)
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: <92b4a81e-5b86-2ece-bb75-f26230ec0992.ref@yahoo.com> <92b4a81e-5b86-2ece-bb75-f26230ec0992@yahoo.com>
In-Reply-To: <92b4a81e-5b86-2ece-bb75-f26230ec0992@yahoo.com>
From: Archimedes Gaviola 
Date: Wed, 16 Feb 2022 11:42:58 +0800
Message-ID: 
Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use after
 April 1, 2021 version; or use 14.0 Current
To: Fred Finster 
Cc: freebsd-arm@freebsd.org, fred@thegalacticzoo.com
Content-Type: multipart/alternative; boundary="000000000000d46df405d81a7292"
X-Rspamd-Queue-Id: 4Jz3hQ1Z39z3HCJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=GHVlJRRo;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 17128
Lines: 364

--000000000000d46df405d81a7292
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 15, 2022 at 8:35 PM Fred Finster  wrote:

> Use after April 1, 2021 version; Re: Raspberry Pi 4B does not detect
> devices in USB 3.0
>
> Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use after April
> 1, 2021 13,0 stable version;  or use 14.0 Current
>
> From: Archimedes Gaviola  
> >
> Date: Mon, 14 Feb 2022 21:58:28 +0800
>
>
> On Mon, Feb 14, 2022 at 9:40 PM tech-lists 
> wrote: > Hi, > > On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes
> Gaviola wrote: > >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola < >=
 >
> archimedes.gaviola_at_gmail.com> wrote: > > > >> On Fri, Dec 24, 2021 at
> 10:49 AM Daniel O'Connor  > >> wrote: > >>> > >>>
> > On 24 Dec 2021, at 02:25, Archimedes Gaviola < > >>>
> archimedes.gaviola_at_gmail.com> wrote: > >>> > Are you using the boot
> files that came with 13.0 (dtb, etc)? > >>> > > >>> > Yes, I am. I have n=
ot
> changed anything that came from 13.0 files, > it's > >>> all intact since=
 I
> wrote the image to the microSD card. > > I might be wrong here - but I se=
em
> to recollect that there was some > issue with the pi4 and 13.0-RELEASE. I
> have only ever used snapshots > of that branch. > > If you go to the msdo=
s
> partition of your installation and run strings on > start4.elf, what do y=
ou
> see? > > I saw this (from the last time installed 13-STABLE) > > # string=
s
> start4.elf | grep VC_BUILD_ID_ > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME=
:
> 12:10:40 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 >
> VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot >
> VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION:
> 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) > > -- > J. > Hi J, Here=
,
> it's the same with your output. freebsd_at_fbsd13:/boot/msdos % strings
> start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME:
> 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION:
> 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) Thanks and best regards,
> Archimedes
>
>
> Use after April 1, 2021 version; Re: Raspberry Pi 4B does not detect
> devices in USB 3.0
>
> I had a nonfunctional keyboard for 2 months, before I figured out, to try=
 a different version.  I, mean,  They must have tested that version up in
> the snapshot and NOT HAD ANY PROBLEMS with running that version.?  Rghtt?=
  I mean they would have saw something run with the USB Keyboard for
> they released that image to be placed up there for every one to grab and =
use?  Correct?   Well NO!  Can have any kind of problems with the software.=
https://ghostbsd-arm64.blogspot.com/2021/02/download-freebsd-140-current-ve=
rsion.html
>
> I took a different version of the file startx4.elf and over wrote the bug=
gy version startx4.elf in the  MSDOS ESP EFI Fat32 partition of 50Megabytes=
.
> Then my keyboard started working again.
>
> I could figure out how to email you directly, Archimedes.  But not what t=
o click to create a proper reply email from the email archives to answer pr=
operly with
> a copied lines of your original email.  Can you tell me procedure to read=
  HTML email from archives, and then click and open up a reply mail in your=
 Thunderbird email program.?
> I am old ,  so a couple simple straight suggestions to know the dust loos=
e in my brain, is helpful.
> *Try a newer version of FreeBSD 14.0 Current for the raspberry Pi board 4=
B is good. (or the 3+ version)
> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/=
 
>
> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/=
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220210-8dc42f98047-253065.img.xz <=
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/Fr=
eeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220210-8dc42f98047-253065.img.xz>
> xzcat FreeBSD14.0 | dd bs=3D1m conv=3Dsync status=3Dprogress of=3D/dev/da=
1
> *
>
>
Hi Fred,

Thanks for your inputs, sharing your experiences and resolutions and
providing procedures! This is highly appreciated. I'll try later after work
with FreeBSD 14.0-current as your recommendation and then get back to the
outcome.


> *
> I have a TP-Link TL-WN725N version 3.8,0x0bda:0x8179  P/N 0152802283  UPC=
 8 45973 05071 9 ;  RTL8188eu chipset working with my raspberry pi 4B.
> https://forums.ghostbsd.org/viewtopic.php?f=3D64&t=3D526   EDIMAX EW-7811un  if_rtwn.ko  ;=
 if_rtwn_usb.ko  device drivers
> *https://forums.ghostbsd.org/viewtopic.php?f=3D64&t=3D570  RTL8188CE  PCI=
 rtwn chip set   if_rtwn.ko   ; if_rtwn_pck.ko  device drivers
>
>
> Have a tiny little telegram group   Arm Open-Source  ARM Open-Source Tele=
gram https://t.me/+ST6N61pnu3Di8zgk   You a=
re welcome to pop in and say hello. Archimedes and others.
>
> My little goal,  Have the Raspberry Pi 4B, running FreeBSD 14.0 self host=
ing a compile station, using a 500GB SSD Sata external USB drive case.
> pkg install xorg MATE  has the Desktop Environment (DE) running.  Have an=
 external USB Wifi dongle working to connect to internet and download softw=
are.
> Getting close to booting straight up from the 500 GB SSD, with many GPT p=
artitions actuvated on it.
> Refind EFI boot manager running in ARM64 ( aarch64 armv8 64 bit) to selec=
t FreeBSD 14.0 arm64; Manjaro arm64; POP!_OS arm64; Fedora 35 arm64;https:/=
/ghostbsd-arm64.blogspot.com/2022/02/booting-500-gb-ssd-on-freebsd-arm64-14=
0.html
>
> Any howtos booting FreeBSD straight up from a USB SSD drive.  ( Can alrea=
dy boot up from a single USB flash drive ).
> *Share what goals* you have and what documents you have created to help t=
he next guy out.  See you on Telegram and I appreciate your answers shared =
here FreeBSD-arm mailing list.
> I have many url links to documents like U-BOOT at the booting-500-gb-ssd =
URL above.  What nice URLS that you read documents from have you used latel=
y to go from scratch to bringing
> up your Raspberry Pi with FreeBSD? or other Linuxes?  Share on my blog po=
st in a comment or mention here on your next posts
>
>
This is noted as well, thanks for the idea and initiative. These are very
good and useful stuffs.

Thanks,
Archimedes

--000000000000d46df405d81a7292
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tue, Feb 15, 2022 at 8:35 PM Fred Fins=
ter <wb7odyfred@yahoo.com>=
; wrote:

 =20

   =20
 =20
  

    
Use after April 1, 2021 version; Re:
        Raspberry Pi 4B does not detect devices in USB 3.0

    
Re: Raspberry Pi 4B does not detect devices in USB 3.0 , Use
      after April 1, 2021 13,0 stable version;=C2=A0 or use 14.0 Current
    

    

    
From: Archimedes Gaviola <archimedes.gaviola_at_gmail.com&g=
t;

      Date: Mon,
        14 Feb 2022 21:58:28 +0800

        

        

      

    On
      Mon, Feb 14, 2022 at 9:40 PM tech-lists
      <tech=
-lists_at_zyxst.net> wrote:
      > Hi,
      >
      > On Mon, Feb 14, 2022 at 08:40:56PM +0800, Archimedes Gaviola
      wrote:
      > >On Fri, Dec 24, 2021 at 12:32 PM Archimedes Gaviola <
      > >archimedes.gaviola_at_gmail.com> wrote:
      > >
      > >> On Fri, Dec 24, 2021 at 10:49 AM Daniel O'Connor
      <darius=
_at_dons.net.au>
      > >> wrote:
      > >>>
      > >>> > On 24 Dec 2021, at 02:25, Archimedes
      Gaviola <
      > >>> archimedes.gaviola_at_gmail.com> wrote:
      > >>> > Are you using the boot files that came with
      13.0 (dtb, etc)?
      > >>> >
      > >>> > Yes, I am. I have not changed anything that
      came from 13.0 files,
      > it's
      > >>> all intact since I wrote the image to the
      microSD card.
      >
      > I might be wrong here - but I seem to recollect that there
      was some
      > issue with the pi4 and 13.0-RELEASE. I have only ever used
      snapshots
      > of that branch.
      >
      > If you go to the msdos partition of your installation and run
      strings on
      > start4.elf, what do you see?
      >
      > I saw this (from the last time installed 13-STABLE)
      >
      > # strings start4.elf | grep VC_BUILD_ID_
      > VC_BUILD_ID_USER: dom
      > VC_BUILD_ID_TIME: 12:10:40
      > VC_BUILD_ID_VARIANT: start
      > VC_BUILD_ID_TIME: Feb 25 2021
      > VC_BUILD_ID_BRANCH: bcm2711_2
      > VC_BUILD_ID_HOSTNAME: buildbot
      > VC_BUILD_ID_PLATFORM: raspberrypi_linux
      > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0
      (clean)
      >
      > --
      > J.
      >
      Hi J,
      Here, it's the same with your output.
      freebsd_at_fbsd13:/boot/msdos % strings start4.elf | grep
      VC_BUILD_ID_
      VC_BUILD_ID_USER: dom
      VC_BUILD_ID_TIME: 12:10:40
      VC_BUILD_ID_VARIANT: start
      VC_BUILD_ID_TIME: Feb 25 2021
      VC_BUILD_ID_BRANCH: bcm2711_2
      VC_BUILD_ID_HOSTNAME: buildbot
      VC_BUILD_ID_PLATFORM: raspberrypi_linux
      VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0
      (clean)
      Thanks and best regards,
      Archimedes
    


    

    
Use after April 1, 2021 version; Re:
        Raspberry Pi 4B does not detect devices in USB 3.0

    

    
I had a nonfunctional keyboard for 2 months, before I =
figured out, to try a different version.  I, mean,  They must have tested t=
hat version up in=20
the snapshot and NOT HAD ANY PROBLEMS with running that version.?  Rghtt?  =
I mean they would have saw something run with the USB Keyboard for=20
they released that image to be placed up there for every one to grab and us=
e?  Correct?   Well NO!  Can have any kind of problems with the software.
https://ghostbsd-arm64.blogspot.co=
m/2021/02/download-freebsd-140-current-version.html

I took a different version of the file startx4.elf and over wrote the buggy=
 version startx4.elf in the  MSDOS ESP EFI Fat32 partition of 50Megabytes. =
=20
Then my keyboard started working again.

I could figure out how to email you directly, Archimedes.  But not what to =
click to create a proper reply email from the email archives to answer prop=
erly with=20
a copied lines of your original email.  Can you tell me procedure to read  =
HTML email from archives, and then click and open up a reply mail in your T=
hunderbird email program.? =20
I am old ,  so a couple simple straight suggestions to know the dust loose =
in my brain, is helpful.

Try a newer version of FreeBSD 14.0 Current for the ras=
pberry Pi board 4B is good. (or the 3+ version)
https://download.freebsd.org/ftp/snapshots/arm=
64/aarch64/ISO-IMAGES/14.0/

https://download.freebsd.org/ftp/snapshots/arm64=
/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220210-8d=
c42f98047-253065.img.xz
xzcat FreeBSD14.0 | dd bs=3D1m conv=3Dsync status=3Dprogress of=3D/dev/da1=
=20


Hi Fred,
=

Thanks for your inputs, sharing your experiences and resolut=
ions and providing procedures! This is highly appreciated. I'll try=20
later after work=20

with FreeBSD 14.0-current as your recommendation and then get back to the o=
utcome.
=C2=A0

I have a TP-Link TL-WN725N version 3.8,0x0bda:0x8179  P/N 0152802283  UPC 8=
 45973 05071 9 ;  RTL8188eu chipset working with my raspberry pi 4B.
https://forums.ghostbsd.org/viewtopic.php?f=3D64&t=3D52=
6  EDIMAX EW-7811un  if_rtwn.ko  ; if_rtwn_usb.ko  device drivers
https://forums.ghostbsd.org/viewtopic.php?f=3D64=
&t=3D570  RTL8188CE  PCI rtwn chip set   if_rtwn.ko   ; if_rtwn_pck=
.ko  device drivers


Have a tiny little telegram group   Arm Open-Source  ARM Open-Source Telegram https://t.m=
e/+ST6N61pnu3Di8zgk  You are welcome to pop in and say hello. Archimede=
s and others.

My little goal,  Have the Raspberry Pi 4B, running FreeBSD 14.0 self hostin=
g a compile station, using a 500GB SSD Sata external USB drive case.
pkg install xorg MATE  has the Desktop Environment (DE) running.  Have an e=
xternal USB Wifi dongle working to connect to internet and download softwar=
e.
Getting close to booting straight up from the 500 GB SSD, with many GPT par=
titions actuvated on it.
Refind EFI boot manager running in ARM64 ( aarch64 armv8 64 bit) to select =
FreeBSD 14.0 arm64; Manjaro arm64; POP!_OS arm64; Fedora 35 arm64;
https://ghostbsd-arm64.blogspot=
.com/2022/02/booting-500-gb-ssd-on-freebsd-arm64-140.html

Any howtos booting FreeBSD straight up fro=
m a USB SSD drive.  ( Can already boot up from a single USB flash drive ).

Share what goals you have and what documents=
 you have created to help the next guy out.  See you on Telegram and I appr=
eciate your answers shared here FreeBSD-arm mailing list.
I have many url links to documents like U-BOOT at the booting-500-gb-ssd UR=
L above.  What nice URLS that you read documents from have you used lately =
to go from scratch to bringing=20
up your Raspberry Pi with FreeBSD? or other Linuxes?  Share on my blog post=
 in a comment or mention here on your next posts




This is noted as well, thanks for the idea and initiati=
ve. These are very good and useful stuffs.

Thanks,=

Archimedes







  





--000000000000d46df405d81a7292--

From nobody Wed Feb 16 08:30:14 2022
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 7BF7519D0B7B
	for ; Wed, 16 Feb 2022 08:35:53 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JzBB046bjz4cd4
	for ; Wed, 16 Feb 2022 08:35:52 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: from relay6-d.mail.gandi.net (unknown [217.70.183.198])
	by mslow1.mail.gandi.net (Postfix) with ESMTP id 310AECF5CC
	for ; Wed, 16 Feb 2022 08:30:28 +0000 (UTC)
Received: (Authenticated sender: daniel.engberg@pyret.net)
	by mail.gandi.net (Postfix) with ESMTPA id B5327C0004;
	Wed, 16 Feb 2022 08:30:14 +0000 (UTC)
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
Date: Wed, 16 Feb 2022 09:30:14 +0100
From: Daniel Engberg 
To: Freebsd Arm 
Cc: mjl@luckie.org.nz
Subject: Re: DLink DWM-222 revision A2
Message-ID: <853205bfd60fc3ed6ad6e8a6ee2ab271@FreeBSD.org>
X-Sender: diizzy@FreeBSD.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4JzBB046bjz4cd4
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 217.70.178.240 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org
X-Spamd-Result: default: False [-2.19 / 15.00];
	 ARC_NA(0.00)[];
	 FAKE_REPLY(1.00)[];
	 FREEFALL_USER(0.00)[diizzy];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[FreeBSD.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.992];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.198:received]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 796
Lines: 28

Hi,

It's been a while since I played around with LTE USB sticks but I have a 
vauge memory of some kind of race condidion between (default) kernel 
modules and modem interfaces which by the way may no longer be valid.

Anyhow, looking at my notes... (KERNCONF)

device          ucom
device          u3g
device          uether
device          cdce

Since these are notes from an ARM SBC these lines are also present in 
/boot/loader.conf not sure if they (umodem) are related or not

# Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"

...and 
https://forums.freebsd.org/threads/4g-usb-modem.67263/page-2#post-431369

This will only work if your modem offers a CDC ECM/NCM interface and not 
PPP which makes your experience a lot less painful ;-)

Best regards,
Daniel

From nobody Wed Feb 16 10:31:02 2022
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 B9AA3194B48A
	for ; Wed, 16 Feb 2022 10:31:15 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130])
	(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 "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JzDl63txHz4pdX
	for ; Wed, 16 Feb 2022 10:31:14 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Date: Wed, 16 Feb 2022 10:31:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail3; t=1645007464;
	bh=cVI5RDXdEwfx4HLZMpS7k78ypP/7g9AocG5VSdE3jdM=;
	h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject:
	 Reply-To:Feedback-ID:Message-ID;
	b=iRSaKffmAps/E8kDs0/yzGLjcU7ziE/LHdNDzBo1rgT2QU1J1Kx2L8LUa0AQ2Lx18
	 eTLm0sLqu6q8E38zvoTb/QyPdSneFH4cBfgdqC+9jKdYUcutB5TrzTU/B6Xsvb73Mx
	 X5nxZw+R8TJn/sCM8ds0vSOGRq2I93i6qPQy7641KKQr1B9KZHWZe2aNcf9vYwWmD+
	 rYz6Zm4He2EsCyp0iMqwH9NBEEfH85ycx8FBt1U0Skz1S5oHlsZkB1QmFXrHyloHyJ
	 0OMkeZmwifX0N+EVqgxp/nhtCdbM7pGo6vczpnjYVP2v4iPRetuZgUb2HjjQ3Ph4lF
	 NobgmhCQsj/9Q==
To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" 
From: qroxana 
Reply-To: qroxana 
Subject: Kernel panic for if_epair
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: multipart/alternative;
 boundary="b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE"
X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
	T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=disabled version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	mailout.protonmail.ch
X-Rspamd-Queue-Id: 4JzDl63txHz4pdX
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=iRSaKffm;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.130 as permitted sender) smtp.mailfrom=qroxana@protonmail.com
X-Spamd-Result: default: False [-0.80 / 15.00];
	 HAS_REPLYTO(0.00)[qroxana@protonmail.com];
	 FREEMAIL_FROM(0.00)[protonmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 DKIM_TRACE(0.00)[protonmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[protonmail.com];
	 ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.996];
	 NEURAL_HAM_LONG(-0.89)[-0.894];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 FREEMAIL_REPLYTO(0.00)[protonmail.com];
	 HAS_PHPMAILER_SIG(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.130:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 34008
Lines: 453

This is a multi-part message in MIME format.

--b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SXQncyBydW5uaW5nIDE0LjAtQ1VSUkVOVCBhcm12NyBtYWluLW4yNTI5ODMtZDIxZTcxZWZjZTM5
CgpLZXJuZWwgcGFnZSBmYXVsdCB3aXRoIHRoZSBmb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2Nr
cyBoZWxkOgpleGNsdXNpdmUgc2xlZXAgbXV0ZXggZXBhaXJpZHggKGVwYWlyaWR4KSByID0gMCAo
MHhlMmZlOTE2MCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldC9pZl9lcGFpci5jOjE2NQpzdGFj
ayBiYWNrdHJhY2U6CiMwIDB4YzAzNTU4ZjggYXQgd2l0bmVzc19kZWJ1Z2dlcisweDdjCiMxIDB4
YzAzNTZiM2MgYXQgd2l0bmVzc193YXJuKzB4M2ZjCiMyIDB4YzA1ZWIzYzggYXQgYWJvcnRfaGFu
ZGxlcisweDFkOAojMyAweGMwNWNhOGUwIGF0IGV4Y2VwdGlvbl9leGl0KzAKIzQgMHhjMDQ3NTky
OCBhdCB1ZHBfaW5wdXQrMHgxYzAKIzUgMHhjMDQ0MTg4NCBhdCBpcF9pbnB1dCsweGExOAojNiAw
eGMwNDE0MjZjIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAKIzcgMHhjMDQwYjlhMCBhdCBl
dGhlcl9kZW11eCsweDFjOAojOCAweGMwNDBkMjJjIGF0IGV0aGVyX25oX2lucHV0KzB4NTE0CiM5
IDB4YzA0MTQyNmMgYXQgbmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMAojMTAgMHhjMDQwYmU5NCBh
dCBldGhlcl9pbnB1dCsweDhjCiMxMSAweGUyZmQ4MTMwIGF0ICRhLjgrMHgxMjgKIzEyIDB4YzAy
YTFlZTAgYXQgaXRocmVhZF9sb29wKzB4MjY4CiMxMyAweGMwMjllMDg4IGF0IGZvcmtfZXhpdCsw
eGEwCiMxNCAweGMwNWNhODcwIGF0IHN3aV9leGl0KzAKRmF0YWwga2VybmVsIG1vZGUgZGF0YSBh
Ym9ydDogJ0FsaWdubWVudCBGYXVsdCcgb24gcmVhZAp0cmFwZnJhbWU6IDB4ZTJhMGJhZjAKRlNS
PTAwMDAwMDAxLCBGQVI9ZTNmMDJhNTYsIHNwc3I9MjAwMDAwMTMKcjAgPTAwMDAwMDAwLCByMSA9
MDAwMDAwMDEsIHIyID0wMDAwMDAwMSwgcjMgPTAwMDAwYTBhCnI0ID0wMDAwMDAwMCwgcjUgPWUz
ZjAyYTZhLCByNiA9ZTNmMDJhNTYsIHI3ID0wMDAwMDA0NApyOCA9MDAwMDAwNDQsIHI5ID1jMGFm
OTU1YywgcjEwPTAwMDAwMDE0LCByMTE9ZTJhMGJjMTAKcjEyPTAwMDAwMDAwLCBzc3A9ZTJhMGJi
ODAsIHNscj1jMDQ0MTg4NCwgcGMgPWMwNDc1OTI4CgpwYW5pYzogRmF0YWwgYWJvcnQKY3B1aWQg
PSAwCnRpbWUgPSAxNjQ1MDA0ODg5CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm
KCkgYXQgZGJfdHJhY2Vfc2VsZgogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhjMDA3
YWM0OCAoZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MzApCiAgICAgICAgIHNwID0gMHhlMmEwYjhj
OCAgZnAgPSAweGUyYTBiOWUwCmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3Nl
bGZfd3JhcHBlcisweDMwCiAgICAgICAgIHBjID0gMHhjMDA3YWM0OCAgbHIgPSAweGMwMmUyNTlj
ICh2cGFuaWMrMHgxNzApCiAgICAgICAgIHNwID0gMHhlMmEwYjllOCAgZnAgPSAweGUyYTBiYTA4
CiAgICAgICAgIHI0ID0gMHgwMDAwMDEwMCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0g
MHhjMDc3ZjY3MCAgcjcgPSAweGMwOTBkOTEwCnZwYW5pYygpIGF0IHZwYW5pYysweDE3MAogICAg
ICAgICBwYyA9IDB4YzAyZTI1OWMgIGxyID0gMHhjMDJlMjM0YyAoZG9hZHVtcCkKICAgICAgICAg
c3AgPSAweGUyYTBiYTEwICBmcCA9IDB4ZTJhMGJhMTQKICAgICAgICAgcjQgPSAweGUyYTBiYWYw
ICByNSA9IDB4MDAwMDAwMTMKICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9IDB4MDAwMDAw
MDEKICAgICAgICAgcjggPSAweDAwMDAwMDAxICByOSA9IDB4ZTI5NGUwMDAKICAgICAgICByMTAg
PSAweGUzZjAyYTU2CmRvYWR1bXAoKSBhdCBkb2FkdW1wCiAgICAgICAgIHBjID0gMHhjMDJlMjM0
YyAgbHIgPSAweGMwNWViYTE4IChhYm9ydF9hbGlnbikKICAgICAgICAgc3AgPSAweGUyYTBiYTFj
ICBmcCA9IDB4ZTJhMGJhNDgKICAgICAgICAgcjQgPSAweGUzZjAyYTU2ICByNSA9IDB4ZTJhMGJh
MTQKICAgICAgICAgcjYgPSAweGMwMmUyMzRjIHIxMCA9IDB4ZTJhMGJhMWMKYWJvcnRfYWxpZ24o
KSBhdCBhYm9ydF9hbGlnbgogICAgICAgICBwYyA9IDB4YzA1ZWJhMTggIGxyID0gMHhjMDVlYjUx
OCAoYWJvcnRfaGFuZGxlcisweDMyOCkKICAgICAgICAgc3AgPSAweGUyYTBiYTUwICBmcCA9IDB4
ZTJhMGJhZTgKICAgICAgICAgcjQgPSAweDAwMDAwMDEzICByNSA9IDB4ZTNmMDJhNTYKYWJvcnRf
aGFuZGxlcigpIGF0IGFib3J0X2hhbmRsZXIrMHgzMjgKICAgICAgICAgcGMgPSAweGMwNWViNTE4
ICBsciA9IDB4YzA1Y2E4ZTAgKGV4Y2VwdGlvbl9leGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJh
ZjAgIGZwID0gMHhlMmEwYmMxMAogICAgICAgICByNCA9IDB4MDAwMDAwMDAgIHI1ID0gMHhlM2Yw
MmE2YQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NAogICAgICAgICBy
OCA9IDB4MDAwMDAwNDQgIHI5ID0gMHhjMGFmOTU1YwogICAgICAgIHIxMCA9IDB4MDAwMDAwMTQK
ZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdAogICAgICAgICBwYyA9IDB4YzA1Y2E4
ZTAgIGxyID0gMHhjMDQ0MTg4NCAoaXBfaW5wdXQrMHhhMTgpCiAgICAgICAgIHNwID0gMHhlMmEw
YmI4MCAgZnAgPSAweGUyYTBiYzEwCiAgICAgICAgIHIwID0gMHgwMDAwMDAwMCAgcjEgPSAweDAw
MDAwMDAxCiAgICAgICAgIHIyID0gMHgwMDAwMDAwMSAgcjMgPSAweDAwMDAwYTBhCiAgICAgICAg
IHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGUzZjAyYTZhCiAgICAgICAgIHI2ID0gMHhlM2YwMmE1
NiAgcjcgPSAweDAwMDAwMDQ0CiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMwYWY5
NTVjCiAgICAgICAgcjEwID0gMHgwMDAwMDAxNCByMTIgPSAweDAwMDAwMDAwCnVkcF9pbnB1dCgp
IGF0IHVkcF9pbnB1dCsweDFjMAogICAgICAgICBwYyA9IDB4YzA0NzU5MjggIGxyID0gMHhjMDQ0
MTg4NCAoaXBfaW5wdXQrMHhhMTgpCiAgICAgICAgIHNwID0gMHhlMmEwYmMxOCAgZnAgPSAweGUy
YTBiYzUwCiAgICAgICAgIHI0ID0gMHgwMDAyMmU3NSAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAg
IHI2ID0gMHgwMDAwMDAxNCAgcjcgPSAweDAwMDAwMGZiCiAgICAgICAgIHI4ID0gMHhjMDkwZDkx
MCAgcjkgPSAweGMwOTQ1N2ZjCiAgICAgICAgcjEwID0gMHhlM2YwMmE1NgppcF9pbnB1dCgpIGF0
IGlwX2lucHV0KzB4YTE4CiAgICAgICAgIHBjID0gMHhjMDQ0MTg4NCAgbHIgPSAweGMwNDE0MjZj
IChuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MTAwKQogICAgICAgICBzcCA9IDB4ZTJhMGJjNTggIGZw
ID0gMHhlMmEwYmM4MAogICAgICAgICByNCA9IDB4MDAwM2E3M2IgIHI1ID0gMHhlM2YwMmEwMAog
ICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjRiNAogICAgICAgICByOCA9IDB4
ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYyOAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDgKbmV0aXNy
X2Rpc3BhdGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAKICAgICAgICAgcGMg
PSAweGMwNDE0MjZjICBsciA9IDB4YzA0MGI5YTAgKGV0aGVyX2RlbXV4KzB4MWM4KQogICAgICAg
ICBzcCA9IDB4ZTJhMGJjODggIGZwID0gMHhlMmEwYmNhMAogICAgICAgICByNCA9IDB4ZTMyNDQ0
MDAgIHI1ID0gMHhlM2YwMmEwMAogICAgICAgICByNiA9IDB4MDAwMDA4MDAgIHI3ID0gMHhlMzI0
NDQwMAogICAgICAgICByOCA9IDB4ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYyOAogICAgICAgIHIx
MCA9IDB4MDAwMDAwMDgKZXRoZXJfZGVtdXgoKSBhdCBldGhlcl9kZW11eCsweDFjOAogICAgICAg
ICBwYyA9IDB4YzA0MGI5YTAgIGxyID0gMHhjMDQwZDIyYyAoZXRoZXJfbmhfaW5wdXQrMHg1MTQp
CiAgICAgICAgIHNwID0gMHhlMmEwYmNhOCAgZnAgPSAweGUyYTBiZDEwCiAgICAgICAgIHI0ID0g
MHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHhlM2YwMmE0OCAgcjcg
PSAweDAwMDAwMDAwCmV0aGVyX25oX2lucHV0KCkgYXQgZXRoZXJfbmhfaW5wdXQrMHg1MTQKICAg
ICAgICAgcGMgPSAweGMwNDBkMjJjICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9z
cmMrMHgxMDApCiAgICAgICAgIHNwID0gMHhlMmEwYmQxOCAgZnAgPSAweGUyYTBiZDQwCiAgICAg
ICAgIHI0ID0gMHgwMDA1MGU4OCAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHgwMDAw
MDAwMCAgcjcgPSAweGMwYjViNTM0CiAgICAgICAgIHI4ID0gMHg1ZTRhNmYyOCAgcjkgPSAweDAw
MDAwMDIwCiAgICAgICAgcjEwID0gMHgwMDAwMDAwMApuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQg
bmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMAogICAgICAgICBwYyA9IDB4YzA0MTQyNmMgIGxyID0g
MHhjMDQwYmU5NCAoZXRoZXJfaW5wdXQrMHg4YykKICAgICAgICAgc3AgPSAweGUyYTBiZDQ4ICBm
cCA9IDB4ZTJhMGJkODAKICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4MDAwMDAwMDAK
ICAgICAgICAgcjYgPSAweGUzZjAyYTAwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAgcjggPSAw
eDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjAKICAgICAgICByMTAgPSAweDAwMDAwMDAwCmV0aGVy
X2lucHV0KCkgYXQgZXRoZXJfaW5wdXQrMHg4YwogICAgICAgICBwYyA9IDB4YzA0MGJlOTQgIGxy
ID0gMHhlMmZkODEzMCAoJGEuOCsweDEyOCkKICAgICAgICAgc3AgPSAweGUyYTBiZDg4ICBmcCA9
IDB4ZTJhMGJkYjgKICAgICAgICAgcjQgPSAweGM1N2Y1YzhjICByNSA9IDB4MDAwMDAwMDAKICAg
ICAgICAgcjYgPSAweGUzMjQ0NDAwICByNyA9IDB4YzU3ZjVjODAKICAgICAgICAgcjggPSAweGUy
ZmU5MTcwICByOSA9IDB4YzA5MzgzMjgKICAgICAgICByMTAgPSAweGUyYTBiZDg4CiRhLjgoKSBh
dCAkYS44KzB4MTI4CiAgICAgICAgIHBjID0gMHhlMmZkODEzMCAgbHIgPSAweGMwMmExZWUwIChp
dGhyZWFkX2xvb3ArMHgyNjgpCiAgICAgICAgIHNwID0gMHhlMmEwYmRjMCAgZnAgPSAweGUyYTBi
ZTIwCiAgICAgICAgIHI0ID0gMHhkYjc3ZjY0MCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2
ID0gMHhlM2IzZjU0NCAgcjcgPSAweGUzYjNmNTAwCiAgICAgICAgIHI4ID0gMHhjMDc3Y2VjOSAg
cjkgPSAweGUzYjNmNTA4CiAgICAgICAgcjEwID0gMHhkYjc3ZjY0MAppdGhyZWFkX2xvb3AoKSBh
dCBpdGhyZWFkX2xvb3ArMHgyNjgKICAgICAgICAgcGMgPSAweGMwMmExZWUwICBsciA9IDB4YzAy
OWUwODggKGZvcmtfZXhpdCsweGEwKQogICAgICAgICBzcCA9IDB4ZTJhMGJlMjggIGZwID0gMHhl
MmEwYmU0MAogICAgICAgICByNCA9IDB4ZTI5NGUwMDAgIHI1ID0gMHhkNzk2NzAwMAogICAgICAg
ICByNiA9IDB4YzAyYTFjNzggIHI3ID0gMHhkYjZlODEyMAogICAgICAgICByOCA9IDB4ZTJhMGJl
NDggIHI5ID0gMHgwMDAwMDAwMAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDAKZm9ya19leGl0KCkg
YXQgZm9ya19leGl0KzB4YTAKICAgICAgICAgcGMgPSAweGMwMjllMDg4ICBsciA9IDB4YzA1Y2E4
NzAgKHN3aV9leGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMAog
ICAgICAgICByNCA9IDB4YzAyYTFjNzggIHI1ID0gMHhkYjZlODEyMAogICAgICAgICByNiA9IDB4
MDAwMDAwMDAgIHI3ID0gMHgwMDAwMDAwMAogICAgICAgICByOCA9IDB4MDAwMDAwMDAgcjEwID0g
MHgwMDAwMDAwMApzd2lfZXhpdCgpIGF0IHN3aV9leGl0CiAgICAgICAgIHBjID0gMHhjMDVjYTg3
MCAgbHIgPSAweGMwNWNhODcwIChzd2lfZXhpdCkKICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBm
cCA9IDB4MDAwMDAwMDAKS0RCOiBlbnRlcjogcGFuaWMKWyB0aHJlYWQgcGlkIDExIHRpZCAxMDAx
NzQgXQpTdG9wcGVkIGF0ICAgICAga2RiX2VudGVyKzB4NTg6IGxkcmIgICAgcjE1LCBbcjE1LCBy
MTUsIHJvciByMTVdIQpkYj4gYnQKVHJhY2luZyBwaWQgMTEgdGlkIDEwMDE3NCB0ZCAweGUyOTRl
MDAwCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxmCiAgICAgICAgIHBjID0gMHhjMDVj
N2YzNCAgbHIgPSAweGMwMDc3NmY0IChkYl9zdGFja190cmFjZSsweDE0MCkKICAgICAgICAgc3Ag
PSAweGUyYTBiNzE4ICBmcCA9IDB4ZTJhMGI3MzAKZGJfc3RhY2tfdHJhY2UoKSBhdCBkYl9zdGFj
a190cmFjZSsweDE0MAogICAgICAgICBwYyA9IDB4YzAwNzc2ZjQgIGxyID0gMHhjMDA3NzQwNCAo
ZGJfY29tbWFuZCsweDM5YykKICAgICAgICAgc3AgPSAweGUyYTBiNzM4ICBmcCA9IDB4ZTJhMGI3
ZDgKICAgICAgICAgcjQgPSAweGMwNzI0NjQ2ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYg
PSAweGMwYWY5NTVjIHIxMCA9IDB4YzA4YThiYTAKZGJfY29tbWFuZCgpIGF0IGRiX2NvbW1hbmQr
MHgzOWMKICAgICAgICAgcGMgPSAweGMwMDc3NDA0ICBsciA9IDB4YzAwNzcwNDAgKGRiX2NvbW1h
bmRfbG9vcCsweDY0KQogICAgICAgICBzcCA9IDB4ZTJhMGI3ZTAgIGZwID0gMHhlMmEwYjdmMAog
ICAgICAgICByNCA9IDB4YzA3ODZkY2QgIHI1ID0gMHhjMDc4NjQ0NQogICAgICAgICByNiA9IDB4
YzA5NWVmNWMgIHI3ID0gMHhjMGFmYjg1OAogICAgICAgICByOCA9IDB4YzBhZmI4MzggIHI5ID0g
MHhjMDhhOGYzOAogICAgICAgIHIxMCA9IDB4YzA5Mzg3NzgKZGJfY29tbWFuZF9sb29wKCkgYXQg
ZGJfY29tbWFuZF9sb29wKzB4NjQKICAgICAgICAgcGMgPSAweGMwMDc3MDQwICBsciA9IDB4YzAw
N2FkY2MgKGRiX3RyYXArMHgxMjgpCiAgICAgICAgIHNwID0gMHhlMmEwYjdmOCAgZnAgPSAweGUy
YTBiOTEwCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGMwOTVlZjUwCiAgICAgICAg
IHI2ID0gMHhlMmEwYjk0OCByMTAgPSAweGMwOTM4Nzc4CmRiX3RyYXAoKSBhdCBkYl90cmFwKzB4
MTI4CiAgICAgICAgIHBjID0gMHhjMDA3YWRjYyAgbHIgPSAweGMwMzMyNTQ0IChrZGJfdHJhcCsw
eDFiOCkKICAgICAgICAgc3AgPSAweGUyYTBiOTE4ICBmcCA9IDB4ZTJhMGI5NDAKICAgICAgICAg
cjQgPSAweDAwMDAwMDAwICByNSA9IDB4MDAwMDAwMDEKICAgICAgICAgcjYgPSAweGUyYTBiOTQ4
ICByNyA9IDB4YzBhZmI4NTgKa2RiX3RyYXAoKSBhdCBrZGJfdHJhcCsweDFiOAogICAgICAgICBw
YyA9IDB4YzAzMzI1NDQgIGxyID0gMHhjMDVjYThlMCAoZXhjZXB0aW9uX2V4aXQpCiAgICAgICAg
IHNwID0gMHhlMmEwYjk0OCAgZnAgPSAweGUyYTBiOWUwCiAgICAgICAgIHI0ID0gMHg2MDAwMDFk
MyAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0gMHhjMDc3ZjY3MCAgcjcgPSAweGMwOTBk
OTEwCiAgICAgICAgIHI4ID0gMHhlMjk0ZTAwMCAgcjkgPSAweGUyYTBiYTFjCiAgICAgICAgcjEw
ID0gMHhjMGFlYmIzMApleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2VwdGlvbl9leGl0CiAgICAgICAg
IHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwMzMxYWJjIChrZGJfZW50ZXIrMHg0OCkKICAgICAg
ICAgc3AgPSAweGUyYTBiOWQ4ICBmcCA9IDB4ZTJhMGI5ZTAKICAgICAgICAgcjAgPSAweGMwYWZi
ODQ4ICByMSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjIgPSAweDAwMDAwMDEyICByMyA9IDB4MDAw
MDAwMDAKICAgICAgICAgcjQgPSAweGMwNzk4NzA0ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAg
cjYgPSAweGMwNzdmNjcwICByNyA9IDB4YzA5MGQ5MTAKICAgICAgICAgcjggPSAweGUyOTRlMDAw
ICByOSA9IDB4ZTJhMGJhMWMKICAgICAgICByMTAgPSAweGMwYWViYjMwIHIxMiA9IDB4MjAwMDAw
MDAKa2RiX2VudGVyKCkgYXQga2RiX2VudGVyKzB4NWMKICAgICAgICAgcGMgPSAweGMwMzMxYWQw
ICBsciA9IDB4YzAyZTI1ZTggKHZwYW5pYysweDFiYykKICAgICAgICAgc3AgPSAweGUyYTBiOWU4
ICBmcCA9IDB4ZTJhMGJhMDgKICAgICAgICAgcjQgPSAweDAwMDAwMTAwIHIxMCA9IDB4YzBhZWJi
MzAKdnBhbmljKCkgYXQgdnBhbmljKzB4MWJjCiAgICAgICAgIHBjID0gMHhjMDJlMjVlOCAgbHIg
PSAweGMwMmUyMzRjIChkb2FkdW1wKQogICAgICAgICBzcCA9IDB4ZTJhMGJhMTAgIGZwID0gMHhl
MmEwYmExNAogICAgICAgICByNCA9IDB4ZTJhMGJhZjAgIHI1ID0gMHgwMDAwMDAxMwogICAgICAg
ICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDAwMQogICAgICAgICByOCA9IDB4MDAwMDAw
MDEgIHI5ID0gMHhlMjk0ZTAwMAogICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYKZG9hZHVtcCgpIGF0
IGRvYWR1bXAKICAgICAgICAgcGMgPSAweGMwMmUyMzRjICBsciA9IDB4YzA1ZWJhMTggKGFib3J0
X2FsaWduKQogICAgICAgICBzcCA9IDB4ZTJhMGJhMWMgIGZwID0gMHhlMmEwYmE0OAogICAgICAg
ICByNCA9IDB4ZTNmMDJhNTYgIHI1ID0gMHhlMmEwYmExNAogICAgICAgICByNiA9IDB4YzAyZTIz
NGMgcjEwID0gMHhlMmEwYmExYwphYm9ydF9hbGlnbigpIGF0IGFib3J0X2FsaWduCiAgICAgICAg
IHBjID0gMHhjMDVlYmExOCAgbHIgPSAweGMwNWViNTE4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQog
ICAgICAgICBzcCA9IDB4ZTJhMGJhNTAgIGZwID0gMHhlMmEwYmFlOAogICAgICAgICByNCA9IDB4
MDAwMDAwMTMgIHI1ID0gMHhlM2YwMmE1NgphYm9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxl
cisweDMyOAogICAgICAgICBwYyA9IDB4YzA1ZWI1MTggIGxyID0gMHhjMDVjYThlMCAoZXhjZXB0
aW9uX2V4aXQpCiAgICAgICAgIHNwID0gMHhlMmEwYmFmMCAgZnAgPSAweGUyYTBiYzEwCiAgICAg
ICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGUzZjAyYTZhCiAgICAgICAgIHI2ID0gMHhlM2Yw
MmE1NiAgcjcgPSAweDAwMDAwMDQ0CiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMw
YWY5NTVjCiAgICAgICAgcjEwID0gMHgwMDAwMDAxNApleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2Vw
dGlvbl9leGl0CiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwNDQxODg0IChpcF9p
bnB1dCsweGExOCkKICAgICAgICAgc3AgPSAweGUyYTBiYjgwICBmcCA9IDB4ZTJhMGJjMTAKICAg
ICAgICAgcjAgPSAweDAwMDAwMDAwICByMSA9IDB4MDAwMDAwMDEKICAgICAgICAgcjIgPSAweDAw
MDAwMDAxICByMyA9IDB4MDAwMDBhMGEKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4
ZTNmMDJhNmEKICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9IDB4MDAwMDAwNDQKICAgICAg
ICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMKICAgICAgICByMTAgPSAweDAwMDAw
MDE0IHIxMiA9IDB4MDAwMDAwMDAKdWRwX2lucHV0KCkgYXQgdWRwX2lucHV0KzB4MWMwCiAgICAg
ICAgIHBjID0gMHhjMDQ3NTkyOCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1dCsweGExOCkKICAg
ICAgICAgc3AgPSAweGUyYTBiYzE4ICBmcCA9IDB4ZTJhMGJjNTAKICAgICAgICAgcjQgPSAweDAw
MDIyZTc1ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDE0ICByNyA9IDB4
MDAwMDAwZmIKICAgICAgICAgcjggPSAweGMwOTBkOTEwICByOSA9IDB4YzA5NDU3ZmMKICAgICAg
ICByMTAgPSAweGUzZjAyYTU2CmlwX2lucHV0KCkgYXQgaXBfaW5wdXQrMHhhMTgKICAgICAgICAg
cGMgPSAweGMwNDQxODg0ICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgx
MDApCiAgICAgICAgIHNwID0gMHhlMmEwYmM1OCAgZnAgPSAweGUyYTBiYzgwCiAgICAgICAgIHI0
ID0gMHgwMDAzYTczYiAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg
cjcgPSAweGMwYjViNGI0CiAgICAgICAgIHI4ID0gMHhlNDQxN2FjMCAgcjkgPSAweDVlNGE2ZjI4
CiAgICAgICAgcjEwID0gMHgwMDAwMDAwOApuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0aXNy
X2Rpc3BhdGNoX3NyYysweDEwMAogICAgICAgICBwYyA9IDB4YzA0MTQyNmMgIGxyID0gMHhjMDQw
YjlhMCAoZXRoZXJfZGVtdXgrMHgxYzgpCiAgICAgICAgIHNwID0gMHhlMmEwYmM4OCAgZnAgPSAw
eGUyYTBiY2EwCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAwCiAgICAg
ICAgIHI2ID0gMHgwMDAwMDgwMCAgcjcgPSAweGUzMjQ0NDAwCiAgICAgICAgIHI4ID0gMHhlNDQx
N2FjMCAgcjkgPSAweDVlNGE2ZjI4CiAgICAgICAgcjEwID0gMHgwMDAwMDAwOApldGhlcl9kZW11
eCgpIGF0IGV0aGVyX2RlbXV4KzB4MWM4CiAgICAgICAgIHBjID0gMHhjMDQwYjlhMCAgbHIgPSAw
eGMwNDBkMjJjIChldGhlcl9uaF9pbnB1dCsweDUxNCkKICAgICAgICAgc3AgPSAweGUyYTBiY2E4
ICBmcCA9IDB4ZTJhMGJkMTAKICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4ZTNmMDJh
MDAKICAgICAgICAgcjYgPSAweGUzZjAyYTQ4ICByNyA9IDB4MDAwMDAwMDAKZXRoZXJfbmhfaW5w
dXQoKSBhdCBldGhlcl9uaF9pbnB1dCsweDUxNAogICAgICAgICBwYyA9IDB4YzA0MGQyMmMgIGxy
ID0gMHhjMDQxNDI2YyAobmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMCkKICAgICAgICAgc3AgPSAw
eGUyYTBiZDE4ICBmcCA9IDB4ZTJhMGJkNDAKICAgICAgICAgcjQgPSAweDAwMDUwZTg4ICByNSA9
IDB4ZTNmMDJhMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4YzBiNWI1MzQKICAg
ICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjAKICAgICAgICByMTAgPSAweDAw
MDAwMDAwCm5ldGlzcl9kaXNwYXRjaF9zcmMoKSBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MTAw
CiAgICAgICAgIHBjID0gMHhjMDQxNDI2YyAgbHIgPSAweGMwNDBiZTk0IChldGhlcl9pbnB1dCsw
eDhjKQogICAgICAgICBzcCA9IDB4ZTJhMGJkNDggIGZwID0gMHhlMmEwYmQ4MAogICAgICAgICBy
NCA9IDB4ZTMyNDQ0MDAgIHI1ID0gMHgwMDAwMDAwMAogICAgICAgICByNiA9IDB4ZTNmMDJhMDAg
IHI3ID0gMHgwMDAwMDAwMAogICAgICAgICByOCA9IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAy
MAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDAKZXRoZXJfaW5wdXQoKSBhdCBldGhlcl9pbnB1dCsw
eDhjCiAgICAgICAgIHBjID0gMHhjMDQwYmU5NCAgbHIgPSAweGUyZmQ4MTMwICgkYS44KzB4MTI4
KQogICAgICAgICBzcCA9IDB4ZTJhMGJkODggIGZwID0gMHhlMmEwYmRiOAogICAgICAgICByNCA9
IDB4YzU3ZjVjOGMgIHI1ID0gMHgwMDAwMDAwMAogICAgICAgICByNiA9IDB4ZTMyNDQ0MDAgIHI3
ID0gMHhjNTdmNWM4MAogICAgICAgICByOCA9IDB4ZTJmZTkxNzAgIHI5ID0gMHhjMDkzODMyOAog
ICAgICAgIHIxMCA9IDB4ZTJhMGJkODgKJGEuOCgpIGF0ICRhLjgrMHgxMjgKICAgICAgICAgcGMg
PSAweGUyZmQ4MTMwICBsciA9IDB4YzAyYTFlZTAgKGl0aHJlYWRfbG9vcCsweDI2OCkKICAgICAg
ICAgc3AgPSAweGUyYTBiZGMwICBmcCA9IDB4ZTJhMGJlMjAKICAgICAgICAgcjQgPSAweGRiNzdm
NjQwICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweGUzYjNmNTQ0ICByNyA9IDB4ZTNi
M2Y1MDAKICAgICAgICAgcjggPSAweGMwNzdjZWM5ICByOSA9IDB4ZTNiM2Y1MDgKICAgICAgICBy
MTAgPSAweGRiNzdmNjQwCml0aHJlYWRfbG9vcCgpIGF0IGl0aHJlYWRfbG9vcCsweDI2OAogICAg
ICAgICBwYyA9IDB4YzAyYTFlZTAgIGxyID0gMHhjMDI5ZTA4OCAoZm9ya19leGl0KzB4YTApCiAg
ICAgICAgIHNwID0gMHhlMmEwYmUyOCAgZnAgPSAweGUyYTBiZTQwCiAgICAgICAgIHI0ID0gMHhl
Mjk0ZTAwMCAgcjUgPSAweGQ3OTY3MDAwCiAgICAgICAgIHI2ID0gMHhjMDJhMWM3OCAgcjcgPSAw
eGRiNmU4MTIwCiAgICAgICAgIHI4ID0gMHhlMmEwYmU0OCAgcjkgPSAweDAwMDAwMDAwCiAgICAg
ICAgcjEwID0gMHgwMDAwMDAwMApmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHhhMAogICAgICAg
ICBwYyA9IDB4YzAyOWUwODggIGxyID0gMHhjMDVjYTg3MCAoc3dpX2V4aXQpCiAgICAgICAgIHNw
ID0gMHhlMmEwYmU0OCAgZnAgPSAweDAwMDAwMDAwCiAgICAgICAgIHI0ID0gMHhjMDJhMWM3OCAg
cjUgPSAweGRiNmU4MTIwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweDAwMDAwMDAw
CiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMCByMTAgPSAweDAwMDAwMDAwCnN3aV9leGl0KCkgYXQg
c3dpX2V4aXQKICAgICAgICAgcGMgPSAweGMwNWNhODcwICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9l
eGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMA==

--b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48ZGl2IHN0
eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPkl0J3MgcnVubmluZyAx
NC4wLUNVUlJFTlQgYXJtdjcgbWFpbi1uMjUyOTgzLWQyMWU3MWVmY2UzOTxicj48L2Rpdj48ZGl2
IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48
L2Rpdj48cHJlPktlcm5lbCBwYWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBh
YmxlIGxvY2tzIGhlbGQ6DQpleGNsdXNpdmUgc2xlZXAgbXV0ZXggZXBhaXJpZHggKGVwYWlyaWR4
KSByID0gMCAoMHhlMmZlOTE2MCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldC9pZl9lcGFpci5j
OjE2NQ0Kc3RhY2sgYmFja3RyYWNlOg0KIzAgMHhjMDM1NThmOCBhdCB3aXRuZXNzX2RlYnVnZ2Vy
KzB4N2MNCiMxIDB4YzAzNTZiM2MgYXQgd2l0bmVzc193YXJuKzB4M2ZjDQojMiAweGMwNWViM2M4
IGF0IGFib3J0X2hhbmRsZXIrMHgxZDgNCiMzIDB4YzA1Y2E4ZTAgYXQgZXhjZXB0aW9uX2V4aXQr
MA0KIzQgMHhjMDQ3NTkyOCBhdCB1ZHBfaW5wdXQrMHgxYzANCiM1IDB4YzA0NDE4ODQgYXQgaXBf
aW5wdXQrMHhhMTgNCiM2IDB4YzA0MTQyNmMgYXQgbmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0K
IzcgMHhjMDQwYjlhMCBhdCBldGhlcl9kZW11eCsweDFjOA0KIzggMHhjMDQwZDIyYyBhdCBldGhl
cl9uaF9pbnB1dCsweDUxNA0KIzkgMHhjMDQxNDI2YyBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4
MTAwDQojMTAgMHhjMDQwYmU5NCBhdCBldGhlcl9pbnB1dCsweDhjDQojMTEgMHhlMmZkODEzMCBh
dCAkYS44KzB4MTI4DQojMTIgMHhjMDJhMWVlMCBhdCBpdGhyZWFkX2xvb3ArMHgyNjgNCiMxMyAw
eGMwMjllMDg4IGF0IGZvcmtfZXhpdCsweGEwDQojMTQgMHhjMDVjYTg3MCBhdCBzd2lfZXhpdCsw
DQpGYXRhbCBrZXJuZWwgbW9kZSBkYXRhIGFib3J0OiAnQWxpZ25tZW50IEZhdWx0JyBvbiByZWFk
DQp0cmFwZnJhbWU6IDB4ZTJhMGJhZjANCkZTUj0wMDAwMDAwMSwgRkFSPWUzZjAyYTU2LCBzcHNy
PTIwMDAwMDEzDQpyMCA9MDAwMDAwMDAsIHIxID0wMDAwMDAwMSwgcjIgPTAwMDAwMDAxLCByMyA9
MDAwMDBhMGENCnI0ID0wMDAwMDAwMCwgcjUgPWUzZjAyYTZhLCByNiA9ZTNmMDJhNTYsIHI3ID0w
MDAwMDA0NA0KcjggPTAwMDAwMDQ0LCByOSA9YzBhZjk1NWMsIHIxMD0wMDAwMDAxNCwgcjExPWUy
YTBiYzEwDQpyMTI9MDAwMDAwMDAsIHNzcD1lMmEwYmI4MCwgc2xyPWMwNDQxODg0LCBwYyA9YzA0
NzU5MjgNCg0KcGFuaWM6IEZhdGFsIGFib3J0DQpjcHVpZCA9IDANCnRpbWUgPSAxNjQ1MDA0ODg5
DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxm
DQogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhjMDA3YWM0OCAoZGJfdHJhY2Vfc2Vs
Zl93cmFwcGVyKzB4MzApDQogICAgICAgICBzcCA9IDB4ZTJhMGI4YzggIGZwID0gMHhlMmEwYjll
MA0KZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MzAN
CiAgICAgICAgIHBjID0gMHhjMDA3YWM0OCAgbHIgPSAweGMwMmUyNTljICh2cGFuaWMrMHgxNzAp
DQogICAgICAgICBzcCA9IDB4ZTJhMGI5ZTggIGZwID0gMHhlMmEwYmEwOA0KICAgICAgICAgcjQg
PSAweDAwMDAwMTAwICByNSA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI2ID0gMHhjMDc3ZjY3MCAg
cjcgPSAweGMwOTBkOTEwDQp2cGFuaWMoKSBhdCB2cGFuaWMrMHgxNzANCiAgICAgICAgIHBjID0g
MHhjMDJlMjU5YyAgbHIgPSAweGMwMmUyMzRjIChkb2FkdW1wKQ0KICAgICAgICAgc3AgPSAweGUy
YTBiYTEwICBmcCA9IDB4ZTJhMGJhMTQNCiAgICAgICAgIHI0ID0gMHhlMmEwYmFmMCAgcjUgPSAw
eDAwMDAwMDEzDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDAwMQ0KICAg
ICAgICAgcjggPSAweDAwMDAwMDAxICByOSA9IDB4ZTI5NGUwMDANCiAgICAgICAgcjEwID0gMHhl
M2YwMmE1Ng0KZG9hZHVtcCgpIGF0IGRvYWR1bXANCiAgICAgICAgIHBjID0gMHhjMDJlMjM0YyAg
bHIgPSAweGMwNWViYTE4IChhYm9ydF9hbGlnbikNCiAgICAgICAgIHNwID0gMHhlMmEwYmExYyAg
ZnAgPSAweGUyYTBiYTQ4DQogICAgICAgICByNCA9IDB4ZTNmMDJhNTYgIHI1ID0gMHhlMmEwYmEx
NA0KICAgICAgICAgcjYgPSAweGMwMmUyMzRjIHIxMCA9IDB4ZTJhMGJhMWMNCmFib3J0X2FsaWdu
KCkgYXQgYWJvcnRfYWxpZ24NCiAgICAgICAgIHBjID0gMHhjMDVlYmExOCAgbHIgPSAweGMwNWVi
NTE4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiYTUwICBmcCA9
IDB4ZTJhMGJhZTgNCiAgICAgICAgIHI0ID0gMHgwMDAwMDAxMyAgcjUgPSAweGUzZjAyYTU2DQph
Ym9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxlcisweDMyOA0KICAgICAgICAgcGMgPSAweGMw
NWViNTE4ICBsciA9IDB4YzA1Y2E4ZTAgKGV4Y2VwdGlvbl9leGl0KQ0KICAgICAgICAgc3AgPSAw
eGUyYTBiYWYwICBmcCA9IDB4ZTJhMGJjMTANCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUg
PSAweGUzZjAyYTZhDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NA0K
ICAgICAgICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMNCiAgICAgICAgcjEwID0g
MHgwMDAwMDAxNA0KZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdA0KICAgICAgICAg
cGMgPSAweGMwNWNhOGUwICBsciA9IDB4YzA0NDE4ODQgKGlwX2lucHV0KzB4YTE4KQ0KICAgICAg
ICAgc3AgPSAweGUyYTBiYjgwICBmcCA9IDB4ZTJhMGJjMTANCiAgICAgICAgIHIwID0gMHgwMDAw
MDAwMCAgcjEgPSAweDAwMDAwMDAxDQogICAgICAgICByMiA9IDB4MDAwMDAwMDEgIHIzID0gMHgw
MDAwMGEwYQ0KICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4ZTNmMDJhNmENCiAgICAg
ICAgIHI2ID0gMHhlM2YwMmE1NiAgcjcgPSAweDAwMDAwMDQ0DQogICAgICAgICByOCA9IDB4MDAw
MDAwNDQgIHI5ID0gMHhjMGFmOTU1Yw0KICAgICAgICByMTAgPSAweDAwMDAwMDE0IHIxMiA9IDB4
MDAwMDAwMDANCnVkcF9pbnB1dCgpIGF0IHVkcF9pbnB1dCsweDFjMA0KICAgICAgICAgcGMgPSAw
eGMwNDc1OTI4ICBsciA9IDB4YzA0NDE4ODQgKGlwX2lucHV0KzB4YTE4KQ0KICAgICAgICAgc3Ag
PSAweGUyYTBiYzE4ICBmcCA9IDB4ZTJhMGJjNTANCiAgICAgICAgIHI0ID0gMHgwMDAyMmU3NSAg
cjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4MDAwMDAwMTQgIHI3ID0gMHgwMDAwMDBm
Yg0KICAgICAgICAgcjggPSAweGMwOTBkOTEwICByOSA9IDB4YzA5NDU3ZmMNCiAgICAgICAgcjEw
ID0gMHhlM2YwMmE1Ng0KaXBfaW5wdXQoKSBhdCBpcF9pbnB1dCsweGExOA0KICAgICAgICAgcGMg
PSAweGMwNDQxODg0ICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAp
DQogICAgICAgICBzcCA9IDB4ZTJhMGJjNTggIGZwID0gMHhlMmEwYmM4MA0KICAgICAgICAgcjQg
PSAweDAwMDNhNzNiICByNSA9IDB4ZTNmMDJhMDANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg
cjcgPSAweGMwYjViNGI0DQogICAgICAgICByOCA9IDB4ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYy
OA0KICAgICAgICByMTAgPSAweDAwMDAwMDA4DQpuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0
aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0KICAgICAgICAgcGMgPSAweGMwNDE0MjZjICBsciA9IDB4
YzA0MGI5YTAgKGV0aGVyX2RlbXV4KzB4MWM4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiYzg4ICBm
cCA9IDB4ZTJhMGJjYTANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAw
DQogICAgICAgICByNiA9IDB4MDAwMDA4MDAgIHI3ID0gMHhlMzI0NDQwMA0KICAgICAgICAgcjgg
PSAweGU0NDE3YWMwICByOSA9IDB4NWU0YTZmMjgNCiAgICAgICAgcjEwID0gMHgwMDAwMDAwOA0K
ZXRoZXJfZGVtdXgoKSBhdCBldGhlcl9kZW11eCsweDFjOA0KICAgICAgICAgcGMgPSAweGMwNDBi
OWEwICBsciA9IDB4YzA0MGQyMmMgKGV0aGVyX25oX2lucHV0KzB4NTE0KQ0KICAgICAgICAgc3Ag
PSAweGUyYTBiY2E4ICBmcCA9IDB4ZTJhMGJkMTANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAg
cjUgPSAweGUzZjAyYTAwDQogICAgICAgICByNiA9IDB4ZTNmMDJhNDggIHI3ID0gMHgwMDAwMDAw
MA0KZXRoZXJfbmhfaW5wdXQoKSBhdCBldGhlcl9uaF9pbnB1dCsweDUxNA0KICAgICAgICAgcGMg
PSAweGMwNDBkMjJjICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAp
DQogICAgICAgICBzcCA9IDB4ZTJhMGJkMTggIGZwID0gMHhlMmEwYmQ0MA0KICAgICAgICAgcjQg
PSAweDAwMDUwZTg4ICByNSA9IDB4ZTNmMDJhMDANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg
cjcgPSAweGMwYjViNTM0DQogICAgICAgICByOCA9IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAy
MA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0
aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0KICAgICAgICAgcGMgPSAweGMwNDE0MjZjICBsciA9IDB4
YzA0MGJlOTQgKGV0aGVyX2lucHV0KzB4OGMpDQogICAgICAgICBzcCA9IDB4ZTJhMGJkNDggIGZw
ID0gMHhlMmEwYmQ4MA0KICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4MDAwMDAwMDAN
CiAgICAgICAgIHI2ID0gMHhlM2YwMmEwMCAgcjcgPSAweDAwMDAwMDAwDQogICAgICAgICByOCA9
IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAyMA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpl
dGhlcl9pbnB1dCgpIGF0IGV0aGVyX2lucHV0KzB4OGMNCiAgICAgICAgIHBjID0gMHhjMDQwYmU5
NCAgbHIgPSAweGUyZmQ4MTMwICgkYS44KzB4MTI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiZDg4
ICBmcCA9IDB4ZTJhMGJkYjgNCiAgICAgICAgIHI0ID0gMHhjNTdmNWM4YyAgcjUgPSAweDAwMDAw
MDAwDQogICAgICAgICByNiA9IDB4ZTMyNDQ0MDAgIHI3ID0gMHhjNTdmNWM4MA0KICAgICAgICAg
cjggPSAweGUyZmU5MTcwICByOSA9IDB4YzA5MzgzMjgNCiAgICAgICAgcjEwID0gMHhlMmEwYmQ4
OA0KJGEuOCgpIGF0ICRhLjgrMHgxMjgNCiAgICAgICAgIHBjID0gMHhlMmZkODEzMCAgbHIgPSAw
eGMwMmExZWUwIChpdGhyZWFkX2xvb3ArMHgyNjgpDQogICAgICAgICBzcCA9IDB4ZTJhMGJkYzAg
IGZwID0gMHhlMmEwYmUyMA0KICAgICAgICAgcjQgPSAweGRiNzdmNjQwICByNSA9IDB4MDAwMDAw
MDANCiAgICAgICAgIHI2ID0gMHhlM2IzZjU0NCAgcjcgPSAweGUzYjNmNTAwDQogICAgICAgICBy
OCA9IDB4YzA3N2NlYzkgIHI5ID0gMHhlM2IzZjUwOA0KICAgICAgICByMTAgPSAweGRiNzdmNjQw
DQppdGhyZWFkX2xvb3AoKSBhdCBpdGhyZWFkX2xvb3ArMHgyNjgNCiAgICAgICAgIHBjID0gMHhj
MDJhMWVlMCAgbHIgPSAweGMwMjllMDg4IChmb3JrX2V4aXQrMHhhMCkNCiAgICAgICAgIHNwID0g
MHhlMmEwYmUyOCAgZnAgPSAweGUyYTBiZTQwDQogICAgICAgICByNCA9IDB4ZTI5NGUwMDAgIHI1
ID0gMHhkNzk2NzAwMA0KICAgICAgICAgcjYgPSAweGMwMmExYzc4ICByNyA9IDB4ZGI2ZTgxMjAN
CiAgICAgICAgIHI4ID0gMHhlMmEwYmU0OCAgcjkgPSAweDAwMDAwMDAwDQogICAgICAgIHIxMCA9
IDB4MDAwMDAwMDANCmZvcmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweGEwDQogICAgICAgICBwYyA9
IDB4YzAyOWUwODggIGxyID0gMHhjMDVjYTg3MCAoc3dpX2V4aXQpDQogICAgICAgICBzcCA9IDB4
ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjQgPSAweGMwMmExYzc4ICByNSA9
IDB4ZGI2ZTgxMjANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweDAwMDAwMDAwDQog
ICAgICAgICByOCA9IDB4MDAwMDAwMDAgcjEwID0gMHgwMDAwMDAwMA0Kc3dpX2V4aXQoKSBhdCBz
d2lfZXhpdA0KICAgICAgICAgcGMgPSAweGMwNWNhODcwICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9l
eGl0KQ0KICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBmcCA9IDB4MDAwMDAwMDANCktEQjogZW50
ZXI6IHBhbmljDQpbIHRocmVhZCBwaWQgMTEgdGlkIDEwMDE3NCBdDQpTdG9wcGVkIGF0ICAgICAg
a2RiX2VudGVyKzB4NTg6IGxkcmIgICAgcjE1LCBbcjE1LCByMTUsIHJvciByMTVdIQ0KZGImZ3Q7
IGJ0DQpUcmFjaW5nIHBpZCAxMSB0aWQgMTAwMTc0IHRkIDB4ZTI5NGUwMDANCmRiX3RyYWNlX3Nl
bGYoKSBhdCBkYl90cmFjZV9zZWxmDQogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhj
MDA3NzZmNCAoZGJfc3RhY2tfdHJhY2UrMHgxNDApDQogICAgICAgICBzcCA9IDB4ZTJhMGI3MTgg
IGZwID0gMHhlMmEwYjczMA0KZGJfc3RhY2tfdHJhY2UoKSBhdCBkYl9zdGFja190cmFjZSsweDE0
MA0KICAgICAgICAgcGMgPSAweGMwMDc3NmY0ICBsciA9IDB4YzAwNzc0MDQgKGRiX2NvbW1hbmQr
MHgzOWMpDQogICAgICAgICBzcCA9IDB4ZTJhMGI3MzggIGZwID0gMHhlMmEwYjdkOA0KICAgICAg
ICAgcjQgPSAweGMwNzI0NjQ2ICByNSA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI2ID0gMHhjMGFm
OTU1YyByMTAgPSAweGMwOGE4YmEwDQpkYl9jb21tYW5kKCkgYXQgZGJfY29tbWFuZCsweDM5Yw0K
ICAgICAgICAgcGMgPSAweGMwMDc3NDA0ICBsciA9IDB4YzAwNzcwNDAgKGRiX2NvbW1hbmRfbG9v
cCsweDY0KQ0KICAgICAgICAgc3AgPSAweGUyYTBiN2UwICBmcCA9IDB4ZTJhMGI3ZjANCiAgICAg
ICAgIHI0ID0gMHhjMDc4NmRjZCAgcjUgPSAweGMwNzg2NDQ1DQogICAgICAgICByNiA9IDB4YzA5
NWVmNWMgIHI3ID0gMHhjMGFmYjg1OA0KICAgICAgICAgcjggPSAweGMwYWZiODM4ICByOSA9IDB4
YzA4YThmMzgNCiAgICAgICAgcjEwID0gMHhjMDkzODc3OA0KZGJfY29tbWFuZF9sb29wKCkgYXQg
ZGJfY29tbWFuZF9sb29wKzB4NjQNCiAgICAgICAgIHBjID0gMHhjMDA3NzA0MCAgbHIgPSAweGMw
MDdhZGNjIChkYl90cmFwKzB4MTI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiN2Y4ICBmcCA9IDB4
ZTJhMGI5MTANCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGMwOTVlZjUwDQogICAg
ICAgICByNiA9IDB4ZTJhMGI5NDggcjEwID0gMHhjMDkzODc3OA0KZGJfdHJhcCgpIGF0IGRiX3Ry
YXArMHgxMjgNCiAgICAgICAgIHBjID0gMHhjMDA3YWRjYyAgbHIgPSAweGMwMzMyNTQ0IChrZGJf
dHJhcCsweDFiOCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjkxOCAgZnAgPSAweGUyYTBiOTQwDQog
ICAgICAgICByNCA9IDB4MDAwMDAwMDAgIHI1ID0gMHgwMDAwMDAwMQ0KICAgICAgICAgcjYgPSAw
eGUyYTBiOTQ4ICByNyA9IDB4YzBhZmI4NTgNCmtkYl90cmFwKCkgYXQga2RiX3RyYXArMHgxYjgN
CiAgICAgICAgIHBjID0gMHhjMDMzMjU0NCAgbHIgPSAweGMwNWNhOGUwIChleGNlcHRpb25fZXhp
dCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjk0OCAgZnAgPSAweGUyYTBiOWUwDQogICAgICAgICBy
NCA9IDB4NjAwMDAxZDMgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweGMwNzdmNjcw
ICByNyA9IDB4YzA5MGQ5MTANCiAgICAgICAgIHI4ID0gMHhlMjk0ZTAwMCAgcjkgPSAweGUyYTBi
YTFjDQogICAgICAgIHIxMCA9IDB4YzBhZWJiMzANCmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0
aW9uX2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwMzMxYWJjIChrZGJf
ZW50ZXIrMHg0OCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjlkOCAgZnAgPSAweGUyYTBiOWUwDQog
ICAgICAgICByMCA9IDB4YzBhZmI4NDggIHIxID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjIgPSAw
eDAwMDAwMDEyICByMyA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI0ID0gMHhjMDc5ODcwNCAgcjUg
PSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4YzA3N2Y2NzAgIHI3ID0gMHhjMDkwZDkxMA0K
ICAgICAgICAgcjggPSAweGUyOTRlMDAwICByOSA9IDB4ZTJhMGJhMWMNCiAgICAgICAgcjEwID0g
MHhjMGFlYmIzMCByMTIgPSAweDIwMDAwMDAwDQprZGJfZW50ZXIoKSBhdCBrZGJfZW50ZXIrMHg1
Yw0KICAgICAgICAgcGMgPSAweGMwMzMxYWQwICBsciA9IDB4YzAyZTI1ZTggKHZwYW5pYysweDFi
YykNCiAgICAgICAgIHNwID0gMHhlMmEwYjllOCAgZnAgPSAweGUyYTBiYTA4DQogICAgICAgICBy
NCA9IDB4MDAwMDAxMDAgcjEwID0gMHhjMGFlYmIzMA0KdnBhbmljKCkgYXQgdnBhbmljKzB4MWJj
DQogICAgICAgICBwYyA9IDB4YzAyZTI1ZTggIGxyID0gMHhjMDJlMjM0YyAoZG9hZHVtcCkNCiAg
ICAgICAgIHNwID0gMHhlMmEwYmExMCAgZnAgPSAweGUyYTBiYTE0DQogICAgICAgICByNCA9IDB4
ZTJhMGJhZjAgIHI1ID0gMHgwMDAwMDAxMw0KICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9
IDB4MDAwMDAwMDENCiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMSAgcjkgPSAweGUyOTRlMDAwDQog
ICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYNCmRvYWR1bXAoKSBhdCBkb2FkdW1wDQogICAgICAgICBw
YyA9IDB4YzAyZTIzNGMgIGxyID0gMHhjMDVlYmExOCAoYWJvcnRfYWxpZ24pDQogICAgICAgICBz
cCA9IDB4ZTJhMGJhMWMgIGZwID0gMHhlMmEwYmE0OA0KICAgICAgICAgcjQgPSAweGUzZjAyYTU2
ICByNSA9IDB4ZTJhMGJhMTQNCiAgICAgICAgIHI2ID0gMHhjMDJlMjM0YyByMTAgPSAweGUyYTBi
YTFjDQphYm9ydF9hbGlnbigpIGF0IGFib3J0X2FsaWduDQogICAgICAgICBwYyA9IDB4YzA1ZWJh
MTggIGxyID0gMHhjMDVlYjUxOCAoYWJvcnRfaGFuZGxlcisweDMyOCkNCiAgICAgICAgIHNwID0g
MHhlMmEwYmE1MCAgZnAgPSAweGUyYTBiYWU4DQogICAgICAgICByNCA9IDB4MDAwMDAwMTMgIHI1
ID0gMHhlM2YwMmE1Ng0KYWJvcnRfaGFuZGxlcigpIGF0IGFib3J0X2hhbmRsZXIrMHgzMjgNCiAg
ICAgICAgIHBjID0gMHhjMDVlYjUxOCAgbHIgPSAweGMwNWNhOGUwIChleGNlcHRpb25fZXhpdCkN
CiAgICAgICAgIHNwID0gMHhlMmEwYmFmMCAgZnAgPSAweGUyYTBiYzEwDQogICAgICAgICByNCA9
IDB4MDAwMDAwMDAgIHI1ID0gMHhlM2YwMmE2YQ0KICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICBy
NyA9IDB4MDAwMDAwNDQNCiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMwYWY5NTVj
DQogICAgICAgIHIxMCA9IDB4MDAwMDAwMTQNCmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0aW9u
X2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1
dCsweGExOCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmI4MCAgZnAgPSAweGUyYTBiYzEwDQogICAg
ICAgICByMCA9IDB4MDAwMDAwMDAgIHIxID0gMHgwMDAwMDAwMQ0KICAgICAgICAgcjIgPSAweDAw
MDAwMDAxICByMyA9IDB4MDAwMDBhMGENCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAw
eGUzZjAyYTZhDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NA0KICAg
ICAgICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMNCiAgICAgICAgcjEwID0gMHgw
MDAwMDAxNCByMTIgPSAweDAwMDAwMDAwDQp1ZHBfaW5wdXQoKSBhdCB1ZHBfaW5wdXQrMHgxYzAN
CiAgICAgICAgIHBjID0gMHhjMDQ3NTkyOCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1dCsweGEx
OCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmMxOCAgZnAgPSAweGUyYTBiYzUwDQogICAgICAgICBy
NCA9IDB4MDAwMjJlNzUgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweDAwMDAwMDE0
ICByNyA9IDB4MDAwMDAwZmINCiAgICAgICAgIHI4ID0gMHhjMDkwZDkxMCAgcjkgPSAweGMwOTQ1
N2ZjDQogICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYNCmlwX2lucHV0KCkgYXQgaXBfaW5wdXQrMHhh
MTgNCiAgICAgICAgIHBjID0gMHhjMDQ0MTg4NCAgbHIgPSAweGMwNDE0MjZjIChuZXRpc3JfZGlz
cGF0Y2hfc3JjKzB4MTAwKQ0KICAgICAgICAgc3AgPSAweGUyYTBiYzU4ICBmcCA9IDB4ZTJhMGJj
ODANCiAgICAgICAgIHI0ID0gMHgwMDAzYTczYiAgcjUgPSAweGUzZjAyYTAwDQogICAgICAgICBy
NiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjRiNA0KICAgICAgICAgcjggPSAweGU0NDE3YWMw
ICByOSA9IDB4NWU0YTZmMjgNCiAgICAgICAgcjEwID0gMHgwMDAwMDAwOA0KbmV0aXNyX2Rpc3Bh
dGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDANCiAgICAgICAgIHBjID0gMHhj
MDQxNDI2YyAgbHIgPSAweGMwNDBiOWEwIChldGhlcl9kZW11eCsweDFjOCkNCiAgICAgICAgIHNw
ID0gMHhlMmEwYmM4OCAgZnAgPSAweGUyYTBiY2EwDQogICAgICAgICByNCA9IDB4ZTMyNDQ0MDAg
IHI1ID0gMHhlM2YwMmEwMA0KICAgICAgICAgcjYgPSAweDAwMDAwODAwICByNyA9IDB4ZTMyNDQ0
MDANCiAgICAgICAgIHI4ID0gMHhlNDQxN2FjMCAgcjkgPSAweDVlNGE2ZjI4DQogICAgICAgIHIx
MCA9IDB4MDAwMDAwMDgNCmV0aGVyX2RlbXV4KCkgYXQgZXRoZXJfZGVtdXgrMHgxYzgNCiAgICAg
ICAgIHBjID0gMHhjMDQwYjlhMCAgbHIgPSAweGMwNDBkMjJjIChldGhlcl9uaF9pbnB1dCsweDUx
NCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmNhOCAgZnAgPSAweGUyYTBiZDEwDQogICAgICAgICBy
NCA9IDB4ZTMyNDQ0MDAgIHI1ID0gMHhlM2YwMmEwMA0KICAgICAgICAgcjYgPSAweGUzZjAyYTQ4
ICByNyA9IDB4MDAwMDAwMDANCmV0aGVyX25oX2lucHV0KCkgYXQgZXRoZXJfbmhfaW5wdXQrMHg1
MTQNCiAgICAgICAgIHBjID0gMHhjMDQwZDIyYyAgbHIgPSAweGMwNDE0MjZjIChuZXRpc3JfZGlz
cGF0Y2hfc3JjKzB4MTAwKQ0KICAgICAgICAgc3AgPSAweGUyYTBiZDE4ICBmcCA9IDB4ZTJhMGJk
NDANCiAgICAgICAgIHI0ID0gMHgwMDA1MGU4OCAgcjUgPSAweGUzZjAyYTAwDQogICAgICAgICBy
NiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjUzNA0KICAgICAgICAgcjggPSAweDVlNGE2ZjI4
ICByOSA9IDB4MDAwMDAwMjANCiAgICAgICAgcjEwID0gMHgwMDAwMDAwMA0KbmV0aXNyX2Rpc3Bh
dGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDANCiAgICAgICAgIHBjID0gMHhj
MDQxNDI2YyAgbHIgPSAweGMwNDBiZTk0IChldGhlcl9pbnB1dCsweDhjKQ0KICAgICAgICAgc3Ag
PSAweGUyYTBiZDQ4ICBmcCA9IDB4ZTJhMGJkODANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAg
cjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4ZTNmMDJhMDAgIHI3ID0gMHgwMDAwMDAw
MA0KICAgICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjANCiAgICAgICAgcjEw
ID0gMHgwMDAwMDAwMA0KZXRoZXJfaW5wdXQoKSBhdCBldGhlcl9pbnB1dCsweDhjDQogICAgICAg
ICBwYyA9IDB4YzA0MGJlOTQgIGxyID0gMHhlMmZkODEzMCAoJGEuOCsweDEyOCkNCiAgICAgICAg
IHNwID0gMHhlMmEwYmQ4OCAgZnAgPSAweGUyYTBiZGI4DQogICAgICAgICByNCA9IDB4YzU3ZjVj
OGMgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweGUzMjQ0NDAwICByNyA9IDB4YzU3
ZjVjODANCiAgICAgICAgIHI4ID0gMHhlMmZlOTE3MCAgcjkgPSAweGMwOTM4MzI4DQogICAgICAg
IHIxMCA9IDB4ZTJhMGJkODgNCiRhLjgoKSBhdCAkYS44KzB4MTI4DQogICAgICAgICBwYyA9IDB4
ZTJmZDgxMzAgIGxyID0gMHhjMDJhMWVlMCAoaXRocmVhZF9sb29wKzB4MjY4KQ0KICAgICAgICAg
c3AgPSAweGUyYTBiZGMwICBmcCA9IDB4ZTJhMGJlMjANCiAgICAgICAgIHI0ID0gMHhkYjc3ZjY0
MCAgcjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4ZTNiM2Y1NDQgIHI3ID0gMHhlM2Iz
ZjUwMA0KICAgICAgICAgcjggPSAweGMwNzdjZWM5ICByOSA9IDB4ZTNiM2Y1MDgNCiAgICAgICAg
cjEwID0gMHhkYjc3ZjY0MA0KaXRocmVhZF9sb29wKCkgYXQgaXRocmVhZF9sb29wKzB4MjY4DQog
ICAgICAgICBwYyA9IDB4YzAyYTFlZTAgIGxyID0gMHhjMDI5ZTA4OCAoZm9ya19leGl0KzB4YTAp
DQogICAgICAgICBzcCA9IDB4ZTJhMGJlMjggIGZwID0gMHhlMmEwYmU0MA0KICAgICAgICAgcjQg
PSAweGUyOTRlMDAwICByNSA9IDB4ZDc5NjcwMDANCiAgICAgICAgIHI2ID0gMHhjMDJhMWM3OCAg
cjcgPSAweGRiNmU4MTIwDQogICAgICAgICByOCA9IDB4ZTJhMGJlNDggIHI5ID0gMHgwMDAwMDAw
MA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHhh
MA0KICAgICAgICAgcGMgPSAweGMwMjllMDg4ICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9leGl0KQ0K
ICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBmcCA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI0ID0g
MHhjMDJhMWM3OCAgcjUgPSAweGRiNmU4MTIwDQogICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3
ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjggPSAweDAwMDAwMDAwIHIxMCA9IDB4MDAwMDAwMDAN
CnN3aV9leGl0KCkgYXQgc3dpX2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYTg3MCAgbHIgPSAw
eGMwNWNhODcwIChzd2lfZXhpdCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmU0OCAgZnAgPSAweDAw
MDAwMDAwDQo8YnI+PC9wcmU+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp
emU6IDE0cHg7Ij48YnI+PC9kaXY+


--b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE--


From nobody Wed Feb 16 10:57:56 2022
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 0F32F1951644;
	Wed, 16 Feb 2022 10:58:01 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4JzFL075VYz4t2l;
	Wed, 16 Feb 2022 10:58:00 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1645009081;
	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=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=;
	b=YpCbdJ7UF9BBJPFpbGB6eNNKdn0NhQ2PHUoMHykU1TGc0rYmq5GDQsjR9izhbVGEeVra63
	CV3y4RKYm26J9p5FDChQ1HMfCo3B4SLfkcmh5hMWnUtDBmb72JIzWn4K/ZT134p8qnkjvv
	onui9KIfmijae3Qm3gk+CzR+rDDC1HxaNwOyjK7XvSCT5Eb9AsKYbqfY3Dz+TRv56GWRFm
	tId9FgVKXK/3+fK/tRgzuQjvdr9mlxYmuRzNS7gd23jzwgxPfcwuAHwXbTETAFidNN3PuX
	M63OiOjHObZQcwllrGohE86cCc4/ZyQY2Zt85cvr4jOOcXdxbieSZPJZ3nw0kg==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id BA7436B58;
	Wed, 16 Feb 2022 10:58:00 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 814233E215;
	Wed, 16 Feb 2022 11:57:57 +0100 (CET)
From: Kristof Provost 
To: qroxana 
Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: Kernel panic for if_epair
Date: Wed, 16 Feb 2022 11:57:56 +0100
X-Mailer: MailMate (1.14r5852)
Message-ID: 
In-Reply-To: 
References: 
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645009081;
	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=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=;
	b=yZUoFJahAm15WUho5MtbuX9JIARxeciHYMlCr3WzrUlXGAuIQnsBuVtX0MynHF8SxPjDTa
	Hv28SrMtj4Mo9V5huHsBknNY2XuLbqtykzZumHLjnkut5zhV2wWuJvKCYKIKeS1lXTWQkW
	lemGKt4Wf3zbVQo6/tfFwITc+H9F6Jd4X1q4I/qSZRCSPpyU4OBmkzQIbx+BIZyd3p8FLU
	3T+Vk+UDBdtM+dls6BO53Hm78Q4uI8gqODEoHvUrhYUEyLjR+py+zvJ4PrUassvaeveXGj
	ylX9YuV35/kOQq/jH21h92cSWHWX3W1W3ztiCH4SH8sMkDhlMEkPNRGzUb4KLg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645009081; a=rsa-sha256; cv=none;
	b=RTko03DgcKrCD4ohKSRTcyhbLlI9HHmiSZOjTUA5t/bwLi0gd+/umDBEVLWzJl8WYWmjM2
	jvsTJtEeAxlgn2TM7KzwbUvX8OXE6dASrNpui9nMD6cIFTQ9Tl10FSveTLJX5MrHUp2U5H
	BxEzXerqNHT4Hh8xUQm4Yo9i/jTzo2n4NQZtODkUDI34Cz0k8geISXoC53o6Aukystc2VO
	Kjq//6/SRTvHu5SKxp1J594M+2bOc1Udpjao3K6JQSTf2ZS3PCNgRKA2Rq2YxqhBjMsHMz
	rcxAcenYHHzodkwRhWR/SRd3LoEAi3QXvTiJzD7FEZRzbnH1cwKDZoSUcJ9FAA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1922
Lines: 46

On 16 Feb 2022, at 11:31, qroxana wrote:
> It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39
>
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex epairidx (epairidx) r =3D 0 (0xe2fe9160) locked @=
 /usr/src/sys/net/if_epair.c:165
> stack backtrace:
> #0 0xc03558f8 at witness_debugger+0x7c
> #1 0xc0356b3c at witness_warn+0x3fc
> #2 0xc05eb3c8 at abort_handler+0x1d8
> #3 0xc05ca8e0 at exception_exit+0
> #4 0xc0475928 at udp_input+0x1c0
> #5 0xc0441884 at ip_input+0xa18
> #6 0xc041426c at netisr_dispatch_src+0x100
> #7 0xc040b9a0 at ether_demux+0x1c8
> #8 0xc040d22c at ether_nh_input+0x514
> #9 0xc041426c at netisr_dispatch_src+0x100
> #10 0xc040be94 at ether_input+0x8c
> #11 0xe2fd8130 at $a.8+0x128
> #12 0xc02a1ee0 at ithread_loop+0x268
> #13 0xc029e088 at fork_exit+0xa0
> #14 0xc05ca870 at swi_exit+0
> Fatal kernel mode data abort: 'Alignment Fault' on read
> trapframe: 0xe2a0baf0
> FSR=3D00000001, FAR=3De3f02a56, spsr=3D20000013
> r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3D00000a0a
> r4 =3D00000000, r5 =3De3f02a6a, r6 =3De3f02a56, r7 =3D00000044
> r8 =3D00000044, r9 =3Dc0af955c, r10=3D00000014, r11=3De2a0bc10
> r12=3D00000000, ssp=3De2a0bb80, slr=3Dc0441884, pc =3Dc0475928
>
> panic: Fatal abort

That backtrace suggests an alignment fault in udp_input(), not an issue w=
ith if_epair.
There=E2=80=99s not even any mention of if_epair in that backtrace, but I=
 suppose it=E2=80=99s remotely possible that it=E2=80=99s in epair_intr()=
, calling epair_sintr() in #11. That would explain why the epair lock is =
held, at least.

Note that the epair code has been substantially reworked recently so if y=
ou retry with a recent (post 24f0bfbad57b9c3cb9b543a60b2ba00e4812c286) bu=
ild you won=E2=80=99t see the epair lock mentioned (assuming you can repr=
oduce the panic), but again, it doesn=E2=80=99t look to be involved here =
anyway.

Kristof

From nobody Wed Feb 16 12:19:15 2022
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 F1FA519B98B5
	for ; Wed, 16 Feb 2022 12:19:28 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(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 4JzH7z6XVxz3HQ5
	for ; Wed, 16 Feb 2022 12:19:27 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52a.google.com with SMTP id q17so3612506edd.4
        for ; Wed, 16 Feb 2022 04:19:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=CRbZ9YUmhgebkxRO1nIjaNEru76NbYO4hV+QlZS+cXg=;
        b=T6oQhnAX17JcjV8QX2aUNRtcJOK243LvadIVgjxxg/iZt4Di+imYz8sb4QNkNcHrau
         rQ8gxsOGlq3H8Ks4Gdz8VplAR2alffhsqqPN7bICbRgDacMg00bPu3sCCb/0fueQUfFd
         QaB8TP7UzoY/2R9xzBBImmRgVbterkEqee/SXvYAxnc3HRFOXwzrwa+gnTbQei+3HsWt
         6eIlf7p+owGdjcBtMR3vFvjHoYY9+DqpPuMA2jbmOyRBm8rDTK5lOD95mFPphkinsojw
         WmdQHj++ETkCcUPucXYH6u9hrhrhCM9gU6dlPm7UA3NSKKFqg/sUJ3SRWck5e8yaZqpR
         WxVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=CRbZ9YUmhgebkxRO1nIjaNEru76NbYO4hV+QlZS+cXg=;
        b=ZZFKjXcmQQ4SDjplsw/GOs816zNbF8Q+vpL3KUN5xwcAq9lYvttWVGBgOPcYHZ3brf
         /sJlRKbWi6IuP/Jh+fVtQg+FGh7PYfPsnCE4R+zuSXfzz0jmuPtBH0d0YW6qaVrBusDQ
         0AUsWpUJLnuWlOq9LFlHsu1sZxF1VaGFIviA8QYaMcnBK8t/14NpO7tr0pqCubJx/QFk
         LwjdQt9jbxxS3rrpTFeZrahEzpPligqbEiKzvGSBi9CtrRZ8ag4Yxr339cXQWjg3wiaX
         SadSBWKJMODeL2nGLEt1KV/KDTzUqu1co5GHGvPAybkbGWpJ8f3xZftooDMw+liT2LwP
         TtaQ==
X-Gm-Message-State: AOAM532yOrmZRbnlOADxjEAka9/jfl52Ov84niDsKI/DzveqEDKLQFzV
	VwKN5GBFUrseaJvszTRSvNfO7OYA18hAXwkytkIyF20TnEADUQ==
X-Google-Smtp-Source: ABdhPJwKLx9YbzaDyHw35yAqArW5TKXy4w05bPmM1OnTccTnv8A6KIjmBo/1Jed/+RN6AHtM2vU4mjOhmVsbyd6aUdo=
X-Received: by 2002:aa7:d80f:0:b0:410:d5c3:f770 with SMTP id
 v15-20020aa7d80f000000b00410d5c3f770mr2662139edq.279.1645013967012; Wed, 16
 Feb 2022 04:19:27 -0800 (PST)
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: 
 <202112231500.1BNF0FgX014693@mail.karels.net> 
  
 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Wed, 16 Feb 2022 20:19:15 +0800
Message-ID: 
Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0
To: "Daniel O'Connor" 
Cc: mike@karels.net, freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000002784ec05d821a9dc"
X-Rspamd-Queue-Id: 4JzH7z6XVxz3HQ5
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=T6oQhnAX;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6723
Lines: 129

--0000000000002784ec05d821a9dc
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 15, 2022 at 6:47 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
> On Tue, Feb 15, 2022 at 6:22 AM Daniel O'Connor 
> wrote:
>
>>
>>
>> > On 14 Feb 2022, at 23:10, Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>> > I just tried my new RPI4 board and it seems to work fine the same as my
>> old board. I just observed that the problem is when my VFD (vacuum
>> fluorescent display) device is connected to either of the two USB 3.0
>> ports, this device having uplcom(4) driver is not detected.
>>
>> I wonder if the VFD is causing interference - it likely has a high
>> voltage supply and those are notorious for generating electrical noise.
>>
>> > It's a Prolific USB-serial device having PL2303 chipset. However, when
>> plugged-in to USB 2.0 ports, this device is detected and functioning. I can
>> send characters with the echo command and redirect it to /dev/cuaU0 for
>> display without any problem. Other observations when this VFD device is
>> connected to either 3.0 ports, the 2.0 ports will not function i.e.
>> plugging-in any USB devices like my keyboard or my EMV reader. When this
>> device is also connected to either of the 2.0 ports, the other 2.0 port is
>> functioning for other USB devices while 3.0 ports are not. I attached two
>> dmesg outputs when the device is detected with 2.0 ports and undetected
>> with 3.0. I also include kldstat and usbdump.
>>
>> I would be curious if putting the VFD on a longer cable, or wrapping the
>> cable through a ferrite, or using an external hub fixes it.
>>
>> Any of those would give a bit more isolation between the VFD and USB3
>> hardware.
>>
>
> Thanks Daniel for your recommendations, I've tried extending it to a long
> cable and using an external USB hub however the outcomes were still the
> same, it cannot be detected. As per checking, this device has a default
> ferrite bead clamped over its USB cable.
>
> Using the same RPI 4B hardware, this VFD device has been tested as well
> with OpenBSD 6.9 and CentOS 8. They both work with USB 3.0 except OpenBSD
> system will panic the first time you plug-in the device but will work fine
> after a forced reboot or when you unplug and plug back the power.
>
> Thanks,
> Archimedes
>

Based on Fred's recommendation here
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001010.html
with FreeBSD 14.0-CURRENT, my VFD device is now detected and functioning in
3.0 while the rests of the ports are now functioning as well with my other
USB devices. So, I will now close this raised concern. Hoping this working
state will still be available until release.

Thanks for your inputs and support!

Best regards,
Archimedes

--0000000000002784ec05d821a9dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tue, Feb 15, 2022 at 6:47 PM Archimede=
s Gaviola <archimedes.ga=
viola@gmail.com> wrote:

On Tue, Feb 15, 2022 at 6:=
22 AM Daniel O'Connor <darius@dons.net.au> wrote:




> On 14 Feb 2022, at 23:10, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> I just tried my new RPI4 board and it seems to work fine the same as m=
y old board. I just observed that the problem is when my VFD (vacuum fluore=
scent display) device is connected to either of the two USB 3.0 ports, this=
 device having uplcom(4) driver is not detected.



I wonder if the VFD is causing interference - it likely has a high voltage =
supply and those are notorious for generating electrical noise.



> It's a Prolific USB-serial device having PL2303 chipset. However, =
when plugged-in to USB 2.0 ports, this device is detected and functioning. =
I can send characters with the echo command and redirect it to /dev/cuaU0 f=
or display without any problem. Other observations when this VFD device is =
connected to either 3.0 ports, the 2.0 ports will not function i.e. pluggin=
g-in any USB devices like my keyboard or my EMV reader. When this device is=
 also connected to either of the 2.0 ports, the other 2.0 port is functioni=
ng for other USB devices while 3.0 ports are not. I attached two dmesg outp=
uts when the device is detected with 2.0 ports and undetected with 3.0. I a=
lso include kldstat and usbdump.



I would be curious if putting the VFD on a longer cable, or wrapping the ca=
ble through a ferrite, or using an external hub fixes it.



Any of those would give a bit more isolation between the VFD and USB3 hardw=
are.



Based on Fred=
9;s recommendation here https://lists.freebsd.org/archives/freebs=
d-arm/2022-February/001010.html with FreeBSD 14.0-CURRENT, my VFD devic=
e is now detected and functioning in 3.0 while the rests of the ports are n=
ow functioning as well with my other USB devices. So, I will now close this=
 raised concern. Hoping this working state will still be available until re=
lease.

Thanks for your inputs and support!

Best regards,
Archimedes 
=C2=
=A0


--0000000000002784ec05d821a9dc--

From nobody Wed Feb 16 16:02:18 2022
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 50F2219D22EC
	for ; Wed, 16 Feb 2022 16:02:38 +0000 (UTC)
	(envelope-from swills@FreeBSD.org)
Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mouf.net", Issuer "mouf.net" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JzN5S1Y1rz4RSn;
	Wed, 16 Feb 2022 16:02:36 +0000 (UTC)
	(envelope-from swills@FreeBSD.org)
Received: from [10.0.1.27] (hs-nc-6b363c0412-470382-1.tingfiber.com [64.99.197.86])
	(authenticated bits=0)
	by mouf.net (8.14.9/8.14.9) with ESMTP id 21GG2Nmb052363
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 16 Feb 2022 16:02:28 GMT
	(envelope-from swills@FreeBSD.org)
Message-ID: 
Date: Wed, 16 Feb 2022 11:02:18 -0500
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:91.0) Gecko/20100101
 Thunderbird/91.5.1
Subject: Re: RockPro64 PCI
Content-Language: en-US
To: Daniel Engberg , freebsd-arm@FreeBSD.org
References: 
From: Steve Wills 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Wed, 16 Feb 2022 16:02:28 +0000 (UTC)
X-Spam-Status: No, score=0.0 required=4.5 tests=KHOP_HELO_FCRDNS,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net
X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net
X-Virus-Status: Clean
X-Rspamd-Queue-Id: 4JzN5S1Y1rz4RSn
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2607:fc50:0:4400:216:3eff:fe69:33b3 is neither permitted nor denied by domain of swills@FreeBSD.org) smtp.mailfrom=swills@FreeBSD.org
X-Spamd-Result: default: False [-2.68 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.64)[-0.639];
	 FREEFALL_USER(0.00)[swills];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[FreeBSD.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_HAM_SHORT(-0.94)[-0.941];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1435
Lines: 42

Hi,

On 2/14/22 21:22, Daniel Engberg wrote:
> Hi,
> 
> I've seen some reports on Linux that especially older NICs can be a bit 
> troublesome so can you have a look at what you exactly have? Even if it 
> doesn't work I'd like to add it to the wiki. Cards based on i340 and 
> i350 usually works fine though. I also have a snapshot of 13-STABLE from 
> November if you want to give it a try.

The card I'm trying to use shows up on my intel box as:

pcib7:  irq 18 at device 28.6 numa-domain 0 on pci1
pci7:  numa-domain 0 on pcib7
em1:  port 0xd000-0xd01f mem 
0xfbcc0000-0xfbcdffff,0xfbc00000-0xfbc7ffff,0xfbce0000-0xfbce3fff irq 18 
at device 0.0 numa-domain 0 on pci7
em1: EEPROM V1.8-0
em1: Using 1024 TX descriptors and 1024 RX descriptors
em1: Using 2 RX queues 2 TX queues
em1: Using MSI-X interrupts with 3 vectors
em1: Ethernet address: 00:1b:21:a8:5b:86
em1: netmap queues/slots: TX 2/1024, RX 2/1024

(I include the first two lines because they don't show up without the card.)

I guess I shouldn't expect this card to work given what I see here:

https://wiki.pine64.org/wiki/ROCKPro64_Hardware_Accessory_Compatibility#PCIe_devices

There's no mention of 82575 here:

https://wiki.freebsd.org/arm/RockChip#Tested_PCIe_devices_on_RockPro64

but maybe I'll try one of those just to see. If I have to track down an 
I350 base card, so be it...

Cheers,
Steve



From nobody Wed Feb 16 17:36:52 2022
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 5099819C4117
	for ; Wed, 16 Feb 2022 17:36:55 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::227])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JzQBG1qhrz4dW2;
	Wed, 16 Feb 2022 17:36:54 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: (Authenticated sender: daniel.engberg@pyret.net)
	by mail.gandi.net (Postfix) with ESMTPA id 4B6522000D;
	Wed, 16 Feb 2022 17:36:52 +0000 (UTC)
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
Date: Wed, 16 Feb 2022 18:36:52 +0100
From: Daniel Engberg 
To: Steve Wills 
Cc: freebsd-arm@freebsd.org
Subject: Re: RockPro64 PCI
In-Reply-To: 
References: 
 
Message-ID: 
X-Sender: diizzy@FreeBSD.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4JzQBG1qhrz4dW2
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::227 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org
X-Spamd-Result: default: False [2.37 / 15.00];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[diizzy];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_SPAM_MEDIUM(0.97)[0.968];
	 VIOLATED_DIRECT_SPF(3.50)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2857
Lines: 72

On 2022-02-16 17:02, Steve Wills wrote:
> Hi,
> 
> On 2/14/22 21:22, Daniel Engberg wrote:
>> Hi,
>> 
>> I've seen some reports on Linux that especially older NICs can be a 
>> bit troublesome so can you have a look at what you exactly have? Even 
>> if it doesn't work I'd like to add it to the wiki. Cards based on i340 
>> and i350 usually works fine though. I also have a snapshot of 
>> 13-STABLE from November if you want to give it a try.
> 
> The card I'm trying to use shows up on my intel box as:
> 
> pcib7:  irq 18 at device 28.6 numa-domain 0 on 
> pci1
> pci7:  numa-domain 0 on pcib7
> em1:  port 0xd000-0xd01f mem
> 0xfbcc0000-0xfbcdffff,0xfbc00000-0xfbc7ffff,0xfbce0000-0xfbce3fff irq
> 18 at device 0.0 numa-domain 0 on pci7
> em1: EEPROM V1.8-0
> em1: Using 1024 TX descriptors and 1024 RX descriptors
> em1: Using 2 RX queues 2 TX queues
> em1: Using MSI-X interrupts with 3 vectors
> em1: Ethernet address: 00:1b:21:a8:5b:86
> em1: netmap queues/slots: TX 2/1024, RX 2/1024
> 
> (I include the first two lines because they don't show up without the 
> card.)
> 
> I guess I shouldn't expect this card to work given what I see here:
> 
> https://wiki.pine64.org/wiki/ROCKPro64_Hardware_Accessory_Compatibility#PCIe_devices
> 
> There's no mention of 82575 here:
> 
> https://wiki.freebsd.org/arm/RockChip#Tested_PCIe_devices_on_RockPro64
> 
> but maybe I'll try one of those just to see. If I have to track down
> an I350 base card, so be it...
> 
> Cheers,
> Steve

Hi,

Going by the information you provided it seems to be this card?
https://www.intel.com/content/www/us/en/products/details/ethernet/gigabit-network-adapters/gigabit-ct-desktop-adapters.html
That's a rather old controller (PCIe 1.1) which should be backwards 
compatible however given the pricing of the SoC I wouldn't bet on it 
being fully PCIe tested/compliant but that's just a speculation on my 
behalf.
Unfortunately I don't have that old Intel NICs to test on my end either 
to verify.

https://forums.servethehome.com/index.php?threads/list-of-nics-and-their-equivalent-oem-parts.20974/ 
first page might be helpful in finding older I340-based cards at least.

Unfortunately I didn't find any listings of OEM models for i350-based 
cards although these are still (in general it seems) available as new so 
they may be scarce pulled/used.

I did also find these cheap (if you live in US) which seems to be based 
on the I340 chipset (not tested by me) which may also work:
https://www.ebay.com/itm/122501625474?epid=27017868551&hash=item1c85aa7682%3Ag%3AXXwAAOSwYvFZHK9e&LH_BIN=1
https://forum.netgate.com/topic/135149/riverbed-4-port-nic-how-to-convert-it-into-a-regular-nic

If you have anything else PCIe-based to test feel free to report back 
and I'll add it to the wiki

Best regards,
Daniel

From nobody Wed Feb 16 17:47:20 2022
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 3EC2E19C6558
	for ; Wed, 16 Feb 2022 17:47:33 +0000 (UTC)
	(envelope-from swills@FreeBSD.org)
Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mouf.net", Issuer "mouf.net" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JzQQX1Tw2z4gpp;
	Wed, 16 Feb 2022 17:47:32 +0000 (UTC)
	(envelope-from swills@FreeBSD.org)
Received: from [10.0.1.27] (hs-nc-6b363c0412-470382-1.tingfiber.com [64.99.197.86])
	(authenticated bits=0)
	by mouf.net (8.14.9/8.14.9) with ESMTP id 21GHlPVd061122
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Wed, 16 Feb 2022 17:47:30 GMT
	(envelope-from swills@FreeBSD.org)
Message-ID: <3e3473c3-a511-16a6-c233-0d0ef4ac0c61@FreeBSD.org>
Date: Wed, 16 Feb 2022 12:47:20 -0500
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:91.0) Gecko/20100101
 Thunderbird/91.5.1
Subject: Re: RockPro64 PCI
Content-Language: en-US
To: Daniel Engberg 
Cc: freebsd-arm@freebsd.org
References: 
 
 
From: Steve Wills 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Wed, 16 Feb 2022 17:47:30 +0000 (UTC)
X-Spam-Status: No, score=0.0 required=4.5 tests=KHOP_HELO_FCRDNS,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net
X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net
X-Virus-Status: Clean
X-Rspamd-Queue-Id: 4JzQQX1Tw2z4gpp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2607:fc50:0:4400:216:3eff:fe69:33b3 is neither permitted nor denied by domain of swills@FreeBSD.org) smtp.mailfrom=swills@FreeBSD.org
X-Spamd-Result: default: False [-2.78 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[swills];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 NEURAL_HAM_MEDIUM(-0.68)[-0.684];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:2607:fc50::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1492
Lines: 36

Hi,

On 2/16/22 12:36, Daniel Engberg wrote:
> Going by the information you provided it seems to be this card?
> https://www.intel.com/content/www/us/en/products/details/ethernet/gigabit-network-adapters/gigabit-ct-desktop-adapters.html 
> 
> That's a rather old controller (PCIe 1.1) which should be backwards 
> compatible however given the pricing of the SoC I wouldn't bet on it 
> being fully PCIe tested/compliant but that's just a speculation on my 
> behalf.
> Unfortunately I don't have that old Intel NICs to test on my end either 
> to verify.
> 
> https://forums.servethehome.com/index.php?threads/list-of-nics-and-their-equivalent-oem-parts.20974/ 
> first page might be helpful in finding older I340-based cards at least.
> 
> Unfortunately I didn't find any listings of OEM models for i350-based 
> cards although these are still (in general it seems) available as new so 
> they may be scarce pulled/used.
> 
> I did also find these cheap (if you live in US) which seems to be based 
> on the I340 chipset (not tested by me) which may also work:
> https://www.ebay.com/itm/122501625474?epid=27017868551&hash=item1c85aa7682%3Ag%3AXXwAAOSwYvFZHK9e&LH_BIN=1 
> 
> https://forum.netgate.com/topic/135149/riverbed-4-port-nic-how-to-convert-it-into-a-regular-nic 

I ended up buying one of these:

https://www.ebay.com/itm/302281308542

I'll let you know if it doesn't work when it arrives. In the mean time, 
I may try some other random cards I have laying around.

Cheers,
Steve


From nobody Wed Feb 16 23:18:26 2022
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 343BC19BC7E1;
	Wed, 16 Feb 2022 23:18:28 +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 4JzYmM20r4z4SFh;
	Wed, 16 Feb 2022 23:18:27 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 21GNIRcA055289
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 16 Feb 2022 15:18:27 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 21GNIQ4K055288;
	Wed, 16 Feb 2022 15:18:26 -0800 (PST)
	(envelope-from fbsd)
Date: Wed, 16 Feb 2022 15:18:26 -0800
From: bob prohaska 
To: freebsd-net@freebsd.org
Cc: Free BSD , bob prohaska 
Subject: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound ping
 is running on -current
Message-ID: <20220216231826.GA54961@www.zefox.net>
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@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: 4JzYmM20r4z4SFh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2049
Lines: 56

[changed subject to more clearly reflect the symptoms]

On Mon, Feb 14, 2022 at 09:59:23PM -0800, Mark Millard wrote:
> >>>> Since I have a context working based on the kernel in:
> >>>> 
> >>>> https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a028c372d4ac4f72b503/arm64/aarch64/kernel.txz
> >>>> 
> >>>> I recommend that you try that exact same kernel in your
> >>>> stable/13 context. I recommend renaming the existing
> >>>> /boot/kernel before expanding the kernel.txz into / and
> >>>> so causing a new /boot/kernel/ to be filled in.
> 

It looks like the kernel isn't an obvious culprit: Versions
from late October to a few days ago all behave the same way.

Even when booted single-user, with the ue0 device brought up
by hand, only about 1% of incoming pings are answered. That
figure rises to a little over 50% when there's an outgoing ping
process (both running a 1/seccond). Destination of the ping
does not seem to matter, an unused IP seems to work fine. 

AIUI, nothing of userland apart from a shell and the ping
process will be running under those circumstances. Is this
correct? 

Might the trouble be inherited from the boot files? I've left
them alone since the machine does boot and updating them 
isn't automated. Right now the machine boots from microSD
and then runs bootcmd_usb0.

One oddity noticed during the kernel-swapping experiments
is that at the loader prompt some kernel names don't seem
to be recognized. If I type kernel or kernel.old it's
loaded immediately. If I type kernel.no-bpf which is one
I built, booted using the name kernel and then saved with
the name kernel.no-bpf it can't be found, even though it's
visible via ls at the OK prompt. Might - be a prohibited
or priviledged character to the loader? Names like
kernel.20220214 are likewise not recognized, even though
they're visible using ls.

For lack of immediately better ideas I've started stress2
running in single-user mode to see if anything of interest
results.

Thanks for reading, and any ideas!

bob prohaska
 

 



 

From nobody Thu Feb 17 08:02:15 2022
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 9E80919D1441
	for ; Thu, 17 Feb 2022 08:02:22 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4JznNs6cgmz3kL8
	for ; Thu, 17 Feb 2022 08:02:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645084940; bh=QABWEFzT5bb1gvRbqeu99lqsq0DVDOTkaFJAEAzVMso=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Sonpql7WEcKDRxdtTZ4CR8kWZeVI38oua+artWMWh0FBFN7pjW1fSqqC+YYO5bFL6L7gj9Ml7wIB+Eg9iScxaHlfWujqzL1WHNQspbV7ZO5dtvykxEbfSWbAu8eVL8dhfmFav9nepYj2vqujhUZJqRm2QP/wVVbQk47OS112lqOzGA/COtFrz7ZXvYFWTL1LH/Fq3B0zcXopr13dYI77dRJrpiWKtbSilkCuO/r8fw6oA3+qMoXL/GzgvfRUoMumqHtQkSKL5NWUOmTw2qvwp/5byjIXMegNu1W7xa/jW1sfwAjdkAI1IQb9vvYEBMouP55eqScaq+RPPZFYtJvBEw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645084940; bh=f0h1Taue8r3sCO7icHwsQ97nJxiawQFbDJG59zCuIhv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UfErEOC85Iy5Yq9VCZE1M7b/SvMyi5FNPtK8PGke1ri0Z917EPB7XbY4zZtCP4KVLNVTwOdNiaNi973JwRzWnICqzg4Fs/3LdcFRT7j+xE8S0sIP8WJLAfqE1ABSPWO/If2G9S6Geu11s3Nqt/M9CDf5mHoHkx+9XSgdd20RJnaoLABWiN24sdYBwIQ35QnZTBAlgs6NFqYaXdsy+1LFtV2IBXLFrmY07r4NcFwGKZYIuvoEF/+4V8AbLB8Jw0dfscpf+5oPAwT2Q6vjp89e2O7YngSkI1yPMeKTZrdmv/y3VPUsk+JMEJjbzz5hHStkKnrqQgMXCMovO6mepG3Wbg==
X-YMail-OSG: in7oPfsVM1ky0hgydXFU4AyCoj2_PSFl9VsmP1cY7tKslmT.s3KjKrpSkVfXS4d
 Xrnn3meQRMQ8V5aF8GpFl3I0nYHTmpBQtVUCFN18HF8HD_3huX9lkzZt4jaYh.w1Ht1BhYzVva1L
 9Oakf8_jR_qXzL3Jlk3Q1x0OE7jT6tb.VBrQJs4yQM8FHLbjGq48xHoDw8Tp4DS6g_nH.fYUMgg8
 zmJk75YVcEsVIc6wBibKCbcmYBvWhd7gt3YMH2B_o9ELTzaw3zgWDrbw6TLY5NCeuFmbq5aT.tmg
 Xk2JHvMJUyL_wXj85_UMb0TQPW8VqWEJ6t939ZKqVVSO.u03mIkqQuZG.JLpN8go_FxgOirmOKd.
 ydjVeWrZmDedajAg7KrJ6QnFEN3HgnLmhdXvPGq_l1kHfjtFG1aIkxE9aMTH5wvqxu_rPcDO.g__
 Or4JBkrUplTB_c5u4rn0Eg92ys4DuWQd1WsCBueaAIeshdgOWIM3m2AWK5VZ8xxjobHMRNpS6Hjd
 df10R9kyI1STAPdNNrpZQesSMKAhtvInlscDYgA8cGw4mRStjNnxM.IN2O1Xt39aO2NB2_GSEJKO
 9HZ7DWK3LYg0ScLRh4O27jYzkPpJUdPCV3yrtQ0gHGeqPchmJXZyO_pe1HWE.IUq68cvPxvQgzwW
 RJKuPlVIUZFRaIMQbDCNQIeZSTmC.nGkL6z7V0PgU.H0CNuPZd7YzoUqp.bVQvtZAVHSA9m40Tn5
 9tZ47ftQiUlF65r3BCjFh2ZsX2yfOw.nbMdBrdpk02Mrs5pjoPjo39Kbb0awuWwCmUcW4_7A5xRU
 AHRJ8kRVl2pjiGK7Kz9q.AYZxRjd7P3ybmEKOrvDpxH..35TBZIQjXiwG9LNhUfRcFJRphfDNyQg
 NdQV4aZxrNe4V20MGHp3jzZwtKedHxgqY9vBeRbEqnUlEqCyKR8Zk_NyO3.rSOnlx1FSWJMbYNnV
 UF3hySvwedpbJTlpBCYTt5RiVBcq1ETIksO9gTEv94yBKMsGOeffq5f1tXd6p4IMlUzFWfhMDzSt
 ebNizqvCqZPcGGxSa4Q4J4YZi2amh0F0WNQYvPBTGPHdm0L739lK09WzsWcAyiYW1T6XtAu4.y1E
 W3CYVsWypzJoQxQiCS7UX1n10R42PV2aMpWZVnQyh.EwCdEC9RgO0YuUAm334YFQuweKegPeP85W
 UTplCq083.rniI7Y807TiBDoS.rafPJpsDaTrpRxDFIFlRuIME_8ZiwteOdA0SjZciEabszJUany
 D1f5smd.JHxP4xdLwwVMiBRW4WOR5.QAczUnwdQId2fb8LIr6gVkFQ0OXSveWzoeidnOGEIVNPOZ
 cLyV.bgNW8pqx6xGLwZRsRSlrOD7FCn_j.ewGKDTms9uXIq9_BSJm6TbtHcjyY9mbQUnebTasG3m
 24PYHbCmfyrCq1seCX1PqAVFVHYGzv6x8EF_ruwN0ZgNNq._R0NEzN7FPnnv8TPseolF6QjkkRJV
 5OHp8_liLzLENYKFrNPY1YBpfxGodRMgyK7kZ1UXifyzJdZi2C2kPoorldb7NXjOnNMXSKK5kpK2
 ae5TwTTIBIBFu97XpGPySlzOvyVUC7Qfvyc4.pcKNL5Ye0hpNq3lCjJcTV.DFklINS.GXyspIsFW
 EVSVXjKvCUmzlHxtvjIm2ExNHg82qhzjTa1nOnrHIiQtx2doa9aUhthsb2ibBcvS7P.qXeaB7bYf
 fDAad67pHHhwDaY35l93E2wp5g77mZHU9Jxvkz0eQJQ27QV7khkv26r2H.g8ZpyhqNDRDqeHex9e
 UHGvEvGOXreEg.WaHvqfv0u2A3_kMbzxv4AFOsOtgcJ.EW3ZeNm4d57Vw0uYf6y_7uqWSloDSmeA
 ZXLGJGxWJmGVG4OyrbtZYiOzgi7Q1Wq1_F5Tz0eVvswULeKISA0yDlgKzp65u0zDlBMNG2j3ViP7
 dwhWT4GC11haSLJMP6z.d_OFfLBXS2cUFC7bUlE15MKvMH0EhgJUkWx6oVKakOW5MwLjSalmjICg
 Dnvn37ClPvMhYXFubihFC_djxfnUAEDSVM7URyZ58yJ60QWGG3RQ7H6s.0W1w7sDyVTainIU9kYb
 xtqBDmZoiwTmWNBoBSLvtjsYollAW.rEYShGKVyrjXrWb_06h1PhrWGVrfInNa6gM8HYW4UJTH.0
 VhDqGL3jeK5B.6rw3mQR_VwIoLBLgN.FicrjdqybNcHJ5k5_7Dp9PDM74jm74pAXu_dpish9L7nm
 RbSiD8DLMFENCS1JgLypaTxr66EV8DSKaXh75Xh67F9VTtz5miOAsdteaGaN69xaPjI3TxcpE.Px
 oLuiIoS9BJ44grdV9bOHVXG.buPOsfqEMypdXbWk60vHJ7Ki96IGOy.KeqOVzIO7kABZJv6fEhd.
 kplWtnpbiwBlRiRCAo9QVJcOLhCa4vxju8I7xEVAuXulzqB69jzY48htLGqfTMA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 17 Feb 2022 08:02:20 +0000
Received: by kubenode500.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 329a4f42450bc5cce24e70f83c907a66;
          Thu, 17 Feb 2022 08:02:17 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: <20220216231826.GA54961@www.zefox.net>
Date: Thu, 17 Feb 2022 00:02:15 -0800
Cc: freebsd-net@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4JznNs6cgmz3kL8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Sonpql7W;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2570
Lines: 64

On 2022-Feb-16, at 15:18, bob prohaska  wrote:

> [changed subject to more clearly reflect the symptoms]
>=20
> On Mon, Feb 14, 2022 at 09:59:23PM -0800, Mark Millard wrote:
>>>>>> Since I have a context working based on the kernel in:
>>>>>>=20
>>>>>> =
https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02=
8c372d4ac4f72b503/arm64/aarch64/kernel.txz
>>>>>>=20
>>>>>> I recommend that you try that exact same kernel in your
>>>>>> stable/13 context. I recommend renaming the existing
>>>>>> /boot/kernel before expanding the kernel.txz into / and
>>>>>> so causing a new /boot/kernel/ to be filled in.
>>=20
>=20
> It looks like the kernel isn't an obvious culprit: Versions
> from late October to a few days ago all behave the same way.
>=20
> Even when booted single-user, with the ue0 device brought up
> by hand, only about 1% of incoming pings are answered. That
> figure rises to a little over 50% when there's an outgoing ping
> process (both running a 1/seccond). Destination of the ping
> does not seem to matter, an unused IP seems to work fine.=20
>=20
> AIUI, nothing of userland apart from a shell and the ping
> process will be running under those circumstances. Is this
> correct?=20
>=20
> Might the trouble be inherited from the boot files? I've left
> them alone since the machine does boot and updating them=20
> isn't automated. Right now the machine boots from microSD
> and then runs bootcmd_usb0.
>=20
> One oddity noticed during the kernel-swapping experiments
> is that at the loader prompt some kernel names don't seem
> to be recognized. If I type kernel or kernel.old it's
> loaded immediately. If I type kernel.no-bpf which is one
> I built, booted using the name kernel and then saved with
> the name kernel.no-bpf it can't be found, even though it's
> visible via ls at the OK prompt. Might - be a prohibited
> or priviledged character to the loader? Names like
> kernel.20220214 are likewise not recognized, even though
> they're visible using ls.
>=20
> For lack of immediately better ideas I've started stress2
> running in single-user mode to see if anything of interest
> results.

I expect that this was your first message on the
issue to freebsd-net. So I'll reference your previous
notes on the behaviors that you are seeing that you
sent to freebsd-arm at the time:

https://lists.freebsd.org/archives/freebsd-arm/2022-February/000989.html
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001002.html

This might avoid some Q&A.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Feb 17 15:32:25 2022
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 047C519C6EAA
	for ; Thu, 17 Feb 2022 15:32:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c])
	(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 4JzzNP25vFz3rc1
	for ; Thu, 17 Feb 2022 15:32:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52c.google.com with SMTP id h18so10320903edb.7
        for ; Thu, 17 Feb 2022 07:32:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=jrDPC4mpSEGQzRLEpqY75hB1VXhxCoAEHi409Cbj04s=;
        b=Usumg3LKeHyQh7JCDo3j063mO2ayMRQLOFPJbVb6RinXDKsPliyMzRhqdXP+Mc9prN
         MyEq0bvrlbgSz99RBegj475gr8/80JPwODB+KNmRt9AeXLXlsFXdDJE/EmopsEBjAraO
         LvWoyAGywTqVlB3SH1QoyQ4DdpRkv6SJFV+Qs929QUrjH9mkV5YoascIBFyLRD6PvL+1
         6HexW+D0CwrZH+Zk7wr6i2LbOEsHPaudM0yOVE1RGAaQj3dA4o+gfqa3+vi4HHCunYlN
         2bfXCWrt5kCZhUkcegtRgKJ9RqChgGcZlCNDgadfxasH5Gv5Q2tJ8czGzUm910dV7mGi
         PDng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=jrDPC4mpSEGQzRLEpqY75hB1VXhxCoAEHi409Cbj04s=;
        b=o1coFx0d2wUgNr4Y3Tt82PT9SixV5I/0m60AN9M8GE5oT2ykVNBtFU3+u6vhQd7mB+
         LeM/bE6QCo8Rv8mzSIPyzaiWDjb+1mQGfx3oLCKxDh2KN59j/zB7oHLgRIv2DjmOAQ0s
         azElueTN7z3xB1Z/88fk+Unv03hQsFBH/j8ha1vaU0PbPK67FoZ1simZMTyecPUHYQww
         YvcvrGF7rhhT4jaT1RBV6DoVBep1MaQvSX+L85Deo+Rt3ECZyShv6RIPBWTjjmdA6h59
         Oy6GBr/wsWrSH/rkfxfawx1Bz4nzT7UVKIImhm4s+11ZbIsm2/qRfbTdb5QM7y9vkdD1
         UlYw==
X-Gm-Message-State: AOAM531WmQpOJPr9S8de2omEt1LF77gB4LGgJS98jJS7qp/FSqIfzJ/6
	lIY4taEaDVFlw0hRi0jnmp+45SMWPpEq0zQAV3SvYVFF+JnfrQ==
X-Google-Smtp-Source: ABdhPJxwFe8UlU82oDAZ+/Q+MClKviE/iRcRJbNJwz+ypHgG0SwfXBTlEty4+UWfc5b+h4ZYNr2o1uUNk/otzyJHqXE=
X-Received: by 2002:a50:8e44:0:b0:40f:d71f:bdf5 with SMTP id
 4-20020a508e44000000b0040fd71fbdf5mr3217230edx.166.1645111956029; Thu, 17 Feb
 2022 07:32:36 -0800 (PST)
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
From: Archimedes Gaviola 
Date: Thu, 17 Feb 2022 23:32:25 +0800
Message-ID: 
Subject: DS3231 RTC module not detected
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000c1465e05d8387997"
X-Rspamd-Queue-Id: 4JzzNP25vFz3rc1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Usumg3LK;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3790
Lines: 81

--000000000000c1465e05d8387997
Content-Type: text/plain; charset="UTF-8"

Hi,

I have a DS3231 real-time clock module (
http://wiki.sunfounder.cc/index.php?title=DS3231_Real_Time_Clock_Module_for_Raspberry_Pi)
but cannot be detected with FreeBSD 13.0-RELEASE and 14.0-CURRENT. My
config.txt have this following lines;

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231

and then I fetched a copy of the i2c-rtc.dtbo file here
https://github.com/raspberrypi/firmware/blob/master/boot/overlays/i2c-rtc.dtbo
and put it in the /boot/msdos/overlays directory.

root@generic:/boot/msdos/overlays # ls -lah
total 208
drwxr-xr-x  1 root  wheel   4.0K Feb 10 10:18 .
drwxr-xr-x  1 root  wheel    16K Jan  1  1980 ..
-rwxr-xr-x  1 root  wheel   1.0K Mar  3  2021 disable-bt.dtbo
-rwxr-xr-x  1 root  wheel   172K Feb 11 06:09 i2c-rtc.dtbo
-rwxr-xr-x  1 root  wheel   1.2K Mar  3  2021 mmc.dtbo
-rwxr-xr-x  1 root  wheel   985B Mar  3  2021 pwm.dtbo

I rebooted my RPi 4B and then dmesg still prompts this message.

Warning: no time-of-day clock registered, system time will not be set
accurately

I have tried this configuration in OpenBSD 6.9 and it is working. Is there
any method with FreeBSD?

I also tried loading the ds3231.ko and enabled in the loader.conf and then
rebooted my system again but still not able to detect the module.

root@generic:~ # kldload ds3231
root@generic:~ # kldstat | grep ds3231
 9    1 0xffff0000d1ab8000    23000 ds3231.ko

Thanks,
Archimedes

--000000000000c1465e05d8387997
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I have a DS3231 real-tim=
e clock module (http://wiki.sunfounder.cc/index=
.php?title=3DDS3231_Real_Time_Clock_Module_for_Raspberry_Pi) but cannot=
 be detected with FreeBSD 13.0-RELEASE and 14.0-CURRENT. My config.txt have=
 this following lines;


dtparam=3Di2c_arm=3Don

dtoverlay=3Di2c-rtc,ds3231

and then I fetched a co=
py of the i2c-rtc.dtbo file here https://github.com/raspber=
rypi/firmware/blob/master/boot/overlays/i2c-rtc.dtbo and put it in the =
/boot/msdos/overlays directory. 

root@generic:=
/boot/msdos/overlays # ls -lah
total 208
drwxr-xr-x =C2=A01 root =C2=
=A0wheel =C2=A0 4.0K Feb 10 10:18 .
drwxr-xr-x =C2=A01 root =C2=A0wheel =
=C2=A0 =C2=A016K Jan =C2=A01 =C2=A01980 ..
-rwxr-xr-x =C2=A01 root =C2=
=A0wheel =C2=A0 1.0K Mar =C2=A03 =C2=A02021 disable-bt.dtbo
-rwxr-xr-x =
=C2=A01 root =C2=A0wheel =C2=A0 172K Feb 11 06:09 i2c-rtc.dtbo
-rwxr-xr-=
x =C2=A01 root =C2=A0wheel =C2=A0 1.2K Mar =C2=A03 =C2=A02021 mmc.dtbo
-=
rwxr-xr-x =C2=A01 root =C2=A0wheel =C2=A0 985B Mar =C2=A03 =C2=A02021 pwm.d=
tbo

I rebooted my RPi 4B and then dmesg still prom=
pts this message.

Warning: no time-of-day cloc=
k registered, system time will not be set accurately

I have tried this configuration in OpenBSD 6.9 and it is work=
ing. Is there any method with FreeBSD?


I also tried loading the ds3231.ko and enabled in the loader.conf and then =
rebooted my system again but still not able to detect the module.

root@generic:~ # kldload ds3231
root@generic:~ # kldstat=
 | grep ds3231
=C2=A09 =C2=A0 =C2=A01 0xffff0000d1ab8000 =C2=A0 =C2=A023=
000 ds3231.ko




Thanks,
Archimedes



--000000000000c1465e05d8387997--

From nobody Fri Feb 18 14:22:30 2022
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 A862119D18A1
	for ; Fri, 18 Feb 2022 14:22:51 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536])
	(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 4K0YnR0BQMz4tCJ
	for ; Fri, 18 Feb 2022 14:22:51 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x536.google.com with SMTP id w3so15770019edu.8
        for ; Fri, 18 Feb 2022 06:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=/EI90TByrVJJl7qG+KGdJY/sLVELSA5X+uHVT999PUc=;
        b=gyUwmFLgiyWiibkAvXjWurcuiPfAk8oysEoVWeZoWIPr4BlhsDn9vJpiD+eGJmgnFi
         F8qLat3pCDfsINTBmwpEcjhlAuBkSVIu6bdWX0iQBKqYlTClk6ieANIF8qWGPyCjJGJU
         6NM/93ueL13it/Oj7f9OQ5lYasGsPB+YtFpZ5L1/erXoS0zYFs4jvOyjHrMkuInuhTs7
         42JIY38Blm9dskIoxiKYWCDXMq+ka+VAGNqVmRMGuejn4J2l1hClRbOwKf8vZEn0TnF3
         VHTlZuwd0D9q3R/qlW4N2dRuAGRa2ly4hFiiIdTRrZKx2RucVXwYkqb5JbbqWJHrwUZJ
         notw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=/EI90TByrVJJl7qG+KGdJY/sLVELSA5X+uHVT999PUc=;
        b=pLtxU6EkR3i7RHnQbwBzpjureSGFQwfGeKyThfcnb3yUtevpJqFAvvvnk48SntcuJ4
         a4cfiiXMQsANe1CuK5iIPeb8LFrcyLBswTVFR04m+3gEzTVp6z/VFpqFMq0ki1m0ySGR
         K2yBaLInNMvO+rgoivtZhDx3hq5kd3Uvdr/AX/YcV/oIMILeD3MtdN/lIfw2ogMY/e/3
         iG1h68tbLLd4JAunswaCDZaVOOBsiAmryWAM3Dgfajcdgu9SzLt4tDhPdkNvuPiYkN15
         luYcaBbB5SzCcKu2En7Htb6Wu2IIhKdgUUEv+UpGrIfmSLmKXR23EQgTYjFgkkk1NtmM
         FjDw==
X-Gm-Message-State: AOAM533m7gcXzMIvWg2y/UDMSqFy88oZ726lG0jfkL5CgjBkMEaQKRsg
	w+68ajnyCZEisLb4QkrsBv4ixR+x8aE8gLxRp3Oox7MWMaLYZA==
X-Google-Smtp-Source: ABdhPJwvyfRmVealhOA8+wE6+bfo/84ZSVMKlUNOnIal1j2s0gn71ZY63hHDQCRUVGgbLYz0i3DE/cJpodZ1YOgIF5Y=
X-Received: by 2002:a50:c056:0:b0:40f:9c6d:7701 with SMTP id
 u22-20020a50c056000000b0040f9c6d7701mr8285280edd.110.1645194169982; Fri, 18
 Feb 2022 06:22:49 -0800 (PST)
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: Archimedes Gaviola 
Date: Fri, 18 Feb 2022 22:22:30 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000016a43205d84b9e1e"
X-Rspamd-Queue-Id: 4K0YnR0BQMz4tCJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=gyUwmFLg;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.68:email,0.0.0.0:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.68:email,0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 14588
Lines: 322

--00000000000016a43205d84b9e1e
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 18, 2022 at 7:08 AM Daniel O'Connor  wrote:

>
>
> > On 18 Feb 2022, at 02:02, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> > I have a DS3231 real-time clock module (
> http://wiki.sunfounder.cc/index.php?title=DS3231_Real_Time_Clock_Module_for_Raspberry_Pi)
> but cannot be detected with FreeBSD 13.0-RELEASE and 14.0-CURRENT. My
> config.txt have this following lines;
> >
> > dtparam=i2c_arm=on
> > dtoverlay=i2c-rtc,ds3231
> >
> > and then I fetched a copy of the i2c-rtc.dtbo file here
> https://github.com/raspberrypi/firmware/blob/master/boot/overlays/i2c-rtc.dtbo
> and put it in the /boot/msdos/overlays directory.
>
> I have a DS1307 board on an RPi4 and I made the following modifications:
>
> I have /boot/msdos/overlays/ds1307.dtso with the following contents:
> // Definition for RPi3 I2C based Real Time Clock
> /dts-v1/;
> /plugin/;
>
> / {
>         compatible = "brcm,bcm2835";
>
>         fragment@0 {
>                 target = <&i2c1>;
>                 __overlay__ {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                         status = "okay";
>                                 ds1307: ds1307@68 {
>                                         compatible = "maxim,ds1307";
>                                         reg = <0x68>;
>                                         status = "okay";
>                         };
>                 };
>         };
>         __overrides__ {
>                 ds1307 = <&ds1307>,"status";
>         };
> };
>
> Then compiled it with..
> sudo dtc -O dtb -o /boot/msdos/overlays/ds1307.dtbo -b 0 -@
> /boot/msdos/overlays/ds1307.dtso
>
> In /boot/msdos/config.txt I have..
>
> [all]
> ...
> # DS1307 RTC
> dtparam=i2c_arm=on
> dtoverlay=ds1307
> ...
> [pi4]
> # For I2C as per
> # https://lists.freebsd.org/pipermail/freebsd-arm/2021-May/023713.html
> gpio=2,3=a0
>
> If it doesn't work post your dmesg output, but I suspect changing the
> config.txt as just above will fix it.
>

Hi Daniel,

Thanks for the info! I followed similar with your DS1307 RTC by creating a
ds3231.dtso file and then compiling it with dtc to generate a ds3231.dtbo.
The result is it is detected as MAX77620 RTC on 0xd0 address but when I run
an i2c scan, the address detected is 68. Does this should match?

With this setup I could update the date and time now by initiating an
ntpdate to match our time plus invoking tzsetup command for my timezone
which is doing well without any issue. Now, the moment I shutdown the
system and plug back the power cable (with disconnected Ethernet cable just
to make sure NTP servers are not called for updates upon restart) the time
remains as it was before shutting down and then upon bootup system clock
continues. I am expecting that it should be real time even if the RPi4
system is shutdown or detached from power due to the battery that will
sustain the continuity of the clock. I'm sure that I'm having good DS3231
modules as I also tested my existing and another new spare and it is tested
with OpenBSD too. Below are the system info. Is there anything I've missed?
FreeBSD 13.0-RELEASE have the same outcome and behavior.

freebsd@generic:~ % uname -a
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n253065-8dc42f98047: Thu Feb 10 09:27:01 UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
 arm64

freebsd@generic:~ % dmesg | grep iic
iichb0:  mem 0x7e804000-0x7e804fff irq 26 on
simplebus0
iicbus0:  on iichb0
iic0:  on iicbus0
rtc0:  at addr 0xd0 on iicbus0
rtc0: registered as a time-of-day clock, resolution 1.000000s

root@generic:~ # i2c -s
68

root@generic:~ # sysctl -a | grep rtc
rtc0:  at addr 0xd0 on iicbus0
rtc0: registered as a time-of-day clock, resolution 1.000000s
"max77620_rtc","bcm_bsc"
"rtc list","max77620_rtc"
machdep.disable_rtc_set: 0
machdep.rtc_save_period: 1800
dev.rtc.0.%parent: iicbus0
dev.rtc.0.%pnpinfo: name=ds3231@68 compat=maxim,ds3231
dev.rtc.0.%location: addr=0xd0
dev.rtc.0.%driver: rtc
dev.rtc.0.%desc: MAX77620 RTC
dev.rtc.%parent:

freebsd@generic:~ % cat /boot/msdos/overlays/ds3231.dtso
// Definition for RPi3 I2C based Real Time Clock
/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2835";

        fragment@0 {
                target = <&i2c1>;
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        status = "okay";
                                ds3231: ds3231@68 {
                                        compatible = "maxim,ds3231";
                                        reg = <0x68>;
                                        status = "okay";
                        };
                };
        };
        __overrides__ {
                ds3231 = <&ds3231>,"status";
        };
};

and my config.txt have

dtparam=i2c_arm=on
dtoverlay=ds3231
gpio=2,3=a0

Thanks,
Archimedes

--00000000000016a43205d84b9e1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Feb 18, 2022 at 7:08 AM Danie=
l O'Connor <darius@dons.net.au=
> wrote:
=




> On 18 Feb 2022, at 02:02, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> I have a DS3231 real-time clock module (http://wiki.sunfounder.cc/index.php?titl=
e=3DDS3231_Real_Time_Clock_Module_for_Raspberry_Pi) but cannot be detec=
ted with FreeBSD 13.0-RELEASE and 14.0-CURRENT. My config.txt have this fol=
lowing lines;

> 

> dtparam=3Di2c_arm=3Don

> dtoverlay=3Di2c-rtc,ds3231

> 

> and then I fetched a copy of the i2c-rtc.dtbo file here https://github.com/raspberrypi/firmw=
are/blob/master/boot/overlays/i2c-rtc.dtbo and put it in the /boot/msdo=
s/overlays directory. 



I have a DS1307 board on an RPi4 and I made the following modifications:


I have /boot/msdos/overlays/ds1307.dtso with the following contents:

// Definition for RPi3 I2C based Real Time Clock

/dts-v1/;

/plugin/;



/ {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D "brcm,bcm2835";



=C2=A0 =C2=A0 =C2=A0 =C2=A0 fragment@0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 target =3D <&=
;i2c1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __overlay__ {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 #address-cells =3D <1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 #size-cells =3D <0>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 status =3D "okay";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ds1307: ds1307@68 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compatib=
le =3D "maxim,ds1307";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reg =3D =
<0x68>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status =
=3D "okay";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 };

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };

=C2=A0 =C2=A0 =C2=A0 =C2=A0 };

=C2=A0 =C2=A0 =C2=A0 =C2=A0 __overrides__ {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ds1307 =3D <&=
;ds1307>,"status";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 };

};



Then compiled it with..

sudo dtc -O dtb -o /boot/msdos/overlays/ds1307.dtbo -b 0 -@ /boot/msdos/ove=
rlays/ds1307.dtso



In /boot/msdos/config.txt I have..



[all]

...

# DS1307 RTC

dtparam=3Di2c_arm=3Don

dtoverlay=3Dds1307

...

[pi4]

# For I2C as per

# https://lists.freebsd.org/pipe=
rmail/freebsd-arm/2021-May/023713.html

gpio=3D2,3=3Da0



If it doesn't work post your dmesg output, but I suspect changing the c=
onfig.txt as just above will fix it.

<=
div class=3D"gmail_quote">Hi Daniel,

Thanks for the info! I followed similar with=
 your DS1307 RTC by creating a ds3231.dtso file and then compiling it with =
dtc to generate a ds3231.dtbo. The result is it is detected as MAX77620 RTC=
 on 0xd0 address but when I run an i2c scan, the address detected is 68. Do=
es this should match?

With this setup I could update the date and time now by=
 initiating an ntpdate to match our time plus invoking tzsetup command for =
my timezone which is doing well without any issue. Now, the moment I shutdo=
wn the system and plug back the power cable (with disconnected Ethernet cab=
le just to make sure NTP servers are not called for updates upon restart) t=
he time remains as it was before shutting down and then upon bootup system =
clock continues. I am expecting that it should be real time even if the RPi=
4 system is shutdown or detached from power due to the battery that will su=
stain the continuity of the clock. I'm sure that I'm having good DS=
3231 modules as I also tested my existing and another new spare and it is t=
ested with OpenBSD too. Below are the system info. Is there anything I'=
ve missed? FreeBSD 13.0-RELEASE have the same outcome and behavior.

freebsd@generic:~ % uname -a
FreeBSD generic 14.=
0-CURRENT FreeBSD 14.0-CURRENT #0 main-n253065-8dc42f98047: Thu Feb 10 09:2=
7:01 UTC 2022 =C2=A0 =C2=A0 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/a=
rm64.aarch64/sys/GENERIC =C2=A0arm64

freebsd@generic:~ % dmesg | grep iic
iich=
b0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 26 on=
 simplebus0
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C gene=
ric I/O> on iicbus0
rtc0: <MAX77620 RTC> at addr 0xd0 on iicbus=
0

rtc0: registered as a time-of-day clock, resolution 1.000000s




root@generic:~ # i2c -s
68

root@generic:~ # sysctl -a | grep rtc
rtc0: <=
MAX77620 RTC> at addr 0xd0 on iicbus0
rtc0: registered as a time-of-d=
ay clock, resolution 1.000000s
"max77620_rtc","bcm_bsc&qu=
ot;
"rtc list","max77620_rtc"
machdep.disable_rtc=
_set: 0
machdep.rtc_save_period: 1800
dev.rtc.0.%parent: iicbus0
d=
ev.rtc.0.%pnpinfo: name=3Dds3231@68 compat=3Dmaxim,ds3231
dev.rtc.0.%loc=
ation: addr=3D0xd0
dev.rtc.0.%driver: rtc
dev.rtc.0.%desc: MAX77620 R=
TC
dev.rtc.%parent:

freebsd@generic:~ % cat /=
boot/msdos/overlays/ds3231.dtso
// Definition for RPi3 I2C based Real Ti=
me Clock
/dts-v1/;
/plugin/;

/ {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 compatible =3D "brcm,bcm2835";

=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 fragment@0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 target =3D <&i2c1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 __overlay__ {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 #address-cells =3D <1>;=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 #size-cells =3D <0>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D "okay&=
quot;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ds3231: ds3231@68 {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =
=3D "maxim,ds3231";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 reg =3D <0x68>;
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status =3D "okay";
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 };
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __overrid=
es__ {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ds3231 =
=3D <&ds3231>,"status";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
};
};

and my config.txt have

dtparam=3Di2c_arm=3Don
=
dtoverlay=3Dds3231
gpio=3D2,3=3Da0

Thanks,
<=
div class=3D"gmail_quote">Archimedes

--00000000000016a43205d84b9e1e--

From nobody Fri Feb 18 22:52:01 2022
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 1DB9219C94D9
	for ; Fri, 18 Feb 2022 22:52:43 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K0n5h6FVGz3PwJ
	for ; Fri, 18 Feb 2022 22:52:40 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21IMqJVo071219
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sat, 19 Feb 2022 09:22:23 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1645224746;
	bh=XUAPU3WD0clXHTCfpy5SmRin7GWFYzAqwxhSB5gDYXs=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=kovzbfvLmsSWYESGdBOslqQqvKauHYkNLfInNrnxyTi9Q3c5AxAmLCr0czFaMSJwI
	 4s4Y9NQxdAVX/5nw9gK/iZAr86otgEG62JGVPlNFUmdFnPEnXZheXlkWEXB+jw8eA8
	 FTyuLC9juJuZ5nLAn9FO0Og86RdLilPfoXNQVe0c=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21IMq1G4071212
	for ; Sat, 19 Feb 2022 09:22:01 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:985d:2478:209b:f77a
Received: from smtpclient.apple (2403-5800-5200-4700-985d-2478-209b-f77a.ip6.aussiebb.net [2403:5800:5200:4700:985d:2478:209b:f77a])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21IMq1IZ071207; Sat, 19 Feb 2022 09:22:01 +1030
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 15.0 \(3693.40.0.1.81\))
Subject: Re: DS3231 RTC module not detected
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Sat, 19 Feb 2022 09:22:01 +1030
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
References: 
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-Spam-Score: 0.6 () No, score=0.6 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1
X-Rspamd-Queue-Id: 4K0n5h6FVGz3PwJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=kovzbfvL;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-3.03 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[dons.net.au:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	 NEURAL_HAM_SHORT(-0.53)[-0.531];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2219
Lines: 52



> On 19 Feb 2022, at 00:52, Archimedes Gaviola =
 wrote:
> Thanks for the info! I followed similar with your DS1307 RTC by =
creating a ds3231.dtso file and then compiling it with dtc to generate a =
ds3231.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 =
address but when I run an i2c scan, the address detected is 68. Does =
this should match?

Mine was detected similarly:
iic0:  on iicbus0
rtc0:  at addr 0xd0 on iicbus0
usbus0: 5.0Gbps Super Speed USB v3.0
rtc0: registered as a time-of-day clock, resolution 1.000000s

I am not sure why it shows up like that but it does seem to work.

> With this setup I could update the date and time now by initiating an =
ntpdate to match our time plus invoking tzsetup command for my timezone =
which is doing well without any issue. Now, the moment I shutdown the =
system and plug back the power cable (with disconnected Ethernet cable =
just to make sure NTP servers are not called for updates upon restart) =
the time remains as it was before shutting down and then upon bootup =
system clock continues. I am expecting that it should be real time even =
if the RPi4 system is shutdown or detached from power due to the battery =
that will sustain the continuity of the clock. I'm sure that I'm having =
good DS3231 modules as I also tested my existing and another new spare =
and it is tested with OpenBSD too. Below are the system info. Is there =
anything I've missed? FreeBSD 13.0-RELEASE have the same outcome and =
behavior.

That is strange, I tested powering mine off and it kept time but I am =
not 100% sure it was advancing correctly - I didn't take a precise note =
of when I powered it off etc..

Unfortunately it's not physically with me so I can't test it right now.

I do note this sysctl:
machdep.rtc_save_period: Save system time to RTC with this period (in =
seconds)

Which suggests to me that the clock could be up to 30 minutes off if the =
power is removed (I believe it gets flushed out on a clean shutdown =
though). Perhaps that is the problem?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


From nobody Sat Feb 19 05:01:41 2022
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 B98AB19DD180
	for ; Sat, 19 Feb 2022 05:02:02 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmse03.mailcluster.com.au (vmse03.mailcluster.com.au [IPv6:2401:fc00:0:14::11])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K0xHr5yHbz4mHF
	for ; Sat, 19 Feb 2022 05:02:00 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmcp43.digitalpacific.com.au ([101.0.119.58])
	by vmse03.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128)
	(Exim 4.92)
	(envelope-from )
	id 1nLHsN-0001l0-UE
	for freebsd-arm@freebsd.org; Sat, 19 Feb 2022 16:01:48 +1100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type:
	In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:
	Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
	List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=57D4nckx8D01msoE9INv52l5emYnQyfYZov3APD+oYk=; b=e6BVje09QDH2X0hrqISOUI0nM4
	fRIsd1QKVugUmPgBvtDSXWxlW65KNDZ86gjiUY5tu719Se2nOqOg5SrRPtUdmCM0C3v+j3Imvnxhg
	8KtLU3W6PnYnQ+f3qQvCXgNIzN+aQ78go0dZvSWe+5EtT0bJtuOz7JeXc1qmuAxIFZ/AmT9BT98iS
	uWMTjGwB3stoexooCCQAnqhMGscNgczrbhEIayh1chl35wjE54ZJEg6CnGKnpkxtMWHG5biDDf97q
	rf67K5mmLr8ueM6IXv5R/g80mVQKkTveILG5D5u/jDa0/xaKdDMRIgzy0XE0y+8ZBv7U70faxi5ND
	rDuy/irA==;
Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:45488 helo=[10.0.1.106])
	by vmcp43.digitalpacific.com.au with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from )
	id 1nLHsM-00BFxd-EY
	for freebsd-arm@freebsd.org; Sat, 19 Feb 2022 16:01:42 +1100
Message-ID: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
Date: Sat, 19 Feb 2022 16:01:41 +1100
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 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.0
Subject: Re: DS3231 RTC module not detected
To: freebsd-arm@freebsd.org
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
From: Brian Scott 
In-Reply-To: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Authenticated-User: bscott@bunyatech.com.au
X-Authenticator: dovecot_plain
X-Originating-IP: 101.0.119.58
X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au
X-SpamExperts-Username: 101.0.119.58
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.04)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/aj9iD2d1pqP5BYrP21CA3PUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH
 zJ6mVE7ewsipSVIfs4bk/BERpQBBfwDmwK4QZ5tjABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY
 pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyjwYONoRaT/P0bWwmOx4gR8p8Gnm
 YnDDwZLHsvD3pj+LvuKTBmuOVTCmQ/b22sw+yoj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2
 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4
 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH
 wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U
 ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC64
 m+k59xMAqz9bfz2u3IufXgzJJmjXk7fyp6dRgNba57y0+NUW6SiQze/aT7qNfwLF4DEPUxAkEvKE
 S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2
 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbuUCVbnFmfwLrtFboZlI4VlsjUqWShwiJykPEul
 jbtoq1z1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r
 Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3
 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO
 g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE=
X-Report-Abuse-To: spam@vmse01.mailcluster.com.au
X-Rspamd-Queue-Id: 4K0xHr5yHbz4mHF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bunyatech.com.au header.s=default header.b=e6BVje09;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:0:14::11 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au
X-Spamd-Result: default: False [-3.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[bunyatech.com.au];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[bunyatech.com.au:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[2401:fc00:0:14::11:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3319
Lines: 60

On 19/2/22 9:52 am, Daniel O'Connor wrote:
>
>> On 19 Feb 2022, at 00:52, Archimedes Gaviola  wrote:
>> Thanks for the info! I followed similar with your DS1307 RTC by creating a ds3231.dtso file and then compiling it with dtc to generate a ds3231.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address but when I run an i2c scan, the address detected is 68. Does this should match?
> Mine was detected similarly:
> iic0:  on iicbus0
> rtc0:  at addr 0xd0 on iicbus0
> usbus0: 5.0Gbps Super Speed USB v3.0
> rtc0: registered as a time-of-day clock, resolution 1.000000s
>
> I am not sure why it shows up like that but it does seem to work.
>
>> With this setup I could update the date and time now by initiating an ntpdate to match our time plus invoking tzsetup command for my timezone which is doing well without any issue. Now, the moment I shutdown the system and plug back the power cable (with disconnected Ethernet cable just to make sure NTP servers are not called for updates upon restart) the time remains as it was before shutting down and then upon bootup system clock continues. I am expecting that it should be real time even if the RPi4 system is shutdown or detached from power due to the battery that will sustain the continuity of the clock. I'm sure that I'm having good DS3231 modules as I also tested my existing and another new spare and it is tested with OpenBSD too. Below are the system info. Is there anything I've missed? FreeBSD 13.0-RELEASE have the same outcome and behavior.
> That is strange, I tested powering mine off and it kept time but I am not 100% sure it was advancing correctly - I didn't take a precise note of when I powered it off etc..
>
> Unfortunately it's not physically with me so I can't test it right now.
>
> I do note this sysctl:
> machdep.rtc_save_period: Save system time to RTC with this period (in seconds)
>
> Which suggests to me that the clock could be up to 30 minutes off if the power is removed (I believe it gets flushed out on a clean shutdown though). Perhaps that is the problem?
>
> --
> Daniel O'Connor
> "The nice thing about standards is that there
> are so many of them to choose from."
>   -- Andrew Tanenbaum
>
>
Hi people,

I had the same problem a few months ago.

The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to 
unilaterally claim anything at address 68. It doesn't understand the 
DS3231 and fails to operate properly, but in claiming the device, the 
ds3231 driver doesn't get a chance. This is compounded by the MAX77620 
driver being compiled into the kernel by default so the loadable module 
doesn't get to try until after the wrong driver has claimed it.

The only answer at present is to build a custom kernel without the 
unwanted driver. My kernel config is:

include         GENERIC
ident           GENERIC-PI
nooptions       SOC_NVIDIA_TEGRA210

Ideally, the TEGRA210 code would be fixed or removed from the GENERIC 
kernel but that doesn't seem to have happened despite the adverse effect 
on the many clock devices that live at address 68 and will already be in 
use.

I dislike building a custom kernel because everything else I do strives 
to use precompiled binaries whenever possible.

Cheers,


Brian


From nobody Sat Feb 19 11:59:02 2022
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 F2DB119D5738
	for ; Sat, 19 Feb 2022 11:59:22 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533])
	(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 4K16YQ0bJxz3vJ0
	for ; Sat, 19 Feb 2022 11:59:22 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x533.google.com with SMTP id x5so19896937edd.11
        for ; Sat, 19 Feb 2022 03:59:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=fxxE1cKO/kFyzkZgiuV8hyKAjBsm2d+d79+QAlBJ83A=;
        b=PtfJ4fZ+6Pcm+AroDqjSHpdSNRoCSf0RbBOmbLr+oUDUtpqLaQ93b7WQ00IGIuB6Wl
         i/eoQBMGxFraMgNfUXAhv0vyxj4/woNFDolwQexiZvP26MBLg9q0bo4HSQMOqHY/z2ir
         WS42QGt7qBKWZD77OrEkHNQu18FNSgYAmX9mJQGvdT4v9F3KaTGJnTACGzz8Hf6RtDa4
         RdJP+upVir28heSVxsiJ/ZKuL3oRtpA6IGAYVmyRP+2Tbr6KEUwBOGCwwj/fdvbQ47j5
         52n0B+9E76CERVkuk5B0+uFrgGSz0aebBRJ+K7scGcLjrcFKCNN/Ssv1VfIHBfGqT5yZ
         5uqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=fxxE1cKO/kFyzkZgiuV8hyKAjBsm2d+d79+QAlBJ83A=;
        b=qaaGw+z7WmNytYNL39oWIb9qhQldhawUvKKFx8QvlqTXmsJpEAJorVFixkWiKZd1wg
         Is0mtfBHR+DMhvnwYDJZ3T3aPpqTESEsL47VnvduN/He56raJUXeAmyjOsc0B8DmVqO5
         uOcX/AW7IND0rNlHpctTVwDBI4Pu/8BPG5XL7wdvl2M97miLP97AHvf+314dQzA5C6vX
         ZWcRkHcfF4yVJ9s9jdZ0whZQdGNzTiR4/rpCC9Uh7gmH0JkKQWmlTBFG6vWf+Gg7nViS
         ee72xBEZi9Z+mwDaokroJs5gd1NNzbuvjs9kO4dKPiKTWOzK7UyP95HbLAfRbY6amqgZ
         aEOA==
X-Gm-Message-State: AOAM5330SiwUgufD5qM6Jc8LDOgKnMhdPJVHekxor7e987hlMBHYPGTC
	selpFLR4lKuYmhNZfU2nXcgngGx+wU0YQ/p3FWEK3OVeK8s=
X-Google-Smtp-Source: ABdhPJygmpk45Tv6W0q+EJBfyNTN3vS1CbGtjATBZ89nwCO1aPY/4yYmjCXgRKIYAO8xoqyhRjROUmlj40YeKekzWrI=
X-Received: by 2002:a50:c056:0:b0:40f:9c6d:7701 with SMTP id
 u22-20020a50c056000000b0040f9c6d7701mr12354557edd.110.1645271960129; Sat, 19
 Feb 2022 03:59:20 -0800 (PST)
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: 
  
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
In-Reply-To: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
From: Archimedes Gaviola 
Date: Sat, 19 Feb 2022 19:59:02 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: Brian Scott 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000be136e05d85dba10"
X-Rspamd-Queue-Id: 4K16YQ0bJxz3vJ0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=PtfJ4fZ+;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.995];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.68:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.68:email];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10181
Lines: 230

--000000000000be136e05d85dba10
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 19, 2022 at 1:02 PM Brian Scott  wrote:

> On 19/2/22 9:52 am, Daniel O'Connor wrote:
> >
> >> On 19 Feb 2022, at 00:52, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >> Thanks for the info! I followed similar with your DS1307 RTC by
> creating a ds3231.dtso file and then compiling it with dtc to generate a
> ds3231.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address
> but when I run an i2c scan, the address detected is 68. Does this should
> match?
> > Mine was detected similarly:
> > iic0:  on iicbus0
> > rtc0:  at addr 0xd0 on iicbus0
> > usbus0: 5.0Gbps Super Speed USB v3.0
> > rtc0: registered as a time-of-day clock, resolution 1.000000s
> >
> > I am not sure why it shows up like that but it does seem to work.
> >
> >> With this setup I could update the date and time now by initiating an
> ntpdate to match our time plus invoking tzsetup command for my timezone
> which is doing well without any issue. Now, the moment I shutdown the
> system and plug back the power cable (with disconnected Ethernet cable just
> to make sure NTP servers are not called for updates upon restart) the time
> remains as it was before shutting down and then upon bootup system clock
> continues. I am expecting that it should be real time even if the RPi4
> system is shutdown or detached from power due to the battery that will
> sustain the continuity of the clock. I'm sure that I'm having good DS3231
> modules as I also tested my existing and another new spare and it is tested
> with OpenBSD too. Below are the system info. Is there anything I've missed?
> FreeBSD 13.0-RELEASE have the same outcome and behavior.
> > That is strange, I tested powering mine off and it kept time but I am
> not 100% sure it was advancing correctly - I didn't take a precise note of
> when I powered it off etc..
> >
> > Unfortunately it's not physically with me so I can't test it right now.
> >
> > I do note this sysctl:
> > machdep.rtc_save_period: Save system time to RTC with this period (in
> seconds)
> >
> > Which suggests to me that the clock could be up to 30 minutes off if the
> power is removed (I believe it gets flushed out on a clean shutdown
> though). Perhaps that is the problem?
> >
> > --
> > Daniel O'Connor
> > "The nice thing about standards is that there
> > are so many of them to choose from."
> >   -- Andrew Tanenbaum
> >
> >
> Hi people,
>
> I had the same problem a few months ago.
>
> The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to
> unilaterally claim anything at address 68. It doesn't understand the
> DS3231 and fails to operate properly, but in claiming the device, the
> ds3231 driver doesn't get a chance. This is compounded by the MAX77620
> driver being compiled into the kernel by default so the loadable module
> doesn't get to try until after the wrong driver has claimed it.
>
> The only answer at present is to build a custom kernel without the
> unwanted driver. My kernel config is:
>
> include         GENERIC
> ident           GENERIC-PI
> nooptions       SOC_NVIDIA_TEGRA210
>
> Ideally, the TEGRA210 code would be fixed or removed from the GENERIC
> kernel but that doesn't seem to have happened despite the adverse effect
> on the many clock devices that live at address 68 and will already be in
> use.
>
> I dislike building a custom kernel because everything else I do strives
> to use precompiled binaries whenever possible.
>

Okay, that explains. After re-compiling the kernel my system now already
detects the module. This is with 13.0-RELEASE.

root@fbsd13:~ # kldload ds3231
ds32310:  at addr 0xd0 on iicbus0
ds32310: registered as a time-of-day clock, resolution 1.000000s

freebsd@fbsd13:~ % sysctl -a | grep ds3231
        value:  /boot/kernel/ds3231.ko
dev.ds3231.0.32khz_enable: 1
dev.ds3231.0.sqw_mode: interrupt
dev.ds3231.0.sqw_freq: 8192
dev.ds3231.0.bbsqw: 0
dev.ds3231.0.temp_conv: 0
dev.ds3231.0.temperature: 39.1C
dev.ds3231.0.%parent: iicbus0
dev.ds3231.0.%pnpinfo: name=ds3231@68 compat=maxim,ds3231
dev.ds3231.0.%location: addr=0xd0
dev.ds3231.0.%driver: ds3231
dev.ds3231.0.%desc: Maxim DS3231 RTC
dev.ds3231.%parent:

I'm on my way with 14.0-CURRENT kernel recompilation.

Thanks a lot Brian for sharing the info and resolution! It is well
appreciated.

Thanks,
Archimedes

--000000000000be136e05d85dba10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Feb 19, 2022 at 1:02 PM Brian=
 Scott <bscott@bunyatech.com.=
au> wrote:
archimedes.gaviola@gmail.c=
om> wrote:

>> Thanks for the info! I followed similar with your DS1307 RTC by cr=
eating a ds3231.dtso file and then compiling it with dtc to generate a ds32=
31.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address but w=
hen I run an i2c scan, the address detected is 68. Does this should match?<=
br>
> Mine was detected similarly:

> iic0: <I2C generic I/O> on iicbus0

> rtc0: <MAX77620 RTC> at addr 0xd0 on iicbus0

> usbus0: 5.0Gbps Super Speed USB v3.0

> rtc0: registered as a time-of-day clock, resolution 1.000000s

>

> I am not sure why it shows up like that but it does seem to work.

>

>> With this setup I could update the date and time now by initiating=
 an ntpdate to match our time plus invoking tzsetup command for my timezone=
 which is doing well without any issue. Now, the moment I shutdown the syst=
em and plug back the power cable (with disconnected Ethernet cable just to =
make sure NTP servers are not called for updates upon restart) the time rem=
ains as it was before shutting down and then upon bootup system clock conti=
nues. I am expecting that it should be real time even if the RPi4 system is=
 shutdown or detached from power due to the battery that will sustain the c=
ontinuity of the clock. I'm sure that I'm having good DS3231 module=
s as I also tested my existing and another new spare and it is tested with =
OpenBSD too. Below are the system info. Is there anything I've missed? =
FreeBSD 13.0-RELEASE have the same outcome and behavior.

> That is strange, I tested powering mine off and it kept time but I am =
not 100% sure it was advancing correctly - I didn't take a precise note=
 of when I powered it off etc..

>

> Unfortunately it's not physically with me so I can't test it r=
ight now.

>

> I do note this sysctl:

> machdep.rtc_save_period: Save system time to RTC with this period (in =
seconds)

>

> Which suggests to me that the clock could be up to 30 minutes off if t=
he power is removed (I believe it gets flushed out on a clean shutdown thou=
gh). Perhaps that is the problem?

>

> --

> Daniel O'Connor

> "The nice thing about standards is that there

> are so many of them to choose from."

>=C2=A0 =C2=A0-- Andrew Tanenbaum

>

>

Hi people,



I had the same problem a few months ago.



The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to 

unilaterally claim anything at address 68. It doesn't understand the 
DS3231 and fails to operate properly, but in claiming the device, the 

ds3231 driver doesn't get a chance. This is compounded by the MAX77620 =


driver being compiled into the kernel by default so the loadable module 
doesn't get to try until after the wrong driver has claimed it.



The only answer at present is to build a custom kernel without the 

unwanted driver. My kernel config is:



include=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC

ident=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GENERIC-P=
I

nooptions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SOC_NVIDIA_TEGRA210



Ideally, the TEGRA210 code would be fixed or removed from the GENERIC 

kernel but that doesn't seem to have happened despite the adverse effec=
t 

on the many clock devices that live at address 68 and will already be in 
use.



I dislike building a custom kernel because everything else I do strives 
to use precompiled binaries whenever possible.



Okay, that explains. After re-compiling the kernel my system now alrea=
dy detects the module. This is with 13.0-RELEASE.

<=
div>root@fbsd13:~ # kldload ds3231
ds32310: <Maxim DS3231 RTC&=
gt; at addr 0xd0 on iicbus0
ds32310: registered as a time-of-day clock, =
resolution 1.000000s

freebsd@fbsd13:~ % sysctl=
 -a | grep ds3231
=C2=A0 =C2=A0 =C2=A0 =C2=A0 value: =C2=A0/boot/kernel/=
ds3231.ko
dev.ds3231.0.32khz_enable: 1
dev.ds3231.0.sqw_mode: interru=
pt
dev.ds3231.0.sqw_freq: 8192
dev.ds3231.0.bbsqw: 0
dev.ds3231.0.=
temp_conv: 0
dev.ds3231.0.temperature: 39.1C
dev.ds3231.0.%parent: ii=
cbus0
dev.ds3231.0.%pnpinfo: name=3Dds3231@68 compat=3Dmaxim,ds3231
d=
ev.ds3231.0.%location: addr=3D0xd0
dev.ds3231.0.%driver: ds3231
dev.d=
s3231.0.%desc: Maxim DS3231 RTC
dev.ds3231.%parent:

=


I'm on my way with 14.0-CURRENT kernel recompilation.




Thanks a lot Brian for sharing the info and resolution! It is well apprecia=
ted.

Thanks,
Archimedes








--000000000000be136e05d85dba10--

From nobody Sat Feb 19 12:19:25 2022
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 49D8719D85D6
	for ; Sat, 19 Feb 2022 12:19:45 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4K170w3zPrz4Qpj
	for ; Sat, 19 Feb 2022 12:19:44 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x634.google.com with SMTP id hw13so21119593ejc.9
        for ; Sat, 19 Feb 2022 04:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=dqS5ELeAFd9VmJoGq89TIlH6k7zukrW2mRFD4BYXeVM=;
        b=cIizrFRVMRhLRrPyAYYycJu9qJISdBbuGdypEJFAoTFAiSUDlVcjryHVJ2iwGas0EI
         GJa541HxWATJjxEKNNFWfcGV/7aVQiVk5/srWG1neME18EOuZWuL2tCyi/cmB8TSydGK
         Y1DgGv2zDlNho8ELol+OR97y7BZXrPlSRCtSMrq0WJbEKgZprZJzjpRLgZx1LS0TA1tG
         WiW+7xHG07+JzuIItlMegdCyPCrpNsoEpLUt5Xh0cr05kjuHf9qC+EM7kWkEUNe/Q3vX
         40A1qg8Io8RibpDcXmqIIiDKdJkJ28jat+bzO6/yyXjpycmBEeGoGauSUukDFUIraBzE
         Tk4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=dqS5ELeAFd9VmJoGq89TIlH6k7zukrW2mRFD4BYXeVM=;
        b=CQl2PP85X27ZPJL/uhaILES0OCL0F+gafeutIJ56MUBIsRk1Rhs12m0Ya6xcSTlUQe
         Ril1Uymg7Xe7M9wC+iuwUCAL7DGi54S60gRANQdx9L0a2cOeFsW9YPpp/AMGxYV7mZfG
         jI44HOH6yTJ6SmhRSP3NzXR8Jbp59XjhmeypkRlFTHkxjsjf2dFi0qMuecoACCauTbKv
         OcaLdRAbXVMuPccStl21hhP65HDkTUFg5CxmtmzTKmILVfZTT/RKJh4ucepd0fib+kUz
         EwyfokwUd2rJT5wLnYUgkrFIJc4KDc80oYMJh0z+DS3wStfbbGdwAyx7Q9b321Heb1KF
         ow/Q==
X-Gm-Message-State: AOAM531TSZJHQvPbWlbmoV2oeIuNNVJORbVTCUt1Jl0EhAcu4FlmdYnK
	l62jYfx+K5qnxiEKe3utiCZAM0X6YUbKyML1MValhpEF
X-Google-Smtp-Source: ABdhPJyRf5+5j6MPvKKZmE3lX5+xVPEdUFuME5WVCJuSyS4FuO6hzNSTbGhHH7TRxg5w/a9bjhwALHQlJbnm2UsceOs=
X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id
 b17-20020a1709063cb100b006ce2a975ademr9695466ejh.728.1645273183465; Sat, 19
 Feb 2022 04:19:43 -0800 (PST)
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: 
  
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
In-Reply-To: <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
From: Archimedes Gaviola 
Date: Sat, 19 Feb 2022 20:19:25 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000a8b40205d85e03ff"
X-Rspamd-Queue-Id: 4K170w3zPrz4Qpj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=cIizrFRV;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6301
Lines: 127

--000000000000a8b40205d85e03ff
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 19, 2022 at 6:52 AM Daniel O'Connor  wrote:

>
>
> > On 19 Feb 2022, at 00:52, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> > Thanks for the info! I followed similar with your DS1307 RTC by creating
> a ds3231.dtso file and then compiling it with dtc to generate a
> ds3231.dtbo. The result is it is detected as MAX77620 RTC on 0xd0 address
> but when I run an i2c scan, the address detected is 68. Does this should
> match?
>
> Mine was detected similarly:
> iic0:  on iicbus0
> rtc0:  at addr 0xd0 on iicbus0
> usbus0: 5.0Gbps Super Speed USB v3.0
> rtc0: registered as a time-of-day clock, resolution 1.000000s
>
> I am not sure why it shows up like that but it does seem to work.
>
> > With this setup I could update the date and time now by initiating an
> ntpdate to match our time plus invoking tzsetup command for my timezone
> which is doing well without any issue. Now, the moment I shutdown the
> system and plug back the power cable (with disconnected Ethernet cable just
> to make sure NTP servers are not called for updates upon restart) the time
> remains as it was before shutting down and then upon bootup system clock
> continues. I am expecting that it should be real time even if the RPi4
> system is shutdown or detached from power due to the battery that will
> sustain the continuity of the clock. I'm sure that I'm having good DS3231
> modules as I also tested my existing and another new spare and it is tested
> with OpenBSD too. Below are the system info. Is there anything I've missed?
> FreeBSD 13.0-RELEASE have the same outcome and behavior.
>
> That is strange, I tested powering mine off and it kept time but I am not
> 100% sure it was advancing correctly - I didn't take a precise note of when
> I powered it off etc..
>
> Unfortunately it's not physically with me so I can't test it right now.
>
> I do note this sysctl:
> machdep.rtc_save_period: Save system time to RTC with this period (in
> seconds)
>
> Which suggests to me that the clock could be up to 30 minutes off if the
> power is removed (I believe it gets flushed out on a clean shutdown
> though). Perhaps that is the problem?
>

Thanks for your feedback Daniel! With the exact DS3231 driver all the
concerns I've mentioned were answered. Once it is set manually via date or
ntpdate, the clock will now continue even if your system is shutdown (with
unplug power cable) or even detaching the module from the RPi4 system for
some time and then attaching it back will now be "real-time".

You can bring your DS1307 with the exact driver as well. Thanks a lot for
your help, it is well appreciated.

Archimedes

--000000000000a8b40205d85e03ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Feb 19, 2022 at 6:52 AM Danie=
l O'Connor <darius@dons.net.au=
> wrote:
=




> On 19 Feb 2022, at 00:52, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> Thanks for the info! I followed similar with your DS1307 RTC by creati=
ng a ds3231.dtso file and then compiling it with dtc to generate a ds3231.d=
tbo. The result is it is detected as MAX77620 RTC on 0xd0 address but when =
I run an i2c scan, the address detected is 68. Does this should match?



Mine was detected similarly:

iic0: <I2C generic I/O> on iicbus0

rtc0: <MAX77620 RTC> at addr 0xd0 on iicbus0

usbus0: 5.0Gbps Super Speed USB v3.0

rtc0: registered as a time-of-day clock, resolution 1.000000s



I am not sure why it shows up like that but it does seem to work.



> With this setup I could update the date and time now by initiating an =
ntpdate to match our time plus invoking tzsetup command for my timezone whi=
ch is doing well without any issue. Now, the moment I shutdown the system a=
nd plug back the power cable (with disconnected Ethernet cable just to make=
 sure NTP servers are not called for updates upon restart) the time remains=
 as it was before shutting down and then upon bootup system clock continues=
. I am expecting that it should be real time even if the RPi4 system is shu=
tdown or detached from power due to the battery that will sustain the conti=
nuity of the clock. I'm sure that I'm having good DS3231 modules as=
 I also tested my existing and another new spare and it is tested with Open=
BSD too. Below are the system info. Is there anything I've missed? Free=
BSD 13.0-RELEASE have the same outcome and behavior.



That is strange, I tested powering mine off and it kept time but I am not 1=
00% sure it was advancing correctly - I didn't take a precise note of w=
hen I powered it off etc..



Unfortunately it's not physically with me so I can't test it right =
now.



I do note this sysctl:

machdep.rtc_save_period: Save system time to RTC with this period (in secon=
ds)



Which suggests to me that the clock could be up to 30 minutes off if the po=
wer is removed (I believe it gets flushed out on a clean shutdown though). =
Perhaps that is the problem?

Thanks for your=
 feedback Daniel! With the exact DS3231 driver all the concerns I've me=
ntioned were answered. Once it is set manually via date or ntpdate, the clo=
ck will now continue even if your system is shutdown (with unplug power cab=
le) or even detaching the module from the RPi4 system for some time and the=
n attaching it back will now be "real-time".

You can bring your DS1307 =
with the exact driver as well. Thanks a lot for your help, it is well appre=
ciated.
=C2=A0
Archimedes


--000000000000a8b40205d85e03ff--

From nobody Sun Feb 20 03:51:38 2022
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 5364519C0790
	for ; Sun, 20 Feb 2022 03:52:21 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K1Why1fFGz3FL0
	for ; Sun, 20 Feb 2022 03:52:17 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21K3pq3p044387
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sun, 20 Feb 2022 14:22:01 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1645329124;
	bh=Wd577kcP2/MPK4sn6YZ8Hm+Bt7OSJEniCT0gtAeGTP4=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=QNq1O8nptiqPf9MXJhLExH82rs/dmwbAYPNwFENrjcC00gMm/hJZ1cqKYiz/xfHP8
	 Y1r7HSD//Z2PHjxXnpnchP8xHRNXrL2tbSJrAYosZTEfh25xeVGdHwxLEpsPPlpiQj
	 fSKr1aI/JjsR1uMaP2csw6pSWAQMibkQmYqHAmkM=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21K3pc4K044369
	for ; Sun, 20 Feb 2022 14:21:38 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:d837:ccfd:b9f8:b7f8
Received: from smtpclient.apple (2403-5800-5200-4700-d837-ccfd-b9f8-b7f8.ip6.aussiebb.net [2403:5800:5200:4700:d837:ccfd:b9f8:b7f8])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21K3pc6o044363; Sun, 20 Feb 2022 14:21:38 +1030
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 15.0 \(3693.40.0.1.81\))
Subject: Re: DS3231 RTC module not detected
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Sun, 20 Feb 2022 14:21:38 +1030
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-Spam-Score: 0.6 () No, score=0.6 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1
X-Rspamd-Queue-Id: 4K1Why1fFGz3FL0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=QNq1O8np;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-3.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[dons.net.au:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 767
Lines: 21



> On 19 Feb 2022, at 22:49, Archimedes Gaviola =
 wrote:
> Thanks for your feedback Daniel! With the exact DS3231 driver all the =
concerns I've mentioned were answered. Once it is set manually via date =
or ntpdate, the clock will now continue even if your system is shutdown =
(with unplug power cable) or even detaching the module from the RPi4 =
system for some time and then attaching it back will now be "real-time".
>=20
> You can bring your DS1307 with the exact driver as well. Thanks a lot =
for your help, it is well appreciated.
>=20
When you say "with the exact DS3231 driver.." what do you mean?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


From nobody Sun Feb 20 04:29:06 2022
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 0E8FE19C6002
	for ; Sun, 20 Feb 2022 04:29:31 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4K1XWt2N2Bz3J0G
	for ; Sun, 20 Feb 2022 04:29:30 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62f.google.com with SMTP id a23so24581779eju.3
        for ; Sat, 19 Feb 2022 20:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=CntG3f0a+k946cyPyAwzCeY9lil5NNJRR/m3RzpjG3Y=;
        b=KMVH5Tqi/7sw72aSzjUJHIJJUjETPVA5tvcVR2IDfEWZpiUn4ckR7Pp90IPiJXCv5b
         WxjwkBo9GASZGMiAz+9blv8FkW/TO8dmaOnESMAM3GxHFXnRNL4GEl3FVZ/x5tJ5g8OX
         xENqbdLKS2DNt7uTDB3TquyYviJ7nsPVlvTRA2hgkYgP6szC+zIfVRUXENN7OGufL3uF
         rDemRYSNv6akjkfTGG44bIYc41yorQdv9XAn90cQ3YHAZIcMp2DWzGyxYmvalMgn4LFr
         Z9K0yjm3VCxrAdwfJ8kUPrNDIQ0uViNLoasv0e/MwsiWODpxMY3wUxEuQy3v6TGiZcZ0
         aOGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=CntG3f0a+k946cyPyAwzCeY9lil5NNJRR/m3RzpjG3Y=;
        b=XLv+qz9EwogmJnInjeLzLBiiIrYaLxF1sa4mECLv86gFJ/+7wC6ClVbKfUfRY2tFem
         iBlpbUskK8Nv38m8Vib0c5jVTdXEepy9KJrhnDVX+6dqyiMnD4CQKZjND9Tmtbvr2oUZ
         khDE2AdVN/MB9+rN4eJCvMQn25VQsgqoRLP+dGDsVCz8CpFRTTY3G3wZewMfmKCNTLuS
         gViuT8HTkPdhMFFnrU4eze/W3yyE/doqSsXPUkhTKBUzIDOhwoN2YL3rr7MHRb/5nacK
         Y5FCek7lhWj9P2OQ5Ll5eYZZGqOW7eAbpikwqbA5QilDNLC8A+f6CwVOWUj0W+p0LAcd
         gkwg==
X-Gm-Message-State: AOAM530gC6+KdBsWnLRY3Ixyb/4QAxoe5eqK+f01smx7AXxfRunE1lw0
	hY99OaO609TFj89cVPG8cdX0aLW0fOX2F31pDPvkx1hpeqw=
X-Google-Smtp-Source: ABdhPJz6vrWfBedA3pQwu8r743+PO3Va3CygaEK82R91aoOmCpBD1eCnyFLYsXqDwYVO4UekkNskhZeHJlNGVHW4T3U=
X-Received: by 2002:a17:907:9208:b0:6cf:cd92:c1e7 with SMTP id
 ka8-20020a170907920800b006cfcd92c1e7mr11844410ejb.282.1645331363637; Sat, 19
 Feb 2022 20:29:23 -0800 (PST)
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: 
  
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
In-Reply-To: <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
From: Archimedes Gaviola 
Date: Sun, 20 Feb 2022 12:29:06 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000077ad0605d86b8f65"
X-Rspamd-Queue-Id: 4K1XWt2N2Bz3J0G
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=KMVH5Tqi;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3607
Lines: 76

--00000000000077ad0605d86b8f65
Content-Type: text/plain; charset="UTF-8"

On Sun, Feb 20, 2022 at 11:51 AM Daniel O'Connor  wrote:

>
>
> > On 19 Feb 2022, at 22:49, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> > Thanks for your feedback Daniel! With the exact DS3231 driver all the
> concerns I've mentioned were answered. Once it is set manually via date or
> ntpdate, the clock will now continue even if your system is shutdown (with
> unplug power cable) or even detaching the module from the RPi4 system for
> some time and then attaching it back will now be "real-time".
> >
> > You can bring your DS1307 with the exact driver as well. Thanks a lot
> for your help, it is well appreciated.
> >
> When you say "with the exact DS3231 driver.." what do you mean?
>

I mean the appropriate DS3231 driver - ds3231(4) for the module which is a
kernel loadable as the dominating driver with 13.0-RELEASE and 14.0-CURRENT
which is MAX77620 RTC is the wrong one thus the module will not work
properly. The clock stops and goes back to the time when you set it. This
behavior is observable when my RPi system is rebooted or shutdown. With the
loadable  ds3231 driver, this behavior is no longer observed and working as
expected. For your DS1307, there's also an equivalent and perhaps the
appropriate driver as described in the manual ds1307(4), it can be loaded
as well via kldload.

Thanks,
Archimedes

--00000000000077ad0605d86b8f65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Feb 20, 2022 at 11:51 AM Dani=
el O'Connor <darius@dons.net.a=
u> wrote:




> On 19 Feb 2022, at 22:49, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> Thanks for your feedback Daniel! With the exact DS3231 driver all the =
concerns I've mentioned were answered. Once it is set manually via date=
 or ntpdate, the clock will now continue even if your system is shutdown (w=
ith unplug power cable) or even detaching the module from the RPi4 system f=
or some time and then attaching it back will now be "real-time".<=
br>
> 

> You can bring your DS1307 with the exact driver as well. Thanks a lot =
for your help, it is well appreciated.

> 

When you say "with the exact DS3231 driver.." what do you mean?

I mean the appropriate DS3231 driver - ds3231=
(4) for the module which is a kernel loadable as the dominating driver with=
 13.0-RELEASE and 14.0-CURRENT which is=20
MAX77620 RTC

is the wrong one thus the module will not work properly. The clock stops an=
d goes back to the time when you set it. This behavior is observable when m=
y RPi system is rebooted or shutdown. With the loadable=C2=A0
ds3231

 driver, this behavior is no longer observed and working as expected. For y=
our DS1307, there's also an equivalent and perhaps the appropriate driv=
er as described in the manual ds1307(4), it can be loaded as well via kldlo=
ad.

Thanks,
Archimedes


--00000000000077ad0605d86b8f65--

From nobody Sun Feb 20 10:30:24 2022
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 8335D19E6A13
	for ; Sun, 20 Feb 2022 10:30:28 +0000 (UTC)
	(envelope-from avg@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 4K1hXN2zbMz4ZXZ;
	Sun, 20 Feb 2022 10:30:28 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1645353028;
	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=Rr1Fg58TpJYxw6lnA0lCLdykzonVPspHImmh2jhOwNs=;
	b=O4DRrMRRyox6rU6btRApwbWMxYIobRy/+As83YMeuq3Yk1414RhB1LBfV+vg2a6cRcMsF/
	Bp0kRtaqow0WV5+l43owzdoWIQk9YOaFXmiUlk2SSV0e9kZgAu8jlap6T0urOtOuBLf7/W
	/r3pjpjyHc74AVZZHLupUVUrvvHwwbnJMWMkgj/CBrCeOP0j73j9nZTNZMRzdLlaZ23pjG
	LhkAhZNXylJoqCnQA5nvVybteQZ8Nvs9dBdhEeA/h+N3+yclv3JhbzsqepsnPALiE8/eF7
	3+mPFFkxcrHJq8vkswDAEXO4sz8/uMCB4VRy9IDXOe3AVDL3BmqZfR0Fl3ZSwQ==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: avg/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id C354D26DA2;
	Sun, 20 Feb 2022 10:30:27 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: <1015913d-ea06-2524-e988-f8a4a04366f9@FreeBSD.org>
Date: Sun, 20 Feb 2022 12:30:24 +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:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.6.0
Subject: Re: DS3231 RTC module not detected
Content-Language: en-US
To: Archimedes Gaviola ,
 Daniel O'Connor 
Cc: freebsd-arm@freebsd.org
References: 
 
 
From: Andriy Gapon 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645353028;
	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=Rr1Fg58TpJYxw6lnA0lCLdykzonVPspHImmh2jhOwNs=;
	b=e4B7JINMMdCEi9UgPT7C8x6LEvNM5piqxNEIiYqmN9FIRGlYONnlzjkWw1M8gHKtyH2UDQ
	41o0SXdOLL6VJi9XXrAwBQchsC/Wnf2GiqSZJ9V+DFqua+RX3dcLrbz8wILKQelYFdIv1f
	9r/JWq6KIWL0cSXH17s3Oi1DD4sBUCh8C3QP9OMElxqWz41uaCb5bhhHUTxhA1yH2PBWa5
	UjBnPYh7sOzXRKc2nPNR+PfWgOeNDtrHXtJxmK/jfZjFgUEVKpsSa6TPkQNzx0x48WHuAn
	2EiWjhEZwsQz9XNHCdM0HH7duVt1B3XjKB+jLq0urG2KkFxeZXno5PEOoUG01A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645353028; a=rsa-sha256; cv=none;
	b=sIoBI3TsgLd3/sBd3O8jAQG6xYm/jQjguTF/Lb3APe/69B6OBQnyFdCrsrKPbWn3aSbmfM
	I+cC+3uCpimPlTSTN82m1BFwellGxEB7tQu2LzMomcGczWw4QbNIl7XME7EkSGURu/dAHq
	EW61Up4KJ7KAkdfz7V0YuaIIAngveT+cWYvj+EZn9FQs2fZ7LM5t2DNMpYKd2PuXD6b2hg
	pxwBIKGF8zuXTt12mY026MhEiXvVakduUKLOXaFikKZ1ubEU48x9rgtF0rz8AY0dyKHZbF
	yp7y8ItCQZbSeHYEqWtCVLOwo7MO9ac3qJQjJBDvkebKo32mF0lgUEo9R1bi1Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 340
Lines: 9

On 18/02/2022 16:22, Archimedes Gaviola wrote:
> The result is it is detected as MAX77620 RTC on 0xd0 address but when I run an 
> i2c scan, the address detected is 68. Does this should match?

0xd0 and 0x68 are different representations of the same I2C address.
If you write it out in binary (base of two), you will see.

-- 
Andriy Gapon

From nobody Sun Feb 20 11:42:47 2022
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 DD1EA19D2D5B
	for ; Sun, 20 Feb 2022 11:42:49 +0000 (UTC)
	(envelope-from melounmichal@gmail.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4K1k7s00hwz4jP8
	for ; Sun, 20 Feb 2022 11:42:49 +0000 (UTC)
	(envelope-from melounmichal@gmail.com)
Received: by mail-ed1-x52f.google.com with SMTP id u18so23722540edt.6
        for ; Sun, 20 Feb 2022 03:42:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:from:message-id:date:mime-version:user-agent:reply-to
         :subject:content-language:to:references:in-reply-to
         :content-transfer-encoding;
        bh=mdiBaoRzR/zD0rSDak2DcOink6r1vYsC1lYH5qAMHdg=;
        b=n1A+jmn+iODb1Yxg2tVcHfKQF3w7g6NCSZXjoRUsCpZpwR5RP2iCOHm3v0uTSyfVPj
         GVmu4hpFLBM5HSffkcCWCMqr1uNTGSaZ894/RJsQARHJWVTbtCjAqKr8dzUTuP5nBMnF
         iCVDM2qXpp0GAH0PTp5tZXPCR4fQDGR+q/f+SMeI1hkq3D1Cr8aAwe9/J3gISY8qORZP
         Rwku+KXc04yWwgWowpd+uBqxeQ7vjamV/zFhwCQuDO7bywDQEm9uCcVNsKiYULKJ83BG
         Bj+KMMJ89JyNaQyjYAup5nTUSQVa+Pg7PBe1YBIRTRLJ2JMYig1f52gL4KduOHvVYHat
         cHCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:from:message-id:date:mime-version
         :user-agent:reply-to:subject:content-language:to:references
         :in-reply-to:content-transfer-encoding;
        bh=mdiBaoRzR/zD0rSDak2DcOink6r1vYsC1lYH5qAMHdg=;
        b=toOlFcs5uhFJAy+4dDIBeq45EKdCksFxMATi7h3o64yZokMXLT5kZkWWcT0IiKpacd
         LBgPjXFqtTNfjDhSyYb19nPIxCirGyKuNIduFgT+TDKKTxiBYX7Xv3294eZSZXbA7Rmv
         Yvr7BWoGGmoxaZYrK3vMKVKcQwpE+XgnSr7QUiZCurn/H9WSTSvpxhzf0Jz8g5+sKTz7
         +yW6tI9tG+UyawMpXGe5o7TiwssmA/LLsQPfWKzRFfxvwsc02kBXbKVbT4PJ6iRyNzLN
         g1MqQuMOi6aiXOPHD6D9J0R0ci7KsrAXnTcgmIThcwwRa4ZgcrJkvlSt2j2hsLz1uGzs
         3MtQ==
X-Gm-Message-State: AOAM530kD7YWcph7b9lZ7zXM2AeqbKClcHQBu42tNFe6UhINdrAVsWj+
	jrINPoSqW/MVcmHrk9/FCWbn3UOGcBE=
X-Google-Smtp-Source: ABdhPJz6HDuuCl4pQldaN6mEOgymn02cu8YgiF+Kzn8zWylaPC7NYrZ+zNEug9kTXlJ6s5r6QGNBzA==
X-Received: by 2002:a05:6402:42ca:b0:408:ed7:b011 with SMTP id i10-20020a05640242ca00b004080ed7b011mr16190527edc.6.1645357367840;
        Sun, 20 Feb 2022 03:42:47 -0800 (PST)
Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100])
        by smtp.gmail.com with ESMTPSA id m25sm4144011ejl.38.2022.02.20.03.42.47
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 20 Feb 2022 03:42:47 -0800 (PST)
From: Michal Meloun 
X-Google-Original-From: Michal Meloun 
Message-ID: 
Date: Sun, 20 Feb 2022 12:42:47 +0100
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Reply-To: mmel@freebsd.org
Subject: Re: DS3231 RTC module not detected
Content-Language: en-US
To: Brian Scott , freebsd-arm@freebsd.org
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
 <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
In-Reply-To: <982a60c8-81f9-4e57-9b0c-41a16fad45f7@bunyatech.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4K1k7s00hwz4jP8
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=n1A+jmn+;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=melounmichal@gmail.com
X-Spamd-Result: default: False [-0.87 / 15.00];
	 HAS_REPLYTO(0.00)[mmel@freebsd.org];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.997];
	 NEURAL_HAM_LONG(-0.98)[-0.978];
	 MIME_GOOD(-0.10)[text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.11)[0.114];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3625
Lines: 92



On 19.02.2022 6:01, Brian Scott wrote:
> On 19/2/22 9:52 am, Daniel O'Connor wrote:
>>
>>> On 19 Feb 2022, at 00:52, Archimedes Gaviola 
>>>  wrote:
>>> Thanks for the info! I followed similar with your DS1307 RTC by 
>>> creating a ds3231.dtso file and then compiling it with dtc to 
>>> generate a ds3231.dtbo. The result is it is detected as MAX77620 RTC 
>>> on 0xd0 address but when I run an i2c scan, the address detected is 
>>> 68. Does this should match?
>> Mine was detected similarly:
>> iic0:  on iicbus0
>> rtc0:  at addr 0xd0 on iicbus0
>> usbus0: 5.0Gbps Super Speed USB v3.0
>> rtc0: registered as a time-of-day clock, resolution 1.000000s
>>
>> I am not sure why it shows up like that but it does seem to work.
>>
>>> With this setup I could update the date and time now by initiating an 
>>> ntpdate to match our time plus invoking tzsetup command for my 
>>> timezone which is doing well without any issue. Now, the moment I 
>>> shutdown the system and plug back the power cable (with disconnected 
>>> Ethernet cable just to make sure NTP servers are not called for 
>>> updates upon restart) the time remains as it was before shutting down 
>>> and then upon bootup system clock continues. I am expecting that it 
>>> should be real time even if the RPi4 system is shutdown or detached 
>>> from power due to the battery that will sustain the continuity of the 
>>> clock. I'm sure that I'm having good DS3231 modules as I also tested 
>>> my existing and another new spare and it is tested with OpenBSD too. 
>>> Below are the system info. Is there anything I've missed? FreeBSD 
>>> 13.0-RELEASE have the same outcome and behavior.
>> That is strange, I tested powering mine off and it kept time but I am 
>> not 100% sure it was advancing correctly - I didn't take a precise 
>> note of when I powered it off etc..
>>
>> Unfortunately it's not physically with me so I can't test it right now.
>>
>> I do note this sysctl:
>> machdep.rtc_save_period: Save system time to RTC with this period (in 
>> seconds)
>>
>> Which suggests to me that the clock could be up to 30 minutes off if 
>> the power is removed (I believe it gets flushed out on a clean 
>> shutdown though). Perhaps that is the problem?
>>
>> -- 
>> Daniel O'Connor
>> "The nice thing about standards is that there
>> are so many of them to choose from."
>>   -- Andrew Tanenbaum
>>
>>
> Hi people,
> 
> I had the same problem a few months ago.
> 
> The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to 
> unilaterally claim anything at address 68. It doesn't understand the 
> DS3231 and fails to operate properly, but in claiming the device, the 
> ds3231 driver doesn't get a chance. This is compounded by the MAX77620 
> driver being compiled into the kernel by default so the loadable module 
> doesn't get to try until after the wrong driver has claimed it.
> 
> The only answer at present is to build a custom kernel without the 
> unwanted driver. My kernel config is:
> 
> include         GENERIC
> ident           GENERIC-PI
> nooptions       SOC_NVIDIA_TEGRA210
> 
> Ideally, the TEGRA210 code would be fixed or removed from the GENERIC 
> kernel but that doesn't seem to have happened despite the adverse effect 
> on the many clock devices that live at address 68 and will already be in 
> use.
> 
> I dislike building a custom kernel because everything else I do strives 
> to use precompiled binaries whenever possible.
> 
> Cheers,
> 
> 
> Brian
> 
>

Thanks for report,
it should be fixed in a534b50e245d

Michal


From nobody Sun Feb 20 21:00:15 2022
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 8D5C319C95A4
	for ; Sun, 20 Feb 2022 21:00:16 +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 4K1yW36Dflz3Kw3
	for ; Sun, 20 Feb 2022 21:00:15 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 A4488235B6
	for ; Sun, 20 Feb 2022 21:00:15 +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 21KL0F48065830
	for ; Sun, 20 Feb 2022 21:00:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21KL0FrQ065829
	for freebsd-arm@FreeBSD.org; Sun, 20 Feb 2022 21:00:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202202202100.21KL0FrQ065829@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, 20 Feb 2022 21:00:15 +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="16453908152.A8EA6647.64779"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645390815;
	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=p8PQo2ofnoUDdS01bY6wTS5C/BySwp2VV1yWMeYsKE0=;
	b=Aq6HGpNjPYgTFSztU+L2O+2OBUCRfk1gOA42AKW8Nn7T5gMQ8VnNxwF7np/1zNR6iHCctB
	ZRHVy05WeUP19+kjiq5RzH9EDfgUHojm23XLv9gZ2s/Om1Sc6f606vzIkobLpoC7SChA0h
	xq833AabZpsJgSEkZzuuOsqVXn0HKUprZ4HASgiSCW1y78ymnPx62FL609J2jQZt2z4ENo
	EFUPKTemYz4wKLRiORZeR9/qNYCQGagfQ+pd1kRDz7Jaxt/2e9OGG3cLVLjDs5eeWkxT3L
	a5WM2IWwpf5VOQad8lHKsmm6Q54lUIf9YEuTOqs42f7E7SfsJr9/b2A/9/k8NA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645390815; a=rsa-sha256; cv=none;
	b=PTKDZla5ALtSAIsFTNX3feYd6Dzt1dMYTOj8cyg3ctClVQTC6O/M+bw5jMcP+9uD1vt0W+
	1pE9KWgRxvT0DBRsYL7Im5iaLC1+zawGOb4T1P3pbUXs9HETdTBoayvkELNIyjDq1PTZ9m
	8cGGuy3BS61JJtdqfb7qx8F+tMUVa9sa7ACquWOvY3elTVnwlyr9DuUYmycIYhDoGpeMUf
	Bf4eiyGh+oUH2x5Odj4WAYEi04UHdh2oqY7+xy6KaFy8W2RXjTVlhB/j/CKT5pLRHqRakY
	Uab2Jd2BXPAtZeUuJ6HUAwPovCVjcyrhAg6pyvKfN4WPLJayoVmptDin5R5n3Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1807
Lines: 38


--16453908152.A8EA6647.64779
Date: Sun, 20 Feb 2022 21:00:15 +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.

--16453908152.A8EA6647.64779
Date: Sun, 20 Feb 2022 21:00:15 +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.


--16453908152.A8EA6647.64779--

From nobody Sun Feb 20 22:26:26 2022
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 A1AD219DD535;
	Sun, 20 Feb 2022 22:26:39 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1])
	(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 "smtp", Issuer "smtp" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K20Qk2HF1z3sb7;
	Sun, 20 Feb 2022 22:26:37 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (kx.truefc.org [36.52.212.1])
       by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 21KMQQxG082376;
       Mon, 21 Feb 2022 07:26:26 +0900 (JST)
       (envelope-from kiri@kx.truefc.org)
Message-Id: <202202202226.21KMQQxG082376@kx.truefc.org>
Date: Mon, 21 Feb 2022 07:26:26 +0900
From: KIRIYAMA Kazuhiko 
To: x11@freebsd.org
Cc: freebsd-arm@freebsd.org, KIRIYAMA Kazuhiko 
Subject: Is there any X driver for Panfrost on PBP ?
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24)
 (Standard C) (amd64--freebsd)
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 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4K20Qk2HF1z3sb7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org
X-Spamd-Result: default: False [-2.02 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.93)[-0.930];
	 FREEFALL_USER(0.00)[kiri];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[truefc.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.98)[-0.985];
	 MLMMJ_DEST(0.00)[freebsd-arm,x11];
	 RCVD_COUNT_ONE(0.00)[1];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ONCE_RECEIVED(0.10)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 27030
Lines: 485

Hi, lists

I'm tring to start X with builtin Mali-T860MP4 Quad-core
GPU on Pinebook Pro (PBP). I've wakeuped GPU with panfrost :

---<>---
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 compliance
Copyright (c) 1992-2022 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-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022
    root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 1920x1080
module firmware already present!
real memory  = 4150083584 (3957 MB)
avail memory = 4021764096 (3835 MB)
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
Starting CPU 4 (100)
Starting CPU 5 (101)
FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs
random: unblocking device.
random: entropy device external interface
MAP f3f10000 mode 2 pages 4
MAP f3f15000 mode 2 pages 4
MAP f6f30000 mode 2 pages 16
kbd0 at kbdmux0
ofwbus0: 
clk_fixed0:  on ofwbus0
simplebus0:  on ofwbus0
rk_grf0:  mem 0xff320000-0xff320fff on ofwbus0
rk3399_pmucru0:  mem 0xff750000-0xff750fff on ofwbus0
rk3399_cru0:  mem 0xff760000-0xff760fff on ofwbus0
rk_grf1:  mem 0xff770000-0xff77ffff on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
regfix3:  on ofwbus0
regfix4:  on ofwbus0
regfix5:  on ofwbus0
regfix6:  on ofwbus0
regfix7:  on ofwbus0
regfix8:  on ofwbus0
regfix9:  on ofwbus0
regfix10:  on ofwbus0
regfix11:  on ofwbus0
simple_mfd0:  mem 0xff310000-0xff310fff on ofwbus0
psci0:  on ofwbus0
rk_drm0:  on ofwbus0
gic0:  mem 0xfee00000-0xfee0ffff,0xfef00000-0xfefbffff,0xfff00000-0xfff0ffff,0xfff10000-0xfff1ffff,0xfff20000-0xfff2ffff irq 18 on ofwbus0
its0:  mem 0xfee20000-0xfee3ffff on gic0
rk_iodomain0:  mem 0-0xff31ffff,0-0xfff on rk_grf0
rk_iodomain1:  mem 0-0xff76ffff,0-0xffff on rk_grf1
rk_pinctrl0:  on ofwbus0
gpio0:  mem 0xff720000-0xff7200ff irq 71 on rk_pinctrl0
gpiobus0:  on gpio0
gpio1:  mem 0xff730000-0xff7300ff irq 72 on rk_pinctrl0
gpiobus1:  on gpio1
gpio2:  mem 0xff780000-0xff7800ff irq 73 on rk_pinctrl0
gpiobus2:  on gpio2
gpio3:  mem 0xff788000-0xff7880ff irq 74 on rk_pinctrl0
gpiobus3:  on gpio3
gpio4:  mem 0xff790000-0xff7900ff irq 75 on rk_pinctrl0
gpiobus4:  on gpio4
rk_i2c0:  mem 0xff110000-0xff110fff irq 20 on ofwbus0
iicbus0:  on rk_i2c0
rk_i2c1:  mem 0xff130000-0xff130fff irq 22 on ofwbus0
iicbus1:  on rk_i2c1
rk_i2c2:  mem 0xff3c0000-0xff3c0fff irq 38 on ofwbus0
iicbus2:  on rk_i2c2
fan53555_pmic0:  at addr 0x80 on iicbus2
fan53555_pmic1:  at addr 0x82 on iicbus2
rk_i2c3:  mem 0xff3d0000-0xff3d0fff irq 39 on ofwbus0
iicbus3:  on rk_i2c3
rk808_pmu0:  at addr 0x36 irq 76 on iicbus2
rk_vop0:  mem 0xff8f0000-0xff8f3efb irq 53 on ofwbus0
rk_vop0: VOP version: 3068896
generic_timer0:  irq 2,3,4,5 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
rk_tsadc0:  mem 0xff260000-0xff2600ff irq 35 on ofwbus0
mmc_pwrseq0:  on ofwbus0
rk_edp0:  mem 0xff970000-0xff977fff irq 62 on ofwbus0
rk_usb2phy0:  mem 0-0xff76ffff,0-0xffff on rk_grf1
rk_usb2phy1:  mem 0-0xff76ffff,0-0xffff on rk_grf1
rk_emmcphy0:  mem 0-0xff76ffff,0-0xffff on rk_grf1
rk_pcie_phy0:  mem 0-0xff76ffff,0-0xffff on rk_grf1
rk_typec_phy0:  mem 0xff7c0000-0xff7fffff on ofwbus0
rk_typec_phy1:  mem 0xff800000-0xff83ffff on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
cpufreq_dt0:  on cpu0
cpufreq_dt0: Found cpu-supply
cpu1:  on cpulist0
cpufreq_dt1:  on cpu1
cpufreq_dt1: Found cpu-supply
cpu2:  on cpulist0
cpufreq_dt2:  on cpu2
cpufreq_dt2: Found cpu-supply
cpu3:  on cpulist0
cpufreq_dt3:  on cpu3
cpufreq_dt3: Found cpu-supply
cpu4:  on cpulist0
cpufreq_dt4:  on cpu4
cpufreq_dt4: Found cpu-supply
cpu5:  on cpulist0
cpufreq_dt5:  on cpu5
cpufreq_dt5: Found cpu-supply
pmu0:  irq 0 on ofwbus0
pmu1:  irq 1 on ofwbus0
pcib0:  mem 0xf8000000-0xf9ffffff,0xfd000000-0xfdffffff irq 6,7,8 on ofwbus0
pcib0: Gen1 link training timeouted: 0x00080001.
pci0:  on pcib0
pcib1:  at device 0.0 on pci0
pcib0: failed to reserve resource for pcib1
pcib1: failed to allocate initial memory window: 0-0xfffff
pci1:  on pcib1
rockchip_dwmmc0:  mem 0xfe310000-0xfe313fff irq 10 on ofwbus0
rockchip_dwmmc0: Hardware version ID is 270a
rockchip_dwmmc1:  mem 0xfe320000-0xfe323fff irq 11 on ofwbus0
rockchip_dwmmc1: Hardware version ID is 270a
sdhci_fdt0:  mem 0xfe330000-0xfe33ffff irq 12 on ofwbus0
rk_emmcphy0: got emmcclk clock
sdhci_fdt0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk.
sdhci_fdt0: 1 slot(s) allocated
mmc0:  on sdhci_fdt0
ehci0:  mem 0xfe380000-0xfe39ffff irq 13 on ofwbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ohci0:  mem 0xfe3a0000-0xfe3bffff irq 14 on ofwbus0
usbus1 on ohci0
ehci1:  mem 0xfe3c0000-0xfe3dffff irq 15 on ofwbus0
usbus2: EHCI version 1.0
usbus2 on ehci1
ohci1:  mem 0xfe3e0000-0xfe3fffff irq 16 on ofwbus0
usbus3 on ohci1
rk_dwc30:  on ofwbus0
xhci0:  mem 0xfe800000-0xfe8fffff irq 77 on rk_dwc30
xhci0: 64 bytes context size, 32-bit DMA
usbus4: trying to attach
usbus4 on xhci0
rk_dwc31:  on ofwbus0
xhci1:  mem 0xfe900000-0xfe9fffff irq 78 on rk_dwc31
xhci1: 64 bytes context size, 32-bit DMA
usbus5: trying to attach
usbus5 on xhci1
es8316codec0:  at addr 0x22 on iicbus0
iic0:  on iicbus0
iic1:  on iicbus1
uart0:  mem 0xff180000-0xff1800ff irq 26 on ofwbus0
uart0: debug port (-1,n,8,1)
uart1: <16750 or compatible> mem 0xff1a0000-0xff1a00ff irq 28 on ofwbus0
uart1: console (1500000,n,8,1)
spi0:  mem 0xff1d0000-0xff1d0fff irq 31 on ofwbus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
iic2:  on iicbus2
iicbus3:  at addr 0x44
iic3:  on iicbus3
pwm0:  mem 0xff420000-0xff42000f on ofwbus0
pwmbus0:  on pwm0
pwmc0:  channel 0 on pwmbus0
pwm1:  mem 0xff420020-0xff42002f on ofwbus0
pwmbus1:  on pwm1
pwmc1:  channel 0 on pwmbus1
i2s0:  mem 0xff890000-0xff890fff irq 51 on ofwbus0
Cannot set frequency for clk: clkin_i2s, error: 34
Cannot set frequency for clk: xin24m, error: 34
pcm0:  on ofwbus0
gpioc0:  on gpio0
gpioc1:  on gpio1
gpioc2:  on gpio2
gpioc3:  on gpio3
gpioc4:  on gpio4
rk_edp_panel0:  on ofwbus0
gpioled0:  on ofwbus0
pcm1:  on ofwbus0
simpleamp0:  on ofwbus0
armv8crypto0: 
Timecounters tick every 1.000 msec
rk_drm0: port found
usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
<6>[drm] Connector eDP-1: get mode from tunables:
<6>[drm]   - kern.vt.fb.modes.eDP-1
<6>[drm]   - kern.vt.fb.default_mode
rk_drm0: Cannot find port with phandle 10
rk_drm_fb_preinit
<6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
<6>[drm] No driver support for vblank timestamp query.
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
<6>[drm] Initialized rockchip 1.0.0 20201113 for rk_drm on minor 0
rk808_pmu0: registered as a time-of-day clock, resolution 1.000000s
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
ugen0.1:  at usbus0
uhub1 on usbus0
uhub1:  on usbus0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 5.0Gbps Super Speed USB v3.0
usbus5: 5.0Gbps Super Speed USB v3.0
ugen5.1:  at usbus5
uhub2 on usbus5
uhub2:  on usbus5
ugen4.1:  at usbus4
uhub3 on usbus4
uhub3:  on usbus4
ugen3.1:  at usbus3
uhub4 on usbus3
uhub4:  on usbus3
ugen2.1:  at usbus2
uhub5 on usbus2
uhub5:  on usbus2
WARNING cur_vblank != vblank->last failed at /usr/src/sys/dev/drm/core/drm_vblank.c:279
mmcsd0: 125GB  at mmc0 25.0MHz/8bit/65535-block
mmcsd0boot0: 4MB partition 1 at mmcsd0
mmcsd0boot1: 4MB partition 2 at mmcsd0
mmcsd0rpmb: 17MB partition 3 at mmcsd0
pcm0: no driver attached to cpu node
Cannot set frequency for clk: clkin_i2s, error: 34
Cannot set frequency for clk: xin24m, error: 34
pcm1: failed to set sysclk for aux node
pcm1: failed to set sysclk for aux node
pcm1: failed to set sysclk for aux node
pcm1: failed to set sysclk for aux node
CPU  0: ARM Cortex-A53 r0p4 affinity:  0  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
CPU  1: ARM Cortex-A53 r0p4 affinity:  0  1
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
      Memory Model Features 0 = 
CPU  2: ARM Cortex-A53 r0p4 affinity:  0  2
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
      Memory Model Features 0 = 
CPU  3: ARM Cortex-A53 r0p4 affinity:  0  3
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
      Memory Model Features 0 = 
CPU  4: ARM Cortex-A72 r0p2 affinity:  1  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
      Memory Model Features 0 = 
CPU  5: ARM Cortex-A72 r0p2 affinity:  1  1
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
      Memory Model Features 0 = 
Release APs...done
Trying to mount root from ufs:/dev/mmcsd0p3 [rw]...
uhub0: 1 port with 1 removable, self powered
Unresolved linked clock found: clkin_gmac
uhub4: 1 port with 1 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
Dual Console: Serial Primary, Video Secondary
uhub1: 1 port with 1 removable, self powered
uhub5: 1 port with 1 removable, self powered
ugen5.2:  at usbus5
ure0 on uhub2
ure0:  on usbus5
miibus0:  on ure0
rgephy0:  PHY 0 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
ue0:  on ure0
ue0: Ethernet address: a0:ce:c8:de:9c:95
Waiting 30s for the root mount holders: usbus2ugen2.2:  at usbus2
uhub6 on uhub5
uhub6:  on usbus2
ugen1.2:  at usbus1
ukbd0 on uhub0
ukbd0:  on usbus1
kbd1 at ukbd0
ums0 on uhub0
ums0:  on usbus1
ums0: 3 buttons and [XY] coordinates ID=1
uhub6: 4 ports with 4 removable, self powered
.ugen2.3:  at usbus2
Setting hostuuid: 31323634-3737-6236-6162-336630376339.
Setting hostid: 0x5d4b60f9.
warning: total configured swap (4194304 pages) exceeds maximum recommended amount (3929384 pages).
warning: increase kern.maxswzone or reduce amount of swap.
Starting file system checks:
/dev/mmcsd0p3: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/mmcsd0p3: clean, 11381889 free (18521 frags, 1420421 blocks, 0.1% fragmentation)
Mounting local filesystems:.
Loading kernel modules:
panfrost0:  mem 0xff9a0000-0xff9affff irq 63,64,65 on ofwbus0
panfrost0: Mali GPU clock rate 500000000 Hz
panfrost0: GPU revision 2000, id 860
panfrost0: Mali 860, major 2, minor 0, status 0
panfrost0: Features: L2 7120206, Shader 0, Tiler 809, Mem 1, MMU 2830, AS ff, JS 7
panfrost0: GPU is powered on
<6>[drm] Initialized panfrost 1.1.0 20201124 for panfrost on minor 1
Autoloading module: dwwdt
Autoloading module: mx25l
Autoloading module: pwm_backlight
dwwdt0:  mem 0xff848000-0xff8480ff irq 47 on ofwbus0
pwm_backlight0:  on ofwbus0
mx25l0:  at cs 0 mode 0 on spibus0
mx25l0: device type gd25q128, size 16384K in 256 sectors of 64K, erase size 4K
Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/R/lib /usr/local/lib/compat/pkg /usr/local/lib/gcc10 /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/perl5/5.34/mach/CORE /usr/local/lib/qt5 /usr/local/llvm13/lib
Setting hostname: kazu.tfc.
lo0: link state changed to UP
ue0: link state changed to DOWN
Starting Network: lo0 ue0.
lo0: flags=8049 metric 0 mtu 16384
        options=680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
        options=68009b
        ether a0:ce:c8:de:9c:95
        inet 192.168.1.65 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (none)
        status: no carrier
        nd6 options=29
Starting devd.
ue0: link state changed to UP
Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.
Starting ums0 moused.
Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.
Cannot 'start' webcamd. Set webcamd_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add net default: gateway 192.168.1.254
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Mounting NFS filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/R/lib /usr/local/lib/compat/pkg /usr/local/lib/gcc10 /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/lib/perl5/5.34/mach/CORE /usr/local/lib/qt5 /usr/local/llvm13/lib
Updating motd:.
Updating /var/run/os-release done.
Creating and/or trimming log files.
Clearing /tmp (X related).
Starting syslogd.
No core dumps found.
Security policy loaded: MAC/ntpd (mac_ntpd)
Starting ntpd.
Mounting late filesystems:.
/etc/rc: WARNING: /etc/bluetooth/bthidd.conf is not readable.
/etc/rc: WARNING: failed precmd routine for bthidd
Starting sendmail.
Starting sendmail_msp_queue.
Starting cron.
Performing sanity check on sshd configuration.
Starting sshd.
Configuring vt: blanktime screensaverkldload: can't load logo_saver: No such file or directory
/etc/rc: WARNING: Unable to load kernel module logo_saver
.
Starting background file system checks in 60 seconds.

Mon Feb 21 07:11:06 JST 2022

FreeBSD/arm64 (kazu.tfc) (ttyu1)

login: 


But I could not found panfrot X driver. Is there any panfrost
X driver for FreeBSD ?

My machine environments are as follows :

Ports branch is 47d8fb3af3f0 and others are :

admin@kazu:~ % uname -a
FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022     root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM  arm64
admin@kazu:~ % df -h
Filesystem                                                                         Size    Used   Avail Capacity  Mounted on
/dev/mmcsd0p3                                                                       82G     15G     61G    19%    /
devfs                                                                              1.0K    1.0K      0B   100%    /dev
tmpfs                                                                               34G    4.0K     34G     0%    /tmp
linprocfs                                                                          4.0K    4.0K      0B   100%    /compat/linux/proc
tmpfs                                                                               34G    4.0K     34G     0%    /compat/linux/dev/shm
linsysfs                                                                           4.0K    4.0K      0B   100%    /compat/linux/sys
devfs                                                                              1.0K    1.0K      0B   100%    /compat/linux/dev
fdescfs                                                                            1.0K    1.0K      0B   100%    /compat/linux/dev/fd
192.168.1.17:/.dake                                                                 12T    973G     11T     8%    /.dake
192.168.1.17:/ds/src/freebsd/current/14.0/3f106af0cd92.generic_drm                  11T     81G     11T     1%    /usr/src
192.168.1.17:/ds/obj/freebsd/current/14.0/3f106af0cd92.generic_drm                  11T    442G     11T     4%    /usr/obj
192.168.1.17:/ds/ports/freebsd/47d8fb3af3f0                                         11T    111G     11T     1%    /usr/ports
192.168.1.17:/ds/distfiles                                                          11T     54G     11T     0%    /var/ports/distfiles
192.168.1.17:/ds/packages/freebsd/arm64/aarch64/14.0C/3f106af0cd92/47d8fb3af3f0     11T    117G     11T     1%    /var/ports/packages
admin@kazu:~ % uname -a
FreeBSD kazu.tfc 14.0-CURRENT FreeBSD 14.0-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022     root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM  arm64
admin@kazu:~ % df -h
Filesystem                                                                         Size    Used   Avail Capacity  Mounted on
/dev/mmcsd0p3                                                                       82G     15G     61G    19%    /
devfs                                                                              1.0K    1.0K      0B   100%    /dev
tmpfs                                                                               34G    4.0K     34G     0%    /tmp
linprocfs                                                                          4.0K    4.0K      0B   100%    /compat/linux/proc
tmpfs                                                                               34G    4.0K     34G     0%    /compat/linux/dev/shm
linsysfs                                                                           4.0K    4.0K      0B   100%    /compat/linux/sys
devfs                                                                              1.0K    1.0K      0B   100%    /compat/linux/dev
fdescfs                                                                            1.0K    1.0K      0B   100%    /compat/linux/dev/fd
192.168.1.17:/.dake                                                                 12T    973G     11T     8%    /.dake
192.168.1.17:/ds/src/freebsd/current/14.0/3f106af0cd92.generic_drm                  11T     81G     11T     1%    /usr/src
192.168.1.17:/ds/obj/freebsd/current/14.0/3f106af0cd92.generic_drm                  11T    442G     11T     4%    /usr/obj
192.168.1.17:/ds/ports/freebsd/47d8fb3af3f0                                         11T    111G     11T     1%    /usr/ports
192.168.1.17:/ds/distfiles                                                          11T     54G     11T     0%    /var/ports/distfiles
192.168.1.17:/ds/packages/freebsd/arm64/aarch64/14.0C/3f106af0cd92/47d8fb3af3f0     11T    117G     11T     1%    /var/ports/packages
admin@kazu:~ % cat /etc/make.conf
PORTSDIR=               /var/ports/lpbpkx
INDEXDIR=               /var/ports/lpbpkx
WRKDIRPREFIX=           /var/ports/work
PACKAGES=               /var/ports/packages
DISTDIR=                /var/ports/distfiles
BATCH=                  yes
DEFAULT_VERSIONS=       perl5=5.34 ruby=2.7 java=12
COMPILER_TYPE=          clang
USE_PACKAGE_DEPENDS=    yes
DISABLE_VULNERABILITIES=yes
admin@kazu:~ % 

GENERIC-DRM kernel was built by `git subtree add' to 14.0-CURRENT
(e35816c1c909) for Panfrost driver [1] :

First `git subtree add' to 14.0-CURRENT (e35816c1c909) in src server :

root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git checkout e35816c1c909
HEAD is now at e35816c1c909 aw_spi: improve I/O stability
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git remote add drm-subtree https://github.com/jsm222/drm-subtree.git
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git subtree add --prefix sys/dev/drm/ drm-subtree pinebookpro-test
git fetch drm-subtree pinebookpro-test
remote: Enumerating objects: 794, done.
remote: Counting objects: 100% (794/794), done.
remote: Compressing objects: 100% (518/518), done.
remote: Total 794 (delta 370), reused 685 (delta 264), pack-reused 0
Receiving objects: 100% (794/794), 1.14 MiB | 5.09 MiB/s, done.
Resolving deltas: 100% (370/370), done.
 From https://github.com/jsm222/drm-subtree
  * branch                      pinebookpro-test -> FETCH_HEAD
  * [new branch]                pinebookpro-test -> drm-subtree/pinebookpro-test
Added dir 'sys/dev/drm'
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0001-Hook-DRM-to-the-build.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0002-Add-GENERIC-DRM-for-armv7.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/extra_patches/0003-drm-Add-rockchip-and-bridges-into-GENERIC-DRM.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/gicv3_its.c-patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mixer.c.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_dev_iicbus_es8316.c
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/GENERIC-DRM.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/sys_modules_dtb_rockchip_Makefile.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git apply sys/dev/drm/pbp-kernel-extra-patches/mmc.c.patch
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # git rev-parse --verify --short HEAD
3f106af0cd92
root@vm:/ds/src/freebsd/current/14.0/e35816c1c909.generic_drm # cd ..
root@vm:/ds/src/freebsd/current/14.0 # mv e35816c1c909.generic_drm 3f106af0cd92.generic_drm

and then build GENERIC-DRM in PBP :
  
# cd /usr/src
# make buildworld TARGET=arm64
# make buildkernel TARGET=arm64 KERNCONF=GENERIC-DRM

Best regards

[1] https://github.com/jsm222/drm-subtree
---
Kazuhiko Kiriyama 


From nobody Mon Feb 21 00:06:49 2022
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 56CFC19C4A62;
	Mon, 21 Feb 2022 00:07:04 +0000 (UTC)
	(envelope-from greg@unrelenting.technology)
Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K22fZ69rBz4XDT;
	Mon, 21 Feb 2022 00:07:02 +0000 (UTC)
	(envelope-from greg@unrelenting.technology)
Date: Mon, 21 Feb 2022 03:06:49 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology;
	s=key1; t=1645402014;
	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=tt96medKwwfigditkzTmEHrqqcJLu6DgaLWuO8NkSeg=;
	b=MvATljmjxbCjfgCtaC0gu4WswLC2JvmWcsl4wOcHVkIW6/cxi5Uz/RZqoThvyDR1XJh3jM
	BNvHX36uJy5DGY8a8QgTz15oU6JSAlq+wyZuXR7th15m7UfApxGpG5hZ2a19AmT/GeaapT
	9N7EdJ561kUplbCytbicW438gkIXfW6HmlrW0V53Bx/EYPs+dyy/6cMYw0n9/gWEroyERY
	ImF3ULuQhWsB7CcRz8wXfB7gvPDSaNT/lAjppJTq1B4wphcljttwbrMOZvvXmvSLMXoCJ/
	M43HaJzdNECJqxdn8Hv9oiOTNO4A0oAlEkJAdze9gDKhZazt4gMRYFLFizohgw==
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Greg V 
To: KIRIYAMA Kazuhiko , x11@freebsd.org
CC: freebsd-arm@freebsd.org
Subject: Re: Is there any X driver for Panfrost on PBP ?
In-Reply-To: <202202202226.21KMQQxG082376@kx.truefc.org>
References: <202202202226.21KMQQxG082376@kx.truefc.org>
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=utf-8
Content-Transfer-Encoding: quoted-printable
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: unrelenting.technology
X-Rspamd-Queue-Id: 4K22fZ69rBz4XDT
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=unrelenting.technology header.s=key1 header.b=MvATljmj;
	dmarc=pass (policy=quarantine) header.from=unrelenting.technology;
	spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:aacc:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology
X-Spamd-Result: default: False [-2.79 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.76)[-0.756];
	 R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=key1];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:aacc::];
	 FROM_HAS_DN(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[unrelenting.technology:+];
	 DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,quarantine];
	 NEURAL_HAM_SHORT(-0.94)[-0.937];
	 MLMMJ_DEST(0.00)[freebsd-arm,x11];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[2001:41d0:2:aacc:::from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 661
Lines: 26



On February 21, 2022 1:26:26 AM GMT+03:00, KIRIYAMA Kazuhiko  wrote:
>Hi, lists

Hi,

[=2E=2E]

>rk_drm0: Cannot find port with phandle 10

(hopefully this one is harmless=2E=2E)

>But I could not found panfrot X driver=2E Is there any panfrost
>X driver for FreeBSD ?

Please forget about the notion of hardware specific X drivers and just run=
 startx=2E

There is *one* relevant X video driver =E2=80=93 xf86-video-modesetting =
=E2=80=93 and it is built in=2E

(Ok, -amdgpu is somewhat relevant but that's just -modesetting with TearFr=
ee hacks=2E Meanwhile -intel is a terrible pile of abandonware that mostly =
causes problems=2E)

From nobody Mon Feb 21 08:00:44 2022
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 E82A319C804E
	for ; Mon, 21 Feb 2022 08:01:28 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K2F9y26hKz3pP5
	for ; Mon, 21 Feb 2022 08:01:25 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21L80tXI080161
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 21 Feb 2022 18:31:09 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1645430473;
	bh=VYwW+rrfu8G6D2xQZTg+8+R5KH21N57cnq/UiS0nEXo=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=AjNNpsGvOEdExAOAq8cNZigRmBeULtPmgCm06u89VCyxIoGH8T0j1AbUjPQLiXh/k
	 +wrcHTNYIqhUTNx8RxsrhgBxjaanmA7GFILIQQvb4H2LKeaCa1yUu112b+d1TThTJK
	 rYaI85BEAqg9HhzS8wxlSeKGe/he74G81N2FShII=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21L80ivG080155
	for ; Mon, 21 Feb 2022 18:30:44 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:9ff:9026:de6b:58bc
Received: from smtpclient.apple (2403-5800-5200-4700-9ff-9026-de6b-58bc.ip6.aussiebb.net [2403:5800:5200:4700:9ff:9026:de6b:58bc])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21L80ice080150; Mon, 21 Feb 2022 18:30:44 +1030
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 15.0 \(3693.40.0.1.81\))
Subject: Re: DS3231 RTC module not detected
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Mon, 21 Feb 2022 18:30:44 +1030
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au>
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-Spam-Score: 0.6 () No, score=0.6 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1
X-Rspamd-Queue-Id: 4K2F9y26hKz3pP5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=AjNNpsGv;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-3.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[dons.net.au:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1095
Lines: 27



> On 20 Feb 2022, at 14:59, Archimedes Gaviola =
 wrote:
>> When you say "with the exact DS3231 driver.." what do you mean?
>=20
> I mean the appropriate DS3231 driver - ds3231(4) for the module which =
is a kernel loadable as the dominating driver with 13.0-RELEASE and =
14.0-CURRENT which is MAX77620 RTC is the wrong one thus the module will =
not work properly. The clock stops and goes back to the time when you =
set it. This behavior is observable when my RPi system is rebooted or =
shutdown. With the loadable  ds3231 driver, this behavior is no longer =
observed and working as expected. For your DS1307, there's also an =
equivalent and perhaps the appropriate driver as described in the manual =
ds1307(4), it can be loaded as well via kldload.

I tried loading ds1307.ko in the loader but it has no effect on the =
result - still shows up as a MAX77620 for me.

I haven't tested pulling the power yet as I'm remote from it.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


From nobody Mon Feb 21 11:20:40 2022
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 7216E19CFAA4
	for ; Mon, 21 Feb 2022 11:20:53 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533])
	(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 4K2Kc455dbz4q0P
	for ; Mon, 21 Feb 2022 11:20:52 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x533.google.com with SMTP id h15so11646577edv.7
        for ; Mon, 21 Feb 2022 03:20:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=AMUsWczkQeHVwE0N9JOid2UWWIQ3WkiNyGdAYrnetTg=;
        b=e9hB01NfiZnt16ztymmhEB7MIXV6xlO7kV8iGyfKr8oTILPu+xsOiCT7kgmiJ2tY92
         /xE/LDLKE0zuSi/ezbS3gYEHan4ygtgyDJe5ppyFo3QNIdJoGiMygpJUbwLEjhDcHCIM
         +rCXKYmE8mxRxflfMdMkUsvml1SjwAgY41C+8FZOOMk8MbQ84Ox6mW82fkziF4e70seZ
         OmTTLAHe18JcItdEKjq2T4fD/mWT+P2/uOZYfVO+83bx52YvmW151qcHPXXcdTzg56aU
         YVFoCSVOsmJLVbkAP6OBNJbg5vbpwBvWcCLEUR6BgdMVeX+oTCxrw3DoHKsy/K0PgWyk
         JkxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=AMUsWczkQeHVwE0N9JOid2UWWIQ3WkiNyGdAYrnetTg=;
        b=dhkVD3ZWmj+mlnPRBmG6KMSCS2A+SXRkLeblCFVjLN6q1YZVXqYfvYH5BgF0H2FoS1
         UCsS/Ijn5X0tcB3bUuPSDBcPXoxckAYVh7U4Qr/BYJRkI+CWhC9WImLLPoiNpL3a+tNb
         dQGQpx/ErV+ENfNnMUx7mHDVqxCCEAekjMLoUZZ99yU6ARdYFoNL5MCGKqwDvjH/jGdp
         G0Ks/Avhzb0esqpf0NnGyGgnBVB38ymiQJQ2oZ24KPgm+VAj9LdA4zwiAsjKgNsmbTaL
         yrTuEbdXCtyZUqWP3Gf7xUnRJ6H68NzPNYV/imYTuwyyquooNjvCj9+SMr88DGUwT6Ep
         K+PA==
X-Gm-Message-State: AOAM532Ou1VodpmAoCtWlRO4hn52PBSf1CCGp4f4+YNovwccMbDEbQj2
	263iU7yGWSHcwQBb5pcNd7MDAFSIpFd3IewKJLHb0GH2Be9tBQ==
X-Google-Smtp-Source: ABdhPJzHgDoCJ5ehbEEtbi39D+Q9qs+IEGuQHyyP57xnIkvqToUjai40Vn9ZD0yZZCFkl5J8VLc5x5aK5ceLwfUMvmA=
X-Received: by 2002:a05:6402:d0d:b0:412:d49c:74d3 with SMTP id
 eb13-20020a0564020d0d00b00412d49c74d3mr12370986edb.207.1645442451633; Mon, 21
 Feb 2022 03:20:51 -0800 (PST)
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: 
  
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au> 
 <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au>
In-Reply-To: <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au>
From: Archimedes Gaviola 
Date: Mon, 21 Feb 2022 19:20:40 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d3f8f805d8856c02"
X-Rspamd-Queue-Id: 4K2Kc455dbz4q0P
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=e9hB01Nf;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.84 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.84)[-0.844];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5533
Lines: 110

--000000000000d3f8f805d8856c02
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 21, 2022 at 4:01 PM Daniel O'Connor  wrote:

>
>
> > On 20 Feb 2022, at 14:59, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >> When you say "with the exact DS3231 driver.." what do you mean?
> >
> > I mean the appropriate DS3231 driver - ds3231(4) for the module which is
> a kernel loadable as the dominating driver with 13.0-RELEASE and
> 14.0-CURRENT which is MAX77620 RTC is the wrong one thus the module will
> not work properly. The clock stops and goes back to the time when you set
> it. This behavior is observable when my RPi system is rebooted or shutdown.
> With the loadable  ds3231 driver, this behavior is no longer observed and
> working as expected. For your DS1307, there's also an equivalent and
> perhaps the appropriate driver as described in the manual ds1307(4), it can
> be loaded as well via kldload.
>
> I tried loading ds1307.ko in the loader but it has no effect on the result
> - still shows up as a MAX77620 for me.
>
> I haven't tested pulling the power yet as I'm remote from it.
>

Did you re-compile your kernel? Brian has shared his resolution on
customizing the GENERIC kernel here
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html
which allows to free-up the i2c address 0x68 which by default is being used
by the MAX77620 RTC driver from the SOC_NVIDIA_TEGRA210. So, you need to
add these lines in your kernel (I assume it's still the GENERIC otherwise
use your existing config),

include         GENERIC
ident             GENERIC-PI
nooptions     SOC_NVIDIA_TEGRA210

and then recompile. Keep your /boot/msdos/config.txt and
/boot/msdos/overlays/ds1307.dtbo files intact. After recompiling and
rebooting, you can check the dmesg if the ds1307 driver is loaded,
otherwise invoke "kldload ds1307" and see if it's detected. Add a line into
your /boot/loader.conf with ds1307_enable="YES" if necessary. Lastly,
kindly backup your data before recompiling for safety.

This is the way I do it with my ds3231 driver, hope you will get the same
result.

Thanks,
Archimedes

--000000000000d3f8f805d8856c02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 21, 2022 at 4:01 PM Danie=
l O'Connor <=
darius@dons.net.au> wrote:




> On 20 Feb 2022, at 14:59, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

>> When you say "with the exact DS3231 driver.." what do yo=
u mean?

> 

> I mean the appropriate DS3231 driver - ds3231(4) for the module which =
is a kernel loadable as the dominating driver with 13.0-RELEASE and 14.0-CU=
RRENT which is MAX77620 RTC is the wrong one thus the module will not work =
properly. The clock stops and goes back to the time when you set it. This b=
ehavior is observable when my RPi system is rebooted or shutdown. With the =
loadable=C2=A0 ds3231 driver, this behavior is no longer observed and worki=
ng as expected. For your DS1307, there's also an equivalent and perhaps=
 the appropriate driver as described in the manual ds1307(4), it can be loa=
ded as well via kldload.



I tried loading ds1307.ko in the loader but it has no effect on the result =
- still shows up as a MAX77620 for me.



I haven't tested pulling the power yet as I'm remote from it.

Did you re-compile your kernel? Brian has shared =
his resolution on customizing the GENERIC kernel here https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.=
html which allows to free-up the i2c address 0x68 which by default is b=
eing used by the=20
MAX77620 RTC

driver from the SOC_NVIDIA_TEGRA210. So, you need to add these lines in you=
r kernel (I assume it's still the GENERIC otherwise use your existing c=
onfig),

include =C2=A0 =C2=A0 =C2=A0 =C2=A0 GENERIC
ident =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0=C2=A0=C2=A0 GENERIC-PI
nooptions =C2=A0 =C2=A0 SOC_NVIDIA=
_TEGRA210

and then recompile. Keep your /boot/msdos/config.txt and=20
/boot/msdos/overlays/ds1307.dtbo files intact. After recompiling and reboot=
ing, you can check the dmesg if the ds1307 driver is loaded, otherwise invo=
ke "kldload ds1307" and see if it's detected. Add a line into=
 your /boot/loader.conf with ds1307_enable=3D"YES" if necessary. =
Lastly, kindly backup your data before recompiling for safety.

This is the wa=
y I do it with my ds3231 driver, hope you will get the same result.

Thanks,
=

Archimedes 
=

=C2=A0 


--000000000000d3f8f805d8856c02--

From nobody Mon Feb 21 11:26:47 2022
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 9711319D09E3
	for ; Mon, 21 Feb 2022 11:27:00 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e])
	(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 4K2Kl775Knz4qpV;
	Mon, 21 Feb 2022 11:26:59 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52e.google.com with SMTP id x5so28582259edd.11;
        Mon, 21 Feb 2022 03:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=q2yQi0BoHS4Bpt0F+AWZt3PUHMnMg4afuh2LtQPUQss=;
        b=MmCizTgei2wwZMcxij4TUDX2+6m4oUtc+84l7ra5mlhpPnbRNEtlZ9+8ZG5bBt6GZM
         z1coAWjIGAH3PhhGY+xDCh80QcXWW6hO1nm1yd1svBA99yZPyhVo4OmewQRejoWIoOmf
         Z7KQV29ZooDtKKTUoop/bYait0JGnD+lH/K2NyV7DZAHtmpQzP8gTNj1bbi5BUq/fOm1
         20fRoRM+tQOYZaX1HBnkbQUVu50tlPfizSIEbA8NIb76KTLsEBJ7ILvWhW9u3gX+U8eK
         DgEgzX9U7UWvfFJ2WhQ3X7HcVc5wYlS4ZEEZfAaSqAeImdgA2VwSgmaJXWqjk2XDD2FY
         pt4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=q2yQi0BoHS4Bpt0F+AWZt3PUHMnMg4afuh2LtQPUQss=;
        b=ih+pOawvZ2kF0a8Nf0jRO/Ld+RAmq8fJhXHt0u1RFkiuXdRXF+Gefx8pxJo2IcRgu6
         YUm5YmOIY4z3ao1ZWLwhU2DZlkcb9xni0uDzHW5VHuT34IXdihRnbg5nybtmG+jThtuL
         x9nuVNf4rSBOL74if5kTOk8CJojV9BgIG+obKAPyFJW6CnPp5GBFCrAIaU83RbLlfgyN
         u5tBdBYwPeJIsKraHAvuAqF86hUQ50O0QbPOHWvCURuyUU7biXL3LiPeKs90Ls6MD0Fm
         dLpK5Hmyf2Y4TxOoBuVbKJpq2rrVSkREeI2qIsvx+R++Xi6gtIFKL2ddjeN/YEPced7v
         T9cQ==
X-Gm-Message-State: AOAM530/YsZnYqpYkkZwXJ/TwpaxXFv0nZynlJvjzTVSyKb84cGyUN3M
	d5Y5PWlCFNHgK6OQsAZpSm6C4PI07OmpgUrisgYSvCiQobY=
X-Google-Smtp-Source: ABdhPJyb9qBfzq1L6Cq1B1xCbGfZZkb7KvaDllhFk0P3M0it310q87trzJwHIn++g8QR7PqROl1sGve/0RFeVu7ZW+c=
X-Received: by 2002:a05:6402:2686:b0:412:d1cb:a6d8 with SMTP id
 w6-20020a056402268600b00412d1cba6d8mr13501223edd.280.1645442818722; Mon, 21
 Feb 2022 03:26:58 -0800 (PST)
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: 
  
 <1015913d-ea06-2524-e988-f8a4a04366f9@FreeBSD.org>
In-Reply-To: <1015913d-ea06-2524-e988-f8a4a04366f9@FreeBSD.org>
From: Archimedes Gaviola 
Date: Mon, 21 Feb 2022 19:26:47 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: Andriy Gapon 
Cc: "Daniel O'Connor" , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000b54d8705d8858266"
X-Rspamd-Queue-Id: 4K2Kl775Knz4qpV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MmCizTge;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1585
Lines: 37

--000000000000b54d8705d8858266
Content-Type: text/plain; charset="UTF-8"

On Sun, Feb 20, 2022 at 6:30 PM Andriy Gapon  wrote:

> On 18/02/2022 16:22, Archimedes Gaviola wrote:
> > The result is it is detected as MAX77620 RTC on 0xd0 address but when I
> run an
> > i2c scan, the address detected is 68. Does this should match?
>
> 0xd0 and 0x68 are different representations of the same I2C address.
> If you write it out in binary (base of two), you will see.
>

Thanks Andriy for your input, now I know.

--000000000000b54d8705d8858266
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Feb 20, 2022 at 6:30 PM Andri=
y Gapon <avg@freebsd.org> wrot=
e:
On 18/02/2022=
 16:22, Archimedes Gaviola wrote:

> The result is it is detected as MAX77620 RTC on 0xd0 address but when =
I run an 

> i2c scan, the address detected is 68. Does this should match?



0xd0 and 0x68 are different representations of the same I2C address.

If you write it out in binary (base of two), you will see.
=


Thank=
s Andriy for your input, now I know.


--000000000000b54d8705d8858266--

From nobody Mon Feb 21 11:28:45 2022
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 B4FB119D1850
	for ; Mon, 21 Feb 2022 11:29:10 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K2Knc4f6dz4rBj
	for ; Mon, 21 Feb 2022 11:29:08 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21LBSu0g028537
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 21 Feb 2022 21:58:56 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1645442940;
	bh=d6OaIhjVVOJroBJqnhZV+pnLqWFKPCe8aa8RRC4a79w=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=IxRQDsYErV0hYJ+13NBZzQf7au4csRgFiDxI9Ttyck5BLphny4H8UJ7hc055NrlsX
	 58Pd+TKltaTAVjcIchNVZ5T/7XqqWe23fed9dMl2JqJtBQMvnM0BXN0jc5I1+U102h
	 U5gDj1aK/EH6MuerZpw+RSnvaTpcBhtS/RezVpfE=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21LBSkoF028527
	for ; Mon, 21 Feb 2022 21:58:46 +1030 (ACDT)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:9ff:9026:de6b:58bc
Received: from smtpclient.apple (2403-5800-5200-4700-9ff-9026-de6b-58bc.ip6.aussiebb.net [2403:5800:5200:4700:9ff:9026:de6b:58bc])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21LBSkHZ028522; Mon, 21 Feb 2022 21:58:46 +1030
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 15.0 \(3693.40.0.1.81\))
Subject: Re: DS3231 RTC module not detected
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Mon, 21 Feb 2022 21:58:45 +1030
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C023EE9-E5E9-4C2B-B715-97317B6370A7@dons.net.au>
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
 
 <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au>
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-Spam-Score: 0.6 () No, score=0.6 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1
X-Rspamd-Queue-Id: 4K2Knc4f6dz4rBj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=IxRQDsYE;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-3.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[dons.net.au:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1667
Lines: 50



> On 21 Feb 2022, at 21:50, Archimedes Gaviola =
 wrote:
> Did you re-compile your kernel? Brian has shared his resolution on =
customizing the GENERIC kernel here=20

No I didn't realise it was necessary :)

> =
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html =
which allows to free-up the i2c address 0x68 which by default is being =
used by the MAX77620 RTC driver from the SOC_NVIDIA_TEGRA210. So, you =
need to add these lines in your kernel (I assume it's still the GENERIC =
otherwise use your existing config),
>=20
> include         GENERIC
> ident             GENERIC-PI
> nooptions     SOC_NVIDIA_TEGRA210
>=20
> and then recompile. Keep your /boot/msdos/config.txt and =
/boot/msdos/overlays/ds1307.dtbo files intact. After recompiling and =
rebooting, you can check the dmesg if the ds1307 driver is loaded, =
otherwise invoke "kldload ds1307" and see if it's detected. Add a line =
into your /boot/loader.conf with ds1307_enable=3D"YES" if necessary. =
Lastly, kindly backup your data before recompiling for safety.
>=20
> This is the way I do it with my ds3231 driver, hope you will get the =
same result.

Thanks.

I chatted to some people on IRC and I think it's fixed in a later =
version anyway with these commits:
=
https://cgit.freebsd.org/src/commit/?id=3D1bd3e8ba696633ccd7525030d951b58a=
de167814
=
https://cgit.freebsd.org/src/commit/?id=3Da534b50e245d801af887d91b5d48ebcf=
120aa039

Although I have not been brave enough to update to HEAD and try it yet =
:)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


From nobody Mon Feb 21 11:46:41 2022
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 37EF219D6267
	for ; Mon, 21 Feb 2022 11:46:54 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.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 4K2LB533dfz3C6c
	for ; Mon, 21 Feb 2022 11:46:53 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x529.google.com with SMTP id s14so11402791edw.0
        for ; Mon, 21 Feb 2022 03:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=mJ4tACieHCPUmPLhv61IyWGuQYA1EUNsYN1av+fLguQ=;
        b=FJg2dFIXAv7ImxcG7lHX5uDGRsDwwtDFR1uxCUoHsTqLr1wMrQK6q+EvVeqXM19pod
         UXmi/+LsuWPSGf1lGaS0s6W87u1aYfng9QWPeaLAMTBCbA9IlTfCAVrscTHfbvf8kuZR
         hFaESjTxAQPVEXHk94r971FLFxy04SzO7Xnp+2k51U+AW2IQgWnW36SMuOctUd836uaM
         sAQy0ktZr4GudoSQ8KR03dfNrs8aabTa4DzcCsb6zSuKBn03WH+P+Lk3VrpQJUc/w+Wm
         0WggS+2ijaRJpIqCdODUir3w84k2QLPEuoaASqFQBM3kKlweck6WURA53SNiAU9cxBiI
         4UAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=mJ4tACieHCPUmPLhv61IyWGuQYA1EUNsYN1av+fLguQ=;
        b=WCqdgfK3LwgWH0d71RtXO2bWZG4o/4u7NqsfrKnVAiRofO9nH5ZetxWOHIL48EsC2D
         hhK4Zb5mtCAaNQr4mGddm/HhU3bPPRhi9JwJcvaZWBgT2VRMVQMc3Le+RsOe4MfuB1bU
         zEf6jWWh7swbQwi+E17ykZc4h/uHZpnOhLPe7SUhG7HRB3LFKUm4IIFKurgBgCTc+cjL
         q0xDeMDYbAtYFYkzCUx+O6AfFbKlYbD01jGaQp+sdNU3HjnRqNmAaKqz5RYzuj7KJLcC
         ya9PUkbH4BwX6RPqwm46IMoZSLu8H7IO/AwAgcK9g/1c139y5bmnFVQ9c12YFat61tE/
         BEkw==
X-Gm-Message-State: AOAM5302INhM/qx32cxVEU/o1imHOXaebTFK0pAqccoyfVKPk3IxJb9d
	FoSbjkPeYQB4B8dBHfFrwepa+W18pv3PCJF//HHQyXBg/Y0=
X-Google-Smtp-Source: ABdhPJyzLXzB35qEJUmesJOJ7xs7nzYRt+oc+81wcBZq+UYibUSHkCMXmMEawKQAyj+wpk7FkHhl0VC/U2n1Ew8b7tg=
X-Received: by 2002:a50:9ea2:0:b0:409:5438:debf with SMTP id
 a31-20020a509ea2000000b004095438debfmr20862975edf.126.1645444012383; Mon, 21
 Feb 2022 03:46:52 -0800 (PST)
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: 
  
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au> 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au> 
 <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au> 
 <6C023EE9-E5E9-4C2B-B715-97317B6370A7@dons.net.au>
In-Reply-To: <6C023EE9-E5E9-4C2B-B715-97317B6370A7@dons.net.au>
From: Archimedes Gaviola 
Date: Mon, 21 Feb 2022 19:46:41 +0800
Message-ID: 
Subject: Re: DS3231 RTC module not detected
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000db229305d885c9fd"
X-Rspamd-Queue-Id: 4K2LB533dfz3C6c
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=FJg2dFIX;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.993];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5449
Lines: 129

--000000000000db229305d885c9fd
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 21, 2022 at 7:29 PM Daniel O'Connor  wrote:

>
>
> > On 21 Feb 2022, at 21:50, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> > Did you re-compile your kernel? Brian has shared his resolution on
> customizing the GENERIC kernel here
>
> No I didn't realise it was necessary :)
>

Yes it is :-)


>
> > https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html
> which allows to free-up the i2c address 0x68 which by default is being used
> by the MAX77620 RTC driver from the SOC_NVIDIA_TEGRA210. So, you need to
> add these lines in your kernel (I assume it's still the GENERIC otherwise
> use your existing config),
> >
> > include         GENERIC
> > ident             GENERIC-PI
> > nooptions     SOC_NVIDIA_TEGRA210
> >
> > and then recompile. Keep your /boot/msdos/config.txt and
> /boot/msdos/overlays/ds1307.dtbo files intact. After recompiling and
> rebooting, you can check the dmesg if the ds1307 driver is loaded,
> otherwise invoke "kldload ds1307" and see if it's detected. Add a line into
> your /boot/loader.conf with ds1307_enable="YES" if necessary. Lastly,
> kindly backup your data before recompiling for safety.
> >
> > This is the way I do it with my ds3231 driver, hope you will get the
> same result.
>
> Thanks.
>


You're welcome.


>
> I chatted to some people on IRC and I think it's fixed in a later version
> anyway with these commits:
>
> https://cgit.freebsd.org/src/commit/?id=1bd3e8ba696633ccd7525030d951b58ade167814
>
> https://cgit.freebsd.org/src/commit/?id=a534b50e245d801af887d91b5d48ebcf120aa039
>
>
Wow, this is good news...


> Although I have not been brave enough to update to HEAD and try it yet :)
>

Yeah, better to wait than meet a lot of surprises with HEAD :-)

--000000000000db229305d885c9fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 21, 2022 at 7:29 PM Danie=
l O'Connor <darius@dons.net.au=
> wrote:
=




> On 21 Feb 2022, at 21:50, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> Did you re-compile your kernel? Brian has shared his resolution on cus=
tomizing the GENERIC kernel here 



No I didn't realise it was necessary :)

=

Yes it is :-)
=C2=A0



> https://lists.freebsd.o=
rg/archives/freebsd-arm/2022-February/001024.html which allows to free-=
up the i2c address 0x68 which by default is being used by the MAX77620 RTC =
driver from the SOC_NVIDIA_TEGRA210. So, you need to add these lines in you=
r kernel (I assume it's still the GENERIC otherwise use your existing c=
onfig),

> 

> include=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GENERIC

> ident=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GENERIC-PI

> nooptions=C2=A0 =C2=A0 =C2=A0SOC_NVIDIA_TEGRA210

> 

> and then recompile. Keep your /boot/msdos/config.txt and /boot/msdos/o=
verlays/ds1307.dtbo files intact. After recompiling and rebooting, you can =
check the dmesg if the ds1307 driver is loaded, otherwise invoke "kldl=
oad ds1307" and see if it's detected. Add a line into your /boot/l=
oader.conf with ds1307_enable=3D"YES" if necessary. Lastly, kindl=
y backup your data before recompiling for safety.

> 

> This is the way I do it with my ds3231 driver, hope you will get the s=
ame result.



Thanks.


You're welco=
me.
=C2=A0



I chatted to some people on IRC and I think it's fixed in a later versi=
on anyway with these commits:

https://cgit.freeb=
sd.org/src/commit/?id=3D1bd3e8ba696633ccd7525030d951b58ade167814

https://cgit.freeb=
sd.org/src/commit/?id=3Da534b50e245d801af887d91b5d48ebcf120aa039



Wow, this is good news...
=C2=A0

Although I have not been brave enough to update to HEAD and try it yet :)

Yeah, better to wait than meet a lot of surprises with HEAD :-)


--000000000000db229305d885c9fd--

From nobody Mon Feb 21 12:03:42 2022
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 3845719D8B87
	for ; Mon, 21 Feb 2022 12:04:09 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmse03.mailcluster.com.au (vmse03.mailcluster.com.au [IPv6:2401:fc00:0:14::11])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K2LYy4tTGz3D4r
	for ; Mon, 21 Feb 2022 12:04:06 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmcp43.digitalpacific.com.au ([101.0.119.58])
	by vmse03.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128)
	(Exim 4.92)
	(envelope-from )
	id 1nM7Ps-0007Pd-Ac
	for freebsd-arm@freebsd.org; Mon, 21 Feb 2022 23:03:54 +1100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=bunyatech.com.au; s=default; h=In-Reply-To:From:References:To:Subject:
	MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To:Cc:
	Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
	List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=UV4bOkIJqwpeKEFaH1t8+Uu8CRN52FTlpsLqTDlBwEs=; b=p3V7f2hwri3BF9ro2mS1EXRisM
	OEp1fn0iB087trSTjy5N+LkOnPvP1Pf2H9EpKtjBp1ODAQW1BsmRx51bF+2XcB1+z4YQOK4EHlh4b
	KDdD8b/pGxLFczm0MW7m3Ppj3+sb3hleeO1kU2BuQcF8mUm1cagcaNqRy+hfUe8fq17gPD4I/F5u1
	vHsT6DoYrtx5Xh2r5idvnch8KIT62pxes7iE08xht8s3DQ0W7zKOsPcPT46f/8BEfpHH3g6z97OCh
	8rZHmH308G1NrT9Yi8MjVMEuqBtbHwcAbYP7Qq1vjlFw3yu3sazCNyYeBPhH4g8WeZwRFexMsbkkv
	P1aPBdLg==;
Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:58165 helo=[10.0.1.106])
	by vmcp43.digitalpacific.com.au with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from )
	id 1nM7Pq-008Cnl-LB
	for freebsd-arm@freebsd.org; Mon, 21 Feb 2022 23:03:42 +1100
Content-Type: multipart/alternative;
 boundary="------------3qvlW3xoMYqViptcaTO00p0w"
Message-ID: <3c167b34-9f12-edd8-0d28-251c5529e6b0@bunyatech.com.au>
Date: Mon, 21 Feb 2022 23:03:42 +1100
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 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.1
Subject: Re: DS3231 RTC module not detected
To: freebsd-arm@freebsd.org
References: 
 
 
 <2DF482A7-FEFC-4833-A16B-A7A01B8713DD@dons.net.au>
 
 <94C3A304-B821-4885-A50D-32BD1FBED43D@dons.net.au>
 
 <76D58677-D12C-4F0D-A0E0-F28E300FE39B@dons.net.au>
 
 <6C023EE9-E5E9-4C2B-B715-97317B6370A7@dons.net.au>
 
From: Brian Scott 
In-Reply-To: 
X-Authenticated-User: bscott@bunyatech.com.au
X-Authenticator: dovecot_plain
X-Originating-IP: 101.0.119.58
X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au
X-SpamExperts-Username: 101.0.119.58
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+8ci8NJrjD/SYzF5QdzSXDPUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH
 zJ6mVE7ewsipSVIfs4aBifxp35YCgSZOa5n8D4LCABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY
 pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyjwYONoRaT/P0bWwmOx4gR8p8Gnm
 YnDDwZLHsvD3pj+LvuKTBmuOVTCmQ/b22sw+yoj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2
 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4
 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH
 wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U
 ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC64
 m+k59xMAqz9bfz2u3IufXgzJJmjXk7fyp6dRgNba51of9YItJB0MkCkTt8DDH53F4DEPUxAkEvKE
 S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2
 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbvRFCi8MTAlEaJ1q0yvnIG9wT5yMggQ7z8XL83C
 o0hANFz1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r
 Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3
 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO
 g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE=
X-Report-Abuse-To: spam@vmse01.mailcluster.com.au
X-Rspamd-Queue-Id: 4K2LYy4tTGz3D4r
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bunyatech.com.au header.s=default header.b=p3V7f2hw;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:0:14::11 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au
X-Spamd-Result: default: False [-3.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[bunyatech.com.au];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[bunyatech.com.au:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[2401:fc00:0:14::11:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7479
Lines: 197

This is a multi-part message in MIME format.
--------------3qvlW3xoMYqViptcaTO00p0w
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 21/2/22 10:46 pm, Archimedes Gaviola wrote:
>
>
> On Mon, Feb 21, 2022 at 7:29 PM Daniel O'Connor  
> wrote:
>
>
>
>     > On 21 Feb 2022, at 21:50, Archimedes Gaviola
>      wrote:
>     > Did you re-compile your kernel? Brian has shared his resolution
>     on customizing the GENERIC kernel here
>
>     No I didn't realise it was necessary :)
>
>
> Yes it is :-)
>
>
>     >
>     https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html
>     which allows to free-up the i2c address 0x68 which by default is
>     being used by the MAX77620 RTC driver from the
>     SOC_NVIDIA_TEGRA210. So, you need to add these lines in your
>     kernel (I assume it's still the GENERIC otherwise use your
>     existing config),
>     >
>     > include         GENERIC
>     > ident             GENERIC-PI
>     > nooptions     SOC_NVIDIA_TEGRA210
>     >
>     > and then recompile. Keep your /boot/msdos/config.txt and
>     /boot/msdos/overlays/ds1307.dtbo files intact. After recompiling
>     and rebooting, you can check the dmesg if the ds1307 driver is
>     loaded, otherwise invoke "kldload ds1307" and see if it's
>     detected. Add a line into your /boot/loader.conf with
>     ds1307_enable="YES" if necessary. Lastly, kindly backup your data
>     before recompiling for safety.
>     >
>     > This is the way I do it with my ds3231 driver, hope you will get
>     the same result.
>
>     Thanks.
>
>
>
> You're welcome.
>
>
>     I chatted to some people on IRC and I think it's fixed in a later
>     version anyway with these commits:
>     https://cgit.freebsd.org/src/commit/?id=1bd3e8ba696633ccd7525030d951b58ade167814
>     https://cgit.freebsd.org/src/commit/?id=a534b50e245d801af887d91b5d48ebcf120aa039
>
>
> Wow, this is good news...
>
>     Although I have not been brave enough to update to HEAD and try it
>     yet :)
>
>
> Yeah, better to wait than meet a lot of surprises with HEAD :-)

Thanks for the fix. I hope to try it soon.

Brian

--------------3qvlW3xoMYqViptcaTO00p0w
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 21/2/22 10:46 pm, Archimedes Gaviola
      wrote:

    

    

      
      

        


        

        

        

          
On Mon, Feb 21, 2022 at 7:29
            PM Daniel O'Connor <darius@dons.net.au>
            wrote:

          

          


            

            > On 21 Feb 2022, at 21:50, Archimedes Gaviola <archimedes.gaviola@gmail.com>
            wrote:

            > Did you re-compile your kernel? Brian has shared his
            resolution on customizing the GENERIC kernel here 

            

            No I didn't realise it was necessary :)

          

          


          

          
Yes it is :-)

          
 

          

          

            

            > https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html
            which allows to free-up the i2c address 0x68 which by
            default is being used by the MAX77620 RTC driver from the
            SOC_NVIDIA_TEGRA210. So, you need to add these lines in your
            kernel (I assume it's still the GENERIC otherwise use your
            existing config),

            > 

            > include         GENERIC

            > ident             GENERIC-PI

            > nooptions     SOC_NVIDIA_TEGRA210

            > 

            > and then recompile. Keep your /boot/msdos/config.txt
            and /boot/msdos/overlays/ds1307.dtbo files intact. After
            recompiling and rebooting, you can check the dmesg if the
            ds1307 driver is loaded, otherwise invoke "kldload ds1307"
            and see if it's detected. Add a line into your
            /boot/loader.conf with ds1307_enable="YES" if necessary.
            Lastly, kindly backup your data before recompiling for
            safety.

            > 

            > This is the way I do it with my ds3231 driver, hope you
            will get the same result.

            

            Thanks.

          

          


          

          


          

          
You're welcome.

          

          
 

          

            

            I chatted to some people on IRC and I think it's fixed in a
            later version anyway with these commits:

            https://cgit.freebsd.org/src/commit/?id=1bd3e8ba696633ccd7525030d951b58ade167814

            https://cgit.freebsd.org/src/commit/?id=a534b50e245d801af887d91b5d48ebcf120aa039

            

          

          


          

          
Wow, this is good news...

          

          
 

          

          

            Although I have not been brave enough to update to HEAD and
            try it yet :)

          

        

        


        

        
Yeah, better to wait than meet a lot of
          surprises with HEAD :-)

        

      

    

    
Thanks for the fix. I hope to try it soon.

    
Brian

    

  


--------------3qvlW3xoMYqViptcaTO00p0w--

From nobody Mon Feb 21 12:22:19 2022
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 ED0E319DBC19;
	Mon, 21 Feb 2022 12:22:25 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1])
	(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 "smtp", Issuer "smtp" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K2Lz43SsQz3Fdd;
	Mon, 21 Feb 2022 12:22:24 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (kx.truefc.org [36.52.212.1])
       by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 21LCMJbq089998;
       Mon, 21 Feb 2022 21:22:20 +0900 (JST)
       (envelope-from kiri@kx.truefc.org)
Message-Id: <202202211222.21LCMJbq089998@kx.truefc.org>
Date: Mon, 21 Feb 2022 21:22:19 +0900
From: KIRIYAMA Kazuhiko 
To: Greg V 
Cc: KIRIYAMA Kazuhiko , x11@freebsd.org,
        freebsd-arm@freebsd.org
Subject: Re: Is there any X driver for Panfrost on PBP ?
In-Reply-To: 
References: <202202202226.21KMQQxG082376@kx.truefc.org>
	
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24)
 (Standard C) (amd64--freebsd)
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 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4K2Lz43SsQz3Fdd
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org
X-Spamd-Result: default: False [-2.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[kiri];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[truefc.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.90)[-0.896];
	 MLMMJ_DEST(0.00)[freebsd-arm,x11];
	 RCVD_COUNT_ONE(0.00)[1];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ONCE_RECEIVED(0.10)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 17368
Lines: 362

Hi, Greg !

On Mon, 21 Feb 2022 09:06:49 +0900,
Greg V wrote:
>=20
>=20
>=20
> On February 21, 2022 1:26:26 AM GMT+03:00, KIRIYAMA Kazuhiko  wrote:
> >Hi, lists
>=20
> Hi,
>=20
> [..]
>=20
> >rk_drm0: Cannot find port with phandle 10
>=20
> (hopefully this one is harmless..)
>=20
> >But I could not found panfrot X driver. Is there any panfrost
> >X driver for FreeBSD ?
>=20
> Please forget about the notion of hardware specific X drivers and just ru=
n startx.
>=20
> There is *one* relevant X video driver =E2=80=93 xf86-video-modesetting =
=E2=80=93 and it is built in.
>=20
> (Ok, -amdgpu is somewhat relevant but that's just -modesetting with TearF=
ree hacks. Meanwhile -intel is a terrible pile of abandonware that mostly c=
auses problems.)
>=20

I set Driver to "modesetting" in Device section :

kiri@kazu:~[1002]% cat /usr/local/share/X11/xorg.conf.d/30-driver-mali.conf=
=20
Section "Device"
      Identifier "Card1"
      Driver "modesetting"
EndSection
kiri@kazu:~[1003]%=20

and then `startx', X started  :-)

kiri@kazu:~[1003]% cat /var/log/Xorg.0.log
[ 47449.405]=20
X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
[ 47449.405] Build Operating System: FreeBSD 14.0-CURRENT arm64=20
[ 47449.405] Current Operating System: FreeBSD kazu.tfc 14.0-CURRENT FreeBS=
D 14.0-CURRENT #0 n252641-3f106af0cd92-dirty: Wed Jan 26 22:41:41 JST 2022 =
    root@tbedfc:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-DRM arm64
[ 47449.407] Build Date: 03 February 2022  10:24:33PM
[ 47449.407] =20
[ 47449.407] Current version of pixman: 0.40.0
[ 47449.407] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[ 47449.407] Markers: (--) probed, (**) from config file, (=3D=3D) default =
setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 47449.408] (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 21 20:=
21:12 2022
[ 47449.410] (=3D=3D) Using config directory: "/usr/local/etc/X11/xorg.conf=
.d"
[ 47449.411] (=3D=3D) Using system config directory "/usr/local/share/X11/x=
org.conf.d"
[ 47449.413] (=3D=3D) No Layout section.  Using the first Screen section.
[ 47449.413] (=3D=3D) No screen section available. Using defaults.
[ 47449.413] (**) |-->Screen "Default Screen Section" (0)
[ 47449.413] (**) |   |-->Monitor ""
[ 47449.416] (=3D=3D) No device specified for screen "Default Screen Sectio=
n".
	Using the first device section listed.
[ 47449.416] (**) |   |-->Device "Card1"
[ 47449.416] (=3D=3D) No monitor specified for screen "Default Screen Secti=
on".
	Using a default monitor configuration.
[ 47449.416] (=3D=3D) Automatically adding devices
[ 47449.416] (=3D=3D) Automatically enabling devices
[ 47449.416] (=3D=3D) Not automatically adding GPU devices
[ 47449.416] (=3D=3D) Max clients allowed: 256, resource mask: 0x1fffff
[ 47449.417] (WW) The directory "/usr/local/share/fonts/stix/" does not exi=
st.
[ 47449.417] 	Entry deleted from font path.
[ 47449.417] (WW) `fonts.dir' not found (or not valid) in "/usr/local/share=
/fonts/std.ja_JP/".
[ 47449.417] 	Entry deleted from font path.
[ 47449.417] 	(Run 'mkfontdir' on "/usr/local/share/fonts/std.ja_JP/").
[ 47449.419] (**) FontPath set to:
	/usr/local/share/fonts/cyrillic/,
	/usr/local/share/fonts/bitstream-vera/,
	/usr/local/share/fonts/misc/,
	/usr/local/share/fonts/TTF/,
	/usr/local/share/fonts/OTF/,
	/usr/local/share/fonts/Type1/,
	/usr/local/share/fonts/100dpi/,
	/usr/local/share/fonts/75dpi/,
	catalogue:/usr/local/etc/X11/fontpath.d
[ 47449.419] (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules"
[ 47449.419] (II) The server relies on udev to provide the list of input de=
vices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 47449.419] (II) Loader magic: 0x43c3f8
[ 47449.419] (II) Module ABI versions:
[ 47449.419] 	X.Org ANSI C Emulation: 0.4
[ 47449.419] 	X.Org Video Driver: 24.1
[ 47449.419] 	X.Org XInput driver : 24.1
[ 47449.419] 	X.Org Server Extension : 10.0
[ 47449.419] (II) LoadModule: "glx"
[ 47449.421] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[ 47449.431] (II) Module glx: vendor=3D"X.Org Foundation"
[ 47449.431] 	compiled for 1.20.13, module version =3D 1.0.0
[ 47449.431] 	ABI class: X.Org Server Extension, version 10.0
[ 47449.431] (II) LoadModule: "modesetting"
[ 47449.432] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_d=
rv.so
[ 47449.440] (II) Module modesetting: vendor=3D"X.Org Foundation"
[ 47449.440] 	compiled for 1.20.13, module version =3D 1.20.13
[ 47449.440] 	Module class: X.Org Video Driver
[ 47449.440] 	ABI class: X.Org Video Driver, version 24.1
[ 47449.440] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 47449.441] (--) Using syscons driver with X support (version 358875076105=
33890.0)
[ 47449.441] (--) using VT number 9

[ 47449.441] (WW) Falling back to old probe method for modesetting
[ 47449.450] (II) modeset(0): using default device
[ 47449.450] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card su=
pport
[ 47449.451] (II) modeset(0): Creating default Display subsection in Screen=
 section
	"Default Screen Section" for depth/fbbpp 24/32
[ 47449.451] (=3D=3D) modeset(0): Depth 24, (=3D=3D) framebuffer bpp 32
[ 47449.451] (=3D=3D) modeset(0): RGB weight 888
[ 47449.451] (=3D=3D) modeset(0): Default visual is TrueColor
[ 47449.451] (II) Loading sub module "glamoregl"
[ 47449.451] (II) LoadModule: "glamoregl"
[ 47449.453] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[ 47449.573] (II) Module glamoregl: vendor=3D"X.Org Foundation"
[ 47449.574] 	compiled for 1.20.13, module version =3D 1.0.1
[ 47449.574] 	ABI class: X.Org ANSI C Emulation, version 0.4
[ 47452.771] (II) modeset(0): Refusing to try glamor on llvmpipe
[ 47452.815] (EE) modeset(0): glamor initialization failed
[ 47452.815] (II) modeset(0): ShadowFB: preferred NO, enabled NO
[ 47452.820] (II) modeset(0): Output eDP-1 has no monitor section
[ 47452.824] (II) modeset(0): EDID for output eDP-1
[ 47452.827] (II) modeset(0): Printing probed modes for output eDP-1
[ 47452.827] (II) modeset(0): Modeline "1920x1080"x60.0  141.40  1920 1968 =
2000 2142  1080 1083 1089 1100 +hsync -vsync (66.0 kHz eP)
[ 47452.827] (II) modeset(0): Modeline "1920x1080"x48.0  113.12  1920 1968 =
2000 2142  1080 1083 1089 1100 +hsync -vsync (52.8 kHz e)
[ 47452.827] (II) modeset(0): Output eDP-1 connected
[ 47452.827] (II) modeset(0): Using exact sizes for initial modes
[ 47452.827] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
[ 47452.827] (=3D=3D) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[ 47452.827] (=3D=3D) modeset(0): DPI set to (96, 96)
[ 47452.827] (II) Loading sub module "fb"
[ 47452.827] (II) LoadModule: "fb"
[ 47452.829] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[ 47452.835] (II) Module fb: vendor=3D"X.Org Foundation"
[ 47452.835] 	compiled for 1.20.13, module version =3D 1.0.0
[ 47452.835] 	ABI class: X.Org ANSI C Emulation, version 0.4
[ 47452.855] (=3D=3D) modeset(0): Backing store enabled
[ 47452.855] (=3D=3D) modeset(0): Silken mouse enabled
[ 47452.883] (II) modeset(0): Initializing kms color map for depth 24, 8 bp=
c.
[ 47452.886] (=3D=3D) modeset(0): DPMS enabled
[ 47452.888] (II) Initializing extension Generic Event Extension
[ 47452.894] (II) Initializing extension SHAPE
[ 47452.898] (II) Initializing extension MIT-SHM
[ 47452.903] (II) Initializing extension XInputExtension
[ 47452.911] (II) Initializing extension XTEST
[ 47452.916] (II) Initializing extension BIG-REQUESTS
[ 47452.921] (II) Initializing extension SYNC
[ 47452.928] (II) Initializing extension XKEYBOARD
[ 47452.934] (II) Initializing extension XC-MISC
[ 47452.938] (II) Initializing extension SECURITY
[ 47452.942] (II) Initializing extension XFIXES
[ 47452.949] (II) Initializing extension RENDER
[ 47452.953] (II) Initializing extension RANDR
[ 47452.961] (II) Initializing extension COMPOSITE
[ 47452.965] (II) Initializing extension DAMAGE
[ 47452.969] (II) Initializing extension MIT-SCREEN-SAVER
[ 47452.975] (II) Initializing extension DOUBLE-BUFFER
[ 47452.979] (II) Initializing extension RECORD
[ 47452.983] (II) Initializing extension DPMS
[ 47452.987] (II) Initializing extension Present
[ 47452.991] (II) Initializing extension DRI3
[ 47452.991] (II) Initializing extension X-Resource
[ 47452.995] (II) Initializing extension XVideo
[ 47453.002] (II) Initializing extension XVideo-MotionCompensation
[ 47453.002] (II) Initializing extension GLX
[ 47453.008] (II) AIGLX: Screen 0 is not DRI2 capable
[ 47453.432] (II) IGLX: Loaded and initialized swrast
[ 47453.432] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 47453.432] (II) Initializing extension XFree86-VidModeExtension
[ 47453.436] (II) Initializing extension XFree86-DGA
[ 47453.440] (II) Initializing extension XFree86-DRI
[ 47453.440] (II) Initializing extension DRI2
[ 47453.445] (II) modeset(0): Damage tracking initialized
[ 47453.445] (II) modeset(0): Setting screen physical size to 508 x 285
[ 47454.785] (II) config/udev: Adding input device System mouse (/dev/input=
/event0)
[ 47454.785] (**) System mouse: Applying InputClass "libinput pointer catch=
all"
[ 47454.785] (II) LoadModule: "libinput"
[ 47454.788] (II) Loading /usr/local/lib/xorg/modules/input/libinput_drv.so
[ 47454.938] (II) Module libinput: vendor=3D"X.Org Foundation"
[ 47454.938] 	compiled for 1.20.13, module version =3D 0.30.0
[ 47454.938] 	Module class: X.Org XInput Driver
[ 47454.938] 	ABI class: X.Org XInput driver, version 24.1
[ 47454.940] (II) Using input driver 'libinput' for 'System mouse'
[ 47454.940] (**) System mouse: always reports core events
[ 47454.941] (**) Option "Device" "/dev/input/event0"
[ 47454.944] (**) Option "_source" "server/udev"
[ 47455.076] (II) event0  - System mouse: is tagged by udev as: Mouse
[ 47455.084] (II) event0  - System mouse: device is a pointer
[ 47455.095] (II) event0  - System mouse: device removed
[ 47455.096] (**) Option "config_info" "udev:/dev/input/event0"
[ 47455.096] (II) XINPUT: Adding extended input device "System mouse" (type=
: MOUSE, id 6)
[ 47455.098] (**) Option "AccelerationScheme" "none"
[ 47455.098] (**) System mouse: (accel) selected scheme none/0
[ 47455.098] (**) System mouse: (accel) acceleration factor: 2.000
[ 47455.098] (**) System mouse: (accel) acceleration threshold: 4
[ 47455.111] (II) event0  - System mouse: is tagged by udev as: Mouse
[ 47455.119] (II) event0  - System mouse: device is a pointer
[ 47455.127] (II) config/udev: Adding input device System keyboard multiple=
xer (/dev/input/event1)
[ 47455.128] (**) System keyboard multiplexer: Applying InputClass "Evdev k=
eyboard"
[ 47455.128] (**) System keyboard multiplexer: Applying InputClass "libinpu=
t keyboard catchall"
[ 47455.128] (II) Using input driver 'libinput' for 'System keyboard multip=
lexer'
[ 47455.128] (**) System keyboard multiplexer: always reports core events
[ 47455.128] (**) Option "Device" "/dev/input/event1"
[ 47455.128] (**) Option "_source" "server/udev"
[ 47455.142] (II) event1  - System keyboard multiplexer: is tagged by udev =
as: Keyboard
[ 47455.146] (II) event1  - System keyboard multiplexer: device is a keyboa=
rd
[ 47455.158] (II) event1  - System keyboard multiplexer: device removed
[ 47455.159] (**) Option "config_info" "udev:/dev/input/event1"
[ 47455.159] (II) XINPUT: Adding extended input device "System keyboard mul=
tiplexer" (type: KEYBOARD, id 7)
[ 47455.159] (**) Option "xkb_rules" "evdev"
[ 47455.609] (II) event1  - System keyboard multiplexer: is tagged by udev =
as: Keyboard
[ 47455.613] (II) event1  - System keyboard multiplexer: device is a keyboa=
rd
[ 47455.626] (II) config/udev: Adding input device HAILUCK CO. (/dev/input/=
event2)
[ 47455.626] (**) HAILUCK CO.: Applying InputClass "Evdev keyboard"
[ 47455.626] (**) HAILUCK CO.: Applying InputClass "libinput keyboard catch=
all"
[ 47455.626] (II) Using input driver 'libinput' for 'HAILUCK CO.'
[ 47455.626] (**) HAILUCK CO.: always reports core events
[ 47455.627] (**) Option "Device" "/dev/input/event2"
[ 47455.627] (**) Option "_source" "server/udev"
[ 47455.639] (II) event2  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: is tagged by udev as: Keyboard
[ 47455.643] (II) event2  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device is a keyboard
[ 47455.663] (II) event2  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device removed
[ 47455.663] (**) Option "config_info" "udev:/dev/input/event2"
[ 47455.663] (II) XINPUT: Adding extended input device "HAILUCK CO." (type:=
 KEYBOARD, id 8)
[ 47455.663] (**) Option "xkb_rules" "evdev"
[ 47455.677] (II) event2  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: is tagged by udev as: Keyboard
[ 47455.681] (II) event2  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device is a keyboard
[ 47455.701] (II) config/udev: Adding input device HAILUCK CO. (/dev/input/=
event3)
[ 47455.701] (**) HAILUCK CO.: Applying InputClass "libinput pointer catcha=
ll"
[ 47455.701] (II) Using input driver 'libinput' for 'HAILUCK CO.'
[ 47455.701] (**) HAILUCK CO.: always reports core events
[ 47455.701] (**) Option "Device" "/dev/input/event3"
[ 47455.702] (**) Option "_source" "server/udev"
[ 47455.714] (II) event3  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: is tagged by udev as: Mouse
[ 47455.722] (II) event3  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device is a pointer
[ 47455.734] (II) event3  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device removed
[ 47455.734] (**) Option "config_info" "udev:/dev/input/event3"
[ 47455.734] (II) XINPUT: Adding extended input device "HAILUCK CO." (type:=
 MOUSE, id 9)
[ 47455.736] (**) Option "AccelerationScheme" "none"
[ 47455.736] (**) HAILUCK CO.: (accel) selected scheme none/0
[ 47455.736] (**) HAILUCK CO.: (accel) acceleration factor: 2.000
[ 47455.736] (**) HAILUCK CO.: (accel) acceleration threshold: 4
[ 47455.748] (II) event3  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: is tagged by udev as: Mouse
[ 47455.756] (II) event3  - HAILUCK CO.,LTD USB KEYBOARD, class 0/0, rev 1.=
10/1.00, addr 2: device is a pointer
[ 47473.793] (II) config/udev: Adding input device Logitech USB Receiver (/=
dev/input/event4)
[ 47473.793] (**) Logitech USB Receiver: Applying InputClass "libinput poin=
ter catchall"
[ 47473.793] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[ 47473.793] (**) Logitech USB Receiver: always reports core events
[ 47473.793] (**) Option "Device" "/dev/input/event4"
[ 47473.793] (**) Option "_source" "server/udev"
[ 47473.807] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: is tagged by udev as: Mouse
[ 47473.816] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: device is a pointer
[ 47473.828] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: device removed
[ 47473.829] (**) Option "config_info" "udev:/dev/input/event4"
[ 47473.829] (II) XINPUT: Adding extended input device "Logitech USB Receiv=
er" (type: MOUSE, id 10)
[ 47473.831] (**) Option "AccelerationScheme" "none"
[ 47473.832] (**) Logitech USB Receiver: (accel) selected scheme none/0
[ 47473.832] (**) Logitech USB Receiver: (accel) acceleration factor: 2.000
[ 47473.832] (**) Logitech USB Receiver: (accel) acceleration threshold: 4
[ 47473.846] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: is tagged by udev as: Mouse
[ 47473.854] (II) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: device is a pointer
[ 47892.921] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: client bug: event processing lagging behind by 23ms, your system=
 is too slow
[ 47948.174] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: client bug: event processing lagging behind by 11ms, your system=
 is too slow
[ 47951.197] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: client bug: event processing lagging behind by 41ms, your system=
 is too slow
[ 47988.409] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: client bug: event processing lagging behind by 15ms, your system=
 is too slow
[ 48004.732] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: client bug: event processing lagging behind by 37ms, your system=
 is too slow
[ 48004.732] (EE) event4  - Logitech USB Receiver, class 0/0, rev 2.00/30.0=
0, addr 6: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding =
future messages.


I tried to run firefox and viewed sevral YouTube channels,
then suddenly crashed with :

kiri@kazu:~[1008]% firefox
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via P=
CI (t=3D5.25465) [GFX1-]: No GPUs detected via PCI
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via P=
CI (t=3D5.25465) |[1][GFX1-]: glxtest: process failed (received signal 11) =
(t=3D5.2565) [GFX1-]: glxtest: process failed (received signal 11)

But now stable ;-)

Anyway thanx !

---
Kiriyama Kazuhiko 

From nobody Tue Feb 22 09:42:42 2022
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 B1DF519E1614
	for ; Tue, 22 Feb 2022 09:42:49 +0000 (UTC)
	(envelope-from peterj@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 4K2vNT4gBqz4RDt;
	Tue, 22 Feb 2022 09:42:49 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1645522969;
	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;
	bh=ycnZwT3D5JAiu1NxbgD5y3ue6rqMwiAslkF/AYry5iI=;
	b=RfZZPuJDXqOeMs4MVlmnHtlX3ItYWyWtMsKD5+Yz5zH/mMuuSP6dp9lAp379GOnJQMQC3j
	VdNkAZdN+al5Gz/vlZhHdNrxuy5vqmhFqociHrSHL8WRCHyVdSl5Um3yw4gGZfKUTA76/o
	2pdwUewDEEExW0VvBRpL53q1aiq0MrXRleGX48DME3Pbi+JaiEaAxPlfl+isKqI+KWah8i
	hbIv5SgPQLqbAb4GbdjMPaBUL6YWeWvwVtWSX3FSlrayPUzASLaMHKe6c0dE673a5zn2dR
	sumY63ttP59dN6sVXv5rPEmusKaIqWrdJNSyDnFlSfZs5did4ZzrgksYZwbhgA==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 89F5EE978;
	Tue, 22 Feb 2022 09:42:48 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Tue, 22 Feb 2022 20:42:42 +1100
From: peterj@freebsd.org
To: manu@freebsd.org
Cc: FreeBSD-arm@freebsd.org
Subject: Allwinner H6 thermal support
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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="iFNHVD+8cDNfhebL"
Content-Disposition: inline
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645522969;
	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;
	bh=ycnZwT3D5JAiu1NxbgD5y3ue6rqMwiAslkF/AYry5iI=;
	b=PUHKNhhd8c82tKrI2xV+suYOeTgICtJXz1D4D8+sYmA7F278JRk7rFe/YTXyyaLENQ/HCh
	A/HCq2AcoS3RduRPFz0xWrjXTfpt0q/D962FUsimhrZXQ1LVcrBdqZR0ftSZSMd3Py5tXS
	k9UfqS5ztkF9/DuuA+aElwETtO4s8P0DryHgshyW2Z8MrFy5EBtgbQrAbPirX5LJV2bXit
	jk/m+xywd0C5jWPb2Oq6BmLeFQTHiE4ot+XkPwV4Hlabskvg/NJPkXh4bPyv955F4PrT5M
	69nU94TOHHy+DA4ylooVmFk5PZ8zi2I6DSAjVFSK2Aa/1WxwksaKBSiRx3I63Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645522969; a=rsa-sha256; cv=none;
	b=EoDotdoOkqdT7MJatf9kM7u8WHgFmXtIFoaUAOKUK6Pa1Eok5u5JUuk4iIJS+VXaBTjuvS
	lqjIBmvR1287/pZEBd09KF5/i7FLdXfB7pcigIaTwXLgsWAoT2VFjUYn1wLchAdQxxU2vT
	/By8bxEtkzZUU8pmZLPxgePeqb8NAf/c1Rot/4NpZ31p0LILSoFvIPiOIaOtawzYuL7b4W
	Rb8oM7QkmMuO+RHFMADPmEkuj+fg+ctXg6dhnrHyKGO8zpjLuAo90Y3WI7/yYcJpEHxWCI
	lzXtjKijRDLjo4HsrBczK0wKf+tZEy6fnplzHcIwOXEoNd4i1pmSM7dk7l+D/Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2095
Lines: 50


--iFNHVD+8cDNfhebL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Emmanuel,

I notice you indicated that there is thermal support for the H6 on
https://wiki.freebsd.org/arm/Allwinner.  I've just started
experimenting with a PINE H64 and noticed the board didn't report any
temperature data.  Looking through the head code, the doesn't seem to
be any support for sun50i-h6-ths.  Do you have the code in a branch
somewhere?

Before I noticed the wiki page, I started looking at implementing the
code myself.  I had expected it would just be a matter of replicating
the H5 code and tweaking the constants but, reading the Thermal Sensor
Controller section of the H6 manual, it looks like the H6 controller
is very different to the H5 controller:  The registers are at different
offsets and laid out differently, so it's not compatible with (eg)
sys/arm/allwinner/aw_thermal.c:aw_thermal_init(), which is a PITA.
Have I missed something?

--=20
Peter Jeremy

--iFNHVD+8cDNfhebL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmIUsAxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzQzYRAAm8cl+UkCEgBokimJvbzroA436/BPnIVBVmE++LRG2gU9/Udm/WpUBD0d
qM5M816EMXDGNDEDOgTbR/60wEEVGE2jHvFnyWSfKIGnYloKdyRZ1+d2X7KEHyt/
DXXaXpFm9uTLUg+LS1BwW+b9D/h40lwxnk7KB/1YcX2WmPvEPXTVHlAJWoCigBq4
lRAzvzYzsbL54Z1JCNqceQZuo5Mf+z1kwG/I22E7QoP++JmAU1t7luy0F6qlVoCj
WpF3hpvtAxI2PxWhQRAaSpp+Vjhf3//irryns1brCQ/wgmLMB/aDZxBLHQPbITdR
ROVQooDJ8+XHAo/A7bbOmWff9CvybC/jZK9AcAAdDUGczJselzQIMnrnxBiYfLAk
NdiKgaQ9rlhlqQZTGKP+9u0q7qEfOhvsnLwcI6ZgbdBN3h+NUTi/6zMq8QVwG8if
Vl6M6j4bh3ycBSwTow9qiASMKAt43S5OGmn+OoluKsjsANDjO9fr+mk9GnDoKOxc
S+4gvIjKK5nUPGcXTM8mp98cvjDWXU9if9uJDNrTjBjWrVxvW3vrUt7XYWAwgKfc
YUevPHDMf/2u/gnE8uvNBVrgHJlVwKigmfupBNUGHqdiw9zew4oj307oMLpY3KNq
unHTu2SwnA+N0kRGlxsv0joAkTN5Ep1NX/uuGh8Rdh84T82nayM=
=pXMT
-----END PGP SIGNATURE-----

--iFNHVD+8cDNfhebL--

From nobody Tue Feb 22 10:08:34 2022
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 A7BB119E556A
	for ; Tue, 22 Feb 2022 10:08:40 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mail.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 4K2vyH4XLJz4Tjm;
	Tue, 22 Feb 2022 10:08:36 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1645524514;
	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=gPiKYog6atIfrS8w3ABNsfbXUJKISJAJj+MsvZfpciA=;
	b=AbXYlCMxwChwWKdLH3wTjZ7qKQRszkFE5b/ieIVwB52zeQ8wxavHYIjmHmYDEdXNDc2/wi
	RvMekh9PNHGoahdhJSjCC0a9pRplVm868FaIV26ra3x+TQIL5XBMcX+Md6ZJ68eXMYBL96
	3x4FwsXOB8PHUHEU8ZQKbhsP7ubXBpE=
Received: from skull.home.blih.net (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id ed89bbc2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 22 Feb 2022 10:08:34 +0000 (UTC)
Date: Tue, 22 Feb 2022 11:08:34 +0100
From: Emmanuel Vadot 
To: peterj@freebsd.org
Cc: FreeBSD-arm@freebsd.org
Subject: Re: Allwinner H6 thermal support
Message-Id: <20220222110834.60b99a4edb8a4322a4c0a7ac@bidouilliste.com>
In-Reply-To: 
References: 
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: 4K2vyH4XLJz4Tjm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=AbXYlCMx;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.46 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-0.96)[-0.963];
	 MLMMJ_DEST(0.00)[FreeBSD-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1527
Lines: 36


 Hi Peter,

On Tue, 22 Feb 2022 20:42:42 +1100
peterj@freebsd.org wrote:

> Hi Emmanuel,
> 
> I notice you indicated that there is thermal support for the H6 on
> https://wiki.freebsd.org/arm/Allwinner.  I've just started
> experimenting with a PINE H64 and noticed the board didn't report any
> temperature data.  Looking through the head code, the doesn't seem to
> be any support for sun50i-h6-ths.  Do you have the code in a branch
> somewhere?

 If it's indeed me who put this on the wiki it's a mistake, I don't
remember ever working on H6 thermal support sorry.

> Before I noticed the wiki page, I started looking at implementing the
> code myself.  I had expected it would just be a matter of replicating
> the H5 code and tweaking the constants but, reading the Thermal Sensor
> Controller section of the H6 manual, it looks like the H6 controller
> is very different to the H5 controller:  The registers are at different
> offsets and laid out differently, so it's not compatible with (eg)
> sys/arm/allwinner/aw_thermal.c:aw_thermal_init(), which is a PITA.
> Have I missed something?

 Haven't looked myself but I'm not surprised, Allwinner is known to
change its design from time to time.
 Also tbh the only reason I've added basic H6 support was to work on
the designware usb3 controller as at the time I had problems with
Rockchip and didn't knew if it was my driver for the usb3 controller or
the phy and the phy driver was simpler on Allwinner.

-- 
Emmanuel Vadot  

From nobody Tue Feb 22 10:14:15 2022
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 3666D19E6791;
	Tue, 22 Feb 2022 10:14:18 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mail.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 4K2w4m72gvz4VTQ;
	Tue, 22 Feb 2022 10:14:16 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1645524855;
	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=bfv9NdNGs61KR1LaG61J54Q7F3eXubnevxHPHaUG2Kk=;
	b=brgXfjAAHIl4d0jZjds37Snj3pjcXEjnFX+a7MAf1Mry1Xk0QLmcgTIXt4VxwZ2+Crh2Oh
	REgJYHGSAPUCEGJTT63XplOc1u33/pnwDZH9I7UhDakzWZO7VsCX+d2HaoHPZgpb6hzib3
	V+vMGfcfQ13aF0sZP4VFFI4pa4uTCi4=
Received: from skull.home.blih.net (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 21cadafe (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 22 Feb 2022 10:14:15 +0000 (UTC)
Date: Tue, 22 Feb 2022 11:14:15 +0100
From: Emmanuel Vadot 
To: KIRIYAMA Kazuhiko 
Cc: Greg V , x11@freebsd.org,
 freebsd-arm@freebsd.org
Subject: Re: Is there any X driver for Panfrost on PBP ?
Message-Id: <20220222111415.ae1b10b881c6471a004b8e8f@bidouilliste.com>
In-Reply-To: <202202211222.21LCMJbq089998@kx.truefc.org>
References: <202202202226.21KMQQxG082376@kx.truefc.org>
	
	<202202211222.21LCMJbq089998@kx.truefc.org>
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-Rspamd-Queue-Id: 4K2w4m72gvz4VTQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=brgXfjAA;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-2.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[x11,freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2630
Lines: 88

On Mon, 21 Feb 2022 21:22:19 +0900
KIRIYAMA Kazuhiko  wrote:

> Hi, Greg !
>=20
> On Mon, 21 Feb 2022 09:06:49 +0900,
> Greg V wrote:
> >=20
> >=20
> >=20
> > On February 21, 2022 1:26:26 AM GMT+03:00, KIRIYAMA Kazuhiko  wrote:
> > >Hi, lists
> >=20
> > Hi,
> >=20
> > [..]
> >=20
> > >rk_drm0: Cannot find port with phandle 10
> >=20
> > (hopefully this one is harmless..)

 It is depending on the platform, it's just a warning that we couldn't
find one component of the pipeline (so for example eDP on a board or
HDMI on the PinebookPro in this case).

> > >But I could not found panfrot X driver. Is there any panfrost
> > >X driver for FreeBSD ?
> >=20
> > Please forget about the notion of hardware specific X drivers and just =
run startx.
> >=20
> > There is *one* relevant X video driver ? xf86-video-modesetting ? and i=
t is built in.
> >=20
> > (Ok, -amdgpu is somewhat relevant but that's just -modesetting with Tea=
rFree hacks. Meanwhile -intel is a terrible pile of abandonware that mostly=
 causes problems.)
> >=20
>=20
> I set Driver to "modesetting" in Device section :
>=20
> kiri@kazu:~[1002]% cat /usr/local/share/X11/xorg.conf.d/30-driver-mali.co=
nf=20
> Section "Device"
>       Identifier "Card1"
>       Driver "modesetting"
> EndSection
> kiri@kazu:~[1003]%=20
>=20
> and then `startx', X started  :-)

 You shouldn't have to provide any X configuration, modesetting is the
default.

> kiri@kazu:~[1003]% cat /var/log/Xorg.0.log
> [log trimmed]
> I tried to run firefox and viewed sevral YouTube channels,
> then suddenly crashed with :
>=20
> kiri@kazu:~[1008]% firefox
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via=
 PCI (t=3D5.25465) [GFX1-]: No GPUs detected via PCI
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via=
 PCI (t=3D5.25465) |[1][GFX1-]: glxtest: process failed (received signal 11=
) (t=3D5.2565) [GFX1-]: glxtest: process failed (received signal 11)

 That seems to be some firefox specific thing where it looks for the
DRI driver and (probably) do optimization based on this.
 See
https://searchfox.org/mozilla-central/source/widget/gtk/GfxInfo.cpp#343

 I don't really know what the correct value should be for embedded
platform tbh. It's probably using the render node to get the driver
name (that is what make sense at least) but even if we returned the
correct value in the panfrost code right now it doesn't handle it ...

> But now stable ;-)
>=20
> Anyway thanx !
>=20
> ---
> Kiriyama Kazuhiko 
>=20


--=20
Emmanuel Vadot  

From nobody Tue Feb 22 15:01:27 2022
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 77AC119D02F3
	for ; Tue, 22 Feb 2022 15:01:41 +0000 (UTC)
	(envelope-from adridg@freebsd.org)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.170])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K32SN3btJz56J3
	for ; Tue, 22 Feb 2022 15:01:40 +0000 (UTC)
	(envelope-from adridg@freebsd.org)
X-KPN-MessageId: 46908a32-93f0-11ec-8147-005056ab378f
Received: from smtp.kpnmail.nl (unknown [10.31.155.40])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id 46908a32-93f0-11ec-8147-005056ab378f;
	Tue, 22 Feb 2022 16:01:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=kpnmail.nl; s=kpnmail01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=az+xsmxfIYAJpPMi+HMvQtxM+EoHYQ6nkgZVwBOppPA=;
	b=IWcV4fP3YgRdvqpAXbSJHrvR5HjiMcX1hWeX2duOxD0xm/VK0UME006oMk8Bo3C4+Lo2qVWJFycoz
	 ghojn2K1gJTPMKuosKPPDoPf3mRWfPoFw642yg/1txdeoejzI0mSb178UxfHn5vJUvpQ/TNALaK/mT
	 yiJ7DiZKCRa+36D0=
X-KPN-VerifiedSender: No
X-CMASSUN: 33|QytKp7rMeuhjfKFGN6pzOIYbUn+UH+x8m5mEzBZw5HHBialfyoY57Fv0e1oztv5
 FeMLTxVsmbnaBcYwHIUiMeQ==
X-Originating-IP: 62.251.92.29
Received: from beastie.bionicmutton.org (62-251-92-29.ip.xs4all.nl [62.251.92.29])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id 528f8ae2-93f0-11ec-a9ea-005056ab7584;
	Tue, 22 Feb 2022 16:01:33 +0100 (CET)
From: Adriaan de Groot 
To: peterj@freebsd.org, freebsd-arm@freebsd.org
Cc: FreeBSD-arm@freebsd.org, Emmanuel Vadot 
Subject: Re: Allwinner H6 thermal support
Date: Tue, 22 Feb 2022 16:01:27 +0100
Message-ID: <2435897.0dHE6SNnxz@beastie.bionicmutton.org>
Organization: FreeBSD
In-Reply-To: <20220222110834.60b99a4edb8a4322a4c0a7ac@bidouilliste.com>
References:  <20220222110834.60b99a4edb8a4322a4c0a7ac@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: multipart/signed; boundary="nextPart3909011.BRNeRiNLvY"; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Rspamd-Queue-Id: 4K32SN3btJz56J3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=kpnmail.nl header.s=kpnmail01 header.b=IWcV4fP3;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 195.121.94.170 is neither permitted nor denied by domain of adridg@freebsd.org) smtp.mailfrom=adridg@freebsd.org
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 HAS_XOIP(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 HAS_ORG_HEADER(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[195.121.94.170:from];
	 DKIM_TRACE(0.00)[kpnmail.nl:+];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	 RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.170:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[kpnmail.nl:s=kpnmail01];
	 FREEFALL_USER(0.00)[adridg];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2397
Lines: 57

--nextPart3909011.BRNeRiNLvY
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Adriaan de Groot 
To: peterj@freebsd.org, freebsd-arm@freebsd.org
Cc: FreeBSD-arm@freebsd.org, Emmanuel Vadot 
Subject: Re: Allwinner H6 thermal support
Date: Tue, 22 Feb 2022 16:01:27 +0100
Message-ID: <2435897.0dHE6SNnxz@beastie.bionicmutton.org>
Organization: FreeBSD
In-Reply-To: <20220222110834.60b99a4edb8a4322a4c0a7ac@bidouilliste.com>
References:  <20220222110834.60b99a4edb8a4322a4c0a7ac@bidouilliste.com>

On Tuesday, 22 February 2022 11:08:34 CET Emmanuel Vadot wrote:
> > Hi Emmanuel,
> > 
> > I notice you indicated that there is thermal support for the H6 on
> > https://wiki.freebsd.org/arm/Allwinner.  I've just started
> > experimenting with a PINE H64 and noticed the board didn't report any
> > temperature data.  Looking through the head code, the doesn't seem to
> > be any support for sun50i-h6-ths.  Do you have the code in a branch
> > somewhere?
> 
>  If it's indeed me who put this on the wiki it's a mistake, I don't
> remember ever working on H6 thermal support sorry.

It might have been a copy-paste error be me, even -- wiki blame wasn't 
immediately helpful, though. I think I put together some of the H6-specific 
page since I was so happy that Manu had gotten it to boot. In the meantime I 
use an H6 for DNS &c locally, never bothered to think about thermals.

[ade]

--nextPart3909011.BRNeRiNLvY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQGzBAABCAAdFiEESUdADzdGoDiQC7F4Mo10LYgHpDUFAmIU+scACgkQMo10LYgH
pDUz3AwAlG5NECvoz0Y02j2EAKuW6Ak9vL8CHcrQsf+Nr+0P/dYLCY8RIH7arTBB
UCQCsa4mxg87OLBpWBwfku4F425JMbTsaSO6yGI0H2Xlqup7vNm8HgbGfRQCqSFT
/h3ozdJcnH7wlTXVbdAoefBvDU6XzXHEEvEZdwE3kh7A6AKbl1cJgR4kzoQh43tu
Qd1gsLJVPVxZhh+1tMVavd/xeGdhCrkyl8zegf18IxhX1NeRu00gUgMxl9PjYfII
R8XqjzX6TbV8wUDxJw5FIqB+didunv+LSAgHc/LdMoj92F2MlNS9pD0XHrTp2NxZ
5rx4rrf6221MTI0CUf+eH3NI91MfzhF9TCip7PDG54jEDUgOXaHGeyxjk72xGaWU
p/63hR6WxyIbu8fUozSy6uzoUhfxJpmfNzW7wdIRcSZMg0P+fJeKqm1a+Fnc7Ydl
ln1P9j5gHFSpGFwTqJ3FR5bkOqfE27cHXKEpXpj80LszCr1YyeIFvS/6fkClpWvW
SRJxhNym
=hfXU
-----END PGP SIGNATURE-----

--nextPart3909011.BRNeRiNLvY--




From nobody Wed Feb 23 07:59:19 2022
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 E2A8519DD91E;
	Wed, 23 Feb 2022 07:59:31 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1])
	(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 "smtp", Issuer "smtp" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K3T2p5fCjz4V0w;
	Wed, 23 Feb 2022 07:59:30 +0000 (UTC)
	(envelope-from kiri@truefc.org)
Received: from kx.truefc.org (kx.truefc.org [36.52.212.1])
       by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 21N7xJNM062398;
       Wed, 23 Feb 2022 16:59:19 +0900 (JST)
       (envelope-from kiri@kx.truefc.org)
Message-Id: <202202230759.21N7xJNM062398@kx.truefc.org>
Date: Wed, 23 Feb 2022 16:59:19 +0900
From: KIRIYAMA Kazuhiko 
To: Greg V 
Cc: KIRIYAMA Kazuhiko , x11@freebsd.org,
        freebsd-arm@freebsd.org
Subject: Re: Is there any X driver for Panfrost on PBP ?
In-Reply-To: 
References: <202202202226.21KMQQxG082376@kx.truefc.org>
	
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24)
 (Standard C) (amd64--freebsd)
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 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4K3T2p5fCjz4V0w
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org
X-Spamd-Result: default: False [-1.18 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.24)[-0.235];
	 FREEFALL_USER(0.00)[kiri];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[truefc.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.85)[-0.849];
	 MLMMJ_DEST(0.00)[freebsd-arm,x11];
	 RCVD_COUNT_ONE(0.00)[1];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ONCE_RECEIVED(0.10)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1668
Lines: 61

Hi, all

On Mon, 21 Feb 2022 09:06:49 +0900,
Greg V wrote:
>=20
>=20
>=20
> On February 21, 2022 1:26:26 AM GMT+03:00, KIRIYAMA Kazuhiko  wrote:
> >Hi, lists
>=20
> Hi,
>=20
> [..]
>=20
> >rk_drm0: Cannot find port with phandle 10
>=20
> (hopefully this one is harmless..)
>=20
> >But I could not found panfrot X driver. Is there any panfrost
> >X driver for FreeBSD ?
>=20
> Please forget about the notion of hardware specific X drivers and just ru=
n startx.
>=20
> There is *one* relevant X video driver =E2=80=93 xf86-video-modesetting =
=E2=80=93 and it is built in.
>=20
> (Ok, -amdgpu is somewhat relevant but that's just -modesetting with TearF=
ree hacks. Meanwhile -intel is a terrible pile of abandonware that mostly c=
auses problems.)
>=20

I've tested with benchmarks/glmark2 (glmark2-2021.12) both
GPU on and off. Results are alomost same ;-(

How to confirm to use builtin GPU ?

All logs are below :

1) PBP bootstrap log [1]
2) Non GPU Xorg.0.log [2]
3) Non GPU glmark2 run resukts [3]
4) With GPU Xorg.0.log [4]
5) With GPU glmark2 run resukts [5]

[1] http://www.truefc.org/~kiri/freebsd/pbp/PBP-boot_14.0-CURRENT-3f106af0c=
d92_panfrost
[2] http://www.truefc.org/~kiri/freebsd/pbp/Xorg.0.log_14.0-CURRENT-3f106af=
0cd92_Xorg-1.20.13_default
[3] http://www.truefc.org/~kiri/freebsd/pbp/glmark2_14.0-CURRENT-3f106af0cd=
92_Xorg-1.20.13_default
[4] http://www.truefc.org/~kiri/freebsd/pbp/Xorg.0.log_14.0-CURRENT-3f106af=
0cd92_Xorg-1.20.13_panfrost-modesetting
[5] http://www.truefc.org/~kiri/freebsd/pbp/glmark2_14.0-CURRENT-3f106af0cd=
92_Xorg-1.20.13_panfrost-modesetting

Best Regards

---
Kazuhiko Kiriyama 

From nobody Wed Feb 23 08:07:11 2022
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 915C719DFA1C;
	Wed, 23 Feb 2022 08:07:13 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mail.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 4K3TCh4zYMz4VxR;
	Wed, 23 Feb 2022 08:07:12 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1645603631;
	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=PAmPN+ELz6ySkWB31/Kms+go1klKn0dKC8LFY5VH0Yw=;
	b=Dhb8d3H+RWN5spb5hODU9vx0N564rM2ddes0zSRxfEovw+M2rYX9O/EdC05GMEla/s6ZYP
	95G+81uc2j8uLhyrw1AY2GJ9niufwb8ultdaeOh1R6gQQJz4OgGluxFiGy3cweEDvg8jou
	68x6ligq6yuLU1OwG8Ym+cOvN0jBd+k=
Received: from amy (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 35bf9587 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Wed, 23 Feb 2022 08:07:11 +0000 (UTC)
Date: Wed, 23 Feb 2022 09:07:11 +0100
From: Emmanuel Vadot 
To: KIRIYAMA Kazuhiko 
Cc: Greg V , x11@freebsd.org,
 freebsd-arm@freebsd.org
Subject: Re: Is there any X driver for Panfrost on PBP ?
Message-Id: <20220223090711.ad4be947236424c6fbbb83c1@bidouilliste.com>
In-Reply-To: <202202230759.21N7xJNM062398@kx.truefc.org>
References: <202202202226.21KMQQxG082376@kx.truefc.org>
	
	<202202230759.21N7xJNM062398@kx.truefc.org>
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-Rspamd-Queue-Id: 4K3TCh4zYMz4VxR
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=Dhb8d3H+;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-2.50 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[x11,freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2028
Lines: 71

On Wed, 23 Feb 2022 16:59:19 +0900
KIRIYAMA Kazuhiko  wrote:

> Hi, all
>=20
> On Mon, 21 Feb 2022 09:06:49 +0900,
> Greg V wrote:
> >=20
> >=20
> >=20
> > On February 21, 2022 1:26:26 AM GMT+03:00, KIRIYAMA Kazuhiko  wrote:
> > >Hi, lists
> >=20
> > Hi,
> >=20
> > [..]
> >=20
> > >rk_drm0: Cannot find port with phandle 10
> >=20
> > (hopefully this one is harmless..)
> >=20
> > >But I could not found panfrot X driver. Is there any panfrost
> > >X driver for FreeBSD ?
> >=20
> > Please forget about the notion of hardware specific X drivers and just =
run startx.
> >=20
> > There is *one* relevant X video driver ? xf86-video-modesetting ? and i=
t is built in.
> >=20
> > (Ok, -amdgpu is somewhat relevant but that's just -modesetting with Tea=
rFree hacks. Meanwhile -intel is a terrible pile of abandonware that mostly=
 causes problems.)
> >=20
>=20
> I've tested with benchmarks/glmark2 (glmark2-2021.12) both
> GPU on and off. Results are alomost same ;-(
>=20
> How to confirm to use builtin GPU ?
>=20
> All logs are below :
>=20
> 1) PBP bootstrap log [1]
> 2) Non GPU Xorg.0.log [2]
> 3) Non GPU glmark2 run resukts [3]
> 4) With GPU Xorg.0.log [4]
> 5) With GPU glmark2 run resukts [5]
>=20
> [1] http://www.truefc.org/~kiri/freebsd/pbp/PBP-boot_14.0-CURRENT-3f106af=
0cd92_panfrost
> [2] http://www.truefc.org/~kiri/freebsd/pbp/Xorg.0.log_14.0-CURRENT-3f106=
af0cd92_Xorg-1.20.13_default
> [3] http://www.truefc.org/~kiri/freebsd/pbp/glmark2_14.0-CURRENT-3f106af0=
cd92_Xorg-1.20.13_default
> [4] http://www.truefc.org/~kiri/freebsd/pbp/Xorg.0.log_14.0-CURRENT-3f106=
af0cd92_Xorg-1.20.13_panfrost-modesetting
> [5] http://www.truefc.org/~kiri/freebsd/pbp/glmark2_14.0-CURRENT-3f106af0=
cd92_Xorg-1.20.13_panfrost-modesetting
>=20
> Best Regards
>=20
> ---
> Kazuhiko Kiriyama 
>=20

 That's probably because we don't build the panfrost mesa driver so you
end up using llvmpipe in both case.

--=20
Emmanuel Vadot  

From nobody Wed Feb 23 09:48:18 2022
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 5E4CF19CF9D1
	for ; Wed, 23 Feb 2022 09:48:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536])
	(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 4K3WSj43B4z4gNh
	for ; Wed, 23 Feb 2022 09:48:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x536.google.com with SMTP id h15so26212658edv.7
        for ; Wed, 23 Feb 2022 01:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=Djf7Tt9E10BejD/1rUGaWX+PZLKygEsEG5sZsQBoM1Y=;
        b=S0D8hbS9hkwi3aueKl1lKmEbMtFsUpxoPOAwD9fETC5YHSMxGY92xBlU84RXe1I0tj
         ryY7MtwGu5imimqZVP7ximVz6UgNRgM2ZP7AjU7tr7el9DFAX4CcPHZwZO9KvhzE/wzF
         IpKi1ogm2q9EZgqE0uVCxK0l6GMU1LSnLJI9scDOnlk3LlbFWDfPuzqIeKe+wEE9rAC8
         pyTDfg3NivTmxe85msUZQji3U8jFaf/RBS8UGU1jykbD0QQ/a3QRXrCz1PXTPuOy+s1R
         22pEl2jcmxLcDlZ+hisNbciguPOE5aE6IvwYD6z7CYWys2TMEXydL6m9xYDEmieprr30
         7dYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=Djf7Tt9E10BejD/1rUGaWX+PZLKygEsEG5sZsQBoM1Y=;
        b=ELufk2h20nGYUR/jB+LuPJ1iZ74jUVZQOw4EE5AILDon9As9WBZP65/L/KWAYZbZVL
         JieKN0m9nssFctuCx68vO5uvSUjrF0EdKZAxFj7NvNmqjj9T1y1bKnzJUAHBKrlkC4d0
         R+MG1kc31Uuf73KgVNUAwZhbyElKFTpuoXYrop31CPj7hL2A0pWuzR09/zFMTixp1Uva
         tOJvMhk05sFIVZUI7dOQes9Uv6TgAITdknKBXE7rDagCpwXyNxD9fMM0wi8DWV/7ZW86
         tVXCeHX74SLbReIkY9x1gcSKZwKT3XHxtTFOMVOVd01/YN7SmqoYMVxFyI0wlkyqB0Fu
         viiQ==
X-Gm-Message-State: AOAM5332kdS4IMlxPYa8jakPm1AJqHZVao92JOvw00H5p45Alt6UKAEy
	OEHhw8bciMcc757Zk4V1hBgik3r+joGA5HT0rxMrJb/TpEprdg==
X-Google-Smtp-Source: ABdhPJzpU653XJsx5v4YSyOsHp7QOrdaUCbhNx7iCkiiQzVarn3C8LEYiQnqslXLtfCTVStZe33FuvYwgS9sj8LQayA=
X-Received: by 2002:a50:8e44:0:b0:40f:d71f:bdf5 with SMTP id
 4-20020a508e44000000b0040fd71fbdf5mr30977435edx.166.1645609709555; Wed, 23
 Feb 2022 01:48:29 -0800 (PST)
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
From: Archimedes Gaviola 
Date: Wed, 23 Feb 2022 17:48:18 +0800
Message-ID: 
Subject: Raspberry Pi Serial Number
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000002d541c05d8ac5ec8"
X-Rspamd-Queue-Id: 4K3WSj43B4z4gNh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=S0D8hbS9;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1240
Lines: 32

--0000000000002d541c05d8ac5ec8
Content-Type: text/plain; charset="UTF-8"

Hi,

How to obtain the RPi serial number? I'm checking sysctl info but there
seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such as:

Hardware        : BCM2835
Revision        : b03112
Serial          : 10000000bc8a56a3
Model           : Raspberry Pi 4 Model B Rev 1.2

Thanks,
Archimedes

--0000000000002d541c05d8ac5ec8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

How to obtain the RPi se=
rial number? I'm checking sysctl info but there seems to be none with F=
reeBSD-13.0-RELEASE and 14.0-CURRENT or I just missed it somewhere? In Cent=
OS it is reflected in the /proc/cpuinfo such as:

H=
ardware =C2=A0 =C2=A0 =C2=A0 =C2=A0: BCM2835
Revision =C2=A0 =C2=A0 =C2=
=A0 =C2=A0: b03112
Serial =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 10000000bc=
8a56a3
Model =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Raspberry Pi 4 Model B=
 Rev 1.2

Thanks,
Archimedes



--0000000000002d541c05d8ac5ec8--

From nobody Wed Feb 23 10:14:49 2022
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 18FE419D5387
	for ; Wed, 23 Feb 2022 10:14:58 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4K3X356fTCz4kTb;
	Wed, 23 Feb 2022 10:14:57 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1645611298;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=b10NMBwH21MHCn/NnQV8yPu0+uF3erlILXgx25606Mc=;
	b=p5ZXRDWAObTB/nJJXosvzP8tTiiqG0Iqzeu5N89ci0+8UUMM6VUZWpnP2dQzomOnxorExZ
	10Spe5/0qXb/CALWIIvb3UyoUbUsjlyY3s0vNozG7H804yNTi76hjN84q/50+s4HPwI+Ex
	l+WhSkKuw6lwGURSRok73e9nMY4VGPnl3F2wPWaLzwdtRgeyb9yHW0iCCTweH2vG8eOscF
	nWDXlkiZHpd+6iV6XFfKNh464D5tLi9py+TTyCtWbGbUclieFL1pd75Z0e7WrG5PGObChs
	lKpzEkfxFN/iftD5Tv2osQfH6LSSJ6/gjioMynzE4YoJSJw9XH1rf8pMTUZnmQ==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id B72072B7A8;
	Wed, 23 Feb 2022 10:14:56 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Wed, 23 Feb 2022 21:14:49 +1100
From: Peter Jeremy 
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
Subject: Re: Raspberry Pi Serial Number
Message-ID: 
References: 
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="CpAFE7VuugNAXIPK"
Content-Disposition: inline
In-Reply-To: 
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645611298;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=b10NMBwH21MHCn/NnQV8yPu0+uF3erlILXgx25606Mc=;
	b=QSJNmLilZx3GU3u//FGc8whzBfw/BLs1JcFH5sYKTGsDEJXKT2ZqQYOxhkOOwt/hdBnjyV
	Pf+53MOg1g+bzhpid0/XQdHWIJpm0yUzYjppCFS64bYahJfWig8aED8PhbW2/pi0IXy9rF
	94IL9NLmFQ92tCAg0KmlaZgI8RhtYCrFvYR9Mkjy2nUSBTwNyONPtFvs5I+2k3+y2dEEFG
	8+kiglj2PWQ7B3KZHHyurEJ6Bp/w1+D5gEZn76QcZP6vCxseChpGupk/KMYQPc+ULQf+CJ
	PjOdMDTdnlQQy8Rz/e3h7GJwmq7eXYlr40Owtbtn7eeSdWCkKWLwx0oy/WxWng==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645611298; a=rsa-sha256; cv=none;
	b=S5YUkirdnMFzJofEwDl3IM53l8Y5C9q3zhVGS23bI6iQf6LXsixmY2P1w7Pcr3DjFVbPja
	niUSElTooa0ArYeywnO+f97Xc1j8BI+uvMsm2I70FUM0oGXbn+ouc6GKGgbyekcaLQmZVi
	uCTEkITj8/GFvTytyWKRwrlQjlcdXnE5Ra60NzPnbjMltV92yd9SzHYK6VKk5Kk0SO7WQi
	sD5Zb3hCqiDmc0qccdA2I4Bj4xgd3n4mv+V69u9c8tgqswYVQg7AS/d+/D5vZLOPQo/p3V
	q4PchPVEztSM0noSQRjNfrd9Qb69W9WKgLPB16NPuyIyDH/YH/wQYT1dcQWFOA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1844
Lines: 50


--CpAFE7VuugNAXIPK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-Feb-23 17:48:18 +0800, Archimedes Gaviola  wrote:
>How to obtain the RPi serial number? I'm checking sysctl info but there
>seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
>missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such a=
s:
>
>Hardware        : BCM2835
>Revision        : b03112
>Serial          : 10000000bc8a56a3
>Model           : Raspberry Pi 4 Model B Rev 1.2

I don't have a RPi4 but at least on my RPi2, the data appears to
be in sysctl:
hw.board.serial: 00000000d206f16c
hw.board.revision: 10620993
hw.platform: bcm2836

--=20
Peter Jeremy

--CpAFE7VuugNAXIPK
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKSBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmIWCRRfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzQLBg/1GSyNnyfjeUkbGujt4Td3KjkXllchrFrp/F+whH/hwv6JPGdOBB7Siyyr
6Bion7FAMVSusYLk7k2gjW5hOJ7c9g94UgP1Pp7b30kUJ+ca+5RiuHKp+2ou3YUB
zk06A34EAkAf6Cb9OEEqXgVGa5/DTmiP9GCJRyymbV0duixCVNMBCpHfOp8fB0+X
jZr8Je03TlKGGRYHjABR3d3IPqtDrLjH67owJ/W5JFWcIXu36T/07n4oED90aAP3
/bOrw9plN6Ts3IRXAXqrpseuz47wfyRD22ILf88f/HVmjCG57shUO1eVxdj73ZAi
d1DU5ldsr8G+76rJiPnOPB2lpd7NjWyHPBar4LEc+zr1jp4WQM7uYzypkq7aAK1l
6E+09WUEzxQo2n5ZRA6UgurkIcGds459RX/XYDd1LIBPcBa691kKsa4Lit76ucE8
9TGgy9QUtCQ7QrZ/QI4ae2E99VmyQ4CYb4oUvElUZ+6JrsuDbRcpLnizvMMlCrKb
6trkKe6azLwJGQ3EvO7AFK1L4ZTTg6iwv+SBqcK3di3a9E8NYFFBnGXK1wNq5U49
rYgVoCG/QJ9z4EyL/qTLJD/+GRjQ5We3jQN92xCWH1TJf9yoC9RCU0UZ39fHh9Uu
BrgUITjBM44vwO3vOpwxgP13xn4HXOZnjjX1G19tFV3FHRTDeQ==
=jatk
-----END PGP SIGNATURE-----

--CpAFE7VuugNAXIPK--

From nobody Wed Feb 23 10:23:03 2022
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 7836E19D6CA6
	for ; Wed, 23 Feb 2022 10:23:12 +0000 (UTC)
	(envelope-from SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K3XDb2zVdz4md6
	for ; Wed, 23 Feb 2022 10:23:11 +0000 (UTC)
	(envelope-from SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl)
Date: Wed, 23 Feb 2022 11:23:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1645611783;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=tKQByMh9ZgEzRd5EAqNzW7o6v3SuQH0xFW4tNZdP6mk=;
	b=Tp1FBiUpgD0lgbeGQQuLPKHOBnBXLtnZL/m5dXPkVHor6YMJqTe7BJI4OMNjleHrlknUxz
	tQHl6F3I3hfLawTtQVGmF+bsYcRerILavse2pzPlL6cgUKnLUk4VdDmAjs6KNZeLCFrYwn
	Cyb2u7Cm9lrXgb+eWe/xs1Wi6ch48imeMgbWKUgFzUZroHooJAwnduBpmxF1stgzphuN57
	sY4OjwfU6QuqoMC1Gq1LpogoKFBoU/G0TSdptxXgLcGEd3drcYzdkkztzzh2BS9Qsy28pt
	8CH1vXBoOp6YZD7/i/ilEQGFerBkcsGZrG5QIr8wJCaptXw3PU1kcSjGc09Waw==
From: Ronald Klop 
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
Message-ID: <722278586.24.1645611783398@mailrelay>
In-Reply-To: 
References: 
Subject: Re: Raspberry Pi Serial Number
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="----=_Part_23_1278155202.1645611783387"
X-Mailer: Realworks (597.138.6f75bd0)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4K3XDb2zVdz4md6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=Tp1FBiUp;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=V7EQ=TG=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2967
Lines: 94

------=_Part_23_1278155202.1645611783387
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Is that this number?

[root@rpi4 ~]# ofwdump -p -a | head
Node 0x48:
  memreserve:
    3b 30 00 00 04 c0 00 00
  serial-number:
    31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
    '10000000649521a0'
  compatible:
    72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
    62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
  model:


 
Van: Archimedes Gaviola 
Datum: woensdag, 23 februari 2022 10:48
Aan: freebsd-arm@freebsd.org
Onderwerp: Raspberry Pi Serial Number
> 
> Hi,
>  
> How to obtain the RPi serial number? I'm checking sysctl info but there seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such as:
>  
> Hardware        : BCM2835
> Revision        : b03112
> Serial          : 10000000bc8a56a3
> Model           : Raspberry Pi 4 Model B Rev 1.2
>  
> Thanks,
> Archimedes
>  

------=_Part_23_1278155202.1645611783387
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is that this number?



[root@rpi4 ~]# ofwdump -p -a | head

Node 0x48:

  memreserve:

    3b 30 00 00 04 c0 00 00

  serial-number:

    31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00

    '10000000649521a0'

  compatible:

    72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d

    62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00

  model:





 

Van: Archimedes Gaviola <archimedes.gaviola@gmail.com>

Datum: woensdag, 23 februari 2022 10:48

Aan: freebsd-arm@freebsd.org

Onderwerp: Raspberry Pi Serial Number













Hi,



 



How to obtain the RPi serial number? I'm checking sysctl info but there seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such as:



 



Hardware        : BCM2835

Revision        : b03112

Serial          : 10000000bc8a56a3

Model           : Raspberry Pi 4 Model B Rev 1.2



 



Thanks,



Archimedes



 











------=_Part_23_1278155202.1645611783387--

From nobody Wed Feb 23 10:39:40 2022
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 291DE19D9275
	for ; Wed, 23 Feb 2022 10:39:53 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4K3Xbr2B6jz4nrp
	for ; Wed, 23 Feb 2022 10:39:52 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id vz16so51511400ejb.0
        for ; Wed, 23 Feb 2022 02:39:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=bscv1hILTJ2uEZLkivVPZS5AVW3cCAObzAwO/RK6dEk=;
        b=qsaKbOvsbeVIuFgCy08pKyV62Q7GoACnan4x5Anw8ZBC5dqTF02Av2WiSGa1W4pxxc
         U0r7OoHYWpiaoQCecn9np7V6rOUmikmUy+BaEeVk1nPgu1qyWIjKl2XjNZSeUMrDRJmU
         Z9NPigv5Z6l3XSwkXce+CruUFt4UsBMR7I6eJ6i8hRJ5pHVctePIVgyyhVd+96LupgCU
         d4phS2YAIQ44zLmOvnYrHOy+cjeGdGI6jcTKq2ZZj8T9UxYCU/I4xrpK5hCxWsgMOyds
         RhrWAxbPCAikMubDzxQssO0RHEYwTbEv3dVoIoKbejC2qjN012bRd7CehP42k6gCc1nD
         eLVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=bscv1hILTJ2uEZLkivVPZS5AVW3cCAObzAwO/RK6dEk=;
        b=xEP5Ei+NcdfJ4Xh8q7TXGgr86T2hKmay2ji6Q3mBNSwsAh7m1DWNK5pBykoX1CbQnp
         O8kYW9PlRWGT9VN6p3lMSrxj2dv/GfajXDJhoN6IalXMStj9YIEud9EpvyXUyRbRBqtQ
         lHHvtSVV6A2E4yLrV2iDBPauf3mdtk5MWYGdjk3CW+i/akfJ/juv8dmp5qxSI+m36Yjo
         k3RBWiX+uOtbN0A0qZ+/irDNtqJpcekLn/403AgYMC0wzcTSKLP0ahVZO7+CWfiJ2dLh
         sJcQz/SMSv+eatGdIPvGxyODurTSy3ZDb8d7uHpHDGQkbY3e/I3RQmOKFrL/5Zjj11fh
         xgCg==
X-Gm-Message-State: AOAM531qh68LJyx34Genq1ebZ30B8gw+7BvAcUGGnQjFj2UCVStmKVh4
	ireS2quaEMAnUijTugW5a4bY2CYg4qa7FlRhH0ba5BuSV/gASQ==
X-Google-Smtp-Source: ABdhPJykkNvJTZuNlRGFbTCXBvcA9S/dDTyEBWKz27RDsZ0bKdbpGFUH3zABz2F5u4nhmSRHIjB1Lq5tQsCwTF+Kfo8=
X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id
 b17-20020a1709063cb100b006ce2a975ademr22284145ejh.728.1645612791167; Wed, 23
 Feb 2022 02:39:51 -0800 (PST)
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: 
 <722278586.24.1645611783398@mailrelay>
In-Reply-To: <722278586.24.1645611783398@mailrelay>
From: Archimedes Gaviola 
Date: Wed, 23 Feb 2022 18:39:40 +0800
Message-ID: 
Subject: Re: Raspberry Pi Serial Number
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000daff1105d8ad1536"
X-Rspamd-Queue-Id: 4K3Xbr2B6jz4nrp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qsaKbOvs;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2358
Lines: 66

--000000000000daff1105d8ad1536
Content-Type: text/plain; charset="UTF-8"

On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop  wrote:

> Is that this number?
>
> [root@rpi4 ~]# ofwdump -p -a | head
> Node 0x48:
>   memreserve:
>     3b 30 00 00 04 c0 00 00
>   serial-number:
>     31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
>     '10000000649521a0'
>   compatible:
>     72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
>     62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
>   model:
>
>
I believe so Ronald as it matches the serial number from my CentOS in the
same hardware.

root@generic:~ # ofwdump -p -a | head
Node 0x48:
  memreserve:
    3b 40 00 00 04 c0 00 00
  serial-number:
    31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
    '10000000bc8a56a3'

Thanks,
Archimedes

--000000000000daff1105d8ad1536
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Feb 23, 2022 at 6:23 PM Ronal=
d Klop <ronald-lists@klop.ws=
> wrote:
Is that this number?



[root@rpi4 ~]# ofwdump -p -a | head

Node 0x48:

=C2=A0 memreserve:

=C2=A0=C2=A0=C2=A0 3b 30 00 00 04 c0 00 00

=C2=A0 serial-number:

=C2=A0=C2=A0=C2=A0 31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00

=C2=A0=C2=A0=C2=A0 '10000000649521a0'

=C2=A0 compatible:

=C2=A0=C2=A0=C2=A0 72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c=
 2d

=C2=A0=C2=A0=C2=A0 62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00

=C2=A0 model:



I believe so Ronald as it matche=
s the serial number from my CentOS in the same hardware.

=

root@generic:~ # ofwdump -p -a | head
Node 0x48:
=C2=A0 me=
mreserve:
=C2=A0 =C2=A0 3b 40 00 00 04 c0 00 00
=C2=A0 serial-number:=

=C2=A0 =C2=A0 31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
=C2=
=A0 =C2=A0 '10000000bc8a56a3'

Thanks,
Archimedes



--000000000000daff1105d8ad1536--

From nobody Wed Feb 23 10:42:45 2022
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 7AD0C19DA582
	for ; Wed, 23 Feb 2022 10:43:04 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c])
	(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 4K3XgW6FDCz4pdJ;
	Wed, 23 Feb 2022 10:43:03 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52c.google.com with SMTP id x5so43334084edd.11;
        Wed, 23 Feb 2022 02:43:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=e466M6/kSK1xD+CeP6kLAOD+Q70wJoGGhZMmKaiUOX0=;
        b=RlzdwutIte0MHtoaBdwyQhd7t9CohEYNjbx9aUviOmCiakDw+MFXz3yRw1JK4X9HvG
         3g+iF3IRnNchXbF0lcqgCqyVtcARhy6KCimUzOsQOCAcj75F3R9Frh/XuNxoLRTKBiog
         9nfPfrpnaSrRrNA8ekCuoWM21sEJ086hIiMzqKEeWt8OkHLSxJjns+Qh/dqjfUoskZh/
         b9Ob4tC8qovxtL3D/2Z+m3PmRDO35oMpHP2dSHmZ6tf06whSHaCrvq2unFeRNRc2zX7S
         gaetPnHai5fvTRpDNUr8PmXTIYHOSBKnmjFWH1Qrt67ifbM56r/OOnMzabGa3IaLC253
         BFsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=e466M6/kSK1xD+CeP6kLAOD+Q70wJoGGhZMmKaiUOX0=;
        b=u8mPSqUqJ7O5Pbmt56dOlGXPOF+IM76MCb+f4rrNHujq5LYpnfcNcNXFbISZZaj9lv
         EAg6Jr5xqAw90Jn8Q+IPsvT0EzqwbASrVMbkXZIVRTWnyXQG8eaVJpabqzrTE4AkCPG7
         sbw98uQwdN3jv5BXkT5nnpmZAKjUB5fgghPnDfsurX3CuEQhoE3K009fFjbbNiG7RrIz
         StpuSh3z3YiNV8Jb5EamFYmt+3GmB8zj/g1yv5xyxn9r3arzuChZnWKoKOf+KDSGLh5J
         U/FZLfaIYg6HLPLzkaVdjFgOGs6R4oQuWMPLanOOSlQu/e+lu/dgjEs+z3KscR51De1G
         eF3A==
X-Gm-Message-State: AOAM53263HALKUgObX5gzvFPiVjOE9HVXK59LV38iC9bJtL30Livp/eA
	+aDLN2Tx6Ge+a5n6AB9yZw7RJTWJSW79kXOMhu+iie97iEs=
X-Google-Smtp-Source: ABdhPJwDPEbuJpG0nIbtUl8rdUpPiUVTNhOW7UJ411I9BZc3KaJsiCnr3zs74PAbHzO+2bd5nU238BtyrIhISEAOEoE=
X-Received: by 2002:a05:6402:369c:b0:413:2bc0:3f00 with SMTP id
 ej28-20020a056402369c00b004132bc03f00mr5524913edb.126.1645612976653; Wed, 23
 Feb 2022 02:42:56 -0800 (PST)
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: Archimedes Gaviola 
Date: Wed, 23 Feb 2022 18:42:45 +0800
Message-ID: 
Subject: Re: Raspberry Pi Serial Number
To: Peter Jeremy 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e9475f05d8ad208d"
X-Rspamd-Queue-Id: 4K3XgW6FDCz4pdJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=RlzdwutI;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2574
Lines: 63

--000000000000e9475f05d8ad208d
Content-Type: text/plain; charset="UTF-8"

On Wed, Feb 23, 2022 at 6:14 PM Peter Jeremy  wrote:

> On 2022-Feb-23 17:48:18 +0800, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >How to obtain the RPi serial number? I'm checking sysctl info but there
> >seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
> >missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such
> as:
> >
> >Hardware        : BCM2835
> >Revision        : b03112
> >Serial          : 10000000bc8a56a3
> >Model           : Raspberry Pi 4 Model B Rev 1.2
>
> I don't have a RPi4 but at least on my RPi2, the data appears to
> be in sysctl:
> hw.board.serial: 00000000d206f16c
> hw.board.revision: 10620993
> hw.platform: bcm2836
>

Thanks Peter, I'm wondering why there's no such output in sysctl with RPi4?

Archimedes

--000000000000e9475f05d8ad208d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Feb 23, 2022 at 6:14 PM Peter=
 Jeremy <peterj@freebsd.org>=
; wrote:
On 2022=
-Feb-23 17:48:18 +0800, Archimedes Gaviola <archimedes.gaviola@gmail.com> =
wrote:

>How to obtain the RPi serial number? I'm checking sysctl info but t=
here

>seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
>missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo suc=
h as:

>

>Hardware=C2=A0 =C2=A0 =C2=A0 =C2=A0 : BCM2835

>Revision=C2=A0 =C2=A0 =C2=A0 =C2=A0 : b03112

>Serial=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 10000000bc8a56a3

>Model=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Raspberry Pi 4 Model B =
Rev 1.2



I don't have a RPi4 but at least on my RPi2, the data appears to

be in sysctl:

hw.board.serial: 00000000d206f16c

hw.board.revision: 10620993

hw.platform: bcm2836

<=
/div>
Thanks Peter, I'm wondering why there&#=
39;s no such output in sysctl with RPi4?
Archimedes


--000000000000e9475f05d8ad208d--

From nobody Wed Feb 23 10:52:56 2022
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 6079F19DC295
	for ; Wed, 23 Feb 2022 10:53:05 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mail.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 4K3Xv36b0Qz4qV6;
	Wed, 23 Feb 2022 10:53:03 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1645613576;
	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=NW0hfXQToIgOgLkXVvBsuIWMNweiU1UMicV11b+xy+s=;
	b=tZYQ3MzEUVulmegOFQdMgIxVD43+4OPxc4+4NEJnzQ/ISMcP7sM8YSZ1cdjpDmQ+WUGu2p
	gzx7c7x93ZrBcZTTfGpBlOH3ptaec1JIEfuQUAoxEG+vyD6YobkHhRkmaM8baeGJg6rm4m
	pcjpwoRgSkc6z2F4DabVYQdLSV5n140=
Received: from skull.home.blih.net (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 3e213c6b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Wed, 23 Feb 2022 10:52:56 +0000 (UTC)
Date: Wed, 23 Feb 2022 11:52:56 +0100
From: Emmanuel Vadot 
To: Archimedes Gaviola 
Cc: Peter Jeremy , freebsd-arm@freebsd.org
Subject: Re: Raspberry Pi Serial Number
Message-Id: <20220223115256.6d67ebda1b8a7ddb52105d98@bidouilliste.com>
In-Reply-To: 
References: 
	
	
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: 4K3Xv36b0Qz4qV6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=tZYQ3MzE;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1422
Lines: 39

On Wed, 23 Feb 2022 18:42:45 +0800
Archimedes Gaviola  wrote:

> On Wed, Feb 23, 2022 at 6:14 PM Peter Jeremy  wrote:
> 
> > On 2022-Feb-23 17:48:18 +0800, Archimedes Gaviola <
> > archimedes.gaviola@gmail.com> wrote:
> > >How to obtain the RPi serial number? I'm checking sysctl info but there
> > >seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
> > >missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo such
> > as:
> > >
> > >Hardware        : BCM2835
> > >Revision        : b03112
> > >Serial          : 10000000bc8a56a3
> > >Model           : Raspberry Pi 4 Model B Rev 1.2
> >
> > I don't have a RPi4 but at least on my RPi2, the data appears to
> > be in sysctl:
> > hw.board.serial: 00000000d206f16c
> > hw.board.revision: 10620993
> > hw.platform: bcm2836
> >
> 
> Thanks Peter, I'm wondering why there's no such output in sysctl with RPi4?
> 
> Archimedes

 Because those sysctls are only added on armv7 if u-boot passed some
linux boot argument, see
https://cgit.freebsd.org/src/tree/sys/arm/arm/machdep_boot.c#n91

 The proper way to handle those is to add them under hw.fdt like I did
for model and compatible property in
https://cgit.freebsd.org/src/commit/?id=50e0dc0c4b46ee62b898ce2d92e52be4f77383d9
 but I don't think that those are standard properties.

-- 
Emmanuel Vadot  

From nobody Wed Feb 23 11:31:22 2022
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 895D219E3BDD
	for ; Wed, 23 Feb 2022 11:31:41 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e])
	(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 4K3Ylc5z6Kz3D6W;
	Wed, 23 Feb 2022 11:31:40 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52e.google.com with SMTP id g20so1790276edw.6;
        Wed, 23 Feb 2022 03:31:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=NHK9km3Rje5xGoNOLNsEATG/RFQYbLQvjevZE/OgjTY=;
        b=KWQcffBZfQnam0n+5FMRwJ2cP5doVPp8nxvF3kW2vmOX3a5pEgBt38sLe6LpZY0rSV
         TjtYTLnp6MHO+99NXVsEJCtOpr0FybxEn2y6oxd3yihGdXXQ35Lsv+aPfA5HmWoMHvre
         ICGul4KThOG9v4B5G1r+X/twXxWpgaU97/L4L3teJXAfpMm9JUI6OHW9L3tROnSvtrie
         HRehd7Ks/qb7tptP0FLrqwRSfwUhw40aOgaGHNV2F0fkW9NlaxORgLixGVMuZWcwdgC9
         S+v9CqP1MtnDgwyJ7AdBof6wMevznvfTvvHXzIYPGbQ059W3Qlssf0ZTZFSobMwEAaFX
         9Svw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=NHK9km3Rje5xGoNOLNsEATG/RFQYbLQvjevZE/OgjTY=;
        b=yHLVMJrBV/QtXP1EX005J5V/DBZX9bVlfoaLuUlxALpBbr4TVyphOmG0p+vI//Kpxc
         AUviY2QaIsLjHPXAkqIO5RnREXXY5FnYSHfpNE3K1wz9w4nA1VyRl0GXKQYXJt18eQ2c
         tUsjAEDTwTsotA4ajAFC4GObbTBxokpS0RCYE1CLc//YRd6sfoP6FC4kP9EcApva1uAF
         F40ie6ICr1MeXCUXMfdrW5rY8I4fvj6GdxjScxTADJOCZrDdjB7w7Yepi6jiSl1m6PZY
         eGjL0Yd6MhGBSO8ny1JD249EBWHi1VQ5Qb7RPax7xOD7WwI4m4nGkwMchOpOYbNKy1xL
         3dFw==
X-Gm-Message-State: AOAM532P7sXRCQEtKzTgeJ1sH99p2ybPVNU8/y1ZbXYIaC1U2r6b5lfB
	LFiyXgaXRWYMfQF2fE6R2zX3fWX8Ylzkbr0h6fKInFIE48Dt1A==
X-Google-Smtp-Source: ABdhPJxiZq2KrbaV9UTNDwv1NtvCcbCSeMcB71WRdUJnuKVTHmbdQn752TzX5nZB6W7KOo6fkpJ8MVGrtN5KGLOosUs=
X-Received: by 2002:aa7:d80f:0:b0:410:d5c3:f770 with SMTP id
 v15-20020aa7d80f000000b00410d5c3f770mr30975573edq.279.1645615894167; Wed, 23
 Feb 2022 03:31:34 -0800 (PST)
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: 
  
 <20220223115256.6d67ebda1b8a7ddb52105d98@bidouilliste.com>
In-Reply-To: <20220223115256.6d67ebda1b8a7ddb52105d98@bidouilliste.com>
From: Archimedes Gaviola 
Date: Wed, 23 Feb 2022 19:31:22 +0800
Message-ID: 
Subject: Re: Raspberry Pi Serial Number
To: Emmanuel Vadot 
Cc: Peter Jeremy , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000cf050a05d8adce3e"
X-Rspamd-Queue-Id: 4K3Ylc5z6Kz3D6W
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=KWQcffBZ;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5417
Lines: 134

--000000000000cf050a05d8adce3e
Content-Type: text/plain; charset="UTF-8"

On Wed, Feb 23, 2022 at 6:52 PM Emmanuel Vadot 
wrote:

> On Wed, 23 Feb 2022 18:42:45 +0800
> Archimedes Gaviola  wrote:
>
> > On Wed, Feb 23, 2022 at 6:14 PM Peter Jeremy  wrote:
> >
> > > On 2022-Feb-23 17:48:18 +0800, Archimedes Gaviola <
> > > archimedes.gaviola@gmail.com> wrote:
> > > >How to obtain the RPi serial number? I'm checking sysctl info but
> there
> > > >seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT or I just
> > > >missed it somewhere? In CentOS it is reflected in the /proc/cpuinfo
> such
> > > as:
> > > >
> > > >Hardware        : BCM2835
> > > >Revision        : b03112
> > > >Serial          : 10000000bc8a56a3
> > > >Model           : Raspberry Pi 4 Model B Rev 1.2
> > >
> > > I don't have a RPi4 but at least on my RPi2, the data appears to
> > > be in sysctl:
> > > hw.board.serial: 00000000d206f16c
> > > hw.board.revision: 10620993
> > > hw.platform: bcm2836
> > >
> >
> > Thanks Peter, I'm wondering why there's no such output in sysctl with
> RPi4?
> >
> > Archimedes
>
>  Because those sysctls are only added on armv7 if u-boot passed some
> linux boot argument, see
> https://cgit.freebsd.org/src/tree/sys/arm/arm/machdep_boot.c#n91
>
>  The proper way to handle those is to add them under hw.fdt like I did
> for model and compatible property in
>
> https://cgit.freebsd.org/src/commit/?id=50e0dc0c4b46ee62b898ce2d92e52be4f77383d9
>  but I don't think that those are standard properties.
>
> --
> Emmanuel Vadot  
>

Oh I see, that explains thanks Emmanuel! It's alright just stick to the
standard properties because in my case as long as I can obtain the serial
number in any other way like the ofwdump tool I'm already satisfied. For
some reason, I need the serial number for system identification.

Thanks,
Archimedes

--000000000000cf050a05d8adce3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Feb 23, 2022 at 6:52 PM Emman=
uel Vadot <manu@bidouilliste.co=
m> wrote:
On Wed, 23 Feb 2022 18:42:45 +0800

Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



> On Wed, Feb 23, 2022 at 6:14 PM Peter Jeremy <peterj@freebsd.org> wrote:

> 

> > On 2022-Feb-23 17:48:18 +0800, Archimedes Gaviola <

> > archimedes.gaviola@gmail.com> wrote:

> > >How to obtain the RPi serial number? I'm checking sysctl =
info but there

> > >seems to be none with FreeBSD-13.0-RELEASE and 14.0-CURRENT o=
r I just

> > >missed it somewhere? In CentOS it is reflected in the /proc/c=
puinfo such

> > as:

> > >

> > >Hardware=C2=A0 =C2=A0 =C2=A0 =C2=A0 : BCM2835

> > >Revision=C2=A0 =C2=A0 =C2=A0 =C2=A0 : b03112

> > >Serial=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 10000000bc8a56a3
> > >Model=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Raspberry Pi =
4 Model B Rev 1.2

> >

> > I don't have a RPi4 but at least on my RPi2, the data appears=
 to

> > be in sysctl:

> > hw.board.serial: 00000000d206f16c

> > hw.board.revision: 10620993

> > hw.platform: bcm2836

> >

> 

> Thanks Peter, I'm wondering why there's no such output in sysc=
tl with RPi4?

> 

> Archimedes



=C2=A0Because those sysctls are only added on armv7 if u-boot passed some
linux boot argument, see

https://cgit.freebsd.org/src/tree/sy=
s/arm/arm/machdep_boot.c#n91



=C2=A0The proper way to handle those is to add them under hw.fdt like I did=


for model and compatible property in

https://cgit.freeb=
sd.org/src/commit/?id=3D50e0dc0c4b46ee62b898ce2d92e52be4f77383d9

=C2=A0but I don't think that those are standard properties.



-- 

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

Oh I see, that explains thanks Emmanuel! It's alright just stick to t=
he standard properties because in my case as long as I can obtain the seria=
l number in any other way like the ofwdump

tool I'm already satisfied. For some reason, I need the serial number f=
or system identification.

Thanks,
Archim=
edes=C2=A0 


--000000000000cf050a05d8adce3e--

From nobody Wed Feb 23 16:44:49 2022
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 D8FB519DBF81
	for ; Wed, 23 Feb 2022 16:45:04 +0000 (UTC)
	(envelope-from carlj@peak.org)
Received: from smtp.email-protect.gosecure.net (smtp.email-protect.gosecure.net [208.80.203.2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
	(Client CN "*.email-protect.gosecure.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K3hjD0lP5z4pGx
	for ; Wed, 23 Feb 2022 16:45:03 +0000 (UTC)
	(envelope-from carlj@peak.org)
Received: from envoy14.neonova.net ([137.118.58.100])
          by smtp.email-protect.gosecure.net ({0ea43f3c-8644-11ec-bfc3-ad14e99bfaf7})
          via TCP (outbound) with ESMTP id 20220223164454863_00004584
          for ;
          Wed, 23 Feb 2022 08:44:54 -0800
X-RC-FROM: 
X-RC-RCPT: 
Received: from bay.localnet (unknown [199.58.99.76])
	(Authenticated sender: carlj@peak.org)
	by envoy14.neonova.net (Postfix) with ESMTPA id 4K3hhy5DMWz9sxV
	for ; Wed, 23 Feb 2022 11:44:50 -0500 (EST)
Received: from carlj by bay.localnet with local (Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1nMukz-0002Va-GO
	for freebsd-arm@freebsd.org;
	Wed, 23 Feb 2022 08:44:49 -0800
From: Carl Johnson 
To: freebsd-arm@freebsd.org
Subject: Re: Raspberry Pi Serial Number
References: 
	<722278586.24.1645611783398@mailrelay>
	
Date: Wed, 23 Feb 2022 08:44:49 -0800
In-Reply-To: 
	(Archimedes Gaviola's message of "Wed, 23 Feb 2022 18:39:40 +0800")
Message-ID: <86ee3t3532.fsf@bay.localnet>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix)
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
X-MAG-OUTBOUND: greymail.email-protect.gosecure.net@137.118.58.100/32
X-Rspamd-Queue-Id: 4K3hjD0lP5z4pGx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=peak.org;
	spf=pass (mx1.freebsd.org: domain of carlj@peak.org designates 208.80.203.2 as permitted sender) smtp.mailfrom=carlj@peak.org
X-Spamd-Result: default: False [-3.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:208.80.200.0/21];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[peak.org,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14618, ipnet:208.80.202.0/23, country:US];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 946
Lines: 36

Archimedes Gaviola  writes:

> On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop  wrote:
>
>> Is that this number?
>>
>> [root@rpi4 ~]# ofwdump -p -a | head
>> Node 0x48:
>>   memreserve:
>>     3b 30 00 00 04 c0 00 00
>>   serial-number:
>>     31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
>>     '10000000649521a0'
>>   compatible:
>>     72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
>>     62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
>>   model:
>>
>>
> I believe so Ronald as it matches the serial number from my CentOS in the
> same hardware.
>
> root@generic:~ # ofwdump -p -a | head
> Node 0x48:
>   memreserve:
>     3b 40 00 00 04 c0 00 00
>   serial-number:
>     31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
>     '10000000bc8a56a3'

The serial number also appears to be available with
'kenv smbios.system.serial' on my RPi4.

-- 
Carl Johnson		carlj@peak.org


From nobody Wed Feb 23 16:49:41 2022
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 0AB9F19DCF7E
	for ; Wed, 23 Feb 2022 16:49:49 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K3hph0z8nz4prR
	for ; Wed, 23 Feb 2022 16:49:48 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 0FB8A2110A8
	for ; Wed, 23 Feb 2022 11:48:18 -0500 (EST)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id D5D5516E2E6
	for ; Wed, 23 Feb 2022 11:49:41 -0500 (EST)
Message-ID: <6faaee4d-03f9-6d50-7dcf-4ee3a88f913d@denninger.net>
Date: Wed, 23 Feb 2022 11:49:41 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Raspberry Pi Serial Number
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 <722278586.24.1645611783398@mailrelay>
 
 <86ee3t3532.fsf@bay.localnet>
From: Karl Denninger 
In-Reply-To: <86ee3t3532.fsf@bay.localnet>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060509050803020605040806"
X-Rspamd-Queue-Id: 4K3hph0z8nz4prR
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-5.90 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10606
Lines: 213

This is a cryptographically signed message in MIME format.

--------------ms060509050803020605040806
Content-Type: multipart/alternative;
 boundary="------------mhaykjin0V1aSHO0v0obuClL"

--------------mhaykjin0V1aSHO0v0obuClL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/23/2022 11:44, Carl Johnson wrote:
> Archimedes Gaviola  writes:
>
>> On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop  wrote:
>>
>>> Is that this number?
>>>
>>> [root@rpi4 ~]# ofwdump -p -a | head
>>> Node 0x48:
>>>    memreserve:
>>>      3b 30 00 00 04 c0 00 00
>>>    serial-number:
>>>      31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
>>>      '10000000649521a0'
>>>    compatible:
>>>      72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
>>>      62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
>>>    model:
>>>
>>>
>> I believe so Ronald as it matches the serial number from my CentOS in the
>> same hardware.
>>
>> root@generic:~ # ofwdump -p -a | head
>> Node 0x48:
>>    memreserve:
>>      3b 40 00 00 04 c0 00 00
>>    serial-number:
>>      31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
>>      '10000000bc8a56a3'
> The serial number also appears to be available with
> 'kenv smbios.system.serial' on my RPi4.
That also works on the Pi3 under 12.x (and, if I recall correctly, on 
prior-to-12.x as well.)
-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------mhaykjin0V1aSHO0v0obuClL
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 2/23/2022 11:44, Carl Johnson wrote:

    

    

      
Archimedes Gaviola <archimedes.gaviola@gmail.com> writes:



      

        
On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop <ronald-lists@klop.ws> wrote:



        

          
Is that this number?

[root@rpi4 ~]# ofwdump -p -a | head
Node 0x48:
  memreserve:
    3b 30 00 00 04 c0 00 00
  serial-number:
    31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
    '10000000649521a0'
  compatible:
    72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
    62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
  model:




        

        
I believe so Ronald as it matches the serial number from my CentOS in the
same hardware.

root@generic:~ # ofwdump -p -a | head
Node 0x48:
  memreserve:
    3b 40 00 00 04 c0 00 00
  serial-number:
    31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
    '10000000bc8a56a3'


      

      
The serial number also appears to be available with
'kenv smbios.system.serial' on my RPi4.


    

    That also works on the Pi3 under 12.x (and, if I recall correctly,
    on prior-to-12.x as well.)
    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------mhaykjin0V1aSHO0v0obuClL--

--------------ms060509050803020605040806
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO
62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp
ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD
QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx
MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A
16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg
96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg
y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs
YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg
6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX
SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM
cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN
5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l
CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg
CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v
b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG
SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O
BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC
GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE
BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh
IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ
zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN
AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR
dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu
2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X
lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK
FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q
IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA
1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL
shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ
qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE
QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMjIzMTY0OTQx
WjBPBgkqhkiG9w0BCQQxQgRAgGijgYClAPnkNMXOPX/Kc1OeLw5WWvjRbJPu8bREGXDBBSwr
5spCDoERGW/RhzTtFCeKS/UTqkXQ5ySih5wazTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg
gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz
dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0
ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF
AASCAgCfZMuWzLomdtatKiCkqwGbPmJdtAzSjf5l4TOKYrToGkXmvhbZJvEN0leEuqYhHKDC
fQabiJpPcbO48DTyp8VnaDJWmSrqCnpHHgFHrP9kSGSCjH0lfO4ik15bpBYHxD3O+SoMNQeQ
fB5gWhhxTU5ZEi2ik7B3obu7MWRaJAt5xWFUqyWoulXNC3RCgwTll/xjRWhDeSnu2HpN/2v4
SAbiSCvtfpMUTmKYgblnXnPbIY46Cjn/JkZIeKlpzDy4OGD6QMTTq7bPKr8Hqz5/BlQqqA3P
fzeRsL5jxnLQWv30jFyPMdEYBwiutwrAt/LRfkKSejMzJ7H+p43zr2bErSo0OY4Sl9EW3/IW
uTrqsX2s7BEym91MRFt42fCLHKXX9N5g+woa0MU3hepRcDGjENxssqNhB+CWf+mnSV6Zfg8O
TCiC4gbchvLrqm1/D7c1UY/RGpZj1TMx5wC3qsG+rU3KT1MTw0cBxwRM3bkm9xjr4Fy20Y7U
xspMjWmV1Ws+3+05GehCfAqVh3Tdln7KhyefJtGwSgPRD6QS+OMLvDgVquD7jtA7JWxqgucG
csbpzEfLWUCiyjjG5891A1NsYZfVtgVFujUnra0gXaefpEYn392ov+KOIfOCoxWLHjLnifA3
lRxfcwgZb44A+pGTGNUVyAsLUZyDOGm9n1DjSpSi2gAAAAAAAA==
--------------ms060509050803020605040806--

From nobody Thu Feb 24 14:50:59 2022
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 BF2BA19CAA8E
	for ; Thu, 24 Feb 2022 14:51:18 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4K4G7T6Wvnz4lnr
	for ; Thu, 24 Feb 2022 14:51:17 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id qx21so4828413ejb.13
        for ; Thu, 24 Feb 2022 06:51:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=xZ409uO8AnuGkEP4VNZz9kA0w6thwd1phFSPM2veWnc=;
        b=K6AN69ZRw2ZRIdkZO56JNzev0GYEqIdOBpUyFYep89EeBGnCFkOi1DzAcBfnu5d8Pq
         80fzAejNEIaZic4uKxRbiKW1skiaYBg0vt7uruLurG2lXPS+xXVXORXXARpe+0lA/+fN
         kcxumnPaRxnx7l5s1XqtYr1EGUqpTQorddzKUD1HVMwt9Ha4MIm2VdHKO57Eq++Q/1lN
         EyZ1v/SN10jcHgnz1CmP6uuibbLmJoNQO4kmjs36cTNbNR9b4QRaiRefnHgn3qKt0HLl
         cUBJXZ2lTMmOX2nGfsm9AgGGZUHuBC+ps5GQFgy0Et/iZMZSUOALwc5uGq48z4K443gN
         zxZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=xZ409uO8AnuGkEP4VNZz9kA0w6thwd1phFSPM2veWnc=;
        b=XPD44p/lddGsLVo5zUIxC9isD/khIchPzyiAkUanRiQWjYKd2agQdJPMZMECOK/V1+
         kVdscIa24nPhrnttsMjVUz4xbHUZKApmHEEdkzIRAOuWT+a8N4hlEgk0ebh2NJqWdcjf
         Fn6iS7cDwlRrnTZ/zXIULUFEKOBPixKypFUqiWcjzhVXoWqcU5d9a1DMAdlBMC/gfkHR
         Je94y7TYADyrHdsJgEEK8rmWoz+f4a8TdLMJ5NHFrizJOC8kJn4jbsjn7mxbN7hPEhrf
         rhorqpUYrOgAGFe7mawWu85QRs9y+dk1Xe3X6IRGQOOGTV4nxJAzbtUNkUUWZiClY5Bw
         PJzA==
X-Gm-Message-State: AOAM532qZOG3VCYIxzk9oDlYfMVfd97Pds6I2QA9/yhE+rTYBSN5xGgf
	6le830GBxANfTybf74jUFI2LeoqvAieeb6R50VpJa5PG285tfQ==
X-Google-Smtp-Source: ABdhPJxpgOwC8YaxsApcGBrnmkZET/QrY598gQ/H6RqJtIJWSYFdAloWr5R4CA/md+fo9ZgZ/+SBDSOcUz/FiOCqiWc=
X-Received: by 2002:a17:907:9208:b0:6cf:cd92:c1e7 with SMTP id
 ka8-20020a170907920800b006cfcd92c1e7mr2661773ejb.282.1645714271104; Thu, 24
 Feb 2022 06:51:11 -0800 (PST)
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: 
 <722278586.24.1645611783398@mailrelay> 
 <86ee3t3532.fsf@bay.localnet>
In-Reply-To: <86ee3t3532.fsf@bay.localnet>
From: Archimedes Gaviola 
Date: Thu, 24 Feb 2022 22:50:59 +0800
Message-ID: 
Subject: Re: Raspberry Pi Serial Number
To: Carl Johnson 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000087f1ee05d8c4b63b"
X-Rspamd-Queue-Id: 4K4G7T6Wvnz4lnr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=K6AN69ZR;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3697
Lines: 109

--00000000000087f1ee05d8c4b63b
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 24, 2022 at 12:45 AM Carl Johnson  wrote:

> Archimedes Gaviola  writes:
>
> > On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop 
> wrote:
> >
> >> Is that this number?
> >>
> >> [root@rpi4 ~]# ofwdump -p -a | head
> >> Node 0x48:
> >>   memreserve:
> >>     3b 30 00 00 04 c0 00 00
> >>   serial-number:
> >>     31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
> >>     '10000000649521a0'
> >>   compatible:
> >>     72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
> >>     62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
> >>   model:
> >>
> >>
> > I believe so Ronald as it matches the serial number from my CentOS in the
> > same hardware.
> >
> > root@generic:~ # ofwdump -p -a | head
> > Node 0x48:
> >   memreserve:
> >     3b 40 00 00 04 c0 00 00
> >   serial-number:
> >     31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
> >     '10000000bc8a56a3'
>
> The serial number also appears to be available with
> 'kenv smbios.system.serial' on my RPi4.
>

 Indeed it gives a more direct output, thanks for sharing!

freebsd@fbsd13:~ % kenv smbios.system.serial
10000000bc8a56a


>
>

--00000000000087f1ee05d8c4b63b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Feb 24, 2022 at 12:45 AM Carl=
 Johnson <carlj@peak.org> wrote=
:
Archimedes Gav=
iola <=
archimedes.gaviola@gmail.com> writes:



> On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop <ronald-lists@klop.ws> wrote:

>

>> Is that this number?

>>

>> [root@rpi4 ~]# ofwdump -p -a | head

>> Node 0x48:

>>=C2=A0 =C2=A0memreserve:

>>=C2=A0 =C2=A0 =C2=A03b 30 00 00 04 c0 00 00

>>=C2=A0 =C2=A0serial-number:

>>=C2=A0 =C2=A0 =C2=A031 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30=
 00

>>=C2=A0 =C2=A0 =C2=A0'10000000649521a0'

>>=C2=A0 =C2=A0compatible:

>>=C2=A0 =C2=A0 =C2=A072 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f=
 64 65 6c 2d

>>=C2=A0 =C2=A0 =C2=A062 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
>>=C2=A0 =C2=A0model:

>>

>>

> I believe so Ronald as it matches the serial number from my CentOS in =
the

> same hardware.

>

> root@generic:~ # ofwdump -p -a | head

> Node 0x48:

>=C2=A0 =C2=A0memreserve:

>=C2=A0 =C2=A0 =C2=A03b 40 00 00 04 c0 00 00

>=C2=A0 =C2=A0serial-number:

>=C2=A0 =C2=A0 =C2=A031 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00<=
br>
>=C2=A0 =C2=A0 =C2=A0'10000000bc8a56a3'



The serial number also appears to be available with

'kenv smbios.system.serial' on my RPi4.

=C2=A0Indeed it gives a more direct output, thanks for sharing!

freebsd@fbsd13:~ % kenv smbios.system.serial
10000000bc8a56a











--00000000000087f1ee05d8c4b63b--

From nobody Thu Feb 24 15:04:39 2022
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 69BA219CD6E0
	for ; Thu, 24 Feb 2022 15:04:30 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K4GQj0dsMz4nTr
	for ; Thu, 24 Feb 2022 15:04:28 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=VQzwbuRGVrcDlCygQp422NKaAe0Zku2evSfGtSTu3NY=; b=bccrfyxplXBUYU56Wo7L485pYd
	8l6Wv1Us0xM3Pa+lEix9OVtHyfIuGgcZffUseAnKfH7nGNuyVBLnBAtnpnc9f1gOcjtP8Y1hjSbsE
	KZKRIjZ+LFtsR+ItH68p6YtoKeGZ+4Sh/MWK4Br6gwa4oQ7a1fw8Z6BZsPniSKsBqPKg=;
Message-ID: <8f933b23-2ce7-9e41-4845-32e81a58d5ef@klop.ws>
Date: Thu, 24 Feb 2022 16:04:39 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Raspberry Pi Serial Number
Content-Language: en-US
To: Archimedes Gaviola ,
 Carl Johnson 
Cc: freebsd-arm@freebsd.org
References: 
 <722278586.24.1645611783398@mailrelay>
 
 <86ee3t3532.fsf@bay.localnet>
 
From: Ronald Klop 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: -
X-Spam-Score: -1.2
X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 4c3c8b3d32e7d0cfaf2d58264fc1daa3
X-Rspamd-Queue-Id: 4K4GQj0dsMz4nTr
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=bccrfyxp;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[195.190.28.88:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com,peak.org];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1617
Lines: 54

On 2/24/22 15:50, Archimedes Gaviola wrote:
> 
> 
> On Thu, Feb 24, 2022 at 12:45 AM Carl Johnson > wrote:
> 
>     Archimedes Gaviola > writes:
> 
>      > On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop > wrote:
>      >
>      >> Is that this number?
>      >>
>      >> [root@rpi4 ~]# ofwdump -p -a | head
>      >> Node 0x48:
>      >>   memreserve:
>      >>     3b 30 00 00 04 c0 00 00
>      >>   serial-number:
>      >>     31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
>      >>     '10000000649521a0'
>      >>   compatible:
>      >>     72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
>      >>     62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
>      >>   model:
>      >>
>      >>
>      > I believe so Ronald as it matches the serial number from my CentOS in the
>      > same hardware.
>      >
>      > root@generic:~ # ofwdump -p -a | head
>      > Node 0x48:
>      >   memreserve:
>      >     3b 40 00 00 04 c0 00 00
>      >   serial-number:
>      >     31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
>      >     '10000000bc8a56a3'
> 
>     The serial number also appears to be available with
>     'kenv smbios.system.serial' on my RPi4.
> 
> 
>   Indeed it gives a more direct output, thanks for sharing!
> 
> freebsd@fbsd13:~ % kenv smbios.system.serial
> 10000000bc8a56a
> 
> 
> 


If it is about direct output you can also do:

ofwdump -P serial-number -S /

Cheers,
Ronald.

From nobody Thu Feb 24 16:03:47 2022
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 B00EF19D97EA
	for ; Thu, 24 Feb 2022 16:04:18 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(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 4K4Hlk0BcGz3CfN
	for ; Thu, 24 Feb 2022 16:04:18 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52a.google.com with SMTP id s14so3590549edw.0
        for ; Thu, 24 Feb 2022 08:04:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Q94GOXpGWrTUiSjVzKyIyZxbh2DHe/N5RsHQ0w2WELA=;
        b=koA2cpIBROc+hJWxaZrES4BopKBY4WV/S3iSSGHQ3sAW1DWvH9JZ+YxY3nC7u/FAzw
         1B3UBTAvl0dffGtD7qDxynIzVVzJ+vcnypbP47Eo5Ux+HN15qfTDrzs1wlpkI8sVR7Iw
         LlKQ6vPvTJvsZirssXEz0ic/903EYbIBCKF5ystMyBkC8TJ3hkziCrB8FTcVbO0HFktO
         4j2l13H3zwQSrFuoPVfyKeZVMJJRm1CJ0/YSzAUe9bp1UnFmURTg5NKqxtH73daM1yyt
         fvUGu3fG4u4w98pm1SVh07iergN+uDEQK9I8UMTY3l15FqkzyAd3ES0K4VkJpL9S7o1g
         fG+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Q94GOXpGWrTUiSjVzKyIyZxbh2DHe/N5RsHQ0w2WELA=;
        b=B0Dh/1c2d1QDA/lv+/dawv2x3E7aDqnc6x64GRQvgZvwJm7JywzaVFw48z4+DHeBUn
         8LsrjkqsU9hdt3yLd05hynTh08zvAGoVSrJA7TVtx7Bqk09TkYQImxMzheuwOnNo0zyd
         +O2WNfA3zxMOGQn8DZ8oU6pdMtbGypAR6EhraMAFygKxwlPIr6inSXs9hxaPj7t86n/G
         w5kwHvNNNzEyui360tPXaIICRVF8gx3wPw5xzFFFNG2qAAhWsbv9Y/leMzqoN7os7ksw
         LkNzflwz1wbuFw3+yAzJrJ0/IYPBQKj2FzptSgIxfXZNHP7O/nyXd/rGAdsuLxbhsSj5
         +IXQ==
X-Gm-Message-State: AOAM532UKx8keplCtG3aBxSM0JjUh0O94FqB4Hhk4HU3BhZ2DyFoGnYn
	dxXAnryQn5wS5r8FiX/xngFTvxO//2B5ocJguKU=
X-Google-Smtp-Source: ABdhPJwrvM+6+Odsu1PZbOYU/UehwKCjziM1ElFho9ZynLXSHWpc2PEsjtMlyI7V2UBmR990TaMbuyZDpK3c61H/du4=
X-Received: by 2002:a05:6402:2686:b0:412:d1cb:a6d8 with SMTP id
 w6-20020a056402268600b00412d1cba6d8mr2983872edd.280.1645718656981; Thu, 24
 Feb 2022 08:04:16 -0800 (PST)
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: 
 <722278586.24.1645611783398@mailrelay> 
 <86ee3t3532.fsf@bay.localnet> 
 <8f933b23-2ce7-9e41-4845-32e81a58d5ef@klop.ws>
In-Reply-To: <8f933b23-2ce7-9e41-4845-32e81a58d5ef@klop.ws>
From: Archimedes Gaviola 
Date: Fri, 25 Feb 2022 00:03:47 +0800
Message-ID: 
Subject: Re: Raspberry Pi Serial Number
To: Ronald Klop 
Cc: Carl Johnson , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f31d1705d8c5bb5b"
X-Rspamd-Queue-Id: 4K4Hlk0BcGz3CfN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=koA2cpIB;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5591
Lines: 147

--000000000000f31d1705d8c5bb5b
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 24, 2022 at 11:04 PM Ronald Klop  wrote:

> On 2/24/22 15:50, Archimedes Gaviola wrote:
> >
> >
> > On Thu, Feb 24, 2022 at 12:45 AM Carl Johnson  carlj@peak.org>> wrote:
> >
> >     Archimedes Gaviola  archimedes.gaviola@gmail.com>> writes:
> >
> >      > On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop  > wrote:
> >      >
> >      >> Is that this number?
> >      >>
> >      >> [root@rpi4 ~]# ofwdump -p -a | head
> >      >> Node 0x48:
> >      >>   memreserve:
> >      >>     3b 30 00 00 04 c0 00 00
> >      >>   serial-number:
> >      >>     31 30 30 30 30 30 30 30 36 34 39 35 32 31 61 30 00
> >      >>     '10000000649521a0'
> >      >>   compatible:
> >      >>     72 61 73 70 62 65 72 72 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d
> >      >>     62 00 62 72 63 6d 2c 62 63 6d 32 37 31 31 00
> >      >>   model:
> >      >>
> >      >>
> >      > I believe so Ronald as it matches the serial number from my
> CentOS in the
> >      > same hardware.
> >      >
> >      > root@generic:~ # ofwdump -p -a | head
> >      > Node 0x48:
> >      >   memreserve:
> >      >     3b 40 00 00 04 c0 00 00
> >      >   serial-number:
> >      >     31 30 30 30 30 30 30 30 62 63 38 61 35 36 61 33 00
> >      >     '10000000bc8a56a3'
> >
> >     The serial number also appears to be available with
> >     'kenv smbios.system.serial' on my RPi4.
> >
> >
> >   Indeed it gives a more direct output, thanks for sharing!
> >
> > freebsd@fbsd13:~ % kenv smbios.system.serial
> > 10000000bc8a56a
> >
> >
> >
>
>
> If it is about direct output you can also do:
>
> ofwdump -P serial-number -S /
>

Nice, thanks again Ronald!

--000000000000f31d1705d8c5bb5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Feb 24, 2022 at 11:04 PM Rona=
ld Klop <ronald-lists@klop.ws> wrote:
On =
2/24/22 15:50, Archimedes Gaviola wrote:

> 

> 

> On Thu, Feb 24, 2022 at 12:45 AM Carl Johnson <carlj@peak.org <mailto:carlj@peak.org>> wrote:
> 

>=C2=A0 =C2=A0 =C2=A0Archimedes Gaviola <archimedes.gaviola@gmail.com <=
mailto:ar=
chimedes.gaviola@gmail.com>> writes:

> 

>=C2=A0 =C2=A0 =C2=A0 > On Wed, Feb 23, 2022 at 6:23 PM Ronald Klop &=
lt;ronald-lists@k=
lop.ws <mailto:ronald-lists@klop.ws>> wrote:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >> Is that this number?

>=C2=A0 =C2=A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0 >> [root@rpi4 ~]# ofwdump -p -a | head

>=C2=A0 =C2=A0 =C2=A0 >> Node 0x48:

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0memreserve:

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A03b 30 00 00 04 c0 00 0=
0

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0serial-number:

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A031 30 30 30 30 30 30 3=
0 36 34 39 35 32 31 61 30 00

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0'10000000649521a0&=
#39;

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0compatible:

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A072 61 73 70 62 65 72 7=
2 79 70 69 2c 34 2d 6d 6f 64 65 6c 2d

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A062 00 62 72 63 6d 2c 6=
2 63 6d 32 37 31 31 00

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0model:

>=C2=A0 =C2=A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0 > I believe so Ronald as it matches the serial =
number from my CentOS in the

>=C2=A0 =C2=A0 =C2=A0 > same hardware.

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > root@generic:~ # ofwdump -p -a | head

>=C2=A0 =C2=A0 =C2=A0 > Node 0x48:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0memreserve:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A03b 40 00 00 04 c0 00 00
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0serial-number:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A031 30 30 30 30 30 30 30 62=
 63 38 61 35 36 61 33 00

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0'10000000bc8a56a3'=


> 

>=C2=A0 =C2=A0 =C2=A0The serial number also appears to be available with=


>=C2=A0 =C2=A0 =C2=A0'kenv smbios.system.serial' on my RPi4.

> 

> 

>=C2=A0 =C2=A0Indeed it gives a more direct output, thanks for sharing!<=
br>
> 

> freebsd@fbsd13:~ % kenv smbios.system.serial

> 10000000bc8a56a

> 

> 

> 





If it is about direct output you can also do:



ofwdump -P serial-number -S /

Nice, thanks a=
gain Ronald!


--000000000000f31d1705d8c5bb5b--

From nobody Sat Feb 26 03:49:54 2022
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 1038B19E063D
	for ; Sat, 26 Feb 2022 03:50:26 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4K5CN12ycmz3CqF
	for ; Sat, 26 Feb 2022 03:50:25 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id gb39so14430277ejc.1
        for ; Fri, 25 Feb 2022 19:50:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=CTPSR8+O773nPhBgAzicht/hJaemvTxf0iH5OY7aVfA=;
        b=ogwi1awj8wshR2OdvMBXngWBDObJiuP/7uTHENFvQOuH9BOStI2WsOayqZ8YL3x1cY
         MyHBwz21WE3zFGFqKbvjYo8erqBMBGwzDPRxTY5Jj1CTOtU1COKYg8Iywst0Kypmo+2k
         LmIa4SNOcK9DsTDcpS+FI/JD/0ba3c4QPPcuan//UJwBqp4bc1R0GX7uyJ9SDXCm9BEW
         7ZH0eObFA9M85m3DJbvAuT2giqtdv0iDYtSV83iM5+8GEClXm0SMh4GLZdcbrezNvzDc
         KzAfEL+JrpsUGZVwBZlWeyC3oYbT74tkpa4VDqkHWUi/nhTPqMUQV/WBksG2SQA0ctbp
         Fzbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=CTPSR8+O773nPhBgAzicht/hJaemvTxf0iH5OY7aVfA=;
        b=CB6PPSd4IwdSpVYTS3UHGDtvz2/byVoIuC3MVuE6M5Rv05xpVzCMQGn4AR/pQ0qvrN
         V9MYnD6ifKCfoFRnDhhjZpxPpT3wb/qlUyRBxtZWOGVvO8TPWmq2KHOmq+gpgRUS2uAd
         B6WcP8AQq2DKXmtNRo8zIxnRkx+9e4V8lVUPAYgBjeVwC4eTJ/by0fhK4nIKYADDGZ72
         4JDbd8+pgp+gFWYrjM9BxoZ76TuBKcEqHYDFg0PofzgAdjqvb6aOvycLDc3H+gHhLxyJ
         JmdjX+gAU2q8cEJ87PGeHUNQdHei8bON7/UWjxRpBkhf3KZ3jLYvBmDgrt7yXyo0Dwd8
         beJQ==
X-Gm-Message-State: AOAM530ZEo3zWp89/WDrrzZKvboFZ4uWvz9SapVpqetaPxeZFi37n07y
	jB6j3WZBVWQvFNIM+qWO79oVnqywqy6BPRuZqvAIrvfiN+s=
X-Google-Smtp-Source: ABdhPJyrYN+BHGiBaeUaTMD0/9vPWeMvwDSgCgwVC6n4+iW0QGtdcfMP7loksgyY0RU5OtyC/rSxM2xHD9D+VS/JanM=
X-Received: by 2002:a17:907:9208:b0:6cf:cd92:c1e7 with SMTP id
 ka8-20020a170907920800b006cfcd92c1e7mr8611847ejb.282.1645847422312; Fri, 25
 Feb 2022 19:50:22 -0800 (PST)
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
From: Archimedes Gaviola 
Date: Sat, 26 Feb 2022 11:49:54 +0800
Message-ID: 
Subject: Raspberry Pi 3B Distorted U-boot Display
To: freebsd-arm@freebsd.org
Content-Type: multipart/mixed; boundary="000000000000f637b505d8e3b600"
X-Rspamd-Queue-Id: 4K5CN12ycmz3CqF
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ogwi1awj;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [0.10 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 HAS_ATTACHMENT(0.00)[];
	 TO_DN_NONE(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 CTYPE_MIXED_BOGUS(1.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 15074
Lines: 243

--000000000000f637b505d8e3b600
Content-Type: multipart/alternative; boundary="000000000000f637b305d8e3b6fe"

--000000000000f637b305d8e3b6fe
Content-Type: text/plain; charset="UTF-8"

Hi,

I've installed FreeBSD 13.0-RELEASE and 14.0-CURRENT successfully with
Raspberry Pi 3B. However, upon U-boot initialization stage the monitor
display is distorted as you can see here
https://pasteboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is
loaded it displays normal as you can see here
https://pasteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowering the
resolution so I tried changing the HDMI configuration settings in the
config.txt but it cannot be changed, it has no effect. It always stays on
the default 1366x768 as what dmesg has detected. This behavior is also
observed in 14.0-CURRENT.

FreeBSD 13.0-RELEASE #0: Sat Feb 19 14:09:03 PST 2022
    root@fbsd13:/usr/src/sys/arm64/compile/GENERIC arm64
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
VT(efifb): resolution 1366x768
...
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.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1366x768(1366x768@0,0) 32bpp
fb0: fbswap: 1, pitch 5504, base 0x3e7f2000, screen_size 4227072

freebsd@fbsd13:~ % cat /boot/msdos/config.txt
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=ds3231
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin
enable_uart=1

[pi4]
hdmi_group=2
hdmi_mode=11
armstub=armstub8-gic.bin

freebsd@fbsd13:~ % grep -r "1366x768" /boot/msdos/
Binary file /boot/msdos/start_cd.elf matches
Binary file /boot/msdos/start_db.elf matches
Binary file /boot/msdos/start_x.elf matches
Binary file /boot/msdos/start.elf matches
Binary file /boot/msdos/start4.elf matches
Binary file /boot/msdos/start4cd.elf matches
Binary file /boot/msdos/start4db.elf matches
Binary file /boot/msdos/start4x.elf matches

Using the same images with 13.0-RELEASE and 14.0-CURRENT this issue does
not occur in RPi 4B. Anyone encountered this issue? I confirmed this as
well with another new RPi 3B hardware and it behaves the same. Please see
attached dmesg log output for reference.

Thanks,
Archimedes

--000000000000f637b305d8e3b6fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I've installed FreeB=
SD 13.0-RELEASE and 14.0-CURRENT successfully with Raspberry Pi 3B. However=
, upon U-boot initialization stage the monitor display is distorted as you =
can see here https://pas=
teboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is loaded it di=
splays normal as you can see here https://pasteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowe=
ring the resolution so I tried changing the HDMI configuration settings in =
the config.txt but it cannot be changed, it has no effect. It always stays =
on the default 1366x768 as what dmesg has detected. This behavior is also o=
bserved in 14.0-CURRENT.

FreeBSD 13.0-RELEASE =
#0: Sat Feb 19 14:09:03 PST 2022
=C2=A0 =C2=A0 root@fbsd13:/usr/src/sys/=
arm64/compile/GENERIC arm64
FreeBSD clang version 11.0.1 (git@github.com=
:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
VT(efifb): resolu=
tion 1366x768
...
fb0: <BCM2835 VT framebuffer drive=
r> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0WARNING: Device "fb" is Giant locked and may be deleted before F=
reeBSD 14.0.
VT: Replacing driver "efifb" with new "fb&qu=
ot;.
fb0: 1366x768(1366x768@0,0) 32bpp
fb0: fbswap: 1, pitch 5504, ba=
se 0x3e7f2000, screen_size 4227072

freebsd@fbsd13:=
~ % cat /boot/msdos/config.txt
[all]
arm_64bit=3D1
dtparam=3Daudio=
=3Don,i2c_arm=3Don,spi=3Don
dtoverlay=3Dds3231
dtoverlay=3Dmmc
dto=
verlay=3Ddisable-bt
device_tree_address=3D0x4000
kernel=3Du-boot.bin<=
br>enable_uart=3D1

[pi4]
hdmi_group=3D2
hdmi_mode=3D11
arms=
tub=3Darmstub8-gic.bin

freebsd@fbsd=
13:~ % grep -r "1366x768" /boot/msdos/
Binary file /boot/msdos=
/start_cd.elf matches
Binary file /boot/msdos/start_db.elf matches
Bi=
nary file /boot/msdos/start_x.elf matches
Binary file /boot/msdos/start.=
elf matches
Binary file /boot/msdos/start4.elf matches
Binary file /b=
oot/msdos/start4cd.elf matches
Binary file /boot/msdos/start4db.elf matc=
hes
Binary file /boot/msdos/start4x.elf matches

Using the same images with 13.0-RELEASE and 14.0-CURRENT this issue does n=
ot occur in RPi 4B. Anyone encountered this issue? I confirmed this as well=
 with another new RPi 3B hardware and it behaves the same. Please see attac=
hed dmesg log output for reference.

Thanks,
Archimedes 



<=
div>


--000000000000f637b305d8e3b6fe--
--000000000000f637b505d8e3b600
Content-Type: text/plain; charset="US-ASCII"; 
	name="freebsd13_rpi3b_u-boot-distorted-display.txt"
Content-Disposition: attachment; 
	filename="freebsd13_rpi3b_u-boot-distorted-display.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_l03awgf30

ZnJlZWJzZEBmYnNkMTM6fiAlIGRtZXNnDQotLS08PEJPT1Q+Pi0tLQ0KQ29weXJpZ2h0IChjKSAx
OTkyLTIwMjEgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwg
MTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBU
aGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJl
c2VydmVkLg0KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNE
IEZvdW5kYXRpb24uDQpGcmVlQlNEIDEzLjAtUkVMRUFTRSAjMDogU2F0IEZlYiAxOSAxNDowOTow
MyBQU1QgMjAyMg0KICAgIHJvb3RAZmJzZDEzOi91c3Ivc3JjL3N5cy9hcm02NC9jb21waWxlL0dF
TkVSSUMgYXJtNjQNCkZyZWVCU0QgY2xhbmcgdmVyc2lvbiAxMS4wLjEgKGdpdEBnaXRodWIuY29t
Omxsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZtb3JnLTExLjAuMS0wLWc0M2ZmNzVmMmMzZmUpDQpW
VChlZmlmYik6IHJlc29sdXRpb24gMTM2Nng3NjgNCm1vZHVsZSBmaXJtd2FyZSBhbHJlYWR5IHBy
ZXNlbnQhDQpyZWFsIG1lbW9yeSAgPSA5OTM4NDExNTIgKDk0NyBNQikNCmF2YWlsIG1lbW9yeSA9
IDk0NzQwMDcwNCAoOTAzIE1CKQ0KU3RhcnRpbmcgQ1BVIDEgKDEpDQpTdGFydGluZyBDUFUgMiAo
MikNClN0YXJ0aW5nIENQVSAzICgzKQ0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl
bSBEZXRlY3RlZDogNCBDUFVzDQpyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLg0KcmFuZG9tOiBl
bnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UNCk1BUCAzOWYzZDAwMCBtb2RlIDIgcGFn
ZXMgMQ0KTUFQIDM5ZjQxMDAwIG1vZGUgMiBwYWdlcyAzDQpNQVAgMzlmNDUwMDAgbW9kZSAyIHBh
Z2VzIDQNCk1BUCAzYjM1MDAwMCBtb2RlIDIgcGFnZXMgMTYNCk1BUCAzZjEwMDAwMCBtb2RlIDAg
cGFnZXMgMQ0KV0FSTklORzogRGV2aWNlICJvcGVuZmlybSIgaXMgR2lhbnQgbG9ja2VkIGFuZCBt
YXkgYmUgZGVsZXRlZCBiZWZvcmUgRnJlZUJTRCAxNC4wLg0KV0FSTklORzogRGV2aWNlICJrYmQi
IGlzIEdpYW50IGxvY2tlZCBhbmQgbWF5IGJlIGRlbGV0ZWQgYmVmb3JlIEZyZWVCU0QgMTQuMC4N
CmtiZDAgYXQga2JkbXV4MA0Kb2Z3YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNlIFRyZWU+DQpz
aW1wbGVidXMwOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1czAN
Cm9md19jbGtidXMwOiA8T0ZXIGNsb2NrcyBidXM+IG9uIG9md2J1czANCmNsa19maXhlZDA6IDxG
aXhlZCBjbG9jaz4gb24gb2Z3X2Nsa2J1czANCmNsa19maXhlZDE6IDxGaXhlZCBjbG9jaz4gb24g
b2Z3X2Nsa2J1czANCnJlZ2ZpeDA6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIG9md2J1czANCnJlZ2Zp
eDE6IDxGaXhlZCBSZWd1bGF0b3I+IG9uIG9md2J1czANCmJjbTI4MzVfZmlybXdhcmUwOiA8QkNN
MjgzNSBGaXJtd2FyZT4gb24gc2ltcGxlYnVzMA0Kb2Z3X2Nsa2J1czE6IDxPRlcgY2xvY2tzIGJ1
cz4gb24gYmNtMjgzNV9maXJtd2FyZTANCnBzY2kwOiA8QVJNIFBvd2VyIFN0YXRlIENvLW9yZGlu
YXRpb24gSW50ZXJmYWNlIERyaXZlcj4gb24gb2Z3YnVzMA0KbGludGMwOiA8QkNNMjgzNiBJbnRl
cnJ1cHQgQ29udHJvbGxlcj4gbWVtIDB4NDAwMDAwMDAtMHg0MDAwMDBmZiBvbiBzaW1wbGVidXMw
DQppbnRjMDogPEJDTTI4MzUgSW50ZXJydXB0IENvbnRyb2xsZXI+IG1lbSAweDdlMDBiMjAwLTB4
N2UwMGIzZmYgaXJxIDM5IG9uIHNpbXBsZWJ1czANCmdwaW8wOiA8QkNNMjcwOC8yODM1IEdQSU8g
Y29udHJvbGxlcj4gbWVtIDB4N2UyMDAwMDAtMHg3ZTIwMDBiMyBpcnEgNyw4IG9uIHNpbXBsZWJ1
czANCmdwaW9idXMwOiA8T0ZXIEdQSU8gYnVzPiBvbiBncGlvMA0KZ3BpbzE6IDxSYXNwYmVycnkg
UGkgRmlybXdhcmUgR1BJTyBjb250cm9sbGVyPiBvbiBiY20yODM1X2Zpcm13YXJlMA0KZ3Bpb2J1
czE6IDxHUElPIGJ1cz4gb24gZ3BpbzENCm1ib3gwOiA8QkNNMjgzNSBWaWRlb0NvcmUgTWFpbGJv
eD4gbWVtIDB4N2UwMGI4ODAtMHg3ZTAwYjhiZiBpcnEgNiBvbiBzaW1wbGVidXMwDQpnZW5lcmlj
X3RpbWVyMDogPEFSTXY3IEdlbmVyaWMgVGltZXI+IGlycSAxLDIsMyw0IG9uIG9md2J1czANClRp
bWVjb3VudGVyICJBUk0gTVBDb3JlIFRpbWVjb3VudGVyIiBmcmVxdWVuY3kgMTkyMDAwMDAgSHog
cXVhbGl0eSAxMDAwDQpFdmVudCB0aW1lciAiQVJNIE1QQ29yZSBFdmVudHRpbWVyIiBmcmVxdWVu
Y3kgMTkyMDAwMDAgSHogcXVhbGl0eSAxMDAwDQp1c2Jfbm9wX3hjZWl2MDogPFVTQiBOT1AgUEhZ
PiBvbiBvZndidXMwDQpiY20yODM1X2Nsa21hbjA6IDxCQ00yODN4IENsb2NrIE1hbmFnZXI+IG1l
bSAweDdlMTAxMDAwLTB4N2UxMDJmZmYgb24gc2ltcGxlYnVzMA0KZ3Bpb2MwOiA8R1BJTyBjb250
cm9sbGVyPiBvbiBncGlvMA0KdWFydDA6IDxQcmltZUNlbGwgVUFSVCAoUEwwMTEpPiBtZW0gMHg3
ZTIwMTAwMC0weDdlMjAxMWZmIGlycSA5IG9uIHNpbXBsZWJ1czANCnVhcnQwOiBjb25zb2xlICgx
MTUyMDAsbiw4LDEpDQpzcGkwOiA8QkNNMjcwOC8yODM1IFNQSSBjb250cm9sbGVyPiBtZW0gMHg3
ZTIwNDAwMC0weDdlMjA0MWZmIGlycSAxMSBvbiBzaW1wbGVidXMwDQpzcGlidXMwOiA8T0ZXIFNQ
SSBidXM+IG9uIHNwaTANCnNwaWJ1czA6IDx1bmtub3duIGNhcmQ+IGF0IGNzIDAgbW9kZSAwDQpz
cGlidXMwOiA8dW5rbm93biBjYXJkPiBhdCBjcyAxIG1vZGUgMA0KaWljaGIwOiA8QkNNMjcwOC8y
ODM1IEJTQyBjb250cm9sbGVyPiBtZW0gMHg3ZTgwNDAwMC0weDdlODA0ZmZmIGlycSAxOSBvbiBz
aW1wbGVidXMwDQpiY20yODN4X2R3Y290ZzA6IDxEV0MgT1RHIDIuMCBpbnRlZ3JhdGVkIFVTQiBj
b250cm9sbGVyIChiY20yODN4KT4gbWVtIDB4N2U5ODAwMDAtMHg3ZTk4ZmZmZiwweDdlMDA2MDAw
LTB4N2UwMDZmZmYgaXJxIDIxLDIyIG9uIHNpbXBsZWJ1czANCnVzYnVzMSBvbiBiY20yODN4X2R3
Y290ZzANCmJjbV9kbWEwOiA8QkNNMjgzNSBETUEgQ29udHJvbGxlcj4gbWVtIDB4N2UwMDcwMDAt
MHg3ZTAwN2VmZiBpcnEgMjMsMjQsMjUsMjYsMjcsMjgsMjksMzAsMzEsMzIsMzMsMzQsMzUsMzYs
MzcsMzggb24gc2ltcGxlYnVzMA0KYmNtd2QwOiA8QkNNMjcwOC8yODM1IFdhdGNoZG9nPiBtZW0g
MHg3ZTEwMDAwMC0weDdlMTAwMTEzLDB4N2UwMGEwMDAtMHg3ZTAwYTAyMyBvbiBzaW1wbGVidXMw
DQpiY21ybmcwOiA8QnJvYWRjb20gQkNNMjgzNSBSTkc+IG1lbSAweDdlMTA0MDAwLTB4N2UxMDQw
MGYgaXJxIDQwIG9uIHNpbXBsZWJ1czANCnNkaGNpX2JjbTA6IDxCcm9hZGNvbSAyNzA4IFNESENJ
IGNvbnRyb2xsZXI+IG1lbSAweDdlMzAwMDAwLTB4N2UzMDAwZmYgaXJxIDQ4IG9uIHNpbXBsZWJ1
czANCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhjaV9iY20wDQpncGlvYzE6IDxHUElPIGNvbnRy
b2xsZXI+IG9uIGdwaW8xDQpmYjA6IDxCQ00yODM1IFZUIGZyYW1lYnVmZmVyIGRyaXZlcj4gb24g
c2ltcGxlYnVzMA0KZmIwOiBrZWVwaW5nIGV4aXN0aW5nIGZiIGJwcCBvZiAzMg0KZmJkMCBvbiBm
YjANCldBUk5JTkc6IERldmljZSAiZmIiIGlzIEdpYW50IGxvY2tlZCBhbmQgbWF5IGJlIGRlbGV0
ZWQgYmVmb3JlIEZyZWVCU0QgMTQuMC4NClZUOiBSZXBsYWNpbmcgZHJpdmVyICJlZmlmYiIgd2l0
aCBuZXcgImZiIi4NCmZiMDogMTM2Nng3NjgoMTM2Nng3NjhAMCwwKSAzMmJwcA0KZmIwOiBmYnN3
YXA6IDEsIHBpdGNoIDU1MDQsIGJhc2UgMHgzZTdmMjAwMCwgc2NyZWVuX3NpemUgNDIyNzA3Mg0K
cG11MDogPFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgVW5pdD4gaXJxIDAgb24gb2Z3YnVzMA0KY3B1
bGlzdDA6IDxPcGVuIEZpcm13YXJlIENQVSBHcm91cD4gb24gb2Z3YnVzMA0KY3B1MDogPE9wZW4g
RmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KYmNtMjgzNV9jcHVmcmVxMDogPENQVSBGcmVxdWVu
Y3kgQ29udHJvbD4gb24gY3B1MA0KY3B1MTogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0
MA0KY3B1MjogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1MzogPE9wZW4gRmly
bXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KZ3Bpb2xlZDA6IDxHUElPIExFRHM+IG9uIG9md2J1czAN
CmdwaW9sZWQwOiA8bGVkMD4gZmFpbGVkIHRvIG1hcCBwaW4NCmNyeXB0b3NvZnQwOiA8c29mdHdh
cmUgY3J5cHRvPg0KYXJtdjhjcnlwdG8wOiBDUFUgbGFja3MgQUVTIGluc3RydWN0aW9ucw0KVGlt
ZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KaWljYnVzMDogPE9GVyBJMkMgYnVzPiBv
biBpaWNoYjANCmlpYzA6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czANCmRzMzIzMTA6IDxN
YXhpbSBEUzMyMzEgUlRDPiBhdCBhZGRyIDB4ZDAgb24gaWljYnVzMA0KdXNidXMxOiA0ODBNYnBz
IEhpZ2ggU3BlZWQgVVNCIHYyLjANCnVnZW4xLjE6IDxEV0NPVEcgT1RHIFJvb3QgSFVCPiBhdCB1
c2J1czENCnVodWIwIG9uIHVzYnVzMQ0KdWh1YjA6IDxEV0NPVEcgT1RHIFJvb3QgSFVCLCBjbGFz
cyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxDQptbWNzZDA6IDMyR0IgPFNE
SEMgU1AzMkcgOC4wIFNOIEY3RTQ5MUE4IE1GRyAwMy8yMDIxIGJ5IDMgU0Q+IGF0IG1tYzAgNTAu
ME1Iei80Yml0LzY1NTM1LWJsb2NrDQpiY20yODM1X2NwdWZyZXEwOiBBUk0gNjAwTUh6LCBDb3Jl
IDI1ME1IeiwgU0RSQU0gNDAwTUh6LCBUdXJibyBPRkYNCmRzMzIzMTA6IHJlZ2lzdGVyZWQgYXMg
YSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAwMDAwMHMNClJlbGVhc2UgQVBzLi4u
ZG9uZQ0KQ1BVICAwOiBBUk0gQ29ydGV4LUE1MyByMHA0IGFmZmluaXR5OiAgMA0KVHJ5aW5nIHRv
IG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi91ZnMvcm9vdGZzIFtyd10uLi4NCiAgICAgICAgICAg
ICAgICAgICBDYWNoZSBUeXBlID0gPDY0IGJ5dGUgRC1jYWNoZWxpbmUsNjQgYnl0ZSBJLWNhY2hl
bGluZSxWSVBUIElDYWNoZSw2NCBieXRlIEVSRyw2NCBieXRlIENXRz4NCiBJbnN0cnVjdGlvbiBT
ZXQgQXR0cmlidXRlcyAwID0gPENSQzMyPg0KIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDEg
PSA8Pg0KICAgICAgICAgUHJvY2Vzc29yIEZlYXR1cmVzIDAgPSA8QWR2U0lNRCxGUCxFTDMgMzIs
RUwyIDMyLEVMMSAzMixFTDAgMzI+DQogICAgICAgICBQcm9jZXNzb3IgRmVhdHVyZXMgMSA9IDw+
DQogICAgICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMCA9IDxUR3JhbjQsVEdyYW42NCxTTlNNZW0s
QmlnRW5kLDE2Yml0IEFTSUQsMVRCIFBBPg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDEg
PSA8OGJpdCBWTUlEPg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDIgPSA8MzJiaXQgQ0NJ
RFgsNDhiaXQgVkE+DQogICAgICAgICAgICAgRGVidWcgRmVhdHVyZXMgMCA9IDwyIENUWCBCS1BU
cyw0IFdhdGNocG9pbnRzLDYgQnJlYWtwb2ludHMsUE1VdjMsRGVidWd2OD4NCiAgICAgICAgICAg
ICBEZWJ1ZyBGZWF0dXJlcyAxID0gPD4NCiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAwID0g
PD4NCiAgICAgICAgIEF1eGlsaWFyeSBGZWF0dXJlcyAxID0gPD4NCkNQVSAgMTogQVJNIENvcnRl
eC1BNTMgcjBwNCBhZmZpbml0eTogIDENCkNQVSAgMjogQVJNIENvcnRleC1BNTMgcjBwNCBhZmZp
bml0eTogIDINCkNQVSAgMzogQVJNIENvcnRleC1BNTMgcjBwNCBhZmZpbml0eTogIDMNCkR1YWwg
Q29uc29sZTogU2VyaWFsIFByaW1hcnksIFZpZGVvIFNlY29uZGFyeQ0KdWh1YjA6IDEgcG9ydCB3
aXRoIDEgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVnZW4xLjI6IDx2ZW5kb3IgMHgwNDI0IHBy
b2R1Y3QgMHg5NTE0PiBhdCB1c2J1czENCnVodWIxIG9uIHVodWIwDQp1aHViMTogPHZlbmRvciAw
eDA0MjQgcHJvZHVjdCAweDk1MTQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMi4wMCwgYWRkciAyPiBv
biB1c2J1czENCnVodWIxOiBNVFQgZW5hYmxlZA0KdWh1YjE6IDUgcG9ydHMgd2l0aCA0IHJlbW92
YWJsZSwgc2VsZiBwb3dlcmVkDQpsbzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KdWdlbjEu
MzogPHZlbmRvciAweDA0MjQgcHJvZHVjdCAweGVjMDA+IGF0IHVzYnVzMQ0Kc21zYzAgb24gdWh1
YjENCnNtc2MwOiA8dmVuZG9yIDB4MDQyNCBwcm9kdWN0IDB4ZWMwMCwgcmV2IDIuMDAvMi4wMCwg
YWRkciAzPiBvbiB1c2J1czENCnNtc2MwOiBjaGlwIDB4ZWMwMCwgcmV2LiAwMDAyDQptaWlidXMw
OiA8TUlJIGJ1cz4gb24gc21zYzANCnNtc2NwaHkwOiA8U01DIExBTjg3MDAgMTAvMTAwIGludGVy
ZmFjZT4gUEhZIDEgb24gbWlpYnVzMA0Kc21zY3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwg
MTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQp1ZTA6IDxVU0IgRXRoZXJuZXQ+IG9uIHNt
c2MwDQp1ZTA6IEV0aGVybmV0IGFkZHJlc3M6IGI4OjI3OmViOjY0OjhiOjU3DQp1Z2VuMS40OiA8
VVNCIEFkYXB0ZXIgVVNCIERldmljZT4gYXQgdXNidXMxDQp1a2JkMCBvbiB1aHViMQ0KdWtiZDA6
IDxVU0IgQWRhcHRlciBVU0IgRGV2aWNlLCBjbGFzcyAwLzAsIHJldiAxLjEwLzAuMDEsIGFkZHIg
ND4gb24gdXNidXMxDQprYmQxIGF0IHVrYmQwDQp1ZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBV
UA0Kc21zYzA6IGNoaXAgMHhlYzAwLCByZXYuIDAwMDINCnVlMDogbGluayBzdGF0ZSBjaGFuZ2Vk
IHRvIERPV04NCnVlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQp1Z2VuMS42OiA8QTRUZWNo
IFVTQiBLZXlib2FyZD4gYXQgdXNidXMxDQp1a2JkMSBvbiB1aHViMQ0KdWtiZDE6IDxBNFRlY2gg
VVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDUsIGFkZHIgNj4gb24gdXNidXMx
DQprYmQyIGF0IHVrYmQxDQp1aGlkMCBvbiB1aHViMQ0KdWhpZDA6IDxBNFRlY2ggVVNCIEtleWJv
YXJkLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMDUsIGFkZHIgNj4gb24gdXNidXMxDQoNCg==
--000000000000f637b505d8e3b600--

From nobody Sat Feb 26 09:28:59 2022
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 410A619E9CCF
	for ; Sat, 26 Feb 2022 16:01:24 +0000 (UTC)
	(envelope-from mayuresh.w1@gmail.com)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431])
	(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 4K5WbR1tRKz3Kgj
	for ; Sat, 26 Feb 2022 16:01:23 +0000 (UTC)
	(envelope-from mayuresh.w1@gmail.com)
Received: by mail-wr1-x431.google.com with SMTP id b5so8906462wrr.2
        for ; Sat, 26 Feb 2022 08:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:resent-from:resent-date:resent-message-id:resent-to:date
         :from:to:subject:message-id:mime-version:content-disposition;
        bh=Gft8cQwT2cl6GZnxuVirKdzgDdNCfYApumvTLmVpsRE=;
        b=EAV4d7N+t81OUsVhLt7hFBmYU8iSMJ/OlB4wUePFtCyZCIkXyjc01NktSD/ZKKPWDI
         HZ+c6yKSaJXq6fzTltzbCQv5ByPXfaYVnPmLOZzWNtxMABS/aydcDjB5dz6gVPi24eap
         TntMr7w10pzHSo3Zw/8uAzmc4AlaZ/g+P9sOle/zfk6xx9fhPFvz+9p/VghnZPVhckXG
         zzECBLBACxXmbEjz1qMRBI0YVplnTYTKu7lgaR9laCbpW5+jLT/4sKA9V4HFxl3Jdj7p
         X9UhRnFbQepwTrnLhJz3r4UmpIPWxkxNgWT3htqF76DvGlCvqxL9wtqYYRVhkFyXswHQ
         RZoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:resent-from:resent-date:resent-message-id
         :resent-to:date:from:to:subject:message-id:mime-version
         :content-disposition;
        bh=Gft8cQwT2cl6GZnxuVirKdzgDdNCfYApumvTLmVpsRE=;
        b=dVONzrCZbIXQlKXy7gBq52Sla52dbNq+Nw88Js8BaGSwuJ3G/DSL/jNZCqBQacJhLc
         1GwBdlTRFo3arHmn1z9HyyXA7f+/o8V3GNV5sKu4EWnUvqTV6yt3t6Vd7qrvXoHjvcKV
         H1A9uVpo7+KJhx09/0978baIOsXxc1LpEZqyLUL2kBPPVsxsN+7zxQPwvPScBksTxofO
         CBOBGIT6rvtWozPUIaY2aD7OEmqwq3QBZUeclnnLWxUVRRof9fSbINgg0Akd/jt4u8nD
         Hgmn4y4Gqrv5OFyAf94CyBd6vAo4Y5nwi3bUEjdy3g8/hc7PTj14P7J4o+n+91+oIbg5
         UayQ==
X-Gm-Message-State: AOAM533fqZJTHsRvMQf0N1aDAGK7ONJ1K2YCJSlPDIqWBA5tUML9ifb5
	coyiyTLsuw2TZIgdD7dJRY1OtKrPqbTjiw==
X-Google-Smtp-Source: ABdhPJwiGkEIRzgzAlz02IuXUYuqz1uBJin848wP7F5O2opkMK+VOLpzrRx8Vjg4QAC48P8i2J+mWA==
X-Received: by 2002:adf:90ca:0:b0:1ea:99dd:db45 with SMTP id i68-20020adf90ca000000b001ea99dddb45mr9898430wri.262.1645891281718;
        Sat, 26 Feb 2022 08:01:21 -0800 (PST)
Received: from localhost (warunjikardental.com. [116.203.142.195])
        by smtp.gmail.com with ESMTPSA id l5-20020adff485000000b001d54142b02bsm5322254wro.85.2022.02.26.08.01.21
        for 
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 26 Feb 2022 08:01:21 -0800 (PST)
Resent-From: Mayuresh 
Resent-Date: Sat, 26 Feb 2022 21:31:20 +0530
Resent-Message-ID: <20220226160120.broyrrqrpcr5bala@localhost>
Resent-To: freebsd-arm@FreeBSD.org
Date: Sat, 26 Feb 2022 14:58:59 +0530
From: Mayuresh 
To: freebsd-arm@FreeBSD.org
Subject: FreeBSD 13 on RPI4 : stuck at splash screen
Message-ID: <20220226092858.pnbtdwq2uyoc5rgb@localhost>
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-Rspamd-Queue-Id: 4K5WbR1tRKz3Kgj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=EAV4d7N+;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mayureshw1@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=mayureshw1@gmail.com
X-Spamd-Result: default: False [-2.69 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[mayuresh@acm.org,mayureshw1@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mayuresh@acm.org,mayureshw1@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[acm.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 736
Lines: 24

Hello,

I am new to FreeBSD for any architecture.

Was trying out FreeBSD 13 downloaded from here[1] on RPI4 8G device.
However the device did not go past the splash screen.

As some web pages suggest (probably those were for RPI40), tried inserting
the sd card into a USB adapter and tried booting from USB. But the device
then shows "insert SD card" message.

I had dd'ed it on an sdcard. This operation looks ok as I am able to mount
and examine the sdcard's boot partition on Linux.

The device normally runs Raspberry OS and is working fine.

Please suggest if there is something I could try.


[1]
https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz

-- 
Mayuresh

From nobody Sun Feb 27 02:42:06 2022
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 30CE919F66E9
	for ; Sun, 27 Feb 2022 02:42:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K5nq26z22z3vCw
	for ; Sun, 27 Feb 2022 02:42:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645929734; bh=9EXVTVqLcAwUnGEwV/GzTCVsPNBMMj8LA8e7WOgILTE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EO72nO7tUz8kfKCwerTF2MBD7UnAi0PqtGn4eG6jzj2rsXSmZtGakjT9rZP2uM5RyY8XPBTi5DoIfaIun+N3Ga6hvxuS84sLSF3apJzPSln//Kqg18V56nDAvOuz3AHZ6TvHxY+JLqvO9rs/x84juSqpSB8OSvnUIqPmboXIznBdn2aKOM10Gj58mfbEakmUdxyF8UMVaJNQUqsz396CC6wdaplaUy9va4y51svkAGmOG9FjbFYjQ8M2ajEzQuLSChT+M9J9wYlrwNFT9i4PqEnwHk9hqveClvec4mLjrYFjOaw7mSlT74dUfPMlie62jEuMsdY9Z3AG1+XwGaVqXA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645929734; bh=u1p2NHX+tSJV2bIGigSZoeOjfMNE0U2abubfTDC6Zfc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GODyHe3GDyQ4gCszYv2eUSPbwcxgtahg/M6MYE/cuc2u3zXXnOhOmkUaeLb8UfyQI2mqm2wIT5foIlW5XW0oYsvBNy5FRnUEzU/7wOJfmIqqcKFlL84pFuTFdUZk0fHnvDARITkEYmZrBlJiz6KDyFABnVM7fUIPjod1/xDl3cCf2sDgoQE6XA2HWygBXI0qj08BHXv+9e48AV9PsrUQbiOIEisPVV10J7W4D2XMxpQggVAPNtu8yR0gdj6tbxdmezEzZTabu7uTrt5JU6Ep1JxJoXv6VYysVOq0gH/LBhNpqYuryfirtB8HUjTkDRAUFafHtKx8N7PQ7HcDfTa1YA==
X-YMail-OSG: g46HeQwVM1l2pRp9nUdpvrFIidVMBFy.KygYsNmjF9ApCrJHsk61RaLAU.JnJux
 mqt2a30ACgn6vqA8PnYZDER2mJdOpNtyStPJyHjykdb2O0Oy2BXGCpFxCU0ZlenSYkzSepnSwlIY
 H6TVIzAPectUu8h9R74dOcvLmR8ndGvIisb_8bcL9.2eWuXVcVYAy2rTWv.lC8DWf5vGeRYLntcS
 LFpGHyEZUtFr.CIn2qd7cr1PNXkSq8i05quEDUFiSO0Qi0Hq2vYcmTz7hX22Nv7IP5sO39FiT.aw
 sIZKcyeQUgQmFAZ9e19AxSiwLRLVf.5tq849VRU7ESQPLU5hX1rY0LuNdSwnGKOKf4vf2DKGGru9
 RmW10Rt07Ax7v6w7dk0xpFaa61BAQ2uYdlZwpA5.71nZqjyb359q1._6.RIc6s4sEL3D8JbHSr3C
 X12UC3qCaECOxZ9uryjyizRBv1Gt8xcSeBt08FlMNUxV20q3pGVArx3P4yLUYhYhHEbQmBb3.RLn
 Zy4e9tqi1cQxFvkEsOrSHgyrgDk8BfRmQToZiFLICxhBS3m3.yJqBJ.SjRwT7A7kkce8BIge_jyh
 oNomjrRlkBvidR0gBk7J07VBYFCnK9Xairrg37i6gt4keeAhmHdZj67sra4w1UslwQmiOaTOsd25
 kDFqMspaH4hKPdAUj.kyI5P9Mg52L87jV0SmUhmCyFeAOSvucE52m.s86zcxsm2ymHGBXpqbyz55
 7rDGZE7A98WcTh1fMWHeE_4t8QF4ljHKHbUbZ5N4E0PbxGAlMvFYA4YFz7N0ZX7VXPN6mYZdb_5U
 UfOT01.VqnOj0FOT8XjZAvb_PA3pdQpW1CE5W_gHbXHNTA.er.JOSMHExS9Fx8X47rgsbVH5YFyB
 CYB4M.KMeYUYAuLEtAp4S8cIDUiQ3ueKb_oqteowIovjp84j28sSmYpDiuxgz2MXKJL7kureVieu
 nM5YGDvAbtxM0d0gRVgRtxKfMMtQYkJyz2hk7XRQrLstynZwpcTa3WE68UuQtNi_8.CWCQW79tke
 35Dcs4dby9oEm6BUu4ljiqAbku2YW_6jG2SLUwuL7psZUgfX9m9SYUccnfIL.b.HIueyQo5rHxc7
 zj7N8fsp7IV6ajWmrE6grxtpK.DUqdFLiH8MPfdXTlYiOjUuMCM_svwu96C09MoH3A50urmte1vm
 gLmtPhg35iHlhC6KXhJP5LLJ9ErcyoFF5Me3cOKnMovD.M2H46YGhH_fX5J1F0_ooJjgSkfT3NfO
 ZExH9_3QBzTZVXwwIzmpW.pixAR23ZkmOl0kn46_wJeDvaFAsYBi5KZEAplEDvcEu4Ysn909ia3A
 V8lCQfP02_vDfnzDZXdBFGYH1dn2D7DFNsdeUNFMJy1sVo4gMcPSD7z5xDHdvCzGkEWcyR.tlSu4
 c7.Dttkpn1uCux4A5khcozC8brcdhpy.a36MOHWmunPqlc.SVT_K.vwAiao6W.Gl2D3IBEp.OGsP
 VrPb5GPLPgkQATlz8w3nmUoUFp3R2s4hCbit_oi.ZSl2RGemxXKz2IQokGyYuKrO5cZE4NMBTbBr
 3K7RtsUvBghXj.x.mvrFC4Zb_5N4xx5uF_r4yVAYzgJeAOuVCsmzbANcLl6JZWRYLHLoH6MWRi_N
 N.6vdRUv6cm45kLHUHklz3uLLa.TWFXPXthWiRvlSPAYluVkiHwJzU2PzpefDeyphctJihzfKxhF
 oEm8F.4eFC_HKwynUQ.yX060.9qQKYI783qx8R1xkZNpEQYNH8wvo0lneQYsEjbxrDOGP5dFYr8L
 E2NXWfyeliccQiz4pqzPrIF6BGEhbbjRW1RcZZeMBcE0voLGY6UDcM_CtS4eUi3Iy3I4ywHjzW_p
 UBhDs.qcUMqJ7q2nMLkFHgvy2LVpyJ1PzC35TC_adO1ztn7Qk2K7dzU8Dpqag937eHLP040deeI7
 tV47F8Oa.7zSiXrNW8vDUMKG2G.65NjruRllRqjzDfPTnmv24LIzLoS.z6iKlOTVxU.T6rrnBv0g
 ZP2SyiNa5ZByffH6dmqy63PsDTTHJ6lq4EMwrA65dKOybTcKzj09CuccWgRnlkBcr8ifOPYkWPIu
 oLJo.tLwydqy4dYuBeVo02HcBsXupz3r7OAwO6flUDcw9TY7VFbrw1A3QHpjXZl4mK.6wQQk0bdF
 u2G7TogBQIPWd9BPYHLWRQWpRyz0x.nicAKZBYpEQx4jJnt3GblTHmLEzwtWTDcd6TYGJiIrr6Yt
 .nyIbkarAWdpbE0XTK5eMmDShsu9X1YeZlqBUUMEDV6D86glThqnFnFMT.BjyFMTJrncB4_oTl3Q
 Iqoykt5VslgW64TrPH1LUYTWLEE6Jq7vBd66CwhBY00eZL3fUBtXq8J0MjmO2DOykHRZzDg6eXMW
 nUylwcbL4iL15F9eSGN8vaDg2KzFxPjyKkYNMbVsCLY5Ux2PHPeV57JOq6cNErjRGkmxHfEucAWL
 OaOoUKLqNA9zjazHj
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 27 Feb 2022 02:42:14 +0000
Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2cb6736cfe93ae4e30f66ad83dfa5a8e;
          Sun, 27 Feb 2022 02:42: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
Date: Sat, 26 Feb 2022 18:42:06 -0800
Cc: freebsd-net@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K5nq26z22z3vCw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=EO72nO7t;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.37 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.13)[0.134];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3109
Lines: 80

On 2022-Feb-17, at 00:02, Mark Millard  wrote:

> On 2022-Feb-16, at 15:18, bob prohaska  wrote:
>=20
>> [changed subject to more clearly reflect the symptoms]
>>=20
>> On Mon, Feb 14, 2022 at 09:59:23PM -0800, Mark Millard wrote:
>>>>>>> Since I have a context working based on the kernel in:
>>>>>>>=20
>>>>>>> =
https://artifact.ci.freebsd.org/snapshot/stable-13/371633ece3ae88e3b3d7a02=
8c372d4ac4f72b503/arm64/aarch64/kernel.txz
>>>>>>>=20
>>>>>>> I recommend that you try that exact same kernel in your
>>>>>>> stable/13 context. I recommend renaming the existing
>>>>>>> /boot/kernel before expanding the kernel.txz into / and
>>>>>>> so causing a new /boot/kernel/ to be filled in.
>>>=20
>>=20
>> It looks like the kernel isn't an obvious culprit: Versions
>> from late October to a few days ago all behave the same way.
>>=20
>> Even when booted single-user, with the ue0 device brought up
>> by hand, only about 1% of incoming pings are answered. That
>> figure rises to a little over 50% when there's an outgoing ping
>> process (both running a 1/seccond). Destination of the ping
>> does not seem to matter, an unused IP seems to work fine.=20
>>=20
>> AIUI, nothing of userland apart from a shell and the ping
>> process will be running under those circumstances. Is this
>> correct?=20
>>=20
>> Might the trouble be inherited from the boot files? I've left
>> them alone since the machine does boot and updating them=20
>> isn't automated. Right now the machine boots from microSD
>> and then runs bootcmd_usb0.
>>=20
>> One oddity noticed during the kernel-swapping experiments
>> is that at the loader prompt some kernel names don't seem
>> to be recognized. If I type kernel or kernel.old it's
>> loaded immediately. If I type kernel.no-bpf which is one
>> I built, booted using the name kernel and then saved with
>> the name kernel.no-bpf it can't be found, even though it's
>> visible via ls at the OK prompt. Might - be a prohibited
>> or priviledged character to the loader? Names like
>> kernel.20220214 are likewise not recognized, even though
>> they're visible using ls.

There might be a name length restriction on the directory
name that contains the kernel files? I know I used to have
problems on old PowerMacs and got in the habit of using
only short names. (So I've not challenged the assumption
in a long time.)

>> For lack of immediately better ideas I've started stress2
>> running in single-user mode to see if anything of interest
>> results.

The following are now available for experiments with microsd
card boot media for testing:

main [so: 14]:

=
http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0=
-CURRENT-arm64-aarch64-RPI-20220224-45c23c2608e-253384.img.xz

stable/13 as 13.1-PRERELEASE (no releng/13.1 branch yet):

=
http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.1/FreeBSD-13.1=
-PRERELEASE-arm64-aarch64-RPI-20220224-9134a398506-249729.img.xz

Can you repeat the problem with either of these as your boot media
content? Which one(s)?

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Feb 27 08:51:38 2022
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 64B8819DED3D
	for ; Sun, 27 Feb 2022 08:52:17 +0000 (UTC)
	(envelope-from daniel@morante.net)
Received: from venus.morante.net (venus.morante.net [63.247.147.163])
	by mx1.freebsd.org (Postfix) with ESMTP id 4K5y1q58Sbz4smy
	for ; Sun, 27 Feb 2022 08:52:15 +0000 (UTC)
	(envelope-from daniel@morante.net)
Received: from venus.morante.net (zenon.morante.com [192.168.0.233])
	by saturn.morante.com (Postfix) with ESMTP id F054D11F80B
	for ; Sun, 27 Feb 2022 03:52:02 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5
X-Spam-RelaysUntrusted: 
Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10;
Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2])
	by venus.morante.net (Postfix) with ESMTPSA id 6E75111F809
	for ; Sun, 27 Feb 2022 03:52:02 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net;
	s=default; t=1645951922;
	bh=hGqJG8qXE+CEFMuSEYomL9rn5hhU8KW6eguII9wM0WU=;
	h=Date:To:From:Subject;
	b=D+XCo555UIT/S3m5M+MVdAPYyDzMLeAshAZtfma/qsZkAUlvtup0119lyAOXX96FE
	 yk8trLIVLVAKX1fD2t5VxHOL5DWNacuIq+uYWkBLRbTDbFVaj5Enarif4km6ovogO2
	 aC7z70FA/+cCmXj7dAo6xNwBp3cwW3feLzMScq1Y=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.104.2 at zenon.morante.com
Content-Type: multipart/mixed; boundary="------------XkPNLy7dWMY4XwgfKPYGUNlZ"
Message-ID: 
Date: Sun, 27 Feb 2022 03:51:38 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
To: freebsd-arm@freebsd.org
Content-Language: en-US
From: Daniel Morante 
Subject: 14-CURRENT Corrupting SPI Flash on Panic?
X-Rspamd-Queue-Id: 4K5y1q58Sbz4smy
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=morante.net header.s=default header.b=D+XCo555;
	dmarc=pass (policy=reject) header.from=morante.net;
	spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net
X-Spamd-Result: default: False [-0.71 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 HAS_ATTACHMENT(0.00)[];
	 TO_DN_NONE(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[morante.net:+];
	 MIME_BASE64_TEXT(0.10)[];
	 CTYPE_MIXED_BOGUS(1.00)[];
	 NEURAL_HAM_SHORT(-0.91)[-0.911];
	 DMARC_POLICY_ALLOW(-0.50)[morante.net,reject];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+];
	 ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[morante.net:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 23376
Lines: 342

This is a multi-part message in MIME format.
--------------XkPNLy7dWMY4XwgfKPYGUNlZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Sometimes (not always) when there is a kernel panic the hardware will no 
longer POST after resetting.  I would have to power down the system AND 
remove all power cables.  Then after reconnecting power its back to a 
bootable state.  I first noticed this happening on 
14-CURRENT-3ede04c78c7.  Snapshots prior to that didn't exhibit this 
behavior. The most recent version I've experienced it on is 
14-CURRENT-45c23c2608e.  This is a ARM64 server (Gigabyte R281-T91).  At 
first I thought it could be bad memory.  I replaced the memory and saw 
no changes.  I sent the server back to the vendor for testing/repair.  
It came back as OK/passing all tests.

Here is the serial over LAN capture of the most recent kernel panic that 
"broke" my server (also attached):
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-45c23c2608e/panic1.txt

Rebooting the server is no longer possible, the UEFI firmware gets stuck 
here (also attached):
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-45c23c2608e/stuckboot.txt

This is what a "good" boot should start out like (also attached):
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-45c23c2608e/goodboot.txt

It seems as if the kernel panic is corrupting the firmware or 
overwriting memory somewhere (sorry I don't fully understand UEFI yet) 
with 1's



--------------XkPNLy7dWMY4XwgfKPYGUNlZ
Content-Type: text/plain; charset=UTF-8; name="panic1.txt"
Content-Disposition: attachment; filename="panic1.txt"
Content-Transfer-Encoding: base64

Q1BVMjUyOiBDYXZpdW0gVGh1bmRlclgyIHIxcDIgYWZmaW5pdHk6ICAxIDI4ICAzDQpDUFUy
NTM6IENhdml1bSBUaHVuZGVyWDIgcjFwMiBhZmZpbml0eTogIDEgMjkgIDMNCkNQVTI1NDog
Q2F2aXVtIFRodW5kZXJYMiByMXAyIGFmZmluaXR5OiAgMSAzMCAgMw0KQ1BVMjU1OiBDYXZp
dW0gVGh1bmRlclgyIHIxcDIgYWZmaW5pdHk6ICAxIDMxICAzDQpSZWxlYXNlIEFQcy4uLmRv
bmUNClJBUyBDT05UUk9MTEVSOiBGYXRhbCB1bnJlY292ZXJhYmxlIGVycm9yIGRldGVjdGVk
DQoNCiAgICAgICAgKioqIE5CVSBFcnJvciAqKioNCg0KDQogIE1QSURSPSAweDgxMDAwMDAw
DQogIENUWF9YMD0gZmZmZmEwMDAwYmQzMDYwMA0KICBDVFhfWDE9IGZmZmYwMDAwMDBmMzg0
MzANCiAgQ1RYX1gyPSBmZmZmMDAwMDAwNzcyMDk4DQogIENUWF9YMz0gMjg2DQogIENUWF9Y
ND0gMA0KICBDVFhfWDU9IGZmZmYwMDAxMWRiOTUyOTANCiAgQ1RYX1g2PSBmMDAxZWUxMA0K
ICBDVFhfWDc9IDANCiAgQ1RYX1g4PSAxDQogIENUWF9YOT0gMA0KICBDVFhfWDEwPSBmZmZm
MDAwMDAwZTVlZTc4DQogIENUWF9YMTE9IDENCiAgQ1RYX1gxMj0gMQ0KICBDVFhfWDEzPSBm
ZmZmYTAwMDE4MTQ5MDgwDQogIENUWF9YMTQ9IGMxDQogIENUWF9YMTU9IDJhZjgNCiAgQ1RY
X1gxNj0gYzENCiAgQ1RYX1gxNz0gMw0KICBDVFhfWDE4PSBmZmZmMDAwMDAwZjM1YjgwDQog
IENUWF9YMTk9IDENCiAgQ1RYX1gyMD0gZmZmZjAwMDAwMGU1ZWU1OA0KICBDVFhfWDIxPSBm
ZmZmMDAwMDAwYjk5MDAwDQogIENUWF9YMjI9IGZmZmYwMDAwMDBlNWVlNzgNCiAgQ1RYX1gy
Mz0gZmZmZmEwMDAwYmM3NjljMA0KICBDVFhfWDI0PSBmZjAwZmZmZQ0KICBDVFhfWDI1PSA0
MzAwMGExMA0KICBDVFhfWDI2PSBmZmZmMDAwMDAwZjJkMDg4DQogIENUWF9YMjc9IGZmZmYw
MDAwNTU3NGUwMDANCiAgQ1RYX1gyOD0gZmZmZjAwMDAwMDc3MjBjNA0KICBDVFhfWDI5PSBm
ZmZmMDAwMTFkYjk1MjkwDQogIENUWF9YMzA9IGZmZmYwMDAwMDA3NzIwYzQNCiAgQ1RYX1gz
MT0gZmZmZmEwMDAwYmQzMGFkMA0KICBDVFhfU0NSX0VMMz0gNzM1DQogIENUWF9SVU5USU1F
X1NQPSA2ZTYzZGMwDQogIENUWF9TUFNSX0VMMz0gNDA0MDAyYzUNCiAgQ1RYX0VMUl9FTDM9
IGZmZmYwMDAwMDA3NzIxMjQNCiBOb2RlIDAgTkJVIDAgRXJyb3IgcmVwb3J0IDoNCiBOQlUg
QkFSIEVycm9yDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzAgOiAweDA4
MjAwNDRjDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzEgOiAweDNmZmZm
ZGMwDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzIgOiAweDAwMDAwMDAw
DQogICAgICBQaHlzaWNhbCBBZGRyZXNzIDogMHgzZmZmZmRjMA0KICAgICAgDQpOQlUgQkFS
IEVycm9yIDogRGVjb2RlZCBpbmZvIDoNCiAgICAgICAgQWdlbnQgaW5mbyA6IENQVQ0KICAg
ICAgICAgICAgQ29yZSBJRCA6IDENCiAgICAgICAgICAgIFRocmVhZCBJRCA6IDANCiAgICAg
ICAgUmVxdTogdHlwZSA6IDQgOiBXcml0ZSBCYWNrDQogTm9kZSAwIE5CVSAxIEVycm9yIHJl
cG9ydCA6DQogTkJVIEJBUiBFcnJvcg0KICAgICAgTkJVdGltZW91dCBzdG9EUmlTZ19jcHVz
Ug0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJFRzAgOiAweDA4MjAwNDRjDQpm
YXVsdCAgTnRyXywgR19CcjogMERmUmZTUzAwMTA5ZF83MDAwIDogMHgwMDAwMDAwMA0KICAg
ICAgUGh5c2ljYWwgQWRkcmVzcyA6IDB4M2ZmZmZkYjANCg0KY3B1aWQgPSAzOSAgICAgIA0K
TkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6DQogICAgICAgIEFnZW50IGluZm8gOiBD
UFUNCiAgICANCiBpbWUgPSAycmUgSUQgOiAxDQogICAgICAgICAgICBUaHJlYWQgSUQgOiAw
DQogICAgICAgIFJlcXU6IHR5cGUgOiA0IDogV3JpdA0KdGFjayBiYWNrdHJhY2U6IE5vZGUg
MCBOQlUgMiBFcnJvciByZXBvcnQgOg0KIE5CVSBCQVIgRXJyb3INCmF0ICAgICBOZGJfdHJh
Y0JfUmVsRERSRVNTX0VSUk9SX1JFRzEgOiAweDNmZmZmZDcwDQogICAgICBOQlVfUkVHX0JB
Ul9BRERSRVNTX0VSUk9SX1JFRzIgOiAweDAwMDAwMDAwDQogICAgUHh5c2ljOmxyOiBwYWVz
aSAgIDB4M2ZmZmZkNzANCiAgICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6
DQogICAgICAgIEFnZW50IGluZm8gOiBDUFUNCiAgICAgICAgICAgdENvICBkIHBpZCAwIHQg
ZCAxMCA1MSAgICBUaHJlYWQgSUQgOiAwDQogICAgICAgIFJlcXU6IHR5cGUgOiA0IDogV3Jp
dGUgQmFjaw0KIE5vZGUgMCBOQlUgMyBFcnJvciByZXBvcnQgOg0KIE5CVSBCQVIgRXJyb3IN
CiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMCA6IDB4MDgyMDA0MWMNCiAg
ICAgIE5CVV8NClN0IHBSZUFEYSBmZmZmMDBSICAgICBrMWJfIG54NHIrMGY0NDANCiAgIDog
dW5kZWZpbmVkQiAgICAgRGY5MDIwRTFmT1JfUkVHMiA6IDB4MDAwMDAwMDANCiAgICAgIFBo
eXNpY2FsIEFkZHJlc3MgOiAweDNmZmZmZDMwDQogICAgICANCk5CVSBCQVIgRXJyb3IgOiBE
ZWNvZGVkIGluZm8gOg0KICAgICAgICBBZ2VudCBpbmZvIDogQ1BVDQogICAgICAgICAgICBD
b3JlIElEIDogMQ0KICAgICAgDQogICAgICAgYj54MjpoZmVmZiBJMCA6MDgNCiBiMiAgICAg
UmUodTogdHhwY3ZlIDEgOmVjZV9wDQpjX3RpdGxlICsgMzMzOTcpIE5vZGUgMCBOQlUgNCBF
cnJvciByZXBvcnQgOg0KIE5CVSBCQVIgRXJyb3INCiAgICAgIE5CVV9SRUdfQkFSX0FERFJF
U1NfRVJST1JfUkVHMCA6IDB4MDgyMDA0NGMNCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1Nf
RVJST1JfUkVHMSA6IDB4DQpmZiAgMCAwTjA4N1I2NDVCQVJfQUQgKEVTU19zUlJPdV9fdEdi
bGUgK3gyMDBkZCkwMA0KICAgICAgUGh5c2ljYWwgQWRkcmVzcyA6IDB4M2ZmZmY4YjANCiAg
ICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6DQogICAgICAgIEFnZW50IGlu
Zm8gOiBDUFUNCiAgICAgICAgICAgIENvcmUgSUQgOiAxDQogICAgICAgICAgICBUaHJlDQog
ICAgICAgICBSZSB1OiB0eXBlIDogNCA6IFdyaXRlIEJhY2sNCiBOb2RlIDAgTkJVIDUgRXJy
b3IgcmVwb3J0IDoNCiBOQlUgQkFSIEVycm9yDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNT
X0VSUk9SX1JFRzAgOiAweDA4MjAwNDRjDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0UN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJPeDU6RWYxIGYgMDAzMWRmMTQ3MDANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBO
QlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzIgOiAweDAwMDAwMDAwDQogICAgICBQaHlz
aWNhbCBBZGRyZXNzIDogMHgzZmZmZjhmMA0KICAgICAgDQpOQlUgQkFSIEVycm9yIDogRGVj
b2RlZCBpbmZvIDoNCiAgICAgICAgQWdlbnQgaW5mbyA6IENQVQ0KICAgIDAgICAgICAgIFRo
cmVhZCBJRCA6IDANCiAgICAgICAgUmVxdTogdHlwZSA6IDQgOiBXcml0ZSBCYWNrDQogTm9k
ZSAwIE5CVSA2IEVycm9yIHJlcG9ydCA6DQogTkJVIEJBUiBFcnJvcg0KICAgICAgTkJVX1JF
R19CQVJfQUREUkVTU19FUlJPUl9SRUcwIDogMHgwODIwMDQ0Yw0KICB4NyAgIEIgICAgRyAg
QSAgIEREMEVTU19FUlJPUl9SRUcxIDogMHgzZmZmZmM0MA0KICAgICAgTkJVX1JFR19CQVJf
QUREUkVTU19FUlJPUl9SRUcyIDogMHgwMDAwMDAwMA0KICAgICAgUGh5c2ljYWwgQWRkcmVz
cyA6IDB4M2ZmZmZjNDANCiAgICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6
DQogIHg4OiAgICAgIHQgaSBmICAgIENQVQ0KICAgICAgICAgICAgQ29yZSBJRCA6IDENCiAg
ICAgICAgICAgIFRocmVhZCBJRCA6IDANCiAgICAgICAgUmVxdTogdHlwZSA6IDQgOiBXcml0
ZSBCYWNrDQogTm9kZSAwIE5CVSA3IEVycm9yIHJlcG9ydCA6DQogTkJVIEJBUiBFcnJvcg0K
Y18gciBlIE5za18rRUc4KUFSX0FERFJFU1NfRVJST1JfUkVHMSA6IDB4M2ZmZmZjMzANCiAg
ICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMiA6IDB4MDAwMDAwMDANCiAgICAg
IFBoeXNpY2FsIEFkZHJlc3MgOiAweDNmZmZmYzMwDQogICAgICANCk5CVSBCQVIgRXJyb3Ig
OiBEZWNvZGVkIGluZm8gOg0KICAgICAgDQogICAgICApICAgICAgVGhyZWFkIElEIDogMA0K
ICAgICAgICBSZXF1OiB0eXBlIDogNCA6IFdyaXRlIEJhY2sNCiBOb2RlIDAgTkJVIDggRXJy
b3IgcmVwb3J0IDoNCiBOQlUgQkFSIEVycm9yDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNT
X0VSUk9SX1JFRzAgOiAweDA4MjAwNDRjDQogICAgICBOQlVfUkVHX0JBUl9BREQNCiB4MTFS
ICAgXyAgICAgOiAweDNmZiBmOGUwDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9S
X1JFRzIgOiAweDAwMDAwMDAwDQogICAgICBQaHlzaWNhbCBBZGRyZXNzIDogMHgzZmZmZmZl
MA0KICAgICAgDQpOQlUgQkFSIEVycm9yIDogRGVjb2RlZCBpbmZvIDoNCiAgICAgICAgQWdl
bnQgaW5mbyA6IENQVQ0KICAgICAgICAgICAgQ29yZSBJRCA6IA0KDQogIDogICAgICAgICBU
NjAwYWQgSUQgOiAwDQogICAgICAgIFJlcXU6IHR5cGUgOiA0IDogV3JpdGUgQmFjaw0KIE5v
ZGUgMCBOQlUgOSBFcnJvciByZXBvcnQgOg0KIE5CVSBCQVIgRXJyb3INCiAgICAgIE5CVV9S
RUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMCA6IDB4MDgyMDA0NGMNCiAgICAgIE5CVV9SRUdf
QkFSX0FERFJFU1NfRVJST1JfUkVHMSANCiAgICAgICAyQmY4UkVHX0JBUl9BRERSRVNTX0VS
Uk9SX1JFRzIgOiAweDAwMDAwMDAwDQogICAgICBQaHlzaWNhbCBBZGRyZXNzIDogMHgzZmZm
ZmJmMA0KICAgICAgDQpOQlUgQkFSIEVycm9yIDogRGVjb2RlZCBpbmZvIDoNCiAgICAgICAg
QWdlbnQgaW5mbyA6IENQVQ0KICAgICAgICAgICAgQ29yZSBJRCA6IDENCiAgICAgICAgIA0K
IHhocjphICAgRCA6IDAgDQogICAgICAgICAgICAgICAgICAgIDIgIFJlcXU6IHR5cGUgOiA0
IDogV3JpdGUgQmFjaw0KIE5vZGUgMCBOQlUgMTAgRXJyb3IgcmVwb3J0IDoNCiBOQlUgQkFS
IEVycm9yDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzAgOiAweDA4MjAw
NDRjDQogICAgICBOQlVfUkVHX0JBUl9BRERSRVNTX0VSUk9SX1JFRzEgOiAweDNmZmZmZjQw
DQogICAxNTogICAgIEVHICBBIF9BMmFSRVNTX0VSUk9SX1JFRzIgOiAweDAwMDAwMDAwDQog
ICAgICBQaHlzaWNhbCBBZGRyZXNzIDogMHgzZmZmZmY0MA0KICAgICAgDQpOQlUgQkFSIEVy
cm9yIDogRGVjb2RlZCBpbmZvIDoNCiAgICAgICAgQWdlbnQgaW5mbyA6IENQVQ0KICAgICAg
ICAgICAgQ29yZSBJRCA6IDENCiAgICAgICAgICAgIFRocmVhZCBJRCA6IDANCiB4ICA6ICAg
UiBxIDogdHkgICA6ZTQgOiBXcml0ZSBCYWNrDQogTm9kZSAwIE5CVSAxMSBFcnJvciByZXBv
cnQgOg0KIE5CVSBCQVIgRXJyb3INCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1Jf
UkVHMCA6IDB4MDgyMDA0NGMNCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVH
MSA6IDB4M2ZmZmZmMzANCiAgICAgIE5CVV9SRUdfQkFSX0FEDQogICAgICAgICAgICAgICAg
ICAgICBFUzc6RVJSICAgIEVHICA6IDAgIDAwMDAwMDANCiAgICAgIFBoeXNpY2FsIEFkZHJl
c3MgOiAweDNmZmZmZjMwDQogICAgICANCk5CVSBCQVIgRXJyb3IgOiBEZWNvZGVkIGluZm8g
Og0KICAgICAgICBBZ2VudCBpbmZvIDogQ1BVDQogICAgICAgICAgICBDb3JlIElEIDogMQ0K
ICAgICAgICAgICAgVGhyZWFkIElEIDogMA0KICAgICAgICBSZXF1OiB0eXBlIDoNCiB4IDhy
IGZmZmZhMGsNCjViMGJmZTAgTm9kZSAwIE5CVSAxMiBFcnJvciByZXBvcnQgOg0KIE5CVSBC
QVIgRXJyb3INCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMCA6IDB4MDgy
MDA0NGMNCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMSA6IDB4M2ZmZmZl
ZjANCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1NfRVJST1JfUkVHMiA6IDB4MDAwMDAwMDAN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgg
ICAgIFAgIHMgICBsIEEgZHJlc3MgOiAweDNmZmZmZWYwDQogICAgICANCk5CVSBCQVIgRXJy
b3IgOiBEZWNvZGVkIGluZm8gOg0KICAgICAgICBBZ2VudCBpbmZvIDogQ1BVDQogICAgICAg
ICAgICBDb3JlIElEIDogMQ0KICAgICAgICAgICAgVGhyZWFkIElEIDogMA0KICAgICAgICBS
ZXF1OiB0eXBlIDogNCA6IFdyaXRlIEJhY2sNCg0KIHgyMDogICAgICAgICAgICAgICAgMSBO
b2RlIDAgTkJVIDEzIEVycm9yIHJlcG9ydCA6DQogTkJVIEJBUiBFcnJvcg0KICAgICAgTkJV
X1JFR19CQVJfQUREUkVTU19FUlJPUl9SRUcwIDogMHgwODIwMDQ0Yw0KICAgICAgTkJVX1JF
R19CQVJfQUREUkVTU19FUlJPUl9SRUcxIDogMHgzZmZmZmViMA0KICAgICAgTkJVX1JFR19C
QVJfQUREUkVTU19FUlJPUl9SRUcyIHggMTowMCAgMCAwICANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMGh5c2ljYWwgQWRkcmVz
cyA6IDB4M2ZmZmZlYjANCiAgICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6
DQogICAgICAgIEFnZW50IGluZm8gOiBDUFUNCiAgICAgICAgICAgIENvcmUgSUQgOiAxDQog
ICAgICAgICAgICBUaHJlYWQgSUQgOiAwDQogICAgICAgIFJlcXU6IA0KMCBOb2RlIDAgTkJV
IDE0IEVycm9yIHJlcG9ydCA6Y2E5MA0KIE5CVSBCQVIgRXJyb3INCiAgICAgIE5CVV9SRUdf
QkFSX0FERFJFU1NfRVJST1JfUkVHMCA6IDB4MDgyMDA0NGMNCiAgICAgIE5CVV9SRUdfQkFS
X0FERFJFU1NfRVJST1JfUkVHMSA6IDB4M2ZmZmZlNzANClIgRzIzOlJmQUREUkVTU19FUlJP
NDhhMUcyIDogMHgoMG8wZXgwY3ZlLiAgeCAgdl9wc29jYXQgQWxkICsgMiA4Nil4M2ZmZmZl
NzANCiAgICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29kZWQgaW5mbyA6DQogICAgICAgIEFn
ZW50IGluZm8gOiBDUFUNCiAgICAgICAgICAgIENvcmUgSUQgOiAxDQogICAgICAgICAgICBU
aHJlYWQgSUQgOiAwDQogICAgICAgIFJlcXU6IHR5cGUgOiA0IDogV3JpdGUgQmFjaw0KDQog
eDI0OiBmZmZmMDAwMDAwOGU3MDQxIChkaWdpdHMgKyAxOTRkYSkgTm9kZSAwIE5CVSAxNSBF
cnJvciByZXBvcnQgOg0KIE5CVSBCQVIgRXJyb3INCiAgICAgIE5CVV9SRUdfQkFSX0FERFJF
U1NfRVJST1JfUkVHMCA6IDB4MDgyMDA0NGMNCiAgICAgIE5CVV9SRUdfQkFSX0FERFJFU1Nf
RVJST1JfUkVHMSA6IDB4M2ZmZmZlMTANCiAgICAgIE5CVV9SRUdfQkFSX0ENCiAgICAgICAg
ICAgICAgICAgICBEeEU1U19FIFIgUl9SRUcgICAgIHgxMDAwMDAwMA0KICAgICAgUGh5c2lj
YWwgQWRkcmVzcyA6IDB4M2ZmZmZlMTANCiAgICAgIA0KTkJVIEJBUiBFcnJvciA6IERlY29k
ZWQgaW5mbyA6DQogICAgICAgIEFnZW50IGluZm8gOiBDUFUNCiAgICAgICAgICAgIENvcmUg
SUQgOiAxDQogICAgICAgICAgICBUaHJlYWQgSUQgOiANCg0KICAgIGYgZiAwMDAxOjV0MGRl
ZjogNCA6IFdyaXRlIEJhY2sNCg0KQ3VycmVudCBOQlUgRFJBTSBCQVIgc2V0dGluZzoNCk5v
ZGUwIEJBUjAgQmFzZSAwMDAwNDAwMCBMaW1pdCAwMDAwN0ZGQyBjaGFuX3hsYXRpb24gMDAw
MDQwMDggbm9kZV94bGF0aW9uIDAwMDAwMDAwDQpOb2RlMCBCQVIxIEJhc2UgMDAwODAwMDEg
TGltaXQNCjROb2RlMCBCQVIyIEJhc2UgMDA4ODAwMDEgTGltaXQgMDBGRkNGRkMgY2hhbl94
bGF0aW9uIDAwN0ZEMDA4IG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9kZTAgQkFSMyBCYXNl
IDAwRkZEMDAxIExpbWl0IDAwRkZGRkZDIGNoYW5feGxhdGlvbiAwMEZGRDAwOCBub2RlX3hs
YXRpb24gMDAwMDAwMDINCg0Kb3gyMDpCZmZmIDBhMGUwMDg4MDY0NTEgTGltaXQoMGFtRkNG
RnR1c19hbmJ4bGF0IG8zIGQ4N0ZEMDA4IG5vZGVfeGxhdGlvbiAwMDAwMDAwMg0KTm9kZTAg
QkFSNSBCYXNlIEZGRkZGMDAwIExpbWl0IDAwMDAwMDAwIGNoYW5feGxhdGlvbiAwMDAwMDAw
MCBub2RlX3hsYXRpb24gMDAwMDAwMDANCk5vZGUwIEJBUjYgQmFzZSBGRkZGRjAwMCBMaW1p
dCAwMDAwMDAwMCBjaGFuX3hsYXRpb24gMDAwMDAwIHggOTpkZV9mbDB0aW8xIDAwMGYwMDAw
DQpOb2RlMCBCQVI3IEJhc2UgRkZGRkYwMDAgTGltaXQgMDAwMDAwMDAgY2hhbl94bGF0aW9u
IDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KMCAwczAgQkFSOCBCYXNlIEZGRkZG
MDAwIExpbWl0IDAwMDAwMDAwIGNoYW5feGxhdGlvbiAwMDAwMDAwMCBub2RlX3hsYXRpb24g
MDAwMA0KICAgIDpvZGVmZkIwMDkgNWEwZWZGMEZGRjAwMCBMaW1pdCAwMDAwMDAwMCBjaGFu
X3hsYXRpb24gMDAwMDAwMDAgbm9kZV94bGF0aW9uIDAwMDAwMDAwDQpOb2RlMCBCQVIxMCBC
YXNlIEZGRkZGMDAwIExpbWl0IDAwMDAwMDAwIGNoYW5feGxhdGlvbiAwMDAwMDAwMCBub2Rl
X3hsYXRpb24gMDAwMDAwMDANCk4NCmUwbEI6UmZmZmYwc2UwRjA3RkYwMDAgTGltaXQgMDBv
MDBsMWhfY3lhY194bGE1aSluIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9k
ZTAgQkFSMTIgQmFzZSBGRkZGRjAwMCBMaW1pdCAwMDAwMDAwMCBjaGFuX3hsYXRpb24gMDAw
MDAwMDAgbm9kZV94bGF0aW9uIDAwMDAwMDAwDQpOb2RlMCBCQVIxMyBCYXNlIEZGRkZGMDAw
IExpbWl0ICAwbHIwIGZmZmMwYTBfeGxhdGk3YiAwMDAwMDAwICh1b2RlX19pbnRubysgMTAp
MDAwMDANCk5vZGUwIEJBUjE0IEJhc2UgRkZGRkYwMDAgTGltaXQgMDAwMDAwMDAgY2hhbl94
bGF0aW9uIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9kZTAgQkFSMTUgQmFz
ZSBGRkZGRjAwMCBMaW1pdCAwMDAwMDAwMCBjaGFuX3hsYXRpc3IgIDAwMCAwMDAgODA0MDB4
YzV0aW9uIDAwMDAwMDAwDQpOb2RlMSBCQVIwIEJhc2UgMDAwMDQwMDAgTGltaXQgMDAwMDdG
RkMgY2hhbl94bGF0aW9uIDAwMDA0MDA4IG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9kZTEg
QkFSMSBCYXNlIDAwMDgwMDAxIExpbWl0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmRnJGRiAgYyAgIF94ICAgaSAgIDAwMDdDMDA4IG5vZGVfeGxhdGlvbiAwMDAwMDAw
MA0KTm9kZTEgQkFSMiBCYXNlIDAwODgwMDAxIExpbWl0IDAwRkZDRkZDIGNoYW5feGxhdGlv
biAwMDdGRDAwOCBub2RlX3hsYXRpb24gMDAwMDAwMDANCmVwYTBpYzogVTEgTG5tbHRkMDBG
RkZGRkMgY25hbCB4YXR0IG9uIHIwRkZEMDA4IG5vZGVfeGxhdGlvbiAwMDAwMDAwMg0KTm9k
ZTEgQkFSNCBCYXNlIDA4ODAwMDAxIExpbWl0IDA4RkZDRkZDIGNoYW5feGxhdGlvbiAwODdG
RDAwOCBub2RlX3hsYXRpb24gMDAwMDAwMDINCk5vZGUxIEJBUjUgQmFzZSBGRkZGRjAwMCBM
aW1pdCAwMDAwMA0KMCBjaWFuPXgxYXRpb24gMDAwMDAwMDAgbm9kZV94bGF0aW9uIDAwMDAw
MDAwDQpOb2RlMSBCQVI2IEJhc2UgRkZGRkYwMDAgTGltaXQgMDAwMDAwMDAgY2hhbl94bGF0
aW9uIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9kZTEgQkFSNyBCYXNlIEZG
RkYNCnQwbUwgbWl0IDAwMDAwMDAwIGNoYW5feGxhdGlvbiAwMDAwMDAwMCBub2RlX3hsYXRp
b24gMDAwMDAwMDANCk5vZGUxIEJBUjggQmFzZSBGRkZGRjAwMCBMaW1pdCAwMDAwMDAwMCBj
aGFuX3hsYXRpb24gMDAwMDAwMDAgbm9kZV94bGF0aW9uIDAwMDAwMDAwDQpOb2RlMQ0KQURC
OkJzdGVja0ZGRmMwMDBhTGk6aXQgMDAwMDAwMDAgY2hhbl94bGF0aW9uIDAwMDAwMDAwIG5v
ZGVfeGxhdGlvbiAwMDAwMDAwMA0KTm9kZTEgQkFSMTAgQmFzZSBGRkZGRjAwMCBMaW1pdCAw
MDAwMDAwMCBjaGFuX3hsYXRpb24gMDAwMDAwMDAgbm9kZV94bGF0aW9uIDAwMDAwMDAwDQpO
b2RlMSBCQVJfdHJCY3NfIGVGZkYpIGEwIExpbWlkIDAwcjBjMF9zZWxmYW5feGxhdGlvbiAw
MDAwMDAwMCBub2RlX3hsYXRpb24gMDAwMDAwMDANCk5vZGUxIEJBUjEyIEJhc2UgRkZGRkYw
MDAgTGltaXQgMDAwMDAwMDAgY2hhbl94bGF0aW9uIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAw
MDAwMDAwMA0KTm9kZTEgQkFSMTMgQmFzZSBGRkZGDQogICAgICAgICAgICAgICAgICAgICAw
MFVwdGltZTogMjAwMDAwMDAgY2hhbl94bGF0aW9uIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAw
MDAwMDAwMA0KTm9kZTEgQkFSMTQgQmFzZSBGRkZGRjAwMCBMaW1pdCAwMDAwMDAwMCBjaGFu
X3hsYXRpb24gMDAwMDAwMDAgbm9kZV94bGF0aW9uIDAwMDAwMDAwDQo1IEJhc2UgRkZGRkYw
MDAgTGltaXQgMDAwMDAwMDAgY2hhbl94bGF0aW9uIDAwMDAwMDAwIG5vZGVfeGxhdGlvbiAw
MDAwMDAwMA0KDQpkYj4gYnQgICANClRyYWNpbmcgcGlkIDAgdGlkIDEwMDUxMiB0ZCAweGZm
ZmZhMDAwMDgwOTMwMDANCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxmDQpkYj4g
cmVzZXQ=
--------------XkPNLy7dWMY4XwgfKPYGUNlZ
Content-Type: text/plain; charset=UTF-8; name="stuckboot.txt"
Content-Disposition: attachment; filename="stuckboot.txt"
Content-Transfer-Encoding: base64

Um9tLi4uDQpDUkM6IGxlbj0weGYwODAsIGNhbD0weDI3ZmY1ZGU5LCBpbWc9MHgyN2ZmNWRl
OSwgbWF0Y2ghDQoNCkxvYWRpbmcgZnJvbSBib290IGRldmljZSBTUEkgTk9SIA0KSGVhZGVy
Og0KICAwMDB8MHgyM2ZmZGMwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBG
RiBGRiBGRiBGRiBGRiBGRiANCiAgMDEwfDB4MjNmZmRkMDogICBGRiBGRiBGRiBGRiBGRiBG
RiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDAyMHwweDIzZmZkZTA6ICAg
RkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAw
MzB8MHgyM2ZmZGYwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBG
RiBGRiBGRiBGRiANCiAgMDQwfDB4MjNmZmUwMDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBG
RiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDA1MHwweDIzZmZlMTA6ICAgRkYgRkYg
RkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwNjB8MHgy
M2ZmZTIwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBG
RiBGRiANCiAgMDcwfDB4MjNmZmUzMDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYg
RkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDA4MHwweDIzZmZlNDA6ICAgRkYgRkYgRkYgRkYg
RkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwOTB8MHgyM2ZmZTUw
OiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAN
CiAgMEEwfDB4MjNmZmU2MDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYg
RkYgRkYgRkYgRkYgRkYgDQogIDBCMHwweDIzZmZlNzA6ICAgRkYgRkYgRkYgRkYgRkYgRkYg
RkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwQzB8MHgyM2ZmZTgwOiAgIEZG
IEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMEQw
fDB4MjNmZmU5MDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYg
RkYgRkYgRkYgDQogIDBFMHwweDIzZmZlYTA6ICAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYg
IEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwRjB8MHgyM2ZmZWIwOiAgIEZGIEZGIEZG
IEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMTAwfDB4MjNm
ZmVjMDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYg
RkYgDQogIDExMHwweDIzZmZlZDA6ICAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZG
IEZGIEZGIEZGIEZGIEZGIEZGIA0KICAxMjB8MHgyM2ZmZWUwOiAgIEZGIEZGIEZGIEZGIEZG
IEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMTMwfDB4MjNmZmVmMDog
ICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQog
IDE0MHwweDIzZmZmMDA6ICAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZG
IEZGIEZGIEZGIEZGIA0KICAxNTB8MHgyM2ZmZjEwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZG
IEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMTYwfDB4MjNmZmYyMDogICBGRiBG
RiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDE3MHww
eDIzZmZmMzA6ICAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZG
IEZGIEZGIA0KICAxODB8MHgyM2ZmZjQwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBG
RiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMTkwfDB4MjNmZmY1MDogICBGRiBGRiBGRiBG
RiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDFBMHwweDIzZmZm
NjA6ICAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZG
IA0KICAxQjB8MHgyM2ZmZjcwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBG
RiBGRiBGRiBGRiBGRiBGRiANCiAgMUMwfDB4MjNmZmY4MDogICBGRiBGRiBGRiBGRiBGRiBG
RiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDFEMHwweDIzZmZmOTA6ICAg
RkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAx
RTB8MHgyM2ZmZmEwOiAgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBG
RiBGRiBGRiBGRiANCiAgMUYwfDB4MjNmZmZiMDogICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBG
RiAgRkYgRkYgRkYgRkYgRkYgRkYgRkYgRkYg
--------------XkPNLy7dWMY4XwgfKPYGUNlZ
Content-Type: text/plain; charset=UTF-8; name="goodboot.txt"
Content-Disposition: attachment; filename="goodboot.txt"
Content-Transfer-Encoding: base64

Um9tLi4uDQpDUkM6IGxlbj0weGYwODAsIGNhbD0weDI3ZmY1ZGU5LCBpbWc9MHgyN2ZmNWRl
OSwgbWF0Y2ghDQoNCkxvYWRpbmcgZnJvbSBib290IGRldmljZSBTUEkgTk9SIA0KSGVhZGVy
Og0KICAwMDB8MHgyM2ZmZGMwOiAgIDAxIDAyIEZGIEZGIDRDIDQ2IDQzIDUzICAwMCAwNCAw
MCAwMCAxMCBGQiAwNSAwMCANCiAgMDEwfDB4MjNmZmRkMDogICAwMSAwNCBGRiBGRiA0QyA0
NiA0MyA1MyAgMDAgMDAgMDYgMDAgRDggOTIgMDAgMDAgDQogIDAyMHwweDIzZmZkZTA6ICAg
MDEgMDMgRkYgRkYgNEMgNDYgNDMgNTMgIDAwIDAwIDA3IDAwIDE1IDhFIDAwIDAwIA0KICAw
MzB8MHgyM2ZmZGYwOiAgIDAxIDA1IEZGIEZGIDRDIDQ2IDQzIDUzICAwMCAwMCAwOCAwMCAw
MCAwMCAwQiAwMSANCiAgMDQwfDB4MjNmZmUwMDogICAwMSAwNiBGRiBGRiA0QyA0NiA0MyA1
MyAgMDAgMDAgMTMgMDEgRkQgMTcgMDAgMDAgDQogIDA1MHwweDIzZmZlMTA6ICAgMDEgMTQg
RkYgRkYgNEMgNDYgNDMgNTMgIDAwIDAwIDE0IDAxIDhDIDNFIDAwIDAwIA0KICAwNjB8MHgy
M2ZmZTIwOiAgIDdGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBG
RiBGRiANCiAgMDcwfDB4MjNmZmUzMDogICA3RiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYg
RkYgRkYgRkYgRkYgRkYgRkYgRkYgDQogIDA4MHwweDIzZmZlNDA6ICAgN0YgRkYgRkYgRkYg
RkYgRkYgRkYgRkYgIEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwOTB8MHgyM2ZmZTUw
OiAgIDdGIEZGIEZGIEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAN
CiAgMEEwfDB4MjNmZmU2MDogICA3RiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYg
RkYgRkYgRkYgRkYgRkYgDQogIDBCMHwweDIzZmZlNzA6ICAgMDEgMTYgRkYgRkYgNEMgNDYg
NDMgNTMgIDAwIDAwIDE1IDAxIDAwIDAwIDBBIDAwIA0KICAwQzB8MHgyM2ZmZTgwOiAgIDAx
IDA3IEZGIEZGIDRDIDQ2IDQzIDUzICAwMCAwMCAxRiAwMSBFMCAzRCAxQiAwMCANCiAgMEQw
fDB4MjNmZmU5MDogICA3RiBGRiBGRiBGRiBGRiBGRiBGRiBGRiAgRkYgRkYgRkYgRkYgRkYg
RkYgRkYgRkYgDQogIDBFMHwweDIzZmZlYTA6ICAgN0YgRkYgRkYgRkYgRkYgRkYgRkYgRkYg
IEZGIEZGIEZGIEZGIEZGIEZGIEZGIEZGIA0KICAwRjB8MHgyM2ZmZWIwOiAgIEZGIEZGIEZG
IEZGIEZGIEZGIEZGIEZGICBGRiBGRiBGRiBGRiBGRiBGRiBGRiBGRiANCiAgMTAwfDB4MjNm
ZmVjMDogICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg
MDAgDQogIDExMHwweDIzZmZlZDA6ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAw
IDAwIDAwIDAwIDAwIDAwIDAwIA0KICAxMjB8MHgyM2ZmZWUwOiAgIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIDAwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCANCiAgMTMwfDB4MjNmZmVmMDog
ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgDQog
IDE0MHwweDIzZmZmMDA6ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAw
IDAwIDAwIDAwIDAwIA0KICAxNTB8MHgyM2ZmZjEwOiAgIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCANCiAgMTYwfDB4MjNmZmYyMDogICAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgDQogIDE3MHww
eDIzZmZmMzA6ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAw
IDAwIDAwIA0KICAxODB8MHgyM2ZmZjQwOiAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAw
MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCANCiAgMTkwfDB4MjNmZmY1MDogICAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgDQogIDFBMHwweDIzZmZm
NjA6ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IA0KICAxQjB8MHgyM2ZmZjcwOiAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCANCiAgMUMwfDB4MjNmZmY4MDogICAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgDQogIDFEMHwweDIzZmZmOTA6ICAg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIA0KICAx
RTB8MHgyM2ZmZmEwOiAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCANCiAgMUYwfDB4MjNmZmZiMDogICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgDQoNCkxvYWRpbmcgTm9ybWFsIEltYWdlIGZy
b20gdGFibGUgb2Zmc2V0IDQwMCANCkNSQzogbGVuPTB4NWZiMTAsIGNhbD0weDEzNTJhZTU4
LCBpbWc9MHgxMzUyYWU1OCwgbWF0Y2ghDQoNCiBKdW1wIHRvIEJvb3QxIEAweDIyMDAwMDAN
Cg0KPT09PT09PT09PT09PT09PT09PT09DQogQ2F2aXVtIENOOTlYWCBCT09UMQ0KPT09PT09
PT09PT09PT09PT09PT09DQogVmVyc2lvbiA6IFRYMi1GVy1SZWxlYXNlLTcuMy1idWlsZF8w
MQ0KIEJ1aWx0IGF0IDE2OjIwOjMyIG9uIEF1ZyAxMyAyMDIwDQo9PT09PT09PT09PT09PT09
PT09PT0NCg0KU1BJIE5PUiBkZXZpY2UgaW5mb3JtOiBub2RlPTAsIGNzPTAsIGtoej0wDQog
IENoaXAgU2VsZWN0aW9uIDogMA0KICAgICBEZXZpY2UgTmFtZSA6IA0KICAgIE1hbnVmYWN0
dXJlciA6IDB4MjAsIE1JQ1JPTg0KICAgICAgICBJRCBDb2RlcyA6IDB4YmEyMCwgMHgxMDQ0
DQogIEJ5dGVzIFBlciBQYWdlIDogMHgxMDANCiBQYWdlIFBlciBTZWN0b3IgOiAweDEwMA0K
ICAgVG90YWwgU2VjdG9ycyA6IDB4NDAwDQpPVFA6IEZyZXE6IGNvcmUgMjE5OSwgbWVtIDIx
OTksIHNvY24gNjY2LCBzb2NzIDExOTkNCg==

--------------XkPNLy7dWMY4XwgfKPYGUNlZ--

From nobody Sun Feb 27 14:59:15 2022
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 9F85719D31D4
	for ; Sun, 27 Feb 2022 14:59:24 +0000 (UTC)
	(envelope-from SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K669R37w3z4TyL
	for ; Sun, 27 Feb 2022 14:59:23 +0000 (UTC)
	(envelope-from SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl)
Date: Sun, 27 Feb 2022 15:59:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1645973956;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=PhNf5eB8FiDwomgX8i0jggKbSjxOAyzMDYTA8Ycj4R4=;
	b=WPh+LLijOnbY+Z9wFahYvgjbj0v430+krDUQqW+CNTwd9sURpgyWBvuGICkFQtz50xOZyU
	TtuyrQmGlGa56OJ6WAIP/tA6KlPaYF5lBgHu/dDe54Nhh/hOggP0pf8hVxh4b9bikadPYz
	Nlp/t8vmvN7FmvQ0cxSxFaoqNPoaA2wgZN6RvWYnAyzY40V9uJOLUPjNSJj2kOcNChErwZ
	i5OBoESrPIZApXUH6Iw0XjigYH9J7Ahy2DYZ21qNcGDiRyIn8M7F/ljS45CvJeszntVgbb
	XnC32tl/V8wRgtklFqbt2cJzfnFPCI9s3AfnjKeUw99DEBYayhEZYP9Lwx9mnw==
From: Ronald Klop 
To: freebsd-arm@FreeBSD.org, Mayuresh 
Message-ID: <465995159.19255.1645973955854@localhost>
In-Reply-To: <20220226092858.pnbtdwq2uyoc5rgb@localhost>
Subject: Re: FreeBSD 13 on RPI4 : stuck at splash screen
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="----=_Part_19254_873059473.1645973955852"
X-Mailer: Realworks (596.36.420274e)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4K669R37w3z4TyL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=WPh+LLij;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.15 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.95)[-0.947];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3923
Lines: 115

------=_Part_19254_873059473.1645973955852
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,


Just guessing. I assume you have connected a HDMI screen? It might be that =
the default output is on a serial console (which you don=E2=80=99t have con=
nected).
Can you ssh to the RPI?
It is also possible to set some variables to choose the hdmi as output.=20


Anyway. I don=E2=80=99t use hdmi on my rpi so I might be totally wrong here=
.=20


Regards,
Ronald


Van: Mayuresh 
Datum: 26 februari 2022 17:02
Aan: freebsd-arm@FreeBSD.org
Onderwerp: FreeBSD 13 on RPI4 : stuck at splash screen

>=20
>=20
> Hello,
>=20
> I am new to FreeBSD for any architecture.
>=20
> Was trying out FreeBSD 13 downloaded from here[1] on RPI4 8G device.
> However the device did not go past the splash screen.
>=20
> As some web pages suggest (probably those were for RPI40), tried insertin=
g
> the sd card into a USB adapter and tried booting from USB. But the device
> then shows "insert SD card" message.
>=20
> I had dd'ed it on an sdcard. This operation looks ok as I am able to moun=
t
> and examine the sdcard's boot partition on Linux.
>=20
> The device normally runs Raspberry OS and is working fine.
>=20
> Please suggest if there is something I could try.
>=20
>=20
> [1]
> https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/F=
reeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz
>=20
> --=20
> Mayuresh
>=20
>=20
>=20
>=20
>=20
------=_Part_19254_873059473.1645973955852
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

Just guessing. I assume y=
ou have connected a HDMI screen? It might be that the default output is on =
a serial console (which you don=E2=80=99t have connected).
Can yo=
u ssh to the RPI?
It is also possible to set some variables to ch=
oose the hdmi as output. 

Anyway. I don=E2=
=80=99t use hdmi on my rpi so I might be totally wrong here. 

Regards,
Ronald

Van: Mayuresh <mayuresh@acm.org>
Datum: 26 februari 2022 17:02
Aan: freebsd-arm@FreeBSD=
.org
Onderwerp: FreeBSD 13 on RPI4 : stuck at splash =
screen


Hello,



I am new to FreeBSD for any architecture.



Was trying out FreeBSD 13 downloaded from here[1] on RPI4 8G device.

However the device did not go past the splash screen.



As some web pages suggest (probably those were for RPI40), tried inserting<=
br />
the sd card into a USB adapter and tried booting from USB. But the device
then shows "insert SD card" message.



I had dd'ed it on an sdcard. This operation looks ok as I am able to mount<=
br />
and examine the sdcard's boot partition on Linux.



The device normally runs Raspberry OS and is working fine.



Please suggest if there is something I could try.





[1]

https://download.fre=
ebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-ar=
m64-aarch64-RPI.img.xz



-- 

Mayuresh














------=_Part_19254_873059473.1645973955852--

From nobody Sun Feb 27 15:33:21 2022
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 A35AA19D892E
	for ; Sun, 27 Feb 2022 15:33:32 +0000 (UTC)
	(envelope-from tech-lists@zyxst.net)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K66wq2vw3z4XrH
	for ; Sun, 27 Feb 2022 15:33:31 +0000 (UTC)
	(envelope-from tech-lists@zyxst.net)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 6278D3200D60
	for ; Sun, 27 Feb 2022 10:33:24 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
  by compute2.internal (MEProxy); Sun, 27 Feb 2022 10:33:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; bh=ZwSMfwYnDOmC/Rg/+70jUX5mi5hri2Nv6I7Gqu
	4fz9g=; b=ON5kx0sPsFUoC043NanWMGdjQjTLeyl4aIQeigRIORZy4zKoVTkA44
	smG4KOkvQ/Lqqph2qUb+OQj7vrNBr3s7eNB2hhEDCMchSNb9A6k5pkmZ+/HBoGOT
	5VlWaFK7C9PWANbhNmerKFWR6fzJ74dQDmTcKFh1SORu5K0jhXTGl0fs9F15BMU9
	FhCfLqu305UZBNirJQK9DfakcrbJ5cwz+H7DSJIumTS9pWEmBEMKW2F5S7foAq00
	eCAfV1p4foM7nMmpKst5S3wHXTcLvGRxt9rnAnFXz7GILefKsptk4KUUd1jwVBuW
	AAKXIyVcra+pMcsLZYOct74sfLoZ1oLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZwSMfwYnDOmC/Rg/+
	70jUX5mi5hri2Nv6I7Gqu4fz9g=; b=ZQhjnZKBcPwUTJJB4ThwgoB2K/ZWb68DI
	GAtcLcb2O8wWYeF0kWU1I48pshbwfGuuZVpPMl/WrZmBcgb78IG7lkDuxVUFWR/7
	Zyd6njnBx3VLAdGaWyQId9C2MTTocoewVWqVIAcv6+7YcLRx05Yg2hyUjQfc9th3
	/d/bQh/rSP1cR3Kd7+3nj/8DX1NyMfL/56CMck1ymRupvaZK3SET5z+TIdi7OAna
	+xWz1K3mKACp5DpuqjU260eSLzAkGcg/0c7tuPU4KLumcG3GXxpIKX53bvQB+ZcF
	+KlrIn54BVdhe9mPAIn+dlMOhasJJ5ynVOBD3CvyWv1KzBPmNvv2g==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleekgdejiecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre
    dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih
    gihsthdrnhgvtheqnecuggftrfgrthhtvghrnhepieegheelvdfffefhgedtfeeitdegke
    evgeffieevffdttdefjeehfeejteeigedunecuffhomhgrihhnpehfrhgvvggsshgurdho
    rhhgpdiihiigshhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
    hmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght
X-ME-Proxy: 
    
    
    
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Sun, 27 Feb 2022 10:33:23 -0500 (EST)
Date: Sun, 27 Feb 2022 15:33:21 +0000
From: tech-lists 
To: freebsd-arm@freebsd.org
Subject: Re: FreeBSD 13 on RPI4 : stuck at splash screen
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: <20220226092858.pnbtdwq2uyoc5rgb@localhost>
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="T0ihfbf9m5rNbtD5"
Content-Disposition: inline
In-Reply-To: <20220226092858.pnbtdwq2uyoc5rgb@localhost>
X-Rspamd-Queue-Id: 4K66wq2vw3z4XrH
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=zyxst.net header.s=fm2 header.b=ON5kx0sP;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ZQhjnZKB;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.19 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net
X-Spamd-Result: default: False [-6.66 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm2];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	 RCVD_COUNT_THREE(0.00)[4];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+];
	 NEURAL_HAM_SHORT(-0.96)[-0.957];
	 DMARC_NA(0.00)[zyxst.net];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	 RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1828
Lines: 50


--T0ihfbf9m5rNbtD5
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

On Sat, Feb 26, 2022 at 02:58:59PM +0530, Mayuresh wrote:
>Please suggest if there is something I could try.
>[1]
>https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/Fr=
eeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz

I've not had success with 13.0-RELEASE. I suggest you try a snapshot instea=
d:

https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.1/FreeBSD-13.1-PRE=
RELEASE-arm64-aarch64-RPI-20220224-9134a398506-249729.img.xz

I've written some notes for installation to rpi4 (specifically root-on-zfs =
and boot via usb3 with no sd card)
please note they are only notes primarily for my own use and not a how-to.=
=20

https://zyxst.net/FreeBSD/rpi4/txt/rpi4-8GB-zfs-root-freebsd13stable.txt
--=20
J.

--T0ihfbf9m5rNbtD5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmIbmbMACgkQs8o7QhFz
NAXxtg/+Kq6ARpVOzbDVqrRWZgqk8ux1cnJeVraGSYz8cIizbSF+BLvVFP1xlGzJ
CJYelhOg2NVduinwMRTEK7oTMj0KXimslvHfUn7gLLAlasosbgUYRg4IaNWOOcBf
AJLp9YaSUcHvQhIe7TcWmElT9PVl9NtCsDkDyyjtMdfoxR8N1zm/i6BxVQiByZuB
0KkP05kta0iSGwDiPHhadfHy0amPDpTn1LmaGNYLecZY1G7g1yB3U/f/dGS38wly
+h25dbT9kjj2Svpgnl9rjGfYF/4NdiiRAVl0jRpsjmYjm1nY2MUIh9AlLi0FlxLS
HNZoAw4ppmh2H7FQDsL0R4sOp/myfLoCn0A28jLL9tzjsP4Ux+cAYwOG/gXyj9xP
wUH0fuVDUNVofZAmtTYdilxZojsMbsgW9qKYi0IhGn9uSIH5fjNBHASQ97dRB40A
Sk/uuxPXJMqZylpJhuygABt37f17aLtRH8cJbYgWKSh+TFdn2gq63LFjt1i1Usq3
2wtMSWi9ccCaQgZhM3VL5d39DeqwlL5cshVfr21d+7iXnAPiqNjsSvNxxBhR/pWJ
wvWL5fLQEZALGX/1gtXbmlvBn9Fzx6ynMAKTHZFtVw69kRFAZYcFFGZZvqC6vkZP
PduY5oEWC+81sffOXhYMFGDWl/THyHhN2MMr2o6vBASY35MnAMY=
=eqey
-----END PGP SIGNATURE-----

--T0ihfbf9m5rNbtD5--

From nobody Sun Feb 27 15:37:29 2022
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 DDBE919D9EB2
	for ; Sun, 27 Feb 2022 15:37:32 +0000 (UTC)
	(envelope-from mayuresh.w1@gmail.com)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d])
	(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 4K671S09W5z4Yhq
	for ; Sun, 27 Feb 2022 15:37:32 +0000 (UTC)
	(envelope-from mayuresh.w1@gmail.com)
Received: by mail-wr1-x42d.google.com with SMTP id n14so11751909wrq.7
        for ; Sun, 27 Feb 2022 07:37:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=uZOitHP4ngsWWKfJ8kDUvYjixaN+b39enb82SVNXDdY=;
        b=Gr/t/45JScXRDtbhOjgPCcWQYAcKqmf0Uy4R+Fuf6Ma3tCkrJADlqs3fEeAZ/m/k0M
         Rd+OFnjTq/olXcskcGrnZCjSBppejh4zxxVz1wrZOfGNx8oewO5pMOpOEcn+3IMjp8To
         wsWWxVoijJRLH6BS/jlrJn120Rp8jZWuYC/P/Kq+8czw9Gxqrje13w1BeL0x6zThmsPc
         lfFa2OV706Wcv5nuQW3qeod9mFGlbXrFSGfS2k5/G30p01cqODHsJvCpdSRoQVAFbxqH
         rL5HGicM+4+GkaVfN5cI8de5wmaXwJi+whDgrnrYhgoCrK0/ux/318Zy0SgLqHqseDlB
         ketg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=uZOitHP4ngsWWKfJ8kDUvYjixaN+b39enb82SVNXDdY=;
        b=YdlP7nFSuSdHoWB2jYOuwAAFrPvOD7QgkiDV2xyEiqK8VOO6uqOipAFYwocm8Q97fF
         nW8wreoOPZAF8QCHUt9mu5ME5h3OfC+YxFYzk5kINzQ/Ot5S0qQXRBibGF0/7mL0BdO+
         hPVY3NsPhDaTCcdhXLalQ2vIA6xtQJFJbAgZt3TSSaWrPZFh2B8UA7nukVHEtcJZK7lF
         Adc5Gwgj7JsBtjiphBrpm5aQCeOPkapMJlmjVxGy1EZyTNV7lKsv5H0/nUPocSsJBKdv
         vwua6JZJgjWhuUI22lYdV/HXz+eaZ5TzQdVXqIwT4NlRzPQxOq6WyxTrPkw7phbz8lsj
         8erw==
X-Gm-Message-State: AOAM533qeQSlaTsip6fL/giovklpDDC9V/Q+Nxst5izU1tTVtGXJ3BMP
	C+zIgao11SGAxrirVnCEIoXrmg36iee/Ww==
X-Google-Smtp-Source: ABdhPJzexrhxptAPp54Ub/uOVTyBKUTeePGz8rxSO+f4H/a58//91gh+HDt6NltMMVDtfh/f+ShC1g==
X-Received: by 2002:a05:6000:178e:b0:1ef:b76e:f54 with SMTP id e14-20020a056000178e00b001efb76e0f54mr1856635wrg.324.1645976250769;
        Sun, 27 Feb 2022 07:37:30 -0800 (PST)
Received: from localhost (warunjikardental.com. [116.203.142.195])
        by smtp.gmail.com with ESMTPSA id k19-20020a05600c479300b00380e461a4d2sm15520072wmo.0.2022.02.27.07.37.30
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 27 Feb 2022 07:37:30 -0800 (PST)
Date: Sun, 27 Feb 2022 21:07:29 +0530
From: Mayuresh 
To: Ronald Klop 
Cc: freebsd-arm@FreeBSD.org
Subject: Re: FreeBSD 13 on RPI4 : stuck at splash screen
Message-ID: <20220227153729.f2yzsqtgdwzkctyt@localhost>
References: <20220226092858.pnbtdwq2uyoc5rgb@localhost>
 <465995159.19255.1645973955854@localhost>
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: <465995159.19255.1645973955854@localhost>
X-Rspamd-Queue-Id: 4K671S09W5z4Yhq
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="Gr/t/45J";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mayureshw1@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=mayureshw1@gmail.com
X-Spamd-Result: default: False [-0.70 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 FORGED_SENDER(0.30)[mayuresh@acm.org,mayureshw1@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mayuresh@acm.org,mayureshw1@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.998];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[acm.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 566
Lines: 17

On Sun, Feb 27, 2022 at 03:59:15PM +0100, Ronald Klop wrote:
> Just guessing. I assume you have connected a HDMI screen?

Thanks to this[1] post I got to know that the HDMI port nearer top the SD
card works!

I was not able to get audio to work through the 3.5mm audio jack.

Also curious whether there is any media player on FreeBSD 13 that can use
RPI4's GPU. (Without GPU, usually the device will heat up and won't be
suitable for long video viewing.)

-- 
Mayuresh

[1]
https://forums.freebsd.org/threads/freebsd-wont-boot-on-rpi-4-4b-8gb-ram.81778/#post-528606

From nobody Sun Feb 27 15:43:25 2022
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 DE9E519DC0F3
	for ; Sun, 27 Feb 2022 15:43:28 +0000 (UTC)
	(envelope-from SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4K678H4BFZz4bdC
	for ; Sun, 27 Feb 2022 15:43:27 +0000 (UTC)
	(envelope-from SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl)
Date: Sun, 27 Feb 2022 16:43:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1645976605;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=Z7edeC1bW2ClcRahxhGP4B693Y7NsdL+4t33NIHA45E=;
	b=NBS+GKRShi7KKRRzJnZUJzWO24ok3kI1BEJyBSU68of6Q5EY385rAsljuXkz2UufP5ygPW
	HAKr4Eu72LeqQCDJfg9Eccml8I8KqnHPkYKcTZlFLkwuDNLtHzZ4r0Q3xco7EObWZ9pbfV
	D5Fhkv5sEjwtZckGjvyNkplcUVCw6/hRDen8X5Uk6GstTsMB/1S6B5/hpRYkhPwKusv/Gu
	XmND1qEUaSWgS2r/PeJScYskUdMdw822v8yJ+bWV7LZCeLxWUQ+kp4xW0oWFw6hjxDDPU0
	Xzz/GLDZ2uZlh8dgoXhKWi3pLjwdcG3tlhvtBMpy6mJNK9U/7GltdLzDfy48sw==
From: Ronald Klop 
To: freebsd-arm@FreeBSD.org, Mayuresh 
Message-ID: <1823643517.18217.1645976605647@localhost>
In-Reply-To: <20220227153729.f2yzsqtgdwzkctyt@localhost>
Subject: Re: FreeBSD 13 on RPI4 : stuck at splash screen
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="----=_Part_18216_15318504.1645976605646"
X-Mailer: Realworks (596.36.420274e)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4K678H4BFZz4bdC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=NBS+GKRS;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Hr80=TK=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3338
Lines: 91

------=_Part_18216_15318504.1645976605646
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

There was a patch on the mailinglist some time ago to enable the audio Jack=
 on 64 bits rpi4. I tested it and it worked but it is not committed yet. Ca=
n look it up if you are interested.=20


I don=E2=80=99t know about gpu/video. Never needed it.=20


Regards,
Ronald


Van: Mayuresh 
Datum: 27 februari 2022 16:37
Aan: Ronald Klop 
CC: freebsd-arm@FreeBSD.org
Onderwerp: Re: FreeBSD 13 on RPI4 : stuck at splash screen

>=20
>=20
> On Sun, Feb 27, 2022 at 03:59:15PM +0100, Ronald Klop wrote:
> > Just guessing. I assume you have connected a HDMI screen?
>=20
> Thanks to this[1] post I got to know that the HDMI port nearer top the SD
> card works!
>=20
> I was not able to get audio to work through the 3.5mm audio jack.
>=20
> Also curious whether there is any media player on FreeBSD 13 that can use
> RPI4's GPU. (Without GPU, usually the device will heat up and won't be
> suitable for long video viewing.)
>=20
> --=20
> Mayuresh
>=20
> [1]
> https://forums.freebsd.org/threads/freebsd-wont-boot-on-rpi-4-4b-8gb-ram.=
81778/#post-528606
>=20
>=20
>=20
>=20
------=_Part_18216_15318504.1645976605646
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

There was a patch on the mailinglist some time ago=
 to enable the audio Jack on 64 bits rpi4. I tested it and it worked but it=
 is not committed yet. Can look it up if you are interested. 

I don=E2=80=99t know about gpu/video. Never needed it. 

Regards,
Ronald

Van: Mayuresh <mayuresh@acm.org>
Dat=
um: 27 februari 2022 16:37
Aan: Ronald Klop =
<ronald-lists@klop.ws>
CC: freebsd-arm@FreeBSD.=
org
Onderwerp: Re: FreeBSD 13 on RPI4 : stuck at spla=
sh screen


On Sun, Feb 27, 2022 at 03:59:15PM +0100, Ronald Klop =
wrote:

> Just guessing. I assume you have connected a HDMI screen?



Thanks to this[1] post I got to know that the HDMI port nearer top the SD
card works!



I was not able to get audio to work through the 3.5mm audio jack.



Also curious whether there is any media player on FreeBSD 13 that can use
RPI4's GPU. (Without GPU, usually the device will heat up and won't be

suitable for long video viewing.)



-- 

Mayuresh



[1]

https://forums.freebsd.org/threads/freebsd-won=
t-boot-on-rpi-4-4b-8gb-ram.81778/#post-528606












------=_Part_18216_15318504.1645976605646--

From nobody Sun Feb 27 15:44:17 2022
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 ACF1519DC589
	for ; Sun, 27 Feb 2022 15:44:22 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433])
	(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 4K679K6Gj3z4cCF
	for ; Sun, 27 Feb 2022 15:44:21 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: by mail-wr1-x433.google.com with SMTP id d17so11753238wrc.9
        for ; Sun, 27 Feb 2022 07:44:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=HNVXjkQdC3SjgVW5K+bX/5WKomZ+e2cGiIpFOFZUmGE=;
        b=j4CFrGN2FEyJ7C8Izg8Uev61iEZl8EcYQOkhMHFi8j8cDjHtRN6XxqrIYx0O+tkhMk
         wevvmN25UXpA04xKUgMLxI9eNowy7IPBpOGVmEs0JvhoKMkXtzIQHyqQqb84OBiLtLLd
         yXa1NBskp90ZmR7feqj5CjfJhlzJctGu65+5TH2Ny8TzBWFbhCGsYnUCJWHk3+Yqnlfb
         tYPHqHgNzLLgpMt6hNRjBFHKKBF6wOK+B93TQ3d0IbqdcTgmnB9bqYwCc3WQx2GZ7L9D
         4fiLzphL4cxl1arcXR0ifsHFAaRCxBaVY0/T6Ia39p6+iF/E/roxVu+jJ01aWRcCHFSa
         +R/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=HNVXjkQdC3SjgVW5K+bX/5WKomZ+e2cGiIpFOFZUmGE=;
        b=UujH8wA86W3XkjAxpy/rxYTTG5QGapkhoL40A4PbcQ+S4jGoJZseeiX/OhvbveXW4I
         ny8Du7tWgZP/+Ry4o7TMTHRycCtvkBa+0EZ00NfXbEQJipxQNKlR9UkAAWe2QHIw1hE4
         /W9CPnbgnAQCi1gDoR4BlnlA7NYy+bpAGVJ41mdWrtoqqQmBFHOf1fe82DO4XjAWdcEf
         6AmIKqSSo4nqGaRUIdZ6Xz0QB7uQsbYrHQzWYQDHw/jQrQxAKwpmdVj/XEcFChH8+/8m
         cjfyj77WQGz+Y3h4SQ0ozaUSw4NBnbZVX6ZQ8tiZQUJ6rKP01M/QkKHy2TAK5rRW34uU
         JjFA==
X-Gm-Message-State: AOAM531M9CnACCcGUfFxUbA/uot9+0UdmFbi1Uicdn8r+G49xgzIKjUx
	8jOD7WHJzu9I8fJ7li+oGHdQo0K0Ep9HlA==
X-Google-Smtp-Source: ABdhPJwgldfowtGsLzHNQcYwHt3q7PeGkddgS58551XCp0t1N7NG3rQ0LB8RZjgXeVVDlhu60iflVw==
X-Received: by 2002:a05:6000:1789:b0:1ea:7bb7:312c with SMTP id e9-20020a056000178900b001ea7bb7312cmr12910712wrg.660.1645976660663;
        Sun, 27 Feb 2022 07:44:20 -0800 (PST)
Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181])
        by smtp.gmail.com with ESMTPSA id r15-20020a05600c35cf00b003808165fbc2sm9425309wmq.25.2022.02.27.07.44.18
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 27 Feb 2022 07:44:19 -0800 (PST)
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 14.0 \(3654.120.0.1.13\))
Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64
From: Marco Devesas Campos 
X-Priority: 3 (Normal)
In-Reply-To: <106195874.50.1644310150579@localhost>
Date: Sun, 27 Feb 2022 15:44:17 +0000
Cc: Ronald Klop 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com>
 <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws>
 <106195874.50.1644310150579@localhost>
To: freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K679K6Gj3z4cCF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=j4CFrGN2;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of devesascampos@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=devesascampos@gmail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MV_CASE(0.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 RECEIVED_SPAMHAUS_PBL(0.00)[213.22.242.181:received];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4113
Lines: 155

Hi, List

On the back of Ronald Klop's comments (thanks!), I went and got myself =
an
RPI 4 and it turns out all that was need was adding the right dtb
reference and it all works (seemingly) fine (incremental patch =
attached).

One of the potential projects highlighted in the latest call for =
proposals
was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. If
anyone who voted for that reads this list, wd be nice to get some input =
on
the patches.

Best,
Marco



diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c =
b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
index dc18678b99a3..344267ff0c1c 100644
--- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
+++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
@@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NULL;
 static struct ofw_compat_data compat_data[] =3D {
        {"broadcom,bcm2835-vchiq",      BSD_DTB},
        {"brcm,bcm2835-vchiq",          UPSTREAM_DTB},
+       {"brcm,bcm2711-vchiq",          UPSTREAM_DTB},
        {NULL,                          0}
 };
=20


> On 8 Feb 2022, at 08:49, Ronald Klop  wrote:
>=20
> Van: Ronald Klop 
> Datum: maandag, 7 februari 2022 21:05
> Aan: Marco Devesas Campos , =
freebsd-arm@freebsd.org
> Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support =
for arm64
>=20
> On 2/6/22 14:46, Marco Devesas Campos wrote:
> > Hi Ronald,
> >
> > Thanks so much for trying out the patch out.
> >
> >> On 6 Feb 2022, at 13:05, Ronald Klop  wrote:
> >>
> >> Hi,
> >>
> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no =
difference in available devices.
> >> I can try to boot it on a RPI3B+ on another time.
> >
> > I *think* the GPU/VC in RPI-4 is a very different beast from the =
others. I'll
> > look into it, but if you could give it a try on the 3+ I'd be much =
obliged.
> >
> >>
> >> What would be the expected outcome? Where should I look at (or =
listen to)?
> >>
> >
> > You should see something like
> >
> >    vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on =
simplebus0
> >    vchiq: local ver 8 (min 3), remote ver 8.
> >    pcm0:  on vchiq0
> >
> > in your dmesg output.
> >
> > The file /dev/vchiq should exist, as well as the following sysctl-s =
(I'm
> > assuming no other audio devices are attached)
> >
> >    % sysctl dev.pcm
> >    dev.pcm.0.trace: 0
> >    ...
> >    dev.pcm.0.dest: 0
> >    ...
> >    dev.pcm.0.%parent: vchiq0
> >    ...
> >    dev.pcm.0.%driver: pcm
> >    dev.pcm.0.%desc: VCHIQ audio
> >    =E2=80=A6
> >
> > Then if you `cat < /dev/random > /dev/dsp` you should hear some =
static coming
> > out of whatever is connected to hdmi (maybe headphones too? =
otherwise try
> > setting `sysctl dev.pcm.0.dest=3D1`)
> >
> > Best,
> > Marco
>=20
>=20
> Hi,
>=20
> Booted the patched 14-CURRENT on the RPI3B+.
>=20
> dmesg diff:
> +vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on =
simplebus0
> +vchiq: local ver 8 (min 3), remote ver 8.
> +pcm0:  on vchiq0
>=20
> [root@rpi3 ~]# cat /dev/sndstat
> Installed devices:
> pcm0:  (play) default
> No devices installed from userspace.
>=20
> [root@rpi3 ~]# sysctl dev.pcm
> dev.pcm.0.trace: 0
> dev.pcm.0.starved: 0
> dev.pcm.0.freebuffer: 40000
> dev.pcm.0.underruns: 0
> dev.pcm.0.retrieved: 0
> dev.pcm.0.submitted: 0
> dev.pcm.0.callbacks: 0
> dev.pcm.0.dest: 0
> dev.pcm.0.mode: 3
> dev.pcm.0.bitperfect: 0
> dev.pcm.0.buffersize: 0
> dev.pcm.0.play.vchanformat: s16le:2.0
> dev.pcm.0.play.vchanrate: 48000
> dev.pcm.0.play.vchanmode: fixed
> dev.pcm.0.play.vchans: 1
> dev.pcm.0.%parent: vchiq0
> dev.pcm.0.%pnpinfo:
> dev.pcm.0.%location:
> dev.pcm.0.%driver: pcm
> dev.pcm.0.%desc: VCHIQ audio
> dev.pcm.%parent:
>=20
>=20
> To play some audio I need to search some headphones first. :-)
>=20
> Ronald.
> =20
>=20
>=20
> Good morning,
>=20
> Found headphones with a cable on the attic. Plugged it into the audio =
jack and played an mp3. Amazing!
>=20
> Regards,
> Ronald.
> =20


From nobody Sun Feb 27 16:41:25 2022
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 16CC919E7EA0
	for ; Sun, 27 Feb 2022 16:41:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c])
	(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 4K68RV33y1z4kyc
	for ; Sun, 27 Feb 2022 16:41:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa2c.google.com with SMTP id j12so4071390vkr.0
        for ; Sun, 27 Feb 2022 08:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=nkXUbSHLyqrEUVuhJlsyhcPKDUiju4uYm+9Kikn6T5I=;
        b=efKABpavKIme+20F23UZ8u48eMNMb5TIbXMzxhDsVtWFCFmxjZyD62QNYCMw3WcsJH
         C/fPgx2L/znpcWHBHPbqHU7So1huQ+NP+8Nk+y5CPDlXDAgL49C9zqNvGsZIAn2qsnX2
         9gzoYuj+XjX6pjw+KY8Tc8Ukx9f01SHs1hg2ebqrXbQWlUBpR3kVoFMHLxWlp4p++Kj/
         FLiKyjVRsTdgN/NFlI/4eiJHX3bZlsD94+K57l6dd1RmhU0g83qcFJfNaZ0kfrvdUaMl
         +fy/6DYpzUss/2ENSQQq1oTDQBYkqDcFGxlWzmuCe1HscDR2j1jUf4gvNEAjDtjNxS5y
         8geg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=nkXUbSHLyqrEUVuhJlsyhcPKDUiju4uYm+9Kikn6T5I=;
        b=hcSg5AeHXdJ1dInaDCsaNx+U/jt7jMhsyL3dLuT1U/dtcWnKYyLaoUprzX6M1Z5D6G
         +tuI8Z7ccQRQ/3Xndbp5ffFAr2ms6GFuFFpuFwHfRJeQ9is+ioIdFCNty+xCwFSfuO3a
         WE+QEb/3opbKfwlch9nDQ0KRBAlQ/grQvmt73Jfg7b2Q9+aIiDPthXltwSrueIznTeOd
         GwklWFXEylEIUPC7RQ7nMZHcNED83dbq6j2bg/tFkJ3IZVXVtRt6jyXXwXjYQMl/nTEq
         IL0RSOEk5f6U1A070ymI+qgwtsNPeLtZUE9vN4q3KqzmDOtH30d8uO2rtbI96CnmMkuI
         foYg==
X-Gm-Message-State: AOAM532Fa9dGPufXv4ubMfuPg3Phj5wb2/mKoVlaU0G3Zg+vUk5Lg6rw
	kHBScCbJv+ecIU7/xh3PmXp0cHIzo9Bi0fb1W4GkQ2vkGCs=
X-Google-Smtp-Source: ABdhPJxe++bPnEZKQeiD0wP7G7R1PPPX8zSyETZqW89gVS/Bl+xU7ZugevPzrAbdhey2GjbGrtFnbzKF3mZmMDx3J48=
X-Received: by 2002:a1f:2355:0:b0:32a:e5bb:29a1 with SMTP id
 j82-20020a1f2355000000b0032ae5bb29a1mr6765088vkj.2.1645980096266; Sun, 27 Feb
 2022 08:41:36 -0800 (PST)
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: 
  <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com>
 <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws> <106195874.50.1644310150579@localhost>
 
In-Reply-To: 
From: Warner Losh 
Date: Sun, 27 Feb 2022 09:41:25 -0700
Message-ID: 
Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64
To: Marco Devesas Campos 
Cc: "freebsd-arm@freebsd.org" , Ronald Klop 
Content-Type: multipart/alternative; boundary="000000000000f2174005d9029a6a"
X-Rspamd-Queue-Id: 4K68RV33y1z4kyc
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=efKABpav;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2c) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 RCVD_TLS_ALL(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11428
Lines: 351

--000000000000f2174005d9029a6a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 27, 2022 at 8:44 AM Marco Devesas Campos <
devesas.campos@gmail.com> wrote:

> Hi, List
>
> On the back of Ronald Klop's comments (thanks!), I went and got myself an
> RPI 4 and it turns out all that was need was adding the right dtb
> reference and it all works (seemingly) fine (incremental patch attached).
>

I've committed the patch below. If it turns out we need more, we can always
augment.

Warner


> One of the potential projects highlighted in the latest call for proposal=
s
> was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. If
> anyone who voted for that reads this list, wd be nice to get some input o=
n
> the patches.
>
> Best,
> Marco
>
>
>
> diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
> b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
> index dc18678b99a3..344267ff0c1c 100644
> --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
> +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
> @@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NULL;
>  static struct ofw_compat_data compat_data[] =3D {
>         {"broadcom,bcm2835-vchiq",      BSD_DTB},
>         {"brcm,bcm2835-vchiq",          UPSTREAM_DTB},
> +       {"brcm,bcm2711-vchiq",          UPSTREAM_DTB},
>         {NULL,                          0}
>  };
>
>
>
> > On 8 Feb 2022, at 08:49, Ronald Klop  wrote:
> >
> > Van: Ronald Klop 
> > Datum: maandag, 7 februari 2022 21:05
> > Aan: Marco Devesas Campos ,
> freebsd-arm@freebsd.org
> > Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support for
> arm64
> >
> > On 2/6/22 14:46, Marco Devesas Campos wrote:
> > > Hi Ronald,
> > >
> > > Thanks so much for trying out the patch out.
> > >
> > >> On 6 Feb 2022, at 13:05, Ronald Klop  wrote:
> > >>
> > >> Hi,
> > >>
> > >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no
> difference in available devices.
> > >> I can try to boot it on a RPI3B+ on another time.
> > >
> > > I *think* the GPU/VC in RPI-4 is a very different beast from the
> others. I'll
> > > look into it, but if you could give it a try on the 3+ I'd be much
> obliged.
> > >
> > >>
> > >> What would be the expected outcome? Where should I look at (or liste=
n
> to)?
> > >>
> > >
> > > You should see something like
> > >
> > >    vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on
> simplebus0
> > >    vchiq: local ver 8 (min 3), remote ver 8.
> > >    pcm0:  on vchiq0
> > >
> > > in your dmesg output.
> > >
> > > The file /dev/vchiq should exist, as well as the following sysctl-s
> (I'm
> > > assuming no other audio devices are attached)
> > >
> > >    % sysctl dev.pcm
> > >    dev.pcm.0.trace: 0
> > >    ...
> > >    dev.pcm.0.dest: 0
> > >    ...
> > >    dev.pcm.0.%parent: vchiq0
> > >    ...
> > >    dev.pcm.0.%driver: pcm
> > >    dev.pcm.0.%desc: VCHIQ audio
> > >    =E2=80=A6
> > >
> > > Then if you `cat < /dev/random > /dev/dsp` you should hear some stati=
c
> coming
> > > out of whatever is connected to hdmi (maybe headphones too? otherwise
> try
> > > setting `sysctl dev.pcm.0.dest=3D1`)
> > >
> > > Best,
> > > Marco
> >
> >
> > Hi,
> >
> > Booted the patched 14-CURRENT on the RPI3B+.
> >
> > dmesg diff:
> > +vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on simplebus0
> > +vchiq: local ver 8 (min 3), remote ver 8.
> > +pcm0:  on vchiq0
> >
> > [root@rpi3 ~]# cat /dev/sndstat
> > Installed devices:
> > pcm0:  (play) default
> > No devices installed from userspace.
> >
> > [root@rpi3 ~]# sysctl dev.pcm
> > dev.pcm.0.trace: 0
> > dev.pcm.0.starved: 0
> > dev.pcm.0.freebuffer: 40000
> > dev.pcm.0.underruns: 0
> > dev.pcm.0.retrieved: 0
> > dev.pcm.0.submitted: 0
> > dev.pcm.0.callbacks: 0
> > dev.pcm.0.dest: 0
> > dev.pcm.0.mode: 3
> > dev.pcm.0.bitperfect: 0
> > dev.pcm.0.buffersize: 0
> > dev.pcm.0.play.vchanformat: s16le:2.0
> > dev.pcm.0.play.vchanrate: 48000
> > dev.pcm.0.play.vchanmode: fixed
> > dev.pcm.0.play.vchans: 1
> > dev.pcm.0.%parent: vchiq0
> > dev.pcm.0.%pnpinfo:
> > dev.pcm.0.%location:
> > dev.pcm.0.%driver: pcm
> > dev.pcm.0.%desc: VCHIQ audio
> > dev.pcm.%parent:
> >
> >
> > To play some audio I need to search some headphones first. :-)
> >
> > Ronald.
> >
> >
> >
> > Good morning,
> >
> > Found headphones with a cable on the attic. Plugged it into the audio
> jack and played an mp3. Amazing!
> >
> > Regards,
> > Ronald.
> >
>
>
>

--000000000000f2174005d9029a6a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Feb 27, 2022 at 8:44 AM Marco=
 Devesas Campos <devesas.cam=
pos@gmail.com> wrote:
Hi, List



On the back of Ronald Klop's comments (thanks!), I went and got myself =
an

RPI 4 and it turns out all that was need was adding the right dtb

reference and it all works (seemingly) fine (incremental patch attached).

I've committed the patch below. If i=
t turns out we need more, we can always augment.

W=
arner
=C2=A0

One of the potential projects highlighted in the latest call for proposals<=
br>
was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. If

anyone who voted for that reads this list, wd be nice to get some input on<=
br>
the patches.



Best,

Marco







diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c b/sys/contr=
ib/vchiq/interface/vchiq_arm/vchiq_kmod.c

index dc18678b99a3..344267ff0c1c 100644

--- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

+++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

@@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NULL;

=C2=A0static struct ofw_compat_data compat_data[] =3D {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"broadcom,bcm2835-vchiq",=C2=A0 =C2=
=A0 =C2=A0 BSD_DTB},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"brcm,bcm2835-vchiq",=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 UPSTREAM_DTB},

+=C2=A0 =C2=A0 =C2=A0 =C2=A0{"brcm,bcm2711-vchiq",=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 UPSTREAM_DTB},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {NULL,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0}

=C2=A0};







> On 8 Feb 2022, at 08:49, Ronald Klop <ronald-lists@klop.ws> wrote:

> 

> Van: Ronald Klop <ronald-lists@klop.ws>

> Datum: maandag, 7 februari 2022 21:05

> Aan: Marco Devesas Campos <devesas.campos@gmail.com>, freebsd-arm@freebsd.org

> Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support fo=
r arm64

> 

> On 2/6/22 14:46, Marco Devesas Campos wrote:

> > Hi Ronald,

> >

> > Thanks so much for trying out the patch out.

> >

> >> On 6 Feb 2022, at 13:05, Ronald Klop <ronald-lists@klop.ws> wrote:
> >>

> >> Hi,

> >>

> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see n=
o difference in available devices.

> >> I can try to boot it on a RPI3B+ on another time.

> >

> > I *think* the GPU/VC in RPI-4 is a very different beast from the =
others. I'll

> > look into it, but if you could give it a try on the 3+ I'd be=
 much obliged.

> >

> >>

> >> What would be the expected outcome? Where should I look at (o=
r listen to)?

> >>

> >

> > You should see something like

> >

> >=C2=A0 =C2=A0 vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b=
87b irq 54 on simplebus0

> >=C2=A0 =C2=A0 vchiq: local ver 8 (min 3), remote ver 8.

> >=C2=A0 =C2=A0 pcm0: <VCHIQ audio> on vchiq0

> >

> > in your dmesg output.

> >

> > The file /dev/vchiq should exist, as well as the following sysctl=
-s (I'm

> > assuming no other audio devices are attached)

> >

> >=C2=A0 =C2=A0 % sysctl dev.pcm

> >=C2=A0 =C2=A0 dev.pcm.0.trace: 0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.dest: 0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.%parent: vchiq0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.%driver: pcm

> >=C2=A0 =C2=A0 dev.pcm.0.%desc: VCHIQ audio

> >=C2=A0 =C2=A0 =E2=80=A6

> >

> > Then if you `cat < /dev/random > /dev/dsp` you should hear =
some static coming

> > out of whatever is connected to hdmi (maybe headphones too? other=
wise try

> > setting `sysctl dev.pcm.0.dest=3D1`)

> >

> > Best,

> > Marco

> 

> 

> Hi,

> 

> Booted the patched 14-CURRENT on the RPI3B+.

> 

> dmesg diff:

> +vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b87b irq 54 on sim=
plebus0

> +vchiq: local ver 8 (min 3), remote ver 8.

> +pcm0: <VCHIQ audio> on vchiq0

> 

> [root@rpi3 ~]# cat /dev/sndstat

> Installed devices:

> pcm0: <VCHIQ audio> (play) default

> No devices installed from userspace.

> 

> [root@rpi3 ~]# sysctl dev.pcm

> dev.pcm.0.trace: 0

> dev.pcm.0.starved: 0

> dev.pcm.0.freebuffer: 40000

> dev.pcm.0.underruns: 0

> dev.pcm.0.retrieved: 0

> dev.pcm.0.submitted: 0

> dev.pcm.0.callbacks: 0

> dev.pcm.0.dest: 0

> dev.pcm.0.mode: 3

> dev.pcm.0.bitperfect: 0

> dev.pcm.0.buffersize: 0

> dev.pcm.0.play.vchanformat: s16le:2.0

> dev.pcm.0.play.vchanrate: 48000

> dev.pcm.0.play.vchanmode: fixed

> dev.pcm.0.play.vchans: 1

> dev.pcm.0.%parent: vchiq0

> dev.pcm.0.%pnpinfo:

> dev.pcm.0.%location:

> dev.pcm.0.%driver: pcm

> dev.pcm.0.%desc: VCHIQ audio

> dev.pcm.%parent:

> 

> 

> To play some audio I need to search some headphones first. :-)

> 

> Ronald.

>=C2=A0 

> 

> 

> Good morning,

> 

> Found headphones with a cable on the attic. Plugged it into the audio =
jack and played an mp3. Amazing!

> 

> Regards,

> Ronald.

>=C2=A0 








--000000000000f2174005d9029a6a--

From nobody Sun Feb 27 21:01:19 2022
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 6B10519DA16A
	for ; Sun, 27 Feb 2022 21:01:21 +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 4K6GC34DVxz4XBf
	for ; Sun, 27 Feb 2022 21:01:19 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 337B56C08
	for ; Sun, 27 Feb 2022 21:01:19 +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 21RL1JbP064826
	for ; Sun, 27 Feb 2022 21:01:19 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 21RL1JCm064825
	for freebsd-arm@FreeBSD.org; Sun, 27 Feb 2022 21:01:19 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202202272101.21RL1JCm064825@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, 27 Feb 2022 21:01:19 +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="16459956791.c6fFf08.62674"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1645995679;
	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=NjffaqlRUcIogoMBwmrTdem2zY037dWSHMCz8jaJ/vk=;
	b=uSkDUxiQ4N15dwnoDAIlKArB9Xnicr4tmDNyHVl/UoMiTUeGTrnO+LXGFhVoVpH9q+d6M9
	2ejwoXFoJ+ZhVjA5uw4p1T2JF+NWYLsriACUkieMeUB0EZGMr/teR0Kj/Llloiq4BsNGzT
	WkZXl5K8XHjfhLVwOHHSZHqO13drndZxH0HJdbTPeLA0GfoC/qnRIMu5lJBlMtCyDZpeLC
	98Te2C8y4mGp/BZ5PouC9+CpPGU8b5/ePEg9h/TRUagJbvGbgefKqH0kjoVREkn2HURVzS
	QNi6R6C9KBD0PGHoAtazTSLujCj5vzAmZLOphrrPPxq4cI3W/I9dBtLhyhYuiA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645995680; a=rsa-sha256; cv=none;
	b=usUVqZiTLzcs3/VlgGGPfWlYJ+8/2r1+AUe2SEY4O3hwmiCZCf6y94rnec1+cuqHwqeBzq
	8aT09gjVRjX90g2oNkvaoX0oLJKcknJJYiYTBpc7ZucrJ7vhiqXlJLiZdIf4qsUrkm/6Oq
	BFP7d1YjtQM0g3YinhWhnXVwyh7ectpwhCT/O3qS+hJMFKjAl+DMoJ5ZFvLkt8y29nagW6
	HBEOR4K7r98OBjvu5kx7sT1wDiQbduhTU3Z0p8HorgJRjJVNcL7bLySzHeBCox4WuYO3Gq
	Nhkd79OCjgnPTRQgwfPWAMZaFYYu1puMyRG+itg57H5pqXzexcuqutV+1tYwjg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1804
Lines: 38


--16459956791.c6fFf08.62674
Date: Sun, 27 Feb 2022 21:01:19 +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.

--16459956791.c6fFf08.62674
Date: Sun, 27 Feb 2022 21:01:19 +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.


--16459956791.c6fFf08.62674--

From nobody Mon Feb 28 08:51:47 2022
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 A408D19EB916
	for ; Mon, 28 Feb 2022 08:51:59 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4K6Yz307lLz4mQm
	for ; Mon, 28 Feb 2022 08:51:59 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x534.google.com with SMTP id s14so16558888edw.0
        for ; Mon, 28 Feb 2022 00:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=VKMdVakmXDdAPHD8UpEy/zcC8kJ5phREwE/ITHBwy1c=;
        b=l+lmwtHCP5uXVZZN483S5Sny+8/xHKBfO0CCZ+X1wnIzHFjaWXWhnUNX6dCzo+2hRs
         rLe8B+Fc3Jbg9ghUP5B/nmLASAeEmQSd3SggtHDgpvErKkqlhfFjIO6kua/rpAYphmgW
         Sa3yCy8J83wvcgdhDazsh8a7UEH4gZLZTdYQufnbRLGBW0rjFNgw28d7MR3M+so/D7ZC
         YWiLn85qUWP92c++kk3fuo/O0avFbT3pN0x7Rk2XOTrdlz5B76zECj+lisoVLxdf62dn
         r6hjXZBcMYdje41VX2MgcZp9FirQKNl5kzeTG+xVPJN1XFePk08o8VI+qsQ5PVFOjVA1
         /mvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=VKMdVakmXDdAPHD8UpEy/zcC8kJ5phREwE/ITHBwy1c=;
        b=MqSJTqlYc5X5RhwMpnEkMKvcMvBcgTpgHBjqcEmlNEO0o0pFJLD6munllSseNFUaz/
         hk3R0MqVUEcVuchPar9GO84qNkir1fjl0l9MMekguIbN1ZEHGnULfxQGe80fRo26k22n
         rxzQJzqkE8o6+2r1q+loHBoVwRiYFDHTHkObAJi24GlxF3TksPOEMLWkqds7IRw4eg6P
         XOiNTfp2ske/Mum9wpi75jO7fo0A+P4Rdj/68UFAL0IBNdP5nyHpXBAKMoAF6xVygme9
         eCZMYe04QRQ0dRCNud/qkPWM/sUnjVfyqbaIdPmEcAjrfIw5UK8aGCBjpTP2xHZcbqsu
         NCRQ==
X-Gm-Message-State: AOAM530GpRQIYZicu7s0xbj5GBE6zvhF6nK1sPZa/dTxSbWtkOORZ88R
	OcSDE4PLWIIljL7VUB7VYtILyGZoA1Lwo4J5DD9116K8idB4jg==
X-Google-Smtp-Source: ABdhPJw5k8X1ix8Mc2M3oT633NFBSuUWchlMMAZ9n4rVLzs0puJgLLZRPuM2Kw8Vm8MSKqHSQM828h06O07LwQq+1Mw=
X-Received: by 2002:aa7:d1d7:0:b0:410:d6cf:82b2 with SMTP id
 g23-20020aa7d1d7000000b00410d6cf82b2mr17809776edp.193.1646038317638; Mon, 28
 Feb 2022 00:51:57 -0800 (PST)
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: Archimedes Gaviola 
Date: Mon, 28 Feb 2022 16:51:47 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Distorted U-boot Display
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000035a5f705d91029cb"
X-Rspamd-Queue-Id: 4K6Yz307lLz4mQm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=l+lmwtHC;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7287
Lines: 151

--00000000000035a5f705d91029cb
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 26, 2022 at 11:49 AM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

> Hi,
>
> I've installed FreeBSD 13.0-RELEASE and 14.0-CURRENT successfully with
> Raspberry Pi 3B. However, upon U-boot initialization stage the monitor
> display is distorted as you can see here
> https://pasteboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is
> loaded it displays normal as you can see here
> https://pasteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowering the
> resolution so I tried changing the HDMI configuration settings in the
> config.txt but it cannot be changed, it has no effect. It always stays on
> the default 1366x768 as what dmesg has detected. This behavior is also
> observed in 14.0-CURRENT.
>
> FreeBSD 13.0-RELEASE #0: Sat Feb 19 14:09:03 PST 2022
>     root@fbsd13:/usr/src/sys/arm64/compile/GENERIC arm64
> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git
> llvmorg-11.0.1-0-g43ff75f2c3fe)
> VT(efifb): resolution 1366x768
> ...
> 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.0.
> VT: Replacing driver "efifb" with new "fb".
> fb0: 1366x768(1366x768@0,0) 32bpp
> fb0: fbswap: 1, pitch 5504, base 0x3e7f2000, screen_size 4227072
>
> freebsd@fbsd13:~ % cat /boot/msdos/config.txt
> [all]
> arm_64bit=1
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=ds3231
> dtoverlay=mmc
> dtoverlay=disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
> enable_uart=1
>
> [pi4]
> hdmi_group=2
> hdmi_mode=11
> armstub=armstub8-gic.bin
>
> freebsd@fbsd13:~ % grep -r "1366x768" /boot/msdos/
> Binary file /boot/msdos/start_cd.elf matches
> Binary file /boot/msdos/start_db.elf matches
> Binary file /boot/msdos/start_x.elf matches
> Binary file /boot/msdos/start.elf matches
> Binary file /boot/msdos/start4.elf matches
> Binary file /boot/msdos/start4cd.elf matches
> Binary file /boot/msdos/start4db.elf matches
> Binary file /boot/msdos/start4x.elf matches
>
> Using the same images with 13.0-RELEASE and 14.0-CURRENT this issue does
> not occur in RPi 4B. Anyone encountered this issue? I confirmed this as
> well with another new RPi 3B hardware and it behaves the same. Please see
> attached dmesg log output for reference.
>
> Okay, I got this working now with the following HDMI config.txt
adjustment. I just indicated the :0 which means the first HDMI interface in
group and mode settings. So, the configuration from

hdmi_group=2
hdmi_mode=11

becomes

hdmi_group:0=2
hdmi_mode:0=11

Tested using 14.0-CURRENT.

freebsd@generic:~ % uname -a
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n253384-45c23c2608e: Thu Feb 24 09:18:58 UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64

Reference:
https://www.raspberrypi.com/documentation/computers/config_txt.html

Thanks,
Archimedes

--00000000000035a5f705d91029cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Feb 26, 2022 at 11:49 AM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:
Hi,

I=
9;ve installed FreeBSD 13.0-RELEASE and 14.0-CURRENT successfully with Rasp=
berry Pi 3B. However, upon U-boot initialization stage the monitor display =
is distorted as you can see here https://pasteboard.co/hxDjJHwxXPc8.jpg but w=
hen the FreeBSD kernel is loaded it displays normal as you can see here https://p=
asteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowering the resolution=
 so I tried changing the HDMI configuration settings in the config.txt but =
it cannot be changed, it has no effect. It always stays on the default 1366=
x768 as what dmesg has detected. This behavior is also observed in 14.0-CUR=
RENT.

FreeBSD 13.0-RELEASE #0: Sat Feb 19 14:0=
9:03 PST 2022
=C2=A0 =C2=A0 root@fbsd13:/usr/src/sys/arm64/compile/GENER=
IC arm64
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.=
git llvmorg-11.0.1-0-g43ff75f2c3fe)
VT(efifb): resolution 1366x768
=

...
fb0: <BCM2835 VT framebuffer driver> on simplebus0=

fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device &q=
uot;fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT:=
 Replacing driver "efifb" with new "fb".
fb0: 1366x7=
68(1366x768@0,0) 32bpp
fb0: fbswap: 1, pitch 5504, base 0x3e7f2000, scre=
en_size 4227072

freebsd@fbsd13:~ % cat /boot/msdos=
/config.txt
[all]
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,=
spi=3Don
dtoverlay=3Dds3231
dtoverlay=3Dmmc
dtoverlay=3Ddisable-bt=

device_tree_address=3D0x4000
kernel=3Du-boot.bin
enable_uart=3D1<=
br>
[pi4]
hdmi_group=3D2
hdmi_mode=3D11
armstub=3Darmstub8-gic.=
bin

freebsd@fbsd13:~ % grep -r &quo=
t;1366x768" /boot/msdos/
Binary file /boot/msdos/start_cd.elf match=
es
Binary file /boot/msdos/start_db.elf matches
Binary file /boot/msd=
os/start_x.elf matches
Binary file /boot/msdos/start.elf matches
Bina=
ry file /boot/msdos/start4.elf matches
Binary file /boot/msdos/start4cd.=
elf matches
Binary file /boot/msdos/start4db.elf matches
Binary file =
/boot/msdos/start4x.elf matches

Using the same ima=
ges with 13.0-RELEASE and 14.0-CURRENT this issue does not occur in RPi 4B.=
 Anyone encountered this issue? I confirmed this as well with another new R=
Pi 3B hardware and it behaves the same. Please see attached dmesg log outpu=
t for reference.

Okay, I go=
t this working now with the following HDMI config.txt adjustment. I just in=
dicated the :0 which means the first HDMI interface in group and mode setti=
ngs. So, the configuration from

hdmi_group=3D2=

hdmi_mode=3D11

becomes
hdmi_group:0=3D2
hdmi_mode:0=3D11

=
Tested using 14.0-CURRENT.

freebsd@generic:~ %=
 uname -a
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n253=
384-45c23c2608e: Thu Feb 24 09:18:58 UTC 2022 =C2=A0 =C2=A0 root@releng1.ny=
i.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

Thanks,
Archim=
edes




--00000000000035a5f705d91029cb--

From nobody Mon Feb 28 19:26:49 2022
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 7654719D9E8B
	for ; Mon, 28 Feb 2022 19:27:00 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K6r3l3qTdz4Xl0
	for ; Mon, 28 Feb 2022 19:26:59 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=In-Reply-To:Message-ID:From:MIME-Version:Date:References:Subject:Cc
	:To:Content-Type:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=oGb6hWGRT1F5h70HUacIyb7ELOtveT7r2HFgHLoeNSw=; b=WtkKQHBU7rY+aH+gHwwQ+7SOcN
	Bxw8GqeNL4Y6wOJ+j3TmYDREiiGX8BhRKQkd+rhiHMzri4u2Cj1MoV9a0Y16IdVaFnhsuutHpK74D
	nSdoPcoH14wMfrprMKHmbVPp1pepqVNRazB9pSJ6y6gTvVw+T9a4mVuKPVLuh452GcJI=;
Content-Type: multipart/alternative; boundary=----------fUu38EU0gquoIVv62Jdqb2
To: "Marco Devesas Campos" , "Warner Losh"
 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64
References: 
 
 <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com>
 <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws>
 <106195874.50.1644310150579@localhost>
 
 
Date: Mon, 28 Feb 2022 20:26:49 +0100
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
From: "Ronald Klop" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/1.0 (Win32)
X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: -
X-Spam-Score: -1.2
X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 5687c124a59f8446ff23677bbf5e6265
X-Rspamd-Queue-Id: 4K6r3l3qTdz4Xl0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=WtkKQHBU;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[195.190.28.88:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com,bsdimp.com];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 12906
Lines: 403

------------fUu38EU0gquoIVv62Jdqb2
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable

On Sun, 27 Feb 2022 17:41:25 +0100, Warner Losh  wrote:

>
>
> On Sun, Feb 27, 2022 at 8:44 AM Marco Devesas Campos  =

>  wrote:
>> Hi, List
>>
>> On the back of Ronald Klop's comments (thanks!), I went and got mysel=
f  =

>> an
>> RPI 4 and it turns out all that was need was adding the right dtb
>> reference and it all works (seemingly) fine (incremental patch  =

>> attached).
>
> I've committed the patch below. If it turns out we need more, we can  =

> always augment.


Hi Marco, Warner,

Isn't the patch from  =

https://lists.freebsd.org/archives/freebsd-arm/2022-February/000949.html=
  =

needed also?
As you mention the patch below is an incremental patch?

Regards,
Ronald.






>
> Warner
>
>> One of the potential projects highlighted in the latest call for  =

>> proposals
>> was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. I=
f
>> anyone who voted for that reads this list, wd be nice to get some inp=
ut  =

>> on
>> the patches.
>>
>> Best,
>> Marco
>>
>>
>>
>> diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c  =

>> b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> index dc18678b99a3..344267ff0c1c 100644
>> --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> @@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NUL=
L;
>> static struct ofw_compat_data compat_data[] =3D {
>>        {"broadcom,bcm2835-vchiq",      BSD_DTB},
>>        {"brcm,bcm2835-vchiq",          UPSTREAM_DTB},
>> +       {"brcm,bcm2711-vchiq",          UPSTREAM_DTB},
>>        {NULL,                          0}
>> };
>>
>>
>>
>>> On 8 Feb 2022, at 08:49, Ronald Klop  wrote:
>>>Van: Ronald Klop 
>>> Datum: maandag, 7 februari 2022 21:05
>>> Aan: Marco Devesas Campos ,  =

>>> freebsd-arm@freebsd.org
>>> Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support =
 =

>>> for arm64
>>>On 2/6/22 14:46, Marco Devesas Campos wrote:
>>> > Hi Ronald,
>>> >
>>> > Thanks so much for trying out the patch out.
>>> >
>>> >> On 6 Feb 2022, at 13:05, Ronald Klop  wrote=
:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no  =

>>> difference in available devices.
>>> >> I can try to boot it on a RPI3B+ on another time.
>>> >
>>> > I *think* the GPU/VC in RPI-4 is a very different beast from the  =

>>> others. I'll
>>> > look into it, but if you could give it a try on the 3+ I'd be much=
  =

>>> obliged.
>>> >
>>> >>
>>> >> What would be the expected outcome? Where should I look at (or  =

>>> listen to)?
>>> >>
>>> >
>>> > You should see something like
>>> >
>>> >    vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on  =

>>> simplebus0
>>> >    vchiq: local ver 8 (min 3), remote ver 8.
>>> >    pcm0:  on vchiq0
>>> >
>>> > in your dmesg output.
>>> >
>>> > The file /dev/vchiq should exist, as well as the following sysctl-=
s  =

>>> (I'm
>>> > assuming no other audio devices are attached)
>>> >
>>> >    % sysctl dev.pcm
>>> >    dev.pcm.0.trace: 0
>>> >    ...
>>> >    dev.pcm.0.dest: 0
>>> >    ...
>>> >    dev.pcm.0.%parent: vchiq0
>>> >    ...
>>> >    dev.pcm.0.%driver: pcm
>>> >    dev.pcm.0.%desc: VCHIQ audio
>>> >    =E2=80=A6
>>> >
>>> > Then if you `cat < /dev/random > /dev/dsp` you should hear some  =

>>> static coming
>>> > out of whatever is connected to hdmi (maybe headphones too?  =

>>> otherwise try
>>> > setting `sysctl dev.pcm.0.dest=3D1`)
>>> >
>>> > Best,
>>> > Marco
>>>Hi,
>>>Booted the patched 14-CURRENT on the RPI3B+.
>>>dmesg diff:
>>> +vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on simpleb=
us0
>>> +vchiq: local ver 8 (min 3), remote ver 8.
>>> +pcm0:  on vchiq0
>>>[root@rpi3 ~]# cat /dev/sndstat
>>> Installed devices:
>>> pcm0:  (play) default
>>> No devices installed from userspace.
>>>[root@rpi3 ~]# sysctl dev.pcm
>>> dev.pcm.0.trace: 0
>>> dev.pcm.0.starved: 0
>>> dev.pcm.0.freebuffer: 40000
>>> dev.pcm.0.underruns: 0
>>> dev.pcm.0.retrieved: 0
>>> dev.pcm.0.submitted: 0
>>> dev.pcm.0.callbacks: 0
>>> dev.pcm.0.dest: 0
>>> dev.pcm.0.mode: 3
>>> dev.pcm.0.bitperfect: 0
>>> dev.pcm.0.buffersize: 0
>>> dev.pcm.0.play.vchanformat: s16le:2.0
>>> dev.pcm.0.play.vchanrate: 48000
>>> dev.pcm.0.play.vchanmode: fixed
>>> dev.pcm.0.play.vchans: 1
>>> dev.pcm.0.%parent: vchiq0
>>> dev.pcm.0.%pnpinfo:
>>> dev.pcm.0.%location:
>>> dev.pcm.0.%driver: pcm
>>> dev.pcm.0.%desc: VCHIQ audio
>>> dev.pcm.%parent:
>>>To play some audio I need to search some headphones first. :-)
>>>Ronald.
>>>  Good morning,
>>>Found headphones with a cable on the attic. Plugged it into the audio=
  =

>>> jack and played an mp3. Amazing!
>>>Regards,
>>> Ronald.
------------fUu38EU0gquoIVv62Jdqb2
Content-Type: multipart/related; boundary=----------fUu38EU0gquoIVXPrLJBDs

------------fUu38EU0gquoIVXPrLJBDs
Content-Type: text/html; charset=utf-8
Content-ID: 
Content-Transfer-Encoding: Quoted-Printable





On Sun, 27 Feb 2022 17:41:25 +0100, Warner Losh <imp@bsdimp.com> =
wrote:



On Sun, Feb 27, 2022 at 8:44 AM Marco =
Devesas Campos <devesas.campos@gmail.com> wrote:
Hi, List



On the back of Ronald Klop's comments (thanks!), I went and got myself =
an

RPI 4 and it turns out all that was need was adding the right dtb

reference and it all works (seemingly) fine (incremental patch =
attached).

I've committed the patch below. If it =
turns out we need more, we can always =
augment.


Hi =
Marco, Warner,

Isn't the patch from https://lists.freebsd.org/archives/freebsd-arm/2022-February/00=
0949.html needed also?
As you mention the patch =
below is an incremental patch?

Regards,
Ronald.







Warner
 

One of the potential projects highlighted in the latest call for =
proposals

was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. =
If

anyone who voted for that reads this list, wd be nice to get some input =
on

the patches.



Best,

Marco







diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c =
b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

index dc18678b99a3..344267ff0c1c 100644

--- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

+++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

@@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D =
NULL;

 static struct ofw_compat_data compat_data[] =3D {

        {"broadcom,bcm2835-vchiq",    =
  BSD_DTB},

        {"brcm,bcm2835-vchiq",      =
    UPSTREAM_DTB},

+       {"brcm,bcm2711-vchiq",      =
    UPSTREAM_DTB},

        {NULL,          =
                0}

 };







> On 8 Feb 2022, at 08:49, Ronald Klop <ronald-lists@klop.ws> wrote:

> 

> Van: Ronald Klop <ronald-lists@klop.ws>

> Datum: maandag, 7 februari 2022 21:05

> Aan: Marco Devesas Campos <devesas.campos@gmail.com>, freebsd-arm@freebsd.org

> Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support =
for arm64

> 

> On 2/6/22 14:46, Marco Devesas Campos wrote:

> > Hi Ronald,

> >

> > Thanks so much for trying out the patch out.

> >

> >> On 6 Feb 2022, at 13:05, Ronald Klop <ronald-lists@klop.ws> wrote:

> >>

> >> Hi,

> >>

> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I =
see no difference in available devices.

> >> I can try to boot it on a RPI3B+ on another time.

> >

> > I *think* the GPU/VC in RPI-4 is a very different beast from =
the others. I'll

> > look into it, but if you could give it a try on the 3+ I'd be =
much obliged.

> >

> >>

> >> What would be the expected outcome? Where should I look at =
(or listen to)?

> >>

> >

> > You should see something like

> >

> >    vchiq0: <BCM2835 VCHIQ> mem =
0x7e00b840-0x7e00b87b irq 54 on simplebus0

> >    vchiq: local ver 8 (min 3), remote ver 8.

> >    pcm0: <VCHIQ audio> on vchiq0

> >

> > in your dmesg output.

> >

> > The file /dev/vchiq should exist, as well as the following =
sysctl-s (I'm

> > assuming no other audio devices are attached)

> >

> >    % sysctl dev.pcm

> >    dev.pcm.0.trace: 0

> >    ...

> >    dev.pcm.0.dest: 0

> >    ...

> >    dev.pcm.0.%parent: vchiq0

> >    ...

> >    dev.pcm.0.%driver: pcm

> >    dev.pcm.0.%desc: VCHIQ audio

> >    =E2=80=A6

> >

> > Then if you `cat < /dev/random > /dev/dsp` you should =
hear some static coming

> > out of whatever is connected to hdmi (maybe headphones too? =
otherwise try

> > setting `sysctl dev.pcm.0.dest=3D1`)

> >

> > Best,

> > Marco

> 

> 

> Hi,

> 

> Booted the patched 14-CURRENT on the RPI3B+.

> 

> dmesg diff:

> +vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b87b irq 54 on =
simplebus0

> +vchiq: local ver 8 (min 3), remote ver 8.

> +pcm0: <VCHIQ audio> on vchiq0

> 

> [root@rpi3 ~]# cat /dev/sndstat

> Installed devices:

> pcm0: <VCHIQ audio> (play) default

> No devices installed from userspace.

> 

> [root@rpi3 ~]# sysctl dev.pcm

> dev.pcm.0.trace: 0

> dev.pcm.0.starved: 0

> dev.pcm.0.freebuffer: 40000

> dev.pcm.0.underruns: 0

> dev.pcm.0.retrieved: 0

> dev.pcm.0.submitted: 0

> dev.pcm.0.callbacks: 0

> dev.pcm.0.dest: 0

> dev.pcm.0.mode: 3

> dev.pcm.0.bitperfect: 0

> dev.pcm.0.buffersize: 0

> dev.pcm.0.play.vchanformat: s16le:2.0

> dev.pcm.0.play.vchanrate: 48000

> dev.pcm.0.play.vchanmode: fixed

> dev.pcm.0.play.vchans: 1

> dev.pcm.0.%parent: vchiq0

> dev.pcm.0.%pnpinfo:

> dev.pcm.0.%location:

> dev.pcm.0.%driver: pcm

> dev.pcm.0.%desc: VCHIQ audio

> dev.pcm.%parent:

> 

> 

> To play some audio I need to search some headphones first. :-)

> 

> Ronald.

>  

> 

> 

> Good morning,

> 

> Found headphones with a cable on the attic. Plugged it into the =
audio jack and played an mp3. Amazing!

> 

> Regards,

> Ronald.

>  












=

--Apple-Mail=_6390B139-EA65-43CA-B7BA-C9C88ABEB429--

From nobody Mon Feb 28 19:42:24 2022
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 ACB1F19DE04D
	for ; Mon, 28 Feb 2022 19:42:38 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934])
	(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 4K6rPn3sN5z4bxs
	for ; Mon, 28 Feb 2022 19:42:37 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x934.google.com with SMTP id a28so1439891uaf.7
        for ; Mon, 28 Feb 2022 11:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=tDZh1g/07oJxcvyZ93i3L1V5dxn8ACurxnd1slHIhyw=;
        b=Vxpm7UgIkUasRW3pl7yv7tavW2wXMTSQw5VuUV0MZTDWdlZJCJTqPJB+A6tdR5CQF5
         9+p0xEG1yZbprq0+sFT07fS9tCPdGOd71ZvvRbJUdlObqcEkFCwI42KXoJjB5iu62V5E
         onWmHQJ6Z8/ddIekX2FpiVOl565bOSiiwTcRxNn/z8eqJLcWA0d8/180faI97gqhIt5e
         de57h71cIqA4MQnIoIW9neEgo1D1Eszo2u82k1z8RRc0jsLmc3x+WhCy4NnksZ/YnIOQ
         ufHlJnvJeR2YR+6I/82q34shfCok4v0QJWM/jNRn8HAU7DY9iC9oXhQbcupJfPnHi1l5
         g/bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=tDZh1g/07oJxcvyZ93i3L1V5dxn8ACurxnd1slHIhyw=;
        b=MGV/RuLqa+1he72aCjJSB6ptq3nAnx6OWjsJKU/jr18hZkIpxbvaiqEz/ENr83JI/n
         UpKheStuyVNzt1/02ny1XiOlCl7E7zl9XJrq9eK82425VwKwKV/LQjvoBH+iZds147gp
         s9P6JlTpUtxEF/6yHNsJ28wQCcAb3ICK2Gf8QsgKoFQTYJveq7k5voal7pdhGStGmMtH
         pxOihpaxlixjZBaUSNVlzLZitFdy/Z9gC83wCfDNWghErC/XT4KPVp/O35s4qF6B0Mmj
         VEBJOIEQS9GRnHAVuyHqQA+TcEuxSStdL445/zG13ipDVpbKK+93ztBlEReuys3LvVQW
         Ch/Q==
X-Gm-Message-State: AOAM532M0JGQHsWrrIXWgSmbJP2XI19PVaZTiNE43pnZUk5bunOCg3iA
	8zfN5rPUn9S4J57puiIN/Flp+xsAL0qodtYIbIKRxppcDVU=
X-Google-Smtp-Source: ABdhPJz64GQZC8qdbP5qwdcPmLSziTqwBfHxcNVDAfla2UUnw3rvtci9hZaXg65kDRSP2kqu0j32RC6O/uEzRIIYYQY=
X-Received: by 2002:ab0:694d:0:b0:340:618e:57a5 with SMTP id
 c13-20020ab0694d000000b00340618e57a5mr8117555uas.54.1646077356811; Mon, 28
 Feb 2022 11:42:36 -0800 (PST)
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: 
  <8EC05647-00D9-455B-98A9-B83A33DDFC5D@gmail.com>
 <48190d6a-fc5d-7da9-ddfd-fded48d429db@klop.ws> <106195874.50.1644310150579@localhost>
  
  <87A63A19-5807-4BA9-9821-D3378129CDB5@gmail.com>
In-Reply-To: <87A63A19-5807-4BA9-9821-D3378129CDB5@gmail.com>
From: Warner Losh 
Date: Mon, 28 Feb 2022 12:42:24 -0700
Message-ID: 
Subject: Re: [PATCH] Experimental vchiq and bcm2835_audio support for arm64
To: Marco Devesas Campos 
Cc: Ronald Klop , 
	"freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000203d1605d9194013"
X-Rspamd-Queue-Id: 4K6rPn3sN5z4bxs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Vxpm7UgI;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::934) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 RCVD_TLS_ALL(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 15606
Lines: 450

--000000000000203d1605d9194013
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 28, 2022, 12:36 PM Marco Devesas Campos <
devesas.campos@gmail.com> wrote:

> Entirely right, Ronald =E2=80=94 thanks for catching it!
>

Oops

Warner, can I send you a consolidated patch later in the week? What=E2=80=
=99s the
> best way to submit it?
>

Git format-patch is likely best.

Warner


> Best,
> Marco
>
> On 28 Feb 2022, at 19:26, Ronald Klop  wrote:
>
> On Sun, 27 Feb 2022 17:41:25 +0100, Warner Losh  wrote:
>
>
>
> On Sun, Feb 27, 2022 at 8:44 AM Marco Devesas Campos <
> devesas.campos@gmail.com> wrote:
>
>> Hi, List
>>
>> On the back of Ronald Klop's comments (thanks!), I went and got myself a=
n
>> RPI 4 and it turns out all that was need was adding the right dtb
>> reference and it all works (seemingly) fine (incremental patch attached)=
.
>>
>
> I've committed the patch below. If it turns out we need more, we can
> always augment.
>
>
>
> Hi Marco, Warner,
>
> Isn't the patch from
> https://lists.freebsd.org/archives/freebsd-arm/2022-February/000949.html
> needed also?
> As you mention the patch below is an incremental patch?
>
> Regards,
> Ronald.
>
>
>
>
>
>
>
> Warner
>
>
>> One of the potential projects highlighted in the latest call for proposa=
ls
>> was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. If
>> anyone who voted for that reads this list, wd be nice to get some input =
on
>> the patches.
>>
>> Best,
>> Marco
>>
>>
>>
>> diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> index dc18678b99a3..344267ff0c1c 100644
>> --- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> +++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c
>> @@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NULL;
>>  static struct ofw_compat_data compat_data[] =3D {
>>         {"broadcom,bcm2835-vchiq",      BSD_DTB},
>>         {"brcm,bcm2835-vchiq",          UPSTREAM_DTB},
>> +       {"brcm,bcm2711-vchiq",          UPSTREAM_DTB},
>>         {NULL,                          0}
>>  };
>>
>>
>>
>> > On 8 Feb 2022, at 08:49, Ronald Klop  wrote:
>> >
>> > Van: Ronald Klop 
>> > Datum: maandag, 7 februari 2022 21:05
>> > Aan: Marco Devesas Campos ,
>> freebsd-arm@freebsd.org
>> > Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support fo=
r
>> arm64
>> >
>> > On 2/6/22 14:46, Marco Devesas Campos wrote:
>> > > Hi Ronald,
>> > >
>> > > Thanks so much for trying out the patch out.
>> > >
>> > >> On 6 Feb 2022, at 13:05, Ronald Klop  wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see no
>> difference in available devices.
>> > >> I can try to boot it on a RPI3B+ on another time.
>> > >
>> > > I *think* the GPU/VC in RPI-4 is a very different beast from the
>> others. I'll
>> > > look into it, but if you could give it a try on the 3+ I'd be much
>> obliged.
>> > >
>> > >>
>> > >> What would be the expected outcome? Where should I look at (or
>> listen to)?
>> > >>
>> > >
>> > > You should see something like
>> > >
>> > >    vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on
>> simplebus0
>> > >    vchiq: local ver 8 (min 3), remote ver 8.
>> > >    pcm0:  on vchiq0
>> > >
>> > > in your dmesg output.
>> > >
>> > > The file /dev/vchiq should exist, as well as the following sysctl-s
>> (I'm
>> > > assuming no other audio devices are attached)
>> > >
>> > >    % sysctl dev.pcm
>> > >    dev.pcm.0.trace: 0
>> > >    ...
>> > >    dev.pcm.0.dest: 0
>> > >    ...
>> > >    dev.pcm.0.%parent: vchiq0
>> > >    ...
>> > >    dev.pcm.0.%driver: pcm
>> > >    dev.pcm.0.%desc: VCHIQ audio
>> > >    =E2=80=A6
>> > >
>> > > Then if you `cat < /dev/random > /dev/dsp` you should hear some
>> static coming
>> > > out of whatever is connected to hdmi (maybe headphones too? otherwis=
e
>> try
>> > > setting `sysctl dev.pcm.0.dest=3D1`)
>> > >
>> > > Best,
>> > > Marco
>> >
>> >
>> > Hi,
>> >
>> > Booted the patched 14-CURRENT on the RPI3B+.
>> >
>> > dmesg diff:
>> > +vchiq0:  mem 0x7e00b840-0x7e00b87b irq 54 on simplebus=
0
>> > +vchiq: local ver 8 (min 3), remote ver 8.
>> > +pcm0:  on vchiq0
>> >
>> > [root@rpi3 ~]# cat /dev/sndstat
>> > Installed devices:
>> > pcm0:  (play) default
>> > No devices installed from userspace.
>> >
>> > [root@rpi3 ~]# sysctl dev.pcm
>> > dev.pcm.0.trace: 0
>> > dev.pcm.0.starved: 0
>> > dev.pcm.0.freebuffer: 40000
>> > dev.pcm.0.underruns: 0
>> > dev.pcm.0.retrieved: 0
>> > dev.pcm.0.submitted: 0
>> > dev.pcm.0.callbacks: 0
>> > dev.pcm.0.dest: 0
>> > dev.pcm.0.mode: 3
>> > dev.pcm.0.bitperfect: 0
>> > dev.pcm.0.buffersize: 0
>> > dev.pcm.0.play.vchanformat: s16le:2.0
>> > dev.pcm.0.play.vchanrate: 48000
>> > dev.pcm.0.play.vchanmode: fixed
>> > dev.pcm.0.play.vchans: 1
>> > dev.pcm.0.%parent: vchiq0
>> > dev.pcm.0.%pnpinfo:
>> > dev.pcm.0.%location:
>> > dev.pcm.0.%driver: pcm
>> > dev.pcm.0.%desc: VCHIQ audio
>> > dev.pcm.%parent:
>> >
>> >
>> > To play some audio I need to search some headphones first. :-)
>> >
>> > Ronald.
>> >
>> >
>> >
>> > Good morning,
>> >
>> > Found headphones with a cable on the attic. Plugged it into the audio
>> jack and played an mp3. Amazing!
>> >
>> > Regards,
>> > Ronald.
>> >
>>
>>
>>
>
>
>
>

--000000000000203d1605d9194013
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 28, 2022, 12:36 PM Marco Devesas Campos &l=
t;devesas.campos@gmail.com&=
gt; wrote:
Entirely right, Ronald =E2=80=94 t=
hanks for catching it!

Oops

Warner, can I s=
end you a consolidated patch later in the week? What=E2=80=99s the best way=
 to submit it?

<=
/div>
Git format-patch is likely best.

Warner=C2=A0


Best,
Marco

On 28 Feb 2022, a=
t 19:26, Ronald Klop <ronald-lists@klop.ws> wrote:





On Sun, 27 Feb 2022 17:41:25 +0100, Warner Losh <imp@bsdimp.com>=
 wrote:



=

On Sun, Fe=
b 27, 2022 at 8:44 AM Marco Devesas Campos <devesas.campos@gmail.c=
om> wrote:
https://lists.freebsd.org/archives/freebsd-arm/2022-February/000949.htm=
l needed also?
As you mention the patch below is an increment=
al patch?

Regards,
Ronald.





Warner
=C2=A0

One of the potential projects highlighted in the latest call for proposals<=
br>
was exactly to get hdmi audio output in 64 bit Pis, viz. the 400-s. If

anyone who voted for that reads this list, wd be nice to get some input on<=
br>
the patches.



Best,

Marco







diff --git a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c b/sys/contr=
ib/vchiq/interface/vchiq_arm/vchiq_kmod.c

index dc18678b99a3..344267ff0c1c 100644

--- a/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

+++ b/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kmod.c

@@ -83,6 +83,7 @@ static struct bcm_vchiq_softc *bcm_vchiq_sc =3D NULL;

=C2=A0static struct ofw_compat_data compat_data[] =3D {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"broadcom,bcm2835-vchiq",=C2=A0 =C2=
=A0 =C2=A0 BSD_DTB},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {"brcm,bcm2835-vchiq",=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 UPSTREAM_DTB},

+=C2=A0 =C2=A0 =C2=A0 =C2=A0{"brcm,bcm2711-vchiq",=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 UPSTREAM_DTB},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {NULL,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0}

=C2=A0};







> On 8 Feb 2022, at 08:49, Ronald Klop <ronald-lists@klop.ws>=
; wrote:

> 

> Van: Ronald Klop <ronald-lists@klop.ws>

> Datum: maandag, 7 februari 2022 21:05

> Aan: Marco Devesas Campos <devesas.campos@gmail.com>, =
freebsd-arm@freebsd.org

> Onderwerp: Re: [PATCH] Experimental vchiq and bcm2835_audio support fo=
r arm64

> 

> On 2/6/22 14:46, Marco Devesas Campos wrote:

> > Hi Ronald,

> >

> > Thanks so much for trying out the patch out.

> >

> >> On 6 Feb 2022, at 13:05, Ronald Klop <ronald-lists@klop.=
ws> wrote:

> >>

> >> Hi,

> >>

> >> I compiled this on a RPI4 + 14-CURRENT. It boots, but I see n=
o difference in available devices.

> >> I can try to boot it on a RPI3B+ on another time.

> >

> > I *think* the GPU/VC in RPI-4 is a very different beast from the =
others. I'll

> > look into it, but if you could give it a try on the 3+ I'd be=
 much obliged.

> >

> >>

> >> What would be the expected outcome? Where should I look at (o=
r listen to)?

> >>

> >

> > You should see something like

> >

> >=C2=A0 =C2=A0 vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b=
87b irq 54 on simplebus0

> >=C2=A0 =C2=A0 vchiq: local ver 8 (min 3), remote ver 8.

> >=C2=A0 =C2=A0 pcm0: <VCHIQ audio> on vchiq0

> >

> > in your dmesg output.

> >

> > The file /dev/vchiq should exist, as well as the following sysctl=
-s (I'm

> > assuming no other audio devices are attached)

> >

> >=C2=A0 =C2=A0 % sysctl dev.pcm

> >=C2=A0 =C2=A0 dev.pcm.0.trace: 0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.dest: 0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.%parent: vchiq0

> >=C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 dev.pcm.0.%driver: pcm

> >=C2=A0 =C2=A0 dev.pcm.0.%desc: VCHIQ audio

> >=C2=A0 =C2=A0 =E2=80=A6

> >

> > Then if you `cat < /dev/random > /dev/dsp` you should hear =
some static coming

> > out of whatever is connected to hdmi (maybe headphones too? other=
wise try

> > setting `sysctl dev.pcm.0.dest=3D1`)

> >

> > Best,

> > Marco

> 

> 

> Hi,

> 

> Booted the patched 14-CURRENT on the RPI3B+.

> 

> dmesg diff:

> +vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b87b irq 54 on sim=
plebus0

> +vchiq: local ver 8 (min 3), remote ver 8.

> +pcm0: <VCHIQ audio> on vchiq0

> 

> [root@rpi3 ~]# cat /dev/sndstat

> Installed devices:

> pcm0: <VCHIQ audio> (play) default

> No devices installed from userspace.

> 

> [root@rpi3 ~]# sysctl dev.pcm

> dev.pcm.0.trace: 0

> dev.pcm.0.starved: 0

> dev.pcm.0.freebuffer: 40000

> dev.pcm.0.underruns: 0

> dev.pcm.0.retrieved: 0

> dev.pcm.0.submitted: 0

> dev.pcm.0.callbacks: 0

> dev.pcm.0.dest: 0

> dev.pcm.0.mode: 3

> dev.pcm.0.bitperfect: 0

> dev.pcm.0.buffersize: 0

> dev.pcm.0.play.vchanformat: s16le:2.0

> dev.pcm.0.play.vchanrate: 48000

> dev.pcm.0.play.vchanmode: fixed

> dev.pcm.0.play.vchans: 1

> dev.pcm.0.%parent: vchiq0

> dev.pcm.0.%pnpinfo:

> dev.pcm.0.%location:

> dev.pcm.0.%driver: pcm

> dev.pcm.0.%desc: VCHIQ audio

> dev.pcm.%parent:

> 

> 

> To play some audio I need to search some headphones first. :-)

> 

> Ronald.

>=C2=A0 

> 

> 

> Good morning,

> 

> Found headphones with a cable on the attic. Plugged it into the audio =
jack and played an mp3. Amazing!

> 

> Regards,

> Ronald.

>=C2=A0 














--000000000000203d1605d9194013--

From nobody Tue Mar  1 04:52:05 2022
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 6435E19DC86D
	for ; Tue,  1 Mar 2022 04:52:09 +0000 (UTC)
	(envelope-from philip@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 4K74bs2CpSz4rfY;
	Tue,  1 Mar 2022 04:52:09 +0000 (UTC)
	(envelope-from philip@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1646110329;
	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=+Q7suiuJmsvAOcX9ZisVAE7pZnXx0hZzU7FvucETdyA=;
	b=tDkqfEWuvWk+HYnySBsGWTIsGMjAksaCfI2pVGNTW4bIqVL73YjXzB/C78J7zofNgrWFnO
	qttJnUiw/COdTz5X1UsiG8DknsOD+D84IyZQ4bmqmX+9GRErh6UHf250o4Dwv3Tc8WhApY
	oWZfHsMEca42YQlvzfWJMJjrrTh1G42UowFagTRwYUuyvM+8rEV2fv3m/bPtnlQl92oB8z
	1fp+G2a7/e/2hBdi4K4aW4kN+foQD59I4AF9ZVRrdwN6xqk19eUOos/vCDNONMom7qTDm5
	vvzIirrH5aP7rxdTCO+w9n+y5WJHNBTTDWxI/o7oazcfuPeYDUmLDaxXDKx8DA==
Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: philip/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 283412E20;
	Tue,  1 Mar 2022 04:52:09 +0000 (UTC)
	(envelope-from philip@freebsd.org)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
	by mailauth.nyi.internal (Postfix) with ESMTP id 0D34E27C0054;
	Mon, 28 Feb 2022 23:52:09 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
  by compute3.internal (MEProxy); Mon, 28 Feb 2022 23:52:09 -0500
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddtuddgjeehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfgjfhggtgfgsehtqh
    hmtdertddtnecuhfhrohhmpefrhhhilhhiphcurfgrvghpshcuoehphhhilhhiphesfhhr
    vggvsghsugdrohhrgheqnecuggftrfgrthhtvghrnhepveevieeuffefieeigfdukeduvd
    ehteduhfelfeejhfetgfegudetfeelhfefhfetnecuffhomhgrihhnpehfrhgvvggsshgu
    rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh
    epphhhihhlihhpodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiiedv
    iedvgeekqddvfeehudektddtkedqphhhihhlihhppeepfhhrvggvsghsugdrohhrghesth
    hrohhusghlvgdrihhs
X-ME-Proxy: 
    
    
    
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 28 Feb 2022 23:52:07 -0500 (EST)
From: Philip Paeps 
To: Ronald Klop 
Cc: clusteradm@freebsd.org, Ports Management Team ,
 freebsd-arm@freebsd.org
Subject: Re: aarch64 build cluster and linux64.ko
Date: Tue, 01 Mar 2022 12:52:05 +0800
X-Mailer: MailMate (1.14r5874)
Message-ID: <65B16CD2-7F7A-4D4C-818F-B8E14FD74808@freebsd.org>
In-Reply-To: <180462427.61.1644913953734@mailrelay>
References: <1365005114.369.1643120837534@localhost>
 <993C6A92-7412-4426-903C-A2214B8A8031@freebsd.org>
 <55D4000E-2691-442D-9E46-E1966750344A@freebsd.org>
 <787825862.6.1644527984584@mailrelay>
 <1666CD64-2A90-4BBC-9DEF-C9BCED4738FF@freebsd.org>
 <180462427.61.1644913953734@mailrelay>
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
Content-Transfer-Encoding: quoted-printable
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1646110329;
	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=+Q7suiuJmsvAOcX9ZisVAE7pZnXx0hZzU7FvucETdyA=;
	b=buvo9z2tuVCA3QazEXylU+qY3JiXYu6ogyfvw4vadCbZ+Cg4iyFl9NKEO0PIchsmF0qIng
	/IYD7P28/xaJSp5M3Dft0PvYiyMWpSCvy4N9TkGOqfMxcGqeBheiV+QkuanYYy6bYJWJlE
	+MmQJE6wdeBLT6DryKz50sGRkK+menP/VbSOg56ZfneZGZBZyaW2xmmo2Bf+Of86zCRnM+
	4CHVwfForE/AeKpFF0+GaQWX0MbaxJxWW0/xc0H9ftX9X/vNVOhtne9XWNdcf+t9lOIBxJ
	Pb9IEevEhgTwrA1Jxg5D8UOVlsyGxsnZXwWQCSwsooHtxg5L6KeoMZn6UX1MwQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646110329; a=rsa-sha256; cv=none;
	b=la4/Z5NYO51zoHZE2z87d8C3zBy4Hhd5JDKOzrunj3zh8pbE2EW6asPRf+qNQIIaC3ENQt
	94C/rqY4Oh1pyO2o4Khzfgs1CaeI8zh59ftZazIqPBUHrfZY4QG3rg4J6UK0ltBiQD99Ff
	yXnqmZKPs77UhXLM4fXB0f6Onfg7z6sMw259yTABkIjuR8Hd2XtZaRSf2i+AmLaMC2/xG+
	Mykh5Vf7GOZZ5lZnsdykQiatKjX1fpF3W6rd+3GGL+Af4LisjU+lJV14UcqTL1s2+fOT3J
	+3ppjTyHVnjO2omSrvoKGdXVcgFVxBHK8g2tUDMCcgB+rnCGmtqEi3rvEdJUeA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 706
Lines: 25

On 2022-02-15 16:32:33 (+0800), Ronald Klop wrote:
> One more question.
> Do you know why the arm64 package builds are not registered on =

> https://pkg-status.freebsd.org/builds?type=3Dpackage anymore?
>
> Because the pkg-status page has a nice way to compare two builds and =

> spot regression (or progression).
> https://pkg-status.freebsd.org/builds/default:default:main-arm64:pbd241=
2a3b974_sac678b4aaf:ampere2

I think I fixed this one.  I believe it got stuck on trying to parse the =

status of that build that was interrupted by upgrading.  I cleared the =

logs for that build and something seems to have changed. :)

Philip

-- =

Philip Paeps
Senior Reality Engineer
Alternative Enterprises

From nobody Wed Mar  2 04:46:03 2022
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 CCFAF19F57AD
	for ; Wed,  2 Mar 2022 04:46:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K7hQc6Swkz3Hwg
	for ; Wed,  2 Mar 2022 04:46:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646196369; bh=ZEHIBdVaDpS0f/XmM6/lVKQ1tFUdm4NFHPVkYwd6D2Y=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=Y0+VVp1rzb5NU8cVOk2oxtvbKQJTg4pKn5kEhBlGEOQ9m+xXQiVrWHyBIPnb8QXG2VXtVoEZNla5qJsHAkkGnqqvKaUxVrRiJgPpXsO+STFq/gJ4PXIbw3IgUl9S+WpB7EwfMeuyR76IgwTxC1W75Hr4qQCiKKU7P1cD4JRal7uQhDSd4/otPlZkCeLTyDsVMpITdXhQ7CpzUOrsWMUVtriEDPHUFYCjG004ShBhSbZlCdXws2DhtByiN7LYP+kXTfE4oCLgDVgLOxyX0lQ7hOfJ3KeUvFFSBAXr9EfurUOrSLtcPlJQbUQ7jPmjrDMWCU61LUpedIqU45gZPq621Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646196369; bh=dtc3Gb3beFqySA0Aeyp3iP2uNmp+HvQo7D7Bkl9jzAv=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=YHZFObc75bWcHNj43B3csZbMFIcrpVl4QzU84ot7e7twQYacvebZERqIXXCxKCgUaIvvKC/8mDt11tmaNLhSqk0gLjjwbIcXGwAmRX8oZ4namG5MIyPDiVNZ8jY7iLHueG6TspUXWy6HuWT8dWonAVNK6VVhKFLTPLQFo6qW4xxTfSxgsXwaaxK2usok6SFdw9tn3fFpHwWoxBE6wwr01ljTUAz19kjv8N4AdDdjsOe5mzYvDKWjTpOGaC5PG6MMhLvsz6fRdre6i6K14Y00as8D9GLxx0VZE+211YE/8XRi5/OAu3rVWPBxCaHSEmaZHtDo4omupANuMUZss9VYcg==
X-YMail-OSG: k_R_t.0VM1kRL7KcFbtMgEZTt0ipdJV3bvjG.o4bra6ENLJF3TZO25zDrlrCPJh
 Ni3X7XlQAkIt8ErjHc.yQYXnB7XxUADViL6J_aFPZ13YOAPp9riu6XCx.aWz3SPDFCplpF7icGHp
 CTxWer7Pt3CJhDSWrIb89mjxu8ztJe5gnQPQFkvLKePEx6OnpJUt7DAG29jpkyQQnWJIVh9JiH04
 NJnisZaNkfHnwJli.ya_XKlkQ19uEYT1QFpHSxdSccKqXr0JKQGT97c8wTXrrxfZyQJg5ChKmhs0
 fxqEwDnaLZK_I46QdtteHF2JDU0wFmHzhdD.LqzZekVELSOfD9d7.R2Cf6HZetYiO1_iBi.yMQUl
 1ka3fdqIll.aPQpm4JZNfYTZtgXETSjYoMAwSw3P3PO9Zo7_Z0IcchkXxP.ckKjMNnYVYpFnskwf
 Hi0dLz7RB6z6apIZp7Y6DZXyvBFygwwT0AtCHCqUxtWIQV7FZbkai6XgFpmv1Bb2PekhF2uzukEH
 cgwRhuG_a_3plippSMPPvQxxUQ1C5R6SPF.ip8xa7eyk.ayZhVGajs__FOuTb6zdaRC7qaYmag2J
 oN95R45L7B6lSYTa8MIJ0jztawMTBiCbZBW8_bNWRBuHqvZfKEP9m2lbelVmjku7XSLdpCKo4xkD
 rkxty1r53e8RzqWECBaY0232dr0Gj_oQBa.k90eYrmQXPuRbjP_IvZ3bZm7UWFT4vzNXojYQtySc
 EXS7kkBbFdlJbclNrKV.hG2HWAEB7Pm8W.3Pl_J8JO_U4LwCcIgpiMlZuBYBPgHLaArb9VyBzOmr
 6k0yazLQQ2bGAEC8sWekurtw_HrTUIyexEeovn7bnymo8AZWg.gvKIgl6.RQUPyk3L8IjX6Oj6vN
 rhs8wxc3REASXZFOUiIGSd_ii3PXaWqxGrhdVebmCdMeY9NSkjJxxoxoas5FMwPDm_j0EG6Z5wOg
 T5c_yXJhrpfwuwifk3BxjJf.B8dvCZ6zzWWdAJj.7LHbmQ8YnLer8gyRc4F_hFEOEuwt4O5MiCr1
 eVJSPRYcKtCnRVZbZrEgGxYcveu7UILkxNaawZtZfZ61c9AhxyxB_1iUntr7S.68Egpds2BiEKXt
 2KOlk5rsXyh7S3Gj2mr52H0KwYQyXRaVePejUN2YRbtqV51iSb2US9BnFCnHSW3Z88k0UCxZx3KI
 HjCTqCo52.05TufUSHkdoEUzl2igSdafWwt764FM4CLP6jYH.DpuhxV5nUIKjcH7cVu2L6qBbNlR
 xcCLHWrWqW.5f_e6C77dL_UKUcs4YdmmrL_Nbp0cjtK0Jkcozi0VDIiLUngzXnHCj_pZOYdrAG6_
 MXOicxL.6T0hy_hSUxRjT21Um8pHXMXzdEUeoBWgQk1tsyaw_dR_Pnf3fgpXIO06haCYDjtxla5k
 QWgNbe9HkmoTwVuIbyjP5k19O9JklYEFbPfF0rIVwDLEN3xtj3jqGVod8ZCePAfflsuW7f9J5MOu
 YZIFGH9ICJ0CEi1MIZEvXsdf_7gpyUH2gDuK5W0BfYgiMnpC7Iqp3g4jwq2XyRHhgyvwQV0Z1mVU
 BdRk4NFC6KhENXc5Tvqq11QYYHhQSs0FmjgyZtFRNxV28r65JRRs4zdna266Zf3vomFg5QCRtKW1
 qmaaUvxzwfP9hV1EONx3tj9NTyo1C6wLVc.o28o6hY1OGagdwlfTEXRZtCH.5RFDnZ63S6YMVeZK
 Ozrf3MY9EB4uzqWCNU63xpjZp6XowhHr0G0BJOVBq9Pzwke.4pcLdfbnRJvDUxp50pv1nm2hF._X
 sT.kPyvB0_hbW_0W7eVlQArR.0qBrYVfuzS5PDv2CZceyeRUwnuVWBWce6spk7SHLi.62EVDYelp
 tSll1TOYGXOmFa6TyT2gqhaM0H4.WBSyy8E85ZT_9qzYzD2R_C3J8cCfH.d9BvrcJPKjqmgH5wq6
 5NYLBKMfoY84s3AWW.bgtG8H2xVR8ej91o8oDfPkXyYVAi3p4WhFM3tZR6TV.jcb4i0..vLVp2EW
 9mKTvcC8cbVptVpLz_kAbelX.FkuGd3tCrGzIsEA98G8rR.IsdH_1NcHPNcFGnhQQM3bJy_FJ5.2
 KhzXFwfjfMGOf4lMCJ2wbyS2.U0vKYOKzHzXILb.3JZuLUfl.DmhiG1dWMzmyJm3TG6Z8ZVtXa2G
 P2ag8H5sI1rf4J8qan5xFMz3yhdnN7tRFI03ma30V_sMrayXnPChGfYX_7avkjb74SO12ie9jHRq
 D4VnXWHrFRss20KjobB8XmD.kemP3ApG_av_d3GiQWrePV43l5IdaI5vBlJnQqZxxt4hGAD3pOV2
 6OKUdB9L8YhRxVA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Mar 2022 04:46:09 +0000
Received: by kubenode505.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 37819216843bc7aeb9850eb3190d77e8;
          Wed, 02 Mar 2022 04:46:05 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: EDK2's invalid C code (VLA) problems are reported to have been fixed
 at 42af706dfba7
Message-Id: <129B8917-C877-4B29-B62E-5D7E9C270BB9@yahoo.com>
Date: Tue, 1 Mar 2022 20:46:03 -0800
Cc: "manu@freebsd.org" ,
 Free BSD 
To: freebsd-ports@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <129B8917-C877-4B29-B62E-5D7E9C270BB9.ref@yahoo.com>
X-Rspamd-Queue-Id: 4K7hQc6Swkz3Hwg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y0+VVp1r;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 725
Lines: 18

https://bugzilla.tianocore.org/show_bug.cgi?id=3417 reports that EDK2's
(indirect) problems with compiling under gcc11 are "fixed at
42af706dfba72bf2639ae2101caca10d89701b24" and the status has been set to
RESOLVED FIXED.

Note: EDK2's original problems being rejected for invalid C code
were from an upstream code base and what vintages of that a code
base were being used by EDK2. Still, it left EDK2 broken on
compilers with with correct(ed) VLA checking until EDK2 pulled
in a corrected vintage of the brotli code. (I've not looked at
what else might have gotten involved over the 9 months after the
initial bugzilla.tianocore.org report, so I may be oversimplifying
the history.)

===
Mark Millard
marklmi at yahoo.com


From nobody Thu Mar  3 04:39:30 2022
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 3A77519F1BF5
	for ; Thu,  3 Mar 2022 04:39:31 +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 4K8JDL6Gydz3LZS
	for ; Thu,  3 Mar 2022 04:39:30 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 B92E411785
	for ; Thu,  3 Mar 2022 04:39:30 +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 2234dUFj030922
	for ; Thu, 3 Mar 2022 04:39:30 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2234dUqm030921
	for freebsd-arm@FreeBSD.org; Thu, 3 Mar 2022 04:39:30 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 262310] c++: error: clang frontend command failed with exit
 code 139
Date: Thu, 03 Mar 2022 04:39:30 +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: 13.0-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: wisdom@isogo.dyndns.org
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.mimetype 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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1646282370;
	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=/cZGxTQgY1208xUaP1tWURLcxPXfrBqznM+ISqJCCIo=;
	b=c3OHNop5fHs4rvU3s+aYuLni9a98Qtf3tIUBPWVIvb/sdWeOIGso6PN3GVW/BEYf+km2/t
	BSQvsMrglqbEg/gci4/ayujToQ1e2pzUaG01c/kXwqSZuDBJ9tEMAL6stKZEJqQj/ppTIu
	aEnS3pBvreQZ4OVyK4sR+evFnqfWTfGxfBErSxl/SMzzWBiqtUCj/Sx1jhGKz/0Xstzco1
	c5zn326HWC3rmgUo+TUWgY+adx+wOd6xV4xE2Apk5S7uha9plma9S/nwpquSCeYq3++DHG
	uBINOa25j2dgAnmy0w7TKxaSyCcCoTkEKRJayl8u58AcXXs3A4z1JmJyS9WzsQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646282370; a=rsa-sha256; cv=none;
	b=SZXad2EqxbpH7vxJraAalh6m81mweo/c4mgeaNSmQYV+nJBxw4U2SS4KA3h9fBc5nInCLd
	/sXNjUp3cD8Yg/BqHsKO9rXQFQhqWesgfTq8m83gQ9D7fKDgojO7mlxHd0PENKxKO/CGR+
	MM8s4RZ+Mu5mWcAr/+0QDDFURrrjyWxx3Qdulf/OivP6bDJYTTtpKLG/Yybe/zFSNjJJy9
	zFEUrcXZw9ZXlqLlti3L1N/60Gn4D9mG610T1W19W5C8S4/lax1YoMtjhqrlEJ/MHQ1UXk
	SOTvILVswfhEfdwKz+AXdS6kn2YGCJSGjtX+qoQky0I6eCztxC6QlIo7RkvGYg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4614
Lines: 133

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262310

            Bug ID: 262310
           Summary: c++: error: clang frontend command failed with exit
                    code 139
           Product: Base System
           Version: 13.0-STABLE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: wisdom@isogo.dyndns.org
 Attachment #232218 text/plain
         mime type:

Created attachment 232218
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232218&action=
=3Dedit
c++: note: diagnostic msg

I've tried to build world several times.  However all trials failed on same
place with same error (clang frontend crashed).  Following is a part of the
console log.

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
$ uname -a
FreeBSD raspi.isogo.dyndns.org 13.1-PRERELEASE FreeBSD 13.1-PRERELEASE #14
stable/13-11045f1b7: Mon Feb 28 12:09:56 JST 2022=20=20=20=20
root@raspi.isogo.dyndns.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm=
64
$ cd /usr/src; sudo make buildworld
...
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include =
the
crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: c++ -target aarch64-unknown-freebsd13.0
--sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g -MD
-MF.depend.gtest-all.o -MTgtest-all.o -Wno-format-zero-length
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-str=
ings
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts
-Wredundant-decls -Wmissing-variable-declarations -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=3Dunused-but-set-variable -Qunused-arguments
-I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private
-I/usr/src/contrib/googletest/googletest/include
-I/usr/src/contrib/googletest/googletest -g -std=3Dc++11
-Wno-deprecated-declarations -Wno-deprecated-copy -Wno-c++11-extensions -c
/usr/src/contrib/googletest/googletest/src/gtest-all.cc -o gtest-all.o
1.=20=20=20=20=20
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest=
-type-util.h:960:37:
current parser token '{'
2.=20=20=20=20=20
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtest=
-type-util.h:58:1:
parsing namespace 'testing'
#0 0x0000000004112640 PrintStackTrace
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
#1 0x0000000004110a84 __cxx_atomic_store
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5
#2 0x0000000004110a84 store
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10
#3 0x0000000004110a84 RunSignalHandlers
/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16
#4 0x00000000040b4f08 HandleCrash
/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76:5
#5 0x00000000040b4f08 CrashRecoverySignalHandler
/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:389=
:51
#6 0x00000000452bad80 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
c++: error: clang frontend command failed with exit code 139 (use -v to see
invocation)
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a303)
Target: aarch64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.cpp
c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.sh
c++: note: diagnostic msg:

********************
*** Error code 139

Stop.
make[6]: stopped in /usr/src/lib/googletest/gtest
*** Error code 1

Stop.
make[5]: stopped in /usr/src/lib/googletest
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

I can't attach "c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.cpp" becau=
se
of file too large(7138KB).
//

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Mar  3 07:58:50 2022
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 2301619EA6CC
	for ; Thu,  3 Mar 2022 07:59:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K8Nfd5YTMz3vgl
	for ; Thu,  3 Mar 2022 07:59:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646294338; bh=18btC2ljTLYfbfG6wMpYpVNEYWUbiWjQNY/5dlz7mos=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p7rI/bdvNgtvErEi4EBFcvOPl5b407HHBjKoGjMOVBONNDfTcXbDPm1KWp56A4GUChUrBJIcQyOjgp6/HWISllR/rrBqCSEFO4z70mqO5WGfQ5h8N4yVVmOebK/pZrRhq4osNEUQjq6TY56hYIwdUIT8Mlx1HrJnVawl2/Ez2ciqYrouHIhVc9DtNkU42/DhoRAep+5co3oyref7HpcZ1v1/jcRk4HA98gCmt/Ps90LaDvauKgEaaeoIJKYKS5Z+rPfDGyNQSV+gy+NyJApHs4s0Z2H6ZGNRawA6l6wHGYpMxGmuaxlqjTQ5pDRMBBNLMQDCSwDPYnv81Tsms1eGjw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646294338; bh=jm9l+3vTuvJP+bWNj4en+rPZYKALJnAPl3cX+cxLSx7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pggFQTfP6f8FmSIrHBd3EllaDk47zU7ehnvUhkkAfZnRfAJ/pPN253bgSsIzGUvijsH0Wic7nEd6hGaHnZZiIp69BsW1F05dxOpERzJmY9hrd1oNb8pelt7kMM8Zuz+bgj7F5/TYdhLrJf2Jta3ZjMkOKM39JSwC6HoU77HJy0Yg+HlXu53betBRIEZZxmzINTL4ybIoh2RN5OqhqkjdJv5FmXLuWKKkbQhDA3TZrnx1k2EZvIZWJv7Amamidu2L5VwTdssp6IpRCA2Fdu1UwUWWFp71sBMcphkpXq6A1MNCcOiKXwDq4aIENAhZTUSRTUIN27425wfJXkPNwXJCAA==
X-YMail-OSG: mtkcVToVM1lWF82vUKFZsNB2a3fPT6ZQxpE3y8SlTmNLibY7TCHkGO7WlXKzbRu
 ywKQDQdQU4EROz540HMkmRkn1cod74JC_k9ZL7Ewd1YOy7KA4PCOgevndw.6cZg21JyhA_hYwCBB
 v81_u7ByyNhSBrJF3QUfEUguutKbOhIfZaY1dYVvvw8o9xCYpBHKeHffkr0W42Qgxx4d4kH_LQus
 S2UTCYXvUBUXpSIAg0XlcXtSRZs3c62DTTkrNmDjr5tKsI2I35sTAMLo0wLlKCzTmCwyYQihyvYd
 __0bImEmnx0Z9Ubo8BhA2V63SJaO_annFYiY38EjXYlytqzCPONPIt1Y9e.Mp7oKgqj4esrqJZFm
 T.3ge0Kmf.BPDSjqYwBfvAYTKS3O2Eklc5KL53QOsiDtAjHwM7iEqgm9ZIfXNCWh951FYIVdnjAu
 B4GV5.NLktK1T8bIktxbfT8e.ZoW.zPzQtoZVNnQI_L1nttZxgHDnRs4WLHs76zc2dg5WvTqLmCa
 tgMtEDeIWXfFjeeyZBsZYJl.R47TXwNLl0lFifqRMpOVe.yiZCzq0Xv7ywueo_Bbgdv8YvOFB_CQ
 IJCRyaFTFXIKh..8SubGFeIAEOKNcSF6s2HhELGXx68HB1oL9t4pAPBWUSNE_1YuIky5D_T7Q2Rk
 h0ncDaVQZNwb07aqI.f_izzCJB.yXD_g.QbylVZzl_KIuR1rmzKgBClVByCY9qHUl0LeIPtQxJkA
 B7KL0595z2PwkpM0Zdkhvth_7Ao.8XOENdGlEzfkLfnOo2tB4qBzkxUEIkVd.Bpq_x2zEld43Gp_
 kiMVbNbGIJkKKGtW0Np151vaqOsNrioh1vyvrw6gwtgbb17EOtDWv3pXrmjQBRdbTsXkzzCi382m
 bcvTX8fkBnS9qSgvX.IZ_4fJiWEdICY8m2nfNtcSZBXwsNdSM1dCIlVV5.XR93jiLfMKa6K359Pg
 sbJGyne0OMql0i03Gj_HYq92QKI_7L8mIu8h2xj1dhl0X7vxTcSP0BETQGWbs3ZJVKiDzdIz4Twy
 oS2wDM3KYXGp4djlJRtV7m9G250cpQbu1saIC3u5D6l7u5ug4AGcvsQ5.YnGjNtSatIb41KxlK_s
 hXxJK.jDCGKuBeMRHLDvir_eDGvIS9PtjN0nE5f4Xyv7diIS_qXKJEjatLAFMEvWYB_qy8FmOdD.
 A1b3EpP3DVCIXQ7JjlWb2w1oMNH5.mVqgoGkyceqEXpbArPvd_aPZaGUcVTYsU.FfUJtgil3NjJa
 ahJ7r0t5Tl57FWzhHoVqXF6AAK3Gs5iTv4Akd9kx4XO7EOyibTLXH404NoBjBhAgLUKOLb5k_HLl
 B0ABUW7bK.JxUFYMN7dW05tmU_3Vbksh6CZBQsKOgXPetPwFAaukUhLPmLWvSV.X5U6hLROFtDnN
 7LE6.gXstj5L6Why.DHFxfN1HxXlkUFyU.O8Wt.lp.SRApZIW9qASJ9bsgMGbE.3SwW4O1zbDfiX
 SIT1m9kFoo__6jgYsDBrKUgG204aKl6wZ7FYaszw86k5osvosLRLmIdjOeQ14NdiaJh5zkUdG.ve
 FbODrnQG8p1_5Hl84TCwZe4gxB7LN41OVkIN4l3N5BsnrT1LxF_7yWTXe_NEXdoWtdX_iJLKhmKZ
 DeEcES3r57s_rapXThq9upPlHkdtlC_wXvEcWL0ex7JUxTRvWM6ZWCld0OO4WrIBqG2H1F3z5GrO
 arHGMC9nfPEwJ4VBy9IH4tDC6Ffa8aGhfIo_KWbh0sXBRJO505FkX8bCphVpKVC0_dgajO2OzfsV
 71t8Wz.Q0w.e_xJ2ytFMAxrf5zYpBQ0cbml.67q_NEMIQugbGH_Mh_EvLmksbOlqalMA5OmJeiMf
 vQTH4lsP9OTIwThA8TaAuv43XTBLSbxyEZ1loWRQTwJ8FsmTYltNTnbfT_kf_mmTwAeKF.G2t.rQ
 SRYMfDspf91qbBB0ILN3ADtPWoKySvKHB7EuShdPH2emRTg3uDZXazFLFt4TjYhI7FPM_u1z96Mb
 q1QcTH_e8TwXjH0HSrRkrp6.2VMKI7FhxaF.sdD2wbbAe_ztnVUa9GcDlbmPAalrvPr8m5zYltap
 VZR4NLp3AsszAreg7HBhWCiDOwa9S0frhAV3P0kWQRqYcVWDemRGOvsI2dA2u62DUXGys05I3MLS
 a6oF0LjLLkjgGMmIu_2VMARq4RqHChDwU_fSOctZWApUCXGrV.1PccTmpQWo.rUR3XhrrbXthk3M
 9kyftyEMkTsF_UCf7F0eCxAv8YgZQSAZAO04eO2bcEujte.chPB0PENg0eFSXAqqGaGIJTCiJVEV
 vfPPOKCjIZONvNVHCTt7FDeHoVuo_lWcpzeVgyHrLc2z5mLKyuShWNw13ZGvqbHrjEO6qozPT4J8
 M6mHaXQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Mar 2022 07:58:58 +0000
Received: by kubenode500.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 96c85e041d78a9a50e48a50209d19420;
          Thu, 03 Mar 2022 07:58: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 14.0 \(3654.120.0.1.13\))
Subject: Re: [Bug 262310] c++: error: clang frontend command failed with exit
 code 139 [failure during gtest-all.cc compile, 13.1-PRERELEASE context]
From: Mark Millard 
In-Reply-To: 
Date: Wed, 2 Mar 2022 23:58:50 -0800
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K8Nfd5YTMz3vgl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="p7rI/bdv";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.45 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.95)[-0.953];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5463
Lines: 170

On 2022-Mar-2, at 20:39, bugzilla-noreply@freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262310
>=20
>            Bug ID: 262310
>           Summary: c++: error: clang frontend command failed with exit
>                    code 139
>           Product: Base System
>           Version: 13.0-STABLE
>          Hardware: arm64
>                OS: Any
>            Status: New
>          Severity: Affects Some People
>          Priority: ---
>         Component: arm
>          Assignee: freebsd-arm@FreeBSD.org
>          Reporter: wisdom@isogo.dyndns.org
> Attachment #232218 text/plain
>         mime type:
>=20
> Created attachment 232218
>  --> =
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232218&action=3Dedit=

> c++: note: diagnostic msg
>=20
> I've tried to build world several times.  However all trials failed on =
same
> place with same error (clang frontend crashed).  Following is a part =
of the
> console log.
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D
> $ uname -a
> FreeBSD raspi.isogo.dyndns.org 13.1-PRERELEASE FreeBSD 13.1-PRERELEASE =
#14
> stable/13-11045f1b7: Mon Feb 28 12:09:56 JST 2022   =20
> root@raspi.isogo.dyndns.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
 arm64
> $ cd /usr/src; sudo make buildworld
> ...
> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and =
include the
> crash backtrace, preprocessed source, and associated run script.
> Stack dump:
> 0.      Program arguments: c++ -target aarch64-unknown-freebsd13.0
> --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -g =
-MD
> -MF.depend.gtest-all.o -MTgtest-all.o -Wno-format-zero-length
> -fstack-protector-strong -Wsystem-headers -Werror -Wall =
-Wno-format-y2k -W
> -Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wcast-qual =
-Wwrite-strings
> -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts
> -Wredundant-decls -Wmissing-variable-declarations -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=3Dunused-but-set-variable -Qunused-arguments
> -I/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private
> -I/usr/src/contrib/googletest/googletest/include
> -I/usr/src/contrib/googletest/googletest -g -std=3Dc++11
> -Wno-deprecated-declarations -Wno-deprecated-copy =
-Wno-c++11-extensions -c
> /usr/src/contrib/googletest/googletest/src/gtest-all.cc -o gtest-all.o
> 1.    =20
> =
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes=
t-type-util.h:960:37:
> current parser token '{'
> 2.    =20
> =
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/private/gtest/internal/gtes=
t-type-util.h:58:1:
> parsing namespace 'testing'
> #0 0x0000000004112640 PrintStackTrace
> /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
> #1 0x0000000004110a84 __cxx_atomic_store
> /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:996:5
> #2 0x0000000004110a84 store
> /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/c++/v1/atomic:1617:10
> #3 0x0000000004110a84 RunSignalHandlers
> /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:99:16
> #4 0x00000000040b4f08 HandleCrash
> =
/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:76=
:5
> #5 0x00000000040b4f08 CrashRecoverySignalHandler
> =
/usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:38=
9:51
> #6 0x00000000452bad80 handle_signal =
/usr/src/lib/libthr/thread/thr_sig.c:0:3
> c++: error: clang frontend command failed with exit code 139 (use -v =
to see
> invocation)
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git
> llvmorg-13.0.0-0-gd7b669b3a303)
> Target: aarch64-unknown-freebsd13.0
> Thread model: posix
> InstalledDir: /usr/bin
> c++: note: diagnostic msg:
> ********************
>=20
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.cpp
> c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.sh
> c++: note: diagnostic msg:
>=20
> ********************
> *** Error code 139
>=20
> Stop.
> make[6]: stopped in /usr/src/lib/googletest/gtest
> *** Error code 1
>=20
> Stop.
> make[5]: stopped in /usr/src/lib/googletest
> *** Error code 1
>=20
> Stop.
> make[4]: stopped in /usr/src/lib
> *** Error code 1
>=20
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make: stopped in /usr/src
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>=20
> I can't attach "c++: note: diagnostic msg: /tmp/gtest-all-f81d5b.cpp" =
because
> of file too large(7138KB).
> //
>=20
> --=20
> You are receiving this mail because:
> You are the assignee for the bug.

Well, someone has independently replicated
"Troubles building world on stable/13" but
in 13.1-PRERELEASE vintage context.

For reference for "Troubles building world on stable/13",
its start on the lists was at:

https://lists.freebsd.org/archives/freebsd-arm/2022-January/000857.html

Also the only possibly useful evidence I got before
giving up analyzing the failure mode was as noted in:

https://lists.freebsd.org/archives/freebsd-arm/2022-February/000979.html


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Mar  4 21:48:36 2022
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 3B60D1A07EE9
	for ; Fri,  4 Mar 2022 21:48:31 +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 4K9M1B2xjvz3h8G
	for ; Fri,  4 Mar 2022 21:48:30 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 224Lma0b021437
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 4 Mar 2022 13:48:37 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 224LmaAW021436;
	Fri, 4 Mar 2022 13:48:36 -0800 (PST)
	(envelope-from fbsd)
Date: Fri, 4 Mar 2022 13:48:36 -0800
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Panic while making buildlernel on RPi3
Message-ID: <20220304214836.GA21411@www.zefox.net>
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-Rspamd-Queue-Id: 4K9M1B2xjvz3h8G
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 541
Lines: 15

For the first time a panic has occurred while making buildkernel
on an RPi3. The same machine successfully ran stress2's misc/all.sh
test suite for a couple of days, so I'm surprised. Granted, that was
a few updates ago and this is on -current, but still..... buildkernel
is not the trigger expected.

The backtrace and build logs are at 
http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
but unfortunately I didn't anticipate trouble and so didn't
capture very much.

Hope this is of some interest, thanks for reading.

bob prohaska


From nobody Sat Mar  5 01:29:35 2022
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 C09D219EA48D
	for ; Sat,  5 Mar 2022 01:29:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K9RwX343qz4bX6
	for ; Sat,  5 Mar 2022 01:29:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646443780; bh=fr59qndRR3KKHow41ZvZTpgGrqmDGrS+BY9qYKZW85s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lTpihzcDt/Q1+zv7NJgjZsuFREJxVRxVYK5we84w3+fB7VERcSwbgDhIK42nCTi1GFUUgTbR8OA4xl/2n5qRNeAesy0SBOGTYlLnP8I6E796E8tMh+/WAFmEneTMP3t2pzK56vRZOuAANlX1cUJM9YXe68cSD2B5ZgrYV8tMLSjn9At6tQBgOMTbrOVU9NQYXdCuZ19CQUByGl/zyBekRrunR8hKih0GFOZgrm4cEqZIS6itDAjsYbfV4sawdnyfaxuGMNC7HN0DDzJw49Wc/CE8eBpA04jvSShssVNAcetegABGG/2YxRLG0XBkQWmV4Zn0EUx/I5kXU6myh+F+vQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646443780; bh=68b6m1jekHih9pxdr2v0odZmwoW+fAYJNra+U9L2bV6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PsqqGONO+14cxY9baCDbv4mC0Nf9CQ51AK5VJNdApaeRHZALqPlxxFzt0GE8CP8sePtv8w/wGL0ca5jD+j/H3ERUWNKK9WTNscNXLQp0LSNVZDy09CHHcv3sTf/ZPLOYko29tV053y1saGvlLpNfFDcb+6x8JvVQdlcq+yqRXvhyDr1hVTsINVtYWLUztNubI0NhvcHxcaHYNtjhMJQkTatgFDKkV45elyO7A5/QMmGifIE9+VSjTi2pwzHOvZZQtJL4YxidJJI9Ot6Go8lDodkxW9WScxgKfSPWpbJMZ5zW+Q9DzuxgaNx0xcpeWSM08Co66Q156xFUlTr2zYafgA==
X-YMail-OSG: WJKlzZ0VM1lIBXmHQhSbgPjvODc5oeDv5KpsobGHvNtJqa95zE6MVFvWWYz70aH
 Q5NUJ89ftO3prfEhS9BKDKn.6m17V1uxdzXV0rxWjh68eF1jxy4_UKZR5hFu1VfcCGdAXkDSXQa1
 0E5I7Eyw8C2Rco6AY24wjsGacazsWg0d8xKsnb6lL7gjig7GVBD1Uy1XHegDo_R1.fdg5y_OT705
 t869mRWRe78rc0JvqNek5owSw05l22pqQk0oQ1zYKMy7GNHqbtXgw0zyQpa4aD1THKuk0P4u3cUS
 aOz1q8n15FfiZV6RGpgmnkZN0axbyVVs65C1PxuHWZy.RKdoUJplDy43atoSakHZbUEnAWYN5pEL
 9WLdmlk9j18vRCooobmyuCXjiuQ9n5Gn23.xCCrog2H_aM3AoNmtRA9_rGcM_oJ5Fige3E6xZUsU
 A4zAqOlubH1nyeFDMD1eVJ2YPP.MZCy06lJ7sDx5u3eUJsMg0nidVIbGtY42hs0jIglYibddpXGt
 Kxzdy4twpQS.JMMsGetgVIo1RYn7O5gFNOL_ziYK2_Cjp8co232wqfZakQ2kd0qN2yG.bp6.8Hni
 N7s_xSOPef.EwMmKX5fY0CJ6KzpG.kl.eEu6_xt6m5Zj_yToRPQEA4FuIp5GD79x3iy1fXw33neJ
 pvMWmwQ08JrhvTncTAbdS8ZZ7Q0Zwx8iqAqKqaW3QgW7OMreCBPexJxMFf4HaLVYEY4kBeVBcGy_
 04ctl5GZaDfPmu9K_lJo12YnZmBeeoF116iQK9Q8R.7SFCefmAI4bCvtphpyxm7TIdxdORTZMC1U
 ckO5GSB6j8MEg6uhaOcQEM88K4p7qhU.F.gP07tV2n0au6YBxeDlrfvk75DqLjJhwYxJMDBrqUit
 wrwDdVWbXfa8ZFafeyr55ObN12ByB7_n4hCq85nZl58SjtkWidoVC.uHmhB0BHM9uRxwASvcc9qn
 UwGbiHreoLQAiIZPnQ5tnSmHfsvzhw9zormchsGtOODdzBWiaJKcZ5GvILIVcfLFDz9vNVn0WOk1
 lLVQfi7xERyyndAjvk1y91EZfemSEYj7QNVqdPG9jwFD9O6SeR7xjQjHduw11RlIVKA_SJB7LNjc
 dwH2_CsD_I_hiFXibhbRyGOdDluGjzkTs2p_TriUg5Y1QMhCz0lXIRxd3ViXHQzB4W92.en5SONy
 tgpFYigeQZHOE.StRfod1YrnTTGBSrHNBAuzoVFSmuXE_iqzC6Acsn5CoGnbCAYnppARY_y83QsM
 2gaRKKwbR0vvnbK5sFQgaE4xX8pXXnpJag_eRQamIJa.k4LLwqpKNKEbFXj2BFnuL3l0lz3F2TVr
 S1JdRwrIRPQQOeA4llYTVjK.1w55VlugOA11_h7MdahAUe.cy4PxPgiID988LS.mo_nfqUVQcqOb
 N_U9_iVW7KdyTmcjvXm13gmsn51iwMNLYolCqFVAxjmUtFou0juWnS2ydDyQm_Y7bDsNojxtRGVr
 _2.2aiWnXWas9PwP0T9mxWrNK1YbIUdJqDP2fB965VTY8in9kPyVX92ECtd1AQQsaMI4RQAEWwq2
 u_TSrwO8ObEFsuevgjeImWVl_7Ks92IIrsdoEm6VIrMY8oKuS.LvgNsw0pV1_FQJOkTSa_l4ZTLC
 GCcMSxHVTsqjBWKtkfsMkP5FNcIaH2._toyOUvLbiS7fvCVFfnmxEnD3d6eCJhsg9bGqHDSlVIbg
 4FFI8ViExCiOQQgOCs7F7RHbESROecp3sP2An8dBrNzPNWUuY7mXpjQqLU9AHZvb7Dt8py.E.OlK
 lGs.lH2hSIEtb942Nl_FUwWSzmIYfjngjamtLkEFf8gTnLFoJlFvw.ZfDhmHekKpwl86oebzyiVu
 foa03t2fksmDnXZUII5UXqHE0.OG7OiXNYRFpCyBUXFaS5vDMM2KYMVnz1rGbcl.1a49LSSIwZ1G
 4271QJB3Cjq.rCduDy6oPL2zYe67niCUn1TkEzw3ubuQr4C5NEu5a7vnNl76OnDcUR8ZXH73NAzq
 tb4aQCEQ78CAgjk5HRbLOSOMvyPMt._MrDYyHb6PzWnv9xp2rualwt5BjedKQndJLqimoI928gTs
 QqP5JG22KkA7._g8tY3VY.mi577DDRNiSIPJPMJR2kJI0OHSU5YyVwo_V6Z75xnSPfO4CliMsdL8
 T6UPaO7iqyaxAMqrt65i_VhFxFCZYIasScrW5n2pf2cT_tULv55ad1IN7DrGH6PZLz5MDWup9lHp
 nm65KpNUJ1MbujP12BKHSpW4z71QEgucYdRlrAZEok7UD1xm7e_dfADy.AyXUmje5QTZKzFVz8gm
 z3mYUztSUWHA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 01:29:40 +0000
Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7e9db7bfe1f82681679fb9b3fe659c83;
          Sat, 05 Mar 2022 01:29:37 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Panic while making buildlernel on RPi3
From: Mark Millard 
In-Reply-To: <20220304214836.GA21411@www.zefox.net>
Date: Fri, 4 Mar 2022 17:29:35 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220304214836.GA21411@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K9RwX343qz4bX6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lTpihzcD;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1551
Lines: 57

On 2022-Mar-4, at 13:48, bob prohaska  wrote:

> For the first time a panic has occurred while making buildkernel
> on an RPi3. The same machine successfully ran stress2's misc/all.sh
> test suite for a couple of days, so I'm surprised. Granted, that was
> a few updates ago and this is on -current, but still..... buildkernel
> is not the trigger expected.
>=20
> The backtrace and build logs

Unfortunately, the crash means that the buffers were not
flushed to media when the problem occurred. The build log
is incomplete compared to what actually built and where
it actually stopped.

So I'm not sure how you got:

--- ng_pppoe.kld ---
ld: error: no input files
*** [ng_pppoe.kld] Error code 1

When I looked at the buildkernel.log file provided,
it stopped without such:

--- all_subdir_netgraph ---
Building =
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC/modules/usr/src/sys/modules/net=
graph/pptpgre/ng_pptpgre.o

It had no more.


With the then-running kernel file and its .debug file in
place, it would be possible to dump the instructions
in _rm_rlock_debug(), sysctl_root_handler_locked(),
sysctl_root(), and so on. Someone might then be able to
associate the code around:

_rm_rlock_debug+0x8c
sysctl_root_handler_locked+0x140
sysctl_root+0x1ac
userland_sysctl+0x140

with whatever corresponds in the source code.

> are at=20
> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
> but unfortunately I didn't anticipate trouble and so didn't
> capture very much.
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Mar  5 01:36:20 2022
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 5B1C919EB5E9
	for ; Sat,  5 Mar 2022 01:36:37 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K9S4N1ctKz4cJZ
	for ; Sat,  5 Mar 2022 01:36:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646444188; bh=bnGeP4yEEVrVbY3Ut/SPyG79mwEUJBcax6WQrB3EjxE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=c87+bJ/m37GzwUoo9vbk8PK719V2N9LBFwkJiy+xtbRM1kvbrQKeeDEOtSXSyyPTiFRgqJW7QkL75Hz1YJDPVKYq0J62e0t0uHqUJiHFUL/+RF2LRGLqpW7h0rKQtSqAx3CyHIzqniOI+bqXjvWPAvUW/3YNP5trbHcvuGb3vVexhQTjC43aCSDqTdEy/PGMxXbn/pLgPGJLFcEUqMl3cc/d3gwGhZ/1zUZJhqkoz365sBU1gCfUtnv0IuFlhkpmcBLhHXcGXnoXF8NHHgOM/9bfMx2VRZLRnroBXgeV/z7MEz00YJfd35zwNA56cpptWoO/AmOO0o2mdE78q73P5Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646444188; bh=+HYEuZNhp9H+VslftSe09MTgVm+zYDHq7MQmv46O2tk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=C0Jo6TlF9Fm1zdtvOcMNtjopdT+CbgQiCZH9q8iTcnxu2XAd1GkmY/RLeDCVZso5F91GpY7nIoafuxPHjDh4P3aj97uj3/PfpnghX9glVVkhT0SevMZ0lQxath1jGB2mb0+4S2eUQECG2xbqxBdTEw/L53gdloq/kvS1Cq4FENdvK7rQ2NxDVr/GvfKFCfdeOmRxQasSFFZ4/lj28lF1zMvvPb5kwryoVa1pZ6vA5R5Ec7pDYSRj60G7IKjUMKVZeyZ1VF5ucdFsSZ0EpV3oHPv00anLK7JVKmdmPDT+eYjrErRpZDI6dDNmLkXomGOQOuapu8yxtk+AJ+oLm98KRg==
X-YMail-OSG: qFveHwgVM1mRt0Du2R83fFuXG8Sjb8XzEjQZ5CycXviWvMhGnTB5_1XDuKFWwvL
 GLc78VxkPnycjYn7dTdt2U6lCFj1UM5ho7_psaM.1Rej4dq5c9ZBfqEqtpHHbsSDJyGSZ0rOivJz
 yErBYNz_cQcfw0Ibk9R_P57B793GH.wCIJliVog3tDcDA_vqJzB9_.tRXiX_A3xHZsNHqHOmwn0S
 lJcO2wP3ixhCPFuwegt1bEfv1FsUbJBiV.laKJL8G4w2RCxlc3CGBS.wCAUYDUUsgb6o7jbo0sB_
 OUIdgrZMbjzCoIEKJQgFRK2pWNaBr_HOQ78i08IrNQWMBJ3i.N_XE8ru4C0_Q5rdbTFB5gNN_skn
 Da90Gh0EpnOwOWxRm4DOYnAudTqeXo9XnoSgDetpGXpSHAmjEj8vdWNZ_CbmljMaTi7ppiMouWa5
 GqqkxMSLkImuAVfNCtX0XKoMoy_tK94_dRwpBZLsBfNzVr5uc8NtUvJGcq1I4DLcxxA9JrPKnOQu
 J4z7CNoywlHs.fuqa99VfxEttiB0fsjNB6ALXZOq5paT9yqNs2ROBQs4KR7cOBQo6PID1GwZmgc8
 _olA16MYpA1AZteyJ7am5J0ExWK9_4G8n8tZNTTthwqsg7nRrE3Bwxv6o4DdE.8LxQe0VXILhlmc
 B0.qp1BusP0LocFfaEdYZ17AH8UE4CKOm5dTorETdniz_dgxUnhf7tIxeuNytfhPZ.UX7AgWmIbs
 ..Dk0gQSwzNWR0qCegbmJMiP2oSzkMYW.n4EjtYzX9JgIMYjGyEf8KlyQ9decNp_tFwNJ5wwyt0h
 UaauBcZCyrlcbvXOMWbK8fZkWqLf8RBcWPFRANWf7ZxziqSXZm6U9f9EDxVx_QdwJOM90yBREfR1
 eUGApX3caassAvtyHvhdt2iG5fvHMkT0B2.J2VOMfT4W7ujKwu9KqkXoqCl5mSLmkme6O3SuDbq7
 cLYK_B0dhihacN6eZ9uw0wf72LiBHIaVrbu2dWFg02ktx5FXwXz6qDI0bBqJJA7u_i74I_tqDkOw
 j9OPpD3m9PJcJBZkJgjsmPpRl7DFzj3XHaK2ODtih0_LsCDSfzzI2nO97_HIgd0NTRjnfphUvlrM
 ZvohOir9aFn2phuhlBz_YckacxqS9kz0.AHch6duWZ99Tvm3eOsImtX5detO9vEPFAT9ivz0cDjv
 DNgOhsd2hbZkz7uoYCeYGjtbwsoS93rdokRfgLi9oDNAEglX7dg.0cu9ITepdeAX_i11QpeP95xz
 nrBHt_xY1TYwPeHUZFYhSafy_wcwC8zXwniGZUczAcNMY7Jt1kjCjRyj8HOLfV3htgwcUiknXt_M
 Uuq79_CXsVYphfV8ZoRgjzKDED1KMDdmZ._GvnhmXHhtBEXPxMxGf5QLanj3V5uA1y8315cbi97B
 .U0dK5r6s2kMv6.P.W5.Xem8QUvG3zpt5w.yFgER.JDzShO_1gpCY5qxJilkU2FVT9mMhotp5rGj
 adGTwCOyIRkGRWjyxiJe.pZqAQpPaGpFm4dfMQna37OdGL9_re04z2G3AHa914mmkWlnrKwJsCdt
 Ddfc05FZ5pWxp070SS4EfwuUdbgodAeznOnYCvxM9l9Sma.crR0_EMmqpmudL02mWeKVKVOWFIGw
 FKxiuBaV1ubq1VZGCtkZeZ2PK7EX5BULN5sLnZuDGVWWsd8u.vD4CacwsLsuRz81EaTafaGkcTfm
 TjD5QUlmPzFOHWn.pw0h_68urqQqQkxOLz8R6W1f6dkYEOF191U3n7Znd5DR62WEbMvlPAsyrOwQ
 g1IeAfojtYtFAaXvwPa8PZLdGbMNPLFb4TZ4QRja3n_4cjhx5inmsWAOm4TTG1oZ_xYjoh4bUzIP
 K4NV0zX4E_A_40H8oaCiPeIVlmTvuiwmEIm4K64nTiSw0kqGSj.xFmTWQ4JyTP2ApDnoHqaiwuTz
 dfjnLoGnaA5cX6.IjbdhyhpqMG8VHu.0r3mDeq5Mcoq5IN.OTdM0vUr6smbRYHuuXItnEbEXBb3S
 R.jt2fvQ0Dxw1wtXU2y2NlBdoSqkvPuEChp_YLhiFuQtd7NCggf6feYLU1vUcve2IhcXpSHLUT7y
 G6PG.ZfU5ANRbTveeQgLOAbjEsUVmw5VNsaXdT4cwUuXQYkAk9lcugqcwGtS3Vm2gXk48p1uM1X0
 YFOrp4cIeLW_cSRmnAKE0xJbUYiBUMyscETt8J1mvTV6RwJUFnCImaZVExUPZfU4kHYYS6W3cMMn
 6oKbWY5Wqjm2lYqvhpnbm.e15eYOXdsu0DEaU_1hKXrhLQH9sXdMiJ4N_QLpMXmkrpnhb8pAEkud
 9W5Zn35gEtvFK
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 01:36:28 +0000
Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 33398913b05d5dbe0f290851f6eea3a7;
          Sat, 05 Mar 2022 01:36: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Panic while making buildlernel on RPi3
From: Mark Millard 
In-Reply-To: 
Date: Fri, 4 Mar 2022 17:36:20 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
References: <20220304214836.GA21411@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K9S4N1ctKz4cJZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="c87+bJ/m";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.23 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.73)[-0.734];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1848
Lines: 67



On 2022-Mar-4, at 17:29, Mark Millard  wrote:

> On 2022-Mar-4, at 13:48, bob prohaska  wrote:
>=20
>> For the first time a panic has occurred while making buildkernel
>> on an RPi3. The same machine successfully ran stress2's misc/all.sh
>> test suite for a couple of days, so I'm surprised. Granted, that was
>> a few updates ago and this is on -current, but still..... buildkernel
>> is not the trigger expected.
>>=20
>> The backtrace and build logs
>=20
> Unfortunately, the crash means that the buffers were not
> flushed to media when the problem occurred. The build log
> is incomplete compared to what actually built and where
> it actually stopped.
>=20
> So I'm not sure how you got:
>=20
> --- ng_pppoe.kld ---
> ld: error: no input files
> *** [ng_pppoe.kld] Error code 1

Poorly worded on my part. I mean that I'm not sure how
you would know it was "in the same place" when you
re-ran.

> When I looked at the buildkernel.log file provided,
> it stopped without such:
>=20
> --- all_subdir_netgraph ---
> Building =
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC/modules/usr/src/sys/modules/net=
graph/pptpgre/ng_pptpgre.o
>=20
> It had no more.
>=20
>=20
> With the then-running kernel file and its .debug file in
> place, it would be possible to dump the instructions
> in _rm_rlock_debug(), sysctl_root_handler_locked(),
> sysctl_root(), and so on. Someone might then be able to
> associate the code around:
>=20
> _rm_rlock_debug+0x8c
> sysctl_root_handler_locked+0x140
> sysctl_root+0x1ac
> userland_sysctl+0x140
>=20
> with whatever corresponds in the source code.
>=20
>> are at=20
>> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
>> but unfortunately I didn't anticipate trouble and so didn't
>> capture very much.
>>=20
>=20
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Mar  5 04:30:02 2022
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 F2B2419E136E
	for ; Sat,  5 Mar 2022 04:29:51 +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 4K9WwH08Jhz4wQs
	for ; Sat,  5 Mar 2022 04:29:50 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2254U2Xv022233
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 4 Mar 2022 20:30:03 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2254U2fh022232;
	Fri, 4 Mar 2022 20:30:02 -0800 (PST)
	(envelope-from fbsd)
Date: Fri, 4 Mar 2022 20:30:02 -0800
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: Panic while making buildlernel on RPi3
Message-ID: <20220305043002.GB21411@www.zefox.net>
References: <20220304214836.GA21411@www.zefox.net>
 
 <29044F99-661A-4C75-9493-28857DAB963F@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: <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
X-Rspamd-Queue-Id: 4K9WwH08Jhz4wQs
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1714
Lines: 47

On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
> 
> 
> > 
> > Unfortunately, the crash means that the buffers were not
> > flushed to media when the problem occurred. The build log
> > is incomplete compared to what actually built and where
> > it actually stopped.
> > 
> > So I'm not sure how you got:
> > 
> > --- ng_pppoe.kld ---
> > ld: error: no input files
> > *** [ng_pppoe.kld] Error code 1
> 
> Poorly worded on my part. I mean that I'm not sure how
> you would know it was "in the same place" when you
> re-ran.
> 
> > When I looked at the buildkernel.log file provided,
> > it stopped without such:
> > 
> > --- all_subdir_netgraph ---
> > Building /usr/obj/usr/src/arm64.aarch64/sys/GENERIC/modules/usr/src/sys/modules/netgraph/pptpgre/ng_pptpgre.o
> > 

Apologies for the ambiguity!

After the panic I simply re-ran the original buildkernel command, which furnished the
added output and then stopped in _roughly_ the same place. It didn't panic, and maybe
the panic was unrelated to the error. I've tried hard to _make_ the machine panic,
using stress2, and failed. 

Perhaps more curious, I subsequently ran a make -j4 buildkernel with no
extra options and it completed successfully. It's rebooted now and seems
to work no worse than lately. It still displays the strange ping behavior,
answering a few percent of incoming pings  unless an outbound ping is running. 
Then it answers maybe half of pings. That seems to allow enough network access
to permit ssh and git to function, with a sort of stutter. 
 
I've been using -DWITH_META_MODE as a default setting for buildworld and 
buildkernel. Might this be part of my  problems with the Pi3's ? 

Thanks for reading!

bob prohaska


From nobody Sat Mar  5 06:51:00 2022
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 949CB19F9FF2
	for ; Sat,  5 Mar 2022 06:51:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K9b3R16gJz594N
	for ; Sat,  5 Mar 2022 06:51:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646463066; bh=7SaGmlrNry0RNzfMZEFxqWH57ppR3UeKK50ryCRCSRA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=r4spSiQFEpa6+YI+CaTyQZ1xIOEkS0izsMt9F7jrTIAwExRq9/jBazd1ta0g+B3DZHHx5sPEYJpUXX8L0nKxYKxb9ZR0/C6LJGUKHOCgQA2qcgLcJiNA66ubpzlstmegQY0+pQvtqW+cDFexgG5hgaCKXZerdxV64CeFbWypYRXEMgN/KFBFHzbkN5luiNYvS0oWB3DpzNkNq3eB4YsYghGLowLWTJYoXF8oEUHZ9D0I4JhpPjY1GK6ARYx2auyJxhv4xwX7fdAQizLFz2gSRgMTpWSHhXD+9q6yUpQbw2Uq4RhN153NwJ5Dce/uE214B6Nsm9lg0t31pRrBIThNHw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646463066; bh=Wq/WrD2fESCAVUENLBHZNMDaoNCu4hJtNkHx3h7NfNL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=c9D28uWKyNI74YSQAc7fBsRWWmGgopAyLilAyZWj2v4HWFscbnSC/r0fT/XY9JkIPD/v5nK9MT0wCny23OzYNd83O2odyp/M+7Y2nMbha89efHdArjzEILr+7ZWnGhujqHgiTg43CWvXbPP2TU8eoLGnO++gHSR4dgAyCAwPjsGgU1Ba6aG5g7qToTJ9izQ+RUw4mbKRYeU+PFYKQi6n//n3Hn/mjKZbNjSAhMQgenIlvhr9TqAHD5FAbBp5vW/UQHAtMNuK8ntC6endhFO988ptdGsT55p6yG0QZk6PqWkjbM8NrAMQ6Hx+GK117zBdBofYGWT/OXQzQWlM7a50Kg==
X-YMail-OSG: OkGkF0wVM1k09O6iI5gSjLR0cqIf7ydnDYqKJVxxM5_PB9APwU6O7ohh67HSaft
 TdTlJQBHhy9fhx9tW5uTMV6PKl5T9owwRGjfo.Uj2MXasi9P9ebfg6oQPWaz9hqCSaVwRYSUeumY
 1_3JP36Cro0ers.QT0do5Nrq6ydne9AUJH6OBJyardp21udv39pS_9AxzuROWLDDjd4XubQtK9PH
 tsbsKCNKLnBzDJlOQyoLXyUrYKEcdQDrsX4u456azV2KQ8honCHOvs8BeVcE_FRdgN3GvfG0_itF
 vfqMleWu7uLSbgTjCt8YT2dCz4TxPuRSYg8REuEZZgfNl7n963Tmg0zpdpGT_P5BWdtQMtdwwtri
 j8IBG2HnRHBY7IuwUZYKiPUAK745Z8CWVINb8mQEgRbx4EB.9CN_yGfNUg1Btblm7bSxC7buXwaw
 YB1KejEDaHW6tVVS5ueTluW622V_DHgGnWQwIPz7i5GZu8LNXOBsfzjcr9FE8nXDkGVS_VNoIiPc
 mJdzv7mZXqFJCkdyslNm.xfp9g5wDS2MItdyLAmnS6nhm1R3b9ztawYxz3Wa6Io26OOW_WNmITih
 .J93m.CwhpqKRuM5Fa6PePtobI49YqArON7SN_Htq16QiEpxLIh2696xFdqEPCUfOIsjQoHu6plY
 Xm7k7YEclBr.gqtNn__iD4x2jMMZ3MS78T7Kx3dtsUMU.RWdb3cmHpuL4SLZZEahVIYWnMbnx9hw
 LM_AsZ6Lmh7fIimawDwtKZiA78DVmx_MEcNma9Y637mr73o5x_rqnnFJq7XCcyrvzw1c5A7b_aNk
 fIldHmndjYLpNFy35qGA278oeSM1shoPOVdr8RdwWkaHEr83klhBXsD6GMokYrrD68XYnBDz5UdQ
 RHlVuwfQCak9iH0fRESQ4.sob11o16gWc8KLO8dUXyQ2bvQK.6DgMRXpNIqkBikZpuBJRv_DdZjU
 0EkPcIWZlqd2ozMP4A_7zhfrsQ_czwGttIG5wN1_61Jg5MW53sGr6FNdkKxx.R07BMNl1pbtTRE9
 qVJb_k4U_xygRAXxju7ty2FAku1tSISJWTUbUUdGkIb.mrdFul2J3Dn6OjoRGxKl95h_3ILnclXN
 n5VdZoOZxQFaC8hodJlJYzc81SgXNqTm0uOQrR6kusJSt5z5mVihMFvowwvZK1VPFitf5neY7OaD
 9Jeg1l5oUW6rea3St5Os25FPDd1rQOnErCpckVClF6h98t1LiJkiRLC5_JZs55VgIpnX.fiE67Ge
 yz_G3pMuWTJJGG.IzyQioxg3Fmwbz9hZJ0JN5NLoJ5mOjysA7Du83XfF9Vk9z0rfUXgTEOgvsX.1
 QipBz42oYliZBRwEQj8zJE5qsItLNLe_g8_HKH1UteG73_hlytnDz5t4KXh4sP.10ASEQgtlG3V.
 Tu88BPRmn47dLpo20sR6YJK9kauxTKa4uyyddU4cfYK.HJjvvHAr9IZvm_cgSd3AJcXf0u5t.4xu
 qmXnRpZPrX5MjfrouVw9jG9NehtqgbY4EyThSSO.1YUmSGASaAIWoGehGn2T.lZV10gZiJZwEEqg
 ymZ_C1UXUYG2WRZjxGiXTItAJ2OjUQhdJfOj1CX5BH4vnl4BR304Ik.iGs0yAdCm2A56hLClWj_o
 QRAMuNy2wlO.7sQf4p43aTHrwN1qKTIsE7nqsKsreEp0wlYHzT9crr05x1AP7wGa3Hi4HflWB.Z5
 mWLO6E5ZkyGPqDkUtVm_G136_MIDYqmqevowjBuKlDkfBk7mZRLMXZOaWRjs2gIdlwSEcWoUEkNb
 4CGeUDe7yCGpT3rStvmAf4PTvMTkg808kyI9x7S2DNyprticpMqmjUPJipPsR6KWysrXPC4RQwtt
 g0TWprybuWV7gyzBkviWTzrvv4RjuwgG0THb6hBSiKRq9Em0XQ1jzQUPFK4oyHbxADHNILGzOVbB
 CPTfopKlIOgHjqOfl2LGJg_yVULDmoJUh_OUyU249iPymuGz5k0FcbCe7m4sN2jQwlWMgOzLP_xX
 8F_.ONuHsVAbcMdyOR5KJv7f9LOFl2IjB67XBMt6R_1U_fB8ZRIo2RL.dtveRKEpo79cSgZHT1Wq
 Yo82Z5jIK_hytNLWnbrMS.OHQvIPPsdErYrS30HSBW9nJXMpQLs59AKF3uZeW55TYqFuJl6xB6FP
 5dtMlFFHrMa3Y2t4zVonFkT58MfkvUD.SVh8zuQnDucp9mcXWzLs5Q94hN6.RNoJu4Qmh1KUXPxX
 .odxkVR5V74gS3LisK1_EHRsOELsmJK6yzukI9PjSrQUDLSgyguGwFe7FrRcl4KSlKfjiOhqnRZi
 BkLKKu9pPNa0I
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 06:51:06 +0000
Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6ef99443d169e1fe5186bf95b11c4de8;
          Sat, 05 Mar 2022 06:51:01 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Panic while making buildlernel on RPi3
From: Mark Millard 
In-Reply-To: <20220305043002.GB21411@www.zefox.net>
Date: Fri, 4 Mar 2022 22:51:00 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220304214836.GA21411@www.zefox.net>
 
 <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
 <20220305043002.GB21411@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K9b3R16gJz594N
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=r4spSiQF;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.53 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.97)[0.975];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2836
Lines: 89

On 2022-Mar-4, at 20:30, bob prohaska  wrote:

> On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
>>=20
>>=20
>>>=20
>>> Unfortunately, the crash means that the buffers were not
>>> flushed to media when the problem occurred. The build log
>>> is incomplete compared to what actually built and where
>>> it actually stopped.
>>>=20
>>> So I'm not sure how you got:
>>>=20
>>> --- ng_pppoe.kld ---
>>> ld: error: no input files
>>> *** [ng_pppoe.kld] Error code 1
>>=20
>> Poorly worded on my part. I mean that I'm not sure how
>> you would know it was "in the same place" when you
>> re-ran.
>>=20
>>> When I looked at the buildkernel.log file provided,
>>> it stopped without such:
>>>=20
>>> --- all_subdir_netgraph ---
>>> Building =
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC/modules/usr/src/sys/modules/net=
graph/pptpgre/ng_pptpgre.o
>>>=20
>=20
> Apologies for the ambiguity!
>=20
> After the panic I simply re-ran the original buildkernel command, =
which furnished the
> added output and then stopped in _roughly_ the same place. It didn't =
panic, and maybe
> the panic was unrelated to the error. I've tried hard to _make_ the =
machine panic,
> using stress2, and failed.=20
>=20
> Perhaps more curious, I subsequently ran a make -j4 buildkernel with =
no
> extra options and it completed successfully. It's rebooted now and =
seems
> to work no worse than lately.

[Split to show temporary context switch.]

> It still displays the strange ping behavior,
> answering a few percent of incoming pings  unless an outbound ping is =
running.=20
> Then it answers maybe half of pings. That seems to allow enough =
network access
> to permit ssh and git to function, with a sort of stutter.=20

Are you going to do the official-builds-on-microsd-card
sorts of boot and try tests that I've suggested, such as a
13.1-PRERELEASE (snapshot) test? (This avoids your having
built anything tested and all but whatever minimal
configuration that you need to do to allow the test.)

Getting a failure from such an installation of official
installation materials might be more likely to lead to
getting help isolating the issue.

[Back to the Subject line's issue . . .]

> I've been using -DWITH_META_MODE as a default setting for buildworld =
and=20
> buildkernel. Might this be part of my  problems with the Pi3's ?=20

NO_CLEAN is more likely to have the result messed up: it
does less dependency checking and can miss more that should
be rebuilt/relinked.

WITH_META_MODE is likely to rebuild more than NO_CLEAN, and
so, less likely to include stale material.

Without special knowledge of the details of what all needs to
be rebuilt at the time, WITH_META_MODE is normally safer.

Rebuilding from scratch each time takes a lot of time
for each rebuild.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Mar  5 15:37:48 2022
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 90A5719E7042
	for ; Sat,  5 Mar 2022 15:37:38 +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 4K9pkn0WRcz4t2g
	for ; Sat,  5 Mar 2022 15:37:36 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 225FbmGC024490
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 5 Mar 2022 07:37:49 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 225FbmeX024489;
	Sat, 5 Mar 2022 07:37:48 -0800 (PST)
	(envelope-from fbsd)
Date: Sat, 5 Mar 2022 07:37:48 -0800
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: Panic while making buildlernel on RPi3
Message-ID: <20220305153748.GA24413@www.zefox.net>
References: <20220304214836.GA21411@www.zefox.net>
 
 <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
 <20220305043002.GB21411@www.zefox.net>
 
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: 4K9pkn0WRcz4t2g
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.04 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 NEURAL_HAM_MEDIUM(-0.95)[-0.946];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1995
Lines: 52

On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote:
> On 2022-Mar-4, at 20:30, bob prohaska  wrote:
> 
> > On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
> 
> Are you going to do the official-builds-on-microsd-card
> sorts of boot and try tests that I've suggested, such as a
> 13.1-PRERELEASE (snapshot) test? (This avoids your having
> built anything tested and all but whatever minimal
> configuration that you need to do to allow the test.)
>
Yes, after stable/13 settles down a bit. This failure was on
-current. 

> Getting a failure from such an installation of official
> installation materials might be more likely to lead to
> getting help isolating the issue. 

Understood. At this point I have two RPI3 systems which
exhibit the same problem (faulty ping response). One has
followed stable/13 (which had the clang errors you helped
with), the other has tracked -current.  
 
> [Back to the Subject line's issue . . .]
> 
> > I've been using -DWITH_META_MODE as a default setting for buildworld and 
> > buildkernel. Might this be part of my  problems with the Pi3's ? 
> 
> NO_CLEAN is more likely to have the result messed up: it
> does less dependency checking and can miss more that should
> be rebuilt/relinked.
> 
> WITH_META_MODE is likely to rebuild more than NO_CLEAN, and
> so, less likely to include stale material.
> 
> Without special knowledge of the details of what all needs to
> be rebuilt at the time, WITH_META_MODE is normally safer.

I note with interest that you say "safer", not safe. How do the
various cleaning targets described in the build manpage compare?
There's clean, cleandir and cleandepend, along with rm -rf /usr/obj.
It appears cleandir run twice is equivalant to combined clean and
rm -rf /usr/obj. I've not tried cleandepend yet, might it help?

It sounds like an occasional clean start buildworld/buildkernel
would reduce uncertainty, if not problems. 

Thanks very much for writing!

bob prohaska



From nobody Sat Mar  5 19:11:16 2022
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 350EE19F6B26
	for ; Sat,  5 Mar 2022 19:11:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K9vTY6BL0z3mdX
	for ; Sat,  5 Mar 2022 19:11:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646507482; bh=YvpnTmXWlcxyyxJgFj0teQeXqqmfmflZr9M8cm0E+tQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MupAsqCOgfb+piqKoUeBaZ43OzABhdQNZduJV8JLOt62r3DxlgBb9ERTTnzmVsK5NQ3gHVCWg9zA3Ni2D5QmL9J+d0pKUPXnsgH2+ra8pstVevNeNRJzLuAUPuzqLtHCtN7VNsSSp0A9BdJFtjy+kXnGd6Zvuc3CZgkw8cEU6x9SESGEVqjPXDimkBFm+Ud53rNHoeGetkiCr0TVsQaMmnpXi9lspF5YW6xnGzXZp0ZuNtZAgMzd8zuC5bdbqjMixSuhVOqtztJ2+eeXvEdOV4dUaVYq5L5n0yZzUPmMDf5RKgH5tyqFTyWd0MmaWTIa20xP/rkjlPrnLymYPoV5gQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646507482; bh=AxIXqBcwH9w/l8gq93VcatCGOYeW3F0hg9u+dRl3Xsa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j1GYNGuYZYvo3Gd/NxzxyAc8xo9sfE/+3gWea+//WeJ8NqVEio08gvT8CcNOV3SI8W6xQRJ2fizTEUDjP7p3DKFX0DCZ1/ifO8LY6fJFtzjB2xWsY+h02nHAakn7FFmo+MAGws0Bs3pwrKDmgah3lrN27C8LQ9KT9m8olursFIRWGCfI3sAyA3Pn3AhfpgyrLqilBEhSvAHEjZXCwTP9OKQpfFSK1tMF6Cnzrd4h1DFGcd3Q88C+k8TNhxKyszbgZai+7cKFTAS6R6p4GHld0LRAOxLuBnsagfjXDPAQemFOwJIgaHRaKbk+1Y5Ux9xXYY77+Avz4auxkDJa9wCewQ==
X-YMail-OSG: Cv.mfTgVM1ljntC40NpXOKIcE6YCxT24p8bgaj_BOiJWDzglaxZ1WS67DXcGQWG
 EA20DzJ4TYsXUaEF0pgqDNQPBj4dxrB1Cb4Tw6G0Oh7515lpk8dQD7hjyVK_6j2HWZHOepGFDR_r
 R9yei1Kvb4I.21wq3qDCpIdTDTvnIenXObJAW5tBoBoH_OzcH0utLYZSvgjHV6PZDe9e99MXSkOk
 xINaYRbKj4CPn2Bemcm1zA9vfnjqdFeZOxib6LamQ5yEZ9DequzsljZEcJ6o2qGC0jQ6WK0eTAzP
 JZ1GxZcdaysczRcme7a2YNlrFFzNr5NKHCyoZK66AzNnOvanuUmDTGsrWqWtjBDy2aZ.hFLRiAjP
 Cg1IfY1eDfdPd0on_iFnUdnQgxSbx3MugHCHxljCNR2SP8TF5lCxuiy0gzJN3TFLu4R9xR1lBCNr
 gA9n9GOvaDPXSdrgE06P5OCWjEnqjSg1AmncBj1PLyXw0i.6Rcy3d4Xqnhe9ozyWgKbB1YduLBo5
 6ATbthQGCKLpNP7VU84fkjom13f3QJOX9n6XqiBNN3LFFBwUv1EbkzKYMiDhJxwbA0MyNExE6kPs
 XN0lVsbHXdCxQAgZF1PfwSZGBCYjlyoqJ0Y2gJY75aviC.xlVcGjaGPeFHABmdV65sxQvMXtAjX9
 a6iK8u3fPjRHe5ETdYr1FBus48.ueTxlJUJfwWqmBZbbo1QdghRcSPvvArXA4ErHI61._C9dK4Ou
 JzK9g6YXRLSJ6v3C3TKU83AxqYGNO1I3lsnaLN5qc9RO1.KvnPu_QEN80eAw3jYpDE1Qmzv1iMBG
 f7laCQfb2bFtrZFZ9S51j_YnzgcnmIqPE1YH2fJGnvNWxCIm3MLN6BRprGzNYaRqs_gfJcXVuLZY
 GeY1T0pS1CuPjoMWZMli9pCvBh0.5XqO3sygM.0FPR3F_AZ071tBZHBHNsi9GJsicFC56N7sGFVw
 sJUyuqp4iwSaQ6sTfcAmeTXjy53mvdGJpMkCaI5ey95oso2wy1KlmbGrsH3p7ukypGN9d_Nj.Z0b
 YNClvw5DJgXKxEvNvDa3UrJ_PXz2tdgRlx2GpJ9OZVIKStZXDHVo1LKMlGGgFJK2O4S6KA04i_iC
 lxt0aqwxtoq4H_AJVvTTGaw3LLsq3wAhstLQItm71MFlTUC.QmvsJYk47P.HtTDCEs6iyobJQx_.
 P_FoFroR1zuyl4JIzLXiCkD1vWrX.KM3Tm9cvCwbS6HdyEQaH3JlK7Cu9sOF_KTZYDzGHUzOadli
 rxekJY4X1q9tT2J1XRf4FTCkf63xT1Cs2LcHZomkAb4TtyoP12sAGJZzOBIXtxEgiysCxHYFTAbH
 LfVCWDeEUjzIQ_d0AmHa.PCt.aSGd7Al6WTseGG.0YRBKizrP0wGEI03WgUH23I0Rf9mrLI6hsLO
 IGEoZhkgO6dxFgjWSr.tThlPrgdbFzIJS_jGVSqGF8HwdaCYT9dz0c7_FbotEg.yf5MlxpP2KMiU
 K_1N6FxwdrnXklkTmkcC6fyHA88NL0wR.P8YOsn.Enisc._HsjJXdCbyKHCkZkqAajfHWXtYDqX5
 Y9CdTRoLhe63lRNjitORR6XhX7dF4Lt0ZduBznVIq9GHqxVo7fYViDm.DgQYruJkoj2XbLr9kT_e
 8SwHwOYa5aYxkvym1k8IgXgOnllAS845VRY_LnBgRloUgdrx6QHJByar1PiMfAqmpNNQCcG41xsG
 Wq7nK9mlZXJrRGgAfERgcQdy9WtY.RZo7Cav1UOgd0t8_8ofnWQrpD9SULwvK5XMpl.oQ5G2B94.
 PU6PUlANgeAGTQLGRYiH4UK3uuQl2r5ogyGQhiUUIzw_uBAZ6mxRjvzL2gx89MeYkjlQi7uK0dNA
 WfkiVGFa0TblQPU_2q4II4vgVQsXE6yq6kwROLUG7WTfMXwrSm3BOIb2HpZ_rXZIiLdC7oLa6d_r
 x2TkspYHrCtBrNmcWdMYA7g99nlpUbp7moBjotdgf2RNwr_fAM1MljtYejA1KKh9obTxGcdClkgH
 5EWVC5peq1u.AiDRf1ZoxG4HjEZuIERsiRXhnm6FrHwVBk1BGiURWRaUDOr2HrGp4mLrbmCx9EEx
 ukQAcVvP7N67yPOR532N_eYudkGH3QuHWVnnaCaKyfpRLKOHGj1siHNjkqOjshDAB0s03.E.m70S
 .NzsGevyU.eHAybX3C_UzAeGocvlEZQd61ROCvrFNCQOvD7INLUdS0Ed.FiRhjGBXRzrq0SlM7Op
 lO2Z0Rvi6B7kfBzix0eDNoFDdj3UvnGrCE7qUNWu4jLpROdWcDyfszgMsI2QLmM.DE0oOn.FpF3G
 oFYSEFHTHCgk-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 19:11:22 +0000
Received: by kubenode523.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d589183c3f39e772b79c0bd3c5d00da3;
          Sat, 05 Mar 2022 19:11:17 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Panic while making buildlernel on RPi3
From: Mark Millard 
In-Reply-To: <20220305153748.GA24413@www.zefox.net>
Date: Sat, 5 Mar 2022 11:11:16 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com>
References: <20220304214836.GA21411@www.zefox.net>
 
 <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
 <20220305043002.GB21411@www.zefox.net>
 
 <20220305153748.GA24413@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K9vTY6BL0z3mdX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MupAsqCO;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6547
Lines: 179

On 2022-Mar-5, at 07:37, bob prohaska  wrote:

> On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote:
>> On 2022-Mar-4, at 20:30, bob prohaska  wrote:
>>=20
>>> On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
>>=20
>> Are you going to do the official-builds-on-microsd-card
>> sorts of boot and try tests that I've suggested, such as a
>> 13.1-PRERELEASE (snapshot) test? (This avoids your having
>> built anything tested and all but whatever minimal
>> configuration that you need to do to allow the test.)
>>=20
> Yes, after stable/13 settles down a bit. This failure was on
> -current.=20

I had also recommended doing the same sort of thing
with a 14-CURRENT snapshot: both tests.

>> Getting a failure from such an installation of official
>> installation materials might be more likely to lead to
>> getting help isolating the issue.=20

That also applies to 14-CURRENT.

> Understood. At this point I have two RPI3 systems which
> exhibit the same problem (faulty ping response). One has
> followed stable/13 (which had the clang errors you helped
> with), the other has tracked -current. =20
>=20
>> [Back to the Subject line's issue . . .]
>>=20
>>> I've been using -DWITH_META_MODE as a default setting for buildworld =
and=20
>>> buildkernel. Might this be part of my  problems with the Pi3's ?=20
>>=20
>> NO_CLEAN is more likely to have the result messed up: it
>> does less dependency checking and can miss more that should
>> be rebuilt/relinked.

I should also have referenced WITHOUT_CLEAN these days.

>> WITH_META_MODE is likely to rebuild more than NO_CLEAN, and
>> so, less likely to include stale material.
>>=20
>> Without special knowledge of the details of what all needs to
>> be rebuilt at the time, WITH_META_MODE is normally safer.
>=20
> I note with interest that you say "safer", not safe.

The Makefiles themselves can still have problems. WITH_META_MODE
notes more dependencies (for next time) than the Makefile is
explicit about. But there can be other types of special handling
at transition points that Makefiles are responsible for. That
includes dealing with new dependencies that prior WITH_META_MODE
activity could not have seen yet for future use and dependencies
that existed before but that WITH_META_MODE has not yet recorded
a new lack of a dependency yet. Frequently such is handled by
extra clean-like activity that forces certain things to rebuild
based on just the older dependency information or dependencies
that Makefile* themselves would detect.

Also, files that are no longer intended to be used can hang
around and potentially be accidentally used.

> How do the
> various cleaning targets described in the build manpage compare?
> There's clean, cleandir and cleandepend, along with rm -rf /usr/obj.
> It appears cleandir run twice is equivalant to combined clean and
> rm -rf /usr/obj. I've not tried cleandepend yet, might it help?

I happen to do rm -rf explicitly.

clean and cleandepend serve different purposes. cleandir done
twice includes doing an effective clean and cleandepend at
least once. There is also cleanworld and clean universe.

QUOTE
     clean            Remove any files created during the build process.

     cleandepend      Remove the ${.OBJDIR}/${DEPENDFILE}* files =
generated by
                      prior =E2=80=9Cmake=E2=80=9D and =E2=80=9Cmake =
depend=E2=80=9D steps.

     cleandir         Remove the canonical object directory if it =
exists, or
                      perform actions equivalent to =E2=80=9Cmake clean =
cleandepend=E2=80=9D
                      if it does not.  This target will also remove an =
obj
                      link in ${.CURDIR} if that exists.

                      It is advisable to run =E2=80=9Cmake cleandir=E2=80=9D=
 twice: the first
                      invocation will remove the canonical object =
directory
                      and the second one will clean up ${.CURDIR}.
. . .
     cleanworld           Attempt to clean up targets built by a =
preceding
                          buildworld, or similar step built from this =
source
                          directory.

     cleanuniverse        When WITH_UNIFIED_OBJDIR is enabled, attempt =
to
                          clean up targets built by a preceding =
buildworld,
                          universe, or similar step, for any =
architecture
                          built from this source directory.
END QUOTE

To my knowledge you do not build for all architectures,
just aarch64 and armv7 . So cleanuniverse should be able to
be ignored.

=46rom Makefile.inc1 :

QUOTE
# Make command line options:
#       -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir
#       -DNO_CLEAN do not clean at all
. . .
#       -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel
END QUOTE

but the actual logic is:

.if defined(NO_CLEANDIR)
CLEANDIR=3D       clean cleandepend
.else
CLEANDIR=3D       cleandir
.endif

so cleandepend is also used for NO_CLEANDIR . This shows the
relationship: clean cleandepend does less.

As for cleanworld ( from Makefile.inc1 ):

QUOTE
# cleanworld
# In the following, the first 'rm' in a series will usually remove all
# files and directories.  If it does not, then there are probably some
# files with file flags set, so this unsets them and tries the 'rm' a
# second time.  There are situations where this target will be cleaning
# some directories via more than one method, but that duplication is
# needed to correctly handle all the possible situations.  Removing all
# files without file flags set in the first 'rm' instance saves time,
# because 'chflags' will need to operate on fewer files afterwards.
#
# It is expected that BW_CANONICALOBJDIR =3D=3D the CANONICALOBJDIR as =
would be
# created by bsd.obj.mk, except that we don't want to .include that file
# in this makefile.  We don't do a cleandir walk if MK_AUTO_OBJ is yes
# since it is not possible for files to land in the wrong place.
END QUOTE

To my knowledge cleanworld is more extensive in its coverage than
any clean , cleandepend , or cleandir usage combination.

cleanworld has some fall back logic that uses cleandir once for a
particular type of context after its potenial rm -fr activities.


> It sounds like an occasional clean start buildworld/buildkernel
> would reduce uncertainty, if not problems.=20
>=20

It can. At times UPDATING will report needing to have cleaned
before a buildworld or buildkernel .



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Mar  5 19:22:59 2022
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 E834219FD77B
	for ; Sat,  5 Mar 2022 19:46:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4K9wGF24sdz3s79
	for ; Sat,  5 Mar 2022 19:46:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646509597; bh=jUyusGatyI5jxXbl7VTza3DOmL/v+I2Iavo+YiqFKrs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lIsjGbH6UL0Oi2eUlPYq0SG/VUei4inYxdybjWNl1c4svcadaoe4arz2ODSBYeNgwW/lP24AJdFqsKJa7APrHo1z/fN5kAhc4I4jPSRTtWMXVP65i4lE466oKbdCGnUVzm5Sf/2sBKfJLmdg4yce1CMBi3cmrSs9+GHm6z08mtcCs7YwRdQoX3lJqAYcmUCfl2TKowZjMvcuRbc3TOW0QOCUZEh3jzejNil/KR11CLsOQnZG/uwJST9ZrjHL7+yF3SmlU4pXPvcglFm7Qpflhg2ddi7yUJuzLHuYaFJvtecSeni9gLGrxMdZBhMF1BGl2j+jKd/Txo8x+jfWJh0qqg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646509597; bh=KQUfaWnD97l/pv5kw3Ax7LuE63Eex0X23zGZUn8TtXw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uITSjmVaGm9kRHbCkda6x+OiGZ9UX/WejQZU9/VQckqSMEJTCW/F/v9VNvtLRrSCtrEaRmw2QkYR5SXrQ42qCv3TkBLuqYkftbwqBfkXinE2Z6bVncGjtKDgw3HkPpLA5g2S/SnKW6aSLBGvFjts5Li4yS1ejl3SP88FifrNfHkHnC8+TXW6Jtxvqfet32MINxuPKFdumRfYj6FG8Cx4rH8tVlCPkQrx4yjODax59MMpMlRuB393e1kg7izVpy9RzdzW/Yci3F2idztakJJhFxgssfLIFnS2W3oQyQZnU/DFn2+qMToBYcCT6aGeAp2bjOJl1JpfPjc5fp5dU+TXrA==
X-YMail-OSG: pXujB1sVM1mCFbwQ32fcAWp.eqY20waiqoxxfx4.q1KYunx5E5Wl6qlJRAU_khs
 w4TcJh4aJUM8qkwcpLuQPLajIZ2K.dWyWJF3Qy3TumAAlsbjSBdTKsy8DAPts55PBS57CktInZFr
 3EP8LLSm7SCAivkOCw3cXN1u_5gfzaDsqOtfjmmDkGtAj4kj20QLOuu33GjVRjSGupkgGIknc902
 rf.zarkaDU3FWEptKl4LeWZFrK9TUru1bycWnu5gr.MLIBnk.bZcpG6ar5dDYWKqYXaBSbvQjixD
 akxqkarpnWPt2NgRn3Q4v4p80Fd86nLdawTSBB_cUt28IhJa0qhn3ND2HShosiChp6gvAXx06E5Q
 0VuLxlZST5rqEYK5QCBKTh9B982SLyKcryFyI2h97.m7sME3QC78mOCXPWzXFYVUo2lhOZDe25Yq
 1ojZlA_ybyPsh3yyjCkWxxbif8s_DmeKtFpzb.eDTjMO8tpFCW.RSgTaNv45mKJEhFxWVnY4tgAO
 SlbP9OEblb7wpr7GbCiqTVZoyy9LNz9aMmECf7w.5UOgYkJJXHtHgmjJNBDZtK6OuS3arGZFREZ7
 SHrYYU2ck6NL5YAB7yPR8ew9NHXARa31.i6WAcqWbgWCAmrrhnM0eKw5VFzabyd0F7yc1Gza.FjZ
 y5kfCP2wKh88N9TZs3RBO_P0Gu09e1wA2A9grp2MjD2unACqxedNiyRW3x6WxSHxolIZWpMZVp1v
 UNVFFXrFVK0nwIY48tgBpKAr2tNSTdl6Ck54Ws0usGIUKtHIhWTLNY0I91jWdsylUI3NHpPu2T8j
 xkuaA6ifgwIgFNcHBEjcgg8ka84yxin14qOo.qAakIiKLfH1qNfOPk1wFZFE15yFa8MOJWxtMOGw
 gbPiFNgZq2Px5VCml4ANks07qqd1uAgT4jpDesCbrOFB2jpLPMVxgmhc8Bzvro93gAOM4bBOrLmc
 oTAiluuIM.EjiW0KJNMWBKZ.TxpF5BoWs7BKMGK8l_KAureKX2gf6kSHC5kHj7Fi4XfZdZGi9qgF
 ZJXsH8Ni70VGEhx6gnxP60Z8BJGn8G9OYb_TH_j6.XZYKM8jkM2IztKXucaufgN5u52QZgSMg._Q
 ID1BdJxo4KgJZbXp0DVxqkZ.8z03UdztacfDTh1alSlPS_B0eHbwoEec6VlgttQGRSJnIiYKnOI6
 Gn8xg0gNIgo7m3RtSVH69Jocv4BAZJV7bEYSvymDuKjI6150TcawdgkKUMt0lHBhcUOkuPTMiYLH
 F4B64l9PHdNFv2jWtT7GW3SxQWMKkEO23MRF_wxKirGr_k0W8KbRRFtxt7I3kUxNGagZQCIDupcz
 FmgGzZEnuEjS3j28t1nsoHyeWkoRgUJ2BV5gqVHSPzP7PMV0rs7F1k6G7GjOMTeFS3lNE.vw.PbN
 rdRDm95lmCtaMBgoSUliaaqJsDVfDKGyAHK4txVty.IUNCGmOr3Ak_2vDI_hLmba3_SKXDyDnMeX
 hqcfCR5kgo98ihoEWJupItbcjCBrBonLslXZiHJ_oYT9.OJBgxoD.pEB5PVahf_CqYiibuIGWsFl
 gM4_04.0uwMldXzEAHKZxwpwgCzTyC3kyvixVmJme8rvlztY9gsXem0TJDxlh0qSH2wObatrwPEa
 bu_DIBfNGhO.zCxhADKZ_UVc6OYTynxF6CNX3fOi_eepXsiATGJJjVfsCKm8HNiesCsFps1DM.Bk
 .rWQQy2AbLDHy4lCg3N4VxQz4uL21FX4BhdiSqWtDRkVl4KyA0PCFSoEJLknTMEoXSlqVRujGoTt
 4RndA96whCGJPf_tLA6DvIWyQHRni.njRlyxMnt1suMGoFaoepQv6DURgDV2OaPI7g_MxuXG10Js
 .AJxIbJ_NXZ38kyyL4ma4uVvEN1sa2tbR5SlMnN0nt7eo6uvVxMKShyWthCFHt6Nz3SRPiMUaple
 9jaytVI4jKSCrLPxSxWi4suuoXG8agsk.Nwx6WYaK0VWwMVDuS7AvEEVk9L7dSSkb7KKD3JtKh9E
 nv2L0u.X0ctPkiMfMTW0LVxbV0vcW1CsIz5JxXQxgHY_kVcmqL5P7GUem0dEGPkzkLFaLfjoUWvT
 IVnfiew57RZjdKCYwKXLW.fdm1JvEZWAJPqfhKMFCTO52l7IL3ybvp0BKL7EUwQRir1F6uHxTe4.
 bbXAGb6hf5GrDFbw3zbwizHk8XXHXURALiVSDFFlqInQxOockPMOurnOkA6aEqO1XdqjrnupJcyp
 .nANyQYeOvNSmucuDDbu_xFUBkbjNst6v3WsSPE8apAp2Ib_r6rp7cwVxdV1a5Upj9ahAe0hft.e
 uijSG8N0URwqW
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 19:46:37 +0000
Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ae5a90ba2db0832d31271a01e8a0614;
          Sat, 05 Mar 2022 19:23:00 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Panic while making buildlernel on RPi3
From: Mark Millard 
In-Reply-To: <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com>
Date: Sat, 5 Mar 2022 11:22:59 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220304214836.GA21411@www.zefox.net>
 
 <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com>
 <20220305043002.GB21411@www.zefox.net>
 
 <20220305153748.GA24413@www.zefox.net>
 <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4K9wGF24sdz3s79
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lIsjGbH6;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7351
Lines: 199



On 2022-Mar-5, at 11:11, Mark Millard  wrote:

> On 2022-Mar-5, at 07:37, bob prohaska  wrote:
>=20
>> On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote:
>>> On 2022-Mar-4, at 20:30, bob prohaska  wrote:
>>>=20
>>>> On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
>>>=20
>>> Are you going to do the official-builds-on-microsd-card
>>> sorts of boot and try tests that I've suggested, such as a
>>> 13.1-PRERELEASE (snapshot) test? (This avoids your having
>>> built anything tested and all but whatever minimal
>>> configuration that you need to do to allow the test.)
>>>=20
>> Yes, after stable/13 settles down a bit. This failure was on
>> -current.=20

I recommended a temporary experiment on independent media.
Why would settling be important? If you want 13.1 to
address the issue (if it has it), the earlier the better
for discovering if it has the problem in official builds
with minimal local adjustments to allow the test.

Side note: stable/13 now has the greatly improved OOM
kill messaging and so is unlikely to be misleading in
notices about such.

> I had also recommended doing the same sort of thing
> with a 14-CURRENT snapshot: both tests.
>=20
>>> Getting a failure from such an installation of official
>>> installation materials might be more likely to lead to
>>> getting help isolating the issue.=20
>=20
> That also applies to 14-CURRENT.
>=20
>> Understood. At this point I have two RPI3 systems which
>> exhibit the same problem (faulty ping response). One has
>> followed stable/13 (which had the clang errors you helped
>> with), the other has tracked -current. =20
>>=20
>>> [Back to the Subject line's issue . . .]
>>>=20
>>>> I've been using -DWITH_META_MODE as a default setting for =
buildworld and=20
>>>> buildkernel. Might this be part of my  problems with the Pi3's ?=20
>>>=20
>>> NO_CLEAN is more likely to have the result messed up: it
>>> does less dependency checking and can miss more that should
>>> be rebuilt/relinked.
>=20
> I should also have referenced WITHOUT_CLEAN these days.
>=20
>>> WITH_META_MODE is likely to rebuild more than NO_CLEAN, and
>>> so, less likely to include stale material.
>>>=20
>>> Without special knowledge of the details of what all needs to
>>> be rebuilt at the time, WITH_META_MODE is normally safer.
>>=20
>> I note with interest that you say "safer", not safe.
>=20
> The Makefiles themselves can still have problems. WITH_META_MODE
> notes more dependencies (for next time) than the Makefile is
> explicit about. But there can be other types of special handling
> at transition points that Makefiles are responsible for. That
> includes dealing with new dependencies that prior WITH_META_MODE
> activity could not have seen yet for future use and dependencies
> that existed before but that WITH_META_MODE has not yet recorded
> a new lack of a dependency yet. Frequently such is handled by
> extra clean-like activity that forces certain things to rebuild
> based on just the older dependency information or dependencies
> that Makefile* themselves would detect.
>=20
> Also, files that are no longer intended to be used can hang
> around and potentially be accidentally used.
>=20
>> How do the
>> various cleaning targets described in the build manpage compare?
>> There's clean, cleandir and cleandepend, along with rm -rf /usr/obj.
>> It appears cleandir run twice is equivalant to combined clean and
>> rm -rf /usr/obj. I've not tried cleandepend yet, might it help?
>=20
> I happen to do rm -rf explicitly.
>=20
> clean and cleandepend serve different purposes. cleandir done
> twice includes doing an effective clean and cleandepend at
> least once. There is also cleanworld and clean universe.
>=20
> QUOTE
>     clean            Remove any files created during the build =
process.
>=20
>     cleandepend      Remove the ${.OBJDIR}/${DEPENDFILE}* files =
generated by
>                      prior =E2=80=9Cmake=E2=80=9D and =E2=80=9Cmake =
depend=E2=80=9D steps.
>=20
>     cleandir         Remove the canonical object directory if it =
exists, or
>                      perform actions equivalent to =E2=80=9Cmake clean =
cleandepend=E2=80=9D
>                      if it does not.  This target will also remove an =
obj
>                      link in ${.CURDIR} if that exists.
>=20
>                      It is advisable to run =E2=80=9Cmake cleandir=E2=80=
=9D twice: the first
>                      invocation will remove the canonical object =
directory
>                      and the second one will clean up ${.CURDIR}.
> . . .
>     cleanworld           Attempt to clean up targets built by a =
preceding
>                          buildworld, or similar step built from this =
source
>                          directory.
>=20
>     cleanuniverse        When WITH_UNIFIED_OBJDIR is enabled, attempt =
to
>                          clean up targets built by a preceding =
buildworld,
>                          universe, or similar step, for any =
architecture
>                          built from this source directory.
> END QUOTE
>=20
> To my knowledge you do not build for all architectures,
> just aarch64 and armv7 . So cleanuniverse should be able to
> be ignored.
>=20
> =46rom Makefile.inc1 :
>=20
> QUOTE
> # Make command line options:
> #       -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir
> #       -DNO_CLEAN do not clean at all
> . . .
> #       -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} =
buildkernel
> END QUOTE
>=20
> but the actual logic is:
>=20
> .if defined(NO_CLEANDIR)
> CLEANDIR=3D       clean cleandepend
> .else
> CLEANDIR=3D       cleandir
> .endif
>=20
> so cleandepend is also used for NO_CLEANDIR . This shows the
> relationship: clean cleandepend does less.
>=20
> As for cleanworld ( from Makefile.inc1 ):
>=20
> QUOTE
> # cleanworld
> # In the following, the first 'rm' in a series will usually remove all
> # files and directories.  If it does not, then there are probably some
> # files with file flags set, so this unsets them and tries the 'rm' a
> # second time.  There are situations where this target will be =
cleaning
> # some directories via more than one method, but that duplication is
> # needed to correctly handle all the possible situations.  Removing =
all
> # files without file flags set in the first 'rm' instance saves time,
> # because 'chflags' will need to operate on fewer files afterwards.
> #
> # It is expected that BW_CANONICALOBJDIR =3D=3D the CANONICALOBJDIR as =
would be
> # created by bsd.obj.mk, except that we don't want to .include that =
file
> # in this makefile.  We don't do a cleandir walk if MK_AUTO_OBJ is yes
> # since it is not possible for files to land in the wrong place.
> END QUOTE
>=20
> To my knowledge cleanworld is more extensive in its coverage than
> any clean , cleandepend , or cleandir usage combination.
>=20
> cleanworld has some fall back logic that uses cleandir once for a
> particular type of context after its potenial rm -fr activities.
>=20
>=20
>> It sounds like an occasional clean start buildworld/buildkernel
>> would reduce uncertainty, if not problems.=20
>>=20
>=20
> It can. At times UPDATING will report needing to have cleaned
> before a buildworld or buildkernel .
>=20
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Mar  6 18:11:50 2022
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 4A8051A05923
	for ; Sun,  6 Mar 2022 18:11:59 +0000 (UTC)
	(envelope-from mail@crcomp.net)
Received: from www18.qth.com (www18.qth.com [69.16.238.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KBV6Q1FZcz4hKk
	for ; Sun,  6 Mar 2022 18:11:58 +0000 (UTC)
	(envelope-from mail@crcomp.net)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crcomp.net;
	s=default; h=Subject:From:To:Date:Sender:Reply-To:Message-ID:Cc:MIME-Version:
	Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=QUHSVREizftoZ0pw6WeWpLDd4UGiISRdoSb8Gs76FOU=; b=HUNqap86/h2ndUfxQJB3SuJnGJ
	Bcwez4tnBX5DQLOW/EWzveWmnbA2v4+h8ZuV0ZJjthMm7rthoKbAjSPK1xcRF9WHhpParjy3kjXr7
	c5/QXP/aPDlI0Nq9Bu+vCT7uUWv7mqiFzusr2IBMuMbPdevrX8lBjYZ11aHxWOWmw85lRSxsNQUfD
	weMrtiCyZGAUpkfm9GqoYey0uq4H/8PBNgwOTCu8uY8CFwxlWG4ALy4cCn3A5KSHJUWKlOBqwiU2r
	r15bhfaEfSwkwtoxESonLOVYA2lfrnZBtMshgIG4wmqiW8wSCuTgOsZ8vK0OHu5qHikm3/S6byasz
	u1Ru6JMA==;
Received: from [69.146.199.132] (port=21234 helo=michael2)
	by www18.qth.com with esmtpa (Exim 4.94.2)
	(envelope-from )
	id 1nQvME-0002Nk-JR
	for freebsd-arm@freebsd.org; Sun, 06 Mar 2022 12:11:50 -0600
Date: 06 Mar 2022 18:11:50 UTC
To: 
From: Don Kuenz 
Subject: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - www18.qth.com
X-AntiAbuse: Original Domain - freebsd.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - crcomp.net
X-Get-Message-Sender-Via: www18.qth.com: authenticated_id: mail@crcomp.net
X-Authenticated-Sender: www18.qth.com: mail@crcomp.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Rspamd-Queue-Id: 4KBV6Q1FZcz4hKk
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=crcomp.net header.s=default header.b=HUNqap86;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mail@crcomp.net designates 69.16.238.59 as permitted sender) smtp.mailfrom=mail@crcomp.net
X-Spamd-Result: default: False [0.43 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 HAS_X_SOURCE(0.00)[];
	 TO_DN_NONE(0.00)[];
	 DKIM_TRACE(0.00)[crcomp.net:+];
	 NEURAL_HAM_SHORT(-0.97)[-0.966];
	 INVALID_DATE(1.50)[];
	 HAS_X_ANTIABUSE(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[69.146.199.132:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:32244, ipnet:69.16.192.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 HAS_X_AS(0.00)[mail@crcomp.net];
	 RCVD_IN_DNSWL_LOW(-0.10)[69.16.238.59:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[crcomp.net:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[crcomp.net];
	 RCPT_COUNT_ONE(0.00)[1];
	 MISSING_MID(2.50)[];
	 HAS_X_GMSV(0.00)[mail@crcomp.net];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
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
Status: O
Content-Length: 1341
Lines: 57

Greetings,

My RPi2B GPIO header connects to a PCF8574 I2C adapter with these pins:

    RPi2B           PCF8574
---------------     -------
Pin  2 - +5VDC  <-> VCC
Pin  3 - GPIO 2 <-> SDA
Pin  5 - GPIO 3 <-> SCL
Pin 39 - Gnd    <-> GND

/boot/loader.conf contains these lines:

root@generic:/boot # cat /boot/loader.conf
# Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="NO"
gpioiic_load="YES"

and /boot/msdos/config.txt looks like this:

root@generic:/boot # cat /boot/msdos/config.txt
init_uart_clock=3000000
enable_uart=1
kernel=u-boot.bin
kernel7=u-boot.bin
dtoverlay=mmc
/ {
  gpioiic0 {
    compatible = "i2c-gpio";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_gpioiic0>;
    scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
    sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
    status = "okay";
  };
};

Nothing happens:

root@generic:/boot # i2c -sv
dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
Error opening I2C controller (/dev/iic0): No such file or directory

What's missing? Thank you in advance.

Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.



From nobody Sun Mar  6 21:00:38 2022
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 2F0EE1A0206F
	for ; Sun,  6 Mar 2022 21:00:41 +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 4KBYs31LS5z3Fk8
	for ; Sun,  6 Mar 2022 21:00:39 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 382BC1B1E4
	for ; Sun,  6 Mar 2022 21:00:38 +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 226L0cgN076950
	for ; Sun, 6 Mar 2022 21:00:38 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 226L0cJA076949
	for freebsd-arm@FreeBSD.org; Sun, 6 Mar 2022 21:00:38 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202203062100.226L0cJA076949@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, 6 Mar 2022 21:00:38 +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="16466004381.f346b.75356"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1646600439;
	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=Polaqw20sOib6xuXkFWbL7lmDC0sRSj0kt5Wp2t5xJY=;
	b=t9aGfWKpY+Nk7rIY26nl+PThQ6YiA51mZJ/A3oicW8PjuWxLnavflj3L3vECoOfBjmTywo
	wd5OIzE/52SxztiY3W5wCcG+zxTpSYFT5j2XRUm6cHXEAAdB+PcNWF496FSfRqPyNd96lD
	LQSTtEGvfqoOQQaihQeUCsBnyvKOks9XjRO8dRyWP2vKov9Zfx7Z/Dbxla8gqX549f8utx
	1pd0a8LG5gKiBoP7SeWrtRtdoY9ruWbLUyMiDZgrEdm92gzl0HUZpEwqUtT7eV9Dp5HzzQ
	V1fT7SiAURnUTUO8ILUfDfbeoqLxjMp6LHOmX5KeonDqWIW0/JZXbsc61tBEsg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646600439; a=rsa-sha256; cv=none;
	b=XDu+7CEpjO/fAL6MFy2/0woYMWnNWBdhGbky4b46MuHO5VrxePVI8G8lEJu5X5aYd8pys2
	XkJvxSAUjoIGz9naAjN3vNBhT6y8SLuTo3r/4zzhFuWs9T5OK7wWj5QEvrtFZhf5/5y7+h
	vrfws92JtLjU+0VR5ss8NR9gPyZHt4Vc8RfW0ARJZN+76OEJiPTpvhgzABAns11GRbN6GF
	xxbGnY893qpwuk8/zHGWvOdU3gEM+xnLFZSpJ/JDaAHwKEkbMCm3xTUy4qHehIXqBLrE45
	5/2MY8346OfZP1rHSSr4lChMRHEjSmlIGawRTbP/yEEaCsOPmtBE0cu2600abg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1796
Lines: 38


--16466004381.f346b.75356
Date: Sun, 6 Mar 2022 21:00:38 +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.

--16466004381.f346b.75356
Date: Sun, 6 Mar 2022 21:00:38 +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.


--16466004381.f346b.75356--

From nobody Sun Mar  6 22:14:54 2022
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 189C119E9564
	for ; Sun,  6 Mar 2022 22:15:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KBbVx5Hsjz3jhc
	for ; Sun,  6 Mar 2022 22:15:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646604898; bh=zmBMWLcDHXtRZBCCz1jV2xJxn2OR3e6N8m9Q55t6BQY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=htp+x0NLLFRkivX3P+3ji7i/2C5GEGmPJIsRGfwSwDpo6a84r3EFTKUQSPSfqZgOfOiM4ia+kZZVSHGc1v48OPEXYGvWQQaeGN7o+NUHK8fTIQOFIHuZ5M0j9VOx+s1XV4r6Lg4BVEnLed1G4xC82k4wwLAPO7OndyWZwsAMCcI4QI4pM/fQ2f0d59bmI00Bid7JnSZ5GLlnxwJxoZdaAgZElhT1p9/6UoxPoIwbLh0dEjjbEHMbMBdqsdq9QbhdRo9NXgKUo4neMl+3KedcEnOcuxR35jrk8j41Zm/P4rd2LOwBpln+uTSn9WMuWMXS63gSXIkJgjVw/X5y86/7qQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646604898; bh=4KiYnNXeG3rJMiiHcgtVdt1G2f6j2WJ+agpmPtRO8Fx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BOi5H/j43/iUCrtQGkjirp6OUiYR7WsdMjmahJrqYRuzNgi6XKgxSx9gMMNqUB/rLg3tchYwDO2dkC+EDcQc6JHNJQqIDtli+EfM+AQA0vnzwnRvEMKcoKNozEG4lxzrxsz6Ky5lefJLVsH6Z+ifKvxDUB35AS0yIJ8KFDoCZU2ihFZ9g6ydJfd9rTN87A1qgcIDeLNW5AjFgdrJNOt9AXZimLyZyjLjfLJJnb3k896ikl40JPFmw2tIY6y5Z5uY5CLmUM/V8l6V5u5DPa4aJrFU5iweBKupaitjpvsc+rozIOgryUmw+L8X2yVwh0SWgtX8FVCJ1JQ50KPL4/5C4w==
X-YMail-OSG: vFcrHVAVM1kF4MwygGM3zRc.CDVmNOXgAMuMx5WtfZ0cvUFPmAUkv7iuIzt4sHu
 voA6l_vX_HhexOVZPINIUaB6ipzlesVD2Ed_Q2PXQjWgjSsswcAbYPpP1k7IyKtQpx6Wk8oIoYFd
 kBZtQvB58epi8JutDz2DyM7vBtnw_FpZB53CoVgCnqV2mBOmGUHcYB1GXDNn_CRH2IoByJpj.Vvs
 .lc0fy8flr9687jArkDsXSLjHUU6oqAP.wBUv_QqaY2Q0H1h8gjTkbG0yYuiDIbPBtcF.HO6t8Xg
 03oFudszT3dkzy.sKBukQDP6CNYv7NETF8EG8PF4Y4hxA4t2X654xV5VukamlusIMRixlfSOy4ij
 MRp0Q5UYt8MVIxB7ic7Ku2idCAhVhwAfmz8k.jK0_neAjUavCY6P5sgcEf40Q33reWEnjKFfccEZ
 6ssjhkj10OyLQFD1_f_T7TksL7Q96A18OLs079fzfCdRcJmdLRsVZtOCrrC5I9uL2wcsyNjgsW9P
 2BeauO1sg5b_qqUHTHOL9ce6Z8sOyXXeoMZdJLhDWE6pKL28OMN6d49DEx9EYwU3PqVmhlKR0aWu
 zJFX9bUVLjLnCQxgu9nUkT.8BGziZaDfJTzit.NTBOj0.27PxsdCihjHd2.xr1E2fUaz6dWUJe9z
 qNZjxpu74DNF5igEgTLTpgviarsCmIGZSm.KCT0KrShkDkSyl5kGRJczfScoCkH1CsFEkj.vpx6n
 CvVn1kUjX74PovM4y7uDW_jOhdzPePWoIoctmicODmEMVkPxoC7PW9A7tVOddTVhkubZwAdteMJJ
 VYx8npmneL8a9hdWCa2bSoUVDRwEph7.XZDIhuiCHjTqSiTfW8vcygVYvc_GrYpSL18dloQLLOd0
 Kp6REjFR_H0gFga3qC7kK88NsbO74Q2dVqVVG0zEiaPRUbqqgSu8RQm7DTr8Er5U0k5hLcL5476U
 XrqGS.WzbxOEgs.rIuY2KrRECj_kEzsgTxr2X884ELtycya88_jo1p_sUqLN0rN4qzfo6_KIEqhE
 0o59ht0CKG.sw7uZ.8mWS_1NUk5ST0BjDMTJklmfw0lcZXCpZ61unAOcmLUcdLCRNiF0kAVkg8jn
 fOQRusCw0GCS5T_jW_7CVFclE.ZcirVFbl4dR6xvdlG7n1OY0C5g17LS9_Py2vcsQ8yEs37848h9
 KtRf7_uUtErer_GvNL1_R8Ocqzzft4i1wJNMaRk2DsGuvA_gFrIkEqp9XwNwyQbWjr5WEkCu8GNT
 LpJzsPQHBF5MELb0_bKSPE7O8dlKYd3LyA08FE43Wroi7f34lY9rswTdeqfGalVsldGSPLvejr9M
 l_YDCrR6IuzIYfw3eQ4oR1GQL05m_MwPpw_YU1veRtdLhTETtJzN292c_vfBtSVi4.i0a_sgKi.6
 naXnnhndevyz8JnodgcDTnoBHvlNQZmSOzk752LfG3..e_YWf3xq_4GwDHqj1bVUb5lW_Rv1z881
 AkTInxPlPaAKd.X7c9_XXwCJNFjZmwfTY0hZmtB2U9oxvoCko1uQbz2SKt1xoIRW5FKgTpfQNTY4
 gGDFyhhNqw6aZwICYVq4DQOy9vASN8pDrymMXE003EAogs86KPYKTvx7Ee9koSSkalcWx8ohtoK.
 LfXaFyv_.ZpvR1i6jt8Km2Ec5WLqh8kbF5RoMpWOowGa5jPWSifPSCOYfsyKw1rJ2CwDHVPtKtsh
 FXW4ORHZsKcB2CpzaFa2cbTyUawUiC03k53lQee3qwqaqOWS61NoOLuIes.qe57NT7sHQtekcuYe
 1aLRK6JNAq9pNRfBQwAagq0J4jPg3pTTugc84aAl8tbm2SvjQgl9BE9XwbZ2a41KxcypOFQJv30w
 VaC7MTJjuYk9O0y3yfl94wOw.WVPH49yy4yeklWgXABxFy3Lp6rA57NioygQ8LTWmXpftTzVKDN8
 PTk2IPV0PeUwHRymPU79X1OfrVPwqiy1wkPeaUObH8jFH6l0tz1HRHpzVWDuuHkuj0xwRZCRh8NF
 S1O6BALfuEL6eyu0NGvbvz0mVfwsvbvtXU1EpSoLd68JA547K7W6VvKC8S1TBUeFY6EvYU2OH7uO
 Xs_jWu.zW4BWdWPRYfeWc6P5D7rvzdwlF0T2YL0sBif1TdqTAyH2nVxYE5HbtMTeWzhxVQWG5ZEq
 mjIjU8IDcedBNFFwcHhvT5WikrAijE.SO1Zv7FHJlLLY90L1tocvZ9TTk02k2vf48iEb6i0umNWi
 lxNM6iRNtEgbTOAlb0MPijGdJujDBTJO.iSxsIN_bii.8lQhgSHuZWDONGvC7yNqskP1_XceNj9o
 zl4K2l7AAcM0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Mar 2022 22:14:58 +0000
Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 069f05b675626856e8c4bcf1133344cd;
          Sun, 06 Mar 2022 22:14:56 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
From: Mark Millard 
In-Reply-To: <20220306181214.932C51A05C0D@mlmmj.nyi.freebsd.org>
Date: Sun, 6 Mar 2022 14:14:54 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <47C61079-AB2E-4E81-AD95-F6042477D4E8@yahoo.com>
References: <20220306181214.932C51A05C0D@mlmmj.nyi.freebsd.org>
To: Don Kuenz 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KBbVx5Hsjz3jhc
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=htp+x0NL;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.93 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.43)[-0.426];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2107
Lines: 80

On 2022-Mar-6, at 10:11, Don Kuenz  wrote:

> My RPi2B GPIO header connects to a PCF8574 I2C adapter with these pins:
> 
>    RPi2B           PCF8574
> ---------------     -------
> Pin  2 - +5VDC  <-> VCC
> Pin  3 - GPIO 2 <-> SDA
> Pin  5 - GPIO 3 <-> SCL
> Pin 39 - Gnd    <-> GND
> 
> /boot/loader.conf contains these lines:
> 
> root@generic:/boot # cat /boot/loader.conf
> # Configure USB OTG; see usb_template(4).
> hw.usb.template=3
> umodem_load="YES"
> # Disable the beastie menu and color
> beastie_disable="YES"
> loader_color="NO"
> gpioiic_load="YES"
> 
> and /boot/msdos/config.txt looks like this:
> 
> root@generic:/boot # cat /boot/msdos/config.txt
> init_uart_clock=3000000
> enable_uart=1
> kernel=u-boot.bin
> kernel7=u-boot.bin
> dtoverlay=mmc

config.txt seems fine up to here. But I've never seen
anything indicating that the following notation is
valid for config.txt files:

> / {
>  gpioiic0 {
>    compatible = "i2c-gpio";
>    pinctrl-names = "default";
>    pinctrl-0 = <&pinctrl_gpioiic0>;
>    scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
>    sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
>    status = "okay";
>  };
> };

If you have a reference indicating otherwise, I'd
be interested to know what it is.

The notation seems to be source code for part of a
.dtb or .dtbo file. As I understand, there is a
separate toolchain involved in producing the binary
file(s) for such ( dtc ) and there is separate
place to put such .dtbo binary files on the msdos
file system: overlays/ .

I've never made my own .dtbo and so am not able to
help with the details. But I expect that producing
and using a .dtbo file is the general direction
of what needs to change for this part of what you
were doing.

"man dtc" should work for getting some information
about the dtc tool and how to use it.

> Nothing happens:
> 
> root@generic:/boot # i2c -sv
> dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
> Error opening I2C controller (/dev/iic0): No such file or directory
> 
> What's missing? Thank you in advance.




===
Mark Millard
marklmi at yahoo.com


From nobody Sun Mar  6 22:18:15 2022
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 8D40F19EA59D
	for ; Sun,  6 Mar 2022 22:18:26 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KBbZn3d2tz3k8n
	for ; Sun,  6 Mar 2022 22:18:25 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by mailhost.netlabit.sk with ESMTPSA; Sun, 06 Mar 2022 23:18:17 +0100
  id 00DADC7E.62253329.0001760E
Date: Sun, 6 Mar 2022 23:18:15 +0100
From: Milan Obuch 
To: freebsd-arm@freebsd.org
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
Message-ID: <20220306231815.6ea9b3b2@zeta.dino.sk>
In-Reply-To: <20220306181231.4801A1A059FB@mlmmj.nyi.freebsd.org>
References: <20220306181231.4801A1A059FB@mlmmj.nyi.freebsd.org>
X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4)
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: 4KBbZn3d2tz3k8n
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[dino.sk];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1815
Lines: 70

On 06 Mar 2022 18:11:50 UTC
Don Kuenz  wrote:

> Greetings,
> 
> My RPi2B GPIO header connects to a PCF8574 I2C adapter with these
> pins:
> 
>     RPi2B           PCF8574
> ---------------     -------
> Pin  2 - +5VDC  <-> VCC
> Pin  3 - GPIO 2 <-> SDA
> Pin  5 - GPIO 3 <-> SCL
> Pin 39 - Gnd    <-> GND
> 
> /boot/loader.conf contains these lines:
> 
> root@generic:/boot # cat /boot/loader.conf
> # Configure USB OTG; see usb_template(4).
> hw.usb.template=3
> umodem_load="YES"
> # Disable the beastie menu and color
> beastie_disable="YES"
> loader_color="NO"
> gpioiic_load="YES"
> 
> and /boot/msdos/config.txt looks like this:
> 
> root@generic:/boot # cat /boot/msdos/config.txt
> init_uart_clock=3000000
> enable_uart=1
> kernel=u-boot.bin
> kernel7=u-boot.bin
> dtoverlay=mmc
> / {
>   gpioiic0 {
>     compatible = "i2c-gpio";
>     pinctrl-names = "default";
>     pinctrl-0 = <&pinctrl_gpioiic0>;
>     scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
>     sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
>     status = "okay";
>   };
> };
> 
> Nothing happens:
> 
> root@generic:/boot # i2c -sv
> dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
> Error opening I2C controller (/dev/iic0): No such file or directory
> 
> What's missing? Thank you in advance.
>

Hi,

could you show us what's in /dev directory? Probably no iic0 file
there. Also, you did not write which kernel are you using. For
/dev/iic0 to appear, you need either 'device iic' in your kernel config
or load it dynamically via 'kldload iic', in addition to working i2c
controller.

Showing your 'dmesg' output helps to determine what's going on, along
with DTB used as well.

All this are just basic hints what and where to look for, there are
probably other as well, but I hope this helps.

Regards,
Milan

From nobody Sun Mar  6 23:09:14 2022
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 B9F1019F6188
	for ; Sun,  6 Mar 2022 23:09:15 +0000 (UTC)
	(envelope-from mail@crcomp.net)
Received: from www18.qth.com (www18.qth.com [69.16.238.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KBcjR0bqhz3rTp
	for ; Sun,  6 Mar 2022 23:09:15 +0000 (UTC)
	(envelope-from mail@crcomp.net)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crcomp.net;
	s=default; h=References:Subject:From:To:Date:Sender:Reply-To:Message-ID:Cc:
	MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=q4fpXhtRaYaw71svzjII9dx3dkIZEftF4QBqA1IB+zQ=; b=VOGNgvt23N4cJMk1MTVonDxMPY
	4Wmng643/1Zgwj8DwDttFtiLYgEF2Iu136bjTFgeDG7pNO3BAj8oWQWo+hcS30CEiAB8+1fGFw/Iy
	1qTaomT0QRuc5eQESHG04UkiKWdCq8g9vIzjuOuJ9O1mNvZYqjbx9UCPgBku7M8wq4Y0TMePsJzte
	sAJI7ZJcw1QbQl0/Y3GZGvsVCWJXyLzZw6Y6xE+5ZvGLkjSnRv4TfmYgd4AkLskGVEF+THhNmQ7Oi
	2k9k2wGsYMMufHt7XaXNXplzV5v6EAt7Z+ZbZar6zGqWiu3mPc6yx4CKp0uKo2BTzRqoYI/S++pi5
	tCxjwujw==;
Received: from [69.146.199.132] (port=52255 helo=michael2)
	by www18.qth.com with esmtpa (Exim 4.94.2)
	(envelope-from )
	id 1nR002-00052s-AS
	for freebsd-arm@freebsd.org; Sun, 06 Mar 2022 17:09:14 -0600
Date: 06 Mar 2022 23:09:14 UTC
To: 
From: Don Kuenz 
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
References: <20220306231815.6ea9b3b2@zeta.dino.sk>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - www18.qth.com
X-AntiAbuse: Original Domain - freebsd.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - crcomp.net
X-Get-Message-Sender-Via: www18.qth.com: authenticated_id: mail@crcomp.net
X-Authenticated-Sender: www18.qth.com: mail@crcomp.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Rspamd-Queue-Id: 4KBcjR0bqhz3rTp
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=crcomp.net header.s=default header.b=VOGNgvt2;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mail@crcomp.net designates 69.16.238.59 as permitted sender) smtp.mailfrom=mail@crcomp.net
X-Spamd-Result: default: False [0.43 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:c];
	 HAS_X_SOURCE(0.00)[];
	 TO_DN_NONE(0.00)[];
	 DKIM_TRACE(0.00)[crcomp.net:+];
	 NEURAL_HAM_SHORT(-0.97)[-0.972];
	 INVALID_DATE(1.50)[];
	 HAS_X_ANTIABUSE(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[69.146.199.132:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:32244, ipnet:69.16.192.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 HAS_X_AS(0.00)[mail@crcomp.net];
	 RCVD_IN_DNSWL_LOW(-0.10)[69.16.238.59:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 R_DKIM_ALLOW(-0.20)[crcomp.net:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[crcomp.net];
	 RCPT_COUNT_ONE(0.00)[1];
	 MISSING_MID(2.50)[];
	 HAS_X_GMSV(0.00)[mail@crcomp.net];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
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
Status: O
Content-Length: 1705
Lines: 51

Milan wrote:

> could you show us what's in /dev directory? Probably no iic0 file
> there. Also, you did not write which kernel are you using. For
> /dev/iic0 to appear, you need either 'device iic' in your kernel config
> or load it dynamically via 'kldload iic', in addition to working i2c
> controller.
> 
> Showing your 'dmesg' output helps to determine what's going on, along
> with DTB used as well.
> 
> All this are just basic hints what and where to look for, there are
> probably other as well, but I hope this helps.

oot@generic:~ # dmesg | grep iic

root@generic:~ # dmesg | grep gpio
gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
gpiobus0:  on gpio0
gpioc0:  on gpio0
gpioled0:  on ofwbus0

root@generic:~ # ls /dev/iic*
ls: /dev/iic*: No such file or directory

root@generic:~ # kldload iic
kldload: can't load iic: module already loaded or in kernel

root@generic:~ # kldstat
Id Refs Address        Size Name
 1   14 0xc0000000   d6a938 kernel
 2    1 0xc0d6b000    23358 gpioiic.ko
 3    2 0xc0d8f000    23fcc iicbb.ko
 4    1 0xc0db3000    24f48 umodem.ko
 5    2 0xc0dd8000    28328 ucom.ko

FreeBSD 11.1 automatically creates /dev/iic (unsure of the suffices).
But 11.1 is now obsolete. FDT replaced automatic IIC bit-bang driver
discovery. 
    You need to "wire" FDT beforehand. Although there's hints and 
configuration snippets all over the Inet, a full blown howto example 
eludes me thus far.

Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.



From nobody Mon Mar  7 07:10:05 2022
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 EE66F19FBBFC
	for ; Mon,  7 Mar 2022 07:10:10 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KBqNK4l8Fz3JVw
	for ; Mon,  7 Mar 2022 07:10:09 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by mailhost.netlabit.sk with ESMTPSA; Mon, 07 Mar 2022 08:10:07 +0100
  id 00DADC7E.6225AFCF.000035B7
Date: Mon, 7 Mar 2022 08:10:05 +0100
From: Milan Obuch 
To: freebsd-arm@freebsd.org
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
Message-ID: <20220307081005.6a944b46@zeta.dino.sk>
In-Reply-To: <20220306230947.47F0A19F60FF@mlmmj.nyi.freebsd.org>
References: <20220306231815.6ea9b3b2@zeta.dino.sk>
	<20220306230947.47F0A19F60FF@mlmmj.nyi.freebsd.org>
X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4)
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: 4KBqNK4l8Fz3JVw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[dino.sk];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4342
Lines: 120

On 06 Mar 2022 23:09:14 UTC
Don Kuenz  wrote:

> Milan wrote:
> 
> > could you show us what's in /dev directory? Probably no iic0 file
> > there. Also, you did not write which kernel are you using. For
> > /dev/iic0 to appear, you need either 'device iic' in your kernel
> > config or load it dynamically via 'kldload iic', in addition to
> > working i2c controller.
> > 
> > Showing your 'dmesg' output helps to determine what's going on,
> > along with DTB used as well.
> > 
> > All this are just basic hints what and where to look for, there are
> > probably other as well, but I hope this helps.  
> 
> root@generic:~ # dmesg | grep iic
>

OK, this means no iic device is being detected.

> root@generic:~ # dmesg | grep gpio
> gpio0:  mem 0x7e200000-0x7e2000b3 irq
> 7,8 on simplebus0 gpiobus0:  on gpio0
> gpioc0:  on gpio0
> gpioled0:  on ofwbus0
>

So, you have GPUIO controller present, you should see what's available
to control it with 'gpioctl -lv' (it uses /dev/gpioc0, which should be
present in your system according to the dmesg snippet above).

> root@generic:~ # ls /dev/iic*
> ls: /dev/iic*: No such file or directory
>

This confirms what I wrote above, no iic device.

> root@generic:~ # kldload iic
> kldload: can't load iic: module already loaded or in kernel
>

You are probably using GENERIC kernel, judging from host name show, and
indeed, 'device iic' is present in GENERIC kernel config.

> root@generic:~ # kldstat
> Id Refs Address        Size Name
>  1   14 0xc0000000   d6a938 kernel
>  2    1 0xc0d6b000    23358 gpioiic.ko
>  3    2 0xc0d8f000    23fcc iicbb.ko
>  4    1 0xc0db3000    24f48 umodem.ko
>  5    2 0xc0dd8000    28328 ucom.ko
>

'kldstat -v' would show more details, device iic is presented as part
of kernel, most probably (again, judged from what you present).

> FreeBSD 11.1 automatically creates /dev/iic (unsure of the suffices).
> But 11.1 is now obsolete. FDT replaced automatic IIC bit-bang driver
> discovery. 
> You need to "wire" FDT beforehand. Although there's hints and 
> configuration snippets all over the Inet, a full blown howto example 
> eludes me thus far.
>

Well, I think what Mark wrote is exactly what's needed. As I did not
work with Raspberry a long time, I can't tell anything about config.txt
in /boot/msdos directory (or, in another word, in FAT partition
available for pre-FreeBSD boot loader), but I think this snippet from
your first message should not go there:

> / {
>  gpioiic0 {
>    compatible = "i2c-gpio";
>    pinctrl-names = "default";
>    pinctrl-0 = <&pinctrl_gpioiic0>;
>    scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
>    sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
>    status = "okay";
>  };
> };  

My gut feeling here is it is just being ignored because syntactically it
does not make much sense. I may be wrong here. Do you have any pointer
where you got this snipped from?

For me it would be meaningfull if you put this snippet into a file,
say, rpi2-gpioiic.dtso, use DTB compiler to create binary blob,
rpi2-gpioiic.dtbo.

I would create such an overlay by putting source file into
sys/dts/arm/overlays directory and modifying Makefile in
sys/modules/dtb/rpi directory to include rpi2-gpioiic.dtso in DTSO
variable for appropriate MACHINE_ARCH. (As I see there now, file name
should be gpioiic-rpi2.dtso to match the convention used here, but this
is functionally irrelevant.)

This way, overlay file would be created when doing 'make buildkernel'
and installed in appropriate place with 'make installkernel', but it is
possible to do just FDT overlay build, I just do not know exact
commands from my memory.

Now, when you have your overlay in /boot/dtb/overlay directory, you
need to activate it by including its name in fdt_overlays variable in
loader.conf file present in /boot directory, so there should be line
like this:

fdt_overlays="rpi2-gpioiic"

I hope this is correct and usefull for you. It's based on my experience
elsewhere, but this is what works for me on my boards, albeit not RPI
(I did not use for a long time).

Also, you can try 'ofwdump -a' command to see which devices should be
present according FDT provided to system before and after doing some
change to verify there is some effect from your changes...

Regards,
Milan

From nobody Mon Mar  7 09:05:51 2022
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 30F601A0E40C
	for ; Mon,  7 Mar 2022 09:06:15 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmse02.mailcluster.com.au (vmse02.mailcluster.com.au [IPv6:2401:fc00:0:14::6])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KBsyD0rPgz3khf
	for ; Mon,  7 Mar 2022 09:06:11 +0000 (UTC)
	(envelope-from bscott@bunyatech.com.au)
Received: from vmcp43.digitalpacific.com.au ([101.0.119.58])
	by vmse02.mailcluster.com.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128)
	(Exim 4.92)
	(envelope-from )
	id 1nR9JR-00043c-WE
	for freebsd-arm@freebsd.org; Mon, 07 Mar 2022 20:05:59 +1100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=bunyatech.com.au; s=default; h=Content-Transfer-Encoding:Content-Type:
	In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:
	Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
	List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=M86hXHJjMmnRP6i0C/j5TkwhajVN4CeB27YxUyKtey4=; b=mqXgROPbZ8oGPvyp+vObMrbmNg
	u490DjZ6JTJMOES7b/UnxfOH/3Pj+LavmPZy54ETM8iQdRaesOq3laT7Cjl/TiHs5sHpUxE0kR6MC
	o0fJjqeczx39IGiJIYQYwex3IqSV9zvMN1hiatXNdxaO2xzArHQM7xts+SRp7voERAyCQOxlQ/LQ6
	uVdEGJdlveY4uQWZT8AmEpAGx8pB0JfztOCuHhLOQx7npSgLXAp2YN65kcT00HZzhl9hooG2uZqig
	QzxDvSEcUoNDhVBTI+2h5JkB7FiRob2rN99/F0DndMRb1m0ND+uvfb+q2JV2P/uSdYEkYb07NL8WK
	74sfWUrA==;
Received: from ppp221-139.static.internode.on.net ([150.101.221.139]:65124 helo=[10.0.1.106])
	by vmcp43.digitalpacific.com.au with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from )
	id 1nR9JQ-00ARlc-EG
	for freebsd-arm@freebsd.org; Mon, 07 Mar 2022 20:05:52 +1100
Message-ID: <9f337b5a-4e2d-a52f-2b99-4af69ad4c480@bunyatech.com.au>
Date: Mon, 7 Mar 2022 20:05:51 +1100
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 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.1
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
To: freebsd-arm@freebsd.org
References: <20220306231815.6ea9b3b2@zeta.dino.sk>
 <20220306230947.47F0A19F60FF@mlmmj.nyi.freebsd.org>
 <20220307081005.6a944b46@zeta.dino.sk>
From: Brian Scott 
In-Reply-To: <20220307081005.6a944b46@zeta.dino.sk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-User: bscott@bunyatech.com.au
X-Authenticator: dovecot_plain
X-Originating-IP: 101.0.119.58
X-SpamExperts-Domain: digipac-sh-outbound4.mailcluster.com.au
X-SpamExperts-Username: 101.0.119.58
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8qccNshak6bP+lE4mnXPu7PUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wOvGg18h18lTsuUGH1KgAagLCWYuPCxwJEfxKP87A95+fH
 zJ6mVE7ewsipSVIfs4ant3M5SOrMD66a/rUMFbM1ABHVTw1lV42ob3hDgXVUNfMYOaf2k/5ge9xY
 pFnK4mEZANNbnYFKmAzb4T8ZHiCK+gaXrHkgRC7/tI3CjXmVyi5YMqHAB0TkAjcnlD6a+24p8Gnm
 YnDDwZLHsvD3pj+L6BZl9UDn9FWH/+ul8XIFmIj/3DdQ0wDV188+gffZv/QAKQlQdTfwbSciar+2
 JCMst0dEunmtVTQWqR0MJGYnYGBIZS4rRgm1GD0QN7Psq7kMoOLjGsRz/MUE6aIZoCcUNXR4aVG4
 tVHU1Zldyy+zfdeiXSYiLTYFU2inszSuEYHdlUkt/DWy8vGLtXVYC5E2Ixfs2qKc0fhF4YMd0lwH
 wOXyY7DGIntSiB4r6Kj1fsj0vv0lYcA3KUCZ1xbWKiooCEhtIlNufemFbU3yy1ZWIMOHTNjJsV8U
 ZvUGC4qEZBLXzXmHaN80JC+nfH561Te/6BtpbmdpMLvM58ZB4GVvZfvg7iEFLP+SSY+Av5+AiC64
 m+k59xMAqz9bfz2u3IufmfuEJ6TSseKIGzVAoa+NyF7C8zTp0kl0lFSxyO0ulzPF4DEPUxAkEvKE
 S3Dwga/K50QJEfuYSa1oqImpgX99qcen5bW2mj7gpl+Nel82aV6t85jdQ1W7xM52M4KvSDibnd+2
 AEC7XXwrqk2mM9pO7yAC7PGX5cs6w1Q8AODFgbts0gQX4rIW1Nbeh11ZApSg4V4L815FITqV6Ht9
 qDMOGVz1pRXWhjh9fdbl44I0Df0hM4dsD4bDwITFGCwK76hQ6vxPb3kvW+FOj8dHBAEnPnyse24r
 Z04BTGPuKCWPMdaEOqqgRFGeEt6xotIlx57hKeDIpVo9Y8swg9vllynHi7u2NJscbLjsBWgbQir3
 s7IISG0iU2596YVtTfLLVlYg24YpMwV2Qj6zr+H1W4fdfycpg/800vALz8mnE6wA706qGokY7okO
 g7HJIt1nJKmB0MxOKVrDfQzDgqFDumjx9w03a6SLNhJ6Q12/4jZa7jE=
X-Report-Abuse-To: spam@vmse01.mailcluster.com.au
X-Rspamd-Queue-Id: 4KBsyD0rPgz3khf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bunyatech.com.au header.s=default header.b=mqXgROPb;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bscott@bunyatech.com.au designates 2401:fc00:0:14::6 as permitted sender) smtp.mailfrom=bscott@bunyatech.com.au
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bunyatech.com.au:s=default];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[bunyatech.com.au];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[bunyatech.com.au:+];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:55803, ipnet:2401:fc00::/32, country:AU];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5344
Lines: 137

On 7/3/22 6:10 pm, Milan Obuch wrote:
> On 06 Mar 2022 23:09:14 UTC
> Don Kuenz  wrote:
>
>> Milan wrote:
>>
>>> could you show us what's in /dev directory? Probably no iic0 file
>>> there. Also, you did not write which kernel are you using. For
>>> /dev/iic0 to appear, you need either 'device iic' in your kernel
>>> config or load it dynamically via 'kldload iic', in addition to
>>> working i2c controller.
>>>
>>> Showing your 'dmesg' output helps to determine what's going on,
>>> along with DTB used as well.
>>>
>>> All this are just basic hints what and where to look for, there are
>>> probably other as well, but I hope this helps.
>> root@generic:~ # dmesg | grep iic
>>
> OK, this means no iic device is being detected.
>
>> root@generic:~ # dmesg | grep gpio
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq
>> 7,8 on simplebus0 gpiobus0:  on gpio0
>> gpioc0:  on gpio0
>> gpioled0:  on ofwbus0
>>
> So, you have GPUIO controller present, you should see what's available
> to control it with 'gpioctl -lv' (it uses /dev/gpioc0, which should be
> present in your system according to the dmesg snippet above).
>
>> root@generic:~ # ls /dev/iic*
>> ls: /dev/iic*: No such file or directory
>>
> This confirms what I wrote above, no iic device.
>
>> root@generic:~ # kldload iic
>> kldload: can't load iic: module already loaded or in kernel
>>
> You are probably using GENERIC kernel, judging from host name show, and
> indeed, 'device iic' is present in GENERIC kernel config.
>
>> root@generic:~ # kldstat
>> Id Refs Address        Size Name
>>   1   14 0xc0000000   d6a938 kernel
>>   2    1 0xc0d6b000    23358 gpioiic.ko
>>   3    2 0xc0d8f000    23fcc iicbb.ko
>>   4    1 0xc0db3000    24f48 umodem.ko
>>   5    2 0xc0dd8000    28328 ucom.ko
>>
> 'kldstat -v' would show more details, device iic is presented as part
> of kernel, most probably (again, judged from what you present).
>
>> FreeBSD 11.1 automatically creates /dev/iic (unsure of the suffices).
>> But 11.1 is now obsolete. FDT replaced automatic IIC bit-bang driver
>> discovery.
>> You need to "wire" FDT beforehand. Although there's hints and
>> configuration snippets all over the Inet, a full blown howto example
>> eludes me thus far.
>>
> Well, I think what Mark wrote is exactly what's needed. As I did not
> work with Raspberry a long time, I can't tell anything about config.txt
> in /boot/msdos directory (or, in another word, in FAT partition
> available for pre-FreeBSD boot loader), but I think this snippet from
> your first message should not go there:
>
>> / {
>>   gpioiic0 {
>>     compatible = "i2c-gpio";
>>     pinctrl-names = "default";
>>     pinctrl-0 = <&pinctrl_gpioiic0>;
>>     scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
>>     sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
>>     status = "okay";
>>   };
>> };
> My gut feeling here is it is just being ignored because syntactically it
> does not make much sense. I may be wrong here. Do you have any pointer
> where you got this snipped from?
>
> For me it would be meaningfull if you put this snippet into a file,
> say, rpi2-gpioiic.dtso, use DTB compiler to create binary blob,
> rpi2-gpioiic.dtbo.
>
> I would create such an overlay by putting source file into
> sys/dts/arm/overlays directory and modifying Makefile in
> sys/modules/dtb/rpi directory to include rpi2-gpioiic.dtso in DTSO
> variable for appropriate MACHINE_ARCH. (As I see there now, file name
> should be gpioiic-rpi2.dtso to match the convention used here, but this
> is functionally irrelevant.)
>
> This way, overlay file would be created when doing 'make buildkernel'
> and installed in appropriate place with 'make installkernel', but it is
> possible to do just FDT overlay build, I just do not know exact
> commands from my memory.
>
> Now, when you have your overlay in /boot/dtb/overlay directory, you
> need to activate it by including its name in fdt_overlays variable in
> loader.conf file present in /boot directory, so there should be line
> like this:
>
> fdt_overlays="rpi2-gpioiic"
>
> I hope this is correct and usefull for you. It's based on my experience
> elsewhere, but this is what works for me on my boards, albeit not RPI
> (I did not use for a long time).
>
> Also, you can try 'ofwdump -a' command to see which devices should be
> present according FDT provided to system before and after doing some
> change to verify there is some effect from your changes...
>
> Regards,
> Milan
>
I think I'm like most people here, trying to guess what you are wanting 
to achieve. Pins 2 and 3 are already avalable as iic1 provided you include:

dtparam=i2c_arm

in your config.txt file. There's a little more magic needed on the rpi4 
but that doesn't effect you.

Pin 3 (GPIO 2) is SDA and Pin 5 (GPIO 3) is SCL. This 'seems' to be the 
opposite of what you are doing in your dts snippet so I could be wrong, 
but I would have thought these functions would be hardwired in the SOC.

As for your specific device, PCF8574; I don't have any direct experience 
but it looks like a standard IIC device that should work OK. I see there 
is a FreeBSD kernel module to support it but it is quite recent so 
probably only in CURRENT. As I said, I don't have experience with that 
particular device.

Hope this helps,


Brian


From nobody Mon Mar  7 10:38:59 2022
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 EB43819FDE01;
	Mon,  7 Mar 2022 10:39:03 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KBw1L53S7z3sbn;
	Mon,  7 Mar 2022 10:39:02 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 7 Mar 2022 11:38:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1646649539;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=+qQZYHdB3YNrYW6YzD6SgwhJkJg6yyGjGAPj2WC58aE=;
	b=bpEOvOrCbEoRyPHrp/lk8ojpayCo+NS/oLWUlUbadR+pgAnyYovx5lSh0KSctQsZhNs71D
	t6Nsmg0LmZamQcZEGj9GfYwgHbOQ6Fd6Bf3KEbUABX+OCz7YpUdD0e6+luDljMEw0eZ74F
	9TXQ8klZWK2AKiYDyJMefhXl9HcCWc9lB3/P9rDPt+Wf6HlwiSbAL4FOhKKjb7fETRuVJe
	m1IgAa6fF59ci8zDtxyzfWOzcE8hC2ff0R8uZhi+Xi4J6dogTubYwFDq2xWNkMq21odRK5
	wbcD277oDjJaew3c92VIdWi+0Wd/tNJB9KZsPXxXbUTVkKLlGZ0Df3n8J6j2Pw==
From: Ronald Klop 
To: Mark Millard 
Cc: bob prohaska ,
	freebsd-current ,
	freebsd-arm@freebsd.org
Message-ID: <1800459695.1.1646649539521@mailrelay>
In-Reply-To: 
References: 
 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64
 Feb 28))
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="----=_Part_0_597764175.1646649539431"
X-Mailer: Realworks (599.211.aa1e011)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KBw1L53S7z3sbn
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=bpEOvOrC;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl"
X-Spamd-Result: default: False [-3.15 / 15.00];
	 ARC_NA(0.00)[];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.95)[-0.953];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 47586
Lines: 857

------=_Part_0_597764175.1646649539431
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Yes, I spoke to soon too. Often it crashes as soon as I start a parallel po=
udriere build. But this time it went very far. As soon as nightly backups k=
icked in it was game over again.
I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusi=
on that it is about the same problem to the developers. (Have seen enough o=
f wrong guessing of causes in my work. =F0=9F=98=89)

I will need to go further into the binary search of working kernels.

This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 2022
Fatal data abort:                                                          =
                                                        =20
  x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_polic=
y_rm + 0)                                               =20
                                                                           =
                                                        =20
  x1:                2  x1:                2                               =
                                                        =20
                                                                           =
                                                        =20
  x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + 2f28a)    =
                                                        =20
 (cam_status_table + 2f28a)  x3: ffff00000087dcf2                          =
                                                        =20
  x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a=
)                                                       =20
                                                                           =
                                                        =20
  x4:              102  x4:              102                               =
                                                        =20
                                                                           =
                                                        =20
  x5:                7  x5:                1                               =
                                                        =20
                                                                           =
                                                        =20
  x6:                0  x6:               ff                               =
                                                        =20
                                                                           =
                                                        =20
  x7:                0  x7: ffffa00011fc2800                               =
                                                        =20
  x8:                1                                                     =
                                                        =20
                                                                           =
                                                        =20
  x8:                1  x9: ffff000000f37c10                               =
                                                        =20
  x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)                     =
                                                        =20
                                                                           =
                                                        =20
 x10: ffffa0017be2a600 x10: ffffa000010fa600                               =
                                                        =20
 x11: 394aed08d0003a48                                                     =
                                                        =20
                                                                           =
                                                        =20
 x12: 350001a8b946a108 x11:                0                               =
                                                        =20
                                                                           =
                                                        =20
 x12: ffff000000f37c10 x13:         badecce4 (pcpu0 + 90)                  =
                                                        =20
                                                                           =
                                                        =20
 x13: ffffa0001fbde6b0 x14:                0                               =
                                                        =20
                                                                           =
                                                        =20
 x14:         4965ae49 x15:                1                               =
                                                        =20
                                                                           =
                                                        =20
 x15:          1000193 x16: ffff0000016a4238                               =
                                                        =20
 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modme=
tadata_set + 448)                                       =20
                                                                           =
                                                        =20
 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0=
)                                                       =20
                                                                           =
                                                        =20
 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314)            =
                                                        =20
 (next_index + 3a228c0) x19:              102                              =
                                                        =20

                                                                           =
                                                       =20
 x19:              102 x20: ffff0000b49a2428                               =
                                                        =20
 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)           =
                                                        =20

 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (ca=
m_status_table + 2f28a)

 x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_polic=
y_rm + 0)

 x23: ffff00000086f107 x23:                0 (cam_status_table + 2069f)

 x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
 x25:                0

 x25: ffff00000088aa11 x26:                4 (do_execve.fexecv_proc_title +=
 76b7)

 x27:                0 x26: ffffa0017be2a600
 x28: ffff00010209fcf0
 x27: ffffa00025626a80 (next_index + 1bb0a30)

 x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx =
+ b3242334)

 x29: ffff000103f11ba0  sp: ffff0000b49a23c0
 (next_index + 3a228e0)  lr: ffff00000046ef98
  sp: ffff000103f11b80
 (_rm_runlock_debug + 60)  lr: ffff00000046ef98
 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

 elr: ffff00000046dc0cspsr:               45
 (_rm_assert + a4) far:               10

 esr:         96000004
spsr:               45

panic: data abort in critical section or under mutex
cpuid =3D 1
time =3D 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>

NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi c=
onnected power switch on it.

Regards,
Ronald.

=20
Van: Mark Millard 
Datum: maandag, 7 maart 2022 02:01
Aan: Ronald Klop 
CC: freebsd-current , bob prohaska 
Onderwerp: Re: panic: data abort in critical section or under mutex (was: R=
e: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64=
 Feb 28))
>=20
> From: Ronald Klop  wrote on
> Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :
>=20
> > Did some binary search with kernels from artifact.ci.freebsd.org.
> >
> > I suspect "rmlock: Micro-optimize read locking" as cause.
> >
> > https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32d=
da470bef23a
> >
> >
> > And "rmlock: Add required compiler barriers to _rm_runlock()" as soluti=
on.
> >
> > https://cgit.freebsd.org/src/commit/?id=3D89ae8eb74e87ac19aa2d7abe4ba16=
bcccd32bb9f
> >
> >
> > So I probably just had a bad day.
>=20
> Well, there is a report of a buildkernel crash after that pair:
>=20
> https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html
>=20
> that references additional information at:
>=20
> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
>=20
> and reported:
>=20
> QUOTE
> The console connection dropped before the crash (unrelated) I didn't
> get the preamble, all  I have is the backtrace and buildkernel log.
> Here's the backtrace:
> db> bt
> Tracing pid 14795 tid 100098 td 0xffffa00017815600
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x368
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1cc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1b0
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
> sysctl_root() at sysctl_root+0x1ac
> userland_sysctl() at userland_sysctl+0x140
> sys___sysctl() at sys___sysctl+0x68
> do_el0_sync() at do_el0_sync+0x520
> handle_el0_sync() at handle_el0_sync+0x40
> --- exception, esr 0x56000000
> END QUOTE
>=20
> The above material does reference _rm_rlock_debug . Might be
> related?
>=20
> The readme reports:
>=20
> main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022
>=20
> for the system doing the buildkernel. This is after
> 89ae8eb74e8 .
>=20
> (It also mentions another panic earlier in the week,
> apparently not reported to the lists at the time.)
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> =20
>=20
>=20
>=20
------=_Part_0_597764175.1646649539431
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes, I spoke to soon too. Often it crashes as soon=
 as I start a parallel poudriere build. But this time it went very far. As =
soon as nightly backups kicked in it was game over again.

I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusi=
on that it is about the same problem to the developers. (Have seen enough o=
f wrong guessing of causes in my work. =F0=9F=98=89)



I will need to go further into the binary search of working kernels.



This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 202=
2

Fatal data abort:         &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
  x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) =
(mac_policy_rm + 0)         &n=
bsp;            =
;            &n=
bsp;            &nbs=
p;
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x1:           =
;     2  x1:      &n=
bsp;         2   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + =
2f28a)           &nb=
sp;            =
            &nb=
sp;            =
            
 (cam_status_table + 2f28a)  x3: ffff00000087dcf2  &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
  x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + =
2f28a)           &nb=
sp;            =
            &nb=
sp;            =
       
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x4:           =
;   102  x4:        =
      102       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x5:           =
;     7  x5:      &n=
bsp;         1   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x6:           =
;     0  x6:      &n=
bsp;        ff    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x7:           =
;     0  x7: ffffa00011fc2800   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
  x8:           =
;     1        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x8:           =
;     1  x9: ffff000000f37c10   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
  x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)  &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;            
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x10: ffffa0017be2a600 x10: ffffa000010fa600    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
 x11: 394aed08d0003a48        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x12: 350001a8b946a108 x11:       &=
nbsp;        0    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x12: ffff000000f37c10 x13:       &=
nbsp; badecce4 (pcpu0 + 90)        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;    
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x13: ffffa0001fbde6b0 x14:       &=
nbsp;        0    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x14:         4965ae49 x15:&nb=
sp;            =
   1          &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x15:          1000193 x1=
6: ffff0000016a4238         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   
 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_=
modmetadata_set + 448)         =
;            &n=
bsp;            =
;      
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counte=
r + 0)           &nb=
sp;            =
            &nb=
sp;            =
       
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314) &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
 (next_index + 3a228c0) x19:       =
       102      =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      

            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
      
 x19:           =
;   102 x20: ffff0000b49a2428      =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928) =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;    

 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a=
) (cam_status_table + 2f28a)

 x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_=
policy_rm + 0)

 x23: ffff00000086f107 x23:       &=
nbsp;        0 (cam_status_table + 2069f=
)

 x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
 x25:           =
;     0

 x25: ffff00000088aa11 x26:       &=
nbsp;        4 (do_execve.fexecv_proc_ti=
tle + 76b7)

 x27:           =
;     0 x26: ffffa0017be2a600
 x28: ffff00010209fcf0
 x27: ffffa00025626a80 (next_index + 1bb0a30)

 x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g=
_ctx + b3242334)

 x29: ffff000103f11ba0  sp: ffff0000b49a23c0
 (next_index + 3a228e0)  lr: ffff00000046ef98
  sp: ffff000103f11b80
 (_rm_runlock_debug + 60)  lr: ffff00000046ef98
 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

 elr: ffff00000046dc0cspsr:       &=
nbsp;       45
 (_rm_assert + a4) far:        =
;       10

 esr:         96000004
spsr:           &nbs=
p;   45

panic: data abort in critical section or under mutex
cpuid =3D 1
time =3D 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at      kdb_enter+0x44: undefined &nb=
sp;     f902011f
db>




NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wif=
i connected power switch on it.



Regards,

Ronald.



 

Van: Mark Millard <marklmi@yahoo.com>

Datum: maandag, 7 maart 2022 02:01

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: freebsd-current <freebsd-current@freebsd.org>, b=
ob prohaska <fbsd@www.zefox.net>

Onderwerp: Re: panic: data abort in critical section or un=
der mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 1=
4-CURRENT/aarch64 Feb 28))







From: Ronald Klop <ronald-list=
s_at_klop.ws> wrote on

Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :



> Did some binary search with kernels from artifact.ci.freebsd.org.

>

> I suspect "rmlock: Micro-optimize read locking" as cause.
>

> https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd=
771ce4bed58152e47a32dda470bef23a

>

>

> And "rmlock: Add required compiler barriers to _rm_runlock()"=
; as solution.

>

> https://cgit.freebsd.org/src/commit/?id=3D89ae8eb7=
4e87ac19aa2d7abe4ba16bcccd32bb9f

>

>

> So I probably just had a bad day.



Well, there is a report of a buildkernel crash after that pair:



https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.htm=
l



that references additional information at:



http://=
www.zefox.net/~fbsd/rpi3/crashes/20220304/readme



and reported:



QUOTE

The console connection dropped before the crash (unrelated) I didn't

get the preamble, all  I have is the backtrace and buildkernel log.
Here's the backtrace:

db> bt

Tracing pid 14795 tid 100098 td 0xffffa00017815600

db_trace_self() at db_trace_self

db_stack_trace() at db_stack_trace+0x11c

db_command() at db_command+0x368

db_command_loop() at db_command_loop+0x54

db_trap() at db_trap+0xf8

kdb_trap() at kdb_trap+0x1cc

handle_el1h_sync() at handle_el1h_sync+0x10

--- exception, esr 0xf2000000

kdb_enter() at kdb_enter+0x44

vpanic() at vpanic+0x1b0

panic() at panic+0x44

data_abort() at data_abort+0x2e8

handle_el1h_sync() at handle_el1h_sync+0x10

--- exception, esr 0x96000004

_rm_rlock_debug() at _rm_rlock_debug+0x8c

sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140

sysctl_root() at sysctl_root+0x1ac

userland_sysctl() at userland_sysctl+0x140

sys___sysctl() at sys___sysctl+0x68

do_el0_sync() at do_el0_sync+0x520

handle_el0_sync() at handle_el0_sync+0x40

--- exception, esr 0x56000000

END QUOTE



The above material does reference _rm_rlock_debug . Might be

related?



The readme reports:



main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022



for the system doing the buildkernel. This is after

89ae8eb74e8 .



(It also mentions another panic earlier in the week,

apparently not reported to the lists at the time.)



=3D=3D=3D

Mark Millard

marklmi at yahoo.com

 






------=_Part_0_597764175.1646649539431--

From nobody Mon Mar  7 13:46:09 2022
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 8B93519FCB88;
	Mon,  7 Mar 2022 13:46:13 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KC09J2yY3z4vRp;
	Mon,  7 Mar 2022 13:46:12 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 7 Mar 2022 14:46:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1646660769;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=loPRI9HeODZSw7f9ycpQAjFrmToqcGoe6XqdEdwAgNg=;
	b=br12TzQSUvGpgQR9Z56F/OEV88yVvYb0RON3JDglBicovXSf9SBAA7RCVbWEY/GeCAUKRC
	MBpIMHtDqYhU6Jvb5GZWlqm6cM6U+vC+rTv5sgf1gWWHyxKTJ+jMskmAe6vwzlpM7NZiNH
	I4tEFDLeDOsxvi5O2sAaNH3ELc4QW2oRjbVTmrYN7vr+XJxrATmCWFTDCyTMJgHFmRCTa7
	aTP6mP36eiydAFa297epEo9GHPNTK2xKBubYuY9uav3JexxW8yAu5LDS17zlfl9Iz5hMXw
	9lMspIzK3ZmdeQRLwfmJNCxmjadskrQnOYJO259Hu2PP9ArhhPFFxgi9qa/JBQ==
From: Ronald Klop 
To: Mark Johnston 
Cc: bob prohaska , Mark Millard ,
	freebsd-arm@freebsd.org,
	freebsd-current 
Message-ID: <132978150.92.1646660769467@mailrelay>
In-Reply-To: <1800459695.1.1646649539521@mailrelay>
References: 
 
 <1800459695.1.1646649539521@mailrelay>
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64
 Feb 28))
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="----=_Part_91_1813909039.1646660769454"
X-Mailer: Realworks (599.211.aa1e011)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KC09J2yY3z4vRp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=br12TzQS;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl"
X-Spamd-Result: default: False [-3.18 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.98)[-0.978];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl];
	 FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 50968
Lines: 511

------=_Part_91_1813909039.1646660769454
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear Mark Johnston,

I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.

I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.

Last panic:

panic: vm_fault failed: ffff00000046e708 error 1
cpuid = 1
time = 1646660058
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_rlock_debug() at _rm_rlock_debug+0x8c
osd_get() at osd_get+0x5c
zio_execute() at zio_execute+0xf8
taskqueue_run_locked() at taskqueue_run_locked+0x178
taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>

A more recent kernel (912df91) still panics. See below.

Do you have time to look into this? What can I provide in information to help?

Regards,
Ronald.

 
Van: Ronald Klop 
Datum: maandag, 7 maart 2022 11:38
Aan: Mark Millard 
CC: bob prohaska , freebsd-current , freebsd-arm@freebsd.org
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))
> 
> Yes, I spoke to soon too. Often it crashes as soon as I start a parallel poudriere build. But this time it went very far. As soon as nightly backups kicked in it was game over again.
> I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion that it is about the same problem to the developers. (Have seen enough of wrong guessing of causes in my work. )
> 
> I will need to go further into the binary search of working kernels.
> 
> This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 2022
> Fatal data abort:                                                                                                                   
>   x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)                                                
>                                                                                                                                     
>   x1:                2  x1:                2                                                                                        
>                                                                                                                                     
>   x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + 2f28a)                                                             
>  (cam_status_table + 2f28a)  x3: ffff00000087dcf2                                                                                   
>   x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)                                                        
>                                                                                                                                     
>   x4:              102  x4:              102                                                                                        
>                                                                                                                                     
>   x5:                7  x5:                1                                                                                        
>                                                                                                                                     
>   x6:                0  x6:               ff                                                                                        
>                                                                                                                                     
>   x7:                0  x7: ffffa00011fc2800                                                                                        
>   x8:                1                                                                                                              
>                                                                                                                                     
>   x8:                1  x9: ffff000000f37c10                                                                                        
>   x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)                                                                              
>                                                                                                                                     
>  x10: ffffa0017be2a600 x10: ffffa000010fa600                                                                                        
>  x11: 394aed08d0003a48                                                                                                              
>                                                                                                                                     
>  x12: 350001a8b946a108 x11:                0                                                                                        
>                                                                                                                                     
>  x12: ffff000000f37c10 x13:         badecce4 (pcpu0 + 90)                                                                           
>                                                                                                                                     
>  x13: ffffa0001fbde6b0 x14:                0                                                                                        
>                                                                                                                                     
>  x14:         4965ae49 x15:                1                                                                                        
>                                                                                                                                     
>  x15:          1000193 x16: ffff0000016a4238                                                                                        
>  x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modmetadata_set + 448)                                        
>                                                                                                                                     
>  x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0)                                                        
>                                                                                                                                     
>  x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314)                                                                     
>  (next_index + 3a228c0) x19:              102                                                                                       
> 
>                                                                                                                                    
>  x19:              102 x20: ffff0000b49a2428                                                                                        
>  x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)                                                                    
> 
>  x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)
> 
>  x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)
> 
>  x23: ffff00000086f107 x23:                0 (cam_status_table + 2069f)
> 
>  x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
>  x25:                0
> 
>  x25: ffff00000088aa11 x26:                4 (do_execve.fexecv_proc_title + 76b7)
> 
>  x27:                0 x26: ffffa0017be2a600
>  x28: ffff00010209fcf0
>  x27: ffffa00025626a80 (next_index + 1bb0a30)
> 
>  x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx + b3242334)
> 
>  x29: ffff000103f11ba0  sp: ffff0000b49a23c0
>  (next_index + 3a228e0)  lr: ffff00000046ef98
>   sp: ffff000103f11b80
>  (_rm_runlock_debug + 60)  lr: ffff00000046ef98
>  elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)
> 
>  elr: ffff00000046dc0cspsr:               45
>  (_rm_assert + a4) far:               10
> 
>  esr:         96000004
> spsr:               45
> 
> panic: data abort in critical section or under mutex
> cpuid = 1
> time = 1646609483
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2d4
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_assert() at _rm_assert+0xa4
> _rm_runlock_debug() at _rm_runlock_debug+0x5c
> mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
> tcp_input_with_port() at tcp_input_with_port+0xab4
> tcp_input() at tcp_input+0xc
> ip_input() at ip_input+0x2e8
> netisr_dispatch_src() at netisr_dispatch_src+0xe4
> ether_demux() at ether_demux+0x178
> ether_nh_input() at ether_nh_input+0x3e8
> netisr_dispatch_src() at netisr_dispatch_src+0xe4
> ether_input() at ether_input+0x80
> if_input() at if_input+0xc
> gen_intr() at gen_intr+0x444
> ithread_loop() at ithread_loop+0x2a0
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 12 tid 100063 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db>
> 
> NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi connected power switch on it.
> 
> Regards,
> Ronald.
> 
>  
> Van: Mark Millard 
> Datum: maandag, 7 maart 2022 02:01
> Aan: Ronald Klop 
> CC: freebsd-current , bob prohaska 
> Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))
>> 
>> From: Ronald Klop  wrote on
>> Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :
>> 
>> > Did some binary search with kernels from artifact.ci.freebsd.org.
>> >
>> > I suspect "rmlock: Micro-optimize read locking" as cause.
>> >
>> > https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a
>> >
>> >
>> > And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.
>> >
>> > https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f
>> >
>> >
>> > So I probably just had a bad day.
>> 
>> Well, there is a report of a buildkernel crash after that pair:
>> 
>> https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html
>> 
>> that references additional information at:
>> 
>> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
>> 
>> and reported:
>> 
>> QUOTE
>> The console connection dropped before the crash (unrelated) I didn't
>> get the preamble, all  I have is the backtrace and buildkernel log.
>> Here's the backtrace:
>> db> bt
>> Tracing pid 14795 tid 100098 td 0xffffa00017815600
>> db_trace_self() at db_trace_self
>> db_stack_trace() at db_stack_trace+0x11c
>> db_command() at db_command+0x368
>> db_command_loop() at db_command_loop+0x54
>> db_trap() at db_trap+0xf8
>> kdb_trap() at kdb_trap+0x1cc
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0xf2000000
>> kdb_enter() at kdb_enter+0x44
>> vpanic() at vpanic+0x1b0
>> panic() at panic+0x44
>> data_abort() at data_abort+0x2e8
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0x96000004
>> _rm_rlock_debug() at _rm_rlock_debug+0x8c
>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
>> sysctl_root() at sysctl_root+0x1ac
>> userland_sysctl() at userland_sysctl+0x140
>> sys___sysctl() at sys___sysctl+0x68
>> do_el0_sync() at do_el0_sync+0x520
>> handle_el0_sync() at handle_el0_sync+0x40
>> --- exception, esr 0x56000000
>> END QUOTE
>> 
>> The above material does reference _rm_rlock_debug . Might be
>> related?
>> 
>> The readme reports:
>> 
>> main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022
>> 
>> for the system doing the buildkernel. This is after
>> 89ae8eb74e8 .
>> 
>> (It also mentions another panic earlier in the week,
>> apparently not reported to the lists at the time.)
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>  
>> 
>> 
>> 
> 
------=_Part_91_1813909039.1646660769454
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Mark Johnston,



I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.



I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.



Last panic:



panic: vm_fault failed: ffff00000046e708 error 1

cpuid = 1

time = 1646660058

KDB: stack backtrace:

db_trace_self() at db_trace_self

db_trace_self_wrapper() at db_trace_self_wrapper+0x30

vpanic() at vpanic+0x174

panic() at panic+0x44

data_abort() at data_abort+0x2e8

handle_el1h_sync() at handle_el1h_sync+0x10

--- exception, esr 0x96000004

_rm_rlock_debug() at _rm_rlock_debug+0x8c

osd_get() at osd_get+0x5c

zio_execute() at zio_execute+0xf8

taskqueue_run_locked() at taskqueue_run_locked+0x178

taskqueue_thread_loop() at taskqueue_thread_loop+0xc8

fork_exit() at fork_exit+0x74

fork_trampoline() at fork_trampoline+0x14

KDB: enter: panic

[ thread pid 0 tid 100129 ]

Stopped at      kdb_enter+0x44: undefined       f902011f

db>



A more recent kernel (912df91) still panics. See below.



Do you have time to look into this? What can I provide in information to help?



Regards,

Ronald.



 

Van: Ronald Klop <ronald-lists@klop.ws>

Datum: maandag, 7 maart 2022 11:38

Aan: Mark Millard <marklmi@yahoo.com>

CC: bob prohaska <fbsd@www.zefox.net>, freebsd-current <freebsd-current@freebsd.org>, freebsd-arm@freebsd.org

Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))









Yes, I spoke to soon too. Often it crashes as soon as I start a parallel poudriere build. But this time it went very far. As soon as nightly backups kicked in it was game over again.

I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion that it is about the same problem to the developers. (Have seen enough of wrong guessing of causes in my work. )



I will need to go further into the binary search of working kernels.



This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 2022

Fatal data abort:                                                                                                                   
  x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)                                                
                                                                                                                                    
  x1:                2  x1:                2                                                                                        
                                                                                                                                    
  x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + 2f28a)                                                             
 (cam_status_table + 2f28a)  x3: ffff00000087dcf2                                                                                   
  x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)                                                        
                                                                                                                                    
  x4:              102  x4:              102                                                                                        
                                                                                                                                    
  x5:                7  x5:                1                                                                                        
                                                                                                                                    
  x6:                0  x6:               ff                                                                                        
                                                                                                                                    
  x7:                0  x7: ffffa00011fc2800                                                                                        
  x8:                1                                                                                                              
                                                                                                                                    
  x8:                1  x9: ffff000000f37c10                                                                                        
  x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)                                                                              
                                                                                                                                    
 x10: ffffa0017be2a600 x10: ffffa000010fa600                                                                                        
 x11: 394aed08d0003a48                                                                                                              
                                                                                                                                    
 x12: 350001a8b946a108 x11:                0                                                                                        
                                                                                                                                    
 x12: ffff000000f37c10 x13:         badecce4 (pcpu0 + 90)                                                                           
                                                                                                                                    
 x13: ffffa0001fbde6b0 x14:                0                                                                                        
                                                                                                                                    
 x14:         4965ae49 x15:                1                                                                                        
                                                                                                                                    
 x15:          1000193 x16: ffff0000016a4238                                                                                        
 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modmetadata_set + 448)                                        
                                                                                                                                    
 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0)                                                        
                                                                                                                                    
 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314)                                                                     
 (next_index + 3a228c0) x19:              102                                                                                       

                                                                                                                                   
 x19:              102 x20: ffff0000b49a2428                                                                                        
 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)                                                                    

 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)

 x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)

 x23: ffff00000086f107 x23:                0 (cam_status_table + 2069f)

 x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
 x25:                0

 x25: ffff00000088aa11 x26:                4 (do_execve.fexecv_proc_title + 76b7)

 x27:                0 x26: ffffa0017be2a600
 x28: ffff00010209fcf0
 x27: ffffa00025626a80 (next_index + 1bb0a30)

 x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx + b3242334)

 x29: ffff000103f11ba0  sp: ffff0000b49a23c0
 (next_index + 3a228e0)  lr: ffff00000046ef98
  sp: ffff000103f11b80
 (_rm_runlock_debug + 60)  lr: ffff00000046ef98
 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

 elr: ffff00000046dc0cspsr:               45
 (_rm_assert + a4) far:               10

 esr:         96000004
spsr:               45

panic: data abort in critical section or under mutex
cpuid = 1
time = 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>




NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi connected power switch on it.



Regards,

Ronald.



 

Van: Mark Millard <marklmi@yahoo.com>

Datum: maandag, 7 maart 2022 02:01

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: freebsd-current <freebsd-current@freebsd.org>, bob prohaska <fbsd@www.zefox.net>

Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))







From: Ronald Klop <ronald-lists_at_klop.ws> wrote on

Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :



> Did some binary search with kernels from artifact.ci.freebsd.org.

>

> I suspect "rmlock: Micro-optimize read locking" as cause.

>

> https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a

>

>

> And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.

>

> https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f

>

>

> So I probably just had a bad day.



Well, there is a report of a buildkernel crash after that pair:



https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html



that references additional information at:



http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme



and reported:



QUOTE

The console connection dropped before the crash (unrelated) I didn't

get the preamble, all  I have is the backtrace and buildkernel log.

Here's the backtrace:

db> bt

Tracing pid 14795 tid 100098 td 0xffffa00017815600

db_trace_self() at db_trace_self

db_stack_trace() at db_stack_trace+0x11c

db_command() at db_command+0x368

db_command_loop() at db_command_loop+0x54

db_trap() at db_trap+0xf8

kdb_trap() at kdb_trap+0x1cc

handle_el1h_sync() at handle_el1h_sync+0x10

--- exception, esr 0xf2000000

kdb_enter() at kdb_enter+0x44

vpanic() at vpanic+0x1b0

panic() at panic+0x44

data_abort() at data_abort+0x2e8

handle_el1h_sync() at handle_el1h_sync+0x10

--- exception, esr 0x96000004

_rm_rlock_debug() at _rm_rlock_debug+0x8c

sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140

sysctl_root() at sysctl_root+0x1ac

userland_sysctl() at userland_sysctl+0x140

sys___sysctl() at sys___sysctl+0x68

do_el0_sync() at do_el0_sync+0x520

handle_el0_sync() at handle_el0_sync+0x40

--- exception, esr 0x56000000

END QUOTE



The above material does reference _rm_rlock_debug . Might be

related?



The readme reports:



main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022



for the system doing the buildkernel. This is after

89ae8eb74e8 .



(It also mentions another panic earlier in the week,

apparently not reported to the lists at the time.)



===

Mark Millard

marklmi at yahoo.com

 














------=_Part_91_1813909039.1646660769454--

From nobody Mon Mar  7 14:37:46 2022
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 6F2651A09404
	for ; Mon,  7 Mar 2022 14:37:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KC1Jz4jfMz3MvQ
	for ; Mon,  7 Mar 2022 14:37:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646663868; bh=7kHVrKu9oXlIEbV3NBPRG6N/pa7eH09AMl3KAfRQxWk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oAJxDSwmrS34oKP5Hhbiof6YTwidw8J8R4zVmrmSgemeohFeSnwJe0XldqC1QxWTyd2WhkGx1YAv1+Ak98d+wEkWw/GFJH8/BRh1UbhILyYzft8Rl1oMxCGkMAjmpgUT2vYG0WrCkfOSc4cu7sPmu0cyaTZIc6dKOzC/uDRGmCENozRxK+paEb86ccw2GnrVPH/VDlWzXwTzsaZTiukp2wIjKXYrhGo6msgAOaHM8IEbDi828t7Jt+yWEjGrmWl0AvG5XCtLKXDZHgxNmZ2qshuibWYoXm5wfyuxMRTlfj5qYfgjRDN1HUZzgMhpTFmIQepSJVjqlt+8RMdOfZB+jQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646663868; bh=LdrCv26l+T62kLuaxuIxgGxCCWrx1VMnanmN8oql19c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rbbBIA542RDgZ9+HOdb/DX5iHhJb2s+zsMno+YuNLPH/q3h0lzDAgK3f3kW2WfOYW/jRCto1begxtHe8i9LEDx5fvVee+40GrkoKn8akk+rKxxeUczeIlmDLcNJx14WEehKf00sNdyVEA06auStG6A+WalJ8jEHtI0PW797qKXCSvlmg2EMtjy/r9BIpaP0nzzFlVZSKHi/3btAHWfj/1I88WN/tB3l6FobX6szhzCXDQYCjJ8DRB+6opiPwzsDcCRZc90cXxNezFYW6ShJGNwXe5h4SpMGcglKHPCxy+9Rf7rRHTe9gGCMVw6QehojJ5YumoFADgyFdaHtEVYDsmA==
X-YMail-OSG: Bb_cLScVM1nHCq0Tn57u5zAbCRG0P3eEuLc_kgI67v9NteVA657teiE1KPx0yIG
 HtVLRsnn33vh5GIdfdh5eqbOgk4ULgT5IMmDDvKi_1GAziSAHlSr3MqtdMARtH3l3xD12CClGsy4
 3YfT2DR7HvN0UEI5aldyoIYa1vPq6EtznDN0Vp3LlUAVs5P6x0pEoq1oCZCRCSVDL.qsHxS6CHVj
 wJuIxRIDiFPXUxzDzKUZeSnFBMq9MnxJu__C6Df2hqo6k34lf60eaDXOJE_yMI7X9k6U7r.vZ.dG
 gArgEofvBFDpyV4l6AiQvbk6r4i0rEnzyq.PN11G_iE93lx5a6Ag5ddjijcApFv_UvhcEV2xaVEF
 V50mQPb0Cy0w7ZmfnWinjHOvdWjyXi0OHcPDBDh9WMmVAt2xwiTnYqRhvH9Wc4YDINyH_yBdCQFN
 KNIAC19Z_13sej2LI8XoywVEJeQhrzuWQ0DabNS6Ekqx_Uu.WDTPq9NDXxa7jDHWkjfR199o0MTD
 k4ciW.NdkC.rMxYsFKsz4Qb5hVCifMCBl2ad2VXu1TpG2g4s4kh9vm5pa0wKXBMPStMZHBbOR9oz
 WC0iWgpPhcyVz8v1jlMKUkZToJEUbwn9U0OpIqj51KKViXadNZH3ToLfdN4Cw5LMBVxPACRGm0Wr
 xo_CVtnmqiz7KRIPwVTVujHeVvzQfxerkoQXfX1MOs.uPQcAfdY.4h4UUQJnCbqGfYMIW11HABxA
 D2BRj0Aqdp6AXCDjIKLWDOZzpioi17sSrJO1SkhhcfwGZZRIs9gZzPAmXGwH7ORWdc8se0JZqjwc
 GeuSDXZ4dFEeuW7Sc9u_v.P2UABsDKXk2T.uxCeb2XvbUFMx_nggeYuqrHcmomNM1RFL0wljrBGH
 ZlAgfY9gd5St83j5bMtOqudOIPyp1NWKWFUfJrynPXjIVKN87HLU.oo0XFvv7RnXIZQmKBlnK4yM
 zI1ex99ar4iU0lrmarLZqZWvXT2Ov59Ykte2ioNR2oEy7LsZvnc8dE0xGeRJQcET4g1lBsWPWXUR
 Hhv4_jhn4s6VRrlY_bOHh_ffkb5DGuZx4._riHu2yjar39RqCRvN0lgxlxxv7I2KvnEaghi_xbj9
 XPe02Eyq9dUYs_C64jMhr36D2HxQMEt1eEoNN_cQDtucSJ1QuXp...hKPu.myCyXRFDMXICgpk.f
 A13feBmqd9yBqI.AR6fRvmE9RWhGXT0GloJZIX6qpeM96_cjcvClNB.ocxy0cIHC4XbBkRKCH11N
 FPNIqTYekXogYya9g8XtbgAovqztP6ppoTEhQsNMmFIN2HzFCKw4QH3M.HGl_ZcpnxbF4BnmJ3ZY
 owKT.y99ya_k33gIUez8E75U.0.nRsm_gF_D._Yr0Fk5InkymV318cbfM7tGDOkWrEmlgLUFFoCZ
 jOQQFfe6UbAmt_hkR2q2aXvHSy3IcZrm4yUciU.iS8XIPyHPQ_BlpR3JNaAk3r3oORQI3RDYsEyp
 Oq8tesBRrFNDF4Gj6s9HetZ4gVt98fjAlySHR9PodJB0jAd8v7PiJcde59wEK_dXfPYxetYLyxaY
 8okEJuEFPFPvrPMlv0jRPeqPXAgKuRHn8tCCKrHhx8GOXaJG4n_c33mv8tFrRZn6R64R9JLHBdC1
 qa25rn2b5U1UDmRT8OkG9bNA7F70j.fzllyILrZ9CWRcIz0rTsnpdRff3iv.VEwBuXLmxkuHEE1y
 2SHBE8IotCjFzgaArFKGiJVF_DTkydrR8bFNZwi8BhCHRC65_viSTYGPYcdaHStQqlI5wPnJIZ4z
 iz2OPothyXqz5nvspYo_A2Kt.Vynlo8jvOi1.D75dEaFzI4I0b4Q7oFEOR8LUmMZi81Tr2fE2AJJ
 UiB3DR6rpCF.uOt_KfSCgycSlbZgowxzwRiQLTYj8vlvZaOm8Wn.6Cmqenw4ioZr3cu3CyyO9n7r
 WnJXW1jTNOFGY.NQkAkuNLooS5vqBM1svoVxO63PKvaUT.EQSwB7CbMCDBKFad31KTLU0oEX9nes
 Xi_mkzz4nBjyKKW_R1oMPxRyjqp8F.NS8D_iFwEfyryk3Azbpc_U2doknfXfkVW.pMwuNu4vjOd5
 mfKsvk0KnDRJiNeWc4p1U7uQIrs9bj_lmsCFs2XU8sHBoekuhMAqttvKuAKxXdXaWU7KmSQI86ju
 0Bh9Rx7x7uHEXVK6oFUpSQBQQHCy4GZM5nFw9eFuttCz_l_ySLRiSE1g6gMowPkGWBx6zsdNNqgk
 tNP0Jo0y9SB9Mx8HyCR62yyUsrhlz.O0AOvCY3WWgxVzfdEYsPsN6TD4iMSbVOXzLEZxLBYohYmt
 EhcteZ83a84DEJvRcHaP7gKlLXvwh8fQZ9XyIw1.qWBqK7uNf5LhLfNLFHyX502B_tLiiIOr6OfC
 mhwEyYl2T6g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 14:37:48 +0000
Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e531a35fae5a7c14a8e4be774e4c7a63;
          Mon, 07 Mar 2022 14:37: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 14.0 \(3654.120.0.1.13\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <132978150.92.1646660769467@mailrelay>
Date: Mon, 7 Mar 2022 06:37:46 -0800
Cc: bob prohaska ,
 Free BSD ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <10724FB9-8E75-4DB7-A0F4-CFF55D21272B@yahoo.com>
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
To: Ronald Klop ,
 Mark Johnston 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KC1Jz4jfMz3MvQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=oAJxDSwm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.54 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.73)[-0.727];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_MEDIUM(0.69)[0.690];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 14008
Lines: 339


On 2022-Mar-7, at 05:46, Ronald Klop  wrote:

> Dear Mark Johnston,
>=20
> I did some binary search in the kernels and came to the conclusion =
that =
https://cgit.freebsd.org/src/commit/?id=3D1517b8d5a7f58897200497811de1b188=
09c07d3e still works and =
https://cgit.freebsd.org/src/commit/?id=3D407c34e735b5d17e2be574808a09e6d7=
29b0a45a panics.
>=20
> I suspect your commit in =
https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4=
70bef23a.
>=20
> Last panic:
>=20
> panic: vm_fault failed: ffff00000046e708 error 1
> cpuid =3D 1
> time =3D 1646660058
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> osd_get() at osd_get+0x5c
> zio_execute() at zio_execute+0xf8
> taskqueue_run_locked() at taskqueue_run_locked+0x178
> taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db>

Was this a WITNESS/DEBUG kernel? Non-WITNESS? Non-debug?

Which aarch64 variant? Bob's was Cortex-A53 (RPi3).

> A more recent kernel (912df91) still panics. See below.
>=20
> Do you have time to look into this? What can I provide in information =
to help?
>=20
> Regards,
> Ronald.
>=20
> Van: Ronald Klop 
> Datum: maandag, 7 maart 2022 11:38
> Aan: Mark Millard 
> CC: bob prohaska , freebsd-current =
, freebsd-arm@freebsd.org
> Onderwerp: Re: panic: data abort in critical section or under mutex =
(was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on =
14-CURRENT/aarch64 Feb 28))
>=20
> Yes, I spoke to soon too. Often it crashes as soon as I start a =
parallel poudriere build. But this time it went very far. As soon as =
nightly backups kicked in it was game over again.
> I had read the mail of Bob on the arm@ ML. But I wanted to let the =
conclusion that it is about the same problem to the developers. (Have =
seen enough of wrong guessing of causes in my work. )
>=20
> I will need to go further into the binary search of working kernels.
>=20
> This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC =
2022
> Fatal data abort:                                                      =
                                                            =20
>   x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) =
(mac_policy_rm + 0)                                              =20
>                                                                        =
                                                            =20
>   x1:                2  x1:                2                           =
                                                           =20
>                                                                        =
                                                            =20
>   x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + =
2f28a)                                                            =20
>  (cam_status_table + 2f28a)  x3: ffff00000087dcf2                      =
                                                            =20
>   x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + =
2f28a)                                                      =20
>                                                                        =
                                                            =20
>   x4:              102  x4:              102                           =
                                                           =20
>                                                                        =
                                                            =20
>   x5:                7  x5:                1                           =
                                                           =20
>                                                                        =
                                                            =20
>   x6:                0  x6:               ff                           =
                                                           =20
>                                                                        =
                                                            =20
>   x7:                0  x7: ffffa00011fc2800                           =
                                                           =20
>   x8:                1                                                 =
                                                           =20
>                                                                        =
                                                            =20
>   x8:                1  x9: ffff000000f37c10                           =
                                                           =20
>   x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)                 =
                                                           =20
>                                                                        =
                                                            =20
>  x10: ffffa0017be2a600 x10: ffffa000010fa600                           =
                                                           =20
>  x11: 394aed08d0003a48                                                 =
                                                           =20
>                                                                        =
                                                            =20
>  x12: 350001a8b946a108 x11:                0                           =
                                                           =20
>                                                                        =
                                                            =20
>  x12: ffff000000f37c10 x13:         badecce4 (pcpu0 + 90)              =
                                                            =20
>                                                                        =
                                                            =20
>  x13: ffffa0001fbde6b0 x14:                0                           =
                                                           =20
>                                                                        =
                                                            =20
>  x14:         4965ae49 x15:                1                           =
                                                           =20
>                                                                        =
                                                            =20
>  x15:          1000193 x16: ffff0000016a4238                           =
                                                           =20
>  x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) =
(__stop_set_modmetadata_set + 448)                                      =20=

>                                                                        =
                                                            =20
>  x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) =
(if_inc_counter + 0)                                                     =
 =20
>                                                                        =
                                                            =20
>  x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314)        =
                                                            =20
>  (next_index + 3a228c0) x19:              102                          =
                                                            =20
>=20
>                                                                        =
                                                           =20
>  x19:              102 x20: ffff0000b49a2428                           =
                                                           =20
>  x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)       =
                                                           =20
>=20
>  x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + =
2f28a) (cam_status_table + 2f28a)
>=20
>  x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) =
(mac_policy_rm + 0)
>=20
>  x23: ffff00000086f107 x23:                0 (cam_status_table + =
2069f)
>=20
>  x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
>  x25:                0
>=20
>  x25: ffff00000088aa11 x26:                4 =
(do_execve.fexecv_proc_title + 76b7)
>=20
>  x27:                0 x26: ffffa0017be2a600
>  x28: ffff00010209fcf0
>  x27: ffffa00025626a80 (next_index + 1bb0a30)
>=20
>  x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) =
(g_ctx + b3242334)
>=20
>  x29: ffff000103f11ba0  sp: ffff0000b49a23c0
>  (next_index + 3a228e0)  lr: ffff00000046ef98
>   sp: ffff000103f11b80
>  (_rm_runlock_debug + 60)  lr: ffff00000046ef98
>  elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)
>=20
>  elr: ffff00000046dc0cspsr:               45
>  (_rm_assert + a4) far:               10
>=20
>  esr:         96000004
> spsr:               45
>=20
> panic: data abort in critical section or under mutex
> cpuid =3D 1
> time =3D 1646609483
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2d4
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_assert() at _rm_assert+0xa4
> _rm_runlock_debug() at _rm_runlock_debug+0x5c
> mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
> tcp_input_with_port() at tcp_input_with_port+0xab4
> tcp_input() at tcp_input+0xc
> ip_input() at ip_input+0x2e8
> netisr_dispatch_src() at netisr_dispatch_src+0xe4
> ether_demux() at ether_demux+0x178
> ether_nh_input() at ether_nh_input+0x3e8
> netisr_dispatch_src() at netisr_dispatch_src+0xe4
> ether_input() at ether_input+0x80
> if_input() at if_input+0xc
> gen_intr() at gen_intr+0x444
> ithread_loop() at ithread_loop+0x2a0
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 12 tid 100063 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db>
>=20
>=20
> NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a =
wifi connected power switch on it.
>=20
> Regards,
> Ronald.
>=20
> Van: Mark Millard 
> Datum: maandag, 7 maart 2022 02:01
> Aan: Ronald Klop 
> CC: freebsd-current , bob prohaska =

> Onderwerp: Re: panic: data abort in critical section or under mutex =
(was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on =
14-CURRENT/aarch64 Feb 28))
>=20
> From: Ronald Klop  wrote on
> Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :
>=20
> > Did some binary search with kernels from artifact.ci.freebsd.org.
> >
> > I suspect "rmlock: Micro-optimize read locking" as cause.
> >
> > =
https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4=
70bef23a
> >
> >
> > And "rmlock: Add required compiler barriers to _rm_runlock()" as =
solution.
> >
> > =
https://cgit.freebsd.org/src/commit/?id=3D89ae8eb74e87ac19aa2d7abe4ba16bcc=
cd32bb9f
> >
> >
> > So I probably just had a bad day.
>=20
> Well, there is a report of a buildkernel crash after that pair:
>=20
> https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html
>=20
> that references additional information at:
>=20
> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme
>=20
> and reported:
>=20
> QUOTE
> The console connection dropped before the crash (unrelated) I didn't
> get the preamble, all  I have is the backtrace and buildkernel log.
> Here's the backtrace:
> db> bt
> Tracing pid 14795 tid 100098 td 0xffffa00017815600
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x368
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1cc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1b0
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
> sysctl_root() at sysctl_root+0x1ac
> userland_sysctl() at userland_sysctl+0x140
> sys___sysctl() at sys___sysctl+0x68
> do_el0_sync() at do_el0_sync+0x520
> handle_el0_sync() at handle_el0_sync+0x40
> --- exception, esr 0x56000000
> END QUOTE

This was a WITNESS and debug kernel as I understand.

Also, this was a RPi3, so Cortex-A53, that has
in-order-execution cores. (Unlike Cortex-A72's,
for example).

> The above material does reference _rm_rlock_debug . Might be
> related?
>=20
> The readme reports:
>=20
> main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022
>=20
> for the system doing the buildkernel. This is after
> 89ae8eb74e8 .
>=20
> (It also mentions another panic earlier in the week,
> apparently not reported to the lists at the time.)
>=20

So far as I have noticed, all reports of the crashes in
_rm_rlock_debug are on aarch64 hardware. So may be the
problem is tied to the weak memory model --but for something
that matters to a Cortex-A53's executes-in-order cores?
(Just athought.) But, then, the constrasting(?) status of
powerpc64 might be of note. (And I'll stop guessing here.)

I do not know if any non-WITNESS/non-debug kernel builds
have failed.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar  7 14:48:15 2022
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 771781A0BEA7
	for ; Mon,  7 Mar 2022 14:48:17 +0000 (UTC)
	(envelope-from mail@crcomp.net)
Received: from www18.qth.com (www18.qth.com [69.16.238.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KC1Xw5Byfz3Qgk
	for ; Mon,  7 Mar 2022 14:48:16 +0000 (UTC)
	(envelope-from mail@crcomp.net)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crcomp.net;
	s=default; h=References:Subject:From:To:Date:Sender:Reply-To:Message-ID:Cc:
	MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=VQOghm7P/Bl4vu5i/evWTia1x4V+YDLeZp6LDolWdzM=; b=R/AFbcsS3WV2WqA4c077QmQYzF
	yltWhCfc3jcRcU25dqyRxe0p0rOFlOq/ay0vunBRBLNzk18m8jvDshucEqabzE7BC5lJv8SEqPaVe
	NdgoHmTAgtFYDu4/tk0j+Lx7g1M6EIXv92WNqvt3JgNBUGSN5LbJGy5O0Rr6codXlwJpMREQ77pUp
	WcGdGmls/mRX4F5geDoJkoDit698mMgUHYFF0MtnSAHPfC1Y01WNflJ0o0NQv/J+y3k1Bm0NayUw0
	3A2AvtQd75h5Suii6FubgbYLXUO/GH/iZNyZSDJwbl3UVTs3upKnmfEXqzoYatb2KpYmmauE4sFLB
	OSBfgNJg==;
Received: from [69.146.199.132] (port=31732 helo=michael2)
	by www18.qth.com with esmtpa (Exim 4.94.2)
	(envelope-from )
	id 1nREel-0000sA-V5
	for freebsd-arm@freebsd.org; Mon, 07 Mar 2022 08:48:16 -0600
Date: 07 Mar 2022 14:48:15 UTC
To: 
From: Don Kuenz 
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
References: <47C61079-AB2E-4E81-AD95-F6042477D4E8@yahoo.com>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - www18.qth.com
X-AntiAbuse: Original Domain - freebsd.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - crcomp.net
X-Get-Message-Sender-Via: www18.qth.com: authenticated_id: mail@crcomp.net
X-Authenticated-Sender: www18.qth.com: mail@crcomp.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Rspamd-Queue-Id: 4KC1Xw5Byfz3Qgk
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=crcomp.net header.s=default header.b="R/AFbcsS";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mail@crcomp.net designates 69.16.238.59 as permitted sender) smtp.mailfrom=mail@crcomp.net
X-Spamd-Result: default: False [0.40 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 HAS_X_SOURCE(0.00)[];
	 TO_DN_NONE(0.00)[];
	 DKIM_TRACE(0.00)[crcomp.net:+];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 INVALID_DATE(1.50)[];
	 HAS_X_ANTIABUSE(0.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:32244, ipnet:69.16.192.0/18, country:US];
	 HAS_X_AS(0.00)[mail@crcomp.net];
	 RCVD_IN_DNSWL_LOW(-0.10)[69.16.238.59:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[crcomp.net:s=default];
	 RECEIVED_SPAMHAUS_PBL(0.00)[69.146.199.132:received];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.51:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[crcomp.net];
	 RCPT_COUNT_ONE(0.00)[1];
	 MISSING_MID(2.50)[];
	 DBL_PROHIBIT(0.00)[0.0.0.51:email];
	 HAS_X_GMSV(0.00)[mail@crcomp.net];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
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
Status: O
Content-Length: 3943
Lines: 131

Attempt number four to answer Mark's question in regards to the origin 
of config.txt content. (The em control character spewed out by "man" 
mangled my mail earlier.)

Mark wrote:
> Don wrote:
>>
>> and /boot/msdos/config.txt looks like this:
>> 
>> root@generic:/boot # cat /boot/msdos/config.txt
>> init_uart_clock=3000000
>> enable_uart=1
>> kernel=u-boot.bin
>> kernel7=u-boot.bin
>> dtoverlay=mmc
>
> config.txt seems fine up to here. But I've never seen
> anything indicating that the following notation is
> valid for config.txt files:
> 
>> / {
>>  gpioiic0 {
>>    compatible = "i2c-gpio";
>>    pinctrl-names = "default";
>>    pinctrl-0 = <&pinctrl_gpioiic0>;
>>    scl-gpios = <&gpio2  3 GPIO_ACTIVE_HIGH>;
>>    sda-gpios = <&gpio3  5 GPIO_ACTIVE_HIGH>;
>>    status = "okay";
>>  };
>> };
>
> If you have a reference indicating otherwise, I'd
> be interested to know what it is.

# man gpioicc

------------------------------------------------------------------------
GPIOIIC(4)	       FreeBSD Kernel Interfaces Manual 	    GPIOIIC(4)
 
NAME
     gpioiic - GPIO I2C bit-banging device driver
 
SYNOPSIS
     To compile this driver into the kernel, place the following lines in your
     kernel configuration file:
 
	   device gpio
	   device gpioiic
	   device iicbb
	   device iicbus
 
     Alternatively, to load the driver as a module at boot time, place the
     following line in loader.conf(5):
 
	   gpioiic_load="YES"
 
DESCRIPTION
     The gpioiic driver provides an IIC bit-banging interface using two GPIO
     pins for the SCL and SDA lines on the bus.

     gpioiic simulates an open collector kind of output when managing the pins
     on the bus, even on systems which don't directly support configuring gpio
     pins in that mode.  The pins are never driven to the logical value of
     '1'.  They are driven to '0' or switched to input mode (Hi-Z/tri-state),
     and an external pullup resistor pulls the line to the 1 state unless some
     other device on the bus is driving it to 0.
 
HINTS CONFIGURATION



FDT CONFIGURATION
     On an FDT(4) based system, such as ARM, the DTS node for gpioiic conforms
     to the standard bindings document i2c/i2c-gpio.yaml.  The device node
     typically appears at the root of the device tree.	The following is an
     example of a gpioiic node with one slave device on the IIC bus:

     / {
	     gpioiic0 {
		     compatible = "i2c-gpio";
		     pinctrl-names = "default";
		     pinctrl-0 = <&pinctrl_gpioiic0>;
		     scl-gpios = <&gpio1  5 GPIO_ACTIVE_HIGH>;
		     sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
		     status = "okay";

		     /* One slave device on the i2c bus. */
		     rtc@51 {
			     compatible="nxp,pcf2127";
			     reg = <0x51>;
			     status = "okay";
		     };
	     };
     };

     Where:

     compatible      Should be set to "i2c-gpio".  The deprecated string
		     "gpioiic" is also accepted for backwards compatibility.

     scl-gpios sda-gpios
		     These properties indicate which GPIO pins should be used
		     for clock and data on the GPIO IIC bit-banging bus.
		     There is no requirement that the two pins belong to the
		     same gpio controller.

     pinctrl-names pinctrl-0
		     These properties may be required to configure the chosen
		     pins as gpio pins, unless the pins default to that state
		     on your system.

SEE ALSO
     fdt(4), gpio(4), iic(4), iicbb(4), iicbus(4)

------------------------------------------------------------------------

I'll take a closer look at "man dtc" and "i2c/i2c-gpio.yaml"

https://mjmwired.net/kernel/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml

Other replies in the thread provide me with additional food for thought
for the time being.

Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.



From nobody Mon Mar  7 15:13:37 2022
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 DB13619EA01A;
	Mon,  7 Mar 2022 15:13:41 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835])
	(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 4KC26F0Lm9z3ltp;
	Mon,  7 Mar 2022 15:13:41 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qt1-x835.google.com with SMTP id b23so13476645qtt.6;
        Mon, 07 Mar 2022 07:13:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=ke+WAIsIlx2cs1GtXexL6lDfk0mefkBVKXgofAu6iss=;
        b=BpTPXuU3R9MN/OHmXFHiq0A5tXnaua8zmaMgzkGmYm0a6E3OPCfSu8hQc4t+4W3bZN
         HM3Vtl4FW7/YPIKjMKRGqgGLC0fmdXp+uWInKBlKalpeywsEk4fSSi04m72MijRILcNW
         tIKsnM5yXpVMkurPP9M/YlTp1gyqkM6nBP8fgv7Cg8vw84OjIxPoTIm468P/oQKlnD+s
         kl/4/RQOQerohsWrs+76faqcxTQWSYuU1v7086barR+q3b8hKgsQ44zMCRuSNb4QGZWa
         U2sCXak5Z0KA49umbPPOwljEgI9bKp/RmJVje2OdQpnum6oz/jzK1e3/jQORdEngTqjc
         87Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=ke+WAIsIlx2cs1GtXexL6lDfk0mefkBVKXgofAu6iss=;
        b=WdGEQ2LTJIVfwnHvOy7/OAGuStOm5L6PmA7dHv3q14K8oR3qE5Wb+TZgDaVlwH1Ns9
         xgFTT4/xeHEsKS8AR6PNMj39MicuS+kPPfQTrBHiHiHLEon2d0l5UfCF6cfZpgX1vR3C
         WqvL6XnqKPNl5fFP1s/oDWqZgcuoNwqxjEZ8w8BEqnK374auFJH+1BSePRsgqCqKY+Ji
         0RzZDRgaYIfY0FKfydUq5zV8DUVloDLYGupsO5BEwQEj0FEPTIsYYqYRh5JgkHGhe9AW
         JxDWEoXaRGTD8SjONjuyRmKf7IHxgefsTUCI7oTHVJ9+mqGnIXY9xAfN86au4jUuD0yv
         nlVQ==
X-Gm-Message-State: AOAM533qSuWTaPmtn8fKbBOIhp8k6So6lbj01tBN999nYwa52UhhykzQ
	MKrbnlQhgGnZ8dghkDGOxgY=
X-Google-Smtp-Source: ABdhPJwHRV9IVngDb8Or+gaomMiu8lsMa9kNgVNzqo6DDq2FQqkpa/WosWGUb0VO6LLFGxHDylQVYQ==
X-Received: by 2002:ac8:5b0f:0:b0:2e0:5a1f:9910 with SMTP id m15-20020ac85b0f000000b002e05a1f9910mr8892131qtw.356.1646666020161;
        Mon, 07 Mar 2022 07:13:40 -0800 (PST)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id w9-20020a05620a148900b005f188f755adsm6304214qkj.32.2022.03.07.07.13.39
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 07 Mar 2022 07:13:39 -0800 (PST)
Date: Mon, 7 Mar 2022 10:13:37 -0500
From: Mark Johnston 
To: Ronald Klop 
Cc: bob prohaska , Mark Millard ,
	freebsd-arm@freebsd.org,
	freebsd-current 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Message-ID: 
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay>
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: <132978150.92.1646660769467@mailrelay>
X-Rspamd-Queue-Id: 4KC26F0Lm9z3ltp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=BpTPXuU3;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.70 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5753
Lines: 128

On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> Dear Mark Johnston,
> 
> I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.
> 
> I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.
> 
> Last panic:
> 
> panic: vm_fault failed: ffff00000046e708 error 1
> cpuid = 1
> time = 1646660058
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> osd_get() at osd_get+0x5c
> zio_execute() at zio_execute+0xf8
> taskqueue_run_locked() at taskqueue_run_locked+0x178
> taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db>
> 
> A more recent kernel (912df91) still panics. See below.
> 
> Do you have time to look into this? What can I provide in information to help?

Hmm.  So after my rmlock commits, we have the following disassembly for
_rm_rlock() (with a few annotations added by me).  Note that the pcpu
pointer is stored in register x18 by convention.

   0xffff00000046e304 <+0>:     stp     x29, x30, [sp, #-16]!
   0xffff00000046e308 <+4>:     mov     x29, sp
   0xffff00000046e30c <+8>:     ldr     x8, [x18]
   0xffff00000046e310 <+12>:    ldr     x9, [x18]
   0xffff00000046e314 <+16>:    ldr     x10, [x18]
   0xffff00000046e318 <+20>:    cmp     x9, x10
   0xffff00000046e31c <+24>:    b.ne    0xffff00000046e3cc <_rm_rlock+200>  // b.any
   0xffff00000046e320 <+28>:    ldr     x9, [x18]
   0xffff00000046e324 <+32>:    ldrh    w9, [x9, #314]
   0xffff00000046e328 <+36>:    cbnz    w9, 0xffff00000046e3c0 <_rm_rlock+188>
   0xffff00000046e32c <+40>:    str     wzr, [x1, #32]
   0xffff00000046e330 <+44>:    stp     x0, x8, [x1, #16]
   0xffff00000046e334 <+48>:    ldrb    w9, [x0, #10]
   0xffff00000046e338 <+52>:    tbz     w9, #4, 0xffff00000046e358 <_rm_rlock+84>
   0xffff00000046e33c <+56>:    ldr     x9, [x18]
   0xffff00000046e340 <+60>:    ldr     w10, [x9, #888]
   0xffff00000046e344 <+64>:    add     w10, w10, #0x1
   0xffff00000046e348 <+68>:    str     w10, [x9, #888]
   0xffff00000046e34c <+72>:    ldr     x9, [x18]
   0xffff00000046e350 <+76>:    ldr     w9, [x9, #888]
   0xffff00000046e354 <+80>:    cbz     w9, 0xffff00000046e3f4 <_rm_rlock+240>
   0xffff00000046e358 <+84>:    ldr     w9, [x8, #1212]
   0xffff00000046e35c <+88>:    add     x10, x18, #0x90
   0xffff00000046e360 <+92>:    add     w9, w9, #0x1
   0xffff00000046e364 <+96>:    str     w9, [x8, #1212]  <------- critical_enter
   0xffff00000046e368 <+100>:   str     x10, [x1, #8]
   0xffff00000046e36c <+104>:   ldr     x9, [x18, #144]
   0xffff00000046e370 <+108>:   str     x9, [x1]
   0xffff00000046e374 <+112>:   str     x1, [x9, #8]
   0xffff00000046e378 <+116>:   str     x1, [x18, #144]
   0xffff00000046e37c <+120>:   ldr     x9, [x18]
   0xffff00000046e380 <+124>:   ldr     w10, [x9, #356]
   0xffff00000046e384 <+128>:   add     w10, w10, #0x1
   0xffff00000046e388 <+132>:   str     w10, [x9, #356]
   0xffff00000046e38c <+136>:   ldr     w9, [x8, #1212]
   0xffff00000046e390 <+140>:   sub     w9, w9, #0x1
   0xffff00000046e394 <+144>:   str     w9, [x8, #1212]  <------- critical_exit
   0xffff00000046e398 <+148>:   ldrb    w8, [x8, #304]
   0xffff00000046e39c <+152>:   ldr     w9, [x18, #60]   <------- loading &pc->pc_cpuid
   ...

A (the?) problem is that the compiler is treating "pc" as an alias
for x18, but the rmlock code assumes that the pcpu pointer is loaded
once, as it dereferences "pc" outside of the critical section.  On
arm64, if a context switch occurs between the store at _rm_rlock+144 and
the load at +152, and the thread is migrated to another CPU, then we'll
end up using the wrong CPU ID in the rm->rm_writecpus test.

I suspect the problem is unique to arm64 as its get_pcpu()
implementation is different from the others in that it doesn't use
volatile-qualified inline assembly.  This has been the case since
https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
.

I haven't been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though.  Could you please try the patch below and
confirm whether it fixes your panics?  I verified that the apparent
problem described above is gone with the patch.

diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c
index 0cdcfb8fec62..e51c25136ae0 100644
--- a/sys/kern/kern_rmlock.c
+++ b/sys/kern/kern_rmlock.c
@@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
 {
 	struct thread *td = curthread;
 	struct pcpu *pc;
+	int cpuid;
 
 	if (SCHEDULER_STOPPED())
 		return (1);
@@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
 	atomic_interrupt_fence();
 
 	pc = get_pcpu();
+	cpuid = pc->pc_cpuid;
 	rm_tracker_add(pc, tracker);
 	sched_pin();
 
@@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
 	 * conditional jump.
 	 */
 	if (__predict_true(0 == (td->td_owepreempt |
-	    CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))
+	    CPU_ISSET(cpuid, &rm->rm_writecpus))))
 		return (1);
 
 	/* We do not have a read token and need to acquire one. */

From nobody Mon Mar  7 16:10:12 2022
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 1B7AF19FABFB
	for ; Mon,  7 Mar 2022 16:10:14 +0000 (UTC)
	(envelope-from mail@crcomp.net)
Received: from www18.qth.com (www18.qth.com [69.16.238.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KC3MT1yxrz4Wmj
	for ; Mon,  7 Mar 2022 16:10:13 +0000 (UTC)
	(envelope-from mail@crcomp.net)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crcomp.net;
	s=default; h=References:Subject:From:To:Date:Sender:Reply-To:Message-ID:Cc:
	MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=1hBntDvf+PHBjgP/PlmXfdaQ5P2irTOocSD1nr2293U=; b=NVnjtymqtxSviim9e1O/OEWxKs
	QIyFV1FubxOf3+cAdrT+GC14kEWPgPfWVQGMoBgXikmJ9CAEzKUZyNtKPvmYs5frsl/3MwVrvKzE7
	gsgl2/EcCjQ2YvRjgtBk7Q+Kup4XlW0uaMgoAF9KuZdm9XQmwdvrwNMQ/bZ3B61fBTIIawQmj65EL
	vfdvCpccNx4g6FB23ZfxR6D5Qt0vatkcHJk5fuexv2lS6hvRVUaMRVzvRsSwv8iILlYaOD0Q9Ye/4
	950v5NgXCItUhHFYZ17IaL6M6lw6ud9cTq5H9DZR/HGKGaVRLq5YXPB/rxTOWfi7SiWaBM5Ty0+yb
	/t6Vv+iA==;
Received: from [69.146.199.132] (port=40457 helo=michael2)
	by www18.qth.com with esmtpa (Exim 4.94.2)
	(envelope-from )
	id 1nRFw4-0005GQ-Dl
	for freebsd-arm@freebsd.org; Mon, 07 Mar 2022 10:10:12 -0600
Date: 07 Mar 2022 16:10:12 UTC
To: 
From: Don Kuenz 
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
References: <9f337b5a-4e2d-a52f-2b99-4af69ad4c480@bunyatech.com.au>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - www18.qth.com
X-AntiAbuse: Original Domain - freebsd.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - crcomp.net
X-Get-Message-Sender-Via: www18.qth.com: authenticated_id: mail@crcomp.net
X-Authenticated-Sender: www18.qth.com: mail@crcomp.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Rspamd-Queue-Id: 4KC3MT1yxrz4Wmj
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=crcomp.net header.s=default header.b=NVnjtymq;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mail@crcomp.net designates 69.16.238.59 as permitted sender) smtp.mailfrom=mail@crcomp.net
X-Spamd-Result: default: False [0.41 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 HAS_X_SOURCE(0.00)[];
	 TO_DN_NONE(0.00)[];
	 DKIM_TRACE(0.00)[crcomp.net:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 INVALID_DATE(1.50)[];
	 HAS_X_ANTIABUSE(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[69.146.199.132:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:32244, ipnet:69.16.192.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 HAS_X_AS(0.00)[mail@crcomp.net];
	 RCVD_IN_DNSWL_LOW(-0.10)[69.16.238.59:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	 R_DKIM_ALLOW(-0.20)[crcomp.net:s=default];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[crcomp.net];
	 RCPT_COUNT_ONE(0.00)[1];
	 MISSING_MID(2.50)[];
	 HAS_X_GMSV(0.00)[mail@crcomp.net];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
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
Status: O
Content-Length: 1661
Lines: 51

Brian Scott wrote:
>
> I think I'm like most people here, trying to guess what you are wanting
> to achieve. Pins 2 and 3 are already avalable as iic1 provided you include:
>
> dtparam=i2c_arm
>
> in your config.txt file. There's a little more magic needed on the rpi4
> but that doesn't effect you.
>
> Pin 3 (GPIO 2) is SDA and Pin 5 (GPIO 3) is SCL. This 'seems' to be the
> opposite of what you are doing in your dts snippet so I could be wrong,
> but I would have thought these functions would be hardwired in the SOC.
>
> As for your specific device, PCF8574; I don't have any direct experience
> but it looks like a standard IIC device that should work OK. I see there
> is a FreeBSD kernel module to support it but it is quite recent so
> probably only in CURRENT. As I said, I don't have experience with that
> particular device.
>
> Hope this helps,

It did indeed. Problem solved. Mucho gracias!

------------------------------------------------------------------------
root@generic:~ # cat /boot/msdos/config.txt
init_uart_clock=3000000
enable_uart=1
kernel=u-boot.bin
kernel7=u-boot.bin
dtoverlay=mmc
dtparam=i2c_arm

root@generic:~ # ls /dev | grep iic
iic0

root@generic:~ # i2c -sv
dev: /dev/iic0, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic0:
27
------------------------------------------------------------------------

Danke,

-- 
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.



From nobody Mon Mar  7 16:25:22 2022
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 D993819FF2FB;
	Mon,  7 Mar 2022 16:26:06 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KC3jk4kpCz4Zg5;
	Mon,  7 Mar 2022 16:26:01 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id E00234E691;
	Mon,  7 Mar 2022 16:25:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz;
	s=mail; t=1646670325;
	bh=7XrO+HaAx4iY3x3pFrVg45yl1uV5r+TSyOoKSvgfHkk=;
	h=From:Subject:Date:In-Reply-To:Cc:To:References;
	b=RFijEnsVrMOCC4A0q561JG7eVkbahX00Nqx9p1mxa9VBezirmPks/x3mpCbmygZH0
	 eB59BuSrztQHKsdU6oqMqmy4v3PzOMaoGDAV9IWfa5tVx0gZXdKl0Tgd6IgSPKGqsf
	 AFNOpRvecWe8+7LC7K4M2llmCqxw9OJsGO5yk6XIT4TP0rjhNytpbTHU8jddLQOCWF
	 8i8PrFIfIeyJVg805dB5x5jjavd2geqJSCQW7ILbAQzB1C2woJ4BEOISGyN5KwlTxf
	 ALvOlw1CjF/WER8xwPs8hD2Ug4iCx/PmBvdOfWm8DRERtAj2/EphDWKz3whGjoH3vr
	 L9lpsWNC3sH+ayr1Y0Db95EhZTaDKUaQecGBLE8JqS0Y7/9jAnEgwfmMs5sdoWxe1t
	 fpCeSUyxKUOzp/yQYLlbXKBft02yBX6bOiPGt+BAQ3fvWUE4qZiitR1YFOuyDToq1b
	 qh3ZS0VsKtAuvgM97RqVusGT4w6Kaxl4xoyT1gcH8AAIItVO+COVEG+c5PoV/uoNux
	 EAXypYPS4Fy8ltgItPfmKoN7qSxUyL5OkAyse61e3MbfxZf3LcZ+ju1Fh+7f9B2sRM
	 NGQhbDHDaLsfdT3FVu2zu/Imr7pUXXpFBFCwxvmCNOZtpvTehUAyLDIpKGMe4/MtKy
	 u7AE3Q2svHWOHNodoDZAgckU=
From: Andrew Turner 
Message-Id: <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B"
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 15.0 \(3693.60.0.1.1\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Date: Mon, 7 Mar 2022 16:25:22 +0000
In-Reply-To: 
Cc: Ronald Klop ,
 bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org,
 freebsd-current 
To: Mark Johnston 
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KC3jk4kpCz4Zg5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=fubar.geek.nz header.s=mail header.b=RFijEnsV;
	dmarc=pass (policy=none) header.from=fubar.geek.nz;
	spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz
X-Spamd-Result: default: False [-3.40 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_FIVE(0.00)[6];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[fubar.geek.nz:+];
	 DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 FREEMAIL_CC(0.00)[klop.ws,www.zefox.net,yahoo.com,freebsd.org];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 17129
Lines: 287


--Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
> ...
> A (the?) problem is that the compiler is treating "pc" as an alias
> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> once, as it dereferences "pc" outside of the critical section.  On
> arm64, if a context switch occurs between the store at _rm_rlock+144 =
and
> the load at +152, and the thread is migrated to another CPU, then =
we'll
> end up using the wrong CPU ID in the rm->rm_writecpus test.
>=20
> I suspect the problem is unique to arm64 as its get_pcpu()
> implementation is different from the others in that it doesn't use
> volatile-qualified inline assembly.  This has been the case since
> =
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e=
99e73762 =

> .
>=20
> I haven't been able to reproduce any crashes running poudriere in an
> arm64 AWS instance, though.  Could you please try the patch below and
> confirm whether it fixes your panics?  I verified that the apparent
> problem described above is gone with the patch.

Alternatively (or additionally) we could do something like the =
following. There are only a few MI users of get_pcpu with the main place =
being in rm locks.

diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index 09f6361c651c..59b890e5c2ea 100644
--- a/sys/arm64/include/pcpu.h
+++ b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct pcpu;

 register struct pcpu *pcpup __asm ("x18");

-#define        get_pcpu()      pcpup
+static inline struct pcpu *
+get_pcpu(void)
+{
+       struct pcpu *pcpu;
+
+       __asm __volatile("mov   %0, x18" : "=3D&r"(pcpu));
+       return (pcpu);
+}

 static inline struct thread *
 get_curthread(void)

Andrew


--Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On =
7 Mar 2022, at 15:13, Mark Johnston <markj@freebsd.org> =
wrote:
...
A (the?) problem is that the compiler is treating "pc" as an =
alias
for x18, but =
the rmlock code assumes that the pcpu pointer is loaded
once, as it dereferences "pc" =
outside of the critical section.  On
arm64, if a context switch occurs between the store at =
_rm_rlock+144 and
the load at +152, and the thread is migrated to another CPU, =
then we'll
end up using =
the wrong CPU ID in the rm->rm_writecpus test.

I suspect the problem is unique =
to arm64 as its get_pcpu()
implementation is different from the others in that it =
doesn't use
volatile-qualified inline assembly.  This has been the =
case since
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd=
f85ad04fc8e99e73762
.

I haven't =
been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though. =
 Could you please try the patch below and
confirm whether it fixes your =
panics?  I verified that the apparent
problem described above is gone with the patch.

Alternatively=
 (or additionally) we could do something like the following. There are =
only a few MI users of get_pcpu with the main place being in rm =
locks.

diff --git =
a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index =
09f6361c651c..59b890e5c2ea 100644
--- =
a/sys/arm64/include/pcpu.h
+++ =
b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct =
pcpu;

 register struct pcpu =
*pcpup __asm ("x18");

-#define =
       get_pcpu()     =
 pcpup
+static inline struct pcpu =
*
+get_pcpu(void)
+{
+     =
  struct pcpu *pcpu;
+
+       =
__asm __volatile("mov   %0, x18" : "=3D&r"(pcpu));
+ =
      return (pcpu);
+}

 static inline struct thread =
*
 get_curthread(void)

Andrew

=

--Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B--

From nobody Mon Mar  7 16:45:02 2022
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 8A3E31A051E3;
	Mon,  7 Mar 2022 16:45:18 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832])
	(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 4KC47x4SgQz4j3s;
	Mon,  7 Mar 2022 16:45:17 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qt1-x832.google.com with SMTP id 11so13716589qtt.9;
        Mon, 07 Mar 2022 08:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=5UYaPmaTEqBJoZRQrb8hIFwZZsI3StJpQcF7a5ffnfk=;
        b=IUstT1RgGaFjTpv9oNTVMo1dYUCStoh3nxph2gw4dwsis6vbIOGlGWPlVWAstKDebr
         acR6FfELyFpfuz6HielHo7OC62fd8tdEimZ85ZSVRmrcKm2w2NlRvhFUlLZJzPhgx3UD
         BJW2XvkIOysMA72JUnidH8VmMBwZONz0K13vC2W3TOpffCfekoK9d7WewwfJa1TLproh
         jZr1r/fxA8buyNSNFATRH/9CdYjZ/5bUZ12wYeNjwS7gE2qlR375pgQGV3JZx5RNp+4x
         1KBf4d7BlC9e2eYSaSFiMCPkuoG9jiR3sw0KBlssdXvgk2X4B94RNLFDDGhX/3Na9thJ
         n4pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=5UYaPmaTEqBJoZRQrb8hIFwZZsI3StJpQcF7a5ffnfk=;
        b=xsKBbnhS7/xUTi4pItNkI5W4Gtug28BlrRC9LuOsx3YMeDkwIfWkG6OaTgzLlySNpE
         FDApXEz8M/JjaPdAdi/KQ9PCEqDcymTm+z1KiIbIDUhdAsMBopSZuI8kdhXeffy28D25
         zA1zXCHGML4x3kdJpzl/6qkE5PtjsbnGQ0a495QH9+fbbHTPeQViz6AXw9KIQFbygGJg
         xj0bHq2IypDQQNzWwRkfVpgf9SLMWFmDgTfhLeawlUKkFetfLZ5x1iLS/Jrcq98qYi/3
         wYf4WCJ6jtLmTK/V0muHrwqNfnA3wcHBSDXbpaBKqR7NH3K4vS3tE8vD2XfYLHUXfTsv
         ZN9g==
X-Gm-Message-State: AOAM530uvVmimp3lSx1/E3lblh6r1PjRY9bWhkcLoxBGgXl7hjdkzEgl
	y/g4L0+Ek+eCdBV12FJ3jdY=
X-Google-Smtp-Source: ABdhPJzlc0Zggspr8Cto8dM8HsXuYqdkHYszZmwu09XKCJ89gVohiVxquCEfHtkVH4aSHYXG1GX8xQ==
X-Received: by 2002:ac8:5c4e:0:b0:2de:7191:7480 with SMTP id j14-20020ac85c4e000000b002de71917480mr10169763qtj.489.1646671511395;
        Mon, 07 Mar 2022 08:45:11 -0800 (PST)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id 15-20020ac8570f000000b002e05a1f990dsm4841181qtw.65.2022.03.07.08.45.07
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 07 Mar 2022 08:45:10 -0800 (PST)
Date: Mon, 7 Mar 2022 11:45:02 -0500
From: Mark Johnston 
To: Andrew Turner 
Cc: Ronald Klop , bob prohaska ,
	Mark Millard , freebsd-arm@freebsd.org,
	freebsd-current 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Message-ID: 
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay>
 
 <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
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: <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
X-Rspamd-Queue-Id: 4KC47x4SgQz4j3s
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=IUstT1Rg;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-0.70 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCPT_COUNT_FIVE(0.00)[6];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 FREEMAIL_CC(0.00)[klop.ws,www.zefox.net,yahoo.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1987
Lines: 46

On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
> 
> > On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
> > ...
> > A (the?) problem is that the compiler is treating "pc" as an alias
> > for x18, but the rmlock code assumes that the pcpu pointer is loaded
> > once, as it dereferences "pc" outside of the critical section.  On
> > arm64, if a context switch occurs between the store at _rm_rlock+144 and
> > the load at +152, and the thread is migrated to another CPU, then we'll
> > end up using the wrong CPU ID in the rm->rm_writecpus test.
> > 
> > I suspect the problem is unique to arm64 as its get_pcpu()
> > implementation is different from the others in that it doesn't use
> > volatile-qualified inline assembly.  This has been the case since
> > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 
> > .
> > 
> > I haven't been able to reproduce any crashes running poudriere in an
> > arm64 AWS instance, though.  Could you please try the patch below and
> > confirm whether it fixes your panics?  I verified that the apparent
> > problem described above is gone with the patch.
> 
> Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks.
> 
> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
> index 09f6361c651c..59b890e5c2ea 100644
> --- a/sys/arm64/include/pcpu.h
> +++ b/sys/arm64/include/pcpu.h
> @@ -58,7 +58,14 @@ struct pcpu;
> 
>  register struct pcpu *pcpup __asm ("x18");
> 
> -#define        get_pcpu()      pcpup
> +static inline struct pcpu *
> +get_pcpu(void)
> +{
> +       struct pcpu *pcpu;
> +
> +       __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
> +       return (pcpu);
> +}
> 
>  static inline struct thread *
>  get_curthread(void)

Indeed, I think this is probably the best solution.

From nobody Mon Mar  7 17:25:38 2022
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 43E291A0DDD9
	for ; Mon,  7 Mar 2022 17:25:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KC52l1nvTz4rCh
	for ; Mon,  7 Mar 2022 17:25:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646673944; bh=2fqLh5m9USW/r4fn5/lSyKOlM8QhF8BndyysYpkPjx8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IyoodA77TpQdrigzu9DbE4xm2QbUonaOgpNu62PRy8FSvCu3Y24Q5c65SwyQUaNcF7xpFaceKdY/E0u35z0Ft8ERYx6l82OyUW/9I9hfSfPA7fzNJ19RU54+Mm/t8Cug+undMazPekRUcxDhe4xSul3zcKcjNDwyBLBhODLWA64vpKEJhgAa9Yq3UA1t1s8yTNFquWH0l/n7xi7wA0hrDAblNj6GVKD+JBcnl/F1AaGr60tdvaz2X6rziLvUwJyxc4mcGu0CFL9u85RsOgmHxhR4oQSQ6NBWX9u9XwJ4Xa/lM9Z4zCk99xzw9N5CCnP11v15UsXu8u+2Y/W4hxlE4w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646673944; bh=2IZdYycHNH60YqxM4HDE1slXwvt+sH0PxpkciOJknpm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MO95kKuj62BIvZ8Gc/e89LECfMsSPkNRvzQkA19tZDR8i1B0zDuBpsPJqaEx82IZmoLcYhUfU7srxlO4ra2a32AHZkX3CgLk83OKQibBbIvQT1h2UIWz2cOy2qXUZuIw6nOmj7abnmgQco80tOe+ZzWhplfB/LfZRqlyfRQO8ZDl7WSLPEqRSBhtbEOEHVSbgDio3nb9femB64A6eO9nlAjKAtA0Ni5H7f5idnCgXGBN5FYXF9yrUaL2S4hpCWMaeyThSAtOIbX1gwVahaZQAVA8nhoeWfkI2oANVFGbO713H2k7oTZZTPxvbZcmUDTLGtDADNwLFm+I3EaP+iKx2Q==
X-YMail-OSG: o9zmkuEVM1nloZiFpADWG_lm8U1rKpXAPCSIbgDumcoFAB5T2vlgKN4OxW2Yo7C
 _GEsITBTnVhUIk1V8svYsT3Ublzr4xlO9dh.GMAG8uHMwmzBXm8rWaQN5d2y__gSVcSXnOOai9Wb
 hc1f7cxNV4EfJSAqDmCepcbb_CiLIGWeynVjmqgap4ppdd77zc9rnvSxG6__pF0sEHWi53Y5Di3r
 iFC_5QWivFqib5k98T4VUa8gdJkTI.A7UXo9il49_ubgdpHLvPnGHIN4LPxTH68jZfwOU7FofdIl
 Wa6qY1.TU_AAooQPINscqIwTqafiet_DyeWpMLezU0imLmzDLpHB4mJA4DirK80enp_MqPIiMGjL
 d75SLQI9XGgeFuQXgHJDGwm6BpxOecM1Dt4YKsEKOxGGD5VhpfrGKG7hpXzQ0dh7nJRZtH0TPveB
 0sFgGOCahxoM924.gm8eAP9bKi04q__0A1mMYir6PQW4keR4hnn1.Y3Q28wYSIeWfoDrv4iOzuym
 nhgpAbSmVQhllIR1FMiT8xNzVCyphDatJsdgXQiQz0uM6bPr.ZHeUqoX5rxwwBy181xNIbFO.vIS
 F9oMYjzvg5L8wKi.EUZYqd.EIoDFBC0XnJ3lnj7sZ1GZn4tywMqJAu9CtP0usSGWdN1IyQQ5l2vG
 PEz6wv8OWQxK_STMEjt3J2DxJuqwtLm39F8x3OIGK4u.kKU.sz6SVfi.4EA6WPLXP.WM3anEmaYJ
 wX75usoRDvMlnGByRRaulCMLAlQzHR_ISz4u3Yv7sDpgGUeQa1sdSGwiO32kIIysHr6_KMnWoIY_
 FFtpaWHrQ8eI_mhFaIQdZEnQ89zIEMbaR1pecsGJ4rfthWMaWLV0fyGpILALtRzlr3KllybDGR2E
 Bm2BE7K56OydyGop6EMBn6ZI._scRjuoPQd.Dok2rFxMnImfIs9TkAVkTdMqJAMCvHS7v6TptuL1
 RRDzipl4OKtiYJXNsV5GgxfFrwOYvE5gV6h9OxI9hfjeheMCFUEHTc.cMJF8hoG8dYhHebY1Q_KK
 9EdCH.pKj3ZnnGxyvrlTMbGy6ktHVET7SztXykMlmHDot1P1lhzUDJyt3E8KxSUvoOxBYewd2QSj
 qrCe8NOTDbkC_AhKaXrG51NqapKf7jfyha_w1Lc01Yo7pUVwzroVm3cJvkINS_tGA0OFaJ4fgf0j
 kBYwZVkncq0qG_yGqynPacHNMMoI1bpC9UmdRQBfZNUXnDmHrRBzOqjK81c2A8YqLNl1_At_rg._
 1zINlZTdM39EqzV9Ci778ud1i_k.t_2COspjZtQYCjnuyOJomtEjss45ZtZplPKlGnjz99v1xW8J
 zLgH8ztcs0QLcTxpEnHfk9rwlpth8ser5iS9GctnOq7SN0m8TEiN7Org0AftKUIQIfqOv7RBN_4M
 8JB7FokUq8eJflPMAwbUy4yc36d5Xw7CZjd0eOBdMJcBOgpkWxF5WhRGC.l2lO6peAEvmmWOKs1F
 cWogYL_.y3qiUXoyGk2Wfi.EGxKnB8rZ7GF7aIDSXhX2Mjwkxyxe0Do3buFhVVOD1shbPIf9IueF
 fH.pxr7OpFkNZaa8VBSKC225uh09j56R8bcPX4Vy04JTy9FEf6ychmou_2YSrblVcf1dijrB8yeN
 gYNszMAgFdS7Zie_ztl9YyuEzsCxv6aZbK9LHWJqE.zDOpfO7aYoL3GBQHrFicAaaSrAtUfETDlU
 BhrC5gZmZgUW0wdGNbhsiQstbwIBJi3yCHD5xrUN6jgaktJWnBwF9LfdXo5CekfeuHZQw7egpG7b
 _hgJNITshxvLN860ENQZmctot7KtBFjoPJ8ydPAEABbdcM8gtDpJ_L.ZgsBiwgT8D0mkzeHDV_9r
 lK14IV_I.S61Rhp9OelgHS0DrTVY.M2wPyTwsuit1._N41F14UwevVfImx_8HbXJMAGJNLMC7MQ1
 Ok9kP1OXlHtq02Sw0kZDiJOunruD5nfxgqMHZBCKL56THuLN2S7hdyAsVpuTv9.J9MGx60Hb4wxr
 JKXZqUIS7HgJXxAwsmoyorWcjiwwqqoxMAfwU4vYLvY6cUZC6H_hkcV6t00G9R1GEMegvxVGAuyb
 tivie2xjQTyjmMT87wl6LQpiKRz4pTzeFw.5aPcrI9riB0TtngG.cqeA2aYBR3ZxC5py.B3dOHkA
 rfSD_Bz8V_253pRdjuP5s1LHPBI3a8.Iu8BzI8tmJrSXoIHEyG9b.oI2fLxbJsUzAk2yn3k0rEkI
 .RoYjxL4FRSqfBbgLWYgPMr02OcnL8_H5FySXizq_zc3UMu8vUNSiinAVpmdzqxQKbBQXNf0PotP
 k49h811.f728jg8iQ
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 17:25:44 +0000
Received: by kubenode523.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c8982908dc2d63c5ff62b39a41b78f1a;
          Mon, 07 Mar 2022 17:25:38 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: PCF8574 I2C configuration for 14.0-CURRENT on a RPi2B
From: Mark Millard 
In-Reply-To: <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org>
Date: Mon, 7 Mar 2022 09:25:38 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B2150A8-40AA-47CE-9A78-985129865A7E@yahoo.com>
References: <47C61079-AB2E-4E81-AD95-F6042477D4E8@yahoo.com>
 <20220307144832.6D1771A0C112@mlmmj.nyi.freebsd.org>
To: Don Kuenz 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KC52l1nvTz4rCh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=IyoodA77;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.51 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.51:email];
	 NEURAL_SPAM_SHORT(0.99)[0.994];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.51:email];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5486
Lines: 190


On 2022-Mar-7, at 06:48, Don Kuenz  wrote:

> Attempt number four to answer Mark's question in regards to the origin=20=

> of config.txt content. (The em control character spewed out by "man"=20=

> mangled my mail earlier.)
>=20
> Mark wrote:
>> Don wrote:
>>>=20
>>> and /boot/msdos/config.txt looks like this:
>>>=20
>>> root@generic:/boot # cat /boot/msdos/config.txt
>>> init_uart_clock=3D3000000
>>> enable_uart=3D1
>>> kernel=3Du-boot.bin
>>> kernel7=3Du-boot.bin
>>> dtoverlay=3Dmmc
>>=20
>> config.txt seems fine up to here. But I've never seen
>> anything indicating that the following notation is
>> valid for config.txt files:
>>=20
>>> / {
>>> gpioiic0 {
>>>   compatible =3D "i2c-gpio";
>>>   pinctrl-names =3D "default";
>>>   pinctrl-0 =3D <&pinctrl_gpioiic0>;
>>>   scl-gpios =3D <&gpio2  3 GPIO_ACTIVE_HIGH>;
>>>   sda-gpios =3D <&gpio3  5 GPIO_ACTIVE_HIGH>;
>>>   status =3D "okay";
>>> };
>>> };
>>=20
>> If you have a reference indicating otherwise, I'd
>> be interested to know what it is.
>=20
> # man gpioicc

config.txt is not something from FreeBSD at all, its
is from/for RPi* firmware only and is common across all
contexts that use the RPi* firmware. Only RPi* specific
documentation applies to the content supported in
config.txt on the msdos file system for an RPi*.

In other words: man gpioicc does not in any way refer
to the config.txt file involved in booting an RPi*
(for any operating system). To my knowledge no FreeBSD
man page covers much about files that are specific to
the RPi* firmware (ignoring, say, drivers strictly
specific to RPi* contexts).

> =
------------------------------------------------------------------------
> GPIOIIC(4)	       FreeBSD Kernel Interfaces Manual 	    =
GPIOIIC(4)
>=20
> NAME
>     gpioiic - GPIO I2C bit-banging device driver
>=20
> SYNOPSIS
>     To compile this driver into the kernel, place the following lines =
in your
>     kernel configuration file:
>=20
> 	   device gpio
> 	   device gpioiic
> 	   device iicbb
> 	   device iicbus
>=20
>     Alternatively, to load the driver as a module at boot time, place =
the
>     following line in loader.conf(5):
>=20
> 	   gpioiic_load=3D"YES"
>=20
> DESCRIPTION
>     The gpioiic driver provides an IIC bit-banging interface using two =
GPIO
>     pins for the SCL and SDA lines on the bus.
>=20
>     gpioiic simulates an open collector kind of output when managing =
the pins
>     on the bus, even on systems which don't directly support =
configuring gpio
>     pins in that mode.  The pins are never driven to the logical value =
of
>     '1'.  They are driven to '0' or switched to input mode =
(Hi-Z/tri-state),
>     and an external pullup resistor pulls the line to the 1 state =
unless some
>     other device on the bus is driving it to 0.
>=20
> HINTS CONFIGURATION
>=20
> 
>=20
> FDT CONFIGURATION
>     On an FDT(4) based system, such as ARM, the DTS node for gpioiic =
conforms
>     to the standard bindings document i2c/i2c-gpio.yaml.  The device =
node
>     typically appears at the root of the device tree.	The following is =
an
>     example of a gpioiic node with one slave device on the IIC bus:
>=20
>     / {
> 	     gpioiic0 {
> 		     compatible =3D "i2c-gpio";
> 		     pinctrl-names =3D "default";
> 		     pinctrl-0 =3D <&pinctrl_gpioiic0>;
> 		     scl-gpios =3D <&gpio1  5 GPIO_ACTIVE_HIGH>;
> 		     sda-gpios =3D <&gpio7 11 GPIO_ACTIVE_HIGH>;
> 		     status =3D "okay";
>=20
> 		     /* One slave device on the i2c bus. */
> 		     rtc@51 {
> 			     compatible=3D"nxp,pcf2127";
> 			     reg =3D <0x51>;
> 			     status =3D "okay";
> 		     };
> 	     };
>     };

This document does not say where the above text would
go for any system or what toolchain (if any) is involved
in putting it to use.

There can even be issues like the RPi* firmware and
FreeBSD kernel disagreeing about .dtb content and
the like. The FreeBSD firmware is still somewhat active
when FreeBSD runs as I understand. If true, it could
be important to have the RPi* firmware have the same
.dtb context as the kernel, normally by updating what
the RPi* firmware uses and letting the kernel
(indirectly) get its dtb information from the RPi*
firmware.

(I mention that because, if I remember right, one of
the replies proposed working strictly on the FreeBSD
side. I'm not sure such is appropriate to an RPi*.
However, I'm not an expert.)

>     Where:
>=20
>     compatible      Should be set to "i2c-gpio".  The deprecated =
string
> 		     "gpioiic" is also accepted for backwards =
compatibility.
>=20
>     scl-gpios sda-gpios
> 		     These properties indicate which GPIO pins should be =
used
> 		     for clock and data on the GPIO IIC bit-banging bus.
> 		     There is no requirement that the two pins belong to =
the
> 		     same gpio controller.
>=20
>     pinctrl-names pinctrl-0
> 		     These properties may be required to configure the =
chosen
> 		     pins as gpio pins, unless the pins default to that =
state
> 		     on your system.
>=20
> SEE ALSO
>     fdt(4), gpio(4), iic(4), iicbb(4), iicbus(4)
>=20
> =
------------------------------------------------------------------------
>=20
> I'll take a closer look at "man dtc" and "i2c/i2c-gpio.yaml"
>=20
> =
https://mjmwired.net/kernel/Documentation/devicetree/bindings/i2c/i2c-gpio=
.yaml
>=20
> Other replies in the thread provide me with additional food for =
thought
> for the time being.
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar  7 18:03:51 2022
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 3A98F19F54CA
	for ; Mon,  7 Mar 2022 18:04:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KC5ts0mDZz3D71
	for ; Mon,  7 Mar 2022 18:04:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646676237; bh=QNJmAQMRxgmElsmewRjV6HwzLY6BrLjlqtFuBV2iLXY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G18lIaRC0WkvovsONRYxNO6qaxtOIkNxt6nVsb3zuk29jBwj44ukb8P8DTh3q+Cyj2I2czWjkTRhHi3NUOoQv6ihtfBcNa6GSfewkdDZpw8lwnxcUnHTczfQxsjrpqv4S+Uy9eoXCchFDSODkzyBRjhBCY4wXQjQvc6p8sLpTqmp4KqkM007Hgxn8JUhPiQqyfnrflqjSLgrN2jOBKwDrPmGpmS8117riUicAv7n7E8cL60Ujqz3wlz5R2wWcHlm3PTCqi/abXGrGDxnTO/CrzYqlOcC32SRZPvMNWNv7khc9LQqMYwqDCxXllIBjaM96dVBNvW2HsSIztxLycjyww==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646676237; bh=D3B0Zj4SUlq3Qcq4JJd0joW0jjk5s2cohbbX9zsEFNu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FxoXkzSrJIgquaSw/URh2GneEDRbsyHYd4+6hQ4lQoqeX47OVk6WzRJUk/RciQd98bm+s3D+yj0wV68Gp5ccEFWRPUF07hfHyN+3UyT1xsqvzK+x4kkKNoqTFvhPArsBHIGE3gtLY3U9TLZAoFahWWHoxS0b8Icgl2GdRz6Wn5AQpiixDKPt1ciu3UjS+joLkFh58mbfqVK3kGU2yPjVvqD57y/2JXFLLcaDKHalTeAknwUZ06eut2bEztaiVPNZUw5j5MUKOuKCBbPVoxlhHTYw1bBZD0rOn8PsiaDPSxrbRQPBKFsgYoth2RyoPYcFGgqMhjhQl5Uf5UTQOqHrTw==
X-YMail-OSG: f0XSjhAVM1ntBc.DAjrpYvHF8g7bQAQyqUXDaPNvHjX0cpGrck4Ss1wEdNEWdWg
 E76LC0CMwrzz7xQ8zgGMm6ozXOxHvaSq25HI4arbyvFJr6qeG.UMnQznP1iqu2q_W6XWyYlET7Tx
 cXRPF_1sZXr1GvI9xS6QMngRuaYuSemRHNd_BSSmy98sRvYskmX08cPq6tgz.WsIskxUT7LJa_XE
 jyfn0MjIc4sLi7S..DdbUUFrFQGE48pLEuRCnKQcoPNnP2SmPru.L14W1dG1ENq.o1FDUbe3gKro
 Bh4gAxVd23EqncWBulqaPa6A6GVia_4__LrHH1WMzo0vNcA1uZlH7gB59al73nng3kQgxF2jRgMl
 UT6zblYD3NcYp6xh.zw3b.hBM3h0CCeufoBI1X83IBCZy1SUMrtUIE7pj5VLvtfyEsBtP18X0_sZ
 1LNhNFaA8CJIidEleS0a98xEqZvNwiw_KJAe_vV2dRuB4JrzHyOUMQUN0FICV97hRKEozaX6Ea7W
 h79A5E0xBUVEaZlIkcAdjyUsyBQDmjg.PoQKm3sN78lhP25C3lgiv.wBxY.YzWdSM7DGS1Xc2wQD
 Qew8vVGgzTHVz8JgdNidrwiQEbo6IiJI1P85bO0NTA2Fo01y0dS7G_3AEN6iFQPFAwsKCWykIpIy
 CfFUOEWpdMqch_ARfcW5X_ffTL2g4iD_ZCbIjyDS2j7iFRfPx_2QC_7Cabr6btd_UkVVkX3f5Cpl
 5XiViVBlrkbPZ4_.UoPL72XbZjJqyVUub3jeVLUsF5X53._jVIbKjE1G5bbqRKK1KQJIvoYZ8U2a
 kFZe6tyPgSWmhcVBs6ru4CphT1tjmiRgZYNfyPZYUBXwk7F0AOKfxXmL4KZX.PfxOoUqzCZW4uIw
 IM41JrnIB1PTiWVT6WS1.0php59gJlHGz.z0KN2qfgDA8iIOxfBuo.i_NH6nikr4SLMdbvCtv7KJ
 1VGWiXBhsUTzJeSNQL1rCcI9h2qleVaibpp4Pc9HnyS6y_dNLbNpNv_Gsv8vYkL4g49bhxHj2X5b
 EcNiN6rCZHdGQAvLqf4A6SSMiFlnSO.dLFT8QvQ5pOY10NsKSAZFXUnrAACaRDrZQ8PzYNPXdlBq
 nzWErbuXt7n9xdmy6FPVEOr1Dnhl8Cdl7vbpjbR.bZn5W_cUcmU9z4UeGPUoJRRHBTxBcti8wUVp
 3rj_dVQCURlLkRNv57IgfmA4ZeHEl3BbCYnyNFrXbsFHnoYY0BgHINjV_zWNNROObQyKEryfcHdk
 MS2Uy.jnpvnNK2mbwtNTBflsUM0p9BzI.VBYcTih9kxJSuOa.Exj08MIxObJsushj5.uy0MGPpBv
 cSGpYcd4D9jiumShDWCUMDGg5hSG.ioCZU7h3rc.OqClOo6r2xM5NQx7QI9_hg13yrtAKsv0Kl7j
 GPtxgeNrIJ8kskLEpkq8NH_907QK_Bc9YRSPNwJ5jSV2XCLYtvqoQ_WawILeCvVMyW41eEWU90YI
 qSJptWb5JwdnD6CeYl5SX0n10D6Wx0xo12zcelN96ZFD.a3M7ql_QlvCkhI2purGUBFnAZZvc1BO
 hZUI3y0KSTmLGYPqoseQRSqOHW1KHs4TaXQgyThdk8dweQSDVtWttm9S8KMqDTmfyJN15rhQRvtl
 sNhWNZZuD13KF0NyQrVRE..n8J_36OiF2twwpaW0NjaD2VDDYzx4fqXrTimXTC9A7LayW0VYLo8m
 NvvBmNvZomV0RuYhTNmUv6ngbhPxUp1F5LejWh2DDsJ0i6g7DJe_IimoDsL2RUBS_vRV5bOgNAGK
 .H4dLb3n9PCeb1ml7ZjaKWFLCkBd0C3ysbsug5HiRk9KQXJJKA5deg4qdF8.J7NyM9ReEzJrq6UU
 iWsZGniT7mjgreGLmM6mi.lbnvKeJrgHzIVVCC7z_dMLiAUxfkRNTWh6uo1GFmPH8Q0okKnjYPeQ
 OsDImabpVwq790f23IMRreoZ07.QuyTVDs7E5vPjCoFoa3R9xmAzfTB5CY1HTQkEStvj3n8rpBAX
 GAQhrkhlkeRFevnJB0_wH5Ut50rHhGQjTPhBgmcpRnm6d8bN_rI.PdNXnpul8Ekf7jGgHanvtKW4
 mP5SC_d1jwQNGTy4goiMri4yYuTn.tWPVNcMeUq5sMjPc2y4O3qFL0k4zZMF4Ciaa084PK_rXJNe
 Pvq0TZJF80EkL3W7_5LDtC1F54cnz9.Lf71nBo1Cpu.Fd9MkgNVwzGFmGkzP8Xd2er.14dpePSRD
 oBbpplsw2o1_dwhAdgg7yOL3z29Y5NJmctztjJfYZv_t2jc_pjKF7LRnNMQpvribcQRd5f9bjnLm
 Vc1gLEf8cIIaeEhHfgSPN0huC7JX6iDxGViwHQAAUVUDtg6agrZAmPf4gSn910Jz964vUE9NOAuS
 jwgAOSQ_EMRGaEBg-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 18:03:57 +0000
Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID beef9abb4f3e81af87e938ac5564e7ad;
          Mon, 07 Mar 2022 18:03:53 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
From: Mark Millard 
In-Reply-To: 
Date: Mon, 7 Mar 2022 10:03:51 -0800
Cc: Andrew Turner ,
 Ronald Klop ,
 bob prohaska ,
 Free BSD ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
  <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
 
To: Mark Johnston ,
 FreeBSD-STABLE Mailing List 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KC5ts0mDZz3D71
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=G18lIaRC;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2821
Lines: 87



On 2022-Mar-7, at 08:45, Mark Johnston  wrote:

> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
>>=20
>>> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
>>> ...
>>> A (the?) problem is that the compiler is treating "pc" as an alias
>>> for x18, but the rmlock code assumes that the pcpu pointer is loaded
>>> once, as it dereferences "pc" outside of the critical section.  On
>>> arm64, if a context switch occurs between the store at _rm_rlock+144 =
and
>>> the load at +152, and the thread is migrated to another CPU, then =
we'll
>>> end up using the wrong CPU ID in the rm->rm_writecpus test.
>>>=20
>>> I suspect the problem is unique to arm64 as its get_pcpu()
>>> implementation is different from the others in that it doesn't use
>>> volatile-qualified inline assembly.  This has been the case since
>>> =
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e=
99e73762 =

>>> .
>>>=20
>>> I haven't been able to reproduce any crashes running poudriere in an
>>> arm64 AWS instance, though.  Could you please try the patch below =
and
>>> confirm whether it fixes your panics?  I verified that the apparent
>>> problem described above is gone with the patch.
>>=20
>> Alternatively (or additionally) we could do something like the =
following. There are only a few MI users of get_pcpu with the main place =
being in rm locks.
>>=20
>> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
>> index 09f6361c651c..59b890e5c2ea 100644
>> --- a/sys/arm64/include/pcpu.h
>> +++ b/sys/arm64/include/pcpu.h
>> @@ -58,7 +58,14 @@ struct pcpu;
>>=20
>> register struct pcpu *pcpup __asm ("x18");
>>=20
>> -#define        get_pcpu()      pcpup
>> +static inline struct pcpu *
>> +get_pcpu(void)
>> +{
>> +       struct pcpu *pcpu;
>> +
>> +       __asm __volatile("mov   %0, x18" : "=3D&r"(pcpu));
>> +       return (pcpu);
>> +}
>>=20
>> static inline struct thread *
>> get_curthread(void)
>=20
> Indeed, I think this is probably the best solution.

Is this just partially reverting:

https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56

If so, there might need to be comments about why the updated
code is as it will be.

Looks like stable/13 picked up sensitivity to the get_pcpu
details in rmlock in:

https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D543157870da5

(a 2022-03-04 commit) and stable/13 also has the get_pcpu
misdefinition in:

=
https://cgit.freebsd.org/src/commit/sys/arm64/include/pcpu.h?h=3Dstable/13=
&id=3D63c858a04d56

. So an MFC would be appropriate in order for aarch64
to be reliable for any variations in get_pcpu in stable/13
(and for 13.1 to be so as well).

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar  7 19:04:09 2022
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 2DAAB1A1F105;
	Mon,  7 Mar 2022 19:04:14 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a])
	(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 4KC7DF0d3Bz4jrG;
	Mon,  7 Mar 2022 19:04:12 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qv1-xf2a.google.com with SMTP id e22so12812278qvf.9;
        Mon, 07 Mar 2022 11:04:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=esZKyfTOPNgtjph7i3nXEvXHagQgF99ajXO9YY9+DcA=;
        b=HPCKDDbtO/a2bGU0A4jEhKuQUdPD9kptMpjYNICoshgaRLrvEEABe7WblRyU7V0wmv
         hYVTK4OlSAXKwbSmV6kHrz5PO4RWqM65DzeU5EJtIEUderTZ+tPfk3XrKzUQdoFJlBzz
         JKnunZK9u+qLpRXsn0uHEhL2B6Vp9V0wZr6ldN+ZBGaRwkqdOBOlD9Sfjp6TeRLbLBif
         YFS/9KvEcdJZOlzkzEUTbJcsFX6LOz98lakup6sBdviMky0n3KtWlLXyGFD2S7ZguI/G
         gxLB41m32vtxK0H8hr6DqaEkMx5/AhoG5VRgnEJOtheK4rxJZvpzEGz4rTQ3plmxxCWR
         VInw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=esZKyfTOPNgtjph7i3nXEvXHagQgF99ajXO9YY9+DcA=;
        b=Bhsl154d+G8oc+vqwhJauFTkBLHjLoAc/8bnpBB7y7jSIX+hxrrio6h3gwwMQULBzn
         o3TxD5X412AO0Qz2d7/8q4Y/U1yNfF0RHW+LW8EMKm15IsVDELPsLevTI7puitDSim9w
         VTS9x4zJuCOCDMwNbsXhTpP4wqSTK5wgvPEDbEWPcfSLgTRbcYAyP59j4zpVUTv9cNBH
         Brsm777aqvmpd8EJlKnwWvMW1CjcrbkHYQmEqXEieP1ktytZ+v2WNWrxZzmgPKexR1cV
         qasFVXFar9FYbdrJNcxCX59/KdHfXyYRTE76UKG3rOzh1f8uIq8BHtOU97PE0vVnh3VH
         /qcg==
X-Gm-Message-State: AOAM532ZoCOu8lbbeL9jU9ah+CNa5xmttMFkK+C+vxjbKEIDtrgUCy44
	a4W1qyEo36Me1xBGEeEAAVo=
X-Google-Smtp-Source: ABdhPJy7JZKbZ0toPNLBBJU8r3OvQzaua82asbIDbzSEYtvHi8xspeNNTsqmyhjQSHaQhPS73TgJdA==
X-Received: by 2002:a05:6214:d06:b0:435:6794:f929 with SMTP id 6-20020a0562140d0600b004356794f929mr9402128qvh.101.1646679852446;
        Mon, 07 Mar 2022 11:04:12 -0800 (PST)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id x26-20020ae9f81a000000b005f1916fc61fsm6400480qkh.106.2022.03.07.11.04.11
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 07 Mar 2022 11:04:11 -0800 (PST)
Date: Mon, 7 Mar 2022 14:04:09 -0500
From: Mark Johnston 
To: Mark Millard 
Cc: FreeBSD-STABLE Mailing List ,
	Andrew Turner ,
	Ronald Klop ,
	bob prohaska ,
	Free BSD ,
	freebsd-current 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Message-ID: 
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay>
 
 <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
 
 
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: 4KC7DF0d3Bz4jrG
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=HPCKDDbt;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.68 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.98)[-0.983];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from];
	 MLMMJ_DEST(0.00)[freebsd-stable,freebsd-arm,freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3361
Lines: 89

On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote:
> 
> 
> On 2022-Mar-7, at 08:45, Mark Johnston  wrote:
> 
> > On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
> >> 
> >>> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
> >>> ...
> >>> A (the?) problem is that the compiler is treating "pc" as an alias
> >>> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> >>> once, as it dereferences "pc" outside of the critical section.  On
> >>> arm64, if a context switch occurs between the store at _rm_rlock+144 and
> >>> the load at +152, and the thread is migrated to another CPU, then we'll
> >>> end up using the wrong CPU ID in the rm->rm_writecpus test.
> >>> 
> >>> I suspect the problem is unique to arm64 as its get_pcpu()
> >>> implementation is different from the others in that it doesn't use
> >>> volatile-qualified inline assembly.  This has been the case since
> >>> https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 
> >>> .
> >>> 
> >>> I haven't been able to reproduce any crashes running poudriere in an
> >>> arm64 AWS instance, though.  Could you please try the patch below and
> >>> confirm whether it fixes your panics?  I verified that the apparent
> >>> problem described above is gone with the patch.
> >> 
> >> Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks.
> >> 
> >> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
> >> index 09f6361c651c..59b890e5c2ea 100644
> >> --- a/sys/arm64/include/pcpu.h
> >> +++ b/sys/arm64/include/pcpu.h
> >> @@ -58,7 +58,14 @@ struct pcpu;
> >> 
> >> register struct pcpu *pcpup __asm ("x18");
> >> 
> >> -#define        get_pcpu()      pcpup
> >> +static inline struct pcpu *
> >> +get_pcpu(void)
> >> +{
> >> +       struct pcpu *pcpu;
> >> +
> >> +       __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
> >> +       return (pcpu);
> >> +}
> >> 
> >> static inline struct thread *
> >> get_curthread(void)
> > 
> > Indeed, I think this is probably the best solution.

Thinking a bit more, even with that patch, code like this may not behave
the same on arm64 as on other platforms:

critical_enter();
ptr = &PCPU_GET(foo);
critical_exit();
bar = *ptr;

since as far as I can see the compiler may translate it to

critical_enter();
critical_exit();
bar = PCPU_GET(foo);

> Is this just partially reverting:
> 
> https://cgit.freebsd.org/src/commit/?id=63c858a04d56
> 
> If so, there might need to be comments about why the updated
> code is as it will be.
> 
> Looks like stable/13 picked up sensitivity to the get_pcpu
> details in rmlock in:
> 
> https://cgit.freebsd.org/src/commit/?h=stable/13&id=543157870da5
> 
> (a 2022-03-04 commit) and stable/13 also has the get_pcpu
> misdefinition in:
> 
> https://cgit.freebsd.org/src/commit/sys/arm64/include/pcpu.h?h=stable/13&id=63c858a04d56
> 
> . So an MFC would be appropriate in order for aarch64
> to be reliable for any variations in get_pcpu in stable/13
> (and for 13.1 to be so as well).

I reverted the rmlock commit in stable/13 already.  Either get_pcpu()
will be fixed shortly or 13.1 will ship without the rmlock commit.

From nobody Mon Mar  7 20:54:26 2022
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 CD11219F3841;
	Mon,  7 Mar 2022 20:54:29 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KC9gT00PNz3rwN;
	Mon,  7 Mar 2022 20:54:28 +0000 (UTC)
	(envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 7 Mar 2022 21:54:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1646686466;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=5WNf6aELst4UDlOXYajv/u8+6WSw4kSQiOjBQwM7D+M=;
	b=jAlcHq6vTJ7WTgxh0OfUPPh78lWhxKuZAUdEMpYO5yY2sZ6V5+/e4cgpvogNum7vStsSAj
	RumkfT+eKvfn/gyo3UserZHdTngoyzsNoVlH+jL5IGLuM36gkkCgXmWjgN9zgfoo8wYX1L
	YGqk2OtcZX6e3d+mBc1Vxo+p9RC4dHBmuXDTiPQmI6OM0H0sxbBkxrhZ5KMUNwr/R28BVf
	R9MljJf/KNllvctYD0HCQOPz8qckUKIFCCu5mWuKjL3dUyozp9GFcWS5D+QOyi+AB3Qkk/
	8OVkU0uvkCaM7gL7nLu4NAmoEu0BECadRgWqNK02Bw8aYQvWhje3o6CY928Tzw==
From: Ronald Klop 
To: Mark Johnston 
Cc: bob prohaska , Mark Millard ,
	freebsd-arm@freebsd.org,
	freebsd-current 
Message-ID: <1302689164.173.1646686466515@mailrelay>
In-Reply-To: 
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay> 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64
 Feb 28))
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="----=_Part_172_1254189170.1646686466401"
X-Mailer: Realworks (599.211.aa1e011)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KC9gT00PNz3rwN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=jAlcHq6v;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl];
	 FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 26276
Lines: 416

------=_Part_172_1254189170.1646686466401
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mark Johnston 
Datum: maandag, 7 maart 2022 16:13
Aan: Ronald Klop 
CC: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current 
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))
> 
> On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> > Dear Mark Johnston,
> >
> > I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.
> >
> > I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.
> >
> > Last panic:
> >
> > panic: vm_fault failed: ffff00000046e708 error 1
> > cpuid = 1
> > time = 1646660058
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> > vpanic() at vpanic+0x174
> > panic() at panic+0x44
> > data_abort() at data_abort+0x2e8
> > handle_el1h_sync() at handle_el1h_sync+0x10
> > --- exception, esr 0x96000004
> > _rm_rlock_debug() at _rm_rlock_debug+0x8c
> > osd_get() at osd_get+0x5c
> > zio_execute() at zio_execute+0xf8
> > taskqueue_run_locked() at taskqueue_run_locked+0x178
> > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> > fork_exit() at fork_exit+0x74
> > fork_trampoline() at fork_trampoline+0x14
> > KDB: enter: panic
> > [ thread pid 0 tid 100129 ]
> > Stopped at      kdb_enter+0x44: undefined       f902011f
> > db>
> >
> > A more recent kernel (912df91) still panics. See below.
> >
> > Do you have time to look into this? What can I provide in information to help?
> 
> Hmm.  So after my rmlock commits, we have the following disassembly for
> _rm_rlock() (with a few annotations added by me).  Note that the pcpu
> pointer is stored in register x18 by convention.
> 
>    0xffff00000046e304 <+0>:     stp     x29, x30, [sp, #-16]!
>    0xffff00000046e308 <+4>:     mov     x29, sp
>    0xffff00000046e30c <+8>:     ldr     x8, [x18]
>    0xffff00000046e310 <+12>:    ldr     x9, [x18]
>    0xffff00000046e314 <+16>:    ldr     x10, [x18]
>    0xffff00000046e318 <+20>:    cmp     x9, x10
>    0xffff00000046e31c <+24>:    b.ne    0xffff00000046e3cc <_rm_rlock+200>  // b.any
>    0xffff00000046e320 <+28>:    ldr     x9, [x18]
>    0xffff00000046e324 <+32>:    ldrh    w9, [x9, #314]
>    0xffff00000046e328 <+36>:    cbnz    w9, 0xffff00000046e3c0 <_rm_rlock+188>
>    0xffff00000046e32c <+40>:    str     wzr, [x1, #32]
>    0xffff00000046e330 <+44>:    stp     x0, x8, [x1, #16]
>    0xffff00000046e334 <+48>:    ldrb    w9, [x0, #10]
>    0xffff00000046e338 <+52>:    tbz     w9, #4, 0xffff00000046e358 <_rm_rlock+84>
>    0xffff00000046e33c <+56>:    ldr     x9, [x18]
>    0xffff00000046e340 <+60>:    ldr     w10, [x9, #888]
>    0xffff00000046e344 <+64>:    add     w10, w10, #0x1
>    0xffff00000046e348 <+68>:    str     w10, [x9, #888]
>    0xffff00000046e34c <+72>:    ldr     x9, [x18]
>    0xffff00000046e350 <+76>:    ldr     w9, [x9, #888]
>    0xffff00000046e354 <+80>:    cbz     w9, 0xffff00000046e3f4 <_rm_rlock+240>
>    0xffff00000046e358 <+84>:    ldr     w9, [x8, #1212]
>    0xffff00000046e35c <+88>:    add     x10, x18, #0x90
>    0xffff00000046e360 <+92>:    add     w9, w9, #0x1
>    0xffff00000046e364 <+96>:    str     w9, [x8, #1212]  <------- critical_enter
>    0xffff00000046e368 <+100>:   str     x10, [x1, #8]
>    0xffff00000046e36c <+104>:   ldr     x9, [x18, #144]
>    0xffff00000046e370 <+108>:   str     x9, [x1]
>    0xffff00000046e374 <+112>:   str     x1, [x9, #8]
>    0xffff00000046e378 <+116>:   str     x1, [x18, #144]
>    0xffff00000046e37c <+120>:   ldr     x9, [x18]
>    0xffff00000046e380 <+124>:   ldr     w10, [x9, #356]
>    0xffff00000046e384 <+128>:   add     w10, w10, #0x1
>    0xffff00000046e388 <+132>:   str     w10, [x9, #356]
>    0xffff00000046e38c <+136>:   ldr     w9, [x8, #1212]
>    0xffff00000046e390 <+140>:   sub     w9, w9, #0x1
>    0xffff00000046e394 <+144>:   str     w9, [x8, #1212]  <------- critical_exit
>    0xffff00000046e398 <+148>:   ldrb    w8, [x8, #304]
>    0xffff00000046e39c <+152>:   ldr     w9, [x18, #60]   <------- loading &pc->pc_cpuid
>    ...
> 
> A (the?) problem is that the compiler is treating "pc" as an alias
> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> once, as it dereferences "pc" outside of the critical section.  On
> arm64, if a context switch occurs between the store at _rm_rlock+144 and
> the load at +152, and the thread is migrated to another CPU, then we'll
> end up using the wrong CPU ID in the rm->rm_writecpus test.
> 
> I suspect the problem is unique to arm64 as its get_pcpu()
> implementation is different from the others in that it doesn't use
> volatile-qualified inline assembly.  This has been the case since
> https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
> .
> 
> I haven't been able to reproduce any crashes running poudriere in an
> arm64 AWS instance, though.  Could you please try the patch below and
> confirm whether it fixes your panics?  I verified that the apparent
> problem described above is gone with the patch.
> 
> diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c
> index 0cdcfb8fec62..e51c25136ae0 100644
> --- a/sys/kern/kern_rmlock.c
> +++ b/sys/kern/kern_rmlock.c
> @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
>  {
>     struct thread *td = curthread;
>     struct pcpu *pc;
> +   int cpuid;
>  
>     if (SCHEDULER_STOPPED())
>         return (1);
> @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
>     atomic_interrupt_fence();
>  
>     pc = get_pcpu();
> +   cpuid = pc->pc_cpuid;
>     rm_tracker_add(pc, tracker);
>     sched_pin();
>  
> @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
>      * conditional jump.
>      */
>     if (__predict_true(0 == (td->td_owepreempt |
> -       CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))
> +       CPU_ISSET(cpuid, &rm->rm_writecpus))))
>         return (1);
>  
>     /* We do not have a read token and need to acquire one. */
> 
> 
> 

Hi,

This patch paniced again:
x0: ffffa00005a31500                                                                                             
  x1: ffffa00005a0e000                                                                                                            
  x2:                2                                                                                                            
  x3: ffffa00076c4e9a0                                                                                                            
  x4:                0                                                                                                            
  x5:    e672743c8f9e5                                                                                                            
  x6:    dc89f70500ab1
  x7:               14
  x8: ffffa00005a31518
  x9:                1
 x10: ffffa00005a0e000
 x11:                0
 x12:                0
 x13:                a
 x14: 1013e6b85a8ecbe4
 x15:     1dce740d11a5
 x16: ffff3ea86e2434bf
 x17: fffffffffffffff2
 x18: ffff0000fe661800 (g_ctx + fcf9fa54)
 x19: ffffa00076c4e9a0
 x20: ffff0000fec39000 (g_ctx + fd577254)
 x21:                2
 x22: ffff0000419b6090 (g_ctx + 402f42e4)
 x23: ffff000000c0b137 (lockstat_enabled + 0)
 x24:              100
 x25: ffff000000c0b000 (version + a0)
 x26: ffff000000c0b000 (version + a0)
 x27: ffff000000c0b000 (version + a0)
 x28:                0
 x29: ffff0000fe661800 (g_ctx + fcf9fa54)
  sp: ffff0000fe661800
  lr: ffff00000154ea50 (zio_dva_throttle + 154)
 elr: ffff00000154ea80 (zio_dva_throttle + 184)
spsr:         60000045
 far:     2b753286b0b8
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 1
time = 1646685857
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>  



Will try the patch of Andrew next. Compilation might take a while so maybe it wil be tomorrow.

Regards,
Ronald.
 
------=_Part_172_1254189170.1646686466401
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Mark Johnston <markj@freebsd.org>

Datum: maandag, 7 maart 2022 16:13

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: bob prohaska <fbsd@www.zefox.net>, Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, freebsd-current <freebsd-current@freebsd.org>

Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))







On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:

> Dear Mark Johnston,

>

> I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.

>

> I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.

>

> Last panic:

>

> panic: vm_fault failed: ffff00000046e708 error 1

> cpuid = 1

> time = 1646660058

> KDB: stack backtrace:

> db_trace_self() at db_trace_self

> db_trace_self_wrapper() at db_trace_self_wrapper+0x30

> vpanic() at vpanic+0x174

> panic() at panic+0x44

> data_abort() at data_abort+0x2e8

> handle_el1h_sync() at handle_el1h_sync+0x10

> --- exception, esr 0x96000004

> _rm_rlock_debug() at _rm_rlock_debug+0x8c

> osd_get() at osd_get+0x5c

> zio_execute() at zio_execute+0xf8

> taskqueue_run_locked() at taskqueue_run_locked+0x178

> taskqueue_thread_loop() at taskqueue_thread_loop+0xc8

> fork_exit() at fork_exit+0x74

> fork_trampoline() at fork_trampoline+0x14

> KDB: enter: panic

> [ thread pid 0 tid 100129 ]

> Stopped at      kdb_enter+0x44: undefined       f902011f

> db>

>

> A more recent kernel (912df91) still panics. See below.

>

> Do you have time to look into this? What can I provide in information to help?



Hmm.  So after my rmlock commits, we have the following disassembly for

_rm_rlock() (with a few annotations added by me).  Note that the pcpu

pointer is stored in register x18 by convention.



   0xffff00000046e304 <+0>:     stp     x29, x30, [sp, #-16]!

   0xffff00000046e308 <+4>:     mov     x29, sp

   0xffff00000046e30c <+8>:     ldr     x8, [x18]

   0xffff00000046e310 <+12>:    ldr     x9, [x18]

   0xffff00000046e314 <+16>:    ldr     x10, [x18]

   0xffff00000046e318 <+20>:    cmp     x9, x10

   0xffff00000046e31c <+24>:    b.ne    0xffff00000046e3cc <_rm_rlock+200>  // b.any

   0xffff00000046e320 <+28>:    ldr     x9, [x18]

   0xffff00000046e324 <+32>:    ldrh    w9, [x9, #314]

   0xffff00000046e328 <+36>:    cbnz    w9, 0xffff00000046e3c0 <_rm_rlock+188>

   0xffff00000046e32c <+40>:    str     wzr, [x1, #32]

   0xffff00000046e330 <+44>:    stp     x0, x8, [x1, #16]

   0xffff00000046e334 <+48>:    ldrb    w9, [x0, #10]

   0xffff00000046e338 <+52>:    tbz     w9, #4, 0xffff00000046e358 <_rm_rlock+84>

   0xffff00000046e33c <+56>:    ldr     x9, [x18]

   0xffff00000046e340 <+60>:    ldr     w10, [x9, #888]

   0xffff00000046e344 <+64>:    add     w10, w10, #0x1

   0xffff00000046e348 <+68>:    str     w10, [x9, #888]

   0xffff00000046e34c <+72>:    ldr     x9, [x18]

   0xffff00000046e350 <+76>:    ldr     w9, [x9, #888]

   0xffff00000046e354 <+80>:    cbz     w9, 0xffff00000046e3f4 <_rm_rlock+240>

   0xffff00000046e358 <+84>:    ldr     w9, [x8, #1212]

   0xffff00000046e35c <+88>:    add     x10, x18, #0x90

   0xffff00000046e360 <+92>:    add     w9, w9, #0x1

   0xffff00000046e364 <+96>:    str     w9, [x8, #1212]  <------- critical_enter

   0xffff00000046e368 <+100>:   str     x10, [x1, #8]

   0xffff00000046e36c <+104>:   ldr     x9, [x18, #144]

   0xffff00000046e370 <+108>:   str     x9, [x1]

   0xffff00000046e374 <+112>:   str     x1, [x9, #8]

   0xffff00000046e378 <+116>:   str     x1, [x18, #144]

   0xffff00000046e37c <+120>:   ldr     x9, [x18]

   0xffff00000046e380 <+124>:   ldr     w10, [x9, #356]

   0xffff00000046e384 <+128>:   add     w10, w10, #0x1

   0xffff00000046e388 <+132>:   str     w10, [x9, #356]

   0xffff00000046e38c <+136>:   ldr     w9, [x8, #1212]

   0xffff00000046e390 <+140>:   sub     w9, w9, #0x1

   0xffff00000046e394 <+144>:   str     w9, [x8, #1212]  <------- critical_exit

   0xffff00000046e398 <+148>:   ldrb    w8, [x8, #304]

   0xffff00000046e39c <+152>:   ldr     w9, [x18, #60]   <------- loading &pc->pc_cpuid

   ...



A (the?) problem is that the compiler is treating "pc" as an alias

for x18, but the rmlock code assumes that the pcpu pointer is loaded

once, as it dereferences "pc" outside of the critical section.  On

arm64, if a context switch occurs between the store at _rm_rlock+144 and

the load at +152, and the thread is migrated to another CPU, then we'll

end up using the wrong CPU ID in the rm->rm_writecpus test.



I suspect the problem is unique to arm64 as its get_pcpu()

implementation is different from the others in that it doesn't use

volatile-qualified inline assembly.  This has been the case since

https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762

.



I haven't been able to reproduce any crashes running poudriere in an

arm64 AWS instance, though.  Could you please try the patch below and

confirm whether it fixes your panics?  I verified that the apparent

problem described above is gone with the patch.



diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c

index 0cdcfb8fec62..e51c25136ae0 100644

--- a/sys/kern/kern_rmlock.c

+++ b/sys/kern/kern_rmlock.c

@@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)

 {

    struct thread *td = curthread;

    struct pcpu *pc;

+   int cpuid;

 

    if (SCHEDULER_STOPPED())

        return (1);

@@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)

    atomic_interrupt_fence();

 

    pc = get_pcpu();

+   cpuid = pc->pc_cpuid;

    rm_tracker_add(pc, tracker);

    sched_pin();

 

@@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)

     * conditional jump.

     */

    if (__predict_true(0 == (td->td_owepreempt |

-       CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))

+       CPU_ISSET(cpuid, &rm->rm_writecpus))))

        return (1);

 

    /* We do not have a read token and need to acquire one. */








Hi,



This patch paniced again:

x0: ffffa00005a31500                                                                                             
  x1: ffffa00005a0e000                                                                                                            
  x2:                2                                                                                                            
  x3: ffffa00076c4e9a0                                                                                                            
  x4:                0                                                                                                            
  x5:    e672743c8f9e5                                                                                                            
  x6:    dc89f70500ab1
  x7:               14
  x8: ffffa00005a31518
  x9:                1
 x10: ffffa00005a0e000
 x11:                0
 x12:                0
 x13:                a
 x14: 1013e6b85a8ecbe4
 x15:     1dce740d11a5
 x16: ffff3ea86e2434bf
 x17: fffffffffffffff2
 x18: ffff0000fe661800 (g_ctx + fcf9fa54)
 x19: ffffa00076c4e9a0
 x20: ffff0000fec39000 (g_ctx + fd577254)
 x21:                2
 x22: ffff0000419b6090 (g_ctx + 402f42e4)
 x23: ffff000000c0b137 (lockstat_enabled + 0)
 x24:              100
 x25: ffff000000c0b000 (version + a0)
 x26: ffff000000c0b000 (version + a0)
 x27: ffff000000c0b000 (version + a0)
 x28:                0
 x29: ffff0000fe661800 (g_ctx + fcf9fa54)
  sp: ffff0000fe661800
  lr: ffff00000154ea50 (zio_dva_throttle + 154)
 elr: ffff00000154ea80 (zio_dva_throttle + 184)
spsr:         60000045
 far:     2b753286b0b8
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 1
time = 1646685857
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>  




Will try the patch of Andrew next. Compilation might take a while so maybe it wil be tomorrow.



Regards,

Ronald.

 
------=_Part_172_1254189170.1646686466401--

From nobody Mon Mar  7 21:17:56 2022
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 7031C19F81BD
	for ; Mon,  7 Mar 2022 21:18:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KCBBj70Kcz3vbR
	for ; Mon,  7 Mar 2022 21:18:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646687878; bh=mCcHKlyBPNimdscd7fOFHd6k1HiIvRhwt6DQ7NzFRkI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nx3fLBE0zfYQStJCgBtlJ9X+9Rx8i2Sl7RgQ6DSr96zNxKQDl57ddKZcSNoJBS1ILDJIWP6x7Olte2zMIxH1N62y1HwzCapJzgWMeXM3tpdU6qpNKJiihKTgopVGPCcUg9QQihrVc+YxNWYvZ+QKE0nipmkXaWSUZSaX3wgmhJ6u93sfcbNVmzWhd2RBQmUgetPFN457AlKawo45tjl7rWgUhnDTInAerZ1kWrwocbFzXFs/GQrofn4W9Jz9i/HQhc+Mmrs7iFJ9XnPXxdvntdVrxfigsfkEI89kJSgcu/w23E6rJXG/cDRXWo3LUaPI9tW1pyLHwpJRGTjLbIRX0Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646687878; bh=5yhuMu/hrdZgUGc/kWru4Er/LpCJ6hXxGsKMw5ybvs8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TSO0nJe5VS8xc8MOXgS8b8+AKjyYq/uheS963BpjdIrMbxv/re49c8ZAvrvXQaStq9FTcTEslQfftt4z5TGwsB+dFuNN5UIUPmvGbEE42DahdzKuYaqYAY7kE0mVvgGJ++RxpIJWmP8GgpMwxTqSRc1Ofn4M7/P5+fv3f3i6cIlme8evjjlrFwNLwwhltB1XJ0WLTGvG6hb5AP/qL+pwEJtNiT1ZpOzQ4XSs8n9pmIrlFlfHyW006YOa8nhRCdrh/ejfSbaKoVUv6WdSqJWdwyFmqj/Z9ZU1AsUWx5mamVcEz+5BszRFDFfnpy62H8gl4b+QtkMjPdHYLV24nFUETQ==
X-YMail-OSG: IGkmHDkVM1mDTahsWpU94Y_ch5zSIEfGGpzxdFxx.iAUNBmgEmRy2asCQK34.1v
 7AuRZ1RyJ4R2ZMvKhhRHIx6D41ZiSvT.cpsn5OYr3de99T5mr1hOXUhWntq2CPuoSIwQRCDVsCc2
 T1yngpqtdwuhlSZxi7wsgC.96b3WKHjRmFtVtlBJszyGhV2djRstrrLQHZCTi4qCWlYs4jZeSIWY
 QbbfdVzGJ0h1RfUUYsh5KjDaQRmHaf8sIdHTIgv_vnDJP_dtAPaGvs95LA.P2ZegoIEEhAqkNBOi
 noasm91mMM5fIfo_0N.GvWVw4dCbfNB3Rk2dCrhOfzRxoxw6Jr3h8CzD8q0QYRw0Ke8UHKJmxKNZ
 9upF1ZBi8jlmbRtoSMmJFxWJSStH3QExV_FF0poWxJ3Hx9vz2wi9J4XxYwwwiKJQJZzop_VGqb_3
 HwuH_1J0htSxMNnx0FoUOGXxOwCnsZD3N_RymV9dHTilElMJbmoFCs_130Old2qYMlSFTtc0e4kS
 u.r5fXfvkh6LDqaf.mf2gOPdsqvvRmpIU1IP_WgpUKTKb8fuYByYmus3Nrs5QUvbY9ccbuUfnv07
 VvtVrIhm4ICl7rTErdg_NhL76.gdRBSEgscgUcDnrh9Ia5Tf4.NZxcMy2zENDed2ANJ2kmxeApvd
 FonfnWFczQv7nKoaa5Mpbtrj7Iaj3.jI7ToNUczHXS2EZiFIS2seqBto9Rn.sVg5nk3.ITwviBQe
 GoQIA7uBB47RDX4NpcZdwF8u77_yBMNQ0Fw1G43YMpaZKk3eOhVErVxxiRIhPnN4k37Bi6Vf4u0u
 88RQMRfGdhcQS16FrQT.bnWYFtpM0QCzMVaBdLoXiIpZPp_CjnwPWk4QWv3X62jmtzsr1xeUGroQ
 EZU9tfQ8LzsIo6eDDpWJaNugKRwJI7Ke47aoq8vwEftwuNXXg32HKWZ9GPUp8CNNAXr1IYAXiomA
 Fg4tI2cS272Kd5HPQhg40zIvTWOowe85NScANDeQMcGJn20YYTDkWMOMSSGjC0i0y5DA3qA4PXEV
 fLVWsDXX6KZenOtNqORkDCw8RjcxpqhtvXp6zYvd2T2bo7bWRJVvxBs8YsCYsiLT_077.1MbkqGx
 Rjsu7m9ojFjRSwx0G66WSQHZEg0Hv2t1ScR04knkHSZ5G8O5Y4Kb7Kxj7E10yC75gPVBHwkNKwwv
 9WYUxQL0QRRZcMXwpm4YCV9v_kc.fhBMTNhxdH4Ttwuk.gWRUUypKqjiWDSThTPXyu.w9vrBnqOi
 zbnrUUcAJWY9XQiYaQ0QXO3B2p8DCBRXvOGIrZWlOy8.9PmQ60RJmzCYeGEAKK.uiVefZmnRQPgR
 dKYuzkIMCSMkPY2BDxqqYxTceTbMQuhqEV3bfrW3WV3mzSEdOmR0dz3f4XgWmFs3F.ptZ4XdpZuR
 nmBRRoACT3bwI5AwmQwfo9J36oiglpaB1Y_nKdy2Wo38B3m1MGBRqFi3ZZmmoBdYFtV_Eg_U83em
 _jq59HrwDLWwFWtjhb_cwt4zBR91hUI3R5CtOs3HKLgoFcLWEKrQPasdH3WJ_n41NpTTgF2t5_.A
 .8aL4oipiIEd1Z_qoNlgVvUrHDTe2SRGg6460TXoOpy6NK2gQWIa4ZoCxGGqAVozwXM6LvumEnhM
 uNPZ7d9T22ADTVa6RfR0xMYAm4L.arQlVK5hZ8ZEPJ_72nMvYolSQrvkswHj_MpCevTcJFVft4O7
 P8hCPgOCQn68kVAVZ9p1tfdD5LIh7kWG.qZ1KJ5cjPjKvx2F4CLfBWyOh59UqV.EByaLc5cXLTbw
 Cz4guN_ojV3rZubBTrcGL42cCZ0RJHpB6Z2IFLXBzrZ_hWQVamhlhVGNoposuVAEiccdpbgF9rAy
 FXqLwdYR2ZAOmKxMNgtcXWg5VuYVLdkhbopYJyB0fTT3krVTngeU.1k3auD0btnZQngOT_JmbvPM
 qT3s.wAlz18g312PdNoJIa.hwjPBscs_5ty4rYoSG8QVu.Wwqwpjveo99QS59e6hQsKobgdZ_F7c
 jdu3qQYwQ0GNTjMA_Ev1VDsMj8lwNhaMW7NlLb59DPAcF6K0vkw4WElSIvanrXhrUgHqaYcaa5Jp
 WVy03bGEk4ghjXEjAFBVErgW.7XKf9snjxBztAOFvcPTKxiDOsK4_W3.I4q7WxKxvoKzsylyUwX7
 9Bgxbn5N180TIyzaQtR8pvZ72RGNtKwH_9mLJGO_YLQA6ZUf2KGKxSVuiN4vj_UwlyedBkTgFUmd
 c_cr5dmOZXMJkljoqfmc4rrTcQW4DCTJ8FH0tuzADtx.MxyKYM7grugVJ32pugwp6Q4e_zFX1sf7
 hFC1.CJYmPvpWHIIQdsFqf.Hoc6oTJi2hPW4.4DbSGRDMalhy0pd6AVihKJp9zl61RZevqcbtVYm
 TKADKMqVIhwaAZmfWRMnz9w--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 21:17:58 +0000
Received: by kubenode521.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e1549565dc8fadf08c44473826d7d7bb;
          Mon, 07 Mar 2022 21:17:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <1302689164.173.1646686466515@mailrelay>
Date: Mon, 7 Mar 2022 13:17:56 -0800
Cc: Mark Johnston ,
 bob prohaska ,
 Free BSD ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
  <1302689164.173.1646686466515@mailrelay>
To: Ronald Klop 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KCBBj70Kcz3vbR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=nx3fLBE0;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9455
Lines: 246



On 2022-Mar-7, at 12:54, Ronald Klop  wrote:

> Van: Mark Johnston 
> Datum: maandag, 7 maart 2022 16:13
> Aan: Ronald Klop 
> CC: bob prohaska , Mark Millard =
, freebsd-arm@freebsd.org, freebsd-current =

> Onderwerp: Re: panic: data abort in critical section or under mutex =
(was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on =
14-CURRENT/aarch64 Feb 28))
>=20
> On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> > Dear Mark Johnston,
> >
> > I did some binary search in the kernels and came to the conclusion =
that =
https://cgit.freebsd.org/src/commit/?id=3D1517b8d5a7f58897200497811de1b188=
09c07d3e still works and =
https://cgit.freebsd.org/src/commit/?id=3D407c34e735b5d17e2be574808a09e6d7=
29b0a45a panics.
> >
> > I suspect your commit in =
https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4=
70bef23a.
> >
> > Last panic:
> >
> > panic: vm_fault failed: ffff00000046e708 error 1
> > cpuid =3D 1
> > time =3D 1646660058
> > KDB: stack backtrace:
> > db_trace_self() at db_trace_self
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> > vpanic() at vpanic+0x174
> > panic() at panic+0x44
> > data_abort() at data_abort+0x2e8
> > handle_el1h_sync() at handle_el1h_sync+0x10
> > --- exception, esr 0x96000004
> > _rm_rlock_debug() at _rm_rlock_debug+0x8c
> > osd_get() at osd_get+0x5c
> > zio_execute() at zio_execute+0xf8
> > taskqueue_run_locked() at taskqueue_run_locked+0x178
> > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> > fork_exit() at fork_exit+0x74
> > fork_trampoline() at fork_trampoline+0x14
> > KDB: enter: panic
> > [ thread pid 0 tid 100129 ]
> > Stopped at      kdb_enter+0x44: undefined       f902011f
> > db>
> >
> > A more recent kernel (912df91) still panics. See below.
> >
> > Do you have time to look into this? What can I provide in =
information to help?
>=20
> Hmm.  So after my rmlock commits, we have the following disassembly =
for
> _rm_rlock() (with a few annotations added by me).  Note that the pcpu
> pointer is stored in register x18 by convention.
>=20
>    0xffff00000046e304 <+0>:     stp     x29, x30, [sp, #-16]!
>    0xffff00000046e308 <+4>:     mov     x29, sp
>    0xffff00000046e30c <+8>:     ldr     x8, [x18]
>    0xffff00000046e310 <+12>:    ldr     x9, [x18]
>    0xffff00000046e314 <+16>:    ldr     x10, [x18]
>    0xffff00000046e318 <+20>:    cmp     x9, x10
>    0xffff00000046e31c <+24>:    b.ne    0xffff00000046e3cc =
<_rm_rlock+200>  // b.any
>    0xffff00000046e320 <+28>:    ldr     x9, [x18]
>    0xffff00000046e324 <+32>:    ldrh    w9, [x9, #314]
>    0xffff00000046e328 <+36>:    cbnz    w9, 0xffff00000046e3c0 =
<_rm_rlock+188>
>    0xffff00000046e32c <+40>:    str     wzr, [x1, #32]
>    0xffff00000046e330 <+44>:    stp     x0, x8, [x1, #16]
>    0xffff00000046e334 <+48>:    ldrb    w9, [x0, #10]
>    0xffff00000046e338 <+52>:    tbz     w9, #4, 0xffff00000046e358 =
<_rm_rlock+84>
>    0xffff00000046e33c <+56>:    ldr     x9, [x18]
>    0xffff00000046e340 <+60>:    ldr     w10, [x9, #888]
>    0xffff00000046e344 <+64>:    add     w10, w10, #0x1
>    0xffff00000046e348 <+68>:    str     w10, [x9, #888]
>    0xffff00000046e34c <+72>:    ldr     x9, [x18]
>    0xffff00000046e350 <+76>:    ldr     w9, [x9, #888]
>    0xffff00000046e354 <+80>:    cbz     w9, 0xffff00000046e3f4 =
<_rm_rlock+240>
>    0xffff00000046e358 <+84>:    ldr     w9, [x8, #1212]
>    0xffff00000046e35c <+88>:    add     x10, x18, #0x90
>    0xffff00000046e360 <+92>:    add     w9, w9, #0x1
>    0xffff00000046e364 <+96>:    str     w9, [x8, #1212]  <------- =
critical_enter
>    0xffff00000046e368 <+100>:   str     x10, [x1, #8]
>    0xffff00000046e36c <+104>:   ldr     x9, [x18, #144]
>    0xffff00000046e370 <+108>:   str     x9, [x1]
>    0xffff00000046e374 <+112>:   str     x1, [x9, #8]
>    0xffff00000046e378 <+116>:   str     x1, [x18, #144]
>    0xffff00000046e37c <+120>:   ldr     x9, [x18]
>    0xffff00000046e380 <+124>:   ldr     w10, [x9, #356]
>    0xffff00000046e384 <+128>:   add     w10, w10, #0x1
>    0xffff00000046e388 <+132>:   str     w10, [x9, #356]
>    0xffff00000046e38c <+136>:   ldr     w9, [x8, #1212]
>    0xffff00000046e390 <+140>:   sub     w9, w9, #0x1
>    0xffff00000046e394 <+144>:   str     w9, [x8, #1212]  <------- =
critical_exit
>    0xffff00000046e398 <+148>:   ldrb    w8, [x8, #304]
>    0xffff00000046e39c <+152>:   ldr     w9, [x18, #60]   <------- =
loading &pc->pc_cpuid
>    ...
>=20
> A (the?) problem is that the compiler is treating "pc" as an alias
> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> once, as it dereferences "pc" outside of the critical section.  On
> arm64, if a context switch occurs between the store at _rm_rlock+144 =
and
> the load at +152, and the thread is migrated to another CPU, then =
we'll
> end up using the wrong CPU ID in the rm->rm_writecpus test.
>=20
> I suspect the problem is unique to arm64 as its get_pcpu()
> implementation is different from the others in that it doesn't use
> volatile-qualified inline assembly.  This has been the case since
> =
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e=
99e73762
> .
>=20
> I haven't been able to reproduce any crashes running poudriere in an
> arm64 AWS instance, though.  Could you please try the patch below and
> confirm whether it fixes your panics?  I verified that the apparent
> problem described above is gone with the patch.
>=20
> diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c
> index 0cdcfb8fec62..e51c25136ae0 100644
> --- a/sys/kern/kern_rmlock.c
> +++ b/sys/kern/kern_rmlock.c
> @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker =
*tracker, int trylock)
>  {
>     struct thread *td =3D curthread;
>     struct pcpu *pc;
> +   int cpuid;
> =20
>     if (SCHEDULER_STOPPED())
>         return (1);
> @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker =
*tracker, int trylock)
>     atomic_interrupt_fence();
> =20
>     pc =3D get_pcpu();
> +   cpuid =3D pc->pc_cpuid;
>     rm_tracker_add(pc, tracker);
>     sched_pin();
> =20
> @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker =
*tracker, int trylock)
>      * conditional jump.
>      */
>     if (__predict_true(0 =3D=3D (td->td_owepreempt |
> -       CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))
> +       CPU_ISSET(cpuid, &rm->rm_writecpus))))
>         return (1);
> =20
>     /* We do not have a read token and need to acquire one. */
>=20
> Hi,
>=20
> This patch paniced again:
> x0: ffffa00005a31500                                                   =
                                         =20
>   x1: ffffa00005a0e000                                                 =
                                                         =20
>   x2:                2                                                 =
                                                         =20
>   x3: ffffa00076c4e9a0                                                 =
                                                         =20
>   x4:                0                                                 =
                                                         =20
>   x5:    e672743c8f9e5                                                 =
                                                         =20
>   x6:    dc89f70500ab1
>   x7:               14
>   x8: ffffa00005a31518
>   x9:                1
>  x10: ffffa00005a0e000
>  x11:                0
>  x12:                0
>  x13:                a
>  x14: 1013e6b85a8ecbe4
>  x15:     1dce740d11a5
>  x16: ffff3ea86e2434bf
>  x17: fffffffffffffff2
>  x18: ffff0000fe661800 (g_ctx + fcf9fa54)
>  x19: ffffa00076c4e9a0
>  x20: ffff0000fec39000 (g_ctx + fd577254)
>  x21:                2
>  x22: ffff0000419b6090 (g_ctx + 402f42e4)
>  x23: ffff000000c0b137 (lockstat_enabled + 0)
>  x24:              100
>  x25: ffff000000c0b000 (version + a0)
>  x26: ffff000000c0b000 (version + a0)
>  x27: ffff000000c0b000 (version + a0)
>  x28:                0
>  x29: ffff0000fe661800 (g_ctx + fcf9fa54)
>   sp: ffff0000fe661800
>   lr: ffff00000154ea50 (zio_dva_throttle + 154)
>  elr: ffff00000154ea80 (zio_dva_throttle + 184)
> spsr:         60000045
>  far:     2b753286b0b8
> panic: Unknown kernel exception 0 esr_el1 2000000
> cpuid =3D 1
> time =3D 1646685857
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> do_el1h_sync() at do_el1h_sync+0x184
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x2000000
> zio_dva_throttle() at zio_dva_throttle+0x184
> zio_execute() at zio_execute+0x58
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at      kdb_enter+0x44: undefined       f901c11f
> db> =20


Hmm. My somewhat older source code shows zio_dva_throttle
as having:

        mutex_enter(&spa->spa_allocs[allocator].spaa_lock);
        avl_add(&spa->spa_allocs[allocator].spaa_tree, zio);
        nio =3D zio_io_to_allocate(spa, allocator);
        mutex_exit(&spa->spa_allocs[allocator].spaa_lock);
        return (nio);

That might have implications if the issue is actually
analogous to _rm_rlock_debug crashes in some way.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar  7 21:42:54 2022
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 5277919FD8FA;
	Mon,  7 Mar 2022 21:42:59 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d])
	(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 4KCBlQ3Ssfz4T8b;
	Mon,  7 Mar 2022 21:42:58 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qt1-x82d.google.com with SMTP id bc10so14527994qtb.5;
        Mon, 07 Mar 2022 13:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=keQ4L7UbBstjJ4Z8l3tC/GCwog+37U4yNm5EHWpkJyI=;
        b=YELCZYJVzFSkd+idx/YfA9Oyt9zrPW4l4hTnpgFxkIw0g4cVnTc+oOZHzT6pnVLh+0
         P5j81luLKkOxJF+Chxwkps5FMEpukmrgyH1E7EFko6LndBrY4In2V41MAjp4Le87ukuy
         kIZa/BG7ERp8/gvjZcod7fElWLpR9TD8tUEQhqRztyN0eazVyGw41nEzJLhM9xdvF/vK
         jdBzwZbJSY2lDaOn7uoB0tFV1Njo3MpT4AWJPBpKdab/0TQ6R6068014AgBVtQ7jm0VR
         cVptbpymyg3SPPyqI4SVV46DTV2ueK2cF5u7anNPHOWCFRSStqT9mMKloEoBRz3L9Rzv
         qE+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=keQ4L7UbBstjJ4Z8l3tC/GCwog+37U4yNm5EHWpkJyI=;
        b=3oXnGZ0i137szOeQgHrQtLtVRt37WLf2oCIk1hydT7lMJP4Icn0oBynvMt407Axtk4
         2hBCpAUoO9MWQgoGZ5oP315BxDO6KsmRIci9G9FKvXnVDXMg1lMVwC2ZGSSSvgGs6D3f
         uUhi5yCSIZxVkXQdAILs+2kbBt5jRHIoJQ19tnGzScxzOoL2gpbxBsHfK9yxdl2o/mxk
         C6naaDvrWBTQYIKaUaza2bJIAFNASr0pkXvQk3ScmvBGId3seW2mE5MPutArVaxDy6C1
         fflz3iSvDwskDzpqHS667wQNiuFDzldaM/d70WYz4lLyzWcuefxf0zKOSCaF15YbM9yi
         1COQ==
X-Gm-Message-State: AOAM533IQcBZSn3/1bZ7P+QmRTnkBlCfKZzzDWzo/cfEogeUn4c1Yksp
	pSsQeSSYLtmTb5CNxj/gcrI=
X-Google-Smtp-Source: ABdhPJyCwNnxkvBhwxel+dTah4K5okKROtOb+iOTIiXy+V8phQN1otM3q5nebqF5dgc2s0RLsfuFFg==
X-Received: by 2002:ac8:5986:0:b0:2de:97e9:a517 with SMTP id e6-20020ac85986000000b002de97e9a517mr11100340qte.599.1646689377836;
        Mon, 07 Mar 2022 13:42:57 -0800 (PST)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id x21-20020a05622a001500b002e064e63fc2sm3271935qtw.70.2022.03.07.13.42.56
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 07 Mar 2022 13:42:56 -0800 (PST)
Date: Mon, 7 Mar 2022 16:42:54 -0500
From: Mark Johnston 
To: Ronald Klop 
Cc: bob prohaska , Mark Millard ,
	freebsd-arm@freebsd.org,
	freebsd-current 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Message-ID: 
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay>
 
 <1302689164.173.1646686466515@mailrelay>
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: <1302689164.173.1646686466515@mailrelay>
X-Rspamd-Queue-Id: 4KCBlQ3Ssfz4T8b
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=YELCZYJV;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.70 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4291
Lines: 105

On Mon, Mar 07, 2022 at 09:54:26PM +0100, Ronald Klop wrote:
>  
> Van: Mark Johnston 
> Datum: maandag, 7 maart 2022 16:13
> Aan: Ronald Klop 
> CC: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current 
> > I haven't been able to reproduce any crashes running poudriere in an
> > arm64 AWS instance, though.  Could you please try the patch below and
> > confirm whether it fixes your panics?  I verified that the apparent
> > problem described above is gone with the patch.
> > 
> > diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c
> > index 0cdcfb8fec62..e51c25136ae0 100644
> > --- a/sys/kern/kern_rmlock.c
> > +++ b/sys/kern/kern_rmlock.c
> > @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
> >  {
> >     struct thread *td = curthread;
> >     struct pcpu *pc;
> > +   int cpuid;
> >  
> >     if (SCHEDULER_STOPPED())
> >         return (1);
> > @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
> >     atomic_interrupt_fence();
> >  
> >     pc = get_pcpu();
> > +   cpuid = pc->pc_cpuid;
> >     rm_tracker_add(pc, tracker);
> >     sched_pin();
> >  
> > @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
> >      * conditional jump.
> >      */
> >     if (__predict_true(0 == (td->td_owepreempt |
> > -       CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))
> > +       CPU_ISSET(cpuid, &rm->rm_writecpus))))
> >         return (1);
> >  
> >     /* We do not have a read token and need to acquire one. */
> > 
> > 
> > 
> 
> Hi,
> 
> This patch paniced again:
> x0: ffffa00005a31500                                                                                             
>   x1: ffffa00005a0e000                                                                                                            
>   x2:                2                                                                                                            
>   x3: ffffa00076c4e9a0                                                                                                            
>   x4:                0                                                                                                            
>   x5:    e672743c8f9e5                                                                                                            
>   x6:    dc89f70500ab1
>   x7:               14
>   x8: ffffa00005a31518
>   x9:                1
>  x10: ffffa00005a0e000
>  x11:                0
>  x12:                0
>  x13:                a
>  x14: 1013e6b85a8ecbe4
>  x15:     1dce740d11a5
>  x16: ffff3ea86e2434bf
>  x17: fffffffffffffff2
>  x18: ffff0000fe661800 (g_ctx + fcf9fa54)
>  x19: ffffa00076c4e9a0
>  x20: ffff0000fec39000 (g_ctx + fd577254)
>  x21:                2
>  x22: ffff0000419b6090 (g_ctx + 402f42e4)
>  x23: ffff000000c0b137 (lockstat_enabled + 0)
>  x24:              100
>  x25: ffff000000c0b000 (version + a0)
>  x26: ffff000000c0b000 (version + a0)
>  x27: ffff000000c0b000 (version + a0)
>  x28:                0
>  x29: ffff0000fe661800 (g_ctx + fcf9fa54)
>   sp: ffff0000fe661800
>   lr: ffff00000154ea50 (zio_dva_throttle + 154)
>  elr: ffff00000154ea80 (zio_dva_throttle + 184)
> spsr:         60000045
>  far:     2b753286b0b8
> panic: Unknown kernel exception 0 esr_el1 2000000
> cpuid = 1
> time = 1646685857
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> do_el1h_sync() at do_el1h_sync+0x184
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x2000000
> zio_dva_throttle() at zio_dva_throttle+0x184
> zio_execute() at zio_execute+0x58
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at      kdb_enter+0x44: undefined       f901c11f
> db>  

ZFS doesn't make use of rm locks as far as I can see, so this is a
little weird.  I reverted the original rmlock commit in main, so it may
be worth verifying that the problem really is gone before digging
deeper.  In other words, I'm a bit suspicious that this is a different
bug.

From nobody Tue Mar  8 10:06:48 2022
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 F399C19F0AB5
	for ; Tue,  8 Mar 2022 10:06:49 +0000 (UTC)
	(envelope-from lee.matthews.external@stormshield.eu)
Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KCWFj2GDgz4pyb
	for ; Tue,  8 Mar 2022 10:06:49 +0000 (UTC)
	(envelope-from lee.matthews.external@stormshield.eu)
Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1])
	by work.stormshield.eu (Postfix) with ESMTPS id 5EBF63760278
	for ; Tue,  8 Mar 2022 11:06:48 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by work.stormshield.eu (Postfix) with ESMTP id 489DC37607B8
	for ; Tue,  8 Mar 2022 11:06:48 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 work.stormshield.eu 489DC37607B8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu;
	s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE; t=1646734008;
	bh=2t8tBKH6ahQYrLqqN7K5x9bK/vZZ9VCZDqEJeq4JtgA=;
	h=Date:From:To:Message-ID:MIME-Version;
	b=e5Bn+RwX5KU3Lug4l0G9ygwKlOfW49LS9oWK1MYbA+CunQAlULJj3RmXk08GLLBNS
	 U6/XJU/ghEWCsHA6FEOGcyDsexbPI7zoSXTrsv4awPR2IqFcitqqNKM2K/IFtvy8u1
	 1IDf4v3U1G+9yJhV5Tlp18+I/i0cTgMqwrYRcWPo=
Received: from work.stormshield.eu ([127.0.0.1])
	by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id NYC0ejoM3CTp for ;
	Tue,  8 Mar 2022 11:06:48 +0100 (CET)
Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1])
	by work.stormshield.eu (Postfix) with ESMTP id 388B63760278
	for ; Tue,  8 Mar 2022 11:06:48 +0100 (CET)
Date: Tue, 8 Mar 2022 11:06:48 +0100 (CET)
From: Lee MATTHEWS 
To: freebsd-arm@FreeBSD.org
Message-ID: <645758921.24525489.1646734008202.JavaMail.zimbra@stormshield.eu>
Subject: 'Translation Fault (L1) on read' error
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
Thread-Index: TMEvRxsfBRXhPbuxmbwWl4yV75U16w==
Thread-Topic: 'Translation Fault (L1) on read' error
X-Rspamd-Queue-Id: 4KCWFj2GDgz4pyb
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=stormshield.eu header.s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE header.b=e5Bn+RwX;
	dmarc=pass (policy=quarantine) header.from=stormshield.eu;
	spf=pass (mx1.freebsd.org: domain of lee.matthews.external@stormshield.eu designates 91.212.116.1 as permitted sender) smtp.mailfrom=lee.matthews.external@stormshield.eu
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[stormshield.eu:s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE];
	 RCVD_COUNT_FIVE(0.00)[5];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:91.212.116.1:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[stormshield.eu:+];
	 DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6167
Lines: 162

Hello,

We are currently having problems during wifi testing on our embedded device=
s that run FreeBSD 11.3 on armv6. We know that this version is no longer su=
pported and we are currently working on updating to FreeBSD 13.0.

We get random "Translation Fault (L1) on read" errors followed by a core du=
mp. Continuous repeated testing can take several days before the problem ap=
pears.

What could be causing this error? I've been looking online and I wonder if =
it could be an icache issue ?=20

https://lists.freebsd.org/pipermail/freebsd-hackers/2016-December/050255.ht=
ml

I have attached below a couple of kernel panic messages as well as the code=
 at the origin of the panic.

Thanks in advance.

Best regards,
Lee Matthews

----

Unread portion of the kernel message buffer:
[7022] Fatal kernel mode data abort: 'Translation Fault (L1)' on read
[7022] trapframe: 0xb559e550
[7022] FSR=3D00000005, FAR=3D00000024, spsr=3D00000013
[7022] r0 =3D00000000, r1 =3D86bc7e00, r2 =3D86b26000, r3 =3D00000000
[7022] r4 =3D8702f0c8, r5 =3D000005b6, r6 =3D85055000, r7 =3D00000040
[7022] r8 =3D8702f000, r9 =3D86bc7e00, r10=3D853cb9fc, r11=3Db559e5e8
[7022] r12=3D853cb9fc, ssp=3Db559e5e0, slr=3D80092a34, pc =3D8036b2b0
[7022]=20
[7022] timeout stopping cpus
[7022] panic: Fatal abort
[7022] cpuid =3D 0
[7022] __HardenedBSD_version =3D 1100056 __FreeBSD_version =3D 1103500
[7022] version =3D NS-BSD 4.3.0.snap20210902--HBSD #0 : Tue Jan 18 01:21:57=
 CET 2022
[7022]     leem@BuildHBSD113-1-armv6.labo.int:/home/leem/build/kernel/work-=
OPTIM/sys/arm/compile/NETASQ.S.SMP.HW.RELEASE
[7022] Uptime: 1h57m2s
[7022] Physical memory: 2038 MB
[7022] Dumping 250 MB: 247 243 239 235 231 227 223

savectx () at ../../../arm/arm/swtch.S:103
103=09../../../arm/arm/swtch.S: No such file or directory.
(kgdb) bt
#0  savectx () at ../../../arm/arm/swtch.S:103
#1  0x8024e5c0 in dumpsys (di=3D) at ./machine/dump.h:67
#2  doadump (textdump=3D) at ../../../kern/kern_shutdown.c:3=
33
#3  0x8024e3dc in kern_reboot (howto=3D260) at ../../../kern/kern_shutdown.=
c:390
#4  0x8024e73c in vpanic (fmt=3D0x84e20400 "0\004=EF=BF=BD\204", ap=3D...) =
at ../../../kern/kern_shutdown.c:785
#5  0x8024e5fc in panic (fmt=3D) at ../../../kern/kern_shutdow=
n.c:714
#6  0x8052d2cc in abort_fatal (tf=3D0x0, idx=3D, fsr=3D, far=3D, prefetch=3D0, td=3D0x84f5a880, ksig=3D0x=
b559e4d0) at ../../../arm/arm/trap-v6.c:625
#7  0x8052d0cc in abort_handler (tf=3D, prefetch=3D) at ../../../arm/arm/trap-v6.c:424
#8  
#9  ieee80211_crypto_encap (ni=3D, m=3D0x86bc7e00) at ../../=
../net80211/ieee80211_crypto.c:573



/*
 * Add privacy headers appropriate for the specified key.
 */
struct ieee80211_key *
ieee80211_crypto_encap(struct ieee80211_node *ni, struct mbuf *m)
{
=09struct ieee80211_key *k;
=09const struct ieee80211_cipher *cip;

=09if ((k =3D ieee80211_crypto_get_txkey(ni, m)) !=3D NULL) {
=09=09cip =3D k->wk_cipher;
=09=09return (cip->ic_encap(k, m) ? k : NULL);    -------- ligne 573
=09}

=09return NULL;
}

----

[1095] Fatal kernel mode data abort: 'Translation Fault (L1)' on read
[1095] trapframe: 0xb559e9c0
[1095] FSR=3D00000005, FAR=3D0000ffff, spsr=3D00000013
[1095] r0 =3D870a955a, r1 =3D410c2018, r2 =3D00000011, r3 =3D0000ffff
[1095] r4 =3D86b7c000, r5 =3D00000000, r6 =3D00000020, r7 =3D00000400
[1095] r8 =3D8705a000, r9 =3D85055000, r10=3D86bd7000, r11=3Db559ea80
[1095] r12=3D870a9558, ssp=3Db559ea50, slr=3D80384ea4, pc =3D80384f08
[1095]=20
[1095] timeout stopping cpus
[1095] panic: Fatal abort
[1095] cpuid =3D 0
[1095] __HardenedBSD_version =3D 1100056 __FreeBSD_version =3D 1103500
[1095] version =3D NS-BSD 4.3.3--HBSD #0  711c600c(pretag/4.3.3): Thu Dec 2=
3 18:46:12 CET 2021
[1095]     build@buildmajHBSD113-armv6.labo.int:/home/build/fw-PRETAG_4.3.3=
/firmware/tmp/armv6/kernel/work-OPTIM/sys/arm/compile/NETASQ.S.SMP.HW.RELEA=
SE
[1095] Uptime: 18m15s
[1095] Physical memory: 2038 MB
[1095] Dumping 249 MB: 246 242 238 234 230 226 222

savectx () at ../../../arm/arm/swtch.S:103
103=09../../../arm/arm/swtch.S: No such file or directory.
(kgdb) bt
#0  savectx () at ../../../arm/arm/swtch.S:103
#1  0x8024ee28 in dumpsys (di=3D) at ./machine/dump.h:67
#2  doadump (textdump=3D) at ../../../kern/kern_shutdown.c:3=
33
#3  0x8024ec44 in kern_reboot (howto=3D260) at ../../../kern/kern_shutdown.=
c:390
#4  0x8024efa4 in vpanic (fmt=3D0x84e20400 "0\004=EF=BF=BD\204", ap=3D...) =
at ../../../kern/kern_shutdown.c:785
#5  0x8024ee64 in panic (fmt=3D) at ../../../kern/kern_shutdow=
n.c:714
#6  0x8052d9c0 in abort_fatal (tf=3D0x0, idx=3D, fsr=3D, far=3D, prefetch=3D0, td=3D0x84f5a880, ksig=3D0x=
b559e940) at ../../../arm/arm/trap-v6.c:625
#7  0x8052d7c0 in abort_handler (tf=3D, prefetch=3D) at ../../../arm/arm/trap-v6.c:424
#8  
#9  0x80384f08 in ieee80211_getcapinfo (vap=3D, chan=3D0xfff=
f) at ../../../net80211/ieee80211_output.c:2195

/*
 * Calculate capability information for mgt frames.
 */
uint16_t
ieee80211_getcapinfo(struct ieee80211vap *vap, struct ieee80211_channel *ch=
an)
{
=09struct ieee80211com *ic =3D vap->iv_ic;
=09uint16_t capinfo;

=09KASSERT(vap->iv_opmode !=3D IEEE80211_M_STA, ("station mode"));

=09if (vap->iv_opmode =3D=3D IEEE80211_M_HOSTAP)
=09=09capinfo =3D IEEE80211_CAPINFO_ESS;
=09else if (vap->iv_opmode =3D=3D IEEE80211_M_IBSS)
=09=09capinfo =3D IEEE80211_CAPINFO_IBSS;
=09else
=09=09capinfo =3D 0;
=09if (vap->iv_flags & IEEE80211_F_PRIVACY)
=09=09capinfo |=3D IEEE80211_CAPINFO_PRIVACY;
=09if ((ic->ic_flags & IEEE80211_F_SHPREAMBLE) &&
=09    IEEE80211_IS_CHAN_2GHZ(chan))
=09=09capinfo |=3D IEEE80211_CAPINFO_SHORT_PREAMBLE;
=09if (ic->ic_flags & IEEE80211_F_SHSLOT)  -------------- line 2195
=09=09capinfo |=3D IEEE80211_CAPINFO_SHORT_SLOTTIME;
=09if (IEEE80211_IS_CHAN_5GHZ(chan) && (vap->iv_flags & IEEE80211_F_DOTH))
=09=09capinfo |=3D IEEE80211_CAPINFO_SPECTRUM_MGMT;
=09return capinfo;
}

From nobody Tue Mar  8 11:13:59 2022
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 BE5D719FF73C
	for ; Tue,  8 Mar 2022 11:13:59 +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 4KCXlC2k43z3FZh
	for ; Tue,  8 Mar 2022 11:13:59 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 3DCC71B8B0
	for ; Tue,  8 Mar 2022 11:13:59 +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 228BDxeP005409
	for ; Tue, 8 Mar 2022 11:13:59 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 228BDxiq005408
	for freebsd-arm@FreeBSD.org; Tue, 8 Mar 2022 11:13:59 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 262417] armv7 build fails for ARMADAXP
Date: Tue, 08 Mar 2022 11:13:59 +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: me@igalic.co
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1646738039;
	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=zi0yR+xZNkSfIRY0GKpvWtGwDE5AH8ruJ2i4gxXcVHw=;
	b=iwenp00FDYRfE8kabyz+TfHQYjC0iLZA10HD2ibhf/hcYd9duYO3j/tg09w3mZ6kjQOsMQ
	oY+4M39FGTRkrE+eEdL/HMr6URYMpLZuCNMfaQlVOUQ5Ly/j94q3CEs5iE3gmtZTAEbj1v
	Lsm2I+XPBu5f5OzmiQbtyewYPZTDFUW9vzMGkBcxQcOdcuZA3SOM+bX1rpMOgIxlMWRxCl
	Qd1+2GevNIk/G9AS9szt6K6r43Uary3vAehHgPpiRgK6o19d2JCm5mWu8P3F88TMdyTrIN
	TuseaivdCSUnglXSDCrKKXBe11tHkb/3YFm1T3ua9tmqMtGWGrU3TZi/atsKYA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646738039; a=rsa-sha256; cv=none;
	b=BMIUMpHHcIn8H3DkpEU4vEGf306JeRpO/gIotCw2hniaJSMQfkRes9zr7CKnePBm6e7R1i
	eW2sw2jBzQ1rlwCovvArgHs/4tPp3nAUDf0+AXnX3UBO7c2A5yBoqnANA+dqfln/I1qRGO
	6BB3mW4yDAaB2/ls17hueKv6MeDMXo3FJZlJIClO18QLGofY8pjGY9jXo3KigU9oT8arHU
	TN3x4mRNpsPKlmqxerSpIziPxZIUWTTBwoVDfOh8UaCJ8fnH3dE9HP+u6NA1zVMVOe0nKk
	Gg1CICODSgBK/3619CsN2c/T7ukESe/q11vIfMR56JEAcXzxC+vS0uW6NeZ4uw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3096
Lines: 74

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262417

            Bug ID: 262417
           Summary: armv7 build fails for ARMADAXP
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: me@igalic.co

# Meta data file
/usr/obj/poudriere/jails/14-current-armv7/usr/src/arm.armv7/sys/ARMADAXP/of=
w_cpu.o.meta
CMD cc -target armv7-gnueabihf-freebsd14.0
--sysroot=3D/usr/obj/poudriere/jails/14-current-armv7/usr/src/arm.armv7/tmp
-B/usr/obj/poudriere/jails/14-current-armv7/usr/src/arm.armv7/tmp/usr/bin -c
-O2 -pipe  -fno-strict-aliasing  -g -nostdinc  -I.
-I/poudriere/jails/14-current-armv7/usr/src/sys
-I/poudriere/jails/14-current-armv7/usr/src/sys/contrib/ck/include
-I/poudriere/jails/14-current-armv7/usr/src/sys/contrib/libfdt
-I/poudriere/jails/14-current-armv7/usr/src/sys/contrib/device-tree/include
-I$/dts/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-common   -march=3Darmv7a -DLINUX_DTS_VERSION=3D\""5.13"\" -funwind-tab=
les
-fdebug-prefix-map=3D./machine=3D/poudriere/jails/14-current-armv7/usr/src/=
sys/arm/include
-ffreestanding -fwrapv -fstack-protector -Wall -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=3Dtautological-co=
mpare
-Wno-error=3Dempty-body -Wno-error=3Dparentheses-equality
-Wno-error=3Dunused-function -Wno-error=3Dpointer-sign
-Wno-error=3Dshift-negative-value -Wno-address-of-packed-member
-Wno-error=3Dunused-but-set-variable -Wno-format-zero-length   -mfpu=3Dnone=
=20
-std=3Diso9899:1999 -Werror
/poudriere/jails/14-current-armv7/usr/src/sys/dev/ofw/ofw_cpu.c
CMD ctfconvert -L VERSION -g ofw_cpu.o
CWD /usr/obj/poudriere/jails/14-current-armv7/usr/src/arm.armv7/sys/ARMADAXP
TARGET ofw_cpu.o
OODATE /poudriere/jails/14-current-armv7/usr/src/sys/dev/ofw/ofw_cpu.c
offset.inc assym.inc vnode_if.h fdt_static_dtb.h miidevs.h usbdevs.h
usbdevs_data.h rpctlscd.h rpctlssd.h card_if.h power_if.h fb_if.h iicbus_if=
.h
ofw_iicbus_if.h mdio_if.h miibus_if.h mmcbr_if.h mmcbus_if.h mvs_if.h
ofw_bus_if.h ofw_if.h pci_if.h pci_iov_if.h pcib_if.h uart_if.h usb_if.h
g_part_if.h isa_if.h bus_if.h clock_if.h cpufreq_if.h device_if.h linker_if=
.h
serdev_if.h cryptodev_if.h platform_if.h msi_if.h pic_if.h opt_global.h mac=
hine
-- command output --
In file included from
/poudriere/jails/14-current-armv7/usr/src/sys/dev/ofw/ofw_cpu.c:49:
/poudriere/jails/14-current-armv7/usr/src/sys/dev/extres/clk/clk.h:37:10: f=
atal
error: 'clknode_if.h' file not found
#include "clknode_if.h"
         ^~~~~~~~~~~~~~
1 error generated.

*** Error code 1

it appears that other armv7 KERNCONFs also need this commit:
f34560385c730c8b1db4f46a9c711a60511864bf

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Mar  8 12:26:05 2022
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 27C6F1A0E302;
	Tue,  8 Mar 2022 12:26:14 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KCZLX1LlVz3R6t;
	Tue,  8 Mar 2022 12:26:11 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id B05B04E6E9;
	Tue,  8 Mar 2022 12:26:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz;
	s=mail; t=1646742370;
	bh=QlmT9QpM8WqrTLMpNA3WqsHqQTGYbmLrfGhj6giEddI=;
	h=From:Subject:Date:In-Reply-To:Cc:To:References;
	b=S69YN5Qr/GurddKIFUXN3AyhqA08qFEDoAhibVnsTlyrvTikcm2FL0lS8xwSRJ05W
	 Kq9rpVAhkNJi4jybZIA0z18zP9T2N3Bg4Jfhr1v8YcUdT9z1WzVNcBt2JvsNdYB/1v
	 OD4iMtdscr4E4UfMB7YuoqWQYG9/9DcuLOS4zwW4zorUQS8ZkhcMZfyPbvlUY/SWGJ
	 JDzhvkIHR5JDB0DIujgrwicZdW5rxolwORGq3j8TZ0LFrIXECkxNGLHEUfL04GIOfA
	 8wf/fvnhEZeHThURC9AptRmzQFup9LWoNEJYuJ3l5IrkOdkWirS3s+SBpxkTjUojwW
	 kyqn9Xu7qZbdFZBHTMHTFi273qedG3eYneN4NHQeyRRXB3i/XLplTjZaooVB61/3vt
	 /RyPofZt7GWUGk30YVd2XjVJ55F+WcTZc5fMg9de8v5M7ZnTZKhBd+gA/H66eR95qk
	 xCpD8GOm7yfd3Mz734oRIEvzSNPx+abAJ4rgvsYGGBkWWvXvv3Cr/FjKw71pV0x+cz
	 514JNI+8TL9rwn/F/kbCpU4qU18HWvt53mkYgrCCGKT6Ar3sIdG9BSN7Sk6AsFQmV0
	 z57I3Khh/mmQcl8fqHfGdrDbK7rS6JZZFBHqJlbz6kLzRjX9kKq7BtmG8qLNLt0nkq
	 tq74XaluCbqW7stcxtWtDnHc=
From: Andrew Turner 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B"
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 15.0 \(3693.60.0.1.1\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Date: Tue, 8 Mar 2022 12:26:05 +0000
In-Reply-To: 
Cc: Mark Millard ,
 FreeBSD-STABLE Mailing List ,
 Ronald Klop ,
 bob prohaska ,
 Free BSD ,
 freebsd-current 
To: Mark Johnston 
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
  <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
  
 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KCZLX1LlVz3R6t
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=fubar.geek.nz header.s=mail header.b=S69YN5Qr;
	dmarc=pass (policy=none) header.from=fubar.geek.nz;
	spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz
X-Spamd-Result: default: False [-3.40 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[fubar.geek.nz:+];
	 DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current,freebsd-stable];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,klop.ws,www.zefox.net];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 18620
Lines: 329


--Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 7 Mar 2022, at 19:04, Mark Johnston  wrote:
>=20
> On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote:
>>=20
>>=20
>> On 2022-Mar-7, at 08:45, Mark Johnston  wrote:
>>=20
>>> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
>>>>=20
>>>>> On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
>>>>> ...
>>>>> A (the?) problem is that the compiler is treating "pc" as an alias
>>>>> for x18, but the rmlock code assumes that the pcpu pointer is =
loaded
>>>>> once, as it dereferences "pc" outside of the critical section.  On
>>>>> arm64, if a context switch occurs between the store at =
_rm_rlock+144 and
>>>>> the load at +152, and the thread is migrated to another CPU, then =
we'll
>>>>> end up using the wrong CPU ID in the rm->rm_writecpus test.
>>>>>=20
>>>>> I suspect the problem is unique to arm64 as its get_pcpu()
>>>>> implementation is different from the others in that it doesn't use
>>>>> volatile-qualified inline assembly.  This has been the case since
>>>>> =
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e=
99e73762 =

>>>>> .
>>>>>=20
>>>>> I haven't been able to reproduce any crashes running poudriere in =
an
>>>>> arm64 AWS instance, though.  Could you please try the patch below =
and
>>>>> confirm whether it fixes your panics?  I verified that the =
apparent
>>>>> problem described above is gone with the patch.
>>>>=20
>>>> Alternatively (or additionally) we could do something like the =
following. There are only a few MI users of get_pcpu with the main place =
being in rm locks.
>>>>=20
>>>> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
>>>> index 09f6361c651c..59b890e5c2ea 100644
>>>> --- a/sys/arm64/include/pcpu.h
>>>> +++ b/sys/arm64/include/pcpu.h
>>>> @@ -58,7 +58,14 @@ struct pcpu;
>>>>=20
>>>> register struct pcpu *pcpup __asm ("x18");
>>>>=20
>>>> -#define        get_pcpu()      pcpup
>>>> +static inline struct pcpu *
>>>> +get_pcpu(void)
>>>> +{
>>>> +       struct pcpu *pcpu;
>>>> +
>>>> +       __asm __volatile("mov   %0, x18" : "=3D&r"(pcpu));
>>>> +       return (pcpu);
>>>> +}
>>>>=20
>>>> static inline struct thread *
>>>> get_curthread(void)
>>>=20
>>> Indeed, I think this is probably the best solution.

I=E2=80=99ve pushed the above to git in ed3066342660 & will MFC in a few =
days.

>=20
> Thinking a bit more, even with that patch, code like this may not =
behave
> the same on arm64 as on other platforms:
>=20
> critical_enter();
> ptr =3D &PCPU_GET(foo);
> critical_exit();
> bar =3D *ptr;
>=20
> since as far as I can see the compiler may translate it to
>=20
> critical_enter();
> critical_exit();
> bar =3D PCPU_GET(foo);

If we think this will be a problem we could change the PCPU_PTR macro to =
use get_pcpu again, however I only see two places it=E2=80=99s used in =
the MI code in subr_witness.c and kern_clock.c. Neither of these appear =
to be problematic from a quick look as there are no critical sections, =
although I=E2=80=99m not familiar enough with the code to know for =
certain.

Andrew=

--Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 7 Mar 2022, at 19:04, Mark Johnston <markj@freebsd.org> =
wrote:

On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard =
wrote:


On 2022-Mar-7, at 08:45, Mark Johnston <markj@FreeBSD.org> =
wrote:

On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner =
wrote:

On 7 Mar 2022, at 15:13, =
Mark Johnston <markj@freebsd.org> wrote:
...
A (the?) problem is that the compiler is treating "pc" as an =
alias
for x18, but the rmlock code assumes that the pcpu =
pointer is loaded
once, as it dereferences "pc" outside of =
the critical section.  On
arm64, if a context switch =
occurs between the store at _rm_rlock+144 and
the load at =
+152, and the thread is migrated to another CPU, then we'll
end up using the wrong CPU ID in the rm->rm_writecpus =
test.

I suspect the problem is unique to =
arm64 as its get_pcpu()
implementation is different from =
the others in that it doesn't use
volatile-qualified =
inline assembly.  This has been the case since
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd=
f85ad04fc8e99e73762 <https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd=
f85ad04fc8e99e73762>
.

I=
 haven't been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though.  Could you please try the =
patch below and
confirm whether it fixes your panics? =
 I verified that the apparent
problem described above =
is gone with the patch.

Alternatively (or additionally) we could do something like =
the following. There are only a few MI users of get_pcpu with the main =
place being in rm locks.

diff --git =
a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index =
09f6361c651c..59b890e5c2ea 100644
--- =
a/sys/arm64/include/pcpu.h
+++ =
b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct =
pcpu;

register struct pcpu *pcpup __asm =
("x18");

-#define =
       get_pcpu() =
     pcpup
+static inline struct =
pcpu *
+get_pcpu(void)
+{
+ =
      struct pcpu *pcpu;
+
+       __asm __volatile("mov =
  %0, x18" : "=3D&r"(pcpu));
+ =
      return (pcpu);
+}

static inline struct thread *
get_curthread(void)

Indeed, I think this is probably the best solution.

I=E2=80=99ve pushed the above to git =
in ed3066342660 & will MFC in a few days.


Thinking a bit more, even with =
that patch, code like this may not behave
the same on arm64 as on other platforms:

critical_enter();
ptr =3D =
&PCPU_GET(foo);
critical_exit();
bar =3D *ptr;

since as far as I can see the compiler may translate it =
to

critical_enter();
critical_exit();
bar =3D PCPU_GET(foo);

If we think this will be a problem we could change =
the PCPU_PTR macro to use get_pcpu again, however I only see two =
places it=E2=80=99s used in the MI code in subr_witness.c =
and kern_clock.c. Neither of these appear to be problematic from a =
quick look as there are no critical sections, although I=E2=80=99m not =
familiar enough with the code to know for certain.

Andrew
=

--Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B--

From nobody Tue Mar  8 15:42:04 2022
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 CBF201A1436A;
	Tue,  8 Mar 2022 15:42:00 +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 4KCfhR2ymrz4c3D;
	Tue,  8 Mar 2022 15:41:59 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 228Fg6vo037302
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 8 Mar 2022 07:42:06 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 228Fg5Cc037301;
	Tue, 8 Mar 2022 07:42:05 -0800 (PST)
	(envelope-from fbsd)
Date: Tue, 8 Mar 2022 07:42:04 -0800
From: bob prohaska 
To: Mark Johnston 
Cc: Andrew Turner , Ronald Klop ,
        Mark Millard , freebsd-arm@freebsd.org,
        freebsd-current ,
        bob prohaska 
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
Message-ID: <20220308154204.GA37265@www.zefox.net>
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay>
 
 <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
 
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: 4KCfhR2ymrz4c3D
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.92 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.94)[-0.944];
	 NEURAL_HAM_LONG(-0.88)[-0.878];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_SEVEN(0.00)[7];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[fubar.geek.nz,klop.ws,yahoo.com,freebsd.org,www.zefox.net];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3307
Lines: 85

On Mon, Mar 07, 2022 at 11:45:02AM -0500, Mark Johnston wrote:
> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
> > 
> > > On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
> > > ...
> > > A (the?) problem is that the compiler is treating "pc" as an alias
> > > for x18, but the rmlock code assumes that the pcpu pointer is loaded
> > > once, as it dereferences "pc" outside of the critical section.  On
> > > arm64, if a context switch occurs between the store at _rm_rlock+144 and
> > > the load at +152, and the thread is migrated to another CPU, then we'll
> > > end up using the wrong CPU ID in the rm->rm_writecpus test.
> > > 
> > > I suspect the problem is unique to arm64 as its get_pcpu()
> > > implementation is different from the others in that it doesn't use
> > > volatile-qualified inline assembly.  This has been the case since
> > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 
> > > .
> > > 
> > > I haven't been able to reproduce any crashes running poudriere in an
> > > arm64 AWS instance, though.  Could you please try the patch below and
> > > confirm whether it fixes your panics?  I verified that the apparent
> > > problem described above is gone with the patch.
> > 
> > Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks.
> > 
> > diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
> > index 09f6361c651c..59b890e5c2ea 100644
> > --- a/sys/arm64/include/pcpu.h
> > +++ b/sys/arm64/include/pcpu.h
> > @@ -58,7 +58,14 @@ struct pcpu;
> > 
> >  register struct pcpu *pcpup __asm ("x18");
> > 
> > -#define        get_pcpu()      pcpup
> > +static inline struct pcpu *
> > +get_pcpu(void)
> > +{
> > +       struct pcpu *pcpu;
> > +
> > +       __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
> > +       return (pcpu);
> > +}
> > 
> >  static inline struct thread *
> >  get_curthread(void)
> 
> Indeed, I think this is probably the best solution.

Just for fun I tried the patch on a Pi3 running -current, updated a day or two
prior. The patch applied, compiled and seemed to run acceptably, but when I 
left a -j2 -DWITH_META_MODE buildworld running it crashed overnight, reporting


login: panic: rm_rlock: recursed on non-recursive rmlock sysctl lock @ /usr/src/sys/kern/kern_sysctl.c:193

cpuid = 0
time = 1646720264
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
_rm_rlock_debug() at _rm_rlock_debug+0x214
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
sysctl_root() at sysctl_root+0x1ac
userland_sysctl() at userland_sysctl+0x140
sys___sysctl() at sys___sysctl+0x68
do_el0_sync() at do_el0_sync+0x520
handle_el0_sync() at handle_el0_sync+0x40
--- exception, esr 0x56000000
KDB: enter: panic
[ thread pid 869 tid 100091 ]
Stopped at      kdb_enter+0x44: undefined       f902011f


I tried typing bt at the debugger prompt but got no more output. 

I've put the buildworld log file at
http://www.zefox.net/~fbsd/rpi3/crashes/20220307/

Hope this is of some use....

bob prohaska



From nobody Wed Mar  9 17:55:44 2022
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 C6C8D19F1763
	for ; Wed,  9 Mar 2022 17:56:03 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c])
	(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 4KDKcg0PV4z4nTB
	for ; Wed,  9 Mar 2022 17:56:03 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52c.google.com with SMTP id g3so3939120edu.1
        for ; Wed, 09 Mar 2022 09:56:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=dxyAlQyF00wtG3FrFbPYRTNEBsaubyHj1CShVwixHgg=;
        b=JWJMsdqVWSo7Au1dU5Lzfj+4E+URGBOdPpsn1x0EC0KWIIQjUxJ7LyILI7XwWms9uv
         xhHfjiuRcJ7mQZnK6CEVby03Tbz51bvvhrzPHjL9BKrRT9mxgBaRLN9jLXv7o9fAiGqT
         iT+CblLUqN3KmHiYYN0G8Gwlnx/SYHEHCkFxeVeCZngoyXPAPahaK0BOAKLUPtxB9Zbw
         gf0ygdxIR0h+EnvXMbO9o0+WmGE+MF0ZWB0Xn4uZ6bFAPIWkDFIA864m8GOg0nC7YNdw
         j1D6kB71PID4cFO9YAjIq6YTYm/ikvCUiqf6GdjCY0eXCZA6BuFN95HyjWrY2e8RSuIb
         xRiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=dxyAlQyF00wtG3FrFbPYRTNEBsaubyHj1CShVwixHgg=;
        b=55wiZsuK1d+/tiFqBH8bMu/G4XlBc1FmcWS3qBvbxqhy79kGWxdolt/mUMuf+Thedy
         c5dA4g2c8BCQefYKoSMCnPPTvU9P/iFEl5fWIZUcjDXmPGn47iF7jcpNAch0rtPOe1dP
         g6FuXBhKN5j/aPTq03z70bS5DsPFJdkbA+CSHysJj/veQl3L8N5dz0RIy6fgQFoclPuR
         w6eIMksbG7YdI4JHdhDVH1+tbMBdR+Omsv0IxrpRJGcIyakIdj7V43m7noRboBktBGDt
         xucMbrhsTbHHqSt1HnGzr3FepXdQOjbhtNS7rekD8mkLeXQlaOHAprj/DCssUmQAwpXO
         smAA==
X-Gm-Message-State: AOAM53225lmt44cM8lh8kH12V2mr9zc2jEpB8HuIm61G/uZ2wq+erHlZ
	/7RqNa5pE01dNjsqxONDCZXdazdNSG58H8BgI4GcPKlRT4IP1w==
X-Google-Smtp-Source: ABdhPJwzZJkkn+kD5cakDmRzRZ+h/6TU+LUcTtUE4GiLP4pBr1UpV2k2JIf3rnTxpM4wdPfL4CXUzBLbYN7qsPoGhj8=
X-Received: by 2002:a05:6402:5cb:b0:415:e04a:5230 with SMTP id
 n11-20020a05640205cb00b00415e04a5230mr642203edx.352.1646848556294; Wed, 09
 Mar 2022 09:55:56 -0800 (PST)
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
From: Archimedes Gaviola 
Date: Thu, 10 Mar 2022 01:55:44 +0800
Message-ID: 
Subject: Raspberry Pi 3B USB Printing Issue
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000032685a05d9cccf8d"
X-Rspamd-Queue-Id: 4KDKcg0PV4z4nTB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=JWJMsdqV;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4571
Lines: 98

--00000000000032685a05d9cccf8d
Content-Type: text/plain; charset="UTF-8"

Hi,

I have an Epson printer connected to one of the USB ports of my RPi 3B. The
printer is detected as a ugen(4) driver and then I have a text file -
myfile3.txt which contains 10 lines of repeating sentences.

freebsd@generic:~ % dmesg | grep EPSON
ugen1.4:  at usbus1

freebsd@generic:~ % cat myfile3.txt
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.

freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1

I print the file successfully through device file redirection with cat
command as described above. However, there were times that printing seemed
to suspend and withhold especially when my RPi 3B system got idle for some
period of time. Suspended or withhold in such a way that out of the 10
lines there were only 2-3 lines to be printed in the paper. So, the only
remedy I have for now is to reboot the system to be able to get back to
normal printing. I'm using the 14.0-CURRENT #0 main-n253384-45c23c2608e:
Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this behavior
using this same 14.0-CURRENT version. Any idea what's going on?

I found these sysctl knobs thinking if some tweaks would help but not sure
what are the exact settings beyond these defaults.

hw.usb.timings.port_resume_delay: 40
hw.usb.timings.port_powerup_delay: 300
hw.usb.timings.port_reset_recovery: 10
hw.usb.timings.port_root_reset_delay: 200
hw.usb.timings.port_reset_delay: 50

(Resend this message without dmesg and sysctl outputs as files are quite
big, sorry I didn't notice it.)

Thanks,
Archimedes

--00000000000032685a05d9cccf8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




Hi,

I have an Eps=
on printer
 connected to one of the USB ports of my RPi 3B. The printer is detected=20
as a ugen(4) driver and then I have a text file - myfile3.txt which=20
contains 10 lines of repeating sentences. 

fre=
ebsd@generic:~ % dmesg | grep EPSON
ugen1.4: <EPSON EPSON UB-U03II>=
; at usbus1

freebsd@generic:~ % cat myfile3.txtThe quick brown fox jumps over the lazy dog.
The quick brown fox jumps =
over the lazy dog.
The quick brown fox jumps over the lazy dog.
The q=
uick brown fox jumps over the lazy dog.
The quick brown fox jumps over t=
he lazy dog.
The quick brown fox jumps over the lazy dog.
The quick b=
rown fox jumps over the lazy dog.
The quick brown fox jumps over the laz=
y dog.
The quick brown fox jumps over the lazy dog.
The quick brown f=
ox jumps over the lazy dog.


freebsd@generic:~ % cat myfile3.txt=C2=A0 > /dev/usb/1.4.1



I print the file successfully through device=20
file redirection with cat command as described above. However, there=20
were times that printing seemed to suspend and withhold especially when=20
my RPi 3B system got idle for some period of time. Suspended or withhold
 in such a way that out of the 10 lines there were only 2-3 lines to be=20
printed in the paper. So, the only remedy I have for now is to reboot=20
the system to be able to get back to normal printing. I'm using the=20
14.0-CURRENT #0 main-n253384-45c23c2608e: Thu Feb 24 09:18:58 UTC 2022



 and my RPi 4B does not manifest this behavior using this same=20
14.0-CURRENT

version.=20
Any idea what's going on?

I found these sy=
sctl knobs thinking if some tweaks would help but not sure what are the exa=
ct settings beyond these defaults.

hw.usb.timi=
ngs.port_resume_delay: 40
hw.usb.timings.port_powerup_delay: 300
hw.u=
sb.timings.port_reset_recovery: 10
hw.usb.timings.port_root_reset_delay:=
 200
hw.usb.timings.port_reset_delay: 50

=

(Resend this message without dmesg and sysctl outputs as fi=
les are quite big, sorry I didn't notice it.)

<=
div>Thanks,
Archimedes


--00000000000032685a05d9cccf8d--

From nobody Wed Mar  9 19:56:35 2022
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 3E0DC1A0AEBF
	for ; Wed,  9 Mar 2022 19:57:14 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KDNJT20zyz3JQC
	for ; Wed,  9 Mar 2022 19:57:13 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 1DF552110C3
	for ; Wed,  9 Mar 2022 14:56:37 -0500 (EST)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id ABC87490A06
	for ; Wed,  9 Mar 2022 14:56:36 -0500 (EST)
Message-ID: 
Date: Wed, 9 Mar 2022 14:56:35 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Karl Denninger 
Subject: Pi4 via Crochet?
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060907090701090205090807"
X-Rspamd-Queue-Id: 4KDNJT20zyz3JQC
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-4.89 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 HAS_ATTACHMENT(0.00)[];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.987];
	 RCPT_COUNT_ONE(0.00)[1];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8885
Lines: 153

This is a cryptographically signed message in MIME format.

--------------ms060907090701090205090807
Content-Type: multipart/alternative;
 boundary="------------1XK5RpABEkvz810OpcAtgbSI"

--------------1XK5RpABEkvz810OpcAtgbSI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Anyone got the necessary magic for it on -HEAD?

I've tried to build it and the SD card it makes appears to be built 
correctly.  I copied the Pi3s board config and modified it to get the 
RPI4 dtb and config.txt files, along with the RPI4 u-boot package.  That 
*should* work, I'd expect.

I get nothing on the serial console at all and only a three-blink/pause 
pattern on the green LED when power is connected so I have no idea where 
its failing in the boot process.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------1XK5RpABEkvz810OpcAtgbSI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Anyone got the necessary magic for it on -HEAD?

    
I've tried to build it and the SD card it makes appears to be
      built correctly.  I copied the Pi3s board config and modified it
      to get the RPI4 dtb and config.txt files, along with the RPI4
      u-boot package.  That *should* work, I'd expect.

    
I get nothing on the serial console at all and only a
      three-blink/pause pattern on the green LED when power is connected
      so I have no idea where its failing in the boot process.

    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------1XK5RpABEkvz810OpcAtgbSI--

--------------ms060907090701090205090807
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO
62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp
ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD
QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx
MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A
16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg
96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg
y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs
YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg
6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX
SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM
cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN
5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l
CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg
CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v
b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG
SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O
BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC
GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE
BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh
IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ
zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN
AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR
dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu
2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X
lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK
FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q
IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA
1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL
shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ
qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE
QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMzA5MTk1NjM1
WjBPBgkqhkiG9w0BCQQxQgRAdDyukyWZfOlGvigARR20zPXUAaaGPXSYJSlqbY224CJ1Xi9i
wO5Cj1FbsiIRuxDOCxvYoHrEhKDeAYasAuQ1ZDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg
gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz
dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0
ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF
AASCAgCH2qciRMWzmytpzRWkSp/euN0TEYBje/SivBmCPyadYtVrIQ7A6a86XFm+Ayzsb/Nt
x9sqDai2eUKDQgg0ZIkU/xeVMQ8qWiOU+yFrSyGVsds2yFZg6Xa8NsQ+1QPHjzEFDwMbbk2W
bpgtypY3y6Xne5kw+xJyk0tbvWqbMp8byvmBh8hz57SwZN5GCNjVX1okrAyJRjZzIqO/DXns
MQDbFlaur54hWwdCgXMiOYaSunFakTl1TeLcuxfBAiRX0+Ak1EMwU6DXRq7RfKTmx7bjVIOj
fnxe0sDT9QQT1DYz0SOLTBX2b9Le6H4FKaKylzW95PoXlzbVlG1RIyjdZu1Pdp10RCiJRjzS
hKpCUDPpsMJOj/SJh7gI8ZGonZGHChWFDOr/WnwVGMfJqDZVz8+5s7EMIRTBhu+XYn3LYV0F
jm+KZE74YkC6m4TKZ9aof6QbEa2BQSdilop/SdHrXnHOKK2G18Ipmd2GSW8MTuyLKg4KAcbr
dfSej/e+jTywcLSgbJ3FvQy5XIJugw0Ma3QzWB8/5lCUXy+7Sp17zFyrEncBkIJFBHnLVi6X
s6yoAxgWi9GAliMrD1H/ANcMoElVWZ2tG8LM2Nd9QB/gyMgJWhIa2GGsjyeld0ZCljVGs6S4
dgJmA5ImDqne6QVYpHXBrsxIu3DkVKRngJGCyzGG/wAAAAAAAA==
--------------ms060907090701090205090807--

From nobody Wed Mar  9 20:13:56 2022
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 D62711A0DABC
	for ; Wed,  9 Mar 2022 20:14:18 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KDNhB1TRqz3LN7
	for ; Wed,  9 Mar 2022 20:14:18 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 5D60826163C;
	Wed,  9 Mar 2022 21:14:10 +0100 (CET)
Message-ID: <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
Date: Wed, 9 Mar 2022 21:13:56 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola , freebsd-arm@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KDNhB1TRqz3LN7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2138
Lines: 54

On 3/9/22 18:55, Archimedes Gaviola wrote:
> Hi,
> 
> I have an Epson printer connected to one of the USB ports of my RPi 3B. The
> printer is detected as a ugen(4) driver and then I have a text file -
> myfile3.txt which contains 10 lines of repeating sentences.
> 
> freebsd@generic:~ % dmesg | grep EPSON
> ugen1.4:  at usbus1
> 
> freebsd@generic:~ % cat myfile3.txt
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> The quick brown fox jumps over the lazy dog.
> 
> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
> 
> I print the file successfully through device file redirection with cat
> command as described above. However, there were times that printing seemed
> to suspend and withhold especially when my RPi 3B system got idle for some
> period of time. Suspended or withhold in such a way that out of the 10
> lines there were only 2-3 lines to be printed in the paper. So, the only
> remedy I have for now is to reboot the system to be able to get back to
> normal printing. I'm using the 14.0-CURRENT #0 main-n253384-45c23c2608e:
> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this behavior
> using this same 14.0-CURRENT version. Any idea what's going on?
> 
> I found these sysctl knobs thinking if some tweaks would help but not sure
> what are the exact settings beyond these defaults.
> 
> hw.usb.timings.port_resume_delay: 40
> hw.usb.timings.port_powerup_delay: 300
> hw.usb.timings.port_reset_recovery: 10
> hw.usb.timings.port_root_reset_delay: 200
> hw.usb.timings.port_reset_delay: 50
> 
> (Resend this message without dmesg and sysctl outputs as files are quite
> big, sorry I didn't notice it.)
> 

Hi,

Why are you not using /dev/ulpt ?

/dev/usb/1.4.1 is the raw BULK endpoint.

--HPS

From nobody Wed Mar  9 21:21:22 2022
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 07C5D19F3C14
	for ; Wed,  9 Mar 2022 21:21:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KDQ9r5v0Zz3nH5
	for ; Wed,  9 Mar 2022 21:21:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646860888; bh=YvrqdvJmXq+vEj51xffMIdpqECnb1yxgA23SKBYGOtk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=n4iS2ZrXBX1eY+0p6O+L4lFrb2DwBcSP+lr1rouY+DNk82sHgv8BT7PppeAvmMzVBj0UVvk2ruBmS7g+q5KcDCn4aQbT+WNxbY7qYCrBwO6Rfvztz74fZy2curlbPO6mWi4Ng/CxgpwCJh0TyVxtlr+MxA7WxKh/LiwxeYWSjOh/3BGg4CNnxr0fGuXe/3t3myreQ1+iwUNOSTAlud1Dplsv3PUShv+ouxHVwEWajCCMZduDa39z4Ma3L0VDmpg0QT1fiucq1HU++4r4uL3la8vBHHb54+xXLem8V7Cs9auTHWsJJwrDMbRY4uf+N8ELaawlb/fUpy7TDWkonCQvjw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646860888; bh=Lo0wtv35MftYmCvGiNj4vV/U218RPrBGDzzm5/Czwvy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r+tJK2DMxSc3Sf4WZ/HbDYolmkfjWCa9qZmWSrE1yWehFhlk7OXYkzrS6KR+d0KaUXJonyJ3PzXXf0AnTmW0s+q9W90s2i/MT/43xgAtM22PWroJqHJ5fMxgGhd998VVu7Qkv9u19gCbQcA1U62WIrpWbuI6G3FVLfMS/NgwU8Yf98GP7cYPBJBPRlqz5Dlp7mfLcZK8T7eBulYfFGDV26peJBZPHVxs8XSQMFMXqLeYGxwBFrcBCTtUSPRz9dJe3lkRCYtF4s/3XwZsTJ8tcQ17BLTny0NIvWPXcHmNL1p/0NQpPsYqWpFYLrmcMgB5K5F2JXqqzHz7HOtc9vj2Tw==
X-YMail-OSG: WNCSNXoVM1k3u65qX1H6C4aJJvjoboPPZ.MbIZB5GMuB_80oX_n6DMLHxO5qqz3
 B5BguSQXTdxnoeGB7crEKWvFzxS2PE2BpeivJW0IcObrnzsmv6tzfb_gUMbzZBuj7cHPZPVBIedJ
 MVgFK4uw0BgKb7Ml.dN1EQtbT3ZG.6Rn1z8K58oXNxnw0ZbA9EyjI_ipcepMHOiQQwsL5NV2VaGN
 KBzzQ5mEiAWtucgBTNki1ct.7pLRVTPQxqFiNzCuE3PefKYjmPpUZJ72pW_AWm2wwpJ_q9TlRQA9
 JcCv2cCvUioSmnAGUZ8I6v105YRfc2sfkuUwen1RrCAfuDMXYwTAtXNWEMGAHcr1z7unDLgH6J.N
 keWCIG1o57WkvuRCm0edMGiFkzJzCs8vU_TRYc8p.nTADlhLzNFhJb02FxQ1h5_U08gsBoqLlcy2
 FCYyxa4dsAZGIeOPfyDLwyz9FUGN2Of0PMJI1bJpq9fLRwv2ym4Ivg_i8mxgZr76.9pUwal0GD1s
 fD810MOeGqHxxEKpiIKyCTbODcY4pgdTpWFx9ngMslVqsTglAWwHB2iM0FiEN1qaCLwBKaLJbP_8
 AWsv4Hti_lnPKOOpreyb6cWO9FRyViqE0rDSgfxyh_HxBqcRtSsMbFeBziEYxgVW7kvov3Wh_onD
 795Fz9TLER86unrbZg4vsyTcuyht2Ez9dBaprpUmipedGvhIlZGAv4c_CKcT5sif7.l9BBmUedWT
 qx4OgneiK0BnvV3fDHopLUzOqenXI341gLhC4qi3esXP4Nz1uqNhFfXmLTIZIGImDbZ_FykDZMsB
 pVwgYkU2V75KDVS_Ax45NeMhsTnJYqmHMq.wNHzin7op4UR2x999a._vl.OlAAGKRX1RROJMgMdU
 rmHmapvPR_khH9pOQL5HW2NJATi5mUl8AjjzAYIPG0FWRHIVcMlv1ULKqNfMD.G4hKDJopRKtMv9
 48lYeneE7a80E0EwBKTuBEFx2zB7wVq4fK4USYRr0.FVbxKXFOkY2EpeSKMAv_g8RUueY8k876y_
 ejM8eR2QntkSzUJgxFSST2QiD2G9Lo7ukq1GV0C2aZDxlR0yV4hGviMXYAj04cE2NEEcAty.M54Y
 xbzAb0Bh0AUaefwlz0Qf1fhh7ZxsQjl_YHMqsMPaxWrtsSxP9HKzi0_ev5Rw72izOrgEEnt07jgr
 yCH2wSaUBOxF6RvEQjacLT3S9mmqWwxGL6N86cr0ElGgA1q_thYNwYtPcxgo.v0N7lKBHwF4qRx.
 xTmXWIRd.b.vczeZH.aEp.HkRfme0DAKHEvnYVu4L869zuczq.bLoVbFaTIk.8gs7kplUtSkIzYe
 fEy8sN3qBCA1j13DUuz3cdsQweespo02trqF7Knxi5P83n4rHz9d6wXE5TN6QcztqAuLvEg7V_77
 B8tTKeHeBuRsiCEiy00JkUOlzXg_f1WdcgU0Vb_IL.Hch.gxXQ3N59ASHCLTWza58Uj91OWYRfUh
 WKvTFcuUFG9l1k2.EIzhlDtGb9IcWn0QGIL8HM2uiq6RyE0S6atdq1eeX.0AZ83_r_GJ06fr9Rmw
 MnWZIVNXL_F6JvvbYx9dRg2gMCrWNo_8BxrOnUva1kseIagZ_iR2wTocTCa1BO2a6L8ZDjbI5UD9
 hqZhE3v8LJ.FGjRKD7adbR.T_kiY0S2qmAMhxHG0eBQ_UqkNDetpLTc8aycSXNbgNXwpSci1zD0V
 ThNNr6aI4Z6F7Twv8ZNix25EpbjHGl9IKiY9GSmpW0xhkCZr1eYn4W2po6MxxkmhwODn.yK.9SYM
 6rYYJxhGJCYj2bhQVLZc0XAbe3FXPBoi7pGda5QUWwuy0bgGGYuN9nYA84l2pI66NP1.6r5XyTft
 LFIMrydX.vEylsvEgh3vG4su4fezL7glS4EAhPv_g667fn0QmMJhzFWrYPxpyotzD7OHluouk_OU
 DMPte7NBJEEIQ0ZYguT8iI..xY0vfEhua30EaCk4.mrdfjMFos6T5ugLYDC3DTrES1q9gnyn6fcQ
 gvVy5RHgK8uNa7KoUFEk0W9tC7Jm_06TwS9It7Pvao01CmzXADxpX35QyxwNRItvwEWhIymX6Fya
 zBSUIH6el_euC7j6TA86Cz63hX30Cb6bse174wwcCb8AT1qmPqCPLt4nh639_AKaLlllPSUcRETc
 PQf5bYsDgnhzTCtv_iruVA3Ge_6ZBO0PoKM6gjOS8d5fhHfYn09T6mxBz2_fT5eGWf.ZcZif1Yzf
 rPMpvTTSVXtfE8rtmwxpI5utw3LYEnojnRIEqysk57jEZq.jDwEj4bMxPdck41CCv2ev8C7Q.BVE
 hcAM2FJJUcxA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Mar 2022 21:21:28 +0000
Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 90f9fadd0b087fa2639ddd5460fad119;
          Wed, 09 Mar 2022 21:21:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Pi4 via Crochet?
From: Mark Millard 
In-Reply-To: 
Date: Wed, 9 Mar 2022 13:21:22 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Karl Denninger 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KDQ9r5v0Zz3nH5
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=n4iS2ZrX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3224
Lines: 103

On 2022-Mar-9, at 11:56, Karl Denninger  wrote:

> Anyone got the necessary magic for it on -HEAD?
>=20
> I've tried to build it and the SD card it makes appears to be built =
correctly.  I copied the Pi3s board config and modified it to get the =
RPI4 dtb and config.txt files, along with the RPI4 u-boot package.  That =
*should* work, I'd expect.
>=20
> I get nothing on the serial console at all and only a =
three-blink/pause pattern on the green LED when power is connected so I =
have no idea where its failing in the boot process.
>=20

What you describe is long before FreeBSD is involved. The sequence
for an RPi4 (in use-aarch64 mode) is basically:

RPI4 EEPROM
config.txt (you mentioned this one)
start4.elf (note the "4")
fixup4.dat (note the "4")
bcm2711-rpi-4-b.dtb (you mentioned this one)
(I omit overlays and such steps here.)
armstub8-gic.bin
U-Boot
FreeBSD loader (efi/boot/bootaa64.efi)
FreeBSD kernel (not from the msdos file system)
FreeBSD world  (not from the msdos file system)

But what you report looks like not even the RPi* firmware
got started.

If Crochet has copies of or refers to RPi* firmware to
put in the msdos file system, I see no evidence of
updates after the RPi4 was released. If so, the
materials are possibly way out of date --or track
the development firmware releases (frequently broken).
(It basically takes manual tracking to identify good
RPi* firmware and U-Boot combinations.)

A similar point could go for whatever U-Boot vintage
it is set up to put in place, although you did not
get that far (yet).

There are lots of vintages of the RPi* firmware and
U-Boot around and many combinations do not work well.
You were not explicit about what versions you are
using.

What does your context show for the likes of:

# strings start4.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

# strings u-boot.bin | grep "U-Boot 20"
U-Boot 2021.07 (Jan 22 2022 - 18:06:42 -0800)

Does the msdos file system have all files:

config.txt (you mentioned this one)
start4.elf (note the "4")
fixup4.dat (note the "4")
bcm2711-rpi-4-b.dtb (you mentioned this one)
(Here, I omit overlay/ content.)
armstub8-gic.bin
u-boot.bin
efi/boot/bootaa64.efi

Note that armstub8-gic.bin is neither RPi* firmware
nor part of U-Boot nor part of FreeBSD. But installing
the port sysutils/rpi-firmware supplies a copy under:

/usr/local/share/rpi-firmware/

with the RPi* firmware.

(I've not been tracking the status of RPi* firmware,
armstub8-gic.bin , or U-Boot for any RPi*s in some
time. Other vintages may be better than what I happen
to have around. There is more modern RPi* hardware
that "my vintage" materials would definitely not
handle. I'm not sure anyone is trying to track what
vintages are good vs. bad, or in what contexts or
in what ways.)

Note: What I have in overlays/ is just:

overlays/disable-bt.dtbo
overlays/miniuart-bt.dtbo
overlays/mmc.dtbo
overlays/pwm.dtbo

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar  9 21:49:47 2022
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 6BF4B19FC4FA
	for ; Wed,  9 Mar 2022 21:49:50 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KDQpP62Zbz3tqY
	for ; Wed,  9 Mar 2022 21:49:49 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 688D12110C3
	for ; Wed,  9 Mar 2022 16:49:49 -0500 (EST)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 1F755490E7C
	for ; Wed,  9 Mar 2022 16:49:49 -0500 (EST)
Message-ID: 
Date: Wed, 9 Mar 2022 16:49:47 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Pi4 via Crochet?
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 
From: Karl Denninger 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000203040300060707060905"
X-Rspamd-Queue-Id: 4KDQpP62Zbz3tqY
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-4.90 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 HAS_ATTACHMENT(0.00)[];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 15820
Lines: 360

This is a cryptographically signed message in MIME format.

--------------ms000203040300060707060905
Content-Type: multipart/alternative;
 boundary="------------HG0uHK9hK7Q02C9IGT17FG09"

--------------HG0uHK9hK7Q02C9IGT17FG09
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 3/9/2022 16:21, Mark Millard wrote:
> On 2022-Mar-9, at 11:56, Karl Denninger  wrote:
>
>> Anyone got the necessary magic for it on -HEAD?
>>
>> I've tried to build it and the SD card it makes appears to be built correctly.  I copied the Pi3s board config and modified it to get the RPI4 dtb and config.txt files, along with the RPI4 u-boot package.  That *should* work, I'd expect.
>>
>> I get nothing on the serial console at all and only a three-blink/pause pattern on the green LED when power is connected so I have no idea where its failing in the boot process.
>>
> What you describe is long before FreeBSD is involved. The sequence
> for an RPi4 (in use-aarch64 mode) is basically:
>
> RPI4 EEPROM
> config.txt (you mentioned this one)
> start4.elf (note the "4")
> fixup4.dat (note the "4")
> bcm2711-rpi-4-b.dtb (you mentioned this one)
> (I omit overlays and such steps here.)
> armstub8-gic.bin
> U-Boot
> FreeBSD loader (efi/boot/bootaa64.efi)
> FreeBSD kernel (not from the msdos file system)
> FreeBSD world  (not from the msdos file system)
>
> But what you report looks like not even the RPi* firmware
> got started.
>
> If Crochet has copies of or refers to RPi* firmware to
> put in the msdos file system, I see no evidence of
> updates after the RPi4 was released. If so, the
> materials are possibly way out of date --or track
> the development firmware releases (frequently broken).
> (It basically takes manual tracking to identify good
> RPi* firmware and U-Boot combinations.)
>
> A similar point could go for whatever U-Boot vintage
> it is set up to put in place, although you did not
> get that far (yet).
>
> There are lots of vintages of the RPi* firmware and
> U-Boot around and many combinations do not work well.
> You were not explicit about what versions you are
> using.
>
> What does your context show for the likes of:
>
> # strings start4.elf | grep "VC_BUILD_ID_"
> VC_BUILD_ID_USER: dom
> VC_BUILD_ID_TIME: 12:10:40
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
>
> # strings u-boot.bin | grep "U-Boot 20"
> U-Boot 2021.07 (Jan 22 2022 - 18:06:42 -0800)
>
> Does the msdos file system have all files:
>
> config.txt (you mentioned this one)
> start4.elf (note the "4")
> fixup4.dat (note the "4")
> bcm2711-rpi-4-b.dtb (you mentioned this one)
> (Here, I omit overlay/ content.)
> armstub8-gic.bin
> u-boot.bin
> efi/boot/bootaa64.efi
>
> Note that armstub8-gic.bin is neither RPi* firmware
> nor part of U-Boot nor part of FreeBSD. But installing
> the port sysutils/rpi-firmware supplies a copy under:
>
> /usr/local/share/rpi-firmware/
>
> with the RPi* firmware.
>
> (I've not been tracking the status of RPi* firmware,
> armstub8-gic.bin , or U-Boot for any RPi*s in some
> time. Other vintages may be better than what I happen
> to have around. There is more modern RPi* hardware
> that "my vintage" materials would definitely not
> handle. I'm not sure anyone is trying to track what
> vintages are good vs. bad, or in what contexts or
> in what ways.)
>
> Note: What I have in overlays/ is just:
>
> overlays/disable-bt.dtbo
> overlays/miniuart-bt.dtbo
> overlays/mmc.dtbo
> overlays/pwm.dtbo
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
Aha -- some of the "4" required files were not.  I have my own local 
copy of Crochet and have been maintaining it myself; the base repo has 
nothing for the "4" in it at this point.

Got it fixed up and it boots.  There are some complaints about 
interrupts on sdhci with no active command during the boot process but 
other than that it looks to be running more-or-less as expected.

Thanks!

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------HG0uHK9hK7Q02C9IGT17FG09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 3/9/2022 16:21, Mark Millard wrote:

    

    

      
On 2022-Mar-9, at 11:56, Karl Denninger <karl@denninger.net> wrote:



      

        
Anyone got the necessary magic for it on -HEAD?

I've tried to build it and the SD card it makes appears to be built correctly.  I copied the Pi3s board config and modified it to get the RPI4 dtb and config.txt files, along with the RPI4 u-boot package.  That *should* work, I'd expect.

I get nothing on the serial console at all and only a three-blink/pause pattern on the green LED when power is connected so I have no idea where its failing in the boot process.



      

      
What you describe is long before FreeBSD is involved. The sequence
for an RPi4 (in use-aarch64 mode) is basically:

RPI4 EEPROM
config.txt (you mentioned this one)
start4.elf (note the "4")
fixup4.dat (note the "4")
bcm2711-rpi-4-b.dtb (you mentioned this one)
(I omit overlays and such steps here.)
armstub8-gic.bin
U-Boot
FreeBSD loader (efi/boot/bootaa64.efi)
FreeBSD kernel (not from the msdos file system)
FreeBSD world  (not from the msdos file system)

But what you report looks like not even the RPi* firmware
got started.

If Crochet has copies of or refers to RPi* firmware to
put in the msdos file system, I see no evidence of
updates after the RPi4 was released. If so, the
materials are possibly way out of date --or track
the development firmware releases (frequently broken).
(It basically takes manual tracking to identify good
RPi* firmware and U-Boot combinations.)

A similar point could go for whatever U-Boot vintage
it is set up to put in place, although you did not
get that far (yet).

There are lots of vintages of the RPi* firmware and
U-Boot around and many combinations do not work well.
You were not explicit about what versions you are
using.

What does your context show for the likes of:

# strings start4.elf | grep "VC_BUILD_ID_"
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

# strings u-boot.bin | grep "U-Boot 20"
U-Boot 2021.07 (Jan 22 2022 - 18:06:42 -0800)

Does the msdos file system have all files:

config.txt (you mentioned this one)
start4.elf (note the "4")
fixup4.dat (note the "4")
bcm2711-rpi-4-b.dtb (you mentioned this one)
(Here, I omit overlay/ content.)
armstub8-gic.bin
u-boot.bin
efi/boot/bootaa64.efi

Note that armstub8-gic.bin is neither RPi* firmware
nor part of U-Boot nor part of FreeBSD. But installing
the port sysutils/rpi-firmware supplies a copy under:

/usr/local/share/rpi-firmware/

with the RPi* firmware.

(I've not been tracking the status of RPi* firmware,
armstub8-gic.bin , or U-Boot for any RPi*s in some
time. Other vintages may be better than what I happen
to have around. There is more modern RPi* hardware
that "my vintage" materials would definitely not
handle. I'm not sure anyone is trying to track what
vintages are good vs. bad, or in what contexts or
in what ways.)

Note: What I have in overlays/ is just:

overlays/disable-bt.dtbo
overlays/miniuart-bt.dtbo
overlays/mmc.dtbo
overlays/pwm.dtbo

===
Mark Millard
marklmi at yahoo.com



    

    
Aha -- some of the "4" required files were not.  I have my own
      local copy of Crochet and have been maintaining it myself; the
      base repo has nothing for the "4" in it at this point.

    
Got it fixed up and it boots.  There are some complaints about
      interrupts on sdhci with no active command during the boot process
      but other than that it looks to be running more-or-less as
      expected.

    

    
Thanks!

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------HG0uHK9hK7Q02C9IGT17FG09--

--------------ms000203040300060707060905
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO
62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp
ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD
QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx
MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A
16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg
96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg
y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs
YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg
6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX
SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM
cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN
5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l
CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg
CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v
b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG
SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O
BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC
GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE
BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh
IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ
zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN
AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR
dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu
2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X
lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK
FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q
IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA
1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL
shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ
qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE
QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMzA5MjE0OTQ4
WjBPBgkqhkiG9w0BCQQxQgRAgsMKCnlvbsHZpgMPAA3s+r47uhm76Pv2TOgVAj5J7lbxJTp+
F53aw5/IlvyhLI0S3f6VUXfpoFRTe0la8nGwjTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl
AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM
TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM
QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg
gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz
dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0
ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF
AASCAgC04c6//kNO+N9cQXzSyG/5MqOswtZ6Ul1VLddF1bSA7UZlxiQpatJlW1xSyQmz4T+E
RLsiXoSyfbbcCBKlwqbuh1R1wRVGi9Wcswe1Bj/9uBadgNV+2d4bFoxxdLniuKaX3BsOjRvQ
OdWUGNAeYoawvu/tm/iITliEFop44blAeIwGulEcWeRFb8eOBPS+Y0gFrm4d63LWGiaT+tOG
qoSSJdFHJCSMdYdGtY2qsKva90VxDVRA0UhTGxmQe34osbsdJ+zD9Li/NITJ/F3I+NJ5huqV
Hsqs9V+cJxL1vRzYmC/fq5lKaTE+zUahi8XnJuc42WnmOhwd7Styj/3/LjATiEckyeaha5LX
T1f/3+Xyjjg7wyIjkZ8Rt1N8tpsLWutJDXXFrXm97E6xgscVah5gfL56w8g8TgMjGq3U1Yup
jbQj14aOK6j0TgDcZDULHvgBRnGSXRNmfZnIFHbZ3G5s/K3Zqo4rx3mepoR+VoJZDnBJbfoJ
Ei7cSXyeIoanOsV7a+OssRPUyZw/LjeifZ+k1fQTNKCk+7NZaUi5zhqMc1pQ3WeR6ndYBujc
QpnQ83E87x8nWSiG9fXjP8HsSGd0+ob1tHx40a3Tsv2Ydfc3sTBoe6qv7hkiyHfv+Kx6rTGh
eYQe2KU4QcMBFH1FJ7dW3Tnglpk3ca/+wiqfyo/RcQAAAAAAAA==
--------------ms000203040300060707060905--

From nobody Wed Mar  9 23:24:58 2022
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 17C831A0D3E0
	for ; Wed,  9 Mar 2022 23:25:11 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633])
	(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 4KDSwQ2Wbkz4YWZ
	for ; Wed,  9 Mar 2022 23:25:10 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x633.google.com with SMTP id qa43so8324944ejc.12
        for ; Wed, 09 Mar 2022 15:25:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=IT1e3A2zZ/yqy7GVi/veF6/gVVX161oSZIjYxSe9UeI=;
        b=OInIz3TRj5HCyG821hxRaZ5U9jph2+v7QMYrTuIYBuCVZKtjJ1OZpioOf+LNqhAJlO
         R2+3YW59N0qomXosVEmwN97dqx0H6DI1EBJkLPm8uO1BwvU9mHNysLNvQ1tuEe/qAeMM
         Eg0V9ZDCDkacP8Yk4VQAxmDxiL5Fcfd+CFetqSJkJhL15Y+cemq2qW5WtaxdbYmSOUPJ
         pFvAS4lgNP9/ZAOcbN3Q78dZl64/xg7970O1Iabw38RmEObRycVKCk/rR2lHqybAaMcB
         ew1u6AdJ7r1OKOx5tMismfDfuWM6ceziqYNxSp3lUHvb4PTzOiazk56bsYcGPLvmWGVG
         +QSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=IT1e3A2zZ/yqy7GVi/veF6/gVVX161oSZIjYxSe9UeI=;
        b=PLjqP6CJPnZHh4uK+YxNh4ZOF8fzEzRxqGVIpxjCluUfdqWXd6DGPkkoYDIfusdDf9
         8GXz6g88Q4nFoeCiG3Rc3BqqTQmC+n+A5QJcA/+BnOAK7gES0QEWKYYVk0JXNG/kAPS9
         DSxutt9CA78uZrAetJuyYD+9ufgzkUrxlZZfZIw8fODUe7Cm8kcnFeU7IKO7LzT4BTZq
         shgGvTB6l16Qjj5L5vVA4q3HayjAVH7wolBmy6CyaWiX3P44ut9I7m12ZSRM8TyOBNMb
         IJwhHLOS/Q0NZcdEMpalNF1yz2U2fcWo6xsqOatRuMPniYa50ClO1p8rZafyouKBIYCE
         GeNw==
X-Gm-Message-State: AOAM530qiyW3gDYVt1pHqPMaR5/5juxk3yXiqkWCYK539oulatEWi3VQ
	AAu9VobsdhjQOgE2cFEQm8Tm2AjwgPhUPw9Ep3hSNVlZFq0=
X-Google-Smtp-Source: ABdhPJxY0Dlfuo2KEtTYDZmMIXTA9cW0x+JpPdTjLLRCQmvqA3z5lCYtewGJV7y9zoWcA1PUv2Cf4T7vl8uDgXAnTEg=
X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id
 b17-20020a1709063cb100b006ce2a975ademr1880784ejh.728.1646868309242; Wed, 09
 Mar 2022 15:25:09 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
In-Reply-To: <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
From: Archimedes Gaviola 
Date: Thu, 10 Mar 2022 07:24:58 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000009078a205d9d16850"
X-Rspamd-Queue-Id: 4KDSwQ2Wbkz4YWZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=OInIz3TR;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5950
Lines: 153

--0000000000009078a205d9d16850
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky  wrote:

> On 3/9/22 18:55, Archimedes Gaviola wrote:
> > Hi,
> >
> > I have an Epson printer connected to one of the USB ports of my RPi 3B.
> The
> > printer is detected as a ugen(4) driver and then I have a text file -
> > myfile3.txt which contains 10 lines of repeating sentences.
> >
> > freebsd@generic:~ % dmesg | grep EPSON
> > ugen1.4:  at usbus1
> >
> > freebsd@generic:~ % cat myfile3.txt
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> > The quick brown fox jumps over the lazy dog.
> >
> > freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
> >
> > I print the file successfully through device file redirection with cat
> > command as described above. However, there were times that printing
> seemed
> > to suspend and withhold especially when my RPi 3B system got idle for
> some
> > period of time. Suspended or withhold in such a way that out of the 10
> > lines there were only 2-3 lines to be printed in the paper. So, the only
> > remedy I have for now is to reboot the system to be able to get back to
> > normal printing. I'm using the 14.0-CURRENT #0 main-n253384-45c23c2608e:
> > Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
> behavior
> > using this same 14.0-CURRENT version. Any idea what's going on?
> >
> > I found these sysctl knobs thinking if some tweaks would help but not
> sure
> > what are the exact settings beyond these defaults.
> >
> > hw.usb.timings.port_resume_delay: 40
> > hw.usb.timings.port_powerup_delay: 300
> > hw.usb.timings.port_reset_recovery: 10
> > hw.usb.timings.port_root_reset_delay: 200
> > hw.usb.timings.port_reset_delay: 50
> >
> > (Resend this message without dmesg and sysctl outputs as files are quite
> > big, sorry I didn't notice it.)
> >
>
> Hi,
>
> Why are you not using /dev/ulpt ?
>
> /dev/usb/1.4.1 is the raw BULK endpoint.
>


Hi Hans,

The ulpt(4) driver isn't detected with this Epson printer. Only my other
printer which is an Xprinter brand is able to get detected with ulpt(4).

Thanks,
Archimedes

--0000000000009078a205d9d16850
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 10, 2022 at 4:14 AM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/9=
/22 18:55, Archimedes Gaviola wrote:

> Hi,

> 

> I have an Epson printer connected to one of the USB ports of my RPi 3B=
. The

> printer is detected as a ugen(4) driver and then I have a text file -<=
br>
> myfile3.txt which contains 10 lines of repeating sentences.

> 

> freebsd@generic:~ % dmesg | grep EPSON

> ugen1.4: <EPSON EPSON UB-U03II> at usbus1

> 

> freebsd@generic:~ % cat myfile3.txt

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> The quick brown fox jumps over the lazy dog.

> 

> freebsd@generic:~ % cat myfile3.txt=C2=A0 > /dev/usb/1.4.1

> 

> I print the file successfully through device file redirection with cat=


> command as described above. However, there were times that printing se=
emed

> to suspend and withhold especially when my RPi 3B system got idle for =
some

> period of time. Suspended or withhold in such a way that out of the 10=


> lines there were only 2-3 lines to be printed in the paper. So, the on=
ly

> remedy I have for now is to reboot the system to be able to get back t=
o

> normal printing. I'm using the 14.0-CURRENT #0 main-n253384-45c23c=
2608e:

> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this beha=
vior

> using this same 14.0-CURRENT version. Any idea what's going on?
> 

> I found these sysctl knobs thinking if some tweaks would help but not =
sure

> what are the exact settings beyond these defaults.

> 

> hw.usb.timings.port_resume_delay: 40

> hw.usb.timings.port_powerup_delay: 300

> hw.usb.timings.port_reset_recovery: 10

> hw.usb.timings.port_root_reset_delay: 200

> hw.usb.timings.port_reset_delay: 50

> 

> (Resend this message without dmesg and sysctl outputs as files are qui=
te

> big, sorry I didn't notice it.)

> 



Hi,



Why are you not using /dev/ulpt<N> ?



/dev/usb/1.4.1 is the raw BULK endpoint.


Hi Hans,

The ulpt(4) driver isn&#=
39;t detected with this Epson printer. Only my other printer which is an Xp=
rinter brand is able to get detected with ulpt(4).

Thanks,
Archimedes=C2=A0 


--0000000000009078a205d9d16850--

From nobody Thu Mar 10 07:47:42 2022
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 8BD7E19FA134
	for ; Thu, 10 Mar 2022 07:47:57 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KDh4X5B4cz4SyC
	for ; Thu, 10 Mar 2022 07:47:56 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6009D26062A;
	Thu, 10 Mar 2022 08:47:54 +0100 (CET)
Message-ID: <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
Date: Thu, 10 Mar 2022 08:47:42 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KDh4X5B4cz4SyC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.974];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.925];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2845
Lines: 80

On 3/10/22 00:24, Archimedes Gaviola wrote:
> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky  wrote:
> 
>> On 3/9/22 18:55, Archimedes Gaviola wrote:
>>> Hi,
>>>
>>> I have an Epson printer connected to one of the USB ports of my RPi 3B.
>> The
>>> printer is detected as a ugen(4) driver and then I have a text file -
>>> myfile3.txt which contains 10 lines of repeating sentences.
>>>
>>> freebsd@generic:~ % dmesg | grep EPSON
>>> ugen1.4:  at usbus1
>>>
>>> freebsd@generic:~ % cat myfile3.txt
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>> The quick brown fox jumps over the lazy dog.
>>>
>>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
>>>
>>> I print the file successfully through device file redirection with cat
>>> command as described above. However, there were times that printing
>> seemed
>>> to suspend and withhold especially when my RPi 3B system got idle for
>> some
>>> period of time. Suspended or withhold in such a way that out of the 10
>>> lines there were only 2-3 lines to be printed in the paper. So, the only
>>> remedy I have for now is to reboot the system to be able to get back to
>>> normal printing. I'm using the 14.0-CURRENT #0 main-n253384-45c23c2608e:
>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
>> behavior
>>> using this same 14.0-CURRENT version. Any idea what's going on?
>>>
>>> I found these sysctl knobs thinking if some tweaks would help but not
>> sure
>>> what are the exact settings beyond these defaults.
>>>
>>> hw.usb.timings.port_resume_delay: 40
>>> hw.usb.timings.port_powerup_delay: 300
>>> hw.usb.timings.port_reset_recovery: 10
>>> hw.usb.timings.port_root_reset_delay: 200
>>> hw.usb.timings.port_reset_delay: 50
>>>
>>> (Resend this message without dmesg and sysctl outputs as files are quite
>>> big, sorry I didn't notice it.)
>>>
>>
>> Hi,
>>
>> Why are you not using /dev/ulpt ?
>>
>> /dev/usb/1.4.1 is the raw BULK endpoint.
>>
> 
> 
> Hi Hans,
> 
> The ulpt(4) driver isn't detected with this Epson printer. Only my other
> printer which is an Xprinter brand is able to get detected with ulpt(4).
> 

Hi,

Is it correctly detected if you the VID and PID to 
/usr/src/sys/dev/usb/serial/ulpt.c ?

When you use the printer via the BULK endpoint, there might be a missing 
flush packet, to flush all the printed text. This happens when the 
payload length is a multiple of the wMaxPacketSize.

--HPS


From nobody Thu Mar 10 12:37:08 2022
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 F1DD41A09D23
	for ; Thu, 10 Mar 2022 12:37:21 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4KDpVT1X7hz54Dl
	for ; Thu, 10 Mar 2022 12:37:21 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x534.google.com with SMTP id c20so6750162edr.8
        for ; Thu, 10 Mar 2022 04:37:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=gaHDX++Y3m9I6tNVSpculdjPqZWT2vtYoIGcUKxo42w=;
        b=j3wi7qzQL3wgTjNHgZMo0kCN8OslKJdEfCy+eY9iaC9bQ4V+rj7Y259ZolyjgvNcv4
         0w/Z6IZ1nARxMIfg8CH7vKFzsCy1Y5ljNAtRTWVfku81aIFHidSNOYDBTFfKMH+94uB+
         F2lJZkTWPWy4ctr4/jbcsk0GD1SsxJ2KhejwWGM99HMfdM0cmt6aobVGUa3yXPLyue1f
         yPtqTiOa+u+LdKw+86U0oD+k86Iz1/XG6T5EPCa6Z4r1SDB33Tajk5d8/X/tYqzWwalA
         MQhMYQbR+mM3c5Nhnzi6+4cpO6mD3fh/pb+fqM1qSBj5Lxa72Wij5TGOjAuzfLuvB2Y5
         oncA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=gaHDX++Y3m9I6tNVSpculdjPqZWT2vtYoIGcUKxo42w=;
        b=h8vlYR8AKmi+hbIOZVzM5sRpkW8gAoTnVD1Qrwcrg6W7z1ELihhkusWNsCxU2HA7QK
         2YAdnaWNVLEwsOQGx4d4DWMf4N0WSs4TYxdS941Srjg/dRfqmc/1oNB4HnhAv4IYqmv4
         1JSm2qUmX5H6pxDb0402WC54LmSYEcvVK2TybMJzHwKKRyLCVv25TIgLi1QAk2dzBbIo
         1MuMk7N/vyu3P22mBVNTWI/0SiJJ4YAInZ9otNKkQfTPHyyKs5nCzu0lz5bl1JdR1fPI
         Au/2P5rSV3pTSSIDpqlS0OYSQ0jnYIDtVt7EH9+OA9Uil30ZarYX79pp26TrGk0qR5V6
         nFUQ==
X-Gm-Message-State: AOAM530KAt6vCrBmSN7DzJNYcTqUN4lIY8DJggYAmmC3xAzvp4VIPKGP
	f2SYdf9KttB5uJ8fEAYp8LMiWwQ63LPPKQ4Cbi0zW9yz1bXT+A==
X-Google-Smtp-Source: ABdhPJx5t4E0MpEAwJZDRIsjSrsDYxt9Py3El3Gu7RQHSIEKJ5OKi80qMXwxvHXWJD2x49ilFIRS50utVoq6wuzo5hQ=
X-Received: by 2002:a05:6402:35cb:b0:416:465b:7aa2 with SMTP id
 z11-20020a05640235cb00b00416465b7aa2mr4015178edc.343.1646915840020; Thu, 10
 Mar 2022 04:37:20 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
In-Reply-To: <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
From: Archimedes Gaviola 
Date: Thu, 10 Mar 2022 20:37:08 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000009e946405d9dc79a7"
X-Rspamd-Queue-Id: 4KDpVT1X7hz54Dl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=j3wi7qzQ;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.992];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 33011
Lines: 703

--0000000000009e946405d9dc79a7
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky  wrote:

> On 3/10/22 00:24, Archimedes Gaviola wrote:
> > On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky 
> wrote:
> >
> >> On 3/9/22 18:55, Archimedes Gaviola wrote:
> >>> Hi,
> >>>
> >>> I have an Epson printer connected to one of the USB ports of my RPi 3B.
> >> The
> >>> printer is detected as a ugen(4) driver and then I have a text file -
> >>> myfile3.txt which contains 10 lines of repeating sentences.
> >>>
> >>> freebsd@generic:~ % dmesg | grep EPSON
> >>> ugen1.4:  at usbus1
> >>>
> >>> freebsd@generic:~ % cat myfile3.txt
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>> The quick brown fox jumps over the lazy dog.
> >>>
> >>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
> >>>
> >>> I print the file successfully through device file redirection with cat
> >>> command as described above. However, there were times that printing
> >> seemed
> >>> to suspend and withhold especially when my RPi 3B system got idle for
> >> some
> >>> period of time. Suspended or withhold in such a way that out of the 10
> >>> lines there were only 2-3 lines to be printed in the paper. So, the
> only
> >>> remedy I have for now is to reboot the system to be able to get back to
> >>> normal printing. I'm using the 14.0-CURRENT #0
> main-n253384-45c23c2608e:
> >>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
> >> behavior
> >>> using this same 14.0-CURRENT version. Any idea what's going on?
> >>>
> >>> I found these sysctl knobs thinking if some tweaks would help but not
> >> sure
> >>> what are the exact settings beyond these defaults.
> >>>
> >>> hw.usb.timings.port_resume_delay: 40
> >>> hw.usb.timings.port_powerup_delay: 300
> >>> hw.usb.timings.port_reset_recovery: 10
> >>> hw.usb.timings.port_root_reset_delay: 200
> >>> hw.usb.timings.port_reset_delay: 50
> >>>
> >>> (Resend this message without dmesg and sysctl outputs as files are
> quite
> >>> big, sorry I didn't notice it.)
> >>>
> >>
> >> Hi,
> >>
> >> Why are you not using /dev/ulpt ?
> >>
> >> /dev/usb/1.4.1 is the raw BULK endpoint.
> >>
> >
> >
> > Hi Hans,
> >
> > The ulpt(4) driver isn't detected with this Epson printer. Only my other
> > printer which is an Xprinter brand is able to get detected with ulpt(4).
> >
>
> Hi,
>
> Is it correctly detected if you the VID and PID to
> /usr/src/sys/dev/usb/serial/ulpt.c ?
>

Hi Hans,

Not sure how to make the current ugen(4) driver into ulpt(4). Is there a
need to disable ugen(4) and recompile the kernel and let ulpt(4) driver
loaded and enabled? As far as vendor ID and product ID of this Epson
printer are concerned, these are  0x04b8 and  0x0200 respectively. I
checked it with usbconfig below. I checked also
/usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
present but no product ID on these particular model which is TM-U220B.

root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc
ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL (12Mbps)
pwr=ON (10mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDeviceClass = 0x0000  
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x04b8
  idProduct = 0x0202
  bcdDevice = 0x0200
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0003  <20160118193053218M03C>
  bNumConfigurations = 0x0001


>
> When you use the printer via the BULK endpoint, there might be a missing
> flush packet, to flush all the printed text. This happens when the
> payload length is a multiple of the wMaxPacketSize.
>

Okay this is noted but what I found lately in usbdump are the presence of
ioerrors ERR=IOERROR in capturing the ugen1.4.1 device while printing were
the printed outputs are intermittent. This time I'm going to use the word
"intermittent" as I don't have any idea when this occurs. It just behaves
anytime without any warnings or notices to the system not even logs in the
dmesg. On the other hand, normal printing will prompts with ERR=0 with
complete outputs.

root@generic:~ # usbdump -d ugen1.4.1 -v
19:14:11.861532 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:14:12.147498 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:14:23.491555 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:14:23.777222 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:14:32.325817 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:14:32.612222 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:18:46.334624 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:18:46.620474 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:18:53.975846 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:18:54.262223 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:21:38.505907 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:21:38.792224 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:22:06.235833 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:22:06.521723 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:22:16.344551 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:22:16.630472 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:22:31.625887 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:22:31.911723 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:22:40.325843 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:22:40.612223 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:23:53.484761 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:23:53.514428 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,
 frame[0] WRITE 128 bytes
19:23:57.055902 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:23:57.084227 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:00.244450 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:00.274206 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:03.974541 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:04.004203 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:24:06.975851 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:07.004209 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:09.605790 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:09.633980 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:12.385923 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:12.413760 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:15.224542 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:15.253771 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:18.174530 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:18.203756 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:21.125927 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:21.153752 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 136 bytes
19:24:24.275854 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:24.303756 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:24:27.485857 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:27.772223 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:24:36.194633 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:36.223750 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:39.115831 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:39.143771 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:24:41.855851 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:41.883758 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:44.215882 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:44.243755 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:47.634603 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:47.663751 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:50.324493 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:50.353755 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:52.864637 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:52.893756 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:24:54.944528 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:54.973743 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:24:57.254498 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:24:57.537227 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 1264 bytes
19:25:06.024607 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:06.053747 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:08.214550 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:08.243749 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:25:10.355858 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:10.383752 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:12.435851 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:12.463752 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:14.574555 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:14.603740 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:17.814561 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:17.844015 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:19.924529 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:19.954029 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:28.075867 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:28.104036 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes
19:25:30.195823 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:30.224035 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:32.574567 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:32.604028 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:34.624522 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:34.654016 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 128 bytes
19:25:36.895889 usbus1.4
SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
 frame[0] WRITE 1264 bytes
19:25:36.924007 usbus1.4
DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
 frame[0] WRITE 144 bytes

86 packets captured
41546 packets received by filter
0 packets dropped by kernel

What could be these ioerrors? As I am also firm that my Epson printer's
status is good and this only happens in RPi 3B but not RPi 4B. My RPi 4B
using the same printer and ugen(4) driver is very stable.

Thanks,
Archimedes

--0000000000009e946405d9dc79a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 10, 2022 at 3:47 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
0/22 00:24, Archimedes Gaviola wrote:

> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/9/22 18:55, Archimedes Gaviola wrote:

>>> Hi,

>>>

>>> I have an Epson printer connected to one of the USB ports of m=
y RPi 3B.

>> The

>>> printer is detected as a ugen(4) driver and then I have a text=
 file -

>>> myfile3.txt which contains 10 lines of repeating sentences.
>>>

>>> freebsd@generic:~ % dmesg | grep EPSON

>>> ugen1.4: <EPSON EPSON UB-U03II> at usbus1

>>>

>>> freebsd@generic:~ % cat myfile3.txt

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>> The quick brown fox jumps over the lazy dog.

>>>

>>> freebsd@generic:~ % cat myfile3.txt=C2=A0 > /dev/usb/1.4.1<=
br>
>>>

>>> I print the file successfully through device file redirection =
with cat

>>> command as described above. However, there were times that pri=
nting

>> seemed

>>> to suspend and withhold especially when my RPi 3B system got i=
dle for

>> some

>>> period of time. Suspended or withhold in such a way that out o=
f the 10

>>> lines there were only 2-3 lines to be printed in the paper. So=
, the only

>>> remedy I have for now is to reboot the system to be able to ge=
t back to

>>> normal printing. I'm using the 14.0-CURRENT #0 main-n25338=
4-45c23c2608e:

>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest t=
his

>> behavior

>>> using this same 14.0-CURRENT version. Any idea what's goin=
g on?

>>>

>>> I found these sysctl knobs thinking if some tweaks would help =
but not

>> sure

>>> what are the exact settings beyond these defaults.

>>>

>>> hw.usb.timings.port_resume_delay: 40

>>> hw.usb.timings.port_powerup_delay: 300

>>> hw.usb.timings.port_reset_recovery: 10

>>> hw.usb.timings.port_root_reset_delay: 200

>>> hw.usb.timings.port_reset_delay: 50

>>>

>>> (Resend this message without dmesg and sysctl outputs as files=
 are quite

>>> big, sorry I didn't notice it.)

>>>

>>

>> Hi,

>>

>> Why are you not using /dev/ulpt<N> ?

>>

>> /dev/usb/1.4.1 is the raw BULK endpoint.

>>

> 

> 

> Hi Hans,

> 

> The ulpt(4) driver isn't detected with this Epson printer. Only my=
 other

> printer which is an Xprinter brand is able to get detected with ulpt(4=
).

> 



Hi,



Is it correctly detected if you the VID and PID to 

/usr/src/sys/dev/usb/serial/ulpt.c ?

Hi=
 Hans,

Not sure how to make the current ugen(4) dr=
iver into ulpt(4). Is there a need to disable ugen(4) and recompile the ker=
nel and let ulpt(4) driver loaded and enabled? As far as vendor ID and prod=
uct ID of this Epson printer are concerned, these are=C2=A0
0x04b8 and=C2=A0

=20
0x0200 respectively.=20
I checked it with usbconfig below.

I checked also /usr/src/sys/dev/usb/usbdevs file and it seems only the vend=
or ID is present but no product ID on these particular model which is TM-U2=
20B.

root@generic:~ # usbconfig -u 1 -a 4 dump=
_device_desc
ugen1.4: <EPSON EPSON UB-U03II> at usbus1, cfg=3D0 md=
=3DHOST spd=3DFULL (12Mbps) pwr=3DON (10mA)

=C2=A0 bLength =3D 0x001=
2
=C2=A0 bDescriptorType =3D 0x0001
=C2=A0 bcdUSB =3D 0x0110
=C2=
=A0 bDeviceClass =3D 0x0000 =C2=A0<Probed by interface class>
=C2=
=A0 bDeviceSubClass =3D 0x0000
=C2=A0 bDeviceProtocol =3D 0x0000
=C2=
=A0 bMaxPacketSize0 =3D 0x0008
=C2=A0 idVendor =3D 0x04b8
=C2=A0 idPr=
oduct =3D 0x0202
=C2=A0 bcdDevice =3D 0x0200
=C2=A0 iManufacturer =3D=
 0x0001 =C2=A0<EPSON>
=C2=A0 iProduct =3D 0x0002 =C2=A0<EPSON U=
B-U03II>
=C2=A0 iSerialNumber =3D 0x0003 =C2=A0<20160118193053218M=
03C>
=C2=A0 bNumConfigurations =3D 0x0001
=C2=A0



When you use the printer via the BULK endpoint, there might be a missing 
flush packet, to flush all the printed text. This happens when the 

payload length is a multiple of the wMaxPacketSize.
Okay this is noted but what I found lately in usbdump are the prese=
nce of ioerrors=20
ERR=3DIOERROR

in capturing the ugen1.4.1 device while printing were the printed outputs a=
re intermittent. This time I'm going to use the word "intermittent=
" as I don't have any idea when this occurs. It just behaves anyti=
me without any warnings or notices to the system not even logs in the dmesg=
. On the other hand, normal printing will prompts with ERR=3D0 with complet=
e outputs.


root@generic:~ # usbdump -d ugen1.4.1 -v
19=
:14:11.861532 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D12=
64,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:14:12.147498 usbus1.4 =
DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=
=A0frame[0] WRITE 1264 bytes
19:14:23.491555 usbus1.4 SUBM-BULK-EP=3D000=
00001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 =
bytes
19:14:23.777222 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D=
1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:14:32.=
325817 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=
=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:14:32.612222 usbus1.4 DONE-BU=
LK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0fram=
e[0] WRITE 1264 bytes
19:18:46.334624 usbus1.4 SUBM-BULK-EP=3D00000001,S=
PD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes19:18:46.620474 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=
=3D0,IVAL=3D0,ERR=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:18:53.975846=
 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0=C2=A0frame[0] WRITE 1264 bytes
19:18:54.262223 usbus1.4 DONE-BULK-EP=
=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0frame[0] =
WRITE 1264 bytes
19:21:38.505907 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3D=
FULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:=
21:38.792224 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,I=
VAL=3D0,ERR=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:22:06.235833 usbus=
1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=
=A0frame[0] WRITE 1264 bytes
19:22:06.521723 usbus1.4 DONE-BULK-EP=3D000=
00001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0frame[0] WRITE =
1264 bytes
19:22:16.344551 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,N=
FR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:22:16.=
630472 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D=
0,ERR=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:22:31.625887 usbus1.4 SU=
BM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0fram=
e[0] WRITE 1264 bytes
19:22:31.911723 usbus1.4 DONE-BULK-EP=3D00000001,S=
PD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0frame[0] WRITE 1264 by=
tes
19:22:40.325843 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,=
SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:22:40.612223 =
usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=
=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:23:53.484761 usbus1.4 SUBM-BU=
LK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] =
WRITE 1264 bytes
19:23:53.514428 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3D=
FULL,NFR=3D1,SLEN=3D0,IVAL=3D0, 
=C2=A0frame[0] WRITE 128 bytes
19:23=
:57.055902 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,=
IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:23:57.084227 usbus1.4 DON=
E-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=
=C2=A0frame[0] WRITE 128 bytes
19:24:00.244450 usbus1.4 SUBM-BULK-EP=3D0=
0000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 126=
4 bytes
19:24:00.274206 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=
=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
1=
9:24:03.974541 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1=
264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:04.004203 usbus1.4=
 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR=

=C2=A0frame[0] WRITE 144 bytes
19:24:06.975851 usbus1.4 SUBM-BULK-EP=
=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE=
 1264 bytes
19:24:07.004209 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,=
NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes19:24:09.605790 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=
=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:09.633980 usbu=
s1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR
=C2=A0frame[0] WRITE 128 bytes
19:24:12.385923 usbus1.4 SUBM-BUL=
K-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] W=
RITE 1264 bytes
19:24:12.413760 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DF=
ULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 byt=
es
19:24:15.224542 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,S=
LEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:15.253771 u=
sbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D=
IOERROR
=C2=A0frame[0] WRITE 128 bytes
19:24:18.174530 usbus1.4 SUBM-=
BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0=
] WRITE 1264 bytes
19:24:18.203756 usbus1.4 DONE-BULK-EP=3D00000001,SPD=
=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128=
 bytes
19:24:21.125927 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=
=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:21.15=
3752 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,=
ERR=3DIOERROR
=C2=A0frame[0] WRITE 136 bytes
19:24:24.275854 usbus1.4=
 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0f=
rame[0] WRITE 1264 bytes
19:24:24.303756 usbus1.4 DONE-BULK-EP=3D0000000=
1,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRIT=
E 144 bytes
19:24:27.485857 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,=
NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:27=
.772223 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=
=3D0,ERR=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:36.194633 usbus1.4=
 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0f=
rame[0] WRITE 1264 bytes
19:24:36.223750 usbus1.4 DONE-BULK-EP=3D0000000=
1,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRIT=
E 128 bytes
19:24:39.115831 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,=
NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:39=
.143771 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=
=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 144 bytes
19:24:41.855851 usb=
us1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=
=C2=A0frame[0] WRITE 1264 bytes
19:24:41.883758 usbus1.4 DONE-BULK-EP=3D=
00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[=
0] WRITE 128 bytes
19:24:44.215882 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=
=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
=
19:24:44.243755 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D=
0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
19:24:47.6346=
03 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0=

=C2=A0frame[0] WRITE 1264 bytes
19:24:47.663751 usbus1.4 DONE-BULK-E=
P=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0fr=
ame[0] WRITE 128 bytes
19:24:50.324493 usbus1.4 SUBM-BULK-EP=3D00000001,=
SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes<=
br>19:24:50.353755 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=
=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
19:24:52.8=
64637 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=
=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:52.893756 usbus1.4 DONE-BU=
LK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=
=A0frame[0] WRITE 144 bytes
19:24:54.944528 usbus1.4 SUBM-BULK-EP=3D0000=
0001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 b=
ytes
19:24:54.973743 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1=
,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
19:24=
:57.254498 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,=
IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:24:57.537227 usbus1.4 DON=
E-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
=C2=A0=
frame[0] WRITE 1264 bytes
19:25:06.024607 usbus1.4 SUBM-BULK-EP=3D000000=
01,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 byt=
es
19:25:06.053747 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,S=
LEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
19:25:0=
8.214550 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IV=
AL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:08.243749 usbus1.4 DONE-=
BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=
=C2=A0frame[0] WRITE 144 bytes
19:25:10.355858 usbus1.4 SUBM-BULK-EP=3D0=
0000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 126=
4 bytes
19:25:10.383752 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=
=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
1=
9:25:12.435851 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1=
264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:12.463752 usbus1.4=
 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR=

=C2=A0frame[0] WRITE 128 bytes
19:25:14.574555 usbus1.4 SUBM-BULK-EP=
=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE=
 1264 bytes
19:25:14.603740 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,=
NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes19:25:17.814561 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=
=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:17.844015 usbu=
s1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR
=C2=A0frame[0] WRITE 128 bytes
19:25:19.924529 usbus1.4 SUBM-BUL=
K-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] W=
RITE 1264 bytes
19:25:19.954029 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DF=
ULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 byt=
es
19:25:28.075867 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,S=
LEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:28.104036 u=
sbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D=
IOERROR
=C2=A0frame[0] WRITE 144 bytes
19:25:30.195823 usbus1.4 SUBM-=
BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0=
] WRITE 1264 bytes
19:25:30.224035 usbus1.4 DONE-BULK-EP=3D00000001,SPD=
=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 128=
 bytes
19:25:32.574567 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=
=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:32.60=
4028 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,=
ERR=3DIOERROR
=C2=A0frame[0] WRITE 128 bytes
19:25:34.624522 usbus1.4=
 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0f=
rame[0] WRITE 1264 bytes
19:25:34.654016 usbus1.4 DONE-BULK-EP=3D0000000=
1,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRIT=
E 128 bytes
19:25:36.895889 usbus1.4 SUBM-BULK-EP=3D00000001,SPD=3DFULL,=
NFR=3D1,SLEN=3D1264,IVAL=3D0
=C2=A0frame[0] WRITE 1264 bytes
19:25:36=
.924007 usbus1.4 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=
=3D0,ERR=3DIOERROR
=C2=A0frame[0] WRITE 144 bytes

86 packets capt=
ured
41546 packets received by filter
0 packets dropped by kernel


What could be these ioerrors?

As I am also firm that my Epson printer's status is good and this only =
happens in RPi 3B but not RPi 4B. My RPi 4B using the same printer and ugen=
(4) driver is very stable.

Thanks,
Archimedes=C2=
=A0 


--0000000000009e946405d9dc79a7--

From nobody Thu Mar 10 12:52:53 2022
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 EA50C1A0CEC5
	for ; Thu, 10 Mar 2022 12:53:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KDprh6ZL1z55pj
	for ; Thu, 10 Mar 2022 12:53:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 29291260074;
	Thu, 10 Mar 2022 13:53:06 +0100 (CET)
Message-ID: <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
Date: Thu, 10 Mar 2022 13:52:53 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KDprh6ZL1z55pj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 16672
Lines: 434

On 3/10/22 13:37, Archimedes Gaviola wrote:
> On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky  wrote:
> 
>> On 3/10/22 00:24, Archimedes Gaviola wrote:
>>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky 
>> wrote:
>>>
>>>> On 3/9/22 18:55, Archimedes Gaviola wrote:
>>>>> Hi,
>>>>>
>>>>> I have an Epson printer connected to one of the USB ports of my RPi 3B.
>>>> The
>>>>> printer is detected as a ugen(4) driver and then I have a text file -
>>>>> myfile3.txt which contains 10 lines of repeating sentences.
>>>>>
>>>>> freebsd@generic:~ % dmesg | grep EPSON
>>>>> ugen1.4:  at usbus1
>>>>>
>>>>> freebsd@generic:~ % cat myfile3.txt
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>> The quick brown fox jumps over the lazy dog.
>>>>>
>>>>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
>>>>>
>>>>> I print the file successfully through device file redirection with cat
>>>>> command as described above. However, there were times that printing
>>>> seemed
>>>>> to suspend and withhold especially when my RPi 3B system got idle for
>>>> some
>>>>> period of time. Suspended or withhold in such a way that out of the 10
>>>>> lines there were only 2-3 lines to be printed in the paper. So, the
>> only
>>>>> remedy I have for now is to reboot the system to be able to get back to
>>>>> normal printing. I'm using the 14.0-CURRENT #0
>> main-n253384-45c23c2608e:
>>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
>>>> behavior
>>>>> using this same 14.0-CURRENT version. Any idea what's going on?
>>>>>
>>>>> I found these sysctl knobs thinking if some tweaks would help but not
>>>> sure
>>>>> what are the exact settings beyond these defaults.
>>>>>
>>>>> hw.usb.timings.port_resume_delay: 40
>>>>> hw.usb.timings.port_powerup_delay: 300
>>>>> hw.usb.timings.port_reset_recovery: 10
>>>>> hw.usb.timings.port_root_reset_delay: 200
>>>>> hw.usb.timings.port_reset_delay: 50
>>>>>
>>>>> (Resend this message without dmesg and sysctl outputs as files are
>> quite
>>>>> big, sorry I didn't notice it.)
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Why are you not using /dev/ulpt ?
>>>>
>>>> /dev/usb/1.4.1 is the raw BULK endpoint.
>>>>
>>>
>>>
>>> Hi Hans,
>>>
>>> The ulpt(4) driver isn't detected with this Epson printer. Only my other
>>> printer which is an Xprinter brand is able to get detected with ulpt(4).
>>>
>>
>> Hi,
>>
>> Is it correctly detected if you the VID and PID to
>> /usr/src/sys/dev/usb/serial/ulpt.c ?
>>
> 
> Hi Hans,
> 
> Not sure how to make the current ugen(4) driver into ulpt(4). Is there a
> need to disable ugen(4) and recompile the kernel and let ulpt(4) driver
> loaded and enabled? As far as vendor ID and product ID of this Epson
> printer are concerned, these are  0x04b8 and  0x0200 respectively. I
> checked it with usbconfig below. I checked also
> /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
> present but no product ID on these particular model which is TM-U220B.
> 
> root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc
> ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL (12Mbps)
> pwr=ON (10mA)
> 
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0110
>    bDeviceClass = 0x0000  
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0008
>    idVendor = 0x04b8
>    idProduct = 0x0202
>    bcdDevice = 0x0200
>    iManufacturer = 0x0001  
>    iProduct = 0x0002  
>    iSerialNumber = 0x0003  <20160118193053218M03C>
>    bNumConfigurations = 0x0001
> 
> 
>>
>> When you use the printer via the BULK endpoint, there might be a missing
>> flush packet, to flush all the printed text. This happens when the
>> payload length is a multiple of the wMaxPacketSize.
>>
> 
> Okay this is noted but what I found lately in usbdump are the presence of
> ioerrors ERR=IOERROR in capturing the ugen1.4.1 device while printing were
> the printed outputs are intermittent. This time I'm going to use the word
> "intermittent" as I don't have any idea when this occurs. It just behaves
> anytime without any warnings or notices to the system not even logs in the
> dmesg. On the other hand, normal printing will prompts with ERR=0 with
> complete outputs.
> 
> root@generic:~ # usbdump -d ugen1.4.1 -v
> 19:14:11.861532 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:14:12.147498 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:14:23.491555 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:14:23.777222 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:14:32.325817 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:14:32.612222 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:18:46.334624 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:18:46.620474 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:18:53.975846 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:18:54.262223 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:21:38.505907 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:21:38.792224 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:22:06.235833 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:22:06.521723 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:22:16.344551 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:22:16.630472 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:22:31.625887 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:22:31.911723 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:22:40.325843 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:22:40.612223 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:23:53.484761 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:23:53.514428 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,
>   frame[0] WRITE 128 bytes
> 19:23:57.055902 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:23:57.084227 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:00.244450 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:00.274206 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:03.974541 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:04.004203 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:24:06.975851 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:07.004209 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:09.605790 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:09.633980 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:12.385923 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:12.413760 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:15.224542 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:15.253771 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:18.174530 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:18.203756 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:21.125927 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:21.153752 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 136 bytes
> 19:24:24.275854 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:24.303756 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:24:27.485857 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:27.772223 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:24:36.194633 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:36.223750 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:39.115831 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:39.143771 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:24:41.855851 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:41.883758 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:44.215882 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:44.243755 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:47.634603 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:47.663751 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:50.324493 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:50.353755 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:52.864637 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:52.893756 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:24:54.944528 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:54.973743 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:24:57.254498 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:24:57.537227 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>   frame[0] WRITE 1264 bytes
> 19:25:06.024607 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:06.053747 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:08.214550 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:08.243749 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:25:10.355858 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:10.383752 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:12.435851 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:12.463752 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:14.574555 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:14.603740 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:17.814561 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:17.844015 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:19.924529 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:19.954029 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:28.075867 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:28.104036 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 19:25:30.195823 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:30.224035 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:32.574567 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:32.604028 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:34.624522 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:34.654016 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 128 bytes
> 19:25:36.895889 usbus1.4
> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>   frame[0] WRITE 1264 bytes
> 19:25:36.924007 usbus1.4
> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>   frame[0] WRITE 144 bytes
> 
> 86 packets captured
> 41546 packets received by filter
> 0 packets dropped by kernel
> 
> What could be these ioerrors? As I am also firm that my Epson printer's
> status is good and this only happens in RPi 3B but not RPi 4B. My RPi 4B
> using the same printer and ugen(4) driver is very stable.

Hi,

IOERROR usually means an electrical error. The RPI3B will use a 
transaction translator for the FULL speed traffic, which is driven by 
software. Maybe there is a bug in the HC driver, 
"dev/usb/controller/dwc_otg.c". There are some sysctls to enable full HC 
debugging, see hw.usb.xxx.debug=17 .

Is the device self-powered?

Try something like this:

> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c
> index c566da92437..d663800f4fc 100644
> --- a/sys/dev/usb/serial/ulpt.c
> +++ b/sys/dev/usb/serial/ulpt.c
> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] = {
>         {USB_IFACE_CLASS(UICLASS_PRINTER),
>          USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
>          USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> +
> +       /* Epson printer */
> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
>  };
>  
>  static int
> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
> index 01c25d7c096..632b8f19610 100644
> --- a/sys/dev/usb/usbdevs
> +++ b/sys/dev/usb/usbdevs
> @@ -1941,6 +1941,7 @@ product EPSON 1270                0x0120  Perfection 1270 scanner
>  product EPSON 2480             0x0121  Perfection 2480 scanner
>  product EPSON 3590             0x0122  Perfection 3590 scanner
>  product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> +product EPSON TMU220B          0x0200  TM-U220B
>  product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
>  product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
>  product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader

--HPS

From nobody Thu Mar 10 13:09:58 2022
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 E773D1A10675
	for ; Thu, 10 Mar 2022 13:10:12 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 4KDqDM4Rprz5898
	for ; Thu, 10 Mar 2022 13:10:11 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x631.google.com with SMTP id a8so11952735ejc.8
        for ; Thu, 10 Mar 2022 05:10:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=fQ1ww3wn1oUot/CB5savFzEQrnJPYo1if3lrxsYROm4=;
        b=fBPDUEh7NhmT5e1SBVZsEyFqKvZfxLyDakI80Rug8nwqjBlnJls7EEb+nBGd/BitY1
         pkQRIyFSr43C2YZ5pAdwJeS5Qwcg7LB3fsSxW6s+zlxiwNOm9Ir2+gKV4o2VlgpuawvR
         J9fKccPeyzcayCYchDiWXUwS3yNmokAHLFS9DTFj6UIQxvIMGp+j+bODdxmWuO/lGMfV
         K/kUvOaFFko720FaNA4u4zWuHjVJ+toPHGfabsId0ez2975HmkLHVQe9cBu1btwHHK/i
         NN2SMNvo+eTSUQLiJ8e72RfB8Y1oTUm2mh6/mRr1MWDUTfZAhnf2tJQfW5/qXm3N7nmg
         jzDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=fQ1ww3wn1oUot/CB5savFzEQrnJPYo1if3lrxsYROm4=;
        b=vKGMq4A1Z7SjOZf5Ja46Vmyc1WwDaVLLpphnmlxW5ZfhsGJ+A/fi8jA8HmAf9vwNQV
         VrEn1JlbFSn+RKgS897ZIbVApROczmGX1orA7Oda4hb0gEN5zsKH0Av72JZ9AMlO16el
         H2r8//FTZ9ttVa+um9ZuRV4sdcTWQCXnIoSWs3UmMqalR4Xfxdw7VlJuEB9TC29hosDw
         hMHA+4mcnc+rKt5ibKwyUa+X9Zy7l8lpMWNEacI96ifocDeeo+mE15mZFy5kp4tjORNF
         u5flP4mbqOw1/JGPk+B3HelpV2MyE/Pd7qUw7dMTTTL6ePXOKRsRjgobzbbbjN33esTC
         sJyg==
X-Gm-Message-State: AOAM533jWvqosP9wZOX2uSNFFWCCvStf/MpAGxdtouBa96AeJ/TtN1jb
	quG46+KGSvqMUcY9Zouee8MXN++luEz7qqyb3cEam8bLOBc=
X-Google-Smtp-Source: ABdhPJwXZ3WN+6p7eyCE90wSepsZ1ZoxFy8vTtTCEG7ok7Mu+XsVmd+XH6M1lYED7OcHn1NAqnYLm5QzAPS8SoLDwLI=
X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id
 b17-20020a1709063cb100b006ce2a975ademr4131267ejh.728.1646917810345; Thu, 10
 Mar 2022 05:10:10 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
In-Reply-To: <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
From: Archimedes Gaviola 
Date: Thu, 10 Mar 2022 21:09:58 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000000f5d5105d9dcefb3"
X-Rspamd-Queue-Id: 4KDqDM4Rprz5898
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=fBPDUEh7;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.98 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.98)[-0.985];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 42633
Lines: 1016

--0000000000000f5d5105d9dcefb3
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 10, 2022 at 8:53 PM Hans Petter Selasky  wrote:

> On 3/10/22 13:37, Archimedes Gaviola wrote:
> > On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky 
> wrote:
> >
> >> On 3/10/22 00:24, Archimedes Gaviola wrote:
> >>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky 
> >> wrote:
> >>>
> >>>> On 3/9/22 18:55, Archimedes Gaviola wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I have an Epson printer connected to one of the USB ports of my RPi
> 3B.
> >>>> The
> >>>>> printer is detected as a ugen(4) driver and then I have a text file -
> >>>>> myfile3.txt which contains 10 lines of repeating sentences.
> >>>>>
> >>>>> freebsd@generic:~ % dmesg | grep EPSON
> >>>>> ugen1.4:  at usbus1
> >>>>>
> >>>>> freebsd@generic:~ % cat myfile3.txt
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>>
> >>>>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
> >>>>>
> >>>>> I print the file successfully through device file redirection with
> cat
> >>>>> command as described above. However, there were times that printing
> >>>> seemed
> >>>>> to suspend and withhold especially when my RPi 3B system got idle for
> >>>> some
> >>>>> period of time. Suspended or withhold in such a way that out of the
> 10
> >>>>> lines there were only 2-3 lines to be printed in the paper. So, the
> >> only
> >>>>> remedy I have for now is to reboot the system to be able to get back
> to
> >>>>> normal printing. I'm using the 14.0-CURRENT #0
> >> main-n253384-45c23c2608e:
> >>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
> >>>> behavior
> >>>>> using this same 14.0-CURRENT version. Any idea what's going on?
> >>>>>
> >>>>> I found these sysctl knobs thinking if some tweaks would help but not
> >>>> sure
> >>>>> what are the exact settings beyond these defaults.
> >>>>>
> >>>>> hw.usb.timings.port_resume_delay: 40
> >>>>> hw.usb.timings.port_powerup_delay: 300
> >>>>> hw.usb.timings.port_reset_recovery: 10
> >>>>> hw.usb.timings.port_root_reset_delay: 200
> >>>>> hw.usb.timings.port_reset_delay: 50
> >>>>>
> >>>>> (Resend this message without dmesg and sysctl outputs as files are
> >> quite
> >>>>> big, sorry I didn't notice it.)
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Why are you not using /dev/ulpt ?
> >>>>
> >>>> /dev/usb/1.4.1 is the raw BULK endpoint.
> >>>>
> >>>
> >>>
> >>> Hi Hans,
> >>>
> >>> The ulpt(4) driver isn't detected with this Epson printer. Only my
> other
> >>> printer which is an Xprinter brand is able to get detected with
> ulpt(4).
> >>>
> >>
> >> Hi,
> >>
> >> Is it correctly detected if you the VID and PID to
> >> /usr/src/sys/dev/usb/serial/ulpt.c ?
> >>
> >
> > Hi Hans,
> >
> > Not sure how to make the current ugen(4) driver into ulpt(4). Is there a
> > need to disable ugen(4) and recompile the kernel and let ulpt(4) driver
> > loaded and enabled? As far as vendor ID and product ID of this Epson
> > printer are concerned, these are  0x04b8 and  0x0200 respectively. I
> > checked it with usbconfig below. I checked also
> > /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
> > present but no product ID on these particular model which is TM-U220B.
> >
> > root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc
> > ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL
> (12Mbps)
> > pwr=ON (10mA)
> >
> >    bLength = 0x0012
> >    bDescriptorType = 0x0001
> >    bcdUSB = 0x0110
> >    bDeviceClass = 0x0000  
> >    bDeviceSubClass = 0x0000
> >    bDeviceProtocol = 0x0000
> >    bMaxPacketSize0 = 0x0008
> >    idVendor = 0x04b8
> >    idProduct = 0x0202
> >    bcdDevice = 0x0200
> >    iManufacturer = 0x0001  
> >    iProduct = 0x0002  
> >    iSerialNumber = 0x0003  <20160118193053218M03C>
> >    bNumConfigurations = 0x0001
> >
> >
> >>
> >> When you use the printer via the BULK endpoint, there might be a missing
> >> flush packet, to flush all the printed text. This happens when the
> >> payload length is a multiple of the wMaxPacketSize.
> >>
> >
> > Okay this is noted but what I found lately in usbdump are the presence of
> > ioerrors ERR=IOERROR in capturing the ugen1.4.1 device while printing
> were
> > the printed outputs are intermittent. This time I'm going to use the word
> > "intermittent" as I don't have any idea when this occurs. It just behaves
> > anytime without any warnings or notices to the system not even logs in
> the
> > dmesg. On the other hand, normal printing will prompts with ERR=0 with
> > complete outputs.
> >
> > root@generic:~ # usbdump -d ugen1.4.1 -v
> > 19:14:11.861532 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:12.147498 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:23.491555 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:23.777222 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:32.325817 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:32.612222 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:46.334624 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:46.620474 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:53.975846 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:54.262223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:21:38.505907 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:21:38.792224 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:06.235833 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:06.521723 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:16.344551 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:16.630472 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:31.625887 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:31.911723 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:40.325843 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:40.612223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:53.484761 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:53.514428 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,
> >   frame[0] WRITE 128 bytes
> > 19:23:57.055902 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:57.084227 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:00.244450 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:00.274206 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:03.974541 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:04.004203 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:06.975851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:07.004209 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:09.605790 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:09.633980 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:12.385923 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:12.413760 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:15.224542 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:15.253771 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:18.174530 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:18.203756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:21.125927 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:21.153752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 136 bytes
> > 19:24:24.275854 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:24.303756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:27.485857 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:27.772223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:36.194633 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:36.223750 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:39.115831 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:39.143771 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:41.855851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:41.883758 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:44.215882 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:44.243755 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:47.634603 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:47.663751 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:50.324493 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:50.353755 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:52.864637 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:52.893756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:54.944528 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:54.973743 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:57.254498 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:57.537227 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:06.024607 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:06.053747 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:08.214550 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:08.243749 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:25:10.355858 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:10.383752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:12.435851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:12.463752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:14.574555 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:14.603740 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:17.814561 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:17.844015 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:19.924529 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:19.954029 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:28.075867 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:28.104036 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:25:30.195823 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:30.224035 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:32.574567 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:32.604028 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:34.624522 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:34.654016 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:36.895889 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:36.924007 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> >
> > 86 packets captured
> > 41546 packets received by filter
> > 0 packets dropped by kernel
> >
> > What could be these ioerrors? As I am also firm that my Epson printer's
> > status is good and this only happens in RPi 3B but not RPi 4B. My RPi 4B
> > using the same printer and ugen(4) driver is very stable.
>
> Hi,
>
> IOERROR usually means an electrical error. The RPI3B will use a
> transaction translator for the FULL speed traffic, which is driven by
> software. Maybe there is a bug in the HC driver,
> "dev/usb/controller/dwc_otg.c". There are some sysctls to enable full HC
> debugging, see hw.usb.xxx.debug=17 .
>

Hi Hans,

Thanks for your immediate response! I'll also try my spare RPi 3B if it
behaves the same. Noted on this HC driver you've mentioned. I'll explore
the sysctl knobs for debugging.


>
> Is the device self-powered?
>

Yes it's a self-powered device.


>
> Try something like this:
>
> > diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c
> > index c566da92437..d663800f4fc 100644
> > --- a/sys/dev/usb/serial/ulpt.c
> > +++ b/sys/dev/usb/serial/ulpt.c
> > @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] = {
> >         {USB_IFACE_CLASS(UICLASS_PRINTER),
> >          USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
> >          USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> > +
> > +       /* Epson printer */
> > +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
> >  };
> >
> >  static int
> > diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
> > index 01c25d7c096..632b8f19610 100644
> > --- a/sys/dev/usb/usbdevs
> > +++ b/sys/dev/usb/usbdevs
> > @@ -1941,6 +1941,7 @@ product EPSON 1270                0x0120
> Perfection 1270 scanner
> >  product EPSON 2480             0x0121  Perfection 2480 scanner
> >  product EPSON 3590             0x0122  Perfection 3590 scanner
> >  product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> > +product EPSON TMU220B          0x0200  TM-U220B
> >  product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
> >  product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
> >  product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
>

Okay I'll add this patch.

Thanks and best regards,
Archimedes

--0000000000000f5d5105d9dcefb3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 10, 2022 at 8:53 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
0/22 13:37, Archimedes Gaviola wrote:

> On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/10/22 00:24, Archimedes Gaviola wrote:

>>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky <hps@selasky.org>

>> wrote:

>>>

>>>> On 3/9/22 18:55, Archimedes Gaviola wrote:

>>>>> Hi,

>>>>>

>>>>> I have an Epson printer connected to one of the USB po=
rts of my RPi 3B.

>>>> The

>>>>> printer is detected as a ugen(4) driver and then I hav=
e a text file -

>>>>> myfile3.txt which contains 10 lines of repeating sente=
nces.

>>>>>

>>>>> freebsd@generic:~ % dmesg | grep EPSON

>>>>> ugen1.4: <EPSON EPSON UB-U03II> at usbus1

>>>>>

>>>>> freebsd@generic:~ % cat myfile3.txt

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>>

>>>>> freebsd@generic:~ % cat myfile3.txt=C2=A0 > /dev/us=
b/1.4.1

>>>>>

>>>>> I print the file successfully through device file redi=
rection with cat

>>>>> command as described above. However, there were times =
that printing

>>>> seemed

>>>>> to suspend and withhold especially when my RPi 3B syst=
em got idle for

>>>> some

>>>>> period of time. Suspended or withhold in such a way th=
at out of the 10

>>>>> lines there were only 2-3 lines to be printed in the p=
aper. So, the

>> only

>>>>> remedy I have for now is to reboot the system to be ab=
le to get back to

>>>>> normal printing. I'm using the 14.0-CURRENT #0

>> main-n253384-45c23c2608e:

>>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not ma=
nifest this

>>>> behavior

>>>>> using this same 14.0-CURRENT version. Any idea what=
9;s going on?

>>>>>

>>>>> I found these sysctl knobs thinking if some tweaks wou=
ld help but not

>>>> sure

>>>>> what are the exact settings beyond these defaults.

>>>>>

>>>>> hw.usb.timings.port_resume_delay: 40

>>>>> hw.usb.timings.port_powerup_delay: 300

>>>>> hw.usb.timings.port_reset_recovery: 10

>>>>> hw.usb.timings.port_root_reset_delay: 200

>>>>> hw.usb.timings.port_reset_delay: 50

>>>>>

>>>>> (Resend this message without dmesg and sysctl outputs =
as files are

>> quite

>>>>> big, sorry I didn't notice it.)

>>>>>

>>>>

>>>> Hi,

>>>>

>>>> Why are you not using /dev/ulpt<N> ?

>>>>

>>>> /dev/usb/1.4.1 is the raw BULK endpoint.

>>>>

>>>

>>>

>>> Hi Hans,

>>>

>>> The ulpt(4) driver isn't detected with this Epson printer.=
 Only my other

>>> printer which is an Xprinter brand is able to get detected wit=
h ulpt(4).

>>>

>>

>> Hi,

>>

>> Is it correctly detected if you the VID and PID to

>> /usr/src/sys/dev/usb/serial/ulpt.c ?

>>

> 

> Hi Hans,

> 

> Not sure how to make the current ugen(4) driver into ulpt(4). Is there=
 a

> need to disable ugen(4) and recompile the kernel and let ulpt(4) drive=
r

> loaded and enabled? As far as vendor ID and product ID of this Epson
> printer are concerned, these are=C2=A0 0x04b8 and=C2=A0 0x0200 respect=
ively. I

> checked it with usbconfig below. I checked also

> /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
> present but no product ID on these particular model which is TM-U220B.=


> 

> root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc

> ugen1.4: <EPSON EPSON UB-U03II> at usbus1, cfg=3D0 md=3DHOST spd=
=3DFULL (12Mbps)

> pwr=3DON (10mA)

> 

>=C2=A0 =C2=A0 bLength =3D 0x0012

>=C2=A0 =C2=A0 bDescriptorType =3D 0x0001

>=C2=A0 =C2=A0 bcdUSB =3D 0x0110

>=C2=A0 =C2=A0 bDeviceClass =3D 0x0000=C2=A0 <Probed by interface cla=
ss>

>=C2=A0 =C2=A0 bDeviceSubClass =3D 0x0000

>=C2=A0 =C2=A0 bDeviceProtocol =3D 0x0000

>=C2=A0 =C2=A0 bMaxPacketSize0 =3D 0x0008

>=C2=A0 =C2=A0 idVendor =3D 0x04b8

>=C2=A0 =C2=A0 idProduct =3D 0x0202

>=C2=A0 =C2=A0 bcdDevice =3D 0x0200

>=C2=A0 =C2=A0 iManufacturer =3D 0x0001=C2=A0 <EPSON>

>=C2=A0 =C2=A0 iProduct =3D 0x0002=C2=A0 <EPSON UB-U03II>

>=C2=A0 =C2=A0 iSerialNumber =3D 0x0003=C2=A0 <20160118193053218M03C&=
gt;

>=C2=A0 =C2=A0 bNumConfigurations =3D 0x0001

> 

> 

>>

>> When you use the printer via the BULK endpoint, there might be a m=
issing

>> flush packet, to flush all the printed text. This happens when the=


>> payload length is a multiple of the wMaxPacketSize.

>>

> 

> Okay this is noted but what I found lately in usbdump are the presence=
 of

> ioerrors ERR=3DIOERROR in capturing the ugen1.4.1 device while printin=
g were

> the printed outputs are intermittent. This time I'm going to use t=
he word

> "intermittent" as I don't have any idea when this occurs=
. It just behaves

> anytime without any warnings or notices to the system not even logs in=
 the

> dmesg. On the other hand, normal printing will prompts with ERR=3D0 wi=
th

> complete outputs.

> 

> root@generic:~ # usbdump -d ugen1.4.1 -v

> 19:14:11.861532 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:12.147498 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:23.491555 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:23.777222 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:32.325817 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:32.612222 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:46.334624 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:46.620474 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:53.975846 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:54.262223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:21:38.505907 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:21:38.792224 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:06.235833 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:06.521723 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:16.344551 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:16.630472 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:31.625887 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:31.911723 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:40.325843 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:40.612223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:53.484761 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:53.514428 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:23:57.055902 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:57.084227 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:00.244450 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:00.274206 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:03.974541 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:04.004203 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:06.975851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:07.004209 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:09.605790 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:09.633980 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:12.385923 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:12.413760 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:15.224542 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:15.253771 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:18.174530 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:18.203756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:21.125927 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:21.153752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 136 bytes

> 19:24:24.275854 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:24.303756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:27.485857 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:27.772223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:36.194633 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:36.223750 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:39.115831 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:39.143771 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:41.855851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:41.883758 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:44.215882 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:44.243755 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:47.634603 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:47.663751 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:50.324493 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:50.353755 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:52.864637 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:52.893756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:54.944528 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:54.973743 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:57.254498 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:57.537227 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:06.024607 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:06.053747 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:08.214550 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:08.243749 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:25:10.355858 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:10.383752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:12.435851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:12.463752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:14.574555 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:14.603740 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:17.814561 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:17.844015 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:19.924529 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:19.954029 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:28.075867 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:28.104036 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:25:30.195823 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:30.224035 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:32.574567 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:32.604028 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:34.624522 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:34.654016 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:36.895889 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:36.924007 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 

> 86 packets captured

> 41546 packets received by filter

> 0 packets dropped by kernel

> 

> What could be these ioerrors? As I am also firm that my Epson printer&=
#39;s

> status is good and this only happens in RPi 3B but not RPi 4B. My RPi =
4B

> using the same printer and ugen(4) driver is very stable.



Hi,



IOERROR usually means an electrical error. The RPI3B will use a 

transaction translator for the FULL speed traffic, which is driven by 

software. Maybe there is a bug in the HC driver, 

"dev/usb/controller/dwc_otg.c". There are some sysctls to enable =
full HC 

debugging, see hw.usb.xxx.debug=3D17 .

=
Hi Hans,

Thanks for your immediate response! I'=
;ll also try my spare RPi 3B if it behaves the same. Noted on this HC drive=
r you've mentioned. I'll explore the sysctl knobs for debugging.
=C2=A0



Is the device self-powered?

Yes it'=
s a self-powered device.
=C2=A0



Try something like this:



> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c

> index c566da92437..d663800f4fc 100644

> --- a/sys/dev/usb/serial/ulpt.c

> +++ b/sys/dev/usb/serial/ulpt.c

> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] =3D {<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_IFACE_CLASS(UICLASS_PRINTER),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_SUBCLASS(UISUBCLASS_PRINTE=
R),

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1=
284)},

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPS=
ON_TMU220B, 0)},

>=C2=A0 };

>=C2=A0 

>=C2=A0 static int

> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs

> index 01c25d7c096..632b8f19610 100644

> --- a/sys/dev/usb/usbdevs

> +++ b/sys/dev/usb/usbdevs

> @@ -1941,6 +1941,7 @@ product EPSON 1270=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0120=C2=A0 Perfection 1270 scanner

>=C2=A0 product EPSON 2480=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x0121=C2=A0 Perfection 2480 scanner

>=C2=A0 product EPSON 3590=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x0122=C2=A0 Perfection 3590 scanner

>=C2=A0 product EPSON 4990=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x012a=C2=A0 Perfection 4990 Photo scanner

> +product EPSON TMU220B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0200=C2=A0 =
TM-U220B

>=C2=A0 product EPSON CRESSI_EDY=C2=A0 =C2=A0 =C2=A0 =C2=A00x0521=C2=A0 =
Cressi Edy diving computer

>=C2=A0 product EPSON N2ITION3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0522=
=C2=A0 Zeagle N2iTion3 diving computer

>=C2=A0 product EPSON STYLUS_875DC=C2=A0 =C2=A0 =C2=A00x0601=C2=A0 Stylu=
s Photo 875DC Card Reader

Okay I'll add =
this patch.

Thanks and best regards,
Archimedes


--0000000000000f5d5105d9dcefb3--

From nobody Fri Mar 11 05:02:13 2022
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 A0E921A0EC7C
	for ; Fri, 11 Mar 2022 05:02:15 +0000 (UTC)
	(envelope-from pusateri@ncopen.org)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KFDLt5lXBz3GZf
	for ; Fri, 11 Mar 2022 05:02:14 +0000 (UTC)
	(envelope-from pusateri@ncopen.org)
Received: from [107.13.246.59] (mta-107-13-246-59.nc.rr.com [107.13.246.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by oj.bangj.com (Postfix) with ESMTPSA id B0EA01F701
	for ; Fri, 11 Mar 2022 00:02:13 -0500 (EST)
Content-Type: multipart/alternative;
 boundary="------------Kq211d8svQjoqYSJwTD3VU4F"
Message-ID: <31087824-e774-78dc-704c-d0b27a19447f@ncopen.org>
Date: Fri, 11 Mar 2022 00:02:13 -0500
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:91.0) Gecko/20100101
 Thunderbird/91.4.1
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Tom Pusateri 
Subject: Booting MOCHAbin-5g Marvell board from GlobalscaleTech
X-Rspamd-Queue-Id: 4KFDLt5lXBz3GZf
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of pusateri@ncopen.org has no SPF policy when checking 69.77.154.174) smtp.mailfrom=pusateri@ncopen.org
X-Spamd-Result: default: False [-0.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.7.208.0:email,0.10.177.8:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[ncopen.org];
	 DBL_PROHIBIT(0.00)[0.7.208.0:email,0.10.177.8:email];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 NEURAL_SPAM_LONG(0.30)[0.295];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:23118, ipnet:69.77.128.0/19, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[107.13.246.59:received]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 20102
Lines: 557

This is a multi-part message in MIME format.
--------------Kq211d8svQjoqYSJwTD3VU4F
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I loaded the FreeBSD 13.0 (and also tried 14.0-current snapshot) on a 
USB stick and tried to boot it on the new MOCHAbin-5g.

https://globalscaletechnologies.com/product/mochabin/ It paniced booting 
the EFI file. Any ideas what to try next? Marvell>> usb start starting 
USB... USB0: Register 2000120 NbrPorts 2 Starting the controller USB 
XHCI 1.00 USB1: Register 2000120 NbrPorts 2 Starting the controller USB 
XHCI 1.00 scanning bus 0 for devices... 4 USB Device(s) found scanning 
bus 1 for devices... 5 USB Device(s) found scanning usb for storage 
devices... 1 Storage Device(s) found
Marvell>> fatload usb 0 0x6000000 EFI/BOOT/bootaa64.efi
1259212 bytes read in 59 ms (20.4 MiB/s) Marvell>> bootefi 0x6000000
## Starting EFI application at 06000000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disksdhci@6e0000.blk...
Scanning disk usb_mass_storage.lun0...
Found 5 disks
"Synchronous Abort" handler, esr 0x96000046
elr: 0000000000063728 lr : 000000000005b51c (reloc)
elr: 000000007ff9c728 lr : 000000007ff9451c
x0 : 00000000bffff000 x1 : 0000000000000000
x2 : 000000000000001f x3 : 00000000bffff018
x4 : 00000000bffff008 x5 : 0000000000000000
x6 : 0000000000000003 x7 : 00000000bffff020
x8 : 000000007f900000 x9 : 0000000000000008
x10: 0000000000000006 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000003
x14: 0000000000000000 x15: 00000000ffffffff
x16: 0000000000000000 x17: 0000000000000001
x18: 000000007f628dd0 x19: 00000000bffff000
x20: 000000007e624040 x21: 000000007e624040
x22: 0000000006000000 x23: 0000000000000000
x24: 000000007f624bc0 x25: 000000007ffa4000
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007f717870 x29: 000000007f624b60

Resetting CPU ...

resetting ...

BootROM - 2.03
Starting CP-0 IOROM 1.07
Booting from SPI NOR flash 1 (0x32)
Found valid image at boot postion 0x000
lmv_ddr: mv_ddr-devel-18.12.0-g2e20f5d (Dec 30 2021 - 16:08:48)
mv_ddr: scrubbing memory...
mv_ddr: completed successfully
llBL2: Initiating SCP_BL2 transfer to SCP
ll

U-Boot 2018.03-devel-18.12.3-ga49bd540df (Dec 30 2021 - 16:06:18 +0800)

Model: Marvell Armada 7040 Mochabin development board
SoC: Armada7040-B0; AP806-B0; CP115-A0
Clock:  CPU     1400 [MHz]
	DDR     800  [MHz]
	FABRIC  800  [MHz]
	MSS     200  [MHz]
LLC Enabled (Exclusive Mode)
DRAM:  8 GiB
Bus spi@700680 CS0 configured for direct access 00000000f9000000:0x1000000
SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB
EEPROM configuration pattern not detected.
Comphy chip #0:
Comphy-0: SGMII1        3.125 Gbps
Comphy-1: USB3_HOST0
Comphy-2: SATA0
Comphy-3: SATA1
Comphy-4: SFI0          10.3125 Gbps
Comphy-5: PEX2
UTMI PHY 0 initialized to USB Host0
UTMI PHY 1 initialized to USB Host1
SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
PCIE-0: Link up (Gen1-x1, Bus0)
MMC:   sdhci@6e0000: 0
Loading Environment from SPI Flash... OK
Model: Marvell Armada 7040 Mochabin development board
Net:   eth0: mvpp2-0 [PRIME], eth1: mvpp2-1, eth2: mvpp2-2
Hit any key to stop autoboot:  0
Marvell>>
Marvell>> help
?       - alias for 'help'
avs     - Set/Get Adaptive Voltage Scaling (AVS) value

base    - print or set address offset
bdinfo  - print Board Info structure
blkcache- block cache diagnostics and control
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootefi - Boots an EFI payload from memory
bootelf - Boot from an ELF image in memory
booti   - boot arm64 Linux Image image from memory
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
bubt    - Burn a u-boot image to flash
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
dhcp    - boot image via network using DHCP/TFTP protocol
dm      - Driver model low level access
echo    - echo args to console
editenv - edit environment variable
env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls  - list files in a directory (default /)
ext4size- determine a file's size
ext4write- create a file in the root directory
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatsize - determine a file's size
fdt     - flattened device tree utility commands
fstype  - Look up a filesystem type
go      - start application at address 'addr'
gpio    - query and control gpio pins
gzwrite - unzip and write memory to block device
help    - print command description/usage
hw_info - hw_info

i2c     - I2C sub-system
icache  - enable or disable instruction cache
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
ir      - ir	- Reading and changing internal register values.

itest   - return true/false on integer compare
led     - manage LEDs
load    - load binary file from a filesystem
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
lzmadec - lzma uncompress a memory region
map     - Display address decode windows

md      - memory display
mdio    - MDIO utility commands
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
part    - disk partition related commands
pci     - list and access PCI Configuration Space
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
pxe     - commands to get and boot from pxe files
regulator- uclass operations
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
rx_training- rx_training  

save    - save file to a filesystem
saveenv - save environment variables to persistent storage
scsi    - SCSI sub-system
scsiboot- boot from SCSI device
setenv  - set environment variables
setexpr - set environment variable as the result of eval expression
sf      - SPI flash sub-system
showvar - print local hushshell variables
size    - determine a file's size
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility command
switch  - Switch Access commands
sysboot - command to get and boot from syslinux files
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
time    - run commands and summarize execution time
true    - do nothing, successfully
tsen    - tsen - Display the SoC temperature.

unzip   - unzip a memory region
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
Marvell>>

Marvell>> printenv
arch=arm
baudrate=115200
board=mvebu_armada-8k
board_name=mvebu_armada-8k
bootcmd=ev 0; ext4load mmc 0:1 $kernel_addr_r $image_name; ext4load mmc 0:1 $fdt_addr_r $fdt_name; setenv bootargs $console root=PARTUUID=89708921-01 rw rootwait net.ifnames=0 biosdevname=0; booti $kernel_addr_r - $fdt_addr_r
bootdelay=2
console=console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000
cpu=armv8
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
ethact=mvpp2-0
ethaddr=00:51:82:11:22:00
ethprime=eth0
extra_params=pci=pcie_bus_safe
fdt_addr_r=0x6f00000
fdt_high=0xffffffffffffffff
fdt_name=boot/armada-7040-mochabin.dtb
fdtcontroladdr=7f625230
gatewayip=10.4.50.254
get_images=tftpboot $kernel_addr_r $image_name; tftpboot $fdt_addr_r $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramdisk_addr_r 0x8000000; tftpboot $ramdisk_addr_r $ramfs_name; else setenv ramdisk_addr_r -;fi
hostname=marvell
image_name=boot/Image
initrd_addr=0xa00000
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr_r=0x7000000
loadaddr=0x6000000
netdev=eth0
netmask=255.255.255.0
ramdisk_addr_r=0x8000000
ramfs_name=-
root=root=/dev/nfs rw
rootpath=/srv/nfs/
serverip=0.0.0.0
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath,tcp,v3 $extra_params $cpuidle
soc=mvebu
stderr=serial@512000
stdin=serial@512000
stdout=serial@512000
vendor=Marvell

Environment size: 1511/65532 bytes

Marvell>> help bootefi
bootefi - Boots an EFI payload from memory

Usage:
bootefi  [fdt address]
   - boot EFI payload stored at address .
     If specified, the device tree located at  gets
     exposed as EFI configuration table.
bootefi bootmgr [fdt addr]
   - load and boot EFI payload based on BootOrder/BootXXXX variables.

     If specified, the device tree located at  gets
     exposed as EFI configuration table.

Marvell>> help usbboot
usbboot - boot from USB device

Usage:
usbboot loadAddr dev:part

Marvell>> usb storage
   Device 0: Vendor: Monster  Rev: PMAP Prod: MONSTER DIGITAL
             Type: Removable Hard Disk
             Capacity: 59082.0 MB = 57.6 GB (120999936 x 512)


--------------Kq211d8svQjoqYSJwTD3VU4F
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
I loaded the FreeBSD 13.0 (and also tried
        14.0-current snapshot) on a USB stick and tried to boot it on
        the new MOCHAbin-5g.

    
https://globalscaletechnologies.com/product/mochabin/

It paniced booting the EFI file. Any ideas what to try next?

Marvell>> usb start
starting USB...
USB0:   Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
scanning bus 1 for devices... 5 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

Marvell>> fatload usb 0 0x6000000 EFI/BOOT/bootaa64.efi
1259212 bytes read in 59 ms (20.4 MiB/s)

Marvell>> bootefi 0x6000000
## Starting EFI application at 06000000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disk sdhci@6e0000.blk...
Scanning disk usb_mass_storage.lun0...
Found 5 disks
"Synchronous Abort" handler, esr 0x96000046
elr: 0000000000063728 lr : 000000000005b51c (reloc)
elr: 000000007ff9c728 lr : 000000007ff9451c
x0 : 00000000bffff000 x1 : 0000000000000000
x2 : 000000000000001f x3 : 00000000bffff018
x4 : 00000000bffff008 x5 : 0000000000000000
x6 : 0000000000000003 x7 : 00000000bffff020
x8 : 000000007f900000 x9 : 0000000000000008
x10: 0000000000000006 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000003
x14: 0000000000000000 x15: 00000000ffffffff
x16: 0000000000000000 x17: 0000000000000001
x18: 000000007f628dd0 x19: 00000000bffff000
x20: 000000007e624040 x21: 000000007e624040
x22: 0000000006000000 x23: 0000000000000000
x24: 000000007f624bc0 x25: 000000007ffa4000
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007f717870 x29: 000000007f624b60

Resetting CPU ...

resetting ...

BootROM - 2.03
Starting CP-0 IOROM 1.07
Booting from SPI NOR flash 1 (0x32)
Found valid image at boot postion 0x000
lmv_ddr: mv_ddr-devel-18.12.0-g2e20f5d (Dec 30 2021 - 16:08:48)
mv_ddr: scrubbing memory...
mv_ddr: completed successfully
llBL2: Initiating SCP_BL2 transfer to SCP
ll

U-Boot 2018.03-devel-18.12.3-ga49bd540df (Dec 30 2021 - 16:06:18 +0800)

Model: Marvell Armada 7040 Mochabin development board
SoC: Armada7040-B0; AP806-B0; CP115-A0
Clock:  CPU     1400 [MHz]
	DDR     800  [MHz]
	FABRIC  800  [MHz]
	MSS     200  [MHz]
LLC Enabled (Exclusive Mode)
DRAM:  8 GiB
Bus spi@700680 CS0 configured for direct access 00000000f9000000:0x1000000
SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB
EEPROM configuration pattern not detected.
Comphy chip #0:
Comphy-0: SGMII1        3.125 Gbps
Comphy-1: USB3_HOST0   
Comphy-2: SATA0        
Comphy-3: SATA1        
Comphy-4: SFI0          10.3125 Gbps
Comphy-5: PEX2         
UTMI PHY 0 initialized to USB Host0
UTMI PHY 1 initialized to USB Host1
SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link up (Gen1-x1, Bus0)
MMC:   sdhci@6e0000: 0
Loading Environment from SPI Flash... OK
Model: Marvell Armada 7040 Mochabin development board
Net:   eth0: mvpp2-0 [PRIME], eth1: mvpp2-1, eth2: mvpp2-2
Hit any key to stop autoboot:  0 
Marvell>> 
Marvell>> help
?       - alias for 'help'
avs     - Set/Get Adaptive Voltage Scaling (AVS) value

base    - print or set address offset
bdinfo  - print Board Info structure
blkcache- block cache diagnostics and control
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootefi - Boots an EFI payload from memory
bootelf - Boot from an ELF image in memory
booti   - boot arm64 Linux Image image from memory
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
bubt    - Burn a u-boot image to flash
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
dhcp    - boot image via network using DHCP/TFTP protocol
dm      - Driver model low level access
echo    - echo args to console
editenv - edit environment variable
env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls  - list files in a directory (default /)
ext4size- determine a file's size
ext4write- create a file in the root directory
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatsize - determine a file's size
fdt     - flattened device tree utility commands
fstype  - Look up a filesystem type
go      - start application at address 'addr'
gpio    - query and control gpio pins
gzwrite - unzip and write memory to block device
help    - print command description/usage
hw_info - hw_info

i2c     - I2C sub-system
icache  - enable or disable instruction cache
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
ir      - ir	- Reading and changing internal register values.

itest   - return true/false on integer compare
led     - manage LEDs
load    - load binary file from a filesystem
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
lzmadec - lzma uncompress a memory region
map     - Display address decode windows

md      - memory display
mdio    - MDIO utility commands
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
part    - disk partition related commands
pci     - list and access PCI Configuration Space
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
pxe     - commands to get and boot from pxe files
regulator- uclass operations
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
rx_training- rx_training <cp id> <comphy id>

save    - save file to a filesystem
saveenv - save environment variables to persistent storage
scsi    - SCSI sub-system
scsiboot- boot from SCSI device
setenv  - set environment variables
setexpr - set environment variable as the result of eval expression
sf      - SPI flash sub-system
showvar - print local hushshell variables
size    - determine a file's size
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility command
switch  - Switch Access commands
sysboot - command to get and boot from syslinux files
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
time    - run commands and summarize execution time
true    - do nothing, successfully
tsen    - tsen - Display the SoC temperature.

unzip   - unzip a memory region
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
Marvell>>

Marvell>> printenv
arch=arm
baudrate=115200
board=mvebu_armada-8k
board_name=mvebu_armada-8k
bootcmd=ev 0; ext4load mmc 0:1 $kernel_addr_r $image_name; ext4load mmc 0:1 $fdt_addr_r $fdt_name; setenv bootargs $console root=PARTUUID=89708921-01 rw rootwait net.ifnames=0 biosdevname=0; booti $kernel_addr_r - $fdt_addr_r
bootdelay=2
console=console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000
cpu=armv8
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
ethact=mvpp2-0
ethaddr=00:51:82:11:22:00
ethprime=eth0
extra_params=pci=pcie_bus_safe
fdt_addr_r=0x6f00000
fdt_high=0xffffffffffffffff
fdt_name=boot/armada-7040-mochabin.dtb
fdtcontroladdr=7f625230
gatewayip=10.4.50.254
get_images=tftpboot $kernel_addr_r $image_name; tftpboot $fdt_addr_r $fdt_name; run get_ramfs
get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramdisk_addr_r 0x8000000; tftpboot $ramdisk_addr_r $ramfs_name; else setenv ramdisk_addr_r -;fi
hostname=marvell
image_name=boot/Image
initrd_addr=0xa00000
initrd_size=0x2000000
ipaddr=0.0.0.0
kernel_addr_r=0x7000000
loadaddr=0x6000000
netdev=eth0
netmask=255.255.255.0
ramdisk_addr_r=0x8000000
ramfs_name=-
root=root=/dev/nfs rw
rootpath=/srv/nfs/
serverip=0.0.0.0
set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath,tcp,v3 $extra_params $cpuidle
soc=mvebu
stderr=serial@512000
stdin=serial@512000
stdout=serial@512000
vendor=Marvell

Environment size: 1511/65532 bytes

Marvell>> help bootefi
bootefi - Boots an EFI payload from memory

Usage:
bootefi <image address> [fdt address]
  - boot EFI payload stored at address <image address>.
    If specified, the device tree located at <fdt address> gets
    exposed as EFI configuration table.
bootefi bootmgr [fdt addr]
  - load and boot EFI payload based on BootOrder/BootXXXX variables.

    If specified, the device tree located at <fdt address> gets
    exposed as EFI configuration table.

Marvell>> help usbboot
usbboot - boot from USB device

Usage:
usbboot loadAddr dev:part

Marvell>> usb storage
  Device 0: Vendor: Monster  Rev: PMAP Prod: MONSTER DIGITAL 
            Type: Removable Hard Disk
            Capacity: 59082.0 MB = 57.6 GB (120999936 x 512)




  


--------------Kq211d8svQjoqYSJwTD3VU4F--

From nobody Fri Mar 11 15:36:43 2022
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 E95EB1A0D17B
	for ; Fri, 11 Mar 2022 15:37:02 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4KFVRK69H5z3w3c
	for ; Fri, 11 Mar 2022 15:37:01 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id qx21so19837299ejb.13
        for ; Fri, 11 Mar 2022 07:37:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=0SbrKKc9yE3cCRh9bTIoR6ifNw0cC8Ebxx8snfZ5Myk=;
        b=JofHrLYEHrnn6IDX9r1gGfQ5u0hEEb4Z1Xpuy3C4kD/kG3B7Snh0ZLKCywi1rrpS9o
         1himUuXV/1Ao19Yrp8isxjVgiXmVYXlh4MQdm9KAroK4teAwaTu05VwIw9JprAQCNNUT
         woWdks/0FgOeQ5iMPRlyK4LhynKQksSaV4DG3oELmmII89VYMDmeLTdkayD4csQrU3+6
         V31QmtY9SxkjA5+D37pYwYLb2dKUOU0k6KP2CcIhIUo01MerIL3SqaB1Dkd9TnMCW+5f
         wjFy7SjeEqYBI+9zZPMWeq7IAkMXuWjjIp8lpXr8kxpPwhYa3kbyBzt905OJIQBFV4B7
         c+Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=0SbrKKc9yE3cCRh9bTIoR6ifNw0cC8Ebxx8snfZ5Myk=;
        b=iL4IiCNueem3aWaEpz1t877nqC0z6rpwf3Y6LKZABgXKQ2dGBTxtRAFgofcNM8gpyJ
         0CG7x6PYChN06xtYzceBr94XPJqBDFrJ5Zg81UWfnSUa22uoM4kyowDr6gptB9Sn7eez
         OGOjelrUk1XRM4v7DCuAr+QiYNu4nRR82phzUxf3BjpG555CkOTpz2aJoxQE1OX3G2iE
         CyzdZUy5pZybEFewrsksneQiGFUButgT+zrvObSX+G7djdnmzDFPHF2SG3WVPsyYqZht
         DTqWnLFVHLYkV+5/CWHGapsJCr3SLPw/mMX4G8F6VlSGC5qTNGDrTZ3tRO/KZIkN6j3y
         CwgQ==
X-Gm-Message-State: AOAM532QSiXaRm0C9y5LkFo2ymOcC//Crhq8st/16gdVWUAEi7Sl7V14
	ledPE0tQqxgx/oHrDeYnW1bJgXumVZZTYXlug8V+YIwF/nw=
X-Google-Smtp-Source: ABdhPJywKG0VNThKEDvXy6bT/0G1kFSjYVBQ3DR7oiARbH2ZpbDXOzB0AD0b/M3wcA8+0ms5DAQeLVn9Cx2fwOECHwA=
X-Received: by 2002:a17:906:4fc4:b0:6da:b4c6:fadb with SMTP id
 i4-20020a1709064fc400b006dab4c6fadbmr9621838ejw.282.1647013014706; Fri, 11
 Mar 2022 07:36:54 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
In-Reply-To: <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
From: Archimedes Gaviola 
Date: Fri, 11 Mar 2022 23:36:43 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000aea77205d9f319c4"
X-Rspamd-Queue-Id: 4KFVRK69H5z3w3c
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=JofHrLYE;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.97 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.97)[-0.974];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.992];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 42111
Lines: 1000

--000000000000aea77205d9f319c4
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 10, 2022 at 8:53 PM Hans Petter Selasky  wrote:

> On 3/10/22 13:37, Archimedes Gaviola wrote:
> > On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky 
> wrote:
> >
> >> On 3/10/22 00:24, Archimedes Gaviola wrote:
> >>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky 
> >> wrote:
> >>>
> >>>> On 3/9/22 18:55, Archimedes Gaviola wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I have an Epson printer connected to one of the USB ports of my RPi
> 3B.
> >>>> The
> >>>>> printer is detected as a ugen(4) driver and then I have a text file -
> >>>>> myfile3.txt which contains 10 lines of repeating sentences.
> >>>>>
> >>>>> freebsd@generic:~ % dmesg | grep EPSON
> >>>>> ugen1.4:  at usbus1
> >>>>>
> >>>>> freebsd@generic:~ % cat myfile3.txt
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>> The quick brown fox jumps over the lazy dog.
> >>>>>
> >>>>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
> >>>>>
> >>>>> I print the file successfully through device file redirection with
> cat
> >>>>> command as described above. However, there were times that printing
> >>>> seemed
> >>>>> to suspend and withhold especially when my RPi 3B system got idle for
> >>>> some
> >>>>> period of time. Suspended or withhold in such a way that out of the
> 10
> >>>>> lines there were only 2-3 lines to be printed in the paper. So, the
> >> only
> >>>>> remedy I have for now is to reboot the system to be able to get back
> to
> >>>>> normal printing. I'm using the 14.0-CURRENT #0
> >> main-n253384-45c23c2608e:
> >>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
> >>>> behavior
> >>>>> using this same 14.0-CURRENT version. Any idea what's going on?
> >>>>>
> >>>>> I found these sysctl knobs thinking if some tweaks would help but not
> >>>> sure
> >>>>> what are the exact settings beyond these defaults.
> >>>>>
> >>>>> hw.usb.timings.port_resume_delay: 40
> >>>>> hw.usb.timings.port_powerup_delay: 300
> >>>>> hw.usb.timings.port_reset_recovery: 10
> >>>>> hw.usb.timings.port_root_reset_delay: 200
> >>>>> hw.usb.timings.port_reset_delay: 50
> >>>>>
> >>>>> (Resend this message without dmesg and sysctl outputs as files are
> >> quite
> >>>>> big, sorry I didn't notice it.)
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Why are you not using /dev/ulpt ?
> >>>>
> >>>> /dev/usb/1.4.1 is the raw BULK endpoint.
> >>>>
> >>>
> >>>
> >>> Hi Hans,
> >>>
> >>> The ulpt(4) driver isn't detected with this Epson printer. Only my
> other
> >>> printer which is an Xprinter brand is able to get detected with
> ulpt(4).
> >>>
> >>
> >> Hi,
> >>
> >> Is it correctly detected if you the VID and PID to
> >> /usr/src/sys/dev/usb/serial/ulpt.c ?
> >>
> >
> > Hi Hans,
> >
> > Not sure how to make the current ugen(4) driver into ulpt(4). Is there a
> > need to disable ugen(4) and recompile the kernel and let ulpt(4) driver
> > loaded and enabled? As far as vendor ID and product ID of this Epson
> > printer are concerned, these are  0x04b8 and  0x0200 respectively. I
> > checked it with usbconfig below. I checked also
> > /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
> > present but no product ID on these particular model which is TM-U220B.
> >
> > root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc
> > ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL
> (12Mbps)
> > pwr=ON (10mA)
> >
> >    bLength = 0x0012
> >    bDescriptorType = 0x0001
> >    bcdUSB = 0x0110
> >    bDeviceClass = 0x0000  
> >    bDeviceSubClass = 0x0000
> >    bDeviceProtocol = 0x0000
> >    bMaxPacketSize0 = 0x0008
> >    idVendor = 0x04b8
> >    idProduct = 0x0202
> >    bcdDevice = 0x0200
> >    iManufacturer = 0x0001  
> >    iProduct = 0x0002  
> >    iSerialNumber = 0x0003  <20160118193053218M03C>
> >    bNumConfigurations = 0x0001
> >
> >
> >>
> >> When you use the printer via the BULK endpoint, there might be a missing
> >> flush packet, to flush all the printed text. This happens when the
> >> payload length is a multiple of the wMaxPacketSize.
> >>
> >
> > Okay this is noted but what I found lately in usbdump are the presence of
> > ioerrors ERR=IOERROR in capturing the ugen1.4.1 device while printing
> were
> > the printed outputs are intermittent. This time I'm going to use the word
> > "intermittent" as I don't have any idea when this occurs. It just behaves
> > anytime without any warnings or notices to the system not even logs in
> the
> > dmesg. On the other hand, normal printing will prompts with ERR=0 with
> > complete outputs.
> >
> > root@generic:~ # usbdump -d ugen1.4.1 -v
> > 19:14:11.861532 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:12.147498 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:23.491555 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:23.777222 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:32.325817 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:14:32.612222 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:46.334624 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:46.620474 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:53.975846 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:18:54.262223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:21:38.505907 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:21:38.792224 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:06.235833 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:06.521723 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:16.344551 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:16.630472 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:31.625887 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:31.911723 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:40.325843 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:22:40.612223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:53.484761 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:53.514428 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,
> >   frame[0] WRITE 128 bytes
> > 19:23:57.055902 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:23:57.084227 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:00.244450 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:00.274206 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:03.974541 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:04.004203 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:06.975851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:07.004209 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:09.605790 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:09.633980 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:12.385923 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:12.413760 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:15.224542 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:15.253771 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:18.174530 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:18.203756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:21.125927 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:21.153752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 136 bytes
> > 19:24:24.275854 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:24.303756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:27.485857 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:27.772223 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:36.194633 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:36.223750 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:39.115831 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:39.143771 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:41.855851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:41.883758 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:44.215882 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:44.243755 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:47.634603 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:47.663751 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:50.324493 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:50.353755 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:52.864637 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:52.893756 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:24:54.944528 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:54.973743 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:24:57.254498 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:24:57.537227 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:06.024607 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:06.053747 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:08.214550 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:08.243749 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:25:10.355858 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:10.383752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:12.435851 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:12.463752 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:14.574555 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:14.603740 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:17.814561 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:17.844015 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:19.924529 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:19.954029 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:28.075867 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:28.104036 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> > 19:25:30.195823 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:30.224035 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:32.574567 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:32.604028 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:34.624522 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:34.654016 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 128 bytes
> > 19:25:36.895889 usbus1.4
> > SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
> >   frame[0] WRITE 1264 bytes
> > 19:25:36.924007 usbus1.4
> > DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
> >   frame[0] WRITE 144 bytes
> >
> > 86 packets captured
> > 41546 packets received by filter
> > 0 packets dropped by kernel
> >
> > What could be these ioerrors? As I am also firm that my Epson printer's
> > status is good and this only happens in RPi 3B but not RPi 4B. My RPi 4B
> > using the same printer and ugen(4) driver is very stable.
>
> Hi,
>
> IOERROR usually means an electrical error. The RPI3B will use a
> transaction translator for the FULL speed traffic, which is driven by
> software. Maybe there is a bug in the HC driver,
> "dev/usb/controller/dwc_otg.c". There are some sysctls to enable full HC
> debugging, see hw.usb.xxx.debug=17 .
>
> Is the device self-powered?
>
>
Try something like this:
>
> > diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c
> > index c566da92437..d663800f4fc 100644
> > --- a/sys/dev/usb/serial/ulpt.c
> > +++ b/sys/dev/usb/serial/ulpt.c
> > @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] = {
> >         {USB_IFACE_CLASS(UICLASS_PRINTER),
> >          USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
> >          USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> > +
> > +       /* Epson printer */
> > +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
> >  };
> >
> >  static int
> > diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
> > index 01c25d7c096..632b8f19610 100644
> > --- a/sys/dev/usb/usbdevs
> > +++ b/sys/dev/usb/usbdevs
> > @@ -1941,6 +1941,7 @@ product EPSON 1270                0x0120
> Perfection 1270 scanner
> >  product EPSON 2480             0x0121  Perfection 2480 scanner
> >  product EPSON 3590             0x0122  Perfection 3590 scanner
> >  product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> > +product EPSON TMU220B          0x0200  TM-U220B
> >  product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
> >  product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
> >  product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
>
>
Hi Hans,

The patch above has no effect. My Epson printer is still obtaining the
ugen(4) driver after I apply and recompile the kernel. Anything I've missed?

Thanks,
Archimedes

--000000000000aea77205d9f319c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 10, 2022 at 8:53 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
0/22 13:37, Archimedes Gaviola wrote:

> On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/10/22 00:24, Archimedes Gaviola wrote:

>>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky <hps@selasky.org>

>> wrote:

>>>

>>>> On 3/9/22 18:55, Archimedes Gaviola wrote:

>>>>> Hi,

>>>>>

>>>>> I have an Epson printer connected to one of the USB po=
rts of my RPi 3B.

>>>> The

>>>>> printer is detected as a ugen(4) driver and then I hav=
e a text file -

>>>>> myfile3.txt which contains 10 lines of repeating sente=
nces.

>>>>>

>>>>> freebsd@generic:~ % dmesg | grep EPSON

>>>>> ugen1.4: <EPSON EPSON UB-U03II> at usbus1

>>>>>

>>>>> freebsd@generic:~ % cat myfile3.txt

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>> The quick brown fox jumps over the lazy dog.

>>>>>

>>>>> freebsd@generic:~ % cat myfile3.txt=C2=A0 > /dev/us=
b/1.4.1

>>>>>

>>>>> I print the file successfully through device file redi=
rection with cat

>>>>> command as described above. However, there were times =
that printing

>>>> seemed

>>>>> to suspend and withhold especially when my RPi 3B syst=
em got idle for

>>>> some

>>>>> period of time. Suspended or withhold in such a way th=
at out of the 10

>>>>> lines there were only 2-3 lines to be printed in the p=
aper. So, the

>> only

>>>>> remedy I have for now is to reboot the system to be ab=
le to get back to

>>>>> normal printing. I'm using the 14.0-CURRENT #0

>> main-n253384-45c23c2608e:

>>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not ma=
nifest this

>>>> behavior

>>>>> using this same 14.0-CURRENT version. Any idea what=
9;s going on?

>>>>>

>>>>> I found these sysctl knobs thinking if some tweaks wou=
ld help but not

>>>> sure

>>>>> what are the exact settings beyond these defaults.

>>>>>

>>>>> hw.usb.timings.port_resume_delay: 40

>>>>> hw.usb.timings.port_powerup_delay: 300

>>>>> hw.usb.timings.port_reset_recovery: 10

>>>>> hw.usb.timings.port_root_reset_delay: 200

>>>>> hw.usb.timings.port_reset_delay: 50

>>>>>

>>>>> (Resend this message without dmesg and sysctl outputs =
as files are

>> quite

>>>>> big, sorry I didn't notice it.)

>>>>>

>>>>

>>>> Hi,

>>>>

>>>> Why are you not using /dev/ulpt<N> ?

>>>>

>>>> /dev/usb/1.4.1 is the raw BULK endpoint.

>>>>

>>>

>>>

>>> Hi Hans,

>>>

>>> The ulpt(4) driver isn't detected with this Epson printer.=
 Only my other

>>> printer which is an Xprinter brand is able to get detected wit=
h ulpt(4).

>>>

>>

>> Hi,

>>

>> Is it correctly detected if you the VID and PID to

>> /usr/src/sys/dev/usb/serial/ulpt.c ?

>>

> 

> Hi Hans,

> 

> Not sure how to make the current ugen(4) driver into ulpt(4). Is there=
 a

> need to disable ugen(4) and recompile the kernel and let ulpt(4) drive=
r

> loaded and enabled? As far as vendor ID and product ID of this Epson
> printer are concerned, these are=C2=A0 0x04b8 and=C2=A0 0x0200 respect=
ively. I

> checked it with usbconfig below. I checked also

> /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
> present but no product ID on these particular model which is TM-U220B.=


> 

> root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc

> ugen1.4: <EPSON EPSON UB-U03II> at usbus1, cfg=3D0 md=3DHOST spd=
=3DFULL (12Mbps)

> pwr=3DON (10mA)

> 

>=C2=A0 =C2=A0 bLength =3D 0x0012

>=C2=A0 =C2=A0 bDescriptorType =3D 0x0001

>=C2=A0 =C2=A0 bcdUSB =3D 0x0110

>=C2=A0 =C2=A0 bDeviceClass =3D 0x0000=C2=A0 <Probed by interface cla=
ss>

>=C2=A0 =C2=A0 bDeviceSubClass =3D 0x0000

>=C2=A0 =C2=A0 bDeviceProtocol =3D 0x0000

>=C2=A0 =C2=A0 bMaxPacketSize0 =3D 0x0008

>=C2=A0 =C2=A0 idVendor =3D 0x04b8

>=C2=A0 =C2=A0 idProduct =3D 0x0202

>=C2=A0 =C2=A0 bcdDevice =3D 0x0200

>=C2=A0 =C2=A0 iManufacturer =3D 0x0001=C2=A0 <EPSON>

>=C2=A0 =C2=A0 iProduct =3D 0x0002=C2=A0 <EPSON UB-U03II>

>=C2=A0 =C2=A0 iSerialNumber =3D 0x0003=C2=A0 <20160118193053218M03C&=
gt;

>=C2=A0 =C2=A0 bNumConfigurations =3D 0x0001

> 

> 

>>

>> When you use the printer via the BULK endpoint, there might be a m=
issing

>> flush packet, to flush all the printed text. This happens when the=


>> payload length is a multiple of the wMaxPacketSize.

>>

> 

> Okay this is noted but what I found lately in usbdump are the presence=
 of

> ioerrors ERR=3DIOERROR in capturing the ugen1.4.1 device while printin=
g were

> the printed outputs are intermittent. This time I'm going to use t=
he word

> "intermittent" as I don't have any idea when this occurs=
. It just behaves

> anytime without any warnings or notices to the system not even logs in=
 the

> dmesg. On the other hand, normal printing will prompts with ERR=3D0 wi=
th

> complete outputs.

> 

> root@generic:~ # usbdump -d ugen1.4.1 -v

> 19:14:11.861532 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:12.147498 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:23.491555 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:23.777222 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:32.325817 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:14:32.612222 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:46.334624 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:46.620474 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:53.975846 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:18:54.262223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:21:38.505907 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:21:38.792224 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:06.235833 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:06.521723 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:16.344551 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:16.630472 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:31.625887 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:31.911723 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:40.325843 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:22:40.612223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:53.484761 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:53.514428 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:23:57.055902 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:23:57.084227 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:00.244450 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:00.274206 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:03.974541 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:04.004203 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:06.975851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:07.004209 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:09.605790 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:09.633980 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:12.385923 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:12.413760 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:15.224542 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:15.253771 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:18.174530 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:18.203756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:21.125927 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:21.153752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 136 bytes

> 19:24:24.275854 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:24.303756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:27.485857 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:27.772223 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:36.194633 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:36.223750 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:39.115831 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:39.143771 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:41.855851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:41.883758 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:44.215882 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:44.243755 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:47.634603 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:47.663751 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:50.324493 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:50.353755 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:52.864637 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:52.893756 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:24:54.944528 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:54.973743 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:24:57.254498 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:24:57.537227 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:06.024607 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:06.053747 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:08.214550 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:08.243749 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:25:10.355858 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:10.383752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:12.435851 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:12.463752 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:14.574555 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:14.603740 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:17.814561 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:17.844015 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:19.924529 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:19.954029 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:28.075867 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:28.104036 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 19:25:30.195823 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:30.224035 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:32.574567 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:32.604028 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:34.624522 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:34.654016 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 128 bytes

> 19:25:36.895889 usbus1.4

> SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D1264,IVAL=3D0

>=C2=A0 =C2=A0frame[0] WRITE 1264 bytes

> 19:25:36.924007 usbus1.4

> DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3DIOE=
RROR

>=C2=A0 =C2=A0frame[0] WRITE 144 bytes

> 

> 86 packets captured

> 41546 packets received by filter

> 0 packets dropped by kernel

> 

> What could be these ioerrors? As I am also firm that my Epson printer&=
#39;s

> status is good and this only happens in RPi 3B but not RPi 4B. My RPi =
4B

> using the same printer and ugen(4) driver is very stable.



Hi,



IOERROR usually means an electrical error. The RPI3B will use a 

transaction translator for the FULL speed traffic, which is driven by 

software. Maybe there is a bug in the HC driver, 

"dev/usb/controller/dwc_otg.c". There are some sysctls to enable =
full HC 

debugging, see hw.usb.xxx.debug=3D17 .



Is the device self-powered?
=C2=A0 

Try something like this:



> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c

> index c566da92437..d663800f4fc 100644

> --- a/sys/dev/usb/serial/ulpt.c

> +++ b/sys/dev/usb/serial/ulpt.c

> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] =3D {<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_IFACE_CLASS(UICLASS_PRINTER),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_SUBCLASS(UISUBCLASS_PRINTE=
R),

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1=
284)},

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPS=
ON_TMU220B, 0)},

>=C2=A0 };

>=C2=A0 

>=C2=A0 static int

> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs

> index 01c25d7c096..632b8f19610 100644

> --- a/sys/dev/usb/usbdevs

> +++ b/sys/dev/usb/usbdevs

> @@ -1941,6 +1941,7 @@ product EPSON 1270=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0120=C2=A0 Perfection 1270 scanner

>=C2=A0 product EPSON 2480=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x0121=C2=A0 Perfection 2480 scanner

>=C2=A0 product EPSON 3590=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x0122=C2=A0 Perfection 3590 scanner

>=C2=A0 product EPSON 4990=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A00x012a=C2=A0 Perfection 4990 Photo scanner

> +product EPSON TMU220B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0200=C2=A0 =
TM-U220B

>=C2=A0 product EPSON CRESSI_EDY=C2=A0 =C2=A0 =C2=A0 =C2=A00x0521=C2=A0 =
Cressi Edy diving computer

>=C2=A0 product EPSON N2ITION3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0522=
=C2=A0 Zeagle N2iTion3 diving computer

>=C2=A0 product EPSON STYLUS_875DC=C2=A0 =C2=A0 =C2=A00x0601=C2=A0 Stylu=
s Photo 875DC Card Reader



Hi Hans,

The =
patch above has no effect. My Epson printer is still obtaining the ugen(4) =
driver after I apply and recompile the kernel. Anything I've missed?

Thanks,
Archimedes 


--000000000000aea77205d9f319c4--

From nobody Fri Mar 11 16:20:21 2022
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 E2A0B1A180ED
	for ; Fri, 11 Mar 2022 16:20:34 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KFWPZ27lZz4ZVm
	for ; Fri, 11 Mar 2022 16:20:34 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 20F4F260197;
	Fri, 11 Mar 2022 17:20:33 +0100 (CET)
Message-ID: <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
Date: Fri, 11 Mar 2022 17:20:21 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KFWPZ27lZz4ZVm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.30 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 18096
Lines: 464

On 3/11/22 16:36, Archimedes Gaviola wrote:
> On Thu, Mar 10, 2022 at 8:53 PM Hans Petter Selasky  wrote:
> 
>> On 3/10/22 13:37, Archimedes Gaviola wrote:
>>> On Thu, Mar 10, 2022 at 3:47 PM Hans Petter Selasky 
>> wrote:
>>>
>>>> On 3/10/22 00:24, Archimedes Gaviola wrote:
>>>>> On Thu, Mar 10, 2022 at 4:14 AM Hans Petter Selasky 
>>>> wrote:
>>>>>
>>>>>> On 3/9/22 18:55, Archimedes Gaviola wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have an Epson printer connected to one of the USB ports of my RPi
>> 3B.
>>>>>> The
>>>>>>> printer is detected as a ugen(4) driver and then I have a text file -
>>>>>>> myfile3.txt which contains 10 lines of repeating sentences.
>>>>>>>
>>>>>>> freebsd@generic:~ % dmesg | grep EPSON
>>>>>>> ugen1.4:  at usbus1
>>>>>>>
>>>>>>> freebsd@generic:~ % cat myfile3.txt
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>> The quick brown fox jumps over the lazy dog.
>>>>>>>
>>>>>>> freebsd@generic:~ % cat myfile3.txt  > /dev/usb/1.4.1
>>>>>>>
>>>>>>> I print the file successfully through device file redirection with
>> cat
>>>>>>> command as described above. However, there were times that printing
>>>>>> seemed
>>>>>>> to suspend and withhold especially when my RPi 3B system got idle for
>>>>>> some
>>>>>>> period of time. Suspended or withhold in such a way that out of the
>> 10
>>>>>>> lines there were only 2-3 lines to be printed in the paper. So, the
>>>> only
>>>>>>> remedy I have for now is to reboot the system to be able to get back
>> to
>>>>>>> normal printing. I'm using the 14.0-CURRENT #0
>>>> main-n253384-45c23c2608e:
>>>>>>> Thu Feb 24 09:18:58 UTC 2022 and my RPi 4B does not manifest this
>>>>>> behavior
>>>>>>> using this same 14.0-CURRENT version. Any idea what's going on?
>>>>>>>
>>>>>>> I found these sysctl knobs thinking if some tweaks would help but not
>>>>>> sure
>>>>>>> what are the exact settings beyond these defaults.
>>>>>>>
>>>>>>> hw.usb.timings.port_resume_delay: 40
>>>>>>> hw.usb.timings.port_powerup_delay: 300
>>>>>>> hw.usb.timings.port_reset_recovery: 10
>>>>>>> hw.usb.timings.port_root_reset_delay: 200
>>>>>>> hw.usb.timings.port_reset_delay: 50
>>>>>>>
>>>>>>> (Resend this message without dmesg and sysctl outputs as files are
>>>> quite
>>>>>>> big, sorry I didn't notice it.)
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Why are you not using /dev/ulpt ?
>>>>>>
>>>>>> /dev/usb/1.4.1 is the raw BULK endpoint.
>>>>>>
>>>>>
>>>>>
>>>>> Hi Hans,
>>>>>
>>>>> The ulpt(4) driver isn't detected with this Epson printer. Only my
>> other
>>>>> printer which is an Xprinter brand is able to get detected with
>> ulpt(4).
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Is it correctly detected if you the VID and PID to
>>>> /usr/src/sys/dev/usb/serial/ulpt.c ?
>>>>
>>>
>>> Hi Hans,
>>>
>>> Not sure how to make the current ugen(4) driver into ulpt(4). Is there a
>>> need to disable ugen(4) and recompile the kernel and let ulpt(4) driver
>>> loaded and enabled? As far as vendor ID and product ID of this Epson
>>> printer are concerned, these are  0x04b8 and  0x0200 respectively. I
>>> checked it with usbconfig below. I checked also
>>> /usr/src/sys/dev/usb/usbdevs file and it seems only the vendor ID is
>>> present but no product ID on these particular model which is TM-U220B.
>>>
>>> root@generic:~ # usbconfig -u 1 -a 4 dump_device_desc
>>> ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL
>> (12Mbps)
>>> pwr=ON (10mA)
>>>
>>>     bLength = 0x0012
>>>     bDescriptorType = 0x0001
>>>     bcdUSB = 0x0110
>>>     bDeviceClass = 0x0000  
>>>     bDeviceSubClass = 0x0000
>>>     bDeviceProtocol = 0x0000
>>>     bMaxPacketSize0 = 0x0008
>>>     idVendor = 0x04b8
>>>     idProduct = 0x0202
>>>     bcdDevice = 0x0200
>>>     iManufacturer = 0x0001  
>>>     iProduct = 0x0002  
>>>     iSerialNumber = 0x0003  <20160118193053218M03C>
>>>     bNumConfigurations = 0x0001
>>>
>>>
>>>>
>>>> When you use the printer via the BULK endpoint, there might be a missing
>>>> flush packet, to flush all the printed text. This happens when the
>>>> payload length is a multiple of the wMaxPacketSize.
>>>>
>>>
>>> Okay this is noted but what I found lately in usbdump are the presence of
>>> ioerrors ERR=IOERROR in capturing the ugen1.4.1 device while printing
>> were
>>> the printed outputs are intermittent. This time I'm going to use the word
>>> "intermittent" as I don't have any idea when this occurs. It just behaves
>>> anytime without any warnings or notices to the system not even logs in
>> the
>>> dmesg. On the other hand, normal printing will prompts with ERR=0 with
>>> complete outputs.
>>>
>>> root@generic:~ # usbdump -d ugen1.4.1 -v
>>> 19:14:11.861532 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:14:12.147498 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:14:23.491555 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:14:23.777222 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:14:32.325817 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:14:32.612222 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:18:46.334624 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:18:46.620474 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:18:53.975846 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:18:54.262223 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:21:38.505907 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:21:38.792224 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:06.235833 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:06.521723 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:16.344551 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:16.630472 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:31.625887 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:31.911723 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:40.325843 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:22:40.612223 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:23:53.484761 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:23:53.514428 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,
>>>    frame[0] WRITE 128 bytes
>>> 19:23:57.055902 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:23:57.084227 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:00.244450 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:00.274206 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:03.974541 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:04.004203 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:24:06.975851 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:07.004209 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:09.605790 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:09.633980 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:12.385923 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:12.413760 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:15.224542 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:15.253771 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:18.174530 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:18.203756 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:21.125927 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:21.153752 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 136 bytes
>>> 19:24:24.275854 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:24.303756 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:24:27.485857 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:27.772223 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:36.194633 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:36.223750 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:39.115831 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:39.143771 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:24:41.855851 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:41.883758 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:44.215882 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:44.243755 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:47.634603 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:47.663751 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:50.324493 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:50.353755 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:52.864637 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:52.893756 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:24:54.944528 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:54.973743 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:24:57.254498 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:24:57.537227 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:06.024607 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:06.053747 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:08.214550 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:08.243749 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:25:10.355858 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:10.383752 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:12.435851 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:12.463752 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:14.574555 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:14.603740 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:17.814561 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:17.844015 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:19.924529 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:19.954029 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:28.075867 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:28.104036 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>> 19:25:30.195823 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:30.224035 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:32.574567 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:32.604028 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:34.624522 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:34.654016 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 128 bytes
>>> 19:25:36.895889 usbus1.4
>>> SUBM-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=1264,IVAL=0
>>>    frame[0] WRITE 1264 bytes
>>> 19:25:36.924007 usbus1.4
>>> DONE-BULK-EP=00000001,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=IOERROR
>>>    frame[0] WRITE 144 bytes
>>>
>>> 86 packets captured
>>> 41546 packets received by filter
>>> 0 packets dropped by kernel
>>>
>>> What could be these ioerrors? As I am also firm that my Epson printer's
>>> status is good and this only happens in RPi 3B but not RPi 4B. My RPi 4B
>>> using the same printer and ugen(4) driver is very stable.
>>
>> Hi,
>>
>> IOERROR usually means an electrical error. The RPI3B will use a
>> transaction translator for the FULL speed traffic, which is driven by
>> software. Maybe there is a bug in the HC driver,
>> "dev/usb/controller/dwc_otg.c". There are some sysctls to enable full HC
>> debugging, see hw.usb.xxx.debug=17 .
>>
>> Is the device self-powered?
>>
>>
> Try something like this:
>>
>>> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c
>>> index c566da92437..d663800f4fc 100644
>>> --- a/sys/dev/usb/serial/ulpt.c
>>> +++ b/sys/dev/usb/serial/ulpt.c
>>> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] = {
>>>          {USB_IFACE_CLASS(UICLASS_PRINTER),
>>>           USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
>>>           USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
>>> +
>>> +       /* Epson printer */
>>> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
>>>   };
>>>
>>>   static int
>>> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
>>> index 01c25d7c096..632b8f19610 100644
>>> --- a/sys/dev/usb/usbdevs
>>> +++ b/sys/dev/usb/usbdevs
>>> @@ -1941,6 +1941,7 @@ product EPSON 1270                0x0120
>> Perfection 1270 scanner
>>>   product EPSON 2480             0x0121  Perfection 2480 scanner
>>>   product EPSON 3590             0x0122  Perfection 3590 scanner
>>>   product EPSON 4990             0x012a  Perfection 4990 Photo scanner
>>> +product EPSON TMU220B          0x0200  TM-U220B
                                     ^^^ 0x0202 (should be this value)
>>>   product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
>>>   product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
>>>   product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
>>
>>
> Hi Hans,
> 
> The patch above has no effect. My Epson printer is still obtaining the
> ugen(4) driver after I apply and recompile the kernel. Anything I've missed?
> 
> Thanks,
> Archimedes
> 

Hi,

See comment above!

--HPS

From nobody Sat Mar 12 07:07:22 2022
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 6773D1A10B1D
	for ; Sat, 12 Mar 2022 07:07:35 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(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 4KFv523sdKz3vnH
	for ; Sat, 12 Mar 2022 07:07:34 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52a.google.com with SMTP id b15so9316698edn.4
        for ; Fri, 11 Mar 2022 23:07:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=YSYHY6wxmwrs5bTHtSBMw+cCpfcikIh3kDPSA7hYdXY=;
        b=qTzQTFCvE8bldLP3tZuX8F36XbKcJgKeSQmKMUYS5XYFLXFKdSh2uD/BHitqNcs7oH
         7J/05jd7R/unCqbtpX9KvRI9t4N1K/DfAYjuC39nb6LLW2n3v2AQ/w+60gSoHKZ7PJg0
         xv2/yFIbMkxWW8i/iGI4IhsyOz+VWeQ7uEweTpWVYBRakIA83kusERdHZVK3mOAziTsl
         Xk6fvYdkjrkXMC8NgY4ACSwC/8IT6BVWsufyv/lNgo5x7fd+SxRizV0mV8E3Th4CD6Wm
         U3Sq9hzyZGf4SWozFgaLpNBeTfTqlnFeCOp3eUaRKsbyWmXIqiIB/Nh1H2W1Lmo/vm6c
         KoPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=YSYHY6wxmwrs5bTHtSBMw+cCpfcikIh3kDPSA7hYdXY=;
        b=HV5m5f/kdsee7US9qTGMhZoGK/WjlRsZTntDDkyWFQSJYLpdBh/MhTOFvV3H2lsr0Z
         ldzFMwhWVqbMGp1w8k8v9fr06bvtTYDr0HUxNs+ORDiUkIH9gC/idZ/QLSc1apu10tl8
         9i1mFAynhJSooVXhbordvJM5ze9wd64uXXlKZLRtPT9/ndR5v3m9jMiBUVmVxGdN3d3i
         3uVctQ85g5wmzTaYzxJb60igmmcvbof110YzDKE6oygzPDsABrX+cfHSOlXc+63SZt06
         ialwJLT06k48etPQKOyBY+GDyLAoCApxMAxqAJP/WGWZPfS2JNr6875gNBHNl/jihPp2
         W4lg==
X-Gm-Message-State: AOAM532lA0YacB+l4dQQ7WoKruOMx8GHAGPGZMmtYqZTggOXZDbky47d
	2nUeTLHOFtkyvTEIeTd1G71N4/ceg98a48Qi+2o=
X-Google-Smtp-Source: ABdhPJwxf5Y9COT04jVpP6Ks5IYTUIuhhJux8e4X7szos0mKGU+uQPJ/R0QymkOftbxaX1OZ3Rn2kewb2XYFbHT2n8M=
X-Received: by 2002:a50:cf48:0:b0:415:df40:9e3d with SMTP id
 d8-20020a50cf48000000b00415df409e3dmr11889107edk.185.1647068853076; Fri, 11
 Mar 2022 23:07:33 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
In-Reply-To: <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
From: Archimedes Gaviola 
Date: Sat, 12 Mar 2022 15:07:22 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e8892405da0019ab"
X-Rspamd-Queue-Id: 4KFv523sdKz3vnH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qTzQTFCv;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.989];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8247
Lines: 193

--000000000000e8892405da0019ab
Content-Type: text/plain; charset="UTF-8"

    >> Try something like this:

> >>
> >>> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ulpt.c
> >>> index c566da92437..d663800f4fc 100644
> >>> --- a/sys/dev/usb/serial/ulpt.c
> >>> +++ b/sys/dev/usb/serial/ulpt.c
> >>> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[] = {
> >>>          {USB_IFACE_CLASS(UICLASS_PRINTER),
> >>>           USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
> >>>           USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> >>> +
> >>> +       /* Epson printer */
> >>> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
> >>>   };
> >>>
> >>>   static int
> >>> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
> >>> index 01c25d7c096..632b8f19610 100644
> >>> --- a/sys/dev/usb/usbdevs
> >>> +++ b/sys/dev/usb/usbdevs
> >>> @@ -1941,6 +1941,7 @@ product EPSON 1270                0x0120
> >> Perfection 1270 scanner
> >>>   product EPSON 2480             0x0121  Perfection 2480 scanner
> >>>   product EPSON 3590             0x0122  Perfection 3590 scanner
> >>>   product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> >>> +product EPSON TMU220B          0x0200  TM-U220B
>                                      ^^^ 0x0202 (should be this value)
> >>>   product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
> >>>   product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving
> computer
> >>>   product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
> >>
> >>
> > Hi Hans,
> >
> > The patch above has no effect. My Epson printer is still obtaining the
> > ugen(4) driver after I apply and recompile the kernel. Anything I've
> missed?
> >
> > Thanks,
> > Archimedes
> >
>
> Hi,
>
> See comment above!
>


Thanks Hans for the correction! My Epson printer is now detected with the
ulpt(4) driver. However, it's throwing a message code no. 12 and there is
no character device file of ulpt1 created in the /dev directory thus I
could not print.

root@generic:~ # dmesg
...
ugen1.5:  at usbus1
ulpt1 on uhub1
ulpt1:  on usbus1
device_attach: ulpt1 attach returned 12

root@generic:~ # ls -la /dev/ulpt1
ls: /dev/ulpt1: No such file or directory

I double checked my Xprinter printer and compared the behavior.

root@generic:~ # dmesg
...
ugen1.4:  at usbus1
ulpt0 on uhub1
ulpt0: 
on usbus1
ulpt0: using bi-directional mode
ulpt0: offline

root@generic:~ # ls -la /dev/ulpt0
crw-r--r--  1 root  operator  0x7c Apr 10 03:44 /dev/ulpt0

What is this message code no. 12 showing-up in the device_attach() ->
device_attach: ulpt1 attach returned 12? I'm currently looking at this
message code trying to figure-out what's going on.

Thanks,
Archimedes

--000000000000e8892405da0019ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=C2=A0=C2=A0=C2=A0 >> Try something like this:

>>

>>> diff --git a/sys/dev/usb/serial/ulpt.c b/sys/dev/usb/serial/ul=
pt.c

>>> index c566da92437..d663800f4fc 100644

>>> --- a/sys/dev/usb/serial/ulpt.c

>>> +++ b/sys/dev/usb/serial/ulpt.c

>>> @@ -499,6 +499,9 @@ static const STRUCT_USB_HOST_ID ulpt_devs[=
] =3D {

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {USB_IFACE_CLASS(UICLASS_PRI=
NTER),

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UIS=
UBCLASS_PRINTER),

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIP=
ROTO_PRINTER_1284)},

>>> +

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRO=
DUCT_EPSON_TMU220B, 0)},

>>>=C2=A0 =C2=A0};

>>>

>>>=C2=A0 =C2=A0static int

>>> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs

>>> index 01c25d7c096..632b8f19610 100644

>>> --- a/sys/dev/usb/usbdevs

>>> +++ b/sys/dev/usb/usbdevs

>>> @@ -1941,6 +1941,7 @@ product EPSON 1270=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0120

>> Perfection 1270 scanner

>>>=C2=A0 =C2=A0product EPSON 2480=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x0121=C2=A0 Perfection 2480 scanner

>>>=C2=A0 =C2=A0product EPSON 3590=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x0122=C2=A0 Perfection 3590 scanner

>>>=C2=A0 =C2=A0product EPSON 4990=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x012a=C2=A0 Perfection 4990 Photo scanner

>>> +product EPSON TMU220B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x020=
0=C2=A0 TM-U220B

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^ 0x0202 (shou=
ld be this value)

>>>=C2=A0 =C2=A0product EPSON CRESSI_EDY=C2=A0 =C2=A0 =C2=A0 =C2=
=A00x0521=C2=A0 Cressi Edy diving computer

>>>=C2=A0 =C2=A0product EPSON N2ITION3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A00x0522=C2=A0 Zeagle N2iTion3 diving computer

>>>=C2=A0 =C2=A0product EPSON STYLUS_875DC=C2=A0 =C2=A0 =C2=A00x06=
01=C2=A0 Stylus Photo 875DC Card Reader

>>

>>

> Hi Hans,

> 

> The patch above has no effect. My Epson printer is still obtaining the=


> ugen(4) driver after I apply and recompile the kernel. Anything I'=
ve missed?

> 

> Thanks,

> Archimedes

> 



Hi,



See comment above!


Thanks H=
ans for the correction! My Epson printer is now detected with the ulpt(4) d=
river. However, it's throwing a message code no. 12 and there is no cha=
racter device file of ulpt1 created in the /dev directory thus I could not =
print.

root@generic:~ # dmesg
...
ugen1.5: <EPSON EPSON UB-U03II> at usbus1ulpt1 on uhub1
ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.0=
0, addr 5> on usbus1
device_attach: ulpt1 attach returned 12

root@generic:~=
 # ls -la /dev/ulpt1
ls: /dev/ulpt1: No such file or directory

I double checke=
d my Xprinter printer and compared the behavior.



root@generic:~ # dmesg
...



ugen1.4: <Printer-58 USB Printing Suppo=
rt> at usbus1
ulpt0 on uhub1
ulpt0: <Printer-58 USB Printing Su=
pport, class 0/0, rev 2.00/2.54, addr 4> on usbus1
ulpt0: using bi-di=
rectional mode
ulpt0: offline

=



root@generic:~ # ls -la /dev/ulpt0
crw-=
r--r-- =C2=A01 root =C2=A0operator =C2=A00x7c Apr 10 03:44 /dev/ulpt0
=


What is thi=
s message code no. 12 showing-up in the device_attach() ->=20
device_attach: ulpt1 attach returned 12? I'm currently looking at this =
message code trying to figure-out what's going on.

Thanks,
Archimedes=C2=A0




<=
/div>





--000000000000e8892405da0019ab--

From nobody Sat Mar 12 08:27:53 2022
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 DCFD11A1F214
	for ; Sat, 12 Mar 2022 08:28:07 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.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 4KFwsz0klXz4Zkg
	for ; Sat, 12 Mar 2022 08:28:07 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x529.google.com with SMTP id b15so9451523edn.4
        for ; Sat, 12 Mar 2022 00:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=+qp0DiMizipyTaIg2zbeOE5UjpRdwJRXaQiWkCgeWfE=;
        b=DT0S3tEFQyvpeq+N9pOYhK+SbWBUbZz/+Vpk3+GqWm42SDgZzywgFMLJra0ylxFKHf
         5/DGPtaEsxc0TPWIMZgXWdAcFpo1Yoekysc6WUY5iONwlJvmsdtJvrjrqbYtOZkqppWw
         W6ORkecm0n3x4JqWr0XeU6v5TO3gETSTdzNR7E2SppZKdpU0ZTW3oM00mCwWWr121cRo
         OCRcAj1sh8GJLBjcQRVlG2DwLZXhn6kQQU0vgcgfxnRlBz47mBjPm/RyBkeaStIjYNs3
         x+ya0AcFpwwALGxqHkWO8SIQ/XhxNFGVgKBCS1DDl2lYveIDl/+zrEhQH+eSDrmRigRR
         kPVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=+qp0DiMizipyTaIg2zbeOE5UjpRdwJRXaQiWkCgeWfE=;
        b=74Z41wlRvjIIj5N5CpvuZJWCk+l+L3hIK5cT+Uy3YRCl29riklg6doAB3VtrJ1g4sf
         bYi3r0XTFE6L7uN3sVU5y5xBwjNpUefJXyvBXTzxfBgPeZ1x3+lmcY/cMH6TRh1S4Az6
         9Gg0yMLuXKOc5504NWDH7PvPsI+omM81TxNcu4P15GOIByvI0m87gsIM0W+6d3ZgUa7e
         s0e3Wh7ut1YV3YsA6TSlUkXN/7ff3EQeWXiIexoBPP5S75sbW5lHYu4eH5u/R0ZR9RLT
         EeaFwNYSMFmwoiTan3YmdcbmOTBIVl4OCHet45Ooq0ccU1mijKrDn1FYTigJBAp2FasD
         uUyQ==
X-Gm-Message-State: AOAM530xyiyRoMfSguAcgZgCp7AcIaQZ6SZdz7Rp8q4A5zKn3GUtSBBd
	fImALnV+g8xQmaHO4cxeaKeZxyjvsbMQD7rE25GtonxL68hg4g==
X-Google-Smtp-Source: ABdhPJzSo9ciejc/zXnaA8EIkg+2QNlaKq0Q4ITIMk6acYro2upLsTUjlW3AkkIesqUUzAO9ZbKjrxywNv7MV4aJclI=
X-Received: by 2002:a05:6402:2548:b0:416:4155:e12 with SMTP id
 l8-20020a056402254800b0041641550e12mr12180432edb.175.1647073684361; Sat, 12
 Mar 2022 00:28:04 -0800 (PST)
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: Archimedes Gaviola 
Date: Sat, 12 Mar 2022 16:27:53 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Distorted U-boot Display
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e01a4a05da0139cc"
X-Rspamd-Queue-Id: 4KFwsz0klXz4Zkg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=DT0S3tEF;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8945
Lines: 186

--000000000000e01a4a05da0139cc
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 28, 2022 at 4:51 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sat, Feb 26, 2022 at 11:49 AM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>> Hi,
>>
>> I've installed FreeBSD 13.0-RELEASE and 14.0-CURRENT successfully with
>> Raspberry Pi 3B. However, upon U-boot initialization stage the monitor
>> display is distorted as you can see here
>> https://pasteboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is
>> loaded it displays normal as you can see here
>> https://pasteboard.co/EkgcZdQSxjtA.jpg. I am thinking of lowering the
>> resolution so I tried changing the HDMI configuration settings in the
>> config.txt but it cannot be changed, it has no effect. It always stays on
>> the default 1366x768 as what dmesg has detected. This behavior is also
>> observed in 14.0-CURRENT.
>>
>> FreeBSD 13.0-RELEASE #0: Sat Feb 19 14:09:03 PST 2022
>>     root@fbsd13:/usr/src/sys/arm64/compile/GENERIC arm64
>> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git
>> llvmorg-11.0.1-0-g43ff75f2c3fe)
>> VT(efifb): resolution 1366x768
>> ...
>> 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.0.
>> VT: Replacing driver "efifb" with new "fb".
>> fb0: 1366x768(1366x768@0,0) 32bpp
>> fb0: fbswap: 1, pitch 5504, base 0x3e7f2000, screen_size 4227072
>>
>> freebsd@fbsd13:~ % cat /boot/msdos/config.txt
>> [all]
>> arm_64bit=1
>> dtparam=audio=on,i2c_arm=on,spi=on
>> dtoverlay=ds3231
>> dtoverlay=mmc
>> dtoverlay=disable-bt
>> device_tree_address=0x4000
>> kernel=u-boot.bin
>> enable_uart=1
>>
>> [pi4]
>> hdmi_group=2
>> hdmi_mode=11
>> armstub=armstub8-gic.bin
>>
>> freebsd@fbsd13:~ % grep -r "1366x768" /boot/msdos/
>> Binary file /boot/msdos/start_cd.elf matches
>> Binary file /boot/msdos/start_db.elf matches
>> Binary file /boot/msdos/start_x.elf matches
>> Binary file /boot/msdos/start.elf matches
>> Binary file /boot/msdos/start4.elf matches
>> Binary file /boot/msdos/start4cd.elf matches
>> Binary file /boot/msdos/start4db.elf matches
>> Binary file /boot/msdos/start4x.elf matches
>>
>> Using the same images with 13.0-RELEASE and 14.0-CURRENT this issue does
>> not occur in RPi 4B. Anyone encountered this issue? I confirmed this as
>> well with another new RPi 3B hardware and it behaves the same. Please see
>> attached dmesg log output for reference.
>>
>> Okay, I got this working now with the following HDMI config.txt
> adjustment. I just indicated the :0 which means the first HDMI interface in
> group and mode settings. So, the configuration from
>
> hdmi_group=2
> hdmi_mode=11
>
> becomes
>
> hdmi_group:0=2
> hdmi_mode:0=11
>
> Tested using 14.0-CURRENT.
>
> freebsd@generic:~ % uname -a
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n253384-45c23c2608e: Thu Feb 24 09:18:58 UTC 2022
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64
>
> Reference:
> https://www.raspberrypi.com/documentation/computers/config_txt.html
>
>
In addition though booting the firmware and loading U-boot is very very
slow, still this works in 13.0-RELEASE however the [pi3] label must be
indicated otherwise it has no effect.

[pi3]
hdmi_group:0=2
hdmi_mode:0=11

This is for documentation purposes only.

Thanks,
Archimedes

--000000000000e01a4a05da0139cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 28, 2022 at 4:51 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Sat, Feb 26, 20=
22 at 11:49 AM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div>Hi,

I've installed FreeBSD 13.0-RELEASE an=
d 14.0-CURRENT successfully with Raspberry Pi 3B. However, upon U-boot init=
ialization stage the monitor display is distorted as you can see here https://pas=
teboard.co/hxDjJHwxXPc8.jpg but when the FreeBSD kernel is loaded it di=
splays normal as you can see here https://pasteboard.co/EkgcZdQSxjtA.jpg. I a=
m thinking of lowering the resolution so I tried changing the HDMI configur=
ation settings in the config.txt but it cannot be changed, it has no effect=
. It always stays on the default 1366x768 as what dmesg has detected. This =
behavior is also observed in 14.0-CURRENT.

Fre=
eBSD 13.0-RELEASE #0: Sat Feb 19 14:09:03 PST 2022
=C2=A0 =C2=A0 root@fb=
sd13:/usr/src/sys/arm64/compile/GENERIC arm64
FreeBSD clang version 11.0=
.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)VT(efifb): resolution 1366x768
...
fb0: <BCM2835 VT=
 framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32=

fbd0 on fb0
WARNING: Device "fb" is Giant locked and may b=
e deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" wi=
th new "fb".
fb0: 1366x768(1366x768@0,0) 32bpp
fb0: fbswap:=
 1, pitch 5504, base 0x3e7f2000, screen_size 4227072

freebsd@fbsd13:~ % cat /boot/msdos/config.txt
[all]
arm_64bit=3D1<=
br>dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dtoverlay=3Dds3231
dtov=
erlay=3Dmmc
dtoverlay=3Ddisable-bt
device_tree_address=3D0x4000
ke=
rnel=3Du-boot.bin
enable_uart=3D1

[pi4]
hdmi_group=3D2
hdmi=
_mode=3D11
armstub=3Darmstub8-gic.bin

freebsd@fbsd13:~ % grep -r "1366x768" /boot/msdos/
Binar=
y file /boot/msdos/start_cd.elf matches
Binary file /boot/msdos/start_db=
.elf matches
Binary file /boot/msdos/start_x.elf matches
Binary file =
/boot/msdos/start.elf matches
Binary file /boot/msdos/start4.elf matches=

Binary file /boot/msdos/start4cd.elf matches
Binary file /boot/msdos=
/start4db.elf matches
Binary file /boot/msdos/start4x.elf matches
<=
div>
Using the same images with 13.0-RELEASE and 14.0-CURRENT=
 this issue does not occur in RPi 4B. Anyone encountered this issue? I conf=
irmed this as well with another new RPi 3B hardware and it behaves the same=
. Please see attached dmesg log output for reference.

Okay, I got this working now with the following =
HDMI config.txt adjustment. I just indicated the :0 which means the first H=
DMI interface in group and mode settings. So, the configuration from

hdmi_group=3D2
hdmi_mode=3D11

becomes

hdmi_group:0=3D2
hdmi_=
mode:0=3D11

Tested using 14.0-CURRENT.

freebsd@generic:~ % uname -a
FreeBSD generic 14.0-CURR=
ENT FreeBSD 14.0-CURRENT #0 main-n253384-45c23c2608e: Thu Feb 24 09:18:58 U=
TC 2022 =C2=A0 =C2=A0 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.a=
arch64/sys/GENERIC arm64



In addition though booting the firmware and lo=
ading U-boot is very very slow, still this works in 13.0-RELEASE however th=
e [pi3] label must be indicated otherwise it has no effect.

[pi3]


hdmi_group:0=3D2
hdmi_mode:0=3D11

This is =
for documentation purposes only.

Thanks,
Archimedes





<=
/div>





--000000000000e01a4a05da0139cc--

From nobody Sat Mar 12 08:41:19 2022
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 128341A20E61
	for ; Sat, 12 Mar 2022 08:41:34 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KFx9T1ydpz4bx4
	for ; Sat, 12 Mar 2022 08:41:33 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 74FFE2602E7;
	Sat, 12 Mar 2022 09:41:31 +0100 (CET)
Message-ID: 
Date: Sat, 12 Mar 2022 09:41:19 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KFx9T1ydpz4bx4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 549
Lines: 18

On 3/12/22 08:07, Archimedes Gaviola wrote:
> ugen1.5:  at usbus1
> ulpt1 on uhub1
> ulpt1:  on usbus1
> device_attach: ulpt1 attach returned 12

12 : man errno :
      12 ENOMEM Cannot allocate memory.

I guess the EPSON printer you've got is not compatible with ulpt

When printing, can you make sure that the length transferred is never a 
multiple of 64 bytes?

Also, there might be a bug lurking in the USB host controller driver, 
like already mentioned.

--HPS

From nobody Sat Mar 12 09:33:07 2022
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 0A01D19F9837
	for ; Sat, 12 Mar 2022 09:33:27 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535])
	(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 4KFyKL0KD9z4hPX
	for ; Sat, 12 Mar 2022 09:33:26 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x535.google.com with SMTP id g20so13664521edw.6
        for ; Sat, 12 Mar 2022 01:33:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=rF+hiGoIJac+QXbrgKyYeQ8Ezw+pBsKNOln6NGDkezI=;
        b=khWam5t/dx9Dp8sxuIzsu16SVljNj65u6oyx151rnVXvjbbBMPxtQNIBxxRYimPS5o
         JgcnsrgeGZ4LcHad6elu3rnSdmTc8C7KNrHyngBTX3bYz3n6aXD6Y3ExYKNH7eXiIQpS
         gTVGeCqGOpbkxhkmvQqL0AB0HDrwp+DjFaOxVOWFjGfy4Lz2qSjqEU5mHvIruHIvmy27
         +DWktylnXCu0vkkLsuhBSBQq79XeUeVRKn6FoHpkPFKfBBPZ1WSUPzj95OPJuPPQ8iAV
         jL7J70BFc2s1IX4ynLk67NC57a2oX3SlXTEtbOJ/g2jpS+x9tY+xWVvsOXqXPix4v6Rc
         hzWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=rF+hiGoIJac+QXbrgKyYeQ8Ezw+pBsKNOln6NGDkezI=;
        b=Kjp8RKxYUKVasKLxTdy8qMhSBUgLE7ewUJkM5HsGmaipigd3HXRKpW2tihMpOKc0Tq
         Ofzcg2mgja7EvP6rbS/xKRaJK8XR4HJnH3AQmcyzpxGRVBdhKMTbAOiPBy0UkzrlKU0l
         YVnSFOieZnAY1cH3+m5gnvjfgfAs1U2sqkirewXx6dcjqe3BxCOf0wmx8Hbbt8JCCSVP
         ov3ynTgrske5vLQUM6T5QwO9YbolqrVyQMDwEkx/JK2J3D5MM2dWOgEOhEt47WiMCOQ3
         lr6pn8egcsuW1EDtXZUO7ohtHbehMMCPWnqk+0GA/vRD2HGerGqoZukcyyR5WnXbHKSj
         gAYg==
X-Gm-Message-State: AOAM531gsM3V34uPGoq24fQJauGheHmRD/4rr6TxwrQaLu+dp+664zcL
	CrxwvdLDsHlzrpUzvUetcU7KTbo+1lrkjt6Imy0=
X-Google-Smtp-Source: ABdhPJybK4qrrboQgSAtH6IN8tEFpTBxoa95ykoURMePIvycCHqLMD9v10nKYIWb0EPX00hJgpqA7aT1czrljhSNZY4=
X-Received: by 2002:a50:cf48:0:b0:415:df40:9e3d with SMTP id
 d8-20020a50cf48000000b00415df409e3dmr12226924edk.185.1647077598092; Sat, 12
 Mar 2022 01:33:18 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sat, 12 Mar 2022 17:33:07 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000026e1f405da022313"
X-Rspamd-Queue-Id: 4KFyKL0KD9z4hPX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="khWam5t/";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4090
Lines: 100

--00000000000026e1f405da022313
Content-Type: text/plain; charset="UTF-8"

On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky  wrote:

> On 3/12/22 08:07, Archimedes Gaviola wrote:
> > ugen1.5:  at usbus1
> > ulpt1 on uhub1
> > ulpt1:  on usbus1
> > device_attach: ulpt1 attach returned 12
>


Hi Hans,


>
> 12 : man errno :
>       12 ENOMEM Cannot allocate memory.
>
> I guess the EPSON printer you've got is not compatible with ulpt
>

Oh I see, just tried with my RPi 4B and it has the same issue with returned
12 on ENOMEM. Previously with OpenBSD it was only detected as well with the
ugen(4) driver not ulpt(4) so most likely not compatible. I will check the
manual for any settings relevant to this.


>
> When printing, can you make sure that the length transferred is never a
> multiple of 64 bytes?
>

Okay let me double check with usbdump again as these are only plain text
characters being printed with no other formats involved.


>
> Also, there might be a bug lurking in the USB host controller driver,
> like already mentioned.
>

Okay noted again, so there's a need to check and review the code of the DWC
OTG host controller driver. So this is just specific to RPi 3B. I'll
proceed on enabling the debugging settings and observed.

Thanks,
Archimedes

--00000000000026e1f405da022313
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Mar 12, 2022 at 4:41 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
2/22 08:07, Archimedes Gaviola wrote:

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ulpt1 on uhub1

> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> device_attach: ulpt1 attach returned 12


Hi Hans,
=C2=A0



12 : man errno :

=C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.



I guess the EPSON printer you've got is not compatible with ulpt<n&g=
t;

Oh I see, just tried with my RPi 4B =
and it has the same issue with returned 12 on ENOMEM. Previously with OpenB=
SD it was only detected as well with the ugen(4) driver not ulpt(4) so most=
 likely not compatible. I will check the manual for any settings relevant t=
o this.
=C2=A0



When printing, can you make sure that the length transferred is never a 
multiple of 64 bytes?

Okay let me doubl=
e check with usbdump again as these are only plain text characters being pr=
inted with no other formats involved.
=C2=A0



Also, there might be a bug lurking in the USB host controller driver, 

like already mentioned.
Okay noted again, so there's a need =
to check and review the code of the DWC OTG host controller driver. So this=
 is just specific to RPi 3B. I'll proceed on enabling the debugging set=
tings and observed.

Thanks,
Archimedes




--00000000000026e1f405da022313--

From nobody Sat Mar 12 15:31:26 2022
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 EB1EB1A00C5F
	for ; Sat, 12 Mar 2022 15:31:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4KG6Gf1Zxbz4T2Y
	for ; Sat, 12 Mar 2022 15:31:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id a8so25076291ejc.8
        for ; Sat, 12 Mar 2022 07:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=RFNulp8+rOgq0koLYtwAs2LdFeYfujnfwgZM6oFN9mk=;
        b=AEu23g4nCoRx6KcQU1+Nx/dRvi2ZW9nJei7yrYsG6yZ+nJUA4yI4xZNabDnqg+d8MW
         HAIXejIBsGmS8e3Fo1liTm7TIp4TN9a6vxwosj4Jn9WniAnfQeGVf3AR3OySJFGqH2lR
         /PrmRJeLDxzYx8CUl+SZdXjU5T7b8gmL+IRRQRy5uiiUMce4vjrR2PIuHsdp82StR7lL
         vu8BDbP3AzD3J002Ev8IjQviGxdnGxj64/CON/x+1zolykorDe/FhQRCY80uA9sEkWE7
         IEv122VpLA5kvN/+MyZmdtX9CB264JoPD5QInmDouejWb1VfpSEEONGJuu9UI1ShS4uL
         r7Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=RFNulp8+rOgq0koLYtwAs2LdFeYfujnfwgZM6oFN9mk=;
        b=d/MyO18iBE2LPJFDUNhuFIuRkOLevRVyNLIGLTq83iM1k5veh4RkkJT14HcGwsw/0V
         JSc/2mhZxzEkK4m8So23xFjs2D9+N51r5cDqnmZ2K6RqNATfvfoUvHkVAMdNMOwHkM2k
         BEC01UcHvpNip2JVEbLhBcW0PTh7pAie5TmHncmfcJ8Skorn5y9QOu6szAjLHXCLr3cv
         6VYkco6mg0bOBSJ+Or9J9uw51WGVJUpSFwUryb54i9vqYB4EG1xlGxGiUhi+ME6BEj0E
         9r2jJIdHtKXKkNhMCXXeZbLELyJvQ4pTFwyp8ghZw3Ncmstej70Y5sgVUezOuwh7L1PP
         zq6w==
X-Gm-Message-State: AOAM530xq4pEHcrQpfOnqJdDV06qdJ2Jxa6XFhgjvz2ARSgX89/FTNz6
	YX9sjkYJbPjR6yRlynfN6KQw8cq/TZZPLMAqcmcJQ0KL
X-Google-Smtp-Source: ABdhPJz5IwPSBee/qiSE+N9w6+6GRWAY6UKJ05jLG3VAQc+bot3+BEGaW7d+elzXAsbgYdjsNFAmqoOamZSynXWTkaQ=
X-Received: by 2002:a17:907:eac:b0:6db:799c:cb3c with SMTP id
 ho44-20020a1709070eac00b006db799ccb3cmr13068233ejc.559.1647099097231; Sat, 12
 Mar 2022 07:31:37 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
In-Reply-To: <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
From: Archimedes Gaviola 
Date: Sat, 12 Mar 2022 23:31:26 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000099b6bf05da0724b6"
X-Rspamd-Queue-Id: 4KG6Gf1Zxbz4T2Y
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=AEu23g4n;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2380
Lines: 50

--00000000000099b6bf05da0724b6
Content-Type: text/plain; charset="UTF-8"

>
> IOERROR usually means an electrical error. The RPI3B will use a
> transaction translator for the FULL speed traffic, which is driven by
> software.


Hi Hans,

I'm curious about the transaction translator you've mentioned, any idea why
there's a need for translation and what is being translated? Does this only
happen when RPi 3B (acting as host controller) is transmitting data to the
Epson printer? Are translation events visible in the usbdump? In this case
there's a way to possibly track what's going on and how to identify any
info that is being translated? Any idea also if translation is being
performed in RPi 4B? As I have conducted several printing cases with my
Epson printer without any issues with either of the 4 ports.

Sorry for these questions as I am catching-up to the USB technology
internal workings under the hood.

Thanks,
Archimedes

--00000000000099b6bf05da0724b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



IOERROR usually means an electrical error. The RPI3B will use a 

transaction translator for the FULL speed traffic, which is driven by 

software.

Hi Hans,

I'm curious about the transaction translator you've mentioned, any=
 idea why there's a need for translation and what is being translated? =
Does this only happen when RPi 3B (acting as host controller) is transmitti=
ng data to the Epson printer? Are translation events visible in the usbdump=
? In this case there's a way to possibly track what's going on and =
how to identify any info that is being translated? Any idea also if transla=
tion is being performed in RPi 4B? As I have conducted several printing cas=
es with my Epson printer without any issues with either of the 4 ports.
=


Sorry for these questions as I am catching-up to =
the USB technology internal workings under the hood.

Thanks,
Archimedes


--00000000000099b6bf05da0724b6--

From nobody Sat Mar 12 16:38:34 2022
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 8E5531A0EEED
	for ; Sat, 12 Mar 2022 16:38:55 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KG7mG1q3pz4cHR
	for ; Sat, 12 Mar 2022 16:38:54 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B18C9260535;
	Sat, 12 Mar 2022 17:38:46 +0100 (CET)
Message-ID: 
Date: Sat, 12 Mar 2022 17:38:34 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KG7mG1q3pz4cHR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.24 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.95)[-0.946];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1658
Lines: 47

On 3/12/22 16:31, Archimedes Gaviola wrote:
>>
>> IOERROR usually means an electrical error. The RPI3B will use a
>> transaction translator for the FULL speed traffic, which is driven by
>> software.
> 

Hi Archimedes,

> Hi Hans,
> 
> I'm curious about the transaction translator you've mentioned, any idea why
> there's a need for translation and what is being translated? 

When the High Speed USB HUB was invented, there was a need to support 
FULL and LOW speed USB transactions. Because FULL and LOW speed 
transactions are slow and take up much bandwidth, a transactions 
translator was invented which translates between High Speed USB and 
FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH 
speed port, followed by a USB HUB. These transactions are not visible in 
usbdump .

 >Does this only
> happen when RPi 3B (acting as host controller) is transmitting data to the
> Epson printer? Are translation events visible in the usbdump? In this case
> there's a way to possibly track what's going on and how to identify any
> info that is being translated? 

By turning on the HC debugging, you can possibly track via debug 
messages what is going on. Maybe it is a timing issue, that the SW is 
too slow serving the micro transactions.

Any idea also if translation is being
> performed in RPi 4B? 

The later RPi's do the transaction translator bits in HW or via the XHCI 
block.

As I have conducted several printing cases with my
> Epson printer without any issues with either of the 4 ports.
> 
> Sorry for these questions as I am catching-up to the USB technology
> internal workings under the hood.

You are welcome!

--HPS

From nobody Sun Mar 13 06:27:09 2022
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 2A7CB1A247DE
	for ; Sun, 13 Mar 2022 06:27:20 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4KGV872xRfz3HBS
	for ; Sun, 13 Mar 2022 06:27:19 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id a8so27530303ejc.8
        for ; Sat, 12 Mar 2022 22:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=0zkD9gkxn1rftqnIvkhh6RrVAK8znRetFStSe55Tbyo=;
        b=ZXOX0eNZCZFygVeNi/5JLyKUV54G/Evpb+vjHpzYuuWxnhBtv5gt1iP+F/fUCjTP3C
         8rqH9r2ImyM+rTQMRpaUj77fR8v9fEZbiLqted8wlvVIva6lVVae34A3+0kQeUtOOhN+
         hMAIhekL/2O/2JsVlflHRSxxBTHXNvj8iprxKBnQWYssHimBQvmYt2tE2q6hTJE/kP9p
         6Eag63r4x+zLK8vhc6PfrkplNkBBz1q8nWc8OjJ1aJt9IVilb99HD17dwxaf4vKnN2Ox
         SVyxcgDhMhhIpyHf5v2XiBTv9Q12O0rtGHTkqU8xkTKuStz/ILS+uiUUnJOJVgyTeWmk
         QyYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=0zkD9gkxn1rftqnIvkhh6RrVAK8znRetFStSe55Tbyo=;
        b=OM5NWJjfPP36+PJZVtsWOO71f9TW3OTtCXfcaOK8eqoJrp42pR0gCZbahg3Y9VVAeQ
         tZwukEkIzpmErETmlpkzeSeAkq77Nk4pNDIB0ykRvpTNMdmMSKXBBu6BUnW3+h/0d8jK
         ie/r2cY3jI/iXI6+k7S7Z92eiEVDjU4ITT2MechJQfmm5h/g0WoOpl27YUoypMf4kE31
         cFGEqPOCZhKDDmGdo3lshzJGIdek+XyNhRe8cCDiHRqcQ+v7e6bGMTYNg11jsAjnjxW3
         hHnOLpgALorSJHymhO26IInEwBWFvbOl+nKvS9PP+unUaCwx/tFRfOOmQ/wqbVUg+zzt
         z4rQ==
X-Gm-Message-State: AOAM531oAbWw/d1fDYR/2NKn0RPs9XqIPjiH4gynVx6DB/Zq9NnmusVe
	FOkUqMexvsilUP9He/+kriDG8K6dkH2n2RLbvFu4YwdrkMo=
X-Google-Smtp-Source: ABdhPJw6fiYSbmO2t7D+1Z56DyyGY7rahkKZiDl4I8aCIoz93Mpc0grnel373x7YAc0PQ6QIH/FUkxxDCx0sxhiI2Bo=
X-Received: by 2002:a17:907:a41f:b0:6d6:f925:1696 with SMTP id
 sg31-20020a170907a41f00b006d6f9251696mr14916188ejc.62.1647152838399; Sat, 12
 Mar 2022 22:27:18 -0800 (PST)
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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sun, 13 Mar 2022 14:27:09 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d2de2405da13a750"
X-Rspamd-Queue-Id: 4KGV872xRfz3HBS
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ZXOX0eNZ;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.73 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.27)[0.267];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6404
Lines: 155

--000000000000d2de2405da13a750
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky 
wrote:

> On 3/12/22 16:31, Archimedes Gaviola wrote:
> >>
> >> IOERROR usually means an electrical error. The RPI3B will use a
> >> transaction translator for the FULL speed traffic, which is driven by
> >> software.
> >
>
> Hi Archimedes,
>
> > Hi Hans,
> >
> > I'm curious about the transaction translator you've mentioned, any idea
> why
> > there's a need for translation and what is being translated?
>
> When the High Speed USB HUB was invented, there was a need to support
> FULL and LOW speed USB transactions. Because FULL and LOW speed
> transactions are slow and take up much bandwidth, a transactions
> translator was invented which translates between High Speed USB and
> FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH
> speed port, followed by a USB HUB. These transactions are not visible in
> usbdump .
>
>  >Does this only
> > happen when RPi 3B (acting as host controller) is transmitting data to
> the
> > Epson printer? Are translation events visible in the usbdump? In this
> case
> > there's a way to possibly track what's going on and how to identify any
> > info that is being translated?
>
> By turning on the HC debugging, you can possibly track via debug
> messages what is going on. Maybe it is a timing issue, that the SW is
> too slow serving the micro transactions.
>
> Any idea also if translation is being
> > performed in RPi 4B?
>
> The later RPi's do the transaction translator bits in HW or via the XHCI
> block.
>
> As I have conducted several printing cases with my
> > Epson printer without any issues with either of the 4 ports.
> >
> > Sorry for these questions as I am catching-up to the USB technology
> > internal workings under the hood.
>
> You are welcome!
>


Thank you so much Hans for answering my questions, really appreciate it! I
have a much better understanding now.

I came from testing with 13.0-RELEASE having the same RPi 3B hardware and
setup and it's very stable. I haven't encountered any IOERROR and
incomplete printed outputs that were encountered with 14.0-CURRENT
(February 24, 2022). By the way, I found in the repository here
https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ that
there were two latest snapshots released dated March 3 and March 10,
respectively. I need to take printing tests first, especially the latest to
check if it also manifests before I go back to the Feb. 24 snapshot and do
a thorough test with debugging. I'll provide updates for any observations.

Thanks,
Archimedes

--000000000000d2de2405da13a750
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Mar 13, 2022 at 12:38 AM Hans=
 Petter Selasky <hps@selasky.org&=
gt; wrote:
On 3/=
12/22 16:31, Archimedes Gaviola wrote:

>>

>> IOERROR usually means an electrical error. The RPI3B will use a
>> transaction translator for the FULL speed traffic, which is driven=
 by

>> software.

> 



Hi Archimedes,



> Hi Hans,

> 

> I'm curious about the transaction translator you've mentioned,=
 any idea why

> there's a need for translation and what is being translated? 



When the High Speed USB HUB was invented, there was a need to support 

FULL and LOW speed USB transactions. Because FULL and LOW speed 

transactions are slow and take up much bandwidth, a transactions 

translator was invented which translates between High Speed USB and 

FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH 
speed port, followed by a USB HUB. These transactions are not visible in 
usbdump .



=C2=A0>Does this only

> happen when RPi 3B (acting as host controller) is transmitting data to=
 the

> Epson printer? Are translation events visible in the usbdump? In this =
case

> there's a way to possibly track what's going on and how to ide=
ntify any

> info that is being translated? 



By turning on the HC debugging, you can possibly track via debug 

messages what is going on. Maybe it is a timing issue, that the SW is 

too slow serving the micro transactions.



Any idea also if translation is being

> performed in RPi 4B? 



The later RPi's do the transaction translator bits in HW or via the XHC=
I 

block.



As I have conducted several printing cases with my

> Epson printer without any issues with either of the 4 ports.

> 

> Sorry for these questions as I am catching-up to the USB technology
> internal workings under the hood.



You are welcome!


Thank you so much Hans for answering my questions, really appreci=
ate it! I have a much better understanding now.

I came from testing with 13.0=
-RELEASE having the same RPi 3B hardware and setup and it's very stable=
. I haven't encountered any IOERROR and incomplete printed outputs that=
 were encountered with 14.0-CURRENT (February 24, 2022). By the way, I foun=
d in the repository here https://download.freebsd.org/snapshots/arm6=
4/aarch64/ISO-IMAGES/14.0/ that there were two latest snapshots release=
d dated March 3 and March 10, respectively. I need to take printing tests f=
irst, especially the latest to check if it also manifests before I go back =
to the Feb. 24 snapshot and do a thorough test with debugging. I'll pro=
vide updates for any observations.

=

Thanks,
Archimedes




--000000000000d2de2405da13a750--

From nobody Sun Mar 13 15:25:39 2022
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 552C919B31AD
	for ; Sun, 13 Mar 2022 15:26:01 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635])
	(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 4KGk5h2V43z3NkN
	for ; Sun, 13 Mar 2022 15:26:00 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x635.google.com with SMTP id qt6so28890774ejb.11
        for ; Sun, 13 Mar 2022 08:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Pq8tWDrT1Q9cAGxNtTWYTF2ZjWH0VSmcP5kabpLWPnY=;
        b=MOf40aopxcuh8YxGPd/5Vm+vo+/xWBNpg6VNV9xzvoNj9osuX/NKWSdWqsFziY+Uhp
         BY2pQwwk9apZyL1jcB7g+T5IuymRJGy1cdG42vzkvIPlejH2baDASVLhpBdOmo5DahzU
         IOnn3OvuPsO24elkQN0niNFCPPTkoyFbdcJ+k04PeLDFrf45nbfidR0MxMkjFoc22U8C
         YaGhALjLwCe/2D+8XTS5djdwOkVFp84qqHsIPrJjvnXY5o64dR1A+MaNPhvl+VdFle6s
         DEFlSrnou0qR005oHB1Nq+HGU2F2EjM+qM2Ql0Ngxx25a9+ztP06lQg2KH+qJ37yiQkN
         ymbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Pq8tWDrT1Q9cAGxNtTWYTF2ZjWH0VSmcP5kabpLWPnY=;
        b=k94C1+E4TgHKomEZ+1FxRNlr3KvPqeg4gx0Tw7v1HFx3MWoBIubjroXxBlRRtwKK1s
         sWkU6yoStohIS+V7YCStsLlRVZCjUnCeKufHmpE/TWx28/RRC5uMNAxfmitrSdT1ghfj
         gFbI4P7D4ATlL2rSJisuiXDYYyAiDwN1+XRhByNtPcvTLgSjsBJfOjYKg6kK7dbXfSo0
         /fglcoN7vXHZT4AygoV8Wd+n1GHnAs4e0zdh5xeM9ch9VtuI/lIsYfE17Gzu5+/lWBX4
         LcsS6EEPLNKCbErQJOhBD91ZegY3vaQzvVfs2DJ0Koy+ElBDoqc9TrGxnZzTkDTg2iXP
         oZSw==
X-Gm-Message-State: AOAM530Sc5dkKQe/PMp0zGJbNb6Vqa7stAkS+mjcUEDEhIsnzYvdIoPB
	9zaNU5rLmk7PN0dm8EWTHa1ji2/eFoO/ODZWvUCbK979qYs=
X-Google-Smtp-Source: ABdhPJzl3qqAZ/EeeprdteByxOJAuFF04ZoTf+cIKr4EYGIKITqiG2J4y14GGtlJeCJAOmZEyATrM2lyzKNtwpl4To0=
X-Received: by 2002:a17:907:d90:b0:6db:a372:e61c with SMTP id
 go16-20020a1709070d9000b006dba372e61cmr9900644ejc.276.1647185153250; Sun, 13
 Mar 2022 08:25:53 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sun, 13 Mar 2022 23:25:39 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f0590405da1b2dbb"
X-Rspamd-Queue-Id: 4KGk5h2V43z3NkN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MOf40aop;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7450
Lines: 180

--000000000000f0590405da1b2dbb
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky 
> wrote:
>
>> On 3/12/22 16:31, Archimedes Gaviola wrote:
>> >>
>> >> IOERROR usually means an electrical error. The RPI3B will use a
>> >> transaction translator for the FULL speed traffic, which is driven by
>> >> software.
>> >
>>
>> Hi Archimedes,
>>
>> > Hi Hans,
>> >
>> > I'm curious about the transaction translator you've mentioned, any idea
>> why
>> > there's a need for translation and what is being translated?
>>
>> When the High Speed USB HUB was invented, there was a need to support
>> FULL and LOW speed USB transactions. Because FULL and LOW speed
>> transactions are slow and take up much bandwidth, a transactions
>> translator was invented which translates between High Speed USB and
>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH
>> speed port, followed by a USB HUB. These transactions are not visible in
>> usbdump .
>>
>>  >Does this only
>> > happen when RPi 3B (acting as host controller) is transmitting data to
>> the
>> > Epson printer? Are translation events visible in the usbdump? In this
>> case
>> > there's a way to possibly track what's going on and how to identify any
>> > info that is being translated?
>>
>> By turning on the HC debugging, you can possibly track via debug
>> messages what is going on. Maybe it is a timing issue, that the SW is
>> too slow serving the micro transactions.
>>
>> Any idea also if translation is being
>> > performed in RPi 4B?
>>
>> The later RPi's do the transaction translator bits in HW or via the XHCI
>> block.
>>
>> As I have conducted several printing cases with my
>> > Epson printer without any issues with either of the 4 ports.
>> >
>> > Sorry for these questions as I am catching-up to the USB technology
>> > internal workings under the hood.
>>
>> You are welcome!
>>
>
>
> Thank you so much Hans for answering my questions, really appreciate it! I
> have a much better understanding now.
>
> I came from testing with 13.0-RELEASE having the same RPi 3B hardware and
> setup and it's very stable. I haven't encountered any IOERROR and
> incomplete printed outputs that were encountered with 14.0-CURRENT
> (February 24, 2022). By the way, I found in the repository here
> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
> that there were two latest snapshots released dated March 3 and March 10,
> respectively. I need to take printing tests first, especially the latest to
> check if it also manifests before I go back to the Feb. 24 snapshot and do
> a thorough test with debugging. I'll provide updates for any observations.
>
> Thanks,
> Archimedes
>


Hi Hans,

Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
snapshot) seems to be stable. Another test will be performed tomorrow.

Thanks,
Archimedes

--000000000000f0590405da1b2dbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Mar 13, 2022 at 2:27 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Sun, Mar 13, 20=
22 at 12:38 AM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/12/22 16:31, Archimedes Gaviola wrote=
:

>>

>> IOERROR usually means an electrical error. The RPI3B will use a
>> transaction translator for the FULL speed traffic, which is driven=
 by

>> software.

> 



Hi Archimedes,



> Hi Hans,

> 

> I'm curious about the transaction translator you've mentioned,=
 any idea why

> there's a need for translation and what is being translated? 



When the High Speed USB HUB was invented, there was a need to support 

FULL and LOW speed USB transactions. Because FULL and LOW speed 

transactions are slow and take up much bandwidth, a transactions 

translator was invented which translates between High Speed USB and 

FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH 
speed port, followed by a USB HUB. These transactions are not visible in 
usbdump .



=C2=A0>Does this only

> happen when RPi 3B (acting as host controller) is transmitting data to=
 the

> Epson printer? Are translation events visible in the usbdump? In this =
case

> there's a way to possibly track what's going on and how to ide=
ntify any

> info that is being translated? 



By turning on the HC debugging, you can possibly track via debug 

messages what is going on. Maybe it is a timing issue, that the SW is 

too slow serving the micro transactions.



Any idea also if translation is being

> performed in RPi 4B? 



The later RPi's do the transaction translator bits in HW or via the XHC=
I 

block.



As I have conducted several printing cases with my

> Epson printer without any issues with either of the 4 ports.

> 

> Sorry for these questions as I am catching-up to the USB technology
> internal workings under the hood.



You are welcome!


Thank you so much Hans for answering my questions, really appreci=
ate it! I have a much better understanding now.

I came from testing with 13.0=
-RELEASE having the same RPi 3B hardware and setup and it's very stable=
. I haven't encountered any IOERROR and incomplete printed outputs that=
 were encountered with 14.0-CURRENT (February 24, 2022). By the way, I foun=
d in the repository here https://download.freebsd.=
org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ that there were two latest=
 snapshots released dated March 3 and March 10, respectively. I need to tak=
e printing tests first, especially the latest to check if it also manifests=
 before I go back to the Feb. 24 snapshot and do a thorough test with debug=
ging. I'll provide updates for any observations.

Thanks,
Archimedes
=



Hi Hans,

Initial testing conducted with the latest 14.0-CURRENT (March 10, 20=
22 snapshot) seems to be stable. Another test will be performed tomorrow.

Thanks,
Archimedes 


--000000000000f0590405da1b2dbb--

From nobody Sun Mar 13 19:34:06 2022
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 77C441A13E34;
	Sun, 13 Mar 2022 19:33:58 +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 4KGqbn3cXcz4kh2;
	Sun, 13 Mar 2022 19:33:57 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 22DJY6bh069970
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 13 Mar 2022 12:34:07 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 22DJY62F069969;
	Sun, 13 Mar 2022 12:34:06 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 13 Mar 2022 12:34:06 -0700
From: bob prohaska 
To: bob prohaska 
Cc: freebsd-net@freebsd.org, Free BSD 
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
Message-ID: <20220313193406.GA65568@www.zefox.net>
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@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: <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
X-Rspamd-Queue-Id: 4KGqbn3cXcz4kh2
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [1.52 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.971];
	 NEURAL_SPAM_LONG(0.98)[0.976];
	 NEURAL_HAM_MEDIUM(-0.38)[-0.384];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1704
Lines: 41

It looks as if things are somewhat altered, but not really
improved,  after updating to 

FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #24 stable/13-n249989-b85d0d603c5: Sat Mar 12 17:47:19 PST 2022     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

on the Pi3 with USB root disk (hdd, not ssd).

After reboot the machine answered around 30 % of incoming pings and
sometimes responded to ssh login attempts. At least once the login
attempt was successful, even with no outgoing ping process running.
That seems like progress.

With an outgoing ping running it's possible to ssh into the machine,
with a highly variable delay for the password prompt.

Unfortunately, new console errors are appeared:

bob@pelorus:~ % (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 1f ea a3 c0 00 00 40 00 
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected)
(da0:umass-sim0:0:0:0): Retrying command (per sense data)

The error message repeated at intervals, seemingly linked to disk activity,
with the machine running out of retries after starting buildworld. 
That seems like progress in reverse 8-)

Reverting to 13-n249985-dd6c1475a63: Fri Mar 11 18:06:31 PST 2022
permitted recovery, with the old problems attendant.
 
-current now has some usb testing tools:
root@www:/usr/src # ls tools/tools/usbtest
Makefile		usb_control_ep_test.c	usb_msc_test.c		usbtest.c
Makefile.depend		usb_modem_test.c	usb_msc_test.h		usbtest.h

Is there any guidance on what they do? I couldn't find a man page.

Thanks for reading,

bob prohaska


From nobody Sun Mar 13 20:46:17 2022
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 DBF8C1A22B6D
	for ; Sun, 13 Mar 2022 20:46:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KGsCS5WkTz4twC
	for ; Sun, 13 Mar 2022 20:46:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647204381; bh=EA82p1tZnjsic0U/oW1S8UOepOLuphEcS7s48mx39cw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=twjbLEcSV+R2rlIvGQ1fs2jYSuQ+rZPWSm7INnmcNYdGBS9AgqiDQdtZ79rnOMk/9foJWzC1QaQ1xsLaqpI5Px0daM5wCF8fqhjGOxZi4QJSCWMwYH95MvnaMrwd6QGZPwBNYc90AdtLq+sgQR3FScQ5P26G4GHFQs8BeLW0BppHrvY0XOiRKE16RJfqhK7RiyV93FW2ri+WQn6nFjSv8cEf1s7VhUSCYt0aDxw1nTUQBzNu31iTeMLVrUMFcxBkQPmJNJsKiAINZFfE72aIkec7ZLjtHxfxA7NuphS619muxjDGTKEb+Xl8ENE/qkDJiBsv9hO+J+kWNFRPWWdhHQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647204381; bh=OQxMM49Mx4KpIhNqaMoZhDSoT9yNqnyU/UyooPYe3hQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=juna71YH5hizvuNSO/84SpHUC5uQfKIiyTtaEYaUFa4pp0QtCG4gnL9QhYNIwBxBvbimghARJhdrR2LULQ1/6NmcWVnN2j4bOWEkgRZgKOaLuGYGli/pMJkTJqgNpvYkrNQx5leVJGXo9QrDvu63EFkQNGN6ZXH9ouT5q9DKFwhO/cnhrawCQTdDh9yqN8+02igflTMS4pwwr3YnZMSGtkwGS4eBVn3CGhVTbaV3K7raK8VGHvthXh30Ne0sM+TeonXlOjLERetLzlsTUlASWXQ1Cnftad2L7yLaR0o+dKmkkavossBq5oMN312j0mKRV7saTd/SCKGoDv7m/DadJA==
X-YMail-OSG: zFOxZEMVM1kbRukaThszQfAmrZWCtqE8T.cJn2ZDDcDiYdvIgNAGZgCBdoSCJ8B
 PuVKTnUwAM0KvCmH8Xh20WcJ1Dt98MDSlEVgsusjftNTDstmFNJnCadxGcu4hBI67cB6lBpwY2Mc
 tWO3TrYCMcMEvjx0uB1xs80AAeLXfnImpA5lPSOr25KbF20iuYnizYzneIeCJqn3VYRMreZpRCRl
 lhWj02IfboclkIHe1dlGdGNgu.X0ul97ZYUq4Xq2oeKu31e5I_f54mxdfpSxt9R7P0oM0iE5nM47
 LaCLezHIA3eojJCLJYMYT3vGkXmIE0FgsVFDmXKU_29XN1E3XYeaEg8rxf_zkqS6JarBWq2seQ80
 .cEh6yhZcnFN4t02p6.3HKLBDMG_u3gseTPjQJ8BnykDmVTSHTu2t4thYQo9UJIUdO0EOHEqtFnx
 YGb1An0RRizguDTtgXUkK02Ga5lsGaeR2fi3VRPf8LMhF.mX0eGgmtnZ6wt7mqtKMpwr4l_YbSt4
 cQk7bQDp5jvcWBEHFV.THRKbWDb9RfFzTeryT0IBX40JVeaVwkAVl.4S0eY0V58lz_A3LDfBOr0c
 zJUSp4nk0m.FBHaM3ohpDcKW1OQlKUEi6g1t4EbtV3RyCyIWXkJQXwY8AqxhT505N3wxxCXwPs7_
 c9JoKfGlShUOcQ7HHjY5IYDHVAIqFdaAYcsl68Rs2KODATyCXNMEkkuw3_87efiVhEhXo_8AKpAD
 Sns7HiICCDTDFkxiHX.yNR1.i.djRFrwl3bb.vZ5KaJ7NtTiWfEx.uH7k8o3FGctr_28t04RzzOE
 WWIsX7y4LJ35IkfnDFB1kZsKFQORttpvaMmwXR14hwAM0v_hqzs9uT4bFRzNV16dxWhOnFOr1u8c
 NBRdbMlu9VtP8kc10FSV12KCZTDYQZz.izWvzgQlGRlI6P_1B7XhsTc6dYmZK7j649rs5E0uz9.h
 cGMLuUZdc2rDftTYwtyvIxQrfL7ngBggR_7OUkjE0pzSbrA6YSb6WH74NhLaXoJy3xPBJazFwpGd
 5ejXx30aKPOPL5XDe.oNt7UtCjkpA4RoLPhWKdCWdFRpSR_Gm1U5HkTt.JeKRCHuXyp96DD7IA5g
 ma8Gq.9Th7GJvN2EHjsnSDpafOV30dXvnOfTcnODFNs6MyQU4Zyvv8D9NhmSusv31oVErR3NT6XA
 1MbEsP3MVShvKCiyLDd_UL983vVak4u_rhoOnaAq8y3DA9GGt39DDGe40CBwVb55eR4eFdXt6Shu
 FHgDaUSO7FTPCvWtU6XPc2CoY1lOmZgTLOy0O.m6yYF84gFpyGrnFq1A0rkCeUBMMjrJHkL567tQ
 JqujOe2VzMqi6PcvWKKrOHa4TBvQgRQ_quySlc.9GDdqqd5M0poHvnaKN_lE9834oS_Nd3mSyfu_
 G0wb1wKtHBv29TFU0F602BZ2qUFVgjykgqREHCg9c7EcOCYQqWa3SGQZJPIHIo.UQyvs_UgG.Wqd
 pFXLid3zRPpcAXVrCWzJszEznmqQ9gX.baHnonQRx._R_0nZcp8UgFCq0.Hc2ySZmUez81XEo3TW
 BtklAny2t4FMaii4xcKumQv4pNAb9e2TsxZ5pUFDYFAe.v.8PTs.ZoIYnDP0oxK_pp65m3Q0WaxA
 SOMXOEtp4s.cZ9VC.EpqhQvBpujhDpn8WbyRv19Odd3TwgVUmjBPGd1xX0p1iW0zWeq4uYCEqNBS
 4fXoa81o4BFjK.Foerq7cus83NI0XWihIEoKyvMz3PQ2I1Lfuxyf5jIgElYSUAArPz9fAvPT6mwn
 lDDjs9R84I_RpQrAvS_VtEh1aRDYQ1iZkGOoYeSfbUacWokfr9WGQzTKU2uYiuQ9SkTORpjcDM12
 kTMf7himUnt0e5I4vnJtRFfksfuYyLkD9.yooWJ3Ag2br6HaME41gjLutcQbC5BIi58YmlWNpnpe
 JyNAEZTbRxkcB2.dgKF6WQySF0qTAwBoPDEhf1irkISRAr7CtwSS_MwvGaIblfk37OK0fcqLaSMj
 ekViu1WHi3wv_jM4w4uUtKRzLuv7PH.fG2dJZaBTNjBQlgdl28UdXjvJ1L.MAN8F5d7JvoYRlPoy
 m.2x8gEMY9.1jwuY2S3szBuleaLLvqi3FMa8sgO0txPps6F0LMxUGg.Rhwa1fl8AGsYSmHWqbddt
 40eG0SIrZmyXYS5y3Twvex3JDlHlrB2Crsj1ZImH7OrmF3AKQxYljXKd7BI9DXyTzuydIwxMFiia
 mVw13h3T8VoWlw.bGVTsb_Cltuk9rtXLVG_t0Xtp_CJ8UbJ4PaojMfhftKfK_xEOMJt9IqIvOvgi
 z26.uIF9PvEfq0.4-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Mar 2022 20:46:21 +0000
Received: by kubenode525.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 249b7facdc9c4e9c7154a66c5c41cc8e;
          Sun, 13 Mar 2022 20:46:17 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: <20220313193406.GA65568@www.zefox.net>
Date: Sun, 13 Mar 2022 13:46:17 -0700
Cc: freebsd-net@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KGsCS5WkTz4twC
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=twjbLEcS;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.51 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.99)[0.988];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2873
Lines: 77

On 2022-Mar-13, at 12:34, bob prohaska  wrote:

> It looks as if things are somewhat altered, but not really
> improved,  after updating to=20
>=20
> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #24 =
stable/13-n249989-b85d0d603c5: Sat Mar 12 17:47:19 PST 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

That is still your build and your configuration adjsutemtns
for your general use --on your usual media.

Are you ever going to test the networking behavior of a snapshot
image and/or, now, BETA image, installed to a fresh, independent
microsd card that is used to boot, no other media attached? The
point being: not your build, not your configuration, minimal
adjustment to allow the basic testing. (The system does not need
to be able to support your general use, just the network testing.)

If you want the problem worked on, folks will need an identified
configuration that they can reproduce the problem with. Your
builds and full set of configuration adjustments likely can not
be involved in that.

> on the Pi3 with USB root disk (hdd, not ssd).
>=20
> After reboot the machine answered around 30 % of incoming pings and
> sometimes responded to ssh login attempts. At least once the login
> attempt was successful, even with no outgoing ping process running.
> That seems like progress.
>=20
> With an outgoing ping running it's possible to ssh into the machine,
> with a highly variable delay for the password prompt.
>=20
> Unfortunately, new console errors are appeared:
>=20
> bob@pelorus:~ % (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 1f ea a3 =
c0 00 00 40 00=20
> (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
> (da0:umass-sim0:0:0:0): SCSI status: Check Condition
> (da0:umass-sim0:0:0:0): SCSI sense: ABORTED COMMAND asc:47,3 =
(Information unit iuCRC error detected)
> (da0:umass-sim0:0:0:0): Retrying command (per sense data)

Note that no USB drive would be involved in the type of
testing that I've asked for. This sort of issue would not
interfere with the proposed testing.

> The error message repeated at intervals, seemingly linked to disk =
activity,
> with the machine running out of retries after starting buildworld.=20
> That seems like progress in reverse 8-)

So you have bounds for a bisect to find where the USB
failures start happening on your RPi3, if you want to
investigate that.

> Reverting to 13-n249985-dd6c1475a63: Fri Mar 11 18:06:31 PST 2022
> permitted recovery, with the old problems attendant.
>=20
> -current now has some usb testing tools:
> root@www:/usr/src # ls tools/tools/usbtest
> Makefile		usb_control_ep_test.c	usb_msc_test.c		=
usbtest.c
> Makefile.depend		usb_modem_test.c	usb_msc_test.h		=
usbtest.h
>=20
> Is there any guidance on what they do? I couldn't find a man page.
>=20




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Mar 13 21:00:54 2022
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 661571A26BA1
	for ; Sun, 13 Mar 2022 21:00:56 +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 4KGsX65mjjz3DJ1
	for ; Sun, 13 Mar 2022 21:00:54 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 64B3D1FFE5
	for ; Sun, 13 Mar 2022 21:00:54 +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 22DL0sEw023656
	for ; Sun, 13 Mar 2022 21:00:54 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22DL0s5N023655
	for freebsd-arm@FreeBSD.org; Sun, 13 Mar 2022 21:00:54 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202203132100.22DL0s5N023655@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 Mar 2022 21:00:54 +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="16472052544.DDe8d2E.20832"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647205255;
	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=KwvR3IiBG/K7PD7yrY/7gFm78+xhFOIHmczkwfPr+FI=;
	b=k40dbBUQdDXxxVRYnwDXU63GllfyeXlnb1tGtJ6b1I1lsNCXjlOyMAY4gPPq9eMuUZQfPg
	H03CnLh+aw6NgtuTbvHDt5ELSE3YSI6USN6zEcMCekmZOKBMIzd/2hpUQCwi+fH2s+umwE
	YRekX+4ZxHvYm3k8skQxMG69Fyp6oqJJAUAq1KCbGv9ZxYCu36jIAV2/25keaQiDsw/dT2
	jY58XvxFYroSH1y+zApKQIETwN5z4ZZEFVVycO5wKaWwKV/H13EOxMd7yXeDUUAkdR1Ow+
	1ixkhKyyZ4lmszkj62jIcinvrq4yRDPhzu60YraQ2mBsEnW0VSulW0fVhBZxEw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647205255; a=rsa-sha256; cv=none;
	b=FPuFrdZc691CfsVscMz8PMYBGtVlSvS3LfQBCfUQFoj0EWOHjHjOsZ7smAMFQgWbN8Fce3
	2NeJRcr/NeMLe4CMYfg2DaJi2RoR+G4QMTge7texqgxdigqIbIol3SBb+p+KMWJI+DSfeO
	3E4A60SEYebPpSphAKJ4hSxEZ+M0Drj30up7y8hdLKBwcv1GnLMmvSSnZhJGXlnQnGqzaC
	3sjn7dz45YEZ6mBnw0yE0U7Qw/fuck+fwAF3vRlx5faJjUE8AfRmhFz+NzUXbQnJqWZKlm
	lcntfbBW2xM2dxUzKWaRUKg4zUZKHv0XeHld5NfUGBMJlym2195PmnZyG9KngQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1804
Lines: 38


--16472052544.DDe8d2E.20832
Date: Sun, 13 Mar 2022 21:00:54 +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.

--16472052544.DDe8d2E.20832
Date: Sun, 13 Mar 2022 21:00:54 +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.


--16472052544.DDe8d2E.20832--

From nobody Sun Mar 13 22:00:24 2022
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 054C61A15262
	for ; Sun, 13 Mar 2022 22:00:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KGts307dVz3Q7F
	for ; Sun, 13 Mar 2022 22:00:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647208830; bh=NIdg3FOIfdzhs/arlrkzwozAzcbEETOL4SVbbeJo4gk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XlOb3KSEG3BaneDERlEEE2Dxl+AITNzRN6LOHxtxsf/+gC7c7mnx4FB4A0Km3da3rSfOsRZ0jEKMI1kx75RfuiZegTYnHGh2Xn2KqlakvFWIR3/pHhTOl2Qi/DyEvneWsiDED+xUMgiPnFfg5PiWEUz4RPcon1WN5UMaXxFZ6RGFO1aNG4P4smU757HBHMJyXwANntPnaepY+HJgZPJvDGtje+D1+TyiVQ8jyfXnobNk5guUPT7TI/Hh9+47lpZRFB/nPlbrvM1RHEzoBiwrYKYtGWL6njUVGGnDPEQypU4eXO2goajfPcKA2ifLw735958SmFFX4C3QacdBOtdLXA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647208830; bh=l/JTAkxw5HCmFlEV0hChuSka+vNO/AFM/fBrDgXA/gF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JHfmxv9I5D3p2OqI4+58CTvq/Hytbg/uLD0tbc65qLMwTDkbJ1MxLitCgNwM+1+pk/O8HkTQU8FutzkXhpwkV4bZrJ1WRzwBfmq7YSglCF7zi1xliZmBooNqJo7W9n8x9IqZ+gbq3amPXLQCGXEjMgvFT6PbQjpLqYvoEB0x0DzmqRaqv010WjLXeacCqayAL7jUtO7w7jwv5yxpHfBsf2CcipOcThHnsgmR3Ir9+uVdmtc2jemu52hcBp5MEkcKR5K11kjTSD4BdL2e9z2f4jgVObonRAYTM88SiYItjJbZQoTD3uVfJXn7OoSctLIwdP+q5D//nTNM2ZX7xBSLJQ==
X-YMail-OSG: TzuZO3EVM1nXMJBXx04mNUpjGFC0VSYdtMgmVyaJ6O2pR21.cDeT9pqXVeL.hPd
 Db0HNWBQOPxC6GizxB.dbufTUbpf13uMPL0VvPK1aR2fFv9IkxU5BRGBf3sur7k8vPr7HjDEBoGU
 5kxfgpf1SWLo_y1KbIct16hlWazV0SXeCFM5a9Zh.bNYTJE0LuD8MOqv8tURpCq7SGrdaQ2VnZAw
 9fDv_x6kE5qp.dD_zpyDIvwKeYNNkwYlJSVW2Lt9XG7Ldnv4uIvYVEDK5I3lChWSBLdeEXB2H2XV
 AGc8I0agakl8msjPgRIJrUK6ZUdXBcUl86nJNHAxwWrHfJh9e2o0J7JSMcpg23zu9Nbbk_XMeX8p
 _Dg4.OpsVLW25bmsdraHD8Zt8k1K4VYjMIqiV3EuBwErdiAjp2v1uzAyBdrrvlwNmlXcO_oZGhSB
 PNVWIhuEIR_P2V5Vkc3J75qqAIVIufOhDFFnAaSmuyI5lKtljzKUJFu.RjmhE3LPgF5hW._ANAkw
 obtpxPK1xdCucPQS25B4RBl04YJ_K9jp.tdJnZy9L6l_e.FL3dYsWvle9cC9pQYc1YU3.olifOOe
 7B6d4WCW60fNiwrzxCb7SFCBiAoTHQCIkpu291ICaJNm5TkcaIsZsuxmVD1oM48XBqGPoQcpCjBc
 XLJj1mCViWMezj6eKr6WSg8hOgmiJULabKaA1QmNozqWthFQ61oo58UJaOM1KQClLci_pX952IKj
 zJcSSHacftgjINALgLhiZxjTv3VCrHCfh0w.FVVOR_J64vHzGvz8vpIhE1aU.LP.qSUI7ubcCOco
 .05pqnivVTVvMfGEZmAufII3q3Foap.yLpA1E6zyt5dLdRAFQxHwraLV.oFT_k2H97H4s3mZo0us
 p6zWb48s_mqUQc.uum1R9v.VwvCXEQ.U1Aq5vL4gA.y.J8hMfcloPD6C6xyP5PH4k.Sfa44vw6Pm
 .dq6rmR3fO10Le7wsVSlofrwTuNdGYs0EREujo.9WF9iYUJK0eqcryE.4f_0NReQ4K8YwzpPgG6q
 QdlMP6Kb_PcbTkAIsOTnIlxYYBm_8kEZfB3DHGIX7nfRUNq4h_LWWr67utym_iLUsk8DKoh.omTt
 4C9pY516ymJB5dQ6min.iVF.SnIOpPchBGhhWiDFOMXm04jNOa3KhqCl_JAnmOAuri_3ZSLUsQTi
 YWNHZRbq1sS8mJUCaGN3Kn.LhsLBRShu1VU3QqKonLS25BZSUOS_08wlEHiCnqkzISRHWWzo2dD8
 yeLBgJX6WVUOTt5dN5_Tex.AWWiqqc5fu53fo.thOa_Gas7ZcYfFxI85DV5DNZuEyFS5oh1g6FBn
 rMmyqioAqO3CEE6Mb_t_ZKR5yxhNWenQxzpo.kuQ3Zif0quLRqkuv16jSFss9ZOQ5YWaymYd02TV
 xu63uTSTKUwNLZTj1zpPvHLzV70s6TL74yBeZh31wAqZlfermTZbKZQIJyda06de9SQkMyhhXCqe
 EFmsFfqICDwZMFunxdhW9yfLk_b1SrwK9bcxfSF_.jJ9bGCQ7JtlV1hlIFQdlmwW82c552v39qhF
 BwlbaDtW1vPulOI0TKyQA0GOTzNYvs_.LdjWoAy9s5IAbMQMz3nuOX4Y_dMG.7AXBsjLTq1M9hKV
 fMQHQGaY57dm.bgqD3wjXeLBon2X.6qMY1QlaLK9gPhrnrJ4XGFZgRibOs11ck23QfrFnRbogvzJ
 Y_mZcrCjD5p5dPfEltMeo4EGPFwxcWJ8rVkJNe2NA6mIXIg.s9JIaRK4vbgs0rGoYha5bPAqm0Dj
 GCmHdCGfJWUcfXyggMaizN13_NFDh4k8dcEeXUktojJuz8IyvQmutZvCfQGbUu0U.9sASkObPKrv
 UApV6O93C_yZEsKNVRNwqtG1VRqn5uTXRnRm4If2CF8m8iaXUCLETm7QdEBirJ8lnE34VRM8LM04
 jc65jcLbGMyXI4miMFcsfoDnpGrDiozz9RDKav6G1yzWzUt0m4ZNanidX_ardvJ3mkJdgQXPkXlv
 StqAutYOxKAKWqKPwYdrujY9jFo.XabkemqTn3bahbotQKxmsU_3BOOdiIiQLLb.2noh7SN9R3hA
 dIePDUN0aJhlPje7DrTkxmP.wjsBMpDzC_Uyy9C9_v.1T3I.DHnqjlT4rdMK1nYjkmTewvF71g6.
 rIhPgsroMRCuxmcJ.8tk_aIy.aXz8v1uH8ITNIi4ofO6ZQD2YQLDDeT3Sa.FfDowOTd.n7hrQSkI
 2W69qYq85li52D.UJNewOGkZhM2.GzVvlki5X0BOQ2yuICKuJxZd_KoArYaTBA8y_XJc0qkUFWkh
 AAHBA0UEhjxouXZkm
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Mar 2022 22:00:30 +0000
Received: by kubenode508.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9692e48e657d1e80d63df3892fd2a0f6;
          Sun, 13 Mar 2022 22:00:26 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: 
Date: Sun, 13 Mar 2022 15:00:24 -0700
Cc: freebsd-net@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220212185618.GA37391@www.zefox.net>
 <34F5C092-7C35-4CBB-9CC3-99E373D1F785@yahoo.com>
 
 <20220215034924.GA46139@www.zefox.net>
 <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KGts307dVz3Q7F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=XlOb3KSE;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3065
Lines: 93

[The USB I/O problem.]

On 2022-Mar-13, at 13:46, Mark Millard  wrote:

>> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #24 =
stable/13-n249989-b85d0d603c5: Sat Mar 12 17:47:19 PST 2022    =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20
>> . . .
>>=20
>> Unfortunately, new console errors are appeared:
>>=20
>> bob@pelorus:~ % (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 1f ea =
a3 c0 00 00 40 00=20
>> (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
>> (da0:umass-sim0:0:0:0): SCSI status: Check Condition
>> (da0:umass-sim0:0:0:0): SCSI sense: ABORTED COMMAND asc:47,3 =
(Information unit iuCRC error detected)
>> (da0:umass-sim0:0:0:0): Retrying command (per sense data)

Quoting part of a forum reply:

QUOTE
That error translates to "INFORMATION UNIT iuCRC ERROR DETECTED" (cut =
and pasted from the SCSI standard), which means an error in data =
transmission between the disk and the controller, not an error on the =
disk.
END QUOTE

You report: stable/13-n249989-b85d0d603c5 shows the problem and
later that 13-n249985-dd6c1475a63 does not. That is odd because
the only stable/13 activity after dd6c1475a63 is (newer to older):

git: b85d0d603c57 - stable/13 - tslog.4: Document TSLOG Mateusz =
Piotrowski=20
git: 85379a47c4cb - stable/13 - time.3: Update ERRORS section Mateusz =
Piotrowski=20
git: 991c0e3ddb93 - stable/13 - ctime.3: Add a cross-reference to =
clock_gettime(2) Mateusz Piotrowski=20
git: bd2e56ef47d5 - stable/13 - zfs: merge openzfs/zfs_at_ef83e07db =
(zfs-2.1-release) into stable/13 Martin Matuska=20

In other words: updates to man pages and a zfs update.
As I understand, you do not use zfs.

The next commit back is the dd6c1475a63 that you report as working:

git: dd6c1475a63a - stable/13 - Add support for getting early entropy =
from UEFI Colin Percival=20

A possibility might be a poor connection that was later
reconnected (with better contact)? Brownout power
conditions?

It seems odd for zfs to be involved but man page changes
have no chance of being involved. It tends to suggest a
non-software issue at the time.

> . . .
>=20
>> The error message repeated at intervals, seemingly linked to disk =
activity,
>> with the machine running out of retries after starting buildworld.=20
>> That seems like progress in reverse 8-)
>=20
> So you have bounds for a bisect to find where the USB
> failures start happening on your RPi3, if you want to
> investigate that.

Looks like this idea was a bust, given the narrow range
and the content involved in that range.

>> Reverting to 13-n249985-dd6c1475a63: Fri Mar 11 18:06:31 PST 2022
>> permitted recovery, with the old problems attendant.
>>=20
>> -current now has some usb testing tools:
>> root@www:/usr/src # ls tools/tools/usbtest
>> Makefile		usb_control_ep_test.c	usb_msc_test.c		=
usbtest.c
>> Makefile.depend		usb_modem_test.c	usb_msc_test.h		=
usbtest.h
>>=20
>> Is there any guidance on what they do? I couldn't find a man page.
>>=20
>=20
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar 14 09:20:30 2022
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 46DE41A0E616
	for ; Mon, 14 Mar 2022 09:20:43 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 4KH9xj6jMnz4T2P
	for ; Mon, 14 Mar 2022 09:20:41 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x631.google.com with SMTP id gb39so32233763ejc.1
        for ; Mon, 14 Mar 2022 02:20:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=N9saEovwrUAc3JGGd8JqXR1nvr+GbId0s9p0hqnEzKo=;
        b=aLG1aFkgIanHMuaPffQvItCE2RgZBNRNEIPVe9ABFwLNJ13m9ilk8FpEk+nQ4A5wfp
         PJP76Brbh9GChTjowaPKghtBAMUqctsAqpxSYunmtgVs9OUPPBmKaM3utI+TtmNMsXv2
         4OBby/NqoC7OwlEjYO1lr9o0k5n9xeFWL7vBGS6S6sqTsaYBldah1ei32fTVeFilFXyF
         xnkd6TrpCMy/7g7AtTeVsh8RztI+OV6WkoQgj29B2+D/WM8JzYc66mEMRtV20gB6x8zS
         0IHIHb6LK8HokBU2LRQAuErdNSIRceh/87wmERhh9zxMOM0dfPVke68iy0IV292hDjtk
         uasw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=N9saEovwrUAc3JGGd8JqXR1nvr+GbId0s9p0hqnEzKo=;
        b=kK+ivNy/XJdPYAyVUUpw51HmaQ83b1gNm2MTbs1dgZ/XFWyxEO2omRAIinLLdS3LPw
         HYEiGR7yD1tq2yw9QZQJQ5MObaKyjwbb7sSzFEfllDoM0o9SyyGQwJjsDOC0zRFw5wIe
         dS0drmf8gcRkXu6mmf0jEd1dRrfvlk9mtQnKxkzb+Brc7kSw6kL1SvIKKaCDxuJQuxPk
         dxIYjAcCeoY5d/3c+2nGemtNtBAZWDqo1f+xWiNpKDIWLZ6bWOkYFWUMZOY8W4xbdHtM
         38tXuvd9jitDoC418l12ML373vLLRvYPFvtq2r3+mhXMwWGoQwY/UTo8nIPYlYnlwq4W
         g4vg==
X-Gm-Message-State: AOAM532Szbk8pQZNOJgyJ/lhBrSjv3hnLewQl/rd9UsPLYcEwe20vS+c
	Zrbqlr9ihyTcuUFtxcSQvfxw9KCetWkyL1lXu8OH+SLOCjq5Tg==
X-Google-Smtp-Source: ABdhPJwWx3GoogLxiuhWOB7+FkL6+d3sdJrmngUZnu1JkaUorLBP1A2R8cKh1hncGUVrUx5QS/bIMZEjA1hksFb5Gwc=
X-Received: by 2002:a17:906:730c:b0:6d6:f8f2:fb92 with SMTP id
 di12-20020a170906730c00b006d6f8f2fb92mr17012599ejc.370.1647249640616; Mon, 14
 Mar 2022 02:20:40 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Mon, 14 Mar 2022 17:20:30 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/mixed; boundary="000000000000af8e8e05da2a316c"
X-Rspamd-Queue-Id: 4KH9xj6jMnz4T2P
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=aLG1aFkg;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [0.09 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 HAS_ATTACHMENT(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 CTYPE_MIXED_BOGUS(1.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.98)[0.982];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 78206
Lines: 1124

--000000000000af8e8e05da2a316c
Content-Type: multipart/alternative; boundary="000000000000af8e8a05da2a316a"

--000000000000af8e8a05da2a316a
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky 
>> wrote:
>>
>>> On 3/12/22 16:31, Archimedes Gaviola wrote:
>>> >>
>>> >> IOERROR usually means an electrical error. The RPI3B will use a
>>> >> transaction translator for the FULL speed traffic, which is driven by
>>> >> software.
>>> >
>>>
>>> Hi Archimedes,
>>>
>>> > Hi Hans,
>>> >
>>> > I'm curious about the transaction translator you've mentioned, any
>>> idea why
>>> > there's a need for translation and what is being translated?
>>>
>>> When the High Speed USB HUB was invented, there was a need to support
>>> FULL and LOW speed USB transactions. Because FULL and LOW speed
>>> transactions are slow and take up much bandwidth, a transactions
>>> translator was invented which translates between High Speed USB and
>>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH
>>> speed port, followed by a USB HUB. These transactions are not visible in
>>> usbdump .
>>>
>>>  >Does this only
>>> > happen when RPi 3B (acting as host controller) is transmitting data to
>>> the
>>> > Epson printer? Are translation events visible in the usbdump? In this
>>> case
>>> > there's a way to possibly track what's going on and how to identify any
>>> > info that is being translated?
>>>
>>> By turning on the HC debugging, you can possibly track via debug
>>> messages what is going on. Maybe it is a timing issue, that the SW is
>>> too slow serving the micro transactions.
>>>
>>> Any idea also if translation is being
>>> > performed in RPi 4B?
>>>
>>> The later RPi's do the transaction translator bits in HW or via the XHCI
>>> block.
>>>
>>> As I have conducted several printing cases with my
>>> > Epson printer without any issues with either of the 4 ports.
>>> >
>>> > Sorry for these questions as I am catching-up to the USB technology
>>> > internal workings under the hood.
>>>
>>> You are welcome!
>>>
>>
>>
>> Thank you so much Hans for answering my questions, really appreciate it!
>> I have a much better understanding now.
>>
>> I came from testing with 13.0-RELEASE having the same RPi 3B hardware and
>> setup and it's very stable. I haven't encountered any IOERROR and
>> incomplete printed outputs that were encountered with 14.0-CURRENT
>> (February 24, 2022). By the way, I found in the repository here
>> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
>> that there were two latest snapshots released dated March 3 and March 10,
>> respectively. I need to take printing tests first, especially the latest to
>> check if it also manifests before I go back to the Feb. 24 snapshot and do
>> a thorough test with debugging. I'll provide updates for any observations.
>>
>> Thanks,
>> Archimedes
>>
>
>
> Hi Hans,
>
> Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
> snapshot) seems to be stable. Another test will be performed tomorrow.
>
> Thanks,
> Archimedes
>

Hi Hans,

I still encountered the issue this morning with 14.0-CURRENT (March 10,
2022 snapshot). I just noticed when I left my RPi 3B idle for a long period
of time (2-3 hours and more) and started printing, then the issue pops-up.
Another concern I encountered was when I started enabling
hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network
interface (remotely connected over SSH from my laptop) seemed to freeze and
I got disconnected.

freebsd@generic:~ % uname -a
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64

root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=1
hw.usb.dwc_otg.debug: 0 -> 1

See attached initial debug info (no printing testing yet).

Thanks,
Archimedes

--000000000000af8e8a05da2a316a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Mar 13, 2022 at 11:25 PM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:


On Sun, Mar 13, 2=
022 at 2:27 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div dir=3D"ltr">

On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky &l=
t;hps@selasky.org&=
gt; wrote:
On 3/=
12/22 16:31, Archimedes Gaviola wrote:

>>

>> IOERROR usually means an electrical error. The RPI3B will use a
>> transaction translator for the FULL speed traffic, which is driven=
 by

>> software.

> 



Hi Archimedes,



> Hi Hans,

> 

> I'm curious about the transaction translator you've mentioned,=
 any idea why

> there's a need for translation and what is being translated? 



When the High Speed USB HUB was invented, there was a need to support 

FULL and LOW speed USB transactions. Because FULL and LOW speed 

transactions are slow and take up much bandwidth, a transactions 

translator was invented which translates between High Speed USB and 

FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH 
speed port, followed by a USB HUB. These transactions are not visible in 
usbdump .



=C2=A0>Does this only

> happen when RPi 3B (acting as host controller) is transmitting data to=
 the

> Epson printer? Are translation events visible in the usbdump? In this =
case

> there's a way to possibly track what's going on and how to ide=
ntify any

> info that is being translated? 



By turning on the HC debugging, you can possibly track via debug 

messages what is going on. Maybe it is a timing issue, that the SW is 

too slow serving the micro transactions.



Any idea also if translation is being

> performed in RPi 4B? 



The later RPi's do the transaction translator bits in HW or via the XHC=
I 

block.



As I have conducted several printing cases with my

> Epson printer without any issues with either of the 4 ports.

> 

> Sorry for these questions as I am catching-up to the USB technology
> internal workings under the hood.



You are welcome!


Thank you so much Hans for answering my questions, really appreci=
ate it! I have a much better understanding now.

I came from testing with 13.0=
-RELEASE having the same RPi 3B hardware and setup and it's very stable=
. I haven't encountered any IOERROR and incomplete printed outputs that=
 were encountered with 14.0-CURRENT (February 24, 2022). By the way, I foun=
d in the repository here https://download.freebsd.=
org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/ that there were two latest=
 snapshots released dated March 3 and March 10, respectively. I need to tak=
e printing tests first, especially the latest to check if it also manifests=
 before I go back to the Feb. 24 snapshot and do a thorough test with debug=
ging. I'll provide updates for any observations.

Thanks,
Archimedes
=



Hi Hans,

Initial testing conducted with the latest 14.0-CURRENT (March 10, 20=
22 snapshot) seems to be stable. Another test will be performed tomorrow.

Thanks,
Archimedes

Hi Hans,

I still encountered the issue this morning with 14.0-CURRENT=20
(March 10, 2022 snapshot). I just noticed when I left my RPi 3B idle for a =
long period of time (2-3 hours and more) and started printing, then the iss=
ue pops-up. Another concern I encountered was when I started enabling=20
hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network inte=
rface (remotely connected over SSH from my laptop) seemed to freeze and I g=
ot disconnected.

freebsd@generic:~ % uname -a
F=
reeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n253697-f1d450ddee=
6: Thu Mar 10 09:32:38 UTC 2022 =C2=A0 =C2=A0 root@releng1.nyi.freebsd.org:=
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

r=
oot@generic:~ # sysctl -w hw.usb.dwc_otg.debug=3D1
hw.usb.dwc_otg.debug:=
 0 -> 1

See attached initial debug info (no pri=
nting testing yet).

Thanks,
Archimed=
es
=C2=A0




--000000000000af8e8a05da2a316a--
--000000000000af8e8e05da2a316c
Content-Type: text/plain; charset="US-ASCII"; 
	name="freebsd14_current_rpi3b_dwc_otg_debug_info.txt"
Content-Disposition: attachment; 
	filename="freebsd14_current_rpi3b_dwc_otg_debug_info.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_l0qfm7ny0

ZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0w
eDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1
YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQ
TFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAw
MDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3Rf
Y2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhh
bHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2Nr
ZWQ6IFJlYWRpbmcgNzIgYnl0ZXMgZnJvbSBlcCAxDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9
MSBTVD0xIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4ODAwMDAx
YjgNCmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwNDgx
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX3RpbWVyOg0KZHdjX290Z19o
b3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODEyMDAgSENTUExUPTB4MDAwMDAw
MDANCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NI
QVI9MHgwMGM4MTIwMCBIQ1RTSVo9MHg0MDAwMDA4ZQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJl
ZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgw
Yzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0x
IEhDSU5UPTB4MDAwMDAwMDAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4MDAwODAyMDANCmR3
Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4
MGM4OGEwMCBIQ1RTSVo9MHgwMDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgw
YzgxMjAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDog
UmVhZGluZyA3MiBieXRlcyBmcm9tIGVwIDENCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNU
PTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHhjMDAwMDFiOA0K
ZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNDA0ODENCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0yIFNU
PTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGM4MTIwMCBIQ1RTSVo9MHgwMDAwMDA3ZQ0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgxNDI4ODA4IEhDU1BMVD0weDgwMDEwMTA1DQpkd2Nfb3Rn
X2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0yIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODE0Mjg4
MDggSENUU0laPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0w
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAw
MDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyA3MiBieXRlcyBm
cm9tIGVwIDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAy
MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg4MDAwMDFiOA0KZHdjX290Z19ob3N0X2RhdGFf
cnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTA0ODANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBj
aGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzgx
MjAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MCBTVD0xIEhD
SU5UPTB4MDAwMDAwMDAgSENDSEFSPTB4MDBjODEyMDAgSENUU0laPTB4NDAwMDAwOGUNCmR3Y19v
dGdfaG9zdF9kYXRhX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGM4
MTIwMCBIQ1RTSVo9MHg0MDAwMDA4ZQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENI
PTANCmR3Y19vdGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NI
QVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxs
b2M6IENIPTEgSENDSEFSPTB4ODA4MDAwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50
ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDcyIGJ5dGVzIGZyb20gZXAgMA0KZHdjX290Z19o
b3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzg4YTAw
IEhDVFNJWj0weGMwMDAwMWI4DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBT
VEFUVVM9MHgwMDA0MDQ4MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19o
b3N0X3NldHVwX3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0
MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTEN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwODAwMDQwIEhDU1BM
VD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyAwIGJ5
dGVzIGZyb20gZXAgMQ0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAw
MDAwMDIwIEhDQ0hBUj0weDgwODA4MDQwIEhDVFNJWj0weDgwMDAwMDQwDQpkd2Nfb3RnX2hvc3Rf
ZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDAwMQ0KZHdjX290Z19ob3N0X2No
YW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0
aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19v
dGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MTQy
MDAwOCBIQ1NQTFQ9MHg4MDAwMDEwNQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEg
SENDSEFSPTB4ODA5MDg4MDEgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3Rn
X2hvc3Rfc2V0dXBfdHg6IENIPTAgU1Q9MiBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgxNDIw
MDA4IEhDVFNJWj0weDYwMDgwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9
MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nf
b3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODA5
MDg4MDEgSENUU0laPTB4NDAwODAwMDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBD
SD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3
Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4
MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMg0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTMgSENDSEFSPTB4ODBjODhhMDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MyBT
VD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0zDQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDMNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9j
OiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3Rf
ZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENU
U0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nf
b3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAw
DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFS
PTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVf
c3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVs
IDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhD
U1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9
MHg4MDgwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAg
U1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0
X3NldHVwX3R4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBI
Q1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwODAwMDQwIEhDU1BMVD0w
eDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyAwIGJ5dGVz
IGZyb20gZXAgMg0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAw
MDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRp
bmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4
MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTIgU1Q9
MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwODA4MDQwIEhDVFNJWj0weDgwMDAwMDQwDQpk
d2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDAwMg0KZHdj
X290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2Zy
ZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMg0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9
MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX3RpbWVyOg0KZHdjX290Z19ob3N0
X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwg
MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENT
UExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgw
MDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBI
YWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFS
PTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0w
IFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIw
MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxs
b2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9z
dF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBI
Q1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19o
b3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAw
MDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NI
QVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENI
PTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgw
MjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2No
YW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9h
bGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19o
b3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAw
IEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAw
MDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhD
Q0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hh
bm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lO
VD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6
IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQw
MDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290
Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDAwIEhDQ0hBUj0weDgwYzg4
YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhD
SU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0w
IEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9y
eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4
NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nf
b3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBj
ODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBD
SD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0w
eDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAw
MTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGlu
ZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgw
Yzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0x
IEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBD
SD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0
YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0la
PTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MTQyMDAwOCBIQ1NQTFQ9
MHg4MDAwMDEwNQ0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAw
MDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRp
bmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4
MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0wIFNU
PTIgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MTQyMDAwOCBIQ1RTSVo9MHg2MDA4MDAwOA0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTIg
U1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z190aW1l
cjoNCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NI
QVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJl
ZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5u
ZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAg
SENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9
MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSEND
SEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBD
SD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4
MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxf
YWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNo
YW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhh
MDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJ
TlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVf
c3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEg
SENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwODAwMDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3Rn
X2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhh
MDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0x
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAw
MDAwMDAwDQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDIx
IEhDQ0hBUj0weDAwODAwMDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTIgSENDSEFS
PTB4ODA4MDAwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9j
a2VkOiBSZWFkaW5nIDAgYnl0ZXMgZnJvbSBlcCAyDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9
MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAy
MDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2Fs
bG9jOiBDSD0xIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hv
c3RfZGF0YV9yeDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODA4MDgwNDAg
SENUU0laPTB4ODAwMDAwNDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNU
QVRVUz0weDAwMDUwMDAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdj
X290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9hbGxvYzogQ0g9MyBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAw
MA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hB
Uj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5l
bCAxDQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhD
Q0hBUj0weDAwYzAwMDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogQ0g9Mw0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4
ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2Vk
OiBSZWFkaW5nIDQgYnl0ZXMgZnJvbSBlcCAwDQpkd2Nfb3RnX3RpbWVyOg0KZHdjX290Z19ob3N0
X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9
MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBE
QVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BM
VD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAw
MDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFs
dGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0yIFNUPTEgSENJTlQ9MHgw
MDAwMDAwMCBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9
MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IENIPTINCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAx
MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5n
IGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBj
ODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEg
SENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdj
X290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2Zy
ZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENI
PTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRh
X3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9
MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2No
YW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3
Y19vdGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAw
MDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFs
dGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0w
eDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzog
Q0g9MiBIQ0NIQVI9MHg4MGMwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2Rh
dGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJ
Wj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3Rf
Y2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0K
ZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9
MHgwMGMwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwYzAw
MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhD
SU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0w
IEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90
eDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4
MDAwMDAwMDQNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4MGMwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAw
MA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcgMCBieXRlcyBmcm9tIGVw
IDINCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NI
QVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJl
ZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5u
ZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAg
SENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0yIFNUPTEgSENJTlQ9
MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDA0MA0KZHdjX290Z19o
b3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwMDINCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1Yjog
SGFsdGluZyBjaGFubmVsIDINCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9
MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSEND
SEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBD
SD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4
MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
YWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTEN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z190aW1lcjoNCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0x
IEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODE0MjAwMDggSENTUExUPTB4ODAw
MDAxMDUNCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNo
YW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTMgSENDSEFSPTB4ODBjODhh
MDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9zZXR1cF90eDogQ0g9MiBTVD0xIEhD
SU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4MjAwMDAwMDgNCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MiBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRl
cnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcgNCBieXRlcyBmcm9tIGVwIDINCmR3Y19vdGdfaG9z
dF9zZXR1cF90eDogQ0g9MCBTVD0yIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODE0MjAwMDgg
SENUU0laPTB4NjAwODAwMDgNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0zIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTMN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMw0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBI
Q0NIQVI9MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0X2RhdGFfcnhf
c3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2Zy
ZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFu
bmVsIDINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD00IEhDQ0hBUj0weDgwYzA4MDQw
IEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5U
PTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1
YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD00IFNUPTEgSENJ
TlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTQNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9j
OiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3Rf
Y2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MDgwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0K
ZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0w
eDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1
YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQ
TFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgw
MDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0x
IEhDQ0hBUj0weDgwODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9w
b2xsX2xvY2tlZDogUmVhZGluZyA0IGJ5dGVzIGZyb20gZXAgMQ0KZHdjX290Z190aW1lcjoNCmR3
Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4
MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMg0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAw
MDAyMCBIQ0NIQVI9MHg4MDgwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0X2Rh
dGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDENCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGlu
ZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0zIEhDQ0hBUj0weDgw
ODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9
NCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFf
cng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0w
eDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfZGF0
YV90eDogQ0g9MyBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDA4MDAwNDAgSENUU0la
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0zDQpkd2Nfb3Rn
X2hvc3Rfc2V0dXBfdHg6IENIPTQgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwYzAw
MDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9
NA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjMDgwNDAgSENT
UExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDQg
Ynl0ZXMgZnJvbSBlcCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEg
U1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzA4MDQwIEhDVFNJWj0weDgwMDAwMDNj
DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDA0MQ0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6
IENIPTIgSENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9k
YXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RT
SVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0
X2RhdGFfdHg6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDAwIEhDQ0hBUj0weDAwYzAwMDQwIEhD
VFNJWj0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfdHg6IENIPTIg
U1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwYzAwMDQwIEhDVFNJWj0weDAwMDAwMDAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODA4MDAwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgxNDIwMDA4IEhDU1BMVD0weDgw
MDAwMTA1DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAg
SENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBj
aGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0zIEhDQ0hBUj0weDgwYzg4
YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTEgU1Q9MSBI
Q0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwODAwMDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nf
b3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxs
b2M6IENIPTEgSENDSEFSPTB4ODA4MDAwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfdGlt
ZXI6DQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyAwIGJ5dGVzIGZyb20g
ZXAgMQ0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0yIFNUPTIgSENJTlQ9MHgwMDAwMDAyMCBI
Q0NIQVI9MHg4MTQyMDAwOCBIQ1RTSVo9MHg2MDA4MDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNo
YW5uZWwgMg0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDEw
IEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9mcmVlX3N1YjogQ0g9Mw0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcg
Y2hhbm5lbCAzDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGM4
OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBI
Q0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwODA4MDQwIEhDVFNJWj0weDgwMDAwMDQwDQpkd2Nf
b3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDAwMQ0KZHdjX290
Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVf
c3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTQg
SENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4
OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0
MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X3NldHVw
X3R4OiBDSD00IFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9
MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTQNCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAw
MDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyA0IGJ5dGVzIGZyb20g
ZXAgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAg
SENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9
MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19o
b3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDENCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1Yjog
SGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hB
Uj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9
MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAy
MDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBD
SD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAw
MDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAg
SENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0yIFNUPTEgSENJTlQ9
MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBD
SD0xIEhDQ0hBUj0weDgwODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0
YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0la
PTB4NDAwODAyMDANCmR3Y19vdGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1
YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQ
TFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgw
MDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0x
IEhDQ0hBUj0weDgwODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9w
b2xsX2xvY2tlZDogUmVhZGluZyA0IGJ5dGVzIGZyb20gZXAgMQ0KZHdjX290Z19ob3N0X2RhdGFf
cng6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0w
eDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdj
X290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgw
ODA4MDQwIEhDVFNJWj0weDgwMDAwMDNjDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEg
U1Q9MSBTVEFUVVM9MHgwMDA1MDA0MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENI
PTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdj
X290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTMgSENDSEFSPTB4ODA4MDgwNDAgSENTUExUPTB4
MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAx
MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5n
IGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2RhdGFfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAw
MDIxIEhDQ0hBUj0weDAwODAwMDQwIEhDVFNJWj0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9Mw0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSEND
SEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBD
SD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4
MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
YWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTEN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNo
YW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhh
MDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhD
Q0hBUj0weDgwODAwMDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDog
Q0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAw
ODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3Rf
Y2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3Rn
X2hvc3Rfc2V0dXBfdHg6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwODAw
MDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9
Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTIgSENDSEFSPTB4ODA4MDAwNDAgSENT
UExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDAg
Ynl0ZXMgZnJvbSBlcCAyDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4
MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1Yjog
SGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hB
Uj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9
MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODA4MDgwNDAgSENUU0laPTB4ODAwMDAw
NDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDAy
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MyBIQ0NIQVI9MHg4MGMwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0
X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhD
VFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdj
X290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hv
c3Rfc2V0dXBfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwYzAwMDQw
IEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mw0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjMDAwNDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgw
Yzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX3RpbWVyOg0KZHdjX290Z19ob3N0X2Rh
dGFfdHg6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwYzAwMDQwIEhDVFNJ
Wj0weDAwMDAwMDA0DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjMDAwNDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDAgYnl0ZXMgZnJv
bSBlcCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4MTQyMDAw
OCBIQ1NQTFQ9MHg4MDAwMDEwNQ0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lO
VD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MyBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6
IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzA4MDQwIEhDVFNJWj0weDgw
MDAwMDQwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1
MDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X3NldHVwX3R4
OiBDSD0yIFNUPTIgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MTQyMDAwOCBIQ1RTSVo9MHg2
MDA4MDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMg0KZHdjX290Z19ob3N0X2RhdGFf
cng6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0w
eDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mw0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAzDQpkd2Nfb3RnX3RpbWVyOg0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgw
ODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0x
IEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBD
SD0yIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3Rfc2V0
dXBfdHg6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwODAwMDQwIEhDVFNJ
Wj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290
Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODA4MDgwNDAgSENTUExUPTB4MDAw
MDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDQgYnl0ZXMgZnJv
bSBlcCAxDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMTAg
SENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBj
aGFubmVsIDINCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4
YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhD
SU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODA4MDgwNDAgSENUU0laPTB4ODAwMDAwM2MNCmR3Y19v
dGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDQxDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MyBI
Q0NIQVI9MHg4MDgwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxf
YWxsb2M6IENIPTQgSENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290
Z19ob3N0X2RhdGFfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwODAw
MDQwIEhDVFNJWj0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9
Mw0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD00IFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NI
QVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJl
ZV9zdWI6IENIPTQNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgw
YzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDog
UmVhZGluZyA0IGJ5dGVzIGZyb20gZXAgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENI
PTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRh
X3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1RTSVo9
MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4
MDAwNTAwNDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nf
b3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBj
ODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBD
SD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3
Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHgw
MGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290Z190aW1lcjoNCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpk
d2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4
MDBjMDAwNDAgSENUU0laPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MDgwMDA0
MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lO
VD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4
OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBIQ1RTSVo9MHgy
MDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwODAwMDQwIEhDU1BMVD0weDAwMDAwMDAw
DQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyAwIGJ5dGVzIGZyb20gZXAg
MQ0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hB
Uj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5l
bCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGM4OGEwMCBI
Q1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0w
eDAwMDAwMDIwIEhDQ0hBUj0weDgwODA4MDQwIEhDVFNJWj0weDgwMDAwMDQwDQpkd2Nfb3RnX2hv
c3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDAwMQ0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBI
YWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0w
eDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NI
QVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxs
b2M6IENIPTEgSENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50
ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDEzMCBieXRlcyBmcm9tIGVwIDANCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHg4MDAwMDE3ZQ0KZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEg
U1RBVFVTPTB4MDAwNTA4MjANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdf
aG9zdF9zZXR1cF90eDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjMDAw
NDAgSENUU0laPTB4MjAwMDAwMDgNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0x
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQ
TFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcgNCBi
eXRlcyBmcm9tIGVwIDENCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgw
MDAwMDAyMCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0
X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDENCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFs
dGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0w
eDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MCBT
VD0xIEhDSU5UPTB4MDAwMDAwMDAgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4MDAwMDAwMDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9
MHgwMGMwMDA0MCBIQ1RTSVo9MHgwMDAwMDAwMA0KZHdjX290Z190aW1lcjoNCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9
MCBIQ0NIQVI9MHg4MDgwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVw
X3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBIQ1RTSVo9
MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwODA4MDQwIEhDU1BMVD0weDAwMDAw
MDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBI
Q1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcg
NCBieXRlcyBmcm9tIGVwIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hB
Uj0weDgxNDIwMDA4IEhDU1BMVD0weDgwMDAwMTA1DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9
MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODA4MDgwNDAgSENUU0laPTB4ODAwMDAw
M2MNCmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDQw
DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MyBIQ0NIQVI9MHg4MDgwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0
X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzg4YTAwIEhD
VFNJWj0weGMwMDAwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9NCBIQ0NIQVI9
MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2Nr
ZWQ6IFJlYWRpbmcgMTMwIGJ5dGVzIGZyb20gZXAgMQ0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBD
SD0yIFNUPTIgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MTQyMDAwOCBIQ1RTSVo9MHg2MDA4
MDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTINCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMg0KZHdjX290Z19ob3N0X2RhdGFfdHg6
IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwODAwMDQwIEhDVFNJWj0weDAw
MDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mw0KZHdjX290Z19ob3N0
X2RhdGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzg4YTAwIEhD
VFNJWj0weGMwMDAwMTdlDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFU
VVM9MHgwMDA0MDgyMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0
X3NldHVwX3R4OiBDSD00IFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHgwMGMwMDA0MCBI
Q1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD00IFNUPTEgSENJTlQ9
MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19o
b3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTQNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBD
SD0wIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX3RpbWVyOg0K
ZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcgNCBieXRlcyBmcm9tIGVwIDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9
MHg4MGMwODA0MCBIQ1RTSVo9MHg4MDAwMDAzYw0KZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBE
QVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwNDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BM
VD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MiBIQ0NIQVI9MHg4
MGM4MTIwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfdHg6IENIPTEgU1Q9
MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0weDAwYzAwMDQwIEhDVFNJWj0weDAwMDAwMDAwDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2RhdGFfdHg6
IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDAwIEhDQ0hBUj0weDAwYzgxMjAwIEhDVFNJWj0weDAw
MDAwMDdlDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjEg
SENDSEFSPTB4MDBjODEyMDAgSENUU0laPTB4MDAwMDAwN2UNCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAg
U1Q9MSBIQ0lOVD0weDAwMDAwMDAwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAw
DQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyA1MTIgYnl0ZXMgZnJvbSBl
cCAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjAgSEND
SEFSPTB4ODBjODhhMDAgSENUU0laPTB4ODAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1
YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUyMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5l
bCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBI
Q1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcg
MTAgYnl0ZXMgZnJvbSBlcCAxDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5U
PTB4MDAwMDAwMjAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4YzAwMDAxZjYNCmR3Y19vdGdf
aG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDQwMGExDQpkd2Nfb3RnX2hv
c3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NI
QVI9MHg4MDgwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBD
SD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMDgwMDA0MCBIQ1RTSVo9MHgyMDAw
MDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9j
aGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwODAwMDQwIEhDU1BMVD0weDAwMDAwMDAwDQpk
d2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyAwIGJ5dGVzIGZyb20gZXAgMA0K
ZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0w
eDgwODA4MDQwIEhDVFNJWj0weDgwMDAwMDQwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERB
VEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6
IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAw
MDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2No
YW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0
aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4
ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNU
PTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6
IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9k
YXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RT
SVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDAN
CmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAxMCBIQ0NIQVI9
MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwg
MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENT
UExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgw
MDAwMDAxMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0
X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBI
YWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFS
PTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9j
OiBDSD0yIEhDQ0hBUj0weDgwODA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3Rf
ZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMTAgSENDSEFSPTB4ODBjODhhMDAgSENU
U0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nf
b3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDENCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAw
DQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTIgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hB
Uj0weDAwODAwMDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTIgSENDSEFSPTB4ODA4
MDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBS
ZWFkaW5nIDEzMCBieXRlcyBmcm9tIGVwIDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNU
PTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9MHg4MDAwMDE3ZQ0K
ZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTA4MjANCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9m
cmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0yIFNU
PTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MDgwODA0MCBIQ1RTSVo9MHg4MDAwMDA0MA0K
ZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjMDAwNDAgSENTUExU
PTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDQgYnl0
ZXMgZnJvbSBlcCAyDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAw
MDAwMjAgSENDSEFSPTB4ODA4MDgwNDAgSENUU0laPTB4ODAwMDAwM2MNCmR3Y19vdGdfaG9zdF9k
YXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDQyDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRp
bmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MyBIQ0NIQVI9MHg4
MDgwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0xIFNU
PTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0K
ZHdjX290Z19ob3N0X2RhdGFfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hBUj0w
eDAwODAwMDQwIEhDVFNJWj0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1
YjogQ0g9Mw0KZHdjX290Z19ob3N0X3NldHVwX3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAy
MSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hB
Uj0weDgwYzAwMDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9
MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4MDAwMDAw
MDQNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGMwMDA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdj
X290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTEgSENDSEFSPTB4ODBjODEyMDAgSENTUExUPTB4
MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDAgYnl0ZXMg
ZnJvbSBlcCAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAw
MjAgSENDSEFSPTB4ODBjMDgwNDAgSENUU0laPTB4ODAwMDAwNDANCmR3Y19vdGdfaG9zdF9kYXRh
X3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5l
bF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcg
Y2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAw
MDAgSENDSEFSPTB4MDBjODEyMDAgSENUU0laPTB4NDAwMDAwN2UNCmR3Y19vdGdfaG9zdF9kYXRh
X3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGM4MTIwMCBIQ1RTSVo9
MHg0MDAwMDA3ZQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzgxMjAwIEhDU1BMVD0weDAwMDAw
MDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSEND
SEFSPTB4MDBjODEyMDAgSENUU0laPTB4MDAwMDAwNGENCmR3Y19vdGdfdGltZXI6DQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6
IENIPTAgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJy
dXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDE0NCBieXRlcyBmcm9tIGVwIDANCmR3Y19vdGdfaG9z
dF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MGM4OGEwMCBI
Q1RTSVo9MHhjMDAwMDE3MA0KZHdjX290Z19ob3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RB
VFVTPTB4MDAwNDA5MDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nf
b3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAw
DQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDIxIEhDQ0hB
Uj0weDAwYzAwMDQwIEhDVFNJWj0weDIwMDAwMDA4DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVl
X3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODBj
MDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBS
ZWFkaW5nIDQgYnl0ZXMgZnJvbSBlcCAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0x
IEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODBjMDgwNDAgSENUU0laPTB4ODAwMDAwM2MNCmR3
Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDQwDQpkd2Nf
b3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJl
ZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9
MSBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2RhdGFf
dHg6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDAwIEhDQ0hBUj0weDAwYzAwMDQwIEhDVFNJWj0w
eDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAw
MjEgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4MDAwMDAwMDANCmR3Y19vdGdfdGltZXI6DQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxf
YWxsb2M6IENIPTAgSENDSEFSPTB4ODBjODEyMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdf
aG9zdF9kYXRhX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGM4MTIw
MCBIQ1RTSVo9MHg0MDAwMDA3ZQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTAN
CmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzgxMjAwIEhDU1BM
VD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAw
MDAwMDAgSENDSEFSPTB4MDBjODEyMDAgSENUU0laPTB4MDAwMDAwN2UNCmR3Y19vdGdfaG9zdF9k
YXRhX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGM4MTIwMCBIQ1RT
SVo9MHgwMDAwMDA3ZQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzgxMjAwIEhDU1BMVD0weDAw
MDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV90eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMDAg
SENDSEFSPTB4MDBjODEyMDAgSENUU0laPTB4NDAwMDAwN2UNCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgwYzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3Rn
X2hvc3RfZGF0YV90eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjODEy
MDAgSENUU0laPTB4NDAwMDAwN2UNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0w
DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAwMDAgSENDSEFS
PTB4ODBjODhhMDAgSENUU0laPTB4ODAwMDAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVf
c3ViOiBDSD0wDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVhZGluZyA3MiBieXRl
cyBmcm9tIGVwIDENCmR3Y19vdGdfdGltZXI6DQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzog
Q0g9MCBIQ0NIQVI9MHg4MTQyMDAwOCBIQ1NQTFQ9MHg4MDAwMDEwNQ0KZHdjX290Z19ob3N0X2Rh
dGFfcng6IENIPTEgU1Q9MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJ
Wj0weDgwMDAwMWI4DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9
MHgwMDA1MDQ4MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdf
aG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMQ0KZHdjX290Z19ob3N0X2No
YW5uZWxfYWxsb2M6IENIPTIgSENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3
Y19vdGdfaG9zdF9zZXR1cF90eDogQ0g9MCBTVD0yIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4
ODE0MjAwMDggSENUU0laPTB4NjAwODAwMDgNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3Vi
OiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBjaGFubmVsIDAN
CmR3Y19vdGdfaG9zdF9zZXR1cF90eDogQ0g9MiBTVD0xIEhDSU5UPTB4MDAwMDAwMDAgSENDSEFS
PTB4MDBjMDAwNDAgSENUU0laPTB4MjAwMDAwMDgNCmR3Y19vdGdfaG9zdF9zZXR1cF90eDogQ0g9
MiBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDBjMDAwNDAgSENUU0laPTB4MjAwMDAw
MDgNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0yDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdj
X290Z190aW1lcjoNCmR3Y19vdGdfaW50ZXJydXB0X3BvbGxfbG9ja2VkOiBSZWFkaW5nIDQgYnl0
ZXMgZnJvbSBlcCAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAw
MDAwMjAgSENDSEFSPTB4ODBjMDgwNDAgSENUU0laPTB4ODAwMDAwM2MNCmR3Y19vdGdfaG9zdF9k
YXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwMDQwDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRp
bmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4
MGMwODA0MCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENI
PTIgSENDSEFSPTB4ODBjODhhMDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRh
X3R4OiBDSD0xIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBIQ1RTSVo9
MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTENCmR3Y19vdGdf
aG9zdF9kYXRhX3J4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHg4MGM4OGEw
MCBIQ1RTSVo9MHhjMDAwMDIwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRp
bmcgNzIgYnl0ZXMgZnJvbSBlcCAyDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MiBTVD0xIEhD
SU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4YzAwMDAxYjgNCmR3Y19v
dGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDQwNDgyDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX3RpbWVyOg0KZHdjX290Z19ob3N0X2NoYW5u
ZWxfYWxsb2M6IENIPTAgSENDSEFSPTB4ODA4MDAwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19v
dGdfaG9zdF9zZXR1cF90eDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMjEgSENDSEFSPTB4MDA4
MDAwNDAgSENUU0laPTB4MjAwMDAwMDgNCmR3Y19vdGdfaG9zdF9jaGFubmVsX2ZyZWVfc3ViOiBD
SD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBIQ0NIQVI9MHg4MDgwMDA0MCBI
Q1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19pbnRlcnJ1cHRfcG9sbF9sb2NrZWQ6IFJlYWRpbmcg
MCBieXRlcyBmcm9tIGVwIDANCmR3Y19vdGdfaG9zdF9kYXRhX3J4OiBDSD0wIFNUPTEgSENJTlQ9
MHgwMDAwMDAyMCBIQ0NIQVI9MHg4MDgwODA0MCBIQ1RTSVo9MHg4MDAwMDA0MA0KZHdjX290Z19o
b3N0X2RhdGFfcnhfc3ViOiBEQVRBIFNUPTEgU1RBVFVTPTB4MDAwNTAwMDANCmR3Y19vdGdfaG9z
dF9jaGFubmVsX2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1Yjog
SGFsdGluZyBjaGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hB
Uj0weDgwYzA4MDQwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxv
YzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0
X3NldHVwX3R4OiBDSD0wIFNUPTEgSENJTlQ9MHgwMDAwMDAyMSBIQ0NIQVI9MHgwMGMwMDA0MCBI
Q1RTSVo9MHgyMDAwMDAwOA0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3
Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0wIEhDQ0hBUj0weDgwYzA4MDQwIEhDU1BMVD0w
eDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MSBTVD0xIEhDSU5UPTB4MDAwMDAw
MTAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFu
bmVsX2ZyZWVfc3ViOiBDSD0xDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGlu
ZyBjaGFubmVsIDENCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgw
Yzg4YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDog
UmVhZGluZyA0IGJ5dGVzIGZyb20gZXAgMA0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTAgU1Q9
MSBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgwYzA4MDQwIEhDVFNJWj0weDgwMDAwMDNjDQpk
d2Nfb3RnX2hvc3RfZGF0YV9yeF9zdWI6IERBVEEgU1Q9MSBTVEFUVVM9MHgwMDA1MDA0MA0KZHdj
X290Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IENIPTANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2Zy
ZWVfc3ViOiBIYWx0aW5nIGNoYW5uZWwgMA0KZHdjX290Z19ob3N0X2NoYW5uZWxfYWxsb2M6IENI
PTMgSENDSEFSPTB4ODBjMDgwNDAgSENTUExUPTB4MDAwMDAwMDANCmR3Y19vdGdfaG9zdF9kYXRh
X3J4OiBDSD0yIFNUPTEgSENJTlQ9MHgwMDAwMDAwMCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1RTSVo9
MHg0MDA4MDIwMA0KZHdjX290Z19ob3N0X2RhdGFfdHg6IENIPTMgU1Q9MSBIQ0lOVD0weDAwMDAw
MDIxIEhDQ0hBUj0weDAwYzAwMDQwIEhDVFNJWj0weDAwMDAwMDAwDQpkd2Nfb3RnX2hvc3RfY2hh
bm5lbF9mcmVlX3N1YjogQ0g9Mw0KZHdjX290Z19ob3N0X2RhdGFfcng6IENIPTIgU1Q9MSBIQ0lO
VD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJWj0weDQwMDgwMjAwDQpkd2Nfb3Rn
X2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxfZnJlZV9z
dWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzogQ0g9MCBI
Q0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z190aW1lcjoNCmR3Y19v
dGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0xIEhDQ0hBUj0weDgxNDIwMDA4IEhDU1BMVD0weDgw
MDAwMTA1DQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MCBTVD0xIEhDSU5UPTB4MDAwMDAwMTAg
SENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4NDAwODAyMDANCmR3Y19vdGdfaG9zdF9jaGFubmVs
X2ZyZWVfc3ViOiBDSD0wDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogSGFsdGluZyBj
aGFubmVsIDANCmR3Y19vdGdfaG9zdF9jaGFubmVsX2FsbG9jOiBDSD0yIEhDQ0hBUj0weDgwYzg4
YTAwIEhDU1BMVD0weDAwMDAwMDAwDQpkd2Nfb3RnX2ludGVycnVwdF9wb2xsX2xvY2tlZDogUmVh
ZGluZyAxMzAgYnl0ZXMgZnJvbSBlcCAyDQpkd2Nfb3RnX2hvc3Rfc2V0dXBfdHg6IENIPTEgU1Q9
MiBIQ0lOVD0weDAwMDAwMDIwIEhDQ0hBUj0weDgxNDIwMDA4IEhDVFNJWj0weDYwMDgwMDA4DQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MQ0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAxDQpkd2Nfb3RnX2hvc3RfZGF0YV9yeDogQ0g9MiBT
VD0xIEhDSU5UPTB4MDAwMDAwMjAgSENDSEFSPTB4ODBjODhhMDAgSENUU0laPTB4ODAwMDAxN2UN
CmR3Y19vdGdfaG9zdF9kYXRhX3J4X3N1YjogREFUQSBTVD0xIFNUQVRVUz0weDAwMDUwODIyDQpk
d2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9Mg0KZHdjX290Z19ob3N0X2NoYW5uZWxf
ZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAyDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9hbGxvYzog
Q0g9MCBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0KZHdjX290Z19ob3N0X2Rh
dGFfcng6IENIPTAgU1Q9MSBIQ0lOVD0weDAwMDAwMDEwIEhDQ0hBUj0weDgwYzg4YTAwIEhDVFNJ
Wj0weDAwMDgwMjAwDQpkd2Nfb3RnX2hvc3RfY2hhbm5lbF9mcmVlX3N1YjogQ0g9MA0KZHdjX290
Z19ob3N0X2NoYW5uZWxfZnJlZV9zdWI6IEhhbHRpbmcgY2hhbm5lbCAwDQpkd2Nfb3RnX2hvc3Rf
Y2hhbm5lbF9hbGxvYzogQ0g9MSBIQ0NIQVI9MHg4MGM4OGEwMCBIQ1NQTFQ9MHgwMDAwMDAwMA0K
--000000000000af8e8e05da2a316c--

From nobody Mon Mar 14 09:31:20 2022
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 57DBE1A10843
	for ; Mon, 14 Mar 2022 09:31:40 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KHBBM3nhNz4Twx
	for ; Mon, 14 Mar 2022 09:31:39 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0F7ED26062A;
	Mon, 14 Mar 2022 10:31:32 +0100 (CET)
Message-ID: <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
Date: Mon, 14 Mar 2022 10:31:20 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KHBBM3nhNz4Twx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4607
Lines: 139

On 3/14/22 10:20, Archimedes Gaviola wrote:
> On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> 
>>
>>
>> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky 
>>> wrote:
>>>
>>>> On 3/12/22 16:31, Archimedes Gaviola wrote:
>>>>>>
>>>>>> IOERROR usually means an electrical error. The RPI3B will use a
>>>>>> transaction translator for the FULL speed traffic, which is driven by
>>>>>> software.
>>>>>
>>>>
>>>> Hi Archimedes,
>>>>
>>>>> Hi Hans,
>>>>>
>>>>> I'm curious about the transaction translator you've mentioned, any
>>>> idea why
>>>>> there's a need for translation and what is being translated?
>>>>
>>>> When the High Speed USB HUB was invented, there was a need to support
>>>> FULL and LOW speed USB transactions. Because FULL and LOW speed
>>>> transactions are slow and take up much bandwidth, a transactions
>>>> translator was invented which translates between High Speed USB and
>>>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB HIGH
>>>> speed port, followed by a USB HUB. These transactions are not visible in
>>>> usbdump .
>>>>
>>>>   >Does this only
>>>>> happen when RPi 3B (acting as host controller) is transmitting data to
>>>> the
>>>>> Epson printer? Are translation events visible in the usbdump? In this
>>>> case
>>>>> there's a way to possibly track what's going on and how to identify any
>>>>> info that is being translated?
>>>>
>>>> By turning on the HC debugging, you can possibly track via debug
>>>> messages what is going on. Maybe it is a timing issue, that the SW is
>>>> too slow serving the micro transactions.
>>>>
>>>> Any idea also if translation is being
>>>>> performed in RPi 4B?
>>>>
>>>> The later RPi's do the transaction translator bits in HW or via the XHCI
>>>> block.
>>>>
>>>> As I have conducted several printing cases with my
>>>>> Epson printer without any issues with either of the 4 ports.
>>>>>
>>>>> Sorry for these questions as I am catching-up to the USB technology
>>>>> internal workings under the hood.
>>>>
>>>> You are welcome!
>>>>
>>>
>>>
>>> Thank you so much Hans for answering my questions, really appreciate it!
>>> I have a much better understanding now.
>>>
>>> I came from testing with 13.0-RELEASE having the same RPi 3B hardware and
>>> setup and it's very stable. I haven't encountered any IOERROR and
>>> incomplete printed outputs that were encountered with 14.0-CURRENT
>>> (February 24, 2022). By the way, I found in the repository here
>>> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
>>> that there were two latest snapshots released dated March 3 and March 10,
>>> respectively. I need to take printing tests first, especially the latest to
>>> check if it also manifests before I go back to the Feb. 24 snapshot and do
>>> a thorough test with debugging. I'll provide updates for any observations.
>>>
>>> Thanks,
>>> Archimedes
>>>
>>
>>
>> Hi Hans,
>>
>> Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
>> snapshot) seems to be stable. Another test will be performed tomorrow.
>>
>> Thanks,
>> Archimedes
>>
> 
> Hi Hans,
> 
> I still encountered the issue this morning with 14.0-CURRENT (March 10,
> 2022 snapshot). I just noticed when I left my RPi 3B idle for a long period
> of time (2-3 hours and more) and started printing, then the issue pops-up.
> Another concern I encountered was when I started enabling
> hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network
> interface (remotely connected over SSH from my laptop) seemed to freeze and
> I got disconnected.
> 
> freebsd@generic:~ % uname -a
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64
> 
> root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=1
> hw.usb.dwc_otg.debug: 0 -> 1
> 
> See attached initial debug info (no printing testing yet).

Hi,

Nothing obvious there.

Maybe you need to add a conditional to DPRINTF's in the fast path, to 
only print for a certain device, to reduce the debug prints.

How many USB devices are connected?

One experiment you might try is to comment out:

usbd_transfer_submit(xfer);

in

uhub_intr_callback()

in

/usr/src/sys/dev/usb/usb_hub.c

It will save some USB resources, but also makes USB enumeration a bit 
slower. Maybe the chip is out of USB HW endpoints and is only polling 
for RX data ...

--HPS

From nobody Mon Mar 14 09:55:35 2022
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 537A91A15A94
	for ; Mon, 14 Mar 2022 09:56:03 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4KHBkV1s4Lz4XSB
	for ; Mon, 14 Mar 2022 09:56:02 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x52f.google.com with SMTP id w4so18988349edc.7
        for ; Mon, 14 Mar 2022 02:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=7eikZmd70VjYmmVWk8WE4zLYqD1G3+0aQcAuKzYAKrI=;
        b=fJWqTt8owbk2L1v8iLVjK3sslLKJSSDvn+d5sAaKBIH4A1iy+Pj/gJAjhIlpV6I49M
         WRJeRTvQ3guUx6RqY/jNJ/Q26snvwAvQnuOYY9g3RTHR2w3x5Cy0eHtGLyVFQ5dVY82p
         HBOzOHZFyqXE2JPgzgOMrBmCjzA04lX3vVVEL7i6A+Ei7NlSzFsKesZEnQC0tZEKHtUG
         TncEdEgGIJakTuP+qk3F7ThfKMkJVGxDwnhkS0PHS05uFSV1jCl/zTi80/iDsUyC0ZPv
         iNs5TEXk3/aGdoS3sgOm8u7vU6EOVVAM+hFI0+c/hFfAFiipWBm5MyYRibMiiXvvs0In
         4IIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=7eikZmd70VjYmmVWk8WE4zLYqD1G3+0aQcAuKzYAKrI=;
        b=ClbgpJF1J0YBNHvWk8Pa8H5YsRPK6tm0B5CiFE7nubkiRNStsFDBIGYU9RmSCvNccY
         ZcIBj7A9RMxnzK4qZsh1udrM9Iqbc+0XDUBcnMBkme4KOLp44kcTmPzOrl/tQ73FVcsd
         fYB2auarL2UghUdWjNm1Mb/CKv+GtATtmWRaxMo0HnqxwOFXA38UbByUHQJpjS0MouOq
         iQmStRrAsTUM4ebgkUJj24W1IqCJ/d0k1HyAo2GIJpH4oiX9hP9OGgrbMttZCS0fsIOj
         hKIwxGtNqxOhhFAVKUt+18w1a1eX914akthJy4xW9UT2ps3AaYGK8jj66V3q57Fg0zGp
         pEhg==
X-Gm-Message-State: AOAM532pGJ/tPR0BqlAXWkN3FCStKSoGEKEiruzKV2QB/iCAJyrfVXED
	2VHQbZmo+z6nNYokt4zb1K+7tCa1ciVm9na4JXMogIcR/cEraw==
X-Google-Smtp-Source: ABdhPJxC9tsSuRCg/d995enSJ2Cue0NV896cT3uSlPQiHeYqIMSREZz9kbHam0IxTWqmj53UIY/rDMxvBY8fLUwaDgM=
X-Received: by 2002:a50:cd8c:0:b0:418:65c2:8b77 with SMTP id
 p12-20020a50cd8c000000b0041865c28b77mr8757899edi.170.1647251745491; Mon, 14
 Mar 2022 02:55:45 -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
From: Archimedes Gaviola 
Date: Mon, 14 Mar 2022 17:55:35 +0800
Message-ID: 
Subject: Raspberry Pi 3B Slow Boot-up
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000254cf905da2aafc2"
X-Rspamd-Queue-Id: 4KHBkV1s4Lz4XSB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=fJWqTt8o;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3258
Lines: 82

--000000000000254cf905da2aafc2
Content-Type: text/plain; charset="UTF-8"

Hi,

In the default config.txt file there is [pi4] line. If I'm going to remove
this [pi4] line, the boot-up process is very slow. Slow in a sense that
some extended time is observed as compared to the default. I already tested
emphasizing the boot_delay=1 but to no avail. The reason why I removed it
is because I want to change the settings of the HDMI display resolution as
changes will not take effect with the [pi4] line in RPi 3B.

With 14.0-CURRENT (February 24, 2022 snapshot) I have described my
resolution here
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html
however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no
longer possible. Any idea what's going on?

Below is the default config.txt and my current config.txt for reference.

freebsd@generic:~ % cat /boot/msdos/config.txt
[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

freebsd@generic:~ % cat /boot/msdos/config.txt
[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

hdmi_group=2
hdmi_mode=11
armstub=armstub8-gic.bin

Thanks,
Archimedes

--000000000000254cf905da2aafc2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

In the default config.txt file there is [p=
i4] line. If I'm going to remove this [pi4] line, the boot-up process i=
s very slow. Slow in a sense that some extended time is observed as compare=
d to the default. I already tested emphasizing the boot_delay=3D1 but to no=
 avail. The reason why I removed it is because I want to change the setting=
s of the HDMI display resolution as changes will not take effect with the [=
pi4] line in RPi 3B.

With 14.0-CURRENT (February 2=
4, 2022 snapshot) I have described my resolution here https://lis=
ts.freebsd.org/archives/freebsd-arm/2022-February/001070.html however w=
ith the latest=20
14.0-CURRENT (March 10, 2022 snapshot) it's no longer possible. Any ide=
a what's going on?

Below is the default config=
.txt and my current config.txt for reference.

freeb=
sd@generic:~ % cat /boot/msdos/config.txt
[all]
arm_64bit=3D1
dtpa=
ram=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dtoverlay=3Dmmc
dtoverlay=3Ddi=
sable-bt
device_tree_address=3D0x4000
kernel=3Du-boot.bin

[pi4=
]
hdmi_safe=3D1
armstub=3Darmstub8-gic.bin

<=
div>
freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
arm_64bit=3D1dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dtoverlay=3Dmmc
dtoverlay=
=3Ddisable-bt
device_tree_address=3D0x4000
kernel=3Du-boot.bin
hdmi_group=3D2
hdmi_mode=3D11




armstub=3Darmstub8-gic.bin

Thanks,
Archimedes




--000000000000254cf905da2aafc2--

From nobody Mon Mar 14 10:12:40 2022
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 D16CD1A192A5
	for ; Mon, 14 Mar 2022 10:12:49 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4KHC5s2cbTz4Zrq
	for ; Mon, 14 Mar 2022 10:12:49 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id qt6so32606067ejb.11
        for ; Mon, 14 Mar 2022 03:12:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=M1FrzHL54PHFLHidwxnMCGo56f9Dp4j3stOzjwCOv7M=;
        b=AdOsaUEIjE5180VUdv3mzEe4CPV1QjBbRV7Aqb00XuNre1xQCm/4FyQX+tb7Qznj76
         hy7Y/U++L/bc5GCgNhtmUfe0W1jXpHUFiZvExq43n36nxNWqStpcFzutAVXhXUJxfbgG
         zQ+6jhw0GYkY3tLSTRaOyxqRa0RpWe/2XrkjieqFh1lwRHtWV8sVy+yHBfM/gVBEu037
         pW7RV9jGiak7zKxH7OGHYJHBYatz7VGTHgS0tZA2aL7jAyr+/PAiGugopiIRsI+vapOP
         UO+haGzKStEFE1kujn0+fALLq6ZAOlw5O9thGR0PEHkdUKkviD3ch+mX1mUitjGKSL0O
         fIRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=M1FrzHL54PHFLHidwxnMCGo56f9Dp4j3stOzjwCOv7M=;
        b=Fz0nfZbJRx/+nFiWlGBfdvItcuhNRDEJPelIjFNmCHBCvLbHkOEW5McWdx8jJOclzj
         wQUSYPqqtTvxBU1NvunoL8SZ7yuQIdz8wzq8ri3Slkidtm4Zzlzk1JkRGAO5PCPqO1FK
         ZmgGsn8MUFcagCWqOX5og/L36M91w7GWhqwOCPiodanN+4yvGsN8luO5Rkq+E47mRQso
         vO0ZydzDLpBduJtfdZRk92mSb1nm69WNkg0MuTQm0BpbPXH7puZ0q+te0eaOAc5r+F5k
         BB2D3Yvs8c9ZzQseKI4ue9y873QpjcIjE6ctp6FIg1MTK+zQJ73rIm9R9KEaOWti0m1P
         AXoA==
X-Gm-Message-State: AOAM530kMLW53B2zoNVFZkyzK4qW+ea7uK73YEYQZZpOUuu0BhPo99P0
	v7oA8hp/aeevYnPgyfz1J4cGhnsE7F7MYDNsku7WwiMKb8g=
X-Google-Smtp-Source: ABdhPJxamPiBkInFCHioG7GhHutcL1R7svqIkKKbmsESNHOKuKWo6vSrVk2K0IQnfKF6yyyb7DOIdJQUlawjm3Xd1qM=
X-Received: by 2002:a17:906:730c:b0:6d6:f8f2:fb92 with SMTP id
 di12-20020a170906730c00b006d6f8f2fb92mr17154496ejc.370.1647252768475; Mon, 14
 Mar 2022 03:12:48 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
  <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
In-Reply-To: <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
From: Archimedes Gaviola 
Date: Mon, 14 Mar 2022 18:12:40 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000001ed12005da2aec65"
X-Rspamd-Queue-Id: 4KHC5s2cbTz4Zrq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=AdOsaUEI;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.71 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.71)[-0.712];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 13487
Lines: 385

--0000000000001ed12005da2aec65
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 14, 2022 at 5:31 PM Hans Petter Selasky  wrote:

> On 3/14/22 10:20, Archimedes Gaviola wrote:
> > On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <
> > archimedes.gaviola@gmail.com> wrote:
> >
> >>
> >>
> >> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
> >> archimedes.gaviola@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky 
> >>> wrote:
> >>>
> >>>> On 3/12/22 16:31, Archimedes Gaviola wrote:
> >>>>>>
> >>>>>> IOERROR usually means an electrical error. The RPI3B will use a
> >>>>>> transaction translator for the FULL speed traffic, which is driven
> by
> >>>>>> software.
> >>>>>
> >>>>
> >>>> Hi Archimedes,
> >>>>
> >>>>> Hi Hans,
> >>>>>
> >>>>> I'm curious about the transaction translator you've mentioned, any
> >>>> idea why
> >>>>> there's a need for translation and what is being translated?
> >>>>
> >>>> When the High Speed USB HUB was invented, there was a need to support
> >>>> FULL and LOW speed USB transactions. Because FULL and LOW speed
> >>>> transactions are slow and take up much bandwidth, a transactions
> >>>> translator was invented which translates between High Speed USB and
> >>>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB
> HIGH
> >>>> speed port, followed by a USB HUB. These transactions are not visible
> in
> >>>> usbdump .
> >>>>
> >>>>   >Does this only
> >>>>> happen when RPi 3B (acting as host controller) is transmitting data
> to
> >>>> the
> >>>>> Epson printer? Are translation events visible in the usbdump? In this
> >>>> case
> >>>>> there's a way to possibly track what's going on and how to identify
> any
> >>>>> info that is being translated?
> >>>>
> >>>> By turning on the HC debugging, you can possibly track via debug
> >>>> messages what is going on. Maybe it is a timing issue, that the SW is
> >>>> too slow serving the micro transactions.
> >>>>
> >>>> Any idea also if translation is being
> >>>>> performed in RPi 4B?
> >>>>
> >>>> The later RPi's do the transaction translator bits in HW or via the
> XHCI
> >>>> block.
> >>>>
> >>>> As I have conducted several printing cases with my
> >>>>> Epson printer without any issues with either of the 4 ports.
> >>>>>
> >>>>> Sorry for these questions as I am catching-up to the USB technology
> >>>>> internal workings under the hood.
> >>>>
> >>>> You are welcome!
> >>>>
> >>>
> >>>
> >>> Thank you so much Hans for answering my questions, really appreciate
> it!
> >>> I have a much better understanding now.
> >>>
> >>> I came from testing with 13.0-RELEASE having the same RPi 3B hardware
> and
> >>> setup and it's very stable. I haven't encountered any IOERROR and
> >>> incomplete printed outputs that were encountered with 14.0-CURRENT
> >>> (February 24, 2022). By the way, I found in the repository here
> >>> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
> >>> that there were two latest snapshots released dated March 3 and March
> 10,
> >>> respectively. I need to take printing tests first, especially the
> latest to
> >>> check if it also manifests before I go back to the Feb. 24 snapshot
> and do
> >>> a thorough test with debugging. I'll provide updates for any
> observations.
> >>>
> >>> Thanks,
> >>> Archimedes
> >>>
> >>
> >>
> >> Hi Hans,
> >>
> >> Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
> >> snapshot) seems to be stable. Another test will be performed tomorrow.
> >>
> >> Thanks,
> >> Archimedes
> >>
> >
> > Hi Hans,
> >
> > I still encountered the issue this morning with 14.0-CURRENT (March 10,
> > 2022 snapshot). I just noticed when I left my RPi 3B idle for a long
> period
> > of time (2-3 hours and more) and started printing, then the issue
> pops-up.
> > Another concern I encountered was when I started enabling
> > hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network
> > interface (remotely connected over SSH from my laptop) seemed to freeze
> and
> > I got disconnected.
> >
> > freebsd@generic:~ % uname -a
> > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> > main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022
> > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> > arm64
> >
> > root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=1
> > hw.usb.dwc_otg.debug: 0 -> 1
> >
> > See attached initial debug info (no printing testing yet).
>


Hi Hans,


>
> Hi,
>
> Nothing obvious there.
>
> Maybe you need to add a conditional to DPRINTF's in the fast path, to
> only print for a certain device, to reduce the debug prints.
>
> How many USB devices are connected?
>

Only two devices, one is my USB keyboard and the other one is my Epson
printer.


>
> One experiment you might try is to comment out:
>
> usbd_transfer_submit(xfer);
>
> in
>
> uhub_intr_callback()
>
> in
>
> /usr/src/sys/dev/usb/usb_hub.c
>
> It will save some USB resources, but also makes USB enumeration a bit
> slower.


This is noted, I'll try.


> Maybe the chip is out of USB HW endpoints and is only polling
> for RX data ...
>

This is noted as well, we'll probably see later what's going on. I'll get
back to you once I recompile the kernel and perform the testing.

Thanks,
Archimedes

--0000000000001ed12005da2aec65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 14, 2022 at 5:31 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
4/22 10:20, Archimedes Gaviola wrote:

> On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <

> arch=
imedes.gaviola@gmail.com> wrote:

> 

>>

>>

>> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <

>> =
archimedes.gaviola@gmail.com> wrote:

>>

>>>

>>>

>>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky <hps@selasky.org>

>>> wrote:

>>>

>>>> On 3/12/22 16:31, Archimedes Gaviola wrote:

>>>>>>

>>>>>> IOERROR usually means an electrical error. The RPI=
3B will use a

>>>>>> transaction translator for the FULL speed traffic,=
 which is driven by

>>>>>> software.

>>>>>

>>>>

>>>> Hi Archimedes,

>>>>

>>>>> Hi Hans,

>>>>>

>>>>> I'm curious about the transaction translator you&#=
39;ve mentioned, any

>>>> idea why

>>>>> there's a need for translation and what is being t=
ranslated?

>>>>

>>>> When the High Speed USB HUB was invented, there was a need=
 to support

>>>> FULL and LOW speed USB transactions. Because FULL and LOW =
speed

>>>> transactions are slow and take up much bandwidth, a transa=
ctions

>>>> translator was invented which translates between High Spee=
d USB and

>>>> FULL/LOW speed USB. That means the RPi 3B consists of a si=
ngle USB HIGH

>>>> speed port, followed by a USB HUB. These transactions are =
not visible in

>>>> usbdump .

>>>>

>>>>=C2=A0 =C2=A0>Does this only

>>>>> happen when RPi 3B (acting as host controller) is tran=
smitting data to

>>>> the

>>>>> Epson printer? Are translation events visible in the u=
sbdump? In this

>>>> case

>>>>> there's a way to possibly track what's going o=
n and how to identify any

>>>>> info that is being translated?

>>>>

>>>> By turning on the HC debugging, you can possibly track via=
 debug

>>>> messages what is going on. Maybe it is a timing issue, tha=
t the SW is

>>>> too slow serving the micro transactions.

>>>>

>>>> Any idea also if translation is being

>>>>> performed in RPi 4B?

>>>>

>>>> The later RPi's do the transaction translator bits in =
HW or via the XHCI

>>>> block.

>>>>

>>>> As I have conducted several printing cases with my

>>>>> Epson printer without any issues with either of the 4 =
ports.

>>>>>

>>>>> Sorry for these questions as I am catching-up to the U=
SB technology

>>>>> internal workings under the hood.

>>>>

>>>> You are welcome!

>>>>

>>>

>>>

>>> Thank you so much Hans for answering my questions, really appr=
eciate it!

>>> I have a much better understanding now.

>>>

>>> I came from testing with 13.0-RELEASE having the same RPi 3B h=
ardware and

>>> setup and it's very stable. I haven't encountered any =
IOERROR and

>>> incomplete printed outputs that were encountered with 14.0-CUR=
RENT

>>> (February 24, 2022). By the way, I found in the repository her=
e

>>> https://download.f=
reebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/

>>> that there were two latest snapshots released dated March 3 an=
d March 10,

>>> respectively. I need to take printing tests first, especially =
the latest to

>>> check if it also manifests before I go back to the Feb. 24 sna=
pshot and do

>>> a thorough test with debugging. I'll provide updates for a=
ny observations.

>>>

>>> Thanks,

>>> Archimedes

>>>

>>

>>

>> Hi Hans,

>>

>> Initial testing conducted with the latest 14.0-CURRENT (March 10, =
2022

>> snapshot) seems to be stable. Another test will be performed tomor=
row.

>>

>> Thanks,

>> Archimedes

>>

> 

> Hi Hans,

> 

> I still encountered the issue this morning with 14.0-CURRENT (March 10=
,

> 2022 snapshot). I just noticed when I left my RPi 3B idle for a long p=
eriod

> of time (2-3 hours and more) and started printing, then the issue pops=
-up.

> Another concern I encountered was when I started enabling

> hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network=


> interface (remotely connected over SSH from my laptop) seemed to freez=
e and

> I got disconnected.

> 

> freebsd@generic:~ % uname -a

> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0

> main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022

> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERI=
C

> arm64

> 

> root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=3D1

> hw.usb.dwc_otg.debug: 0 -> 1

> 

> See attached initial debug info (no printing testing yet).


Hi Hans,
=C2=A0
=




Hi,



Nothing obvious there.



Maybe you need to add a conditional to DPRINTF's in the fast path, to <=
br>
only print for a certain device, to reduce the debug prints.



How many USB devices are connected?

Onl=
y two devices, one is my USB keyboard and the other one is my Epson printer=
.
=C2=A0



One experiment you might try is to comment out:



usbd_transfer_submit(xfer);



in



uhub_intr_callback()



in



/usr/src/sys/dev/usb/usb_hub.c



It will save some USB resources, but also makes USB enumeration a bit 

slower. 

This is noted, I'll try.
=C2=A0
=
Maybe the chip is out of USB HW endpoints and is only polling 

for RX data ...

This is noted as well, =
we'll probably see later what's going on. I'll get back to you =
once I recompile the kernel and perform the testing.

Thanks,
Archimedes



--0000000000001ed12005da2aec65--

From nobody Mon Mar 14 12:01:16 2022
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 281CC1A2DD3B
	for ; Mon, 14 Mar 2022 12:01:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KHFWB6Xt1z4pJt
	for ; Mon, 14 Mar 2022 12:01:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647259279; bh=mmf6tZRHvWyrHZsa5ZwCzZEKbmselDP0ybT0dhtYZOY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tLvFc1aPUghs3knBg0sRIIa2MhxsxubQcyqK51xSF389fD6o+2JRDfK7XZIqufKLN9gnpBOwl5GS/+mPoCYCq6bz6ONN7RE5h4xbx0u7Rpwy9fUmX9XWBN3LC40lAn6Cnr0n7waEOX/RAgIBxm3pcNLW1MDyq+mZhV/wtOewVYrbq3foXUBj+ViM3QSnM0ehORDugS7g7qHjJTT+yCjmBYKB42T1vW1tVnvXNDT6asMRJMiQs7rq+stsAhEBp34M3F17FGObx/gawjcUK7Y39tc3KHAd/L0jfaEIVOLKlh6RHlbbwAajTDYcLnYkMR13l9uDg8IcORUnBCVbPXuJow==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647259279; bh=OJMB+tBqaZFYRSyl5myACXX7a2wTkES0f/2JlztiNOJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KAI8TIvodbDVGybYvdMpooZhLO7rXH/UvuKIt/lchQo3dw1+Rtkc4QET+bSBcDv+sSMV2i7a0x25FcQG5T91/+AnHGlcYVmVoKHiC8brsLSEawOLEc6GzgJ0dy0ha1DCh4q9ziBb0txdynXEVRgVRSAW/5shUHBJNWNBfKOQLm2qltF1/GNqr4u5Hwam78LrTWoK5AR8CMWILiV7mubEZf1A6nQq4PBW9O3W9iGXAWBAdmiioHc0R7HJRLDBLSlPqfJbGu+QgpCnw/aICDmYo2iCktz2o4pgO9zvnvRfl0CD+hhNvkqtI9vQTHCdLhsjWj3UXvCYmdMaBQDvGgkN9w==
X-YMail-OSG: 3L2DAvgVM1n0NIWhLzRCa8vMNCIsbGAopGf190Ag2sH.BAvE_fKSGI.de4O263T
 _CkUKaRzMo1uzRw4M5AOIXgGDV4Yl6WOQv0pI3yD94Ak1D6dE.J4gPKgY0vX71dNqcN6h6OtFUgV
 ZbeVAW1d0xw_MIRSHWqf_.AeIqlbwEOz2pKZ6varx.VTHSUP0ZIuday7sj0SGeaGsQvvMB.3DjhP
 H0ZARcqB5I6ai_7fdJthfpXDCAUIUinpexXwMi.eHaQ__uwB8VUAVi0jKZZcMk32nfmtakZNgLt5
 5LdxJ07qx.8xyMBXK7en1rVv.nq8EgwgCh1t_R1BCARa_os3MBxm6pTqSpChUiTragU_45LsZsQ6
 NG4I0Tu5pTeaNo80lnK3lAC75JdtehG_tEc54ExXdKNgsSv5m7P4hHASk64bRFKcdqlEmJaJeCuE
 lEaGy83iMu5QE1SvVEHnGzLMdiACCGxOj7IZ91NHHp881iM3rd352Ha8Z5OS6whVoR3wyTdKvKxT
 Qi0vC8fTZsNAAaDHeYWqPvHt_SzZ3ZdsttlzoLrQ7s5Phma4yVE14E0fbW3xiQu3h.2ILmYd.wFm
 451luglZfTaTrmD1gaHBZZAosEmhjN60LD8kEEsQeQedUnauQIKjn_NdrAM3IK7KK23V_DWwTtOK
 lACRI6zLy7VLQB_210ImTt6r5EwnKqCPKJFC53zH6WWfsHBo6mHnSXDfQQG2HcddkbscEkoj70q1
 v0bxVow4x8fxg0ud7vbgLgrfNtJk2pUTeOQM1zQwYIpLwyZFlt9cW_gmsX4_F32SZiuAOmvfkp4.
 tmcKKF6J5HZBTf0Bt36OlzXG9YdGzZWPLLlZp.T_Avei4RcvsWdDv_juBezuBN8AIGfKGDH3_3jQ
 WBAst3Be8jd.y4WJSDNCSqWgaMASHdQhjbSJpdULrkptRIH4As_5Bt_zpqjiX19VniLxxZGuTtkv
 0.D.XYztAoxEmAIBT.G.kKwJXRle05Hcb9DHUD7_vCXu14auBvCuNP4OEdnTFdzPRAUJ3HCJeGgB
 nlWI8po8J9fBv4N7HIqRIBitYBOfVyegwps2iGQXswbVi77WBX25Bj_iqRBAuMh_.HbJVXmVrNDT
 bZ6lECPqey8xwEJvdDbmuwXJUD1z9zULLYSGMhvtSwA6JIvINye88Tvfj37M0ro.sn2wVzeEuIt3
 ynuRX0MQ4AHVdD8yPN0D_2YDsrceIrKcrqOOLekNtHJHs53wt2E0UbamL4t.EpbW1S1Hejny0Ue3
 DxTOdFBadvvY4yIH.cYnxQl6YjB.8y4xcdzJubOtqndleu6v9lU5_qYdGb2nQCWV3qQg7J5aKARF
 dR67Vvjdnets.8xXFtKcvhV1KTY9K1Fdva1fyNuDvvcQEJU87VQkCelo88bOPJ6WhgHJ8F6EZ5eT
 q.iPefempe8hcadFeGg5NdPiJtI0J.kyC_eW2PD0l7c8a7ZwpA32qPwSfMUHQyXpqsvheZiga2eI
 mEkbmCWVG06Pkkw5OEteCUui9F_2RcrbVgUKGkpBMwBgk7Fh6VCMB2sufRfaqxBl7QeBB59V9SLJ
 .gGRmJhvjWJ3ZWxMJuopbZcvU59XRfs22gih_VpVFQ2l9Klc4KL8imHKHOib2vi4qNFx410Z.aAe
 eIy9M.t57WcZo0OZuJ1_apZxfspmb6iZ8Na56RiFkboRzYO1UKF9jKjf4t4qrGmTxo8nKqS4b0Di
 9jOR8_ea3i7LugodPjS7M25nwXxR5cLze6Y8FDZLlYfaJxfYQWhhXtIy1Ot71Vz79GukDQZc10rh
 0DPl0VrlR938lyDD02VFBtSj5m_SFyQXFhdhKAubbhSlTBoGWOMUs_eqCcWE1diiaDb.TRQjArS6
 TfihXPongv6.hbmJMuBZZEqr_fi4vXjR0jNCnOcwoofvLwm2J.8sor3nPBFuTKz8M1Qw4dz27Px6
 p9DVMBuB7F5A6JEc1GleC4O0yaKR5CgPXCsau5JIA_1VWflKBJs2Ce8JxeGKZuKUz3v3atFJnkhr
 GSg6dcdTJGY1fkFlU_wNSZQIVrPz0HsI080fLmLK62MkWynmtrSk3s0WmBd_cyLEUikzExg9p_rl
 2orgrajitV8n8lsW1XSwBjCb9gJp8Ssdmvk4vyVS6zfItbyeOYn2q2Gwu9tysHuaDcCQPmg58Wxo
 4AY_UMZI_Qel9uAz2fIynFGlRCeG4T_ez3YC_gM4TukrJpyszEGtGMWX8UKhiB8MbJZfPUQiKFvv
 PJOx1WF3tRtT1HiwuBf2x4GpiRTUjP_ugUwd4KkzDwXtosdPI.n0l0Y5nTb8POGbiAYm_oAY.Q.d
 l9py2kYW2VlXp
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Mar 2022 12:01:19 +0000
Received: by kubenode508.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2824e138775066456bcf05d893b399d3;
          Mon, 14 Mar 2022 12:01:18 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Raspberry Pi 3B Slow Boot-up
From: Mark Millard 
In-Reply-To: 
Date: Mon, 14 Mar 2022 05:01:16 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com>
References: 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KHFWB6Xt1z4pJt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tLvFc1aP;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2435
Lines: 74

On 2022-Mar-14, at 02:55, Archimedes Gaviola =
 wrote:

> In the default config.txt file there is [pi4] line. If I'm going to =
remove this [pi4] line, the boot-up process is very slow. Slow in a =
sense that some extended time is observed as compared to the default. I =
already tested emphasizing the boot_delay=3D1 but to no avail. The =
reason why I removed it is because I want to change the settings of the =
HDMI display resolution as changes will not take effect with the [pi4] =
line in RPi 3B.
>=20
> With 14.0-CURRENT (February 24, 2022 snapshot) I have described my =
resolution here =
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html =
however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no =
longer possible. Any idea what's going on?
>=20
> Below is the default config.txt and my current config.txt for =
reference.
>=20
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [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
>=20
> [pi4]
> hdmi_safe=3D1
> armstub=3Darmstub8-gic.bin
>=20
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [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
>=20
> hdmi_group=3D2
> hdmi_mode=3D11
> armstub=3Darmstub8-gic.bin

armstub8-gic.bin is specific to the BCM2711 and will not
work for the RPi3, as I understand.

armstub=3Darmstub8.bin is the default and is what was being
used for the RPi3 when the [pi4] was in place.

You have the option of listing a [pi3] section last
(after the [pi4] section). To have a [pi3] section
be last, it should have an explicit
armstub=3Darmstub8.bin line.

Listing older RPi* models last is done because some older
RPi models ignore the [] notation and listing things last
overrides earlier assignments, in this case overriding
assignments for newer models. It is a safe notational
ordering convention, even for models that do support
the [] notation sufficiently.

If one depended on RPi3 models processing [] notation,
if it does, then another option would have been to move
the [rpi4] line to be just before the
armstub=3Darmstub8-gic.bin line, causing the RPi3 to skip
the assignment and use the default.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar 14 13:50:05 2022
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 59F8B1A1A1DC
	for ; Mon, 14 Mar 2022 13:50:17 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4KHHwm357Dz3GvB
	for ; Mon, 14 Mar 2022 13:50:16 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62d.google.com with SMTP id qa43so33918492ejc.12
        for ; Mon, 14 Mar 2022 06:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ahXQK3Kf6X0Ir4iy71jSq+suE2uI3JQkove+2cY7lCs=;
        b=dVbYTErujkLBw8ERlGVYeZvywIsXSEQE+OUfcPcAidc24iUpyFkQ8Ht7tcf6NUjVgf
         1jJnIHW3NTsdEG6HptC7PvJLxMmL9kFVSr249B7uIm0lzaUari9lrBQnxaqutsHKBErH
         FJSHLlqa09ln3ufqLi62HqZD0OIWSHfRc/P0vtEtBkn/O3Xomt/ab+D0Z3y+i2GEZBsl
         F4ePWhRHgh/lYcTt1uIR/zAD0zyBeZcepMQ8Zz6QpWudgctJvU/40piTK1ZzVdSdk4bF
         FlzAGCpfIEZeQY7ZB/5oat391xLyiwcuaTrJzP/j/l4Bh1u7Hs5RyCF7EFNdsNsdkQK0
         eLzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ahXQK3Kf6X0Ir4iy71jSq+suE2uI3JQkove+2cY7lCs=;
        b=6KOzz8XfTlvjHy8QHZMCS6V1M5oSB/UTX7rkgbowAcZw90hXnf72FdxzM779u1Ak8W
         M9HPLDBBEl/WQfSlIMkeEJAP4gbWSS8MOmoPfiLgVCjESY0E0woHgqEVhjWi15nsbw98
         52FEZT8vXyHCZCFkJRutPdNpBZ5RHtJAU+lciyccGuYYwUk50Y0DStSb5vI6dOIgyHUm
         ShHK3rKAbCbk8ovY2QkSnLFD22EQk5zJz5fW7aXaXZXXRUBNrw7Pxi2LlitFl2Nzz84T
         CvGY60AX//y1ZCNqA9Opf6fni36qxoFjPqnCfhue6YsePkCH2zDelIPyVkjedG4eNKGl
         EhnA==
X-Gm-Message-State: AOAM532FLMAorl+mLbTs9VE24DNNmxq7BcgdZNk2i3knASdFzCSNjIrn
	a83Yt8jDHMI3ISW4inwj1FiEKH+EUqvDRh9xwxYKSRaHah81iA==
X-Google-Smtp-Source: ABdhPJzCmWr7xBELAPWdNBC2J86vFHYaenRJlo1lXyqgeuwTJNj3uZoeNekxA3ZY6c2NxFiEshXTQZPKUEr2E6qdrf8=
X-Received: by 2002:a17:906:3cb1:b0:6ce:2a97:5ade with SMTP id
 b17-20020a1709063cb100b006ce2a975ademr18379524ejh.728.1647265814530; Mon, 14
 Mar 2022 06:50:14 -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: 
 <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com>
In-Reply-To: <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com>
From: Archimedes Gaviola 
Date: Mon, 14 Mar 2022 21:50:05 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Slow Boot-up
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000b9cebf05da2df523"
X-Rspamd-Queue-Id: 4KHHwm357Dz3GvB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=dVbYTEru;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.97 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.97)[-0.975];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7651
Lines: 197

--000000000000b9cebf05da2df523
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 14, 2022 at 8:01 PM Mark Millard  wrote:

> On 2022-Mar-14, at 02:55, Archimedes Gaviola 
> wrote:
>
> > In the default config.txt file there is [pi4] line. If I'm going to
> remove this [pi4] line, the boot-up process is very slow. Slow in a sense
> that some extended time is observed as compared to the default. I already
> tested emphasizing the boot_delay=1 but to no avail. The reason why I
> removed it is because I want to change the settings of the HDMI display
> resolution as changes will not take effect with the [pi4] line in RPi 3B.
> >
> > With 14.0-CURRENT (February 24, 2022 snapshot) I have described my
> resolution here
> https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html
> however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no
> longer possible. Any idea what's going on?
> >
> > Below is the default config.txt and my current config.txt for reference.
> >
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [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
> >
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [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
> >
> > hdmi_group=2
> > hdmi_mode=11
> > armstub=armstub8-gic.bin
>
> armstub8-gic.bin is specific to the BCM2711 and will not
> work for the RPi3, as I understand.
>
> armstub=armstub8.bin is the default and is what was being
> used for the RPi3 when the [pi4] was in place.
>
> You have the option of listing a [pi3] section last
> (after the [pi4] section). To have a [pi3] section
> be last, it should have an explicit
> armstub=armstub8.bin line.
>
> Listing older RPi* models last is done because some older
> RPi models ignore the [] notation and listing things last
> overrides earlier assignments, in this case overriding
> assignments for newer models. It is a safe notational
> ordering convention, even for models that do support
> the [] notation sufficiently.
>
> If one depended on RPi3 models processing [] notation,
> if it does, then another option would have been to move
> the [rpi4] line to be just before the
> armstub=armstub8-gic.bin line, causing the RPi3 to skip
> the assignment and use the default.
>


Hi Mark,

Awesome, it works great! Below is my revised config.txt file now, no more
boot-up delay and display resolution was effectively changed. Thank you so
much for sharing your thoughts in well-explained details, now I learned.

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_delay=0
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]
armstub=armstub8-gic.bin

[pi3]
hdmi_group=2
hdmi_mode=11

Thanks,
Archimedes

--000000000000b9cebf05da2df523
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 14, 2022 at 8:01 PM Mark =
Millard <marklmi@yahoo.com> =
wrote:
On 2022-M=
ar-14, at 02:55, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:<=
br>


> In the default config.txt file there is [pi4] line. If I'm going t=
o remove this [pi4] line, the boot-up process is very slow. Slow in a sense=
 that some extended time is observed as compared to the default. I already =
tested emphasizing the boot_delay=3D1 but to no avail. The reason why I rem=
oved it is because I want to change the settings of the HDMI display resolu=
tion as changes will not take effect with the [pi4] line in RPi 3B.

> 

> With 14.0-CURRENT (February 24, 2022 snapshot) I have described my res=
olution here https://lists.f=
reebsd.org/archives/freebsd-arm/2022-February/001070.html however with =
the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no longer possib=
le. Any idea what's going on?

> 

> Below is the default config.txt and my current config.txt for referenc=
e.

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [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

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [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

> 

> hdmi_group=3D2

> hdmi_mode=3D11

> armstub=3Darmstub8-gic.bin



armstub8-gic.bin is specific to the BCM2711 and will not

work for the RPi3, as I understand.



armstub=3Darmstub8.bin is the default and is what was being

used for the RPi3 when the [pi4] was in place.



You have the option of listing a [pi3] section last

(after the [pi4] section). To have a [pi3] section

be last, it should have an explicit

armstub=3Darmstub8.bin line.



Listing older RPi* models last is done because some older

RPi models ignore the [] notation and listing things last

overrides earlier assignments, in this case overriding

assignments for newer models. It is a safe notational

ordering convention, even for models that do support

the [] notation sufficiently.



If one depended on RPi3 models processing [] notation,

if it does, then another option would have been to move

the [rpi4] line to be just before the

armstub=3Darmstub8-gic.bin line, causing the RPi3 to skip

the assignment and use the default.


Hi Mark,

Awesome, it works great! Below is my revised config.txt file no=
w, no more boot-up delay and display resolution was effectively changed. Th=
ank you so much for sharing your thoughts in well-explained details, now I =
learned.

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_dela=
y=3D0
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dto=
verlay=3Dmmc
dtoverlay=3Ddisable-bt
device_tree_address=3D0x4000
k=
ernel=3Du-boot.bin

[pi4]
armstub=3Darmstub8-gic.bin

[pi3]<=
br>hdmi_group=3D2
hdmi_mode=3D11

Thanks,
Archi=
medes



=C2=A0


--000000000000b9cebf05da2df523--

From nobody Mon Mar 14 14:12:49 2022
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 F0A7F1A1FF78
	for ; Mon, 14 Mar 2022 14:12:59 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4KHJQz26C3z3M0j
	for ; Mon, 14 Mar 2022 14:12:59 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id r13so34279478ejd.5
        for ; Mon, 14 Mar 2022 07:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=JmA2OsGUBh3MnaLn89X7w4PX42sqifHdYV9oLlQ3N+E=;
        b=jprLdG5i5DWiRsbEVcK7s2VLe9BZ2GUpWtH9nlyfM8Z+bbwzoZZZrK/PYoVe1PMZb3
         aOppJO0j6Rmfv2+EsF5HrVOkcMySD/AHVfxzQdKkbo3EUdSboA+lUjTKPytMF/gu3T7r
         tmCsnlMb+mmFrG3LVB3iX0lWNg2DHrWanG2cnJm04v+qIpsYUa890K9AAZoPmR0UNoxs
         fMxEdsgqpbWGUZEaONpxW6OzDD7WhuacOG2IsVgKsBpG1/lh8Aiv7ylIluZ5NyrJxxYq
         X3BU6iOlAnxtn6WyusloTfUFl1dGe/mXyC8AdIEc8OS+UsBs5UtOUByz7E5bUh5us6+D
         h8Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=JmA2OsGUBh3MnaLn89X7w4PX42sqifHdYV9oLlQ3N+E=;
        b=wBW3gB4AKDUA2cABmhldoNM3A4D+DjJFneXJQfDDQet7KNbZOwd4aRoywXh6ba4LvV
         L8fx4Nb6nvDzzUwxAq9qwh4qwiJkpA8i30Unog5RQdgB8ZVdiV0EvvMXvKXNkOq7xQJf
         g1932QcoOwB8z2utqP9FzO/nKLCaxD7oPV7FvwUhkR6Vbtwnp3uIJygBsWGbYRneMtLM
         D77ntooXIVc4mFbAkzxhdfxtk6P7Rql5CIrU9FiI9t8IEH0RFU9tQcqncHxX7veniS3m
         HZX2zED6+XPsGR5GRLKJYS1g/XD65ZYpb7YgbRlWpP/EHAEW86/kdKxqdbfn+5wFcxf6
         LPKQ==
X-Gm-Message-State: AOAM532LtuwB2Epz/elA2kowO8ciidYvKSjnCSOgoItonYIoI/mHk4yO
	v5hU/Z8BIp2LrRb2Y7FvfgBNPtiLXkv79q7YFm8T4++sCcjgIg==
X-Google-Smtp-Source: ABdhPJzxs1SW5brCV/Dg1QlmV/Lj3dEDDA0EElLg8KB6xiQZHaGcYF0J+gESMg2BJEigMIQ0qe66t9CztiCpWq+gpGg=
X-Received: by 2002:a17:906:4fc4:b0:6da:b4c6:fadb with SMTP id
 i4-20020a1709064fc400b006dab4c6fadbmr19826203ejw.282.1647267178266; Mon, 14
 Mar 2022 07:12:58 -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: 
 <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Mon, 14 Mar 2022 22:12:49 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Slow Boot-up
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000003362c05da2e47c1"
X-Rspamd-Queue-Id: 4KHJQz26C3z3M0j
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=jprLdG5i;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9853
Lines: 259

--00000000000003362c05da2e47c1
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 14, 2022 at 9:50 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Mon, Mar 14, 2022 at 8:01 PM Mark Millard  wrote:
>
>> On 2022-Mar-14, at 02:55, Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>>
>> > In the default config.txt file there is [pi4] line. If I'm going to
>> remove this [pi4] line, the boot-up process is very slow. Slow in a sense
>> that some extended time is observed as compared to the default. I already
>> tested emphasizing the boot_delay=1 but to no avail. The reason why I
>> removed it is because I want to change the settings of the HDMI display
>> resolution as changes will not take effect with the [pi4] line in RPi 3B.
>> >
>> > With 14.0-CURRENT (February 24, 2022 snapshot) I have described my
>> resolution here
>> https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html
>> however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no
>> longer possible. Any idea what's going on?
>> >
>> > Below is the default config.txt and my current config.txt for reference.
>> >
>> > freebsd@generic:~ % cat /boot/msdos/config.txt
>> > [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
>> >
>> > freebsd@generic:~ % cat /boot/msdos/config.txt
>> > [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
>> >
>> > hdmi_group=2
>> > hdmi_mode=11
>> > armstub=armstub8-gic.bin
>>
>> armstub8-gic.bin is specific to the BCM2711 and will not
>> work for the RPi3, as I understand.
>>
>> armstub=armstub8.bin is the default and is what was being
>> used for the RPi3 when the [pi4] was in place.
>>
>> You have the option of listing a [pi3] section last
>> (after the [pi4] section). To have a [pi3] section
>> be last, it should have an explicit
>> armstub=armstub8.bin line.
>>
>> Listing older RPi* models last is done because some older
>> RPi models ignore the [] notation and listing things last
>> overrides earlier assignments, in this case overriding
>> assignments for newer models. It is a safe notational
>> ordering convention, even for models that do support
>> the [] notation sufficiently.
>>
>> If one depended on RPi3 models processing [] notation,
>> if it does, then another option would have been to move
>> the [rpi4] line to be just before the
>> armstub=armstub8-gic.bin line, causing the RPi3 to skip
>> the assignment and use the default.
>>
>
>
> Hi Mark,
>
> Awesome, it works great! Below is my revised config.txt file now, no more
> boot-up delay and display resolution was effectively changed. Thank you so
> much for sharing your thoughts in well-explained details, now I learned.
>
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [all]
> boot_delay=0
> 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]
> armstub=armstub8-gic.bin
>
> [pi3]
> hdmi_group=2
> hdmi_mode=11
>

Hi Mark,

I did further testing and these two configuration settings (removing [pi4]
and armstub=armstub8-gic.bin lines) below will do too.

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_delay=0
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi3]
hdmi_group=2
hdmi_mode=11

or

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_delay=0
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

hdmi_group=2
hdmi_mode=11

Thanks again for the help!

Archimedes


>

--00000000000003362c05da2e47c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 14, 2022 at 9:50 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Mon, Mar 14, 20=
22 at 8:01 PM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Mar-14, at 02:55, Archimedes Gaviola &=
lt;archim=
edes.gaviola@gmail.com> wrote:



> In the default config.txt file there is [pi4] line. If I'm going t=
o remove this [pi4] line, the boot-up process is very slow. Slow in a sense=
 that some extended time is observed as compared to the default. I already =
tested emphasizing the boot_delay=3D1 but to no avail. The reason why I rem=
oved it is because I want to change the settings of the HDMI display resolu=
tion as changes will not take effect with the [pi4] line in RPi 3B.

> 

> With 14.0-CURRENT (February 24, 2022 snapshot) I have described my res=
olution here https://lists.f=
reebsd.org/archives/freebsd-arm/2022-February/001070.html however with =
the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no longer possib=
le. Any idea what's going on?

> 

> Below is the default config.txt and my current config.txt for referenc=
e.

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [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

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [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

> 

> hdmi_group=3D2

> hdmi_mode=3D11

> armstub=3Darmstub8-gic.bin



armstub8-gic.bin is specific to the BCM2711 and will not

work for the RPi3, as I understand.



armstub=3Darmstub8.bin is the default and is what was being

used for the RPi3 when the [pi4] was in place.



You have the option of listing a [pi3] section last

(after the [pi4] section). To have a [pi3] section

be last, it should have an explicit

armstub=3Darmstub8.bin line.



Listing older RPi* models last is done because some older

RPi models ignore the [] notation and listing things last

overrides earlier assignments, in this case overriding

assignments for newer models. It is a safe notational

ordering convention, even for models that do support

the [] notation sufficiently.



If one depended on RPi3 models processing [] notation,

if it does, then another option would have been to move

the [rpi4] line to be just before the

armstub=3Darmstub8-gic.bin line, causing the RPi3 to skip

the assignment and use the default.


Hi Mark,

Awesome, it works great! Below is my revised config.txt file no=
w, no more boot-up delay and display resolution was effectively changed. Th=
ank you so much for sharing your thoughts in well-explained details, now I =
learned.

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_dela=
y=3D0
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dto=
verlay=3Dmmc
dtoverlay=3Ddisable-bt
device_tree_address=3D0x4000
k=
ernel=3Du-boot.bin

[pi4]
armstub=3Darmstub8-gic.bin

[pi3]<=
br>hdmi_group=3D2
hdmi_mode=3D11

=

Hi Mark,

I did further testing and these two =
configuration settings (removing=20
[pi4] and armstub=3Darmstub8-gic.bin lines) below will do too.

freebsd@generic:~ % cat /boot/msdos/config.txt
[all]boot_delay=3D0
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,spi=
=3Don
dtoverlay=3Dmmc
dtoverlay=3Ddisable-bt
device_tree_address=
=3D0x4000
kernel=3Du-boot.bin

[pi3]
hdmi_group=3D2
hdmi_mod=
e=3D11

or



freebsd@generic:~ % cat /boot/msdos/config.txt
[all]
boot_delay=
=3D0
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dtov=
erlay=3Dmmc
dtoverlay=3Ddisable-bt
device_tree_address=3D0x4000
ke=
rnel=3Du-boot.bin

hdmi_group=3D2
hdmi_mode=3D11

Thanks again for the help!

Archimedes
<=
/div>
=C2=A0




--00000000000003362c05da2e47c1--

From nobody Mon Mar 14 15:10:01 2022
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 109361A0F121
	for ; Mon, 14 Mar 2022 15:10:13 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KHKhz6RKFz3pw8
	for ; Mon, 14 Mar 2022 15:10:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647270604; bh=k51Ul1sV6NoCwqmkupF7ZDkZa8tnoyA04U4QmLAHrgk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MoV7Guy2xajJp6BDq+I1UXSqekPkJlSjwh1XI9ZKo382cau6hFQqSmw+ZJb2HX4FcQNIZohZAQRkYJyArzGIgKHtwJTPdTbWZEDsf+C9Ns53GsqWOIOkMjwTPUnjn9fNp31un910zVGaX+PiVd3UMngiwVIryT0Vih8v5lsrmXE2n6qQRSrXjEqbSDBQoCsqFGJl56b/c4Ml9e09ihwrJfOEIR1G6BqmbQgU2MhIHB3QkiUXoyQKSWsWts1Ym8iQ1+Dy+TnGBJv+nwP9Gdw5L1MfxmR1Hh6YZ4SjOeSAeegu0sdeMGfKIM1ctqxCC9jxp/69EM8XziGGlH6Uu/1I0Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647270604; bh=X+FDKnj/fRSmTURnrS8+E7IfB6wp9dCgsJxyAzOAR8f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BY3kNvdtpwmAs07WWrfis6Mt4eyUyhU5h015/ygAlm0a1yE/ASfTBhDlkSPUK60xsbEwzNIltLN8aBb6FIYBtr2Jy6zhZ+G+Y4nTJlN2DHXKdL42o64YlxfLxNyGbtK8yCQFwJhuSULIXQlEO9udDoLDXUCBUTVlR8I7MC9or44T86hOuUI6eY6g01dlsbeZRW6cHb5CUi7ahc0IJR12GOLAJ2ME5179GfRETJPobllslTJ0fgNEfrg0dMX+Egc0pNj8qmMiL2C24A1NbQ+kIROaohnULvIjLOcx9WoQbAIdcTcTO8eAk/mZ0wxLa3H7/Q6FF8/2a0IRuF9PKVca+w==
X-YMail-OSG: dp1DNj0VM1lo1SpqucLnlve2i_.MD3QxOaBdV9ig0nZUy1jgITMiuGO1pp1Zlp0
 X9UN30lTkzvF.nTOBt5HPiZNdzDqPw07GxuMNolWoCxMJ6Il_wU4obUpWlBf_z9oEKOloIh2OxZ5
 vWVO8K39fclD6CqSaKCNj2JAzjsWUI3.iUj3z6vigG2LDOCW4UAFHcqBf3xhpHxbOP9IFfGBXBMb
 drLdXXkSkMqBS8S_0Mo.SJk2aG1MhxwFTqnN88CR9hXUEuE92Oyjfn1H2ijJyUTOYXFmMvQTc90S
 4ViQWkL60BhPzA9o.Vdyc5APnPy4XmZygSaAk40_sB9.MC4jv_QtFgWupFXSIWkezNAZw4x24jdc
 8CdpCJ8Gik47gqO.ZJV7P6sGTxxaUDFdJEEGpOUq.tRdjyOzLnPBa1PvTEUyfFyMFJ2A2iTKqPiF
 sMEnFO1f1rQUHkhRbHqQKZLSonZpfB3md6Nu7M4Z.orzufMEnpbLp4mYBwscZhcXDq4iDo7Q2x0p
 iY76PzKMJn3goVxEC8cKfqeG6vQhLJ9I0O8MWW.Bc9fgW1XznFXht7TmKht8KNLHLvVEE6afrHE2
 GNQOq3pQvuTUL4hOjm_LbcbTlqi1V1pZaB83S8Cnif2DtKuma9T8cGZMqW_hycfMZMapnu5tFyBF
 MQOXVivPYG8XOXylcn76O6kyiHVux23xrwNIIIkNlYEvFjRM7QYfFSC6Wxzs22bw03O8WhHDRMoU
 0QmjnpClcb3.5jAN2KbzTI47qau3cq7qGR3zKCnuCRJ_d3HaOZSn2rmwp9O6fSDBuW3VeYZUkuuV
 se6b1bfhmOxlQxt4S9u2B2RcX9O2B0l1ptCr8yAzoR7PTo_ywXhmUD5FDca8UUjrx_6rLgl3zeRw
 bQdaYqI4qMM7.MTFY7SdDrLTh8EZxp3V.KmPg3cwWQOUDPZKEhOl7g_yjLX4zIZDPUqUH_VmLDAB
 OAOGByOfK3QL_USJ38H_sBpMpLRETneAlSIr0xr332Y0MwPi9J.9W3kalOR1MvbOs_qXsOxtLkxH
 50elIEHCrNhbvBv__nA.kWPytnjiJRkusEMOINfImzkv8TQb4v7qDyKxNxhKzNtgS8lDNgNXmQZh
 .gKGgAQmyp4SZrdfF9e1sT28Aa.r97iKcSwxL_stpvMy_0yaeP2aTN252SGZ4aoLwBoFO612JI1o
 W6u6hAL9ROzVIUW.ktbQmb1kD3ahj39lpSaSNHZhcd2voabwkPYbtwViQmAwBvSLdpmA6r.NPNdk
 BMrIe9ksD5Hpz7YuwY0klazi87BiJDzoGf035QnfZgNKcHow_JJUsrFm9AJamri.sguP4kryw7zG
 mmzq5_.gkUBr.MvkAwO_WeBURSiM46zzuWrRGQlufUmSF8PZJ1aikxVEurf_1HzQnkTaKcWj3l6y
 hsa14mJs7CgYiFL8fqwEN7hRzWSxUnLgdXs2pFDdpALFxTVw3J_1rELBzYJJVxNuR8uo2DCtwyo_
 rWr0OA722tD5JpHsoZ4TZIo6uE.qrQIlfIlgBDj.UeudQaRtIvTnKLWhXy.7swIQs6BaXKfSqXFL
 4E5SoLAeqBw0OXf599h_DKOrC_2Is5wGlQhxKqKkNyQB16UczV4lZQzAtOf04Rq47SuaKsPGa4th
 UCyol5uNszQy_QUdvGjOWJTkLxsGcCNScuR5dl5ZkWBDmbnp9B2YKbUtJWNtuGXdVrB4u_Uj7.1s
 71vW948mDhbSQ1Wp7VpTuHerLWHny9ZZ3KD8EOrfTd9lRI3pE2BFA_..f_TI_Tieb4UwhznSADnk
 609h5Sg1K3A36wuQalUj9RQl7TUD6TD2MgmPDnl75pa22m3e_j3lhXmdFN0fUqYKs6vjYqtkNwDE
 HBtJ074qLkD.mfAXlG5Csdi8KtPM1l254ld9Y8TV700smYeHGpN605Q0X01mB.HXuM.zjBCERRMj
 lK1YKeBBI4V1CsgMKs2G3SonuoopnoQ9EcaBeab9Nf3gSDPJ11V1uwhlo0TXrLIVVEKlvRoEVx9K
 xWQlBMm1qNUQkHKb2KPTwZyuOxtXbx7RBqAbbJo5zGTGA3v.z2TqcUkwuLe2PgbBAeuqPV3N7AzP
 ThSu90nG898SJApxdE2OjoAY36GJMIeg1IdfbtdV9WzyrfMYuX7f7xydMYXBcph1NU1j30UMBSul
 9oHd_cVuhiaWQIaCne2k.QfIjy2wepustltDpdK9lopH7y9vH8lShvvF96E5T4vbssUrqj89X78b
 c9ORTOPM6f2FCc9vQITsY8uFPi4g0Kx0u1KaTqup1LvurftKXNM6OmEq7VJa2WYlwZY6QGtQPHrT
 enfedGrdAsNCuTrpI
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Mar 2022 15:10:04 +0000
Received: by kubenode513.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fbe29f789e7d946fe64c5af860a70ae2;
          Mon, 14 Mar 2022 15:10:02 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Raspberry Pi 3B Slow Boot-up
From: Mark Millard 
In-Reply-To: 
Date: Mon, 14 Mar 2022 08:10:01 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com>
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KHKhz6RKFz3pw8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MoV7Guy2;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4581
Lines: 155

Hello.

On 2022-Mar-14, at 07:12, Archimedes Gaviola =
 wrote:

> On Mon, Mar 14, 2022 at 9:50 PM Archimedes Gaviola =
 wrote:
>=20
> On Mon, Mar 14, 2022 at 8:01 PM Mark Millard  =
wrote:
> On 2022-Mar-14, at 02:55, Archimedes Gaviola =
 wrote:
>=20
> > In the default config.txt file there is [pi4] line. If I'm going to =
remove this [pi4] line, the boot-up process is very slow. Slow in a =
sense that some extended time is observed as compared to the default. I =
already tested emphasizing the boot_delay=3D1 but to no avail. The =
reason why I removed it is because I want to change the settings of the =
HDMI display resolution as changes will not take effect with the [pi4] =
line in RPi 3B.
> >=20
> > With 14.0-CURRENT (February 24, 2022 snapshot) I have described my =
resolution here =
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html =
however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no =
longer possible. Any idea what's going on?
> >=20
> > Below is the default config.txt and my current config.txt for =
reference.
> >=20
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [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
> >=20
> > [pi4]
> > hdmi_safe=3D1
> > armstub=3Darmstub8-gic.bin
> >=20
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [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
> >=20
> > hdmi_group=3D2
> > hdmi_mode=3D11
> > armstub=3Darmstub8-gic.bin
>=20
> armstub8-gic.bin is specific to the BCM2711 and will not
> work for the RPi3, as I understand.
>=20
> armstub=3Darmstub8.bin is the default and is what was being
> used for the RPi3 when the [pi4] was in place.
>=20
> You have the option of listing a [pi3] section last
> (after the [pi4] section). To have a [pi3] section
> be last, it should have an explicit
> armstub=3Darmstub8.bin line.
>=20
> Listing older RPi* models last is done because some older
> RPi models ignore the [] notation and listing things last
> overrides earlier assignments, in this case overriding
> assignments for newer models. It is a safe notational
> ordering convention, even for models that do support
> the [] notation sufficiently.
>=20
> If one depended on RPi3 models processing [] notation,
> if it does, then another option would have been to move
> the [rpi4] line to be just before the
> armstub=3Darmstub8-gic.bin line, causing the RPi3 to skip
> the assignment and use the default.
>=20
>=20
> Hi Mark,
>=20
> Awesome, it works great! Below is my revised config.txt file now, no =
more boot-up delay and display resolution was effectively changed. Thank =
you so much for sharing your thoughts in well-explained details, now I =
learned.
>=20
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [all]
> boot_delay=3D0
> arm_64bit=3D1
> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
> dtoverlay=3Dmmc
> dtoverlay=3Ddisable-bt
> device_tree_address=3D0x4000
> kernel=3Du-boot.bin
>=20
> [pi4]
> armstub=3Darmstub8-gic.bin
>=20
> [pi3]
> hdmi_group=3D2
> hdmi_mode=3D11
>=20
> Hi Mark,
>=20
> I did further testing and these two configuration settings (removing =
[pi4] and armstub=3Darmstub8-gic.bin lines) below will do too.
>=20
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [all]
> boot_delay=3D0
> arm_64bit=3D1
> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
> dtoverlay=3Dmmc
> dtoverlay=3Ddisable-bt
> device_tree_address=3D0x4000
> kernel=3Du-boot.bin
>=20
> [pi3]
> hdmi_group=3D2
> hdmi_mode=3D11
>=20
> or
>=20
> freebsd@generic:~ % cat /boot/msdos/config.txt
> [all]
> boot_delay=3D0
> arm_64bit=3D1
> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
> dtoverlay=3Dmmc
> dtoverlay=3Ddisable-bt
> device_tree_address=3D0x4000
> kernel=3Du-boot.bin
>=20
> hdmi_group=3D2
> hdmi_mode=3D11
>=20

The BCM2711 has both the older style hardware and the
new-to-RPi*'s gic. These two alternatives that do not
mention armstub8-gic.bin are having the BCM2711 use
the older, less capable type of hardware instead of
using the newer, more capable gic. (Or, at least,
that is what is explicitly initialized.)

You are better off with the solution that has the
[pi4] and armstub=3Darmstub8-gic.bin lines so that
the gic is explicitly initialized.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Mar 14 15:24:09 2022
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 A64161A11FAE
	for ; Mon, 14 Mar 2022 15:24:21 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4KHL1K3HLQz3rn3
	for ; Mon, 14 Mar 2022 15:24:21 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1647271461;
	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=HF7u6OFQCJ0wrY3jMUhUaG72FXhnEzMstJsCf75Fr98=;
	b=IvSCMaPWhjtKNAuDpNeZ4fWsaPSTjpgsCvkq07wZpf02KOr7qQj2JhYwb3FRyCoBiuYRdl
	qhr/bLxOR3EvNE9AFMZMVLd2q2DXqWApvSCShvGZdZKm46DI6GG7WGqpHOZyADGbLX83k0
	Nk3m4l5Ldy96J/hrPRn4notdyC65cNP5UbdzQ85PsxQAfpgUL/rekmNW5XUUNNFu9AWWAk
	E5x6IGAcI0mRQnewG6wO3sfx6K0S5O8/Xy0vSvViDaNrUh3QmHksLIwDStJ0gbr8w47EO+
	lrULPADj0ljXxJHcxMPfjbaDKJj/PKed3z5IqRgFoQDsj91fwNXWAHMquMWcEw==
Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 26B66267D
	for ; Mon, 14 Mar 2022 15:24:21 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-qv1-f51.google.com with SMTP id kl20so12736890qvb.10
        for ; Mon, 14 Mar 2022 08:24:21 -0700 (PDT)
X-Gm-Message-State: AOAM532fJ8/5rlR86UtbDzynTrQHYxGRdT7tfefjQ4daN8txP3oUk2Z8
	dIFyxk6iooRSoiiWmCR8yobUNu0KY4IondKrxEE=
X-Google-Smtp-Source: ABdhPJzhYAJxfK3j89dvQISq5FX1h6ucDvM37P8SCxi5NNvN5nZAuFAPR3Es7sy8myNp2Icl2nIaYhpslpNGyVfRlXw=
X-Received: by 2002:ad4:5cc2:0:b0:440:a6cb:5c13 with SMTP id
 iu2-20020ad45cc2000000b00440a6cb5c13mr5301078qvb.70.1647271460550; Mon, 14
 Mar 2022 08:24:20 -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: Kyle Evans 
Date: Mon, 14 Mar 2022 10:24:09 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Raspberry Pi 3B Slow Boot-up
To: Archimedes Gaviola 
Cc: freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647271461;
	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=HF7u6OFQCJ0wrY3jMUhUaG72FXhnEzMstJsCf75Fr98=;
	b=D8l6l9qXHxKvnyDr4W9k2mxYEUc+itOQztQSSrff5FM2YncBwflVS/yVySNxmMNuqiIbVt
	XsYZyKp0BMS++3WxyjKQtrx5rJeuIVriDtmopy1gh+RDG5iax9iEHkrKximfN+NYlUwMDU
	QO0gpkDQEPZnY417trDJ5IVB5OzdgryPnOUgt1+PuPRiN7IGf+o8jn5uDp0wKRJWi5ZQxL
	96mmb6WoodZXAgO7hct+YaFHYqjraFaMnDmKjlSxYQCTuuNSKnRSTljCAeStvpSoX7wrhK
	DLqRSCoBwGd+fVJ1QBiFiDj7BPu4WWm41U4jZcFEtuTfLGmfPSUcLlsx/5g0IA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647271461; a=rsa-sha256; cv=none;
	b=tqu3D+kG9xPw4c7hcEJt5xxX4BqkDBrhOXaXHyceNbbaBPtuXbfOGClDnwfqyRmT+xF/GO
	5WU1L5GjLoVDLT3CdbUGZuvy6DwHQgcbxCcZsC0J5scAzCNwC74/edEnkqL7LeL8OAvefe
	1oXOdzw4o3px/srZ0Q/KyrsGTG73XHQCQhHex2CAbudL7RgWfLDGMc9p4J5ckJpj+IXMol
	wn7AaRvOJ1CG2jZBzOtT9WYY+QaUTReSW6oA9ZfvPZpoICxzngoQUnuq237oDdcb2zLoYa
	QuePZtrX3qKzz+drC9n8yTyk0Ivmcy0v17jM9QMsgBIby6ENz/q26ky1RLlCXg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1097
Lines: 26

On Mon, Mar 14, 2022 at 4:56 AM Archimedes Gaviola
 wrote:
>
> Hi,
>
> In the default config.txt file there is [pi4] line. If I'm going to remov=
e this [pi4] line, the boot-up process is very slow. Slow in a sense that s=
ome extended time is observed as compared to the default. I already tested =
emphasizing the boot_delay=3D1 but to no avail. The reason why I removed it=
 is because I want to change the settings of the HDMI display resolution as=
 changes will not take effect with the [pi4] line in RPi 3B.
>
> With 14.0-CURRENT (February 24, 2022 snapshot) I have described my resolu=
tion here https://lists.freebsd.org/archives/freebsd-arm/2022-February/0010=
70.html however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's=
 no longer possible. Any idea what's going on?
>

I don't think I'd ever tried tampering with config.txt after my
initial setup, but I found there was something weird with the default
MMC stack and it wouldn't tune sdhci frequency on any of my Pi3/Pi4.
GENERIC-MMCCAM performed wonderfully for me.

Thanks,

Kyle Evans

From nobody Mon Mar 14 15:37:46 2022
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 35FB11A14772
	for ; Mon, 14 Mar 2022 15:37:46 +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 4KHLJn6fj9z3t44
	for ; Mon, 14 Mar 2022 15:37:45 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 C5145103C3
	for ; Mon, 14 Mar 2022 15:37:45 +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 22EFbjt4032601
	for ; Mon, 14 Mar 2022 15:37:45 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22EFbjKY032600
	for freebsd-arm@FreeBSD.org; Mon, 14 Mar 2022 15:37:45 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 262554] [armv7] [GENERICSD] release.sh fails
Date: Mon, 14 Mar 2022 15:37:46 +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: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: matteo@FreeBSD.org
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 keywords 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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647272266;
	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=74PFONWJkGM4ZewYDaurZ9CbkDvCYm+Qk4qXxdLlfa0=;
	b=tG+32jr6GtnONCkRgfshDjp/bZ6/Q0xKGJpZOiVBUz0F+vpwKOl6QYQ+c7kv78yoJ3sZyh
	TlXPqMsonrKMuYZRUGdeUPSMaqzqMi+lgaXlKrkeTT8tK7yaR3F2w+JoE+BSbJ8QwtDZFg
	MTCeJc8V/Dyk04gjmP39kpny5hXO9suMy5myc2cf8LwjN+9/QB3svapPJoBTIjGXHzWNur
	8QXwl/1KCQ2b35D42i8ifDrOXer/IOZlzAVo5F71yG76fjmMFS7VZ/YtlyN20eFJM1TeDj
	Bq9UYtm7KBVz9uH7dw7Q7JuYL2kvQSFvTUKXt8SypBQt4IY/nUxzm1yCJgxHOA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647272266; a=rsa-sha256; cv=none;
	b=KsGYERIkixQv86L6X3izJRdmwrPd8nbzPKci9dnJu+GFZ7nIYe++ORWddkEQOeqsKA1wTm
	G2KKGuz/NnEHWN/4O41CFIKFmn0lEVNCeOsle8jHrO2cS9sB1Naez718umVLU/LoC5DDqw
	9GgH4F7C8X4a4m9g92xIZGfKk/r2iNBlYK22JlylMaZVJ9N44Y2lFCUGZOqjf8tbIA8vIG
	+TYeHCiA3c2boxE6uc+85vdjY9is9Fteo2OYHtQj+KQ+Cvkm9YUxTJY7WdMja7H0DJoU5/
	aqH2maBRPG48DWsey3hs20Z7lq0Iiwc3PlGE3K+ozgwSjTvrp6C8BhspthPNtQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2108
Lines: 63

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262554

            Bug ID: 262554
           Summary: [armv7] [GENERICSD] release.sh fails
           Product: Base System
           Version: CURRENT
          Hardware: arm
                OS: Any
            Status: New
          Keywords: regression
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: matteo@FreeBSD.org

I am trying to build a vanilla -CURRENT image for my beaglebone enhanced.=20

In release/arm/GENERICSD.conf, I added info about CHROOT_DIR, MAKE_CONF,
SRC_CONF (both with harmless contents, imho), and changed GENERIC to
GENERIC-NODEBUG.=20

I run sh ./release.sh -c arm/GENERICSD.conf and got the following:

--------------------------------------------------------------
>>> Kernel(s)  GENERIC-NODEBUG built in 94 seconds, ncpu: 40, make -j20
--------------------------------------------------------------
md0 created
md0s1 added
active set on md0s1
/dev/md0s1: 102264 sectors in 12783 FAT16 clusters (4096 bytes/cluster)
BytesPerSec=3D512 SecPerClust=3D8 ResSectors=3D1 FATs=3D2 RootDirEnts=3D512=
 Media=3D0xf0
FATsecs=3D50 SecPerTrack=3D63 Heads=3D255 HiddenSecs=3D0 HugeSectors=3D1024=
00
md0s2 added
md0s2 created
gpart: No partitioning scheme found on geom /dev/md0s2. Create one first us=
ing
'gpart create'.

The error is raised on line 80 of tools/arm.subr:

chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k /dev/${mddev}s2

It seems quite weird that it fails on this line, because there is a "gpart
create" command on line 79. The whole sequence of commands here looks corre=
ct
to me. Could it be a timing issue?=20

The building host is an amd64 running -CURRENT (from yesterday)

By the way, if I change PART_SCHEME=3D"GPT" and change the arm_install_uboo=
t_*
functions in GENERICSD.conf,  to account for the different names of partiti=
ons
in GPT vs MBR, I can successfully build a GPT image (I haven't tried bootin=
g it
yet though).

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Mar 15 04:57:26 2022
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 4850E1A1D4C9
	for ; Tue, 15 Mar 2022 04:57:39 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4KHh3k3rgqz3QtZ
	for ; Tue, 15 Mar 2022 04:57:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id hw13so37213143ejc.9
        for ; Mon, 14 Mar 2022 21:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=3/ihnUfY1qxhWGRFL8BMOXBTE9yvfAvVKvK00vriSrQ=;
        b=XWKnU40rAiZJj2QFBDs+y5bHIW4cOOi0t/W3TJqY0dckPocJGFPknM+NPCY/o1lzAP
         p/J8qL2JV4fmPI68e0g8tJrQ/NfRXxGx1YJKBwLDf+TRNhHNibTkB1M2RJ4Nz1GtA9pr
         zpUCGch0h2wloXD1csWWausND7OhTSUvpfW62/N1CfTYv8swRrcSbJmRtd7fgcIeKGCF
         fp0JfmprOukg7PzgipYmVwV0DCzKEaWrGSpgxzZpZOTX6bJp4QpwCaetDnkzhpJAOO6X
         K8BVSIhlELWfJw2S6rssfAD9QzljVZM/0R6UCz30ZGIY+esyodILpyf/WfUj9yFPUbjj
         F2TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=3/ihnUfY1qxhWGRFL8BMOXBTE9yvfAvVKvK00vriSrQ=;
        b=AhXCmgFRd+UG6r4qMwDW33kwzNhtkXOgez5chdLhNRJ6iE0IuMaIclqb5FG8lEEpkN
         rq6p0Gv5u+5B5DUvZ8faOzybfiiQ9QxqdRHfv9T83yUPFcwEiSewrYAdxqhnK6kKOPju
         ubmPrl4FtyBTIDoSY/53uzyARFGDub3qklOSpFUNg0m1gfQcztwYbIc6jZcuOt+Z0baY
         BIguJvE3DBZr/1ZmQrAf7VkhlwSNckyvOwVZGBChhAV6+dmqpdbpMhltEUu3zdPeXMoF
         EhxTCNvbYmXilL/9qL7XGbCPFobf2w8PLa1Atdc9gwyZpVkGfgIBU8gqmae5VBxyVfZP
         2ucQ==
X-Gm-Message-State: AOAM532d9gqZjcvL2eaNj7oOXuKeEhdL/GdIWRKJAwcyLGf6M++wI9BS
	drZTo73vcAedwiH9h0lW87D6sVBIuGwRSakRYiUcSVJzxypS3w==
X-Google-Smtp-Source: ABdhPJyv6MOq8LT8wtIwflbL/49uC5Be4AJwZ1UskWzV1cb5witJBWiW6vlc2999TioMrdhJWNF4otXVM1VT3Jsrbck=
X-Received: by 2002:a17:907:6d9d:b0:6da:7d4c:287f with SMTP id
 sb29-20020a1709076d9d00b006da7d4c287fmr20895059ejc.741.1647320257478; Mon, 14
 Mar 2022 21:57:37 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 15 Mar 2022 12:57:26 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000c7449305da3aa2b0"
X-Rspamd-Queue-Id: 4KHh3k3rgqz3QtZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=XWKnU40r;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 16161
Lines: 441

--000000000000c7449305da3aa2b0
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 14, 2022 at 6:12 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Mon, Mar 14, 2022 at 5:31 PM Hans Petter Selasky 
> wrote:
>
>> On 3/14/22 10:20, Archimedes Gaviola wrote:
>> > On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <
>> > archimedes.gaviola@gmail.com> wrote:
>> >
>> >>
>> >>
>> >> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <
>> >> archimedes.gaviola@gmail.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky > >
>> >>> wrote:
>> >>>
>> >>>> On 3/12/22 16:31, Archimedes Gaviola wrote:
>> >>>>>>
>> >>>>>> IOERROR usually means an electrical error. The RPI3B will use a
>> >>>>>> transaction translator for the FULL speed traffic, which is driven
>> by
>> >>>>>> software.
>> >>>>>
>> >>>>
>> >>>> Hi Archimedes,
>> >>>>
>> >>>>> Hi Hans,
>> >>>>>
>> >>>>> I'm curious about the transaction translator you've mentioned, any
>> >>>> idea why
>> >>>>> there's a need for translation and what is being translated?
>> >>>>
>> >>>> When the High Speed USB HUB was invented, there was a need to support
>> >>>> FULL and LOW speed USB transactions. Because FULL and LOW speed
>> >>>> transactions are slow and take up much bandwidth, a transactions
>> >>>> translator was invented which translates between High Speed USB and
>> >>>> FULL/LOW speed USB. That means the RPi 3B consists of a single USB
>> HIGH
>> >>>> speed port, followed by a USB HUB. These transactions are not
>> visible in
>> >>>> usbdump .
>> >>>>
>> >>>>   >Does this only
>> >>>>> happen when RPi 3B (acting as host controller) is transmitting data
>> to
>> >>>> the
>> >>>>> Epson printer? Are translation events visible in the usbdump? In
>> this
>> >>>> case
>> >>>>> there's a way to possibly track what's going on and how to identify
>> any
>> >>>>> info that is being translated?
>> >>>>
>> >>>> By turning on the HC debugging, you can possibly track via debug
>> >>>> messages what is going on. Maybe it is a timing issue, that the SW is
>> >>>> too slow serving the micro transactions.
>> >>>>
>> >>>> Any idea also if translation is being
>> >>>>> performed in RPi 4B?
>> >>>>
>> >>>> The later RPi's do the transaction translator bits in HW or via the
>> XHCI
>> >>>> block.
>> >>>>
>> >>>> As I have conducted several printing cases with my
>> >>>>> Epson printer without any issues with either of the 4 ports.
>> >>>>>
>> >>>>> Sorry for these questions as I am catching-up to the USB technology
>> >>>>> internal workings under the hood.
>> >>>>
>> >>>> You are welcome!
>> >>>>
>> >>>
>> >>>
>> >>> Thank you so much Hans for answering my questions, really appreciate
>> it!
>> >>> I have a much better understanding now.
>> >>>
>> >>> I came from testing with 13.0-RELEASE having the same RPi 3B hardware
>> and
>> >>> setup and it's very stable. I haven't encountered any IOERROR and
>> >>> incomplete printed outputs that were encountered with 14.0-CURRENT
>> >>> (February 24, 2022). By the way, I found in the repository here
>> >>> https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/
>> >>> that there were two latest snapshots released dated March 3 and March
>> 10,
>> >>> respectively. I need to take printing tests first, especially the
>> latest to
>> >>> check if it also manifests before I go back to the Feb. 24 snapshot
>> and do
>> >>> a thorough test with debugging. I'll provide updates for any
>> observations.
>> >>>
>> >>> Thanks,
>> >>> Archimedes
>> >>>
>> >>
>> >>
>> >> Hi Hans,
>> >>
>> >> Initial testing conducted with the latest 14.0-CURRENT (March 10, 2022
>> >> snapshot) seems to be stable. Another test will be performed tomorrow.
>> >>
>> >> Thanks,
>> >> Archimedes
>> >>
>> >
>> > Hi Hans,
>> >
>> > I still encountered the issue this morning with 14.0-CURRENT (March 10,
>> > 2022 snapshot). I just noticed when I left my RPi 3B idle for a long
>> period
>> > of time (2-3 hours and more) and started printing, then the issue
>> pops-up.
>> > Another concern I encountered was when I started enabling
>> > hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network
>> > interface (remotely connected over SSH from my laptop) seemed to freeze
>> and
>> > I got disconnected.
>> >
>> > freebsd@generic:~ % uname -a
>> > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
>> > main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022
>> > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
>> > arm64
>> >
>> > root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=1
>> > hw.usb.dwc_otg.debug: 0 -> 1
>> >
>> > See attached initial debug info (no printing testing yet).
>>
>
>
> Hi Hans,
>
>
>>
>> Hi,
>>
>> Nothing obvious there.
>>
>> Maybe you need to add a conditional to DPRINTF's in the fast path, to
>> only print for a certain device, to reduce the debug prints.
>>
>> How many USB devices are connected?
>>
>
> Only two devices, one is my USB keyboard and the other one is my Epson
> printer.
>
>
>>
>> One experiment you might try is to comment out:
>>
>> usbd_transfer_submit(xfer);
>>
>> in
>>
>> uhub_intr_callback()
>>
>> in
>>
>> /usr/src/sys/dev/usb/usb_hub.c
>>
>> It will save some USB resources, but also makes USB enumeration a bit
>> slower.
>
>
> This is noted, I'll try.
>
>
>> Maybe the chip is out of USB HW endpoints and is only polling
>> for RX data ...
>>
>
> This is noted as well, we'll probably see later what's going on. I'll get
> back to you once I recompile the kernel and perform the testing.
>
> Thanks,
> Archimedes
>


Hi Hans,

I did comment-out usbd_transfer_submit(xfer) and still the same behavior is
experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
freeze as my USB keyboard is unresponsive and I cannot connect over the
Ethernet NIC with SSH. I can't print and capture.

freebsd@generic:/usr/src/sys/dev/usb % diff -Nur usb_hub.c.orig usb_hub.c
--- usb_hub.c.orig      2022-03-14 22:37:03.162678000 +0800
+++ usb_hub.c   2022-03-14 22:38:23.832660000 +0800
@@ -202,7 +202,7 @@

        case USB_ST_SETUP:
                usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer));
-               usbd_transfer_submit(xfer);
+               /* usbd_transfer_submit(xfer); */
                break;

Let me know our next step.

Thanks,
Archimedes

--000000000000c7449305da3aa2b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 14, 2022 at 6:12 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Mon, Mar 14, 20=
22 at 5:31 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/14/22 10:20, Archimedes Gaviola wrote=
:

> On Sun, Mar 13, 2022 at 11:25 PM Archimedes Gaviola <

> arch=
imedes.gaviola@gmail.com> wrote:

> 

>>

>>

>> On Sun, Mar 13, 2022 at 2:27 PM Archimedes Gaviola <

>> =
archimedes.gaviola@gmail.com> wrote:

>>

>>>

>>>

>>> On Sun, Mar 13, 2022 at 12:38 AM Hans Petter Selasky <hps@selasky.org>

>>> wrote:

>>>

>>>> On 3/12/22 16:31, Archimedes Gaviola wrote:

>>>>>>

>>>>>> IOERROR usually means an electrical error. The RPI=
3B will use a

>>>>>> transaction translator for the FULL speed traffic,=
 which is driven by

>>>>>> software.

>>>>>

>>>>

>>>> Hi Archimedes,

>>>>

>>>>> Hi Hans,

>>>>>

>>>>> I'm curious about the transaction translator you&#=
39;ve mentioned, any

>>>> idea why

>>>>> there's a need for translation and what is being t=
ranslated?

>>>>

>>>> When the High Speed USB HUB was invented, there was a need=
 to support

>>>> FULL and LOW speed USB transactions. Because FULL and LOW =
speed

>>>> transactions are slow and take up much bandwidth, a transa=
ctions

>>>> translator was invented which translates between High Spee=
d USB and

>>>> FULL/LOW speed USB. That means the RPi 3B consists of a si=
ngle USB HIGH

>>>> speed port, followed by a USB HUB. These transactions are =
not visible in

>>>> usbdump .

>>>>

>>>>=C2=A0 =C2=A0>Does this only

>>>>> happen when RPi 3B (acting as host controller) is tran=
smitting data to

>>>> the

>>>>> Epson printer? Are translation events visible in the u=
sbdump? In this

>>>> case

>>>>> there's a way to possibly track what's going o=
n and how to identify any

>>>>> info that is being translated?

>>>>

>>>> By turning on the HC debugging, you can possibly track via=
 debug

>>>> messages what is going on. Maybe it is a timing issue, tha=
t the SW is

>>>> too slow serving the micro transactions.

>>>>

>>>> Any idea also if translation is being

>>>>> performed in RPi 4B?

>>>>

>>>> The later RPi's do the transaction translator bits in =
HW or via the XHCI

>>>> block.

>>>>

>>>> As I have conducted several printing cases with my

>>>>> Epson printer without any issues with either of the 4 =
ports.

>>>>>

>>>>> Sorry for these questions as I am catching-up to the U=
SB technology

>>>>> internal workings under the hood.

>>>>

>>>> You are welcome!

>>>>

>>>

>>>

>>> Thank you so much Hans for answering my questions, really appr=
eciate it!

>>> I have a much better understanding now.

>>>

>>> I came from testing with 13.0-RELEASE having the same RPi 3B h=
ardware and

>>> setup and it's very stable. I haven't encountered any =
IOERROR and

>>> incomplete printed outputs that were encountered with 14.0-CUR=
RENT

>>> (February 24, 2022). By the way, I found in the repository her=
e

>>> https://download.f=
reebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/

>>> that there were two latest snapshots released dated March 3 an=
d March 10,

>>> respectively. I need to take printing tests first, especially =
the latest to

>>> check if it also manifests before I go back to the Feb. 24 sna=
pshot and do

>>> a thorough test with debugging. I'll provide updates for a=
ny observations.

>>>

>>> Thanks,

>>> Archimedes

>>>

>>

>>

>> Hi Hans,

>>

>> Initial testing conducted with the latest 14.0-CURRENT (March 10, =
2022

>> snapshot) seems to be stable. Another test will be performed tomor=
row.

>>

>> Thanks,

>> Archimedes

>>

> 

> Hi Hans,

> 

> I still encountered the issue this morning with 14.0-CURRENT (March 10=
,

> 2022 snapshot). I just noticed when I left my RPi 3B idle for a long p=
eriod

> of time (2-3 hours and more) and started printing, then the issue pops=
-up.

> Another concern I encountered was when I started enabling

> hw.usb.dwc_otg.debug but after 1-2 minutes my USB keyboard and network=


> interface (remotely connected over SSH from my laptop) seemed to freez=
e and

> I got disconnected.

> 

> freebsd@generic:~ % uname -a

> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0

> main-n253697-f1d450ddee6: Thu Mar 10 09:32:38 UTC 2022

> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERI=
C

> arm64

> 

> root@generic:~ # sysctl -w hw.usb.dwc_otg.debug=3D1

> hw.usb.dwc_otg.debug: 0 -> 1

> 

> See attached initial debug info (no printing testing yet).


Hi Hans,
=C2=A0
=




Hi,



Nothing obvious there.



Maybe you need to add a conditional to DPRINTF's in the fast path, to <=
br>
only print for a certain device, to reduce the debug prints.



How many USB devices are connected?

Onl=
y two devices, one is my USB keyboard and the other one is my Epson printer=
.
=C2=A0



One experiment you might try is to comment out:



usbd_transfer_submit(xfer);



in



uhub_intr_callback()



in



/usr/src/sys/dev/usb/usb_hub.c



It will save some USB resources, but also makes USB enumeration a bit 

slower. 

This is noted, I'll try.
=C2=A0
=
Maybe the chip is out of USB HW endpoints and is only polling 

for RX data ...

This is noted as well, =
we'll probably see later what's going on. I'll get back to you =
once I recompile the kernel and perform the testing.

Thanks,
Archimedes

=


Hi Hans,

I did comment-o=
ut=20
usbd_transfer_submit(xfer) and still the same behavior is experienced when =
hw.usb.dwc_otg.debug is enabled. The system seems to freeze as my USB keybo=
ard is unresponsive and I cannot connect over the Ethernet NIC with SSH. I =
can't print and capture.

freebsd@generic:/=
usr/src/sys/dev/usb % diff -Nur usb_hub.c.orig usb_hub.c
--- usb_hub.c.o=
rig =C2=A0 =C2=A0 =C2=A02022-03-14 22:37:03.162678000 +0800
+++ usb_hub.=
c =C2=A0 2022-03-14 22:38:23.832660000 +0800
@@ -202,7 +202,7 @@

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case USB_ST_SETUP:
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_=
max_len(xfer));
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usbd_=
transfer_submit(xfer);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 /* usbd_transfer_submit(xfer); */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 break;

Let me know our next =
step.

Thanks,
Archimedes
=
=C2=A0


--000000000000c7449305da3aa2b0--

From nobody Tue Mar 15 05:00:37 2022
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 B26401A1ED2D
	for ; Tue, 15 Mar 2022 05:00:49 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4KHh7N5Xhwz3hJW
	for ; Tue, 15 Mar 2022 05:00:48 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id bg10so38690782ejb.4
        for ; Mon, 14 Mar 2022 22:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=od0ynYMc2QxgYrH2/LIQYJU13jFuefgsh0w4dLJUQ5w=;
        b=CR9hma6ynozxXXejfwhTzm2Sqf7KlfBTirb9Ka3r+OD3lpNjg5WD7Cg3bf076jSkPX
         uoulypPzcEKSZOcoLHAjOtGYia8he0GsHnZWCymEsBeGcUaAD7dwobB/ssKug3SbL5kq
         6ptRHPQ5f8vVhzWBBk0z7bcZumnDxJlbdzFDAmM5Uv5Q9efTINJRXZyWMtMKygdQcWmj
         w00TvlJbobGP86Jjremjy+YquOIkniyL12K6/9foU1rQ9rnQQ2u5cCK+TUkzhD2wpJ0J
         kdMJpPEdv+Ei3LPCXf0XK4MAHMzaNwXN2Elhi/5fnECefruXAHjnF50bAjy1narrmgNY
         VQxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=od0ynYMc2QxgYrH2/LIQYJU13jFuefgsh0w4dLJUQ5w=;
        b=OLsRyeZpR1J3zui68d6FSr9BOisv5qsRQwhusxw7K5oNHZnOpc8GTuuS/WLHDszFLz
         uVqhZ/yjKiog8CW26ZJJOt0AhOPXG6E2HyoCOqbjzUV+wpgetWurQK0kMMfRbeaDbxcH
         RYdAOITZW3HkoHPdYWksP3i7yPJ7YHac0FafIob1t/EH0oFN1vK44+1iULKxlgo7Bssf
         O0DYnMm01ogTHjU2kX/zqesXVj1ENoLDr18+K18ucOG7t06YQ/sA+9lxti9dHXw11c/m
         OtN/tyM2XWBFZM5Q/VMp2CfEhREyFpxQuAydBAcbgcNwtGwetr3bnXQ65LuDOm7pj00R
         dReA==
X-Gm-Message-State: AOAM531gThJ06FFDVKPl9T05/GHPgKeAl2AHzP5eQtMk/q1vDeyflim+
	6zu5vPGzDIQKQqlSHffkdkcYbSjTTk6ilWSX19KF4V9mmQI=
X-Google-Smtp-Source: ABdhPJwkGgYsVoxSmUmJxg0VTuhogWLMxWtS/YJPzVWlfENKZUN18aTu0eEcVvoyr3RpVe7xHcXJdxVcuv4nbhNH6Dk=
X-Received: by 2002:a17:906:730c:b0:6d6:f8f2:fb92 with SMTP id
 di12-20020a170906730c00b006d6f8f2fb92mr20213938ejc.370.1647320447853; Mon, 14
 Mar 2022 22:00:47 -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: 
 <71491D61-415D-4096-9BB1-CE07DCDFE185@yahoo.com> 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 15 Mar 2022 13:00:37 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Slow Boot-up
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000002026fd05da3aae1d"
X-Rspamd-Queue-Id: 4KHh7N5Xhwz3hJW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=CR9hma6y;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11575
Lines: 331

--0000000000002026fd05da3aae1d
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 14, 2022 at 11:10 PM Mark Millard  wrote:

> Hello.
>
> On 2022-Mar-14, at 07:12, Archimedes Gaviola 
> wrote:
>
> > On Mon, Mar 14, 2022 at 9:50 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >
> > On Mon, Mar 14, 2022 at 8:01 PM Mark Millard  wrote:
> > On 2022-Mar-14, at 02:55, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >
> > > In the default config.txt file there is [pi4] line. If I'm going to
> remove this [pi4] line, the boot-up process is very slow. Slow in a sense
> that some extended time is observed as compared to the default. I already
> tested emphasizing the boot_delay=1 but to no avail. The reason why I
> removed it is because I want to change the settings of the HDMI display
> resolution as changes will not take effect with the [pi4] line in RPi 3B.
> > >
> > > With 14.0-CURRENT (February 24, 2022 snapshot) I have described my
> resolution here
> https://lists.freebsd.org/archives/freebsd-arm/2022-February/001070.html
> however with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no
> longer possible. Any idea what's going on?
> > >
> > > Below is the default config.txt and my current config.txt for
> reference.
> > >
> > > freebsd@generic:~ % cat /boot/msdos/config.txt
> > > [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
> > >
> > > freebsd@generic:~ % cat /boot/msdos/config.txt
> > > [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
> > >
> > > hdmi_group=2
> > > hdmi_mode=11
> > > armstub=armstub8-gic.bin
> >
> > armstub8-gic.bin is specific to the BCM2711 and will not
> > work for the RPi3, as I understand.
> >
> > armstub=armstub8.bin is the default and is what was being
> > used for the RPi3 when the [pi4] was in place.
> >
> > You have the option of listing a [pi3] section last
> > (after the [pi4] section). To have a [pi3] section
> > be last, it should have an explicit
> > armstub=armstub8.bin line.
> >
> > Listing older RPi* models last is done because some older
> > RPi models ignore the [] notation and listing things last
> > overrides earlier assignments, in this case overriding
> > assignments for newer models. It is a safe notational
> > ordering convention, even for models that do support
> > the [] notation sufficiently.
> >
> > If one depended on RPi3 models processing [] notation,
> > if it does, then another option would have been to move
> > the [rpi4] line to be just before the
> > armstub=armstub8-gic.bin line, causing the RPi3 to skip
> > the assignment and use the default.
> >
> >
> > Hi Mark,
> >
> > Awesome, it works great! Below is my revised config.txt file now, no
> more boot-up delay and display resolution was effectively changed. Thank
> you so much for sharing your thoughts in well-explained details, now I
> learned.
> >
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [all]
> > boot_delay=0
> > 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]
> > armstub=armstub8-gic.bin
> >
> > [pi3]
> > hdmi_group=2
> > hdmi_mode=11
> >
> > Hi Mark,
> >
> > I did further testing and these two configuration settings (removing
> [pi4] and armstub=armstub8-gic.bin lines) below will do too.
> >
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [all]
> > boot_delay=0
> > arm_64bit=1
> > dtparam=audio=on,i2c_arm=on,spi=on
> > dtoverlay=mmc
> > dtoverlay=disable-bt
> > device_tree_address=0x4000
> > kernel=u-boot.bin
> >
> > [pi3]
> > hdmi_group=2
> > hdmi_mode=11
> >
> > or
> >
> > freebsd@generic:~ % cat /boot/msdos/config.txt
> > [all]
> > boot_delay=0
> > arm_64bit=1
> > dtparam=audio=on,i2c_arm=on,spi=on
> > dtoverlay=mmc
> > dtoverlay=disable-bt
> > device_tree_address=0x4000
> > kernel=u-boot.bin
> >
> > hdmi_group=2
> > hdmi_mode=11
> >
>
> The BCM2711 has both the older style hardware and the
> new-to-RPi*'s gic. These two alternatives that do not
> mention armstub8-gic.bin are having the BCM2711 use
> the older, less capable type of hardware instead of
> using the newer, more capable gic. (Or, at least,
> that is what is explicitly initialized.)
>
> You are better off with the solution that has the
> [pi4] and armstub=armstub8-gic.bin lines so that
> the gic is explicitly initialized.
>

Hi Mark,

Oh I see, thanks again! I'll apply your recommendation.

Thanks,
Archimedes

--0000000000002026fd05da3aae1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Mar 14, 2022 at 11:10 PM Mark=
 Millard <marklmi@yahoo.com>=
 wrote:
Hello.


On 2022-Mar-14, at 07:12, Archimedes Gaviola <archimedes.gaviola@gmail.com>=
; wrote:



> On Mon, Mar 14, 2022 at 9:50 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> 

> On Mon, Mar 14, 2022 at 8:01 PM Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Mar-14, at 02:55, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> 

> > In the default config.txt file there is [pi4] line. If I'm go=
ing to remove this [pi4] line, the boot-up process is very slow. Slow in a =
sense that some extended time is observed as compared to the default. I alr=
eady tested emphasizing the boot_delay=3D1 but to no avail. The reason why =
I removed it is because I want to change the settings of the HDMI display r=
esolution as changes will not take effect with the [pi4] line in RPi 3B.
> > 

> > With 14.0-CURRENT (February 24, 2022 snapshot) I have described m=
y resolution here https://li=
sts.freebsd.org/archives/freebsd-arm/2022-February/001070.html however =
with the latest 14.0-CURRENT (March 10, 2022 snapshot) it's no longer p=
ossible. Any idea what's going on?

> > 

> > Below is the default config.txt and my current config.txt for ref=
erence.

> > 

> > freebsd@generic:~ % cat /boot/msdos/config.txt

> > [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

> > 

> > freebsd@generic:~ % cat /boot/msdos/config.txt

> > [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

> > 

> > hdmi_group=3D2

> > hdmi_mode=3D11

> > armstub=3Darmstub8-gic.bin

> 

> armstub8-gic.bin is specific to the BCM2711 and will not

> work for the RPi3, as I understand.

> 

> armstub=3Darmstub8.bin is the default and is what was being

> used for the RPi3 when the [pi4] was in place.

> 

> You have the option of listing a [pi3] section last

> (after the [pi4] section). To have a [pi3] section

> be last, it should have an explicit

> armstub=3Darmstub8.bin line.

> 

> Listing older RPi* models last is done because some older

> RPi models ignore the [] notation and listing things last

> overrides earlier assignments, in this case overriding

> assignments for newer models. It is a safe notational

> ordering convention, even for models that do support

> the [] notation sufficiently.

> 

> If one depended on RPi3 models processing [] notation,

> if it does, then another option would have been to move

> the [rpi4] line to be just before the

> armstub=3Darmstub8-gic.bin line, causing the RPi3 to skip

> the assignment and use the default.

> 

> 

> Hi Mark,

> 

> Awesome, it works great! Below is my revised config.txt file now, no m=
ore boot-up delay and display resolution was effectively changed. Thank you=
 so much for sharing your thoughts in well-explained details, now I learned=
.

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [all]

> boot_delay=3D0

> 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]

> armstub=3Darmstub8-gic.bin

> 

> [pi3]

> hdmi_group=3D2

> hdmi_mode=3D11

> 

> Hi Mark,

> 

> I did further testing and these two configuration settings (removing [=
pi4] and armstub=3Darmstub8-gic.bin lines) below will do too.

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [all]

> boot_delay=3D0

> arm_64bit=3D1

> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don

> dtoverlay=3Dmmc

> dtoverlay=3Ddisable-bt

> device_tree_address=3D0x4000

> kernel=3Du-boot.bin

> 

> [pi3]

> hdmi_group=3D2

> hdmi_mode=3D11

> 

> or

> 

> freebsd@generic:~ % cat /boot/msdos/config.txt

> [all]

> boot_delay=3D0

> arm_64bit=3D1

> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don

> dtoverlay=3Dmmc

> dtoverlay=3Ddisable-bt

> device_tree_address=3D0x4000

> kernel=3Du-boot.bin

> 

> hdmi_group=3D2

> hdmi_mode=3D11

> 



The BCM2711 has both the older style hardware and the

new-to-RPi*'s gic. These two alternatives that do not

mention armstub8-gic.bin are having the BCM2711 use

the older, less capable type of hardware instead of

using the newer, more capable gic. (Or, at least,

that is what is explicitly initialized.)



You are better off with the solution that has the

[pi4] and armstub=3Darmstub8-gic.bin lines so that

the gic is explicitly initialized.

Hi Mark,

=

Oh I see, thanks again! I'll apply your reco=
mmendation.

Thanks,
Archimedes


--0000000000002026fd05da3aae1d--

From nobody Tue Mar 15 07:59:03 2022
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 D81511A2A58E
	for ; Tue, 15 Mar 2022 07:59:17 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KHm5J6zNLz4WZl
	for ; Tue, 15 Mar 2022 07:59:16 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 1D9F7260345;
	Tue, 15 Mar 2022 08:59:15 +0100 (CET)
Message-ID: <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org>
Date: Tue, 15 Mar 2022 08:59:03 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 
 
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KHm5J6zNLz4WZl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 928
Lines: 27

On 3/15/22 05:57, Archimedes Gaviola wrote:
> I did comment-out usbd_transfer_submit(xfer) and still the same behavior is
> experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
> freeze as my USB keyboard is unresponsive and I cannot connect over the
> Ethernet NIC with SSH. I can't print and capture.

Hi,

If you re-plug the USB keyboard, does it come back?

Try setting "sysctl kern.consmute=1". Then only capture logs from 
/var/log/messages.

--HPS

> 
> freebsd@generic:/usr/src/sys/dev/usb % diff -Nur usb_hub.c.orig usb_hub.c
> --- usb_hub.c.orig      2022-03-14 22:37:03.162678000 +0800
> +++ usb_hub.c   2022-03-14 22:38:23.832660000 +0800
> @@ -202,7 +202,7 @@
> 
>          case USB_ST_SETUP:
>                  usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer));
> -               usbd_transfer_submit(xfer);
> +               /* usbd_transfer_submit(xfer); */
>                  break;
> 

From nobody Tue Mar 15 08:54:30 2022
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 229F51A0E485
	for ; Tue, 15 Mar 2022 08:54:44 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4KHnKH1lxYz4fhV
	for ; Tue, 15 Mar 2022 08:54:43 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x534.google.com with SMTP id g3so23289690edu.1
        for ; Tue, 15 Mar 2022 01:54:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=qfQ5M+M8HiiqoqnIogBbl0KJgARCIdbxvcs90ZMf0y0=;
        b=SzOCwy+oBAYOA6LXB3xQ+AK1vsdAv02iooEqLCQboHMZNDjxZx/GTKqEUTKUCXn6h9
         Jwx2TYAtYB4n0yxba1qCt86Y48hbIYIYM2ag2n0T/bUmRYakVobwNQccVWt4oZxut3ek
         m9H89Jjy4j2Y7nXuB7O7gGhky3znlOsn3qgJlNXVv4e1q+dwhfRElNotjfJyK2PuqtgQ
         BtRziQxv853kZT/gikTc236y+ZX0PG/JcZk0VP8bGyn98Glp0LfFyNXlVYSniWRWHU2W
         2mlCcRMOuzLcF6xoVnYwn+UfEaNAA6vYlTw3pKHW/FHJmr9KJ19XtVkvBrMiI2cW+VI0
         H+eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=qfQ5M+M8HiiqoqnIogBbl0KJgARCIdbxvcs90ZMf0y0=;
        b=8QkJ6gToxsWcwCOLDmlGiJstyrsqLSQdx4yrrrQmsk7QiZKmkhmxk8/J4Jt//tZN4g
         XDzxiHfs/00mtbIRafL7Dw5CGd0V9Xzd4U/QhIsbFPKm8s20Y2ei2nooy8+AhlnIOHfQ
         LWUV+Q4tQDsB+qSZ7orjvVX0xUv9qEfAH8UYTMC0mO+t6z3HNTLTljKHDYgMWQHNPXQR
         DHQRB8U5oBxUnm172loQ8lz4jVddZeu+sa95PnARkByojr11BMKPWD0oM7Tty6wS9g1l
         pICKqr0xe7b3LpxG1lfbTxQMyJpMLD7+lgnA97lp/Ye6VkYkNIVfiatC8RU7uYg0l3Tu
         xyrQ==
X-Gm-Message-State: AOAM533GbE9mpNRsFhljBaPGC8CvTIIijZlo5oKHvigTT9e3h7VaSz+T
	fYqfUZsndwc3xdBSgKuYQUCZPk/NKEpevXWW7PCl/Hv+puE=
X-Google-Smtp-Source: ABdhPJwgKkBoITaJcG+SK56S2wWVY1puY4kFEiTjPZN+YbVxIb7PImVD1yuAgSA2SB3YWCbnpgRzXKfd8ieswejtNkA=
X-Received: by 2002:a50:cf48:0:b0:415:df40:9e3d with SMTP id
 d8-20020a50cf48000000b00415df409e3dmr23866956edk.185.1647334482370; Tue, 15
 Mar 2022 01:54:42 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
  <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org>
In-Reply-To: <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org>
From: Archimedes Gaviola 
Date: Tue, 15 Mar 2022 16:54:30 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000a5e6ab05da3df233"
X-Rspamd-Queue-Id: 4KHnKH1lxYz4fhV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=SzOCwy+o;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2534
Lines: 71

--000000000000a5e6ab05da3df233
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 15, 2022 at 3:59 PM Hans Petter Selasky  wrote:

> On 3/15/22 05:57, Archimedes Gaviola wrote:
> > I did comment-out usbd_transfer_submit(xfer) and still the same behavior
> is
> > experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
> > freeze as my USB keyboard is unresponsive and I cannot connect over the
> > Ethernet NIC with SSH. I can't print and capture.
>

Hi Hans,


>
> Hi,
>
> If you re-plug the USB keyboard, does it come back?
>

No, it does not come back.


> Try setting "sysctl kern.consmute=1". Then only capture logs from
> /var/log/messages.
>

Much better, no more system freeze. I'll proceed with testing and capturing
after work.

Thanks,
Archimedes

--000000000000a5e6ab05da3df233
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Mar 15, 2022 at 3:59 PM Hans =
Petter Selasky <hps=
@selasky.org> wrote:
On 3/15/22 05:57, Archimedes Gaviola wrote:

> I did comment-out usbd_transfer_submit(xfer) and still the same behavi=
or is

> experienced when hw.usb.dwc_otg.debug is enabled. The system seems to<=
br>
> freeze as my USB keyboard is unresponsive and I cannot connect over th=
e

> Ethernet NIC with SSH. I can't print and capture.
=


Hi Hans,
=C2=A0



Hi,



If you re-plug the USB keyboard, does it come back?
No, it does not come back.




Try setting "sysctl kern.consmute=3D1". Then only capture logs fr=
om 

/var/log/messages.

Much bett=
er, no more system freeze. I'll proceed with testing and capturing afte=
r work.

Thanks,
Arc=
himedes


--000000000000a5e6ab05da3df233--

From nobody Tue Mar 15 13:13:17 2022
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 F22701A27330
	for ; Tue, 15 Mar 2022 13:13:17 +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 4KHv3d3pgVz3nZS
	for ; Tue, 15 Mar 2022 13:13:17 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 60C392232A
	for ; Tue, 15 Mar 2022 13:13:17 +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 22FDDHAU035940
	for ; Tue, 15 Mar 2022 13:13:17 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22FDDHbK035939
	for freebsd-arm@FreeBSD.org; Tue, 15 Mar 2022 13:13:17 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 262570] How to fix Mincraft LAN Not Working Issue?
Date: Tue, 15 Mar 2022 13:13:17 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: cyberxgaming0@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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647349997;
	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=MZ46hnTW9PHh0O98T22nF7cplI7NGVq0FgaQ9J3CKZA=;
	b=uWirYGqLjf9wrOKlp2zj9fu84gy8R3C4vLg0iab9Lf8B3UZ43IMx42qevexybFimH1v6BA
	7DfhQnFCzOyKwDd92CH3S/66dhnBXQBY7Yi3+Tsi7CjvvSRDKNznH3bv+oyxkBhtheqjtP
	+xKLJPFk7PdnzkZqasT9E8+zSx9Zh8gJEY01bKLmU6VKXS/Re+kMUT2cN3CZEaNAgInWnq
	MTbvNELUN9keD+bs9sXQvNlRIFo4eK0uFmbTE8tJeGN4aYe0rmoG7ERk9SEBCExnQoiL39
	U6SFSZBVp1fwsYaWILWztuT/CDje8leRYRGISfPsanuupiBI0sC0zAKJ59YxXQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647349997; a=rsa-sha256; cv=none;
	b=WXRA1eDULSJ8UKCr96lqmIQsd1PXzL5WlPxBAwZGztc+pb3KevetWpI3irCBItrueFSOrI
	jW0RUG0jsbLkIHT7Ssvu100Vp6Z9IJv5chL6TkUR/a/jJJiotcKp9UZ/zonzck1yZ8K4NV
	AKqQ35fZTUgiYzZDpF6yhX23IoO2jN+P7+NOXaFEbOPV25fWeCqgY1XIbWrx4pEaZCCNOa
	PLSfhSaEQHdCB61dV6QT41WAjSNRM5VT+Jv8lLgKhUmGlym+c/Ksnpa1CDFSDGO8UJot1A
	ucNigpDCU9DKSPs1RRs8zBmt2ZOlzKuJwyGGqKfKDbblQdpgk5VVOhVBgNvt4w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 933
Lines: 29

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262570

            Bug ID: 262570
           Summary: How to fix Mincraft LAN Not Working Issue?
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: cyberxgaming0@gmail.com

LAN not working is one of the normal Windows issues for Minecraft. In many
situations, the players can interface with the web yet they can't join each
other to play the game. Assuming you run into this issue, sit back and rela=
x.
You can fix it by using this guide given below.

https://cyberxgaming.com/minecraft-lan-not-working/


If it does not help try contacting the minecraft server.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Mar 15 14:34:14 2022
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 E33411A107BC
	for ; Tue, 15 Mar 2022 14:34:33 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530])
	(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 4KHwsN6njhz4V1f
	for ; Tue, 15 Mar 2022 14:34:32 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x530.google.com with SMTP id w25so831610edi.11
        for ; Tue, 15 Mar 2022 07:34:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=W4PiAPJNaWcvhz4adId+73vtJ35ZEmeJ0Kkw9ar0wrk=;
        b=Kbr3hh83mq7EUJPy/cljzwCVh8NFxagalQhx1ZGReJDigKMO1A8gC54sNIhBbmokIK
         2fHR0PzFwrmJYj9/4EPr7m90OgaOBqngZbAP3dcEED1MaGlgS5jU/SLA5cAryRgWkpn3
         aA3pK0zokwgEpbXrM/pUuQ9SlAvca1yvDmaqz8H7tCDsLVe5myqE3QtpfE0zxigHwvtq
         hMEkURN/VIgvDyeNfdU11Fx//mGfFJZR/UZ4QeWNNlJg6IPimizSpQPzgqk373ihEKU1
         8sLKwg++3fKTXer3ka7nzHMOHLaheXhOREQ8rDUdjBPijmqVA1cFnHFkYFQSBkuT9Nw9
         2iQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=W4PiAPJNaWcvhz4adId+73vtJ35ZEmeJ0Kkw9ar0wrk=;
        b=Fkdkyq+GNv4RtLl5UJeHY/oqa19XYYlMmusPtmbDro4KOefLV3LYCY9YD/hFCbZl6h
         zDpOaLKC0dWl/tyPHra+G3K/hqT/JbvXLa4yIQiN1RKc4YCOC+tnss1lSPdr2ETsicSr
         bs2rqh2NVC1dr7fyv5m4b3A82eINAl05hXG3ixJr6UWRbrk2H71PNG/ByVkdnn4l+5c4
         M8yzO+H+vdPLCRqfG88xikcsBo5UyaYuzZ5WDDZoebmkVOW1sxv1HNJpj27xv9ISfoCA
         ZNVrTuCJ3eYhIJdNUTk+neynAH6PWaHD/yMP2ZN64SjvjRBle2iasynO3rKD9wio2wC/
         W/6Q==
X-Gm-Message-State: AOAM533DhusZ94g+PtraUancqJDsRIGKtCV8tAGdD/y+hbD/yNazzMaO
	nxvn545N/jNCgSZn0x91M4BLowRY1utpdgERJpbQwxvsXoM=
X-Google-Smtp-Source: ABdhPJw5/+FIAOb+/VzOCkOvFurrA1yD5Vz0+ekrPC4NmmmrlQ5HxloCQKVClD/anbyqgjlkF3gkc8PcjKUmM/z5TV8=
X-Received: by 2002:a05:6402:35c7:b0:418:6577:9eb0 with SMTP id
 z7-20020a05640235c700b0041865779eb0mr14109272edc.343.1647354865906; Tue, 15
 Mar 2022 07:34:25 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 15 Mar 2022 22:34:14 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000099f83b05da42b127"
X-Rspamd-Queue-Id: 4KHwsN6njhz4V1f
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Kbr3hh83;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3716
Lines: 98

--00000000000099f83b05da42b127
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 15, 2022 at 4:54 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Tue, Mar 15, 2022 at 3:59 PM Hans Petter Selasky 
> wrote:
>
>> On 3/15/22 05:57, Archimedes Gaviola wrote:
>> > I did comment-out usbd_transfer_submit(xfer) and still the same
>> behavior is
>> > experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
>> > freeze as my USB keyboard is unresponsive and I cannot connect over the
>> > Ethernet NIC with SSH. I can't print and capture.
>>
>
> Hi Hans,
>
>
>>
>> Hi,
>>
>> If you re-plug the USB keyboard, does it come back?
>>
>
> No, it does not come back.
>
>
>> Try setting "sysctl kern.consmute=1". Then only capture logs from
>> /var/log/messages.
>>
>
> Much better, no more system freeze. I'll proceed with testing and
> capturing after work.
>
> Thanks,
> Archimedes
>

Hi Hans,

I'll just give you an update for now. For several times of printing I've
done, the issue never occurred. So, tomorrow I'll continue for another
round of testing. Thanks for the debugging resolution, it's working now.

Thanks,
Archimedes

--00000000000099f83b05da42b127
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Mar 15, 2022 at 4:54 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Tue, Mar 15, 20=
22 at 3:59 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/15/22 05:57, Archimedes Gaviola wrote=
:

> I did comment-out usbd_transfer_submit(xfer) and still the same behavi=
or is

> experienced when hw.usb.dwc_otg.debug is enabled. The system seems to<=
br>
> freeze as my USB keyboard is unresponsive and I cannot connect over th=
e

> Ethernet NIC with SSH. I can't print and capture.
=


Hi Hans,
=C2=A0



Hi,



If you re-plug the USB keyboard, does it come back?
No, it does not come back.




Try setting "sysctl kern.consmute=3D1". Then only capture logs fr=
om 

/var/log/messages.

Much bett=
er, no more system freeze. I'll proceed with testing and capturing afte=
r work.

Thanks,
Arc=
himedes

Hi Hans,
=

I'll just give you an update for now. For several times =
of printing I've done, the issue never occurred. So, tomorrow I'll =
continue for another round of testing. Thanks for the debugging resolution,=
 it's working now. 

Thanks,
Arch=
imedes 


--00000000000099f83b05da42b127--

From nobody Tue Mar 15 20:53:39 2022
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 1A4A81A213B5
	for ; Tue, 15 Mar 2022 21:04:54 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJ5Wm45TGz3GW9
	for ; Tue, 15 Mar 2022 21:04:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647378285; bh=4rSK/vNraY/95dBUr94MVX6+ZpiZlfIkfIpw2gG2Su4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=k8VXLPvAo/4Mkaeb3My7ffg60i1JDq5d9JYEpDl6i7EhUIXcq7nZm1gInTbmr6EutZBkkqPyZnsPxB3Z+DPvlTbkp9ai4W6fL7e9J5g+kfuNpq6anoNO92GLyXOxDXUt+rW0tIx4UkfmR3mH8dzYHL5eUvhUtr6qE08TMIWzDnjnaYnavGUmcypYoNZ8+gO3EQ7XU/nxbI0HOflqypKzM9HYQge2PIIwMWn2WhXdaPzjulIuccc35jPLtoNAyWnmedp0ZUL4BDWIPorpBRNLSxhSBNWk/2cBcNydYbxFCHy/Y3bctLiQhHwEo876So8GtmOaXJLhbXWjZdQD0bl7eA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647378285; bh=q1Ii5YYz4kgt3Sqc5aECks2OepMhO5l5sJ2mMzslSgn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=X4gp1IoZkgIU3+a5EoUXZG6TX9msevoYS6M574XB6CxTLOCOUSSGWzdVCgJWT5p9G9gEpU7SLRUGWADbj2S5f+OzesxJoDkHIVf8G4MIqNwW56F/WK/rwPeKqsRqb/mgp6wnER0N5b+ToA4sWvhLalcsTX4SwazyHts2ePdGwrnAjad6vNjHUGpS6E69mhoeX60obLyKgwhYjq4EL057PnNRxVZgbVCccKTsQPbzRlBX6fN6CGpsT4BUHnRs8wocz232QBGnWL4hxW9sjHHQhYF5EMbj704RzvVcmNzSR1P2Ez51vmCkM//oYdwe/+efHD4zyxJZr/CsNjM6nl0Ajw==
X-YMail-OSG: uZKrumoVM1kbAneFGWitHOk7iiN1oDkVK9YIx_vUUkoMhdpoO1bKul8jOc9YSV9
 d9NobvDcZkGQjziD1GSzGfwIAb9DZdD7q15CchNMWnsRqHN8pZdVdqcAYjg5HpkAAf0hmrbwdx04
 6XZhBpgbRVRwJm63xC8dg09nxzT0kz9hSu2OUjLV8wnW.pR7vRRG595J840WQD1QGAeI9Xb0l8Ot
 k9YypSq5.DMCD940qjSFYG4fGTpoQ5RhayYF6isYAn9pHD3E_5q6fINDNFN4QpvOdfxBTiBRgtUf
 StqXsq7CjogPR9F.5I1K3db36NG2YQl3iIPLcIfEh6O26KV.bO.rZmr5TVt0_WkXuirtBi52SwMY
 zOSloz2fgfBrFDNZ0J4zWNZlJ5CEHUo0wCKbOimebNcDENKMIoH5yHv.Q4f8MewMqpyVthnw4I0K
 ohSCrc4iGqlrdk8l9xe1xCl4qtx1hjC.BtXIH_a7IzWXe0tZo5Czb_HlJed_YGF.c39M3y.EYSZf
 7voLsv0HuhxCFlqJNJQc8AnFdpvSz6ws1jWQcwb5HXDdq6MVJFwCrukr4H7rqmrg8HTDj_sjlOOp
 H_qkX8sK9PShUGsRlGdAu4rVyRKBzF7yZXzCvKQtQ5AcSYXNeeNEV6FGvSAbsBz0.4F73fjhLk1K
 gHVbHDB9lT6Pf7UfUTcwdReXDLsT2V36VIc5X5BSaT11oBwG09A8uapwA_sZsfEUdXDa4eCsdH8Y
 oMua.9CLKQvTqmF_0LeKpOiumBqxkwNRpxdNAHL.Y0.5w0pJBfI3LrWHX9hMWF6Y6q2lEjI0OHf7
 a9mpVckV8yBFbvi6QkVGYXyuKUszEIMwkOzF99C.fVgIvX5ypWzErXk3T3Xh1KfZcLAp2C02_8MU
 LDwg_Dk0oWcgK4KhdeIT4eXPwHeoZeXcYnuHgUGClLLH.hD8Rsi102jkNWojk9oLEnsvbHVE6obf
 JBoyVVC..vtQaU.OI_cpFKQU_QN_PJlsqDAvJBa05fzQlYintfvkhGX6P.XGS80WgoQbqfNL0Omo
 sh0WCeXi_Iq0OJhCuXbTMsRJLsqHHUdOhpCDsiNUUEY.tbtbCPIFzAYIkCM_F0jaVlwMWl5mGmFG
 1qrhkfL.o2GPiL1yrkTRQgivkdNv7SWyK4g4vSA19KrYPWu1ZICTVhLT.vYRmfEwRuUVkU9p300A
 lsLNc5PbF_gg0tLUR.IqnYa9dZ1IQvx0Wu76cvbNizNdbkbHb2fhOtknP.04.r4.0UNdZUtlcuXZ
 sNvJhvoUTy1qEznm7z6q8dxEUG2j2zJ6YQOekQ3bslEdQvgXMSJ37pAldHJiaJYDl16ltTTna9QE
 OlkAmxNJ2hACO9PZBSTln3teTT7LI2Udo_Tcmfw2OmO5BB2BbEmQNTVS12FqFLqyAxbZ5XLLPi_c
 cdwxQPlQ_zUIanxLDNoFHoJChJBkI9E3CSwZ.DfbfFaE7TTfXds8JbC_Z1DFoBk8MHhdS6zLK0k8
 SLJay5jrY9hv3mfFh4ohbMZjrxJ7P0UP6rXdRIJOk3ma4h.WWbVmz94rEh4p5Z3CfGslLU2e1cLw
 cxidYwEkXTYnbOOJIP1WumvWlT6.Z0EEYmKZwAgHLMdgNwUD9LqWDjFW5lTyJoWSYdVaEkYkrvNX
 zqk156mnJo6pgiSxwelAiTpaYi5d4r_Oqso57S_tBMMQOjfas7x5zb8VSIVpi.ABHpy3W8Oa38cT
 24Lb3GGaoO_SBCAFSg__cy3xCLLRWRlwfRM_NFXezD_jPRLCkxX8eqzeJa2hKpy0BthbyiGZrY9O
 fdzcMO_4W.AxVMfhsJnKEUhVn.gQ7bIv13inMA4WuezaPB.RzSmzWStgHtyEtQMmd2LlnoqOZTMX
 BEI275gP61YnP_v1jV_POcroyPb8Q5B77GOlrF4MJpqdlzVT5J72hxtiILEjAw8BomBIEoH5nZcJ
 TH5ZdKWRlrAA8t_albjHOupRHEqFunYHFFrnx4zqot1JAZKwA_p6mMDTH2VhxBZOpEDcUTShwEqV
 UBNuyTLyMboyUuKYCc.NXXNRrF80dUtgWm5vvPqZ8LvNg1kBgvp5jQ5pYPQ1Skpun.bHLSZJIhm3
 KR0pnnuH9SHhtbVOiIWbneq.KzpsFq3Q33weREKD4M_4EexZUf4nyKCLadVROL2QHufrXrjL82vb
 fwHzzuyidxBrD98Z07ToyAuTMbTUMQojAF3_167ySdu1NsjAF9qzJDRQM8cjukZN6n1PQ4NWcDpT
 65QBIIRPmtgz14UtkP_gmez0lX0nSiKfjqFfbsBK3d4ENjYG2JxC8WrCXRhbhKZr1CsD35nYolBW
 9XLV4T8T.wZ_29Jx7ShOlvOeU6eFoA4QM8PU1J4FnEYJGC40W9w773c6JFLGZNYsXJbaNNYG9
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Mar 2022 21:04:45 +0000
Received: by kubenode531.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8a72efa4e0990c8b1af7f3673ce84e9a;
          Tue, 15 Mar 2022 20:53:40 +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 14.0 \(3654.120.0.1.13\))
Subject: aarch64 contexts: devel/libunwind  builds broken --"error: no member
 named 'regs' in 'struct __mcontext'" (and more)
Message-Id: <627AD631-DCF5-40C5-9ABF-FC3C791062BA@yahoo.com>
Date: Tue, 15 Mar 2022 13:53:39 -0700
Cc: Free BSD 
To: FreeBSD Toolchain ,
 freebsd-ports@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <627AD631-DCF5-40C5-9ABF-FC3C791062BA.ref@yahoo.com>
X-Rspamd-Queue-Id: 4KJ5Wm45TGz3GW9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=k8VXLPvA;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-0.99)[-0.993];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1700
Lines: 49

Context: I'm using poudriere-devel for port builds.

=
http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-arm64-default&=
build=3Dp422f190aeba4_s23210c9f42

from "build started at Tue Mar  8 01:55:26 UTC 2022" shows the same
sorts errors I'm getting trying to build updated ports. So do
later builds there. An example:

. . . error: no member named 'regs' in 'struct __mcontext'
      unw_getcontext (&uc);
      ^~~~~~~~~~~~~~~~~~~~
../include/libunwind-common.h:127:29: note: expanded from macro =
'unw_getcontext'
#define unw_getcontext(uc)              unw_tdep_getcontext(uc)
                                        ^~~~~~~~~~~~~~~~~~~~~~~
../include/libunwind-aarch64.h:237:79: note: expanded from macro =
'unw_tdep_getcontext'
  register uint64_t unw_base __asm__ ("x0") =3D (uint64_t) =
unw_ctx->uc_mcontext.regs; \
                                                         =
~~~~~~~~~~~~~~~~~~~~ ^
1 error generated.

I also get such when attempting building for releng/13.0
(13.0-RELEASE-p7) , not just when building for main [so: 14].

I'll note that it looks like:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262257

was reopened on 2022-Mar-12 because of these types of problems
on aarch64. (The problem reported there on 2002-Mar-09.) No
news after that (yet), but it has been only a couple more days.


So, a question on tier-1 related procedures:

It looks like having an "exp-run" before the associated commit
did not include doing so on aarch64. Are all tier 1 architectures
generally supposed to get an exp-run when exp-runs are requested?
Or is it only amd64 that is supposed to get such unless explicitly
requested?

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 16 02:10:14 2022
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 1BAF91A29E27
	for ; Wed, 16 Mar 2022 02:10:15 +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 4KJDJ65mpvz3J90
	for ; Wed, 16 Mar 2022 02:10:14 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 A2E2F516C
	for ; Wed, 16 Mar 2022 02:10:14 +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 22G2AE8k058321
	for ; Wed, 16 Mar 2022 02:10:14 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22G2AEUX058319
	for freebsd-arm@FreeBSD.org; Wed, 16 Mar 2022 02:10:14 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 262570] How to fix Mincraft LAN Not Working Issue?
Date: Wed, 16 Mar 2022 02:10:14 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: misc
X-Bugzilla-Version: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not A Bug
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: bugmeister@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: assigned_to bug_status component resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647396614;
	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=j74YtXXd9Sz9kC4KI96OMba4rBwJPgsVHtWVtcfxaHc=;
	b=UtGCaI8860GdsKpYffqf+RKyvK8NFFu0DfcT8xyCiDezVuuD6N+C9CQomaIcFC7IkMz14R
	6lOf20fobzlTPPoYBlyp0ieBk+JK40qHlrKvkdDLozThE3lk2euqgMA9jphvRz2Y/QSmjK
	6rM9ZXV+HD1TQkrpG9wJfY5v06JOd52FK3UKgnkSeZZYlweR13KgYuzNVNR/U5nDVApyq3
	w2W1IA8bg+qBEPqXh09PPnfUDgCyDoxf2irqEngKzAY68j462w8mStBqjGSkWCHF1mjO8N
	DPbpc1dWQfhCLWsWeAPS6G2gT61e3Nrlip2Z+Rv882Z8MT7OL/NqMXKbe2jJsw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647396614; a=rsa-sha256; cv=none;
	b=iuclTRM5s1KVMbHVLfiAkY2hyFO/Ioz3JAqtx+jalUSS/PWvBVSXYCogv+1i7ErR9sSzfM
	jbn2r5ocu3XgSqPGcBAd5DjW+AqRcyvEfjVLO/VrbJt4qq0EFuKJclYw9y9gZrZwgaoMPa
	J+SZITjOTd8D/7N/EUS/aopNC9GqCtXlgPYbcXqu6UBL+lcTVbymusnVTj6I3S5NROhRAZ
	y+euZXbYwGZfqpYQ9ZrEp2tp2BQBNjTu/fsihLJhl2IgidFCfwAtsXqrHWbVzrVjbtHZe8
	QjgGfo8m2H2FsV5o48NR6/Z0x3vafJx5/36i47Xgesv4KMlZEmgkTk9NT/cbPA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 557
Lines: 14

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262570

Mark Linimon  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|freebsd-arm@FreeBSD.org     |bugmeister@FreeBSD.org
             Status|New                         |Closed
          Component|arm                         |misc
         Resolution|---                         |Not A Bug

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Mar 16 04:12:45 2022
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 EB1A51A23398
	for ; Wed, 16 Mar 2022 04:12:45 +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 4KJH1T4YgWz3sQJ
	for ; Wed, 16 Mar 2022 04:12:45 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 7C8A372DA
	for ; Wed, 16 Mar 2022 04:12:45 +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 22G4Cjfb032388
	for ; Wed, 16 Mar 2022 04:12:45 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22G4Cjms032387
	for freebsd-arm@FreeBSD.org; Wed, 16 Mar 2022 04:12:45 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 262554] [armv7][GENERICSD][patch] release.sh fails due to wrong
 argument to gpart add
Date: Wed, 16 Mar 2022 04:12:45 +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: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: mav@FreeBSD.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: mav@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: resolution bug_status assigned_to cc
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647403965;
	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=cYRelvC1RZYUGlHJWrc/JENznvgMKu6JyNJNDpmpdsE=;
	b=ItzrjXRNNVQwBSaOMu7qNedbrvMsJyttWTZ2NVapG1mPrG86bD1s/Q9Vm+VwpgLr7hWSaB
	CPw3CPEPWtrAEY3r2vJPqVi5TaPtz5gxQ+1/IlCrjf/f9qS7p5XKtuuwv29kWhuGaFvXKK
	+IpULjZuU1KWOyqYeXLlxYUq4DWMEcMhiT3kjmfSt6Gk8sCJRFrgnDSBQTl/C7VYWKZ8mJ
	yCEktACHGlLF8r+4wZPvl8WzT18QfuGqn2p/dTvonyRRukXC4zB09Y0t2vH+c1VK/cIOh0
	XWUhMNmkyAKj0OvrIiTGRFUP7AJ2I62O3QS8zp03UtFCziOwqSaPoR8zn3PJaA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647403965; a=rsa-sha256; cv=none;
	b=fvhZQZ8SibjogRlmdl6QsFGG4MaxDnjQc883z8tKlmzVfVWW+IQXf25y6yVkT0qFUaO126
	3RrY9g2PsRfprYin4ymjL+rQjwR694uNm9NTT272eqtMZcYRQXEWsgvc8XanT+98C/h5Xn
	FhO5L2dOcyd3jdg0CcJzMBUBS3DN7ZmP18JhyS2NeOhuh95QZGecoHhKqYLQXCRVR1FcIi
	OioMMRjSNJA/ipnSHJV1c9fka3fnOindpSjQDd5SlN/2tiAR3uNIZ3S3HQx+Ng3WzCW2P6
	C7ZvyFp65+Cm/A37OaEi8GDl8SVIYeeH6u0hp7b41baxd5lCtI7fiCICJn+VIg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 755
Lines: 18

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262554

Alexander Motin  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|New                         |Closed
           Assignee|freebsd-arm@FreeBSD.org     |mav@FreeBSD.org
                 CC|                            |mav@FreeBSD.org

--- Comment #12 from Alexander Motin  ---
I think the proposed patch is right.  But since it was my regression that
triggered the problem, I've restored the previous behavior also.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Mar 16 12:02:57 2022
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 A56021A2F7EC
	for ; Wed, 16 Mar 2022 12:03:11 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4KJTSG6z49z4b2K
	for ; Wed, 16 Mar 2022 12:03:10 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id bi12so3701304ejb.3
        for ; Wed, 16 Mar 2022 05:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=/BRvKOc3Cp+kmTVL11TpMS01sJIqGoKrfhdMHFH3bi4=;
        b=hcFSPuVQ26Lv71+nYrEYidRW4G3jenlp7PjO25ZC9wbMHaAWEp/qBUXxNgjvHiDVv1
         fWuVbNtAQGc8AueSaCogLxH0PRzJaXOIS5IJZxQ5Ytvy1Uaw8n8LyxaWckjbF8W/EDz7
         wQVUyy4kTORUx4P6HxivCMWY8qWpmSV5UwC2tNgYIQjt0E+wHX5rdtH9ky+tuxnHEqqy
         lKFOBJyHluuXx19IdcN2meZuIZhLu6936r0UN4t/bGmITu3ju3te69BSsgwZjlkI77R9
         JFJ0gufB3+rEwNGTNwx7wKAQ8HlwkS4wukY/O7j/Ftp1JIuiE2LKr9WpNu8wyDoCjNLk
         m1eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=/BRvKOc3Cp+kmTVL11TpMS01sJIqGoKrfhdMHFH3bi4=;
        b=783eEHntmMBoozmGF1eDIjQ1gEwfukLGL9wddNRmGqvGOu5KdyxFhaI7VNY/SNqzjV
         z6aVXbN2X7mvxFv3fJJZxoRCqXMlBuPPYm+PP06OYgKpUm/4N4TedYZu3J7nbXPO7Jk5
         Jpd8DGXaHjlYmGgEfcKjbGVXjRMIxiMRsp0EPGpL98uVGWM4coo+jaY0EP2L1LVEAO5c
         KWDVrgkj041WzLTxQZ6iRr/+Bpo5Uh8KoVWpoqryCvSQWe1w0cwtn6SGbE5AZwhCdGoJ
         sFbmEBEbzTGTM8kulM7Kg6LbXryESjeILRnvaHAaIrGKfArDPhLDa0mMjTUy4aoXeSRi
         Rc6Q==
X-Gm-Message-State: AOAM533aZNZQr6AWcijMc6fnugJhMgAlyl2w6tiXopx7kGr/W3qE4Nd1
	pY2SoT7oxKn9hwy4vTmT2Bd4H0t7E4+efFiMVrLqiYszZiv2RA==
X-Google-Smtp-Source: ABdhPJzwcmh+6WUKt3WxCKW8oTISeCo/JqwYxYyDMxbKM6/W8P/91ZwBRNR4ygSA73cfyvP6Cr/GoUhzmRdXCDVs+bU=
X-Received: by 2002:a17:907:eac:b0:6db:799c:cb3c with SMTP id
 ho44-20020a1709070eac00b006db799ccb3cmr27314630ejc.559.1647432189898; Wed, 16
 Mar 2022 05:03:09 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Wed, 16 Mar 2022 20:02:57 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000078739b05da54b284"
X-Rspamd-Queue-Id: 4KJTSG6z49z4b2K
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=hcFSPuVQ;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.81 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.997];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.18)[0.185];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4914
Lines: 124

--00000000000078739b05da54b284
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 15, 2022 at 10:34 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Tue, Mar 15, 2022 at 4:54 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 15, 2022 at 3:59 PM Hans Petter Selasky 
>> wrote:
>>
>>> On 3/15/22 05:57, Archimedes Gaviola wrote:
>>> > I did comment-out usbd_transfer_submit(xfer) and still the same
>>> behavior is
>>> > experienced when hw.usb.dwc_otg.debug is enabled. The system seems to
>>> > freeze as my USB keyboard is unresponsive and I cannot connect over the
>>> > Ethernet NIC with SSH. I can't print and capture.
>>>
>>
>> Hi Hans,
>>
>>
>>>
>>> Hi,
>>>
>>> If you re-plug the USB keyboard, does it come back?
>>>
>>
>> No, it does not come back.
>>
>>
>>> Try setting "sysctl kern.consmute=1". Then only capture logs from
>>> /var/log/messages.
>>>
>>
>> Much better, no more system freeze. I'll proceed with testing and
>> capturing after work.
>>
>> Thanks,
>> Archimedes
>>
>
> Hi Hans,
>
> I'll just give you an update for now. For several times of printing I've
> done, the issue never occurred. So, tomorrow I'll continue for another
> round of testing. Thanks for the debugging resolution, it's working now.
>
> Thanks,
> Archimedes
>


Hi Hans,

I just uploaded the /var/log/messages file here
https://filebin.net/gffcyx587ynrcg6u. Kindly check if you can find
something. The issue occurred twice and I caught the second occurrence.

Thanks,
Archimedes

--00000000000078739b05da54b284
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Mar 15, 2022 at 10:34 PM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:


On Tue, Mar 15, 2=
022 at 4:54 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div dir=3D"ltr">

On Tue, Mar 15, 2022 at 3:59 PM Hans Petter Selasky <=
;hps@selasky.org&g=
t; wrote:
On 3/1=
5/22 05:57, Archimedes Gaviola wrote:

> I did comment-out usbd_transfer_submit(xfer) and still the same behavi=
or is

> experienced when hw.usb.dwc_otg.debug is enabled. The system seems to<=
br>
> freeze as my USB keyboard is unresponsive and I cannot connect over th=
e

> Ethernet NIC with SSH. I can't print and capture.
=


Hi Hans,
=C2=A0



Hi,



If you re-plug the USB keyboard, does it come back?
No, it does not come back.




Try setting "sysctl kern.consmute=3D1". Then only capture logs fr=
om 

/var/log/messages.

Much bett=
er, no more system freeze. I'll proceed with testing and capturing afte=
r work.

Thanks,
Arc=
himedes

Hi Hans,
=

I'll just give you an update for now. For several times =
of printing I've done, the issue never occurred. So, tomorrow I'll =
continue for another round of testing. Thanks for the debugging resolution,=
 it's working now. 

Thanks,
Arch=
imedes


Hi =
Hans,

I just uploaded the /var/log/messages file h=
ere https://filebin.net/gf=
fcyx587ynrcg6u. Kindly check if you can find something. The issue occur=
red twice and I caught the second occurrence.

Than=
ks,
Archimedes 


--00000000000078739b05da54b284--

From nobody Wed Mar 16 13:31:45 2022
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 3BD8A1A2939F
	for ; Wed, 16 Mar 2022 13:32:02 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KJWQn05rPz4tXg
	for ; Wed, 16 Mar 2022 13:32:00 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 37B002605A3;
	Wed, 16 Mar 2022 14:31:58 +0100 (CET)
Message-ID: 
Date: Wed, 16 Mar 2022 14:31:45 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 
 
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org>
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KJWQn05rPz4tXg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.09 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-0.80)[-0.796];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 143
Lines: 7

Hi Archimedes,

I don't see any issue in there. There should be a print containing ERROR .

Did you set the DWC OTG debug level to 17 ?

--HPS

From nobody Wed Mar 16 13:46:06 2022
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 4174B1A2C7D8
	for ; Wed, 16 Mar 2022 13:46:22 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJWlJ5Nhsz3Cw8
	for ; Wed, 16 Mar 2022 13:46:20 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18])
	by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 22GDk6Cn005718
	for ; Wed, 16 Mar 2022 09:46:13 -0400
Received: from w92expo29.exchange.mit.edu (18.7.74.41) by
 oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id
 15.0.1497.32; Wed, 16 Mar 2022 09:45:49 -0400
Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by
 w92expo29.exchange.mit.edu (18.7.74.41) with Microsoft SMTP Server (TLS) id
 15.0.1497.23; Wed, 16 Mar 2022 09:46:07 -0400
Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by
 oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.023; Wed,
 16 Mar 2022 09:46:07 -0400
From: John F Carr 
To: freebsd-arm 
Subject: USB regression on Overdrive 1000
Thread-Topic: USB regression on Overdrive 1000
Thread-Index: AQHYOTwvCD/SIr0zf0WqyIfVME12Bg==
Date: Wed, 16 Mar 2022 13:46:06 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [108.7.221.50]
Content-Type: multipart/mixed;
	boundary="_003_AC0D625A79594329B4C8A7784FBB09A0exchangemitedu_"
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-Rspamd-Queue-Id: 4KJWlJ5Nhsz3Cw8
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.59 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [1.02 / 15.00];
	 HAS_XOIP(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	 HAS_ATTACHMENT(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[18.9.28.59:from];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 RCVD_IN_DNSWL_MED(-0.20)[18.9.28.59:from];
	 MIME_BASE64_TEXT(0.10)[];
	 CTYPE_MIXED_BOGUS(1.00)[];
	 NEURAL_HAM_SHORT(-0.06)[-0.055];
	 DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:+];
	 ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 RCVD_COUNT_FIVE(0.00)[5];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.98)[0.976];
	 RCPT_COUNT_ONE(0.00)[1];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 25894
Lines: 367

--_003_AC0D625A79594329B4C8A7784FBB09A0exchangemitedu_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5014238AC516F143BF3B15185B0A0800@exchange.mit.edu>
Content-Transfer-Encoding: quoted-printable

I updated my kernel from 13.0-STABLE from early December to 13.1-STABLE fro=
m yesterday and I am having USB problems on my Overdrive 1000 ARM box.  I s=
ee some usb_msc_auto_quirk messages I haven't seen before and there is a lo=
ng delay "Root mount waiting for: usbus0".  It does boot eventually off of =
the internal drive, ada0, but it continues to spew USB errors to the consol=
e.  It doesn't register a "CAMuhub0" device and it never finds the USB stic=
k plugged into the external port which should appear as da0.  Any ideas?

dmesg output attached, "good" comes from "boot kernel.old".  The if_msk err=
or is probably caused by a mismatch between old kernel and new root filesys=
tem.


CPU  3: ARM Cortex-A57 r1p2 affinity:  1  1
Release APs...done
usbus0: 5.0Gbps Super Speed USB v3.0
Trying to mount root from zfs:zroot/ROOT/default []...
ugen0.1: <(0x1b73) XHCI root HUB> at usbus0
uhub0 on usbus0
uhub0: <(0x1b73) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ACS-2 ATA SATA 3.x device
...
Root mount waiting for: usbus0
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Gen=
eric Mass Storage Device (0x14cd:0x125d)
usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage devi=
ce Generic Mass Storage Device (0x14cd:0x125d)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device=
 Generic Mass Storage Device (0x14cd:0x125d)
usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device Ge=
neric Mass Storage Device (0x14cd:0x125d)
Root mount waiting for: usbus0
xhci0: Resetting controller
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=3D1, set address failed! (USB_ERR_TIMEOUT, igno=
red)
Root mount waiting for: usbus0
...
xhci0: Resetting controller


--_003_AC0D625A79594329B4C8A7784FBB09A0exchangemitedu_
Content-Type: text/plain; name="dmesg-bad.txt"
Content-Description: dmesg-bad.txt
Content-Disposition: attachment; filename="dmesg-bad.txt"; size=9487;
	creation-date="Wed, 16 Mar 2022 13:46:06 GMT";
	modification-date="Wed, 16 Mar 2022 13:46:06 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

V0FSTklORzogQ2Fubm90IGZpbmQgZnJlZWJzZCxkdHMtdmVyc2lvbiBwcm9wZXJ0eSwgY2Fubm90
IGNoZWNrIERUQiBjb21wbGlhbmNlDQpDb3B5cmlnaHQgKGMpIDE5OTItMjAyMSBUaGUgRnJlZUJT
RCBQcm9qZWN0Lg0KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAx
OTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0DQoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNp
dHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCkZyZWVCU0QgaXMgYSByZWdp
c3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLg0KRnJlZUJTRCAxMy4x
LVNUQUJMRSAjNiBzdGFibGUvMTMtbjI1MDAyMC01ZjNkOTUyZjZlNjogVHVlIE1hciAxNSAxOTo1
ODozMiBFRFQgMjAyMg0KICAgIHJvb3RAc3RyaWF0dXM6L3Vzci9vYmovdXNyL2hvbWUvamZjL2Zy
ZWVic2Qvc3JjL2FybTY0LmFhcmNoNjQvc3lzL0dFTkVSSUMgYXJtNjQNCkZyZWVCU0QgY2xhbmcg
dmVyc2lvbiAxMy4wLjAgKGdpdEBnaXRodWIuY29tOmxsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZt
b3JnLTEzLjAuMC0wLWdkN2I2NjliM2EzMDMpDQpWVDogaW5pdCB3aXRob3V0IGRyaXZlci4NCm1v
ZHVsZSBmaXJtd2FyZSBhbHJlYWR5IHByZXNlbnQhDQpyZWFsIG1lbW9yeSAgPSA4NTcwMDExNjQ4
ICg4MTczIE1CKQ0KYXZhaWwgbWVtb3J5ID0gODMyODM2ODEyOCAoNzk0MiBNQikNClN0YXJ0aW5n
IENQVSAxICgxKQ0KU3RhcnRpbmcgQ1BVIDIgKDEwMCkNClN0YXJ0aW5nIENQVSAzICgxMDEpDQpG
cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMNCnJhbmRv
bTogdW5ibG9ja2luZyBkZXZpY2UuDQpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGlu
dGVyZmFjZQ0KTUFQIDgxZmI4MzAwMDAgbW9kZSAyIHBhZ2VzIDk5Mg0KTUFQIDgxZmJlMTAwMDAg
bW9kZSAyIHBhZ2VzIDQ5Ng0KTUFQIDgxZmZmZDAwMDAgbW9kZSAyIHBhZ2VzIDMyDQprYmQwIGF0
IGtiZG11eDANCm9md2J1czA6IDxPcGVuIEZpcm13YXJlIERldmljZSBUcmVlPg0Kc2ltcGxlYnVz
MDogPEZsYXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwDQpjbGtfZml4
ZWQwOiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19maXhlZDE6IDxGaXhlZCBjbG9j
az4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkMjogPEZpeGVkIGNsb2NrPiBvbiBzaW1wbGVidXMw
DQpjbGtfZml4ZWQzOiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19maXhlZDQ6IDxG
aXhlZCBjbG9jaz4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkNTogPEZpeGVkIGNsb2NrPiBvbiBz
aW1wbGVidXMwDQpjbGtfZml4ZWQ2OiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19m
aXhlZDc6IDxGaXhlZCBjbG9jaz4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkODogPEZpeGVkIGNs
b2NrPiBvbiBzaW1wbGVidXMwDQpjbGtfZml4ZWQ5OiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1
czANCmNsa19maXhlZDEwOiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCnBzY2kwOiA8QVJN
IFBvd2VyIFN0YXRlIENvLW9yZGluYXRpb24gSW50ZXJmYWNlIERyaXZlcj4gb24gb2Z3YnVzMA0K
Z2ljMDogPEFSTSBHZW5lcmljIEludGVycnVwdCBDb250cm9sbGVyPiBtZW0gMHhlMTExMDAwMC0w
eGUxMTEwZmZmLDB4ZTExMmYwMDAtMHhlMTEzMGZmZiwweGUxMTQwMDAwLTB4ZTExNGZmZmYsMHhl
MTE2MDAwMC0weGUxMTZmZmZmIGlycSA0IG9uIG9md2J1czANCmdpYzA6IHBuIDB4MiwgYXJjaCAw
eDIsIHJldiAweDEsIGltcGxlbWVudGVyIDB4NDNiIGlycXMgNDQ4DQpnaWN2Mm0wOiA8QVJNIEdl
bmVyaWMgSW50ZXJydXB0IENvbnRyb2xsZXIgTVNJL01TSVg+IG1lbSAweDgwMDAwLTB4ODBmZmYg
b24gZ2ljMA0KZ2VuZXJpY190aW1lcjA6IDxBUk12OCBHZW5lcmljIFRpbWVyPiBpcnEgNSw2LDcs
OCBvbiBvZndidXMwDQpUaW1lY291bnRlciAiQVJNIE1QQ29yZSBUaW1lY291bnRlciIgZnJlcXVl
bmN5IDI1MDAwMDAwMCBIeiBxdWFsaXR5IDEwMDANCkV2ZW50IHRpbWVyICJBUk0gTVBDb3JlIEV2
ZW50dGltZXIiIGZyZXF1ZW5jeSAyNTAwMDAwMDAgSHogcXVhbGl0eSAxMDAwDQplZmlydGMwOiA8
RUZJIFJlYWx0aW1lIENsb2NrPg0KZWZpcnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5
IGNsb2NrLCByZXNvbHV0aW9uIDEuMDAwMDAwcw0KY3B1bGlzdDA6IDxPcGVuIEZpcm13YXJlIENQ
VSBHcm91cD4gb24gb2Z3YnVzMA0KY3B1MDogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0
MA0KY3B1MTogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1MjogPE9wZW4gRmly
bXdhcmUgQ1BVPiBvbiBjcHVsaXN0MA0KY3B1MzogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVs
aXN0MA0KcG11MDogPFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgVW5pdD4gaXJxIDAsMSwyLDMgb24g
b2Z3YnVzMA0KcG11MDogQ2Fubm90IGZpbmQgQ1BVIHdpdGggTVBJRFI6IDB4MDAwMDAwMDINCnBt
dTA6IENhbm5vdCBwYXJzZSBhZmZpbml0eSBmb3IgQ1BVaWQ6IDIuDQpkZXZpY2VfYXR0YWNoOiBw
bXUwIGF0dGFjaCByZXR1cm5lZCA2DQphaGNpMDogPEFIQ0kgU0FUQSBjb250cm9sbGVyPiBtZW0g
MHhlMDMwMDAwMC0weGUwM2VmZmZmIGlycSA5IG9uIHNpbXBsZWJ1czANCmFoY2kwOiBBSENJIHYx
LjMwIHdpdGggOCA2R2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIHN1cHBvcnRlZA0KYWhjaWNo
MDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGFoY2kwDQphaGNpY2gxOiA8QUhDSSBj
aGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTANCnVhcnQwOiA8UHJpbWVDZWxsIFVBUlQgKFBM
MDExKT4gbWVtIDB4ZTEwMTAwMDAtMHhlMTAxMGZmZiBpcnEgMTMgb24gc2ltcGxlYnVzMA0KdWFy
dDA6IGNvbnNvbGUgKDExNTIwMCxuLDgsMSkNCnBjaWIwOiA8R2VuZXJpYyBQQ0kgaG9zdCBjb250
cm9sbGVyPiBtZW0gMHhmMDAwMDAwMC0weGZmZmZmZmZmIG9uIHNpbXBsZWJ1czANCnBjaTA6IDxQ
Q0kgYnVzPiBvbiBwY2liMA0KcGNpYjE6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIuMiBv
biBwY2kwDQpwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjENCnhoY2kwOiA8WEhDSSAoZ2VuZXJpYykg
VVNCIDMuMCBjb250cm9sbGVyPiBtZW0gMHg0MDEwMDAwMC0weDQwMTBmZmZmLDB4NDAxMTAwMDAt
MHg0MDExMGZmZiwweDQwMTExMDAwLTB4NDAxMTFmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQp4
aGNpMDogMzIgYnl0ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BDQp1c2J1czAgb24geGhjaTAN
CnBjaWIyOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyLjMgb24gcGNpMA0KcGNpMjogPFBD
SSBidXM+IG9uIHBjaWIyDQptc2tjMDogPE1hcnZlbGwgWXVrb24gODhFODA1OSBHaWdhYml0IEV0
aGVybmV0PiBwb3J0IDB4MTAwMC0weDEwZmYgbWVtIDB4NDAwMDAwMDAtMHg0MDAwM2ZmZiBhdCBk
ZXZpY2UgMC4wIG9uIHBjaTINCm1zazA6IDxNYXJ2ZWxsIFRlY2hub2xvZ3kgR3JvdXAgTHRkLiBZ
dWtvbiBPcHRpbWEgSWQgMHhiYyBSZXYgMHgwMT4gb24gbXNrYzANCm1zazA6IFVzaW5nIGRlZmF1
bHRzIGZvciBUU086IDY1NTE4LzM1LzIwNDgNCm1zazA6IEV0aGVybmV0IGFkZHJlc3M6IGUwOmZm
OmY3OjAwOjIwOmYwDQptaWlidXMwOiA8TUlJIGJ1cz4gb24gbXNrMA0KZTEwMDBwaHkwOiA8TWFy
dmVsbCBQSFlHNjVHIEdpZ2FiaXQgUEhZPiBQSFkgMCBvbiBtaWlidXMwDQplMTAwMHBoeTA6ICBu
b25lLCAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAw
YmFzZVQsIDEwMDBiYXNlVC1tYXN0ZXIsIDEwMDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFz
dGVyLCBhdXRvLCBhdXRvLWZsb3cNCmFybXY4Y3J5cHRvMDogPEFFUy1DQkMsQUVTLVhUUyxBRVMt
R0NNPg0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KWkZTIGZpbGVzeXN0ZW0g
dmVyc2lvbjogNQ0KWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0ICg1
MDAwKQ0KQ1BVICAwOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMCAgMA0KICAgICAg
ICAgICAgICAgICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEkt
Y2FjaGVsaW5lLFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJHLDY0IGJ5dGUgQ1dHPg0KIEluc3RydWN0
aW9uIFNldCBBdHRyaWJ1dGVzIDAgPSA8Q1JDMzIsU0hBMixTSEExLEFFUytQTVVMTD4NCiBJbnN0
cnVjdGlvbiBTZXQgQXR0cmlidXRlcyAxID0gPD4NCiAgICAgICAgIFByb2Nlc3NvciBGZWF0dXJl
cyAwID0gPEFkdlNJTUQsRlAsRUwzIDMyLEVMMiAzMixFTDEgMzIsRUwwIDMyPg0KICAgICAgICAg
UHJvY2Vzc29yIEZlYXR1cmVzIDEgPSA8Pg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDAg
PSA8VEdyYW40LFRHcmFuNjQsU05TTWVtLEJpZ0VuZCwxNmJpdCBBU0lELDE2VEIgUEE+DQogICAg
ICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDw4Yml0IFZNSUQ+DQogICAgICBNZW1vcnkgTW9k
ZWwgRmVhdHVyZXMgMiA9IDwzMmJpdCBDQ0lEWCw0OGJpdCBWQT4NCiAgICAgICAgICAgICBEZWJ1
ZyBGZWF0dXJlcyAwID0gPERvdWJsZUxvY2ssMiBDVFggQktQVHMsNCBXYXRjaHBvaW50cyw2IEJy
ZWFrcG9pbnRzLFBNVXYzLERlYnVndjg+DQogICAgICAgICAgICAgRGVidWcgRmVhdHVyZXMgMSA9
IDw+DQogICAgICAgICBBdXhpbGlhcnkgRmVhdHVyZXMgMCA9IDw+DQogICAgICAgICBBdXhpbGlh
cnkgRmVhdHVyZXMgMSA9IDw+DQpBQXJjaDMyIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDUg
PSA8Q1JDMzIsU0hBMixTSEExLEFFUytWTVVMTCxTRVZMPg0KQUFyY2gzMiBNZWRpYSBhbmQgVkZQ
IEZlYXR1cmVzIDAgPSA8RlBSb3VuZCxGUFNxcnQsRlBEaXZpZGUsRFAgVkZQdjMrdjQsU1AgVkZQ
djMrdjQsQWR2U0lNRD4NCkFBcmNoMzIgTWVkaWEgYW5kIFZGUCBGZWF0dXJlcyAxID0gPFNJTURG
TUFDLEZQSFAgRFAgQ29udixTSU1ESFAgU1AgQ29udixTSU1EU1AsU0lNREludCxTSU1ETFMsRlBE
TmFOLEZQRnRaPg0KQ1BVICAxOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMCAgMQ0K
Q1BVICAyOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMSAgMA0KQ1BVICAzOiBBUk0g
Q29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMSAgMQ0KUmVsZWFzZSBBUHMuLi5kb25lDQp1c2J1
czA6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNCIHYzLjANClRyeWluZyB0byBtb3VudCByb290IGZy
b20gemZzOnpyb290L1JPT1QvZGVmYXVsdCBbXS4uLg0KdWdlbjAuMTogPCgweDFiNzMpIFhIQ0kg
cm9vdCBIVUI+IGF0IHVzYnVzMA0KdWh1YjAgb24gdXNidXMwDQp1aHViMDogPCgweDFiNzMpIFhI
Q0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDMuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAN
CmFkYTAgYXQgYWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDANCmFkYTA6IDxQYXRy
aW90IFAyMDAgMVRCIFMwNDI0QTA+IEFDUy0yIEFUQSBTQVRBIDMueCBkZXZpY2UNCmFkYTA6IFNl
cmlhbCBOdW1iZXIgQUEwMDAwMDAwMDAwMDAwMDA1MDkNCmFkYTA6IDYwMC4wMDBNQi9zIHRyYW5z
ZmVycyAoU0FUQSAzLngsIFVETUE2LCBQSU8gNTEyYnl0ZXMpDQphZGEwOiBDb21tYW5kIFF1ZXVl
aW5nIGVuYWJsZWQNCmFkYTA6IDk3Njc2Mk1CICgyMDAwNDA5MjY0IDUxMiBieXRlIHNlY3RvcnMp
DQp1aHViMDogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClJvb3QgbW91
bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KdXNiX21zY19hdXRvX3F1aXJrOiBVUV9NU0NfTk9fR0VU
TUFYTFVOIHNldCBmb3IgVVNCIG1hc3Mgc3RvcmFnZSBkZXZpY2UgR2VuZXJpYyBNYXNzIFN0b3Jh
Z2UgRGV2aWNlICgweDE0Y2Q6MHgxMjVkKQ0KdXNiX21zY19hdXRvX3F1aXJrOiBVUV9NU0NfTk9f
VEVTVF9VTklUX1JFQURZIHNldCBmb3IgVVNCIG1hc3Mgc3RvcmFnZSBkZXZpY2UgR2VuZXJpYyBN
YXNzIFN0b3JhZ2UgRGV2aWNlICgweDE0Y2Q6MHgxMjVkKQ0KdXNiX21zY19hdXRvX3F1aXJrOiBV
UV9NU0NfTk9fUFJFVkVOVF9BTExPVyBzZXQgZm9yIFVTQiBtYXNzIHN0b3JhZ2UgZGV2aWNlIEdl
bmVyaWMgTWFzcyBTdG9yYWdlIERldmljZSAoMHgxNGNkOjB4MTI1ZCkNCnVzYl9tc2NfYXV0b19x
dWlyazogVVFfTVNDX05PX1NZTkNfQ0FDSEUgc2V0IGZvciBVU0IgbWFzcyBzdG9yYWdlIGRldmlj
ZSBHZW5lcmljIE1hc3MgU3RvcmFnZSBEZXZpY2UgKDB4MTRjZDoweDEyNWQpDQpSb290IG1vdW50
IHdhaXRpbmcgZm9yOiB1c2J1czANCnhoY2kwOiBSZXNldHRpbmcgY29udHJvbGxlcg0KUm9vdCBt
b3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQp1c2JkX3JlcV9yZV9lbnVtZXJhdGU6IGFkZHI9MSwg
c2V0IGFkZHJlc3MgZmFpbGVkISAoVVNCX0VSUl9USU1FT1VULCBpZ25vcmVkKQ0KUm9vdCBtb3Vu
dCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJv
b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNi
dXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2FpdGluZyBm
b3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50IHdh
aXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBt
b3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czAN
ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog
dXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2FpdGlu
ZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50
IHdhaXRpbmcgZm9yOiB1c2J1czANCnVzYmRfc2V0dXBfZGV2aWNlX2Rlc2M6IGdldHRpbmcgZGV2
aWNlIGRlc2NyaXB0b3IgYXQgYWRkciAxIGZhaWxlZCwgVVNCX0VSUl9USU1FT1VUDQpSb290IG1v
dW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0K
dXNiZF9yZXFfcmVfZW51bWVyYXRlOiBhZGRyPTEsIHNldCBhZGRyZXNzIGZhaWxlZCEgKFVTQl9F
UlJfVElNRU9VVCwgaWdub3JlZCkNClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9v
dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1
czANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZv
cjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2Fp
dGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1v
dW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0K
Um9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1
c2J1czANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5n
IGZvcjogdXNidXMwDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANClJvb3QgbW91bnQg
d2FpdGluZyBmb3I6IHVzYnVzMA0KdXNiZF9zZXR1cF9kZXZpY2VfZGVzYzogZ2V0dGluZyBkZXZp
Y2UgZGVzY3JpcHRvciBhdCBhZGRyIDEgZmFpbGVkLCBVU0JfRVJSX1RJTUVPVVQNClJvb3QgbW91
bnQgd2FpdGluZyBmb3I6IHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwDQpS
b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czANCnVzYl9hbGxvY19kZXZpY2U6IEZhaWx1cmUg
c2VsZWN0aW5nIGNvbmZpZ3VyYXRpb24gaW5kZXggMDpVU0JfRVJSX1RJTUVPVVQsIHBvcnQgMiwg
YWRkciAxIChpZ25vcmVkKQ0KdWdlbjAuMjogPEdlbmVyaWMgTWFzcyBTdG9yYWdlIERldmljZT4g
YXQgdXNidXMwDQp1aHViMDogYXQgdXNidXMwLCBwb3J0IDEsIGFkZHIgMSAoZGlzY29ubmVjdGVk
KQ0KdWdlbjAuMjogPEdlbmVyaWMgTWFzcyBTdG9yYWdlIERldmljZT4gYXQgdXNidXMwIChkaXNj
b25uZWN0ZWQpDQp1aHViMDogZGV0YWNoZWQNCnVodWIwIG9uIHVzYnVzMA0KdWh1YjA6IDwoMHgx
YjczKSBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24g
dXNidXMwDQp3YXJuaW5nOiB0b3RhbCBjb25maWd1cmVkIHN3YXAgKDgzODg2MDggcGFnZXMpIGV4
Y2VlZHMgbWF4aW11bSByZWNvbW1lbmRlZCBhbW91bnQgKDgxMzQzODQgcGFnZXMpLg0Kd2Fybmlu
ZzogaW5jcmVhc2Uga2Vybi5tYXhzd3pvbmUgb3IgcmVkdWNlIGFtb3VudCBvZiBzd2FwLg0KdWh1
YjA6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpsbzA6IGxpbmsgc3Rh
dGUgY2hhbmdlZCB0byBVUA0KbXNrMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04NCnVzYl9t
c2NfYXV0b19xdWlyazogVVFfTVNDX05PX0dFVE1BWExVTiBzZXQgZm9yIFVTQiBtYXNzIHN0b3Jh
Z2UgZGV2aWNlIEdlbmVyaWMgTWFzcyBTdG9yYWdlIERldmljZSAoMHgxNGNkOjB4MTI1ZCkNCnVz
Yl9tc2NfYXV0b19xdWlyazogVVFfTVNDX05PX1RFU1RfVU5JVF9SRUFEWSBzZXQgZm9yIFVTQiBt
YXNzIHN0b3JhZ2UgZGV2aWNlIEdlbmVyaWMgTWFzcyBTdG9yYWdlIERldmljZSAoMHgxNGNkOjB4
MTI1ZCkNCnVzYl9tc2NfYXV0b19xdWlyazogVVFfTVNDX05PX1BSRVZFTlRfQUxMT1cgc2V0IGZv
ciBVU0IgbWFzcyBzdG9yYWdlIGRldmljZSBHZW5lcmljIE1hc3MgU3RvcmFnZSBEZXZpY2UgKDB4
MTRjZDoweDEyNWQpDQp1c2JfbXNjX2F1dG9fcXVpcms6IFVRX01TQ19OT19TWU5DX0NBQ0hFIHNl
dCBmb3IgVVNCIG1hc3Mgc3RvcmFnZSBkZXZpY2UgR2VuZXJpYyBNYXNzIFN0b3JhZ2UgRGV2aWNl
ICgweDE0Y2Q6MHgxMjVkKQ0KeGhjaTA6IFJlc2V0dGluZyBjb250cm9sbGVyDQp1c2JkX3JlcV9y
ZV9lbnVtZXJhdGU6IGFkZHI9MSwgc2V0IGFkZHJlc3MgZmFpbGVkISAoVVNCX0VSUl9USU1FT1VU
LCBpZ25vcmVkKQ0KbXNrMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQpTZWN1cml0eSBwb2xp
Y3kgbG9hZGVkOiBNQUMvbnRwZCAobWFjX250cGQpDQp1c2JkX3NldHVwX2RldmljZV9kZXNjOiBn
ZXR0aW5nIGRldmljZSBkZXNjcmlwdG9yIGF0IGFkZHIgMSBmYWlsZWQsIFVTQl9FUlJfVElNRU9V
VA0KdXNiZF9yZXFfcmVfZW51bWVyYXRlOiBhZGRyPTEsIHNldCBhZGRyZXNzIGZhaWxlZCEgKFVT
Ql9FUlJfVElNRU9VVCwgaWdub3JlZCkNCg==

--_003_AC0D625A79594329B4C8A7784FBB09A0exchangemitedu_
Content-Type: text/plain; name="dmesg-good.txt"
Content-Description: dmesg-good.txt
Content-Disposition: attachment; filename="dmesg-good.txt"; size=7511;
	creation-date="Wed, 16 Mar 2022 13:46:06 GMT";
	modification-date="Wed, 16 Mar 2022 13:46:06 GMT"
Content-ID: <15D671F503C48141A553666C2E94E3C5@exchange.mit.edu>
Content-Transfer-Encoding: base64

LS0tPDxCT09UPj4tLS0NCldBUk5JTkc6IENhbm5vdCBmaW5kIGZyZWVic2QsZHRzLXZlcnNpb24g
cHJvcGVydHksIGNhbm5vdCBjaGVjayBEVEIgY29tcGxpYW5jZQ0KQ29weXJpZ2h0IChjKSAxOTky
LTIwMjEgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4
MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRz
IG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQpG
cmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlv
bi4NCkZyZWVCU0QgMTMuMC1TVEFCTEUgIzQgc3RhYmxlLzEzLW4yNDg0NDMtYzg5YzhiODk0Y2Y6
IFR1ZSBEZWMgIDcgMTk6MjM6MjYgRVNUIDIwMjENCiAgICByb290QHN0cmlhdHVzOi91c3Ivb2Jq
L3Vzci9ob21lL2pmYy9mcmVlYnNkL3NyYy9hcm02NC5hYXJjaDY0L3N5cy9HRU5FUklDIGFybTY0
DQpGcmVlQlNEIGNsYW5nIHZlcnNpb24gMTIuMC4xIChnaXRAZ2l0aHViLmNvbTpsbHZtL2xsdm0t
cHJvamVjdC5naXQgbGx2bW9yZy0xMi4wLjEtMC1nZmVkNDEzNDJhODJmKQ0KVlQ6IGluaXQgd2l0
aG91dCBkcml2ZXIuDQptb2R1bGUgZmlybXdhcmUgYWxyZWFkeSBwcmVzZW50IQ0KcmVhbCBtZW1v
cnkgID0gODU3MDAxMTY0OCAoODE3MyBNQikNCmF2YWlsIG1lbW9yeSA9IDgzMjgyMjg4NjQgKDc5
NDIgTUIpDQpTdGFydGluZyBDUFUgMSAoMSkNClN0YXJ0aW5nIENQVSAyICgxMDApDQpTdGFydGlu
ZyBDUFUgMyAoMTAxKQ0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3Rl
ZDogNCBDUFVzDQpyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLg0KcmFuZG9tOiBlbnRyb3B5IGRl
dmljZSBleHRlcm5hbCBpbnRlcmZhY2UNCk1BUCA4MWZiODMwMDAwIG1vZGUgMiBwYWdlcyA5OTIN
Ck1BUCA4MWZiZTEwMDAwIG1vZGUgMiBwYWdlcyA0OTYNCk1BUCA4MWZmZmQwMDAwIG1vZGUgMiBw
YWdlcyAzMg0Ka2JkMCBhdCBrYmRtdXgwDQpvZndidXMwOiA8T3BlbiBGaXJtd2FyZSBEZXZpY2Ug
VHJlZT4NCnNpbXBsZWJ1czA6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24g
b2Z3YnVzMA0KY2xrX2ZpeGVkMDogPEZpeGVkIGNsb2NrPiBvbiBzaW1wbGVidXMwDQpjbGtfZml4
ZWQxOiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19maXhlZDI6IDxGaXhlZCBjbG9j
az4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkMzogPEZpeGVkIGNsb2NrPiBvbiBzaW1wbGVidXMw
DQpjbGtfZml4ZWQ0OiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19maXhlZDU6IDxG
aXhlZCBjbG9jaz4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkNjogPEZpeGVkIGNsb2NrPiBvbiBz
aW1wbGVidXMwDQpjbGtfZml4ZWQ3OiA8Rml4ZWQgY2xvY2s+IG9uIHNpbXBsZWJ1czANCmNsa19m
aXhlZDg6IDxGaXhlZCBjbG9jaz4gb24gc2ltcGxlYnVzMA0KY2xrX2ZpeGVkOTogPEZpeGVkIGNs
b2NrPiBvbiBzaW1wbGVidXMwDQpjbGtfZml4ZWQxMDogPEZpeGVkIGNsb2NrPiBvbiBzaW1wbGVi
dXMwDQpwc2NpMDogPEFSTSBQb3dlciBTdGF0ZSBDby1vcmRpbmF0aW9uIEludGVyZmFjZSBEcml2
ZXI+IG9uIG9md2J1czANCmdpYzA6IDxBUk0gR2VuZXJpYyBJbnRlcnJ1cHQgQ29udHJvbGxlcj4g
bWVtIDB4ZTExMTAwMDAtMHhlMTExMGZmZiwweGUxMTJmMDAwLTB4ZTExMzBmZmYsMHhlMTE0MDAw
MC0weGUxMTRmZmZmLDB4ZTExNjAwMDAtMHhlMTE2ZmZmZiBpcnEgNCBvbiBvZndidXMwDQpnaWMw
OiBwbiAweDIsIGFyY2ggMHgyLCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQzYiBpcnFzIDQ0OA0K
Z2ljdjJtMDogPEFSTSBHZW5lcmljIEludGVycnVwdCBDb250cm9sbGVyIE1TSS9NU0lYPiBtZW0g
MHg4MDAwMC0weDgwZmZmIG9uIGdpYzANCmdlbmVyaWNfdGltZXIwOiA8QVJNdjggR2VuZXJpYyBU
aW1lcj4gaXJxIDUsNiw3LDggb24gb2Z3YnVzMA0KVGltZWNvdW50ZXIgIkFSTSBNUENvcmUgVGlt
ZWNvdW50ZXIiIGZyZXF1ZW5jeSAyNTAwMDAwMDAgSHogcXVhbGl0eSAxMDAwDQpFdmVudCB0aW1l
ciAiQVJNIE1QQ29yZSBFdmVudHRpbWVyIiBmcmVxdWVuY3kgMjUwMDAwMDAwIEh6IHF1YWxpdHkg
MTAwMA0KZWZpcnRjMDogPEVGSSBSZWFsdGltZSBDbG9jaz4NCmVmaXJ0YzA6IHJlZ2lzdGVyZWQg
YXMgYSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAwMDAwMHMNCmNwdWxpc3QwOiA8
T3BlbiBGaXJtd2FyZSBDUFUgR3JvdXA+IG9uIG9md2J1czANCmNwdTA6IDxPcGVuIEZpcm13YXJl
IENQVT4gb24gY3B1bGlzdDANCmNwdTE6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDAN
CmNwdTI6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDANCmNwdTM6IDxPcGVuIEZpcm13
YXJlIENQVT4gb24gY3B1bGlzdDANCnBtdTA6IDxQZXJmb3JtYW5jZSBNb25pdG9yaW5nIFVuaXQ+
IGlycSAwLDEsMiwzIG9uIG9md2J1czANCnBtdTA6IENhbm5vdCBmaW5kIENQVSB3aXRoIE1QSURS
OiAweDAwMDAwMDAyDQpwbXUwOiBDYW5ub3QgcGFyc2UgYWZmaW5pdHkgZm9yIENQVWlkOiAyLg0K
ZGV2aWNlX2F0dGFjaDogcG11MCBhdHRhY2ggcmV0dXJuZWQgNg0KYWhjaTA6IDxBSENJIFNBVEEg
Y29udHJvbGxlcj4gbWVtIDB4ZTAzMDAwMDAtMHhlMDNlZmZmZiBpcnEgOSBvbiBzaW1wbGVidXMw
DQphaGNpMDogQUhDSSB2MS4zMCB3aXRoIDggNkdicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGllciBz
dXBwb3J0ZWQNCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMA0K
YWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwDQp1YXJ0MDogPFBy
aW1lQ2VsbCBVQVJUIChQTDAxMSk+IG1lbSAweGUxMDEwMDAwLTB4ZTEwMTBmZmYgaXJxIDEzIG9u
IHNpbXBsZWJ1czANCnVhcnQwOiBjb25zb2xlICgxMTUyMDAsbiw4LDEpDQpwY2liMDogPEdlbmVy
aWMgUENJIGhvc3QgY29udHJvbGxlcj4gbWVtIDB4ZjAwMDAwMDAtMHhmZmZmZmZmZiBvbiBzaW1w
bGVidXMwDQpwY2kwOiA8UENJIGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+
IGF0IGRldmljZSAyLjIgb24gcGNpMA0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxDQp4aGNpMDog
PFhIQ0kgKGdlbmVyaWMpIFVTQiAzLjAgY29udHJvbGxlcj4gbWVtIDB4NDAxMDAwMDAtMHg0MDEw
ZmZmZiwweDQwMTEwMDAwLTB4NDAxMTBmZmYsMHg0MDExMTAwMC0weDQwMTExZmZmIGF0IGRldmlj
ZSAwLjAgb24gcGNpMQ0KeGhjaTA6IDMyIGJ5dGVzIGNvbnRleHQgc2l6ZSwgNjQtYml0IERNQQ0K
dXNidXMwIG9uIHhoY2kwDQpwY2liMjogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMi4zIG9u
IHBjaTANCnBjaTI6IDxQQ0kgYnVzPiBvbiBwY2liMg0KbXNrYzA6IDxNYXJ2ZWxsIFl1a29uIDg4
RTgwNTkgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAweDEwMDAtMHgxMGZmIG1lbSAweDQwMDAwMDAw
LTB4NDAwMDNmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kyDQptc2swOiA8TWFydmVsbCBUZWNobm9s
b2d5IEdyb3VwIEx0ZC4gWXVrb24gT3B0aW1hIElkIDB4YmMgUmV2IDB4MDE+IG9uIG1za2MwDQpt
c2swOiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4DQptc2swOiBFdGhlcm5l
dCBhZGRyZXNzOiBlMDpmZjpmNzowMDoyMDpmMA0KbWlpYnVzMDogPE1JSSBidXM+IG9uIG1zazAN
CmUxMDAwcGh5MDogPE1hcnZlbGwgUEhZRzY1RyBHaWdhYml0IFBIWT4gUEhZIDAgb24gbWlpYnVz
MA0KZTEwMDBwaHkwOiAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw
YmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAx
MDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93DQphcm12OGNyeXB0bzA6IDxBRVMt
Q0JDLEFFUy1YVFMsQUVTLUdDTT4NClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMN
ClpGUyBmaWxlc3lzdGVtIHZlcnNpb246IDUNClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbjogZmVh
dHVyZXMgc3VwcG9ydCAoNTAwMCkNCnVzYnVzMDogNS4wR2JwcyBTdXBlciBTcGVlZCBVU0IgdjMu
MA0KQ1BVICAwOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMCAgMA0KICAgICAgICAg
ICAgICAgICAgIENhY2hlIFR5cGUgPSA8NjQgYnl0ZSBELWNhY2hlbGluZSw2NCBieXRlIEktY2Fj
aGVsaW5lLFBJUFQgSUNhY2hlLDY0IGJ5dGUgRVJHLDY0IGJ5dGUgQ1dHPg0KIEluc3RydWN0aW9u
IFNldCBBdHRyaWJ1dGVzIDAgPSA8Q1JDMzIsU0hBMixTSEExLEFFUytQTVVMTD4NCiBJbnN0cnVj
dGlvbiBTZXQgQXR0cmlidXRlcyAxID0gPD4NCiAgICAgICAgIFByb2Nlc3NvciBGZWF0dXJlcyAw
ID0gPEFkdlNJTUQsRlAsRUwzIDMyLEVMMiAzMixFTDEgMzIsRUwwIDMyPg0KICAgICAgICAgUHJv
Y2Vzc29yIEZlYXR1cmVzIDEgPSA8Pg0KICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDAgPSA8
VEdyYW40LFRHcmFuNjQsU05TTWVtLEJpZ0VuZCwxNmJpdCBBU0lELDE2VEIgUEE+DQogICAgICBN
ZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDw4Yml0IFZNSUQ+DQogICAgICBNZW1vcnkgTW9kZWwg
RmVhdHVyZXMgMiA9IDwzMmJpdCBDQ0lEWCw0OGJpdCBWQT4NCiAgICAgICAgICAgICBEZWJ1ZyBG
ZWF0dXJlcyAwID0gPERvdWJsZUxvY2ssMiBDVFggQktQVHMsNCBXYXRjaHBvaW50cyw2IEJyZWFr
cG9pbnRzLFBNVXYzLERlYnVndjg+DQogICAgICAgICAgICAgRGVidWcgRmVhdHVyZXMgMSA9IDw+
DQogICAgICAgICBBdXhpbGlhcnkgRmVhdHVyZXMgMCA9IDw+DQogICAgICAgICBBdXhpbGlhcnkg
RmVhdHVyZXMgMSA9IDw+DQpBQXJjaDMyIEluc3RydWN0aW9uIFNldCBBdHRyaWJ1dGVzIDUgPSA8
Q1JDMzIsU0hBMixTSEExLEFFUytWTVVMTCxTRVZMPg0KQUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZl
YXR1cmVzIDAgPSA8RlBSb3VuZCxGUFNxcnQsRlBEaXZpZGUsRFAgVkZQdjMrdjQsU1AgVkZQdjMr
djQsQWR2U0lNRD4NCkFBcmNoMzIgTWVkaWEgYW5kIFZGUCBGZWF0dXJlcyAxID0gPFNJTURGTUFD
LEZQSFAgRFAgQ29udixTSU1ESFAgU1AgQ29udixTSU1EU1AsU0lNREludCxTSU1ETFMsRlBETmFO
LEZQRnRaPg0KQ1BVICAxOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMCAgMQ0KQ1BV
ICAyOiBBUk0gQ29ydGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMSAgMA0KQ1BVICAzOiBBUk0gQ29y
dGV4LUE1NyByMXAyIGFmZmluaXR5OiAgMSAgMQ0KUmVsZWFzZSBBUHMuLi5kb25lDQp1Z2VuMC4x
OiA8MHgxYjczIFhIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMA0KVHJ5aW5nIHRvIG1vdW50IHJvb3Qg
ZnJvbSB6ZnM6enJvb3QvUk9PVC9kZWZhdWx0IFtdLi4uDQp1aHViMFJvb3QgbW91bnQgd2FpdGlu
ZyBmb3I6IG9uIHVzYnVzMA0KIENBTXVodWIwOiA8MHgxYjczIFhIQ0kgcm9vdCBIVUIsIGNsYXNz
IDkvMCwgcmV2IDMuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czANCiB1c2J1czANCmFkYTAgYXQg
YWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDANCmFkYTA6IDxQYXRyaW90IFAyMDAg
MVRCIFMwNDI0QTA+IEFDUy0yIEFUQSBTQVRBIDMueCBkZXZpY2UNCmFkYTA6IFNlcmlhbCBOdW1i
ZXIgQUEwMDAwMDAwMDAwMDAwMDA1MDkNCmFkYTA6IDYwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FU
QSAzLngsIFVETUE2LCBQSU8gNTEyYnl0ZXMpDQphZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJs
ZWQNCmFkYTA6IDk3Njc2Mk1CICgyMDAwNDA5MjY0IDUxMiBieXRlIHNlY3RvcnMpDQp1aHViMDog
NCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClJvb3QgbW91bnQgd2FpdGlu
ZyBmb3I6IHVzYnVzMA0KdWdlbjAuMjogPEdlbmVyaWMgTWFzcyBTdG9yYWdlIERldmljZT4gYXQg
dXNidXMwDQp1bWFzczAgb24gdWh1YjANCnVtYXNzMDogPEdlbmVyaWMgTWFzcyBTdG9yYWdlIERl
dmljZSwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMA0KdW1hc3Mw
OiAgU0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtzID0gMHhjMTAwDQp1bWFzczA6MjowOiBBdHRh
Y2hlZCB0byBzY2J1czINCmRhMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHNjYnVzMiB0YXJnZXQgMCBs
dW4gMA0KZGEwOiA8TWFzcyBTdG9yYWdlIERldmljZSA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNz
IFNDU0kgZGV2aWNlDQpkYTA6IFNlcmlhbCBOdW1iZXIgMTI1RDIwMTQwMzEwDQpkYTA6IDQwLjAw
ME1CL3MgdHJhbnNmZXJzDQpkYTA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVk
OiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudA0KZGEwOiBxdWlya3M9MHgyPE5PXzZfQllU
RT4NCndhcm5pbmc6IHRvdGFsIGNvbmZpZ3VyZWQgc3dhcCAoODM4ODYwOCBwYWdlcykgZXhjZWVk
cyBtYXhpbXVtIHJlY29tbWVuZGVkIGFtb3VudCAoODEzNDM4NCBwYWdlcykuDQp3YXJuaW5nOiBp
bmNyZWFzZSBrZXJuLm1heHN3em9uZSBvciByZWR1Y2UgYW1vdW50IG9mIHN3YXAuDQpsbzA6IGxp
bmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KbW9kdWxlX3JlZ2lzdGVyOiBjYW5ub3QgcmVnaXN0ZXIg
cGNpL21za2MgZnJvbSBpZl9tc2sua287IGFscmVhZHkgbG9hZGVkIGZyb20ga2VybmVsDQpNb2R1
bGUgcGNpL21za2MgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbW9kdWxlX3JlZ2lzdGVyOiBjYW5u
b3QgcmVnaXN0ZXIgbXNrYy9tc2sgZnJvbSBpZl9tc2sua287IGFscmVhZHkgbG9hZGVkIGZyb20g
a2VybmVsDQpNb2R1bGUgbXNrYy9tc2sgZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbW9kdWxlX3Jl
Z2lzdGVyOiBjYW5ub3QgcmVnaXN0ZXIgbXNrL21paWJ1cyBmcm9tIGlmX21zay5rbzsgYWxyZWFk
eSBsb2FkZWQgZnJvbSBrZXJuZWwNCk1vZHVsZSBtc2svbWlpYnVzIGZhaWxlZCB0byByZWdpc3Rl
cjogMTcNCm1zazA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQptb2R1bGVfcmVnaXN0ZXI6
IGNhbm5vdCByZWdpc3RlciBwY2kvbXNrYyBmcm9tIGlmX21zay5rbzsgYWxyZWFkeSBsb2FkZWQg
ZnJvbSBrZXJuZWwNCk1vZHVsZSBwY2kvbXNrYyBmYWlsZWQgdG8gcmVnaXN0ZXI6IDE3DQptb2R1
bGVfcmVnaXN0ZXI6IGNhbm5vdCByZWdpc3RlciBtc2tjL21zayBmcm9tIGlmX21zay5rbzsgYWxy
ZWFkeSBsb2FkZWQgZnJvbSBrZXJuZWwNCk1vZHVsZSBtc2tjL21zayBmYWlsZWQgdG8gcmVnaXN0
ZXI6IDE3DQptb2R1bGVfcmVnaXN0ZXI6IGNhbm5vdCByZWdpc3RlciBtc2svbWlpYnVzIGZyb20g
aWZfbXNrLmtvOyBhbHJlYWR5IGxvYWRlZCBmcm9tIGtlcm5lbA0KTW9kdWxlIG1zay9taWlidXMg
ZmFpbGVkIHRvIHJlZ2lzdGVyOiAxNw0KbXNrMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQDQpT
ZWN1cml0eSBwb2xpY3kgbG9hZGVkOiBNQUMvbnRwZCAobWFjX250cGQpDQo=

--_003_AC0D625A79594329B4C8A7784FBB09A0exchangemitedu_--

From nobody Wed Mar 16 14:17:58 2022
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 BCD731A154B0
	for ; Wed, 16 Mar 2022 14:18:13 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4KJXS46dDvz3JSF
	for ; Wed, 16 Mar 2022 14:18:12 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id r13so4504873ejd.5
        for ; Wed, 16 Mar 2022 07:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=T5HZuer/7iwMLXoQqDtJatItWyURiGIOyvFXIPfBCWw=;
        b=qAK3KpBsABB+d8ONhz/yIyanujQMi1787Hspn/euXQJUkdi4oDZa8KoX5dUZ9evV9c
         M6ZTM6Es6xoFMcBDbPlSKVpwZKce2SoW7xXjTcL5m41gUiDoq7DSbpi8Xr90dnui7Xde
         +uWaTm82PmlCEmaMLjWqBbP2XE8zI7P2g/aUit8nm7SbbeJwy2THWs52CVZo5oBkGLvV
         Pe3wfB5py398xWazDLWztywwKVztfQgn/RGhSHnKfI0j0RSi77kwAf7nUH5YFTdXNu5I
         yxPJ7kfouK+LOCsd47k9lYlCM0G+1yB7LHSetXnyIpic0JP1cnMylAC92NtxQB0zPNp8
         ppCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=T5HZuer/7iwMLXoQqDtJatItWyURiGIOyvFXIPfBCWw=;
        b=06udhj0kcZ534YTYYa1wCHC2EOhCfn9sCeQz1Xgy/b5k5RFBAPWjOlr7P7mgfBm8vR
         TvModzlIB34x2oddT/uYawr2T2rmf66hLFG6/LI/whUkt5e1J1rUw659VGL7k528EzVm
         qq5Dpb86i7tZBOptpSt/4MbQgY12Cct+YQ4AegGkFtg63MShgcxkYe7niZ1zf3luNRtI
         9CAGgRoYxR8LUbCd9x+grlao9BmdGM/vjo5coJtN5X5PQzf0adfIj3TrNnzGeq2TMuiS
         JU7yp9ZSAFgjgIrSQIT/km71FAnVtMk/xp9fAlCQgqum7H42wB/O2oB13/K1uyEVaQ+v
         d66Q==
X-Gm-Message-State: AOAM531i9B8GL8w6YErEsJdxgSsUQypPwtnwgIgHbXIMd9pudEhvf8jy
	no4pdBhbMCLL0ks3ieJC0k2zc7brff7naq6+s/iwrD1gIaY=
X-Google-Smtp-Source: ABdhPJzaVXVlzlnabyT5UpJ7qP4g1ubTBvF+7ONIuYFBgQFpzYCjnu+sDThoQGDbzltxuj6DDnAm6S4+KAZCqTEIcrc=
X-Received: by 2002:a17:906:4fc4:b0:6da:b4c6:fadb with SMTP id
 i4-20020a1709064fc400b006dab4c6fadbmr219295ejw.282.1647440291883; Wed, 16 Mar
 2022 07:18:11 -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: 
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Wed, 16 Mar 2022 22:17:58 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000062f22605da569522"
X-Rspamd-Queue-Id: 4KJXS46dDvz3JSF
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qAK3KpBs;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.30 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.989];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.69)[0.685];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2119
Lines: 51

--00000000000062f22605da569522
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 16, 2022 at 9:31 PM Hans Petter Selasky  wrote:

> Hi Archimedes,
>
> I don't see any issue in there. There should be a print containing ERROR .
>
> Did you set the DWC OTG debug level to 17 ?
>


Hi Hans,

I tried that with debug level 17 on DWC OTG but my keyboard seems not
responsive even when I unplug and re-plugged the keyboard. That's why I
just stay to level 1. Let me try this time, I have an idea, I'll put this
printing script in cron and run it there and then have the debug level at
17. Let's see how it goes.

Thanks,
Archimedes

--00000000000062f22605da569522
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Mar 16, 2022 at 9:31 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
Hi Arc=
himedes,



I don't see any issue in there. There should be a print containing ERRO=
R .



Did you set the DWC OTG debug level to 17 ?

=

Hi Hans,

I tried that with debug level 17 on=
 DWC OTG but my keyboard seems not responsive even when I unplug and re-plu=
gged the keyboard. That's why I just stay to level 1. Let me try this t=
ime, I have an idea, I'll put this printing script in cron and run it t=
here and then have the debug level at 17. Let's see how it goes.

Thanks,<=
/div>
Archimedes






--00000000000062f22605da569522--

From nobody Wed Mar 16 14:51:35 2022
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 476F41A1EC81
	for ; Wed, 16 Mar 2022 14:51:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KJYBt2nncz3QRY
	for ; Wed, 16 Mar 2022 14:51:50 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id A7F5B26067C;
	Wed, 16 Mar 2022 15:51:48 +0100 (CET)
Message-ID: 
Date: Wed, 16 Mar 2022 15:51:35 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: USB regression on Overdrive 1000
Content-Language: en-US
To: John F Carr , freebsd-arm 
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KJYBt2nncz3QRY
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-0.66 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-0.38)[-0.378];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.98)[-0.977];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2181
Lines: 44

On 3/16/22 14:46, John F Carr wrote:
> I updated my kernel from 13.0-STABLE from early December to 13.1-STABLE from yesterday and I am having USB problems on my Overdrive 1000 ARM box.  I see some usb_msc_auto_quirk messages I haven't seen before and there is a long delay "Root mount waiting for: usbus0".  It does boot eventually off of the internal drive, ada0, but it continues to spew USB errors to the console.  It doesn't register a "CAMuhub0" device and it never finds the USB stick plugged into the external port which should appear as da0.  Any ideas?
> 
> dmesg output attached, "good" comes from "boot kernel.old".  The if_msk error is probably caused by a mismatch between old kernel and new root filesystem.
> 
> 
> CPU  3: ARM Cortex-A57 r1p2 affinity:  1  1
> Release APs...done
> usbus0: 5.0Gbps Super Speed USB v3.0
> Trying to mount root from zfs:zroot/ROOT/default []...
> ugen0.1: <(0x1b73) XHCI root HUB> at usbus0
> uhub0 on usbus0
> uhub0: <(0x1b73) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
> ada0:  ACS-2 ATA SATA 3.x device
> ...
> Root mount waiting for: usbus0
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> Root mount waiting for: usbus0
> xhci0: Resetting controller
> Root mount waiting for: usbus0
> usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_TIMEOUT, ignored)
> Root mount waiting for: usbus0
> ...
> xhci0: Resetting controller
> 

Hi,

Can you cherry pick this commit:

https://cgit.freebsd.org/src/commit/?id=33cbbf268f7d0f3daff0c2aa06836d932faf56a9

to your 13-stable and enable it in the loader either manually or in 
/boot/loader.conf:

set hw.usb.xhci.dcepquirk=1

hw.usb.xhci.dcepquirk=1

--HPS

From nobody Wed Mar 16 15:43:10 2022
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 9A5951A2C9DF
	for ; Wed, 16 Mar 2022 15:43:43 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJZLl1YhPz3qKS
	for ; Wed, 16 Mar 2022 15:43:43 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18])
	by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 22GFhA25012323;
	Wed, 16 Mar 2022 11:43:42 -0400
Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by
 oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id
 15.0.1497.32; Wed, 16 Mar 2022 11:42:52 -0400
Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by
 oc11expo29.exchange.mit.edu (18.9.4.102) with Microsoft SMTP Server (TLS) id
 15.0.1497.23; Wed, 16 Mar 2022 11:43:11 -0400
Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by
 oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.023; Wed,
 16 Mar 2022 11:43:10 -0400
From: John F Carr 
To: Hans Petter Selasky 
CC: freebsd-arm 
Subject: Re: USB regression on Overdrive 1000
Thread-Topic: USB regression on Overdrive 1000
Thread-Index: AQHYOTwvT6JTIbjcM0e48iyzgwO8ZKzCWz+AgAAOagA=
Date: Wed, 16 Mar 2022 15:43:10 +0000
Message-ID: <9831B325-242D-4143-B043-F150A9646672@exchange.mit.edu>
References: 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [108.7.221.50]
Content-Type: multipart/mixed;
	boundary="_002_9831B325242D4143B043F150A9646672exchangemitedu_"
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-Rspamd-Queue-Id: 4KJZLl1YhPz3qKS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.59 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 RCVD_COUNT_FIVE(0.00)[5];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 HAS_ATTACHMENT(0.00)[];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[18.9.28.59:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 RCVD_IN_DNSWL_MED(-0.20)[18.9.28.59:from];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3813
Lines: 89

--_002_9831B325242D4143B043F150A9646672exchangemitedu_
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable


> On Mar 16, 2022, at 10:51 , Hans Petter Selasky  wrote:
>=20
> On 3/16/22 14:46, John F Carr wrote:
>> I updated my kernel from 13.0-STABLE from early December to 13.1-STABLE =
from yesterday and I am having USB problems on my Overdrive 1000 ARM box.  =
I see some usb_msc_auto_quirk messages I haven't seen before and there is a=
 long delay "Root mount waiting for: usbus0".  It does boot eventually off =
of the internal drive, ada0, but it continues to spew USB errors to the con=
sole.  It doesn't register a "CAMuhub0" device and it never finds the USB s=
tick plugged into the external port which should appear as da0.  Any ideas?
>> dmesg output attached, "good" comes from "boot kernel.old".  The if_msk =
error is probably caused by a mismatch between old kernel and new root file=
system.
>> CPU  3: ARM Cortex-A57 r1p2 affinity:  1  1
>> Release APs...done
>> usbus0: 5.0Gbps Super Speed USB v3.0
>> Trying to mount root from zfs:zroot/ROOT/default []...
>> ugen0.1: <(0x1b73) XHCI root HUB> at usbus0
>> uhub0 on usbus0
>> uhub0: <(0x1b73) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usb=
us0
>> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
>> ada0:  ACS-2 ATA SATA 3.x device
>> ...
>> Root mount waiting for: usbus0
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Generic Mass Storage Device (0x14cd:0x125d)
>> usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage d=
evice Generic Mass Storage Device (0x14cd:0x125d)
>> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage dev=
ice Generic Mass Storage Device (0x14cd:0x125d)
>> usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device=
 Generic Mass Storage Device (0x14cd:0x125d)
>> Root mount waiting for: usbus0
>> xhci0: Resetting controller
>> Root mount waiting for: usbus0
>> usbd_req_re_enumerate: addr=3D1, set address failed! (USB_ERR_TIMEOUT, i=
gnored)
>> Root mount waiting for: usbus0
>> ...
>> xhci0: Resetting controller
>=20
> Hi,
>=20
> Can you cherry pick this commit:
>=20
> https://cgit.freebsd.org/src/commit/?id=3D33cbbf268f7d0f3daff0c2aa06836d9=
32faf56a9
>=20
> to your 13-stable and enable it in the loader either manually or in /boot=
/loader.conf:
>=20
> set hw.usb.xhci.dcepquirk=3D1
>=20
> hw.usb.xhci.dcepquirk=3D1
>=20
> --HPS

That fixed it.  I attached a diff to recognize the USB controller in my sys=
tem.


--_002_9831B325242D4143B043F150A9646672exchangemitedu_
Content-Type: application/octet-stream; name="xhci.diff"
Content-Description: xhci.diff
Content-Disposition: attachment; filename="xhci.diff"; size=514;
	creation-date="Wed, 16 Mar 2022 15:43:10 GMT";
	modification-date="Wed, 16 Mar 2022 15:43:10 GMT"
Content-ID: <18F81D820AC25B4EA8F670255AD7E800@exchange.mit.edu>
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNiL2NvbnRyb2xsZXIveGhjaV9wY2kuYyBiL3N5cy9kZXYv
dXNiL2NvbnRyb2xsZXIveGhjaV9wY2kuYw0KaW5kZXggYmUxMmQ4YzMzMzguLjMxYTNjODgyYmYy
IDEwMDY0NA0KLS0tIGEvc3lzL2Rldi91c2IvY29udHJvbGxlci94aGNpX3BjaS5jDQorKysgYi9z
eXMvZGV2L3VzYi9jb250cm9sbGVyL3hoY2lfcGNpLmMNCkBAIC0yODcsNiArMjg3LDcgQEAgeGhj
aV9wY2lfYXR0YWNoKGRldmljZV90IHNlbGYpDQogCXNjLT5zY19pb19zaXplID0gcm1hbl9nZXRf
c2l6ZShzYy0+c2NfaW9fcmVzKTsNCiANCiAJc3dpdGNoIChwY2lfZ2V0X2RldmlkKHNlbGYpKSB7
DQorCWNhc2UgMHgxMDA5MWI3MzoJLyogRnJlc2NvIExvZ2ljIEZMMTAwOSBVU0IgMy4wIEhvc3Qg
Q29udHJvbGxlciAqLw0KIAljYXNlIDB4ODI0MTEwNGM6CS8qIFRVU0I3M3gwIFVTQjMuMCB4SENJ
IENvbnRyb2xsZXIgKi8NCiAJCXNjLT5zY19ub19kZWNvbmZpZ3VyZSA9IDE7DQogCQlicmVhazsN
Cg==

--_002_9831B325242D4143B043F150A9646672exchangemitedu_--

From nobody Wed Mar 16 15:50:59 2022
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 DCD951A2E6E4
	for ; Wed, 16 Mar 2022 15:51:14 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KJZWP6KtDz3rQj
	for ; Wed, 16 Mar 2022 15:51:13 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id E63CB26019E;
	Wed, 16 Mar 2022 16:51:11 +0100 (CET)
Message-ID: 
Date: Wed, 16 Mar 2022 16:50:59 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: USB regression on Overdrive 1000
Content-Language: en-US
To: John F Carr 
Cc: freebsd-arm 
References: 
 
 <9831B325-242D-4143-B043-F150A9646672@exchange.mit.edu>
From: Hans Petter Selasky 
In-Reply-To: <9831B325-242D-4143-B043-F150A9646672@exchange.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KJZWP6KtDz3rQj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.99 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-0.78)[-0.777];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.918];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2667
Lines: 57

On 3/16/22 16:43, John F Carr wrote:
> 
>> On Mar 16, 2022, at 10:51 , Hans Petter Selasky  wrote:
>>
>> On 3/16/22 14:46, John F Carr wrote:
>>> I updated my kernel from 13.0-STABLE from early December to 13.1-STABLE from yesterday and I am having USB problems on my Overdrive 1000 ARM box.  I see some usb_msc_auto_quirk messages I haven't seen before and there is a long delay "Root mount waiting for: usbus0".  It does boot eventually off of the internal drive, ada0, but it continues to spew USB errors to the console.  It doesn't register a "CAMuhub0" device and it never finds the USB stick plugged into the external port which should appear as da0.  Any ideas?
>>> dmesg output attached, "good" comes from "boot kernel.old".  The if_msk error is probably caused by a mismatch between old kernel and new root filesystem.
>>> CPU  3: ARM Cortex-A57 r1p2 affinity:  1  1
>>> Release APs...done
>>> usbus0: 5.0Gbps Super Speed USB v3.0
>>> Trying to mount root from zfs:zroot/ROOT/default []...
>>> ugen0.1: <(0x1b73) XHCI root HUB> at usbus0
>>> uhub0 on usbus0
>>> uhub0: <(0x1b73) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
>>> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
>>> ada0:  ACS-2 ATA SATA 3.x device
>>> ...
>>> Root mount waiting for: usbus0
>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
>>> usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
>>> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
>>> usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
>>> Root mount waiting for: usbus0
>>> xhci0: Resetting controller
>>> Root mount waiting for: usbus0
>>> usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_TIMEOUT, ignored)
>>> Root mount waiting for: usbus0
>>> ...
>>> xhci0: Resetting controller
>>
>> Hi,
>>
>> Can you cherry pick this commit:
>>
>> https://cgit.freebsd.org/src/commit/?id=33cbbf268f7d0f3daff0c2aa06836d932faf56a9
>>
>> to your 13-stable and enable it in the loader either manually or in /boot/loader.conf:
>>
>> set hw.usb.xhci.dcepquirk=1
>>
>> hw.usb.xhci.dcepquirk=1
>>
>> --HPS
> 
> That fixed it.  I attached a diff to recognize the USB controller in my system.
> 

Hi,

Here you go:
https://cgit.freebsd.org/src/commit/?id=19837718ab51756183046e5162b8b3b7b3cb8c3d

Will be MFC'ed to 13-stable next week.

I will try to get these patches int 13.1, but no promise.

--HPS

From nobody Wed Mar 16 15:52:43 2022
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 E8C801A2EA5D
	for ; Wed, 16 Mar 2022 15:52:54 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mail.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 4KJZYK5kbhz3rj5
	for ; Wed, 16 Mar 2022 15:52:53 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1647445966;
	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=djhKB11X4/X0it76x62+XTGbr3D164RY5xsFVNqgVJI=;
	b=tM9EDqS1tthWyud9Tm2sH1mtOSD0zJpa6s5wG31CYkv3QtQ+v7972/mai6QlRCDApkpl93
	jl4nfTp0t8kY6f5wI971k23SMxVhm2ly2PPJMLm3+97sKl4HzkzXLTNdLnj/8ycv8IEP8l
	x47ldyji+o9HaPbm5W7YIqYIiHJjdLc=
Received: from skull.home.blih.net (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id d7e795af (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Wed, 16 Mar 2022 15:52:45 +0000 (UTC)
Date: Wed, 16 Mar 2022 16:52:43 +0100
From: Emmanuel Vadot 
To: Hans Petter Selasky 
Cc: John F Carr , freebsd-arm 
Subject: Re: USB regression on Overdrive 1000
Message-Id: <20220316165243.f4e6936f6e13f94586c11371@bidouilliste.com>
In-Reply-To: 
References: 
	
	<9831B325-242D-4143-B043-F150A9646672@exchange.mit.edu>
	
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: 4KJZYK5kbhz3rj5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=tM9EDqS1;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2974
Lines: 70


 Hi Hans,

On Wed, 16 Mar 2022 16:50:59 +0100
Hans Petter Selasky  wrote:

> On 3/16/22 16:43, John F Carr wrote:
> > 
> >> On Mar 16, 2022, at 10:51 , Hans Petter Selasky  wrote:
> >>
> >> On 3/16/22 14:46, John F Carr wrote:
> >>> I updated my kernel from 13.0-STABLE from early December to 13.1-STABLE from yesterday and I am having USB problems on my Overdrive 1000 ARM box.  I see some usb_msc_auto_quirk messages I haven't seen before and there is a long delay "Root mount waiting for: usbus0".  It does boot eventually off of the internal drive, ada0, but it continues to spew USB errors to the console.  It doesn't register a "CAMuhub0" device and it never finds the USB stick plugged into the external port which should appear as da0.  Any ideas?
> >>> dmesg output attached, "good" comes from "boot kernel.old".  The if_msk error is probably caused by a mismatch between old kernel and new root filesystem.
> >>> CPU  3: ARM Cortex-A57 r1p2 affinity:  1  1
> >>> Release APs...done
> >>> usbus0: 5.0Gbps Super Speed USB v3.0
> >>> Trying to mount root from zfs:zroot/ROOT/default []...
> >>> ugen0.1: <(0x1b73) XHCI root HUB> at usbus0
> >>> uhub0 on usbus0
> >>> uhub0: <(0x1b73) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> >>> ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
> >>> ada0:  ACS-2 ATA SATA 3.x device
> >>> ...
> >>> Root mount waiting for: usbus0
> >>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> >>> usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> >>> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> >>> usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device Generic Mass Storage Device (0x14cd:0x125d)
> >>> Root mount waiting for: usbus0
> >>> xhci0: Resetting controller
> >>> Root mount waiting for: usbus0
> >>> usbd_req_re_enumerate: addr=1, set address failed! (USB_ERR_TIMEOUT, ignored)
> >>> Root mount waiting for: usbus0
> >>> ...
> >>> xhci0: Resetting controller
> >>
> >> Hi,
> >>
> >> Can you cherry pick this commit:
> >>
> >> https://cgit.freebsd.org/src/commit/?id=33cbbf268f7d0f3daff0c2aa06836d932faf56a9
> >>
> >> to your 13-stable and enable it in the loader either manually or in /boot/loader.conf:
> >>
> >> set hw.usb.xhci.dcepquirk=1
> >>
> >> hw.usb.xhci.dcepquirk=1
> >>
> >> --HPS
> > 
> > That fixed it.  I attached a diff to recognize the USB controller in my system.
> > 
> 
> Hi,
> 
> Here you go:
> https://cgit.freebsd.org/src/commit/?id=19837718ab51756183046e5162b8b3b7b3cb8c3d
> 
> Will be MFC'ed to 13-stable next week.
> 
> I will try to get these patches int 13.1, but no promise.

 This need to go to 13.1, thanks.

> --HPS
> 


-- 
Emmanuel Vadot  

From nobody Wed Mar 16 16:32:13 2022
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 995C91A0AEC2
	for ; Wed, 16 Mar 2022 16:32:28 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182])
	(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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJbQz3GMXz4WZq
	for ; Wed, 16 Mar 2022 16:32:27 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from smtpclient.apple (87-95-51-103.bb.dnainternet.fi [87.95.51.103])
	(authenticated bits=0)
	by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 22GGWIgc045236
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Wed, 16 Mar 2022 16:32:19 GMT
	(envelope-from sparvu@kronometrix.org)
X-Authentication-Warning: mail.kronometrix.org: Host 87-95-51-103.bb.dnainternet.fi [87.95.51.103] claimed to be smtpclient.apple
From: Stefan Parvu 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 15.0 \(3693.60.0.1.1\))
Subject: RBPI4B+ 2GB using FreeBSD 13.1 RC1
Message-Id: 
Date: Wed, 16 Mar 2022 18:32:13 +0200
To: freebsd-arm 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KJbQz3GMXz4WZq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org
X-Spamd-Result: default: False [-2.68 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 HAS_XAW(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-0.97)[-0.975];
	 DMARC_NA(0.00)[kronometrix.org];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+a];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_MEDIUM(-0.90)[-0.901];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 402
Lines: 16

Hi all,

I am trying to see how stable FreeBSD 13 is on latest RBPI 4B+ boards.
 
I am using at the moment a RBPI 4B+ 2GB with a 64GB microsd 
SanDisk high endurance. No go.

I get a register dump and an error: no compatible cards found on bus. 

The RBPI4B+ 1GB boots fine and I can login.

Anyone any ideas!? Should I wait for 13.1 RELEASE or can I do anything 
to boot on 2GB model?

Thanks,
Stefan

From nobody Wed Mar 16 16:49:00 2022
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 54D681A0F3CF
	for ; Wed, 16 Mar 2022 16:49:24 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJbpW4MmRz4YNR
	for ; Wed, 16 Mar 2022 16:49:23 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20])
	by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 22GGnFXf078476
	for ; Wed, 16 Mar 2022 11:49:15 -0500 (CDT)
	(envelope-from mgrooms@shrew.net)
Received: from [10.16.32.30] (65-36-5-114.static.grandenetworks.net [65.36.5.114])
	by mail.shrew.net (Postfix) with ESMTPSA id DBC2719DBA9
	for ; Wed, 16 Mar 2022 11:49:10 -0500 (CDT)
Message-ID: <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
Date: Wed, 16 Mar 2022 11:49:00 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
From: Matthew Grooms 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Wed, 16 Mar 2022 11:49:15 -0500 (CDT)
X-Rspamd-Queue-Id: 4KJbpW4MmRz4YNR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DMARC_NA(0.00)[shrew.net];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 957
Lines: 31

Does your device have a C0T at the end of the CPU part number?

https://www.jeffgeerling.com/blog/2021/raspberry-pi-4-model-bs-arriving-newer-c0-stepping

I had some problems with this as well but I've had trouble narrowing 
down the criteria that causes the failure at the very same place in the 
boot process. I've read the open ticket related to this and don't see an 
answer to this particular problem there ...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080

-Matthew

On 3/16/2022 11:32 AM, Stefan Parvu wrote:
> Hi all,
>
> I am trying to see how stable FreeBSD 13 is on latest RBPI 4B+ boards.
>   
> I am using at the moment a RBPI 4B+ 2GB with a 64GB microsd
> SanDisk high endurance. No go.
>
> I get a register dump and an error: no compatible cards found on bus.
>
> The RBPI4B+ 1GB boots fine and I can login.
>
> Anyone any ideas!? Should I wait for 13.1 RELEASE or can I do anything
> to boot on 2GB model?
>
> Thanks,
> Stefan
>

From nobody Wed Mar 16 16:54:06 2022
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 DE59B1A10BDF
	for ; Wed, 16 Mar 2022 16:54:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KJbwG5sv0z4ZQg
	for ; Wed, 16 Mar 2022 16:54:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 748952600B0;
	Wed, 16 Mar 2022 17:54:19 +0100 (CET)
Message-ID: 
Date: Wed, 16 Mar 2022 17:54:06 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: USB regression on Overdrive 1000
Content-Language: en-US
To: Emmanuel Vadot 
Cc: John F Carr , freebsd-arm 
References: 
 
 <9831B325-242D-4143-B043-F150A9646672@exchange.mit.edu>
 
 <20220316165243.f4e6936f6e13f94586c11371@bidouilliste.com>
From: Hans Petter Selasky 
In-Reply-To: <20220316165243.f4e6936f6e13f94586c11371@bidouilliste.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KJbwG5sv0z4ZQg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.64 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-0.79)[-0.791];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_SPAM_LONG(0.45)[0.452];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 357
Lines: 15

>> Hi,
>>
>> Here you go:
>> https://cgit.freebsd.org/src/commit/?id=19837718ab51756183046e5162b8b3b7b3cb8c3d
>>
>> Will be MFC'ed to 13-stable next week.
>>
>> I will try to get these patches int 13.1, but no promise.
> 
>   This need to go to 13.1, thanks.

I'll try to MFC it tomorrow, and then request it for releng, before the 
next beta build.

--HPS

From nobody Wed Mar 16 17:02:29 2022
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 330371A1246E
	for ; Wed, 16 Mar 2022 17:02:39 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182])
	(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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJc5p2KZYz4bLy
	for ; Wed, 16 Mar 2022 17:02:38 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from smtpclient.apple (87-95-51-103.bb.dnainternet.fi [87.95.51.103])
	(authenticated bits=0)
	by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 22GH2YdO082115
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Wed, 16 Mar 2022 17:02:35 GMT
	(envelope-from sparvu@kronometrix.org)
X-Authentication-Warning: mail.kronometrix.org: Host 87-95-51-103.bb.dnainternet.fi [87.95.51.103] claimed to be smtpclient.apple
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 15.0 \(3693.60.0.1.1\))
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
From: Stefan Parvu 
In-Reply-To: <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
Date: Wed, 16 Mar 2022 19:02:29 +0200
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
To: Matthew Grooms 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KJc5p2KZYz4bLy
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 MIME_GOOD(-0.10)[text/plain];
	 HAS_XAW(0.00)[];
	 DMARC_NA(0.00)[kronometrix.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 452
Lines: 19

Looks like B0T=E2=80=A6=20

BROADCOM
2711ZPKFSB06B0T
TE1915
126-56 B3 W

>=20
> I had some problems with this as well but I've had trouble narrowing =
down the criteria that causes the failure at the very same place in the =
boot process. I've read the open ticket related to this and don't see an =
answer to this particular problem there ...
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255080


Thanks. Will dig into that.=20

Stefan=

From nobody Wed Mar 16 17:25:46 2022
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 216431A18D66
	for ; Wed, 16 Mar 2022 17:26:01 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJccm1CgKz4frY
	for ; Wed, 16 Mar 2022 17:26:00 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20])
	by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 22GHPq48007716
	for ; Wed, 16 Mar 2022 12:25:52 -0500 (CDT)
	(envelope-from mgrooms@shrew.net)
Received: from [10.16.32.30] (65-36-5-114.static.grandenetworks.net [65.36.5.114])
	by mail.shrew.net (Postfix) with ESMTPSA id B595C19CE3A
	for ; Wed, 16 Mar 2022 12:25:47 -0500 (CDT)
Message-ID: 
Date: Wed, 16 Mar 2022 12:25:46 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
 
From: Matthew Grooms 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Wed, 16 Mar 2022 12:25:52 -0500 (CDT)
X-Rspamd-Queue-Id: 4KJccm1CgKz4frY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DMARC_NA(0.00)[shrew.net];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2103
Lines: 63

Interesting. If you're building the kernel from scratch, deleting the 
entire contents of MAKEOBJDIRPREFIX directory before a rebuilding helped 
at one point. Also, maybe try copying in the latest pkg firmware and 
rpi4 u-boot versions. Here's what I do after mounting the sd card to 
/mnt ...

u-boot-rpi4-2021.07_1:

cp /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin 
/mnt/boot/msdos/u-boot.bin

rpi-firmware-1.20210303.g20210303:

cp /usr/local/share/rpi-firmware/armstub8-gic.bin /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/armstub8.bin /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/bcm2710-rpi-2-b.dtb /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/bcm2710-rpi-3-b-plus.dtb /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/bcm2710-rpi-3-b.dtb /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/bcm2711-rpi-4-b.dtb /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/bootcode.bin /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/fixup* /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/start* /mnt/boot/msdos/
cp /usr/local/share/rpi-firmware/overlays/disable-bt.dtbo 
/mnt/boot/msdos/overlays/
cp /usr/local/share/rpi-firmware/overlays/mmc.dtbo /mnt/boot/msdos/overlays/
cp /usr/local/share/rpi-firmware/overlays/pwm.dtbo /mnt/boot/msdos/overlays/
cp /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin 
/mnt/boot/msdos/u-boot.bin

And here is what I have in my config.txt:

[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=pwm
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi4]
hdmi_safe=0
armstub=armstub8-gic.bin

Hope this helps,

-Matthew

On 3/16/2022 12:02 PM, Stefan Parvu wrote:
> Looks like B0T…
>
> BROADCOM
> 2711ZPKFSB06B0T
> TE1915
> 126-56 B3 W
>
>> I had some problems with this as well but I've had trouble narrowing down the criteria that causes the failure at the very same place in the boot process. I've read the open ticket related to this and don't see an answer to this particular problem there ...
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080
>
> Thanks. Will dig into that.
>
> Stefan

From nobody Wed Mar 16 18:04:53 2022
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 8EA541A236C4
	for ; Wed, 16 Mar 2022 18:05:03 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182])
	(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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJdTn6gb1z4mFV
	for ; Wed, 16 Mar 2022 18:05:01 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from smtpclient.apple (87-95-51-103.bb.dnainternet.fi [87.95.51.103])
	(authenticated bits=0)
	by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 22GI4xrf057802
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Wed, 16 Mar 2022 18:05:00 GMT
	(envelope-from sparvu@kronometrix.org)
X-Authentication-Warning: mail.kronometrix.org: Host 87-95-51-103.bb.dnainternet.fi [87.95.51.103] claimed to be smtpclient.apple
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 15.0 \(3693.60.0.1.1\))
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
From: Stefan Parvu 
In-Reply-To: 
Date: Wed, 16 Mar 2022 20:04:53 +0200
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CCFB32A-A98E-4E8C-A0A4-E1ADFAA3C8B9@kronometrix.org>
References: 
 <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
 
 
To: Matthew Grooms 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KJdTn6gb1z4mFV
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 MIME_GOOD(-0.10)[text/plain];
	 HAS_XAW(0.00)[];
	 DMARC_NA(0.00)[kronometrix.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1642
Lines: 43

> Interesting. If you're building the kernel from scratch, deleting the =
entire contents of MAKEOBJDIRPREFIX directory before a rebuilding helped =
at one point. Also, maybe try copying in the latest pkg firmware and =
rpi4 u-boot versions. Here's what I do after mounting the sd card to =
/mnt ...

Right. Probable I wont try to rebuild the kernel on this. But I must try =
to copy latest
pkg firmware and rpi4 uboot pkg. Any ideas where should I get these from =
?=20

Then I should probable do the below !?

>=20
> u-boot-rpi4-2021.07_1:
>=20
> cp /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin =
/mnt/boot/msdos/u-boot.bin
>=20
> rpi-firmware-1.20210303.g20210303:
>=20
> cp /usr/local/share/rpi-firmware/armstub8-gic.bin /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/armstub8.bin /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/bcm2710-rpi-2-b.dtb /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/bcm2710-rpi-3-b-plus.dtb =
/mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/bcm2710-rpi-3-b.dtb /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/bcm2711-rpi-4-b.dtb /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/bootcode.bin /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/fixup* /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/start* /mnt/boot/msdos/
> cp /usr/local/share/rpi-firmware/overlays/disable-bt.dtbo =
/mnt/boot/msdos/overlays/
> cp /usr/local/share/rpi-firmware/overlays/mmc.dtbo =
/mnt/boot/msdos/overlays/
> cp /usr/local/share/rpi-firmware/overlays/pwm.dtbo =
/mnt/boot/msdos/overlays/
> cp /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin =
/mnt/boot/msdos/u-boot.bin
>=20

Stefan


From nobody Wed Mar 16 18:49:51 2022
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 CA0F01A2F162
	for ; Wed, 16 Mar 2022 18:49:59 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJfTf60kbz4tpZ
	for ; Wed, 16 Mar 2022 18:49:58 +0000 (UTC)
	(envelope-from mgrooms@shrew.net)
Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20])
	by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 22GInvPX008774
	for ; Wed, 16 Mar 2022 13:49:57 -0500 (CDT)
	(envelope-from mgrooms@shrew.net)
Received: from [10.16.32.30] (65-36-5-114.static.grandenetworks.net [65.36.5.114])
	by mail.shrew.net (Postfix) with ESMTPSA id 9297119A7B0
	for ; Wed, 16 Mar 2022 13:49:52 -0500 (CDT)
Message-ID: 
Date: Wed, 16 Mar 2022 13:49:51 -0500
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
 
 
 <4CCFB32A-A98E-4E8C-A0A4-E1ADFAA3C8B9@kronometrix.org>
From: Matthew Grooms 
In-Reply-To: <4CCFB32A-A98E-4E8C-A0A4-E1ADFAA3C8B9@kronometrix.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Wed, 16 Mar 2022 13:49:57 -0500 (CDT)
X-Rspamd-Queue-Id: 4KJfTf60kbz4tpZ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net
X-Spamd-Result: default: False [-2.81 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.51)[-0.510];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DMARC_NA(0.00)[shrew.net];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 605
Lines: 13

On 3/16/2022 1:04 PM, Stefan Parvu wrote:

>> Interesting. If you're building the kernel from scratch, deleting the entire contents of MAKEOBJDIRPREFIX directory before a rebuilding helped at one point. Also, maybe try copying in the latest pkg firmware and rpi4 u-boot versions. Here's what I do after mounting the sd card to /mnt ...
> Right. Probable I wont try to rebuild the kernel on this. But I must try to copy latest
> pkg firmware and rpi4 uboot pkg. Any ideas where should I get these from ?
>
> Then I should probable do the below !?

pkg search u-boot-rpi4
pkg search rpi-firmware

-Matthew


From nobody Thu Mar 17 05:17:21 2022
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 6C9D61A2195A
	for ; Thu, 17 Mar 2022 05:17:32 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182])
	(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 "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KJwPl2ChXz4kMv
	for ; Thu, 17 Mar 2022 05:17:31 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from smtpclient.apple (87-95-51-103.bb.dnainternet.fi [87.95.51.103])
	(authenticated bits=0)
	by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 22H5HQek017275
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Thu, 17 Mar 2022 05:17:28 GMT
	(envelope-from sparvu@kronometrix.org)
X-Authentication-Warning: mail.kronometrix.org: Host 87-95-51-103.bb.dnainternet.fi [87.95.51.103] claimed to be smtpclient.apple
From: Stefan Parvu 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D6666B90-DFC1-486D-BF6A-ACEF372C4B60"
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 15.0 \(3693.60.0.1.1\))
Subject: Re: RBPI4B+ 2GB using FreeBSD 13.1 RC1
Date: Thu, 17 Mar 2022 07:17:21 +0200
In-Reply-To: 
Cc: freebsd-arm@freebsd.org
To: Matthew Grooms 
References: 
 <15ec886b-b45a-29ad-ddd5-a272306adee7@shrew.net>
 
 
 <4CCFB32A-A98E-4E8C-A0A4-E1ADFAA3C8B9@kronometrix.org>
 
X-Mailer: Apple Mail (2.3693.60.0.1.1)
X-Rspamd-Queue-Id: 4KJwPl2ChXz4kMv
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org
X-Spamd-Result: default: False [-2.66 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 HAS_XAW(0.00)[];
	 DMARC_NA(0.00)[kronometrix.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.86)[-0.862];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2756
Lines: 54


--Apple-Mail=_D6666B90-DFC1-486D-BF6A-ACEF372C4B60
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

> 
> pkg search u-boot-rpi4
> pkg search rpi-firmware

cheers. Will try to do that. 

Stefan
--Apple-Mail=_D6666B90-DFC1-486D-BF6A-ACEF372C4B60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



pkg search =
u-boot-rpi4
pkg search =
rpi-firmware

cheers. Will try to do that. 

Stefan
=

--Apple-Mail=_D6666B90-DFC1-486D-BF6A-ACEF372C4B60--

From nobody Thu Mar 17 13:54:47 2022
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 D5E101A14DB1
	for ; Thu, 17 Mar 2022 13:54:58 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.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 4KK7tp0tLgz594d
	for ; Thu, 17 Mar 2022 13:54:58 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x529.google.com with SMTP id x34so5493369ede.8
        for ; Thu, 17 Mar 2022 06:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=2sOT0XrzGGPhPNLDmuvIdmZD55wUfn7cfQn3aTQ9i6M=;
        b=Yl/CYDVLYJCDUKgCdN8FL9Ei1sDSLWA2hCEBpLgfP+algFcniuv1obthgFn5jG235o
         jzsmo7dRzblNMEgtV3FRo8G3zIpRMNm5lBnhPQucXB+Wq4uJXJJhPqDMg5zN3kMnoFN0
         dGYDnCGuRwOLdTkb8E7oxazfR6LpMIuNsPw1Rrul0ur4nr9fthMDja/Tv5m5e2FMXjCs
         qmoZX+ghtL91f6hRaQACbsmNUxBexsWYl6p31oczEcej5hsyYbWWPAAdtwmgsEIzdwBl
         vc6QUSVJirs0g/FA06qJvMI2fz5AWBiA+MY+EaAw2dXRcEf6vt9k70rzzTTGYV99GNNt
         xJew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=2sOT0XrzGGPhPNLDmuvIdmZD55wUfn7cfQn3aTQ9i6M=;
        b=XVdk+NdGnRAAjfooMlfomxiq0x3eVX7ff/73tBZQ0kZfMObc/aV87ND4Qk6wW4cW65
         vajkD6wI/iM3WlKFBk31LvRW5AMhmsYr2W5yNfD7mq5wS6f3XGKagKLrWp+StAMLlWFA
         X8W7limFgtrc6KSOnqGNAFWipTxnRHWnqQuFTo59WAZ2Kuu6XEIMQVNkbHNdb7p0zzHj
         Hom7gA6FjsAnHmPzb+tgOJ8knrqGFHzhoydwSBbHM14+/lHPcu0sBQ/+FwDPDb94n5P7
         mJjVRoNBxl8BQkbecFd96+WIuM9Epa9PvpbjROxZevLuouYNTIS2jrXefAF/qpV3HdgR
         TDiw==
X-Gm-Message-State: AOAM530U8b5VIOYJCW5OhVcCfDYVvdDnon92j6KAP+AXo+YeKTyDjl2Q
	4wmVk60dlyLmY0lw6/TuX9gZsTYUOdsGOcn/lVw=
X-Google-Smtp-Source: ABdhPJy1SKciZ4KeTEIO9Rg57LMUHZp0fdJe6MU1iK/XH1uTXkMXPMpBt5tDrbEfg9cJRK+jooQof9OWHpJOYvBckas=
X-Received: by 2002:a05:6402:35c7:b0:418:6577:9eb0 with SMTP id
 z7-20020a05640235c700b0041865779eb0mr4408019edc.343.1647525296984; Thu, 17
 Mar 2022 06:54: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: 
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
 
 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Thu, 17 Mar 2022 21:54:47 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000015d75c05da6a6083"
X-Rspamd-Queue-Id: 4KK7tp0tLgz594d
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="Yl/CYDVL";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4665
Lines: 99

--00000000000015d75c05da6a6083
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 16, 2022 at 10:17 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Wed, Mar 16, 2022 at 9:31 PM Hans Petter Selasky 
> wrote:
>
>> Hi Archimedes,
>>
>> I don't see any issue in there. There should be a print containing ERROR .
>>
>> Did you set the DWC OTG debug level to 17 ?
>>
>
>
> Hi Hans,
>
> I tried that with debug level 17 on DWC OTG but my keyboard seems not
> responsive even when I unplug and re-plugged the keyboard. That's why I
> just stay to level 1. Let me try this time, I have an idea, I'll put this
> printing script in cron and run it there and then have the debug level at
> 17. Let's see how it goes.
>
> Thanks,
> Archimedes
>


Hi Hans,

The cron idea works and printing is now automated with DWC OTG in debug
level 17. With this debug level 17 enabled, my keyboard gets unresponsive
for some period of time but still you can type. It just takes time to
respond but not totally unresponsive. Anyway, nothing to worry now as
automation is in place. As of this moment, still no error is encountered,
very intermittent. So, until its presence.

By the way, I have another observation. Since this printing investigation,
the USB's physical port assignments of my Epson printer and my USB keyboard
haven't changed. My keyboard is detected and assigned as a ugen1.5 device
on usbus1 while my printer is assigned as ugen1.4 on usbus1 as well.
Sometimes I turned off this printer and after several hours turned it back
on, the usbus1 assignment of the printer changed to ugen1.5 device. Though
not all the time, I noticed this twice already. Is this an expected
behavior?

Thanks,
Archimedes

--00000000000015d75c05da6a6083
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Mar 16, 2022 at 10:17 PM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:


On Wed, Mar 16, 2=
022 at 9:31 PM Hans Petter Selasky <hps@selasky.org> wrote:
Hi Archimedes,



I don't see any issue in there. There should be a print containing ERRO=
R .



Did you set the DWC OTG debug level to 17 ?

=

Hi Hans,

I tried that with debug level 17 on=
 DWC OTG but my keyboard seems not responsive even when I unplug and re-plu=
gged the keyboard. That's why I just stay to level 1. Let me try this t=
ime, I have an idea, I'll put this printing script in cron and run it t=
here and then have the debug level at 17. Let's see how it goes.

Thanks,<=
/div>
Archimedes


Hi Hans,

The cron idea works and printing is now automated with DWC OTG in debug le=
vel 17. With this debug level 17 enabled, my keyboard gets unresponsive for=
 some period of time but still you can type. It just takes time to respond =
but not totally unresponsive. Anyway, nothing to worry now as automation is=
 in place. As of this moment, still no error is encountered, very intermitt=
ent. So, until its presence.

By the way, I hav=
e another observation. Since this printing investigation, the USB's phy=
sical port assignments of my Epson printer and my USB keyboard haven't =
changed. My keyboard is detected and assigned as a ugen1.5 device on usbus1=
 while my printer is assigned as ugen1.4 on usbus1 as well. Sometimes I tur=
ned off this printer and after several hours turned it back on, the usbus1 =
assignment of the printer changed to ugen1.5 device. Though not all the tim=
e, I noticed this twice already. Is this an expected behavior?

Thanks,
Archimedes 
=C2=A0


--00000000000015d75c05da6a6083--

From nobody Thu Mar 17 14:32:00 2022
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 AC2E21A1EA48
	for ; Thu, 17 Mar 2022 14:32:15 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KK8jp4BYdz3JmS
	for ; Thu, 17 Mar 2022 14:32:14 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 582D42616A8;
	Thu, 17 Mar 2022 15:32:13 +0100 (CET)
Message-ID: <5afb1138-b9db-3549-1220-e332a0f68815@selasky.org>
Date: Thu, 17 Mar 2022 15:32:00 +0100
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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 
 
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org>
 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org>
 
 
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KK8jp4BYdz3JmS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 178
Lines: 8

On 3/17/22 14:54, Archimedes Gaviola wrote:
> Is this an expected
> behavior?

Yes, you shouldn't rely on the ugen numbering. It depends on the actual 
enumeration order.

--HPS

From nobody Thu Mar 17 14:35:24 2022
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 E6C471A20859
	for ; Thu, 17 Mar 2022 14:35:35 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4KK8ng1TmSz3LGc
	for ; Thu, 17 Mar 2022 14:35:35 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x634.google.com with SMTP id yy13so11177609ejb.2
        for ; Thu, 17 Mar 2022 07:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=pcuXI6bmROtIuHLT1m4PUVPIMvqaQNw6CM2nXEutbuI=;
        b=D54QXcIP503QWe4cPCPSppE5+cisfw7HrxM2NhFBEUV6TSnAtTIXpyZbCmwnI6l5qv
         ZBVPirRnJj41LImGUBKzZlayOwfMG2hUdwVKfSo0hNdTCeGhN8ZLomneiDwY0irX/qRN
         e8Q+iOFxKYXfGdJgBk38ZD7F8qI2oE6x0tvR2rdaZtZFa7KS1Zvo/ykZtllU0wZom2NM
         P4dguASVRNKvo4+ir8ncnf7T7R2hYhSL+JewsKyNGyYUSIHJQHT0XJSkpJRZzq64ybYx
         6QPFwpH3lkMrx8kKv/15M1xOkV9uoSVqqbCD+iH46HH3JLZMyhDTKaXt0BX/rKeuN6Gu
         84eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=pcuXI6bmROtIuHLT1m4PUVPIMvqaQNw6CM2nXEutbuI=;
        b=5oWicDnljdaD9JfvvoPEPoVCGj2gfNVJ2UwWWu75v/+YahNWlrxNb0eDW7q5rCJyB3
         xqyYiEfwu5ZARkAmuB0x4kpIUR2iwtBEZoqeRDlkpZhzNBc/tWYt4DZUAbehZyT1w4XV
         lFvx67n0nptDJekyNUV/zsrkioRoJurjy2iAmBlebtwroflqOaQXNshxzvtlqJ2F/S5P
         cuXTmG3hnk64guEIw/8qBh+EMuGwGDLXqSBHkjyaYnlHRzTUiisVwMvjHJcBIXItSbNW
         0BTMzCu82KzY7dOkD2yzz+6e7dtMVNiYg7qYMOp30stR1qeK9tVY3+FFEF8r0jhrBB1z
         tVkA==
X-Gm-Message-State: AOAM533YBz1efPs23dlxoKJkcnHyVdz9dRCa4Hm9/sIOXoy/YOq4gIkh
	5SRDl0dS+v/wLgetYUWVIzB6167oPOnRZGoWxys=
X-Google-Smtp-Source: ABdhPJyB89vzCdd9RXX5gC8gPn9ZUqIYy4nR+H7tNpbUpS0ZKQphk6d2gPlv41znDeafi2q+T2kEYRYSlfCXlJaY+Rw=
X-Received: by 2002:a17:907:eac:b0:6db:799c:cb3c with SMTP id
 ho44-20020a1709070eac00b006db799ccb3cmr4840979ejc.559.1647527734147; Thu, 17
 Mar 2022 07:35:34 -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: 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
 
 
  
  <5afb1138-b9db-3549-1220-e332a0f68815@selasky.org>
In-Reply-To: <5afb1138-b9db-3549-1220-e332a0f68815@selasky.org>
From: Archimedes Gaviola 
Date: Thu, 17 Mar 2022 22:35:24 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000005a01c605da6af14c"
X-Rspamd-Queue-Id: 4KK8ng1TmSz3LGc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=D54QXcIP;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1304
Lines: 36

--0000000000005a01c605da6af14c
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 17, 2022 at 10:32 PM Hans Petter Selasky 
wrote:

> On 3/17/22 14:54, Archimedes Gaviola wrote:
> > Is this an expected
> > behavior?
>
> Yes, you shouldn't rely on the ugen numbering. It depends on the actual
> enumeration order.
>

Alright, this is noted. Thank you Hans!

--0000000000005a01c605da6af14c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 17, 2022 at 10:32 PM Hans=
 Petter Selasky <hps@selasky.org&=
gt; wrote:
On 3/=
17/22 14:54, Archimedes Gaviola wrote:

> Is this an expected

> behavior?



Yes, you shouldn't rely on the ugen numbering. It depends on the actual=
 

enumeration order.

Alright, this is not=
ed. Thank you Hans! 





--0000000000005a01c605da6af14c--

From nobody Sat Mar 19 01:42:48 2022
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 F18761A13472
	for ; Sat, 19 Mar 2022 01:42:52 +0000 (UTC)
	(envelope-from matteo@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 4KL3Y85vXNz3j5l
	for ; Sat, 19 Mar 2022 01:42:52 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1647654172;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=ByWmVameI0+pszTaSvFBfqV2hCq0IjFTBkx5o79F3nQ=;
	b=sema8xk4TqgdEWlv0GGiVmIXtne9FSTVgwba+G8TCGz3gxSqVu/A7wYL5TjMKtEI6XgAPd
	P8bM9BvqPvK4Zt2mV+8Fvrt7z3hKUuEOoK5NGbyKgOe7Txwq+2BucNHd27l/r9DSY6qec7
	xNG1I/JwRxSEcW/+jtRqipGgi1lBJHEfn8Ma8rBv4wfO/xY5NNt/d30VO9o7J3y5Yzzpri
	8RttGo+sDEp4EFJQPcrHfhIfISwK7VbCfzahvbXRULxKerqs8ZgVv5XqWYUim+mXyRbc8S
	Jv7RrjXThg/8HDjalWqw9IvhldV3n/usV/1I6HtwI1rFH8qquItoGr4jI1qK6A==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::1000])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 8EE8F2B472
	for ; Sat, 19 Mar 2022 01:42:52 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Fri, 18 Mar 2022 21:42:48 -0400
From: Matteo Riondato 
To: freebsd-arm@freebsd.org
Subject: [armv7] 13.1-BETA1-GENERICSD panic at boot on beaglebone enhanced
Message-ID: <20220319014248.6frp3ses7z2ouwus@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="433u6wgp6nqj3wng"
Content-Disposition: inline
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647654172;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=ByWmVameI0+pszTaSvFBfqV2hCq0IjFTBkx5o79F3nQ=;
	b=Rg7n1xClDlBQtAQrcIxS5DQl8CHQks8uo2XyMDNTrXUP0zz4NtgSfm+PqIVogL+QXHT91M
	XamXc/DutL3Ba4XxIDiSU6bhfQFiIMzsxjhH651sMSXDTe7TyFeBlyNgk1sckuy1+ZH4IT
	b8zLvbmev9PrjZZNkDxMuJwwcE6tm0/LmHpPtslSmtctqEbIxYc/n1P2Ypj9P7a5tr7XlT
	d2ZycBVEHe9OwyqW5DNd4FoehKfInVaz8KyHEfz3XtWOu9XWyYDDErYMDvPqELwPQYKxsa
	4jVjhlE0JfiK8Saju4jAnKkhdxqkW+HYFj7Bv+BzZugTipaI/D53sWWW1fkDHw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647654172; a=rsa-sha256; cv=none;
	b=gsGpL/r2dD8YX4gY1xT2/w32fwGl1KJVIGWxhWfhUjXbV54HEZFKq9OPc8s1WYvzasI6yD
	5Fg5F1Yjh2rck2lhj4LZu5z+V/SeWYE2cgCOLqukfmvQD3CYQorK6XX0QYUIAA/5RHLrry
	wY/88wCAOmrpcapVMVsOnoaWj2NnFNNBUVAy+LtavsnWcZL/KKkOVlbJyD3kX4vJwabuCw
	63oFTWxFYbfiOaNbNVxusR7J2DvExvuxnkaFKdwUXjj82Emy2YqCOVY3kwolYAKH1icXtz
	w0fx6vhb+OW4XW1dy5Zsvn8nmfUW30afQlsV9691uAwjNDX1hoZLE9ST9kOJKw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2905
Lines: 78


--433u6wgp6nqj3wng
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

I'm getting the following panic at boot when trying to boot up the=20
13.1-BETA1-arm-armv7-GENERICSD (from the FTP) image on a beaglebone=20
enhanced (https://beagleboard.org/enhanced), which is "essentially" a=20
beaglebone black (although I do understand that even minor variations=20
may have a big effect on SoC): b

Fatal kernel mode data abort: 'Translation Fault (L1)' on read
trapframe: 0xc0e14c98
FSR=3D00000005, FAR=3D6578696e, spsr=3D20000093
r0 =3Dd6837680, r1 =3D65786966, r2 =3Dd6925d50, r3 =3Dc08cf75c
r4 =3Dd690faa4, r5 =3D00000001, r6 =3D00000000, r7 =3D00000006
r8 =3Dd690fa80, r9 =3Dd684ba00, r10=3Dd690fa80, r11=3Dc0e14d30
r12=3D00020000, ssp=3Dc0e14d28, slr=3Dc06db204, pc =3Dc06db210

panic: Fatal abort
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xc035561c at kdb_backtrace+0x48
#1 0xc02fc7ac at vpanic+0x170
#2 0xc02fc63c at vpanic+0
#3 0xc061aa94 at abort_align+0
#4 0xc061a584 at abort_handler+0x2a0
#5 0xc05f9b2c at exception_exit+0
#6 0xc06db210 at ti_sysc_clock_enable+0x18
#7 0xc06d7dfc at ti_i2c_attach+0xd8
#8 0xc0342184 at device_attach+0x4f4
#9 0xc03442c4 at bus_generic_new_pass+0x134
#10 0xc034424c at bus_generic_new_pass+0xbc
#11 0xc034424c at bus_generic_new_pass+0xbc
#12 0xc034424c at bus_generic_new_pass+0xbc
#13 0xc0346108 at root_bus_configure+0x48
#14 0xc027c644 at mi_startup+0x134
#15 0xc0000344 at _start+0x144

boot -v messages up until the panic are available at=20
http://rionda.to/files/beagleboneenhanced-FBSD131BETA1-bootverbose.log=20
):

This is the first time that I trying booting up FreeBSD on this board,=20
so I don't know whether I need to do anything special.

Tomorrow I'll try to compile a -CURRENT image and boot it up, but if=20
anyone has an idea of what is going on, please let me know.

Thanks,
Matteo

--433u6wgp6nqj3wng
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmI1NRATGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAehMD/9diyhya1wnz8xCbYt9utPFhaq85hY4
+r/77QHFNwudg6DwwPp9wRyJ26j7j/fKkJeAbgYN6UyxfbNVvKUH25vaS+0m39dY
UIjw1p1EKDBYaCf5GNBG33E2doh3VZ6zy56OkNHAglUsBM7fxghHef4GYZdiVEs7
1DxfswugBOeF+7ywbdgdvAZyxf5kAc2Bi+FawzTWv7id2cjJVHrisVYtcObwCvqK
vsz5OWUEAWE7No7GUOS0I3T0PO3tJfIndB7ZExuZc/rPbb7LLS6TmXnHUbXayx0U
HSkbP1owuC5CoMtLj3BiAPaPmTgy+fO0pqwkrw0+3RruhCyUAJIGqPMq+z8HLhsD
E1IvoFusRFJBFnrxDfeHxnHVlqSSquQHGutEk8M2k5dkCDKtkMGWfQXfS/cB7fRt
gfz65+rr0Kh114Ck0KuMC+CyuSOoafkXPxU8FNGk5SNW6bMj9KwzNZ+uXEsI6ayc
dAYz1DHUDXi0Au2Y30kduF9iXjtaNnYC+FGLK36ZWoz/5/8Iov2cWIRrAvf9Z7aU
I31Feqn+UEKeLebxSyh6zjMT8emZrfXqoRFmhtv5vMS3j6GGNc9ZkrWGEKhHnmDA
zFPy3AI1QkTrUgb/gZFhLy4Pwc4M8pj89XAUq525O2HHwBoQgNf2Y0WKrCWn59Sd
wmtsoCgnF/3NlA==
=Wvfc
-----END PGP SIGNATURE-----

--433u6wgp6nqj3wng--

From nobody Sun Mar 20 12:02:22 2022
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 02ADA1A36FFA
	for ; Sun, 20 Mar 2022 12:02:52 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4KLxG30dNyz4Vcf
	for ; Sun, 20 Mar 2022 12:02:51 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62f.google.com with SMTP id dr20so24651502ejc.6
        for ; Sun, 20 Mar 2022 05:02:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Kt31ZUxvMeoyu9hMr5Rih/FehUEIC3rxGGz5xxFTF/Y=;
        b=VIFhR46wqyTPtEFA3XU3qgd6IPd17ZxGZBnuHz9oyphb6HtojvkCA7JC3K3ZS5vnYn
         q8Pm3Zi30Q9eJ/q20Tme7uTFk++f5zxppNs8XPgXUd9DUplHbwNmUnh/HXLRBjVTmigS
         l4gFHJETHwqsiiOoWLVv4xkyfc0uMwe6nBuuzRN+aX2s7mAx0UpIfs55ZUNjgmf0hKzN
         F9hRtJSYkBsHWSw3S0C38/P3wC5WJC+2boBeXjPPtDN5FF91+72dFw71W2Un9u7K/TGT
         3Gaxnx2EzlyWo9DSjt0V34b33wlEQXLtsUHXEFHRbXJqXE/GPH88Tz/zMOVj1sUWSnsh
         rihg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Kt31ZUxvMeoyu9hMr5Rih/FehUEIC3rxGGz5xxFTF/Y=;
        b=uSJeUvtchA+MODDLQJqfYFwbnwbd3P4PDKMAg0KeaQB80WnJEsTLzKhR177nYWUdUV
         RFMxhrj5URlo/BsavadEVYztR2jxnigKL39RDnSuzb+ObkHDcHZUITVjq5jdXygLbyvC
         wtPg7TcpKEgjQCIoWenYXIVg3X7AWgl7fdhR2YHv6f75GZYD1aExjIU3qhh/L7TwhxrL
         KCosEjTKFZg3NGnP1EqqvAu7T70BlBchyWGTHOwUpmgT/JbNNpLSj0jgFs888XAWTmUe
         YVURdIY7cP5wsmampP5su3GnvL/FEJt7f7W1KNXNhnjz26FToxCX8bfZU4E8Guz2cX0W
         Jl3A==
X-Gm-Message-State: AOAM532OmCLPU0PSxqOT+C1dgfTofZ6E+dijBH6b3yMHX+M8BxA5wPMs
	uVmyxrUWXB+DcFf15ZFgF4u/IipK0tjzhx5qbIdhoL7gOYw=
X-Google-Smtp-Source: ABdhPJwqpyyOS5QEZQ+JlapmlumDXCNLhkJ47dFDRobE0dCL49/FDwKbsWvdwZVmyk9jQqMRsuS7QCLXYYICE5ZiMes=
X-Received: by 2002:a17:906:7302:b0:6df:8c05:60c6 with SMTP id
 di2-20020a170906730200b006df8c0560c6mr15667335ejc.370.1647777769337; Sun, 20
 Mar 2022 05:02:49 -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: 
  
 
 
 <7a77e3bd-1186-56a6-e60e-89e51c190a01@selasky.org> 
 
 <87a3da15-d83d-c864-bdb7-6035db5cd70d@selasky.org> 
 
 
  
 
 <5afb1138-b9db-3549-1220-e332a0f68815@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sun, 20 Mar 2022 20:02:22 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000009c35fa05daa52853"
X-Rspamd-Queue-Id: 4KLxG30dNyz4Vcf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=VIFhR46w;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.50)[-0.497];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10979
Lines: 213

--0000000000009c35fa05daa52853
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 17, 2022 at 10:35 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Thu, Mar 17, 2022 at 10:32 PM Hans Petter Selasky 
> wrote:
>
>> On 3/17/22 14:54, Archimedes Gaviola wrote:
>> > Is this an expected
>> > behavior?
>>
>> Yes, you shouldn't rely on the ugen numbering. It depends on the actual
>> enumeration order.
>>
>
> Alright, this is noted. Thank you Hans!
>


Hi Hans,

For how many days I've been doing the automated printing the issue never
occurred with DWC OTG debug level 17 but still for sure the issue is
observed when debug is bypassed or disabled . That's why it's quite a
challenge for me to capture. Not sure why this debug level 17 issue never
appeared. Any ideas?

Meanwhile, I've tried enabling 'sysctl hw.usb.ugen.debug=17' and this is
what I've got. Not sure if this is helpful to you for any clue. When
exactly the printing issue occurred this is what happened as found in the
logs -> ugen_write_clear_stall_callback: f=0xffffa00016208d80: stall
cleared. Below is the complete /var/log/messages (appeared twice) and the
c-file-to-printer is my little printing program invoked.

Mar 20 14:39:04 generic kernel: ugen_open: flag=0x402 pid=1337
name=c-file-to-printer
Mar 20 14:39:04 generic kernel: ugen_ioctl: cmd=0x402c7413
Mar 20 14:39:04 generic kernel: ugen_ioctl: error=-3
Mar 20 14:39:04 generic kernel: ugen_ioctl_post: cmd=0x402c7413
Mar 20 14:39:04 generic kernel: ugen_ioctl_post: error=-3
Mar 20 14:39:04 generic kernel: ugen_ctrl_write_callback: actlen=0,
aframes=0
Mar 20 14:39:04 generic kernel: ugen_ctrl_write_callback: actlen=697,
aframes=1
Mar 20 14:39:04 generic kernel: ugen_close: flag=0x402 pid=1337
name=c-file-to-printer
Mar 20 14:39:04 generic kernel: ugen_close: no FIFOs
Mar 20 14:39:10 generic kernel: ugen_open: flag=0x402 pid=1338
name=c-file-to-printer
Mar 20 14:39:10 generic kernel: ugen_ioctl: cmd=0x402c7413
Mar 20 14:39:10 generic kernel: ugen_ioctl: error=-3
Mar 20 14:39:10 generic kernel: ugen_ioctl_post: cmd=0x402c7413
Mar 20 14:39:10 generic kernel: ugen_ioctl_post: error=-3
Mar 20 14:39:10 generic kernel: ugen_ctrl_write_callback: actlen=0,
aframes=0
Mar 20 14:39:10 generic kernel: ugen_ctrl_write_callback: actlen=697,
aframes=1
Mar 20 14:39:10 generic kernel: ugen_close: flag=0x402 pid=1338
name=c-file-to-printer
Mar 20 14:39:10 generic kernel: ugen_close: no FIFOs
Mar 20 14:39:15 generic kernel: ugen_open: flag=0x402 pid=1339
name=c-file-to-printer
Mar 20 14:39:15 generic kernel: ugen_ioctl: cmd=0x402c7413
Mar 20 14:39:15 generic kernel: ugen_ioctl: error=-3
Mar 20 14:39:15 generic kernel: ugen_ioctl_post: cmd=0x402c7413
Mar 20 14:39:15 generic kernel: ugen_ioctl_post: error=-3
Mar 20 14:39:15 generic kernel: ugen_ctrl_write_callback: actlen=0,
aframes=0
Mar 20 14:39:15 generic kernel: ugen_ctrl_write_callback: actlen=56,
aframes=1
Mar 20 14:39:15 generic kernel: ugen_write_clear_stall_callback:
f=0xffffa00016208d80: stall cleared
Mar 20 14:39:15 generic kernel: ugen_ctrl_write_callback: actlen=56,
aframes=1
Mar 20 14:39:15 generic kernel: ugen_close: flag=0x402 pid=1339
name=c-file-to-printer
Mar 20 14:39:15 generic kernel: ugen_close: no FIFOs
Mar 20 14:39:49 generic login[1169]: ROOT LOGIN (root) ON ttyv3
Mar 20 14:40:40 generic kernel: ugen_open: flag=0x402 pid=1346
name=c-file-to-printer
Mar 20 14:40:40 generic kernel: ugen_ioctl: cmd=0x402c7413
Mar 20 14:40:40 generic kernel: ugen_ioctl: error=-3
Mar 20 14:40:40 generic kernel: ugen_ioctl_post: cmd=0x402c7413
Mar 20 14:40:40 generic kernel: ugen_ioctl_post: error=-3
Mar 20 14:40:40 generic kernel: ugen_ctrl_write_callback: actlen=0,
aframes=0
Mar 20 14:40:40 generic kernel: ugen_ctrl_write_callback: actlen=72,
aframes=1
Mar 20 14:40:40 generic kernel: ugen_write_clear_stall_callback:
f=0xffffa00016208d80: stall cleared
Mar 20 14:40:40 generic kernel: ugen_ctrl_write_callback: actlen=72,
aframes=1
Mar 20 14:40:40 generic kernel: ugen_close: flag=0x402 pid=1346
name=c-file-to-printer
Mar 20 14:40:40 generic kernel: ugen_close: no FIFOs
Mar 20 14:40:51 generic kernel: ugen_open: flag=0x402 pid=1347
name=c-file-to-printer
Mar 20 14:40:51 generic kernel: ugen_ioctl: cmd=0x402c7413
Mar 20 14:40:51 generic kernel: ugen_ioctl: error=-3
Mar 20 14:40:51 generic kernel: ugen_ioctl_post: cmd=0x402c7413
Mar 20 14:40:51 generic kernel: ugen_ioctl_post: error=-3
Mar 20 14:40:51 generic kernel: ugen_ctrl_write_callback: actlen=0,
aframes=0
Mar 20 14:40:51 generic kernel: ugen_ctrl_write_callback: actlen=697,
aframes=1
Mar 20 14:40:51 generic kernel: ugen_close: flag=0x402 pid=1347
name=c-file-to-printer
Mar 20 14:40:51 generic kernel: ugen_close: no FIFOs

Thanks,
Archimedes

--0000000000009c35fa05daa52853
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 17, 2022 at 10:35 PM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:


On Thu, Mar 17, 2=
022 at 10:32 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/17/22 14:54, Archimedes Gaviola wrote=
:

> Is this an expected

> behavior?



Yes, you shouldn't rely on the ugen numbering. It depends on the actual=
 

enumeration order.

Alright, this is not=
ed. Thank you Hans!


<=
/div>
Hi Hans,

For how many days I've been=
 doing the automated printing the issue never occurred with DWC OTG debug l=
evel 17 but still for sure the issue is observed when debug is bypassed or =
disabled . That's why it's quite a challenge for me to capture. Not=
 sure why this debug level 17 issue never appeared. Any ideas?

Meanwhile, I've tried enabling 'sysctl hw.usb.ugen=
.debug=3D17' and this is what I've got. Not sure if this is helpful=
 to you for any clue. When exactly the printing issue occurred this is what=
 happened as found in the logs -> ugen_write_clear_stall_callback: f=3D0=
xffffa00016208d80: stall cleared. Below is the complete /var/log/messages (=
appeared twice)=20

 and the
c-file-to-printer is my little printing program invoked.







Mar 20 14:39:04 generic kernel: ugen_open: flag=
=3D0x402 pid=3D1337 name=3Dc-file-to-printer
Mar 20 14:39:04 generic ker=
nel: ugen_ioctl: cmd=3D0x402c7413
Mar 20 14:39:04 generic kernel: ugen_i=
octl: error=3D-3
Mar 20 14:39:04 generic kernel: ugen_ioctl_post: cmd=3D=
0x402c7413
Mar 20 14:39:04 generic kernel: ugen_ioctl_post: error=3D-3Mar 20 14:39:04 generic kernel: ugen_ctrl_write_callback: actlen=3D0, afr=
ames=3D0
Mar 20 14:39:04 generic kernel: ugen_ctrl_write_callback: actle=
n=3D697, aframes=3D1
Mar 20 14:39:04 generic kernel: ugen_close: flag=3D=
0x402 pid=3D1337 name=3Dc-file-to-printer
Mar 20 14:39:04 generic kernel=
: ugen_close: no FIFOs
Mar 20 14:39:10 generic kernel: ugen_open: flag=
=3D0x402 pid=3D1338 name=3Dc-file-to-printer
Mar 20 14:39:10 generic ker=
nel: ugen_ioctl: cmd=3D0x402c7413
Mar 20 14:39:10 generic kernel: ugen_i=
octl: error=3D-3
Mar 20 14:39:10 generic kernel: ugen_ioctl_post: cmd=3D=
0x402c7413
Mar 20 14:39:10 generic kernel: ugen_ioctl_post: error=3D-3Mar 20 14:39:10 generic kernel: ugen_ctrl_write_callback: actlen=3D0, afr=
ames=3D0
Mar 20 14:39:10 generic kernel: ugen_ctrl_write_callback: actle=
n=3D697, aframes=3D1
Mar 20 14:39:10 generic kernel: ugen_close: flag=3D=
0x402 pid=3D1338 name=3Dc-file-to-printer
Mar 20 14:39:10 generic kernel=
: ugen_close: no FIFOs
Mar 20 14:39:15 generic kernel: ugen_open: flag=
=3D0x402 pid=3D1339 name=3Dc-file-to-printer
Mar 20 14:39:15 generic ker=
nel: ugen_ioctl: cmd=3D0x402c7413
Mar 20 14:39:15 generic kernel: ugen_i=
octl: error=3D-3
Mar 20 14:39:15 generic kernel: ugen_ioctl_post: cmd=3D=
0x402c7413
Mar 20 14:39:15 generic kernel: ugen_ioctl_post: error=3D-3Mar 20 14:39:15 generic kernel: ugen_ctrl_write_callback: actlen=3D0, afr=
ames=3D0
Mar 20 14:39:15 generic kernel: ugen_ctrl_write_callback: actle=
n=3D56, aframes=3D1
Mar 20 14:39:15 generic kernel: ugen_write_clear_sta=
ll_callback: f=3D0xffffa00016208d80: stall cleared
Mar 20 14:39:15 gener=
ic kernel: ugen_ctrl_write_callback: actlen=3D56, aframes=3D1
Mar 20 14:=
39:15 generic kernel: ugen_close: flag=3D0x402 pid=3D1339 name=3Dc-file-to-=
printer
Mar 20 14:39:15 generic kernel: ugen_close: no FIFOs
Mar 20 1=
4:39:49 generic login[1169]: ROOT LOGIN (root) ON ttyv3
Mar 20 14:40:40 =
generic kernel: ugen_open: flag=3D0x402 pid=3D1346 name=3Dc-file-to-printer=

Mar 20 14:40:40 generic kernel: ugen_ioctl: cmd=3D0x402c7413
Mar 20 =
14:40:40 generic kernel: ugen_ioctl: error=3D-3
Mar 20 14:40:40 generic =
kernel: ugen_ioctl_post: cmd=3D0x402c7413
Mar 20 14:40:40 generic kernel=
: ugen_ioctl_post: error=3D-3
Mar 20 14:40:40 generic kernel: ugen_ctrl_=
write_callback: actlen=3D0, aframes=3D0
Mar 20 14:40:40 generic kernel: =
ugen_ctrl_write_callback: actlen=3D72, aframes=3D1
Mar 20 14:40:40 gener=
ic kernel: ugen_write_clear_stall_callback: f=3D0xffffa00016208d80: stall c=
leared
Mar 20 14:40:40 generic kernel: ugen_ctrl_write_callback: actlen=
=3D72, aframes=3D1
Mar 20 14:40:40 generic kernel: ugen_close: flag=3D0x=
402 pid=3D1346 name=3Dc-file-to-printer
Mar 20 14:40:40 generic kernel: =
ugen_close: no FIFOs
Mar 20 14:40:51 generic kernel: ugen_open: flag=3D0=
x402 pid=3D1347 name=3Dc-file-to-printer
Mar 20 14:40:51 generic kernel:=
 ugen_ioctl: cmd=3D0x402c7413
Mar 20 14:40:51 generic kernel: ugen_ioctl=
: error=3D-3
Mar 20 14:40:51 generic kernel: ugen_ioctl_post: cmd=3D0x40=
2c7413
Mar 20 14:40:51 generic kernel: ugen_ioctl_post: error=3D-3
Ma=
r 20 14:40:51 generic kernel: ugen_ctrl_write_callback: actlen=3D0, aframes=
=3D0
Mar 20 14:40:51 generic kernel: ugen_ctrl_write_callback: actlen=3D=
697, aframes=3D1
Mar 20 14:40:51 generic kernel: ugen_close: flag=3D0x40=
2 pid=3D1347 name=3Dc-file-to-printer
Mar 20 14:40:51 generic kernel: ug=
en_close: no FIFOs

Thanks,
Archimedes

=C2=A0



--0000000000009c35fa05daa52853--

From nobody Sun Mar 20 20:58:03 2022
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 CF2141A32757
	for ; Sun, 20 Mar 2022 20:58:03 +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 4KM97b0Kkpz3PRZ
	for ; Sun, 20 Mar 2022 20:58:03 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 D258364A6
	for ; Sun, 20 Mar 2022 20:58:02 +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 22KKw2n3005986
	for ; Sun, 20 Mar 2022 20:58:02 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22KKw2UU005985
	for freebsd-arm@FreeBSD.org; Sun, 20 Mar 2022 20:58:02 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 262691] [patch] Save only callee-saved registers in pcb
Date: Sun, 20 Mar 2022 20:58:03 +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: dpglg@icloud.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647809883;
	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=tJuBbnrWepuncwpPkUkSNdUj7NpenXhxZUHuHLnQZGI=;
	b=AvWmpaMMWSavZfuP8oFKK7o35kw3bZf5YNcsX0xHTBiMc7uAVPWa9FwBweLPBl6GWFh/hv
	ARMc8srnjXT6v9ZhdFAMiTa3feXF094GfmNo5juYWVHSk3A93APXWTokxnkJupV4a2I7Ya
	gWOtj9t9H8w4AEN6gYDtPuMW8TmpigvbGIcQgMjN19SO7CII3TIyrzRBx4lMauS0shfUKs
	FqH1BrUbmgMXCZujkEVT2YwbUHvQB4Mv790ELlquHxrnsoFg6WlKXhUYDNfQNiUzjjzoL6
	MBXgUb3Y/JIU09jBnemnPA7WYhkpshD69/NM7BuSg/3cA5QubozfrKN/eayy4Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647809883; a=rsa-sha256; cv=none;
	b=v/R59y5i/GcbYuuCENY+Mk9+4q4SlmtuqKS+CYwr/o4x0ju05zbVA7wOAaUTuU3UpIysyF
	Bsj1fqwCSdYfSjon0s6SmrtQl+zh3C86HDUqKx7FXUSGnvtchFOjC+JtvgmioLhN1+Ybnu
	2VT9aYq67w9NMl+pfgr0Mld7Dg4C94FXDdIl4sLp5mbkewC19qkGgHYbtlpVloy/g/DT7t
	N9NEKZMFcqW/VvCmzK4DRb7qBUHHCZgxb4nhszFUgp8dk4bqkxUrkdrriSAEy/BZXjlHVB
	/ouNLy1xIv3c+PcBEFkWyPAZd26D/yUy94xanzPWYF7Dth2rM5hmlo/QX7/K2w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7209
Lines: 178

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262691

            Bug ID: 262691
           Summary: [patch] Save only callee-saved registers in pcb
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: dpglg@icloud.com

On AArch64, registers x9-x18 are not callee-saved, yet they are preserved at
many placed in swtch.S. This patch removes code that preserves these regist=
ers.

It may also be worth it to remove the unused entries in the `pcb_x` field of
`struct pcb`, but this would be a more disruptive change with compatibility
concerns (e.g. `kgdb` would need to be changed to recognise the new layout =
the
struct).

--- a/sys/arm64/arm64/swtch.S
+++ b/sys/arm64/arm64/swtch.S
@@ -94,18 +94,12 @@ ENTRY(cpu_throw)
        msr     tpidr_el0, x6
        ldr     x6, [x4, #PCB_TPIDRRO]
        msr     tpidrro_el0, x6
-       ldp     x8, x9, [x4, #PCB_REGS + 8 * 8]
-       ldp     x10, x11, [x4, #PCB_REGS + 10 * 8]
-       ldp     x12, x13, [x4, #PCB_REGS + 12 * 8]
-       ldp     x14, x15, [x4, #PCB_REGS + 14 * 8]
-       ldp     x16, x17, [x4, #PCB_REGS + 16 * 8]
-       ldr          x19, [x4, #PCB_REGS + 19 * 8]
-       ldp     x20, x21, [x4, #PCB_REGS + 20 * 8]
-       ldp     x22, x23, [x4, #PCB_REGS + 22 * 8]
-       ldp     x24, x25, [x4, #PCB_REGS + 24 * 8]
-       ldp     x26, x27, [x4, #PCB_REGS + 26 * 8]
-       ldp     x28, x29, [x4, #PCB_REGS + 28 * 8]
-       ldr     lr, [x4, #PCB_LR]
+       ldp     x19, x20, [x4, #PCB_REGS + 19 * 8]
+       ldp     x21, x22, [x4, #PCB_REGS + 21 * 8]
+       ldp     x23, x24, [x4, #PCB_REGS + 23 * 8]
+       ldp     x25, x26, [x4, #PCB_REGS + 25 * 8]
+       ldp     x27, x28, [x4, #PCB_REGS + 27 * 8]
+       ldp     x29, lr, [x4, #PCB_REGS + 29 * 8]

        ret
 END(cpu_throw)
@@ -125,18 +119,12 @@ ENTRY(cpu_switch)
        ldr     x4, [x0, #TD_PCB]

        /* Store the callee-saved registers */
-       stp     x8, x9, [x4, #PCB_REGS + 8 * 8]
-       stp     x10, x11, [x4, #PCB_REGS + 10 * 8]
-       stp     x12, x13, [x4, #PCB_REGS + 12 * 8]
-       stp     x14, x15, [x4, #PCB_REGS + 14 * 8]
-       stp     x16, x17, [x4, #PCB_REGS + 16 * 8]
-       stp     x18, x19, [x4, #PCB_REGS + 18 * 8]
-       stp     x20, x21, [x4, #PCB_REGS + 20 * 8]
-       stp     x22, x23, [x4, #PCB_REGS + 22 * 8]
-       stp     x24, x25, [x4, #PCB_REGS + 24 * 8]
-       stp     x26, x27, [x4, #PCB_REGS + 26 * 8]
-       stp     x28, x29, [x4, #PCB_REGS + 28 * 8]
-       str     lr, [x4, #PCB_LR]
+       stp     x19, x20, [x4, #PCB_REGS + 19 * 8]
+       stp     x21, x22, [x4, #PCB_REGS + 21 * 8]
+       stp     x23, x24, [x4, #PCB_REGS + 23 * 8]
+       stp     x25, x26, [x4, #PCB_REGS + 25 * 8]
+       stp     x27, x28, [x4, #PCB_REGS + 27 * 8]
+       stp     x29, lr, [x4, #PCB_REGS + 29 * 8]
        /* And the old stack pointer */
        mov     x5, sp
        mrs     x6, tpidrro_el0
@@ -195,18 +183,12 @@ ENTRY(cpu_switch)
        msr     tpidr_el0, x6
        ldr     x6, [x4, #PCB_TPIDRRO]
        msr     tpidrro_el0, x6
-       ldp     x8, x9, [x4, #PCB_REGS + 8 * 8]
-       ldp     x10, x11, [x4, #PCB_REGS + 10 * 8]
-       ldp     x12, x13, [x4, #PCB_REGS + 12 * 8]
-       ldp     x14, x15, [x4, #PCB_REGS + 14 * 8]
-       ldp     x16, x17, [x4, #PCB_REGS + 16 * 8]
-       ldr          x19, [x4, #PCB_REGS + 19 * 8]
-       ldp     x20, x21, [x4, #PCB_REGS + 20 * 8]
-       ldp     x22, x23, [x4, #PCB_REGS + 22 * 8]
-       ldp     x24, x25, [x4, #PCB_REGS + 24 * 8]
-       ldp     x26, x27, [x4, #PCB_REGS + 26 * 8]
-       ldp     x28, x29, [x4, #PCB_REGS + 28 * 8]
-       ldr     lr, [x4, #PCB_LR]
+       ldp     x19, x20, [x4, #PCB_REGS + 19 * 8]
+       ldp     x21, x22, [x4, #PCB_REGS + 21 * 8]
+       ldp     x23, x24, [x4, #PCB_REGS + 23 * 8]
+       ldp     x25, x26, [x4, #PCB_REGS + 25 * 8]
+       ldp     x27, x28, [x4, #PCB_REGS + 27 * 8]
+       ldp     x29, lr, [x4, #PCB_REGS + 29 * 8]

        str     xzr, [x4, #PCB_REGS + 18 * 8]
        ret
@@ -258,23 +240,17 @@ ENTRY(fork_trampoline)
         * will be set to the desired value anyway.
         */
        ERET
-=20=20=20=20=20=20=20
+
 END(fork_trampoline)

 ENTRY(savectx)
        /* Store the callee-saved registers */
-       stp     x8,  x9,  [x0, #PCB_REGS + 8 * 8]
-       stp     x10, x11, [x0, #PCB_REGS + 10 * 8]
-       stp     x12, x13, [x0, #PCB_REGS + 12 * 8]
-       stp     x14, x15, [x0, #PCB_REGS + 14 * 8]
-       stp     x16, x17, [x0, #PCB_REGS + 16 * 8]
-       stp     x18, x19, [x0, #PCB_REGS + 18 * 8]
-       stp     x20, x21, [x0, #PCB_REGS + 20 * 8]
-       stp     x22, x23, [x0, #PCB_REGS + 22 * 8]
-       stp     x24, x25, [x0, #PCB_REGS + 24 * 8]
-       stp     x26, x27, [x0, #PCB_REGS + 26 * 8]
-       stp     x28, x29, [x0, #PCB_REGS + 28 * 8]
-       str     lr, [x0, #PCB_LR]
+       stp     x19, x20, [x0, #PCB_REGS + 19 * 8]
+       stp     x21, x22, [x0, #PCB_REGS + 21 * 8]
+       stp     x23, x24, [x0, #PCB_REGS + 23 * 8]
+       stp     x25, x26, [x0, #PCB_REGS + 25 * 8]
+       stp     x27, x28, [x0, #PCB_REGS + 27 * 8]
+       stp     x29, lr, [x0, #PCB_REGS + 29 * 8]
        /* And the old stack pointer */
        mov     x5, sp
        mrs     x6, tpidrro_el0
diff --git a/sys/arm64/arm64/vm_machdep.c b/sys/arm64/arm64/vm_machdep.c
index c52a7e2fc5..feb439314f 100644
--- a/sys/arm64/arm64/vm_machdep.c
+++ b/sys/arm64/arm64/vm_machdep.c
@@ -105,8 +105,8 @@ cpu_fork(struct thread *td1, struct proc *p2, struct th=
read
*td2, int flags)
        td2->td_frame =3D tf;

        /* Set the return value registers for fork() */
-       td2->td_pcb->pcb_x[8] =3D (uintptr_t)fork_return;
-       td2->td_pcb->pcb_x[9] =3D (uintptr_t)td2;
+       td2->td_pcb->pcb_x[19] =3D (uintptr_t)fork_return;
+       td2->td_pcb->pcb_x[20] =3D (uintptr_t)td2;
        td2->td_pcb->pcb_lr =3D (uintptr_t)fork_trampoline;
        td2->td_pcb->pcb_sp =3D (uintptr_t)td2->td_frame;
        td2->td_pcb->pcb_fpusaved =3D &td2->td_pcb->pcb_fpustate;
@@ -183,8 +183,8 @@ cpu_copy_thread(struct thread *td, struct thread *td0)
        bcopy(td0->td_frame, td->td_frame, sizeof(struct trapframe));
        bcopy(td0->td_pcb, td->td_pcb, sizeof(struct pcb));

-       td->td_pcb->pcb_x[8] =3D (uintptr_t)fork_return;
-       td->td_pcb->pcb_x[9] =3D (uintptr_t)td;
+       td->td_pcb->pcb_x[19] =3D (uintptr_t)fork_return;
+       td->td_pcb->pcb_x[20] =3D (uintptr_t)td;
        td->td_pcb->pcb_lr =3D (uintptr_t)fork_trampoline;
        td->td_pcb->pcb_sp =3D (uintptr_t)td->td_frame;
        td->td_pcb->pcb_fpflags &=3D ~(PCB_FP_STARTED | PCB_FP_KERN |
PCB_FP_NOSAVE);
@@ -287,8 +287,8 @@ void
 cpu_fork_kthread_handler(struct thread *td, void (*func)(void *), void *ar=
g)
 {

-       td->td_pcb->pcb_x[8] =3D (uintptr_t)func;
-       td->td_pcb->pcb_x[9] =3D (uintptr_t)arg;
+       td->td_pcb->pcb_x[19] =3D (uintptr_t)func;
+       td->td_pcb->pcb_x[20] =3D (uintptr_t)arg;
 }

 void

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Mar 20 21:00:13 2022
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 45B341A32CA0
	for ; Sun, 20 Mar 2022 21:00:14 +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 4KM9B56Vytz3PsZ
	for ; Sun, 20 Mar 2022 21:00:13 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 2FBE0651C
	for ; Sun, 20 Mar 2022 21:00:13 +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 22KL0DFm007359
	for ; Sun, 20 Mar 2022 21:00:13 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22KL0DRm007358
	for freebsd-arm@FreeBSD.org; Sun, 20 Mar 2022 21:00:13 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202203202100.22KL0DRm007358@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, 20 Mar 2022 21:00:13 +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="16478100131.EeDb.6382"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647810014;
	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=W1KmZH18dXhrz4vmKBH4qne2DW/lN8uiqcCm841qPR4=;
	b=Son+SmPPHyhn7g4RGBAiPwBNiVKk4/CDVGu3h6ZlWv4uQtyqP9zEDEFNutypxCUE7fk2mO
	Rnz/5YYPMnWJLhniNPin/cgZ7mS13xXV/iLLPSxwOIVs1KvgBkBc1qFtw6HKlW2cm4Y1wN
	o+y6MDcnyMO59CiVuZkW1hWrBoi14aTmMOIJjIME+vqrbA6YFZHLfMVTbcSRowTVH0qGtQ
	wbF7c0Sw6SybUrhtsqrilrgawqxvIQWdApNemb8ufmDpbWoF8pB9mpRcsEinju3zaxaFUe
	5APWmiTVxIUT0ZVNlb4WlWYNvS2v02Q5DKeIATft6n4XRtOH4cV/m/liwgKSJQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647810014; a=rsa-sha256; cv=none;
	b=H17uf+KId7BYDsGdF9hG/ywyqXLfkVoYtjSsu5hWMSDucRJ6q8jtNEgMIBdUva5uqf6Nor
	rbFLXfnius3bVKh8B7TYEFXYsrKOY+p84ccqJJr/pnpKMuAqTfjISqJq11s1SFMBzXLqxi
	ozl/zNO584+KAyh2zsPWmEXNAoPk685waS+DVZGsxU19AWzwhC5wwvQhSYxHJFPncGdF10
	F6WuWIZBIRi4AKKMdPOpc+MU+kph3iWcrWJY6KhHayn92S/ar7Na8kGymKZegcnvCGsbw1
	gHBc1/8pm6g1WVbWMM4TpaJ60vOycyO0AcLzKnL1hnwjHtM5GUyjGwtaWpwsRQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1792
Lines: 38


--16478100131.EeDb.6382
Date: Sun, 20 Mar 2022 21:00:13 +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.

--16478100131.EeDb.6382
Date: Sun, 20 Mar 2022 21:00:13 +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.


--16478100131.EeDb.6382--

From nobody Mon Mar 21 14:27:16 2022
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 0A7101A2A3E4
	for ; Mon, 21 Mar 2022 14:27:17 +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 4KMcQD1vdMz4hrg
	for ; Mon, 21 Mar 2022 14:27:16 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 11A771CD2B
	for ; Mon, 21 Mar 2022 14:27:16 +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 22LERFOv046395
	for ; Mon, 21 Mar 2022 14:27:15 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22LERFMN046394
	for freebsd-arm@FreeBSD.org; Mon, 21 Mar 2022 14:27:15 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 262700] pmu0: Cannot find CPU with MPIDR: 0x00000002
Date: Mon, 21 Mar 2022 14:27:16 +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: jfc@mit.edu
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1647872836;
	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=DVl+G1iBzG8NyDvVXtShn1pdyK9EXJ3zwshN10i2YP4=;
	b=mnzpeSVcjDoKyFCbE5OVglqOMyrhwTmIdySbUeK/7oJ/BHf9vQ9xDORgLMjwmbUpqiyIdp
	vSWbpjfFrdT+6GpIozebNfsdG12U+SJlE0e6ew6u05FFDD5imSLPhPtHSl9X9bL9lfkCCe
	+Y1Vx948q/tHNVd6O309gmzrXDcw2Hk+YhSdV+dfHA9F/MhsUA4GEkO+HEIxKTKoe9xTA2
	eQz2LGNX4hz3PSAzQlxeTqnG1xi3u3UydZalQRk9xw/l9cFDmaG+2TpjZZ1iHcP6PaPSI6
	fvPBNFbtgFkYiOd8XmQnnH3jMxFBfvpjO4KVGtU0tqD8oNEIe2hd7izhdH402Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647872836; a=rsa-sha256; cv=none;
	b=PG+kvc5OKtY+gxKbyTmPsIT4CjprZDep/xcGLNnkas1uDh8MJb03kDEsqaQeFRVjbbVwKc
	LmxBsf9b2fsRE5Un6iTRpVv2+QBFCs4GP7KvW92wcbNVd/gVPtHTZw5rjlfv3m1fB+y3CE
	YYqi5RfGB1FdOtxWz3MMR2TEQ2bakYYrzyx/YMk64iUenvA/mzKA9HxlApapdGLCMcxZpK
	rFA3RYzRxhmIJIkNaCq1quiauTJ6/g5W/w6rZTGQKKdzL2zQRbOjyNPigmv3ZLKYGujpRE
	D19wtidzbB00xumeQH7tOLmhBJf1o7IqLM9cO09Jwirep1yeFCtEEPfbxPJjzw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1291
Lines: 40

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262700

            Bug ID: 262700
           Summary: pmu0: Cannot find CPU with MPIDR: 0x00000002
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jfc@mit.edu

My OverDrive 1000 (4x ARM Cortex A-57) reports during boot:

Starting CPU 1 (1)
Starting CPU 2 (100)
Starting CPU 3 (101)
...
cpulist0:  on ofwbus0
cpu0:  on cpulist0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
pmu0:  irq 0,1,2,3 on ofwbus0
pmu0: Cannot find CPU with MPIDR: 0x00000002
pmu0: Cannot parse affinity for CPUid: 2.
device_attach: pmu0 attach returned 6
ahci0:  mem 0xe0300000-0xe03effff irq 9 on simplebus0

Is the (100) in the CPU list the MPIDR for CPU 2?  If so there's confusion
between sparse and dense processor numberings.

Reported against CURRENT but also present in stable/13.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Mar 23 01:26:57 2022
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 7F9F91A338AC
	for ; Wed, 23 Mar 2022 01:27:06 +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 4KNW154KWpz4b58
	for ; Wed, 23 Mar 2022 01:27:05 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 22N1QvRY082149
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 22 Mar 2022 18:26:58 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 22N1Qvtx082148;
	Tue, 22 Mar 2022 18:26:57 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 22 Mar 2022 18:26:57 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: /usr/src/sys/net/if_epair.c:181:6: error: ...
Message-ID: <20220323012657.GA82109@www.zefox.net>
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-Rspamd-Queue-Id: 4KNW154KWpz4b58
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.65 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.974];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.58)[-0.577];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1146
Lines: 34

A Pi2 running 
FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC  arm

stops buildkernel with:
--- if_epair.o ---
/usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of function 'atomic_testandclear_long' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
            ^

Not sure if this is specific to the Raspberry Pi 2, it didn't show up on a pair of Pi3's
and a single Pi4. The system is still using svnlite, info reports
root@www:/usr/src # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/stable/12
Relative URL: ^/stable/12
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 371771
Node Kind: directory
Schedule: normal
Last Changed Author: 0mp
Last Changed Rev: 371771
Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
 

Didn't see anything similar on bugs.freebsd.org, if it's worth a bug report or
there's a workaround please post. It was built using WITH_META_MODE if that 
matters. 

Thanks for reading,

bob prohaska


From nobody Wed Mar 23 03:06:46 2022
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 85B9E1A22B16
	for ; Wed, 23 Mar 2022 03:07:00 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNYDM3kVBz4qr7
	for ; Wed, 23 Mar 2022 03:06:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648004811; bh=ktnJFpq0TWrSi7anNw4s8kuINWtgAg5hW10n7Kzh6GA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oSBsR/WbQeVaR/uK+Sm14GmXqR5Dp5Ua5YEQ/ZvKv9QeTAM4Mrn8xEbyhyBkpB21AOjAy/kjcvRyY1ZTaZoePN7uuKROJgF6nTGygtElOJPKLqwpmzmOdBPEA+8QFd6C4bAVR6jqmDNfb3Q+HhBx0F6mDEa8lFSqjSqgKjmMJm+o0pIYWa4XcYB5bGmprsk/gFdt5Whimq+v572c5dHyJ9Gqd/L5RSByv3HpWVAe+E9yCy93Rtyx/GS1WBJHre1VElJOpZMaqxm9zoNkrrEeNgnUfmVU7I/W726WjAVrN9aODabrxFOA1eVtcyMsENaZjo35vs7gs0tifm0qzxdU1Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648004811; bh=DWrNXbsToyBKgT3ZidFKrod10Rav6HLxbt6UPw7VSsD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=diwMzWp8qDrtPDmnCcXWZstXrNwQ4kEgwbLlt6mumxBOUIEmqOKh7eQ11xMXIRNAJa7gatusGPWUamsoMFGddZ49Vk5MCrraXn4ekpKlqWekNrYnSv40lLdWIZsydCTvG7tny6oiA/OrLy/mBnlHDoUt0mkL1at+tP1oG+1CsBU6sQSEAVu5l2U8uyprsak13B33gmszQhMLGrP1Dz7TlHyb/dFosF8zU90yC/aBia6UYvNgKtNd1Z7uYaBgb2G1oMrXYO+wp8GfG6dGpGC60k2L3M+F8nqNiYHtZqn3ebBsK5LeNQfSU41IMoRmBq9Ijw4HYV75nSQ1K3oyPfUcaA==
X-YMail-OSG: ldFAD6EVM1md9cA0seHNK90PJnAA.UcXclMsqJbruA9UlA3g6LR8zZsB.xi0L2S
 xD21noqlKeL82Wbz4.3xxSaS9EEL4vtfqKNl.Qp4TVvhUCRjo_qWGVkhIkuKx6Wf65S2B27EnfJa
 AviGp31aDyMLjfzyesUo8QacWfOOBqrs0n.aCD37GY3B3qH5Ntl4SRZVqzwtWUUOHbdqujESlpKm
 nCZfil9qsbSbF.OVAfS8NTYIXU.8Yf1Y4kT9fsd5Dx5kWC0r4mHdTd11Posov3DJEV9rgzLf0H8i
 TM2_g9nVfs67cdPQ8mtgRpTkA.0OoXye6ICyyn97R.QdKLJcUN6KnYXMKkHS6Jx.3HWNft598A_Z
 zWWVBTmVFvv7zNaJKtqtUD0xjaBndzlXRmlbWqM8zSS8n7UY9555sO0uIWh364sC2mXjq5at936p
 aYPUnTfPv0eTG0lYmVOpxLQjQIrRIw9n8t9QC25vco3pPIDVqOVdqLB6VRHWScrw0NMqOZP5JQLF
 LuIuUFPLpVb5RoEXO1bdIdpZsDCI_hMlRvjiH.AwbJd48scmFYl8RV8va__vDnxWMwH4yBgckG2b
 AT5yA7KyvPRzqgL.GpKPEHOFZ8XnoT1p8.Cyo1usGGlI3UuFQdyiLqYL2Cc_W1UKpWhW9VsPSOru
 2vEdiIeXabaKjcxxKQ_0BYaVQyTaevHjF.1Gp2dpb3_TtIf_cs_bJNJ4C7DGrwP.d9u9f1koGd7D
 SYtW_xlySBtjQ_qNHqVYHZnyzENqXxcXXLDEg77A6pwhi.U1vxPZJsqooya7_yT0UunpqjRLWIQ_
 6zxOxKfYQlte5cE1l6KCmYu3g6XrGvtUczAsG8VXMN53UNugp3VzW9ZfVZdeIjnCtR4rycZZ3rwq
 26HHNoTcuokrye9iQHrEZKoxWvtqFfdfq32bqtvH_TUIB3H1aWyYDJRNLmRm8rOH2pMg5f9ZRsmW
 CyKs_lIjXOtZpFtKhOZ.OnWI1uckEbZM51Z7FM.yGsu6hjI8p.vHVzmmNOON2UVkUC8k03IJzbmk
 k2HrqfNrxdGggVDrw_l5Cx9yFj07NWtsdg_tUsjuO55XYX5cptnaFqMZSIlfOLx6P_msvSL2eWTE
 oVtYf9ahqlacaaLDj1t44LTQL5YMQtMlLzfQuFNmiq_Jqf6nnwgMiYCmRkxGZ.GKVNaEA3GsVMw7
 0ZOB9fdQfp.LStdqYyIvywRvxOPbdkwdred3Hn.rsiHTs72utXaxKc.7BVLxSWJGK41knGUKxDQ_
 nws56fMwS29NXx0PN55kXctFmiBdzDlb2yWfi98qTmOM1yvOwdViDmoSfGmSgq37TU63rm469RpE
 cLMHyw0jNdGKTJzG2Mm3s7Msn7uG3MkEDRVUmbKXx1_dLBxaejdnqr81IhocieMKJb_16HjcY67M
 KqGaJBMABGReTE1dLj93VEx7Rgzlx3nrowoMplKEDtZo05y5W3K2_SxLzAk5vJtwyiTva00sG5Sh
 ZOFkU_bZx_kCoHLQ8jntdwidhS.BDQD53cgiKdDyK.Iw937QzK00rN56CFpBR_RrnbyGrEttNlpP
 Kcf.orE0n8ypAZh8uT0UURCcraXHJMAP9c5bQsQewPQG3I5nNPrsAef9S4twyUpOqmYqbITACq_j
 WxSmOpFAyibBm3EeICHTk5AkxTMw2klM2.lsSrbXnSroBAne7LpsEtLv5bVhdD2.W.xcNzVeJUCf
 Vyk9djTYi0bWQsC9KJr81XaStp1Oes8EkjhAyq65LW2RjHwFW7pMXAu2IqymvdQFrN8abqhmf5Wx
 YFU4xIGudZ4zF21F6g_lhHvwCJg9Iq.WDzs88DTDtaV_Z2D6sPNc278aQmwPJL.DzMH6gikvEsyi
 8hZfw9j8KnSlFRUTWj4v31F2yIinajR6TD4dAvx0zhkjKkj4fq5CynRk29PTdJKLkYaeITwX2pSY
 aAsYUdyeOyGgOc1T7omW4o8ypKo7GozSePnEGwuQUsqgDBjQrzb7iX8AOx_sBWdK1NMNyKH67WE.
 BOPvSVky61KzCp0a_JCxPu1WAMMNfdDV7qVz_mp0_2LtCeD0hPmRI1T.7fPfsZKNTHlmpQzqDhES
 MfA8aXfVWi7sfg6HtBampVkmhF5hCmkMcOIiQevCMXs5gTj0F9RpzXmKVop0J.tFq01ZJQzf2_rZ
 dQseZbRQUd7FVhXMZmpGoDfmulG7sONqMOVjlMNIYfE8u9KDFsjjplFY9F913gJcu5sXAPPzcT5U
 OqfGMFaufW3IOETOiHG01O9O5iCdLdfcFtbrHRqUv7QMszsHXCL6XyKaytQVPCupMuKDZU0MLMcn
 xbKwZBroyIAATXMwwBIokVMyGPgbnQcL0snlKS6tHmHODPu3tf9I-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 03:06:51 +0000
Received: by kubenode510.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20092869fb7f53c92be3ae3813b55ffe;
          Wed, 23 Mar 2022 03:06:48 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <20220323012657.GA82109@www.zefox.net>
Date: Tue, 22 Mar 2022 20:06:46 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220323012657.GA82109@www.zefox.net>
To: bob prohaska ,
 "mav@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNYDM3kVBz4qr7
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="oSBsR/Wb";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.76 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.74)[0.740];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2528
Lines: 88

On 2022-Mar-22, at 18:26, bob prohaska  wrote:

> A Pi2 running=20
> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC  =
arm
>=20
> stops buildkernel with:
> --- if_epair.o ---
> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of =
function 'atomic_testandclear_long' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>            ^
>=20
> Not sure if this is specific to the Raspberry Pi 2, it didn't show up =
on a pair of Pi3's
> and a single Pi4. The system is still using svnlite, info reports
> root@www:/usr/src # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/stable/12
> Relative URL: ^/stable/12
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 371771
> Node Kind: directory
> Schedule: normal
> Last Changed Author: 0mp
> Last Changed Rev: 371771
> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>=20
>=20
> Didn't see anything similar on bugs.freebsd.org, if it's worth a bug =
report or
> there's a workaround please post. It was built using WITH_META_MODE if =
that=20
> matters.=20


author	Alexander Motin 	2022-03-16 04:09:09 =
+0000
committer	Alexander Motin 	2022-03-23 =
01:31:17 +0000
commit	5f81a4619dcf8026ab0ba12ea0bd1e6e36ae8c6c (patch)
. . .

Remove "/dev/" from geom name in `gpart add` command.stable/12

broke things by adding the atomic_testandclear_long usage without
defining it as well.

It goes like this:

path: root/sys/arm/include/atomic.h
Commit message (Expand)	Author	Age	Files	Lines
* 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all =
platforms.	Andriy Gapon	2019-10-24	1	-0/+7
* 	Remove arm-specific implementations of atomic_load/store_xxx() =
now that	Ian Lepore	2017-12-20	1	-27/+0
. . .

So not updated in a long time. But for armv7 and the like, it includes:

path: root/sys/arm/include/atomic-v6.h
Commit message (Expand)	Author	Age	Files	Lines
* 	MFC r352938:	Ian Lepore	2019-12-07	1	=
-100/+256
* 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
. . .

Also not updated in a long time.

sys/arm/include/atomic-v6.h has various "atomic_testand"
examples ( sys/arm/include/atomic.h does not ):

atomic_testandset_32
atomic_testandset_int
atomic_testandset_long
atomic_testandset_64

But no examples of "atomic_testandclear"



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 03:12:21 2022
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 B950B1A24371
	for ; Wed, 23 Mar 2022 03:12:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNYLn0gKZz4s8Q
	for ; Wed, 23 Mar 2022 03:12:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005146; bh=FJfWLx4izICyVPMo2Z+p7O2haNW5cKOFxijhObYb6QI=; h=From:Subject:Date:In-Reply-To:Cc:References:From:Subject:Reply-To; b=SX3AveEi24l3vO4GDlqfs0+nBpcOzzlweRRSXLbJKYaqGeynSjVR/FeEWGkqReHsHVYACNfP+GC6JSS18IfUJFg9QU/DtoXKK+e6+8so1caFsM6EzGkwtyRqyVSb5IEc/IjPg0B+yFHtspfctVJG0PIElYhRXFey4WnYrvyVAlgUclDxKG6tBG4v396sooxgJYNGFs0cLFy5prn/eFbqZOWcmFkXHAJVZJezfvHfxA8otUlsXPqozaVofxTn0j2YTkbvV1WgF+iaSomlb6t8jV/38dKAOVJrdFsJlrIc4P6dkAuH5x7vIjHtZGPVqL8iQcXlxGkiJkETwB1FRf0Flg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005146; bh=zrXgVyqpzn36PRca4+/5DVgx/Bf7j8lRr25g+liH81S=; h=X-Sonic-MF:From:Subject:Date:From:Subject; b=fnR3iivRu/7qD3liLlBmrvFM3S85iFbaq8gEufOSjkFkW66wKzA2txn5mjPlU0ZOtuUnrBkInAbQ8p9mPHnzRyMEtA+oj89Ag/fxCpAAjjHoCzDtmlhth7ZvnFOrZWWw7t5kXWYyXKs/HgzDS2wM/lxpHncR+DBtofhFS5fNXhPXPdGo2I/qXwLN/6Xt17RrPhgiFW+Pzkj1AMLuNvKc18oMxVLP4l1eMptbRSq5FDK8bOV9plEzgJKZJDu/P5rvSHf0JWAdYsTv/XvErS/J6+JYY7AAdPy3y7bkBTINZnbTaUGHGMFqia2cXpin3CMYmfkgAw374EDmSnVZ2qyqXA==
X-YMail-OSG: kToZcYgVM1m3NAhTR1A7Lk1Q.y5mSu0R0PBatuS4ZwWAC0b7.dWiJT0BL94kZTa
 ayFkg1tQpNUZDJEgKd9oLzZMID.6IXoJj5hsEZEj6amgNLLfwVspk3O60jHULE_kOGGsSACgNwJt
 M4y9.I9sqnTiJFb6gvcYrCrJkIAJFIcehyzbq6ywvEvnaxWCm9muRCRD.Q7Wd1GMrGvRaHVnHuPd
 X0BmxibWXJWV52Bfu_KsbJmsBUa2Cj7VAPhk8xQj5oHq0WP3thz_2A814947pgptstazxb_g7FM8
 ENHVOJRErf.LWk3fbc7vPzRDTAQisuXHgiaWDpB6ePVD_YIiuGCrCDMtJzzimbF3RvmohjqRBcYT
 4jLKiXuL4UPA44PsJ5ZP9vOwuYV7eBEOAfRFULK2x8HDofxDO1sh2PWJ76nVgbX_4.5pQZau9l2O
 aE3Fb3c4Q6Zebb4OJsvUMWVL1WwcCiKGRJ0rWJgClz.WI_h7RxfhtpgmbCM8fc0xCAVnQZ6tvLQH
 aa3LOiQwmu5cT9GBbj39gCy5k8FC3PAyxF9drpPrwHYpho_J8HUcE4KsOKWasGdEL9cDTC5QHenX
 7Zp24JNDTOwuK6XbA0doLMbYt0DU6bjLEzJLBdvH7dGSfW5jmNLsg0lfE80cyNOEUojeysTbXtuO
 QwgwCNVXgb9BH0NsWIdy71ImyAAD2hANW67Og8jXad35x32vLe9pHgfz1aKprMO4kqJpjZmIuZKa
 PMhknfH1aNypyK7nD4Wql8gAJtakr6yWk7p5u3TMBXjNdskaG9s3VLV_6tF_nnjl4f40JsP8l51Z
 86FWwYSdiD6axk6UAm_GiqajQJLAVOrKEFnB6GOriEy2FVPaktvOleef383qshdTU6WDog_KrXlR
 DeCEu0hCySma1C0xr08FjtfeQSZsbNke.AhsiVx_wEIVhLB0ZKtdZDFfTrLqvVhuGsrwezfniASY
 io06jsLCm0JrN4GngNZNEs3ZdYDo37F8DGwBGbUgjKZyWKisK2LG0R7e4YssReeNXbfNXdmtpu3D
 sFW7oC0yP.8I7Ui_ETIhTimZxmMlOz9GDV_BLUYBMDvxAdE82g5I8Yaf8.w_2TO46cUO.5WmHVhC
 WAfcQpQuTz69gBorQEbntVlgoQkVAoPAWozV0FYs7klt.Nb5yXe.4PLaq.ztR0Yjy2ThFfRCxXD9
 fW7XtLNvu_5H5TSx4g4AFPevDGml9jyap3ppggFXXBxv1fWM0f9aT.UzFYPH0tUBV3TJYkYX.65j
 J7KUMXSoAtZ_W_5WJFc3NsZO764zxmU1RQXDuZaAOaAphUj6VviPdxTCAZ.5z8LyPwnIZYWczUIq
 2JP.FQ5wFainawFmhIU6sF5W5lZmTozE2FadPshooHDdG_Yf9PleHevBQX7pCc8Pr6PtYwz.vHl.
 Rc2CxLf2qWCkcWA11ywrcRpQwgvEqJxaz.x6SSZntkNZ0f_QKlNNfwKtpzl4KLsrZOWX1F4304Yh
 AUH5H6ddA8sFzTqJECXvLaYVErOUHOuPoC1hMqMzgfHEkpYKAye23sDun2VaP8r04haG5iim_Ptj
 PHkm5BwxABr2WZ7HtaDX_2aunDgrmtdrmQvYAJgisu77xTzvBBCvB.MtXcmiOzGe6HsHP8WIzb.n
 rkx2bW9kcw3RR3BQCzoKFn.WdQ0E_QLx_YHauPJYy7mb3_y561CeC3A5doT1RdLetdOUU_rr.AnM
 GzXxM2FxBzL0JAgAX1IsW32SutTv8eZr9l8nQSVkJ.zG2jmmoVMv4ZY1Zw3U8Waop4WIL.fT2VcD
 GiTetickdqqq5pmXz8R5clb53uLSIHebl4vWv377h2b5Hf_v5NFkPLPfWMvU6DiEmUHY8vYMvCbL
 3OVioKvO2iO1DyCSZI6BfPcmPQLuot2I2k0OYSDuOImI3gRiNMyYgDNyE7KWGmuhAacVnhX_TQPW
 bjPTEnlZzOD29_VxEvDB_HyLcMWh315VkRCwi5mRpEALIm54PP0TbtHF2WerkwBQpYHW65Ej7SS7
 9M6BCEJA_SEGPVxyY6gBjsdtmW9hbZUIRTUEn6KWTYsBknNONsFJTZtVyQKBzFNVWf8U.7BW_bzP
 TpT_DkiqSekAirnahl4ZWnZuc0LPjDin2Q4I68U4JQ2ezjBwfNYak3QEit7W0vuTeJy1m2PYuvVh
 9W4vmnEceugTKXVpICfiDqusvT0yC1m.0aBqTTIdEK3MMz39M7Ik0mT0aRhjPU.2jJi96SDjWfbr
 3QtMU.P6wr.V2pQCwv5GEDU0I4bqnn3zjTEMH2kCcm4eqToW.IjxY8UIBI.wEcmWtbfw1DlnkbWl
 RugvO4KfjqDsa0_q._VvMhnUc
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 03:12:26 +0000
Received: by kubenode510.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bb12fef0c1bd0cfab01079379866fecd;
          Wed, 23 Mar 2022 03:12:22 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
Date: Tue, 22 Mar 2022 20:12:21 -0700
In-Reply-To: 
Cc: bob prohaska ,
 "mav@freebsd.org" ,
 freebsd-arm@freebsd.org
References: <20220323012657.GA82109@www.zefox.net>
 
Message-Id: <956CA18B-CB65-412D-86D3-60400FD30767@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNYLn0gKZz4s8Q
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=SX3AveEi;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [0.47 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MISSING_TO(2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.97)[0.969];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2813
Lines: 97

IGNORE THIS: I somehow switched contexts. Wrong
commit referenced!

> On 2022-Mar-22, at 20:06, Mark Millard  wrote:
>=20
> On 2022-Mar-22, at 18:26, bob prohaska  wrote:
>=20
>> A Pi2 running=20
>> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC =
 arm
>>=20
>> stops buildkernel with:
>> --- if_epair.o ---
>> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of =
function 'atomic_testandclear_long' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>>       if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>>           ^
>>=20
>> Not sure if this is specific to the Raspberry Pi 2, it didn't show up =
on a pair of Pi3's
>> and a single Pi4. The system is still using svnlite, info reports
>> root@www:/usr/src # svnlite info
>> Path: .
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/stable/12
>> Relative URL: ^/stable/12
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 371771
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: 0mp
>> Last Changed Rev: 371771
>> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>>=20
>>=20
>> Didn't see anything similar on bugs.freebsd.org, if it's worth a bug =
report or
>> there's a workaround please post. It was built using WITH_META_MODE =
if that=20
>> matters.=20
>=20
>=20
> author	Alexander Motin 	2022-03-16 =
04:09:09 +0000
> committer	Alexander Motin 	2022-03-23 =
01:31:17 +0000
> commit	5f81a4619dcf8026ab0ba12ea0bd1e6e36ae8c6c (patch)
> . . .
>=20
> Remove "/dev/" from geom name in `gpart add` command.stable/12
>=20
> broke things by adding the atomic_testandclear_long usage without
> defining it as well.
>=20
> It goes like this:
>=20
> path: root/sys/arm/include/atomic.h
> Commit message (Expand)	Author	Age	Files	Lines
> * 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all =
platforms.	Andriy Gapon	2019-10-24	1	-0/+7
> * 	Remove arm-specific implementations of atomic_load/store_xxx() =
now that	Ian Lepore	2017-12-20	1	-27/+0
> . . .
>=20
> So not updated in a long time. But for armv7 and the like, it =
includes:
>=20
> path: root/sys/arm/include/atomic-v6.h
> Commit message (Expand)	Author	Age	Files	Lines
> * 	MFC r352938:	Ian Lepore	2019-12-07	1	=
-100/+256
> * 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
> . . .
>=20
> Also not updated in a long time.
>=20
> sys/arm/include/atomic-v6.h has various "atomic_testand"
> examples ( sys/arm/include/atomic.h does not ):
>=20
> atomic_testandset_32
> atomic_testandset_int
> atomic_testandset_long
> atomic_testandset_64
>=20
> But no examples of "atomic_testandclear"
>=20





=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 03:16:42 2022
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 0AAD11A25D16
	for ; Wed, 23 Mar 2022 03:16:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNYRr0j3cz4snV
	for ; Wed, 23 Mar 2022 03:16:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005409; bh=UdL+wrZPaQ+mPJCcLVdOeC/ZoES5RwbIs5kFsKCDgak=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JBhosGJo4YlycGzL85IkLns/yYSKdCnl18CHxyBFH+F06xGAZTtjJ+atvD5XygfmkqBzC5Hzo8IaPPO4jIAzfss4S5MudmorqUn8OnMZsyI9LJv8wMg7njTIj3+Ge3AZe45vB5ixd/HEAz8G442/55ekSf/VYzp6FaGqciLSZqZlTH1ofm66XSWx33QNJm96AqXXO7LdDXZnhw8InDZccBmGGuLZib+KWT7uI7iXQTE7hDlXExFRBf0A+kxAcrU07Z+OJH//e0A60DjMQmUxCgX+cFnwZeYHMZ588VOVuacKUcYbaSmh1mWaFTNV7U0tq629A9BZQF1Mxdclw9P90g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005409; bh=SOGV3bFY7o+uU6JWcYotIIpaAPJIabscUySbcBVEI7v=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=n0mTvn6FKlqCT8qT7hOS+jRZfeYscZzNH8xH8xwUv07n8S9X1D3Qvhdms3iVpcR/CR7lXrutYZJuooubP4jjYZMI5LrBH0rkuxqgmTZ4TRGQ+396pVQFS075X8922XURn+iUUGkf2WGq3f1MTLAStqYkBhBSSzqoWSdrd/X+lTScyyVWCAosPyGGafbs0ngl59z1QFuRbFT/ITE03u/qBT39WHSCC/TaJVLFgIt4XBRdH+5rxwzdN3scFKR3tAtqmchlgKJEhswHfSwPsSVly7mtF8p1saK6kTIpJE9hu1xJnk32fJSRtPhXIAyOE+2ksZ58moNHeDp3n/sxa4mf/Q==
X-YMail-OSG: xwlqqVUVM1nPIWhvCrgXHy.QBBV3nmrFp8JAjkibLhXwMEyLDKO4wqomVRb2CfA
 nsbhjZ9rNK0YurQc2H7WCN9ywgfTjKVFNLw31jxZEbwnFq7_Jul7Li.rOA1FGu0wDFo6mKiwYatA
 zlCXNM2Cv4HBiB8M5j8XjiXv_oRZGXElzspPFRrBlCyT.597wvZjzmNhR2tWyCtV__VyeVed0Q8_
 yWIAyCtAIfJhPfgosgGU.tfbSHHZsoWW5eknf9UAp4WAjD9u85NpPO6SPW_JB4Nn5ywVowc58Igd
 o7a7OAB0h8wZHEy1j4jvdaOw_CrB0AAcAIU16UN0gL1En_QKHXZGmj0WJ8t.ka09hhJFL9C6nQjv
 DQwzH2h1mZ5yjtbW82tUmSH9ItLao_QIBn0XuqF69KNpDXQ9t2yPfJI2YTQnnNfTrEv86ZOfDNKR
 hwEIXK4RQJo3waoJQlgFXNBas4QarGn.ZOXxw4R9212Oo7qgw4QJlzCTaqFWwQVSOoo_byuDIRCv
 Iub50b7eu0LVpj.WdfRY3zhnvOVhwmw.tbebXGSZ3TpVXcVF7.lvLQbcRtXj1nXM_u3XHH5dkXU9
 GJ9M9hCqNtvhK9xBZJ37ZCxI.6j3rdZfkpZZEOSr729e_intBbdsoJzugvQbHt4.buYUQhb5J7U5
 A8hn4bgDXmYOP7TxLMm9V0kOhzxQOPouVeFCBdlqMtCvsRw8_4lzz98a3XUw5vLNNnwVpNU9Ar7r
 zLVcn9LSkZeQMKbycVaoEm4TR.JVjj2PxxH8FUxhv41ugGPjh0o58z8RAkEMHPep6.A.OVp388pF
 TraLzuLe0B0tD0FoSkuF5ShoPdzoopCggnOfv.9sCAx0WAOHlja0zsmePrJ_3M2s_iTsDaKnmdYC
 OXNVW.keuXylZdUpuMacmGUfs7A995LQnXIwPMB6I_y2Offg.ALLp542NOf5CNPN4X05vsjDi7jn
 QOdPJDsW4gtYv2GeCb5aCgmQkgSAuvAQ1MgBK5bdYKkGtw.vw01Agcj2Ly8UPTvDza5Sips_Vcef
 wdeR_EkF2lPxfJ9OZG16V0HJhBzXSVuxqY1jkhaR_MFaZKEbAWSjVkCP8AwSldcL.Vk3scImUnyp
 90L8ry8JsiB8Pjxz_zjqqicGAJJfM4P3qBeCC5Gh_J1YbLXRDBXdbFmlOoBanxmdKcsf82EeyD8e
 mOKMFq4p8YECFOoiuUGgYFlYP7gRAGUr8RAXclXr2Jrw22dz48qRhQBLQLERoKLSDlHoLoz2k9Jo
 NzquObrzw4uxjPqY7A3LcnUJmwycjFUTNZ.20dvz0ODH9A2wDipdYh9icoBnnLDG0SHcCOKu8W_R
 SC8dHM5rxIUFEP06fZe6fceaCYenb_DRdVXUdieUwAQQBgMGJ56kWU6iha9binrihzfZwXyzi1Hu
 5SeM9IS0y1XL_sxe4zD9OqSTovkkop9n7NE2KeikDa7iKUgbXYG1q0Y3ef.JQL0XXEUCU2HWtb5T
 0NbebBAp23Fl1o4EPBZ3B000uzdLqcK1O4k20Xfah2JdHXYBig28NENAWieNUJCg2YUAuTgEfD3r
 RCyFPBhkE2NmVAAa9Hgnrpsne4ant3NYoQ1AVMuzF1F_v60IrCa_PSQY_LnRhZemU.ohkeM7SNJl
 4foXwOXCvpM6yi_brqkE1fflmB2wssPaXc_IuuFHocayCa9dXo.dbfbvthyd.yq7sAY98TkFk4Rs
 uLOt3dJRay51qbUxhfWCCLfxOBhql2K59I9TMyhTQd9nTxlVI2X3b3dppfkhQ4zW0dwQbdoC96.r
 zZCyq0qUtbkbjfn.2vsYdM9FKGafRDRQQTxW8miQcaZmAoI8uFVOrE5pNdHT_16ilHffdjQg6IpO
 G3ul35_0icggI6vNc5rJVCn7hkD9_27XegRacYHiMNqCSEBaz6oi8cahv.8246rTuJCmkocEZOB4
 FmFAA4isA6cUKb3va0epYxyZutZCn3dA83AZ79u6vlNgsVQE0tbY_OZC5og6FfeKFvxx8jF9TOGV
 0dDkAkJdFCfPz2m7DG1s4.3n1JVclJEk6HA8h.LPJw_qv4biWI_cF.ILWpPiEnuC.6OCxKifqQ2D
 pQRoV8p_rSI_cT4LE12o_4.VgfdaLBnsVIwzbmuTQDSN0SQO.bIgMatSaDQwTJ5nP23oewvlj2lm
 4HZNKGn9gElLuiIanXQ7IYnkq3n1mOU8sa1W5v9GJeTuMuK_zX9NFne.oGOtvkt0j8nh4dTj6mYZ
 HPYfZ4Cajmg5WyVUJUq342QXWzzx9BLmW9ye.Voku.E0RRpbx5yjGIbx1VxfCAjhZHfdfSiVlfPs
 4q4OoNbGymi6hP1vwZW_OTXecIhz_UclDxIZXuz7_Le21ZbLOjIPG6VS6
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 03:16:49 +0000
Received: by hermes--canary-production-bf1-665cdb9985-zm65g (VZM Hermes SMTP Server) with ESMTPA ID 30d29adc6ff11769a47b75a2425bfcf3;
          Wed, 23 Mar 2022 03:16: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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <20220323012657.GA82109@www.zefox.net>
Date: Tue, 22 Mar 2022 20:16:42 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
References: <20220323012657.GA82109@www.zefox.net>
To: bob prohaska ,
 "kp@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNYRr0j3cz4snV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JBhosGJo;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.97)[-0.974];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2792
Lines: 93

[Trying again after getting material from the wrong
commit the first time.]

On 2022-Mar-22, at 18:26, bob prohaska  wrote:

> A Pi2 running=20
> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC  =
arm
>=20
> stops buildkernel with:
> --- if_epair.o ---
> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of =
function 'atomic_testandclear_long' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>            ^
>=20
> Not sure if this is specific to the Raspberry Pi 2, it didn't show up =
on a pair of Pi3's
> and a single Pi4. The system is still using svnlite, info reports
> root@www:/usr/src # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/stable/12
> Relative URL: ^/stable/12
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 371771
> Node Kind: directory
> Schedule: normal
> Last Changed Author: 0mp
> Last Changed Rev: 371771
> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>=20
>=20
> Didn't see anything similar on bugs.freebsd.org, if it's worth a bug =
report or
> there's a workaround please post. It was built using WITH_META_MODE if =
that=20
> matters.=20

QUOTE
author	Kristof Provost 	2022-03-17 02:35:13 =
+0000
committer	Kristof Provost 	2022-03-20 =
00:25:06 +0000
commit	b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d (patch)
. . .
if_epair: build fix
66acf7685b failed to build on riscv (and mips). This is because the
atomic_testandset_int() (and friends) functions do not exist there.
Happily those platforms do have the long variant, so switch to that.
END QUOTE

broke things for stable/12 by adding the atomic_testandclear_long
usage without defining it as well.

It goes like this:

path: root/sys/arm/include/atomic.h
Commit message (Expand)	Author	Age	Files	Lines
* 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all =
platforms.	Andriy Gapon	2019-10-24	1	-0/+7
* 	Remove arm-specific implementations of atomic_load/store_xxx() =
now that	Ian Lepore	2017-12-20	1	-27/+0
. . .

So not updated in a long time. But for armv7 and the like, it includes:

path: root/sys/arm/include/atomic-v6.h
Commit message (Expand)	Author	Age	Files	Lines
* 	MFC r352938:	Ian Lepore	2019-12-07	1	=
-100/+256
* 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
. . .

Also not updated in a long time.

sys/arm/include/atomic-v6.h has various "atomic_testand"
examples ( sys/arm/include/atomic.h does not ):

atomic_testandset_32
atomic_testandset_int
atomic_testandset_long
atomic_testandset_64

But no examples of "atomic_testandclear"


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 03:23:09 2022
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 4DE2A1A2725F
	for ; Wed, 23 Mar 2022 03:23: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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNYbJ22llz4tpY
	for ; Wed, 23 Mar 2022 03:23:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005797; bh=rGPXguB//fkmLXJyT9QJ1WO9eQmmhRopLVu3KEu4VB4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LqKSYwHTwRNbHuwZ90TVBzQPjt+HMUHCSOR5A1O5vOLegOqCmMuC5h9ckl1tkcGZEfc/YOhiJzQUJg1aR8KiGCrSWY/g3czCtdaKVttBEAtIqRluLF3MbF9S6hnfDOi3Fg08l5nGWfiUkQbb5y2POt3WzM4ZhUkkBpmWGApWPMoKzP1eZG1/RZnSmcbjflp6cgLVwPri1ji4XvQrBy0yIzoiKy9H3pZ9hruoLfDZp8LIaRQAMsZeahAyjr/79V6qEprRbri+sAFs0mHvc1KKqW7eVp0joXiLZZxZJy3GHkLO8/x1ZQZ5W4+0caAmEvOK83rSH6h7BZDo0YmzLJHWwg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648005797; bh=a5jMcdAVTz9NbaHXUeS+Mt49d4U40tHeKsjfyJbu5kk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RSF0BvQ7c+gpFPIdz0dwb64y9lsxxdn7onRLrx6N/kZ/M/MOiGNzi1x/R5V3+1VJyntw44Yp4EBsWhtYcSphY1HY8yCasm5uMRaCcqfBpq2StfM0TNGlfBh8eyRn2WfaLhmd1/c17r21Sc9a73bQSrh0swoEOceVbRodh9fCcQ7pdJdFPrVMXdbrBhtWJAfIlS6NPvO5XfdA4jvC7Bxma19j/UaTSdePn7gz1r1RzoQptRKkMUUNSfoNEqSWr5jWNZCcczgtnP9Ng30/la+D/Hcx38xhfTb5CfkD4Q7Y5kPqy/W9+3tPZGgyRYgi+xntHRucq58HH3oFZ9fiv3ZP/A==
X-YMail-OSG: yFbjOAYVM1nsuVIPU5_Il19neK1PhNP03tBt141ksWdkWTr4EOc85jktKvd1RK2
 Jl6Bmo4FJEWHldUXmAoHksMvJ_TxsqGJ0QBmetD1WcGTWZV.z8z6x96GkVMVFBDBa187gUxG0YwS
 sTs63kLkngKK8NWvdvvazJEi0yRAvCNSlzzYMDokbZ8a3z10Ymqd7ofr.Cumb6lSPdAidtt9yGU1
 wcMulOC0DjWqO3ugEjrUC11rMIKQG1ZSnH44bszNu4HEEvi_rd.b6gxu9pmxn9ospCqKQziWMSnJ
 jKNUax4anMCyXp9nUTrequz30yl5kpkoMRppe_YleCJZcueBEUjOMMTu3JRaNRQLwDee2hBHlEW3
 UVaMYXvyU8zUcuahdNX78FSTDLF3kqW7Ra4htU_nKLr0Rw3O1gOVUydB6RWc5z87gxz4TBPBcCQk
 sxG0Ghh3kCLlQHJ0NldhQ8ZrkQmyDonN79rk2I7_.UD5lqYGkVa6MQH5Bi7u6eTAN1TUBXMpd3cq
 0kFB4fm.JE4x86Qbgx2GXlPitDcCQ3ZDLqc93e6aUqX63jefacl7mmi5_ZN6M9NCNZ1Q0DEaDQsj
 3_ZkPduRW_iEN99bZyRV.5agHoVJ5AkCWD.2UUHQ9._yy041qpQ_4ZMd1w0cLJQZ_oKF4NFjkD20
 Yh0iM23gnO7q1QDsvM7wTj_XrrH5t8vf6aAE1vqSQ1Xpo2wrOmuQaamuw8vfbeuYQHwhAawjDB9.
 srA5bfq9pNFdQKDMDHBNkVjTTuYUZV6N5WuTueZ.wf6r_MK3J_4Fc0B7KFfrtPO_bdOPf5K6ZKN9
 Zahpqv5p6xDsKZbIFkZEuQJY6BVikZyR4_dkOT9OnFyY3NAKyzUW5qTrTswtqa8uFwrj.oU9_GAU
 M6kmdbpp_zZdtTYWUFdg5nAhaE0zMXor0c9JHCRRpZufcQW.16mCdd_a5Kj6WJlPKbpytUkdRaCB
 569VqKDkahlbQcXx1RlODmGE9lkrqKAOmCRAUkd5ZpdGu9NQKVnZuu7C4cSNmPMGZhM43q3DHY69
 FGzbbFG6DbJqRdIdI7ckMhMqaxiBBgWDzMS8uK.rmWFw.DLQoYIoHAISfHCmGRGUvLaoG3kLrzRK
 JiN8i_es.rsJaWrc3Mp7UJccI8y_kNEzSW2NaBgYViXd3JvLzuPvisoQVHCAfbDhD4FePEfX.q50
 VDFhVGJu7RKvYdiy2MZjL.j2VWM7WJfzNT7XqyyA6BcxfBCV94A8MFLgpmVNt_DgFvtNsdzuIgh5
 eeKdChmJoGZYQz9IPS_Mhzbj253z4fmd1M7STDb79yQ6R288SKEeo0159x97s5IxJrViB23dK28A
 tQr76GdAPRdTVZf6mOPfN8HJ2CHNfLMZTO7prwznEtrqRAh3xKowM3wkEQ.D6EEc7ry8eUDkuB3g
 mC.Qc5SBKZOMCrRekjR4Zb6_PLwmihpqsJlqWNbkbbIVa3Gs8LMGEFewns38WAYcrxWvM54g3oj1
 jP9pEQ1BXWQGFlpRlBolsybzmSOy7_nkMZaqNdRJ2kRj0CSAVnI5jXxfy6qM5b1S2X7iMI8ctEEP
 Hm693IxXaCvCWM0K8Zn1vBlSfggo1gTKv_iLL27bV.q6EjLEx0i8rCvq83pHSmbYwA1ci1zIkS5d
 8lVLUDh.GRnV6FAvHFCZ5XxVHK0lGI017Ovb.j3zZeA9Rwkj0BvUk9E4XoClinzCT7hToL7wbEII
 KUxTePExfuf_iZGuzs6VFcE_3hRKWO_Jx7MXmTWLWPCII.iOMJAuAmnBXUhG7SKN2MEoc3u3HxnS
 E9HaJ6c4k8bT4jnLIhtn3foXlpkv3aDdj1bNyl_matYKl2sNfQrvTwot3qSfLU8ft9970RIb2xNl
 Tqna.AdSlBgFf6tPVpV.U8ky3Su8IzC8UMIM_Up5AOkTVv2ffpiCw01xSGr3Y2rMXq6uR1JyagE2
 ytpVQjdHW9DobPceuxWYmA3nEfsyRb4zv6GiwRiWeollaSberECpFyohvgyUxf98heBJx09gFPO4
 AFqFW0n0Iq0n8F7J148iBMA4QrTSSKWNH9jP19HleOxlZS.cfzlbuEjSuFi1_gXHFZeVeHntXxry
 GwAYecSzjgDdW05hRiGeUI.pmme_FToZYD_DDE8kA53gM9VIyM.0hbkfyKx2Zy1e2UiDc0f5zxXZ
 PEIGxPp0F61OMrtUL.o_AJ0MVg6h0noEIjCkwW6bzcpRzGVt5iYwffegmdy0T8slgsk2khxAJY87
 bv8icT_lmn6yHVwMVJYG70bpz_A0.1pZsUUpT.sb2ZpzE81dNLRCwBsr0HJZJSBy7ne3qJUL0e5I
 bPhJHrX8IG8pimh0NQPUMn443GeBdCrsc_J28GePtxiZsBgQdHTxU0oA9Ju8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 03:23:17 +0000
Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID 502e8a778bd1892701a24b248ab8bc2c;
          Wed, 23 Mar 2022 03:23:11 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
Date: Tue, 22 Mar 2022 20:23:09 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com>
References: <20220323012657.GA82109@www.zefox.net>
 <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
To: bob prohaska ,
 "kp@freebsd.org" ,
 "grembo@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNYbJ22llz4tpY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=LqKSYwHT;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.97)[-0.970];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3367
Lines: 114



On 2022-Mar-22, at 20:16, Mark Millard  wrote:

> [Trying again after getting material from the wrong
> commit the first time.]
>=20
> On 2022-Mar-22, at 18:26, bob prohaska  wrote:
>=20
>> A Pi2 running=20
>> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC =
 arm
>>=20
>> stops buildkernel with:
>> --- if_epair.o ---
>> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of =
function 'atomic_testandclear_long' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>>       if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>>           ^
>>=20
>> Not sure if this is specific to the Raspberry Pi 2, it didn't show up =
on a pair of Pi3's
>> and a single Pi4. The system is still using svnlite, info reports
>> root@www:/usr/src # svnlite info
>> Path: .
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/stable/12
>> Relative URL: ^/stable/12
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 371771
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: 0mp
>> Last Changed Rev: 371771
>> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>>=20
>>=20
>> Didn't see anything similar on bugs.freebsd.org, if it's worth a bug =
report or
>> there's a workaround please post. It was built using WITH_META_MODE =
if that=20
>> matters.=20
>=20
> QUOTE
> author	Kristof Provost 	2022-03-17 =
02:35:13 +0000
> committer	Kristof Provost 	2022-03-20 =
00:25:06 +0000
> commit	b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d (patch)
> . . .
> if_epair: build fix
> 66acf7685b failed to build on riscv (and mips). This is because the
> atomic_testandset_int() (and friends) functions do not exist there.
> Happily those platforms do have the long variant, so switch to that.
> END QUOTE
>=20
> broke things for stable/12 by adding the atomic_testandclear_long
> usage without defining it as well.
>=20
> It goes like this:
>=20
> path: root/sys/arm/include/atomic.h
> Commit message (Expand)	Author	Age	Files	Lines
> * 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all =
platforms.	Andriy Gapon	2019-10-24	1	-0/+7
> * 	Remove arm-specific implementations of atomic_load/store_xxx() =
now that	Ian Lepore	2017-12-20	1	-27/+0
> . . .
>=20
> So not updated in a long time. But for armv7 and the like, it =
includes:
>=20
> path: root/sys/arm/include/atomic-v6.h
> Commit message (Expand)	Author	Age	Files	Lines
> * 	MFC r352938:	Ian Lepore	2019-12-07	1	=
-100/+256
> * 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
> . . .
>=20
> Also not updated in a long time.
>=20
> sys/arm/include/atomic-v6.h has various "atomic_testand"
> examples ( sys/arm/include/atomic.h does not ):
>=20
> atomic_testandset_32
> atomic_testandset_int
> atomic_testandset_long
> atomic_testandset_64
>=20
> But no examples of "atomic_testandclear"
>=20
>=20

The slightly older commit:

QUOTE
author	Michael Gmelin 	2022-03-16 22:08:55 =
+0000
committer	Kristof Provost 	2022-03-20 =
00:24:51 +0000
commit	fb3644ab2afe777fdd2539bc996a390443f052f1 (patch)
. . .
if_epair: fix race condition on multi-core systems
END QUOTE

has a use of "atomic_testandclear_int" as well.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 10:51:17 2022
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 003D41A22371
	for ; Wed, 23 Mar 2022 10:51:22 +0000 (UTC)
	(envelope-from kp@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 4KNlX96TQqz3K42;
	Wed, 23 Mar 2022 10:51:21 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1648032681;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=+ydJT3o/fiv15cw462Dq4hhC1z7oc6+7JisVDOcW95w=;
	b=EzYwkOsdnYLyNPiBwZKfRNlXFuze/BBihGaSO0Z3F/Qt1MEG4QTKajLlxp61nFyllUsha6
	6YoV3I+UYpj/sEa/ubYUDXKKk2SCwsNI0FEoDpFAyuKwIAj2pP2cCItXc+1pVe/kCQWYM5
	k1a14FJlfc5MWbRp0eJpuLnfEShN5Y751zQWTeZXOQy1x6kMvfPzHY2dYkQXpgcEKg8LKx
	xtcpVVWU6SXJY6BMQJAomdI9rqGSjc79tx9zNHJasv1MDZBj32VWErfqKD9n3KPBRuWdYT
	4byN3yS4ZLNGqqk0roIIsdZRR7T2IBtUkcqBM1O9rbCftrgMcEs2QCg8L4tHOg==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 7C2C822165;
	Wed, 23 Mar 2022 10:51:21 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 603DD3DB55;
	Wed, 23 Mar 2022 11:51:18 +0100 (CET)
From: Kristof Provost 
To: Mark Millard 
Cc: bob prohaska , grembo@FreeBSD.org,
 Free BSD 
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
Date: Wed, 23 Mar 2022 11:51:17 +0100
X-Mailer: MailMate (1.14r5852)
Message-ID: <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
In-Reply-To: <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com>
References: <20220323012657.GA82109@www.zefox.net>
 <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
 <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@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: multipart/mixed;
 boundary="=_MailMate_023E3E3C-1326-4075-96E1-440957B9BAB2_="
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648032681;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=+ydJT3o/fiv15cw462Dq4hhC1z7oc6+7JisVDOcW95w=;
	b=j2iFC085/qu6+DUAVLzAAEHGgi3X/U0ZgY5dzS2OWcZyKPa2pw4in/w+9ql/BIzCrSD7qP
	OdNbVojxaAp/gOYVIFRoIs+KPs7vG2eZkhpAvipMVznxlL8y/qpR0XYZue4Z7Fuh9j7M8W
	rMi7cYK2RygXAytJ5xD7StCy9UO6wpf1H314Egg7MRP+C9puEstMohroU/OBgM6BklxYw0
	+86h8pkIznCf0vQHy/bbB0X/n6FiqvGahJsiXgsS34JKNisTkNQqCFcHlawkWQZmnVXszi
	4T896R0vG8/asQkaNbUpaK9BbetZa9Buy0xcY4G0QK9Eb50Nlaw8x26/50Cx0w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648032681; a=rsa-sha256; cv=none;
	b=fl3atVU0jRlXACCgf0UzlBMfFE0ObdbYnsZLDjHKWOZy4q/MHbV/7739EHPZMmZVEUJOvM
	wBaqfuMLYXDfEE/LLqT0wgKffxMgu2pazF9+7DHm2Sfq3v63Qj3h8HtO6ROQbRqi5zVTxM
	55AyLkyDKDVXq32WgpG0lweQiDMjVyreOhshnrSRkK4tY6QuvAI0dEe1RLH4DZ7pV/ophZ
	9Or/5BjNsQWjHwoQaO8uwc/JmBAzitObyC6cRfhlo0agGWe7Mamx03IdEwzsXhkjWTH6h/
	hYqfQFxwTDoezZZfhLLPlox//iZZW+Jo4HmcIgWJsNfbubYAYNMfr38F6b9Pcw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 38903
Lines: 1403


--=_MailMate_023E3E3C-1326-4075-96E1-440957B9BAB2_=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mark,

On 23 Mar 2022, at 4:23, Mark Millard wrote:
> On 2022-Mar-22, at 20:16, Mark Millard  wrote:
>
>> [Trying again after getting material from the wrong
>> commit the first time.]
>>
>> On 2022-Mar-22, at 18:26, bob prohaska  wrote:
>>
>>> A Pi2 running
>>> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 GENERIC=
  arm
>>>
>>> stops buildkernel with:
>>> --- if_epair.o ---
>>> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of fun=
ction 'atomic_testandclear_long' is invalid in C99 [-Werror,-Wimplicit-fu=
nction-declaration]
>>>       if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>>>           ^
>>>
>>> Not sure if this is specific to the Raspberry Pi 2, it didn't show up=
 on a pair of Pi3's
>>> and a single Pi4. The system is still using svnlite, info reports
>>> root@www:/usr/src # svnlite info
>>> Path: .
>>> Working Copy Root Path: /usr/src
>>> URL: svn://svn.freebsd.org/base/stable/12
>>> Relative URL: ^/stable/12
>>> Repository Root: svn://svn.freebsd.org/base
>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>> Revision: 371771
>>> Node Kind: directory
>>> Schedule: normal
>>> Last Changed Author: 0mp
>>> Last Changed Rev: 371771
>>> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>>>
>>>
>>> Didn't see anything similar on bugs.freebsd.org, if it's worth a bug =
report or
>>> there's a workaround please post. It was built using WITH_META_MODE i=
f that
>>> matters.
>>
>> QUOTE
>> author	Kristof Provost 	2022-03-17 02:35:13 +0000
>> committer	Kristof Provost 	2022-03-20 00:25:06 +0000
>> commit	b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d (patch)
>> . . .
>> if_epair: build fix
>> 66acf7685b failed to build on riscv (and mips). This is because the
>> atomic_testandset_int() (and friends) functions do not exist there.
>> Happily those platforms do have the long variant, so switch to that.
>> END QUOTE
>>
>> broke things for stable/12 by adding the atomic_testandclear_long
>> usage without defining it as well.
>>
>> It goes like this:
>>
>> path: root/sys/arm/include/atomic.h
>> Commit message (Expand)	Author	Age	Files	Lines
>> * 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all platfo=
rms.	Andriy Gapon	2019-10-24	1	-0/+7
>> * 	Remove arm-specific implementations of atomic_load/store_xxx() now =
that	Ian Lepore	2017-12-20	1	-27/+0
>> . . .
>>
>> So not updated in a long time. But for armv7 and the like, it includes=
:
>>
>> path: root/sys/arm/include/atomic-v6.h
>> Commit message (Expand)	Author	Age	Files	Lines
>> * 	MFC r352938:	Ian Lepore	2019-12-07	1	-100/+256
>> * 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
>> . . .
>>
>> Also not updated in a long time.
>>
>> sys/arm/include/atomic-v6.h has various "atomic_testand"
>> examples ( sys/arm/include/atomic.h does not ):
>>
>> atomic_testandset_32
>> atomic_testandset_int
>> atomic_testandset_long
>> atomic_testandset_64
>>
>> But no examples of "atomic_testandclear"
>>
>>
>
> The slightly older commit:
>
> QUOTE
> author	Michael Gmelin 	2022-03-16 22:08:55 +0000
> committer	Kristof Provost 	2022-03-20 00:24:51 +0000
> commit	fb3644ab2afe777fdd2539bc996a390443f052f1 (patch)
> . . .
> if_epair: fix race condition on multi-core systems
> END QUOTE
>
> has a use of "atomic_testandclear_int" as well.
>
>
Thanks for the report.

Can you try the attached patch? I=E2=80=99m not going to argue with the M=
I code about the atomic_testandclear_int, but instead revert the new if_e=
pair code (in stable/12 only, of course).

Best regards,
Kristof
--=_MailMate_023E3E3C-1326-4075-96E1-440957B9BAB2_=
Content-Disposition: attachment; filename="0001-Revert-if_epair-rework.patch"
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

=46rom cd13085b06296f5ce9079abfba5b52e2877398d3 Mon Sep 17 00:00:00 2001
From: Kristof Provost 
Date: Mon, 21 Mar 2022 15:41:32 +0100
Subject: [PATCH] Revert "if_epair: rework"

Revert the recent performance rework of if_epair. It relies on functions =
like
atomic_testandclear_long() which are not available on all platforms in
stable/12.

This reverts commits b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d,
fb3644ab2afe777fdd2539bc996a390443f052f1,
ca7af63e88f8cc96865d45e020a57b3062631388,
092da35a0d80af7a3e5c5c22cbeddb6cffbd9524,
and 7c2b681b33fc78ed06c7e9e65eeebb2ab5420586.

This is a direct commit to stable/12.
---
 sys/modules/if_epair/Makefile |   2 +-
 sys/net/if_epair.c            | 832 +++++++++++++++++++++-------------
 2 files changed, 509 insertions(+), 325 deletions(-)

diff --git a/sys/modules/if_epair/Makefile b/sys/modules/if_epair/Makefil=
e
index 8b063623f2e8..3e102413bfe2 100644
--- a/sys/modules/if_epair/Makefile
+++ b/sys/modules/if_epair/Makefile
@@ -3,6 +3,6 @@
 .PATH: ${SRCTOP}/sys/net
 =

 KMOD=3D	if_epair
-SRCS=3D	bus_if.h device_if.h if_epair.c opt_rss.h opt_inet.h opt_inet6.h=

+SRCS=3D	bus_if.h device_if.h if_epair.c
 =

 .include 
diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c
index 4b01e97c354d..cd11036ad028 100644
--- a/sys/net/if_epair.c
+++ b/sys/net/if_epair.c
@@ -2,8 +2,8 @@
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
  * Copyright (c) 2008 The FreeBSD Foundation
+ * Copyright (c) 2009-2010 Bjoern A. Zeeb 
  * All rights reserved.
- * Copyright (c) 2009-2021 Bjoern A. Zeeb 
  *
  * This software was developed by CK Software GmbH under sponsorship
  * from the FreeBSD Foundation.
@@ -37,14 +37,21 @@
  * This is mostly intended to be used to provide connectivity between
  * different virtual network stack instances.
  */
+/*
+ * Things to re-think once we have more experience:
+ * - ifp->if_reassign function once we can test with vimage. Depending o=
n
+ *   how if_vmove() is going to be improved.
+ * - Real random etheraddrs that are checked to be uniquish; we would ne=
ed
+ *   to re-do them in case we move the interface between network stacks
+ *   in a private if_reassign function.
+ *   In case we bridge to a real interface/network or between indepedent=

+ *   epairs on multiple stacks/machines, we may need this.
+ *   For now let the user handle that case.
+ */
 =

 #include 
 __FBSDID("$FreeBSD$");
 =

-#include "opt_rss.h"
-#include "opt_inet.h"
-#include "opt_inet6.h"
-
 #include 
 #include 
 #include 
@@ -54,16 +61,13 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
-#include 
-#include 
 =

 #include 
 #include 
@@ -74,66 +78,121 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
-#ifdef RSS
-#include 
-#ifdef INET
-#include 
-#endif
-#ifdef INET6
-#include 
-#endif
-#endif
 #include 
 =

+SYSCTL_DECL(_net_link);
+static SYSCTL_NODE(_net_link, OID_AUTO, epair, CTLFLAG_RW, 0, "epair sys=
ctl");
+
+#ifdef EPAIR_DEBUG
+static int epair_debug =3D 0;
+SYSCTL_INT(_net_link_epair, OID_AUTO, epair_debug, CTLFLAG_RW,
+    &epair_debug, 0, "if_epair(4) debugging.");
+#define	DPRINTF(fmt, arg...)						\
+	if (epair_debug)						\
+		printf("[%s:%d] " fmt, __func__, __LINE__, ##arg)
+#else
+#define	DPRINTF(fmt, arg...)
+#endif
+
+static void epair_nh_sintr(struct mbuf *);
+static struct mbuf *epair_nh_m2cpuid(struct mbuf *, uintptr_t, u_int *);=

+static void epair_nh_drainedcpu(u_int);
+
+static void epair_start_locked(struct ifnet *);
+static int epair_media_change(struct ifnet *);
+static void epair_media_status(struct ifnet *, struct ifmediareq *);
+
 static int epair_clone_match(struct if_clone *, const char *);
 static int epair_clone_create(struct if_clone *, char *, size_t, caddr_t=
);
 static int epair_clone_destroy(struct if_clone *, struct ifnet *);
 =

 static const char epairname[] =3D "epair";
-#define	RXRSIZE	4096	/* Probably overkill by 4-8x. */
+static unsigned int next_index =3D 0;
 =

-static MALLOC_DEFINE(M_EPAIR, epairname,
-    "Pair of virtual cross-over connected Ethernet-like interfaces");
+/* Netisr related definitions and sysctl. */
+static struct netisr_handler epair_nh =3D {
+	.nh_name	=3D epairname,
+	.nh_proto	=3D NETISR_EPAIR,
+	.nh_policy	=3D NETISR_POLICY_CPU,
+	.nh_handler	=3D epair_nh_sintr,
+	.nh_m2cpuid	=3D epair_nh_m2cpuid,
+	.nh_drainedcpu	=3D epair_nh_drainedcpu,
+};
 =

-VNET_DEFINE_STATIC(struct if_clone *, epair_cloner);
-#define	V_epair_cloner	VNET(epair_cloner)
+static int
+sysctl_epair_netisr_maxqlen(SYSCTL_HANDLER_ARGS)
+{
+	int error, qlimit;
 =

-static unsigned int next_index =3D 0;
-#define	EPAIR_LOCK_INIT()		mtx_init(&epair_n_index_mtx, "epairidx", \
-					    NULL, MTX_DEF)
-#define	EPAIR_LOCK_DESTROY()		mtx_destroy(&epair_n_index_mtx)
-#define	EPAIR_LOCK()			mtx_lock(&epair_n_index_mtx)
-#define	EPAIR_UNLOCK()			mtx_unlock(&epair_n_index_mtx)
-
-#define BIT_QUEUE_TASK		0
-#define BIT_MBUF_QUEUED		1
-
-struct epair_softc;
-struct epair_queue {
-	int			 id;
-	struct buf_ring		*rxring[2];
-	volatile int		 ridx;		/* 0 || 1 */
-	volatile long		 state;		/* taskqueue coordination */
-	struct task		 tx_task;
-	struct epair_softc	*sc;
-};
+	netisr_getqlimit(&epair_nh, &qlimit);
+	error =3D sysctl_handle_int(oidp, &qlimit, 0, req);
+	if (error || !req->newptr)
+		return (error);
+	if (qlimit < 1)
+		return (EINVAL);
+	return (netisr_setqlimit(&epair_nh, qlimit));
+}
+SYSCTL_PROC(_net_link_epair, OID_AUTO, netisr_maxqlen, CTLTYPE_INT|CTLFL=
AG_RW,
+    0, 0, sysctl_epair_netisr_maxqlen, "I",
+    "Maximum if_epair(4) netisr \"hw\" queue length");
 =

-static struct mtx epair_n_index_mtx;
 struct epair_softc {
-	struct ifnet		*ifp;		/* This ifp. */
-	struct ifnet		*oifp;		/* other ifp of pair. */
-	int			 num_queues;
-	struct epair_queue	*queues;
-	struct ifmedia		 media;		/* Media config (fake). */
-	STAILQ_ENTRY(epair_softc) entry;
+	struct ifnet	*ifp;		/* This ifp. */
+	struct ifnet	*oifp;		/* other ifp of pair. */
+	struct ifmedia	media;		/* Media config (fake). */
+	u_int		refcount;	/* # of mbufs in flight. */
+	u_int		cpuid;		/* CPU ID assigned upon creation. */
+	void		(*if_qflush)(struct ifnet *);
+					/* Original if_qflush routine. */
 };
 =

-struct epair_tasks_t {
-	int			 tasks;
-	struct taskqueue	 *tq[MAXCPU];
+/*
+ * Per-CPU list of ifps with data in the ifq that needs to be flushed
+ * to the netisr ``hw'' queue before we allow any further direct queuing=

+ * to the ``hw'' queue.
+ */
+struct epair_ifp_drain {
+	STAILQ_ENTRY(epair_ifp_drain)	ifp_next;
+	struct ifnet			*ifp;
 };
+STAILQ_HEAD(eid_list, epair_ifp_drain);
+
+#define	EPAIR_LOCK_INIT(dpcpu)		mtx_init(&(dpcpu)->if_epair_mtx, \
+					    "if_epair", NULL, MTX_DEF)
+#define	EPAIR_LOCK_DESTROY(dpcpu)	mtx_destroy(&(dpcpu)->if_epair_mtx)
+#define	EPAIR_LOCK_ASSERT(dpcpu)	mtx_assert(&(dpcpu)->if_epair_mtx, \
+					    MA_OWNED)
+#define	EPAIR_LOCK(dpcpu)		mtx_lock(&(dpcpu)->if_epair_mtx)
+#define	EPAIR_UNLOCK(dpcpu)		mtx_unlock(&(dpcpu)->if_epair_mtx)
+
+#ifdef INVARIANTS
+#define	EPAIR_REFCOUNT_INIT(r, v)	refcount_init((r), (v))
+#define	EPAIR_REFCOUNT_AQUIRE(r)	refcount_acquire((r))
+#define	EPAIR_REFCOUNT_RELEASE(r)	refcount_release((r))
+#define	EPAIR_REFCOUNT_ASSERT(a, p)	KASSERT(a, p)
+#else
+#define	EPAIR_REFCOUNT_INIT(r, v)
+#define	EPAIR_REFCOUNT_AQUIRE(r)
+#define	EPAIR_REFCOUNT_RELEASE(r)
+#define	EPAIR_REFCOUNT_ASSERT(a, p)
+#endif
 =

-static struct epair_tasks_t epair_tasks;
+static MALLOC_DEFINE(M_EPAIR, epairname,
+    "Pair of virtual cross-over connected Ethernet-like interfaces");
+
+VNET_DEFINE_STATIC(struct if_clone *, epair_cloner);
+#define	V_epair_cloner	VNET(epair_cloner)
+
+/*
+ * DPCPU area and functions.
+ */
+struct epair_dpcpu {
+	struct mtx	if_epair_mtx;		/* Per-CPU locking. */
+	int		epair_drv_flags;	/* Per-CPU ``hw'' drv flags. */
+	struct eid_list	epair_ifp_drain_list;	/* Per-CPU list of ifps with
+						 * data in the ifq. */
+};
+DPCPU_DEFINE(struct epair_dpcpu, epair_dpcpu);
 =

 static void
 epair_clear_mbuf(struct mbuf *m)
@@ -142,199 +201,313 @@ epair_clear_mbuf(struct mbuf *m)
 }
 =

 static void
-epair_if_input(struct epair_softc *sc, struct epair_queue *q, int ridx)
+epair_dpcpu_init(void)
 {
-	struct epoch_tracker et;
-	struct ifnet *ifp;
-	struct mbuf *m;
+	struct epair_dpcpu *epair_dpcpu;
+	struct eid_list *s;
+	u_int cpuid;
+
+	CPU_FOREACH(cpuid) {
+		epair_dpcpu =3D DPCPU_ID_PTR(cpuid, epair_dpcpu);
+
+		/* Initialize per-cpu lock. */
+		EPAIR_LOCK_INIT(epair_dpcpu);
+
+		/* Driver flags are per-cpu as are our netisr "hw" queues. */
+		epair_dpcpu->epair_drv_flags =3D 0;
+
+		/*
+		 * Initialize per-cpu drain list.
+		 * Manually do what STAILQ_HEAD_INITIALIZER would do.
+		 */
+		s =3D &epair_dpcpu->epair_ifp_drain_list;
+		s->stqh_first =3D NULL;
+		s->stqh_last =3D &s->stqh_first;
+	} =

+}
 =

-	ifp =3D sc->ifp;
-	NET_EPOCH_ENTER_ET(et);
-	CURVNET_SET(ifp->if_vnet);
-	while (! buf_ring_empty(q->rxring[ridx])) {
-		m =3D buf_ring_dequeue_mc(q->rxring[ridx]);
-		if (m =3D=3D NULL)
-			continue;
+static void
+epair_dpcpu_detach(void)
+{
+	struct epair_dpcpu *epair_dpcpu;
+	u_int cpuid;
 =

-		MPASS((m->m_pkthdr.csum_flags & CSUM_SND_TAG) =3D=3D 0);
-		(*ifp->if_input)(ifp, m);
+	CPU_FOREACH(cpuid) {
+		epair_dpcpu =3D DPCPU_ID_PTR(cpuid, epair_dpcpu);
+
+		/* Destroy per-cpu lock. */
+		EPAIR_LOCK_DESTROY(epair_dpcpu);
 	}
-	CURVNET_RESTORE();
-	NET_EPOCH_EXIT_ET(et);
 }
 =

-static void
-epair_tx_start_deferred(void *arg, int pending)
+/*
+ * Helper functions.
+ */
+static u_int
+cpuid_from_ifp(struct ifnet *ifp)
 {
-	struct epair_queue *q =3D (struct epair_queue *)arg;
-	struct epair_softc *sc =3D q->sc;
-	int ridx, nidx;
-
-	if_ref(sc->ifp);
-	ridx =3D atomic_load_int(&q->ridx);
-	do {
-		nidx =3D (ridx =3D=3D 0) ? 1 : 0;
-	} while (!atomic_fcmpset_int(&q->ridx, &ridx, nidx));
-	epair_if_input(sc, q, ridx);
-
-	atomic_clear_long(&q->state, (1 << BIT_QUEUE_TASK));
-	if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
-		taskqueue_enqueue(epair_tasks.tq[q->id], &q->tx_task);
-
-	if_rele(sc->ifp);
+	struct epair_softc *sc;
+
+	if (ifp =3D=3D NULL)
+		return (0);
+	sc =3D ifp->if_softc;
+
+	return (sc->cpuid);
 }
 =

-static int
-epair_menq(struct mbuf *m, struct epair_softc *osc)
+/*
+ * Netisr handler functions.
+ */
+static void
+epair_nh_sintr(struct mbuf *m)
 {
-	struct ifnet *ifp, *oifp;
-	int len, ret;
-	int ridx;
-	short mflags;
-	struct epair_queue *q =3D NULL;
-	uint32_t bucket;
-#ifdef RSS
-	struct ether_header *eh;
-#endif
+	struct ifnet *ifp;
+	struct epair_softc *sc __unused;
 =

-	/*
-	 * I know this looks weird. We pass the "other sc" as we need that one
-	 * and can get both ifps from it as well.
-	 */
-	oifp =3D osc->ifp;
-	ifp =3D osc->oifp;
+	ifp =3D m->m_pkthdr.rcvif;
+	(*ifp->if_input)(ifp, m);
+	sc =3D ifp->if_softc;
+	EPAIR_REFCOUNT_RELEASE(&sc->refcount);
+	EPAIR_REFCOUNT_ASSERT((int)sc->refcount >=3D 1,
+	    ("%s: ifp=3D%p sc->refcount not >=3D 1: %d",
+	    __func__, ifp, sc->refcount));
+	DPRINTF("ifp=3D%p refcount=3D%u\n", ifp, sc->refcount);
+}
 =

-	M_ASSERTPKTHDR(m);
-	epair_clear_mbuf(m);
-	if_setrcvif(m, oifp);
-	M_SETFIB(m, oifp->if_fib);
+static struct mbuf *
+epair_nh_m2cpuid(struct mbuf *m, uintptr_t source, u_int *cpuid)
+{
 =

-	/* Save values as once the mbuf is queued, it's not ours anymore. */
-	len =3D m->m_pkthdr.len;
-	mflags =3D m->m_flags;
+	*cpuid =3D cpuid_from_ifp(m->m_pkthdr.rcvif);
 =

-	MPASS(m->m_nextpkt =3D=3D NULL);
-	MPASS((m->m_pkthdr.csum_flags & CSUM_SND_TAG) =3D=3D 0);
+	return (m);
+}
 =

-#ifdef RSS
-	ret =3D rss_m2bucket(m, &bucket);
-	if (ret) {
-		/* Actually hash the packet. */
-		eh =3D mtod(m, struct ether_header *);
+static void
+epair_nh_drainedcpu(u_int cpuid)
+{
+	struct epair_dpcpu *epair_dpcpu;
+	struct epair_ifp_drain *elm, *tvar;
+	struct ifnet *ifp;
 =

-		switch (ntohs(eh->ether_type)) {
-#ifdef INET
-		case ETHERTYPE_IP:
-			rss_soft_m2cpuid_v4(m, 0, &bucket);
-			break;
-#endif
-#ifdef INET6
-		case ETHERTYPE_IPV6:
-			rss_soft_m2cpuid_v6(m, 0, &bucket);
-			break;
-#endif
-		default:
-			bucket =3D 0;
+	epair_dpcpu =3D DPCPU_ID_PTR(cpuid, epair_dpcpu);
+	EPAIR_LOCK(epair_dpcpu);
+	/*
+	 * Assume our "hw" queue and possibly ifq will be emptied
+	 * again. In case we will overflow the "hw" queue while
+	 * draining, epair_start_locked will set IFF_DRV_OACTIVE
+	 * again and we will stop and return.
+	 */
+	STAILQ_FOREACH_SAFE(elm, &epair_dpcpu->epair_ifp_drain_list,
+	    ifp_next, tvar) {
+		ifp =3D elm->ifp;
+		epair_dpcpu->epair_drv_flags &=3D ~IFF_DRV_OACTIVE;
+		ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE;
+		epair_start_locked(ifp);
+
+		IFQ_LOCK(&ifp->if_snd);
+		if (IFQ_IS_EMPTY(&ifp->if_snd)) {
+			struct epair_softc *sc __unused;
+
+			STAILQ_REMOVE(&epair_dpcpu->epair_ifp_drain_list,
+			    elm, epair_ifp_drain, ifp_next);
+			/* The cached ifp goes off the list. */
+			sc =3D ifp->if_softc;
+			EPAIR_REFCOUNT_RELEASE(&sc->refcount);
+			EPAIR_REFCOUNT_ASSERT((int)sc->refcount >=3D 1,
+			    ("%s: ifp=3D%p sc->refcount not >=3D 1: %d",
+			    __func__, ifp, sc->refcount));
+			free(elm, M_EPAIR);
+		}
+		IFQ_UNLOCK(&ifp->if_snd);
+
+		if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) !=3D 0) {
+			/* Our "hw"q overflew again. */
+			epair_dpcpu->epair_drv_flags |=3D IFF_DRV_OACTIVE;
+			DPRINTF("hw queue length overflow at %u\n",
+			    epair_nh.nh_qlimit);
 			break;
 		}
 	}
-	bucket %=3D osc->num_queues;
-#else
-	bucket =3D 0;
-#endif
-	q =3D &osc->queues[bucket];
-
-	atomic_set_long(&q->state, (1 << BIT_MBUF_QUEUED));
-	ridx =3D atomic_load_int(&q->ridx);
-	ret =3D buf_ring_enqueue(q->rxring[ridx], m);
-	if (ret !=3D 0) {
-		/* Ring is full. */
-		if_inc_counter(ifp, IFCOUNTER_OQDROPS, 1);
-		m_freem(m);
-		return (0);
+	EPAIR_UNLOCK(epair_dpcpu);
+}
+
+/*
+ * Network interface (`if') related functions.
+ */
+static void
+epair_remove_ifp_from_draining(struct ifnet *ifp)
+{
+	struct epair_dpcpu *epair_dpcpu;
+	struct epair_ifp_drain *elm, *tvar;
+	u_int cpuid;
+
+	CPU_FOREACH(cpuid) {
+		epair_dpcpu =3D DPCPU_ID_PTR(cpuid, epair_dpcpu);
+		EPAIR_LOCK(epair_dpcpu);
+		STAILQ_FOREACH_SAFE(elm, &epair_dpcpu->epair_ifp_drain_list,
+		    ifp_next, tvar) {
+			if (ifp =3D=3D elm->ifp) {
+				struct epair_softc *sc __unused;
+
+				STAILQ_REMOVE(
+				    &epair_dpcpu->epair_ifp_drain_list, elm,
+				    epair_ifp_drain, ifp_next);
+				/* The cached ifp goes off the list. */
+				sc =3D ifp->if_softc;
+				EPAIR_REFCOUNT_RELEASE(&sc->refcount);
+				EPAIR_REFCOUNT_ASSERT((int)sc->refcount >=3D 1,
+				    ("%s: ifp=3D%p sc->refcount not >=3D 1: %d",
+				    __func__, ifp, sc->refcount));
+				free(elm, M_EPAIR);
+			}
+		}
+		EPAIR_UNLOCK(epair_dpcpu);
 	}
+}
 =

-	if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);
-	/*
-	 * IFQ_HANDOFF_ADJ/ip_handoff() update statistics,
-	 * but as we bypass all this we have to duplicate
-	 * the logic another time.
-	 */
-	if_inc_counter(ifp, IFCOUNTER_OBYTES, len);
-	if (mflags & (M_BCAST|M_MCAST))
-		if_inc_counter(ifp, IFCOUNTER_OMCASTS, 1);
-	/* Someone else received the packet. */
-	if_inc_counter(oifp, IFCOUNTER_IPACKETS, 1);
+static int
+epair_add_ifp_for_draining(struct ifnet *ifp)
+{
+	struct epair_dpcpu *epair_dpcpu;
+	struct epair_softc *sc;
+	struct epair_ifp_drain *elm =3D NULL;
 =

-	if (!atomic_testandset_long(&q->state, BIT_QUEUE_TASK))
-		taskqueue_enqueue(epair_tasks.tq[bucket], &q->tx_task);
+	sc =3D ifp->if_softc;
+	epair_dpcpu =3D DPCPU_ID_PTR(sc->cpuid, epair_dpcpu);
+	EPAIR_LOCK_ASSERT(epair_dpcpu);
+	STAILQ_FOREACH(elm, &epair_dpcpu->epair_ifp_drain_list, ifp_next)
+		if (elm->ifp =3D=3D ifp)
+			break;
+	/* If the ifp is there already, return success. */
+	if (elm !=3D NULL)
+		return (0);
+
+	elm =3D malloc(sizeof(struct epair_ifp_drain), M_EPAIR, M_NOWAIT|M_ZERO=
);
+	if (elm =3D=3D NULL)
+		return (ENOMEM);
+
+	elm->ifp =3D ifp;
+	/* Add a reference for the ifp pointer on the list. */
+	EPAIR_REFCOUNT_AQUIRE(&sc->refcount);
+	STAILQ_INSERT_TAIL(&epair_dpcpu->epair_ifp_drain_list, elm, ifp_next);
 =

 	return (0);
 }
 =

 static void
-epair_start(struct ifnet *ifp)
+epair_start_locked(struct ifnet *ifp)
 {
+	struct epair_dpcpu *epair_dpcpu;
 	struct mbuf *m;
 	struct epair_softc *sc;
 	struct ifnet *oifp;
+	int error;
+
+	DPRINTF("ifp=3D%p\n", ifp);
+	sc =3D ifp->if_softc;
+	epair_dpcpu =3D DPCPU_ID_PTR(sc->cpuid, epair_dpcpu);
+	EPAIR_LOCK_ASSERT(epair_dpcpu);
+
+	if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0)
+		return;
+	if ((ifp->if_flags & IFF_UP) =3D=3D 0)
+		return;
 =

 	/*
 	 * We get packets here from ether_output via if_handoff()
 	 * and need to put them into the input queue of the oifp
-	 * and will put the packet into the receive-queue (rxq) of the
-	 * other interface (oifp) of our pair.
+	 * and call oifp->if_input() via netisr/epair_sintr().
 	 */
-	sc =3D ifp->if_softc;
 	oifp =3D sc->oifp;
 	sc =3D oifp->if_softc;
 	for (;;) {
 		IFQ_DEQUEUE(&ifp->if_snd, m);
 		if (m =3D=3D NULL)
 			break;
-		M_ASSERTPKTHDR(m);
 		BPF_MTAP(ifp, m);
 =

-		/* In case either interface is not usable drop the packet. */
-		if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0 ||
-		    (ifp->if_flags & IFF_UP) =3D=3D 0 ||
-		    (oifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0 ||
-		    (oifp->if_flags & IFF_UP) =3D=3D 0) {
+		/*
+		 * In case the outgoing interface is not usable,
+		 * drop the packet.
+		 */
+		if ((oifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0 ||
+		    (oifp->if_flags & IFF_UP) =3D=3D0) {
+			if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
 			m_freem(m);
 			continue;
 		}
-
-		(void) epair_menq(m, sc);
+		DPRINTF("packet %s -> %s\n", ifp->if_xname, oifp->if_xname);
+
+		epair_clear_mbuf(m);
+
+		/*
+		 * Add a reference so the interface cannot go while the
+		 * packet is in transit as we rely on rcvif to stay valid.
+		 */
+		EPAIR_REFCOUNT_AQUIRE(&sc->refcount);
+		m->m_pkthdr.rcvif =3D oifp;
+		CURVNET_SET_QUIET(oifp->if_vnet);
+		error =3D netisr_queue(NETISR_EPAIR, m);
+		CURVNET_RESTORE();
+		if (!error) {
+			if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);
+			/* Someone else received the packet. */
+			if_inc_counter(oifp, IFCOUNTER_IPACKETS, 1);
+		} else {
+			/* The packet was freed already. */
+			epair_dpcpu->epair_drv_flags |=3D IFF_DRV_OACTIVE;
+			ifp->if_drv_flags |=3D IFF_DRV_OACTIVE;
+			(void) epair_add_ifp_for_draining(ifp);
+			if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
+			EPAIR_REFCOUNT_RELEASE(&sc->refcount);
+			EPAIR_REFCOUNT_ASSERT((int)sc->refcount >=3D 1,
+			    ("%s: ifp=3D%p sc->refcount not >=3D 1: %d",
+			    __func__, oifp, sc->refcount));
+		}
 	}
 }
 =

+static void
+epair_start(struct ifnet *ifp)
+{
+	struct epair_dpcpu *epair_dpcpu;
+
+	epair_dpcpu =3D DPCPU_ID_PTR(cpuid_from_ifp(ifp), epair_dpcpu);
+	EPAIR_LOCK(epair_dpcpu);
+	epair_start_locked(ifp);
+	EPAIR_UNLOCK(epair_dpcpu);
+}
+
 static int
-epair_transmit(struct ifnet *ifp, struct mbuf *m)
+epair_transmit_locked(struct ifnet *ifp, struct mbuf *m)
 {
+	struct epair_dpcpu *epair_dpcpu;
 	struct epair_softc *sc;
 	struct ifnet *oifp;
 	int error, len;
 	short mflags;
 =

+	DPRINTF("ifp=3D%p m=3D%p\n", ifp, m);
+	sc =3D ifp->if_softc;
+	epair_dpcpu =3D DPCPU_ID_PTR(sc->cpuid, epair_dpcpu);
+	EPAIR_LOCK_ASSERT(epair_dpcpu);
+
 	if (m =3D=3D NULL)
 		return (0);
-
-	M_ASSERTPKTHDR(m);
-
+	=

 	/*
 	 * We are not going to use the interface en/dequeue mechanism
 	 * on the TX side. We are called from ether_output_frame()
-	 * and will put the packet into the receive-queue (rxq) of the
-	 * other interface (oifp) of our pair.
+	 * and will put the packet into the incoming queue of the
+	 * other interface of our pair via the netsir.
 	 */
 	if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0) {
 		m_freem(m);
-		if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
 		return (ENXIO);
 	}
 	if ((ifp->if_flags & IFF_UP) =3D=3D 0) {
 		m_freem(m);
-		if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
 		return (ENETDOWN);
 	}
 =

@@ -344,16 +517,16 @@ epair_transmit(struct ifnet *ifp, struct mbuf *m)
 	 * In case the outgoing interface is not usable,
 	 * drop the packet.
 	 */
-	sc =3D ifp->if_softc;
 	oifp =3D sc->oifp;
 	if ((oifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0 ||
-	    (oifp->if_flags & IFF_UP) =3D=3D 0) {
+	    (oifp->if_flags & IFF_UP) =3D=3D0) {
 		if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
 		m_freem(m);
 		return (0);
 	}
 	len =3D m->m_pkthdr.len;
 	mflags =3D m->m_flags;
+	DPRINTF("packet %s -> %s\n", ifp->if_xname, oifp->if_xname);
 =

 #ifdef ALTQ
 	/* Support ALTQ via the classic if_start() path. */
@@ -367,17 +540,99 @@ epair_transmit(struct ifnet *ifp, struct mbuf *m)
 			if_inc_counter(ifp, IFCOUNTER_OBYTES, len);
 			if (mflags & (M_BCAST|M_MCAST))
 				if_inc_counter(ifp, IFCOUNTER_OMCASTS, 1);
-			epair_start(ifp);
+			=

+			if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) =3D=3D 0)
+				epair_start_locked(ifp);
+			else
+				(void)epair_add_ifp_for_draining(ifp);
 		}
 		return (error);
 	}
 	IF_UNLOCK(&ifp->if_snd);
 #endif
 =

-	error =3D epair_menq(m, oifp->if_softc);
+	if ((epair_dpcpu->epair_drv_flags & IFF_DRV_OACTIVE) !=3D 0) {
+		/*
+		 * Our hardware queue is full, try to fall back
+		 * queuing to the ifq but do not call ifp->if_start.
+		 * Either we are lucky or the packet is gone.
+		 */
+		IFQ_ENQUEUE(&ifp->if_snd, m, error);
+		if (!error)
+			(void)epair_add_ifp_for_draining(ifp);
+		return (error);
+	}
+
+	epair_clear_mbuf(m);
+
+	sc =3D oifp->if_softc;
+	/*
+	 * Add a reference so the interface cannot go while the
+	 * packet is in transit as we rely on rcvif to stay valid.
+	 */
+	EPAIR_REFCOUNT_AQUIRE(&sc->refcount);
+	m->m_pkthdr.rcvif =3D oifp;
+	CURVNET_SET_QUIET(oifp->if_vnet);
+	error =3D netisr_queue(NETISR_EPAIR, m);
+	CURVNET_RESTORE();
+	if (!error) {
+		if_inc_counter(ifp, IFCOUNTER_OPACKETS, 1);
+		/*
+		 * IFQ_HANDOFF_ADJ/ip_handoff() update statistics,
+		 * but as we bypass all this we have to duplicate
+		 * the logic another time.
+		 */
+		if_inc_counter(ifp, IFCOUNTER_OBYTES, len);
+		if (mflags & (M_BCAST|M_MCAST))
+			if_inc_counter(ifp, IFCOUNTER_OMCASTS, 1);
+		/* Someone else received the packet. */
+		if_inc_counter(oifp, IFCOUNTER_IPACKETS, 1);
+	} else {
+		/* The packet was freed already. */
+		epair_dpcpu->epair_drv_flags |=3D IFF_DRV_OACTIVE;
+		ifp->if_drv_flags |=3D IFF_DRV_OACTIVE;
+		if_inc_counter(ifp, IFCOUNTER_OERRORS, 1);
+		EPAIR_REFCOUNT_RELEASE(&sc->refcount);
+		EPAIR_REFCOUNT_ASSERT((int)sc->refcount >=3D 1,
+		    ("%s: ifp=3D%p sc->refcount not >=3D 1: %d",
+		    __func__, oifp, sc->refcount));
+	}
+
 	return (error);
 }
 =

+static int
+epair_transmit(struct ifnet *ifp, struct mbuf *m)
+{
+	struct epair_dpcpu *epair_dpcpu;
+	int error;
+
+	epair_dpcpu =3D DPCPU_ID_PTR(cpuid_from_ifp(ifp), epair_dpcpu);
+	EPAIR_LOCK(epair_dpcpu);
+	error =3D epair_transmit_locked(ifp, m);
+	EPAIR_UNLOCK(epair_dpcpu);
+	return (error);
+}
+
+static void
+epair_qflush(struct ifnet *ifp)
+{
+	struct epair_softc *sc;
+	=

+	sc =3D ifp->if_softc;
+	KASSERT(sc !=3D NULL, ("%s: ifp=3D%p, epair_softc gone? sc=3D%p\n",
+	    __func__, ifp, sc));
+	/*
+	 * Remove this ifp from all backpointer lists. The interface will not
+	 * usable for flushing anyway nor should it have anything to flush
+	 * after if_qflush().
+	 */
+	epair_remove_ifp_from_draining(ifp);
+
+	if (sc->if_qflush)
+		sc->if_qflush(ifp);
+}
+
 static int
 epair_media_change(struct ifnet *ifp __unused)
 {
@@ -446,6 +701,8 @@ epair_clone_match(struct if_clone *ifc, const char *n=
ame)
 {
 	const char *cp;
 =

+	DPRINTF("name=3D'%s'\n", name);
+
 	/*
 	 * Our base name is epair.
 	 * Our interfaces will be named epair[ab].
@@ -534,29 +791,17 @@ epair_clone_create(struct if_clone *ifc, char *name=
, size_t len, caddr_t params)
 =

 	/* Allocate memory for both [ab] interfaces */
 	sca =3D malloc(sizeof(struct epair_softc), M_EPAIR, M_WAITOK | M_ZERO);=

+	EPAIR_REFCOUNT_INIT(&sca->refcount, 1);
 	sca->ifp =3D if_alloc(IFT_ETHER);
-	sca->num_queues =3D epair_tasks.tasks;
 	if (sca->ifp =3D=3D NULL) {
 		free(sca, M_EPAIR);
 		ifc_free_unit(ifc, unit);
 		return (ENOSPC);
 	}
-	sca->queues =3D mallocarray(sca->num_queues, sizeof(struct epair_queue)=
,
-	    M_EPAIR, M_WAITOK);
-	for (int i =3D 0; i < sca->num_queues; i++) {
-		struct epair_queue *q =3D &sca->queues[i];
-		q->id =3D i;
-		q->rxring[0] =3D buf_ring_alloc(RXRSIZE, M_EPAIR, M_WAITOK, NULL);
-		q->rxring[1] =3D buf_ring_alloc(RXRSIZE, M_EPAIR, M_WAITOK, NULL);
-		q->ridx =3D 0;
-		q->state =3D 0;
-		q->sc =3D sca;
-		TASK_INIT(&q->tx_task, 0, epair_tx_start_deferred, q);
-	}
 =

 	scb =3D malloc(sizeof(struct epair_softc), M_EPAIR, M_WAITOK | M_ZERO);=

+	EPAIR_REFCOUNT_INIT(&scb->refcount, 1);
 	scb->ifp =3D if_alloc(IFT_ETHER);
-	scb->num_queues =3D epair_tasks.tasks;
 	if (scb->ifp =3D=3D NULL) {
 		free(scb, M_EPAIR);
 		if_free(sca->ifp);
@@ -564,33 +809,23 @@ epair_clone_create(struct if_clone *ifc, char *name=
, size_t len, caddr_t params)
 		ifc_free_unit(ifc, unit);
 		return (ENOSPC);
 	}
-	scb->queues =3D mallocarray(scb->num_queues, sizeof(struct epair_queue)=
,
-	    M_EPAIR, M_WAITOK);
-	for (int i =3D 0; i < scb->num_queues; i++) {
-		struct epair_queue *q =3D &scb->queues[i];
-		q->id =3D i;
-		q->rxring[0] =3D buf_ring_alloc(RXRSIZE, M_EPAIR, M_WAITOK, NULL);
-		q->rxring[1] =3D buf_ring_alloc(RXRSIZE, M_EPAIR, M_WAITOK, NULL);
-		q->ridx =3D 0;
-		q->state =3D 0;
-		q->sc =3D scb;
-		TASK_INIT(&q->tx_task, 0, epair_tx_start_deferred, q);
-	}
-
+	=

 	/*
 	 * Cross-reference the interfaces so we will be able to free both.
 	 */
 	sca->oifp =3D scb->ifp;
 	scb->oifp =3D sca->ifp;
 =

-	EPAIR_LOCK();
-#ifdef SMP
-	/* Get an approximate distribution. */
-	hash =3D next_index % mp_ncpus;
-#else
-	hash =3D 0;
-#endif
-	EPAIR_UNLOCK();
+	/*
+	 * Calculate the cpuid for netisr queueing based on the
+	 * ifIndex of the interfaces. As long as we cannot configure
+	 * this or use cpuset information easily we cannot guarantee
+	 * cache locality but we can at least allow parallelism.
+	 */
+	sca->cpuid =3D
+	    netisr_get_cpuid(sca->ifp->if_index);
+	scb->cpuid =3D
+	    netisr_get_cpuid(scb->ifp->if_index);
 =

 	/* Initialise pseudo media types. */
 	ifmedia_init(&sca->media, 0, epair_media_change, epair_media_status);
@@ -627,14 +862,12 @@ epair_clone_create(struct if_clone *ifc, char *name=
, size_t len, caddr_t params)
 	if (hostid =3D=3D 0) =

 		arc4rand(&hostid, sizeof(hostid), 0);
 =

-	EPAIR_LOCK();
 	if (ifp->if_index > next_index)
 		next_index =3D ifp->if_index;
 	else
 		next_index++;
 =

 	key[0] =3D (uint32_t)next_index;
-	EPAIR_UNLOCK();
 	key[1] =3D (uint32_t)(hostid & 0xffffffff);
 	key[2] =3D (uint32_t)((hostid >> 32) & 0xfffffffff);
 	hash =3D jenkins_hash32(key, 3, 0);
@@ -643,8 +876,10 @@ epair_clone_create(struct if_clone *ifc, char *name,=
 size_t len, caddr_t params)
 	memcpy(&eaddr[1], &hash, 4);
 	eaddr[5] =3D 0x0a;
 	ether_ifattach(ifp, eaddr);
-	ifp->if_baudrate =3D IF_Gbps(10);	/* arbitrary maximum */
+	sca->if_qflush =3D ifp->if_qflush;
+	ifp->if_qflush =3D epair_qflush;
 	ifp->if_transmit =3D epair_transmit;
+	ifp->if_baudrate =3D IF_Gbps(10);	/* arbitrary maximum */
 =

 	/* Swap the name and finish initialization of interface b. */
 	*dp =3D 'b';
@@ -669,43 +904,27 @@ epair_clone_create(struct if_clone *ifc, char *name=
, size_t len, caddr_t params)
 	strlcpy(name, scb->ifp->if_xname, len);
 	epair_clone_add(ifc, scb);
 =

-	ifp->if_baudrate =3D IF_Gbps(10);	/* arbitrary maximum */
+	scb->if_qflush =3D ifp->if_qflush;
+	ifp->if_qflush =3D epair_qflush;
 	ifp->if_transmit =3D epair_transmit;
+	ifp->if_baudrate =3D IF_Gbps(10);	/* arbitrary maximum */
 =

 	/*
 	 * Restore name to a as the ifp for this will go into the
 	 * cloner list for the initial call.
 	 */
 	strlcpy(name, sca->ifp->if_xname, len);
+	DPRINTF("name=3D'%s/%db' created sca=3D%p scb=3D%p\n", name, unit, sca,=
 scb);
 =

 	/* Tell the world, that we are ready to rock. */
 	sca->ifp->if_drv_flags |=3D IFF_DRV_RUNNING;
-	if_link_state_change(sca->ifp, LINK_STATE_UP);
 	scb->ifp->if_drv_flags |=3D IFF_DRV_RUNNING;
+	if_link_state_change(sca->ifp, LINK_STATE_UP);
 	if_link_state_change(scb->ifp, LINK_STATE_UP);
 =

 	return (0);
 }
 =

-static void
-epair_drain_rings(struct epair_softc *sc)
-{
-	int ridx;
-	struct mbuf *m;
-
-	for (ridx =3D 0; ridx < 2; ridx++) {
-		for (int i =3D 0; i < sc->num_queues; i++) {
-			struct epair_queue *q =3D &sc->queues[i];
-			do {
-				m =3D buf_ring_dequeue_sc(q->rxring[ridx]);
-				if (m =3D=3D NULL)
-					break;
-				m_freem(m);
-			} while (1);
-		}
-	}
-}
-
 static int
 epair_clone_destroy(struct if_clone *ifc, struct ifnet *ifp)
 {
@@ -713,6 +932,8 @@ epair_clone_destroy(struct if_clone *ifc, struct ifne=
t *ifp)
 	struct epair_softc *sca, *scb;
 	int unit, error;
 =

+	DPRINTF("ifp=3D%p\n", ifp);
+
 	/*
 	 * In case we called into if_clone_destroyif() ourselves
 	 * again to remove the second interface, the softc will be
@@ -726,18 +947,27 @@ epair_clone_destroy(struct if_clone *ifc, struct if=
net *ifp)
 	oifp =3D sca->oifp;
 	scb =3D oifp->if_softc;
 =

-	/* Frist get the interfaces down and detached. */
+	DPRINTF("ifp=3D%p oifp=3D%p\n", ifp, oifp);
 	if_link_state_change(ifp, LINK_STATE_DOWN);
-	ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING;
 	if_link_state_change(oifp, LINK_STATE_DOWN);
+	ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING;
 	oifp->if_drv_flags &=3D ~IFF_DRV_RUNNING;
 =

-	ether_ifdetach(ifp);
-	ether_ifdetach(oifp);
-
-	/* Third free any queued packets and all the resources. */
+	/*
+	 * Get rid of our second half. As the other of the two
+	 * interfaces may reside in a different vnet, we need to
+	 * switch before freeing them.
+	 */
 	CURVNET_SET_QUIET(oifp->if_vnet);
-	epair_drain_rings(scb);
+	ether_ifdetach(oifp);
+	/*
+	 * Wait for all packets to be dispatched to if_input.
+	 * The numbers can only go down as the interface is
+	 * detached so there is no need to use atomics.
+	 */
+	DPRINTF("scb refcnt=3D%u\n", scb->refcount);
+	EPAIR_REFCOUNT_ASSERT(scb->refcount =3D=3D 1,
+	    ("%s: ifp=3D%p scb->refcount!=3D1: %d", __func__, oifp, scb->refcou=
nt));
 	oifp->if_softc =3D NULL;
 	error =3D if_clone_destroyif(ifc, oifp);
 	if (error)
@@ -745,27 +975,19 @@ epair_clone_destroy(struct if_clone *ifc, struct if=
net *ifp)
 		    __func__, error);
 	if_free(oifp);
 	ifmedia_removeall(&scb->media);
-	for (int i =3D 0; i < scb->num_queues; i++) {
-		struct epair_queue *q =3D &scb->queues[i];
-		buf_ring_free(q->rxring[0], M_EPAIR);
-		buf_ring_free(q->rxring[1], M_EPAIR);
-	}
-	free(scb->queues, M_EPAIR);
 	free(scb, M_EPAIR);
 	CURVNET_RESTORE();
 =

-	epair_drain_rings(sca);
+	ether_ifdetach(ifp);
+	/*
+	 * Wait for all packets to be dispatched to if_input.
+	 */
+	DPRINTF("sca refcnt=3D%u\n", sca->refcount);
+	EPAIR_REFCOUNT_ASSERT(sca->refcount =3D=3D 1,
+	    ("%s: ifp=3D%p sca->refcount!=3D1: %d", __func__, ifp, sca->refcoun=
t));
 	if_free(ifp);
 	ifmedia_removeall(&sca->media);
-	for (int i =3D 0; i < sca->num_queues; i++) {
-		struct epair_queue *q =3D &sca->queues[i];
-		buf_ring_free(q->rxring[0], M_EPAIR);
-		buf_ring_free(q->rxring[1], M_EPAIR);
-	}
-	free(sca->queues, M_EPAIR);
 	free(sca, M_EPAIR);
-
-	/* Last free the cloner unit. */
 	ifc_free_unit(ifc, unit);
 =

 	return (0);
@@ -777,6 +999,9 @@ vnet_epair_init(const void *unused __unused)
 =

 	V_epair_cloner =3D if_clone_advanced(epairname, 0,
 	    epair_clone_match, epair_clone_create, epair_clone_destroy);
+#ifdef VIMAGE
+	netisr_register_vnet(&epair_nh);
+#endif
 }
 VNET_SYSINIT(vnet_epair_init, SI_SUB_PSEUDO, SI_ORDER_ANY,
     vnet_epair_init, NULL);
@@ -785,84 +1010,43 @@ static void
 vnet_epair_uninit(const void *unused __unused)
 {
 =

+#ifdef VIMAGE
+	netisr_unregister_vnet(&epair_nh);
+#endif
 	if_clone_detach(V_epair_cloner);
 }
 VNET_SYSUNINIT(vnet_epair_uninit, SI_SUB_INIT_IF, SI_ORDER_ANY,
     vnet_epair_uninit, NULL);
 =

-static int
-epair_mod_init()
-{
-	char name[32];
-	epair_tasks.tasks =3D 0;
-
-#ifdef RSS
-	struct pcpu *pcpu;
-	int cpu;
-
-	CPU_FOREACH(cpu) {
-		cpuset_t cpu_mask;
-
-		/* Pin to this CPU so we get appropriate NUMA allocations. */
-		pcpu =3D pcpu_find(cpu);
-		thread_lock(curthread);
-		sched_bind(curthread, cpu);
-		thread_unlock(curthread);
-
-		snprintf(name, sizeof(name), "epair_task_%d", cpu);
-
-		epair_tasks.tq[cpu] =3D taskqueue_create(name, M_WAITOK,
-		    taskqueue_thread_enqueue,
-		    &epair_tasks.tq[cpu]);
-		CPU_SETOF(cpu, &cpu_mask);
-		taskqueue_start_threads_cpuset(&epair_tasks.tq[cpu], 1, PI_NET,
-		    &cpu_mask, "%s", name);
-
-		epair_tasks.tasks++;
-	}
-#else
-	snprintf(name, sizeof(name), "epair_task");
-
-	epair_tasks.tq[0] =3D taskqueue_create(name, M_WAITOK,
-	    taskqueue_thread_enqueue,
-	    &epair_tasks.tq[0]);
-	taskqueue_start_threads(&epair_tasks.tq[0], 1, PI_NET, "%s", name);
-
-	epair_tasks.tasks =3D 1;
-#endif
-
-	return (0);
-}
-
 static void
-epair_mod_cleanup()
+epair_uninit(const void *unused __unused)
 {
-
-	for (int i =3D 0; i < epair_tasks.tasks; i++) {
-		taskqueue_drain_all(epair_tasks.tq[i]);
-		taskqueue_free(epair_tasks.tq[i]);
-	}
+	netisr_unregister(&epair_nh);
+	epair_dpcpu_detach();
+	if (bootverbose)
+		printf("%s unloaded.\n", epairname);
 }
+SYSUNINIT(epair_uninit, SI_SUB_INIT_IF, SI_ORDER_MIDDLE,
+    epair_uninit, NULL);
 =

 static int
 epair_modevent(module_t mod, int type, void *data)
 {
-	int ret;
+	int qlimit;
 =

 	switch (type) {
 	case MOD_LOAD:
-		EPAIR_LOCK_INIT();
-		ret =3D epair_mod_init();
-		if (ret !=3D 0)
-			return (ret);
+		/* For now limit us to one global mutex and one inq. */
+		epair_dpcpu_init();
+		epair_nh.nh_qlimit =3D 42 * ifqmaxlen; /* 42 shall be the number. */
+		if (TUNABLE_INT_FETCH("net.link.epair.netisr_maxqlen", &qlimit))
+		    epair_nh.nh_qlimit =3D qlimit;
+		netisr_register(&epair_nh);
 		if (bootverbose)
-			printf("%s: %s initialized.\n", __func__, epairname);
+			printf("%s initialized.\n", epairname);
 		break;
 	case MOD_UNLOAD:
-		epair_mod_cleanup();
-		EPAIR_LOCK_DESTROY();
-		if (bootverbose)
-			printf("%s: %s unloaded.\n", __func__, epairname);
+		/* Handled in epair_uninit() */
 		break;
 	default:
 		return (EOPNOTSUPP);
@@ -877,4 +1061,4 @@ static moduledata_t epair_mod =3D {
 };
 =

 DECLARE_MODULE(if_epair, epair_mod, SI_SUB_PSEUDO, SI_ORDER_MIDDLE);
-MODULE_VERSION(if_epair, 3);
+MODULE_VERSION(if_epair, 1);
-- =

2.35.1


--=_MailMate_023E3E3C-1326-4075-96E1-440957B9BAB2_=--

From nobody Wed Mar 23 15:34:31 2022
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 00C7C11D5BD3
	for ; Wed, 23 Mar 2022 15:45:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNt3r1dLKz4yX4
	for ; Wed, 23 Mar 2022 15:45:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648050337; bh=/xSrbxUvOhrIHrhBK55v1OEtYrFw/jtCDuUVsQSu0ik=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=R4TuLh96IpL9wH1GCxKPSTg9lnFR5xV+qN1HxZZuSPScPIpJpRTC5xd3hxNPhBu49X2cNmwtz7/WCqLEhMg1RdWBa+LCLOmxEQG9e7R0s4jeUFewi3De0hCfobGeQIQil1F7EB3ksuycihHbFN8KcASerQlao6zOPeOLUZUMJgFkOxIWLNAA6gJ7nVT+haGhpLlJERUBOK5It/3kXL3mpP16OsK3/ytaJMp5roP00+QqkzKQaNjWj5MptQbUuHPI6146COrMIv5xjZTMgjOwmLj+90CYL87LObNJs5E9hvV0+wO1PF6xnjxuh2CT6PAYX6Op+ANKLxc2DEt6jQyy4g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648050337; bh=Fhigjci8vjp76DWdm49Ju9bhb30+feBj+PpEcO+KJ1w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LBFliILLMaA+r2SuagFbyBKAOx2hIvEsgstYWrKTnGFO4N0wMfkMjsevnmqoUSHn+f49QvI5vPOE/I1nUebIzCgPD6591L2+aMI9CYsIfjSjl1CmzFPkcWYQXhfCCRXbIZkS2k0nN2kN/gYEHvOjsf6HPh0OCEaMgBE74z0yfumBKs73ZjLxZa77OmQ1TiYQC50nijaiqSnpidNihxAX0DyboRvnfV95EtlhLLrGZPu/3D2OSphouApf7/1MlKRU/81OQK/gV+szGdydsT28eiWaGcxWWL+iPFDMXHlBHlPqRaFw0WEXpUeWHceKIW1f4EhARcwDMoi8xkFNG1bx2w==
X-YMail-OSG: plP_GbwVM1mHCFOq9.QjE8_09faqJVFEBhQv90Cn8Ettss.NB891ze8qJONm9qo
 wZnFJGWxFNcMTqzxP0aMHy0oxM2vmtQ9T75g8nwyH85J9DdrreOprn6YBlZ0bgRmEZARpQJ0aJS8
 ypY0hkb7z5MbCYUZ0mJw02eEqs0k.DHNzA67BheVKVm4Wl6vbInmsxfWGEPeV.VtesfbmPq7hl7T
 2zqrokP85iIo2.ZE.YnCFn6Gn3Jn.HIsYSr1iJR52kj4OHjTDo8eXTJMEOse3DMn5tP1xTMnK5JL
 JCeNFX6lREv3OgjxWNJMqTnKkEUk52SxSF9AjzRVHNGHRSFaVVA.h5cpd3y2LB2qItRONDuabsR0
 ELKIbyblw5N5PqvrxpKbzVC0SbSXCZB8D_xVA94M7cO5FP8t4qYf9VUUMWP8O.FErvwFG0hmH97.
 RdCtU.ctQi0kr4j4X.qZDzZG6RQa7LsaH_M.XdMlRTIAkpntN7QBrjF1_RUUP_tELfod3xC82Oau
 8KtrbScqF9c4wZnLLiITsf7IsxwCXfSKkwAF0Me0wRb7r_pc4atQr8SBUL.xNOU4OyjCs986tzxU
 PWuYTxPTd4VS96IGO3GDMhUq.5UBkRMO5VgRbvvtAHDVN2u31yz9R.n5aJC6NbNZqdOykLKGW5um
 E75BbHkGTL_jXSc3ujlRJmwk8aWMWPxc7N12y8TH8wduhq8zNB5FvgWY7uIYTuSZh6AOjaADXc6z
 h_bjRHkqZ4NTYNZ.VEreqhbxlZzb98qtY.kONQDoZeMeQYu9r4Fp2SEp8zxIgiitJJNMQbY5ROyn
 ujG0FOtUQGtoNx2HQSe.gWTnOV1oKj7TXj0UJu_nitjJbqe_VI1JPH8rZE3Xx63xQW0qpkrBk8KO
 SHDjb61h74zyZOYubhWw5pL8SCi1zXg34cHzlkV2eN4OdbWq0K71i5uBdywpDFfrv2WYBFiMlNtw
 Gx1WCtH5hdztk.VFPSQ9tTbIoESRWRcYuMzQoGStof1EWbmUYap5Q9BqDy1OiH5oFzmrkFf7CO90
 MaetRXhpdENZc1nZsgoWhyNwG9BkPfK4jpD9x.ElaJWUTZCHpdlmYshelsbAQrjjPXYQGzf3TORR
 kMCrAYfdUz.j6vSMB1ggzGiu..kq3xdBLQnoJ8W2ksCY7q3W_JdsjQm7NccCR_SKBQZXZUEWHdP4
 mtbv_MTEvQdi5.J3YT0r4_HPxAnmDYTL2EvH2J4Hna4dUUpIw7zxKix1Z.nwT2Tk0202Mtro2FBH
 l0mqf5ojUMQFlDrJHisVgiHvBWUTMEjRTiJhgHOZVuIOJ5Geb2nkW0Fauw4ziD8UxKVlIEQnCyOS
 iI6ISZDV7blVhuy4bJQxKHOpJxjp5t6fSv3A0r8PjIt6.ZvAYSzKO_qxcbyXfDMMeKkkv_VD7hfd
 jtIpw6W8_0WvkPf1Hco3jv7aWCc5a1Y.vtQKe3OvQ8nR3LqMfEdFpzW7pD4jXvxIrEeoBUkrNqlr
 ooppvgBYfW25HAoASYCYw1vqjiFngpheUiI8N9NDxxsavr1cCj4mhBGDYPL23CL8xf1ZJnhTa3Lx
 jPESnyR4nJZFZb4kqLa.jxTQgogAnYzOk4lspIP8Ca7_jzKMwxytF0H_2QdUnFMiRCjT.AYrAZq4
 jlkazuNpufP1XvmCjbJSYIXoB2JC_x3KTxA3DJLgwtuHMa2bGrAGsgZa2V3VTfNTFaTugaF0YOWH
 MvC1jFEX8fTAeq8GR6iHbLqqifRWL03otrFfsm_HrdUVkDPO.Xh43DqIDP69_y8jsJRC01hTu4lj
 wN.weqLJCOougoUmb83M7xV_EidsKruT3NNEprsT0tw_Z02ATSrsN2OPCtsPRaFAF9IOmr8Rj65J
 Au1S5ftwThBSZ89YcVCKGqIpsKCvEODGjkZlc_amORgfC6FJ8P2.ezinqrWOMV.phwXW.YwLTUiP
 M_O7y1M_FF9cxALNkYKj46jRSZnOrTdSg.W0hSxUr0F6Qez2_hxJSLsV6RO06CHY1RGbsdsUC8CB
 ZSGSnDdGpMiw5.fCFwWp6DQQr4911dx_Bl.7kDHY9.K.Q.JgcndEt_SwANJPI5zK_kXaL2mjGSQS
 dtrmXKTI.pO2rAqqkwgIUSacIviFcsXWHZTYLRJ0F0p1F97xQfILiGUyiyOy0MAIo5TY9fvBQFgy
 iOX3c320E24QOwC4rLa1E7JcIi2JwK6.oBfJkapzqcVdNYLmt6ufAflmXcJDIz83i.lSso6RgiM1
 RcHcbbkaACfv6MvuEp6JvBp20m_QlWxfKDknR7zoyZqklyWkbALTG6aEzE4QiSbKbIpb68874OX.
 7MfPMKEBp_F_enI.rIEbHHoTEyHtCqy91tvkI6NyTuC6ieRAqf_raXfbc2g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 15:45:37 +0000
Received: by hermes--canary-production-bf1-665cdb9985-x6p65 (VZM Hermes SMTP Server) with ESMTPA ID 13a231051e4e31f703dcdf29d14c6090;
          Wed, 23 Mar 2022 15:34:34 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
Date: Wed, 23 Mar 2022 08:34:31 -0700
Cc: "grembo@freebsd.org" ,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220323012657.GA82109@www.zefox.net>
 <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
 <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com>
 <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
To: Kristof Provost ,
 bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNt3r1dLKz4yX4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=R4TuLh96;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4241
Lines: 134

On 2022-Mar-23, at 03:51, Kristof Provost  wrote:

> Hi Mark,

Hello.

> On 23 Mar 2022, at 4:23, Mark Millard wrote:
>> On 2022-Mar-22, at 20:16, Mark Millard  wrote:
>>=20
>>> [Trying again after getting material from the wrong
>>> commit the first time.]
>>>=20
>>> On 2022-Mar-22, at 18:26, bob prohaska  wrote:
>>>=20
>>>> A Pi2 running
>>>> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 =
GENERIC  arm
>>>>=20
>>>> stops buildkernel with:
>>>> --- if_epair.o ---
>>>> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of =
function 'atomic_testandclear_long' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>>>>      if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED))
>>>>          ^
>>>>=20
>>>> Not sure if this is specific to the Raspberry Pi 2, it didn't show =
up on a pair of Pi3's
>>>> and a single Pi4. The system is still using svnlite, info reports
>>>> root@www:/usr/src # svnlite info
>>>> Path: .
>>>> Working Copy Root Path: /usr/src
>>>> URL: svn://svn.freebsd.org/base/stable/12
>>>> Relative URL: ^/stable/12
>>>> Repository Root: svn://svn.freebsd.org/base
>>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>>> Revision: 371771
>>>> Node Kind: directory
>>>> Schedule: normal
>>>> Last Changed Author: 0mp
>>>> Last Changed Rev: 371771
>>>> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)
>>>>=20
>>>>=20
>>>> Didn't see anything similar on bugs.freebsd.org, if it's worth a =
bug report or
>>>> there's a workaround please post. It was built using WITH_META_MODE =
if that
>>>> matters.
>>>=20
>>> QUOTE
>>> author	Kristof Provost 	2022-03-17 =
02:35:13 +0000
>>> committer	Kristof Provost 	2022-03-20 =
00:25:06 +0000
>>> commit	b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d (patch)
>>> . . .
>>> if_epair: build fix
>>> 66acf7685b failed to build on riscv (and mips). This is because the
>>> atomic_testandset_int() (and friends) functions do not exist there.
>>> Happily those platforms do have the long variant, so switch to that.
>>> END QUOTE
>>>=20
>>> broke things for stable/12 by adding the atomic_testandclear_long
>>> usage without defining it as well.
>>>=20
>>> It goes like this:
>>>=20
>>> path: root/sys/arm/include/atomic.h
>>> Commit message (Expand)	Author	Age	Files	Lines
>>> * 	MFC r341787 by hselasky: Implement atomic_swap_xxx() for all =
platforms.	Andriy Gapon	2019-10-24	1	-0/+7
>>> * 	Remove arm-specific implementations of atomic_load/store_xxx() =
now that	Ian Lepore	2017-12-20	1	-27/+0
>>> . . .
>>>=20
>>> So not updated in a long time. But for armv7 and the like, it =
includes:
>>>=20
>>> path: root/sys/arm/include/atomic-v6.h
>>> Commit message (Expand)	Author	Age	Files	Lines
>>> * 	MFC r352938:	Ian Lepore	2019-12-07	1	=
-100/+256
>>> * 	MFC r341679:	Michal Meloun	2018-12-14	1	-1/+1
>>> . . .
>>>=20
>>> Also not updated in a long time.
>>>=20
>>> sys/arm/include/atomic-v6.h has various "atomic_testand"
>>> examples ( sys/arm/include/atomic.h does not ):
>>>=20
>>> atomic_testandset_32
>>> atomic_testandset_int
>>> atomic_testandset_long
>>> atomic_testandset_64
>>>=20
>>> But no examples of "atomic_testandclear"
>>>=20
>>>=20
>>=20
>> The slightly older commit:
>>=20
>> QUOTE
>> author	Michael Gmelin 	2022-03-16 =
22:08:55 +0000
>> committer	Kristof Provost 	2022-03-20 =
00:24:51 +0000
>> commit	fb3644ab2afe777fdd2539bc996a390443f052f1 (patch)
>> . . .
>> if_epair: fix race condition on multi-core systems
>> END QUOTE
>>=20
>> has a use of "atomic_testandclear_int" as well.
>>=20
>>=20
> Thanks for the report.
>=20
> Can you try the attached patch? I=E2=80=99m not going to argue with =
the MI code about the atomic_testandclear_int, but instead revert the =
new if_epair code (in stable/12 only, of course).

We will see if Bob P. can try it. (But his builds
take time, given the machine type involved.)

I'm not set up to build anything for 12. I just looked
up what was going on in Bob's report and commented.

Ultimately, if needed, I could deal with setting up a
temporary context for building stable/12 on aarch64.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 15:59:47 2022
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 75ADE1A23052
	for ; Wed, 23 Mar 2022 15:59:51 +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 4KNtN63pw6z52nm;
	Wed, 23 Mar 2022 15:59:50 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 22NFxmrC099800
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 23 Mar 2022 08:59:48 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 22NFxlC4099799;
	Wed, 23 Mar 2022 08:59:47 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 23 Mar 2022 08:59:47 -0700
From: bob prohaska 
To: Kristof Provost 
Cc: Mark Millard , grembo@freebsd.org,
        Free BSD , bob prohaska 
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
Message-ID: <20220323155947.GA96051@www.zefox.net>
References: <20220323012657.GA82109@www.zefox.net>
 <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
 <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com>
 <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
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: <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
X-Rspamd-Queue-Id: 4KNtN63pw6z52nm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.08 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 NEURAL_HAM_LONG(-0.98)[-0.984];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1162
Lines: 38

On Wed, Mar 23, 2022 at 11:51:17AM +0100, Kristof Provost wrote:
> 
> Can you try the attached patch? I???m not going to argue with the MI code about the atomic_testandclear_int, but instead revert the new if_epair code (in stable/12 only, of course).
> 

Trying it now.

Patch reported:
Patching file sys/net/if_epair.c using Plan A...
Hunk #1 succeeded at 2.
Hunk #2 failed at 37.
Hunk #3 succeeded at 61.
Hunk #4 succeeded at 78.
Hunk #5 succeeded at 201.
Hunk #6 succeeded at 517.
Hunk #7 succeeded at 540.
Hunk #8 succeeded at 701.
Hunk #9 succeeded at 791.
Hunk #10 succeeded at 809.
Hunk #11 succeeded at 862.
Hunk #12 succeeded at 876.
Hunk #13 succeeded at 904.
Hunk #14 succeeded at 932.
Hunk #15 succeeded at 947.
Hunk #16 succeeded at 975.
Hunk #17 succeeded at 999.
Hunk #18 succeeded at 1010.
Hunk #19 succeeded at 1061.
1 out of 19 hunks failed--saving rejects to sys/net/if_epair.c.rej
 
Running make buildkernel -DWITH_META_MODE anyway to see if anything 
else goes wrong. Half an hour in so far and no errors. If it fails 
I'll delete the altered files, run svnlite up again and try over. 

Thanks to all for the speedy replies!

bob prohaska


From nobody Wed Mar 23 16:51:18 2022
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 EC0661A301C0
	for ; Wed, 23 Mar 2022 16:51:21 +0000 (UTC)
	(envelope-from kp@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4KNvWY6QDvz3Cn0;
	Wed, 23 Mar 2022 16:51:21 +0000 (UTC)
	(envelope-from kp@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1648054281;
	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=kZ+yA6viSZkFv4OQLY3+6Cf1WCqwgXRHKPYF73S9gRY=;
	b=HSvnUY+xW/sHOqBbakBkCPAcjD1Gh5hdvOtR9Z6mzmv4K784HlE5bmNBwWpi7Mlt/tSt0k
	m7kFgdRWNmse5h3lG2G1/311+xZgWRRpf/qU3ufvo3lfUUQ0fGz/z3ajb/wwFfYZxOlzdA
	C/PbZVXx82QevfCDzEH3KBFqDFgmJE3XVqquUoqQMA7op7QwAAoK6htE4cj2iuWwOxa+wW
	zSawUjQmhybEYskh6Cqecj3oYA5g1evVJmtqjNDjNJwqCV51740SLXedLhlPvZa80x3VYd
	6dfzyYCaZDvRnNU4tPGMptQWYf7OiSxEHCHibMTprEPE4D9K5C/gEloN2g27pA==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id A404A25A6A;
	Wed, 23 Mar 2022 16:51:21 +0000 (UTC)
	(envelope-from kp@freebsd.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 0DC113E5C9;
	Wed, 23 Mar 2022 17:51:20 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Kristof Provost 
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: /usr/src/sys/net/if_epair.c:181:6: error: ...
Date: Wed, 23 Mar 2022 17:51:18 +0100
Message-Id: <22389953-442F-4915-8797-32D1FF577F44@freebsd.org>
References: <20220323155947.GA96051@www.zefox.net>
Cc: Mark Millard , grembo@freebsd.org,
 Free BSD 
In-Reply-To: <20220323155947.GA96051@www.zefox.net>
To: bob prohaska 
X-Mailer: iPhone Mail (19E241)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648054281;
	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=kZ+yA6viSZkFv4OQLY3+6Cf1WCqwgXRHKPYF73S9gRY=;
	b=QTt83cDztepyvJqFOHEnfU4I+9CPYCCEMM3t+1qcPV84qU7hqTVuiaNLgocIDsEQb9DY6n
	m4mF4nW9lZcllB96BVIEMuy/A9fMZsjBWU9ENPk+RgnxKjRTUeHQq01t49QKQZy6mFTwZS
	fXJoU8awsDGkOmznKMbDtAr1XNHVit4TKJBPCTe4mMoi+uFk52jgZg13BrjMRG8h2AGVy2
	uCJR9ViyGMH6QRNdB19jGWJmWb012l6/4e2lz/eTHMI0J5/WJyGjSlhM6Qlhmw70IUuP47
	FHUSgAP7Vln/JUXKb9LADt+24w+XxaWYWQ6dAhcxU8fdi2cIwuKUNgp+mB7ziQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648054281; a=rsa-sha256; cv=none;
	b=acVMRAB2Bq1dnegPent6O9nGbRywTC1Ah4iEVSpp0NOm16dc8A38NINVAx5wLOnUrxojYq
	gA5qRQQpT/+5cwYvQSdfYF5/UW2zoYlziaQp/YyVb95hPF8hHKhYxOfO+7rWubo4wipyc4
	BeddnuDW6rz6K5SjQ1yTf6f5S/uds0Y3t6A+vP9HhLyy2jpkD5PfyJ1lNEjeyY9HAds848
	w8hvU+M2fNiJ1j9Gqbl9HPl48p6++er8Pyt+KWwMaoWShacVsZcjwzlGj3InuH/2kSOkFL
	bl4JdQCQcdP65M7EiMFf9x3fNkwYHBm5v7tz+xRqItg6pXS3ynvfkoec4J6IYA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1462
Lines: 46



> On 23 Mar 2022, at 16:59, bob prohaska  wrote:
>=20
> =EF=BB=BFOn Wed, Mar 23, 2022 at 11:51:17AM +0100, Kristof Provost wrote:
>>=20
>> Can you try the attached patch? I???m not going to argue with the MI code=
 about the atomic_testandclear_int, but instead revert the new if_epair code=
 (in stable/12 only, of course).
>>=20
>=20
> Trying it now.
>=20
> Patch reported:
> Patching file sys/net/if_epair.c using Plan A...
> Hunk #1 succeeded at 2.
> Hunk #2 failed at 37.
> Hunk #3 succeeded at 61.
> Hunk #4 succeeded at 78.
> Hunk #5 succeeded at 201.
> Hunk #6 succeeded at 517.
> Hunk #7 succeeded at 540.
> Hunk #8 succeeded at 701.
> Hunk #9 succeeded at 791.
> Hunk #10 succeeded at 809.
> Hunk #11 succeeded at 862.
> Hunk #12 succeeded at 876.
> Hunk #13 succeeded at 904.
> Hunk #14 succeeded at 932.
> Hunk #15 succeeded at 947.
> Hunk #16 succeeded at 975.
> Hunk #17 succeeded at 999.
> Hunk #18 succeeded at 1010.
> Hunk #19 succeeded at 1061.
> 1 out of 19 hunks failed--saving rejects to sys/net/if_epair.c.rej
>=20
> Running make buildkernel -DWITH_META_MODE anyway to see if anything=20
> else goes wrong. Half an hour in so far and no errors. If it fails=20
> I'll delete the altered files, run svnlite up again and try over.=20
>=20
> Thanks to all for the speedy replies!

I=E2=80=99m a little confused by that failed hunk. What version are you patc=
hing? The patch should apply cleanly on stable/12.=20

Kristof

From nobody Wed Mar 23 17:43:27 2022
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 239581A2682E
	for ; Wed, 23 Mar 2022 17:43:33 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNwgm01rKz3PV6
	for ; Wed, 23 Mar 2022 17:43:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648057410; bh=42//U9dolsV53WwOH49vfKoynW1Xf4EJFJELxzs3KQg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ISNifrCaO4URgSl/I7fG2nI9//1NbHOk0/I+j5v498n8jsQNZ59n+mHeInhxP01dPq0jMBj7vT+/TX1b6Aq8Pj31/4QDTo4oShcHZvWhloWw+W30VzhHfvxhGfmCVGGpdue8gNRA0cC0r/O7MIJZ7mD6Pmtw0PY9iFmsUNlD9tVE9t+X+rRNDpq2sRU3nJ0nBDek1+h/IMypJgNVhvdSlEpqYDuSvIDaAD+6+lIPeoBp0SRHZY5vdDSaX2qF5ZKcHNwBHJa/35ZNvIft6fAhNZZ6kh5IvI2IhvyqVPtM1VQzw42Zziw1qVD0AqEF+t7NHoxs9oattP/XrJyjNP5y3A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648057410; bh=fmo9XPCGIp6YP2FGsB7YIks+axA02YvnDx33Kjm/As1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QSdk5D8Y0mDsOwxtz8urHd/E4W5Ulhu7Woau+majyIl6iYMoQRmow4YaRUyutWElDdyOn3Dcb6xiDwx9GpsHInqRxDrYIxvZpdXJ1wTaIJo+tPpBqFER4T6EC9goREHuNYMeGe5je/QIlRX8O2SYlygGgjmVrERTLmnuFPiE+UsUVnRKIfSh5jTGCJ/5MM4t1XK7b214aMIyntWUjZO5w5iSGNUeyZbb5p7PhFV+/qkgKKXKJiXN4G7aNEqIfClrvArocJzLEO/hCVJDEmoTxIgQLuR1OfO8FsJe0TpEEScMtfyybj6f4RDPZ06EYzCnKpKO+ez49SldreKf/JyzJA==
X-YMail-OSG: rHhCQAAVM1kCT2g.h0ScSpHoQCtwO.7XBWkJ1c8UDKxQJkmx5KdQr6RAWMjmjU8
 GDct17G7x_mRRowK9foR2jW.P3irbj1gBlovuFTnq7OQLnkSEsZoKtMCl4lQDI.wM6jZVjXr1J.c
 c94TmrUGkznPwldGU_BtEFClDUQgBufPYsE0IehxXsD6h.MGHc0iVyRuRw85L.g1A1toxSQc_dod
 5QZmqeoLRsS1ROd4IbhXjdO0hAW7ekG1LvqM_Y0Ax.aZd2WBQDSBNtK6df9WXv2WTtJSDzY6fRuR
 jTSa1WNRGa892OGwObUI0tcT_Gaef6mmbfg.koYQNLjXIvXoK2GhiDQEx7mK_SdXYxG2s33DXblM
 RLwMYQMXcvvpiwm0Is_JmwOVFIECIQA2QuHmP5qPDeQZTxF0AmxjaIKNU99k95Qe1Vlu0Hbfk7LK
 hmxMNBArsRX2qL0s_UwmVl2qBqFFO_FExJKcysIow7ob1yYOeE99Qk7hKdMrPnMn6KIdNGEcj.F0
 9QHl_N3GTvh7WuaUm.VzvNHISvA5a0jCWnb0BfxNoLW16iky2lAIz53xpmfzhxkg9VYFBBzRm1Tn
 c7nwpCSVScuXLuILi2XDrFnHxnl_se5hTjp47hNU6nb4GZKy2LuF49VPCDx6ZRJG7nXvizEZ6YWH
 43QyL7hFOIUdKL7LFZNBgrJsBa2prr_ncKmN5tCMcYJED68OyuJDi3ITPfd1M1S4tVylklRRZ_1I
 VrUMmC1LvHJJRPGFMyRDZH6aVlCkJdCSp0sDPXCv7y7D3kBJYUuOWcMiqclic8wH8je98hmvrYg0
 qV70sDdf2VysLrzkx0lHc.1JkDI6im0kuJ.sac10su4hJcyh7plgjklV_SwOPqQv4dYNiROxBHm5
 0XIO4WB8YXV4jmCjV9nz1.RlS2eqxETSKfEZgb6qYPzPenxjcZA1NMkU_8BwjenV8lZ4Ni5pf8Jc
 Teh4pzC7fGS98IzcChsO.Wo10k1dFdTbffENcbURDXX02o6XYYKNAZVRjL11ca.oSqQe2eWgQ8pK
 blTHtbO504VvZWG2PeDJW4LN2O_Qj8NUKbOK178M3PzHUcIYCaRajDt3P749DDxTHIQfjucd3L8X
 9Ve23Cy21Om.MA31oxORzUhOsbMLANwtdhdCfprajmSwsQgXUSxuJquoWs79oiTYs8T2.9Vowdl9
 3p9j5Ffh5TnFukS82A0Bl5xQwfq0I3crZ8XdeM6aaz42jVTiVy7i5K1gJjWgpu3hXu60XrHE9c7N
 _3P_hkh_Cb46AunHGkLZhOlzPEA_5WZ5QYYPTC4B3g6zju847VomleCRThF3VrZEkxSDaQbNDDv.
 5c0sRktoqACnKbEgr7NTV_d8uTcI8zCLMuPuKm1Kqm6zIsH3Nj_nL_N2MtJEEvXF49BBevDUUwKk
 kpaixcfEOH5SpjSOhb12zafvqvXl3i4ennUGEaA5gTSQYmen7W1kjnaZ7af9rN4k.6VqgEVq5aZ9
 ek.AD.DoKutdNkNTyhF5mQ1TM8euJs.WkK0uxzkYpGouAfsFMkVL.AZztVotrP4xDUVPry5pgEMf
 Hmq.SI6w5r5k3zH3KM7lPvtkSy4OannhgB76Fy3zJuZ.fGB9YjjbwkZsLDZKhtkfV_0tp817tgD0
 kVv87pvHqAd6kgsCtvxL3X1b32cjporZNlkpSsWyI.XBsZ7EUdV1yKRvKgJMFMdSu5dwYV9eFE_o
 Iy79lhSK7nwsIoRnaA7bwoG48evztn3ng_w5uu2IOImsJHo9DXWLmbVhAuKj6jA9K0ZIVOs98JDw
 OODz1bxgQT0_VqjcAfumHYvcO0ZnteGjLp5YsutLuaEb2jygzSB0dQfxi1.qDJRfOlONNZ0ZQVL6
 Q3A9aZiUdzTIeBslPXemZDXsZ3Qq8oQhG4DtLMCjVsHeJFuohxlbKZId7wO8z6UWZ9E0PUOha__H
 rXyfcEjM_CEYu4p._q.Fyw1KXTm8Ny9YDP.1_oDQUqohOSPCv_akw7PXdH3ebHvklA0y67CXBOqg
 DfCjxk9RwX3Ld75O_OyN445vuJwYwJi6e_cq3XfKYb9gD23o5lkc73DODj6QYRLUhxWGmwQW2_Gb
 ZFD327I5esqNJg62bvSlMar2jYfHWg3DXlqdQq81LbWdDlFRx345LeYGYq20RfVzgU9qO4xPhNz_
 kvS43bP3CuMc7L_M6YniNxIcZv_r8ZHWgoG5VbgP0zfYN_8WTylTKrK1lc1MCDlEbAaO4Vcij9Ub
 Xz4geQbiR_7ASVHaq0XnJVTrcOpuImUo0.rmKtZxC9Ul71OdiGIRly13q5Awh6.eJeqHy.M8x5GU
 bsi24GvPfYScjCqa3hozwsc7swGPIWpJSFhmKXDm8mPw-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 17:43:30 +0000
Received: by kubenode550.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3e3b4bb6f13a0ffabd603b4be758a026;
          Wed, 23 Mar 2022 17:43:28 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <22389953-442F-4915-8797-32D1FF577F44@freebsd.org>
Date: Wed, 23 Mar 2022 10:43:27 -0700
Cc: bob prohaska ,
 grembo@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B9CB488-80F3-4BB3-BA78-97CEFED6CE26@yahoo.com>
References: <20220323155947.GA96051@www.zefox.net>
 <22389953-442F-4915-8797-32D1FF577F44@freebsd.org>
To: Kristof Provost 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNwgm01rKz3PV6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ISNifrCa;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2567
Lines: 88


On 2022-Mar-23, at 09:51, Kristof Provost  wrote:

> On 23 Mar 2022, at 16:59, bob prohaska  wrote:
>>=20
>> =EF=BB=BFOn Wed, Mar 23, 2022 at 11:51:17AM +0100, Kristof Provost =
wrote:
>>>=20
>>> Can you try the attached patch? I???m not going to argue with the MI =
code about the atomic_testandclear_int, but instead revert the new =
if_epair code (in stable/12 only, of course).
>>>=20
>>=20
>> Trying it now.
>>=20
>> Patch reported:
>> Patching file sys/net/if_epair.c using Plan A...
>> Hunk #1 succeeded at 2.
>> Hunk #2 failed at 37.
>> Hunk #3 succeeded at 61.
>> Hunk #4 succeeded at 78.
>> Hunk #5 succeeded at 201.
>> Hunk #6 succeeded at 517.
>> Hunk #7 succeeded at 540.
>> Hunk #8 succeeded at 701.
>> Hunk #9 succeeded at 791.
>> Hunk #10 succeeded at 809.
>> Hunk #11 succeeded at 862.
>> Hunk #12 succeeded at 876.
>> Hunk #13 succeeded at 904.
>> Hunk #14 succeeded at 932.
>> Hunk #15 succeeded at 947.
>> Hunk #16 succeeded at 975.
>> Hunk #17 succeeded at 999.
>> Hunk #18 succeeded at 1010.
>> Hunk #19 succeeded at 1061.
>> 1 out of 19 hunks failed--saving rejects to sys/net/if_epair.c.rej
>>=20
>> Running make buildkernel -DWITH_META_MODE anyway to see if anything=20=

>> else goes wrong. Half an hour in so far and no errors. If it fails=20
>> I'll delete the altered files, run svnlite up again and try over.=20
>>=20
>> Thanks to all for the speedy replies!
>=20
> I=E2=80=99m a little confused by that failed hunk. What version are =
you patching? The patch should apply cleanly on stable/12.=20

Bob's original report was very specific about the version
--but from a svn viewpoint:

root@www:/usr/src # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/stable/12
Relative URL: ^/stable/12
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 371771
Node Kind: directory
Schedule: normal
Last Changed Author: 0mp
Last Changed Rev: 371771
Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022)

In other words (using svnweb to look it up):

Revision 371771 - Directory Listing=20
Modified Tue Mar 22 22:28:40 2022 UTC (19 hours, 13 minutes ago) by 0mp
nullfs.5: Add an example fstab(5) entry

Some other file system manual pages like msdosfs(5) feature similar
examples as well.

MFC after:	1 week

(cherry picked from commit 7d62b5df83000e3c5d14f0dfe8be22a2978534f4)

Git Hash:   dd999ed9463e3f4f3fe43e843510c8ed371100ed
Git Author: 0mp@FreeBSD.org




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 18:11:54 2022
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 49F0E1A2E2CE
	for ; Wed, 23 Mar 2022 18:12:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KNxJk2gtmz3kJt
	for ; Wed, 23 Mar 2022 18:12:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648059119; bh=Bt0EEmKx87+xhcs3v5xNJ1QtX+ANzM/98s0L8qDibEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=so1P8FXujwwpQUOlVO8FIiMg8pC7alrXppJQkotH25PjyNrRNobJ4Rr8NqkRXoKgfPWeouhguqd9sc4Dkk/v1ObddfvxcNUmF3NjVnT0PCquO3vVzgW+Lp1h9ihWxhKC6Mw/RWTLI9AJnyxTqM6tuYLCZFiaUNV/2P6Fq0DaZvCqbOM8k5InSm4X+eLDaJp6M9zNQQjfy/l+6RAU9FSAqQfZcIgK8naRBwFt1PX3gtfuNEnki/gyEWq58hljx46fY54a4wgeK719CuU0Gi6BFyxRIYAxKbWWYmbV1CoOS2WjWAirp6TzwIfW4YDm4yFmnq9KCNB38pzP0ZqeuuvDOQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648059119; bh=UMuh83lzo9wpDQKtJOHcESEN2ICcnaV3Zm3XB5gAmuY=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=i9tdG8XGO9GqIcKDn8okAsd+n9GG7FZDnN3rhQcb26COzMWHGhlvLpw4CU14eLm3OTIxVGX6k97lFmy7o1d34y69wZ747qEaYBgq7L2x9nQoF8pWa/bvh9gqqIcuU93w80CYfEeUUgDdRaX0qgttYhxNdKCOqvU6bHHgeB+pVoOTLwl78jBWCMP5nP/xPNhd5otM0Rt5x5BilarPM+bET1HTJLgWDaRQpzA1Vm8h0285oJkrQ0kNW7jHmph7N68VutnTwKZkueta3BaIyytlCCokY4BP0TgVvkZpmprmMhGl48ciyODUvMVbeRvxjPfMJRqtvi61/us1711gBD6XLA==
X-YMail-OSG: Iv7FN.EVM1nuNapPG9z.YL8KIN4dhVUImUPDlkfJgluwdBVUCKiHGTTgZJ17Asj
 QBREWROE.U0WApy7x5tMdNmOWsAZP.SyWl4pHknr1LEKnRzyvDUoELX1x3Tlf.4.3UXdmwgALD_k
 _fPtIsYLkZRneLC7RWImzHIGKohWGv0scOEPTYt_dPsi65rWkMoKA3u9EUBiQdbKCFjPma7jANgh
 rvTA4neCP2XHrJm_sYXcDZbvHXFyKc0FE3IzBOHAuj3JO6Q3ZPqDbQZreHN6jixxuy09jLhPORra
 dOGzEtcUj3_on20Kz4VECQdyhoDeiO4bGFXzEVfWxFwxsc4gTZ.NMioBCi6Em343pkQCYdbv6TY4
 bNbSIlOVrDW8qsvyjAJFvvDkU_5ECNJsuj7pwqVyShkTcq6z4GPuX1oGV.BSKjUpjs9_gZHm9skO
 L1drruHdhqQNSdhdBP1J2C0Du6xZQqwUtjXmDw3Srhj8ayJjsXFTVO349AD1_aZ4r0Fv8xiSJXb5
 6D5IS_kWjGg.thJTvOQDasE6xpZXjq8RzFZDlKQ_r3Gm0XB0L2zqdGilUizseRmslXLFJ.CXmrsb
 6sWEPFdnqZ0hDCoFWYTOAYPTgmypiTBkTYgbb71K.wuw9ApQPXL9ymbhPEFJvYvmkks1Xmnsv9BK
 mIhlAwGLOVtFaYLpSAj4FgDGqMIthSS2Q_3fQKXWRY4dsAtz0f_Squg2r8Of.YEFZh849.eoh2kf
 iTD.212XzV9oucNe8kiaO7uq9VKF3kw4s0AENPGosYKvtb2BXIXuR8FF25XFq_WIC3gCh4z2P1Gk
 WmKmwoWLAHjUsXWjpAJ8CdUcDK0_PaURt9kbKVDO70bumpscmbcWmiEk7N3r_Q_0VlEo5MaaJ5fu
 qKZvH_CzMJYSHW2xxF5AeHmAebzXQyj1w0Ym5s0XLDOZ4NeVkMSkzCYbK1aQ7QaTIocPgrEeoVfg
 Ti7PerDrb99N_niN_q7ufg9.Dio88TS4Qmvf7OfI9vIXsWrYN828rnyEDk5hhi9Vu0exfoNFzebK
 jVnUw00.y4rAs__5M422zbhtY5BuQLolPNN1VFMy0V.1lqV.Br0mwV7RjJzmg0Tp0oadSJE_3CBr
 Na7XLpV8BDzX4o_bOvKTEkhH0Fs2DANjxmAFXzF1ckSdAx2fNSZ92uzIcBuRNxYTLW13Mx8a8iEr
 y9R76fmNpGeEqmnj0FyehCkQbUjqhzNSgZS_OzI2VnUjnvFkduuIogEElQUykFWbk_wm9ACjS_y6
 GpBMPRK8Aaw2e75Lmr7yl6eVIRqIm3rdPMlk5f_RXIDAgUR7Iskx608UelPDIRfIMku4OsaSq4Q1
 5C.v3MD99ZEbXZGE.jYvMnMRzTryQyF.moFED2aS_92gH4YhRT85naElPdn5VI9dnHjfI9J9dVtf
 HGObzvtks8XSmjSIqSooVJ4Mn9GwrUCuCkIFUpvG5b1ev26ObPPjQ.7h2J_BSgujEP_cBLfJ.Vaa
 RmCtypsJRZdJ0iBo4Y2jSGojqHASk3dlt2Dbo2doNS9S6S7z7nNCygim.ewWHvgdx2acGfwNgkDP
 5f0Irx.QJrO9JBnh.WYaz.twk1b4VXCM6ASkU2lgRzZETvGnsi_cT3uZlX7Lhq.Ltvd6J_xqGjL6
 KGtZbGuRm.QFhXop59VbZM_HAXry_.PTDVF3fQeQOcUR_jKYeJlyLB2xpeZUjGCasWar70Yv1c01
 HBz3TSixNsioHHDwSloEYFLJZVMkoI5893Pu03qqGnPbIRgubXTaJHTX28qF4rl.p6A5x0M7amnX
 s9WrRWV8NNVCTpxiBaH6Fs.FADOypLi1xSXH0ZXT1P98sA2WNy3YRHftHKm5gbnx6UTIdgv5wNNy
 CYUh7OXjDXr7OYbg6nhJCbNbHGxcHtpiNj8GZ5Z2O8F8HknTWKekGquMb6BX3JET5oqYxlu3LHRG
 50ozKOGEZ0y8ZuMfKiFL4I3NX5i556c0Z1avMSoG3_Vs6I4nGD_MrASKmvTITdlLjrBAIWkQ0YOp
 MxcazuBmSYaCBDUwotZj_dC9aJFolt9xxUybs5x5AbhKRYBbMA40t.CLenoqgLpuHyFwq1wyKwV7
 YwSyraOo6S4hhftaNwgbS7FI2LSzor9MjFGFCqVypVHwlrGi5PGolHcr4YpiEW7bxPzGbpK3dq5v
 yx1hkIsHVCp191Ku6JAylgE58rc1GM8XTC5WAR5BXC4n9DGN9yGyygqkpPOuH79XUPAFENC0Isai
 pXioQq39mlGHpnT8N3gKGL1K1AvAAmYo4YiDdYpwnyrEUWPh2LHCrwQ0SnLdpXTvzL2Mk1obpWKX
 QwuECZ0pj6Eh.C_8vPXMAZXDO4aI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Mar 2022 18:11:59 +0000
Received: by hermes--canary-production-bf1-665cdb9985-l8dtt (VZM Hermes SMTP Server) with ESMTPA ID a3b8abc0db4c67bee1f6529601d3d983;
          Wed, 23 Mar 2022 18:11:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
From: Mark Millard 
In-Reply-To: <20220323155947.GA96051@www.zefox.net>
Date: Wed, 23 Mar 2022 11:11:54 -0700
Cc: Kristof Provost ,
 grembo@freebsd.org,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2185A67E-1B69-4F47-B125-87C15B042491@yahoo.com>
References: <20220323012657.GA82109@www.zefox.net>
 <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com>
 <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com>
 <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
 <20220323155947.GA96051@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KNxJk2gtmz3kJt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=so1P8FXu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.41 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.91)[-0.908];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.205:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4324
Lines: 142

On 2022-Mar-23, at 08:59, bob prohaska  wrote:

> On Wed, Mar 23, 2022 at 11:51:17AM +0100, Kristof Provost wrote:
>>=20
>> Can you try the attached patch? I???m not going to argue with the MI =
code about the atomic_testandclear_int, but instead revert the new =
if_epair code (in stable/12 only, of course).
>>=20
>=20
> Trying it now.
>=20
> Patch reported:
> Patching file sys/net/if_epair.c using Plan A...
> Hunk #1 succeeded at 2.
> Hunk #2 failed at 37.
> Hunk #3 succeeded at 61.
> Hunk #4 succeeded at 78.
> Hunk #5 succeeded at 201.
> Hunk #6 succeeded at 517.
> Hunk #7 succeeded at 540.
> Hunk #8 succeeded at 701.
> Hunk #9 succeeded at 791.
> Hunk #10 succeeded at 809.
> Hunk #11 succeeded at 862.
> Hunk #12 succeeded at 876.
> Hunk #13 succeeded at 904.
> Hunk #14 succeeded at 932.
> Hunk #15 succeeded at 947.
> Hunk #16 succeeded at 975.
> Hunk #17 succeeded at 999.
> Hunk #18 succeeded at 1010.
> Hunk #19 succeeded at 1061.
> 1 out of 19 hunks failed--saving rejects to sys/net/if_epair.c.rej
>=20
> Running make buildkernel -DWITH_META_MODE anyway to see if anything=20
> else goes wrong. Half an hour in so far and no errors. If it fails=20
> I'll delete the altered files, run svnlite up again and try over.=20
>=20

I do not have an svn tree around. So my checking below is
just via git and patch.

I created a /usr/12S-src git worktree with the identified
version (that happened to match were my git was last fetched).
I tried:

# git -C /usr/12S-src/ apply ~/12S.diff=20
/usr/home/root/12S.diff:289: trailing whitespace.
	}=20
/usr/home/root/12S.diff:677: trailing whitespace.
=09
/usr/home/root/12S.diff:721: trailing whitespace.
		=09
/usr/home/root/12S.diff:800: trailing whitespace.
=09
/usr/home/root/12S.diff:876: trailing whitespace.
=09
warning: 5 lines add whitespace errors.

So: no problem. I then did:

# git -C /usr/12S-src/ restore .
# git -C /usr/12S-src/ status
On branch stable/12
Your branch is up to date with 'freebsd/stable/12'.

nothing to commit, working tree clean
# cd /usr/12S-src/
# patch -p1 < ~/12S.diff=20
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|=46rom cd13085b06296f5ce9079abfba5b52e2877398d3 Mon Sep 17 00:00:00 =
2001
|From: Kristof Provost 
|Date: Mon, 21 Mar 2022 15:41:32 +0100
|Subject: [PATCH] Revert "if_epair: rework"
|
|Revert the recent performance rework of if_epair. It relies on =
functions like
|atomic_testandclear_long() which are not available on all platforms in
|stable/12.
|
|This reverts commits b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d,
|fb3644ab2afe777fdd2539bc996a390443f052f1,
|ca7af63e88f8cc96865d45e020a57b3062631388,
|092da35a0d80af7a3e5c5c22cbeddb6cffbd9524,
|and 7c2b681b33fc78ed06c7e9e65eeebb2ab5420586.
|
|This is a direct commit to stable/12.
|---
| sys/modules/if_epair/Makefile |   2 +-
| sys/net/if_epair.c            | 832 +++++++++++++++++++++-------------
| 2 files changed, 509 insertions(+), 325 deletions(-)
|
|diff --git a/sys/modules/if_epair/Makefile =
b/sys/modules/if_epair/Makefile
|index 8b063623f2e8..3e102413bfe2 100644
|--- a/sys/modules/if_epair/Makefile
|+++ b/sys/modules/if_epair/Makefile
--------------------------
Patching file sys/modules/if_epair/Makefile using Plan A...
Hunk #1 succeeded at 3.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/sys/net/if_epair.c b/sys/net/if_epair.c
|index 4b01e97c354d..cd11036ad028 100644
|--- a/sys/net/if_epair.c
|+++ b/sys/net/if_epair.c
--------------------------
Patching file sys/net/if_epair.c using Plan A...
Hunk #1 succeeded at 2.
Hunk #2 succeeded at 37.
Hunk #3 succeeded at 61.
Hunk #4 succeeded at 78.
Hunk #5 succeeded at 201.
Hunk #6 succeeded at 517.
Hunk #7 succeeded at 540.
Hunk #8 succeeded at 701.
Hunk #9 succeeded at 791.
Hunk #10 succeeded at 809.
Hunk #11 succeeded at 862.
Hunk #12 succeeded at 876.
Hunk #13 succeeded at 904.
Hunk #14 succeeded at 932.
Hunk #15 succeeded at 947.
Hunk #16 succeeded at 975.
Hunk #17 succeeded at 999.
Hunk #18 succeeded at 1010.
Hunk #19 succeeded at 1061.
Hmm...  Ignoring the trailing garbage.
done

So, again, no problem.

Looks like something was likely odd on your end.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Mar 23 18:24:46 2022
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 054231A312C1
	for ; Wed, 23 Mar 2022 18:24:50 +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 4KNxbN2X65z3mJH;
	Wed, 23 Mar 2022 18:24:48 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 22NIOkSe022836
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 23 Mar 2022 11:24:46 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 22NIOkMQ022835;
	Wed, 23 Mar 2022 11:24:46 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 23 Mar 2022 11:24:46 -0700
From: bob prohaska 
To: Kristof Provost 
Cc: Mark Millard , grembo@freebsd.org,
        Free BSD , bob prohaska 
Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ...
Message-ID: <20220323182446.GA22818@www.zefox.net>
References: <20220323155947.GA96051@www.zefox.net>
 <22389953-442F-4915-8797-32D1FF577F44@freebsd.org>
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: <22389953-442F-4915-8797-32D1FF577F44@freebsd.org>
X-Rspamd-Queue-Id: 4KNxbN2X65z3mJH
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.99 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_LONG(-0.89)[-0.894];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2105
Lines: 64

On Wed, Mar 23, 2022 at 05:51:18PM +0100, Kristof Provost wrote:
> 
> 
> > On 23 Mar 2022, at 16:59, bob prohaska  wrote:
> > 
> > ???On Wed, Mar 23, 2022 at 11:51:17AM +0100, Kristof Provost wrote:
> >> 
> >> Can you try the attached patch? I???m not going to argue with the MI code about the atomic_testandclear_int, but instead revert the new if_epair code (in stable/12 only, of course).
> >> 
> > 
> > Trying it now.
> > 
> > Patch reported:
> > Patching file sys/net/if_epair.c using Plan A...
> > Hunk #1 succeeded at 2.
> > Hunk #2 failed at 37.
> > Hunk #3 succeeded at 61.
> > Hunk #4 succeeded at 78.
> > Hunk #5 succeeded at 201.
> > Hunk #6 succeeded at 517.
> > Hunk #7 succeeded at 540.
> > Hunk #8 succeeded at 701.
> > Hunk #9 succeeded at 791.
> > Hunk #10 succeeded at 809.
> > Hunk #11 succeeded at 862.
> > Hunk #12 succeeded at 876.
> > Hunk #13 succeeded at 904.
> > Hunk #14 succeeded at 932.
> > Hunk #15 succeeded at 947.
> > Hunk #16 succeeded at 975.
> > Hunk #17 succeeded at 999.
> > Hunk #18 succeeded at 1010.
> > Hunk #19 succeeded at 1061.
> > 1 out of 19 hunks failed--saving rejects to sys/net/if_epair.c.rej
> > 
> > Running make buildkernel -DWITH_META_MODE anyway to see if anything 
> > else goes wrong. Half an hour in so far and no errors. If it fails 
> > I'll delete the altered files, run svnlite up again and try over. 
> > 
> > Thanks to all for the speedy replies!
> 
> I???m a little confused by that failed hunk. What version are you patching? The patch should apply cleanly on stable/12. 

svnlite info reports
Path: /usr/src
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/stable/12
Relative URL: ^/stable/12
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 371773
Node Kind: directory
Schedule: normal
Last Changed Author: royger
Last Changed Rev: 371773
Last Changed Date: 2022-03-23 06:53:19 -0700 (Wed, 23 Mar 2022)

The kernel compiled and installed without error. After sending this
email I'll attempt to reboot.

Thanks for your help!

bob prohaska


From nobody Sat Mar 26 16:12:27 2022
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 B0B5A1A4A2E0
	for ; Sat, 26 Mar 2022 16:12:27 +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 4KQkWH1xN7z4SJZ
	for ; Sat, 26 Mar 2022 16:12:27 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 2251A24368
	for ; Sat, 26 Mar 2022 16:12:27 +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 22QGCR96046916
	for ; Sat, 26 Mar 2022 16:12:27 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22QGCRGt046915
	for freebsd-arm@FreeBSD.org; Sat, 26 Mar 2022 16:12:27 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 262836] [arm64] cacheline flush instruction (dc cvau) causes
 SIGSEGV from userland
Date: Sat, 26 Mar 2022 16:12:27 +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: dch@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648311147;
	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=9W28knl0V3Zo+bxTzZecOnbmhNBR67OnQPGTEXT5glo=;
	b=VlXh3HHBgEjb/LxH3Xew1+W9Hdpwf/FqaqlW5YJM6WobxdqAoFnBq7L/VIR2NXsy6LGfZa
	nm6JhRWCH3yHfazkkGOwT/g4RhTszqh4ci2OOkQAr4nnrDYaRB60Dbn0m9VZEeeXvD+uq3
	Tlf9Ody8r6cetMcqdoteADlIttVO/rHppEKwNxyX2swUx4TDpg5sKnyR1bqz+7dFTM2hRr
	Jg+tU5JXj4CHobPYNFh9D5xCSSWKgqNY5AIDadgW/cMmJAq8PkzRGWkBUPEzUyckprXpKF
	J4qkxnoq8/LWSfxxgO8eAa8CqDP63It9NjtTiaT8O8m+YQVU8y51Cx3We+xyhg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648311147; a=rsa-sha256; cv=none;
	b=bXb4OhURvaNUcqOytTF0syJTRP6wEGjhHwUL3+q6AK4knFx/IzOyurl1d7Nnv12v8QknR3
	9SBXrhZJYEFFKry8knHbF1PF2fsr61Qd+M6DrzOhcTm2e8XcOiua2mS12NtHouMAaB+P/l
	HT/Ed3jzxbQrRpaOEiRTjRVBOfRkL3dHoMVReXDxc5jqgDAzJG9j4PiH5NiyVBrz2tFXUz
	e1SJup9CeBiXilkEOs0QXbwlh9cdXNwRQtS7lQ6tftfxaPuelxlhBdPoZc8leivKU1Jdqs
	kuLudCelMwlLHk7XfFC7qlYP6fyA/ZTz4NmScuxlCPu6Lbsam65HiBRXTHpZkA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6150
Lines: 161

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262836

            Bug ID: 262836
           Summary: [arm64] cacheline flush instruction (dc cvau) causes
                    SIGSEGV from userland
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: dch@freebsd.org

Created attachment 232744
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232744&action=
=3Dedit
https://git.sr.ht/~dch/src/commit/ae9221b85d18b6816276b8401734548f03b89013.=
patch

building OTP-25-RC2 from source yields a segfault during build. After
some build finagling, we can narrow this down to `dc cvau` failing:


```
sudo lldb ./bin/aarch64-unknown-freebsd14.0/beam.debug.jit
(lldb) target create "./bin/aarch64-unknown-freebsd14.0/beam.debug.jit"
Current executable set to
'/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64).

(lldb) run
Process 40356 launched:
'/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64)
Process 40356 stopped
* thread #1, name =3D 'beam.debug.jit', stop reason =3D signal SIGSEGV: add=
ress
access protected (fault address: 0xdee00000)
    frame #0: 0x0000000000769f54
beam.debug.jit`__clear_cache(start=3D0x00000000dee00000, end=3D0x00000000de=
e0294c)
at clear_cache.c:119:7
   116      const size_t dcache_line_size =3D 4 << ((ctr_el0 >> 16) & 15);
   117      for (addr =3D xstart & ~(dcache_line_size - 1); addr < xend;
   118           addr +=3D dcache_line_size)
-> 119        __asm __volatile("dc cvau, %0" ::"r"(addr));
   120    }
   121    __asm __volatile("dsb ish");
   122

(lldb) bt
* thread #1, name =3D 'beam.debug.jit', stop reason =3D signal SIGSEGV: add=
ress
access protected (fault address: 0xdee00000)
  * frame #0: 0x0000000000769f54
beam.debug.jit`__clear_cache(start=3D0x00000000dee00000, end=3D0x00000000de=
e0294c)
at clear_cache.c:119:7
    frame #1: 0x00000000003feb60
beam.debug.jit`BeamAssembler::_codegen(this=3D0x00000000d4b0e000,
allocator=3D0x000000008b16c018, executable_ptr=3D,
writable_ptr=3D) at beam_jit_common.cpp:128:5
    frame #2: 0x00000000003ea4e8
beam.debug.jit`BeamGlobalAssembler::BeamGlobalAssembler(this=3D0x00000000d4=
b0e000,
allocator=3D0x000000008b16c018) at beam_asm_global.cpp:71:9
    frame #3: 0x00000000004034dc beam.debug.jit`::beamasm_init() at
beam_jit_main.cpp:256:15
    frame #4: 0x000000000049c908 beam.debug.jit`erl_init(ncpu=3D32,
proc_tab_sz=3D262144, legacy_proc_tab=3D0, port_tab_sz=3D65536,
port_tab_sz_ignore_files=3D0, legacy_port_tab=3D0, sys_proc_outst_req_lim=
=3D64,
time_correction=3D1, time_warp_mode=3DERTS_NO_TIME_WARP_MODE,
node_tab_delete_delay=3D60, db_spin_count=3DERTS_DB_SPNCNT_NORMAL) at
erl_init.c:355:5
    frame #5: 0x000000000049b0a8 beam.debug.jit`erl_start(argc=3D1,
argv=3D0x000000008144b690) at erl_init.c:2424:5
    frame #6: 0x00000000003c0828 beam.debug.jit`main(argc=3D1,
argv=3D0x000000008144b690) at erl_main.c:30:5
    frame #7: 0x00000000003c063c beam.debug.jit`__start(argc=3D1,
argv=3D0x000000008144b690, env=3D0x000000008144b6a0, cleanup=3D) at
crt1_c.c:72:7
    frame #8: 0x0000236d2a2f60d8 ld-elf.so.1`.rtld_start at rtld_start.S:41

(lldb) x/8i $pc-16
    0x769f44: 0xcb0903ea   neg    x10, x9
    0x769f48: 0x8a00014a   and    x10, x10, x0
    0x769f4c: 0xeb01015f   cmp    x10, x1
    0x769f50: 0x540000a2   b.hs   0x769f64                  ; <+76> at
clear_cache.c:121:3
->  0x769f54: 0xd50b7b2a   dc     cvau, x10
    0x769f58: 0x8b09014a   add    x10, x10, x9
    0x769f5c: 0xeb01015f   cmp    x10, x1
    0x769f60: 0x54ffffa3   b.lo   0x769f54                  ; <+60> at
clear_cache.c:119:7

(lldb) x/8i start
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =3D0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =3D0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044

(lldb) x/8i end
    0xdee0294c: 0x00000000   udf    #0x0
    0xdee02950: 0x00000000   udf    #0x0
    0xdee02954: 0x00000000   udf    #0x0
    0xdee02958: 0x00000000   udf    #0x0
    0xdee0295c: 0x00000000   udf    #0x0
    0xdee02960: 0x00000000   udf    #0x0
    0xdee02964: 0x00000000   udf    #0x0
    0xdee02968: 0x00000000   udf    #0x0

(lldb) x/8i $x0
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =3D0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =3D0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044

(lldb) x/8i $x1
    0xdee0294c: 0x00000000   udf    #0x0
    0xdee02950: 0x00000000   udf    #0x0
    0xdee02954: 0x00000000   udf    #0x0
    0xdee02958: 0x00000000   udf    #0x0
    0xdee0295c: 0x00000000   udf    #0x0
    0xdee02960: 0x00000000   udf    #0x0
    0xdee02964: 0x00000000   udf    #0x0
    0xdee02968: 0x00000000   udf    #0x0

(lldb) x/8i $x9
error: memory read failed for 0x0

(lldb) x/8i $x10
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =3D0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =3D0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044
(lldb)
```

andrew@ produced a small patch which seems to be sufficient (attached).

It would be great to have a fix for this included in 13.1-RELEASE arm64 if
possible.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Mar 27 05:55:18 2022
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 EB85D1A385F2
	for ; Sun, 27 Mar 2022 05:55:25 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4KR4ms0W8rz4Vfh
	for ; Sun, 27 Mar 2022 05:55:25 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62d.google.com with SMTP id bq8so8673660ejb.10
        for ; Sat, 26 Mar 2022 22:55:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=HDVRR9yg2PRDChbb+wTyQxK78Z13qms72CmYi/j9khA=;
        b=Em4Aaz9DT1Sh0tUtl+1GlpNxDEc2pn2sjlWmAUxv+a3D6g8iHqBfSjgt5im1+hH8GD
         YiNYYb95z0DKDpw2f7hob74EyMmVSzcjJsl48/p4hHBcM2cNe9lJwYatQikVTrcy/pD3
         cjKnYR0mIRWDHZBGYuUw4D5SWNslYLqN8HhyaLZQ7NPBsNIjNXaB/rJGX+F45NAs97vh
         8wLPMGUUx7eq+QwnP/OObiTmwwrByB2C2KeRh+8nk94jFakjXp80E8Ym0EA1P9/6HowX
         nJ3qngPnsvygOpjYfOrUNmgns2cUJ4yPGa/oUjpkAMv1kcUQFbFFz3IgGy8nNiYrVrE2
         LrwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=HDVRR9yg2PRDChbb+wTyQxK78Z13qms72CmYi/j9khA=;
        b=NATMMX/KzWerExxqd8IQzghVV1b1KUf43V8d7Ct0yg5chk5Eolx9UElXiqretFXaSP
         s9FWOF+jeSFChiimu6yOXEYocoFUuYph1l8mg4y97vjV+DSBpOA353NBm656QsuW3fSP
         F9bJfcgyfFzODcRZwskeQYbGVNfuBXJB3QfTehOvAPItQ2CAxWCE8JyWhRaIo6ZOYzzg
         YryDr58ChhuTrIOHR4JvHxTeT9RivGQPuSOl2wLziDE7hgElKbSD4IfAQd5dIGp3w6hD
         MIJH54TGY/Kx+BoKNhBlbQLy8GSr3tsyzQrWCyac4Od0HioQ5FTjs412D3ohtoDAgWdC
         qUog==
X-Gm-Message-State: AOAM532kzzpPppsr/phCSGpvt6TjJSxZZK1g2MLqjbv+XI+EBkAvGlVN
	D3dmgmTwIj7ZZd46GGy0fo1Zg27ieuYeeWMMIJceIinNSoE=
X-Google-Smtp-Source: ABdhPJxVkEOo0Qz8oj98P8sypqSvEI8ojqg5Wle9QAWw7gZdx162YkiIQSCFCxnLOvQXPJTKoEob4P7Bd9wEAifG+yM=
X-Received: by 2002:a17:907:eac:b0:6db:799c:cb3c with SMTP id
 ho44-20020a1709070eac00b006db799ccb3cmr20929567ejc.559.1648360523918; Sat, 26
 Mar 2022 22:55:23 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sun, 27 Mar 2022 13:55:18 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000007d718f05db2cd7d3"
X-Rspamd-Queue-Id: 4KR4ms0W8rz4Vfh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Em4Aaz9D;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8871
Lines: 183

--0000000000007d718f05db2cd7d3
Content-Type: text/plain; charset="UTF-8"

On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky  wrote:

> On 3/12/22 08:07, Archimedes Gaviola wrote:
> > ugen1.5:  at usbus1
> > ulpt1 on uhub1
> > ulpt1:  on usbus1
> > device_attach: ulpt1 attach returned 12
>
> 12 : man errno :
>       12 ENOMEM Cannot allocate memory.
>
> I guess the EPSON printer you've got is not compatible with ulpt
>
> When printing, can you make sure that the length transferred is never a
> multiple of 64 bytes?
>
> Also, there might be a bug lurking in the USB host controller driver,
> like already mentioned.
>


Hi Hans,

I just figured-out the ulpt(4) driver in my Epson printer while comparing
with my Xprinter printer's USB device info. My Epson printer is providing
vendor specific values of 255 in the bInterfaceClass and bInterfaceSubClass
respectively.

      bInterfaceClass = 0x00ff  
      bInterfaceSubClass = 0x00ff

It should be a value of 7 for bInterfaceClass and a value of 1 in
bInterfaceSubClass.

      bInterfaceClass = 0x0007  
      bInterfaceSubClass = 0x0001

So, the ulpt_attach() routine below will break upon validation for
mismatched values in UICLASS_PRINTER and  UISUBCLASS_PRINTER.

                        } else {
                                alt_index++;
                                if ((id->bInterfaceClass ==
UICLASS_PRINTER) &&
                                    (id->bInterfaceSubClass ==
UISUBCLASS_PRINTER) &&
                                    (id->bInterfaceProtocol ==
UIPROTO_PRINTER_BI)) {
                                        goto found;
                                }
                        }

What I did is temporarily replace these values in the USB definition. In
this case, how should the project handle this non-compliance USB devices?
Though I will raise this to Epson if they could provide an updated firmware.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig
/usr/src/sys/dev/usb/usb.h
--- /usr/src/sys/dev/usb/usb.h.orig     2022-03-27 02:55:01.319235000 +0800
+++ /usr/src/sys/dev/usb/usb.h  2022-03-27 02:57:10.608518000 +0800
@@ -459,8 +459,10 @@
 #define        UICLASS_PHYSICAL        0x05
 #define        UICLASS_IMAGE           0x06
 #define        UISUBCLASS_SIC          1       /* still image class */
-#define        UICLASS_PRINTER         0x07
-#define        UISUBCLASS_PRINTER      1
+/* #define     UICLASS_PRINTER         0x07 */
+/* #define     UISUBCLASS_PRINTER      1 */
+#define        UICLASS_PRINTER         0xff
+#define        UISUBCLASS_PRINTER      0xff

I can print now with ulpt(4) driver but need further testing for any issues.

ugen1.5:  at usbus1
ulpt0 on uhub1
ulpt0:  on usbus1
ulpt_attach: setting alternate config number: 0
ulpt0: using bi-directional mode

Thanks,
Archimedes

--0000000000007d718f05db2cd7d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Mar 12, 2022 at 4:41 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/1=
2/22 08:07, Archimedes Gaviola wrote:

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ulpt1 on uhub1

> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> device_attach: ulpt1 attach returned 12



12 : man errno :

=C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.



I guess the EPSON printer you've got is not compatible with ulpt<n&g=
t;



When printing, can you make sure that the length transferred is never a 
multiple of 64 bytes?



Also, there might be a bug lurking in the USB host controller driver, 

like already mentioned.


Hi Hans,

I just figured-out th=
e ulpt(4) driver in my Epson printer while comparing with my Xprinter print=
er's USB device info. My Epson printer is providing vendor specific val=
ues of 255 in the bInterfaceClass and bInterfaceSubClass respectively.
<=
/div>

=C2=A0=
 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff =C2=A0<Vendor specific>
=
=C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x00ff

It should be a value of 7 for=
=20
bInterfaceClass and a value of 1 in=20
bInterfaceSubClass.



=C2=
=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x0007 =C2=A0<Printer device>=C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0001

So, the ulpt_attach() routin=
e below will break upon validation for mismatched values in=20
 UICLASS_PRINTER and=C2=A0
UISUBCLASS_PRINTER.





=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClass =3D=3D UICLA=
SS_PRINTER) &&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 (id->bInterfaceSubClass =3D=3D UISUBCLASS_PRINTER) &&
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceProtocol=
 =3D=3D UIPROTO_PRINTER_BI)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 goto found;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }

What I did is temporarily replace these values in the USB def=
inition. In this case, how should the project handle this non-compliance US=
B devices? Though I will raise this to Epson if they could provide an updat=
ed firmware.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig /u=
sr/src/sys/dev/usb/usb.h
--- /usr/src/sys/dev/usb/usb.h.orig =C2=A0 =C2=
=A0 2022-03-27 02:55:01.319235000 +0800
+++ /usr/src/sys/dev/usb/usb.h =
=C2=A02022-03-27 02:57:10.608518000 +0800
@@ -459,8 +459,10 @@
=C2=A0=
#define =C2=A0 =C2=A0 =C2=A0 =C2=A0UICLASS_PHYSICAL =C2=A0 =C2=A0 =C2=A0 =
=C2=A00x05
=C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=A0UICLASS_IMAGE =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x06
=C2=A0#define =C2=A0 =C2=A0 =C2=A0 =C2=
=A0UISUBCLASS_SIC =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 =
/* still image class */
-#define =C2=A0 =C2=A0 =C2=A0 =C2=A0UICLASS_PRIN=
TER =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07
-#define =C2=A0 =C2=A0 =C2=A0 =C2=
=A0UISUBCLASS_PRINTER =C2=A0 =C2=A0 =C2=A01
+/* #define =C2=A0 =C2=A0 UI=
CLASS_PRINTER =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x07 */
+/* #define =C2=A0 =C2=
=A0 UISUBCLASS_PRINTER =C2=A0 =C2=A0 =C2=A01 */
+#define =C2=A0 =C2=A0 =
=C2=A0 =C2=A0UICLASS_PRINTER =C2=A0 =C2=A0 =C2=A0 =C2=A0 0xff
+#define =
=C2=A0 =C2=A0 =C2=A0 =C2=A0UISUBCLASS_PRINTER =C2=A0 =C2=A0 =C2=A00xff

I can prin=
t now with ulpt(4) driver but need further testing for any issues.

ugen1.5: &=
lt;EPSON EPSON UB-U03II> at usbus1
ulpt0 on uhub1
ulpt0: <EPSON=
 EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> on usbus1
ulpt_att=
ach: setting alternate config number: 0
ulpt0: using bi-directional mode=


Thank=
s,
Archimedes 




--0000000000007d718f05db2cd7d3--

From nobody Sun Mar 27 08:04:52 2022
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 EFED11A417B9
	for ; Sun, 27 Mar 2022 09:05:24 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KR90334X9z4tjC
	for ; Sun, 27 Mar 2022 09:05:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0995D260754;
	Sun, 27 Mar 2022 11:05:13 +0200 (CEST)
Message-ID: 
Date: Sun, 27 Mar 2022 10:04: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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KR90334X9z4tjC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.26 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.98)[-0.980];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.982];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3237
Lines: 88

On 3/27/22 07:55, Archimedes Gaviola wrote:
> On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky  wrote:
> 
>> On 3/12/22 08:07, Archimedes Gaviola wrote:
>>> ugen1.5:  at usbus1
>>> ulpt1 on uhub1
>>> ulpt1:  on usbus1
>>> device_attach: ulpt1 attach returned 12
>>
>> 12 : man errno :
>>        12 ENOMEM Cannot allocate memory.
>>
>> I guess the EPSON printer you've got is not compatible with ulpt
>>
>> When printing, can you make sure that the length transferred is never a
>> multiple of 64 bytes?
>>
>> Also, there might be a bug lurking in the USB host controller driver,
>> like already mentioned.
>>
> 
> 
> Hi Hans,
> 
> I just figured-out the ulpt(4) driver in my Epson printer while comparing
> with my Xprinter printer's USB device info. My Epson printer is providing
> vendor specific values of 255 in the bInterfaceClass and bInterfaceSubClass
> respectively.
> 
>        bInterfaceClass = 0x00ff  
>        bInterfaceSubClass = 0x00ff
> 
> It should be a value of 7 for bInterfaceClass and a value of 1 in
> bInterfaceSubClass.
> 
>        bInterfaceClass = 0x0007  
>        bInterfaceSubClass = 0x0001
> 
> So, the ulpt_attach() routine below will break upon validation for
> mismatched values in UICLASS_PRINTER and  UISUBCLASS_PRINTER.
> 
>                          } else {
>                                  alt_index++;
>                                  if ((id->bInterfaceClass ==
> UICLASS_PRINTER) &&
>                                      (id->bInterfaceSubClass ==
> UISUBCLASS_PRINTER) &&
>                                      (id->bInterfaceProtocol ==
> UIPROTO_PRINTER_BI)) {
>                                          goto found;
>                                  }
>                          }
> 
> What I did is temporarily replace these values in the USB definition. In
> this case, how should the project handle this non-compliance USB devices?
> Though I will raise this to Epson if they could provide an updated firmware.
> 
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig
> /usr/src/sys/dev/usb/usb.h
> --- /usr/src/sys/dev/usb/usb.h.orig     2022-03-27 02:55:01.319235000 +0800
> +++ /usr/src/sys/dev/usb/usb.h  2022-03-27 02:57:10.608518000 +0800
> @@ -459,8 +459,10 @@
>   #define        UICLASS_PHYSICAL        0x05
>   #define        UICLASS_IMAGE           0x06
>   #define        UISUBCLASS_SIC          1       /* still image class */
> -#define        UICLASS_PRINTER         0x07
> -#define        UISUBCLASS_PRINTER      1
> +/* #define     UICLASS_PRINTER         0x07 */
> +/* #define     UISUBCLASS_PRINTER      1 */
> +#define        UICLASS_PRINTER         0xff
> +#define        UISUBCLASS_PRINTER      0xff
> 
> I can print now with ulpt(4) driver but need further testing for any issues.
> 
> ugen1.5:  at usbus1
> ulpt0 on uhub1
> ulpt0:  on usbus1
> ulpt_attach: setting alternate config number: 0
> ulpt0: using bi-directional mode
> 

Hi,

I think you can just extend that piece of code to accept either value 
using a boolean OR, ||.

--HPS


From nobody Sun Mar 27 14:28:07 2022
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 7B8B71A425BE
	for ; Sun, 27 Mar 2022 14:28:30 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4KRJ8s39xDz4hQr
	for ; Sun, 27 Mar 2022 14:28:29 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62f.google.com with SMTP id bg10so23813046ejb.4
        for ; Sun, 27 Mar 2022 07:28:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ddQlPRgr/BMqUvBOul3p1EcTsrcb9ptvwGner16XrEY=;
        b=iOTuTwQaDzCQFgbNf1ulJ3E3Dfd/bRkLp3mvpNKB1e+kb6pSxxf18615qHGGoh8MqR
         zPfE7E3oYMldIuLVfpQlZeiHUn9++ktoCo7s18fzCeHlaKXdNRINw6l6Vb99Rc+/gznl
         lOyUBzZ7VcVgoa5zw8+upvx4uc0J0c3/QaMY5uQqwqhnBlh0KzO4kFc6srObA2UIwEp3
         4+dNI8mWY58atEPEkrf9uEtUF7Dp/a3F6PzTXWP8L7yxv5tDNX0f0vRVgT0LjtmNOb/5
         aWdPcUacobFe1rX5BZK1Cx/3uyVvmh1sjHsSkI3A7tEu3VlXOS3nTzg33nsmoEYlZ8i/
         4Rdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ddQlPRgr/BMqUvBOul3p1EcTsrcb9ptvwGner16XrEY=;
        b=aEliO13CezYPOfI6Z6AMEwaNLSSodLd7BVWUJ16NlmpmFXmVfpI/+0qyKS/zMRM35S
         pvth/zY2gZPQpcMk8X3ocwksk0xwnqpnvnMlqVQWs3Q4Pe/jVOPpmr+q27an7061ZwT8
         iPIG11USjIyty4qgFlLjOUrJ6esFhphWsNrilH88OhvXrqPM9XGSl+nx+S02UAcIMsX5
         4NaX8GCJNSAapqtEfH+Qhb37cMrZuy+Abmpt2wmwdNRhRNFiWsCDnTsuFq/fhSSe8Ocn
         cQtYo9hTIp29g0nWwgNKmIoM3Rnprw3MUaFrB+T0QHiXGZWDeZpUZdPS3GgSlrxdISqE
         IdHQ==
X-Gm-Message-State: AOAM533ov0F4ltZwTQwt0BIAZvOeqBRR086lqe0Tky8uuIebWC+gLKhz
	NclqfciwhkpMpPEIJeKM0RtGT1VsF+E1jdxoUYwsWTTH
X-Google-Smtp-Source: ABdhPJwm9/XOuEAhUXkaTAIkwEolIqtgKF8LvDpakROiXR4ev68XNFkA38ryWXpxsmzkHKuzr+zY889KUAtlUFE0wxA=
X-Received: by 2002:a17:906:7304:b0:6e0:6918:ef6f with SMTP id
 di4-20020a170906730400b006e06918ef6fmr22046288ejc.370.1648391307524; Sun, 27
 Mar 2022 07:28: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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sun, 27 Mar 2022 22:28:07 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000055ff3005db3402bb"
X-Rspamd-Queue-Id: 4KRJ8s39xDz4hQr
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=iOTuTwQa;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.996];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9986
Lines: 247

--00000000000055ff3005db3402bb
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky  wrote:

> On 3/27/22 07:55, Archimedes Gaviola wrote:
> > On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky 
> wrote:
> >
> >> On 3/12/22 08:07, Archimedes Gaviola wrote:
> >>> ugen1.5:  at usbus1
> >>> ulpt1 on uhub1
> >>> ulpt1:  on
> usbus1
> >>> device_attach: ulpt1 attach returned 12
> >>
> >> 12 : man errno :
> >>        12 ENOMEM Cannot allocate memory.
> >>
> >> I guess the EPSON printer you've got is not compatible with ulpt
> >>
> >> When printing, can you make sure that the length transferred is never a
> >> multiple of 64 bytes?
> >>
> >> Also, there might be a bug lurking in the USB host controller driver,
> >> like already mentioned.
> >>
> >
> >
> > Hi Hans,
> >
> > I just figured-out the ulpt(4) driver in my Epson printer while comparing
> > with my Xprinter printer's USB device info. My Epson printer is providing
> > vendor specific values of 255 in the bInterfaceClass and
> bInterfaceSubClass
> > respectively.
> >
> >        bInterfaceClass = 0x00ff  
> >        bInterfaceSubClass = 0x00ff
> >
> > It should be a value of 7 for bInterfaceClass and a value of 1 in
> > bInterfaceSubClass.
> >
> >        bInterfaceClass = 0x0007  
> >        bInterfaceSubClass = 0x0001
> >
> > So, the ulpt_attach() routine below will break upon validation for
> > mismatched values in UICLASS_PRINTER and  UISUBCLASS_PRINTER.
> >
> >                          } else {
> >                                  alt_index++;
> >                                  if ((id->bInterfaceClass ==
> > UICLASS_PRINTER) &&
> >                                      (id->bInterfaceSubClass ==
> > UISUBCLASS_PRINTER) &&
> >                                      (id->bInterfaceProtocol ==
> > UIPROTO_PRINTER_BI)) {
> >                                          goto found;
> >                                  }
> >                          }
> >
> > What I did is temporarily replace these values in the USB definition. In
> > this case, how should the project handle this non-compliance USB devices?
> > Though I will raise this to Epson if they could provide an updated
> firmware.
> >
> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig
> > /usr/src/sys/dev/usb/usb.h
> > --- /usr/src/sys/dev/usb/usb.h.orig     2022-03-27 02:55:01.319235000
> +0800
> > +++ /usr/src/sys/dev/usb/usb.h  2022-03-27 02:57:10.608518000 +0800
> > @@ -459,8 +459,10 @@
> >   #define        UICLASS_PHYSICAL        0x05
> >   #define        UICLASS_IMAGE           0x06
> >   #define        UISUBCLASS_SIC          1       /* still image class */
> > -#define        UICLASS_PRINTER         0x07
> > -#define        UISUBCLASS_PRINTER      1
> > +/* #define     UICLASS_PRINTER         0x07 */
> > +/* #define     UISUBCLASS_PRINTER      1 */
> > +#define        UICLASS_PRINTER         0xff
> > +#define        UISUBCLASS_PRINTER      0xff
> >
> > I can print now with ulpt(4) driver but need further testing for any
> issues.
> >
> > ugen1.5:  at usbus1
> > ulpt0 on uhub1
> > ulpt0:  on usbus1
> > ulpt_attach: setting alternate config number: 0
> > ulpt0: using bi-directional mode
> >
>
> Hi,
>
> I think you can just extend that piece of code to accept either value
> using a boolean OR, ||.
>


Hi Hans,

Ah okay, this is noted. I just thought it's not allowed. I already extended
the code and on the way re-building the kernel.

Thanks,
Archimedes

--00000000000055ff3005db3402bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Mar 27, 2022 at 5:05 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/2=
7/22 07:55, Archimedes Gaviola wrote:

> On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/12/22 08:07, Archimedes Gaviola wrote:

>>> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

>>> ulpt1 on uhub1

>>> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, add=
r 5> on usbus1

>>> device_attach: ulpt1 attach returned 12

>>

>> 12 : man errno :

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.

>>

>> I guess the EPSON printer you've got is not compatible with ul=
pt<n>

>>

>> When printing, can you make sure that the length transferred is ne=
ver a

>> multiple of 64 bytes?

>>

>> Also, there might be a bug lurking in the USB host controller driv=
er,

>> like already mentioned.

>>

> 

> 

> Hi Hans,

> 

> I just figured-out the ulpt(4) driver in my Epson printer while compar=
ing

> with my Xprinter printer's USB device info. My Epson printer is pr=
oviding

> vendor specific values of 255 in the bInterfaceClass and bInterfaceSub=
Class

> respectively.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <Vendor=
 specific>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x00ff

> 

> It should be a value of 7 for bInterfaceClass and a value of 1 in

> bInterfaceSubClass.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x0007=C2=A0 <Printe=
r device>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0001

> 

> So, the ulpt_attach() routine below will break upon validation for

> mismatched values in UICLASS_PRINTER and=C2=A0 UISUBCLASS_PRINTER.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 } else {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClas=
s =3D=3D

> UICLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceSubClass =3D=3D

> UISUBCLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceProtocol =3D=3D

> UIPROTO_PRINTER_BI)) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 goto found;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }

> 

> What I did is temporarily replace these values in the USB definition. =
In

> this case, how should the project handle this non-compliance USB devic=
es?

> Though I will raise this to Epson if they could provide an updated fir=
mware.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig

> /usr/src/sys/dev/usb/usb.h

> --- /usr/src/sys/dev/usb/usb.h.orig=C2=A0 =C2=A0 =C2=A02022-03-27 02:5=
5:01.319235000 +0800

> +++ /usr/src/sys/dev/usb/usb.h=C2=A0 2022-03-27 02:57:10.608518000 +08=
00

> @@ -459,8 +459,10 @@

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PHYSICAL=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 0x05

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_IMAGE=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x06

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_SIC=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0/* still image clas=
s */

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x07

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 1

> +/* #define=C2=A0 =C2=A0 =C2=A0UICLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x07 */

> +/* #define=C2=A0 =C2=A0 =C2=A0UISUBCLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =
1 */

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00xff

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 0xff

> 

> I can print now with ulpt(4) driver but need further testing for any i=
ssues.

> 

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ulpt0 on uhub1

> ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> ulpt_attach: setting alternate config number: 0

> ulpt0: using bi-directional mode

> 



Hi,



I think you can just extend that piece of code to accept either value 

using a boolean OR, ||.


Hi Hans,

Ah okay, this is noted. I just thought it's not all=
owed. I already extended the code and on the way re-building the kernel.

Thanks,<=
/div>
Archimedes


--00000000000055ff3005db3402bb--

From nobody Sun Mar 27 21:00:15 2022
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 0B5F61A3C042
	for ; Sun, 27 Mar 2022 21:00:17 +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 4KRSrv6nfLz55b3
	for ; Sun, 27 Mar 2022 21:00:15 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 819271C7CA
	for ; Sun, 27 Mar 2022 21:00:15 +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 22RL0FwB067761
	for ; Sun, 27 Mar 2022 21:00:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22RL0FaT067760
	for freebsd-arm@FreeBSD.org; Sun, 27 Mar 2022 21:00:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202203272100.22RL0FaT067760@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, 27 Mar 2022 21:00:15 +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="16484148150.1a446.66697"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648414816;
	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=jYFrWf5VHA7YFlzqWIBTIihn8StCnzWcYfeKpM/7lgU=;
	b=uPwco456zOdhn2pqdSHN13D72Yupyap4A2NjEpTP2f8wH80L15H5LCbIPDypLRmZffWwwT
	XXMGSO0MeCo++AnlnwHe2vwhKi0LA4vvCNDqBywYHRB1KNg4I8CEsWLn2uX8mgR2VCK/W+
	vW1Qpk4n345Tuk473S/W4YON3RRd5n92fj9zx2FIzTL8d4pcwOLsJVH4UhIpRnoY9WPjTc
	mkNBPtm9YXJxDC/GOl3kb9SMUiLw8jd1UbWxtbEkU35GqKO5+fypnyIrPoyv/3dKMHb5eY
	PuG4LziGhPJjMKwo5BI7ilV1cxejOcJCyOjb7Regf4rf+TpR0waJ8lma8YOJ8g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648414816; a=rsa-sha256; cv=none;
	b=OPdpDGs8HuxAYxwn5Z6vXPKXbYUyqH6pYjpCdAJy24LPDmBhDyoJF93/NzDNvv/1I4OwK9
	ytcuKTtYdDq6+IByoeULnZfEX5XkfVMRnY8pwExdk3UiIKUstpAGWFNn9IDdzeF0jKsYox
	CFaj3qUMvLJAftTZSqiyJ8NljAHQiDHPlvEY775nD75zVoUSA1hsLiwMXDwjTo+w+2jV6H
	KactfwESOIiLRiyZDzKqXN1r3iUp9K2atBhIeFCA2WYnRKRY/ea3PQKzXWlCu39qn+vNfT
	/RFLxhIg2KYOaaz08TkIlvNeptgM0FJg5QxsVOKo+7imC5Rk+fnW7gOWC3f6QA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1798
Lines: 38


--16484148150.1a446.66697
Date: Sun, 27 Mar 2022 21:00:15 +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.

--16484148150.1a446.66697
Date: Sun, 27 Mar 2022 21:00:15 +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.


--16484148150.1a446.66697--

From nobody Tue Mar 29 19:17:55 2022
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 F37A21A4A795
	for ; Tue, 29 Mar 2022 19:17:55 +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 4KSfTv3xvPz5154
	for ; Tue, 29 Mar 2022 19:17:55 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 67F4A246E8
	for ; Tue, 29 Mar 2022 19:17:55 +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 22TJHtU2095005
	for ; Tue, 29 Mar 2022 19:17:55 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22TJHt2B095004
	for freebsd-arm@FreeBSD.org; Tue, 29 Mar 2022 19:17:55 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 262910] immintrin.h fails on arm64: error: use of undeclared
 identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
Date: Tue, 29 Mar 2022 19:17:55 +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: 13.0-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: yuri@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648581475;
	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=LcpeeGauxWycme+25dxQXKo18NUnzyQuKs63GehHLqA=;
	b=BTo56pZh+NuBkbA6HVoDFtZhRj9QaitCtzUmIsWqJd7zXUZyExFrloqg34Ho2VF7BahW9o
	3xq/fcxYRa1H1TMMWMuj49nbB523l0kAZXyD3WchtpWuNvGBCXjJ0VUdnfZOCc2kJv5DQn
	006qBQ3B3ZZGQo3rdNnoCesAs8BBnslWXEjPbXhrghd4283ZfoVAPwzp5+ssiemNwJVxKl
	BPjbtuZ0FNNWypX+A6FKgMURG5tMjVGEYppygXtmO+4xQ4+tDgV0XArUAgwPp00cqW1x4/
	yN8MN3Tf1H8zzo3lGQa4DFeGcQp7grA8+E4KL4Wgc1gX1G2AI6VOIqXGBBxkVA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648581475; a=rsa-sha256; cv=none;
	b=ufemX1SyqGCggp2zv/LRua1PcD1XkG1ZHRuFnqAesmxB6iVPdaRrthQN8S0xzqOWflnHoO
	xooejEhr0vhj95JbVHInF+06mTueCdTLKzgSDOhWc1x/8M6Qm+wl3xm09PweZmvcWyjzH1
	ZSaOxN1kUQj7PUriG9mTxMspGmdOBdVlTL0I+hCZ6X628Fsu9F1sy9TJTWlI/Q3YCE4XoS
	2PXNTdx/x0/VDd1Zc5TQVuN2t89oCMDGbRwFDlqXw6BgQKW/gsT2lyJP7ik0bTn9X/9F1e
	lKwzDnML+37S8MBfk/a9iTW4YjvvTEZlKVcltRNCTFaV+U0EqzvjqAf1CbHW3g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1394
Lines: 40

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262910

            Bug ID: 262910
           Summary: immintrin.h fails on arm64: error: use of undeclared
                    identifier '__builtin_ia32_emms'; did you mean
                    '__builtin_isless'?
           Product: Base System
           Version: 13.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: yuri@freebsd.org

The science/opensph port fails on arm64:

> In file included from /usr/lib/clang/11.0.1/include/immintrin.h:15:
> /usr/lib/clang/11.0.1/include/mmintrin.h:33:5: error: use of undeclared i=
dentifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
>     __builtin_ia32_emms();
>     ^
> /usr/include/c++/v1/math.h:649:12: note: '__builtin_isless' declared here
>     return isless(__lcpp_x, __lcpp_y);
           ^
> /usr/include/math.h:120:23: note: expanded from macro 'isless'
> #define isless(x, y)            __builtin_isless((x), (y))
>                                 ^

It seems that just include of immintrin.h causes the problem.

Log:
http://ampere3.nyi.freebsd.org/data/130arm64-default/60ab72786154/logs/Open=
SPH-0.3.8_4.log

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Mar 29 21:02:43 2022
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 D11281A3F68C
	for ; Tue, 29 Mar 2022 21:02:43 +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 4KShpq3mHbz3Q5t
	for ; Tue, 29 Mar 2022 21:02:43 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 614AE25F7F
	for ; Tue, 29 Mar 2022 21:02:43 +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 22TL2hhE051696
	for ; Tue, 29 Mar 2022 21:02:43 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 22TL2hT9051695
	for freebsd-arm@FreeBSD.org; Tue, 29 Mar 2022 21:02:43 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 262910] immintrin.h fails on arm64: error: use of undeclared
 identifier '__builtin_ia32_emms'; did you mean '__builtin_isless'?
Date: Tue, 29 Mar 2022 21:02:43 +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: 13.0-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: yuri@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Works As Intended
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648587763;
	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=+cxy/SA7841zllDcfDsU8vlby65KOyGeWc0AVFGYowc=;
	b=OtEi1pCCA9huN/bdK7vAdmVk0NMRMTmJO8+IxE8P8E2SARAbXNOgFSili0pugini3FMpdp
	PZCy6ebetE1muIKCLh1yEEdbU+BbtSC6CPx9hNyILUVp8OKqcExrPLQwReC0iDsHao7vdc
	Y6HUYkrPnGA4Cq/yy+GpRqjvSKdacsMJ/wDyCRgsRZ/bi7oUDm5JbqImnST6P8FfLqxmT8
	+T0hgpJWvaRQffiwDVnoSiZNHgOOCCN08g8UyPup1AzWcQh5kkEeAbbn7ADhKiM+GGfo6V
	vZRAYibCL8cxVDalKfk5BwYNqdtElmFdytD75HwR8xfcE/uHq9cC147XIdkR/g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648587763; a=rsa-sha256; cv=none;
	b=jSyZRJvjPakKx9RI+CPEMyhLZ9WnY0eq3F2T+Ca6OprMELQxFCcdAnIuFvAIiNWg9V7BPX
	Zc+Uqf8vXxJmGUl4SoeWbhqlLYar+uG8lQA8nx16zg6WE+U3+qpdJjxPmkdI+UOefJG47K
	if/2WRsWnOlWXnja/Hf7E1y8lxpXhj5md7NN4uRQQw32ldYfVhCGDwRvqUwd39vMX3mbbN
	RmilEOgvQ3rLkOz6A/OQJXHaNp7zcoxfvuBPZPKl3AM+ijM3ofpLw4v5nwOoOdUlKIrqz8
	/UPaGuv66wmoG8plsN3vRya3pTs8JITnPYR/6v33R02d+f3AXdaFBARDdURFjg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 549
Lines: 17

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262910

Yuri Victorovich  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |Works As Intended
             Status|New                         |Closed

--- Comment #4 from Yuri Victorovich  ---
Thanks.

I've added ONLY_FOR_ARCHS to the port.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Mar 31 11:52:58 2022
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 EB63F1A42E34
	for ; Thu, 31 Mar 2022 11:53:11 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4KThWp6Fr1z59St
	for ; Thu, 31 Mar 2022 11:53:10 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x634.google.com with SMTP id bi12so47638985ejb.3
        for ; Thu, 31 Mar 2022 04:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=/YXWZNX39x2HMuyWcSQF9zBTZYZ62ugeIabminyj7bc=;
        b=WbUicy2Jy1nccVakwEdocZ4p0h3yvtmXzGvigNifQbsh9ZZMEdYeC/HwckWnf6ZHjM
         GjxgxKvHKIz5XpMsxCZuGOAp0geMyvzivDmu4iM4iEFbFN4SH2cLNRzZ1wuvl/Ra0PUX
         xyMZqJXGKOPSe2veAbhFADxtIIWZjP5YPQKzt3+ec7mp6xGMWe375zjGXMc3K+q/FpMj
         Cq+VrEzWkGk0XxBaMSUomr0aDqx67ojmECE3I7V/TIW+Ay0EaxqLv6Fox5dQn3cilVGw
         2QdaSNnjuckKJ3wbPsy3PJ6j5jsnDqf+fgbSoI3+NWoleTZtt9j+ijO6EsVlV0qvT24k
         Bzeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=/YXWZNX39x2HMuyWcSQF9zBTZYZ62ugeIabminyj7bc=;
        b=uq2Aphs26pP39FHm5mj3PBeqqylrqseLZChjo5Tz52BYXQVD/ouLQaDmwb2Hna/zHo
         Rjhugyva6bQmFIUYhiRrSQR5IxcgN4InHZLta3moLXuFLtQgQZti6bXLPKUnQkq/hfK2
         PZYUeQFaUwign+vfrxbnA3XsQbr8ZmGyQ24x1ZpYs5PLpBxmhhs1wfFFlo7NGnVHiNq4
         qF/x4DlNEg/paI7XjzaEmjiNsyIUteGNz66RM/lQ/NJOdcFhM9pIx7dc4mzFn2Vect6l
         fHdC/47aIVxrKmfcEaiPBnejz9UPREjOs7sETVUUlPfTohJoxS2FEnHbOjsvk8alwuWW
         usVA==
X-Gm-Message-State: AOAM531nloDT5p+ace8f1Dw9Zh15lRQdnFjcp+lnxTXrKMMrRIdCBYrK
	WOlAOUTXENhndTQkMM088YmErX13VtZWU4PIRxqMftvPjYQtUA==
X-Google-Smtp-Source: ABdhPJxOVWqbKfQEthc3YeIrbK3dOS83CSwpUbK5p18mt1l6tPV2fb+6fnivC1cyZ/q7EWMsh+JbDtWe9i0vZUGiKwk=
X-Received: by 2002:a17:907:7284:b0:6df:9120:d935 with SMTP id
 dt4-20020a170907728400b006df9120d935mr4738513ejc.276.1648727589550; Thu, 31
 Mar 2022 04:53:09 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Thu, 31 Mar 2022 19:52:58 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000004e7db505db824ee0"
X-Rspamd-Queue-Id: 4KThWp6Fr1z59St
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=WbUicy2J;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.87 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.88)[-0.875];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 18128
Lines: 392

--0000000000004e7db505db824ee0
Content-Type: text/plain; charset="UTF-8"

On Sun, Mar 27, 2022 at 10:28 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky 
> wrote:
>
>> On 3/27/22 07:55, Archimedes Gaviola wrote:
>> > On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky 
>> wrote:
>> >
>> >> On 3/12/22 08:07, Archimedes Gaviola wrote:
>> >>> ugen1.5:  at usbus1
>> >>> ulpt1 on uhub1
>> >>> ulpt1:  on
>> usbus1
>> >>> device_attach: ulpt1 attach returned 12
>> >>
>> >> 12 : man errno :
>> >>        12 ENOMEM Cannot allocate memory.
>> >>
>> >> I guess the EPSON printer you've got is not compatible with ulpt
>> >>
>> >> When printing, can you make sure that the length transferred is never a
>> >> multiple of 64 bytes?
>> >>
>> >> Also, there might be a bug lurking in the USB host controller driver,
>> >> like already mentioned.
>> >>
>> >
>> >
>> > Hi Hans,
>> >
>> > I just figured-out the ulpt(4) driver in my Epson printer while
>> comparing
>> > with my Xprinter printer's USB device info. My Epson printer is
>> providing
>> > vendor specific values of 255 in the bInterfaceClass and
>> bInterfaceSubClass
>> > respectively.
>> >
>> >        bInterfaceClass = 0x00ff  
>> >        bInterfaceSubClass = 0x00ff
>> >
>> > It should be a value of 7 for bInterfaceClass and a value of 1 in
>> > bInterfaceSubClass.
>> >
>> >        bInterfaceClass = 0x0007  
>> >        bInterfaceSubClass = 0x0001
>> >
>> > So, the ulpt_attach() routine below will break upon validation for
>> > mismatched values in UICLASS_PRINTER and  UISUBCLASS_PRINTER.
>> >
>> >                          } else {
>> >                                  alt_index++;
>> >                                  if ((id->bInterfaceClass ==
>> > UICLASS_PRINTER) &&
>> >                                      (id->bInterfaceSubClass ==
>> > UISUBCLASS_PRINTER) &&
>> >                                      (id->bInterfaceProtocol ==
>> > UIPROTO_PRINTER_BI)) {
>> >                                          goto found;
>> >                                  }
>> >                          }
>> >
>> > What I did is temporarily replace these values in the USB definition. In
>> > this case, how should the project handle this non-compliance USB
>> devices?
>> > Though I will raise this to Epson if they could provide an updated
>> firmware.
>> >
>> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig
>> > /usr/src/sys/dev/usb/usb.h
>> > --- /usr/src/sys/dev/usb/usb.h.orig     2022-03-27 02:55:01.319235000
>> +0800
>> > +++ /usr/src/sys/dev/usb/usb.h  2022-03-27 02:57:10.608518000 +0800
>> > @@ -459,8 +459,10 @@
>> >   #define        UICLASS_PHYSICAL        0x05
>> >   #define        UICLASS_IMAGE           0x06
>> >   #define        UISUBCLASS_SIC          1       /* still image class */
>> > -#define        UICLASS_PRINTER         0x07
>> > -#define        UISUBCLASS_PRINTER      1
>> > +/* #define     UICLASS_PRINTER         0x07 */
>> > +/* #define     UISUBCLASS_PRINTER      1 */
>> > +#define        UICLASS_PRINTER         0xff
>> > +#define        UISUBCLASS_PRINTER      0xff
>> >
>> > I can print now with ulpt(4) driver but need further testing for any
>> issues.
>> >
>> > ugen1.5:  at usbus1
>> > ulpt0 on uhub1
>> > ulpt0:  on
>> usbus1
>> > ulpt_attach: setting alternate config number: 0
>> > ulpt0: using bi-directional mode
>> >
>>
>> Hi,
>>
>> I think you can just extend that piece of code to accept either value
>> using a boolean OR, ||.
>>
>
>
> Hi Hans,
>
> Ah okay, this is noted. I just thought it's not allowed. I already
> extended the code and on the way re-building the kernel.
>


Hi Hans,

Here are the changes I've done in the /usr/src/sys/dev/usb/serial/ulpt.c
source. This works both now with my Epson TM-U220B and Xprinter printers.
It can detect either or both in 14.0-CURRENT. So far I haven't encountered
any strange behavior while printing using this ulpt(4) driver.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
/usr/src/sys/dev/usb/serial/ulpt.c
--- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
19:44:29.178010000 +0800
+++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-03-31 16:57:53.317952000 +0800
@@ -495,6 +495,11 @@
         USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
         USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},

+       /* Bi-directional USB vendor specific */
+       {USB_IFACE_CLASS(UICLASS_VENDOR),
+        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
+        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
+
        /* 1284 USB printer */
        {USB_IFACE_CLASS(UICLASS_PRINTER),
         USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
@@ -555,9 +560,11 @@
                                break;
                        } else {
                                alt_index++;
-                               if ((id->bInterfaceClass ==
UICLASS_PRINTER) &&
-                                   (id->bInterfaceSubClass ==
UISUBCLASS_PRINTER) &&
-                                   (id->bInterfaceProtocol ==
UIPROTO_PRINTER_BI)) {
+                               if ((id->bInterfaceClass == UICLASS_PRINTER
||
+                                   id->bInterfaceClass == UICLASS_VENDOR)
&&
+                                   (id->bInterfaceSubClass ==
UISUBCLASS_PRINTER ||
+                                   id->bInterfaceClass ==
UISUBCLASS_VENDOR) &&
+                                   (id->bInterfaceProtocol ==
UIPROTO_PRINTER_BI)) {
                                        goto found;
                                }
                        }

In the /usr/src/sys/dev/usb/usbdevs, I think there's a need to include the
undefined TM-U220B.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
/usr/src/sys/dev/usb/usbdevs
--- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000 +0800
+++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000 +0800
@@ -1941,6 +1941,7 @@
 product EPSON 2480             0x0121  Perfection 2480 scanner
 product EPSON 3590             0x0122  Perfection 3590 scanner
 product EPSON 4990             0x012a  Perfection 4990 Photo scanner
+product EPSON TMU220B          0x0202  TM-U220B
 product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
 product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
 product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader

Thanks,
Archimedes

--0000000000004e7db505db824ee0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Mar 27, 2022 at 10:28 PM Arch=
imedes Gaviola <archimed=
es.gaviola@gmail.com> wrote:


On Sun, Mar 27, 2=
022 at 5:05 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/27/22 07:55, Archimedes Gaviola wrote=
:

> On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/12/22 08:07, Archimedes Gaviola wrote:

>>> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

>>> ulpt1 on uhub1

>>> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, add=
r 5> on usbus1

>>> device_attach: ulpt1 attach returned 12

>>

>> 12 : man errno :

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.

>>

>> I guess the EPSON printer you've got is not compatible with ul=
pt<n>

>>

>> When printing, can you make sure that the length transferred is ne=
ver a

>> multiple of 64 bytes?

>>

>> Also, there might be a bug lurking in the USB host controller driv=
er,

>> like already mentioned.

>>

> 

> 

> Hi Hans,

> 

> I just figured-out the ulpt(4) driver in my Epson printer while compar=
ing

> with my Xprinter printer's USB device info. My Epson printer is pr=
oviding

> vendor specific values of 255 in the bInterfaceClass and bInterfaceSub=
Class

> respectively.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <Vendor=
 specific>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x00ff

> 

> It should be a value of 7 for bInterfaceClass and a value of 1 in

> bInterfaceSubClass.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x0007=C2=A0 <Printe=
r device>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0001

> 

> So, the ulpt_attach() routine below will break upon validation for

> mismatched values in UICLASS_PRINTER and=C2=A0 UISUBCLASS_PRINTER.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 } else {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClas=
s =3D=3D

> UICLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceSubClass =3D=3D

> UISUBCLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceProtocol =3D=3D

> UIPROTO_PRINTER_BI)) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 goto found;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }

> 

> What I did is temporarily replace these values in the USB definition. =
In

> this case, how should the project handle this non-compliance USB devic=
es?

> Though I will raise this to Epson if they could provide an updated fir=
mware.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig

> /usr/src/sys/dev/usb/usb.h

> --- /usr/src/sys/dev/usb/usb.h.orig=C2=A0 =C2=A0 =C2=A02022-03-27 02:5=
5:01.319235000 +0800

> +++ /usr/src/sys/dev/usb/usb.h=C2=A0 2022-03-27 02:57:10.608518000 +08=
00

> @@ -459,8 +459,10 @@

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PHYSICAL=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 0x05

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_IMAGE=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x06

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_SIC=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0/* still image clas=
s */

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x07

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 1

> +/* #define=C2=A0 =C2=A0 =C2=A0UICLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x07 */

> +/* #define=C2=A0 =C2=A0 =C2=A0UISUBCLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =
1 */

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00xff

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 0xff

> 

> I can print now with ulpt(4) driver but need further testing for any i=
ssues.

> 

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ulpt0 on uhub1

> ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> ulpt_attach: setting alternate config number: 0

> ulpt0: using bi-directional mode

> 



Hi,



I think you can just extend that piece of code to accept either value 

using a boolean OR, ||.


Hi Hans,

Ah okay, this is noted. I just thought it's not all=
owed. I already extended the code and on the way re-building the kernel.


Hi Hans,

Here are the changes I've done in the /usr/src/sys/dev/=
usb/serial/ulpt.c source. This works both now with my Epson TM-U220B and Xp=
rinter printers. It can detect either or both in 14.0-CURRENT. So far I hav=
en't encountered any strange behavior while printing using this ulpt(4)=
 driver.

freebsd@generic:~ % diff -Nur /usr/sr=
c/sys/dev/usb/serial/ulpt.c.orig /usr/src/sys/dev/usb/serial/ulpt.c
--- =
/usr/src/sys/dev/usb/serial/ulpt.c.orig =C2=A0 =C2=A0 2022-03-21 19:44:29.1=
78010000 +0800
+++ /usr/src/sys/dev/usb/serial/ulpt.c =C2=A02022-03-31 1=
6:57:53.317952000 +0800
@@ -495,6 +495,11 @@
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},

+ =C2=A0 =C2=
=A0 =C2=A0 /* Bi-directional USB vendor specific */
+ =C2=A0 =C2=A0 =C2=
=A0 {USB_IFACE_CLASS(UICLASS_VENDOR),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_I=
FACE_SUBCLASS(UISUBCLASS_VENDOR),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE=
_PROTOCOL(UIPROTO_PRINTER_BI)},
+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 1284=
 USB printer */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {USB_IFACE_CLASS(UICLASS_PRI=
NTER),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_P=
RINTER),
@@ -555,9 +560,11 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b=
reak;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_inde=
x++;
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClass =3D=
=3D UICLASS_PRINTER) &&
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (id->bInterfaceSubClass =3D=3D UISUBCLASS_PRINTER) &&
=
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceProtocol =
=3D=3D UIPROTO_PRINTER_BI)) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id-=
>bInterfaceClass =3D=3D UICLASS_PRINTER ||
+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 id->bInterfaceClass =3D=3D UICLASS_VENDOR) &&am=
p;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceSubC=
lass =3D=3D UISUBCLASS_PRINTER ||
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 id->bInterfaceClass =3D=3D UISUBCLASS_VENDOR) &&
+=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceProtocol =
=3D=3D UIPROTO_PRINTER_BI)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 goto found;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }

In the=20
/usr/src/sys/dev/usb/usbdevs, I think there's a need to include the und=
efined TM-U220B.

freebsd@generic:~ % diff -Nur=
 /usr/src/sys/dev/usb/usbdevs.orig /usr/src/sys/dev/usb/usbdevs
--- /usr=
/src/sys/dev/usb/usbdevs.orig =C2=A0 2022-03-21 19:42:20.999397000 +0800+++ /usr/src/sys/dev/usb/usbdevs =C2=A0 =C2=A0 =C2=A0 =C2=A02022-04-01 01:=
21:31.361567000 +0800
@@ -1941,6 +1941,7 @@
=C2=A0product EPSON 2480 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0121 =C2=A0Perfection 2480 scan=
ner
=C2=A0product EPSON 3590 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0=
x0122 =C2=A0Perfection 3590 scanner
=C2=A0product EPSON 4990 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x012a =C2=A0Perfection 4990 Photo scanner<=
br>+product EPSON TMU220B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0202 =C2=A0TM=
-U220B
=C2=A0product EPSON CRESSI_EDY =C2=A0 =C2=A0 =C2=A0 0x0521 =C2=A0=
Cressi Edy diving computer
=C2=A0product EPSON N2ITION3 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 0x0522 =C2=A0Zeagle N2iTion3 diving computer
=C2=A0product=
 EPSON STYLUS_875DC =C2=A0 =C2=A0 0x0601 =C2=A0Stylus Photo 875DC Card Read=
er

Thanks,
Archimedes



--0000000000004e7db505db824ee0--

From nobody Thu Mar 31 12:03:23 2022
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 06D3E1A45751
	for ; Thu, 31 Mar 2022 12:03:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4KThlr2W1Qz3DHW
	for ; Thu, 31 Mar 2022 12:03:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id dr20so47575636ejc.6
        for ; Thu, 31 Mar 2022 05:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=bKTIfCvnurskKfyoT9VgNyMiIgdJMqorQxx2cJFwabs=;
        b=XrzuJQaNnBr35msXhPooY4I1PurUv9dg/0U/SZM+zvXcSBVanWH0eYQdg9GyIibghN
         7aoE7SfqEFZZ09MSjjQENgyjORUS2+ww0833ecxelznn7AdNlvagisN56nlYnLelVLuJ
         lqDj0RnXjuVg2VsdNbXfAkkEx2R3VRm33r+BfCJmZKKd/fr6ZDkgM2Bb+CEFyeHIZdz0
         KiTkFxaDS5PdezgWQooMu+hFbKgjyAD1otBsBRzoUs19Ql6KH4jV1+H1tPfDCCyqORBo
         dI1pvOHBjDfZ65iVs3xFb8nlJhRtXLr1xBB58Qcbmx52XJK5NX0sqGVlAvn4aNr8EWl3
         xwfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=bKTIfCvnurskKfyoT9VgNyMiIgdJMqorQxx2cJFwabs=;
        b=XvVTZte3qlJHI6NBCgYl9Sp8BNErrKCB3ctuJgu1qwFIibr1uIaEpZ84Llvu3dnI7z
         l6z9W879iI7rIexgnUe7/BeFMLs0DqWqqC6W1q/G19CKw2aK+toJZixxO6eMHk2TCGtb
         g4qorUQtGiJWp77q3VRybmVrmT7Kihtq66L0UHNbg/XBCHRhtMDxQfhtrLuKeNskNgqj
         Jaw1G/S7uL74K9DiCv9194NiS8j1EcRhR44XZOEy95EDUkbMOY1F2h+AUdYZYcJ+uIG2
         oTzzngxOKQGjnFRnJpFL/3K8628TG6DnO1/WiRT500NGJ8ofGj34q4wFiYnBr6hnj06I
         BMmw==
X-Gm-Message-State: AOAM532QLk52XyQkBVB6IUDidD1SWEj8xevn51FLMwXkq5TtkV3vPTJK
	Dihe6tFyNY8bhoYnF+qT+AUSB6DxtkJvI0yd7cQU7jbC+Oligg==
X-Google-Smtp-Source: ABdhPJybmbAGZL+8zP/fC5eo2Ns6mD/30wO9AoxqY8z3nyPHUGhllZ/biqoehDzVVw8/Im6fANg3D/cBQbvkpXou7j8=
X-Received: by 2002:a17:907:6d9d:b0:6da:7d4c:287f with SMTP id
 sb29-20020a1709076d9d00b006da7d4c287fmr4438216ejc.741.1648728215226; Thu, 31
 Mar 2022 05:03:35 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Thu, 31 Mar 2022 20:03:23 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000099913005db827320"
X-Rspamd-Queue-Id: 4KThlr2W1Qz3DHW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=XrzuJQaN;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 20035
Lines: 426

--00000000000099913005db827320
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 31, 2022 at 7:52 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sun, Mar 27, 2022 at 10:28 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>> On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky 
>> wrote:
>>
>>> On 3/27/22 07:55, Archimedes Gaviola wrote:
>>> > On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky 
>>> wrote:
>>> >
>>> >> On 3/12/22 08:07, Archimedes Gaviola wrote:
>>> >>> ugen1.5:  at usbus1
>>> >>> ulpt1 on uhub1
>>> >>> ulpt1:  on
>>> usbus1
>>> >>> device_attach: ulpt1 attach returned 12
>>> >>
>>> >> 12 : man errno :
>>> >>        12 ENOMEM Cannot allocate memory.
>>> >>
>>> >> I guess the EPSON printer you've got is not compatible with ulpt
>>> >>
>>> >> When printing, can you make sure that the length transferred is never
>>> a
>>> >> multiple of 64 bytes?
>>> >>
>>> >> Also, there might be a bug lurking in the USB host controller driver,
>>> >> like already mentioned.
>>> >>
>>> >
>>> >
>>> > Hi Hans,
>>> >
>>> > I just figured-out the ulpt(4) driver in my Epson printer while
>>> comparing
>>> > with my Xprinter printer's USB device info. My Epson printer is
>>> providing
>>> > vendor specific values of 255 in the bInterfaceClass and
>>> bInterfaceSubClass
>>> > respectively.
>>> >
>>> >        bInterfaceClass = 0x00ff  
>>> >        bInterfaceSubClass = 0x00ff
>>> >
>>> > It should be a value of 7 for bInterfaceClass and a value of 1 in
>>> > bInterfaceSubClass.
>>> >
>>> >        bInterfaceClass = 0x0007  
>>> >        bInterfaceSubClass = 0x0001
>>> >
>>> > So, the ulpt_attach() routine below will break upon validation for
>>> > mismatched values in UICLASS_PRINTER and  UISUBCLASS_PRINTER.
>>> >
>>> >                          } else {
>>> >                                  alt_index++;
>>> >                                  if ((id->bInterfaceClass ==
>>> > UICLASS_PRINTER) &&
>>> >                                      (id->bInterfaceSubClass ==
>>> > UISUBCLASS_PRINTER) &&
>>> >                                      (id->bInterfaceProtocol ==
>>> > UIPROTO_PRINTER_BI)) {
>>> >                                          goto found;
>>> >                                  }
>>> >                          }
>>> >
>>> > What I did is temporarily replace these values in the USB definition.
>>> In
>>> > this case, how should the project handle this non-compliance USB
>>> devices?
>>> > Though I will raise this to Epson if they could provide an updated
>>> firmware.
>>> >
>>> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig
>>> > /usr/src/sys/dev/usb/usb.h
>>> > --- /usr/src/sys/dev/usb/usb.h.orig     2022-03-27 02:55:01.319235000
>>> +0800
>>> > +++ /usr/src/sys/dev/usb/usb.h  2022-03-27 02:57:10.608518000 +0800
>>> > @@ -459,8 +459,10 @@
>>> >   #define        UICLASS_PHYSICAL        0x05
>>> >   #define        UICLASS_IMAGE           0x06
>>> >   #define        UISUBCLASS_SIC          1       /* still image class
>>> */
>>> > -#define        UICLASS_PRINTER         0x07
>>> > -#define        UISUBCLASS_PRINTER      1
>>> > +/* #define     UICLASS_PRINTER         0x07 */
>>> > +/* #define     UISUBCLASS_PRINTER      1 */
>>> > +#define        UICLASS_PRINTER         0xff
>>> > +#define        UISUBCLASS_PRINTER      0xff
>>> >
>>> > I can print now with ulpt(4) driver but need further testing for any
>>> issues.
>>> >
>>> > ugen1.5:  at usbus1
>>> > ulpt0 on uhub1
>>> > ulpt0:  on
>>> usbus1
>>> > ulpt_attach: setting alternate config number: 0
>>> > ulpt0: using bi-directional mode
>>> >
>>>
>>> Hi,
>>>
>>> I think you can just extend that piece of code to accept either value
>>> using a boolean OR, ||.
>>>
>>
>>
>> Hi Hans,
>>
>> Ah okay, this is noted. I just thought it's not allowed. I already
>> extended the code and on the way re-building the kernel.
>>
>
>
> Hi Hans,
>
> Here are the changes I've done in the /usr/src/sys/dev/usb/serial/ulpt.c
> source. This works both now with my Epson TM-U220B and Xprinter printers.
> It can detect either or both in 14.0-CURRENT. So far I haven't encountered
> any strange behavior while printing using this ulpt(4) driver.
>
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
> /usr/src/sys/dev/usb/serial/ulpt.c
> --- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
> 19:44:29.178010000 +0800
> +++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-03-31 16:57:53.317952000 +0800
> @@ -495,6 +495,11 @@
>          USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
>          USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
>
> +       /* Bi-directional USB vendor specific */
> +       {USB_IFACE_CLASS(UICLASS_VENDOR),
> +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
> +
>         /* 1284 USB printer */
>         {USB_IFACE_CLASS(UICLASS_PRINTER),
>          USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
> @@ -555,9 +560,11 @@
>                                 break;
>                         } else {
>                                 alt_index++;
> -                               if ((id->bInterfaceClass ==
> UICLASS_PRINTER) &&
> -                                   (id->bInterfaceSubClass ==
> UISUBCLASS_PRINTER) &&
> -                                   (id->bInterfaceProtocol ==
> UIPROTO_PRINTER_BI)) {
> +                               if ((id->bInterfaceClass ==
> UICLASS_PRINTER ||
> +                                   id->bInterfaceClass == UICLASS_VENDOR)
> &&
> +                                   (id->bInterfaceSubClass ==
> UISUBCLASS_PRINTER ||
> +                                   id->bInterfaceClass ==
> UISUBCLASS_VENDOR) &&
> +                                   (id->bInterfaceProtocol ==
> UIPROTO_PRINTER_BI)) {
>                                         goto found;
>                                 }
>                         }
>
> In the /usr/src/sys/dev/usb/usbdevs, I think there's a need to include the
> undefined TM-U220B.
>
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
> /usr/src/sys/dev/usb/usbdevs
> --- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000 +0800
> +++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000 +0800
> @@ -1941,6 +1941,7 @@
>  product EPSON 2480             0x0121  Perfection 2480 scanner
>  product EPSON 3590             0x0122  Perfection 3590 scanner
>  product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> +product EPSON TMU220B          0x0202  TM-U220B
>  product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
>  product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
>  product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
>


Here's the dmesg showing ulpt0 and ulpt1 respectively with my printers.

ugen1.5:  at usbus1
ugen1.6:  at usbus1
ulpt0 on uhub1
ulpt0:  on usbus1
ulpt0: using bi-directional mode
ulpt1 on uhub1
ulpt1: 
on usbus1
ulpt1: using bi-directional mode
ulpt1: offline

--00000000000099913005db827320
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 31, 2022 at 7:52 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Sun, Mar 27, 20=
22 at 10:28 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div dir=3D"ltr">

On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky <=
;hps@selasky.org&g=
t; wrote:
On 3/2=
7/22 07:55, Archimedes Gaviola wrote:

> On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/12/22 08:07, Archimedes Gaviola wrote:

>>> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

>>> ulpt1 on uhub1

>>> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, add=
r 5> on usbus1

>>> device_attach: ulpt1 attach returned 12

>>

>> 12 : man errno :

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.

>>

>> I guess the EPSON printer you've got is not compatible with ul=
pt<n>

>>

>> When printing, can you make sure that the length transferred is ne=
ver a

>> multiple of 64 bytes?

>>

>> Also, there might be a bug lurking in the USB host controller driv=
er,

>> like already mentioned.

>>

> 

> 

> Hi Hans,

> 

> I just figured-out the ulpt(4) driver in my Epson printer while compar=
ing

> with my Xprinter printer's USB device info. My Epson printer is pr=
oviding

> vendor specific values of 255 in the bInterfaceClass and bInterfaceSub=
Class

> respectively.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <Vendor=
 specific>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x00ff

> 

> It should be a value of 7 for bInterfaceClass and a value of 1 in

> bInterfaceSubClass.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x0007=C2=A0 <Printe=
r device>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0001

> 

> So, the ulpt_attach() routine below will break upon validation for

> mismatched values in UICLASS_PRINTER and=C2=A0 UISUBCLASS_PRINTER.

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 } else {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClas=
s =3D=3D

> UICLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceSubClass =3D=3D

> UISUBCLASS_PRINTER) &&

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt=
erfaceProtocol =3D=3D

> UIPROTO_PRINTER_BI)) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 goto found;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }

> 

> What I did is temporarily replace these values in the USB definition. =
In

> this case, how should the project handle this non-compliance USB devic=
es?

> Though I will raise this to Epson if they could provide an updated fir=
mware.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig

> /usr/src/sys/dev/usb/usb.h

> --- /usr/src/sys/dev/usb/usb.h.orig=C2=A0 =C2=A0 =C2=A02022-03-27 02:5=
5:01.319235000 +0800

> +++ /usr/src/sys/dev/usb/usb.h=C2=A0 2022-03-27 02:57:10.608518000 +08=
00

> @@ -459,8 +459,10 @@

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PHYSICAL=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 0x05

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_IMAGE=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x06

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_SIC=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0/* still image clas=
s */

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00x07

> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 1

> +/* #define=C2=A0 =C2=A0 =C2=A0UICLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x07 */

> +/* #define=C2=A0 =C2=A0 =C2=A0UISUBCLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =
1 */

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00xff

> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 =
=C2=A0 0xff

> 

> I can print now with ulpt(4) driver but need further testing for any i=
ssues.

> 

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ulpt0 on uhub1

> ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> ulpt_attach: setting alternate config number: 0

> ulpt0: using bi-directional mode

> 



Hi,



I think you can just extend that piece of code to accept either value 

using a boolean OR, ||.


Hi Hans,

Ah okay, this is noted. I just thought it's not all=
owed. I already extended the code and on the way re-building the kernel.


Hi Hans,

Here are the changes I've done in the /usr/src/sys/dev/=
usb/serial/ulpt.c source. This works both now with my Epson TM-U220B and Xp=
rinter printers. It can detect either or both in 14.0-CURRENT. So far I hav=
en't encountered any strange behavior while printing using this ulpt(4)=
 driver.

freebsd@generic:~ % diff -Nur /usr/sr=
c/sys/dev/usb/serial/ulpt.c.orig /usr/src/sys/dev/usb/serial/ulpt.c
--- =
/usr/src/sys/dev/usb/serial/ulpt.c.orig =C2=A0 =C2=A0 2022-03-21 19:44:29.1=
78010000 +0800
+++ /usr/src/sys/dev/usb/serial/ulpt.c =C2=A02022-03-31 1=
6:57:53.317952000 +0800
@@ -495,6 +495,11 @@
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},

+ =C2=A0 =C2=
=A0 =C2=A0 /* Bi-directional USB vendor specific */
+ =C2=A0 =C2=A0 =C2=
=A0 {USB_IFACE_CLASS(UICLASS_VENDOR),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_I=
FACE_SUBCLASS(UISUBCLASS_VENDOR),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE=
_PROTOCOL(UIPROTO_PRINTER_BI)},
+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 1284=
 USB printer */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {USB_IFACE_CLASS(UICLASS_PRI=
NTER),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_P=
RINTER),
@@ -555,9 +560,11 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b=
reak;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_inde=
x++;
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClass =3D=
=3D UICLASS_PRINTER) &&
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (id->bInterfaceSubClass =3D=3D UISUBCLASS_PRINTER) &&
=
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceProtocol =
=3D=3D UIPROTO_PRINTER_BI)) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id-=
>bInterfaceClass =3D=3D UICLASS_PRINTER ||
+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 id->bInterfaceClass =3D=3D UICLASS_VENDOR) &&am=
p;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceSubC=
lass =3D=3D UISUBCLASS_PRINTER ||
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 id->bInterfaceClass =3D=3D UISUBCLASS_VENDOR) &&
+=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceProtocol =
=3D=3D UIPROTO_PRINTER_BI)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 goto found;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }

In the=20
/usr/src/sys/dev/usb/usbdevs, I think there's a need to include the und=
efined TM-U220B.

freebsd@generic:~ % diff -Nur=
 /usr/src/sys/dev/usb/usbdevs.orig /usr/src/sys/dev/usb/usbdevs
--- /usr=
/src/sys/dev/usb/usbdevs.orig =C2=A0 2022-03-21 19:42:20.999397000 +0800+++ /usr/src/sys/dev/usb/usbdevs =C2=A0 =C2=A0 =C2=A0 =C2=A02022-04-01 01:=
21:31.361567000 +0800
@@ -1941,6 +1941,7 @@
=C2=A0product EPSON 2480 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0121 =C2=A0Perfection 2480 scan=
ner
=C2=A0product EPSON 3590 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0=
x0122 =C2=A0Perfection 3590 scanner
=C2=A0product EPSON 4990 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x012a =C2=A0Perfection 4990 Photo scanner<=
br>+product EPSON TMU220B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0202 =C2=A0TM=
-U220B
=C2=A0product EPSON CRESSI_EDY =C2=A0 =C2=A0 =C2=A0 0x0521 =C2=A0=
Cressi Edy diving computer
=C2=A0product EPSON N2ITION3 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 0x0522 =C2=A0Zeagle N2iTion3 diving computer
=C2=A0product=
 EPSON STYLUS_875DC =C2=A0 =C2=A0 0x0601 =C2=A0Stylus Photo 875DC Card Read=
er


Here's the dmesg showing ulpt0 and ulpt1 respectively with my printers=
.

=
ugen1.5: <EPSON EPSON UB-U03II> at usbus1
ugen1.6: <Printer-58 =
USB Printing Support> at usbus1
ulpt0 on uhub1
ulpt0: <EPSON EP=
SON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> on usbus1
ulpt0: usin=
g bi-directional mode
ulpt1 on uhub1
ulpt1: <Printer-58 USB Printi=
ng Support, class 0/0, rev 2.00/2.54, addr 6> on usbus1
ulpt1: using =
bi-directional mode
ulpt1: offline
<=
br>



--00000000000099913005db827320--

From nobody Thu Mar 31 13:22:15 2022
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 8732C1A5693A
	for ; Thu, 31 Mar 2022 13:22:24 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KTkVl4CDRz3PC0
	for ; Thu, 31 Mar 2022 13:22:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 355072600D1;
	Thu, 31 Mar 2022 15:22:16 +0200 (CEST)
Message-ID: 
Date: Thu, 31 Mar 2022 15:22:15 +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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
 
 
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KTkVl4CDRz3PC0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 404
Lines: 11

On 3/31/22 13:52, Archimedes Gaviola wrote:
> +       /* Bi-directional USB vendor specific */
> +       {USB_IFACE_CLASS(UICLASS_VENDOR),
> +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},

Can you use the product ID and vendor ID in addition to the IFACE_CLASS 
in the match? Then it will be safe for other devices too, and I can 
upstream it.

--HPS

From nobody Thu Mar 31 13:52:59 2022
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 A9FBE1A3E49D
	for ; Thu, 31 Mar 2022 13:53:18 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4KTlBP6Qjsz3jyx
	for ; Thu, 31 Mar 2022 13:53:17 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62d.google.com with SMTP id bq8so34314955ejb.10
        for ; Thu, 31 Mar 2022 06:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=jFr/JYFzsGbVyuaBx4yhDeGNU96+8E0h78z9O1Gjhtg=;
        b=JpfBwnjCcf9LUiZrJ0YuMijSgZ7/mEBbRLL8dMvc7kPKYyEeR9G+7ITEHQnx3lqs7h
         rZT3ctcCfhvPSjjuM7An2ZDQR/LKQZl5ikXu4pIpGMzSwT9OPhOzepLmFGwiXur7iarv
         mxNFuNuRkpQ4nhdyEI6K0BNDnLebj1mLRPzq2JQbMO9OKe/yYiNtUlbNpM897tW1o76N
         /DLyTH9oBv9UVqI3I6F8rVFFL1Me3tc5CAG/Y4QJbMIA9rPYAoV+KTO3wS4gQxHmwZIc
         0eEznCVKaoZXsb2KXkymf11Hbb2U4eoJkSxhng2wxzSBjr/rWJSLMLUIPyFLgJilFSCQ
         sCnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=jFr/JYFzsGbVyuaBx4yhDeGNU96+8E0h78z9O1Gjhtg=;
        b=n+evpfeX2aLHrsRb5wqJlq2PyTwSL4P5EaGUvIMwD6v0ls5k6eINJF5t+V8DSRbYxk
         CdRPHGQkmqJ64f/o1LGjJbrQyWYVRcxS5KsUt8MyGaA8IOsTOP9UtStjESkynMMrcbQK
         b4Ul2xdNZIQbQdjlD+BKAg/SNJ7GCuH0RESSD5UhpAhwDNjBZECOftM5B6sd3vaakx8X
         i8sFVK2u+9vB1IqVBxhvF+FUWNfqioUmJOFXp13q8t6MEby3FsCSn1pOOpGhgf7tGWey
         vyJUq8WOWjorhtNJo8CSyr/OotYizU8kd2JkKn7Yd2Ms4mLjBj78sV9cXM9Yz1yxOwQS
         la1w==
X-Gm-Message-State: AOAM530wVqEBtthiENZm8b+5fTiiE7kuGKQLKTofO5mmlEhmKWaYB6bf
	n1/Dsscz4xgMULbjepDr4liTUpuzFh7lqwjBEu8tqBebywH6cQ==
X-Google-Smtp-Source: ABdhPJwOihPbdWpSUJ8j9e3K56EVbMmLPe6i9ocLxgNF6QZhHZBACKGGaYTaZTZdlwrJgWgEoH3/aU9Tq7e1ktB4EUw=
X-Received: by 2002:a17:906:7304:b0:6e0:6918:ef6f with SMTP id
 di4-20020a170906730400b006e06918ef6fmr5028367ejc.370.1648734790659; Thu, 31
 Mar 2022 06:53:10 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Thu, 31 Mar 2022 21:52:59 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000086b3f505db83fb90"
X-Rspamd-Queue-Id: 4KTlBP6Qjsz3jyx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=JpfBwnjC;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2283
Lines: 52

--00000000000086b3f505db83fb90
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 31, 2022 at 9:22 PM Hans Petter Selasky  wrote:

> On 3/31/22 13:52, Archimedes Gaviola wrote:
> > +       /* Bi-directional USB vendor specific */
> > +       {USB_IFACE_CLASS(UICLASS_VENDOR),
> > +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> > +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
>
> Can you use the product ID and vendor ID in addition to the IFACE_CLASS
> in the match? Then it will be safe for other devices too, and I can
> upstream it.
>

Are you pertaining to this code Hans, the one you've shared to me
previously?

+       /* Epson printer */
+       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},

--00000000000086b3f505db83fb90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Mar 31, 2022 at 9:22 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/3=
1/22 13:52, Archimedes Gaviola wrote:

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Bi-directional USB vendor specific */
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_IFACE_CLASS(UICLASS_VENDOR),

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},<=
br>


Can you use the product ID and vendor ID in addition to the IFACE_CLASS 
in the match? Then it will be safe for other devices too, and I can 

upstream it.

Are you pertaining to this co=
de Hans, the one you've shared to me previously?

+ =C2=A0 =C2=A0 =C2=A0 /=
* Epson printer */
+ =C2=A0 =C2=A0 =C2=A0 {USB_VPI(USB_VENDOR_EPSON, USB=
_PRODUCT_EPSON_TMU220B, 0)},





--00000000000086b3f505db83fb90--

From nobody Thu Mar 31 16:01:13 2022
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 67DBA1A3C561
	for ; Thu, 31 Mar 2022 16:01:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KTp285Tq4z4Xd3
	for ; Thu, 31 Mar 2022 16:01:20 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id EC52A2600D1;
	Thu, 31 Mar 2022 18:01:12 +0200 (CEST)
Message-ID: <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org>
Date: Thu, 31 Mar 2022 18:01:13 +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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org>
 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
 
 
 
 
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KTp285Tq4z4Xd3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 298
Lines: 10

On 3/31/22 15:52, Archimedes Gaviola wrote:
> Are you pertaining to this code Hans, the one you've shared to me
> previously?
> 
> +       /* Epson printer */
> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},

Yes, but you can also add the IFACE_XXX ones with "," simply.

--HPS

From nobody Fri Apr  1 13:51:12 2022
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 755941A390C9
	for ; Fri,  1 Apr 2022 13:51:22 +0000 (UTC)
	(envelope-from lm@lukaszmoskala.pl)
Received: from lukaszmoskala.pl (mail2.lukaszmoskala.pl [IPv6:2001:470:71:5c5::129:2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KVM5j3FvZz4qd2
	for ; Fri,  1 Apr 2022 13:51:21 +0000 (UTC)
	(envelope-from lm@lukaszmoskala.pl)
Received: by lukaszmoskala.pl (Postfix, from userid 5555)
	id 3EBA760626; Fri,  1 Apr 2022 15:51:13 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 lukaszmoskala.pl 3EBA760626
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukaszmoskala.pl;
	s=mail; t=1648821073;
	bh=7dvMlLtYHyq+PZ4XkGYqGFikbz9WtYvFvKKwWxHlWNc=;
	h=Date:To:From:Subject:From;
	b=UuH5gLK/YSf5nKlaDiCLMkAWw1SRYjkXaaQN11ANVte4HVpkmvDNWyishpL1VHZK6
	 lzbaL4g5LcOepN553mVMhjkiRGP/VOvaau61WTVXIAT4kZUfjbkJNlZxil2e85zxmF
	 csWgMCJsOb1bnGK2MVe4NzHgjpQCf/podjhTshLI=
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	mail2.lukaszmoskala.pl
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: from [IPV6:2001:470:612d:1337:f171:8c08:6007:5a65] (unknown [IPv6:2001:470:612d:1337:f171:8c08:6007:5a65])
	by lukaszmoskala.pl (Postfix) with ESMTPSA id CD34960624
	for ; Fri,  1 Apr 2022 15:51:12 +0200 (CEST)
Message-ID: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl>
Date: Fri, 1 Apr 2022 15:51:12 +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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: =?UTF-8?Q?=c5=81ukasz_Moska=c5=82a?= 
Subject: Booting rock64 from USB SSD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4KVM5j3FvZz4qd2
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lukaszmoskala.pl header.s=mail header.b="UuH5gLK/";
	dmarc=pass (policy=none) header.from=lukaszmoskala.pl;
	spf=pass (mx1.freebsd.org: domain of lm@lukaszmoskala.pl designates 2001:470:71:5c5::129:2 as permitted sender) smtp.mailfrom=lm@lukaszmoskala.pl
X-Spamd-Result: default: False [-2.75 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lukaszmoskala.pl:s=mail];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2001:470:71:5c5::129:2];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[lukaszmoskala.pl:+];
	 DMARC_POLICY_ALLOW(-0.50)[lukaszmoskala.pl,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 R_MIXED_CHARSET(1.25)[subject];
	 ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1010
Lines: 27

Hi everyone,

I want to boot my rock64 from SSD (because all sd cards I could find are 
crap).

I followed those instructions to flash u-boot to SPI: 
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md

I was then able to boot FreeBSD from SSD (dd 
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SSD, just like it would 
be to SD card), but ethernet wasn't working. Actually, it could receive 
packets but no outgoing packets were sent. Not even ARP packets - switch 
didn't detect any device on that port, but link was UP

I assumed it was something to do with u-boot, so I erased u-boot from 
flash, then DD FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SD card, 
and it worked without problems.

Do I understand correctly that this means that FreeBSD on rock64 uses 
custom u-boot? Can I somehow flash it to SPI?

Possible workaround that I can think of would be to put /boot on sd 
card, install u-boot to sd card, then put / on SSD.

Thanks in advance
-- 
Łukasz Moskała

From nobody Fri Apr  1 20:52:34 2022
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 B24F81A5FF25
	for ; Fri,  1 Apr 2022 20:52:47 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KVXRy5ncvz3s5d
	for ; Fri,  1 Apr 2022 20:52:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648846359; bh=n+YkO1XPIP0/L8j6hzV40Gv3TGkP+FSoXEYzewF2lpQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lfVorst74GWlfj1G60uUciutXjsZXbVKKD5UtwdRchHfxLDEHIDSmNWIM5LqLFw2DFo3qqVWT++BeiWGB/RdAGcmITwM1/DFFY4g5pXXTlTm+nk7nzYmsGx/l0AlV+ctY8qAPErGKaNR5Qs/5ns2p1Tdt7VQkp0hQGHtLWndwjHHw7SfkXvODuFOAi1UjTOEfaqWYWe3XDH6349+y5cdzDT1mfYyZDJAJu0WRIaIeQ4f+wfj0V6qml75jPIGcDChVWeWAD85ipxUCp6HHEu1aSka5gxD6iAZlCcSk5dhKeHimfeBTv1tFY8F0oePkfzD7QghPAqlXTCa2y5nGNBwTw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648846359; bh=1fDc005ASzFWSjWrKr1qlExPEX6mZkuctRXMMEhRNE4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e3nMozgCqTrjWBGrNPjvgbgKVCrZjyS8p6HPhDPyy4suBlzaMgLD3ruZadmnhESnGJrH7uqAtmxFXMH7IZ8wvALxda8eTZWcxneNu2Yen7U1O46cQv8YSEC+UvOc8GErrSoc48EcIH1tgAxiFNxhDrXbQFDbOVloQA5AeOsXlGn2b+BE8eMC6w1lB/jS2grpNSyYnT2ucsj+Ympugsx/95/+UvsR6WYYPks/MHXMkX/oUOipnV0s3KKhkAyPSANhgWGJOO7ohZhm88Ixn5msVDhZ6/TciJ9VNkV1eddn7+/ShX0DP48+fXpvD7884RyvsaYoH7sFEliNBGAYKHrqyA==
X-YMail-OSG: FWFDGf0VM1mkkQvmrwSCchGpAWpll1bLTsMryzhi4SWVSqnIlfXSKF1.wuUV0bW
 TJ8n_53A9K66yZib2HN0RfNClW2lw7byvmAUQdIsYvnBIPkwCfyyPKB_.dbFpHdgPx8BWwvVX39.
 .LK6j2tHLPqFw9eS1zqSO1Bi4_hHzA0TkmV_1oiCIHTBpp_UbMUWSjABB5P8FoQfH5Wkw_lj34yo
 zEIvv4PGigKb1biiepwGuT1P1ZAizIbyQfTKGDvCkR5LgTaEbiSe7ZKCqSDZr_kYc2XM3Cd.JloV
 zHxeYEfUwRzkB1eD2AfP_GcYoQqvK39oWckck.U25FCgGyFbBpwGQiSF9HbglO24RddNdhmAFmr7
 2pRnpbWivhg8zU91W.Fn4J_FWjof8HudzWQJvOudLmbFhTavS3gLNmSlW093BamZquAsUpfV7jaU
 9zYTCknupdjFXYjkQOTj_PX4EHAmOLABg12O5QmRGp5h9NnB.VjrR6OVLApsS8.KDgl4q29AczQm
 qmd5XAo3MS66.E1agnLlKww54CpMJRF5r6YN3D9XPsEmR_HLULXlgl8NCBYJJ649_yRpTGpChJPY
 Hsp7bKItWnR085MtGO9VJfm3F55N.q2N9JYIgkZIn5zfY0jyiQNun9SdGaEDiVTg222BQz4MC.PQ
 gDAtRMtqyyWw_s6aGXp6Lr3aSUNz5mTkj2MPAPGknomCMylm_a4NX9ALxEiYi9Yc1C55VQEj6on4
 kxrittBUh2fz2DNrwHWF5S3T4pFfbcRS6VvKCaxhswt.QC0K50WNJCnoP9h5Xspvb3K.o9S77825
 38Gy94eNS0WkAnQD4awWSxcGEE3NaJWFCTIIWmE2OuLnuAO_yoU4cT7b1ueJbkFvlJ.6wh.lp7T9
 DL6F0ZpRMrFX4DuEm6P9SoveK9eP8_2DKCG3sdIFOkA9moG3IV2uZntB_HILteQ4NtZ0GnCKDE5C
 b0rJiAozc.d5F6UB49XruVocybZorodDzcBBp5PKHbmcnJkLaypeUiw4DwAQlFWkqRBv_SCkcT4h
 Ar7H5M5z9daliUq3BYv7y0UswkDYZt.Z92LUjwuBE4mjFZgY2PYPPMlMAXy_rE5jM6lh9sPMvZ7U
 InHs3c2bCUmUXeMGYUnZr0HW8La5ELcJm0sUS.WYWpWWxqk9SAzOCHTWh0hG3h76bMMI2or7vS22
 qfFptYTr1yxUZdRqC8hCXqllZQNq73tRaa2DMziSeZT3LF1D8Q6Dkg4a.t0PgZX.roTczKkxqnn8
 a8SQ_2GZzouhpIiZHn_H4AGNytymM2Igm.Zyj3RmgtZGidJeti3y2lPiTANxJALGUaamiEzJ.Ync
 gpR25BNWXIDTpDLL1bCE1_I0S_6LTAbRBy0t3bfhERoYivnCRI_bUTbizpcXrSeANHKJeFf0H4Kl
 2sGcGHVcxJTTQygeyCWHmoi5fSQxJcSrka8WUc5t6o2_CKZCIg8iA_4kIOx78mmcFD8SqNsEIACc
 yfqOVUEKK58c7dBGNBkpvWWVKkGG15KSNTJ9QSR8_YIlYXTZbjGsq9BennkFgUX4guLM47kFGD6B
 HZI81uMn_8cLoaPnKme1pl86kP0vpHQzr8JpyffDaP71bveXG.7TWbpMu05JAhH46Z.AXRhK36tI
 cBFwA5j28n9mnYM.voXLbo2ZevpA_F4zbvb4MP2qeHUmeGq1heRquFPw4jMalG1Q7eDmx4EJPJSc
 44rQJugWURpSYkHM8Tn.AcjtNl_b4dNWZY5OK88s8fnqNofftg5lBjn5rROh1r6UTmnDRGcsybgg
 N21z9JTPf67JYbXP7Q9Ml9X6J340UA3oy1cbkvR0WwQSliCkLkGdi1x_EmdrfrvIa6.Cl7pmPNr0
 IRfzHsIRC1iL9yd.CeSoCUSL0LqqlXjRmhqzZF_1xTpc9QLF5ZrSaDYfzTzeyHDvBqxpPHRKdU3O
 SoM22PoEd9quKNsol8JK6EIaqm5OJDYY6uNzP45eIXz1rH79nZ5LyRwfcu3DyjGj48sH113hW6vJ
 zomQAfkK0bn03uPqadqWriDaKaVz8FSN0GeFyJvTVaeT9Q_R0CdDstYvXayZbP2yvIumX6kbzfh.
 Ea.5lc70KCqiDBArppMVc_EEoZpr96mlXbbmjjSQO4fFSb0_GTrUGZMkCVlpyQ7LToPodiZvfVwz
 rGyaqickbzWDOjxvtVSvkfDPxWP4.5G_Fy0.C0mx5wXW66cqWuxB_8VHjlPRZkJtYsqTyTzpY9Vs
 OaVORrDnYkXapqiPI99Hn8RV2oJzvTV08g64yZc9X6DzdpvEFsfwgIhBCywesxgPz4UZG6uqvz39
 _H0EY_aM5GGYf__3B
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 Apr 2022 20:52:39 +0000
Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID 1f94e35a11547554e111c2c066d33bff;
          Fri, 01 Apr 2022 20:52:37 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Booting rock64 from USB SSD
From: Mark Millard 
In-Reply-To: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl>
Date: Fri, 1 Apr 2022 13:52:34 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <83A1232D-38B7-46E1-8991-043AAC36CE42@yahoo.com>
References: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl>
To: =?utf-8?Q?=C5=81ukasz_Moska=C5=82a?= 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KVXRy5ncvz3s5d
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lfVorst7;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5078
Lines: 129

On 2022-Apr-1, at 06:51, =C5=81ukasz Moska=C5=82a  =
wrote:

> Hi everyone,
>=20
> I want to boot my rock64 from SSD (because all sd cards I could find =
are crap).
>=20
> I followed those instructions to flash u-boot to SPI: =
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi=
.md
>=20
> I was then able to boot FreeBSD from SSD (dd =
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SSD, just like it would =
be to SD card), but ethernet wasn't working. Actually, it could receive =
packets but no outgoing packets were sent. Not even ARP packets - switch =
didn't detect any device on that port, but link was UP
>=20
> I assumed it was something to do with u-boot, so I erased u-boot from =
flash, then DD FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SD card, =
and it worked without problems.
>=20
> Do I understand correctly that this means that FreeBSD on rock64 uses =
custom u-boot? Can I somehow flash it to SPI?
>=20
> Possible workaround that I can think of would be to put /boot on sd =
card, install u-boot to sd card, then put / on SSD.

My memory is that USB2 booting could be more normal, in that the
U-Boot from ports could access USB2 storage but not USB3 storage,
at least when I set this up long ago. I wanted USB3 use, thus the
below details.

I have U-Boot on the /media/ device below. As I remember, it could not
deal with the USB3 port, which is the one I wanted to use. The
FreeBSD kernel was the first stage that could deal with the USB3 port
back when I set up the Rock64 that I have access to.

I've not had to change the basic structure since I set it up. There
could be aspects that could be different these days and I'd not know.
Think of any comments as potentially being old information.

Note: mmcsd0 here is actually an eMMC device instead of the microsd
card slot contents, leaving the microsd card slot free for other uses.
But I'd used a microsd card this way before using the eMMC device
(as I remember anyway).

# gpart show -p
=3D>       63  244277185    mmcsd0  MBR  (116G)
         63      32705            - free -  (16M)
      32768     102312  mmcsd0s1  fat32lba  [active]  (50M)
     135080      28760            - free -  (14M)
     163840  241172480  mmcsd0s2  freebsd  (115G)
  241336320    2940928            - free -  (1.4G)

=3D>        0  241172480   mmcsd0s2  BSD  (115G)
          0  230686720  mmcsd0s2a  freebsd-ufs  (110G)
  230686720   10485760             - free -  (5.0G)

=3D>        40  1953525088    da0  GPT  (932G)
          40      532480  da0p1  efi  (260M)
      532520        2008         - free -  (1.0M)
      534528     7340032  da0p2  freebsd-swap  (3.5G)
     7874560     1048576         - free -  (512M)
     8923136    23068672  da0p3  freebsd-swap  (11G)
    31991808     2097152         - free -  (1.0G)
    34088960    33554432  da0p4  freebsd-swap  (16G)
    67643392  1740636160  da0p5  freebsd-ufs  (830G)
  1808279552     4194304  da0p6  freebsd-swap  (2.0G)
  1812473856   141051272         - free -  (67G)

For reference, from "gpart show -pl" :

    67643392  1740636160  da0p5  Rock64root  (830G)

(The USB drive can boot other systems as well, with
widely varying amounts of RAM. Thus the efi partition
and the odd set of freebsd-swap partitions.)

So, /media/ below is mmcsd0s1's fat32lba and /mnt/ is
mmcsd0s2a's freebsd-ufs. da0 is the USB3 SSD media,
which I do not give other details of here. (I manually
mounted these for this note.)

# ls -Tld /media/*/*/* /mnt/* /mnt/etc/*
-r-xr-xr-x   1 root  wheel  1243772 Jan 28 12:33:00 2022 =
/media/EFI/BOOT/bootaa64.efi
-r-xr-xr-x   1 root  wheel    50618 Jan 28 12:32:28 2022 =
/media/dtb/rockchip/rk3328-rock64.dtb
-r--r--r--   1 root  wheel     6170 Feb  1 04:48:34 2020 /mnt/COPYRIGHT
drwxr-xr-x  23 root  wheel     1536 Jan 28 15:26:41 2022 /mnt/boot
drwxr-xr-x   2 root  wheel      512 Apr 26 14:39:22 2020 /mnt/etc
-rw-r--r--   1 root  wheel       37 Dec 31 16:00:18 2009 /mnt/etc/hostid
drwx------   2 root  wheel    33280 Nov 27 09:46:08 2019 /mnt/lost+found

# ls -Tld /mnt/boot/dtb/overlays/rk3328-*
-r--r--r--  1 root  wheel   238 Jan 28 12:32:28 2022 =
/mnt/boot/dtb/overlays/rk3328-analog-sound.dtbo
-r--r--r--  1 root  wheel  1281 Jan 28 12:32:28 2022 =
/mnt/boot/dtb/overlays/rk3328-dwc3.dtbo

(I make no use of rk3328-analog-sound.dtbo .)

/mnt/boot/loader.conf has, in part,

# A msdosfs /MNTPNT/dtb/rockchip/rk3328-rock64.dtb
# copy of the ufs /boot/dtb/rockchip/rk3328-rock64.dtb
# uses the intended DTB in u-boot and the kernel --and
# avoids needing to tell the kernel where to find a
# copy . . .
#rk3328_rock64_load=3D"YES"
#rk3328_rock64_type=3D"dtb"
#rk3328_rock64_name=3D"/boot/dtb/rockchip/rk3328-rock64.dtb"
#
# rk3328 USB3-related:
fdt_overlays=3D"rk3328-dwc3.dtbo"
# ucom is not automatically being loaded when umodem is loaded at boot.
ucom_load=3D"YES"
umodem_load=3D"YES"
#
vfs.root.mountfrom=3D"ufs:/dev/gpt/Rock64root"
kern.cam.boot_delay=3D10000
vfs.mountroot.timeout=3D10
vfs.root_mount_always_wait=3D1

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Apr  1 22:39:29 2022
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 8A21F1A4F86E
	for ; Fri,  1 Apr 2022 22:39:35 +0000 (UTC)
	(envelope-from lm@lukaszmoskala.pl)
Received: from lukaszmoskala.pl (mail2.lukaszmoskala.pl [IPv6:2001:470:71:5c5::129:2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KVZqB3fpMz4fHc
	for ; Fri,  1 Apr 2022 22:39:34 +0000 (UTC)
	(envelope-from lm@lukaszmoskala.pl)
Received: by lukaszmoskala.pl (Postfix, from userid 5555)
	id E50D460628; Sat,  2 Apr 2022 00:39:31 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 lukaszmoskala.pl E50D460628
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukaszmoskala.pl;
	s=mail; t=1648852771;
	bh=5Xlq3mVPqQi0CpuA9G/EawRYBbiC8k2H4T4LcP45bU4=;
	h=Date:To:Cc:References:From:Subject:In-Reply-To:From;
	b=Hs+oe+RnQqlzIpH/2301t177oOLwIS0ErVX71lgb6KnQ+Tr0YyWhWH4FUBAWObWZx
	 aNnNl7IHonU6Yve9v6ZEKM71wLYlTWUGxLv93xCxpSxNAsc1u3dS9vTunsozZ7Z1z1
	 P3jpX30AKoNGnQfsubxvExAzjtbedDVltkhu10eo=
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	mail2.lukaszmoskala.pl
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.4
Received: from [IPV6:2001:470:612d:1337:f171:8c08:6007:5a65] (unknown [IPv6:2001:470:612d:1337:f171:8c08:6007:5a65])
	by lukaszmoskala.pl (Postfix) with ESMTPSA id F2C10604C8;
	Sat,  2 Apr 2022 00:39:29 +0200 (CEST)
Message-ID: <767ee719-287f-323d-ef18-4da3ef464d6c@lukaszmoskala.pl>
Date: Sat, 2 Apr 2022 00:39:29 +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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
References: <18284b32-6d1d-864a-63a9-21b5fe72deb1@lukaszmoskala.pl>
 <83A1232D-38B7-46E1-8991-043AAC36CE42@yahoo.com>
From: =?UTF-8?Q?=c5=81ukasz_Moska=c5=82a?= 
Subject: Re: Booting rock64 from USB SSD
In-Reply-To: <83A1232D-38B7-46E1-8991-043AAC36CE42@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4KVZqB3fpMz4fHc
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lukaszmoskala.pl header.s=mail header.b=Hs+oe+Rn;
	dmarc=pass (policy=none) header.from=lukaszmoskala.pl;
	spf=pass (mx1.freebsd.org: domain of lm@lukaszmoskala.pl designates 2001:470:71:5c5::129:2 as permitted sender) smtp.mailfrom=lm@lukaszmoskala.pl
X-Spamd-Result: default: False [-2.75 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lukaszmoskala.pl:s=mail];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2001:470:71:5c5::129:2];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[lukaszmoskala.pl:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lukaszmoskala.pl,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 R_MIXED_CHARSET(1.25)[subject];
	 ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9555
Lines: 221

W dniu 1.04.2022 o 22:52, Mark Millard pisze:
> On 2022-Apr-1, at 06:51, Łukasz Moskała  wrote:
> 
>> Hi everyone,
>>
>> I want to boot my rock64 from SSD (because all sd cards I could find are crap).
>>
>> I followed those instructions to flash u-boot to SPI: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md
>>
>> I was then able to boot FreeBSD from SSD (dd FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SSD, just like it would be to SD card), but ethernet wasn't working. Actually, it could receive packets but no outgoing packets were sent. Not even ARP packets - switch didn't detect any device on that port, but link was UP
>>
>> I assumed it was something to do with u-boot, so I erased u-boot from flash, then DD FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to SD card, and it worked without problems.
>>
>> Do I understand correctly that this means that FreeBSD on rock64 uses custom u-boot? Can I somehow flash it to SPI?
>>
>> Possible workaround that I can think of would be to put /boot on sd card, install u-boot to sd card, then put / on SSD.
> 
> My memory is that USB2 booting could be more normal, in that the
> U-Boot from ports could access USB2 storage but not USB3 storage,
> at least when I set this up long ago. I wanted USB3 use, thus the
> below details.
> 
> I have U-Boot on the /media/ device below. As I remember, it could not
> deal with the USB3 port, which is the one I wanted to use. The
> FreeBSD kernel was the first stage that could deal with the USB3 port
> back when I set up the Rock64 that I have access to.
> 
> I've not had to change the basic structure since I set it up. There
> could be aspects that could be different these days and I'd not know.
> Think of any comments as potentially being old information.
> 
> Note: mmcsd0 here is actually an eMMC device instead of the microsd
> card slot contents, leaving the microsd card slot free for other uses.
> But I'd used a microsd card this way before using the eMMC device
> (as I remember anyway).
> 
> # gpart show -p
> =>       63  244277185    mmcsd0  MBR  (116G)
>           63      32705            - free -  (16M)
>        32768     102312  mmcsd0s1  fat32lba  [active]  (50M)
>       135080      28760            - free -  (14M)
>       163840  241172480  mmcsd0s2  freebsd  (115G)
>    241336320    2940928            - free -  (1.4G)
> 
> =>        0  241172480   mmcsd0s2  BSD  (115G)
>            0  230686720  mmcsd0s2a  freebsd-ufs  (110G)
>    230686720   10485760             - free -  (5.0G)
> 
> =>        40  1953525088    da0  GPT  (932G)
>            40      532480  da0p1  efi  (260M)
>        532520        2008         - free -  (1.0M)
>        534528     7340032  da0p2  freebsd-swap  (3.5G)
>       7874560     1048576         - free -  (512M)
>       8923136    23068672  da0p3  freebsd-swap  (11G)
>      31991808     2097152         - free -  (1.0G)
>      34088960    33554432  da0p4  freebsd-swap  (16G)
>      67643392  1740636160  da0p5  freebsd-ufs  (830G)
>    1808279552     4194304  da0p6  freebsd-swap  (2.0G)
>    1812473856   141051272         - free -  (67G)
> 
> For reference, from "gpart show -pl" :
> 
>      67643392  1740636160  da0p5  Rock64root  (830G)
> 
> (The USB drive can boot other systems as well, with
> widely varying amounts of RAM. Thus the efi partition
> and the odd set of freebsd-swap partitions.)
> 
> So, /media/ below is mmcsd0s1's fat32lba and /mnt/ is
> mmcsd0s2a's freebsd-ufs. da0 is the USB3 SSD media,
> which I do not give other details of here. (I manually
> mounted these for this note.)
> 
> # ls -Tld /media/*/*/* /mnt/* /mnt/etc/*
> -r-xr-xr-x   1 root  wheel  1243772 Jan 28 12:33:00 2022 /media/EFI/BOOT/bootaa64.efi
> -r-xr-xr-x   1 root  wheel    50618 Jan 28 12:32:28 2022 /media/dtb/rockchip/rk3328-rock64.dtb
> -r--r--r--   1 root  wheel     6170 Feb  1 04:48:34 2020 /mnt/COPYRIGHT
> drwxr-xr-x  23 root  wheel     1536 Jan 28 15:26:41 2022 /mnt/boot
> drwxr-xr-x   2 root  wheel      512 Apr 26 14:39:22 2020 /mnt/etc
> -rw-r--r--   1 root  wheel       37 Dec 31 16:00:18 2009 /mnt/etc/hostid
> drwx------   2 root  wheel    33280 Nov 27 09:46:08 2019 /mnt/lost+found
> 
> # ls -Tld /mnt/boot/dtb/overlays/rk3328-*
> -r--r--r--  1 root  wheel   238 Jan 28 12:32:28 2022 /mnt/boot/dtb/overlays/rk3328-analog-sound.dtbo
> -r--r--r--  1 root  wheel  1281 Jan 28 12:32:28 2022 /mnt/boot/dtb/overlays/rk3328-dwc3.dtbo
> 
> (I make no use of rk3328-analog-sound.dtbo .)
> 
> /mnt/boot/loader.conf has, in part,
> 
> # A msdosfs /MNTPNT/dtb/rockchip/rk3328-rock64.dtb
> # copy of the ufs /boot/dtb/rockchip/rk3328-rock64.dtb
> # uses the intended DTB in u-boot and the kernel --and
> # avoids needing to tell the kernel where to find a
> # copy . . .
> #rk3328_rock64_load="YES"
> #rk3328_rock64_type="dtb"
> #rk3328_rock64_name="/boot/dtb/rockchip/rk3328-rock64.dtb"
> #
> # rk3328 USB3-related:
> fdt_overlays="rk3328-dwc3.dtbo"
> # ucom is not automatically being loaded when umodem is loaded at boot.
> ucom_load="YES"
> umodem_load="YES"
> #
> vfs.root.mountfrom="ufs:/dev/gpt/Rock64root"
> kern.cam.boot_delay=10000
> vfs.mountroot.timeout=10
> vfs.root_mount_always_wait=1
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 

Hi Mark,

With some idea from what you did, I managed to do this:

=================== BEGIN COMMAND LIST ============================
sudo pkg install u-boot-rock64
truncate -s 512M rock64-sd.img
truncate -s 5G rock64-disk.img
sudo mdconfig -a -t vnode -f 
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img #returned md0
sudo mdconfig -a -t vnode -f rock64-sd.img #returned md1
sudo mdconfig -a -t vnode -f rock64-disk.img #returned md2
sudo gpart create -s gpt md1
sudo gpart add -t efi -b 32768 -s 50M -i 1 md1
sudo gpart add -t freebsd-ufs -i 2 md1
sudo newfs -O 2 -L bootfs /dev/md1p2
sudo dd if=/dev/md0p1 of=/dev/md1p1 bs=1M
mkdir mp_old mp_new
sudo mount -o ro /dev/md0p2 mp_old
sudo mount -o rw /dev/md1p2 mp_new
sudo rsync -rxav mp_old/boot/ mp_new/boot/
echo 'fdt_overlays="rk3328-dwc3.dtbo"' | sudo tee -a mp_new/boot/loader.conf
echo 'vfs.root.mountfrom="ufs:/dev/ufs/rootfs"' | sudo tee -a 
mp_new/boot/loader.conf
echo 'kern.cam.boot_delay=10000' | sudo tee -a mp_new/boot/loader.conf
echo 'vfs.mountroot.timeout=10' | sudo tee -a mp_new/boot/loader.conf
echo 'vfs.root_mount_always_wait=1' | sudo tee -a mp_new/boot/loader.conf
sudo gpart create -s gpt md2
sudo gpart add -t freebsd-ufs -a 4096 -i 1 md2
sudo newfs -O 2 -t -L rootfs /dev/md2p1
mkdir mp_newroot
sudo mount -o rw /dev/md2p1 mp_newroot
sudo rsync -rxav --exclude=boot mp_old/ mp_newroot/
sudo rm mp_newroot/etc/fstab
sudo mkdir mp_newroot/media/sd
echo '/dev/ufs/rootfs / ufs rw 1 1' | sudo tee -a mp_newroot/etc/fstab
echo '/dev/ufs/bootfs /media/sd ufs rw,noatime 1 2' | sudo tee -a 
mp_newroot/etc/fstab
echo '/dev/msdosfs/EFI /media/sd/boot/efi msdosfs rw,noatime 0 0' | sudo 
tee -a mp_newroot/etc/fstab
echo 'tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0' | sudo tee -a 
mp_newroot/etc/fstab
cd mp_newroot
sudo ln -sf media/sd/boot boot
cd ..
sudo umount mp_newroot
sudo umount mp_new
sudo umount mp_old
sudo dd if=/usr/local/share/u-boot/u-boot-rock64/idbloader.img 
of=/dev/md1 seek=64 bs=512 conv=sync
sudo dd if=/usr/local/share/u-boot/u-boot-rock64/u-boot.itb of=/dev/md1 
seek=16384 bs=512 conv=sync
sudo mdconfig -d -u 2
sudo mdconfig -d -u 1
sudo mdconfig -d -u 0
=================== END COMMAND LIST ============================
(my apologies if some lines wrap improperly)

then, DD rock64-sd.img to sdcard and rock64-disk.img to disk.
It would be possible to do that directly on disk and sdcard itself, but 
in my case, machine on which I ran these commands doesn't have sd card 
reader.

Anyway, it successfully booted with SSD plugged into USB3 port, despite 
those messages:
Root mount waiting for: usbus0 usbus2 usbus3 usbus4 CAM
usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
after which da0 was detected and boot continued. Network is working, and 
everything seems okay (uptime is 6 minutes as of moment I'm writing 
this). I'm using official pine64 usb-sata adapter, but I suppose it 
doesn't really matter. I don't have any other adapters to check. I 
copied 2.5GiB file to it and it seems stable.

I got a lot of "devmatch: Can't read linker hints file."
That was fixed by kldxref -R /media/sd/boot

root@generic:~ # df -h
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/ufs/rootfs     108G    4.2G     95G     4%    /
devfs               1.0K    1.0K      0B   100%    /dev
/dev/ufs/bootfs     432M     82M    316M    21%    /media/sd
/dev/msdosfs/EFI     50M    2.7M     47M     5%    /media/sd/boot/efi
tmpfs                50M    4.0K     50M     0%    /tmp
root@generic:~ # mount
/dev/ufs/rootfs on / (ufs, local)
devfs on /dev (devfs)
/dev/ufs/bootfs on /media/sd (ufs, local, noatime)
/dev/msdosfs/EFI on /media/sd/boot/efi (msdosfs, local, noatime)
tmpfs on /tmp (tmpfs, local)
root@generic:~ # gpart show -p
=>     40  1048496    mmcsd0  GPT  (7.4G) [CORRUPT]
        40    32728            - free -  (16M)
     32768   102400  mmcsd0p1  efi  (50M)
    135168   913368  mmcsd0p2  freebsd-ufs  (446M)

=>       40  234441568    da0  GPT  (112G)
          40       4056         - free -  (2.0M)
        4096  234437512  da0p1  freebsd-ufs  (112G)

Thanks for your help, and I hope that whatever I made here will be 
usefull to someone.

-- 
Łukasz Moskała

From nobody Fri Apr  1 22:56:39 2022
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 82D881A54DBF
	for ; Fri,  1 Apr 2022 22:57:07 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4KVbCK1Blhz4llD
	for ; Fri,  1 Apr 2022 22:56:58 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id p15so8773367ejc.7
        for ; Fri, 01 Apr 2022 15:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=z/WzfxXWjzFX8C97lZBNMmn4n654ebROy/9KYvo/nUs=;
        b=OQ3uBTM4pCGY6c6WB0227oA3sTOu4Ep4+QciKpCCC9gXXeGlP/KovXnBoSisnD0bUE
         C6nyNVbgoCKXT2VMGCNvmTnzh1lsrBH6xkiqeSD/hbTsmnTjcW8rzqL54bh38duN7+kJ
         ej6YQodBb9rJVAVRvSJAA6nV9wPqw8VyR1GbenUpoF2HFoeEupi2ZFSiqeMblRF+nJYE
         GRBTioaLk2XzT3z3/wrQbtp6qS8L2XhFljQaWWIHHFl42t2paoFntn9P6wn7c8p+6W3j
         u3+ipd6H6XwBQWAF+Z4gizZzjI2LYYyQhUMPoRnqq0fsrAwGHyzpO/gI3cEeQPSicANq
         CoOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=z/WzfxXWjzFX8C97lZBNMmn4n654ebROy/9KYvo/nUs=;
        b=56iAjSxofQBjwvJdgcXokpMtqZ7QaSu3vF4Tx1In1IGIIB1LGCQiYYSZM2y/cnUdxu
         VHm5lRRLcHaM8xvEcnFPlToTUrR4jfqzBElN8nSHhNOlLTQOTCDBFVAIDaeZN5vwzQUr
         lRgbOBCYiffbMh/auBXnl7QUxkGD0DlBxM30XRZwbCz41HOBiSJ2azOQrGdGt4l5pWcl
         pr+HiJdyT/gmWahqycmBg2d1lqgAPh8mpz0cTp4vUtzomRM5yTt8ACxtk+GTnRHxLptd
         5C1GlWYwCa8HE8cJcDFGTFNdqI9NVTDrS34c5yZBiWNME2mRMQWtZ7JuPLStFGw3a2h2
         9usA==
X-Gm-Message-State: AOAM530+niyooqjmH8r5hfYUGSso0SnW7mHz3p2Si5uHVSWTm8KxQGL/
	iHTTXhf9m3d7YPs6bHvh2eJTtK5fxqA3Ev2SQzg2ksEnL7EL/w==
X-Google-Smtp-Source: ABdhPJwvsMeI6unOLbgoR9uZNb4FyBOvshKyATKu09aOyk+DOIya2wbLhdFBHypxyqtWDinhwLm4fJ9ErayJAtyZoUc=
X-Received: by 2002:a17:907:a41f:b0:6d6:f925:1696 with SMTP id
 sg31-20020a170907a41f00b006d6f9251696mr1789128ejc.62.1648853810773; Fri, 01
 Apr 2022 15:56:50 -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: 
 <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
 
  
 <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org>
In-Reply-To: <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org>
From: Archimedes Gaviola 
Date: Sat, 2 Apr 2022 06:56:39 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000ad820305db9fb1a0"
X-Rspamd-Queue-Id: 4KVbCK1Blhz4llD
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=OQ3uBTM4;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.73 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.27)[0.273];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10069
Lines: 190

--000000000000ad820305db9fb1a0
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky  wrote:

> On 3/31/22 15:52, Archimedes Gaviola wrote:
> > Are you pertaining to this code Hans, the one you've shared to me
> > previously?
> >
> > +       /* Epson printer */
> > +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
>
> Yes, but you can also add the IFACE_XXX ones with "," simply.
>

Hi Hans,

Here's what I have come-up with based on my understanding from your
suggestion. I took a look as well from other USB devices' sources. This
compiles without any problems, still able to detect my printers and
printing still works well. Let me know if this is correct or needs further
changes.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
/usr/src/sys/dev/usb/serial/ulpt.c
--- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
19:44:29.178010000 +0800
+++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-04-02 14:27:54.073592000 +0800
@@ -499,6 +499,13 @@
        {USB_IFACE_CLASS(UICLASS_PRINTER),
         USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
         USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
+
+       /* Epson printer */
+       {USB_VENDOR(USB_VENDOR_EPSON),
+        USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
+        USB_IFACE_CLASS(UICLASS_VENDOR),
+        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
+        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
 };

 static int
@@ -555,9 +562,11 @@
                                break;
                        } else {
                                alt_index++;
-                               if ((id->bInterfaceClass ==
UICLASS_PRINTER) &&
-                                   (id->bInterfaceSubClass ==
UISUBCLASS_PRINTER) &&
-                                   (id->bInterfaceProtocol ==
UIPROTO_PRINTER_BI)) {
+                               if ((id->bInterfaceClass == UICLASS_PRINTER
||
+                                   id->bInterfaceClass == UICLASS_VENDOR)
&&
+                                   (id->bInterfaceSubClass ==
UISUBCLASS_PRINTER ||
+                                   id->bInterfaceClass ==
UISUBCLASS_VENDOR) &&
+                                   (id->bInterfaceProtocol ==
UIPROTO_PRINTER_BI)) {
                                        goto found;
                                }
                        }

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
/usr/src/sys/dev/usb/usbdevs
--- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000 +0800
+++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000 +0800
@@ -1941,6 +1941,7 @@
 product EPSON 2480             0x0121  Perfection 2480 scanner
 product EPSON 3590             0x0122  Perfection 3590 scanner
 product EPSON 4990             0x012a  Perfection 4990 Photo scanner
+product EPSON TMU220B          0x0202  TM-U220B
 product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
 product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
 product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader

freebsd@generic:~ % dmesg
...
ugen1.5:  at usbus1
ugen1.6:  at usbus1
ulpt0 on uhub1
ulpt0:  on usbus1
ulpt0: using bi-directional mode
ulpt1 on uhub1
ulpt1: 
on usbus1
ulpt1: using bi-directional mode
ulpt1: offline

Thanks,
Archimedes

--000000000000ad820305db9fb1a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Apr 1, 2022 at 12:01 AM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 3/3=
1/22 15:52, Archimedes Gaviola wrote:

> Are you pertaining to this code Hans, the one you've shared to me<=
br>
> previously?

> 

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPS=
ON_TMU220B, 0)},



Yes, but you can also add the IFACE_XXX ones with "," simply.
=


Hi Hans,

Here's what I have come-up wi=
th based on my understanding from your suggestion. I took a look as well fr=
om other USB devices' sources. This compiles without any problems, stil=
l able to detect my printers and printing still works well. Let me know if =
this is correct or needs further changes.

freebsd@generic:~ % diff -Nur /usr/=
src/sys/dev/usb/serial/ulpt.c.orig /usr/src/sys/dev/usb/serial/ulpt.c
--=
- /usr/src/sys/dev/usb/serial/ulpt.c.orig =C2=A0 =C2=A0 2022-03-21 19:44:29=
.178010000 +0800
+++ /usr/src/sys/dev/usb/serial/ulpt.c =C2=A02022-04-02=
 14:27:54.073592000 +0800
@@ -499,6 +499,13 @@
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 {USB_IFACE_CLASS(UICLASS_PRINTER),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
+
+ =C2=A0 =C2=
=A0 =C2=A0 /* Epson printer */
+ =C2=A0 =C2=A0 =C2=A0 {USB_VENDOR(USB_VE=
NDOR_EPSON),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_PRODUCT(USB_PRODUCT_EPSON_=
TMU220B),
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_CLASS(UICLASS_VENDOR),<=
br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
+=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
=C2=
=A0};

=C2=A0static int
@@ -555,9 +562,11 @@
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 alt_index++;
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id-=
>bInterfaceClass =3D=3D UICLASS_PRINTER) &&
- =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInterfaceSubClass =3D=3D UISUBCLAS=
S_PRINTER) &&
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id-=
>bInterfaceProtocol =3D=3D UIPROTO_PRINTER_BI)) {
+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 if ((id->bInterfaceClass =3D=3D UICLASS_PRINTER ||
+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id->bInterfaceClass =3D=3D=
 UICLASS_VENDOR) &&
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 (id->bInterfaceSubClass =3D=3D UISUBCLASS_PRINTER ||
+ =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id->bInterfaceClass =3D=3D UISUBCLASS=
_VENDOR) &&
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id-&=
gt;bInterfaceProtocol =3D=3D UIPROTO_PRINTER_BI)) {
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto found;
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

freebsd@generic:~ % diff -Nur /usr/s=
rc/sys/dev/usb/usbdevs.orig /usr/src/sys/dev/usb/usbdevs
--- /usr/src/sy=
s/dev/usb/usbdevs.orig =C2=A0 2022-03-21 19:42:20.999397000 +0800
+++ /u=
sr/src/sys/dev/usb/usbdevs =C2=A0 =C2=A0 =C2=A0 =C2=A02022-04-01 01:21:31.3=
61567000 +0800
@@ -1941,6 +1941,7 @@
=C2=A0product EPSON 2480 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0121 =C2=A0Perfection 2480 scanner
=
=C2=A0product EPSON 3590 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0122 =
=C2=A0Perfection 3590 scanner
=C2=A0product EPSON 4990 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 0x012a =C2=A0Perfection 4990 Photo scanner
+pro=
duct EPSON TMU220B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0202 =C2=A0TM-U220B<=
br>=C2=A0product EPSON CRESSI_EDY =C2=A0 =C2=A0 =C2=A0 0x0521 =C2=A0Cressi =
Edy diving computer
=C2=A0product EPSON N2ITION3 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 0x0522 =C2=A0Zeagle N2iTion3 diving computer
=C2=A0product EPSON =
STYLUS_875DC =C2=A0 =C2=A0 0x0601 =C2=A0Stylus Photo 875DC Card Reader

freebsd@ge=
neric:~ % dmesg
...
ugen1.5: <EPSON EPSON UB-U03II> at usbus1
ugen1.6: &l=
t;Printer-58 USB Printing Support> at usbus1
ulpt0 on uhub1
ulpt0:=
 <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> on usbus1ulpt0: using bi-directional mode
ulpt1 on uhub1
ulpt1: <Printer-=
58 USB Printing Support, class 0/0, rev 2.00/2.54, addr 6> on usbus1
=
ulpt1: using bi-directional mode
ulpt1: offline

Thanks,
Archimedes



--000000000000ad820305db9fb1a0--

From nobody Sat Apr  2 00:30:25 2022
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 A1D3D1A46EED
	for ; Sat,  2 Apr 2022 00:30:29 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KVdH84v77z3F4x
	for ; Sat,  2 Apr 2022 00:30:28 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.17.145.105])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 013662600D1;
	Sat,  2 Apr 2022 02:30:26 +0200 (CEST)
Message-ID: <0b3e82fe-b45f-67f0-3009-90e887c14159@selasky.org>
Date: Sat, 2 Apr 2022 02:30:25 +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:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: Raspberry Pi 3B USB Printing Issue
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org>
 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org>
 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org>
 
 
 
 
 
 
 
 
 <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KVdH84v77z3F4x
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3774
Lines: 98

On 4/2/22 00:56, Archimedes Gaviola wrote:
> On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky  wrote:
> 
>> On 3/31/22 15:52, Archimedes Gaviola wrote:
>>> Are you pertaining to this code Hans, the one you've shared to me
>>> previously?
>>>
>>> +       /* Epson printer */
>>> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
>>
>> Yes, but you can also add the IFACE_XXX ones with "," simply.
>>
> 
> Hi Hans,
> 
> Here's what I have come-up with based on my understanding from your
> suggestion. I took a look as well from other USB devices' sources. This
> compiles without any problems, still able to detect my printers and
> printing still works well. Let me know if this is correct or needs further
> changes.
> 
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
> /usr/src/sys/dev/usb/serial/ulpt.c
> --- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
> 19:44:29.178010000 +0800
> +++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-04-02 14:27:54.073592000 +0800
> @@ -499,6 +499,13 @@
>          {USB_IFACE_CLASS(UICLASS_PRINTER),
>           USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
>           USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> +
> +       /* Epson printer */
> +       {USB_VENDOR(USB_VENDOR_EPSON),
> +        USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
> +        USB_IFACE_CLASS(UICLASS_VENDOR),
> +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
>   };
> 
>   static int
> @@ -555,9 +562,11 @@
>                                  break;
>                          } else {
>                                  alt_index++;
> -                               if ((id->bInterfaceClass ==
> UICLASS_PRINTER) &&
> -                                   (id->bInterfaceSubClass ==
> UISUBCLASS_PRINTER) &&
> -                                   (id->bInterfaceProtocol ==
> UIPROTO_PRINTER_BI)) {
> +                               if ((id->bInterfaceClass == UICLASS_PRINTER
> ||
> +                                   id->bInterfaceClass == UICLASS_VENDOR)
> &&
> +                                   (id->bInterfaceSubClass ==
> UISUBCLASS_PRINTER ||
> +                                   id->bInterfaceClass ==
> UISUBCLASS_VENDOR) &&
> +                                   (id->bInterfaceProtocol ==
> UIPROTO_PRINTER_BI)) {
>                                          goto found;
>                                  }
>                          }
> 
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
> /usr/src/sys/dev/usb/usbdevs
> --- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000 +0800
> +++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000 +0800
> @@ -1941,6 +1941,7 @@
>   product EPSON 2480             0x0121  Perfection 2480 scanner
>   product EPSON 3590             0x0122  Perfection 3590 scanner
>   product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> +product EPSON TMU220B          0x0202  TM-U220B
>   product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
>   product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
>   product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
> 
> freebsd@generic:~ % dmesg
> ...
> ugen1.5:  at usbus1
> ugen1.6:  at usbus1
> ulpt0 on uhub1
> ulpt0:  on usbus1
> ulpt0: using bi-directional mode
> ulpt1 on uhub1
> ulpt1: 
> on usbus1
> ulpt1: using bi-directional mode
> ulpt1: offline
> 

Here you go:
https://cgit.freebsd.org/src/commit/?id=88162f7abd61206c98432f2c0de869a59be13854

Happy printing :-)

--HPS


From nobody Sat Apr  2 01:10:25 2022
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 689411A4FBAE
	for ; Sat,  2 Apr 2022 01:10:39 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4KVf9V04frz3Jxt
	for ; Sat,  2 Apr 2022 01:10:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id i27so2078785ejd.9
        for ; Fri, 01 Apr 2022 18:10:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=zM9ddGUaKS92LH3+ZVaq9WoPsOHunHQddU4kq8kMWSw=;
        b=XIj+hfXwXyk7wG0FHiKp33eJqI8581ccWc5sLX3uZxh7JOF7Ehkh/KuE5HlkrJzA28
         9Sd7PH3ASEzfEXDYm8o2/WUN+y88bcwD9THILd2yYy6oVqK558PFtGEVpCeFndxtwvx3
         XlhJzZ48o3xxu8QwOHaD+iFhGodQ5DsYnodhxTxNyyMvQXEXONRXgNcr/i6k4hVZOPW3
         4jLjAekc4pVZhp04YXMJMiCZT7TInm6ye+2NGGWWn8q2QrIHPp86MPRgnXzIH7g3sXP0
         co1DyM+DbNfGtYDGpYxDsfu1lsBRLqSkT5Ggwkhg+MZiNJkCApGaeVB9R9Fz4NFkTxYn
         7zCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=zM9ddGUaKS92LH3+ZVaq9WoPsOHunHQddU4kq8kMWSw=;
        b=l4lLF6ynucNVA4XZAts3OiyxrB/ZC5/7qy8gibVl6gyzVQG6kUmF6+Qt6jwtGHaxIP
         r3Pr/HR7DvjLTZ3BNtdbwJYzmmjyssZJjJkEbhX0pCfBjApYYLYdpssgbE8A2O9ocejJ
         y4o1Z6FGGnLI9Tv/wA2G/ZbxYt/7E5SHgH6WVstto49khy6+Mmxw7hNgioPppEVNgtsU
         /gbqAsr8qAx3kNd6MrgYWn9iTf3dv0nxCSgDn5KKBNxgCAM00661nEc1qYeZ/EbN0JCb
         PCRTDVgNl6Vxh+96YoGqa4cejmfkxIEiyEasYnQlw781oPO2ZSw042NbN7QyehIZffnO
         CgCQ==
X-Gm-Message-State: AOAM530p42UC2KSI8OdlhZlVwxxF1/xwE/pRxi+UEInjeZRWB2Q2A5bf
	nsVmsVwvq30w5TvL8GM28VZ8JI7JEww37JQ4Z4qmTDInG1E=
X-Google-Smtp-Source: ABdhPJxhJcNa/DepxX3Eu61ICPa4OuzOM97IfQuvjNHTHuSAscemaISLcDrYpQzL0g5IiaB7X1m9xvgnO8fEfXKR5FE=
X-Received: by 2002:a17:906:7304:b0:6e0:6918:ef6f with SMTP id
 di4-20020a170906730400b006e06918ef6fmr2040301ejc.370.1648861836888; Fri, 01
 Apr 2022 18:10:36 -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: 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
 
  
 <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org> 
 <0b3e82fe-b45f-67f0-3009-90e887c14159@selasky.org>
In-Reply-To: <0b3e82fe-b45f-67f0-3009-90e887c14159@selasky.org>
From: Archimedes Gaviola 
Date: Sat, 2 Apr 2022 09:10:25 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000124f6d05dba19021"
X-Rspamd-Queue-Id: 4KVf9V04frz3Jxt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=XIj+hfXw;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11489
Lines: 273

--000000000000124f6d05dba19021
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 2, 2022 at 8:30 AM Hans Petter Selasky  wrote:

> On 4/2/22 00:56, Archimedes Gaviola wrote:
> > On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky 
> wrote:
> >
> >> On 3/31/22 15:52, Archimedes Gaviola wrote:
> >>> Are you pertaining to this code Hans, the one you've shared to me
> >>> previously?
> >>>
> >>> +       /* Epson printer */
> >>> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
> >>
> >> Yes, but you can also add the IFACE_XXX ones with "," simply.
> >>
> >
> > Hi Hans,
> >
> > Here's what I have come-up with based on my understanding from your
> > suggestion. I took a look as well from other USB devices' sources. This
> > compiles without any problems, still able to detect my printers and
> > printing still works well. Let me know if this is correct or needs
> further
> > changes.
> >
> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
> > /usr/src/sys/dev/usb/serial/ulpt.c
> > --- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
> > 19:44:29.178010000 +0800
> > +++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-04-02 14:27:54.073592000
> +0800
> > @@ -499,6 +499,13 @@
> >          {USB_IFACE_CLASS(UICLASS_PRINTER),
> >           USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
> >           USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
> > +
> > +       /* Epson printer */
> > +       {USB_VENDOR(USB_VENDOR_EPSON),
> > +        USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
> > +        USB_IFACE_CLASS(UICLASS_VENDOR),
> > +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> > +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
> >   };
> >
> >   static int
> > @@ -555,9 +562,11 @@
> >                                  break;
> >                          } else {
> >                                  alt_index++;
> > -                               if ((id->bInterfaceClass ==
> > UICLASS_PRINTER) &&
> > -                                   (id->bInterfaceSubClass ==
> > UISUBCLASS_PRINTER) &&
> > -                                   (id->bInterfaceProtocol ==
> > UIPROTO_PRINTER_BI)) {
> > +                               if ((id->bInterfaceClass ==
> UICLASS_PRINTER
> > ||
> > +                                   id->bInterfaceClass ==
> UICLASS_VENDOR)
> > &&
> > +                                   (id->bInterfaceSubClass ==
> > UISUBCLASS_PRINTER ||
> > +                                   id->bInterfaceClass ==
> > UISUBCLASS_VENDOR) &&
> > +                                   (id->bInterfaceProtocol ==
> > UIPROTO_PRINTER_BI)) {
> >                                          goto found;
> >                                  }
> >                          }
> >
> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
> > /usr/src/sys/dev/usb/usbdevs
> > --- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000
> +0800
> > +++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000
> +0800
> > @@ -1941,6 +1941,7 @@
> >   product EPSON 2480             0x0121  Perfection 2480 scanner
> >   product EPSON 3590             0x0122  Perfection 3590 scanner
> >   product EPSON 4990             0x012a  Perfection 4990 Photo scanner
> > +product EPSON TMU220B          0x0202  TM-U220B
> >   product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
> >   product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
> >   product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
> >
> > freebsd@generic:~ % dmesg
> > ...
> > ugen1.5:  at usbus1
> > ugen1.6:  at usbus1
> > ulpt0 on uhub1
> > ulpt0:  on usbus1
> > ulpt0: using bi-directional mode
> > ulpt1 on uhub1
> > ulpt1:  6>
> > on usbus1
> > ulpt1: using bi-directional mode
> > ulpt1: offline
> >
>
> Here you go:
>
> https://cgit.freebsd.org/src/commit/?id=88162f7abd61206c98432f2c0de869a59be13854
>
> Happy printing :-)
>

Hans, thank you so much for the help and guidance! :-)

--000000000000124f6d05dba19021
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Apr 2, 2022 at 8:30 AM Hans P=
etter Selasky <hps@selasky.org>=
; wrote:
On 4/2/=
22 00:56, Archimedes Gaviola wrote:

> On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/31/22 15:52, Archimedes Gaviola wrote:

>>> Are you pertaining to this code Hans, the one you've share=
d to me

>>> previously?

>>>

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRO=
DUCT_EPSON_TMU220B, 0)},

>>

>> Yes, but you can also add the IFACE_XXX ones with "," si=
mply.

>>

> 

> Hi Hans,

> 

> Here's what I have come-up with based on my understanding from you=
r

> suggestion. I took a look as well from other USB devices' sources.=
 This

> compiles without any problems, still able to detect my printers and
> printing still works well. Let me know if this is correct or needs fur=
ther

> changes.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig<=
br>
> /usr/src/sys/dev/usb/serial/ulpt.c

> --- /usr/src/sys/dev/usb/serial/ulpt.c.orig=C2=A0 =C2=A0 =C2=A02022-03=
-21

> 19:44:29.178010000 +0800

> +++ /usr/src/sys/dev/usb/serial/ulpt.c=C2=A0 2022-04-02 14:27:54.07359=
2000 +0800

> @@ -499,6 +499,13 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {USB_IFACE_CLASS(UICLASS_PRINTER),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_=
PRINTER),

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRI=
NTER_1284)},

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VENDOR(USB_VENDOR_EPSON),

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_CLASS(UICLASS_VENDOR),

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},<=
br>
>=C2=A0 =C2=A0};

> 

>=C2=A0 =C2=A0static int

> @@ -555,9 +562,11 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 } else {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((id->bInterfaceClass =3D=
=3D

> UICLASS_PRINTER) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceS=
ubClass =3D=3D

> UISUBCLASS_PRINTER) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceP=
rotocol =3D=3D

> UIPROTO_PRINTER_BI)) {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((id->bInterfaceClass =3D=
=3D UICLASS_PRINTER

> ||

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->bInterfaceCl=
ass =3D=3D UICLASS_VENDOR)

> &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceS=
ubClass =3D=3D

> UISUBCLASS_PRINTER ||

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->bInterfaceCl=
ass =3D=3D

> UISUBCLASS_VENDOR) &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceP=
rotocol =3D=3D

> UIPROTO_PRINTER_BI)) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 goto found;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig

> /usr/src/sys/dev/usb/usbdevs

> --- /usr/src/sys/dev/usb/usbdevs.orig=C2=A0 =C2=A02022-03-21 19:42:20.=
999397000 +0800

> +++ /usr/src/sys/dev/usb/usbdevs=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-04-01=
 01:21:31.361567000 +0800

> @@ -1941,6 +1941,7 @@

>=C2=A0 =C2=A0product EPSON 2480=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x0121=C2=A0 Perfection 2480 scanner

>=C2=A0 =C2=A0product EPSON 3590=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x0122=C2=A0 Perfection 3590 scanner

>=C2=A0 =C2=A0product EPSON 4990=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x012a=C2=A0 Perfection 4990 Photo scanner

> +product EPSON TMU220B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0202=C2=A0 =
TM-U220B

>=C2=A0 =C2=A0product EPSON CRESSI_EDY=C2=A0 =C2=A0 =C2=A0 =C2=A00x0521=
=C2=A0 Cressi Edy diving computer

>=C2=A0 =C2=A0product EPSON N2ITION3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x=
0522=C2=A0 Zeagle N2iTion3 diving computer

>=C2=A0 =C2=A0product EPSON STYLUS_875DC=C2=A0 =C2=A0 =C2=A00x0601=C2=A0=
 Stylus Photo 875DC Card Reader

> 

> freebsd@generic:~ % dmesg

> ...

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ugen1.6: <Printer-58 USB Printing Support> at usbus1

> ulpt0 on uhub1

> ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> ulpt0: using bi-directional mode

> ulpt1 on uhub1

> ulpt1: <Printer-58 USB Printing Support, class 0/0, rev 2.00/2.54, =
addr 6>

> on usbus1

> ulpt1: using bi-directional mode

> ulpt1: offline

> 



Here you go:

https://cgit.freeb=
sd.org/src/commit/?id=3D88162f7abd61206c98432f2c0de869a59be13854



Happy printing :-)

Hans, thank you so much f=
or the help and guidance! :-)


--000000000000124f6d05dba19021--

From nobody Sun Apr  3 12:39:18 2022
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 CD0441A63886
	for ; Sun,  3 Apr 2022 12:39:32 +0000 (UTC)
	(envelope-from mishin@mh.net.ru)
Received: from frog.mh.net.ru (mh.balakovo.san.ru [88.147.158.22])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KWYPt0ztQz3N36
	for ; Sun,  3 Apr 2022 12:39:28 +0000 (UTC)
	(envelope-from mishin@mh.net.ru)
Received: from webmail.mh.net.ru (mouse.home [192.168.5.6])
	by frog.mh.net.ru (Postfix) with ESMTPSA id 0D75637C15
	for ; Sun,  3 Apr 2022 16:39:19 +0400 (+04)
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
Date: Sun, 03 Apr 2022 16:39:18 +0400
From: Alexander Mishin 
To: freebsd-arm@freebsd.org
Subject: Extra uarts to Rpi4b 8Gb do not work
Message-ID: <5b5832ae7bd3f3b642815d179a56ab3a@mh.net.ru>
X-Sender: mishin@mh.net.ru
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KWYPt0ztQz3N36
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=mh.net.ru;
	spf=pass (mx1.freebsd.org: domain of mishin@mh.net.ru designates 88.147.158.22 as permitted sender) smtp.mailfrom=mishin@mh.net.ru
X-Spamd-Result: default: False [-3.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[mh.net.ru,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12389, ipnet:88.147.128.0/17, country:RU];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1975
Lines: 69

Hi,

I tried adding extra serial ports on my Raspberry pi 4b 8Gb rev 1.4 for 
a gpio GPS module - the GPS module connected to uart0 (as well as uart1) 
is preventing the Raspberry from booting up. I even see dev/ttyu* files 
for added uarts after reboot, but uarts don't work for me.

My os-version:
FreeBSD 13.1-STABLE #3 stable/13-n250037-7d59a9451d3b: Sun Mar 20 
00:51:26 +04 2022 arm64

I copied uart4.dtbo and uart5.dtbo from rpi-firmware package to 
/boot/dtb/overlays directory (and to /boot/msdos/overlays. Don't know 
for sure which folder is being used) and added to /boot/msdos/config.txt 
to [All] section:
---
dtoverlay=uart4
gpio=8,9=a4
dtoverlay=uart5
gpio=12,13=a4
---

I then rebooted my system, checked that the /dev/ttyu(0,1,2) files are 
exist (uart0 is worked correctly) and checked pins configuration:
---
# gpioctl -l | egrep "pin (08|09|12|13|14|15)"
pin 08:	1	pin 8<>
pin 09:	1	pin 9<>
pin 12:	1	pin 12<>
pin 13:	1	pin 13<>
pin 14:	1	pin 14<>
pin 15:	1	pin 15<>
---

Then I connecteded the loops to the following pairs of pins: 8,10 (gpio 
14,15), 21,24 (gpio 9,8) and 32,33 (gpio 12,13) and ran a script I found 
somewhere on the Internet when I was looking for a solution to my issue:
---
import serial
import time
test_string = "[serial port test]".encode('utf-8')
port_list = ["/dev/ttyu0", "/dev/ttyu1", "/dev/ttyu2" ]
for port in port_list:
   ok = False
   try:
     buff = bytearray(len(test_string))
     serialPort = serial.Serial(port, 115200, timeout = 2, writeTimeout = 
2)
     bytes_sent = serialPort.write(test_string)
     time.sleep(1)
     bytes_read = serialPort.readinto(buff)
     ok = bytes_read == bytes_sent
     serialPort.close()
   except IOError:
     pass
   print("port %s is %s" % (port, "OK" if ok else "NOT OK"))
---

I get the result:
---
port /dev/ttyu0 is OK
port /dev/ttyu1 is NOT OK
port /dev/ttyu2 is NOT OK
---

Did I make a mistake in my actions? Is it possible to add extra uarts to 
rpi4b at all?

Thanks

From nobody Sun Apr  3 15:03:36 2022
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 E0ACA1A5AEC8
	for ; Sun,  3 Apr 2022 15:03:36 +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 4KWcc82KkVz3wSQ
	for ; Sun,  3 Apr 2022 15:03:36 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 190451F941
	for ; Sun,  3 Apr 2022 15:03:36 +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 233F3a1g006920
	for ; Sun, 3 Apr 2022 15:03:36 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 233F3aE1006919
	for freebsd-arm@FreeBSD.org; Sun, 3 Apr 2022 15:03:36 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 216062] linker command failed in function `numa_setaffinity'
Date: Sun, 03 Apr 2022 15:03:36 +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 Many People
X-Bugzilla-Who: emaste@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: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1648998216;
	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=qm6n1nNGXNN03XT1Rv8i5cRoPA7SQm7OoPmfvsPBATw=;
	b=g68nrYimolX5NBRF6z97ySE+zJ911g8YLarb6QGEjgdjwb/biTnVG7ZuJTHEVlyds0670T
	u0e1B5JDkrJ8hstJj/tLNzu4Ly4ouuyVdGlT5pWaBtvyYtDXT36oD0JGXVtZqVmU/e3PoH
	ES+r2jEiW1qOvMumOkJTviWcqDlvk5cl1mmi9kQi9dRTXRTWZ46vLgcdoDuHGFgzG3dIKk
	pzrVvBZ9S5k3Lmly60molcSAHaO4MHGPsAhjj7ZoAPoNKpv18bYdOJprOb8XischIg6+6H
	5696In4o5MngXfY+juk8Q9hC+gKC6ysEY9iTQ9J3bzv29Yx5uvE/9Cpr5ngFoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648998216; a=rsa-sha256; cv=none;
	b=c4i4MZc37xYnkfWrEV3/7X3GAe4CeW1e78djRJIJ80LEZaFSirLVlaJuezgGXbZnmGERat
	XvCnn5jpGJ/h0FX0AAYkBzm1exafhXyDQ4b++zN5Xxv2v0VrZ5V9K+j/m/ADLCc2V33PfU
	KLFU8ygM54yaRN4viSZc7xWO4TTE9E+Qo6y3446MhhkmFHViMynKQ3tqCoZVswyDZXyUn3
	8UqY5ZN37L/NNykxflZ3up5DqbBir1kOBDUTiC0dxrc0w2/ERHsyWbWL6SCkD/8vkfNI3W
	fCAXZRwdxt/EhQJPoLlBycTnLp3iR4xjyFLUQeHqAu4+oocepnct/UXY5m7Wbw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 507
Lines: 15

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216062

Ed Maste  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
         Resolution|---                         |FIXED

--- Comment #3 from Ed Maste  ---
Presumed fixed per comment #1

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Apr  3 21:00:41 2022
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 709601A60FE4
	for ; Sun,  3 Apr 2022 21:00:42 +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 4KWmX92W3Nz3k8M
	for ; Sun,  3 Apr 2022 21:00:41 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 176EF248C6
	for ; Sun,  3 Apr 2022 21:00:41 +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 233L0f5I092593
	for ; Sun, 3 Apr 2022 21:00:41 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 233L0fuT092592
	for freebsd-arm@FreeBSD.org; Sun, 3 Apr 2022 21:00:41 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202204032100.233L0fuT092592@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, 3 Apr 2022 21:00:41 +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="16490196410.aA38C85.90949"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649019641;
	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=403MV5SQqoCniGbnCfRByWBZumPLHiacE1gY7nTrufs=;
	b=hTpzcRwqF02OuV+lU+gM3gD2nOuvitV/A0VKHd25OuO6vzyiT1ITcuv87XaLx06m20om8g
	PKd4DuLJU9FMVMbS3DEAdqaLVCXf/cOa5yb8g/wQd9kU91/VpANqsV4GS1Hv+n3ew7RI0y
	ABvesE9v/ys8TpsofwnbQvs0x6BKpieRmNRl76HWQ/DZTccbvLfpCth7cO+yk10CGCSr8N
	kL0qTV50utjkCrh8mGFvMtw5Lp620xwJ59lHcdRmasw5pzhVNXGS5p2Wzz+FssXsJNJoAM
	SxFwWuwoOeEGz1ggV8AIUd/ZjwIvSN1BYaKbn5AnnBBSOvQfaadD/iJpcubLoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649019641; a=rsa-sha256; cv=none;
	b=l3dOYd1FzA6PBddYmcCtbFBO2XNaQHMeNn6NOSvWZkBtHwsIQ+MKwVWfdslJGd6uJA89m+
	orLAICsJt7MJ7B+u8hX4tF4GlxMNp4KfGRuDUb8RnAV1mFHdr4FFTAbKPEkxgCmRqbF8Ix
	cZEe3KEYI94HMYg9cg1OX6SeKbndgFF5KcEaLOHLc2uF0Qqbg5ku3TLy1Si91S5FoTOKsb
	WWxYqAaIo8Mfbx/1CIZSkphbc2dLzAa+xhHHlqZiuaqkHzGDsKUFsuvp5RXbN9nOY65wns
	s7uM/to7s3H9eOpYqCaA5grwdPvcZWefoFKO7XumYvKMzPZzFzO2Ces7KYdmbQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1802
Lines: 38


--16490196410.aA38C85.90949
Date: Sun, 3 Apr 2022 21:00:41 +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.

--16490196410.aA38C85.90949
Date: Sun, 3 Apr 2022 21:00:41 +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.


--16490196410.aA38C85.90949--

From nobody Mon Apr  4 06:44:29 2022
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 5289F1A51F01
	for ; Mon,  4 Apr 2022 06:44:45 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KX1V36RnMz4YlY
	for ; Mon,  4 Apr 2022 06:44:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649054676; bh=TxAPFRh5A+iu5spcGBxtacrZ2zVZUX9AYZgx/yMdetk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=sJGV4u8ic5qwO7RbPZv8dLyPFMPYkMsPo5LjbjpZ+zo9Byx8byKqbYm3bDnxFDUQHTzE6Ck5GDTUp1z/i2G3FJY8pLEG4BRsKZ0iA55yhzY9NMQ3DGMsWG8sZR0TD6CMz2ZaeHlLvAvwyfLNrNo8n9JqAnXwiDjjl7jlGP9N81UnXJIF966uB0KXM3eV2Oky2NyvzGDuooGBoaWp93swP/nJMGxBmfxkFOP1N9zFe//2pgQRktB6z0u3gjJ6bFFyrueJtVzbY38jLrf+gCOTGSHfIAPEOR5nA8PknxMTmJMUdCxjanCkc62OKl+76cAY+MAqjcwVghn1wQ+xJUOVgA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649054676; bh=upgcpCdRQxiQbNmWeZsdzlnmHZO+9Ay5QMS+ZrxRjc8=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=LmEizEuG4J8G4JULNlPvN6fROrMqXGDy5rvvUgmQ7ScQL7FMT5kg1FCrOp09St5N/wzO9V1ZPcWyZFtG9JtHo8oWS9k8k0tZQFJsgEg8nGid7Yg5+WiL/j8MpuFNro8QUhUTPvqoQ+U39sXEh1w/ZTLW/Y+PEQpEyfA7LBo1RXbCdgvq3pdg3dcZd4olfI9TNhm6r0eTTj25cpPIKee/VMkDgQfxqp2L4J0AOd13eUFdnkxb4K7Ue2BtN7K4e6sL39AcK6ADWeAo1ajfCh2DZle7cBxCZUe2MjkyBzUuBOsdpBSzQtUU+rql6zN2wCtXaRD0gB9qMo+RjV2f3341zA==
X-YMail-OSG: TGNwESsVM1kcGYigTOG4PECEPop7gWr.SQ4OWJBWi8ozSbe8CUXzLElp9SZzIu7
 TQ9tZeazXQuyRw.eZLgqJ3fdjpyGiXcJdwgw8cWVz8F_YSBBxx8Ck.tfd1VGOeDu8F6TemwVfaAw
 E8bKq2Ecbbq9LZjRUsr9CqmkgKOf0WopIc2XwqrpP_FpBB1Z.5bL27EG4zWVKFM1rhOUW.bH5XZp
 12n0GWM4r7_zESXi.m8h3oyFDvp5HhhMpDnSf1qdBddPtQ9aaTxqyzxKnBGgvl6pRBK4dG0cNE0J
 lEZ6nPZUkgPyzztoZqddLm3IvzDqDc4mCc5hwZIr0xQyR0l6nlltdQobv2pITQWhxtwJHYuiKuEj
 vKBtaPjq55V9IWEY3mbF2fiOT1OA6Yic66QoTHevkdXjV0uv2gI_0goFzL9Is.M9KkKXTVpSuC3c
 ZTQKx81AoSfzaF.qBZYPCrLGGnf2JUil0UITh2CVS.V2TPB4CoTILEMbkHtjiVqcAb4p_fP8IzP8
 .IK947GpvelLg0MgXqtNydo1a7liC_zna99Ud5p.BWb_BlFJgM1JVQrBgdoLwq0k.YY3fy7S3khY
 qBduHFFOQ6cx1e78OT18cRHfQeyamgj7jERhVnw4_Nc6wBnxrRgnbW5x7xOKvbLh1wBcOGM3slTT
 BGIDagn1SlIrysgyAMV4S0h9sC.PQjiXG7jl1xUvwZG6fLOYFvl63ci3t2O1onk5AHzY73DVimGm
 KHxauZwOwJBnQlRXDMu9Qv.HRhPyhW04bAGla.BvfxI15_To8D8L8_wIb4ErLqFvf.47lVBMvKSk
 g9Ba6b7wgEwuXebwYDTGm8sq6bhfaFr.kdy1PzwRI0xOIMU9NHNWdn6RzcSj5UuSibrBfK.nK3_t
 xNai4FleejG9gPQb1kFGL46K6op5mTLZRCAupRU43pt5glm9fYDmeXk9nJ.LPR4qTgn2XK3oh4Vz
 SNF_SDX6DQK1eRK5patgbCOkSbk6uUwZ8.DZELJGazmYuuQADKOY2GnpRmjoVvgFfQc9Jm3vsi79
 0tzkiLBn.W8MXdi6bm8s0h83cKvf_b2wzv0IFH23S4UsZl_zjqcgzCEkPRGZxVGxmfd89pvbo5FW
 yGle_B5AwfJCMWzAzqxd6M6NZSj8W.vs_TQ1LeLiRwKP6drNj9KS7QD6.yZQxVUVMKiDMkaEVDqS
 PrjzCr9SQDAadX1chFSWbrkqkF022sLFQwLJ81crXFPkyFH4h3bmX8LnY3EfMu__0PxEAXj505U9
 TVs5CArGdtV2nKwbSwLn6p9B6Z31dxKByloXONU8Nonuu2Uc4JhW2D96V6xISe9bABcbjpnkLARt
 GmIQUsRCnHDeGey8eDbBGir5JtJeuSMywcggQaymdcl72im09r0ELj2FOARAPBjo9rOGmIJYvRG8
 dmWvRQ6GYLswYLNA16VDvMVqPdtwbSWtRjzAkbQczenke_KAEOFVfhPdQ3_Ak2u5V_999e2rqG5k
 _aPeKzO1qaB5UPAnzusp5cUvLE46rIxhZ.OpKSMZ9EoyjTuc8qlVslBib2.nHccWQuopFn8SPLgW
 PI5H6au1.vM3xa1eMT6nkmPop2ONl3HjfaBkB9o9QmspMOIou0Uu0uKkm_ekEvI3pXAVgp83DlDA
 RjL8hLzntbXhJkTjmPGiPoHHLWXBFZ0gfvvmy5cZSmBJAiKawHPD9d9rVkwcZDV96bbUx8AwgXvu
 nscCIeiZ7qFC8ZSmu8bkO4neHxjLwri2WSLiIoSF8Q80HTePWoTGuWd6YM6cBF4d1b02lUXzzwa8
 Hkhfijl4BeqfwskGV_ClHw9KKjvB7eMpAVzbEyG.2NPKxhE1gYkKCWDDXJOnIneXCuazPYaiczkH
 H7XKX30lDauJirXyHKWp7.yHox4EenLffOx9yX3PPaYCigjtkEumNf7rH8iKhlmuzoJ.P6ZzpPZ7
 EWN3EPonGQOowNf6IX9rXsCz_4Y3M6T58edRF2CUEnxmpP10OZn8EuggqeBO.U0C7C_4xBpv0tOR
 nuZCZ7OFhdywZXT9rCNox6JXsag0gSvUPUAKeyIjHQ2.PG1rbrqNv8MO0nEffIayTsLEBR9aQ84g
 1L__m.iu5hjnu7m_vKz20YjyXQ4ux_w9rr5LHk8DhZ5Bj9vBoBtgw4Ve6yisCqA.0OdpXhRNPmi2
 EWJc3lP96fNFskGyY25L19k19F0QeZOdkdPjhpiSg75TYpS9IL7Te4IR7ROXDc4v5NYUD7QySFxp
 Vt_Iyu7eb19IgBPfiL7LyudSGj2Z71IXHU0mU57IBSyTlK8UXnj1nQ97ZLDE3cMZL_TzD7j7FRM0
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Apr 2022 06:44:36 +0000
Received: by kubenode546.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e68e78bb0b27b397e5b8308133f2bcb3;
          Mon, 04 Apr 2022 06:44: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 14.0 \(3654.120.0.1.13\))
Subject: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants
 with matching firmware requirements; more
Message-Id: 
Date: Sun, 3 Apr 2022 23:44:29 -0700
To: Free BSD 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4KX1V36RnMz4YlY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=sJGV4u8i;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2263
Lines: 68

The 2022-Feb-08 https://forums.raspberrypi.com/viewtopic.php?t=3D329299
reports about v1.5 (via a "Moderator" "Engineer"):

QUOTE
The PMIC has been changed. Needs firmware from April 21 or later.
. . .
The bootloader has supported this since Apr 2021 (previous default =
release).
END QUOTE


I will note that, separately from this, the 2021-Nov-24

https://forums.raspberrypi.com/viewtopic.php?t=3D324653

reports about the stepping with the C0T labeling (via a "Moderator" =
"Engineer"):

QUOTE
Any current production of 8GB will be C0 anyway.
. . .
And just informationally, the C0 stepping fixed a bug in the accessible =
memory region for one of the peripherals, and improved some power gating =
on some HW blocks. The first means a driver no longer needs bounce =
buffers, and the second we save a tiny amount of power.
END QUOTE

Other sources report the EMMC2 bus addressing as no longer limited to 1 =
GB
and the PCIe interface addressing as no longer limited to 3 GB. The
following information is listed (in a different form) in

https://github.com/raspberrypi/linux/issues/3210#issuecomment-680007995 =
:

Old (B0T): emmc2bus dma-ranges ending in 40 00 00 00
New (C0T): emmc2bus dma-ranges ending in fc 00 00 00

(Not visible via a separate .dtb file: the device tree is dynamically
adjusted to match the stepping before being handed over to later =
stages.)

=46rom what I've seen checking on the web and the like, it looks like =
the
C0T stepping usage is not limited to the 8 GiByte RPi4B's (or even 8 and
4 GiByte): 2 GiByte examples are also reported as having been received.


=46rom what I saw, U-Boot had some 0xff800000UL instance with a matching
size of 0x800000UL that was proposed as changed to 0xffc00000UL and
0x400000UL to avoid overlapping newly updated ARM/VideoCore firmware
memory use. (I'm unsure if this is related to the wider addressing
ranges reported above leading things to have been moved around.) The
reference is from 2021-Jun-17:

https://www.mail-archive.com/u-boot@lists.denx.de/msg409182.html

I do not know the first U-Boot release to have a change for the type
of issue.


Overall I do not know the implications for FreeBSD's status. I only have
access to older RPi4B's.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Apr  4 11:53:14 2022
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 3CA091A820A0
	for ; Mon,  4 Apr 2022 11:53:27 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KX8LG0LJSz3npg
	for ; Mon,  4 Apr 2022 11:53:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649073198; bh=zOrp4o2GrDF0IJ/MJMWYorc9R2ZJUN4jlsuHDMpdMjg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=BEyATo3cp1P+3c7YYi/My77TgJTOuWyVWL3k0Cxm6BG4az79B4WDvaRjXrg0ZKhJfXv+w03YgG+UiVamuhXkJ981MC0Rt0bITsI+0YQhdHMOcSTRWOGDRII0s+FKqHYjxQQjSr11ZY1dLhKZUSjg/t88TQ/SRJ7GD0ypH+NiwZBtzVWc79Z88vZB8byJpXlDxX59k6yKW39y375/b+8XnbMKZMgI82TYkxgs/D1T3vVwAXi+lr1q2LD9Dl4RxiwsCiWDAlezHOcolLPS6sBrMrGV0uDPALBzavsKEIc+XIX6SlvrFY4Of3tAd05hNH4oAdBuHaDs44tYNso1K3ufqA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649073198; bh=9ZB0O9TSIrg2HoDvfoQ4yK25UUV/BEVEDcXaijqvx+D=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KpBMdzKpZlhz+QJU6RNNFwvy7a7NLA7dYq4S+US532Wb8zI8jTvax3MGN1GvbBheZzzWkBXtWzQlZM3kR+nH+vZd4B8xlBPYpnBurwrcq5XvoQRP53zaputqqysC2xXFFRQSy29ztzVHh/DU6kbSzoi1OxRfhJCioYKrhH3+G564cPavL0PhM9RFcWJxtl8fd+3ZQpTC7fn/KaXv/0rcLDrNKusnxen1NX6HMa5DK1YumNBCfHybDg60Lo29QY0PJMXLZg+dfFmuvChDo54tGJYDPzFwHldfhUdaXubNi1NZsww4Gb2XT+eUTAvd3SWB+1l8tddsR7Zk5vMQcT2olg==
X-YMail-OSG: NlyJiT8VM1l8jZJ3fSoOBS_oDugkLWlMERAY1.G1C_AzadFUsGY9dRbWuI4SN_a
 3L7ZjuTT44rREWBR.CakVOIiTTpvPTMW9R8GAyQnOiuc6ylsHM8i4mUAZmSOK81eftFvY5LQWKv7
 KJ8_nKABRinRYvUEKAOu5u_U2scZi_zCzeZBNYdfWJJl2cJsg3fZ6nh8luUCEloEt_k3fSJuGoCw
 ISe2u1GHeawvPFf1o0epfihqQpB6Xj6bM8FrEMwE4t0zRH.E6b6OitlXU3kNOD3zIRrgo.W.Sd02
 QOARAKzqEJJQ7Zg6H2C6t99Zhv.XMbNZV_Hb20u2eSxe4nW_3AzGvcZsvVk8WkZfkbv8oQtJzXu9
 nL6zHo69pGCG8hqi48bwxDQNaWnCvdHDi2dzrXlR7_LLUX7__.tJK3.Q5p5PEHngWWQddTQvX2Dc
 EkagLDOSMx7FIoNMarAM.bKMCuG9wOZ4zTU_qk81Ak4W1cKGkPkC8SKB8l8moC4dM3YGxTQLuCfq
 wuwm4z0HalkiFA3NMs1sM.pcrBVgrsHNJ_xKuPycoBn3gk_RyvzdfqdIvaaQb7MEEkbN0o.m7FG_
 0JNNnFmsw.o4HwjxHvgEe92Gqk7H_3gLgKNqEhnEjKy6DXbozk9eFnljOyrA2m.nkbFuN5E1mplb
 AdIbQXOO4UJ7a6dNuUsmZtGYh5XUElOjAwQy2_xc638IHJVPtWqKwBLF.gFSjzk9vGHDXnBNrYJX
 3XznJx4DlJYEpeAbMPvA4GUre4tjbz5S4eWKYQpXFSmpFAqKyptLAMLa5JsBTp9hTdlP3KnVn1QP
 3sHqJ9lk6V1zsxZLJFjaZhRjRXDJkG_xRVFGuQWaGlDWL0Bu7fBQ82LoB2ysWa7K9TKbPhG2MQ.X
 MbF_oSJBWeA1GAtbPTS7tgkb_1zbR0tM64UALiNCvRMm.KEbIR47pa5rjJRc4C9EHuboqXw.H9NE
 X1Iepx8dSNxaksS1Xv5Rd9FwkAwBqbaw.1._iOEplIk9hc3mzc75EMxP7dLiq8WjtRt1WNKoJjfX
 Cy77fZ80cE5gywODixuI9H3pYyIn83sP8NxvPEV5T_6dT.RD1lP8Yxg4ttz637wNjC1Jqfn9R7VT
 72u_lBLEsocCpgfKjTJVglt_8EJlaw_Ycxe7.4ItGzZ9tnCeVgBaXPWb2odLqs3VNz3FGHA_CgAx
 TCCl7VG3a7MJ1K0zazrqFppqfIlzHoNXacfyralowKvdVHozoEgYKZ1jhWr2mZkCq9WkY9g.dHOi
 fCtjAYZkJWbXT_zx8z_bAsUHja9MlF9AjAy5.luCHZuLna0EzheTn6v0ThyUuZSQ7P6xj.VawXCj
 T6n.7m0NSbtuOQGt9QTBD8EE6TYw3V8qUw_eMhDBwgALt_pWmh1w_KOy4Zrw00wV0fwHP9uRCfHT
 5OwSuxKtDE.bKkz6Yv1SD71NH6fLMWMEZV0q7YPIocIaGPhZg40idrWhfCUhaUSpArgc6JUwVXOa
 fdMP_gIuxr3EUby8q4CwqPep_F_rA2Ss8Q6v2wHsf06L8zTElZyzGwIsyH05qTFTrQPadXSUBW8q
 ujZGa1rleRFxYv2s2n7g.OGU8IEu8c6etEjRyg0khlyxMwgzq2nA_eEgsYtXP8a7gxLRCCaSDklM
 iiAzl1wNJSQr_pbDf_5qkG8pY41b3xnl4hgGNqHVEPMmFo2mnTJZYTLoLOXT50rklbwxjEPysqyo
 LkslKeNLe7uFNnDgxgNMwhp79cHYZMRjbZDNeSkrPn_hzS5_ANOftmwMRRsxqVJD1IRMCkq4zQTv
 SOso3Diee3Aw2C6om7IW3SEK_eQfzmNWvF5AK97Hft6kviZ3B5hGDLrgaDS1lmGaGwbq3iitJy5e
 g0xpYH3tKO7QY_lE2SqSldyVCT_L5_eoqn4_mD01raiEl0Gn_3OZDJZnBrOGY4d4hfxmteLW5cDq
 1jf2.iw7SUde200u6s3U5snXti_LwJ9PRwVlp3_CcD18K1khV7BGJmt0Ip.YwrxE.cb88Jb5aIvt
 i1lyoaZ2rq61za1AdOSgCskro44aXw.5jfSxr6XKBElEq32xNiwwGqEzGrecjwrRF2bNrxfk_DQV
 U4RGnYJRxTPaL2x8s6esKlSDmSCjPzT.Ri7Bibj.djv_Xdp6sbIeDbaAftDHzaFAn9AsFUkJmFXJ
 Dtq790N0XmzWBBztdQ2X6.FVkEsfBzeC4oHJYY_1KCj3Q6CocTJbeCo.UIii_gG6WkN7eEo1VeHz
 88BP3ckkxtS7DF0qnyboAXPaa7ghq58sv3EAQDDVakbmNGo8Aqb7lQdfGKor4w_l06cUc_A.EVVI
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Apr 2022 11:53:18 +0000
Received: by kubenode522.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 688755483e26b384645d51c1fc052df7;
          Mon, 04 Apr 2022 11:53:14 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants
 with matching firmware requirements; more
Date: Mon, 4 Apr 2022 04:53:14 -0700
References: 
To: Free BSD 
In-Reply-To: 
Message-Id: <8A72AF2D-339D-4A31-B31F-524E29E9A327@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KX8LG0LJSz3npg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=BEyATo3c;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.93)[-0.934];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5186
Lines: 149

On 2022-Apr-3, at 23:44, Mark Millard  wrote:

> The 2022-Feb-08 https://forums.raspberrypi.com/viewtopic.php?t=3D329299
> reports about v1.5 (via a "Moderator" "Engineer"):
>=20
> QUOTE
> The PMIC has been changed. Needs firmware from April 21 or later.
> . . .
> The bootloader has supported this since Apr 2021 (previous default =
release).
> END QUOTE
>=20
>=20
> I will note that, separately from this, the 2021-Nov-24
>=20
> https://forums.raspberrypi.com/viewtopic.php?t=3D324653
>=20
> reports about the stepping with the C0T labeling (via a "Moderator" =
"Engineer"):
>=20
> QUOTE
> Any current production of 8GB will be C0 anyway.
> . . .
> And just informationally, the C0 stepping fixed a bug in the =
accessible memory region for one of the peripherals, and improved some =
power gating on some HW blocks. The first means a driver no longer needs =
bounce buffers, and the second we save a tiny amount of power.
> END QUOTE
>=20
> Other sources report the EMMC2 bus addressing as no longer limited to =
1 GB
> and the PCIe interface addressing as no longer limited to 3 GB. The
> following information is listed (in a different form) in
>=20
> =
https://github.com/raspberrypi/linux/issues/3210#issuecomment-680007995 =
:
>=20
> Old (B0T): emmc2bus dma-ranges ending in 40 00 00 00
> New (C0T): emmc2bus dma-ranges ending in fc 00 00 00
>=20
> (Not visible via a separate .dtb file: the device tree is dynamically
> adjusted to match the stepping before being handed over to later =
stages.)
>=20
> =46rom what I've seen checking on the web and the like, it looks like =
the
> C0T stepping usage is not limited to the 8 GiByte RPi4B's (or even 8 =
and
> 4 GiByte): 2 GiByte examples are also reported as having been =
received.
>=20
>=20
> =46rom what I saw, U-Boot had some 0xff800000UL instance with a =
matching
> size of 0x800000UL that was proposed as changed to 0xffc00000UL and
> 0x400000UL to avoid overlapping newly updated ARM/VideoCore firmware
> memory use. (I'm unsure if this is related to the wider addressing
> ranges reported above leading things to have been moved around.) The
> reference is from 2021-Jun-17:
>=20
> https://www.mail-archive.com/u-boot@lists.denx.de/msg409182.html
>=20
> I do not know the first U-Boot release to have a change for the type
> of issue.
>=20
>=20
> Overall I do not know the implications for FreeBSD's status. I only =
have
> access to older RPi4B's.
>=20

FYI:

I did an experiment with modern RPi* firmware, with both U-Boot and
RPI4-UEFI-dev v1.33 (but having the 3GB limit enabled). It appears
that there are possibly significant additions/changes to the device
tree content presented to U-Boot but I've no clue if this explains
some of the below or not.

I did not expect this experiment to end up correctly booted via
U-Boot/Device-Tree usage. It did not.

Note: My new understanding is that 2021.10 is the first release with
the 0xffc00000UL and 0x400000UL usage. The U-Boot I had around to
test was based on building 2021.07 from one of the ports (with some
historical patches for my context). This contributed to my
expectations.

RPI4-UEFI-dev v1.33 based booting with the 3GB limit enabled worked
with the firmware/dtb combination.

FreeBSD got "clk_fixed4: Cannot FDT parameters" (and another message)
over 50 times if I counted about right --and crashed with a backtrace:

db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x178
panic() at panic+0x44
data_abort() at data_abort+0x2bc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
bcm_dma_allocate() at bcm_dma_allocate+0x88
bcm_sdhci_attach() at bcm_sdhci_attach+0x310
device_attach() at device_attach+0x3f8
bus_generic_new_pass() at bus_generic_new_pass+0x120
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
root_bus_configure() at root_bus_configure+0x40
mi_startup() at mi_startup+0x224
virtdone() at virtdone+0x7c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x48: undefined       f901c11f

But I've no clue if the U-Boot vintage might be the
fundamental issue, such as via trashed memory content
vs. the RPi* firmware.

The "Using DTB provided by EFI at 0x7eef000" does not have
the historical address listed. The boot also reported:

WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance


My guess is that RPI4-UEFI-dev v1.33 with the 3GB limit enabled(?)
has a good chance of booting the modern RPi4B's. But it will have
the historical lack of support via ACPI booting for:

the built in EtherNet
the built in microsd card slot

I've no clue if a RPi4B that has no 3 GB limitation would
happen to be handled appropriately by FreeBSD under ACPI
use that does not impose the size limit. It might, for all
I know.

So there may end up being a class of RPi4B's that are more
supported by using RPI4-UEFI-dev v1.33 than by using the
U-Boot ports. (To my knowledge no one is working on keeping
things working for RPi4B's [or pi400's or such].)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Apr  5 14:56:10 2022
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 3FEE01A93DA4
	for ; Tue,  5 Apr 2022 14:56:11 +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 4KXrLf4Qjhz4jb1
	for ; Tue,  5 Apr 2022 14:56:10 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 60C8EA91
	for ; Tue,  5 Apr 2022 14:56:10 +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 235EuAju034067
	for ; Tue, 5 Apr 2022 14:56:10 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 235EuAmh034065
	for freebsd-arm@FreeBSD.org; Tue, 5 Apr 2022 14:56:10 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 263063] [if_ure] ure0: attaching PHYs failed
Date: Tue, 05 Apr 2022 14:56:10 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: freebsd@sysctl.cz
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649170570;
	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=oQCTI4wv53F6GeQZZnFD47FhIUfsUIQ6q5kTOKHPXCs=;
	b=ZDY9pc6KB7dS51eSjeUU0ACVA9Wbo1Ld3eJ4Z5acEdOLjsdWWentctPFwUJ2VA/JUPClNW
	CQ1pH4mbHxUVYIZzyUbH3kvn5ZKdGDI5CE0Cc7trDVWUMBuo0C58qw+ybqAZ2Vd1bsXFDG
	mJAh2gvlsNFtmxKPuOwppy1HxEg8PdyJMwdApzPgxZR/2QoprZis9P3XJdgcFqx22himKe
	GBVYjcvbpQwqaqyaQ1X1pxUL7CEmPRONGMTXjIy2SYRlWTP9K8KXEce/WYjcSyCE18J041
	G/tG7CQ+iABanl34t7FFeCwwXVR9vnxcsnfLkVK5Dfrw8wpT8/7nWbgg5LeSug==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649170570; a=rsa-sha256; cv=none;
	b=SYsFnSr9jhHU6nLrN1f0mXYSK2hyFBJV0cMWU0Y+MRxY1ra2OsfhGxDWaklfPRjTl2TEAq
	zOV9cL1EncYLy7qguMkVG3CQfgtVaJIg0YEU9wCXFOu5UmAyK7jaA9BDXtYYYu8gxhT3gM
	lalE0U2HZdNzkJpm/hgZg/kq0TQZ8gxX1ARNaRT5AfvHdvfd8POU7u2j3pu21EAiZ9pCOb
	El505Mlo5IjaGmWL7NQDApuowXd7nom8UMebv79y7CMgzaY0zpKHxN5eoeIAJcBDqgqkcN
	jrGrcT5b+r+wphMsy4UFiYu50iY5DiQ0yxPAadqYLcZIC/Gc0ImClJoCZIxdyQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5209
Lines: 116

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263063

            Bug ID: 263063
           Summary: [if_ure] ure0: attaching PHYs failed
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: freebsd@sysctl.cz

Created attachment 232970
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232970&action=
=3Dedit
message.txt

I have new board orangepi r1 plus lts
http://www.orangepi.org/Orange%20Pi%20R1%20Plus%20LTS/=20
and have issue with ethernets.
I dont see ure0 in ifconfig and dwc0 has not link.
I try service netif restart and dhclient dwc0 without result

dwc0: flags=3D8843 metric 0 mtu 1500
        options=3D8000b
        ether 22:9f:8a:bf:dc:f6
        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
        media: Ethernet autoselect (none)
        status: no carrier
        nd6 options=3D29
lo0: flags=3D8049 metric 0 mtu 16384
        options=3D680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21
# Jan  1 00:06:19 orangepi syslogd: last message repeated 1 times
ure0: timeout waiting for OOB control
ure0: MAC assigned randomly
ure0: attaching PHYs failed

Jan  1 00:01:08 orangepi kernel: GEOM: mmcsd0: the secondary GPT header is =
not
in the last LBA.
Jan  1 00:01:08 orangepi kernel: GEOM: diskid/DISK-5A201608: the secondary =
GPT
header is not in the last LBA.
Jan  1 00:01:08 orangepi kernel: Root mount waiting for: usbus0
Jan  1 00:01:08 orangepi kernel: uhub0: 2 ports with 2 removable, self powe=
red
Jan  1 00:01:08 orangepi kernel: ugen0.2:  at
usbus0
Jan  1 00:01:08 orangepi kernel: ure0 on uhub0
Jan  1 00:01:08 orangepi kernel: ure0:  on usbus0
Jan  1 00:01:08 orangepi kernel: ure0: unknown version 0x0000
Jan  1 00:01:08 orangepi kernel: Warning: no time-of-day clock registered,
system time will not be set accurately
Jan  1 00:01:08 orangepi kernel: random: randomdev_wait_until_seeded unblock
wait
Jan  1 00:01:08 orangepi syslogd: last message repeated 1 times
Jan  1 00:01:08 orangepi kernel: random: unblocking device.
Jan  1 00:01:08 orangepi kernel: dwwdt0: 
mem 0xff1a0000-0xff1a00ff irq 20 on ofwbus0
Jan  1 00:01:08 orangepi kernel: dwwdt0: cannot find clock
Jan  1 00:01:08 orangepi kernel: device_attach: dwwdt0 attach returned 6
Jan  1 00:01:08 orangepi kernel: lo0: link state changed to UP
Jan  1 00:01:08 orangepi kernel: dwc0: link state changed to DOWN
Jan  1 00:01:08 orangepi kernel: Security policy loaded: MAC/ntpd (mac_ntpd)
Jan  1 00:01:09 orangepi ntpd[1005]: ntpd 4.2.8p15-a (1): Starting
Jan  1 00:01:09 orangepi ntpd[1005]: Command line: /usr/sbin/ntpd -p
/var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift -g
Jan  1 00:01:09 orangepi ntpd[1005]:
----------------------------------------------------
Jan  1 00:01:09 orangepi ntpd[1005]: ntp-4 is maintained by Network Time
Foundation,
Jan  1 00:01:09 orangepi ntpd[1005]: Inc. (NTF), a non-profit 501(c)(3)
public-benefit
Jan  1 00:01:09 orangepi ntpd[1005]: corporation.  Support and training for
ntp-4 are
Jan  1 00:01:09 orangepi ntpd[1005]: available at
https://www.nwtime.org/support
Jan  1 00:01:09 orangepi ntpd[1005]:
----------------------------------------------------
Jan  1 00:01:09 orangepi ntpd[1006]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): good hash signature
Jan  1 00:01:09 orangepi ntpd[1006]: leapsecond file
('/var/db/ntpd.leap-seconds.list'): loaded, expire=3D2021-06-28T00:00:00Z
last=3D2017-01-01T00:00:00Z ofs=3D37
Jan  1 00:01:10 orangepi ntpd[1006]: error resolving pool
0.freebsd.pool.ntp.org: Name does not resolve (8)
Jan  1 00:01:38 orangepi kernel: ure0: timeout waiting for chip autoload
Jan  1 00:02:17 orangepi ntpd[1006]: error resolving pool
0.freebsd.pool.ntp.org: Name does not resolve (8)
Jan  1 00:03:22 orangepi syslogd: last message repeated 1 times
Jan  1 00:04:08 orangepi kernel: ure0: timeout waiting for phy to stabilize
Jan  1 00:04:28 orangepi ntpd[1006]: error resolving pool
0.freebsd.pool.ntp.org: Name does not resolve (8)
Jan  1 00:05:08 orangepi kernel: ure0: timeout waiting for OOB control
Jan  1 00:05:35 orangepi ntpd[1006]: error resolving pool
0.freebsd.pool.ntp.org: Name does not resolve (8)
Jan  1 00:06:38 orangepi kernel: ure0: timeout waiting for OOB control
Jan  1 00:06:38 orangepi kernel: ure0: MAC assigned randomly
Jan  1 00:06:38 orangepi kernel: ure0: attaching PHYs failed
Jan  1 00:06:41 orangepi ntpd[1006]: error resolving pool
0.freebsd.pool.ntp.org: Name does not resolve (8)

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Apr  5 17:31:53 2022
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 36C8A1A94744
	for ; Tue,  5 Apr 2022 17:31:54 +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 4KXvpK4YcCz3Qnd
	for ; Tue,  5 Apr 2022 17:31:53 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 7D7B32D36
	for ; Tue,  5 Apr 2022 17:31:53 +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 235HVram019273
	for ; Tue, 5 Apr 2022 17:31:53 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 235HVrRH019272
	for freebsd-arm@FreeBSD.org; Tue, 5 Apr 2022 17:31:53 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 263063] [if_ure] ure0: attaching PHYs failed
Date: Tue, 05 Apr 2022 17:31:53 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: freebsd@sysctl.cz
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not Accepted
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649179913;
	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=Tx2PBKAGKszLu0RWnrFGx52rwRqJc8TUoJYn6HyhajQ=;
	b=GKrT2JK3NKRT/EkhwrGOwkk0ljMNSW8jNTNCY/DS2B2YN8dH6Y90j6VOlzvzpAJKCGWlPg
	0HDHfX+40QMqgXJpLebtO472mUjKFqmZwN/1TkYWR77AlhijgWhB1KE+knad+oC4zdnrB1
	HJlbKo4r7fCtJeowSJ5Ksn4kh1DYRnyQvFwKT5lXt3VHaWZhqHpc+lYZKzR+7kAro5yDS5
	A5oZmecOxf0MCXOZIoJKvgSKCKF2nMFCoI2TDC+Y4UnawRrxFFfxXcOrfpAVfztqURw2fw
	V/i1tnzhD6sMfedvzcFxfFwd63FY5EH9TgnxW+JuP5WnC7EzfVkdBomgY3ao1w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649179913; a=rsa-sha256; cv=none;
	b=QwibO4d8wlo9dy/77n8jcmieqN42I0y80tG1aLILV2xtugnYKi6VzrUVl8FTUS3kTJvn1j
	xpR6DCgUc6USESGgUOHrhduALqbqAehhbaPwNRwgN1EB5sfzACOpBKGeujfoJPZ3HTD9sA
	aAJE5uX+aLG3JVMnuSNyJWe6da6KkibyaB28Nrw8SUQgML5RQXW9euqvOUSSnJmaao6FkU
	9MKDxwZAc8+Lh8Dvi8VgFLjjUsiidLcGp/4JyxQKm5mLQY0vSeXcI6SMuvnLe/xV4pl9dZ
	Ss78fmGBBJHFF5ZqyJOCQwmOKjFFnJrpC28TCSsA4lzxYs2a3znUuzeZR6oWEw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 432
Lines: 12

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263063

Martin Filla  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |Not Accepted
             Status|New                         |Closed

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Apr  6 08:01:31 2022
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 E48921A99555
	for ; Wed,  6 Apr 2022 08:01:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KYH622fFqz3NWh
	for ; Wed,  6 Apr 2022 08:01:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649232099; bh=0qP5PJVXjuzYG5RbgVnZi8pHYsjlKNxBYvHV6Eumz8Q=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=PUquP0WCcFTFyb9/017lC2sGZFSv8FdUz3GKYgQ9HtSg+8YEZ2J9XDveRrkBY8sy5zA5Dj3rCgBSA2c9ugIzXX9PY8Q3Hkrk1Js4Hl0IW3V2QOGU3IC4jFsrb+p0srZrHLcozOuX9une1xaQGu1trDluJlgJoRUvJxXGRkXFDDcJlF6Eiv2bzfMkAPvsfSfQ2sNfTF6c6Uq3uVSy1EYO68Gg1ciwDGEsYYnK6sXxDTOxw6X8i20cfTL32An0cyrbJ+/kfq2icbmQvto4EcT0II2XtYwlfvTR+CfkTFgktRFoz5W1vzRjJUM4889Xry17sXuvNtbmahWL6vKUwc63rg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649232099; bh=/61Dowxuf9JpVbcWHQr0sWVMG2A54yg3drre63snZlf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=J3odOeFK//SZGVwqnIy3Um3pyX67I9zUdCl9NZCrGrsi93Wv1fecDmwY6xIDJvQeH3QeX1dbUKvg/iLhRU0M8xN2Vn8hVCh51bNrk4V5Upbz37ArMwcBUEOoqrydfK4jvMoMZ/Eoj6D9fcTngNWvigRuqLT6GFG8Y7GThVxNjxbHDqBNyT2xONrbm4V0hVMvY6NO+Qv8S5gEIVCVDZ7r2ARN/QUWlLrg+WmtZ77IyQJYWnvWiLadvclmJ7u0wTQ+4JCyK6p2g+MqjVrsN9nareuyr5x/KWKCn9D5TXejgTHyZ3tCN92yVprM0oaHn/b4w6b9t3kpZSWJWzckz7Ptog==
X-YMail-OSG: CsipixoVM1lTIecQUcXvu1ZLX6EMysR57c52l8FWQGmpCK0p2XxKJEJ1zcybK8Q
 gkzg0vh4dBQTxcSl1I_4yxyNZUiEfYdellT5wJILWvRuoLEIHsAHY4E2Xb_46ufB3FsetlWXzHPu
 nuttywic6Yy3P5D2gAiHWSYpeibncnYQldQWDDx.3gw8jKfujPBJnN4rX705INhmvMc45PLWxzKu
 uR47lJPj2DEMFIrw0GtdDoMAi7G6u596NYY5ED5_i1U42BX2dZjBDtgZmh0KcRwkRY9uEvNyNfb6
 NoBXCheLBHbskD2MyGZ0P5Ik3.WY7imvrWTO3vZO1kISYLCMN41vUAUEhXADqLiLXqXnMIpdEpXk
 g1qUH02iw.U3LYhwN7iuVpgSV0io.W1wBwhJc2jAo.En3xOngWCrZArYvKGQx9p0dHdOvM2g6gNJ
 N06Ane1ugIZvb5wTKrulyk6qc80MyboF0lUzpjD9kc0a9G4Go8ej55rcOF5WvY2UbaQsIgvyIYk1
 Jlt97_g9Plkydl2PPI0oasrwmqUN0eru_DGi9gw81YwqCSH87KpWTKm1BUF5VYlrJ7IjCM3ITB63
 TAUP9RBFYTcgGm5Dm98D_JAaR7h2hVltdS42f3DtaWSnmUXH3pBIoq9wchM0oP4PIZFMZS63_lnC
 ybXBfYA6mMwpu4mgT3BQxDSrEGthFfNAA9gxtxr_XaHl1v5OiysPNK0Y89ej3XEY4.NuJisayi8B
 KxEeG9PkMJweC5AYtr0aJqqmXP0YpUqjmGqoFtNBbSTTsy6NhPHvCSV349VQetMriD5KbVihlEZ8
 4Nxe5euL.VH2cQj3jDh3aMsmMEKzVFDN0wr0X3rSAXLTKyn91HsH1PmveRFj2A4vFQECRQ1jg6cd
 MxsH0apghDxFOagdBk57HXcHCkzeLGlttv_eg9A2YSfZf8E.QdFG..gqbhLTZ2Imlji5phYgciBN
 VGWIhx0TrCSzLQY7IjBpwx____vBFhAL6AXWxluxpainvMNmfCgZTbXw4UTIzd3oeEqOHdPWhGlS
 yuLXWEVgxOkHndQQP21PGLORnPXMwOnU1a_jq.E0xIZIuorZNTYYPDQmFEsQb3AGyHyf2LVoqHfe
 1l_xXOgewzBPnpiBHqp.tD7tlBQivg4SklEYh9Fg0opW.cX6uv.blAOFij3etNQq3LVcqgS1DIwh
 WYqnr2bTjJLa49lON1xgX4SCrHYEWV5rPANisHrcK3vZSX1YOwxrbpsBUxxbjOxdfMVDhCFQAVnv
 AaI_r.V1ln9v.7_EL__i6MTO.8BnGcHh5KmIVSFhs8DJt2uOqQjLXG4twFL.ZiNV4WhEG.TA3T8V
 IccIxBr1wpuCdDylmvuMmvQ1z8lQWvhQinmO2cnYRieOd_vcbzVmKWSOnPHCZ6R7UktgnvwdLvM4
 J95ZwOmlbKjeIdLTW74kVvw4Z14kkVQ.gWKta9AJIDLaPIJ.dvNFJCPuAYlHhLcyaV6LTMKrH38R
 cJZBkeWHVw2SRnxSJUZYOWE0i.rSk.QjKPgRZnJzPtuNOCYSGClLG76FawoatKYU17bW_VRlzeBZ
 m33NckyC3uQ2GEeNd4yMZwrvDwYJg421_xYB2afcd7THCL9aHn0dgVSba80fP41wKCT9TCw3kJKl
 Z9.LMeTY8vtyJZ.aLF9jEO1d.Aya80GcwwTI.TbwjNPQVNDmxStUvEZ_XDhWFtuKx1aNj3Ocs.Fd
 97CIpIxAXsZYONIkFGy2wks7V6BdimpK.bQVaMrLkUpCF0yo6OySNF3NGkSa1T1EPvgGvFOPOL5y
 Gly2usaamgRzqmhuHVzXXAPerp9vN7WpeJCFKkIDhfMS3BP6tlBy9OhWSVkDkvA7BlOwLDAypdcg
 _47z3zE4hPi3xLYhXqp9eNx1MRpNr19Wg7VZ5rf1onEBXyoZwtdU_BAFIh_9DE70aoEbzZlrjXCT
 llAIN46wdeYm4lAk5fmcvcVsdO2w5IJ4gW5RgCw7Z7zQdd2ewOhIbaKhQr0pZ94Vi3HgWQnP8E.L
 _kbiDvbWWBPupC0j1EcPXa5q4x.wWWwkHCLoeGUr8It5y0uu_1ojRfrkQ4gFGm6vk99NOREdPmd_
 MLTnTYGHmpcg5DuSLfCfqDhdoOP5H.7xspy2QTiwTDAeGWkt9KJZcpv2RPVDyHdLWTuPSsKzsuLe
 5E0W2ZIOLSJ5Emw8N723wO3IAJTyOvAmRvTc3eKJIAlnp3p.xmwumctbsB9r3Lo8FO0y_Rd5cr_J
 e5AeRkX3GoQlS8qOvNfQjMyeMCOwNAKBlcT90.ubO_nqZXaFpL4ooRZjfkyOuLgFVxldtKqvZFsh
 aKG6RiHQlHbvqg.kEg8Y-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Apr 2022 08:01:39 +0000
Received: by hermes--canary-production-bf1-665cdb9985-85ftg (VZM Hermes SMTP Server) with ESMTPA ID 65bd5730589b7fcb224bf667594af052;
          Wed, 06 Apr 2022 08:01:33 +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 14.0 \(3654.120.0.1.13\))
Subject: https://github.com/pftf/RPi3 UEFI/ACPI based booting:
 gic_acpi_identify crashes dereferencing a NULL pointer value
Message-Id: <6609AB07-942C-4E06-A99A-2B3A0D65D970@yahoo.com>
Date: Wed, 6 Apr 2022 01:01:31 -0700
To: Free BSD ,
 "freebsd-acpi@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <6609AB07-942C-4E06-A99A-2B3A0D65D970.ref@yahoo.com>
X-Rspamd-Queue-Id: 4KYH622fFqz3NWh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=PUquP0WC;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.44 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.94)[-0.941];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3814
Lines: 132

https://github.com/pftf/RPi3 UEFI/ACPI use gets a boot crash in
FreeBSD's gic_acpi_identify:

. . .
MAP 1d0000 mode 2 pages 32
MAP 339d0000 mode 2 pages 80
MAP 33a20000 mode 2 pages 256
MAP 37000000 mode 2 pages 400
MAP 37190000 mode 2 pages 592
kbd0 at kbdmux0
acpi0: 
acpi0: Power Button (fixed)
acpi0: Could not update all GPEs: AE_NOT_CONFIGURED
psci0:  on acpi0
Fatal data abort:
  x0: ffff000086ffe6b4 (crypto_dev + 858f044c)
  x1: ffff00000103d0d0 (initstack + 30d0)
  x2: ffff00000080ed2c (madt_handler + 0)
  x3: ffff00000103d0d0 (initstack + 30d0)
  x4:         d2d9fffc
  x5:                0
  x6: ffffffffffffffff
  x7:             2001
  x8:                0
  x9:              400
 x10:              800
 x11:                0
 x12: ffff00000103d8dc (initstack + 38dc)
 x13:               b6
 x14:              551
 x15:              16c
 x16:                0
 x17:                1
 x18: ffff00000103d0d0 (initstack + 30d0)
 x19: ffff000086ffe598 (crypto_dev + 858f0330)
 x20: ffffa00000dba200
 x21: ffff00000103d0e0 (initstack + 30e0)
 x22: ffffa00000c37a40
 x23: ffff000000ec8000 (devsoftc + 88)
 x24: ffff00000097fe1a (digits + 102f6)
 x25:          3800000
 x26: ffff000000e74000 (gdb_tx_u + a98)
 x27: ffff000000e74000 (gdb_tx_u + a98)
 x28: ffff00004042bd28 (crypto_dev + 3ed1dac0)
 x29: ffff00000103d8e0 (initstack + 38e0)
  sp: ffff00000103d0d0
  lr: ffff00000080e908 (gic_acpi_identify + 7c)
 elr: ffff00000080e90c (gic_acpi_identify + 80)
spsr:         600000c5
 far:               14
 esr:         96000004
panic: vm_fault failed: ffff00000080e90c error 1
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x178
panic() at panic+0x44
data_abort() at data_abort+0x2bc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
gic_acpi_identify() at gic_acpi_identify+0x80
bus_generic_new_pass() at bus_generic_new_pass+0x44
bus_generic_new_pass() at bus_generic_new_pass+0xb0
bus_generic_new_pass() at bus_generic_new_pass+0xb0
root_bus_configure() at root_bus_configure+0x40
mi_startup() at mi_startup+0x224
virtdone() at virtdone+0x7c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x48: undefined       f901c11f

This turns out to have gic_acpi_identify+0x80
with the code shown below:

ffff00000080e904  bl    ffff00000011d640 =

ffff00000080e908  ldr   x8, [sp, #8]
ffff00000080e90c  ldrb  w8, [x8, #20]

and the register dump above shows:

  x8:                0

Looking up the source ( sys/arm/arm/gic_acpi.c ) there is
the likes of:

struct madt_table_data {
        device_t parent;
        ACPI_MADT_GENERIC_DISTRIBUTOR *dist;
        ACPI_MADT_GENERIC_INTERRUPT *intr[MAXCPU];
};
. . .
        bzero(&madt_data, sizeof(madt_data));
        madt_data.parent =3D parent;
        madt_data.dist =3D NULL;

        acpi_walk_subtables(madt + 1, (char *)madt + =
madt->Header.Length,
            madt_handler, &madt_data);

        /* Check the version of the GIC we have */
        switch (madt_data.dist->Version) {

So it appears that madt_data.dist held a NULL pointer value
that was not checked for. (I've no clue if such a NULL is
supposed to be possible --but I do know it occured.)

The following lines are:

        case ACPI_MADT_GIC_VERSION_NONE:
        case ACPI_MADT_GIC_VERSION_V1:
        case ACPI_MADT_GIC_VERSION_V2:
                break;
        default:
                goto out;
        }
. . .
out:
        acpi_unmap_table(madt);
}

That might suggest that madt_data.dist=3D=3DNULL should lead to
a "goto out".



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Apr  6 14:10:55 2022
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 711FB1A8F2B3
	for ; Wed,  6 Apr 2022 14:11:04 +0000 (UTC)
	(envelope-from luciano@vespaperitivo.it)
Received: from baobab.bilink.net (baobab.bilink.net [212.45.144.44])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KYRJ74nPGz3KdJ
	for ; Wed,  6 Apr 2022 14:11:03 +0000 (UTC)
	(envelope-from luciano@vespaperitivo.it)
Received: from baobab.bilink.net (localhost [127.0.0.1])
	by baobab.bilink.it (Postfix) with ESMTP id 4KYRJ04VnGz1ftWm
	for ; Wed,  6 Apr 2022 16:10:56 +0200 (CEST)
Received: from hermes.mcs.it (hermes.mcs.it [192.168.132.21])
	by baobab.bilink.it (Postfix) with ESMTP id 4KYRJ04990z1ftWg
	for ; Wed,  6 Apr 2022 16:10:56 +0200 (CEST)
Received: from mordeus.mcs.it (mordeus.mcs.it [192.168.45.6])
	by hermes.mcs.it (Postfix) with ESMTP id 3CCFF4E607C
	for ; Wed,  6 Apr 2022 16:10:56 +0200 (CEST)
Date: Wed, 6 Apr 2022 16:10:55 +0200
From: Luciano Mannucci 
To: freebsd-arm@freebsd.org
Subject: Installing Freebsd on RPI 4
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.2)
X-Face: 4qPv4GNcD;h<7Q/sK>+GqF4=CR@KmnPkSmwd+#%\F`4yjKO3"C]p'z=(oWRnsYBQGM\5g:4skqQY0NnV'dM:Mm:^/_+I@a";[-s=ogufdF"9ggQ'=y
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
Message-Id: <4KYRJ04990z1ftWg@baobab.bilink.it>
X-Virus-Scanned: PippoLillo, ClamAV using ClamSMTP
X-Rspamd-Queue-Id: 4KYRJ74nPGz3KdJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of luciano@vespaperitivo.it designates 212.45.144.44 as permitted sender) smtp.mailfrom=luciano@vespaperitivo.it
X-Spamd-Result: default: False [-3.27 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:212.45.144.0/24];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[4];
	 DMARC_NA(0.00)[vespaperitivo.it];
	 NEURAL_HAM_SHORT(-0.97)[-0.970];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:8816, ipnet:212.45.128.0/19, country:IT];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1106
Lines: 30


Hello all!

I'm new to the arm world. I've bought a Raspberry PI 4 that came
with it's raspbian OS working as expected. As it comes with systemd,
I flashed a Devuan Image on an empty Micro SD card via "dd" from my
freebsd PC and now it runs happily. From dmesg on Devuan I see:

[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.4

(I can post the whole dmesg output, if relevant, tough it is a bit long)

Being Rev 1.4 > 1.2, I did replace u-boot.bin following wiki instructions
found at https://wiki.freebsd.org/arm/Raspberry%20Pi and flashed the
13.0-RELEASE with dd on a clean Micro SD card.

Now, if I try to boot from it I only get a colored patch on the screen
attached to the RPI 4 through the same HDMI cable that works well with
reaspbian and Devuan.

What did I do wrong?

Thanks to all in advance,

Luciano.
-- 
 /"\                         /Via A. Salaino, 7 - 20144 Milano (Italy)
 \ /  ASCII RIBBON CAMPAIGN / PHONE : +39 02485781 FAX: +39 0248028247
  X   AGAINST HTML MAIL    /  E-MAIL: posthamster@sublink.sublink.ORG
 / \  AND POSTINGS        /   WWW: http://www.lesassaie.IT/

From nobody Wed Apr  6 23:37:45 2022
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 BAA3C1A9EB18
	for ; Wed,  6 Apr 2022 23:38:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KYgtH4Ym7z3slw
	for ; Wed,  6 Apr 2022 23:37:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649288272; bh=KhKCMnppS8qoL9kjDRvMb6sp/cJLoh/pS6EIR6Yd6A0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qz8xxlsFzGZeoiDnZvLgmRbDCsyAd0yuOs6lZTp2s9CSGVN+7UTffpSE+MUi0LYYsxhnE0O/umwKLausEmSzda5sKlXz5aO0wz1h+aA78Bjrxt2rzKU0kCOUSYmKq3d6Afb0tdvEuWkBD46cyxofLr9R1gAOXtPHLbm0noRZDWWwmU3nOo5ywmKXPJL/MCTqx6Sg72wtbacVfE6i2lqCVgGcWtfcLoIVn+FDyIQ5aWe0wMAw8yr2aj6B4ZQCB1NQ8f79fOdVToy2PzFnD4TxfjrzahYau00F9grj6wpNbhOSRIiH3bqKG2GDOpnVmQxCkEFJqS8UKPx+YLxfJf3t8g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649288272; bh=dz7Cu91DeBfbYTx/pK/FllzkRukI/GTNVwxxE5J5iM+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fe/90YK0pQnYWAEwIFcC77JBzbyvWF3NvVg+pnWCV4VwyqRuTdjUPNAIdzGf3sE8U4cS7pWVE8IuNz0z1RUsnup1Kq7W18hC60Y3C4Y4aR3s3HT9rzYXS9P9X5ROjslcAtYGNg2IZDs//8bObyum70t+BSnwRrwQKcRn/hMwy1AGpkJ/zBQvQ8kyvTpwp1CCJt7+j0Ct3We/X+SDaGl2NRI9s/puxG0B3Zvv36K9MNckhW0LNMCRzhEbusuT1NCPbMgzKxOpNpnpzevQEVN8Ke6ci7e2IyVw1moAYm/N0VT6th5C7Ko4raIkxo4dNqSt40x3nyzjOIAKwHCc9ZdZTg==
X-YMail-OSG: TrgtjeAVM1lhinl9MfhVARZC6aWA7NmDHxuQkHl7mB_37PENAoYtCLD7n5IbQxK
 NEdON1754ZfKVRvVakAw8_jTcyiPP1Hba.vUVXCIVlghbE6jqMsrModwqnP1gIlLra6mOliDOarA
 M7fca.IjdQqClUrdLaitS2oOMHn3B7k4tMaZfzxqGH941rDXLfi_rnGhvrFBMTgzbKbw9NzyMXZ0
 5SU2h4Hol44Ae8THIa2G3y6TkDMQTRnaGTFCRkDfDyBo.luW7E6y2TFp3YEKhViVn5ouaDLkgSHJ
 n2k_vSyYN.irsmsQgSUw4QnHDOa0.S_Yl_kZ5eC2OIegW6KWvVxVfujms7Fl0ERTTWNVNgWIR6Oo
 AkhQBuLRFBKpfiVihwhZI_4LZ9uvixYOhqnJ4UUDoZ4kOlCkeOi5gXUtR0h4VApkDbk5PMJBmGPB
 xIND0coGqVIwjp5DxBf68yU66GUcvNBKjIKg9cSerQTqcIOwD5foeqTOjdDmEOvfip24wWefsE2w
 XxvSr90XkYECcSjOSZvb1gurMXZHTyYwmH.02lkyVGLKSmF0Ir2vyTKhym98ls8WSBQpWOYqpC_d
 0mrdlTBVvG6PFS7Iq_m0BHeu8LatToPOOVJeGwvBnFuIev5Rc36w3wczbMxZyjMLNslhfx0z52Ok
 IdX2t4i_N26eX_UcyG2IoLpnKQ6Zf1_OR9NPlaRk6EZ1JA6RFJ_.NsZDaq3nM.fskljMs7692Whk
 dSpFthOzjqJFuizlT5lBHJPk1V1jgauPyJ3ynaw4qQOxNb.5Kptn3Ys9ay6mDKbjosU7IjeUdQCy
 I7ItrEVzTa9HqeeT.BTzT3Vx2eUG2PjE6lkqGP1rzw9R4G7hUaNA.VLuJcZ9ZtXmTfTKsbVJ8Ibe
 M2zLfE9La89Qz3s1w2ep6ak88FBXUmXhWMWs7BExBqYlsv..oiqUsBNrOXwvdkJLBKILGFIp6Y2O
 sLdSpf3ecg0lziC.X.BNfmNzN5.a6tvj2EZckNOZ8a3fyfI0khUJtiCie0tQ5s9crPG4mmvF9j9G
 bhdXc_7YGZuj_FxXa24RYwDLDv5R.l6tp4OmVZL71TOZCXdG_ixow.tpCzbXEPckhkl2cBnUHy7C
 .9Ow0voPXlg3JrTP2qKXSmLNwfthf9zNKcCHi0dZW6qajjFpnm2dmC7.kDPUMEIk0A.p0jlVz.5c
 azEiKqzYG8Y_2B8S_i0lgyeYRZGpX8_qBSeM0WBVeqBpsz2hjnNkSK7ndH7YHFcqVT9UNc0L2Kq3
 z2sz.MJb_ZjAY96G2XxjjNCpCwRRSNB2jbdmbQCgWxJ1ec6Rkud3HrhQrz7oabLJ3st21LOuUZp0
 F7dbJao8j.EOhdE6pOWpR1FfFGhnYk4rjwwzF5FL3iJPrhZkp9txYRsFUuvZFkXcIBVVF5cNYhtc
 Yg46cvGkyaM1xBFy3A5sGGusElETBjHIJY3Wm9Fao6A9Az9vBghEtj8AA4fYnrVVhnsyRlo6sPxp
 ggHT71r8ZOs2RkFITOgQPNOklccax9sVL0NYguUhZNk4kkKdOoHCA7_JlxjBgYcEFLzpa50yIT5p
 FpYe.b53VpQO7mVVeheUdIw_5EOIRFJw44XsUlTdV5quqZFG7ZxnUljZKj7h_ofEQHVwDlMAfndH
 pQc19bRTElKz3bo_CMTGXhR3IF92WwoK4TqtTTivJnEMC7z0PB2srjOkeyQ2sWWV72_wZNeObA5K
 34FiTXVBl8CPSRKl.ifPminA2hvzu_g1Ks7hWlMdqfXmubQOGesCw6eSL3sJegN5bnKK_MVLGOGU
 T_lHxVg991F88rb8fPp94oh2SUl_Jxrxfh1yGG5iE.qhW5F30EfTYLf3HVYd2tGvwIfTjk0viA8e
 uPT3oVmTwtOi0NiYEvx3rHrd2z0BSJsbYDCeqPpauU.DDq2qbs8g6GdXFoFFdLVMW2w1lteGMwDu
 t1AJxYTuIbWKiOkOykUG9QiZoXq88R1XI4XyUiCw6QbsSbkQDHehwVKkRCjRYVic7GUq6a4F2Uhd
 .A2tm8kaa.9UGXVnRs1B0Q6c6DwHkQwIRWzvowQjNJ39_W7QW2vvg7nDRwa0TdtUIfHVq7eRuUTR
 pv88.DbhbWe26UcysaBewK7vh8MTPqATmQ95Q9SJDiZPnUM9nPgl6KgxsIxEn2ltpAN23yqORp8y
 uIQZsNoaYRWtmVjBJyIyoIpRFc.xTGOxROjwz7.EJhIcJkP2HC788KK0Jz52qi1aybrxibyigh7N
 EQEL2UVX4MzID7ZLASb9TnGV1Wf.GOk1pRvY07ccxmA0zNwvUQ4nUPe333dR8PbQD9u3.eYOWVHZ
 gKgSoBIDX1cvUYQfzCDWmGQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Apr 2022 23:37:52 +0000
Received: by kubenode534.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20c8bf4effeb2ab6890164d11804a978;
          Wed, 06 Apr 2022 23:37: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 14.0 \(3654.120.0.1.13\))
Subject: Re: https://github.com/pftf/RPi3 UEFI/ACPI based booting:
 gic_acpi_identify crashes dereferencing a NULL pointer value
From: Mark Millard 
In-Reply-To: <6609AB07-942C-4E06-A99A-2B3A0D65D970@yahoo.com>
Date: Wed, 6 Apr 2022 16:37:45 -0700
Cc: Andrew Turner 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6609AB07-942C-4E06-A99A-2B3A0D65D970@yahoo.com>
To: Free BSD ,
 "freebsd-acpi@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KYgtH4Ym7z3slw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qz8xxlsF;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.33 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.83)[-0.831];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5318
Lines: 167



On 2022-Apr-6, at 01:01, Mark Millard  wrote:

> https://github.com/pftf/RPi3 UEFI/ACPI use gets a boot crash in
> FreeBSD's gic_acpi_identify:
>=20
> . . .
> MAP 1d0000 mode 2 pages 32
> MAP 339d0000 mode 2 pages 80
> MAP 33a20000 mode 2 pages 256
> MAP 37000000 mode 2 pages 400
> MAP 37190000 mode 2 pages 592
> kbd0 at kbdmux0
> acpi0: 
> acpi0: Power Button (fixed)
> acpi0: Could not update all GPEs: AE_NOT_CONFIGURED
> psci0:  on acpi0
> Fatal data abort:
>  x0: ffff000086ffe6b4 (crypto_dev + 858f044c)
>  x1: ffff00000103d0d0 (initstack + 30d0)
>  x2: ffff00000080ed2c (madt_handler + 0)
>  x3: ffff00000103d0d0 (initstack + 30d0)
>  x4:         d2d9fffc
>  x5:                0
>  x6: ffffffffffffffff
>  x7:             2001
>  x8:                0
>  x9:              400
> x10:              800
> x11:                0
> x12: ffff00000103d8dc (initstack + 38dc)
> x13:               b6
> x14:              551
> x15:              16c
> x16:                0
> x17:                1
> x18: ffff00000103d0d0 (initstack + 30d0)
> x19: ffff000086ffe598 (crypto_dev + 858f0330)
> x20: ffffa00000dba200
> x21: ffff00000103d0e0 (initstack + 30e0)
> x22: ffffa00000c37a40
> x23: ffff000000ec8000 (devsoftc + 88)
> x24: ffff00000097fe1a (digits + 102f6)
> x25:          3800000
> x26: ffff000000e74000 (gdb_tx_u + a98)
> x27: ffff000000e74000 (gdb_tx_u + a98)
> x28: ffff00004042bd28 (crypto_dev + 3ed1dac0)
> x29: ffff00000103d8e0 (initstack + 38e0)
>  sp: ffff00000103d0d0
>  lr: ffff00000080e908 (gic_acpi_identify + 7c)
> elr: ffff00000080e90c (gic_acpi_identify + 80)
> spsr:         600000c5
> far:               14
> esr:         96000004
> panic: vm_fault failed: ffff00000080e90c error 1
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x178
> panic() at panic+0x44
> data_abort() at data_abort+0x2bc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> gic_acpi_identify() at gic_acpi_identify+0x80
> bus_generic_new_pass() at bus_generic_new_pass+0x44
> bus_generic_new_pass() at bus_generic_new_pass+0xb0
> bus_generic_new_pass() at bus_generic_new_pass+0xb0
> root_bus_configure() at root_bus_configure+0x40
> mi_startup() at mi_startup+0x224
> virtdone() at virtdone+0x7c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x48: undefined       f901c11f
>=20
> This turns out to have gic_acpi_identify+0x80
> with the code shown below:
>=20
> ffff00000080e904  bl    ffff00000011d640 =

> ffff00000080e908  ldr   x8, [sp, #8]
> ffff00000080e90c  ldrb  w8, [x8, #20]
>=20
> and the register dump above shows:
>=20
>  x8:                0
>=20
> Looking up the source ( sys/arm/arm/gic_acpi.c ) there is
> the likes of:
>=20
> struct madt_table_data {
>        device_t parent;
>        ACPI_MADT_GENERIC_DISTRIBUTOR *dist;
>        ACPI_MADT_GENERIC_INTERRUPT *intr[MAXCPU];
> };
> . . .
>        bzero(&madt_data, sizeof(madt_data));
>        madt_data.parent =3D parent;
>        madt_data.dist =3D NULL;
>=20
>        acpi_walk_subtables(madt + 1, (char *)madt + =
madt->Header.Length,
>            madt_handler, &madt_data);
>=20
>        /* Check the version of the GIC we have */
>        switch (madt_data.dist->Version) {
>=20
> So it appears that madt_data.dist held a NULL pointer value
> that was not checked for. (I've no clue if such a NULL is
> supposed to be possible --but I do know it occured.)
>=20
> The following lines are:
>=20
>        case ACPI_MADT_GIC_VERSION_NONE:
>        case ACPI_MADT_GIC_VERSION_V1:
>        case ACPI_MADT_GIC_VERSION_V2:
>                break;
>        default:
>                goto out;
>        }
> . . .
> out:
>        acpi_unmap_table(madt);
> }
>=20
> That might suggest that madt_data.dist=3D=3DNULL should lead to
> a "goto out".
>=20
>=20

QUOTE ( https://en.wikipedia.org/wiki/Raspberry_Pi )
The Raspberry Pi 4 uses a Broadcom BCM2711 SoC . . . Unlike previous =
models, which all used a custom interrupt controller poorly suited for =
virtualisation, the interrupt controller on this SoC is compatible with =
the ARM Generic Interrupt Controller (GIC) architecture 2.0, providing =
hardware support for interrupt distribution when using ARM =
virtualisation capabilities.
END QUOTE

So it looks like the madt_data.dist=3D=3DNULL corresponds to
there not being a GIC of any version present to find in
MADT for an RPi3.

I'll note that the value ACPI_MADT_GIC_VERSION_NONE is listed in
ACPI_Spec_6_4_Jan22.pdf as:

QUOTE
0x00: No GIC version is specified, fall back to hardware discovery for =
GIC version
END QUOTE

I'd take that wording as still presuming the presence of a GIC
to do version discovery with. If true, the madt_data.dist=3D=3DNULL
for the RPi3B may well be the way to indicate that no GIC is
present to even do hardware version discovery with.


FreeBSD may well not want to support https://github.com/pftf/RPi3
use in ACPI mode. But it still may want to avoid a non-obvious
crash as the means of rejecting the ACPI it is provided.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Apr  7 04:08:10 2022
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 0023B1A8076A
	for ; Thu,  7 Apr 2022 04:08:20 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KYntC0j7yz4VGj
	for ; Thu,  7 Apr 2022 04:08:18 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 23748A7Q029301
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Wed, 6 Apr 2022 21:08:10 -0700 (PDT)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 23748Ahb029300
	for freebsd-arm@FreeBSD.org; Wed, 6 Apr 2022 21:08:10 -0700 (PDT)
	(envelope-from jmg)
Date: Wed, 6 Apr 2022 21:08:10 -0700
From: John-Mark Gurney 
To: freebsd-arm@FreeBSD.org
Subject: Rock64 eMMC not working
Message-ID: <20220407040810.GD88842@funkthat.com>
Mail-Followup-To: freebsd-arm@FreeBSD.org
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-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 06 Apr 2022 21:08:10 -0700 (PDT)
X-Rspamd-Queue-Id: 4KYntC0j7yz4VGj
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com
X-Spamd-Result: default: False [-1.13 / 15.00];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US];
	 FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.995];
	 FREEFALL_USER(0.00)[jmg];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-0.34)[-0.335];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[funkthat.com];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 16554
Lines: 389

Hello,

I am trying to get the latest FreeBSD -current snapshot to boot/run off
a Pine64 eMMC module on the Rock64, but I'm seeing an issue w/ mounting
root:

FreeBSD 14.0-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 UTC 2022
[...]
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
mmcsd0: Error indicated: 4 Failed

I got similar messages when 13.1-RC1:

mmcsd0: 16GB  at mmc0 150.0MHz/8bit/1016-block
mmcsd0boot0: 4MB partition 1 at mmcsd0
mmcsd0boot1: 4MB partition 2 at mmcsd0
mmcsd0rpmb: 4MB partition 3 at mmcsd0
[...]
GEOM: mmcsd0: the secondary GPT header is not in the last LBA.
mmcsd0: Error indicated: 4 Failed
rockchip_dwmmc1: Failed to update clk


Are there any known issues w/ this?  A different image to try?

Also, in trying to debug this issue, I tried to boot from a microSD
card with the eMMC module installed by shorting the jumper, but when I did,
I got:
mmcsd0: 32GB  at mmc0 50.0MHz/4bit/1016-block
mmcsd1: Error reading EXT_CSD Failed
device_attach: mmcsd1 attach returned 6
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex rockchip_dwmmc1 (dwmmc) r = 0 (0xffffa000008d2128) locked @ /usr/src/sys/dev/mmc/host/dwmmc.c:386
stack backtrace:
#0 0xffff0000004e5390 at witness_debugger+0x5c
#1 0xffff0000004e6564 at witness_warn+0x3e8
#2 0xffff00000078962c at data_abort+0xa0
#3 0xffff000000767810 at handle_el1h_sync+0x10
  x0:             8088
  x1: ffff00008e18b000 (ucom_cons_softc + 8ce4ca40)
  x2:               40
  x3:              182
  x4:                0
  x5: ffff00008e1767a0 (ucom_cons_softc + 8ce381e0)
  x6:                0
  x7:                0
  x8:                4
  x9: ffff000000b55910 (memmap_bus + 0)
 x10:                3
 x11:            10000
 x12:                1
 x13:             2af8
 x14:               88
 x15:             2af8
 x16:               88
 x17:                0
 x18: ffff00008e176850 (ucom_cons_softc + 8ce38290)
 x19: ffffa000008d2140
 x20: ffffa000008d2000
 x21:             8088
 x22:                0
 x23:         80000003
 x24: ffffa000008c9580
 x25: ffffa00000bb9100
 x26: ffff000000b9ea98 (Giant + 18)
 x27: ffff0000008df336 (digits + ea96)
 x28: ffffa00000bb9110
 x29: ffff00008e176850 (ucom_cons_softc + 8ce38290)
  sp: ffff00008e176850
  lr: ffff0000007b0298 (dwmmc_intr + 50)
 elr: ffff0000007b02c4 (dwmmc_intr + 7c)
spsr:               45
 far:               20
 esr:         96000044
panic: data abort in critical section or under mutex
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2dc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000044
dwmmc_intr() at dwmmc_intr+0x7c
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic


Complete boot message:
======================
U-Boot TPL 2021.07 (Mar 31 2022 - 05:26:18)
LPDDR3, 800MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2021.07 (Mar 31 2022 - 05:26:18 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC2
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 05:24:37, Mar 31 2022
NOTICE:  BL31:Rockchip release version: v1.2


U-Boot 2021.07 (Mar 31 2022 - 05:28:19 +0000)

Model: Pine64 Rock64
DRAM:  2 GiB
PMIC:  RK8050 (on=0x40, off=0x00)
MMC:   mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
50618 bytes read in 7 ms (6.9 MiB/s)
Card did not respond to voltage select! : -110
Scanning disk mmc@ff500000.blk...
Disk mmc@ff500000.blk not ready
Scanning disk mmc@ff520000.blk...
** Unrecognized filesystem type **
** Unrecognized filesystem type **
** Unrecognized filesystem type **
Found 5 disks
** Unable to read file ubootefi.var **
Failed to load EFI variables
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
1263868 bytes read in 33 ms (36.5 MiB/s)
Booting /efi\boot\bootaa64.efi


Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/arm64 EFI loader, Revision 1.1
(Thu Mar 31 08:48:02 UTC 2022 root@releng1.nyi.freebsd.org)

   Command line arguments: loader.efi
   Image base: 0x7cdde000
   EFI version: 2.80
   EFI Firmware: Das U-Boot (rev 8225.1792)
   Console: efi (0x1000)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(2,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x21000,0x1cc6fd8)
Setting currdev to disk0p2:
/


Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
/

Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x84f4a0 text=0x249adc data=0x1b9aa8 data=0x0+0x40d000 0x8+0x133de8+0x8+0x15b370\
Loading configured modules...
/boot/entropy size=0x1000
/boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6d8+0x10 0x8+0xf18+0x8+0xb5c
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x2590 text=0x2f00 data=0x8e0+0x858 0x8+0x1290+0x8+0xbd5
/etc/hostid size=0x25

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x80f0000.
EFI framebuffer information:
addr, size     0x0, 0x0
dimensions     0 x 0
stride         0
masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
---<>---
GDB: debug ports: uart
GDB: current port: uart
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
Copyright (c) 1992-2022 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-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 UTC 2022
    root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
module firmware already present!
real memory  = 2145136640 (2045 MB)
avail memory = 2065342464 (1969 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
MAP 7cf1b000 mode 2 pages 1
MAP 7cf1f000 mode 2 pages 3
MAP 7cf23000 mode 2 pages 4
MAP 7ff40000 mode 2 pages 16
kbd0 at kbdmux0
ofwbus0: 
clk_fixed0:  on ofwbus0
rk_grf0:  mem 0xff100000-0xff100fff on ofwbus0
rk3328_cru0:  mem 0xff440000-0xff440fff on ofwbus0
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
Cannot set frequency for clk: aclk_bus_pre_c, error: 34
rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
Cannot set frequency for clk: aclk_peri_pre, error: 34
rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clk_fixed1:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
regfix3:  on ofwbus0
simple_mfd0:  mem 0xff450000-0xff45ffff on ofwbus0
psci0:  on ofwbus0
gic0:  mem 0xff811000-0xff811fff,0xff812000-0xff813fff,0xff814000-0xff815fff,0xff816000-0xff817fff irq 52 on ofwbus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 160
rk_pinctrl0:  on ofwbus0
gpio0:  mem 0xff210000-0xff2100ff irq 53 on rk_pinctrl0
gpiobus0:  on gpio0
gpio1:  mem 0xff220000-0xff2200ff irq 54 on rk_pinctrl0
gpiobus1:  on gpio1
gpio2:  mem 0xff230000-0xff2300ff irq 55 on rk_pinctrl0
gpiobus2:  on gpio2
gpio3:  mem 0xff240000-0xff2400ff irq 56 on rk_pinctrl0
gpiobus3:  on gpio3
rk_i2c0:  mem 0xff160000-0xff160fff irq 16 on ofwbus0
iicbus0:  on rk_i2c0
rk805_pmu0:  at addr 0x30 irq 57 on iicbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
rk_tsadc0:  mem 0xff250000-0xff2500ff irq 24 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
cpufreq_dt0:  on cpu0
cpufreq_dt0: Found cpu-supply
cpu1:  on cpulist0
cpufreq_dt1:  on cpu1
cpufreq_dt1: Found cpu-supply
cpu2:  on cpulist0
cpufreq_dt2:  on cpu2
cpufreq_dt2: Found cpu-supply
cpu3:  on cpulist0
cpufreq_dt3:  on cpu3
cpufreq_dt3: Found cpu-supply
pcm0:  on ofwbus0
pmu0:  irq 0,1,2,3 on ofwbus0
pcm1:  on ofwbus0
i2s0:  mem 0xff000000-0xff000fff irq 8 on ofwbus0
Cannot set frequency for clk: xin12m, error: 34
Cannot set frequency for clk: xin12m, error: 34
i2s1:  mem 0xff010000-0xff010fff irq 9 on ofwbus0
Cannot set frequency for clk: clkin_i2s1, error: 34
Cannot set frequency for clk: xin12m, error: 34
uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on ofwbus0
uart0: console (1500000,n,8,1)
iic0:  on iicbus0
spi0:  mem 0xff190000-0xff190fff irq 19 on ofwbus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
rockchip_dwmmc0:  mem 0xff500000-0xff503fff irq 43 on ofwbus0
rockchip_dwmmc0: Hardware version ID is 270a
rockchip_dwmmc1:  mem 0xff520000-0xff523fff irq 45 on ofwbus0
rockchip_dwmmc1: Hardware version ID is 270a
mmc0:  on rockchip_dwmmc1
dwc0:  mem 0xff540000-0xff54ffff irq 46 on ofwbus0
miibus0:  on dwc0
rgephy0:  PHY 0 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
rgephy1:  PHY 1 on miibus0
rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
dwc0: Ethernet address: xxx
dwcotg0:  mem 0xff580000-0xff5bffff irq 48 on ofwbus0
usbus1 on dwcotg0
ehci0:  mem 0xff5c0000-0xff5cffff irq 49 on ofwbus0
usbus2: EHCI version 1.0
usbus2 on ehci0
ohci0:  mem 0xff5d0000-0xff5dffff irq 50 on ofwbus0
usbus3 on ohci0
gpioc0:  on gpio0
gpioc1:  on gpio1
gpioc2:  on gpio2
gpioc3:  on gpio3
gpioled0:  on ofwbus0
gpioled0:  failed to map pin
gpioled0:  failed to map pin
pcm2:  on ofwbus0
armv8crypto0: 
Timecounters tick every 1.000 msec
usbus1: 480Mbps High Speed USB v2.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s
pcm0: no driver attached to codec node
pcm1: no driver attached to codec node
ugen2.1:  at usbus2
uhub0 on usbus2
uhub0:  on usbus2
ugen1.1:  at usbus1
uhub1 on usbus1
uhub1:  on usbus1
ugen3.1:  at usbus3
uhub2 on usbus3
uhub2:  on usbus3
mmcsd0: 16GB  at mmc0 150.0MHz/8bit/1016-block
mmcsd0boot0: 4MB partition 1 at mmcsd0
mmcsd0boot1: 4MB partition 2 at mmcsd0
mmcsd0rpmb: 4MB partition 3 at mmcsd0
pcm2: no driver attached to cpu node
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
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
WARNING: WITNESS option enabled, expect reduced performance.
Unresolved linked clock found: hdmi_phy
Unresolved linked clock found: usb480m_phy
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
mmcsd0: Error indicated: 4 Failed
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From nobody Fri Apr  8 23:08:53 2022
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 404AB1A8FDF5
	for ; Fri,  8 Apr 2022 23:09:01 +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 4KZv7v4dtHz3LqW
	for ; Fri,  8 Apr 2022 23:08:59 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 238N8sKi051726
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Apr 2022 16:08:54 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 238N8r7Z051725;
	Fri, 8 Apr 2022 16:08:53 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 8 Apr 2022 16:08:53 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Rpi3 panic, data abort with spinlock held on -current
Message-ID: <20220408230853.GA51713@www.zefox.net>
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-Rspamd-Queue-Id: 4KZv7v4dtHz3LqW
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [1.17 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.91)[-0.909];
	 NEURAL_SPAM_SHORT(0.03)[0.031];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(0.15)[0.147];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 618
Lines: 21

Here's an example of a crash on an RPI3 running -current that was
updated the morning of April 8th. The build command was
make -j3 -DWITH_META_MODE > buildworld.log

The panic started with 
 panic: data abort with spinlock held

The crashing kernel reports
FreeBSD 14.0-CURRENT #36 main-n254371-fb8c87b4f3b: Tue Apr  5 22:20:39 PDT 2022

The machine uses a USB mechanical hard drive for root, with 3547 MB of swap.
Only about 10% of swap was in use when it crashed.

The console output, final top window and buildworld log are at
http://www.zefox.net/~fbsd/rpi3/crashes/20220408/

Thanks for reading,

bob prohaska

 

From nobody Sat Apr  9 00:15:48 2022
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 AD9451AA896B
	for ; Sat,  9 Apr 2022 00:16:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KZwdG3vcDz3lpV
	for ; Sat,  9 Apr 2022 00:16:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649463355; bh=iQ8HUouuDo5nUTFdZ1DcVhyB/dlPXfDH4VMhy16/ahc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HjnvaaJlHnruGlSYPYtTaLorGT+UrHvN+QYGjLxjgDhNJVyiBTVjY4HmSXhO1Zpx0BHhvFSoFULJMVXyDhRwKRHcEbY+pOHOsREwQBl5H9PCsJHJGbnt/4AVs9HtH9z2X05QI6LbSDbTSzT2gkRYoUbiMqYGejQuZkul8HQssop26KYpf9FnyUUWf7/dIh2VRJ4SbKk1dua/Cn83fyCTfcrTd6zHwiHPaBAUKMGzJWcfd3KwCZvXqomRYGSoOfv2R2XOeOW1Rm+7HU4EnAyfZLmDoGdrD09Kz83GgWEychj0GbF8oUNhYSffDFvCB9PuRJ1LCtHEvpVRH5AiqxreLA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649463355; bh=6L/jtN0k/QJhAGse2O7Vbdfehwwl6rXjcK3eonz46hz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nB2879SCb6otItBMK0gF3zPok4GJislx2qHO6PvZJJ+lE4cXe690tZ0XJoGD4xXGoCQpM9MQCufrvLBR0r2R6wc5eLKNXSRyI68oFTH6P4U9S1P13tB+3rxA9nnVqpTWAjwKylDH3jqLnG13GyflsxV2FC35BvNQ5/j+K+ixkub0Y0uFwa07xltuCXxTOHQbn4L3OLg1djY1dTPICVcNMcznGaydH0BuBZezxvMhez+jruFUrSv7MAIMcQ7bDxXoe1w1fOJynWEd/X64Dhlx2YUNo4eYXDLlQOsxPcwG5t4waX5XqAFcsnRdnqL8DLZ72UynWbGoJHe0G/Xtx4l3Pw==
X-YMail-OSG: r6Pd_sIVM1m_9eE968iRRyrlzl6POOCBYoXD6DMfdzyDmKmr4sSehT6ve6o1CiX
 Y.tTyZCP32uC.RgG2rAqSYQzHZIenYE3dNX4cfhNJA_cjN6HDYVlKPYkLhubNUiI1P1_XlOe3CNx
 wDO.gaZwSsjpfW7lIuPWRw9tDomJ87wHldJYX7HRxj_JJ6pU3.aOPKJHT.SNQVKjVpZv09B1U4YJ
 iUZCsUZruIFv9BTnjhMmZHNW7YFYpTZVVjqVmgLL50pshrZHdl8exZ5YMayjuU5a09FGW7_NijLQ
 9FlKJoNIVNnZzxb.d4kITVe222l43RMVm6LsH.3Iac6kBqlqcHb5OxQqFmlQE9MG8HRxqJkpAfkt
 vUcj0bNJf9ia708w6DaIuihtbyCBYpoV_WMgtvQsBZqFQszlO.5E4.br7SeAMwPj1D6OsSF5n2kL
 GbkbWcGN1mn9WXhLqkbfyFwQbGI7.jEoKVN3VgiT3Jtx8E8WV2YGkpdsYyoyCnviCfoyWmOaUSLy
 UGqWc9meXUB2EwiHTSC_CPEyPc8g24CR2basR_qU3V8VJlMSLQDtll1RpVGf15JhpxOcwVueg1d.
 GH6A5q2qVLV11tTjOZn6teD1NrzKN5XGiEH4nAAkFkHQffVlpavYQn9nhpseqwv2SV9KVuWdKPPT
 54kfwkJTeEEb3XO9Msbzk3oMHzqLwdR85DIZUOk5umQtQmavVcs4HTZAaxvYvr4eU5y7S1q.GNea
 0LjSZkrHaUElaHq9egz5K0A1yO9HnhiZlrA_E01gIQCscRW9U78mAO63Um3g0SNmweNcxg2gxBXm
 j1cC9fCF5djwUM1Roj3hS49ZKwxjxX8i7rJC9bMaYuezIwEPIAjKFc7oW2ShIJL3b5tJJtZlJBzd
 GKyGQCxyl_xizEjntRIzevfJ12yVBhd51McMBw9CNNhb3u1iHs_8kP.R9.Oi8bhgfZJNE7ZC_17h
 haQp.G3gn81rdL_auF7L2bGk7MXv2SgWC_7Ljy83yFNmoAzBnvloBDUR7YafMdm9MuRMEQKoKpnH
 4umFQ5cNh6NrSU_0nP_F3X6_EBwE3SnFSYwb6zs0kO2FobVYKv4YMcJ.Cy6nWHO78Nq7i8385Iu.
 OCcfmyx4oij6kXRp5pt5SozGrHvj9nOZDM_jki5Iik_f1HRbw6edzQ6howlWaAX6CMnziZkIcI.F
 jeJkZhDZGWLn1TleVQ7hAZv8QDwchX0Mk79INRVHvFm1d5pRCPQevjOKyESsdXrlIQjNpCSQV.Ra
 v4jH8DDG7.TddWsA0ESp94zDJYOaXu.5oD1GGaz_Ffar8UGwHR2nVTcYBMdmrZmsLaJ6gfTM_0M_
 C4whky2eG38vw4glX.5mpz_obiO2jNiUcoAUjM8QJxaOXGBMg.NqMDUcGtGzmQ4Hj2eBU3MdkqT2
 MWnvgyNj5fnC5ugGwH2x6LyuDohxLDNiyZc4JMm4xLXPgPkCLyieNT8IOS_PA5HO25iS2.vCNSiq
 YJrgQU6fq65DorRTLuz8lZiCtkTUkLRk1cYGtm0ubpJL7k5eTTTaBj4PoCcVdbKArb6ldWJwd_HM
 YtPpqVMgDT2VM5KNuyrReBDHkree0JPS8RIvx.uMia7hTDUcThVqt8yNym0irSdfkhF3.O7wGeLp
 03tjXnNnj.gIHvo6rcY4Mbpf0jt2SSmBd.H36jY9yRHsgf2fRdAlKnNEyTTsFDYu4XTxER_LpAbk
 mh0RKpxUZBaD2SHZkKeNzOk6o.Na96Xw6KpZmiZn6s0pAh6ill2SeWMPh42OagUc.b981s4tsgP8
 oo2oEnW7yTUInvIl2aPe6U0LG0PAF_JnAEpzC2AJrNxTYFSOdLYIwVNy1oSNUoQqFlQy2kudsTox
 mYxbC.6eAvll5CgkAObxmoKpc9DRuWQ8VmnqSPqgGkvtaMWmFVRS.W21.rvzQC_Lrh5.lt541tAm
 V0GaIuO2B4Yck.dxvYHpFlYsj9VXzM0colWm0eHQ1OY1TmfzRT0GRVRoh1tOHJ4wxikejoucDQl2
 Y6eJo04t8K8r8RxjPfUbeT4AcJd0GkmnuL1ir.AfcQI9x9ybzyeTSV76ZM5e2y2si.Dvx984qZxA
 9YSSw8QudgwySrl1QH.WKfXvMwn2WrZVc1V5Q9lwjRFNO7qtQOqQINwCtlf7lqpZ2Wiqdus6bLY6
 2nQEB6Tm4rOywK.5hepsst9hB_FasJ6m0uCYq6Hjq6of7MECRqNHVv.VcOk782opiYNOigmWOwER
 ydD2tEicQVW99.yoYwdmUb9JS.PUTJ7lrlvO1RitP5JowRct2Q37G_076BQGLaDkf5RpfhrvV._4
 5KEmL.NnUTJMtMFQ-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 00:15:55 +0000
Received: by kubenode506.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 967dbbe0c646b3c989fd26689f75e939;
          Sat, 09 Apr 2022 00:15:50 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Rpi3 panic, data abort with spinlock held on -current
From: Mark Millard 
In-Reply-To: <20220408230853.GA51713@www.zefox.net>
Date: Fri, 8 Apr 2022 17:15:48 -0700
Cc: bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
References: <20220408230853.GA51713@www.zefox.net>
To: Free BSD 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KZwdG3vcDz3lpV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=HjnvaaJl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2765
Lines: 82

On 2022-Apr-8, at 16:08, bob prohaska  wrote:

> Here's an example of a crash on an RPI3 running -current that was
> updated the morning of April 8th. The build command was
> make -j3 -DWITH_META_MODE > buildworld.log
>=20
> The panic started with=20
> panic: data abort with spinlock held
>=20
> The crashing kernel reports
> FreeBSD 14.0-CURRENT #36 main-n254371-fb8c87b4f3b: Tue Apr  5 22:20:39 =
PDT 2022
>=20
> The machine uses a USB mechanical hard drive for root, with 3547 MB of =
swap.
> Only about 10% of swap was in use when it crashed.
>=20
> The console output, final top window and buildworld log are at
> http://www.zefox.net/~fbsd/rpi3/crashes/20220408/

I'm just including the backtrace so it is visible on the
list without having to go exploring. It might help folks
decide if they want to do that exploring or are otherwise
interested.

General nested structure (bottom to top
of the backtrace below):

interrupt leads to exception,
then interrupt, which leads to exception,
which leads to panic.

The backtrace:

login: panic: data abort with spinlock held
cpuid =3D 0
time =3D 1649444088
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2a8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000007
generic_bs_rr_4() at generic_bs_rr_4+0xc
dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
intr_event_handle() at intr_event_handle+0xf0
intr_isrc_dispatch() at intr_isrc_dispatch+0x74
bcm2835_intc_intr() at bcm2835_intc_intr+0xa4
intr_event_handle() at intr_event_handle+0xf0
intr_isrc_dispatch() at intr_isrc_dispatch+0x74
bcm_lintc_intr() at bcm_lintc_intr+0x1d8
intr_irq_handler() at intr_irq_handler+0x80
handle_el1h_irq() at handle_el1h_irq+0xc
--- interrupt
data_abort() at data_abort+0x14c
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000006
dwc_otg_host_data_rx() at dwc_otg_host_data_rx+0x260
dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
intr_event_handle() at intr_event_handle+0xf0
intr_isrc_dispatch() at intr_isrc_dispatch+0x74
bcm2835_intc_intr() at bcm2835_intc_intr+0xa4
intr_event_handle() at intr_event_handle+0xf0
intr_isrc_dispatch() at intr_isrc_dispatch+0x74
bcm_lintc_intr() at bcm_lintc_intr+0x1d8
intr_irq_handler() at intr_irq_handler+0x80
handle_el0_irq() at handle_el0_irq+0x38
--- interrupt
KDB: enter: panic
[ thread pid 83684 tid 100210 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 01:53:21 2022
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 4C8AF1A9255C
	for ; Sat,  9 Apr 2022 01:53:22 +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 4KZynX75T7z4qng
	for ; Sat,  9 Apr 2022 01:53:20 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2391rLN1052063
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Apr 2022 18:53:21 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2391rLCa052062;
	Fri, 8 Apr 2022 18:53:21 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 8 Apr 2022 18:53:21 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: RPI4 panic on boot with -current
Message-ID: <20220409015321.GA52002@www.zefox.net>
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-Rspamd-Queue-Id: 4KZynX75T7z4qng
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8197
Lines: 223

Might this be related to "RPi4B's got a PMIC replacement,..." reported 4/3 ?

A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build of 
-current reports:

Resetting system ... 

U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)

DRAM:  7.9 GiB
RPI 4 Model B (0xd03114)
MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
sdhci_send_command: MMC: 1 busy timeout.
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_send_command: MMC: 1 busy timeout.

Device 0: Vendor: SABRENT  Rev: 0204 Prod: 
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_set_clock: Timeout to wait cmd & data inhibit
sdhci_send_command: MMC: 1 busy timeout.
Scanning disk mmc@7e300000.blk...
Disk mmc@7e300000.blk not ready
Card did not respond to voltage select!
Scanning disk emmc2@7e340000.blk...
Disk emmc2@7e340000.blk not ready
Scanning disk usb_mass_storage.lun0...
** Unrecognized filesystem type **
Found 3 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
1259292 bytes read in 5 ms (240.2 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootaa64.efi

[whitespace trimmed]

Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/arm64 EFI loader, Revision 1.1
(Thu Mar  4 07:32:03 UTC 2021 root@releng1.nyi.freebsd.org)

   Command line arguments: loader.efi
   Image base: 0x39cfc000
   EFI version: 2.80
   EFI Firmware: Das U-Boot (rev 8224.4096)
   Console: comconsole (0)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x746ed5e9)
Setting currdev to disk0p2:
/
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x851220 text=0x24be84 data=0x1b9ba8 data=0x0+0x34f000 syms=[0x8+0x134028+0x8+0x15b5e1]
Loading configured modules...
/boot/kernel/filemon.ko text=0x1867 text=0x2558 data=0x510+0x20 syms=[0x8+0xd08+0x8+0x7c9]
/boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6d8+0x10 syms=[0x8+0xf18+0x8+0xb5c]
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x2590 text=0x2f00 data=0x8e0+0x858 syms=[0x8+0x1290+0x8+0xbd5]
/boot/entropy size=0x1000
/etc/hostid size=0x25

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x7ef0000.
EFI framebuffer information:
addr, size     0x3e22c000, 0x8ca000
dimensions     1920 x 1200
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
---<>---
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 compliance
Copyright (c) 1992-2022 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-CURRENT #40 main-aa597d4049-dirty: Fri Apr  8 11:44:42 PDT 2022
    bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1920x1200
module firmware already present!
real memory  = 8441835520 (8050 MB)
avail memory = 8206352384 (7826 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
Fatal data abort:
  x0: ffffa0003b25dad0
  x1:                8
  x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
  x3:              78a
  x4:                0
  x5:               69
  x6:         40a7152f
  x7:         f2db3c10
  x8: ffffa0003b25dad0
  x9:        200000000
 x10: ffffa00000000000
 x11:         3b25dad0
 x12: 725f696665006966
 x13:  100000102ff0001
 x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
 x15:                0
 x16:                8
 x17:         f4b3707d
 x18: ffff000000fa79b0 (initstack + 39b0)
 x19: ffffa000008db380
 x20: ffff000000ab4810 (efirt_moddata + 0)
 x21: ffff000000911163 (console_pausestr + 13a59)
 x22: ffff000000c6d000 (db_watch_table + b88)
 x23: ffff000000ba1000 (compiler_version + 20)
 x24: ffff000000dfb000 (gdb_tx_u + aa0)
 x25:                0
 x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
 x27:          3100000
 x28: ffff000000dfb000 (gdb_tx_u + aa0)
 x29: ffff000000fa79c0 (initstack + 39c0)
  sp: ffff000000fa79b0
  lr: ffff000000157ac4 (efirt_modevents + 78)
 elr: ffff000000157ad0 (efirt_modevents + 84)
spsr:         200000c5
 far: ffffa0003b25dad0
 esr:         96000007
panic: vm_fault failed: ffff000000157ad0 error 1
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2f0
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000007
efirt_modevents() at efirt_modevents+0x84
module_register_init() at module_register_init+0xc4
mi_startup() at mi_startup+0x130
virtdone() at virtdone+0x7c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db> bt
Tracing pid 0 tid 100000 td 0xffff000000dfc0e0
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x11c
db_command() at db_command+0x368
db_command_loop() at db_command_loop+0x54
db_trap() at db_trap+0xf8
kdb_trap() at kdb_trap+0x1cc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0xf2000000
kdb_enter() at kdb_enter+0x44
vpanic() at vpanic+0x1b0
panic() at panic+0x44
data_abort() at data_abort+0x2f0
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000007
efirt_modevents() at efirt_modevents+0x84
module_register_init() at module_register_init+0xc4
mi_startup() at mi_startup+0x130
virtdone() at virtdone+0x7c
db> 

followed by

db> reboot
cpu_reset failed

After power cycle the machine rebooted to
FreeBSD 14.0-CURRENT #34 main-79c4c4be96-dirty: Tue Apr  5 09:26:19 PDT 2022
without obvious problems. "Dirty" is in reference to /usr/src/tests, I've
refrained from tampering with the sources.

Thanks for reading, 

bob prohaska
 

From nobody Sat Apr  9 02:46:57 2022
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 BEB211A87740
	for ; Sat,  9 Apr 2022 02:47:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KZzzZ2Xqgz3DxV
	for ; Sat,  9 Apr 2022 02:47:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649472419; bh=3u4IVfUs9PYxut25tqMYCBWFP3trprhlTeM51v2gKrg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=quspTgObEoqLYcYVQjOD/Mm1R4TLHLDi8LQaOLSUWu2GbKtzPw1K0shK2GvBHazUiEjXxXkJ62QU0VXsfEwudGtjL2YzIlOmUAqxgmAubl8yus+nAs7Uv0LN+rbuP398NbMgWIt6QUMXQt0bdI6PRv4KOZfCXpQBFTFPsWZZj5O4zxPVM3Qc39wmF6F4XX3RLAd+I3xVlqOosXcbYlYc1iuMn7sePcXcG1fm7snqL6XBA4hKOvmVvOLbGVOHkCalVDZN8HOcig3g0mh4dIuG28w+cQ3tIGETjOaEaC44DUnDSa7YBBqR6RQVHZEC/TXa9FnhdoE6BMnv8OK5BfeTZQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649472419; bh=oHB5gal4WIZEnUq7JHUvYKvwML6/DznGASca4dRWgm1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G0gYP50QhbDrx5ZJWGf8qGYNkK0K/6dInbv/61rhj3SQbcn6Z7L5EemXjMhv3lZZ+3ua89srwyuK+qkRgawURUc2q17b2in9+r9WaVjJaeZba/oz8d6BwkOXM2P91vWpfpzRFkGDg4SdtCoVviTXT0xpHasX0hG96aIeRI+gQ6a0P4RUn6qY3j9+TYPyxqSE6O7kbV9GK4GRQbJ4Pk0rT1EUrOBQ9VSUik/+F2sEwhlkDz8uWXx9rX3k/0GHXPYJIpEiMmuJEzeDbROkQlKJ9hudsS0ePsbLO5rngcRyo5Wq25U77m4T3mHeyqd0bJJY40h+l+LjOwv5seEBUK7ilw==
X-YMail-OSG: DxMGfaoVM1mNaUS_O4syOD8xaZ_aLORNtRxUGAxo4mdjInH0QoPeedVMlDU1WSN
 wV7Gqc5ivCsCstfYdhOCxWxxcbZq_4AZBqlWhcvP_MdBmhuMl_YbxxorEO10x__NfWgZ4du.u2yk
 DbhC_oE9h4U6iGGQEMCs7P2dCnPZOBl9cPytQupgSzWG7ceM.EfVayTnW7Pm2dfUy3ZalbRATbzz
 Z4iW6EcGHzvDx_QBcFYy8xROn6v.JXPw4TWzPqaJkrbo2cdvPU8OForlOS2KinP_dXiXBVnmuygd
 2h5sXwkyj5vfZrc2PlIl2ZUxNjB6dYm3Kxa2SqL2E5zJsRDwOuObqa8TWs_i_vGJ6dFDQILwgT36
 lgjp25DtTnTvW02Jupsif37aSdrlGg45JkHcP7ya7aiMT0wRu1hqg6rIXqM3M6VkwF.0IjHRb36F
 Yc2.a2pwLO2kuKvPv5cRkcxKHp9N8Qml_MGtQlq2x2.ytAh6OPIpGNhGN8_eCiT85xWIPAblg2TM
 1l24BWSCzmwU3nfC9wv8.Im9LbadKmr94z91uXS7.CrfG3uSg2VwhneWDc.NfjROWcubjWxZnBl6
 FljtHberYpKzYu6rpDLE8QwRMARWeWg7GVVkUIkhNSbcUDfOSGb2U_2..6ZRfLu5RP4OfdQMK5vx
 zZ1WUoyFmcWYvvPEHZimib819tBCejMGmV5uH5JfHKmX.WfsV5so6gOxAHfJvK21Mbo3UP7fw7yp
 v.fuuFRILmkcYpVH7JrBPZaS2lklQggyFgNAN8ZjvFl87P5ksLhKJU1ZbZKWOfcXaYWzDBG8Ec4l
 GMZH9KUCio_IXD_jCnubZ3S9Z0_lEZzXmWxW.UTn.Df0JNO0veooojTLG1RxnPVml4opfUZXCEKt
 4BCLSmNi2AOhnynxVW_WTG2t7lpeNPorhfE7iAKMWIuUgTQ6uAIrhSGbJGFJdrou3Q9X15uPp1fi
 fcgzpk3vJ9HkPEF3a_F95iAFN_wWpEtcdSBxmzXp0gV2lfibh8lxUOyUnuahz2SwL1HtzLwivgO2
 p43e74M9p9HXrW2V331Zlb5ZdoY8r9cFbhj_ymwXsmRbfOI_xkhUHJxpmqvtCvqyRZWl7MvCT3rH
 Tq9_XiG8Y.S_HNBvp19D2nZ4F1nvawY4hgKfp0kOpcvHe1OaBo1koHQuehDbR7AzdtU.gf3UBrjS
 ZEkNR0Ym7Wkfno925Cj54vazdRGj_G5cGmiWZ7p_uXeV.yQIq5sATTBbSiUomx5UZn9OeoF5iA68
 8N7aRVI540996Zy8A1iTuOWVBG4JgX_whqeHcRKofDsT0mC6T2O1Ck6fnuHrcs5VymkkXxTNbLP0
 v2wHZfvS87ARw9H61ES3S1IW13TMAt2Uzqsm8K5MPmC6XnpqBCDdwC6N9s9FTW5HDgwPA9JKO4r5
 hK0bm3PJwOZI5f98gwRS173B8QslVVcfifmsQKVGBgMVDuyd88Dn3UHvPna22y5HiUobqMWH3cP8
 zPIR04Y8pOVEv1rWC_VEz29giCtUiwpKgFYz3OYBkH2KExzRXAIGtPg.lzmyvOmws2vguWZXodf0
 EEHp5WKVkoHkZhTBEGMj.96FBmITvzfzhnIhvt4BPhDWFnmdryjjT4NDEwKwJ5tHWxqhG6zrsYmH
 hGYyv9r_0buRi_1rxYR2xVOaXTCZ0Hj5eRtzyCeqyyroqrJiAiJFI4rbl8XJ.IfEvoJzTylVHwUh
 TL4eLjSzmuW1as.Q.T7EtQX9LN9ei5Ua9GCwLtiqwuD0m_KqEMORn1IUyjRB2QfNvot6sJkwu.bW
 C.81HmRGsLVbr0q2bjHBgoHHe63c6f.i8Yv8_QxiNl4XGaME63U49xjXHJBbcxCKg7IOAtEr_zCT
 ddk64wfDhPCVM78pf3nAzb_H5dT3DZ.WrK08c5bbjOpuwKKI2Roz3hSwVmav.MPISY9PgNKjb8vL
 D0IjyvIQdRwyQKOKQk843fIlbqLjv9YsbCDAaudqwg8kW0ATXZX1F_9WsH2TVmL3hfhTY.46ajwN
 gjKQEWPuPsiNJvneZQwqiurd1K.R0y21vfo1LXZKskZRbzx0qnd7ejg.Cy9iePGo9DyQOpQzjsBo
 i5rLdNlpyRFLdlwqLbL8890zIjeZhT_zHpO237PXcmYV.qDM.0nXnn3fMgv0o3l3w5dKiD6eY_P0
 RSA9W9Fx5._JLTTNRHPKmBVtgFG0mf__1P3GrKe2Bu7bGeAolMv7Z1Ti4x3kUiKAA4drTYcAJ0qR
 oq0Vnm3cnGPipousSdZ2pCPS5Tw4AbpXghW.6G8e7QmroLpnHVX5l9zbkZRUDNQmZBuV7Pqjh3Fp
 UXwX75T7TOWUQkfD6Yi1aGCsAIoTv4dsQoJ1HOw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 02:46:59 +0000
Received: by kubenode551.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d032b447dca464c02ae5fd2faa42a776;
          Sat, 09 Apr 2022 02:46:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPI4 panic on boot with -current
From: Mark Millard 
In-Reply-To: <20220409015321.GA52002@www.zefox.net>
Date: Fri, 8 Apr 2022 19:46:57 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220409015321.GA52002@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KZzzZ2Xqgz3DxV
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=quspTgOb;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.36 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.14)[0.139];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9828
Lines: 287

On 2022-Apr-8, at 18:53, bob prohaska  wrote:

> Might this be related to "RPi4B's got a PMIC replacement,..." reported =
4/3 ?

No: See the later note about the RPi4B Revision.

> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build =
of=20
> -current reports:
>=20
> Resetting system ...=20
>=20
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)

This is an old U-Boot compared to sysutils/u-boot-* .
There may well be good reasons for using it, for all
I know.

sysutils/u-boot-* got 2021.04 on 2021-Apr-06.
sysutils/u-boot-* got 2021.07 on 2021-Jul-07.

sysutils/u-boot-* got a patch to fix MMC ordering
because 2021.07 had changed something the port
depended on for the ordering, if I udnerstand right.
This update was on 2021-Nov-09.

I do not know if any of the more up to date vintages
would be more appropriate or not.

I can not tell which of the following is in use:

sysutils/u-boot-rpi-arm64
vs.
sysutils/u-boot-rpi-rpi4

The 2021-Nov-09 patching changed both to explicitly
have:

U_BOOT_SLAVE_PORTREVISION_2021.07=3D	1

in addition to the extra patch.

> DRAM:  7.9 GiB
> RPI 4 Model B (0xd03114)

An RPi4B with the new PMIC would jave the 0x... end in 15,
instead of 14. This is a RPi4B Rev 1.4 (the 14). [The d
is the 8 GiByte indication.] A RPi4B with the new PMIC
would be Rev. 1.5 at this point (15).

> MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
> Loading Environment from FAT... sdhci_set_clock: Timeout to wait cmd & =
data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
> sdhci_send_command: MMC: 1 busy timeout.

I've no clue about the above lines --or related material below.

> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> Card did not respond to voltage select!
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
>=20
> Device 0: Vendor: SABRENT  Rev: 0204 Prod:=20
>            Type: Hard Disk
>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
> Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Card did not respond to voltage select!
> Scanning disk emmc2@7e340000.blk...
> Disk emmc2@7e340000.blk not ready
> Scanning disk usb_mass_storage.lun0...
> ** Unrecognized filesystem type **
> Found 3 disks
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> 1259292 bytes read in 5 ms (240.2 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootaa64.efi
>=20
> [whitespace trimmed]
>=20
> Consoles: EFI console =20
>    Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk0p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Thu Mar  4 07:32:03 UTC 2021 root@releng1.nyi.freebsd.org)
>=20
>   Command line arguments: loader.efi
>   Image base: 0x39cfc000
>   EFI version: 2.80
>   EFI Firmware: Das U-Boot (rev 8224.4096)
>   Console: comconsole (0)
>   Load Path: /efi\boot\bootaa64.efi
>   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Setting currdev to disk0p1:
> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x746ed5e9)
> Setting currdev to disk0p2:
> /
> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=3D0x2a8 text=3D0x851220 text=3D0x24be84 =
data=3D0x1b9ba8 data=3D0x0+0x34f000 syms=3D[0x8+0x134028+0x8+0x15b5e1]
> Loading configured modules...
> /boot/kernel/filemon.ko text=3D0x1867 text=3D0x2558 data=3D0x510+0x20 =
syms=3D[0x8+0xd08+0x8+0x7c9]
> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x13a0 data=3D0x6d8+0x10 =
syms=3D[0x8+0xf18+0x8+0xb5c]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=3D0x2590 text=3D0x2f00 data=3D0x8e0+0x858 =
syms=3D[0x8+0x1290+0x8+0xbd5]
> /boot/entropy size=3D0x1000
> /etc/hostid size=3D0x25
>=20
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...              =20
> Using DTB provided by EFI at 0x7ef0000.
> EFI framebuffer information:
> addr, size     0x3e22c000, 0x8ca000
> dimensions     1920 x 1200
> stride         1920
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<>---
> 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 =
compliance
> Copyright (c) 1992-2022 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-CURRENT #40 main-aa597d4049-dirty: Fri Apr  8 11:44:42 =
PDT 2022
>    bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 1920x1200
> module firmware already present!
> real memory  =3D 8441835520 (8050 MB)
> avail memory =3D 8206352384 (7826 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
> Fatal data abort:
>  x0: ffffa0003b25dad0
>  x1:                8
>  x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
>  x3:              78a
>  x4:                0
>  x5:               69
>  x6:         40a7152f
>  x7:         f2db3c10
>  x8: ffffa0003b25dad0
>  x9:        200000000
> x10: ffffa00000000000
> x11:         3b25dad0
> x12: 725f696665006966
> x13:  100000102ff0001
> x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
> x15:                0
> x16:                8
> x17:         f4b3707d
> x18: ffff000000fa79b0 (initstack + 39b0)
> x19: ffffa000008db380
> x20: ffff000000ab4810 (efirt_moddata + 0)
> x21: ffff000000911163 (console_pausestr + 13a59)
> x22: ffff000000c6d000 (db_watch_table + b88)
> x23: ffff000000ba1000 (compiler_version + 20)
> x24: ffff000000dfb000 (gdb_tx_u + aa0)
> x25:                0
> x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
> x27:          3100000
> x28: ffff000000dfb000 (gdb_tx_u + aa0)
> x29: ffff000000fa79c0 (initstack + 39c0)
>  sp: ffff000000fa79b0
>  lr: ffff000000157ac4 (efirt_modevents + 78)
> elr: ffff000000157ad0 (efirt_modevents + 84)
> spsr:         200000c5
> far: ffffa0003b25dad0
> esr:         96000007
> panic: vm_fault failed: ffff000000157ad0 error 1
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db> bt
> Tracing pid 0 tid 100000 td 0xffff000000dfc0e0
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x368
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1cc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1b0
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> db>=20
>=20
> followed by
>=20
> db> reboot
> cpu_reset failed
>=20
> After power cycle the machine rebooted to
> FreeBSD 14.0-CURRENT #34 main-79c4c4be96-dirty: Tue Apr  5 09:26:19 =
PDT 2022
> without obvious problems. "Dirty" is in reference to /usr/src/tests, =
I've
> refrained from tampering with the sources.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 05:57:30 2022
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 60ACC1A9023B
	for ; Sat,  9 Apr 2022 05:57:30 +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 4Kb4CG0SDKz4bSh
	for ; Sat,  9 Apr 2022 05:57:30 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 DA4D414749
	for ; Sat,  9 Apr 2022 05:57:29 +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 2395vTlo061625
	for ; Sat, 9 Apr 2022 05:57:29 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2395vTDm061624
	for freebsd-arm@FreeBSD.org; Sat, 9 Apr 2022 05:57:29 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 263170] RPi3B+ U-Boot Saveenv fails
Date: Sat, 09 Apr 2022 05:57:30 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jollyrogue@dangertoaster.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649483850;
	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=IhDFaP0aORxWLvWiog/Dtys9IQenSxufAa88TjeSCGc=;
	b=Fzrrq22vvbrD9FMVSJ3k3r4BBE12NFB/Vl0JZBmTGwAscGOTq4c9SPRAyk1eZks6yTr4aV
	+8f27518CqxEVIJr+N6IhSJsOKJV8i7TcE95d5xUwgWum3bBdWXq8yQ9F5T+RasDXRhr3u
	tE4g4epF1+H92uSYnoUiWvfSn7nUo7o/pQVkCy5wsX6GO7z3LPsgfLbt/aA9FvwfJ1wPBH
	r6lFquBwOYat6+ExluqSAS99nx3QntC3a3BbksFWhM/Pch3wlkVBkqMTBJds8BqAhHdvne
	P2S/BTfbTyggximS8obQfP77LhEb92vDP8u5vCJY/f+YwkL4KalJYJ5mWAr+Jg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649483850; a=rsa-sha256; cv=none;
	b=oOmTczrmVJihQOITOIoPwBDi/fSJZI8k/DIjjkhJrCz9NnZaWm3fQTfbh5tOktt8UuEBb5
	ytqtm2SlXJq0EkfcxUHPCEIOepAYtnXMaJpz92h6d6+79RBUCdfu9TnvP7EPvwKAMyfuwv
	2op++8g9JKpT9HGCiRHfu22RXB39OXDRhpgxzRyR3u2EXr+EcGx65nAzfUwxjZWoYy3VL8
	GJ+dNd9yDZt/sTLRE1+1viPm6vLh0YvgrNbodRbA4M30HT8N1NE4h8/3zAkTv0gFL2uLOI
	v3r3W56Ecx+MOXSqs7C66b5GUManBRrR/WKKO5obK8eq2xIU6knT7yYFSghBwQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1633
Lines: 59

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263170

            Bug ID: 263170
           Summary: RPi3B+ U-Boot Saveenv fails
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jollyrogue@dangertoaster.com

Short story...

My RPi3+ fails to save my edited u-boot environment.

```
U-Boot> editenv usb_pgood_delay
edit: 10000
U-Boot> saveenv
Saving Environment to FAT... Failed (1)
U-Boot>
```

Any suggestions about what I should look at?

Long story...

I'm trying to get my RPi 3B+ to mount home on an external USB HD, but the
external HD spins down just as the filesystems are being checked. The home =
dir
on the HD isn't found, and FreeBSD drops down to single user mode. The HD is
found about 3 seconds later, and I can exit single user mode to finish boot=
ing.

Weirdly, the swap partition on the HD is found and works without problem.

I switched to an external SSD, and that works fine. home and the swap are f=
ound
and mounted without any problems.

I started working throught Bob Prohaska's notes as linked in the FreeBSD Arm
wiki, and that's when I got to the u-boot saveenv problem.

```
% uname -a
FreeBSD gopher 13.0-RELEASE-p11 FreeBSD 13.0-RELEASE-p11 #0: Tue Apr  5
18:58:59 UTC 2022=20=20=20=20
root@arm64-builder.daemonology.net:/usr/obj/usr/src/arm64.aarch64/sys/GENER=
IC=20
arm64
```

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Apr  9 07:47:34 2022
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 28F901A930EF
	for ; Sat,  9 Apr 2022 07:47:44 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Kb6fQ5RMjz4YTb
	for ; Sat,  9 Apr 2022 07:47:42 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B97C42622AC;
	Sat,  9 Apr 2022 09:47:34 +0200 (CEST)
Message-ID: <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
Date: Sat, 9 Apr 2022 09:47:34 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: Rpi3 panic, data abort with spinlock held on -current
Content-Language: en-US
To: Mark Millard , Free BSD 
Cc: bob prohaska 
References: <20220408230853.GA51713@www.zefox.net>
 <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
From: Hans Petter Selasky 
In-Reply-To: <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Kb6fQ5RMjz4YTb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.34 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_SPAM_MEDIUM(0.93)[0.930];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.971];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 413
Lines: 13

On 4/9/22 02:15, Mark Millard wrote:
> generic_bs_rr_4() at generic_bs_rr_4+0xc
> dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
> dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
> intr_event_handle() at intr_event_handle+0xf0

Hi,

Is it possible to get and verify the arguments for generic_bs_rr_4() ?

My guess is that the destination buffer is no longer available.

--HPS

From nobody Sat Apr  9 08:22:47 2022
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 4B2211A9DD8A
	for ; Sat,  9 Apr 2022 08:23:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kb7R71Kvcz4h5y
	for ; Sat,  9 Apr 2022 08:22:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649492572; bh=od7xSnNFEDHgzSZooWhac+zEIjfLMARkxTBhkfLTRCQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=doFQggZtaPAKrJLDn4/pMSftHpKQv+/g3UB3+6ZfVnl11xPenwFlmBwEoomhriZVSeECT3wLE5xPbxF2LD8YYieEMuY27tuJOjKWFx49TzRt/RThkmzjWSvYbEd+c2bIzehkkhMvndTJSGKyLEU8IbNQR6chIEYzCisOSglYA4XwC6fcoQJFIwYAfW8Cqv/FWL4xxWYXhj8qDC4/FN5bLy2avtyzxj5GEyVvqhsIGiNFw4wOQyhc58IuBS7rvFcp5HPa1BDSsOGtXd44qECD3f2OkPm1ZXGeR9Iw2qXBVZnxj37Ei1ckOc+gfwwINSGvbwqam17yq5+liS8IHdKy4g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649492572; bh=3+BSn28aJUHEGmTfOd9aoD1xVspIio8h+oQxs4Oks8c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VjtKhgW3FV1Acih9MxFrbJmQUfMPxag2SlhwWdhU1DNwEyfWEjlRBhZBA96pIlu3oqZT0Yl6kXXv1vwkm5e6oMmJeecaDssNJaWMJE2Y6PQ8ltZhSe7Iy4400M791cQCkqY55l3dQ/8dXMMXgFA593Bqh47q4QrMeUUzCzFw0BkIwvfxtU2pHJi01t5rrhZcf+6vJZLvT+964v4BpFV3/PMvEE5dadkn5IuUQZnNZx1MeDfOKXCwe5O42CUbzIWBPyYSmxNWxSLcH00WLUX/DjTIjpRTRMDNQWQ/5dmfH+sdnrqIgeLFt5XkwWA0PW54GxD4Qj3PP8ZpxEgnGwrXxw==
X-YMail-OSG: 31BvA0oVM1kUtJpRuXD57j3APFsBWowMxCMmnm7OdMoexAsqKEMx.nnfHnUS6mr
 rBn2mAiP2bRTG_2nW0qHvcUMxwbgEZyNi3t7ZBi2jyB9iLuVRjrsI370OZq3CUj.F4HCxkJqq6Jm
 MKeIVEOGwdjLmAZ081wzWoljxuZ41ojcFH9WFDFGeUnF_LvGxlROj.ZEvw67M6cqw4fJPNg_lOLb
 kSe_9k.Xv3LUARk8D4eNTg_IDwkVjupLIuoAnze1vlbJIPqeLdJ1rB7Kw_6pgql2vihi92JGt..e
 FvGdPo6WUV9l2xAUptzR793L1JNAQfp3CjuOMcYbQZTLgOq0ODK4UffJU4.g9FkPIeaLgfvLLKVN
 vr80LvyWBSvGbFignwyemKAekn5z5TudLWAcNW8VkPL07Gzj6VK6GY7sQbCKMle7nsatPb0M8rvb
 Q9WXyuFgrryyjG96AnT2usLRM1ZzYpBnxgU5cteI6_1ArVTdeu1sX4YmK5IMpy3JVZ5lzbPhaimQ
 uJfHPtS0Yl0dlxio_RhjLLc2KDwDWWQj70jjg0KOq0MSurHLw3yKbSZs2Tx.iylCw3l2EfkwmCve
 uXjjA6chh77Ks7pwfhfLhWuuxvaPUQaDQlMxBuvGh4RNRec_4oiHVRBiMkDzfQeBeJV4Nc_Zwc60
 7P55araZqi6fBW1cdVDEBt9RwTEuWJDZEYs_xolZuC1KfE0n5QRtfL8BrQQojBRuPVUBMg9lJzxK
 vyaLEkzC9MZsvhquXLvNRKwL7mz8.zSTFfWLf5GrKmZvmqXq5LyV66WWRnWw0rUiaamYQtACqIZG
 33KyD3EWUP95ZAnryY9aFRCCgKMcXVKZj.R3l0qwkQljbnon7G0GYNvhBv6tX6WGLnmoxDeoENih
 iw4EGgPgXanm3JluwDiZtj7ELTw_E_jxJ8a6LkCvzbghVMBI7B3QSbavK044NSRW6a6OQGoYGwgE
 aK_Na9ptihVhHcwf_cxpXqd8peDiiN9JKrhV_x8s3V4qKurMCw5A9.lJpmLBzA7cAMo2Td5t2fDT
 sZqReQ6HJQ59_yqJ18rxOIhtaA4dBLoyAwgtfwdu4kbyr.jikZzya.NfLZLHdtLFBpr38cpJH4vd
 Oo30i7aa8nStymXvUEBZErl8qlRInt4HoulGM9A_1ufUhWAO2S2B6Ayrp1ul98BaHGvDYVyJrsYJ
 Vyb6B0IwcksrfLw5aVRt0BzoLYcxB6CAmS7ORSTTFsORXfkivwsqZK4abGazmdEChDSWK091wBPT
 w.vKu8v.LNO.psQYjFSlK12SYfywTGbmzCRsmtToGpv5rjldrSZ1Uau1eqPdX7yV675sbgccRwHM
 Ee..gCew1Olrn8ilYfgEOHzkUiz1m9Xy7jMcJ04HSze.HTX4eqGyd93.zH5K4e1ITCzhWFFOEt32
 SVymYTbIGioH4BMLGeHHR2CVUeHCnFpv81DnmLDIysG6Gabw2srkrarB06KgVqMfA_NcJQEOBU0h
 QObwgeVZTAYISenJ5zEbDJl47lweUxtplPr0OuCuy12hrf52rA7WNQHGeZ6xjrS8mx9B3LagGaji
 ACk0En8gbAeTnUNCUPlu3xdmgRxv._XkExgEPKjjHMxRkkU61RGvIdeLjBiFqsHNNLTx1aPmEZlZ
 mnHix_BvaQhj_ZnixcPu785AE3ON9vngOCpn9NI9Y6K1Rw15COU0w0oEtCQ3Pbt30lMSx4Ae8v84
 A2_aEcvgYOGNYTEDjquTxLpax_8F3DjzItjpb211gX2ufNDNpnwSvXLuyXhL8sPyviwhVZiaKzQS
 hqW_YPRyEDOFRZgRmjMWuEoeu4jMBAqDbGoRMZiQtuKFC6Aim_YIUDMSoH4Xz2ozyDqwyvFXhatz
 xpyx.hVopwHWtloJ76m2ou6aZiuMjK6ukDEFDsQVJEGj2GUtAyFZ_75xkq0kYt9pbU.wHA7Q1l80
 vdTi3UFC2WlNvdkPyzLn3lJSrvoVmP4aEtVFzjVpz_4uosxbMYN3C0vj4uefmcvcV1T0vNpsBkjl
 Ri8Mbi_GqOjLz6rz.a_tC3kXQ0PVN45Z.ODOwPmVvYUvfink2TZD.yjpgNudELFogtAHSLrUzqqr
 aKGF47.SH4MJq1NiiloGoLzL9EfrbhanztJST8AIQ1oC26lu0At8ahW_OaB78PB.X3.1usJKid.s
 oWVO4kiQ2a_RGoKtJaYpjRBgsj9mFHwfpu7Z1wMGJd1kQnY3_ke1oZ3teNur9x0Sxw8d1.GTih5K
 EeLLPrBOaQFRWXa4AYjCJV7ah2LX8uqsT7xoMCE5WW74jpj5cT.EarkhCTBcnYavaaO3nzmaTMIe
 yRUwQuV5Yl87eEU5373iaD2LCJoQL
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 08:22:52 +0000
Received: by hermes--canary-production-bf1-665cdb9985-l8dtt (VZM Hermes SMTP Server) with ESMTPA ID 130eaf72f912f58083810a2b11835141;
          Sat, 09 Apr 2022 08:22:49 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Rpi3 panic, data abort with spinlock held on -current
From: Mark Millard 
In-Reply-To: <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
Date: Sat, 9 Apr 2022 01:22:47 -0700
Cc: Free BSD 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20220408230853.GA51713@www.zefox.net>
 <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
 <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
To: Hans Petter Selasky ,
 bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kb7R71Kvcz4h5y
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=doFQggZt;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 794
Lines: 26

On 2022-Apr-9, at 00:47, Hans Petter Selasky  wrote:

> On 4/9/22 02:15, Mark Millard wrote:
>> generic_bs_rr_4() at generic_bs_rr_4+0xc
>> dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
>> dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
>> intr_event_handle() at intr_event_handle+0xf0
> 
> Hi,
> 
> Is it possible to get and verify the arguments for generic_bs_rr_4() ?

That is a question for Bob P. All I did was forward some of
his off-list written material to the list for easier reference.

I do not have a context for reproducing the issue. My systems
date back to 2022-Mar-22 or before. Bob's running more recent
versions.

> My guess is that the destination buffer is no longer available.


===
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 11:00:47 2022
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 D9DA61AAE896
	for ; Sat,  9 Apr 2022 11:00:55 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbBxL6fzGz3Pdh
	for ; Sat,  9 Apr 2022 11:00:54 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=O1YSErky/NOVsM/DUQ8/t/RCfxzxYgJnwtRsEh/l1V0=; b=McCPb1q+Hf1PfOZDna8h7EPzLf
	2/7PBMkvsOfZeT1nzj8e2AjRmzNVE9LxUi6g6y4HhG1AWKT3k+je+ig2+h4hMcDIDEHsVBKbCvoEA
	OLVsZ7oY7CHhx4Y89iSEax0Cmc9BmfgXCysOIOr1D/x7YQZSRv3/Tzk+PIsxHiPz4g3M=;
Message-ID: <818eec37-222f-0ce8-be38-3f38e7205b55@klop.ws>
Date: Sat, 9 Apr 2022 13:00:47 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: RPI4 panic on boot with -current
Content-Language: en-US
To: bob prohaska , freebsd-arm@freebsd.org
References: <20220409015321.GA52002@www.zefox.net>
From: Ronald Klop 
In-Reply-To: <20220409015321.GA52002@www.zefox.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: ---
X-Spam-Score: -3.2
X-Spam-Status: No, score=-3.2 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 4c6e9116b9ad1e3c2304ae6adbe1e50f
X-Rspamd-Queue-Id: 4KbBxL6fzGz3Pdh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=McCPb1q+;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-3.33 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RWL_MAILSPIKE_EXCELLENT(0.00)[195.190.28.88:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 NEURAL_HAM_SHORT(-0.33)[-0.335];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8838
Lines: 238

On 4/9/22 03:53, bob prohaska wrote:
> Might this be related to "RPi4B's got a PMIC replacement,..." reported 4/3 ?
> 
> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build of
> -current reports:
> 
> Resetting system ...
> 
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
> 
> DRAM:  7.9 GiB
> RPI 4 Model B (0xd03114)
> MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
> Loading Environment from FAT... sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
> sdhci_send_command: MMC: 1 busy timeout.
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 6 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> Card did not respond to voltage select!
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
> 
> Device 0: Vendor: SABRENT  Rev: 0204 Prod:
>              Type: Hard Disk
>              Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
> Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Card did not respond to voltage select!
> Scanning disk emmc2@7e340000.blk...
> Disk emmc2@7e340000.blk not ready
> Scanning disk usb_mass_storage.lun0...
> ** Unrecognized filesystem type **
> Found 3 disks
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> 1259292 bytes read in 5 ms (240.2 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootaa64.efi
> 
> [whitespace trimmed]
> 
> Consoles: EFI console
>      Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk0p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Thu Mar  4 07:32:03 UTC 2021 root@releng1.nyi.freebsd.org)
> 
>     Command line arguments: loader.efi
>     Image base: 0x39cfc000
>     EFI version: 2.80
>     EFI Firmware: Das U-Boot (rev 8224.4096)
>     Console: comconsole (0)
>     Load Path: /efi\boot\bootaa64.efi
>     Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Setting currdev to disk0p1:
> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x746ed5e9)
> Setting currdev to disk0p2:
> /
> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=0x2a8 text=0x851220 text=0x24be84 data=0x1b9ba8 data=0x0+0x34f000 syms=[0x8+0x134028+0x8+0x15b5e1]
> Loading configured modules...
> /boot/kernel/filemon.ko text=0x1867 text=0x2558 data=0x510+0x20 syms=[0x8+0xd08+0x8+0x7c9]
> /boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6d8+0x10 syms=[0x8+0xf18+0x8+0xb5c]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=0x2590 text=0x2f00 data=0x8e0+0x858 syms=[0x8+0x1290+0x8+0xbd5]
> /boot/entropy size=0x1000
> /etc/hostid size=0x25
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> Using DTB provided by EFI at 0x7ef0000.
> EFI framebuffer information:
> addr, size     0x3e22c000, 0x8ca000
> dimensions     1920 x 1200
> stride         1920
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<>---
> 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 compliance
> Copyright (c) 1992-2022 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-CURRENT #40 main-aa597d4049-dirty: Fri Apr  8 11:44:42 PDT 2022
>      bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 1920x1200
> module firmware already present!
> real memory  = 8441835520 (8050 MB)
> avail memory = 8206352384 (7826 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
> Fatal data abort:
>    x0: ffffa0003b25dad0
>    x1:                8
>    x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
>    x3:              78a
>    x4:                0
>    x5:               69
>    x6:         40a7152f
>    x7:         f2db3c10
>    x8: ffffa0003b25dad0
>    x9:        200000000
>   x10: ffffa00000000000
>   x11:         3b25dad0
>   x12: 725f696665006966
>   x13:  100000102ff0001
>   x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
>   x15:                0
>   x16:                8
>   x17:         f4b3707d
>   x18: ffff000000fa79b0 (initstack + 39b0)
>   x19: ffffa000008db380
>   x20: ffff000000ab4810 (efirt_moddata + 0)
>   x21: ffff000000911163 (console_pausestr + 13a59)
>   x22: ffff000000c6d000 (db_watch_table + b88)
>   x23: ffff000000ba1000 (compiler_version + 20)
>   x24: ffff000000dfb000 (gdb_tx_u + aa0)
>   x25:                0
>   x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
>   x27:          3100000
>   x28: ffff000000dfb000 (gdb_tx_u + aa0)
>   x29: ffff000000fa79c0 (initstack + 39c0)
>    sp: ffff000000fa79b0
>    lr: ffff000000157ac4 (efirt_modevents + 78)
>   elr: ffff000000157ad0 (efirt_modevents + 84)
> spsr:         200000c5
>   far: ffffa0003b25dad0
>   esr:         96000007
> panic: vm_fault failed: ffff000000157ad0 error 1
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db> bt
> Tracing pid 0 tid 100000 td 0xffff000000dfc0e0
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x368
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1cc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1b0
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> db>
> 
> followed by
> 
> db> reboot
> cpu_reset failed
> 
> After power cycle the machine rebooted to
> FreeBSD 14.0-CURRENT #34 main-79c4c4be96-dirty: Tue Apr  5 09:26:19 PDT 2022
> without obvious problems. "Dirty" is in reference to /usr/src/tests, I've
> refrained from tampering with the sources.
> 
> Thanks for reading,
> 
> bob prohaska
>   
> 





Is this similar to this?

https://lists.freebsd.org/archives/dev-commits-src-all/2022-April/009765.html


Regards,
Ronald.


From nobody Sat Apr  9 11:46:36 2022
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 B36761A83203
	for ; Sat,  9 Apr 2022 11:46:41 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KbCy75PNTz3mj8
	for ; Sat,  9 Apr 2022 11:46:39 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id 3E4DC4E74B;
	Sat,  9 Apr 2022 11:46:39 +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 \(3696.80.82.1.1\))
Subject: Re: RPI4 panic on boot with -current
From: Andrew Turner 
In-Reply-To: <20220409015321.GA52002@www.zefox.net>
Date: Sat, 9 Apr 2022 12:46:36 +0100
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
References: <20220409015321.GA52002@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Rspamd-Queue-Id: 4KbCy75PNTz3mj8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=fubar.geek.nz;
	spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz
X-Spamd-Result: default: False [-3.10 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.90)[-0.901];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8972
Lines: 254

Does the patch in https://reviews.freebsd.org/D34858 allow the system to =
boot? The EFI runtime services may not work, but it should stop the =
panic.

Andrew

> On 9 Apr 2022, at 02:53, bob prohaska  wrote:
>=20
> Might this be related to "RPi4B's got a PMIC replacement,..." reported =
4/3 ?
>=20
> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build =
of=20
> -current reports:
>=20
> Resetting system ...=20
>=20
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
>=20
> DRAM:  7.9 GiB
> RPI 4 Model B (0xd03114)
> MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
> Loading Environment from FAT... sdhci_set_clock: Timeout to wait cmd & =
data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
> sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
> sdhci_send_command: MMC: 1 busy timeout.
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> Card did not respond to voltage select!
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
>=20
> Device 0: Vendor: SABRENT  Rev: 0204 Prod:=20
>            Type: Hard Disk
>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_set_clock: Timeout to wait cmd & data inhibit
> sdhci_send_command: MMC: 1 busy timeout.
> Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Card did not respond to voltage select!
> Scanning disk emmc2@7e340000.blk...
> Disk emmc2@7e340000.blk not ready
> Scanning disk usb_mass_storage.lun0...
> ** Unrecognized filesystem type **
> Found 3 disks
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> 1259292 bytes read in 5 ms (240.2 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootaa64.efi
>=20
> [whitespace trimmed]
>=20
> Consoles: EFI console =20
>    Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk0p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Thu Mar  4 07:32:03 UTC 2021 root@releng1.nyi.freebsd.org)
>=20
>   Command line arguments: loader.efi
>   Image base: 0x39cfc000
>   EFI version: 2.80
>   EFI Firmware: Das U-Boot (rev 8224.4096)
>   Console: comconsole (0)
>   Load Path: /efi\boot\bootaa64.efi
>   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
> Setting currdev to disk0p1:
> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x746ed5e9)
> Setting currdev to disk0p2:
> /
> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=3D0x2a8 text=3D0x851220 text=3D0x24be84 =
data=3D0x1b9ba8 data=3D0x0+0x34f000 syms=3D[0x8+0x134028+0x8+0x15b5e1]
> Loading configured modules...
> /boot/kernel/filemon.ko text=3D0x1867 text=3D0x2558 data=3D0x510+0x20 =
syms=3D[0x8+0xd08+0x8+0x7c9]
> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x13a0 data=3D0x6d8+0x10 =
syms=3D[0x8+0xf18+0x8+0xb5c]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=3D0x2590 text=3D0x2f00 data=3D0x8e0+0x858 =
syms=3D[0x8+0x1290+0x8+0xbd5]
> /boot/entropy size=3D0x1000
> /etc/hostid size=3D0x25
>=20
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...              =20
> Using DTB provided by EFI at 0x7ef0000.
> EFI framebuffer information:
> addr, size     0x3e22c000, 0x8ca000
> dimensions     1920 x 1200
> stride         1920
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<>---
> 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 =
compliance
> Copyright (c) 1992-2022 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-CURRENT #40 main-aa597d4049-dirty: Fri Apr  8 11:44:42 =
PDT 2022
>    bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 1920x1200
> module firmware already present!
> real memory  =3D 8441835520 (8050 MB)
> avail memory =3D 8206352384 (7826 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
> Fatal data abort:
>  x0: ffffa0003b25dad0
>  x1:                8
>  x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
>  x3:              78a
>  x4:                0
>  x5:               69
>  x6:         40a7152f
>  x7:         f2db3c10
>  x8: ffffa0003b25dad0
>  x9:        200000000
> x10: ffffa00000000000
> x11:         3b25dad0
> x12: 725f696665006966
> x13:  100000102ff0001
> x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
> x15:                0
> x16:                8
> x17:         f4b3707d
> x18: ffff000000fa79b0 (initstack + 39b0)
> x19: ffffa000008db380
> x20: ffff000000ab4810 (efirt_moddata + 0)
> x21: ffff000000911163 (console_pausestr + 13a59)
> x22: ffff000000c6d000 (db_watch_table + b88)
> x23: ffff000000ba1000 (compiler_version + 20)
> x24: ffff000000dfb000 (gdb_tx_u + aa0)
> x25:                0
> x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
> x27:          3100000
> x28: ffff000000dfb000 (gdb_tx_u + aa0)
> x29: ffff000000fa79c0 (initstack + 39c0)
>  sp: ffff000000fa79b0
>  lr: ffff000000157ac4 (efirt_modevents + 78)
> elr: ffff000000157ad0 (efirt_modevents + 84)
> spsr:         200000c5
> far: ffffa0003b25dad0
> esr:         96000007
> panic: vm_fault failed: ffff000000157ad0 error 1
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db> bt
> Tracing pid 0 tid 100000 td 0xffff000000dfc0e0
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x368
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1cc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1b0
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x84
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x130
> virtdone() at virtdone+0x7c
> db>=20
>=20
> followed by
>=20
> db> reboot
> cpu_reset failed
>=20
> After power cycle the machine rebooted to
> FreeBSD 14.0-CURRENT #34 main-79c4c4be96-dirty: Tue Apr  5 09:26:19 =
PDT 2022
> without obvious problems. "Dirty" is in reference to /usr/src/tests, =
I've
> refrained from tampering with the sources.
>=20
> Thanks for reading,=20
>=20
> bob prohaska
>=20
>=20


From nobody Sat Apr  9 14:00:36 2022
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 20C051A894DA
	for ; Sat,  9 Apr 2022 14:00:41 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KbGwm1jY4z4knL
	for ; Sat,  9 Apr 2022 14:00:40 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 239E0a30082900;
	Sat, 9 Apr 2022 09:00:38 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id M8GMK4SRUWLSQwEA4+wvSQ
	(envelope-from ); Sat, 09 Apr 2022 09:00:36 -0500
From: Mike Karels 
To: Andrew Turner 
Cc: bob prohaska , Free BSD 
Subject: Re: RPI4 panic on boot with -current
Date: Sat, 09 Apr 2022 09:00:36 -0500
X-Mailer: MailMate (1.14r5818)
Message-ID: <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
In-Reply-To: <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
References: <20220409015321.GA52002@www.zefox.net>
 <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
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: 4KbGwm1jY4z4knL
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [1.34 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[mike];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_MISSING_CHARSET(2.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[karels.net];
	 NEURAL_HAM_LONG(-0.95)[-0.948];
	 NEURAL_SPAM_SHORT(0.99)[0.990];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9237
Lines: 259

On 9 Apr 2022, at 6:46, Andrew Turner wrote:

> Does the patch in https://reviews.freebsd.org/D34858 allow the system t=
o boot? The EFI runtime services may not work, but it should stop the pan=
ic.

It works on my RPi4 (original 4 GB model), which had the problem too.

		Mike

> Andrew
>
>> On 9 Apr 2022, at 02:53, bob prohaska  wrote:
>>
>> Might this be related to "RPi4B's got a PMIC replacement,..." reported=
 4/3 ?
>>
>> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build =
of
>> -current reports:
>>
>> Resetting system ...
>>
>> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
>>
>> DRAM:  7.9 GiB
>> RPI 4 Model B (0xd03114)
>> MMC:   mmc@7e300000: 1, emmc2@7e340000: 0
>> Loading Environment from FAT... sdhci_set_clock: Timeout to wait cmd &=
 data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
>> sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
>> sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
>> sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
>> sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
>> sdhci_send_command: MMC: 1 busy timeout.
>> In:    serial
>> Out:   vidconsole
>> Err:   vidconsole
>> Net:   eth0: ethernet@7d580000
>> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
>> starting USB...
>> Bus xhci_pci: Register 5000420 NbrPorts 5
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus xhci_pci for devices... 6 USB Device(s) found
>>       scanning usb for storage devices... 1 Storage Device(s) found
>> Hit any key to stop autoboot:  0
>> Card did not respond to voltage select!
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_send_command: MMC: 1 busy timeout.
>>
>> Device 0: Vendor: SABRENT  Rev: 0204 Prod:
>>            Type: Hard Disk
>>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
>> ... is now current device
>> Scanning usb 0:1...
>> Found EFI removable media binary efi/boot/bootaa64.efi
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_set_clock: Timeout to wait cmd & data inhibit
>> sdhci_send_command: MMC: 1 busy timeout.
>> Scanning disk mmc@7e300000.blk...
>> Disk mmc@7e300000.blk not ready
>> Card did not respond to voltage select!
>> Scanning disk emmc2@7e340000.blk...
>> Disk emmc2@7e340000.blk not ready
>> Scanning disk usb_mass_storage.lun0...
>> ** Unrecognized filesystem type **
>> Found 3 disks
>> No EFI system partition
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>> 1259292 bytes read in 5 ms (240.2 MiB/s)
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> Booting /efi\boot\bootaa64.efi
>>
>> [whitespace trimmed]
>>
>> Consoles: EFI console
>>    Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk0p1:
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Thu Mar  4 07:32:03 UTC 2021 root@releng1.nyi.freebsd.org)
>>
>>   Command line arguments: loader.efi
>>   Image base: 0x39cfc000
>>   EFI version: 2.80
>>   EFI Firmware: Das U-Boot (rev 8224.4096)
>>   Console: comconsole (0)
>>   Load Path: /efi\boot\bootaa64.efi
>>   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0=
x0,0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f=
,0x18fa8)
>> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,=
0x0,0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x=
18fa8)
>> Setting currdev to disk0p1:
>> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,=
0x9,0x0,0x3)/UsbClass(0x152d,0x1561,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x74=
6ed5e9)
>> Setting currdev to disk0p2:
>> /
>> Loading /boot/defaults/loader.conf
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> Loading kernel...
>> /boot/kernel/kernel text=3D0x2a8 text=3D0x851220 text=3D0x24be84 data=3D=
0x1b9ba8 data=3D0x0+0x34f000 syms=3D[0x8+0x134028+0x8+0x15b5e1]
>> Loading configured modules...
>> /boot/kernel/filemon.ko text=3D0x1867 text=3D0x2558 data=3D0x510+0x20 =
syms=3D[0x8+0xd08+0x8+0x7c9]
>> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x13a0 data=3D0x6d8+0x10 s=
yms=3D[0x8+0xf18+0x8+0xb5c]
>> loading required module 'ucom'
>> /boot/kernel/ucom.ko text=3D0x2590 text=3D0x2f00 data=3D0x8e0+0x858 sy=
ms=3D[0x8+0x1290+0x8+0xbd5]
>> /boot/entropy size=3D0x1000
>> /etc/hostid size=3D0x25
>>
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]...
>> Using DTB provided by EFI at 0x7ef0000.
>> EFI framebuffer information:
>> addr, size     0x3e22c000, 0x8ca000
>> dimensions     1920 x 1200
>> stride         1920
>> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>> ---<>---
>> 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 co=
mpliance
>> Copyright (c) 1992-2022 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19=
94
>>        The Regents of the University of California. All rights reserve=
d.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 14.0-CURRENT #40 main-aa597d4049-dirty: Fri Apr  8 11:44:42 PD=
T 2022
>>    bob@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC ar=
m64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llv=
morg-13.0.0-0-gd7b669b3a303)
>> WARNING: WITNESS option enabled, expect reduced performance.
>> VT(efifb): resolution 1920x1200
>> module firmware already present!
>> real memory  =3D 8441835520 (8050 MB)
>> avail memory =3D 8206352384 (7826 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
>> Fatal data abort:
>>  x0: ffffa0003b25dad0
>>  x1:                8
>>  x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
>>  x3:              78a
>>  x4:                0
>>  x5:               69
>>  x6:         40a7152f
>>  x7:         f2db3c10
>>  x8: ffffa0003b25dad0
>>  x9:        200000000
>> x10: ffffa00000000000
>> x11:         3b25dad0
>> x12: 725f696665006966
>> x13:  100000102ff0001
>> x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
>> x15:                0
>> x16:                8
>> x17:         f4b3707d
>> x18: ffff000000fa79b0 (initstack + 39b0)
>> x19: ffffa000008db380
>> x20: ffff000000ab4810 (efirt_moddata + 0)
>> x21: ffff000000911163 (console_pausestr + 13a59)
>> x22: ffff000000c6d000 (db_watch_table + b88)
>> x23: ffff000000ba1000 (compiler_version + 20)
>> x24: ffff000000dfb000 (gdb_tx_u + aa0)
>> x25:                0
>> x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
>> x27:          3100000
>> x28: ffff000000dfb000 (gdb_tx_u + aa0)
>> x29: ffff000000fa79c0 (initstack + 39c0)
>>  sp: ffff000000fa79b0
>>  lr: ffff000000157ac4 (efirt_modevents + 78)
>> elr: ffff000000157ad0 (efirt_modevents + 84)
>> spsr:         200000c5
>> far: ffffa0003b25dad0
>> esr:         96000007
>> panic: vm_fault failed: ffff000000157ad0 error 1
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> vpanic() at vpanic+0x174
>> panic() at panic+0x44
>> data_abort() at data_abort+0x2f0
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0x96000007
>> efirt_modevents() at efirt_modevents+0x84
>> module_register_init() at module_register_init+0xc4
>> mi_startup() at mi_startup+0x130
>> virtdone() at virtdone+0x7c
>> KDB: enter: panic
>> [ thread pid 0 tid 100000 ]
>> Stopped at      kdb_enter+0x44: undefined       f902011f
>> db> bt
>> Tracing pid 0 tid 100000 td 0xffff000000dfc0e0
>> db_trace_self() at db_trace_self
>> db_stack_trace() at db_stack_trace+0x11c
>> db_command() at db_command+0x368
>> db_command_loop() at db_command_loop+0x54
>> db_trap() at db_trap+0xf8
>> kdb_trap() at kdb_trap+0x1cc
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0xf2000000
>> kdb_enter() at kdb_enter+0x44
>> vpanic() at vpanic+0x1b0
>> panic() at panic+0x44
>> data_abort() at data_abort+0x2f0
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0x96000007
>> efirt_modevents() at efirt_modevents+0x84
>> module_register_init() at module_register_init+0xc4
>> mi_startup() at mi_startup+0x130
>> virtdone() at virtdone+0x7c
>> db>
>>
>> followed by
>>
>> db> reboot
>> cpu_reset failed
>>
>> After power cycle the machine rebooted to
>> FreeBSD 14.0-CURRENT #34 main-79c4c4be96-dirty: Tue Apr  5 09:26:19 PD=
T 2022
>> without obvious problems. "Dirty" is in reference to /usr/src/tests, I=
've
>> refrained from tampering with the sources.
>>
>> Thanks for reading,
>>
>> bob prohaska
>>
>>

From nobody Sat Apr  9 15:02:42 2022
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 CF52F1A98540
	for ; Sat,  9 Apr 2022 15:02:46 +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 4KbJJP44Yyz4tjV
	for ; Sat,  9 Apr 2022 15:02:45 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 239F2jn1055523
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 9 Apr 2022 08:02:46 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 239F2gDP055522;
	Sat, 9 Apr 2022 08:02:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 9 Apr 2022 08:02:42 -0700
From: bob prohaska 
To: Hans Petter Selasky 
Cc: Mark Millard , Free BSD 
Subject: Re: Rpi3 panic, data abort with spinlock held on -current
Message-ID: <20220409150242.GA55458@www.zefox.net>
References: <20220408230853.GA51713@www.zefox.net>
 <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
 <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
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: <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
X-Rspamd-Queue-Id: 4KbJJP44Yyz4tjV
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.54 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-0.79)[-0.795];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 NEURAL_SPAM_LONG(0.44)[0.437];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 631
Lines: 20

On Sat, Apr 09, 2022 at 09:47:34AM +0200, Hans Petter Selasky wrote:
> On 4/9/22 02:15, Mark Millard wrote:
> > generic_bs_rr_4() at generic_bs_rr_4+0xc
> > dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
> > dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
> > intr_event_handle() at intr_event_handle+0xf0

> 
> Is it possible to get and verify the arguments for generic_bs_rr_4() ?
> 
> My guess is that the destination buffer is no longer available.
> 

That particular panic hasn't repeated, yet. If it does repeat I can
try with sufficient instruction. 

Thanks for reading,

bob prohaska


From nobody Sat Apr  9 15:44:33 2022
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 936121A84BF0
	for ; Sat,  9 Apr 2022 15:44:34 +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 4KbKDd4sqbz52bl
	for ; Sat,  9 Apr 2022 15:44:33 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 239FiYux055602
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 9 Apr 2022 08:44:34 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 239FiYYh055601;
	Sat, 9 Apr 2022 08:44:34 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 9 Apr 2022 08:44:33 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: RPI4 panic on boot with -current
Message-ID: <20220409154433.GB55458@www.zefox.net>
References: <20220409015321.GA52002@www.zefox.net>
 
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: 4KbKDd4sqbz52bl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.04 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.94)[-0.939];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1554
Lines: 44

On Fri, Apr 08, 2022 at 07:46:57PM -0700, Mark Millard wrote:
> On 2022-Apr-8, at 18:53, bob prohaska  wrote:
> 
> > Might this be related to "RPi4B's got a PMIC replacement,..." reported 4/3 ?
> 
> No: See the later note about the RPi4B Revision.
> 
> > A Pi4 (mechanical disk only, no microsd) trying to boot a fresh build of 
> > -current reports:
> > 
> > Resetting system ... 
> > 
> > U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
> 
> This is an old U-Boot compared to sysutils/u-boot-* .
> There may well be good reasons for using it, for all
> I know.
> 

Only the most universal reasons: Inertia and ignorance 8-)

There are many versions of u-boot for rpi boards, some of 
which are rather ambiguously named; u-boot-rpi-arm64 versus
u-boot-rp4 is a good example. It appears the pkg-descr files
have been updated since I last looked, but the descriptions
overlap and it's not obvious how to choose among them. Man
pages seem passe, is there some other guidance? 

Even if one knows which to select and build from ports the
make install command doesn't really install; the admin still
has to know what files to copy where. Your instructions for 
the task have been noted and saved, but even then it's very
easy to make mistakes that are hard to recover from.

Does pkg handle u-boot and firmware updates more automatically?
Alternatively, is it feasible to update u-boot and firmware with
an "installboot" target, either from the port directory or /usr/src?

Thanks for reading, and all your help!

bob prohaska

[big snip]


From nobody Sat Apr  9 16:56:28 2022
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 7C4AF1A95BC4
	for ; Sat,  9 Apr 2022 16:56:30 +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 4KbLqd3RHJz3D1t
	for ; Sat,  9 Apr 2022 16:56:29 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 239GuTRo055770
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 9 Apr 2022 09:56:30 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 239GuT37055769;
	Sat, 9 Apr 2022 09:56:29 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 9 Apr 2022 09:56:28 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: Andrew Turner , bob prohaska 
Subject: Re: RPI4 panic on boot with -current
Message-ID: <20220409165628.GA55743@www.zefox.net>
References: <20220409015321.GA52002@www.zefox.net>
 <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
 <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
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: <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
X-Rspamd-Queue-Id: 4KbLqd3RHJz3D1t
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.93 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.83)[-0.826];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 399
Lines: 12

On Sat, Apr 09, 2022 at 09:00:36AM -0500, Mike Karels wrote:
> On 9 Apr 2022, at 6:46, Andrew Turner wrote:
> 
> > Does the patch in https://reviews.freebsd.org/D34858 allow the system to boot? The EFI runtime services may not work, but it should stop the panic.
> 
> It works on my RPi4 (original 4 GB model), which had the problem too.

Also seems to work on my 8 GB model.

Thanks!

bob prohaska

From nobody Sat Apr  9 18:04:24 2022
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 1556A1AAD7A3
	for ; Sat,  9 Apr 2022 18:01:43 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.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 4KbNGt3CsMz3N51
	for ; Sat,  9 Apr 2022 18:01:42 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ed1-x529.google.com with SMTP id c64so1344334edf.11
        for ; Sat, 09 Apr 2022 11:01:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=h0r5WOAe5kj4YjWQUEryvXsqmpbTClGk8tV3bd96tZg=;
        b=beoVOB1uLhBN8qmjT7HKM6UcAGTlVsxPYgWScbr4I2ohyhI6mc3qzEkhsLBolEokxA
         1WoG4TT02vDZtcfuF9t6h0upoz5VwbPutGDWVKmu9Z14TwGxRDBxlxDCeW5H2OCyNMn4
         y5SeyzEaGMJWX2iCTAM+IKzEAmAEDbOZwqXXvmwfZV3iQmVMnS/BQnimbr93F27gwSlr
         L6KrLMXG28MruklFIxcDjeGTDJVt2XdWaro4VNHohdEGCAf5oSt6+xoWz+Bhp35u7j48
         EYISq6nttzLl6WNvPjtSja2Vt/ZE8v5ATDcHu7wJkPX7wA29KndrL+qE3NE5XpyN+Wsz
         BYHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=h0r5WOAe5kj4YjWQUEryvXsqmpbTClGk8tV3bd96tZg=;
        b=TlUpB1ZBC3mKpcJWQw8Oeh6oOpz2rQCSgT+mtWAAhF35/7HUvbOAk5NA2CWEAgmzyY
         ZvqCs3yg2bomE26SkPOZCkVURF4qSJxoSzdUJRgBoKmbfYwbnbJEhvGuc+cfeG1Z+q1T
         lkbbcqpGbgeGKKltoaKlYAz4aPT5jSt+2KtO9M4EYHcgMhotu3TiHZIcrsj3kzEvQ4pC
         PcnGd7gwo5ytgP8z46Dx84X+YHcI+Spw8PAqnVMOBynulzdDAtVgEm+2gdO3YS4nMTkI
         6A/+aRqkh6qk91OcyF/ooku8wvYk/Y2tCHuPrsnkqmCj9Do90hTbZnpZnfw6+1dVYKof
         GguA==
X-Gm-Message-State: AOAM533DufLQBeGEqVKH/TT6lVWGiqgxsORhKJlVlgeuECae6vkCbklB
	XWqhKdZDZBkvZ61r0g5mQLgvZRb5XUoTHDiyvQFO0vAXHSw=
X-Google-Smtp-Source: ABdhPJz+xkX8J1qoahW4nzayAgRf7wKiT/PdHnPQzv/xCy+YZ5s2lTYdPIskp2JkzLEEdd79O5l7JliEWVC6+TWUTks=
X-Received: by 2002:a05:6402:4247:b0:419:3990:3db6 with SMTP id
 g7-20020a056402424700b0041939903db6mr24822126edb.193.1649527301139; Sat, 09
 Apr 2022 11:01:41 -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
From: Archimedes Gaviola 
Date: Sun, 10 Apr 2022 02:04:24 +0800
Message-ID: 
Subject: Raspberry Pi 3B Over-current USB
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d4f22b05dc3c8026"
X-Rspamd-Queue-Id: 4KbNGt3CsMz3N51
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=beoVOB1u;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 16354
Lines: 315

--000000000000d4f22b05dc3c8026
Content-Type: text/plain; charset="UTF-8"

 Hi,

I have a Prolific PL2303 USB-serial device when plugged-in to my Raspberry
Pi 3B (14.0-CURRENT) will cause an over-current situation (enabled USB hub
debugging hw.usb.uhub.debug=1) as observed in the dmesg below. All 4 ports
got no power hence my USB keyboard was disconnected and stopped functioning
and my PL2303 device wasn't able to get detected and load its uplcom(4)
driver. However, the network is still okay in which I am able to access the
system over SSH.

ukbd0:  on usbus1
kbd1 at ukbd0
lo0: link state changed to UP
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP
uhid0 on uhub1
uhid0:  on usbus1
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
uhub_explore: Overcurrent on port 2.
uhub_reattach_port: reattaching port 4
ugen1.4:  at usbus1 (disconnected)
ukbd0: at uhub1, port 4, addr 4 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
ukbd0: detached
uhid0: at uhub1, port 4, addr 4 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
uhid0: detached
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=0xffff000089390000

Here's also the USB device info of my PL2303 device.

root@generic:~ # usbconfig -u 0 -a 5 dump_all_desc
  ugen0.5:  at usbus0,
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x067b
  idProduct = 0x2303
  bcdDevice = 0x0300
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0000  
  bNumConfigurations = 0x0001

 Configuration index 0

    bLength = 0x0009
    bDescriptorType = 0x0002
    wTotalLength = 0x0027
    bNumInterfaces = 0x0001
    bConfigurationValue = 0x0001
    iConfiguration = 0x0000  
    bmAttributes = 0x00a0
    bMaxPower = 0x0032

    Interface 0
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0000
      bNumEndpoints = 0x0003
      bInterfaceClass = 0x00ff  
      bInterfaceSubClass = 0x0000
      bInterfaceProtocol = 0x0000
      iInterface = 0x0000  

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  
        bmAttributes = 0x0003  
        wMaxPacketSize = 0x000a
        bInterval = 0x0001
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0002  
        bmAttributes = 0x0002  
        wMaxPacketSize = 0x0040
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 2
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0083  
        bmAttributes = 0x0002  
        wMaxPacketSize = 0x0040
        bInterval = 0x0000
        bRefresh = 0x0000
        bSynchAddress = 0x0000

I'm using a USB port measuring device that can check the voltage and
current usages and by default (without any USB devices attached) each port
reads as 5.15 volts and 0.00 amperes for current of 3B. I'm using the
official Raspberry Pi Stontronics power adapter with 5.1V with 2.5A DC
output https://docs.rs-online.com/0c30/0900766b814dc7bb.pdf. From here due
to over-current, I cannot obtain the actual power consumptions specific to
my PL2303 device so I try installing the latest Raspberry Pi OS to check if
it behaves the same. I found out that it has a similar behavior and
experience getting over-current with additional under-voltage detected
messages. However, it's interesting to observe that even in an over-current
and under-voltage experience, all the ports are re-powered up and
functioning and then able to load the PL2303 driver and I am able to use it
via /dev/ttyUSB0 device. This time I could see the measuring device giving
a 4.93 volts with 0.46 amperes of current (460mA) in the PL2303 device (see
captured measurement here https://filebin.net/kqq664yf9w70omnh). Below is
the dmesg log I've got from RPi OS.

[ 7490.507686] usb 1-1-port2: over-current change #3
[ 7490.722717] usb 1-1.2: USB disconnect, device number 5
[ 7491.006607] hwmon hwmon1: Undervoltage detected!
[ 7491.094482] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
[ 7491.198613] usb 1-1.5: New USB device found, idVendor=067b,
idProduct=2303, bcdDevice= 3.00
[ 7491.198676] usb 1-1.5: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 7491.198700] usb 1-1.5: Product: USB-Serial Controller
[ 7491.198722] usb 1-1.5: Manufacturer: Prolific Technology Inc.
[ 7491.200210] pl2303 1-1.5:1.0: pl2303 converter detected
[ 7491.206808] usb 1-1.5: pl2303 converter now attached to ttyUSB0
[ 7491.209222] usb 1-1-port2: over-current change #4
[ 7491.646484] usb 1-1.2: new low-speed USB device number 8 using dwc_otg
[ 7491.770462] usb 1-1.2: New USB device found, idVendor=09da,
idProduct=2267, bcdDevice= 1.05
[ 7491.770515] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 7491.770539] usb 1-1.2: Product: USB Keyboard
[ 7491.770560] usb 1-1.2: Manufacturer: A4Tech
[ 7491.793771] input: A4Tech USB Keyboard as
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:09DA:2267.0004/input/input6
[ 7491.852612] hid-generic 0003:09DA:2267.0004: input,hidraw0: USB HID
v1.11 Keyboard [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input0
[ 7491.875068] input: A4Tech USB Keyboard as
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:09DA:2267.0005/input/input7
[ 7491.935697] hid-generic 0003:09DA:2267.0005: input,hidraw1: USB HID
v1.11 Device [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input1
[ 7495.038507] hwmon hwmon1: Voltage normalised

Though this experience is specific to the Raspberry 3B case, is there a way
to enable this in FreeBSD? Knowing that there is dropping of voltage to
4.93 volts and current is 460mA which is still below the maximum of 500mA?

Thanks,
Archimedes

--000000000000d4f22b05dc3c8026
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




Hi,

I have a Prolific PL2303 USB-serial=20
device when plugged-in to my Raspberry Pi 3B (14.0-CURRENT) will cause=20
an over-current situation (enabled USB hub debugging=20
hw.usb.uhub.debug=3D1) as observed in the dmesg below. All 4 ports got no=
=20
power hence my USB keyboard was disconnected and stopped functioning and
 my PL2303 device wasn't able to get detected and load its uplcom(4) dr=
iver.=20
However, the network is still okay in which I am able to access the=20
system over SSH.


ukbd0: <A4Tech USB Keyboard, class 0/0, rev 2.00/1.05, addr 4> on usb=
us1
kbd1 at ukbd0
lo0: link state changed to UP
smsc0: chip 0xec00=
, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed t=
o UP
uhid0 on uhub1
uhid0: <A4Tech USB Keyboard, class 0/0, rev 2.=
00/1.05, addr 4> on usbus1
usb_needs_explore:
usb_bus_powerd: bus=
=3D0xffff000089390000
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff=
000089390000
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000089390=
000
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000089390000
us=
b_needs_explore:
usb_bus_powerd: bus=3D0xffff000089390000
uhub_explor=
e: Overcurrent on port 2.
uhub_reattach_port: reattaching port 4
ugen=
1.4: <A4Tech USB Keyboard> at usbus1 (disconnected)
ukbd0: at uhub=
1, port 4, addr 4 (disconnected)
uhub_child_location: device not on hub<=
br>uhub_child_pnpinfo: device not on hub
ukbd0: detached
uhid0: at uh=
ub1, port 4, addr 4 (disconnected)
uhub_child_location: device not on hu=
b
uhub_child_pnpinfo: device not on hub
uhid0: detached
usb_needs_=
explore:
usb_bus_powerd: bus=3D0xffff000089390000
usb_needs_explore:<=
br>usb_bus_powerd: bus=3D0xffff000089390000
usb_needs_explore:
usb_bu=
s_powerd: bus=3D0xffff000089390000

Here's also=
 the USB device info of my PL2303 device.



root@generic:~ # usbconfig -u 0 -a 5 dump_all_desc
=C2=A0 ug=
en0.5: <Prolific Technology Inc. USB-Serial Controller> at usbus0, cf=
g=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)
=C2=A0 bLeng=
th =3D 0x0012
=C2=A0 bDescriptorType =3D 0x0001
=C2=A0 =
bcdUSB =3D 0x0200
=C2=A0 bDeviceClass =3D 0x0000=C2=A0 <Probed=
 by interface class>
=C2=A0 bDeviceSubClass =3D 0x0000
=C2=A0 bDeviceProtocol =3D 0x0000
=C2=A0 bMaxPacketSize0 =3D 0=
x0040
=C2=A0 idVendor =3D 0x067b
=C2=A0 idProduct =3D 0=
x2303
=C2=A0 bcdDevice =3D 0x0300
=C2=A0 iManufacturer =
=3D 0x0001=C2=A0 <Prolific Technology Inc.>
=C2=A0 iProduct=
 =3D 0x0002=C2=A0 <USB-Serial Controller>
=C2=A0 iSerialNum=
ber =3D 0x0000=C2=A0 <no string>
=C2=A0 bNumConfigurations =
=3D 0x0001

=C2=A0Configuration index 0
<=
br>
=C2=A0 =C2=A0 bLength =3D 0x0009
=C2=A0 =C2=A0 bDes=
criptorType =3D 0x0002
=C2=A0 =C2=A0 wTotalLength =3D 0x0027
=C2=A0 =C2=A0 bNumInterfaces =3D 0x0001
=C2=A0 =C2=A0 bConf=
igurationValue =3D 0x0001
=C2=A0 =C2=A0 iConfiguration =3D 0x0000=
=C2=A0 <no string>
=C2=A0 =C2=A0 bmAttributes =3D 0x00a0
=C2=A0 =C2=A0 bMaxPower =3D 0x0032

=C2=
=A0 =C2=A0 Interface 0
=C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0009
=C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0004
=C2=A0 =
=C2=A0 =C2=A0 bInterfaceNumber =3D 0x0000
=C2=A0 =C2=A0 =C2=A0 bA=
lternateSetting =3D 0x0000
=C2=A0 =C2=A0 =C2=A0 bNumEndpoints =3D=
 0x0003
=C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <=
;Vendor specific>
=C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D =
0x0000
=C2=A0 =C2=A0 =C2=A0 bInterfaceProtocol =3D 0x0000
=C2=A0 =C2=A0 =C2=A0 iInterface =3D 0x0000=C2=A0 <no string>
=


=C2=A0 =C2=A0 =C2=A0Endpoint 0
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 bLength =3D 0x0007
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bDes=
criptorType =3D 0x0005
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddre=
ss =3D 0x0081=C2=A0 <IN>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttr=
ibutes =3D 0x0003=C2=A0 <INTERRUPT>
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 wMaxPacketSize =3D 0x000a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInt=
erval =3D 0x0001
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bSynchAddress =3D 0x0000
=C2=A0 =C2=A0 =C2=A0Endpoint 1
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 bLength =3D 0x0007
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptor=
Type =3D 0x0005
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddress =3D =
0x0002=C2=A0 <OUT>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttributes=
 =3D 0x0002=C2=A0 <BULK>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wMaxPa=
cketSize =3D 0x0040
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterval =3D 0x0=
000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 bSynchAddress =3D 0x0000

=
=C2=A0 =C2=A0 =C2=A0Endpoint 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bLengt=
h =3D 0x0007
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x00=
05
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddress =3D 0x0083=C2=A0 =
<IN>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttributes =3D 0x0002=C2=
=A0 <BULK>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wMaxPacketSize =3D 0=
x0040
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterval =3D 0x0000
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 bSynchAddress =3D 0x0000




I'm using a USB port measuring device that ca=
n
 check the voltage and current usages and by default (without any USB=20
devices attached) each port reads as 5.15 volts and 0.00 amperes for=20
current of 3B. I'm using the official Raspberry Pi=20
Stontronics power adapter with 5.1V with 2.5A DC output https://docs.rs-online.com/0c=
30/0900766b814dc7bb.pdf. From here due=20
to over-current, I cannot obtain the actual power
consumptions specific to my PL2303 device so I try installing the latest
 Raspberry Pi OS to check if it behaves the same. I found out that it=20
has a similar behavior and experience getting over-current with=20
additional under-voltage detected messages. However, it's interesting t=
o observe=20
that even in an over-current and under-voltage experience, all the ports=20
are re-powered up and functioning and then able to load the PL2303 driver a=
nd I am able to use it via /dev/ttyUSB0 device. This time I could see=20
the measuring device giving a 4.93 volts with 0.46 amperes of current (460m=
A) in the PL2303 device (see captured measurement here https://filebin.net/kqq664yf9w70omnh). Bel=
ow is the dmesg log I've got from RPi OS.


[ 7490.507686] usb 1-1-port2: over-current change #3
[ 7490.722717] usb =
1-1.2: USB disconnect, device number 5
[ 7491.006607] hwmon hwmon1: Unde=
rvoltage detected!
[ 7491.094482] usb 1-1.5: new full-speed USB device n=
umber 7 using dwc_otg
[ 7491.198613] usb 1-1.5: New USB device found, id=
Vendor=3D067b, idProduct=3D2303, bcdDevice=3D 3.00
[ 7491.198676] usb 1-=
1.5: New USB device strings: Mfr=3D1, Product=3D2, SerialNumber=3D0
[ 74=
91.198700] usb 1-1.5: Product: USB-Serial Controller
[ 7491.198722] usb =
1-1.5: Manufacturer: Prolific Technology Inc.
[ 7491.200210] pl2303 1-1.=
5:1.0: pl2303 converter detected
[ 7491.206808] usb 1-1.5: pl2303 conver=
ter now attached to ttyUSB0
[ 7491.209222] usb 1-1-port2: over-current c=
hange #4
[ 7491.646484] usb 1-1.2: new low-speed USB device number 8 usi=
ng dwc_otg
[ 7491.770462] usb 1-1.2: New USB device found, idVendor=3D09=
da, idProduct=3D2267, bcdDevice=3D 1.05
[ 7491.770515] usb 1-1.2: New US=
B device strings: Mfr=3D1, Product=3D2, SerialNumber=3D0
[ 7491.770539] =
usb 1-1.2: Product: USB Keyboard
[ 7491.770560] usb 1-1.2: Manufacturer:=
 A4Tech
[ 7491.793771] input: A4Tech USB Keyboard as /devices/platform/s=
oc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:09DA:2267.0004/input/input6[
 7491.852612] hid-generic 0003:09DA:2267.0004: input,hidraw0: USB HID=20
v1.11 Keyboard [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input0
[ 74=
91.875068] input: A4Tech USB Keyboard as /devices/platform/soc/3f980000.usb=
/usb1/1-1/1-1.2/1-1.2:1.1/0003:09DA:2267.0005/input/input7
[
 7491.935697] hid-generic 0003:09DA:2267.0005: input,hidraw1: USB HID=20
v1.11 Device [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input1
[ 7495=
.038507] hwmon hwmon1: Voltage normalised

Though
 this experience is specific to the Raspberry 3B case, is there a way to
 enable this in FreeBSD? Knowing that there is dropping of voltage to=20
4.93 volts and current is 460mA which is still below the maximum of 500mA?<=
/div>

Thanks,
Archimedes





--000000000000d4f22b05dc3c8026--

From nobody Sat Apr  9 20:29:00 2022
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 F24A11AA8EC6
	for ; Sat,  9 Apr 2022 20:29:34 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KbRYV0TsFz4Rt8
	for ; Sat,  9 Apr 2022 20:29:33 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id 5F71C4E6E6;
	Sat,  9 Apr 2022 20:29: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 \(3696.80.82.1.1\))
Subject: Re: RPI4 panic on boot with -current
From: Andrew Turner 
In-Reply-To: <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
Date: Sat, 9 Apr 2022 21:29:00 +0100
Cc: bob prohaska ,
 Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <47783138-7E34-4B60-936B-D53B413B9491@fubar.geek.nz>
References: <20220409015321.GA52002@www.zefox.net>
 <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
 <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
To: Mike Karels 
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Rspamd-Queue-Id: 4KbRYV0TsFz4Rt8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=fubar.geek.nz;
	spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz
X-Spamd-Result: default: False [-1.76 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 TO_DN_ALL(0.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.44)[0.436];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 437
Lines: 15



> On 9 Apr 2022, at 15:00, Mike Karels  wrote:
>=20
> On 9 Apr 2022, at 6:46, Andrew Turner wrote:
>=20
>> Does the patch in https://reviews.freebsd.org/D34858 allow the system =
to boot? The EFI runtime services may not work, but it should stop the =
panic.
>=20
> It works on my RPi4 (original 4 GB model), which had the problem too.

https://reviews.freebsd.org/D34861 should fix the EFI runtime services.

Andrew=

From nobody Sat Apr  9 20:37:24 2022
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 96B0E1AAA52D
	for ; Sat,  9 Apr 2022 20:37:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbRkp24R2z4Sqg
	for ; Sat,  9 Apr 2022 20:37:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649536651; bh=oMhvSOXdRiNa8pJtZXIYUT7zGd87JRs6apqdU9+bAoM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kchKr4SzW/3UgVqaVLfMsmSslml020aiEdzLi9OCISaKSP46pVn7DZF+fgpxOCHf8tpLh0qkA4q5gu66CrcMX43ufpccfshWiU7+nFTeIsmEw97z1dBnPrzbIWKj0sp+yr06Rcqr6Mb8QFrQVJ9940OxouJnndOd3a9Alclao8lxcrE6XEsVtNpn9RyR79LguJOcUjFuKoxEhHTbAt1EO+kg1Hnyg/V/GIPQT47BYMFHU0G4M+m3l0pxEV5nfRpRAiU70YBc3VcnYpzwsHEjft/hzdklv6qSOncd/LI3tGnVOhmimumCdacH17up6GCdaZfsYlcN1wbi+bKCeib4Fw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649536651; bh=ymAW/rBimK+nM0/hZ6gS3TOW4/FeKWy36ldqvvPi3ot=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=owlhLqk73jvslrQ1ojNGAcFynLyKixBJFVAA4EMOtBu6VPm8QsVLk3cuzUl894pJJYvKkeu+djAYxAS9iS9ZHmDTB9M6mpgcsVh9UMet1V3ZCD2BH6WbXMbKq1nfv0IKKsQGhUOTi/MS/Aq49ndRFd/OVVnn/0OCwlUleSM9dXulCd2mcv3vxQmy4awvni4FEzZ4GbfGAELXjePVUF+uL9tNx+JoWAQoYwsAeIE0mPuX2oovwJXEdN9byeSwmVtGUJ+4cPUmPS9ROLX4PAwC4SrEQytw/HJ7C2r2pxZ/n6n2zNfbmHP5IEENU4swCdDJby9IcFK2hic6Ru2GQPbRSw==
X-YMail-OSG: wdLjQBIVM1nVc7eGLbLDb69qsWLXTDsrh7IdaciC71w_f7ugEBcJdaWb09JSXXv
 ng_150bE7.fpdCJ.zkKZkiplf5xHZFZs.iyzLzo_HLUP.yv8LXX1giHNsMJBryJez_whxgL2fSgK
 7dnvFFR.VLfox42WDbGmDp_3Ew4y9eiav.FN7iUvJJzki4aB.oXRVTwi9uRmVgOgDbbyAf1K.QIk
 fhz6NLZbwt4TyIPjnB2vHv_NGjEzPUS7Lv3Q04F_T_o1n8PEeVi8ydWDLGht3E3r.8zehxtM.glV
 GFf2x6bLXXcEeXjkv6XxEYlqcHaDxXibNDZPvZbIo6Lye1yV3DsKI3RsDVMcnxViJjAUoUPvS6I0
 F8Zx5WnPXsxlMb4pD5PnoycAGGamo6xcoTLUEL9TqRL.QSJQ2kwciS7.VyEAsveyiyhCAUaPaLCB
 OU4_qoIgKQqowItlt5RaQhE_jAYJwSTsapPGzuJY0CREq5ZWKZ075lGENk.qqTYBtpY31YAdv2kn
 XRYQfCE50LbHjuVyTYaxSjIToxtIctCLlUZ2l_fYZjNRFdQCdOQBIlSmrxIOM5i3XmEUCdoxSggk
 O2RXcvByKHa4B1bDaakOk8GN2p7oPYiCg7r8UYeuc9grNFVjgDM053DGuIWPid.sQgg8zBjR2c4a
 0ddNIZH3JKIkcrEGtCRN8tG3V3jgnygRVXwd6Hm9mkxKNmqyO1nYuav8JhT0Id4OPzweGJO1vZXf
 EduGBrPvtfyu6qY9zBO.YD9n5dTFbQsdyyBt7DaaIuzGNPbEt.ZWx5jJyyi8w.un5UScvlV4S_Xa
 oD66YOhvGY3DdcI3ZzODFfbFX1EFRUWm_7nc7me4jE3yGgrEDJj7xXmVaNXcIH3.k5hIYVKMDEjI
 pdN.U5DwRIiur9UueT9MMO7zLBFG6dLxoAk9Ff8PNf_Aoz53QGYhOHo0O9dC.emYkDEwaqbctk4n
 OuWsylfmxpRJEMgdo9Bc8Ad8qfWaFVwbLPFoMvQSUO9E7k_DXoPfa5aYcxQCccGINNSMBqC.H3xj
 m8NR6YldQSTDfuTgZRKPLMTbXsDatzLQZOHniLlpXELCQpMEUszOLKZSRZ4xjD9NVlwexvp4bO5O
 gRIpq19QIUhxbPFNX3URjAmjFsP6V1.pKYERon7zD_0Q6hO2YVU0XLZyxQNwa3v2bGm7xPizwG_x
 xELVkQrZRVn28gTdyEDdF7sblrGfCh4l5QjFW1n.QzfpxdVgp0dKX1OasmhrKp9V_Utk9Nskh9aS
 oWXeuFeVXVjJeGzejzZEguCrlWhitkhsKoklw29NT32pzHHIrWe4BOi4euHYe_OgaZFI4xxWuLbV
 Bh4vBKAz008BPrf_o24BjTcvAYGiYChYXbKXFBEqrXVh0112V2JNsves6IFnXrEnBAVbnMsVrt1y
 F253hKPk0ovRjGPpk_cf2eDMW6BqW9L3zciKka3TXBlLeFixDwUPwAGTB4O3KhCS5m6E4UJS0_xG
 tldb7aNnL4hFnWxnD32Gi29w1mi4QOTb992kYD8RSLj25rM4jnpvWDjqnN_bmI2fonH.eL9VqoQD
 vysh3oNjX1R4de4GkHwjsGhZr3mUKDklWBi0wqwyL.wPd6hAo44jyS_oaXO4DtjC9eCLWV33poiR
 I9djG1oaaqQMMS9IqaPGwHXdp0zF4zrc3qIoRkahII_qd8tQvb9.8gSp3HzXGU5rgRk4osaZf885
 x6hQ3utoJ6gnjDQDynX_XLDMFOFcclh6M9a2i0JRBMSd5FRWXsil_a1u6w67X_q.Pt7cDd4xK9e6
 WQzpSnSe9x.2I135Dst36_CD29Gr8qJEb5SbuCgZReGvKw.gfyvGpKoViTWLiB00qDpAXRmJw84c
 X0Q1dGIOCtW8iWENcSXHTSu24iS4uX8h97xEzVo3UELnObwdHwFKeAd1yntpn6yqbzVL2ZOhd5nH
 35n.Ydu7kzHQhfOwZ9DknFE68.MXJNZ_lTqCwS.I8aNgRxGLSK._DDU6mWblkrF5y0jOLUbwB4g8
 ooJWnPfWCPFHRyxrwiedyAIdb2loXI35nsyTyvT_UJK1zQecVVbGz65SyPCbHjhXWG3LbXmd6VvA
 GqQUF9NsyXxLrxl9Q9WlyUGn2DH0wA_Y5ZoihzwLJpPYVNRf9H3YMN9stjpvRx4nc0_LGDczCldN
 2pbK7Bi7rdhejzBUhG0zUb9d0ko5RZXxkXwDH6XduzY6Z5nsD2fX.1Y_x8N4y6q2NS3q7VlP4FKS
 vnuyUUkLOvtFCyYOeK6SCZ2P05KFLgmwjdnOEpvxWgbtZFp1TY1XpAgQDHANPXmGDwb_pE2b.65n
 wZkvCdzDKqA53FnnQh.ruYiA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 20:37:31 +0000
Received: by kubenode527.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12b666cd54d983777e52d819a3cef342;
          Sat, 09 Apr 2022 20:37:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Rpi3 panic, data abort with spinlock held on -current
From: Mark Millard 
In-Reply-To: <20220409150242.GA55458@www.zefox.net>
Date: Sat, 9 Apr 2022 13:37:24 -0700
Cc: Free BSD 
Content-Transfer-Encoding: 7bit
Message-Id: <38809217-92FE-4A3C-9618-14186F466341@yahoo.com>
References: <20220408230853.GA51713@www.zefox.net>
 <0E6E478E-2644-4EF4-B750-AB6CC5DD7AF7@yahoo.com>
 <88ca08fe-88ef-8ef2-a3e6-da13e068af74@selasky.org>
 <20220409150242.GA55458@www.zefox.net>
To: bob prohaska ,
 Hans Petter Selasky 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KbRkp24R2z4Sqg
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=kchKr4Sz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.85 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.35)[-0.349];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 917
Lines: 29

On 2022-Apr-9, at 08:02, bob prohaska  wrote:

> On Sat, Apr 09, 2022 at 09:47:34AM +0200, Hans Petter Selasky wrote:
>> On 4/9/22 02:15, Mark Millard wrote:
>>> generic_bs_rr_4() at generic_bs_rr_4+0xc
>>> dwc_otg_interrupt_poll_locked() at dwc_otg_interrupt_poll_locked+0x69c
>>> dwc_otg_filter_interrupt() at dwc_otg_filter_interrupt+0x130
>>> intr_event_handle() at intr_event_handle+0xf0
> 
>> 
>> Is it possible to get and verify the arguments for generic_bs_rr_4() ?
>> 
>> My guess is that the destination buffer is no longer available.
>> 
> 
> That particular panic hasn't repeated, yet. If it does repeat I can
> try with sufficient instruction. 
> 

I do not know if just working from the ddb> prompt would be
sufficient. May be code changes are needed to set up the
context to examine? If so, then getting those in place would
be appropriate.


===
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 20:59:10 2022
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 DDE141AAEC54
	for ; Sat,  9 Apr 2022 20:59:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbSCs4KXPz4WHt
	for ; Sat,  9 Apr 2022 20:59:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649537954; bh=CiEqIBYBtN3xWxd9ethkOvB7lu9yn9uycOC1q/qNhIQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=egTDR51T3ZfyKjNItjG7DRfx1o7C4wlfm8yv1r+P2xbvHEYDbl/D/Zwp00WUeLyNmmp+N8LISmF9bLMf5xiSvg63gm+w9OW5vjSBnErwBdhbmJh0G5/Fx+BM6gK7KiY0w8XLfq9+HLDQhyUu45mMvrDew0ZoSQBKEE4+zCIeXU9Zvlxy7Hr9UEzYIHaaYLcM7gsBFWpEPu0FfgFmcfJI0vUednKt5pVKq2QnWbKXZSaAZxEgj+8MXP6NF2cTTEVIHEyQaaya+cIoEGGX4nYl+e/8WJxaL5msib84qAUyyPrCs7kjD8mnbvQSESW/4pP4HPfo2m25zUkgTx99e3OLbA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649537954; bh=+RaDk6OelRuZR8Qnz4BqG+oAX82HEV1mArTwClJi1HV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZReHR889j9FxPAHgvVXk12p1T2nSwQ+4vY7qDBTYMg7ZxqepaUec/maUTCHtqUPrlYEoLZ9d4i4gWixwZ7vBKPoNP2HujNSJxWKvlJz3aodXDIr2r3Cftnec8NYw0ev8W8BdcnJuUhtmiiixCQTISPE/QzY7b6DPNtjHV8yOMDf5KBvY0UXuhNH7iOyE8sda0PwRKqoqehaaQU8zo0lXPx1eNHN29RrxrxZ4eVTDY+g2dpDMCLh0mdWo6XWVGGiFQN1teS/ko8MTwdbQuNmd3ZZ23RdddXnp43YfEcmCumx1Kerliq5kUP67u06/SH6PbkeyS9FOhqqYShGqZQg0kw==
X-YMail-OSG: dcuIA38VM1kz1yMkOmG.YCUQ9EqGIpZSTJJdcS_gFZtYUbsnhPgC_mDQLmknVdI
 0V6RqVFXlAehO0D9kyYe6Al8uo7964T6Gd5hV9iQrAzT3dlDl7O.dbDrcyl8XgLQIa7jGBMnmIQV
 Q0yfceu2ODBI0glXw9leBF3g6fQzAjozwPRzSV3jsXmJAV5h_rweXsTuHltoaPcjOid9djF6W2bV
 PYykOyJwRyEBpkQAE27Drv75qNTuB5my0rClcz72I70LSpRePVtnpqj70KNZwrJGXV3TJHPVSPqJ
 HWJdmQiM9U0zdbGmsn7F2PEcxITaxIiGLqs2EfDzJFwD7uM7p_6Sx0SnH_YpsmEyt0REUOXBcv_r
 iYlTaO8qvc0joYhrgrscHd6LWoB4ltIhfuRFZk_N.1moEhSowdOilRRoD.ik9yEVix4nKAXyoVYc
 2EppaSzJL5nLlrMpWxbLf5hz5w5JPOSgsBAgKhV_AWXtj99llLdoZrJMTzmRW5pvAN.JgwdR8Dip
 PU2s5aTDq.qBxpeLkNgfPD6YDr1WCVCQVBR8RQJ4GCsUNtNTeACW8dh.lETv5WUqtsx9qVmFShZT
 F0BDD.r8ZHvSJRh.8sUOWDW30FU2ula3F3iC.MZbqfi2l3MKPveB_JQ_wLvlmE_PLe0TlrhrjW9e
 Ou.2NxjfOAI25vHJhOSLjWTIcJ9CZTLoi0r3n0ufA3vuYGYY62QKvG585QyMAIp9V8jrfty6GH_M
 gGgBKSscL08H4KV2RSnPgYlYef6IqKIfeHuBPId1xHyUIQXJwOVjtw51_B49sD2mjtCGmWQD0zCl
 cR5Y_QpD2tZSksL.VT2Z0T8UKFE1LHtUYeXiz0NefvD0iw4XRr0cCrn5tvLtMmH9ICj_RCQwM_OA
 zP5KpkXLrZYIzpN0TfW6gP.dDz4r1PGoeliv.L9XJ2sJ4Agg92aXmOV4Ksd5SzhkXEVCRJ2a8z0J
 n_pve.Y_UCRi.yHAEABLzyXNzRO7iesCUksjzENOQkPIjL5mZ9rciKUmtubEMks4gFTN5B2BTsvA
 SbRCWniI7gSgBmXjU3Zyo6_ZTvu41YYIIctMMkeMQAfyuO5vkhk5uNtH3CmS.BMfGvXlvFjcm9ui
 NKZCDUpm_xGhc1cocCOxVFcJEKKBMVF3Vd._mf0AtDMWtEXnTarOQ5xhUsnbqwlzMgCM1OOXRpDz
 3HHAToZgrOhPS6fhkPlnzg32CvtPttTUWzXsHxQlZl0LbKNLlTM34TuY2kxRTVFUpk5RC3iaHW8s
 KhpALS5Prg.JYXCMIjNczKkcMv80SHqseTCEu6tIPYq0xHh0_pCMdxSxc_Nt922dniw_JbwW4v6L
 sVcWEZ4cRh9CTog2dWj5zlh__HhQ0QoLhkZOHNSdzgAZjlEgQbukRCPgNh_6K54Ie9lnsYIHVUSj
 XxY6BigwG6_xaPbB5h3ZhN82sFmvDjGTfTrj7N.1cALYG.r0NLNiwZ_JwwMocTUS_0k7RMEPBz96
 Olwnupi4wHJh.BAD31X6IkUFLZ3ZBCvuZaZXqC8u6kga1uJMneYmuUxNFhZ3yDHpCIsLWmQLgxIF
 3JrXOKyNk0oK4WmQZWh8QlW6GCpgQufQlUx3BHk4MlhxbQ.oixbQsNwAeLOiiV9vQhYGWLHZ4vrU
 vULckCUedlKJx7xvdsD787CsguQfGw98qfITvWwhEIP61s6tmIypBTR00Dr5XGVn2Vnf4tuT.8Kg
 OhT4l7anoKDGAsV9hdl_o4qMBY6J.l7eKR2iIbk50J.XdoiREdXw6cOfUZukXfr.5ffX1jo9VkbM
 U4ymsNMft6JFCGSIF0wh_KXYgzTOZWjBFkB8YGx5PvpScrVG1wa4xRlhgBOdRDD_U4vk2i62_GBx
 QzFrQo.NDCveeIAWkwQiowdVhkzhAe_LpowubxvOGrQ8B6_SjcIDYczZrLKR2QWArcdKYaqy7hPl
 onKnzdliWeHEV_WQD0oZrCc_JGzTSx4RuivxOKKtuoPl5mHgBNss5U7OhdrWIaZseFQHwy6siY8l
 EmYNyHHN4UXe0sfNIZUQIC34fRJ.WIz_645EyXG2B6D520Pr_C8UogikKfPVBX65th6gQ9L4kr3g
 1pvo_ZjIThBLxSs_pM58uHIbACtE2G2H16fY4ogwwNVU0cL1Nvlgo5jiPaCdm7EzzPW5C6pcG0Rc
 anvLHumloNLo1PMiloU.5.Jo29NOphfWV2Avmz6MdENS2XUw3sUU_Swgy6ahfcmNMeNm6vdHttIk
 wIVW4Dd24i1NuqAOWBbkf8PZW_Fc4FUlwDJM7YZNYypgPy8Y9d0Dz4P1Vsz2B2IWvCeijIiQkDoV
 VOGVBGol3fiNKS8zSrg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 20:59:14 +0000
Received: by kubenode532.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 51da6c2c31be77538051761bad73d845;
          Sat, 09 Apr 2022 20:59:12 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPI4 panic on boot with -current
From: Mark Millard 
In-Reply-To: <20220409154433.GB55458@www.zefox.net>
Date: Sat, 9 Apr 2022 13:59:10 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KbSCs4KXPz4WHt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=egTDR51T;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.45 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.98)[-0.981];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.972];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3217
Lines: 92

On 2022-Apr-9, at 08:44, bob prohaska  wrote:

> On Fri, Apr 08, 2022 at 07:46:57PM -0700, Mark Millard wrote:
>> On 2022-Apr-8, at 18:53, bob prohaska  wrote:
>>=20
>>> Might this be related to "RPi4B's got a PMIC replacement,..." =
reported 4/3 ?
>>=20
>> No: See the later note about the RPi4B Revision.
>>=20
>>> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh =
build of=20
>>> -current reports:
>>>=20
>>> Resetting system ...=20
>>>=20
>>> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
>>=20
>> This is an old U-Boot compared to sysutils/u-boot-* .
>> There may well be good reasons for using it, for all
>> I know.
>>=20
>=20
> Only the most universal reasons: Inertia and ignorance 8-)
>=20
> There are many versions of u-boot for rpi boards, some of=20
> which are rather ambiguously named; u-boot-rpi-arm64 versus
> u-boot-rp4 is a good example.

u-boot-rpi-arm64 handles various RPi4B's, RPi3*'s, and, if I
remember right, RPi2B v1.2's. This is what snapshots and
BETA and PRERELEASE and RELEASE builds use these days.

The older ports are more specific, as I understand:

u-boot-rpi4 does not handle RPi3*'s or RPi2B v1.2's.
u-boot-rpi3 does not handle RPi4B's.

So the usable-contexts do overlap. Technically. there is no
unique answer to which to use.

> It appears the pkg-descr files
> have been updated since I last looked, but the descriptions
> overlap and it's not obvious how to choose among them. Man
> pages seem passe, is there some other guidance?=20
>=20
> Even if one knows which to select and build from ports the
> make install command doesn't really install; the admin still
> has to know what files to copy where.

With good reason for where: the msdosfs file system is not part
of FreeBSD's file systems (UFS or ZFS) and there is no standard
mount point for the msdosfs in FreeBSD's file system.

The admin may well be able to set up scripts that match how they
have things configured.

> Your instructions for=20
> the task have been noted and saved, but even then it's very
> easy to make mistakes that are hard to recover from.

I suspect that you are referring to more than u-boot.bin above,
i.e., not just U-Boot.

Keeping a copy around of the last known-usable msdosfs content
before updating it is appropriate. The copy should be someplace
that can be used to replace any problematic update to the
msdosfs content.

> Does pkg handle u-boot and firmware updates more automatically?

No, with good reason for where: the msdosfs file system is not part
of FreeBSD's file systems (UFS or ZFS) and there is no standard
mount point for the msdosfs in FreeBSD's file system.

The admin may well be able to set up scripts that match how they
have things configured.

> Alternatively, is it feasible to update u-boot and firmware with
> an "installboot" target, either from the port directory or /usr/src?

No, with good reason for where: the msdosfs file system is not part
of FreeBSD's file systems (UFS or ZFS) and there is no standard
mount point for the msdosfs in FreeBSD's file system.

The admin may well be able to set up scripts that match how they
have things configured.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 21:41:53 2022
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 5633A1A894E5
	for ; Sat,  9 Apr 2022 21:42:04 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4KbT972X66z4cBZ
	for ; Sat,  9 Apr 2022 21:42:03 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 239LfsDU084545;
	Sat, 9 Apr 2022 16:41:56 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id eVHwD6L9UWI/SgEA4+wvSQ
	(envelope-from ); Sat, 09 Apr 2022 16:41:54 -0500
From: Mike Karels 
To: Andrew Turner 
Cc: bob prohaska , Free BSD 
Subject: Re: RPI4 panic on boot with -current
Date: Sat, 09 Apr 2022 16:41:53 -0500
X-Mailer: MailMate (1.14r5818)
Message-ID: <1A3CF73A-5B7A-415C-A676-111BC6FC0168@karels.net>
In-Reply-To: <47783138-7E34-4B60-936B-D53B413B9491@fubar.geek.nz>
References: <20220409015321.GA52002@www.zefox.net>
 <2679B86C-CB1C-44E8-A43E-C9E2533322B9@fubar.geek.nz>
 <428D955C-E775-4F34-A548-297CD89BD764@karels.net>
 <47783138-7E34-4B60-936B-D53B413B9491@fubar.geek.nz>
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: 4KbT972X66z4cBZ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-0.09 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[mike];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_MISSING_CHARSET(2.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[karels.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.39)[-0.389];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 545
Lines: 20

On 9 Apr 2022, at 15:29, Andrew Turner wrote:

>> On 9 Apr 2022, at 15:00, Mike Karels  wrote:
>>
>> On 9 Apr 2022, at 6:46, Andrew Turner wrote:
>>
>>> Does the patch in https://reviews.freebsd.org/D34858 allow the system=
 to boot? The EFI runtime services may not work, but it should stop the p=
anic.
>>
>> It works on my RPi4 (original 4 GB model), which had the problem too.
>
> https://reviews.freebsd.org/D34861 should fix the EFI runtime services.=

>
> Andrew

Boots on the RPi4, replacing the previous patch.

		Mike

From nobody Sat Apr  9 22:17:42 2022
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 BC5BC1A94A3D
	for ; Sat,  9 Apr 2022 22:17:42 +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 4KbTyF55zCz4mZS
	for ; Sat,  9 Apr 2022 22:17:41 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 239MHg65056672
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 9 Apr 2022 15:17:42 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 239MHgTQ056671;
	Sat, 9 Apr 2022 15:17:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 9 Apr 2022 15:17:42 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Subject: Updating RPi boot materials, was Re: RPI4 panic on boot with -current
Message-ID: <20220409221742.GB56550@www.zefox.net>
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@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: <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
X-Rspamd-Queue-Id: 4KbTyF55zCz4mZS
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.22 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.971];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_SHORT(0.29)[0.290];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 752
Lines: 21

On Sat, Apr 09, 2022 at 01:59:10PM -0700, Mark Millard wrote:
> On 2022-Apr-9, at 08:44, bob prohaska  wrote:
> 
 
> > Even if one knows which to select and build from ports the
> > make install command doesn't really install; the admin still
> > has to know what files to copy where.
> 
> With good reason for where: the msdosfs file system is not part
> of FreeBSD's file systems (UFS or ZFS) and there is no standard
> mount point for the msdosfs in FreeBSD's file system.
>
 
I must be missing something here. On the Pi2, Pi3 and Pi4 images
the msdos partition is always mounted at /boot/msdos with /boot
part of UFS and the msdos partition under it. Are you  referring 
to other platforms?  

Thanks for reading!

bob prohaska

From nobody Sat Apr  9 22:26:48 2022
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 9B6951A980BE
	for ; Sat,  9 Apr 2022 22:27:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbV922zL3z4pX1
	for ; Sat,  9 Apr 2022 22:27:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649543214; bh=oBxdQc1mM8OAIndJYps5dWnwSgBMeDYtKmyHIxQV714=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=trUCueeiPdPx0y1OJ8gQr7npTdXJ6wy+AF5V8HzTdrQBKTrwhF1oH/fZYRcapxcApzhAU3XShxRAX/brKWqBBuU5BX1QQ4VdiqJnm+FU4K8pbZTokVL7OB0kO0RUKe7TgJZ5/jEvbeNZgrLNSIE7CaF+VREJRZtiKfTHgF74UdHWb9RYSvUqzj6mqHShhJ24n6LEDMRmzj1WYGu8c6XIOerNGYJXFdgrAyTWIBUlU/rf6eL1BBTufbc7EXiUJw6HSSHQcIIJP1Pv51mWu98tiMOTyypjCcpte6oIWh3MDC5TRDMaYIkbqIrO2b5246cWbM7SzrZep287yr6yM52Klg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649543214; bh=biHBEmM+N+z/W1+VHBy/bFhBxu9RHa1x7PhSJdSfbuB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=V0jsyEO63ZU+thV16Bt/DMokb+anlLMuaj9Rh893qpvFKm1/z8yrMaK6R+UBnYOP+1WZVW+bvLwSpOTxxmg8CQQXbtnPzYQ45JrwpoLXNXDwMwUNKFYBENJktAWmu2mRjp35kew3Q9ivyi7Iwc9KNp6DZABXaVXNT73GAixptNOffgyyYc+9TXYJ3Arxt6kzcbEdAEmFB+0P8Ly6T9/rYqtBbVN7/0G89MIWeUyLdqqSqvTguQqLUZddWqOGeOq2KTG4r0sPAEyZ7ykPpNOp5W+OEGUHUIyU7nco1yaNotNb1RbbLvIKEcC9dxXfdZOMKjr74DGcAeNrxvX4zfRyHA==
X-YMail-OSG: ts9q5XQVM1mNmwpx0jvr.9gFDUJrL65PJ3HqtPf_S9jDHyrE_f3ki1otl.fDI9l
 zOwz0qg1JbRbJvfVMC1Ma79CLQZS4_NcW3EyF9Bu_uvcqQKV8P.DFjqOMphO8vF2jjnxrEsUMbMy
 DgyQ3jVY2nwrYfY.yhYue6nr_pTnpvVdZ1Uz1VZykz8Di0Fp3lmRVslCxKwkEL3c3gLUcNLTyYHV
 EmyNfKnRlaaFgxOmR34IozgRq.JwwEsy3PVfD.E9_uCEm1ndXo0oCsIvxth5zU7Se7pvKLK29e8R
 Tj0hol4K6KRHKSuRHfhm9IXMWixaeHAqgoel854FM7GapuRWVOyJySrwSFj8vuWI5H3cTQqwCCmH
 GStlDLMHnX6.S8tak7ASzM6RTt0fKeo4MtRr2ZFTfkYcRS6ALwtXpClyzmd9_V0nKbZ0F2fl1sqR
 qA2Ak4JlMhUetXWfqmMPH48_T8g0lSMW.XdHq1K73Mp2u.hkuMnYAYQfqHkts6HUnqZYARHXeeL0
 J6iXbI3IHoTRtWHAoB89GzCgDyxwb1nMhA4acFvC6DmN_ZplUFnVYPEwnG34SHKy0vDZIPsWQGBB
 WAVwgc81EjsXM4hmzHWA27e5f.c2pzxVv5J5zkLDDho6kx43Q10dvToGJdKLE8z13xEzDLTPlYdL
 5wqTk9AuqY6KbOXu9ySJlbgCEtQeYC7_EkhuLY6DE34qsRSmqaUAbHFiTmPuvJLeflhnlo0u.s_B
 INlzaZxTcRQlVlOPHXXA4GE2yF4OCevFS3a6DK_H3GtaBLkcA6.mUnuRlYgA8fyavIu2zIWOaCno
 MV._aiL.sxjRkiFVG8ONoEe.9XpNk_9yx.N1RoBySe7KKwaOkRB57n2surDlmcZNwbfxhml0OisS
 YwoFu0mI055hTCBzj6PhLfkTWqK8a2WrLhvj4CABVpAsMXHP396U5X0RVhAqm7txbTMaVR0Wn5Yj
 aLQzahzbOByvwoaSN.mj2yAxbQRQcCm_yj42fyycst95VNPja.PvK9sSYtcyWzONMkoE4je.6.XF
 KfdaT_6gSUHKxMruSOcOfwJNoyfUfWiKIFGiXIYE4rkPtgGcZCIrFoCOiMBtX.IzVE021.kzRBGc
 V3d27R.U7XAuOsNUTOl9Atvc7VnhjzHnnZtSSPZI0_in0LnqoI0UdGvSet3uZm2k_B3naUJidJtZ
 B_S5SPF1rX3pT0.QJKvtJpt1R2k91DA5TwjDsK931LFpR6lsS6SK4ry6ICZltTIgEJXeLOn6.Zlv
 1J3upIzCE9TSXmcX79kE4IRLuutJdirhHVuf8s2EqV6Vq6INpn.dj1cM09GSwmGp0IB2oaQ90cNn
 XvaauMtTVlQjiWd4NRpgFTuL9zxtunDOMRGO7CkSxCsZCrsmZO.ssY38JWKFPR9JvtvXDWOxgHBd
 CITv8mCAsB4BhavObaDynq_hQgvKt32uNdlpqZ9B0G9q9Yr5Vm.HQeJOuPkzZTd36bqQsQ.XIP_.
 fJIAYrynbF0U2oZjlkTCmxtXsXSxROD2OxxvbOh2vrmduICtRE401H9vHVokfSE3KRKC4hRYCk1n
 OPNpKEDn4MeY12ZBCTSFNdsVdsrjo.kk.L5pKm4xYFaYGA80RSaZ5GXiLNqVJVmntD61jNIE2fhk
 cLzo2Ki3PtJGSnq_3i2xilZx_ly.T_q3gGngC64tD1xF5BQkh0ev4ZPxUZUXyQPhTwvSqCqa._hR
 iEjATBGP0fI0G8SflMOAHxyqcV7f9FfknUwbD624zzJLYYadnEewVHQGwRnQ3a9MSVzqKyUy_Lsf
 ZKnbA_DUrxKmuQXBeA_WXHY.T5qbaQvjwXEURwv._KYrLBwNJmuV2XERnq9WXCxvq4CudbPgA6fu
 x3_Yp6tvFJ5BgrboxHEJo6Dx8S0eCB5rLXnFBPksnIwoCK1SPzh4eMhX4VaW_BFjDj222PSotgK_
 pimM5mt9VmCXEYQ3Rtr0WYQoix6uY3mgEs85ct84R34ZWHxeHj8cpvubQtDdRw7F3DGUvdjaMILv
 b8LJ7IwdkNuE9.BKQXxk64AR6d.5arJ9yDhEU4tU.y4x8ZA34L3UG.bWQ1YQ_xCY6bL8WWsoiTet
 uNMNXOYHLNsaPHwt33O.Qg4eXPMqaNyFw0lI4MPw4QIe1uTVjR5sZuM_zfHpAjZxn4XAoxLTrZ6d
 oKT_S7iutkZ7RWKmeNTTt3UwZUiu9h5XJn5e9qwCbKzrX1oOOSXlDhzpkQ5ngbwXRc4uRdPuuYzz
 cWEPMp8XkNS4aW89vZ.zNkYwwHIwSWIeo96.En2t0LW7Rsk2lUTr09zaJ8c9rcCnbmZaexZfZDRZ
 nSnwXg6lQsTRJTkYgNtizifWU
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 22:26:54 +0000
Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID 6a4196d62d3695a01b37e8473f95370e;
          Sat, 09 Apr 2022 22:26:50 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPI4 panic on boot with -current
From: Mark Millard 
In-Reply-To: <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
Date: Sat, 9 Apr 2022 15:26:48 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <63FAC16E-2C49-4A09-BDC8-ED6E74FAA3BB@yahoo.com>
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KbV922zL3z4pX1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=trUCueei;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.25 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.77)[-0.772];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.977];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4935
Lines: 131

On 2022-Apr-9, at 13:59, Mark Millard  wrote:

> On 2022-Apr-9, at 08:44, bob prohaska  wrote:
>=20
>> On Fri, Apr 08, 2022 at 07:46:57PM -0700, Mark Millard wrote:
>>> On 2022-Apr-8, at 18:53, bob prohaska  wrote:
>>>=20
>>>> Might this be related to "RPi4B's got a PMIC replacement,..." =
reported 4/3 ?
>>>=20
>>> No: See the later note about the RPi4B Revision.
>>>=20
>>>> A Pi4 (mechanical disk only, no microsd) trying to boot a fresh =
build of=20
>>>> -current reports:
>>>>=20
>>>> Resetting system ...=20
>>>>=20
>>>> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
>>>=20
>>> This is an old U-Boot compared to sysutils/u-boot-* .
>>> There may well be good reasons for using it, for all
>>> I know.
>>>=20
>>=20
>> Only the most universal reasons: Inertia and ignorance 8-)
>>=20
>> There are many versions of u-boot for rpi boards, some of=20
>> which are rather ambiguously named; u-boot-rpi-arm64 versus
>> u-boot-rp4 is a good example.
>=20
> u-boot-rpi-arm64 handles various RPi4B's, RPi3*'s, and, if I
> remember right, RPi2B v1.2's. This is what snapshots and
> BETA and PRERELEASE and RELEASE builds use these days.
>=20
> The older ports are more specific, as I understand:
>=20
> u-boot-rpi4 does not handle RPi3*'s or RPi2B v1.2's.
> u-boot-rpi3 does not handle RPi4B's.
>=20
> So the usable-contexts do overlap. Technically. there is no
> unique answer to which to use.
>=20
>> It appears the pkg-descr files
>> have been updated since I last looked, but the descriptions
>> overlap and it's not obvious how to choose among them. Man
>> pages seem passe, is there some other guidance?=20
>>=20
>> Even if one knows which to select and build from ports the
>> make install command doesn't really install; the admin still
>> has to know what files to copy where.
>=20
> With good reason for where: the msdosfs file system is not part
> of FreeBSD's file systems (UFS or ZFS) and there is no standard
> mount point for the msdosfs in FreeBSD's file system.
>=20
> The admin may well be able to set up scripts that match how they
> have things configured.
>=20
>> Your instructions for=20
>> the task have been noted and saved, but even then it's very
>> easy to make mistakes that are hard to recover from.
>=20
> I suspect that you are referring to more than u-boot.bin above,
> i.e., not just U-Boot.
>=20
> Keeping a copy around of the last known-usable msdosfs content
> before updating it is appropriate. The copy should be someplace
> that can be used to replace any problematic update to the
> msdosfs content.
>=20
>> Does pkg handle u-boot and firmware updates more automatically?
>=20
> No, with good reason for where: the msdosfs file system is not part
> of FreeBSD's file systems (UFS or ZFS) and there is no standard
> mount point for the msdosfs in FreeBSD's file system.
>=20
> The admin may well be able to set up scripts that match how they
> have things configured.
>=20
>> Alternatively, is it feasible to update u-boot and firmware with
>> an "installboot" target, either from the port directory or /usr/src?
>=20
> No, with good reason for where: the msdosfs file system is not part
> of FreeBSD's file systems (UFS or ZFS) and there is no standard
> mount point for the msdosfs in FreeBSD's file system.
>=20
> The admin may well be able to set up scripts that match how they
> have things configured.
>=20

I should have noted more fully:

The issue is Small Board Computers in general, not just RPi*'s.

RPi*'s are unusual in that U-Boot goes in an msdosfs instead
of being dd'd someplace. And the RPi*'s firmware placement
and handling is also atypical.

Nothing even says that a msdosfs has to be mounted in FreeBSD
at all. In fact, for a microsd card msdosfs used for RPi*
firmware and u-boot.bin , but the EFI msdosfs being on a
USB drive, along with a UFS or ZFS file system, there are
two msdosfs around and used during booting, neither of which
has to ever be mounted in FreeBSD at all in order for the
system to boot and operate.

(I use this EFI on "only the same media as UFS or ZFS" all
the time. It allows me to use a microsd card to override any
RPi* firmware or the like on that media that has UFS/ZFS, a
microsd card that does not have the EFI content but
has the other stuff. This can be handy for some forms of
recovery from rpi* firmware/U-Boot/FreeBSD combinations
that do not work well together.)

And what if the devices connected overall have more than one
msdosfs around that has RPi* firmware and/or u-boot.bin ?
Which ones should be updated?

Nothing requires that the snapshot/PRERELEASE/BETA/RC/RELEASE
build images be used or that things outside FreeBSD file systems
be organized the same as on those images. pkg and such can not
presume that they are.

The admin may well be able to set up scripts that match how they
have things configured for the system.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr  9 23:54:23 2022
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 B60351A8498F
	for ; Sat,  9 Apr 2022 23:54:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbX662z0bz3JNW
	for ; Sat,  9 Apr 2022 23:54:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649548471; bh=W6sC5RsHCRpuPdCa0Ltd1yyfuZgHBBogTOS5jKyz1jM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fFiLETp6ohhtzepMuaAiHpK+hOFmFP0isHhS25qIcNN8zFdC50Y5+8ILe8WCvQ5zKaGDpiMV7S92YRqvWPpWPawI0wmh0gO0lXVr1QbPhu/6Q6rkCQ75qximEA5+pVhI1WX7vZT7I+6sUNlSvk+NdmaOP1Nwj6Lk3HCUuq5SkyLRBOstD5kuOfyKh0ImQB2A+CzWoUwOy7731CmVlFPafIus68ZIaKMePrK+MYS4wOvaNomjiIF+azkZg1vvkuYUir7XIUDzRsYDrV0QBERfcXP2wKHBXWjYR+PNLXga+JCS/iVPqSb1d/0jYzbTrPLgjsY6FHWPCPTN+ED54he5QQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649548471; bh=yUIP7uR8FbJioXJbU/usSISe8THkWuoV+R+rmAHvlKN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Zt0OTX4+aG+qtjqY6ZexRv8t6tYmFhKTH9YcyVnPyqvkkXh2RCNQMg16h6orwTIspdiE6L2OOb7S2fOK3vr/W869yrdbO9Rh/iXc8xDOaelyD6B84lV5N6Xd9YAIRgEl0Wy8bT0l8cJ/QHSN7ef3A3qNoePoJ8Tau1GVOs7l4DFf+haGmn97UMPfcmeGTYA2bzMA7xOT77Svvm8K8NDXxhLYJ4B97Yn1QAhQ46xCA3SO28lodni8qepU2aNmHiChh/eL41L04Si3QtoGYS2DSSSfhMZvIp/yStF8A2TNwF7w6o8U2/8jnman7DuamoLQLOSJHS+68q6P821lhYJm/Q==
X-YMail-OSG: tMG6GxYVM1nKiAjLkGAiE.bCiDqbtUQgN7JtWXPcJK5KASP2ClJqhIcOkspv9ez
 ZiHdS9mdvmRqyea2daJnpjo79e8BLFWVLyDJnNTkSNz3Km3t6GltPQi1SqK1k.V1wxo28L7u7oTt
 EqLrtsm0NQ_ouh_LmcXVJK8rDF0P5BHd2J0TOJTMUPQz4i.pI52OAoV0VJTsubzfaJBM7gIhtkjd
 oyNzujqONBTLC0x..kX_SDHe3jDPKfYQqxex3gJwon_LFHs5EjgyGs7ofN08.iOgJau6axbqtlCO
 FpBw.bNFjHg48Ktj_m4LNHW0mSHKjEVEfW8Tm9ak3my.ehVd9GVg.F2cOBbWeIk5hsD0hOiAmk9w
 sC5xhDuiFgP4yjSSllpO.4xzK9eExOaxAG5ob042hhuEVrGFKVLlVO5ouzHGhwq150_NOhwmqyet
 gK378jg2j.DRXDJbgHZX0R1XbbNQ2hNsPcPrEP90NlXZYezfI9H.wdwvDeB5ZVluOzTGS5Zt2PMH
 qHt4F3UeGGaEiwKvkIp_VqabANjKWkLUqBlvftPmIEtccVz4lpLQRm1qWh0GQnC3FNwgxBOZ852L
 iP2GYjyt.R01iONQOcs02RHPcNlO0bZbcsltWGHz6osMI8Iul99tC_YaC5s8qrJlU4gzrfX8U3V3
 fSvHF0nxnvcNp9wBjJ6FkGmNgaSY.cvF65T8jWD4TFjmCFlT0tl38PxSyumN1.PIoW3eKacSN3NL
 EBB4sKlWdahJ9WN7xURFet5tTo2Hs1rERv.eDyodYHCPWpHfLNg2KJMlDfpPyUuF_XNXAsjKeA8z
 1zADonMHtePXDVoQntguBN7RFNAUoMTXyj0.ygmbPAJrzj1dpjVEvUZKad4lKdsMUO514AippYVZ
 VqsOoXfc2dGDPlCZai3Tx2r1tvu3DZFg_PGiU_UwoOihJg3WhHor1jUED1jwJfSQAWpH.t2ODUl9
 JVWoGeL3NUTmMEBPpcgBqEMXxwppQAsh1rlh_layWL2TdP9igVZ9B_JVsABdk3hfRoGOFNW5iS9t
 ZeJOC9qBb_3divZGE0qlYqRi.l48vDwAc8O2n2Y1wJg8j3_A42UER6nebhH1jH6xPnqM6uidgYKq
 9usa4Pe2EMXkUd7QLyfkgyqJWoL1ezs_WnyNaNYMM.cGwA.gt9n7kE4_TmhOJVSTZ6pn6ceg_h3D
 GSWba8Qw7vo7A1DPUu9q2TDB8HY0jpMJ4s7KvfuhC2rnmRUU_HCP_m_pXk4yYA8PqA4PSOZhslgm
 j6FZlz8Ew_8r7iAD24oJ6IZQoyC5t2s1Q.jddVKOvEKRo0HN4ORNUvvJSvOHBQ2GT.A.fBad4OOU
 EyPL.DJXrifW19iYVpAyQHNnpdcu0O6GpbTU1KXOwPnJjtu1Mpm5CXxqdBbegLnhVxNAMhAhXprS
 Ye3EftsZJBkJ22AdSCajwS0lv1CB5gUICRYkCr9cITeUP9.NuvNKIseCG8iJm.WrtLCdJjBeaBye
 SCQoaVNEBwOJ1j.J9qFEqkee_cD31.lf7EONPcUgVtMemoNP6AfCcvv1uwUzHr4ybzpH2WCRJRpC
 QngvyoJFTbBoH7XgMGhRAJPEGhzHKoWXRXvmR_eXnKktOCJlTmVZEM4wlt3b0s8EjA32wtQuY3nb
 XXGUWSBje_nZsBLpe7Fa_stgNL7IuM4XlBvZG2dS2Fu3ErZsZR5YZ4CB4mZH.4G53arMCjRbktIm
 05uKbeocr.o6DH1VL45XHUd7fWb8PoyjrUtxS8xtM.Fnn0nyDhawFX9N_SBxYnFgq7FqjNacxblN
 3oV8_zb3rKunqmdE0q4Nscyq4DeEd54RaF5jKgeURCVrAEBRrkKvEnVU92OHzSV.ktn_Uk9GQulQ
 PdBl.MpO81fa._O81kvn2WtctWHwLRPuBt4GNGY4lfUXrIJXWipX5TY1Awy9hF.t5eMHEcicpHCT
 Y5Vs9S8jz_UlvOgg2kkyZN3rwywkOJEEfBd.HklKmQxhWGK3q3XH6GnbldXWeT70jnVoGAArn2Sg
 KbFf9aB0x8nQ_LYX1_cOZx5tCGYVBlayuNIaNNO7u4opQS3q.yTtpwfDdP7cVY1LjGQ0kIHCOJO.
 VvYh83VV4ozsjsmXD7jMpcuFd4_9RY3w..VSS..Y39wZzJ6D9hwNr7iu1JS1_qHu54003AbCZktA
 uVEKtgatjFn8BTIVcQE.dyp7ti0mk.195DtPkUQ3JQRoAmN_WAQW3ZsnvmbV2MsNEaj1.Mf_7jB1
 FNGB1ijGWgf27q0ebF6buXCEpO81zdXry8QLoZlA3b3m6_wPOCwpbImbdlpYaFX8wipPNwIgUwf9
 y0q0AN56Dniq9gYlqWQZLPnOW
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 Apr 2022 23:54:31 +0000
Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID e9d50b0fc7c471b5c54faf53b6180193;
          Sat, 09 Apr 2022 23:54:26 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with
 -current
From: Mark Millard 
In-Reply-To: <20220409221742.GB56550@www.zefox.net>
Date: Sat, 9 Apr 2022 16:54:23 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com>
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
 <20220409221742.GB56550@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KbX662z0bz3JNW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fFiLETp6;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3685
Lines: 89

On 2022-Apr-9, at 15:17, bob prohaska  wrote:

> On Sat, Apr 09, 2022 at 01:59:10PM -0700, Mark Millard wrote:
>> On 2022-Apr-9, at 08:44, bob prohaska  wrote:
>> 
> 
>>> Even if one knows which to select and build from ports the
>>> make install command doesn't really install; the admin still
>>> has to know what files to copy where.
>> 
>> With good reason for where: the msdosfs file system is not part
>> of FreeBSD's file systems (UFS or ZFS) and there is no standard
>> mount point for the msdosfs in FreeBSD's file system.
>> 
> 
> I must be missing something here. On the Pi2, Pi3 and Pi4 images
> the msdos partition is always mounted at /boot/msdos with /boot
> part of UFS and the msdos partition under it. Are you  referring 
> to other platforms?  
> 

pkg and such is not limited to RPi* contexts. pkg and such do
not have a bunch of logic based on identifying if it is a RPi*
or . . . or not and doing different things on that basis. What
is it supposed to do for a Rock64, for example?

But it is not just that which is at issue . . .

I do not have even one example of an aarch64 FreeBSD installation
that is limited to booting just one type of aarch64 system. The
exact same FreeBSD UFS/ZFS media can be moved between systems
and boot almost any of them: HoneyComb, MACCHIATObin Double Shot,
various RPi4B's, a RPi3B, and a RPi2B v1.2. (The Rock64 would be
in that list if I booted via USB2. But booting it from USB3 is
special, requiring a FreeBSD kernel that is not on the media
plugged into the USB3 port. But with that kernel, U-Boot, and
EFI related material in place on the same media as that extra
kernel copy, again all the USB3 aarch64 UFS/ZFS root file systems
can be booted. The media with the extra kernel is not as portable.)

So how are pkg or other such to deal with updating such generally
bootable media?

Or: Say that the RPi* has a msdosfs on its USB device that is
able to be used for booting. But that, at the time, there is
also a microsd card present that capable of being used for
booting, at least for the RPi* firmware and u-boot.bin stages.
What sort of activity is pkg supposed to do to identify the
context? How would pkg even identify, say, which way FreeBSD
had been booted?

The early stages of RPi* booting are outside FreeBSD's direct
control and there are a lot of possibilities.

Nothing in FreeBSD says that /boot/msdos should exist or be the
mount point used as far as I know. It is just something that the
snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently,
do by the free choice of the author(s) involved.

In fact, if you tried to use bsdinstall to set up a RPi*
context, it would not set up something like the
snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I
know.

Nothing says that RPi*'s have to be set up the same as the
snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential
differences in question are not part of FreeBSD.

Another common convention is /boot/efi (especially when the
msdosfs invovled has the FreeBSD efi boot loader as well).
FreeBSD does now have some predefined behavior for this
convention.

What if nothing is mounted to /boot/msdos or to /boot/efi
at the time (say, disabled in /etc/fstab)? How much analysis
of the context is pkg or such to do and adjust for?

The FreeBSD loader.efi has the same sort of "there is no
fixed place for it" issue. Other than the /boot/efi use,
there is no automatic update of loader.efi either. This is
largely because the copy used to boot is not in a FreeBSD
UFS/ZFS file system at all --but in some msdosfs file
system, possibly with a special partition type.


===
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 10 00:22:49 2022
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 CD3181A8B5A1
	for ; Sun, 10 Apr 2022 00:23:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KbXks51MTz3N2T
	for ; Sun, 10 Apr 2022 00:23:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649550173; bh=Jygg+jE7sXg6Wks/ahnLOzunNZLOBXGBfr6LL0cJN2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bkQnm4FllL+g0gUjZ9PIb/KQS6eVcAFHjG2Y9IohtC8nOW036dZ3bcxayFB7lGfIkFH6/zzlP4ICG410eVh+zWIR3BMztlnw1GFtscRwOn3SYvTHgEU4zT2GQQI8uSj/kVbHqcO4bpocJuY9+9hw94eiILWQL4vM+SzNZp6R9C6sPcwMLSRgVmFOIX3sAj2SnQ6d0oa98uXY4YMTuQZsZ0+M0wPcLd4mWiUlCfS36jlihE95WwFJjl2w15078oIE3J0mpHtbeZeLxzQE0LK44F3Q3WIcCHE3J/Clnh3u3JXhxPMYC+Gg29Iq3c2PaZS0c/ms6HPpnOWisOd0hjEbCQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649550173; bh=1JAzEyPmidlzXBl4nS5waJHNSarZtoxHXENoGKEsW+G=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y6YGsCVnqmzcNTovFiL3vzpsIJTRwIM/z19QMeZ9Lxe1r3R/55vQ70yuARnA9z/IxdOd0sUYsVFpEDL8hoSVJVenOODxvZaPDssSjhCY8Ia1kNtM4uIYZ7fUkmbiqJlQkFRCSHdqHsQ9r1CeGc0Y94Q5nRENkavZnb1dNoExUoXYtjSfLxIsai3px467R7+a22MuOjP7/9BfTqEh3jKlaMuTp2nF/sBh/HMWqBTG3Rda64Hu9TDCCoVul0tF1JNV3yTdxjtq6cmxEeblT5xf12eTmjQzNCyP3jffuT+c0SzS0zr7Vw/2Ht0tf5I0WOCrcLK/+1IeikDPQx3ZD9HV+g==
X-YMail-OSG: 3S42UhoVM1ncoc7ypc2.OkTZufbtrJet8GoImWgbViXizMtcroLswUfEvoLC6jN
 UkI3ruQ9p5mRY6L7o3OYITLCuupCwy4m8gw646RGLIHW..KSGeqW45ZtfeKHHbk1bR.Z6VwmVRt.
 Imxo4iBOzAszYiqhcC4Ckew1Vd8_cgp9vobA.wHjBnVD6O8JyffZqCZNu4Ua2rNcYCsIjP99Z5QN
 j32rGfh.pnkOoWtsp0JSlkTEbUYrqsGWCqdFzI4AMmBp5FiW1r.v0QFfYjZ2CxWi6vz5le5pFCBY
 c5Wyk_UBMg0uZwWOy1UITkvao0pw_Axlg0r54AGvoGvD28AkWGuJXIYBMW5PqOBovnXSYs4piyQL
 sXuui1Vs3FseNgUca.dcqMSAXdvYKlmK2ArzE30PLqANSuix2NobBJ9XmvFARTkNflKz3.PiWjzV
 CTdEaBX32cWUJf0W5LsQBZb8cvv0Fd9fcwap0EyzmSxFz42Od2N28xE5y_V2qD590ElijLlQ5nPP
 FGdTruVprdz_IqzyeFyHYP9n5XD_K8VffK06jp74tCZetj3xILtt6.dds569uYNHBnLeyzIAmI9A
 ml5Qg.K7uIXJIVrK0u9ovYSLA_opgspIVEXHAOyEXpAjHfHoGkn5PWiTw.CWOZNPPDQfMYEWPZjY
 0CYn8fC6xnFG4eKaLnpfyMQCI20m0yeyLh3ykZTGioFKCwiX7g0dOST3sspEpffpPTrsJWej6XUV
 .pTPMn2V06EqeuvetlnSKxFZwzO5ciBnqxTyOvW_uTjo1.Xat7W6UUQb.nFIogJ1stO8EP36iVhN
 MQlF7d3fvhS1cnBnc7CkvbISVWmZL1VncTkGDP_lhBhA9kow9B63RQLqzjXbFaQ6kyaei7VNEvud
 1nvUljaxayYSlXf8xduzUKojZGuhkQgISnFD10idEzrXPy.NRCGavKV6xp6TKavjFfNINBNp8a5i
 Ubu55NJI6qkxQB7t8a0ciTQDtN4zzHwNAlt08Vf6FGm3uTYcL0Yuco_.btBIrHDijwQ0hHLdp4B1
 xDZWsBdn82D1I5EWLI8e_LZXwboP1E63XQCGvEYR9xzTE6jc2_2aXQx.wgKEzPpYyPNwczX5wwXf
 NfADlJXEwSsRgZMWFSDESeeAeaM9Q1644hZcQYPzedw550IC5rRNZyKEA.opyEokdxQZv2LJTojp
 5.1aIDAHdp6HASdVapXG1k5vWuSEIXVzI1h9AGtyhCZC6NwXYEpu7agLL40soaQbk6j4JZGkdHvd
 SwytrHkqKjrkkFSeMG5mLzH1XoV_iFlqQeYa9yUHREefBXVT5GQWtHFTW.QUBAVZ8CqRObXo2S3B
 XloTowFKRvsuSRBqmFo53W2J4Qq1Fz.Wo9MsMdA9foRvZsDDXfpcD93cX5Qw1k0S1WqSor6d9KW2
 QS3y3o_LWvt5hr5emqniUsznyvxjdFl7INl4jszlA8u5dUxZTq34WJb70fnjDQqeAjzXzQqH_sYP
 n1HRJA2GuCuLoqlyzhat7EvoSr.PYu9omJIHfWtHyLyVIhhyecH0DPefpFLffnWb4JtznUuMT3W.
 hR72QtJy_eRjYUOZ0.M2WEJxBCPSJb.N7uML6xibzVa9h_Htv7NveKvmymu4yVxUsUBjjLcFE2P3
 r2OeHTRbzjtTRpTD9fl_FY2V3fMRbemunLOwZRnwsDmLTscK4kpH19b9jR8uzVUVzoLM.NvYB.hR
 ZrVCD1oXljVLaebbbBjTt2HSTu79721KzbQFO_AxiXPG_dWkug72IoYzJucTjxxvDz5dMaf.4uDE
 eKrMLXVXn5kPYtUF_9BAefpsW5tf.AyP40zQ4l_5JG.GFmxGjggarhP6nzV_qmsT3vwbKaPugwCw
 DdgiuyAhuJYQZ6VSYwB7qs0hH.dJTfWnxOQzOhVHWojBgq3BsH6.IJcgLxKTVK9ztRI_bqRKnIfX
 Ke1XswHvurFLpnFr9e.q4XQ7oGN4jLY9fE3ewp0c6y6ntiRPz_RpVPNxjga2kUPM81H15B6i2qpv
 1rifI_EP0Cn.rpbfo2QRY5qvtJPrcOcYaHnrxmUw2.lzwCX9cHJ91HNi0T1QR5.TI2yu9k8.rmWk
 dL8cJE9fyA6FH_ZatWDEkoHwx.6KmZNuTy.6un8VmER9BplE9ICul4xADWKT4z14tm32Kxmxq1xm
 ov7mmY2mJ2GZoZ.N8tuDG7CuayUJYOvPRYImkaM24gDm0xdZUkR63GmWWZ8UdK_ymWWiC2ycrMAj
 krtp1jboUuioa89MZooOFvSwocB8WPjDQ8Zip8VUF7BWikDp9lbG8Zp1FdWrUV01eXDjMTqgvtBD
 tqWnfRgJLs5Y9Qa55d8U-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 00:22:53 +0000
Received: by kubenode546.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fb0e4346083de05231cb744fd2976cfa;
          Sun, 10 Apr 2022 00:22:49 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with
 -current
From: Mark Millard 
In-Reply-To: <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com>
Date: Sat, 9 Apr 2022 17:22:49 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
 <20220409221742.GB56550@www.zefox.net>
 <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KbXks51MTz3N2T
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bkQnm4Fl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4463
Lines: 105


On 2022-Apr-9, at 16:54, Mark Millard  wrote:

> On 2022-Apr-9, at 15:17, bob prohaska  wrote:
> 
>> On Sat, Apr 09, 2022 at 01:59:10PM -0700, Mark Millard wrote:
>>> On 2022-Apr-9, at 08:44, bob prohaska  wrote:
>>> 
>> 
>>>> Even if one knows which to select and build from ports the
>>>> make install command doesn't really install; the admin still
>>>> has to know what files to copy where.
>>> 
>>> With good reason for where: the msdosfs file system is not part
>>> of FreeBSD's file systems (UFS or ZFS) and there is no standard
>>> mount point for the msdosfs in FreeBSD's file system.
>>> 
>> 
>> I must be missing something here. On the Pi2, Pi3 and Pi4 images
>> the msdos partition is always mounted at /boot/msdos with /boot
>> part of UFS and the msdos partition under it. Are you  referring 
>> to other platforms?  
>> 
> 
> pkg and such is not limited to RPi* contexts. pkg and such do
> not have a bunch of logic based on identifying if it is a RPi*
> or . . . or not and doing different things on that basis. What
> is it supposed to do for a Rock64, for example?
> 
> But it is not just that which is at issue . . .
> 
> I do not have even one example of an aarch64 FreeBSD installation
> that is limited to booting just one type of aarch64 system. The
> exact same FreeBSD UFS/ZFS media can be moved between systems
> and boot almost any of them: HoneyComb, MACCHIATObin Double Shot,
> various RPi4B's, a RPi3B, and a RPi2B v1.2. (The Rock64 would be
> in that list if I booted via USB2. But booting it from USB3 is
> special, requiring a FreeBSD kernel that is not on the media
> plugged into the USB3 port. But with that kernel, U-Boot, and
> EFI related material in place on the same media as that extra
> kernel copy, again all the USB3 aarch64 UFS/ZFS root file systems
> can be booted. The media with the extra kernel is not as portable.)
> 
> So how are pkg or other such to deal with updating such generally
> bootable media?

I should have explicitly noted: How likely is that that I'd happen
to always do FreeBSD updates on a aarch64 RPi* instead of one of
the other systems, especially the faster ones? Is pkg to notice and
update RPi* boot materials because the updated system could also
boot an aarch64 RPi*?

This better illustrates what I'm referring to when I reference pkg
and the like identifying contexts and handling a variety of them.
Should it be checking if it happens to be running on a RPi* and
behave differently than it would on other types of systems (same
boot media)?

> Or: Say that the RPi* has a msdosfs on its USB device that is
> able to be used for booting. But that, at the time, there is
> also a microsd card present that capable of being used for
> booting, at least for the RPi* firmware and u-boot.bin stages.
> What sort of activity is pkg supposed to do to identify the
> context? How would pkg even identify, say, which way FreeBSD
> had been booted?
> 
> The early stages of RPi* booting are outside FreeBSD's direct
> control and there are a lot of possibilities.
> 
> Nothing in FreeBSD says that /boot/msdos should exist or be the
> mount point used as far as I know. It is just something that the
> snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently,
> do by the free choice of the author(s) involved.
> 
> In fact, if you tried to use bsdinstall to set up a RPi*
> context, it would not set up something like the
> snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I
> know.
> 
> Nothing says that RPi*'s have to be set up the same as the
> snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential
> differences in question are not part of FreeBSD.
> 
> Another common convention is /boot/efi (especially when the
> msdosfs invovled has the FreeBSD efi boot loader as well).
> FreeBSD does now have some predefined behavior for this
> convention.
> 
> What if nothing is mounted to /boot/msdos or to /boot/efi
> at the time (say, disabled in /etc/fstab)? How much analysis
> of the context is pkg or such to do and adjust for?
> 
> The FreeBSD loader.efi has the same sort of "there is no
> fixed place for it" issue. Other than the /boot/efi use,
> there is no automatic update of loader.efi either. This is
> largely because the copy used to boot is not in a FreeBSD
> UFS/ZFS file system at all --but in some msdosfs file
> system, possibly with a special partition type.



===
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 10 03:39:06 2022
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 9DCAA1A9AEED
	for ; Sun, 10 Apr 2022 03:39: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 4Kbd5D3ycRz4YjH
	for ; Sun, 10 Apr 2022 03:39:12 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 23A3d7EX057467
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 9 Apr 2022 20:39:07 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 23A3d7FF057466;
	Sat, 9 Apr 2022 20:39:07 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 9 Apr 2022 20:39:06 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with
 -current
Message-ID: <20220410033906.GA57250@www.zefox.net>
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
 <20220409221742.GB56550@www.zefox.net>
 <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@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: 4Kbd5D3ycRz4YjH
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.29 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.98)[-0.981];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_MEDIUM(0.37)[0.373];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4379
Lines: 113

On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote:
> 
> > So how are pkg or other such to deal with updating such generally
> > bootable media?

I don't think they can be expected to update alien media.

There are lots of platform-specific ports for u-boot. Why not match
the install target to the named platform? If folks go to the trouble
of creating a port for a platform it's little extra work to add the
pathnames. What you're talking about seems far more ambitious.

> 
> I should have explicitly noted: How likely is that that I'd happen
> to always do FreeBSD updates on a aarch64 RPi* instead of one of
> the other systems, especially the faster ones? Is pkg to notice and
> update RPi* boot materials because the updated system could also
> boot an aarch64 RPi*?
>

Presumably you'd cross compile a package for the intended target and
then install the package on the running target. The platform details 
would be part of the package. If the target is RPi3 and you're compiling 
on Cavium, the RPi3 paths would be part of the package. The Cavium
won't be running the pkg install, but I don't think that's possible
in any case. Both pkg and make install work on the host they're running 
on, no?  

> This better illustrates what I'm referring to when I reference pkg
> and the like identifying contexts and handling a variety of them.
> Should it be checking if it happens to be running on a RPi* and
> behave differently than it would on other types of systems (same
> boot media)?
>
That's the admin's discretion. He knows what the target architecture
is and the media being written.

> > Or: Say that the RPi* has a msdosfs on its USB device that is
> > able to be used for booting. But that, at the time, there is
> > also a microsd card present that capable of being used for
> > booting, at least for the RPi* firmware and u-boot.bin stages.
> > What sort of activity is pkg supposed to do to identify the
> > context? How would pkg even identify, say, which way FreeBSD
> > had been booted?
> >

I'd suggest this is an unrealistic scenario. Pkg can know what
files it's supposed to update, the admin has to make those files
accessible. If the wrong paths are mounted, that's a wetware problem.

 
> > The early stages of RPi* booting are outside FreeBSD's direct
> > control and there are a lot of possibilities.
> >

Yes, too many. The admin has to constrain them.
 
> > Nothing in FreeBSD says that /boot/msdos should exist or be the
> > mount point used as far as I know. It is just something that the
> > snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently,
> > do by the free choice of the author(s) involved.
> > 

But it does exist and is useful. Why not use it?

> > In fact, if you tried to use bsdinstall to set up a RPi*
> > context, it would not set up something like the
> > snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I
> > know.
> >

Can it work at all? I always prefered the installer whose man
page said it was "greaty in need of death". 

> > Nothing says that RPi*'s have to be set up the same as the
> > snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential
> > differences in question are not part of FreeBSD.
> > 

But in practice they are, and it's useful for most folks.

> > Another common convention is /boot/efi (especially when the
> > msdosfs invovled has the FreeBSD efi boot loader as well).
> > FreeBSD does now have some predefined behavior for this
> > convention.
> >

Curiously, my Pi4 has an empty /boot/efi, but I've never
tampered with it.

> > What if nothing is mounted to /boot/msdos or to /boot/efi
> > at the time (say, disabled in /etc/fstab)? How much analysis
> > of the context is pkg or such to do and adjust for?
> >

Just report "path not found" and list what was expected.
 
> > The FreeBSD loader.efi has the same sort of "there is no
> > fixed place for it" issue. Other than the /boot/efi use,
> > there is no automatic update of loader.efi either. This is
> > largely because the copy used to boot is not in a FreeBSD
> > UFS/ZFS file system at all --but in some msdosfs file
> > system, possibly with a special partition type.
> 

My plea is not for adaptability, but acceptance of convention. 
Identify a platform and a location  then put that info in the
port install target. Let convention be set by the image. 

If you got this far, thanks for reading!

bob prohaska


From nobody Sun Apr 10 08:02:15 2022
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 036C51A874E0
	for ; Sun, 10 Apr 2022 08:02:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kbkwz4GTMz3QGq
	for ; Sun, 10 Apr 2022 08:02:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649577739; bh=P/AaVWI6mTAxKLzDPxYvxgMo5zp1v/gI3jQJTFyvyN8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=V3rSoNMj9KWf+juU055IPYegFCu9F4bdw0hlaPQf/SY5PQ48uC2Kp1qJO8jfo1fDDVxudnGg4L9Oqxt4e//0qkH2AyzyL2bJdBAaw3soIDEDo+XBwos366AgDuDWFenE8LVqjf4DatdacwxLzhAHdsg0swkuSnnnhjO7jP5zS5nXu6HRm2G+wtDbUifSa4vSmvlyr+0CWjtmWBAqq0dr4wfGuxjFILCU4v50xU6f267moDUwF0taHY/R88YQXMuKYIksDSP2H8nQJR4lflTPXv+L4ROG1nV9XzXIS8vzPyHNRhmqhOqkLg/kro8NBDcWgataxUhFkclx26RWoX/9dg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649577739; bh=IR9l2N6gymTE58jb42k2ezXfq+B6S227AoNvYYnQkLC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IqLkycdQwdFqdNarErD21Po2u9RduBthuIXRPujRgV8H2Gd5+b1LFVavWR4noR0FiFc8u7YpGgbPEYwypoN6FPGiLjwzUxZNd0HMizltPrU6fsyuHWAd3MM8Ji935yBL2cciVO2B9ltsLgQOwY/cklktDJOWyQTu6evHXiZS2lk38Yu2omg/7U3cvkx3E+oRYlFi0GaabUNYyIsmauSN0i6EbFxTm9pLW2fG3/cVluSmY6zVjuBh2HgxBygophxeFvDmxTpXfbLHgkUsCj18tndnac8RUy+1Z2Rb+0vphy1F1sC2wbIqFbF2MaCSxvJYQ/EDx+/ML2Nm7H9LG04jTQ==
X-YMail-OSG: 9YrGSVEVM1mEAtqkVlkIBTRZKwdyWoAWfbseXVJ7Z6zh48ELdFyF5RhMfB5S0rW
 KWnEI_K2QFIDsUQqYgyZMBeygAmLUZLgaxyOIgHCOG06RWvnJcWBJVKggXOfY35WdDjDqD0_CLe1
 THJGsxXf6eal8bFWN02snHe4aUWaptW56IqlW7b75taIeNf5VjRaZVQOF4C6JR7kxc_rahkPk7ld
 uir81asonR.0UGgoQhBQSwjVfwP763b_LI.vDXhOaQz6p6dm5rvhvyZ8e1eza4NdjGypLm_OPyPD
 mSEfMovvNVGZ8rDWrZKZBCjofCxBAmAkUf2AChWBpf1X4asKhejX5GQwfB.Ji_NlutMsxnin5iky
 zssqp6UBER4G7emmBcrcUAYjvWuPYyVd3ITiMPsqGqaHoF8Qgwwrk2os5IBwiCfIqNHalQsaRHVC
 HR5SFCe_aEFl7nwSUy.a.iwf9qgs7wMGhNH5tIlXB6EA5e5vSCKXFpKMlk_8nAx0RExkwyTJX.wi
 ZSNMrHC5Hv3FuncZwNLo9echQMApW98SkVtoXNJxOh5QbbSjIOsdzku9xMWH._JFrPWe4G60hLMz
 yLdQ5JhW.d4yxMSIHotPDe_IvOgEw_K4in38q2f4w2gpNWNPLo1XnfGIHlBbA3tsFWQtYv6qtloV
 Zo6gbwKoqCUg2Ocv430EkN8gtDqqDRsMoJe5xs4fWHUTvZKohbqzYqrHHHmL6Y9xzQNNtRJkOOWT
 O3hmkjWqcTiyfgY2NEHpO5BJcW72.TCs0RVP.9QmENWlssw4632edExhaSTM7SJ0b5UG46Cd.T9a
 rUlenaIsRpL_MoYotH0Q8KmnIrvn_XRwccpEWuM6BsXXTHg_orboXWRdYTJcmcn80oZn0KWAQbkp
 Ap0CCdHEJNWvdgS61Kutr51n17EIE6595OFc8mvSVNfTjTs.LFKmdhkmHKG7SkxUjnwXRgTv0BIP
 K1ayyJuLKx9mIbzAxsexYb6upglOzhMCtWrgLVepfr4ER.j6j4wgHpWRYhK49CAE20BKlaqPCCKl
 UG_NlDCNZpPupH7lII3Sc1vi1hkoaACeXY3FdpGxCDeC1ujXEtH1LXiA0DbGEg2n17V0wFSTrAce
 WwvBj5pN8aHEGVm9r25bK8neIy3MPNxVdGtyP.ewCFp1MoJkJqlm.SvVcM3Zs.mdDh9OKYjD8IfD
 ewRzjSBJAcjksQcYEsODW3ZFSERo_6zTL8H_EYCFtG9TrCPKjQJNGQ5KguuCmpM6mE7HBNgvyzN7
 GMvjIsdXplbREyRSXdjdQ24HyACLkgg.l..VvoiLi_78TB_qc1Zg7tP1YnLoApG7z7xSRSv6A1nM
 3KojJ8iP1BOOgN3IaxjIHEHViYx_be7zeeW_j42xBiFqYrVvWNZIkJFxk_wzoQGKiVfdMaBh2UkM
 z.5.aJRNnLhM6gyHY7xVUwu94eu_xFAqE8sFiBZeV7PLk3qIADIVk17tUdsTT34igu8HAMEpjLSe
 fF8h6cK8ZxbCA7zTr8vgHtyguK.Zp75heMTDzJscuA31ntRUY9e6XmBnLs.LHJ0DhVaYKgm8vEVi
 KqsH9_mOx6ZxQGOZFfBwgxBWKffA0yfhyBKkPntjmOpiV1HWvtX19i4Z.HnUlxjLyuXruZuunc.Y
 nWi2zZ2sZDoJHojgXDimGdm.ZSX5om6zCXjEw_HxkzqWCCZLnElfoQgdlMHiN2JbzWbTFNduyQSN
 p5Zea3Nru6GkDOa5XazpMrVO7N4E9Ofu7riFXyv6HB6Wx9El6qMxefhYIn8UWUjDS.51OhwSR.qA
 lz0Myy31AUStPldWLv_erGLTzoh7Co8Xg0MI5kmrILwuBIP4XkP4_hhy2rBrZu4a_Syk3zp3umBT
 lQeWGYU4oBq_ZAlqL__ySynvgBIJ.Vdz5t7nfJltIETPIRjlfCtlpvRo125yGW6hAioru2iihimE
 lCKSZHkaEvfOhNxUXjAtNUbtIN7zNNLbnwKnPj8IEZupGteAt1r3hT7PYVpGLzlvN7FBtDlsAydK
 JAwDzYq32NyfZCRwTb7qgGFt2D64XOEmEhnHOExnvTV7XwbpM3jHCf1miYOld1BqKfIhnVAkWIxT
 JIERzN59dEsEQp2BC8W.RI4wX6wQzFtKeHuQm64RbonxE0FXCu2aAYy6xtfGRoIYBgdfs3WViWJc
 Vz4mvm.FPM2QcQv38FLjMaRNAx63mebYgDqVIEf9f5b6mflIx11kewp_V3imOW.eRsJowenhoRdZ
 66jOLOSxbDvy3TUEjWCue_ErK19PdDZXrv2WMzw4uaHo6A_HFY9FeOwdIIxbuPiBDvbK73sdmICX
 PPtJBE0_PRa_sbut9DaE2lcilNQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 08:02:19 +0000
Received: by hermes--canary-production-bf1-665cdb9985-6p9bt (VZM Hermes SMTP Server) with ESMTPA ID 95a9ce7d87da96805bcca8f79ea72e7f;
          Sun, 10 Apr 2022 08:02:17 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with
 -current
From: Mark Millard 
In-Reply-To: <20220410033906.GA57250@www.zefox.net>
Date: Sun, 10 Apr 2022 01:02:15 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
 <20220409221742.GB56550@www.zefox.net>
 <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com>
 
 <20220410033906.GA57250@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kbkwz4GTMz3QGq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=V3rSoNMj;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.204:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.204:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10006
Lines: 265

On 2022-Apr-9, at 20:39, bob prohaska  wrote:

> On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote:
>>=20
>>> So how are pkg or other such to deal with updating such generally
>>> bootable media?
>=20
> I don't think they can be expected to update alien media.

What alien media? Depending on how you have things set up for
/etc/fstab use, likely your no-microsd-card-required USB3
RPi4B media would boot the same list of machines that I
indicated. ( I use labels to avoid numbering variations
and reference the labels in /etc/fstab .)

> There are lots of platform-specific ports for u-boot. Why not match
> the install target to the named platform?

And how does one do that?

> If folks go to the trouble
> of creating a port for a platform it's little extra work to add the
> pathnames.

Most Small Board Computers do not have file path names for
U-Boot materials: They are put outside the file systems
on the media. There is a "seek" position on the media.
RPi*'s are fairly rare for putting such in a file system at
all.

For example, for the Rock64 the instructions for its U-Boot
and related material are:

QUOTE
To install this bootloader on an sdcard just do:
dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
END QUOTE

The dd commands are very dangerous when done inappropriately.

"sdcarddevice" is only suggestive, since other types of
devices are possible. In fact, the Rock64 I use boots via
an e.MMC device that the board supports, not the microsd card
slot. That is true even if a microsd card is in the slot at
boot. As I remember, there is a jumper on the board for
controlling which of the two is used by default.

Lots of Small Board Computers have multiple devices that can
hold the U-Boot involved, with some means of control over
which is used.

> What you're talking about seems far more ambitious.

Seems you are viewing what you want to happen as
trivially easy to make happen.

>> I should have explicitly noted: How likely is that that I'd happen
>> to always do FreeBSD updates on a aarch64 RPi* instead of one of
>> the other systems, especially the faster ones? Is pkg to notice and
>> update RPi* boot materials because the updated system could also
>> boot an aarch64 RPi*?
>>=20
>=20
> Presumably you'd cross compile a package for the intended target and
> then install the package on the running target.

All the machines I listed were aarch64: What cross compile?

Your wording presumes that the target boots fine already. What
about setting up the first boot ever for the target --or
recovering from boot failures?

> The platform details=20
> would be part of the package.

Which boot media is in use for the RPi* firmware and U-Boot stage
is not a fixed property of RPi* platform: it can be used various
ways via configuring it differently.

> If the target is RPi3 and you're compiling=20
> on Cavium, the RPi3 paths would be part of the package. The Cavium
> won't be running the pkg install,

As stands "pkg install" means putting the directory tree with the
instructions and files under the likes of /usr/local/share/u-boot/ .
You are creating a distinct operation and reuse of the terminology
makes things are to talk about/follow.

But if a Cavium has USB ports or microsd card ports supported by
FreeBSD, it certainly could be used to create the matching type of
media for a RPi4B, including getting RPi* firmware and U-Boot in
place, as well as EFI and UFS/ZFS material (same or different
media).

For the machines I listed in an earlier part of the exchange, they
all can produce USB drives usable in booting all of the others --and
I take great advantage of that. The two machines with PCIe slots
can produce PCIe media used in booting that work in both. The Rock64
can produce microsd card boot-media for any of the machines. And
so it goes.

> but I don't think that's possible
> in any case. Both pkg and make install work on the host they're =
running=20
> on, no? =20

The assumption that things need to be run on the target system
would be false. That is only one way of working when multiple
systems are available for use.

>> This better illustrates what I'm referring to when I reference pkg
>> and the like identifying contexts and handling a variety of them.
>> Should it be checking if it happens to be running on a RPi* and
>> behave differently than it would on other types of systems (same
>> boot media)?
>>=20
> That's the admin's discretion. He knows what the target architecture
> is and the media being written.

So it can not be automatic and the admin must do the work to
set up something that matches the context --at least that sounds
like what you are saying.

>>> Or: Say that the RPi* has a msdosfs on its USB device that is
>>> able to be used for booting. But that, at the time, there is
>>> also a microsd card present that capable of being used for
>>> booting, at least for the RPi* firmware and u-boot.bin stages.
>>> What sort of activity is pkg supposed to do to identify the
>>> context? How would pkg even identify, say, which way FreeBSD
>>> had been booted?
>>>=20
>=20
> I'd suggest this is an unrealistic scenario. Pkg can know what
> files it's supposed to update, the admin has to make those files
> accessible. If the wrong paths are mounted, that's a wetware problem.

So, here the admin must know/remember where things need to be
and set up the mounts, it is not automatic.

>>> The early stages of RPi* booting are outside FreeBSD's direct
>>> control and there are a lot of possibilities.
>>>=20
>=20
> Yes, too many. The admin has to constrain them.

Admin? FreeBSD? If the procedures are part of FreeBSD instead
of being created by the Admin, it is not the Admin that is
placing the constraints.

>>> Nothing in FreeBSD says that /boot/msdos should exist or be the
>>> mount point used as far as I know. It is just something that the
>>> snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently,
>>> do by the free choice of the author(s) involved.
>>>=20
>=20
> But it does exist and is useful. Why not use it?

Most Small Board Computers do not have U-Boot in any file
system: no way to mount anything to /boot/msdos that would
help with the typical dd commands for U-Boot (and related
material). It only works for the files that go in a msdosfs.
(RPi*'s are unusual for this.)

So any such convention is of limited utility across the
range of Small Board Computers.

>>> In fact, if you tried to use bsdinstall to set up a RPi*
>>> context, it would not set up something like the
>>> snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I
>>> know.
>>>=20
>=20
> Can it work at all?

As I remember, it can set up a EFI file system with FreeBSD's
loader in it. The other files would have to be copied over
(presuming the same media was the desired target for them).

> I always prefered the installer whose man
> page said it was "greaty in need of death".=20
>=20
>>> Nothing says that RPi*'s have to be set up the same as the
>>> snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential
>>> differences in question are not part of FreeBSD.
>>>=20
>=20
> But in practice they are, and it's useful for most folks.
>=20
>>> Another common convention is /boot/efi (especially when the
>>> msdosfs invovled has the FreeBSD efi boot loader as well).
>>> FreeBSD does now have some predefined behavior for this
>>> convention.
>>>=20
>=20
> Curiously, my Pi4 has an empty /boot/efi, but I've never
> tampered with it.
>=20
>>> What if nothing is mounted to /boot/msdos or to /boot/efi
>>> at the time (say, disabled in /etc/fstab)? How much analysis
>>> of the context is pkg or such to do and adjust for?
>>>=20
>=20
> Just report "path not found" and list what was expected.
>=20
>>> The FreeBSD loader.efi has the same sort of "there is no
>>> fixed place for it" issue. Other than the /boot/efi use,
>>> there is no automatic update of loader.efi either. This is
>>> largely because the copy used to boot is not in a FreeBSD
>>> UFS/ZFS file system at all --but in some msdosfs file
>>> system, possibly with a special partition type.
>>=20
>=20
> My plea is not for adaptability, but acceptance of convention.=20

The convention does not work for most types of Small Board
Computer U-Boot (and related) placements: Most use dd to
someplace outside all file systems. RPi*'s are unusual in
that they have u-boot.bin as a file in a file system. For
example, /boot/msdosfs as a mount point does no good for
U-Boot (or its related file) for a Rock64.

Basically, you are asking for special handling of RPi*'s,
at least relative to U-Boot.

> Identify a platform and a location

Normally: not a file system location at all for U-Boot.

>  then put that info in the
> port install target. Let convention be set by the image.=20
>=20

Again: It is rare that a type of Small Board Computer has its
U-Boot in any file system location.

The assumption that most things are like RPi*'s is false based
on what I've seen. For example (from README's of 4 u-boot ports
for devices I use or have used):

dd =
if=3D$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl=
.bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync

dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync

dd =
if=3D$LOCALBASE/share/u-boot/u-boot-sinovoip-bpi-m3/u-boot-sunxi-with-spl.=
bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync

dd if=3D/usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin =
of=3D/path/to/sdcarddevice bs=3D128k seek=3D1 conv=3Dsync

/boot/msdosfs mount point conventions do no good for any of those
specific commands.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 10 18:35:09 2022
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 574D31A84538
	for ; Sun, 10 Apr 2022 18:35:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kc0zF5ptZz4kHN
	for ; Sun, 10 Apr 2022 18:35:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649615713; bh=f1MXOZPND37NL0a71O0PghAhkn7YYE/EfPQ0cjPWW+w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iaK6/ivjyxy366Hq6plwGatQ3YUD//lNaX1oyaNdiSrKpgz+QgAYVXROpZfAyVHWJygP9HTYHNBmozMnddDbOnTt/ZTtENV2Xop3JM9WIYKEha0gyeAAHvJYvKgd7Cv5ZH7AGch+AJ51rL7PQV6zZFzeTzo8XC6qR9OGs9SxLCgS/tC+288m9BbjKCBJ7DSg2CxLdt0Fuxt0tFAk3lFGy7mNCXnNBnLKK37XlUgWE1BkimdZE3HoluqlczdkMnMdhitloMqmTRng1Hx6S6WTEg8XiPormh91g1tbupbW+AcRDBgjvysKyOY5LGPZra1vtq5mNxerI9zEjM8MU9IY+Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649615713; bh=wecW+MRMX6t1zRML9QCWmMJ2wdIW+nPI/8+hEdorOux=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fluAV0eQrRrBa/nHkqCojBlTGtmV7cFo6LSzYbT+qBwQWVpLSWn9ow4Iekf6fAthvRNqUoQ5M3LI3Zx0bYm6GTCcOKhWVcFhdSkKyuenmTRQLMQfOz23Mcvxz+8jYExJhqnc1uEiN1mk2Hv4831wyk0bXVa/EGAg0gNhKaTiBjLkOdcwPokzeCtJLL+PdXc3Nv2rXN+y9uxnJWn6GD1x7rrtGo39RblVqabCYFtL1xfOznC+5PGkp6PfqVI4jJi73jFJk+kvdXMdBOXZ97kcmjjLUSn2/7k7sv0WJTKIduNMcjdYQbRCReVztBeNe3do+S1UzRGRINCUT/zdSmYBZw==
X-YMail-OSG: N_29Q30VM1kusrXcpKZGXUxKly9Sj.dnvGaVPwEMGsYq84b.jSypc1AxgSv1QM2
 2pO2yOqhkOul6bAWg2bCJJAzgsM8wTeNplbZ9D_fkJIrGdCFZ_FNyGGE8D8FnXN7nhGWtAJ_BOG8
 SdAQDSZcDIc0AHtTp8mVoZckFwW0A0NKQKw4cHwiHFXpnfW.X.MdA4.Re5sSyPBeRlb7RlG8Glx0
 E9BiNhRlbMoZxs6eGdfuNddqLUNdo6vwQe._cmhbJ1guZro.Qt1hXaMopCkdRoqyR.pmCVh80N.s
 Ftqcv.WHiswTjkSq5Q.6JkfQN5NeGer1vwDptdqYh7vAVVetF5dBAgEForaoISAnwE0Es9.5qpdb
 NUatvGX7az2CghT3i5Jw6vKuez1guGkzmY_JOVUJLqauLhgDDrpf2oV9jkHPi0hp8r5ZTWymZ0St
 _hxU_555NahoYXWhSCVZEoy55.Quum1ZgM31ZhjhxXG2swipvZwlNnKOzq4AdNKIHAONhvGlJTRQ
 YWaPvyjhlPaINf8LhFdFG1gt6b5A91Dcp0GFC8BDZoIkebStHJAHEoToudOuVtzOODVzGN5xNnlb
 wiCIAeUOOU6He3kL3ZjVEpeCxvPvSd2LBmnKOOK1L.0opnggfDtS5qJMHx9oBZEUrVuJ1vzkPzBt
 zRIFurCFm_PdsHOX6RA8586u.ovvSQy._mTPqa9arx7lODgcifC3.q1R5nXJNLGlVeEHbV6m2dVP
 eaDuSsTXpmS0bPcN3_fnLfVviz2YyS0BZfFNAjWsEZ_9MyH9POT_EUxDNNcpZB3sUFxwriRDOE_Z
 EuJbXqYKGsPbNlF_QzqRn1WBKpZpsJSrKNsK9jg1pIhkj1Ua3OHxKkMap2QT6fq5MDQLp1OPV9n7
 xY_CaeJk3A4qKuyqDRqmknrqq6KkIjcIYUrZTS0Ga.rMrv3In3dpEJybwuUdK37dxPwGS3dNZyjN
 QFGhYalQ7.wk9jHQDLjdW71SA0CdMXl7lm7okhdocQRpFYKtwMfKiw43_NK2sx1wqVZILoE3Ax9J
 dwmTQKbWw4dmfXmxyIl.DrOiyFz70YOItKh54uu.2US_ahrCCTXmZ6Xhbpz47KRT.Kk3VlbkcZdF
 D9JjsUP_hOkxZgoerjU_v5ZSpdo11Y1XECzQ5Uv_v2agTKbeAUoZYGQ376pMdwHRCHDYgYVF9b2S
 LRiO44q6oyJ9W1WSEkNhIGs9K9ePzlCoNTCmbdKJr64WWzPfYV0NykCTEJUd4yZkApR.dzUJ546H
 BOe6a4AQGplVIfUYZP47kccL4fmcE.Uk7MmBOVIHlOgIe59Zb9qCVhepNbqWh9p39D078tJrEoyD
 8zgAu1vXTNJHs4.U5ILxaqgLOiXxC48YGQg5VwgV.X4AvGIaMwkrE8xgCeHMkZ13UalZFWoCylze
 VKeGoj1wD3oYgmFkeHBHmzB2eyk_cQoe52lZxeQV5iSYuINP4Hp9_sFtUaNk5d5KTBVQQEFZ3Zrz
 fDAhfxkWvRmSPDnzFSnkM75hGUsEZT56MVvQ3x.uKtd6plv91SFW6dTt.Oh80d9XUefPkxnfqdQA
 BT1pyYKrVoSdVxtWBElMWPuRIwBzAuLqNor2xDqYI1g6oH29NrAU5HsPVTLfA3bxHZiQ.5XrZWDz
 F3oz0fttndUhpRiXfjr3zXxTfxAjRa..j.ex.wB1uBbn_vM8uHH9PqgF9vZHfAW6Rxe33SkCtcew
 DgrzkonOCA9h6Qyj91lZfZtwawRGwIRELRTKtqPHIJ5gJxM3T7__.1juUlTaZuny4WEFWP8MQB2w
 D.jvnRA8GVtPIGZC0aHAQ7h5SWG1VWhg8MQYrhh2ay4yJz0.WUx1838kDnMzs1FRSflLu3db.Kob
 lE4_C_n4KrbfrSW7iI7SZOkp5tYeppxDIXBdmdCi.eCYgho.jBDBbjaLehDmMC53YasxENJCivKJ
 AwzilH7Y0mAMfVoapvz4zkfmVekb6Sy0qluM4r93sWMTBO04ALsjYnREowuQn7KqQLKbRXtNxw8m
 KQdgsRZwSudBSaJqntc3IouxWZ91VLvYPK2MwWCN4d5JxCizrE8h5E0wSFDKTCNU9eKI6drPGnpM
 Go5OiCnmYXsl.RM0mTCbVHEo0rm_pWnjCfHQlacSf5lz6RK2cnHAoD94plQ2GNRnnQ.gwqbdgTbD
 er1p.qo0JszjkbV5smVBKWkBK7Z3drfDZR49UDyyppsPGYiLLbfiWW3mnN6nfMl4kJaHa7JypoXh
 k24fW4nORGpcMx7vfTQj8ZuOeKuWS_i1tLp03V6hquqm0j4GT2egifqhxDMpqO7.Gj4LiNbrWSah
 pfFG6J9Mx6Jjs
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Apr 2022 18:35:13 +0000
Received: by kubenode520.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4db1eb8961b7557807c3a6fe0e441a30;
          Sun, 10 Apr 2022 18:35: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Updating RPi boot materials, was Re: RPI4 panic on boot with
 -current
From: Mark Millard 
In-Reply-To: 
Date: Sun, 10 Apr 2022 11:35:09 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220409015321.GA52002@www.zefox.net>
 
 <20220409154433.GB55458@www.zefox.net>
 <1B2DD49C-96AD-4586-B9A7-F6D8386D4DE0@yahoo.com>
 <20220409221742.GB56550@www.zefox.net>
 <05CFCC3A-EE32-468A-9BDD-9A6104F572EE@yahoo.com>
 
 <20220410033906.GA57250@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kc0zF5ptZz4kHN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="iaK6/ivj";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10650
Lines: 274

[Just fixing a really bad typing mistake.]

On 2022-Apr-10, at 01:02, Mark Millard  wrote:

> On 2022-Apr-9, at 20:39, bob prohaska  wrote:
>=20
>> On Sat, Apr 09, 2022 at 05:22:49PM -0700, Mark Millard wrote:
>>>=20
>>>> So how are pkg or other such to deal with updating such generally
>>>> bootable media?
>>=20
>> I don't think they can be expected to update alien media.
>=20
> What alien media? Depending on how you have things set up for
> /etc/fstab use, likely your no-microsd-card-required USB3
> RPi4B media would boot the same list of machines that I
> indicated. ( I use labels to avoid numbering variations
> and reference the labels in /etc/fstab .)
>=20
>> There are lots of platform-specific ports for u-boot. Why not match
>> the install target to the named platform?
>=20
> And how does one do that?
>=20
>> If folks go to the trouble
>> of creating a port for a platform it's little extra work to add the
>> pathnames.
>=20
> Most Small Board Computers do not have file path names for
> U-Boot materials: They are put outside the file systems
> on the media. There is a "seek" position on the media.
> RPi*'s are fairly rare for putting such in a file system at
> all.
>=20
> For example, for the Rock64 the instructions for its U-Boot
> and related material are:
>=20
> QUOTE
> To install this bootloader on an sdcard just do:
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
> END QUOTE
>=20
> The dd commands are very dangerous when done inappropriately.
>=20
> "sdcarddevice" is only suggestive, since other types of
> devices are possible. In fact, the Rock64 I use boots via
> an e.MMC device that the board supports, not the microsd card
> slot. That is true even if a microsd card is in the slot at
> boot. As I remember, there is a jumper on the board for
> controlling which of the two is used by default.
>=20
> Lots of Small Board Computers have multiple devices that can
> hold the U-Boot involved, with some means of control over
> which is used.
>=20
>> What you're talking about seems far more ambitious.
>=20
> Seems you are viewing what you want to happen as
> trivially easy to make happen.
>=20
>>> I should have explicitly noted: How likely is that that I'd happen
>>> to always do FreeBSD updates on a aarch64 RPi* instead of one of
>>> the other systems, especially the faster ones? Is pkg to notice and
>>> update RPi* boot materials because the updated system could also
>>> boot an aarch64 RPi*?
>>>=20
>>=20
>> Presumably you'd cross compile a package for the intended target and
>> then install the package on the running target.
>=20
> All the machines I listed were aarch64: What cross compile?
>=20
> Your wording presumes that the target boots fine already. What
> about setting up the first boot ever for the target --or
> recovering from boot failures?
>=20
>> The platform details=20
>> would be part of the package.
>=20
> Which boot media is in use for the RPi* firmware and U-Boot stage
> is not a fixed property of RPi* platform: it can be used various
> ways via configuring it differently.
>=20
>> If the target is RPi3 and you're compiling=20
>> on Cavium, the RPi3 paths would be part of the package. The Cavium
>> won't be running the pkg install,
>=20
> As stands "pkg install" means putting the directory tree with the
> instructions and files under the likes of /usr/local/share/u-boot/ .
> You are creating a distinct operation and reuse of the terminology
> makes things are to talk about/follow.

"makes things hard to talk about/follow"

> But if a Cavium has USB ports or microsd card ports supported by
> FreeBSD, it certainly could be used to create the matching type of
> media for a RPi4B, including getting RPi* firmware and U-Boot in
> place, as well as EFI and UFS/ZFS material (same or different
> media).
>=20
> For the machines I listed in an earlier part of the exchange, they
> all can produce USB drives usable in booting all of the others --and
> I take great advantage of that. The two machines with PCIe slots
> can produce PCIe media used in booting that work in both. The Rock64
> can produce microsd card boot-media for any of the machines. And
> so it goes.
>=20
>> but I don't think that's possible
>> in any case. Both pkg and make install work on the host they're =
running=20
>> on, no? =20
>=20
> The assumption that things need to be run on the target system
> would be false. That is only one way of working when multiple
> systems are available for use.
>=20
>>> This better illustrates what I'm referring to when I reference pkg
>>> and the like identifying contexts and handling a variety of them.
>>> Should it be checking if it happens to be running on a RPi* and
>>> behave differently than it would on other types of systems (same
>>> boot media)?
>>>=20
>> That's the admin's discretion. He knows what the target architecture
>> is and the media being written.
>=20
> So it can not be automatic and the admin must do the work to
> set up something that matches the context --at least that sounds
> like what you are saying.
>=20
>>>> Or: Say that the RPi* has a msdosfs on its USB device that is
>>>> able to be used for booting. But that, at the time, there is
>>>> also a microsd card present that capable of being used for
>>>> booting, at least for the RPi* firmware and u-boot.bin stages.
>>>> What sort of activity is pkg supposed to do to identify the
>>>> context? How would pkg even identify, say, which way FreeBSD
>>>> had been booted?
>>>>=20
>>=20
>> I'd suggest this is an unrealistic scenario. Pkg can know what
>> files it's supposed to update, the admin has to make those files
>> accessible. If the wrong paths are mounted, that's a wetware problem.
>=20
> So, here the admin must know/remember where things need to be
> and set up the mounts, it is not automatic.
>=20
>>>> The early stages of RPi* booting are outside FreeBSD's direct
>>>> control and there are a lot of possibilities.
>>>>=20
>>=20
>> Yes, too many. The admin has to constrain them.
>=20
> Admin? FreeBSD? If the procedures are part of FreeBSD instead
> of being created by the Admin, it is not the Admin that is
> placing the constraints.
>=20
>>>> Nothing in FreeBSD says that /boot/msdos should exist or be the
>>>> mount point used as far as I know. It is just something that the
>>>> snapshot/PRERELEASE/BETA/RC/RELEASE images happen to currently,
>>>> do by the free choice of the author(s) involved.
>>>>=20
>>=20
>> But it does exist and is useful. Why not use it?
>=20
> Most Small Board Computers do not have U-Boot in any file
> system: no way to mount anything to /boot/msdos that would
> help with the typical dd commands for U-Boot (and related
> material). It only works for the files that go in a msdosfs.
> (RPi*'s are unusual for this.)
>=20
> So any such convention is of limited utility across the
> range of Small Board Computers.
>=20
>>>> In fact, if you tried to use bsdinstall to set up a RPi*
>>>> context, it would not set up something like the
>>>> snapshots/PRERELEASEs/BETAs/RCs/RELEASEs as far as I
>>>> know.
>>>>=20
>>=20
>> Can it work at all?
>=20
> As I remember, it can set up a EFI file system with FreeBSD's
> loader in it. The other files would have to be copied over
> (presuming the same media was the desired target for them).
>=20
>> I always prefered the installer whose man
>> page said it was "greaty in need of death".=20
>>=20
>>>> Nothing says that RPi*'s have to be set up the same as the
>>>> snapshot/PRERELEASE/BETA/RC/RELEASE images. The potential
>>>> differences in question are not part of FreeBSD.
>>>>=20
>>=20
>> But in practice they are, and it's useful for most folks.
>>=20
>>>> Another common convention is /boot/efi (especially when the
>>>> msdosfs invovled has the FreeBSD efi boot loader as well).
>>>> FreeBSD does now have some predefined behavior for this
>>>> convention.
>>>>=20
>>=20
>> Curiously, my Pi4 has an empty /boot/efi, but I've never
>> tampered with it.
>>=20
>>>> What if nothing is mounted to /boot/msdos or to /boot/efi
>>>> at the time (say, disabled in /etc/fstab)? How much analysis
>>>> of the context is pkg or such to do and adjust for?
>>>>=20
>>=20
>> Just report "path not found" and list what was expected.
>>=20
>>>> The FreeBSD loader.efi has the same sort of "there is no
>>>> fixed place for it" issue. Other than the /boot/efi use,
>>>> there is no automatic update of loader.efi either. This is
>>>> largely because the copy used to boot is not in a FreeBSD
>>>> UFS/ZFS file system at all --but in some msdosfs file
>>>> system, possibly with a special partition type.
>>>=20
>>=20
>> My plea is not for adaptability, but acceptance of convention.=20
>=20
> The convention does not work for most types of Small Board
> Computer U-Boot (and related) placements: Most use dd to
> someplace outside all file systems. RPi*'s are unusual in
> that they have u-boot.bin as a file in a file system. For
> example, /boot/msdosfs as a mount point does no good for
> U-Boot (or its related file) for a Rock64.
>=20
> Basically, you are asking for special handling of RPi*'s,
> at least relative to U-Boot.
>=20
>> Identify a platform and a location
>=20
> Normally: not a file system location at all for U-Boot.
>=20
>> then put that info in the
>> port install target. Let convention be set by the image.=20
>>=20
>=20
> Again: It is rare that a type of Small Board Computer has its
> U-Boot in any file system location.
>=20
> The assumption that most things are like RPi*'s is false based
> on what I've seen. For example (from README's of 4 u-boot ports
> for devices I use or have used):
>=20
> dd =
if=3D$LOCALBASE/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl=
.bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync
>=20
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
>=20
> dd =
if=3D$LOCALBASE/share/u-boot/u-boot-sinovoip-bpi-m3/u-boot-sunxi-with-spl.=
bin of=3D/path/to/sdcarddevice bs=3D1k seek=3D8 conv=3Dsync
>=20
> dd if=3D/usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin =
of=3D/path/to/sdcarddevice bs=3D128k seek=3D1 conv=3Dsync
>=20
> /boot/msdosfs mount point conventions do no good for any of those
> specific commands.
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 10 19:58:16 2022
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 BD39B1A811F5
	for ; Sun, 10 Apr 2022 19:58:17 +0000 (UTC)
	(envelope-from matteo@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 4Kc2px4x9Vz3F1W
	for ; Sun, 10 Apr 2022 19:58:17 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1649620697;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=9SGuYha58Ie2RT6wI7X3z9tFQc2NZqaAXaXdPSKVjLA=;
	b=W4b+a1SdJK8bMRJCQ/r0n94tV7Xv2geomp1N+Ovm7a0QMS5C5dlL9JyZv4/bvrf++nkFDF
	O6z/qPdiv3FjwLDgKEXn0uFvsFSLB6SsTxHa/exMVMbcTgvinkih1FOYIKKnvxNfcie2WL
	5oxVGz8rUW7aNZ40GG+v5avxz7dMfkZtZBKvo3cI595T7us0WRVJmF4fATu+St1EcmNq31
	kJV/dB5WglRm+zULuCPwUKflR8mTTM/ZTaOT7n3Drx+SlGT46ClpMNbzSDMyWeGMPVvUuz
	0Ak6jHoACN/vOzmccfcou3OwaOFyrSsV68ov8h+a9ZyOvmY1HrE1I0jiftGyYQ==
Received: from host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu (unknown [IPv6:2601:19b:4400:1779::102f])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 6DBE02834F
	for ; Sun, 10 Apr 2022 19:58:17 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Sun, 10 Apr 2022 15:58:16 -0400
From: Matteo Riondato 
To: freebsd-arm@freebsd.org
Subject: [armv7] dtb specified with FDT_DTS_FILE in kernconf not built when
 using release.sh
Message-ID: <20220410195816.k6qvkagroudas634@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="274se3atambhr2qv"
Content-Disposition: inline
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649620697;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=9SGuYha58Ie2RT6wI7X3z9tFQc2NZqaAXaXdPSKVjLA=;
	b=SxC9IKASF/IrJ5spQ0x7pia8JxEPamivS2CLLRHNTEdpOdB6gl3kIJDcVc7Z04BEWI6Dxn
	Lt2pgmQk2PqeyBeQyeVVSiC2D2twfrKS0wdkgTtDEdUML6Mg4ceaiTWlDDmHlmfDiXU4IM
	u9/ptwOPbQM7/oH7l+Gw2P88N6WTLnBOD5/YI1TVPVynOf5sP6GN9tTIYvGCmkL9IU/t7o
	AidQynhNbkB9bQog/3hn0fGA8k3qZRvmKLSp8TG4BWcnhFAIBU48AA5u9NAqbXKFFjj7uq
	MYZLaS0LKgx3bRZ+ZRZfcppxoMxqZbmgnyxFcttdK799AXD8BONWuNjXkuaIgg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649620697; a=rsa-sha256; cv=none;
	b=VX2c4mSf5W+5adRM4NyyGbUR+MIeVjyevcYy/T/5kcDmhUD01igMdUHSRETovxlso3UHz/
	jPCE1OXhGiZ2qwqDT+Lob+FLRgINf4C99LCRc55XaxiApZlgykmpgT4ZYQgEBpHCNIJNor
	SyBgV/Og2wHao0HJLxBT52sleYh2cCVHLHvWxtgTrA/zxjyrWh2uuvWcNORYqwvNyhJDbe
	Ol2dCxpnZofGW3uZNBqTDcfyhJ/Bj11pDY/co9+32dvRMZLs1a9OcXZMDZG3R3waRUCmMg
	p9BgTAWQuMU2Tr+36JSm5SUSFGBxd6g6mcyJyTyCN8CmHwB0go7Azx5Ac/wldw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2319
Lines: 62


--274se3atambhr2qv
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

I'm trying to cross-build (from amd64) a custom -CURRENT armv7 image for=20
my beaglebone enhanced using the release(7) method with a custom=20
release.conf script, which I wrote starting from release/arm/GENERICSD.

The only customization that I want to include is to use the appropriate=20
dtb compiled from the dts files for this board. I thought I could=20
achieve this goal by having "makeoptions FDT_DTS_FILE=3D..." in my=20
kernconf, but the dtb does not seem to be compiled in the chrootdir, not=20
to say installed, the image.

The kernconf is the following:

include GENERIC
include "../../conf/std.nodebug"
ident   GENERIC-ND-BBE
makeoptions FDT_DTS_FILE=3Dam335x-sancloud-bbe.dts

My release.conf script has a custom buildenv_setup() function to cp the
above kernconf to the /usr/src/sys/arm/conf/ directory of the chroot,=20
and the dts to /usr/src/sys/dts/arm of the chroot (from what I could=20
infer, that is the correct path for the dts, but please let me know if=20
that's not the case).

I don't see the compiled dtb anywhere in the chroot, nor an error=20
message or a warning that it failed to build, and it is not in the image=20
either.

What am I missing?

Thanks,
Matteo

--274se3atambhr2qv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmJTNtgTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAWrCD/wLxkrHZoUEYQD0XKsSUWoO+hJzS9Mp
TabHInrgerk9YbM0VfUlFWZv9LgiNIBbO2iRbS2U8Y8d1EA6cDeooc2BeKBpTeVx
C1OEv5wR5L/hqoBOE4ns2TTkwE9MtF7gRMFAMRJU5B8XBn8obWUOyIttmkOoauJa
85mZFmOfUwlIQW//aQhmlEfxcop2Nf2IbkOIHsM9XLbQsuivblJXj8e5EPwv5xkc
BI6a4BVuRPZOtmpSzA7uIZd4Brei9OYx0BTHPUPZapvEPLA0zv70/pS5PH080M/l
9XWU0snGq/X8fa1SHGBI71Tdu1d/pGEP0xo7eBmq2NGCB9yZ0T+Y/pF6i+UcC6Id
76plwlrt384Nge3mscpTD+7YGj2CTEj2XL6aaUA/SHRgdlm8FJVQjxmDA0LFh7m/
DS7U9DXzkqWz2xV24SvKk8m+AirFkNDqCzWy1xonnnxIjO91Mo4NccCJDl/+kiPk
hYOsl4K/QaqTnmz7u7fGpf5NlDVPxAG/aojlSv1QW3PpEWNWWeE2zZT1LTNkdHzq
8v9f7S0anYYneSdCsDcbjlV35YhX9y83tpuhodrR5M+JMHTwAyiVvDispQ8kI/fO
5IKyx171fRX7mpQvKQwFTaKb/68xe5xi20Zmr84XMyVvL6093QG/AsMq61oOEBgF
3iue0AEi5kVcjg==
=BrDR
-----END PGP SIGNATURE-----

--274se3atambhr2qv--

From nobody Sun Apr 10 20:15:30 2022
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 150B71A862A2
	for ; Sun, 10 Apr 2022 20:15:31 +0000 (UTC)
	(envelope-from mhorne@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 4Kc3Bq06dJz3Hcm;
	Sun, 10 Apr 2022 20:15:31 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1649621731;
	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=T1I+r2KnJqq/58zGEHOo+JGl75mlaWxznyVwp+lT6B4=;
	b=ym4YTMi4YAlXEv3oJnN77eRti5TaDWTplYYNtgeqaMW6NVg0rOT69BlKf2j4WQwoQk72et
	nQd/AMqAWE/j/M+ljALpogfFy9tgsUCWvuxkDP0HR6ld5gAApxQl1o8B+UtrgO1aiE4wrZ
	8NJsxbz9OOMtdaKW/7I4nVYyxU9MZ/xUUCwZNB8Dtcm+mj2tH5DvbgUHpmpX4yBrSk2spM
	+S76F+i49lUwqJFQNNaIJ5ld3N9VIB4MaoB32W6tGmHToOG6dftyBiKxeJWPrjVJa0TJME
	NC7Vrkfn7aoZ12Yclv21mOMcuo5saAmNtD1fNs6YmGWMj9u2LFM2NpnSqr0KDw==
Received: from [192.168.1.106] (host-71-7-134-180.public.eastlink.ca [71.7.134.180])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: mhorne)
	by smtp.freebsd.org (Postfix) with ESMTPSA id B228528361;
	Sun, 10 Apr 2022 20:15:30 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
Message-ID: <9b07e4bd-2b77-bab3-6844-e2e2873f582d@freebsd.org>
Date: Sun, 10 Apr 2022 17:15:30 -0300
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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [armv7] dtb specified with FDT_DTS_FILE in kernconf not built
 when using release.sh
Content-Language: en-CA
To: Matteo Riondato , freebsd-arm@freebsd.org
References: <20220410195816.k6qvkagroudas634@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
From: Mitchell Horne 
In-Reply-To: <20220410195816.k6qvkagroudas634@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649621731;
	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=T1I+r2KnJqq/58zGEHOo+JGl75mlaWxznyVwp+lT6B4=;
	b=B4J5K2V788SjQzvcb6HAXIiTbaafgI95jfAawe3bZP22ryiMxZxElwg9z+1fb3KcWlCCTe
	Gojr58vRyn9Ys2enyKP8AipPMRqSWbt7vHOjbtvmJ/z0LoI8w8nwiJpgUx9AOgS0NZrQ/P
	7A5g0KeS3wzZ9osP9E1PvEPkXhZ7OmZXSsu+3TdcPul24TbyzFhyzOq45ri4iM+Jlw2i/t
	2X6X1n036pQW4nQdV2KbodjH+XyO2xC0jdgF71RJNMpNpZAFTTjFspIKn2UDMWUcUWn2yw
	AfMRoesPANBc9i6Tm98dBnvRio1uGUXIzG944fd/ACI3nj8EiGlrMyHF9JMS2Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649621731; a=rsa-sha256; cv=none;
	b=gUyD081rMtby3R5Y+rsiTuFRtm50HbThHc0jgvw4GATTniZ0SgQ5lMf/kj7HnK+Wt1Hd2R
	62lQMyulfehPJElbiRz02jDestgnsA+rB/A04rIGwpZFljZMrCu80MTwk4TBAY8VCTKnrm
	4IPY1EgA83xi7XBKGTeusCqi6Mcyd9IM3PNx6p3Zt8zHm1kaOTWAr7xiRg1pp9zHUfKthk
	JYobvOA3y7HuuKAU7pqZUTCp0H5yaRMCg+jejawtmEav7qAqW13/tggfkbVznqaXg5dR+6
	ItevNMj/YNn3HeS/uUvCYz/ZAaV3a2pzu8hsIqZ2r8fC+YwCaiagKyQjFl5d/w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1700
Lines: 50



On 4/10/22 16:58, Matteo Riondato wrote:
> Hi,
> 
> I'm trying to cross-build (from amd64) a custom -CURRENT armv7 image for 
> my beaglebone enhanced using the release(7) method with a custom 
> release.conf script, which I wrote starting from release/arm/GENERICSD.
> 
> The only customization that I want to include is to use the appropriate 
> dtb compiled from the dts files for this board. I thought I could 
> achieve this goal by having "makeoptions FDT_DTS_FILE=..." in my 
> kernconf, but the dtb does not seem to be compiled in the chrootdir, not 
> to say installed, the image.
> 
> The kernconf is the following:
> 
> include GENERIC
> include "../../conf/std.nodebug"
> ident   GENERIC-ND-BBE
> makeoptions FDT_DTS_FILE=am335x-sancloud-bbe.dts
> 

I believe this option is used to embed a static DTB in the kernel 
binary, not to have it compiled as part of the build.

What you most likely want instead is:
     makeoptions MODULES_EXTRA+="dtb/am335x"

This line is already included as part of the GENERIC config. However, 
you will need to modify sys/modules/dtb/am335x/Makefile to include the 
sancloud variant that you are interested in.

Cheers,
Mitchell

> My release.conf script has a custom buildenv_setup() function to cp the
> above kernconf to the /usr/src/sys/arm/conf/ directory of the chroot, 
> and the dts to /usr/src/sys/dts/arm of the chroot (from what I could 
> infer, that is the correct path for the dts, but please let me know if 
> that's not the case).
> 
> I don't see the compiled dtb anywhere in the chroot, nor an error 
> message or a warning that it failed to build, and it is not in the image 
> either.
> 
> What am I missing?
> 
> Thanks,
> Matteo

From nobody Sun Apr 10 20:22:44 2022
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 D654E1A88A0F
	for ; Sun, 10 Apr 2022 20:22:45 +0000 (UTC)
	(envelope-from matteo@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 4Kc3M95l7sz3KRL;
	Sun, 10 Apr 2022 20:22:45 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1649622165;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=VyGk0zgsIT91YSBM6DsiDF/BgEENUGD28DCqjWGlJ8M=;
	b=kqhiLQH5bs+1G27/lPdieLH7xSq9jD8cz86HVY26L+YpoicjAiELp3d18oX8UJOTgo0lYP
	vzNB/p0c6Aj0hoNZCAjzUnFA8xTI2NLEi7zgB+j+fJOE4xTDMbmZ1DwhHaZhC5ZlpBiQH5
	tptgIT8+QM0q/HeceyV3ihJBQz647CYXzlPAkEANtzQqzWYb3+ak1msA9g/aw6QQQubkDw
	wU/Q7RgrKKXAMVK3vp/Mw8l/J2XY9UktKCN6RqClgZrljHOYnZxudBUj3ch0QkoV3VVRPn
	zMe8ZMScw55DVMeHbbOX1dXgfaUM56sV0O2z2dEAiejMkheukqwuHlo69VWdrg==
Received: from host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu (unknown [IPv6:2601:19b:4400:1779::102f])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 8606228B69;
	Sun, 10 Apr 2022 20:22:45 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Sun, 10 Apr 2022 16:22:44 -0400
From: Matteo Riondato 
To: Mitchell Horne 
Cc: freebsd-arm@freebsd.org
Subject: Re: [armv7] dtb specified with FDT_DTS_FILE in kernconf not built
 when using release.sh
Message-ID: <20220410202244.xkojjsg7ppri6nbc@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
References: <20220410195816.k6qvkagroudas634@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
 <9b07e4bd-2b77-bab3-6844-e2e2873f582d@freebsd.org>
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="k2sukini6sx6l3kl"
Content-Disposition: inline
In-Reply-To: <9b07e4bd-2b77-bab3-6844-e2e2873f582d@freebsd.org>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649622165;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=VyGk0zgsIT91YSBM6DsiDF/BgEENUGD28DCqjWGlJ8M=;
	b=bXfPF9Y27ggmts/lkDuz8o2MWFzU640kliGLq1JLuQ3DziihFAkYlXpWspTWmePFsIBAOB
	igw6FJc7xa5G7bTpzNvOBMke5hO9s0zgaLNk56N5jZGwwDzODO1xBwLDnnEfGhnWpNVTIV
	v+bGvXHnFzN/KgKSPs1iYA84aCBZFYbT8bnjt5rU+2irgWM6MkMuUr9GwvYDrxL6wzTFKs
	thFegEr46o3L1saq8usIJfP8krCh9IyDl6npFZkqP31kXHfdGt4SutqxFzzV4MKYqcjSz3
	r5qvwICABiSlMqJQSotj2zNfGuFFL9u3FXi1GfQYEyo0J5RJI/kdE69xQa9yCg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649622165; a=rsa-sha256; cv=none;
	b=RPovjYkIwo40vh6k2GVlx7pHq+4Gx5jj6zVtG34oHUArWfxgaOMWi7B7RSzKgbWc2k2JFk
	7sImdQYvj7+WCnq/ygH/gNlp+S1Uox8eRhtjyPW72Sp1wylwwFnzV6mMSunyEQttpUBmRe
	tja/ulkCdn0y50gIGQEE/OnnvdzYouexessxbkCyqqVpg8w1BrPCXTX+tCXBGh6TjOPzZj
	OA1fuOdSaIBMj+JcMQUSgeWGQxp3v+OrPcdDfcq7P3ssn0YhI9ano7K3HwjndoP0zrwPwa
	gdoU1zIN2BidWTvSnqfJTExxOOemu5gtm3u05bT1AeCQ4cqfMiid0vsnwsVDJQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1912
Lines: 51


--k2sukini6sx6l3kl
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-04-10 at 16:15 EDT, Mitchell Horne  wrote:
>On 4/10/22 16:58, Matteo Riondato wrote:
>>makeoptions FDT_DTS_FILE=3Dam335x-sancloud-bbe.dts
>
>I believe this option is used to embed a static DTB in the kernel=20
>binary, not to have it compiled as part of the build.

I see, I thought that a static DTB in the kernel would only be the case=20
if
options        FDT_DTB_STATIC
was also specified, and otherwise a standalone dtb would be compiled.

>What you most likely want instead is:=20
>    makeoptions MODULES_EXTRA+=3D"dtb/am335x"
>
>This line is already included as part of the GENERIC config. However,=20
>you will need to modify sys/modules/dtb/am335x/Makefile to include the=20
>sancloud variant that you are interested in.

I'll try that. Thank you.

Matteo

--k2sukini6sx6l3kl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmJTPJQTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAdnGD/9ZlhchZpUyqEuBDsFVTBKOQM5XEft5
D5/d5wb5NXcO9J7/oDctTyHks6rBrcTb8RFivqrchzkd7aYps5K8AUDaQ9NP2197
Bauf8Etqs3tRahYr7yeFLFyn29RxMltbdDS2GJcpKliq4JzST82viWpnJ1yyrmKU
eZp85B4OnqNMMxF2YEU0blWlKfXmFqaBTLX1j4qjKJeeV4OWb0PBYvVqeiWo78uh
sn3ibTcxRArAcH/HLcJqZW52YF7nJhqYxVpaKDlosS7p3L+L/4THai2872UQ3BCr
mma06buob9HaTlT9f/O4Rrw0oPDbjTkGTGQ1M/mUz5xUST3HHB0CgM65A2hbKO59
unk/x2OcqljihmMqWcz7hkKCt7BlF8LJyZBSMXXiYWz1rF6RHOZuco+sM2nNrw23
AxrRuM8tYiR4X/qEXRFalEeWnZKVUJck5BrvkvfkVjo88UWF4ZVovCHHh9tNs9/5
u7KkRCFn4gkppwMforB15BKp+u1I2vQgRQg3a7boE0qfNubqOwx96Sj+cpuZHJWs
B92aWVve+tlhJKbHMwb8W7HoQan4U/ay3XpzDpd2O2Dj/Pv2ztVyteRAJG2uRTjj
ulpjSt9OZPpNzXqOP8ETPU1SxDe5BaUmRsK1Y2yu7Ecr2w+QuLoRDkWdsN01/QcJ
QfVwzk3hUf8Gbw==
=XwPH
-----END PGP SIGNATURE-----

--k2sukini6sx6l3kl--

From nobody Sun Apr 10 21:01:01 2022
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 AEB621A95202
	for ; Sun, 10 Apr 2022 21:01:06 +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 4Kc4CN46xPz3j1j
	for ; Sun, 10 Apr 2022 21:01:04 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 67C7115F8E
	for ; Sun, 10 Apr 2022 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 23AL11na020170
	for ; Sun, 10 Apr 2022 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 23AL11x2020169
	for freebsd-arm@FreeBSD.org; Sun, 10 Apr 2022 21:01:01 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202204102101.23AL11x2020169@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, 10 Apr 2022 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="16496244611.715110EC.17147"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649624465;
	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=5PTYRhpSzkRwLgYkaaA06+XhnSOYlY+SUFYLwtsIAq0=;
	b=GWVTbjbaMFPsxerUHDFccDdRGpj08b4DKImX2mX8TRkEWTntpedqInoIg22Z1Eq2vDe1nM
	s3S7VAzOl4RgFo4q00y61/MR6oZv2ASfBt+YTPkEGpmiyV4TA8lv+q2ZqirY5LF3/qkmfI
	/JgNrrkisPHE0e0+drdz0He9hp4gIeE5sRoXW8uxV2KTc73U9BkpRQLztzKR3DyIXzVf8G
	QBRVLdrzVXsNSyXwiw1OgVLlPA6uxbfOr6O1FbUVOE0I95EmBrpBWxnx9mUs1cZl6DJ3Zz
	Ik8KTa9p6FtvXREjyE4Tnb3PS4bBHs3i9ocQQFhlqLFyS8CmkwXh0oHMjklb8Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649624465; a=rsa-sha256; cv=none;
	b=lSrGUq9JyUglpdW/zMK67TPCgvZS/FC/oI0h205Ig891AarDQP0+qIZ+/gsiTMbS+TKDXr
	qTH0Obb6WKzWzTQDkFpFILoxI5P5f0pONGM11pxnMrq7Feaw1A0g8xDVKsoogOlzhLOVbi
	VuIZwPdtM5FBaB1YrU5Yx98Zsm8egtw57vWsq0lV2aB3162Cimw/mRGJXzmNmLBgpIuKtt
	ec55KGtTCixlmyqN7oZ8UyVbk2Ctn1VKEPhEw41yT0chX3BO5Qm3SfMdWiDrmPIkmWp4nF
	/yjroJr4Dvlv1Ce1PNePHkU6BTfI9p7c4KuamkWgOt0Q0SFuiafUE10lGtm4SQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1807
Lines: 38


--16496244611.715110EC.17147
Date: Sun, 10 Apr 2022 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.

--16496244611.715110EC.17147
Date: Sun, 10 Apr 2022 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.


--16496244611.715110EC.17147--

From nobody Mon Apr 11 09:10:02 2022
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 933011A902ED
	for ; Mon, 11 Apr 2022 09:10:13 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KcNNh1NMnz3jtD
	for ; Mon, 11 Apr 2022 09:10:12 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 9BCEF2604AB;
	Mon, 11 Apr 2022 11:10:02 +0200 (CEST)
Message-ID: <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org>
Date: Mon, 11 Apr 2022 11:10:02 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: Raspberry Pi 3B Over-current USB
Content-Language: en-US
To: Archimedes Gaviola , freebsd-arm@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KcNNh1NMnz3jtD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7197
Lines: 175

On 4/9/22 20:04, Archimedes Gaviola wrote:
>   Hi,
> 
> I have a Prolific PL2303 USB-serial device when plugged-in to my Raspberry
> Pi 3B (14.0-CURRENT) will cause an over-current situation (enabled USB hub
> debugging hw.usb.uhub.debug=1) as observed in the dmesg below. All 4 ports
> got no power hence my USB keyboard was disconnected and stopped functioning
> and my PL2303 device wasn't able to get detected and load its uplcom(4)
> driver. However, the network is still okay in which I am able to access the
> system over SSH.
> 
> ukbd0:  on usbus1
> kbd1 at ukbd0
> lo0: link state changed to UP
> smsc0: chip 0xec00, rev. 0002
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> uhid0 on uhub1
> uhid0:  on usbus1
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> uhub_explore: Overcurrent on port 2.
> uhub_reattach_port: reattaching port 4
> ugen1.4:  at usbus1 (disconnected)
> ukbd0: at uhub1, port 4, addr 4 (disconnected)
> uhub_child_location: device not on hub
> uhub_child_pnpinfo: device not on hub
> ukbd0: detached
> uhid0: at uhub1, port 4, addr 4 (disconnected)
> uhub_child_location: device not on hub
> uhub_child_pnpinfo: device not on hub
> uhid0: detached
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> usb_needs_explore:
> usb_bus_powerd: bus=0xffff000089390000
> 
> Here's also the USB device info of my PL2303 device.
> 
> root@generic:~ # usbconfig -u 0 -a 5 dump_all_desc
>    ugen0.5:  at usbus0,
> cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0200
>    bDeviceClass = 0x0000  
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0040
>    idVendor = 0x067b
>    idProduct = 0x2303
>    bcdDevice = 0x0300
>    iManufacturer = 0x0001  
>    iProduct = 0x0002  
>    iSerialNumber = 0x0000  
>    bNumConfigurations = 0x0001
> 
>   Configuration index 0
> 
>      bLength = 0x0009
>      bDescriptorType = 0x0002
>      wTotalLength = 0x0027
>      bNumInterfaces = 0x0001
>      bConfigurationValue = 0x0001
>      iConfiguration = 0x0000  
>      bmAttributes = 0x00a0
>      bMaxPower = 0x0032
> 
>      Interface 0
>        bLength = 0x0009
>        bDescriptorType = 0x0004
>        bInterfaceNumber = 0x0000
>        bAlternateSetting = 0x0000
>        bNumEndpoints = 0x0003
>        bInterfaceClass = 0x00ff  
>        bInterfaceSubClass = 0x0000
>        bInterfaceProtocol = 0x0000
>        iInterface = 0x0000  
> 
>       Endpoint 0
>          bLength = 0x0007
>          bDescriptorType = 0x0005
>          bEndpointAddress = 0x0081  
>          bmAttributes = 0x0003  
>          wMaxPacketSize = 0x000a
>          bInterval = 0x0001
>          bRefresh = 0x0000
>          bSynchAddress = 0x0000
> 
>       Endpoint 1
>          bLength = 0x0007
>          bDescriptorType = 0x0005
>          bEndpointAddress = 0x0002  
>          bmAttributes = 0x0002  
>          wMaxPacketSize = 0x0040
>          bInterval = 0x0000
>          bRefresh = 0x0000
>          bSynchAddress = 0x0000
> 
>       Endpoint 2
>          bLength = 0x0007
>          bDescriptorType = 0x0005
>          bEndpointAddress = 0x0083  
>          bmAttributes = 0x0002  
>          wMaxPacketSize = 0x0040
>          bInterval = 0x0000
>          bRefresh = 0x0000
>          bSynchAddress = 0x0000
> 
> I'm using a USB port measuring device that can check the voltage and
> current usages and by default (without any USB devices attached) each port
> reads as 5.15 volts and 0.00 amperes for current of 3B. I'm using the
> official Raspberry Pi Stontronics power adapter with 5.1V with 2.5A DC
> output https://docs.rs-online.com/0c30/0900766b814dc7bb.pdf. From here due
> to over-current, I cannot obtain the actual power consumptions specific to
> my PL2303 device so I try installing the latest Raspberry Pi OS to check if
> it behaves the same. I found out that it has a similar behavior and
> experience getting over-current with additional under-voltage detected
> messages. However, it's interesting to observe that even in an over-current
> and under-voltage experience, all the ports are re-powered up and
> functioning and then able to load the PL2303 driver and I am able to use it
> via /dev/ttyUSB0 device. This time I could see the measuring device giving
> a 4.93 volts with 0.46 amperes of current (460mA) in the PL2303 device (see
> captured measurement here https://filebin.net/kqq664yf9w70omnh). Below is
> the dmesg log I've got from RPi OS.
> 
> [ 7490.507686] usb 1-1-port2: over-current change #3
> [ 7490.722717] usb 1-1.2: USB disconnect, device number 5
> [ 7491.006607] hwmon hwmon1: Undervoltage detected!
> [ 7491.094482] usb 1-1.5: new full-speed USB device number 7 using dwc_otg
> [ 7491.198613] usb 1-1.5: New USB device found, idVendor=067b,
> idProduct=2303, bcdDevice= 3.00
> [ 7491.198676] usb 1-1.5: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 7491.198700] usb 1-1.5: Product: USB-Serial Controller
> [ 7491.198722] usb 1-1.5: Manufacturer: Prolific Technology Inc.
> [ 7491.200210] pl2303 1-1.5:1.0: pl2303 converter detected
> [ 7491.206808] usb 1-1.5: pl2303 converter now attached to ttyUSB0
> [ 7491.209222] usb 1-1-port2: over-current change #4
> [ 7491.646484] usb 1-1.2: new low-speed USB device number 8 using dwc_otg
> [ 7491.770462] usb 1-1.2: New USB device found, idVendor=09da,
> idProduct=2267, bcdDevice= 1.05
> [ 7491.770515] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [ 7491.770539] usb 1-1.2: Product: USB Keyboard
> [ 7491.770560] usb 1-1.2: Manufacturer: A4Tech
> [ 7491.793771] input: A4Tech USB Keyboard as
> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:09DA:2267.0004/input/input6
> [ 7491.852612] hid-generic 0003:09DA:2267.0004: input,hidraw0: USB HID
> v1.11 Keyboard [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input0
> [ 7491.875068] input: A4Tech USB Keyboard as
> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:09DA:2267.0005/input/input7
> [ 7491.935697] hid-generic 0003:09DA:2267.0005: input,hidraw1: USB HID
> v1.11 Device [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input1
> [ 7495.038507] hwmon hwmon1: Voltage normalised
> 
> Though this experience is specific to the Raspberry 3B case, is there a way
> to enable this in FreeBSD? Knowing that there is dropping of voltage to
> 4.93 volts and current is 460mA which is still below the maximum of 500mA?
> 

You need an external self-powerd USB HUB.

--HPS


From nobody Mon Apr 11 13:59:08 2022
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 F2BC11A932CE
	for ; Mon, 11 Apr 2022 13:56:25 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b])
	(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 4KcVkw6rf4z3FN5
	for ; Mon, 11 Apr 2022 13:56:24 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x62b.google.com with SMTP id l7so25624939ejn.2
        for ; Mon, 11 Apr 2022 06:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=IBsCs9d6SJsf0dBykefFjJBdYbgBNujQoONptBR5ZAc=;
        b=OXa6FN0TGksSVmRYE05dkYCY2QX5a3MHFtkOs/kX6lUNpVqn6uVth1uCMMD4EQJqC4
         sf4ZiKntqk0DFghFLbPPALw6257xu2FLk3s6x/ntrpFFYvbYGlQARTlRxO+2TpZ4gfll
         YgHVOqw0L/gK/SgnBMOErwXIvLokGctpP1jS+XZFHXuw2upus6kQJFix+WhXQiuZ+VmB
         EPEqOSwSjszo4iXSZmkybSHmeuyiTC8CPE14SKzIkKNfzOWSGLHRm8sDlAFYxPBpH6bE
         l4QJKLIlW2A3ugxd/714DX90cdO/JTvvjS5TJ/xe6Yc8J03DNWJFkQZ/bIiLLJMKkVup
         xXWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=IBsCs9d6SJsf0dBykefFjJBdYbgBNujQoONptBR5ZAc=;
        b=esEd6uhAhhnjc7n9XrA+klm2NCCs8oGDHm0SLLvrLxKdI+x4PrxT9hJjylFFxzUPVi
         S87SSb6W8cA4wyPbrM/Xz3SZne0SfYoDMHavEMHunqdHgYtckNzK2E6qbgBDZx4njqF7
         56dwekZCLRghpIv8ip1cLKEDuNBV8jHGH4hFROhxAgcTXXGMr8T2Ht/xD65pDrVV2tDW
         UEqj42wj95DOWzACs8NrlY47PK7LF9ej3qvAjfYGRF/E01TCTJsDvs+UR0Ype7xeAzEY
         NOGM4wj/WX4KXGsvB083krZuO2RUhZqg/yb0WBTjZw4XD2s/eaz1SbbKGuLd7DJB43R1
         tMXA==
X-Gm-Message-State: AOAM531gYVEvrkbbOuU4wnSAycjPyzZAaLnOKmMk4qkjF2hXOTL7lHFd
	xqa/pS1AitNlaiXcH1dnVj1PA8z7AOg5iQ4Uzj4TQ7sFwAQ=
X-Google-Smtp-Source: ABdhPJy12UfCxtJYatfbGtr6hYi+XdXbWv8tf7Rspp6+KMdYR6DmPuaLlksNbH8KMHAKocdBYHe9E4RpHTtpVA8oswQ=
X-Received: by 2002:a17:906:5d14:b0:6e8:90d6:efe4 with SMTP id
 g20-20020a1709065d1400b006e890d6efe4mr4954019ejt.559.1649685383860; Mon, 11
 Apr 2022 06:56:23 -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: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org>
In-Reply-To: <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org>
From: Archimedes Gaviola 
Date: Mon, 11 Apr 2022 21:59:08 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Over-current USB
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000004bd56205dc614fc0"
X-Rspamd-Queue-Id: 4KcVkw6rf4z3FN5
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=OXa6FN0T;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.49 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.51)[0.510];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 43718
Lines: 907

--0000000000004bd56205dc614fc0
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 11, 2022 at 5:10 PM Hans Petter Selasky  wrote:

> On 4/9/22 20:04, Archimedes Gaviola wrote:
> >   Hi,
> >
> > I have a Prolific PL2303 USB-serial device when plugged-in to my
> Raspberry
> > Pi 3B (14.0-CURRENT) will cause an over-current situation (enabled USB
> hub
> > debugging hw.usb.uhub.debug=1) as observed in the dmesg below. All 4
> ports
> > got no power hence my USB keyboard was disconnected and stopped
> functioning
> > and my PL2303 device wasn't able to get detected and load its uplcom(4)
> > driver. However, the network is still okay in which I am able to access
> the
> > system over SSH.
> >
> > ukbd0:  on usbus1
> > kbd1 at ukbd0
> > lo0: link state changed to UP
> > smsc0: chip 0xec00, rev. 0002
> > ue0: link state changed to DOWN
> > ue0: link state changed to UP
> > uhid0 on uhub1
> > uhid0:  on usbus1
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > uhub_explore: Overcurrent on port 2.
> > uhub_reattach_port: reattaching port 4
> > ugen1.4:  at usbus1 (disconnected)
> > ukbd0: at uhub1, port 4, addr 4 (disconnected)
> > uhub_child_location: device not on hub
> > uhub_child_pnpinfo: device not on hub
> > ukbd0: detached
> > uhid0: at uhub1, port 4, addr 4 (disconnected)
> > uhub_child_location: device not on hub
> > uhub_child_pnpinfo: device not on hub
> > uhid0: detached
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> > usb_needs_explore:
> > usb_bus_powerd: bus=0xffff000089390000
> >
> > Here's also the USB device info of my PL2303 device.
> >
> > root@generic:~ # usbconfig -u 0 -a 5 dump_all_desc
> >    ugen0.5:  at usbus0,
> > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
> >    bLength = 0x0012
> >    bDescriptorType = 0x0001
> >    bcdUSB = 0x0200
> >    bDeviceClass = 0x0000  
> >    bDeviceSubClass = 0x0000
> >    bDeviceProtocol = 0x0000
> >    bMaxPacketSize0 = 0x0040
> >    idVendor = 0x067b
> >    idProduct = 0x2303
> >    bcdDevice = 0x0300
> >    iManufacturer = 0x0001  
> >    iProduct = 0x0002  
> >    iSerialNumber = 0x0000  
> >    bNumConfigurations = 0x0001
> >
> >   Configuration index 0
> >
> >      bLength = 0x0009
> >      bDescriptorType = 0x0002
> >      wTotalLength = 0x0027
> >      bNumInterfaces = 0x0001
> >      bConfigurationValue = 0x0001
> >      iConfiguration = 0x0000  
> >      bmAttributes = 0x00a0
> >      bMaxPower = 0x0032
> >
> >      Interface 0
> >        bLength = 0x0009
> >        bDescriptorType = 0x0004
> >        bInterfaceNumber = 0x0000
> >        bAlternateSetting = 0x0000
> >        bNumEndpoints = 0x0003
> >        bInterfaceClass = 0x00ff  
> >        bInterfaceSubClass = 0x0000
> >        bInterfaceProtocol = 0x0000
> >        iInterface = 0x0000  
> >
> >       Endpoint 0
> >          bLength = 0x0007
> >          bDescriptorType = 0x0005
> >          bEndpointAddress = 0x0081  
> >          bmAttributes = 0x0003  
> >          wMaxPacketSize = 0x000a
> >          bInterval = 0x0001
> >          bRefresh = 0x0000
> >          bSynchAddress = 0x0000
> >
> >       Endpoint 1
> >          bLength = 0x0007
> >          bDescriptorType = 0x0005
> >          bEndpointAddress = 0x0002  
> >          bmAttributes = 0x0002  
> >          wMaxPacketSize = 0x0040
> >          bInterval = 0x0000
> >          bRefresh = 0x0000
> >          bSynchAddress = 0x0000
> >
> >       Endpoint 2
> >          bLength = 0x0007
> >          bDescriptorType = 0x0005
> >          bEndpointAddress = 0x0083  
> >          bmAttributes = 0x0002  
> >          wMaxPacketSize = 0x0040
> >          bInterval = 0x0000
> >          bRefresh = 0x0000
> >          bSynchAddress = 0x0000
> >
> > I'm using a USB port measuring device that can check the voltage and
> > current usages and by default (without any USB devices attached) each
> port
> > reads as 5.15 volts and 0.00 amperes for current of 3B. I'm using the
> > official Raspberry Pi Stontronics power adapter with 5.1V with 2.5A DC
> > output https://docs.rs-online.com/0c30/0900766b814dc7bb.pdf. From here
> due
> > to over-current, I cannot obtain the actual power consumptions specific
> to
> > my PL2303 device so I try installing the latest Raspberry Pi OS to check
> if
> > it behaves the same. I found out that it has a similar behavior and
> > experience getting over-current with additional under-voltage detected
> > messages. However, it's interesting to observe that even in an
> over-current
> > and under-voltage experience, all the ports are re-powered up and
> > functioning and then able to load the PL2303 driver and I am able to use
> it
> > via /dev/ttyUSB0 device. This time I could see the measuring device
> giving
> > a 4.93 volts with 0.46 amperes of current (460mA) in the PL2303 device
> (see
> > captured measurement here https://filebin.net/kqq664yf9w70omnh). Below
> is
> > the dmesg log I've got from RPi OS.
> >
> > [ 7490.507686] usb 1-1-port2: over-current change #3
> > [ 7490.722717] usb 1-1.2: USB disconnect, device number 5
> > [ 7491.006607] hwmon hwmon1: Undervoltage detected!
> > [ 7491.094482] usb 1-1.5: new full-speed USB device number 7 using
> dwc_otg
> > [ 7491.198613] usb 1-1.5: New USB device found, idVendor=067b,
> > idProduct=2303, bcdDevice= 3.00
> > [ 7491.198676] usb 1-1.5: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [ 7491.198700] usb 1-1.5: Product: USB-Serial Controller
> > [ 7491.198722] usb 1-1.5: Manufacturer: Prolific Technology Inc.
> > [ 7491.200210] pl2303 1-1.5:1.0: pl2303 converter detected
> > [ 7491.206808] usb 1-1.5: pl2303 converter now attached to ttyUSB0
> > [ 7491.209222] usb 1-1-port2: over-current change #4
> > [ 7491.646484] usb 1-1.2: new low-speed USB device number 8 using dwc_otg
> > [ 7491.770462] usb 1-1.2: New USB device found, idVendor=09da,
> > idProduct=2267, bcdDevice= 1.05
> > [ 7491.770515] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [ 7491.770539] usb 1-1.2: Product: USB Keyboard
> > [ 7491.770560] usb 1-1.2: Manufacturer: A4Tech
> > [ 7491.793771] input: A4Tech USB Keyboard as
> >
> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:09DA:2267.0004/input/input6
> > [ 7491.852612] hid-generic 0003:09DA:2267.0004: input,hidraw0: USB HID
> > v1.11 Keyboard [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input0
> > [ 7491.875068] input: A4Tech USB Keyboard as
> >
> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:09DA:2267.0005/input/input7
> > [ 7491.935697] hid-generic 0003:09DA:2267.0005: input,hidraw1: USB HID
> > v1.11 Device [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input1
> > [ 7495.038507] hwmon hwmon1: Voltage normalised
> >
> > Though this experience is specific to the Raspberry 3B case, is there a
> way
> > to enable this in FreeBSD? Knowing that there is dropping of voltage to
> > 4.93 volts and current is 460mA which is still below the maximum of
> 500mA?
> >
>
> You need an external self-powerd USB HUB.
>

Hi Hans,

Noted on the self-powered hub, thanks for the suggestion, I will try.

Just wanted to share the observation from the testing I've conducted with
my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is
also experienced and it did, there was overcurrent and each ports' power
shut-off during the situation but it was able to recover back. I initiated
the command 'usbconfig reset' and each port gloriously came back alive one
by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
functional and operational states. My measuring device is showing the same
amount of current 460mA while the voltage stayed at 5.05 from a baseline of
5.15 volts https://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B, voltage
dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
observed is when the voltage dropped below 5, the system will not give a
chance to make the ports come back alive as a sort of protection mechanism.
Sharing to you the logs below (with hw.usb.uhub.debug=1).

usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
uhub_reset_tt_callback: TT buffer reset
uhub_reset_tt_callback: TT buffer reset
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
uhub_reattach_port: reattaching port 2
ugen0.3:  at usbus0 (disconnected)
ukbd0: at uhub1, port 2, addr 2 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
ukbd0: detached
uhid0: at uhub1, port 2, addr 2 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
uhid0: detached
uhub_explore: Overcurrent on port 3.
uhub_explore: Overcurrent on port 4.
uhub_explore: Overcurrent on port 2.
uhub_explore: Overcurrent on port 3.
uhub_explore: Overcurrent on port 4.
uhub_explore: Overcurrent on port 5.
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
uhub_explore: Overcurrent on port 1.
uhub_explore: Overcurrent on port 2.
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
uhub0: at usbus0, port 1, addr 1 (disconnected)
ugen0.2:  at usbus0 (disconnected)
uhub1: at uhub0, port 1, addr 1 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
uhub1: detached
uhub0: detached
uhub0 on usbus0
uhub0: <(0x1106) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub_attach: turn on port 1 power
uhub_attach: turn on port 2 power
usb_needs_explore:
uhub_attach: turn on port 3 power
uhub_attach: turn on port 4 power
uhub_attach: turn on port 5 power
uhub0: 5 ports with 4 removable, self powered
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
uhub_reattach_port: reattaching port 1
uhub_reattach_port: Port 1 is in Host Mode
usb_needs_explore:
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on
usbus0
uhub_attach: turn on port 1 power
uhub_attach: turn on port 2 power
uhub_attach: turn on port 3 power
uhub_attach: turn on port 4 power
uhub1: 4 ports with 4 removable, self powered
usb_needs_explore:
usbd_transfer_power_ref: Adding type 3 to power state
usbd_transfer_power_ref: needs power
uhub_explore: Overcurrent on port 1.
uhub_reattach_port: reattaching port 1
uhub_explore: Overcurrent on port 2.
uhub_reattach_port: reattaching port 2
uhub_explore: Overcurrent on port 3.
uhub_reattach_port: reattaching port 3
uhub_reattach_port: Port 3 is in Host Mode
usb_needs_explore:
ugen0.3:  at usbus0
uhub_explore: Overcurrent on port 4.
uhub_reattach_port: reattaching port 4
uhub_explore: Overcurrent on port 2.
uhub_reattach_port: reattaching port 2
uhub_explore: Overcurrent on port 3.
uhub_reattach_port: reattaching port 3
uhub_explore: Overcurrent on port 4.
uhub_reattach_port: reattaching port 4
uhub_explore: Overcurrent on port 5.
uhub_reattach_port: reattaching port 5
usb_bus_powerd: bus=0xffff000091fcb428
usb_needs_explore:
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
uplcom0 on uhub1
uplcom0:  on usbus0
usb_bus_powerd: bus=0xffff000091fcb428
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs power

Thanks,
Archimedes

--0000000000004bd56205dc614fc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Apr 11, 2022 at 5:10 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 4/9=
/22 20:04, Archimedes Gaviola wrote:

>=C2=A0 =C2=A0Hi,

> 

> I have a Prolific PL2303 USB-serial device when plugged-in to my Raspb=
erry

> Pi 3B (14.0-CURRENT) will cause an over-current situation (enabled USB=
 hub

> debugging hw.usb.uhub.debug=3D1) as observed in the dmesg below. All 4=
 ports

> got no power hence my USB keyboard was disconnected and stopped functi=
oning

> and my PL2303 device wasn't able to get detected and load its uplc=
om(4)

> driver. However, the network is still okay in which I am able to acces=
s the

> system over SSH.

> 

> ukbd0: <A4Tech USB Keyboard, class 0/0, rev 2.00/1.05, addr 4> o=
n usbus1

> kbd1 at ukbd0

> lo0: link state changed to UP

> smsc0: chip 0xec00, rev. 0002

> ue0: link state changed to DOWN

> ue0: link state changed to UP

> uhid0 on uhub1

> uhid0: <A4Tech USB Keyboard, class 0/0, rev 2.00/1.05, addr 4> o=
n usbus1

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> uhub_explore: Overcurrent on port 2.

> uhub_reattach_port: reattaching port 4

> ugen1.4: <A4Tech USB Keyboard> at usbus1 (disconnected)

> ukbd0: at uhub1, port 4, addr 4 (disconnected)

> uhub_child_location: device not on hub

> uhub_child_pnpinfo: device not on hub

> ukbd0: detached

> uhid0: at uhub1, port 4, addr 4 (disconnected)

> uhub_child_location: device not on hub

> uhub_child_pnpinfo: device not on hub

> uhid0: detached

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> usb_needs_explore:

> usb_bus_powerd: bus=3D0xffff000089390000

> 

> Here's also the USB device info of my PL2303 device.

> 

> root@generic:~ # usbconfig -u 0 -a 5 dump_all_desc

>=C2=A0 =C2=A0 ugen0.5: <Prolific Technology Inc. USB-Serial Controll=
er> at usbus0,

> cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)

>=C2=A0 =C2=A0 bLength =3D 0x0012

>=C2=A0 =C2=A0 bDescriptorType =3D 0x0001

>=C2=A0 =C2=A0 bcdUSB =3D 0x0200

>=C2=A0 =C2=A0 bDeviceClass =3D 0x0000=C2=A0 <Probed by interface cla=
ss>

>=C2=A0 =C2=A0 bDeviceSubClass =3D 0x0000

>=C2=A0 =C2=A0 bDeviceProtocol =3D 0x0000

>=C2=A0 =C2=A0 bMaxPacketSize0 =3D 0x0040

>=C2=A0 =C2=A0 idVendor =3D 0x067b

>=C2=A0 =C2=A0 idProduct =3D 0x2303

>=C2=A0 =C2=A0 bcdDevice =3D 0x0300

>=C2=A0 =C2=A0 iManufacturer =3D 0x0001=C2=A0 <Prolific Technology In=
c.>

>=C2=A0 =C2=A0 iProduct =3D 0x0002=C2=A0 <USB-Serial Controller>
>=C2=A0 =C2=A0 iSerialNumber =3D 0x0000=C2=A0 <no string>

>=C2=A0 =C2=A0 bNumConfigurations =3D 0x0001

> 

>=C2=A0 =C2=A0Configuration index 0

> 

>=C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0009

>=C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0002

>=C2=A0 =C2=A0 =C2=A0 wTotalLength =3D 0x0027

>=C2=A0 =C2=A0 =C2=A0 bNumInterfaces =3D 0x0001

>=C2=A0 =C2=A0 =C2=A0 bConfigurationValue =3D 0x0001

>=C2=A0 =C2=A0 =C2=A0 iConfiguration =3D 0x0000=C2=A0 <no string><=
br>
>=C2=A0 =C2=A0 =C2=A0 bmAttributes =3D 0x00a0

>=C2=A0 =C2=A0 =C2=A0 bMaxPower =3D 0x0032

> 

>=C2=A0 =C2=A0 =C2=A0 Interface 0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0009

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0004

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceNumber =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bAlternateSetting =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bNumEndpoints =3D 0x0003

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <Vendor=
 specific>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceProtocol =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 iInterface =3D 0x0000=C2=A0 <no string&g=
t;

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Endpoint 0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0007

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0005

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddress =3D 0x0081=C2=A0 &l=
t;IN>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttributes =3D 0x0003=C2=A0 <IN=
TERRUPT>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wMaxPacketSize =3D 0x000a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterval =3D 0x0001

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bSynchAddress =3D 0x0000

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Endpoint 1

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0007

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0005

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddress =3D 0x0002=C2=A0 &l=
t;OUT>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttributes =3D 0x0002=C2=A0 <BU=
LK>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wMaxPacketSize =3D 0x0040

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterval =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bSynchAddress =3D 0x0000

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Endpoint 2

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bLength =3D 0x0007

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bDescriptorType =3D 0x0005

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bEndpointAddress =3D 0x0083=C2=A0 &l=
t;IN>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bmAttributes =3D 0x0002=C2=A0 <BU=
LK>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wMaxPacketSize =3D 0x0040

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterval =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bRefresh =3D 0x0000

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bSynchAddress =3D 0x0000

> 

> I'm using a USB port measuring device that can check the voltage a=
nd

> current usages and by default (without any USB devices attached) each =
port

> reads as 5.15 volts and 0.00 amperes for current of 3B. I'm using =
the

> official Raspberry Pi Stontronics power adapter with 5.1V with 2.5A DC=


> output https://docs.rs-online.com/0c30/0900=
766b814dc7bb.pdf. From here due

> to over-current, I cannot obtain the actual power consumptions specifi=
c to

> my PL2303 device so I try installing the latest Raspberry Pi OS to che=
ck if

> it behaves the same. I found out that it has a similar behavior and
> experience getting over-current with additional under-voltage detected=


> messages. However, it's interesting to observe that even in an ove=
r-current

> and under-voltage experience, all the ports are re-powered up and

> functioning and then able to load the PL2303 driver and I am able to u=
se it

> via /dev/ttyUSB0 device. This time I could see the measuring device gi=
ving

> a 4.93 volts with 0.46 amperes of current (460mA) in the PL2303 device=
 (see

> captured measurement here https://filebin.net/kqq664yf9w70o=
mnh). Below is

> the dmesg log I've got from RPi OS.

> 

> [ 7490.507686] usb 1-1-port2: over-current change #3

> [ 7490.722717] usb 1-1.2: USB disconnect, device number 5

> [ 7491.006607] hwmon hwmon1: Undervoltage detected!

> [ 7491.094482] usb 1-1.5: new full-speed USB device number 7 using dwc=
_otg

> [ 7491.198613] usb 1-1.5: New USB device found, idVendor=3D067b,

> idProduct=3D2303, bcdDevice=3D 3.00

> [ 7491.198676] usb 1-1.5: New USB device strings: Mfr=3D1, Product=3D2=
,

> SerialNumber=3D0

> [ 7491.198700] usb 1-1.5: Product: USB-Serial Controller

> [ 7491.198722] usb 1-1.5: Manufacturer: Prolific Technology Inc.

> [ 7491.200210] pl2303 1-1.5:1.0: pl2303 converter detected

> [ 7491.206808] usb 1-1.5: pl2303 converter now attached to ttyUSB0

> [ 7491.209222] usb 1-1-port2: over-current change #4

> [ 7491.646484] usb 1-1.2: new low-speed USB device number 8 using dwc_=
otg

> [ 7491.770462] usb 1-1.2: New USB device found, idVendor=3D09da,

> idProduct=3D2267, bcdDevice=3D 1.05

> [ 7491.770515] usb 1-1.2: New USB device strings: Mfr=3D1, Product=3D2=
,

> SerialNumber=3D0

> [ 7491.770539] usb 1-1.2: Product: USB Keyboard

> [ 7491.770560] usb 1-1.2: Manufacturer: A4Tech

> [ 7491.793771] input: A4Tech USB Keyboard as

> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:09DA:=
2267.0004/input/input6

> [ 7491.852612] hid-generic 0003:09DA:2267.0004: input,hidraw0: USB HID=


> v1.11 Keyboard [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input0
> [ 7491.875068] input: A4Tech USB Keyboard as

> /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:09DA:=
2267.0005/input/input7

> [ 7491.935697] hid-generic 0003:09DA:2267.0005: input,hidraw1: USB HID=


> v1.11 Device [A4Tech USB Keyboard] on usb-3f980000.usb-1.2/input1

> [ 7495.038507] hwmon hwmon1: Voltage normalised

> 

> Though this experience is specific to the Raspberry 3B case, is there =
a way

> to enable this in FreeBSD? Knowing that there is dropping of voltage t=
o

> 4.93 volts and current is 460mA which is still below the maximum of 50=
0mA?

> 



You need an external self-powerd USB HUB.

Hi=
 Hans,

Noted on the self-powered hub, thanks for the suggestion, I will try.
<=
/div>

Just w=
anted to share the observation from the testing I've conducted with my =
Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is also =
experienced and it did, there was overcurrent and each ports' power shu=
t-off during the situation but it was able to recover back. I initiated the=
 command 'usbconfig reset' and each port gloriously came back alive=
 one by one and loaded my USB keyboard and Prolific uplcom(4) drivers into =
functional and operational states. My measuring device is showing the same =
amount of current 460mA while the voltage stayed at 5.05 from a baseline of=
 5.15 volts https://filebi=
n.net/10vy575q6h2yl8og. Unlike my RPi 3B, voltage dropped to 4.93 from =
a baseline of 5.19 volts. So, the difference I observed is when the voltage=
 dropped below 5, the system will not give a chance to make the ports come =
back alive as a sort of protection mechanism. Sharing to you the logs below=
 (with hw.usb.uhub.debug=3D1).


usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_needs=
_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: =
Adding type 0 to power state
usbd_transfer_power_ref: needs power
usb=
_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfe=
r_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs=
 power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fc=
b428
usb_bus_powerd: Recomputing power masksusbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_pow=
er_ref: needs power
uhub_reset_tt_callback: TT buffer reset
uh=
ub_reset_tt_callback: TT buffer reset
usb_needs_explore:
usb_bus_powe=
rd: bus=3D0xffff000091fcb428
uhub_reattach_port: reattaching port 2
u=
gen0.3: <A4Tech USB Keyboard> at usbus0 (disconnected)
ukbd0: at u=
hub1, port 2, addr 2 (disconnected)
uhub_child_=
location: device not on hub
uhub_child_pnpinfo: device not on hub
ukbd0: detached
uhid0: at uhub1, port 2, addr 2 (disconnected)
uhub_child_location: device not on hub
uhub_child=
_pnpinfo: device not on hub
uhid0: detached
uhub_explore: Over=
current on port 3.
uhub_explore: Overcurrent on port 4.
uhub_explore: Overcurrent on port 2.
uhub_explore: Ov=
ercurrent on port 3.
uhub_explore: Overcurrent on port 4.
uhub_explor=
e: Overcurrent on port 5.
usb_needs_explore:
usb_bus_powerd: bus=3D0x=
ffff000091fcb428
uhub_explore: Overcurrent on port 1.
uhub_explore: Overcurrent on port 2.
usb_needs_explore:=

usb_bus_powerd: bus=3D0xffff000091fcb428
usb_needs_explore:
usb_b=
us_powerd: bus=3D0xffff000091fcb428
usb_bus_pow=
erd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to p=
ower state
usbd_transfer_power_ref: needs power
usb_needs_explore:usb_bus_powerd: bus=3D0xffff000091fcb428usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Addin=
g type 0 to power state
usbd_transfer_power_ref: needs power
usb_need=
s_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_pow=
er_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs powe=
r
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428<=
span class=3D"gmail-im">
usb_bus_powerd: Recomputing power masks
usbd=
_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_re=
f: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff=
000091fcb428
usb_bus_powerd: Recomputing power =
masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_tran=
sfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd:=
 bus=3D0xffff000091fcb428
usb_bus_powerd: Recom=
puting power masks
usbd_transfer_power_ref: Adding type 0 to power state=

usbd_transfer_power_ref: needs power
usb_needs_explore:
us=
b_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_=
powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 t=
o power state
usbd_transfer_power_ref: needs power
usb_needs_explore:=

usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Ad=
ding type 0 to power state
usbd_transfer_power_ref: needs power
usb_n=
eeds_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_=
power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs p=
ower
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb4=
28
usb_bus_powerd: Recomputing power masks
u=
sbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power=
_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xf=
fff000091fcb428
usb_bus_powerd: Recomputing pow=
er masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_t=
ransfer_power_ref: needs power
usb_needs_explore:
usb_bus_powe=
rd: bus=3D0xffff000091fcb428
usb_bus_powerd: Re=
computing power masks
usbd_transfer_power_ref: Adding type 0 to power st=
ate
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_b=
us_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type =
0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explo=
re:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref:=
 Adding type 0 to power state
usbd_transfer_power_ref: needs power
us=
b_needs_explore:
uhub0: at usbus0, port 1, addr 1 (disconnected)
ugen=
0.2: <vendor 0x2109 USB2.0 Hub> at usbus0 (disconnected)
uhub1: at=
 uhub0, port 1, addr 1 (disconnected)
uhub_child_location: device not on=
 hub
uhub_child_pnpinfo: device not on hub
uhub1: detached
uhub0: =
detached
uhub0 on usbus0
uhub0: <(0x1106) XHCI root HUB, class 9/0=
, rev 3.00/1.00, addr 1> on usbus0
uhub_attach: turn on port 1 power<=
br>uhub_attach: turn on port 2 power
usb_needs_explore:
uhub_attach: turn on port 3 power
uhub_attach: turn o=
n port 4 power
uhub_attach: turn on port 5 power
uhub0: 5 ports with =
4 removable, self powered
usb_needs_explore:
usb_bus_powerd: b=
us=3D0xffff000091fcb428
usb_bus_powerd: Recompu=
ting power masks
uhub_reattach_port: reattaching port 1
uhub_reattach=
_port: Port 1 is in Host Mode
usb_needs_explore:
usbd_transfer_power_=
ref: Adding type 0 to power state
usbd_transfer_power_ref: needs powerugen0.2: <vendor 0x2109 USB2.0 Hub> at usbus0
uhub1 on uhub0
=
uhub1: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.20, addr 1> o=
n usbus0
uhub_attach: turn on port 1 power
uhub_attach: turn on port =
2 power
uhub_attach: turn on port 3 power
uhub_attach: turn on port 4=
 power
uhub1: 4 ports with 4 removable, self powered
usb_needs_explor=
e:
usbd_transfer_power_ref: Adding type 3 to power state
usbd_transfe=
r_power_ref: needs power
uhub_explore: Overcurrent on port 1.
=
uhub_reattach_port: reattaching port 1
uhub_exp=
lore: Overcurrent on port 2.
uhub_reattach_port: reattaching port=
 2
uhub_explore: Overcurrent on port 3.
uhub_reattach_port: reattachi=
ng port 3
uhub_reattach_port: Port 3 is in Host Mode
usb_needs_explor=
e:
ugen0.3: <Prolific Technology Inc. USB-Se=
rial Controller> at usbus0
uhub_explore: Overcurrent on port 4=
.
uhub_reattach_port: reattaching port 4
uhu=
b_explore: Overcurrent on port 2.
uhub_reattach_port: reattaching=
 port 2
uhub_explore: Overcurrent on port 3.
uhub_reattach_port: reat=
taching port 3
uhub_explore: Overcurrent on port 4.
uhub_reattach_por=
t: reattaching port 4
uhub_explore: Overcurrent on port 5.
uhub_reatt=
ach_port: reattaching port 5
usb_bus_powerd: bus=3D0xffff000091fcb428usb_needs_explore:
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff00=
0091fcb428
uplcom0 on uhub1
uplcom0: <Pro=
lific Technology Inc. USB-Serial Controller, class 0/0, rev 2.00/3.00, addr=
 2> on usbus0
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_=
needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_=
ref: Adding type 0 to power state
usbd_transfer_power_ref: needs powerusb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_tr=
ansfer_power_ref: Adding type 0 to power state
usbd_transfer_power_ref: =
needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000=
091fcb428
usb_bus_powerd: Recomputing power mas=
ks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_transfe=
r_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bu=
s=3D0xffff000091fcb428
usb_bus_powerd: Recomput=
ing power masks
usbd_transfer_power_ref: Adding type 0 to power stateusbd_transfer_power_ref: needs power
usb_needs_explore:
usb_b=
us_powerd: bus=3D0xffff000091fcb428
usb_bus_pow=
erd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 to p=
ower state
usbd_transfer_power_ref: needs power
usb_needs_explore:usb_bus_powerd: bus=3D0xffff000091fcb428usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Addin=
g type 0 to power state
usbd_transfer_power_ref: needs power
usb_need=
s_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_pow=
er_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs powe=
r
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428<=
span class=3D"gmail-im">
usb_bus_powerd: Recomputing power masks
usbd=
_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power_re=
f: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff=
000091fcb428
usb_bus_powerd: Recomputing power =
masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_tran=
sfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd:=
 bus=3D0xffff000091fcb428
usb_bus_powerd: Recom=
puting power masks
usbd_transfer_power_ref: Adding type 0 to power state=

usbd_transfer_power_ref: needs power
usb_needs_explore:
us=
b_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_=
powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type 0 t=
o power state
usbd_transfer_power_ref: needs power
usb_needs_explore:=

usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref: Ad=
ding type 0 to power state
usbd_transfer_power_ref: needs power
usb_n=
eeds_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_=
power_ref: Adding type 0 to power state
usbd_transfer_power_ref: needs p=
ower
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb4=
28
usb_bus_powerd: Recomputing power masks
u=
sbd_transfer_power_ref: Adding type 0 to power state
usbd_transfer_power=
_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xf=
fff000091fcb428
usb_bus_powerd: Recomputing pow=
er masks
usbd_transfer_power_ref: Adding type 0 to power state
usbd_t=
ransfer_power_ref: needs power
usb_needs_explore:
usb_bus_powe=
rd: bus=3D0xffff000091fcb428
usb_bus_powerd: Re=
computing power masks
usbd_transfer_power_ref: Adding type 0 to power st=
ate
usbd_transfer_power_ref: needs power
usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_b=
us_powerd: Recomputing power masks
usbd_transfer_power_ref: Adding type =
0 to power state
usbd_transfer_power_ref: needs power
usb_needs_explo=
re:
usb_bus_powerd: bus=3D0xffff000091fcb428
usb_bus_powerd: Recomputing power masks
usbd_transfer_power_ref:=
 Adding type 0 to power state
usbd_transfer_power_ref: needs power

Thanks,
Archimedes




=C2=
=A0 


--0000000000004bd56205dc614fc0--

From nobody Mon Apr 11 13:59:10 2022
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 2C5F21A94A65
	for ; Mon, 11 Apr 2022 13:59:20 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KcVpH0m3yz3G1x
	for ; Mon, 11 Apr 2022 13:59:18 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 4CE99260189;
	Mon, 11 Apr 2022 15:59:10 +0200 (CEST)
Message-ID: <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org>
Date: Mon, 11 Apr 2022 15:59:10 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: Raspberry Pi 3B Over-current USB
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KcVpH0m3yz3G1x
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.13 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-0.83)[-0.828];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1161
Lines: 22

On 4/11/22 15:59, Archimedes Gaviola wrote:
> Hi Hans,
> 
> Noted on the self-powered hub, thanks for the suggestion, I will try.
> 
> Just wanted to share the observation from the testing I've conducted with
> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is
> also experienced and it did, there was overcurrent and each ports' power
> shut-off during the situation but it was able to recover back. I initiated
> the command 'usbconfig reset' and each port gloriously came back alive one
> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
> functional and operational states. My measuring device is showing the same
> amount of current 460mA while the voltage stayed at 5.05 from a baseline of
> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B, voltage
> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
> observed is when the voltage dropped below 5, the system will not give a
> chance to make the ports come back alive as a sort of protection mechanism.
> Sharing to you the logs below (with hw.usb.uhub.debug=1).

FreeBSD does not actively check and use "bMaxPower" .

--HPS

From nobody Tue Apr 12 09:16:02 2022
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 EEC3411E68E0
	for ; Tue, 12 Apr 2022 09:15:08 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636])
	(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 4Kd0Rw17fvz3j8M
	for ; Tue, 12 Apr 2022 09:15:08 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-ej1-x636.google.com with SMTP id l7so30601123ejn.2
        for ; Tue, 12 Apr 2022 02:15:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=bFSNv5q39P+q4OlfhKZIevLrgeqrtexoZ+b/8GRgH2A=;
        b=dTSgT91CVYtUuju5zUJE/gdtCLhh5GHFPUlpGD48huIW1/WlNxoVIqIJKiswvvi97R
         aQ6NT3UEimUvFGNprUrJ8LDnE4E52sy198nMpJ43AFcGw1sa3vus57bXVbG4yWUdE3JC
         /JY2REMCEi+WDIYcn92juXesMx+3W4aF0j7ztAkhRbJmnDRUUGTSOqHSagdUb73/cO0L
         mbDsobmFzh8PDluTBPjw31rXp8br9wXPRGc+vvPZZ+gvDaSh2n4ehDlQAbN2BaPfn7qB
         +6gYDSSLeDzd2HCJjkPsu1k4NedUx+5EmVyfP2t4+8pVMedF0Khgp1UOwq+DbElKCwLO
         A/Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=bFSNv5q39P+q4OlfhKZIevLrgeqrtexoZ+b/8GRgH2A=;
        b=MVWWAoC5a4Z6R8AiqboBmjpvVA/cXEF8bkqO8YJyryUbaWY1qX+sC9vxvR1sbsdsZb
         sauz3/R1CXhFtVfa1ovDtu8LQgTajBKZ75n5Bdt2EwbAW9jTHi/nyleQbtf1AzHb6Gm7
         gBZOnkPQDTTAjJEm6qUXFyyKphFW6n2F0VAV9s1PWzSQInMMxoR8wzMnEayT4feL9lpp
         s8xbGeL/fJlFm5gJqvz84e45j3aegVs8xXWKGygxv0K4EtKQMPt8rstrwdM+d8s487fa
         /MQfAq5bCJCFkcOPfzmM75qDKfVAxTRnt7yEPNeFds5lZd353d3x2eQDoB2HnFAlA3ZB
         DzAg==
X-Gm-Message-State: AOAM531byEP+opeSvGfzzT+tuadxjyeNUZL1QDU3j+J7CU8tVNIG+PZC
	Ud+8bsEzh0JcNp0AaDXCzw4uKId2GJxGRTLPDif2X+5ARVE=
X-Google-Smtp-Source: ABdhPJwxLMm/l/doryddTs3oGqGHkVay6riUU6wMH5q5G6mo/KBDqXdf7z+TJB/mFrHe+274GVXOMP4kubRjWkkvkEA=
X-Received: by 2002:a17:907:a41f:b0:6d6:f925:1696 with SMTP id
 sg31-20020a170907a41f00b006d6f9251696mr34367536ejc.62.1649754907122; Tue, 12
 Apr 2022 02:15:07 -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: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org> 
 <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org>
In-Reply-To: <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org>
From: Archimedes Gaviola 
Date: Tue, 12 Apr 2022 17:16:02 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Over-current USB
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000349e6605dc717f72"
X-Rspamd-Queue-Id: 4Kd0Rw17fvz3j8M
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=dTSgT91C;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3803
Lines: 90

--000000000000349e6605dc717f72
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky  wrote:

> On 4/11/22 15:59, Archimedes Gaviola wrote:
> > Hi Hans,
> >
> > Noted on the self-powered hub, thanks for the suggestion, I will try.
> >
> > Just wanted to share the observation from the testing I've conducted with
> > my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is
> > also experienced and it did, there was overcurrent and each ports' power
> > shut-off during the situation but it was able to recover back. I
> initiated
> > the command 'usbconfig reset' and each port gloriously came back alive
> one
> > by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
> > functional and operational states. My measuring device is showing the
> same
> > amount of current 460mA while the voltage stayed at 5.05 from a baseline
> of
> > 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,
> voltage
> > dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
> > observed is when the voltage dropped below 5, the system will not give a
> > chance to make the ports come back alive as a sort of protection
> mechanism.
> > Sharing to you the logs below (with hw.usb.uhub.debug=1).
>
> FreeBSD does not actively check and use "bMaxPower" .
>

Hi Hans,

It's okay, just tried your recommendation on a self-powered USB hub, my
Prolific device is now working. Thanks a lot!

Archimedes

--000000000000349e6605dc717f72
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Apr 11, 2022 at 9:59 PM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 4/1=
1/22 15:59, Archimedes Gaviola wrote:

> Hi Hans,

> 

> Noted on the self-powered hub, thanks for the suggestion, I will try.<=
br>
> 

> Just wanted to share the observation from the testing I've conduct=
ed with

> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent =
is

> also experienced and it did, there was overcurrent and each ports'=
 power

> shut-off during the situation but it was able to recover back. I initi=
ated

> the command 'usbconfig reset' and each port gloriously came ba=
ck alive one

> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into<=
br>
> functional and operational states. My measuring device is showing the =
same

> amount of current 460mA while the voltage stayed at 5.05 from a baseli=
ne of

> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike =
my RPi 3B, voltage

> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
> observed is when the voltage dropped below 5, the system will not give=
 a

> chance to make the ports come back alive as a sort of protection mecha=
nism.

> Sharing to you the logs below (with hw.usb.uhub.debug=3D1).



FreeBSD does not actively check and use "bMaxPower" .

Hi Hans,
It's okay, just tried your recommenda=
tion on a self-powered USB hub, my Prolific device is now working. Thanks a=
 lot!

=
Archimedes


--000000000000349e6605dc717f72--

From nobody Tue Apr 12 13:48:14 2022
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 142191A8C48E
	for ; Tue, 12 Apr 2022 13:48:16 +0000 (UTC)
	(envelope-from matteo@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 4Kd6W404q0z3GFf
	for ; Tue, 12 Apr 2022 13:48:16 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1649771296;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=8d7GyHlgjDEIr15atcQE3tBorPNAGc0nqU7k1kmL2Us=;
	b=Uwyud+RB//xbeEGiIqrkuzpSM7cMPDS4BkUplfZnfhKClfymFCf/IXiNpSMX46hbAGa3Gt
	RtModxuh+D7ifDsn3jULw//pXhgyFGXjZ7rLQrdtqCk3oCc+YIjQaUYkrkb8aAJZgIcGC1
	sIO/UkZYmkSZ/uhF+04/jsFcpSZD5zx8R9WUjoNGPuE/1ceMM/xciKchNRXLLbPqq7coun
	NUga52rui3ioZzA6uAVUfM/gwxFOdsiFOH/O60ukck6CtF0hGrhMVxR37KiKn1wpPBAyNS
	+S5ZL3jQFo/KeBkhpNzUvQP5X7aMTMmiLYjm7hFEFOlyGNp7iJFpIMQFsdPbpg==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::102f])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id B337FF200
	for ; Tue, 12 Apr 2022 13:48:15 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Tue, 12 Apr 2022 09:48:14 -0400
From: Matteo Riondato 
To: freebsd-arm@freebsd.org
Subject: [armv7] 13.1-BETA2 boots on beaglebone, 14-CURRENT snapshot panics
Message-ID: <20220412134814.4m5cdgoqliol52gb@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="r3dgeagbpvhtwikw"
Content-Disposition: inline
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649771296;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=8d7GyHlgjDEIr15atcQE3tBorPNAGc0nqU7k1kmL2Us=;
	b=yogriBo7g4xHvcm5RhJ7OF9WYsOVIEJQwa2QJR82uDbPRtziVYz1Z6/aqPArK+7ZHam4/n
	FCgRbLiPWE1Cq+Qq8yFjy5Vn4vMRuvtj+5XgDd6S3c53GC1Q9/8n68NM1NU4APWu8Uxz7q
	OpreaicGjFglmMfQ0ZFOOvajc8wD5+jbXS51l8auarhHCjNiZT6kpYwz/P09i0aFXBmQCw
	T5g5FiDcKqJsRHFGYhQOeKfNFaOfAtQKkQto48Dwv7xfwGZV1vtHLyPXkSKc+ABddNcaEz
	NByWEhemA/SqI0mseoIkPAePWfxeanUG9eTVAn+8Sx0vyxSMeiRqe/67BXfhuw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649771296; a=rsa-sha256; cv=none;
	b=SYjn2wJYw7fRIlS3Ah99HfYnlkGtIyMSQWJE0H1+r49i6qYXRb4Oxe7hr+ni4DV+6wMnsM
	MEDT+kAXexJSKdkMd7z8hYbbQcm7PEh7wnYNxOdECrdX81iwKDzQ3kO0W6pvW/Sphya6gY
	wqSHs9bvPIJBJQOIFcacFBHdpQMjHbZvkRW00E0G2Kv+qU70D6sBqcesjG1JlkMark4sAH
	wrv4roGay2cLCBjlSQY6lLdUrNxuDUqA+bOpxVLek9rZllfuAHy5pIuDbNapJFmgTXMFMY
	Oe43Hi4ouVLKWRO3NW/uQFeuEy+kpLQkByxerhnsiG4NUYZF+Ad25kZ20Gaghw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10030
Lines: 243


--r3dgeagbpvhtwikw
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi All,

While trying to make my beaglebone enhanced boot with the=20
am335x-sancloud-bbe.dtb (no success so far), I tried booting it with
the am335x-boneblack.dtb, loaded at the loader prompt.

The publicly available 13.1-BETA2 GENERICSD image boots into multi-user=20
(boot -v log available at=20
http://rionda.to/files/boot-13.1-BETA2-boneblack.log), while the=20
14-CURRENT 20220407 snapshot panics as follows:

ARM Debug Architecture not supported
GDB: debug ports: uart
GDB: current port: uart
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
Copyright (c) 1992-2022 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-CURRENT #0 main-n254435-8af24219565: Thu Apr  7 09:31:14=20
UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git=20
llvmorg-13.0.0-0-gd7b669b3a303)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e22000.
Preloaded elf module "/boot/kernel/umodem.ko" at 0xc0e2ae6c.
Preloaded elf module "/boot/kernel/ucom.ko" at 0xc0e2b3d8.
Preloaded dtb "/boot/dtb/am335x-boneblack.dtb" at 0xc0e2b944.
Preloaded TSLOG data "TSLOG" at 0xc0e2b998.
CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000)
CPU Features:=20
   Thumb2, Security, VMSAv7
Optional instructions:=20
   UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:3 LoUIS:1=20
Cache level 1:
  32KB/64B 4-way data cache WT WB Read-Alloc
  32KB/64B 4-way instruction cache Read-Alloc
Cache level 2:
  256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc
real memory  =3D 1072926720 (1023 MB)
avail memory =3D 1031000064 (983 MB)
Physical memory chunk(s):
   0x80000000 - 0x87ee8fff,   126 MB (  32489 pages)
   0x87f17000 - 0xbcf26fff,   848 MB ( 217104 pages)
   0xbcf2e000 - 0xbcf2efff,     0 MB (      1 pages)
   0xbcf30000 - 0xbcf31fff,     0 MB (      2 pages)
   0xbcf36000 - 0xbcf36fff,     0 MB (      1 pages)
   0xbcf3c000 - 0xbcf3dfff,     0 MB (      2 pages)
   0xbcf40000 - 0xbcf40fff,     0 MB (      1 pages)
   0xbcf42000 - 0xbcf43fff,     0 MB (      2 pages)
   0xbcf45000 - 0xbff7bfff,    48 MB (  12343 pages)
Excluded memory regions:
   0xb6e00000 - 0xb7d4efff,    15 MB (   3919 pages) NoAlloc=20
Static device mappings:
   0x44c00000 - 0x44ffffff mapped at VA 0xffb00000
   0x47400000 - 0x474fffff mapped at VA 0xffa00000
   0x47800000 - 0x478fffff mapped at VA 0xff900000
   0x48000000 - 0x48ffffff mapped at VA 0xfe900000
   0x49000000 - 0x490fffff mapped at VA 0xfe800000
   0x49800000 - 0x49afffff mapped at VA 0xfe500000
   0x4a000000 - 0x4affffff mapped at VA 0xfd500000
No PSCI/SMCCC call function found
Texas Instruments AM335x Processor, Revision ES2.1
random: no preloaded entropy cache
random: no platform bootloader entropy
arc4random: WARNING: initial seeding bypassed the cryptographic random=20
device because it was not yet seeded and the knob=20
'bypass_before_seeding' was enabled.
VIMAGE (virtualized network stack) enabled
hostuuid: using 00000000-0000-0000-0000-000000000000
ULE: setup cpu 0
snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10=
24]
feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D2=20
feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25
random: entropy device external interface
firmware: 'sdma-imx6q' version 0: 2196 bytes loaded at 0xc092a318
crypto: 
null: 
openfirm: 
kbd0 at kbdmux0
mem: 
ofwbus0: 
ti_sysc0:  on ofwbus0
panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
	 pc =3D 0xc05cdb84  lr =3D 0xc007ac8c (db_trace_self_wrapper+0x30)
	 sp =3D 0xc0f14a98  fp =3D 0xc0f14bb0
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
	 pc =3D 0xc007ac8c  lr =3D 0xc02e5c48 (vpanic+0x170)
	 sp =3D 0xc0f14bb8  fp =3D 0xc0f14bd8
	 r4 =3D 0x00000100  r5 =3D 0x00000000
	 r6 =3D 0xc07314a8  r7 =3D 0xc0916f10
vpanic() at vpanic+0x170
	 pc =3D 0xc02e5c48  lr =3D 0xc02e59f8 (dump_savectx)
	 sp =3D 0xc0f14be0  fp =3D 0xc0f14be4
	 r4 =3D 0x00000000  r5 =3D 0xc2b24000
	 r6 =3D 0x00000000  r7 =3D 0xc0f14c50
	 r8 =3D 0xc0b65ec0  r9 =3D 0x00000002
	r10 =3D 0xc0f14c2c
dump_savectx() at dump_savectx
	 pc =3D 0xc02e59f8  lr =3D 0xc0354fe4 (vmem_xalloc)
	 sp =3D 0xc0f14bec  fp =3D 0xc0f14c20
vmem_xalloc() at vmem_xalloc
	 pc =3D 0xc0354fe4  lr =3D 0xc0593f18 (kmem_malloc_domainset+0x9c)
	 sp =3D 0xc0f14c28  fp =3D 0xc0f14c70
	 r4 =3D 0xc0048f30  r5 =3D 0xc0e0b0ec
	 r6 =3D 0xc0f14c1c  r7 =3D 0x00000000
	 r8 =3D 0xc2b24000  r9 =3D 0x00000000
	r10 =3D 0xc0f14c50
kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
	 pc =3D 0xc0593f18  lr =3D 0xc02bf748 (malloc_large+0x2c)
	 sp =3D 0xc0f14c78  fp =3D 0xc0f14c88
	 r4 =3D 0xc08e7714  r5 =3D 0xd53dca80
	 r6 =3D 0x00000000  r7 =3D 0x00000002
	 r8 =3D 0x00000d74  r9 =3D 0xc079ae29
	r10 =3D 0x00000d74
malloc_large() at malloc_large+0x2c
	 pc =3D 0xc02bf748  lr =3D 0xc06a3940 (ti_sysc_attach+0x19c)
	 sp =3D 0xc0f14c90  fp =3D 0xc0f14cd0
	 r4 =3D 0xc387b400  r5 =3D 0xd53dca80
	 r6 =3D 0xffffffff  r7 =3D 0xc387b428
ti_sysc_attach() at ti_sysc_attach+0x19c
	 pc =3D 0xc06a3940  lr =3D 0xc032439c (device_attach+0x4f0)
	 sp =3D 0xc0f14cd8  fp =3D 0xc0f14d20
	 r4 =3D 0xd53dc800  r5 =3D 0xd53dca80
	 r6 =3D 0x3a780a0c  r7 =3D 0x00000000
	 r8 =3D 0xc0b6a924  r9 =3D 0xc077cf27
	r10 =3D 0xd6f1a500
device_attach() at device_attach+0x4f0
	 pc =3D 0xc032439c  lr =3D 0xc0323e10 (device_probe_and_attach+0x8c)
	 sp =3D 0xc0f14d28  fp =3D 0xc0f14d40
	 r4 =3D 0xd53dc800  r5 =3D 0xc3868f40
	 r6 =3D 0x5e4a6f28  r7 =3D 0xffffffff
	 r8 =3D 0x00000000  r9 =3D 0x00000000
	r10 =3D 0xd6f1a6e0
device_probe_and_attach() at device_probe_and_attach+0x8c
	 pc =3D 0xc0323e10  lr =3D 0xc0325804 (bus_generic_attach+0x1c)
	 sp =3D 0xc0f14d48  fp =3D 0xc0f14d50
	 r4 =3D 0xd53dc800  r5 =3D 0x00000000
	 r6 =3D 0xc0f14d60 r10 =3D 0xd6f1a6e0
bus_generic_attach() at bus_generic_attach+0x1c
	 pc =3D 0xc0325804  lr =3D 0xc00e4248 (ofwbus_attach+0x138)
	 sp =3D 0xc0f14d58  fp =3D 0xc0f14d90
	 r4 =3D 0xd53dca80 r10 =3D 0xd6f1a6e0
ofwbus_attach() at ofwbus_attach+0x138
	 pc =3D 0xc00e4248  lr =3D 0xc032439c (device_attach+0x4f0)
	 sp =3D 0xc0f14d98  fp =3D 0xc0f14de0
	 r4 =3D 0xd53dca80  r5 =3D 0xd53dcb00
	 r6 =3D 0x39cf0259  r7 =3D 0x00000000
	 r8 =3D 0xc0b6a924  r9 =3D 0xc077cf27
device_attach() at device_attach+0x4f0
	 pc =3D 0xc032439c  lr =3D 0xc0323e10 (device_probe_and_attach+0x8c)
	 sp =3D 0xc0f14de8  fp =3D 0xc0f14e00
	 r4 =3D 0xd53dca80  r5 =3D 0xc3868f40
	 r6 =3D 0x5e4a6f28  r7 =3D 0x00000000
	 r8 =3D 0xc0b01654  r9 =3D 0xc0b01658
	r10 =3D 0x03800000
device_probe_and_attach() at device_probe_and_attach+0x8c
	 pc =3D 0xc0323e10  lr =3D 0xc0326278 (bus_generic_new_pass+0xb4)
	 sp =3D 0xc0f14e08  fp =3D 0xc0f14e20
	 r4 =3D 0xd53dca80  r5 =3D 0xc08dde38
	 r6 =3D 0xc08b986c r10 =3D 0x03800000
bus_generic_new_pass() at bus_generic_new_pass+0xb4
	 pc =3D 0xc0326278  lr =3D 0xc03262c4 (bus_generic_new_pass+0x100)
	 sp =3D 0xc0f14e28  fp =3D 0xc0f14e40
	 r4 =3D 0xd53dcb00  r5 =3D 0xc08dde38
	 r6 =3D 0xd53dd700  r7 =3D 0x00000000
	 r8 =3D 0xc0b01654 r10 =3D 0x03800000
bus_generic_new_pass() at bus_generic_new_pass+0x100
	 pc =3D 0xc03262c4  lr =3D 0xc03213cc (bus_set_pass+0x54)
	 sp =3D 0xc0f14e48  fp =3D 0xc0f14e60
	 r4 =3D 0xc389d4a0  r5 =3D 0xc08dde38
	 r6 =3D 0xd53dd700  r7 =3D 0xc0b01654
	 r8 =3D 0x7fffffff r10 =3D 0x03800000
bus_set_pass() at bus_set_pass+0x54
	 pc =3D 0xc03213cc  lr =3D 0xc02708c0 (mi_startup+0x2cc)
	 sp =3D 0xc0f14e68  fp =3D 0xc0f14e90
	 r4 =3D 0x0fffffff  r5 =3D 0xc08b3764
	 r6 =3D 0xc0ae31b8  r7 =3D 0x00000000
	 r8 =3D 0xc0ae31b4  r9 =3D 0xc38a3324
mi_startup() at mi_startup+0x2cc
	 pc =3D 0xc02708c0  lr =3D 0xc0000344 (btext+0x144)
	 sp =3D 0xc0f14e98  fp =3D 0x00000000
	 r4 =3D 0xc0000478  r5 =3D 0xc0ba0000
	 r6 =3D 0xbb102340  r7 =3D 0x00c52078
	 r8 =3D 0xc0e22000  r9 =3D 0xbcf085d8
	r10 =3D 0x00000000
btext() at btext+0x144
	 pc =3D 0xc0000344  lr =3D 0xc0000344 (btext+0x144)
	 sp =3D 0xc0f14e98  fp =3D 0x00000000
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x58: ldrb    r15, [r15, r15, ror r15]!
  db>

I'm not a kernel hacker, but I'll be happy to give more information as=20
needed, when told what to type at the db> prompt =3D)

I can also build my own image trying to bisect the problem, but wonder=20
if anyone has any hint of what commit(s) could be causing this issue.

(I also wonder whether I should be posting on freebsd-current@, rather=20
than freebsd-arm@ . Suggestions accepted)

Thanks,
Matteo

--r3dgeagbpvhtwikw
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmJVgxkTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAfidD/9ykf2x4//BtOChsxmnXcqUTUfAelqz
s61Y9HBoiOMr3bwSa5C2eByvAXChsEmaDwUq73iLYsmaxh46gXXxuupVl7NGRWEP
ZNb7cOn+8Xi33DbNWKW2EG8tfkhFEQbOnzr6SKggjP++Ne5i9uVzUZm2J8hzHfeB
Is9ITMztoT4CuLMvV2bSx33ZA+QoBnqjO+caJlKmu5cB/8I09hhA+AAUxxhCEHhW
YFe3oQVWmw/Dic8do5/4q03H0tcOxW5xLuvRgDiveIYGzdvKjkf7mv2WV3whHMt+
qgxEj8eVm7RGIpF9C1zdm94pGuaCS5WHlWdGPc3cZzxb7ej0AjoudTRTEvjlyHqr
au6AixLcZe5GEa/wXbsPUKi0GccTVDwFYHfN8q53STo/5PsBPSR6+Inv/Qz5ABWz
eAu/CCxrNiZ9jjRqP/V65yBN7rnRJBGgQ3b+EBslDpohD/GsPz9r0UyY016/bbV8
cuvKX95iX1wATCdkrN9/KrxwpFgMTOzSzs0R24HAQ4aZI3HDQMQjeBgJEFSLUY1d
V25P8/WZAwECbA1b0M3Je/NMiekJ93ygZ7j3k9CIWnPx3P8yOWgv/XRl/XmtegJ1
vlyv/Z2ZLnJ7HzNIpeFyp0PuLnvggMmTo7aJXLkjzmsf5sj8D5MFWp88yx2Dlm6S
uxCFtuvv8kaiBA==
=hWlq
-----END PGP SIGNATURE-----

--r3dgeagbpvhtwikw--

From nobody Tue Apr 12 22:09:59 2022
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 AFD981AF9285
	for ; Tue, 12 Apr 2022 21:52:18 +0000 (UTC)
	(envelope-from info@ohdata.se)
Received: from mail01.ohdata.se (46-22-124-5.ip.axbyte.se [46.22.124.5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KdKFY4964z4fpM
	for ; Tue, 12 Apr 2022 21:52:17 +0000 (UTC)
	(envelope-from info@ohdata.se)
Received: from localhost (localhost [127.0.0.1])
	by mail01.ohdata.se (Postfix) with ESMTP id 612999089
	for ; Tue, 12 Apr 2022 23:45:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mail01.ohdata.se
Received: from mail01.ohdata.se ([127.0.0.1])
	by localhost (mail01.ohdata.se [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id FHbFuDyy3xve for ;
	Tue, 12 Apr 2022 23:45:10 +0200 (CEST)
Received: from webmail.ohdata.se (unknown [10.0.38.61])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail01.ohdata.se (Postfix) with ESMTPSA id 53C3F9086
	for ; Tue, 12 Apr 2022 23:45:10 +0200 (CEST)
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;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 13 Apr 2022 00:09:59 +0200
From: Oskar Holmlund 
To: freebsd-arm@freebsd.org
Subject: Re: [armv7] 13.1-BETA2 boots on beaglebone, 14-CURRENT snapshot
 panics
Organization: OH Data
In-Reply-To: <20220412134814.4m5cdgoqliol52gb@ubertino.local>
References: <20220412134814.4m5cdgoqliol52gb@ubertino.local>
Message-ID: <32c957088640343eae49e7e76d89ac0c@ohdata.se>
X-Sender: info@ohdata.se
User-Agent: Roundcube Webmail/1.3.6
X-Rspamd-Queue-Id: 4KdKFY4964z4fpM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of info@ohdata.se designates 46.22.124.5 as permitted sender) smtp.mailfrom=info@ohdata.se
X-Spamd-Result: default: False [-3.30 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 HAS_ORG_HEADER(0.00)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 DMARC_NA(0.00)[ohdata.se];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:43853, ipnet:46.22.112.0/20, country:SE];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9253
Lines: 227

2022-04-12 15:48 skrev Matteo Riondato:
> Hi All,
> 
> While trying to make my beaglebone enhanced boot with the
> am335x-sancloud-bbe.dtb (no success so far), I tried booting it with
> the am335x-boneblack.dtb, loaded at the loader prompt.
> 
> The publicly available 13.1-BETA2 GENERICSD image boots into
> multi-user (boot -v log available at
> http://rionda.to/files/boot-13.1-BETA2-boneblack.log), while the
> 14-CURRENT 20220407 snapshot panics as follows:
> 
> ARM Debug Architecture not supported
> GDB: debug ports: uart
> GDB: current port: uart
> KDB: debugger backends: ddb gdb
> KDB: current backend: ddb
> Copyright (c) 1992-2022 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-CURRENT #0 main-n254435-8af24219565: Thu Apr  7 09:31:14 
> UTC 2022
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git
> llvmorg-13.0.0-0-gd7b669b3a303)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT: init without driver.
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0e22000.
> Preloaded elf module "/boot/kernel/umodem.ko" at 0xc0e2ae6c.
> Preloaded elf module "/boot/kernel/ucom.ko" at 0xc0e2b3d8.
> Preloaded dtb "/boot/dtb/am335x-boneblack.dtb" at 0xc0e2b944.
> Preloaded TSLOG data "TSLOG" at 0xc0e2b998.
> CPU: ARM Cortex-A8 r3p2 (ECO: 0x00000000)
> CPU Features:   Thumb2, Security, VMSAv7
> Optional instructions:   UMULL, SMULL, SIMD(ext)
> LoUU:2 LoC:3 LoUIS:1 Cache level 1:
>  32KB/64B 4-way data cache WT WB Read-Alloc
>  32KB/64B 4-way instruction cache Read-Alloc
> Cache level 2:
>  256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc
> real memory  = 1072926720 (1023 MB)
> avail memory = 1031000064 (983 MB)
> Physical memory chunk(s):
>   0x80000000 - 0x87ee8fff,   126 MB (  32489 pages)
>   0x87f17000 - 0xbcf26fff,   848 MB ( 217104 pages)
>   0xbcf2e000 - 0xbcf2efff,     0 MB (      1 pages)
>   0xbcf30000 - 0xbcf31fff,     0 MB (      2 pages)
>   0xbcf36000 - 0xbcf36fff,     0 MB (      1 pages)
>   0xbcf3c000 - 0xbcf3dfff,     0 MB (      2 pages)
>   0xbcf40000 - 0xbcf40fff,     0 MB (      1 pages)
>   0xbcf42000 - 0xbcf43fff,     0 MB (      2 pages)
>   0xbcf45000 - 0xbff7bfff,    48 MB (  12343 pages)
> Excluded memory regions:
>   0xb6e00000 - 0xb7d4efff,    15 MB (   3919 pages) NoAlloc Static
> device mappings:
>   0x44c00000 - 0x44ffffff mapped at VA 0xffb00000
>   0x47400000 - 0x474fffff mapped at VA 0xffa00000
>   0x47800000 - 0x478fffff mapped at VA 0xff900000
>   0x48000000 - 0x48ffffff mapped at VA 0xfe900000
>   0x49000000 - 0x490fffff mapped at VA 0xfe800000
>   0x49800000 - 0x49afffff mapped at VA 0xfe500000
>   0x4a000000 - 0x4affffff mapped at VA 0xfd500000
> No PSCI/SMCCC call function found
> Texas Instruments AM335x Processor, Revision ES2.1
> random: no preloaded entropy cache
> random: no platform bootloader entropy
> arc4random: WARNING: initial seeding bypassed the cryptographic random
> device because it was not yet seeded and the knob
> 'bypass_before_seeding' was enabled.
> VIMAGE (virtualized network stack) enabled
> hostuuid: using 00000000-0000-0000-0000-000000000000
> ULE: setup cpu 0
> snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff 
> [1024]
> feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=2
> feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25
> random: entropy device external interface
> firmware: 'sdma-imx6q' version 0: 2196 bytes loaded at 0xc092a318
> crypto: 
> null: 
> openfirm: 
> kbd0 at kbdmux0
> mem: 
> ofwbus0: 
> ti_sysc0:  on ofwbus0
> panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> 	 pc = 0xc05cdb84  lr = 0xc007ac8c (db_trace_self_wrapper+0x30)
> 	 sp = 0xc0f14a98  fp = 0xc0f14bb0
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> 	 pc = 0xc007ac8c  lr = 0xc02e5c48 (vpanic+0x170)
> 	 sp = 0xc0f14bb8  fp = 0xc0f14bd8
> 	 r4 = 0x00000100  r5 = 0x00000000
> 	 r6 = 0xc07314a8  r7 = 0xc0916f10
> vpanic() at vpanic+0x170
> 	 pc = 0xc02e5c48  lr = 0xc02e59f8 (dump_savectx)
> 	 sp = 0xc0f14be0  fp = 0xc0f14be4
> 	 r4 = 0x00000000  r5 = 0xc2b24000
> 	 r6 = 0x00000000  r7 = 0xc0f14c50
> 	 r8 = 0xc0b65ec0  r9 = 0x00000002
> 	r10 = 0xc0f14c2c
> dump_savectx() at dump_savectx
> 	 pc = 0xc02e59f8  lr = 0xc0354fe4 (vmem_xalloc)
> 	 sp = 0xc0f14bec  fp = 0xc0f14c20
> vmem_xalloc() at vmem_xalloc
> 	 pc = 0xc0354fe4  lr = 0xc0593f18 (kmem_malloc_domainset+0x9c)
> 	 sp = 0xc0f14c28  fp = 0xc0f14c70
> 	 r4 = 0xc0048f30  r5 = 0xc0e0b0ec
> 	 r6 = 0xc0f14c1c  r7 = 0x00000000
> 	 r8 = 0xc2b24000  r9 = 0x00000000
> 	r10 = 0xc0f14c50
> kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
> 	 pc = 0xc0593f18  lr = 0xc02bf748 (malloc_large+0x2c)
> 	 sp = 0xc0f14c78  fp = 0xc0f14c88
> 	 r4 = 0xc08e7714  r5 = 0xd53dca80
> 	 r6 = 0x00000000  r7 = 0x00000002
> 	 r8 = 0x00000d74  r9 = 0xc079ae29
> 	r10 = 0x00000d74
> malloc_large() at malloc_large+0x2c
> 	 pc = 0xc02bf748  lr = 0xc06a3940 (ti_sysc_attach+0x19c)
> 	 sp = 0xc0f14c90  fp = 0xc0f14cd0
> 	 r4 = 0xc387b400  r5 = 0xd53dca80
> 	 r6 = 0xffffffff  r7 = 0xc387b428
> ti_sysc_attach() at ti_sysc_attach+0x19c
> 	 pc = 0xc06a3940  lr = 0xc032439c (device_attach+0x4f0)
> 	 sp = 0xc0f14cd8  fp = 0xc0f14d20
> 	 r4 = 0xd53dc800  r5 = 0xd53dca80
> 	 r6 = 0x3a780a0c  r7 = 0x00000000
> 	 r8 = 0xc0b6a924  r9 = 0xc077cf27
> 	r10 = 0xd6f1a500
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032439c  lr = 0xc0323e10 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14d28  fp = 0xc0f14d40
> 	 r4 = 0xd53dc800  r5 = 0xc3868f40
> 	 r6 = 0x5e4a6f28  r7 = 0xffffffff
> 	 r8 = 0x00000000  r9 = 0x00000000
> 	r10 = 0xd6f1a6e0
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc0323e10  lr = 0xc0325804 (bus_generic_attach+0x1c)
> 	 sp = 0xc0f14d48  fp = 0xc0f14d50
> 	 r4 = 0xd53dc800  r5 = 0x00000000
> 	 r6 = 0xc0f14d60 r10 = 0xd6f1a6e0
> bus_generic_attach() at bus_generic_attach+0x1c
> 	 pc = 0xc0325804  lr = 0xc00e4248 (ofwbus_attach+0x138)
> 	 sp = 0xc0f14d58  fp = 0xc0f14d90
> 	 r4 = 0xd53dca80 r10 = 0xd6f1a6e0
> ofwbus_attach() at ofwbus_attach+0x138
> 	 pc = 0xc00e4248  lr = 0xc032439c (device_attach+0x4f0)
> 	 sp = 0xc0f14d98  fp = 0xc0f14de0
> 	 r4 = 0xd53dca80  r5 = 0xd53dcb00
> 	 r6 = 0x39cf0259  r7 = 0x00000000
> 	 r8 = 0xc0b6a924  r9 = 0xc077cf27
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032439c  lr = 0xc0323e10 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14de8  fp = 0xc0f14e00
> 	 r4 = 0xd53dca80  r5 = 0xc3868f40
> 	 r6 = 0x5e4a6f28  r7 = 0x00000000
> 	 r8 = 0xc0b01654  r9 = 0xc0b01658
> 	r10 = 0x03800000
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc0323e10  lr = 0xc0326278 (bus_generic_new_pass+0xb4)
> 	 sp = 0xc0f14e08  fp = 0xc0f14e20
> 	 r4 = 0xd53dca80  r5 = 0xc08dde38
> 	 r6 = 0xc08b986c r10 = 0x03800000
> bus_generic_new_pass() at bus_generic_new_pass+0xb4
> 	 pc = 0xc0326278  lr = 0xc03262c4 (bus_generic_new_pass+0x100)
> 	 sp = 0xc0f14e28  fp = 0xc0f14e40
> 	 r4 = 0xd53dcb00  r5 = 0xc08dde38
> 	 r6 = 0xd53dd700  r7 = 0x00000000
> 	 r8 = 0xc0b01654 r10 = 0x03800000
> bus_generic_new_pass() at bus_generic_new_pass+0x100
> 	 pc = 0xc03262c4  lr = 0xc03213cc (bus_set_pass+0x54)
> 	 sp = 0xc0f14e48  fp = 0xc0f14e60
> 	 r4 = 0xc389d4a0  r5 = 0xc08dde38
> 	 r6 = 0xd53dd700  r7 = 0xc0b01654
> 	 r8 = 0x7fffffff r10 = 0x03800000
> bus_set_pass() at bus_set_pass+0x54
> 	 pc = 0xc03213cc  lr = 0xc02708c0 (mi_startup+0x2cc)
> 	 sp = 0xc0f14e68  fp = 0xc0f14e90
> 	 r4 = 0x0fffffff  r5 = 0xc08b3764
> 	 r6 = 0xc0ae31b8  r7 = 0x00000000
> 	 r8 = 0xc0ae31b4  r9 = 0xc38a3324
> mi_startup() at mi_startup+0x2cc
> 	 pc = 0xc02708c0  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> 	 r4 = 0xc0000478  r5 = 0xc0ba0000
> 	 r6 = 0xbb102340  r7 = 0x00c52078
> 	 r8 = 0xc0e22000  r9 = 0xbcf085d8
> 	r10 = 0x00000000
> btext() at btext+0x144
> 	 pc = 0xc0000344  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x58: ldrb    r15, [r15, r15, ror r15]!
>  db>
> 
> I'm not a kernel hacker, but I'll be happy to give more information as
> needed, when told what to type at the db> prompt =)
> 
> I can also build my own image trying to bisect the problem, but wonder
> if anyone has any hint of what commit(s) could be causing this issue.
> 
> (I also wonder whether I should be posting on freebsd-current@, rather
> than freebsd-arm@ . Suggestions accepted)
> 
> Thanks,
> Matteo

Hi Matteo,

Read this thread
https://lists.freebsd.org/archives/freebsd-arm/2021-August/000410.html

I'm not sure the reviews mentioned in the last post are the one to use 
today. I hope I find some time to do a testbuild tomorrow and get back 
to you.

-- 
Bästa Hälsningar
Oskar Holmlund
Tel 070-3220292

From nobody Wed Apr 13 06:58:46 2022
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 CBC2E1B03880
	for ; Wed, 13 Apr 2022 06:59:05 +0000 (UTC)
	(envelope-from kamalpr@gmail.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4KdYNS6gS0z4VBb
	for ; Wed, 13 Apr 2022 06:59:04 +0000 (UTC)
	(envelope-from kamalpr@gmail.com)
Received: by mail-ed1-x52f.google.com with SMTP id 21so1252734edv.1
        for ; Tue, 12 Apr 2022 23:59:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:reply-to:from:date:message-id:subject:to;
        bh=lPHJDfqMUPitlD+H9qtnfb48/kMZ8EDZhfgYdtoea3A=;
        b=NXh+MJp6UkK8QNcVxRHSaOdEA96bRSuYsTGA0yQ3fWTyfVrABsrn2yb88nlGF2LSw5
         M8gQPah7mNlDkGcRHqMbuI/rhaBM075+dymkNZD2WAsU7pJpfxwo01S0Y3g8Z9xarlhB
         CG8J7Zi1Y0SZF2VyPrFmbEC10JDI8SB2/56a3ZnB5yccAe5k+8+5yVgu4sQj4sXDsKc8
         IeICHKfdhKRw7Wc9E6eyTmIwrrZyDW5Z/qu+2SZQz+TxvCzx8vQUfvmG4wzm/TO9ddq0
         pAjRDaAiFJ1R3/r+mJwKtRa7Ratbw5GGu7e93B9zFNz0NxEHh+2daiT0TBI7Zl+wlhjV
         ZgzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:reply-to:from:date:message-id
         :subject:to;
        bh=lPHJDfqMUPitlD+H9qtnfb48/kMZ8EDZhfgYdtoea3A=;
        b=xGudCDuYr1QY6yuAEor2uag37IxS1J8rabcWInibuJAFDXE0edpFqmbA87o2roHIaC
         rdqVw1fDfZCxsSEvsQ3h3BVkSu2j3lll6jbwOVsJwrYADE+WocWoC+l53keOoHpd47MN
         fwrKqYyZ6P3IieO1FZIUPXeRWu8K97TUZC5UTMp9D9/Fn4QCeyql3JjtJ0JLAXhSPwJq
         6VyQND0ch1c9uiJLtKbOl5YUu+uLgiVVK1tsez+ymIdDMZ+T7O5GWBESdznLcRxl7ziN
         IxbLNFqtz7+vUq13S6VS8WlZ2I7+LVTvU1u9aBxqvNz2ophWxxyE/1NfOLTWJCnlAWp4
         KJqA==
X-Gm-Message-State: AOAM531hzJAg9z+5kK5J0fc6lNxR7K1CROldFHUKcUpjAwSOtiXUL0H9
	igYSU/Epw4FwELA6Fbg+1vKdHlzrXV1qmU2KjDeXQRf53A==
X-Google-Smtp-Source: ABdhPJyv0uH7MWOs7xpTlZyVq4cmvJLQ1lU1jQP8m79Dyf0ukqY1zmthJRLh0pNvHBx/BKhPNApCcWfobgSuYzlxYS4=
X-Received: by 2002:a50:99cd:0:b0:418:d6c2:2405 with SMTP id
 n13-20020a5099cd000000b00418d6c22405mr42356282edb.342.1649833138338; Tue, 12
 Apr 2022 23:58:58 -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
Reply-To: kamalpr@gmail.com
From: "Kamal R. Prasad" 
Date: Wed, 13 Apr 2022 12:28:46 +0530
Message-ID: 
Subject: .clear_stall
To: freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4KdYNS6gS0z4VBb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=NXh+MJp6;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of kamalpr@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=kamalpr@gmail.com
X-Spamd-Result: default: False [-1.45 / 15.00];
	 HAS_REPLYTO(0.00)[kamalpr@gmail.com];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 REPLYTO_ADDR_EQ_FROM(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-0.01)[-0.008];
	 MIME_GOOD(-0.10)[text/plain];
	 FREEMAIL_REPLYTO(0.00)[gmail.com];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.55)[0.553];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 291
Lines: 12

hello,

 my xhci driver keeps getting calls from the kernel to the
.clear_stall interface defined in
http://fxr.watson.org/fxr/source/dev/usb/controller/xhci.c?im=10#L4365

 4365         .clear_stall = xhci_ep_clear_stall,

Can someone tell me why this interface gets called?

thanks
-kamal

From nobody Wed Apr 13 09:17:40 2022
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 6BA041AFFA0D
	for ; Wed, 13 Apr 2022 09:17:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KdcSZ4jSgz4pts
	for ; Wed, 13 Apr 2022 09:17:50 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B11252604AB;
	Wed, 13 Apr 2022 11:17:41 +0200 (CEST)
Message-ID: <50f16744-2eeb-6dff-c31a-7a0a6dd0bf7a@selasky.org>
Date: Wed, 13 Apr 2022 11:17:40 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: .clear_stall
Content-Language: en-US
To: kamalpr@gmail.com, freebsd-arm 
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KdcSZ4jSgz4pts
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.27 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.980];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 605
Lines: 24

On 4/13/22 08:58, Kamal R. Prasad wrote:
> hello,
> 
>   my xhci driver keeps getting calls from the kernel to the
> .clear_stall interface defined in
> http://fxr.watson.org/fxr/source/dev/usb/controller/xhci.c?im=10#L4365
> 
>   4365         .clear_stall = xhci_ep_clear_stall,
> 
> Can someone tell me why this interface gets called?
> 

Hi Kamal,

This interface gets called typically to reset USB endpoints:

a) before the first endpoint transfer.
b) after an endpoint failure.

This ensures the data toggle value gets synced and no data is lost.

Can you explain what problem you are seeing?

--HPS

From nobody Wed Apr 13 12:58:23 2022
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 B0F0B1B0D198
	for ; Wed, 13 Apr 2022 12:58:24 +0000 (UTC)
	(envelope-from matteo@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 4KdjM44hrwz3sGF;
	Wed, 13 Apr 2022 12:58:24 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1649854704;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=X8EDiVdBr5Dd4v2bOavlMM24if+r6u/3at+8nZ8KqNQ=;
	b=vBqqhvfjve4CsOMSZV58z9EKKo8d1c87tV1tV8u/a4Hhx439bUOYKcYWLf7jTPdD4hUQyj
	mU3juKcsY8RuXFjFUMSF5l3te2mauUsl1M2uWN6Milwf19+0c2JkQ/OhEVri5d87BzBbwa
	LLMP+bvscibfG6H0K69zaOnnoxW0xa/E9+WxdZNeel8nymPBdFA+IPSB2VKtvV+GQJtPei
	e0UA9aqwh9vpfWStgBwFx8jVNuny2pfBBkOrudtQfr2VM/gsbWZrrm3mokOEP9n92KRTaH
	iqIGLJP4xzDPC+FhKqvWyrXi/kEjnPSAOUF8m3Dzmiy6V/Xjk5ecdWYNfRMLhQ==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::102f])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 6281B2B540;
	Wed, 13 Apr 2022 12:58:24 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Wed, 13 Apr 2022 08:58:23 -0400
From: Matteo Riondato 
To: Oskar Holmlund 
Cc: freebsd-arm@freebsd.org
Subject: Re: [armv7] 13.1-BETA2 boots on beaglebone, 14-CURRENT snapshot
 panics
Message-ID: <20220413125823.u4cpmnxutamtmql5@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
References: <20220412134814.4m5cdgoqliol52gb@ubertino.local>
 <32c957088640343eae49e7e76d89ac0c@ohdata.se>
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ujjd7d4r27yxwhej"
Content-Disposition: inline
In-Reply-To: <32c957088640343eae49e7e76d89ac0c@ohdata.se>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1649854704;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=X8EDiVdBr5Dd4v2bOavlMM24if+r6u/3at+8nZ8KqNQ=;
	b=u5sbKlAE2qO3w0fS6TNEW3Ckhl5YSc8epKz2FH+KYXhzpkIqGHPzG32OLlXzno0QgnSlHP
	XdUMsMJXnNuJIbrVEtNqsNSyam0HFfrFoZl115xUNlns1N+VWIRIE2P0wDrEaXrBcqaqK+
	iue0rAzfTDOAGo2Zius7Iswh/poVB2SJ7mnY3v0TINbwRGn8Tq+S23h3pS8NfF61Zj9mHC
	7CdWtvG30Wpafob1dtI3l4j2IZ0rZbMLErmyw2/WJjpEUUw+1Kd3mUNQeKeOW55QF3I5FZ
	syFLAMOlTgSgJn9GNdjF6iW+HcRxANtfbvnf6y1raPcC8I2vAc0+EOYIM8cRzg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649854704; a=rsa-sha256; cv=none;
	b=sBLSLR0dwSKWiwwhu6bVtafJI3cI2d7+HAda6ErKa+flNa3tsOvDk0/Ha2O5at3zDB2FFJ
	xnzA5HG31IGJQmbcLTidzDwvRNbIKevIfAKTloIimuwuvSd/58Oa1MeRt24u61nzEs3Qnl
	oXzdxrOPopb1i4o6FInkfl880/MMbKa6vBqLi20JqWhF9i488VEWCkgkhk/WFOv17boF44
	8/yFAA03UU9cpdUj7IYNH+dn/a11Z3JdlILzLrIaRUHtg9244Ne/FiWV226onXd6xKxdEL
	mUVdaoJL+YRllX+tHuDqmbWFYXdvy00zwxHMYoIjxbQREi+fN+EpbxCKzUa7Sw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2264
Lines: 57


--ujjd7d4r27yxwhej
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-04-12 at 18:09 EDT, Oskar Holmlund  wrote:
>2022-04-12 15:48 skrev Matteo Riondato:
>>While trying to make my beaglebone enhanced boot with the=20
>>am335x-sancloud-bbe.dtb (no success so far), I tried booting it with=20
>>the am335x-boneblack.dtb, loaded at the loader prompt.
>>
>>The publicly available 13.1-BETA2 GENERICSD image boots into=20
>>multi-user (boot -v log available at=20
>>http://rionda.to/files/boot-13.1-BETA2-boneblack.log), while the=20
>>14-CURRENT 20220407 snapshot panics as follows:
>> [SNIP]
>>I can also build my own image trying to bisect the problem, but wonder=20
>>if anyone has any hint of what commit(s) could be causing this issue.
>>
>>(I also wonder whether I should be posting on freebsd-current@, rather=20
>>than freebsd-arm@ . Suggestions accepted)

>Read this thread=20
>https://lists.freebsd.org/archives/freebsd-arm/2021-August/000410.html
>
>I'm not sure the reviews mentioned in the last post are the one to use=20
>today. I hope I find some time to do a testbuild tomorrow and get back=20
>to you.

Thank you, Oskar, I'll give it a shot in the next few days.

Thanks,
Matteo

--ujjd7d4r27yxwhej
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmJWyOcTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAeX0D/96RSewC0xR4jZiMmmnCXQTWN+hWOps
pL5OgAK6mxtaYnUIDBslPhdBcRYLsRykRserM1ripTEa3i5qym73YPpjTKGu02OZ
wOomO6s+6VbaIcns/9DEPo9lMBWZEhOD8L4PwAgJyQhYbH1f0X+SqJLSmAe348wY
HvamTGctAXfUolz2m2/NDf+iC2o94AHGoUqhQEBhptb1InehcHfd8cZyVOw8YfyI
goPtItpJKlrEEy7oxvH82yzYQN65toexteqchBMm5BJh5KX3hi3V36K7J/ZKox42
ByVgie3pl0onSvkJe7Xi7BetuNiWwA/G6Llf/UKhzIDZBmCdr98viAKsm7ogjBE1
jSyERxci9VH2B3jN62beRyt3MUC77Ee2iMHGAV9eXvkfcjevvDzlVAtVzegNRVaj
t1xHm/IysX4eSDSOK2NuJrETfoulvlfKB1WUKISt83VOAO0ZPsk+zbsy/Lr24caS
ojVENC1bVfoF+KWLr/bmXWjtZ2NcCY+cRsgzSusYWQXxhQjCEkaPH7qyz9waJCgw
LqEq3F1nOT4+a+0ItmNUMCXed0lbkOq8EmtUR7y836U7yynJJFZ4qgwyuSUxpLIq
7ZzKyS5xT4fL/qTi4EO9V9SXeaA2kjgr9nuYaIbf05MA4hkPfQxi3Ejw/GmJ6emx
O5+tVlQ70xOM4A==
=T2YP
-----END PGP SIGNATURE-----

--ujjd7d4r27yxwhej--

From nobody Sat Apr 16 17:37:57 2022
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 ECF2D5D45BD
	for ; Sat, 16 Apr 2022 17:37:57 +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 4KggQF4PJ2z4j6S
	for ; Sat, 16 Apr 2022 17:37:57 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 76F2B627D
	for ; Sat, 16 Apr 2022 17:37:57 +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 23GHbvd4022254
	for ; Sat, 16 Apr 2022 17:37:57 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23GHbvWr022253
	for freebsd-arm@FreeBSD.org; Sat, 16 Apr 2022 17:37:57 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 263348] Kernel cannot detect second ethernet interface
Date: Sat, 16 Apr 2022 17:37:57 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: freebsd@sysctl.cz
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650130677;
	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=CSahrZCwvp4PwrZwMNdUaG4MJbrj4jUXxvotIy2XBAg=;
	b=a2JFC308U+kOfWlOeR9otV9eLxQdcQOtdU5bys3kOsEjKvAw6WDXK4hDBADxGud9B76gi6
	/x9nEX70GsFzHsIDK6HklliXkT4SZyc6syfDmZrwT3r4fOi8pYCr6HMf2dq07aSyzq6KbV
	JeMyc/pPYgmVtEdUQ/66Wjp5JUP8yGBgEGQPPWbV6Y6bmvfzLoSUjB2yYJLaerje0U4Npq
	n4D69vZsyAoRUiYUK4uvXvQJixFgtg9AKPYpHXSb2G4keGHnHk2Qy4RYdLFUEEnFgbRxvw
	IFZ7x6Y1ZcugzlLAV50BZ5wN7Ixs6JZ8waBPYve1pwyojee1sGn0nD7zoAz9Jg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650130677; a=rsa-sha256; cv=none;
	b=BXJuvgFeVLSL0NTbCJrjFlHf3jqowrU33+tVOmoj66eXeGL0sC4GCc8OJR0X1c/Ee+yhy0
	v9dxXGQJxMlz/4fdikjOyCE/3FlhEncErVu+Nb+ZA81ZVtXpZ9MHAC3nfr19D1hKkCf/EO
	S+QXwkBHYO/P6HsGoYU0Knvc5RUhPScFWAIcx9afRW/QcW9K5pYnko0Wndl0hOqmwzwyjw
	vkmpCGStRUuVDIyctsBdYlAR/wjrqmmRH9TBv2PUuyIr9wFJK8c8hASyH6oVYafsmU+eq1
	bdNTLJrlKZscB+mZFeBKvF+NI+qar+RU9noMHxAf22xiBnvvEJSS6ZjnMJe6fQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1520
Lines: 41

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263348

            Bug ID: 263348
           Summary: Kernel cannot detect second ethernet interface
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: freebsd@sysctl.cz

Hi,
I use board orangepi r1 plus lts with two ethernet interface
First is dwc0. Here cannot get address
Second kernel cannot detect interface.
Maybe kernel havent driver for ethernet
So i tried also USB to RJ45 and without interface but for
amd64 this adapter is detected.=20=20

dwc0: flags=3D8843 metric 0 mtu 1500
        options=3D8000b
        ether 22:9f:8a:bf:dc:f6
        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
        media: Ethernet autoselect (none)
        status: no carrier
        nd6 options=3D29
lo0: flags=3D8049 metric 0 mtu 16384
        options=3D680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Apr 16 21:14:09 2022
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 AABC9CFFBCF
	for ; Sat, 16 Apr 2022 21:14:10 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4KgmCk4ND9z3jQF;
	Sat, 16 Apr 2022 21:14:10 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1650143650;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=WlTPmz93ZVhZndVIZMpOlOMshCW44FSzfnVOkZyiQOI=;
	b=WRbIbISFZHLLaIA2+oFtYi0EdYZOJhtecDWCxTpITB1beDZ+khOiIVD2GDvwlm5jTUi80s
	BAi25AeNZYpYcVotdtauQbNjo1/0jxCT9S2JqpTXeSewMalVBk46yDpsX1HagwNb0A4Fjz
	u/somlU2R8VXoZpDLCZ0NHYqL9k356KRn5V+rb1LhyEq8s58Uz6dr/Piv8uFwqR012JPyE
	0NQva5f1YUovGa5vMpnSCv4twFZBklnDOWs2X2tAzMhLEhQ+6g98N7ePXY7dDTgCocRva1
	RP+WiOhQBJDwrSrDJId+F0naY/puaVM44g3x6VsEiODpysunDnnv8/tMFrZGtw==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::102f])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 552DF6C8D;
	Sat, 16 Apr 2022 21:14:10 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Sat, 16 Apr 2022 17:14:09 -0400
From: Matteo Riondato 
To: Oskar Holmlund 
Cc: freebsd-arm@freebsd.org
Subject: Re: [armv7] 13.1-BETA2 boots on beaglebone, 14-CURRENT snapshot
 panics
Message-ID: <20220416211409.tafuqhgcwavmkzdc@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
References: <20220412134814.4m5cdgoqliol52gb@ubertino.local>
 <32c957088640343eae49e7e76d89ac0c@ohdata.se>
 <20220413125823.u4cpmnxutamtmql5@ubertino.local>
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mwvlmrecolqquyqn"
Content-Disposition: inline
In-Reply-To: <20220413125823.u4cpmnxutamtmql5@ubertino.local>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650143650;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=WlTPmz93ZVhZndVIZMpOlOMshCW44FSzfnVOkZyiQOI=;
	b=a71uEGxc7FeCr2+aTYqNbQO0N6EBGhnF3RJirCb+lREnaxE5OyTPaps7GQMrTox3oMu9IP
	dPcm2AbvmLKs2SObOWxtYUSCxO/E1SjKIA6O0yArqKTSUDaK3ctScChmjyoP92y+urUZrK
	aYEXY26dXu+Gc3MIGETRPDHNgjmq4W5rZ9qlGBdcNu7IKJZZiKYUKLEr2UXCtWPhjzl5LZ
	si6KswvXFGBmEHba4QlCVEubSmv3tI2iCxaZErcmoveGJmXI9oKGHLJRpgI637bEVb1nu6
	bMP0t7W14OisnbM8b9d6tX/OOaW4twcyfTcN8FdzvRDr8M1IVgJIFNYvtsFrWA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650143650; a=rsa-sha256; cv=none;
	b=JFehJTv4ROwq2styYN+bwh7yUAMvus75JMoJ0oHgvQ2YOS1gtmG93VqP5ZndINh9xR/Fqv
	d6qRSO4rsXuJP3k9mfhiVVHcrgQaTktT5HteerLGKkm0tpfQmnqbqltALoDlqbgJLe0my+
	1sW5bAq7rI6cn77XRTzfXzp+qNHHMmHhmicNAX3CCjaOUdIr9mUL9qCccq1fO8w04yz0pw
	4ephM89UoOq9nCnXwVqHqM+cOXTbDe4m2df7Ew4Lx11u1ot0HeDmY42SLxiwNY0SilWe66
	UGqP0qtai+GaRnfC+PPsQVpy7foj+licYrf8ey+rmlSBnRJWct56J3oFlTxYVw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3962
Lines: 98


--mwvlmrecolqquyqn
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-04-13 at 08:58 EDT, Matteo Riondato  wrote:
>On 2022-04-12 at 18:09 EDT, Oskar Holmlund  wrote:=20
>>2022-04-12 15:48 skrev Matteo Riondato:=20
>>>While trying to make my beaglebone enhanced boot with the =20
>>>am335x-sancloud-bbe.dtb (no success so far), I tried booting it =20
>>>with the am335x-boneblack.dtb, loaded at the loader prompt.
>>>
>>>The publicly available 13.1-BETA2 GENERICSD image boots into =20
>>>multi-user (boot -v log available at =20
>>>http://rionda.to/files/boot-13.1-BETA2-boneblack.log), while the =20
>>>14-CURRENT 20220407 snapshot panics as follows:=20
>>>[SNIP]=20
>>>I can also build my own image trying to bisect the problem, but =20
>>>wonder if anyone has any hint of what commit(s) could be causing =20
>>>this issue.
>>>
>>>(I also wonder whether I should be posting on freebsd-current@, =20
>>>rather than freebsd-arm@ . Suggestions accepted)
>
>>Read this thread=20
>>https://lists.freebsd.org/archives/freebsd-arm/2021-August/000410.html
>>
>>I'm not sure the reviews mentioned in the last post are the one to =20
>>use today. I hope I find some time to do a testbuild tomorrow and =20
>>get back to you.
>
>Thank you, Oskar, I'll give it a shot in the next few days.

Hi Oskar,

The patches at the linked reviews made my BBE boot to multiuser. Thank=20
you for creating them. Some details below:

	* I uploaded the bootverbose log at=20
	 https://rionda.to/files/boot-14.0-CURRENT(patched)-sancloud-bbe.log
	 in case it may interest you.

	* The patch at https://reviews.freebsd.org/D27889 didn't apply=20
	cleanly (I'm not entirely sure why, it seems that very little has=20
	changed since it was created), but it was easy to apply the rejs.=20
	The patch at https://reviews.freebsd.org/D31311 applied cleanly.

	* I enabled building am335x-sancloud-bbe.dtb in=20
	sys/modules/dtb/am335x/Makefile, and I managed to boot to multiuser=20
	by loading it at the loader prompt. While the BBE was able to boot=20
	13.x to multiuser by loading am335x-boneblack.dtb, that's no longer=20
	the case for 14.

	* The onboard Wi-Fi does not seem to be recognized out of the box.=20
	It should be supported by rtwn(4), as it is a rtwn over usb. I see=20
	the following in dmesg:
	ugen1.3:  at usbus1
	I assume I'll have to play around with the device tree. Any hint is=20
	appreciated.

	* I'm also trying to configure the pcf8563 RTC clock that is=20
	connected to the i2c bus. From=20
	https://cgit.freebsd.org/src/tree/sys/dev/iicbus/rtc/pcf85063.c, it=20
	seems it would be supported. I'll likely need something like
	pcf8563: pcf8563@51 {
		compatible =3D "nxp,pcf8563";
		reg =3D <0x51>;
	};
	in the &i2c0 section of the dts, but we'll see whether that's enough=20
	(I bet not, I'm still learning my way around dts.)


Thanks,
Matteo

--mwvlmrecolqquyqn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmJbMZoTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVARNdD/9Cggqb0VyR+Pm/fJAdan1NdTqzlMhK
YAhlhDVUY5Tles9nf/OhlrW8zu6/L42L8HqhALNS1WYrhUWuoySzjLqLIckVh5Vi
2lDA+W+U9NzzleA8l0qaL5bNukyT72cpWAIV/MNSNi9lObPopK7O+YimPlv6z/nP
DnXJLZ2Z2xRggNkxG2lDtbjCv80N9863zE/CdHKBNa3tkqOJ2CmXz1PzostXvT7o
I4TBorYezRBwAsgrh09jKLn3VI5pXHlWX1xEafTeilJbKEVEnlYtRtwO2wypMsBa
vLkIXG2uaAFlD2wsIDaVmmwDN5gsi9xgXhq/SbSkJbpfE0vK3w+atf88KpMqQYrr
ipkqTpagEI7V/PWWdHHHRugi+6Z0JgASlqUNuqg3K+JWA4Ir1HZm34VAVhLkgrZV
yXZ1GUqknhlyrAQA9o3Q6Smyvm3xvVmLxC56p0Ds04SRzKyjvd1HwI6/UOKuK93U
UwyubZpZ3VxCZoMzERkNhoA7ZKKjJsckVvxfuD17lOp2wMwGAWbzxCYidOO5zO0v
c0k0meNiylVxV6nrGeiRWeHxiRoORMqTV0kEA175Z3PCCPKCAWvpJCD+6omuW9xc
DpE8n9Xt5c6/BI3UkDhAcpj2HbwlCvsVhyUSnEN+1sGbVekdghnPtWPYK+uMXhW7
6k/JE9+WPOXmOg==
=0C6G
-----END PGP SIGNATURE-----

--mwvlmrecolqquyqn--

From nobody Sun Apr 17 11:41:07 2022
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 7C3FFCFA920
	for ; Sun, 17 Apr 2022 11:41:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh7SG3RtXz3D9t
	for ; Sun, 17 Apr 2022 11:41:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650195671; bh=ATxhoqN69VVQ4VctrJg3/Hw5aIQdygLGzw8dsR5uCHM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=DtuF6rIVGbvG2ktXT1cv7Y8yKxDw1qE5fRC+ehDt8uPuUJxtgI/gf8EYHFLW7aLSfs0te/RCM50ntVmeQCAbM0et/Lj+sYaAoYc0MrIou0p5nkMqNJBblXi7T22Bj8AntBXzvx7iWkcv3xK/qcpxBAIWgU4VWbohXlbks3iaj3YVF5/+7xoH0D6KDxRR1aLfneJuxE90eTJxe9gE31slfyATSqrCFnCHVoF7q3mWq324qBfyf2cXsNSvwSUcQBm/dwj2acF81xbdQYyKY4CGuX5rwifSVdh6vF+j10zI1XKiqCJXHxXJ4u8WKlRqhhgDgsMpNCa/xnPiaVnfkAJymg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650195671; bh=B33DqZLP++oIyYK2jxoDLS9krUAdnWYpRTXAi4U+tRi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qG7gQhVCwmxM2us7iqebUDrjkKCeC+NU7mhtrnJVXCuWC5G8bKA5WuWVi0kyCz35gVJSf47Dd4HfwB8N7tpLjShsBgOCU5UnnNXeIFAyaVlDDyO9u8zOWrU7qXsdu5Jv/4feMhUYLVDpVwU77OFLGGhnarb74H8PGut6w72H0oVJiywbJkgMkg3rZpdaqs32BFF7uBR2LmWu0epJPWwyFXST5wTlTPT6Rs2e8Cz9PGNcUzGUdpAadPxa8LGUgfBkvilsHjyQunMHSJduG0oHN28eIzsDu0YFOPdbpFgTQBVpOlCVce3Diu9kDOd8OdwR5jklsB8SCJ284dQvjIoOHw==
X-YMail-OSG: R6YwalIVM1m1AcqOIB66fcGfQOz3jsTEQuau1ag1SxFAKywvWsGYM1PNpdDQ92L
 MyCbWMjGwLWSP23jNa.yO_TApbA9Pk4OhMlKanByJaUYyI4bsiS7.LloMgJRKjKZnfXIzfWZJa80
 _35nDDaRa7TTe9YTupfEq4RiWAa4RKOQWLmLF7R3VmJQgUhIbIFDV6gZCNJu4VMAbWUVzcYnr.Pg
 8ki.YuaY60i8RCXTqyTht7S0lq20_A7g6TbyRt46mKOYz47X2tKaLfkzAc8m0is_SOTzugLvDVdG
 reUwGqL0iE0_s_hbuy9gngjd2K03Ev.p2BLPcRq18lLbXaAYAigCCTFW3SsW_zJ8RnOJt0DR9z_0
 YUBET1t1kx5rjYHtfklNB0XnChKBhof3uqysgqArwINunidkNCI3qbuAzO6AFmSwB5teEVQmdkjN
 D2IR27ehxu78AHEvtPJJgTfOoWya4EHAWoUSunu2dFIhbnK8VpDKzFMzezHr.G6Pp1_iH2dPkEqm
 0NzzHiJoN.XKkA_v6H3OnwQdLiB1Y5Hgkttdw3d2jkv_UwlQ1fc1et5DgCduWDIBCSd3kRelJ1px
 iv6IPt9hy5SFbWSSaEzWq6wkuaNXriND4qE.EsRzdnjY5jDEO2plX9_79C5a45ChQ1f5KKatrCgo
 rBDmAHjFPNryZtvBHuCacoVdO2lqdmETtG8FmdymM5XK8azbZM8dX72GFrJW3Vkq7wZcXhANjcSc
 oNAqq_hoShZ77W3ttR7K5WB.AsKNJNj5YCqys5UpfTdy_WIVYZhK_JidKyTmW3ATTGT_BLTaVlNL
 0jmqYpxxI0Sh1tw8CktUyPAxYQQg7zS1pC0GZF9sZoGmt1h0xid2NX_jiTuSQ_wPuIH3abTEn9p3
 baCjlUPLgMNBAx1YeqHJ8USmLP.UFF_LYMP8MSxXCe3vwFABRP6MJ9dAHZAQngrZdzUa7AUqJtxy
 KysLcbCWvEUo9wlJ8EDibYonCvryVnrFkaFiSuX0PTe5LahZOLX6YzWQlm5c.Kb_kskVHIlintUF
 .RRytn.EYkGPnQYdhPXKHvgXlYlVOMlAzgHL1dyH_bf2rCH9H37tPk6_XxwYFIwRlAujPIzOQ47b
 ER4j_.JNXQmPatPez0YlLoHVVZvHdFjQoX899toEUBxSzWJZQNGyKz1UX3d4GeW43ux_uhY_rDFV
 ZoBOvSTAmVbCNtdBXx2dmluwXBD6OKf3Bg9M1o87DeOf_r5IlPavYbDJU.11d43oKObtOufHXyWn
 OSXwecaIyyhh151Zjg7L8.vgryyNgZHC1AqjmCXbDwoqXQywKTAhs3lkYnd2Rem_1_GQAq_QaV6N
 JZKnutC1KcaBo4.pcvj8ZFVqmatig6mFpwL4IuS0ja_aU99_udq6MAbYa8b2iySmXKMg5V0Wm.FN
 2ZS1VmCR03A57bRpVl3zjje4AZ7amncp84Sucls1O1ck1cnzYuSfm1o5hLTgaYc5F_.nt_3rWaoL
 nA2aLX2QoJHX9OOWXtTnil7l7r6QsYqAZnAxpT3oMerAC46YoG66cHkU.36b42vz1uFVlEWsgh1o
 1LK9lwWjCe30G0m4iLXtAKVXsowr7X0pkSk_GlCH1hdKuugJWiOtqhQPiv4rPgpB.6dbBEUwMUSk
 bq_lSpr3cSL4meMpIq0KQTzvoc0lEIKXhy9_4ORo0cBnIdyR8AEX3VbBmByjdCS4XGRSwqiHrKOA
 QPDC7faDckxiDMOEdhZr6QZXCIvmwiHuy9sbpVG.dP63ds5qp0wCjKgJG19nKtP8xgpQBmYzcjHg
 7B4hyktvEY2uGxKjhnQjYroqIhbl.z.mz7Ne8mYIlRVGkh3iiy7BfJ0AN.l9ktolLVCMzG6YT5oL
 mbRei5KE1CfaWOaldB5TSGlm6_3xQUEVNVJfBX4cV21S7OAouaDOEp23.nzUWZfw5IQUzE2pkjll
 D6Ec7f6bmDkREfcTBECl.vlfjMmuKa2k0xDiO21WfdOrj..3thWIouvCVlrx3QHRX4rwAjY2sDer
 gyEuVK8vpgfos_72bTUNLDoK4dpCsQ27ksko7A8s7suQuXxFkJ7FIeUciMqffvXBHx8BJhLelKUD
 3SR2Q1eX9mlk0syeWwIiVBYpkSmOVZ5bMALbaz1.W1spviDPl9Q9k6cQ.g2UvE1Jp76lm2S2BZ9U
 mnhB77tnoPmfViWmNG6N3zGbNgcgC8f9imEyGVTg3tFlMzW07aSRd4qMDxDluEIKbKc5F8cKqO1P
 rMCrk8sit.NFSWJgY7Us7cGNuKz1YpCwYUbDvgo8mEa4zfCQ.XjiHSczdtF624mw8DUB_V_3o9Q-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Apr 2022 11:41:11 +0000
Received: by hermes--canary-production-gq1-665697845d-ftzwk (VZM Hermes SMTP Server) with ESMTPA ID 881da988dfe6eeb042830fa86b88812a;
          Sun, 17 Apr 2022 11:41:08 +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 14.0 \(3654.120.0.1.13\))
Subject: A FreeBSD port to build a RPI_EFI.fd matching
 https://github.com/pftf/RPi4 versioning?
Message-Id: 
Date: Sun, 17 Apr 2022 04:41:07 -0700
To: Free BSD 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4Kh7SG3RtXz3D9t
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=DtuF6rIV;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-0.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5891
Lines: 156

One of the things about the sysutils/edk2@rpi4 port flavor is that
it does not build the same tested/in-use releases as the project
that develops the EDK2 support for the RPi4: different commits
are used.

I wonder if it would be worthwhile to have a port that has
the purpose of building what matches some https://github.com/pftf/RPi4
release. So I tried to make a variant of sysutils/edk2 that
does build such. (I'm new to creating a port, even as a
textually minor variation of another one.)

Part of the prompt for this is OpenBSD has taken the route of:

QUOTE of https://www.openbsd.org/arm64.html :
Some Raspberry Pi models that do not work with the included
U-Boot (e.g. Raspberry Pi 400) can instead be booted using
EDK2-based UEFI firmware.
END QUOTE

(Where the link in that text is to: https://github.com/pftf/RPi4 .)

I suspect such may well be true of the RPi4B C0T parts
that do not have the odd size limitations, such as a
3 GiBytes limitation.

As for https://github.com/pftf/RPi4 vs. tianocore . . .

All https://github.com/pftf/RPi4 really does is hold a git
repository that has the https://github.com/tianocore/edk2*
and such needed as submodules --plus having a patch or two.
(I ignore .github/workflows material here.)

I made a variant of sysutils/edk2 that only targets
allowing tracking of what https://github.com/pftf/RPi4
uses from tianocore (and what that in turn uses). For now,
I used the example of matching v1.33 for
https://github.com/pftf/RPi4 (the most recent release).

The core of it is:

PORTNAME=3D       edk2-pftf-rpi4
DISTVERSIONPREFIX=3D      v
DISTVERSION=3D    1.33
CATEGORIES=3D     sysutils
. . .
COMMENT=3D        EDK2 Firmware matching a github.com/pftf/RPi4 version

# Tags for tianocore submodules needed. (Note: pftf/RPi3 does not
# match pftf/RPi4 .) Same tags as git submodule status reports for
# manually following the pftf/RPi4 steps.
# Also later true of GH_TAGNAME for edk2.
PLATFORM_TAG=3D   958fc02b15
NONOSI_TAG=3D     0320db9

# Tags for non-tianocore submodules used by tianocore for the
# pftf/RPi4 build. BROTLI_TAG has a 2nd use, handled via the
# post-extract make target. (Some submodules are not listed
# because they are unused for pftf/RPi4 .) Note: pftf/RPi3
# does not match pftf/RPI4 .
OPENSSL_TAG=3D    OpenSSL_1_1_1j
SOFTFLOAT_TAG=3D  b64af41
ONIGURUMA_TAG=3D  v6.9.4_mark1
BROTLI_TAG=3D     v1.0.9-36-gf4153a0
# Note: git submodule status showed v1.0.9-35-gf4153a0 but that
# failed here and when I counted I got 36. So I tried 36 --and it
# worked.

One oddity that I ran into is a known problem for FreeBSD's
/lib/libgcc_s.so.1 vs. aarch64 g++ code generation. I documented
that with:

USE_GCC=3D        11:build
# Note:
# I needed to use a -Wl,-rpath=3D/usr/local/lib/gcc* to work around
# FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate
# coverage for aarch64 g++ code generation's use of libgcc_s.so.1 .
# Otherwise tools built, such as VfrCompile, get the following
# when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
# required by /usr/local/lib/gcc11/libstdc++.so.6 not found".
# I did not see a supported way to have an automatically
# adjusting -Wl,-rpath=3D/usr/local/lib/gcc* .
. . .
# Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
#         required by /usr/local/lib/gcc11/libstdc++.so.6 not found"
# (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate
# coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ):
EXTRA_LDFLAGS+=3D -Wl,-rpath=3D${LOCALBASE}/lib/gcc11
. . .
# Emulate source edk2/edksetup.sh
MAKE_ENV+=3D      WORKSPACE=3D${WRKDIR} \
                =
PACKAGES_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PL=
ATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \
                CONF_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/Conf \
                EDK_TOOLS_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools =
\
                =
PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH=
} \
                PYTHON_COMMAND=3Dpython3 \
                PYTHONHASHSEED=3D1 \
                EXTRA_LDFLAGS=3D${EXTRA_LDFLAGS}

I kept the original patch file names. One I could list in
EXTRA_PATCHES and the other was used via post-patch:

# Using same patch file names as pftf/RPi4 :
EXTRA_PATCHES=3D  =
${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patc=
h:-p1
. . .
# Using same patch file names as pftf/RPi4 :
post-patch:
        ${PATCH} -d ${WRKDIR}/edk2-platforms-${PLATFORM_TAG} -p1 -s < =
${FILESDIR}/0002-Check-for-Boot-Discovery-Policy-change.patch

pkg-descr and distinfo were updated as well.

poudriere testport seemed to be happy with things.
portlint only complains about the limitation to
exactly gcc11 (or whatever is listed there).

But I've not actually tested the image built (yet?).
Note that, unlike sysutils/edk2@rpi4 , the port
does build to completion. (sysutils/edk2@FLAVOR builds
have been failing for a very long time for versions
of gcc that handle C's newer VLA notation correctly
(Variable Length Array). This is because brotli
violated the C language definition but gcc10 and
before ignored the issue. (Otherwise the other things
likely would have also been broken.) But, even when it
built, I avoided the mix of versions that no development
team was testing for the platform(s) of interest to me.)

So I got far enough along to ask: does a port for this
purpose seem worthwhile?

I'll note that FreeBSD still has no ACPI drivers
supporting the use of the RPi4B's:

A) built-in microsd card slot
B) built-in EtherNet port

I use USB devices for such when using
https://github.com/pftf/RPi4 .

It is possible that I'll get access to a RPi4B with
a C0T part (no odd size limitations) that is also
Rev 1.5 (new PMIC) instead of Rev 1.4 . So I may end
up able to test booting and operation of an example
of such.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 17 17:28:42 2022
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 556B25D3240
	for ; Sun, 17 Apr 2022 17:28:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KhH9M2pkTz4f5G
	for ; Sun, 17 Apr 2022 17:28:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650216528; bh=oooY1uAaB0Ip8a5a3UXJScnKN9pY37wf0ikbFA2I5kc=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=CFcEsrG5uVJgpdmxAGxtJWWMccJO7qxxVBg6QXU7qFdhevExfwnwZf/xApn4hKVD8Quu0xxU7X1gHQjW8YL8/GvXTw4cPhLLcx9NZbIcPV/BJpeqcGWiqgcbLx8YiqFl6cgz31sZveMLJmIe//3a911QihkVAbrRCwF6wUMGdwYBBSDA3nZ7jUtqdRFc40Vy87CKDsQ2ka/kJvN1cb88LCBDnkkFKzc1bJw/c0wkr2sXln1dfFZg7OH7EKcjeDBRuaV8Jgzoks4tZ73tcrgzNEfm808aInOTRr2ZSifUVdQIMplQSsFWR4sj1wsN9klFlqIQfDY/TDjEjLKZCJJsDA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650216528; bh=0OEvXvhYFuHtweH7UfmKgyp1IKgFLKWyKSXJe2eEqrs=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=U0E9vHYGoqcDbHv3TSb81Qmq1ePTMZNKlD74VV+iCYz204jojawBqcF+QQ/w/iySEsvj8HTe/2/BrO2jlMvXzE6KLHWoXiQuFHw1a+pYshpd0m5SObdem1Tk9kqaDEh0ZyJEBhNrXYAOLnTtpsA8wP6Vy8gSEjSiamgm13GqiKNilto3ju7U8pPCTNJHlPbfeuWgApEVFXUUxJjkuepu/9uW64DhSRGerH65KevCaEz3amGw7kG9mVjRjSV0FqCUnJJP08ktvyG/+KjWeRHmY8I3ItTZBoy1GGYrG+bZnWqRc6rzyTOi3LWnEgfN68QVVRcR5NME2a2jlqfnqzhlBQ==
X-YMail-OSG: Am2itbAVM1maVR1ZOWiWLnBL9zkJtzk9Fsfu0qiUmtlY6wS5oQiB.u8i1PMqAoo
 1S7PvOleK2sqPi8qCWG1YplqYPqRLKBagmPQU76hnOExswNnAdaR9lqG75i8uGJx8OHuK1.e.tqX
 NHooW_AUvqAZzkTrY9Jbkf5p5UhLwKFnGFSDDiE_dVvl4_Y4jdBsUyQ4c7c4kPRCn2u3LfwINyvc
 nGPYap4tBH3EIYW6XtQn42NaM_CzTjasvWssHgKn4sE8Kms99FoXbhS8JoReyCX9kSBWpvV2DodY
 TQnPck.lb3sPuO0fEQARfo8yEqDowvgvzUPmZRvbYBSt90yQwL1NUay1pkRw0uC7NJSsG.u05Wim
 16yQCIPwLOIDYmdFHaiIMVH.2yIacWJjE5BHjLix9cvs8tBw8ydH1fXMoqyV.HO74x3WhesuB.7D
 mK6oDDje03_1rCngcnw1f25beD.DUUUsWhrvgR5gcVsCS0BLoWQbKpYaaw_rokCCSHTM6Ee8TJ9X
 hlwn14o90FisVkOEKPf1AhGfNY.KZfLd1T06BSUx6OU6xh.FimvqiiJ7ujLvyHzPgF2IX2ZEpmhk
 PyZ9NKyZ2xjD_l4chL7zepDOfByBt7Qg7MNekKhYchLS7H6izFzG.QO7qjzjwd88jiHeYTmF3XJ3
 96VhRnhu_X04TjZvP6M8ZlMgaFU5DP.FbLUTm2SW9RWv2YXAlgnrzVNPleK5MxWf.qSz81wpC5a0
 kKefIBG6mhfe3xIkveQIZX06W_CaTzlNlSJh7n7fazk9X3KXWc5DtTut52hq7rlU3h11YgsRs5hA
 .PMcUgUsS85ldlgsHzJx2T_a2iQlpmUB0rKTbey6jeDeBcwm2ZqQBgpsicGOXPGbW5k_49gUkDMu
 ua6GgmVjX95qCvvBxJ8JGUXG4NdfDbW8IC_QxQPSUzX4LDEEDwj5v.xrrr.W_LARrGMDj0v382n6
 Vw1AQTjJ7eHkM5MwIiZCuKmXjPxB4C29WFPCE1ZQl7ClcFFayY40FKYSe.X_Z7ro4plKJCQ.iS.k
 BdLi2NpPKbmvlaR_zAFJ5KMorkefsI.cXdSlo0RH.Wo1PZ1TVtbyM_wK3xgiqyo_hIUdHlRpjFNt
 rzlI0r2Ym6i3W7NvqbrKZ.xJH0_j2gQU9pOsj3AidHISPCbu62ac1dixhsB9Nr.TdGJxdflgX8lX
 q4uFwC0FyLHse9dlodrRojzlrvZzuwCo2gQ6WUM373A6oGWMl8FPB7pX.9JHOiL39C8hvo7_EQeQ
 GmOhGjoXRQtsGlljR8wQS_DyHsj64M2qnD3dhOkZc7o0Z_FmYqOxRNvfsAY.pp83ILhGVIFi2mFK
 MpNtlZr8NO8zkA9jEvPX.b0E545yh6QBH8xTeKGWQsLbEPAesnfRzbwnASWBih20.PQHtmmNvUtM
 8qfp7RKbjFYRkEReH.QVA5V5.oAqk6ahh6qatH5nlyhzs3Y6rBgzDwu243FdQS4L2vphA3ZB_1Zd
 dLPJcsVDc18ZuOKMOsXpXHUezFVriNTsj.r4tNyCJxto9bi1TZRHWi8qcOFNVi.qUxnTTqwOGrqn
 eAACJTJSNNaaezFmvBQiN8CDAKwyB9vwk2m2nbecHFmqGX.WpuUMCbn3KMTSVkXVrqImqLgHSrL9
 y4uNFrUYcGc2a6oiPsBowIAkj2N7x2NvYsl9DDtfUU2Jxc2jN3X6f6KXk02EWnTd5C1EKv8lybOO
 JTGUMZZhQ01H0WllGJ3Djaz_ikotKUhV71BDmk0Eg4Mje6TafwOxPdgtbywunu1xYf0Y9ZhcC5Ye
 SWJQPpAgCAvposwxqLp564a4uLBryXENVl4QYA1xx3W4CbjrOUsMyM.g.khRKhDE1caUOWA37WWZ
 zzZmZDZ.boxJw9yD9CVlrgT0XlqyZKIQ2MqAfGVW_pr_ZtmAi9y7eN7DqiPMDEQTJnBUPckbKkkj
 lBFZCb.CN04jPb4E5tpjB_PaIDAF1DODznnySj_KZSlbv9WIjhvBl9k7WFhTtZmi5mQ4sBADhxAV
 O9lHPVvl.esUw_7.AHj2GF0fmmR.G2xFz7Rmc8l7dHf.g30dtJtVhwL2Txn2_NAayftCK8x1D3NV
 DUWK.NzdFJtlJ7Ww.9XBAqpRFLUIQjyTJH8P_O26E0wE2DAd4Wkx7XE_Jto8lFD7MrCjUqnW6MVc
 aNstDOuhcndsToaDay7V6JLFDHYiUQP8u6tXrbvZzzRB2J9EDvSu2EfdK6McpgHdIu80IvF__hua
 gpC1JcupprpeCanlTz02DrPufgbZ39Jo2zJvCXhtu0FOvwtqRtBLq_Z0uTWF55gBk2qC8ZBA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Apr 2022 17:28:48 +0000
Received: by hermes--canary-production-ne1-c7c4f6977-qcc8c (VZM Hermes SMTP Server) with ESMTPA ID c20d29c1388adb58255adc8e949b169b;
          Sun, 17 Apr 2022 17:28:44 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: A FreeBSD port to build a RPI_EFI.fd matching
 https://github.com/pftf/RPi4 versioning?
Date: Sun, 17 Apr 2022 10:28:42 -0700
References: 
To: Free BSD 
In-Reply-To: 
Message-Id: <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KhH9M2pkTz4f5G
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CFcEsrG5;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [1.40 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_SHORT(0.90)[0.898];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6697
Lines: 171

On 2022-Apr-17, at 04:41, Mark Millard  wrote:

> One of the things about the sysutils/edk2@rpi4 port flavor is that
> it does not build the same tested/in-use releases as the project
> that develops the EDK2 support for the RPi4: different commits
> are used.
>=20
> I wonder if it would be worthwhile to have a port that has
> the purpose of building what matches some https://github.com/pftf/RPi4
> release. So I tried to make a variant of sysutils/edk2 that
> does build such. (I'm new to creating a port, even as a
> textually minor variation of another one.)
>=20
> Part of the prompt for this is OpenBSD has taken the route of:
>=20
> QUOTE of https://www.openbsd.org/arm64.html :
> Some Raspberry Pi models that do not work with the included
> U-Boot (e.g. Raspberry Pi 400) can instead be booted using
> EDK2-based UEFI firmware.
> END QUOTE
>=20
> (Where the link in that text is to: https://github.com/pftf/RPi4 .)
>=20
> I suspect such may well be true of the RPi4B C0T parts
> that do not have the odd size limitations, such as a
> 3 GiBytes limitation.
>=20
> As for https://github.com/pftf/RPi4 vs. tianocore . . .
>=20
> All https://github.com/pftf/RPi4 really does is hold a git
> repository that has the https://github.com/tianocore/edk2*
> and such needed as submodules --plus having a patch or two.
> (I ignore .github/workflows material here.)
>=20
> I made a variant of sysutils/edk2 that only targets
> allowing tracking of what https://github.com/pftf/RPi4
> uses from tianocore (and what that in turn uses). For now,
> I used the example of matching v1.33 for
> https://github.com/pftf/RPi4 (the most recent release).
>=20
> The core of it is:
>=20
> PORTNAME=3D       edk2-pftf-rpi4
> DISTVERSIONPREFIX=3D      v
> DISTVERSION=3D    1.33
> CATEGORIES=3D     sysutils
> . . .
> COMMENT=3D        EDK2 Firmware matching a github.com/pftf/RPi4 =
version
>=20
> # Tags for tianocore submodules needed. (Note: pftf/RPi3 does not
> # match pftf/RPi4 .) Same tags as git submodule status reports for
> # manually following the pftf/RPi4 steps.
> # Also later true of GH_TAGNAME for edk2.
> PLATFORM_TAG=3D   958fc02b15
> NONOSI_TAG=3D     0320db9
>=20
> # Tags for non-tianocore submodules used by tianocore for the
> # pftf/RPi4 build. BROTLI_TAG has a 2nd use, handled via the
> # post-extract make target. (Some submodules are not listed
> # because they are unused for pftf/RPi4 .) Note: pftf/RPi3
> # does not match pftf/RPI4 .
> OPENSSL_TAG=3D    OpenSSL_1_1_1j
> SOFTFLOAT_TAG=3D  b64af41
> ONIGURUMA_TAG=3D  v6.9.4_mark1
> BROTLI_TAG=3D     v1.0.9-36-gf4153a0
> # Note: git submodule status showed v1.0.9-35-gf4153a0 but that
> # failed here and when I counted I got 36. So I tried 36 --and it
> # worked.
>=20
> One oddity that I ran into is a known problem for FreeBSD's
> /lib/libgcc_s.so.1 vs. aarch64 g++ code generation. I documented
> that with:
>=20
> USE_GCC=3D        11:build
> # Note:
> # I needed to use a -Wl,-rpath=3D/usr/local/lib/gcc* to work around
> # FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate
> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 .
> # Otherwise tools built, such as VfrCompile, get the following
> # when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
> # required by /usr/local/lib/gcc11/libstdc++.so.6 not found".
> # I did not see a supported way to have an automatically
> # adjusting -Wl,-rpath=3D/usr/local/lib/gcc* .
> . . .
> # Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
> #         required by /usr/local/lib/gcc11/libstdc++.so.6 not found"
> # (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate
> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ):
> EXTRA_LDFLAGS+=3D -Wl,-rpath=3D${LOCALBASE}/lib/gcc11
> . . .
> # Emulate source edk2/edksetup.sh
> MAKE_ENV+=3D      WORKSPACE=3D${WRKDIR} \
>                =
PACKAGES_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PL=
ATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \
>                CONF_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/Conf \
>                EDK_TOOLS_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools =
\
>                =
PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH=
} \
>                PYTHON_COMMAND=3Dpython3 \
>                PYTHONHASHSEED=3D1 \
>                EXTRA_LDFLAGS=3D${EXTRA_LDFLAGS}
>=20
> I kept the original patch file names. One I could list in
> EXTRA_PATCHES and the other was used via post-patch:
>=20
> # Using same patch file names as pftf/RPi4 :
> EXTRA_PATCHES=3D  =
${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patc=
h:-p1
> . . .
> # Using same patch file names as pftf/RPi4 :
> post-patch:
>        ${PATCH} -d ${WRKDIR}/edk2-platforms-${PLATFORM_TAG} -p1 -s < =
${FILESDIR}/0002-Check-for-Boot-Discovery-Policy-change.patch
>=20
> pkg-descr and distinfo were updated as well.
>=20
> poudriere testport seemed to be happy with things.
> portlint only complains about the limitation to
> exactly gcc11 (or whatever is listed there).
>=20
> But I've not actually tested the image built (yet?).
> Note that, unlike sysutils/edk2@rpi4 , the port
> does build to completion. (sysutils/edk2@FLAVOR builds
> have been failing for a very long time for versions
> of gcc that handle C's newer VLA notation correctly
> (Variable Length Array). This is because brotli
> violated the C language definition but gcc10 and
> before ignored the issue. (Otherwise the other things
> likely would have also been broken.) But, even when it
> built, I avoided the mix of versions that no development
> team was testing for the platform(s) of interest to me.)
>=20
> So I got far enough along to ask: does a port for this
> purpose seem worthwhile?
>=20
> I'll note that FreeBSD still has no ACPI drivers
> supporting the use of the RPi4B's:
>=20
> A) built-in microsd card slot
> B) built-in EtherNet port
>=20
> I use USB devices for such when using
> https://github.com/pftf/RPi4 .
>=20
> It is possible that I'll get access to a RPi4B with
> a C0T part (no odd size limitations) that is also
> Rev 1.5 (new PMIC) instead of Rev 1.4 . So I may end
> up able to test booting and operation of an example
> of such.
>=20

I should have noted that I've not done anything (yet?)
about getting a copy of the RPi* firmware that
https://github.com/pftf/RPi4 bundles in a release
(v1.33 here). As stands, it is only the EDK2's RPI_EFI.fd
that is provided.

Part of what https://github.com/pftf/RPi4 provides is that
they develop a working combination and update when
problems are discovered, such a reverting to older RPi*
firmware.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 17 21:00:01 2022
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 3356F7E9125
	for ; Sun, 17 Apr 2022 21:00: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 4KhMrx6Mg9z3K94
	for ; Sun, 17 Apr 2022 21:00:01 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 B7AA32547A
	for ; Sun, 17 Apr 2022 21:00: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 23HL01CO018125
	for ; Sun, 17 Apr 2022 21:00:01 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23HL01TB018124
	for freebsd-arm@FreeBSD.org; Sun, 17 Apr 2022 21:00:01 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202204172100.23HL01TB018124@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, 17 Apr 2022 21:00: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="16502292013.4dFc0.17539"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650229201;
	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=gvyodDWXqHgzTR6Ft8lWl4IhwCPv87O8+szfi+kJ3TY=;
	b=Nt3Bix9oK7y94pH96cjI+vKFX3wagMP+eSp9UW+I8zGjqv8vuroFFm9CRGvpZFyROFnLfP
	lLtStNryoVsATCsae6LAkGQFUrhX9nhT9pHQUm5r4C4MLdW+WLK27Z204eGKEyIUeLFeJk
	A9ZXa82py1DrwaK0CMn8/13vFs2+sTJQJ/4P1+/9iAUn6RV/DWbni5FrDzQeF4xju4V4gN
	gSznz+IoxOYuBp49xpA8/DBKb8D1X06qFOmIb07Sv7+8xZDANrRmdviq9tXfaEwk9LgzkS
	1ZvcRqD4ZqK/Wt+5/gLRvRLFRKsmrg2AUP2RjfzDkKILiAoMODs0uZsGwpjzsg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650229201; a=rsa-sha256; cv=none;
	b=D1Lw3KGioglzKn7GT7uo8e05iiMT6oy0xPT7RmGipujhhvw+tUzGlxzxPvATap4Qexwhe2
	KLgYK1Mdfg+X8f9gLYjWvBiu0+nhepbZsSlUwiEgi6jsg5I6ce//vREWeHOLONvY91b6iB
	6mxTBL9uvKVRGtq6Z0QOp4RE5W0eZq1rHtZb8azb1akwJnYTckxI1E+9PpS7MW0OiU5Vjh
	fcP74+JZethtzIeP363iisFhFCK6M0asXDitAqEyInIhinh2EAqZTbM9rCNiL/KyVj1rkT
	66RV66QEZvj6Mkqhb2JZ+mTiOelGKmqQ/FYVYNiy/BqSsK71dEaQIxjlAfymDg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1798
Lines: 38


--16502292013.4dFc0.17539
Date: Sun, 17 Apr 2022 21:00: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.

--16502292013.4dFc0.17539
Date: Sun, 17 Apr 2022 21:00: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.


--16502292013.4dFc0.17539--

From nobody Sun Apr 17 22:14:55 2022
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 CDB1611CF3A9
	for ; Sun, 17 Apr 2022 22:15:10 +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 ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KhPWd57ZQz3rKV
	for ; Sun, 17 Apr 2022 22:15:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650233702; bh=HmjK3Lexx9rL0EWanOOhai5BhkYFnwdyJMf+SSBXWfQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=aTPw3+BXGm2aqUwpsb6pi3KCVlND9C00X7q11LcgmSmZ08bGrw/8bOegix7NXCCsHm0Kl+a+H4geKwluWoFMiwMK1DLO1IaTuSWAAb9I3a9K3aO6xnneZSunrn827KLTmBKOWWcDVgabBuiiW1kpdQhQREjHtx4zvMSNRirYWo3ilbuESnwt9VXQ8z/byKjlo80A7p0rMEd39P+e1C6+ksuZaazQmlmdBjFjQHu7bYvFkChwECwpSLJ2iP7omjp7jEuYSjmpQXX+5yi7edupNycDDNAKIHZQAeqQjuyc2f27g5Os0CXsZ9EXfkV88zRy9S64BzBhmfiKlS8NZT9csg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650233702; bh=nMobrbq7guBrlJUPszqfkfQOXDDg1Qs0HrvqY/NFIM9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EwUTwrlsrsB2l1J/7yJLQRApVMjP728TwurqxR2VgaQBYlA9DSsoVgfflQYPy/bk9VAYqEhj9isuFcP62rFdY5yrp7djmjscdi5e+L//QW7s3LAWQa97aimIXjIwRP732UI7rIZonH9YllaS040VveAsNcsDeEFeuV9gnsTzYCUMIZIVc6dMY2pAxA6xW4I0DEuqjoPlHm/wgLipMIXYmoJAycFUm9IiCfxHgWcfeZfERq4BApKYrXx8vpoLuzLnVwCfQAHugUT2ZanlXVg97OQQ4nySQ4YpTKQHUP5qwx0UPhPKY0ZxRd42LIjHQ/kQ83vLmsFqHAJokGoK0dgp7A==
X-YMail-OSG: 5uGTomEVM1ninnQr2b4VZ8Lc_cD6TM9.1yWOYaGIi1azoNPFrOnPJzBWF6YEuOz
 aasJrFLrPscDeU9jJZVGkh88fhIZB16y0HCU3JxfOrngeqRLG1bdPn8CBfhUXd1y_wVAW1ErL3et
 EMnMDIL1Gfkxbq0aEJ0mrFrXWhQZW_i_OkM.vbzZOxQxh45mdi0NzN9hSKq_KldB_PpSWNH8Y2Tz
 HCzQTsft0CzzlghNCUeUqBMkqs29H_J6dFqKdtRzydyOIV8kqKdiJLM8ZUtyfy6crXYYe6lxYiUn
 JFxNBMBVs09ja77TBHz7br5vd2WjjDVX2A_K6d5BlgpXEvT2JQXh2dA1LYTQwvAOZ3Gr7aEBAzBZ
 Xv6L.dcY.z_.Br5dvbj3RTdoCQSiIii3SKMECJFjVmQ1aeFHMxdy2JZitupkCJIEhJRLRnNQSIPY
 i058w0S8KJfwJneaC0IdI9OAqBStf56wJBoImLDHGFIC59HZJWUtlV9tziT1UfRi6PRSdYb1BMSJ
 UXyTdODXTwLsimRiAbZzf063BFvSOeVcavVXuYzXQEZdO6vag_BFcZ8woJrXvnfBocj9WSCWeDDP
 f.JzR7D8OCt.LfNJxsRHXIvTxNTAK1IdBXWdK_5A9z5xqpJrYOH8OEO64bD.T0zRYIw7lbODCzWe
 nPsMts5RwULQdbxO.QjEmlx8.CIlOq2Ovw5RAZlYucm26zoGSLi2q94wPLun.JCM4gaU6tySZiBM
 pnx0WWDKHOdUlPm1GKv3rfhYrb2cQqjNRVfZPFt9fuueGFvorfW3.kHhnCoLprekRKoLJGo6fqe_
 C57wNLANk4A4OwfdUfYWNqluUqYMjrwRXnzjTlIFbzcpAVWJbwx1WxmytW6BGUOMUW3vgdcGieC7
 JobSAGUO1l1ZPjZgclAYy3SfldVHRZj_daaIvgJcPYT9gW4Y5mkd1I3gMyW1ttPDWXkIx0TjsfLS
 AElCRCkPgufSfsWtalKQLboyNhRTfaDx5WwbXEOMuHpfBJYy8m1JdkyhfGQRbGp9FGWN1galSEPP
 jRocfNGi2LML5Vd8EqMY9xoNU4Wz9XmkZ2zo_.TrbkyuUNoPLxC6Ckiy0t2GfYtbJLSalH0pfVfL
 G8QzdBdGDQ4y_5S7YPUA2CWAxLuDwyny8UoTbb9S4RxIO.XX1ICH3rKe_nhe3rjJNoLoh8gApKeS
 GzhlmxF0qhzr.nLb2xxXVVBQPHt3gBa4ZvzM1Bm7O21XDHzWooo6YAqRW8wWwPkd8qtzvjfdVYOs
 dQxifNwKOSUjvd9ZiFD7QKITcWlMBCDYW2yC4s.DSGxHvTth52nKCBy5_KL1EGL2OBkzyR5ex3gj
 LndSVVcLJFO3.ZPwPOn.QoFaMypBrbo43F7WLB4.jDbuUvftixBlR1Ghj_O9cS11xiQoWXTKERJb
 _5MjdzLouUQRmJGXlxdnaARloFMP0Q9n_qk8uVr_YBpdPFjyU8Q.RdooqJboXkCoY4Mt.GKE5gJV
 kPLHU_AqZk4d579EdIUBUsZQp261uNDEy4XmBQW0B6zDrjDcG3RfVw94pQWxt87DZG6Nil9tx1O7
 J9AC8lnizPRRQXD0D6HI8sK2VVzRLYGObTDIJncffbElm_FEptExIk1EaZqcre5pFnxl8CqpSEiU
 797kji33Egr7j.1Atw8MJNJkSuraYidKtK5EHdv0YFsZWJGO_9WtAoC4AXhl66g79O0OJn6GS0Dt
 KqqIzpMg.i_w0fE26bP0bHyS0HBIHUXP9YrfiWUqsjbMyy_EbcYx61K_LGp5mNTqXZZgAQuCLkoe
 rdPMHZshAARBbtcRMvHDQhAF3PjwUul2lwwpaCK3PUuD8unkRXi8gT8s3g6.u0P3FKgOZrjw8RDu
 rvqyHUZTl2Gj0zQ0GU69nzqCHEU9yWwzTDcPkE0RTOKJBqVKZ0G1PrCQFCF4IiV.8UGr5Sx1r5DZ
 QQ5xdui_wdXEduzzJFH0_.72FvUBSpOjxyTZ5g2rt6Xd7qvQ5BWF22x6wyq6kh5qa0Ii84xu5dl7
 L6B.Xy8c1jTtSMhxFY__.1Tf.f2na4g0iMVc2zCqMZQlvp2d57DnGXUoyrti67xT_is7xPBArW6O
 aH6SvtxHDfL4FWLdUTH7bIaZh4ZrXUiccMaNknZPY.2PwKYEzCkBUJ10G0uQJ199c6Nl77ODWRhv
 0HcdxKBKrlFwAxtIoX1S4N7ptNRk4QrS1x_fbLtcofYN._udFbvwIqno3NcRsiJWTgXPNNMVQBO3
 6nRQwEtCNGrMGVQVUTLDWlWUqvRdczNnGP73WxhHhxexfj8HydQJ.C28KGxUYvPavdDJ7h7g-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Apr 2022 22:15:02 +0000
Received: by hermes--canary-production-ne1-c7c4f6977-qcc8c (VZM Hermes SMTP Server) with ESMTPA ID 452077bd14071764b407a07c563c90a0;
          Sun, 17 Apr 2022 22:14:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: A FreeBSD port to build a RPI_EFI.fd matching
 https://github.com/pftf/RPi4 versioning?
Date: Sun, 17 Apr 2022 15:14:55 -0700
References: 
 <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com>
To: Free BSD 
In-Reply-To: <4B03F462-5C34-4B36-9075-586CFE59037C@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KhPWd57ZQz3rKV
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aTPw3+BX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.48 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.98)[-0.978];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8824
Lines: 225

On 2022-Apr-17, at 10:28, Mark Millard  wrote:

> On 2022-Apr-17, at 04:41, Mark Millard  wrote:
>=20
>> One of the things about the sysutils/edk2@rpi4 port flavor is that
>> it does not build the same tested/in-use releases as the project
>> that develops the EDK2 support for the RPi4: different commits
>> are used.
>>=20
>> I wonder if it would be worthwhile to have a port that has
>> the purpose of building what matches some =
https://github.com/pftf/RPi4
>> release. So I tried to make a variant of sysutils/edk2 that
>> does build such. (I'm new to creating a port, even as a
>> textually minor variation of another one.)
>>=20
>> Part of the prompt for this is OpenBSD has taken the route of:
>>=20
>> QUOTE of https://www.openbsd.org/arm64.html :
>> Some Raspberry Pi models that do not work with the included
>> U-Boot (e.g. Raspberry Pi 400) can instead be booted using
>> EDK2-based UEFI firmware.
>> END QUOTE
>>=20
>> (Where the link in that text is to: https://github.com/pftf/RPi4 .)
>>=20
>> I suspect such may well be true of the RPi4B C0T parts
>> that do not have the odd size limitations, such as a
>> 3 GiBytes limitation.
>>=20
>> As for https://github.com/pftf/RPi4 vs. tianocore . . .
>>=20
>> All https://github.com/pftf/RPi4 really does is hold a git
>> repository that has the https://github.com/tianocore/edk2*
>> and such needed as submodules --plus having a patch or two.
>> (I ignore .github/workflows material here.)
>>=20
>> I made a variant of sysutils/edk2 that only targets
>> allowing tracking of what https://github.com/pftf/RPi4
>> uses from tianocore (and what that in turn uses). For now,
>> I used the example of matching v1.33 for
>> https://github.com/pftf/RPi4 (the most recent release).
>>=20
>> The core of it is:
>>=20
>> PORTNAME=3D       edk2-pftf-rpi4
>> DISTVERSIONPREFIX=3D      v
>> DISTVERSION=3D    1.33
>> CATEGORIES=3D     sysutils
>> . . .
>> COMMENT=3D        EDK2 Firmware matching a github.com/pftf/RPi4 =
version
>>=20
>> # Tags for tianocore submodules needed. (Note: pftf/RPi3 does not
>> # match pftf/RPi4 .) Same tags as git submodule status reports for
>> # manually following the pftf/RPi4 steps.
>> # Also later true of GH_TAGNAME for edk2.
>> PLATFORM_TAG=3D   958fc02b15
>> NONOSI_TAG=3D     0320db9
>>=20
>> # Tags for non-tianocore submodules used by tianocore for the
>> # pftf/RPi4 build. BROTLI_TAG has a 2nd use, handled via the
>> # post-extract make target. (Some submodules are not listed
>> # because they are unused for pftf/RPi4 .) Note: pftf/RPi3
>> # does not match pftf/RPI4 .
>> OPENSSL_TAG=3D    OpenSSL_1_1_1j
>> SOFTFLOAT_TAG=3D  b64af41
>> ONIGURUMA_TAG=3D  v6.9.4_mark1
>> BROTLI_TAG=3D     v1.0.9-36-gf4153a0
>> # Note: git submodule status showed v1.0.9-35-gf4153a0 but that
>> # failed here and when I counted I got 36. So I tried 36 --and it
>> # worked.
>>=20
>> One oddity that I ran into is a known problem for FreeBSD's
>> /lib/libgcc_s.so.1 vs. aarch64 g++ code generation. I documented
>> that with:
>>=20
>> USE_GCC=3D        11:build
>> # Note:
>> # I needed to use a -Wl,-rpath=3D/usr/local/lib/gcc* to work around
>> # FreeBSD's /lib/libgcc_s.so.1 having incomplete/inaccurate
>> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 .
>> # Otherwise tools built, such as VfrCompile, get the following
>> # when run: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
>> # required by /usr/local/lib/gcc11/libstdc++.so.6 not found".
>> # I did not see a supported way to have an automatically
>> # adjusting -Wl,-rpath=3D/usr/local/lib/gcc* .
>> . . .
>> # Avoid: "ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0
>> #         required by /usr/local/lib/gcc11/libstdc++.so.6 not found"
>> # (that is from /lib/libgcc_s.so.1 having incomplete/inaccurate
>> # coverage for aarch64 g++ code generation's use of libgcc_s.so.1 ):
>> EXTRA_LDFLAGS+=3D -Wl,-rpath=3D${LOCALBASE}/lib/gcc11
>> . . .
>> # Emulate source edk2/edksetup.sh
>> MAKE_ENV+=3D      WORKSPACE=3D${WRKDIR} \
>>               =
PACKAGES_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}:${WRKDIR}/edk2-platforms-${PL=
ATFORM_TAG}:${WRKDIR}/edk2-non-osi-${NONOSI_TAG} \
>>               CONF_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/Conf \
>>               EDK_TOOLS_PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools =
\
>>               =
PATH=3D${WRKDIR}/edk2-${GH_TAGNAME}/BaseTools/BinWrappers/PosixLike:${PATH=
} \
>>               PYTHON_COMMAND=3Dpython3 \
>>               PYTHONHASHSEED=3D1 \
>>               EXTRA_LDFLAGS=3D${EXTRA_LDFLAGS}
>>=20
>> I kept the original patch file names. One I could list in
>> EXTRA_PATCHES and the other was used via post-patch:
>>=20
>> # Using same patch file names as pftf/RPi4 :
>> EXTRA_PATCHES=3D  =
${FILESDIR}/0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patc=
h:-p1
>> . . .
>> # Using same patch file names as pftf/RPi4 :
>> post-patch:
>>       ${PATCH} -d ${WRKDIR}/edk2-platforms-${PLATFORM_TAG} -p1 -s < =
${FILESDIR}/0002-Check-for-Boot-Discovery-Policy-change.patch

I've noticed that another difference vs. sysutils/edk2@rpi4
is that the equivalent of PLAT_ARGS is different for
pftf/RPi4 than used in sysutils/edk2@rpi4 :

sysutils/edk2@rpi4 : -D X64EMU_ENABLE=3DFALSE -D CAPSULE_ENABLE=3DFALSE

pftf/RPi4          : -D SECURE_BOOT_ENABLE=3DTRUE -D =
INCLUDE_TFTP_COMMAND=3DTRUE \
                      -D NETWORK_ISCSI_ENABLE=3DTRUE -D =
SMC_PCI_SUPPORT=3D1

Nothing I did dealt with secure boot at all and I'm not so
sure that a port should. (Example: secure boot's default keys.)
So I might be more inclined to include something like:

-D INCLUDE_TFTP_COMMAND=3DTRUE -D NETWORK_ISCSI_ENABLE=3DTRUE -D =
SMC_PCI_SUPPORT=3D1

but I'm unsure about the -D X64EMU_ENABLE=3DFALSE -D =
CAPSULE_ENABLE=3DFALSE .

(Note: NETWORK_ISCSI_ENABLE is not something that pftf/RPi3
has.)

>> pkg-descr and distinfo were updated as well.
>>=20
>> poudriere testport seemed to be happy with things.
>> portlint only complains about the limitation to
>> exactly gcc11 (or whatever is listed there).
>>=20
>> But I've not actually tested the image built (yet?).
>> Note that, unlike sysutils/edk2@rpi4 , the port
>> does build to completion. (sysutils/edk2@FLAVOR builds
>> have been failing for a very long time for versions
>> of gcc that handle C's newer VLA notation correctly
>> (Variable Length Array). This is because brotli
>> violated the C language definition but gcc10 and
>> before ignored the issue. (Otherwise the other things
>> likely would have also been broken.) But, even when it
>> built, I avoided the mix of versions that no development
>> team was testing for the platform(s) of interest to me.)
>>=20
>> So I got far enough along to ask: does a port for this
>> purpose seem worthwhile?
>>=20
>> I'll note that FreeBSD still has no ACPI drivers
>> supporting the use of the RPi4B's:
>>=20
>> A) built-in microsd card slot
>> B) built-in EtherNet port
>>=20
>> I use USB devices for such when using
>> https://github.com/pftf/RPi4 .
>>=20
>> It is possible that I'll get access to a RPi4B with
>> a C0T part (no odd size limitations) that is also
>> Rev 1.5 (new PMIC) instead of Rev 1.4 . So I may end
>> up able to test booting and operation of an example
>> of such.
>>=20
>=20
> I should have noted that I've not done anything (yet?)
> about getting a copy of the RPi* firmware that
> https://github.com/pftf/RPi4 bundles in a release
> (v1.33 here). As stands, it is only the EDK2's RPI_EFI.fd
> that is provided.
>=20
> Part of what https://github.com/pftf/RPi4 provides is that
> they develop a working combination and update when
> problems are discovered, such a reverting to older RPi*
> firmware.
>=20

Hmm. Looking at the details for that last it is not what I
expected for how it is implemented. In essence, the RPi*
firmware needs to be extracted from an already built
pftf/RPi4 release in order to be reproducible . . .

The pftf/RPi4 builds themselves normally just grab from
https://github.com/raspberrypi/firmware/ 's master branch.
So, if rerun after master has changed, would produce a
different result.

They do patch in a more specific reference to specific files
when they release in order to revert one or more files. But
the other RPi* files are left as grabbed from master. In
such cases they are testing and releasing RPi* firmware
materials from a mix of time frames. (Also not what I would
have guessed.)

Still, they do make such adjustments when problem occur and
folks help them test.

I know how to look up what version a start*.elf is from
--and the fixup*.dat needs to be from the same version. But
I do not know a reasonable way to identify how to find
the .dtb or .dtbo files to grab from github in order to
have a match to what is in a pftf/RPi4 release.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Apr 18 19:36:01 2022
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 A516911E02A9
	for ; Mon, 18 Apr 2022 19:36:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Khxxn4dTdz4fFB
	for ; Mon, 18 Apr 2022 19:36:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650310566; bh=6rKw9AL64eYsYUvtgXAkz8x2ecAfN0gyoSqWwtJbmWw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=PjnLQUV2voevqcT3p65Vl3PxQ9E0v/hm/fnvEEU7rnSE6+d/TTWcCasJOzU3WVP8Xd8JFQveNJy/49dL1jnWJwPbBd0WiM8sOFgbJWPXTONfKMZ8iL+CQ/HppSCtdd73jiIhEmNwA3BjD8vu+hygSeM9SkDg2wkZnWDv2bTKcN/p8p03ODQQgByv1o2JjRcSM2ORVQlzTyCuP5tyZ77W6PPGXnfcxhHlLFdQ7MqmmdSlybx57lmi6TXu1uDnBxuAw1YtMvPJYt7mavkT58H5PA17VbmrLDuGlICFliz7S7wirUQZNhQMO3KJjDtav3GqtxvGepI8SklWH2Lf1Chixg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650310566; bh=ynus8Q/9e0zSR+a391Q+QMylsOo/9M6H19g89pymc9N=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ldCS6ODru5jAXUuZtohZNDafnlywfdw9e0IhK49MwtOLGpR4UDYWlPKp2hiQ491Q7lEL2UQTtnR9ZcWOjSCuk2TLLHoaQ05rKCujP8ycMeBah1fAKBKN6rZgUE4tDfqQEuqRhgxeOF4G6i657BY3oAWliXV+TzIeV+a/SEaEvLibk471kkcwBpdl4IQn59Odwy/XrhZ+V78ssiZAwu4WEcUDX9X4vksSkB+NQ9yM6DCvMe0xWsv+rNOujOxQyHestVTi/+ItruZA/caPmEHzc5Z9PrptvenZ2MD1363ijE5DgfXf4QCZ6p7+JpXKM+iglnJjdejp4CfG/f+O25a3vA==
X-YMail-OSG: stfVoQcVM1kEwmR6Mth3WGsW3XNd2PrzsehnD.0B6n.k6OqTqlcRuiSnXisWo1c
 NuKejZSYNQzc_3MduBz4Q.ApD28._ybjlrMtmBZaE74Ko87YKH45k1sYSZCsQiK6zsitAGlJtcxt
 uGet.Z7AhpmKUZTdFbsL4E2HwHRs5rWUp1bN2iJoydWHxu650iqRtuC6u4sDlewu7U.SUcmAr8KK
 Vn.tWoD6auveZFS4llLriL1NwSnGyxnWwFD8CSm6Hs0YXAaKIAECVtQibV3fvr7a8PeaqmgYyOHG
 mAaRHNBRxtecQQN8rPNU6.RTSWUwxl7JcjAfQsLe0qUl2mreAWcoerPL.uec.ASe_IlM8iD2UiUB
 vG2SBGFRHqlfqQllwmLBUNnhMtqMXFeXj51M9vdMMpunqcv0bKENlqbvzN3XjYIG8RDOguotUXgF
 mwEO1cY6SIckTtUgiu_tnbaqtmunQUfqJr5r_WaaecTtcNYFgI93WEYeTVHQi6re2556YLTNyE5I
 fGcxAHi6QQDKfcMzDYfB78SfW97lngyQbhWvCF5pymT1NUxpSmy0qdO.QV_2KBzTVtXsi3MTbMUt
 soRmUNOVaG2k.GgDoWi3Jn6KS18zXghTN2ZR9Zjr.UymTtymakT8xlzbl4.9FVd6J3umtACc.W9N
 IK4OMB7FwZqKGukKPVbjDagTbKMM9iQXK0KMXlGIdk9lh3i1JxY4oMR25YEDMj91eW7tzBJ3SPAI
 uxjwIIG7ncvt.30.cu8fToD8FIzIwRzk8RPf1oYhc62_4nwXzDVUvMz.lhnqtXwP8HWYsVVeaTeB
 YJ9K1D3xSbBLj8EXsiTnz52w0ZqEfBE.UQUSNjahyTM0lf253nomu6ldUBV_GoVrkoJrV_9AOWp9
 tXle.4D5L2QzE..J0DFJkj0mdBQ6UEHT4txdT8T3Ea.V5pq_tQPjajskLOxt_pNbGmdaATTbk50e
 aaMFoxGlQnvm2sHB7JyNmgyX12PVHUa8.1Wy_oAOw3qguK2J.aJeT0domzY0q9rHTmifAb87ViTI
 H7OZGFSxFw09EYaj6lf4Vglpwvmdt3cAJN2_oxZ6gbVR6MVPNFUHMElTPJHMC9pbZ7ggmnUVkLN3
 EAnyPca9QEsaX0HtRUWDAjymNGv7tWUv7d8H8SZd0N20nxudkLnlIC1JBZBrmkXpf.14K9cVdWO9
 9_ZuzPJT5WDktjjekRh8p47KZirSXxOJS0SNuCJqnnr94sB88wSsFP20wr4avfl8N3TnmQJ3KFJd
 KTQJ.e5fgj5ebi7O3Spok6840H6Sun3vTCPCVOWCrMI76rC84zqnYlINDjvcDCKQGRU.h3aniPtQ
 .hvxVKWTfgpH7FqKiIChnHMFHTlAVaMxGJstafq.skQtfpzp29.bmAJy70t4A1f1MBPrWrjchxBy
 UL70VQol1sYpbqpoq1tMsTL4jTjIYh4Dp7wvVlEGIAOnsm_COGCHU2GbvI3aa9df6LAa_bowdv5f
 x9pkjMK4mBMpxxutWDcD0nhOluqBf48JtqTKtj6kO.9sofIrih0qXVnUcyUyvwlAmom3_LQGQ.dg
 mHLV9rP_j14caHL8AQ1Pi_kQOPx1ytf2OvVVxuV6EN1wa6uXjG_BKKQQeNaBAyj8FjQgU9b4Ojtk
 UCXhgN1AYPBJQzLCreo8SD7ZJ9xwLMahvwmoq2PtLiyvSIqaQGXoZF1cQF3Ca_FrAXwFC7HLl4tN
 nf6MQLFEKPGXSDjw.MuZ6HOZlEpR7P_myrmNNUOfBay0pAQ6Ou0h2JawpK.FHUHWJ59teKpHCpzE
 KDnHuDDJ9gVqXUodU2VgsGB6liWBVMDV8FTMZP.LdnRhZXu7EXlcApvII6iipUPF3iOUPdyMH.4P
 xO_DflbHfKIDP3Bfi4DNSPgtQrRL0QRkPO0WVUlppCQiHNEV48_GGwjUvQEgLo4Tf7jMBJkue2uv
 tYpHR9EniWAAPaKEbkVlAQudwKIUah93thFy_Yszz1LZ5Idu_1uRiwR9bxPyZbnLSExh_GNR892E
 tjEVXkGaTPT0mgv7V_g9inqHSshYxnNww9RxKcyAPAnoonYPow1XudmEltSZHmJ0qStIOJlXTRiM
 PBizftLZ27RFL1K_2G54tUn9TekP0Klea2F7meriCRg2k6333mM76zhuOCm.5BHglxOsy2T.4hn.
 o_b9qjs1cg3D5p8nNMiBXrodLdQPbSSOLY9Khy85dx.QaTOtYlvPVayw7N1gk6czwjTo0Tkxqx5z
 eUQcTNBoPGsv9ifCaeXqz9h7AQbf_U0vmxUtCneiqVoRnZZL94I.2lDVUcnousnwEbnY7pHNlrZo
 fAKyUkvMJqWY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Apr 2022 19:36:06 +0000
Received: by hermes--canary-production-ne1-c7c4f6977-hpxwv (VZM Hermes SMTP Server) with ESMTPA ID 15faed27107579704ad62d62508dc817;
          Mon, 18 Apr 2022 19:36:03 +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 14.0 \(3654.120.0.1.13\))
Subject: It looks like devel/aarch64-none-elf-gcc and other aarch64 */gcc* 's
 suffer from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723
Message-Id: 
Date: Mon, 18 Apr 2022 12:36:01 -0700
To: Free BSD ,
 freebsd-ports@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4Khxxn4dTdz4fFB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=PjnLQUV2;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1763
Lines: 55

In doing some experiments, it looks like I've run into:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101723

which had fixes applied to gcc9 , gcc10, and gcc11 in very
late 2021-July into Aug (all after the most recent tagged
release). gcc8 was already out of support or it would have
had a commit too. ( aarch64-none-elf-gcc is currently at
8.4.0 .)

The specific issue is that for compiles with -march=3Darmv8-a+crc
specified the result is as if the +crc had not been specified.
In my context:

{standard input}: Assembler messages:
{standard input}:37: Error: selected processor does not support `crc32b =
w0,w0,w4'

The description of the fixes starts with:

QUOTE
    A change to the way gas interprets the .fpu directive in =
binutils-2.34
    means that issuing .fpu will clear any features set by =
.arch_extension
    that apply to the floating point or simd units.  This unfortunately
    causes problems for more recent versions of the architecture because
    we currently emit .arch, .arch_extension and .fpu directives at
    different times and try to suppress redundant changes.
. . .
END QUOTE

So seeing the problem or not also depends on the vintage of gas
in use, possibly explaining this not having been noticed before.

This was reported separately in:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104439

for 11.2.0 and more and specifically for crc32b messages, but was
classified as a duplicate of the earlier one listed above.

As far as I can tell no tagged gcc release has the fix yet:

releases/gcc-11.2.0 (2021-Jul-27, so close: 29th commit)
releases/gcc-9.4.0  (2021-Jun-01)
releases/gcc-10.3.0 (2021-Apr-08)

This interfere with experimenting with an updated U-Boot for
aarch64.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Apr 18 19:37:20 2022
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 B2A0311E0F87
	for ; Mon, 18 Apr 2022 19:37:21 +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 4Khxz46dLsz4g3v
	for ; Mon, 18 Apr 2022 19:37:20 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 9AA4F18E9B
	for ; Mon, 18 Apr 2022 19:37:20 +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 23IJbKkU064887
	for ; Mon, 18 Apr 2022 19:37:20 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23IJbK3a064886
	for freebsd-arm@FreeBSD.org; Mon, 18 Apr 2022 19:37:20 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 262417] armv7 build fails for ARMADAXP
Date: Mon, 18 Apr 2022 19:37:20 +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 Only Me
X-Bugzilla-Who: markj@FreeBSD.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: imp@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status assigned_to cc resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650310641;
	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=UUdWPB8YF3wh3U+C4As6Fi79J2h9AYrOZVTazH5We9M=;
	b=sL1Fmt9x4/1QBTZgOogyriw91mmCY5s4cPpWl+cL1CTONbIDBRgKcqQBU0SlGsxiSvReLr
	jvcNlDc610x9NdT2ZETogMcDd3CnLJmCwLrCrqx0lT/HEHni+n9d4AkehiaX0UQBwdDn77
	XUrfr/D8Sa9/w1g44bYRdx0S1Voj9tS5ZpALIJxKNRWOYuvYg5pnDf8G38Madss9Gjxx3e
	JtPSdGLilGI3YaIDOX0CEhQNivd7r5tUsHSEc0Jk2cXACnPgCmk/ccsZsxE2BAB9K298F4
	lGX+idt8xzDdoR4ze5jJyD+rzq5Wlb+wZUYr9EtOZ6ocOViXvFOtff2rCfMjuQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650310641; a=rsa-sha256; cv=none;
	b=TsiJVJ5LNJVtrvoj9/l59JKP+wGBG5k/pLPt4Os/+fDJDNejMrmzlCTSL1QoqNR+2OrQ6r
	5YaCModTvqJOnTXviaM+gclR1TeAdBr1kilUstlF3gRtDOf2JvLSoJrLSQhbwB1bMOhEUV
	cbN8z+j2iDiqzG9OSSf1MI7002jS0XtNSD0oaX2P5oeWiv+rijiU5tg/sAPBilvMEuMLcU
	a2Id2uvaMHRXqmnOVgL45U4AC6amkh8ObM7te15sglOtqGICwk5kfR9rnMdBiZB6OnfbKv
	YognJNR1s7OmQiWj4U+9xnukRoL81voMcbwy5wph3RkzlvmarrxnJFZPAhi3aQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 650
Lines: 17

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262417

Mark Johnston  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|In Progress                 |Closed
           Assignee|freebsd-arm@FreeBSD.org     |imp@FreeBSD.org
                 CC|                            |markj@FreeBSD.org
         Resolution|---                         |FIXED

--- Comment #3 from Mark Johnston  ---
Verified that this is fixed now.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Mon Apr 18 21:10:08 2022
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 9604E11D35CF
	for ; Mon, 18 Apr 2022 21:10:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kj02S3Sttz3GpR
	for ; Mon, 18 Apr 2022 21:10:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650316216; bh=DyOIJh+H1seFbWV9CHKPvnE+ee/Z3h/Bjqh/Rq4NKDM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bfXy7s5UtCDT6IKp5g7prNJHILqu5Zm6HB49OJ0o8h9N4FpkZH5Vrlw9grlFhjc4gZD3oijBhAnspyioML3oLc5vE0m1+4KbdzP7/rzi77E63EiHcrXUyqD//gaN0kWpGpNSh6T1s3IWXODfX/Ckmgu5FNCt9WLVfGY7+A2A+ukjmxuZ0YL50RguNc629HWKl2WMUsxE841HKPapolv79By+gxHpf3NUSRlignNxJ6dO8pmBXA3ptkgXrngrlp/XMu/mMChE2d7jtne2sQ291lAIV9mF0eOErWB1R5ZJDifX3EV01BsXiEnUsDFEONmVeeEsK3keANAPSwkLyyTPrQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650316216; bh=i7eaaPUAIDhhWOYep/BY9vBsfakKxbnUfdSV5v+Ll6g=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JvxB4ddLIhNmcxDdKWPD9CzpTLixWkdg3idGY6Jb0SL4MQc+N2YgFzRevSFhjTp/NCJYbk5cC5tB0CgHqnJGBadgm/is7nQdJXA4RpviwHCiF0U88PvtB071SQ0kMrqcyIJvOY7b5NDkTdjQqZbnZsvuKllW80gbU57h0HmdLk7nQm8PcENqKhGFaM7rvcAZHx9FNG5aTnxq8QOC2sCv7HyISoOnFMPwQqCaqirKWQWWhXeVZVvm9vEcApIk8W5bW4vLC7YqY8dD8fwXFQb4GCTbvThtpVu92LEKSc2tAkgz4XDwxNGIVp63oQNpMz2kE4WFGC0W5dAgXJykPmU1DQ==
X-YMail-OSG: 4kObDDsVM1lQIQP5VoJOkGI6UHrMTBovO7U9mk7qeJPKST22uV2emR8C487.QtD
 hPSw6dwAIid1lTejISjeqbflTXG4pxP5cPDXO1scaeJ7MGbjh6ULpxBcgJRzaXEOfDqITC6LClwI
 kJUM.Uh2Tp2xCubgOjKYpOIXevMKk.dSBVgHdXv93NW_isVl6UW_wwDyR1YKA5qgXv5IHrqnyZ7F
 oOB4x.an25_9zKW1ZgWTTW7Ud6nOX3KZtyLrS_gctfMDCQklId1OYF6Lz6VTmBnsqUR8JJGp1iua
 euGRUOXZoNmLtPl3FhtZRe.xEE68Zmvulb01u_JyH9cU41TfdrPUdaUVkq1Lp5GljJegfJ2CifsW
 a3fBAESDk2sjvQWim7.5HYWQdrUKGa3LB4nx4IwRpwB1A8FRkv_PW9pnWnJzaT9yhaCnt1VvRfAL
 lCVUNqFqe4ZGCuoMXa5wK.yeLAvB.6INb04xDwTcJGL0pYzNMet.QPQXmBqN9QLSvp7.OR.sP0Gt
 JHM5Qsv144U8rCno_gXw67QTDXUx_RUi67BnmbdF1tCrecLzSuUFxkd542o_LxoGgreaohH.xLfG
 VYSYVAEYEfH_eGg05ztKDMSSmLcUivDuvq.dsvG11mFJ3_O45Zfu0_FSN4Xt3PHkysqKadd8SARm
 Pi2pveX7zAF58JPzfXiX__Nc.dJOgyKpKeTu7Cj9nJv3xM.0T2GIMZ4foS.gbjS1oNdwBd.22DbC
 LbHECzBbXRmmmDxNZ9Xbz1DqLhVuhmlsKUbJrWyl8TSh2fnppGnrvLhlY9vVYHHt4ujC91yP5Ixq
 j4tNkHeBR_itncfd0p9QBiQvl9svojadZOrUOou_hKkxTKGeo1_5QNv0tAc8XTyzFucQXA3PZapB
 4IXfpUwivNhfshAMR6JmkAkU.CFxXYFyTnT7jNj4oB.o8VpSbJF.kD4mincPmelHSEkBr0kLF.PV
 HhJ1MDPQUfEGVZmXqAvENOdhaGivnZE2sxWNzZeMohz2Zg9eQSfpBRtyPpB2BIBLhpSZMXHgkcD3
 .UQ7K0WaJgU.OSWEOt7ttSsUn4p9Rk.YGVc50L9axAfd.J.I89e1u1aZfWROY_rnB6_137IyFnRw
 eOEBKKLIEuZb5ibok8pXOK8bUH8B7qZ0LNd3z7fOnBhKLqn5uva9xraOf1ZL3FIZMFS6IWT9bh6g
 k8FtrpZwI0sohiU908dXvyE4WiNxKkkflWVDnoCip8er16V6QKui1W2.bIKsMP2YCnh2.zn9XGmi
 5.Ne0D7M09ykcBKQWj7p.lVc7ufuJ_H1QyfxRejp7OB74rvt40lVDlJGPQWcaMT4P2ZyKbHyQbqo
 bmSrYjgHqiYBINXydVTEs.0t7pVatM9XFtLRuV9isA2xCcMcFQYor8ebfAaMBAkShH4ohLEjqYlu
 DE26E_nnyCQHagpyj_DnaMd2htrGGMzyWOgqgNVFkvs5RmnYxVYeW.2E2Hky3XVIlt3_fzMiH95a
 Vq_dRzsA60eQT7HGfMKUBHK7tOQ5GMk744KtdTnm_vGXM780XIx_92kn1jmIE_9DMMJrR3gMY3JC
 KCHc7uiHMJiutYz_mnE0mlQlQIadBTX0JaRPU0lVK4ev1Zuag1oDMasomlBtC3XNrFmYG67T5v2G
 8OfuQMIzsISReRsemOuyxOZ6Um9DbTT0FxL_jz110P2JPiMnsBRY9xUUnapZQz_CUmgcGPXawU4_
 wOhm9OrGO1m6UDvk3nO6AxhIJGofp7e8JJAOOHgCOl1rxadgRSYdGi2c4pa4msG8CigmglCOGqvz
 xnju_.2qnlHf3dqdmm2.kTxJ5cUQgn1ZsW1DI59C.pNWYRs9FP3SPYXwJ3BxzfP4s5pQ2GgBGy8A
 KYSjmTIV_11dcYW_ta0iaTNbUgNKKBmejv0qiFtV64OB0e22EDrw.rxYZDyPIsXK7Ul_d16QYdWu
 PKqzPAdAfrGGEevviNsWWXmFLaIygwmCW.rZZHan3N6oTLslnyEllrt4DvZJY0nkf71Y3nnBBlU.
 vlHLNURjxj5AtxEz.V9EwGxosOiY5PaDFgl2Koy3ikUrsrR6LITnjsuEk_bSNsX8h0Zlkg2Rlfca
 P3N1aWPUgCmu2ry3H9hXfDvjxqXOz9KNR1BYoD_um2u8UMbboSdJ38Xkrp6LysPSQXvmflBe6Cx8
 vFeiXaCPZdgTLajwEJIyM8pID5Ner9wpaA2uvPF0Pal2xFs2IO8ha9MrXYZDCN5hLoGaUoSYRWIA
 JfEpwt27WFyWNROA36zQZ2yIkJwJ3NZUzqjOyNaoD0Zqek__7JzJbcPiGLXL3ixtp.FhPIjaVWLr
 b6YEA.YwcFYmg1PY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Apr 2022 21:10:16 +0000
Received: by hermes--canary-production-bf1-5f49dbcd6-vddpd (VZM Hermes SMTP Server) with ESMTPA ID 5b0fcccf35a75020e8317c4ac8e5b275;
          Mon, 18 Apr 2022 21:10:11 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: It looks like devel/aarch64-none-elf-gcc and other aarch64 */gcc*
 's suffer from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723
From: Mark Millard 
In-Reply-To: 
Date: Mon, 18 Apr 2022 14:10:08 -0700
Cc: Emmanuel Vadot ,
 toolchain@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Free BSD ,
 freebsd-ports@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kj02S3Sttz3GpR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bfXy7s5U;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 RCPT_COUNT_THREE(0.00)[4];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3397
Lines: 111

On 2022-Apr-18, at 12:36, Mark Millard  wrote:

> In doing some experiments, it looks like I've run into:
>=20
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101723
>=20
> which had fixes applied to gcc9 , gcc10, and gcc11 in very
> late 2021-July into Aug (all after the most recent tagged
> release). gcc8 was already out of support or it would have
> had a commit too. ( aarch64-none-elf-gcc is currently at
> 8.4.0 .)
>=20
> The specific issue is that for compiles with -march=3Darmv8-a+crc
> specified the result is as if the +crc had not been specified.
> In my context:
>=20
> {standard input}: Assembler messages:
> {standard input}:37: Error: selected processor does not support =
`crc32b w0,w0,w4'
>=20
> The description of the fixes starts with:
>=20
> QUOTE
>    A change to the way gas interprets the .fpu directive in =
binutils-2.34
>    means that issuing .fpu will clear any features set by =
.arch_extension
>    that apply to the floating point or simd units.  This unfortunately
>    causes problems for more recent versions of the architecture =
because
>    we currently emit .arch, .arch_extension and .fpu directives at
>    different times and try to suppress redundant changes.
> . . .
> END QUOTE
>=20
> So seeing the problem or not also depends on the vintage of gas
> in use, possibly explaining this not having been noticed before.
>=20
> This was reported separately in:
>=20
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104439
>=20
> for 11.2.0 and more and specifically for crc32b messages, but was
> classified as a duplicate of the earlier one listed above.
>=20
> As far as I can tell no tagged gcc release has the fix yet:
>=20
> releases/gcc-11.2.0 (2021-Jul-27, so close: 29th commit)
> releases/gcc-9.4.0  (2021-Jun-01)
> releases/gcc-10.3.0 (2021-Apr-08)
>=20
> This interfere with experimenting with an updated U-Boot for
> aarch64.
>=20

I looked around and found:

=
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dc1cdabe3aab817d95a8db0=
0a8b5e9f6bcdea936f

arm: reorder assembler architecture directives [PR101723]
author	Richard Earnshaw =09
Thu, 29 Jul 2021 10:00:31 +0000 (11:00 +0100)
committer	Richard Earnshaw =09
Thu, 5 Aug 2021 11:51:14 +0000 (12:51 +0100)
commit	c1cdabe3aab817d95a8db00a8b5e9f6bcdea936f
tree	2e3b5461af89619f316ecefa9d46564aa7514d33	tree
parent	6a37d0331c25f23628d4308e5a75624005c223b2	commit | diff

As well as the refs/heads/releases/gcc-* related commits . . .


=
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dc21ba5e57e49b870f16079=
44c0742e78feb7bc8d
[Wed, 18 Aug 2021 15:22:38 +0000 (16:22 +0100)]

via =
https://gcc.gnu.org/git?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/g=
cc-11


=
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D02d5a1988247207da46f25=
ce8b58515e25c1f250
[Mon, 23 Aug 2021 14:31:16 +0000 (15:31 +0100)]

via =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/=
gcc-10


=
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D04c568961e793a1d7ad862=
48b4ca929fc84acf8d
[Mon, 23 Aug 2021 14:39:20 +0000 (15:39 +0100)]

via =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/=
gcc-9


So possibly anything based on more recent snapshots than those
refs/heads/releases/gcc-* related commits have the commit in
place already.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Apr 19 02:32:06 2022
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 98565CFF6F2
	for ; Tue, 19 Apr 2022 02:32:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kj79x27c4z4mJR
	for ; Tue, 19 Apr 2022 02:32:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650335534; bh=kR1/rdjfcgegCahGsTgkvdm7h5UMg/jSSCxIkeHY7Es=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=iUjFKj7OWqIfnXCXlzdJ2od21otVwp/aH+DYoECDbobB19HzTXk3xDJaX0Ayj8VZyWF0JlzI704sl+smJIAPOTXUYDjwcYcc4XN2u6BH20BheP5PHSPIn4vrbXK4CPGrxz73WgNBcsDB4Mf+hsfQBfZimiWk6DLmnhsUbO/mM5amgkJpNtaMs8tjEfvWhh62JPCi7QBaz0ANlLLhHHo44QPhEPOh3FqN22OaaGk2fy67M7+56u0UGJL6+s54Bz5kfqVCZ/Ds+iJpMqpWZEn9zcOXx5UrmmT20OPatXusV5VsZ8DQyN2D5Ab7Zmb6udsZ2L55+FZPGh+gWjPJf9a9ag==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650335534; bh=bHL14Ktg1tjMbq6OQqGmzul2xtA0FEQFjAisqL9Moy4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hTWFww3WY7qXnbGvM9HZtsN2PBFFT1C68EYOwH7CBegif3lMU0s9TnqUIKNlW+qdRVHpozJPCA4H4of/w/KDMBjvp5zG9xz+Yv6ciq6fgFmvaO33TOjGzgizDj/gSOcmjuM56l0Abq0pYM6SI9hLyvgpCgdU2+BAXiElGhzB1lxRztkmHBE6PKd1kGi1y6eVaJ9yFIT/JaMYGkS9pj2r1IjCsAjCMF3mSzlRH+XDNry0mGAYTovpj4AOTmmCvWieKQ055pCvKo4BM/zfLRzIrSOzCXAg09XLhY6wPLcMeRZIcESKCLJ5cHrAPeh1UqjcW8ieX/8jnBuyu5zaCy33mg==
X-YMail-OSG: Xf1i2_wVM1nykHshIiNG4R8EE8FctNxefeSmPauVUeEVXFDVMbqz4Jh3beAgGAd
 aWBbpTmm0uLmtAKxaFTuEKx4_mbC0gDfBLzNiKnVTnUN2TGoC07lb4szdDZnqZA5PqGelbBMnOKU
 cjgXGV5YE1QjaDAo47YwI.23FswmjutwaITB4GieorcyjeYM18nZTfyG8bdICnRXUOdmbw3GiwJk
 kEgGpQlloQ.7ZUvlHSHYS89FxS8mlXihOE74YwFyyMK2FUNJ66dJ7_NTFb9rg.q2_kOV96LaQ8V6
 _irRPcaqjosrOsyaUCj03IxY.xppw3cEJa_BEM4TnKe98x9gf_92yBnsJ.IH6oAv5jO_kkfykqYo
 IR7O.BSagM_EnV5ttHrAgz4MVz_rFQNSjka2wrMQw5DbJxzibQpuEpbpPiiajvBKnV41Aaw88GJc
 WnS4XeEaIyEnpzalZ8e8kLzvIfc0zOWX9ycmexiy6AZvmzQk7VBW3vzXZ0yHL4_6XzSOPUUE6p5r
 w8TAx.ib2aIST6wcB7vK5nXVvVR5yrxoJz_F.WHTOIo8KBdoGSzyhYp6obX45eZJV3IUhxJqkX4T
 xcmn_3a0kjRlkkQ5AduLSZ0vxew2bzBUXg5682fwyBa4dJ2KdH7kSp0XxCCsJ0Y0CozSmcNTiViy
 XVTq0hZCQNloiLZ.JMUS18fcX5VnOlo4VsxPHtSpPDCXv5HM_ySlgjNyTk0i3FK85hB1aJ2rVgSP
 bJx8uxMRajV8nNmPr43J.ej9zJHiU42PYSqPdm1Mrt4kveE2QpQdE3Pbpa_0HhzcdH0ILANJv0nr
 B4QY7M4q2xF6kIG0.KS8M8cDfOlA8X0kMjg34cTWG9nxGpYL4LCCaX0gH888w_frih_y.hrm.EOK
 YGhrmzZ3lzs88qN7JWQp3.AzqWx.EHhCm3ZOf.3__IR1aUCz3jq5x_5CiJxvdjTYA7QBHkxPEZOE
 VyWIe69z9cX2xlS6qzIfzi_afgXqBlBR.mG5hraPDNPR0gd1HFhKb2Vz28LLgzpNX8JLHRE0HiQe
 FWK.yzadSPBmfddOTIzimiBW5qyeEAHVSUk0AlZq4F9pUK6FJmu9MBvANIw3RtsnTUTRA6VrV4SK
 IvAjet4xPS_N_.Ake0y74uxNKwl4JAncO4ufr9vZEULHeLcJ4Qb7th3rqJuhHGjLDkylTnWe7fY.
 kignsex94QekxCkpS_ckH5yC9IkiJdcDkrkk_XhrAAdR7w.5dtcuBQJNaXhmvbOX2NO4EtbQ3i3j
 InD9rNkYYmeGNcP_l9vlizcDt4Sg6VeyhcbtEBP7dyLLl1cofAjJw5CZpVir85eCvSgw6HYsZC2X
 UCZZ4fOh24Q..9xjVNCSDUnowsZ2SblMr9LQ2XBAqhVJDSPBYNjkJRDJGzAC62fm0eTzWmhEHRLL
 JJh8bDKf_vwPcSKT7wIjLzB6Ewd6_58PdqS22KB_JvdXPykP9Q3Wx2IOEdTD.egTX2HYmO6BSGBr
 CslttQoqJV1sSNC_zKLiVvSvHz5MJsstZFSYOHkK5Mt8sI.QsXccF51bbwAd1OSp6VHsEyoyjdV2
 SJs5Bg_T3i4D6qH7vxjS1kKg.QVH55GF43CwGDvY.wFpI3qYAdtuZLdi7LpIHh3BRVrdqSdbNQ.H
 fR_EPGu0cQVXuVrrAsw.pVAnFfBE_B1YMYkr6p7ZhvjWdZ_7Kh2CT1IgXarCE6isuCAhg8ULHHC6
 GpWTVSe3ZZmgEtk_ATSj.zK4QN6EIgfTq7GCbhSJUaHSohzvrb4QfzeuIVBfOYtzyeJNEiMsaq_v
 amWQ5vW3XX.S3dfABxcE_qLcTA6L0J3QC_oZ7KUmRKsJ_O_S93kwb1Vn3e5SQaR7FeBRd_.riJxJ
 1P29NsiaF_xOdm8GDDWbPJ5YfmkOESz31ErRVV3hHMblGXR6XBEpUBko3DCU7Xxt0fF9hzutZGaH
 l4PZ5Jvov6U3B46oU39MAZApPUqZ.Ih4EjyjKyti4y2CzeYVZNKVtxycEHzYANdrQ5DSwA6jdeLf
 pMAXoe.ZOtBftyih6o02BQlXARlYwU8DH5QV2uqxkI4me0_TLb24tOsrnJvzuee.vyffswxkTRFs
 zUOqI7h25a0pHRij9QB_ENxmNp2kTX8sLeVjeiFLp_Lt6fDKT4FdLrqMoT2eMSyawdV99YGpJQBh
 V65XdOTsiQz0_dFts6HsyW3W3G435jd8yS4ZwsWnDBogYFmeIsAaPWUzWORFgV.bew_yeLVr.UlO
 pu2YFLOpW_elLha4iLGiNUNd4cufvy1oexo4kvHHfDb3Oky4Cs6gEbU68IjJAVtDM4unDjNcPyDN
 nm9nj0ZMdwq5wWw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 19 Apr 2022 02:32:14 +0000
Received: by hermes--canary-production-bf1-5f49dbcd6-wg6zc (VZM Hermes SMTP Server) with ESMTPA ID 49a25c432eef9cb5f5701d49bb897370;
          Tue, 19 Apr 2022 02:32:09 +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 14.0 \(3654.120.0.1.13\))
Subject: What was sufficient to get sysutils/u-boot-tools to build a 2022.04
 vintage
Message-Id: 
Date: Mon, 18 Apr 2022 19:32:06 -0700
To: Free BSD 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4Kj79x27c4z4mJR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=iUjFKj7O;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2646
Lines: 77

I've abandoned the overall experiment that lead to building an
updated sysutils/u-boot-tools (in preparation for the experiment).
But I figured that, for future reference, I'd report what was
sufficient to allow the build:

# git -C /usr/ports diff sysutils/u-boot-tools/
diff --git a/sysutils/u-boot-tools/Makefile =
b/sysutils/u-boot-tools/Makefile
index 62ade2765607..28813f0032f2 100644
--- a/sysutils/u-boot-tools/Makefile
+++ b/sysutils/u-boot-tools/Makefile
@@ -1,7 +1,7 @@
 # Created by: Emmanuel Vadot 
=20
 PORTNAME=3D      u-boot-tools
-DISTVERSION=3D   2020.07
+DISTVERSION=3D   2022.04
 CATEGORIES=3D    sysutils
 MASTER_SITES=3D  ftp://ftp.denx.de/pub/u-boot/
 DISTNAME=3D      u-boot-${PORTVERSION}
@@ -14,6 +14,9 @@ LICENSE=3D      GPLv2
 BROKEN_SSL=3D    libressl
 BROKEN_SSL_REASON_libressl=3D    not supported by the upstream
=20
+BUILD_DEPENDS=3D gnutls>0:security/gnutls \
+               e2fsprogs-libuuid>0:misc/e2fsprogs-libuuid
+
 USES=3D          bison compiler:c11 gmake python:build ssl tar:bzip2
=20
 CONFLICTS=3D     uboot-mkimage
@@ -23,6 +26,7 @@ MAKE_ARGS=3D    ARCH=3Dsandbox \
                HOSTCC=3D"${CC}" \
                KBUILD_VERBOSE=3D1 \
                NOSTDINC_FLAGS=3D"" \
+               HOSTCFLAGS=3D"-I${LOCALBASE}/include -L${LOCALBASE}/lib"
=20
 PLIST_FILES=3D   bin/mkimage bin/mkenvimage bin/dumpimage bin/fit_info
=20
diff --git a/sysutils/u-boot-tools/distinfo =
b/sysutils/u-boot-tools/distinfo
index 7556c3f85224..edb5af20acd7 100644
--- a/sysutils/u-boot-tools/distinfo
+++ b/sysutils/u-boot-tools/distinfo
@@ -1,3 +1,3 @@
-TIMESTAMP =3D 1594115686
-SHA256 (u-boot-2020.07.tar.bz2) =3D =
c1f5bf9ee6bb6e648edbf19ce2ca9452f614b08a9f886f1a566aa42e8cf05f6a
-SIZE (u-boot-2020.07.tar.bz2) =3D 15338841
+TIMESTAMP =3D 1650330735
+SHA256 (u-boot-2022.04.tar.bz2) =3D =
68e065413926778e276ec3abd28bb32fa82abaa4a6898d570c1f48fbdb08bcd0
+SIZE (u-boot-2022.04.tar.bz2) =3D 17772787


portlint had no new messages. poudriere testport looked to
be okay with it on amd64 and aarch64. For reference:

=3D>> Checking shared library dependencies
 0x0000000000000001 NEEDED               Shared library: [libc.so.7]
 0x0000000000000001 NEEDED               Shared library: =
[libcrypto.so.111]
 0x0000000000000001 NEEDED               Shared library: [libssl.so.111]

The HOSTCFLAGS use does result in a bunch of messages:

cc: warning: argument unused during compilation: '-L/usr/local/lib' =
[-Wunused-command-line-argument]

but the -L was sometimes used.

I did not install and test the build before abandoning
the overall experiment.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Apr 20 14:28:55 2022
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 D6FE411E09AF
	for ; Wed, 20 Apr 2022 14:28:55 +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 4Kk32H3twfz3Q6t
	for ; Wed, 20 Apr 2022 14:28:55 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 5E64F15776
	for ; Wed, 20 Apr 2022 14:28:55 +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 23KESt7r074353
	for ; Wed, 20 Apr 2022 14:28:55 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23KEStBO074352
	for freebsd-arm@FreeBSD.org; Wed, 20 Apr 2022 14:28:55 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 215691] head -r310854: lldb.full gets various "relocation
 truncated to fit: R_ARM_CALL against symbol ... defined in .plt section in 
 ..." failure messages
Date: Wed, 20 Apr 2022 14:28:55 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: CURRENT
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: emaste@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: emaste@freebsd.org
X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12?
X-Bugzilla-Changed-Fields: resolution assigned_to 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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650464935;
	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=SDBmwDZv1FatXs2GEit/GnvC8dilOsQEnusswYBeTFo=;
	b=IzGo5RTz5hkgJra/hsjXAP066aJ1W9dig1ydT/IS6Vey3CVgmYBUDWQbeVlTBwVxHdAnj/
	1FWj6px15DgJ3FTUUMosV7xM9OeYnOnUW6koJs5cBGNcupeKClEKpYBSHJFxYwIEAdmsj0
	GDfDHiJ+eucfKXGTHMAfZn3Y2IagH8FvyfGjuQM9j791K/7nneMqVIVe4bWFhzCA+hvPNQ
	byeHjEa4dxKCFr+Gnpa18kih/RqQfMfmchgTjg3QJwZrYzbjqXsgX2ITKru+IN30AmVGp1
	OFbR47CoyMiEUp9duc6Xw6m80pmULw3ZYiXfKxoCZsQzvFSsEArXfclILmMg5Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650464935; a=rsa-sha256; cv=none;
	b=aACBJarBv0UemnD+G4nNc8UYYH5jfpZM63wCj+brXstDVAaIf0g0NQ4urX7iXbGoKo6AHY
	SzafBBcyjumyAR/2utaqAerVnYXjvDbW+LLtp4dOcOQfaonlpx4qRYwBweC8QBbb9dOcn5
	PD39JEwU2SNDViyXYPjfCNgQk7mKnzdaYwtviX2lpcXzFGpCiBvqU6NJBOngBJ2pL1F9LM
	O40OKGfxSb3rfD/1PZ2relWK6VvxS2x0sKJiplWQdTUikxhvkapgjWnR6Hb/f3F3v84gBv
	3jQU4la3ouV9+K4vFuSF056Xe65xsBIzoHvdbASaziVkM4JZHVoXAFOJi3WpxA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 490
Lines: 13

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215691

Ed Maste  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           Assignee|freebsd-arm@FreeBSD.org     |emaste@freebsd.org
             Status|Open                        |Closed

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Apr 22 01:31:43 2022
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 963671A2237F
	for ; Fri, 22 Apr 2022 01:31:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kkxhr2X12z3C2m
	for ; Fri, 22 Apr 2022 01:31:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650591109; bh=9l0BEwE7xv/d5IXDHtaOF9+M9OYiBBcQXdZByO/rDO4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=t/fzfI9opeG6WeQ3YVBd/3BiygAafPb4M/gKfzFcglO4YZknolIRPq5g4NtesTQymh1J6QNGZSbcUAzzjQd0FlLCPPp9OLbxZibROOuwYfS0DRvHaOOdSAgEY78Y3bV4LcedQdxHbfs18+3CAD8HQk7cfEbPmsnb5x8qV+MqRSOInrYJN0LWZHMXe9qJKhr+LTIBgddubOKzIO/1sHkQcH/vhSnqPiVwg/SS+WuSaCDqjMRc5uvnnMj0Plr7T8RnB/HLkm9jAwxns6ojWkmnS3mVNifG6N7Zd61wVvgKO9HIQNyQxJvwqAwhd+a4UiW8ZQjE+vqMi1hofMDBtDUQhg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650591109; bh=MVRw/DBaCXh1q0PWaNacy1sCKPfJ/qZZcAoMiYxg3hN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gIARzFovqss0R+fxtqhrA6CO1HHKTW8KufTZAJf2qnPoH0tyt7RzR5jy0Edcs8Cx9FxwIbKeBmDVeTI3J/dn+YRSTCk7WYXAQaI00sf3dPHSfdK+iJhVyO/0JZ1pArkG3EKHsJgVI6QgbyY8s+RGc0IPDfZKxK6720bSwIkJQdO807bQt/Um6Erz70wqqxrLEkMl713Y8SDiDu3jDxUuG45fIn4HObWhDsX9sGrjVhiLPtvMlE7www0dnnoa+mNNTZFni+ZwKz/BZNy8nWsHTuv6+SxAcX2EIuSiUFWrI7KPwN8Ro0ZJuseK5GcnHje5UrZUQHz4weA4CpNAKNeaYw==
X-YMail-OSG: JK_F2T4VM1lt8PeWn04s1xg9gXva2Hta0iLCnFo3bflvNLmzn555BvAuRNYu55Z
 4c9VpyKKUbpPTJyqrPTI28cbBgXUb24VUw2R.3_dMebA94M9EVF7Ugo7RlT0UVvvP4SS3uk0GGNt
 rCf6IuMczwq98uLCZH34r8OrfVDVpId7N17eW901.GKZVuStC8Oboa5k2hSDaig2VITqz0cAF11W
 IKo_4YIwj2h8KZmNjFirxdKo0V9rp8UAMCuTmqp2U.Qf.73yQRSsMexR_HeXz4S.zaJZeKJ_mfSR
 1lfjJfwFHG1ZteRVlx2LN_DSlC8aQukf7ESMIHdbqHBqKisV5r1_1AyFqj56XaO6HJhfHuPXNL21
 0zSme5_YG1CNK_Cz7NV5pvHHNfzlXgspFKLnO0M0HGxREHhDCXrnYbqELSs7A_qqOAeMSkponz6w
 6Nzm.VEPk0DdyvyLkqdxnlGNQzL71BScb5Fs6sxO2Hc.ijGzUffdgc5CQGR2KSzs4G.v7QzyJlL8
 cJ9ZNeQZgQPNCEkFOSzRmvKb0SZjl_uyEpWF9NLjWHzJNyxwzAjqBPTVKpffk9AsfN4KC7OQY64C
 Z4QtiiWLcjWJ3gMxvYLKYwJRg9_4pdj94AbG.DG5BOlpQAvjMUVoPePiH9tHLAHu2fUllTkMVeGA
 BVekgGh3fzXihiIJXY2LWf619ZVGYG9Vx6Cw8q6DCWe6.quzKwkhOlQ4LKvrlp1tL47ajLO9DkMb
 O624HsoRZ5lhMxEh9z6wv1todlXnlrqUBDsfjoRMxrWeUN62kCJLsQiHvGYZjiWDpRSgw2.z3yjf
 PwQfIKVOMH_uDHGrllfaPSBQns5ARdtl1a6gXxefvVIplgik0LVcA7YPkQgbD2U6pppTDlW7YTjJ
 B0WLvU4x5yZoK5qIoQ.ziEFbZjyUCUYpdFnCVh4v3XjbMK8YhryYyvHRw6PulzvJGIDc1I1uaI7C
 ADAICoqwWONhedMuq24ry4act5xbpLjCHRmIJalMuTKifWCc6rUsIbb8xZm3dr1uQQgM6a0XckEr
 42pMcRzDSkp.R1JXXI.LlgWWwueFTdE5XfIk2gxw_v3APm4dvTPSX2IY.Sctn8fjeOWxekqxmHM7
 xu7Tr68gRqIC.1pUxlIhKfgWe6e0ZdqmvzFk8YLdvbQkTj6GJJUPsfT4bShS39pzP8Snr8m5i8St
 IbD.99V5Oc9bLVwv8PoV8mHtitFROnuP8cB4QvA8UqpxJolB8ajA_S9hUVL_Z8zH_iZ3FEvAheNM
 U0R4iFmKR8bHpUPgJr..4V.h5LeV5XKHIM02D5urudAOM1MPbd_UbcVBZDbnkhhDFb8zCFIXJo38
 lHYV_Trc34pnwKua_6pnZUQOji9PRDiULNdbj60kEM7CxVLr9OhcePmc14FV_LtMdP_JN_vRAaQz
 lyFs4FQknnubBLi8tZkIw7NmQ555H5Ti8a6UK0GFBWS6HWxYp1CoqcKyJVwiELs6R.PegOyMXIpr
 x8ITJEKLoSVY2nmjotEcbYvU81ZP_4O.o6dltqtWDFsVuvpftI0DbjsJc8COjSfkqpbgD7k3Cexi
 TEfuXHvPJUXapuPO8yR0zQvghD32pZdauVU6QjH.B4BCMqGoHPRlSghXEuNUYNOf8Jag.CcBl6oB
 0RoDOB_CXea0IZlGihC9N0q4TxJYVaI7fp1ZmONyF8XjPTCdRVG9icLeOh7eJxAlwDZFizdimE07
 .gX8MS3Wp7smgh2qGzrhLJUnJGV99KqAjZu3gl79AHWN2Sc_A3AC7uJfRm0PgiGtVZ99jgvS56J5
 NX5CrLnfDzfdAo7vuAGIcTBY7K.ZI0jVZs15YJEeWBFPax2oP3UvlTE16Ze490CvlFDt3BnLL1BQ
 IDqSBkBW2sFAG0psqmrGnk4eQ.NIvrndQ.qfHxk8LMIxOPqmxdCTdPGE6sW3jrRR2hIgD6wILFe8
 ALW3ByqZZDCLPyx6Bx4ohJQc0lAh9I65xeL1_klNZGtWyTe52k47JoZATs6JKEgWaENz4KYpo3oD
 M4mj4YbGxSDE.lYi6uJAjbi0RgwKYiUhaRpzrwNxLE9v9quoCUIHgOGsm0ueBU0D3PmLkSZ.OEBP
 cPnS8dgp9F8HvRAFxqk6xxiJa50.BDIx6opZ9q4Sjyw.8ib3ofOucvYQkybNP7wZuNUBzK86bS1k
 12ce2I4VmN72R8WcZjVp5svx.F8nhubYLbV5myet7pEQW80eSxqwfbrAjLoZuDL5LyYyel_nce.o
 pp7LHyHv6pfTXh1wVn8VJqH8LAGrGR91PQg7GRxIReix.ezD_Dhueyp3tZF6skglWrAPlPHf5K_G
 .7fgPVBXn.8uLlw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Apr 2022 01:31:49 +0000
Received: by hermes--canary-production-bf1-7cfdddd556-ggldj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ed026f833997d4fedfb7c2e36251e951;
          Fri, 22 Apr 2022 01:31:46 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: It looks like devel/aarch64-none-elf-gcc and other aarch64 */gcc*
 's suffer from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723
From: Mark Millard 
In-Reply-To: 
Date: Thu, 21 Apr 2022 18:31:43 -0700
Cc: Emmanuel Vadot ,
 toolchain@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F6C9A98-21DC-4AA4-9DDC-CAB0E0154E59@yahoo.com>
References: 
 
To: Free BSD ,
 freebsd-ports@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kkxhr2X12z3C2m
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="t/fzfI9o";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.36 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 NEURAL_SPAM_SHORT(0.14)[0.137];
	 RCPT_COUNT_THREE(0.00)[4];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4179
Lines: 133

On 2022-Apr-18, at 14:10, Mark Millard  wrote:

> On 2022-Apr-18, at 12:36, Mark Millard  wrote:
>=20
>> In doing some experiments, it looks like I've run into:
>>=20
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101723
>>=20
>> which had fixes applied to gcc9 , gcc10, and gcc11 in very
>> late 2021-July into Aug (all after the most recent tagged
>> release). gcc8 was already out of support or it would have
>> had a commit too. ( aarch64-none-elf-gcc is currently at
>> 8.4.0 .)
>>=20
>> The specific issue is that for compiles with -march=3Darmv8-a+crc
>> specified the result is as if the +crc had not been specified.
>> In my context:
>>=20
>> {standard input}: Assembler messages:
>> {standard input}:37: Error: selected processor does not support =
`crc32b w0,w0,w4'
>>=20
>> The description of the fixes starts with:
>>=20
>> QUOTE
>>   A change to the way gas interprets the .fpu directive in =
binutils-2.34
>>   means that issuing .fpu will clear any features set by =
.arch_extension
>>   that apply to the floating point or simd units.  This unfortunately
>>   causes problems for more recent versions of the architecture =
because
>>   we currently emit .arch, .arch_extension and .fpu directives at
>>   different times and try to suppress redundant changes.
>> . . .
>> END QUOTE
>>=20
>> So seeing the problem or not also depends on the vintage of gas
>> in use, possibly explaining this not having been noticed before.
>>=20
>> This was reported separately in:
>>=20
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104439
>>=20
>> for 11.2.0 and more and specifically for crc32b messages, but was
>> classified as a duplicate of the earlier one listed above.
>>=20
>> As far as I can tell no tagged gcc release has the fix yet:
>>=20
>> releases/gcc-11.2.0 (2021-Jul-27, so close: 29th commit)
>> releases/gcc-9.4.0  (2021-Jun-01)
>> releases/gcc-10.3.0 (2021-Apr-08)
>>=20
>> This interfere with experimenting with an updated U-Boot for
>> aarch64.
>>=20
>=20
> I looked around and found:
>=20
> =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dc1cdabe3aab817d95a8db0=
0a8b5e9f6bcdea936f
>=20
> arm: reorder assembler architecture directives [PR101723]
> author	Richard Earnshaw =09
> Thu, 29 Jul 2021 10:00:31 +0000 (11:00 +0100)
> committer	Richard Earnshaw =09
> Thu, 5 Aug 2021 11:51:14 +0000 (12:51 +0100)
> commit	c1cdabe3aab817d95a8db00a8b5e9f6bcdea936f
> tree	2e3b5461af89619f316ecefa9d46564aa7514d33	tree
> parent	6a37d0331c25f23628d4308e5a75624005c223b2	commit | =
diff
>=20
> As well as the refs/heads/releases/gcc-* related commits . . .
>=20
>=20
> =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dc21ba5e57e49b870f16079=
44c0742e78feb7bc8d
> [Wed, 18 Aug 2021 15:22:38 +0000 (16:22 +0100)]
>=20
> via =
https://gcc.gnu.org/git?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/g=
cc-11
>=20
>=20
> =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D02d5a1988247207da46f25=
ce8b58515e25c1f250
> [Mon, 23 Aug 2021 14:31:16 +0000 (15:31 +0100)]
>=20
> via =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/=
gcc-10
>=20
>=20
> =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D04c568961e793a1d7ad862=
48b4ca929fc84acf8d
> [Mon, 23 Aug 2021 14:39:20 +0000 (15:39 +0100)]
>=20
> via =
https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dshortlog;h=3Drefs/heads/releases/=
gcc-9
>=20
>=20
> So possibly anything based on more recent snapshots than those
> refs/heads/releases/gcc-* related commits have the commit in
> place already.
>=20

I looked and gcc 11.3.0 has source code from the fix. So, for
lang/gcc* (non -devel),

git: 06b81ba6804c - main - lang/gcc11: upgrade to 11.3.0 Piotr Kubaj

looks to bee the first (and so-far only) lang/gcc* (non -devel)
to contain the fix. The content of the other versions predate
the fix (so far).

A simple bugzilla search of what had been fixed in 11.3 did not list
PR 101723 but looking at the likes of

=
https://github.com/gcc-mirror/gcc/blob/releases/gcc-11.3.0/gcc/config/arm/=
arm.c

showed a history entry for the fix and code from the fix.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Apr 22 21:39:23 2022
X-Original-To: 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 77AFE1A88CEF
	for ; Fri, 22 Apr 2022 21:39:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KlSVG24Pgz4V2V
	for ; Fri, 22 Apr 2022 21:39:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650663567; bh=9MXJ+2TRBMYcpX4EDs+IaXjutI/QrHq2NVjJELQbxTk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=E/10eYByVBUtcksMP+pFC2Nyom1ivuU/xIo5h7YRCLdcH91N/tQmCkad+kCe5W+By/6pA4jTY1nqr0niERhn6w0NK1vBsksx8ApIwbpv5dCfWEnK+UHvIa/PrX0StQHxP3YSmCFvnKGoSS+/Ls5FiIb5OpP8n50YP386/sHdV/5lL8mdbckemTFXeIfyVI75Mzu/PvgpGGKwCxjuA/pIgrGaobALptrMhsAT6NBAAOjBfnuTF0c+lPYVtID4eYTTC/K5laMuEegFJJQMeIQdSHzXH+dfG7BaE6i94nI91Rm5uYvmugn3vODeU/wR99mA2sqLmA7i64XtIFke0wS1rw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650663567; bh=W05q5aQ7JbmSmy3/2sMgu60JYWuU+xNS+nXrPAJUdl8=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=H0nHEKd/EwUcn5xI0FAH9vX4ckKREDkyoVSaKErfL9X5I9ij4HawXwEycwhTCy2K7flXmdk+vWfES92Ck/79S+NutS2LcIHaEB06odHkeqgmg7Z0MCm7Lkp4Tx8eHC7CLiFh0jKNY+QnZlzGdzL8c6BZPfJzXPNc6OxY/znROHLqU/Vz5VkSEHRpOH0kO+OkiUjZllsT7DerHWh9lp9b64cdI4jhV1TQ2c0EUU++pZQ33U/MOyfW9zpcWb+D1+0UnPGyE1JiBDqfMx5jzjiBPB24ZRlKBHajCRVrMkOXCsVzIsCXHny2gXzeeQ8wMIjahy/J96+GUT4EH02O2xqbaA==
X-YMail-OSG: 8MQjFZMVM1nzDnxU86PjUpWq02ER5R8GhCNeC_SO_ebitItaCgMx.K0B0TuKqHi
 VKuZbTcDsMLeHLVoI4sO.zS6ytFhFVFBFCU.eYPmyiyeONj2CWT8PyebHTw5lS4zeQWSL.SNKx2y
 LDd8qVyt1sAXgE166zUq0rJ_Z2yhRJXF12U3G_wHUL14kuSPjTzQJPk7CBeq1DMeBEQ1YKJ6Tk6V
 1Bss_SRFCP2cs4RTZeg5x0XVpJycIeFOc5mjrk.EGPMcPI0TWXMSYrVu8v7vZfqWPZJmWADEfLX.
 X3j2ULccl.pyATWMHOWvkTl27J1X4RPK7oIHmqWyBENYIEpF3tw5lXhMnAW9_GnJTz6pdppi4P0R
 _I00wAQd68qInBBZbJqRwEFldgozNUMU.yB7mx5tKqVAavamiOh7.9Gjvq7c6Qdg_FcTHZC4MM6I
 EvLwLRldwkz996Ua61CjPiMJQxs5WMJ8ui95EDPu1dYHFmetMX5QYF4zdXSrCj4SSMWBi4BTm7O0
 sIZWu.xwhrilAXJuJoJSKuFI9Vy6S2Iv5VAPvwKz5sca.JaC4cQ2A0m2SCjWIWCK7SDmfYDYGigk
 QO3cCROpLCztzRq_4jw8fnwxM.r1n3nIB2x.tuqZJoHU130S.AkvzWQ4aGmF9rn34i_DlZscV6Al
 rlrSDT.YOnXZxK2Lu176Zgi74NV5q1HsxVadcQNEx5JuT4No5VNhQUPCFAH7rTMFT4XAsxATGMbt
 VfngTJWvXi.jkmGxGyXL4_qLiH3EmliMJ.xGCUXm1fLSa1JIbhk1zX_fDqtFYfXAN9._I7itlcwD
 hhe_6nBPQNvcw7e9BkqEF.EE3yYNY87R_2xCsrohqsBuUYK8x8HdTq4DhACc1TjEEwvckwLi5ccA
 yZctzKN5e66LZuhKw_D6QbkcxWfcvYq8k.99VLggzohLryCGijKucvjrlBdUQQMNMJSXl1sN2ayv
 l5S117umTcAdwhcHeDK8nm2EagekpaqYs96RDt5aVJnSFDWNVFB6bY1WlrysJ22S2uBxkRBWdnqo
 xAnnPfWPxpk1GjkWCD2nSD9.z4fXx0KcQn1GZVHznq5_77k0ijQFd2GXjV8cv6OWo4cmonASr_PT
 _vfY_C2RPXaWLMabK8QV9DCzzst7Uz.vf3smBf2xnMH36D320rGEAuteeT3GIgBeGpiCyPC4WDAU
 rNqGA96wj1WU5sou02IblDuJYFuhAv5OsSoPHtZGnIr6OdzvdC7i.Cz596Nkjgih5nHm1jGBU.qH
 ecJgF7zZixkChmEYP7nHkdwV41yAGXuXVWZLCG1jmztA7mEhcd0eIqV0hthSQsU1JkGJv7BbsDL8
 9X2.N2sv6aQMELp_Bw23KF4bHXWtFZcz_xVGqthi0dRL4A60NfVZM3gCXkHLyi_ilHjHLJ1vBpmW
 ajDSZEzPx1ml6V2e4Rkbu0E2qqxFMfhAc.lUG.VMq12YsNpiiVFDmHUdogrq8WvfeK_BgneLNMcx
 pLMbv0smzkMgJG_0UbxnMel7B9tVwOJ1M3G3GahH9pP90Gz9Z9HqSH71iZ.ZQT1tGm4eo743W3HG
 8NDnS_bEG8H5tHasN_u4HI4tDH4d1WUu3qjujAjBfMvzJ3kZZjOGphefBzj47P4rKI3D8d3OX0i2
 8YDNMdqIDPFIirnFoSId0U2ZbTxJF61_Xm7lT3OamuEUtUuuiaq3zx2gFjVrErXHZwPXM.8YK5xt
 KVHJ7O5cORQcyeLFfqBcyiInByZHX3ymonxk.47qgnclhE8YvOg1XvupP4qiDcszj.lfDq2A_h4C
 LFpFVoX94D9.LhQY_gREGB.KwEHywhv4TTb73fGSl.Sd7OMC6KmS6estnlAoCoE9HvREu4FuQzbC
 s8xhfEzgJDElWdkwKffWckytYjuZitHJftRd0MLPeQyZDBApiuF0v8JPziMMokzuR6ush3FJnoTV
 E82nUEmxxtN5pvi7zcBsvq1hxvTgvlcOT9sLsuMokX2iy64.Ci.etW6qF7t2JDQCuGwBoCjvDems
 FwqX_5XcxMKP08JoivD0F40Qq.GiXfA.3GvhY_gW2vbwjTDjlmg_uCfVUCWu1ZOrjPOlbaAOIGgi
 f8K2MarNp2XJpyLEplaULao.Gt.Wt15pYVIIu_upxUArb.aERn34t7lERJnKR6UWJwARGJuatlEE
 FH43s.VoC_wwqVL9ghFSuLfjdFTWtBBp.ezHqp7ftt4myvLNzzzkxbZFUZVNAEGFYL.rtwV55rap
 FJ1SleqzrndHHpTvE3xZ.kmRCAu8kArvjRfFCznnx4_DHHL8_UIe0swhbWOG_Mv_nLEazXrqj3XK
 yONkKJmBNLW8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Apr 2022 21:39:27 +0000
Received: by hermes--canary-production-ne1-6855c48695-pbbz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 409d0210c3f85e0160e31255cce1f7f0;
          Fri, 22 Apr 2022 21:39:25 +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 14.0 \(3654.120.0.1.13\))
Subject: devel/aarch64-none-elf-gcc and devel/arm-none-eabi-gcc
 include-fixed/... handling ?
Message-Id: <5E569F0E-2B53-420F-B326-0EB4CA400CBC@yahoo.com>
Date: Fri, 22 Apr 2022 14:39:23 -0700
To: Emmanuel Vadot ,
 FreeBSD Toolchain ,
 "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <5E569F0E-2B53-420F-B326-0EB4CA400CBC.ref@yahoo.com>
X-Rspamd-Queue-Id: 4KlSVG24Pgz4V2V
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="E/10eYBy";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.33 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.84)[-0.839];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_LONG(0.01)[0.005];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1104
Lines: 36

"-" prefixed line below is as in:

/usr/ports/devel/aarch64-none-elf-gcc/Makefile

in its "post-install:" target code.

"+" prefixed below is what I expect is required to actually
have the ${RM} remove the include-fixed/... :

-       ${RM} -r =
${STAGEDIR}/usr/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed
+       ${RM} -r =
${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed

So I expect that currently devel/aarch64-none-elf-gcc and
devel/arm-none-eabi-gcc include the include-fixed/...
material and all testing and usage has been on that basis.

Question: Which alternative below is the intent?

A) delete the ${RM} . . ./include-fixed line from the Makefile
   and have the files present and used

B) fix the ${RM} . . ./include-fixed line from the Makefile
   and do not have the files present (so, unused)

C) Did I mess up the interpretation somehow? (Might the path
   be gcc vintage specific for some reason?)

(I've not done a general inspection of devel/*gcc so more
than I've referenced might have similar questions.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 23 05:01:30 2022
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 10AC41A8B9B7
	for ; Sat, 23 Apr 2022 05:01:49 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b])
	(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 4KlfJW667yz4lrT
	for ; Sat, 23 Apr 2022 05:01:47 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-qv1-xf2b.google.com with SMTP id b17so7585272qvf.12
        for ; Fri, 22 Apr 2022 22:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=2vqlfkjrFOxEw7j2406woFJwPH6blh2kgf5ZzSvlZhw=;
        b=F0bh8UuNwO7dMYCII/JhX6WzFXDxOzzCMc1rccdV0oYyH6osmcUN6ZKvyUs5OReTOx
         WzUv7jnPA0RZH8mVCBu5QeQ3VoVS45LdHBwpXdXstyV4Z7Vih3/QfXMlHkUniRmc9TId
         qbhey/NLDRr2aLxSe4/u/m23NDWL9BNhk/pSpq9EQrZwcKAtSGyibBPZdmtQzwazlBLG
         nz4ZR9+31nhYigSXa7aOKnk/ybK44991qPiAfJXdlZej+7oZNstcSCzw1xiOMrc2YPuS
         1LMomxRfT0gsq+O00v10mjxkCBIp6C4j32ukxZNJCy0P715CDs8w8XHfgFUe9kiDKWyL
         HjGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=2vqlfkjrFOxEw7j2406woFJwPH6blh2kgf5ZzSvlZhw=;
        b=Winu2n0jfwYxyphsA4kGXCDe8VX/RhDbOpdIpDl/dTW3z1GsVWhNQ7RpIZESnqWOYN
         8ZoU6iD+mgIV3i00avdlLo2LvJj8lBusvYABtAyvMpYxXqbOyHBu53z92AgZfi5d42Jh
         zbVuyA164Q1ZFOWHy8t6SaWUHEEWOZ55KvKvJLnbAjH0+5rxTqtW2bMxosJ+te3q9fC1
         6iBng3OJGhYV9Tc3F431s3U/Hfvzsw8mZS7Bd2tVOwaS+rDGm7MTDlBl3CWpngKlJBYQ
         9+hi1nCLZ883ZtyO5a4zm7UXbPZqjW68rLyH1K//lC9y/22tRbSYA9KM++Fj+RYEx/NO
         xtDA==
X-Gm-Message-State: AOAM533SCWPjc3QbZWQ8+wLPwXp8vy0INZjaJnUajLEF2FdBhPNK1HNn
	l/ZJWnpZzfFY/ezcMZgTI9lebky64drQ4LEUYPyn9F6EnbeuEA==
X-Google-Smtp-Source: ABdhPJzTt4cr3+HT+gTF+lPWBneSVrr5xQZdHMRsarA49rOVnGZ4xMipTK+oOybh6Kr9j7QMM7BxVK3h6JrNsRSS7r8=
X-Received: by 2002:a05:6214:501b:b0:446:480f:17f9 with SMTP id
 jo27-20020a056214501b00b00446480f17f9mr5904587qvb.111.1650690100989; Fri, 22
 Apr 2022 22:01:40 -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: 
 <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> 
 <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> 
 <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> 
  
  
 
  
 <534edcd2-c6ef-729d-0768-9f469958e16a@selasky.org> 
 <0b3e82fe-b45f-67f0-3009-90e887c14159@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sat, 23 Apr 2022 13:01:30 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000001a922305dd4b3d40"
X-Rspamd-Queue-Id: 4KlfJW667yz4lrT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=F0bh8UuN;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.96 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.96)[-0.964];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2b:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 13019
Lines: 305

--0000000000001a922305dd4b3d40
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 2, 2022 at 9:10 AM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sat, Apr 2, 2022 at 8:30 AM Hans Petter Selasky 
> wrote:
>
>> On 4/2/22 00:56, Archimedes Gaviola wrote:
>> > On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky 
>> wrote:
>> >
>> >> On 3/31/22 15:52, Archimedes Gaviola wrote:
>> >>> Are you pertaining to this code Hans, the one you've shared to me
>> >>> previously?
>> >>>
>> >>> +       /* Epson printer */
>> >>> +       {USB_VPI(USB_VENDOR_EPSON, USB_PRODUCT_EPSON_TMU220B, 0)},
>> >>
>> >> Yes, but you can also add the IFACE_XXX ones with "," simply.
>> >>
>> >
>> > Hi Hans,
>> >
>> > Here's what I have come-up with based on my understanding from your
>> > suggestion. I took a look as well from other USB devices' sources. This
>> > compiles without any problems, still able to detect my printers and
>> > printing still works well. Let me know if this is correct or needs
>> further
>> > changes.
>> >
>> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig
>> > /usr/src/sys/dev/usb/serial/ulpt.c
>> > --- /usr/src/sys/dev/usb/serial/ulpt.c.orig     2022-03-21
>> > 19:44:29.178010000 +0800
>> > +++ /usr/src/sys/dev/usb/serial/ulpt.c  2022-04-02 14:27:54.073592000
>> +0800
>> > @@ -499,6 +499,13 @@
>> >          {USB_IFACE_CLASS(UICLASS_PRINTER),
>> >           USB_IFACE_SUBCLASS(UISUBCLASS_PRINTER),
>> >           USB_IFACE_PROTOCOL(UIPROTO_PRINTER_1284)},
>> > +
>> > +       /* Epson printer */
>> > +       {USB_VENDOR(USB_VENDOR_EPSON),
>> > +        USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
>> > +        USB_IFACE_CLASS(UICLASS_VENDOR),
>> > +        USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
>> > +        USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},
>> >   };
>> >
>> >   static int
>> > @@ -555,9 +562,11 @@
>> >                                  break;
>> >                          } else {
>> >                                  alt_index++;
>> > -                               if ((id->bInterfaceClass ==
>> > UICLASS_PRINTER) &&
>> > -                                   (id->bInterfaceSubClass ==
>> > UISUBCLASS_PRINTER) &&
>> > -                                   (id->bInterfaceProtocol ==
>> > UIPROTO_PRINTER_BI)) {
>> > +                               if ((id->bInterfaceClass ==
>> UICLASS_PRINTER
>> > ||
>> > +                                   id->bInterfaceClass ==
>> UICLASS_VENDOR)
>> > &&
>> > +                                   (id->bInterfaceSubClass ==
>> > UISUBCLASS_PRINTER ||
>> > +                                   id->bInterfaceClass ==
>> > UISUBCLASS_VENDOR) &&
>> > +                                   (id->bInterfaceProtocol ==
>> > UIPROTO_PRINTER_BI)) {
>> >                                          goto found;
>> >                                  }
>> >                          }
>> >
>> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig
>> > /usr/src/sys/dev/usb/usbdevs
>> > --- /usr/src/sys/dev/usb/usbdevs.orig   2022-03-21 19:42:20.999397000
>> +0800
>> > +++ /usr/src/sys/dev/usb/usbdevs        2022-04-01 01:21:31.361567000
>> +0800
>> > @@ -1941,6 +1941,7 @@
>> >   product EPSON 2480             0x0121  Perfection 2480 scanner
>> >   product EPSON 3590             0x0122  Perfection 3590 scanner
>> >   product EPSON 4990             0x012a  Perfection 4990 Photo scanner
>> > +product EPSON TMU220B          0x0202  TM-U220B
>> >   product EPSON CRESSI_EDY       0x0521  Cressi Edy diving computer
>> >   product EPSON N2ITION3         0x0522  Zeagle N2iTion3 diving computer
>> >   product EPSON STYLUS_875DC     0x0601  Stylus Photo 875DC Card Reader
>> >
>> > freebsd@generic:~ % dmesg
>> > ...
>> > ugen1.5:  at usbus1
>> > ugen1.6:  at usbus1
>> > ulpt0 on uhub1
>> > ulpt0:  on
>> usbus1
>> > ulpt0: using bi-directional mode
>> > ulpt1 on uhub1
>> > ulpt1: > 6>
>> > on usbus1
>> > ulpt1: using bi-directional mode
>> > ulpt1: offline
>> >
>>
>> Here you go:
>>
>> https://cgit.freebsd.org/src/commit/?id=88162f7abd61206c98432f2c0de869a59be13854
>>
>> Happy printing :-)
>>
>
> Hans, thank you so much for the help and guidance! :-)
>

Hi Hans,

Confirmed this is now available in the
https://download.freebsd.org/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220421-b91a48693a5-254961.img.xz
and printing is working well. Once again, thanks a lot!

Regards,
Archimedes

--0000000000001a922305dd4b3d40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Apr 2, 2022 at 9:1=
0 AM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

On Sat, =
Apr 2, 2022 at 8:30 AM Hans Petter Selasky <hps@selasky.org> wrote:
On 4/2/22 00:56, Archimedes Gaviola=
 wrote:

> On Fri, Apr 1, 2022 at 12:01 AM Hans Petter Selasky <hps@selasky.org> wrote:

> 

>> On 3/31/22 15:52, Archimedes Gaviola wrote:

>>> Are you pertaining to this code Hans, the one you've share=
d to me

>>> previously?

>>>

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VPI(USB_VENDOR_EPSON, USB_PRO=
DUCT_EPSON_TMU220B, 0)},

>>

>> Yes, but you can also add the IFACE_XXX ones with "," si=
mply.

>>

> 

> Hi Hans,

> 

> Here's what I have come-up with based on my understanding from you=
r

> suggestion. I took a look as well from other USB devices' sources.=
 This

> compiles without any problems, still able to detect my printers and
> printing still works well. Let me know if this is correct or needs fur=
ther

> changes.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/serial/ulpt.c.orig<=
br>
> /usr/src/sys/dev/usb/serial/ulpt.c

> --- /usr/src/sys/dev/usb/serial/ulpt.c.orig=C2=A0 =C2=A0 =C2=A02022-03=
-21

> 19:44:29.178010000 +0800

> +++ /usr/src/sys/dev/usb/serial/ulpt.c=C2=A0 2022-04-02 14:27:54.07359=
2000 +0800

> @@ -499,6 +499,13 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {USB_IFACE_CLASS(UICLASS_PRINTER),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_SUBCLASS(UISUBCLASS_=
PRINTER),

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB_IFACE_PROTOCOL(UIPROTO_PRI=
NTER_1284)},

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0/* Epson printer */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0{USB_VENDOR(USB_VENDOR_EPSON),

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_PRODUCT(USB_PRODUCT_EPSON_TMU220B),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_CLASS(UICLASS_VENDOR),

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_SUBCLASS(UISUBCLASS_VENDOR),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 USB_IFACE_PROTOCOL(UIPROTO_PRINTER_BI)},<=
br>
>=C2=A0 =C2=A0};

> 

>=C2=A0 =C2=A0static int

> @@ -555,9 +562,11 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 } else {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((id->bInterfaceClass =3D=
=3D

> UICLASS_PRINTER) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceS=
ubClass =3D=3D

> UISUBCLASS_PRINTER) &&

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceP=
rotocol =3D=3D

> UIPROTO_PRINTER_BI)) {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((id->bInterfaceClass =3D=
=3D UICLASS_PRINTER

> ||

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->bInterfaceCl=
ass =3D=3D UICLASS_VENDOR)

> &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceS=
ubClass =3D=3D

> UISUBCLASS_PRINTER ||

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id->bInterfaceCl=
ass =3D=3D

> UISUBCLASS_VENDOR) &&

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(id->bInterfaceP=
rotocol =3D=3D

> UIPROTO_PRINTER_BI)) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 goto found;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usbdevs.orig

> /usr/src/sys/dev/usb/usbdevs

> --- /usr/src/sys/dev/usb/usbdevs.orig=C2=A0 =C2=A02022-03-21 19:42:20.=
999397000 +0800

> +++ /usr/src/sys/dev/usb/usbdevs=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-04-01=
 01:21:31.361567000 +0800

> @@ -1941,6 +1941,7 @@

>=C2=A0 =C2=A0product EPSON 2480=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x0121=C2=A0 Perfection 2480 scanner

>=C2=A0 =C2=A0product EPSON 3590=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x0122=C2=A0 Perfection 3590 scanner

>=C2=A0 =C2=A0product EPSON 4990=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A00x012a=C2=A0 Perfection 4990 Photo scanner

> +product EPSON TMU220B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0202=C2=A0 =
TM-U220B

>=C2=A0 =C2=A0product EPSON CRESSI_EDY=C2=A0 =C2=A0 =C2=A0 =C2=A00x0521=
=C2=A0 Cressi Edy diving computer

>=C2=A0 =C2=A0product EPSON N2ITION3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x=
0522=C2=A0 Zeagle N2iTion3 diving computer

>=C2=A0 =C2=A0product EPSON STYLUS_875DC=C2=A0 =C2=A0 =C2=A00x0601=C2=A0=
 Stylus Photo 875DC Card Reader

> 

> freebsd@generic:~ % dmesg

> ...

> ugen1.5: <EPSON EPSON UB-U03II> at usbus1

> ugen1.6: <Printer-58 USB Printing Support> at usbus1

> ulpt0 on uhub1

> ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> =
on usbus1

> ulpt0: using bi-directional mode

> ulpt1 on uhub1

> ulpt1: <Printer-58 USB Printing Support, class 0/0, rev 2.00/2.54, =
addr 6>

> on usbus1

> ulpt1: using bi-directional mode

> ulpt1: offline

> 



Here you go:

https://cgit.freeb=
sd.org/src/commit/?id=3D88162f7abd61206c98432f2c0de869a59be13854



Happy printing :-)

Hans, thank you so much f=
or the help and guidance! :-)



Hi Hans,

Confirmed this is now ava=
ilable in the https://download.freebsd.org/snapshots/arm64/aarch64/ISO=
-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220421-b91a48693a5-25=
4961.img.xz and printing is working well. Once again, thanks a lot!
=


Regards,
Arch=
imedes
 



--0000000000001a922305dd4b3d40--

From nobody Sat Apr 23 09:42:27 2022
X-Original-To: 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 3263819972D9
	for ; Sat, 23 Apr 2022 09:42:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KlmXd3RVZz3slQ
	for ; Sat, 23 Apr 2022 09:42:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650706954; bh=Fl0nQeNy+t6cLk3Nr5aVWGraSNZiN2DaeDZuGxjC6bs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hPwL6Zvcsdz2bF9K5SAzBwRM+Dptl6sqKYgYjA7Nz2u1uBGr4o3Ep47YoTlp/5MJxev+HopkejjooAy6hQURXCsR29e3lIcDUet3OhuarGYQaYbPyevCkLHGc735XfcWDyEWxYzQYPLcOLPy+vEyOmRiiOuagEcSQf5ZpZaj4wXTtDN/KmzPuHKdozGC0rIHDsZE9SGfs3NU+WTveENcNqmO5RL3+nzC9zFooSt0SiaacmDzxbDBi5RBtI0AE9GRwnStSwD/QulUxgu58xM78G8egGzcvFtUCGFe/1K3Epup1alXKwLCzRSXSFb8WPRlLGV89Fvs18C72evbmhV1eQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650706954; bh=vCjZ4xQZURiwUigcHP4z8LcjO6j47FiPt6DhBzfYSmM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=aoZif+8QEIZCeYV8hrGcqnaA0J2Q3r8JJO5q3j8cV/E1zcEChFMGLoPx/jNcHUVnQ+VSDc3Rk4/bmaqZnsstZuaeRSYurygXaAijm10aaQJLHzU0CUd5ve7DSzyEWVv3GTK2gYiBgwynyMI4dm0ZU90qzcqPsxJeFo5nrFejbBnFgU3MiHR/ML7CvLGoxaR8I09UHwRhaeFQoRE0jOeuPVXMNmPCN04gmPUhirO+FS1l+geohMY3t0Bw8LZswtuyZkEh3goZR9DTRqlLvi+AkqHkPrZ7RarRz4ONsnCan6uQZhjQgXsjflq3C2Y2mAXVsK9WQfdoL740EV/iIj/P0A==
X-YMail-OSG: mWjzWmsVM1nd0VB__NLjUBxGh0ro.Pj65A_D7HdwqDqpIReflPBalJED3AypmJI
 SyIWr6d.D6ir6xTi_qOQLm.xYsMAHEg3BHB7CvyiHnTlpcJvSoh2MYRhsG94uLa4KMtsukY8twta
 GfxergVQIg3l7nluDgrMGewjWGyzKWdBMllTcDXk4_4TPuq8b1GIIXFPnpi1yye.jVqs03iiR5JO
 VHEQ2mEUnbzXwNajgSP7hS8kguysivZ.Uudmcd5STUHyMCtv2eeOGFG0C0TvBc_X0cdg0H0cdr9W
 gpje5XaHYwz17c_7NyRH4T3UHweLsCruQIT9NDUnpyw9Ag4tT00Bq0lO26_MjDjXeWoQhB9dou6l
 GcD609swVgvBVnRKV0WNn7Gi7v8i3CzvRuzeiuIpi8tsiPwksq5LNB61x.Va_VuWVioge.cWE30J
 WigSDR3BZPBm47ZXje6El1dZom6diq4cw_P2ld0LoL23Slp4b5y.KiShIczq4YOYmtIzz3VFfCPU
 dmFO8BC4YEZ.AmtedAA7waiOoG4JhlAGL0vQpDjNo12lPMMn0kExHiNxzeBePbj1fKPXxx_RKCuh
 JfqPlxNplN1obl1VTaux7xECW2Zzt1TlXydE7RnncWxDzt3QyFocPU2qLtOmrWR9ggm_pNY5IoTV
 MncyfP4tNJ6w02iSiAaco9Ri9Y91dg7xB9Pv3wfpjaWz4NVyI.6PqS1tbuvG5TKl.s_sfffT2fv_
 VXYPS.QmYe4gCvbhDABsJnOsm0oVPFhNGW17gZQeW46yhlBDO5oOciAfjef35pDiRUB47DVw.nXQ
 Fqck0v6T6qRovFaLDPLY0DgS9lyt5Ln4kI7pP6zHfAI_NN8caFUBV2L9WgZVAzC5yCv3PAF1lLFs
 nm9mQcmEEI_ydEb5ttjsgGQ8W2DITVj.mHL83GLjsoQu1g8sx0RlBrwXI0wHPY1To8wjfw601XMt
 EBiTA7nmpExCKdLsAW6ZKeVdabeBP0KxnHK0F_kEgcgNx8fIn1xyEAeOKTLNgKQzQZClEWQ5LsbY
 LpzUvlqoFNWXwNNBPvQJzQyQ2Zwz2v4E55sCzJ_hiLMDrj6kCagLRNhYn8TpQEwfmr2i8n.o.Ca9
 bTPvwEJcGGIRMxhc8e_Xp4qNVGBfvoqAujjWayceORB6TSwmRjGIp_iOfxqenle2K9uQBB0o1SZw
 ZN_mOyqa5C3bdb08tys5a67bcP8P7emI3Rcsp.kC75yrQWwM5tSCraZbjYrk4TARF5qAffGk_DrF
 kZyIgvuwa4SESZT1qYiNVWaVCLIyrWOXdUXV.3_14Byn1GeMnP9.P2C8mmhETlaWvKWrVr7IwSLv
 FveeuZ086d7daZr2_s6P8xH8ZjfRKn6k2Rc5UIJ_OeuWjRCB6jNqKrKPpZvLf9THMz1ODLGbGXM2
 vIYG3EzdbbHqhx2aipXVfo.GRjOoH2VZl.yvusiOd.CV.duJTgXuOVrBTJPjFeuBA79cr13RgTjd
 J6Bq7GTJR9dyWyCqtX14EtKZo_NWknBkcRkS4glB5FbmSxXUGVC1v114xLIUosxkgKumNTK8NqZZ
 AmpmJq6PUZ57I0ElwUYf1SeFJhCCZGxbmaysmpa9ovmXR.lQpQ6glw.rBTZSGntWsYQXot3bzKo8
 tOhVWmNk9wdbV6gXUn9UusA5.eyp82MIIbaD37yIlmvY8wbldJN0ZTl7tXpXkcIKdWZIJE9NoAk3
 auo2p14JTy_uyxFaMANQSqDUBtsrEjcOFofL7MzDJot8_WhPMP6uzrGeCHWrJObf.P8o3V20jDXW
 VwlOIzzjySE9gl3bUQmkKTWjg__IM6vk_0wMDJKuhFM24ZFimBWoqXLKxVeSenGZa1vueGY65VZu
 Y5P64Kb.JP0Yvbc4N2CH3i1Kc8iSFk_wCGVdeEIv8Bt3EWD1g.1uw.wPaWQv6UkWGN9EjdxA2Mfb
 80jvVLH1Q8XqPvpw9KzbNaplnX054VJtXRW1oLnaCHkhwoPgC7lKVGSHNOghS.CEbCG0xCvRosq_
 chGqf8epnv4cu.eJWgXfIW7lKY386kelVw9exSvOVKpqcF.ke25b1H3VfIMLgQw6N23CkFnOdla7
 SqFrtLB2g_BD_KitHXGpugRvus0BxLFApajVqY2KcYIMrosn3FEw48_izTjBY7R1M_fnp5JSt1ot
 CUjFk2zxf6i02sOmipJIEDKgFxEIh8dmFy2uD1auQML7ZIhUOXWIGVVizQIEoBwPHlsKwuMwtmwS
 Cl8cD.sg5rY356H1UXOpzkHu4cSn7GMukABJjIb0L909lxoQzS9Hawj6F6pLzjjIlmWzPjQL_p.N
 r7SI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 09:42:34 +0000
Received: by hermes--canary-production-bf1-7cfdddd556-pbjl5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b6139de870b34cbc0823fcf051557cc2;
          Sat, 23 Apr 2022 09:42:30 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: Looks like U-Boot 2022.04 may be fairly useful
Message-Id: 
Date: Sat, 23 Apr 2022 02:42:27 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4KlmXd3RVZz3slQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hPwL6Zvc;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.72)[-0.721];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from];
	 NEURAL_HAM_SHORT(-0.97)[-0.968];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4906
Lines: 149

I did the following primarily as a learning exploration
but I figured I'd report some on it.

I have the following devices booting based on U-Boot
2022.04 built via poudriere-devel. I used testport and
bulk and used portlint. I did not update RPi* firmware:
this was just substituting the new U-Boot version into a
working environment to see if it still works.


Xunlong Orange Pi Plus 2E:

U-Boot SPL 2022.04 (Apr 23 2022 - 03:19:10 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1

U-Boot 2022.04 (Apr 23 2022 - 03:19:10 +0000) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E


Pine64 Rock64:

U-Boot TPL 2022.04 (Apr 23 2022 - 03:14:35)
LPDDR3, 800MHz
BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2022.04 (Apr 23 2022 - 03:14:35 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC2
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 05:34:22, Dec  8 2021
NOTICE:  BL31:Rockchip release version: v1.2


U-Boot 2022.04 (Apr 23 2022 - 03:15:10 +0000)

Model: Pine64 Rock64


RPI 4 Model B (0xd03114):

U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000)

DRAM:  7.9 GiB
RPI 4 Model B (0xd03114)

Most of that is based on various FreeBSD main [so: 14]
vintages, some from late March and others going back into
even late last year. (I've not synchronized the systems
in a long time.) But RPi4B was also booted via 13.1-RC4
with the u-boot updated as well.

A simplified sequencing of the exploration is . . .

I started by updating:

 	modified:   devel/aarch64-none-elf-gcc/Makefile
	modified:   devel/aarch64-none-elf-gcc/distinfo
	deleted:    devel/aarch64-none-elf-gcc/files/patch-libcpp_lex.c
	modified:   devel/aarch64-none-elf-gcc/pkg-plist
	modified:   devel/arm-none-eabi-gcc/Makefile
	modified:   devel/arm-none-eabi-gcc/distinfo
	modified:   devel/arm-none-eabi-gcc/pkg-plist

to be based on gcc 11.3.0 (the first non -devel gcc
port to have a bug fix for how it interacts with modern
binutils). Without the fix U-Boot 2022.04 would not
build.

I then updated:

	modified:   sysutils/u-boot-tools/Makefile
	modified:   sysutils/u-boot-tools/distinfo

to be based on 2022.04 . (Turns out that this does
not run into the toolchain bug that u-boot builds
run into. So gcc 11.3.0 is more optional here.
Originally I used 11.2.0 --which still has the
toolchain bug, as I discovered later.)

I then updated:

	modified:   sysutils/u-boot-master/Makefile
	modified:   sysutils/u-boot-master/distinfo
	deleted:    sysutils/u-boot-master/files/patch-common__bootm.c

as well. ( Actually, that last is now in a
sysutils/u-boot-master/files/patch-boot_bootm.c .)
This did run into the toolchain bug and, for now,
11.3.0 is the fix, at least until gcc9 or gcc10
gets an update that has the fix. The fix was
produced after gcc8 went out of support so gcc8
will not be updated by the gcc folks to work
correctly with modern binutils for the issue in
the bug.

For:

	modified:   sysutils/u-boot-rpi-0-w/Makefile
	modified:   sysutils/u-boot-rpi-arm64/Makefile
	modified:   sysutils/u-boot-rpi/Makefile
	modified:   sysutils/u-boot-rpi2/Makefile
	modified:   sysutils/u-boot-rpi3/Makefile
	modified:   sysutils/u-boot-rpi4/Makefile

I removed U_BOOT_SLAVE_PORTREVISION_2021.07 and the
1547145/raw patchfile item that does not apply. (I
have other RPi* patches that I've had for a long time.)
I do not actually have access to a rpi-0-w but it fit
the editing pattern. For rpi-0-w, the build is untested.

The other u-boot slave ports ( u-boot-orangepi-plus-2e ,
u-boot-rock64 , u-boot-pine64 , u-boot-sinovoip-bpi-m3 )
did not need changes to build. I've not had access
to a working pine64 or u-boot-sinovoip-bpi-m3 in years
at this point. So: those builds are untested.

Exploring adjusting things for portlint and how it handled
various things means that I moved around more text than
strictly necessary. I noticed an oddity here or there
that I took a guess about the appropriate fix, not that
I actually know.

As for pkg-plist files, I mostly assumed that what was put
in the staging area was correct and listed it. I do not have
independent knowledge of what should be there. There are
both files that no longer exist and files that are added.
testport reported a type of example of something that I
removed from what I originally generated.

If I end up with access to a 8 GiByte RPi4B Rev 1.5 with
the C0T stepping (no 3 Gibyte limitation, for example),
I'll probably use these builds to explore booting it.
That might have to involve RPi* firmware updates. My
understanding is that there were dtb changes at some
point that FreeBSD is not set up to handle --even for
RPi4B's that now work with the firmware from the port.
But I could be wrong about such.

===
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 24 01:31:34 2022
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 E2A8D1A82B70;
	Sun, 24 Apr 2022 01:31:42 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4Km9bf5cgnz3sXK;
	Sun, 24 Apr 2022 01:31:42 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1650763902;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=J6cPIUqo/hPH+hurFOgQAza3aWtDj91q01r+aS93hi0=;
	b=NBd8+c2IPKHjlGnhSpDEA2u9VD1QnNTk7k19jq10KV0te6iz03TFzuNoPkOG3S1ma2agrR
	yYIXpGky7vZVzCj92udGadwAjoRnIp+qXqmxvE6+EOb7gWYrCMbTgHfbPMqp2LzZchaR6W
	NHH0MFoDXKR9I2O5xXXpl1DMEZ2l+dajU5QRDmbb+PhvHcAqJxMjGF1f7DaJzhNZ/plECY
	02VBhUqzKxOdMwqB4qFvttITi9rwr8GEWSkvYy0oIGTc7FbV3CkT8zTecu4rUXH3EH9hAX
	DeXRCMb7GGuerGJDEAF5/O4cqa140KcrLXjA6tpDnuR33/v/r1aSGOGGalNAHw==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 7EC5F2B0E0;
	Sun, 24 Apr 2022 01:31:41 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Sun, 24 Apr 2022 11:31:34 +1000
From: Peter Jeremy 
To: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org
Subject: USB-OTG on BananaPi M1
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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ZljBatxMhzYYgUJR"
Content-Disposition: inline
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650763902;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=J6cPIUqo/hPH+hurFOgQAza3aWtDj91q01r+aS93hi0=;
	b=g4vQTVorQtcBGT946ZCRg0Fu9aMY0GMh8uB2/MVABKopnXtsGtPVkGqv0fomkECL3smBEC
	PmWZcylu2PFl/76BdR/qYVTo2+zGcnJdivkZduKfm05QOjjAP/sewZA8OVsQtTzkEi9HT1
	Xjb2OTRiJa3t9JTWZpqz/vRcPgIiQTyJRbU5op1Ujzu+bIPZ1EqhFIe5qduvoXp2HGsSp+
	hKvtruIH5tTu4b85Rs+1zBVi44C4rA1g0/TwvYKf7ej7bDZ5ZfzKKWskvB3kWPCHGbR59Z
	0t8/kAcfIAWXmWv2OyztbyRy+nnK2yvOGwUBrQ4R1bwDlEcOrde0lEnZBUtiiA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650763902; a=rsa-sha256; cv=none;
	b=rUivAf7iIli+STDkyhiJ9jfGKlZiN9QdK6U0wrpQWDhzUfYsK3kDE5qpLGeudkh5VLJ96M
	aAZdxiXFu6nemR2Ltf1zlq6dR/WNGubqyj5bnMkQXvCmV4eKV5lLKaHvfJc8IiOwl/O++g
	qJtLRZgcM+dOWkkL2xXQBquZF1lb9C6YL0S/LKRQb2Sh9INRPL1rDnRyxrm+ujilb8Bx2v
	y9hU6lOEkwl7wUNBeEua982A4DBGWidPt3xWUOsxYWX+cigOap2DGEaMwy+l3Jox8HM9Fh
	2U65grfx8uxBQorp8dqzjWODBflwpYMQiLdqT2ghzFgB6JOD4t1FLUf7HGalVg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 40732
Lines: 1017


--ZljBatxMhzYYgUJR
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have a BananaPi M1 running FreeBSD 13.1-stable from about a week ago
and I'm trying to get the OTG port to work.  I have both musb and
umodem devices loaded and the probe looks OK:

musbotg0:  mem 0x1c13000-0x1c133ff irq 20 on simplebus0
musbotg0: setting phy mode 3
usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
usbus0 on musbotg0
usbus0: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub1 on usbus0
uhub1:  on =
usbus0
uhub1: 1 port with 1 removable, self powered

But when I try to connect it to another FreeBSD 13 machine, both ends
report problems:
Apr 24 11:02:59 bpi-m1 kernel: ugen0.2:  at usbus0 (disconnected)
Apr 24 11:02:59 bpi-m1 kernel: ugen0.2:  at usbus0
Apr 24 11:02:59 server kernel: usb_alloc_device: set address 2 failed (USB_=
ERR_IOERROR, ignored)
Apr 24 11:03:00 bpi-m1 kernel: ugen0.2:  at usbus0 (disconnected)
Apr 24 11:03:00 server kernel: usbd_setup_device_desc: getting device descr=
iptor at addr 2 failed, USB_ERR_STALLED
Apr 24 11:03:00 bpi-m1 kernel: ugen0.2:  at usbus0
Apr 24 11:03:00 server kernel: usbd_req_re_enumerate: addr=3D2, set address=
 failed! (USB_ERR_IOERROR, ignored)
Apr 24 11:03:02 server kernel: usbd_setup_device_desc: getting device descr=
iptor at addr 2 failed, USB_ERR_STALLED
Apr 24 11:03:02 bpi-m1 kernel: ugen0.2:  at usbus0 (disconnected)
Apr 24 11:03:02 bpi-m1 kernel: ugen0.2:  at usbus0
Apr 24 11:03:02 server kernel: usbd_req_re_enumerate: addr=3D2, set address=
 failed! (USB_ERR_IOERROR, ignored)
Apr 24 11:03:04 bpi-m1 kernel: ugen0.2:  at usbus0 (disconnected)
Apr 24 11:03:04 server kernel: usbd_setup_device_desc: getting device descr=
iptor at addr 2 failed, USB_ERR_STALLED
Apr 24 11:03:04 server kernel: usbd_req_re_enumerate: addr=3D2, set address=
 failed! (USB_ERR_IOERROR, ignored)
Apr 24 11:03:04 bpi-m1 kernel: ugen0.2:  at usbus0
Apr 24 11:03:05 server kernel: usbd_setup_device_desc: getting device descr=
iptor at addr 2 failed, USB_ERR_STALLED
Apr 24 11:03:05 bpi-m1 kernel: ugen0.2:  at usbus0 (disconnected)
Apr 24 11:03:05 bpi-m1 kernel: ugen0.2:  at usbus0
Apr 24 11:03:06 server kernel: usbd_req_re_enumerate: addr=3D2, set address=
 failed! (USB_ERR_IOERROR, ignored)
Apr 24 11:03:07 server kernel: usbd_setup_device_desc: getting device descr=
iptor at addr 2 failed, USB_ERR_STALLED
Apr 24 11:03:07 server kernel: ugen3.2:  at usbus3 (disconnected)
Apr 24 11:03:07 server kernel: uhub_reattach_port: could not allocate new d=
evice
Apr 24 11:03:17 bpi-m1 rtsold[308]:  interface usb=
us0 removed
Apr 24 11:03:18 server rtsold[857]:  interface usb=
us3 removed

Looking through https://docs.freebsd.org/en/books/handbook/usb-device-mode/
I believe this should work.  I haven't tried using OTG before and am
not an expert on USB so I'm not sure where to start looking.

I'm connecting to the following USB port and there's nothing else on
that USB bus(unfortunately, I don't have ready access to a USB-2
port).  I've tried a different USB bus with the same result (but that
bus was shared so the usbdump was a lot messier).

xhci2:  mem 0xfcc00000-0xfccfffff irq 39 at=
 device 0.3 on pci11
xhci2: 64 bytes context size, 64-bit DMA
usbus3 on xhci2
usbus3: 5.0Gbps Super Speed USB v3.0
ugen3.1:  at usbus3
uhub3 on usbus3
uhub3:  on usbus3
uhub3: 8 ports with 8 removable, self powered

(I actually want to emulate a keyboard but I thought I'd start with
something that's documented to work).

Following are usbdump's from both systems.  According to NTP, the two
system clocks should be within 500=B5s of each other.  Some immediate
questions are:
* Why does the BPi report a number of transactions that aren't seen
  at the other end?
* Why don't the written and read bytes match?  Does this indicate a
  lower-level issue (i.e. the USB-3 part isn't correctly detecting
  that it's connected to a USB-2 device) or is this expected?

"usbdump -vv" on the BPi:
11:02:59.587847 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D0,SLEN=3D=
0,IVAL=3D0,ERR=3DCANCELLED
 flags 0x50 
11:02:59.595811 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:02:59.641528 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:02:59.641555 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:02:59.653500 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:02:59.653515 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:02:59.859546 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:02:59.859582 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.062718 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.062755 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.264592 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.264618 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.264820 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.264832 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.467041 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.467060 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.668150 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.668167 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.872361 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.872398 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.886560 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D0,SLEN=3D=
0,IVAL=3D0,ERR=3DCANCELLED
 flags 0x50 
11:03:00.894526 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.936277 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.936302 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:00.947298 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:00.947306 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.153885 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.153921 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.367219 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.367242 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.576946 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.576964 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.577512 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.577520 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.782875 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.782913 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:01.991425 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:01.991444 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:02.203602 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:02.203644 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:02.738416 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D0,SLEN=3D=
0,IVAL=3D0,ERR=3DCANCELLED
 flags 0x50 
11:03:02.746393 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:02.789289 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:02.789317 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:02.800387 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:02.800402 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.014383 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.014419 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.226854 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.226890 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.430306 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.430331 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.430589 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.430597 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.644238 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.644258 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:03.854669 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:03.854702 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.056638 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.056655 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.070437 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D0,SLEN=3D=
0,IVAL=3D0,ERR=3DCANCELLED
 flags 0x50 
11:03:04.078479 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.121295 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.121328 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.132309 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.132319 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.342687 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.342713 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.553506 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.553524 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.767175 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.767216 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.767478 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.767487 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:04.981110 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:04.981125 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:05.194195 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:05.194234 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:05.408238 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:05.408261 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:05.926753 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D0,SLEN=3D=
0,IVAL=3D0,ERR=3DCANCELLED
 flags 0x50 
11:03:05.934746 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:05.977386 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:05.977412 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:05.989314 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:05.989323 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:06.202272 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:06.202305 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:06.403667 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:06.403689 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:06.617142 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:06.617159 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:06.617395 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:06.617403 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:06.820770 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:06.820809 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:07.034146 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:07.034164 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
11:03:07.247271 usbus0.2 DONE-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
8,IVAL=3D0,ERR=3D0
 frame[0] READ 8 bytes
 0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |
 flags 0x50 
11:03:07.247309 usbus0.2 SUBM-CTRL-EP=3D00000000,SPD=3DHIGH,NFR=3D1,SLEN=3D=
0,IVAL=3D0
 frame[0] READ 8 bytes
 flags 0x50 
^C

"usbdump -vv" on "server":
11:02:59.653012 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:02:59.653237 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:02:59.859094 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:02:59.859370 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.062240 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.062505 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.264137 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.264386 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.264404 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.264635 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.466605 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.466886 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.667715 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.668016 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.871853 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.872522 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:00.946841 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:00.947143 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.153412 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.153765 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.366794 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.367115 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.576522 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.577082 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.577109 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.577267 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.782430 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.782640 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:01.990996 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:01.991509 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:02.203149 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:02.203489 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:02.799840 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:02.800165 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.013911 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.014167 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.226379 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.226967 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.429875 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.430156 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.430188 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.430401 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.643803 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.644155 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:03.854213 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:03.854562 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.056184 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.056408 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.131854 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.132042 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.342252 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.342876 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.553081 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.553515 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.766703 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.767031 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.767067 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.767279 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:04.980695 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:04.980909 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:05.193718 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:05.194070 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:05.407805 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:05.408172 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:05.988840 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:05.989076 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:06.201804 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:06.202178 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:06.403220 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:06.403419 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:06.616714 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:06.616956 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:06.616995 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:06.617170 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:06.820312 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:06.820548 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:07.033716 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:07.033942 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
11:03:07.246804 usbus3.2 SUBM-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000  80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  |........        |
 frame[1] READ 18 bytes
 flags 0 <0>
11:03:07.247070 usbus3.2 DONE-CTRL-EP=3D00000080,SPD=3DHIGH,NFR=3D2,SLEN=3D=
0,IVAL=3D0,ERR=3DSTALLED
 frame[0] WRITE 8 bytes
 frame[1] READ 0 bytes
 flags 0 <0>
^C


--=20
Peter Jeremy



--ZljBatxMhzYYgUJR
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmJkqHJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzSDdQ/+JRY94CbHYyJNH/TUsSCTruV4E6BhQ3gCwTebwSHIKI1E3Ko42ocZfTw9
9sQaBuBQMLe6sOUasL8O6CFvHysULVQRISXl0Go76VtOLZTUGgv4PKo2WNTDTshx
nM0xocgeycIGWE6x3ygigD/caALBIvAXzCZheF5CUob4SbCSYptR9Nc2aPnY1Mvq
GOe+a+h/Absy7o+gKQunOuzf1XMTiLu6i0+Saihff/cMVeuhLT/Wy4e3TAP/DXUU
wkivI3jyKc9tUddndoUzbIxZYEZ/VNQiKXBY6yOj66ozIn1wKcGmpfEnykdf9LH4
2SX7AJFLMKhd1CrSrLSdi/TZGOM4kLWhwofk0ATlZJ4AeLze8y/rQCZ5Vl+CE/cg
bOj1oiyIl2UACJs3Gc257yYO6/uufoA+Eoz/bJsIUBqHCpDZB2vOD0gU3KRxmaIb
hveZLxxaXvCYYXOrKoNnd3BvFYSiPYkvwlip+Qp/hE3+zH70HHa8jujcigQwPhlt
nz/9S0l8St5Htn+IWSiBLztN9/oGzrp2G7PDfJwuu4INWfUMDsuLi+Eu3l+KF3DF
bZMsFtMrnnGcwtDkEvGPQxLiLuOgkM+ooG6H+O+5LfQS+eqS4FrWFGDI5EOI6qt5
DikXL3tFv+4jd0e/4ne6AXL7oLCYXQyarHcW1TJlWjM5BsNb410=
=Uqr1
-----END PGP SIGNATURE-----

--ZljBatxMhzYYgUJR--

From nobody Sun Apr 24 06:45:35 2022
X-Original-To: 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 0B551199BAF3
	for ; Sun, 24 Apr 2022 06:45:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KmJZ552FSz3Gt2
	for ; Sun, 24 Apr 2022 06:45:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650782742; bh=S7FIg6Lr0P1nb632LoPi5MtkUJZAOFkO1usMIGS8TSM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=uIRpoM0f7k2+bqAkPQk7d3Si9HatPiawJkzjP9P546QyPL0a27MYjnZfbWNvuvZxAQ0z+cagzhA7i6YcBaJ8tv0hLdAFfaO3p1UcZN9DFAzl/SJo38h+uu9yF8oKJZcSEWoo1CyUAXv/B22WwtcQ19C4TU5ihe0cx5tNLZR2kAme7D/KJs1Q/aUqxnbbnVYAZtItnYszkEvcwHcfPWW8Zl2qSdqVAsPNN6j/TWgEDxN9YfHB7MUh0L3nXtzwAmOPITUMcku2uITxSWI7stKGc5qLe+CUSKnl/GkGcNiz+smTqle87jFW7bsillTipv1koE9OB1Typ+H7Ycb8RtOpfg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650782742; bh=1AQGzh3OplffyqWa3R2WsBC0Bskj/sh72GJ/c8fFPOP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XZ3hk1+Rn778LRC63sf1ODECT2E3NTqL8BTMqzZz7jth7KHaOmJnxKDf3SlvT1bRVXTXaxwaEUd5c5TbPAfQBraqDsyucTNzT9/doHuP++hGSBy8wFznW43vZNzkAa6hf3N5EOQTzgdLj+40a+e/y6xcy4oAYKMXg/a48ufvG+wId0DXjISfkafGgK2mZVz73HdQ4BQ5qbTVqx2No5QdgOsXJ+wf152n9jl2S7Dvpqf2ZoRVw10GXQA8bFocdyI9NZpmmPe3jy0/5cve9TNt9rmWcDV0fqwYogoEjdPegXqBHhIQmCYujK9bR2/Ok8hYsUDheG4OAQX114fYxLN0qA==
X-YMail-OSG: 93Ob1agVM1knjgSCaiBVnfxrniKTkz_udGN9dSX6fmtpvbEOSXGrVraiB6ucly6
 BpcpNRwZnTY1RGY_SvnnnSogtP4uiJIFMFQmhXuWlDc.fTfNOXKz0qHJQfUswpv7BP2CiXx_Km.2
 VmXiDa.rDixyL9Bf0FUCkIr1wyp_RAno8AumxoYXkSwcNSMKG8c.JUGSQq8jT8DD7WYsbRo9KrQq
 o1Fm.Utdfky6SWAbEGmZLc5zuLAV4wJYQnElCtk7.xLhLpksp0L0kM29gmg47DPEu.Z2meBsXyyg
 BCwJOit7clrVfxZET37I1XCVOvr.gIPT6AbDPqxmh71KgjSc4nUs8RR7PRkS4madZ8A9Z7OJcX3A
 ckgK3ba7QiU2bFxI6hl3OYDPpjAj2.9IDfgkrmS4VXT9cTpZOjwqDqctEoTuGVzvRapY30yyAfwr
 g4HgYnangwxLmYboiSn1kZaM9Lb1Ry6aX6zhkCSC2Hd.3eeOg303kVVv5V9TbJV7YgH_OyDDUSgU
 FPc8Aw64PpAy9CL1xkh4MA0AHAgQgVubQCCWhc4tgmyUfwb0C3jW6MHTGnkgFic_0Cr4N5mC0yrn
 atVKhsUS5qqh0dmIKbCauNR2Vp1ZlTSlq9kIr.mwlrWlsri._NiJi0hp0OIG8XBRBSdm_mNJvkhq
 23e0n9aJc3w.cunRalJHHX.xYFDshDsVwdrUUazQRNLYeKQQBQKR6soNnhVcFjVPcO2cyF3yylfI
 HlOkhsN2pZP8lioyV3tL4MRD_clMYiN_zqaDMwID2vbS.xg9CbBnnL6o.HV_dU09.BZKu12QGqG6
 P7UWHFI_T1cNXeQfpHTWAcW1zjE3GRm1kiGTghzHdyk4wAboBRxoGw_vVbH5GoQO0pdFQ6SkxYZN
 N5h7uMP8zcfcO2QeogrX4xQZlx71NRn9K7rIXwda1CC3XX3N2cYXtlfuL3t6KBX9mdCG4VWAedfQ
 zXXch0tAFOe9h0GwpATS1RdIwBIrDbAJURG870umgBNRWEfEFc1ENFTiJqZrqR.9IlRe8GAunUKl
 3U9svQeV6mPKsUFG0bfLKLHJeRzjzi5maoB65vXPfXxZ0xG5UrV16T3n9hBuUNEt_DE__palS1P4
 yMsKrUR3uqssLpUwnirBFdCmyr5OXryFwr_fg.QtpCwlvg_Vc69q.2PS_T2LFIdHiylnvFNRflwZ
 DbiH7LhMUfEZHJmgErig688riU_u9sAPv67IBUoLQ6_Zcdo3KteGB3GCLSpQSwZyqdOmetEQahMu
 73UzGkOJBYL9ePKfVLVzZ5QKkjtOJOoe65WeunlE62ALjk3gYw0Fh2LO8mlnDfpfy3MzQFoYwhZF
 9zDz_xiK5L9SDeQTB59zEUhswA10_gZqEaCGFkLmxDqm1AZzgmi4cOk4JWLa3YmOqzBisDyJev51
 VKlllPgtLj0VE4Dk2J2xwRZR63sH2FRWssDnusZBCwNdmAsv0s6tFTuPvUyvIXeCJmkYsSGCicK8
 q9ehXwGnRkrEOoleWtqp.Y3Jm_RHiV2Xz8OsSSC8NFFNE3bkqNCa6cbMWGzcucUczw.30V2sC_PP
 G8.8dUQP54O4AM4lKUktsvF1d.Co7ZwEPm2oqkjF_JXbsIDZc.GUpWHJMXU6Rq57zWzdfLBDdMYV
 wVQ.vtHKd9rQzW4McAZpnpIakIQmsNITkj40bcdu2OkhrstwGoVDzTRrC_FRPC6RK89dmfyMbgyY
 8m5BSscFVBXb32izVSazYmwu1QydAE.kE8zXc3mKltx7Fvp7MeW.l.VNWXYiCvwEZidKIY.PEOsV
 C3Uq.sXK44QPyrvDAT_8qtcirrUdloKTxZzP_Rku42xGeiTHG8wx7viUdG2MfN.FNDLZrvx19Brw
 x9WKbisuxgbd0xpV2xHWg06lgn72mXNOtfuW.muavs3kMJK_QrbMSYPUG65TLVmh2FtyGX7QTfl.
 FXwnLr_RBVFYLxClcpPfgdhRC3Gyi06glcobzypaFqu1OKa18zkiaSQNSttb8IA5tpomTqqnK2Vu
 fZrr0YyOVftD9TsgtSVltUXTX9D8vyE6_I6_ITrKYJMV79_lHgQIFbNecaH5FLhR1Jw84layejB8
 cgQDORrhbzztzEw5LTJSZh4thBjtT5iqORWzWJHeYTF7ZkhfGqTq_V_.G7hQVjnVqFMeCvM2hY9B
 U5mYGLWuN0yHGRWDR.TuyQOvi7hjS_rOPYKWTiOKTQP6nVfOWQL1xEB7HOuSuZpk3BRyHBE7MCYb
 scWlAnlj1Gb7.My8PWi3eSY7CtCBEUbocROfoG8FWjRQUCgoGUtQ0IwK_lmdV9EIxJsNthLseUa.
 kG6WjpONX
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 24 Apr 2022 06:45:42 +0000
Received: by hermes--canary-production-ne1-6855c48695-hd29l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8ff92bbd13aaafa7f2cee0a3b5a32ea1;
          Sun, 24 Apr 2022 06:45:37 +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 14.0 \(3654.120.0.1.13\))
Subject: FYI: RPi* firmware tagged 1.20210805 appears to be the last to be
 bootable by FreeBSD via fdt use; sequence of 2 failure modes after that
Message-Id: 
Date: Sat, 23 Apr 2022 23:45:35 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4KmJZ552FSz3Gt2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=uIRpoM0f;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 76982
Lines: 2067

The following is based on a microsd card with 13.1-RC4 on
it were I'd previously substituted my U-Boot 2022.04 build
and tested with the RPi* firmware that is in the 13.1-RC4
image. Here I've tried replacing the RPi* firmware and
holding the rest constant.

The boot tests are on a 8 GiByte RPi4B Rev 1.14 with the
B0T stepping. I've not been copying over the linux kernels,
which they also bundle with the firmware.

[13.1-RC4 is just what I happened to use. I doubt anything
here is special to 13.* or stable/13 or main [so: 14].
(I do not use 12.* or stable/12.)]

The observed status went like . . .


firmware-1.20210805/boot/

The RPi* release tagged 1.20210805 is the last version that
FreeBSD booted with. (Other than booting, logging in, and
shutting down, I've not been testing other aspects of
operation.)

=46rom what I've read, firmware-1.20210805/boot/ should be
recent enough to handle the Rev 1.15 related PMIC variation.

[I'll note that firmware build dates need not be the same day
as the date encoded into the tag --in fact it is usually some
earlier day. On rare occasion it can be a lot earlier, and
there is an example of that below.]


After firmware-1.20210805 there are 2 major failure modes.
Both stop at the same sort of point in the messaging --but
there is a huge difference in the count of earlier error
messages. It looks to me like all the issues require
FreeBSD changes if modern RPi* firmware/dtb's are to be
usable via fdt.


The 1st mode happens for (I've added the -fails notation):

firmware-1.20210831-fails/boot/
firmware-1.20210928-fails/boot/
firmware-1.20211007-fails/boot/
firmware-1.20211029-fails/boot/
firmware-1.20211118-fails/boot/
firmware-1.20220308_buster-fails/boot/
 (The _buster one has firmware from 2021-Dec-01, which
  is before all the tagged releases listed below.
  It looks like the switch to the new major kernel
  version after buster came with other changes that
  FreeBSD has not tracked.)


The 2nd mode happens for the following. (Again with extra
notation.) There are a lot more error messages before the
panic happens for these. The firmware builds for these
are more recent than for the above list.


firmware-1.20220118-fails/boot/

firmware-1.20220120-fails/boot/
firmware-1.20220308-fails-non-kernels-same-as-1.20220120/boot/
 (I did not repeat the testing of the unchanged firmware.
  I just did the "diff -r" to discover the lack of change.)

firmware-1.20220328-fails/boot/
=
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files/boot/
 (Since the .dtb for the RPi4B was different, I did test this.)


The failures look like (each test shown) . . .


firmware-1.20210831/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20210928/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20211007/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20211029/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20211118/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20220308_buster-fails/boot/
 (The _buster one has firmware from 2021-Dec-01, which
  is before all the tagged releases listed below.)

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210251776 (7829 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
MAP 39f30000 mode 2 pages 1
MAP 39f34000 mode 2 pages 3
MAP 39f38000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
usb_nop_xceiv0:  on ofwbus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f89a40
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s



Below are the examples of the 2nd mode of failure . . .


firmware-1.20220118/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210247680 (7829 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
MAP 39f2f000 mode 2 pages 1
MAP 39f33000 mode 2 pages 3
MAP 39f37000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
regfix2:  on ofwbus0
regfix3:  on ofwbus0
regfix4:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
psci0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
regfix1: Cannot configure GPIO pin: 5
REGNODE_INIT failed: 6
regfix1: Cannot register regulator.
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
usb_nop_xceiv0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f8b120
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78


firmware-1.20220120/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442929152 (8051 MB)
avail memory =3D 8210247680 (7829 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
MAP 39f2f000 mode 2 pages 1
MAP 39f33000 mode 2 pages 3
MAP 39f37000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
regfix2:  on ofwbus0
regfix3:  on ofwbus0
regfix4:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
psci0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
regfix1: Cannot configure GPIO pin: 5
REGNODE_INIT failed: 6
regfix1: Cannot register regulator.
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
usb_nop_xceiv0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f8b120
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20220328/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442920960 (8051 MB)
avail memory =3D 8210239488 (7829 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
MAP 39f2f000 mode 2 pages 1
MAP 39f33000 mode 2 pages 3
MAP 39f37000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
regfix2:  on ofwbus0
regfix3:  on ofwbus0
regfix4:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
psci0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
regfix1: Cannot configure GPIO pin: 5
REGNODE_INIT failed: 6
regfix1: Cannot register regulator.
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
usb_nop_xceiv0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f8b120
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s


firmware-1.20220331/boot/

---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
VT(efifb): resolution 592x448
module firmware already present!
real memory  =3D 8442920960 (8051 MB)
avail memory =3D 8210239488 (7829 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
MAP 39f2f000 mode 2 pages 1
MAP 39f33000 mode 2 pages 3
MAP 39f37000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofwbus0
clk_fixed3:  on ofwbus0
simplebus1:  on ofwbus0
simplebus2:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
regfix2:  on ofwbus0
regfix3:  on ofwbus0
regfix4:  on ofwbus0
simplebus3:  on ofwbus0
simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
psci0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
regfix0: Cannot set GPIO pin: 6
REGNODE_INIT failed: 6
regfix0: Cannot register regulator.
regfix1: Cannot configure GPIO pin: 5
REGNODE_INIT failed: 6
regfix1: Cannot register regulator.
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
gpioregulator0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
usb_nop_xceiv0:  on ofwbus0
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b464
  x2:                0
  x3:                6
  x4: ffff000000fbf77c
  x5: ffff000000fbf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fbf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b612
 x25: ffff0000008dfcfc
 x26: ffff000000943716
 x27: ffffa00000f8b120
 x28:         31e00000
 x29: ffff000000fbf7e0
  sp: ffff000000fbf7e0
  lr: ffff0000008680a0
 elr: ffff000000862134
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff000000862134
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 24 09:50:44 2022
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 0A71E1993E61;
	Sun, 24 Apr 2022 09:50:47 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KmNgV2DWyz3sGl;
	Sun, 24 Apr 2022 09:50:46 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 5761226012D;
	Sun, 24 Apr 2022 11:50:45 +0200 (CEST)
Message-ID: 
Date: Sun, 24 Apr 2022 11:50:44 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: USB-OTG on BananaPi M1
Content-Language: en-US
To: Peter Jeremy , freebsd-arm@freebsd.org,
 freebsd-usb@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KmNgV2DWyz3sGl
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [0.33 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.89)[0.889];
	 NEURAL_SPAM_LONG(0.74)[0.736];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-usb];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 345
Lines: 13

On 4/24/22 03:31, Peter Jeremy wrote:
> Apr 24 11:02:59 server kernel: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored)

Just one comment here.

Set address is one of first commands executed.

Are you sure the D+ and D- pins are properly connected via the GPIO 
configuration?

It looks like the pullups / pulldowns are.

--HPS

From nobody Sun Apr 24 09:58:00 2022
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 BC2881996084;
	Sun, 24 Apr 2022 09:58:04 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KmNqw0gCXz3tjX;
	Sun, 24 Apr 2022 09:58:04 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 203F326012D;
	Sun, 24 Apr 2022 11:58:03 +0200 (CEST)
Message-ID: <1b0031a4-6934-e9d2-e782-e7c9c0293c71@selasky.org>
Date: Sun, 24 Apr 2022 11:58:00 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: USB-OTG on BananaPi M1
Content-Language: en-US
To: Peter Jeremy , freebsd-arm@freebsd.org,
 freebsd-usb@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KmNqw0gCXz3tjX
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-0.30 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.28)[0.279];
	 NEURAL_SPAM_LONG(0.72)[0.718];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-usb];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 596
Lines: 19

On 4/24/22 03:31, Peter Jeremy wrote:
> 11:02:59.641528 usbus0.2 DONE-CTRL-EP=00000000,SPD=HIGH,NFR=1,SLEN=8,IVAL=0,ERR=0
>   frame[0] READ 8 bytes
>   0000  A3 77 65 86 A3 77 65 86  -- -- -- -- -- -- -- --  |.we..we.        |

Hi,

This byte sequence looks like garbage. It should be idential to that of 
the host side. If this happens after a while if means that the OTG FIFO 
size is incorrectly set, see this printout:

 > usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
^^^ try having a look in the driver where this comes from.

Try setting 8Kbytes or 1KBytes.

--HPS



From nobody Sun Apr 24 10:01:26 2022
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 AD78119973F7;
	Sun, 24 Apr 2022 10:01:28 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KmNvq71Hnz3vhN;
	Sun, 24 Apr 2022 10:01:27 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id D815D26012D;
	Sun, 24 Apr 2022 12:01:26 +0200 (CEST)
Message-ID: <4ce2559a-56a7-cad4-a884-16781e6e84b2@selasky.org>
Date: Sun, 24 Apr 2022 12:01:26 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: USB-OTG on BananaPi M1
Content-Language: en-US
To: Peter Jeremy , freebsd-arm@freebsd.org,
 freebsd-usb@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KmNvq71Hnz3vhN
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-0.25 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.30)[0.301];
	 NEURAL_SPAM_LONG(0.75)[0.749];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-usb];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1159
Lines: 49

On 4/24/22 03:31, Peter Jeremy wrote:
> (I actually want to emulate a keyboard but I thought I'd start with
> something that's documented to work).

Some hints for that:

> usbtest
> [0] - Select Computer Mode:
> 
>    1) This computer is Running the Device Side
>    2) This computer is Running the Host Side
>    x) Return to previous menu
> 
>>1
> [0.1] - Select Device Mode Test Group:
> 
>      1) Audio (UAUDIO)
>      2) Mass Storage (MSC)
>      3) Ethernet (CDCE)
>      4) Keyboard Input Device (UKBD)
>      5) Mouse Input Device (UMS)
>      6) Message Transfer Protocol (MTP)
>      7) Modem (CDC)
>      8) Generic Endpoint Loopback (GENERIC)
>      x) Return to previous menu
> 
>>4
> [0.1.4] - Select Keyboard Model:
> 
>        1) Generic Keyboard 
>        x) Return to previous menu 
> 
>>1
> [0.1.4.1] - Default Keyboard Settings:
> 
>          1) Set silent mode (selected)
>          2) Set pattern mode 
>          3) Change pattern: 'abcdefpattern'
>          4) Change key press interval: 1023 ms
>          x) Return to previous menu
>          s: Ready for enumeration

And:

/boot/kernel/g_keyboard.ko

Patches are welcome!

--HPS

From nobody Sun Apr 24 11:37:09 2022
X-Original-To: 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 129AF1A8C528
	for ; Sun, 24 Apr 2022 11:37:24 +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 ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KmR2V2Vvbz4ccr
	for ; Sun, 24 Apr 2022 11:37:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650800234; bh=lr6SUSSxo8+KQRjRRODzswq1NYxg2A5Jp2e5jg0kvlw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=B0nqhYzICVzjQhZz2+snKdpkTa/b3FFzl9OjvBjB2JZfvXekvImChXqUOu/H5iJMhica/uUG5l2SBDPkrAZe905vEpj9a751mvwy0b4nH8C5TzkfjvAAUdomAo8DaxRLiRY3ctBvWlpO7R+sBA/XjVkMUX6nMxVPon8c5Qj1Ek9PN8KuceAMcxh/YGwJ48Fk3oftVa9i+a3xUDOgfySuLXmRSFBE9bH+a7l74e0/dLjiM/MxOMN/Zto3KolagF+uliGJwCtUQ7Q4k4r1GhAp4D0x4yWdYHp4MpoKOtpy6YDkfCod5kfYHS5p2HGqbXu4u5T4yTqzPUHgKcDBriHZQQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650800234; bh=F2yfvpNABeaNBZKIYfoUwA9XdzordJ1x9l+6sRno6Ns=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=K/vH9DyNxVFQmrxP2BPBNC+I9G/W7LYuUoT+sRWPL0KoByAk0P29uGkpHdkKNPIqVO/KK4t5tcYiDmava/MK731XSE6kSkDgS/rTkUy8OoTctkMJdWrAMGE95yjUIvF++FLiZWtev9Y87Bme0Z7qgSae9aFYKsE+IEN29pVg5bBrr1qkhO4VgHhKovyZiMQakhHw0dnX8PFzLK95KLKticXJOzbfKB0etBIjVOb4Uej5fO7iff+/b+Of2DmM8eH4x0VQJHSEHV/FgnBhzUYYeVmyCxPv4W6/4bONym4NGxtBGJ0d2IEFTcuUlQBwIPWhxnPkknFdaVlXz1GlG+3Nvw==
X-YMail-OSG: JphRGegVM1nv82TxIn1qP2prqfRb8QqkK3yXBD4SPpPsXD_c7zjU4SoR1e.KE5r
 Te2Yu.mow4zDOY7s2AslzqGXNMOkxs.rWQdAVqDplidD7XTbmXzNI4ptyhUGIbq8rAqINW8uTcKm
 bG7uqx7yeJ2J6eMkQFeYPV68DUud__JJLQSweFgfDsOeD_kN69Ft45lrX_wrz5PcEWyqxZ22L5m.
 6k8WONr4aw_qUPb4ATyxd_SNdF0GSdOwI42aKXeRe390EmKTduc2CiNb8fkmUgvJUAHNwNZz3On0
 aUcNQ7sr3gBwcIjUa4rw71j4yLxAOM3QU0s6wnBDWaYOkUARTAwsmK5wq0FMunRhmrPyj8mg2HAs
 xkfwqQkO9N0I9pJsNVteFIvT_2lkY3Is.XRBF_zSLr57cknhIjhmx2feRFFysInUHQBAFVfj2L3T
 M99uxH7LTul2kURegTDCIg0AwNqY2JrjaS2FLvQQLO1u9w8FMTIRpA_qLGZR7QwpWYeU28zYWsYI
 WhLL_YPlOn5dMVnTU54u5baaOsKszJ.xrGfZnkcQhEQgiLg2.fuJJ5Bbcd0kgQ3SzaO346Cq3kYU
 QSlL1_r13noLktLHjQaEwjNZMgBE.MdKAxDAGlTrjNqY.p43sHpp7MfJeSaGouulkv5GgauGYQEv
 k4pw0jOJUrmwhtycQd3vutjE5emoTtoQl72DrtYysISrXXoKjBVzFC_2WyMI26M0jaDIg4yDbQZI
 B0eohdUQdLJ4hiAAl1huLk2Rshl.xP.CE0JvWi.PbX0czTefdIWtEhkRhIiVfCZUnsbP02L1cKJ7
 6NCrHqwFcP5BqjivGO1zbL1nU_.ZHS8vHQ3icmEL5ctI0B4xAUNhaVk8u1p5IVZKtFTACMSr_BtQ
 VVggeIhB8JmF6RFT9APLfXVVOAbpIvKtqIjA0MYg0HLxtUsYG5U380LGGQRvSqFfyB2vpA0sSmMS
 OQCmn1sm5Tp1svRONcOiu8Wyg_Ibn2j2GUDP2_Vw86Wjh0hoMrFzT2CHsd2FkQwWyaHruocJXfKh
 hFnaaLaO_BcXkaWiUt8wWzh1a36yfoKUc2E03zPwp9ZvpcJOt_oDXOmUT6n4Jf7BcLvT5qM4mb0b
 8wJCDRke.3k7a3COwt09Qb7WsmbUK702E0k_0jqpxDx8RUN7m.WtwlpNIwgejo2MpnvlUOMrQMMi
 5qDAwCvlxLpMOqe21xzCSo5_tTieURUS3_hVtpl2W24EwURy6wSIWRW.85k0RkRH0GKNenTEJkZi
 3yHXJyNx.U1Jc2kuLpGDlIU.gTEY66jlet21UGZaeuWxNBnonELMdNZ1ouV2sybqaUsYvZm6cC_g
 f9yI_Crsm.g6W823uBe1MXEJJxOAzJH.Gat22hlZyvlFJ80AoBURTGgb6HL94C_CUPE1Chu8Iy.Q
 AquROg4X03I6CfkOTRizkhigNfhsCMZBjKn91mECaxQqVyluJz9Qcl4vy8OxXwEwwaSTpuxZ2S4t
 XR43RdzpXNszeANphq1uS0tW6VQ.eY66M0n0Ggz.B7Mgr3yNix40o08LUik.EEftn_w57Gh00iyy
 0qHv4XLyMJetehbeQAyBZXjgjUj.vyhhKEQfZDir20G91mtKOdcvQx_T4gkNyBSE9pdhe40e5Xgw
 47Y9gl7yHWngrpn.rqmXYXuKoZuJSK_rU5yeZClHBBriC6W3bz_KjpBYkM88noG1jE68sghe88Tu
 nZWyhg3Wktr7p9BmlMegFnJ6XQ8AP0f6xJg1VDoHewTvYjY2a6Q_4KcpcY5rZafJ3Yi8H6EjGu0z
 v9T8eUXS_QC2ToXWUJ5ECcE.oxq87LKALXiUWuje3s77yIPBE9S68EUdvt9z93G8UxKUkaRGxHZ.
 wU4FJk3eb_JW.ngWUpNCM8Q9qVEx_SNWSlAfipiQ.vdT2aJnw2MFqWupAcysgc3b5nB0o8L5.dD2
 ZxQvMaC2mzYADlIanYLPDBB.DynWvtcDWxNDSytrJxCNqPaDrCw50aF3Fj9HQsg7tnNaVYqVzp83
 Db__JG3XSznkbrV3PXgKb8Qx9u1vPvm.NKt9y6JeVjxIQ6GwyX4cDQ7Sw2v96Nbs0jPuvjplan2r
 WYxhUFeIpwktddPJJ05sAP_1_L4n3P_ZcoY4A90LzDIZvPBNxS0uLJfv0Agr_dJN5OWkVUmAMfDP
 do7_yx29yOsDRiM0D0D4BGhgc7upsaARlTslTyd.5ZwuOSNYl8PC59SEKGsyQN9eO5isXmVTzgrC
 cxk0YO3tvjZteucMnws4edI_thkCIbRzLcd7mN2do_GKUGa_udZ.cORWeeUuvxVD6Wvqses3Wo31
 9uv2baMU-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 24 Apr 2022 11:37:14 +0000
Received: by hermes--canary-production-gq1-6b7487d8dd-4dbb2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f3916c915c50de148382a8de6b7216cd;
          Sun, 24 Apr 2022 11:37:10 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi* firmware tagged 1.20210805 appears to be the last to be
 bootable by FreeBSD via fdt use; sequence of 2 failure modes after that
Date: Sun, 24 Apr 2022 04:37:09 -0700
References: 
To: "freebsd-arm@freebsd.org" 
In-Reply-To: 
Message-Id: <836019DE-531E-4B49-8A82-0D8F84885C21@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KmR2V2Vvbz4ccr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=B0nqhYzI;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 84420
Lines: 2216

[I think I found the reason for the boot crash that is
a common failure to both failure modes. The 2nd mode
has other issues I've not analyzed.]

On 2022-Apr-23, at 23:45, Mark Millard  wrote:

> The following is based on a microsd card with 13.1-RC4 on
> it were I'd previously substituted my U-Boot 2022.04 build
> and tested with the RPi* firmware that is in the 13.1-RC4
> image. Here I've tried replacing the RPi* firmware and
> holding the rest constant.
>=20
> The boot tests are on a 8 GiByte RPi4B Rev 1.14 with the
> B0T stepping. I've not been copying over the linux kernels,
> which they also bundle with the firmware.
>=20
> [13.1-RC4 is just what I happened to use. I doubt anything
> here is special to 13.* or stable/13 or main [so: 14].
> (I do not use 12.* or stable/12.)]
>=20
> The observed status went like . . .
>=20
>=20
> firmware-1.20210805/boot/
>=20
> The RPi* release tagged 1.20210805 is the last version that
> FreeBSD booted with. (Other than booting, logging in, and
> shutting down, I've not been testing other aspects of
> operation.)
>=20
> =46rom what I've read, firmware-1.20210805/boot/ should be
> recent enough to handle the Rev 1.15 related PMIC variation.
>=20
> [I'll note that firmware build dates need not be the same day
> as the date encoded into the tag --in fact it is usually some
> earlier day. On rare occasion it can be a lot earlier, and
> there is an example of that below.]
>=20
>=20
> After firmware-1.20210805 there are 2 major failure modes.
> Both stop at the same sort of point in the messaging --but
> there is a huge difference in the count of earlier error
> messages. It looks to me like all the issues require
> FreeBSD changes if modern RPi* firmware/dtb's are to be
> usable via fdt.

I've noticed a difference between the working context and
the failing ones (both failure modes).

Failing:

spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
NOTE BELOW LINES MISSING HERE.
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0

Working:

spi0:  mem 0x7e204000-0x7e2041ff irq 18 on =
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
START LINES MISSING ABOVE
iichb0:  mem 0x7e804000-0x7e804fff irq 26 =
on simplebus0
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
bcmwd0:  mem =
0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on =
simplebus0
bcmrng0:  mem 0x7e104000-0x7e104027 on =
simplebus0
gpioc1:  on gpio1
END LINES MISSING ABOVE
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 73 on simplebus0

In particular:

bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0

being missing means no bcm_dma_attach and that in turn means
that the static bcm_dma_sc =3D=3D NULL still.

The panic was: panic: vm_fault failed: ffff000000862134

where:

ffff000000862134  ldaxr  x1, [x9]

which is part of:

int
bcm_dma_allocate(int req_ch)
{
        struct bcm_dma_softc *sc =3D bcm_dma_sc;
        int ch =3D BCM_DMA_CH_INVALID;
        int i;

        if (req_ch >=3D BCM_DMA_CH_MAX)
                return (BCM_DMA_CH_INVALID);

        /* Auto(req_ch < 0) or CH specified */
        mtx_lock(&sc->sc_mtx);
. . .

So the likes of &sc->sc_mtx end up being a small offset
from address zero:

  x9:               20

Thus the panic.

As to how bcm_dma_allocate happened without bcm_dma_attach
happening first . . .

The working context's dtb has the ordering:
(I also show mmcnr@ and the brcm,bcm2711-dma
 just for reference.)

                dma@7e007000 {
                        compatible =3D "brcm,bcm2835-dma";
. . .
                mmc@7e300000 {
                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
. . .
                mmcnr@7e300000 {
                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
. . .
                dma@7e007b00 {
                        compatible =3D "brcm,bcm2711-dma";

But the failing context's dtb has the ordering:
(I also show mmcnr@ and the brcm,bcm2711-dma
 just for reference.)

                mmc@7e300000 {
                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
. . .
                dma@7e007000 {
                        compatible =3D "brcm,bcm2835-dma";
. . .
                mmcnr@7e300000 {
                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
. . .
                dma@7e007b00 {
                        compatible =3D "brcm,bcm2711-dma";

So, for sequential handling in the failing case, the dma@7e007000
would use bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach
sequence had happened, leading to the crash.

Note: I used "fdt print /" from U-Boot to get the dtb and its
ordering. This was based on the address that the RPi* firmware
reports when debugging output is enabled (0x4000 here).


> The 1st mode happens for (I've added the -fails notation):
>=20
> firmware-1.20210831-fails/boot/
> firmware-1.20210928-fails/boot/
> firmware-1.20211007-fails/boot/
> firmware-1.20211029-fails/boot/
> firmware-1.20211118-fails/boot/
> firmware-1.20220308_buster-fails/boot/
> (The _buster one has firmware from 2021-Dec-01, which
>  is before all the tagged releases listed below.
>  It looks like the switch to the new major kernel
>  version after buster came with other changes that
>  FreeBSD has not tracked.)
>=20
>=20
> The 2nd mode happens for the following. (Again with extra
> notation.) There are a lot more error messages before the
> panic happens for these. The firmware builds for these
> are more recent than for the above list.
>=20
>=20
> firmware-1.20220118-fails/boot/
>=20
> firmware-1.20220120-fails/boot/
> firmware-1.20220308-fails-non-kernels-same-as-1.20220120/boot/
> (I did not repeat the testing of the unchanged firmware.
>  I just did the "diff -r" to discover the lack of change.)
>=20
> firmware-1.20220328-fails/boot/
> =
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files/boot/
> (Since the .dtb for the RPi4B was different, I did test this.)
>=20
>=20
> The failures look like (each test shown) . . .
>=20
>=20
> firmware-1.20210831/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20210928/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20211007/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20211029/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20211118/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20220308_buster-fails/boot/
> (The _buster one has firmware from 2021-Dec-01, which
>  is before all the tagged releases listed below.)
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210251776 (7829 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
> MAP 39f30000 mode 2 pages 1
> MAP 39f34000 mode 2 pages 3
> MAP 39f38000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f89a40
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
>=20
> Below are the examples of the 2nd mode of failure . . .
>=20
>=20
> firmware-1.20220118/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210247680 (7829 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
> MAP 39f2f000 mode 2 pages 1
> MAP 39f33000 mode 2 pages 3
> MAP 39f37000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> regfix4:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> psci0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> regfix1: Cannot configure GPIO pin: 5
> REGNODE_INIT failed: 6
> regfix1: Cannot register regulator.
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> usb_nop_xceiv0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f8b120
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
>=20
>=20
> firmware-1.20220120/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442929152 (8051 MB)
> avail memory =3D 8210247680 (7829 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
> MAP 39f2f000 mode 2 pages 1
> MAP 39f33000 mode 2 pages 3
> MAP 39f37000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> regfix4:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> psci0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> regfix1: Cannot configure GPIO pin: 5
> REGNODE_INIT failed: 6
> regfix1: Cannot register regulator.
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> usb_nop_xceiv0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f8b120
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20220328/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442920960 (8051 MB)
> avail memory =3D 8210239488 (7829 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
> MAP 39f2f000 mode 2 pages 1
> MAP 39f33000 mode 2 pages 3
> MAP 39f37000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> regfix4:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> psci0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> regfix1: Cannot configure GPIO pin: 5
> REGNODE_INIT failed: 6
> regfix1: Cannot register regulator.
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> usb_nop_xceiv0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f8b120
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20
>=20
> firmware-1.20220331/boot/
>=20
> ---<>---
> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
> VT(efifb): resolution 592x448
> module firmware already present!
> real memory  =3D 8442920960 (8051 MB)
> avail memory =3D 8210239488 (7829 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
> MAP 39f2f000 mode 2 pages 1
> MAP 39f33000 mode 2 pages 3
> MAP 39f37000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP fe100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> clk_fixed2:  on ofwbus0
> clk_fixed3:  on ofwbus0
> simplebus1:  on ofwbus0
> simplebus2:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> regfix4:  on ofwbus0
> simplebus3:  on ofwbus0
> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> psci0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> regfix0: Cannot set GPIO pin: 6
> REGNODE_INIT failed: 6
> regfix0: Cannot register regulator.
> regfix1: Cannot configure GPIO pin: 5
> REGNODE_INIT failed: 6
> regfix1: Cannot register regulator.
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 on =
simplebus0
> gpioregulator0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> usb_nop_xceiv0:  on ofwbus0
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b464
>  x2:                0
>  x3:                6
>  x4: ffff000000fbf77c
>  x5: ffff000000fbf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fbf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b612
> x25: ffff0000008dfcfc
> x26: ffff000000943716
> x27: ffffa00000f8b120
> x28:         31e00000
> x29: ffff000000fbf7e0
>  sp: ffff000000fbf7e0
>  lr: ffff0000008680a0
> elr: ffff000000862134
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff000000862134
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 24 12:36:56 2022
X-Original-To: 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 BFD31199ACC9
	for ; Sun, 24 Apr 2022 12:37:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KmSMQ4rh5z4mtb
	for ; Sun, 24 Apr 2022 12:37:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650803819; bh=HhwwB6AHXZ+YGVBAI9yp93yp/yCRdvDMk69YbwqIx7U=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=FsZqBpj8TfyEaA4OiBfvyyEllOPlg4Y7LZD79E2q/sz7dXx42d/FmwwrUKJt+aIPcE8NIPEwdeShuVTXPexyc3JdJAPDDKoLb2xKJE1RBgAcmbUxlqJu0AkY87DmRbHf80PJAHzRPjIwZ2Ax4in8rVZ3uA9nPDmTCZq2XJefS7ZD5TCaVm7WLYjWf0QoSGTYQsywBkrBnCZwTJXHnw0zYN9gt9WnLXpUP9nb2NwIpmiW0Kij/kaKH4Ovd9HBMOv5i8V3dWIxjua14uS+Klw1L133weVwmVuqHwf+U0KE5lg4FmQyRSkPnPOonlZ5KgSZ6lUQH82XZL87Jjo14iV5iQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650803819; bh=0OLXx8/4LC2oSd9NMIWNT2w+mJeACRcwaf6xWzmj/v/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FD6Q45iw5uwKII0tzQveBUQL9XrSCgAlr3Yb5RCq6rJiPPWnzOXw8ycyI99tGXqgKlUy8TsCLiDk8B+9GnI05Tvugh0DDJwSqysRbabI2IwG840BdZM+GIJMIQieUOiPmA1gzpyr7zrmQiadm1/Z59O2cO1k6eTWaNDfyjrnTuUOiUXsDPLZ8wtgCpUnXprFCx+3mp2U3gfgzh/Z8sLPGtopDzMAhGfITumcYd+XfQgEgmgRTs4acJKeFVo/wWEg3Xg6ZmcyfQM4sTnQtwsRm/Xl3sGrY2PLH7Vw21b48tgddBj8fYvulOJud8/YfaTyRidHJSXRFLzBZTj0A17Plg==
X-YMail-OSG: hv3SquQVM1mOgde9fYXJfsguCixhAiGj8aaOnl6Vfj631hJAwpX0UhoDJtgK1EK
 9PSDDMKn6ZRremm0kiKUoxLaCEWrHvN8VQikbnPiB.DP9EDohWxwQsrv0SnW8_GeXTvrGsWiTsNx
 AXKZ49.9BFQRSWtTdExJwAh0tRjVqSRWCMbcoR1.u.X1B4MF2PDEMxcELingLVL3_skWBespWuFK
 gitTU_Axdd47fj_.xaFc0b7edaFKjbTPiZfptZgpawPcFIrXK.tY8JBcV57Qlp1sVUdg7qXwPkjR
 18C.QDPFJFSnM7SKRlWnf5n30j5KNTIDKH7qUUMInLxLcJE7SdCv4kLuOxc5qW0Xt_wNgryntg.O
 aTc7RWBApimZt_a9rUfY7CnpGG3hlRqpE72MPh93l3_HcVIxta4I12P3WxjEC4388KQUN4PIuMeu
 v_HAVrdHdB4HtgEo0Y6Chfbu2R0QLxQfiImIIgPsLFpW1V.ytBA5_flG6_LnU.3wvjKkImbI0oVF
 P0dLetyIzUBKEotJBHdzvrAKIJo6ye8mkXD.M1MnKW1h9xDZnu.0RntaMqzC6xXDYsyEfkIvVbcu
 ROpw6TGLuOT9E2EntvVm1LtBlKUX1TJVo2jC634.xPZhhkLWEaYZpdoCiLAj3xilL8Uoy3yzGf2D
 EXtb3u6WsmCemrujDcT7BSx.Df_welCunT3aVTfDGKYZOzm4M9kyIiG17Y929h3vFC3Nbsv0gJMh
 ML4GyCJEANRZWsseAtbGLzeubTN39feXfARWJwQ8x3FA_RVj4jyaxf8H1N0.vgYW7gVcdKzrpmD0
 SCQ6fDNkQJbt3Rhx1YCaKErLJS0VRpFveyaliVl8yd5Ua7xxDbjU6flCYzy1yXys.g9mUQKP2YGz
 UcYzXthD5EsxsyIVqBBaYyFwrSWikdRsOlQORyAZtsVtLGA3BeG8i4NO3nMci_tx_JYBho734HsP
 qn2D7WOqy12gyL7BW.Qp9jo7jtTSNkzUpkAulbDiJUnfWrbcx7gaG1kkcHrV9yb0bkdjKbPVfA8t
 4cb2uWoggdo7GBJLESRw0Pyw.bxnM5Pz9AKoMGu11r9h7c2P.PHPLAO2KQLSTTbaA2mwAG1mQrV9
 PE.jFFkPfw2uOlSb0cCNXaYopBsDOu.Pt41y1ZA7BDkhm6mEoe8Zh5skrrw8NvCwQ8R_76q5.u_A
 kOFkvPSv34ARdNMQLpE0XgOtwFU730IGtrLNcgiE1BidiRc2Lhkox1CK_yLvyPHN3UAaN4VboYk.
 eT.8RHdk9pWgg465axDFe2Cpo26NitBJ.i_UEYN0tWSg3xgzBwZuVBikAiTFa50NvW_YlNivWVEx
 aF_QhHMbNeQdr1UVBzPQnV7QkiBz957yKWKIXVEJ4U4kOcBJ5ZMxB.hnYYkcr.qxFdhMrgM4xic_
 OUWdDJ.vwpxjosoCtKJWaucszKnOo9NBg2q2D_FUD1HwvLoLQNcM0yWl20LP4Agwm0fMLpx_jk1Y
 9c1UfogKA89t8_q1fmZ0PXVa8Qe1mem0VwroPtd8kscIW8iQTFObedgmH7jX77WRqRqiN90FVFCh
 kX_Z9EaMNpvJ.hAGr3lu_uG5LiEIrrE4xDGkH.Qv8vQY70uJ3HvGx2gwS1PUtIMihq6TmnsYbrAk
 fOLLIrXD3VKpp7MikKXcqOAALAtabCti24sALrvyBmmp5alZNJvlfRpKjd5TncVNVi_XHv5zPEBv
 gC6_.kGZyeqpQKemEzWtd2lXVWoR4NIZkwctso3Lq2fjrIPDSHLEf5ho3JpfB1YAcgdYLU3KU4H3
 i7RYwvtVRVCjExHY4OxR0ZblTsqrDtyVYs8CtRf.PQKSymhooJuwOuVnE2JWzfm3IMRWSUKtAfvI
 RuGJ5Ezl8MNgrItqBstDPLN6XeN2gQpp5BPrf7GN9n.du_8hyitAtYP59FXNoUiTlg5wAzUkOHi1
 qkW0X3DSQVTK6mTFB7cJ4x9wpnMVsjxBuTiKZmrSYP0bWZGZXiEOgHBMHvntXSyR9tdDr2Z3C8Qo
 34r.mzL5P4wB6LhSGlQ9Ft_EM4aIyAbzaADEzgEYMLnTndXC6dIjNUh_MGigTn_r_CIf9.58GDR_
 sdMdOJcdlakV801ITHMI.iIWz2zvGFbb6viGuws9dMydz4DknuaJZpv445h9ThfB9A5RKfa7te6T
 NXBT3H6wxQlcOwueDQst4ijhGlQLvcg6pp_UUTOpvwhuueYFAOOytcosLTHVpTw7_nXZlR0KkLwn
 JGTrGrtAPPxvJJe2jws.K4lxtcffZ5HmdPQaJNBMfjevUv0DxEFgfifA099Hj86YK7BW86tP9H0m
 qToMuXzkxqUQ-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 24 Apr 2022 12:36:59 +0000
Received: by hermes--canary-production-ne1-6855c48695-8fndv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 97e339246d040fdc300b7eead262646a;
          Sun, 24 Apr 2022 12:36:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi* firmware tagged 1.20210805 appears to be the last to be
 bootable by FreeBSD via fdt use; sequence of 2 failure modes after that
Date: Sun, 24 Apr 2022 05:36:56 -0700
References: 
 <836019DE-531E-4B49-8A82-0D8F84885C21@yahoo.com>
To: "freebsd-arm@freebsd.org" 
In-Reply-To: <836019DE-531E-4B49-8A82-0D8F84885C21@yahoo.com>
Message-Id: <8291972B-A953-4FD9-AA67-9F1F15AA3940@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KmSMQ4rh5z4mtb
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=FsZqBpj8;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.13 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	 NEURAL_HAM_SHORT(-0.63)[-0.631];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 87729
Lines: 2264

[I may have also found what leads to the extra messages for
the 2nd failure mode, an independent issue it turns out.]

On 2022-Apr-24, at 04:37, Mark Millard  wrote:

> [I think I found the reason for the boot crash that is
> a common failure to both failure modes. The 2nd mode
> has other issues I've not analyzed.]
>=20
> On 2022-Apr-23, at 23:45, Mark Millard  wrote:
>=20
>> The following is based on a microsd card with 13.1-RC4 on
>> it were I'd previously substituted my U-Boot 2022.04 build
>> and tested with the RPi* firmware that is in the 13.1-RC4
>> image. Here I've tried replacing the RPi* firmware and
>> holding the rest constant.
>>=20
>> The boot tests are on a 8 GiByte RPi4B Rev 1.14 with the
>> B0T stepping. I've not been copying over the linux kernels,
>> which they also bundle with the firmware.
>>=20
>> [13.1-RC4 is just what I happened to use. I doubt anything
>> here is special to 13.* or stable/13 or main [so: 14].
>> (I do not use 12.* or stable/12.)]
>>=20
>> The observed status went like . . .
>>=20
>>=20
>> firmware-1.20210805/boot/
>>=20
>> The RPi* release tagged 1.20210805 is the last version that
>> FreeBSD booted with. (Other than booting, logging in, and
>> shutting down, I've not been testing other aspects of
>> operation.)
>>=20
>> =46rom what I've read, firmware-1.20210805/boot/ should be
>> recent enough to handle the Rev 1.15 related PMIC variation.
>>=20
>> [I'll note that firmware build dates need not be the same day
>> as the date encoded into the tag --in fact it is usually some
>> earlier day. On rare occasion it can be a lot earlier, and
>> there is an example of that below.]
>>=20
>>=20
>> After firmware-1.20210805 there are 2 major failure modes.
>> Both stop at the same sort of point in the messaging --but
>> there is a huge difference in the count of earlier error
>> messages. It looks to me like all the issues require
>> FreeBSD changes if modern RPi* firmware/dtb's are to be
>> usable via fdt.
>=20
> I've noticed a difference between the working context and
> the failing ones (both failure modes).
>=20
> Failing:
>=20
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> NOTE BELOW LINES MISSING HERE.
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
>=20
> Working:
>=20
> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> START LINES MISSING ABOVE
> iichb0:  mem 0x7e804000-0x7e804fff irq 26 =
on simplebus0
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
> bcmwd0:  mem =
0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on =
simplebus0
> bcmrng0:  mem 0x7e104000-0x7e104027 on =
simplebus0
> gpioc1:  on gpio1
> END LINES MISSING ABOVE
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 73 on simplebus0
>=20
> In particular:
>=20
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
>=20
> being missing means no bcm_dma_attach and that in turn means
> that the static bcm_dma_sc =3D=3D NULL still.
>=20
> The panic was: panic: vm_fault failed: ffff000000862134
>=20
> where:
>=20
> ffff000000862134  ldaxr  x1, [x9]
>=20
> which is part of:
>=20
> int
> bcm_dma_allocate(int req_ch)
> {
>        struct bcm_dma_softc *sc =3D bcm_dma_sc;
>        int ch =3D BCM_DMA_CH_INVALID;
>        int i;
>=20
>        if (req_ch >=3D BCM_DMA_CH_MAX)
>                return (BCM_DMA_CH_INVALID);
>=20
>        /* Auto(req_ch < 0) or CH specified */
>        mtx_lock(&sc->sc_mtx);
> . . .
>=20
> So the likes of &sc->sc_mtx end up being a small offset
> from address zero:
>=20
>  x9:               20
>=20
> Thus the panic.
>=20
> As to how bcm_dma_allocate happened without bcm_dma_attach
> happening first . . .
>=20
> The working context's dtb has the ordering:
> (I also show mmcnr@ and the brcm,bcm2711-dma
> just for reference.)
>=20
>                dma@7e007000 {
>                        compatible =3D "brcm,bcm2835-dma";
> . . .
>                mmc@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                mmcnr@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible =3D "brcm,bcm2711-dma";
>=20
> But the failing context's dtb has the ordering:
> (I also show mmcnr@ and the brcm,bcm2711-dma
> just for reference.)
>=20
>                mmc@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007000 {
>                        compatible =3D "brcm,bcm2835-dma";
> . . .
>                mmcnr@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible =3D "brcm,bcm2711-dma";
>=20
> So, for sequential handling in the failing case, the dma@7e007000
> would use bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach
> sequence had happened, leading to the crash.
>=20
> Note: I used "fdt print /" from U-Boot to get the dtb and its
> ordering. This was based on the address that the RPi* firmware
> reports when debugging output is enabled (0x4000 here).
>=20
>=20
>> The 1st mode happens for (I've added the -fails notation):
>>=20
>> firmware-1.20210831-fails/boot/
>> firmware-1.20210928-fails/boot/
>> firmware-1.20211007-fails/boot/
>> firmware-1.20211029-fails/boot/
>> firmware-1.20211118-fails/boot/
>> firmware-1.20220308_buster-fails/boot/
>> (The _buster one has firmware from 2021-Dec-01, which
>> is before all the tagged releases listed below.
>> It looks like the switch to the new major kernel
>> version after buster came with other changes that
>> FreeBSD has not tracked.)
>>=20
>>=20
>> The 2nd mode happens for the following. (Again with extra
>> notation.) There are a lot more error messages before the
>> panic happens for these. The firmware builds for these
>> are more recent than for the above list.
>>=20
>>=20
>> firmware-1.20220118-fails/boot/
>>=20
>> firmware-1.20220120-fails/boot/
>> firmware-1.20220308-fails-non-kernels-same-as-1.20220120/boot/
>> (I did not repeat the testing of the unchanged firmware.
>> I just did the "diff -r" to discover the lack of change.)
>>=20
>> firmware-1.20220328-fails/boot/
>> =
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files/boot/
>> (Since the .dtb for the RPi4B was different, I did test this.)

It looks like the extra messages, blocks of:

clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6

Are tied to new dtb content in 2022's dtb updates:

        cam1_clk {
                compatible =3D "fixed-clock";
                #clock-cells =3D <0x00000000>;
                status =3D "disabled";
                phandle =3D <0x000000e2>;
        };
. . .
        cam0_clk {
                compatible =3D "fixed-clock";
                #clock-cells =3D <0x00000000>;
                status =3D "disabled";
                phandle =3D <0x000000e4>;
        };

These 2 did not exist back when the 1st failure mode
started. They appear to be repeatedly processed from
not really being handled --leading to lots of
messages.

The messages may just be noise for activity that is
not contributing to boot failures at all. So fixing
what I called the 1st failure mode might actually fix
booting for all the firmware versions after the
version tagged 1.20210805 .

>> The failures look like (each test shown) . . .
>>=20
>>=20
>> firmware-1.20210831/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20210928/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20211007/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20211029/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20211118/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20220308_buster-fails/boot/
>> (The _buster one has firmware from 2021-Dec-01, which
>> is before all the tagged releases listed below.)
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210251776 (7829 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
>> MAP 39f30000 mode 2 pages 1
>> MAP 39f34000 mode 2 pages 3
>> MAP 39f38000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> psci0:  on ofwbus0
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f89a40
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>>=20
>> Below are the examples of the 2nd mode of failure . . .
>>=20
>>=20
>> firmware-1.20220118/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210247680 (7829 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
>> MAP 39f2f000 mode 2 pages 1
>> MAP 39f33000 mode 2 pages 3
>> MAP 39f37000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> regfix2:  on ofwbus0
>> regfix3:  on ofwbus0
>> regfix4:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> psci0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> regfix1: Cannot configure GPIO pin: 5
>> REGNODE_INIT failed: 6
>> regfix1: Cannot register regulator.
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> usb_nop_xceiv0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f8b120
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>>=20
>>=20
>> firmware-1.20220120/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442929152 (8051 MB)
>> avail memory =3D 8210247680 (7829 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
>> MAP 39f2f000 mode 2 pages 1
>> MAP 39f33000 mode 2 pages 3
>> MAP 39f37000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> regfix2:  on ofwbus0
>> regfix3:  on ofwbus0
>> regfix4:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> psci0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> regfix1: Cannot configure GPIO pin: 5
>> REGNODE_INIT failed: 6
>> regfix1: Cannot register regulator.
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> usb_nop_xceiv0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f8b120
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20220328/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442920960 (8051 MB)
>> avail memory =3D 8210239488 (7829 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
>> MAP 39f2f000 mode 2 pages 1
>> MAP 39f33000 mode 2 pages 3
>> MAP 39f37000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> regfix2:  on ofwbus0
>> regfix3:  on ofwbus0
>> regfix4:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> psci0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> regfix1: Cannot configure GPIO pin: 5
>> REGNODE_INIT failed: 6
>> regfix1: Cannot register regulator.
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> usb_nop_xceiv0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f8b120
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>>=20
>> firmware-1.20220331/boot/
>>=20
>> ---<>---
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>> Copyright (c) 1992-2021 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 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> VT(efifb): resolution 592x448
>> module firmware already present!
>> real memory  =3D 8442920960 (8051 MB)
>> avail memory =3D 8210239488 (7829 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
>> MAP 39f2f000 mode 2 pages 1
>> MAP 39f33000 mode 2 pages 3
>> MAP 39f37000 mode 2 pages 4
>> MAP 3b350000 mode 2 pages 16
>> MAP fe100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> clk_fixed2:  on ofwbus0
>> clk_fixed3:  on ofwbus0
>> simplebus1:  on ofwbus0
>> simplebus2:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> regfix2:  on ofwbus0
>> regfix3:  on ofwbus0
>> regfix4:  on ofwbus0
>> simplebus3:  on ofwbus0
>> simple_mfd0:  mem =
0x7d5d2000-0x7d5d2eff on simplebus0
>> bcm2835_firmware0:  on simplebus0
>> ofw_clkbus1:  on bcm2835_firmware0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> psci0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
14,15 on simplebus0
>> gpiobus0:  on gpio0
>> gpio1:  on bcm2835_firmware0
>> gpiobus1:  on gpio1
>> regfix0: Cannot set GPIO pin: 6
>> REGNODE_INIT failed: 6
>> regfix0: Cannot register regulator.
>> regfix1: Cannot configure GPIO pin: 5
>> REGNODE_INIT failed: 6
>> regfix1: Cannot register regulator.
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 13 =
on simplebus0
>> gpioregulator0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality =
1000
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> usb_nop_xceiv0:  on ofwbus0
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e2011ff irq 16 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b464
>> x2:                0
>> x3:                6
>> x4: ffff000000fbf77c
>> x5: ffff000000fbf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fbf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b612
>> x25: ffff0000008dfcfc
>> x26: ffff000000943716
>> x27: ffffa00000f8b120
>> x28:         31e00000
>> x29: ffff000000fbf7e0
>> sp: ffff000000fbf7e0
>> lr: ffff0000008680a0
>> elr: ffff000000862134
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff000000862134
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>=20




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Apr 24 21:00:57 2022
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 53784199D67F
	for ; Sun, 24 Apr 2022 21:01:00 +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 4KmgXp4gvsz4xG3
	for ; Sun, 24 Apr 2022 21:00:58 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 B267E59C4
	for ; Sun, 24 Apr 2022 21:00:57 +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 23OL0vLp001850
	for ; Sun, 24 Apr 2022 21:00:57 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23OL0v7Q001849
	for freebsd-arm@FreeBSD.org; Sun, 24 Apr 2022 21:00:57 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202204242100.23OL0v7Q001849@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, 24 Apr 2022 21:00:57 +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="16508340571.E201.99744"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650834058;
	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=jW5EYkmgiZv6RQ8RNWHZDoSgvxl4jpwGxD+i4sOoIws=;
	b=TUimA0ZQd4+P0oRe2YV9xpBTfMv5MdcqJdVCog+5HWyQJqAoVcj+iHsug4w+hVany1fxnE
	pOfn78bgIO67PnCRuXfncbQFEfJuNqPTUo4lhvdwtXQmamOEeDSbGyvIbeYhZ5puoXspjY
	DMN0STAIB73jMPm10YFZ2HeYQFc/FHqDxxbjXenUDdTDvVQWgRhJ6OCjDAWKPbRNk+1nmw
	hZW4L+J9FxIt7rq5miRU4gYhLckM2JwfElcStahF+JiZYGfHuuB38Arwaq5lNei4uw7tdP
	+2M8eHAwm8azfkTYVs/I2ogw+UWRok9JVD77ZdvRsKzlExgvbtqsm6EeQRJPXQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650834058; a=rsa-sha256; cv=none;
	b=uDrij9evtMtiveA/SqP9lz42x3MuyU3T9H58NkWPKyIzYqy5rmtpYLTy0UxmxeWY4iMx2n
	6d9f/77wDKgLl7ID8frG+uF6CaQCcQVO+npDePAkjU/AVhJQIbeXC1MS+t56VJEFoQEf3i
	5ylKpToOTnTGlgncy/bt3YBrAfugUrsBWBnOtph4GK2SoW7KC4OdrihnVLE3R0zSud+QD9
	rK84cuea+//Fzb7pGKtXsE5xRzccuAqvl+u/hNvqtBTG0XGdEnJQcs5hEtl9JSDzm8T9ER
	tSD78u7HyDaEF555iTH7hSqWMj0PkAqrYb7YNa8GH0HK3CL90cO5fC767hTMZw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1795
Lines: 38


--16508340571.E201.99744
Date: Sun, 24 Apr 2022 21:00:57 +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.

--16508340571.E201.99744
Date: Sun, 24 Apr 2022 21:00:57 +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.


--16508340571.E201.99744--

From nobody Mon Apr 25 03:07:19 2022
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 9B780199E00F
	for ; Mon, 25 Apr 2022 03:07:19 +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 4KmqgW2H2gz4X19
	for ; Mon, 25 Apr 2022 03:07:19 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 EC56613042
	for ; Mon, 25 Apr 2022 03:07:18 +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 23P37I73097388
	for ; Mon, 25 Apr 2022 03:07:18 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23P37IHP097387
	for freebsd-arm@FreeBSD.org; Mon, 25 Apr 2022 03:07:18 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 222062] unknown file system -> mountroot when booting aarm64
 from ZFS
Date: Mon, 25 Apr 2022 03:07:19 +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: 11.1-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: kevans@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not Enough Information
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status cc resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1650856039;
	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=ySr/VkSXSH/yKwNlW4TuWaxFDGQzcNMtYhoILdQ/7YE=;
	b=N+mYU6LETf9Z1sbCFXugEMHu1wlg4OeWUsal2jZMhRKZwDYw2LEfNoErnlx4+ypTkKIHqh
	VJirTvTlFB8Z8lU0EFXbYsrmAaVe+tbjnN7Y4GFG78F3NpQGA3G3awtXirVykQvx/Ph2iU
	G/33wlRrbHg7eV7mRRou8MeHFaT6QeyN3pMaxt3Ydq4g3MeGVivHzHzqZh8Uvz7NRpg1jj
	rJzmcvX0kVE3Oe3zzdygf1GGT40nwvZ4UzlzunrEIzkgfge67fHtF364rqlUVRHtlb5o0F
	+qn3UBMKcyXPalWMaW3X+bOeXe7dFfUHhRdEE9AOrs7U+Pt9lhniAJP6MFUiWQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650856039; a=rsa-sha256; cv=none;
	b=dndIXAUnbFjbjLGdNfVj/6p8UPrB72ZiSrC75JyRFhoEAY8J/XTX68S6bLjTmwIZdIlTEx
	NbakOQrp6HG5jBVPWw/Kcl09HAtvzlezHa06VdYmA5RHzjjXTy4CTiOhQSjoNnImue/ctl
	OSZQ8d/eRNUXQFjTBlZg++6nMIuQQdIEdtUrk5Xs1oSRmq/fEJ9hS8ZGV9sq3+2whNoTyK
	OwuiQ7XWVOkT0qbq8gjR94d4IRr3x2F7bciECeRDyj2ZfrfxJ0GoboYnBJc+fbtAKeG6nu
	UGt3Dvco9zky3vrmhCkGKfdmDyHZ82EYL78A/UpwBphEw+tdfLaKy6/c5E7Piw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1018
Lines: 25

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222062

Kyle Evans  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
                 CC|                            |kevans@freebsd.org
         Resolution|---                         |Not Enough Information

--- Comment #2 from Kyle Evans  ---
Ditto Graham's question, also: please confirm what modules get loaded in
loader. To see this more easily, you can drop to the loader prompt (3) and
issue a `boot-conf`, then interrupt autoboot to record what's there before
issuing a `boot`.

The last comment was over a year ago, so I'm going to go ahead and close th=
is
with "not enough information," but please feel free to re-open/respond if t=
his
makes it to you and the issue is still relevant.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Mon Apr 25 04:31:18 2022
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 777561A97C16
	for ; Mon, 25 Apr 2022 04:31:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c])
	(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 4KmsXm48NHz4h3F
	for ; Mon, 25 Apr 2022 04:31:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-qt1-x82c.google.com with SMTP id bz24so9606094qtb.2
        for ; Sun, 24 Apr 2022 21:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=zqvpo1cSQ2z9sVLY/CvtXiLXTDTO7EAUKZLT0wtCvZg=;
        b=ZOSVlUN7KUw8M49J1lqZxBYD/YVKX/hpYCKKkERqHisRjkRSCejfLsW0uLyGbSpZAq
         Ti6NRKun/1vwK7rhK3+UR4w907H6RUFby1FQrXlDH2hBRe9xbDzHJ1sPG8JjcGpPH0j4
         flAqsfT6rj4HnVx/vCPlYaJ9FH6gtR69QpFVVtgkgStU68L54WnNkLVNJv0MREKpLf76
         Y5J1MdyI02UmfkpOqwP34O8xpi1doBsWdCr3A34oj705yg7qMpxai+7FtezNo5herot/
         gHSXYOJl46kNQPItzk7Y/GaEzZNsysCt3gFCHKfgNSYMM9E+OhMIE7ebrvCRAgziMwSm
         rUWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=zqvpo1cSQ2z9sVLY/CvtXiLXTDTO7EAUKZLT0wtCvZg=;
        b=TATQZg8I1t5MtwOH+mt7RcUwo8Sf3A8TRjSI5O8bk39UKhIEB7VPsB4NvfLVK6oNF0
         i3nBJE5l+8uziiaOHSFDlMIHcSQaKW0f5tloMW55g5qDDb750e/ks9rRAEdcJSJYygJp
         jIjhS20pmi0Lqx8AJqeKTCnxPsxhvfs6LpeoGQKKu1MCH3/6uqgl+TtXUVk7UbKf2c+h
         hRLAog5QsA9wsaH7HMloiRyJJy8c3MeOpg55b3L3de4oaHcCDg2dXrLwnJWoupK2RwMs
         QLIQQtDqhuWsndLvPjIkwKpxE8oNNesQu8S8HoJorRlfOsldXPTG/eJqU8hTdbccH31k
         FmLg==
X-Gm-Message-State: AOAM5324A6yYwWSfsuSiBlILXKmGtrxB6tO5NCfIBLo9UBzHbLDdwvDn
	WK+t5mtOChB3zW0dfJeZe7w0lqA9Xf30W+1/FK66EZN/9iM=
X-Google-Smtp-Source: ABdhPJzmAlk0+iIY2ysqYDpIwkqZH/U3UX6t5uJ3SWQP5CSuk8+A+pC8XxANFuLVXCn93zLB22oToiYOMyzDkcUG7vc=
X-Received: by 2002:ac8:4e1b:0:b0:2f1:eabf:e3de with SMTP id
 c27-20020ac84e1b000000b002f1eabfe3demr10629564qtw.415.1650861090384; Sun, 24
 Apr 2022 21:31:30 -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: 
 <1650690954159.808787254.1998474368@optimcloud.com>
In-Reply-To: <1650690954159.808787254.1998474368@optimcloud.com>
From: Archimedes Gaviola 
Date: Mon, 25 Apr 2022 12:31:18 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B USB Printing Issue
To: BSD Devel 
Cc: Hans Petter Selasky , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000ddae9105dd730c0c"
X-Rspamd-Queue-Id: 4KmsXm48NHz4h3F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ZOSVlUN7;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.989];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1398
Lines: 36

--000000000000ddae9105dd730c0c
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 23, 2022 at 1:16 PM BSD Devel  wrote:

> And another WIN for Archie! cge go go go..!!!
>
> Dingo...
>

Hi Dingo,

Oh, what a small world... it's been a long time :-)

Regards,
Archimedes

--000000000000ddae9105dd730c0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dingo,
<=
div class=3D"gmail_quote">
Oh, what a s=
mall world... it's been a long time :-)

Regards,
Archimedes





--000000000000ddae9105dd730c0c--

From nobody Mon Apr 25 09:47:39 2022
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 7FC7B1A89835
	for ; Mon, 25 Apr 2022 09:47:48 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1])
	(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 "amnesiac", Issuer "amnesiac" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kn0Yb0lJyz3qmZ
	for ; Mon, 25 Apr 2022 09:47:46 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (localhost [127.0.0.1])
	by fuz.su (8.16.1/8.16.1) with ESMTPS id 23P9ldsl040332
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 25 Apr 2022 11:47:39 +0200 (CEST)
	(envelope-from fuz@fuz.su)
Received: (from fuz@localhost)
	by fuz.su (8.16.1/8.16.1/Submit) id 23P9ldW0040331
	for freebsd-arm@freebsd.org; Mon, 25 Apr 2022 11:47:39 +0200 (CEST)
	(envelope-from fuz)
Date: Mon, 25 Apr 2022 11:47:39 +0200
From: Robert Clausecker 
To: freebsd-arm@freebsd.org
Subject: _Unwind_complete
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-Rspamd-Queue-Id: 4Kn0Yb0lJyz3qmZ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su
X-Spamd-Result: default: False [-1.41 / 15.00];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.88)[0.883];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[fuz.su];
	 NEURAL_HAM_SHORT(-0.99)[-0.990];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 551
Lines: 15

Many ports from the ports collection fail due to an undefined
symbol _Unwind_complete.  It appears that this symbol is an
EABI symbol used as a part of exception unwinding, but I was
unable to find the relevant specification with a short search.
Neither is there a hit in /usr/src.

Do we provide this symbol?  If not, what would be the appropriate
place for it and who do I need to poke to have it added?

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From nobody Mon Apr 25 12:00:42 2022
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 2CE22199C5CB
	for ; Mon, 25 Apr 2022 12:00:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kn3WC6bzdz4bBV
	for ; Mon, 25 Apr 2022 12:00:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650888048; bh=ZRlOz5wdCd4QjJp3KEhYnDH0+6HcTEt9rxJaDomO1U8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=flejYVBZM6fqE4qkN5kHNK9FhVIPe4EsEOu6ZRYR/V78r5FX11RkW2QQTt1dY3KIs554vHHenZ+rkN/UfekERWq4qQKb3tisqmFlVN5GSjgRYHokm4aJOID8dP9rRUMnjquoAS+T3E3KleKMngAFPz2TUq3yDLGXxnJdVtA0anBsdcudNOHOdVBQw8zfQC+ZIzEUclFgPoh9SSXikncKHBfqySkvWTX5jKPYG2IJYQ93QNwlrkDLoG0EJCM7FBvGocrY0ImmW3GQXOfa0I0fPajbOjD1iNwRBZxBehRe9eO6gDWvEvSsVR7pwv1QFg1C0xn6NqlbozPFWrJt4hO3bg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650888048; bh=19DJk3OmpAcNbCiyXQHYECCGsQTVq26f+HFiWWxBPXi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=V0RjIsvN+DBfK6UY/n3uRS3ahLktlpX8iGcTRaDJYl1t8tCoYtZ8CsjeApvUzGm+f8S3xyv3tDyw/3eqjP/aOGZ8y2UV/ukVCQWG9DHZlBajC9KDGL3mDvwzOK7by9wzTYjCCx5F+8vOlEWQsaX7S67JOY1HMc/2uHKC0C49mAYr/LUIojyLCKcpKL2q2JWtBrwE1Gga4DMNyT9sQNCIY7umjPD+G6DVFur9OwPCe4trUAVsejVkb83ZKRozYLja7BpdXPmyTT7U9QzZSsQCwKdHvZoD0plZ8YyK3yj4KIHSywqHL4y97rT/XHvqGGaM15QLDNgBlpKeaa+uW5xIFQ==
X-YMail-OSG: HfDlJnsVM1mIo3bq6kKdM2zbiASncIzuD6qOB1OKvRXr6YQQb1Ev8RCfJILrGJa
 IhfS9tDFdOvI9E0WWF9qz6jvruoWlkz.moKwMNU7YlAj2_94QVO2sDQsfjqDxoXrodpdL7WXcCdo
 il30gVsCwzQHFoZJ9rgXAnOqfrIWCw3sS13dBqeQ9mTqwRYrN.cJM.73mIGz386cQCYZtQl5.oT2
 QQhpEFt4CpKUWKNEtt2QaiCRAomqSZUlqCiQ5ACYpBe0xoWh3GTBlAlDEksHpmYtdwBmvEhUgnYK
 vnKxjJ9pN51E..6HzTnj7lCV33kPAssEqUG1bqqUaItRCAHehpOPubSTX5Z3zb9iLPau99EOsiun
 LUuI4K8bx4BkKPDArAbpJsgQGr183gToaPFzW4hEtUQgXRh.oxYj6J60ixQYVmFW7wHWLOnZCnHx
 dNafk9Ah4cefVC61CoIGbGRtM3R.thFS.JclW_Bt1Y_RM.CgsaBMPZb6Lp1XkHsqSehLLiUDeZ.Q
 7xVX07o5wIYslU6bozOMPXsVtxCSAnPKfwb9ua79L1JAgpcB0blVax3S.KXUEY0QrfQlvpqF8R4u
 wGNL6APedRvMcvU3lYoMi8Di4I7atpVusbl4k2tKf6oPCEmdzKJVNkh6BA5_BV_Cx1L79sfDkjun
 5NJ7qKfLKdb7pZ2e3J.pQZ59ad82YKMhQTqvCbkhYZuUicyJ0gOPyAa3rhHiXS0hVQfyNKLhQIgM
 J1VUf1l..oG2nVgYiOaK9loT4M.4DpjlyzbIKVkv15rneuscBZp2hjCMn59sCnYKIlhR4XgPvgif
 hYLXdseZqoUM.N28sK61izgIr17f9rEp5xUU5Tzjf1Eu6intGQO.o7bLgWMaIezoSA8DdSAECFkw
 .PODuUleNObDQQEAAQlG1vct9RhEi1411UaE1d3mAN7ih5V2SQTbh15KZNIBKyJdiovuh0BCyUK_
 lMHubB7KwmY_laVjLUiixmmWK8AkriWKRYoff7r7Bf2tHEAkGQlNtiuDT.1d21pxf40MJRPG03_k
 TrbuOND7roS0kLdUxpWjEdG_.LG3EVyWfOqMj1Pild.x.7hA71K0pxTVeZAvVN9oEXsTjm2ngyPJ
 By52HPBkJ14jnffPXdbfRy4_J2WdxXJslHipbgQw7wTqymICm.y7KslRntf3ToJfWZgDUivruLJK
 6TVSn24CSEfBityVfbhMh52fuBTFbnwHvYrc3ZsMy.IbIF2jhWJ8nUnxEEpz1ZssiorgcvsIPN2i
 yIxRgvnjdJlx73p7_1swKDwEy261Wph5Yuv_qchhWY.TEBIlcm4wvSP1ATRVQveFMX09pADlHbKY
 vFb99ML4OtJ1x.69s0yrjSfTff4dDCj6wchWfhfX4KzzbDo9iHqkod6yXO9FTkxk7Vrh_mNn1IQT
 Y6SXHoVXyy3kL_ZM0Wp7zXsw6NcKWjUgC.VaUqIyS8hg8sjP_Ke4_5jzQaojKA_Mg_DmbPSeC9BV
 rKx04ZUZEC0WMUm28pCW2gdRNVkWxQoZANDsxY2xIOthz0OkdFBerVzK2T2QP7XBY9bFcxitouNt
 3_oik0vETmtvDdTXK5nGZORTpMd137Jy4Z9U.W7hm0X5JBaXYTXSGgpOXwsdahXDMbUJNo5qeM6W
 u_VkWHuAUojaCP4dX8U60R8XU5gnvUsob.AHuWv03RmKkI_fXBbD7._FXFXabr.sBzgj5garaGuY
 GXJfYKIOlcZ5jCv4.LObquNSQy9K4j35WZ8yndwuQWofNxl.neTjLp3JhyjL.AvY1x.YNfde.Isj
 Z4CqkS_f0sa0SYk1BzOasAYzd97qFzUHMkH5dEyiUW.SBEfNQMoSuhv8cCinRARXrLwizwohSQX6
 Yr1bUdQgsjHkz2NlPeT_3SAn31BdJzX16mHiUfqQwJCHGlIBcqDy9FhXK31odxRSc7KLMrr09aJ7
 rEABjO9AhOBK4pTUvl1jrBUMKDUfOsfJlRL3.LZ0P5_8gAMeydNM6Ac2VDwZXxky80jVvUPysnA5
 xC4271btl8xPnqH_ox5WOxOzbqcO4pwBgpPqB9sZaR1xiBjXclGb6ESvFzKDmJkxDjAhptPkJFVe
 DxwHXPYBrtWWaYCYAzI3UECRoZVWFlh9fiK69D_IvadH8u97yAjvjn3rifcfVSdZP2k9kBL_LJEl
 1RYrgQGqsl5QpreeT5s3Trpcs6HvHfU2QPElat1Cmplkk0hEdgRERVqBKpvUKn82wiFEdWgyZzJ9
 9uI0xHfSIizuR11WiC7x31zj3jvGnHJqK0V.2VEK93QBR9JBDcLEUsfep2v5miUdWP_AX96Hz94I
 rQArFSK6Z1tumSlA0
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 25 Apr 2022 12:00:48 +0000
Received: by hermes--canary-production-gq1-6b7487d8dd-qcdwd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dbb8a920dd1b310f33aa7cd0e54f89d1;
          Mon, 25 Apr 2022 12:00:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: _Unwind_complete
Message-Id: <91900DC8-2BF8-4D22-9058-2617DEECF83B@yahoo.com>
Date: Mon, 25 Apr 2022 05:00:42 -0700
To: Robert Clausecker ,
 Free BSD ,
 FreeBSD Toolchain 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <91900DC8-2BF8-4D22-9058-2617DEECF83B.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Kn3WC6bzdz4bBV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=flejYVBZ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.45 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.99)[-0.990];
	 NEURAL_SPAM_MEDIUM(0.99)[0.995];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from];
	 NEURAL_HAM_SHORT(-0.96)[-0.956];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5833
Lines: 194

Robert Clausecker  wrote on
Date: Mon, 25 Apr 2022 11:47:39 +0200 :

> Many ports from the ports collection fail due to an undefined
> symbol _Unwind_complete.  It appears that this symbol is an
> EABI symbol used as a part of exception unwinding, but I was
> unable to find the relevant specification with a short search.

=
https://github.com/ARM-software/abi-aa/releases/download/2022Q1/ehabi32.pd=
f

seems to be the kind of place where such is found these days.

> Neither is there a hit in /usr/src.

Capitalization mismatch?

# grep -r _Unwind_Complete /usr/main-src/ | more
/usr/main-src/contrib/libcxxrt/unwind-arm.h:void _Unwind_Complete(struct =
_Unwind_Exception *ucbp);
=
/usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:_LIBUNWI=
ND_EXPORT void _Unwind_Complete(_Unwind_Exception* exception_object) {
/usr/main-src/contrib/llvm-project/libunwind/include/unwind.h:extern =
void _Unwind_Complete(_Unwind_Exception* exception_object);

The middle one is an implementation:

_LIBUNWIND_EXPORT void _Unwind_Complete(_Unwind_Exception* =
exception_object) {
  // This is to be called when exception handling completes to give us a =
chance
  // to perform any housekeeping. EHABI #7.2. But we have nothing to do =
here.
  (void)exception_object;
}

> Do we provide this symbol?

CA72_16Gp_ZFS armv7 main-CA7-chroot 1400053 1400053 # nm =
/lib/libgcc_s.so.1 | grep _Unwind
00017630 T _Unwind_Backtrace
00017630 T _Unwind_Backtrace
00017424 t _Unwind_Complete
000174f8 T _Unwind_DeleteException
000175d0 T _Unwind_FindEnclosingFunction
0001773c T _Unwind_Find_FDE
000177a8 T _Unwind_GetCFA
00017530 T _Unwind_GetDataRelBase
00017828 T _Unwind_GetGR
00017894 T _Unwind_GetIP
000177cc T _Unwind_GetIPInfo
000174a0 T _Unwind_GetLanguageSpecificData
000174cc T _Unwind_GetRegionStart
00017580 T _Unwind_GetTextRelBase
000171d4 T _Unwind_RaiseException
00017428 T _Unwind_Resume
0001752c T _Unwind_Resume_or_Rethrow
00017860 T _Unwind_SetGR
000178d0 T _Unwind_SetIP
00016c58 T _Unwind_VRS_Get
00016794 t _Unwind_VRS_Interpret
00016e28 t _Unwind_VRS_Pop
00016d40 T _Unwind_VRS_Set

FYI:

         T       A global text symbol.
. . .
         t       A local text symbol.

So:

00017424 t _Unwind_Complete

is a local symbol, not a global one.

As for lang/gcc11 (for example):

# nm /usr/local/lib/gcc11/libgcc_s.so.1 | grep _Unwind_
0001cd0c T _Unwind_Backtrace
0001c0e4 T _Unwind_Complete
0001bde8 t _Unwind_DebugHook
0001c0e8 T _Unwind_DeleteException
0001cce8 T _Unwind_ForcedUnwind
0001bf84 T _Unwind_GetCFA
0000f4e8 T _Unwind_GetDataRelBase
0000f4e8 t _Unwind_GetDataRelBase.localalias
0001c15c t _Unwind_GetGR
0001cd94 t _Unwind_GetGR.constprop.0
0001cb3c T _Unwind_GetIP
0001cb3c t _Unwind_GetIP.localalias
0001cb50 T _Unwind_GetIPInfo
0001d1d0 T _Unwind_GetLanguageSpecificData
0001d1c0 T _Unwind_GetRegionStart
0000f4f0 T _Unwind_GetTextRelBase
0001cc7c T _Unwind_RaiseException
0001cca0 T _Unwind_Resume
0001ccc4 T _Unwind_Resume_or_Rethrow
0001c1e4 t _Unwind_SetGR
0001d484 t _Unwind_SetGR
0001cb5c T _Unwind_SetIP
0001c100 T _Unwind_VRS_Get
0001c738 T _Unwind_VRS_Pop
0001c188 T _Unwind_VRS_Set
0001bdd4 t _Unwind_decode_typeinfo_ptr.constprop.0
0001cd0c t ___Unwind_Backtrace
0001cce8 t ___Unwind_ForcedUnwind
0001cc7c t ___Unwind_RaiseException
0001cca0 t ___Unwind_Resume
0001ccc4 t ___Unwind_Resume_or_Rethrow
0001c210 t __gnu_Unwind_Backtrace
         w __gnu_Unwind_Find_exidx@FBSD_1.4
0001c034 t __gnu_Unwind_ForcedUnwind
0001bf8c t __gnu_Unwind_RaiseException
0001cb9c t __gnu_Unwind_Restore_VFP
0001cbac t __gnu_Unwind_Restore_VFP_D
0001cbbc t __gnu_Unwind_Restore_VFP_D_16_to_31
0001cc54 t __gnu_Unwind_Restore_WMMXC
0001cbcc t __gnu_Unwind_Restore_WMMXD
0001c050 t __gnu_Unwind_Resume
0001c0c4 t __gnu_Unwind_Resume_or_Rethrow
0001cba4 t __gnu_Unwind_Save_VFP
0001cbb4 t __gnu_Unwind_Save_VFP_D
0001cbc4 t __gnu_Unwind_Save_VFP_D_16_to_31
0001cc68 t __gnu_Unwind_Save_WMMXC
0001cc10 t __gnu_Unwind_Save_WMMXD

So for gcc11:

0001c0e4 T _Unwind_Complete

is a global symbol. (It is not the only mismatch.)

> If not, what would be the appropriate
> place for it and who do I need to poke to have it added?

As I Remember FreeBSD has had an issue where a particular
toolchain related activity turned some global symbols into
local ones as a side effect. But I do not remember the
details.


The above was after exploring the following . . .

If there a more specific context here?

All FreeBSD platform targets? Just armv7/armv6? Just . . . ?

All toolchains? Just lang/gcc* toolchains? Just devel/llvm* ones?
Just system-clang toolchain?

Just system-clang 11? Just system clang 12?  Just system clang 13? Some
range of those but not all? All?

Just in cross builds via the likes of:

CC=3D/nxb-bin/usr/bin/cc
CPP=3D/nxb-bin/usr/bin/cpp
CXX=3D/nxb-bin/usr/bin/c++
NM=3D/nxb-bin/usr/bin/nm
LD=3D/nxb-bin/usr/bin/ld
. . .

but not for native builds? For both types?


Attempting possible answers . . .

Finding that www/nift seemed to be an example, it only seems
to fail for armv7(/armv6?). Building in a context with direct
armv7 code execution fails, so not cross build specific.
It used the system clang toolchain.

Freshports indicates that the last build for FreeBSD:12:armv7
was of 2.3.10 back in early 2020-Dec or so (quarterly). No
armv6 builds are shown and no other armv7 builds are shown.

Modern 2.4.11 builds show for amd64, aarch64, and i386,
going back to FreeBSD:11:*. Even FreeBSD:14:powerpc64 (latest)
and FreeBSD:13:powerpc64 (quarterly) have such. (powerpc64
does not have latest any more for FreeBSD:13:powerpc64. It
used to. Thus the old version listed for that context.)

How well this matches with what you reference, I can not
tell. But it suggest something associated with the
armv7 toolchain is involved.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Apr 27 12:50:04 2022
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 429D31AAA63D
	for ; Wed, 27 Apr 2022 12:50:05 +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 4KpJW06VXyz4d9M
	for ; Wed, 27 Apr 2022 12:50:04 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 BB92F2431E
	for ; Wed, 27 Apr 2022 12:50:04 +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 23RCo4sN039783
	for ; Wed, 27 Apr 2022 12:50:04 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 23RCo4Dv039782
	for freebsd-arm@FreeBSD.org; Wed, 27 Apr 2022 12:50:04 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 263607] [panic] [arm64] [13.1-RC4] very early panic after
 Release APs
Date: Wed, 27 Apr 2022 12:50:04 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dch@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1651063804;
	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=7dtoyD6dAv71mve6gbAwMTXOU9LwpOt7V8L/dmJ9wr4=;
	b=riA+KT8338v2xFrAhCuk/oe26Q5VxW6j6sRuTkQn5gEmr724UckGpXVtrDTvGgYCnKRrhc
	YyDw27m2MVOeVJXDhvJ+YnqeFylGCS6KPmJS9e7Xx9dj+7Eg03ZBN4GoKMbqd8+sp3cOmy
	LrQjjLikD8rldrQKr85PooBzmd1NQZB91lO/HfjGsiLJashdd9DWK8Rze+miHzjxOrETIZ
	xy+nTXFqsa5jgcOLTkeo2Xkiy1NH3hpWSKwNPAmVrgYPAVvrFMkdbwx8uC2V1I08cgjFZZ
	tVwaRlxL/BGn/0hzRfeL648VFrEH/DlcXbQyaipoKTr4ZncgdXiyPEdDwdmJYA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651063804; a=rsa-sha256; cv=none;
	b=qWMKFB6Pe8P+LKdtf50MNJ7jdEX/e4tkCZdx+u//ERbBBY+JYAwqxsS2G4wrMWqfCMudtK
	vZW/eiTcsYHGZ5D5XitbYBuk0XS5rY1E2wOOukclG55nDyemXtcc+4wgTRtPpeuu8UH/vy
	quIK26nB1imTMCWkg/iYMX1itt6GuYhtlkrUd8puAA4YSa7yC6XaaudiSaNIjIF9J7RYnR
	WjnHLKRheZNbmL5GYVyIFes+8yJOM1GoLhxrW5eNU8UytmoxIpyfu2ulT8jxQRRS07I3QT
	6Fj7XcSxkG0MbD3Ig9XLshAbvu0+CK6nNzcznFTTEQTb3dgVQMt3J1Xcw4w4TQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5984
Lines: 202

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263607

            Bug ID: 263607
           Summary: [panic] [arm64] [13.1-RC4] very early panic after
                    Release APs
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: dch@freebsd.org

...
CPU 14: ARM Neoverse-N1 r3p1 affinity: 14
CPU 15: ARM Neoverse-N1 r3p1 affinity: 15
Release APs...Trying to mount root from
zfs:zroot/ROOT/14.0-CURRENT-20220329.190055 []...
done
timeout stopping cpus
panic: Assertion v !=3D tid failed at /usr/src/sys/kern/kern_mutex.c:920
cpuid =3D 13
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
KDB: enter: panic
[ thread pid 0 tid 100035 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>





CPU  1: ARM Neoverse-N1 r3p1 affinity:  1
CPU  2: ARM Neoverse-N1 r3p1 affinity:  2
CPU  3: ARM Neoverse-N1 r3p1 affinity:  3
------ sometimes we hang here for several seconds before panic --------
Release APs...Trying to mount root from
zfs:zroot/ROOT/14.0-CURRENT-20220421.064527 []...
done
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff00004038d000
cpuid =3D 2
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
KDB: enter: panic
[ thread pid 0 tid 100014 ]
Stopped at      kdb_enter+0x40: undefined       f902027f
db> bt
Tracing pid 0 tid 100014 td 0xffffa0000297f000
db_trace_self() at db_trace_self


Sometimes I get more, though:

CPU  3: ARM Neoverse-N1 r3p1 affinity:  3
Release APs...done
  x0:                0
  x1:               68
  x2:              101
  x3:                0
  x4:              201
  x5: ffffa005caec6e98
  x6: 1de7ec7edbadc0de
  x7:         768a5bc7
  x8:         deadc0de
  x9: ffffa0002195f568
 x10:                0
 x11:               1a
 x12:               1a
 x13: ffffa0002195f56c
 x14:                0
 x15:                1
 x16:                8
 x17:                0
 x18: ffff0000403af630 ($d.1 + 3ec80328)
 x19: ffff000040498200 ($d.1 + 3ed68ef8)
 x20: ffffa0002195ffd8
 x21:              101
 x22: ffffa0002195f000
 x23:                a
 x24:                0
 x25:                0
 x26:              101
 x27:               7c
 x28: ffffa00021960fd8
 x29:               fe
  sp: ffff0000403af630
  lr:               b9
 elr:               b9
spsr:         60400045
 far: ffff000043048000 ($d.1 + 41918cf8)


e123e2294cb50deb288916b79a8c05a006f8bca3 occasionally but same fails


CPU 13: ARM Neoverse-N1 r3p1 affinity: 13
CPU 14: ARM Neoverse-N1 r3p1 affinity: 14
CPU 15: ARM Neoverse-N1 r3p1 affinity: 15
Release APs...done
timeout stopping cpus
panic: data abort with spinlock held
cpuid =3D 14
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
KDB: enter: panic
[ thread pid 0 tid 100031 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>



CPU 15: ARM Neoverse-N1 r3p1 affinity: 15
Release APs...done
panic: Assertion v !=3D tid failed at /usr/src/sys/kern/kern_mutex.c:920
cpuid =3D 10
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
thread_lock_flags_() at thread_lock_flags_+0x1dc
sched_preempt() at sched_preempt+0x38
arm_gic_v3_intr() at arm_gic_v3_intr+0xe8
intr_irq_handler() at intr_irq_handler+0x80
handle_el1h_irq() at handle_el1h_irq+0xc
--- interrupt
data_abort() at data_abort+0x148
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
handle_el1h_sync() at handle_el1h_sync+0x8
--- exception, esr 0x96000006
thread_lock_block() at thread_lock_block+0x38
sched_switch() at sched_switch+0x12c
mi_switch() at mi_switch+0x184
spinlock_exit() at spinlock_exit+0x60
__mtx_unlock_flags() at __mtx_unlock_flags+0x154
vm_page_zone_import() at vm_page_zone_import+0xe4
zone_alloc_item() at zone_alloc_item+0xb4
vm_page_alloc_noobj_domain() at vm_page_alloc_noobj_domain+0xd4
uma_small_alloc() at uma_small_alloc+0x64
keg_alloc_slab() at keg_alloc_slab+0xbc
zone_import() at zone_import+0x10c
cache_alloc() at cache_alloc+0x3ac
cache_alloc_retry() at cache_alloc_retry+0x2c
malloc() at malloc+0x94
sbuf_new() at sbuf_new+0x6c
vfs_mountroot() at vfs_mountroot+0x60
start_init() at start_init+0x28
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Apr 28 02:32:26 2022
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 3BEC61AAFB30
	for ; Thu, 28 Apr 2022 02:32:37 +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 4Kpfm41zzNz3HLg
	for ; Thu, 28 Apr 2022 02:32:36 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 23S2WRmv006867
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 27 Apr 2022 19:32:27 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 23S2WRjI006859;
	Wed, 27 Apr 2022 19:32:27 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 27 Apr 2022 19:32:26 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
Message-ID: <20220428023226.GA5666@www.zefox.net>
References: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@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: <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
X-Rspamd-Queue-Id: 4Kpfm41zzNz3HLg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1045
Lines: 33

On Sun, Mar 13, 2022 at 09:45:02PM -0700, Mark Millard wrote:
> 
> A point of testing is to compare/contrast different contexts
> instead of guessing about the alternatives. If the test
> that I proposed showed the failure, it would disprove your
> hypothesis --and it that happened it would be good to know.
> 

You're correct, as usual....

I just tried booting the 13.1-RC4 candidate on my Pi3 from
microSD. It exhibits the same strange "no response to inbound
ping" as before. It does seem to set time successfully using
ntp, and outbound ping works fine. 

Inbound ping from both the same (public) network and across
a NAT link from my LAN work very poorly. The NAT'd link shows 
92% packet loss, the direct link around 88% loss. 

The USB devices present are an FTDI232 and an ASMT usb-sata
bridge, neither is in active use. 

Inbound ssh connections time out, even with outbound ping 
running and getting answers. Not even a password prompt.

It's hard to believe I'm the only one seeing this......

Thanks for reading,

bob prohaska


 

From nobody Thu Apr 28 05:04:27 2022
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 4D338199C86A
	for ; Thu, 28 Apr 2022 05:04:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpk7W1jjWz3rNF
	for ; Thu, 28 Apr 2022 05:04:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651122272; bh=2OXYF67R/PY2YjCmj0qu/WLoF0K3C5u/Mi/N5DlJCrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jKMNBhA3fbGkmbYl1UjlViH6PI3/xLB8PJ8FvYUoBUQuxFMfRzJRtKtUUWqDZ1Kyg+Kz05IasybMZarSO+zLcpoOaUMhMapsw9jncW3mX1n63r+in+TB3TRToqBskrVHnK7vZkGwsYb2MvKrMj0PE6S1bKiwy4zBOs9BHpA+CLkZfUj7jRfLfh7bwm8mAwVAq+btiGycZ3hVPREOym0WBuz6K0KgJkNe/SacYUUc2rA0g6I/UpaXCeGCgHAuDv39oHOg1LLjcGQknLG6VURpwRxeWqjKw+NS0U2p68MGovAJEGBnn+1YV53punYS3GAoiZpYcu0wjfg6l7Kpf72srg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651122272; bh=hj6q47CYghiDJXk8sqZ3nqPBu3EuGxvEGE1+/T81Ol0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YLmDzfkXW92QDz6ag14kGpV3YnYaUgzeswEX717TYU0JkcL9gwM2uWuaOgieWu0ytBHXGVlYgfx/4AcC9FwT1I0ZPy6r6lANLt6+vNCKrTuvkbAsy/SBwkK5K+MwmsshVjlmgxjHb6wiFY3ivBb8ImVSFSNNK/K7nESz4PfDMK+i+ZQvVsxoZ8cZb/oRenp2cz7ctj/1DrOMYYKy5UUIC/y0Tqh6KHAzwdUHREZwNBFJ8o2xPfgBSg95dyrHzhEaZ//CHzAbudGYGY4sJ2mm8f78sXyCvic1H6aS02yFcIGaa9l0Y07pbkW26oDNZrMdH6Vb5cx5HTSqoi9FcqCRIg==
X-YMail-OSG: J8UjDWkVM1kQPY5ygPvKAd8Q0jIZu2sEmlgl.L1SfJW0otcFrv4.IaSfxOqfb2E
 hK7aODSuS.njplmUy9Rfj7tG5C_tHY8uzuNaMElUNVeTmskc_9zipAitc4VRvOcPxwr9yrPcrw8S
 yQmrLWB5JOE0IeuWWbQPubwvALVquA6fPE_PbzPfmwo0x2lnouw6B7ArPEATAIDPOqUze3pwNDr2
 L29V64jAsWbG9xvLc0vHBhEGS1q0dxmX5z6wgvRrta8jSjd03Or0Xvlg2dh4Clc6lpC_op6PGuNC
 SuOXZyqY4wrU3W_oKh8jVHX9W7djYVIIrI_IJ7X8TvLSyDmhkYI5jJLMStX60OKee4bSz8PpdDzy
 L4iqP9IM33q3DHhBlFIpiufLzH1XE52cb0UWcZ9TFgtvBf8gXGVXZXyoFVzyVshUdY0z.o4cJN.B
 nF1Ew8l4hbzo6hkVY9d4wPR8IlXjVUaszTgHcfdtr2u.hC5vmleQp18DGtBHegpXCURe86L6H__3
 VY8TSXVsN31WNsiqAQRswvouZQrZGPBHzF_YLOJrOG4txGiUBIWXrIHMrux.9OG5SPxUxdeU6laf
 2ux.bN2Wo.HRQQuqMBr.C6cXI1Io19eso3n74f5_HK1j7icb4F6hCHuBR0gXm8tcXUaZT.N8jXfy
 iCYBlGNqFjlnDysv3zP6QXj795oieesXcuqBQZJBW_XIo2pvmbO6WdhBQdXuPN.xEyYcokei784A
 VoMCoyQrtlZiJeezynZt7_PSxLrckQFvg920LDa2MfBWK.q0T_RIg7JZve.sFMcHqH36lnWx_PqQ
 _uZeVGymQsO4RO5K_T2auSu.69RNJCF91QBgWDpGtZd7MyX7r7W8GVzuIYXyHLHADDlylRJaE_kj
 O5p.YYT2kEJTgdswGRdHIz202oqGUB_Al_SXT995rOfgcd55ECJYIz5mLhS.u8Atf21UXt7Lr9wx
 Ex9sNRqyN1r_U8YccQwxulEA2fteVmiazhVn28QJ7AoxBA19m8L.pJVgjcan8Ds7ptI0DMLPraP_
 F3kNJSuOvxugk2DjKuEOWfUZPlHGQu8ZIhWfPB5nSLN96R87ng2usCaJGfvBMYgyVYbWcTEMimzV
 .3ryLu9GnT93acKja2CHCg28U8Pb1FPT0_KfN6uqwKj13uD.T8efnoRq0n2E6R6R8bqWypvYWfi2
 GY3atrbxJLG4kUGkFTXc_d4t7Ta8GDHofmNpIl4aXYfNKYdSGmxuTB1jMm.yOrkNGJSmepL1l2da
 M3QtaI.tXwnqJtnfPpKokyf7an3x4dsjZ4Cj2_VgV51QzTeT8Hg4M9051hXFBh1ovcKs4qhV7X_e
 rcKgLoR1BzRSAgnLQDpUYv3aVDf7DAc3wzq.UiLrkMzd8HGLnY52u0MIbPNzlBwpQW3HiZ6jTvhf
 lr_4UaSbQQxUIO1u5XMRwDfaX4qDMuRy.CL2Z8iTQ9mKHDtQNUWo_lnxiUkYL3qNZJjnZ_d9J5K9
 Tuj4OtiRbu9ZP32.RUAXwMyYa_xZuWKGj6VGZewdyTCz0AtuRL_bpLSF0dsE2UaPHUQ.SWZokoPf
 g_fESjxP94Qg.z1pGtzioir5SSK16ud3ccQXZkOc7RXMG9TkHLh88b6eSQX.2ijR2s1w9KoAOTuN
 BomNMYB3DKUvgVrt2yFYAbnzXwkyTuNiTuBba47NkHUncHrq92Dl6P294cYZf7k8gniEr.71wZ97
 Z0C5t2kJQ_etfGc7jgb0COptVekmVeVjD3lb.GtTotUPYWip.o510nnqbB6OGEirDMPrNifQ2pwv
 cIMTJjGjdJvB2bi2trhu54xJH8jOyRHqh8VC.Cgd4bl8dwFBmh3qEzGJdZxFdKyXG1wSw6rW6kAu
 3E53ZuhKGpJ2GdB3gzUY6Hll3_NsGjDZ_eN9JHUtLy6IfY9Pm3RUvJVcGBWT07PGrn0Lpb78rNBL
 ZNSHoqCcmY82PWYJKGmt2jZmhjIzdxs7zdtJ0EeMww69NVtS6eRrDCz.EJixGoB2.keJ1n6zaFqU
 BbylRtrhQ7ktTVc1JKn5n5e01xSavVm3_0ime1nL7TzPIcCc.N_lten4fzJoI.Bk.U1WcPOiPHW7
 pvhCRsOwgB7rRZzBAZ65T4IUp.mZxbhP.Di7sI8O3AMBQXfmw4SzYCJ1zKtQ3A7am1ZPBU4aYNre
 7KNM0Vti9rn2YYXLoVKhr1blX.VepnhN4.K47tzakJ74mXeM0MeXBIy414w_U.EZCLS4ioYSuXSY
 LoBAy1I_ATghcCLoyFuFHqjK3bkfkT3ffhqkrC35VDKUMPk._pbDBqjERMoiCU.EZ4slcSyJX3Q9
 ku5LWZN4_lA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Apr 2022 05:04:32 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-7lp55 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6f8d75bce3cb16844726c664b39a4363;
          Thu, 28 Apr 2022 05:04: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: <20220428023226.GA5666@www.zefox.net>
Date: Wed, 27 Apr 2022 22:04:27 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
References: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kpk7W1jjWz3rNF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jKMNBhA3;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2446
Lines: 72

On 2022-Apr-27, at 19:32, bob prohaska  wrote:

> On Sun, Mar 13, 2022 at 09:45:02PM -0700, Mark Millard wrote:
>> 
>> A point of testing is to compare/contrast different contexts
>> instead of guessing about the alternatives. If the test
>> that I proposed showed the failure, it would disprove your
>> hypothesis --and it that happened it would be good to know.
>> 
> 
> You're correct, as usual....
> 
> I just tried booting the 13.1-RC4 candidate on my Pi3 from
> microSD. It exhibits the same strange "no response to inbound
> ping" as before. It does seem to set time successfully using
> ntp, and outbound ping works fine. 
> 
> Inbound ping from both the same (public) network and across
> a NAT link from my LAN work very poorly. The NAT'd link shows 
> 92% packet loss, the direct link around 88% loss. 
> 
> The USB devices present are an FTDI232 and an ASMT usb-sata
> bridge, neither is in active use. 
> 
> Inbound ssh connections time out, even with outbound ping 
> running and getting answers. Not even a password prompt.
> 
> It's hard to believe I'm the only one seeing this......

RPi3B? RPi3B+? Which Rev?

So, if I gather correctly, if I expand:

FreeBSD-13.1-RC4-arm64-aarch64-RPI.img.xz

onto an microsd card, boot an RPi3B with
EtherNet plugged in, and test pinging to
it, I will have replicated your context
except for, possibly:

A) RPi3B exact Model/Revision
B) presence of a FTDI232 plugged into a USB2 port
C) presence of a ASMT usb-sata bridge plugged into
   a USB2 port (no drive?)
D) the details of the EtherNet network that I'd
   being using. (No public network or NAT in
   the path between machines [same local subnet,
   no other local subnets present], just a simple
   local switch, the cables, the RPi3B, whatever
   other computer(s) I use, and the device that
   provides DHCP assignments for the network.)

If true, I can try such. But to get to a matching
test, you would have to deal with eliminating
(B-C) from the context and setting up something
like (D) as the networking context. (Seems more
reasonable than me trying to replicate your
public network/NAT context.)

Note: I would normally have a serial port connected
to the proper pins for having a boot console. Once
I prove I have correctly set up/booting microsd card
media context, I could eliminate that. (The other
end is USB but that is not what the RPi3B is connected
to.)



===
Mark Millard
marklmi at yahoo.com


From nobody Thu Apr 28 05:42:57 2022
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 913741AAB535
	for ; Thu, 28 Apr 2022 05:43:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpl0025z2z3vG9
	for ; Thu, 28 Apr 2022 05:43:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651124585; bh=2KQTsY52ZBOyr7DRec4ScbawcwqzokbCPbTmtfPiifU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aV7wAiksZoAAUM7tFfP/c5/nASxPOh286lEffrrqsYUSkmx+q+s55JpmMTEryRPNs9ahJiYPIWw93igePcrDg2bRyY/0WhMjBFP5SCAMvnaMzBJSRdzmmqo13LdIMMaVfFoZj2R79yCMU1NGKh1GUhRSE6dMvZJbQHB175KehbHPgTh6l4SHFaZ99HSrL537NU9Z+IuiSy17rck+6yHUdaxDKAmZRf4NpPtNqV0kT0RsyrDzY+We+SFqH+jRz/iLxbUNGfcYVaolhftFThOeU+u3lpWTG/LytFlHnMrhD9qbDYTzT/1G16nO13sNjIGSEMnTKU2uoRAkp0BtAsvtcg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651124585; bh=6bgd1GJP8nAyJMkSS/VQfchOUFyp7dSC2YStRRbqSe3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=niEsP44TerRXhlp9RATnwnd3B+RAsH3jKbZpehfJ/j667wgX/FB3NamPdlu1aKHep1VaH4NgX0Q/cYAw0HFgoYaQBQ/IeL11t7jr4SBCP+VJGzKNzAU9Y6mZ2gjF7qxeYeIjLVJ2bdPd1g6mlmaxAYohVA70xfvDZnL7vIhPbcqvZvaTAZGk3FOPkIyoIUQ/5MxZ3FVSHrmRKt9LrdUnA+ra15I1N/GZ/dqOAUHUdpeGx65yQYVgO5QXMlVtJU9lf7z375mTd0BRh2BmHrkq1RudOl4GyTzgzH/49mlU5PuSjZ6rJGIssJBVyDl2NCzMujoPIaqR2ezOQucBY4eTNw==
X-YMail-OSG: ViRZblgVM1m9DrLwvgcU1TL2vuyYouNgvm4g6myukqSe2vMWrwukv9LEVAX_yAq
 5x4gWCRw2PDan0plW7cZDLD8Z5tLmDTWeflr1WXaTVBiFUd4wzHfqmJhdkbEkHW2YJb_nqi_Zdt6
 zlLbzPEgxTJYKg6H9Sp1uZzl182VP1KFqLSuQwhladHGrBDBb6KWa5o0HQ9sUS8.ci18earaHYEO
 N16BD5psCK8o2I4GoRpKdjWTfjDtG36qDCdF5hgyfrAtxGQ6.vlRqFNzhcldwGXH4AwpYW9xVKsP
 H6FXVv8nGYNY4apJEtWGp0kL5WSKU9D5NtbNX6FvP1T8WCdUc7zdNTYqYjXvAvNPc4fQK_pZAOsy
 6C30aGyK1DBxyNsmYY0VNjoEsjieyYSsJvqu4920pxk29qBGQwNy8sPr_FVRUu3YCJJV5AtKhsNG
 f9urCG87ZWTZ6Q0h1W9RjPmk0n2xpqfx5gdtGKDdXyMVP5sMc7Wj_craheQCsOorFeTdFHhFb4DP
 5wRJR4GYLYVk10r2waPQ5PfTZlWdpoXPGkpx6ANF90M989Oof3Jr4AOhDez_grsQ3VzXklbZxgZ9
 Hy.KxQSY8PTeURZycHvyH5t7FqyApGIzPDxqbtovViTjEaLjw1FJXtDIt4ADao1u7.1OBqRfRteT
 8eqo.jU4hVdXGUkEFMYhgaY9jU2muoEEhoesQACn2xsz14QnULyHueX6iIsHxJvLtiRHXMyz4rO1
 sd0cdClDwfRPM9jn.5SkAdgYT8rpSdPJZfKqAGL8i5bHt8tlFvPH7ZKBYeEq7cB4zWy7GJGSeiNo
 NwQx_JA3sSyC3o4g2YrGjxSHyNqmeu6iPSl2ISFvacIgTuW8Gmc_eNpepxSaGqe8kN5gTot6F8jk
 UuYgmki054f8tnC4p2Izxv2vcY9PbmIXnU.dVka.HTemaFy4xYFAau16lJdUslAh7NlIlg8YT5C0
 WJVn1kUEDxxXgYyqvSbKIAVsE1zBWNIbJtfUlQdxLhJ3rc3bmxIVbBENUPt4V0SNd2euONSq3nWw
 uhIvXSqoTjbm0x4TdBthLDjT23llJd_Xhq0gTipjUAD4a35p_woT0Qm_.B7780dOXHRex23bI6xP
 Zsl6A0hVm__Uqwm.ke5J40dvAIYlze3yM1PJSAauO7TUdX1KPiuvDxMSNY90FU0XjDltFZLDKc4p
 ZCy_2x7cuEboZU5a9K453Cl_1rm8LTeR6crMb9Veyb2LuhNWHmSaRvcntGgPpADbEk0y_9NZ7dcF
 vLNf33ZVRmZxAYhEGBKgOtGeIonDc2oDeDNV56FVQbVRCaQ1QA4M2jeiVLmwC0F3pduG8FLwspSk
 XRTZKPbbWtV7T9Qjp_7cWOdkKaqWTqsQyh6pVNZ6EUbIvVZy5_lEk5EdVNX8KdK175hMVES95VKF
 GjWZMsG4QqxrXT3KG0l8s6pEO.HWMz3Zp1SX.ky3h82rKWDuihO05qiyhnt4mG4NDdH8VisDrD8j
 jP8396xpwvrrhPhq93wE4HTxoYBLA4kHrlMzWz39Vyh6GpNP4bKs5GOWCnsmc7J9XumhK3Ema2er
 ZM_RtE38yvD15GlP.J8zGGtuVoS0ckUmqOcvOy1Lkkgb3u_2DFtNKs5O_P2rDHuGEGZ1jrNwGQa.
 ifW7AHgJGALvqYid9aCmPxLnea1FbFn9QYcVcqi0uTgJiGrrZIi0F.fdXXaeeJ0IEddNit8KdHMD
 LfXL67kEuOxlXkexaYJyDj3Wmr__v0bxcXBHzVnKe7jJfvtJtFzO4WeQYdw_O2LoVdZOKGPKEV0S
 4fZMHIIhseBm0tPCrjcFU83UF2xGpxNzvCYBO2tBxkhkFzRJ_4U0zjktqyPTI6ds1mgSZ5IlxlW3
 8A3bmqth4A2OHKQu03IL5viY8XMD1tQ5y.rNzcbzwupyrXp8RMW5HQOQL9OweknpR9oUEsAu6ci4
 E3Q0OyYcr8GzrMyHLE0JWfhA74bawPMVh42sa3MQMKRu4Cp.7ZNkexX0nSEKLj3LCmg9qxj0w.1H
 kMrU4Fs5AG3dB4c5jCvYKbwSWZIIlHEQsSdAROaXvUOkCcd4JZ2hYrjnv0Yez2zE1Q4XBuabwCPp
 hjyFFl1n6u8roVwAyny5b8qJfC63DkAx7ivgis8z4bca9AkXbbj7Xm82Lxh5rSxukqt0B5mRpQHl
 ySex7Z_Ov5IL4O9EOvQqVJkCHHwx6sw2unhUGzz8Dv9b_4jlvN5xgUxYvLRN4aYMztIZh4qzj_kT
 s.l3EEEDd7XdzAwvFz244fYtnQomjL7FW.1Chjn6yqplZ57SyEIRhFtbglsZVkoXbYS2lDgH1o5Q
 rLe4GRmSYUSgELZXwKeKl1jY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Apr 2022 05:43:05 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-hgcs7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 241044914d82e384325c7e137dc09006;
          Thu, 28 Apr 2022 05:42:59 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Erratic ping behavior, was Re: Pi3 answers ssh only if outbound
 ping is running on -current
From: Mark Millard 
In-Reply-To: <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
Date: Wed, 27 Apr 2022 22:42:57 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
References: <8F9A6C9A-69BF-4D42-9886-A3F08BCB2EA0@yahoo.com>
 <506CD1A7-3D34-4E1B-AEAA-A1A819C6CC73@yahoo.com>
 
 <20220216231826.GA54961@www.zefox.net>
 <64138E81-2415-4D4A-A31A-D901DC53EB01@yahoo.com>
 <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kpl0025z2z3vG9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aV7wAiks;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[192.168.1.143:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[192.168.1.143:email];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9842
Lines: 234

On 2022-Apr-27, at 22:04, Mark Millard  wrote:

> On 2022-Apr-27, at 19:32, bob prohaska  wrote:
> 
>> On Sun, Mar 13, 2022 at 09:45:02PM -0700, Mark Millard wrote:
>>> 
>>> A point of testing is to compare/contrast different contexts
>>> instead of guessing about the alternatives. If the test
>>> that I proposed showed the failure, it would disprove your
>>> hypothesis --and it that happened it would be good to know.
>>> 
>> 
>> You're correct, as usual....
>> 
>> I just tried booting the 13.1-RC4 candidate on my Pi3 from
>> microSD. It exhibits the same strange "no response to inbound
>> ping" as before. It does seem to set time successfully using
>> ntp, and outbound ping works fine. 
>> 
>> Inbound ping from both the same (public) network and across
>> a NAT link from my LAN work very poorly. The NAT'd link shows 
>> 92% packet loss, the direct link around 88% loss. 
>> 
>> The USB devices present are an FTDI232 and an ASMT usb-sata
>> bridge, neither is in active use. 
>> 
>> Inbound ssh connections time out, even with outbound ping 
>> running and getting answers. Not even a password prompt.
>> 
>> It's hard to believe I'm the only one seeing this......
> 
> RPi3B? RPi3B+? Which Rev?
> 
> So, if I gather correctly, if I expand:
> 
> FreeBSD-13.1-RC4-arm64-aarch64-RPI.img.xz
> 
> onto an microsd card, boot an RPi3B with
> EtherNet plugged in, and test pinging to
> it, I will have replicated your context
> except for, possibly:
> 
> A) RPi3B exact Model/Revision
> B) presence of a FTDI232 plugged into a USB2 port
> C) presence of a ASMT usb-sata bridge plugged into
>   a USB2 port (no drive?)
> D) the details of the EtherNet network that I'd
>   being using. (No public network or NAT in
>   the path between machines [same local subnet,
>   no other local subnets present], just a simple
>   local switch, the cables, the RPi3B, whatever
>   other computer(s) I use, and the device that
>   provides DHCP assignments for the network.)
> 
> If true, I can try such. But to get to a matching
> test, you would have to deal with eliminating
> (B-C) from the context and setting up something
> like (D) as the networking context. (Seems more
> reasonable than me trying to replicate your
> public network/NAT context.)
> 
> Note: I would normally have a serial port connected
> to the proper pins for having a boot console. Once
> I prove I have correctly set up/booting microsd card
> media context, I could eliminate that. (The other
> end is USB but that is not what the RPi3B is connected
> to.)
> 

Well, booting it and not even logging in to it,
pinging it from the Rock64, where I am logged in:

# ping 192.168.1.143
PING 192.168.1.143 (192.168.1.143): 56 data bytes
64 bytes from 192.168.1.143: icmp_seq=0 ttl=64 time=1.223 ms
64 bytes from 192.168.1.143: icmp_seq=1 ttl=64 time=0.575 ms
64 bytes from 192.168.1.143: icmp_seq=2 ttl=64 time=0.552 ms
64 bytes from 192.168.1.143: icmp_seq=3 ttl=64 time=0.663 ms
64 bytes from 192.168.1.143: icmp_seq=4 ttl=64 time=0.536 ms
64 bytes from 192.168.1.143: icmp_seq=5 ttl=64 time=0.539 ms
64 bytes from 192.168.1.143: icmp_seq=6 ttl=64 time=0.529 ms
64 bytes from 192.168.1.143: icmp_seq=7 ttl=64 time=0.641 ms
64 bytes from 192.168.1.143: icmp_seq=8 ttl=64 time=0.610 ms
64 bytes from 192.168.1.143: icmp_seq=9 ttl=64 time=0.635 ms
64 bytes from 192.168.1.143: icmp_seq=10 ttl=64 time=0.617 ms
64 bytes from 192.168.1.143: icmp_seq=11 ttl=64 time=0.618 ms
64 bytes from 192.168.1.143: icmp_seq=12 ttl=64 time=0.652 ms
64 bytes from 192.168.1.143: icmp_seq=13 ttl=64 time=0.605 ms
64 bytes from 192.168.1.143: icmp_seq=14 ttl=64 time=0.730 ms
64 bytes from 192.168.1.143: icmp_seq=15 ttl=64 time=1.319 ms
64 bytes from 192.168.1.143: icmp_seq=16 ttl=64 time=0.618 ms
64 bytes from 192.168.1.143: icmp_seq=17 ttl=64 time=0.567 ms
64 bytes from 192.168.1.143: icmp_seq=18 ttl=64 time=0.563 ms
64 bytes from 192.168.1.143: icmp_seq=19 ttl=64 time=0.560 ms
64 bytes from 192.168.1.143: icmp_seq=20 ttl=64 time=0.556 ms
64 bytes from 192.168.1.143: icmp_seq=21 ttl=64 time=0.624 ms
64 bytes from 192.168.1.143: icmp_seq=22 ttl=64 time=0.530 ms
64 bytes from 192.168.1.143: icmp_seq=23 ttl=64 time=0.532 ms
64 bytes from 192.168.1.143: icmp_seq=24 ttl=64 time=0.655 ms
64 bytes from 192.168.1.143: icmp_seq=25 ttl=64 time=0.643 ms
64 bytes from 192.168.1.143: icmp_seq=26 ttl=64 time=0.634 ms
64 bytes from 192.168.1.143: icmp_seq=27 ttl=64 time=0.630 ms
64 bytes from 192.168.1.143: icmp_seq=28 ttl=64 time=0.601 ms
64 bytes from 192.168.1.143: icmp_seq=29 ttl=64 time=0.590 ms
64 bytes from 192.168.1.143: icmp_seq=30 ttl=64 time=0.618 ms
64 bytes from 192.168.1.143: icmp_seq=31 ttl=64 time=0.526 ms
64 bytes from 192.168.1.143: icmp_seq=32 ttl=64 time=0.629 ms
64 bytes from 192.168.1.143: icmp_seq=33 ttl=64 time=1.482 ms
64 bytes from 192.168.1.143: icmp_seq=34 ttl=64 time=0.538 ms
64 bytes from 192.168.1.143: icmp_seq=35 ttl=64 time=0.628 ms
64 bytes from 192.168.1.143: icmp_seq=36 ttl=64 time=0.547 ms
64 bytes from 192.168.1.143: icmp_seq=37 ttl=64 time=0.642 ms
64 bytes from 192.168.1.143: icmp_seq=38 ttl=64 time=0.539 ms
64 bytes from 192.168.1.143: icmp_seq=39 ttl=64 time=0.614 ms
64 bytes from 192.168.1.143: icmp_seq=40 ttl=64 time=0.641 ms
64 bytes from 192.168.1.143: icmp_seq=41 ttl=64 time=0.621 ms
64 bytes from 192.168.1.143: icmp_seq=42 ttl=64 time=0.542 ms
64 bytes from 192.168.1.143: icmp_seq=43 ttl=64 time=0.658 ms
64 bytes from 192.168.1.143: icmp_seq=44 ttl=64 time=0.614 ms
64 bytes from 192.168.1.143: icmp_seq=45 ttl=64 time=0.781 ms
64 bytes from 192.168.1.143: icmp_seq=46 ttl=64 time=0.784 ms
64 bytes from 192.168.1.143: icmp_seq=47 ttl=64 time=0.573 ms
64 bytes from 192.168.1.143: icmp_seq=48 ttl=64 time=0.586 ms
64 bytes from 192.168.1.143: icmp_seq=49 ttl=64 time=0.564 ms
64 bytes from 192.168.1.143: icmp_seq=50 ttl=64 time=0.553 ms
^C
--- 192.168.1.143 ping statistics ---
51 packets transmitted, 51 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.526/0.648/1.482/0.184 ms


Then logging in and creating an account for ssh access to
use, tested from a macOS system on the network:

Password for markmi@generic:
FreeBSD 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
If you want to recursively copy a directory preserving file and directory
attributes use
"cp -a source target"

		-- Lars Engels 
markmi@generic:~ $ ifconfig
lo0: flags=8049 metric 0 mtu 16384
	options=680003
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
	options=80009
	ether b8:27:eb:df:cf:a5
	inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect (100baseTX )
	status: active
	nd6 options=29
markmi@generic:~ $ gpart show -p
=>      63  62333889    mmcsd0  MBR  (30G)
        63      2016            - free -  (1.0M)
      2079    102312  mmcsd0s1  fat32lba  [active]  (50M)
    104391  62228537  mmcsd0s2  freebsd  (30G)
  62332928      1024            - free -  (512K)

=>       0  62228537   mmcsd0s2  BSD  (30G)
         0        57             - free -  (29K)
        57  62228480  mmcsd0s2a  freebsd-ufs  (30G)

markmi@generic:~ $ 


So trying from something based on FreeBSD [main, so: 14],
a RPi4B on the same local subnet:

# ssh markmi@192.168.1.143
(markmi@192.168.1.143) Password for markmi@generic:
Last login: Thu Apr 21 04:13:50 2022 from 192.168.1.106
FreeBSD 13.1-RC4 releng/13.1-n250133-283d1b98251 GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
You can `set autologout = 30' to have tcsh log you off automatically
if you leave the shell idle for more than 30 minutes.
markmi@generic:~ $ 



So the basic test does not show any problems that
you are reporting. 

Can you replicate the simpler environment and see if
you have the problem in it?


===
Mark Millard
marklmi at yahoo.com


From nobody Thu Apr 28 06:47:37 2022
X-Original-To: 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 9E8401AB755B
	for ; Thu, 28 Apr 2022 06:47:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KpmQR3kNfz4YB3
	for ; Thu, 28 Apr 2022 06:47:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651128462; bh=AKsycAhDVzxeMZJDQsWbWVgOU91KR1LZH3RAwjah6xo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=KSAXaDxiZo4I54XwsPtn1UWKr988G6A/vYLhoOxmt4B1lZ0NPMUAge/jvY1tD9lCpeFQh1Y51K/Z7FJ21gODecj8Xa4zjRL8IYohUfW5Q/pNQYQlVHntK1GZtW8GPZsAGFrG6oxglqHTPhFQAO3EH0QtSiwNEJqoP7frSyY8SvnmZ3kF3eSuPmv7vhUGOIyFq75vFCvCWNKHPS9PbUomAXmrKWTm0JtLSBeUjfQ006bdqw6MHLDNrQV8+uDwYha7NBNIiuIM+F39KgvsO7rL99CVknZuFHWNLbbQCPNFhVpSiFVV8c7U4DxmhxB3Fzy2gJhsAboZqPB2ZN/E8kYPAQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651128462; bh=k3Ksl5vlZzm17zGylwg+7EVTNVImrn8r74lKv9kfPph=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=WoWwn/W3EsVEZJ2pR9eQJWCkmf01QNO2dxNB+5yJFAOzyJ/8FFnyvgb9s7JX01MwOtmS2sF9shkvLnECsvAmM8qCLwqojDO5lyz7/VCHOeeKMGN9jIhwRsht7w/KvCNxwpCgRw2FfqTi/9vnDwILI5uGk2RYzy4vSFifPJUxqL+RtXz2Unto+wqR4PAefRuhJx58MylcnzWbwdhXmDoLuk9n7Q80ZtFwHBY+j083dK+ba6E0BhXjUauURLficU85RdP80lY8eiYo/C41QlILySXw11zrOIQCJym7viZXVBGr9oxaPNv09DKeGwOOjQXnMhjxYM96wyNHbT+ozTOUhQ==
X-YMail-OSG: IGd3hw8VM1nSAeZYqTbPth2GJNmS7ixYPANPsq5NWZwKcaGmhYOg_3F7vjxjO_e
 Yfru39z_qeHw9xdGI8EKnHAfDTqV5vUz3simgYRVi8Vyn1Iyo2oVy6TJAjlWPkU3et4wHOblwJF1
 3vGk_sf9C08F9iJIq0z0oMIA4UmQjxstel3RlL5aFt6eVfZzDNSdQVmRenmmQr6YRoZ9SWzXWdBy
 2SzDZMR48aoMUs1FcXBaKM0Yf6ZaZHlaOcbaqVoGqcefdp.SkyT2UFcR27iWNRbpKY8HtAcan7GC
 fIEFU1JMWM_h6XHKxsXJat_VZTp.jv4jjNZe3dMMXqSVFQKnePXCP94I6J8GBe2UaYu5CR4rEMWw
 9V7fsJjdBqRc9X52phOf5I9xjO7ByiMn81F1z5IFzL4t1TM7xo_NgIEap.uCYSDPRYbUl8SM3Fhl
 aP0tJtnIdkpyptrg03gu0e1bvgrUrKc2_U0P3fTxsRevzspzuyp.AmF8hw8QKSk3wYvcIBPhuoDl
 GyFuy8xCog3_amyCJyU0XWXxc1FPnp7MV5G1XFnyU_nL4C1J3.XEBUfDhNIldgED8PuespL_Crwj
 xGUjPBLq8uANuvsbK5MrLdszkRJfDU4Susa9zGi9nmBoRojDRlCChpAdbn4MwlzfW4nhLeB4ABSJ
 x1RMoReCTQ2qjmAQwTaBRRPXGSK6MSa1IdJ2w1oMTDEONWjmvWB4jK2V6S0iRMQXM..ljT6ezeDP
 W5fHlSwpPh0RgnC8AB9uNG0tB6GiPAfTi7Xu1WsPsmQzndfPs6nAbJR380b1XKFOJ88PBGAPQTxn
 CbxoCQSl5yEEY4N.IbUx99ZAdX1qX7Xn4ep95GvIagyFfgoZddYCHa15.Kmas5sB7jpiQqwLTw3b
 s1rJmtNcCA2rboXaZDGYklmd6d4QZad4bwlrMLnR5Ga4R6naT2SUyGi1G6wMYaSp5jVtHvolbSCT
 pQ7TlbFh6CvzHKSEQ39ouMWtYrqx0m6lM3StapJhu3L64n.WwbF0t.6r2Knkbqxe4aczIm.N_YQP
 AYUoGQsr_6fycvMOvqwpl7eeCqtONBNkV2X9vJZqFVK8cjHRWv686ZusTpyWGreuR5fwoq1d4Jqm
 96LVYhHBnoBjiOxKntBsi4tlfxBYYR5SN1Cl_oloV_eX58v8Ib9uOFvOJOH3Yk3i9oRKjzoHFH8c
 EK3RATqkoqr6EgfY0v9EbFuPPPfz0Zz3DOJMjlhFXBZnNUYvcRlyhCgIm15dFs80KO1LNf4lItQG
 ex7scJSOc8a17CHZ26spFb77HrlXX9FV8tavizAwm1QXtPe1.tRGDnWPUWMdHipu2RF31Fca5zFT
 sA_ob1.RckeOuq4A8SoOLySLPayeuam58G2sQQzpUQeGytW9P2yS49ffokvZClE4WSuoC_THV2yC
 pWdc0PXtoxYihFtBU_YUByUNOhfX_Zb.lyo_BS544vXvVjCDAJyBJ0MmhynQ_1bP.UVAuXFye7SQ
 K.aZwT.QqBCMpAN_1NbYwbfRz94xr3JxJONSjI1JERZlVv_RZYp5Tn2yZ7MK9q5evJus_ajbw96f
 BWaX2R_6mzf7l_QvCG.gMq8OlltVcxXhze3L9kR.NDoN3E.PeApj6HJ00JYhYrON1raPWBoIShrH
 _qaHRYoV2KsZk0IApte8PZrkNMQ.hn4LI3z0iXrRnJQ19r303._yHdydR18FZ1NyZa68ANnJPouu
 x2lQEUa3nFC5SmsMk.zH_OOr1VA_8DGtzjzahzZTCMvF4j55.6b.pMQnbcu5sy2bCcoWAM1CDHM0
 CIrezw98JaySAf9rkFk91bKzlMJXRtsBbva0ZDQRV6qgZ24k.7VICfD6OH322MV5OrDaN9nJDOwq
 RXMNHtCDtHGCFveS8a9yX1Q66jFlc6Om9Te5pTbNATXDf2EbyvxRLwgpSG7jpnYv7wiQ7.TaXNVJ
 0kjbdrecJFuYkn1R3GYpuBnQz6K6QcSIUbmOo9MBrxFKhHj8LQlf_icKeU6YeR.BWXkBBpUL15SS
 m_tY.hFMSkozITpugGR6t1sHlQjx9tusqgz1klAJfGRxGMg9OqDGmu_kQHfQFbJR5DE2NZKrPhe.
 fQ5z3tIyEFATYlnDkqhTJcHaHO_mmSnMYn65S8IjltqJqQkRPUCdUkKGSXfmduzOhiBFshjNmIV.
 Twba8zUfPEuCWtE1qf208kuH1bUCTJdf..Zp7v6VwxKVigvu2Sbw0qTT6NlUtp7M.zul9Mmvv1qA
 .zEnYpl3OZfDq6Jwx6r.mqFcFZ8_arV_AiBilY0hrCpNQNWMWCZGhS6V2dU_7lgJXT8MuAXE91_H
 M
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Apr 2022 06:47:42 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-dzsj8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 06a0a7e357b85a4c8ea2691b91343db3;
          Thu, 28 Apr 2022 06:47:39 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi* firmware tagged 1.20210805 appears to be the last to be
 bootable by FreeBSD via fdt use; sequence of 2 failure modes after that
Date: Wed, 27 Apr 2022 23:47:37 -0700
References: 
 <836019DE-531E-4B49-8A82-0D8F84885C21@yahoo.com>
 <8291972B-A953-4FD9-AA67-9F1F15AA3940@yahoo.com>
To: "freebsd-arm@freebsd.org" 
In-Reply-To: <8291972B-A953-4FD9-AA67-9F1F15AA3940@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KpmQR3kNfz4YB3
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KSAXaDxi;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.51 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.981];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	 NEURAL_SPAM_SHORT(0.98)[0.976];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8915
Lines: 265

[Just an FYI: I got ahold of the RPi3B and discovered that
it was not bootable via RPi* firmware tagged 1.20210805 .
In fact it barely produced any output on the serial console:
very early failure. Reverting to the prior one, 1.20210727,
worked for the RPi3B and the RPi4B.]

[I've not added to the below and have removed the long text
block of RPi4B boot failure output.]

On 2022-Apr-24, at 05:36, Mark Millard  wrote:

> [I may have also found what leads to the extra messages for
> the 2nd failure mode, an independent issue it turns out.]
>=20
> On 2022-Apr-24, at 04:37, Mark Millard  wrote:
>=20
>> [I think I found the reason for the boot crash that is
>> a common failure to both failure modes. The 2nd mode
>> has other issues I've not analyzed.]
>>=20
>> On 2022-Apr-23, at 23:45, Mark Millard  wrote:
>>=20
>>> The following is based on a microsd card with 13.1-RC4 on
>>> it were I'd previously substituted my U-Boot 2022.04 build
>>> and tested with the RPi* firmware that is in the 13.1-RC4
>>> image. Here I've tried replacing the RPi* firmware and
>>> holding the rest constant.
>>>=20
>>> The boot tests are on a 8 GiByte RPi4B Rev 1.14 with the
>>> B0T stepping. I've not been copying over the linux kernels,
>>> which they also bundle with the firmware.
>>>=20
>>> [13.1-RC4 is just what I happened to use. I doubt anything
>>> here is special to 13.* or stable/13 or main [so: 14].
>>> (I do not use 12.* or stable/12.)]
>>>=20
>>> The observed status went like . . .
>>>=20
>>>=20
>>> firmware-1.20210805/boot/
>>>=20
>>> The RPi* release tagged 1.20210805 is the last version that
>>> FreeBSD booted with. (Other than booting, logging in, and
>>> shutting down, I've not been testing other aspects of
>>> operation.)
>>>=20
>>> =46rom what I've read, firmware-1.20210805/boot/ should be
>>> recent enough to handle the Rev 1.15 related PMIC variation.
>>>=20
>>> [I'll note that firmware build dates need not be the same day
>>> as the date encoded into the tag --in fact it is usually some
>>> earlier day. On rare occasion it can be a lot earlier, and
>>> there is an example of that below.]
>>>=20
>>>=20
>>> After firmware-1.20210805 there are 2 major failure modes.
>>> Both stop at the same sort of point in the messaging --but
>>> there is a huge difference in the count of earlier error
>>> messages. It looks to me like all the issues require
>>> FreeBSD changes if modern RPi* firmware/dtb's are to be
>>> usable via fdt.
>>=20
>> I've noticed a difference between the working context and
>> the failing ones (both failure modes).
>>=20
>> Failing:
>>=20
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> NOTE BELOW LINES MISSING HERE.
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>>=20
>> Working:
>>=20
>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> START LINES MISSING ABOVE
>> iichb0:  mem 0x7e804000-0x7e804fff irq =
26 on simplebus0
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
>> bcmwd0:  mem =
0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on =
simplebus0
>> bcmrng0:  mem 0x7e104000-0x7e104027 on =
simplebus0
>> gpioc1:  on gpio1
>> END LINES MISSING ABOVE
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 73 on simplebus0
>>=20
>> In particular:
>>=20
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
>>=20
>> being missing means no bcm_dma_attach and that in turn means
>> that the static bcm_dma_sc =3D=3D NULL still.
>>=20
>> The panic was: panic: vm_fault failed: ffff000000862134
>>=20
>> where:
>>=20
>> ffff000000862134  ldaxr  x1, [x9]
>>=20
>> which is part of:
>>=20
>> int
>> bcm_dma_allocate(int req_ch)
>> {
>>       struct bcm_dma_softc *sc =3D bcm_dma_sc;
>>       int ch =3D BCM_DMA_CH_INVALID;
>>       int i;
>>=20
>>       if (req_ch >=3D BCM_DMA_CH_MAX)
>>               return (BCM_DMA_CH_INVALID);
>>=20
>>       /* Auto(req_ch < 0) or CH specified */
>>       mtx_lock(&sc->sc_mtx);
>> . . .
>>=20
>> So the likes of &sc->sc_mtx end up being a small offset
>> from address zero:
>>=20
>> x9:               20
>>=20
>> Thus the panic.
>>=20
>> As to how bcm_dma_allocate happened without bcm_dma_attach
>> happening first . . .
>>=20
>> The working context's dtb has the ordering:
>> (I also show mmcnr@ and the brcm,bcm2711-dma
>> just for reference.)
>>=20
>>               dma@7e007000 {
>>                       compatible =3D "brcm,bcm2835-dma";
>> . . .
>>               mmc@7e300000 {
>>                       compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>> . . .
>>               mmcnr@7e300000 {
>>                       compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>> . . .
>>               dma@7e007b00 {
>>                       compatible =3D "brcm,bcm2711-dma";
>>=20
>> But the failing context's dtb has the ordering:
>> (I also show mmcnr@ and the brcm,bcm2711-dma
>> just for reference.)
>>=20
>>               mmc@7e300000 {
>>                       compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>> . . .
>>               dma@7e007000 {
>>                       compatible =3D "brcm,bcm2835-dma";
>> . . .
>>               mmcnr@7e300000 {
>>                       compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>> . . .
>>               dma@7e007b00 {
>>                       compatible =3D "brcm,bcm2711-dma";
>>=20
>> So, for sequential handling in the failing case, the dma@7e007000
>> would use bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach
>> sequence had happened, leading to the crash.
>>=20
>> Note: I used "fdt print /" from U-Boot to get the dtb and its
>> ordering. This was based on the address that the RPi* firmware
>> reports when debugging output is enabled (0x4000 here).
>>=20
>>=20
>>> The 1st mode happens for (I've added the -fails notation):
>>>=20
>>> firmware-1.20210831-fails/boot/
>>> firmware-1.20210928-fails/boot/
>>> firmware-1.20211007-fails/boot/
>>> firmware-1.20211029-fails/boot/
>>> firmware-1.20211118-fails/boot/
>>> firmware-1.20220308_buster-fails/boot/
>>> (The _buster one has firmware from 2021-Dec-01, which
>>> is before all the tagged releases listed below.
>>> It looks like the switch to the new major kernel
>>> version after buster came with other changes that
>>> FreeBSD has not tracked.)
>>>=20
>>>=20
>>> The 2nd mode happens for the following. (Again with extra
>>> notation.) There are a lot more error messages before the
>>> panic happens for these. The firmware builds for these
>>> are more recent than for the above list.
>>>=20
>>>=20
>>> firmware-1.20220118-fails/boot/
>>>=20
>>> firmware-1.20220120-fails/boot/
>>> firmware-1.20220308-fails-non-kernels-same-as-1.20220120/boot/
>>> (I did not repeat the testing of the unchanged firmware.
>>> I just did the "diff -r" to discover the lack of change.)
>>>=20
>>> firmware-1.20220328-fails/boot/
>>> =
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files/boot/
>>> (Since the .dtb for the RPi4B was different, I did test this.)
>=20
> It looks like the extra messages, blocks of:
>=20
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
>=20
> Are tied to new dtb content in 2022's dtb updates:
>=20
>        cam1_clk {
>                compatible =3D "fixed-clock";
>                #clock-cells =3D <0x00000000>;
>                status =3D "disabled";
>                phandle =3D <0x000000e2>;
>        };
> . . .
>        cam0_clk {
>                compatible =3D "fixed-clock";
>                #clock-cells =3D <0x00000000>;
>                status =3D "disabled";
>                phandle =3D <0x000000e4>;
>        };
>=20
> These 2 did not exist back when the 1st failure mode
> started. They appear to be repeatedly processed from
> not really being handled --leading to lots of
> messages.
>=20
> The messages may just be noise for activity that is
> not contributing to boot failures at all. So fixing
> what I called the 1st failure mode might actually fix
> booting for all the firmware versions after the
> version tagged 1.20210805 .
>=20
>>> The failures look like (each test shown) . . .
>>>=20
>>>=20
>>> . . .
>>=20






=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Apr 28 07:14:15 2022
X-Original-To: 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 D20C3199533A
	for ; Thu, 28 Apr 2022 07:14:26 +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 ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpn1F2fZyz4cwD
	for ; Thu, 28 Apr 2022 07:14:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651130057; bh=ASwlftHcOHx1gvAYmam46uCn1BfPo6MFLgz637q8TBU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Cs65ATC4soxvcCs0a1/lzc3c5a3MmJ+134EdwqRFQ3fhZhJaS4arGrfiBYes/XZd1sES3HFbEYh40tj87nk67JRulG8D2GibpDbO0zFlIe4mEWH/1ySd1RQyebcc8CfbdAf/VQy6X2EGg+wZk4keopze0jMlAjfqcldJqPLkQCyJbu2B/w3OBkzl6r66kSFePEvghf1awy6QJ82UR6WwYhLwAqd4Xfqt63oILZEkwDhvyPQrbeJD5ex5nElcPHckQDuM5GT0dOzAbkRvbu/u6LQ3BIyfcWyLiQMnjoUcCWZs7d+TEgJvxJXV1m5bLXlwuWvR278U7mmG8sEUpkFSWw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651130057; bh=wRGQYdC4s7hZhg/zXVL7/iG7yxHKGhReb43WgReLgmY=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HnDz0S7o90IjsAUNQS05co1L0U1t+cUUuP2+cUO7sdJRU3aYHBvyf2WdlZm+0r+dIb7Tn4DqgIsRSLfcCn1eKzjf2k7Qj/9Q7NeepoOtZB8i2opR7zBvJVbGvDuq0j1pfGhBK/g0wfDwV0BeS0rtYilBk68BjtUhK/ozuv3Qg8DfB0wZBfgKJKVZNfRpcUOX3UgqKYyNct6HDh5LdIHEJJyfRQ20g6EnqycemoK+mVnUxMheCkxcXJ0eZR3gOJ4Mz+gI4Ok90NHW0AAox0iNBFRRQMFPyt/0+Igv3YV0pcUYJoE8X4sgo/AavhcIkvmXKXh9snyv1zv8xdROns2ppw==
X-YMail-OSG: M3w1WrYVM1kumbBDvmFQNcVWK_nfoN3vMBpRXyLU0m.x7Ew9Sj0yZu9p2IhlE9v
 gVgZ.j8i574K7w.QF_iltBECTV7ovRoEKTDy121ydc1I17ZQdjYXhnpblRk9UVrk2RmA.k4q.nv0
 fVn.cDczQi0clRjqUsCRHfjwhkeRQyJaH5bI5Hmc_hNd6ip7jFYZM3DLydCcR4Td2iNaJII1PReu
 F7oJ.ztonxPgm_KngMGJXkh6_AEexuFPZsP7OhCNw4r7mXDkyDM8dSj8XZx07h2Y6Vif9zyzKs9M
 0a79qjrIbkrvS_kdMHW3pdXSxT92smWZ4m.eTdmFo4e5Rdz_5PpK2uJRwxE3_g4XZiaVcruc89ix
 UCiiPUhryArNg9Ic1aZGxlrinbjf0t72djp0mWGQLisAb3dJQujTJTMW5HjgNcoWPojPKQJ842Wt
 Ey.onR4L0W1TC5Ux9l4fWSiqcO7.SfjTlPbo3k._i2kEFrjJd7IwKJQtk2TBiQzxtPcOHFmPf1RO
 mMsfh97eYeCunQZl_gDwYdlGBxsYd8cUH52n.5dP4Ey1ZSzb0_X7PjxeiIdUlxkcnYfv02_gPQD6
 O_Aw7cUKXhGL3dmu85QNr9P4nefqwHL1U_0kgIkeMZAksIrhoyx8EU_znWU_Li9996NlSYZxOaMP
 WYhIYt3Zbo41OdjpBtxqhJ85GZQQrnARnTW8M4AnvFTLwXqbm.Tsyvuhkqrdbbt3gs4yrku9rzvh
 a1qe8JidQi0vBz4LVyQ8MYCOCWWU6NlV45sZ45VU2J.ko9uI.7AK6ApqI.dTxxCrgzINsUzgKhf7
 vz5djt9h1wIhwURGElJS9RiYZgp6gxpKuEqNjU4T2gNiIio8RTbLEJ3ESCIOANNpsq.CTgk_Xfga
 i.EDZ2o2QXKm2wpMi1btt2u9RkTL9GPtr7rC8HUI725XR.uT9De32WnKUSkDjjOE2ozNv1lcevwE
 _s7wYbW5B7_zXKRui2WwhPA6E3Zww41sWLQT1TWecOkXD2ydRA22o7DFApbFl5voIUUiK_WV3QOA
 _ShhDridBNOqE5Yfk3hD0vEGSAf3DdF.MjQFehCCoxzvBrgN7uOAuyNxDkrl8r_rCAphA0Y1geDV
 .1CXQy1uzGq69sTDR5vR1Mi7smIBJ72TA7dREz_.JHIcgZmzrml78y0lx.ZioqEvouW6NIAYYr3C
 P9aCLxgsLfWPbUnp4b9mZMnwJn.Zpm05nJL2NlzuoJ_Eiy9CZORV31uCUeU1HCtl83zcovSJ6U3X
 lJabU5fKgnlbAaIouKizEAwrkjLMq7AsZfhvRpiNxa4olGgIBxIoDccijyTRybGmyEwVAPuSdiNG
 CTrPnEKvcvVIzTXCnEfWKQHRaFAjJRQ3a9dUZkcmYMBNhTQ_OHZyvY0FiRQXY2CeBlN_nZqwNsjB
 cZqomjaFq1d9Z8TFTEuWxRVDDXQhaeSn98XZIrJ8IqzxL2rkEi2zmBbhEy1Q81H_dLCQQ2ep9Vea
 f3TZXeBpVxSWIGfbUO0jVMH633yMJxgcCzUmFSONq.M.6kemhlgBOo2LWeNImtC.bepghl1A1dNO
 w5Nowj5Sv9Qdtiupcs4HhSY1mCId78hmTVj2bGrEz0nTNWorBtWVHzxb_Jlj1pkKm_f_vlc2B8hd
 kiGRsMeS0b7YnEoy7h8TyYsXPsHY1EHGzvN.V2YMFEPKbDrMh3PPSzQnnnQqwxmSg.Vw.59RUDX.
 tSK6asYLNXQcPuuRUc9w2VdwiisphYqXWLUGaXXhk_OfYKmRjA9hgXV5hlF47GOE6F.EscUCI1c8
 vWW9bShZVRzFf8rd6mBiE_nujU7uoRXw7pVnYHjWKo.x1utGJaLfuaQQRsyRMQxDwWhL69OhWKXN
 egKgaLI8eBkYUeon1IGFti8yMMm8HcmttxSemxG2rrYHUbLfBO.BTtlVKoYb1C.VU5ipH4FHjo5t
 FMF63UlsqEqMWlX2NnOWtJnA9YzqNapo_6CbV2R.gZ9M0lGnJJzbQIoBximv1pqhWp4Rmksoj48v
 rkn12G0UQUmr_TuLy0Jo3aYR0gx0QTCag_bRZujXhNvD0A.D_9HsDwLA2GdDcrJYP_STsimc7XSS
 mX1HPDSpWnQBMP4rk8qKiAKjoAx2WIBtGo4oZbakZ4UhYUHftiy_RR7O7oOLZtzUTCDLyP.prfL7
 GFFY92k.abJn5TN1WpsPL196sCxgVSK9J42nf3nxiSzabWB86XVJwSbIi_doS9L9BSom5j4Vh_8T
 DMp363YNpVXCkUFr9cWr05EazO3q_hDTM8dpy8qN3mS9R2_J9NIyUDb8TPRt.Cka2ldEui1zE8Yz
 2kw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Apr 2022 07:14:17 +0000
Received: by hermes--canary-production-gq1-647b99747d-ndj76 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d2d8d20abd8a2c4d4f2e637cd3ced1b9;
          Thu, 28 Apr 2022 07:14:16 +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 14.0 \(3654.120.0.1.13\))
Subject: FYI: RPi* firmware tagged 1.20210727 appears to be the last to be
 bootable by FreeBSD via fdt use for both RPI3B and RPI4B
Message-Id: <80574F1B-1248-4B57-8E9C-CE92B5000908@yahoo.com>
Date: Thu, 28 Apr 2022 00:14:15 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <80574F1B-1248-4B57-8E9C-CE92B5000908.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Kpn1F2fZyz4cwD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Cs65ATC4;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.981];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1436
Lines: 62

I got ahold of the RPi3B and discovered that it was not
bootable via RPi* firmware tagged 1.20210805 . In fact,
it barely produced any output on the serial console
when set up for debug output: 2 lines, so very early
failure. Reverting to the prior tagged release,
1.20210727 , worked for the RPi3B and the RPi4B.

The failure information for firmware with tags after
1.20210805 in the earlier notes to the list still
apply, as does the bootability of the RPi4B for
1.20210805 .

This report is still based on use of my build of U-Boot
2022.04.

This report is still limited by the very limited range
of RPi*'s that I have sometimes access to.

=46rom what I've read, 1.20210727 should handle the new
type of PMIC on the Rev. 1.5 RPi*'s. The firmware is
too old to have:

bcm2710-rpi-zero-2-w.dtb
bcm2710-rpi-zero-2.dtb
bcm2711-rpi-cm4s.dtb

or the newer overlays:

adafruit-st7735r.dtbo
cutiepi-panel.dtbo
fbtft.dtbo
imx519.dtbo
iqs550.dtbo
mcp2515.dtbo
midi-uart2.dtbo
midi-uart3.dtbo
midi-uart4.dtbo
midi-uart5.dtbo
mipi-dbi-spi.dtbo
mlx90640.dtbo
ov2311.dtbo
qca7000-uart0.dtbo
spi0-0cs.dtbo
vc4-kms-dpi-generic.dtbo
vc4-kms-dpi-hyperpixel2r.dtbo
vc4-kms-dpi-hyperpixel4.dtbo
vc4-kms-dpi-hyperpixel4sq.dtbo
vc4-kms-dpi-panel.dtbo
vl805.dtbo
waveshare-can-fd-hat-mode-a.dtbo
waveshare-can-fd-hat-mode-b.dtbo

It also has one overlay that has been
dropped:

vc4-kms-dpi-at056tn53v1.dtbo


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Apr 28 15:11:42 2022
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 329F51A1783E
	for ; Thu, 28 Apr 2022 15:11:45 +0000 (UTC)
	(envelope-from nick@i11.co)
Received: from mx.i11.co (mx.i11.co [159.69.78.69])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpzc02p9Fz4WY3
	for ; Thu, 28 Apr 2022 15:11:44 +0000 (UTC)
	(envelope-from nick@i11.co)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i11.co;
	s=omicron; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:
	Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=lKOxpJR4KbRPh/eaMy8czhoUAP3o+BMauuQuaJCJNCY=; b=BiutG38z8wY77XrGtygZIWZsQJ
	8Axwg45vHxZIbxz0Ruh7GYclYP/vaFnT6ZcQ/kehxs9nw1UF4dnEEEQ0Xf0U3mEymPgwV/AAFo4se
	XBgjnSP0O38HG3BkzY63h6HKFOIyrJ+PBDm8/0ns3bZhYQzrH/HSsuGARAqmD2BbC9kmfzdFjQIIN
	o2Je/5mTOM4+nYq3xoz7Q7w8BXACtKEyIMTi3632TwJiInTG/qPQYnrnmiJvLWN5bz8rj+GYcs2W8
	mVKU7P7lSljhEwS5hgGBPotHC6KOnHeMIGl3Dh5iun00jkoqXFULKhwyqN6fvOLP+H8V1NIrFdAxq
	l/TJlR4w==;
Received: from [91.206.111.188] (helo=thinkbook)
	by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1nk5nz-0001tC-G9
	for freebsd-arm@FreeBSD.org; Thu, 28 Apr 2022 15:11:43 +0000
Date: Thu, 28 Apr 2022 18:11:42 +0300
From: Nick Kostirya 
To: freebsd-arm@FreeBSD.org
Subject: uart1
Message-ID: <20220428151142.5c08cdec@thinkbook>
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.2)
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: 4Kpzc02p9Fz4WY3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i11.co header.s=omicron header.b=BiutG38z;
	dmarc=pass (policy=reject) header.from=i11.co;
	spf=pass (mx1.freebsd.org: domain of nick@i11.co designates 159.69.78.69 as permitted sender) smtp.mailfrom=nick@i11.co
X-Spamd-Result: default: False [-3.03 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[i11.co:s=omicron];
	 FREEFALL_USER(0.00)[nick];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[i11.co:+];
	 DMARC_POLICY_ALLOW(-0.50)[i11.co,reject];
	 NEURAL_HAM_SHORT(-0.53)[-0.527];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 638
Lines: 41

Hello.

How use uart1 ?

I want use MCU wiht UART interface on NanoPI NEO.

I use overlay:

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";
};

&uart1 {
	status = "okay";
};


# dmesg -a | grep uart
uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 35 on simplebus0
uart0: console (115384,n,8,1)
uart1: <16750 or compatible> mem 0x1c28400-0x1c287ff irq 36 on simplebus0

FreeBSD 12.2-STABLE


For test I connect two NanoPI NEO by help RX-TX.

On first boart I run
cu -l /dev/ttyu1

On second boart I run
cu -l /dev/cuau1

But I cannot write on first and on second board.

Please tell me where is my mistake.

Regards.

From nobody Thu Apr 28 15:16:56 2022
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 41A901AA8D53
	for ; Thu, 28 Apr 2022 15:17:04 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpzk72RMrz4XCP
	for ; Thu, 28 Apr 2022 15:17:03 +0000 (UTC)
	(envelope-from freebsd-arm@dino.sk)
Received: from mp2.dino.sk (fw3.dino.sk [84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by mailhost.netlabit.sk with ESMTPSA; Thu, 28 Apr 2022 17:17:01 +0200
  id 00DADC5D.626AAFED.0000258F
Date: Thu, 28 Apr 2022 17:16:56 +0200
From: Milan Obuch 
To: freebsd-arm@freebsd.org
Subject: Re: uart1
Message-ID: <20220428171656.0922112a@mp2.dino.sk>
In-Reply-To: <20220428151142.5c08cdec@thinkbook>
References: <20220428151142.5c08cdec@thinkbook>
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
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: 4Kpzk72RMrz4XCP
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk
X-Spamd-Result: default: False [-1.45 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[dino.sk];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_SPAM_SHORT(0.85)[0.846];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 874
Lines: 48

On Thu, 28 Apr 2022 18:11:42 +0300
Nick Kostirya  wrote:

> Hello.
> 
> How use uart1?
>
> I want use MCU wiht UART interface on NanoPI NEO.
> 
> I use overlay:
> 
> /dts-v1/;
> /plugin/;
> 
> / {
> 	compatible = "allwinner,sun8i-h3";
> };
> 
> &uart1 {
> 	status = "okay";
> };
> 
> 
> # dmesg -a | grep uart
> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 35 on
> simplebus0 uart0: console (115384,n,8,1)
> uart1: <16750 or compatible> mem 0x1c28400-0x1c287ff irq 36 on
> simplebus0
> 
> FreeBSD 12.2-STABLE
> 
> 
> For test I connect two NanoPI NEO by help RX-TX.
> 
> On first boart I run
> cu -l /dev/ttyu1
> 
> On second boart I run
> cu -l /dev/cuau1
> 
> But I cannot write on first and on second board.
>

When I did something similar, I used /dev/cuauN on both sides of
connection. Maybe you should try it that way as well.

Regards,
Milan

From nobody Fri Apr 29 03:33:54 2022
X-Original-To: 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 E10791AA9FF5
	for ; Fri, 29 Apr 2022 03:34:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4KqJ4W1PB3z3NfM
	for ; Fri, 29 Apr 2022 03:34:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203241; bh=AInJasH+YSK4rxjAx5dV7Te32giu6Q9tE2z63S3+Rhc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=lAth9PWfxU37KdcgRHdMfUbJQqI6oue4QJGXFcC+XaVWi0YBT3o8aNOv7Nypk0oic1JgPGEqnrAW29ri/FJg2Qjl+sUcb7ZVNqPalv0yoabkJeimwj9LW2gt3KCrqshxgOQDgpA3/moPsYnJ6aicYVSNtcwZnZ3Fq/uoYoX3v4UFi/AAAPxSBk5K26UmmmCO/5JupPdehbuNizENtPPoXjEiWxIOkSPmhLtVOrkYzUzxo4JJtMU6w+HKO++Pd8pUqeM+UEEGbizfS58/hFXyPjKaREcmbPDcXOxy3WJhkgCLvwgEPqvmQXC6zQG8rl9afhS0vagSJkrNGQ1x2fx54w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203241; bh=nx/r7OAb33szMhXtk07q2TkZfvyuAeYgiR/GPldFqzJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qeiy3K7wh+WlztHR8t5aSv9bRD3G+brG4fEnfOV2fSipWy1Yi8bpBjaRW0hIY5A4o9mf3mh2jw8v6xDuS9R4Gj2wWLrIx4aZFLisfmT6bgPKA2eDNu56mDMtglT/MZZdo0MiEZx/mzcyY5AX6HSJqNdEMpTHXmfTqqk0UeWyvrzB29kRhSkLm8leXsC1bxNfjNXnnFaEX9plNd5DBAdLfe7upIdF9zP3vEs9UzDvmXeHVKQfbp7Pc2RhB8m5ITRI1dhse84wslr4IKYUxThY/kjb4Sklf8c/+bQ4qYGY8ZNaTEacUlqgx8uHn9xJqxOkfdKDoGvNV9JMc+7tCXwCAA==
X-YMail-OSG: mrhvApwVM1mtIxjmI9d2jSWw3IV5rBp7x0_TYnueewuo9ApsN4JwXBwtCZPISz3
 WEv3Kequ7l3AFhQtZJQdMjTGEqKji6Sf534dr.EY6eldTjhxm_RL6BKZDzVxwu_ZTHurcaTiAan8
 Y0d1tzlAxyrOc7QVnRpdVpP3UrVU.IqISH7JQVH_7sOdzlGc4ehdQgDziedyxX6ZXWc_HXbhEWJL
 WZbj0PyPzwgmjFuLwtrT6mnAlEGY9CCzYy7Cz2xKlrszaMlaC7pt7rCow4WleeAzGjyevSYbmAPo
 J27xu6UmpMjicfpuClWUOCdzo0Fiec2sD_536rTW8GblK9KOV16.G9gEnP_Hbn2ofR2cA44URWnf
 jOvNz.7l5_gWautRWgkPZ4ZIb0yUyCrcqvKd36O_TLBrJ0yWr.s9NUjTz9greOOzlLA1xvQtjBft
 wem3JuAu.FWQk_eARwKAsMcP1A6UOP8cYoF_v9dGducGZONqWMP0J9apK.kGjx6jKiS5CKbq6cE_
 Iqoczi2YhaDtdEsS8Gm99HG1EGo8fGp52bNo7wxGhC0eGGmfBxw5o6Tp0WwdRAX9KnicarwFKbgT
 FsbgW9Tsjvd0QRINXEMVxMhSh8sI4KohPIKhp.o0gr4D6Ub2tXrgK0iD.QmAtNb.9Lvpi2TEKPrr
 orvNGUo3n4qBa.6R9aJrtsSvUOBcuYt_jOWHeG.uSug3wS53wIfKKAkx9HFswqNxllUH5R4Ui9rH
 cgs1pGjueSPj8RbFA9.4mc0H0Pem4tV_cMWMPzqTa6jvlFGjjUVCG3sEQ9ph1LVPYvl7EakCCcFg
 KS9GeN.3vYOl5HlNeE_0gAPRBMyYEiFo6cKEs4WfdWM7D.CdJFasus7DuOKKqeKFTAsLFdj9vK33
 zdlkUeRNm2EqH66GPmKwJ6AiG1sOe8fxNWuXbE8bJR_hFeDITgzvNQr9a25G72oD7mXRFEoYvlPB
 5sQJQcYrh47uSg7Mku1x0ZU_BGCfLhBrNjuhvadkdVOd9MRfvQtJo.w0E3C0UDHnzrzhnfolwwAX
 L8RWer1PF4mx8QV6QF3VwNDmivZ2Nf.xSio20hPY6NgTUHd6ib13R0e7zG7nzNMHBcEzbTWmvELd
 TJbYXijIU8JplqR86dpU0MtQzWQ7jpbvdCeauvLHSB_Wxj9p512zAhMRqH35lI5jVIWPaaVDevV4
 xkKLmHI9iUc7BPkFEna9_EUi.pED_luIcXJf4G7ETX1UZL8lZ65b1S_JhY71oXIJ3eNFeTJkKFKX
 oyArVMnTx3hxx4UYDHz59cPDz3zCqu46FY9OtmSkUvAEFNx3X6wgm7mRMPmmuVtZgXoUznANehUP
 K0g41HI9kMHMB2ue6tmVieuZH9LeXnzJ1S1atlac_zD9fFGndKqFf_S4y6rc6D1tO8T8bZ0hBi9Z
 jVcIam64RIzOlgiWzjlih42e_gSBggYROPDu5fgRuc_m4JTGjkVXkKa4Fje7g3MUwYQnhgoooPyd
 o3hNqvdDsqn99xrFUEfGggEBzhHoZBpyIF_ukNVik_jkxWRom7NSqQMqSM_ZWILYi4ZaQ9gtkBU9
 8CY6yxg3Z833U2CJNSrVtnB59FK3DrZW1XPS72XhzU1hK1FrTEzB4QTaKEgGh48PlMeE3oZwhIqi
 oFxfMJmAQ1DIr37AbH6Ibuu7aVJXREO7RtDWlgzCQ5THRffUHrXPFqcVQzs5iByYyFrGfwY62Sky
 5wv7R5rFuEGpsKjlpTp_nYCwyYF4hWIjsqfF1F73EZXzaj0QtKLAFDYjiqnURq3oU43dsyuwK9ri
 yf0_hlq.kCQ62gedeebDLzZYNHVfLbSORYcWqRxqNxWR1J9U61YA.uGDWaG_1xTuAFtRdQ2yBUO1
 XpXLPvTQLDQvtNBOGVMWXJXMOPElxZbzZdpnnMHANXjnnESl_xWg1AQ8XbWq5yu5c.httwLBgIXf
 GYMYfGyRKjPKXpnqGqOJ6j1acxANsbt63LO1Nl6gA_6db9mpkM0jEJx00Ax8VKwcUmtRiBMJfp17
 bQdXx87.Ri07zIEo1C7aaRqJsBiRJXjCfPGVAQnKIvXbuk_822kg26mvvBQlHzrMk6t8S9RbNmDV
 74XajqIVG6I16dZJMFF92O5zAEKAc8ivLEh_QZ.pU2DqTNcmbkzwFvpFs2JMJI_KB8ePaBfw7oz6
 CcfA2C1IchsladJCt9p6K0y1IsXUrQCfLSCVZSG2fJwvBaIDgCZ6By6IfJMN2_ljIzAhZf3sdn8l
 fteZRDME3OINSHStx0wD8dkjpOOyTtboaZQFq5C2fr_aC5hkniboRu6pf_VRnmBr46_hIjJT73ce
 ID702jg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 03:34:01 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-rlf6p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9d6a87c330764699ade55e78f8045f66;
          Fri, 29 Apr 2022 03:33:57 +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 14.0 \(3654.120.0.1.13\))
Subject: sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: variable 'sc'
 set but not used [-Werror,-Wunused-but-set-variable]
Message-Id: 
Date: Thu, 28 Apr 2022 20:33:54 -0700
Cc: "freebsd-arm@freebsd.org" 
To: freebsd-current 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4KqJ4W1PB3z3NfM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lAth9PWf;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	 NEURAL_HAM_SHORT(-0.98)[-0.979];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4822
Lines: 120

In attempting to update from main-n253904-4d1ba6febfa7 based to
main-n255108-9fb40baf6043 based, targeting aarch64, the following
code from sys/arm/broadcom/bcm2835/bcm2838_xhci.c was rejected:

static int
bcm_xhci_attach(device_t dev)
{
        struct xhci_softc *sc;
        int error;

        sc =3D device_get_softc(dev);

        bcm_xhci_install_xhci_firmware(dev);

        error =3D xhci_pci_attach(dev);
        return (error);
}

as follows:

--- bcm2838_xhci.o ---
/usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: =
variable 'sc' set but not used [-Werror,-Wunused-but-set-variable]
        struct xhci_softc *sc;
                           ^
Building =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72/imx_i2c.o
1 error generated.
*** [bcm2838_xhci.o] Error code 1

make[2]: stopped in =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72
.ERROR_TARGET=3D'bcm2838_xhci.o'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm=
64.aarch64/sys/GENERIC-NODBG-CA72/bcm2838_xhci.o.meta'
.MAKE.LEVEL=3D'2'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose curdirOk=3Dyes'
_ERROR_CMD=3D'cc -target aarch64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch=
64/tmp =
-B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr=
/bin -c -O2 -pipe  -fno-strict-aliasing  -g -nostdinc  -I. =
-I/usr/main-src/sys -I/usr/main-src/sys/contrib/ck/include =
-I/usr/main-src/sys/contrib/libfdt =
-I/usr/main-src/sys/contrib/device-tree/include -D_KERNEL =
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common   =
-mcpu=3Dcortex-a72 -DLINUX_DTS_VERSION=3D\""5.13"\" =
-mstack-protector-guard=3Dsysreg -mstack-protector-guard-reg=3Dsp_el0 =
-mstack-protector-guard-offset=3D0 -fno-omit-frame-pointer =
-mno-omit-leaf-frame-pointer =
-fdebug-prefix-map=3D./machine=3D/usr/main-src/sys/arm64/include =
-mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector =
-Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign =
-D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs =
-fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error=3Dtautological-compare -Wno-error=3Dempty-body =
-Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function =
-Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value =
-Wno-address-of-packed-member -Wno-format-zero-length   -mcpu=3Dcortex-a72=
  -std=3Diso9899:1999 -Werror =
/usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c; ctfconvert -L =
VERSION -g bcm2838_xhci.o;'
=
.CURDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/sys/GENERIC-NODBG-CA72'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/sys/GENERIC-NODBG-CA72'
.TARGETS=3D'all'
DESTDIR=3D''
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220208'
=
PATH=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tm=
p/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aar=
ch64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-sr=
c/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-nodbg-c=
lang/usr/main-src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sb=
in:/usr/bin'
SRCTOP=3D'/usr/main-src'
OBJTOP=3D'/usr/main-src'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null Makefile =
/usr/main-src/sys/conf/kern.pre.mk /usr/main-src/share/mk/bsd.own.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk /usr/main-src/sys/conf/kern.opts.mk =
/usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk'
.PATH=3D'. =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72'
1 error


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Apr 29 03:39:55 2022
X-Original-To: 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 239611AABC7A
	for ; Fri, 29 Apr 2022 03:40:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4KqJCR1l5Gz3QKm
	for ; Fri, 29 Apr 2022 03:40:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203596; bh=ctOggl3IxsgNzu+vQLJ/0lgNpkCS3m42ynU9rxcsyPc=; h=From:Subject:Date:In-Reply-To:Cc:References:From:Subject:Reply-To; b=IAk3zpTqiOwmz6oqO2OKtI364RpTAsiLkrSgTqzfq3mghVHHmAxLE4VwvBZi33ci9CEyYLsq3MijFUv1b6lFrR8XObwxGl/1gcWMloHPlcXHc3SAapE1g47Zrknz+da7kXt9LWy2FbGkacdFOJXAnkE6NRblOP/Wxayf8cJwBqq5OGoTj5hcG+sK21f06AziFltFZHtL4RoTjb4GsD/fA2tejX5yF6JR41rgLaTx4Y6IoWQwZSGgrviPw05IHVgXqeWMTVn9s3UQLO1BwWXz9OZKKD7C5pfTKKOCicAERl/NoRlT1XhPnxbXO8rZi27A93RUzR59G2y7qCVC9WIrbw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203596; bh=YOVF3H3XrvCNob4RbNzP8WAFBY3hPbkn2LdijwNtag5=; h=X-Sonic-MF:From:Subject:Date:From:Subject; b=ZFNp7TDZ0RabQq4W92443UrSCq708oxL7Gxq83rT6cdolACWYqW1vtkomtLRBU0qExbr0Lu9NYu0UsbTtNjuYAndNdwlDDwjOolMlBUTCx0GXdwX0qzG3GP12TlfEzJ+CKEg5JNVm0QwK8LN/rnJjyEJX5xx2W3gaRCQkR8lgC/IDkfrkFp7603wjZ1wi8uYs2RAVydvw4T4Hs0WOauqewQ/Pq8fMqmk7m7N94d4cV9baaXl+gd+Kdy6HlukmeMsXyx9EYG9FOWyn1gkeHIzpHas3fDHHnfnmb/O7fOK+4op6AcaHgKPFMrnBJcMns3VpLRY/Djkm/Z0Dzd9RBIXXg==
X-YMail-OSG: _34r5YsVM1m596975NzMplx8.Hj3i0AWQ0R2ICC9Zyb5vw9BmzHMR1x2.gc4R1T
 MdwO5vSTXq.agHiW3O2XsJXpbIS.yDcwxpY59FLA6zK_2X4.4hzRpsSDz8QPRneJUkQUP_7sExAn
 PwAiE4yl2Ps5TbxuwxkpnoHFEWJz_FoeLOFF3XoLroTaexTsdteqQYfoFeVlGTE8gqV85ZG1hSdm
 4Qaj4stLwNFpzBkdbAQ8cWZ3ThSAkhtTuNmVjkFIapZ.q.VCM8CvxsNEhRjwjRYnTO2CVfYI.2bk
 EYWxaP083KF63CjdNIp6hqmhuHO_pDkqbL7LXIGw4vEDnRgCUmvzK5FYpw2iVeQ09YxreMPD49xr
 _Q4JWUJ7Bex_QALX7FAWkeBcA1yi4zOGf39_VCtRhtsdV75tLePAuKC4kKyHJ3hNQ2XF6VT_LugK
 0iaGONBN7ASM2.IGh2tsvKkNSWSVNWYwupHgpnuqTLkq8dO42yD8eT6tTn.le3JxrCwZooA6_d_q
 Sx_HjE0KfBW0TXlXwW.LTCDiJ4u3ZYR2ahaVHRWZAvE.m7IgjTptAcl5_IynCbl3vBlRfPD5iDeS
 mPUIJlN0J0LFUR4w8EgKfvnBNrZrjTh6QlS6rg1bY5xTtwZ5ZESFS8PISCGO3yhn7xK68jFJrJLr
 2S7u0lzldM6ezcNj5crgauxEhvHmiY9vBZPjByrzZyEaOZzBhlIlb8.0fp1ePceAUZ0.vkK04kdN
 RCv5I8EtqD7KcheDS8DOQii4wyz0rfzA8QtekNp1eUnLmmJMMGkeF5Tf.Q.GrG1S.NengrhcCpoF
 eGrz87S8di5yhU5cySlxGJzgKLwzjb6YufydbMY4.H.SVTwILysDHrEWp8nIgKjp3kt2wltdzEyw
 cTn7dySejwKQnGwqHktl4LV1mdXGCGyZJtCUGKcoKbsAkd0m02lnCwmY3fs0u3iwTIoohIuS_OEK
 Cvj4M_xRVopEjY0uxAzJVOTSC.Wi5VU8R1_woaQfBDbDuXUmHXPE4swlpeMnWHX.lcLbd_pIITNL
 9j37VlTgg621EraUMt9f_OsDSgmUeeJYLTSbGUp4WJKJaWmOwlWAOBRXmEN0qjGuynNqTRJ2TXJA
 HIJJV6Mb4IrMwWpSvjIOOA8sSLk23CfW8_GgjkHydx82BT80CsPgaKo1FVnAkQEwZ9Q9QJAzzi1D
 v24Hb.wbAaayUDNURfR3UHxIOGjFbMWy_O7uRre.Bju7T7vEAC.gRS7Ai0i4wmKgAz9EAHN1OkFy
 F4hYnMoUCxGRLJqo6NmxqytVuYvvE2d4rilha3zsWLqvj9Ukg7z_pCurO_aYGihLf3Q.emUCNlgl
 inPLcd9lqVVRlKrRvF80Ai8x8.trAY4ts9V4amCgcGPmmaniGekWxsiXTe9._g1synovigGyzqXh
 D3FiscsKhRQKYVf4AD4jzpYUxH.dRrzxRl84w5Ox.FcBbm8vcwTbpQWu1SrftIeFdu3Q0r3va2SV
 xPmOS7wbQ.rKf5ui0QGbRMqnFVPwXgcAi1wjMpefBbms0.rIko6omTPhLgQCOw5ADZ1zdxBol3WI
 xru9jP2YD8XqnqhVYZsPSEQTOo_F4vbCgHmgJ9i7lmlBlMPImwQbNDamLUG7l84o1Bd3mnq6GY_3
 2U67EyZNGR1ltLZJzLRG_gFtBszDORwoTSd63GFH0d9sNIaGrU5cFpJdwGUJFNTmgFYh.r_wffiT
 5m_y1GdRz5hKRkkZw0EsulaFDPGfwmNONUfetpUnzrBPULY54yFIV7AWv8YOg4kZmzCGOPD_Qwyy
 VYXv6nN2CUVFTZrdTDqem5nst.QnI7I9GiRE5HRf4MvBO.OdOJPnvFzKgT1Q0JOc2hpWptEvvAI9
 VEV5IuD.rwzj9uQzmHlkS98JLGO1q6W3nCJx5tl6YAFu5f0iicnUS46Du3t9HOToS3.XYziTnds.
 aEZQ6kOE5sgUZKqDci7GReXfueU7CisLUv8eDJASBfpCcFhm3EY2lwLe2hunvabgBLVBoMPjoubj
 I0BFhim_hLZNiaOF8UHtMlpDkf6pwCTkYMKfecGEGnIUMC0vOZOzvGyUc1GBhkHjbT7ALBHS058A
 gfH_I643s8fjHBq0V2RSiTajKJzgYjK3Ws2Q3jyseHqByt8IVNNrUz0c7sp9aPUdKnggLDERsrJx
 BN_TTpvlKqfBVbQ7Fs2OiUa7Qi0dbwxjXCdzqKz0TfMn7bB.krI4av26UpVF5zBEAJ8iuOOJNTqa
 I5EQR7V2ctiun1yjNV4NX4ISBarnn4qgXkynMgqensmIU1N78Uzuj0UPeBcsHvKaUiaQ53Ee4UEd
 xhcWhUy1mKPlfLA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 03:39:56 +0000
Received: by hermes--canary-production-gq1-647b99747d-7f5lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10e379f45a115d8f19a095f4bc212960;
          Fri, 29 Apr 2022 03:39:55 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: variable
 'sc' set but not used [-Werror,-Wunused-but-set-variable]
Date: Thu, 28 Apr 2022 20:39:55 -0700
In-Reply-To: 
Cc: freebsd-current ,
 "freebsd-arm@freebsd.org" 
References: 
 
Message-Id: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KqJCR1l5Gz3QKm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=IAk3zpTq;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.46 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MISSING_TO(2.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.968];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	 MLMMJ_DEST(0.00)[arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5104
Lines: 129

IGNORE.

On 2022-Apr-28, at 20:33, Mark Millard  wrote:

> In attempting to update from main-n253904-4d1ba6febfa7 based to
> main-n255108-9fb40baf6043 based, targeting aarch64, the following
> code from sys/arm/broadcom/bcm2835/bcm2838_xhci.c was rejected:
>=20
> static int
> bcm_xhci_attach(device_t dev)
> {
>        struct xhci_softc *sc;
>        int error;
>=20
>        sc =3D device_get_softc(dev);
>=20
>        bcm_xhci_install_xhci_firmware(dev);
>=20
>        error =3D xhci_pci_attach(dev);
>        return (error);
> }
>=20
> as follows:
>=20
> --- bcm2838_xhci.o ---
> /usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: =
variable 'sc' set but not used [-Werror,-Wunused-but-set-variable]
>        struct xhci_softc *sc;
>                           ^
> Building =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72/imx_i2c.o
> 1 error generated.
> *** [bcm2838_xhci.o] Error code 1
>=20
> make[2]: stopped in =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72
> .ERROR_TARGET=3D'bcm2838_xhci.o'
> =
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm=
64.aarch64/sys/GENERIC-NODBG-CA72/bcm2838_xhci.o.meta'
> .MAKE.LEVEL=3D'2'
> MAKEFILE=3D''
> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes=
 verbose curdirOk=3Dyes'
> _ERROR_CMD=3D'cc -target aarch64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch=
64/tmp =
-B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr=
/bin -c -O2 -pipe  -fno-strict-aliasing  -g -nostdinc  -I. =
-I/usr/main-src/sys -I/usr/main-src/sys/contrib/ck/include =
-I/usr/main-src/sys/contrib/libfdt =
-I/usr/main-src/sys/contrib/device-tree/include -D_KERNEL =
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common   =
-mcpu=3Dcortex-a72 -DLINUX_DTS_VERSION=3D\""5.13"\" =
-mstack-protector-guard=3Dsysreg -mstack-protector-guard-reg=3Dsp_el0 =
-mstack-protector-guard-offset=3D0 -fno-omit-frame-pointer =
-mno-omit-leaf-frame-pointer =
-fdebug-prefix-map=3D./machine=3D/usr/main-src/sys/arm64/include =
-mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector =
-Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign =
-D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs =
-fdiagnostics-show-option -Wno-unknown-pragmas =
-Wno-error=3Dtautological-compare -Wno-error=3Dempty-body =
-Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function =
-Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value =
-Wno-address-of-packed-member -Wno-format-zero-length   -mcpu=3Dcortex-a72=
  -std=3Diso9899:1999 -Werror =
/usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c; ctfconvert -L =
VERSION -g bcm2838_xhci.o;'
> =
.CURDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/sys/GENERIC-NODBG-CA72'
> .MAKE=3D'make'
> =
.OBJDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/sys/GENERIC-NODBG-CA72'
> .TARGETS=3D'all'
> DESTDIR=3D''
> LD_LIBRARY_PATH=3D''
> MACHINE=3D'arm64'
> MACHINE_ARCH=3D'aarch64'
> MAKEOBJDIRPREFIX=3D''
> MAKESYSPATH=3D'/usr/main-src/share/mk'
> MAKE_VERSION=3D'20220208'
> =
PATH=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tm=
p/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aar=
ch64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-sr=
c/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-nodbg-c=
lang/usr/main-src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sb=
in:/usr/bin'
> SRCTOP=3D'/usr/main-src'
> OBJTOP=3D'/usr/main-src'
> .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null Makefile =
/usr/main-src/sys/conf/kern.pre.mk /usr/main-src/share/mk/bsd.own.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk /usr/main-src/sys/conf/kern.opts.mk =
/usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk'
> .PATH=3D'. =
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER=
IC-NODBG-CA72'
> 1 error
>=20

This is because of my experimental patches for RPi4 related
issues. Sorry for the noise.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Apr 29 21:30:48 2022
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 D0C551AA86CE
	for ; Fri, 29 Apr 2022 21:30:56 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kqlz400Fwz3hds
	for ; Fri, 29 Apr 2022 21:30:55 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 23TLUm0q062288
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Fri, 29 Apr 2022 14:30:48 -0700 (PDT)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 23TLUmGF062287
	for freebsd-arm@FreeBSD.org; Fri, 29 Apr 2022 14:30:48 -0700 (PDT)
	(envelope-from jmg)
Date: Fri, 29 Apr 2022 14:30:48 -0700
From: John-Mark Gurney 
To: freebsd-arm@FreeBSD.org
Subject: Re: Rock64 eMMC not working
Message-ID: <20220429213048.GL88842@funkthat.com>
Mail-Followup-To: freebsd-arm@FreeBSD.org
References: <20220407040810.GD88842@funkthat.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: <20220407040810.GD88842@funkthat.com>
X-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 29 Apr 2022 14:30:48 -0700 (PDT)
X-Rspamd-Queue-Id: 4Kqlz400Fwz3hds
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com
X-Spamd-Result: default: False [-1.54 / 15.00];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[jmg];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-0.84)[-0.837];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[funkthat.com];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 NEURAL_HAM_MEDIUM(-0.90)[-0.899];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US];
	 FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 17613
Lines: 397

John-Mark Gurney wrote this message on Wed, Apr 06, 2022 at 21:08 -0700:

Bump?

Is no one working on/maintaining the Rock64 port?

Right now looking at getting the OTG port working on it, but it looks
like the dwcotg driver is completely broken in that it can't read data
accurately from the USB bus.

> I am trying to get the latest FreeBSD -current snapshot to boot/run off
> a Pine64 eMMC module on the Rock64, but I'm seeing an issue w/ mounting
> root:
> 
> FreeBSD 14.0-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 UTC 2022
> [...]
> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
> mmcsd0: Error indicated: 4 Failed
> 
> I got similar messages when 13.1-RC1:
> 
> mmcsd0: 16GB  at mmc0 150.0MHz/8bit/1016-block
> mmcsd0boot0: 4MB partition 1 at mmcsd0
> mmcsd0boot1: 4MB partition 2 at mmcsd0
> mmcsd0rpmb: 4MB partition 3 at mmcsd0
> [...]
> GEOM: mmcsd0: the secondary GPT header is not in the last LBA.
> mmcsd0: Error indicated: 4 Failed
> rockchip_dwmmc1: Failed to update clk
> 
> 
> Are there any known issues w/ this?  A different image to try?
> 
> Also, in trying to debug this issue, I tried to boot from a microSD
> card with the eMMC module installed by shorting the jumper, but when I did,
> I got:
> mmcsd0: 32GB  at mmc0 50.0MHz/4bit/1016-block
> mmcsd1: Error reading EXT_CSD Failed
> device_attach: mmcsd1 attach returned 6
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex rockchip_dwmmc1 (dwmmc) r = 0 (0xffffa000008d2128) locked @ /usr/src/sys/dev/mmc/host/dwmmc.c:386
> stack backtrace:
> #0 0xffff0000004e5390 at witness_debugger+0x5c
> #1 0xffff0000004e6564 at witness_warn+0x3e8
> #2 0xffff00000078962c at data_abort+0xa0
> #3 0xffff000000767810 at handle_el1h_sync+0x10
>   x0:             8088
>   x1: ffff00008e18b000 (ucom_cons_softc + 8ce4ca40)
>   x2:               40
>   x3:              182
>   x4:                0
>   x5: ffff00008e1767a0 (ucom_cons_softc + 8ce381e0)
>   x6:                0
>   x7:                0
>   x8:                4
>   x9: ffff000000b55910 (memmap_bus + 0)
>  x10:                3
>  x11:            10000
>  x12:                1
>  x13:             2af8
>  x14:               88
>  x15:             2af8
>  x16:               88
>  x17:                0
>  x18: ffff00008e176850 (ucom_cons_softc + 8ce38290)
>  x19: ffffa000008d2140
>  x20: ffffa000008d2000
>  x21:             8088
>  x22:                0
>  x23:         80000003
>  x24: ffffa000008c9580
>  x25: ffffa00000bb9100
>  x26: ffff000000b9ea98 (Giant + 18)
>  x27: ffff0000008df336 (digits + ea96)
>  x28: ffffa00000bb9110
>  x29: ffff00008e176850 (ucom_cons_softc + 8ce38290)
>   sp: ffff00008e176850
>   lr: ffff0000007b0298 (dwmmc_intr + 50)
>  elr: ffff0000007b02c4 (dwmmc_intr + 7c)
> spsr:               45
>  far:               20
>  esr:         96000044
> panic: data abort in critical section or under mutex
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2dc
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000044
> dwmmc_intr() at dwmmc_intr+0x7c
> ithread_loop() at ithread_loop+0x2a0
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> 
> 
> Complete boot message:
> ======================
> U-Boot TPL 2021.07 (Mar 31 2022 - 05:26:18)
> LPDDR3, 800MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Trying to boot from BOOTROM
> Returning to boot ROM...
> 
> U-Boot SPL 2021.07 (Mar 31 2022 - 05:26:18 +0000)
> Trying to boot from MMC1
> Card did not respond to voltage select! : -110
> spl: mmc init failed with error: -95
> Trying to boot from MMC2
> NOTICE:  BL31: v2.5(release):
> NOTICE:  BL31: Built : 05:24:37, Mar 31 2022
> NOTICE:  BL31:Rockchip release version: v1.2
> 
> 
> U-Boot 2021.07 (Mar 31 2022 - 05:28:19 +0000)
> 
> Model: Pine64 Rock64
> DRAM:  2 GiB
> PMIC:  RK8050 (on=0x40, off=0x00)
> MMC:   mmc@ff500000: 1, mmc@ff520000: 0
> Loading Environment from MMC... Card did not respond to voltage select! : -110
> *** Warning - No block device, using default environment
> 
> In:    serial@ff130000
> Out:   serial@ff130000
> Err:   serial@ff130000
> Model: Pine64 Rock64
> Net:   eth0: ethernet@ff540000
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:1...
> 50618 bytes read in 7 ms (6.9 MiB/s)
> Card did not respond to voltage select! : -110
> Scanning disk mmc@ff500000.blk...
> Disk mmc@ff500000.blk not ready
> Scanning disk mmc@ff520000.blk...
> ** Unrecognized filesystem type **
> ** Unrecognized filesystem type **
> ** Unrecognized filesystem type **
> Found 5 disks
> ** Unable to read file ubootefi.var **
> Failed to load EFI variables
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> 1263868 bytes read in 33 ms (36.5 MiB/s)
> Booting /efi\boot\bootaa64.efi
> 
> 
> Consoles: EFI console  
>     Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk0p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Thu Mar 31 08:48:02 UTC 2022 root@releng1.nyi.freebsd.org)
> 
>    Command line arguments: loader.efi
>    Image base: 0x7cdde000
>    EFI version: 2.80
>    EFI Firmware: Das U-Boot (rev 8225.1792)
>    Console: efi (0x1000)
>    Load Path: /efi\boot\bootaa64.efi
>    Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
> Setting currdev to disk0p1:
> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(2,GPT,64400726-b60c-11ec-a26d-85c343ffa803,0x21000,0x1cc6fd8)
> Setting currdev to disk0p2:
> /
> 
> 
> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> /
> 
> Loading kernel...
> /boot/kernel/kernel text=0x2a8 text=0x84f4a0 text=0x249adc data=0x1b9aa8 data=0x0+0x40d000 0x8+0x133de8+0x8+0x15b370\
> Loading configured modules...
> /boot/entropy size=0x1000
> /boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6d8+0x10 0x8+0xf18+0x8+0xb5c
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=0x2590 text=0x2f00 data=0x8e0+0x858 0x8+0x1290+0x8+0xbd5
> /etc/hostid size=0x25
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...               
> Using DTB provided by EFI at 0x80f0000.
> EFI framebuffer information:
> addr, size     0x0, 0x0
> dimensions     0 x 0
> stride         0
> masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
> ---<>---
> GDB: debug ports: uart
> GDB: current port: uart
> KDB: debugger backends: ddb gdb
> KDB: current backend: ddb
> Copyright (c) 1992-2022 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-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 UTC 2022
>     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT: init without driver.
> module firmware already present!
> real memory  = 2145136640 (2045 MB)
> avail memory = 2065342464 (1969 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
> MAP 7cf1b000 mode 2 pages 1
> MAP 7cf1f000 mode 2 pages 3
> MAP 7cf23000 mode 2 pages 4
> MAP 7ff40000 mode 2 pages 16
> kbd0 at kbdmux0
> ofwbus0: 
> clk_fixed0:  on ofwbus0
> rk_grf0:  mem 0xff100000-0xff100fff on ofwbus0
> rk3328_cru0:  mem 0xff440000-0xff440fff on ofwbus0
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> Cannot set frequency for clk: aclk_bus_pre_c, error: 34
> rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> Cannot set frequency for clk: aclk_peri_pre, error: 34
> rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clk_fixed1:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> simple_mfd0:  mem 0xff450000-0xff45ffff on ofwbus0
> psci0:  on ofwbus0
> gic0:  mem 0xff811000-0xff811fff,0xff812000-0xff813fff,0xff814000-0xff815fff,0xff816000-0xff817fff irq 52 on ofwbus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 160
> rk_pinctrl0:  on ofwbus0
> gpio0:  mem 0xff210000-0xff2100ff irq 53 on rk_pinctrl0
> gpiobus0:  on gpio0
> gpio1:  mem 0xff220000-0xff2200ff irq 54 on rk_pinctrl0
> gpiobus1:  on gpio1
> gpio2:  mem 0xff230000-0xff2300ff irq 55 on rk_pinctrl0
> gpiobus2:  on gpio2
> gpio3:  mem 0xff240000-0xff2400ff irq 56 on rk_pinctrl0
> gpiobus3:  on gpio3
> rk_i2c0:  mem 0xff160000-0xff160fff irq 16 on ofwbus0
> iicbus0:  on rk_i2c0
> rk805_pmu0:  at addr 0x30 irq 57 on iicbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
> rk_tsadc0:  mem 0xff250000-0xff2500ff irq 24 on ofwbus0
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> cpufreq_dt0:  on cpu0
> cpufreq_dt0: Found cpu-supply
> cpu1:  on cpulist0
> cpufreq_dt1:  on cpu1
> cpufreq_dt1: Found cpu-supply
> cpu2:  on cpulist0
> cpufreq_dt2:  on cpu2
> cpufreq_dt2: Found cpu-supply
> cpu3:  on cpulist0
> cpufreq_dt3:  on cpu3
> cpufreq_dt3: Found cpu-supply
> pcm0:  on ofwbus0
> pmu0:  irq 0,1,2,3 on ofwbus0
> pcm1:  on ofwbus0
> i2s0:  mem 0xff000000-0xff000fff irq 8 on ofwbus0
> Cannot set frequency for clk: xin12m, error: 34
> Cannot set frequency for clk: xin12m, error: 34
> i2s1:  mem 0xff010000-0xff010fff irq 9 on ofwbus0
> Cannot set frequency for clk: clkin_i2s1, error: 34
> Cannot set frequency for clk: xin12m, error: 34
> uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on ofwbus0
> uart0: console (1500000,n,8,1)
> iic0:  on iicbus0
> spi0:  mem 0xff190000-0xff190fff irq 19 on ofwbus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> rockchip_dwmmc0:  mem 0xff500000-0xff503fff irq 43 on ofwbus0
> rockchip_dwmmc0: Hardware version ID is 270a
> rockchip_dwmmc1:  mem 0xff520000-0xff523fff irq 45 on ofwbus0
> rockchip_dwmmc1: Hardware version ID is 270a
> mmc0:  on rockchip_dwmmc1
> dwc0:  mem 0xff540000-0xff54ffff irq 46 on ofwbus0
> miibus0:  on dwc0
> rgephy0:  PHY 0 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
> rgephy1:  PHY 1 on miibus0
> rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
> dwc0: Ethernet address: xxx
> dwcotg0:  mem 0xff580000-0xff5bffff irq 48 on ofwbus0
> usbus1 on dwcotg0
> ehci0:  mem 0xff5c0000-0xff5cffff irq 49 on ofwbus0
> usbus2: EHCI version 1.0
> usbus2 on ehci0
> ohci0:  mem 0xff5d0000-0xff5dffff irq 50 on ofwbus0
> usbus3 on ohci0
> gpioc0:  on gpio0
> gpioc1:  on gpio1
> gpioc2:  on gpio2
> gpioc3:  on gpio3
> gpioled0:  on ofwbus0
> gpioled0:  failed to map pin
> gpioled0:  failed to map pin
> pcm2:  on ofwbus0
> armv8crypto0: 
> Timecounters tick every 1.000 msec
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 480Mbps High Speed USB v2.0
> usbus3: 12Mbps Full Speed USB v1.0
> rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s
> pcm0: no driver attached to codec node
> pcm1: no driver attached to codec node
> ugen2.1:  at usbus2
> uhub0 on usbus2
> uhub0:  on usbus2
> ugen1.1:  at usbus1
> uhub1 on usbus1
> uhub1:  on usbus1
> ugen3.1:  at usbus3
> uhub2 on usbus3
> uhub2:  on usbus3
> mmcsd0: 16GB  at mmc0 150.0MHz/8bit/1016-block
> mmcsd0boot0: 4MB partition 1 at mmcsd0
> mmcsd0boot1: 4MB partition 2 at mmcsd0
> mmcsd0rpmb: 4MB partition 3 at mmcsd0
> pcm2: no driver attached to cpu node
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>                    Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
>  Instruction Set Attributes 0 = 
>  Instruction Set Attributes 1 = <>
>          Processor Features 0 = 
>          Processor Features 1 = <>
>       Memory Model Features 0 = 
>       Memory Model Features 1 = <8bit VMID>
>       Memory Model Features 2 = <32bit CCIDX,48bit VA>
>              Debug Features 0 = 
>              Debug Features 1 = <>
>          Auxiliary Features 0 = <>
>          Auxiliary Features 1 = <>
> AArch32 Instruction Set Attributes 5 = 
> AArch32 Media and VFP Features 0 = 
> AArch32 Media and VFP Features 1 = 
> 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
> WARNING: WITNESS option enabled, expect reduced performance.
> Unresolved linked clock found: hdmi_phy
> Unresolved linked clock found: usb480m_phy
> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
> mmcsd0: Error indicated: 4 Failed
> uhub2: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> uhub0: 1 port with 1 removable, self powered

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From nobody Fri Apr 29 22:47:27 2022
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 009BA1AB80C8
	for ; Fri, 29 Apr 2022 22:47:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4KqngV5hXVz3sb2
	for ; Fri, 29 Apr 2022 22:47:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651272453; bh=rybTtmbCM3wYZ2OwoAWBD/u6EWFn+qAcUiIID3PwC18=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KKoKHLTEjD4kmEKpoS4ZUGsvJsXEGWcQQLxB+IKJHzzQe4CCu0KsjHLKylch3IhFNH4zd9v5yPN9aLzAl9xQL+HkxgZ7yG3pgfdFO5GmUX+kE8FQNhGmXm8M1I9/tfvFOdmYBR9qhkBdYdTS1XO+p4RsyPVjm5PI64LkqorQL1SQnnzvGKNBknTFTXHH1xAIcuGHxXKv9ewaxdW0H4zqEZf18P6964W6s+9K05JKXlc7IC+DamO5VjR20NfEDB9hsQ9ZKLz2RiRC/fUw0C/NKBBq5gqdreu11fvXIPJO4tWJzTn7+/uargQWe5Jkz2nOe+nOFMHb+Urb8WUD6TcRrg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651272453; bh=fdrr0V9YknHRoKxHJCQjcuzP1Zds81Mn4/cY4MtVcxQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FJwNYrh08BWAqXSvtfFj2uIlgLXNYiH2827R39+kPNFyPp4JLcD2hWax+STLD6SSBpQ7gqRSu6BNn4kRpUM6UStbrxPltZ4TvWnnEHpdoa8b9p+OGrLgWMBpGL0ThGvnCdczftnQ+gQdqYpUg9bqMMJE2njuT2NyPZzcny4zwQRXLED9gV+IbvqlGWZkU7G+U0/h3JJoXPa5sIGCPHF4UoMI0K8qXIBDuEmhiPun8cPtoRx2VzQ/OP0qjsI8JIzmAYeuugbxU+8PGz2ZhMVb/yjzzL5shnvOTW8fGiCphsG9ZLGYll/GxHNkny6tlxqI22cCuinfTfAZBdDt7/tZPQ==
X-YMail-OSG: 1PZttNAVM1nDchbfjQlRm463m78ig0RpVDnPrO7DBpyR7gZKUNdGkX4TbyJMWL5
 CH6bX4jRUmzotPFnX7Zhk_7_GXHcwo3ymaAw7gOQm_PWBF_YMSJBnpYoLO0q0F63W1LhnQEKq_RD
 M6A1YVtdfIxjtoVWn3.STpA5MXy_TOtr0wEJ4D.91M6O46yHsCezXU1zRwrxOOlkHXTJdryMwfz5
 hx0Gbd5rEBCx3ziEf9AttzgW48Aui5HLEsdbzVO70B2KOaQ0l8t_jv9Jd7nApef.ay3Qlne1rTjb
 URUcmEPU.lIWxZAPdZobk9WHRS.ehoC77TpHFlinIngdiVNJtd_xYLUEyccXa_MkaysU2R3vzglc
 MU8QVwcUgO5HEAnEhDm4d5VDeeK4UdbguE7oorlF5jE7dKECjh_e0igpwN1MvhV4rp2yZptBhWoi
 y8DFL5NEgVdnAbcwHyO9.YnoypGae5zAydCvWhmU_lagoxYkEvd9iKOhLFHXwfe0XKB2V2GRE1Pl
 WQyccdjl23zc99v8OW2HSoLQS0EEVY96wqKrm2MTgMJ725ttSq69VjB26BgIbOzIrmrrEVJl8tmu
 kyRxJ86LUshKA3a5iThQgOZGCNnSXrU6bIcKfkriR.QHexg3wTUFCgMp1lQsVTSR7yvw4bf8bwyM
 JQDClYI9fgy_GEYCbk72ofPBVXpGi.F7Xa3j27hAP6g3ssQpJnG8h_XEbd8tDcYj6RjooRrmmUlv
 fJLDUTTXqVPo0nQpqzNQ5ADOSBnwjZYQyB4_ZT1YGThqj3vGWQ_6yZxH6i08WH8wosMlHTsmXacX
 UfhxCfvqLMi0x.ldGsk4VcUnZ6r58IM9wUAo0fc2PlcURKdobIeUYUQOHLrvclWUYgi.3Yc61_Nc
 yhO6Tp1FvzmQM8gmF5q45iIIDn5rzKhUlmxdLHYpJ8Q2gr8wo7Y0wa96sdkW83PPJcoxX2jQzfhT
 bzej2xDnunq.3KM1fe6Z1u9sm.PKvMRnCcu9eMtIT16VbYqamR2mWFGNNL7GXcKgVqlYTHDaK4sw
 UE4rW89VvQaSJz7FviB71R7IrvK_v9VaNH7mKnJbXhdRPVkKWQQH_ZF3unIbcldiSlJhibdqM0.T
 Jv6zZe2pKWNXnrmem2emH.3H0DBQwfnR0RF7UZFB_rgE5jakwvkyzvu1idESZX5DJF8e4_6WyMSf
 vjplRcOhz6J3L6xaCtINkjJ.8IcLOwVjHJhfDBYtp5VlB0inzePMdwLmCLIzN3FMd8YL_Wo4NLrO
 IudVEyYLpTUSLZwyb_h1451AoYsg59Os8CWwWguP5kbkOWoImRvGAIHEWJP3yu8a6mZ4RI6AXIZo
 wI25H2T_GCct.5iKw3BomTqV7bebVgetBH8zAm57bWn1B.G73t3Mx1mrMcqk_NjXg9zhJcFUsssp
 ItaDavDfM9SWtsP4QUniCxLQHgAw0BaTR_.j9hl3sranBPk5NtsN6.FHqbFCpFmhtAchnpSs6Y2D
 R1rmFEybTuPY2UpNHrYde9vOQ2GR_3kSGMTtdYtwY1ITvbY2Rt1fiPq8uL9ftUiu.6t5MH1ygJSY
 Ua4BvngALdlyNiFjlC4wVq_BHKlnJyjTEKIbJpVZEU5nvK4ViXRm3x5GR3ZEok8jhvjOEXJ2wt0F
 Nj9F_BwPtLO8I5rLwpRh3yKsxgVDL43RdBRxIfvsMrAp6JngQWI8LsXP5fTxdHegcwnXKUdSySpL
 0WlG1LPF5jjsfBcUM07zIvNQkf5og3O3ENE4tsdFMCuuwSRtNhX1mIy88AfazNjQssT7Jzugoc76
 7JsEHsKgA6noicmzQvDIXGJUdup6AkKP.gfrvAOnAsVU0kt3cEfa4Pl1sX6MyzxAEy51Iz_47xKh
 P2ZPKmbup2pu0B.KfOBFWNvrejBJTShXH4aClvCq9flhPiJEMETSIsF1RIUCadNgUV7e7poftbM7
 wXvSIhw7hFhyKWkQf1VFKwih2fRU6ei8kyOJGxWSCRGr86ajH0BodPDNOMuVZi4E94XslkgXQQuI
 XpJMVNbXSOk_PyKDv6WZXx4NX4UGLLMfUUGHd6iJ1eah_H6AYeh6.jkAvoqaq3rtZVjG041IkUXC
 z7xO3GYhLyb0JEOilxXzRPt0qSH_GtyDef7yJ8LZ529Y7RYMRc5OedS6iqWJteK.1llXr0SMYIfZ
 b3LNt6lH_qjQXTvIXRraniDu89eEUgVinNrsrosWS4CFTV.kCLTvq8ZnpAVtvcvjy.JUG_KPHPay
 FfyEMG4CFP1scuepvJ.49MN1NLIbMVLqe9QWzINEs3UIrWKamrPQZyg5KYNbq_2PH.2S8Ku6IkQQ
 32Go5JUuKW49lZyQ8Adu1ADNtSXhMn.rD4hUwdw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 22:47:33 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-dzsj8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eb3127e9b751f002517d9d917e974eed;
          Fri, 29 Apr 2022 22:47: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Rock64 eMMC not working
From: Mark Millard 
In-Reply-To: <20220429213048.GL88842@funkthat.com>
Date: Fri, 29 Apr 2022 15:47:27 -0700
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F74264A-4EF9-48BD-8114-BF9A01AD5C1A@yahoo.com>
References: <20220407040810.GD88842@funkthat.com>
 <20220429213048.GL88842@funkthat.com>
To: John-Mark Gurney 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KqngV5hXVz3sb2
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KKoKHLTE;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.55 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.95)[0.949];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 23013
Lines: 589

On 2022-Apr-29, at 14:30, John-Mark Gurney  wrote:

> John-Mark Gurney wrote this message on Wed, Apr 06, 2022 at 21:08 =
-0700:
>=20
> Bump?
>=20
> Is no one working on/maintaining the Rock64 port?
>=20
> Right now looking at getting the OTG port working on it, but it looks
> like the dwcotg driver is completely broken in that it can't read data
> accurately from the USB bus.
>=20
>> I am trying to get the latest FreeBSD -current snapshot to boot/run =
off
>> a Pine64 eMMC module on the Rock64, but I'm seeing an issue w/ =
mounting
>> root:
>>=20
>> FreeBSD 14.0-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 =
UTC 2022
>> [...]
>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>> mmcsd0: Error indicated: 4 Failed
>>=20
>> I got similar messages when 13.1-RC1:
>>=20
>> mmcsd0: 16GB  =
at mmc0 150.0MHz/8bit/1016-block
>> mmcsd0boot0: 4MB partition 1 at mmcsd0
>> mmcsd0boot1: 4MB partition 2 at mmcsd0
>> mmcsd0rpmb: 4MB partition 3 at mmcsd0
>> [...]
>> GEOM: mmcsd0: the secondary GPT header is not in the last LBA.
>> mmcsd0: Error indicated: 4 Failed
>> rockchip_dwmmc1: Failed to update clk
>>=20
>>=20
>> Are there any known issues w/ this?  A different image to try?
>>=20
>> Also, in trying to debug this issue, I tried to boot from a microSD
>> card with the eMMC module installed by shorting the jumper, but when =
I did,
>> I got:
>> mmcsd0: 32GB  at mmc0 =
50.0MHz/4bit/1016-block
>> mmcsd1: Error reading EXT_CSD Failed
>> device_attach: mmcsd1 attach returned 6
>> Kernel page fault with the following non-sleepable locks held:
>> exclusive sleep mutex rockchip_dwmmc1 (dwmmc) r =3D 0 =
(0xffffa000008d2128) locked @ /usr/src/sys/dev/mmc/host/dwmmc.c:386
>> stack backtrace:
>> #0 0xffff0000004e5390 at witness_debugger+0x5c
>> #1 0xffff0000004e6564 at witness_warn+0x3e8
>> #2 0xffff00000078962c at data_abort+0xa0
>> #3 0xffff000000767810 at handle_el1h_sync+0x10
>>  x0:             8088
>>  x1: ffff00008e18b000 (ucom_cons_softc + 8ce4ca40)
>>  x2:               40
>>  x3:              182
>>  x4:                0
>>  x5: ffff00008e1767a0 (ucom_cons_softc + 8ce381e0)
>>  x6:                0
>>  x7:                0
>>  x8:                4
>>  x9: ffff000000b55910 (memmap_bus + 0)
>> x10:                3
>> x11:            10000
>> x12:                1
>> x13:             2af8
>> x14:               88
>> x15:             2af8
>> x16:               88
>> x17:                0
>> x18: ffff00008e176850 (ucom_cons_softc + 8ce38290)
>> x19: ffffa000008d2140
>> x20: ffffa000008d2000
>> x21:             8088
>> x22:                0
>> x23:         80000003
>> x24: ffffa000008c9580
>> x25: ffffa00000bb9100
>> x26: ffff000000b9ea98 (Giant + 18)
>> x27: ffff0000008df336 (digits + ea96)
>> x28: ffffa00000bb9110
>> x29: ffff00008e176850 (ucom_cons_softc + 8ce38290)
>>  sp: ffff00008e176850
>>  lr: ffff0000007b0298 (dwmmc_intr + 50)
>> elr: ffff0000007b02c4 (dwmmc_intr + 7c)
>> spsr:               45
>> far:               20
>> esr:         96000044
>> panic: data abort in critical section or under mutex
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> vpanic() at vpanic+0x174
>> panic() at panic+0x44
>> data_abort() at data_abort+0x2dc
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0x96000044
>> dwmmc_intr() at dwmmc_intr+0x7c
>> ithread_loop() at ithread_loop+0x2a0
>> fork_exit() at fork_exit+0x74
>> fork_trampoline() at fork_trampoline+0x14
>> KDB: enter: panic
>>=20
>>=20
>> Complete boot message:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> U-Boot TPL 2021.07 (Mar 31 2022 - 05:26:18)
>> LPDDR3, 800MHz
>> BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 =
Size=3D2048MB
>> Trying to boot from BOOTROM
>> Returning to boot ROM...
>>=20
>> U-Boot SPL 2021.07 (Mar 31 2022 - 05:26:18 +0000)
>> Trying to boot from MMC1
>> Card did not respond to voltage select! : -110
>> spl: mmc init failed with error: -95
>> Trying to boot from MMC2
>> NOTICE:  BL31: v2.5(release):
>> NOTICE:  BL31: Built : 05:24:37, Mar 31 2022
>> NOTICE:  BL31:Rockchip release version: v1.2
>>=20
>>=20
>> U-Boot 2021.07 (Mar 31 2022 - 05:28:19 +0000)
>>=20
>> Model: Pine64 Rock64
>> DRAM:  2 GiB
>> PMIC:  RK8050 (on=3D0x40, off=3D0x00)
>> MMC:   mmc@ff500000: 1, mmc@ff520000: 0
>> Loading Environment from MMC... Card did not respond to voltage =
select! : -110
>> *** Warning - No block device, using default environment
>>=20
>> In:    serial@ff130000
>> Out:   serial@ff130000
>> Err:   serial@ff130000
>> Model: Pine64 Rock64
>> Net:   eth0: ethernet@ff540000
>> Hit any key to stop autoboot:  0=20
>> switch to partitions #0, OK
>> mmc0(part 0) is current device
>> Scanning mmc 0:1...
>> 50618 bytes read in 7 ms (6.9 MiB/s)
>> Card did not respond to voltage select! : -110
>> Scanning disk mmc@ff500000.blk...
>> Disk mmc@ff500000.blk not ready
>> Scanning disk mmc@ff520000.blk...
>> ** Unrecognized filesystem type **
>> ** Unrecognized filesystem type **
>> ** Unrecognized filesystem type **
>> Found 5 disks
>> ** Unable to read file ubootefi.var **
>> Failed to load EFI variables
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>> Found EFI removable media binary efi/boot/bootaa64.efi
>> 1263868 bytes read in 33 ms (36.5 MiB/s)
>> Booting /efi\boot\bootaa64.efi
>>=20
>>=20
>> Consoles: EFI console =20
>>    Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk0p1:
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Thu Mar 31 08:48:02 UTC 2022 root@releng1.nyi.freebsd.org)
>>=20
>>   Command line arguments: loader.efi
>>   Image base: 0x7cdde000
>>   EFI version: 2.80
>>   EFI Firmware: Das U-Boot (rev 8225.1792)
>>   Console: efi (0x1000)
>>   Load Path: /efi\boot\bootaa64.efi
>>   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,6440=
0726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
>> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(1,GPT,6440=
0726-b60c-11ec-a26d-85c343ffa803,0x8000,0x19000)
>> Setting currdev to disk0p1:
>> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/eMMC(0)/eMMC(1)/HD(2,GPT,6440=
0726-b60c-11ec-a26d-85c343ffa803,0x21000,0x1cc6fd8)
>> Setting currdev to disk0p2:
>> /
>>=20
>>=20
>> Loading /boot/defaults/loader.conf
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> /
>>=20
>> Loading kernel...
>> /boot/kernel/kernel text=3D0x2a8 text=3D0x84f4a0 text=3D0x249adc =
data=3D0x1b9aa8 data=3D0x0+0x40d000 0x8+0x133de8+0x8+0x15b370\
>> Loading configured modules...
>> /boot/entropy size=3D0x1000
>> /boot/kernel/umodem.ko text=3D0x2100 text=3D0x13a0 data=3D0x6d8+0x10 =
0x8+0xf18+0x8+0xb5c
>> loading required module 'ucom'
>> /boot/kernel/ucom.ko text=3D0x2590 text=3D0x2f00 data=3D0x8e0+0x858 =
0x8+0x1290+0x8+0xbd5
>> /etc/hostid size=3D0x25
>>=20
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]...              =20
>> Using DTB provided by EFI at 0x80f0000.
>> EFI framebuffer information:
>> addr, size     0x0, 0x0
>> dimensions     0 x 0
>> stride         0
>> masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
>> ---<>---
>> GDB: debug ports: uart
>> GDB: current port: uart
>> KDB: debugger backends: ddb gdb
>> KDB: current backend: ddb
>> Copyright (c) 1992-2022 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-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 09:26:31 =
UTC 2022
>>    =
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64
>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git =
llvmorg-13.0.0-0-gd7b669b3a303)
>> WARNING: WITNESS option enabled, expect reduced performance.
>> VT: init without driver.
>> module firmware already present!
>> real memory  =3D 2145136640 (2045 MB)
>> avail memory =3D 2065342464 (1969 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
>> MAP 7cf1b000 mode 2 pages 1
>> MAP 7cf1f000 mode 2 pages 3
>> MAP 7cf23000 mode 2 pages 4
>> MAP 7ff40000 mode 2 pages 16
>> kbd0 at kbdmux0
>> ofwbus0: 
>> clk_fixed0:  on ofwbus0
>> rk_grf0:  mem 0xff100000-0xff100fff =
on ofwbus0
>> rk3328_cru0:  mem =
0xff440000-0xff440fff on ofwbus0
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> Cannot set frequency for clk: aclk_bus_pre_c, error: 34
>> rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> Cannot set frequency for clk: aclk_peri_pre, error: 34
>> rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
>> Cannot get frequency for clk: hdmi_phy, error: 9
>> clk_fixed1:  on ofwbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> regfix2:  on ofwbus0
>> regfix3:  on ofwbus0
>> simple_mfd0:  mem =
0xff450000-0xff45ffff on ofwbus0
>> psci0:  on ofwbus0
>> gic0:  mem =
0xff811000-0xff811fff,0xff812000-0xff813fff,0xff814000-0xff815fff,0xff8160=
00-0xff817fff irq 52 on ofwbus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 160
>> rk_pinctrl0:  on ofwbus0
>> gpio0:  mem 0xff210000-0xff2100ff irq =
53 on rk_pinctrl0
>> gpiobus0:  on gpio0
>> gpio1:  mem 0xff220000-0xff2200ff irq =
54 on rk_pinctrl0
>> gpiobus1:  on gpio1
>> gpio2:  mem 0xff230000-0xff2300ff irq =
55 on rk_pinctrl0
>> gpiobus2:  on gpio2
>> gpio3:  mem 0xff240000-0xff2400ff irq =
56 on rk_pinctrl0
>> gpiobus3:  on gpio3
>> rk_i2c0:  mem 0xff160000-0xff160fff irq 16 on ofwbus0
>> iicbus0:  on rk_i2c0
>> rk805_pmu0:  at addr 0x30 irq 57 on iicbus0
>> generic_timer0:  irq 4,5,6,7 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality =
1000
>> rk_tsadc0:  mem 0xff250000-0xff2500ff =
irq 24 on ofwbus0
>> cpulist0:  on ofwbus0
>> cpu0:  on cpulist0
>> cpufreq_dt0:  on cpu0
>> cpufreq_dt0: Found cpu-supply
>> cpu1:  on cpulist0
>> cpufreq_dt1:  on cpu1
>> cpufreq_dt1: Found cpu-supply
>> cpu2:  on cpulist0
>> cpufreq_dt2:  on cpu2
>> cpufreq_dt2: Found cpu-supply
>> cpu3:  on cpulist0
>> cpufreq_dt3:  on cpu3
>> cpufreq_dt3: Found cpu-supply
>> pcm0:  on ofwbus0
>> pmu0:  irq 0,1,2,3 on ofwbus0
>> pcm1:  on ofwbus0
>> i2s0:  mem 0xff000000-0xff000fff irq 8 on ofwbus0
>> Cannot set frequency for clk: xin12m, error: 34
>> Cannot set frequency for clk: xin12m, error: 34
>> i2s1:  mem 0xff010000-0xff010fff irq 9 on ofwbus0
>> Cannot set frequency for clk: clkin_i2s1, error: 34
>> Cannot set frequency for clk: xin12m, error: 34
>> uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on =
ofwbus0
>> uart0: console (1500000,n,8,1)
>> iic0:  on iicbus0
>> spi0:  mem 0xff190000-0xff190fff irq 19 on ofwbus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> rockchip_dwmmc0:  mem 0xff500000-0xff503fff irq 43 on ofwbus0
>> rockchip_dwmmc0: Hardware version ID is 270a
>> rockchip_dwmmc1:  mem 0xff520000-0xff523fff irq 45 on ofwbus0
>> rockchip_dwmmc1: Hardware version ID is 270a
>> mmc0:  on rockchip_dwmmc1
>> dwc0:  mem =
0xff540000-0xff54ffff irq 46 on ofwbus0
>> miibus0:  on dwc0
>> rgephy0:  PHY 0 on =
miibus0
>> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
>> rgephy1:  PHY 1 on =
miibus0
>> rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
>> dwc0: Ethernet address: xxx
>> dwcotg0:  mem =
0xff580000-0xff5bffff irq 48 on ofwbus0
>> usbus1 on dwcotg0
>> ehci0:  mem 0xff5c0000-0xff5cffff irq 49 on =
ofwbus0
>> usbus2: EHCI version 1.0
>> usbus2 on ehci0
>> ohci0:  mem 0xff5d0000-0xff5dffff irq 50 on =
ofwbus0
>> usbus3 on ohci0
>> gpioc0:  on gpio0
>> gpioc1:  on gpio1
>> gpioc2:  on gpio2
>> gpioc3:  on gpio3
>> gpioled0:  on ofwbus0
>> gpioled0:  failed to map pin
>> gpioled0:  failed to map pin
>> pcm2:  on ofwbus0
>> armv8crypto0: 
>> Timecounters tick every 1.000 msec
>> usbus1: 480Mbps High Speed USB v2.0
>> usbus2: 480Mbps High Speed USB v2.0
>> usbus3: 12Mbps Full Speed USB v1.0
>> rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s
>> pcm0: no driver attached to codec node
>> pcm1: no driver attached to codec node
>> ugen2.1:  at usbus2
>> uhub0 on usbus2
>> uhub0:  on =
usbus2
>> ugen1.1:  at usbus1
>> uhub1 on usbus1
>> uhub1:  on =
usbus1
>> ugen3.1:  at usbus3
>> uhub2 on usbus3
>> uhub2:  on =
usbus3
>> mmcsd0: 16GB  at =
mmc0 150.0MHz/8bit/1016-block
>> mmcsd0boot0: 4MB partition 1 at mmcsd0
>> mmcsd0boot1: 4MB partition 2 at mmcsd0
>> mmcsd0rpmb: 4MB partition 3 at mmcsd0
>> pcm2: no driver attached to cpu node
>> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>>                   Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
>> Instruction Set Attributes 0 =3D 
>> Instruction Set Attributes 1 =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
>> WARNING: WITNESS option enabled, expect reduced performance.
>> Unresolved linked clock found: hdmi_phy
>> Unresolved linked clock found: usb480m_phy
>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>> mmcsd0: Error indicated: 4 Failed
>> uhub2: 1 port with 1 removable, self powered
>> uhub1: 1 port with 1 removable, self powered
>> uhub0: 1 port with 1 removable, self powered

I'm in the middle of updating systems and the Rock64 is
still back at:

# uname -apKU
FreeBSD Rock64_RPi_4 14.0-CURRENT FreeBSD 14.0-CURRENT #28 =
main-n252475-e76c0108990b-dirty: Sat Jan 15 23:39:27 PST 2022     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53  arm64 aarch64 1400047 1400047

I normally only use the e.MMC during booting. The miscrsd card
slot is left empty but I used it to manipulate microsd card
content sometimes. The root file system is on a USB3 NVMe SSD.

# gpart show -p
=3D>       63  244277185    mmcsd0  MBR  (116G)
         63      32705            - free -  (16M)
      32768     102312  mmcsd0s1  fat32lba  [active]  (50M)
     135080      28760            - free -  (14M)
     163840  241172480  mmcsd0s2  freebsd  (115G)
  241336320    2940928            - free -  (1.4G)

=3D>        0  241172480   mmcsd0s2  BSD  (115G)
          0  230686720  mmcsd0s2a  freebsd-ufs  (110G)
  230686720   10485760             - free -  (5.0G)

=3D>        40  1953525088    da0  GPT  (932G)
          40      532480  da0p1  efi  (260M)
      532520        2008         - free -  (1.0M)
      534528     7340032  da0p2  freebsd-swap  (3.5G)
     7874560     1048576         - free -  (512M)
     8923136    23068672  da0p3  freebsd-swap  (11G)
    31991808     2097152         - free -  (1.0G)
    34088960    33554432  da0p4  freebsd-swap  (16G)
    67643392  1740636160  da0p5  freebsd-ufs  (830G)
  1808279552     4194304  da0p6  freebsd-swap  (2.0G)
  1812473856   141051272         - free -  (67G)

I can mount mmcsd0s1 (msdosfs) and/or mmcsd0s2a (UFS)
and do I/O to them. (It is how I update the content.)

mmcsd0s2a has the copy of the FreeBSD kernel used to
boot. This is because the FreeBSD kernel is the first
stage to be able to deal with the USB3 port as far as
I know. The e.MMC also is where the Rock64 gets U-Boot
from and U-Boot gets the EFI from.

# mount -onoatime -tmsdosfs /dev/mmcsd0s1 /media
# ls -Tld /media/*
drwxr-xr-x  1 root  wheel  4096 Apr 13 07:24:32 2021 /media/EFI
drwxr-xr-x  1 root  wheel  4096 Apr 13 08:15:48 2021 /media/dtb
# ls -Tld /media/*/*/*
-r-xr-xr-x  1 root  wheel  1243772 Jan 28 12:33:00 2022 =
/media/EFI/BOOT/bootaa64.efi
-r-xr-xr-x  1 root  wheel    50618 Jan 28 12:32:28 2022 =
/media/dtb/rockchip/rk3328-rock64.dtb

As for the ufs content (boot not expanded):

# mount -onoatime /dev/mmcsd0s2a /mnt
# ls -Tld /mnt/* /mnt/etc/*
-r--r--r--   1 root  wheel   6170 Feb  1 04:48:34 2020 /mnt/COPYRIGHT
drwxr-xr-x  23 root  wheel   1536 Jan 28 15:26:41 2022 /mnt/boot
drwxr-xr-x   2 root  wheel    512 Apr 26 14:39:22 2020 /mnt/etc
-rw-r--r--   1 root  wheel     37 Dec 31 16:00:18 2009 /mnt/etc/hostid
drwx------   2 root  wheel  33280 Nov 27 09:46:08 2019 /mnt/lost+found

I've been experimenting with building and using
U-Boot 2022.04 (not just on the Rock64) and that
is what is currently in place, despite the FreeBSD
vintage:

U-Boot TPL 2022.04 (Apr 23 2022 - 03:14:35)
LPDDR3, 800MHz
BW=3D32 Col=3D11 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 =
Size=3D4096MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2022.04 (Apr 23 2022 - 03:14:35 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
Trying to boot from MMC2
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 05:34:22, Dec  8 2021
NOTICE:  BL31:Rockchip release version: v1.2


U-Boot 2022.04 (Apr 23 2022 - 03:15:10 +0000)

Model: Pine64 Rock64
DRAM:  4 GiB
PMIC:  RK8050 (on=3D0x40, off=3D0x00)
Core:  219 devices, 21 uclasses, devicetree: separate
MMC:   mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... Card did not respond to voltage select! =
: -110
*** Warning - No block device, using default environment

In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  2 =08=08=08 1 =08=08=08 0=20
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
50618 bytes read in 5 ms (9.7 MiB/s)
. . . Card did not respond to voltage select! : -110
Scanning disk mmc@ff500000.blk...
Disk mmc@ff500000.blk not ready
Scanning disk mmc@ff520000.blk...
Found 3 disks
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
1243772 bytes read in 33 ms (35.9 MiB/s)
Booting /efi\boot\bootaa64.efi
. . .

I may discover that something breaks once I update
FreeBSD, but the current status of my context seems
to be working fine for the e.MMC .

I've no clue about the OTG port status. I've never
tied to use it.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 30 02:12:07 2022
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 A4D8919961B0;
	Sat, 30 Apr 2022 02:12:16 +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 4KqtCg2fd4z3CnF;
	Sat, 30 Apr 2022 02:12:15 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 23U2C7R6007680
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 29 Apr 2022 19:12:08 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 23U2C7Mi007679;
	Fri, 29 Apr 2022 19:12:07 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 29 Apr 2022 19:12:07 -0700
From: bob prohaska 
To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220430021207.GA7600@www.zefox.net>
References: <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
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: 4KqtCg2fd4z3CnF
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2004
Lines: 45

Since about December of 2021 I've been noticing problems with
wired network connectivity on a pair of raspberry pi 3 machines
using wired network connections. One runs stable-13.1, the other
runs -current, both are up to date as of a few days ago.

Essentially both machines fail to respond to inbound network
connections via ssh or ping after reboot. If I get on the 
serial console and start an outbound ping to anywhere, both
machines respond to incoming pings with about a 65% packet
loss. Ssh connections are answered with delays of zero to
perhaps thirty seconds. Once connected ssh is usable but
erratic, with dropped characters, multi-second delays and
disconnects after random intervals from minutes to hours.

There are five other Raspberry Pi's on the network. Three
Pi2's run 12.3-stable, one Pi2 runs -current and a Pi4 runs
-current. All have no problems pinging one another and out
of network, so there's nothing obviously wrong with the net.
The network is not routed, but rather a block of eight
addresses simply bridged from my ISP over DSL.

It's been found that an image of 13.1-RC4 behaves similarly
on one Pi3 when on the public network but exhibits more normal
ping response when moved to a 192.168.1.n private network. On
the face of it, this seems significant, but I can't guess how.

I recall a post on one of the mailing lists about a bug that
caused problems when packets arrived out-of-order via NAT, 
but I'm using direct same-network pings and pinging through 
NAT seems little-to-no worse.

I was hoping to upgrade my stable-12 machines to stable-13,
but seeing this behavior gives me pause. If anyone can 
suggest tests or experiments to figure out what's going on
I'd be most grateful. I'm no programmer but can follow 
simple instructions. If this sounds like a known bug(s)
links to bugzilla would be of much interest.

Many thanks for reading, and any ideas! If some essential
details have been omitted please indicate and I'll try to
supply them. 

bob prohaska
  


From nobody Sat Apr 30 02:41:57 2022
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 8A79E199C9F1
	for ; Sat, 30 Apr 2022 02:42:10 +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 4Kqtt90l9dz3GmJ
	for ; Sat, 30 Apr 2022 02:42:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651286522; bh=wC5uC4p7oMKsbW1wO5Sw4dfa3no9OdKm320PIlRtlOM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Qn+WPkdJNyFYYyjtpogUr1AiQN9WdArIWB+cDy+0Z22A1R6JygXI/wZsk/M9MFhQxB5S3+o5WQzlOF+1dfXEqeVOFJKR7Oesr4QMHteH7RHWfhjf99Js+w3lsKwX7PIkAZaB9vC5Bw619krFVrs7mk7s1riKYJlmeZSaQr14MXIDCiKpNX3U2iVD8DAMDbV0ztABfvxzrzSMlTNX9CL4GUVndeuO4/DSfTem9+Nct7W5J4NDsFRHw6QMA8tyeHeuCps/xj4T0SpRu92s8yycb/NuOMutTswVZkPzRVaC3vo69zCycs8m3Qlpr49M6Tl8el4uhsNI2XYwi3xDjl29Bw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651286522; bh=wPi966Y2bwkCEqUBW+vOnFk/lA8Heu7SNWgKSCSuULn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Dvqi79DRlX/ewEi8Xi5e5hk25HDjG9MjdZeU9nJDBNcw42/zGB4XfOzynjnAwj5Prne7xyNl83J43p2gF0vPvSymdsd6A47CNYe8jKHu3QlabZ+SclmeUPSwQaPJJPDOJh1k+TUo95d4kpv2FfoGbvAxNotBBViK9dx148gfu1bw3h7CEEoD9+t6KIugKhWKChShbig0XClQULHsWfwjns6LF6i9FIO+uz4MZuA5z6zihRTbonFwiv+3F+qaX2hzHWfic2+MLZ7tvDyOFne0G3JvOzJTJ1ZIyvf3JsKbyZBUBgbNEiqLCNRT0mqH/atZfGaMO0qyTMt/m0MT7H99WA==
X-YMail-OSG: bwdd2J0VM1k_kPH34th7HX_hgBZAO3wfAKPxzUelSr45ugK.xez19LB4CKxZAcz
 qsH3jgS6SbaK2h.Sp6AYJhGosAUY2ZSwrZFAl0he4h5NJ1mrG2CKRBhbckkP3LnHal4q5gBpRpqV
 8TMK1WKNkuTuyfuGUqUfvt1tRkv.3q4MlB7aknVd6H.htHsknZXa6ULU_vWyziVIR9oK9Eqg7qFi
 htMQARKOUp7uJ82vbje5P5B.KBxpI6o_B.ObfEeqY1uPiMR0jNtNHUvHb1B4hvu5nM.AC29xe9GQ
 SIGVlXiN3dVJYtdbbNDSg2hJJFINyLeejG71a2dZz4erVKG0ufMJZh06Oc5ntlfjrMe3.KBwxxhz
 jWbQ3RSXFw8RR6i3gM3eya16Nqh.fJPCJx6ZBsnl52djb0I9hbQp_b9nERoS8h5NojmnXt17wAJy
 ga.2A4ZMIPIOOO8D5uB5vno2AM7CAN5faLhU2Q37lmfDBtHbZNVTN14pSTybLiCqAALIBQLXJnDR
 DquM5kZjFYsAOA.mfAK4upe2c4Uv..Q1NkvZtF2m20cbSM4iYBGfVLkcLm1zSGDFvCtdheuulYCy
 5.kxcOUROBeX7Gm8ITzt2UejFHpfS8pqx0kO2LQ.BLiiBa201POveUW3ssQ9DPjAFstBA0RIRz3x
 p6DmVkKXyQLPZGsl1DsTYfYZcjC0LcNfI4HRLcutMcEeeHTFb735jNNq2DhNGpElCBkj1xE2Q5BL
 A3oKRh0SnSUghW2UWHXKVNF0yVte5ZDA9CGa2lKpLXT5GZL_KURVhpVSGWAvrlFxCCQxN8BAuiDo
 qRmx1Rp2YZtU3Pz7_6.T9GVdCEd0gPdAiFp3rKG0v7KJq9kOInnGzhsPc0ej3iugTLhWcxmiFcUK
 owdUbx5zOoQgPbe1eZ6bFgGfsu_B6OrBM.g5rglWOsA0gFj5.gLfXFo4IK1q4OUuygzMCrX0nJOZ
 2uvl2AiZS4e4FiDnyMjGEFioBtnrNO1O1f_tKnOBZlB6ggVXwo2yJwbcQaNI7nMMAUuzZaDla_Sl
 xioqnKtner2_sM7cytq_AgDHtFuiOv8oN69yXoUsEPwdKMG0r.ged8sWEDUUrWRoeJ9chsg_LdN.
 16rrm4eIFeQECtu.YUgInXm6D8whLvVsv0W6nfJwnUBcSIOCCP8rVohW0bDqNDLo96EY39MMNJYv
 qyv0EWzcwjEThhpfZuuwVXSzcGAwa.Gie6D4_LlVMfanqKNK8LCyWmJnndc7fNvsljeE2Wef4NuT
 mTHdk2UUJpFdw3IMWWoYDWI1xX2IEKF6.7tkA.GezRVuXqseyS0.akIDekDyny3n7cv8cPDpzDQL
 cTUnHBQiDrmREDwVoHafTEx6Gmi0UeHEo4Bjrmv7oruQV31WI9Buu9pyPZXwSeY7d_z0Pck2FyBp
 9X1.2Hs.x7p2cKAJtq1eRoR4_.acZwPWln7MWiEbb65QCNMXW55ZV_6jJxcGC_SfuZ1FotI8SKzI
 UA3I.9xjjhFTl2u7xDeFHzasa8JjXHt5wJjTyJMtYrwgknLNrd9A_vTHfXQQAJ8RMj66zh_QHSeW
 SCwcY4HM9mH5P9Qzt9n0HaVv28xg3IQxG7TOAgbKyMNGT27Tfzdwd.hyLTmAq44fdoFQiP.roewe
 jSmGk693HPtBzNHiwRfRGGR65KBDjbkj48OhJF2_Wts4m15p2YLVrlyB16wYBwO9LIbnrncnym0e
 x0AQLFejoOLwenHObHcgpU.2TEDMjs4Gf97NgkhALZ1QEvmi9u1lXQdiivdv4QQBBGT_UVBNMojm
 ud5QJd6FC85aIcDZTUdClvta79FjUdLOwSS_conRUcJ.8pPbLa6PwfI1l1XQviDKytbf5vSopfYD
 kgyDqqOlRgxvangxFpo3hsco9.UZkdyXzm5Khnlbgowi0tI3KtyUVjPSpKlhWhqv4ZQNx_Y15JyD
 gAEjysVYpMrul2GfDmIGqk3dTnbrOffk.Utmr9673h8FIay7bhSAfvOIAzQDvqGMyaiLzMNy6mrt
 WCicXhO1fTkD4LYQk6E7sSxXknG8Nj2tlnYOM2v3KWJgt1Ch0IQts97jciJtLibwGbO7NnDE515Q
 ujD7Qubrr60FmqPLckz4nQ1ZArQ1ZO6KYdcVWRQMhccbUgnbC1zYzmwDyQNvO5320P66hnMX9oVY
 M9IQq8BZ6v.Twjgc8KJ7TE9KGWMPQC.nuM8JMA4tzv2O0Ln0rilplNsTqkhUATTCJ_MnsJkBRzTn
 3mtyw_7377GbGk48ctnDCO4p5Bjl92U7xq.VfiJmpP5mqf48fdR3Ko4PVIF0MgG5u0GX3.YohDaH
 .3bjj72ktdN6IA9E10A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Apr 2022 02:42:02 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-h6f5j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2a9f933fef0efef9feee2270fa0231f1;
          Sat, 30 Apr 2022 02:41:58 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Rock64 eMMC not working
From: Mark Millard 
In-Reply-To: <8F74264A-4EF9-48BD-8114-BF9A01AD5C1A@yahoo.com>
Date: Fri, 29 Apr 2022 19:41:57 -0700
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E0C3714-2DF8-44BD-A464-202D5588A46A@yahoo.com>
References: <20220407040810.GD88842@funkthat.com>
 <20220429213048.GL88842@funkthat.com>
 <8F74264A-4EF9-48BD-8114-BF9A01AD5C1A@yahoo.com>
To: John-Mark Gurney 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kqtt90l9dz3GmJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Qn+WPkdJ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.20 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.70)[-0.698];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6914
Lines: 195

On 2022-Apr-29, at 15:47, Mark Millard  wrote:

> On 2022-Apr-29, at 14:30, John-Mark Gurney  wrote:
>=20
>> John-Mark Gurney wrote this message on Wed, Apr 06, 2022 at 21:08 =
-0700:
>>=20
>> Bump?
>>=20
>> Is no one working on/maintaining the Rock64 port?
>>=20
>> Right now looking at getting the OTG port working on it, but it looks
>> like the dwcotg driver is completely broken in that it can't read =
data
>> accurately from the USB bus.
>>=20
>>> I am trying to get the latest FreeBSD -current snapshot to boot/run =
off
>>> a Pine64 eMMC module on the Rock64, but I'm seeing an issue w/ =
mounting
>>> root:
>>>=20
>>> FreeBSD 14.0-CURRENT #0 main-n254105-d53927b0bae: Thu Mar 31 =
09:26:31 UTC 2022
>>> [...]
>>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>>> mmcsd0: Error indicated: 4 Failed
>>>=20
>>> I got similar messages when 13.1-RC1:
>>>=20
>>> mmcsd0: 16GB  at mmc0 150.0MHz/8bit/1016-block
>>> mmcsd0boot0: 4MB partition 1 at mmcsd0
>>> mmcsd0boot1: 4MB partition 2 at mmcsd0
>>> mmcsd0rpmb: 4MB partition 3 at mmcsd0
>>> [...]
>>> GEOM: mmcsd0: the secondary GPT header is not in the last LBA.
>>> mmcsd0: Error indicated: 4 Failed
>>> rockchip_dwmmc1: Failed to update clk
>>>=20
>>>=20
>>> Are there any known issues w/ this?  A different image to try?
>>>=20
>>> . . .
>=20
> I'm in the middle of updating systems and the Rock64 is
> still back at:
>=20
> # uname -apKU
> FreeBSD Rock64_RPi_4 14.0-CURRENT FreeBSD 14.0-CURRENT #28 =
main-n252475-e76c0108990b-dirty: Sat Jan 15 23:39:27 PST 2022     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53  arm64 aarch64 1400047 1400047
>=20
> I normally only use the e.MMC during booting. The miscrsd card
> slot is left empty but I used it to manipulate microsd card
> content sometimes. The root file system is on a USB3 NVMe SSD.
>=20
> # gpart show -p
> =3D>       63  244277185    mmcsd0  MBR  (116G)
>         63      32705            - free -  (16M)
>      32768     102312  mmcsd0s1  fat32lba  [active]  (50M)
>     135080      28760            - free -  (14M)
>     163840  241172480  mmcsd0s2  freebsd  (115G)
>  241336320    2940928            - free -  (1.4G)
>=20
> =3D>        0  241172480   mmcsd0s2  BSD  (115G)
>          0  230686720  mmcsd0s2a  freebsd-ufs  (110G)
>  230686720   10485760             - free -  (5.0G)
>=20
> =3D>        40  1953525088    da0  GPT  (932G)
>          40      532480  da0p1  efi  (260M)
>      532520        2008         - free -  (1.0M)
>      534528     7340032  da0p2  freebsd-swap  (3.5G)
>     7874560     1048576         - free -  (512M)
>     8923136    23068672  da0p3  freebsd-swap  (11G)
>    31991808     2097152         - free -  (1.0G)
>    34088960    33554432  da0p4  freebsd-swap  (16G)
>    67643392  1740636160  da0p5  freebsd-ufs  (830G)
>  1808279552     4194304  da0p6  freebsd-swap  (2.0G)
>  1812473856   141051272         - free -  (67G)
>=20
> I can mount mmcsd0s1 (msdosfs) and/or mmcsd0s2a (UFS)
> and do I/O to them. (It is how I update the content.)
>=20
> mmcsd0s2a has the copy of the FreeBSD kernel used to
> boot. This is because the FreeBSD kernel is the first
> stage to be able to deal with the USB3 port as far as
> I know. The e.MMC also is where the Rock64 gets U-Boot
> from and U-Boot gets the EFI from.
>=20
> # mount -onoatime -tmsdosfs /dev/mmcsd0s1 /media
> # ls -Tld /media/*
> drwxr-xr-x  1 root  wheel  4096 Apr 13 07:24:32 2021 /media/EFI
> drwxr-xr-x  1 root  wheel  4096 Apr 13 08:15:48 2021 /media/dtb
> # ls -Tld /media/*/*/*
> -r-xr-xr-x  1 root  wheel  1243772 Jan 28 12:33:00 2022 =
/media/EFI/BOOT/bootaa64.efi
> -r-xr-xr-x  1 root  wheel    50618 Jan 28 12:32:28 2022 =
/media/dtb/rockchip/rk3328-rock64.dtb
>=20
> As for the ufs content (boot not expanded):
>=20
> # mount -onoatime /dev/mmcsd0s2a /mnt
> # ls -Tld /mnt/* /mnt/etc/*
> -r--r--r--   1 root  wheel   6170 Feb  1 04:48:34 2020 /mnt/COPYRIGHT
> drwxr-xr-x  23 root  wheel   1536 Jan 28 15:26:41 2022 /mnt/boot
> drwxr-xr-x   2 root  wheel    512 Apr 26 14:39:22 2020 /mnt/etc
> -rw-r--r--   1 root  wheel     37 Dec 31 16:00:18 2009 /mnt/etc/hostid
> drwx------   2 root  wheel  33280 Nov 27 09:46:08 2019 /mnt/lost+found
>=20
> I've been experimenting with building and using
> U-Boot 2022.04 (not just on the Rock64) and that
> is what is currently in place, despite the FreeBSD
> vintage:
>=20
> U-Boot TPL 2022.04 (Apr 23 2022 - 03:14:35)
> LPDDR3, 800MHz
> BW=3D32 Col=3D11 Bk=3D8 CS0 Row=3D15 CS1 Row=3D15 CS=3D2 Die BW=3D16 =
Size=3D4096MB
> Trying to boot from BOOTROM
> Returning to boot ROM...
>=20
> U-Boot SPL 2022.04 (Apr 23 2022 - 03:14:35 +0000)
> Trying to boot from MMC1
> Card did not respond to voltage select! : -110
> spl: mmc init failed with error: -95
> Trying to boot from MMC2
> NOTICE:  BL31: v2.5(release):
> NOTICE:  BL31: Built : 05:34:22, Dec  8 2021
> NOTICE:  BL31:Rockchip release version: v1.2
>=20
>=20
> U-Boot 2022.04 (Apr 23 2022 - 03:15:10 +0000)
>=20
> Model: Pine64 Rock64
> DRAM:  4 GiB
> PMIC:  RK8050 (on=3D0x40, off=3D0x00)
> Core:  219 devices, 21 uclasses, devicetree: separate
> MMC:   mmc@ff500000: 1, mmc@ff520000: 0
> Loading Environment from MMC... Card did not respond to voltage =
select! : -110
> *** Warning - No block device, using default environment
>=20
> In:    serial@ff130000
> Out:   serial@ff130000
> Err:   serial@ff130000
> Model: Pine64 Rock64
> Net:   eth0: ethernet@ff540000
> Hit any key to stop autoboot:  2 =08=08=08 1 =08=08=08 0=20
> Card did not respond to voltage select! : -110
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:1...
> 50618 bytes read in 5 ms (9.7 MiB/s)
> . . . Card did not respond to voltage select! : -110
> Scanning disk mmc@ff500000.blk...
> Disk mmc@ff500000.blk not ready
> Scanning disk mmc@ff520000.blk...
> Found 3 disks
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> 1243772 bytes read in 33 ms (35.9 MiB/s)
> Booting /efi\boot\bootaa64.efi
> . . .
>=20
> I may discover that something breaks once I update
> FreeBSD, but the current status of my context seems
> to be working fine for the e.MMC .
>=20
> I've no clue about the OTG port status. I've never
> tied to use it.
>=20

I've got the Rock64 updated to:
(line split for better readability)

# uname -apKU
FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #32
main-n255108-9fb40baf6043-dirty: Thu Apr 28 22:57:05 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53
arm64 aarch64 1400057 1400057

It still works the same as reported earlier. No
evidence of e.MMC related problems.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 30 03:14:27 2022
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 C2D651AAAD8D
	for ; Sat, 30 Apr 2022 03:14:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4Kqvbl1J8pz3KrZ
	for ; Sat, 30 Apr 2022 03:14:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651288475; bh=MPNUUt1KlzmbX1IPEYD53Oab09AZk1/H4AhOZICP4bg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JeUZ2U7qbK6Ab1YcuDEwfWzNxwnrRdPsfHO0j4XtrZ/yxG+JDAkHt3wJKgk4FfyqGeYkoxmXoLfBUeXraQkl+Iw8lF7HL5yJSJjff9jq28nFZFY5cXZPeA0a/+7Z1FDWuhJcNXGu9kvrfzIoSfsVYdtC0tT4AVYqoQJcFnYM2RanEYIEek1lzzVnEuwaTJON7MVQXbnmo/MizuavVLC8fc9dAZd8ZvDwkgNwdCXAM8fK50LFerqzyPR/c8Ga1seX14YYQAcL0DzQbsz7lZicaUB/139u9rQtadaz+Pw49IwFy8fY2dKutiMwMFkXALxu9YGeVSananbmbNW1sf462w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651288475; bh=3c+ymDl8kxp8j/2oX6lO3c0cTqPBvA6E90QK6iZearn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gzt2JT/MzK+H103M6t5zw2hDobIGjHieP2mW01GUCBynglqt+s99vONaMjXIOsKsNFzT5u/CFO3VophgfH/XkxM4w5b1ndhnGYpDlXgcwW5YHeNwpafrltkbUgTCtWvUoD6MGXYBJU4hdQeWXDw49vT0Bz+8hMNQR9KdJxpYLPF4tqMM7GBY1pUKEA1d9RAu3tOr259RDOwN9adBiDB7DkHF3H8dDn1K9xDC/74vyRYpPcPj8hZRa3pQa/MR1aDEL87FI40uxbOlh0w7AezCNux6hJZaZcoOi0Dk1pZRT1b6crZ2WoXy+YsGWpEPT5lSKhfJTGCXN2ysPqyopaI/8A==
X-YMail-OSG: V2AE1bwVM1m5Cp0g_gHzCMNa9hG0Lo_oXctfj_UgoqpNrMAeL0mIWY1XIMG1Le_
 pr4fbP2OwLg2qZs7qvf.FEc_mN0eAgJ0faveAGIBzVSg6kH1_zQEIOYIKmvCDqRTzgxvoQGEXVgu
 RecgvalhfG4dSplXhfmajTOUxxj095Ams3htU8MQP1v9cw.576V_83A4K_YkD3t8C7xoo12jAbpi
 YvJTMyhKX6DQGOCupLSYog88dPTqYgX2a2_CO4q8lerPDinpt9291tKkZfR3o3c9Eb_0lCX4Aimw
 qrsyKsp4TNDH.R0VLhW.vcAvsP.BZT3B8cfUngGLIibih6Wc9UuCuDEU.__4vXqpnIdztbd6Im87
 Gjw8jKIeoS43Pz6gKdvPuxX6YW_3AvAMTPc9UORh75JETCu3P3Kcqj9fSulcysUAVpH2wsH9pFYR
 PZS_6Kl0FTJelm7ESD9r8KOIl74VuJBAAlIWN5txSIP2JqSepIWgYd4RLza13w3GkfIJuuRIMgUO
 LywsTRY2IERhbgCq0MPCXPGajADWFhfJoQEEnUMWoOcclLUYB2.u_MkeA_PfHGnO7.w1UJ_yjFLv
 bKkDP0Wof9WTN8D6U1qV0RilBvX9sl1WAFcSq2AsGAlAzYLcvYk8RkrUwV66lUnEpzfcSnz.V5KX
 2xDPB1CCv0EPA0deAEgXFyPxYjLRtLCVSAE1xAAb4kO_e.jHTmJUdVP4Ha9RqvuPt7grLXEob5PR
 VHnIn86yx44CrFj3nJ6x5268ePlZJiTXXDNK01FoQ0BldOWiO4K1T6URrq.fNs10Ex_opWCfF5QO
 VoUDeIa.MXaIsursUyE_x4W7f_6jR.JysapnKS0BO385leuXFwovshgvsQkjuLqqaQ.R4ohBw.RG
 0cCaK8GQOCuRekLxCYIE3oUpPciEMvsUCHCeAH6I1fJCM_oWoNHQeRFcDlCxr0JvM0eZLRlOt1rR
 9EyMUI8YYzRVbHb9RxP2PRefmgkxO2ovICCmjctCHKdbaYPFsvgyY.aRYbRcIUIVRLIhD_VXyT1K
 Za4ToKKFIF16oRolvlF8afMc1O3_nSjrzkOxlfE.vA8E1A0qYyIokmiHnkvHmq6b6d02DlEZEuoL
 1gr2aML1W_slwWLdRFvqEEp39b2MSGfFswKRSnsiRygz0lDP9Mo7HbTJKA74IouKOU9eYmb4TbTK
 1aex.rHFkJ21L2QM7VT3qHt4HwVpkL5MhFaxiOir.CAfZDV5KNPoH1ZscvuuXWUySE7HCKEoK2JQ
 ISA6kheuGQcGd2IAwGgWE5oqz51AIkiDWJnXSqCDE1P3MeaCl0YredHuhddEwOPWCRnb4Um4cX9h
 b6oC7x3ZvUJgvyHFmPYe3kj32tVaRJLfZEakiD5xh17HFBBuneKcDcd_xInaPIxYuM4MoQUuEamI
 t7Oxg5YUY9FLjl1uuCHcvhIFRC5NYZGCEOymBugBBmrudU6mbiz_DIqgVGA_ZUSJIazu0DImRYWZ
 mDmGeMgEcWzVZQV_y1Fzvvf5jIb6Yt3ye_23EZUILf3dwDzFRxI4_LGbZWsr_vd9p2_VPSvIiQmV
 yPk7ZQqNhuOLHJD1GOZvdt2EYZpX2tSZInbFMrZFZMY0sAYsiLpZW6Psyl0LL.w8lkCPN.8vNaPt
 Como1DevrICDGI3SsmY3sIRehPPtZDNmpJZRfrzJdRl8_KViC1A8urKHhBA31DRUkRDaolfOEY5D
 WQInQ5UjUqtWs6kpurdlGgaWP0BIVDzdS6F2bfsoD3Jxk3wpjHWGs5.y4YjGRpyZppU2DlQeXDEO
 UomsNY05Ks7RnFopnuwqKpgNa_JtoncLpe6s5.rEuygKZ2lWi8Oau96_fd4CfnS47Z51DfzECCG0
 QyRhw090QiuwRmgv6trqYL6ns4Hpn4q6.PwaQ3AuC1P6cPzqdsjdtjexqBFUZI.SSZeTQjOogJDh
 WXXiumdvWAfhTstI_regZpg.iZ.lC_T3faUtmsVPz3_8oaQK_EkPoux.Sd0F_BWBOkthLCTBayAQ
 AKZJtOkwsgCrzLVFChI1mcpZCYxlI31ep6B.XRhEShYJlmMFu7B.A62.mw9ZrEp5lFx590z6X1h9
 Jb5FjzlE50Fu3jmzynafBqE7JPnF2svm4zCxY60SGwAJ7AEoO___jxqLdUUg0p6A9yVmeVLNwjWV
 2B5EactrgZtN6LKWCFf37g56Ja9K6U25Xq4Le1UroyOfhtX5dP6sfdmxo9.nuuBNZ5Z4DRGHOFNy
 uLXuXdxX9126dzbEOquURSl2tckBco_05uZZ3TdonrND.rkdBt63wxJQtLcsICJiQmLg6D1R5r3T
 HCsObUoWk6EDrwg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Apr 2022 03:14:35 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-vklcv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eec88b19e5de97c03cca1a71d62867c0;
          Sat, 30 Apr 2022 03:14:30 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <20220430021207.GA7600@www.zefox.net>
Date: Fri, 29 Apr 2022 20:14:27 -0700
Cc: freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8936EFD1-F1FD-48CF-9ED3-4D42595464DC@yahoo.com>
 <20220313193406.GA65568@www.zefox.net>
 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kqvbl1J8pz3KrZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JeUZ2U7q;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3166
Lines: 82

On 2022-Apr-29, at 19:12, bob prohaska  wrote:

> Since about December of 2021 I've been noticing problems with
> wired network connectivity on a pair of raspberry pi 3 machines
> using wired network connections. One runs stable-13.1, the other
> runs -current, both are up to date as of a few days ago.

Compared to your later notes about 192.168.1.n style use,
are any of the above that way? Or are the all well-analogous
to the "on the public network" context mentioned later?

> Essentially both machines fail to respond to inbound network
> connections via ssh or ping after reboot. If I get on the 
> serial console and start an outbound ping to anywhere, both
> machines respond to incoming pings with about a 65% packet
> loss. Ssh connections are answered with delays of zero to
> perhaps thirty seconds. Once connected ssh is usable but
> erratic, with dropped characters, multi-second delays and
> disconnects after random intervals from minutes to hours.
> 
> There are five other Raspberry Pi's on the network. Three
> Pi2's run 12.3-stable, one Pi2 runs -current

RPi2 v1.2's used as aarch64? (So similar to RPi3*'s.)
RPi2 v1.1's (armv7)?

Which type of RPi3* variant? B? B+? Revision?

> and a Pi4 runs
> -current. All have no problems pinging one another and out
> of network, so there's nothing obviously wrong with the net.
> The network is not routed, but rather a block of eight
> addresses simply bridged from my ISP over DSL.
> 
> It's been found that an image of 13.1-RC4 behaves similarly
> on one Pi3 when on the public network but exhibits more normal
> ping response when moved to a 192.168.1.n private network. On
> the face of it, this seems significant, but I can't guess how.

Did you try a RPi4B on the public network, booted using the
same 13.1-RC4 microsd card you used in the RPi3* testing?
(Modern aarch64 RPi* images should boot either type of
aarch64 RPI*.)

If yes, what was the behavior like? Did it behave like the
RPi3*?

If no, it should be a good test for how specific the problem
is to the RPi3* vs. RPi*'s more generally.

Testing a EtherNet dongle known to use a different driver
could also be a form of cross check, if you happen to have
such available.

> I recall a post on one of the mailing lists about a bug that
> caused problems when packets arrived out-of-order via NAT, 
> but I'm using direct same-network pings and pinging through 
> NAT seems little-to-no worse.
> 
> I was hoping to upgrade my stable-12 machines to stable-13,
> but seeing this behavior gives me pause. If anyone can 
> suggest tests or experiments to figure out what's going on
> I'd be most grateful. I'm no programmer but can follow 
> simple instructions. If this sounds like a known bug(s)
> links to bugzilla would be of much interest.
> 
> Many thanks for reading, and any ideas! If some essential
> details have been omitted please indicate and I'll try to
> supply them. 
> 

My questions and suggestions are all not network-knowledge
specific. My background does not span the public network
related material, sorry.

(Some of this duplicates some off-list activity.)


===
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 30 07:46:47 2022
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 1A79C1AB9C1D;
	Sat, 30 Apr 2022 07:46:57 +0000 (UTC)
	(envelope-from SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Kr1dq5DVtz4WT1;
	Sat, 30 Apr 2022 07:46:55 +0000 (UTC)
	(envelope-from SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl)
Date: Sat, 30 Apr 2022 09:46:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1651304808;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=l1Okte1UTIa/eeJqNPTCsE/3yRNgKLvydqpw9uhxqRQ=;
	b=jtqVR+Z70fQMx4A5jyQhDmChw8ItL8+/10yb2A45ucBOSDGxsXBohArVFOBD6FCJVSU+wq
	GL/nEUwpYtnIKlEMBpAkQLt1q6OJWcewXDPC8lgTk7c1KoQkdSlgSPBgkRGxYqTYMTg35P
	amRinbRmlOoLGULgXw8UezDF/fkKXVsyqBAI79dfLWMtStVawfo8EkmITMNKAjU2t3YZCK
	3X82FnEPlC+XiMZzML7tmPIiyZhtn3raIW6p8T7UUkh0YvMQTXKwdn0gurtXFhdkePaI4k
	OFHke2T6IWj1qz/W8SbwExCM85A8yyARgkZD587EdG4x4s2glGNikH3DCe13aw==
From: Ronald Klop 
To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org,
	bob prohaska 
Message-ID: <911244865.14233.1651304807669@localhost>
In-Reply-To: <20220430021207.GA7600@www.zefox.net>
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
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="----=_Part_14232_2027219218.1651304807667"
X-Mailer: Realworks (604.85.e688255)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4Kr1dq5DVtz4WT1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=jtqVR+Z7;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-1.23 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.991];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_SPAM_SHORT(0.96)[0.961];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-net];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MID_RHS_NOT_FQDN(0.50)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Z1EM=VI=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5886
Lines: 128

------=_Part_14232_2027219218.1651304807667
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,


Did you swap cables?


Regards,
Ronald


Van: bob prohaska 
Datum: 30 april 2022 04:13
Aan: freebsd-net@freebsd.org, freebsd-arm@freebsd.org
CC: bob prohaska 
Onderwerp: Re: 60+% ping packet loss on Pi3 under -current and stable-13

> 
> 
> Since about December of 2021 I've been noticing problems with
> wired network connectivity on a pair of raspberry pi 3 machines
> using wired network connections. One runs stable-13.1, the other
> runs -current, both are up to date as of a few days ago.
> 
> Essentially both machines fail to respond to inbound network
> connections via ssh or ping after reboot. If I get on the 
> serial console and start an outbound ping to anywhere, both
> machines respond to incoming pings with about a 65% packet
> loss. Ssh connections are answered with delays of zero to
> perhaps thirty seconds. Once connected ssh is usable but
> erratic, with dropped characters, multi-second delays and
> disconnects after random intervals from minutes to hours.
> 
> There are five other Raspberry Pi's on the network. Three
> Pi2's run 12.3-stable, one Pi2 runs -current and a Pi4 runs
> -current. All have no problems pinging one another and out
> of network, so there's nothing obviously wrong with the net.
> The network is not routed, but rather a block of eight
> addresses simply bridged from my ISP over DSL.
> 
> It's been found that an image of 13.1-RC4 behaves similarly
> on one Pi3 when on the public network but exhibits more normal
> ping response when moved to a 192.168.1.n private network. On
> the face of it, this seems significant, but I can't guess how.
> 
> I recall a post on one of the mailing lists about a bug that
> caused problems when packets arrived out-of-order via NAT, 
> but I'm using direct same-network pings and pinging through 
> NAT seems little-to-no worse.
> 
> I was hoping to upgrade my stable-12 machines to stable-13,
> but seeing this behavior gives me pause. If anyone can 
> suggest tests or experiments to figure out what's going on
> I'd be most grateful. I'm no programmer but can follow 
> simple instructions. If this sounds like a known bug(s)
> links to bugzilla would be of much interest.
> 
> Many thanks for reading, and any ideas! If some essential
> details have been omitted please indicate and I'll try to
> supply them. 
> 
> bob prohaska
>   
> 
> 
> 
> 
> 
> 
------=_Part_14232_2027219218.1651304807667
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Did you swap cables?

Regards,
Ronald

Van: bob prohaska <fbsd@www.zefox.net>
Datum: 30 april 2022 04:13
Aan: freebsd-net@freebsd.org, freebsd-arm@freebsd.org
CC: bob prohaska <fbsd@www.zefox.net>
Onderwerp: Re: 60+% ping packet loss on Pi3 under -current and stable-13


Since about December of 2021 I've been noticing problems with

wired network connectivity on a pair of raspberry pi 3 machines

using wired network connections. One runs stable-13.1, the other

runs -current, both are up to date as of a few days ago.



Essentially both machines fail to respond to inbound network

connections via ssh or ping after reboot. If I get on the 

serial console and start an outbound ping to anywhere, both

machines respond to incoming pings with about a 65% packet

loss. Ssh connections are answered with delays of zero to

perhaps thirty seconds. Once connected ssh is usable but

erratic, with dropped characters, multi-second delays and

disconnects after random intervals from minutes to hours.



There are five other Raspberry Pi's on the network. Three

Pi2's run 12.3-stable, one Pi2 runs -current and a Pi4 runs

-current. All have no problems pinging one another and out

of network, so there's nothing obviously wrong with the net.

The network is not routed, but rather a block of eight

addresses simply bridged from my ISP over DSL.



It's been found that an image of 13.1-RC4 behaves similarly

on one Pi3 when on the public network but exhibits more normal

ping response when moved to a 192.168.1.n private network. On

the face of it, this seems significant, but I can't guess how.



I recall a post on one of the mailing lists about a bug that

caused problems when packets arrived out-of-order via NAT, 

but I'm using direct same-network pings and pinging through 

NAT seems little-to-no worse.



I was hoping to upgrade my stable-12 machines to stable-13,

but seeing this behavior gives me pause. If anyone can 

suggest tests or experiments to figure out what's going on

I'd be most grateful. I'm no programmer but can follow 

simple instructions. If this sounds like a known bug(s)

links to bugzilla would be of much interest.



Many thanks for reading, and any ideas! If some essential

details have been omitted please indicate and I'll try to

supply them. 



bob prohaska

  
















------=_Part_14232_2027219218.1651304807667--

From nobody Sat Apr 30 08:40:38 2022
X-Original-To: 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 7907B1AC4F39
	for ; Sat, 30 Apr 2022 08:40:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4Kr2r43gKpz4gCW
	for ; Sat, 30 Apr 2022 08:40:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651308044; bh=kY7u5eRsKwpDIAhsWIJBT4ijqPwROm5r8+KtMaiCA40=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=WwMzNwyMdXVnP1DIIfpl3HjJkKE9hdw8N1ft+WonB84oFWi9uC66jajwFmuiZkMERurHfBP61VhzD0hbJKp3G0gNfLy5UkFfMLYyd6dOKq4tSAj1ZieFoFxeR/8tGO63+thC+7qpt7ms3cIoh6kza5NGQfvtx5Li/kn0uoWRHc7ujyl96icZ5+x9muswsht3A61/MmlhAw5OoDD2KJTDQ2U/tg3xC2TwNt1aOKf8mVwQ/4WkOeaphiNC8i6HARGChpKaMzKYyG2Su25gAXep2O/kQrtnFhHBmMyf/ZynMM269zO1EJ2fSDfUmFw+17C6xLjyaT+AVnTtIbdUbn1BfA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651308044; bh=1Ur0Ir8VuQUdR0iaSkDSw4btSoTQwiH9ueKVS/pXe6b=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GIGq2BeYo1qDwDlBJ9s5xeFWRUkniH+uO/wEv3Z79eWSLrJhrFaYfDbROOu30QgjXekXvOZJUjo6TiBL32q0EmHz/GnkwZC8Hp32pyktg2dzAfoysHRqQl9f74XlV1aecrEvqfavds+6THahfdwz1maMe/He4cmdp7aJYe1d9F897OLsJZoDxhsxoYQvTqpAAcLkuP5mdB4yqqDkWIlDNZXmJpBmJQUf4/W3rcV+TN1a1oC2P6TdqHMPFCS7Syi/EVf6acQXvv3DXJdvqWScb4tvNJ2a9NfFiDkQpD2d7Bj+PtFlEj0709nMDYzgEraaTvzm8NP5F0JVgbJBJQfYlw==
X-YMail-OSG: XnhXH3gVM1mktBT4bClKTUjZRcwSg4aKwiAmh4oBZ1kCJu1.sAv36SCcpfAueHm
 FCqnT7fx_fZc990MsbEaXxA5qGd7P7LObGO9E8WgjPQfg4Y.Setxqmo0Capaan2reRs4g0UgjO_C
 fsDnaEcuTJl2QOFn8ncRSzolZ2YWsnl7LSarFiSKgaa2s2WBrHpmbs3tJv_CV_7iXw.8J83PYJT_
 ohi860.1zjjswBLmv7iByVke.TD6sLqIWpejSYn_4JJEne6kW7.JJhOBhQEG5RhMXVfjqU.eZvLs
 umNfXsxoicFK5Sbs.Je8hhAqxnbtvE8B4M2TFCeE8qm.ReBYuvzeus0.O59JnMvJtsCvPOLn0Iut
 RlmQB3pq15ZUTB7sFYjDAQ0u0wSLA_aoGZVJ8ViiijoGwaHaghmZ.M_tLnFhWRC.wal_rdr8wvlq
 STIr1_t01dlMmTh5Cd.SQCt7h7kHfSGcYn1W_dmK0haeXCOZMlwtMhjh2Ip0uZSvo9c_T8bOOI2W
 8AVDhMhFm39jPMeAHiq9PeKq845K0X_2mR2.wctRotSHM2N7_ecZNdvDIKvXM3jPQSAJAESOLK9K
 j8TKSYSOvrxTH2BInO37ul6303wMB.vFKxzn1AJ96i1nRGsN0x3WA8RoXdUVFhFyOveUWAlcUD9X
 5OJS0gtnDsOxohHXtnRrYimkRH7htZ4pgmFY92A4DY2vZnBo7IrdM5ZOuZYjObJoEz44I5gpho7D
 v__OHM_tepcS9DpM5o_KyeMpRpFlCssclSntZLAhrB3rTqF84EfezZCkeCa1rkK42OwibxmDp8Wa
 w7WI4vdJHneXWRJn0OquZdMFNFGfL_JU9vzLbOaU.6PLvcht18uvQ0pvElFAuv2svIhIUlySNgtE
 hhFke7d2hyOqMlqMxnQ2hGbZ_zBlnetDmf3hfpCpuQAjPsPo9l0EeRwsvP43QF78ydyr7fWJymmN
 QnxVvmDi9KWjedRv9pgDGCiOCsycJIK9_5O2.GlRAkbDsgwgzxyiF40vDXCbX8tY030n1YB6xzIV
 olGcBRdgsydCYifUW3O5ik2cn..RX1G.T4tIVjwPy11_IgXIM20ZNbRVf_.UUCzdQxTKC9VSuDBo
 9cwX5Sb9NtIeQW8JiVjOsGC25mri0GWT2wKV_UzRCuuSxdte3DCSgdIQwk4n63MROiz.FNYcnvZd
 lpkHjyV.nzfY9Jqf6POQeV9CMdIThyhgdjXGghLm5D0iJaceUDvjdCTyXNDrSbElBRT.8N5dLR5B
 z7grScxbHy5YPewEmhSTmFmdehRDnvNrD4Yo1T7y81zdVChfAw0dFjCSrWPjEZ8L9mHC36dVav_h
 L20V_dPIFvJcoPmanxCMJG2H5DpZLXP9ZNUQWDcWoSvk.PlHfgu8DAkJEJ2pCAvFlANrIDKEFAVw
 gt5fKe3HClJZMyvqZkmY9xRjguAnh4jewbmxRmLFNtNvCxWH50l8nNduNUp8WHkXDJ1WNaeg37fP
 gfj060n_Fzk7mv.Niu3aquTHq7kdCQGxU3TlcAhZtcJS8X0AxMbLw_RG4vW1MjjGt579oFL_H6WG
 WFli4EdCYb3HIewiSfdwaTIoZW_bYoYSoT7gAa2ZQKihh109fkMyzFTXHzezTLFNiFnJP1Deprxz
 4FKRqHSkpqrhhmArLriRnQ7Rw4pjmtO0B..QqUqIMC_5gSqH9nF6Fs7cslY6eyd78P9QWDmFemnO
 vki2PGqVw5E1NqDt.YaqN42FcnmUOkfdf2dqmKgwU1IsBsGrqod2G.noUli46HQ_oc6Y.hRWdxGk
 9B6IesMFF4WvgJHFbKG2mHzzyPRTLZKmAJ0qAhdcIPYbM3g0B7ylH5ysuuvITubkeDC.TfbJeZCk
 JUYg3RLChMVja7N6Z7Zm1OVJZUZvF5wAFqFaUMXRV9rf8QXBHaMykq2GGtcC2EkvPqWQ9OENuWRm
 ojx2LbHTwzxZ5QtaHdOPHr_yktpdjztQUA2v7pKWCNXg11rH_MMQhlDmGJ58Ssb3pZtpfsWv4Oj9
 LE5Ds9iWxqdtHHXs907CHsm9t9gs4GM999w3ofRyVuSaF4jSqqliaNkGXcMxwItjMJVzvo8KIa0D
 fuSuN8cQwjAbhi0gMdJQgjlnsXxu0XWemXxTIN8zblSf3bdBIeHjWWOVe158NI7iGE2umxyV3J96
 IWXuV56gv8cxAnoWrO8T_K5LlNwApbMLRvGYEtm2cEsbMHKm3dFBhqfHCe2quXNMKLfji0uJBQFv
 gt5rDSWCST8BYjNsUBFqq5V6KvTrUvdekFCVHTgqqIkSb013IThPLj.xAWb3H_CEPopNxOQkkjdp
 ZNsjvUb4S
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Apr 2022 08:40:44 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-xkctq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8fb854b4798ad852b671c3fd0e1cd506;
          Sat, 30 Apr 2022 08:40:40 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi* firmware tagged 1.20210727 is *not* the last to be
 bootable by FreeBSD via fdt use for both RPI3B and RPI4B
Date: Sat, 30 Apr 2022 01:40:38 -0700
References: <80574F1B-1248-4B57-8E9C-CE92B5000908@yahoo.com>
To: "freebsd-arm@freebsd.org" 
In-Reply-To: <80574F1B-1248-4B57-8E9C-CE92B5000908@yahoo.com>
Message-Id: <2C979317-9C9F-46DC-B290-4E7A91548383@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kr2r43gKpz4gCW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=WwMzNwyM;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.87 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.959];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	 NEURAL_SPAM_SHORT(0.59)[0.588];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1908
Lines: 77

[1.20210805 works if I avoid deleting files that I should
not have deleted.]

On 2022-Apr-28, at 00:14, Mark Millard  wrote:

> I got ahold of the RPi3B and discovered that it was not
> bootable via RPi* firmware tagged 1.20210805 .

Turns out I had deleted a required firmware file
from 1.20210805 wihtout noticing. I finally noticed
that I'd done so after ending up with a 1.20210727
also did not work --for the same stupid-operator-error
reason.

> In fact,
> it barely produced any output on the serial console
> when set up for debug output: 2 lines, so very early
> failure. Reverting to the prior tagged release,
> 1.20210727 , worked for the RPi3B and the RPi4B.
> 
> The failure information for firmware with tags after
> 1.20210805 in the earlier notes to the list still
> apply, as does the bootability of the RPi4B for
> 1.20210805 .
> 
> This report is still based on use of my build of U-Boot
> 2022.04.
> 
> This report is still limited by the very limited range
> of RPi*'s that I have sometimes access to.
> 
> From what I've read, 1.20210727 should handle the new
> type of PMIC on the Rev. 1.5 RPi*'s. The firmware is
> too old to have:
> 
> bcm2710-rpi-zero-2-w.dtb
> bcm2710-rpi-zero-2.dtb
> bcm2711-rpi-cm4s.dtb
> 
> or the newer overlays:
> 
> adafruit-st7735r.dtbo
> cutiepi-panel.dtbo
> fbtft.dtbo
> imx519.dtbo
> iqs550.dtbo
> mcp2515.dtbo
> midi-uart2.dtbo
> midi-uart3.dtbo
> midi-uart4.dtbo
> midi-uart5.dtbo
> mipi-dbi-spi.dtbo
> mlx90640.dtbo
> ov2311.dtbo
> qca7000-uart0.dtbo
> spi0-0cs.dtbo
> vc4-kms-dpi-generic.dtbo
> vc4-kms-dpi-hyperpixel2r.dtbo
> vc4-kms-dpi-hyperpixel4.dtbo
> vc4-kms-dpi-hyperpixel4sq.dtbo
> vc4-kms-dpi-panel.dtbo
> vl805.dtbo
> waveshare-can-fd-hat-mode-a.dtbo
> waveshare-can-fd-hat-mode-b.dtbo
> 
> It also has one overlay that has been
> dropped:
> 
> vc4-kms-dpi-at056tn53v1.dtbo
> 



===
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 30 08:46:07 2022
X-Original-To: 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 8D2951AC6537
	for ; Sat, 30 Apr 2022 08:46:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30])
	(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 4Kr2yP2Bbyz4hQy
	for ; Sat, 30 Apr 2022 08:46:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651308373; bh=CcZx+Zuui3vrgWy5W0hqnn2Dn6YHDV9EbtVr24PryjQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=gjvVNQN/NhKqiBH9438Q4iZF//a3xTx6u5IPubZbL7EQXg7vlOLNEPehTcTSqSytwO1hHquI9Sgz89lD5CkfDTjlaEcRJy4z6vhS/VXzIFyLgSa806jrurUMi8e1SHWlwNkkApAD8/W+L8XC5wD85XtDs7mHrvowYbwFJnt8obmLm1kR9vq5usqamMKAG/ZxbVBisFpPw+0kj8A7LXDcooiHasNTJaL1pwRFFQC5tUz6SX6Q6Wo0OwkpnnSqwcbitXRBJmkU2iV4m5u3E/eJKT1Luj5SNanWmBRN5HHi8zsZlJFQaUeqQYVKfqoTj2rFIArBPlr1di4N5Q1duJ0YdA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651308373; bh=tkQ4d41FkHwdFTFnr9oUgaXyWM7s2WGI91t1An9s8SZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AsisUmEO6zuCp9Z1MEVZzz2rAV98tcgSnhwqlewJqeY5K9s9pYByGDF9MILnn6qw8JyHn5WRjN803kaCDt+X4BtceqkC2maGr2Zpws9qL64sG//iaEW4FuymmeopvssRsOdij7qCwOxZOxo3cE4+2XjBC5VCzMlGjJFCIGiKs+vJwI0meXXGASPhNIxXzZBUCdhqmupL9lbWsKe7hV+ImVzgsYlo8ae4csueOMjYpqSlJ09rwpGnEBRiwTftcw5k+FQ2hdDtH17G9dTB4dn1O28oIO4ZDX6jhZkJ6vmzywXBKCK2N0jMwGTm0xvgPO8HAsZRtW9YOU80fGjVH/MpGw==
X-YMail-OSG: wPryvp4VM1neXAeH5nATSYspDni25SXAC5CoBLNSmPq1Q7DjTJ6av1DlEzbWpx6
 lrlzJ.tAqxqeLgWcvgsTKT_fTSOiYhCDcgw1hZC8iPgm3g8PqI5JL.JPQZwzaY3tVvjPc7iojvb7
 hQKxuKSvQ8UeKg8OHtMjbG_jCD7vgRCYsWCYncWehyJNKEcejNqGnR5z8hNNXpjP7UPRkgS8cvPn
 t_uKz4r1IfWeXh1zBVlBNbkqEF__DZxzbAQV6gzrHphR0DadMdItgd9IirznALANpdCAJ_JUQQA7
 z4SUKt6Ysl6S1Lc3bE69RZfCZJOeefnCpeIOxNDSFGm.mt9NQTZgtJ3tb4vozVbfvPDW.PCRX2Cs
 gtxFaiXKchoMojAop5iQrkabSgi30gCiqqXg8V4dvzke0L_Tkf6uzwBoIcbquwigkt29qzuuSmPy
 2RlEoMMqGeupkunsRpU8Ms.CTAZdAWW.aZBA9k1cgpIZbK4.lWLvkNrgpf0.lNviJmxcfVoPB3cf
 Ed7G_hNCV4F3bAuVzl.kNe6geikkhodQq3qbkIMqqEmcktcyCeXOAx57kK4PdYHEUXMwgpi53yK7
 ty88fiVjIOCNQRefgNRG4620BeEfaMZ4GLk070mG.rTK2rPlN6k6ZzHk8JUdaCRvMceqhwRD7Wjj
 RaOu4nEJyuKlUoJ94fKvKp98bCEwi8NV.iZlBr9VnzS33f4F0DoaAazqjLfIfY937hy6K_PMBeoL
 2ODPfRkcEveMqSg6eGg.hgeXR1XiF1FqYO1uvcfQvfmSxvYA_xNUZpRze34JlCQ.IBj9tQ9eiiCL
 PqOWVSWp2de.6lT1WNOBG0HKdA7fmIXxXJ803hKrUPq6_rGpOevkZ1TYvl7Ch0.5fxa6QmNRvy17
 Xo1yEBM9sKdxB.mkvOhg1TIFlN2VV06YextsJsgG1yXrIOpddzU9ko_IG_CuPpsF6.zjdNQKZs99
 MmtqiNrvoqAPwdgbs.N.UHn1D4XH0ZVDFfI6kXgj6_Od7tX3hQYtritFk0ytrqv0jkyWxYTxYy.v
 j0PbNFZ5PW0hoJkDwumqVAJnNocu_3.quYugFquGxC8ouhAvLmf2Sm4BKBi4aJTR6q6mTsgXQ2zR
 DA3yF1HftEmOdeWaNPCRLKevEUG4kKdVNW2HaguLhlJZy_GGqm8zS6OdRBdisvO8rDvkKYYFddUS
 aJLpbHea7hpZ5bRK.suLttAIPQEfzi2NAXW.f.zIx4NO3LzPMC5tQNhEWXDe7Ne7nAOAr_9_w3VQ
 8IT5ZBKDDI6a1qAgc3fJ6pmL9Xhds6VIBji_Qcwhv9_the0JXlTLkrWUjxPRavEG69aI6Vk7vKMO
 nxmFdEaFQY4WzJ6_hdNygbTaCgIAf1tkvwf4EgTXRWIq5DtP6CqRQJ2NecSe4_6XslJTQmbMmbnw
 igxiKnYvn7fXas1U5ClNayGsIGYI0Gi_dm7GBEOPQKRjBpEwG3mhH8CBkek4GJPxrrfy.8UdW1cn
 EKaXZREoY7zlQzOSvZfzRc21WDbJ44kQkU.xzD4N1gldHyF8zUtOMt2OV2FPjkS7Xf_e93xOXk4L
 wB_BFYNMVGXw4EX88tqr_J7UJJoikaYYRZ13yix7ReroFUT8CJxTjldoxFatW63EF0H_LULqK3Xu
 KfBV3ro2eVBTf_tewIXhdVJKFXeFkOyfmewvbt9IQyaESo3td.dEQPDYMbhP0FNqnv4QWkDRDEBS
 Gqe5ySM9o.WHcBDCYr7WB79biyMBsEr_RhvlyeEq1Sexw4L_A4naxSbpdQUnHbOyMvWxs58IRlV3
 hTTLe8xY0rEvu4cfQusIxf1Vjee8dqVuQDbjdqDNCxH2JaV7wKAUI2a6wynj2eFyc53W3BZHrncE
 fcwqEmD17f1rTMux_ngsL3VxhG2f0eufRESzHKlsNSsnWoYdvulncWdnaXCQ1RGucYBmhHMCxZqY
 MCcksbgSM3ii_AGaXFmGSbCOOJK8Pi9Us0qzHHPbcS4u7JQ4zk4FosGKpM68ZJIQjs_MdCQlj.R3
 VKXeGKzlzPM.V5CBlPnL.vX5kyrPWGSMPSXU0BO5_hjen8E2J8Ru5f3WwcR4R6VsQrizs90UUQDf
 z_VcJZZFSq7TXOul4hl5qaibgMEzjLbKRrv2xd4kzHgTfUnLF12LBk8fOVC6pZwco5.GzgcvXcjk
 x4VT86HSKZAS9I_.wGKaLpiuuPhPfF0neTHS1czxIFN8wJPOCYTa6Dtu5PX5yzRdokc0QYHHEfcS
 NqQ1mNREThAo.eCqhz_0AaCeh3hcTBc1S1vfVzyrw3dELtdQcMDMkBDl5nNuhNu_JxNJtCveCRa1
 J.kNzNIfZ.A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Apr 2022 08:46:13 +0000
Received: by hermes--canary-production-gq1-647b99747d-xkjwp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8cdc0e4fe5c0bd8f4a294e9d185fe0f8;
          Sat, 30 Apr 2022 08:46:08 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi* firmware tagged 1.20210805 *is* the last to be bootable
 by FreeBSD via fdt use; sequence of 2 failure modes after that
Date: Sat, 30 Apr 2022 01:46:07 -0700
References: 
 <836019DE-531E-4B49-8A82-0D8F84885C21@yahoo.com>
 <8291972B-A953-4FD9-AA67-9F1F15AA3940@yahoo.com>
 
To: "freebsd-arm@freebsd.org" 
In-Reply-To: 
Message-Id: <4231C088-0156-4BFF-8B7E-BEBE76CB15B5@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Kr2yP2Bbyz4hQy
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="gjvVNQN/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.69 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.964];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from];
	 NEURAL_SPAM_SHORT(0.78)[0.777];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9383
Lines: 272

[1.20210805 works if I avoid deleting a file that I should
not have deleted.]

On 2022-Apr-27, at 23:47, Mark Millard  wrote:

> [Just an FYI: I got ahold of the RPi3B and discovered that
> it was not bootable via RPi* firmware tagged 1.20210805 .

Turns out I had deleted a required firmware file
from 1.20210805 without noticing. I finally noticed
that I'd done so after ending up with a 1.20210727
also did not work in the RPi3B --for the same
stupid-operator-error reason.

> . . . (junk text removed) . . .
>=20
> [I've not added to the below and have removed the long text
> block of RPi4B boot failure output.]
>=20
> On 2022-Apr-24, at 05:36, Mark Millard  wrote:
>=20
>> [I may have also found what leads to the extra messages for
>> the 2nd failure mode, an independent issue it turns out.]
>>=20
>> On 2022-Apr-24, at 04:37, Mark Millard  wrote:
>>=20
>>> [I think I found the reason for the boot crash that is
>>> a common failure to both failure modes. The 2nd mode
>>> has other issues I've not analyzed.]
>>>=20
>>> On 2022-Apr-23, at 23:45, Mark Millard  wrote:
>>>=20
>>>> The following is based on a microsd card with 13.1-RC4 on
>>>> it were I'd previously substituted my U-Boot 2022.04 build
>>>> and tested with the RPi* firmware that is in the 13.1-RC4
>>>> image. Here I've tried replacing the RPi* firmware and
>>>> holding the rest constant.
>>>>=20
>>>> The boot tests are on a 8 GiByte RPi4B Rev 1.14 with the
>>>> B0T stepping. I've not been copying over the linux kernels,
>>>> which they also bundle with the firmware.
>>>>=20
>>>> [13.1-RC4 is just what I happened to use. I doubt anything
>>>> here is special to 13.* or stable/13 or main [so: 14].
>>>> (I do not use 12.* or stable/12.)]
>>>>=20
>>>> The observed status went like . . .
>>>>=20
>>>>=20
>>>> firmware-1.20210805/boot/
>>>>=20
>>>> The RPi* release tagged 1.20210805 is the last version that
>>>> FreeBSD booted with. (Other than booting, logging in, and
>>>> shutting down, I've not been testing other aspects of
>>>> operation.)
>>>>=20
>>>> =46rom what I've read, firmware-1.20210805/boot/ should be
>>>> recent enough to handle the Rev 1.15 related PMIC variation.
>>>>=20
>>>> [I'll note that firmware build dates need not be the same day
>>>> as the date encoded into the tag --in fact it is usually some
>>>> earlier day. On rare occasion it can be a lot earlier, and
>>>> there is an example of that below.]
>>>>=20
>>>>=20
>>>> After firmware-1.20210805 there are 2 major failure modes.
>>>> Both stop at the same sort of point in the messaging --but
>>>> there is a huge difference in the count of earlier error
>>>> messages. It looks to me like all the issues require
>>>> FreeBSD changes if modern RPi* firmware/dtb's are to be
>>>> usable via fdt.
>>>=20
>>> I've noticed a difference between the working context and
>>> the failing ones (both failure modes).
>>>=20
>>> Failing:
>>>=20
>>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>>> spibus0:  on spi0
>>> spibus0:  at cs 0 mode 0
>>> spibus0:  at cs 1 mode 0
>>> NOTE BELOW LINES MISSING HERE.
>>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>>>=20
>>> Working:
>>>=20
>>> spi0:  mem 0x7e204000-0x7e2041ff irq 18 =
on simplebus0
>>> spibus0:  on spi0
>>> spibus0:  at cs 0 mode 0
>>> spibus0:  at cs 1 mode 0
>>> START LINES MISSING ABOVE
>>> iichb0:  mem 0x7e804000-0x7e804fff irq =
26 on simplebus0
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
>>> bcmwd0:  mem =
0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on =
simplebus0
>>> bcmrng0:  mem 0x7e104000-0x7e104027 on =
simplebus0
>>> gpioc1:  on gpio1
>>> END LINES MISSING ABOVE
>>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 73 on simplebus0
>>>=20
>>> In particular:
>>>=20
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
30,31,32,33,34,35,36,37,38,39,40 on simplebus0
>>>=20
>>> being missing means no bcm_dma_attach and that in turn means
>>> that the static bcm_dma_sc =3D=3D NULL still.
>>>=20
>>> The panic was: panic: vm_fault failed: ffff000000862134
>>>=20
>>> where:
>>>=20
>>> ffff000000862134  ldaxr  x1, [x9]
>>>=20
>>> which is part of:
>>>=20
>>> int
>>> bcm_dma_allocate(int req_ch)
>>> {
>>>      struct bcm_dma_softc *sc =3D bcm_dma_sc;
>>>      int ch =3D BCM_DMA_CH_INVALID;
>>>      int i;
>>>=20
>>>      if (req_ch >=3D BCM_DMA_CH_MAX)
>>>              return (BCM_DMA_CH_INVALID);
>>>=20
>>>      /* Auto(req_ch < 0) or CH specified */
>>>      mtx_lock(&sc->sc_mtx);
>>> . . .
>>>=20
>>> So the likes of &sc->sc_mtx end up being a small offset
>>> from address zero:
>>>=20
>>> x9:               20
>>>=20
>>> Thus the panic.
>>>=20
>>> As to how bcm_dma_allocate happened without bcm_dma_attach
>>> happening first . . .
>>>=20
>>> The working context's dtb has the ordering:
>>> (I also show mmcnr@ and the brcm,bcm2711-dma
>>> just for reference.)
>>>=20
>>>              dma@7e007000 {
>>>                      compatible =3D "brcm,bcm2835-dma";
>>> . . .
>>>              mmc@7e300000 {
>>>                      compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>>> . . .
>>>              mmcnr@7e300000 {
>>>                      compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>>> . . .
>>>              dma@7e007b00 {
>>>                      compatible =3D "brcm,bcm2711-dma";
>>>=20
>>> But the failing context's dtb has the ordering:
>>> (I also show mmcnr@ and the brcm,bcm2711-dma
>>> just for reference.)
>>>=20
>>>              mmc@7e300000 {
>>>                      compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>>> . . .
>>>              dma@7e007000 {
>>>                      compatible =3D "brcm,bcm2835-dma";
>>> . . .
>>>              mmcnr@7e300000 {
>>>                      compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
>>> . . .
>>>              dma@7e007b00 {
>>>                      compatible =3D "brcm,bcm2711-dma";
>>>=20
>>> So, for sequential handling in the failing case, the dma@7e007000
>>> would use bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach
>>> sequence had happened, leading to the crash.
>>>=20
>>> Note: I used "fdt print /" from U-Boot to get the dtb and its
>>> ordering. This was based on the address that the RPi* firmware
>>> reports when debugging output is enabled (0x4000 here).
>>>=20
>>>=20
>>>> The 1st mode happens for (I've added the -fails notation):
>>>>=20
>>>> firmware-1.20210831-fails/boot/
>>>> firmware-1.20210928-fails/boot/
>>>> firmware-1.20211007-fails/boot/
>>>> firmware-1.20211029-fails/boot/
>>>> firmware-1.20211118-fails/boot/
>>>> firmware-1.20220308_buster-fails/boot/
>>>> (The _buster one has firmware from 2021-Dec-01, which
>>>> is before all the tagged releases listed below.
>>>> It looks like the switch to the new major kernel
>>>> version after buster came with other changes that
>>>> FreeBSD has not tracked.)
>>>>=20
>>>>=20
>>>> The 2nd mode happens for the following. (Again with extra
>>>> notation.) There are a lot more error messages before the
>>>> panic happens for these. The firmware builds for these
>>>> are more recent than for the above list.
>>>>=20
>>>>=20
>>>> firmware-1.20220118-fails/boot/
>>>>=20
>>>> firmware-1.20220120-fails/boot/
>>>> firmware-1.20220308-fails-non-kernels-same-as-1.20220120/boot/
>>>> (I did not repeat the testing of the unchanged firmware.
>>>> I just did the "diff -r" to discover the lack of change.)
>>>>=20
>>>> firmware-1.20220328-fails/boot/
>>>> =
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files/boot/
>>>> (Since the .dtb for the RPi4B was different, I did test this.)
>>=20
>> It looks like the extra messages, blocks of:
>>=20
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>>=20
>> Are tied to new dtb content in 2022's dtb updates:
>>=20
>>       cam1_clk {
>>               compatible =3D "fixed-clock";
>>               #clock-cells =3D <0x00000000>;
>>               status =3D "disabled";
>>               phandle =3D <0x000000e2>;
>>       };
>> . . .
>>       cam0_clk {
>>               compatible =3D "fixed-clock";
>>               #clock-cells =3D <0x00000000>;
>>               status =3D "disabled";
>>               phandle =3D <0x000000e4>;
>>       };
>>=20
>> These 2 did not exist back when the 1st failure mode
>> started. They appear to be repeatedly processed from
>> not really being handled --leading to lots of
>> messages.
>>=20
>> The messages may just be noise for activity that is
>> not contributing to boot failures at all. So fixing
>> what I called the 1st failure mode might actually fix
>> booting for all the firmware versions after the
>> version tagged 1.20210805 .
>>=20
>>>> The failures look like (each test shown) . . .
>>>>=20
>>>>=20
>>>> . . .
>>>=20
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Apr 30 13:49:35 2022
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 126F71AB946E;
	Sat, 30 Apr 2022 13:49:39 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kr9hL2Nxwz3pWT;
	Sat, 30 Apr 2022 13:49:38 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=I3gPwgry3wFX+s8q6PdTnefJKjIXc4eunu+esphJO+U=; b=ocS18/LrQYEAt5fiD1pEaZFcc/
	NAvG7EnGBgAIC33SX1zHNfm5FEM5Qqq/3crLlFzf9ssczEYyhYn8HB/9CPR64D1n+z01vNf37r+Uf
	4/UyYp7AFaRysEniu8eWdu2H9Ys/e/vloymzwxKS7jH+f69r5/lBKvUclyCKFGgFuyec=;
Message-ID: 
Date: Sat, 30 Apr 2022 15:49:35 +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:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
Content-Language: en-US
To: freebsd-java@freebsd.org, freebsd-arm@freebsd.org
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
From: Ronald Klop 
In-Reply-To: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: ---
X-Spam-Score: -3.3
X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2
X-Scan-Signature: de945f48030f42d2750e746b7c1207b1
X-Rspamd-Queue-Id: 4Kr9hL2Nxwz3pWT
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b="ocS18/Lr";
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-2.48 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.75)[-0.745];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-java,freebsd-arm];
	 NEURAL_HAM_SHORT(-0.84)[-0.836];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 32323
Lines: 443

SGksDQoNCk9wZW5qZGsxNyBhbmQgb3BlbmpkazEzIGFyZSBmYWlsaW5nIG9uIDEzMGFybTY0
Lg0KDQpUaGlzIHN0YXJ0ZWQgaW4gTWFyY2gsIEkgZG9uJ3Qgc2VlIGEgYnVnIHJlcG9ydCBp
biBCdWd6aWxsYSBhYm91dCBpdC4NCk9wZW5qZGsxNyBpcyBhIExUUyB2ZXJzaW9uIHNvIGl0
IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB0aGF0IG9uZSBmaXhlZC4gT3BlbmpkazEzIGlzIGRl
cHJlY2F0ZWQgc28gZG9uJ3QgYm90aGVyIGFib3V0IHRoYXQgb25lIGJ1dCBtZW50aW9uaW5n
IGlzIGJlY2F1c2UgaXQgbWlnaHQgYmUgcmVsYXRlZC4NCg0KQmVsb3cgdGhlIG9wZW5qZGsx
NyBsb2cuDQoNClRoZSBidWlsZCBmb3IgbWFpbi1hcm02NCBoYWQgdGhlIHNhbWUgZXJyb3I6
IChJUHY2OikgaHR0cDovL2FtcGVyZTIubnlpLmZyZWVic2Qub3JnL2RhdGEvbWFpbi1hcm02
NC1kZWZhdWx0L3A2Mjg1MGQyOGNhNTdfczY1MWE4ODdmNGUvbG9ncy9lcnJvcnMvb3Blbmpk
azE3LTE3LjAuMis4LjEubG9nDQoNClJlZ2FyZHMsDQpSb25hbGQuDQoNCg0KDQoNCk9uIDQv
MzAvMjIgMTM6MjksIHBrZy1mYWxsb3V0QEZyZWVCU0Qub3JnIHdyb3RlOg0KPiBZb3UgYXJl
IHJlY2VpdmluZyB0aGlzIG1haWwgYXMgYSBwb3J0IHRoYXQgeW91IG1haW50YWluDQo+IGlz
IGZhaWxpbmcgdG8gYnVpbGQgb24gdGhlIEZyZWVCU0QgcGFja2FnZSBidWlsZCBzZXJ2ZXIu
DQo+IFBsZWFzZSBpbnZlc3RpZ2F0ZSB0aGUgZmFpbHVyZSBhbmQgc3VibWl0IGEgUFIgdG8g
Zml4DQo+IGJ1aWxkLg0KPiANCj4gTWFpbnRhaW5lcjogICAgIGphdmFARnJlZUJTRC5vcmcN
Cj4gTG9nIFVSTDogICAgICAgIGh0dHA6Ly9hbXBlcmUzLm55aS5mcmVlYnNkLm9yZy9kYXRh
LzEzMGFybTY0LWRlZmF1bHQvYjM3NzY4NTQxMTYxL2xvZ3Mvb3BlbmpkazE3LTE3LjAuMis4
LjEubG9nDQo+IEJ1aWxkIFVSTDogICAgICBodHRwOi8vYW1wZXJlMy5ueWkuZnJlZWJzZC5v
cmcvYnVpbGQuaHRtbD9tYXN0ZXJuYW1lPTEzMGFybTY0LWRlZmF1bHQmYnVpbGQ9YjM3NzY4
NTQxMTYxDQo+IExvZzoNCj4gDQo+ID0+PiBCdWlsZGluZyBqYXZhL29wZW5qZGsxNw0KPiBi
dWlsZCBzdGFydGVkIGF0IFNhdCBBcHIgMzAgMTE6Mjg6NTYgVVRDIDIwMjINCj4gcG9ydCBk
aXJlY3Rvcnk6IC91c3IvcG9ydHMvamF2YS9vcGVuamRrMTcNCj4gcGFja2FnZSBuYW1lOiBv
cGVuamRrMTctMTcuMC4yKzguMQ0KPiBidWlsZGluZyBmb3I6IEZyZWVCU0QgMTMwYXJtNjQt
ZGVmYXVsdC1qb2ItMTEgMTMuMC1SRUxFQVNFLXAxMSBGcmVlQlNEIDEzLjAtUkVMRUFTRS1w
MTEgYXJtNjQNCj4gbWFpbnRhaW5lZCBieTogamF2YUBGcmVlQlNELm9yZw0KPiBNYWtlZmls
ZSBpZGVudDoNCj4gUG91ZHJpZXJlIHZlcnNpb246IDMuMi44LTIxLWc4ODNhZmIwNw0KPiBI
b3N0IE9TVkVSU0lPTjogMTQwMDA1MA0KPiBKYWlsIE9TVkVSU0lPTjogMTMwMDEzOQ0KPiBK
b2IgSWQ6IDExDQo+IA0KPiAtLS1CZWdpbiBFbnZpcm9ubWVudC0tLQ0KPiBTSEVMTD0vYmlu
L2NzaA0KPiBPU1ZFUlNJT049MTMwMDEzOQ0KPiBVTkFNRV92PUZyZWVCU0QgMTMuMC1SRUxF
QVNFLXAxMQ0KPiBVTkFNRV9yPTEzLjAtUkVMRUFTRS1wMTENCj4gQkxPQ0tTSVpFPUsNCj4g
TUFJTD0vdmFyL21haWwvcm9vdA0KPiBNTV9DSEFSU0VUPVVURi04DQo+IExBTkc9Qy5VVEYt
OA0KPiBTVEFUVVM9MQ0KPiBIT01FPS9yb290DQo+IFBBVEg9L3NiaW46L2JpbjovdXNyL3Ni
aW46L3Vzci9iaW46L3Vzci9sb2NhbC9zYmluOi91c3IvbG9jYWwvYmluOi9yb290L2Jpbg0K
PiBMT0NBTEJBU0U9L3Vzci9sb2NhbA0KPiBVU0VSPXJvb3QNCj4gTElCRVhFQ1BSRUZJWD0v
dXNyL2xvY2FsL2xpYmV4ZWMvcG91ZHJpZXJlDQo+IFBPVURSSUVSRV9WRVJTSU9OPTMuMi44
LTIxLWc4ODNhZmIwNw0KPiBNQVNURVJNTlQ9L3Vzci9sb2NhbC9wb3VkcmllcmUvZGF0YS8u
bS8xMzBhcm02NC1kZWZhdWx0L3JlZg0KPiBQT1VEUklFUkVfQlVJTERfVFlQRT1idWxrDQo+
IFBBQ0tBR0VfQlVJTERJTkc9eWVzDQo+IFNBVkVEX1RFUk09DQo+IFBXRD0vdXNyL2xvY2Fs
L3BvdWRyaWVyZS9kYXRhLy5tLzEzMGFybTY0LWRlZmF1bHQvcmVmLy5wL3Bvb2wNCj4gUF9Q
T1JUU19GRUFUVVJFUz1GTEFWT1JTIFNFTEVDVEVEX09QVElPTlMNCj4gTUFTVEVSTkFNRT0x
MzBhcm02NC1kZWZhdWx0DQo+IFNDUklQVFBSRUZJWD0vdXNyL2xvY2FsL3NoYXJlL3BvdWRy
aWVyZQ0KPiBPTERQV0Q9L3Vzci9sb2NhbC9wb3VkcmllcmUvZGF0YS8ubS8xMzBhcm02NC1k
ZWZhdWx0L3JlZi8ucA0KPiBTQ1JJUFRQQVRIPS91c3IvbG9jYWwvc2hhcmUvcG91ZHJpZXJl
L2J1bGsuc2gNCj4gUE9VRFJJRVJFUEFUSD0vdXNyL2xvY2FsL2Jpbi9wb3VkcmllcmUNCj4g
LS0tRW5kIEVudmlyb25tZW50LS0tDQo+IA0KPiAtLS1CZWdpbiBQb3VkcmllcmUgUG9ydCBG
bGFncy9FbnYtLS0NCj4gUE9SVF9GTEFHUz0NCj4gUEtHRU5WPQ0KPiBGTEFWT1I9DQo+IERF
UEVORFNfQVJHUz0NCj4gTUFLRV9BUkdTPQ0KPiAtLS1FbmQgUG91ZHJpZXJlIFBvcnQgRmxh
Z3MvRW52LS0tDQo+IA0KPiAtLS1CZWdpbiBPUFRJT05TIExpc3QtLS0NCj4gLS0tRW5kIE9Q
VElPTlMgTGlzdC0tLQ0KPiANCj4gLS1NQUlOVEFJTkVSLS0NCj4gamF2YUBGcmVlQlNELm9y
Zw0KPiAtLUVuZCBNQUlOVEFJTkVSLS0NCj4gDQo+IC0tQ09ORklHVVJFX0FSR1MtLQ0KPiAt
LXdpdGgtYm9vdC1qZGs9L3Vzci9sb2NhbC9ib290c3RyYXAtb3BlbmpkazE3ICAtLWRpc2Fi
bGUtY2NhY2hlICAtLWRpc2FibGUtamF2YWMtc2VydmVyICAtLWRpc2FibGUtaG90c3BvdC1n
dGVzdCAgLS13aXRoLWFsc2E9L3Vzci9sb2NhbCAgLS13aXRoLWN1cHM9L3Vzci9sb2NhbCAg
LS13aXRoLWZvbnRjb25maWc9L3Vzci9sb2NhbCAgLS13aXRoLWZyZWV0eXBlPXN5c3RlbSAg
LS13aXRoLWZyZWV0eXBlLWluY2x1ZGU9L3Vzci9sb2NhbC9pbmNsdWRlL2ZyZWV0eXBlMiAg
LS13aXRoLWZyZWV0eXBlLWxpYj0vdXNyL2xvY2FsL2xpYiAgLS13aXRoLWxpYmpwZWc9c3lz
dGVtICAtLXdpdGgtZ2lmbGliPXN5c3RlbSAgLS13aXRoLWdpZmxpYi1pbmNsdWRlPS91c3Iv
bG9jYWwvaW5jbHVkZSAgLS13aXRoLWdpZmxpYi1saWI9L3Vzci9sb2NhbC9saWIgIC0td2l0
aC1oYXJmYnV6ej1zeXN0ZW0gIC0td2l0aC1saWJwbmc9c3lzdGVtICAtLXdpdGgtemxpYj1z
eXN0ZW0gIC0td2l0aC1sY21zPXN5c3RlbSAgLS14LWluY2x1ZGVzPS91c3IvbG9jYWwvaW5j
bHVkZSAgLS14LWxpYnJhcmllcz0vdXNyL2xvY2FsL2xpYiAgLS13aXRoLWNhY2VydHMtZmls
ZT0vdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3L2ZpbGVzL2NhY2VydHMgIC0td2l0aC12ZXJz
aW9uLXN0cmluZz0xNy4wLjIrOC0xICAtLXdpdGgtbmF0aXZlLWRlYnVnLXN5bWJvbHM9bm9u
ZSAgLS13aXRoLWRlYnVnLWxldmVsPXJlbGVhc2UgIC0td2l0aC12ZW5kb3ItbmFtZT0iT3Bl
bkpESyBCU0QgUG9ydGluZyBUZWFtIiAgLS13aXRoLXZlbmRvci11cmw9Imh0dHBzOi8vZ2l0
aHViLmNvbS9iYXR0bGVibG93L2pkazE3dS8iICAtLXdpdGgtdmVuZG9yLWJ1Zy11cmw9Imh0
dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxsYS9lbnRlcl9idWcuY2dpP3Byb2R1Y3Q9
UG9ydHMlMjAlMjYlMjBQYWNrYWdlcyZjb21wb25lbnQ9SW5kaXZpZHVhbCUyMFBvcnQocykm
c2hvcnRfZGVzYz1qYXZhL29wZW5qZGsxNw0KPiAgICUzQSUyMCIgIC0td2l0aC12ZW5kb3It
dm0tYnVnLXVybD0iaHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL2VudGVyX2J1
Zy5jZ2k/cHJvZHVjdD1Qb3J0cyUyMCUyNiUyMFBhY2thZ2VzJmNvbXBvbmVudD1JbmRpdmlk
dWFsJTIwUG9ydChzKSZzaG9ydF9kZXNjPWphdmEvb3BlbmpkazE3JTNBJTIwIiAtLXdpdGgt
dG9vbGNoYWluLXR5cGU9Y2xhbmcgLS1kaXNhYmxlLXdhcm5pbmdzLWFzLWVycm9ycyAtLWRp
c2FibGUtZHRyYWNlIC0teC1saWJyYXJpZXM9L3Vzci9sb2NhbC9saWIgLS14LWluY2x1ZGVz
PS91c3IvbG9jYWwvaW5jbHVkZSAtLXByZWZpeD0vdXNyL2xvY2FsICR7X0xBVEVfQ09ORklH
VVJFX0FSR1N9DQo+IC0tRW5kIENPTkZJR1VSRV9BUkdTLS0NCj4gDQo+IC0tQ09ORklHVVJF
X0VOVi0tDQo+IENDPWNjICBDWFg9YysrICBDUFA9Y3BwICBhY19jdl9wYXRoX1NFRD0vdXNy
L2xvY2FsL2Jpbi9nc2VkIE1BS0U9Z21ha2UgUEtHX0NPTkZJRz1wa2djb25mIFhER19EQVRB
X0hPTUU9L3dya2RpcnMvdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3L3dvcmsgIFhER19DT05G
SUdfSE9NRT0vd3JrZGlycy91c3IvcG9ydHMvamF2YS9vcGVuamRrMTcvd29yayAgWERHX0NB
Q0hFX0hPTUU9L3dya2RpcnMvdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3L3dvcmsvLmNhY2hl
ICBIT01FPS93cmtkaXJzL3Vzci9wb3J0cy9qYXZhL29wZW5qZGsxNy93b3JrIFRNUERJUj0i
L3RtcCIgUEFUSD0vd3JrZGlycy91c3IvcG9ydHMvamF2YS9vcGVuamRrMTcvd29yay8uYmlu
Oi9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluOi91c3IvbG9jYWwvc2JpbjovdXNyL2xv
Y2FsL2Jpbjovcm9vdC9iaW4gU0hFTEw9L2Jpbi9zaCBDT05GSUdfU0hFTEw9L2Jpbi9zaCBD
T05GSUdfU0lURT0vdXNyL3BvcnRzL1RlbXBsYXRlcy9jb25maWcuc2l0ZSBsdF9jdl9zeXNf
bWF4X2NtZF9sZW49NTI0Mjg4DQo+IC0tRW5kIENPTkZJR1VSRV9FTlYtLQ0KPiANCj4gLS1N
QUtFX0VOVi0tDQo+IExBTkc9IkMiICBMQ19BTEw9IkMiICBDTEFTU1BBVEg9IiIgIEpBVkFf
SE9NRT0iIiAgTERfTElCUkFSWV9QQVRIPSIiICBDQz1jYyAgQ1hYPWMrKyAgQ1BQPWNwcCAg
TUFLRUZMQUdTPSIiIC0td2l0aC10b29sY2hhaW4tdHlwZT1jbGFuZyBVU0VfQ0xBTkc9dHJ1
ZSBYREdfREFUQV9IT01FPS93cmtkaXJzL3Vzci9wb3J0cy9qYXZhL29wZW5qZGsxNy93b3Jr
ICBYREdfQ09ORklHX0hPTUU9L3dya2RpcnMvdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3L3dv
cmsgIFhER19DQUNIRV9IT01FPS93cmtkaXJzL3Vzci9wb3J0cy9qYXZhL29wZW5qZGsxNy93
b3JrLy5jYWNoZSAgSE9NRT0vd3JrZGlycy91c3IvcG9ydHMvamF2YS9vcGVuamRrMTcvd29y
ayBUTVBESVI9Ii90bXAiIFBBVEg9L3dya2RpcnMvdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3
L3dvcmsvLmJpbjovc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2JpbjovdXNyL2xvY2FsL3Ni
aW46L3Vzci9sb2NhbC9iaW46L3Jvb3QvYmluIE5PX1BJRT15ZXMgTUtfREVCVUdfRklMRVM9
bm8gTUtfS0VSTkVMX1NZTUJPTFM9bm8gU0hFTEw9L2Jpbi9zaCBOT19MSU5UPVlFUyBQUkVG
SVg9L3Vzci9sb2NhbCAgTE9DQUxCQVNFPS91c3IvbG9jYWwgIENDPSJjYyIgQ0ZMQUdTPSIt
TzIgLXBpcGUgIC1ETElCSUNPTlZfUExVRyAtZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgLWZu
by1zdHJpY3QtYWxpYXNpbmcgIiAgQ1BQPSJjcHAiIENQUEZMQUdTPSItRExJQklDT05WX1BM
VUciICBMREZMQUdTPSIgLWZzdGFjay1wcm90ZWN0b3Itc3Ryb25nICIgTElCUz0iIiAgQ1hY
PSJjKysiIENYWEZMQUdTPSItTzIgLXBpcGUgLURMSUJJQ09OVl9QTFVHIC1mc3RhY2stcHJv
dGVjdG9yLXN0cm9uZyAtZm5vLXN0cmljdC1hbGlhc2luZyAgLURMSUJJQ09OVl9QTFVHICIg
IE1BTlBSRUZJWD0iL3Vzci9sb2NhbCIgQlNEX0lOU1RBTExfUFJPR1JBTT0iaW5zdGFsbCAg
LXMgLW0gNTU1IiAgQlNEX0lOU1RBTExfTElCPSJpbnN0YWxsICAtDQo+ICAgcyAtbSAwNjQ0
IiAgQlNEX0lOU1RBTExfU0NSSVBUPSJpbnN0YWxsICAtbSA1NTUiICBCU0RfSU5TVEFMTF9E
QVRBPSJpbnN0YWxsICAtbSAwNjQ0IiAgQlNEX0lOU1RBTExfTUFOPSJpbnN0YWxsICAtbSA0
NDQiDQo+IC0tRW5kIE1BS0VfRU5WLS0NCj4gDQo+IC0tUExJU1RfU1VCLS0NCj4gT1NSRUw9
MTMuMCBQUkVGSVg9JUQgTE9DQUxCQVNFPS91c3IvbG9jYWwgIFJFU0VUUFJFRklYPS91c3Iv
bG9jYWwgTElCMzJESVI9bGliIERPQ1NESVI9InNoYXJlL2RvYy9vcGVuamRrIiAgRVhBTVBM
RVNESVI9InNoYXJlL2V4YW1wbGVzL29wZW5qZGsiICBEQVRBRElSPSJzaGFyZS9vcGVuamRr
IiAgV1dXRElSPSJ3d3cvb3BlbmpkayIgIEVUQ0RJUj0iZXRjL29wZW5qZGsiDQo+IC0tRW5k
IFBMSVNUX1NVQi0tDQo+IA0KPiAtLVNVQl9MSVNULS0NCj4gUFJFRklYPS91c3IvbG9jYWwg
TE9DQUxCQVNFPS91c3IvbG9jYWwgIERBVEFESVI9L3Vzci9sb2NhbC9zaGFyZS9vcGVuamRr
IERPQ1NESVI9L3Vzci9sb2NhbC9zaGFyZS9kb2Mvb3BlbmpkayBFWEFNUExFU0RJUj0vdXNy
L2xvY2FsL3NoYXJlL2V4YW1wbGVzL29wZW5qZGsgIFdXV0RJUj0vdXNyL2xvY2FsL3d3dy9v
cGVuamRrIEVUQ0RJUj0vdXNyL2xvY2FsL2V0Yy9vcGVuamRrDQo+IC0tRW5kIFNVQl9MSVNU
LS0NCj4gDQo+IC0tLUJlZ2luIG1ha2UuY29uZi0tLQ0KPiBVU0VfUEFDS0FHRV9ERVBFTkRT
PXllcw0KPiBCQVRDSD15ZXMNCj4gV1JLRElSUFJFRklYPS93cmtkaXJzDQo+IFBPUlRTRElS
PS91c3IvcG9ydHMNCj4gUEFDS0FHRVM9L3BhY2thZ2VzDQo+IERJU1RESVI9L2Rpc3RmaWxl
cw0KPiBQQUNLQUdFX0JVSUxESU5HPXllcw0KPiBQQUNLQUdFX0JVSUxESU5HX0ZMQVZPUlM9
eWVzDQo+ICMjIyMgL3Vzci9sb2NhbC9ldGMvcG91ZHJpZXJlLmQvbWFrZS5jb25mICMjIyMN
Cj4gIyBYWFg6IFdlIHJlYWxseSBuZWVkIHRoaXMgYnV0IGNhbm5vdCB1c2UgaXQgd2hpbGUg
J21ha2UgY2hlY2tzdW0nIGRvZXMgbm90DQo+ICMgdHJ5IHRoZSBuZXh0IG1pcnJvciBvbiBj
aGVja3N1bSBmYWlsdXJlLiAgSXQgY3VycmVudGx5IHJldHJpZXMgdGhlIHNhbWUNCj4gIyBm
YWlsZWQgbWlycm9yIGFuZCB0aGVuIGZhaWxzIHJhdGhlciB0aGVuIHRyeWluZyBhbm90aGVy
LiAgSXQgKmRvZXMqDQo+ICMgdHJ5IHRoZSBuZXh0IGlmIHRoZSBzaXplIGlzIG1pc21hdGNo
ZWQgdGhvdWdoLg0KPiAjTUFTVEVSX1NJVEVfRlJFRUJTRD15ZXMNCj4gIyBCdWlsZCBBTExP
V19NQUtFX0pPQlNfUEFDS0FHRVMgd2l0aCAyIGpvYnMNCj4gTUFLRV9KT0JTX05VTUJFUj0y
DQo+ICMjIyMgL3Vzci9wb3J0cy9Nay9TY3JpcHRzL3BvcnRzX2Vudi5zaCAjIyMjDQo+IF9D
Q1ZFUlNJT05fOTIxZGJiYjI9RnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDExLjAuMSAoZ2l0QGdp
dGh1Yi5jb206bGx2bS9sbHZtLXByb2plY3QuZ2l0IGxsdm1vcmctMTEuMC4xLTAtZzQzZmY3
NWYyYzNmZSkgVGFyZ2V0OiBhYXJjaDY0LXVua25vd24tZnJlZWJzZDEzLjAgVGhyZWFkIG1v
ZGVsOiBwb3NpeCBJbnN0YWxsZWREaXI6IC91c3IvYmluDQo+IF9BTFRDQ1ZFUlNJT05fOTIx
ZGJiYjI9bm9uZQ0KPiBfQ1hYSU5URVJOQUxfYWNhYWQ5Y2E9RnJlZUJTRCBjbGFuZyB2ZXJz
aW9uIDExLjAuMSAoZ2l0QGdpdGh1Yi5jb206bGx2bS9sbHZtLXByb2plY3QuZ2l0IGxsdm1v
cmctMTEuMC4xLTAtZzQzZmY3NWYyYzNmZSkgVGFyZ2V0OiBhYXJjaDY0LXVua25vd24tZnJl
ZWJzZDEzLjAgVGhyZWFkIG1vZGVsOiBwb3NpeCBJbnN0YWxsZWREaXI6IC91c3IvYmluICIv
dXNyL2Jpbi9sZCIgIi0tZWgtZnJhbWUtaGRyIiAiLWR5bmFtaWMtbGlua2VyIiAiL2xpYmV4
ZWMvbGQtZWxmLnNvLjEiICItLWVuYWJsZS1uZXctZHRhZ3MiICItbyIgImEub3V0IiAiL3Vz
ci9saWIvY3J0MS5vIiAiL3Vzci9saWIvY3J0aS5vIiAiL3Vzci9saWIvY3J0YmVnaW4ubyIg
Ii1ML3Vzci9saWIiICIvZGV2L251bGwiICItbGMrKyIgIi1sbSIgIi1sZ2NjIiAiLS1hcy1u
ZWVkZWQiICItbGdjY19zIiAiLS1uby1hcy1uZWVkZWQiICItbGMiICItbGdjYyIgIi0tYXMt
bmVlZGVkIiAiLWxnY2NfcyIgIi0tbm8tYXMtbmVlZGVkIiAiL3Vzci9saWIvY3J0ZW5kLm8i
ICIvdXNyL2xpYi9jcnRuLm8iDQo+IENDX09VVFBVVF85MjFkYmJiMl81ODE3Mzg0OT15ZXMN
Cj4gQ0NfT1VUUFVUXzkyMWRiYmIyXzliZGJhNTdjPXllcw0KPiBDQ19PVVRQVVRfOTIxZGJi
YjJfNmE0ZmU3ZjU9eWVzDQo+IENDX09VVFBVVF85MjFkYmJiMl82YmNhYzAyYj15ZXMNCj4g
Q0NfT1VUUFVUXzkyMWRiYmIyXzY3ZDIwODI5PXllcw0KPiBDQ19PVVRQVVRfOTIxZGJiYjJf
YmZhNjJlODM9eWVzDQo+IENDX09VVFBVVF85MjFkYmJiMl9mMGI0ZDU5Mz15ZXMNCj4gQ0Nf
T1VUUFVUXzkyMWRiYmIyXzMwOGFiYjQ0PXllcw0KPiBDQ19PVVRQVVRfOTIxZGJiYjJfZjAw
NDU2ZTU9eWVzDQo+IENDX09VVFBVVF85MjFkYmJiMl82NWFkMjkwZD15ZXMNCj4gQ0NfT1VU
UFVUXzkyMWRiYmIyX2YyNzc2YjI2PXllcw0KPiBDQ19PVVRQVVRfOTIxZGJiYjJfYjI2NTdj
YzM9eWVzDQo+IENDX09VVFBVVF85MjFkYmJiMl8zODA5ODdmNz15ZXMNCj4gQ0NfT1VUUFVU
XzkyMWRiYmIyXzE2MDkzM2VjPXllcw0KPiBDQ19PVVRQVVRfOTIxZGJiYjJfZmI2MjgwM2I9
eWVzDQo+IF9PQkpDX0NDVkVSU0lPTl85MjFkYmJiMj1GcmVlQlNEIGNsYW5nIHZlcnNpb24g
MTEuMC4xIChnaXRAZ2l0aHViLmNvbTpsbHZtL2xsdm0tcHJvamVjdC5naXQgbGx2bW9yZy0x
MS4wLjEtMC1nNDNmZjc1ZjJjM2ZlKSBUYXJnZXQ6IGFhcmNoNjQtdW5rbm93bi1mcmVlYnNk
MTMuMCBUaHJlYWQgbW9kZWw6IHBvc2l4IEluc3RhbGxlZERpcjogL3Vzci9iaW4NCj4gX09C
SkNfQUxUQ0NWRVJTSU9OXzkyMWRiYmIyPW5vbmUNCj4gQVJDSD1hYXJjaDY0DQo+IE9QU1lT
PUZyZWVCU0QNCj4gX09TUkVMRUFTRT0xMy4wLVJFTEVBU0UtcDExDQo+IE9TUkVMPTEzLjAN
Cj4gT1NWRVJTSU9OPTEzMDAxMzkNCj4gUFlUSE9OQkFTRT0vdXNyL2xvY2FsDQo+IENPTkZJ
R1VSRV9NQVhfQ01EX0xFTj01MjQyODgNCj4gSEFWRV9QT1JUU19FTlY9MQ0KPiAjIyMjIE1p
c2MgUG91ZHJpZXJlICMjIyMNCj4gR0lEPTANCj4gVUlEPTANCj4gLS0tRW5kIG1ha2UuY29u
Zi0tLQ0KPiAtLVJlc291cmNlIGxpbWl0cy0tDQo+IGNwdSB0aW1lICAgICAgICAgICAgICAg
KHNlY29uZHMsIC10KSAgdW5saW1pdGVkDQo+IGZpbGUgc2l6ZSAgICAgICAgICAgKDUxMi1i
bG9ja3MsIC1mKSAgdW5saW1pdGVkDQo+IGRhdGEgc2VnIHNpemUgICAgICAgICAgIChrYnl0
ZXMsIC1kKSAgMTA0ODU3Ng0KPiBzdGFjayBzaXplICAgICAgICAgICAgICAoa2J5dGVzLCAt
cykgIDEwNDg1NzYNCj4gY29yZSBmaWxlIHNpemUgICAgICAoNTEyLWJsb2NrcywgLWMpICB1
bmxpbWl0ZWQNCj4gbWF4IG1lbW9yeSBzaXplICAgICAgICAgKGtieXRlcywgLW0pICB1bmxp
bWl0ZWQNCj4gbG9ja2VkIG1lbW9yeSAgICAgICAgICAgKGtieXRlcywgLWwpICB1bmxpbWl0
ZWQNCj4gbWF4IHVzZXIgcHJvY2Vzc2VzICAgICAgICAgICAgICAoLXUpICA4OTk5OQ0KPiBv
cGVuIGZpbGVzICAgICAgICAgICAgICAgICAgICAgICgtbikgIDEwMjQNCj4gdmlydHVhbCBt
ZW0gc2l6ZSAgICAgICAgKGtieXRlcywgLXYpICB1bmxpbWl0ZWQNCj4gc3dhcCBsaW1pdCAg
ICAgICAgICAgICAgKGtieXRlcywgLXcpICB1bmxpbWl0ZWQNCj4gc29ja2V0IGJ1ZmZlciBz
aXplICAgICAgIChieXRlcywgLWIpICB1bmxpbWl0ZWQNCj4gcHNldWRvLXRlcm1pbmFscyAg
ICAgICAgICAgICAgICAoLXApICB1bmxpbWl0ZWQNCj4ga3F1ZXVlcyAgICAgICAgICAgICAg
ICAgICAgICAgICAoLWspICB1bmxpbWl0ZWQNCj4gdW10eCBzaGFyZWQgbG9ja3MgICAgICAg
ICAgICAgICAoLW8pICB1bmxpbWl0ZWQNCj4gLS1FbmQgcmVzb3VyY2UgbGltaXRzLS0NCj4g
PT09PT09PT09PT09PT09PT09PT09PT08cGhhc2U6IGNoZWNrLXNhbml0eSAgID49PT09PT09
PT09PT09PT09PT09PT09PT09PT09DQo+ID09PT4gIExpY2Vuc2UgR1BMdjIgYWNjZXB0ZWQg
YnkgdGhlIHVzZXINCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID09PT09PT09PT09PT09
PT09PT09PT09PHBoYXNlOiBwa2ctZGVwZW5kcyAgICA+PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQ0KPiA9PT0+ICAgb3BlbmpkazE3LTE3LjAuMis4LjEgZGVwZW5kcyBvbiBmaWxl
OiAvdXNyL2xvY2FsL3NiaW4vcGtnIC0gbm90IGZvdW5kDQo+ID09PT4gICBJbnN0YWxsaW5n
IGV4aXN0aW5nIHBhY2thZ2UgL3BhY2thZ2VzL0FsbC9wa2ctMS4xNy41XzEucGtnDQo+IFsx
MzBhcm02NC1kZWZhdWx0LWpvYi0xMV0gSW5zdGFsbGluZyBwa2ctMS4xNy41XzEuLi4NCj4g
WzEzMGFybTY0LWRlZmF1bHQtam9iLTExXSBFeHRyYWN0aW5nIHBrZy0xLjE3LjVfMTogLi4u
Li4uLi4uLiBkb25lDQo+ID09PT4gICBvcGVuamRrMTctMTcuMC4yKzguMSBkZXBlbmRzIG9u
IGZpbGU6IC91c3IvbG9jYWwvc2Jpbi9wa2cgLSBmb3VuZA0KPiA9PT0+ICAgUmV0dXJuaW5n
IHRvIGJ1aWxkIG9mIG9wZW5qZGsxNy0xNy4wLjIrOC4xDQo+ID09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KPiA9PT09PT09PT09PT09PT09PT09PT09PTxwaGFzZTogZmV0Y2gtZGVwZW5kcyAg
Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
DQo+ID09PT09PT09PT09PT09PT09PT09PT09PHBoYXNlOiBmZXRjaCAgICAgICAgICA+PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA9PT0+ICBMaWNlbnNlIEdQTHYyIGFjY2Vw
dGVkIGJ5IHRoZSB1c2VyDQo+ID09PT4gRmV0Y2hpbmcgYWxsIGRpc3RmaWxlcyByZXF1aXJl
ZCBieSBvcGVuamRrMTctMTcuMC4yKzguMSBmb3IgYnVpbGRpbmcNCj4gPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09DQo+ID09PT09PT09PT09PT09PT09PT09PT09PHBoYXNlOiBjaGVja3N1bSAg
ICAgICA+PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA9PT0+ICBMaWNlbnNlIEdQ
THYyIGFjY2VwdGVkIGJ5IHRoZSB1c2VyDQo+ID09PT4gRmV0Y2hpbmcgYWxsIGRpc3RmaWxl
cyByZXF1aXJlZCBieSBvcGVuamRrMTctMTcuMC4yKzguMSBmb3IgYnVpbGRpbmcNCj4gPT4g
U0hBMjU2IENoZWNrc3VtIE9LIGZvciBiYXR0bGVibG93LWpkazE3dS1qZGstMTcuMC4yKzgt
MV9HSDAudGFyLmd6Lg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPT09PT09PT09PT09
PT09PT09PT09PT08cGhhc2U6IGV4dHJhY3QtZGVwZW5kcz49PT09PT09PT09PT09PT09PT09
PT09PT09PT09DQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA9PT09PT09PT09PT09PT09
PT09PT09PTxwaGFzZTogZXh0cmFjdCAgICAgICAgPj09PT09PT09PT09PT09PT09PT09PT09
PT09PT0NCj4gPT09PiAgTGljZW5zZSBHUEx2MiBhY2NlcHRlZCBieSB0aGUgdXNlcg0KPiA9
PT0+IEZldGNoaW5nIGFsbCBkaXN0ZmlsZXMgcmVxdWlyZWQgYnkgb3BlbmpkazE3LTE3LjAu
Mis4LjEgZm9yIGJ1aWxkaW5nDQo+ID09PT4gIEV4dHJhY3RpbmcgZm9yIG9wZW5qZGsxNy0x
Ny4wLjIrOC4xDQo+ID0+IFNIQTI1NiBDaGVja3N1bSBPSyBmb3IgYmF0dGxlYmxvdy1qZGsx
N3UtamRrLTE3LjAuMis4LTFfR0gwLnRhci5nei4NCj4gPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
DQo+ID09PT09PT09PT09PT09PT09PT09PT09PHBoYXNlOiBwYXRjaC1kZXBlbmRzICA+PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4g
PT09PT09PT09PT09PT09PT09PT09PT08cGhhc2U6IHBhdGNoICAgICAgICAgID49PT09PT09
PT09PT09PT09PT09PT09PT09PT09DQo+ID09PT4gIFBhdGNoaW5nIGZvciBvcGVuamRrMTct
MTcuMC4yKzguMQ0KPiA9PT0+ICBBcHBseWluZyBGcmVlQlNEIHBhdGNoZXMgZm9yIG9wZW5q
ZGsxNy0xNy4wLjIrOC4xIGZyb20gL3Vzci9wb3J0cy9qYXZhL29wZW5qZGsxNy9maWxlcw0K
PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPT09PT09PT09PT09PT09PT09PT09PT08cGhh
c2U6IGJ1aWxkLWRlcGVuZHMgID49PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID09
PT4gICBvcGVuamRrMTctMTcuMC4yKzguMSBkZXBlbmRzIG9uIGV4ZWN1dGFibGU6IHppcCAt
IG5vdCBmb3VuZA0KPiA9PT0+ICAgSW5zdGFsbGluZyBleGlzdGluZyBwYWNrYWdlIC9wYWNr
YWdlcy9BbGwvemlwLTMuMF8xLnBrZw0KPiBbMTMwYXJtNjQtZGVmYXVsdC1qb2ItMTFdIElu
c3RhbGxpbmcgemlwLTMuMF8xLi4uDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0gRXh0
cmFjdGluZyB6aXAtMy4wXzE6IC4uLi4uLi4uLi4gZG9uZQ0KPiA9PT0+ICAgb3BlbmpkazE3
LTE3LjAuMis4LjEgZGVwZW5kcyBvbiBleGVjdXRhYmxlOiB6aXAgLSBmb3VuZA0KPiA9PT0+
ICAgUmV0dXJuaW5nIHRvIGJ1aWxkIG9mIG9wZW5qZGsxNy0xNy4wLjIrOC4xDQo+ID09PT4g
ICBvcGVuamRrMTctMTcuMC4yKzguMSBkZXBlbmRzIG9uIHBhY2thZ2U6IGF1dG9jb25mPjAg
LSBub3QgZm91bmQNCj4gPT09PiAgIEluc3RhbGxpbmcgZXhpc3RpbmcgcGFja2FnZSAvcGFj
a2FnZXMvQWxsL2F1dG9jb25mLTIuNjlfMy5wa2cNCj4gWzEzMGFybTY0LWRlZmF1bHQtam9i
LTExXSBJbnN0YWxsaW5nIGF1dG9jb25mLTIuNjlfMy4uLg0KPiBbMTMwYXJtNjQtZGVmYXVs
dC1qb2ItMTFdIGAtLSBJbnN0YWxsaW5nIGF1dG9jb25mLXdyYXBwZXItMjAxMzEyMDMuLi4N
Cj4gWzEzMGFybTY0LWRlZmF1bHQtam9iLTExXSBgLS0gRXh0cmFjdGluZyBhdXRvY29uZi13
cmFwcGVyLTIwMTMxMjAzOiAuLi4uLi4uLi4uIGRvbmUNCj4gWzEzMGFybTY0LWRlZmF1bHQt
am9iLTExXSBgLS0gSW5zdGFsbGluZyBpbmRleGluZm8tMC4zLjEuLi4NCj4gWzEzMGFybTY0
LWRlZmF1bHQtam9iLTExXSBgLS0gRXh0cmFjdGluZyBpbmRleGluZm8tMC4zLjE6IC4uLi4g
ZG9uZQ0KPiBbMTMwYXJtNjQtZGVmYXVsdC1qb2ItMTFdIGAtLSBJbnN0YWxsaW5nIG00LTEu
NC4xOSwxLi4uDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0gfCAgIGAtLSBJbnN0YWxs
aW5nIGdldHRleHQtcnVudGltZS0wLjIxLi4uDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0x
MV0gfCAgIGAtLSBFeHRyYWN0aW5nIGdldHRleHQtcnVudGltZS0wLjIxOiAuLi4uLi4uLi4u
IGRvbmUNCj4gWzEzMGFybTY0LWRlZmF1bHQtam9iLTExXSBgLS0gRXh0cmFjdGluZyBtNC0x
LjQuMTksMTogLi4uLi4uLi4uLiBkb25lDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0g
YC0tIEluc3RhbGxpbmcgcGVybDUtNS4zMi4xXzEuLi4NCj4gWzEzMGFybTY0LWRlZmF1bHQt
am9iLTExXSBgLS0gRXh0cmFjdGluZyBwZXJsNS01LjMyLjFfMTogLi4uLi4uLi4uLiBkb25l
DQo+IDxzbmlwPg0KPiANCj4gLS0NCj4gVGhlIDIuNy54IHNlcmllcyBub3cgdXNlcyB0aGUg
bmV3IHN1YnBpeGVsIGhpbnRpbmcgbW9kZSAoVjQwIHBvcnQncyBvcHRpb24pIGFzDQo+IHRo
ZSBkZWZhdWx0LCBlbXVsYXRpbmcgYSBtb2Rlcm4gdmVyc2lvbiBvZiBDbGVhclR5cGUuIFRo
aXMgY2hhbmdlIGluZXZpdGFibHkNCj4gbGVhZHMgdG8gZGlmZmVyZW50IHJlbmRlcmluZyBy
ZXN1bHRzLCBhbmQgeW91IG1pZ2h0IGNoYW5nZSBwb3J0J3Mgb3B0aW9ucyB0bw0KPiBhZGFw
dCBpdCB0byB5b3VyIHRhc3RlIChvciB1c2UgdGhlIG5ldyAiRlJFRVRZUEVfUFJPUEVSVElF
UyIgZW52aXJvbm1lbnQNCj4gdmFyaWFibGUpLg0KPiANCj4gVGhlIGVudmlyb25tZW50IHZh
cmlhYmxlICJGUkVFVFlQRV9QUk9QRVJUSUVTIiBjYW4gYmUgdXNlZCB0byBjb250cm9sIHRo
ZQ0KPiBkcml2ZXIgcHJvcGVydGllcy4gRXhhbXBsZToNCj4gDQo+IEZSRUVUWVBFX1BST1BF
UlRJRVM9dHJ1ZXR5cGU6aW50ZXJwcmV0ZXItdmVyc2lvbj0zNSBcDQo+IAljZmY6bm8tc3Rl
bS1kYXJrZW5pbmc9MSBcDQo+IAlhdXRvZml0dGVyOndhcnBpbmc9MQ0KPiANCj4gVGhpcyBh
bGxvd3MgdG8gc2VsZWN0LCBzYXksIHRoZSBzdWJwaXhlbCBoaW50aW5nIG1vZGUgYXQgcnVu
dGltZSBmb3IgYSBnaXZlbg0KPiBhcHBsaWNhdGlvbi4NCj4gDQo+IElmIExPTkdfUENGX05B
TUVTIHBvcnQncyBvcHRpb24gd2FzIGVuYWJsZWQsIHRoZSBQQ0YgZmFtaWx5IG5hbWVzIG1h
eSBpbmNsdWRlDQo+IHRoZSBmb3VuZHJ5IGFuZCBpbmZvcm1hdGlvbiB3aGV0aGVyIHRoZXkg
Y29udGFpbiB3aWRlIGNoYXJhY3RlcnMuIEZvciBleGFtcGxlLA0KPiAiU29ueSBGaXhlZCIg
b3IgIk1pc2MgRml4ZWQgV2lkZSIsIGluc3RlYWQgb2YgIkZpeGVkIi4gVGhpcyBjYW4gYmUg
ZGlzYWJsZWQgYXQNCj4gcnVuIHRpbWUgd2l0aCB1c2luZyBwY2Y6bm8tbG9uZy1mYW1pbHkt
bmFtZXMgcHJvcGVydHksIGlmIG5lZWRlZC4gRXhhbXBsZToNCj4gDQo+IEZSRUVUWVBFX1BS
T1BFUlRJRVM9cGNmOm5vLWxvbmctZmFtaWx5LW5hbWVzPTENCj4gDQo+IEhvdyB0byByZWNy
ZWF0ZSBmb250Y29uZmlnIGNhY2hlIHdpdGggdXNpbmcgc3VjaCBlbnZpcm9ubWVudCB2YXJp
YWJsZSwNCj4gaWYgbmVlZGVkOg0KPiAjIGVudiBGUkVFVFlQRV9QUk9QRVJUSUVTPXBjZjpu
by1sb25nLWZhbWlseS1uYW1lcz0xIGZjLWNhY2hlIC1mc3YNCj4gDQo+IFRoZSBjb250cm9s
bGFibGUgcHJvcGVydGllcyBhcmUgbGlzdGVkIGluIHRoZSBzZWN0aW9uICJDb250cm9sbGlu
ZyBGcmVlVHlwZQ0KPiBNb2R1bGVzIiBpbiB0aGUgcmVmZXJlbmNlJ3MgdGFibGUgb2YgY29u
dGVudHMNCj4gKC91c3IvbG9jYWwvc2hhcmUvZG9jL2ZyZWV0eXBlMi9yZWZlcmVuY2UvaW5k
ZXguaHRtbCwgaWYgZG9jdW1lbnRhdGlvbiB3YXMgaW5zdGFsbGVkKS4NCj4gPT09PiAgIG9w
ZW5qZGsxNy0xNy4wLjIrOC4xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmZvbnRj
b25maWcuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliZm9udGNvbmZpZy5zbykNCj4g
PT09PiAgIFJldHVybmluZyB0byBidWlsZCBvZiBvcGVuamRrMTctMTcuMC4yKzguMQ0KPiA9
PT0+ICAgb3BlbmpkazE3LTE3LjAuMis4LjEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTog
bGliZnJlZXR5cGUuc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliZnJlZXR5cGUuc28p
DQo+ID09PT4gICBvcGVuamRrMTctMTcuMC4yKzguMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJy
YXJ5OiBsaWJnaWYuc28gLSBub3QgZm91bmQNCj4gPT09PiAgIEluc3RhbGxpbmcgZXhpc3Rp
bmcgcGFja2FnZSAvcGFja2FnZXMvQWxsL2dpZmxpYi01LjIuMS5wa2cNCj4gWzEzMGFybTY0
LWRlZmF1bHQtam9iLTExXSBJbnN0YWxsaW5nIGdpZmxpYi01LjIuMS4uLg0KPiBbMTMwYXJt
NjQtZGVmYXVsdC1qb2ItMTFdIEV4dHJhY3RpbmcgZ2lmbGliLTUuMi4xOiAuLi4uLi4uLi4u
IGRvbmUNCj4gPT09PiAgIG9wZW5qZGsxNy0xNy4wLjIrOC4xIGRlcGVuZHMgb24gc2hhcmVk
IGxpYnJhcnk6IGxpYmdpZi5zbyAtIGZvdW5kICgvdXNyL2xvY2FsL2xpYi9saWJnaWYuc28p
DQo+ID09PT4gICBSZXR1cm5pbmcgdG8gYnVpbGQgb2Ygb3BlbmpkazE3LTE3LjAuMis4LjEN
Cj4gPT09PiAgIG9wZW5qZGsxNy0xNy4wLjIrOC4xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJh
cnk6IGxpYmhhcmZidXp6LnNvIC0gbm90IGZvdW5kDQo+ID09PT4gICBJbnN0YWxsaW5nIGV4
aXN0aW5nIHBhY2thZ2UgL3BhY2thZ2VzL0FsbC9oYXJmYnV6ei00LjIuMS5wa2cNCj4gWzEz
MGFybTY0LWRlZmF1bHQtam9iLTExXSBJbnN0YWxsaW5nIGhhcmZidXp6LTQuMi4xLi4uDQo+
IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0gYC0tIEluc3RhbGxpbmcgZ3JhcGhpdGUyLTEu
My4xNC4uLg0KPiBbMTMwYXJtNjQtZGVmYXVsdC1qb2ItMTFdIGAtLSBFeHRyYWN0aW5nIGdy
YXBoaXRlMi0xLjMuMTQ6IC4uLi4uLi4uLi4gZG9uZQ0KPiBbMTMwYXJtNjQtZGVmYXVsdC1q
b2ItMTFdIEV4dHJhY3RpbmcgaGFyZmJ1enotNC4yLjE6IC4uLi4uLi4uLi4gZG9uZQ0KPiA9
PT0+ICAgb3BlbmpkazE3LTE3LjAuMis4LjEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTog
bGliaGFyZmJ1enouc28gLSBmb3VuZCAoL3Vzci9sb2NhbC9saWIvbGliaGFyZmJ1enouc28p
DQo+ID09PT4gICBSZXR1cm5pbmcgdG8gYnVpbGQgb2Ygb3BlbmpkazE3LTE3LjAuMis4LjEN
Cj4gPT09PiAgIG9wZW5qZGsxNy0xNy4wLjIrOC4xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJh
cnk6IGxpYmxjbXMyLnNvIC0gbm90IGZvdW5kDQo+ID09PT4gICBJbnN0YWxsaW5nIGV4aXN0
aW5nIHBhY2thZ2UgL3BhY2thZ2VzL0FsbC9sY21zMi0yLjEyLnBrZw0KPiBbMTMwYXJtNjQt
ZGVmYXVsdC1qb2ItMTFdIEluc3RhbGxpbmcgbGNtczItMi4xMi4uLg0KPiBbMTMwYXJtNjQt
ZGVmYXVsdC1qb2ItMTFdIGAtLSBJbnN0YWxsaW5nIGpwZWctdHVyYm8tMi4xLjMuLi4NCj4g
WzEzMGFybTY0LWRlZmF1bHQtam9iLTExXSBgLS0gRXh0cmFjdGluZyBqcGVnLXR1cmJvLTIu
MS4zOiAuLi4uLi4uLi4uIGRvbmUNCj4gWzEzMGFybTY0LWRlZmF1bHQtam9iLTExXSBgLS0g
SW5zdGFsbGluZyB0aWZmLTQuMy4wLi4uDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0g
fCAgIGAtLSBJbnN0YWxsaW5nIGpiaWdraXQtMi4xXzEuLi4NCj4gWzEzMGFybTY0LWRlZmF1
bHQtam9iLTExXSB8ICAgYC0tIEV4dHJhY3RpbmcgamJpZ2tpdC0yLjFfMTogLi4uLi4uLi4u
LiBkb25lDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0gYC0tIEV4dHJhY3RpbmcgdGlm
Zi00LjMuMDogLi4uLi4uLi4uLiBkb25lDQo+IFsxMzBhcm02NC1kZWZhdWx0LWpvYi0xMV0g
RXh0cmFjdGluZyBsY21zMi0yLjEyOiAuLi4uLi4uLi4uIGRvbmUNCj4gPT09PiAgIG9wZW5q
ZGsxNy0xNy4wLjIrOC4xIGRlcGVuZHMgb24gc2hhcmVkIGxpYnJhcnk6IGxpYmxjbXMyLnNv
IC0gZm91bmQgKC91c3IvbG9jYWwvbGliL2xpYmxjbXMyLnNvKQ0KPiA9PT0+ICAgUmV0dXJu
aW5nIHRvIGJ1aWxkIG9mIG9wZW5qZGsxNy0xNy4wLjIrOC4xDQo+ID09PT4gICBvcGVuamRr
MTctMTcuMC4yKzguMSBkZXBlbmRzIG9uIHNoYXJlZCBsaWJyYXJ5OiBsaWJwbmcuc28gLSBm
b3VuZCAoL3Vzci9sb2NhbC9saWIvbGlicG5nLnNvKQ0KPiA9PT0+ICAgb3BlbmpkazE3LTE3
LjAuMis4LjEgZGVwZW5kcyBvbiBzaGFyZWQgbGlicmFyeTogbGlianBlZy5zbyAtIGZvdW5k
ICgvdXNyL2xvY2FsL2xpYi9saWJqcGVnLnNvKQ0KPiA9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N
Cj4gPT09PT09PT09PT09PT09PT09PT09PT08cGhhc2U6IGNvbmZpZ3VyZSAgICAgID49PT09
PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID09PT4gIENvbmZpZ3VyaW5nIGZvciBvcGVu
amRrMTctMTcuMC4yKzguMQ0KPiBXYXJuaW5nOiBZb3UgYXJlIHVzaW5nIGxlZ2FjeSBhdXRv
Y29uZiBjcm9zcy1jb21waWxhdGlvbiBmbGFncy4NCj4gSXQgaXMgcmVjb21tZW5kZWQgdGhh
dCB5b3UgdXNlIC0tb3Blbmpkay10YXJnZXQgaW5zdGVhZC4NCj4gDQo+IGNvbmZpZ3VyZTog
bG9hZGluZyBzaXRlIHNjcmlwdCAvdXNyL3BvcnRzL1RlbXBsYXRlcy9jb25maWcuc2l0ZQ0K
PiBjb25maWd1cmU6IENvbmZpZ3VyYXRpb24gY3JlYXRlZCBhdCBTYXQgQXByIDMwIDExOjI5
OjQxIFVUQyAyMDIyLg0KPiBjaGVja2luZyBmb3IgYmFzZW5hbWUuLi4gL3Vzci9iaW4vYmFz
ZW5hbWUNCj4gY2hlY2tpbmcgZm9yIGRpcm5hbWUuLi4gL3Vzci9iaW4vZGlybmFtZQ0KPiBj
aGVja2luZyBmb3IgZmlsZS4uLiAvdXNyL2Jpbi9maWxlDQo+IGNoZWNraW5nIGZvciBsZGQu
Li4gL3Vzci9iaW4vbGRkDQo+IGNoZWNraW5nIGZvciBiYXNoLi4uIC91c3IvbG9jYWwvYmlu
L2Jhc2gNCj4gY2hlY2tpbmcgZm9yIGNhdC4uLiAvYmluL2NhdA0KPiBjaGVja2luZyBmb3Ig
Y2htb2QuLi4gL2Jpbi9jaG1vZA0KPiBjaGVja2luZyBmb3IgY3AuLi4gL2Jpbi9jcA0KPiBj
aGVja2luZyBmb3IgY3V0Li4uIC91c3IvYmluL2N1dA0KPiBjaGVja2luZyBmb3IgZGF0ZS4u
LiAvYmluL2RhdGUNCj4gY2hlY2tpbmcgZm9yIGdkaWZmLi4uIFtub3QgZm91bmRdDQo+IGNo
ZWNraW5nIGZvciBkaWZmLi4uIC91c3IvYmluL2RpZmYNCj4gY2hlY2tpbmcgZm9yIGVjaG8u
Li4gZWNobyBbYnVpbHRpbl0NCj4gY2hlY2tpbmcgZm9yIGV4cHIuLi4gL2Jpbi9leHByDQo+
IGNoZWNraW5nIGZvciBmaW5kLi4uIC91c3IvYmluL2ZpbmQNCj4gY2hlY2tpbmcgZm9yIGd1
bnppcC4uLiAvdXNyL2Jpbi9ndW56aXANCj4gY2hlY2tpbmcgZm9yIHBpZ3ouLi4gW25vdCBm
b3VuZF0NCj4gY2hlY2tpbmcgZm9yIGd6aXAuLi4gL3Vzci9iaW4vZ3ppcA0KPiBjaGVja2lu
ZyBmb3IgaGVhZC4uLiAvdXNyL2Jpbi9oZWFkDQo+IGNoZWNraW5nIGZvciBsbi4uLiAvYmlu
L2xuDQo+IGNoZWNraW5nIGZvciBscy4uLiAvYmluL2xzDQo+IGNoZWNraW5nIGZvciBnbWtk
aXIuLi4gW25vdCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9yIG1rZGlyLi4uIC9iaW4vbWtkaXIN
Cj4gY2hlY2tpbmcgZm9yIG1rdGVtcC4uLiAvdXNyL2Jpbi9ta3RlbXANCj4gY2hlY2tpbmcg
Zm9yIG12Li4uIC9iaW4vbXYNCj4gY2hlY2tpbmcgZm9yIGdhd2suLi4gW25vdCBmb3VuZF0N
Cj4gY2hlY2tpbmcgZm9yIG5hd2suLi4gL3Vzci9iaW4vbmF3aw0KPiBjaGVja2luZyBmb3Ig
cHJpbnRmLi4uIHByaW50ZiBbYnVpbHRpbl0NCj4gY2hlY2tpbmcgZm9yIHJtLi4uIC9iaW4v
cm0NCj4gY2hlY2tpbmcgZm9yIHJtZGlyLi4uIC9iaW4vcm1kaXINCj4gY2hlY2tpbmcgZm9y
IHNoLi4uIC9iaW4vc2gNCj4gY2hlY2tpbmcgZm9yIHNvcnQuLi4gL3Vzci9iaW4vc29ydA0K
PiBjaGVja2luZyBmb3IgdGFpbC4uLiAvdXNyL2Jpbi90YWlsDQo+IGNoZWNraW5nIGZvciBn
dGFyLi4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciB0YXIuLi4gL3Vzci9iaW4vdGFy
DQo+IGNoZWNraW5nIGZvciB0ZWUuLi4gL3Vzci9iaW4vdGVlDQo+IGNoZWNraW5nIGZvciB0
b3VjaC4uLiAvdXNyL2Jpbi90b3VjaA0KPiBjaGVja2luZyBmb3IgdHIuLi4gL3Vzci9iaW4v
dHINCj4gY2hlY2tpbmcgZm9yIHVuYW1lLi4uIC91c3IvYmluL3VuYW1lDQo+IGNoZWNraW5n
IGZvciB3Yy4uLiAvdXNyL2Jpbi93Yw0KPiBjaGVja2luZyBmb3IgeGFyZ3MuLi4gL3Vzci9i
aW4veGFyZ3MNCj4gY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5kbGVzIGxvbmcgbGluZXMg
YW5kIC1lLi4uIChjYWNoZWQpIC91c3IvYmluL2dyZXANCj4gY2hlY2tpbmcgZm9yIGVncmVw
Li4uIChjYWNoZWQpIC91c3IvYmluL2VncmVwDQo+IGNoZWNraW5nIGZvciBmZ3JlcC4uLiAo
Y2FjaGVkKSAvdXNyL2Jpbi9mZ3JlcA0KPiBjaGVja2luZyBmb3IgYSBzZWQgdGhhdCBkb2Vz
IG5vdCB0cnVuY2F0ZSBvdXRwdXQuLi4gKGNhY2hlZCkgL3Vzci9sb2NhbC9iaW4vZ3NlZA0K
PiBjaGVja2luZyBmb3IgZGYuLi4gL2Jpbi9kZg0KPiBjaGVja2luZyBmb3IgbmljZS4uLiAv
dXNyL2Jpbi9uaWNlDQo+IGNoZWNraW5nIGZvciBncmVhZGxpbmsuLi4gW25vdCBmb3VuZF0N
Cj4gY2hlY2tpbmcgZm9yIHJlYWRsaW5rLi4uIC91c3IvYmluL3JlYWRsaW5rDQo+IGNoZWNr
aW5nIGZvciBjeWdwYXRoLi4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciB3c2xwYXRo
Li4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciBsc2JfcmVsZWFzZS4uLiBbbm90IGZv
dW5kXQ0KPiBjaGVja2luZyBmb3IgY21kLmV4ZS4uLiBbbm90IGZvdW5kXQ0KPiBjaGVja2lu
ZyBmb3IgY21wLi4uIC91c3IvYmluL2NtcA0KPiBjaGVja2luZyBmb3IgdW5pcS4uLiAvdXNy
L2Jpbi91bmlxDQo+IGNoZWNraW5nIGJ1aWxkIHN5c3RlbSB0eXBlLi4uIGFhcmNoNjQtcG9y
dGJsZC1mcmVlYnNkMTMuMA0KPiBjaGVja2luZyBob3N0IHN5c3RlbSB0eXBlLi4uIGFhcmNo
NjQtcG9ydGJsZC1mcmVlYnNkMTMuMA0KPiBjaGVja2luZyB0YXJnZXQgc3lzdGVtIHR5cGUu
Li4gYWFyY2g2NC1wb3J0YmxkLWZyZWVic2QxMy4wDQo+IGNoZWNraW5nIG9wZW5qZGstYnVp
bGQgb3MtY3B1Li4uIGJzZC1hYXJjaDY0DQo+IGNoZWNraW5nIG9wZW5qZGstdGFyZ2V0IG9z
LWNwdS4uLiBic2QtYWFyY2g2NA0KPiBjaGVja2luZyBvcGVuamRrLXRhcmdldCBvcy1lbnYu
Li4gYnNkLmZyZWVic2QNCj4gY2hlY2tpbmcgY29tcGlsYXRpb24gdHlwZS4uLiBuYXRpdmUN
Cj4gY2hlY2tpbmcgZm9yIHRvcC1sZXZlbCBkaXJlY3RvcnkuLi4gL3dya2RpcnMvdXNyL3Bv
cnRzL2phdmEvb3BlbmpkazE3L3dvcmsvamRrMTd1LWpkay0xNy4wLjItOC0xDQo+IGNoZWNr
aW5nIGlmIGN1c3RvbSBzb3VyY2UgaXMgc3VwcHJlc3NlZCAob3Blbmpkay1vbmx5KS4uLiBk
aXNhYmxlZCwgZGVmYXVsdA0KPiBjaGVja2luZyBmb3IgLS1lbmFibGUtZGVidWcuLi4gZGlz
YWJsZWQsIGRlZmF1bHQNCj4gY2hlY2tpbmcgd2hpY2ggZGVidWcgbGV2ZWwgdG8gdXNlLi4u
IHJlbGVhc2UNCj4gY2hlY2tpbmcgd2hpY2ggdmFyaWFudHMgb2YgdGhlIEpWTSB0byBidWls
ZC4uLiBzZXJ2ZXINCj4gY2hlY2tpbmcgaWYgYWJzb2x1dGUgcGF0aHMgc2hvdWxkIGJlIGFs
bG93ZWQgaW4gdGhlIGJ1aWxkIG91dHB1dC4uLiBubywgcmVsZWFzZSBidWlsZA0KPiBjaGVj
a2luZyBmb3Igc3lzcm9vdC4uLg0KPiBjaGVja2luZyBmb3IgdG9vbGNoYWluIHBhdGguLi4N
Cj4gY2hlY2tpbmcgZm9yIGV4dHJhIHBhdGguLi4NCj4gY2hlY2tpbmcgd2hlcmUgdG8gc3Rv
cmUgY29uZmlndXJhdGlvbi4uLiBpbiBkZWZhdWx0IGxvY2F0aW9uDQo+IGNoZWNraW5nIHdo
YXQgY29uZmlndXJhdGlvbiBuYW1lIHRvIHVzZS4uLiBic2QtYWFyY2g2NC1zZXJ2ZXItcmVs
ZWFzZQ0KPiBjaGVja2luZyBmb3IgenlwcGVyLi4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5n
IGZvciBhcHQtZ2V0Li4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciB5dW0uLi4gW25v
dCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9yIGJyZXcuLi4gW25vdCBmb3VuZF0NCj4gY2hlY2tp
bmcgZm9yIHBvcnQuLi4gW25vdCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9yIHBrZ3V0aWwuLi4g
W25vdCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9yIHBrZ2FkZC4uLiBbbm90IGZvdW5kXQ0KPiBj
aGVja2luZyBmb3IgcGFjbWFuLi4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciBwYW5k
b2MuLi4gW25vdCBmb3VuZF0NCj4gY29uZmlndXJlOiBXQVJOSU5HOiBJZ25vcmluZyB2YWx1
ZSBvZiBNQUtFIGZyb20gdGhlIGVudmlyb25tZW50LiBVc2UgY29tbWFuZCBsaW5lIHZhcmlh
YmxlcyBpbnN0ZWFkLg0KPiBjaGVja2luZyBmb3IgZ21ha2UuLi4gL3Vzci9sb2NhbC9iaW4v
Z21ha2UNCj4gY29uZmlndXJlOiBUZXN0aW5nIHBvdGVudGlhbCBtYWtlIGF0IC91c3IvbG9j
YWwvYmluL2dtYWtlLCBmb3VuZCB1c2luZyBnbWFrZSBpbiBQQVRIDQo+IGNvbmZpZ3VyZTog
VGVzdGluZyBwb3RlbnRpYWwgbWFrZSBhdCBnbWFrZSwgZm91bmQgdXNpbmcgdXNlciBzdXBw
bGllZCBNQUtFPWdtYWtlDQo+IGNvbmZpZ3VyZTogVXNpbmcgR05VIG1ha2UgYXQgL3Vzci9s
b2NhbC9iaW4vZ21ha2UgKHZlcnNpb246IEdOVSBNYWtlIDQuMykNCj4gY2hlY2tpbmcgaWYg
bWFrZSAtLW91dHB1dC1zeW5jIGlzIHN1cHBvcnRlZC4uLiB5ZXMNCj4gY2hlY2tpbmcgZm9y
IG91dHB1dC1zeW5jIHZhbHVlLi4uIG5vbmUNCj4gY2hlY2tpbmcgaWYgZmluZCBzdXBwb3J0
cyAtZGVsZXRlLi4uIHllcw0KPiBjaGVja2luZyB3aGF0IHR5cGUgb2YgdGFyIHdhcyBmb3Vu
ZC4uLiBic2QNCj4gY2hlY2tpbmcgdGhhdCBncmVwICgvdXNyL2Jpbi9ncmVwKSAtRnggaGFu
ZGxlcyBlbXB0eSBsaW5lcyBpbiB0aGUgcGF0dGVybiBsaXN0IGNvcnJlY3RseS4uLiB5ZXMN
Cj4gY2hlY2tpbmcgZm9yIHVuemlwLi4uIC91c3IvYmluL3VuemlwDQo+IGNoZWNraW5nIGZv
ciB6aXAuLi4gL3Vzci9sb2NhbC9iaW4vemlwDQo+IGNoZWNraW5nIGZvciBncmVhZGVsZi4u
LiBbbm90IGZvdW5kXQ0KPiBjaGVja2luZyBmb3IgcmVhZGVsZi4uLiAvdXNyL2Jpbi9yZWFk
ZWxmDQo+IGNoZWNraW5nIGZvciBkb3QuLi4gW25vdCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9y
IGhnLi4uIFtub3QgZm91bmRdDQo+IGNoZWNraW5nIGZvciBnaXQuLi4gW25vdCBmb3VuZF0N
Cj4gY2hlY2tpbmcgZm9yIHN0YXQuLi4gL3Vzci9iaW4vc3RhdA0KPiBjaGVja2luZyBmb3Ig
dGltZS4uLiB0aW1lIFtidWlsdGluXQ0KPiBjaGVja2luZyBmb3IgZmxvY2suLi4gW25vdCBm
b3VuZF0NCj4gY2hlY2tpbmcgZm9yIGR0cmFjZS4uLiAvdXNyL3NiaW4vZHRyYWNlDQo+IGNo
ZWNraW5nIGZvciBncGF0Y2guLi4gW25vdCBmb3VuZF0NCj4gY2hlY2tpbmcgZm9yIHBhdGNo
Li4uIC91c3IvYmluL3BhdGNoDQo+IGNoZWNraW5nIGZvciB1bGltaXQuLi4gdWxpbWl0IFti
dWlsdGluXQ0KPiBjaGVja2luZyBiYXNoIHZlcnNpb24uLi4gNS4xLjE2DQo+IGNoZWNraW5n
IGlmIGJhc2ggc3VwcG9ydHMgcGlwZWZhaWwuLi4geWVzDQo+IGNoZWNraW5nIGlmIGJhc2gg
c3VwcG9ydHMgZXJyZXhpdCAoLWUpLi4uIHllcw0KPiBjaGVja2luZyBwa2ctY29uZmlnIGlz
IGF0IGxlYXN0IHZlcnNpb24gMC45LjAuLi4geWVzDQo+IGNoZWNraW5nIGZvciBkZWZhdWx0
IExPRyB2YWx1ZS4uLg0KPiBjaGVja2luZyBpZiBwYWNrYWdlZCBtb2R1bGVzIGFyZSBrZXB0
Li4uIGVuYWJsZWQsIGRlZmF1bHQNCj4gY2hlY2tpbmcgZm9yIHZlcnNpb24gc3RyaW5nLi4u
IDE3LjAuMis4LTENCj4gY29uZmlndXJlOiBGb3VuZCBwb3RlbnRpYWwgQm9vdCBKREsgdXNp
bmcgY29uZmlndXJlIGFyZ3VtZW50cw0KPiBjb25maWd1cmU6IFBvdGVudGlhbCBCb290IEpE
SyBmb3VuZCBhdCAvdXNyL2xvY2FsL2Jvb3RzdHJhcC1vcGVuamRrMTcgaXMgbm90IGEgd29y
a2luZyBKREs7IGlnbm9yaW5nDQo+IGNvbmZpZ3VyZTogT3V0cHV0IGZyb20gamF2YSAtdmVy
c2lvbiB3YXM6IEVycm9yIG9jY3VycmVkIGR1cmluZyBpbml0aWFsaXphdGlvbiBvZiBWTQ0K
PiBDb3VsZCBub3QgYWxsb2NhdGUgY29tcHJlc3NlZCBjbGFzcyBzcGFjZTogMTA3Mzc0MTgy
NCBieXRlcw0KPiBjb25maWd1cmU6IGVycm9yOiBUaGUgcGF0aCBnaXZlbiBieSAtLXdpdGgt
Ym9vdC1qZGsgZG9lcyBub3QgY29udGFpbiBhIHZhbGlkIEJvb3QgSkRLDQo+IGNvbmZpZ3Vy
ZSBleGl0aW5nIHdpdGggcmVzdWx0IGNvZGUgMQ0KPiA9PT0+ICBTY3JpcHQgImNvbmZpZ3Vy
ZSIgZmFpbGVkIHVuZXhwZWN0ZWRseS4NCj4gUGxlYXNlIHJlcG9ydCB0aGUgcHJvYmxlbSB0
byBqYXZhQEZyZWVCU0Qub3JnIFttYWludGFpbmVyXSBhbmQgYXR0YWNoIHRoZQ0KPiAiL3dy
a2RpcnMvdXNyL3BvcnRzL2phdmEvb3BlbmpkazE3L3dvcmsvamRrMTd1LWpkay0xNy4wLjIt
OC0xL2NvbmZpZy5sb2ciDQo+IGluY2x1ZGluZyB0aGUgb3V0cHV0IG9mIHRoZSBmYWlsdXJl
IG9mIHlvdXIgbWFrZSBjb21tYW5kLiBBbHNvLCBpdCBtaWdodCBiZQ0KPiBhIGdvb2QgaWRl
YSB0byBwcm92aWRlIGFuIG92ZXJ2aWV3IG9mIGFsbCBwYWNrYWdlcyBpbnN0YWxsZWQgb24g
eW91ciBzeXN0ZW0NCj4gKGUuZy4gYSAvdXNyL2xvY2FsL3NiaW4vcGtnLXN0YXRpYyBpbmZv
IC1nIC1FYSkuDQo+ICoqKiBFcnJvciBjb2RlIDENCj4gDQo+IFN0b3AuDQo+IG1ha2U6IHN0
b3BwZWQgaW4gL3Vzci9wb3J0cy9qYXZhL29wZW5qZGsxNw0KPiANCg0K

From nobody Sun May  1 01:11:25 2022
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 1DBC81AB8F7D;
	Sun,  1 May 2022 01:11:29 +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 4KrSq41Rcyz3J3L;
	Sun,  1 May 2022 01:11:28 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2411BQDA010919
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 30 Apr 2022 18:11:26 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2411BQap010918;
	Sat, 30 Apr 2022 18:11:26 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 30 Apr 2022 18:11:25 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org,
        bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220501011125.GC10723@www.zefox.net>
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
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: 4KrSq41Rcyz3J3L
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [1.03 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.92)[-0.917];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_MEDIUM(0.59)[0.587];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.54)[-0.537];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4483
Lines: 111

On Fri, Apr 29, 2022 at 08:14:27PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 19:12, bob prohaska  wrote:
> 
> > Since about December of 2021 I've been noticing problems with
> > wired network connectivity on a pair of raspberry pi 3 machines
> > using wired network connections. One runs stable-13.1, the other
> > runs -current, both are up to date as of a few days ago.
> 
> Compared to your later notes about 192.168.1.n style use,
> are any of the above that way? Or are the all well-analogous
> to the "on the public network" context mentioned later?
> 
Not sure I follow what you're getting at, could you clarify
please? The move between public and private networks was done
by changing comment delimiters in /etc/rc.conf and moving
cables between public switch and private router. Only the two
Pi3s have so far failed to answer pings and ssh connections
after reboot. 

> > Essentially both machines fail to respond to inbound network
> > connections via ssh or ping after reboot. If I get on the 
> > serial console and start an outbound ping to anywhere, both
> > machines respond to incoming pings with about a 65% packet
> > loss. Ssh connections are answered with delays of zero to
> > perhaps thirty seconds. Once connected ssh is usable but
> > erratic, with dropped characters, multi-second delays and
> > disconnects after random intervals from minutes to hours.
> > 
> > There are five other Raspberry Pi's on the network. Three
> > Pi2's run 12.3-stable, one Pi2 runs -current
> 
> RPi2 v1.2's used as aarch64? (So similar to RPi3*'s.)
No, the Pi2s are v1.1.
> RPi2 v1.1's (armv7)?
Yes.
> Which type of RPi3* variant? B? B+? Revision?
>
The stable/13 machine reports:
bob@pelorus:~ % sysctl -a | grep model
hw.model: ARM Cortex-A53 r0p4
hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837
hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2
dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3
bob@pelorus:~ % 

and the -current machine reports: 
bob@www:~ % sysctl -a | grep -i model
      Memory Model Features 0 = 
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
hw.model: ARM Cortex-A53 r0p4
hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837
hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2
dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3
bob@www:~ % 

That's slightly surprising, since they are of different age and
one has WiFi, not sure which. I believe that makes one a B+ though
I gather FreeBSD still doesn't support the on-board WiFi. Either
way, I thought the wired ethernet setup was identical. 
 
> > and a Pi4 runs
> > -current. All have no problems pinging one another and out
> > of network, so there's nothing obviously wrong with the net.
> > The network is not routed, but rather a block of eight
> > addresses simply bridged from my ISP over DSL.
> > 
> > It's been found that an image of 13.1-RC4 behaves similarly
> > on one Pi3 when on the public network but exhibits more normal
> > ping response when moved to a 192.168.1.n private network. 

Just to be clear, it was the same Pi3, I  moved the cables and 
changed lines in /etc/rc.conf to make the switch.

> > On the face of it, this seems significant, but I can't guess how.
> 
> Did you try a RPi4B on the public network, booted using the
> same 13.1-RC4 microsd card you used in the RPi3* testing?
> (Modern aarch64 RPi* images should boot either type of
> aarch64 RPI*.)
>

> If yes, what was the behavior like? Did it behave like the
> RPi3*?
> 
> If no, it should be a good test for how specific the problem
> is to the RPi3* vs. RPi*'s more generally.
> 

I haven't tried yet, since the Pi4 was on the private network to
begin with and it has never had problems answering ping and ssh.
AIUI the Pi4 ethernet is on PCIe, while the Pi3 uses USB. If the
Pi4 failed to answer ping when running the snapshot I guess that
would point to either faulty media or a different place in the
network software. Perhaps worth a try. 



> Testing a EtherNet dongle known to use a different driver
> could also be a form of cross check, if you happen to have
> such available.

My only alternative Ethernet adapter is a Ralink WiFi dongle.
My WiFi is private-network only, and the snapshot worked reasonably
well when wired on the private network. A wired adapter would be
more informative, but I'll have to figure out what to order. 

Thanks for writing!

bob prohaska


From nobody Sun May  1 03:13:43 2022
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 1DED7199FCB0
	for ; Sun,  1 May 2022 03:14:02 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
	(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 "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KrWXS4wByz3mLJ
	for ; Sun,  1 May 2022 03:14:00 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Date: Sun, 01 May 2022 03:13:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail2; t=1651374832;
	bh=aN/SSiT1xFY6R7ITx93M+kPsFOUaDUoE0CsG75wMaFU=;
	h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc:
	 Date:Subject:Reply-To:Feedback-ID:Message-ID;
	b=Y+4R6uvMpL2PnCevjGONyuWBbR571FtRIeSHWuc3JODZ6imnxkC2uCW5QtJER4A9w
	 SFHfiAaIyDs8XQY7EiHkaP1CDL1Pl54bhX30oLEhOLnK8l6qJxlhlMdvYjEJI8fvQM
	 WG6tgrxF4qF+Mp25UU80qGg6gFlsfTHL0VbKGkpRqxbbaFNv98XCzOq/Yf2ZiD7qIe
	 frF0lmw+d6ZBBjsY3eX2VsCo0QO/5k0rbcw7W+kTJYhJfIvf+DHyy6L5Ee37vuSqmm
	 SqI9lMPsw/WTTB8wTwEMAuYisoJe5SvefFMRsRWbHV4rKT0rGad+vhf8SIjY/gb0Yo
	 1jJocIvs9RrMg==
To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" 
From: qroxana 
Reply-To: qroxana 
Subject: Kernel panic on armv7 when PF is enabled
Message-ID: 
Feedback-ID: 29996633:user:proton
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="b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y"
X-Rspamd-Queue-Id: 4KrWXS4wByz3mLJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=Y+4R6uvM;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=qroxana@protonmail.com
X-Spamd-Result: default: False [-0.15 / 15.00];
	 HAS_REPLYTO(0.00)[qroxana@protonmail.com];
	 FREEMAIL_FROM(0.00)[protonmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 DKIM_TRACE(0.00)[protonmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[protonmail.com];
	 ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.23)[-0.230];
	 R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.98)[0.984];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 FREEMAIL_REPLYTO(0.00)[protonmail.com];
	 HAS_PHPMAILER_SIG(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 36637
Lines: 487

This is a multi-part message in MIME format.

--b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

QWZ0ZXIgZ2l0IGJpc2VjdGluZyB0aGUgcGFuaWMgc3RhcnRlZCBzaW5jZSB0aGlzIGNvbW1pdC4K
CmNvbW1pdCA3OGJjM2Q1ZTE3MTJiYzE2NDlhYTU1NzRkMmI4ZDE1M2Y5NjY1MTEzCgpBdXRob3I6
IEtyaXN0b2YgUHJvdm9zdCA8CmtwQEZyZWVCU0Qub3JnCj4KCkRhdGU6ICAgTW9uIEZlYiAxNCAy
MDowOTo1NCAyMDIyICswMTAwCgp2bGFuOiBhbGxvdyBuZXQubGluay52bGFuLm10YWdfcGNwIHRv
IGJlIHNldCBwZXIgdm5ldAoKVGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNoYW5nZSBpcyB0
byBmYWNpbGl0YXRlIHRlc3RpbmcuCgpNRkMgYWZ0ZXI6ICAgICAgMSB3ZWVrCgpzeXMvbmV0L2lm
X2V0aGVyc3Vici5jIHwgOSArKysrKy0tLS0KCnN5cy9uZXQvaWZfdmxhbi5jICAgICAgfCA1ICsr
Ky0tCgoyIGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKClRo
ZSBhcm12NyBib2FyZCBib290cyBmcm9tIGEgTkZTIHJvb3QsCgppdCBjYW4gYm9vdCB3aXRob3V0
IGFueSBwcm9ibGVtIGlmIFBGIGlzIGRpc2FibGVkLgoKQW55IGhlbHBzPwoKYWRkIGhvc3QgOjox
OiBnYXRld2F5IGxvMCBmaWIgMDogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQphZGQgbmV0IGZlODA6
OjogZ2F0ZXdheSA6OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjpmZmZm
OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQpFbmFi
bGluZyBwZi4KS2VybmVsIHBhZ2UgZmF1bHQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFi
bGUgbG9ja3MgaGVsZDoKc2hhcmVkIHJtIHBmIHJ1bGVzZXRzIChwZiBydWxlc2V0cykgciA9IDAg
KDB4ZTMwOTk0MzApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9uZXRwZmlsL3BmL3BmLmM6NjQ5Mwpl
eGNsdXNpdmUgcncgdGNwaW5wICh0Y3BpbnApIHIgPSAwICgweGRiNzQ4ZDg4KSBsb2NrZWQgQCAv
dXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6MTAwOApzdGFjayBiYWNrdHJhY2U6CiMw
IDB4YzAzNTVjYWMgYXQgd2l0bmVzc19kZWJ1Z2dlcisweDdjCiMxIDB4YzAzNTZlZjAgYXQgd2l0
bmVzc193YXJuKzB4M2ZjCiMyIDB4YzA1ZWMwNDggYXQgYWJvcnRfaGFuZGxlcisweDFkOAojMyAw
eGMwNWNiNWFjIGF0IGV4Y2VwdGlvbl9leGl0KzAKIzQgMHhlMzA4M2MxMCBhdCBwZl9zeW5jb29r
aWVfdmFsaWRhdGUrMHg2MAojNSAweGUzMDQ5NmE4IGF0IHBmX3Rlc3QrMHg1MTgKIzYgMHhlMzA2
ZDc2OCBhdCBwZl9jaGVja19vdXQrMHgzMAojNyAweGMwNDE1YjQ0IGF0IHBmaWxfcnVuX2hvb2tz
KzB4YmMKIzggMHhjMDQ0NWNmYyBhdCBpcF9vdXRwdXQrMHhjZTgKIzkgMHhjMDQ1YmM5YyBhdCB0
Y3BfZGVmYXVsdF9vdXRwdXQrMHgyMGFjCiMxMCAweGMwNDcxZWI0IGF0IHRjcF91c3Jfc2VuZCsw
eDFhYwojMTEgMHhjMDM4OTQ2NCBhdCBzb3NlbmRfZ2VuZXJpYysweDQ5MAojMTIgMHhjMDM4OTc5
MCBhdCBzb3NlbmQrMHg2NAojMTMgMHhjMDUwMjg4OCBhdCBjbG50X3ZjX2NhbGwrMHg1NjAKIzE0
IDB4YzA1MDA5ZDggYXQgY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MAojMTUgMHhjMDFlN2IxNCBh
dCBuZXduZnNfcmVxdWVzdCsweGIyMAojMTYgMHhjMDIzMDIxOCBhdCBuZnNjbF9yZXF1ZXN0KzB4
NjAKIzE3IDB4YzAyMGQ5YmMgYXQgbmZzcnBjX2dldGF0dHIrMHhiMApGYXRhbCBrZXJuZWwgbW9k
ZSBkYXRhIGFib3J0OiAnQWxpZ25tZW50IEZhdWx0JyBvbiByZWFkCnRyYXBmcmFtZTogMHhkZjFm
MWM5MApGU1I9MDAwMDAwMDEsIEZBUj1kNzg0MDI2NCwgc3Bzcj00MDAwMDAxMwpyMCA9NmEyMjhl
ZGEsIHIxID1kYWMwZDc4NSwgcjIgPWQ3ODQwMjY0LCByMyA9ZGI1NTI3YzAKcjQgPWRmMWYxZTAw
LCByNSA9ZGFjMGQ3NWYsIHI2ID0wMDAwMDAxOCwgcjcgPWQ5NDIyYzAwCnI4ID1jMDkzZTVlNCwg
cjkgPTAwMDAwMDAxLCByMTA9ZGYxZjFmNWMsIHIxMT1kZjFmMWQzOApyMTI9ZTMwOThkZDAsIHNz
cD1kZjFmMWQyMCwgc2xyPWUzMDgzYmRjLCBwYyA9ZTMwODNjMTAKCnBhbmljOiBGYXRhbCBhYm9y
dApjcHVpZCA9IDEKdGltZSA9IDE2NTEzNjYwODkKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3Ry
YWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxmCiAgICAgICAgIHBjID0gMHhjMDVjOGMwMCAgbHIg
PSAweGMwMDdhYzhjIChkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgzMCkKICAgICAgICAgc3AgPSAw
eGRmMWYxYTY4ICBmcCA9IDB4ZGYxZjFiODAKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJf
dHJhY2Vfc2VsZl93cmFwcGVyKzB4MzAKICAgICAgICAgcGMgPSAweGMwMDdhYzhjICBsciA9IDB4
YzAyZTI4OWMgKHZwYW5pYysweDE3MCkKICAgICAgICAgc3AgPSAweGRmMWYxYjg4ICBmcCA9IDB4
ZGYxZjFiYTgKICAgICAgICAgcjQgPSAweDAwMDAwMTAwICByNSA9IDB4MDAwMDAwMDAKICAgICAg
ICAgcjYgPSAweGMwNzgwNTI5ICByNyA9IDB4YzA5MGVhMTAKdnBhbmljKCkgYXQgdnBhbmljKzB4
MTcwCiAgICAgICAgIHBjID0gMHhjMDJlMjg5YyAgbHIgPSAweGMwMmUyNjRjIChkb2FkdW1wKQog
ICAgICAgICBzcCA9IDB4ZGYxZjFiYjAgIGZwID0gMHhkZjFmMWJiNAogICAgICAgICByNCA9IDB4
ZGYxZjFjOTAgIHI1ID0gMHgwMDAwMDAxMwogICAgICAgICByNiA9IDB4ZDc4NDAyNjQgIHI3ID0g
MHgwMDAwMDAwMQogICAgICAgICByOCA9IDB4MDAwMDAwMDEgIHI5ID0gMHhkYjU1MjdjMAogICAg
ICAgIHIxMCA9IDB4ZDc4NDAyNjQKZG9hZHVtcCgpIGF0IGRvYWR1bXAKICAgICAgICAgcGMgPSAw
eGMwMmUyNjRjICBsciA9IDB4YzA1ZWM2OTggKGFib3J0X2FsaWduKQogICAgICAgICBzcCA9IDB4
ZGYxZjFiYmMgIGZwID0gMHhkZjFmMWJlOAogICAgICAgICByNCA9IDB4ZDc4NDAyNjQgIHI1ID0g
MHhkZjFmMWJiNAogICAgICAgICByNiA9IDB4YzAyZTI2NGMgcjEwID0gMHhkZjFmMWJiYwphYm9y
dF9hbGlnbigpIGF0IGFib3J0X2FsaWduCiAgICAgICAgIHBjID0gMHhjMDVlYzY5OCAgbHIgPSAw
eGMwNWVjMTk4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQogICAgICAgICBzcCA9IDB4ZGYxZjFiZjAg
IGZwID0gMHhkZjFmMWM4OAogICAgICAgICByNCA9IDB4MDAwMDAwMTMgIHI1ID0gMHhkNzg0MDI2
NAphYm9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxlcisweDMyOAogICAgICAgICBwYyA9IDB4
YzA1ZWMxOTggIGxyID0gMHhjMDVjYjVhYyAoZXhjZXB0aW9uX2V4aXQpCiAgICAgICAgIHNwID0g
MHhkZjFmMWM5MCAgZnAgPSAweGRmMWYxZDM4CiAgICAgICAgIHI0ID0gMHhkZjFmMWUwMCAgcjUg
PSAweGRhYzBkNzVmCiAgICAgICAgIHI2ID0gMHgwMDAwMDAxOCAgcjcgPSAweGQ5NDIyYzAwCiAg
ICAgICAgIHI4ID0gMHhjMDkzZTVlNCAgcjkgPSAweDAwMDAwMDAxCiAgICAgICAgcjEwID0gMHhk
ZjFmMWY1YwpleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2VwdGlvbl9leGl0CiAgICAgICAgIHBjID0g
MHhjMDVjYjVhYyAgbHIgPSAweGUzMDgzYmRjIChwZl9zeW5jb29raWVfdmFsaWRhdGUrMHgyYykK
ICAgICAgICAgc3AgPSAweGRmMWYxZDIwICBmcCA9IDB4ZGYxZjFkMzgKICAgICAgICAgcjAgPSAw
eDZhMjI4ZWRhICByMSA9IDB4ZGFjMGQ3ODUKICAgICAgICAgcjIgPSAweGQ3ODQwMjY0ICByMyA9
IDB4ZGI1NTI3YzAKICAgICAgICAgcjQgPSAweGRmMWYxZTAwICByNSA9IDB4ZGFjMGQ3NWYKICAg
ICAgICAgcjYgPSAweDAwMDAwMDE4ICByNyA9IDB4ZDk0MjJjMDAKICAgICAgICAgcjggPSAweGMw
OTNlNWU0ICByOSA9IDB4MDAwMDAwMDEKICAgICAgICByMTAgPSAweGRmMWYxZjVjIHIxMiA9IDB4
ZTMwOThkZDAKcGZfc3luY29va2llX3ZhbGlkYXRlKCkgYXQgcGZfc3luY29va2llX3ZhbGlkYXRl
KzB4NjAKICAgICAgICAgcGMgPSAweGUzMDgzYzEwICBsciA9IDB4ZTMwNDk2YTggKHBmX3Rlc3Qr
MHg1MTgpCiAgICAgICAgIHNwID0gMHhkZjFmMWQ0MCAgZnAgPSAweGRmMWYxZWE4CiAgICAgICAg
IHI0ID0gMHgwMDAyMDAwMCAgcjUgPSAweGRiNGE2MTAwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAx
OCAgcjcgPSAweGQ5NDIyYzAwCiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMiAgcjkgPSAweDAwMDAw
MDAxCnBmX3Rlc3QoKSBhdCBwZl90ZXN0KzB4NTE4CiAgICAgICAgIHBjID0gMHhlMzA0OTZhOCAg
bHIgPSAweGUzMDZkNzY4IChwZl9jaGVja19vdXQrMHgzMCkKICAgICAgICAgc3AgPSAweGRmMWYx
ZWIwICBmcCA9IDB4ZGYxZjFlYzAKICAgICAgICAgcjQgPSAweGRmMWYxZjVjICByNSA9IDB4ZTMw
NmQ3MzgKICAgICAgICAgcjYgPSAweGRiNmJhNjYwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAg
cjggPSAweGQ5NDIyYzAwICByOSA9IDB4ZGI3NDhkODAKICAgICAgICByMTAgPSAweGZmZjcwMDAw
CnBmX2NoZWNrX291dCgpIGF0IHBmX2NoZWNrX291dCsweDMwCiAgICAgICAgIHBjID0gMHhlMzA2
ZDc2OCAgbHIgPSAweGMwNDE1YjQ0IChwZmlsX3J1bl9ob29rcysweGJjKQogICAgICAgICBzcCA9
IDB4ZGYxZjFlYzggIGZwID0gMHhkZjFmMWVmMAogICAgICAgICByNCA9IDB4MDAwMjAwMDAgIHI1
ID0gMHhlMzA2ZDczOApwZmlsX3J1bl9ob29rcygpIGF0IHBmaWxfcnVuX2hvb2tzKzB4YmMKICAg
ICAgICAgcGMgPSAweGMwNDE1YjQ0ICBsciA9IDB4YzA0NDVjZmMgKGlwX291dHB1dCsweGNlOCkK
ICAgICAgICAgc3AgPSAweGRmMWYxZWY4ICBmcCA9IDB4ZGYxZjFmYTgKICAgICAgICAgcjQgPSAw
eDAwMDAwMTBhICByNSA9IDB4MDAwMDBhMGEKICAgICAgICAgcjYgPSAweGRiNGE2MTU4ICByNyA9
IDB4YzA5NDY5MDgKICAgICAgICAgcjggPSAweGRiNWJlYzAwICByOSA9IDB4ZDk0MjJjMDAKICAg
ICAgICByMTAgPSAweDAwMDAwNWRjCmlwX291dHB1dCgpIGF0IGlwX291dHB1dCsweGNlOAogICAg
ICAgICBwYyA9IDB4YzA0NDVjZmMgIGxyID0gMHhjMDQ1YmM5YyAodGNwX2RlZmF1bHRfb3V0cHV0
KzB4MjBhYykKICAgICAgICAgc3AgPSAweGRmMWYxZmIwICBmcCA9IDB4ZGYxZjIwZTAKICAgICAg
ICAgcjQgPSAweDAwMDAwMDAxICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweDAwMDAw
MDM0ICByNyA9IDB4ZGI3NDYwMDAKICAgICAgICAgcjggPSAweGRiNGE2MTZjICByOSA9IDB4ZGI0
YTYxMDAKICAgICAgICByMTAgPSAweGRiNzgyMDAwCnRjcF9kZWZhdWx0X291dHB1dCgpIGF0IHRj
cF9kZWZhdWx0X291dHB1dCsweDIwYWMKICAgICAgICAgcGMgPSAweGMwNDViYzljICBsciA9IDB4
YzA0NzFlYjQgKHRjcF91c3Jfc2VuZCsweDFhYykKICAgICAgICAgc3AgPSAweGRmMWYyMGU4ICBm
cCA9IDB4ZGYxZjIxNjAKICAgICAgICAgcjQgPSAweGMwYWY5NTVjICByNSA9IDB4ZGI3ODIwMDAK
ICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4ZGI3NDYwMDAKICAgICAgICAgcjggPSAw
eDAwMDAwMDAwICByOSA9IDB4ZGI3NDhkODAKICAgICAgICByMTAgPSAweDAwMDAwMDAwCnRjcF91
c3Jfc2VuZCgpIGF0IHRjcF91c3Jfc2VuZCsweDFhYwogICAgICAgICBwYyA9IDB4YzA0NzFlYjQg
IGxyID0gMHhjMDM4OTQ2NCAoc29zZW5kX2dlbmVyaWMrMHg0OTApCiAgICAgICAgIHNwID0gMHhk
ZjFmMjE2OCAgZnAgPSAweGRmMWYyMWQwCiAgICAgICAgIHI0ID0gMHhjMDQ3MWQwOCAgcjUgPSAw
eDAwMDQ0MDAwCiAgICAgICAgIHI2ID0gMHhkYjc0NjAwMCAgcjcgPSAweGRiNTUyN2MwCiAgICAg
ICAgIHI4ID0gMHgwMDAwMDAwMCAgcjkgPSAweGRiNzQ2MWI4CiAgICAgICAgcjEwID0gMHhkYjRi
MjkwMApzb3NlbmRfZ2VuZXJpYygpIGF0IHNvc2VuZF9nZW5lcmljKzB4NDkwCiAgICAgICAgIHBj
ID0gMHhjMDM4OTQ2NCAgbHIgPSAweGMwMzg5NzkwIChzb3NlbmQrMHg2NCkKICAgICAgICAgc3Ag
PSAweGRmMWYyMWQ4ICBmcCA9IDB4ZGYxZjIyMDAKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICBy
NSA9IDB4YzAzODhmZDQKICAgICAgICAgcjYgPSAweGRiNTUyN2MwICByNyA9IDB4MDAwMDAwMDAK
ICAgICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAxMDAKICAgICAgICByMTAgPSAw
eGM3MmZjNDkwCnNvc2VuZCgpIGF0IHNvc2VuZCsweDY0CiAgICAgICAgIHBjID0gMHhjMDM4OTc5
MCAgbHIgPSAweGMwNTAyODg4IChjbG50X3ZjX2NhbGwrMHg1NjApCiAgICAgICAgIHNwID0gMHhk
ZjFmMjIwOCAgZnAgPSAweGRmMWYyMmU4CiAgICAgICAgIHI0ID0gMHhjMDc2ZTEzMiAgcjUgPSAw
eGRmMWYyMmFjCiAgICAgICAgIHI2ID0gMHhjNzJmYzVhMCAgcjcgPSAweGMwNGZkMzQ4CiAgICAg
ICAgIHI4ID0gMHhjNzJmYzQ4MCByMTAgPSAweGM3MmZjNDkwCmNsbnRfdmNfY2FsbCgpIGF0IGNs
bnRfdmNfY2FsbCsweDU2MAogICAgICAgICBwYyA9IDB4YzA1MDI4ODggIGxyID0gMHhjMDUwMDlk
OCAoY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MCkKICAgICAgICAgc3AgPSAweGRmMWYyMmYwICBm
cCA9IDB4ZGYxZjIzNzgKICAgICAgICAgcjQgPSAweGMwNTAyMzI4ICByNSA9IDB4YzA3NjgxMzcK
ICAgICAgICAgcjYgPSAweGRiNjViYzQwICByNyA9IDB4YzcyZmM2MTAKICAgICAgICAgcjggPSAw
eGM3MmZjNjAwICByOSA9IDB4MDAwMDAwMDAKICAgICAgICByMTAgPSAweGRmMWYyNDM4CmNsbnRf
cmVjb25uZWN0X2NhbGwoKSBhdCBjbG50X3JlY29ubmVjdF9jYWxsKzB4MTcwCiAgICAgICAgIHBj
ID0gMHhjMDUwMDlkOCAgbHIgPSAweGMwMWU3YjE0IChuZXduZnNfcmVxdWVzdCsweGIyMCkKICAg
ICAgICAgc3AgPSAweGRmMWYyMzgwICBmcCA9IDB4ZGYxZjI0YTgKICAgICAgICAgcjQgPSAweDAw
MDAwMTJjICByNSA9IDB4YzA1MDA4NjgKICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4
MDAwMDAwMDAKICAgICAgICAgcjggPSAweGRmMWYyNTEwICByOSA9IDB4YzA3MjY3NjEKICAgICAg
ICByMTAgPSAweDAwMDAwMDAwCm5ld25mc19yZXF1ZXN0KCkgYXQgbmV3bmZzX3JlcXVlc3QrMHhi
MjAKICAgICAgICAgcGMgPSAweGMwMWU3YjE0ICBsciA9IDB4YzAyMzAyMTggKG5mc2NsX3JlcXVl
c3QrMHg2MCkKICAgICAgICAgc3AgPSAweGRmMWYyNGIwICBmcCA9IDB4ZGYxZjI0ZTgKICAgICAg
ICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4MDAwMTg2YTMKICAgICAgICAgcjYgPSAweDAwMDAw
MDAzICByNyA9IDB4MDAwMDAwMDEKICAgICAgICAgcjggPSAweGRmMWYyNmM4ICByOSA9IDB4YzBh
Zjk1NWMKICAgICAgICByMTAgPSAweDAwMDAwMDAwCm5mc2NsX3JlcXVlc3QoKSBhdCBuZnNjbF9y
ZXF1ZXN0KzB4NjAKICAgICAgICAgcGMgPSAweGMwMjMwMjE4ICBsciA9IDB4YzAyMGQ5YmMgKG5m
c3JwY19nZXRhdHRyKzB4YjApCiAgICAgICAgIHNwID0gMHhkZjFmMjRmMCAgZnAgPSAweGRmMWYy
NjE4CiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGRiNWFmZDAwCiAgICAgICAgIHI2
ID0gMHhkYjU1MjdjMCAgcjcgPSAweGUyOWQ0NTNjCm5mc3JwY19nZXRhdHRyKCkgYXQgbmZzcnBj
X2dldGF0dHIrMHhiMAogICAgICAgICBwYyA9IDB4YzAyMGQ5YmMgIGxyID0gMHhjMDIyM2I4OCAo
bmZzX2dldGF0dHIrMHhjOCkKICAgICAgICAgc3AgPSAweGRmMWYyNjIwICBmcCA9IDB4ZGYxZjI3
YjAKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4ZTI5ZDQ1M2MKICAgICAgICAgcjYg
PSAweGUyOWQ2NjcwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAgcjggPSAweGRiNTUyN2MwICBy
OSA9IDB4ZGYxZjI4MzAKICAgICAgICByMTAgPSAweGRiNTUyN2MwCm5mc19nZXRhdHRyKCkgYXQg
bmZzX2dldGF0dHIrMHhjOAogICAgICAgICBwYyA9IDB4YzAyMjNiODggIGxyID0gMHhjMDNiOWI4
MCAodm9wX3NpZ2RlZmVyKzB4MzQpCiAgICAgICAgIHNwID0gMHhkZjFmMjdiOCAgZnAgPSAweGRm
MWYyN2M4CiAgICAgICAgIHI0ID0gMHhkZjFmMjk5OCAgcjUgPSAweGZmZmZmZmZmCiAgICAgICAg
IHI2ID0gMHhjMDIyM2FjMCAgcjcgPSAweDAwMDAwMDAwCiAgICAgICAgIHI4ID0gMHhkZjFmMmQ2
MCAgcjkgPSAweGRiNzk1ODAwCnZvcF9zaWdkZWZlcigpIGF0IHZvcF9zaWdkZWZlcisweDM0CiAg
ICAgICAgIHBjID0gMHhjMDNiOWI4MCAgbHIgPSAweGMwMjIxYTAwIChuZnNfbG9va3VwKzB4MzQ0
KQogICAgICAgICBzcCA9IDB4ZGYxZjI3ZDAgIGZwID0gMHhkZjFmMmFhOAogICAgICAgICByNCA9
IDB4ZTI5ZDY2NzAgIHI1ID0gMHhkZjFmMjgzMAogICAgICAgICByNiA9IDB4ZTI5ZDY2NjAgcjEw
ID0gMHhkYjU1MjdjMApuZnNfbG9va3VwKCkgYXQgbmZzX2xvb2t1cCsweDM0NAogICAgICAgICBw
YyA9IDB4YzAyMjFhMDAgIGxyID0gMHhjMDNiOWI4MCAodm9wX3NpZ2RlZmVyKzB4MzQpCiAgICAg
ICAgIHNwID0gMHhkZjFmMmFiMCAgZnAgPSAweGRmMWYyYWMwCiAgICAgICAgIHI0ID0gMHhkZjFm
MmFlNCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0gMHhjMDIyMTZiYyAgcjcgPSAweDAw
MDgwMDAwCiAgICAgICAgIHI4ID0gMHhkZjFmMmQ2MCAgcjkgPSAweDAwMDAwMDAyCiAgICAgICAg
cjEwID0gMHgwMDAwMDAwMAp2b3Bfc2lnZGVmZXIoKSBhdCB2b3Bfc2lnZGVmZXIrMHgzNAogICAg
ICAgICBwYyA9IDB4YzAzYjliODAgIGxyID0gMHhjMDNiZTU1YyAobG9va3VwKzB4NDZjKQogICAg
ICAgICBzcCA9IDB4ZGYxZjJhYzggIGZwID0gMHhkZjFmMmIxMAogICAgICAgICByNCA9IDB4ZGYx
ZjJkMDAgIHI1ID0gMHhkYjllNGVhOAogICAgICAgICByNiA9IDB4ZGYxZjJkNTggcjEwID0gMHgw
MDAwMDAwMApsb29rdXAoKSBhdCBsb29rdXArMHg0NmMKICAgICAgICAgcGMgPSAweGMwM2JlNTVj
ICBsciA9IDB4YzAzYmQ0NTAgKG5hbWVpKzB4M2NjKQogICAgICAgICBzcCA9IDB4ZGYxZjJiMTgg
IGZwID0gMHhkZjFmMmJiOAogICAgICAgICByNCA9IDB4ZGYxZjJkMDAgIHI1ID0gMHhmZmZmZjgx
YwogICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhkYjNiY2M5MAogICAgICAgICByOCA9
IDB4YzBiNWE0OGMgIHI5ID0gMHhkYjU1MjdjMAogICAgICAgIHIxMCA9IDB4ZGYxZjJkNjAKbmFt
ZWkoKSBhdCBuYW1laSsweDNjYwogICAgICAgICBwYyA9IDB4YzAzYmQ0NTAgIGxyID0gMHhjMDNl
NGU5OCAodm5fb3Blbl9jcmVkKzB4NDVjKQogICAgICAgICBzcCA9IDB4ZGYxZjJiYzAgIGZwID0g
MHhkZjFmMmNjOAogICAgICAgICByNCA9IDB4MDAwMDAwMDEgIHI1ID0gMHgwMDAwMDAwMAogICAg
ICAgICByNiA9IDB4MDAxMDAwMDEgIHI3ID0gMHhkZjFmMmQ2MAogICAgICAgICByOCA9IDB4ZmZm
ZmZmOWMgIHI5ID0gMHhkZjFmMmQwMAogICAgICAgIHIxMCA9IDB4ZGYxZjJkNTgKdm5fb3Blbl9j
cmVkKCkgYXQgdm5fb3Blbl9jcmVkKzB4NDVjCiAgICAgICAgIHBjID0gMHhjMDNlNGU5OCAgbHIg
PSAweGMwM2U0YTM0ICh2bl9vcGVuKzB4MjQpCiAgICAgICAgIHNwID0gMHhkZjFmMmNkMCAgZnAg
PSAweGRmMWYyY2Q4CiAgICAgICAgIHI0ID0gMHhkYjU1MjdjMCAgcjUgPSAweGRmMWYyZDAwCiAg
ICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweGRmMWYyZDAwCiAgICAgICAgIHI4ID0gMHhm
ZmZmZmY5YyAgcjkgPSAweDAwMDAwMDEyCiAgICAgICAgcjEwID0gMHgyMDA3NmIwNAp2bl9vcGVu
KCkgYXQgdm5fb3BlbisweDI0CiAgICAgICAgIHBjID0gMHhjMDNlNGEzNCAgbHIgPSAweGMwM2Ri
NDI4IChrZXJuX29wZW5hdCsweDI1NCkKICAgICAgICAgc3AgPSAweGRmMWYyY2UwICBmcCA9IDB4
ZGYxZjJkYjgKa2Vybl9vcGVuYXQoKSBhdCBrZXJuX29wZW5hdCsweDI1NAogICAgICAgICBwYyA9
IDB4YzAzZGI0MjggIGxyID0gMHhjMDNkYjZiMCAoc3lzX29wZW5hdCsweDJjKQogICAgICAgICBz
cCA9IDB4ZGYxZjJkYzAgIGZwID0gMHhkZjFmMmRjOAogICAgICAgICByNCA9IDB4ZGI1NTI3YzAg
IHI1ID0gMHgwMDAwMDAwMQogICAgICAgICByNiA9IDB4YzA4ZDk5Y2MgIHI3ID0gMHgwMDAwMDAw
MAogICAgICAgICByOCA9IDB4MDAwMDAwMDAgIHI5ID0gMHhkYjU1MmE2OAogICAgICAgIHIxMCA9
IDB4ZGJhMjljODAKc3lzX29wZW5hdCgpIGF0IHN5c19vcGVuYXQrMHgyYwogICAgICAgICBwYyA9
IDB4YzAzZGI2YjAgIGxyID0gMHhjMDVlYjliNCAoc3dpX2hhbmRsZXIrMHgxNWMpCiAgICAgICAg
IHNwID0gMHhkZjFmMmRkMCAgZnAgPSAweGRmMWYyZTQwCnN3aV9oYW5kbGVyKCkgYXQgc3dpX2hh
bmRsZXIrMHgxNWMKICAgICAgICAgcGMgPSAweGMwNWViOWI0ICBsciA9IDB4YzA1Y2I1M2MgKHN3
aV9leGl0KQogICAgICAgICBzcCA9IDB4ZGYxZjJlNDggIGZwID0gMHhiZmJmZTcyMAogICAgICAg
ICByNCA9IDB4MjAyN2QyZjQgIHI1ID0gMHgwMDA2NWM0MAogICAgICAgICByNiA9IDB4MjAwNzZh
YzggIHI3ID0gMHgwMDAwMDFmMwogICAgICAgICByOCA9IDB4MDAwMDAwMDEgIHI5ID0gMHgwMDA2
NWM0MAogICAgICAgIHIxMCA9IDB4MDAwNjRkODgKc3dpX2V4aXQoKSBhdCBzd2lfZXhpdAogICAg
ICAgICBwYyA9IDB4YzA1Y2I1M2MgIGxyID0gMHhjMDVjYjUzYyAoc3dpX2V4aXQpCiAgICAgICAg
IHNwID0gMHhkZjFmMmU0OCAgZnAgPSAweGJmYmZlNzIwCktEQjogZW50ZXI6IHBhbmljClsgdGhy
ZWFkIHBpZCA1NzkgdGlkIDEwMDEyMiBdClN0b3BwZWQgYXQgICAgICBrZGJfZW50ZXIrMHg1ODog
bGRyYiAgICByMTUsIFtyMTUsIHIxNSwgcm9yIHIxNV0h

--b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48cHJlPkFm
dGVyIGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0ZWQgc2luY2UgdGhpcyBjb21taXQuPGJy
Pjxicj48c3Bhbj5jb21taXQgNzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0ZDJiOGQxNTNmOTY2NTEx
Mzwvc3Bhbj48ZGl2PjxzcGFuPkF1dGhvcjogS3Jpc3RvZiBQcm92b3N0ICZsdDs8YSB0YXJnZXQ9
Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJtYWlsdG86
a3BARnJlZUJTRC5vcmciPmtwQEZyZWVCU0Qub3JnPC9hPiZndDs8L3NwYW4+PC9kaXY+PGRpdj48
c3Bhbj5EYXRlOiAmbmJzcDsgTW9uIEZlYiAxNCAyMDowOTo1NCAyMDIyICswMTAwPC9zcGFuPjwv
ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyB2bGFuOiBhbGxvdyBu
ZXQubGluay52bGFuLm10YWdfcGNwIHRvIGJlIHNldCBwZXIgdm5ldDwvc3Bhbj48L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyAmbmJzcDsgVGhlIHByaW1hcnkgcmVhc29uIGZv
ciB0aGlzIGNoYW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3RpbmcuPC9zcGFuPjwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyBNRkMgYWZ0ZXI6ICZuYnNwOyAmbmJz
cDsgJm5ic3A7MSB3ZWVrPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5i
c3A7c3lzL25ldC9pZl9ldGhlcnN1YnIuYyB8IDkgKysrKystLS0tPC9zcGFuPjwvZGl2PjxkaXY+
PHNwYW4+Jm5ic3A7c3lzL25ldC9pZl92bGFuLmMgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IDUgKysr
LS08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsyIGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0
aW9ucygrKSwgNiBkZWxldGlvbnMoLSk8L3NwYW4+PC9kaXY+PGJyPlRoZSBhcm12NyBib2FyZCBi
b290cyBmcm9tIGEgTkZTIHJvb3QsPGJyPml0IGNhbiBib290IHdpdGhvdXQgYW55IHByb2JsZW0g
aWYgUEYgaXMgZGlzYWJsZWQuPGJyPkFueSBoZWxwcz88YnI+PGJyPmFkZCBob3N0IDo6MTogZ2F0
ZXdheSBsbzAgZmliIDA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUNCmFkZCBuZXQgZmU4MDo6OiBn
YXRld2F5IDo6MQ0KYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxDQphZGQgbmV0IDo6ZmZmZjow
LjAuMC4wOiBnYXRld2F5IDo6MQ0KYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxDQpFbmFi
bGluZyBwZi4NCktlcm5lbCBwYWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBh
YmxlIGxvY2tzIGhlbGQ6DQpzaGFyZWQgcm0gcGYgcnVsZXNldHMgKHBmIHJ1bGVzZXRzKSByID0g
MCAoMHhlMzA5OTQzMCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldHBmaWwvcGYvcGYuYzo2NDkz
DQpleGNsdXNpdmUgcncgdGNwaW5wICh0Y3BpbnApIHIgPSAwICgweGRiNzQ4ZDg4KSBsb2NrZWQg
QCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6MTAwOA0Kc3RhY2sgYmFja3RyYWNl
Og0KIzAgMHhjMDM1NWNhYyBhdCB3aXRuZXNzX2RlYnVnZ2VyKzB4N2MNCiMxIDB4YzAzNTZlZjAg
YXQgd2l0bmVzc193YXJuKzB4M2ZjDQojMiAweGMwNWVjMDQ4IGF0IGFib3J0X2hhbmRsZXIrMHgx
ZDgNCiMzIDB4YzA1Y2I1YWMgYXQgZXhjZXB0aW9uX2V4aXQrMA0KIzQgMHhlMzA4M2MxMCBhdCBw
Zl9zeW5jb29raWVfdmFsaWRhdGUrMHg2MA0KIzUgMHhlMzA0OTZhOCBhdCBwZl90ZXN0KzB4NTE4
DQojNiAweGUzMDZkNzY4IGF0IHBmX2NoZWNrX291dCsweDMwDQojNyAweGMwNDE1YjQ0IGF0IHBm
aWxfcnVuX2hvb2tzKzB4YmMNCiM4IDB4YzA0NDVjZmMgYXQgaXBfb3V0cHV0KzB4Y2U4DQojOSAw
eGMwNDViYzljIGF0IHRjcF9kZWZhdWx0X291dHB1dCsweDIwYWMNCiMxMCAweGMwNDcxZWI0IGF0
IHRjcF91c3Jfc2VuZCsweDFhYw0KIzExIDB4YzAzODk0NjQgYXQgc29zZW5kX2dlbmVyaWMrMHg0
OTANCiMxMiAweGMwMzg5NzkwIGF0IHNvc2VuZCsweDY0DQojMTMgMHhjMDUwMjg4OCBhdCBjbG50
X3ZjX2NhbGwrMHg1NjANCiMxNCAweGMwNTAwOWQ4IGF0IGNsbnRfcmVjb25uZWN0X2NhbGwrMHgx
NzANCiMxNSAweGMwMWU3YjE0IGF0IG5ld25mc19yZXF1ZXN0KzB4YjIwDQojMTYgMHhjMDIzMDIx
OCBhdCBuZnNjbF9yZXF1ZXN0KzB4NjANCiMxNyAweGMwMjBkOWJjIGF0IG5mc3JwY19nZXRhdHRy
KzB4YjANCkZhdGFsIGtlcm5lbCBtb2RlIGRhdGEgYWJvcnQ6ICdBbGlnbm1lbnQgRmF1bHQnIG9u
IHJlYWQNCnRyYXBmcmFtZTogMHhkZjFmMWM5MA0KRlNSPTAwMDAwMDAxLCBGQVI9ZDc4NDAyNjQs
IHNwc3I9NDAwMDAwMTMNCnIwID02YTIyOGVkYSwgcjEgPWRhYzBkNzg1LCByMiA9ZDc4NDAyNjQs
IHIzID1kYjU1MjdjMA0KcjQgPWRmMWYxZTAwLCByNSA9ZGFjMGQ3NWYsIHI2ID0wMDAwMDAxOCwg
cjcgPWQ5NDIyYzAwDQpyOCA9YzA5M2U1ZTQsIHI5ID0wMDAwMDAwMSwgcjEwPWRmMWYxZjVjLCBy
MTE9ZGYxZjFkMzgNCnIxMj1lMzA5OGRkMCwgc3NwPWRmMWYxZDIwLCBzbHI9ZTMwODNiZGMsIHBj
ID1lMzA4M2MxMA0KDQpwYW5pYzogRmF0YWwgYWJvcnQNCmNwdWlkID0gMQ0KdGltZSA9IDE2NTEz
NjYwODkNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2VsZigpIGF0IGRiX3RyYWNl
X3NlbGYNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzA1YzhjMDAg
Jm5ic3A7bHIgPSAweGMwMDdhYzhjIChkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgzMCkNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFhNjggJm5ic3A7ZnAgPSAw
eGRmMWYxYjgwDQpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBw
ZXIrMHgzMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDA3YWM4
YyAmbmJzcDtsciA9IDB4YzAyZTI4OWMgKHZwYW5pYysweDE3MCkNCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFiODggJm5ic3A7ZnAgPSAweGRmMWYxYmE4DQom
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMTAwICZuYnNwO3I1
ID0gMHgwMDAwMDAwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhj
MDc4MDUyOSAmbmJzcDtyNyA9IDB4YzA5MGVhMTANCnZwYW5pYygpIGF0IHZwYW5pYysweDE3MA0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDJlMjg5YyAmbmJzcDts
ciA9IDB4YzAyZTI2NGMgKGRvYWR1bXApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7c3AgPSAweGRmMWYxYmIwICZuYnNwO2ZwID0gMHhkZjFmMWJiNA0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkZjFmMWM5MCAmbmJzcDtyNSA9IDB4MDAwMDAwMTMN
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4ZDc4NDAyNjQgJm5ic3A7
cjcgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAw
eDAwMDAwMDAxICZuYnNwO3I5ID0gMHhkYjU1MjdjMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IHIxMCA9IDB4ZDc4NDAyNjQNCmRvYWR1bXAoKSBhdCBkb2FkdW1wDQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMmUyNjRjICZuYnNwO2xyID0gMHhjMDVlYzY5
OCAoYWJvcnRfYWxpZ24pDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAw
eGRmMWYxYmJjICZuYnNwO2ZwID0gMHhkZjFmMWJlOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3I0ID0gMHhkNzg0MDI2NCAmbmJzcDtyNSA9IDB4ZGYxZjFiYjQNCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAyZTI2NGMgcjEwID0gMHhkZjFmMWJi
Yw0KYWJvcnRfYWxpZ24oKSBhdCBhYm9ydF9hbGlnbg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3BjID0gMHhjMDVlYzY5OCAmbmJzcDtsciA9IDB4YzA1ZWMxOTggKGFib3J0X2hh
bmRsZXIrMHgzMjgpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRm
MWYxYmYwICZuYnNwO2ZwID0gMHhkZjFmMWM4OA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3I0ID0gMHgwMDAwMDAxMyAmbmJzcDtyNSA9IDB4ZDc4NDAyNjQNCmFib3J0X2hhbmRs
ZXIoKSBhdCBhYm9ydF9oYW5kbGVyKzB4MzI4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cGMgPSAweGMwNWVjMTk4ICZuYnNwO2xyID0gMHhjMDVjYjVhYyAoZXhjZXB0aW9uX2V4
aXQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYxYzkwICZu
YnNwO2ZwID0gMHhkZjFmMWQzOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0
ID0gMHhkZjFmMWUwMCAmbmJzcDtyNSA9IDB4ZGFjMGQ3NWYNCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAwMDAwMTggJm5ic3A7cjcgPSAweGQ5NDIyYzAwDQombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGMwOTNlNWU0ICZuYnNwO3I5ID0g
MHgwMDAwMDAwMQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGYxZjFmNWMN
CmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0aW9uX2V4aXQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzA1Y2I1YWMgJm5ic3A7bHIgPSAweGUzMDgzYmRjIChwZl9z
eW5jb29raWVfdmFsaWRhdGUrMHgyYykNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDtzcCA9IDB4ZGYxZjFkMjAgJm5ic3A7ZnAgPSAweGRmMWYxZDM4DQombmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7cjAgPSAweDZhMjI4ZWRhICZuYnNwO3IxID0gMHhkYWMwZDc4NQ0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3IyID0gMHhkNzg0MDI2NCAmbmJzcDty
MyA9IDB4ZGI1NTI3YzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4
ZGYxZjFlMDAgJm5ic3A7cjUgPSAweGRhYzBkNzVmDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7cjYgPSAweDAwMDAwMDE4ICZuYnNwO3I3ID0gMHhkOTQyMmMwMA0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHhjMDkzZTVlNCAmbmJzcDtyOSA9IDB4MDAw
MDAwMDENCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGRmMWYxZjVjIHIxMiA9
IDB4ZTMwOThkZDANCnBmX3N5bmNvb2tpZV92YWxpZGF0ZSgpIGF0IHBmX3N5bmNvb2tpZV92YWxp
ZGF0ZSsweDYwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGUzMDgz
YzEwICZuYnNwO2xyID0gMHhlMzA0OTZhOCAocGZfdGVzdCsweDUxOCkNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFkNDAgJm5ic3A7ZnAgPSAweGRmMWYxZWE4
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDIwMDAwICZuYnNw
O3I1ID0gMHhkYjRhNjEwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0g
MHgwMDAwMDAxOCAmbmJzcDtyNyA9IDB4ZDk0MjJjMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDtyOCA9IDB4MDAwMDAwMDIgJm5ic3A7cjkgPSAweDAwMDAwMDAxDQpwZl90ZXN0
KCkgYXQgcGZfdGVzdCsweDUxOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bj
ID0gMHhlMzA0OTZhOCAmbmJzcDtsciA9IDB4ZTMwNmQ3NjggKHBmX2NoZWNrX291dCsweDMwKQ0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMWViMCAmbmJzcDtm
cCA9IDB4ZGYxZjFlYzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4
ZGYxZjFmNWMgJm5ic3A7cjUgPSAweGUzMDZkNzM4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7cjYgPSAweGRiNmJhNjYwICZuYnNwO3I3ID0gMHgwMDAwMDAwMA0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHhkOTQyMmMwMCAmbmJzcDtyOSA9IDB4ZGI3
NDhkODANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGZmZjcwMDAwDQpwZl9j
aGVja19vdXQoKSBhdCBwZl9jaGVja19vdXQrMHgzMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3BjID0gMHhlMzA2ZDc2OCAmbmJzcDtsciA9IDB4YzA0MTViNDQgKHBmaWxfcnVu
X2hvb2tzKzB4YmMpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRm
MWYxZWM4ICZuYnNwO2ZwID0gMHhkZjFmMWVmMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3I0ID0gMHgwMDAyMDAwMCAmbmJzcDtyNSA9IDB4ZTMwNmQ3MzgNCnBmaWxfcnVuX2hv
b2tzKCkgYXQgcGZpbF9ydW5faG9va3MrMHhiYw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3BjID0gMHhjMDQxNWI0NCAmbmJzcDtsciA9IDB4YzA0NDVjZmMgKGlwX291dHB1dCsw
eGNlOCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFlZjgg
Jm5ic3A7ZnAgPSAweGRmMWYxZmE4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
cjQgPSAweDAwMDAwMTBhICZuYnNwO3I1ID0gMHgwMDAwMGEwYQ0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhkYjRhNjE1OCAmbmJzcDtyNyA9IDB4YzA5NDY5MDgNCiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI1YmVjMDAgJm5ic3A7cjkg
PSAweGQ5NDIyYzAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHgwMDAwMDVk
Yw0KaXBfb3V0cHV0KCkgYXQgaXBfb3V0cHV0KzB4Y2U4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7cGMgPSAweGMwNDQ1Y2ZjICZuYnNwO2xyID0gMHhjMDQ1YmM5YyAodGNwX2Rl
ZmF1bHRfb3V0cHV0KzB4MjBhYykNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtz
cCA9IDB4ZGYxZjFmYjAgJm5ic3A7ZnAgPSAweGRmMWYyMGUwDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMDAxICZuYnNwO3I1ID0gMHgwMDAwMDAwMA0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHgwMDAwMDAzNCAmbmJzcDtyNyA9
IDB4ZGI3NDYwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI0
YTYxNmMgJm5ic3A7cjkgPSAweGRiNGE2MTAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
cjEwID0gMHhkYjc4MjAwMA0KdGNwX2RlZmF1bHRfb3V0cHV0KCkgYXQgdGNwX2RlZmF1bHRfb3V0
cHV0KzB4MjBhYw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDQ1
YmM5YyAmbmJzcDtsciA9IDB4YzA0NzFlYjQgKHRjcF91c3Jfc2VuZCsweDFhYykNCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjIwZTggJm5ic3A7ZnAgPSAweGRm
MWYyMTYwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweGMwYWY5NTVj
ICZuYnNwO3I1ID0gMHhkYjc4MjAwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O3I2ID0gMHgwMDAwMDAwMCAmbmJzcDtyNyA9IDB4ZGI3NDYwMDANCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4MDAwMDAwMDAgJm5ic3A7cjkgPSAweGRiNzQ4ZDgwDQom
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHgwMDAwMDAwMA0KdGNwX3Vzcl9zZW5k
KCkgYXQgdGNwX3Vzcl9zZW5kKzB4MWFjDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7cGMgPSAweGMwNDcxZWI0ICZuYnNwO2xyID0gMHhjMDM4OTQ2NCAoc29zZW5kX2dlbmVyaWMr
MHg0OTApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyMTY4
ICZuYnNwO2ZwID0gMHhkZjFmMjFkMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O3I0ID0gMHhjMDQ3MWQwOCAmbmJzcDtyNSA9IDB4MDAwNDQwMDANCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4ZGI3NDYwMDAgJm5ic3A7cjcgPSAweGRiNTUyN2MwDQom
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweDAwMDAwMDAwICZuYnNwO3I5
ID0gMHhkYjc0NjFiOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGI0YjI5
MDANCnNvc2VuZF9nZW5lcmljKCkgYXQgc29zZW5kX2dlbmVyaWMrMHg0OTANCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzODk0NjQgJm5ic3A7bHIgPSAweGMwMzg5
NzkwIChzb3NlbmQrMHg2NCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9
IDB4ZGYxZjIxZDggJm5ic3A7ZnAgPSAweGRmMWYyMjAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMDAwICZuYnNwO3I1ID0gMHhjMDM4OGZkNA0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhkYjU1MjdjMCAmbmJzcDtyNyA9IDB4
MDAwMDAwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4NWU0YTZm
MjggJm5ic3A7cjkgPSAweDAwMDAwMTAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEw
ID0gMHhjNzJmYzQ5MA0Kc29zZW5kKCkgYXQgc29zZW5kKzB4NjQNCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzODk3OTAgJm5ic3A7bHIgPSAweGMwNTAyODg4IChj
bG50X3ZjX2NhbGwrMHg1NjApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag
PSAweGRmMWYyMjA4ICZuYnNwO2ZwID0gMHhkZjFmMjJlOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO3I0ID0gMHhjMDc2ZTEzMiAmbmJzcDtyNSA9IDB4ZGYxZjIyYWMNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzcyZmM1YTAgJm5ic3A7cjcgPSAw
eGMwNGZkMzQ4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGM3MmZj
NDgwIHIxMCA9IDB4YzcyZmM0OTANCmNsbnRfdmNfY2FsbCgpIGF0IGNsbnRfdmNfY2FsbCsweDU2
MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDUwMjg4OCAmbmJz
cDtsciA9IDB4YzA1MDA5ZDggKGNsbnRfcmVjb25uZWN0X2NhbGwrMHgxNzApDQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyMmYwICZuYnNwO2ZwID0gMHhkZjFm
MjM3OA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhjMDUwMjMyOCAm
bmJzcDtyNSA9IDB4YzA3NjgxMzcNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty
NiA9IDB4ZGI2NWJjNDAgJm5ic3A7cjcgPSAweGM3MmZjNjEwDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7cjggPSAweGM3MmZjNjAwICZuYnNwO3I5ID0gMHgwMDAwMDAwMA0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGYxZjI0MzgNCmNsbnRfcmVjb25uZWN0
X2NhbGwoKSBhdCBjbG50X3JlY29ubmVjdF9jYWxsKzB4MTcwDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwNTAwOWQ4ICZuYnNwO2xyID0gMHhjMDFlN2IxNCAobmV3
bmZzX3JlcXVlc3QrMHhiMjApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag
PSAweGRmMWYyMzgwICZuYnNwO2ZwID0gMHhkZjFmMjRhOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO3I0ID0gMHgwMDAwMDEyYyAmbmJzcDtyNSA9IDB4YzA1MDA4NjgNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAwMDAwMDAgJm5ic3A7cjcgPSAw
eDAwMDAwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGRmMWYy
NTEwICZuYnNwO3I5ID0gMHhjMDcyNjc2MQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIx
MCA9IDB4MDAwMDAwMDANCm5ld25mc19yZXF1ZXN0KCkgYXQgbmV3bmZzX3JlcXVlc3QrMHhiMjAN
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAxZTdiMTQgJm5ic3A7
bHIgPSAweGMwMjMwMjE4IChuZnNjbF9yZXF1ZXN0KzB4NjApDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyNGIwICZuYnNwO2ZwID0gMHhkZjFmMjRlOA0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHgwMDAwMDAwMCAmbmJzcDtyNSA9
IDB4MDAwMTg2YTMNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAw
MDAwMDMgJm5ic3A7cjcgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cjggPSAweGRmMWYyNmM4ICZuYnNwO3I5ID0gMHhjMGFmOTU1Yw0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MDAwMDAwMDANCm5mc2NsX3JlcXVlc3QoKSBhdCBuZnNj
bF9yZXF1ZXN0KzB4NjANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4
YzAyMzAyMTggJm5ic3A7bHIgPSAweGMwMjBkOWJjIChuZnNycGNfZ2V0YXR0cisweGIwKQ0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMjRmMCAmbmJzcDtmcCA9
IDB4ZGYxZjI2MTgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MDAw
MDAwMDAgJm5ic3A7cjUgPSAweGRiNWFmZDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cjYgPSAweGRiNTUyN2MwICZuYnNwO3I3ID0gMHhlMjlkNDUzYw0KbmZzcnBjX2dldGF0
dHIoKSBhdCBuZnNycGNfZ2V0YXR0cisweGIwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cGMgPSAweGMwMjBkOWJjICZuYnNwO2xyID0gMHhjMDIyM2I4OCAobmZzX2dldGF0dHIr
MHhjOCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjI2MjAg
Jm5ic3A7ZnAgPSAweGRmMWYyN2IwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
cjQgPSAweDAwMDAwMDAwICZuYnNwO3I1ID0gMHhlMjlkNDUzYw0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhlMjlkNjY3MCAmbmJzcDtyNyA9IDB4MDAwMDAwMDANCiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI1NTI3YzAgJm5ic3A7cjkg
PSAweGRmMWYyODMwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHhkYjU1Mjdj
MA0KbmZzX2dldGF0dHIoKSBhdCBuZnNfZ2V0YXR0cisweGM4DQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMjIzYjg4ICZuYnNwO2xyID0gMHhjMDNiOWI4MCAodm9w
X3NpZ2RlZmVyKzB4MzQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAw
eGRmMWYyN2I4ICZuYnNwO2ZwID0gMHhkZjFmMjdjOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3I0ID0gMHhkZjFmMjk5OCAmbmJzcDtyNSA9IDB4ZmZmZmZmZmYNCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAyMjNhYzAgJm5ic3A7cjcgPSAweDAw
MDAwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGRmMWYyZDYw
ICZuYnNwO3I5ID0gMHhkYjc5NTgwMA0Kdm9wX3NpZ2RlZmVyKCkgYXQgdm9wX3NpZ2RlZmVyKzB4
MzQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzYjliODAgJm5i
c3A7bHIgPSAweGMwMjIxYTAwIChuZnNfbG9va3VwKzB4MzQ0KQ0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMjdkMCAmbmJzcDtmcCA9IDB4ZGYxZjJhYTgNCiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZTI5ZDY2NzAgJm5ic3A7cjUg
PSAweGRmMWYyODMwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweGUy
OWQ2NjYwIHIxMCA9IDB4ZGI1NTI3YzANCm5mc19sb29rdXAoKSBhdCBuZnNfbG9va3VwKzB4MzQ0
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMjIxYTAwICZuYnNw
O2xyID0gMHhjMDNiOWI4MCAodm9wX3NpZ2RlZmVyKzB4MzQpDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyYWIwICZuYnNwO2ZwID0gMHhkZjFmMmFjMA0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkZjFmMmFlNCAmbmJzcDtyNSA9
IDB4MDAwMDAwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAy
MjE2YmMgJm5ic3A7cjcgPSAweDAwMDgwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cjggPSAweGRmMWYyZDYwICZuYnNwO3I5ID0gMHgwMDAwMDAwMg0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MDAwMDAwMDANCnZvcF9zaWdkZWZlcigpIGF0IHZvcF9z
aWdkZWZlcisweDM0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMw
M2I5YjgwICZuYnNwO2xyID0gMHhjMDNiZTU1YyAobG9va3VwKzB4NDZjKQ0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMmFjOCAmbmJzcDtmcCA9IDB4ZGYxZjJi
MTANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZGYxZjJkMDAgJm5i
c3A7cjUgPSAweGRiOWU0ZWE4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYg
PSAweGRmMWYyZDU4IHIxMCA9IDB4MDAwMDAwMDANCmxvb2t1cCgpIGF0IGxvb2t1cCsweDQ2Yw0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDNiZTU1YyAmbmJzcDts
ciA9IDB4YzAzYmQ0NTAgKG5hbWVpKzB4M2NjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3NwID0gMHhkZjFmMmIxOCAmbmJzcDtmcCA9IDB4ZGYxZjJiYjgNCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZGYxZjJkMDAgJm5ic3A7cjUgPSAweGZmZmZm
ODFjDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweDAwMDAwMDAwICZu
YnNwO3I3ID0gMHhkYjNiY2M5MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4
ID0gMHhjMGI1YTQ4YyAmbmJzcDtyOSA9IDB4ZGI1NTI3YzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyByMTAgPSAweGRmMWYyZDYwDQpuYW1laSgpIGF0IG5hbWVpKzB4M2NjDQombmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwM2JkNDUwICZuYnNwO2xyID0gMHhj
MDNlNGU5OCAodm5fb3Blbl9jcmVkKzB4NDVjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3NwID0gMHhkZjFmMmJjMCAmbmJzcDtmcCA9IDB4ZGYxZjJjYzgNCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MDAwMDAwMDEgJm5ic3A7cjUgPSAweDAwMDAw
MDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweDAwMTAwMDAxICZu
YnNwO3I3ID0gMHhkZjFmMmQ2MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4
ID0gMHhmZmZmZmY5YyAmbmJzcDtyOSA9IDB4ZGYxZjJkMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyByMTAgPSAweGRmMWYyZDU4DQp2bl9vcGVuX2NyZWQoKSBhdCB2bl9vcGVuX2NyZWQr
MHg0NWMNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzZTRlOTgg
Jm5ic3A7bHIgPSAweGMwM2U0YTM0ICh2bl9vcGVuKzB4MjQpDQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyY2QwICZuYnNwO2ZwID0gMHhkZjFmMmNkOA0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkYjU1MjdjMCAmbmJzcDtyNSA9
IDB4ZGYxZjJkMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAw
MDAwMDAgJm5ic3A7cjcgPSAweGRmMWYyZDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7cjggPSAweGZmZmZmZjljICZuYnNwO3I5ID0gMHgwMDAwMDAxMg0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MjAwNzZiMDQNCnZuX29wZW4oKSBhdCB2bl9vcGVuKzB4
MjQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzZTRhMzQgJm5i
c3A7bHIgPSAweGMwM2RiNDI4IChrZXJuX29wZW5hdCsweDI1NCkNCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjJjZTAgJm5ic3A7ZnAgPSAweGRmMWYyZGI4DQpr
ZXJuX29wZW5hdCgpIGF0IGtlcm5fb3BlbmF0KzB4MjU0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7cGMgPSAweGMwM2RiNDI4ICZuYnNwO2xyID0gMHhjMDNkYjZiMCAoc3lzX29w
ZW5hdCsweDJjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFm
MmRjMCAmbmJzcDtmcCA9IDB4ZGYxZjJkYzgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDtyNCA9IDB4ZGI1NTI3YzAgJm5ic3A7cjUgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweGMwOGQ5OWNjICZuYnNwO3I3ID0gMHgwMDAwMDAw
MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHgwMDAwMDAwMCAmbmJz
cDtyOSA9IDB4ZGI1NTJhNjgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGRi
YTI5YzgwDQpzeXNfb3BlbmF0KCkgYXQgc3lzX29wZW5hdCsweDJjDQombmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwM2RiNmIwICZuYnNwO2xyID0gMHhjMDVlYjliNCAo
c3dpX2hhbmRsZXIrMHgxNWMpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag
PSAweGRmMWYyZGQwICZuYnNwO2ZwID0gMHhkZjFmMmU0MA0Kc3dpX2hhbmRsZXIoKSBhdCBzd2lf
aGFuZGxlcisweDE1Yw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhj
MDVlYjliNCAmbmJzcDtsciA9IDB4YzA1Y2I1M2MgKHN3aV9leGl0KQ0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMmU0OCAmbmJzcDtmcCA9IDB4YmZiZmU3MjAN
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MjAyN2QyZjQgJm5ic3A7
cjUgPSAweDAwMDY1YzQwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAw
eDIwMDc2YWM4ICZuYnNwO3I3ID0gMHgwMDAwMDFmMw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO3I4ID0gMHgwMDAwMDAwMSAmbmJzcDtyOSA9IDB4MDAwNjVjNDANCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweDAwMDY0ZDg4DQpzd2lfZXhpdCgpIGF0IHN3aV9l
eGl0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwNWNiNTNjICZu
YnNwO2xyID0gMHhjMDVjYjUzYyAoc3dpX2V4aXQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7c3AgPSAweGRmMWYyZTQ4ICZuYnNwO2ZwID0gMHhiZmJmZTcyMA0KS0RCOiBlbnRl
cjogcGFuaWMNClsgdGhyZWFkIHBpZCA1NzkgdGlkIDEwMDEyMiBdDQpTdG9wcGVkIGF0ICZuYnNw
OyAmbmJzcDsgJm5ic3A7a2RiX2VudGVyKzB4NTg6IGxkcmIgJm5ic3A7ICZuYnNwO3IxNSwgW3Ix
NSwgcjE1LCByb3IgcjE1XSENCjwvcHJlPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls
eTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4NCg0K


--b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y--


From nobody Sun May  1 04:18:02 2022
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 C33531AB3B78
	for ; Sun,  1 May 2022 04:18:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4KrXyX60kJz3t58
	for ; Sun,  1 May 2022 04:18:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651378685; bh=h52fvnteuRrGDPBs9wfz50y8qei/0CWe/9kbtnioYVY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LBhFooBSzqtqInP+47/xclxUybNsJUMOwUX2g+v09hzoCqXpBzUp/3w4HcRpqZ4/TpxcgzZop9Kzhyg1fQADSM1EuwsWVa+FWHGXQF9JST3/MgAas6RGG1t3382ZbYFd7Yq9uZJBOHXLVXfkV7SLF/x7wTAyJqqeB7aRRPBEeibEMNrRxFieZhX0leVr0TinTA0oL6bUTF0EKS1wfTgYMm3TtutgGtjUcxhuCquqt+lnaU75sB4UcTMRyWy0zFf5C7698qu/awNOctfsi7WN67tAviZstCr3XpaBbsdJW3JRNjZiivyJvASTWRXt8UaUEBKV8CejlPDTDiQnyLv6cA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651378685; bh=R4V/a6mHBCOaqNleVWFwnOgUDaW8kTz2oPHeDku2uV3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BFx/rFWSo5TGVBUjQwUe6xSfKilrdGcWNsyVz2YcsMy+O8FE6wh5oC9OEqsrzIvUmJlyqWvBPbexVk28h7wq/rOqyUo4YThspZF9qjE9yBgsWN7suRHLaHxfiP4Wpv6pF8fRsVyiUUXhfj9UAZPSLGg8pbreHY45i/bMgmoEX1N9m/EGdXaLdKAo8OfaV2i+d7byOM1zUgeGc0cNMsM2PRFz4nGJ5AOyP3L9nYjPl5HrlOpGT6WMl/urhaytahUh0Cw8M8WAB4ItpGik8RTpxmEZwPAi6SfWpOnBHMCKZRUrANeSNrUd1+WvFeqGwf0H1NMhndaKiDbBy2EjRS9cYA==
X-YMail-OSG: GBEgD.EVM1lJ0UcB5TDxmxSijQo0cMMaGBO6p4MdKt3KKGeqMV_ZbnzklDWHoJi
 GMqmfbjAjQiksbqAvKNRLZLiK6ZOprhr8IPVKOZ9MqxMcxx35CEUR1wFaOfI1gZ.64zXwaUCwiBn
 NjfODc45qg.iCW9lKqs6fWNGvEJyVtej05XXYsCd5qSoj87x8s3rMqjDd2NSk0ULcvJ6wxaS6a7p
 UScWDHyiV7fssxYFZ_LHBJKdRK30SRCsg_cBxDPjnWO73xa8D0na63uU4kwRQ8NY5UZZLeBhFzRc
 iVnqZA7TqivLKBLuT_2a.se34ZS04ZtOj43f9kju7Gm_aooJ417xGSwYRq7D.BzKybWzPrbBSfWc
 u8hxY..NC4M_8Pzu.cr5msraAlZEnE9zRan8RsIggyJEj_V8Wx6rXrhohge9wuup11LjLBL89LLk
 8PtusdgDMgFm9z5V6og.VljX3hh1Guut1DcQOBd8Nry216Mql_lbrCT7wZpqK4wR0TQ.6bbZdO.s
 fNM7b29YurBMg9oZB.WgRJCnozXOvizs8qB69ZrhZPMBbaifHaFyEPuCurSgJeegovrnMn4fL28g
 xkFtzczkxzt03naTD7sfbjnzM7en7tJ99OuqZexw1SR3zhATU0kloQZZsGPy0OpRWQVrw39cEK1U
 xxSr.P3iwiR5QJixvgbJ85iYVYF7MBUPciOBgz5jPZGuHYB9ixICwuG3THuikj29m5wxzOO7WBqT
 tBw.MZatOAIjGX3jdwi5Ai_Ox1RIZ3E6bHaWteQlwctjWqe.r5iOsf7xrIFLRUfsgrKqPrTfZkYg
 iDL842pjlgpy2AQXyiFDOdJ28O7Qe9Jk3DzQuqBe_J9j3DwN7lEjgzpLLUKtTav5V4n75bd5JC54
 3FqjWUNnsXF3iGsQ61v6AZ8JFWeU6_OogIjTYW6rar0fAhqxRO8xm0qWbzf10QJw_BdvochZcQvZ
 SQfQ3Hy9w2_O8EB_FmB4uSJfoS46XSsAtk3VTVMNqWbj0PWXeXmQ8roCPHhlx6zxxmsnSrkyh8es
 mKiuwM31HZSv22Ne4e6z6bsfFzV5yy0Dgf5sAbzsnfzurFYG7EiRvbg3GNoB635_bYpuoDFNbkVZ
 CjxysJiUBkembH5xf3mTxlRCiA6iu6DTrFdsPphtKw2umYV_Z6aOgjy.9MQgnBR8vitzkO_tuEaD
 _suICb9JkyCu6.wFTwS2A7Pwf71RObJYgs8n50dpn0PDdDOLLyqDr3AdfXS1zOOot5QKOLVN2lnQ
 yOV4z2W7RNwt.cAxjfHmCF.grBUiNx2bLgI8RunUCDnga_fj9GinllKaRpH99WmCNrnNK9KQAU5X
 ZE.NPHBfdtGlU7gO7QNX8XvZbHurRxh5bgkBCKEXysPyFkDD98AJUzLxrhkX49kxQoFMKEgYH9n5
 E3v3WX_4pWuTpsOb3CCdp6Ye9ZcPNpwtVPdUTtUeCayy0XiYsPjsxuHTXlacGTACywhxUc1N6NRX
 gf6jvNhAlLbKJfjUnCdsrxeOUk7KD8WxyS7Tb6fZ4EjWuEphFghItJA9gNd_XkFwFQYkJW2KUIyG
 8PY8CEb21mMI7duTLIcNQebV34RE_FJcH2sNwVxP_HPmC6NDmRmrC0eLu1lO7SNmkz2qHeELMON8
 otxN6.wRVXpkCyfRoJkDLIYPHCIuw3uWzBf1Hf8ZLMYqbDHrpeVWZ9xb8k1XJLEKKIAje5YOISSg
 HwSPe96BPAePVa1b4qi8wM5rMPZ0Bn40k8fvlxpJSx9sGE3a5CCumu4dY8uA4P2GyEN__fvXxHQA
 _YLM.I2ArrL_OOltS.86rOQil5uMUOdN_7vhOFda0Cyry.uKBsCsNFF2fyM0P3C_yL2UAYqeqxS6
 cDZDbNr3XGJkidrzSaIKPlP4XNXR25NJrtFKVqME9dfKtzULMbcukvkvMZkuzgcrl9PJzW4jsrtc
 0Pj7dypBaWh.IJk8J54u_gA_ZR5Ggq34t7w81JwnCGWtderhOOhyb7oUJXkdPMM4Q5B4_pYfq.WV
 0VK8oq0tUqp2lz898HlZXM4wc8XtCNc9J_8CiKDZPIBtxNBRvKPdMQVJTyXN_JoOB3SwpQiQdscI
 TpCobFfMb7t.Vw.lKTYiCB7kzfmm12wIcRPhr9xaqv0YkRrunEnTtHrbZ1c8H3fnz0Td85SPAMV4
 Pk.IwJVoYF4I679j4UTtQo0lYfORUMsIGffDHSNMdfgKtH8ldWrgqVU2FFUhQvniN99BdiT16tKT
 iHUDwGJ0M3BwhRsJ0g0rEI1aV_hZX8wJztV4EQPgB7SzU6.aKCF0YWxCq30kmXkJZtr986XBKO5r
 DMNyE3YhFtaO0tZhg8UU-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 May 2022 04:18:05 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-cj84z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 928a73409a23d54343fc16fef23a7b46;
          Sun, 01 May 2022 04:18:04 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <20220501011125.GC10723@www.zefox.net>
Date: Sat, 30 Apr 2022 21:18:02 -0700
Cc: freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B08DA24-34F7-4547-8B4E-96C9C8791D10@yahoo.com>
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501011125.GC10723@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KrXyX60kJz3t58
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=LBhFooBS;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8408
Lines: 249

On 2022-Apr-30, at 18:11, bob prohaska  wrote:

> On Fri, Apr 29, 2022 at 08:14:27PM -0700, Mark Millard wrote:
>> On 2022-Apr-29, at 19:12, bob prohaska  wrote:
>>=20
>>> Since about December of 2021 I've been noticing problems with
>>> wired network connectivity on a pair of raspberry pi 3 machines
>>> using wired network connections. One runs stable-13.1, the other
>>> runs -current, both are up to date as of a few days ago.
>>=20
>> Compared to your later notes about 192.168.1.n style use,
>> are any of the above that way? Or are the all well-analogous
>> to the "on the public network" context mentioned later?
>>=20
> Not sure I follow what you're getting at, could you clarify
> please? The move between public and private networks was done
> by changing comment delimiters in /etc/rc.conf and moving
> cables between public switch and private router. Only the two
> Pi3s have so far failed to answer pings and ssh connections
> after reboot.=20
>=20


What, if anything, has been tested that did not fail to
answer pings and ssh connections after reboot on the
public network? Any other types of RPi*'s?

For example, temporarily moving a RPi4B from the private
network to the public one, but booted from the same
13.1-RC4 microsd card as used for the RPi3B test, would
allow checking if the problem happens on the additional
type of RPi*.

Testing a RPi2 v1.1 could not use the same 13.1-RC4 microsd
card content as the RPi3B's can. Still a useful test,
but I mention RPi4B above because it can boot from the
same media content as was used for the RPI3B testing.


>>> Essentially both machines fail to respond to inbound network
>>> connections via ssh or ping after reboot. If I get on the=20
>>> serial console and start an outbound ping to anywhere, both
>>> machines respond to incoming pings with about a 65% packet
>>> loss. Ssh connections are answered with delays of zero to
>>> perhaps thirty seconds. Once connected ssh is usable but
>>> erratic, with dropped characters, multi-second delays and
>>> disconnects after random intervals from minutes to hours.
>>>=20
>>> There are five other Raspberry Pi's on the network. Three
>>> Pi2's run 12.3-stable, one Pi2 runs -current
>>=20
>> RPi2 v1.2's used as aarch64? (So similar to RPi3*'s.)
> No, the Pi2s are v1.1.
>> RPi2 v1.1's (armv7)?
> Yes.

Good to know.

>=20
>> Which type of RPi3* variant? B? B+? Revision?
>>=20
> The stable/13 machine reports:
> bob@pelorus:~ % sysctl -a | grep model
> hw.model: ARM Cortex-A53 r0p4
> hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837
> hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2

A RPi3B+ would be Rev 1.3 based on the table near the
bottom of the page at:

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html

No Rev 1.2 or before for RPi3B+. The only revision
code documented for such a B+ is a020d3.

But there is such a thing as a non-+ RPi3B with Rev 1.3
as well. But most of the revision codes for them are
Rev 1.2.

I'll note that if the RPi* firmware debugging output
is enabled via config.txt then there are lines in the
output identifying the exact .dtb file that is used
as the starting point:

MESS:00:00:02.136715:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:02.140152:0: Trying Device Tree file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:02.155700:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:02.160357:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x4000 size =
0x70fb

The names are as below and indicate the plus
or not expllicitly:

bcm2710-rpi-2-b.dtb
bcm2710-rpi-3-b-plus.dtb
bcm2710-rpi-3-b.dtb
bcm2710-rpi-cm3.dtb
bcm2711-rpi-4-b.dtb
bcm2711-rpi-400.dtb
bcm2711-rpi-cm4.dtb

Enabling the debug output looks like:

enable_uart=3D1
uart_2ndstage=3D1
dtdebug=3D1

> dev.smscphy.0.%pnpinfo: oui=3D0x800f model=3D0xc rev=3D0x3
> bob@pelorus:~ %=20
>=20
> and the -current machine reports:=20
> bob@www:~ % sysctl -a | grep -i model
>      Memory Model Features 0 =3D 
>      Memory Model Features 1 =3D <8bit VMID>
>      Memory Model Features 2 =3D <32bit CCIDX,48bit VA>
> hw.model: ARM Cortex-A53 r0p4
> hw.fdt.compatible: raspberrypi,3-model-b brcm,bcm2837
> hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2

Again, if the Rev. 1.2 is accurate, it is unlikely to be
a RPi3B+ .

> dev.smscphy.0.%pnpinfo: oui=3D0x800f model=3D0xc rev=3D0x3
> bob@www:~ %=20
>=20
> That's slightly surprising, since they are of different age and
> one has WiFi, not sure which. I believe that makes one a B+ though
> I gather FreeBSD still doesn't support the on-board WiFi. Either
> way, I thought the wired ethernet setup was identical.=20
>=20

Both have WiFi: all RPi3's have WiFi.

QUOTING https://www.raspberrypi.com/products/raspberry-pi-3-model-b/ :
Specification

Raspberry Pi 3 Model B is the earliest model of the third-generation =
Raspberry Pi. It replaced Raspberry Pi 2 Model B in February 2016. See =
also Raspberry Pi 3 Model B+, the latest product in the Raspberry Pi 3 =
range.

	=E2=80=A2 Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
	=E2=80=A2 1GB RAM
	=E2=80=A2 BCM43438 wireless LAN and Bluetooth Low Energy (BLE) =
on board
. . .
END QUOTE

What was different was the vintage of WiFi for the RPi3B+ :

QUOTING =
https://www.raspberrypi.com/products/raspberry-pi-3-model-b-plus/ :
Specification

The Raspberry Pi 3 Model B+ is the final revision in the Raspberry Pi 3 =
range.

	=E2=80=A2 Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ =
1.4GHz
	=E2=80=A2 1GB LPDDR2 SDRAM
	=E2=80=A2 2.4GHz and 5GHz IEEE 802.11.b/g/n/ac wireless LAN, =
Bluetooth 4.2, BLE
. . .
END QUOTE

So RPi3B+ had 5 GhZ 802.11.n and 802.11.ac .


The one that I tested via a private network was also
a RPi3B (non-+). I do not have access to a RPi3B+ .


The RPi3B+ has different EtherNet, faster. Right hand side is
again quoting those pages:

RPI3B :	=E2=80=A2 100 Base Ethernet
RPi3B+: =E2=80=A2 Gigabit Ethernet over USB 2.0 (maximum throughput 300 =
Mbps)



>>> and a Pi4 runs
>>> -current. All have no problems pinging one another and out
>>> of network, so there's nothing obviously wrong with the net.
>>> The network is not routed, but rather a block of eight
>>> addresses simply bridged from my ISP over DSL.
>>>=20
>>> It's been found that an image of 13.1-RC4 behaves similarly
>>> on one Pi3 when on the public network but exhibits more normal
>>> ping response when moved to a 192.168.1.n private network.=20
>=20
> Just to be clear, it was the same Pi3, I  moved the cables and=20
> changed lines in /etc/rc.conf to make the switch.
>=20

Yep. I've suggested testing a RPi4B via such switching of
cables and /etc/rc.conf adjustment.

>>> On the face of it, this seems significant, but I can't guess how.
>>=20
>> Did you try a RPi4B on the public network, booted using the
>> same 13.1-RC4 microsd card you used in the RPi3* testing?
>> (Modern aarch64 RPi* images should boot either type of
>> aarch64 RPI*.)
>>=20
>=20
>> If yes, what was the behavior like? Did it behave like the
>> RPi3*?
>>=20
>> If no, it should be a good test for how specific the problem
>> is to the RPi3* vs. RPi*'s more generally.
>>=20
>=20
> I haven't tried yet, since the Pi4 was on the private network to
> begin with and it has never had problems answering ping and ssh.

The question that is left is if it would have problems on
the public network vs. not. I can not reasonably predict
that based on the private network result.

> AIUI the Pi4 ethernet is on PCIe, while the Pi3 uses USB. If the
> Pi4 failed to answer ping when running the snapshot I guess that
> would point to either faulty media or a different place in the
> network software. Perhaps worth a try.=20
>=20

Yep, that is a kind of information I was after.

>=20
>> Testing a EtherNet dongle known to use a different driver
>> could also be a form of cross check, if you happen to have
>> such available.
>=20
> My only alternative Ethernet adapter is a Ralink WiFi dongle.
> My WiFi is private-network only, and the snapshot worked reasonably
> well when wired on the private network. A wired adapter would be
> more informative, but I'll have to figure out what to order.=20

Only being able to test a private network definately limits
the utility of the such a test (WiFi test).

I'm not sure if you want to get a device just for the test
activity at this point.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun May  1 18:12:54 2022
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 189D11AC3A4B;
	Sun,  1 May 2022 18:13:04 +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 4KrvTp4gcyz3FRH;
	Sun,  1 May 2022 18:13:02 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 241ICtbk015083
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 1 May 2022 11:12:55 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 241ICsJp015082;
	Sun, 1 May 2022 11:12:54 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 1 May 2022 11:12:54 -0700
From: bob prohaska 
To: Bakul Shah 
Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org,
        bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220501181254.GA14961@www.zefox.net>
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
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: 4KrvTp4gcyz3FRH
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.49 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.994];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_SHORT(0.40)[0.401];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.81)[-0.813];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5233
Lines: 85

On Sat, Apr 30, 2022 at 06:39:57PM -0700, Bakul Shah wrote:
> On Apr 29, 2022, at 7:12 PM, bob prohaska  wrote:
> > 
> > Since about December of 2021 I've been noticing problems with
> > wired network connectivity on a pair of raspberry pi 3 machines
> > using wired network connections. One runs stable-13.1, the other
> > runs -current, both are up to date as of a few days ago.
> > 
> > Essentially both machines fail to respond to inbound network
> > connections via ssh or ping after reboot. If I get on the 
> > serial console and start an outbound ping to anywhere, both
> > machines respond to incoming pings with about a 65% packet
> > loss. 

> Suggest running tcpdump on the rpi3 to see what is going on
> when connected to the public vs private net. 
>
 
Public net first, since that's where the machine is now. Gateway.zefox.net
is the name of my router's public interface, dcn.org belongs to my isp and
fusionbroadband is their service provider..
 
While on the -current Pi3 serial console (with no outbound ping running) 
and no inbound traffic from my hosts I see after a couple minutes:

root@www:/mnt # tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ue0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:39:40.887853 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46
10:39:40.887929 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28
10:39:40.893220 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.org, length 28
10:39:40.915469 ARP, Reply 50-1-20-1.dsl.static.fusionbroadband.com is-at 00:1b:90:d2:4a:c4 (oui Unknown), length 50
10:39:40.915529 IP www.zefox.org.50714 > spoke.dcn.davis.ca.us.domain: 51409+ PTR? 28.20.1.50.in-addr.arpa. (41)
10:39:40.943602 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.50714: 51409 1/3/6 PTR www.zefox.org. (265)
10:39:40.945416 IP www.zefox.org.15986 > spoke.dcn.davis.ca.us.domain: 44966+ PTR? 31.20.1.50.in-addr.arpa. (41)
10:39:40.973487 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.15986: 44966 1/3/6 PTR gateway.zefox.net. (266)
10:39:40.975037 IP www.zefox.org.57611 > spoke.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
10:39:46.288219 IP www.zefox.org.49710 > wheel.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
10:39:46.316239 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.49710: 31749 1/3/6 PTR 50-1-20-1.dsl.static.fusionbroadband.com. (291)
10:39:46.318267 IP www.zefox.org.17061 > spoke.dcn.davis.ca.us.domain: 37579+ PTR? 2.253.150.168.in-addr.arpa. (44)
10:39:46.346851 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.17061: 37579* 1/2/2 PTR spoke.dcn.davis.ca.us. (145)
10:39:46.348674 IP www.zefox.org.40440 > spoke.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. (44)
10:39:51.420705 IP www.zefox.org.64019 > wheel.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. (44)
10:39:51.448850 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.64019: 20572* 1/2/2 PTR wheel.dcn.davis.ca.us. (145)
10:40:40.147603 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell ns1.zefox.net, length 46
10:40:40.148844 IP www.zefox.org.46127 > spoke.dcn.davis.ca.us.domain: 12186+ PTR? 29.20.1.50.in-addr.arpa. (41)
10:40:40.176486 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.46127: 12186 1/3/6 PTR ns1.zefox.net. (262)
10:40:57.688225 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46
10:40:57.688305 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28
10:42:14.488727 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46
10:42:14.488804 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28
10:42:43.761226 ARP, Request who-has 50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.com, length 46
10:42:43.762522 IP www.zefox.org.56181 > spoke.dcn.davis.ca.us.domain: 28779+ PTR? 26.20.1.50.in-addr.arpa. (41)
10:42:43.790361 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.56181: 28779 1/3/6 PTR www.zefox.com. (265)
10:43:31.289103 ARP, Request who-has www.zefox.org tell gateway.zefox.net, length 46
10:43:31.289181 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui Unknown), length 28

If I now start an inbound ping from one of my hosts it gets no reply and 
tcpdump reports no additional traffic. With an outbound ping running there's
at least a sparse reply.

^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel
root@www:/mnt # 

The "oui unknown" looks like some sort of failure.....
Can you ping www.zefox.org? I have no outside vantage point.
There is still no outbound ping running and I would expect
you'll get no or very sparse reply. 


Thus far only the two Pi3s suffer from connectivity problems; Pi2s and a Pi4 have
no difficulty on the same address block. Is there a switch for tcpdump  that will
limit records to relevant traffic? Otherwise it's a flood.

These results were obtained after standing idle overnight and
are rather different (in ways I don't understand) from behavior
immediately after reboot, I'll have to repeat as I learn more.

Thanks for reading, and any more suggestions!

bob prohaska


From nobody Sun May  1 19:15:27 2022
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 74CDD1AA9664
	for ; Sun,  1 May 2022 19:15:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4Krwt44ZJJz3NyQ
	for ; Sun,  1 May 2022 19:15:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651432533; bh=MRwZ1w2lcjUlpjjxpg3nk0cZQT79VImXffvge+s5uVE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bSnO9FIroSVmfLYs4bXe2srOSDci9VbEpli10Qz6YizsqvY7f2PqWPHKIv2KaAVM7LcN0qQlA3C3ycYbocBZSokZCEGH4QXcZ2155pjFK0PidGH6ao6OqWZLMkojIlZn7vYYGKZyx9doJWQSYXDqQfMQSo3Z7GjqOCKt9+QGDh7cmojxeEJMazAvif/ZqsZ4IM0QRVknTyi0CAPBwO8OZB6BcuUaiSZseTyYq4GTNFLgXhZZaNhO+E3pkZ68dgmXnnE+l2hOUpw+aHOQGJqPeMJAX6qDjbetGMxJO1gHOXyol0twzrhpi7ZRx9F6UFL4MxPjqfl4A9buFi7jA2crWA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651432533; bh=PBmbN1QUw9wqGGV9So3TuK0E0DnyT+hQmfojsZemsKn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tAE5+sdj3JiYkwvuLmoWse1yHgtBcjPTXTdZndvCSdBCCaAxJsUhPWJiPBOYDjcUZ9Wfirhtff3UPP7a4b16+cta0K1yS4JBfTpwZOsP2sHPJYLGdmBnIrUoj5ibYZU5lcn3VQLcxPeNQBXrleQHGMaEEu8gLcCTuse6QWZCDxHJkohvopG/8X/QcOlCKj3lGnlTUmcdKLfUSb6QlkeYspXenCEZ2Xm73SU6mNaYF76PcIcmmX9w1sz0H9XEiR8ObuVol2i/mVNVSWx7euZIUEVz24avZYVV1xd8kOMC3c4xNY4ClJviFA9T7N2nka6a79I3a/p86A8VRFHEaPs5eg==
X-YMail-OSG: E.23QzEVM1mauu_jyNW16JTFipGjxG5USm4Cbv_GASMGUc81wtSjg1L1qkCmkL5
 eeYbU.Td2gUXbOr84r9rG8U1FmgRqn.YhpqJZCJojGNKWHfBtjMvyyhUlBWkVgYlIlojpVIKXtf1
 qqHMTfHa4HaWT6CYtXMDGhZU_vns_bTyrBPY5FwaV15ZOXo5x1KJq4yHvYVs4UzF7hYf3IP46zWd
 yjKNSYjOef70bY6RST.C680T6QSPAhdR9_Z5m_UbtcKN8MA48R_ZVe7kvEsH5OOT7KIJjK9rXEpO
 oQ3DhQcyWMTDPX4cF8CJv02x381.oD8AIEhtQQ_EmYij2.oc.JrpWXl7be_lZfB.TLT5WJrh1ABc
 are_DxgbeMm16zt2dxj5SVdU7UOgW2pTd0uDzcKP12xuLW1m9Y2b8sIlZVNnC1xi7jqTqmQ6QtT9
 Hsh9AminY0TNnZG.DU426FPCvmDX7t67eUWp66LvLeZM2QNuKdyaVObkCwyx1O_pvHeeX.eNjJhS
 j426GTqDlpVoaS3TB3coFLDLnDoy906ccjRhBV6r6sJlY1b5S6a.Xxb1jQvEwbq_iPXQvY4H74mU
 TG197E0Iz9K43t6n_kjcpYWVfkWYafkXY7g08m.UoXAvuwQjYS8n9gXoI7IJ4PonxhHRi.S25aTI
 vmlvydt1vvfiF0xy.9jHiBQQxjKYwQbslU_w0.ldM2HHoHZ_Rufpg8lmQvckanxTeV1d8cdeZmjI
 Ibn6HVqsw0JAAh59tyY_5pNJoCDBz5zPpEy13qslUpXlM6uX3P64ANv6bNCrliCkAanH3gjvcIhu
 86sQi4toxaeoWirHFjoQ7ko.5SBQsLU_MVRAmsK0j2j9.5rexzYQtqRX7Nkk6UoWs7DaRS9UoOK.
 41NoUxYUfLAN_65kU5FMlim0Zt7Al25J4T600T8rNPHGdhM_q1yDGG7QkrfqPP3gJz508pnHnlFH
 GK4Rt94dgkugGIr9I2XCap4UQACuByZbkKg2CH0M5QiGt46DqEkGl5nhLjh_5UXUvkJ2QpSH47Fg
 upG2qVsG5wPg50W_Wm2ePX759ur.uacb4uS2.eM23KMKQPLTOujRY0qoXNmGBR3pl5whAWURgWu8
 LCRRGLRr0iJw8HfaE3xWP7dY4Trnfkpdiact4SqOGsIgcW5W2PFQhhi5CR9ZFnR3463PAM1_5Opq
 YBILqSRYeZhyiCFZygGMLnisZL7KxE7XNm26ZbYrpqRB1vRHH8DwTeahqHRpKtOQ.AN2FVAJ0pUq
 GyjSryR3udaxOHEk4opqFCTnOX8NboB_.fCeXE_S2NPWczm7BAyVUMBVSgL_Douv8K9.H_mGfYtB
 Ehp1xyjwOvsQTv4qwpP31aWF1JNZ4x5kzF8JZi_9XG0TEq8IruoaZo1b1KM6uVsbSDif.gy0Kc.L
 G04WazPeD.PYhQRKEsbl9pUmJzeRz5_xWcBP8thoYcqVye7hyg0QCGZd4oLGgjveGCu6Zuxms0zy
 JIBRfYwWZ1Nj2u500W14DhmqpvDTQVIe4Zp0LzH.jVtWM1eHod4FPZznnfxBs9Frz5ITaniACquy
 eQubd1Q5E0zkPnjohDXEkCqDmsOIhQaLNpZC2Nw1wl7u1v9LB2J0IgRtWRw5YN6TEK_rVmx2OHvJ
 Fam1QsjglCqMf6k5B8jzbYHMDQ0C6jJe0MSX_aLzs_urHCkIbneith3cClL7UmZ5.dewBByyQlKp
 7xRvKVIBMWvcAFTXxGx2Vpl1hLOG0eA92gzOEmA4oNBIdibeBvEYJAzR8ilE_WtHWWVm.etQp20P
 bOPhhNNNQVhc10TcMgZcwlbyAjVU_3i2IunFVKO7oLxVVvyvZ2bIkZJ5.3Ki_BDwovNNzEeJ7_D1
 XCSL2G0iiELYx63Kzx4E2M01tFDFxhGNcYETgVeHjlit4_lEgU9qEF_IOxq4qOibYoYy24pd6Eyg
 rXpL8DwYpVQoa5w4wC.ArPq76JZsjyobA1MPhxeJn9a5N.YUynnH8T5z98nX8LNDu3LEhiJApgL7
 PyMvKXABay6.kwQZ_S6Vq0F6RmwxhSGs7ui_YXhZ6EIkBsTLfygoXg0pt8LgYiW1YbxuVXb4FfeF
 3f26q8kiKnhdySUgHRaD_6eWBeX2nd6u2j5rVMm1CNBHSG3LDtVe2X.sfOpad7BFwuCkttR.l5c1
 AoElYR31BwSzae9MlMRxaN0dXD.SAkAZcCgFSl2y2ckybezXoxb3Gu6ktNky1r2p_EYy0mXPrdne
 7XiOjSDkV.HgqSxi1fX5l4sNehGtnIHOX1_L0UwkEBpLTQQti0ib90aRJ4Qe_BbFtYdpbprq.vHK
 r6v1aaF1IRP2Cc5nC88IIwRdPTjfjxKX59e7_
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 May 2022 19:15:33 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-b7pn2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 424593ac6b261432aef943d9ee0e71a2;
          Sun, 01 May 2022 19:15:30 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <20220501181254.GA14961@www.zefox.net>
Date: Sun, 1 May 2022 12:15:27 -0700
Cc: Bakul Shah ,
 freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Krwt44ZJJz3NyQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bSnO9FIr;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.37 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.88)[-0.876];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8934
Lines: 215


On 2022-May-1, at 11:12, bob prohaska  wrote:

> On Sat, Apr 30, 2022 at 06:39:57PM -0700, Bakul Shah wrote:
>> On Apr 29, 2022, at 7:12 PM, bob prohaska  wrote:
>>>=20
>>> Since about December of 2021 I've been noticing problems with
>>> wired network connectivity on a pair of raspberry pi 3 machines
>>> using wired network connections. One runs stable-13.1, the other
>>> runs -current, both are up to date as of a few days ago.
>>>=20
>>> Essentially both machines fail to respond to inbound network
>>> connections via ssh or ping after reboot. If I get on the=20
>>> serial console and start an outbound ping to anywhere, both
>>> machines respond to incoming pings with about a 65% packet
>>> loss.=20
>=20
>> Suggest running tcpdump on the rpi3 to see what is going on
>> when connected to the public vs private net.=20
>>=20
>=20
> Public net first, since that's where the machine is now. =
Gateway.zefox.net
> is the name of my router's public interface, dcn.org belongs to my isp =
and
> fusionbroadband is their service provider..
>=20
> While on the -current Pi3 serial console (with no outbound ping =
running)=20
> and no inbound traffic from my hosts I see after a couple minutes:
>=20
> root@www:/mnt # tcpdump
> tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
> listening on ue0, link-type EN10MB (Ethernet), capture size 262144 =
bytes
> 10:39:40.887853 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
> 10:39:40.887929 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
> 10:39:40.893220 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.org, length 28
> 10:39:40.915469 ARP, Reply 50-1-20-1.dsl.static.fusionbroadband.com =
is-at 00:1b:90:d2:4a:c4 (oui Unknown), length 50
> 10:39:40.915529 IP www.zefox.org.50714 > spoke.dcn.davis.ca.us.domain: =
51409+ PTR? 28.20.1.50.in-addr.arpa. (41)
> 10:39:40.943602 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.50714: =
51409 1/3/6 PTR www.zefox.org. (265)
> 10:39:40.945416 IP www.zefox.org.15986 > spoke.dcn.davis.ca.us.domain: =
44966+ PTR? 31.20.1.50.in-addr.arpa. (41)
> 10:39:40.973487 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.15986: =
44966 1/3/6 PTR gateway.zefox.net. (266)
> 10:39:40.975037 IP www.zefox.org.57611 > spoke.dcn.davis.ca.us.domain: =
31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
> 10:39:46.288219 IP www.zefox.org.49710 > wheel.dcn.davis.ca.us.domain: =
31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
> 10:39:46.316239 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.49710: =
31749 1/3/6 PTR 50-1-20-1.dsl.static.fusionbroadband.com. (291)
> 10:39:46.318267 IP www.zefox.org.17061 > spoke.dcn.davis.ca.us.domain: =
37579+ PTR? 2.253.150.168.in-addr.arpa. (44)
> 10:39:46.346851 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.17061: =
37579* 1/2/2 PTR spoke.dcn.davis.ca.us. (145)
> 10:39:46.348674 IP www.zefox.org.40440 > spoke.dcn.davis.ca.us.domain: =
20572+ PTR? 1.253.150.168.in-addr.arpa. (44)
> 10:39:51.420705 IP www.zefox.org.64019 > wheel.dcn.davis.ca.us.domain: =
20572+ PTR? 1.253.150.168.in-addr.arpa. (44)
> 10:39:51.448850 IP wheel.dcn.davis.ca.us.domain > www.zefox.org.64019: =
20572* 1/2/2 PTR wheel.dcn.davis.ca.us. (145)
> 10:40:40.147603 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell ns1.zefox.net, length 46
> 10:40:40.148844 IP www.zefox.org.46127 > spoke.dcn.davis.ca.us.domain: =
12186+ PTR? 29.20.1.50.in-addr.arpa. (41)
> 10:40:40.176486 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.46127: =
12186 1/3/6 PTR ns1.zefox.net. (262)
> 10:40:57.688225 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
> 10:40:57.688305 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
> 10:42:14.488727 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
> 10:42:14.488804 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
> 10:42:43.761226 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.com, length 46
> 10:42:43.762522 IP www.zefox.org.56181 > spoke.dcn.davis.ca.us.domain: =
28779+ PTR? 26.20.1.50.in-addr.arpa. (41)
> 10:42:43.790361 IP spoke.dcn.davis.ca.us.domain > www.zefox.org.56181: =
28779 1/3/6 PTR www.zefox.com. (265)
> 10:43:31.289103 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
> 10:43:31.289181 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
>=20
> If I now start an inbound ping from one of my hosts it gets no reply =
and=20
> tcpdump reports no additional traffic. With an outbound ping running =
there's
> at least a sparse reply.
>=20
> ^C
> 28 packets captured
> 28 packets received by filter
> 0 packets dropped by kernel
> root@www:/mnt #=20
>=20
> The "oui unknown" looks like some sort of failure.....
> Can you ping www.zefox.org? I have no outside vantage point.
> There is still no outbound ping running and I would expect
> you'll get no or very sparse reply.=20
>=20
>=20
> Thus far only the two Pi3s suffer from connectivity problems; Pi2s and =
a Pi4 have
> no difficulty on the same address block. Is there a switch for tcpdump =
 that will
> limit records to relevant traffic? Otherwise it's a flood.
>=20
> These results were obtained after standing idle overnight and
> are rather different (in ways I don't understand) from behavior
> immediately after reboot, I'll have to repeat as I learn more.

I wonder if there is a notable difference between
monitoring traffic from 2 places:

A) from the machine seeing the problem
vs.
B) from a machine not having problems but
   connected were all the traffic would be
   on the wire it is connected to.

It may be that monitoring from both and
comparing/contrasting the reported traffic
from the two provides additional evidence.

There may be modes of monitoring that are
relevant for this. But I'm not familiar
with any detail here.


For reference:

# ping www.zefox.org
PING www.zefox.org (50.1.20.28): 56 data bytes
^C
--- www.zefox.org ping statistics ---
32 packets transmitted, 0 packets received, 100.0% packet loss

I found the command traceroute and it reports:

# traceroute www.zefox.org
traceroute to www.zefox.org (50.1.20.28), 64 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  0.697 ms  0.486 ms  1.277 ms
 2  172.30.26.66 (172.30.26.66)  30.019 ms
    172.30.26.67 (172.30.26.67)  41.720 ms
    172.30.26.66 (172.30.26.66)  28.645 ms
 3  68.85.243.125 (68.85.243.125)  8.967 ms
    68.85.243.77 (68.85.243.77)  11.462 ms
    68.85.243.125 (68.85.243.125)  10.254 ms
 4  24.124.129.106 (24.124.129.106)  7.510 ms
    96.216.60.165 (96.216.60.165)  10.176 ms
    24.124.129.106 (24.124.129.106)  8.945 ms
 5  68.85.243.197 (68.85.243.197)  10.837 ms
    96.216.60.165 (96.216.60.165)  10.252 ms
    68.85.243.197 (68.85.243.197)  16.036 ms
 6  68.85.243.197 (68.85.243.197)  14.660 ms
    be-36211-cs01.seattle.wa.ibone.comcast.net (68.86.93.49)  14.629 ms
    68.85.243.197 (68.85.243.197)  8.849 ms
 7  be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142)  14.607 ms
    be-36221-cs02.seattle.wa.ibone.comcast.net (68.86.93.53)  14.122 ms
    be-2212-pe12.seattle.wa.ibone.comcast.net (96.110.34.134)  13.877 ms
 8  be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142)  14.133 ms =
*  13.663 ms
 9  be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233)  30.176 ms *
    be3717.ccr22.sfo01.atlas.cogentco.com (154.54.86.209)  29.002 ms
10  be3717.ccr22.sfo01.atlas.cogentco.com (154.54.86.209)  28.477 ms
    be2430.ccr31.sjc04.atlas.cogentco.com (154.54.88.186)  27.203 ms
    be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233)  28.515 ms
11  38.104.141.82 (38.104.141.82)  29.820 ms
    be2430.ccr31.sjc04.atlas.cogentco.com (154.54.88.186)  28.605 ms
    38.104.141.82 (38.104.141.82)  33.735 ms
12  38.104.141.82 (38.104.141.82)  27.160 ms
    0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net (135.180.179.146)  32.336 ms
    38.104.141.82 (38.104.141.82)  31.867 ms
13  0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.761 ms
    0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net (135.180.179.146)  29.864 ms
    0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.711 ms
14  0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  30.373 ms
    gig1-1-1.gw.wscrca11.sonic.net (50.1.36.106)  35.567 ms
    0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.146 ms
15  gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  31.513 ms
    gig1-1-1.gw.wscrca11.sonic.net (50.1.36.106)  31.203 ms
    gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  31.354 ms
16  gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  30.125 ms *  31.996 ms
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
^C

(There did not seem to be much point in having it continue.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun May  1 19:58:45 2022
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 7C8151AB42F1
	for ; Sun,  1 May 2022 19:59:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4Krxr435ZYz3nBv
	for ; Sun,  1 May 2022 19:59:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651435133; bh=YqL15O//ahapUUTBmjAUTjGUBGQR/SvdyCc37yCbMoo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IoDQ/FVx4UginihBKIbclJHnwBIs3Xo/YeIvrm8P9w4YoYkIHPH4ky9hJg5s7OlImehBOzVoWOpYSydQhNRl3HfJjBxSUfvsO8JOMreZHh4Lj7nDRfdlTF+MkbNEwWybbI1k0HpKx+6eMC2mWGds/YSFa8HxU99CNQ06IZG/WgNC3veI2GjD55x9XGB3wf1T7lkSSEMf3hq5AAJl1d+9/x/udSxT4CMhqDx5/6nGdZwG0gurqIqUySPLZVuk4J7Ur7qDhAZ/GjQTv3+0oYlGYw85FzI+7abs4N8/RGa3Dav6ZzH2Xf7hSbUFI2uAp7BSTuLhaGczhu6SXxsFKpzAsg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651435133; bh=JIRIfhNGfpfZQqbVrBN0yuDb9PoGU4Gvd57q56QshJ+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EAdZe3bMLALHiL1ZDC8Hm0GL7qbIUUy3/drr9BdVbq/Tt0f53SOT7kic0BYurhxnUHYCTmMXM5XnlKheRKnNdrF1QGX7ecPpP1tcRtB150V7onBz+TYpOpUFdbHm1dOJLhmcYzCPURipQInyqKhelq1cyp45B8pXwZsLVeEK9qiaewoF0XKcca16CoqrZm+trdzv0ZtdkfwCojkLJtegtk0BY0lX+NWLIhiZzf5jhwSIFWeH2oBu4onoWuD1blRCeZ6QkHW8vddB95br9y+h+yYTyG235RQidAc63daj3seumTnun+EDnY0kOfXScEbA4QjyAMANn80cGVbEeKWtxQ==
X-YMail-OSG: gmH4OdkVM1nDsoJt1xRU27Wcgr13SDxYPEb0Hk1SaMjXPdRxAxoY1pqo_UhiazP
 pIZ2o7hjBJGfoOrmk4Kn8ciHW1B0UyypOuSCDbX9iq3dKcVaBFU.zH17IyG0EwWXIQmwz9zHhK4y
 PUKrc_u6.DnmhQLg.YBmv84s4SEhAY5arnv54dHEUsl3dyQ304IZo3Xslnoyqx6ITO2PdKfnOPmU
 An6flMNG7a.Z3yYbyVrSSgZw.73Psyy8m2t1QwmgDUj_NqNEW5fRim18AVv9zMhoTsSQydVIbgDA
 rZzXKljAflMCTimnZjFWxB.QFhtqfVkgofM4TS0XU5cHC6Ox6wFiDZkpyEpmO5qGMuUKl_jGzzAZ
 NBwYB7TRiXcf4YhDgnbf4kt5A8qsnF0Ilj5KsdXH4xV3KUaePJCtPAopSz03UtBCR2qkuIzgRGH9
 Bl2OnAtwPpzA2gJZSM58uKp0qD8U8.hcDXMPFsZhyiagU45MTf.On7HeiqYw3CwYlF14OZEyVKay
 m0xojUqM5sFmuww5q9_9Y1R5L40YMn8828uNLzcqs1SmrjgFnCXkdtIg4JqxhSp1oSa3M21ZJRBe
 3FyiDJQ5bkCjCWh8CoAyMlTbEAZUyC5sz9ErJWM2YIbtmxezMzB_jrD9yDy7ZWDyaU8UyOQg.dq2
 _22Ejzz0.EWdXLoc9Ny1gSBUtBw1Js0JXwyYl0b9UJDVJpTsMjYIXbkDg.4.wcPYD6_rm52djOMg
 crbMM.dm8FEUBJm_vizKcUBnYiuDDgYPbd_2qG5IUo3Cy7MiPD_X7umxcoFAjX9PwefpAu_1Llhi
 BSmkuwRBGprdQyixS6n0zVj2ugtBRyIk4UE1mMsbxp0mAkukG997FEpvNQv_FCs0CSipOOEoH952
 TV.V1vUlsg1wCP9vjTVoob5QQJmJ5oPLjWzEym1EKv8BlVodCmiFnrfb1OWJLxjj3hDXUh.uOxM4
 zuN3TwuqbG1zNe1nJ83BtZkHek5JJ78hzJSyi_vAD8KiJZirAqbgaUiN8sWvcMhwoO5VM9Lq7PdN
 P36EFes.K.zgBDhAAM7vmcqoqS7.t9oYpOxRiVwxszOMojQiC2LxTiNU0U3eO8GpJclUuoct0c5f
 jJvr.ryQJ5X5hlJAXBYnk3t6TnpaXvaxd6Rd6krnGc3CCsgOiYmr0q2sBLWzswCtgRbRViZ7ZVVV
 jIZXrWkaclEFswm8aPwLkEMlQhwBS5Ec028IcLCLQL3YCMsEcW.Lrum4.l0m2ODp1xrQx92oZE0s
 OrYLn_so1.2AhTwMuUPHpd9BmtLjFYXicGnKHUAvCFTMJoFJ4qlM.bnj4OdyefLHEyn_cL7qAL14
 44KZv953t2a8PonUfa0KpfLPEV4bht2hyarQRSASk2VH2836F_By6rBptDUY0NE073ssDmMGFBMj
 n2jRDRGopY_qeFUq2jwTTzaKGwUgcPsXOg7Ug9_Tekz653sCOQm5EaDxCMFWcDhponIP2O9.R18q
 GqNJl_AD77VMPbQG0tSUgayQYHz3AnrCqzSCuKx4pbAvpdvgt0eo4MoQxdtC2cpTdS48jZLl8kr6
 t.ms.0kZ5tiKz4JIad_C_xFiH5JwILQ6cRuhXm0kiDJoJS1LiUMBuF233nvv5aArlhDbR134ctOd
 ZI2ugl5XoR73wu4UAqoN88VJLxsTmwS7.stMBb083qyvFF1krFm5fwceVGzFhOqvFrtvS94ii2o0
 NxnaGvakyFn2GbRv3q7f_NB93A1xJgiMJTuiGX7DhhRYTKtYcGGn6VujzFJN95rpPU_o2zx_kWrB
 kFqZ_MmkZXBm7gSM9gSK_iSm1e.teL.nrjlvLFiA.UAsnRMB5MV8XkNqX900OqOfSXB3WALY4NmI
 Ljay8gm0T0UqGZF897TXJoPZcd5r.f1PgJKd9szoA8EVMii0_xDU2MJLXboPIlTWsAV3ANLKEfjR
 VNKDx9nB5NC2CyVMVwburdqr5LWndggACn31BLP8Uf4rKyN8t2cCx.dFFiOYgAu9PD2J0UFFCYGr
 uDmY_1.wYNYbuCuMkEWkEraFKuEkLZAdJ3ngMkrqaCjHL__76U4lIgHg9vyGjsr.MGSu3yvMiFdD
 u9NIlEG_vAb9yYOZoT_fGu2UNPH03IwEv5Q0wNMlU9qMnVO4mkc5wKz_6Aq5rUgKo3zr9SqiuS2m
 7ZUW3PGqB4cVj5FcUpOA1DcVwSrWGnlvkNfZKRQ5ELghPYGKQflaQu84jbjYUOcsfB25R32068K1
 jTB7i04PVsH.FEm5_uVExrd5MkZ908LWOouAh81ujcntbRHtPUV7rk8lGF_v9Lb4UbNw.wirteHr
 YN.gV_JTgtqWYcRThaoq9CqSs2rH1XQBdT1CoMw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 May 2022 19:58:53 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-vklcv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c1c82fa307f3cf7d85b42bad5ff9548f;
          Sun, 01 May 2022 19:58: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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: 
Date: Sun, 1 May 2022 12:58:45 -0700
Cc: Bakul Shah ,
 freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Krxr435ZYz3nBv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="IoDQ/FVx";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11779
Lines: 288

On 2022-May-1, at 12:15, Mark Millard  wrote:


> On 2022-May-1, at 11:12, bob prohaska  wrote:
>=20
>> On Sat, Apr 30, 2022 at 06:39:57PM -0700, Bakul Shah wrote:
>>> On Apr 29, 2022, at 7:12 PM, bob prohaska  =
wrote:
>>>>=20
>>>> Since about December of 2021 I've been noticing problems with
>>>> wired network connectivity on a pair of raspberry pi 3 machines
>>>> using wired network connections. One runs stable-13.1, the other
>>>> runs -current, both are up to date as of a few days ago.
>>>>=20
>>>> Essentially both machines fail to respond to inbound network
>>>> connections via ssh or ping after reboot. If I get on the=20
>>>> serial console and start an outbound ping to anywhere, both
>>>> machines respond to incoming pings with about a 65% packet
>>>> loss.=20
>>=20
>>> Suggest running tcpdump on the rpi3 to see what is going on
>>> when connected to the public vs private net.=20
>>>=20
>>=20
>> Public net first, since that's where the machine is now. =
Gateway.zefox.net
>> is the name of my router's public interface, dcn.org belongs to my =
isp and
>> fusionbroadband is their service provider..
>>=20
>> While on the -current Pi3 serial console (with no outbound ping =
running)=20
>> and no inbound traffic from my hosts I see after a couple minutes:
>>=20
>> root@www:/mnt # tcpdump
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol =
decode
>> listening on ue0, link-type EN10MB (Ethernet), capture size 262144 =
bytes
>> 10:39:40.887853 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
>> 10:39:40.887929 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
>> 10:39:40.893220 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.org, length 28
>> 10:39:40.915469 ARP, Reply 50-1-20-1.dsl.static.fusionbroadband.com =
is-at 00:1b:90:d2:4a:c4 (oui Unknown), length 50
>> 10:39:40.915529 IP www.zefox.org.50714 > =
spoke.dcn.davis.ca.us.domain: 51409+ PTR? 28.20.1.50.in-addr.arpa. (41)
>> 10:39:40.943602 IP spoke.dcn.davis.ca.us.domain > =
www.zefox.org.50714: 51409 1/3/6 PTR www.zefox.org. (265)
>> 10:39:40.945416 IP www.zefox.org.15986 > =
spoke.dcn.davis.ca.us.domain: 44966+ PTR? 31.20.1.50.in-addr.arpa. (41)
>> 10:39:40.973487 IP spoke.dcn.davis.ca.us.domain > =
www.zefox.org.15986: 44966 1/3/6 PTR gateway.zefox.net. (266)
>> 10:39:40.975037 IP www.zefox.org.57611 > =
spoke.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
>> 10:39:46.288219 IP www.zefox.org.49710 > =
wheel.dcn.davis.ca.us.domain: 31749+ PTR? 1.20.1.50.in-addr.arpa. (40)
>> 10:39:46.316239 IP wheel.dcn.davis.ca.us.domain > =
www.zefox.org.49710: 31749 1/3/6 PTR =
50-1-20-1.dsl.static.fusionbroadband.com. (291)
>> 10:39:46.318267 IP www.zefox.org.17061 > =
spoke.dcn.davis.ca.us.domain: 37579+ PTR? 2.253.150.168.in-addr.arpa. =
(44)
>> 10:39:46.346851 IP spoke.dcn.davis.ca.us.domain > =
www.zefox.org.17061: 37579* 1/2/2 PTR spoke.dcn.davis.ca.us. (145)
>> 10:39:46.348674 IP www.zefox.org.40440 > =
spoke.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. =
(44)
>> 10:39:51.420705 IP www.zefox.org.64019 > =
wheel.dcn.davis.ca.us.domain: 20572+ PTR? 1.253.150.168.in-addr.arpa. =
(44)
>> 10:39:51.448850 IP wheel.dcn.davis.ca.us.domain > =
www.zefox.org.64019: 20572* 1/2/2 PTR wheel.dcn.davis.ca.us. (145)
>> 10:40:40.147603 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell ns1.zefox.net, length 46
>> 10:40:40.148844 IP www.zefox.org.46127 > =
spoke.dcn.davis.ca.us.domain: 12186+ PTR? 29.20.1.50.in-addr.arpa. (41)
>> 10:40:40.176486 IP spoke.dcn.davis.ca.us.domain > =
www.zefox.org.46127: 12186 1/3/6 PTR ns1.zefox.net. (262)
>> 10:40:57.688225 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
>> 10:40:57.688305 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
>> 10:42:14.488727 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
>> 10:42:14.488804 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
>> 10:42:43.761226 ARP, Request who-has =
50-1-20-1.dsl.static.fusionbroadband.com tell www.zefox.com, length 46
>> 10:42:43.762522 IP www.zefox.org.56181 > =
spoke.dcn.davis.ca.us.domain: 28779+ PTR? 26.20.1.50.in-addr.arpa. (41)
>> 10:42:43.790361 IP spoke.dcn.davis.ca.us.domain > =
www.zefox.org.56181: 28779 1/3/6 PTR www.zefox.com. (265)
>> 10:43:31.289103 ARP, Request who-has www.zefox.org tell =
gateway.zefox.net, length 46
>> 10:43:31.289181 ARP, Reply www.zefox.org is-at b8:27:eb:71:46:4e (oui =
Unknown), length 28
>>=20
>> If I now start an inbound ping from one of my hosts it gets no reply =
and=20
>> tcpdump reports no additional traffic. With an outbound ping running =
there's
>> at least a sparse reply.
>>=20
>> ^C
>> 28 packets captured
>> 28 packets received by filter
>> 0 packets dropped by kernel
>> root@www:/mnt #=20
>>=20
>> The "oui unknown" looks like some sort of failure.....
>> Can you ping www.zefox.org? I have no outside vantage point.
>> There is still no outbound ping running and I would expect
>> you'll get no or very sparse reply.=20
>>=20
>>=20
>> Thus far only the two Pi3s suffer from connectivity problems; Pi2s =
and a Pi4 have
>> no difficulty on the same address block. Is there a switch for =
tcpdump  that will
>> limit records to relevant traffic? Otherwise it's a flood.
>>=20
>> These results were obtained after standing idle overnight and
>> are rather different (in ways I don't understand) from behavior
>> immediately after reboot, I'll have to repeat as I learn more.
>=20
> I wonder if there is a notable difference between
> monitoring traffic from 2 places:
>=20
> A) from the machine seeing the problem
> vs.
> B) from a machine not having problems but
>   connected were all the traffic would be
>   on the wire it is connected to.
>=20
> It may be that monitoring from both and
> comparing/contrasting the reported traffic
> from the two provides additional evidence.
>=20
> There may be modes of monitoring that are
> relevant for this. But I'm not familiar
> with any detail here.
>=20
>=20
> For reference:
>=20
> # ping www.zefox.org
> PING www.zefox.org (50.1.20.28): 56 data bytes
> ^C
> --- www.zefox.org ping statistics ---
> 32 packets transmitted, 0 packets received, 100.0% packet loss
>=20
> I found the command traceroute and it reports:
>=20
> # traceroute www.zefox.org
> traceroute to www.zefox.org (50.1.20.28), 64 hops max, 40 byte packets
> 1  192.168.1.1 (192.168.1.1)  0.697 ms  0.486 ms  1.277 ms
> 2  172.30.26.66 (172.30.26.66)  30.019 ms
>    172.30.26.67 (172.30.26.67)  41.720 ms
>    172.30.26.66 (172.30.26.66)  28.645 ms
> 3  68.85.243.125 (68.85.243.125)  8.967 ms
>    68.85.243.77 (68.85.243.77)  11.462 ms
>    68.85.243.125 (68.85.243.125)  10.254 ms
> 4  24.124.129.106 (24.124.129.106)  7.510 ms
>    96.216.60.165 (96.216.60.165)  10.176 ms
>    24.124.129.106 (24.124.129.106)  8.945 ms
> 5  68.85.243.197 (68.85.243.197)  10.837 ms
>    96.216.60.165 (96.216.60.165)  10.252 ms
>    68.85.243.197 (68.85.243.197)  16.036 ms
> 6  68.85.243.197 (68.85.243.197)  14.660 ms
>    be-36211-cs01.seattle.wa.ibone.comcast.net (68.86.93.49)  14.629 ms
>    68.85.243.197 (68.85.243.197)  8.849 ms
> 7  be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142)  14.607 =
ms
>    be-36221-cs02.seattle.wa.ibone.comcast.net (68.86.93.53)  14.122 ms
>    be-2212-pe12.seattle.wa.ibone.comcast.net (96.110.34.134)  13.877 =
ms
> 8  be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142)  14.133 =
ms *  13.663 ms
> 9  be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233)  30.176 ms *
>    be3717.ccr22.sfo01.atlas.cogentco.com (154.54.86.209)  29.002 ms
> 10  be3717.ccr22.sfo01.atlas.cogentco.com (154.54.86.209)  28.477 ms
>    be2430.ccr31.sjc04.atlas.cogentco.com (154.54.88.186)  27.203 ms
>    be2075.ccr21.sfo01.atlas.cogentco.com (154.54.0.233)  28.515 ms
> 11  38.104.141.82 (38.104.141.82)  29.820 ms
>    be2430.ccr31.sjc04.atlas.cogentco.com (154.54.88.186)  28.605 ms
>    38.104.141.82 (38.104.141.82)  33.735 ms
> 12  38.104.141.82 (38.104.141.82)  27.160 ms
>    0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net (135.180.179.146)  32.336 ms
>    38.104.141.82 (38.104.141.82)  31.867 ms
> 13  0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.761 ms
>    0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net (135.180.179.146)  29.864 ms
>    0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.711 ms
> 14  0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  30.373 ms
>    gig1-1-1.gw.wscrca11.sonic.net (50.1.36.106)  35.567 ms
>    0.xe-0-0-0.cr1.scrmca13.sonic.net (135.180.179.166)  31.146 ms
> 15  gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  31.513 ms
>    gig1-1-1.gw.wscrca11.sonic.net (50.1.36.106)  31.203 ms
>    gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  31.354 ms
> 16  gig1-1-1.gw.davsca11.sonic.net (50.1.36.110)  30.125 ms *  31.996 =
ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
> ^C
>=20
> (There did not seem to be much point in having it continue.)

I found and built a port called net/mtr-nox11
("My traceroute") and tried it, letting it just
run. The initial try eventually got a connection
but reported a 99.2% packet loss as of when I
captured the below:

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> www.zefox.org (50.1.20.28)          =
2022-05-01T12:40:22-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                 Packets               =
Pings
 Host                                          Loss%   Snt   Last   Avg  =
Best  Wrst StDev
 1. 192.168.1.1                                 0.0%   135    0.4   0.8  =
 0.1   3.1   0.4
 2. 172.30.26.66                                0.0%   134   28.2  26.1  =
 9.3 132.7  18.1
 3. 68.85.243.77                                0.0%   134    8.6   9.0  =
 7.5  11.2   0.8
 4. 24.124.129.106                              0.0%   134   10.2   9.1  =
 7.6  13.4   0.9
 5. 96.216.60.165                               0.0%   134    9.0   9.1  =
 7.8  14.3   0.9
 6. 68.85.243.197                               0.0%   134   14.4  13.6  =
 9.2  44.3   5.4
 7. be-36241-cs04.seattle.wa.ibone.comcast.net  0.0%   134   16.8  14.9  =
13.0  22.6   1.1
 8. be-2412-pe12.seattle.wa.ibone.comcast.net   0.0%   134   13.5  15.0  =
12.8  46.4   3.2
 9. (waiting for reply)
10. be2075.ccr21.sfo01.atlas.cogentco.com       0.0%   134   29.3  29.0  =
26.7  54.1   2.9
11. be2379.ccr31.sjc04.atlas.cogentco.com       0.0%   134   28.0  28.7  =
27.1  40.3   1.3
12. 38.104.141.82                               0.0%   134   28.0  33.8  =
26.6 114.8  16.5
13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net      0.0%   134   30.9  31.0  =
29.0  33.7   0.8
14. 0.xe-0-0-0.cr1.scrmca13.sonic.net           0.0%   134   31.1  32.3  =
29.3  93.2   6.7
15. gig1-1-1.gw.wscrca11.sonic.net              0.0%   134   31.3  34.9  =
29.5 330.4  26.5
16. gig1-1-1.gw.davsca11.sonic.net              0.0%   134   32.8  32.1  =
29.9  44.1   1.7
17. (waiting for reply)
18. (waiting for reply)
19. www.zefox.org                              99.2%   134   74.9  74.9  =
74.9  74.9   0.0

I stopped and restarted it and so far no connection
-- waiting even longer than that first time: Snt
is now over 600. Rows 18 and 19 have not shown up,
the last is 17.

. . . (some more time goes by) . . .

I have now stopped it, avoiding the extra load on the
machines and network.

Looks like there is some problem getting past
gig1-1-1.gw.davsca11.sonic.net .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun May  1 21:00:42 2022
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 756CC199B881
	for ; Sun,  1 May 2022 21:00:44 +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 4KrzCG5J0fz4RYB
	for ; Sun,  1 May 2022 21:00:42 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 7FC661CF01
	for ; Sun,  1 May 2022 21:00:42 +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 241L0gUb022829
	for ; Sun, 1 May 2022 21:00:42 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 241L0gEp022828
	for freebsd-arm@FreeBSD.org; Sun, 1 May 2022 21:00:42 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202205012100.241L0gEp022828@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, 1 May 2022 21:00:42 +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="16514388422.fB3A.19341"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1651438843;
	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=GCUR/Ny7FkSuyM2vK+MFU6RTawtKD9sZ6/TrqY4iU68=;
	b=jSuSBr7FiIGTSyQL2sXQEfFCt02X8TW5CG5eWiq64mSagJAUP5o3c4CIHtr4rpZgrgVZQa
	iNWTprqyAk/rWMJpLfT50BkpKo57rZHiRGGm0/1I2z4vNaNc1ND4JB3c8BAJLS0tPtRRjy
	gfEtvzGZJBUw7aNGyY7+zKbsotudQez8WtO+vnwYRCP1ZVRM8EhlR6Sh+X4qLcJXm/E1TM
	hL6Rtc6CIUvgBEw/uwEsM22bd3R4/Im2F3n0a8RMiootYhjlB5Y93h3xZZjMh/cUPhJrFK
	QMV0zvY3SjLtGyhlVMXDTnUoMcvnanXBoiUwO5i9+5IgpkZqdCrY5ihfyu6HLw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651438843; a=rsa-sha256; cv=none;
	b=JzUbboUoafP2E93Q7Cf9k7BS3IBgcz1bz+uO+zy/hoRsoUx7xHXgoPDKLtvzGVibjVwzhE
	HFH4T5HILuCDJCEEbFEu1cou1gA4IRkVZPF3k+n29UPfNPd7Ps3E1aJ6mWzGjNt7knHBR1
	rlan7QaGg5Y0Yn91irtCm56b3hf/V4tzEm5DuBIfxC2f72FOmnJJBh48WabxU2uMkxVGY3
	nAY5Rzi/n7LdL++m60rjENX8xD7Ptd7UMMQFMu/KFBhglRnzMqGF3fzcEkdFHHUL/XmfHG
	i7UzoaA44/HmEAllFR/UOf7EEOEUYykGWEWteJsf/9hAScDiDtVFXeRRmrC/aQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1793
Lines: 38


--16514388422.fB3A.19341
Date: Sun, 1 May 2022 21:00:42 +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.

--16514388422.fB3A.19341
Date: Sun, 1 May 2022 21:00:42 +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.


--16514388422.fB3A.19341--

From nobody Sun May  1 23:27:57 2022
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 4C2641AC2246;
	Sun,  1 May 2022 23:28:01 +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 4Ks2TD0V8bz4pBf;
	Sun,  1 May 2022 23:27:59 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 241NRwds015768
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 1 May 2022 16:27:58 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 241NRvQZ015767;
	Sun, 1 May 2022 16:27:57 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 1 May 2022 16:27:57 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Bakul Shah , freebsd-net@freebsd.org,
        freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220501232757.GA15446@www.zefox.net>
References: <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
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: 4Ks2TD0V8bz4pBf
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.47 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.57)[0.568];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1432
Lines: 35

On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
> 
> Looks like there is some problem getting past
> gig1-1-1.gw.davsca11.sonic.net .
> 

That seems independent of my own internal connection problems,
but worth taking up with my ISP on Monday. Meanwhile, can you
ping any other hosts in the 50.1.20.31-24 range? All are up
at the moment. Hosts 28 and 24 are the troublemakers. 

If anybody cares there's an ascii-art network diagram at
http://www.zefox.net/~fbsd/netmap

Not sure it'll survive the mailing list, but here goes:
dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation
                      |                  |             | 
                      |                  |             |---Mac workstation
                      |                  |
                      |                  |------printer
    ------------------|
    |
    |------50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial----50.1.20.27
    |------50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial----50.1.20.30
    |------50.1.20.27 www.zefox.net Pi2 12.3 usb-serial----50.1.20.26
    |------50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24
    |------50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
 switch
    |------50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29
    |------50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25

Thanks for your help!

bob prohaska
 

From nobody Mon May  2 00:10:59 2022
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 D8C1E1AAA5A8
	for ; Mon,  2 May 2022 00:11:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4Ks3R34Tc0z4srV
	for ; Mon,  2 May 2022 00:11:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651450264; bh=tPK4dcRWPwYGf6dAkV1T/XUjDHqAQr/nGxUjev+Bd6I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Xcv4yb+rdbI8Pc2ZWJHRtOlGbAqAcsOpt5vgbHyGaJTVJEVezej9lFJ4u0DSQiVSrlhM+LztsFeFrv1V6wV4yZ5MJkdajDNMmvSqBJjEHyKTicmAMpZ2CpaFkVIe9vU/+bUU7x33mj4wC6aHvkr//gu1BAG13/vl+tt/8alprkVoO1jmlUrKJmrYzojbs/PWVuP+SH2by0aitLncYZp60qzFbygqNTuoWlILJoSjLr49KH9I84SdhDaS7x8HOiDkbyl9CbH/riISDUdHATNQ+UY//Qx9YTVk9lb+3JeyT2b1hTImiT9qZYDA/iILnVw412dY98MxhddGStrjBg27Qg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651450264; bh=xZQJr822VxBVAYTyC5emn3QRhYOcxVvDmT6BlaPxqvR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dnKnXHXk5WOoLqp4mNj0hG/xZsBGeXBsKgNqDtno+ld1QoQI09BpT9TwLMe8otGJgGR02qv2DzHtl04fhMauSdn1mLLl9G1mPudwpnC5eAMgsLaGkzhrLtai4TO+MIwtfH83XDf+3zBj2A4BK8Jdt8PUVpklRjK4cceJ44aN0dyRQYYgNBsUiF0pMYqz39ONevVVPk97MwztSXKe2TbR2sMR31oZ9fOltcrghWbNYiljoewvyROanaytVIZ2M9muao5tAOpQjmezmyhMv/Mz/G6d6amm+mYcNiuiHRoLzCtfFlAmDEx4Y+3ZZb2Tn3NTEq8/XBLtaWU8iOb2/nYkzg==
X-YMail-OSG: EFjYKP4VM1lKHVst1ks_sajk_n4k7Qk1oKfcxzBQaygHG7MJHzvwHDHT.0Z74eW
 m16BXsrRcukbgYuAE7OtfeXnUVPhrfxVMIbdTaunh2OweU2EoIWKBWJ0ZkG1NFzbgzvTHPvCX2in
 7nZ65dmUqP4xcqeBvjaNHwn2gT3ynq5Yj4MCBViNAZn2euWctWdg2Qs3PXeiHULoFy2juYa4Aip7
 uqfwvz2FAvQ8s7ylmbZOb9ilMlcyTslA58Ac8m_QmrXem_9sgd5QBTN2H5TWZ7LZJOUJ8dQ9gAho
 XYVS.hAjfj432LbmHg5pWvoaw3WQouWSJlmYcv_gSDHnK7sGPsgLIGEjeMY12HOxi6JIbR90F3z1
 LEjOphw569TFX8USp41Ja56lhmmMuFkObEnnPIkMDDm158bHH1jwHmOIp2dye.JCOYee8brmfb3S
 phTKye_BspuwsvQBO66iuyK9D15Qu2cU46ogpfOqHwb4E1UjlytxpdXong2YFdiF_s1OfTIzFAZ2
 6xa3eJjzTpfs8_LXhk1Bj1a7bw9tKkIl4hcEnfqD.rGkpkGVwlRnn7oNRqXDzvViw9RTcBv5CUwg
 TrMZbA9cObsGOyA0NQdhT9mZ4xIF_sKFvWTIxj7.VPSd5xDIbqJNvyblUl5f8tpA.BSwYv7cdxK4
 72FbFSYBRN5o3Kld7MytOI97KEeDUgVSwdX.iff4OQnzJnlksHqSTalR7_I9TYlQqFRDPJYM6WLa
 a16pZai55euF6woGj60M7PnShGOlXXs2cyFXgF9pmFen3qpZ5eKCdpiWk6mDzDYRHkjuXevm9Nve
 fu25pKOD1rDsSM3OYFqYzEft5iqyNQfZsVhylFvzpocYx1ov.2f5M7s568rJ7Zz7rsnc.ickriRr
 RwYAGcNu5vkoay.XvGAe6nzr.C5QYaQlM_EhmHje0lW66jK53LL7P7wQyG8A7K2HkXkLaYb1kweL
 FMza8ozrLDMV2oGo8fOc0fDkTWrc65K7OxdItH6y.cR1jNtOP05b4GwYOoE0eMP68jeWY7_aqPBs
 w5CdqvfPBrmShsOWQGsU50LZi7ryq2AVgTj7rlFk83kp9sLttyh_UC5Ruvv9xFIeYYYs4Q0lXM3z
 ECkiPEXLST326gIbG4EitYXyVaVVrcdYHtrUIjPfqCxmEMzoArdyf4T9dFP9B00UJgh9ffMp1xjM
 z6_oC.kTmC4eUU2Us5O9TVFlMKz8NSRTE0ss9ZS0cyXAGdmwJz0wFHWSYEZM1tocoyPlIYWQ_j2C
 LNHIg_HE_lE3TTnYGaNKkllr5LCQSraQkx8deG2BjQF_JKDhnX.qy_X_zrO0JFL3cldRgE5CNaJe
 _CXruOIRb_1zXYZ6XA1Baw4gW_zE5LspIF4eNd2ZjZyWZX3BTgkW75h5_omkv8V.p_tnC9grmsbT
 O7A3eKKsiNEKZ99MJprKVJL5rsmZ2QY6KWmcRxAcOYjBixzvnaPPzGEcJty3SOJIpt2ZbhIjPi02
 JFinZETPWmePfQGkNG7WYEwREGB3OnGCQVqbJdSl53ScPqhT2.Kkodc2k2vjQA4Hl9_nxSKYqtTQ
 keM2An1h.sWIqlXbH58r1LcZksMcKV.Z7YkTQpuGxTacuPnGdiE5hPkrpeezR_RQ2Ye97I85HBwe
 pXd5kPWZJK2rb8AYWobT4YDNakdyCa0qQJ_YDYu1EY72WkcJOa39WLw.RLPuBaLx6FDWRpSWsu4e
 ZLIeM9c6j_fhyXF704Lio3_jfl5PD9xtJAHY..RvWXJN_0e2TGUfakQrjxD1LtAJzQzobf3sAqDI
 U2Ohzwcx0iK6dfip3w5LZ.zUbfvUJ9Hd6H_Nl_Ahr1LHPF4tBuA3mjQeREMmAE5nQoBagYXJTJSJ
 _zuv1hlXrbwijzlGBzt0Ws2IkzjUmFucAdWScmnx8R5.XoBYWTii433hcGQZec09iRyTiudv8rp4
 _IDJFCp04LilCyGGY3z_EyrDMCLzY9dGQzH.8uUVplZh38YzXXBZCAwjfms.n.6EaJT.o_ndCMZj
 uAru5OnQ24fpqWKNCvtV6XDMLOw6fexozRb64kBkwRCxri5gNThl4tITogNSRgGA2BytQ6EaS_ya
 jTLPEZrauEmjxfTAJhIriA5hRxMqKWXr7fv1xNv9ULOsl769v7toF_jOIHOgffI0qrQAgzMdG9DC
 J1a7o54phBM3EbfKT.SZBLiEjDGOMqA_dU3QDyco.odr1wuszcYWolLvSQ5CqnhLxUaxg_z56oxx
 D8iHKas9PiMv95tw58UdZDgfYvQ6UgqLlUo8BGtwBc_iItIfY51NqZ4wmnpOGokKMH_HEjnQ.Hj6
 fqpcexxUS_8nbQP0Ecl4XTcd2PQMb2KQtZI6jiqE-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 May 2022 00:11:04 +0000
Received: by hermes--canary-production-bf1-5f4c6455f8-b7pn2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72a04ab74f4f51ae853b38b24726f7ad;
          Mon, 02 May 2022 00:11:02 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <20220501232757.GA15446@www.zefox.net>
Date: Sun, 1 May 2022 17:10:59 -0700
Cc: Bakul Shah ,
 freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
References: <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ks3R34Tc0z4srV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Xcv4yb+r;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6729
Lines: 181

On 2022-May-1, at 16:27, bob prohaska  wrote:

> On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
>>=20
>> Looks like there is some problem getting past
>> gig1-1-1.gw.davsca11.sonic.net .
>>=20
>=20
> That seems independent of my own internal connection problems,
> but worth taking up with my ISP on Monday. Meanwhile, can you
> ping any other hosts in the 50.1.20.31-24 range? All are up
> at the moment. Hosts 28 and 24 are the troublemakers.=20
>=20
> If anybody cares there's an ascii-art network diagram at
> http://www.zefox.net/~fbsd/netmap
>=20
> Not sure it'll survive the mailing list, but here goes:
> =
dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation=

>                      |                  |             |=20
>                      |                  |             |---Mac =
workstation
>                      |                  |
>                      |                  |------printer
>    ------------------|
>    |
>    |------50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial----50.1.20.27
>    |------50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial----50.1.20.30
>    |------50.1.20.27 www.zefox.net Pi2 12.3 usb-serial----50.1.20.26
>    |------50.1.20.26 www.zefox.com Pi2 -current =
usb-serial---50.1.20.24
>    |------50.1.20.24 pelorus.zefox.org Pi3 13.1 =
usb-serial---50.1.20.28
> switch
>    |------50.1.20.25 nemesis.zefox.com Pi4 -current =
usb-serial---50.1.20.29
>    |------50.1.20.28 www.zefox.org Pi3 -current =
usb-serial----50.1.20.25


For ns1.zefox.net there is no problem and
it looks like:

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29)                =
2022-05-01T16:52:27-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets           =
    Pings
 Host                                                Loss%   Snt   Last  =
 Avg  Best  Wrst StDev
 1. 192.168.1.1                                       0.0%    53    1.2  =
 0.8   0.1   1.4   0.4
 2. 172.30.26.67                                      0.0%    53   11.8  =
25.0  11.8  61.0  11.4
 3. 68.85.243.125                                     0.0%    53   10.0  =
10.0   7.7  46.9   5.3
 4. 96.216.60.165                                     0.0%    53    8.8  =
 9.3   7.8  12.1   0.9
 5. 68.85.243.197                                     0.0%    53    8.6  =
13.2   8.6  28.3   4.2
 6. be-36231-cs03.seattle.wa.ibone.comcast.net        0.0%    53   15.3  =
14.8  13.0  16.9   1.0
 7. be-2312-pe12.seattle.wa.ibone.comcast.net         0.0%    53   16.2  =
15.9  12.9  59.8   6.5
 8. (waiting for reply)
 9. be3717.ccr22.sfo01.atlas.cogentco.com             0.0%    53   29.8  =
30.9  26.5  97.9  10.1
10. be2430.ccr31.sjc04.atlas.cogentco.com             0.0%    53   29.0  =
29.0  26.6  39.3   1.8
11. 38.104.141.82                                     0.0%    53   28.9  =
33.8  26.1 115.0  17.0
12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    53   32.1  =
31.3  29.2  33.9   1.0
13. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    53   30.5  =
32.1  29.2  57.6   4.3
14. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    53   31.8  =
32.0  28.8  43.7   2.0
15. gig1-1-1.gw.davsca11.sonic.net                    0.0%    52   31.0  =
32.4  30.2  38.4   1.4
16. ns1.zefox.net                                     0.0%    52   51.4  =
51.1  49.8  53.4   0.8

ns2.zefox.net and others got a 17. instead of
a 16. An example is:

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30)                =
2022-05-01T16:58:45-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets           =
    Pings
 Host                                                Loss%   Snt   Last  =
 Avg  Best  Wrst StDev
 1. 192.168.1.1                                       0.0%    55    0.3  =
 0.9   0.1   1.4   0.4
 2. 172.30.26.66                                      0.0%    55   13.5  =
26.4  10.4  54.7  10.1
 3. 68.85.243.77                                      0.0%    55   10.5  =
 9.1   7.9  10.5   0.6
 4. 24.124.129.106                                    0.0%    54    8.3  =
 9.5   8.2  13.4   1.0
 5. 96.216.60.165                                     0.0%    54    8.8  =
 9.8   7.8  22.8   2.2
 6. 68.85.243.197                                     0.0%    54   17.1  =
15.1   9.0  37.3   5.9
 7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    54   15.2  =
15.0  13.2  17.8   0.9
 8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    54   15.0  =
14.8  13.2  17.1   1.0
 9. (waiting for reply)
10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    54   28.4  =
29.2  26.9  36.8   1.4
11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    54   29.8  =
30.0  27.3  84.2   7.6
12. 38.104.141.82                                     0.0%    54   28.6  =
33.7  27.5 105.5  16.2
13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    54   31.6  =
31.4  29.5  33.8   0.9
14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    54   31.1  =
32.1  29.1  52.9   3.4
15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    54   31.2  =
31.9  30.0  34.1   0.9
16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    54   33.3  =
32.6  30.8  45.8   2.1
17. ns2.zefox.net                                     0.0%    54   52.5  =
51.4  49.1  54.9   1.2

The routing need not be the same from one
try to the next.

www.zefox.net     is similar.
www.zefox.com     is similar.
pelorus.zefox.org is similar.
nemesis.zefox.com is similar.
www.zefox.org     is similar.

Notably www.zefox.org was what I tried and
reported on before that had the failures.

I observed a initial connection sequence once
for pelorus.zefox.org where it briefly displayed
something like (not captured, just from memory):

16. gig1-1-1.gw.davsca11.sonic.net
17. (waiting for reply)
18. (waiting for reply)
19. pelorus.zefox.org

before changing to

16. gig1-1-1.gw.davsca11.sonic.net
17. ns2.zefox.net

That may be normal but usually timed such that I
would not usually see it.

But it might actually be evidence of a stage that
the leads to the overall failure by never getting
past the:

16. gig1-1-1.gw.davsca11.sonic.net
17. (waiting for reply)
18. (waiting for reply)
19. WHATEVER

in some cases.

However, in the above the below worked fine:

50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25

What changed?


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon May  2 01:13:12 2022
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 2371B1AB58DE;
	Mon,  2 May 2022 01:13: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 4Ks4pf28Thz3GNM;
	Mon,  2 May 2022 01:13:14 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2421DC8W016061
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 1 May 2022 18:13:13 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2421DCWd016060;
	Sun, 1 May 2022 18:13:12 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 1 May 2022 18:13:12 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Bakul Shah , freebsd-net@freebsd.org,
        freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220502011312.GA15807@www.zefox.net>
References: <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@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: <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
X-Rspamd-Queue-Id: 4Ks4pf28Thz3GNM
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.01 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.978];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.93)[-0.932];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7365
Lines: 152

On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote:
[reply at end]
> On 2022-May-1, at 16:27, bob prohaska  wrote:
> 
> > On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
> >> 
> >> Looks like there is some problem getting past
> >> gig1-1-1.gw.davsca11.sonic.net .
> >> 
> > 
> > That seems independent of my own internal connection problems,
> > but worth taking up with my ISP on Monday. Meanwhile, can you
> > ping any other hosts in the 50.1.20.31-24 range? All are up
> > at the moment. Hosts 28 and 24 are the troublemakers. 
> > 
> > If anybody cares there's an ascii-art network diagram at
> > http://www.zefox.net/~fbsd/netmap
> > 
> > Not sure it'll survive the mailing list, but here goes:
> > dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation
> >                      |                  |             | 
> >                      |                  |             |---Mac workstation
> >                      |                  |
> >                      |                  |------printer
> >    ------------------|
> >    |
> >    |------50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial----50.1.20.27
> >    |------50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial----50.1.20.30
> >    |------50.1.20.27 www.zefox.net Pi2 12.3 usb-serial----50.1.20.26
> >    |------50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24
> >    |------50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
> > switch
> >    |------50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29
> >    |------50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
> 
> 
> For ns1.zefox.net there is no problem and
> it looks like:
> 
>                                      My traceroute  [v0.95]
> amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29)                2022-05-01T16:52:27-0700
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>                                                        Packets               Pings
>  Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 192.168.1.1                                       0.0%    53    1.2   0.8   0.1   1.4   0.4
>  2. 172.30.26.67                                      0.0%    53   11.8  25.0  11.8  61.0  11.4
>  3. 68.85.243.125                                     0.0%    53   10.0  10.0   7.7  46.9   5.3
>  4. 96.216.60.165                                     0.0%    53    8.8   9.3   7.8  12.1   0.9
>  5. 68.85.243.197                                     0.0%    53    8.6  13.2   8.6  28.3   4.2
>  6. be-36231-cs03.seattle.wa.ibone.comcast.net        0.0%    53   15.3  14.8  13.0  16.9   1.0
>  7. be-2312-pe12.seattle.wa.ibone.comcast.net         0.0%    53   16.2  15.9  12.9  59.8   6.5
>  8. (waiting for reply)
>  9. be3717.ccr22.sfo01.atlas.cogentco.com             0.0%    53   29.8  30.9  26.5  97.9  10.1
> 10. be2430.ccr31.sjc04.atlas.cogentco.com             0.0%    53   29.0  29.0  26.6  39.3   1.8
> 11. 38.104.141.82                                     0.0%    53   28.9  33.8  26.1 115.0  17.0
> 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    53   32.1  31.3  29.2  33.9   1.0
> 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    53   30.5  32.1  29.2  57.6   4.3
> 14. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    53   31.8  32.0  28.8  43.7   2.0
> 15. gig1-1-1.gw.davsca11.sonic.net                    0.0%    52   31.0  32.4  30.2  38.4   1.4
> 16. ns1.zefox.net                                     0.0%    52   51.4  51.1  49.8  53.4   0.8
> 
> ns2.zefox.net and others got a 17. instead of
> a 16. An example is:
> 
>                                      My traceroute  [v0.95]
> amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30)                2022-05-01T16:58:45-0700
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>                                                        Packets               Pings
>  Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 192.168.1.1                                       0.0%    55    0.3   0.9   0.1   1.4   0.4
>  2. 172.30.26.66                                      0.0%    55   13.5  26.4  10.4  54.7  10.1
>  3. 68.85.243.77                                      0.0%    55   10.5   9.1   7.9  10.5   0.6
>  4. 24.124.129.106                                    0.0%    54    8.3   9.5   8.2  13.4   1.0
>  5. 96.216.60.165                                     0.0%    54    8.8   9.8   7.8  22.8   2.2
>  6. 68.85.243.197                                     0.0%    54   17.1  15.1   9.0  37.3   5.9
>  7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    54   15.2  15.0  13.2  17.8   0.9
>  8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    54   15.0  14.8  13.2  17.1   1.0
>  9. (waiting for reply)
> 10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    54   28.4  29.2  26.9  36.8   1.4
> 11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    54   29.8  30.0  27.3  84.2   7.6
> 12. 38.104.141.82                                     0.0%    54   28.6  33.7  27.5 105.5  16.2
> 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    54   31.6  31.4  29.5  33.8   0.9
> 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    54   31.1  32.1  29.1  52.9   3.4
> 15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    54   31.2  31.9  30.0  34.1   0.9
> 16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    54   33.3  32.6  30.8  45.8   2.1
> 17. ns2.zefox.net                                     0.0%    54   52.5  51.4  49.1  54.9   1.2
> 
> The routing need not be the same from one
> try to the next.
> 
> www.zefox.net     is similar.
> www.zefox.com     is similar.
> pelorus.zefox.org is similar.
> nemesis.zefox.com is similar.
> www.zefox.org     is similar.
> 
> Notably www.zefox.org was what I tried and
> reported on before that had the failures.
> 
> I observed a initial connection sequence once
> for pelorus.zefox.org where it briefly displayed
> something like (not captured, just from memory):
> 
> 16. gig1-1-1.gw.davsca11.sonic.net
> 17. (waiting for reply)
> 18. (waiting for reply)
> 19. pelorus.zefox.org
> 
> before changing to
> 
> 16. gig1-1-1.gw.davsca11.sonic.net
> 17. ns2.zefox.net
> 
> That may be normal but usually timed such that I
> would not usually see it.
> 
> But it might actually be evidence of a stage that
> the leads to the overall failure by never getting
> past the:
> 
> 16. gig1-1-1.gw.davsca11.sonic.net
> 17. (waiting for reply)
> 18. (waiting for reply)
> 19. WHATEVER
> 
> in some cases.
> 
> However, in the above the below worked fine:
> 
> 50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
> 50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
> 
> What changed?

I restarted an outgoing ping so I could access those hosts via ssh, 
to bring up a serial console connection to the next host in the "ring". 
Usually I simply ping 50.1.20.31 (my router) but at least in the past
it did not matter what the destination was. In one case I tried an
unused address. That makes the role of a distant host somewhat
baffling.

Thanks for checking!

bob prohaska

> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

From nobody Mon May  2 06:56:12 2022
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 75CA4199AC2B;
	Mon,  2 May 2022 06:56:19 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KsDQT5SHRz4Zpb;
	Mon,  2 May 2022 06:56:17 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B39C326021A;
	Mon,  2 May 2022 08:56:14 +0200 (CEST)
Message-ID: <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
Date: Mon, 2 May 2022 08:56:12 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Content-Language: en-US
To: bob prohaska , Mark Millard 
Cc: Bakul Shah , freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
References: <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
 <20220502011312.GA15807@www.zefox.net>
From: Hans Petter Selasky 
In-Reply-To: <20220502011312.GA15807@www.zefox.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KsDQT5SHRz4Zpb
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.27 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.972];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-net];
	 FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7544
Lines: 152

On 5/2/22 03:13, bob prohaska wrote:
> On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote:
> [reply at end]
>> On 2022-May-1, at 16:27, bob prohaska  wrote:
>>
>>> On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
>>>>
>>>> Looks like there is some problem getting past
>>>> gig1-1-1.gw.davsca11.sonic.net .
>>>>
>>>
>>> That seems independent of my own internal connection problems,
>>> but worth taking up with my ISP on Monday. Meanwhile, can you
>>> ping any other hosts in the 50.1.20.31-24 range? All are up
>>> at the moment. Hosts 28 and 24 are the troublemakers.
>>>
>>> If anybody cares there's an ascii-art network diagram at
>>> http://www.zefox.net/~fbsd/netmap
>>>
>>> Not sure it'll survive the mailing list, but here goes:
>>> dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation
>>>                       |                  |             |
>>>                       |                  |             |---Mac workstation
>>>                       |                  |
>>>                       |                  |------printer
>>>     ------------------|
>>>     |
>>>     |------50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial----50.1.20.27
>>>     |------50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial----50.1.20.30
>>>     |------50.1.20.27 www.zefox.net Pi2 12.3 usb-serial----50.1.20.26
>>>     |------50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24
>>>     |------50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
>>> switch
>>>     |------50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29
>>>     |------50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
>>
>>
>> For ns1.zefox.net there is no problem and
>> it looks like:
>>
>>                                       My traceroute  [v0.95]
>> amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29)                2022-05-01T16:52:27-0700
>> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>>                                                         Packets               Pings
>>   Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
>>   1. 192.168.1.1                                       0.0%    53    1.2   0.8   0.1   1.4   0.4
>>   2. 172.30.26.67                                      0.0%    53   11.8  25.0  11.8  61.0  11.4
>>   3. 68.85.243.125                                     0.0%    53   10.0  10.0   7.7  46.9   5.3
>>   4. 96.216.60.165                                     0.0%    53    8.8   9.3   7.8  12.1   0.9
>>   5. 68.85.243.197                                     0.0%    53    8.6  13.2   8.6  28.3   4.2
>>   6. be-36231-cs03.seattle.wa.ibone.comcast.net        0.0%    53   15.3  14.8  13.0  16.9   1.0
>>   7. be-2312-pe12.seattle.wa.ibone.comcast.net         0.0%    53   16.2  15.9  12.9  59.8   6.5
>>   8. (waiting for reply)
>>   9. be3717.ccr22.sfo01.atlas.cogentco.com             0.0%    53   29.8  30.9  26.5  97.9  10.1
>> 10. be2430.ccr31.sjc04.atlas.cogentco.com             0.0%    53   29.0  29.0  26.6  39.3   1.8
>> 11. 38.104.141.82                                     0.0%    53   28.9  33.8  26.1 115.0  17.0
>> 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    53   32.1  31.3  29.2  33.9   1.0
>> 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    53   30.5  32.1  29.2  57.6   4.3
>> 14. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    53   31.8  32.0  28.8  43.7   2.0
>> 15. gig1-1-1.gw.davsca11.sonic.net                    0.0%    52   31.0  32.4  30.2  38.4   1.4
>> 16. ns1.zefox.net                                     0.0%    52   51.4  51.1  49.8  53.4   0.8
>>
>> ns2.zefox.net and others got a 17. instead of
>> a 16. An example is:
>>
>>                                       My traceroute  [v0.95]
>> amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30)                2022-05-01T16:58:45-0700
>> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>>                                                         Packets               Pings
>>   Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
>>   1. 192.168.1.1                                       0.0%    55    0.3   0.9   0.1   1.4   0.4
>>   2. 172.30.26.66                                      0.0%    55   13.5  26.4  10.4  54.7  10.1
>>   3. 68.85.243.77                                      0.0%    55   10.5   9.1   7.9  10.5   0.6
>>   4. 24.124.129.106                                    0.0%    54    8.3   9.5   8.2  13.4   1.0
>>   5. 96.216.60.165                                     0.0%    54    8.8   9.8   7.8  22.8   2.2
>>   6. 68.85.243.197                                     0.0%    54   17.1  15.1   9.0  37.3   5.9
>>   7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    54   15.2  15.0  13.2  17.8   0.9
>>   8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    54   15.0  14.8  13.2  17.1   1.0
>>   9. (waiting for reply)
>> 10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    54   28.4  29.2  26.9  36.8   1.4
>> 11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    54   29.8  30.0  27.3  84.2   7.6
>> 12. 38.104.141.82                                     0.0%    54   28.6  33.7  27.5 105.5  16.2
>> 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    54   31.6  31.4  29.5  33.8   0.9
>> 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    54   31.1  32.1  29.1  52.9   3.4
>> 15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    54   31.2  31.9  30.0  34.1   0.9
>> 16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    54   33.3  32.6  30.8  45.8   2.1
>> 17. ns2.zefox.net                                     0.0%    54   52.5  51.4  49.1  54.9   1.2
>>
>> The routing need not be the same from one
>> try to the next.
>>
>> www.zefox.net     is similar.
>> www.zefox.com     is similar.
>> pelorus.zefox.org is similar.
>> nemesis.zefox.com is similar.
>> www.zefox.org     is similar.
>>
>> Notably www.zefox.org was what I tried and
>> reported on before that had the failures.
>>
>> I observed a initial connection sequence once
>> for pelorus.zefox.org where it briefly displayed
>> something like (not captured, just from memory):
>>
>> 16. gig1-1-1.gw.davsca11.sonic.net
>> 17. (waiting for reply)
>> 18. (waiting for reply)
>> 19. pelorus.zefox.org
>>
>> before changing to
>>
>> 16. gig1-1-1.gw.davsca11.sonic.net
>> 17. ns2.zefox.net
>>
>> That may be normal but usually timed such that I
>> would not usually see it.
>>
>> But it might actually be evidence of a stage that
>> the leads to the overall failure by never getting
>> past the:
>>
>> 16. gig1-1-1.gw.davsca11.sonic.net
>> 17. (waiting for reply)
>> 18. (waiting for reply)
>> 19. WHATEVER
>>
>> in some cases.
>>
>> However, in the above the below worked fine:
>>
>> 50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
>> 50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
>>
>> What changed?
> 
> I restarted an outgoing ping so I could access those hosts via ssh,
> to bring up a serial console connection to the next host in the "ring".
> Usually I simply ping 50.1.20.31 (my router) but at least in the past
> it did not matter what the destination was. In one case I tried an
> unused address. That makes the role of a distant host somewhat
> baffling.
> 
> Thanks for checking!
> 
> bob prohaska

Hi,

Did you try to force the link mode to 100MBit/s ?

--HPS


From nobody Mon May  2 07:12:32 2022
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 1E815199EC14;
	Mon,  2 May 2022 07:12:41 +0000 (UTC)
	(envelope-from SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KsDnN28mlz4cyL;
	Mon,  2 May 2022 07:12:40 +0000 (UTC)
	(envelope-from SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 2 May 2022 09:12:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1651475552;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=A16vVfhMfEoAYggRR+Imh1ZJxgh0vUqG8c4E1J1W6gk=;
	b=V24BOJwSyTPGCDHJ1QNMTT5pv0kohxtrNup3EFv/WkUNmcq23Shz5BWU9RveDmJ+v3GI8x
	ioMRtl/sYbDYbygQdBY+QHbFBwerqjIq8dbwCuz9O+HUaKt+ZWryZDO3BrnCfruXV/DCrO
	qcuOpb6Y/qO+tMuDB+tXHuRTebdsIPTfqkLKCtMGFiqBDt13zUEMAN7GQbVOicLRXqxOkj
	rzoomppct2312Iwl5mkldGXWQpU1IImhXRpaPuz+aYrOUW0YQ5MGg0UWfU44HDLevHfROx
	w/eoBrRgsFqS+uog/StTk1USwjRCzwpr900BVtIzdQ2o/p/syrkvJF9imc1WfQ==
From: Ronald Klop 
To: =?UTF-8?Q?Mika=C3=ABl_Urankar?= 
Cc: freebsd-java@freebsd.org, freebsd-arm@freebsd.org,
	Greg Lewis 
Message-ID: <1486531687.70.1651475552058@localhost>
In-Reply-To: <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org>
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
 
 <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org>
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
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="----=_Part_69_117772946.1651475551978"
X-Mailer: Realworks (605.17.96b9091)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KsDnN28mlz4cyL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=V24BOJwS;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-2.97 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-0.79)[-0.794];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.98)[-0.976];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MID_RHS_NOT_FQDN(0.50)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=990L=VK=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3469
Lines: 103

------=_Part_69_117772946.1651475551978
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

=20
Van: "Mika=C3=ABl Urankar" 
Datum: zondag, 1 mei 2022 17:56
Aan: Ronald Klop 
Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for open=
jdk17-17.0.2+8.1 in configure
>=20
> On 30/04/2022 15:49, Ronald Klop wrote:
> > Hi,
> >
> > Openjdk17 and openjdk13 are failing on 130arm64.
> >
> > This started in March, I don't see a bug report in Bugzilla about it.
> > Openjdk17 is a LTS version so it would be nice to have that one fixed. =
> Openjdk13 is deprecated so don't bother about that one but mentioning > i=
s because it might be related.
> >
> > Below the openjdk17 log.
> >
> > The build for main-arm64 had the same error: (IPv6:) > http://ampere2.n=
yi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/error=
s/openjdk17-17.0.2+8.1.log
> >
> > Regards,
> > Ronald.
>=20
> Hi,
>=20
> It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D26018=
7
> =20
>=20
>=20
>=20


Hi,

Thanks for sharing your memory of closed issues!

Would the port need something like this?

ELF_FEATURES=3D       noaslr:bootstrap-openjdk17/bin/java

Maybe with a conditional on aarch64.

Regards,
Ronald.
=20
------=_Part_69_117772946.1651475551978
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: "Mikaël Urankar" <mikael@FreeBSD.org>

Datum: zondag, 1 mei 2022 17:56

Aan: Ronald Klop <ronald-lists@klop.ws>

Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for openjdk17-17.0.2+8.1 in configure







On 30/04/2022 15:49, Ronald Klop wrote:

> Hi,

>

> Openjdk17 and openjdk13 are failing on 130arm64.

>

> This started in March, I don't see a bug report in Bugzilla about it.

> Openjdk17 is a LTS version so it would be nice to have that one fixed. > Openjdk13 is deprecated so don't bother about that one but mentioning > is because it might be related.

>

> Below the openjdk17 log.

>

> The build for main-arm64 had the same error: (IPv6:) > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log

>

> Regards,

> Ronald.



Hi,



It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260187

 










Hi,



Thanks for sharing your memory of closed issues!



Would the port need something like this?



ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java



Maybe with a conditional on aarch64.



Regards,

Ronald.

 
------=_Part_69_117772946.1651475551978--

From nobody Mon May  2 07:44:48 2022
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 5E8681AAD98A
	for ; Mon,  2 May 2022 07:44:52 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a])
	(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 4KsFVW4YqJz4hGB
	for ; Mon,  2 May 2022 07:44:51 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Received: by mail-qt1-x82a.google.com with SMTP id o18so10571271qtk.7
        for ; Mon, 02 May 2022 00:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=iitbombay-org.20210112.gappssmtp.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=UXu0yBEgfYb2Oury5m8G32LkmCHdlzaA9FRGIG6+1RI=;
        b=gjEhHFngW5+vwoLMRrn3ET5pXpa3Qw3d7Slrl2mmQkHXRcZfjs8v+OJeF+89lTD0xx
         L9sH/1cMrnt6m2n5ThM424srMhAfHuF4Zts4a+APTSbZwM88hgpaNkD2ghSp5H8Pd51F
         NDactss/yUnLUr8DyjOVZaWRyTYsXhCKbxWeWy8nsFttAPedLqKUueVbzAzR2+cEoX1s
         8tkXHDYFusXZ4eoL3C837GOgEq6PE8UqET/vs5FJsvm7rN5lFW7aZMLXIun3Yu9KQGns
         SjOSvFMkz+/q3b/y7qKXYJL0UUPqMURgHIrqhG1DjHVslor+BQ3JC1nDY2wiUoZWo9AL
         xZbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=UXu0yBEgfYb2Oury5m8G32LkmCHdlzaA9FRGIG6+1RI=;
        b=Utn6vH+HjzkxBoYmzfQ7z98yl2SOpplkH3RFJ7HkPKa+lyq+YaN8X9FoPs4j50ASBb
         Wo6M6gZM58g7Z37bRGo7m8h+4onKREulQ/EOvMrzH63x544OK3D2MgDTW0KAKxXMry8Z
         UCfl9YTSsgewOL+Aak+s7j4s7/IuNOyRGwsTxTl0SWbGsQs0jd9Ml4SaRtHbCq5HNbZj
         pCKenpQvyZmq+BAs3wgstitijyLR2yUdlNuXL0kjTMQWCkMr5fTBQ1msyidF8ba7VKvJ
         +A5ptWgpriZX0TIyJg1WlEpYo0mmeKdt3FB5o+CXdVGroCMS2IMbBeMFt4QGZxiS8G8b
         WiCQ==
X-Gm-Message-State: AOAM531UDs/WphufiI8+N6oiFfPjigG5yv6XcY515CHN49sm0d5bhwDW
	V8BmY8jQxDToUOvZB/sb2wBgVg==
X-Google-Smtp-Source: ABdhPJzTs/jyJVffjtyMe6Pd/izF11/UVvWnenknV2Oj2gNlWr9OQ/y4+kCvVLwOxLDg1Y5PWdHQYg==
X-Received: by 2002:aed:3148:0:b0:2ed:55a5:7a92 with SMTP id 66-20020aed3148000000b002ed55a57a92mr9345783qtg.104.1651477490738;
        Mon, 02 May 2022 00:44:50 -0700 (PDT)
Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229])
        by smtp.gmail.com with ESMTPSA id c14-20020ac853ce000000b002f39b99f67fsm3766562qtq.25.2022.05.02.00.44.49
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 02 May 2022 00:44:49 -0700 (PDT)
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 \(3696.80.82.1.1\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Bakul Shah 
In-Reply-To: <20220501181254.GA14961@www.zefox.net>
Date: Mon, 2 May 2022 00:44:48 -0700
Cc: freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <82F25CEE-9C9C-4CCD-9A59-A4448C37DA95@iitbombay.org>
References: 
 <20220314010330.GA70447@www.zefox.net>
 <9FA3F874-2987-44A2-A987-F905E78CCA65@yahoo.com>
 <20220428023226.GA5666@www.zefox.net>
 <8A57B411-AA06-47F4-935D-EDF45D8DF0EC@yahoo.com>
 <70C2DF4B-D08B-491D-B7B5-1EAD0D1BF0E3@yahoo.com>
 <20220429005206.GA1171@www.zefox.net>
 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Rspamd-Queue-Id: 4KsFVW4YqJz4hGB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=gjEhHFng;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=bakul@iitbombay.org
X-Spamd-Result: default: False [-1.29 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112];
	 FREEFALL_USER(0.00)[bakul];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[iitbombay.org];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.71)[0.705];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1513
Lines: 43

On May 1, 2022, at 11:12 AM, bob prohaska  wrote:
> The "oui unknown" looks like some sort of failure.....

Just ignore. tcpdump couldn't identify the vendor.

Your tcpdump trace didn't give me anything useful.
One suggestion is to use -n flag so that tcpdump
doesn't do DNS resolution! Better, just use "-w file"
so that you capture a trace and then can filter it
different ways along with "-r file".

Create separate files for when connected to the public
vs private net.

> Can you ping www.zefox.org? I have no outside vantage point.
> There is still no outbound ping running and I would expect
> you'll get no or very sparse reply.

Looks like you are a sonic.net customer? If so see if you can
get shell access on sonic. Then you can ping your hosts "from
the outside"!

Earlier I saw some packet loss. Right now I don't see any.

> Thus far only the two Pi3s suffer from connectivity problems; Pi2s and =
a Pi4 have
> no difficulty on the same address block. Is there a switch for tcpdump =
 that will
> limit records to relevant traffic? Otherwise it's a flood.

When see packet loss, do you see any IO errors when you do
"netstat -ni ue0"? Also check if your resolv.conf is set right
as well as your gateway.

> These results were obtained after standing idle overnight and
> are rather different (in ways I don't understand) from behavior
> immediately after reboot, I'll have to repeat as I learn more.
>=20
> Thanks for reading, and any more suggestions!
>=20
> bob prohaska
>=20


From nobody Mon May  2 08:49:31 2022
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 991041AB9D26;
	Mon,  2 May 2022 08:49:44 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.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 (4096 bits) client-digest SHA256)
	(Client CN "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KsGxM2qWZz4p9M;
	Mon,  2 May 2022 08:49:43 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Date: Mon, 02 May 2022 08:49:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail2; t=1651481375;
	bh=sNybVuKPxHy0LR7qkI9AJdEKxppkOR7t0v1Dl54ILks=;
	h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
	 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
	 Message-ID;
	b=EHG+DE1udFzVrJ9AbVxKDlghUReSyPQD1dg1ACMrsiZTyEzPMXQnu5FLRAMVpa+ff
	 cuAGjIcI1YJBzLgjrsYhtMfXUb9TQfRtboXsJbPseJnNXHs5tFayJma/vzTxIFNA+j
	 zrbIbxlPJ5kPMGnyrLFgPsPeSJ6FBgpexk07Zx1Vi2CuEsbRBDlEqvrC5Hf+QMyY43
	 mWLRTs6nS685KKDmC2R5kMIyPw/MY+JohJ6Qc5B2PGaFD6lF0f72iwAifAIPyYU6QP
	 TaTpWA7iP4AsC9lw+1qptG9O7W16FSf9UhEuEdfOhHS8tAKwrRF4HeSg6ZTqS/1Apb
	 6S/lufA3TZCeQ==
To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" 
From: qroxana 
Reply-To: qroxana 
Subject: Re: Kernel panic on armv7 when PF is enabled
Message-ID: 
In-Reply-To: 
References: 
Feedback-ID: 29996633:user:proton
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="b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM"
X-Rspamd-Queue-Id: 4KsGxM2qWZz4p9M
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=EHG+DE1u;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.43.18 as permitted sender) smtp.mailfrom=qroxana@protonmail.com
X-Spamd-Result: default: False [3.00 / 15.00];
	 HAS_REPLYTO(0.00)[qroxana@protonmail.com];
	 FREEMAIL_FROM(0.00)[protonmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 DKIM_TRACE(0.00)[protonmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[protonmail.com];
	 ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_SPAM_SHORT(0.91)[0.913];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 FREEMAIL_REPLYTO(0.00)[protonmail.com];
	 HAS_PHPMAILER_SIG(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.99)[0.986];
	 NEURAL_SPAM_LONG(1.00)[1.000];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3706
Lines: 59

This is a multi-part message in MIME format.

--b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

T24gU3VuLCAwMSBNYXkgMjAyMiAwMzoxMzo0MyArMDAwMCwgcXJveGFuYSA8cXJveGFuYUBwcm90
b25tYWlsLmNvbT4gd3JvdGU6Cgo+IEFmdGVyIGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0
ZWQgc2luY2UgdGhpcyBjb21taXQuCj4KPiBjb21taXQgNzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0
ZDJiOGQxNTNmOTY2NTExMwo+IEF1dGhvcjogS3Jpc3RvZiBQcm92b3N0IDxrcEBGcmVlQlNELm9y
Zz4KPiBEYXRlOiAgIE1vbiBGZWIgMTQgMjA6MDk6NTQgMjAyMiArMDEwMAo+Cj4gICAgIHZsYW46
IGFsbG93IG5ldC5saW5rLnZsYW4ubXRhZ19wY3AgdG8gYmUgc2V0IHBlciB2bmV0Cj4KPiAgICAg
VGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNoYW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3Rp
bmcuCj4KPiAgICAgTUZDIGFmdGVyOiAgICAgIDEgd2Vlawo+Cj4gc3lzL25ldC9pZl9ldGhlcnN1
YnIuYyB8IDkgKysrKystLS0tCj4gc3lzL25ldC9pZl92bGFuLmMgICAgICB8IDUgKysrLS0KPiAy
IGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKPgo+IFRoZSBh
cm12NyBib2FyZCBib290cyBmcm9tIGEgTkZTIHJvb3QsCj4KPiBpdCBjYW4gYm9vdCB3aXRob3V0
IGFueSBwcm9ibGVtIGlmIFBGIGlzIGRpc2FibGVkLgoKSXQgYXBwZWFycyB0aGlzIG9ubHkgb2Nj
dXJzIHdoZW4gdGhlIHJvb3RmcyBpcyBORlMsCkkgYWxzbyB0cmllZCB0byBib290IGl0IGZyb20g
YSBtaWNybyBTRCBjYXJkLCBubyBrZXJuZWwgcGFuaWMuCgpBbm90aGVyIHdvcmthcm91bmQgdG8g
YXZvaWQgdGhlIHBhbmljIGlzIHRvIGRlbGF5CnN0YXJ0aW5nIC9ldGMvcmMuZC9wZiB0byBTRVJW
RVJTCgotLS0gcGYub3JpZwkyMDIyLTAzLTEyIDEyOjI2OjQ3LjAwMDAwMDAwMCArMDAwMAorKysg
cGYJMjAyMi0wNS0wMiAwMjo1OToyOC4xMzEwMjY4NjIgKzAwMDAKQEAgLTQsNyArNCw3IEBACiAj
CgogIyBQUk9WSURFOiBwZgotIyBSRVFVSVJFOiBGSUxFU1lTVEVNUyBuZXRpZiBwZmxvZyBwZnN5
bmMgcm91dGluZworIyBSRVFVSVJFOiBTRVJWRVJTIG5ldGlmIHBmbG9nIHBmc3luYyByb3V0aW5n
CiAjIEtFWVdPUkQ6IG5vamFpbHZuZXQKCiAuIC9ldGMvcmMuc3VicgoKVGhhbmtzLA==

--b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PHByZT5PbiBTdW4sIDAxIE1heSAyMDIyIDAzOjEzOjQzICswMDAwLCBxcm94YW5hICZsdDtxcm94
YW5hQHByb3Rvbm1haWwuY29tJmd0OyB3cm90ZToNCg0KJmd0OyBBZnRlciBnaXQgYmlzZWN0aW5n
IHRoZSBwYW5pYyBzdGFydGVkIHNpbmNlIHRoaXMgY29tbWl0Lg0KJmd0Ow0KJmd0OyBjb21taXQg
NzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0ZDJiOGQxNTNmOTY2NTExMw0KJmd0OyBBdXRob3I6IEty
aXN0b2YgUHJvdm9zdCAmbHQ7a3BARnJlZUJTRC5vcmcmZ3Q7DQomZ3Q7IERhdGU6ICZuYnNwOyBN
b24gRmViIDE0IDIwOjA5OjU0IDIwMjIgKzAxMDANCiZndDsNCiZndDsgJm5ic3A7ICZuYnNwOyB2
bGFuOiBhbGxvdyBuZXQubGluay52bGFuLm10YWdfcGNwIHRvIGJlIHNldCBwZXIgdm5ldA0KJmd0
Ow0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoZSBwcmltYXJ5IHJlYXNvbiBmb3IgdGhpcyBjaGFuZ2Ug
aXMgdG8gZmFjaWxpdGF0ZSB0ZXN0aW5nLg0KJmd0Ow0KJmd0OyAmbmJzcDsgJm5ic3A7IE1GQyBh
ZnRlcjogJm5ic3A7ICZuYnNwOyAmbmJzcDsxIHdlZWsNCiZndDsNCiZndDsgc3lzL25ldC9pZl9l
dGhlcnN1YnIuYyB8IDkgKysrKystLS0tDQomZ3Q7IHN5cy9uZXQvaWZfdmxhbi5jICZuYnNwOyAm
bmJzcDsgJm5ic3A7fCA1ICsrKy0tDQomZ3Q7IDIgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRpb25z
KCspLCA2IGRlbGV0aW9ucygtKQ0KJmd0Ow0KJmd0OyBUaGUgYXJtdjcgYm9hcmQgYm9vdHMgZnJv
bSBhIE5GUyByb290LA0KJmd0Ow0KJmd0OyBpdCBjYW4gYm9vdCB3aXRob3V0IGFueSBwcm9ibGVt
IGlmIFBGIGlzIGRpc2FibGVkLg0KDQpJdCBhcHBlYXJzIHRoaXMgb25seSBvY2N1cnMgd2hlbiB0
aGUgcm9vdGZzIGlzIE5GUywNCkkgYWxzbyB0cmllZCB0byBib290IGl0IGZyb20gYSBtaWNybyBT
RCBjYXJkLCBubyBrZXJuZWwgcGFuaWMuDQoNCkFub3RoZXIgd29ya2Fyb3VuZCB0byBhdm9pZCB0
aGUgcGFuaWMgaXMgdG8gZGVsYXkNCnN0YXJ0aW5nIC9ldGMvcmMuZC9wZiB0byBTRVJWRVJTDQoN
Ci0tLSBwZi5vcmlnCTIwMjItMDMtMTIgMTI6MjY6NDcuMDAwMDAwMDAwICswMDAwDQorKysgcGYJ
MjAyMi0wNS0wMiAwMjo1OToyOC4xMzEwMjY4NjIgKzAwMDANCkBAIC00LDcgKzQsNyBAQA0KJm5i
c3A7Iw0KJm5ic3A7DQombmJzcDsjIFBST1ZJREU6IHBmDQotIyBSRVFVSVJFOiBGSUxFU1lTVEVN
UyBuZXRpZiBwZmxvZyBwZnN5bmMgcm91dGluZw0KKyMgUkVRVUlSRTogU0VSVkVSUyBuZXRpZiBw
ZmxvZyBwZnN5bmMgcm91dGluZw0KJm5ic3A7IyBLRVlXT1JEOiBub2phaWx2bmV0DQombmJzcDsN
CiZuYnNwOy4gL2V0Yy9yYy5zdWJyDQoNClRoYW5rcywNCjwvcHJlPjxicj4=


--b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM--


From nobody Mon May  2 09:02:53 2022
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 6A5311ABDC1A;
	Mon,  2 May 2022 09:02:57 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4KsHDd2WDFz4rh2;
	Mon,  2 May 2022 09:02:57 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1651482177;
	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=SzB63xMfF68oKDS5871Hon0krdh6z5t9G3RCEDEf2eM=;
	b=WxQBJ7su0zWHHNNip8+KEzm1TOwTiRCNMfJa6bfokBxdFgpguH8ztPrf77F2CVkiGNBgOF
	2+LhuQfrBuNIgKbH+/hmIZAoUpOGfoe5UoWw+cPlx1E2rQgcDFmgF3q8x9Vo8xlSuyicxI
	cPVb/FNxtWzv+0igHSNvyZS1aeWPLA1CSOvFdCb8HZrt8/mVsxNFf8G28mgPl27I4dxWcW
	bbukoEEifWOWWXHfJZvyhmY+o1RzRPRknq5f+r21ON4yd/QBM5fPSssBBlVr3IJqKYO3MS
	/WOBiPkMm7EIXJlS9hJS7CcRz41M+fzz4JbUYSdNkfKwejrXy2vPHKtuTdH0jA==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 0E24A7904;
	Mon,  2 May 2022 09:02:57 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 8280211A66;
	Mon,  2 May 2022 11:02:54 +0200 (CEST)
From: Kristof Provost 
To: qroxana 
Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: Kernel panic on armv7 when PF is enabled
Date: Mon, 02 May 2022 11:02:53 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: 
In-Reply-To: 
References: 
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="=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_="
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1651482177;
	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=SzB63xMfF68oKDS5871Hon0krdh6z5t9G3RCEDEf2eM=;
	b=lEecktoBnLy1JivDk8uNkhhKS3zFBxoUEvlsl9/gN5YaV6QoiQRKJPFH+7NxapimBDBLL3
	nM3OGnpDmXlJ58pXl0qyPIsLWHr23pA1BsCzuKYPF85TxZaB5WAT+NfyWEE1DemIvKPktw
	7wxGvsVOLQAbj+EfFI5dDqDfbsEiK7PYN2S3UHDs9vSjkP5xZQquiGGVhh7wW4Jm3k5B+H
	P7rPwHmT1Vzizo8odZGRmhBKiiLZ7suocHqTgLtq03FlQScyob+7L28tnVdspstSD+dNm2
	WLwI6NhvPd8qNjfOW9hNuV9AhuYv7bjaevRMrQ+SvmqPDLcmnkuchvzOhHjIMg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651482177; a=rsa-sha256; cv=none;
	b=i3c8526DS6JIz+CpUedqxgwxL4Pfi2YDQCQg9qGdcvBkqgOhmDNWhn2FoWPE9B28F9GHF9
	v2lQZzAEMnFzrg5JcX082/Gi3HfeCcp8GWpjxvqe/eYrnvgn353lE7IJLg4uSDexcrNLft
	oK23jWsPcIy5m//ebOPv3j0RqErsWWYgnQyzAypbeB6mU1fWUwyMej0l+vJBXUJmM2SB+c
	arnlmSH+FIZuB8beRwv5iNkYOgAd5DeKbUUu8Tdpm0YTHLPZBAT4O8OAdqJhrrxknGBJab
	0YHvpra0ruwP2eOFuD/bQeAoTLzFJEc6RE3Xf5133b9oWs24sB9kS54jD2qjkA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8932
Lines: 264


--=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 1 May 2022, at 5:13, qroxana wrote:
> After git bisecting the panic started since this commit.
>
> commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113
>
> Author: Kristof Provost <
> kp@FreeBSD.org
>>
>
> Date:   Mon Feb 14 20:09:54 2022 +0100
>
> vlan: allow net.link.vlan.mtag_pcp to be set per vnet
>
> The primary reason for this change is to facilitate testing.
>
> MFC after:      1 week
>
> sys/net/if_ethersubr.c | 9 +++++----
>
> sys/net/if_vlan.c      | 5 +++--
>
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> The armv7 board boots from a NFS root,
>
> it can boot without any problem if PF is disabled.
>
> Any helps?
>
> add host ::1: gateway lo0 fib 0: route already in table
> add net fe80::: gateway ::1
> add net ff02::: gateway ::1
> add net ::ffff:0.0.0.0: gateway ::1
> add net ::0.0.0.0: gateway ::1
> Enabling pf.
> Kernel page fault with the following non-sleepable locks held:
> shared rm pf rulesets (pf rulesets) r = 0 (0xe3099430) locked @ 
> /usr/src/sys/netpfil/pf/pf.c:6493
> exclusive rw tcpinp (tcpinp) r = 0 (0xdb748d88) locked @ 
> /usr/src/sys/netinet/tcp_usrreq.c:1008
> stack backtrace:
> #0 0xc0355cac at witness_debugger+0x7c
> #1 0xc0356ef0 at witness_warn+0x3fc
> #2 0xc05ec048 at abort_handler+0x1d8
> #3 0xc05cb5ac at exception_exit+0
> #4 0xe3083c10 at pf_syncookie_validate+0x60
> #5 0xe30496a8 at pf_test+0x518
> #6 0xe306d768 at pf_check_out+0x30
> #7 0xc0415b44 at pfil_run_hooks+0xbc
> #8 0xc0445cfc at ip_output+0xce8
> #9 0xc045bc9c at tcp_default_output+0x20ac
> #10 0xc0471eb4 at tcp_usr_send+0x1ac
> #11 0xc0389464 at sosend_generic+0x490
> #12 0xc0389790 at sosend+0x64
> #13 0xc0502888 at clnt_vc_call+0x560
> #14 0xc05009d8 at clnt_reconnect_call+0x170
> #15 0xc01e7b14 at newnfs_request+0xb20
> #16 0xc0230218 at nfscl_request+0x60
> #17 0xc020d9bc at nfsrpc_getattr+0xb0
> Fatal kernel mode data abort: 'Alignment Fault' on read
> trapframe: 0xdf1f1c90
> FSR=00000001, FAR=d7840264, spsr=40000013
> r0 =6a228eda, r1 =dac0d785, r2 =d7840264, r3 =db5527c0
> r4 =df1f1e00, r5 =dac0d75f, r6 =00000018, r7 =d9422c00
> r8 =c093e5e4, r9 =00000001, r10=df1f1f5c, r11=df1f1d38
> r12=e3098dd0, ssp=df1f1d20, slr=e3083bdc, pc =e3083c10
>
>
The commit you point at is entirely unrelated to the code where the 
panic occurred, so I’m pretty sure something went wrong in your 
bisect.

The backtrace would suggest the issue occurs in the  
pf_syncookie_validate() function, and likely in the line `if 
(atomic_load_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven]) 
== 0)`

The obvious way for that to panic would be to call it without the 
curvnet context set, but pf_test() uses it earlier, so that’s going to 
be fine.

Given that this is unique to armv7 I’d recommend talking to the armv7 
maintainer about 64 bit atomic operations.

You can probably avoid the atomic load with this patch (and not enabling 
syncookie support):

	diff --git a/sys/netpfil/pf/pf_syncookies.c 
b/sys/netpfil/pf/pf_syncookies.c
	index 5230502be30c..c86d469d3cef 100644
	--- a/sys/netpfil/pf/pf_syncookies.c
	+++ b/sys/netpfil/pf/pf_syncookies.c
	@@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd)
	        ack = ntohl(pd->hdr.tcp.th_ack) - 1;
	        cookie.cookie = (ack & 0xff) ^ (ack >> 24);

	+       if (V_pf_status.syncookies_mode == PF_SYNCOOKIES_NEVER)
	+               return (0);
	+
	        /* we don't know oddeven before setting the cookie (union) */
	         if 
(atomic_load_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven])
	            == 0)

That shouldn’t be required though.

Br,
Kristof

--=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable









On 1 May 2022, at 5:13, qroxana wrote:


After git bisecting the panic start=
ed since this commit.


commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113


Author: Kristof Provost <


kp@FreeBSD.org


Date:   Mon Feb 14 20:09:54 2022 +0100


vlan: allow net.link.vlan.mtag_pcp to be set per vnet
=


The primary reason for this change is to facilitate testi=
ng.


MFC after:      1 week


sys/net/if_ethersubr.c | 9 +++++----


sys/net/if_vlan.c      | 5 +++--


2 files changed, 8 insertions(+), 6 deletions(-)


The armv7 board boots from a NFS root,


it can boot without any problem if PF is disabled.


Any helps?


add host ::1: gateway lo0 fib 0: route already in table


add net fe80::: gateway ::1


add net ff02::: gateway ::1


add net ::ffff:0.0.0.0: gateway ::1


add net ::0.0.0.0: gateway ::1


Enabling pf.


Kernel page fault with the following non-sleepable locks held:


shared rm pf rulesets (pf rulesets) r =3D 0 (0xe3099430) locked @ /usr/sr=
c/sys/netpfil/pf/pf.c:6493


exclusive rw tcpinp (tcpinp) r =3D 0 (0xdb748d88) locked @ /usr/src/sys/n=
etinet/tcp_usrreq.c:1008


stack backtrace:


#0 0xc0355cac at witness_debugger+0x7c


#1 0xc0356ef0 at witness_warn+0x3fc


#2 0xc05ec048 at abort_handler+0x1d8


#3 0xc05cb5ac at exception_exit+0


#4 0xe3083c10 at pf_syncookie_validate+0x60


#5 0xe30496a8 at pf_test+0x518


#6 0xe306d768 at pf_check_out+0x30


#7 0xc0415b44 at pfil_run_hooks+0xbc


#8 0xc0445cfc at ip_output+0xce8


#9 0xc045bc9c at tcp_default_output+0x20ac


#10 0xc0471eb4 at tcp_usr_send+0x1ac


#11 0xc0389464 at sosend_generic+0x490


#12 0xc0389790 at sosend+0x64


#13 0xc0502888 at clnt_vc_call+0x560


#14 0xc05009d8 at clnt_reconnect_call+0x170


#15 0xc01e7b14 at newnfs_request+0xb20


#16 0xc0230218 at nfscl_request+0x60


#17 0xc020d9bc at nfsrpc_getattr+0xb0


Fatal kernel mode data abort: 'Alignment Fault' on read


trapframe: 0xdf1f1c90


FSR=3D00000001, FAR=3Dd7840264, spsr=3D40000013


r0 =3D6a228eda, r1 =3Ddac0d785, r2 =3Dd7840264, r3 =3Ddb5527c0


r4 =3Ddf1f1e00, r5 =3Ddac0d75f, r6 =3D00000018, r7 =3Dd9422c00


r8 =3Dc093e5e4, r9 =3D00000001, r10=3Ddf1f1f5c, r11=3Ddf1f1d38


r12=3De3098dd0, ssp=3Ddf1f1d20, slr=3De3083bdc, pc =3De3083c10






The commit you point at is entirely unrelated to the code=
 where the panic occurred, so I=E2=80=99m pretty sure something went wron=
g in your bisect.


The backtrace would suggest the issue occurs in the  pf_s=
yncookie_validate() function, and likely in the line if (atomic_loa=
d_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven]) =3D=3D 0=
)


The obvious way for that to panic would be to call it wit=
hout the curvnet context set, but pf_test() uses it earlier, so that=E2=80=
=99s going to be fine.


Given that this is unique to armv7 I=E2=80=99d recommend =
talking to the armv7 maintainer about 64 bit atomic operations.


You can probably avoid the atomic load with this patch (a=
nd not enabling syncookie support):


diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/=
pf/pf_syncookies.c
index 5230502be30c..c86d469d3cef 100644
--- a/sys/netpfil/pf/pf_syncookies.c
+++ b/sys/netpfil/pf/pf_syncookies.c
@@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd)
        ack =3D ntohl(pd->hdr.tcp.th_ack) - 1;
        cookie.cookie =3D (ack & 0xff) ^ (ack >> 24);

+       if (V_pf_status.syncookies_mode =3D=3D PF_SYNCOOKIES_NEVER)
+               return (0);
+
        /* we don't know oddeven before setting the cookie (union) */
         if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.f=
lags.oddeven])
            =3D=3D 0)



That shouldn=E2=80=99t be required though.


Br,

Kristof







--=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_=--

From nobody Mon May  2 15:37:38 2022
X-Original-To: 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 BEC891AB450D
	for ; Mon,  2 May 2022 15:37:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4KsS0F4kXxz4ck7
	for ; Mon,  2 May 2022 15:37:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651505861; bh=atsQn92vu9+f9of7qi7oFqvrf8cL3Y2V3WSIU6nc6hs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=KYGswuOvMCNIWjhe2JuXxEikrEu4AgmtW3DqOSqPJVAyTU4J9P4sfbeJhUN1+ThGXtZv/BTX5vZIBJA7u9xAvihxbQ0VRJR76nLGcfUQRhsVcAiyb1JI9Vg+TxqZMnN0n0UiAoGmtq+8lfoJRBgU6gIvIUEqisPFwRbXMsKAn1N5XVQhPAVRwvg/ZXLcLZTNce7O22lTZNLwqcAp+DVkIbQ+5VgatZUeBevMSL0zA1wW7qoiFXG55BKSpv5QFzce376bVcd0OTNcE3K60/RQcZCzOkKMnI1Kfw699z/I8sfvel8+TBObyUb2pV8N/HkAcuyNmd/DC7v4Syi9PjZ2bQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651505861; bh=VjSnmVk+f7EsmFuVi8GDbdNj6R1kfNwT7UxvRn8NEHr=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=fCDJy26wd9qH1Z/8IBnrFmtSHRf70946MDkH5BMP18p/iu41s+yWDeH4b32rVsrHtPL4Nk5YCBXwVlpNG+lBwYmHuTOJ5hg73UCnrS5yum+aCvUHClAkP9D4m2Oxr2m8p9OLwtU5fpX+6MQxNmrZh8ihcQ03Aw/dQiM5QdTw6L+Wzak5oWIdge0lgiB/ptFJwjqGw6K8hFvdlVdgsK5g+l7b8Rv1H5Orb/C9ZyzvD2RVfHHtE9E0aI5EsrkrVC0aVMYhmci7aCgTNnYIP+fhI48zXbSkgN5/fdpUzRw6ilwm+gwdEtKy3FWuXJgC7JAssKoBjCFBW5mJh7XE9a5qKA==
X-YMail-OSG: VmYoMoMVM1kDtm7W9FJrUYfDEdF5UrG10SMtqvbkfbI5t_910Y9.84cUdDhkz6h
 wyr95RfxY8FTU7qd5FkCOmMmycw4EuymDkeD2a1o05rK5IpyxXHHGc77rbJBEwslSGZYZIuNVKxv
 lf4fZ_waam6RW5sgHOsEbtYq1xAjhLwQ6eopT1YwY1M7EjFqBEBxHpsVWerTwrFe3g9f8L6Y0MSg
 uelf99NLdJ8vrX3F4ZjTSW1nnGw_eN7ObCwPWLqN2M0XzE.JIrRqyxkTLLRH8H7DKcsDBPFahjNg
 ql7MyXwr3gZN0315C5pU8SLV4duTGr.IedRVhZDyCEovNds__qQnd_Yl2cN7TbTXSx_NIx2Jxoqa
 8aWlwS3lSPe6vtmpk6TjiaLRwYFDJ7wZoIeeuwaLc1vUMZfK_7FddgkNNzq3k2eF7a.hGAYW7_jO
 VZKscQ490WLae1tgaYaPE2.cPkibFjcQwtBUj018Me1jbN1oqVzrhkYt.nuFsmHPxNvHjfhT5D7q
 d_JXcesFGLqffwVt_B.PlB9X9rOhMFYwxyytlO5Z_cRjgMkAhDR_HStfq7KQBrQ6x3YOGfUCbmJ3
 ayxlcWmcqUZu_JDRhb5wy7.0S.hKQS18WWkYmfpN5phy44aQJIECrOQh2Hh0ZviM5XnLypM7JL4e
 wn_hgKUEp25n1hSR1onf6vCvVoq.2GvJh.WsafiJ7VSe4DWDJ9.dElV43YL4SsADRZU9NrhiUqKQ
 MXcmr32qtYJ1bH7W7Aqd2uIomhkHLAUOBol4O5cearnrzi_9R7QbOcBNhG29Rt6lgVJhzlF6617m
 wR13ocXruwqRNqQE5VSZ3gfVQUOBG4Kc0dLy4_2nxT_P6nUxE4lJT9YL7UwJdNzqIdLmclKtMyRR
 MbVA_OirbJ7rZh3nOHi7FqPmaNhoFf5Bl0s8m8gQHeInIQDppI6zD0NawAzMKR.rJkLhRPKFxICv
 my.yT44POnpiP0YZN7Wo4CDuxHj.VCwHJlIyyDgHhJQQiwNIpXu9hTWh687XCvY8jYis6.0TNFkE
 os7rHdkghqOcol6DYW5vnMOBux_M5l81SJs2bjDyHSBmfjuDwgA.BbQumZ8ctO0b5Cds6.67bX5h
 3BPR2TGKQ54Ji0Rr0XIsneH9Cd8LGBpU1sbgO5sp5_hTkuHG6b7XY2OKnK5gMi61gaqF2VIlJKQX
 Vj_vpo_o0BTiS_LeEoLAFd.wSysp_dsxVXRey6A4HP9TwUrb8lLaCoTlCveMBRvUXYIWWDpklEB_
 JO6EJSZd4ivHVr6qQZE8u86KrSJI2JGGNl5gVHx9hwMYOTEsKOQjgj_NM_wrL3knnhiGXIlfrkuN
 FkLceX.1bL4CZs66vokBcG5uXmVQfgKHhq4l1wBMpk1hCWmf_0d4He74Xiby3OmLTpcMS7pX.lMc
 a_JalmfZxzGpailSlypjFFDUxRFIh4Pqh5Wv4tCv127WG.rEyaadHnHbtWFPxKv1DR93OD_bDGXB
 8ESBN5UucxHv4I5O3zaimyfh_bTp90.F_r_mQ4CD4QmUVQlH.ME.Kzci9lT2OyNpy5XLGfo5DOQ4
 4_AKdrXVWzOLTztbZae.HgpzjBtePZUmyL2xU2evn7.Iw1jCu3LEY7YfMuynmuPwatzmKJtRHjPV
 bKBW.QyKzM8flX1Kz9Bmm7VuFS.4s1dCEyxQ24MUHuSEYbTeHxAKHSP0L0R7Gf4kA3.PwzhMs_LX
 N_4672ZNu_9epqkDguSgxIJibSBmeIQ1bTFpnaA.fc3tdJktsBkkKyC3l.nwBCd_dq.77KNuWr21
 iRFpr3wFxwbAuQpPtcQIT5vT4Wq1yFopZM6O3ZToOzN4os_5pVp57V2WFG6MOOL7mEtkiDzPxX5q
 dtdSN1MTf8A.EqKsFgU__NbpWWPVC9AESGjMA54DBBAsMP4L_HVN8IdrYrizl54Rxd1esiWLOEDN
 U.cbYzhPx9U2QfqRFeKfgUR4Wzzjnoqm..arPXo5wJFDLKWqcRSJWYKGzE6U.0fYukjtCYvur9wp
 8mFZIKZWZtfMXf84LuLRqJnNj.8c1AfTO2gQ4HnyItXnity.e3gZimalfl2cwq6DCG0Lsayz657d
 S3iPpYlZfBl4q27GTmJvUQs7Q1fPoBQm0eY2b8Qx9r5HSD4tiSyjJ4DpW_R9DKopHcZNYUw2rSlF
 NQQ.HEFVp5MShEsLSxNQFkWePv.ZPAGaZpYOJyZqAtD6FIOkjLOK18LvAZ3.bUGwbk7ARGcAMJIe
 nzw2A0gRks.ULC1PObc7iSR91wrRvChXmvbUt4oECiq6IfIfnP_fP6KwRO4.9rYSPQJcR9KBARI3
 dBh8iTekbZR5xdKGZS5HwesLVXI_fR4Rhs8hVTdVJfT.jVpqK.hHXiQrsK5wjTJ._14dn5TnmKZt
 y3jp3MQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 May 2022 15:37:41 +0000
Received: by hermes--canary-production-gq1-647b99747d-xkjwp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f6433c9146e2bea7e049d6fb964790a;
          Mon, 02 May 2022 15:37:40 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: a39d7914ec28 - main - devel/aarch64-none-elf-gcc: Update to
 11.3
Message-Id: 
Date: Mon, 2 May 2022 08:37:38 -0700
To: Emmanuel Vadot ,
 dev-commits-ports-main@freebsd.org,
 "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4KsS0F4kXxz4ck7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KYGswuOv;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.146:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1845
Lines: 54

In devel/arm-none-eabi-gcc/pkg-plist this update lists:

+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stddef.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdio.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdlib.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/sys/types.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/unistd.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/wchar.h

but:

https://cgit.freebsd.org/ports/blame/devel/aarch64-none-elf-gcc/Makefile

shows a:

${RM} -r =
${STAGEDIR}/usr/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed

in post-install: . It looks like that should change:

-       ${RM} -r =
${STAGEDIR}/usr/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed
+       ${RM} -r =
${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed

(or that ${RM} line should be removed).

The devel/arm-none-elf-gcc slave port's:

=
https://lists.freebsd.org/archives/dev-commits-ports-main/2022-May/022477.=
html

also shows:

+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stddef.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdio.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdlib.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/sys/types.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/unistd.h
+lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/wchar.h

for the same reason.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon May  2 15:53:34 2022
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 6E2221AB932D;
	Mon,  2 May 2022 15:53:41 +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 4KsSLX11S0z4hJk;
	Mon,  2 May 2022 15:53:39 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 242Frb7q018124
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 2 May 2022 08:53:37 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 242FrYYR018123;
	Mon, 2 May 2022 08:53:34 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 2 May 2022 08:53:34 -0700
From: bob prohaska 
To: Hans Petter Selasky 
Cc: Mark Millard , Bakul Shah ,
        freebsd-net@freebsd.org, freebsd-arm@freebsd.org,
        bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220502155334.GA17962@www.zefox.net>
References: 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
 <20220502011312.GA15807@www.zefox.net>
 <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
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: <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
X-Rspamd-Queue-Id: 4KsSLX11S0z4hJk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_FIVE(0.00)[6];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,iitbombay.org,freebsd.org,www.zefox.net];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9306
Lines: 185

On Mon, May 02, 2022 at 08:56:12AM +0200, Hans Petter Selasky wrote:
[reply at end]
> On 5/2/22 03:13, bob prohaska wrote:
> > On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote:
> > [reply at end]
> > > On 2022-May-1, at 16:27, bob prohaska  wrote:
> > > 
> > > > On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
> > > > > 
> > > > > Looks like there is some problem getting past
> > > > > gig1-1-1.gw.davsca11.sonic.net .
> > > > > 
> > > > 
> > > > That seems independent of my own internal connection problems,
> > > > but worth taking up with my ISP on Monday. Meanwhile, can you
> > > > ping any other hosts in the 50.1.20.31-24 range? All are up
> > > > at the moment. Hosts 28 and 24 are the troublemakers.
> > > > 
> > > > If anybody cares there's an ascii-art network diagram at
> > > > http://www.zefox.net/~fbsd/netmap
> > > > 
> > > > Not sure it'll survive the mailing list, but here goes:
> > > > dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation
> > > >                       |                  |             |
> > > >                       |                  |             |---Mac workstation
> > > >                       |                  |
> > > >                       |                  |------printer
> > > >     ------------------|
> > > >     |
> > > >     |------50.1.20.30 ns1.zefox.net Pi2 12.3 usb-serial----50.1.20.27
> > > >     |------50.1.20.29 ns2.zefox.net Pi2 12.3 usb-serial----50.1.20.30
> > > >     |------50.1.20.27 www.zefox.net Pi2 12.3 usb-serial----50.1.20.26
> > > >     |------50.1.20.26 www.zefox.com Pi2 -current usb-serial---50.1.20.24
> > > >     |------50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
> > > > switch
> > > >     |------50.1.20.25 nemesis.zefox.com Pi4 -current usb-serial---50.1.20.29
> > > >     |------50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
> > > 
> > > 
> > > For ns1.zefox.net there is no problem and
> > > it looks like:
> > > 
> > >                                       My traceroute  [v0.95]
> > > amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29)                2022-05-01T16:52:27-0700
> > > Keys:  Help   Display mode   Restart statistics   Order of fields   quit
> > >                                                         Packets               Pings
> > >   Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
> > >   1. 192.168.1.1                                       0.0%    53    1.2   0.8   0.1   1.4   0.4
> > >   2. 172.30.26.67                                      0.0%    53   11.8  25.0  11.8  61.0  11.4
> > >   3. 68.85.243.125                                     0.0%    53   10.0  10.0   7.7  46.9   5.3
> > >   4. 96.216.60.165                                     0.0%    53    8.8   9.3   7.8  12.1   0.9
> > >   5. 68.85.243.197                                     0.0%    53    8.6  13.2   8.6  28.3   4.2
> > >   6. be-36231-cs03.seattle.wa.ibone.comcast.net        0.0%    53   15.3  14.8  13.0  16.9   1.0
> > >   7. be-2312-pe12.seattle.wa.ibone.comcast.net         0.0%    53   16.2  15.9  12.9  59.8   6.5
> > >   8. (waiting for reply)
> > >   9. be3717.ccr22.sfo01.atlas.cogentco.com             0.0%    53   29.8  30.9  26.5  97.9  10.1
> > > 10. be2430.ccr31.sjc04.atlas.cogentco.com             0.0%    53   29.0  29.0  26.6  39.3   1.8
> > > 11. 38.104.141.82                                     0.0%    53   28.9  33.8  26.1 115.0  17.0
> > > 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    53   32.1  31.3  29.2  33.9   1.0
> > > 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    53   30.5  32.1  29.2  57.6   4.3
> > > 14. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    53   31.8  32.0  28.8  43.7   2.0
> > > 15. gig1-1-1.gw.davsca11.sonic.net                    0.0%    52   31.0  32.4  30.2  38.4   1.4
> > > 16. ns1.zefox.net                                     0.0%    52   51.4  51.1  49.8  53.4   0.8
> > > 
> > > ns2.zefox.net and others got a 17. instead of
> > > a 16. An example is:
> > > 
> > >                                       My traceroute  [v0.95]
> > > amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30)                2022-05-01T16:58:45-0700
> > > Keys:  Help   Display mode   Restart statistics   Order of fields   quit
> > >                                                         Packets               Pings
> > >   Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
> > >   1. 192.168.1.1                                       0.0%    55    0.3   0.9   0.1   1.4   0.4
> > >   2. 172.30.26.66                                      0.0%    55   13.5  26.4  10.4  54.7  10.1
> > >   3. 68.85.243.77                                      0.0%    55   10.5   9.1   7.9  10.5   0.6
> > >   4. 24.124.129.106                                    0.0%    54    8.3   9.5   8.2  13.4   1.0
> > >   5. 96.216.60.165                                     0.0%    54    8.8   9.8   7.8  22.8   2.2
> > >   6. 68.85.243.197                                     0.0%    54   17.1  15.1   9.0  37.3   5.9
> > >   7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    54   15.2  15.0  13.2  17.8   0.9
> > >   8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    54   15.0  14.8  13.2  17.1   1.0
> > >   9. (waiting for reply)
> > > 10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    54   28.4  29.2  26.9  36.8   1.4
> > > 11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    54   29.8  30.0  27.3  84.2   7.6
> > > 12. 38.104.141.82                                     0.0%    54   28.6  33.7  27.5 105.5  16.2
> > > 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    54   31.6  31.4  29.5  33.8   0.9
> > > 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    54   31.1  32.1  29.1  52.9   3.4
> > > 15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    54   31.2  31.9  30.0  34.1   0.9
> > > 16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    54   33.3  32.6  30.8  45.8   2.1
> > > 17. ns2.zefox.net                                     0.0%    54   52.5  51.4  49.1  54.9   1.2
> > > 
> > > The routing need not be the same from one
> > > try to the next.
> > > 
> > > www.zefox.net     is similar.
> > > www.zefox.com     is similar.
> > > pelorus.zefox.org is similar.
> > > nemesis.zefox.com is similar.
> > > www.zefox.org     is similar.
> > > 
> > > Notably www.zefox.org was what I tried and
> > > reported on before that had the failures.
> > > 
> > > I observed a initial connection sequence once
> > > for pelorus.zefox.org where it briefly displayed
> > > something like (not captured, just from memory):
> > > 
> > > 16. gig1-1-1.gw.davsca11.sonic.net
> > > 17. (waiting for reply)
> > > 18. (waiting for reply)
> > > 19. pelorus.zefox.org
> > > 
> > > before changing to
> > > 
> > > 16. gig1-1-1.gw.davsca11.sonic.net
> > > 17. ns2.zefox.net
> > > 
> > > That may be normal but usually timed such that I
> > > would not usually see it.
> > > 
> > > But it might actually be evidence of a stage that
> > > the leads to the overall failure by never getting
> > > past the:
> > > 
> > > 16. gig1-1-1.gw.davsca11.sonic.net
> > > 17. (waiting for reply)
> > > 18. (waiting for reply)
> > > 19. WHATEVER
> > > 
> > > in some cases.
> > > 
> > > However, in the above the below worked fine:
> > > 
> > > 50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
> > > 50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
> > > 
> > > What changed?
> > 
> > I restarted an outgoing ping so I could access those hosts via ssh,
> > to bring up a serial console connection to the next host in the "ring".
> > Usually I simply ping 50.1.20.31 (my router) but at least in the past
> > it did not matter what the destination was. In one case I tried an
> > unused address. That makes the role of a distant host somewhat
> > baffling.
> > 
> > Thanks for checking!
> > 
> > bob prohaska
> 
> Hi,
> 
> Did you try to force the link mode to 100MBit/s ?
> 

Not explcitly, but ifconfig -a reports
ue0: flags=8843 metric 0 mtu 1500
        options=80009
        ether b8:27:eb:71:46:4e
        inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
        media: Ethernet autoselect (100baseTX )
        status: active
        nd6 options=29
so I think it's 100MBit/s anyway.

One new oddity is seeing in the daily security report the lines
www.zefox.org kernel log messages:
+ue0: promiscuous mode enabled
+ue0: promiscuous mode disabled
+ue0: promiscuous mode enabled
+ue0: promiscuous mode disabled
+ue0: promiscuous mode enabled
+ue0: promiscuous mode disabled

I'm using static addresses set in /etc/rc.conf. The DHCP line is commented
out but not expicitly disabled. Could something else be trying to turn DHCP
on, which I gather would also place the interface in promiscuous mode? 

Uname -a reports:

FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #55 main-n255108-9fb40baf604: Fri Apr 29 20:42:26 PDT 2022     bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64


Thanks for writing!

bob prohaska


From nobody Mon May  2 18:31:43 2022
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 15C591ABB278
	for ; Mon,  2 May 2022 18:31:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4KsWs44cHcz3rSL
	for ; Mon,  2 May 2022 18:31:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651516305; bh=7pVC8NuVuAIsjBI2jvqrPEioQoBPa5j3Dap03wozy4g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SXWIJi4h7TDYtjV5HbjeeRTmBMr1HajTtHW4DNqNgsaSo/ByYe96ZaHBMDECvE8B17cqk+1aKUbH8MNIwz4IeYlLTLLiwzlUYAMToekOBZq6MCYKG0n9uavlm9C8qNdgozPy9RHvXkOPYo+cfeg83XJ5s1y7DhgdTJV6UIUYzE+Ktkv2rvw48q47o2tHvktWhMFA/XKXs/nILoTMldlio46xudsXBFKoe1H7YqdyFvhoHjJmMwrb9PHj0G1i7siO0J85JpK+0I3s2+Wyls7FX3wIIQDMUOOlnY5N0SfxpT9qMynbYTleRzkM5CyYCGMSmjnnFnm7uOOOnOwRw9AgIQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651516305; bh=Upw8nJpOTw5lWcs2NSw9OHfZMLk7L530Gehb5xwDsQo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kV7bGPusk91+k/S3a1mxWeg1LOdJS8IthXZKSdM74SHbmnXWipVIYcMi4DAAXFAvcqivZ4DBn3QfTybGV5fJPZOLYMj5VE5gIGN5WXsnSfLJh9Yic9mpnB0yo5UEFDoQWb+w2lbtnAxzO+2PQTLcWFgLHox1z3cDFY2EmwRAqUBtuIK3QDwd4jFEldgyUXBr1ttSKQCllQgwN4yWFtc098iHnr4+pEtA1aDgOTZMap0YLNq/wEJPAbkutAlxrVBu0O5mi6Yg/+q3gLxFgGQj+GvkyAQqG1ZUo/mfvYcHCU2ZwhVRrKHont95IFtyP6MLa6HfX7PTu7URhOwEKSBN9w==
X-YMail-OSG: isWScHcVM1lS7LFHyFpMzIY8Sod8rdU5RD7FCZQ5O6_HeSpa.YCknT307FkL56q
 1HvP1cnpbJZZ_UDI0vCfsy7pUHhu_pi5jkuLfFtJV847LgQJTwCZBsSr4wO9FrU4SoExR_mcWehW
 tzBHyuIH9vjoOh0vkOfZIxQO.fii72y.LiVfsp9oxcS82v5xA34UGBZFSh2KtG_W7EIKKLmQR4Jd
 vQZ1Fa4Q4eIb2r0HqjYY48tdUu2wcr0lE8UCyrLXCrQocuBx7Hjec3uspPbZTy7tFUfJsfd5FJN2
 NvX9GGhhA2hGdM_aUqXOwadw3pyjVVsl1DB8tVf6euyCKfCSywPeCpR75wRJmWI4hBifn5dX.b3M
 TKq8Fglnu8fWU61jmBt8IU8ehrAPFW.c4k5hN8V7YQKBm.ZnwWlAeNROUAIMdCUK17f2Uwdsi9K4
 3PcTy57xgMxxJQ54lXkUFF9VvCwTwweKxQwQHazrt.OHXobG7SQ_8HfImDjn5IDMlGGD696f.Xym
 TmgsMSYqUZxbKrqr5jIv8Lbkp1CJIt.gWhUgdhhAxeQjGGd_GAbrDYEr8WGj9eqVyVoph96V8nB.
 _7.eud52sPW3ozZ.c1uxMpKEGHqmOmeJ3cMVEcsG.AAYlIr1eroZbEcnW0VGFO0OxDRLa3LQRZqf
 J_q4SobfepkUaQhH_lEyHnii5memDtLh5mt1b5MshDVCNFPl7Vn3eWurGTyE45fuIUTmcYhlyTl4
 pMzYwalb9NqkCw6K6ZK66C_7rJihltu1p1UimQ.E.BIp5LBrIXSy7eYy1Xd3QyiSVGDCTCA49dNs
 WJCvsfByEik3HDVzo87toU70THq2D23IEu1c_Q4i.y5kA_B0ACPh9neaRjtRQqmFFCwgreeV_NBw
 EfmzscD9Op.pMm6kmB3FbacIn3V6_b95eNcPt.SpcDyA_g0f2bIoZ5qQKk.tQaH8_4Kb8CDf07YA
 jDe0C073badCCWLTPUjeUiv61EAiGn7fKbgsJfvtjFGppFTXGXNMZ.1k.rmXkIS_PL7x9kwI8Udv
 R7DJErgw..TT4ZBH2uDqAALBceKsUqc0EAuVxokctra8rYcuxYGCjejHKI7cRHEXQe3TUqSn0Rgs
 j_55nuD37HTQuvc47pWH.oltlyc9upq77tiW1IbYel3.WeN8nD8hM552fBai7kMn9q.ggQyqHEk8
 SEb1RYMK7kd2KmUH4CWqnQRNUHZP4M703Kmjz_YGeNAuU8frWfSYuySsmKNRRsObDE2yq2Hyg3qp
 9tRqxz4wKzzFxCv8lmrerIsYSWS8Uk5wg0MmcsKedU9ISPp6_a2eTCnzsPxulSkId3w3C9RnoHdr
 fyPyNfHXHxehXXoZC85fgeO2pRrrw_BG47g8HE.dAs9gMK8jahUWyM._O3vruUT84GLj7DTil5or
 mITUs4dic2j5FYlL2XzFXT73L1JHXoSSIEE533LJ5z7tLkpuPSfVAvKXJq0Y..T0JKtq3Sbed_3H
 MM8BT2kW2AFE4w5T17iF6UokVYznBPXgpFp2maJNUzk04jth8Qip_QkvrJ5ZyWlfMsMcQpErWspS
 bc2.BKMDSWHKpzLFeIJqXkmM7rzXxU0_2hcemDkuba9KVur50fOLDXTuOhhlVg_1wj_cJww2MnsZ
 MexyyRCjkfWyuKY98P9xTILnHUpInAuoKdGMOB5RqruxAWBc1Dx9qEIo8OUZh7MM6B1dSawj8TBd
 kU2I2MSdWCUX62tWtaID9J_28KP5yC29kKuNOxiD.3fTjvggmoqyvJ0c2bJ6wnRj39jpZNOnRYWv
 AZ5XkenFukhrMAtLMVn3Mp4O.0WLf.FYdRxxxcyuVCD.ipWTh3Yeq7lYUPfy6GoU93Z25mqJD61h
 x54ljp4eeN_RafCK2P8m.b2yVXxoaUfquLtVyeLzAZ0mftxixUXtLDVAsrkbO2ny5AfKxveU5o95
 vRMa7U0GUMJX40YX5AAk1VfVZOvBbDnEHpuYD7xV1BohX9uTgk65YbDLxy2qixUdn9CBIgQvU8y7
 AJEfqXXxCcYklEqdK8D3qd0PSsH30gnNx0rwnSeAfNFalR3J82zKFyP6xJSd8vL.SQR3TiCqb_oW
 o27_FOnzgzvA3XAqRYYPfo6bZBxSdYJLr2QaZiKGvDa7KPogCCVKtXWyOgLfdDiJlmaRwO87859k
 X6w_vjNLRyNBjS5lW1Z_8QZNhMJ5GZ7X64NczMtTtzvZLm4WvMykFaEy5oi38ruh3_B5ZDo9oxx8
 51t5AOjpUpeZ8AM51bpg4Cdn2rslmX6yHBcEavfAZ4NRDLwe6XgmJtawv6vXkJ8CMJ_nLlzhHB8p
 zfxzG4Iv_.vTsawMpfMjt_snArXtifHtskIuvwg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 May 2022 18:31:45 +0000
Received: by hermes--canary-production-gq1-647b99747d-7f5lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b6db084d8b5f353fce2272e66a57b161;
          Mon, 02 May 2022 18:31: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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <20220502155334.GA17962@www.zefox.net>
Date: Mon, 2 May 2022 11:31:43 -0700
Cc: Hans Petter Selasky ,
 Bakul Shah ,
 freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5684AD66-9C03-4C01-AC4B-A80D98D9D01A@yahoo.com>
References: 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
 <20220502011312.GA15807@www.zefox.net>
 <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
 <20220502155334.GA17962@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KsWs44cHcz3rSL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=SXWIJi4h;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 13992
Lines: 350

On 2022-May-2, at 08:53, bob prohaska  wrote:

> On Mon, May 02, 2022 at 08:56:12AM +0200, Hans Petter Selasky wrote:
> [reply at end]
>> On 5/2/22 03:13, bob prohaska wrote:
>>> On Sun, May 01, 2022 at 05:10:59PM -0700, Mark Millard wrote:
>>> [reply at end]
>>>> On 2022-May-1, at 16:27, bob prohaska  wrote:
>>>>=20
>>>>> On Sun, May 01, 2022 at 12:58:45PM -0700, Mark Millard wrote:
>>>>>>=20
>>>>>> Looks like there is some problem getting past
>>>>>> gig1-1-1.gw.davsca11.sonic.net .
>>>>>>=20
>>>>>=20
>>>>> That seems independent of my own internal connection problems,
>>>>> but worth taking up with my ISP on Monday. Meanwhile, can you
>>>>> ping any other hosts in the 50.1.20.31-24 range? All are up
>>>>> at the moment. Hosts 28 and 24 are the troublemakers.
>>>>>=20
>>>>> If anybody cares there's an ascii-art network diagram at
>>>>> http://www.zefox.net/~fbsd/netmap
>>>>>=20
>>>>> Not sure it'll survive the mailing list, but here goes:
>>>>> =
dsl_modem-----switch---------router-----lan-------wifi-----pi4_workstation=

>>>>>                      |                  |             |
>>>>>                      |                  |             |---Mac =
workstation
>>>>>                      |                  |
>>>>>                      |                  |------printer
>>>>>    ------------------|
>>>>>    |
>>>>>    |------50.1.20.30 ns1.zefox.net Pi2 12.3 =
usb-serial----50.1.20.27
>>>>>    |------50.1.20.29 ns2.zefox.net Pi2 12.3 =
usb-serial----50.1.20.30
>>>>>    |------50.1.20.27 www.zefox.net Pi2 12.3 =
usb-serial----50.1.20.26
>>>>>    |------50.1.20.26 www.zefox.com Pi2 -current =
usb-serial---50.1.20.24
>>>>>    |------50.1.20.24 pelorus.zefox.org Pi3 13.1 =
usb-serial---50.1.20.28
>>>>> switch
>>>>>    |------50.1.20.25 nemesis.zefox.com Pi4 -current =
usb-serial---50.1.20.29
>>>>>    |------50.1.20.28 www.zefox.org Pi3 -current =
usb-serial----50.1.20.25
>>>>=20
>>>>=20
>>>> For ns1.zefox.net there is no problem and
>>>> it looks like:
>>>>=20
>>>>                                      My traceroute  [v0.95]
>>>> amd64_ZFS (192.168.1.120) -> ns1.zefox.net (50.1.20.29)             =
   2022-05-01T16:52:27-0700
>>>> Keys:  Help   Display mode   Restart statistics   Order of fields   =
quit
>>>>                                                        Packets      =
         Pings
>>>>  Host                                                Loss%   Snt   =
Last   Avg  Best  Wrst StDev
>>>>  1. 192.168.1.1                                       0.0%    53    =
1.2   0.8   0.1   1.4   0.4
>>>>  2. 172.30.26.67                                      0.0%    53   =
11.8  25.0  11.8  61.0  11.4
>>>>  3. 68.85.243.125                                     0.0%    53   =
10.0  10.0   7.7  46.9   5.3
>>>>  4. 96.216.60.165                                     0.0%    53    =
8.8   9.3   7.8  12.1   0.9
>>>>  5. 68.85.243.197                                     0.0%    53    =
8.6  13.2   8.6  28.3   4.2
>>>>  6. be-36231-cs03.seattle.wa.ibone.comcast.net        0.0%    53   =
15.3  14.8  13.0  16.9   1.0
>>>>  7. be-2312-pe12.seattle.wa.ibone.comcast.net         0.0%    53   =
16.2  15.9  12.9  59.8   6.5
>>>>  8. (waiting for reply)
>>>>  9. be3717.ccr22.sfo01.atlas.cogentco.com             0.0%    53   =
29.8  30.9  26.5  97.9  10.1
>>>> 10. be2430.ccr31.sjc04.atlas.cogentco.com             0.0%    53   =
29.0  29.0  26.6  39.3   1.8
>>>> 11. 38.104.141.82                                     0.0%    53   =
28.9  33.8  26.1 115.0  17.0
>>>> 12. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    53   =
32.1  31.3  29.2  33.9   1.0
>>>> 13. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    53   =
30.5  32.1  29.2  57.6   4.3
>>>> 14. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    53   =
31.8  32.0  28.8  43.7   2.0
>>>> 15. gig1-1-1.gw.davsca11.sonic.net                    0.0%    52   =
31.0  32.4  30.2  38.4   1.4
>>>> 16. ns1.zefox.net                                     0.0%    52   =
51.4  51.1  49.8  53.4   0.8
>>>>=20
>>>> ns2.zefox.net and others got a 17. instead of
>>>> a 16. An example is:
>>>>=20
>>>>                                      My traceroute  [v0.95]
>>>> amd64_ZFS (192.168.1.120) -> ns2.zefox.net (50.1.20.30)             =
   2022-05-01T16:58:45-0700
>>>> Keys:  Help   Display mode   Restart statistics   Order of fields   =
quit
>>>>                                                        Packets      =
         Pings
>>>>  Host                                                Loss%   Snt   =
Last   Avg  Best  Wrst StDev
>>>>  1. 192.168.1.1                                       0.0%    55    =
0.3   0.9   0.1   1.4   0.4
>>>>  2. 172.30.26.66                                      0.0%    55   =
13.5  26.4  10.4  54.7  10.1
>>>>  3. 68.85.243.77                                      0.0%    55   =
10.5   9.1   7.9  10.5   0.6
>>>>  4. 24.124.129.106                                    0.0%    54    =
8.3   9.5   8.2  13.4   1.0
>>>>  5. 96.216.60.165                                     0.0%    54    =
8.8   9.8   7.8  22.8   2.2
>>>>  6. 68.85.243.197                                     0.0%    54   =
17.1  15.1   9.0  37.3   5.9
>>>>  7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    54   =
15.2  15.0  13.2  17.8   0.9
>>>>  8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    54   =
15.0  14.8  13.2  17.1   1.0
>>>>  9. (waiting for reply)
>>>> 10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    54   =
28.4  29.2  26.9  36.8   1.4
>>>> 11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    54   =
29.8  30.0  27.3  84.2   7.6
>>>> 12. 38.104.141.82                                     0.0%    54   =
28.6  33.7  27.5 105.5  16.2
>>>> 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    54   =
31.6  31.4  29.5  33.8   0.9
>>>> 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    54   =
31.1  32.1  29.1  52.9   3.4
>>>> 15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    54   =
31.2  31.9  30.0  34.1   0.9
>>>> 16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    54   =
33.3  32.6  30.8  45.8   2.1
>>>> 17. ns2.zefox.net                                     0.0%    54   =
52.5  51.4  49.1  54.9   1.2
>>>>=20
>>>> The routing need not be the same from one
>>>> try to the next.
>>>>=20
>>>> www.zefox.net     is similar.
>>>> www.zefox.com     is similar.
>>>> pelorus.zefox.org is similar.
>>>> nemesis.zefox.com is similar.
>>>> www.zefox.org     is similar.
>>>>=20
>>>> Notably www.zefox.org was what I tried and
>>>> reported on before that had the failures.
>>>>=20
>>>> I observed a initial connection sequence once
>>>> for pelorus.zefox.org where it briefly displayed
>>>> something like (not captured, just from memory):
>>>>=20
>>>> 16. gig1-1-1.gw.davsca11.sonic.net
>>>> 17. (waiting for reply)
>>>> 18. (waiting for reply)
>>>> 19. pelorus.zefox.org
>>>>=20
>>>> before changing to
>>>>=20
>>>> 16. gig1-1-1.gw.davsca11.sonic.net
>>>> 17. ns2.zefox.net
>>>>=20
>>>> That may be normal but usually timed such that I
>>>> would not usually see it.
>>>>=20
>>>> But it might actually be evidence of a stage that
>>>> the leads to the overall failure by never getting
>>>> past the:
>>>>=20
>>>> 16. gig1-1-1.gw.davsca11.sonic.net
>>>> 17. (waiting for reply)
>>>> 18. (waiting for reply)
>>>> 19. WHATEVER
>>>>=20
>>>> in some cases.
>>>>=20
>>>> However, in the above the below worked fine:
>>>>=20
>>>> 50.1.20.24 pelorus.zefox.org Pi3 13.1 usb-serial---50.1.20.28
>>>> 50.1.20.28 www.zefox.org Pi3 -current usb-serial----50.1.20.25
>>>>=20
>>>> What changed?
>>>=20
>>> I restarted an outgoing ping so I could access those hosts via ssh,
>>> to bring up a serial console connection to the next host in the =
"ring".
>>> Usually I simply ping 50.1.20.31 (my router) but at least in the =
past
>>> it did not matter what the destination was. In one case I tried an
>>> unused address. That makes the role of a distant host somewhat
>>> baffling.
>>>=20
>>> Thanks for checking!
>>>=20
>>> bob prohaska
>>=20
>> Hi,
>>=20
>> Did you try to force the link mode to 100MBit/s ?
>>=20
>=20
> Not explcitly, but ifconfig -a reports
> ue0: flags=3D8843 metric 0 mtu =
1500
>        options=3D80009
>        ether b8:27:eb:71:46:4e
>        inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
>        media: Ethernet autoselect (100baseTX )
>        status: active
>        nd6 options=3D29
> so I think it's 100MBit/s anyway.

He might have been asking about how other equipment tries to
to do thing: setting such to only try 100baseTX for talking
to the 2 RPi3B's ( 50.1.20.28 and 50.1.20.24 ).

FYI, I just checked and I'm seeing:

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> pelorus.zefox.org (50.1.20.24)            =
2022-05-02T11:19:40-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets           =
    Pings
 Host                                                Loss%   Snt   Last  =
 Avg  Best  Wrst StDev
 1. 192.168.1.1                                       0.0%    56    0.5  =
 0.8   0.1   1.4   0.4
 2. 172.30.26.66                                      0.0%    56   81.1  =
73.6  23.8 138.6  25.5
 3. 68.85.243.77                                      0.0%    56   70.0  =
62.0   8.1  77.2  17.7
 4. 24.124.129.106                                    0.0%    56   18.4  =
49.0  12.0  83.5  23.7
 5. 96.216.60.165                                     0.0%    56   72.0  =
57.0  14.4  74.7  21.8
 6. 68.85.243.197                                     0.0%    56   72.1  =
63.3  10.6 115.9  22.9
 7. be-36221-cs02.seattle.wa.ibone.comcast.net        0.0%    56   79.4  =
58.8  14.3  79.4  23.3
 8. be-2212-pe12.seattle.wa.ibone.comcast.net         0.0%    56   77.2  =
64.3  19.5 125.1  22.2
 9. (waiting for reply)
10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    55   86.8  =
74.9  30.5 104.6  21.7
11. be2379.ccr31.sjc04.atlas.cogentco.com             3.6%    55   47.4  =
75.8  29.4  92.8  22.0
12. 38.104.141.82                                     0.0%    55   35.5  =
83.3  29.0 155.0  27.5
13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    55   92.6  =
81.0  37.0  95.0  17.9
14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    55   91.3  =
78.8  32.6 136.1  21.5
15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    55   96.9  =
79.9  31.3  96.9  21.4
16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    55   91.8  =
79.9  38.7  97.2  19.8
17. pelorus.zefox.org                                67.3%    55  173.6 =
152.8  51.3 177.6  45.9

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> www.zefox.org (50.1.20.28)                =
2022-05-02T11:21:29-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets           =
    Pings
 Host                                                Loss%   Snt   Last  =
 Avg  Best  Wrst StDev
 1. 192.168.1.1                                       0.0%    57    0.7  =
 0.7   0.1   1.4   0.4
 2. 172.30.26.66                                      0.0%    57   78.2  =
75.3  20.2 193.3  28.8
 3. 68.85.243.77                                      0.0%    57   67.8  =
53.2  11.4  73.1  20.8
 4. 24.124.129.106                                    0.0%    56   72.3  =
51.4  15.8  73.4  21.7
 5. 96.216.60.165                                     0.0%    56   73.6  =
53.5  10.4  74.6  22.8
 6. 68.85.243.197                                     0.0%    56   72.4  =
63.5  19.3  93.4  19.6
 7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    56   77.8  =
58.9  16.6  78.9  22.4
 8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    56   78.0  =
61.7  23.5  79.8  20.8
 9. (waiting for reply)
10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    56   92.1  =
75.2  27.6 137.5  24.2
11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    56   99.5  =
75.3  31.3  99.5  19.9
12. 38.104.141.82                                     0.0%    56   53.6  =
79.8  35.4 132.7  22.6
13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    56   94.0  =
75.5  35.4 108.0  21.6
14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    56   94.8  =
77.6  37.1 102.5  20.2
15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    56   93.5  =
80.6  32.8 128.6  20.3
16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    56   63.6  =
97.5  36.9 274.3  46.5
17. www.zefox.org                                    48.2%    56  175.6 =
153.4  58.4 179.1  44.1

But 0.0% on the others.

This is different than the basic lack of connection
I reported originally.

> One new oddity is seeing in the daily security report the lines
> www.zefox.org kernel log messages:
> +ue0: promiscuous mode enabled
> +ue0: promiscuous mode disabled
> +ue0: promiscuous mode enabled
> +ue0: promiscuous mode disabled
> +ue0: promiscuous mode enabled
> +ue0: promiscuous mode disabled

Looks to me like you ran tcpdump (or other such)
3 times.

> I'm using static addresses set in /etc/rc.conf. The DHCP line is =
commented
> out but not expicitly disabled. Could something else be trying to turn =
DHCP
> on, which I gather would also place the interface in promiscuous mode?=20=


I'd guess that DHCP does not of itself enable promiscuous mode.

But monitoring all the traffic on the EtherNet connection basically
requires promiscuous mode during the monitoring.

> Uname -a reports:
>=20
> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #55 =
main-n255108-9fb40baf604: Fri Apr 29 20:42:26 PDT 2022     =
bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon May  2 18:45:21 2022
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 8147D1ABFE53
	for ; Mon,  2 May 2022 18:45:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4KsX8t5TjPz4QxT
	for ; Mon,  2 May 2022 18:45:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651517127; bh=9M/nUVg+S0X77zPIxriMZuHhIurrp7tnVrg1Zg5/N6E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tmpaG4HjEufgHPo21cafi/5e0csnK9WUcXjWLG0+lzTDgIwqLXKBH9QJcHOxO6e9d4m+mN9O0HN3JnLsWdvixUoWEo2N5xA1aq5M4pX6j42JlhXX7kU/305oTHtJ1z+1AywNOx6UNsymcnX7W3OpYNuJUnBEOu6uoRFVRO+3IWVFDrTOvnEnKo3ffmmf/fEwTvik1Bv8ERYR702s9/5xp8zqA4jinHuaUoqarU4d8Q4F3EzhNi7d7hSJlPdbExe9temlR9XJZraUF48OpTTRAGGMbzpd8ZbL371UEDtrwcb7lflrWmyXrUGF2BzjvoiIyUV4VkhSvtoy5SKyO1uzZA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651517127; bh=PnWJqDe1OMm0g55cNtD3HoKeueDJ7T5ZZJGM6tt7JDU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LEyS6apWl316oqfzYsix+Uje7hNdiLANK9QCsvmcEYoRAHj/cOTScWe6y2Ih5rjGivxXg+6gLQsEYjwe/gKiVgQcs9D9tc65hfz9DtCKpHAqKfpWfG2+uIHOY+zn9ecF2HxrIKp9Tw8FFW1H+JoQedrfcbVr/WFd/j1XljnbtVn0b46Z3bTw2JWkhPLfYDS8+xfkdHLnmF1/YnZYDuXv4K79nFIegPEjVUJVAxGQzFYVPYp+OfCMZsWT+R4sG5VAP9kGVdX3yF5u4t3qmQJiIMyrifLUbbkm+kQsdvtFjxPyteuyoS8+ISzrjArTBij6Fv+WgaxpPBWM7giT0UqOcQ==
X-YMail-OSG: Y48PDqIVM1mXWLXiKLd0c9eP7WOWuGCobReF.NN4P_YjQ2nBeax7lJZ_OorHve0
 kmTi3Mk2qUjVP2bQZs5tgvcaEk8vBb_wK53ZCvdf3GhQ8AzQ1wE0wXDKU0TyIlWbii4N7ZLmOvat
 U_lA11rjkUWAFZEyHXKT3lije9gQ7ZTugXGKtZhCivnjSh6cZx74reMPYjMwAWkGwbapb7nuQBd_
 7VmO1Y3OD6k61JQrQ6sVaNk4D4_3ZN3uwAgQk9ZrHBinIjcJ6Qj74qGVsLcUuMPSQyQNhNkTkNCr
 .T9ZY13PIeVwrJF5voydEPbY_UMmwEd.c8j2lEH7hcORcPs2UIR_nFxT8CoU_xDdLc6mVhZH.DGe
 Ujox9jRH5nxJJ_JnExuVabEsy6n_asL45oRwozqgq5ZNolylTAUAdIHMfcZcwdSo46.D5c_oZu8q
 2QK2PoUy5JmnlLB_YuQpzZM6kdwIoJNPkY24pGnDy_keYRFLSct9.9KYdSi7uOOLzYOGGliJtv86
 dM2bsdt5GAWQMNQRpS2nkh9S5tZ1jhsakxpNnU.sbI3g.4OGgQSW0zKUn3b0PTBw5zDEYcM94LoG
 2nipe8Zu6.f98D6wsNjUWUUL5QfAQLd1B1iGjkapeCPdowWbMr8Hfi4uSuge1Rx7OWj9x8M38AUa
 NjmnapMDp2vyPffjDDQ6BCkCRvf2lBOVsI46kBlZj2HwAw5CxncFU1_.Kkalbx0lWVR6BfqRqvxF
 CVPdLmP4q_tE2pTbGIcnmbcmimKNLWTSV.u3cZdPylvBfByCQ8FNoAc3o6xFb.T8Dlm5kxJTijWU
 fI6L6ml.1cSNtEF8ej_KRXpxvJSwKN89iXyGbZ6cJZxcz0IdV29jt3HnZWu_c.CcQ_ysNQD5gHHP
 HGCSK9yJxiczkGwKjnTz1eWvvyVo7b9VArZxlIA4HBrnmKin4xWG24InxvcSjALhmyfTqyuSSTUT
 ynzRcWN1uoD.lrI9rEcc5UfnvRcesVh3nN4B15DqX9iHFuLyqAGO6Zh9zax4NpaO2WMQZzOarEzM
 R46ZlOo68kfoXBmzhuO0q99_912Qv2B2WjW1gouVXfRpvSthCdGStJkOB6Sl3kzMi5aeA7ZmxX1X
 HE_zUaYx4Hiq16Ua.wqwXonmPAR3lALIK3sKYrbYvj2ogGmmYqn1WjZ2r.X21DEByO0Wjcmym6FH
 U3VhyIIkFSBlfRfN9jwgLvjRoY.sWN9G1rfxY9JMmvMMZkXA8_HXqLp91SnY9tMpePzl1gNnZ0ia
 gwL5jpQfL.J1M4jrSCVzcBHwVXBcVOgtLfpgIozMfwFYc4FoaT.s7.ig4XCnF1Ub4j1j4ICAN_Xo
 kXmvhOFAnF_LLrkOqKAE_yGOO6Wo.U0WEpSOAvyEPkoAQMHoIAX11pGcPY4_fzx__34PpNEYxO1Q
 .7oNwM1fkI1b1mz6JGtEhqlor5lgkqPaVIWmT3qdjpMrw_ANKYVEjgIBZd_gjGG0XeqY5V3wyyru
 epQ8qaqw2z70s2dWXKLUHCbxAzy0Vkvd9uGGW9aAp4qxJbTI.znEC7.2REJOB2oQ7aV8l7f3nzwe
 ZyCH2r1qnE6DjMhHVEneT78DeSD1Hcryw4VsXy0riYXyRYOOtTDcucIO83mwN.CeiyS.BhgnaFHv
 E.bM6gljo9ajbfwfxd_1Nn6zN8BYglixTVphvxRJAgJ.dYjYbpfPXAL2AzpCkuyAeWj5uUJ4eb7v
 47rhFQay8MWWlyAAOR.8Z4RuUSQKj5B1xWDn1.uBZuLGFeEaTfxh22nlPMQlB5o0zZe_2gRN0E4G
 iphEVpPwLNkLigvfwy9X5tL_aIFNC1lpT_Bm9h70hNxGEZOrzbwpHH6zX7G.83Gay1k1QTx_69Hk
 yz3pXop1usnRGy1CMDioIc3DerliAM79kbq46olQsXIez0QWPPs0zFBPzo2XenPr2JGY6Flpsnqg
 dZI3h.3y0TYHLuZ4YrV4nRNg92y4NVyK7iWxKBig_mWwJoVadn6yWuraDKAr4g7dkfdFHyOzWkjX
 KmuAMFwvXgTxMvk2WwuEcoDPJ_sUF_miHILuCTnMQovBGJLTQnlKmHOkZlFIA4w22cfCpdvfLufR
 6Aet90uKcisKIuKGektnoUdXRGop679F6R2q11eqpzZYqrlzKuvn5R9AL9P.7VFkQE0ah3o3L3i8
 iAd13SA.tr8SM7qhkjxAxmWMlLU_1Xt7Lzut3zLY5vCrFiA2HA9HALWqmC4XTy0mWIiVz6hvpwJU
 vT8Zgx1x4MnZBbAPGqM_gUeD0XP27GNk3n9wpbsX0KzLjobeEdwuShGZ__R1kHHnMb.mpOqQvJiF
 oJzYUAGba59acTXoP9dc5gVKPwapDI9KUZaddrH1REglZmCIpeQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 2 May 2022 18:45:27 +0000
Received: by hermes--canary-production-gq1-647b99747d-ndj76 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5b5e79f7177bfcb5337654a257fe1148;
          Mon, 02 May 2022 18:45:23 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
From: Mark Millard 
In-Reply-To: <5684AD66-9C03-4C01-AC4B-A80D98D9D01A@yahoo.com>
Date: Mon, 2 May 2022 11:45:21 -0700
Cc: Hans Petter Selasky ,
 Bakul Shah ,
 freebsd-net@freebsd.org,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7072ADCF-ED5C-4EC5-8222-0F32E99F25A6@yahoo.com>
References: 
 <20220430021207.GA7600@www.zefox.net>
 
 <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
 <20220502011312.GA15807@www.zefox.net>
 <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
 <20220502155334.GA17962@www.zefox.net>
 <5684AD66-9C03-4C01-AC4B-A80D98D9D01A@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KsX8t5TjPz4QxT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tmpaG4Hj;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2648
Lines: 66

I just saw something odd when trying to test again.

I did not manage to capture the earlier display updates
but when it first connected it had a list of "(waiting
for reply)" lines from 17. to 27. with www.zefox.org
at 28. That range got shorter in steps but fairly
rapidly. Before the 18. to 28. showed up it sat at
17. (waiting for reply) for a while.

I finally captured it with www.zefox.org at 20. :

                                     My traceroute  [v0.95]
amd64_ZFS (192.168.1.120) -> www.zefox.org (50.1.20.28)                =
2022-05-02T11:36:06-0700
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets           =
    Pings
 Host                                                Loss%   Snt   Last  =
 Avg  Best  Wrst StDev
 1. 192.168.1.1                                       0.0%    30    0.2  =
 0.8   0.2   1.5   0.4
 2. 172.30.26.66                                      0.0%    30   69.5  =
70.0  42.1 138.0  19.7
 3. 68.85.243.77                                      0.0%    30   38.8  =
49.3  38.8  61.5   6.7
 4. 24.124.129.106                                    0.0%    30   64.0  =
52.2  10.1 109.4  14.7
 5. 96.216.60.165                                     0.0%    30   62.6  =
47.6  17.3  62.6  12.0
 6. 68.85.243.197                                     0.0%    29   66.9  =
55.0  28.4  78.3  10.5
 7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    29   68.9  =
57.8  28.6 122.3  14.9
 8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    29   65.7  =
57.8  49.5 120.7  13.5
 9. (waiting for reply)
10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    29   78.6  =
74.3  63.7 135.2  15.4
11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    29   83.0  =
74.0  62.1 153.8  20.6
12. 38.104.141.82                                     0.0%    29  106.6  =
78.3  62.0 168.3  25.7
13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    29   83.7  =
73.4  58.9 134.8  13.5
14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    29   60.6  =
72.0  50.8 135.6  14.3
15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    29  104.8  =
75.1  44.2 136.7  18.8
16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    29   85.4  =
73.8  48.2 136.3  14.4
17. (waiting for reply)
18. (waiting for reply)
19. (waiting for reply)
20. www.zefox.org                                    86.2%    29  160.4 =
144.9 102.1 160.5  28.6

www.zefox.org ended up at 17. and stayed there
once it got there.

I've no clue if this observation is of any use.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue May  3 02:34:45 2022
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 64D381ABC0C7;
	Tue,  3 May 2022 02:34:49 +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 4KskZJ2Xmrz4dGx;
	Tue,  3 May 2022 02:34:48 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2432Yk52019669
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 2 May 2022 19:34:46 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2432YkjW019668;
	Mon, 2 May 2022 19:34:46 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 2 May 2022 19:34:45 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Hans Petter Selasky , Bakul Shah ,
        freebsd-net@freebsd.org, freebsd-arm@freebsd.org,
        bob prohaska 
Subject: Re: 60+% ping packet loss on Pi3 under -current and stable-13
Message-ID: <20220503023445.GB19378@www.zefox.net>
References: <20220501181254.GA14961@www.zefox.net>
 
 
 <20220501232757.GA15446@www.zefox.net>
 <2F4599BF-EEDA-4D08-AB6E-7AA9F410B2C5@yahoo.com>
 <20220502011312.GA15807@www.zefox.net>
 <6f57cd1d-e1d4-5ca4-e301-2633c1d4c1fa@selasky.org>
 <20220502155334.GA17962@www.zefox.net>
 <5684AD66-9C03-4C01-AC4B-A80D98D9D01A@yahoo.com>
 <7072ADCF-ED5C-4EC5-8222-0F32E99F25A6@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: <7072ADCF-ED5C-4EC5-8222-0F32E99F25A6@yahoo.com>
X-Rspamd-Queue-Id: 4KskZJ2Xmrz4dGx
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.52 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.995];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 RCPT_COUNT_FIVE(0.00)[6];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.43)[-0.430];
	 MLMMJ_DEST(0.00)[freebsd-net,freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3144
Lines: 54

On Mon, May 02, 2022 at 11:45:21AM -0700, Mark Millard wrote:
> I just saw something odd when trying to test again.
> 
> I did not manage to capture the earlier display updates
> but when it first connected it had a list of "(waiting
> for reply)" lines from 17. to 27. with www.zefox.org
> at 28. That range got shorter in steps but fairly
> rapidly. Before the 18. to 28. showed up it sat at
> 17. (waiting for reply) for a while.
> 
> I finally captured it with www.zefox.org at 20. :
> 
>                                      My traceroute  [v0.95]
> amd64_ZFS (192.168.1.120) -> www.zefox.org (50.1.20.28)                2022-05-02T11:36:06-0700
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>                                                        Packets               Pings
>  Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 192.168.1.1                                       0.0%    30    0.2   0.8   0.2   1.5   0.4
>  2. 172.30.26.66                                      0.0%    30   69.5  70.0  42.1 138.0  19.7
>  3. 68.85.243.77                                      0.0%    30   38.8  49.3  38.8  61.5   6.7
>  4. 24.124.129.106                                    0.0%    30   64.0  52.2  10.1 109.4  14.7
>  5. 96.216.60.165                                     0.0%    30   62.6  47.6  17.3  62.6  12.0
>  6. 68.85.243.197                                     0.0%    29   66.9  55.0  28.4  78.3  10.5
>  7. be-36241-cs04.seattle.wa.ibone.comcast.net        0.0%    29   68.9  57.8  28.6 122.3  14.9
>  8. be-2412-pe12.seattle.wa.ibone.comcast.net         0.0%    29   65.7  57.8  49.5 120.7  13.5
>  9. (waiting for reply)
> 10. be2075.ccr21.sfo01.atlas.cogentco.com             0.0%    29   78.6  74.3  63.7 135.2  15.4
> 11. be2379.ccr31.sjc04.atlas.cogentco.com             0.0%    29   83.0  74.0  62.1 153.8  20.6
> 12. 38.104.141.82                                     0.0%    29  106.6  78.3  62.0 168.3  25.7
> 13. 0.xe-0-3-0.scrm-gw1.scrmca01.sonic.net            0.0%    29   83.7  73.4  58.9 134.8  13.5
> 14. 0.xe-0-0-0.cr1.scrmca13.sonic.net                 0.0%    29   60.6  72.0  50.8 135.6  14.3
> 15. gig1-1-1.gw.wscrca11.sonic.net                    0.0%    29  104.8  75.1  44.2 136.7  18.8
> 16. gig1-1-1.gw.davsca11.sonic.net                    0.0%    29   85.4  73.8  48.2 136.3  14.4
> 17. (waiting for reply)
> 18. (waiting for reply)
> 19. (waiting for reply)
> 20. www.zefox.org                                    86.2%    29  160.4 144.9 102.1 160.5  28.6
> 
> www.zefox.org ended up at 17. and stayed there
> once it got there.
> 
> I've no clue if this observation is of any use.
> 

It's consistent with my observations of keyboard interaction vis ssh.
Input sometimes stop echoing for tens of seconds, then all goes through
after the pause. Maybe this really has little or nothing to do with the
network, it's just that all my interaction with the two machines is via
the network. Neither has had a console and keyboard since I got the Pi4.

Thanks for bringing your observations to the discussion!

bob prohaska
 

From nobody Tue May  3 12:36:07 2022
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 7DE081AC593D
	for ; Tue,  3 May 2022 12:36:23 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.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 (4096 bits) client-digest SHA256)
	(Client CN "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4KszwQ3DK3z3CJb
	for ; Tue,  3 May 2022 12:36:22 +0000 (UTC)
	(envelope-from qroxana@protonmail.com)
Date: Tue, 03 May 2022 12:36:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail2; t=1651581375;
	bh=XupXUCnRJOhITh2B2Yh1HGJRUEUZrQgV9tVmeLA1RiE=;
	h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
	 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
	 Feedback-ID:Message-ID;
	b=a4VzN04gxfN2R+s6qq6eD4PoU34yDtMqwSssY+3yoGdUzFFjmJjQrZ482He3C8+5u
	 vsb1ZEssWe9k1HplDJ8odss0OPLSStgWznEoWIGZEZKRnV19058dYfno3ml4OUSKQN
	 GfIU9gc5BElWBC43zxTiKYoFOhyWBBwwjIbtohwahZ38Cm/pys39lG6MtvlHNxJVeK
	 i2UV9h1Q1s+kmyavTZWscDUxEgNWQ8pFfjWCpNdSTi6cROXOwzKHssJniOQJ2K0TBZ
	 pioXayuVNv3XkX6F6s8w/PtOPkLpMc4zPWf8xpIMIw3BYLpmwNHe83Qd7C61zcQczt
	 lm0whKegcZN0w==
To: Kristof Provost 
From: qroxana 
Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Reply-To: qroxana 
Subject: Re: Kernel panic on armv7 when PF is enabled
Message-ID: <83Y13opkQnjBkBmEsEU8Y9TJX06SXVmwSnCQfQCt0a6fInNoiEVaUcEnnrWr3h34dcFZJosg8AksGQr1v9zW_ljw5JIZIpBRm4qR5ga9FZM=@protonmail.com>
In-Reply-To: 
References:  
Feedback-ID: 29996633:user:proton
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: 4KszwQ3DK3z3CJb
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=a4VzN04g;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.27 as permitted sender) smtp.mailfrom=qroxana@protonmail.com
X-Spamd-Result: default: False [-0.02 / 15.00];
	 HAS_REPLYTO(0.00)[qroxana@protonmail.com];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[protonmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24];
	 MIME_GOOD(-0.10)[text/plain];
	 FREEMAIL_REPLYTO(0.00)[protonmail.com];
	 NEURAL_HAM_LONG(-0.98)[-0.981];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.96)[0.961];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.999];
	 DKIM_TRACE(0.00)[protonmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[protonmail.com];
	 ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4116
Lines: 120


On Monday, May 2nd, 2022 at 9:02 AM, Kristof Provost  wrote=
:


> On 1 May 2022, at 5:13, qroxana wrote:
>
> > After git bisecting the panic started since this commit.
> >
> > commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113
> >
> > Author: Kristof Provost <
> > kp@FreeBSD.org
> >
> > Date: Mon Feb 14 20:09:54 2022 +0100
> >
> > vlan: allow net.link.vlan.mtag_pcp to be set per vnet
> >
> > The primary reason for this change is to facilitate testing.
> >
> > MFC after: 1 week
> >
> > sys/net/if_ethersubr.c | 9 +++++----
> >
> > sys/net/if_vlan.c | 5 +++--
> >
> > 2 files changed, 8 insertions(+), 6 deletions(-)
> >
> > The armv7 board boots from a NFS root,
> >
> > it can boot without any problem if PF is disabled.
> >
> > Any helps?
> >
> > add host ::1: gateway lo0 fib 0: route already in table
> > add net fe80::: gateway ::1
> > add net ff02::: gateway ::1
> > add net ::ffff:0.0.0.0: gateway ::1
> > add net ::0.0.0.0: gateway ::1
> > Enabling pf.
> > Kernel page fault with the following non-sleepable locks held:
> > shared rm pf rulesets (pf rulesets) r =3D 0 (0xe3099430) locked @ /usr/=
src/sys/netpfil/pf/pf.c:6493
> > exclusive rw tcpinp (tcpinp) r =3D 0 (0xdb748d88) locked @ /usr/src/sys=
/netinet/tcp_usrreq.c:1008
> > stack backtrace:
> > #0 0xc0355cac at witness_debugger+0x7c
> > #1 0xc0356ef0 at witness_warn+0x3fc
> > #2 0xc05ec048 at abort_handler+0x1d8
> > #3 0xc05cb5ac at exception_exit+0
> > #4 0xe3083c10 at pf_syncookie_validate+0x60
> > #5 0xe30496a8 at pf_test+0x518
> > #6 0xe306d768 at pf_check_out+0x30
> > #7 0xc0415b44 at pfil_run_hooks+0xbc
> > #8 0xc0445cfc at ip_output+0xce8
> > #9 0xc045bc9c at tcp_default_output+0x20ac
> > #10 0xc0471eb4 at tcp_usr_send+0x1ac
> > #11 0xc0389464 at sosend_generic+0x490
> > #12 0xc0389790 at sosend+0x64
> > #13 0xc0502888 at clnt_vc_call+0x560
> > #14 0xc05009d8 at clnt_reconnect_call+0x170
> > #15 0xc01e7b14 at newnfs_request+0xb20
> > #16 0xc0230218 at nfscl_request+0x60
> > #17 0xc020d9bc at nfsrpc_getattr+0xb0
> > Fatal kernel mode data abort: 'Alignment Fault' on read
> > trapframe: 0xdf1f1c90
> > FSR=3D00000001, FAR=3Dd7840264, spsr=3D40000013
> > r0 =3D6a228eda, r1 =3Ddac0d785, r2 =3Dd7840264, r3 =3Ddb5527c0
> > r4 =3Ddf1f1e00, r5 =3Ddac0d75f, r6 =3D00000018, r7 =3Dd9422c00
> > r8 =3Dc093e5e4, r9 =3D00000001, r10=3Ddf1f1f5c, r11=3Ddf1f1d38
> > r12=3De3098dd0, ssp=3Ddf1f1d20, slr=3De3083bdc, pc =3De3083c10
>
> The commit you point at is entirely unrelated to the code where the panic=
 occurred, so I=E2=80=99m pretty sure something went wrong in your bisect.
>
> The backtrace would suggest the issue occurs in the pf_syncookie_validate=
() function, and likely in the line `if (atomic_load_64(&V_pf_status.syncoo=
kies_inflight[cookie.flags.oddeven]) =3D=3D 0)`
>
> The obvious way for that to panic would be to call it without the curvnet=
 context set, but pf_test() uses it earlier, so that=E2=80=99s going to be =
fine.
>
> Given that this is unique to armv7 I=E2=80=99d recommend talking to the a=
rmv7 maintainer about 64 bit atomic operations.
>
> You can probably avoid the atomic load with this patch (and not enabling =
syncookie support):
>
>     diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_synco=
okies.c
>     index 5230502be30c..c86d469d3cef 100644
>     --- a/sys/netpfil/pf/pf_syncookies.c
>     +++ b/sys/netpfil/pf/pf_syncookies.c
>     @@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd)
>             ack =3D ntohl(pd->hdr.tcp.th_ack) - 1;
>             cookie.cookie =3D (ack & 0xff) ^ (ack >> 24);
>
>     +       if (V_pf_status.syncookies_mode =3D=3D PF_SYNCOOKIES_NEVER)
>     +               return (0);
>     +
>             /* we don't know oddeven before setting the cookie (union) */
>              if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.f=
lags.oddeven])
>                 =3D=3D 0)
>
>
> That shouldn=E2=80=99t be required though.
>
> Br,
> Kristof

Thank you sir. You were right.
I tested patch with the latest kernel.
It can boot successfully with the patch,
and still got kernel panic without the patch.





From nobody Tue May  3 14:09:35 2022
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 76F2C1ABD56B;
	Tue,  3 May 2022 14:09:43 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt2054TH9z3lLX;
	Tue,  3 May 2022 14:09:41 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from [IPV6:2001:470:71:d47:4c06:dff6:5a69:7c54] ([IPv6:2001:470:71:d47:4c06:dff6:5a69:7c54])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 243E9ZNZ091945
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Tue, 3 May 2022 16:09:36 +0200 (CEST)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1651586976;
	bh=sbU+D8vc69kzOtQsmtkqJvuT48xz+hFgrwURDpSTp+U=;
	h=Date:To:Cc:References:From:Subject:In-Reply-To;
	b=KCWVJHBDpl1Q3UIMc4Atj55Z/32FB6P2RsSuPa6f9ghNkmYqASU3jeBU4O7eADP8J
	 nAACqUS1kHt2A7+ZVY92djoVhmjkFspsYMbu638ZOvxHutA0SvrPq10vm/+5KzTtgd
	 AJsWSrDeb4VvcWHeUYhiUyx9EyTQrdRqQ9hPHmbHEE4LK/KIJJ/BAJ5gKBuFJ7SlN8
	 C7UTsRMEJmHVewJEFcRh01ZYNlWyni6g58Q2clDfpq2N4bVN3rPiQk5TcmS+LFfEJq
	 NCJd1gU2g8+6LIoQR//l8gl/zqt/4NfQRrDhVL2uPBzLiNKBT5D0AZXgjZe0qIQJTb
	 S98CVDYjEjD0g==
Message-ID: 
Date: Tue, 3 May 2022 16:09:35 +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:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: pl
To: Kristof Provost , qroxana 
Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
References: 
 
From: Marek Zarychta 
Subject: Re: Kernel panic on armv7 when PF is enabled
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Lg0N7bEEfhhztaGlbQeZa0qv"
X-Rspamd-Queue-Id: 4Kt2054TH9z3lLX
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=KCWVJHBD;
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl
X-Spamd-Result: default: False [-5.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	 HAS_ATTACHMENT(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 SIGNED_PGP(-2.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	 MIME_BASE64_TEXT(0.10)[];
	 DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current];
	 FREEMAIL_TO(0.00)[FreeBSD.org,protonmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	 ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7572
Lines: 118

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Lg0N7bEEfhhztaGlbQeZa0qv
Content-Type: multipart/mixed; boundary="------------snUu1J87zM0pGEKwNJnUWVep";
 protected-headers="v1"
From: Marek Zarychta 
To: Kristof Provost , qroxana 
Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Message-ID: 
Subject: Re: Kernel panic on armv7 when PF is enabled
References: 
 
In-Reply-To: 

--------------snUu1J87zM0pGEKwNJnUWVep
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VyBkbml1IDIuMDUuMjAyMiBvwqAxMTowMiwgS3Jpc3RvZiBQcm92b3N0IHBpc3plOg0KPiBP
biAxIE1heSAyMDIyLCBhdCA1OjEzLCBxcm94YW5hIHdyb3RlOg0KPiANCj4gICAgIEFmdGVy
IGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0ZWQgc2luY2UgdGhpcyBjb21taXQuDQo+
IA0KPiAgICAgY29tbWl0IDc4YmMzZDVlMTcxMmJjMTY0OWFhNTU3NGQyYjhkMTUzZjk2NjUx
MTMNCj4gDQo+ICAgICBBdXRob3I6IEtyaXN0b2YgUHJvdm9zdCA8DQo+ICAgICBrcEBGcmVl
QlNELm9yZw0KPiANCj4gICAgIERhdGU6IE1vbiBGZWIgMTQgMjA6MDk6NTQgMjAyMiArMDEw
MA0KPiANCj4gICAgIHZsYW46IGFsbG93IG5ldC5saW5rLnZsYW4ubXRhZ19wY3AgdG8gYmUg
c2V0IHBlciB2bmV0DQo+IA0KPiAgICAgVGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNo
YW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3RpbmcuDQo+IA0KPiAgICAgTUZDIGFmdGVyOiAx
IHdlZWsNCj4gDQo+ICAgICBzeXMvbmV0L2lmX2V0aGVyc3Vici5jIHwgOSArKysrKy0tLS0N
Cj4gDQo+ICAgICBzeXMvbmV0L2lmX3ZsYW4uYyB8IDUgKysrLS0NCj4gDQo+ICAgICAyIGZp
bGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkNCj4gDQo+ICAg
ICBUaGUgYXJtdjcgYm9hcmQgYm9vdHMgZnJvbSBhIE5GUyByb290LA0KPiANCj4gICAgIGl0
IGNhbiBib290IHdpdGhvdXQgYW55IHByb2JsZW0gaWYgUEYgaXMgZGlzYWJsZWQuDQo+IA0K
PiAgICAgQW55IGhlbHBzPw0KPiANCj4gICAgIGFkZCBob3N0IDo6MTogZ2F0ZXdheSBsbzAg
ZmliIDA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUNCj4gICAgIGFkZCBuZXQgZmU4MDo6OiBn
YXRld2F5IDo6MQ0KPiAgICAgYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxDQo+ICAgICBh
ZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQ0KPiAgICAgYWRkIG5ldCA6OjAu
MC4wLjA6IGdhdGV3YXkgOjoxDQo+ICAgICBFbmFibGluZyBwZi4NCj4gICAgIEtlcm5lbCBw
YWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBhYmxlIGxvY2tzIGhlbGQ6
DQo+ICAgICBzaGFyZWQgcm0gcGYgcnVsZXNldHMgKHBmIHJ1bGVzZXRzKSByID0gMCAoMHhl
MzA5OTQzMCkgbG9ja2VkIEANCj4gICAgIC91c3Ivc3JjL3N5cy9uZXRwZmlsL3BmL3BmLmM6
NjQ5Mw0KPiAgICAgZXhjbHVzaXZlIHJ3IHRjcGlucCAodGNwaW5wKSByID0gMCAoMHhkYjc0
OGQ4OCkgbG9ja2VkIEANCj4gICAgIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF91c3JyZXEu
YzoxMDA4DQo+ICAgICBzdGFjayBiYWNrdHJhY2U6DQo+ICAgICAjMCAweGMwMzU1Y2FjIGF0
IHdpdG5lc3NfZGVidWdnZXIrMHg3Yw0KPiAgICAgIzEgMHhjMDM1NmVmMCBhdCB3aXRuZXNz
X3dhcm4rMHgzZmMNCj4gICAgICMyIDB4YzA1ZWMwNDggYXQgYWJvcnRfaGFuZGxlcisweDFk
OA0KPiAgICAgIzMgMHhjMDVjYjVhYyBhdCBleGNlcHRpb25fZXhpdCswDQo+ICAgICAjNCAw
eGUzMDgzYzEwIGF0IHBmX3N5bmNvb2tpZV92YWxpZGF0ZSsweDYwDQo+ICAgICAjNSAweGUz
MDQ5NmE4IGF0IHBmX3Rlc3QrMHg1MTgNCj4gICAgICM2IDB4ZTMwNmQ3NjggYXQgcGZfY2hl
Y2tfb3V0KzB4MzANCj4gICAgICM3IDB4YzA0MTViNDQgYXQgcGZpbF9ydW5faG9va3MrMHhi
Yw0KPiAgICAgIzggMHhjMDQ0NWNmYyBhdCBpcF9vdXRwdXQrMHhjZTgNCj4gICAgICM5IDB4
YzA0NWJjOWMgYXQgdGNwX2RlZmF1bHRfb3V0cHV0KzB4MjBhYw0KPiAgICAgIzEwIDB4YzA0
NzFlYjQgYXQgdGNwX3Vzcl9zZW5kKzB4MWFjDQo+ICAgICAjMTEgMHhjMDM4OTQ2NCBhdCBz
b3NlbmRfZ2VuZXJpYysweDQ5MA0KPiAgICAgIzEyIDB4YzAzODk3OTAgYXQgc29zZW5kKzB4
NjQNCj4gICAgICMxMyAweGMwNTAyODg4IGF0IGNsbnRfdmNfY2FsbCsweDU2MA0KPiAgICAg
IzE0IDB4YzA1MDA5ZDggYXQgY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MA0KPiAgICAgIzE1
IDB4YzAxZTdiMTQgYXQgbmV3bmZzX3JlcXVlc3QrMHhiMjANCj4gICAgICMxNiAweGMwMjMw
MjE4IGF0IG5mc2NsX3JlcXVlc3QrMHg2MA0KPiAgICAgIzE3IDB4YzAyMGQ5YmMgYXQgbmZz
cnBjX2dldGF0dHIrMHhiMA0KPiAgICAgRmF0YWwga2VybmVsIG1vZGUgZGF0YSBhYm9ydDog
J0FsaWdubWVudCBGYXVsdCcgb24gcmVhZA0KPiAgICAgdHJhcGZyYW1lOiAweGRmMWYxYzkw
DQo+ICAgICBGU1I9MDAwMDAwMDEsIEZBUj1kNzg0MDI2NCwgc3Bzcj00MDAwMDAxMw0KPiAg
ICAgcjAgPTZhMjI4ZWRhLCByMSA9ZGFjMGQ3ODUsIHIyID1kNzg0MDI2NCwgcjMgPWRiNTUy
N2MwDQo+ICAgICByNCA9ZGYxZjFlMDAsIHI1ID1kYWMwZDc1ZiwgcjYgPTAwMDAwMDE4LCBy
NyA9ZDk0MjJjMDANCj4gICAgIHI4ID1jMDkzZTVlNCwgcjkgPTAwMDAwMDAxLCByMTA9ZGYx
ZjFmNWMsIHIxMT1kZjFmMWQzOA0KPiAgICAgcjEyPWUzMDk4ZGQwLCBzc3A9ZGYxZjFkMjAs
IHNscj1lMzA4M2JkYywgcGMgPWUzMDgzYzEwDQo+IA0KPiANCj4gVGhlIGNvbW1pdCB5b3Ug
cG9pbnQgYXQgaXMgZW50aXJlbHkgdW5yZWxhdGVkIHRvIHRoZSBjb2RlIHdoZXJlIHRoZSAN
Cj4gcGFuaWMgb2NjdXJyZWQsIHNvIEnigJltIHByZXR0eSBzdXJlIHNvbWV0aGluZyB3ZW50
IHdyb25nIGluIHlvdXIgYmlzZWN0Lg0KDQpJIHdhcyBleHBlcmllbmNpbmcgdGhpcyBwYW5p
YyBhbHNvIHJ1bm5pbmcgRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzEgDQptYWluLW4yNTMwMjgt
MmVjOWE0MjdjODU6IFR1ZSBGZWIgIDggMTc6NDk6MjUgQ0VUIDIwMjIgb24gYXJtdjcsIHNv
IGl0J3MgDQp1bnJlbGF0ZWQgdG8gYWZvcmVtZW50aW9uZWQgY29tbWl0IHdoaWNoIGlzIGRh
dGVkIDIwMjItMDItMTQuDQoNCkl0J3MgdmVyeSBpbnRlcmVzdGluZyBhbmQgd2VpcmQgYnVn
LCBsb2FkaW5nIHBmLmtvLCBlbmFibGluZyBQRiwgbG9hZGluZyANCnRoZSBydWxlcyB3b3Jr
IGFzIGV4cGVjdGVkLCBidXQgcHJvY2Vzc2luZyB0aGUgZmlsdGVyZWQgdHJhZmZpYyBieSBQ
RiANCnRyaWdnZXJzIHRoZSBwYW5pYy4NCg0KPiANCj4gVGhlIGJhY2t0cmFjZSB3b3VsZCBz
dWdnZXN0IHRoZSBpc3N1ZSBvY2N1cnMgaW4gdGhlIA0KPiBwZl9zeW5jb29raWVfdmFsaWRh
dGUoKSBmdW5jdGlvbiwgYW5kIGxpa2VseSBpbiB0aGUgbGluZSB8aWYgDQo+IChhdG9taWNf
bG9hZF82NCgmVl9wZl9zdGF0dXMuc3luY29va2llc19pbmZsaWdodFtjb29raWUuZmxhZ3Mu
b2RkZXZlbl0pIA0KPiA9PSAwKXwNCj4gDQo+IFRoZSBvYnZpb3VzIHdheSBmb3IgdGhhdCB0
byBwYW5pYyB3b3VsZCBiZSB0byBjYWxsIGl0IHdpdGhvdXQgdGhlIA0KPiBjdXJ2bmV0IGNv
bnRleHQgc2V0LCBidXQgcGZfdGVzdCgpIHVzZXMgaXQgZWFybGllciwgc28gdGhhdOKAmXMg
Z29pbmcgdG8gDQo+IGJlIGZpbmUuDQo+IA0KPiBHaXZlbiB0aGF0IHRoaXMgaXMgdW5pcXVl
IHRvIGFybXY3IEnigJlkIHJlY29tbWVuZCB0YWxraW5nIHRvIHRoZSBhcm12NyANCj4gbWFp
bnRhaW5lciBhYm91dCA2NCBiaXQgYXRvbWljIG9wZXJhdGlvbnMuDQo+IA0KPiBZb3UgY2Fu
IHByb2JhYmx5IGF2b2lkIHRoZSBhdG9taWMgbG9hZCB3aXRoIHRoaXMgcGF0Y2ggKGFuZCBu
b3QgZW5hYmxpbmcgDQo+IHN5bmNvb2tpZSBzdXBwb3J0KToNCj4gDQo+IHxkaWZmIC0tZ2l0
IGEvc3lzL25ldHBmaWwvcGYvcGZfc3luY29va2llcy5jIA0KPiBiL3N5cy9uZXRwZmlsL3Bm
L3BmX3N5bmNvb2tpZXMuYyBpbmRleCA1MjMwNTAyYmUzMGMuLmM4NmQ0NjlkM2NlZiAxMDA2
NDQgDQo+IC0tLSBhL3N5cy9uZXRwZmlsL3BmL3BmX3N5bmNvb2tpZXMuYyArKysgDQo+IGIv
c3lzL25ldHBmaWwvcGYvcGZfc3luY29va2llcy5jIEBAIC0zMTMsNiArMzEzLDkgQEAgDQo+
IHBmX3N5bmNvb2tpZV92YWxpZGF0ZShzdHJ1Y3QgcGZfcGRlc2MgKnBkKSBhY2sgPSANCj4g
bnRvaGwocGQtPmhkci50Y3AudGhfYWNrKSAtIDE7IGNvb2tpZS5jb29raWUgPSAoYWNrICYg
MHhmZikgXiAoYWNrID4+IA0KPiAyNCk7ICsgaWYgKFZfcGZfc3RhdHVzLnN5bmNvb2tpZXNf
bW9kZSA9PSBQRl9TWU5DT09LSUVTX05FVkVSKSArIHJldHVybiANCj4gKDApOyArIC8qIHdl
IGRvbid0IGtub3cgb2RkZXZlbiBiZWZvcmUgc2V0dGluZyB0aGUgY29va2llICh1bmlvbikg
Ki8gaWYgDQo+IChhdG9taWNfbG9hZF82NCgmVl9wZl9zdGF0dXMuc3luY29va2llc19pbmZs
aWdodFtjb29raWUuZmxhZ3Mub2RkZXZlbl0pIA0KPiA9PSAwKSB8DQo+IA0KPiBUaGF0IHNo
b3VsZG7igJl0IGJlIHJlcXVpcmVkIHRob3VnaC4NCj4gDQo+IEJyLA0KPiBLcmlzdG9mDQo+
IA0KDQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg==

--------------snUu1J87zM0pGEKwNJnUWVep--

--------------Lg0N7bEEfhhztaGlbQeZa0qv
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmJxN58FAwAAAAAACgkQHZW8vIFppoKj
ZwgAhhfGV0nHZDLk9AMkfsmvUDKMH9CqikEAtFaQccrVdpqoY4AjaJsmaR/Kz1WyAOVj0IfhzZXb
4QAUyO1IajHp1+z98mt3Gp0s1B69VbsInlRGFOzCyD8nCXT4MPSAG0rU2KX9iU9T70K5TgkaGIsq
v4EQVHu6KuoXXh8Bk1FK4xdmzzoZ8FD5QSsWCYfN7ianb06ShLcn/K8+C3rH88ZN8GDlPuJ5aQtT
vYGM9dP+vyWvGLEJSWU1twGBulbsZfEWPN9NUEi42Xq3i8Uuev7tSX4AYahmyvNsrOzwj0CF6jRu
a1xLEuoo45bN4R4mJBO67mT+EhVbJw+VhbQ5wcDWtA==
=E5na
-----END PGP SIGNATURE-----

--------------Lg0N7bEEfhhztaGlbQeZa0qv--

From nobody Tue May  3 22:38:39 2022
X-Original-To: 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 579631AAFA6C
	for ; Tue,  3 May 2022 22:38:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4KtFHZ5hVSz3Lq7
	for ; Tue,  3 May 2022 22:38:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617523; bh=vMQbYLt5dp5WNGsFjMRTEWy1oVp4booHFQCi+Lq0tPc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Irb/avR8XyIVsyOFfRj8qIeYlN51nOAxhmQtBRuw41pxnQSAt8xMfjCxWK1Du56EMZ6YgJlNx52UDw89GaoYyf7AiKw7ghjn9Veq2Ris5cVYAJ6QoHJxEOSqheMc6b6+ee+8h60r9OBjO8qRlyGzgKIYKoJmDCfMZqqI4eFTxe/ExPXihNq6uACQu0NYMOh1UXKh0GTQI/g7pVAruUp0e4WjThmj45x9v5EBHRa5Krt3mfB6XFa1siV51CN6NxtkXW0Wea3rOXE4R5NopskSSkTUJY+WCo4PmvUiwC0g00qDwJmHbK75NoCq5rDouzcGWr8Lrw/7EGg0w8mhfyRgOw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617523; bh=g7dPbeUTwRVd3NIDOKFAohD5qOHoGmjZov9iQpuOK9L=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f/Dl6y0TvXb9Eg+mSWpBohq2rkSvQ/ouZaUzTq0IIKcEWJtiWrNKbp/trdTosnHTXD3aM9b2YQcvkIVBnmUMG6lkr5IocajX1FDoHkDCoW2G26OyrxbXcVNONA3f7OMbstIeYBUJnzqqTuPFOym12hr9Jo9ZIFAGzKuBrl5BFrou9nN4aZvrebIooPVNj49rG9qWHBcs2LiQ305Mihjj8swda6raI1rMPBjb120GlR0Mg3qinxIJpjjYrNKK/QuoUX9sXNPQwwrfOXspWE2nFyBE8M3Qg7Bi8trOqubCEPN/9zt3XKgehh+Mg40VAe9e1UfUT7WutYQHU5mc9TnGzA==
X-YMail-OSG: E4_KDiIVM1n1iQ3HP6vvnMDQPN9XOBqtBU8ywV.4dTAcapRd7FJOWNqZNUq3yD2
 Zo6sG.z38vgTTizTINlKZlew0IjLwz73BOHDHO2ijlPfMIaLzI8ML1pw87Z.7GielJrpMsF3WxZk
 ixWqYyGaeCYMRBdxrZQpL75fEtR9wXK7JdsZpfsNo3d9W8ypOCIX6DZGc8hgoWN5Gqd_YeOB9hvn
 R_JJzaJJayzh4Selfi3VriOcrobUc6HuGt7ALvTk.0bV30u3.qajzpTCZiVuxWXNn.8yFniYHyPd
 dRSvxRNhmuRfwLmtoOaYUJbqktJ.6SXcCiItOPrRbIMjAQ09FZV99QsswKINOkv50Fv2pjlj_Zyk
 fs5zkReJf6VXR9N4SP8PbmlfCPFOGes63fiHJOrA90JMlBW9rDOw0kQVQYlEUdkH2xjNJ_BejvKU
 FkVSGEknoEs4c_dIkfp0dyJT8_OcOERXfnyrRTzCPcWhiBCmiKsHsIe5WxfuLcWe00sH5q_03zMa
 yO5.fL4AnW1tD8f9qg_9RYH2cUhgJ_xV9d7xfPjpRdUSi7vCnk_cKGW.IhBndI4JvZhoCpoAJS_I
 uuk1rkyhdT8.DsYmaGM1b65JJcrlgbdXQsQbaQnpN0a9s.ZRmTy8fQQPKmtScp1nzWN4.XRUzi8Y
 mV2PeSZKtjNkwcJxHzKe9o8VCyFrlxNF8Oi2SkkLh58P3NwEIJyLiSNA32mqKWen5ufOrW5mv9m2
 rdBffKvZDnsPZjN7_CUWM8vx8NiHplwVGfzAYEJNSppBFj2YYSMq2GZh0OM6jw53LaSmSmlCGJy5
 O8UWzorR9nF9_U51XU4juoDIRdS1Ye74LqU5HHU.l7vHH_aKQ5lmS0IqieX4aeu5t3ewEcZ2ldd6
 938R9omNlBDTwgdP.rm5nlCGWKVgXdKTMwR_IUEtv8AlfBFQSI6O7qs9mb7XZV5oVmb_h6hVRRoj
 .2elVfMZIRHWDeeyuZHOBxbs7J_r1czeFenDZ95y6dSqBB0GOSQylHLDGFSQ13Q4Toi1gLZfnPA.
 2YWgtKr6swI4R4WrRFQDcALgE_3YNUbuxMBS2k3BRaykwcvFto5aZHLib3Gv_EuxzfO8CAdSk.ZA
 TpxLAiUSi42zyGfNdkVc6IAy7b9Q5acTe9C9Uq3AkKjlamgflheRsEYYUYQgLIr2nvcZahHQsNTS
 zXZEP4_gm2bacSSLcc6ACIhY7q.rWJUoMAZfnSsl5QnqKtJbJ6c9yoa_On42TCMuqG_0H2IZL7nh
 R1WEuCugwnwdmOXv3RjTxWlgCar7P8apL4snF8NQbSBHVrg5QFzz1g27SdihY62OG5YeU5WlymA1
 56PUWUMUXKB8LM_4cX8wZCUWx.WRCkfa0t.6QLAVeDezVzM5MRHarVJFaN9nIpxWdDI51zSKebY2
 QfgGBCo2rkGngCSHtOwxgk4uVFy.X2dtttqnpjj_6x6VQskihlXkgjCcM_kinew6dm_SGLjAArgi
 nnoTeUkbk64Zq1zhGhaumqG_rDAvVcNcFBInfe0d0HvcLLLW9ldF_mP53KA9Sxd5z3B8q__tZyhx
 QNTfOi3AcHeF54lxOOkI9g9duw2Myiv9Y2N9NtcKNZJw3S3sx_AcKfCq4BoJ__uC_6RPU4fQHDqI
 i2NdkNH5zxum0UTmzK6SlDbxef5IdGcN3_OivhhX2Mel7usuEmqqiTY4eg9_d0MT7bjkGzoyLvIj
 M8a95Ghwd32LvSjdA14ZQfuVoelXrerfPx6uFKBC7B3mxdeTwCsNOfSxZwDiH1LY.GtSYY1RsMEu
 oXA1rx_zxM1pP.c1aoxasi.J7op2Dsje4IlnAYIwlw5jlSxpPeawpnwTKdSwmAHefhAQLHIUQzl0
 Y3TeK1vTHip_Y.7QYMOAkknUgg9.8z0t6SJnnWRe8A.0NTuCdloUWhJTEG0gTGgUe8nQoRS160dA
 Rvuu49NrCOukXr7eHCOx4tAY7iEapaj3S36oKqcMDFMyHAX1LRjO6pBtuhp5SLZpndLImFNAfPm4
 Ib2ucpuzAfWtR.sE3MFUO5_zxmiOHwWz.IH5NYFGlVLL9Jc_Ta939EXMn5yHROrPjAbWMWNjUM2l
 L01fDASOX4PUrBz1N_fZNsKSVtCrRP.FSa9KKsdb2AJq0Kzlv1AnL2F.4O5jxSkEOih_sXd01pHY
 7KqSECIW7AoZ9ZEtkVtiCgwpXvIrd7tTNpKwah6FT7PsdJBGTK70wJIRdLejOUw3z6_VP.JsROyN
 tRDhRaXDLiGsIw2kHXHaKixIB4cwgWUKKIq2XCt9.JAjoC4VeD9ABod8CAx70ioBanaVQ1DP8Pox
 49g2t
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 May 2022 22:38:43 +0000
Received: by hermes--canary-production-gq1-647b99747d-7f5lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6da7e76a8e67d4358cf2797005743a74;
          Tue, 03 May 2022 22:38:42 +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 14.0 \(3654.120.0.1.13\))
Subject: aaarch64 main 9a3583bfbd17 debug build broken: "clri.lo: No such file
 or directory" so "make[4]: stopped in /usr/main-src/rescue/rescue"
Message-Id: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com>
Date: Tue, 3 May 2022 15:38:39 -0700
To: freebsd-current ,
 "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818.ref@yahoo.com>
X-Rspamd-Queue-Id: 4KtFHZ5hVSz3Lq7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="Irb/avR8";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.99)[-0.992];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3668
Lines: 99

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
branch: main
merge-base: 9a3583bfbd1740a158b3916432286190e0f2bf60
merge-base: CommitDate: 2022-05-03 19:12:42 +0000
9a3583bfbd17 (HEAD -> main, freebsd/main, freebsd/HEAD) OpenSSL: Merge =
OpenSSL 1.1.1o
n255160 (--first-parent --count for merge-base)

got:

--- all_subdir_rescue ---
Building =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue/clri.lo
. . .
--- all_subdir_rescue ---
--- clri.lo ---
clri.lo: No such file or directory
. . .
--- all_subdir_rescue ---
*** [clri.lo] Error code 1

make[5]: stopped in =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue
.ERROR_TARGET=3D'clri.lo'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64=
.aarch64/rescue/rescue/clri.lo.meta'
.MAKE.LEVEL=3D'5'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose curdirOk=3Dyes'
. . .
--- all_subdir_rescue ---
_ERROR_CMD=3D'cc -mcpu=3Dcortex-a72 -target aarch64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64=
/tmp =
-B/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/usr/b=
in -O2 -pipe -fno-common    -std=3Dgnu99 -Wno-format-zero-length =
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type =
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter =
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition =
-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety =
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable =
-Wno-error=3Dunused-but-set-variable  -Qunused-arguments     -static   =
-nostdlib -r -o clri.lo clri_stub.o =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue//usr/main-src/sbin/clri/clri.o; crunchide -k _crunched_clri_stub =
clri.lo;'
=
.CURDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
rescue/rescue'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
rescue/rescue'
.TARGETS=3D'exe'
=
DESTDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
tmp'
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220418'
=
PATH=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp=
/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/us=
r/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/=
usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp=
/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aa=
rch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/=
arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-=
src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP=3D'/usr/main-src'
OBJTOP=3D'/usr/main-src'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA72-dbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null rescue.mk'
.PATH=3D'. =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue'
1 error



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue May  3 22:44:55 2022
X-Original-To: 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 5F3151AB1F24
	for ; Tue,  3 May 2022 22:45:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4KtFQr1w8Cz3NnH
	for ; Tue,  3 May 2022 22:45:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617900; bh=p5/STqFZCgEXmDppyTj7ZB2+IKgSzjyq4vK0JIVmMzw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=fePBV1sUBW1shwwTQHL9e4Rg61qbFXd252HURoq2XXz+qhhAtHQd7xsfKWaU363LDTVpAf9Lxh4H4bSenD0ajDwnFni7+2artY1twW6MCyMZSIGCUsDALW2OcG4dA2FlBoNXmGCDbJiy0iXV7nuF+jFEaLlzyUJVosxoO+I4EnBHjpb42LtHRbCZxyI7xGfrzXIot19enyF28SM20d76ZLC/tQpsCO0maeaUegaOYqW9kiOD4tE/gV0clOUahkVjAqNGKzMoYcPRLxSA8piT5dYZKO6+ut4C1QCTzqeac/G7aCkOhQAO8aRuQu4kWKcHeIX0EO3qf1HdELDiQLfRFg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617900; bh=T6EhH18PIJNStkKJjFczcgg7WiAg4OTCguIche/gx6J=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=PzpAnYtDgL77FHLDY3ALP3XdJvzI2LJjIS5g5T5TCsklOgj+fj9cVqBMMIZhuUY+Iqsxzr+FzoCtr0ZQKf1IWrhCLIuzmfGNkBHBBGtL5TBCq54Fp0Vdh4x5HfCFNZ7qYnFhmQ7BRQCtvV1KNGnZ4i42+buuQv8Swe+uhm57aGjgHolrJDvV2X5LLJ85EjdUO5L46OKOg4XI1Frzd1GIllP+rdkvU+YugBLaChk7dKMW+vVFAIqRgkMfj3RpQjm3+/9i8CUS3LFkOFR2gP5ysfZB4G/Kx+JRviuwRKkZkVlMmhEj5/XJCwZ8LqsGkOFzwEv+pvG6ugDAAbEP3wskfA==
X-YMail-OSG: DugEAMgVM1nbuqp93IpyQSisQgw.9zTt3XdiAX7Zf9pJ.U_Ssd62Oq93lSEFQsy
 lCer90v1Fg29jG_CgaKu4U3Rbs13VZcKOv3_lNo06dETW4u1KLx_ZzMwXF7xAGwkZX7Yk9cbovBR
 PwU369AicChwaROAgailrJWw1xRQRnL9Kg_7FwEbCp9JGrOpgL5bBLd5876oWtGVSEyqjKPcgRUw
 laeWr5Dlb_qaWcONSS_p9L4imQqvZ47EN14_eAY34eF8Vg6C2P4wcJ3WQvonR4tbcFg8lPHx_HIK
 UF3bFTZ18U_CDBWWxtZAtyNzDxvqoVhRpToGZx3vFTSS_8NZ3bJXGTMUZK5txt9e86es7Owwv5f9
 iiFUWTwLMZTcQ6j6PZeZ6_qPQlAMqC9ZeEvmQkmVq9hjCEkX1k8EjJtV1RJoz_DdWvZLdmQwIUuB
 0lj.bIyMK14pC4_J7F.ysPLlAjajHrx2Yh6LP4Q.gK8E0aRxrlk4_9mzIgjURSqam7t2N3m9lPHR
 s3omis8u1kYP_FdWz8YM1AOuvhdWWJOx0ZORRWt8e_It_AFegSq1K864M_Pd.7mo_7EeS3Tje5W_
 2JXUHt7kBFACROfxCktpxem6jrG89XYYNiIYZQ3bSweK8girWoHwAzUU4dugfi0vCpABljOYcetS
 v6tuFhXnJIu13kjaj0wuBLTGPAsEulvaHBvHOu1sytJhDqopekdOgByRmkIU1dFrmlrkzKrom_Gh
 sBR.YBkoI9jBd3aRSdggO8hun2Jd6z5acsSKCHfWk8oSLKkY4a5ukSi4sp5hqXMCGJd03nRNxByN
 Rj2jxGmTz_xAP7NFsSM7sz5p2OB0bAaJoNFCgZ_GTviH_khaJOoViRfYEZebU20wK2d.hfB0dYtK
 18SnOLMIvzhq4sTSVUgHPracs6wGCRwJ21DtnJGq3CWzXLTS7YleCxoZ43IiS85PtjBbQryQgDeq
 tAmEctkAlZRmpdiH2QFOQRSSukYVHQpHox6HAqW.Qr2BgfG788eby5O31ymLnS8EJ4KCvZ.lamVA
 BaMSTselvY59HQ.vcULq0zuwIpqHDKve19hgeuI.PhcUKBv_8wnNz3ddsIcA.rhoqckBk5lR5P91
 lF2xhKHnSjoOjrwzzSltIJtvoTO5LePlvmrUm621jvTlXAqoBHmdsT_1_WgpJMtxMxXoiZz3aK3R
 DA.SYZZiHUfYQnc4sr3_l8P8ociLTUNdaIBw5mEB3WhpgCwJsELCIcBaWyubG3DkScrBPMFbdBRO
 Rr4WnekRoycyZtx.hvajaEwZSmuM0ZOP7OSbw4iF_Z..RNcIzC4uLjdSm8LqsDVKZmoB6d7DC20f
 pIxAbpbwZhEFzsH8eyayusK.cP4dauSv_mKCjSKP_vN1.zvKaplzimOvuEX35TG.fmoIHBmiiUVC
 7sUB268TCI1PsRPRzDwKtPpjPFJdG6uFTV3c6nE4J7jFaxO8In60htRMqzMkafyA3J1r4dvZ7Kqw
 79pjOHYX7GXRHnOHDwvrGtTeHth10k8JeJDTZ7A7CGNQbkzeumDSi_U5BEhmnuQ_z5tTBzNzak7v
 8pwXTpjx4mf1JVKaOTk4ILJ28Qs0wrMXfQP9FWVGZ.n4pTCA_55N1UrzEwlfDq4L60IWiPvdWReH
 .K6gC8N3zgzNiRoAGQiq3VCcXQMqhegunn_PO7xytY4qnYp4PLM7ycPhVCihXXQCFLXeKhCc8lEj
 FlKXTdSkjb95dQdWOzmdmuN_jWaMrd7NEiadSyv1SmFlnc_CmnegQ9GleFQWM0exHL2jVZcZai2j
 sy8xLwewZ0rMPmlcE7FvBDmxq8lq5rCvVRs1oPPVZzT9h6asBbgntFhCZzAwPaPvBJ4trKeM4fRX
 SPgidJQGi3VkZEyL4XlvNUC35AnqRtFHTg6NhSO7bz8UdCwWK0pTpIw5DhYxRGvtO17GRIBzuUkr
 8pGmj5xUbz9ks6R7d_V1pDIbKIjcy5S3mSY1MJTCT58robd9MxnBJH6IntmOlcF.MR.tedy_ifZQ
 znM2ZvSP89.ouuv0dwK8fIUi5chLAzV4Mgy8kHCE.LqLnjY28FEpvYQpd6fyA3iZG2mxd7iMXgom
 9MBnYXonzGpo1w65qDy8NMB92n2c3sXDMd8ZnmwqCho2CZGXR7w5GmHrvDlL0uzYye4rRUnV5mwT
 XEqMSCcCiDmZqQZs.PvgCj948iPuwQb3a5lgCgAax2aJAPmQUMVnGtUClxClrY5vHDa4aJUOrJGB
 XoraDTikvje.mZDeyhyzAZm9LKBw1fHjx7rVKfIAIdOqfFEznGL114_ZY_fpArfS4etyTe3Ay.JW
 K5AWBUA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 May 2022 22:45:00 +0000
Received: by hermes--canary-production-gq1-647b99747d-xkjwp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cc0d3885b5e6e89156121fc595cfd2b3;
          Tue, 03 May 2022 22:44:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: aaarch64 main 9a3583bfbd17 debug build broken (race?): "clri.lo:
 No such file or directory" so "make[4]: stopped in
 /usr/main-src/rescue/rescue"
Date: Tue, 3 May 2022 15:44:55 -0700
References: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com>
To: freebsd-current ,
 "freebsd-arm@freebsd.org" 
In-Reply-To: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com>
Message-Id: <7363F687-5F17-4A6B-9436-B13C4545B527@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4KtFQr1w8Cz3NnH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fePBV1sU;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.17 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.69)[-0.691];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 NEURAL_HAM_LONG(-0.98)[-0.978];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 MLMMJ_DEST(0.00)[arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4122
Lines: 112

[Looks to be some form of build race.]

On 2022-May-3, at 15:38, Mark Millard  wrote:

> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
> branch: main
> merge-base: 9a3583bfbd1740a158b3916432286190e0f2bf60
> merge-base: CommitDate: 2022-05-03 19:12:42 +0000
> 9a3583bfbd17 (HEAD -> main, freebsd/main, freebsd/HEAD) OpenSSL: Merge =
OpenSSL 1.1.1o
> n255160 (--first-parent --count for merge-base)
>=20
> got:
>=20
> --- all_subdir_rescue ---
> Building =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue/clri.lo
> . . .
> --- all_subdir_rescue ---
> --- clri.lo ---
> clri.lo: No such file or directory
> . . .
> --- all_subdir_rescue ---
> *** [clri.lo] Error code 1
>=20
> make[5]: stopped in =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue
> .ERROR_TARGET=3D'clri.lo'
> =
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64=
.aarch64/rescue/rescue/clri.lo.meta'
> .MAKE.LEVEL=3D'5'
> MAKEFILE=3D''
> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes=
 verbose curdirOk=3Dyes'
> . . .
> --- all_subdir_rescue ---
> _ERROR_CMD=3D'cc -mcpu=3Dcortex-a72 -target =
aarch64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64=
/tmp =
-B/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/usr/b=
in -O2 -pipe -fno-common    -std=3Dgnu99 -Wno-format-zero-length =
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter =
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type =
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter =
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition =
-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety =
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable =
-Wno-error=3Dunused-but-set-variable  -Qunused-arguments     -static   =
-nostdlib -r -o clri.lo clri_stub.o =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue//usr/main-src/sbin/clri/clri.o; crunchide -k _crunched_clri_stub =
clri.lo;'
> =
.CURDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
rescue/rescue'
> .MAKE=3D'make'
> =
.OBJDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
rescue/rescue'
> .TARGETS=3D'exe'
> =
DESTDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/=
tmp'
> LD_LIBRARY_PATH=3D''
> MACHINE=3D'arm64'
> MACHINE_ARCH=3D'aarch64'
> MAKEOBJDIRPREFIX=3D''
> MAKESYSPATH=3D'/usr/main-src/share/mk'
> MAKE_VERSION=3D'20220418'
> =
PATH=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp=
/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/us=
r/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/=
usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp=
/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aa=
rch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/=
arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-=
src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP=3D'/usr/main-src'
> OBJTOP=3D'/usr/main-src'
> .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA72-dbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null rescue.mk'
> .PATH=3D'. =
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc=
ue'
> 1 error

So I started another buildworld buildkernel , letting
it continue from where it had gotten to. That build
completed.

So: Possibly some form of build race where clri.lo just
was not ready yet when it complained but was in place
for the 2nd attempt.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed May  4 21:46:06 2022
X-Original-To: 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 08CE41AC96D0
	for ; Wed,  4 May 2022 21:46:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4Ktr4P5qKPz4Zbw
	for ; Wed,  4 May 2022 21:46:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651700772; bh=/j9ZWH5YsY1yoRR6raQXuyz/mId/Z+qN/83fHUC6qyc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hRyVbv87kz7HVbnaZSn5c7clwfVz1rT7/hoqzD8lBFvtpYZmIS0ceNKYhJ8eQJMsszsKcHm2MaaZy0NKpm+r7RZxbblaKHUmdAPaeBK0Y/4Yt5mYQcXiOq9b44aX6Lgd/SGJQavvatI2MakO6AETKe1hrfSqgPwRLOTY4kWIZ1/uBCBFx8QXM8XuV4hCnt6oCq9phlgtLWMH3jaxqiq9kdQ9My7IuxEPM34zQ6IHBBRwxsVqHe3MwG7YFGW6PVZwWUdOoU2gvwvFVfAyBMx1kkDSqWlktou8y6Yb05UmpA4D13X0sunGokMsEo+yND6LannzqCfOd4vke0JEY0yDPA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651700772; bh=x7RH4aaXUjQNZQqt6tdojO4dE6kuXppNRRa/Nb0g5J+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ELsIxsZs4JMDT4acljB4tF/hpOq/02Ez8iFZvs/EKxYopV2EcTLwufkCTjnPH37DHV7eKCEm9kFTeOM/CIvN4Xx5/6DAI+7YePBEsWdFj9zSmfkACwhgN7kYH2VFCanfJMNmDgRZjrFKBCPzdgZHNgUxNw3d8UkbSfKBCwHlODbZyZSosFWVHCxzdcR1L4C2OfowFk3wP6MfF+eNkkLrqO1UJK5DsZKyl3AlUNHziHOW+VDuiNhYVlcCTC/nt454+zVqQLvV5JbwS0FB4XQooE9iH62iDlnrj94bpz8WEEqOBmlGoLL9TyW+uc1pDyITOvfHEz7+6A8Vu8xiPQ/nVw==
X-YMail-OSG: gPYHMz4VM1nZZjekL17hEkvjEWIhuqSaUtlCd06HGICJM2ECai3pqUm2K2GZChi
 qAJr9BC2VlEE7Of9rg8ZorSq67fh1a3ugGsiNoc9e3nuiE9sPDWJPcPeZFxW29ss5rBwNejbGaIo
 _IakI0Eyae3tweql5l8F3N_sdtRzZrRpl9uqQMj3o.XBrQVFBkpN379KVX6SnSTj.ZhokvfvdO.k
 5ST_rr8mzjU0SPCzW9on3WIQFfKp6GhdY2EMbUPMUObc0YHeEDud8tKnYyFaZHmiNMxJC9z_RsfH
 9DKjRj0LVqqrgsafXQIo3hbbeU_pzLi42EGwVS8iL3SCverYHia2gCGXruYsK2ltPugXIC70hOP1
 U53PQlJMgzYkyq35ShAEBUT02XaOLUry280Rk.eZOuHdTBCd2UDMv1Q66cXJXyGSHLr.Wflyc2tN
 OcJa4zKG.rsKVlmz5VSGGOehQRA7JBH_DC8nid797fed.vMB4EriMynVbvgvNDehDy94QKZPIOz7
 dGaWFilSzB9o4_nzHDteZCioH5OGViUXmmD4jlblZyhOHuJEkAiEBe2KsiblxhbSzsPyRNJmTMkd
 W42gbPH1d_Eu.DzCW3Bxm1AaHTsgnMWcxxnNQwviOYD_aKHhO9PEYgbowPCtpGEnQq8kmW81RE_M
 NjikE1IgrNlFwd6splvyiAPu8Huz1o6J0YbydnlJrGAIRhZ4h3nn9ZGli52f0r.MeihQlPN0aCXi
 4L9x.gbLjN_TlizK50OgT5sThM1wMHS8reORaW3_Uui9oDVKZV5bsGVnjyghHmrp2B2ebFy346Xj
 N8tiAWG1fj.1tYJM8z8dDnzkZxXcWWWPbb5ANSohHi6dv987w1wB_QjCSehAP5jpYtKyJl0uky8O
 h0kUqxIErnoaCDGIG1LDZ6GoUv_0GhgWDEjqq0S9cxhq.TQML6FFtXPAJG3tB_6.HcftyUUfMsNs
 EPobDGnrcV9sMzUEBXByxWSorcStjT2E0zV4rJlC9DkqcheaNPiqSKWmbHalzOMQf2DGSb5fqMpl
 T_LbYpmsbM70ArW2IGIe1Xb96xwwIScVphS0mO.mOyu06KqY.x4SME0OxSaUuA.3XLJ3qpg.i8vR
 08SdUN5q4InLoiWTD.4tnZUSU_T8crRDLYoses7xauqaWaU.RurW6vjiy_GLHMUVoe_bYRBwMFXZ
 711.p8op5eDfeBrGPS4yzkKpYOqXbk6rCiIyR5xUH.ussSwNOaESMtw.MWvBlP1yHhyzJIDFcdUx
 UQzDvJE96kIFOlW9KV3e4gdmBv60TEJNlUpCSJ7IYxcuU6J9hm9_vb9HVC8FfiecSLD1g4V3uh.8
 9gKwQJljwTgvJXeicYddRiInyEBZhTbYee4Uq0Vb1uC.uK0F0ZBMWF4Lj1sh.NWxdIG6DHXnf8p4
 hxTWx1wBBaulbjFyKrXXlIyt4.IpaasPVyjs1OILPGk3t48m5UqxO17XPQRx7yW1jD8yXdupayVc
 BXTQVWgNpiWJxnayuxNIuDjaCX2l9ZLHf.kh0h0gUMMbFjmLa0nzsz_atmyCflEcexC.h9M02_M1
 bGDx7JvJaOCPNAsI.uFHiEyHgNJOpmdqNXGPA.uJijEVqi7ueor9Mmfy1WQE1fmdb5jVxaqm_zNm
 6w4HLv1o6boilxs3J6_HqNMCdhI8BsEsb0.DpX68nt.z9i5LOx.4ZVhQTfvTQyp76Axv0Lfgz59i
 CFechstgzQCqTrXURXaMPu3jVCsmolCdK8HR2DLscLvo.Fo7tq3OLUOjEWNoG1z3IOE_wmBZWBx7
 sBdA7j599nTRz8n2mP3IopTpEh1ls0XVm5F0YxqGjlrsjS1pFss1uO8IxmDAi6QdCVdcLQmObmj1
 du.qFwZ2uz.gYqivZH8lsOKKvoQ7kyTpxiUG3O1XWkDHw4N00TWOM2erviZDP0zZhUxeiff80WZX
 STcgwKYx30aON_TbOJpbBB34_nTJAjtksHiZVYT7w7kphdPSHHnGypKx6Cn3Jjurs_7MdgHIUGgo
 U30vHUTY6DgzTIwheuU00KIXHh58YkN65L2_OfANuE..7RPDD.Nz59JKV12ZmtrfeUX_lDAjIYMB
 19w9PeNGyV31j6C0ILKUzic5faJbfTQ3Px8xdTs67WJPv1rOGoHccc_3Gztv5QLDgJ0annMddefw
 eVDM2yTilzTX67b4CcB3LGXmuC6hWj0D_xPV.oBpIWrKWzFFPRQwvxcAZO.oEYS1J7xOgZlH4PDt
 Z5qqKWG6hiqeM18hQg2QkgRu_IKZH0kKsutFltHBsIDx7lr8o1dAGydAeYj3pEoyjfUPyzzeSQ.1
 JauhVFbZlEA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 4 May 2022 21:46:12 +0000
Received: by hermes--canary-production-ne1-75b69fcf97-qc4v9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d8d78c5a862cf208d9f736a98ab0ec7e;
          Wed, 04 May 2022 21:46:10 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: Thanks for the various recent port updates
Message-Id: <8117F5A7-849C-46C0-96CE-506DAE29081F@yahoo.com>
Date: Wed, 4 May 2022 14:46:06 -0700
To: Emmanuel Vadot ,
 "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <8117F5A7-849C-46C0-96CE-506DAE29081F.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Ktr4P5qKPz4Zbw
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hRyVbv87;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.67 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_MEDIUM(0.82)[0.820];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	 NEURAL_HAM_SHORT(-0.99)[-0.986];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 211
Lines: 8

Thanks for the recent port updates (gcc 11.3.0 use, u-boot*
updates to 2022.04, etc.). It has allowed me to get rid of
a bunch of experimental material in my environment.

===
Mark Millard
marklmi at yahoo.com


From nobody Fri May  6 14:03:41 2022
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 032B11AB15D5
	for ; Fri,  6 May 2022 14:03:55 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830])
	(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 4Kvsk20mZ2z3Dcc
	for ; Fri,  6 May 2022 14:03:54 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-qt1-x830.google.com with SMTP id t16so6016351qtr.9
        for ; Fri, 06 May 2022 07:03:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=p/J514D1rsLTocA+35T29+k1OBU2M8Dk21Smu2TCJ/g=;
        b=iSe1yRs4fRGlT2BVl8BsVsDHjfYWoF9ugqWiX+X0Tp8hoxaTn8+ZCnn7wESB7kgapT
         r/T/IQL1fMPIrIAxHbSn/wvlK5o6v++WEb+PNDn97+uG3JXGM4MQjnl50ZTEEB+P60Hb
         H4jPHd6kA5/LHGyD+pxxl3K1ZJhySKey0dZFQhoeuMi7N5gINRPDXWLQ11l/SzrdSGAK
         a1lmjo6DOZS0sAmnRXicznGque/k9DI2C7EZ4URs9HeWMSYz9qU5bGQalfkBaLfa2VVP
         GqIf/cysZUqQPoiGMkkO3hu1StB1bY9jukOpy4x+fu/c4TWFir/k4dh9nw8/ip6Kj10w
         DSAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=p/J514D1rsLTocA+35T29+k1OBU2M8Dk21Smu2TCJ/g=;
        b=TTQj+zPp2t19yGiG4ZWIgfhPTAw+JKq4Mty74LVxJzkIwqmwyp39f73m202855mcoe
         43Px7tMswEhqX165cuLFWJOeKiGH3o9vF+Sh/nVTbPGZZ66rLDbSMVTSLFHqdgMqB0qS
         UTN1225OAlTYPRbb1RDBV3dFIAI6d9rLy0sDgK3c4XgjUzo/Vg0QmQECpHaXnTysjR0F
         8+yTtDWnhDON//I59zfwYNkEMFyGTjHk3JcwPb8YvnXblL5edsQav291s9eyZ5YR2KqM
         FziLOG8kSmkBu5EK1OFXM/TCBFYoySBSWe5ikU61TEZGxGGoXMjj8Jvo/8p4If1aPKLp
         +dug==
X-Gm-Message-State: AOAM530mxEmXXLkrUs5/e23OKO0dKBO6WTUK8M+UjxRhDq7W322kp5jS
	cDsgUxv3ro5xKVSflR4grBf+ThoB3E6TiuZWiJHYk1OATj+LZw==
X-Google-Smtp-Source: ABdhPJxaMKvlHEyVHenMcm0POd8wuwNm+CUDFfNoeHVLhF0JfvPoeXZyU8G9jKKMdKhZJvO5s1dCgjnn1lUfVfFXb/4=
X-Received: by 2002:a05:622a:412:b0:2e1:de3b:d110 with SMTP id
 n18-20020a05622a041200b002e1de3bd110mr2917842qtx.420.1651845833370; Fri, 06
 May 2022 07:03:53 -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: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org> 
 <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Fri, 6 May 2022 22:03:41 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Over-current USB
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000001f309d05de585405"
X-Rspamd-Queue-Id: 4Kvsk20mZ2z3Dcc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=iSe1yRs4;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-3.02 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.02)[-0.023];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 26025
Lines: 488

--0000000000001f309d05de585405
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky 
> wrote:
>
>> On 4/11/22 15:59, Archimedes Gaviola wrote:
>> > Hi Hans,
>> >
>> > Noted on the self-powered hub, thanks for the suggestion, I will try.
>> >
>> > Just wanted to share the observation from the testing I've conducted
>> with
>> > my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is
>> > also experienced and it did, there was overcurrent and each ports' power
>> > shut-off during the situation but it was able to recover back. I
>> initiated
>> > the command 'usbconfig reset' and each port gloriously came back alive
>> one
>> > by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
>> > functional and operational states. My measuring device is showing the
>> same
>> > amount of current 460mA while the voltage stayed at 5.05 from a
>> baseline of
>> > 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,
>> voltage
>> > dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
>> > observed is when the voltage dropped below 5, the system will not give a
>> > chance to make the ports come back alive as a sort of protection
>> mechanism.
>> > Sharing to you the logs below (with hw.usb.uhub.debug=1).
>>
>> FreeBSD does not actively check and use "bMaxPower" .
>>
>
> Hi Hans,
>
> It's okay, just tried your recommendation on a self-powered USB hub, my
> Prolific device is now working. Thanks a lot!
>
> Archimedes
>

Hi Hans,

I got my Prolific PL2303 USB-serial device working in RPi 3B without the
self-powered USB hub. I've extended the code /usr/src/sys/dev/usb/usb_hub.c
in the uhub_explore() routine specific to handling overcurrent condition.
Below are the added lines of code.

freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig
/usr/src/sys/dev/usb/usb_hub.c
--- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 +0000
+++ /usr/src/sys/dev/usb/usb_hub.c      2022-05-03 07:29:45.159470000 +0000
@@ -1045,6 +1045,25 @@
                            udev, NULL, portno, UHF_C_PORT_OVER_CURRENT);
                        if (err != USB_ERR_NORMAL_COMPLETION)
                                retval = err;
+
+                       /* Turn on hub port power if current get
normalized. */
+                       DPRINTF("Turn on power on port %d.\n", portno);
+                       err = usbd_req_set_port_feature(
+                           udev, NULL, portno, UHF_PORT_POWER);
+                       if (err != USB_ERR_NORMAL_COMPLETION)
+                               retval = err;
+
+                       /* Re-validate if overcurrent still exists. */
+                       err = uhub_read_port_status(sc, portno);
+                       if (err != USB_ERR_NORMAL_COMPLETION)
+                               retval = err;
+                       if (sc->sc_st.port_change &
UPS_C_OVERCURRENT_INDICATOR) {
+                               DPRINTF("Overcurrent condition on port
%u.\n", portno);
+                               err = usbd_req_clear_port_feature(
+                                   udev, NULL, portno,
UHF_C_PORT_OVER_CURRENT);
+                               if (err != USB_ERR_NORMAL_COMPLETION)
+                                       retval = err;
+                       }
                }

The existing code will shut-off the USB hub port(s) right away after
encountering overcurrent and these code extensions will give chance to USB
devices by turning on the USB hub port power by calling
usbd_req_set_port_feature() with UHF_PORT_POWER argument. Turning on the
USB hub port power will verify if the current gets normalized when a USB
device is already plugged-in to a port because unlike the first time when
the USB device is inserted, there's a tendency of an abrupt current being
introduced to the system. So, when there's overcurrent situation and when
the USB device status is normal, the wPortChange value will just change
from 0x0008 (UPS_C_OVERCURRENT_INDICATOR) to 0x0001 (UPS_C_CONNECT_STATUS)
otherwise when the USB device status is not normal, it will be re-validated
for overcurrent situation thus calling again the
usbd_req_clear_port_feature() with UHF_C_PORT_OVER_CURRENT argument to sets
the ports power to shut-off.

So, based on the actual testing and logs when my Prolific PL2303 device
gets inserted to one of my RPi 3B USB port,

usb_needs_explore:
usb_bus_powerd: bus=0xffff000089394000
uhub_intr_callback:
uhub_explore: udev=0xffffa00001124000 addr=1
usb_needs_explore:
uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_explore: udev=0xffffa000012ed000 addr=2
uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION

uhub_read_port_status: port 2, wPortStatus=0x0000, wPortChange=0x0008,
err=USB_ERR_NORMAL_COMPLETION
uhub_explore: Overcurrent on port 2.
uhub_explore: Turn on power on port 2.

(Above 3 lines, an overcurrent is detected followed by turning on the power
on port 2 and the wPortChange=0x0008 is in UPS_C_OVERCURRENT_INDICATOR, an
overcurrent status.)

uhub_read_port_status: port 2, wPortStatus=0x0101, wPortChange=0x0001,
err=USB_ERR_NORMAL_COMPLETION

(After some time, port 2 is already having wPortChange=0x0001, it's now
getting UPS_C_CONNECT_STATUS which is in connected status. Due to this
status, the code exits and never executes the re-validation of overcurrent
code as it's no longer manifesting the overcurrent status.)

uhub_reattach_port: reattaching port 2
uhub_read_port_status: port 2, wPortStatus=0x0101, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_reattach_port: Port 2 is in Host Mode
uhub_intr_callback:
usb_needs_explore:
uhub_read_port_status: port 2, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_intr_callback:
usb_needs_explore:
usb_bus_port_set_device: bus 0xffff000089394000 devices[5] =
0xffffa00018900000

ugen1.5:  at usbus1
uplcom0 on uhub1
uplcom0:  on usbus1

(The above 3 lines give the info of my PL2303 Prolific ugen(4) and
uplcom(4) device drivers were loaded successfully. Below logs are for the
rest of my USB devices such as my keyboards and Epson printer.)

uhub_read_port_status: port 3, wPortStatus=0x0301, wPortChange=0x0001,
err=USB_ERR_NORMAL_COMPLETION
uhub_reattach_port: reattaching port 3
ugen1.6:  at usbus1 (disconnected)
ukbd0: at uhub1, port 3, addr 6 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
ukbd0: detached
uhid0: at uhub1, port 3, addr 6 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
uhid0: detached
usb_bus_port_set_device: bus 0xffff000089394000 devices[6] = 0
uhub_read_port_status: port 3, wPortStatus=0x0301, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_reattach_port: Port 3 is in Host Mode
uhub_intr_callback:
usb_needs_explore:
uhub_reset_tt_callback: TT buffer reset
uhub_reset_tt_callback: TT buffer reset
usb_needs_explore:
uhub_intr_callback:
usb_needs_explore:
uhub_read_port_status: port 3, wPortStatus=0x0303, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
usb_bus_port_set_device: bus 0xffff000089394000 devices[6] =
0xffffa000017ab000
ugen1.6:  at usbus1
ukbd0 on uhub1
ukbd0:  on usbus1
kbd1 at ukbd0
uhid0 on uhub1
uhid0:  on usbus1
uhub_read_port_status: port 4, wPortStatus=0x0101, wPortChange=0x0001,
err=USB_ERR_NORMAL_COMPLETION
uhub_reattach_port: reattaching port 4
ugen1.7:  at usbus1 (disconnected)
ukbd1: at uhub1, port 4, addr 7 (disconnected)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device not on hub
ukbd1: detached
usb_bus_port_set_device: bus 0xffff000089394000 devices[7] = 0
uhub_read_port_status: port 4, wPortStatus=0x0101, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_reattach_port: Port 4 is in Host Mode
uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
usb_bus_port_set_device: bus 0xffff000089394000 devices[7] =
0xffffa00018909000
ugen1.7:  at usbus1
ukbd1 on uhub1
ukbd1:  on usbus1
kbd2 at ukbd1
uhub_read_port_status: port 5, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
usb_bus_powerd: bus=0xffff000089394000
uhub_explore: udev=0xffffa00001124000 addr=1
uhub_reset_tt_callback: TT buffer reset
uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_reset_tt_callback: TT buffer reset
uhub_explore: udev=0xffffa000012ed000 addr=2
uhub_reset_tt_callback: TT buffer reset
uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 2, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 3, wPortStatus=0x0303, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 5, wPortStatus=0x0103, wPortChange=0x0000,
err=USB_ERR_NORMAL_COMPLETION

root@generic:~ # usbconfig
ugen1.1:  at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen1.2:  at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (2mA)
ugen1.3:  at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (2mA)
ugen1.4:  at usbus1, cfg=0 md=HOST spd=FULL (12Mbps)
pwr=ON (10mA)
ugen1.5:  at usbus1, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen1.6:  at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps)
pwr=ON (100mA)
ugen1.7:  at usbus1, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)

With these added extensions for some days now (14-CURRENT dated April 21,
2022), so far my RPi 3B is working normally, I haven't experienced any
system crash or freeze, keyboard, printer and PL2303 Prolific devices are
working well without any problems even the USB Ethernet (ue0) is working as
well. Plugging and unplugging this PL2303 Prolific device every now and
then from each port works as expected. Doing "usbconfig reset" works
normally as performed. Lastly, this also works with my RPi 4B.

Any comments or suggestions as I am not a seasoned kernel coder :-)

Thanks,
Archimedes

--0000000000001f309d05de585405
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Apr 12, 2022 at 5:16 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Mon, Apr 11, 20=
22 at 9:59 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 4/11/22 15:59, Archimedes Gaviola wrote=
:

> Hi Hans,

> 

> Noted on the self-powered hub, thanks for the suggestion, I will try.<=
br>
> 

> Just wanted to share the observation from the testing I've conduct=
ed with

> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent =
is

> also experienced and it did, there was overcurrent and each ports'=
 power

> shut-off during the situation but it was able to recover back. I initi=
ated

> the command 'usbconfig reset' and each port gloriously came ba=
ck alive one

> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into<=
br>
> functional and operational states. My measuring device is showing the =
same

> amount of current 460mA while the voltage stayed at 5.05 from a baseli=
ne of

> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike =
my RPi 3B, voltage

> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
> observed is when the voltage dropped below 5, the system will not give=
 a

> chance to make the ports come back alive as a sort of protection mecha=
nism.

> Sharing to you the logs below (with hw.usb.uhub.debug=3D1).



FreeBSD does not actively check and use "bMaxPower" .

Hi Hans,
It's okay, just tried your recommenda=
tion on a self-powered USB hub, my Prolific device is now working. Thanks a=
 lot!

=
Archimedes

Hi Hans,

I got my Prolific PL2303 USB-serial=20
device working in RPi 3B without the self-powered USB hub. I've extende=
d the code /usr/src/sys/dev/usb/usb_hub.c in the uhub_explore() routine spe=
cific to handling overcurrent condition. Below are the added lines of code.=


freebsd@generic:~ % diff -Nur /usr/src/sys/de=
v/usb/usb_hub.c.orig /usr/src/sys/dev/usb/usb_hub.c
--- /usr/src/=
sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 +0000
+++ /usr/=
src/sys/dev/usb/usb_hub.c =C2=A0 =C2=A0 =C2=A02022-05-03 07:29:45.159470000=
 +0000
@@ -1045,6 +1045,25 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 udev, NULL, por=
tno, UHF_C_PORT_OVER_CURRENT);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (err !=3D USB_ERR_NORMAL_COMP=
LETION)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retval =3D err;
+
+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 /* Turn on hub port power if current get normalized. */
+ =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DPRINTF(=
"Turn on power on port %d.\n", portno);
+ =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D usbd_req_s=
et_port_feature(
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 udev, NULL, portno, UHF_PORT_POWER);=

+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 if (err !=3D USB_ERR_NORMAL_COMPLETION)
+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 retval =3D err;
+
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Re-validate if overcurrent still =
exists. */
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 err =3D uhub_read_port_status(sc, portno);
+ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (e=
rr !=3D USB_ERR_NORMAL_COMPLETION)
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retva=
l =3D err;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (sc->sc_st.port_change & UPS_C_OVERCURRENT_INDI=
CATOR) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DPRINTF("Overcurrent con=
dition on port %u.\n", portno);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=
rr =3D usbd_req_clear_port_feature(
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 udev, NULL, portno, UHF_C_PORT_OVER_CURRENT);
+ =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 if (err !=3D USB_ERR_NORMAL_COMPLETION)
+ =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retval =3D err;
+ =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
The existing code will shut-off the USB hub port(s) right away =
after encountering overcurrent and these code extensions will give chance t=
o USB devices by turning on the USB hub port power by calling usbd_req_set_=
port_feature() with UHF_PORT_POWER argument. Turning on the USB hub port po=
wer will verify if the current gets normalized when a USB device is already=
 plugged-in to a port because unlike the first time when the USB device is =
inserted, there's a tendency of an abrupt current being introduced to t=
he system. So, when there's overcurrent situation and when the USB devi=
ce status is normal, the wPortChange value will just change from 0x0008 (UP=
S_C_OVERCURRENT_INDICATOR) to=20
0x0001 (UPS_C_CONNECT_STATUS) otherwise when the USB device status is not n=
ormal, it will be re-validated for overcurrent situation thus calling again=
 the=20
usbd_req_clear_port_feature() with=20
UHF_C_PORT_OVER_CURRENT argument to sets the ports power to shut-off.
=


So, based on the actual testing and logs when my Prolif=
ic PL2303

device gets inserted to one of my RPi 3B USB port,

usb_needs_explore:
usb_bus_powerd: bus=3D0xffff000089394000
uhub_int=
r_callback:
uhub_explore: udev=3D0xffffa00001124000 addr=3D1
usb_need=
s_explore:
uhub_read_port_status: port 1, wPortStatus=3D0x0503, wPortCha=
nge=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_explore: udev=3D0xfff=
fa000012ed000 addr=3D2
uhub_read_port_status: port 1, wPortStatus=3D0x05=
03, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION

uhub_read_port_status: port 2, wPortStatus=3D0x0000, wPortChange=3D=
0x0008, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_explo=
re: Overcurrent on port 2.
uhub_explore: Turn on power on port 2.
<=
div>
(Above 3 lines, an overcurrent is detected followed by t=
urning on the power on port 2 and the=20
wPortChange=3D0x0008 is in=20
UPS_C_OVERCURRENT_INDICATOR,

an overcurrent status.)

uhub_read_port_status:=
 port 2, wPortStatus=3D0x0101, wPortChange=3D0x0001, err=3DUSB_ERR_NORMAL_C=
OMPLETION

(After some time, port 2 is already havi=
ng
wPortChange=3D0x0001, it's now getting=20
UPS_C_CONNECT_STATUS

which is in connected status. Due to this status, the code exits and never =
executes the re-validation of overcurrent code as it's no longer manife=
sting the overcurrent status.) 

uhub_reattach_=
port: reattaching port 2
uhub_read_port_status: port 2, wPortStatus=3D0x=
0101, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_reattac=
h_port: Port 2 is in Host Mode
uhub_intr_callback:
usb_needs_explore:=

uhub_read_port_status: port 2, wPortStatus=3D0x0103, wPortChange=3D0x00=
00, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_intr_callback:
usb_needs_exp=
lore:
usb_bus_port_set_device: bus 0xffff000089394000 devices[5] =3D 0xf=
fffa00018900000

ugen1.5: <Prolific Technology I=
nc. USB-Serial Controller> at usbus1
uplcom0 on uhub1
uplcom0: <=
;Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 2.00/3.00, =
addr 5> on usbus1

(The above 3 lines give t=
he info of my PL2303 Prolific ugen(4) and uplcom(4) device drivers were loa=
ded successfully. Below logs are for the rest of my USB devices such as my =
keyboards and Epson printer.)

uhub_read_port_statu=
s: port 3, wPortStatus=3D0x0301, wPortChange=3D0x0001, err=3DUSB_ERR_NORMAL=
_COMPLETION
uhub_reattach_port: reattaching port 3
ugen1.6: <A4Tec=
h USB Keyboard> at usbus1 (disconnected)
ukbd0: at uhub1, port 3, add=
r 6 (disconnected)
uhub_child_location: device not on hub
uhub_child_=
pnpinfo: device not on hub
ukbd0: detached
uhid0: at uhub1, port 3, a=
ddr 6 (disconnected)
uhub_child_location: device not on hub
uhub_chil=
d_pnpinfo: device not on hub
uhid0: detached
usb_bus_port_set_device:=
 bus 0xffff000089394000 devices[6] =3D 0
uhub_read_port_status: port 3, =
wPortStatus=3D0x0301, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION=

uhub_reattach_port: Port 3 is in Host Mode
uhub_intr_callback:
us=
b_needs_explore:
uhub_reset_tt_callback: TT buffer reset
uhub_reset_t=
t_callback: TT buffer reset
usb_needs_explore:
uhub_intr_callback:usb_needs_explore:
uhub_read_port_status: port 3, wPortStatus=3D0x0303,=
 wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
usb_bus_port_set_=
device: bus 0xffff000089394000 devices[6] =3D 0xffffa000017ab000
ugen1.6=
: <A4Tech USB Keyboard> at usbus1
ukbd0 on uhub1
ukbd0: <A4T=
ech USB Keyboard, class 0/0, rev 2.00/1.05, addr 6> on usbus1
kbd1 at=
 ukbd0
uhid0 on uhub1
uhid0: <A4Tech USB Keyboard, class 0/0, rev =
2.00/1.05, addr 6> on usbus1
uhub_read_port_status: port 4, wPortStat=
us=3D0x0101, wPortChange=3D0x0001, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_=
reattach_port: reattaching port 4
ugen1.7: <USB Adapter USB Device>=
; at usbus1 (disconnected)
ukbd1: at uhub1, port 4, addr 7 (disconnected=
)
uhub_child_location: device not on hub
uhub_child_pnpinfo: device n=
ot on hub
ukbd1: detached
usb_bus_port_set_device: bus 0xffff00008939=
4000 devices[7] =3D 0
uhub_read_port_status: port 4, wPortStatus=3D0x010=
1, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_reattach_p=
ort: Port 4 is in Host Mode
uhub_read_port_status: port 4, wPortStatus=
=3D0x0103, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
usb_bus=
_port_set_device: bus 0xffff000089394000 devices[7] =3D 0xffffa00018909000<=
br>ugen1.7: <USB Adapter USB Device> at usbus1
ukbd1 on uhub1
u=
kbd1: <USB Adapter USB Device, class 0/0, rev 1.10/0.01, addr 7> on u=
sbus1
kbd2 at ukbd1
uhub_read_port_status: port 5, wPortStatus=3D0x01=
03, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
usb_bus_powerd=
: bus=3D0xffff000089394000
uhub_explore: udev=3D0xffffa00001124000 addr=
=3D1
uhub_reset_tt_callback: TT buffer reset
uhub_read_port_status: p=
ort 1, wPortStatus=3D0x0503, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COM=
PLETION
uhub_reset_tt_callback: TT buffer reset
uhub_explore: udev=3D=
0xffffa000012ed000 addr=3D2
uhub_reset_tt_callback: TT buffer reset
u=
hub_read_port_status: port 1, wPortStatus=3D0x0503, wPortChange=3D0x0000, e=
rr=3DUSB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 2, wPortStatu=
s=3D0x0103, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_r=
ead_port_status: port 3, wPortStatus=3D0x0303, wPortChange=3D0x0000, err=3D=
USB_ERR_NORMAL_COMPLETION
uhub_read_port_status: port 4, wPortStatus=3D0=
x0103, wPortChange=3D0x0000, err=3DUSB_ERR_NORMAL_COMPLETION
uhub_read_p=
ort_status: port 5, wPortStatus=3D0x0103, wPortChange=3D0x0000, err=3DUSB_E=
RR_NORMAL_COMPLETION

root@generic:~ # usbconfig
ugen1.1: <DWCOTG OTG Root HUB> at usbus1, cfg=3D0 md=3DHOST s=
pd=3DHIGH (480Mbps) pwr=3DSAVE (0mA)
ugen1.2: <vendor 0x0424 product =
0x9514> at usbus1, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DSAVE (2m=
A)
ugen1.3: <vendor 0x0424 product 0xec00> at usbus1, cfg=3D0 md=
=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (2mA)
ugen1.4: <EPSON EPSON UB-=
U03II> at usbus1, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (10mA)<=
br>ugen1.5: <Prolific Technology Inc. USB-Serial Controller> at usbus=
1, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)
ugen1.6: <A=
4Tech USB Keyboard> at usbus1, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps) pwr=
=3DON (100mA)
ugen1.7: <USB Adapter USB Device> at usbus1, cfg=3D0=
 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA)

With these added extensions for some days now (14-CURRENT dated April 21,=
 2022), so far my RPi 3B is working normally, I haven't experienced any=
 system crash or freeze, keyboard, printer and PL2303 Prolific devices are =
working well without any problems even the USB Ethernet (ue0) is working as=
 well. Plugging and unplugging this PL2303 Prolific device every now and th=
en from each port works as expected. Doing "usbconfig reset" work=
s normally as performed. Lastly, this also works with my RPi 4B.
=

Any comments or suggestions as I am not a seasoned kernel co=
der :-)

Thanks,
Archimede=
s


=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 




 


--0000000000001f309d05de585405--

From nobody Fri May  6 19:24:22 2022
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 EFC3C1AB6CEF
	for ; Fri,  6 May 2022 19:24:23 +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 4Kw0qp5XfSz3CqZ
	for ; Fri,  6 May 2022 19:24:22 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 57FEF21847
	for ; Fri,  6 May 2022 19:24:22 +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 246JOMio032767
	for ; Fri, 6 May 2022 19:24:22 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 246JOMBJ032766
	for freebsd-arm@FreeBSD.org; Fri, 6 May 2022 19:24:22 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 263825] Possibly an interesting bug in umtx code
Date: Fri, 06 May 2022 19:24:22 +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 Many People
X-Bugzilla-Who: dchagin@FreeBSD.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1651865063;
	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=TLCn7NNQOXO6JlIOrjj6K8Yqs1Q/ebEyyGZq3/S5U64=;
	b=NylML22sHNLxTw2J/NOYFJfeh3fnFXhiSx2jrbaxjOL0ZiIv1RDLq3VNhSGEsdC2XQy49Y
	eAGDOB4F/n828C+OHMs07Ztr9Kwrnw/UsBPe0XoT4qjtpFM4N+YsVFoKrvvN78mBmtQRuD
	h49NZiNqKNh4Pt8JkCfNFs6qBiJeOgz3lz41cUIojvlw/wEzYNOf73RDEQ9Gi+OSLlcCDq
	RZWMaQ4v42KUCBIG7BXWB7nx6omjD90eIpp+gT46CKID6YX8CzB4OQOIMQnNRcKc+H0GGV
	lOPdf3baiOkOzWjObv1y3bsCSp9vZZ4a88WBXzeqWwyA5P+aKflyhxMa0oMo7Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651865063; a=rsa-sha256; cv=none;
	b=QAe8X/J5DiE7hWJDhTeYAY30vDDgf4lO0TzWBmnLhb+copHxYHy9ekF6qxv9jCs+udTFQi
	afX5cCB2mGGfJEnCV+iQJjmOjAyl52cHLzdTvYkhZxtWI3D4SOlbyCuaEIXoQGGyLj1B+g
	zg5XPw4ZPIra439PoaGKChwxCPtmUrKUvsfnqvCKY/hz62XpqHsbPM3TitL1IJP1hA0qAz
	JdOd2Guo69Ryk1+d6OQinXc1Zqe7NeygWg8mGTw0dbwRmNRPy4VG9zhGQO4MIxO37s9PyO
	v8MinhXFTomqlf1A0hKV9MpUzyYYSKfQqcIdbPNIzJnIOJWC4lKczD7BWvZJMA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 927
Lines: 29

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263825

            Bug ID: 263825
           Summary: Possibly an interesting bug in umtx code
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: dchagin@FreeBSD.org

While testing arm64 Linuxulator's signal trampoline code I found glibc test
which fails on native FreeBSD arm64 (sporadically hangs), but pass on amd64.
Seems to me a some CAS problem.
Unfortunately,  I'm not familiar with arm architecture.

Test, adopted to the FreeBSD here:

https://people.freebsd.org/~dchagin/tst-cond25.c

Btw, I tested it under qemu on mac os m1, maybe problem is here?

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat May  7 09:20:37 2022
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 66B821AB91E0
	for ; Sat,  7 May 2022 09:20:43 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KwMNp3FTQz4fJD
	for ; Sat,  7 May 2022 09:20:42 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6E627260445;
	Sat,  7 May 2022 11:20:40 +0200 (CEST)
Message-ID: <8542947f-a62d-08c8-bb0e-ba3b6b973fec@selasky.org>
Date: Sat, 7 May 2022 11:20:37 +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:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: Raspberry Pi 3B Over-current USB
Content-Language: en-US
To: Archimedes Gaviola 
Cc: freebsd-arm@freebsd.org
References: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org>
 
 <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4KwMNp3FTQz4fJD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3726
Lines: 94

On 5/6/22 16:03, Archimedes Gaviola wrote:
> On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> 
>>
>>
>> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky 
>> wrote:
>>
>>> On 4/11/22 15:59, Archimedes Gaviola wrote:
>>>> Hi Hans,
>>>>
>>>> Noted on the self-powered hub, thanks for the suggestion, I will try.
>>>>
>>>> Just wanted to share the observation from the testing I've conducted
>>> with
>>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent is
>>>> also experienced and it did, there was overcurrent and each ports' power
>>>> shut-off during the situation but it was able to recover back. I
>>> initiated
>>>> the command 'usbconfig reset' and each port gloriously came back alive
>>> one
>>>> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
>>>> functional and operational states. My measuring device is showing the
>>> same
>>>> amount of current 460mA while the voltage stayed at 5.05 from a
>>> baseline of
>>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,
>>> voltage
>>>> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
>>>> observed is when the voltage dropped below 5, the system will not give a
>>>> chance to make the ports come back alive as a sort of protection
>>> mechanism.
>>>> Sharing to you the logs below (with hw.usb.uhub.debug=1).
>>>
>>> FreeBSD does not actively check and use "bMaxPower" .
>>>
>>
>> Hi Hans,
>>
>> It's okay, just tried your recommendation on a self-powered USB hub, my
>> Prolific device is now working. Thanks a lot!
>>
>> Archimedes
>>
> 
> Hi Hans,
> 
> I got my Prolific PL2303 USB-serial device working in RPi 3B without the
> self-powered USB hub. I've extended the code /usr/src/sys/dev/usb/usb_hub.c
> in the uhub_explore() routine specific to handling overcurrent condition.
> Below are the added lines of code.
> 
> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig
> /usr/src/sys/dev/usb/usb_hub.c
> --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 +0000
> +++ /usr/src/sys/dev/usb/usb_hub.c      2022-05-03 07:29:45.159470000 +0000
> @@ -1045,6 +1045,25 @@
>                              udev, NULL, portno, UHF_C_PORT_OVER_CURRENT);
>                          if (err != USB_ERR_NORMAL_COMPLETION)
>                                  retval = err;
> +
> +                       /* Turn on hub port power if current get
> normalized. */
> +                       DPRINTF("Turn on power on port %d.\n", portno);
> +                       err = usbd_req_set_port_feature(
> +                           udev, NULL, portno, UHF_PORT_POWER);
> +                       if (err != USB_ERR_NORMAL_COMPLETION)
> +                               retval = err;

You need a sleep here, to wait for power to come back on.

> +
> +                       /* Re-validate if overcurrent still exists. */
> +                       err = uhub_read_port_status(sc, portno);
> +                       if (err != USB_ERR_NORMAL_COMPLETION)
> +                               retval = err;
> +                       if (sc->sc_st.port_change &
> UPS_C_OVERCURRENT_INDICATOR) {
> +                               DPRINTF("Overcurrent condition on port
> %u.\n", portno);
> +                               err = usbd_req_clear_port_feature(
> +                                   udev, NULL, portno,
> UHF_C_PORT_OVER_CURRENT);
> +                               if (err != USB_ERR_NORMAL_COMPLETION)
> +                                       retval = err;
> +                       }
>                  }
> 

Can you upload the patch to https://reviews.freebsd.org and add 
"hselasky" as reviewer?

--HPS

From nobody Sat May  7 12:46:55 2022
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 3EDAE1AC893C
	for ; Sat,  7 May 2022 12:47:13 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29])
	(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 4KwRz42zQZz3JcN
	for ; Sat,  7 May 2022 12:47:12 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-qv1-xf29.google.com with SMTP id kj8so7261644qvb.6
        for ; Sat, 07 May 2022 05:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=A7NI/vQt1hm4Z+863iWkYOC3ixwdQVwIA1+zWSTWRbw=;
        b=eY6eHW69D2dhKn12mDK3GLn4PhnPVQghlT3IdtgfDpz/ALQdWTYUKIDSGPFhcZy+vB
         7T4mjxyxoL6ezwYC3YxVJ5OquhPkav+SwiaPf4JmNwiVVaOF22s7e1gZf3U8nmbgg9Ht
         vc47Vwnt+zhcDYTGaretFqHc0GBeyWcjv5NLYqen30qDuAXZHZctfvovbwr460Z6g3dq
         fAh8LqwzV+JUMCs1X8hRE8JLjG2ivLctMnAK/+6YOBtr/iXHE7wlRXLcbVgrTrYlPNJb
         4CEPUcTsZvwz/jOjM1ckY+2wGNjX66FNlaLz9lu5NzvIcUAwC2VBuVHA9QK/IEnAHf8s
         4QdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=A7NI/vQt1hm4Z+863iWkYOC3ixwdQVwIA1+zWSTWRbw=;
        b=69BdJtlx1Tv38JWfgJGtWZmpZB5U4ziWrMyuGFAP2EoqEQbY/+2RJyv9Rt1KsvLxOA
         pi0N+xp/ooSUNdTlqbeFyWiEVIXb0s3SgMillfLjMcIKUxul1GKWf7GgezTFEAPhGbP+
         G1rt0Bxjf+blaOP0Oi/yNahY60HjcTUS7XQbhQEG7WZobCFyP7tInMCfFppGJ4VLDUcK
         9thFTZmQ2yamrxCja/MTpWNNMJQY/8XsWVRnmjFrr7Dxz64IjaOR6do0ScfTe/MYvjSy
         A/LGbcxHc61QPZ0HkG5xSnLSEkVkfyRxkG9K0oNO3CdN5lXdWiwC681JSb1Pjx5nR4/G
         mwVg==
X-Gm-Message-State: AOAM532rQoYjJAm0wetSJ4hm8xpF1xY8KkIz+vZ3Em1FfZcY8enc+9dd
	PWt6McjwGa8vf+Rb8uJsliYuX6Nwc7Q/mZLr0BWiCVxL
X-Google-Smtp-Source: ABdhPJxu51oiAfd17Qp7V5qEUn/ezoEV4s1OMjVuNaA7sSLNXE+UxVB+27M8qXO5RNt+qF2pMo9ShKOG83wgFjhUfU0=
X-Received: by 2002:a05:6214:500f:b0:45a:acdd:7985 with SMTP id
 jo15-20020a056214500f00b0045aacdd7985mr6588737qvb.45.1651927625862; Sat, 07
 May 2022 05:47:05 -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: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org> 
 <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org> 
  <8542947f-a62d-08c8-bb0e-ba3b6b973fec@selasky.org>
In-Reply-To: <8542947f-a62d-08c8-bb0e-ba3b6b973fec@selasky.org>
From: Archimedes Gaviola 
Date: Sat, 7 May 2022 20:46:55 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Over-current USB
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000055928a05de6b5fae"
X-Rspamd-Queue-Id: 4KwRz42zQZz3JcN
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=eY6eHW69;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-2.04 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.96)[0.959];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11847
Lines: 270

--00000000000055928a05de6b5fae
Content-Type: text/plain; charset="UTF-8"

On Sat, May 7, 2022 at 5:20 PM Hans Petter Selasky  wrote:

> On 5/6/22 16:03, Archimedes Gaviola wrote:
> > On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <
> > archimedes.gaviola@gmail.com> wrote:
> >
> >>
> >>
> >> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky 
> >> wrote:
> >>
> >>> On 4/11/22 15:59, Archimedes Gaviola wrote:
> >>>> Hi Hans,
> >>>>
> >>>> Noted on the self-powered hub, thanks for the suggestion, I will try.
> >>>>
> >>>> Just wanted to share the observation from the testing I've conducted
> >>> with
> >>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if overcurrent
> is
> >>>> also experienced and it did, there was overcurrent and each ports'
> power
> >>>> shut-off during the situation but it was able to recover back. I
> >>> initiated
> >>>> the command 'usbconfig reset' and each port gloriously came back alive
> >>> one
> >>>> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
> >>>> functional and operational states. My measuring device is showing the
> >>> same
> >>>> amount of current 460mA while the voltage stayed at 5.05 from a
> >>> baseline of
> >>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,
> >>> voltage
> >>>> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
> >>>> observed is when the voltage dropped below 5, the system will not
> give a
> >>>> chance to make the ports come back alive as a sort of protection
> >>> mechanism.
> >>>> Sharing to you the logs below (with hw.usb.uhub.debug=1).
> >>>
> >>> FreeBSD does not actively check and use "bMaxPower" .
> >>>
> >>
> >> Hi Hans,
> >>
> >> It's okay, just tried your recommendation on a self-powered USB hub, my
> >> Prolific device is now working. Thanks a lot!
> >>
> >> Archimedes
> >>
> >
> > Hi Hans,
> >
> > I got my Prolific PL2303 USB-serial device working in RPi 3B without the
> > self-powered USB hub. I've extended the code
> /usr/src/sys/dev/usb/usb_hub.c
> > in the uhub_explore() routine specific to handling overcurrent condition.
> > Below are the added lines of code.
> >
> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig
> > /usr/src/sys/dev/usb/usb_hub.c
> > --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000
> +0000
> > +++ /usr/src/sys/dev/usb/usb_hub.c      2022-05-03 07:29:45.159470000
> +0000
> > @@ -1045,6 +1045,25 @@
> >                              udev, NULL, portno,
> UHF_C_PORT_OVER_CURRENT);
> >                          if (err != USB_ERR_NORMAL_COMPLETION)
> >                                  retval = err;
> > +
> > +                       /* Turn on hub port power if current get
> > normalized. */
> > +                       DPRINTF("Turn on power on port %d.\n", portno);
> > +                       err = usbd_req_set_port_feature(
> > +                           udev, NULL, portno, UHF_PORT_POWER);
> > +                       if (err != USB_ERR_NORMAL_COMPLETION)
> > +                               retval = err;
>
> You need a sleep here, to wait for power to come back on.
>
> > +
> > +                       /* Re-validate if overcurrent still exists. */
> > +                       err = uhub_read_port_status(sc, portno);
> > +                       if (err != USB_ERR_NORMAL_COMPLETION)
> > +                               retval = err;
> > +                       if (sc->sc_st.port_change &
> > UPS_C_OVERCURRENT_INDICATOR) {
> > +                               DPRINTF("Overcurrent condition on port
> > %u.\n", portno);
> > +                               err = usbd_req_clear_port_feature(
> > +                                   udev, NULL, portno,
> > UHF_C_PORT_OVER_CURRENT);
> > +                               if (err != USB_ERR_NORMAL_COMPLETION)
> > +                                       retval = err;
> > +                       }
> >                  }
> >
>
> Can you upload the patch to https://reviews.freebsd.org and add
> "hselasky" as reviewer?
>

Thank you Hans for the feedback! Just created an account and once approved
and activated then I'll upload it. Meanwhile, for the sleep you've
mentioned what particular function should be used? I tried these two,
sleep(3) and usleep(3) but seems to encounter errors during compilation.

--00000000000055928a05de6b5fae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, May 7, 2022 at 5:20 PM Hans P=
etter Selasky <hps@selasky.org>=
; wrote:
On 5/6/=
22 16:03, Archimedes Gaviola wrote:

> On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <

> arch=
imedes.gaviola@gmail.com> wrote:

> 

>>

>>

>> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky <hps@selasky.org>

>> wrote:

>>

>>> On 4/11/22 15:59, Archimedes Gaviola wrote:

>>>> Hi Hans,

>>>>

>>>> Noted on the self-powered hub, thanks for the suggestion, =
I will try.

>>>>

>>>> Just wanted to share the observation from the testing I=
9;ve conducted

>>> with

>>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if =
overcurrent is

>>>> also experienced and it did, there was overcurrent and eac=
h ports' power

>>>> shut-off during the situation but it was able to recover b=
ack. I

>>> initiated

>>>> the command 'usbconfig reset' and each port glorio=
usly came back alive

>>> one

>>>> by one and loaded my USB keyboard and Prolific uplcom(4) d=
rivers into

>>>> functional and operational states. My measuring device is =
showing the

>>> same

>>>> amount of current 460mA while the voltage stayed at 5.05 f=
rom a

>>> baseline of

>>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,

>>> voltage

>>>> dropped to 4.93 from a baseline of 5.19 volts. So, the dif=
ference I

>>>> observed is when the voltage dropped below 5, the system w=
ill not give a

>>>> chance to make the ports come back alive as a sort of prot=
ection

>>> mechanism.

>>>> Sharing to you the logs below (with hw.usb.uhub.debug=3D1)=
.

>>>

>>> FreeBSD does not actively check and use "bMaxPower" =
.

>>>

>>

>> Hi Hans,

>>

>> It's okay, just tried your recommendation on a self-powered US=
B hub, my

>> Prolific device is now working. Thanks a lot!

>>

>> Archimedes

>>

> 

> Hi Hans,

> 

> I got my Prolific PL2303 USB-serial device working in RPi 3B without t=
he

> self-powered USB hub. I've extended the code /usr/src/sys/dev/usb/=
usb_hub.c

> in the uhub_explore() routine specific to handling overcurrent conditi=
on.

> Below are the added lines of code.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig

> /usr/src/sys/dev/usb/usb_hub.c

> --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 =
+0000

> +++ /usr/src/sys/dev/usb/usb_hub.c=C2=A0 =C2=A0 =C2=A0 2022-05-03 07:2=
9:45.159470000 +0000

> @@ -1045,6 +1045,25 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 udev, NULL, portno, UHF_C_PORT_OVER_CURR=
ENT);

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if (err !=3D USB_ERR_NORMAL_COMPLETION)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retval =3D err;

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0/* Turn on hub port power if current get

> normalized. */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0DPRINTF("Turn on power on port %d.\n", portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0err =3D usbd_req_set_port_feature(

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0udev, NULL, portno, UHF_PORT_POWER);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPLETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retval =3D err;



You need a sleep here, to wait for power to come back on.



> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0/* Re-validate if overcurrent still exists. */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0err =3D uhub_read_port_status(sc, portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPLETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retval =3D err;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (sc->sc_st.port_change &

> UPS_C_OVERCURRENT_INDICATOR) {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DPRINTF("Overcurrent conditi=
on on port

> %u.\n", portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D usbd_req_clear_port_featu=
re(

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0udev, NULL, portno,=


> UHF_C_PORT_OVER_CURRENT);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPL=
ETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retva=
l =3D err;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> 



Can you upload the patch to https://reviews.freebsd.org and add 

"hselasky" as reviewer?

Thank you Hans for the feedback! Just created an acc=
ount and once approved and activated then I'll upload it. Meanwhile, fo=
r the sleep you've mentioned what particular function should be used? I=
 tried these two, sleep(3) and usleep(3) but seems to encounter errors duri=
ng compilation.


--00000000000055928a05de6b5fae--

From nobody Sat May  7 14:35:57 2022
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 6C2A61ADACC1
	for ; Sat,  7 May 2022 14:36:15 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f])
	(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 4KwVNt2sxmz3jnl
	for ; Sat,  7 May 2022 14:36:14 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-qt1-x82f.google.com with SMTP id fu47so8024171qtb.5
        for ; Sat, 07 May 2022 07:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=AUGbbFgRSqiEnY4jHKGFgPL4ic9OFFtlusyPyS3sJ/0=;
        b=qe0XRRNDOIZukMSZOQeg3FzMap1m5lfF2UrDspoSNrTnlrq4h2D5qoIJOqa4uNQIbV
         oMcp2tCYlBLb0v0RhIVxeUPMFsU0ADRHXB61uO16S96xzQQCQKenhTjxGNHUzcMHUBl9
         i7sVALSPNVa3W8zhgvR1vIya7G4d+tOCgviGt2lu3L6ILpE8OHptElyvZHobwT4Ef7OJ
         /ajvfTfAP+72CNjlGw6DVjvWbwuSpdXym+waZD4IqqLBH1kH1/lUp4A/go/8ZHWp4dCk
         KFenFaw0MoS91HIaJBA/2YkH2Vhq++vXmgiRszZaDXAouyK4dDQLVXBkbTMlEDapgma9
         W4kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=AUGbbFgRSqiEnY4jHKGFgPL4ic9OFFtlusyPyS3sJ/0=;
        b=TZ9XJ8sLJxuy4y44F5zdVYFW+RkQm1sJAqo8dPdsEnvEAgp/1jsT45ct34We+yd4jO
         DDxlRgEs4K/9WxPbE4oX/17OkyLJriWdIEHWe/wgbB7Piz9qI/Q5jbg6rxd8jBDnc9ro
         lrGO6b11b7qaz1HDAMrPxli0HSyKgkIOUy/Z52nSeZ3bsDAUij/W9pzItyYHswyFT24M
         quMF3PInC0XcLfpL/Q31bq6ar4kz6t7kIE3tqY7aWx1EtpFBEW7A81haJozSH1R2JFGa
         JROy4yxJ12maU72aKhicDowRYL5SL+sdNgtne22aso5Yjzl8fJSed4T48uumYPuHywcc
         mxUA==
X-Gm-Message-State: AOAM533rgS66QURpxWrH7MTBNsHbJj+h5i9cgj7eJD8dz5gO/2X39Guq
	rM6iNEG/GmRi6MltDo4rv24Z20TJXWtfjwaYi1UITEFf+vI=
X-Google-Smtp-Source: ABdhPJy0w1ysq5sShCHKceqaU/a8HnihS1MSJBsp3eHDY9nWLpRR5hmNoVpc0oV4+b6SYttA2Y/TuJ3YgUDmgxKDxoI=
X-Received: by 2002:ac8:7d8e:0:b0:2f1:e909:7a1 with SMTP id
 c14-20020ac87d8e000000b002f1e90907a1mr7719558qtd.385.1651934168336; Sat, 07
 May 2022 07:36:08 -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: 
 <5deaf68b-267c-56dd-603d-8ec0d82ceae2@selasky.org> 
 <8dc68431-ad3d-84db-45b4-cd661d4a15df@selasky.org> 
 
 <8542947f-a62d-08c8-bb0e-ba3b6b973fec@selasky.org> 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sat, 7 May 2022 22:35:57 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B Over-current USB
To: Hans Petter Selasky 
Cc: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000004bcccc05de6ce597"
X-Rspamd-Queue-Id: 4KwVNt2sxmz3jnl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qe0XRRND;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2607:f8b0:4864:20::82f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 12831
Lines: 295

--0000000000004bcccc05de6ce597
Content-Type: text/plain; charset="UTF-8"

On Sat, May 7, 2022 at 8:46 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sat, May 7, 2022 at 5:20 PM Hans Petter Selasky 
> wrote:
>
>> On 5/6/22 16:03, Archimedes Gaviola wrote:
>> > On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <
>> > archimedes.gaviola@gmail.com> wrote:
>> >
>> >>
>> >>
>> >> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky 
>> >> wrote:
>> >>
>> >>> On 4/11/22 15:59, Archimedes Gaviola wrote:
>> >>>> Hi Hans,
>> >>>>
>> >>>> Noted on the self-powered hub, thanks for the suggestion, I will try.
>> >>>>
>> >>>> Just wanted to share the observation from the testing I've conducted
>> >>> with
>> >>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if
>> overcurrent is
>> >>>> also experienced and it did, there was overcurrent and each ports'
>> power
>> >>>> shut-off during the situation but it was able to recover back. I
>> >>> initiated
>> >>>> the command 'usbconfig reset' and each port gloriously came back
>> alive
>> >>> one
>> >>>> by one and loaded my USB keyboard and Prolific uplcom(4) drivers into
>> >>>> functional and operational states. My measuring device is showing the
>> >>> same
>> >>>> amount of current 460mA while the voltage stayed at 5.05 from a
>> >>> baseline of
>> >>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,
>> >>> voltage
>> >>>> dropped to 4.93 from a baseline of 5.19 volts. So, the difference I
>> >>>> observed is when the voltage dropped below 5, the system will not
>> give a
>> >>>> chance to make the ports come back alive as a sort of protection
>> >>> mechanism.
>> >>>> Sharing to you the logs below (with hw.usb.uhub.debug=1).
>> >>>
>> >>> FreeBSD does not actively check and use "bMaxPower" .
>> >>>
>> >>
>> >> Hi Hans,
>> >>
>> >> It's okay, just tried your recommendation on a self-powered USB hub, my
>> >> Prolific device is now working. Thanks a lot!
>> >>
>> >> Archimedes
>> >>
>> >
>> > Hi Hans,
>> >
>> > I got my Prolific PL2303 USB-serial device working in RPi 3B without the
>> > self-powered USB hub. I've extended the code
>> /usr/src/sys/dev/usb/usb_hub.c
>> > in the uhub_explore() routine specific to handling overcurrent
>> condition.
>> > Below are the added lines of code.
>> >
>> > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig
>> > /usr/src/sys/dev/usb/usb_hub.c
>> > --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000
>> +0000
>> > +++ /usr/src/sys/dev/usb/usb_hub.c      2022-05-03 07:29:45.159470000
>> +0000
>> > @@ -1045,6 +1045,25 @@
>> >                              udev, NULL, portno,
>> UHF_C_PORT_OVER_CURRENT);
>> >                          if (err != USB_ERR_NORMAL_COMPLETION)
>> >                                  retval = err;
>> > +
>> > +                       /* Turn on hub port power if current get
>> > normalized. */
>> > +                       DPRINTF("Turn on power on port %d.\n", portno);
>> > +                       err = usbd_req_set_port_feature(
>> > +                           udev, NULL, portno, UHF_PORT_POWER);
>> > +                       if (err != USB_ERR_NORMAL_COMPLETION)
>> > +                               retval = err;
>>
>> You need a sleep here, to wait for power to come back on.
>>
>> > +
>> > +                       /* Re-validate if overcurrent still exists. */
>> > +                       err = uhub_read_port_status(sc, portno);
>> > +                       if (err != USB_ERR_NORMAL_COMPLETION)
>> > +                               retval = err;
>> > +                       if (sc->sc_st.port_change &
>> > UPS_C_OVERCURRENT_INDICATOR) {
>> > +                               DPRINTF("Overcurrent condition on port
>> > %u.\n", portno);
>> > +                               err = usbd_req_clear_port_feature(
>> > +                                   udev, NULL, portno,
>> > UHF_C_PORT_OVER_CURRENT);
>> > +                               if (err != USB_ERR_NORMAL_COMPLETION)
>> > +                                       retval = err;
>> > +                       }
>> >                  }
>> >
>>
>> Can you upload the patch to https://reviews.freebsd.org and add
>> "hselasky" as reviewer?
>>
>
> Thank you Hans for the feedback! Just created an account and once approved
> and activated then I'll upload it. Meanwhile, for the sleep you've
> mentioned what particular function should be used? I tried these two,
> sleep(3) and usleep(3) but seems to encounter errors during compilation.
>

Hi Hans,

Submitted, please see https://reviews.freebsd.org/D35146.

Thanks,
Archimedes

--0000000000004bcccc05de6ce597
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, May 7, 2022 at 8:46 PM Archim=
edes Gaviola <archimedes=
.gaviola@gmail.com> wrote:


On Sat, May 7, 2022=
 at 5:20 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 5/6/22 16:03, Archimedes Gaviola wrote:

> On Tue, Apr 12, 2022 at 5:16 PM Archimedes Gaviola <

> arch=
imedes.gaviola@gmail.com> wrote:

> 

>>

>>

>> On Mon, Apr 11, 2022 at 9:59 PM Hans Petter Selasky <hps@selasky.org>

>> wrote:

>>

>>> On 4/11/22 15:59, Archimedes Gaviola wrote:

>>>> Hi Hans,

>>>>

>>>> Noted on the self-powered hub, thanks for the suggestion, =
I will try.

>>>>

>>>> Just wanted to share the observation from the testing I=
9;ve conducted

>>> with

>>>> my Raspberry Pi 4B with the same 14.0-CURRENT to check if =
overcurrent is

>>>> also experienced and it did, there was overcurrent and eac=
h ports' power

>>>> shut-off during the situation but it was able to recover b=
ack. I

>>> initiated

>>>> the command 'usbconfig reset' and each port glorio=
usly came back alive

>>> one

>>>> by one and loaded my USB keyboard and Prolific uplcom(4) d=
rivers into

>>>> functional and operational states. My measuring device is =
showing the

>>> same

>>>> amount of current 460mA while the voltage stayed at 5.05 f=
rom a

>>> baseline of

>>>> 5.15 voltshttps://filebin.net/10vy575q6h2yl8og. Unlike my RPi 3B,

>>> voltage

>>>> dropped to 4.93 from a baseline of 5.19 volts. So, the dif=
ference I

>>>> observed is when the voltage dropped below 5, the system w=
ill not give a

>>>> chance to make the ports come back alive as a sort of prot=
ection

>>> mechanism.

>>>> Sharing to you the logs below (with hw.usb.uhub.debug=3D1)=
.

>>>

>>> FreeBSD does not actively check and use "bMaxPower" =
.

>>>

>>

>> Hi Hans,

>>

>> It's okay, just tried your recommendation on a self-powered US=
B hub, my

>> Prolific device is now working. Thanks a lot!

>>

>> Archimedes

>>

> 

> Hi Hans,

> 

> I got my Prolific PL2303 USB-serial device working in RPi 3B without t=
he

> self-powered USB hub. I've extended the code /usr/src/sys/dev/usb/=
usb_hub.c

> in the uhub_explore() routine specific to handling overcurrent conditi=
on.

> Below are the added lines of code.

> 

> freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb_hub.c.orig

> /usr/src/sys/dev/usb/usb_hub.c

> --- /usr/src/sys/dev/usb/usb_hub.c.orig 2022-04-29 10:52:44.787344000 =
+0000

> +++ /usr/src/sys/dev/usb/usb_hub.c=C2=A0 =C2=A0 =C2=A0 2022-05-03 07:2=
9:45.159470000 +0000

> @@ -1045,6 +1045,25 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 udev, NULL, portno, UHF_C_PORT_OVER_CURR=
ENT);

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if (err !=3D USB_ERR_NORMAL_COMPLETION)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retval =3D err;

> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0/* Turn on hub port power if current get

> normalized. */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0DPRINTF("Turn on power on port %d.\n", portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0err =3D usbd_req_set_port_feature(

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0udev, NULL, portno, UHF_PORT_POWER);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPLETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retval =3D err;



You need a sleep here, to wait for power to come back on.



> +

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0/* Re-validate if overcurrent still exists. */

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0err =3D uhub_read_port_status(sc, portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPLETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retval =3D err;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0if (sc->sc_st.port_change &

> UPS_C_OVERCURRENT_INDICATOR) {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DPRINTF("Overcurrent conditi=
on on port

> %u.\n", portno);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D usbd_req_clear_port_featu=
re(

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0udev, NULL, portno,=


> UHF_C_PORT_OVER_CURRENT);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (err !=3D USB_ERR_NORMAL_COMPL=
ETION)

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0retva=
l =3D err;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> 



Can you upload the patch to https://reviews.freebsd.org and add 

"hselasky" as reviewer?

Thank you Hans for the feedback! Just created an acc=
ount and once approved and activated then I'll upload it. Meanwhile, fo=
r the sleep you've mentioned what particular function should be used? I=
 tried these two, sleep(3) and usleep(3) but seems to encounter errors duri=
ng compilation.

Hi Hans,


Submitted, please see https:=
//reviews.freebsd.org/D35146.

Thanks,
Archimedes


--0000000000004bcccc05de6ce597--

From nobody Sun May  8 21:01:00 2022
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 933AE1ABC376
	for ; Sun,  8 May 2022 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 4KxGtP0qZTz4fcM
	for ; Sun,  8 May 2022 21:01:00 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 2F61E2BEA0
	for ; Sun,  8 May 2022 21:01:00 +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 248L10WF052649
	for ; Sun, 8 May 2022 21:01:00 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 248L10HE052648
	for freebsd-arm@FreeBSD.org; Sun, 8 May 2022 21:01:00 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202205082101.248L10HE052648@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, 8 May 2022 21:01:00 +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="16520436601.BD84e.50514"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1652043661;
	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=2jlgyhYe+0tshxQPhmJODYYzfu6TcgSV7+Obd0TaIu8=;
	b=wedOIAfxRciKf2aTcoOyrhOPVcQSYBUw3VUUPcQH/NhCGixoV+ufG2G/2F/WhX+Xr9s1z6
	Y/a40APxMqZrIHplCSa3dut1v86gD0Yq73qwPGE//hcbD6duAio+q137uHePBL2NQza/rv
	rc6WxsYGnbBjO5KTpLtzJSz+MAVaj66AJHQVpeoVyeouFdYwo7F1ySmRaBAAWhNjHB9Cwm
	IUX7Hz4FEEiTYkpxBtXP8PXoSs3dQFvhgVqq7QQ/kqPYXT/bD8SML409/mh/Vf0hLg9/3e
	PUjZuDwmIbTuXOW/uIb68leFDQPAA2XY1jB3frMbyGxDFDPpsyjn7COV12Q2+Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652043661; a=rsa-sha256; cv=none;
	b=RgzovewjsQeRi/l+3CP3ixQBBwMLdeY4OzAH6MCfdvLHc++zITA5M/mkq/wk9wiBpOJtxP
	CiXY3POsWY0TbZsImGGyJq6BmIIvcJ5CZPrNxDzxVrkZ8C1EA0BdQYfm0z945W5JpV3QIN
	gVqxNjMTqisMHOalp5RXxHNwhALXs2+Mrr7hw2rLzt0OSbPEaqXjtw3+kl4xxcXj+BycSU
	fsOxuG0qKR1mttwp+RxnpifUlTzMYP3BkwNP7TSQPD+vTeFdrHfLM8rCDxxnnurVLzWDoy
	TnLHpxBfprC/ZY2UKlsnh86ssdZrpoz9svxdtpSp592XjhKPRcFXYYVcxbEufA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1796
Lines: 38


--16520436601.BD84e.50514
Date: Sun, 8 May 2022 21:01:00 +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.

--16520436601.BD84e.50514
Date: Sun, 8 May 2022 21:01:00 +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.


--16520436601.BD84e.50514--

From nobody Mon May  9 08:09:42 2022
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 C22A21ACDF40;
	Mon,  9 May 2022 08:09:45 +0000 (UTC)
	(envelope-from mikael@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4KxYk152Vvz4d50;
	Mon,  9 May 2022 08:09:45 +0000 (UTC)
	(envelope-from mikael@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1652083785;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=Ht6cSObgigx8ds+CmajbhTTGt/J6o1lfQMIH3z2NuDE=;
	b=JB+evPKfgMm9cR6DvzIrYdSxzFCc9q/FVF0Hjp7FUKZmO8TTz6XDluXMwe59Shojz4mG0V
	DKyq5RFGNZJamPF1fj+GYVFjkMp4VUrcOP6VWvNfRvIXFvU3nW2NgWp/0ai1nNU7atZmA2
	2c/RNmTnypk4F+Cw89/N/RDp2rZQgjtr7DEf7rEfITard/1DKSapvs1dLgqc+NXEhBVTCw
	6slKbBb5IuEjph+0tHNNfMbGWnI2pqwWtPcLiXTPNT0p8btZ301d1sh5je+SmtSqFVQdOG
	omRXHR+5E92wD6rgWp+gQpaU+NifFd32+V1c8pV1pwq6bdxF4yxQrr3XcXiTXg==
Received: from [147.171.68.35] (desktop-016.gipsa-lab.grenoble-inp.fr [147.171.68.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: mikael)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 17D2C10C4;
	Mon,  9 May 2022 08:09:44 +0000 (UTC)
	(envelope-from mikael@FreeBSD.org)
Content-Type: multipart/alternative;
 boundary="------------aOac6q26CVux0z3IE9LfPVAi"
Message-ID: <9c1e1a94-b566-a4c3-3c35-751d75845d4b@FreeBSD.org>
Date: Mon, 9 May 2022 10:09:42 +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:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
Content-Language: en-US
To: Greg Lewis , Ronald Klop 
Cc: freebsd-java@freebsd.org, freebsd-arm@freebsd.org
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
 
 <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org>
 <1486531687.70.1651475552058@localhost>
 <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
From: =?UTF-8?Q?Mika=c3=abl_Urankar?= 
In-Reply-To: <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1652083785;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=Ht6cSObgigx8ds+CmajbhTTGt/J6o1lfQMIH3z2NuDE=;
	b=TW04AoadTAz7BpRQy1HrUaUgHnyABgmSeKMHOWRkTprgBQP4D44tKtI4QqYEhL7GeV4zeT
	VUu5wSsAKXnYs5L+GG48F1PRvKQq9rbqZN9mWsCqf0xaf8710ZVUE989Qi1xXO/MkaTxz9
	TpB4b6up/qOWGC3aa5Mge3bBj5mAtDaCCFPDEcvMLwzIzItEyWfK7Tx5bbjgncGrTiTZ56
	NtTPTyyi72DWMKMjFYnlPeD/RVwpnf4CWepHSjjtosSPwReXzSrwdoNG88ngq4OIUJRvVa
	Y7htj0v+TeE0u8MKay22Bi5f5VB0mJtgj8eQ2BCJST9ofK81bYxx9lgO1kXCuQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652083785; a=rsa-sha256; cv=none;
	b=FMbE3mqhP0cQ/EO3N/GLpvIkopKVV+ahZbNic61AnFJjSuZaWBo8h7eXDQ806XnX/w4p6A
	zRgp6D3f9pW9/QsPtNaTmXG54IQMwJlRuKqwlPvBthT/2P+lQJoyNcSjPc6CgetWQDixjY
	9rO7KAeQACEGFNOYShU02cGd+YeR7sXuQjnGzXHWfZt/CHThOWrl89eL+V8VxLWX4EkpYE
	mg93Q/BLCaKXFqkdjTyFgPoHMkl1c2H9tIrBsH0apKlPlA6/VAr0zdGNSTE9F2zzX72JtQ
	5B1JwrTRrBXvcPdaVRSXIMvy1Z+c8Io254o2ujSs25aW9qYY7sqxXZcG37wHeA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6432
Lines: 171

This is a multi-part message in MIME format.
--------------aOac6q26CVux0z3IE9LfPVAi
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

ASLR was turned on by default on -CURRENT. All the java ports are 
affected if they are built with a -CURRENT system.

On 08/05/2022 06:14, Greg Lewis wrote:
>
> Is the suggestion to put that into the openjdk17 port Makefile?  I'll 
> look for some documentation on this.
>
> FWIW, the bootstrap just works on the AWS hardware I stand up for 
> aarch64.  Although that is also where I built the bootstrap images.  
> If someone has some different hardware that would be preferable?
>
> -- Greg
>
> On 5/2/22 12:12 AM, Ronald Klop wrote:
>>
>> *Van:* "Mikaël Urankar" 
>> *Datum:* zondag, 1 mei 2022 17:56
>> *Aan:* Ronald Klop 
>> *Onderwerp:* Re: [package - 130arm64-default][java/openjdk17] Failed 
>> for openjdk17-17.0.2+8.1 in configure
>>
>>     On 30/04/2022 15:49, Ronald Klop wrote:
>>     > Hi,
>>     >
>>     > Openjdk17 and openjdk13 are failing on 130arm64.
>>     >
>>     > This started in March, I don't see a bug report in Bugzilla
>>     about it.
>>     > Openjdk17 is a LTS version so it would be nice to have that one
>>     fixed. > Openjdk13 is deprecated so don't bother about that one
>>     but mentioning > is because it might be related.
>>     >
>>     > Below the openjdk17 log.
>>     >
>>     > The build for main-arm64 had the same error: (IPv6:) >
>>     http://ampere2.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log
>>     >
>>     > Regards,
>>     > Ronald.
>>
>>     Hi,
>>
>>     It's similar to
>>     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260187
>>     ------------------------------------------------------------------------
>>
>>
>>
>> Hi,
>>
>> Thanks for sharing your memory of closed issues!
>>
>> Would the port need something like this?
>>
>> ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java
>>
>> Maybe with a conditional on aarch64.
>>
>> Regards,
>> Ronald.


--------------aOac6q26CVux0z3IE9LfPVAi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
ASLR was turned on by default on
      -CURRENT. All the java ports are affected if they are built with a
      -CURRENT system.

    

    


    

    
On 08/05/2022 06:14, Greg Lewis wrote:

    

    

      
      
Is the suggestion to put that into the openjdk17 port
        Makefile?  I'll look for some documentation on this.

      
FWIW, the bootstrap just works on the AWS hardware I stand up
        for aarch64.  Although that is also where I built the bootstrap
        images.  If someone has some different hardware that would be
        preferable?

      
-- Greg

      

      
On 5/2/22 12:12 AM, Ronald Klop
        wrote:

      

      

        
         
        
Van: "Mikaël Urankar" <mikael@FreeBSD.org>

          Datum: zondag, 1 mei 2022 17:56

          Aan: Ronald Klop <ronald-lists@klop.ws>

          Onderwerp: Re: [package -
          130arm64-default][java/openjdk17] Failed for
          openjdk17-17.0.2+8.1 in configure

        

          

            
On 30/04/2022 15:49,
              Ronald Klop wrote:

              > Hi,

              >

              > Openjdk17 and openjdk13 are failing on 130arm64.

              >

              > This started in March, I don't see a bug report in
              Bugzilla about it.

              > Openjdk17 is a LTS version so it would be nice to
              have that one fixed. > Openjdk13 is deprecated so don't
              bother about that one but mentioning > is because it
              might be related.

              >

              > Below the openjdk17 log.

              >

              > The build for main-arm64 had the same error: (IPv6:)
              > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log

              >

              > Regards,

              > Ronald.

              

              Hi,

              

              It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260187

               

            

        

        

        

        Hi,

        

        Thanks for sharing your memory of closed issues!

        

        Would the port need something like this?

        

        ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java

        

        Maybe with a conditional on aarch64.

        

        Regards,

        Ronald.

          

    

    


    

  


--------------aOac6q26CVux0z3IE9LfPVAi--

From nobody Mon May  9 09:00:18 2022
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 42DB61AD8BE0;
	Mon,  9 May 2022 09:00:26 +0000 (UTC)
	(envelope-from SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KxZrT1msgz4lmm;
	Mon,  9 May 2022 09:00:25 +0000 (UTC)
	(envelope-from SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 9 May 2022 11:00:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1652086818;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=iRyKSafg7mb6wIXyk/o+tEglgwuCRxuW0F/UkhpAZKY=;
	b=O7llOQ8FAVp8YYs8zr61W/OfZxmAwlb/NI8HP6K4K3sA5bOeOxnjsnRvJWFIciFyywkDpS
	DTzJhxg1Qg4X4ga7g2pBewQrG0kHA4p+FO1iv/3JJPOLF1gu83Ou7L979pqU5K2kYv5mp/
	mczX0on1i2SRJy+FoPkvCowM42Di+crlJd7poFJGmTc2sfXXgq8Md7n/ryLA+r8z5FPazE
	ghhaieESYYzV7oJ+ShFQ9Ks0yz6X/UBIv+v0PxrNlIdxLNYGm2Rvz8VHpOZ3ErfNQeFuVC
	39lvtkzhPmq9jsIZXQ0hhEsdLFnO2N4/3IQR/rvPLRv0tWlc/zOh7pU5et8ixA==
From: Ronald Klop 
To: Greg Lewis 
Cc: =?UTF-8?Q?Mika=C3=ABl_Urankar?= ,
	freebsd-arm@freebsd.org, freebsd-java@freebsd.org
Message-ID: <1942762675.4.1652086818035@mailrelay>
In-Reply-To: <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
 
 <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org>
 <1486531687.70.1651475552058@localhost>
 <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
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="----=_Part_3_1938508586.1652086818021"
X-Mailer: Realworks (607.113.437a2a1)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KxZrT1msgz4lmm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=O7llOQ8F;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-1.19 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.988];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_SPAM_SHORT(0.99)[0.994];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6540
Lines: 169

------=_Part_3_1938508586.1652086818021
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Greg,

I can reproduce the issue using poudriere on my rpi4.
Will try to test the "ELF_FEATURES=3D       noaslr:bootstrap-openjdk17/bin/=
java" setting. But it takes a while on this hardware.

NB: The error in the build is that the bootstrap-openjdk17 java command doe=
s not run. So my first test would be to disable ASLR for that port.

Regards,
Ronald.

=20
Van: Greg Lewis 
Datum: zondag, 8 mei 2022 06:14
Aan: Ronald Klop , "Mika=C3=ABl Urankar" 
CC: freebsd-java@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for open=
jdk17-17.0.2+8.1 in configure
>=20
> Is the suggestion to put that into the openjdk17 port Makefile?  I'll loo=
k for some documentation on this.
>=20
> FWIW, the bootstrap just works on the AWS hardware I stand up for aarch64=
.  Although that is also where I built the bootstrap images.  If someone ha=
s some different hardware that would be preferable?
>=20
> -- Greg
>=20
> On 5/2/22 12:12 AM, Ronald Klop wrote:
>> =20
>> Van: "Mika=C3=ABl Urankar" 
>> Datum: zondag, 1 mei 2022 17:56
>> Aan: Ronald Klop 
>> Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for o=
penjdk17-17.0.2+8.1 in configure
>>>=20
>>> On 30/04/2022 15:49, Ronald Klop wrote:
>>> > Hi,
>>> >
>>> > Openjdk17 and openjdk13 are failing on 130arm64.
>>> >
>>> > This started in March, I don't see a bug report in Bugzilla about it.
>>> > Openjdk17 is a LTS version so it would be nice to have that one fixed=
. > Openjdk13 is deprecated so don't bother about that one but mentioning >=
 is because it might be related.
>>> >
>>> > Below the openjdk17 log.
>>> >
>>> > The build for main-arm64 had the same error: (IPv6:) > http://ampere2=
.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/err=
ors/openjdk17-17.0.2+8.1.log
>>> >
>>> > Regards,
>>> > Ronald.
>>>=20
>>> Hi,
>>>=20
>>> It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260=
187
>>> =20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> Hi,
>>=20
>> Thanks for sharing your memory of closed issues!
>>=20
>> Would the port need something like this?
>>=20
>> ELF_FEATURES=3D       noaslr:bootstrap-openjdk17/bin/java
>>=20
>> Maybe with a conditional on aarch64.
>>=20
>> Regards,
>> Ronald.
>>  >=20
------=_Part_3_1938508586.1652086818021
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Greg,



I can reproduce the issue using poudriere on my rpi4.

Will try to test the "ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java" setting. But it takes a while on this hardware.



NB: The error in the build is that the bootstrap-openjdk17 java command does not run. So my first test would be to disable ASLR for that port.



Regards,

Ronald.



 

Van: Greg Lewis <glewis@eyesbeyond.com>

Datum: zondag, 8 mei 2022 06:14

Aan: Ronald Klop <ronald-lists@klop.ws>, "Mikaël Urankar" <mikael@FreeBSD.org>

CC: freebsd-java@freebsd.org, freebsd-arm@freebsd.org

Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for openjdk17-17.0.2+8.1 in configure











Is the suggestion to put that into the openjdk17 port Makefile?  I'll look for some documentation on this.



FWIW, the bootstrap just works on the AWS hardware I stand up for aarch64.  Although that is also where I built the bootstrap images.  If someone has some different hardware that would be preferable?



-- Greg



On 5/2/22 12:12 AM, Ronald Klop wrote:



 

Van: "Mikaël Urankar" <mikael@FreeBSD.org>

Datum: zondag, 1 mei 2022 17:56

Aan: Ronald Klop <ronald-lists@klop.ws>

Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for openjdk17-17.0.2+8.1 in configure







On 30/04/2022 15:49, Ronald Klop wrote:

> Hi,

>

> Openjdk17 and openjdk13 are failing on 130arm64.

>

> This started in March, I don't see a bug report in Bugzilla about it.

> Openjdk17 is a LTS version so it would be nice to have that one fixed. > Openjdk13 is deprecated so don't bother about that one but mentioning > is because it might be related.

>

> Below the openjdk17 log.

>

> The build for main-arm64 had the same error: (IPv6:) > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log

>

> Regards,

> Ronald.



Hi,



It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260187

 










Hi,



Thanks for sharing your memory of closed issues!



Would the port need something like this?



ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java



Maybe with a conditional on aarch64.



Regards,

Ronald.

 









------=_Part_3_1938508586.1652086818021--

From nobody Mon May  9 09:15:54 2022
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 0F9661ADB953
	for ; Mon,  9 May 2022 09:15:55 +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 4KxbBL54kbz4nVY
	for ; Mon,  9 May 2022 09:15:54 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 8AD5A6622
	for ; Mon,  9 May 2022 09:15:54 +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 2499Fs0k052452
	for ; Mon, 9 May 2022 09:15:54 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2499FsfA052451
	for freebsd-arm@FreeBSD.org; Mon, 9 May 2022 09:15:54 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 263873] FreeBSD-13.0-RELEASE boot failure on Raspberry Pi 2B
 Rev 1.1
Date: Mon, 09 May 2022 09:15:54 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: gwq_uk@yahoo.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1652087754;
	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=pE30NchR9Ke/YoZWGT+OKwz0N3CbPx6ZPjEzYVxppHU=;
	b=xN25+ivPAj6YjUXbOjETTog66a6zoTGAivf0bjBJTFOaQnuv4LshEG/lMLe0x0wNHimloU
	5bjUlF70zDIgAfGWOH4LqhZNc5b8ndxLhJ6STvODi6shfmd7LMctBhwjmVtzsg/kJIWhBi
	vdCiNKibcS/NBbY2sqdI0/isuiQ53S7pZ/dEekBO1Z6auJQV2pElNmNfsU1pFX26JJnv1F
	I4putqSdes1QCpwfQhgYMqQvai3+pvyKFtJeYZgCHal1VLiKr9HRAY+Iidgrl/GP0qs6jj
	ixefqGcEvFXm84ywTtoHUfPLgIUla1ItdAhPIJDwpwMhQ0KQeuGIHmcRhnWokg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652087754; a=rsa-sha256; cv=none;
	b=kVNWyF3Q/L5Z7yTjW8JeZ+yTzb/4Zackmr9bHJgW2KhwxGfzWirQbiMBOCcXcM/YxBLFZr
	v2cyaTfOdHFn8+Q87PJs5yiMTN/mLY97wpdUo/ec2HhJdDvTX0zxOGitaA98XjnSXu9oVW
	/o1CWPIdUNlZV7EayafGNAPLdye/etBCi6341Jw+TO/uqKR+k+/LEEEbPhVXbDIVnz3zxC
	xU5kC1MUTHDhA8CLby2Tibzc91E7stfRm2Kwf6I6BHfjqEf6WYR1R7rOp0SJXjA3BayeqD
	Aqj6IIYoBsFNwOMtO47VF3/V/6W1yN5L5PJeloqXIP9bFgFCbnqxGa5L37Emsg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1343
Lines: 50

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263873

            Bug ID: 263873
           Summary: FreeBSD-13.0-RELEASE boot failure on Raspberry Pi 2B
                    Rev 1.1
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: gwq_uk@yahoo.com

Hi,

I have tried to use a FreeBSD-13.0-RELEASE memory card image on my RPI2B bu=
t I
get the dreaded rainbow screen. (Also tried 13.1-RC6 same result)

I have use the following command to create the memory card;

 dd if=3DFreeBSD-13.0-arm-armv6-RPI-B.img of=3D/dev/da0 bs=3D1m conv=3Dsync

The image writes without issue but when placed in the RPI2B it will not boo=
t.

The two file systems are moutable using a memory card reader and plugging t=
hat
into another FreeBSD machine;

 mkdir /msdos
 mount -t msdosfs /dev/da0s1 /msdos
 mount /dev/da0s2a /mnt

I have also tried FreeBSD-12.3-RELEASE image using the same dd command and =
the
RPI2B boots just fine. i.e. works as intended.

The power supply is a good quality one with an output of 3.1 amps.

Thanks

Greg

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Mon May  9 09:20:05 2022
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 0BFC91ADC1AF
	for ; Mon,  9 May 2022 09:20:06 +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 4KxbH95QlZz4nrx
	for ; Mon,  9 May 2022 09:20:05 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 9BE1962C6
	for ; Mon,  9 May 2022 09:20:05 +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 2499K5ln053170
	for ; Mon, 9 May 2022 09:20:05 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2499K5xg053169
	for freebsd-arm@FreeBSD.org; Mon, 9 May 2022 09:20:05 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 263873] FreeBSD-13.0-RELEASE boot failure on Raspberry Pi 2B
 Rev 1.1
Date: Mon, 09 May 2022 09:20:05 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: manu@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not A Bug
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status cc resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1652088005;
	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=8Z6lHLYdMtJL2kkd8tBmnLFOr/EoOB9HjylxSZ4Dk74=;
	b=A4A6H9M3a11DtvQx/X5bwP7fXF5ZrC9Xtm0pnTodUfP8sIp8KSRp6q7GccsYDg8Ylsi1Qw
	AIlo2VMhVlmfLSb5QsTRfCK7WX4krJBz3cCHJBXQ2XUNp6vrXTYLH3vT8LEvWjE0rdnxTo
	YGcEL03Zf8P9Dg1X6/1ZIOscJXCd5ZdPegu9FHCDXogoNmwU9C1T8kONFPD9E3yB8qOl6y
	NJM1vlXNUXwy345zLrQt1qDAJnBsuDnDbyfClHi13vHQmJJURVkM2TQsLRKC7PrxYZ+oYb
	pH6mMfQZMmia1tUy/vxfM6INn8KKqObt+j/Nu6dCuVETVJE96mxz26tBxOezOw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652088005; a=rsa-sha256; cv=none;
	b=qvMPCo94yxdcv5yKr1tdUmAXJwrqEZhjFhl+Eek41GONAb/KX9n3FK/Kd9LwV4lZIgPsV6
	Rg4MqAwBCf/xb0VokDDaVU9gOfirm87WS8ynJtT9gLK+HrlXP8tN5qkcCOsruZ9CpxKHoa
	RPCO9nFcuv5twkJ/OzONizhBup08xGK5Rwg/Auw+sUQ48gSUs287g4H2bxXJVLsMV7xrrC
	HHYRHlQfVqc/ZIFDdyBj+rEcWl2H+6IVPiL4lbVjkTNShShac9Ppmf9NX/B9sZ5oAZ5L/H
	NcwYWGF834vE+Vno3asYlyUo7RmDWZHg8y0H/dtIUZJqZzE9aubj3sq+zYclDw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 683
Lines: 19

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263873

Emmanuel Vadot  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
                 CC|                            |manu@freebsd.org
         Resolution|---                         |Not A Bug

--- Comment #1 from Emmanuel Vadot  ---
RPI-B is only for the first revision of the Pi and the Pi0.
For RPI2 use FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img.

Cheers,

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Mon May  9 14:48:05 2022
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 2051F1ACCC18;
	Mon,  9 May 2022 14:48:08 +0000 (UTC)
	(envelope-from SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4KxkYg0B6rz4V3p;
	Mon,  9 May 2022 14:48:06 +0000 (UTC)
	(envelope-from SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 9 May 2022 16:48:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1652107685;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=hHw+rPtEcF1Wy4gF9HzK96TYVorUedU1C0YpTXdx7gk=;
	b=CJhspVZtALWaGd/XLP7zzM2BGuVvTM+q8BYh3u9Rx8fqqKnthZ9ZnPKZep7WvqzTCOe5gD
	Sz/m+b20P75U0MvsbqNQCO5vtq0swBmhloF1oe/fjVZNrdEdSPlOtg9a6XzzquPxViYIqo
	VPpXKgfC2reqzFqKet73/zkjGvfXASTCUOkFnmG+iJn3z2eC9JMKu2ko94qwxcMZcqYLiP
	rPrT7Jpeq4CP6tQFQAKmi7zGLMHe4hmpK8qdLchEHKlbbE+rJioepwB3PGLxLwUc8A9ZgX
	kx8XWPnn5AIkTRnxYC/CMmLzDBIFl135+1cvEJ3WQDNcTBpA24+QCAPBeyu0Ww==
From: Ronald Klop 
To: Greg Lewis 
Cc: =?UTF-8?Q?Mika=C3=ABl_Urankar?= ,
	freebsd-arm@freebsd.org, freebsd-java@freebsd.org
Message-ID: <1525249842.4.1652107685143@mailrelay>
In-Reply-To: <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>
 
 <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org>
 <1486531687.70.1651475552058@localhost>
 <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com>
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
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="----=_Part_3_102238385.1652107685130"
X-Mailer: Realworks (607.118.ff703a3)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4KxkYg0B6rz4V3p
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=CJhspVZt;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.12 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.92)[-0.924];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=9B21=VR=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 8171
Lines: 219

------=_Part_3_102238385.1652107685130
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

This patch works for me. I didn't test the builded openjdk17 yet. I guess t=
hat needs the same construction but we will see after building is finished.

Regards,
Ronald.


diff --git a/java/bootstrap-openjdk17/Makefile b/java/bootstrap-openjdk17/M=
akefile
index 9cb49ca170af..693da01a2395 100644
--- a/java/bootstrap-openjdk17/Makefile
+++ b/java/bootstrap-openjdk17/Makefile
@@ -1,5 +1,6 @@
 PORTNAME=3D      openjdk17
 PORTVERSION=3D   17.0.1.12.1
+PORTREVISION=3D  1
 CATEGORIES=3D    java devel
 MASTER_SITES=3D  LOCAL/glewis/bootstrap-openjdk17 \
                LOCAL/pkubaj/bootstrap-openjdk17
@@ -40,6 +41,13 @@ PLIST_SUB+=3D  NOT_I386=3D"@comment "
 PLIST_SUB+=3D    NOT_I386=3D""
 .endif
=20
+.if ${ARCH:Maarch64*}
+USES+=3D elfctl
+ELF_FEATURES=3D  +noaslr:bin/*
+
+pre-install: elfctl-post-build # Workaround NO_BUILD
+.endif
+
 do-install:
        @cd ${WRKSRC} && ${COPYTREE_SHARE} . ${INSTALLDIR}
        @cd ${WRKSRC} && ${COPYTREE_BIN} bin ${INSTALLDIR}


=20
Van: Greg Lewis 
Datum: zondag, 8 mei 2022 06:14
Aan: Ronald Klop , "Mika=C3=ABl Urankar" 
CC: freebsd-java@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for open=
jdk17-17.0.2+8.1 in configure
>=20
> Is the suggestion to put that into the openjdk17 port Makefile?  I'll loo=
k for some documentation on this.
>=20
> FWIW, the bootstrap just works on the AWS hardware I stand up for aarch64=
.  Although that is also where I built the bootstrap images.  If someone ha=
s some different hardware that would be preferable?
>=20
> -- Greg
>=20
> On 5/2/22 12:12 AM, Ronald Klop wrote:
>> =20
>> Van: "Mika=C3=ABl Urankar" 
>> Datum: zondag, 1 mei 2022 17:56
>> Aan: Ronald Klop 
>> Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for o=
penjdk17-17.0.2+8.1 in configure
>>>=20
>>> On 30/04/2022 15:49, Ronald Klop wrote:
>>> > Hi,
>>> >
>>> > Openjdk17 and openjdk13 are failing on 130arm64.
>>> >
>>> > This started in March, I don't see a bug report in Bugzilla about it.
>>> > Openjdk17 is a LTS version so it would be nice to have that one fixed=
. > Openjdk13 is deprecated so don't bother about that one but mentioning >=
 is because it might be related.
>>> >
>>> > Below the openjdk17 log.
>>> >
>>> > The build for main-arm64 had the same error: (IPv6:) > http://ampere2=
.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/err=
ors/openjdk17-17.0.2+8.1.log
>>> >
>>> > Regards,
>>> > Ronald.
>>>=20
>>> Hi,
>>>=20
>>> It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260=
187
>>> =20
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>> Hi,
>>=20
>> Thanks for sharing your memory of closed issues!
>>=20
>> Would the port need something like this?
>>=20
>> ELF_FEATURES=3D       noaslr:bootstrap-openjdk17/bin/java
>>=20
>> Maybe with a conditional on aarch64.
>>=20
>> Regards,
>> Ronald.
>>  >=20
------=_Part_3_102238385.1652107685130
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,



This patch works for me. I didn't test the builded openjdk17 yet. I guess that needs the same construction but we will see after building is finished.



Regards,

Ronald.





diff --git a/java/bootstrap-openjdk17/Makefile b/java/bootstrap-openjdk17/Makefile

index 9cb49ca170af..693da01a2395 100644

--- a/java/bootstrap-openjdk17/Makefile

+++ b/java/bootstrap-openjdk17/Makefile

@@ -1,5 +1,6 @@

 PORTNAME=      openjdk17

 PORTVERSION=   17.0.1.12.1

+PORTREVISION=  1

 CATEGORIES=    java devel

 MASTER_SITES=  LOCAL/glewis/bootstrap-openjdk17 \

                LOCAL/pkubaj/bootstrap-openjdk17

@@ -40,6 +41,13 @@ PLIST_SUB+=  NOT_I386="@comment "

 PLIST_SUB+=    NOT_I386=""

 .endif

 

+.if ${ARCH:Maarch64*}

+USES+= elfctl

+ELF_FEATURES=  +noaslr:bin/*

+

+pre-install: elfctl-post-build # Workaround NO_BUILD

+.endif

+

 do-install:

        @cd ${WRKSRC} && ${COPYTREE_SHARE} . ${INSTALLDIR}

        @cd ${WRKSRC} && ${COPYTREE_BIN} bin ${INSTALLDIR}





 

Van: Greg Lewis <glewis@eyesbeyond.com>

Datum: zondag, 8 mei 2022 06:14

Aan: Ronald Klop <ronald-lists@klop.ws>, "Mikaël Urankar" <mikael@FreeBSD.org>

CC: freebsd-java@freebsd.org, freebsd-arm@freebsd.org

Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for openjdk17-17.0.2+8.1 in configure











Is the suggestion to put that into the openjdk17 port Makefile?  I'll look for some documentation on this.



FWIW, the bootstrap just works on the AWS hardware I stand up for aarch64.  Although that is also where I built the bootstrap images.  If someone has some different hardware that would be preferable?



-- Greg



On 5/2/22 12:12 AM, Ronald Klop wrote:



 

Van: "Mikaël Urankar" <mikael@FreeBSD.org>

Datum: zondag, 1 mei 2022 17:56

Aan: Ronald Klop <ronald-lists@klop.ws>

Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for openjdk17-17.0.2+8.1 in configure







On 30/04/2022 15:49, Ronald Klop wrote:

> Hi,

>

> Openjdk17 and openjdk13 are failing on 130arm64.

>

> This started in March, I don't see a bug report in Bugzilla about it.

> Openjdk17 is a LTS version so it would be nice to have that one fixed. > Openjdk13 is deprecated so don't bother about that one but mentioning > is because it might be related.

>

> Below the openjdk17 log.

>

> The build for main-arm64 had the same error: (IPv6:) > http://ampere2.nyi.freebsd.org/data/main-arm64-default/p62850d28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log

>

> Regards,

> Ronald.



Hi,



It's similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260187

 










Hi,



Thanks for sharing your memory of closed issues!



Would the port need something like this?



ELF_FEATURES=       noaslr:bootstrap-openjdk17/bin/java



Maybe with a conditional on aarch64.



Regards,

Ronald.

 









------=_Part_3_102238385.1652107685130--

From nobody Mon May  9 20:52:58 2022
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 2F5281ADE251;
	Mon,  9 May 2022 20:53:14 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxtfx17Ghz4sR7;
	Mon,  9 May 2022 20:53:12 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=In-Reply-To:Message-ID:From:MIME-Version:Date:References:Subject:Cc
	:To:Content-Type:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=YkqGsN9JjDjy+aBDaq+wbN0ps6SrGwfeCjIwpw7ik2E=; b=dOLtwjxoc+7C7SZY0tbS8lwKCu
	Rb0tDEZfzitg+9gB8FzvuSZTGx6aRdfE/MP84h/C6Odyr11Nmg9pDeWHMIFSjAwNdrWeV+Ktc4yR/
	mC1DMA0FUqOQq+6C9X3HWLF/c5Anw1VltNHm35Cn9g4BwTCphNb2ndyB6UDZKOPsS30I=;
Content-Type: multipart/alternative; boundary=----------JvFftLeOXZmsY4i5u55a88
To: "Greg Lewis" , "Ronald Klop" 
Cc: =?iso-8859-15?Q?Mika=EBl_Urankar?= ,
 freebsd-arm@freebsd.org, freebsd-java@freebsd.org
Subject: Re: [package - 130arm64-default][java/openjdk17] Failed for
 openjdk17-17.0.2+8.1 in configure
References: <202204301129.23UBTh9D082833@ampere3.nyi.freebsd.org>  <9f0d2c0b-2ef3-9a5f-3bf4-e3c4068947a4@FreeBSD.org> <1486531687.70.1651475552058@localhost> <01010180a1dfcd05-c3089932-de45-4a67-8910-3142a37ef4d6-000000@us-west-2.amazonses.com> <1525249842.4.1652107685143@mailrelay>
Date: Mon, 09 May 2022 22:52:58 +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
From: "Ronald Klop" 
Message-ID: 
In-Reply-To: <1525249842.4.1652107685143@mailrelay>
User-Agent: Opera Mail/1.0 (Win32)
X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: /
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 0bbd9ee05eb15d243ee94bf35138a91f
X-Rspamd-Queue-Id: 4Kxtfx17Ghz4sR7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=dOLtwjxo;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-2.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related];
	 URI_COUNT_ODD(1.00)[3];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-java];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10004
Lines: 315

------------JvFftLeOXZmsY4i5u55a88
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable

On Mon, 09 May 2022 16:48:05 +0200, Ronald Klop   =

wrote:

> Hi,
>
> This patch works for me. I didn't test the builded openjdk17 yet. I  =

> guess that needs the same construction but we will see after building =
is  =

> >finished.


At least it helped the openjdk17 build get further than the configure  =

phase. It now errors somewhere during the build because the openjdk17 po=
rt  =

seems to build and use some intermediate java binaries which exhibit the=
  =

same error. I don't know how to run elfctl on these.

Doesn't Java on AMD64 have the same issue? If not, what is the differenc=
e  =

in ASLR handling of the kernel or of the java programs on AMD64 vs. ARM6=
4?

Regards,
Ronald.



>
>
> Regards,
> Ronald.
>
>
> diff --git a/java/bootstrap-openjdk17/Makefile  =

> b/java/bootstrap-openjdk17/Makefile
> index 9cb49ca170af..693da01a2395 100644
> --- a/java/bootstrap-openjdk17/Makefile
> +++ b/java/bootstrap-openjdk17/Makefile
> @@ -1,5 +1,6 @@
> PORTNAME=3D      openjdk17
> PORTVERSION=3D   17.0.1.12.1
> +PORTREVISION=3D  1
> CATEGORIES=3D    java devel
> MASTER_SITES=3D  LOCAL/glewis/bootstrap-openjdk17 \
>                LOCAL/pkubaj/bootstrap-openjdk17
> @@ -40,6 +41,13 @@ PLIST_SUB+=3D  NOT_I386=3D"@comment "
> PLIST_SUB+=3D    NOT_I386=3D""
> .endif
>+.if ${ARCH:Maarch64*}
> +USES+=3D elfctl
> +ELF_FEATURES=3D  +noaslr:bin/*
> +
> +pre-install: elfctl-post-build # Workaround NO_BUILD
> +.endif
> +
> do-install:
>        @cd ${WRKSRC} && ${COPYTREE_SHARE} . ${INSTALLDIR}
>        @cd ${WRKSRC} && ${COPYTREE_BIN} bin ${INSTALLDIR}
>
>
>   =

> Van: Greg Lewis 
> Datum: zondag, 8 mei 2022 06:14
> Aan: Ronald Klop , "Mika=EBl Urankar"  =

> 
> CC: freebsd-java@freebsd.org, freebsd-arm@freebsd.org
> Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed for=
  =

> openjdk17-17.0.2+8.1 in configure
>>
>> Is the suggestion to put that into the openjdk17 port Makefile?  I'll=
  =

>> look for some documentation on this.
>>
>> FWIW, the bootstrap just works on the AWS hardware I stand up for  =

>> aarch64.  Although that is also where I built the bootstrap images.  =
If  =

>> >>someone has some different hardware that would be preferable?
>>
>> -- Greg
>> On 5/2/22 12:12 AM, Ronald Klop wrote:
>>>   =

>>> Van: "Mika=EBl Urankar" 
>>> Datum: zondag, 1 mei 2022 17:56
>>> Aan: Ronald Klop 
>>> Onderwerp: Re: [package - 130arm64-default][java/openjdk17] Failed f=
or  =

>>> openjdk17-17.0.2+8.1 in configure
>>>> On 30/04/2022 15:49, Ronald Klop wrote:
>>>>> Hi,
>>>>>
>>>>> Openjdk17 and openjdk13 are failing on 130arm64.
>>>>>
>>>>> This started in March, I don't see a bug report in Bugzilla about =
it.
>>>>> Openjdk17 is a LTS version so it would be nice to have that one  =

>>>>> fixed. > Openjdk13 is deprecated so don't bother about that >>>>on=
e  =

>>>>> but mentioning > is because it might be related.
>>>>>
>>>>> Below the openjdk17 log.
>>>>>
>>>>> The build for main-arm64 had the same error: (IPv6:) >  =

>>>>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/>>>>p62850d=
28ca57_s651a887f4e/logs/errors/openjdk17-17.0.2+8.1.log
>>>>>
>>>>> Regards,
>>>>> Ronald.
>>>>
>>>> Hi,
>>>>
>>>> It's similar to  =

>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260187
>>>>
>>>
>>>
>>> Hi,
>>>
>>> Thanks for sharing your memory of closed issues!
>>>
>>> Would the port need something like this?
>>>
>>> ELF_FEATURES=3D       noaslr:bootstrap-openjdk17/bin/java
>>>
>>> Maybe with a conditional on aarch64.
>>>
>>> Regards,
>>> Ronald.
------------JvFftLeOXZmsY4i5u55a88
Content-Type: multipart/related; boundary=----------JvFftLeOXZmsY4sSKi3Zc3

------------JvFftLeOXZmsY4sSKi3Zc3
Content-Type: text/html; charset=iso-8859-15
Content-ID: 
Content-Transfer-Encoding: Quoted-Printable








Hi,


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.


 


Setting console=3D"efi" is not helping =
to have the virtual serial console access using putty for ARM64. It is befo=
re any kernel module loaded.



I can get the loader output in vmconnect.exe but =
not in the putty.



 


Though I can see VM is getting connected to Hyper=
-V virtual COM1 console. But no output is coming to putty.


 


I have following question :


Any specific support from EFI firmware, is requir=
ed for virtual serial to work in EFI loader in this phase of loading?<=
/o:p>


 


I can see FreeBSD EFI loader is able to read the =
ConInDev and ConOutDev variables.


 


With set console=3D"efi" or set console=
=3D"comconsole,efi"  or set console=3D"efi" , noth=
ing in getting redirected in putty in arm64.


But in X86 that is not the problem.

 


Without this debugging the bring up of FreeBSD on=
 arm64 Hyper-V is quite difficult. Any help or pointers are really apprecia=
ted.


 


Regards,


Souradeep


 






--_000_PSAP153MB0536FC1FA3DA80BC228AEC6ECCD49PSAP153MB0536APCP_--

From nobody Tue May 24 12:26:31 2022
X-Original-To: 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 B98C61B4DD98
	for ; Tue, 24 May 2022 12:26:49 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020014.outbound.protection.outlook.com [52.101.128.14])
	(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 4L6tjd1K06z3rjb
	for ; Tue, 24 May 2022 12:26:45 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RmnNlvBg+c6bDa7zUSCM7wziAOI6aS8c21wcvpbr+2XYRsx5ncG/un6WBlwlvvVVgVLbz2AddS9BpdQgLCM/LG2Pp4HYbz/6Q0tywUrkC2H0qrty75nQM6t9QxbtikINzgFI9tLra4DFqGMO89jOt4TqCShPCdc1ixdKj/qOQnrkUWRr3D1aD9OUjymAOGov/gwOiQiNwMyBp9uT8+DwPM8x+G93xvq1Xddlgku16bT1o7XfXovh7Qsu9O63jpOlx+4Ym+pJr7pNseUlJE0iNyhqsiDX9JWPrIX1/tOVUgMYnTz2JYHbDIiPd3pU8S2oCuvUCtfiizq85HS8RO0qWg==
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=EyRXdVUIG6kfA2yTq+cliXgIjzc5fKA6x37XSywlyS0=;
 b=cZRwc4F9VMcch3KHzAaRttPDbDA1egrpJnDjFycXCzfvBH6/cdJbKgwcprZQfyXvdFZzBEucW7picUie7bCvFcW41cFNfX8G614nZ+wFEEPXHCujhZiQRACd8zvanLVqWXoARzYA6sZ8L7vYD6SDZhczk7WfLjdmuwccUqCtfEmST8ElaSp1HMG9ln6CHDqMUsJJA/h4t1pq5XE5qbRo9WyCLxr6wvsO48S9i5P94rcZYY8GWJgLWmN1htBtCXssYygCCsJHsm4Scrv61MA+8oEF8m3IRZloiBNgGoZczEAqaqOEAUG//5CzNteGA9t3IyDiYZxoHHU1tTJUwe5oag==
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=EyRXdVUIG6kfA2yTq+cliXgIjzc5fKA6x37XSywlyS0=;
 b=bHDi6RBXeWJpfvyGGv5NMqNPngBda5b7/c3kf9SEn90SgxlSGxeWfPYdA/D9+Ncod/OaBGLdizMS2T/Y1F1b3QWORM6dUDGOqwJf8Ny+ifdN/owWc84cick+ymqS8xkGY78cY0htYcFhkE0nqLRZV8SUKHspUIiYNIC7L+I8CG4=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by TYZP153MB0479.APCP153.PROD.OUTLOOK.COM (2603:1096:400:54::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.1; Tue, 24 May
 2022 12:26:31 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd%6]) with mapi id 15.20.5314.005; Tue, 24 May 2022
 12:26:31 +0000
From: Souradeep Chakrabarti 
To: "arm@freebsd.org" , "hacker@freebsd.org"
	
CC: Wei Hu 
Subject: RE: unable to get virtual serial console for EFI
Thread-Topic: unable to get virtual serial console for EFI
Thread-Index: AdhuioZ1RmwGFkAIQSSs+orr/q96BgA3sRNw
Date: Tue, 24 May 2022 12:26:31 +0000
Message-ID:
 
References:
 
In-Reply-To:
 
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=5770f6ef-1257-45a3-91d5-831d3060b3cf;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=2022-05-23T09:48:53Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9da58d2a-9ec0-4949-e395-08da3d80a280
x-ms-traffictypediagnostic: TYZP153MB0479:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 weBpVbt3/csbh6CRj296MUOURYhpcY39/MESMpqBXbLxJ+K8Bm2RMn5QWF0CzM+iuO/EabX+wZxtWM0mftwciZH818LFdf4U70RwtViTQdY8pWIwPpz96T+PryBROp+tNNmspFmi22xPI0AlfQRkXhFeHWCwJT3dY/RL8l59kNivopZikn65ogN6/+r/yu9WMWhuyKLG9IAigM6saPlTFQXZ0rSBVnOJ9ZqKglPrJHADoxbtxmSXSTdFfV6FL2lNZXdiolC5Wmq5872MfPyT7XFjibDDYiqtj8Wa043dwMwYPM6o2x9nAwbTrJ0NmiErL4j91K9BDr8QWYAogRh6uVx/gTtubYOHETQhnHcMa1n5MkfzV6bF8pFSJQf9pLeoN1AqDmu5OGLM7nzj3vDxqpT8ws3gzsQWZ3uvmhtmR6oa7wsuLrf1w+dsPO0/HsparRhlfyNMSkGiVo397oVXlN29MzxVPUXB34Hys8k7d9VzhSygpyNRB82CiqXUDuJNPjEhbZoFhyAwnEc7WAb5ywpMwITbkaJLczPuhg6wDC4wQ3K//SSQw+W6rbh5LMjVTd7Y8IsxIwsWs1CuhU7201jTmZv7MIRUwuNq98Huzf/oeB3BDKTM87UGZ/xwMT56YjBMte43wnPi97+Man6GcP5B6IGvN2xntNVjZG6HFf6Uh4ZFv1otMkRszsI/em0ShlifTuKlDSv8lPRkywBMQRyCJuitHQuyyIK359Eod9whyFhXnCdQI8qtZGzmBHLoHxm59QuU2MDo0cuOAQytA2Lb1HbzRdB8Y29mR606Uuo=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(508600001)(8990500004)(316002)(86362001)(53546011)(55016003)(71200400001)(33656002)(83380400001)(107886003)(2906002)(66946007)(4326008)(8676002)(5660300002)(450100002)(66446008)(66476007)(66556008)(64756008)(82960400001)(82950400001)(76116006)(9326002)(110136005)(186003)(6506007)(7696005)(9686003)(52536014)(26005)(10290500003)(38070700005)(122000001)(8936002)(38100700002)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?1KAvK2m6M+HxtJO7ikZowDVLxQbnafCllJzlCqeNSyX2WDCJ07TnRYQOSeWD?=
 =?us-ascii?Q?rn6Hb9Ed0XJx7lSc2jQTQVVkDMZJggolpdqavfRDV9fWXhPXfa4RVrNrU5Cb?=
 =?us-ascii?Q?hmifFAFheEyGucb/EyZByB6mynbMwcSB81R0Iu7+nVH0lEGJqVzTJ+XxbGR+?=
 =?us-ascii?Q?MrMlhFeVyAKgbxGZsVc7sMHwAIzHBTlmLYhyOhOgofUXIVZ2I5/lwmYI/CR6?=
 =?us-ascii?Q?BUv1xheLkSRsn4Fm+8TjtxXSLBtCo1k0rYecxwr6gTBdPrGI4/db95dBAIpt?=
 =?us-ascii?Q?+ABpOvCyPBqmWVbNM6BinDkhU0+1356QAEh87cn0dPPTSzbqpsAAh5kCuMQg?=
 =?us-ascii?Q?0o3oUVNCqmycPQaXhY+gihrikodxHh+Nm2snkBoy2nRtrQ5p8xL+bFPgbUQZ?=
 =?us-ascii?Q?AdG7ZhEuNess3SPl0Y/YIUA8R8VGNWYAJ+yMkVg4CGMvEeNj4lP+lcPLYT+J?=
 =?us-ascii?Q?JinsepsQ6Bo7O60BEYU9Fw+b87AKP+jBDho0Mw8jt1MXvZP+Ve2BjOS1gx9F?=
 =?us-ascii?Q?GxFKpXU6j4afrSEtMXw8TZJRunw37nJIJDZ2vBAPwaew49fDUWHi8z+sXhDI?=
 =?us-ascii?Q?PNYVpq219EBDQNPNhnmox6ZA19GUtqASl2CkGjvjj9hRlLgxsNE6sHBFQFIp?=
 =?us-ascii?Q?PdI06bHhFfZ63nAZNmyMF2mLR1psz3ickXmeEkdLoctaKNusw3qgudw5xgSZ?=
 =?us-ascii?Q?eTCha5lj0DECDJu0vl8R7uxB37HixD738hTPcTEp+lf5/tkzIayUVfTfPlkB?=
 =?us-ascii?Q?d6V0PPCqRT76lKgnyfSV1dePAcJ2wpAyonNZgU2oDqaps/hvi7Z65tqjAmpw?=
 =?us-ascii?Q?sne0pf0RZtgxvGg6g4yI27s9sQl+065zxVY1y43OfmXJevyUA3+QTgajvSMJ?=
 =?us-ascii?Q?UtNrMrcQgPGhAmg3DTkeHIUxeOws2ngaFVIs0+8v+3Ntp5VKWzunAknlsXOg?=
 =?us-ascii?Q?NBE6ssTDvjotTvMXb3m52RTeBbQnKZqfMYJi6ZXXVOGPvJ1qQGZwzt7DSe1O?=
 =?us-ascii?Q?LbJlJNUk+mQ49mwt5uSXORdd0BYrEDSJi6gXTIKmuKzVppel3tAbPDp91XuA?=
 =?us-ascii?Q?twApEsB+xV0jvcDgvx4YJkKs/ELtm+ooOfnJMo5DKxWkvwR+GVm7moO0vqbm?=
 =?us-ascii?Q?8+gyrxC/P/idsZ0qno07RlE80T5CtJ2Ev9IelNAXzLZCl9C8tpVcPUv+xfFv?=
 =?us-ascii?Q?/5ge8j2yNoboGa0DbRNhSdPrrsfqk8a5eLRt7INa9jYqpO52OR0ZdfUNZ1YB?=
 =?us-ascii?Q?rE+LF0XIVSJJJdVlCHcuiYEOSNM6jRPRnKZAuoS0DTfW7rgm9GcthMQqz6oa?=
 =?us-ascii?Q?at9a5cHEu+NFwv0xgMD9x3K88aUXxf+jE+9RvVsMuTY6zsQj+7wLIfVI3kAZ?=
 =?us-ascii?Q?S0qxbaxHQ2G2QqXXcMCLJQEAveD1iLJm07VFLb+Q86TC+Z7EFFcoAreq4VmU?=
 =?us-ascii?Q?m11UKO6dbvNJb98M1HpQddao+2T0QTMFxvXzFZ9llK9gftaytu4DrnyV4yTa?=
 =?us-ascii?Q?xSckX8ykb3IhZSO5E+NIjKBEmoFz7TN0qVDBCIBimCZzkfloO1crXigfqu9J?=
 =?us-ascii?Q?u8x/YsjNZx8ITfq2rM1Qi5OODBjJHIAp1FaFnDdygCvYR1739TlL+haaNM+Y?=
 =?us-ascii?Q?zZMMlAQoNWzUNu4upn9w/+ZrwVdtCGrDxJnASBgTg/4H9MERBu3LoXXf3GRa?=
 =?us-ascii?Q?MmZxET5iLKSQZR0+UjAUtoxaIzw=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB0536353A03BF26D0F384842DCCD79PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 9da58d2a-9ec0-4949-e395-08da3d80a280
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2022 12:26:31.7497
 (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: 9ccQd3cP21cGpFX0rYlOhUeUBYTaQBGX2a8tgQqNkbAwzW38xX6n2znLFxDcMBINmOngsjcNCJ5llYkEBdpnNeM9ST64JtYkxdK9BdD5Ctc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0479
X-Rspamd-Queue-Id: 4L6tjd1K06z3rjb
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=bHDi6RBX;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.14 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.85 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 NEURAL_HAM_SHORT(-0.85)[-0.855];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9010
Lines: 261

--_000_PSAP153MB0536353A03BF26D0F384842DCCD79PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,

I am trying to get the virtual serial console to access via putty while boo=
ting FreeBSD 13 arm64 bootonly on Hyper-V.


Setting console=3D"efi" is not helping to have the virtual serial console a=
ccess using putty for ARM64. It is before any kernel module loaded.

I can get the loader output in vmconnect.exe but not in the putty.



Though I can see VM is getting connected to Hyper-V virtual COM1 console. B=
ut no output is coming to putty.



I have following question :

Any specific support from EFI firmware, is required for virtual serial to w=
ork in EFI loader in this phase of loading?



I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var=
iables.



With set console=3D"efi" or set console=3D"comconsole,efi"  or set console=
=3D"efi" , nothing in getting redirected in putty in arm64.

But in X86 that is not the problem.



Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di=
fficult. Any help or pointers are really appreciated.



Regards,

Souradeep


From: Souradeep Chakrabarti
Sent: Monday, May 23, 2022 3:28 PM
To: arm@freebsd.org
Cc: Wei Hu 
Subject: unable to get virtual serial console for EFI

Hi,
I am trying to get the virtual serial console to access via putty while boo=
ting FreeBSD 13 arm64 bootonly on Hyper-V.


Setting console=3D"efi" is not helping to have the virtual serial console a=
ccess using putty for ARM64. It is before any kernel module loaded.

I can get the loader output in vmconnect.exe but not in the putty.



Though I can see VM is getting connected to Hyper-V virtual COM1 console. B=
ut no output is coming to putty.



I have following question :

Any specific support from EFI firmware, is required for virtual serial to w=
ork in EFI loader in this phase of loading?



I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var=
iables.



With set console=3D"efi" or set console=3D"comconsole,efi"  or set console=
=3D"efi" , nothing in getting redirected in putty in arm64.

But in X86 that is not the problem.



Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di=
fficult. Any help or pointers are really appreciated.



Regards,

Souradeep


--_000_PSAP153MB0536353A03BF26D0F384842DCCD79PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 


Hi,


 


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.


 


Setting console=3D"efi" is not helping =
to have the virtual serial console access using putty for ARM64. It is befo=
re any kernel module loaded.



I can get the loader output in vmconnect.exe but =
not in the putty.



 


Though I can see VM is getting connected to Hyper=
-V virtual COM1 console. But no output is coming to putty.


 


I have following question :


Any specific support from EFI firmware, is requir=
ed for virtual serial to work in EFI loader in this phase of loading?<=
/o:p>


 


I can see FreeBSD EFI loader is able to read the =
ConInDev and ConOutDev variables.


 


With set console=3D"efi" or set console=
=3D"comconsole,efi"  or set console=3D"efi" , noth=
ing in getting redirected in putty in arm64.


But in X86 that is not the problem.

 


Without this debugging the bring up of FreeBSD on=
 arm64 Hyper-V is quite difficult. Any help or pointers are really apprecia=
ted.


 


Regards,


Souradeep


 


 






From: Souradeep Chakrabarti


Sent: Monday, May 23, 2022 3:28 PM

To: arm@freebsd.org

Cc: Wei Hu <weh@microsoft.com>

Subject: unable to get virtual serial console for EFI






 


Hi,


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.


 


Setting console=3D"efi" is not helping =
to have the virtual serial console access using putty for ARM64. It is befo=
re any kernel module loaded.



I can get the loader output in vmconnect.exe but =
not in the putty.



 


Though I can see VM is getting connected to Hyper=
-V virtual COM1 console. But no output is coming to putty.


 


I have following question :


Any specific support from EFI firmware, is requir=
ed for virtual serial to work in EFI loader in this phase of loading?<=
/o:p>


 


I can see FreeBSD EFI loader is able to read the =
ConInDev and ConOutDev variables.


 


With set console=3D"efi" or set console=
=3D"comconsole,efi"  or set console=3D"efi" , noth=
ing in getting redirected in putty in arm64.


But in X86 that is not the problem.

 


Without this debugging the bring up of FreeBSD on=
 arm64 Hyper-V is quite difficult. Any help or pointers are really apprecia=
ted.


 


Regards,


Souradeep


 






--_000_PSAP153MB0536353A03BF26D0F384842DCCD79PSAP153MB0536APCP_--

From nobody Tue May 24 12:29:05 2022
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 0C3AE1B4E313;
	Tue, 24 May 2022 12:29:17 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2104.outbound.protection.outlook.com [40.107.117.104])
	(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 4L6tmW5cRBz3s9c;
	Tue, 24 May 2022 12:29:15 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Oo9Q6nKJ6g0lZQcyg4w+g8M/USAj2O3phIrH5U7EH2XlCAvPLBclnUZ8S850S46HCCjV/Zt4MBoY4vflQi30bwKabUhkXDpbf3p2XIr4DwS/78fj2W+xMvOGqXG6hBNMqz0llUpXsfWs6N4Ri7DfSJmh2u3wVAV+IviTBWW4QPxi35usGhd6Ky2V1nT03nIKglDv+dErD4CMjumMVrB53YjQKc97SRyggviZ3Y6xoYXrkNlIxZh+TbQwTR/dqum13BFIFq78hm6ggRg1HNlKfocTPV5odgpORu1RvH3OgxO06VYbik8bToB5e9sH54dZSDuAsDtwPVjElsAGRXBRyQ==
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=E2ZBueQyt/XxGsfgfYPu2+acvdnLcdgCh4EiqdFfvDE=;
 b=KQhtINMtqgNON5r3ftIJYZ0DPqJ1w2oi8JwNAWoOMqjUIutXx+zXkZ+Jb73OJwPsNmZobjz/5/jaTLDJ1n8IqTm173uATxB/K4c1XZmlZ4CMyYWpn2zdqENWznwthne8+zVowPzhyrenVH45ekJOK3lpoIT45TXRBe+Wahxd4v2vk4+K12aT+/HobyhNHU9hHcl/TaE8c9AuFfcco6kOcN8jiynTCkCQKFpa2ecl9OxktVkNvritat3z0VMlMu4QWP5eLaXVD2+k8OR91N7QGdykbfFDRR4EEpVmfLAXyJld872Jylxk7ldNkzLtdJVi7pRN6eu0V2NM8M3EQLlc/Q==
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=E2ZBueQyt/XxGsfgfYPu2+acvdnLcdgCh4EiqdFfvDE=;
 b=B/9eDCl6ipXcvXWH2Cijgb6vfCaZrKvwyexmqFzq2H1PQVENSGcteteWApdSN1lR8zc7s6tBlCsA5JmcOhi2j6PqgUe1KEB1QaRFtqT5eMePrGC2G41LKSJE6GK76ynOW4UBRG8fEaf402vzFotiGQqeKUzaVM60/QlfRaid/Vc=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by TYZP153MB0479.APCP153.PROD.OUTLOOK.COM (2603:1096:400:54::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.1; Tue, 24 May
 2022 12:29:05 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd%6]) with mapi id 15.20.5314.005; Tue, 24 May 2022
 12:29:05 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" ,
	"freebsd-hackers@FreeBSD.org" 
CC: Wei Hu 
Subject: RE: unable to get virtual serial console for EFI
Thread-Topic: unable to get virtual serial console for EFI
Thread-Index: AdhuioZ1RmwGFkAIQSSs+orr/q96BgA3sRNwAAAabeA=
Date: Tue, 24 May 2022 12:29:05 +0000
Message-ID:
 
References:
 
 
In-Reply-To:
 
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=5770f6ef-1257-45a3-91d5-831d3060b3cf;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=2022-05-23T09:48:53Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: acef6bbc-9b3a-4678-ac1a-08da3d80fe10
x-ms-traffictypediagnostic: TYZP153MB0479:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 1uQtU/rzgaS2u/Y947SDtL6Hdcck8X++3lMi+3TjgVtWok/1L3GmAkFXVlu1v997G2kh82DZT9KRsZWTVsZY57GPIqQEuqrF0oKukf/7XvS2ceYxiTqV6aR/daGw/3GshSUD4Zg4Xy+G4GxrUZ1AkwB9SYF1eHGwsmfs6VI2z9bUtX6oOwwqx6yRSQSw/0NEqnpfE/PGry2hTOtC0MpfbN4RywRDVJpe42JC/5O+JoWlg6hazy5BCzug4HZuWDRvLTHxSUZFU0hH4Eioa0KKH/f/4yfLPci7Qhs059fSqDxTpr9x5ITpDJ4R+Vft90dl1onC/i5QJNby91dfUHFVO59cPervt5Qelre+i5VixWNIWMKjORhMizcFX3ZxlEUVH9KDsvDXy4MIr5527Mx47spOEE6kZibDJHwuIseT39ZqMlaqstM7el+bjRnyaUJhgv7wTmpB8EL+oN/P4uTCbqvz41G4cx0xHm2FIctG9zgsdlF/VDK8PkbAQ3DxnUH4LBHjwO1e5tEbd+Oc8teYVn0wcdjUd6zw0C8EpcbbIz2DzH+/ixDrihE9VqBMYxLAJNcYi+GULL/mVP+PyY6iPdma1wkZq/Rv3pQhpP2EGYUX7ZIXVPxnAq1stC/0JXjZU9VQ7lOKBesY7lRh6xybEjtu4nE7kVr6dFpPSx1XjpoiL2HBYJ8k/zjE2cJ8GI7wISJ/VWdPs/4MPfn3MjcZpd0wxIDJlYXMtt7z+QeT+i2onbYqrkI6n9VJEr/PMGWAEXYTV/wa5pJnWnlq5lmjJBOBV+1o9+0TFgGmrFtyXQM=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(508600001)(8990500004)(316002)(2940100002)(86362001)(55016003)(71200400001)(33656002)(83380400001)(107886003)(2906002)(66946007)(4326008)(8676002)(5660300002)(450100002)(66446008)(66476007)(66556008)(64756008)(82960400001)(82950400001)(4744005)(76116006)(9326002)(110136005)(186003)(6506007)(7696005)(9686003)(52536014)(26005)(10290500003)(38070700005)(122000001)(8936002)(38100700002)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?fJwinjyBSH8B+rP7q7q6+xz8bhbu6+6Nn3Is+PfmfbrKWSyCURXqnP168ek/?=
 =?us-ascii?Q?mNGrOXDjgS5ASGhZEmBDCsN4UrPrKKIhj8DyUmGIWIYw2v1vJOJWNQYp9QRD?=
 =?us-ascii?Q?DdtZilcBDBVoMRIu8IY428b7VhCnEEvFIWKqSnnUA49e8AsiJSH2QjB5RUjm?=
 =?us-ascii?Q?NBdDF0ZC3/vqMN5mHuppwBHkSNauVzA4nWpV3mh8iEQQA/4T4OVlQPO+nWLH?=
 =?us-ascii?Q?N2GOaEcaesPvltwz3BDjMzXE/ZJnaEnq3fnD6qDk8Rvar+HNMvN0SzuKK3ZF?=
 =?us-ascii?Q?k4wZmYqPo+aJqiPAKsF2qroAItoUy6U0EYgE6YyYqor92SIQzeLWNiCVMJKV?=
 =?us-ascii?Q?eY8R6p7YQYOW7vz7v/5DTV2gxhVOYF9jTGHOLUO70xB6D8PPoK3EPUW0NpCn?=
 =?us-ascii?Q?Q/GPglfdyEiEk/fN/ygb4stJV/CVd+fX0Pt9PEz10uOqL/I/SG9jqzf2jNx/?=
 =?us-ascii?Q?BjvMd2nrBPMUmUR5nrIDpY7fB97CzlYv5VhkdsU2b9NIZWorIldHM+B8+G9q?=
 =?us-ascii?Q?ZNuy90lJSQUsY0cg9WPPhxyeEdHScKsVOwrSxt5LZix+bbj+GVdRhjwSIhKI?=
 =?us-ascii?Q?sgUI3fV9f/I0u8JFv3On/Se6D0sJlXtNF8lGAmYWtdM4bWXYeoKaX44NomFX?=
 =?us-ascii?Q?yX8oAixS1mq2oInsEEoJAiG4EsahPuotK8x3oclXOC7SEXUISoOEUWWE+SwF?=
 =?us-ascii?Q?MfV7H2S/WQq1ocuh8q0DkNZaaZdmXZq3UEuCtGe+ZEyz3ZeKitqLIwRm18XE?=
 =?us-ascii?Q?b/IG/aZOkdXU7TamhYTcnMQTdtWBJbdOr2ANZMNUrJDo2MNbktRyTY1RZwkL?=
 =?us-ascii?Q?IOyv1fforcYHBNFnA80I+X/4WGdb4v9XMppeKQ4eF1X3Iv95el7a/cQ0ex3/?=
 =?us-ascii?Q?lxsvrKC9iDYXGljC1SNaiUybglJEked6IeCnt8blV1j/sxWu+64+ng1qY+6X?=
 =?us-ascii?Q?gEKe50jikQ6xRuFK9Lr8IPk+MQ3hF2DQbJmaPK9aYFyJiQMwv4kuCGzOOaqb?=
 =?us-ascii?Q?q6w8cmAb0v3opx9DC2j5o2LxRj0bD0MzflM/7cgJOgfUiDJuDGyOTyXE6b9M?=
 =?us-ascii?Q?+2etOpStq2DbZd4x2Mx1if1/GyNh9uJnPrnURdiACxIacprBjCWO/D/irHHi?=
 =?us-ascii?Q?DLGBkq6kj8gvzakIwOioCJw5fQhf8btr5JKzKbU8z7hiqYDPjTGDhK27Xz3N?=
 =?us-ascii?Q?aDkqgBFb92GR2vznyVtgD+dcUNaD1pp8aSfBbAr+BSTU4q19BDoazqJST1wc?=
 =?us-ascii?Q?XMTd+izevbrekvjInOt6mMWo4WsOvDbA8M7RFhMvQMnQLCH9LZn73ewnLcUs?=
 =?us-ascii?Q?r5qwZvltZS/1hq7AD7PpJRySjbkZ3AYoLLv2zkVQiP90ka8ogb5f0J3v/Caw?=
 =?us-ascii?Q?efDhIcbWRaHCY8sjSF1kAsYawGf4okfP+GScsBULA7H2yYmR6vYh2SHyOjPC?=
 =?us-ascii?Q?4ldDgnZi9eLjuM3G+Rape1IJVBBMGsRoIiaMMPHbrDV2KEvHWKbXeMEONdT5?=
 =?us-ascii?Q?fDVbYsw8VAmsmaw4AEzxsC5jPNmzFKFHDMtw4k5cAvja+2po9/PNknV8cVa6?=
 =?us-ascii?Q?z+gG4f0fgBs5Y+obTomtzETBAna+pO9xnEW4K/AQ0+Tn9WdW1+4Q2xBPOrJa?=
 =?us-ascii?Q?1gER+siMq6ncaUZl0VkSA1hRzRnNkVhq76uba0BgDbJXpTtVc1Aid7qjIAiV?=
 =?us-ascii?Q?OLYXWupFVSozkfnifF1impTpOE4=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: acef6bbc-9b3a-4678-ac1a-08da3d80fe10
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2022 12:29:05.3492
 (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: N9cVrlxEB/cxsYyqbs+ToGrAtodiYas57WoUa7wUDFyhhcLvnIqTQMjfgyNRZzBXWn1oeBKexQll2tfYf8UkPZEzr2rQP0UDMfotQ6OZa8w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0479
X-Rspamd-Queue-Id: 4L6tmW5cRBz3s9c
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="B/9eDCl6";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.117.104 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.96 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.117.104:from];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 MLMMJ_DEST(0.00)[freebsd-arm,freebsd-hackers];
	 NEURAL_HAM_SHORT(-0.96)[-0.957];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.117.104:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 5142
Lines: 152

--_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to get the virtual serial console to access via putty while boo=
ting FreeBSD 13 arm64 bootonly on Hyper-V.


Setting console=3D"efi" is not helping to have the virtual serial console a=
ccess using putty for ARM64. It is before any kernel module loaded.

I can get the loader output in vmconnect.exe but not in the putty.



Though I can see VM is getting connected to Hyper-V virtual COM1 console. B=
ut no output is coming to putty.



I have following question :

Any specific support from EFI firmware, is required for virtual serial to w=
ork in EFI loader in this phase of loading?



I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var=
iables.



With set console=3D"efi" or set console=3D"comconsole,efi"  or set console=
=3D"efi" , nothing in getting redirected in putty in arm64.

But in X86 that is not the problem.



Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di=
fficult. Any help or pointers are really appreciated.



Regards,

Souradeep



--_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.


 


Setting console=3D"efi" is not helping =
to have the virtual serial console access using putty for ARM64. It is befo=
re any kernel module loaded.



I can get the loader output in vmconnect.exe but =
not in the putty.



 


Though I can see VM is getting connected to Hyper=
-V virtual COM1 console. But no output is coming to putty.


 


I have following question :


Any specific support from EFI firmware, is requir=
ed for virtual serial to work in EFI loader in this phase of loading?<=
/o:p>


 


I can see FreeBSD EFI loader is able to read the =
ConInDev and ConOutDev variables.


 


With set console=3D"efi" or set console=
=3D"comconsole,efi"  or set console=3D"efi" , noth=
ing in getting redirected in putty in arm64.


But in X86 that is not the problem.

 


Without this debugging the bring up of FreeBSD on=
 arm64 Hyper-V is quite difficult. Any help or pointers are really apprecia=
ted.


 


Regards,


Souradeep


 


 






--_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_--

From nobody Tue May 24 14:52:31 2022
X-Original-To: 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 1294C1B44744
	for ; Tue, 24 May 2022 14:52:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34])
	(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 4L6xy34Kpnz4jxM
	for ; Tue, 24 May 2022 14:52:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe34.google.com with SMTP id b7so18498974vsq.1
        for ; Tue, 24 May 2022 07:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=slTQsWuMd5t45FkQuuZO9JMeQ4YZYwRTCCTvEBXKCo4=;
        b=zLel81eNT6mdPE382S7lm3ViyeAU8LGmCmUGJx06h8XjL+cnltm+8wrodJrsSNZqDJ
         42Iso/36+k6JrQcx4GmExJH/s2RKzoA+f+0mPOJFgMhJtcIf0B+pFw2Uc7XMOeNrx0+K
         UBM9QbOzWQYxHZPbuju8PZEbWcQd+fHTZsHNDBmYtl17h641itAQx2sjXk1UE5DAlTtv
         q+JxvE+aPFGXvCRkm3pTd4eAGqmtB84XjERqFkVuQroRGfNc8ue0U90fwaaalNt1oG1t
         UZG9zXk5ZJlb9qH8gOQOjjBoUWtdv1k76YFAyjK8cG6Sudt2mmvlJzAVsaASz3cBHIZy
         oFwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=slTQsWuMd5t45FkQuuZO9JMeQ4YZYwRTCCTvEBXKCo4=;
        b=3N/lDw/LPLJrSO5esM0TAmwo6NY1PYhADhW0LdaFDqQN9JDGvNWpgjJu2paDJ4ugq0
         rQTqZlQlA6g+hfhRH+MdWrk5yWhrUy57IPZDnf30CWRxuCeT52Z9wE6B690i8jySzJm/
         +58SH2OJwqPLGfVp6tT/Mq2ta9UqhHN21E4y7pKMA5IcV+Rv/vqjJShJqaTNoaoob9Em
         Gb9QFNwEznVLucss3jXpaHbGdMIa7ZPY3jHMhKJmNOAcSEa9EmiaPj/G/HVrzGCCy4pK
         OPz9WocIFZIzCGPocWfslLrgKl74ZPVBQtRNkn4mSqs0ksFnxxGt/LexumxQpriNUNgN
         WN4g==
X-Gm-Message-State: AOAM530/PpBUdwXf/DNXvAqEH9ryFPG3S2Z74mElYyL28qx2f9u7Kwir
	xqCiBdatnc4uIXW3xyB6xCyAOBXeE8qo1/h79TPC/pZUGdo=
X-Google-Smtp-Source: ABdhPJwnkR2hgb/yg3USHb6wDZqLFOXkaD6M0ph61oKUqIQuJe6vb8Dkz+YBMkZjMKxWoc6P7s9xeGSFgUzRgTNLWRQ=
X-Received: by 2002:a67:c988:0:b0:333:b089:61f9 with SMTP id
 y8-20020a67c988000000b00333b08961f9mr10766960vsk.42.1653403962808; Tue, 24
 May 2022 07:52:42 -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, 24 May 2022 08:52:31 -0600
Message-ID: 
Subject: Re: unable to get virtual serial console for EFI
To: Souradeep Chakrabarti 
Cc: "arm@freebsd.org" , Wei Hu 
Content-Type: multipart/alternative; boundary="000000000000dfad9205dfc31b71"
X-Rspamd-Queue-Id: 4L6xy34Kpnz4jxM
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=zLel81eN;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e34) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 RCVD_TLS_ALL(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[arm];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4593
Lines: 134

--000000000000dfad9205dfc31b71
Content-Type: text/plain; charset="UTF-8"

What does the ComOut variable say?

Warner


On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi,
>
> I am trying to get the virtual serial console to access via putty while
> booting FreeBSD 13 arm64 bootonly on Hyper-V.
>
>
>
> Setting console="efi" is not helping to have the virtual serial console
> access using putty for ARM64. It is before any kernel module loaded.
>
> I can get the loader output in vmconnect.exe but not in the putty.
>
>
>
> Though I can see VM is getting connected to Hyper-V virtual COM1 console.
> But no output is coming to putty.
>
>
>
> I have following question :
>
> Any specific support from EFI firmware, is required for virtual serial to
> work in EFI loader in this phase of loading?
>
>
>
> I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev
> variables.
>
>
>
> With set console="efi" or set console="comconsole,efi"  or set
> console="efi" , nothing in getting redirected in putty in arm64.
>
> But in X86 that is not the problem.
>
>
>
> Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite
> difficult. Any help or pointers are really appreciated.
>
>
>
> Regards,
>
> Souradeep
>
>
>

--000000000000dfad9205dfc31b71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What does the ComOut variable say?

Warn=
er


On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabart=
i <schakrabarti@microsoft.=
com> wrote:











Hi,


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.=



=C2=A0


Setting console=3D&qu=
ot;efi" is not helping to have the virtual serial console access using=
 putty for ARM64. It is before any kernel module loaded.



I can get the loader =
output in vmconnect.exe but not in the putty.



=C2=A0<=
/p>

Though I can see VM i=
s getting connected to Hyper-V virtual COM1 console. But no output is comin=
g to putty.


=C2=A0<=
/p>

I have following ques=
tion :


Any specific support =
from EFI firmware, is required for virtual serial to work in EFI loader in =
this phase of loading?


=C2=A0<=
/p>

I can see FreeBSD EFI=
 loader is able to read the ConInDev and ConOutDev variables.=



=C2=A0<=
/p>

With set console=3D&q=
uot;efi" or set console=3D"comconsole,efi"=C2=A0 or set cons=
ole=3D"efi" , nothing in getting redirected in putty in arm64.=



But in X86 that is no=
t the problem.


=C2=A0<=
/p>

Without this debuggin=
g the bring up of FreeBSD on arm64 Hyper-V is quite difficult. Any help or =
pointers are really appreciated.


=C2=A0<=
/p>

Regards,


Souradeep


=C2=A0









--000000000000dfad9205dfc31b71--

From nobody Tue May 24 15:53:46 2022
X-Original-To: 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 CAB0D1AEB97C
	for ; Tue, 24 May 2022 15:53:57 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2109.outbound.protection.outlook.com [40.107.255.109])
	(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 4L6zJh4p5vz4vZ3
	for ; Tue, 24 May 2022 15:53:56 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Kmar11yyicfxbhcsuU28PsnFZcrK1yt43IXjHtF3dTHatPUhZirXkVKBji3UIOBdkjT1YSz8PBzq6qFag5ao3vQRv/VA0Aae9bIPGUXHF5qvjSVqfe0oE+p1gNV5FoTy1mhkZ/v3KUZpq+z5Otw+S5kIRm0nIgJXZr44hqctWobSCGQDjdoZKKjJSdRDupQsIUKxmQX9zZfbrzVVTVCYpIsZVRGmJ6XZfXKkwvHzBdai6LCTUW5G5zX7hZQbbZdcDE9m6G9eIyedc1xo4sP4sBlTaEX2t7P0OrtwILltuulOT3YKAMMU50NkRGbroHLB4ZkvNteIFuSS/iu4J0kNfw==
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=CJBEZBtNgaxFpnhsc2nB7JNM1uQ2U2UCit6DdN1/HIs=;
 b=Z1tNK+xo5HhLMSm6J6uqCn8id5/COkUs6zpJoVcYwyFwNqrtKHE99rrxpB/MMcSxorfnrb3c9mAKqlfG5LrVURNAoRKRW86y8DUZUAQIvhuLPSopVI0sWnBMNoBi2Qpe2Hm44AkH+oDcCx9lx6TkysYCD9UBGH88SofiSDlJREVPP9VvftbhrFEPMKSCTdKIK4oM7t2FrxEIAqVGQra8Gsph218F8p2DlmDQfkuStm1eyvXbNmWyGoaGS5yjteNoQLlG3jOiHrvRcSNwnyxQTfmNHa8cKVXOk0c+kdBElFsJTk92rSmvHkXmqHfnkBucAs3b76P2wjMAoGqtn5F9hw==
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=CJBEZBtNgaxFpnhsc2nB7JNM1uQ2U2UCit6DdN1/HIs=;
 b=T7NGrFGtIewTrGGv9rzkSFbt80iFzqXi4D04jDW+y4f3LUEcpZrV/LgqBXD19ehU5SoK8DlDqBws1CVlRGKNd7tGcXHwY4X123vb+93IEW+LH+eXZK1xHa7A4+tYXRW7HHt80sGqcpWe7lV0QDBPrqC7e+Z2ZwRRMZ4XHYQb1kU=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by TYZP153MB0430.APCP153.PROD.OUTLOOK.COM (2603:1096:400:2f::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.0; Tue, 24 May
 2022 15:53:47 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::6146:9fc6:62ef:9cfd%6]) with mapi id 15.20.5314.005; Tue, 24 May 2022
 15:53:46 +0000
From: Souradeep Chakrabarti 
To: Warner Losh 
CC: "arm@freebsd.org" , Wei Hu 
Subject: RE: [EXTERNAL] Re: unable to get virtual serial console for EFI
Thread-Topic: [EXTERNAL] Re: unable to get virtual serial console for EFI
Thread-Index: AdhuioZ1RmwGFkAIQSSs+orr/q96BgA8156AAAHd6VA=
Date: Tue, 24 May 2022 15:53:46 +0000
Message-ID:
 
References:
 
 
In-Reply-To:
 
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=6164c3c0-7bee-454d-b0cf-81d1bbd1bad9;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=2022-05-24T15:45:58Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ddd8011b-01d0-47b5-4e94-08da3d9d9652
x-ms-traffictypediagnostic: TYZP153MB0430:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 ToMoEWNrPIaMkEZz2jLdBtP5MoRH5dc8r7SG7bOcE6ZEkHgcqFmCoYzkkQEZpr+SfCZXE/pv6T0eJBN4aSSltosMQtk91Nz1q1fBb1Ed5PvMHtmcirAvzmAq7Glbqf6eKx6iDYGnAd16YrO1uvIfIlUvf9fLvkmXGsEYxdEUqMpmjfg0oFigLYJRDFxEAOtJU2fciy7AWDGhoQk4JuR6xHSXwNpGa60MilZC4DLfF1kr58ekQMKIUGy+olv5kdjXtHJTnEEC45m5gPXfQvKBpbE45QrFnS78DRAXidS63vNTz+Hght3Aj14KhzhHSsfJjHhLBnjnbqPzSIvqjYU30gPLo8PEnLi7IleQEqHKk7N2Z1psPWDzOtlnUsuhSeLDJDNGXZzyg40LU+cgQxkQ0Ab9IHDt2BuCoC9HpZ9hmIs0adBMurNP0zHOiKgjFxE9dUY9cEK0IeJfLVs+jf/8MqAbnAjbMKCxzcAG/JN9hBCgQGPM5thFtIqC2qIIn6CvZgZSNoiBfjRE9N8lWvgUSUlrYp3kqlEYpe8TdyB3+YcIJgAe7AdtKyQ9r6NyO2gEtkU9yLsmyJODTYBZGO+Zxx0pJzqyZzMBMuKUUuijyOmHT9xG5o8ZEkeeZyxG1NIM2IlqfJU4LNHF8T0M+Wzr8YNU1nknprg7m5rUgmUBNlSXPX2Iy1pTfsPsifW6f9nCBoiGqymnTc1MhKHR0R1rlfefCryd9UkcoXBQJtMTftE23u3x/7YCd1HYBKAaeWwBjdUvbgEta8Kp8vfBlHNPe4et+9Ih00qlVzBxPWWvdUw=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(66446008)(10290500003)(66946007)(33656002)(9326002)(52536014)(8936002)(107886003)(66476007)(76116006)(66556008)(4326008)(8676002)(64756008)(7696005)(26005)(53546011)(6506007)(55016003)(86362001)(9686003)(186003)(508600001)(5660300002)(83380400001)(38070700005)(122000001)(82950400001)(82960400001)(8990500004)(316002)(2906002)(71200400001)(54906003)(6916009)(38100700002)(166002)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?LNAMQz2UUGLeJ2OjuYo2rSvUXPaiL8vmOdwq413ph4eJOvitROW4Kt4OMHS5?=
 =?us-ascii?Q?iycJ9oT1g+2m1k1vugQGOFSe2DJmFeuy0/U12kC79KUQeiPf9cn7Q+tGdGyj?=
 =?us-ascii?Q?OyzSpAH+1UEUMQsfyX+ldWFokLoDt4nX07wARPxYdehvOnduNfNjMWmsyZSE?=
 =?us-ascii?Q?g9cklPPC9EBg3IfFrQx9uVdoghv0rapX66u0aSNcS+diZd9Q0cYL1tQVr0Wq?=
 =?us-ascii?Q?BXcriJNyxqCvcD9yLAE0fkq3st891UgD/0LauD67x6tWCFhk0lOMhouK9Cw+?=
 =?us-ascii?Q?RnyvK7tvB+3oTy7ZYIh9qzae2n2Z9eHcNE5E6PFod+2cmJGpTt8Aqt1tjqtB?=
 =?us-ascii?Q?sW7FhhvhZyODl1Lg1c0WtQcNVdLMjB5YvUlpUL+TA58ZDv2rMDe6iasaoHVU?=
 =?us-ascii?Q?7b5xtT53iZoo0EEmriN2zt/p1PiQEHnOhAKr+fzV/yyL7IUdAO8OvLephRJT?=
 =?us-ascii?Q?RD/XmkMHN558IHEG/tv6xZL1CB5IOWwXbavNgTYP3BIv0A13+CW2aCJ0OcVk?=
 =?us-ascii?Q?8pWlAgJuCDrIFSkUSm/Q46nHu1/ssOXdOUnZF84G5HQBXQQmQ+GxhH3piAuN?=
 =?us-ascii?Q?k6O3IXDCRGNBDePWC3YY+S1L5e9YO32BiDSi6BL3CvMMF6T5XlQa0dpZzg24?=
 =?us-ascii?Q?c1e61+T43uNs9t67jeWbPLdJWFYakNhKKqKtV5Kl2StLnWj466wdwNI71hQo?=
 =?us-ascii?Q?HAPG1eduxBHCP40eB80GJ1/d9yOs8la40Cqts9A6gIRBdW56gKZ5wCcj1NK/?=
 =?us-ascii?Q?N+cqTsQQnEXCPKSNlE8HwlJ+Jt0wbIaE/9Wo6BQwmdbsUMHQUFbyshtbVDEF?=
 =?us-ascii?Q?CUdeztFksR+oNunoo0V8hw1htcoGB3UuuzllFWdr69nRVIfZOVegJKRpS5sA?=
 =?us-ascii?Q?1mssNROooXr3HJ3CCwL7LEEpPK+PBtg7q75X1J5FMpVwhaqJhu5743CL7bL4?=
 =?us-ascii?Q?OP5+44I9pfUR5xFdpvZWNm2ncvfe6ySzWDdUKFf912Nrorx3IrsO9thh56ZV?=
 =?us-ascii?Q?D/BPcUDP41PgW22X4C74CSP0ICVes105Fh8+ozaTiCz/a7xisZs20YWVrbaQ?=
 =?us-ascii?Q?QK1J5TOuiP25kD0Vgf5BQJTPNwu2WZO41o/CTVKgcbd1s1JKUjk7JIMLJBol?=
 =?us-ascii?Q?V70eMfmf1EeJcJ94eL0gfukoRxjsK7FhxDK3ycyHgklnQmU9Mm1ObopgEvwS?=
 =?us-ascii?Q?YKM1ooaFEyIazjarkcfY07/bCxA4h6d4Sj4PmmJzojj3Sxnz/C1TPEYfxe5d?=
 =?us-ascii?Q?cXvSZnSIBeHieOuOI4i+pMafb/MaqGBzB+m82zEEhTb+4hdDw/lUDst04TgQ?=
 =?us-ascii?Q?jQxjHG6GZAQP3PHNT9A/DOQGVVR0JScfu0VNN0IQAotgQLxZhMX1iJ1s/HiI?=
 =?us-ascii?Q?YiDHOc19A6L3FjEDLgjc2kiewVNp0gshou93OqUknbHXorsJfCtxhkUmYkLR?=
 =?us-ascii?Q?KefsQ7yeD9qAGgvPe8ybIExYaXwasZWwLKhE4MR960s1LZmdTCGcKGnKN1Tg?=
 =?us-ascii?Q?OKpA8u8V4WzCaXt3Wo1UKvs94zOaiczACO1uNPzwkmmMkbQ0+OoF1nO6rlPU?=
 =?us-ascii?Q?7GUW+NU3bnXXxd64FRxcz8XLYtKPLALb6HpKizKc88tN5oNJEKEGaSlz23sW?=
 =?us-ascii?Q?nqCEBwvOS8PTCx6iw9KoY7fY+TcbNjNccsEk6Y0yuGYXnTXvaJkch2lGIFsE?=
 =?us-ascii?Q?mgDWk3PgcMSdqfZI2DzIW+OHmLA=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB05361BD405D44B0AE7CF39DACCD79PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: ddd8011b-01d0-47b5-4e94-08da3d9d9652
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2022 15:53:46.7002
 (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: v4IBsqxrgeyNJUtXB1+2sQ8LaWyYgzypmNn0IgKAwB7I5o9HL18DdvNo82ZWTSS9gwD8uN9Y7/ne8otj8KoeSqmsubN6Kb/l3KR5bL2kQb4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0430
X-Rspamd-Queue-Id: 4L6zJh4p5vz4vZ3
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=T7NGrFGt;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.109 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.109:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.109:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10053
Lines: 276

--_000_PSAP153MB05361BD405D44B0AE7CF39DACCD79PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Warner,

The ConOut is :

global NV,BS,RS ConOut =3D AcpiEx(VMBus,,)/VenHw(9B17E5A2-0891-42DD-B653-80=
B5C22809BA,02780ADA77E3AC4A8E770558EB1073F8C7E020566280CE4DAEB7520C7EF76171=
)

Regards,
Souradeep

From: Warner Losh 
Sent: Tuesday, May 24, 2022 8:23 PM
To: Souradeep Chakrabarti 
Cc: arm@freebsd.org; Wei Hu 
Subject: [EXTERNAL] Re: unable to get virtual serial console for EFI

You don't often get email from imp@bsdimp.com. Learn=
 why this is important
What does the ComOut variable say?

Warner


On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabarti > wrote:
Hi,
I am trying to get the virtual serial console to access via putty while boo=
ting FreeBSD 13 arm64 bootonly on Hyper-V.


Setting console=3D"efi" is not helping to have the virtual serial console a=
ccess using putty for ARM64. It is before any kernel module loaded.

I can get the loader output in vmconnect.exe but not in the putty.



Though I can see VM is getting connected to Hyper-V virtual COM1 console. B=
ut no output is coming to putty.



I have following question :

Any specific support from EFI firmware, is required for virtual serial to w=
ork in EFI loader in this phase of loading?



I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var=
iables.



With set console=3D"efi" or set console=3D"comconsole,efi"  or set console=
=3D"efi" , nothing in getting redirected in putty in arm64.

But in X86 that is not the problem.



Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di=
fficult. Any help or pointers are really appreciated.



Regards,

Souradeep


--_000_PSAP153MB05361BD405D44B0AE7CF39DACCD79PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Warner=
,


&nbs=
p;


The ConOu=
t is :


&nbs=
p;


global NV=
,BS,RS ConOut =3D AcpiEx(VMBus,,)/VenHw(9B17E5A2-0891-42DD-B653-80B5C22809B=
A,02780ADA77E3AC4A8E770558EB1073F8C7E020566280CE4DAEB7520C7EF76171)


&nbs=
p;


Regards,<=
o:p>


Souradeep=



&nbs=
p;






From: Warner Losh <imp@bsdimp.com>


Sent: Tuesday, May 24, 2022 8:23 PM

To: Souradeep Chakrabarti <schakrabarti@microsoft.com>

Cc: arm@freebsd.org; Wei Hu <weh@microsoft.com>

Subject: [EXTERNAL] Re: unable to get virtual serial console for EFI=







 












You don't often get email from
imp@bsdimp.com. 
Learn why this is important
















What does the ComOut variable say? 




 






Warner






 






 






On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabart=
i <schakrabarti@microsoft.=
com> wrote:










Hi,


I am trying to get the virtual serial console to access via putty =
while booting FreeBSD 13 arm64 bootonly on Hyper-V.


 


Setting console=3D&quo=
t;efi" is not helping to have the virtual serial console access using =
putty for ARM64. It is before any kernel module loaded.



I can get the loader o=
utput in vmconnect.exe but not in the putty.



 


Though I can see VM is=
 getting connected to Hyper-V virtual COM1 console. But no output is coming=
 to putty.


 


I have following quest=
ion :


Any specific support f=
rom EFI firmware, is required for virtual serial to work in EFI loader in t=
his phase of loading?


 


I can see FreeBSD EFI =
loader is able to read the ConInDev and ConOutDev variables.


 


With set console=3D&qu=
ot;efi" or set console=3D"comconsole,efi"  or set conso=
le=3D"efi" , nothing in getting redirected in putty in arm64.


But in X86 that is not=
 the problem.


 


Without this debugging=
 the bring up of FreeBSD on arm64 Hyper-V is quite difficult. Any help or p=
ointers are really appreciated.


 


Regards,

Souradeep

 
















--_000_PSAP153MB05361BD405D44B0AE7CF39DACCD79PSAP153MB0536APCP_--

From nobody Tue May 24 16:07:35 2022
X-Original-To: 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 A117C1AEF0AE
	for ; Tue, 24 May 2022 16:07:53 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35])
	(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 4L6zcm6YP8z3D42
	for ; Tue, 24 May 2022 16:07:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe35.google.com with SMTP id 67so3543326vsh.2
        for ; Tue, 24 May 2022 09:07:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=8jlPpY0KQ1UmSm4hEGE2Pgn9FfH4GubHmM4sfY1XE8w=;
        b=DmWlBNlJtuj94OISdjdRhTTn/Jk2FybYeoJN+NDlWzX1Jg1alZDd9KHuyeUZ0PsQw7
         txaraskLIP7+JUziDb3oazStHne7dNGVbg5mUi8Ucm33ZtDlgQAKWvpVS5uS8NeOfrxd
         aijK+cazrf8sLJbiMX4AxoYbZjjxtt9hg0s4HBhovNjCbDcKlaX0C51nH4RM7fNHihGB
         pzDR+MI33sfO4gjJZ/tXurA2S5ey6zy+IzW7hxK6V0nhhOSUuy4G8C96/gbdk9Ya2xal
         KOYfIw7PK2JVj2FY4fVEwkTcD8MYPgriHNu6J/QB3Mi8S7E2r4BUqzF6+yrWCzHv2k8B
         CoTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=8jlPpY0KQ1UmSm4hEGE2Pgn9FfH4GubHmM4sfY1XE8w=;
        b=c6SgDKz8rk2MSJ4e+pmhbfC0pOYbVRqCfxc59BHeo5k98TiVmHFDpHjlWVyKfog7/3
         YfdHeLXZu8fZ/97oy3njQxoA3xyf2/32A59bgbBvg831RPhsY3dGuNCoYtSNMyCYlKPm
         DzXjKkY8dQ0jfXAWkw7CmiHx7kDjxCMBrlJY9rmmgEz4mmV+FS37nIjLM5JkpXThXf16
         jmSpmWfE5pwW7TRWkv/ZwCdpv9tvJez+Z4W8afecViVgMXYgX5Ic/rmh9xY0cSK5JQqq
         XYDT3Ubsp3iir+UQBsC1+Mk0+r1NELN+kpv9IUBWbsS7l062fU4KvHA/OUvGPa5iRQtn
         pNlg==
X-Gm-Message-State: AOAM533xeV7q5b8x6YC2oZbh51sbaigFe+PRGoS4R2aKhD5W52cjIh1J
	mMlj35RnZrruiopNjUs2EugLU73B2zN4DW3n7LE/rccco/8=
X-Google-Smtp-Source: ABdhPJyFUFalKiIaba78Z8ep3CNnUBdVZsZqrrW/HMdEt1fyoRmNnXqjEp6xhvp01JGZqKMXYSgGx0ZX6f51gU1t7Po=
X-Received: by 2002:a67:a24e:0:b0:337:b2bb:8187 with SMTP id
 t14-20020a67a24e000000b00337b2bb8187mr4472776vsh.50.1653408467563; Tue, 24
 May 2022 09:07:47 -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, 24 May 2022 10:07:35 -0600
Message-ID: 
Subject: Re: [EXTERNAL] Re: unable to get virtual serial console for EFI
To: Souradeep Chakrabarti 
Cc: "freebsd-arm@freebsd.org" , Wei Hu 
Content-Type: multipart/alternative; boundary="000000000000627e6305dfc42800"
X-Rspamd-Queue-Id: 4L6zcm6YP8z3D42
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=DmWlBNlJ;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e35) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e35:from];
	 MLMMJ_DEST(0.00)[arm];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 9291
Lines: 264

--000000000000627e6305dfc42800
Content-Type: text/plain; charset="UTF-8"

On Tue, May 24, 2022, 9:53 AM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi Warner,
>
>
>
> The ConOut is :
>
>
>
> global NV,BS,RS ConOut =
> AcpiEx(VMBus,,)/VenHw(9B17E5A2-0891-42DD-B653-80B5C22809BA,02780ADA77E3AC4A8E770558EB1073F8C7E020566280CE4DAEB7520C7EF76171)
>
And what does dmesg say?

Warner


Regards,
>
> Souradeep
>
>
>
> *From:* Warner Losh 
> *Sent:* Tuesday, May 24, 2022 8:23 PM
> *To:* Souradeep Chakrabarti 
> *Cc:* arm@freebsd.org; Wei Hu 
> *Subject:* [EXTERNAL] Re: unable to get virtual serial console for EFI
>
>
>
> You don't often get email from imp@bsdimp.com. Learn why this is important
> 
>
> What does the ComOut variable say?
>
>
>
> Warner
>
>
>
>
>
> On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabarti <
> schakrabarti@microsoft.com> wrote:
>
> Hi,
>
> I am trying to get the virtual serial console to access via putty while
> booting FreeBSD 13 arm64 bootonly on Hyper-V.
>
>
>
> Setting console="efi" is not helping to have the virtual serial console
> access using putty for ARM64. It is before any kernel module loaded.
>
> I can get the loader output in vmconnect.exe but not in the putty.
>
>
>
> Though I can see VM is getting connected to Hyper-V virtual COM1 console.
> But no output is coming to putty.
>
>
>
> I have following question :
>
> Any specific support from EFI firmware, is required for virtual serial to
> work in EFI loader in this phase of loading?
>
>
>
> I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev
> variables.
>
>
>
> With set console="efi" or set console="comconsole,efi"  or set
> console="efi" , nothing in getting redirected in putty in arm64.
>
> But in X86 that is not the problem.
>
>
>
> Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite
> difficult. Any help or pointers are really appreciated.
>
>
>
> Regards,
>
> Souradeep
>
>
>
>

--000000000000627e6305dfc42800
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, May 24, 2022, 9:53 AM Souradeep Chakr=
abarti <schakrabarti@micro=
soft.com> wrote:











Hi Warner,


=C2=A0


The ConOut is :


=C2=A0


global NV,BS,RS ConOut =3D AcpiEx(VMBus,,)/Ven=
Hw(9B17E5A2-0891-42DD-B653-80B5C22809BA,02780ADA77E3AC4A8E770558EB1073F8C7E=
020566280CE4DAEB7520C7EF76171)
And what does dmesg say?

Warner=C2=A0




Regards,


Souradeep


=C2=A0






From: Warner Losh <imp@bsdimp.com>


Sent: Tuesday, May 24, 2022 8:23 PM

To: Souradeep Chakrabarti <schakrabarti@microsoft.com=
>

Cc: arm@freebsd.org; Wei Hu <weh@microsoft.com>

Subject: [EXTERNAL] Re: unable to get virtual serial console for EFI=







=C2=A0












You don't often get email from
imp@=
bsdimp.com. 
Learn why this is important
















What does the ComOut variable say? 



=C2=A0






Warner






=C2=A0






=C2=A0






On Mon, May 23, 2022 at 3:57 AM Souradeep Chakrabart=
i <schakrabarti@microsoft.com> wrote:










Hi,


I am trying to get the virtual serial console to acc=
ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.=



=C2=A0


=
Setting console=3D"efi" is not helping to have the virtual serial=
 console access using putty for ARM64. It is before any kernel module loade=
d.



=
I can get the loader output in vmconnect.exe but not in the putty.



=
=C2=A0


=
Though I can see VM is getting connected to Hyper-V virtual COM1 console. B=
ut no output is coming to putty.


=
=C2=A0


=
I have following question :


=
Any specific support from EFI firmware, is required for virtual serial to w=
ork in EFI loader in this phase of loading?


=
=C2=A0


=
I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var=
iables.


=
=C2=A0


=
With set console=3D"efi" or set console=3D"comconsole,efi&qu=
ot;=C2=A0 or set console=3D"efi" , nothing in getting redirected =
in putty in arm64.


=
But in X86 that is not the problem.


=
=C2=A0


=
Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di=
fficult. Any help or pointers are really appreciated.


=
=C2=A0


=
Regards,


=
Souradeep


=C2=A0



















--000000000000627e6305dfc42800--

From nobody Wed May 25 14:14:48 2022
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 C88301B4FB9F
	for ; Wed, 25 May 2022 14:15:00 +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 4L7Y430gb2z3pg9
	for ; Wed, 25 May 2022 14:14:59 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1653488090;
	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=L/eLWXYhUDVJlzqbHRNskhxnF1fXdd3ZE/VdvqMPgjs=;
	b=TPdKS2NRavXSlex7LKkHO72qyi8qx0XxMmbO8Cf39ZxtODC23g9Q2uWAELa8CIoe32p+ni
	Rw/KL9WT+JPYdPZ2jsxYdrblyEK6onz9OSnycDSXBjVzymptMirGQtMo4ek9Q55o7RrGAg
	msnBNRH2iIYjL0PxoG0ShQbBWMn3v7w=
Received: from amy (pop.92-184-104-26.mobile.abo.orange.fr [92.184.104.26])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 15c5a062 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Wed, 25 May 2022 14:14:50 +0000 (UTC)
Date: Wed, 25 May 2022 16:14:48 +0200
From: Emmanuel Vadot 
To: ticso@cicely.de
Cc: Bernd Walter , freebsd-arm@freebsd.org
Subject: Re: Only 400kHz on eMMC with Allwinner Pinebook on 13.1-RELEASE
Message-Id: <20220525161448.1010d6ddb78448676ca7cd34@bidouilliste.com>
In-Reply-To: 
References: 
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: 4L7Y430gb2z3pg9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=TPdKS2NR;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1067
Lines: 27

On Wed, 18 May 2022 20:39:30 +0200
Bernd Walter  wrote:

> I did a binary update from 13.0 with freebsd-update
> I did no U-Boot update however.
> Installing and booting kernel seemed to work, but it came up rather slow.
> And installing the userland took 6h.
> I have an internal eMMC and an additional uSD card.
> The uSD card worked fine and probes at 50MHz.
> The eMMC however is probed with 400kHz only and the pmc fails to attach.

 Are you sure that you didn't updated u-boot ?
 Because the PMIC error looks like it's still in i2c mode and not in
RSB mode.
 This was fixed in
https://cgit.freebsd.org/src/commit/sys/arm/allwinner/aw_rsb.c?id=12faeba9953ac7fa5198b258dcd80f89b3b4b947
but it seems that I forgot to MFC it so 13.1 doesn't have it.

 The eMMC problem is likely due to the PMIC problem (we can't switch
the car to an higher speed as we can't change the voltage).

 I'm travelling right now so can't test if applying this commit will
solve everything.

 Cheers,
-- 
Emmanuel Vadot  

From nobody Fri May 27 11:08:57 2022
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 B1A581B58E1B
	for ; Fri, 27 May 2022 11:09:17 +0000 (UTC)
	(envelope-from ticso@cicely7.cicely.de)
Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1])
	(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 "raven.bwct.de", Issuer "raven.bwct.de" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L8hrr5ZYKz4hcC
	for ; Fri, 27 May 2022 11:09:16 +0000 (UTC)
	(envelope-from ticso@cicely7.cicely.de)
Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c])
	by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 24RB9284052715
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Fri, 27 May 2022 13:09:05 +0200 (CEST)
	(envelope-from ticso@cicely7.cicely.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default;
	t=1653649745; bh=3gYtIfpmGjYpSffX2/tfZNK6qRw9kns0WXecdACeekc=;
	h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To;
	b=ZwO5eGKJ3ab3JwZw5S0m+h2XLZEiFKSV+MOKoRW9DECjlaDxrJKMWqSRlyEKfSeUI
	 4PiIUBNGJo4YcBnf6ztvIv60P8dxfC0zImjTfKDx/VQG14m96d4/mOeTWYeqqpb7bi
	 fA3G63ePTsIez5pqsM0cT1wI+73mEaJ/dgWv8bPw=
Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d])
	by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 24RB8wbR012968
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 27 May 2022 13:08:58 +0200 (CEST)
	(envelope-from ticso@cicely7.cicely.de)
Received: from cicely7.cicely.de (localhost [127.0.0.1])
	by cicely7.cicely.de (8.16.1/8.16.1) with ESMTP id 24RB8w6h016424;
	Fri, 27 May 2022 13:08:58 +0200 (CEST)
	(envelope-from ticso@cicely7.cicely.de)
Received: (from ticso@localhost)
	by cicely7.cicely.de (8.16.1/8.16.1/Submit) id 24RB8vII016422;
	Fri, 27 May 2022 13:08:57 +0200 (CEST)
	(envelope-from ticso)
Date: Fri, 27 May 2022 13:08:57 +0200
From: Bernd Walter 
To: Emmanuel Vadot 
Cc: ticso@cicely.de, Bernd Walter ,
        freebsd-arm@freebsd.org
Subject: Re: Only 400kHz on eMMC with Allwinner Pinebook on 13.1-RELEASE
Message-ID: 
Reply-To: ticso@cicely.de
References: 
 <20220525161448.1010d6ddb78448676ca7cd34@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=us-ascii
Content-Disposition: inline
In-Reply-To: <20220525161448.1010d6ddb78448676ca7cd34@bidouilliste.com>
X-Operating-System: FreeBSD cicely7.cicely.de 13.0-RELEASE-p8 amd64
X-Spam-Status: No, score=-1.5 required=4.5 tests=BAYES_00=-1.9,KHOP_HELO_FCRDNS=0.398,SPF_HELO_NONE=0.001,SPF_NONE=0.001 autolearn=no autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on spamd.cicely.de
X-Rspamd-Queue-Id: 4L8hrr5ZYKz4hcC
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cicely.de header.s=default header.b=ZwO5eGKJ;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of ticso@cicely7.cicely.de has no SPF policy when checking 2a02:21e0:16e0:fe::101:1) smtp.mailfrom=ticso@cicely7.cicely.de
X-Spamd-Result: default: False [-2.26 / 15.00];
	 HAS_REPLYTO(0.00)[ticso@cicely.de];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[cicely.de:s=default];
	 FREEFALL_USER(0.00)[ticso];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[cicely.de];
	 NEURAL_SPAM_SHORT(0.04)[0.044];
	 RCVD_COUNT_THREE(0.00)[4];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[cicely.de:+];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1639
Lines: 41

On Wed, May 25, 2022 at 04:14:48PM +0200, Emmanuel Vadot wrote:
> On Wed, 18 May 2022 20:39:30 +0200
> Bernd Walter  wrote:
> 
> > I did a binary update from 13.0 with freebsd-update
> > I did no U-Boot update however.
> > Installing and booting kernel seemed to work, but it came up rather slow.
> > And installing the userland took 6h.
> > I have an internal eMMC and an additional uSD card.
> > The uSD card worked fine and probes at 50MHz.
> > The eMMC however is probed with 400kHz only and the pmc fails to attach.
> 
>  Are you sure that you didn't updated u-boot ?

I don't know when I did the last u-boot update.
At least I kept it when updating from 13.0 p-something to 13.1.
However, in the meantime I did an update (with the arm64 package content)
and now the screen stays black.
Not sure when I will find time to investigate.
At least I'm happy that I didn't update one of my Pine64 first.

>  Because the PMIC error looks like it's still in i2c mode and not in
> RSB mode.
>  This was fixed in
> https://cgit.freebsd.org/src/commit/sys/arm/allwinner/aw_rsb.c?id=12faeba9953ac7fa5198b258dcd80f89b3b4b947
> but it seems that I forgot to MFC it so 13.1 doesn't have it.
> 
>  The eMMC problem is likely due to the PMIC problem (we can't switch
> the car to an higher speed as we can't change the voltage).
> 
>  I'm travelling right now so can't test if applying this commit will
> solve everything.
> 
>  Cheers,
> -- 
> Emmanuel Vadot  
> 

-- 
B.Walter  https://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

From nobody Sun May 29 21:00:58 2022
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 D70E51B48782
	for ; Sun, 29 May 2022 21:01:01 +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 4LB9th5g4Wz3Dd2
	for ; Sun, 29 May 2022 21:01:00 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 033A91E68
	for ; Sun, 29 May 2022 21:00:59 +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 24TL0wtQ002905
	for ; Sun, 29 May 2022 21:00:58 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 24TL0wwW002904
	for freebsd-arm@FreeBSD.org; Sun, 29 May 2022 21:00:58 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202205292100.24TL0wwW002904@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, 29 May 2022 21:00:58 +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="16538580588.0f9DeA.97661"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1653858061;
	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=enVJUMbUXRPyARCae4TJN/YnruVBwtcXyMfKr8fO3Fs=;
	b=MfE88iCivLG0HoF4uwSfPKmWDeSDqZ6+E06ltC4cYWAbfiqxhpGI9VnbJBb13+3SXs/xuV
	5tfHW4LhDLd573+EatOzll2tztxX0nyv0dKVY41IVfM1qczsHc/oC8h2QTEfIWCZn8LHCK
	p54iVdi0rhlZjz+8n/SzxKLaN5pB2ZNjWotXuzNRZZmHbYQaDot2bKzGCWibmMMfVwUVb5
	ARlTbKJN0JEi8D6DMd2vYDTV8V9YXAeYsOnnmSS+Mf++89nTkNoIVuIVKtPm/imGCeOAuY
	xIkhPOcQHdKYuGH+Bjtr5Xuzogcm+zLOM+VOD1wbDXOdBZTxZwOfNrKwBeXDtw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653858061; a=rsa-sha256; cv=none;
	b=sTK1ghMQP8hF3wUN1BasXYChX/U5k0hFu9DOg5NoBF54xX0V17l0uvpm8Hz18x2OxV5WLn
	gGF8C5XHJM36TYXUzSfqEt6kwXWXqGKuAgvvf25tx/4QHyvoL80Y+0EWALi5xczlpLmYSU
	CeaGTbY6uoXWkOi/GRunYyPN/zXcSNK7KT7GP5xtP5x9kgXmoQqsODkwTMG5JRksriHbJs
	yzQfnsCeB2WDnTKS+x3CtgnG9d9JYeEdBD+/scBDFihcHtH+tB8l+jg0WE15LAgtWjdlX0
	nJ+E4t2FgenTIK8J7i81eGASbnDaddhYSQGSgov8W5BjHwwUApOnU6Vl1g171g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1801
Lines: 38


--16538580588.0f9DeA.97661
Date: Sun, 29 May 2022 21:00:58 +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.

--16538580588.0f9DeA.97661
Date: Sun, 29 May 2022 21:00:58 +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.


--16538580588.0f9DeA.97661--

From nobody Mon May 30 09:30:43 2022
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 C18F61B578DC
	for ; Mon, 30 May 2022 09:30:54 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2133.outbound.protection.outlook.com [40.107.255.133])
	(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 4LBVWx4kzHz4f3S;
	Mon, 30 May 2022 09:30:53 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=dBnQ+ZS5z9gOD/4zXOPqb6W38yQFb+qajz1YYZWfHrLal7gZr8dnCuJ5SlmcRLseXnxYlw1uzAmzEdX0x2SjmufHyy+iUwTf3TOvCqgniYswbb/oF/iA6rDqkfP72TITpwmEy2jjzZy4HySDb6uYIRLuxYUO4ph3b+jnz3vArACv94zzSSAre81xT6y/4dPn7uSnWCGUVzLXRM0rnblpntdENQk5S96rRaux714KM0BRO6NvCm59GRvSzzU3NsW66+bg6JmQ5CgDGA1lMPJItpengPrhpn6mNWS3JPgUMfWLnPEenZuMN5KduGjO9hvDHA2Ktr7kDGAU3ye99iLjLA==
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=6wT88MKKic4Y3AURnrHmUITwDP9srEXkSWeMkTDXRcQ=;
 b=auXR2B88l1q3fQHMeAW0BPEGO/PFwnNDWR4JViLNkx7pJUWsAxVEQByFhfgbinJ5WIAllCz8QZm/FxqurQAjjw72WRBeB7SLDkijGj5YcinmRLK0hAjqBKMbz9e321Oc5LyW+U24wF/1rKmkok7b3nbppItxmX0cexbEv3RYLVJpmojyw6+8wC+biRHpt8EX7C+DqHdhzdiXngZYdOdMybOn5gRY1t+AWiZtyOEtH1mRkC5R0Otn9pCIO5tNjosM6lIt1bAXWHsdQVns2DwB8dTYHUT2h/M6QcebraX3zxyatedgL1Aj4+Ca2A7xuAorLuIiUb02qzHLS2WSfBmopg==
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=6wT88MKKic4Y3AURnrHmUITwDP9srEXkSWeMkTDXRcQ=;
 b=M/IATXyNOt9oceJAS6PU4o6vnH7kOsbaSTwmu+g8nA18pDtoC18L65fp5EPhErt/qmh5hlJhLc6qcB2zzbl07diwXg9s59iBSRMpOvppIjbIScPnxU7+pJp/O0Y/4s6dzoRi/MZt8JLRMRRbNRC77BoRxJZ37TKZZSUDJY1O3V8=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PSAP153MB0440.APCP153.PROD.OUTLOOK.COM (2603:1096:301:35::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.1; Mon, 30 May
 2022 09:30:44 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826%6]) with mapi id 15.20.5332.001; Mon, 30 May 2022
 09:30:44 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	
CC: Wei Hu 
Subject: serial console and comconsole in FreeBSD arm64
Thread-Topic: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQ==
Date: Mon, 30 May 2022 09:30:43 +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=ac0429d8-4397-474c-ac20-458e25c347e8;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=2022-05-30T09:20:04Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8309434c-e038-4b18-4c9f-08da421f11ff
x-ms-traffictypediagnostic: PSAP153MB0440:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 4tBrSVV6nlzINm85grKdMJnLtGEoL+l4qPlq2drA7uuU8QKiNFIGQ5AEpjje5i/35deI/k3sDGLKkqTcmQSTp1HnpNyBp9W/HViuaJaQDXJW3kCKo+etqry77aURfQEy6+Ui1Ml6t70IONseXj/DYU+09g6JRX8CtU59EvxRaQi2Yp/YzojC3/LBhF7ZRMGQmkSpdU19TukmwRIX3VZsw0gMBGYPwkUsiYlTa+KTupU4YITI8fIdnjytdOwxC6HscWCNXxZ7bHWekp/Ixl68L8cIOz7JfJVJCHgqOMfWDXRoNJdVBiY2/mhZHO02MIEPDvkof4lH065W/qXZ7zV+uQB8gZz5+/DqUfVbz4uXkof5xQwshlbL5IUKlXlKvfSmasS4AZxzRrs9md8hHJjCnIisyFmm+Ml5gjH/ZAmffq18wpM54rOH9x8dBwrDnpGxy0EQqxQtzcrkVKA2MjxglSGJirjkKgkC9rF6v9MG5ENPGHE7sYiDYx908HR04hilsLkItFYVG6U3anUJiZTCQxkTYNpXSStzdci2t1ZNmTe5Xwzauu3pp2eA2Nbyu/jZxfqJuY3ubi7oBuqlxNrYjmRHIqjLaloc2pLf5de3pkXwW5rkIW7a+5wUzaR7wxWj5hkGhz5RTJLNrvoJYVVXjVWTsscUbOacXehg8v4svEU9uG7Th2JW9ny8c/TKX4t8fRzjRNUH3MdyWQ5kCikA2x/JVBc61tTNg0CtpkhnqJDwfKB1sEp6e8phUPEsdShF0T3yEhnjmR0RyZo7sDhXeZi/n7oAUwQcQIUrC1Un0As=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(83380400001)(4326008)(110136005)(107886003)(38100700002)(186003)(66476007)(76116006)(64756008)(66446008)(66556008)(316002)(82960400001)(38070700005)(82950400001)(66946007)(8676002)(10290500003)(450100002)(9326002)(52536014)(2906002)(86362001)(8990500004)(9686003)(33656002)(508600001)(8936002)(6506007)(7696005)(5660300002)(122000001)(26005)(71200400001)(55016003)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?xKgAGSEtJitdjtAHKStEI6FrQf5ZEMM4Ef+ywdbQoZkvH+1GUy/hdaDxsJBJ?=
 =?us-ascii?Q?b9Qtf9hHrRzPx1qMr233NkVlj0EZh1aM94HYZ1hf19Q7N/iyrTyd9tg1Q37s?=
 =?us-ascii?Q?bWHArlklX83CQoHj5i1c6oXXVrvy+26Z0ktRE/TipWVL4AqqO+JiDoI+QtqD?=
 =?us-ascii?Q?u9rFsGZjKc6rnxXWnuj1RvhVWWegTuyrly2K7xxXa4h3x5lgbG3mtLA5iEFv?=
 =?us-ascii?Q?Sq1Pa7x5K/9iwMIuNwm8yhRljrhejpFHoN6XqeHlGmDEBtGcUYsFfCrXGh2J?=
 =?us-ascii?Q?IH5VNzBTuZwmYdptk6YiN6GmOOPXCjit+fCTf/5gOskuLARAg/EbtsYujsVj?=
 =?us-ascii?Q?7BALjqP/GbjJZdcgBweum2EVw6om97HXump5QiFlvhJ/U+QbVo3ui3F5Wi4m?=
 =?us-ascii?Q?t2/MKZvlACEU/VUwNxqSCf3s692i5eUlGbxS78u0EPLCBYU4rkwv4OudgyS9?=
 =?us-ascii?Q?g+u6Y8qtMf/eCsalJuW5M/5ffkcksT+/F2kPrFHhc8QEsssrxogNDwFsPuxQ?=
 =?us-ascii?Q?W6Fp6htXzbl4hJ6ebE3vfYfzFlHNcClXAGo24mryGL8/Kh0SSNzpmXK7+r4Z?=
 =?us-ascii?Q?da9vy/ifIkWYjc0tr9r+cIWNRSL9/kpMNEUpAqR+evtHJkKo0UXksxu1QrwO?=
 =?us-ascii?Q?eDoU9/zMO8XqMi6u2Uftstx+sfbVE1rzIhep5D/RDy26nydkQVKKlkyo29nu?=
 =?us-ascii?Q?H0xxJJp9I8eV5ATxCoLRcYgn77uWFJD+wHgjkifEAP8GnWeOJNpNbZ6+BMJi?=
 =?us-ascii?Q?FFkyELfLThJeY6b/Q64AuWgrQ3XHLdWpZO4vgiDlslXkjXtUtVFqJB/bDM0H?=
 =?us-ascii?Q?Tw5ByjGrrVDDtrfEOk9ZP8/EhSsf+iBVI6mXjnIWElnGp/SMa4vgvLsrNuJi?=
 =?us-ascii?Q?BK6q6b4jkjQ9VRsUW2Has92eQz5hgQzoKb9X60C9am+MxawAuMA5hTIDJuGg?=
 =?us-ascii?Q?MQBcOb3j9po1l956MAq+rmu+5uZU6pa/XYQaJMUyqLWtr7G3AQ9pRxck+3vd?=
 =?us-ascii?Q?RaBzEQpNp2YaY41hhjXjmrxghWE73IB+bIbIGENl9yhkpyeb+z3+3uoL3S3u?=
 =?us-ascii?Q?W+FYnkrXoByfAd+zWSw0oaeV/TuJU88YKe9R+kIX4lW5F4EPHWms8+kECbGJ?=
 =?us-ascii?Q?epvNXsc/82s/6197uaJo71ljBJ4x1zvSU0q4UgI07a3I2PBe1X7+YhKhgSsX?=
 =?us-ascii?Q?eFTAEqlAjHmNXbA8Mv6mrJoFleBMtjPladEBsczVZ0+P3bE/E5baGyy6EVOt?=
 =?us-ascii?Q?r4yNAqScmGyW+DfKWtWdqDpuD3Hr6bdzsX+ZzWEmKpgOBGsaqYlvh9e/jz6t?=
 =?us-ascii?Q?UmU+2fHRBi4jr6liRMv2EU9315uJQoUL2jlnbJvrl94V20+aTkJn9gDHM5l9?=
 =?us-ascii?Q?h01OdzMANCoPahbTmz48stYB5bv2rWu4TkJHVJ1YvwGEUnpbL9aBToyDSfeV?=
 =?us-ascii?Q?u2j1hzEjLnBBzLvT/0FH0ufKW+62tWgDr5bno+/R7Fm0W9XVMqJezlw33jRh?=
 =?us-ascii?Q?HWzTWmeyNMKzzMRWF21ECCGQzxtO+6FKoF51WWv9YfFVs7pWf4nZ0eiiTbHw?=
 =?us-ascii?Q?1jNOV9nQqZ8M6aLxuzaLvDBg1WLMd71sIN9Hq8bTNfu/vf9Ooe+a7JaBtaXF?=
 =?us-ascii?Q?Wz6yRvNAqxurNmcFDfuQ6tsKQwKeLyxZq+mkS4//D8xtkysnwl65hMwq0Wyf?=
 =?us-ascii?Q?7UZHMcAnnpdAJTD41K9sQVkO7rw=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB05367C6802D76EC6BA352431CCDD9PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 8309434c-e038-4b18-4c9f-08da421f11ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2022 09:30:43.9084
 (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: LS4F5uuJfzoK44dTDTrOwFBF/K6bAdvb/lh/5adC29HDLA0As/wVayF7FU0/lqaz6Bf7KONX3Wbds3aFq9k+24sEfnADbrebK+YH5auN7kw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0440
X-Rspamd-Queue-Id: 4LBVWx4kzHz4f3S
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="M/IATXyN";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.133 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.133:from];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.133:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7044
Lines: 205

--_000_PSAP153MB05367C6802D76EC6BA352431CCDD9PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to access virtual serial console via Putty and in 13.0 it is no=
t working
for both x86 and arm64.



It is very easy to reproduce:

1) In Windows Hyper-V set a  FreeBSD 13.0 VM

2) Use Powershell in Admin privileged mode and run following:

                Set-VMComPort -VMName  -number 1 -path \\.\pipe\Te=
stpipe

2) In another Powershell with Admin privilege run following:

                Set-VMFirmware -VMName   --ConsoleMode COM1

3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial mode.

No output will be seen on putty.



But the same works in FreeBSD 12.3 and Putty gets the output from EFI loade=
r for both x86 and arm64.

But during kernel booting the console output does not come in Putty, it onl=
y comes in vmconnect.exe.

Like below :



Loading kernel...

/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e sym=
s=3D[0x8+0x138120+0x8+0x124824]

Loading configured modules...

can't find '/boot/entropy'

can't find '/etc/hostid'

No valid device tree blob found!

WARNING! Trying to fire up the kernel, but no device tree blob found!

EFI framebuffer information:

addr, size     0xe0000000, 0x800000

dimensions     1024 x 768

stride         1024

masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<



After this log is not coming in Putty in 12.3 for both x86 and arm64.






--_000_PSAP153MB05367C6802D76EC6BA352431CCDD9PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I am trying to access virtual serial console via Put=
ty and in 13.0 it is not working



for both x86 and arm64.


 


It is very easy to reproduce:


1) In Windows Hyper-V set a  FreeBSD 13.0 VM=



2) Use Powershell in Admin privileged mode and ru=
n following:


        &=
nbsp;       Set-VMComPort -VMName <vm_name=
> -number 1 -path
\\.\pipe\Testpipe


2) In another Powershell with Admin privilege run=
 following:


        &=
nbsp;       Set-VMFirmware -VMName <VM nam=
e>  --ConsoleMode COM1


3) start the VM and open putty to connect the 
\\.\pipe\Testpipe in serial mode.


No output will be seen on putty.


 


But the same works in FreeBSD 12.3 and Putty gets=
 the output from EFI loader for both x86 and arm64.


But during kernel booting the console output does=
 not come in Putty, it only comes in vmconnect.exe.



Like below :


 


Loading kernel...


/boot/kernel/kernel text=3D0x931f24 data=3D0x1874=
50 data=3D0x0+0x2d095e syms=3D[0x8+0x138120+0x8+0x124824]


Loading configured modules...


can't find '/boot/entropy'


can't find '/etc/hostid'


No valid device tree blob found!


WARNING! Trying to fire up the kernel, but no dev=
ice tree blob found!


EFI framebuffer information:


addr, size     0xe0000000, 0x=
800000


dimensions     1024 x 768


stride       &=
nbsp; 1024


masks       &n=
bsp;  0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<<=
o:p>


 


After this log is not coming in Putty in 12.3 for=
 both x86 and arm64.


 


 




 






--_000_PSAP153MB05367C6802D76EC6BA352431CCDD9PSAP153MB0536APCP_--

From nobody Mon May 30 09:31:29 2022
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 396381B58280
	for ; Mon, 30 May 2022 09:31:38 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2131.outbound.protection.outlook.com [40.107.255.131])
	(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 4LBVXn2TZyz4flq;
	Mon, 30 May 2022 09:31:37 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=FICx/Qnw/U1DLV/mQux33tuW9q10chgRtzekqZeKCtlPWraW8kkThGu2h6seZBNuL/2Q7IDzBdOs0xsqGniXxtNzV7+/tIjujd+xx01+m6I58SkxepNtGvFAJ1TeA7wPU1eZuNLe4+7X1lb4s1S8XqV6JwN9q/R5slTiZDJOjeaHD7wHyGMxKtuM2RkJ7QDpKbYyKKWfzNjcPEuj4EDwYjEbfadoKy+I5su/wEXfDR/wdY9ZTnkJYFpXFsJAIQwibmPM6POEQVQZWYWEb53aaabUE30DTVT044p+e5tPMerPOOzZmj4/zIWwR83wEWmUbIqtkMhnLEmf6FYpE4fOIw==
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=D5zNidKRkI+jAnXSRd5VFaS9aW8X93+mO/qpNhEjGpU=;
 b=ZBLsAjOHGbBuEGPAS3FJec6N7irF6q7HUEBNohjBm8Ff164NkgvgFVUCZLpB9MuWj2VEoHE/cEaa4JQFvpn7+qeeWGbLZiAOwMhaYFeHCT7M+PZ2NHH8ULWD23XiqWgAbTYOhRBYk34WmeNERwZZGuIZNDN8R1+NgWxkKiXK4cEwUSfw3ZZO1r7pt0ApwnU7OQsA4IFy68i8jhiBM4CeldUAxY8HQ4pKRe8G0DEbpxib90Rvvo2vrwWSZ48NsXMRCIMPPFwxNfG4cz2TyJ9S/DJN74czs9cFC1nMOPdfoE4sJXsk8T8FRVvXLtbarRmoFnd8Gp995pufqQRpCbuAMg==
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=D5zNidKRkI+jAnXSRd5VFaS9aW8X93+mO/qpNhEjGpU=;
 b=d+ARuWx5Dcx/YZGW9MVX6D13VhdQKHeQxuBKsi5t8M+vO4ffuQPXYknETLgurVaXH9SzSAj5PwR5PE/ipm2bvCdbvK9X8/wcRp+4rlDh9/H8OX4SaWF/fCtBu+2+SE8H23AFrkJp7Bo8nVwiSddhmitLSfVYxzSSLq8Fi00ZuQs=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PSAP153MB0440.APCP153.PROD.OUTLOOK.COM (2603:1096:301:35::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.1; Mon, 30 May
 2022 09:31:29 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826%6]) with mapi id 15.20.5332.001; Mon, 30 May 2022
 09:31:29 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	
CC: Wei Hu 
Subject: serial console and comconsole in FreeBSD arm64
Thread-Topic: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQAASE4A
Date: Mon, 30 May 2022 09:31:29 +0000
Message-ID:
 
References:
 
In-Reply-To:
 
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=ac0429d8-4397-474c-ac20-458e25c347e8;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=2022-05-30T09:20:04Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2eb0fe9a-9229-4a7b-d2ea-08da421f2ce2
x-ms-traffictypediagnostic: PSAP153MB0440:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 /BsoobyWtGSz3HOA3pFO70yDvF3An8hu8dFTGHXqPNQg8NuGufO69mpDV26IMOP0DIctfNOpZiyysMeBnz+Iu3YaTeBhtiLB8uzEoQ9AyEPlj9S9ZDNffmyapyuVPQH1RtuazDUHO1UHLYTTClrHsMp/vbkMveT5YLODoG8oCd5WXuYq1Tq6Ouh76jWKLjZ5OBRlM+v797esdb5nCSDp7JaLNPvo67+S7+hhhnJ7U+8yAEl+VX7NnNpZhAbAevOtMLFvee+8tSupi6eaWi2tnRlheWVHrz63VU7iYfxrBUZ5J8wMuLTip8D5/j/DBDE9wru856JOB/TgfAcabhtBt41nEJaZC6uIYgkoW+1UZw8wTLBYGGeW/Mldwu8iZ3p8ruKS7+ydMWYF4kqPU3oiUX6PHvwmmRUr7cCdT/9zDW8KBbb3Z6n5vMwt1gKqrMikCZyR5vJkPrfKB9IY9JfOxUzP8/bXpxAULB1SeSNmNqTTvG+jCF9Zdq2QFYTYG/Ve2oBwy7AIu86J8ozDpDoruImdWkO1JCiMNmue7hWIZJPFvyXn5bciFqLeiU9o6yqn79oBjq44QAKfTTiYVdzitymnc5LBz316pOFQr49CTPc62agRZI12kJFRxT31F9DL+LfGCmrMZnjp7TiN+wTJ05CZHSLMFpRe+3rEGrMvGRIFuHRixc4GpzzEOThkojRglPr3BVtMyeSreoyFxeV7CYlDVixlnv9cHJ6kCJJzwNRuOlzYy8kp3cikh1T7ss0myIw+0FMEOz+LObFl3b0I4PJvTHifb64RImxT4LFX4eU=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(83380400001)(4326008)(110136005)(107886003)(38100700002)(186003)(66476007)(76116006)(64756008)(66446008)(66556008)(316002)(82960400001)(38070700005)(82950400001)(66946007)(8676002)(10290500003)(450100002)(9326002)(52536014)(2906002)(86362001)(2940100002)(8990500004)(9686003)(33656002)(508600001)(8936002)(6506007)(7696005)(5660300002)(122000001)(26005)(71200400001)(55016003)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?LM0zmluLKy5t1K6Y79f+Xz979ZEZGy+wXbMtVARv0y9LbEDy/br2SYuaT6sl?=
 =?us-ascii?Q?Jqxl6kTJXWojMfTPJ3VDbI8zsgtjNWDq7fqmO0deb+AaBqiOzgFPGeTsYlQG?=
 =?us-ascii?Q?pJ4NBx33a9eG9EZ+eyYtshdZ2QEfK5z4Mg1DSWwmOdM9C5ijN0yQOh2tL/pg?=
 =?us-ascii?Q?+fHMMXJe3AZ4JDAW8y4w5KkaXJvHK2t7Z1RcYTMytHajUYQeB5asQiFaKmIa?=
 =?us-ascii?Q?hN4Mz9mJ3An8ZvHO2M43l2RMg/aKh6uJ/xi/4ncl9bIeaOdpoZAOzyGfrz6G?=
 =?us-ascii?Q?mVn5nkMDrPdSN1bW8+15WF5dWQoSWtMipdd5MgDHsO2UdFhBlAOg46P2zdM1?=
 =?us-ascii?Q?sIHSgh0JFhNZR+qN+MWncKSL45QDlKccnioKE0Z8EnJ0kWoVHzjd6hE5DjPn?=
 =?us-ascii?Q?rCcVikXbXluw9VQ+3ssFDsKzvCh5MikJ1x8Pl3/G27RYtJD4jpxXHce7WKu+?=
 =?us-ascii?Q?dgNeJkhbAJpS/aijObo1Bqd2sE5SuNxypntaY81un7i76Jij7MuP7J2J/qXW?=
 =?us-ascii?Q?X2Uy7Vmf6SDJzBmFzKMI2WSQezP4nyrwYlEqov/d/NDfS0BbixLQjHib0TeK?=
 =?us-ascii?Q?IhYcrG+tvboDISqIvXUme1F/pV8YsIyW2REzDgiU9uMh816i2qEE2IcQ4Atk?=
 =?us-ascii?Q?woVaGy9XPgMVKTU1hRqM8xYeLmNJk+r1ZElsjiMQCoga1uH8XfVpDVuQCMiM?=
 =?us-ascii?Q?+gT2fS0SwAa5odj9Tz/U/sdDfNQk4K1s2GyyHviFXd7FGTJxfNMNFJ1Fg4eX?=
 =?us-ascii?Q?zfmKl/cB66XzW8DBL9m63naXNdV3AVimJTfi+TH2yh5IyRfCnIgzIlKyxFMi?=
 =?us-ascii?Q?Olc/tTg/l1BKrezfd0xbRHDQHh+Qx0IupW99GhGl/GG/u8xmrcMVoojumJMt?=
 =?us-ascii?Q?ZAt6sI91ifXo0Hr5+jAlqzpu285ADRo0xbol3/NCnnB0GJDJHbt9u4rVPE7F?=
 =?us-ascii?Q?chPjsDypmDyV1k9pDmTv3wDcFPAb2Z2kEoEm9b/hBJeA1OkF0M2x/zWf/ftL?=
 =?us-ascii?Q?Rce0pkzQpCw1gOUBH7Bkn0j5aIqNQ6I+R18+QamSn8kCBojbhXOI78kBKCSy?=
 =?us-ascii?Q?wqoVTdQlYxi/MB6R3l2bkJr56UntjAinLfEGTBQBxZz7qRlmuHHT69HXWvoY?=
 =?us-ascii?Q?KDkFPzVaAZ8kk7V0MlbFu/WCWWD9ezlZy1fvui1ebkVQ0AfQmv1vBmFQuZew?=
 =?us-ascii?Q?qMaUocAkL4tnmfk45XsW4DOK5/3ejKQM0owlQoRjpAwYWPnrk4Wxmh/y1YBl?=
 =?us-ascii?Q?IYCqxldHFjG0Qj8AMHUcp89g+5/WDHnaqjLtX9DyIvt3Jc8E4G6oCUJYS2l9?=
 =?us-ascii?Q?islDnKiGAdImoWqBJwH22DSaClros1xhIrzh6CijlhzUA9M6lfyO29K7xg0T?=
 =?us-ascii?Q?6h5NPzWh9E3JRAsawLPhDkQ5nz9M4vURpW89hJoCwHl3CCAIHOL+K2SYqrDp?=
 =?us-ascii?Q?hShRGNKryMEURiVMwm4hVxVscQFCGkf2Lg7CsN4+WvrKPi74Dw4pzZI6Z37A?=
 =?us-ascii?Q?HDQkWdf96mmuPsi1BzccAIuSijLLz66ytGzHHEnGqaiCpyzXKqWjEamPB4o/?=
 =?us-ascii?Q?bdwcwOB58cXvGSKnUBTwlH/j+gfpS+BP9kJ3Lrn035Ili/q3t+7BhmDzzWfE?=
 =?us-ascii?Q?wrBlYP534P4MShBMHvf6W9isz/MCW81Lky8EW1cHCqm0KwZXH87ODTTRv4pw?=
 =?us-ascii?Q?EDTz60izP5PwbUaW9EtCIldUTSE=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB05368451926D7372E9B44EC3CCDD9PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 2eb0fe9a-9229-4a7b-d2ea-08da421f2ce2
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2022 09:31:29.0672
 (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: aRYbCSipxHmdhUAcvY1ORO1FMM2fHINTPJcUdbI2Qqih6LK3xc8LSuKlNWH0Gjl/B4B8qnX2x/G4U5w8RatNXClxhKcMPrRlVotFCDBOASQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0440
X-Rspamd-Queue-Id: 4LBVXn2TZyz4flq
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=d+ARuWx5;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.131 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.131:from];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.131:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7077
Lines: 209

--_000_PSAP153MB05368451926D7372E9B44EC3CCDD9PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am trying to access virtual serial console via Putty and in 13.0 it is no=
t working
for both x86 and arm64.



It is very easy to reproduce:

1) In Windows Hyper-V set a  FreeBSD 13.0 VM

2) Use Powershell in Admin privileged mode and run following:

                Set-VMComPort -VMName  -number 1 -path \\.\pipe\Te=
stpipe

2) In another Powershell with Admin privilege run following:

                Set-VMFirmware -VMName   --ConsoleMode COM1

3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial mode.

No output will be seen on putty.



But the same works in FreeBSD 12.3 and Putty gets the output from EFI loade=
r for both x86 and arm64.

But during kernel booting the console output does not come in Putty, it onl=
y comes in vmconnect.exe.

Like below :



Loading kernel...

/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e sym=
s=3D[0x8+0x138120+0x8+0x124824]

Loading configured modules...

can't find '/boot/entropy'

can't find '/etc/hostid'

No valid device tree blob found!

WARNING! Trying to fire up the kernel, but no device tree blob found!

EFI framebuffer information:

addr, size     0xe0000000, 0x800000

dimensions     1024 x 768

stride         1024

masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<



After this log is not coming in Putty in 12.3 for both x86 and arm64.





Regards,

Souradeep


--_000_PSAP153MB05368451926D7372E9B44EC3CCDD9PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I am trying to access virtual serial console via Put=
ty and in 13.0 it is not working



for both x86 and arm64.


 


It is very easy to reproduce:


1) In Windows Hyper-V set a  FreeBSD 13.0 VM=



2) Use Powershell in Admin privileged mode and ru=
n following:


        &=
nbsp;       Set-VMComPort -VMName <vm_name=
> -number 1 -path
\\.\pipe\Testpipe


2) In another Powershell with Admin privilege run=
 following:


        &=
nbsp;       Set-VMFirmware -VMName <VM nam=
e>  --ConsoleMode COM1


3) start the VM and open putty to connect the 
\\.\pipe\Testpipe in serial mode.


No output will be seen on putty.


 


But the same works in FreeBSD 12.3 and Putty gets=
 the output from EFI loader for both x86 and arm64.


But during kernel booting the console output does=
 not come in Putty, it only comes in vmconnect.exe.



Like below :


 


Loading kernel...


/boot/kernel/kernel text=3D0x931f24 data=3D0x1874=
50 data=3D0x0+0x2d095e syms=3D[0x8+0x138120+0x8+0x124824]


Loading configured modules...


can't find '/boot/entropy'


can't find '/etc/hostid'


No valid device tree blob found!


WARNING! Trying to fire up the kernel, but no dev=
ice tree blob found!


EFI framebuffer information:


addr, size     0xe0000000, 0x=
800000


dimensions     1024 x 768


stride       &=
nbsp; 1024


masks       &n=
bsp;  0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<<=
o:p>


 


After this log is not coming in Putty in 12.3 for=
 both x86 and arm64.


 


 


Regards,


Souradeep


 






--_000_PSAP153MB05368451926D7372E9B44EC3CCDD9PSAP153MB0536APCP_--

From nobody Mon May 30 13:59:58 2022
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 EFDD81B51EFA
	for ; Mon, 30 May 2022 14:00:10 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934])
	(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 4LBcVd6Fkgz3kk6
	for ; Mon, 30 May 2022 14:00:09 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x934.google.com with SMTP id 90so3844170uam.8
        for ; Mon, 30 May 2022 07:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=48d6Co8mGoWYlNoakaMKZdHRZ1HTejHCLw0hHlG+gHo=;
        b=TKOd3ih1cwAJ10qg7ZxKWqGM6OMk5TMAt7WICZEcOWT7LLPS4uCLWG7sPbm7JqdZOy
         7IANkxGNgps3UaIPjt0p6YBs72j+ZjqQhYOlnWqqc3W/omKCH8RscrPDIC13YEZQJw1r
         6d9w7LVrd8Ydkpawf9c+FlLCm+Z6JX24+A2/tZAOOmRRrSzPs2j+aJCESXmf/vwqON1V
         Hk8wGVujoKqMjBVpCrg7t9rvtrOYhHCDFky55CuiH04rCOh1JWXz16HmVu6Eer5g68h3
         rTc+cgflHlPZc1geAik2x4R/rnqglw/5X8od5BMHaEIGuQmK/yUn7NVUOsr5s6ZXhEdC
         VXNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=48d6Co8mGoWYlNoakaMKZdHRZ1HTejHCLw0hHlG+gHo=;
        b=r6Jpo06ebsTDRwOPcS2dAOv0z08KwAkBltan82KYiINjG+Q8fB6GLxZmS4i5UJ72ey
         nnQqCpUGE0fFTuoH5GrQ1FfaXh8tN0M6XzH5LQj8Ve0gPGtqFtOYl9591nADmmqj5L9a
         e62zJgLdlYQ4icTBvwsikX9KHj4lM6zFJHbIT5zfxHNR9Wln3s6n+i54cpkHU4ODqxe7
         i8+p9y4lAjgm58w+dLflnMrdSV8K4aLB2nnUaan1U/SpOFbN256cL10zUExOT0QC7Y46
         MI3JJFVFyZVJR9xL6VI8ebZnhCVY9UuRulAHZHe7LhKdvh3shWjA5cT7T+Y9v2PsLp1i
         c27Q==
X-Gm-Message-State: AOAM531ZFI0ad4Q6pjpZQRt+mluS54B+Z9QVSJI66DHL02gU67EygYpy
	e+y4laG/ElrGCNr/9nNCZZ3dYV5mFKy46IwmMEN6pA==
X-Google-Smtp-Source: ABdhPJzdz5C4Wp97HRCpdUugx7ok3hBuscDw+YHtl6FCQo0MkVcaWJwTrxCnVUdUwW1vtb/H7r34zpX5qCR6j7GDryw=
X-Received: by 2002:a9f:3109:0:b0:368:c346:6203 with SMTP id
 m9-20020a9f3109000000b00368c3466203mr19317926uab.28.1653919209224; Mon, 30
 May 2022 07:00:09 -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: Mon, 30 May 2022 07:59:58 -0600
Message-ID: 
Subject: Re: serial console and comconsole in FreeBSD arm64
To: Souradeep Chakrabarti 
Cc: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org" , 
	Wei Hu 
Content-Type: multipart/alternative; boundary="000000000000f40f0205e03b12ac"
X-Rspamd-Queue-Id: 4LBcVd6Fkgz3kk6
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=TKOd3ih1;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::934) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7093
Lines: 197

--000000000000f40f0205e03b12ac
Content-Type: text/plain; charset="UTF-8"

On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi,
>
>
>
> I am trying to access virtual serial console via Putty and in 13.0 it is
> not working
>
> for both x86 and arm64.
>
>
>
> It is very easy to reproduce:
>
> 1) In Windows Hyper-V set a  FreeBSD 13.0 VM
>
> 2) Use Powershell in Admin privileged mode and run following:
>
>                 Set-VMComPort -VMName  -number 1 -path
> \\.\pipe\Testpipe
>
> 2) In another Powershell with Admin privilege run following:
>
>                 Set-VMFirmware -VMName   --ConsoleMode COM1
>
> 3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial
> mode.
>
> No output will be seen on putty.
>
Not even from the boot loader? That sure sounds like the automatic fallback
to simple text output isn't happening.

What does:
% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
tell you? (Or run as root if you don't like sudo).

The boot loader grew a non-optional graphics mode that's disabled when the
boot code
detects we're talking to a 'serial port' between 12.x and 13.x. If you are
getting no output
from the loader at all, I suspect this is likely to blame.

> But the same works in FreeBSD 12.3 and Putty gets the output from EFI
> loader for both x86 and arm64.
>
> But during kernel booting the console output does not come in Putty, it
> only comes in vmconnect.exe.
>

So on 12.3, kernel output doesn't come out of both? Do you have
boot_multicons=YES in your loader.conf?
If not, only one of the consoles will get output from the kernel.

Warner

> Like below :
>
>
>
> Loading kernel...
>
> /boot/kernel/kernel text=0x931f24 data=0x187450 data=0x0+0x2d095e
> syms=[0x8+0x138120+0x8+0x124824]
>
> Loading configured modules...
>
> can't find '/boot/entropy'
>
> can't find '/etc/hostid'
>
> No valid device tree blob found!
>
> WARNING! Trying to fire up the kernel, but no device tree blob found!
>
> EFI framebuffer information:
>
> addr, size     0xe0000000, 0x800000
>
> dimensions     1024 x 768
>
> stride         1024
>
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<
>
>
>
> After this log is not coming in Putty in 12.3 for both x86 and arm64.
>
>
>
>
>
>
>

--000000000000f40f0205e03b12ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, May 30, 2022, 3:31 =
AM Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:











Hi,


=C2=A0


I am trying to access virtual serial console via Put=
ty and in 13.0 it is not working



for both x86 and arm64.


=C2=A0


It is very easy to reproduce:


1) In Windows Hyper-V set a=C2=A0 FreeBSD 13.0 VM


2) Use Powershell in Admin privileged mode and run following:<=
/u>


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Set-VMComPort -VMName <vm_name> -number 1 -path
\\.\pipe\Testpipe


2) In another Powershell with Admin privilege run following:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Set-VMFirmware -VMName <VM name>=C2=A0 --ConsoleMo=
de COM1


3) start the VM and open putty to connect the 
\\.\pipe\Testpipe in serial mode.


No output will be seen on putty.
Not even from the boot loader? That sure sounds like the autom=
atic fallback to simple text output isn't happening.

What does:
% sudo efivar --device-path 8be4df=
61-93ca-11d2-aa0d-00e098032b8c-ConOut
tell you? (Or run as ro=
ot if you don't like sudo).

The boot loader gr=
ew a non-optional graphics mode that's disabled when the boot code
detects we're talking to a 'serial port' between 12.x and=
 13.x. If you are getting no output
from the loader at all, I sus=
pect this is likely to blame.
=



But the same works in FreeBSD 12.3 and Putty gets the output from EFI lo=
ader for both x86 and arm64.


But during kernel booting the console output does not come in Putty, it =
only comes in vmconnect.exe.

So on 12.3, kernel output doesn't come out of both? Do you have boot_=
multicons=3DYES in your loader.conf?=C2=A0
If not, only one of th=
e consoles will get output from the kernel.=C2=A0

=
Warner




Like below :


=C2=A0


Loading kernel...


/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e =
syms=3D[0x8+0x138120+0x8+0x124824]


Loading configured modules...


can't find '/boot/entropy'


can't find '/etc/hostid'


No valid device tree blob found!


WARNING! Trying to fire up the kernel, but no device tree blob found!=



EFI framebuffer information:


addr, size=C2=A0=C2=A0=C2=A0=C2=A0 0xe0000000, 0x800000

dimensions=C2=A0=C2=A0=C2=A0=C2=A0 1024 x 768


stride=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1024


masks=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x00ff0000, =
0x0000ff00, 0x000000ff, 0xff000000 <<<<


=C2=A0


After this log is not coming in Putty in 12.3 for both x86 and arm64.=



=C2=A0


=C2=A0




=C2=A0











--000000000000f40f0205e03b12ac--

From nobody Tue May 31 06:10:06 2022
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 96E911B62822
	for ; Tue, 31 May 2022 06:10:17 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2134.outbound.protection.outlook.com [40.107.215.134])
	(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 4LC2201xcRz4W2c;
	Tue, 31 May 2022 06:10:16 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=h6oZBGhGZ/I/8ukpx/6YYUlOdsZx2j1779zLYgqsGs8rKZJJkvQLUC6GQ1fvy416A8S+rS0afPdivkBSWB711HErBsspRW4VTkAkSrhIWo259cLq/hJRFHC9x0vuVyH9Nt3rhQBArdlbQAnj95zGo9iqV/2yd16hImGiKYfsGK6GBgSW8utUYWUsKKBQoec60itSlslCR3AcbZdB1/jF+8ZK6C0DFZ1de9eoFkIAFfz9No26cJdxuaA+D1hHQVeQPrac4LngsYCxtHzkOHMEWI/on7g2pViLiCb2ua1mR8q6WWR6zPGNwNz7PabU5K1ODtpTm52tpiq0HxCphgYaLQ==
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=SMg6K6iKnLzDaFqzgkIerjYjmNSsPBiia+Yko+8Nb58=;
 b=gT5UbDsdk3U5YBe/VTS/pyWfoizzh4gdksEq6UVZis+wRbQaPpdJxDPIbjadL/AcKOmDNROzpL5EQjnXAbDJaHOJ+nsCJO/SQMLL0P+J8a3nOSnK/V+VfuZ0AL+1OWShsJnLoOo+kxFtKKQ0mbJmAya3r5uaivYjD4zuDhG0z8BZ4yfc0rE/nvI7LbNXcwApI5+cQ+BpvrpYS7+6V8cVSS/OiKqM4eHxj2Vz27XvBRDtQ9TXahf2o2U3fZM+Q1FYtXC7vWpLIAFLwhCVAnxab9Isv1A+89Zyln5G+jFmnrFicdyUDRVkCr64wJleX2JetrGHNCgLVQQKZIS6BFhFWQ==
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=SMg6K6iKnLzDaFqzgkIerjYjmNSsPBiia+Yko+8Nb58=;
 b=GQfzBc/iUN/yhKKxmTjhagiwwHR/KkCN5trc63azh0pO8id2wYrhYRDEbyyBVPmc/pfLw/KrNAtqHEGeqbSBkCq7cv3YuiXLaoyJiB//SQiqHh/O8IWhb9Ioo7k86ZApXn6DJmZkvP0ueWeIcyW6kXmisLENzXYzYTUSokqj9wE=
Received: from KL1P15301MB0532.APCP153.PROD.OUTLOOK.COM (2603:1096:820:5a::14)
 by KL1P15301MB0449.APCP153.PROD.OUTLOOK.COM (2603:1096:820:3a::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.0; Tue, 31 May
 2022 06:10:06 +0000
Received: from KL1P15301MB0532.APCP153.PROD.OUTLOOK.COM
 ([fe80::e439:ca1e:c407:9a7f]) by KL1P15301MB0532.APCP153.PROD.OUTLOOK.COM
 ([fe80::e439:ca1e:c407:9a7f%6]) with mapi id 15.20.5332.003; Tue, 31 May 2022
 06:10:06 +0000
From: Souradeep Chakrabarti 
To: Warner Losh 
CC: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	, Wei Hu 
Subject: RE: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Topic: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQAJq/UAACEn15A=
Date: Tue, 31 May 2022 06:10:06 +0000
Message-ID:
 
References:
 
 
In-Reply-To:
 
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=c76600f3-247b-466d-95fa-201c43c5eefc;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=2022-05-31T05:49:18Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7874f700-067a-4734-efaa-08da42cc3583
x-ms-traffictypediagnostic: KL1P15301MB0449:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 yKPoeM8vYi0yw81NzSDErFvxZTnVzms0nQHknbY1s7YCPCjjmq6bfQwwRxCcQdcSaolrMRRBX+oC/kiU8gwgIcDlMfccBpbzk7pKg8c6HGasqVmxRw9ZPtm5mnIeWqQctaLLcBkBGmQUvgy8tfu3KEv0HV+6cJV1yalp6//rbgmC7njms2tgBciieh8Q1Xmidrj7kY95Doe8qu79tFaMiwMZOAvEP+dbavSrIbKmMIJRJKzFpbjAbCF36QlMQfOvhtoyvfhB7B3eSa2YAO7EfBuvp4/G04wbImOITR0bmwdxKUacZtADsydPM2+XzkY0N415bMZIrGNL7+hlycSjhYTMsPffTO4gBkBLWLXpu0BSYCB7zz7SF4pyBHAifVRkpzCBYO3fAmX9yXEG+07d14pM+HkOrZt02JTD+G4DZHAEw0VpaouvW9VFx1a/50PjUQQfT4aHWW6TXGzrXwUpRn7pW9q/KltUyMJXAU0cSodEcDUUipe4gjSUeydZp4AdBLwNVg8QioRjNx75VwyB+2VifMuffGOoEBhS7jrHmuKfnfyl1Ze0kr1Lle9GyAGu7NCI1RqZmkT3ul9z0KznXukSarN+yTufQoolY4AW8MCV3y3LZN0JnjFhZGb1d/1FP2W64jFuAW8lbZtWCnVQnkejLo1EXQUo88TlAe4HjjfjStHxGc96Gw/lLujPPWLg4p9sJkNXEFEAH9kSpzPNyrQFYYYUsiXduc/lKR1lA5lhyErQBo8TIdx2V+TQTwf9W/plSwyjVuFAedoJDoCC5j88P+9rcPpYSpiAqMz8BVE=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:KL1P15301MB0532.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(86362001)(4326008)(9326002)(71200400001)(8936002)(52536014)(55016003)(38100700002)(508600001)(33656002)(8990500004)(54906003)(82960400001)(82950400001)(122000001)(316002)(2906002)(9686003)(83380400001)(6916009)(38070700005)(10290500003)(66446008)(64756008)(66556008)(66476007)(8676002)(186003)(107886003)(76116006)(7696005)(6506007)(5660300002)(66946007)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WkRyb0JvKzJXcCtkdlBaMlBJd1J6UGpSeS9QMkJ4NnNyeGc2R01JbE1kV3d0?=
 =?utf-8?B?SFhmd1ZncjZaaVZYdVo3eTBsTnNWejNwcVJHZURqOWZYemw1SERONUlVK0NW?=
 =?utf-8?B?ckt4SGlFeFMvK0ttYXI3MXNkc1dDME16SkJ6cHFoajFZZG5hZDBBMHZzcFNv?=
 =?utf-8?B?cnlCOTdHQVU3MW82SHFEaXZqRkxsbFFJNXd2T0pXVFpKRHZSRmR3a2s2UFhy?=
 =?utf-8?B?MHMxV3llUmFRaDJrT1ZEaVQwS0ZGaWRBTGJ2eG80NEtkOStUelVuZWtmcTJJ?=
 =?utf-8?B?cWwyUU9pcW45OXAycElIaEI2SVlKWUs0T1Mvd1oyc3VkUGlVS2V2WXh5TUtU?=
 =?utf-8?B?YVFBODRFa29zNjBIWi8veFgxL2Y0a0V2YnVWSU5mTFJwaS9rTnQ3L1VyZHQ5?=
 =?utf-8?B?Ui80RnUrU0RZUHhtNERoL1JpMXFiQ0RCUlNXQjJhZkk2d0Vhb2VRVmNRQkVK?=
 =?utf-8?B?TDZYV1RsazJ3NmkvU2VtenpweG4zalFqTXRGYytYaGhYa3k2bUY3eGdLaDdr?=
 =?utf-8?B?WW1nL3dwS3IrK1EyQVdvb3FFUHllcXZTQ3NTRFU4cG1LcElyNS9RS3NFZEVp?=
 =?utf-8?B?aXRzRGExRkx2YngwTnhpdFFJQWF6VEN0OGY3TmlTWWowZEpQR2NEY2hoMVY2?=
 =?utf-8?B?c2M3NGNsYzVubS9hOFRWcHJMZC8yVTlnYlI5a2hlR3RBVGdrSHIyMWlodVYz?=
 =?utf-8?B?OVlEUHlTY25JQXRNelNBcUZuS0dPdk5QUFRPZnZnc0ZmSFZjL3ZGdlNvcit6?=
 =?utf-8?B?U0owdFRqYmZMVGFodVkza3BFcXl6d1NYekRPc0YvVjFMVE1PaUMrQ0pzWEdt?=
 =?utf-8?B?NVFUVkdUQ01IR1dZVGN4U1NOZ1dFZ0xqTDh1Nk93TEErcWlPSCtsRFZ2MEpC?=
 =?utf-8?B?b2hPZUU1T2VZTEJneE5scklLWTJrTnMzdGtWc2pjWnhPdVNkdnhkNzhvQjBi?=
 =?utf-8?B?bmpmRlY1NXZWWVVaOGlxaTAvRVRhUGZFYUxDR3ZLNjRKS1lCTEZJUjFlOHps?=
 =?utf-8?B?R1VpdENLM1p2ZHFUcGVyR0tUYUUwbHM2Q2Y5RTBOT011WVRWMC9JdXplM1gw?=
 =?utf-8?B?R2t5amFSb2lzeDMycENHbTR5ZFZzMno0dmFPV0pmY0xqV1FKTitzQXplbnJm?=
 =?utf-8?B?b3lGd2tuMnNvVUdmdzlaZ3BxYllwZmp0OHdxZGlKWHc3ZnEvM2k1TnBxZnU4?=
 =?utf-8?B?RmRuOGpSL1JwZkFObnJqVGRSRkVlZGpoR05XSEZpM3BJZzBCZHk5amVUQkhF?=
 =?utf-8?B?QW9YNzB6VHFKQkF6ek81YVp6S1FRZEtGbjhjbms4Zm5RNVpLek9MNi9VM2Jn?=
 =?utf-8?B?c3B2S1pXd1JRS085YnordjFhcjJHUkdKemN4TkpvUzBlQUNZakJhS1VPNXpU?=
 =?utf-8?B?WlEzajdCWEtLcXJGYmMzSDFneUxYWEZHN3FnK2JDNGxFNVZiUlkwb3pjbW0z?=
 =?utf-8?B?dWpZY1ZkWTRrWGQ5cEx3bklPRXhTbmpmQkowbnBNTlR6RkZ2RjVvSlhkOS9R?=
 =?utf-8?B?bVJQT3BsM3pqU0l0c2RKLzh0eVhVQ2txM1JQeG9VeHU2ZVhuSEdvOUJKTjQ3?=
 =?utf-8?B?Ui9VQ0ZoSGJ4c3M5NjRrdU5URkp0Zi9HWXZwcXhOclNBN3hBNnB2cFJHeGZH?=
 =?utf-8?B?TzlZemt3UGdNVmVGSkFjZmFJVERra01UclptaUwzU3hCNTkxeXJMMThYbFpX?=
 =?utf-8?B?ZWY1VUU3bjBvUnZhZTJBdGJ4K1N5dGVXai9WSG9OKzNwWW5aWlY2cG5Pd2Jm?=
 =?utf-8?B?R2F2ZndmRDVwOUpZUVVuRUxKNkhEV0JNRnc4a2IrUFdRbHU0dHY1eThRSzda?=
 =?utf-8?B?enB5cG82VUtZdHBpd2R3NUlJdWNteHRBdEhRYUREOXpqU0FuUUpLdmg2bm9y?=
 =?utf-8?B?UE1kQ3pEYVNEdGIzUVFBZTgwNW1xTFhPVUFGakhsZE1vdFJTU0RaWWtzcVBJ?=
 =?utf-8?B?N3FDUXM2TlI2MXk4NWNSd3hSS01mWnZEZGZMY1dKVThVK01hcXVUUVNsckJo?=
 =?utf-8?B?bWV3c0dwVjcrYzdyMFhQNGZiZFBobEtNdDhUaGdmNWcwcG43ZFJ0aGxBUHVx?=
 =?utf-8?B?WWlaUllRMWxNSi96SmJMc2R4SU01NEhWdWdDaVdGTzlnQUVzYWpNdVNqNnRw?=
 =?utf-8?B?Y1NDTkV5Mm5Tb1Z4YjR2RGFSOHB3d1Q2czBZdnZiVTJoQW85clZYSEVINksy?=
 =?utf-8?B?QW9xc3hWb3VHcGN6RFpRc3QwcUZDRktiZ04wSVhlOTBLRUx3S2VIQzRQaVhM?=
 =?utf-8?B?dGp4N1Q3YU5HQjZRbmh0R3R0U1lEbmM4NjZHWVBDeitrV2huQlNlSjNSV1o4?=
 =?utf-8?B?OXpjMHZSK2J0bEhHd0pxbXVLZjRHQjhJUWlBU3o0QnVDNU1GdElOZz09?=
Content-Type: multipart/alternative;
	boundary="_000_KL1P15301MB05324F12C180034986BB27DFCCDC9KL1P15301MB0532_"
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: KL1P15301MB0532.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7874f700-067a-4734-efaa-08da42cc3583
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2022 06:10:06.4478
 (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: nDqRXFi3b79TfCWYuyr4kljZ1+lSP9d51lFWgzOWyhJZ8BwwvVnRZ/Gx1ucff1asiOdzCA/S8pCp/jZSs0V1Pq7t2wmzlt0o/fCegEv0Vio=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0449
X-Rspamd-Queue-Id: 4LC2201xcRz4W2c
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="GQfzBc/i";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.215.134 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.90 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.215.134:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.215.134:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 18672
Lines: 250

--_000_KL1P15301MB05324F12C180034986BB27DFCCDC9KL1P15301MB0532_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgV2FybmVyLA0KVGhhbmtzIGZvciBwb2ludGluZyBib290X211bHRpY29ucywgYW5kIHllcyBp
dCBoYXMgc29sdmVkIHRoZSBwcm9ibGVtIG9mIEZyZWVCU0Qga2VybmVsIGJvb3QgbG9ncw0Kbm90
IGNvbWluZyBpbiBQdXR0eSBpbiBib3RoIHg4NiBhbmQgYXJtNjQuDQoNClJlZ2FyZGluZyBGcmVl
QlNEIDEzLCAgeWVzIGxvYWRlci5lZmkgbG9ncyBhcmUgbm90IGNvbWluZyBpbiBQdXR0eSBtb3N0
bHkgYmVjYXVzZSBvZiBFRkkgZ2Z4IHVzYWdlDQp3aGljaCBpcyBub3Qgc3VwcG9ydGVkIGluIFB1
dHR5Lg0KDQpOb3cgd2UgY2FuIG92ZXJjb21lIGl0IGluIHg4NiBieSBzZXR0aW5nIHNldCBjb25z
b2xlPeKAnWNvbWNvbnNvbGXigJ0sIGFzIGl0IGlzIHVzaW5nIHRoZSBkaWZmZXJlbnQNCnVhcnQg
aW1wbGVtZW50YXRpb24gb2YgY29tY29uc29sZSBvZiBsb2FkZXIsIHdoaWNoIGlzIG5vdCB0aGUg
c2FtZSBpbiBhcm02NC4gVGhlIGltcGxlbWVudGF0aW9uDQpvZiBjb21jb25zb2xlIGluIGFybTY0
IGxvYWRlci5lZmkgaXMgbm90IHN1cHBvcnRlZCBpbiBIeXBlci1WIGxvb2tzIGxpa2UuIEFzIEh5
cGVyLVYgb25seSBzdXBwb3J0cw0KdHR5QU1BMCBmb3Igc2VyaWFsIGNvbnNvbGUgaW4gQVJNNjQg
YnV0IHN1cHBvcnRzIHVhcnQgaW4geDg2Lg0KDQpSZWdhcmRpbmcgQ29uT3V0LCBJIGhhdmUgZ290
IGl0IGZyb20geDg2IEZyZWVCU0QxMywgKGFzIGFybTY0IGlzIGluIHRoZSBwcm9jZXNzIG9mIGJy
aW5naW5nIHVwIGFuZA0KQ29uT3V0IGlzIHNhbWUgZm9yIGFybTY0IGFuZCB4ODYsIGNvbmZpcm1l
ZCBieSB1c2luZyBlZmlzaGVsbCBiaW5hcnkgYW5kIExpbnV4IHNoZWxsKS4NCg0KZWZpdmFyIC0t
ZGV2aWNlLXBhdGggOGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhjLUNvbk91dA0K
OGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhjLUNvbk91dA0KOiBBY3BpRXgoVk1C
dXMsLCkvVmVuSHcoOWIxN2U1YTItMDg5MS00MmRkLWI2NTMtODBiNWMyMjgwOWJhLDAyNzgwYWRh
NzdlM2FjNGE4ZTc3MDU1OGViMTA3M2Y4YzdlMDIwNTY2MjgwY2U0ZGFlYjc1MjBjN2VmNzYxNzEp
DQoNClRoYW5rcyAmIFJlZ2FyZHMsDQpTb3VyYWRlZXANCg0KU2VudDogTW9uZGF5LCBNYXkgMzAs
IDIwMjIgNzozMCBQTQ0KVG86IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8c2NoYWtyYWJhcnRpQG1p
Y3Jvc29mdC5jb20+DQpDYzogZnJlZWJzZC1hcm1ARnJlZUJTRC5vcmc7IHRzb29tZUBGcmVlQlNE
Lm9yZzsgV2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6
IHNlcmlhbCBjb25zb2xlIGFuZCBjb21jb25zb2xlIGluIEZyZWVCU0QgYXJtNjQNCg0KDQpPbiBN
b24sIE1heSAzMCwgMjAyMiwgMzozMSBBTSBTb3VyYWRlZXAgQ2hha3JhYmFydGkgPHNjaGFrcmFi
YXJ0aUBtaWNyb3NvZnQuY29tPG1haWx0bzpzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbT4+IHdy
b3RlOg0KSGksDQoNCkkgYW0gdHJ5aW5nIHRvIGFjY2VzcyB2aXJ0dWFsIHNlcmlhbCBjb25zb2xl
IHZpYSBQdXR0eSBhbmQgaW4gMTMuMCBpdCBpcyBub3Qgd29ya2luZw0KZm9yIGJvdGggeDg2IGFu
ZCBhcm02NC4NCg0KDQoNCkl0IGlzIHZlcnkgZWFzeSB0byByZXByb2R1Y2U6DQoNCjEpIEluIFdp
bmRvd3MgSHlwZXItViBzZXQgYSAgRnJlZUJTRCAxMy4wIFZNDQoNCjIpIFVzZSBQb3dlcnNoZWxs
IGluIEFkbWluIHByaXZpbGVnZWQgbW9kZSBhbmQgcnVuIGZvbGxvd2luZzoNCg0KICAgICAgICAg
ICAgICAgIFNldC1WTUNvbVBvcnQgLVZNTmFtZSA8dm1fbmFtZT4gLW51bWJlciAxIC1wYXRoIFxc
LlxwaXBlXFRlc3RwaXBlPGZpbGU6Ly8uL3BpcGUvVGVzdHBpcGU+DQoNCjIpIEluIGFub3RoZXIg
UG93ZXJzaGVsbCB3aXRoIEFkbWluIHByaXZpbGVnZSBydW4gZm9sbG93aW5nOg0KDQogICAgICAg
ICAgICAgICAgU2V0LVZNRmlybXdhcmUgLVZNTmFtZSA8Vk0gbmFtZT4gIC0tQ29uc29sZU1vZGUg
Q09NMQ0KDQozKSBzdGFydCB0aGUgVk0gYW5kIG9wZW4gcHV0dHkgdG8gY29ubmVjdCB0aGUgXFwu
XHBpcGVcVGVzdHBpcGU8ZmlsZTovLy4vcGlwZS9UZXN0cGlwZT4gaW4gc2VyaWFsIG1vZGUuDQoN
Ck5vIG91dHB1dCB3aWxsIGJlIHNlZW4gb24gcHV0dHkuDQpOb3QgZXZlbiBmcm9tIHRoZSBib290
IGxvYWRlcj8gVGhhdCBzdXJlIHNvdW5kcyBsaWtlIHRoZSBhdXRvbWF0aWMgZmFsbGJhY2sgdG8g
c2ltcGxlIHRleHQgb3V0cHV0IGlzbid0IGhhcHBlbmluZy4NCg0KV2hhdCBkb2VzOg0KJSBzdWRv
IGVmaXZhciAtLWRldmljZS1wYXRoIDhiZTRkZjYxLTkzY2EtMTFkMi1hYTBkLTAwZTA5ODAzMmI4
Yy1Db25PdXQNCnRlbGwgeW91PyAoT3IgcnVuIGFzIHJvb3QgaWYgeW91IGRvbid0IGxpa2Ugc3Vk
bykuDQoNClRoZSBib290IGxvYWRlciBncmV3IGEgbm9uLW9wdGlvbmFsIGdyYXBoaWNzIG1vZGUg
dGhhdCdzIGRpc2FibGVkIHdoZW4gdGhlIGJvb3QgY29kZQ0KZGV0ZWN0cyB3ZSdyZSB0YWxraW5n
IHRvIGEgJ3NlcmlhbCBwb3J0JyBiZXR3ZWVuIDEyLnggYW5kIDEzLnguIElmIHlvdSBhcmUgZ2V0
dGluZyBubyBvdXRwdXQNCmZyb20gdGhlIGxvYWRlciBhdCBhbGwsIEkgc3VzcGVjdCB0aGlzIGlz
IGxpa2VseSB0byBibGFtZS4NCg0KQnV0IHRoZSBzYW1lIHdvcmtzIGluIEZyZWVCU0QgMTIuMyBh
bmQgUHV0dHkgZ2V0cyB0aGUgb3V0cHV0IGZyb20gRUZJIGxvYWRlciBmb3IgYm90aCB4ODYgYW5k
IGFybTY0Lg0KDQpCdXQgZHVyaW5nIGtlcm5lbCBib290aW5nIHRoZSBjb25zb2xlIG91dHB1dCBk
b2VzIG5vdCBjb21lIGluIFB1dHR5LCBpdCBvbmx5IGNvbWVzIGluIHZtY29ubmVjdC5leGUuDQoN
ClNvIG9uIDEyLjMsIGtlcm5lbCBvdXRwdXQgZG9lc24ndCBjb21lIG91dCBvZiBib3RoPyBEbyB5
b3UgaGF2ZSBib290X211bHRpY29ucz1ZRVMgaW4geW91ciBsb2FkZXIuY29uZj8NCklmIG5vdCwg
b25seSBvbmUgb2YgdGhlIGNvbnNvbGVzIHdpbGwgZ2V0IG91dHB1dCBmcm9tIHRoZSBrZXJuZWwu
DQoNCldhcm5lcg0KDQpMaWtlIGJlbG93IDoNCg0KDQoNCkxvYWRpbmcga2VybmVsLi4uDQoNCi9i
b290L2tlcm5lbC9rZXJuZWwgdGV4dD0weDkzMWYyNCBkYXRhPTB4MTg3NDUwIGRhdGE9MHgwKzB4
MmQwOTVlIHN5bXM9WzB4OCsweDEzODEyMCsweDgrMHgxMjQ4MjRdDQoNCkxvYWRpbmcgY29uZmln
dXJlZCBtb2R1bGVzLi4uDQoNCmNhbid0IGZpbmQgJy9ib290L2VudHJvcHknDQoNCmNhbid0IGZp
bmQgJy9ldGMvaG9zdGlkJw0KDQpObyB2YWxpZCBkZXZpY2UgdHJlZSBibG9iIGZvdW5kIQ0KDQpX
QVJOSU5HISBUcnlpbmcgdG8gZmlyZSB1cCB0aGUga2VybmVsLCBidXQgbm8gZGV2aWNlIHRyZWUg
YmxvYiBmb3VuZCENCg0KRUZJIGZyYW1lYnVmZmVyIGluZm9ybWF0aW9uOg0KDQphZGRyLCBzaXpl
ICAgICAweGUwMDAwMDAwLCAweDgwMDAwMA0KDQpkaW1lbnNpb25zICAgICAxMDI0IHggNzY4DQoN
CnN0cmlkZSAgICAgICAgIDEwMjQNCg0KbWFza3MgICAgICAgICAgMHgwMGZmMDAwMCwgMHgwMDAw
ZmYwMCwgMHgwMDAwMDBmZiwgMHhmZjAwMDAwMCA8PDw8DQoNCg0KDQpBZnRlciB0aGlzIGxvZyBp
cyBub3QgY29taW5nIGluIFB1dHR5IGluIDEyLjMgZm9yIGJvdGggeDg2IGFuZCBhcm02NC4NCg0K
DQoNCg0KDQo=

--_000_KL1P15301MB05324F12C180034986BB27DFCCDC9KL1P15301MB0532_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu
MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi
IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+
PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0
IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3
b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SGkgV2FybmVyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhhbmtzIGZvciBwb2ludGluZyBib290X211bHRpY29ucywgYW5kIHllcyBpdCBoYXMg
c29sdmVkIHRoZSBwcm9ibGVtIG9mIEZyZWVCU0Qga2VybmVsIGJvb3QgbG9nczxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm90IGNvbWluZyBpbiBQdXR0eSBpbiBib3RoIHg4
NiBhbmQgYXJtNjQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyBGcmVlQlNEIDEz
LCAmbmJzcDt5ZXMgbG9hZGVyLmVmaSBsb2dzIGFyZSBub3QgY29taW5nIGluIFB1dHR5IG1vc3Rs
eSBiZWNhdXNlIG9mIEVGSSBnZnggdXNhZ2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPndoaWNoIGlzIG5vdCBzdXBwb3J0ZWQgaW4gUHV0dHkuIDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5Ob3cgd2UgY2FuIG92ZXJjb21lIGl0IGluIHg4NiBieSBzZXR0aW5nIHNldCBjb25z
b2xlPeKAnWNvbWNvbnNvbGXigJ0sIGFzIGl0IGlzIHVzaW5nIHRoZSBkaWZmZXJlbnQ8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVhcnQgaW1wbGVtZW50YXRpb24gb2YgY29t
Y29uc29sZSBvZiBsb2FkZXIsIHdoaWNoIGlzIG5vdCB0aGUgc2FtZSBpbiBhcm02NC4gVGhlIGlt
cGxlbWVudGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiBjb21j
b25zb2xlIGluIGFybTY0IGxvYWRlci5lZmkgaXMgbm90IHN1cHBvcnRlZCBpbiBIeXBlci1WIGxv
b2tzIGxpa2UuIEFzIEh5cGVyLVYgb25seSBzdXBwb3J0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+dHR5QU1BMCBmb3Igc2VyaWFsIGNvbnNvbGUgaW4gQVJNNjQgYnV0IHN1
cHBvcnRzIHVhcnQgaW4geDg2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgQ29u
T3V0LCBJIGhhdmUgZ290IGl0IGZyb20geDg2IEZyZWVCU0QxMywgKGFzIGFybTY0IGlzIGluIHRo
ZSBwcm9jZXNzIG9mIGJyaW5naW5nIHVwIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Q29uT3V0IGlzIHNhbWUgZm9yIGFybTY0IGFuZCB4ODYsIGNvbmZpcm1lZCBieSB1
c2luZyBlZmlzaGVsbCBiaW5hcnkgYW5kIExpbnV4IHNoZWxsKS48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+ZWZpdmFyIC0tZGV2aWNlLXBhdGggOGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4
MDMyYjhjLUNvbk91dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OGJlNGRm
NjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhjLUNvbk91dDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+OiBBY3BpRXgoVk1CdXMsLCkvVmVuSHcoOWIxN2U1YTItMDg5MS00
MmRkLWI2NTMtODBiNWMyMjgwOWJhLDAyNzgwYWRhNzdlM2FjNGE4ZTc3MDU1OGViMTA3M2Y4Yzdl
MDIwNTY2MjgwY2U0ZGFlYjc1MjBjN2VmNzYxNzEpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
YW5rcyAmYW1wOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
U291cmFkZWVwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAzMCwgMjAyMiA3OjMwIFBNPGJyPg0KPGI+VG86
PC9iPiBTb3VyYWRlZXAgQ2hha3JhYmFydGkgJmx0O3NjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29t
Jmd0Ozxicj4NCjxiPkNjOjwvYj4gZnJlZWJzZC1hcm1ARnJlZUJTRC5vcmc7IHRzb29tZUBGcmVl
QlNELm9yZzsgV2VpIEh1ICZsdDt3ZWhAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gW0VYVEVSTkFMXSBSZTogc2VyaWFsIGNvbnNvbGUgYW5kIGNvbWNvbnNvbGUgaW4gRnJl
ZUJTRCBhcm02NDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMzAsIDIwMjIsIDM6MzEg
QU0gU291cmFkZWVwIENoYWtyYWJhcnRpICZsdDs8YSBocmVmPSJtYWlsdG86c2NoYWtyYWJhcnRp
QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5zY2hha3JhYmFydGlAbWljcm9zb2Z0LmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5IaSw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9
IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUlOIj5JIGFtIHRyeWluZyB0byBhY2Nlc3MgdmlydHVhbCBzZXJp
YWwgY29uc29sZSB2aWEgUHV0dHkgYW5kIGluIDEzLjAgaXQgaXMgbm90IHdvcmtpbmcNCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t
SU4iPmZvciBib3RoIHg4NiBhbmQgYXJtNjQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gbGFuZz0iRU4tSU4iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh
bmc9IkVOLUlOIj5JdCBpcyB2ZXJ5IGVhc3kgdG8gcmVwcm9kdWNlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj4xKSBJbiBXaW5kb3dzIEh5cGVyLVYgc2V0IGEm
bmJzcDsgRnJlZUJTRCAxMy4wIFZNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu
Zz0iRU4tSU4iPjIpIFVzZSBQb3dlcnNoZWxsIGluIEFkbWluIHByaXZpbGVnZWQgbW9kZSBhbmQg
cnVuIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1J
TiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNldC1WTUNvbVBvcnQgLVZNTmFt
ZSAmbHQ7dm1fbmFtZSZndDsgLW51bWJlciAxIC1wYXRoDQo8YSBocmVmPSJmaWxlOi8vLi9waXBl
L1Rlc3RwaXBlIj5cXC5ccGlwZVxUZXN0cGlwZTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cD48c3BhbiBsYW5nPSJFTi1JTiI+MikgSW4gYW5vdGhlciBQb3dlcnNoZWxsIHdpdGggQWRtaW4g
cHJpdmlsZWdlIHJ1biBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g
bGFuZz0iRU4tSU4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXQtVk1GaXJt
d2FyZSAtVk1OYW1lICZsdDtWTSBuYW1lJmd0OyZuYnNwOyAtLUNvbnNvbGVNb2RlIENPTTE8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1JTiI+Mykgc3RhcnQgdGhlIFZN
IGFuZCBvcGVuIHB1dHR5IHRvIGNvbm5lY3QgdGhlIDxhIGhyZWY9ImZpbGU6Ly8uL3BpcGUvVGVz
dHBpcGUiPg0KXFwuXHBpcGVcVGVzdHBpcGU8L2E+IGluIHNlcmlhbCBtb2RlLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5ObyBvdXRwdXQgd2lsbCBiZSBzZWVu
IG9uIHB1dHR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgZXZlbiBmcm9t
IHRoZSBib290IGxvYWRlcj8gVGhhdCBzdXJlIHNvdW5kcyBsaWtlIHRoZSBhdXRvbWF0aWMgZmFs
bGJhY2sgdG8gc2ltcGxlIHRleHQgb3V0cHV0IGlzbid0IGhhcHBlbmluZy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkb2VzOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JSBzdWRvIGVm
aXZhciAtLWRldmljZS1wYXRoIDhiZTRkZjYxLTkzY2EtMTFkMi1hYTBkLTAwZTA5ODAzMmI4Yy1D
b25PdXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PnRlbGwgeW91PyAoT3IgcnVuIGFzIHJvb3QgaWYgeW91IGRvbid0IGxpa2Ugc3VkbykuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBib290
IGxvYWRlciBncmV3IGEgbm9uLW9wdGlvbmFsIGdyYXBoaWNzIG1vZGUgdGhhdCdzIGRpc2FibGVk
IHdoZW4gdGhlIGJvb3QgY29kZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+ZGV0ZWN0cyB3ZSdyZSB0YWxraW5nIHRvIGEgJ3NlcmlhbCBwb3J0JyBi
ZXR3ZWVuIDEyLnggYW5kIDEzLnguIElmIHlvdSBhcmUgZ2V0dGluZyBubyBvdXRwdXQ8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyb20gdGhlIGxv
YWRlciBhdCBhbGwsIEkgc3VzcGVjdCB0aGlzIGlzIGxpa2VseSB0byBibGFtZS48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFu
IGxhbmc9IkVOLUlOIj5CdXQgdGhlIHNhbWUgd29ya3MgaW4gRnJlZUJTRCAxMi4zIGFuZCBQdXR0
eSBnZXRzIHRoZSBvdXRwdXQgZnJvbSBFRkkgbG9hZGVyIGZvciBib3RoIHg4NiBhbmQgYXJtNjQu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tSU4iPkJ1dCBkdXJpbmcg
a2VybmVsIGJvb3RpbmcgdGhlIGNvbnNvbGUgb3V0cHV0IGRvZXMgbm90IGNvbWUgaW4gUHV0dHks
IGl0IG9ubHkgY29tZXMgaW4gdm1jb25uZWN0LmV4ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+U28gb24gMTIuMywga2VybmVsIG91dHB1dCBkb2Vzbid0IGNvbWUgb3V0IG9mIGJvdGg/IERv
IHlvdSBoYXZlIGJvb3RfbXVsdGljb25zPVlFUyBpbiB5b3VyIGxvYWRlci5jb25mPyZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgbm90
LCBvbmx5IG9uZSBvZiB0aGUgY29uc29sZXMgd2lsbCBnZXQgb3V0cHV0IGZyb20gdGhlIGtlcm5l
bC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+V2FybmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K
PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5MaWtlIGJlbG93IDo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHA+PHNwYW4gbGFuZz0iRU4tSU4iPkxvYWRpbmcga2VybmVsLi4uPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tSU4iPi9ib290L2tlcm5lbC9rZXJuZWwgdGV4dD0w
eDkzMWYyNCBkYXRhPTB4MTg3NDUwIGRhdGE9MHgwKzB4MmQwOTVlIHN5bXM9WzB4OCsweDEzODEy
MCsweDgrMHgxMjQ4MjRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t
SU4iPkxvYWRpbmcgY29uZmlndXJlZCBtb2R1bGVzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHA+PHNwYW4gbGFuZz0iRU4tSU4iPmNhbid0IGZpbmQgJy9ib290L2VudHJvcHknPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tSU4iPmNhbid0IGZpbmQgJy9ldGMvaG9z
dGlkJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5ObyB2YWxp
ZCBkZXZpY2UgdHJlZSBibG9iIGZvdW5kITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu
IGxhbmc9IkVOLUlOIj5XQVJOSU5HISBUcnlpbmcgdG8gZmlyZSB1cCB0aGUga2VybmVsLCBidXQg
bm8gZGV2aWNlIHRyZWUgYmxvYiBmb3VuZCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJFTi1JTiI+RUZJIGZyYW1lYnVmZmVyIGluZm9ybWF0aW9uOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5hZGRyLCBzaXplJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDB4ZTAwMDAwMDAsIDB4ODAwMDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+
PHNwYW4gbGFuZz0iRU4tSU4iPmRpbWVuc2lvbnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTAy
NCB4IDc2ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5zdHJp
ZGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTAyNDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj5tYXNrcyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAweDAwZmYwMDAw
LCAweDAwMDBmZjAwLCAweDAwMDAwMGZmLCAweGZmMDAwMDAwICZsdDsmbHQ7Jmx0OyZsdDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tSU4iPkFmdGVyIHRoaXMgbG9nIGlzIG5v
dCBjb21pbmcgaW4gUHV0dHkgaW4gMTIuMyBmb3IgYm90aCB4ODYgYW5kIGFybTY0LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUlOIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1JTiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_KL1P15301MB05324F12C180034986BB27DFCCDC9KL1P15301MB0532_--

From nobody Tue May 31 13:13:20 2022
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 A41381B423BE
	for ; Tue, 31 May 2022 13:18:46 +0000 (UTC)
	(envelope-from s199p.wa1k9r@gmail.com)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35])
	(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 4LCCXP33qGz3rqd
	for ; Tue, 31 May 2022 13:18:45 +0000 (UTC)
	(envelope-from s199p.wa1k9r@gmail.com)
Received: by mail-vk1-xa35.google.com with SMTP id b81so6191292vkf.1
        for ; Tue, 31 May 2022 06:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=YMnRxHwiPqVXMPOSKI8cr60qgetYYXzLUVrpvowQKpQ=;
        b=h9XV4kSlp5O2bd/AuO6N6Gi4fkYgNp0zTw1U622Cz2hIN1TX+BovmYqnx1Xt9eggs4
         0oxY1sLSKl5jvQCkiNazmsi/AYUTo0m1kGnrvfgU6rt4WorKtraG+TLKghs1UeL+UenK
         S8j+YPlG7WGOQOM7akMkQc59ohNnJ0Qj2XeGthiti8H9rYYWyyLHFdE4ACHq6kwkddH7
         f/BtZ8QKWo9MZ/wFfm/nXguFYfZpfscad8TuzKBPiIWgy2u7iCJx3UFjtB566Bn/+67R
         5m3sf1g9JHas6/lfI15ENIXVaJH3w6aTxh2Lh6XojaX3oLnkKppjpW3W3lz6D00dRUBh
         jGfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=YMnRxHwiPqVXMPOSKI8cr60qgetYYXzLUVrpvowQKpQ=;
        b=YmECsGoIFStbKOdZX8nkCt8uG8RNV0PgApnE/wRPb26HtZoA36dLzEjIamYEIajRUU
         03xQmk7UvAT0hY1vwknTSasS2dB9DcqL5bzFyzb3V5HScmar2B0UCpVQCeShREDJ1+5g
         9rkZm/FECH53e4vN0VhUbzfz5v8sr/XSYCWrFO7h8h/Q9wLVYYjBpQsU83rs2kzMOSzK
         gOFynaKHUoJ4j/wjsypz5xXfEyAnTdxqATtIC0MzCk4EKxvfEdzrV5K1YyDqowEM9M6r
         sI488rV10iLZ6OGkjFdAcqC1gpe6V1ehFgTeXrxur/GT2UvfSDmE9RGyZSMgFf+Xji7a
         di4w==
X-Gm-Message-State: AOAM533IN/x4Bgiohgyvocm1oxon3FmovpGHyf03NdZLc3cj0G3W70yN
	KHAhEH1QXUAdsT4yyATZdf+6CWdUlThKDDruT16PMC7m52M4NA==
X-Google-Smtp-Source: ABdhPJynG4xmmYE7YuzObs5kQq1vXZHUUMdTbrsAGjQ5wuBBd3POxUAeiyLCSUMk1SVuYmnvFM2FtsOhNxjnoPE/2xA=
X-Received: by 2002:a1f:e5c4:0:b0:35c:dc22:15e3 with SMTP id
 c187-20020a1fe5c4000000b0035cdc2215e3mr861690vkh.39.1654003119335; Tue, 31
 May 2022 06:18:39 -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
From: Sleep Walker 
Date: Tue, 31 May 2022 16:13:20 +0300
Message-ID: 
Subject: FreeBSD 13.1-RELEASE on MOCHAbin Marvel/ARMADA 7040
To: Free BSD 
Content-Type: multipart/alternative; boundary="00000000000062af2205e04e9c70"
X-Rspamd-Queue-Id: 4LCCXP33qGz3rqd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=h9XV4kSl;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::a35 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com
X-Spamd-Result: default: False [-3.87 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.87)[-0.870];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a35:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3235
Lines: 64

--00000000000062af2205e04e9c70
Content-Type: text/plain; charset="UTF-8"

Hello!

I still managed to install FreeBSD 13.1-RELEASE
on GlobalScale MOCHAbin(Marvel/ARMADA 7040), for this you have to build
EDK2 UEFI.

Here's what came out, it's dmesg

https://dmesgd.nycbug.org/index.cgi?do=view&id=6609

While PCIe and Ethernet do not work.

This is a great board for FreeBSD/OPNsense.

What do you think about this?
How to make Ethernet work?

-- 
E-Mail: s199p.wa1k9r@gmail.com
Twitter: https://twitter.com/S199pWa1k9r

--00000000000062af2205e04e9c70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello!
I still managed to inst=
all FreeBSD 13.1-RELEASE
on GlobalScale MOCHAbin(Marvel/ARMADA 7040),=C2=A0for this you have to build EDK2 UEFI.
Here's=
 what came out, it's dmesg
https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D6609
While PCIe and =
Ethernet do not work.
This is a great board for Free=
BSD/OPNsense.

What do you think about this?
How to make Ethernet work?

-- 
=



--00000000000062af2205e04e9c70--

From nobody Wed Jun  1 15:41:42 2022
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 6222F1B616AA
	for ; Wed,  1 Jun 2022 15:41:51 +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 4LCtg23R1nz3LCc
	for ; Wed,  1 Jun 2022 15:41:50 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 251Ffhcn041863
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 1 Jun 2022 08:41:43 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 251FfhBm041862;
	Wed, 1 Jun 2022 08:41:43 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 1 Jun 2022 08:41:42 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Mountroot problems on RPi3/aarch64
Message-ID: <20220601154142.GA41835@www.zefox.net>
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-Rspamd-Queue-Id: 4LCtg23R1nz3LCc
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 193
Lines: 9

Since about 05/29 mountroot has been failing on a Pi3 self-hosting -current,
using a usb mechanical hard disk.  

Anybody else seen this sort of behavior? 

Thanks for reading,

bob prohaska
 

From nobody Wed Jun  1 16:17:10 2022
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 D29F41B48CE6
	for ; Wed,  1 Jun 2022 16:17:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4LCvS554z9z3hHQ
	for ; Wed,  1 Jun 2022 16:17:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654100238; bh=IWuLbdPpzWmrNz3uicNpJgZ9uR8QG6+kve9Jp4IdIUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cLdmLdkPPDBNBnj9vvbh3kcZDUZ6M2wk/mAiV8hSvqRfZrMy8U2r73/gftwu7yBmQQ3+YpcCNjkX1PfGPF9VEjv8FmBoEoSIsiaUJZTqPVpQ52GDfQLu5DjZJWD6alkjfjTzm9Ak6a3pBppSMN7Jjdc9dN1h/w/+GsKI3URYmO/CZ97dEYftt+8nblNOhsbdydy8+liriRkmltHJ01g82DDmyNQZoiIzgdzyZM2dbxbYV3pbk0gGIHhSJDzgaOD3c/+Ztp7oiZJmtxkK+EiBhkx7M/qXZD5v2Y3VcSa4cBBOyp6QoU7hTavbcVHilYJUQeGassAF4e45jrjY3PVShQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654100238; bh=jy7YjRFeEAW7GH1vopXhk+QTeqpi12gP3t5ZfuJYkyA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tFyZk/8VvK2DHGmqysz036niquT8t1UBeOSIdZ7qRk6Lbpl7FcVqInTAjzMc3QELQvvJqB0h2oU4jQCQ7y242vKzFoMjoUgP0Sq2dOFlHp9O++J8jlgy5Hz4ebddKjF0+1d8814AuqJRZpzJ4bLm/oLFTLdpELqdjVwJY4xzDo8ZBWX6y8DZmxIzks2hV+M8dtfEdbma5oq7zQdpfJMJ6Gx42gl08vGV5hZXIBz/+Q/oFfGX9s8Sruk/+K4O5SIeU46e/aprb008qHyArMi9mQSEQkj64GCfMo+KZB9p4vBQAoSNR+njGbrSNc0nVf4ZJK3wVGVi87XOP/F/Cje2Ow==
X-YMail-OSG: lLjJvw4VM1mOqJngmNQ7omdIpDaoF4v9qMiof7lA.QaYwP2GswI4m78WGSPD2L5
 B0ZUhRSb5ExhsGD9OL3fWfwII6BqtFzSgmsmVRK4mU4.ATXkZM1JJuoaHama_jwooPeapI2IE5Rc
 gW9DF_ML1DCNwhtq774LYPMrrF9Hu91qii39_ntUx_p5P5ECQsoq4HGyMlhpY078RhJShy_L0ME_
 uDUBcwJrocVls40tjtf5W29RoJSiJCweEg5tmaK5KQN8OnIYnIZlqDv9ys.hfQQEk9tV_kyX5rir
 7UFq4yR7qEyg.wmc1Fn2hZyb3JKIijS2aZBGVCB8DMiTG31pFgWMMtA5vwqDJfjDo.TCA53xjFOc
 .38bgv4LzQCXM4V25h3e1Xc0oaWrKLJe2.7Fz5zYfnh1uGSkBUzZM28JbkdQOoGS8FR_As0lJTRv
 T5FR4hI3pZZZpGyReMUN.2cWm55R07PGzEBsXJS1Qa6fZlSg1cczRsUmfbzjb7b8wmxRogypxcTl
 A2upwpRrxgbq_O3cJJoQVQsenh74y6AYQ7Kt99QYHXbSDrQg_p5KZGdHeBlGfhiFq.ZYLqHcYqq7
 5rPSkPxopV8k6GfiKajthNLKIGFdleDyqyPejzmJFSU1M0eUo_D8JlBf43E6VQgWm2bIBBv6LRP3
 xRiy1Pzm488ftM_vC9gufugd55Gm1UhxyMCL_yWeOqPpgR4cypg6S1gRho1yBTeNmOmZJ_OfV4Mc
 t9SamU_0r92nEyHVXmP3zZ1ceLRxUUxx8vReqS3fOBy509uZWnj76dDrtB5R.rRX8j.yiXcyo7bg
 MCMbC416.CB84i8SkxG0.7doITgKE3U_YpE.FTBAzT4DNe3PQw1eVMUCvz5qs1lcJOXaU0DpteIm
 ZSttJILhkVmLi01iK9V6pctmc9zW1ch76ZO1dDCBR8Xh3RUlL2GAxo8n0NwF7qVN.SlWxbvRsATR
 TCqLCCV4HZhj2Ndl.rMhzLqwF1uNGwfsKxNsyjE3TGOgwWk9CpY84OZbFGghDF74dQ.dCyehEl.M
 UoyCL1gMyA_rnGFtypJxr1F8cO_LA105yF0JJSkagIgErEIvBrs5u8l7QgFxstdRJf5flQRqbPwY
 HI_bbDdFEDRmr1Sc6rCR.GdAkr58f_tqzRbciKd4.5nvDq3mPg6o0lfom.LRVzjEYRrzYEDtm5HY
 2DcRvwro5SC3nXA9.na7QrtBRo.UxnakZvdTBeMhxcE1g89YzJiPpYADErTgpkdD2qWCIt25UQgx
 5fP6xer6NhtNMNjMUKRg.zgVeD2HhNTriKQ_hgHNUWgxN1htszCVopZSHE_eE4dODaoup_iZmuzX
 _Zq4BXYZBKS5Te7hXvs_rZKoJnBh1FSToXc3I9_o6TiNNas9nP0SFTsRZJ5rr7U7ParrpYHTpe3B
 _ArUfQARwaIvQVhv2vdH9IaW0COVn_xXFLapXte6ZHnKb.lZ6fufZc1fpmI7_ilDn767ZiDYeBa8
 m3535YgtZIl2_ScvKaqgdTYQBonF9cW.uP8H1dueTNJAljAohalbqHZPya3jLNekFezADoasriQD
 jXJN0JQisbWFj8OwnpkMhJyWNdh3KLMSFoLE1sFibaeQ8_20MwNEO.w.UexOJB0WNVf4n5Zf1kl1
 lxz5uBy66Tj6LUC5OdNPkywvF1HVfgMvcHHv5CivsAjrUPUu30d8wB.sTF1Y5UnApLtpwBaC07Vm
 hszJuOwHxTFqYTEuPjXFQC9mfNMLi8pD8O53vm03kFnjbep6gbhHd6zD6mDyzmu.zfX4agQvmvor
 azKB9UXghRJ3Tfo2aGg7vZVfQcN02vjybmuVz0ISl5zEh9ug1w3KryB3Zny7YbvMK5tc53M8eZcw
 dTlNTQlWuotXUF2qlAsbpJYrfxjQhiV9rjAbdXUTiexXqUV9L.q7V1.orPYj1UNZ8Nuxc7f1kGav
 WWpUcLPCYewVaUCpkQGavcPuha.s9lG_BHUnoYt.xndd2gY90wNtRfc1hL1XPinTS3cnyZGaNUGe
 8yA0S4FGcBdrtoLoXypnB5QLjaDMDfez35SigVAW8BLq4Lg1qSKjyGfLiHSVYqReOu_3oO1xRi6.
 EYdNxSWHH.emArruQmHz_0GBee4w6ElNgrT0pZsz1HUv898HW5gnydc2nLZ_Yx5Yc0jbSZOtAqmN
 XjZVxhHD1PZKEBFR5rjraX4HJkOVVbYlEy1hXGQjTI4gscoJW8VBGCgcpeNqRRYS.PlMOr5Uy.pn
 wQkKchMxIT44zpRz31JMeHMMcz8.graRbp.lY1Tq5au5Kq7vR.0YS6OWt3umF1SXUZ_.87stFxtw
 qMvFSuDYYMORci3VbjctDydARXOidAapOgRCpLIKKnA6XMD9bw2tVUYdjO7Gb0ZkaqIH1nbImTbp
 fNemF9EzBrgJnGvorSwE-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 1 Jun 2022 16:17:18 +0000
Received: by hermes--canary-production-bf1-856dbf94db-vvmb9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0366967627438ebaf825583e0f33b903;
          Wed, 01 Jun 2022 16:17:12 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220601154142.GA41835@www.zefox.net>
Date: Wed, 1 Jun 2022 09:17:10 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LCvS554z9z3hHQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=cLdmLdkP;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 840
Lines: 32

On 2022-Jun-1, at 08:41, bob prohaska  wrote:

> Since about 05/29 mountroot has been failing on a Pi3 self-hosting =
-current,
> using a usb mechanical hard disk. =20
>=20
> Anybody else seen this sort of behavior?=20

You do not report much context. FreeBSD version? UFS? ZFS?
And so on.

However, there has been today (for main):

git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity =
checks when reading a superblock

that is for fixing boot problems in UFS contexts. See:

=
https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.h=
tml

This is for fixes related to the 2022-May-27 change:

	=E2=80=A2 git: 076002f24d35 - main - Do comprehensive UFS/FFS =
superblock integrity checks when reading a superblock. Kirk McKusick=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jun  1 16:28:50 2022
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 5B9AC1B4B5BB
	for ; Wed,  1 Jun 2022 16:29:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36])
	(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 4LCvjb1q4jz3jqp
	for ; Wed,  1 Jun 2022 16:29:07 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe36.google.com with SMTP id k4so2204002vsp.3
        for ; Wed, 01 Jun 2022 09:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ZP1qbJU0Jbxgtptja4UPoaAtCL1KCaqg0o3pjxOSIZY=;
        b=RBVTrSuCVRvfMQwndzlZ6Ju73zX5knW6tzGBgOqNtlO6ztzvFu0UxkglR9fjxj0V0i
         Nh9lvToCiXGCFmI0nkjAIHtITJG2nJJA8MGX0riyvVgo3mNPExHWD+D/UgEjG1BA7nu7
         nbh5F0f+oC71Jibg0yuk5IPg+J4Cg33krflc5pF9rk7TcF5G3ACpzAq7QuUZAv/fXCe4
         E0Vvux3aMYmJh2k8+pOl3F25bvna1hA70BvTPQvBMwNSRQAmOUTAz7NXG4W1RnvftOTe
         2zBZ+6A8ZXS6DB0bzbay2XyxrKyOveNIe1GVs4b0E/fZ2bCRCQOZyej8oLb5GSDEZbpR
         9Y+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ZP1qbJU0Jbxgtptja4UPoaAtCL1KCaqg0o3pjxOSIZY=;
        b=01OKt/EYzmWmcsZLEHYLh/+9hR+z18jkEVpSO27vQDr/9lmy/KdjcX2crF0fYnFBKS
         wXBKP8Umq2Ux03l8Kl3KFUX8/zwCjCc9Q8qGT9kJmfCkmNhFiTd4q2tUQCuovPaiPIlq
         ps6KjRB78FN2oBn8ZueGiZWiuf2yo1IGJXs3gypON8sblaRYLfNgqYokWP5Pp+55wmaw
         /f3M4D/pqGuOsX3Qkj5bkTPdYXfKTSC3QuvJo2pS0+4cNs3BELUwIhsek1qYttsB4bK7
         eYobUZNU/SoFSJ7BLNpU1qlfLEJtDg1g9+N2G9l9M3vEqDtXHSPLwhZUes9eMMZIlcW8
         Td1g==
X-Gm-Message-State: AOAM531exIICmgM8FTq+N+p8EfLCrZv66sdTX4xVL0hTQwtsX+mY6wcs
	QsdMnDjJ7zm+S7ZnVaqs9gVpIG3gqkJkFtnHWJ+7L12XF1w=
X-Google-Smtp-Source: ABdhPJxUmF8czU7iphHwnvmd+opZAGdJxclw7TMShSrzesOZgSFaFCI5pWN/J9NAA7irFCfGdMPWQlF5KIbfQ/zCouQ=
X-Received: by 2002:a67:1547:0:b0:32c:f3a1:bdd8 with SMTP id
 68-20020a671547000000b0032cf3a1bdd8mr395879vsv.44.1654100941299; Wed, 01 Jun
 2022 09:29:01 -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: <20220601154142.GA41835@www.zefox.net> <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
In-Reply-To: <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
From: Warner Losh 
Date: Wed, 1 Jun 2022 10:28:50 -0600
Message-ID: 
Subject: Re: Mountroot problems on RPi3/aarch64
To: Mark Millard 
Cc: bob prohaska , "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000007780c05e06563ba"
X-Rspamd-Queue-Id: 4LCvjb1q4jz3jqp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=RBVTrSuC;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e36:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3300
Lines: 86

--00000000000007780c05e06563ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 1, 2022 at 10:17 AM Mark Millard  wrote:

> On 2022-Jun-1, at 08:41, bob prohaska  wrote:
>
> > Since about 05/29 mountroot has been failing on a Pi3 self-hosting
> -current,
> > using a usb mechanical hard disk.
> >
> > Anybody else seen this sort of behavior?
>
> You do not report much context. FreeBSD version? UFS? ZFS?
> And so on.
>
> However, there has been today (for main):
>
> git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity
> checks when reading a superblock
>
> that is for fixing boot problems in UFS contexts. See:
>
>
> https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.=
html
>
> This is for fixes related to the 2022-May-27 change:
>
>         =E2=80=A2 git: 076002f24d35 - main - Do comprehensive UFS/FFS sup=
erblock
> integrity checks when reading a superblock. Kirk McKusick
>

I'd expect these to fix only the boot loader issues, not the mountroot
issues, but it wouldn't hurt to try...  p3 is aarch64 which is UEFI which
had the right MAXPHYS in the boot loader...  though since the change is in
the tree, it wouldn't hurt to try it...

Warner

--00000000000007780c05e06563ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jun 1, 2022 at 10:17 AM Mark =
Millard <marklmi@yahoo.com> =
wrote:
On 2022-J=
un-1, at 08:41, bob prohaska <fbsd@www.zefox.net> wrote:



> Since about 05/29 mountroot has been failing on a Pi3 self-hosting -cu=
rrent,

> using a usb mechanical hard disk.=C2=A0 

> 

> Anybody else seen this sort of behavior? 



You do not report much context. FreeBSD version? UFS? ZFS?

And so on.



However, there has been today (for main):



git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity ch=
ecks when reading a superblock



that is for fixing boot problems in UFS contexts. See:



https://lists.freebsd.o=
rg/archives/dev-commits-src-main/2022-June/006977.html



This is for fixes related to the 2022-May-27 change:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 076002f24d35 - main - Do compreh=
ensive UFS/FFS superblock integrity checks when reading a superblock. Kirk =
McKusick

I'd expect these to fix on=
ly the boot loader issues, not the mountroot issues, but it wouldn't hu=
rt to try...=C2=A0 p3 is aarch64 which is UEFI which had the right MAXPHYS =
in the boot loader...=C2=A0 though since the change is in the tree, it woul=
dn't hurt to try it...

Warner


--00000000000007780c05e06563ba--

From nobody Wed Jun  1 18:04:53 2022
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 0A8F21B64FE9
	for ; Wed,  1 Jun 2022 18:05:06 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b])
	(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 4LCxrK2xp1z3wFT
	for ; Wed,  1 Jun 2022 18:05:05 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yb1-xb2b.google.com with SMTP id f34so4291746ybj.6
        for ; Wed, 01 Jun 2022 11:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Cdazh4td8NXwhnZIi3DaZAMWxA+vOWcDaR0RZdLsYeY=;
        b=J9MkGALGNUXOm6dEUcDVF9q+u/5Yb82k3m4/0TTq49i5hbQ4IetTj8CCmXEBXO0RcB
         Aq4tALQH9niUGO30RDd468CjNsqryEDqkVUCuWKT+ocCvWzfhEcTfbnhI/nS76aIx1TZ
         0GuVBk8g+VR7hzPl5/ixTzCXPVdMRYQ/XFfITyZqzrrcoK6YTQ8c6fDH7TKh5o2Nhfkz
         NWJ4hzM+xfQB+25zmd2saOo+L14xsO38GmIxZ6xwHD6pttV5vY6DqllbnlEWY8ei8CPb
         fyuWfNCcijCVfOw0sdh3zhPuyVkKgAhDJz8OHdjwmyGVNppJa+BO91xuJyg2s9u92Zud
         aQ5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Cdazh4td8NXwhnZIi3DaZAMWxA+vOWcDaR0RZdLsYeY=;
        b=xWFw2y7RbTo1Gw60wFYOZAuZ1O9eReZTY7nCDsQQBqloiYOVhlPzAbzc5KTN3VtwbZ
         5mrvo5xCNG3gStim1LRyrD2q99uuQZLt2PLVycIcwouKMpfunGE4L0WSPRwStjGG+xaY
         NbgTHIqvUEqU8KOIvO0IUsv7ZEtSNQ2EymCn6EUEvgQx+7tWkW5c7F+iMC3LScvQPF60
         zqITYvgeq7CItTZ4mLNG2pKd4iGl1EWO9hhG0V5NP1NoNj3rDBnwEz9JvbnEd/T6T0h8
         dhTwJ2qx/6S2kgOpbScrPMn2TAkK1XyVY75xXFwpVpElz/m2hgZZbzgfCbxlaAWZg4Ll
         JyXw==
X-Gm-Message-State: AOAM5339UFOY8dd5djPCD9Hw4394BcK6gDks0gAqPhxzjNXcyxTFZnXN
	R+jj9pPFZLud42nq4uS1nW6awEHRh2nnkpX51LCimGkAxCNeAQ==
X-Google-Smtp-Source: ABdhPJwTt+Ditr8dmhzYqTwZY0j3M+LCU7CAsWL5AbsYYVC0ofis51N5XQ5cqtm03q9Z9q1yCrpyhnQqV5w2HFqFmuM=
X-Received: by 2002:a25:814b:0:b0:650:db5:6ba with SMTP id j11-20020a25814b000000b006500db506bamr1033760ybm.237.1654106704784;
 Wed, 01 Jun 2022 11:05:04 -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: <20220601154142.GA41835@www.zefox.net> <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 
In-Reply-To: 
From: Robert Montano 
Date: Wed, 1 Jun 2022 11:04:53 -0700
Message-ID: 
Subject: Re: Mountroot problems on RPi3/aarch64
To: Warner Losh 
Cc: Mark Millard , bob prohaska , 
	Free BSD 
Content-Type: multipart/alternative; boundary="0000000000008f31e505e066baa6"
X-Rspamd-Queue-Id: 4LCxrK2xp1z3wFT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=J9MkGALG;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-3.98 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.985];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 FREEMAIL_CC(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3883
Lines: 100

--0000000000008f31e505e066baa6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for your emails!

On Wed, Jun 1, 2022, 9:29 AM Warner Losh  wrote:

>
>
> On Wed, Jun 1, 2022 at 10:17 AM Mark Millard  wrote:
>
>> On 2022-Jun-1, at 08:41, bob prohaska  wrote:
>>
>> > Since about 05/29 mountroot has been failing on a Pi3 self-hosting
>> -current,
>> > using a usb mechanical hard disk.
>> >
>> > Anybody else seen this sort of behavior?
>>
>> You do not report much context. FreeBSD version? UFS? ZFS?
>> And so on.
>>
>> However, there has been today (for main):
>>
>> git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity
>> checks when reading a superblock
>>
>> that is for fixing boot problems in UFS contexts. See:
>>
>>
>> https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977=
.html
>>
>> This is for fixes related to the 2022-May-27 change:
>>
>>         =E2=80=A2 git: 076002f24d35 - main - Do comprehensive UFS/FFS su=
perblock
>> integrity checks when reading a superblock. Kirk McKusick
>>
>
> I'd expect these to fix only the boot loader issues, not the mountroot
> issues, but it wouldn't hurt to try...  p3 is aarch64 which is UEFI which
> had the right MAXPHYS in the boot loader...  though since the change is i=
n
> the tree, it wouldn't hurt to try it...
>
> Warner
>

--0000000000008f31e505e066baa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you for your emails!

On Wed, Jun 1, 2022, 9:29 AM Wa=
rner Losh <imp@bsdimp.com> wrot=
e:


On Wed, Jun 1, 2022 at 10:17 AM Mark Millard <marklmi@yahoo.com=
> wrote:
On 2=
022-Jun-1, at 08:41, bob prohaska <fbsd@www.zefox.net> wrote:



> Since about 05/29 mountroot has been failing on a Pi3 self-hosting -cu=
rrent,

> using a usb mechanical hard disk.=C2=A0 

> 

> Anybody else seen this sort of behavior? 



You do not report much context. FreeBSD version? UFS? ZFS?

And so on.



However, there has been today (for main):



git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity ch=
ecks when reading a superblock



that is for fixing boot problems in UFS contexts. See:



https://list=
s.freebsd.org/archives/dev-commits-src-main/2022-June/006977.html



This is for fixes related to the 2022-May-27 change:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 076002f24d35 - main - Do compreh=
ensive UFS/FFS superblock integrity checks when reading a superblock. Kirk =
McKusick

I'd expect these to fix on=
ly the boot loader issues, not the mountroot issues, but it wouldn't hu=
rt to try...=C2=A0 p3 is aarch64 which is UEFI which had the right MAXPHYS =
in the boot loader...=C2=A0 though since the change is in the tree, it woul=
dn't hurt to try it...

Warner




--0000000000008f31e505e066baa6--

From nobody Wed Jun  1 18:25:56 2022
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 A5E631B68396
	for ; Wed,  1 Jun 2022 18:26:08 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a])
	(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 4LCyJb3wSBz4RgN
	for ; Wed,  1 Jun 2022 18:26:07 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qv1-xf2a.google.com with SMTP id cv1so2048758qvb.5
        for ; Wed, 01 Jun 2022 11:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:content-transfer-encoding:in-reply-to;
        bh=01sPpM56Ocoqx1kEax3KSUHGOioDIP6gFyUUq/AkSng=;
        b=bkIaa/NvCYgb0sg4+ywULhvKxMUffBlSwf3wlT6SP9knRwlRnm7l2vhUE+I8iPMfY7
         7yg21LGgqysGD8R0JqbkcX2X7O40H6uzH3n6/MDsw300oXGXhwFkBYr20s+/0B18Ala6
         v4erEEj/he9GesiLdhdybUn70Fp9lokQ23gpFJLie+GJ3woXr8zvpLTi/9eDQxMw6MPH
         MTfWiTNAK+o9UJAYYI15UjEsYbprELtsQhUUPX05S5GSNOJpCGUeAsQbvPlgBIk23soS
         6a5p/dGtpD85OiwkAhN2O/HNvyuugIXTdngM6rzhsvTaOdPvG/GhJ4m3L9ZCP449Uqon
         ZRbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition
         :content-transfer-encoding:in-reply-to;
        bh=01sPpM56Ocoqx1kEax3KSUHGOioDIP6gFyUUq/AkSng=;
        b=lSuwISldxk8DIrOpD1/uOT+7z7ZJldWgMD6zhvsiumOsMctR2rFsZzZQTjsgVLFB5f
         m2HQp/e5btkU43Cmix8vEqsKKVKKW+jXSHDoER2gJlkp/HNbjKPDOY9XuJMUv8r0CYVv
         NXzLgJdp4VbBJnD1DIczEmtO0OsRX/q+1NTz/1afsE70416gDu0W6yNSgpgZIAnB+Tns
         JuvDB7i7B0wApEzx9RGWxFcwu7DZ/HKfFdTlaVk5J7wnlRIsUjLMlUjLnF0GTJRAQCP2
         pBmPslvyKcUsVX74b0Zt7BawszIUDV91DR5wfwU7onL1Qm4IBXNwVDjQnl+enLBNWYUu
         ezCg==
X-Gm-Message-State: AOAM5318wq7ds2mlJyrxUrvyuQuvAm09G760zLCp6/FywLIeKSKj+9Mr
	1dn0VOfVa7SFDc7vVmk7K38=
X-Google-Smtp-Source: ABdhPJy9FSNliBSzR6MPOVRF4Jdc4eqa6zmD4qz0f8Gq+06XnRXi7wg88+wuIeuhjrsxUGwnMVhADQ==
X-Received: by 2002:a05:6214:5002:b0:465:d376:1eb7 with SMTP id jo2-20020a056214500200b00465d3761eb7mr2692359qvb.129.1654107960218;
        Wed, 01 Jun 2022 11:26:00 -0700 (PDT)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id g20-20020ac85814000000b002f3e153f47csm1741423qtg.0.2022.06.01.11.25.58
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 01 Jun 2022 11:25:59 -0700 (PDT)
Date: Wed, 1 Jun 2022 14:25:56 -0400
From: Mark Johnston 
To: Warner Losh 
Cc: Mark Millard , bob prohaska ,
	"freebsd-arm@freebsd.org" 
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: 
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@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-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4LCyJb3wSBz4RgN
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="bkIaa/Nv";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.70 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 MID_RHS_NOT_FQDN(0.50)[];
	 FREEMAIL_CC(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1421
Lines: 37

On Wed, Jun 01, 2022 at 10:28:50AM -0600, Warner Losh wrote:
> On Wed, Jun 1, 2022 at 10:17 AM Mark Millard  wrote:
> 
> > On 2022-Jun-1, at 08:41, bob prohaska  wrote:
> >
> > > Since about 05/29 mountroot has been failing on a Pi3 self-hosting
> > -current,
> > > using a usb mechanical hard disk.
> > >
> > > Anybody else seen this sort of behavior?
> >
> > You do not report much context. FreeBSD version? UFS? ZFS?
> > And so on.
> >
> > However, there has been today (for main):
> >
> > git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity
> > checks when reading a superblock
> >
> > that is for fixing boot problems in UFS contexts. See:
> >
> >
> > https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.html
> >
> > This is for fixes related to the 2022-May-27 change:
> >
> >         • git: 076002f24d35 - main - Do comprehensive UFS/FFS superblock
> > integrity checks when reading a superblock. Kirk McKusick
> >
> 
> I'd expect these to fix only the boot loader issues, not the mountroot
> issues, but it wouldn't hurt to try...  p3 is aarch64 which is UEFI which
> had the right MAXPHYS in the boot loader...  though since the change is in
> the tree, it wouldn't hurt to try it...

At least in my case (a filesystem created with makefs), one of the bugs
fixed by that commit caused mountroot to fail, but the loader was fine.

From nobody Wed Jun  1 20:40:41 2022
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 914941B45787
	for ; Wed,  1 Jun 2022 20:40:53 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f])
	(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 4LD1J44KMvz4fqV;
	Wed,  1 Jun 2022 20:40:52 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-2f83983782fso31682427b3.6;
        Wed, 01 Jun 2022 13:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=KBrff/MWTdeYkZoy9ETOOPG4n9Q6jljkrivUOFsBV3g=;
        b=aaKflpw3fWyANSNs/ppL3H8EU4MSzJN43xzTWFQFaEBKp7/DSgDT1YJKTS+njJTwnM
         AD35aXFek/avjd8p/j8JN5H7CoR1KXqpluSMQILvK2pAF+fskad3yS0Y0rMbzItyqcaR
         4hmfJgNU/uIExG7nA8EibmrJGk8Hqg/SRQvFPuw/DxZCVFYDhyVRh0a6KCXemAQDcPry
         7/7+QWUzN981ZGAPS/Iiijd/ZtnQ1fXvLOnJi0CaP2qYmLV3JqQfQrHm9fEclQMGfSm0
         /VnaNE7hHmsKHPCNIo+LcOMjSLl4F59n3Fmp37504R5PDB+kVJufTKPCEfoL5TIQNvE9
         Ib0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=KBrff/MWTdeYkZoy9ETOOPG4n9Q6jljkrivUOFsBV3g=;
        b=immXL3dfHxf2oS2nP5K39jQR1WImikL5pQetoP9YSqpDHlSfN2d3gxwtDjdU7Mc31J
         Zv+8IsaECn4/ndwDd9jINWS62Xsa/x2NW25D9+9cZjaKdEwul/QdfLxyO4eqBL3efGZx
         FkgFJ7yLsWERhd1w34Ki2p9JXsXLsnTOKLSWi5jWLcrNCHM6EKLvvEZ/MayhYn6ZDuh2
         MP1dv41EAXDZTxRDAI0I/wtKvj1HObGSNhovb9MCowuscotQf6PmjxFTfwB0ulPP3lBz
         48VYnFI0oX263T9nC671ZtUmd+WPsfqLe2siHaQGhnIZ8bG0L1nEFaFxRCKsIgj7T9Rf
         3WFQ==
X-Gm-Message-State: AOAM531kM1pufcYc57uJEPFQ0sGmq0OXXerOMYqDs3zgyG38xIJk1ncL
	oVabi5E1SaqKEQS5W0sw5r0FREwR3p8xawI+1hH4xApp6rXywg==
X-Google-Smtp-Source: ABdhPJwdvBcEghFdtMztQAO8x4FYQj15N6w87AIQP9A/eLo7ng6AGoN5MZc5deRGnOZSQLDdwTWz678GsNFV/1Gbv8w=
X-Received: by 2002:a81:1989:0:b0:30c:214e:f0ea with SMTP id
 131-20020a811989000000b0030c214ef0eamr1550514ywz.517.1654116052127; Wed, 01
 Jun 2022 13:40:52 -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: Robert Montano 
Date: Wed, 1 Jun 2022 13:40:41 -0700
Message-ID: 
Subject: Re: serial console and comconsole in FreeBSD arm64
To: Souradeep Chakrabarti 
Cc: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org" , 
	Wei Hu 
Content-Type: multipart/alternative; boundary="000000000000b452f705e068e766"
X-Rspamd-Queue-Id: 4LD1J44KMvz4fqV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=aaKflpw3;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-3.38 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112f:from];
	 NEURAL_HAM_SHORT(-0.38)[-0.383];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6487
Lines: 178

--000000000000b452f705e068e766
Content-Type: text/plain; charset="UTF-8"

Thx for the help

On Mon, May 30, 2022, 2:31 AM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi,
>
>
>
> I am trying to access virtual serial console via Putty and in 13.0 it is
> not working
>
> for both x86 and arm64.
>
>
>
> It is very easy to reproduce:
>
> 1) In Windows Hyper-V set a  FreeBSD 13.0 VM
>
> 2) Use Powershell in Admin privileged mode and run following:
>
>                 Set-VMComPort -VMName  -number 1 -path
> \\.\pipe\Testpipe
>
> 2) In another Powershell with Admin privilege run following:
>
>                 Set-VMFirmware -VMName   --ConsoleMode COM1
>
> 3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial
> mode.
>
> No output will be seen on putty.
>
>
>
> But the same works in FreeBSD 12.3 and Putty gets the output from EFI
> loader for both x86 and arm64.
>
> But during kernel booting the console output does not come in Putty, it
> only comes in vmconnect.exe.
>
> Like below :
>
>
>
> Loading kernel...
>
> /boot/kernel/kernel text=0x931f24 data=0x187450 data=0x0+0x2d095e
> syms=[0x8+0x138120+0x8+0x124824]
>
> Loading configured modules...
>
> can't find '/boot/entropy'
>
> can't find '/etc/hostid'
>
> No valid device tree blob found!
>
> WARNING! Trying to fire up the kernel, but no device tree blob found!
>
> EFI framebuffer information:
>
> addr, size     0xe0000000, 0x800000
>
> dimensions     1024 x 768
>
> stride         1024
>
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<
>
>
>
> After this log is not coming in Putty in 12.3 for both x86 and arm64.
>
>
>
>
>
>
>

--000000000000b452f705e068e766
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thx for the help

On Mon, May 30, 2022, 2:31 AM Souradeep C=
hakrabarti <schakrabarti@m=
icrosoft.com> wrote:











Hi,


=C2=A0


I am trying to access virtual serial console via Put=
ty and in 13.0 it is not working



for both x86 and arm64.


=C2=A0


It is very easy to reproduc=
e:


1) In Windows Hyper-V set a=
=C2=A0 FreeBSD 13.0 VM


2) Use Powershell in Admin =
privileged mode and run following:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set-VMComPo=
rt -VMName <vm_name> -number 1 -path
\\.\pipe\Testpipe


2) In another Powershell wi=
th Admin privilege run following:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set-VMFirmw=
are -VMName <VM name>=C2=A0 --ConsoleMode COM1


3) start the VM and open pu=
tty to connect the 
\\.\pipe\Testpipe in serial mode.


No output will be seen on p=
utty.


=C2=A0


But the same works in FreeB=
SD 12.3 and Putty gets the output from EFI loader for both x86 and arm64.


But during kernel booting t=
he console output does not come in Putty, it only comes in vmconnect.exe.



Like below :<=
/p>

=C2=A0


Loading kernel...=



/boot/kernel/kernel text=3D=
0x931f24 data=3D0x187450 data=3D0x0+0x2d095e syms=3D[0x8+0x138120+0x8+0x124=
824]


Loading configured modules.=
..


can't find '/boot/e=
ntropy'


can't find '/etc/ho=
stid'


No valid device tree blob f=
ound!


WARNING! Trying to fire up =
the kernel, but no device tree blob found!


EFI framebuffer information=
:


addr, size=C2=A0=C2=A0=C2=
=A0=C2=A0 0xe0000000, 0x800000


dimensions=C2=A0=C2=A0=C2=
=A0=C2=A0 1024 x 768


stride=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 1024


masks=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff0=
00000 <<<<


=C2=A0


After this log is not comin=
g in Putty in 12.3 for both x86 and arm64.


=C2=A0


=C2=A0




=C2=A0









--000000000000b452f705e068e766--

From nobody Wed Jun  1 20:41:01 2022
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 362B51B45BB5
	for ; Wed,  1 Jun 2022 20:41:13 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134])
	(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 4LD1JS1Zdzz4gCv;
	Wed,  1 Jun 2022 20:41:12 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-30c1b401711so31897487b3.2;
        Wed, 01 Jun 2022 13:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=0K13bUEJp5A2LsJiiWp7WqeTr2CrJccE2SojA7sSP+w=;
        b=RmnCDf18AmoRBHsIPzsosN4OWRo6syD35ZvnjinQdEzyvN1JBbFI5PQvo08u+GapUx
         jWHbSZcGFA2jSShtHbPw93iVlJjULp19LAfFmx40e64q28fi6G/4AF6Rto114BDP4IpZ
         x9rVPvfOVAOkxVrQeNBtNMFDN/UwISMyIR4aDc1278mGIhpqs/0s9IJ9LAhFZISCDl95
         41VWD6FlEjkZ81kWHngZvAtwT+hay8n/BeCv9ZxXLxV0LjPbUV219cQZ/fbagpyHw+R0
         rdQhaGcxOTphBGvgSV2L0R6FURQ54yqsnhSQ+sOiCe2yTil61tvSDhF/nLjwjFOdw1og
         uRUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=0K13bUEJp5A2LsJiiWp7WqeTr2CrJccE2SojA7sSP+w=;
        b=IZoQpHQOQLZcuDMUzQnlj+Ab2jYUrXCdxA7iSxNbjZTjeKGNa78c2gwIQsYK4ly/Dk
         8YJzsWZUwtrS6DVsPp7E/s+0jUPVJnCej3bGLYQ2PwDsl4PFL9x8N/YLJjIVYOKFT2QV
         nzJXp8jgMffkWCVcybBcimJ2FuuI6D36gJVMWTPlHUjAEt2leeligmA7slC39GG86mH1
         qd+3hjlH8AxVoXxbqVed7Uwq8TcOSwmE0kfb1COJr1ngpdsXViDNqGXKKCdB4bp8CBzq
         u5qYpaZlRTeY4zcW/mRx0CRHKvoU5JmPGWb2vd0TnwOdI38MtKDwosoVSrTRJ5LQAQMs
         ztTw==
X-Gm-Message-State: AOAM530dj+7Vm2AP1yen0p1e5xGFYE2SBS66O4SkG8P1qmNR0d69Qjfs
	gWasIFefigTgZjiIRRb5ZZ2AbXpkgpZoeRlye32QRWQMuNjFyQ==
X-Google-Smtp-Source: ABdhPJw8fh8tKpm5d8YGe0qaWtKror1efu8mQPKPiIHBM4FPPMMy9lFYoi6+uSoRFX3YtdvzQtL/XgXybWN3EMypRZI=
X-Received: by 2002:a81:6ad4:0:b0:30c:45af:ae3f with SMTP id
 f203-20020a816ad4000000b0030c45afae3fmr1553921ywc.55.1654116071603; Wed, 01
 Jun 2022 13:41:11 -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: Robert Montano 
Date: Wed, 1 Jun 2022 13:41:01 -0700
Message-ID: 
Subject: Re: serial console and comconsole in FreeBSD arm64
To: Souradeep Chakrabarti 
Cc: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org" , 
	Wei Hu 
Content-Type: multipart/alternative; boundary="000000000000dd817c05e068e8c4"
X-Rspamd-Queue-Id: 4LD1JS1Zdzz4gCv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=RmnCDf18;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-3.38 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1134:from];
	 NEURAL_HAM_SHORT(-0.38)[-0.380];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6571
Lines: 180

--000000000000dd817c05e068e8c4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think I'm sunk =F0=9F=98=82

On Mon, May 30, 2022, 2:31 AM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi,
>
>
>
> I am trying to access virtual serial console via Putty and in 13.0 it is
> not working
>
> for both x86 and arm64.
>
>
>
> It is very easy to reproduce:
>
> 1) In Windows Hyper-V set a  FreeBSD 13.0 VM
>
> 2) Use Powershell in Admin privileged mode and run following:
>
>                 Set-VMComPort -VMName  -number 1 -path
> \\.\pipe\Testpipe
>
> 2) In another Powershell with Admin privilege run following:
>
>                 Set-VMFirmware -VMName   --ConsoleMode COM1
>
> 3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial
> mode.
>
> No output will be seen on putty.
>
>
>
> But the same works in FreeBSD 12.3 and Putty gets the output from EFI
> loader for both x86 and arm64.
>
> But during kernel booting the console output does not come in Putty, it
> only comes in vmconnect.exe.
>
> Like below :
>
>
>
> Loading kernel...
>
> /boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e
> syms=3D[0x8+0x138120+0x8+0x124824]
>
> Loading configured modules...
>
> can't find '/boot/entropy'
>
> can't find '/etc/hostid'
>
> No valid device tree blob found!
>
> WARNING! Trying to fire up the kernel, but no device tree blob found!
>
> EFI framebuffer information:
>
> addr, size     0xe0000000, 0x800000
>
> dimensions     1024 x 768
>
> stride         1024
>
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<
>
>
>
> After this log is not coming in Putty in 12.3 for both x86 and arm64.
>
>
>
>
>
>
>

--000000000000dd817c05e068e8c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think I'm sunk =F0=9F=98=82

On Mon, May 30, 2022, 2:=
31 AM Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:











Hi,


=C2=A0


I am trying to access virtual serial console via Put=
ty and in 13.0 it is not working



for both x86 and arm64.


=C2=A0


It is very easy to reproduc=
e:


1) In Windows Hyper-V set a=
=C2=A0 FreeBSD 13.0 VM


2) Use Powershell in Admin =
privileged mode and run following:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set-VMComPo=
rt -VMName <vm_name> -number 1 -path
\\.\pipe\Testpipe


2) In another Powershell wi=
th Admin privilege run following:


=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Set-VMFirmw=
are -VMName <VM name>=C2=A0 --ConsoleMode COM1


3) start the VM and open pu=
tty to connect the 
\\.\pipe\Testpipe in serial mode.


No output will be seen on p=
utty.


=C2=A0


But the same works in FreeB=
SD 12.3 and Putty gets the output from EFI loader for both x86 and arm64.


But during kernel booting t=
he console output does not come in Putty, it only comes in vmconnect.exe.



Like below :<=
/p>

=C2=A0


Loading kernel...=



/boot/kernel/kernel text=3D=
0x931f24 data=3D0x187450 data=3D0x0+0x2d095e syms=3D[0x8+0x138120+0x8+0x124=
824]


Loading configured modules.=
..


can't find '/boot/e=
ntropy'


can't find '/etc/ho=
stid'


No valid device tree blob f=
ound!


WARNING! Trying to fire up =
the kernel, but no device tree blob found!


EFI framebuffer information=
:


addr, size=C2=A0=C2=A0=C2=
=A0=C2=A0 0xe0000000, 0x800000


dimensions=C2=A0=C2=A0=C2=
=A0=C2=A0 1024 x 768


stride=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 1024


masks=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff0=
00000 <<<<


=C2=A0


After this log is not comin=
g in Putty in 12.3 for both x86 and arm64.


=C2=A0


=C2=A0




=C2=A0









--000000000000dd817c05e068e8c4--

From nobody Wed Jun  1 21:08:14 2022
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 784EE1B4AD67
	for ; Wed,  1 Jun 2022 21:08:27 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020027.outbound.protection.outlook.com [52.101.128.27])
	(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 4LD1vs6v23z4jdJ;
	Wed,  1 Jun 2022 21:08:25 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=HKvCIzUfE7X1iuVp9jtCIBo1SWqFAlHHmh1WXWRScHJx+HzFYgJdUC4GGX0F2EVQS/cq0UUNqoPHM7HRExtZLQvq2UZUpVi3fa3LaQSwLDwLH+NXoWNlOfngvZRmxSM6roiZqQeksEDCY9Mmzrnp6MmqXpgjGsdeit3mqnP4Kbp49377vvrg3x+07iDFFqyexWsRz08xRGkTecaqN/vcQVBKSlUW6H4cDswhlph4XOYaV8AkAm83AazSELHmN+Bn06FZFVp+JrSaNbKSO9/FKhsDmCXCrVf4ExczBwady+km/R+npCSKQzWd2hrnXpshjkRtrd2ZYeA3UkktXn2y1w==
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=+03jfZnW3h7R/qhhalVyXCg8GJSfjxF2QvaEehsMakk=;
 b=DAXob/+nA8fPa2uR3t/C3zucXLwAdTeAOgYPU2zXjTmdghV98F2RZ8GebGfCo3MSrdh1HYmCCkXLT3tbvGfq3mazxStSB64ECFHovFx/Otx35H5JsoeDwduNZBTo7lpllFEygLW7gvAQv4ZC/GBx+i/j5GtvEGvws2+4N2YAVw/Xk/CO6gRBs5i+KCQ0Wdgj1KATvO7kPHlAUkQ2WRHfN3MzdBXpAE9Ggxx8Lg/0L2qDIhVSxBG3zaJgPZqvp39Ha7h9tXEnJ4ExeQ7CqAh86fEvTnIj+u8hRzLPhQGmmYci0r7P67qQnV8f3zVaOa9/8hb7SgNPqxjCHMmm8xJDsg==
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=+03jfZnW3h7R/qhhalVyXCg8GJSfjxF2QvaEehsMakk=;
 b=UI/99LyVxm1J/ydzwV+oyuhS0yTJR7ayS3K1YOJxMb2iP/KBvphTYJFpW3XfpkjnX8DDuR6GDiSjJqmvUb0ji8GFwSuNeKyZkQ7FEjZizw6TXme3+c1Q0bPRnRJQ/we7/QxutCAo7XRMmtdxxUYcSCFD4nFf+E9SXC+rgfjJMDE=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PSAP153MB0424.APCP153.PROD.OUTLOOK.COM (2603:1096:301:32::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.4; Wed, 1 Jun
 2022 21:08:14 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826%6]) with mapi id 15.20.5332.004; Wed, 1 Jun 2022
 21:08:14 +0000
From: Souradeep Chakrabarti 
To: Warner Losh 
CC: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	, Wei Hu 
Subject: RE: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Topic: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQAJq/UAAHNLPjA=
Date: Wed, 1 Jun 2022 21:08:14 +0000
Message-ID:
 
References:
 
 
In-Reply-To:
 
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=c13abc98-acd1-400b-b195-bcc4d8df62ef;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=2022-06-01T21:01:11Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 32634d9b-0cec-496d-3038-08da4412d79a
x-ms-traffictypediagnostic: PSAP153MB0424:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 Kbt7EZBwK5SB2eRVGLCGTT/57xAvixgRIQ3IDvNXb/9xWp/CnvQ0RUBQJPo3uZO6+aQ7C6h5K8EaJPrtUh8mlWKmW8ZAK57n4qcxuAhnQTE7hKqSRIYewQ57gxQesSgLNAGM5yHvJbdz24s1naZZeV8JwJD0UeC03ipv4Fki9pSSB+PrLXFOsdXekBuVTQayCo9fD4GBO8KhH9J4p2/RGUKIVqAmpzIU6VQvqH6BcTWKD+eE8Cs1NrlQDXHcze4hJto8Vq1Wi0gTOxvRIUjqntpEmuAistPhYqOEVojCCN/K+5j8hco3qag3WXp6PHN4qf884yVuYi1AvDRrfWILAIp8lJvYMjrMJhfQ6M5OY2tdROi+Ua6UYmPYyiLALomwyddXP8qelEx60Q8F8jyzxNCIjEj+hQmRjw/DLKLAxqhOYAGtUurlTSVrELm3WsNwLsoAf/eM4LmETh/TwAJIfGC4UHbU+cmMOWYSJ8Eq5y6oEd1C4qTi+licns8D1QDsmJkwllgwyF7r0JL0Sm6T5JqUi+nP60I6lx9MN8z2HXMMY4T9EaeJaLDiLSGvvflep/sZksDRtWneJqE9LlMdMpXvsfcPzaDdyTrRqX8Hv017iaR1rZtz1ysnIlwdn0nhmPdwMLrf5gvMtMphXS4e0VbOlbXWLi6VO8TxKl7pn12wv+LE5J66y+n6Byxs/BNKXf1gXbo9IO+lxmSzegn7BS8umjUQn97aPov2zcUJoIU5tFTNAFtoeutRqxVDeiPfQM9er+GNXWeTqz9VJKx9gixkucAOUoc4+h8QPXHrL9A=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(38100700002)(4326008)(7696005)(33656002)(6506007)(8676002)(64756008)(66946007)(54906003)(76116006)(66476007)(66446008)(66556008)(107886003)(186003)(6916009)(2906002)(8990500004)(122000001)(52536014)(71200400001)(38070700005)(316002)(10290500003)(55016003)(86362001)(82950400001)(9686003)(508600001)(82960400001)(26005)(83380400001)(5660300002)(8936002)(9326002)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?TWp6bEIxL3NaR2I4TW85a01yVjRROXdjR3daSzJtWnRXNnFmM0p1VzkreWlR?=
 =?utf-8?B?bDRjRFVWZVlmMnBOYldta2F0MDNLTytMTFhyZ2pmK0MyUVhYN1pLMzduYTNG?=
 =?utf-8?B?ZzJMMEFiV1hGY3FZWEcxbmNRdzYwcmxKYUVvUW9Ua1ZPZHJaMElWSnliMStP?=
 =?utf-8?B?UG1veHVlS3FLVFJCeDFhWkZIQnlyakgzWjNZRGVKTDc4SmYxN29lKzBIM1d2?=
 =?utf-8?B?Wk90QmdBY3EydjMwZ2pxVzMxQ3JLeG1DV2gyZGI1bHdpNEZLQk5jdkRJNVNq?=
 =?utf-8?B?dGMxeTR5SXVXZjhxakM4TTBvaDNRRTdoZXc1M2ZSQ0JYbUcyUVZTWVp2blRZ?=
 =?utf-8?B?MmJFdENFdWFMNmRGbCsvZXAvdktDNjBFUUFxTldmb3NRckdWdlN6V3hTemN5?=
 =?utf-8?B?L0k5KzV0eVdSOXU3TEMzU1BvbWdaaXltbG1QMzZES21RaitYbUNYdWpNODcx?=
 =?utf-8?B?d0hWUHZkbSthMlRYNFFkQkovWmlwNzhxN0I4dHE1NWJ0UjVIZ3ZIOUVmcUgv?=
 =?utf-8?B?aG1oai9OQXZuWFJNUWtobDcybU1kY1h4dXFUbUlIdmdlYVJvWWR4TVFrNGpQ?=
 =?utf-8?B?bi9vdGlsUVl3OENsbUtwVkViZHFNdHlJOGp6Q0IyV0E0ZE5IVHYvRWo0Nzl3?=
 =?utf-8?B?U3JCYWs3b0g2Wjc0SkdFa1N2M1ZjbVczTHpvZDcrSkNuMDhsamlWZzd6MzlM?=
 =?utf-8?B?OXUycTg0bnhIbzhIdjFjNzV5YUZkV2J2NDdBYStIV05YRXBEOWRINldwOTVm?=
 =?utf-8?B?RkpNUFdQTUVhQXh5RzlpSnJ1SWNyNkZTMVdRek9VWWNOa09aNkc2NGpocy9R?=
 =?utf-8?B?WVRXNWM2OGYrakJkdmE5MnFQVmtZdnFWNEZ5UlYyZlRVdTZ4Y1loRzQyK3V5?=
 =?utf-8?B?OFhzRmtjQStXbXJPSW05UGZia1BxSWNLZ3d3Z0orRkl3eHNNbUpmancxL3NC?=
 =?utf-8?B?ZmpqdTJnelBSNWwyUHJoME5uaWtDWHVVT2JDUStad0JKNHkxcnZnd2U3Y1Fu?=
 =?utf-8?B?b3VMbkU0TnhQQkIySFFUc2RFTitFYmRIZkZTUXZPUDBlbkEzRDVlQjhYWHpR?=
 =?utf-8?B?bGZ2dFd3UStiUGhEMUhjSG9hWmcyaG9VYnVjRVlYSlhoTXlNdHFDN29lbExv?=
 =?utf-8?B?aWl0b1pDYzRuNzd4ZGxWNDdjaXJJeEZha2tLNUNlTjZOQU8vQktEQ0cxSHhD?=
 =?utf-8?B?alpMTEYvanhXWFZGV2h1MmRzOVhYSHhXZnN6Y0huNDluYXRORjNGUC9SMDNN?=
 =?utf-8?B?aEExZGxldmVXTVBDTGpOeFhJTmowbkx0a01EeTRHMFZMempzL2VUUjlTRlhQ?=
 =?utf-8?B?QVdLR0twdVZUdmZCU3k4ck9nYVpZb1hNMDlxU0lMeVJWMmJXcDlqYUplS0JW?=
 =?utf-8?B?NTllbXBDZC9mOWJkR2N4OWxNSGxkeEQrUlIvclA3Vnl5U2pIZ2c1cjNtN0dT?=
 =?utf-8?B?cnpTK1YybGRiTUUxd1laU0Z2cVpudjFldFdzNTR2VkFDNkp1NTBpeHVMVEIz?=
 =?utf-8?B?RHpZRnEwQ0J1bE96TTY4TGttbyszWXVzbnpZNGp1cXdVSVNOSlJUbTdaZGhG?=
 =?utf-8?B?a0NaamsrMHR6RW1DeEpEME9kSFhNV0RNZXVJeTIyS0hVdFNXdVBUbmVhTzlp?=
 =?utf-8?B?NzBjUGtBcnNmZXM0M3RmelNVTUxaKzhyWG1mUURXNDB3TDh5N1o4TnNHZXh6?=
 =?utf-8?B?ZktjZmhIZFV6VHJ2dExLNVYyYmFYM1haZkQwOXpxTnhTTEpqdGRtZW9BNUt0?=
 =?utf-8?B?andnTUlIT0dXZE1uWHNrd1hXa0xjNDVwcVBubkRsdUI5VEVOdE5wdUcxaE5q?=
 =?utf-8?B?VU5GZDZiSm0yZzljaFhlYTNnVm1ad2dma09MUUlHV1hoamN6Zk9aY3BMM0tr?=
 =?utf-8?B?bkhvbkszbVAzZmNNREhMd2FpY3FqelhoM0dSMXJJVWNiWlZueEt1cnlUcER0?=
 =?utf-8?B?L0pGN0V4UXAvWDBvVXI4aXRmY2RKbTlrRWZkUG50Szg4MVZZVVN5NFhEWGhJ?=
 =?utf-8?B?bjB5OVd6UjRoUXkreklnSlR1dGxxZys2UHYxVWZDMnFlZzdUK011NkE5aXdu?=
 =?utf-8?B?TWlOYkt6OGhDUlVXUGd0SUFTcG1kNjRWbG4zVzd3cExMejJvVkZlNnpmS3pT?=
 =?utf-8?B?RGJuckh3L3k5cTQ4a0N0bzJySTk1cVBBeFZNYlZPK3pZUmh4S3Q5UEZUS3pO?=
 =?utf-8?B?ZHM5cU5EVnliRmFCb1FWVEZTUVNHbjRvZ3hRQXJVSGROdVZPOS9tQWJGRGVT?=
 =?utf-8?Q?RUqoPvbPEihHYLnKlzGHCtlKDxO0pWuVdlfFFKh1Tk=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB05363C63A79375845D5CD613CCDF9PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 32634d9b-0cec-496d-3038-08da4412d79a
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2022 21:08:14.3184
 (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: kXa1aE0cuqqzau/4PAwnA+uqZCB3BQcpzxpyTBBeB6LhzmmPtAeNPkn7ZSRd4as/olb4+TmvXXolzVYJSbUlwO6MnVrBNs3p9x0XB0KN6tw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0424
X-Rspamd-Queue-Id: 4LD1vs6v23z4jdJ
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="UI/99LyV";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.27 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.88 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 NEURAL_HAM_SHORT(-0.98)[-0.983];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 17059
Lines: 229

--_000_PSAP153MB05363C63A79375845D5CD613CCDF9PSAP153MB0536APCP_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgV2FybmVyLA0KVGhhbmtzIGZvciBwb2ludGluZyBib290X211bHRpY29ucywgYW5kIHllcyBp
dCBoYXMgc29sdmVkIHRoZSBwcm9ibGVtIG9mIEZyZWVCU0Qga2VybmVsIGJvb3QgbG9ncw0Kbm90
IGNvbWluZyBpbiBQdXR0eSBpbiBib3RoIHg4NiBhbmQgYXJtNjQuDQoNClJlZ2FyZGluZyBGcmVl
QlNEIDEzLCAgeWVzIGxvYWRlci5lZmkgbG9ncyBhcmUgbm90IGNvbWluZyBpbiBQdXR0eSBtb3N0
bHkgYmVjYXVzZSBvZiBFRkkgZ2Z4IHVzYWdlDQp3aGljaCBpcyBub3Qgc3VwcG9ydGVkIGluIFB1
dHR5Lg0KDQpOb3cgd2UgY2FuIG92ZXJjb21lIGl0IGluIHg4NiBieSBzZXR0aW5nIHNldCBjb25z
b2xlPeKAnWNvbWNvbnNvbGXigJ0sIGFzIGl0IGlzIHVzaW5nIHRoZSBkaWZmZXJlbnQNCnVhcnQg
aW1wbGVtZW50YXRpb24gb2YgY29tY29uc29sZSBvZiBsb2FkZXIsIHdoaWNoIGlzIG5vdCB0aGUg
c2FtZSBpbiBhcm02NC4gVGhlIGltcGxlbWVudGF0aW9uDQpvZiBjb21jb25zb2xlIGluIGFybTY0
IGxvYWRlci5lZmkgaXMgbm90IHN1cHBvcnRlZCBpbiBIeXBlci1WIGxvb2tzIGxpa2UuIEFzIEh5
cGVyLVYgb25seSBzdXBwb3J0cw0KdHR5QU1BMCBmb3Igc2VyaWFsIGNvbnNvbGUgaW4gQVJNNjQg
YnV0IHN1cHBvcnRzIHVhcnQgaW4geDg2Lg0KDQpSZWdhcmRpbmcgQ29uT3V0LCBJIGhhdmUgZ290
IGl0IGZyb20geDg2IEZyZWVCU0QxMywgKGFzIGFybTY0IGlzIGluIHRoZSBwcm9jZXNzIG9mIGJy
aW5naW5nIHVwIGFuZA0KQ29uT3V0IGlzIHNhbWUgZm9yIGFybTY0IGFuZCB4ODYsIGNvbmZpcm1l
ZCBieSB1c2luZyBlZmlzaGVsbCBiaW5hcnkgYW5kIExpbnV4IHNoZWxsKS4NCg0KZWZpdmFyIC0t
ZGV2aWNlLXBhdGggOGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhjLUNvbk91dA0K
OGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhjLUNvbk91dA0KOiBBY3BpRXgoVk1C
dXMsLCkvVmVuSHcoOWIxN2U1YTItMDg5MS00MmRkLWI2NTMtODBiNWMyMjgwOWJhLDAyNzgwYWRh
NzdlM2FjNGE4ZTc3MDU1OGViMTA3M2Y4YzdlMDIwNTY2MjgwY2U0ZGFlYjc1MjBjN2VmNzYxNzEp
DQoNClRoYW5rcyAmIFJlZ2FyZHMsDQpTb3VyYWRlZXANCg0KT24gTW9uLCBNYXkgMzAsIDIwMjIs
IDM6MzEgQU0gU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNv
bTxtYWlsdG86c2NoYWtyYWJhcnRpQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+SGksDQo+Pkkg
YW0gdHJ5aW5nIHRvIGFjY2VzcyB2aXJ0dWFsIHNlcmlhbCBjb25zb2xlIHZpYSBQdXR0eSBhbmQg
aW4gMTMuMCBpdCBpcyBub3Qgd29ya2luZw0KPj5mb3IgYm90aCB4ODYgYW5kIGFybTY0Lg0KPj4N
Cj4+SXQgaXMgdmVyeSBlYXN5IHRvIHJlcHJvZHVjZToNCj4+MSkgSW4gV2luZG93cyBIeXBlci1W
IHNldCBhICBGcmVlQlNEIDEzLjAgVk0NCj4+MikgVXNlIFBvd2Vyc2hlbGwgaW4gQWRtaW4gcHJp
dmlsZWdlZCBtb2RlIGFuZCBydW4gZm9sbG93aW5nOg0KPj4gICAgICAgICAgICAgICAgU2V0LVZN
Q29tUG9ydCAtVk1OYW1lIDx2bV9uYW1lPiAtbnVtYmVyIDEgLXBhdGggXFwuXHBpcGVcVGVzdHBp
cGUNCj4+MikgSW4gYW5vdGhlciBQb3dlcnNoZWxsIHdpdGggQWRtaW4gcHJpdmlsZWdlIHJ1biBm
b2xsb3dpbmc6DQo+PiAgICAgICAgICAgICAgICBTZXQtVk1GaXJtd2FyZSAtVk1OYW1lIDxWTSBu
YW1lPiAgLS1Db25zb2xlTW9kZSBDT00xDQo+PjMpIHN0YXJ0IHRoZSBWTSBhbmQgb3BlbiBwdXR0
eSB0byBjb25uZWN0IHRoZSBcXC5ccGlwZVxUZXN0cGlwZSBpbiBzZXJpYWwgbW9kZS4NCj4+Tm8g
b3V0cHV0IHdpbGwgYmUgc2VlbiBvbiBwdXR0eS4NCj5Ob3QgZXZlbiBmcm9tIHRoZSBib290IGxv
YWRlcj8gVGhhdCBzdXJlIHNvdW5kcyBsaWtlIHRoZSBhdXRvbWF0aWMgZmFsbGJhY2sgdG8gc2lt
cGxlIHRleHQgb3V0cHV0IGlzbid0IGhhcHBlbmluZy4NCj4NCj5XaGF0IGRvZXM6DQo+JSBzdWRv
IGVmaXZhciAtLWRldmljZS1wYXRoIDhiZTRkZjYxLTkzY2EtMTFkMi1hYTBkLTAwZTA5ODAzMmI4
Yy1Db25PdXQNCj50ZWxsIHlvdT8gKE9yIHJ1biBhcyByb290IGlmIHlvdSBkb24ndCBsaWtlIHN1
ZG8pLg0KPg0KPlRoZSBib290IGxvYWRlciBncmV3IGEgbm9uLW9wdGlvbmFsIGdyYXBoaWNzIG1v
ZGUgdGhhdCdzIGRpc2FibGVkIHdoZW4gdGhlIGJvb3QgY29kZQ0KPmRldGVjdHMgd2UncmUgdGFs
a2luZyB0byBhICdzZXJpYWwgcG9ydCcgYmV0d2VlbiAxMi54IGFuZCAxMy54LiBJZiB5b3UgYXJl
IGdldHRpbmcgbm8gb3V0cHV0DQo+ZnJvbSB0aGUgbG9hZGVyIGF0IGFsbCwgSSBzdXNwZWN0IHRo
aXMgaXMgbGlrZWx5IHRvIGJsYW1lLg0KPkJ1dCB0aGUgc2FtZSB3b3JrcyBpbiBGcmVlQlNEIDEy
LjMgYW5kIFB1dHR5IGdldHMgdGhlIG91dHB1dCBmcm9tIEVGSSBsb2FkZXIgZm9yIGJvdGggeDg2
IGFuZCBhcm02NC4NCj5CdXQgZHVyaW5nIGtlcm5lbCBib290aW5nIHRoZSBjb25zb2xlIG91dHB1
dCBkb2VzIG5vdCBjb21lIGluIFB1dHR5LCBpdCBvbmx5IGNvbWVzIGluIHZtY29ubmVjdC5leGUu
DQo+DQo+U28gb24gMTIuMywga2VybmVsIG91dHB1dCBkb2Vzbid0IGNvbWUgb3V0IG9mIGJvdGg/
IERvIHlvdSBoYXZlIGJvb3RfbXVsdGljb25zPVlFUyBpbiB5b3VyIGxvYWRlci5jb25mPw0KPklm
IG5vdCwgb25seSBvbmUgb2YgdGhlIGNvbnNvbGVzIHdpbGwgZ2V0IG91dHB1dCBmcm9tIHRoZSBr
ZXJuZWwuDQo+DQo+V2FybmVyDQo+Pkxpa2UgYmVsb3cgOg0KPj4NCj4+TG9hZGluZyBrZXJuZWwu
Li4NCj4+L2Jvb3Qva2VybmVsL2tlcm5lbCB0ZXh0PTB4OTMxZjI0IGRhdGE9MHgxODc0NTAgZGF0
YT0weDArMHgyZDA5NWUgc3ltcz1bMHg4KzB4MTM4MTIwKzB4OCsweDEyNDgyNF0NCj4+TG9hZGlu
ZyBjb25maWd1cmVkIG1vZHVsZXMuLi4NCj4+Y2FuJ3QgZmluZCAnL2Jvb3QvZW50cm9weScNCj4+
Y2FuJ3QgZmluZCAnL2V0Yy9ob3N0aWQnDQo+Pk5vIHZhbGlkIGRldmljZSB0cmVlIGJsb2IgZm91
bmQhDQo+PldBUk5JTkchIFRyeWluZyB0byBmaXJlIHVwIHRoZSBrZXJuZWwsIGJ1dCBubyBkZXZp
Y2UgdHJlZSBibG9iIGZvdW5kIQ0KPj5FRkkgZnJhbWVidWZmZXIgaW5mb3JtYXRpb246DQo+PmFk
ZHIsIHNpemUgICAgIDB4ZTAwMDAwMDAsIDB4ODAwMDAwDQo+PmRpbWVuc2lvbnMgICAgIDEwMjQg
eCA3NjgNCj4+c3RyaWRlICAgICAgICAgMTAyNA0KPj5tYXNrcyAgICAgICAgICAweDAwZmYwMDAw
LCAweDAwMDBmZjAwLCAweDAwMDAwMGZmLCAweGZmMDAwMDAwIDw8PDwNCj4+DQo+PkFmdGVyIHRo
aXMgbG9nIGlzIG5vdCBjb21pbmcgaW4gUHV0dHkgaW4gMTIuMyBmb3IgYm90aCB4ODYgYW5kIGFy
bTY0Lg0K

--_000_PSAP153MB05363C63A79375845D5CD613CCDF9PSAP153MB0536APCP_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp
bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K
CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s
PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl
eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs
YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1JTiIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFdhcm5lciw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgcG9pbnRpbmcgYm9vdF9tdWx0aWNvbnMsIGFuZCB5ZXMg
aXQgaGFzIHNvbHZlZCB0aGUgcHJvYmxlbSBvZiBGcmVlQlNEIGtlcm5lbCBib290IGxvZ3M8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPm5vdCBjb21pbmcgaW4gUHV0dHkgaW4gYm90aCB4ODYg
YW5kIGFybTY0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRpbmcgRnJlZUJTRCAxMywmbmJzcDsgeWVzIGxvYWRlci5l
ZmkgbG9ncyBhcmUgbm90IGNvbWluZyBpbiBQdXR0eSBtb3N0bHkgYmVjYXVzZSBvZiBFRkkgZ2Z4
IHVzYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj53aGljaCBpcyBub3Qgc3VwcG9ydGVk
IGluIFB1dHR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5Ob3cgd2UgY2FuIG92ZXJjb21lIGl0IGluIHg4NiBieSBzZXR0aW5n
IHNldCBjb25zb2xlPeKAnWNvbWNvbnNvbGXigJ0sIGFzIGl0IGlzIHVzaW5nIHRoZSBkaWZmZXJl
bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnVhcnQgaW1wbGVtZW50YXRpb24gb2YgY29t
Y29uc29sZSBvZiBsb2FkZXIsIHdoaWNoIGlzIG5vdCB0aGUgc2FtZSBpbiBhcm02NC4gVGhlIGlt
cGxlbWVudGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5vZiBjb21jb25zb2xlIGlu
IGFybTY0IGxvYWRlci5lZmkgaXMgbm90IHN1cHBvcnRlZCBpbiBIeXBlci1WIGxvb2tzIGxpa2Uu
IEFzIEh5cGVyLVYgb25seSBzdXBwb3J0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+dHR5
QU1BMCBmb3Igc2VyaWFsIGNvbnNvbGUgaW4gQVJNNjQgYnV0IHN1cHBvcnRzIHVhcnQgaW4geDg2
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5SZWdhcmRpbmcgQ29uT3V0LCBJIGhhdmUgZ290IGl0IGZyb20geDg2IEZyZWVCU0Qx
MywgKGFzIGFybTY0IGlzIGluIHRoZSBwcm9jZXNzIG9mIGJyaW5naW5nIHVwIGFuZDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29uT3V0IGlzIHNhbWUgZm9yIGFybTY0IGFuZCB4ODYsIGNv
bmZpcm1lZCBieSB1c2luZyBlZmlzaGVsbCBiaW5hcnkgYW5kIExpbnV4IHNoZWxsKS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
ZWZpdmFyIC0tZGV2aWNlLXBhdGggOGJlNGRmNjEtOTNjYS0xMWQyLWFhMGQtMDBlMDk4MDMyYjhj
LUNvbk91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+OGJlNGRmNjEtOTNjYS0xMWQyLWFh
MGQtMDBlMDk4MDMyYjhjLUNvbk91dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+OiBBY3Bp
RXgoVk1CdXMsLCkvVmVuSHcoOWIxN2U1YTItMDg5MS00MmRkLWI2NTMtODBiNWMyMjgwOWJhLDAy
NzgwYWRhNzdlM2FjNGE4ZTc3MDU1OGViMTA3M2Y4YzdlMDIwNTY2MjgwY2U0ZGFlYjc1MjBjN2Vm
NzYxNzEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPlRoYW5rcyAmYW1wOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+U291cmFkZWVwPC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAzMCwgMjAyMiwgMzozMSBB
TSBTb3VyYWRlZXAgQ2hha3JhYmFydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2hha3JhYmFydGlA
bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7
Jmd0O0hpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDtJIGFt
IHRyeWluZyB0byBhY2Nlc3MgdmlydHVhbCBzZXJpYWwgY29uc29sZSB2aWEgUHV0dHkgYW5kIGlu
IDEzLjAgaXQgaXMgbm90IHdvcmtpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmd0OyZndDtmb3IgYm90aCB4ODYgYW5kIGFybTY0LjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mZ3Q7Jmd0O0l0IGlzIHZlcnkgZWFzeSB0byByZXByb2R1Y2U6PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OzEpIEluIFdpbmRvd3MgSHlwZXItViBz
ZXQgYSZuYnNwOyBGcmVlQlNEIDEzLjAgVk08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZndDsmZ3Q7MikgVXNlIFBvd2Vyc2hlbGwgaW4gQWRtaW4gcHJpdmlsZWdlZCBtb2Rl
IGFuZCBydW4gZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2V0LVZNQ29tUG9ydCAt
Vk1OYW1lICZsdDt2bV9uYW1lJmd0OyAtbnVtYmVyIDEgLXBhdGggXFwuXHBpcGVcVGVzdHBpcGU8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7MikgSW4gYW5vdGhl
ciBQb3dlcnNoZWxsIHdpdGggQWRtaW4gcHJpdmlsZWdlIHJ1biBmb2xsb3dpbmc6PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBTZXQtVk1GaXJtd2FyZSAtVk1OYW1lICZsdDtWTSBuYW1lJmd0OyZuYnNw
OyAtLUNvbnNvbGVNb2RlIENPTTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZndDsmZ3Q7Mykgc3RhcnQgdGhlIFZNIGFuZCBvcGVuIHB1dHR5IHRvIGNvbm5lY3QgdGhlIFxc
LlxwaXBlXFRlc3RwaXBlIGluIHNlcmlhbCBtb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jmd0OyZndDtObyBvdXRwdXQgd2lsbCBiZSBzZWVuIG9uIHB1dHR5LjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O05vdCBldmVuIGZyb20gdGhlIGJv
b3QgbG9hZGVyPyBUaGF0IHN1cmUgc291bmRzIGxpa2UgdGhlIGF1dG9tYXRpYyBmYWxsYmFjayB0
byBzaW1wbGUgdGV4dCBvdXRwdXQgaXNuJ3QgaGFwcGVuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jmd0O1doYXQgZG9lczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDslIHN1ZG8gZWZpdmFyIC0tZGV2aWNlLXBhdGggOGJlNGRmNjEtOTNjYS0xMWQyLWFh
MGQtMDBlMDk4MDMyYjhjLUNvbk91dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jmd0O3RlbGwgeW91PyAoT3IgcnVuIGFzIHJvb3QgaWYgeW91IGRvbid0IGxpa2Ugc3Vkbyku
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VGhlIGJvb3QgbG9hZGVyIGdyZXcgYSBu
b24tb3B0aW9uYWwgZ3JhcGhpY3MgbW9kZSB0aGF0J3MgZGlzYWJsZWQgd2hlbiB0aGUgYm9vdCBj
b2RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ZGV0ZWN0cyB3ZSdy
ZSB0YWxraW5nIHRvIGEgJ3NlcmlhbCBwb3J0JyBiZXR3ZWVuIDEyLnggYW5kIDEzLnguIElmIHlv
dSBhcmUgZ2V0dGluZyBubyBvdXRwdXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDtmcm9tIHRoZSBsb2FkZXIgYXQgYWxsLCBJIHN1c3BlY3QgdGhpcyBpcyBsaWtlbHkg
dG8gYmxhbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7QnV0IHRo
ZSBzYW1lIHdvcmtzIGluIEZyZWVCU0QgMTIuMyBhbmQgUHV0dHkgZ2V0cyB0aGUgb3V0cHV0IGZy
b20gRUZJIGxvYWRlciBmb3IgYm90aCB4ODYgYW5kIGFybTY0LjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0J1dCBkdXJpbmcga2VybmVsIGJvb3RpbmcgdGhlIGNvbnNv
bGUgb3V0cHV0IGRvZXMgbm90IGNvbWUgaW4gUHV0dHksIGl0IG9ubHkgY29tZXMgaW4gdm1jb25u
ZWN0LmV4ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtTbyBvbiAxMi4zLCBrZXJu
ZWwgb3V0cHV0IGRvZXNuJ3QgY29tZSBvdXQgb2YgYm90aD8gRG8geW91IGhhdmUgYm9vdF9tdWx0
aWNvbnM9WUVTIGluIHlvdXIgbG9hZGVyLmNvbmY/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZndDtJZiBub3QsIG9ubHkgb25lIG9mIHRoZSBjb25zb2xlcyB3aWxsIGdl
dCBvdXRwdXQgZnJvbSB0aGUga2VybmVsLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
Z3Q7V2FybmVyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O0xp
a2UgYmVsb3cgOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsg
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O0xvYWRpbmcga2Vy
bmVsLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0Oy9ib290
L2tlcm5lbC9rZXJuZWwgdGV4dD0weDkzMWYyNCBkYXRhPTB4MTg3NDUwIGRhdGE9MHgwKzB4MmQw
OTVlIHN5bXM9WzB4OCsweDEzODEyMCsweDgrMHgxMjQ4MjRdPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O0xvYWRpbmcgY29uZmlndXJlZCBtb2R1bGVzLi4uPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O2Nhbid0IGZpbmQgJy9i
b290L2VudHJvcHknPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0
O2Nhbid0IGZpbmQgJy9ldGMvaG9zdGlkJzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmd0OyZndDtObyB2YWxpZCBkZXZpY2UgdHJlZSBibG9iIGZvdW5kITxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDtXQVJOSU5HISBUcnlpbmcgdG8gZmly
ZSB1cCB0aGUga2VybmVsLCBidXQgbm8gZGV2aWNlIHRyZWUgYmxvYiBmb3VuZCE8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7RUZJIGZyYW1lYnVmZmVyIGluZm9y
bWF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDthZGRy
LCBzaXplJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDB4ZTAwMDAwMDAsIDB4ODAwMDAwPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O2RpbWVuc2lvbnMmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgMTAyNCB4IDc2ODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jmd0OyZndDtzdHJpZGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgMTAyNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jmd0OyZndDttYXNrcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAweDAwZmYwMDAwLCAweDAwMDBmZjAwLCAweDAwMDAwMGZmLCAweGZmMDAwMDAw
ICZsdDsmbHQ7Jmx0OyZsdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn
dDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDtBZnRl
ciB0aGlzIGxvZyBpcyBub3QgY29taW5nIGluIFB1dHR5IGluIDEyLjMgZm9yIGJvdGggeDg2IGFu
ZCBhcm02NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_PSAP153MB05363C63A79375845D5CD613CCDF9PSAP153MB0536APCP_--

From nobody Wed Jun  1 21:44:01 2022
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 DA26C1B5AC50
	for ; Wed,  1 Jun 2022 21:44:04 +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 4LD2hz4M0Mz4pTt
	for ; Wed,  1 Jun 2022 21:44:03 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 251Li1jB042525
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Wed, 1 Jun 2022 14:44:02 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 251Li14I042524
	for freebsd-arm@freebsd.org; Wed, 1 Jun 2022 14:44:01 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 1 Jun 2022 14:44:01 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220601214401.GA42494@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@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: <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
X-Rspamd-Queue-Id: 4LD2hz4M0Mz4pTt
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.95 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[zefox.net];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.85)[-0.850];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1447
Lines: 44

On Wed, Jun 01, 2022 at 09:17:10AM -0700, Mark Millard wrote:
> On 2022-Jun-1, at 08:41, bob prohaska  wrote:
> 
> > Since about 05/29 mountroot has been failing on a Pi3 self-hosting -current,
> > using a usb mechanical hard disk.  
> > 
> > Anybody else seen this sort of behavior? 
> 
> You do not report much context. FreeBSD version? UFS? ZFS?

-current, UFS. 

> 
> However, there has been today (for main):
> 
> git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity checks when reading a superblock
> 
> that is for fixing boot problems in UFS contexts. See:
> 
> https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.html
> 
> This is for fixes related to the 2022-May-27 change:
> 
> 	??? git: 076002f24d35 - main - Do comprehensive UFS/FFS superblock integrity checks when reading a superblock. Kirk McKusick 
> 

It sounds like there's some hope the trouble isn't purely local to my
machines. I'll just continue to update and hope for the best. A Pi3
running -current as well as a Pi3 running stable/13 seem to be affected.
A Pi4 running -current works perfectly. All use UFS on mechanical 
hard disks. 

FWIW, one boot attempt followed the mountroot failure
with a kernel panic and backtrace, but I inadvertently wiped 
out the console transcript before I could post it. If that
happens again I'll take more care.

Thanks to everyone who replied, especially Mark!

bob



it. 

From nobody Wed Jun  1 21:45:51 2022
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 2BC1F1B5B1A8
	for ; Wed,  1 Jun 2022 21:46:03 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d])
	(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 4LD2lG3t1Yz4pst
	for ; Wed,  1 Jun 2022 21:46:02 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yb1-xb2d.google.com with SMTP id w2so5178831ybi.7
        for ; Wed, 01 Jun 2022 14:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=SS95ZzxBdzPlGyzqK3bMOXBj/OWetyTwI05MjjuGmN8=;
        b=UuvwvggLfobps/q7wvFJ2dFeunZMdWAts0P+ddFPvUNfgOXzs32ybYrDejrUDtJ+lF
         br5R/49vpDQM9okcZU959RrEgayXoo2D4DIz73mFdAiAuUoGsFUMfL+g81B8vCRvLZnE
         3Rwz4JSXP8q2BIysPmn/UYamYaP2secCTDX+vNO/Aef+5inp/3c/UONP5vwBzUC2tnmH
         kUTPMeoyeM5o3FHODQiph5oJeD19R2HMbgKF5KHgbx1U2GDE5IPdFJVMe6O79/JfeZJs
         mpGRqqNV0Z0caCuDUxBRYH8MJeVcH8JilW+16fgkd9xI+ntbR1CXUDzJAYYdbjETXdVu
         wB4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=SS95ZzxBdzPlGyzqK3bMOXBj/OWetyTwI05MjjuGmN8=;
        b=MImxIyyUUHXt9A5zuZuHmC5z1NJdyW/iuhLHcKo/61RLdV1T0gTQ4qA+HGBjWsl0xi
         Ay+yiaPuseKhh2E17saMh99WrOWyKqr1dGctSpgFea/sJ4xLIz8cdYO+yLvG5nrOk2xh
         FLj1mp3sV1qE53w4rsYRyjrOoKR6iJI1kPpapmOtuUHc5qoDesIpkLlOw8rJuEY45WIs
         6/y09xEYccXZS92o8FQlq+/pYNd7M9vLLO9/dS8MRaHyKY4ik313JqebHn2zpNgkAKZd
         d/El72+T3DFntX951dKffR4HszB1dg38+AJkICYfcJAoQv+i7U/YTySbL3ZBy3E7tgXv
         WGPw==
X-Gm-Message-State: AOAM5302fK5JUx7Fk5I4GjbP1jJgkAr6r0vSwWmDvLU1w3c/oNd/Yq2z
	6XBNa69hovZ56qchlAp536g5USIP5wIblsM/2VE3I8oguZKLXw==
X-Google-Smtp-Source: ABdhPJw4ox0fFp0ec8m1qH4t9CPWCFU56gSj9pw58BqKgHKPs00Mbcercr5Um6koDndbA2Rup2ywR6BHOn8yBgBBomI=
X-Received: by 2002:a25:6155:0:b0:65d:3a65:a801 with SMTP id
 v82-20020a256155000000b0065d3a65a801mr2065840ybb.224.1654119961967; Wed, 01
 Jun 2022 14:46:01 -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: <20220601154142.GA41835@www.zefox.net> <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
In-Reply-To: <20220601214401.GA42494@www.zefox.net>
From: Robert Montano 
Date: Wed, 1 Jun 2022 14:45:51 -0700
Message-ID: 
Subject: Re: Mountroot problems on RPi3/aarch64
To: bob prohaska 
Cc: Free BSD 
Content-Type: multipart/alternative; boundary="000000000000bfbda105e069d016"
X-Rspamd-Queue-Id: 4LD2lG3t1Yz4pst
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=UuvwvggL;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::b2d as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-3.94 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2d:from];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-0.94)[-0.938];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4403
Lines: 131

--000000000000bfbda105e069d016
Content-Type: text/plain; charset="UTF-8"

I'm a newbie to all of this. Sorry I don't really understand the
nomenclature!



On Wed, Jun 1, 2022, 2:44 PM bob prohaska  wrote:

> On Wed, Jun 01, 2022 at 09:17:10AM -0700, Mark Millard wrote:
> > On 2022-Jun-1, at 08:41, bob prohaska  wrote:
> >
> > > Since about 05/29 mountroot has been failing on a Pi3 self-hosting
> -current,
> > > using a usb mechanical hard disk.
> > >
> > > Anybody else seen this sort of behavior?
> >
> > You do not report much context. FreeBSD version? UFS? ZFS?
>
> -current, UFS.
>
> >
> > However, there has been today (for main):
> >
> > git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integrity
> checks when reading a superblock
> >
> > that is for fixing boot problems in UFS contexts. See:
> >
> >
> https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.html
> >
> > This is for fixes related to the 2022-May-27 change:
> >
> >       ??? git: 076002f24d35 - main - Do comprehensive UFS/FFS superblock
> integrity checks when reading a superblock. Kirk McKusick
> >
>
> It sounds like there's some hope the trouble isn't purely local to my
> machines. I'll just continue to update and hope for the best. A Pi3
> running -current as well as a Pi3 running stable/13 seem to be affected.
> A Pi4 running -current works perfectly. All use UFS on mechanical
> hard disks.
>
> FWIW, one boot attempt followed the mountroot failure
> with a kernel panic and backtrace, but I inadvertently wiped
> out the console transcript before I could post it. If that
> happens again I'll take more care.
>
> Thanks to everyone who replied, especially Mark!
>
> bob
>
>
>
> it.
>
>

--000000000000bfbda105e069d016
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm a newbie to all of this. Sorry I don't really=
 understand the nomenclature!

=


On Wed, Jun 1, 2022, 2:44 PM bob prohaska <fbsd@www.zefox.net> wrote:
On Wed, Jun 01, 2022 at 09:17:10AM -0700, Mark Millard wr=
ote:

> On 2022-Jun-1, at 08:41, bob prohaska <fbsd@www.zefox.net> w=
rote:

> 

> > Since about 05/29 mountroot has been failing on a Pi3 self-hostin=
g -current,

> > using a usb mechanical hard disk.=C2=A0 

> > 

> > Anybody else seen this sort of behavior? 

> 

> You do not report much context. FreeBSD version? UFS? ZFS?



-current, UFS. 



> 

> However, there has been today (for main):

> 

> git: bc218d89200f - main - Two bug fixes to UFS/FFS superblock integri=
ty checks when reading a superblock

> 

> that is for fixing boot problems in UFS contexts. See:

> 

> https:/=
/lists.freebsd.org/archives/dev-commits-src-main/2022-June/006977.html<=
br>
> 

> This is for fixes related to the 2022-May-27 change:

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0??? git: 076002f24d35 - main - Do comprehens=
ive UFS/FFS superblock integrity checks when reading a superblock. Kirk McK=
usick 

> 



It sounds like there's some hope the trouble isn't purely local to =
my

machines. I'll just continue to update and hope for the best. A Pi3

running -current as well as a Pi3 running stable/13 seem to be affected.
A Pi4 running -current works perfectly. All use UFS on mechanical 

hard disks. 



FWIW, one boot attempt followed the mountroot failure

with a kernel panic and backtrace, but I inadvertently wiped 

out the console transcript before I could post it. If that

happens again I'll take more care.



Thanks to everyone who replied, especially Mark!



bob







it. 






--000000000000bfbda105e069d016--

From nobody Wed Jun  1 22:03:15 2022
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 7632D1B605DA
	for ; Wed,  1 Jun 2022 22:03:21 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020027.outbound.protection.outlook.com [52.101.128.27])
	(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 4LD37D3PRrz4vmf;
	Wed,  1 Jun 2022 22:03:20 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CzcfpuitqmxZRwzzisvPbNTxG1MqJbIMcEVVkRXmEm2GJL2F1qMyVWr7qJw1B5fKw+gCJkXwSqH5lZXLFJvBUpLUYRpqfyRZTNaTytBFN336qrYyeX3R1idgFCWGnmDBJQstZ8KnMqLbXyuBfya7Xu07d4Iht7PxWOax6O3U9wKkERO9kxerWlRdibisZniAbcQVzRzBhNmoFfocAaz75ibmXQTp2A2EaTXCCChv/4YgI+B6vFu2RXhu56ooejgKOpZYnDy9Zw1r1ofsXST2zlTIJu6W0rDeRC+xri9g6Ru4jDE9TriC68GljjTBeQiOF/mvu8hsytbeo/nAJhqTzg==
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=G7+jp8xldEKSWkUrS2MS7yQNF4ZsA+hng8wWZoYOZF0=;
 b=KfvYbTlwx1prjeMYQ8UY6IoQ/Slq9D6lmCxqk/98UQMZUgwBIETq5HjN9GjYoHHUQhTQ6A/fX6ARuYgwCBhXC4t91rj7kT+s+PyAsImkRbz/vbE4ld8ah4o8qmue9ZuZ33mlubrOrOJpDj1UyJL8Ew490GitiqkSh/Hpbu0Xkw9QBekvUeSibh+47Al1ArTebgND51Ljzw4GgbdUPTE8zQlIZVPUQxxWLUY8OOm7pAZy4Mbh0h3EzlUtTHcvXUStl9okejVDdYeoJLI7Ah9wiQzzYQAc9ipif5Pth/ePocwt8WghzhAtYAFD/XPA4VLoO4VhuZ5gpXdjrF6j67p3jg==
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=G7+jp8xldEKSWkUrS2MS7yQNF4ZsA+hng8wWZoYOZF0=;
 b=SsH8P1vuPGEN1m1QQnGDiteR665vYqdBVXwdHb9sg/6VnMkeW3PMTgzz3+dnBoY6GWpoLBEHDGFSx3Eoz9HGk9KSJxc6DfIDjCX9JxATm0MffcAxD8nItTGSOR0ZXSid/hB4EIz6ZaTKfv5h0EexutSYotBSUtUIPDSrf8q8m9w=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by SEZP153MB0629.APCP153.PROD.OUTLOOK.COM (2603:1096:101:90::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.0; Wed, 1 Jun
 2022 22:03:16 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826%6]) with mapi id 15.20.5332.004; Wed, 1 Jun 2022
 22:03:16 +0000
From: Souradeep Chakrabarti 
To: Warner Losh 
CC: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	, Wei Hu 
Subject: Re: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Topic: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQAJq/UAAHVgdIU=
Date: Wed, 1 Jun 2022 22:03:15 +0000
Message-ID:
 
References:
 
 
In-Reply-To:
 
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-01T22:03:17.031Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 705729c9-eb2b-4986-44fa-08da441a8781
x-ms-traffictypediagnostic: SEZP153MB0629:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 +GG4cBTnb9HRiplZq9qv4/81AaqK1zgAb8Wrh5tP8WRmxPZoPIXCIi1Qu8rTsDD8saCJYguDYui39Kvb/fX8NKkhg5ySBvKvA9Jqk2qGTCQyEJ2TatLMRn6/DrquTePbCx+Qp4iBRsL/ILX4v7TrjaKzNlT3S5Vsp/iSSL6i/LDkT+sE8KBp/Ls5NgkJeQiFPLiZtEFVvAU7tZ8HmAeT3fmZYT0zrIWSwtIHV/TNhd6rNv0yja0xxf28yYubt8S21keuKZFC02KlMbZvHDgXZX47QvROexf3iAAYgGJ+GkuOPAaUcZFbYApSLpwvRcGtkno8MJv7sqFT5+FXpbuaYY5KSLt4TxhiqVytFG9on3NfldglsqKiOt9MbbdH3O5XpVUdv33810hKdgxa0N/gZxyVntlV4K/A46++bauoP2Xu0iBDNSL41zh6ZZ2jgMMUObqiAak8P5biXJ3FCind35leoMN4PrgzwPSz6dNNtTZa7qsJ9k7YoXbCwHovoah7fy6+G7NVcGhq/ZbutCDLGg42gWlrrv1Rt4eArOR5qa47Rgco7XT1i9Y3fX8KqhQzc8xKpMfL4XV6Vb/xZ7U9MlVNt9qj1/Bb8Q4vkrexMopnj+aeutYE7KzdkjmZmZSDmqiBzFOs/j6HsFtCVwCNOUdYzhSxlZ3As689Yf3eUsvkWmvBFQ2mbH/qZQ3DzZynMZjnuBiYYBOKkkYFZgrwqyv7FkDbqkqOI7A/jsmoTBQQmjABzy7fE/+Mby15Oc9qJCfhYwxbFj7oDhbIz+AakA==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(6506007)(8990500004)(7696005)(2906002)(107886003)(186003)(54906003)(82960400001)(6916009)(82950400001)(122000001)(19627405001)(316002)(10290500003)(38100700002)(38070700005)(9686003)(26005)(66556008)(4326008)(5660300002)(508600001)(64756008)(33656002)(71200400001)(91956017)(8676002)(83380400001)(52536014)(8936002)(86362001)(55016003)(66446008)(76116006)(66946007)(66476007)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?Windows-1252?Q?qDr90qH6YzK8ujNGwpfAh4LP+NVvPFT+8cp2W7GfucKMJFsmIH1N0Fjf?=
 =?Windows-1252?Q?73ZtRy3dRmYnT72in0+Bwx994Bj8KtiUM/2UTiE6OEZyePetdU8WBoYc?=
 =?Windows-1252?Q?guvaxUQo72mruIc3Tco0u4BDAXe0ezwi3HCO039c3bp4N+wym9e1Ly3l?=
 =?Windows-1252?Q?vZRbgSUz/fZQyNB6M4plClk0JwhTP/nAoWgfwHwtDnNEyHFWHPApWpRK?=
 =?Windows-1252?Q?3sjhmSh6gtauHc3NLrNmJU643TswY5bICfHeInehhrLg2LwvkG2i6boW?=
 =?Windows-1252?Q?4nUl4VpJWAvWNG4SnZpivlKQjzITocxKAa3tTewc+vwnsNHOv7KgRI3s?=
 =?Windows-1252?Q?/cBFyzeFsdVl+qAYL97/Px933Wm6aKV9KalKI5LS5Jalq9QUgth5wCPj?=
 =?Windows-1252?Q?KJVC1jIRCPTW2GSneQFQ35B2rLUe3c6uFNLfr5eZ4KRgUcWwuURUGOyy?=
 =?Windows-1252?Q?WM5+FClKYFgD9DeeHYEUJOB0l/CX4zm+k8Em5OmMkOWVE+2teP2VK8L2?=
 =?Windows-1252?Q?ykRAMRSCIRz/kFyLN2A8u1WoIu2dd6lkjYedcbNfCKv96AlKt1t/CPQU?=
 =?Windows-1252?Q?aR9RQ5fvQUshetfEZBdui+GAfZn4s5wI64CyGdmdf7AaCiFdOJePx6WA?=
 =?Windows-1252?Q?Z5WLPI0cKyhw2d9wQkEeZhwYXf28bbbqa1MjaglmUE/Q5TP22hGo69si?=
 =?Windows-1252?Q?RLPyMLEqCi3lmJ0wofuhY2rqIZUrvvrJJgeDJRdVWv0qHkuQSpZLwV/B?=
 =?Windows-1252?Q?MMTNr63FJ7qXP0o+H2chqU48GlxA/mfNihnZYel1oxORjsU1F8xl/s2q?=
 =?Windows-1252?Q?tHrLCy0sviRhjSO0Q69bO7QihY/VXCAz2rS81eXVJcMji8PdBEP2tQar?=
 =?Windows-1252?Q?NGX5wuwmaDOFi/FW9PeC3yhZ1IjnG9NmNER55gi5dep1eMh3Ff8bVEfi?=
 =?Windows-1252?Q?SoQ1grpramm/YohyYzh+HnAt0ixIrho4JwIxVGSw2H6o3j1VFME5R4uw?=
 =?Windows-1252?Q?Za33zDE2sagO/Be5fpFEwjaqvDjlc3uyMPDy0eDCPXSz2AJ7TnN1sbhQ?=
 =?Windows-1252?Q?yqFYdKAmCa9MdW4KKmrH7+K+wdOReYzQI4y3omu82m5DfTEGownz9ldF?=
 =?Windows-1252?Q?w/TK0q/s3LZtusa9JNa4C5RC8MinoSi+i8XWRJ5OTAlihUME31sbAVhC?=
 =?Windows-1252?Q?sneX9AhmpPb2TVmFiYcbLk+UQt01wGTYyFSDoYrK/Jz7kWF3TWb/PUGi?=
 =?Windows-1252?Q?9cKhHevZLABuh5oAM9p5KJ0HJW3f6PAoV8bSf5qWAdiMsokKrlAg+p0J?=
 =?Windows-1252?Q?MbVJamzR+i7yNDDTG/ytE6nTXc4xfVFeCbMYdOheB4OWZt5ffXz+3Mm3?=
 =?Windows-1252?Q?Gs4qktzm5vnoYt4xN4Jh/ksmujea1Yu4Bv/qAG0uUlDiTJ981t6hQ+w7?=
 =?Windows-1252?Q?MrUxQn+RxH8Q/U5syvtfPmwX6LGyjvoYtrTUGU8h+dmZf+UdzGPr5L68?=
 =?Windows-1252?Q?AZpv3mDY6ISuPdReONtrm30CEUHBJSMkinVBb/bus9oFkhvGNCU1TvJ3?=
 =?Windows-1252?Q?TxmjH465GrHg1/IqQvvmganVs00soGYXk2tb6x//ZQlgOt3hUhCfh6wL?=
 =?Windows-1252?Q?MHR+fntCDx00/iZMxJa40b3ZKQk1PojT/KfiddCkQqGG9Zzw9tcN9jQS?=
 =?Windows-1252?Q?CUpyzR6fscJ94hDA2iMhIiQDrt7c3U+kSPJAh0CUZ5AKhUMQrEnlN668?=
 =?Windows-1252?Q?dskF7SohpVCWSn4E5A/zq4k/ml1mj+0FxsH+wa6EKQHR3RVNTrAuuI8h?=
 =?Windows-1252?Q?Z4Is5Q=3D=3D?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB0536E7F2B5A8DBF521E306E5CCDF9PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 705729c9-eb2b-4986-44fa-08da441a8781
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2022 22:03:15.9424
 (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: Y924gV00c3vwC2j4KEcZPAxXdGfROvExpXAw4I53dnI2J76U3EfimzfHNO6zKLbum1J3+IbDrD3BODx4iar1J8pi2Lo5K2XbzKfWuGLVubg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZP153MB0629
X-Rspamd-Queue-Id: 4LD37D3PRrz4vmf
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=SsH8P1vu;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.27 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.98 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 NEURAL_HAM_SHORT(-0.98)[-0.982];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10239
Lines: 399

--_000_PSAP153MB0536E7F2B5A8DBF521E306E5CCDF9PSAP153MB0536APCP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Warner,

Thanks for pointing boot_multicons, and yes it has solved the problem of Fr=
eeBSD kernel boot logs

not coming in Putty in both x86 and arm64.

Regarding FreeBSD 13,  yes loader.efi logs are not coming in Putty mostly b=
ecause of EFI gfx usage

which is not supported in Putty.

Now we can overcome it in x86 by setting set console=3D=94comconsole=94, as=
 it is using the different

uart implementation of comconsole of loader, which is not the same in arm64=
. The implementation

of comconsole in arm64 loader.efi is not supported in Hyper-V looks like. A=
s Hyper-V only supports

ttyAMA0 for serial console in ARM64 but supports uart in x86.


Regarding ConOut, I have got it from x86 FreeBSD13, (as arm64 is in the pro=
cess of bringing up and

ConOut is same for arm64 and x86, confirmed by using efishell binary and Li=
nux shell).


efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut

8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut

: AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,02780ada77e3ac=
4a8e770558eb1073f8c7e020566280ce4daeb7520c7ef76171)


On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti  wrote:

>>Hi,

>>I am trying to access virtual serial console via Putty and in 13.0 it is =
not working

>>for both x86 and arm64.

>>

>>It is very easy to reproduce:

>>1) In Windows Hyper-V set a  FreeBSD 13.0 VM

>>2) Use Powershell in Admin privileged mode and run following:

>>                Set-VMComPort -VMName  -number 1 -path \\.\pipe\=
Testpipe

>>2) In another Powershell with Admin privilege run following:

>>3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial=
 mode.

>>No output will be seen on putty.

>Not even from the boot loader? That sure sounds like the automatic fallbac=
k to simple text output isn't happening.

>

>What does:

>% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut

>tell you? (Or run as root if you don't like sudo).

>

>The boot loader grew a non-optional graphics mode that's disabled when the=
 boot code

>detects we're talking to a 'serial port' between 12.x and 13.x. If you are=
 getting no output

>from the loader at all, I suspect this is likely to blame.

>But the same works in FreeBSD 12.3 and Putty gets the output from EFI load=
er for both x86 and arm64.

>But during kernel booting the console output does not come in Putty, it on=
ly comes in vmconnect.exe.

>

>So on 12.3, kernel output doesn't come out of both? Do you have boot_multi=
cons=3DYES in your loader.conf?

>If not, only one of the consoles will get output from the kernel.

>

>Warner

>>Like below :

>>

>>Loading kernel...

>>/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e s=
yms=3D[0x8+0x138120+0x8+0x124824]

>>Loading configured modules...

>>can't find '/boot/entropy'

>>can't find '/etc/hostid'

>>No valid device tree blob found!

>>WARNING! Trying to fire up the kernel, but no device tree blob found!

>>EFI framebuffer information:

>>addr, size     0xe0000000, 0x800000

>>dimensions     1024 x 768

>>stride         1024

>>masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<

>>

>>After this log is not coming in Putty in 12.3 for both x86 and arm64.



Thanks & Regards,
 Souradeep


--_000_PSAP153MB0536E7F2B5A8DBF521E306E5CCDF9PSAP153MB0536APCP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable









Hi Warner,






Thanks for pointing boot_multicons, and yes it has solved the problem =
of FreeBSD kernel boot logs







not coming in Putty in both x86 and arm64.







Regarding FreeBSD 13,  yes loader.efi logs are not coming in Putt=
y mostly because of EFI gfx usage







which is not supported in Putty.







Now we can overcome it in x86 by setting set console=3D=94comconsole=
=94, as it is using the different







uart implementation of comconsole of loader, which is not the same in =
arm64. The implementation







of comconsole in arm64 loader.efi is not supported in Hyper-V looks li=
ke. As Hyper-V only supports







ttyAMA0 for serial console in ARM64 but supports uart in x86.







 


Regarding ConOut, I have got it from x86 FreeBSD13, (as arm64 is in th=
e process of bringing up and







ConOut is same for arm64 and x86, confirmed by using efishell binary a=
nd Linux shell).












efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut







8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut







: AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,02780ada7=
7e3ac4a8e770558eb1073f8c7e020566280ce4daeb7520c7ef76171)






 





On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti <schakrabarti@micros=
oft.com> wrote:









>>Hi,







>>I am trying to access virtual serial console via Putty and in =
13.0 it is not working







>>for both x86 and arm64.







>>







>>It is very easy to reproduce:







>>1) In Windows Hyper-V set a  FreeBSD 13.0 VM







>>2) Use Powershell in Admin privileged mode and run following:<=
/div>






>>                Set-VM=
ComPort -VMName <vm_name> -number 1 -path \\.\pipe\Testpipe







>>2) In another Powershell with Admin privilege run following:






>>3) start the VM and open putty to connect the \\.\pipe\Testpip=
e in serial mode.







>>No output will be seen on putty.







>Not even from the boot loader? That sure sounds like the automatic=
 fallback to simple text output isn't happening.







> 







>What does:







>% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-C=
onOut







>tell you? (Or run as root if you don't like sudo).







> 







>The boot loader grew a non-optional graphics mode that's disabled =
when the boot code







>detects we're talking to a 'serial port' between 12.x and 13.x. If=
 you are getting no output







>from the loader at all, I suspect this is likely to blame.







>But the same works in FreeBSD 12.3 and Putty gets the output from =
EFI loader for both x86 and arm64.







>But during kernel booting the console output does not come in Putt=
y, it only comes in vmconnect.exe.







> 







>So on 12.3, kernel output doesn't come out of both? Do you have bo=
ot_multicons=3DYES in your loader.conf?







>If not, only one of the consoles will get output from the kernel.<=
/div>






> 







>Warner







>>Like below :







>>







>>Loading kernel...







>>/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0=
+0x2d095e syms=3D[0x8+0x138120+0x8+0x124824]







>>Loading configured modules...







>>can't find '/boot/entropy'







>>can't find '/etc/hostid'







>>No valid device tree blob found!







>>WARNING! Trying to fire up the kernel, but no device tree blob=
 found!







>>EFI framebuffer information:







>>addr, size     0xe0000000, 0x800000







>>dimensions     1024 x 768







>>stride         1024







>>masks          0x00ff0000, 0x0000ff00=
, 0x000000ff, 0xff000000 <<<<







>>







>>After this log is not coming in Putty in 12.3 for both x86 and=
 arm64.

























Thanks & Regards,



 Souradeep
















--_000_PSAP153MB0536E7F2B5A8DBF521E306E5CCDF9PSAP153MB0536APCP_--

From nobody Wed Jun  1 22:46:22 2022
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 7AD9D1B677F4
	for ; Wed,  1 Jun 2022 22:46:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933])
	(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 4LD45C4CRTz3GWh
	for ; Wed,  1 Jun 2022 22:46:39 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x933.google.com with SMTP id l12so1039231uan.5
        for ; Wed, 01 Jun 2022 15:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=g1tcFuYNa48JSaBOESgkSSTgoSvu2uUsPUOINVLsjGg=;
        b=6ObeoAUcPx70kyASvz0dq7WxRaV/gowYZBXF/Q/CguMsTGC8EQnbAL7MYrpK76E3JG
         lKhqczZKE3FRuEHWxdRIX+qPgy1Q18rC36o1Q+UXZPg3Me+Xe52xGUM92W5kSVq//ms1
         FVDBn8CtEHnKFESYnUmEwVV7uJutDlsXZr5R6tXHfF1UbcjVsZIPkKcupvR8F3CCJ03I
         wcbcw3qzofM6f+e9BpDddy0jD2oDuW+sl9zjApENP1Y14w9PMdyZnEioGy+AFRBXNnb3
         vfwd/1EldVhX1WvZRbYMjipGTC0i45eHocnSTHv0hFzOhmq8WBhQnovX0gYocWUa0PeB
         aZVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=g1tcFuYNa48JSaBOESgkSSTgoSvu2uUsPUOINVLsjGg=;
        b=UYnfLXF33JGE290dZLdqtm1qZCZhASSkNG+XARVYRLYAfZSuomRD416KNqe8U/IjAg
         RpN2yVvBV9RcRnSR2sLJFaj3wXVYEDMvq/akyiM1WRqZAPgSTy1Df/xKU8tP7OdIcH+V
         c6yIJCzInBViUiYIj0PxFg7f93mUyBLmSW0PeGb1D0diXni8bVwZ345fGLpCOFT+JGha
         RT/AtThX/7+0135HGQcflieySx7MdIvHtL1BxmCgTA9O7anOWiCYqj5DtelX2N0CXZVL
         67QwDpiAxmsRIfmBSRpOoNLUuxBs9qVS+xIr98qHafxw+yV95qF23bqPAa1U9zZIROSI
         RDMg==
X-Gm-Message-State: AOAM530DwWfMgfWDlWxOPjM2VcesIadXZmabEWTa/1zKaY2XpCeAYEQK
	Xln7X/Xrk01EZmWdMhIqYGp1DwtaqNK3WEMlYkuC9g==
X-Google-Smtp-Source: ABdhPJyeFK0FfLbzrs2VpyrvUYdynRoZSS/G14vIilLjIGo70HOmGp6S6WmE0L3yLtedUHPmKLrkMFof31RXMJ9hogg=
X-Received: by 2002:a9f:3806:0:b0:369:34d2:e3bc with SMTP id
 p6-20020a9f3806000000b0036934d2e3bcmr11667486uad.2.1654123593255; Wed, 01 Jun
 2022 15:46: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: 
  
In-Reply-To: 
From: Warner Losh 
Date: Wed, 1 Jun 2022 16:46:22 -0600
Message-ID: 
Subject: Re: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
To: Souradeep Chakrabarti 
Cc: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org" , 
	Wei Hu 
Content-Type: multipart/alternative; boundary="00000000000030e05305e06aa9cf"
X-Rspamd-Queue-Id: 4LD45C4CRTz3GWh
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=6ObeoAUc;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::933) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.94 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-0.94)[-0.944];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::933:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 11607
Lines: 424

--00000000000030e05305e06aa9cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 1, 2022 at 4:03 PM Souradeep Chakrabarti <
schakrabarti@microsoft.com> wrote:

> Hi Warner,
>
> Thanks for pointing boot_multicons, and yes it has solved the problem of
> FreeBSD kernel boot logs
>
> not coming in Putty in both x86 and arm64.
>
> Regarding FreeBSD 13,  yes loader.efi logs are not coming in Putty mostly
> because of EFI gfx usage
>
> which is not supported in Putty.
>
> Now we can overcome it in x86 by setting set console=3D=E2=80=9Dcomconsol=
e=E2=80=9D, as it
> is using the different
>
> uart implementation of comconsole of loader, which is not the same in
> arm64. The implementation
>
> of comconsole in arm64 loader.efi is not supported in Hyper-V looks like.
> As Hyper-V only supports
>
> ttyAMA0 for serial console in ARM64 but supports uart in x86.
>

How is that connected to the system? Does it appear in dmesg? in fact, a
full dmesg wouldn't be bad to have.


> Regarding ConOut, I have got it from x86 FreeBSD13, (as arm64 is in the
> process of bringing up and
> ConOut is same for arm64 and x86, confirmed by using efishell binary and
> Linux shell).
>
>
> efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
>
> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
>
> :
> AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,02780ada77e3ac=
4a8e770558eb1073f8c7e020566280ce4daeb7520c7ef76171)
>

Thanks! That confirms what I thought I knew...

Warner


>
> On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti <
> schakrabarti@microsoft.com> wrote:
>
> >>Hi,
>
> >>I am trying to access virtual serial console via Putty and in 13.0 it i=
s
> not working
>
> >>for both x86 and arm64.
>
> >>
>
> >>It is very easy to reproduce:
>
> >>1) In Windows Hyper-V set a  FreeBSD 13.0 VM
>
> >>2) Use Powershell in Admin privileged mode and run following:
>
> >>                Set-VMComPort -VMName  -number 1 -path
> \\.\pipe\Testpipe
>
> >>2) In another Powershell with Admin privilege run following:
>
> >>3) start the VM and open putty to connect the \\.\pipe\Testpipe in
> serial mode.
>
> >>No output will be seen on putty.
>
> >Not even from the boot loader? That sure sounds like the automatic
> fallback to simple text output isn't happening.
>
> >
>
> >What does:
>
> >% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
>
> >tell you? (Or run as root if you don't like sudo).
>
> >
>
> >The boot loader grew a non-optional graphics mode that's disabled when
> the boot code
>
> >detects we're talking to a 'serial port' between 12.x and 13.x. If you
> are getting no output
>
> >from the loader at all, I suspect this is likely to blame.
>
> >But the same works in FreeBSD 12.3 and Putty gets the output from EFI
> loader for both x86 and arm64.
>
> >But during kernel booting the console output does not come in Putty, it
> only comes in vmconnect.exe.
>
> >
>
> >So on 12.3, kernel output doesn't come out of both? Do you have
> boot_multicons=3DYES in your loader.conf?
>
> >If not, only one of the consoles will get output from the kernel.
>
> >
>
> >Warner
>
> >>Like below :
>
> >>
>
> >>Loading kernel...
>
> >>/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e
> syms=3D[0x8+0x138120+0x8+0x124824]
>
> >>Loading configured modules...
>
> >>can't find '/boot/entropy'
>
> >>can't find '/etc/hostid'
>
> >>No valid device tree blob found!
>
> >>WARNING! Trying to fire up the kernel, but no device tree blob found!
>
> >>EFI framebuffer information:
>
> >>addr, size     0xe0000000, 0x800000
>
> >>dimensions     1024 x 768
>
> >>stride         1024
>
> >>masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <<<<
>
> >>
>
> >>After this log is not coming in Putty in 12.3 for both x86 and arm64.
>
>
>
> Thanks & Regards,
>  Souradeep
>
>

--00000000000030e05305e06aa9cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jun 1, 2022 at 4:03 PM Sourad=
eep Chakrabarti <schakraba=
rti@microsoft.com> wrote:









Hi Warner,






Thanks for pointing boot_multicons, and yes it has solved the problem =
of FreeBSD kernel boot logs







not coming in Putty in both x86 and arm64.







Regarding FreeBSD 13, =C2=A0yes loader.efi logs are not coming in Putt=
y mostly because of EFI gfx usage







which is not supported in Putty.







Now we can overcome it in x86 by setting set console=3D=E2=80=9Dcomcon=
sole=E2=80=9D, as it is using the different







uart implementation of comconsole of loader, which is not the same in =
arm64. The implementation







of comconsole in arm64 loader.efi is not supported in Hyper-V looks li=
ke. As Hyper-V only supports







ttyAMA0 for serial console in ARM64 but supports uart in x86.

How is that connected to the syst=
em? Does it appear in dmesg? in fact, a full dmesg wouldn't be bad to h=
ave.
=C2=A0


Regarding ConOut, I have got it from x86 FreeBSD13, (as arm64 is in th=
e process of bringing up and


ConOut is same for arm64 and x86, confirmed by using efishell binary a=
nd Linux shell).












efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut







8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut







: AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,02780ada7=
7e3ac4a8e770558eb1073f8c7e020566280ce4daeb7520c7ef76171)
<=
/blockquote>

Thanks! That confirms what I thought I knew=
...

Warner
=C2=A0
<=
span style=3D"font-size:12pt">=C2=A0





On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti <schakrabarti@microsoft.com=
> wrote:









>>Hi,







>>I am trying to access virtual serial console via Putty and in =
13.0 it is not working







>>for both x86 and arm64.







>>







>>It is very easy to reproduce:







>>1) In Windows Hyper-V set a =C2=A0FreeBSD 13.0 VM







>>2) Use Powershell in Admin privileged mode and run following:<=
/div>






>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set-VM=
ComPort -VMName <vm_name> -number 1 -path \\.\pipe\Testpipe







>>2) In another Powershell with Admin privilege run following:






>>3) start the VM and open putty to connect the \\.\pipe\Testpip=
e in serial mode.







>>No output will be seen on putty.







>Not even from the boot loader? That sure sounds like the automatic=
 fallback to simple text output isn't happening.







> 







>What does:







>% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-C=
onOut







>tell you? (Or run as root if you don't like sudo).







> 







>The boot loader grew a non-optional graphics mode that's disab=
led when the boot code







>detects we're talking to a 'serial port' between 12.x =
and 13.x. If you are getting no output







>from the loader at all, I suspect this is likely to blame.







>But the same works in FreeBSD 12.3 and Putty gets the output from =
EFI loader for both x86 and arm64.







>But during kernel booting the console output does not come in Putt=
y, it only comes in vmconnect.exe.







> 







>So on 12.3, kernel output doesn't come out of both? Do you hav=
e boot_multicons=3DYES in your loader.conf?







>If not, only one of the consoles will get output from the kernel.<=
/div>






> 







>Warner







>>Like below :







>>







>>Loading kernel...







>>/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0=
+0x2d095e syms=3D[0x8+0x138120+0x8+0x124824]







>>Loading configured modules...







>>can't find '/boot/entropy'







>>can't find '/etc/hostid'







>>No valid device tree blob found!







>>WARNING! Trying to fire up the kernel, but no device tree blob=
 found!







>>EFI framebuffer information:







>>addr, size =C2=A0 =C2=A0 0xe0000000, 0x800000







>>dimensions =C2=A0 =C2=A0 1024 x 768







>>stride =C2=A0 =C2=A0 =C2=A0 =C2=A0 1024







>>masks =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00ff0000, 0x0000ff00=
, 0x000000ff, 0xff000000 <<<<







>>







>>After this log is not coming in Putty in 12.3 for both x86 and=
 arm64.

























Thanks & Regards,



=C2=A0Souradeep



















--00000000000030e05305e06aa9cf--

From nobody Thu Jun  2 04:52:02 2022
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 C32501B622C2
	for ; Thu,  2 Jun 2022 04:52:05 +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 4LDDBq6PyRz4lTt
	for ; Thu,  2 Jun 2022 04:52:03 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2524q27F044725
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Wed, 1 Jun 2022 21:52:02 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2524q21Q044724
	for freebsd-arm@freebsd.org; Wed, 1 Jun 2022 21:52:02 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 1 Jun 2022 21:52:02 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220602045202.GA44686@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
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: <20220601214401.GA42494@www.zefox.net>
X-Rspamd-Queue-Id: 4LDDBq6PyRz4lTt
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.08 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[zefox.net];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 NEURAL_HAM_SHORT(-0.98)[-0.983];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 19106
Lines: 431

Still having trouble, here's the complete console session:


U-Boot 2021.07 (Apr 21 2022 - 02:17:59 +0000)

DRAM:  948 MiB
RPI 3 Model B (0xa22082)
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: usb dr_mode not found
USB DWC2
scanning bus usb@7e980000 for devices... 5 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
U-Boot> editenv usb_pgood_delay
edit: 19000
U-Boot> usb reset
resetting USB...
Bus usb@7e980000: usb dr_mode not found
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0

Device 0: Vendor: ASMT     Rev: 0    Prod: ASM105x         
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@7e300000.blk...
** Unrecognized filesystem type **
Scanning disk usb_mass_storage.lun0...
** Unrecognized filesystem type **
Found 6 disks
Missing RNG device for EFI_RNG_PROTOCOL
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
688224 bytes read in 23 ms (28.5 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootaa64.efi

[whitespace snipped]


Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk1p1:
FreeBSD/arm64 EFI loader, Revision 1.1
(Sun Jun  7 14:17:41 PDT 2020 bob@www.zefox.org)

   Command line arguments: loader.efi
   Image base: 0x39e83000
   EFI version: 2.80
   EFI Firmware: Das U-Boot (rev 8225.1792)
   Console: comconsole (0)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x174c,0x55aa,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x174c,0x55aa,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
Setting currdev to disk1p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x174c,0x55aa,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x746ed5e9)
Setting currdev to disk1p2:
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x82dcb0 text=0x24c644 data=0x1b9f38 data=0x0+0x34e000 syms=[0x8+0x132ff0+0x8+0x15ac9b]
Loading configured modules...
/boot/kernel/filemon.ko text=0x1867 text=0x19b8 data=0x510+0x20 syms=[0x8+0xd38+0x8+0x7ea]
/boot/kernel/umodem.ko text=0x20e0 text=0x1360 data=0x6d8+0x4 syms=[0x8+0xee8+0x8+0xb46]
/boot/entropy size=0x1000
/etc/hostid size=0x25

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 1 second...  

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
Using DTB provided by EFI at 0x7ef5000.
EFI framebuffer information:
addr, size     0x3eaf0000, 0x10a800
dimensions     656 x 416
stride         656
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
---<>---
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 compliance
Copyright (c) 1992-2022 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-CURRENT #78 main-n255929-47699fc265b: Wed Jun  1 17:33:15 PDT 2022
    bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 14.0.3 (https://github.com/llvm/llvm-project.git llvmorg-14.0.3-0-g1f9140064dfb)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 656x416
module firmware already present!
KLD file umodem.ko is missing dependencies
real memory  = 993984512 (947 MB)
avail memory = 944144384 (900 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
MAP 39f34000 mode 2 pages 1
MAP 39f38000 mode 2 pages 3
MAP 39f3c000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP 3f100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
lintc0:  mem 0x40000000-0x400000ff on simplebus0
intc0:  mem 0x7e00b200-0x7e00b3ff irq 39 on simplebus0
gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 6 on simplebus0
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
usb_nop_xceiv0:  on ofwbus0
bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on simplebus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 9 on simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 11 on simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
iichb0:  mem 0x7e804000-0x7e804fff irq 19 on simplebus0
bcm283x_dwcotg0:  mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0
usbus1 on bcm283x_dwcotg0
bcm_dma0:  mem 0x7e007000-0x7e007eff irq 23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0
bcmwd0:  mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023 on simplebus0
bcmrng0:  mem 0x7e104000-0x7e10400f irq 40 on simplebus0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff irq 48 on simplebus0
mmc0:  on sdhci_bcm0
gpioc1:  on gpio1
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.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 656x416(656x416@0,0) 32bpp
fb0: fbswap: 1, pitch 2624, base 0x3eaf0000, screen_size 1091584
pmu0:  irq 0 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
gpioled0:  on ofwbus0
gpioled0:  failed to map pin
lock order reversal: (sleepable after non-sleepable)
 1st 0xffff000000c4aaa0 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298
 2nd 0xffffa00000dc1c10 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 0xffff0000004c911c at witness_checkorder+0xadc
#1 0xffff000000464730 at _sx_xlock+0x7c
#2 0xffff0000007e2e3c at rpi_fw_gpio_pin_set+0xe8
#3 0xffff0000001c9378 at led_create_state+0x158
#4 0xffff0000001950ec at gpioled_attach+0x290
#5 0xffff000000494420 at device_attach+0x3f8
#6 0xffff000000493f90 at device_probe_and_attach+0x7c
#7 0xffff0000004962dc at bus_generic_new_pass+0xfc
#8 0xffff00000049628c at bus_generic_new_pass+0xac
#9 0xffff00000049628c at bus_generic_new_pass+0xac
#10 0xffff000000491204 at bus_set_pass+0x4c
#11 0xffff0000003e2b38 at mi_startup+0x1fc
#12 0xffff0000000008b8 at virtdone+0x7c
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c4aaa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9568 at witness_debugger+0x5c
#1 0xffff0000004ca764 at witness_warn+0x400
#2 0xffff0000006f9140 at uma_zalloc_debug+0x30
#3 0xffff0000006f8cb4 at uma_zalloc_arg+0x2c
#4 0xffff00000042e328 at malloc+0x94
#5 0xffff0000007d80a8 at bcm2835_firmware_property+0x44
#6 0xffff0000007e2e54 at rpi_fw_gpio_pin_set+0x100
#7 0xffff0000001c9378 at led_create_state+0x158
#8 0xffff0000001950ec at gpioled_attach+0x290
#9 0xffff000000494420 at device_attach+0x3f8
#10 0xffff000000493f90 at device_probe_and_attach+0x7c
#11 0xffff0000004962dc at bus_generic_new_pass+0xfc
#12 0xffff00000049628c at bus_generic_new_pass+0xac
#13 0xffff00000049628c at bus_generic_new_pass+0xac
#14 0xffff000000491204 at bus_set_pass+0x4c
#15 0xffff0000003e2b38 at mi_startup+0x1fc
#16 0xffff0000000008b8 at virtdone+0x7c
uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c4aaa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9568 at witness_debugger+0x5c
#1 0xffff0000004ca764 at witness_warn+0x400
#2 0xffff0000006f9140 at uma_zalloc_debug+0x30
#3 0xffff0000006f8cb4 at uma_zalloc_arg+0x2c
#4 0xffff00000042e328 at malloc+0x94
#5 0xffff000000743ca4 at bounce_bus_dmamem_alloc+0x50
#6 0xffff0000007dab24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d80dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e2e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494420 at device_attach+0x3f8
#12 0xffff000000493f90 at device_probe_and_attach+0x7c
#13 0xffff0000004962dc at bus_generic_new_pass+0xfc
#14 0xffff00000049628c at bus_generic_new_pass+0xac
#15 0xffff00000049628c at bus_generic_new_pass+0xac
#16 0xffff000000491204 at bus_set_pass+0x4c
#17 0xffff0000003e2b38 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 (0xffff000000c4aaa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9568 at witness_debugger+0x5c
#1 0xffff0000004ca764 at witness_warn+0x400
#2 0xffff0000006f9140 at uma_zalloc_debug+0x30
#3 0xffff0000006f8cb4 at uma_zalloc_arg+0x2c
#4 0xffff00000042e328 at malloc+0x94
#5 0xffff000000743cf4 at bounce_bus_dmamem_alloc+0xa0
#6 0xffff0000007dab24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d80dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e2e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494420 at device_attach+0x3f8
#12 0xffff000000493f90 at device_probe_and_attach+0x7c
#13 0xffff0000004962dc at bus_generic_new_pass+0xfc
#14 0xffff00000049628c at bus_generic_new_pass+0xac
#15 0xffff00000049628c at bus_generic_new_pass+0xac
#16 0xffff000000491204 at bus_set_pass+0x4c
#17 0xffff0000003e2b38 at mi_startup+0x1fc
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c4aaa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9568 at witness_debugger+0x5c
#1 0xffff0000004ca764 at witness_warn+0x400
#2 0xffff0000006f9140 at uma_zalloc_debug+0x30
#3 0xffff0000006f8cb4 at uma_zalloc_arg+0x2c
#4 0xffff00000042e328 at malloc+0x94
#5 0xffff000000743d7c at bounce_bus_dmamem_alloc+0x128
#6 0xffff0000007dab24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d80dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e2e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494420 at device_attach+0x3f8
#12 0xffff000000493f90 at device_probe_and_attach+0x7c
#13 0xffff0000004962dc at bus_generic_new_pass+0xfc
#14 0xffff00000049628c at bus_generic_new_pass+0xac
#15 0xffff00000049628c at bus_generic_new_pass+0xac
#16 0xffff000000491204 at bus_set_pass+0x4c
#17 0xffff0000003e2b38 at mi_startup+0x1fc
armv8crypto0: CPU lacks AES instructions
Timecounters tick every 1.000 msec
usbus1: 480Mbps High Speed USB v2.0
iicbus0:  on iichb0
iic0:  on iicbus0
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmcsd0: 64GB  at mmc0 50.0MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
Trying to mount root from ufs:/dev/da0s2a [rw]...
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
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
WARNING: WITNESS option enabled, expect reduced performance.
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1 CAM
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:71:46:4e
Root mount waiting for: usbus1 CAM
ugen1.4:  at usbus1
uhub2 on uhub1
uhub2:  on usbus1
uhub2: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1 CAM
Root mount waiting for: usbus1 CAM
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:0:0: Attached to scbus0
ugen1.6:  at usbus1
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
umass0: detached
Root mount waiting for: CAM
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:0:0: Attached to scbus0
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0s2a
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> 
panic: mountroot: unable to (re-)mount root.
cpuid = 3
time = 32
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x178
panic() at panic+0x44
vfs_mountroot() at vfs_mountroot+0x1858
start_init() at start_init+0x28
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      kdb_enter+0x44: undefined       f907c27f
db> bt
Tracing pid 1 tid 100002 td 0xffffa00000ca2000
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x11c
db_command() at db_command+0x364
db_command_loop() at db_command_loop+0x54
db_trap() at db_trap+0xf8
kdb_trap() at kdb_trap+0x1cc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0xf2000000
kdb_enter() at kdb_enter+0x44
vpanic() at vpanic+0x1b4
panic() at panic+0x44
vfs_mountroot() at vfs_mountroot+0x1858
start_init() at start_init+0x28
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
db> 

Thanks for reading, I hope somebody can make sense of it.....

bob prohaska


From nobody Thu Jun  2 06:47:16 2022
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 39D201B5FE69
	for ; Thu,  2 Jun 2022 06:52:44 +0000 (UTC)
	(envelope-from s199p.wa1k9r@gmail.com)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34])
	(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 4LDGt31xH9z3FBh
	for ; Thu,  2 Jun 2022 06:52:43 +0000 (UTC)
	(envelope-from s199p.wa1k9r@gmail.com)
Received: by mail-vs1-xe34.google.com with SMTP id k4so3762024vsp.3
        for ; Wed, 01 Jun 2022 23:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=KVBWeovhAhFy/ZwIgAjJq/TFUCTV59LK0i7FPA9oGuk=;
        b=RV+GSuyKt5vAc20tMvkYXzJWQ7G1bJhjjoPWBwZ4TsiWd0Nd3s5z+boBNF91dyFP8H
         y0cNLYUFgvtoyYfr6pGPbbTuWWxuWUH9QzW7UGsc5XBz3f8448TUK/uvG0AnHunaxtzd
         x/MlGb47QnXfNiOUn8Xz40rg7X0znH10qRTnVy7gZqn3Nj4WCPiBPAo8hfmN2ZANNj4b
         nN/0x40cFco4CCvsQBegs7IsoZMeGbCL/pNQQYPGnisAiYlA0UtuBKGCsELWmTFThqm1
         Xji+n24tDd/RDtbUKn+coeMCBr/cYE9U70S1xmn2tccl9apGeZtRr2uB0Y7ac78if5V/
         0Whw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=KVBWeovhAhFy/ZwIgAjJq/TFUCTV59LK0i7FPA9oGuk=;
        b=BJEKq30EPbHvPXNBLvE0qr1v1ncxaEMO9n2KebndP6aiV0PL7NNeQ3jql17Uk/z6HF
         Sx1gfxRAelJFkxUpkWBTmBXdwPiuABDykxP0Rn1idWlvkF9fsZM3eTfpfmccucAXPMxf
         jSa8R/5IynWIoaoZlEpyaGECJoflJtrOXD/NSDJ57JXsxcDkb0Y3pWyp2S/h8RpInm0O
         AEHfln6OfXB4pbjhrTzk5mS6qYs7E7zlpCGVPmld90XuhCEHj0kRg4E2sWtzMiJI4tEu
         Z/heYkkTefVC14xEZRjDn6vDwfCX6GaXY+Zg6kK/CKJaIIJM1el6oSS/kuS8Fed4VXMH
         IaBw==
X-Gm-Message-State: AOAM532YsKDGkbYhKK4/9ocELzCWfI7ADiqdsUgkqop93NjHvVpEi8K0
	8YupwwEbz/HOuR32+6U11Gwg6KMDjJFFJ4tTPHVbnH/PRd/fSA==
X-Google-Smtp-Source: ABdhPJwJ1E59DANRnxZfG35F1yXMu171T8WdjSSVfDNb/vPRHOWqVoFFXUcDftety7SdhTO/glLeie5iObWwKpBRoVY=
X-Received: by 2002:a67:6fc3:0:b0:32d:e10:b2f5 with SMTP id
 k186-20020a676fc3000000b0032d0e10b2f5mr1595562vsc.2.1654152762601; Wed, 01
 Jun 2022 23:52:42 -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
From: Sleep Walker 
Date: Thu, 2 Jun 2022 09:47:16 +0300
Message-ID: 
Subject: 
To: Free BSD 
Content-Type: multipart/alternative; boundary="000000000000d1b6d405e0717345"
X-Rspamd-Queue-Id: 4LDGt31xH9z3FBh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=RV+GSuyK;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::e34 as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com
X-Spamd-Result: default: False [-1.79 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_SPAM_SHORT(0.21)[0.210];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 EMPTY_SUBJECT(1.00)[];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4053
Lines: 71

--000000000000d1b6d405e0717345
Content-Type: text/plain; charset="UTF-8"

Hi All!

Can anyone share their experience using FreeBSD on
Marvell ARMADA 7040/8040 boards?
Does Ethernet work on boards like MACCHIATObin
DOUBLE SHOT, SINGLE SHOT, CLEARFOG GT 8K

Does Ethernet 10Gbit/1Gbit SFP and twisted pair work?

Sincerely,
Sergey

-- 
E-Mail: s199p.wa1k9r@gmail.com
Twitter: https://twitter.com/S199pWa1k9r

--000000000000d1b6d405e0717345
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi All!

Can anyone share their=
 experience using FreeBSD on=C2=A0
Marvell ARMADA 7040/8040 boards?
Does Ethernet work on boards like MACCHIATObin
DOUBLE SHOT, SINGLE SHOT=
, CLEARFOG GT 8K

Does Ethernet 10Gbit/1Gbit SFP and twisted pair work?

Sincere=
ly,
Sergey

-- 


--000000000000d1b6d405e0717345--

From nobody Thu Jun  2 10:33:21 2022
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 7F5A41B5A4A9
	for ; Thu,  2 Jun 2022 10:33:34 +0000 (UTC)
	(envelope-from mw@semihalf.com)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129])
	(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 4LDMms5HMTz3nnY
	for ; Thu,  2 Jun 2022 10:33:33 +0000 (UTC)
	(envelope-from mw@semihalf.com)
Received: by mail-lf1-x129.google.com with SMTP id a15so7098332lfb.9
        for ; Thu, 02 Jun 2022 03:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=semihalf-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc:content-transfer-encoding;
        bh=CyRTX2vSl+uZs4jEE5hvdYpxCfpuJVjSLvhE5F2MzCg=;
        b=0iuFzCe9ijEuoT2CDB99xL3H05MRgaCQBCTtTDZcqh4WkLvnvYjy+3Dafjocm8R4RG
         GCUgAhviVsECGx+1F0cDaYd1xtM0vEX0/WRdSxWQbXVC+zaLijO4gmQLCSyOwLpbYzz1
         Gxad/96wnrIOa20Gp/dBIuSVJ1ERmuLYn/05DMyk2NCVonKEUCndPQ7aNAuKaaPSr4B8
         h1LNFN8991DBR5wdVNOQTt726QmWrlFBtVD28fEwBJ+53Hrw8KE3AC5Ek/UUM/HkqjBn
         NJGaShjeCTLHMc4mDg5M85EiNBF5izKatvwB9Tyga7x81DOpMHUKN6ZNJGhS4Lu3NQ2d
         wd+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=CyRTX2vSl+uZs4jEE5hvdYpxCfpuJVjSLvhE5F2MzCg=;
        b=JMvSF0RUKmDXJVZTvFsAozZBoaZpPNcHNSZyK3wwH2vPPRBaw4EEp0Bh5eDrZsXPUl
         xynXmk+8HVGn8cxJC4PN0dlin/IE4SCrt1ZRuP2uvagA90S9t5h647A17V7Gr2PQsvTD
         /2C27cQ1xNGu4EYSvi8WDnIBATw7QG2i4fR/xhDzY/LFqqFl4TtY7BdlgHlnqdZG3VNR
         5RVzRxdsXmPtYaZvNZN/EBsjoVAXZmwoQUJSnLX7NxXOF4QcHWzAyjNHgxmGKmLTXPTp
         Iv2SxYgYSExV6z9e23bQTec9fjaxKZZbXUwNFDu8d25HMmJOZvsYzvargQQTPqo8FWdB
         EVkA==
X-Gm-Message-State: AOAM531ei3y5K8tzNOjHWlgmeNOkTf4E9n1sfv6CF2gS595IbmPC79e9
	0kspiEVvYEvFvm0fBs896mCLju+F7qh+WubMw77b6g==
X-Google-Smtp-Source: ABdhPJwYvI962IsNULOCD0FA9VLXHg9BQAYuNXSk5EFngEkdo4fGv1w5pOhTl3yV0EvTVjYVw5obh/9T/4HzZUpcoZA=
X-Received: by 2002:ac2:54ab:0:b0:477:ca4d:166a with SMTP id
 w11-20020ac254ab000000b00477ca4d166amr3045295lfk.428.1654166012428; Thu, 02
 Jun 2022 03:33:32 -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: Marcin Wojtas 
Date: Thu, 2 Jun 2022 12:33:21 +0200
Message-ID: 
Subject: Re:
To: Sleep Walker 
Cc: Free BSD 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LDMms5HMTz3nnY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=0iuFzCe9;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mw@semihalf.com designates 2a00:1450:4864:20::129 as permitted sender) smtp.mailfrom=mw@semihalf.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112];
	 FREEFALL_USER(0.00)[mw];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[semihalf.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::129:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 689
Lines: 26

Hi,


czw., 2 cze 2022 o 08:53 Sleep Walker  napisa=C5=82=
(a):
>
>
> Hi All!
>
> Can anyone share their experience using FreeBSD on
> Marvell ARMADA 7040/8040 boards?
> Does Ethernet work on boards like MACCHIATObin
> DOUBLE SHOT, SINGLE SHOT, CLEARFOG GT 8K
>
> Does Ethernet 10Gbit/1Gbit SFP and twisted pair work?
>

I occasionally boot with DT, but 99% of time I use Armada 7040/8040
(and their successor SoC: CN913x - based boards) with EDK2 + ACPI,
which I recommend. FreeBSD installs and works really flawlessly.

In none of the hardware description (neither with DT nor ACPI), the
integrated MACs work, as there is no FreeBSD driver.

Best regards,
Marcin

From nobody Thu Jun  2 12:04:26 2022
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 EBA321B69A13
	for ; Thu,  2 Jun 2022 12:04:43 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f])
	(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 4LDPp15LTGz4TDY
	for ; Thu,  2 Jun 2022 12:04:41 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: by mail-ot1-x32f.google.com with SMTP id t22-20020a0568301e3600b0060b333f7a1eso3276009otr.0
        for ; Thu, 02 Jun 2022 05:04:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=message-id:date:mime-version:user-agent:content-language:to:from
         :subject:content-transfer-encoding;
        bh=oKgM/jjbr7+p4OxljSGtSfmFTNYRORiL9j9vA0+tgbk=;
        b=efVl3qjmu2bSzT9DYeoAjzrjwx4Udz75m0lwQWjjENqprfrUUm6nUANEx1CE3AFt4b
         nRR7bmhZE8r8eq74Kwq0t1RbofNiIfm/dJw19lYU3B/vvHVQFn8lbL0LPaFoh+ec/q3D
         TYM2iTCgQLmIy3CbHVp8q1eUXDqKDYLYQcJGA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent
         :content-language:to:from:subject:content-transfer-encoding;
        bh=oKgM/jjbr7+p4OxljSGtSfmFTNYRORiL9j9vA0+tgbk=;
        b=8EA1YmXChZfCUsxm65CdaxuXGJyjMkEG5OLo+TOVgKgUL5zk0S9GwnDjppuRRJBEet
         YpyqZ0oFTWLfa4IABTJn1YHtAPrX75vwxf2m/PDA3Nt9aoQVQyWgalPbhFph1yNxSZcT
         sTGX000SViuQ8XXycXn5jViCyrlrsa2TgdrV7w7LvAO+9zLGp9URE8s9zlnsvrJSD8UI
         e1k17280aWBBQpEhj03RwBbwp/mCLwkoPoBc8F1gbwZKMe7qTJrQsKveNQ1X+mQ84FDk
         lV0PqLVmRTxmoWVJU7fwHwCr3l96NQ8VJXZ7Htjnhm89p2Nc/QTdN2xmt17k5Sy6cZpz
         +TyA==
X-Gm-Message-State: AOAM532RLkcZ2CkPfOlo7uFSYrdK9dN1SYhkEJekSCEb70J+LgCACaAu
	iuU5sTFdiFBWpEvL3HfU5xL2BZ0dWao45g==
X-Google-Smtp-Source: ABdhPJx7Un5tY5xaK+aHvTLnAWtaF+Y/7/C1KcAPthXS8TDegKP4tBo/2M4ooCJzaS/08AOmw+Ut2Q==
X-Received: by 2002:a05:6830:1005:b0:60b:1844:cce2 with SMTP id a5-20020a056830100500b0060b1844cce2mr1780049otp.305.1654171480821;
        Thu, 02 Jun 2022 05:04:40 -0700 (PDT)
Received: from [192.168.1.106] ([200.129.71.97])
        by smtp.gmail.com with ESMTPSA id i3-20020a9d6503000000b0060afaae0e34sm2036096otl.0.2022.06.02.05.04.39
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 02 Jun 2022 05:04:40 -0700 (PDT)
Message-ID: <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
Date: Thu, 2 Jun 2022 09:04:26 -0300
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Otacilio 
Subject: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LDPp15LTGz4TDY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b=efVl3qjm;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of otacilio.neto@bsd.com.br designates 2607:f8b0:4864:20::32f as permitted sender) smtp.mailfrom=otacilio.neto@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DMARC_NA(0.00)[bsd.com.br];
	 DKIM_TRACE(0.00)[bsd.com.br:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1704
Lines: 56

Dears


Yesterday I have finished a upgrade from source code of a FreeBSD 12.2 
to FreeBSD 13.1 running on RPI3. After upgrade, this machine only one 
CPU is detected.

RPI3 with problem

[ota@azul ~]$ cat /var/run/dmesg.boot  | grep CPU
Starting CPU 1 (1)
Starting CPU 1 (2)
Starting CPU 1 (3)
FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
armv8crypto0: CPU lacks AES instructions
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
[ota@azul ~]$ uname -a
FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE 
releng/13.1-n250148-fc952ac2212 GENERIC arm64

Another system running on a rpi4 the CPUs detected and initialized are ok:

RPI4 running OK

[ota@verde ~]$ cat /var/run/dmesg.boot  | grep CPU
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
armv8crypto0: CPU lacks AES instructions
CPU  0: ARM Cortex-A72 r0p3 affinity:  0
CPU  1: ARM Cortex-A72 r0p3 affinity:  1
CPU  2: ARM Cortex-A72 r0p3 affinity:  2
CPU  3: ARM Cortex-A72 r0p3 affinity:  3
[ota@verde ~]$ uname -a
FreeBSD verde 13.1-RELEASE FreeBSD 13.1-RELEASE 
releng/13.1-n250148-fc952ac2212 GENERIC arm64


Someone can give-me a hint about how to solve this?


Thanks a lot


From nobody Thu Jun  2 14:54:45 2022
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 B45C11B67DA1
	for ; Thu,  2 Jun 2022 14:54:55 +0000 (UTC)
	(envelope-from SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LDTZQ4FsBz4nfW
	for ; Thu,  2 Jun 2022 14:54:54 +0000 (UTC)
	(envelope-from SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl)
Date: Thu, 2 Jun 2022 16:54:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1654181686;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=XV5PtZT1H9xdVdUZBN5qYkxQ5X43mpsdzqzkNdaSg9o=;
	b=PtpgRxrIsn57XTDtWHQBwlssRVr+ti9HHNWvpqOLaXv5v+n2xOCa5XKrATNy1+UZLY24Ks
	zUNEdPRdV/w4vO8+B4ACLn6dYxxl4xq0/w/uf/+71v/M+QPaLmXo9J1A8Qi1tfdlPYTBGH
	okpb80yKfGZeRXGoMAeJ3ENmp4fYyWM8G5zpzEgD8yzlN7PX0UtkvLv+IyjflyKOdww5p0
	gdePynSwCze5S5wkN8Ss3TEZcdfBPP921fnf0jh2qnV4hYNAh4HWSHjEBvxy0ZFTnPnRhc
	+iRZrW8GCaP/MOW0XiomwDZsyAMJlN/vOJUjnzhr+Z3Uux9J7fs7Amu0TrvyEQ==
From: Ronald Klop 
To: Otacilio 
Cc: freebsd-arm@freebsd.org
Message-ID: <1047394639.643.1654181685742@localhost>
In-Reply-To: <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
References: <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
Subject: Re: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
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="----=_Part_642_1273730850.1654181685718"
X-Mailer: Realworks (609.136.d556cd5)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LDTZQ4FsBz4nfW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=PtpgRxrI;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.19 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.99)[-0.991];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Sll2=WJ=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 7582
Lines: 209

------=_Part_642_1273730850.1654181685718
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

No solution, just a data point. My RPI3B+ works fine.

$ cat /var/run/dmesg.boot  | grep CPU
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
armv8crypto0: CPU lacks AES instructions
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
CPU  1: ARM Cortex-A53 r0p4 affinity:  1
CPU  2: ARM Cortex-A53 r0p4 affinity:  2
CPU  3: ARM Cortex-A53 r0p4 affinity:  3

$ uname -a
FreeBSD rpi3 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64

$ sysctl hw.model
hw.model: ARM Cortex-A53 r0p4

# ofwdump -a -P model  | head -n5
Node 0x48:
  model:
    52 61 73 70 62 65 72 72 79 20 50 69 20 33 20 4d 6f 64 65 6c
    20 42 20 50 6c 75 73 20 52 65 76 20 31 2e 33 00
    'Raspberry Pi 3 Model B Plus Rev 1.3'

I don't know how to help further, but maybe this gives a difference to dive into.

Regards,
Ronald.

 
Van: Otacilio 
Datum: donderdag, 2 juni 2022 14:04
Aan: freebsd-arm@freebsd.org
Onderwerp: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
> 
> Dears
> 
> 
> Yesterday I have finished a upgrade from source code of a FreeBSD 12.2 to FreeBSD 13.1 running on RPI3. After upgrade, this machine only one CPU is detected.
> 
> RPI3 with problem
> 
> [ota@azul ~]$ cat /var/run/dmesg.boot  | grep CPU
> Starting CPU 1 (1)
> Starting CPU 1 (2)
> Starting CPU 1 (3)
> FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> bcm2835_cpufreq0:  on cpu0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> armv8crypto0: CPU lacks AES instructions
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
> [ota@azul ~]$ uname -a
> FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64
> 
> Another system running on a rpi4 the CPUs detected and initialized are ok:
> 
> RPI4 running OK
> 
> [ota@verde ~]$ cat /var/run/dmesg.boot  | grep CPU
> Starting CPU 1 (1)
> Starting CPU 2 (2)
> Starting CPU 3 (3)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> bcm2835_cpufreq0:  on cpu0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> armv8crypto0: CPU lacks AES instructions
> CPU  0: ARM Cortex-A72 r0p3 affinity:  0
> CPU  1: ARM Cortex-A72 r0p3 affinity:  1
> CPU  2: ARM Cortex-A72 r0p3 affinity:  2
> CPU  3: ARM Cortex-A72 r0p3 affinity:  3
> [ota@verde ~]$ uname -a
> FreeBSD verde 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64
> 
> 
> Someone can give-me a hint about how to solve this?
> 
> 
> Thanks a lot
> 
>  
> 
> 
> 
------=_Part_642_1273730850.1654181685718
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

No solution, just a data point. My RPI3B+ works fine.



$ cat /var/run/dmesg.boot  | grep CPU

Starting CPU 1 (1)

Starting CPU 2 (2)

Starting CPU 3 (3)

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

cpulist0: <Open Firmware CPU Group> on ofwbus0

cpu0: <Open Firmware CPU> on cpulist0

bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

cpu1: <Open Firmware CPU> on cpulist0

cpu2: <Open Firmware CPU> on cpulist0

cpu3: <Open Firmware CPU> on cpulist0

armv8crypto0: CPU lacks AES instructions

CPU  0: ARM Cortex-A53 r0p4 affinity:  0

CPU  1: ARM Cortex-A53 r0p4 affinity:  1

CPU  2: ARM Cortex-A53 r0p4 affinity:  2

CPU  3: ARM Cortex-A53 r0p4 affinity:  3



$ uname -a

FreeBSD rpi3 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64



$ sysctl hw.model

hw.model: ARM Cortex-A53 r0p4



# ofwdump -a -P model  | head -n5

Node 0x48:

  model:

    52 61 73 70 62 65 72 72 79 20 50 69 20 33 20 4d 6f 64 65 6c

    20 42 20 50 6c 75 73 20 52 65 76 20 31 2e 33 00

    'Raspberry Pi 3 Model B Plus Rev 1.3'



I don't know how to help further, but maybe this gives a difference to dive into.



Regards,

Ronald.



 

Van: Otacilio <otacilio.neto@bsd.com.br>

Datum: donderdag, 2 juni 2022 14:04

Aan: freebsd-arm@freebsd.org

Onderwerp: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1







Dears





Yesterday I have finished a upgrade from source code of a FreeBSD 12.2 to FreeBSD 13.1 running on RPI3. After upgrade, this machine only one CPU is detected.



RPI3 with problem



[ota@azul ~]$ cat /var/run/dmesg.boot  | grep CPU

Starting CPU 1 (1)

Starting CPU 1 (2)

Starting CPU 1 (3)

FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs

cpulist0: <Open Firmware CPU Group> on ofwbus0

cpu0: <Open Firmware CPU> on cpulist0

bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

cpu1: <Open Firmware CPU> on cpulist0

cpu2: <Open Firmware CPU> on cpulist0

cpu3: <Open Firmware CPU> on cpulist0

armv8crypto0: CPU lacks AES instructions

CPU  0: ARM Cortex-A53 r0p4 affinity:  0

[ota@azul ~]$ uname -a

FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64



Another system running on a rpi4 the CPUs detected and initialized are ok:



RPI4 running OK



[ota@verde ~]$ cat /var/run/dmesg.boot  | grep CPU

Starting CPU 1 (1)

Starting CPU 2 (2)

Starting CPU 3 (3)

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

cpulist0: <Open Firmware CPU Group> on ofwbus0

cpu0: <Open Firmware CPU> on cpulist0

bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

cpu1: <Open Firmware CPU> on cpulist0

cpu2: <Open Firmware CPU> on cpulist0

cpu3: <Open Firmware CPU> on cpulist0

armv8crypto0: CPU lacks AES instructions

CPU  0: ARM Cortex-A72 r0p3 affinity:  0

CPU  1: ARM Cortex-A72 r0p3 affinity:  1

CPU  2: ARM Cortex-A72 r0p3 affinity:  2

CPU  3: ARM Cortex-A72 r0p3 affinity:  3

[ota@verde ~]$ uname -a

FreeBSD verde 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64





Someone can give-me a hint about how to solve this?





Thanks a lot



 






------=_Part_642_1273730850.1654181685718--

From nobody Thu Jun  2 21:04:28 2022
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 7FCF81B60EEB
	for ; Thu,  2 Jun 2022 21:04:36 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2040.outbound.protection.outlook.com [40.107.89.40])
	(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 4LDdmz2gGVz4dqn
	for ; Thu,  2 Jun 2022 21:04:35 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UIL+W3w/7V7xxxAzxrhh4CH+unsTpg8ZN2vqKl89OYmvras11G8IlqYEF4EUuCwG3mvCkiOPtjY4LI1Z7kZBbCxlwkaHuDOK53mPDozX3BQSBu3quxma3CZ8wGi+FvAOCU8d6xTDr3xQLAHdSQ1TQ5UP1thrUDCpW+qObTh5/P1cYC1lsxPRUQZ8r8xEOnZHVFj9xTmXmMYeem8CjPPX5ZIjwlqCQU0xiu2rn+GwbhHfzlVe+TYqOC5TJJPMUMiDpdJgOahiyGIh+G2rSbFYfc0w04+n1xaNhN+xk4LX3/j68mq9rl/aBoOT1e+gcrDGmBkrqQsZwXSJ1l1SrHQiAA==
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=Zks42O6y/DAODSznRn7iyxDJquFSRicDwmuf2/eT4Dg=;
 b=H6Oti3c6gnpPIM3SDAWcwZlIO+gmFJZhnkWuyIFFSvp4mAJZL2MX2DC/sbMPzhuslPfcQV1ZCiMiVVpd69BvVFOVj0ET0dJEcLE/8Yyg4P4aPuYO6t4EldnkqwheMMI/Hv8YtBwU30JOXEwOcjMmso9MPYS0tkxSEtbD/GLBgZf7bjkMC1EOUm2C8hnpX2qdIAbJUK9eJpPGfZ4X2wrZBxuijrF3bNBw9rme65/anfuGCN1FbFSs2oAHXcYNBs6lZghNiNHtO4iHfXfNTkOwqiXSXA1VNtLvo6TyADSN2julBQ+bfvgdh7/9Y3uv6Zta0zezTjo2eGxA6nOc92mooA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Zks42O6y/DAODSznRn7iyxDJquFSRicDwmuf2/eT4Dg=;
 b=4zS4h38U/iphLGypsJE+sykpFqc52JX3Z8ctzrpM6hpDJVOuPE3a0oOIVprcRz3Dl6ClfhJnajAqtV2tFVM8rdBceNmmkngAFZWpVE9bigC3+yU7XZb32ffJsj20bkgyJaDWTHEr9stohTJ6snthGHzPx764yJKq1g2kfCX6LLR1qCQdaUtgUiLVYnXeGJFe25soD1cA+KprtxtdCoxDIJBjHf01Aq2C5F7TBDYWpGqX4imEJNJlk/9h53aJf2YDgxrVZUbyxrj+EPd56tgz2Czd3oXiluqlRtDlwV2x0UemzUy/PSjMtycvYuXeK7KW8cLV3T+g1WlukBKaYOr8TQ==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by SA0PR09MB7355.namprd09.prod.outlook.com (2603:10b6:806:74::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.13; Thu, 2 Jun
 2022 21:04:29 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::c4fe:8ed8:9b92:766e]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::c4fe:8ed8:9b92:766e%8]) with mapi id 15.20.5314.014; Thu, 2 Jun 2022
 21:04:28 +0000
From: "Wall, Stephen" 
To: "freebsd-arm@FreeBSD.org" 
Subject: FreeBSD build hardware?
Thread-Topic: FreeBSD build hardware?
Thread-Index: Adh2xEPuOivVNUqpSYm7PfLKvCE7eQ==
Date: Thu, 2 Jun 2022 21:04:28 +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-office365-filtering-correlation-id: 085c3fd4-4c97-4657-ef37-08da44db7ba7
x-ms-traffictypediagnostic: SA0PR09MB7355:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 h5ERLf2f/90FNeC1fXAYLHLmsclN3K8bP391qOJHeCk1QuVQpHBiCQcF+j6YNimu4Z6Kmbmg41cGyMGsgH0lFaJFa7zk9aSXQ8avh6hdXWz4n7AwR2xE4uZVmIp0CDmve4Z0OFwNDRo+esyvsMgg8kDArpM54505bPHfJcAeP6WtL2fhfiTZY8HRgyktYWkE+hArP9HpfPT0oFUE9PCAmTJakMja785zoYiEl6tiSW+BJgvA1RLUsBNT4nb7thsjdOd4phyfSD/e67YtnSG7wz4XhASMiCzOQTMTCGR6tsbLMFB9MQhIvrGa8eiQGFnT3G77nfDQng2wgD9VLeQO2s9fFJuZjY0vLetnvvQy8Xq9pkBYEcq2yU+W7E/+iuQuDO7FLhU3CkgbTh0J7vFiW+tgpzrehl5JHa2HgCTRyQYD/YIuOd2V4oVAERUMFUN0oFUBAMA+27sw2FVpJrucEcFT6ZpKWHYGFnflrdiwblLd5rK06Ct+kTi9tSdhHqKbhBlrJUsfKjTSbEXoZkFvzuLV5QiQwNTZbKLM/+uWtOW5vuIsotGK1Nj9Ez70VDza55qoMWvPa3J9qSla7UBOzFqukftvM54nwNIR60kkuVgEn3Hkd0m3ILGxuzncz+YmGCyZNrsNR4dXE5bozo+zPYqt4PBWCnp0bTFJ5173KQMHay/c1dmYnDkYAGGMFPytJfVtsI0+mSQHbpZ8k0ZIsg==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(186003)(2906002)(8936002)(86362001)(26005)(52536014)(33656002)(38100700002)(508600001)(5660300002)(122000001)(9686003)(558084003)(6506007)(7696005)(66946007)(66556008)(66476007)(64756008)(38070700005)(8676002)(66446008)(316002)(76116006)(55016003)(3480700007)(7116003)(6916009)(71200400001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?L0JIeVY2QXZxYXBLbkYyaUcyYko2VUJZZXB2eHRBY3A1OWl3bk1CTHJENkNU?=
 =?utf-8?B?ZzNhNWVGWEsxaWVwdEFlWk1KUGVEdHZNREtoaHVnNzNyTnNibXl4UkV1dUtP?=
 =?utf-8?B?cXJycHllTlVPYmFDVHdhN3YyM0E4VEppK0l0Yy9sZitOUURuRklJaHpaaXhY?=
 =?utf-8?B?SDRBbUt0eGNlMTNFUjdvL0xPUGhGVlVwN04wZkdnK1RmbERZaVlKMDhsWUEw?=
 =?utf-8?B?aVMyOERSQnNZVXNZSE9HRlA3emNhYzhCeEpIWTFUWUJOdU1ZbGZYVGE4WWhO?=
 =?utf-8?B?QmdETEtiWWt0aEtRUk1NamtXWTRLM05PNm54amdqaWp0ZjZYQ1NxelEyWTA3?=
 =?utf-8?B?Q0pVNmllRW0vWXRtT0orcGtLc2F0UDlkWURPL1l1bDlIbER5UUVCbytLVGJO?=
 =?utf-8?B?UFFYMjRtZXlmTXo1dTZzOTBJQVUvNXhyMjNlN1BVLys0bXZaeUFwd0VRKzVO?=
 =?utf-8?B?OVFwTXdwUVlKRmE0R012eDUwbFMzYXhsMTZwSUVNWEdWOURzeVkvUGJWbk5B?=
 =?utf-8?B?RURXT0ZFWkZVUXZRV3BBYmkyR0V0dW5OVXZzVU11QkdIYlZ5b3VoZ0pvK2Zv?=
 =?utf-8?B?SHloOEpJS1N6ZDhVdHplNUszRFZQTEM4VjU0V1BVZFFWZFNaa0x2MHhmMnhI?=
 =?utf-8?B?bFNuWlduOHJEUzZ3dCtMRGN3TTFKQUxKMEJ6aFEvUHZFTHRVMXR5ZzNza1hj?=
 =?utf-8?B?K0J1ZkRFWU9XdERXV1FwTzl2K3JiMXhwWWxKRGhaMG5pcG5rdHl6VjdyVk1K?=
 =?utf-8?B?UW5RbDFvNThpenQ0bVVodEIrV2FhQkg0czdCUE0yQkFZTjZibEdpUURFeUdB?=
 =?utf-8?B?WGxtdXhCWWdvVkE1MTZ4bkpwWGF6NUQ3MFJ1RDhaeFg2WVNCVlMxMitHS2Nr?=
 =?utf-8?B?UlNCWXZibDBJMEJxVkt5cHZrakdCYVV6WE5QR01vVmFCclFFYUhFLzh0ZmFD?=
 =?utf-8?B?eGdQZUtncUt1QlpPQTdKZ1YweUZoUmNNemsrVkZtZ2FxMUxRK2VzdmVOM0hW?=
 =?utf-8?B?MkJrdWxBdTQzY2FKUFFnYm56Q2p3RzI4VTUvT1RYcmExQTdlY2tjK3BTS2k0?=
 =?utf-8?B?d1dST1NoME96RktnZHpWZzFsdG5OS2R5Zm9tY1VicUc0TDhDdWxGekxQd0No?=
 =?utf-8?B?RGdGOUhFcys2azU4cFlEcHVPZ3FsQUpEcEtzSmY4dnllcW9oYTVwTVp0N051?=
 =?utf-8?B?cEVpYWJtcmQybnpqT0lhSk1YcVZaR05RRUxpNmREQ2o0RDh5Z1V3Y2J5TTFy?=
 =?utf-8?B?K2hxK1dUSE9hN0xxRjdRKzJBUkRScFBrOGd1N1AyNEo4QlBRVEoyTTd4SFVY?=
 =?utf-8?B?cFp0L01ZMXZCc2VDTXBERDNyTVIxYS9CTUdJMjIwR1kwR2I0YlA0RmpxMnh0?=
 =?utf-8?B?V2w1RmU3WFEzYjRpeHpaUWxLSlJkOVh6cktvQlFCRUl0c1ludS85K1FFamRO?=
 =?utf-8?B?QjdCVDViRk5ZYkJ1R0kyaHphTGdjUGd6WEVjUzRIcXVHOVVQWkQxeXVYLzFa?=
 =?utf-8?B?VUxoa2phQUY1M2dRcm1rdjVMSU5YZHpPS0JLK21BQ1BQYi9ZdGdWVzR0SXRX?=
 =?utf-8?B?YTg0OTd5OVFZVnNFcUFFWnlMNHFlemE1dEI4VmFoRDdscmducTFVVTd5YS85?=
 =?utf-8?B?YXdPdGJHdzl2VnNlWVdYREhUNTlTbzBNRExUYWUxSytLcW1zQnNCblBkTFZU?=
 =?utf-8?B?ejhMZWJ3NVFwcGt4Y29UcGxXQWwyUENEK2dneGR6eVFUQW15QlQ2d1dRUHEr?=
 =?utf-8?B?S2xoSisrK1RGVU5ZbzV3V2VkR2UweFQwQTBmUkNoK0QxLy9waTFmUGRLVmY2?=
 =?utf-8?B?MlBjajhzUWoyWTg2b242ekdBM0xaVjY1WkpjYWdoUURnUGdwVGVhazJDL003?=
 =?utf-8?B?bXNPckZORDNwYVRGTlpOdmpESkF2VlkrdUFsaHJBdUVoS2pZVmgrSWRZTng5?=
 =?utf-8?B?NW5KZDQ1M0ZBWFRxL2ViNG1jbGVlSjM2VU1GL2VXYzAwT01pSlF0b0pFbGk2?=
 =?utf-8?B?c1Q0cS9FOUdxWUZ4R09DU1J0Szg2WjRRZWxHSlFzWm5IbWgxM1dkYnUydWVo?=
 =?utf-8?B?V3FvaFBScTZ2Zm5rZ2tjdjJnVGRYaU43UndZeEU2empHT3pJYmJBL1U5WHZj?=
 =?utf-8?B?b2Q1Z1hCTWRrd2lRQmpKUGlTNE11b0cvYnd4L0tXNmxBaG9Xd3NNaGk5KzBz?=
 =?utf-8?B?N1QxdStObUpzN3BaU2NXZjVxMjYzdWd5MWZjdjdLdFpibmlHL0lDMjN2enor?=
 =?utf-8?B?ZFJPSjZYQ2pyeW1kbnRkTFE0NUZ4NFE1UmpHdlMzb3dFSGYzZVNzRGdXbHgy?=
 =?utf-8?Q?K62+kncBjTccQAfydt?=
Content-Type: multipart/alternative;
	boundary="_000_MN2PR09MB466771CE27C1C6D134B6ABB1EEDE9MN2PR09MB4667namp_"
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 085c3fd4-4c97-4657-ef37-08da44db7ba7
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2022 21:04:28.8851
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB7355
X-Rspamd-Queue-Id: 4LDdmz2gGVz4dqn
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=4zS4h38U;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.89.40 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-2.38 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[redcom.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.89.40:from];
	 NEURAL_HAM_SHORT(-0.98)[-0.976];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.89.40:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2838
Lines: 44

--_000_MN2PR09MB466771CE27C1C6D134B6ABB1EEDE9MN2PR09MB4667namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RG9lcyBhbnlvbmUga25vdyB3aGF0IGhhcmR3YXJlIEZyZWVCU0QgaXMgdXNpbmcgdG8gYnVpbGQg
dGhlIEFSTSByZWxlYXNlcyBvZiBGcmVlQlNEIDEzPw0KDQpUaGFua3MNCi1TdGV2ZQ0K

--_000_MN2PR09MB466771CE27C1C6D134B6ABB1EEDE9MN2PR09MB4667namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1
NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyBhbnlvbmUg
a25vdyB3aGF0IGhhcmR3YXJlIEZyZWVCU0QgaXMgdXNpbmcgdG8gYnVpbGQgdGhlIEFSTSByZWxl
YXNlcyBvZiBGcmVlQlNEIDEzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1TdGV2ZTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_MN2PR09MB466771CE27C1C6D134B6ABB1EEDE9MN2PR09MB4667namp_--

From nobody Thu Jun  2 23:00:00 2022
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 DEFF01B50B99
	for ; Thu,  2 Jun 2022 23:00:06 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LDhLG58cDz4vRV;
	Thu,  2 Jun 2022 23:00:06 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654210806;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=US9jxTYO56NALIzubnd0BnqcbPZd9Zwrn1c8KRH0Z7A=;
	b=Di0vmnbPz1gkLosIHga2k6Z8tSQ1vve+TIGRTPB5o5/n/yOMrB0kIYtPawSRL63T30mdq4
	b+FxPn/UCMAa+QgzcDrjXPbPDz+QBU6TtMgDbRgB9IZKRVOh7m+kE9fXX4uO8WM/u7M0i3
	KvOathhnHc6LdnH7PqsnZ5uE/BYfWd7uuOuT0yDdz3XXcNZ09AfO9TFX1xKD7NW7RkM3nX
	E25XWOjpD1dnRgIs6hxtSR6QNEmXMgMTXvvx/pWjHi3VrlPyOBJ6+Q4tO5A8dDkTpn/OOv
	dq1TCuwemHqDseWUinghr+6xOpMfcc8cPYn8ys4tbnimydWK/DTQUf3IB8ZQYw==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id 2307118BC7;
	Thu,  2 Jun 2022 23:00:06 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Thu, 2 Jun 2022 23:00:00 +0000
From: Glen Barber 
To: "Wall, Stephen" 
Cc: "freebsd-arm@FreeBSD.org" 
Subject: Re: FreeBSD build hardware?
Message-ID: <20220602230000.GL30607@FreeBSD.org>
References: 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="b0R8ugpUbPHtGZft"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654210806;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=US9jxTYO56NALIzubnd0BnqcbPZd9Zwrn1c8KRH0Z7A=;
	b=AODb9HgUS5fM8sv08bjOk530l4I7lPjCGBw9QaHpsUMOom8Wxe0BfPj7KDlj9L7M9rUBE6
	0ll/O74ZcnulbZouK569FJrkcv8k2GArKT38tKyS2//SUu229lv1XzEdMcOHw0c89cPiI7
	L+xe9Qwu3wS+WFnZAmtro3d4KQnY3xj7hOcUIK0c55/EDmIdIDTRMqeBYWRbMVKHnSAbqR
	2LCAGnC54q7qXZZ+MHkLbnOYb75+PIRb+bE8gzAEjuEEnycaWiYIcNgWWOPC2/Yb6Wib4e
	i0lv6higmbf5rxbyNaJIKzR+VromMghlr5pHFP+UkPtxc/tDtQQoJpwrf35MCg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654210806; a=rsa-sha256; cv=none;
	b=GlTzzMgS5w+s/vJ2z+SVk2X8IL+BUCxfWgRoZDf9jDebGveAeUE35vflFZII8cpKR08O4t
	NSS0yEOY3W5tmyOAS+sEOXtGd1qoFY2Htrlm8IFgty3pHWveEd3N5ChGOPpafCcs5MSz23
	dy3sHBUVlbWX5QXuylzLBIe5IgQmLWCq/bJF+t0xGIAX2twzyQlVJL3OYx+DhS72KBS0vh
	sd/FSpKa//XCxR4AMfsNzedSeRTi14h4HEiac5BGxKv8ICgAI/CVXF5vbFVPR/XlU1NRe2
	DGrc8nHQiaHoPVxdfS845iPq65er29brrmoG9O0g6EK3VVDQRxX6l2bCVJaYgA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1283
Lines: 37


--b0R8ugpUbPHtGZft
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> Does anyone know what hardware FreeBSD is using to build the ARM releases=
 of FreeBSD 13?
>=20

They are cross-built on amd64 hardware.

Glen


--b0R8ugpUbPHtGZft
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmKZQPAACgkQAxRYpUeP
4pMWmA/6Aw14cnmNMxr3p5lczPb1LE19+URN78UqzEuIih1KPWnos0Sgo/Fa8yuj
QYIAjbBoRbJ3hC0Yvvbo+6/GIwcZDJuJJRRGUh1ah/N5KLjHMYF1vQZ1NXHGlqIj
TF9a2TqgXQcwFUA9q9vCWdRjsusi61GVMPjtHfaXpYdPfLqxF37gBVPZKtEBh8GL
WXjHIvl+OOZH3G+Fy7a/wmLGRTIZyvFC7ssnMc7kWzNxDmLh6ZaQrek6DxIDatJU
P75stU+O76s6Haqzo5YcBkqKkjwom6ll75A+wQylGqZKg6WDxmRVqOgEdRd9Xm0x
/gl1lYJgRYy0MBm8gQ2gZUpe1qLWjgtlLl9IlnY+vamJ92fuBmPTk6UHApSy2npn
pX3CFJxNSpM3URlddUEhbdNRPGCk+JC6wHfy33HBPqnMXqjwMUEECjglWE0SbPBK
ZvVQT+4y0wr13DF3L6qsYqTNb3ntCjKNc7hWV5QeIeyyAbgSM+e2TgXx9RV/LmYQ
6ZlIPoA0xB9yxIh8wtNzmlT2BQVbJzEi0On4H+zTKUxP6hbbUjByKXj3qNWYISgA
Ka56x3dA8JIMckoYxwbjAYAEbXbUJ0vyockKpMsSMa+PZ27qJcn98KQv3C0f0C+E
6B7FyVR/ya13hmu5S2ZEzzw9a8o7P4htvwwxpx4sT+cACgb6jpY=
=t7HV
-----END PGP SIGNATURE-----

--b0R8ugpUbPHtGZft--

From nobody Thu Jun  2 23:10:23 2022
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 AD6D11B53923
	for ; Thu,  2 Jun 2022 23:10:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4LDhZJ59z3z3DTg
	for ; Thu,  2 Jun 2022 23:10:32 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654211425; bh=kV0QvsKg1anV8P0nGnZvku8almvryY6ZKx2QpGuzaPE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OfTgVXCMCwo1b7EOA2FGUYFA+RL2BVoSOMp9RpGXn/qU9ikVSDWIxI8cpOyqPuKQ9oNWZZeLC5w2UpTXzommhghKggCd84O5IznS8GA/jnGYNBX4l3IY0XmKqifK6vcvjkQtJ6T3d6YS1/BtFPnWNDfgnE9MNtqMCiPM7yTZpSvPBCay5xnMUdpT9qJyaRCZwj9ob2fUmebeSMnuURR7j+OKGQ0SaocHHIAcV7pM7zDKR88fdnTjtrmOako1YRozdf0S1k+XfqbGcjpLqB+mkqEPw5Fg/r3Tto7HSL46zVaiPeLji/8k/5uLenv1Ylg57U3IEDh4Otb+UDe8QfBSXQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654211425; bh=Ab8/5DYhdbuAipJRuU4dZPse9mK33YGf6+RqcnhgRKf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=aAJM4wS4+xWsnYeW1Td0mCIxbIiIe/y3RNTlSjMHwXt3KXsFRcq14yJFViMiOoknKa1dsKHxOPHHVdD3eRakHrVlLxZqTvrYOnn4vnwkpUJ3kG7NU0/KfHEOG9I3xtfNMMT6IfA/a6HPkadOAihUeG+YspknKGRWu9Iu27ROUXBovUze1zrPqWss8PISIdiafW/tR3ZVYVo144E18kAqd+K+3lDA8mKj8HyREpalIJymQm4gUFtzf8qHzFdKribN4twoKOpUS8d+oRvbejILTCpghin1t+CUT48wKbiNVK6owloSgi+RBee2NKcgQvjlyEASDOptUpgwXEYveeLONA==
X-YMail-OSG: uQq7HmcVM1ludxPuE5WVNNE.aN0Vj6yRYM76iYJMRv79anwhHlAjw2FepMEr4Fe
 hw8AvHeBuo_bq1E9d8AnNGWL5O7BcOYd3asiQ0owuPczmbptZaUlBUoMj_P6U.LdvA486Slc3Jii
 rieTq1_jP6nr3AuSYtF8YvbE6RXj4E4SAoBW9KJD9bY68naZb2jPb8El6Rkkcx620uajwppff0Xs
 L9Ph3SFHWUV8DSpnrlYc6ZjAuKDpFdGq42x4YkouMfPnjv3EdzoYN20WqW48UMGP55_ye.0uzMsH
 AmY2498BxzH190ih61RZMBSW6X5BTF_XKruxY2VGh92UO7zMZP0Bk9LbSB.zJhpKLiXn9RDJ4.0l
 IKF209NHh5Tb9ZlQf2dEXQ.h7Z8zK8QV0T.1KuKnAZLPhYaG363XGum19dmRgx2luz2YzU7qh_Ub
 X7fXaR5mgTZcT7Vb56CUeST7voafBRalifjg2IpByMhQHe6L9xIKNLXDRrb04w9pUGboUSkjIGT1
 BfFmdQ3KDfkqN2ulC6c6Xo48Db_o0LJxPAqzBNnE4_PioqzHDa2L55zu84fNp5eqAGQ1rpV3xnbZ
 XG1hfVvB72tm4hQRbwf1kLlbs4DVfXskEsxQBlutFfdAXxqaJD4Lm66.MfCVG8.sSiyy97__M7gy
 BLJqmJZvB1J6NtOciP0iwlmR2wGlVGrlCLBZld4rZ0rqVOj6V.IGp0IBIuch_leGi2tev55TBpzw
 MxyburNOwbyIPGdu7eLH0RZIHEAQ0Q.g4KUTndE5zNUd4KZbARl_GYsnpdkyr_gQ9Tlu4cH125Da
 lA8kkAjY_fv7GB8Sr7Ibw.bkyD66WZExzEWVc.ajo4n_v.eIhgOiTeczow7TArJJLKhqTTy3geKv
 rlpfZFrN8LF4emRQyUebvcfN6FVcICeJRhzRyFeC1GceY9EWYtXetrCjZIP4K9T5Ul45ZZS.FRLI
 zMtOSOZxH1gI1APy4rSm6pNcLL2pZfVXKcwOOGrm19ok6vhZnH62hIiHFJRpQep0DyvGdAqawTA3
 8gWkRWS0j..L.Lcm4HhZXYlCcpciv7k_hGgUbKld5Q71EzYzs3yb6D9bgCVUFBfvg_8Fww1viz_8
 5SuvLd.xV_p4Kp_17OUbpZdV9.x3A_8vwGD8YOlzKhxdikLjukN7rL_lK3FVuUvyH816HxyKFLYB
 YVehDGfYq75Y6ugJJPEzE1Db9SqTlJWvRUNs5t2MqQYAa8_4wLMkhAl9pNPXrzkxja9NICw7.613
 H7zU5xC19bdMsJ.dEC.cU3lpycP_psfmRcRJmlyzcHT.BpyWHQoAk67n23eQ_oqIiF33wkp3j7O9
 oZxW9KWBy3xMnrKrixQOowL6smuyihYjY1XTXPQxyDkKlo.mmwfj5yh1iaG0L1Re7UujKv0MIGU3
 JFvMCIdzYqIVKPqgkPu4.5GFCWRuA1b5CvtvOAbP6fEj.wl3UqkwBoE0aBRXtnNFONe9li6qzEzt
 lqFzvjVVbk_9_3tmBJpNa44IZLVs3BxAxTxd2z73rclqYL_TY4EQQ0KwOge8W.IRJPHr0YXfombb
 puCemncUL.hMvCTpRyfB46_mW81XcnoaY1wzu_9KBUORDSxXR6PpVnuOqav2pC3AdVtYyae7tSj3
 _MtQh2eYnBGkr9OSMyZFrK8mvj7V9GlYhV8WM0cVxRlta6lgEM36d3hDDWx9SQcqlTKooPFVuLu6
 X19R6RGhX05cZAncGw0eAWpJxDd_2vJJPB4G7h4Ty1BgjtlCcVur5t.jo.2az09no1P7iI2gbIoG
 e.dZGHImkKFSAJXAZuyqkP7AIuyqfBPVfYoqcHANt6tTAp0ib4GXurUBvUmVpgfaRAH8OHxXROTd
 YQYjnuBZctvali.sGUIgUPgGW5WJPe3o8.iAgfZ5t0ZVwlLQch0uGWPZA4IfA71sOFfYeXI4TNqm
 1hIHb4FZN74n9Qu3c..8eUD_zLAGlejkj1Zb5vS0YKzhxTvLGnAKkx4zgnAPW6n9Grdznv8prSzF
 eoc8Vn72LzpjuOJX27HfIL1yHRJHnVvvmV4Osb2EEsxG5eZ0.M0LgOFTzSXD7.q8oGx28LDIuD3e
 NA_g2f3xanyQ62AEGwspPFukrwzLU0xqJMrHVAIVBZzkWjcUiya7sw4cJ8SL.RzofOw2opVnTSdM
 BsvObRv8OUrjSg4zYGbAyxEpDWlu5CfxU0VdTaMsQI1h6UtW2DYuLnrVzgDyAv9i5mbiGc.YbVKd
 IyP9aXyOAWmm09pUBBD_rNcTkUXhjC6TPqepmDWH8tWSohkxRD5orhkMk2O8FOy2TBUExJs2M0bB
 loYbvGf3t7kjvig--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Jun 2022 23:10:25 +0000
Received: by hermes--canary-production-gq1-54945cc758-mg5mc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a7350bc54e97d1c10d4610cf054566d8;
          Thu, 02 Jun 2022 23:10:23 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FreeBSD build hardware?
From: Mark Millard 
In-Reply-To: <20220602230000.GL30607@FreeBSD.org>
Date: Thu, 2 Jun 2022 16:10:23 -0700
Cc: Glen Barber ,
 "freebsd-arm@FreeBSD.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20220602230000.GL30607@FreeBSD.org>
To: "Wall, Stephen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LDhZJ59z3z3DTg
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OfTgVXCM;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 488
Lines: 19

On 2022-Jun-2, at 16:00, Glen Barber  wrote:

> On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
>> Does anyone know what hardware FreeBSD is using to build the ARM =
releases of FreeBSD 13?
>>=20
>=20
> They are cross-built on amd64 hardware.
>=20

It was unclear to me if the original question was trying
to span aarch64 as well vs., say, just spanning armv7/armv6.

aarch64 may well have a different answer.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Jun  2 23:50:57 2022
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 969D21B5ABE5
	for ; Thu,  2 Jun 2022 23:51:10 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f])
	(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 4LDjTB3j8rz3HlC;
	Thu,  2 Jun 2022 23:51:10 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yb1-xb2f.google.com with SMTP id r82so11004570ybc.13;
        Thu, 02 Jun 2022 16:51:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=MAH/of4dEHPPl/wUmMXGc9tMCYd88/GRZzY+eJ6oX5g=;
        b=J6pCjoRZa6EuRliFGjw6H384Kr0mop1oZILxrsjVnSMBRBpkRKwunUaZtKpw2T+dsA
         qa7V/FS8YsA1tZoUXlILrgMSJJ/lQ55QVqi4FT8KKMJhFok3A6WLc8FNbRmHINiecpJp
         vMUkczR9/ejZpd9D/uQ/SeExeaZLip4zsUp/m08uNvF1Qx7knG3X3QfnZWqk5h8TtAA1
         7boxzMI+b3URC0mq4l2zc1RvgtjNS3P2Tv8xSZjcvVL/VKPIHzIvD6Y3mO5Ymc6NmyBI
         xFtME9IQ3ZjFvBSG2Uroy+0/SdMn8An6HJRSBxsR8cJgQOHuoNQhOIocmgWf70eNrpeG
         JQxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=MAH/of4dEHPPl/wUmMXGc9tMCYd88/GRZzY+eJ6oX5g=;
        b=1ArRTBX0QbuFO5aFU0p1+QBVOruVMX8IyJYhPJandTUb/WmSu5IL0ThFZ3lUDrAtfX
         T/ZEuCx5l6SDJKcFIeA4qEMir7PJw9xMOQvbuBMOg/JD6i1GL413IHelu2hZe8HMPkom
         E7o2G95yryRF7VebWzzqQ+8p5Wivy1rxAs5SRLdn9S6U89KJRF3sWmelXRxn7T071aD5
         S0XePz2CCdfybUHFGyWafyGGlypwsu7eEAdvO98OBaeIr1MGHTR9PS/PNJtkhImi9sg5
         qEDmxclknlYWX6s8BS976lrefX7H0s7wEqWVW1U67+2rcNYMenuSBX2EuzANhUfNmvJC
         0Qew==
X-Gm-Message-State: AOAM5309dgF7Q4lyrxKyU6DRnYFWoJO/yx27P9BEuMDxFsgdKiFOrE7h
	p/1M9KcaG6VOXIJFpMRyKwid/lmtTjlzNtBZHGo=
X-Google-Smtp-Source: ABdhPJxQGGSBWPeZY9axZLC2TqVqGYatuFsX3eFPM7MDvKmr+CMxczZ1ek6oeF4EYOVnUboA4eNiRQVmxSd0JW1WGLI=
X-Received: by 2002:a25:814b:0:b0:650:db5:6ba with SMTP id j11-20020a25814b000000b006500db506bamr8182628ybm.237.1654213869906;
 Thu, 02 Jun 2022 16:51:09 -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: 
 <20220602230000.GL30607@FreeBSD.org> 
In-Reply-To: 
From: Robert Montano 
Date: Thu, 2 Jun 2022 16:50:57 -0700
Message-ID: 
Subject: Re: FreeBSD build hardware?
To: Mark Millard 
Cc: "Wall, Stephen" , Glen Barber , 
	"freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="000000000000192f0c05e07faedc"
X-Rspamd-Queue-Id: 4LDjTB3j8rz3HlC
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [-4.00 / 15.00];
	 REPLY(-4.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1850
Lines: 62

--000000000000192f0c05e07faedc
Content-Type: text/plain; charset="UTF-8"

Thank you

On Thu, Jun 2, 2022, 4:10 PM Mark Millard  wrote:

> On 2022-Jun-2, at 16:00, Glen Barber  wrote:
>
> > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> >> Does anyone know what hardware FreeBSD is using to build the ARM
> releases of FreeBSD 13?
> >>
> >
> > They are cross-built on amd64 hardware.
> >
>
> It was unclear to me if the original question was trying
> to span aarch64 as well vs., say, just spanning armv7/armv6.
>
> aarch64 may well have a different answer.
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--000000000000192f0c05e07faedc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you

On Thu, Jun 2, 2022, 4:10 PM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Jun-2, at 16:00, Glen Barber <g=
jb@FreeBSD.org> wrote:



> On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:

>> Does anyone know what hardware FreeBSD is using to build the ARM r=
eleases of FreeBSD 13?

>> 

> 

> They are cross-built on amd64 hardware.

> 



It was unclear to me if the original question was trying

to span aarch64 as well vs., say, just spanning armv7/armv6.



aarch64 may well have a different answer.



=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--000000000000192f0c05e07faedc--

From nobody Fri Jun  3 00:04:28 2022
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 A316B1B5D7AA
	for ; Fri,  3 Jun 2022 00:04:35 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LDjmg3vQ5z3Jnv;
	Fri,  3 Jun 2022 00:04:35 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654214675;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=aFBNdWTHZGjayZkHgbb4BUpHEgdMicx5T6JeIMWUBNk=;
	b=W5awjWC5KL5kcZ44b4TV84fh/ayMHgxQHNMxZnwoL5FB0drIRvK1BgJlZh/XTgVmzOfiuc
	bS9PYkQF2YIhNxn3VyXUug+qLFSL6uJC9aPOJTgE6+8u9l4QxDulcyMhv6cY1Ox5rDBJ0E
	bjkFJp9jvl+gS+hTqNN0I8CT8hvGOscRLmqfeLm+Zq60/9QNR8xO2mBkazLQ82gV9LAN9d
	uojQc1rqQN845i4T7Oow8S3bszixN8TQWVeAia9/VNGoRQ14OZPBUp78ASrsFIqZa5squ2
	0sDGsbjvz7kIKhz+vhQVRZMeLLFxDL+6PzRkkU61l/bY16Jwwma4pbiqnNVXbw==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id 0F71418EF6;
	Fri,  3 Jun 2022 00:04:35 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Fri, 3 Jun 2022 00:04:28 +0000
From: Glen Barber 
To: Mark Millard 
Cc: "Wall, Stephen" ,
	"freebsd-arm@FreeBSD.org" 
Subject: Re: FreeBSD build hardware?
Message-ID: <20220603000428.GM30607@FreeBSD.org>
References: 
 <20220602230000.GL30607@FreeBSD.org>
 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="roRPt/Cw7eYGd+Rv"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654214675;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=aFBNdWTHZGjayZkHgbb4BUpHEgdMicx5T6JeIMWUBNk=;
	b=A6zqE2IFGXJzOrKzSlDx+M7ChuqJWWCj4gPP3PlhmfsgaDGYRH/Bfy9utFOLvEiEmIR0vp
	m+h5Ia6aAEt9ZOCM55koS4qzhokbMUN1qfjFwbTN2dudDp6AmKLTeiqNa87AYqg8b5SOQI
	AUfMmO1a6hT5asbB56tU8VI8e541Ow6b4YShndHBYeNuV971+qmWJPopu5MJq+pWvC+5UC
	zVEsxF9Kw4F92XG13Go3ljJEw1LraEKWY6rOicJ2hjEOssKy7NuvHDasfJOfH2dObkXSt6
	wiaNURWjvPgb2pIUg8A/8V8kb3tKbL/aZW24bQz1+ow62nMug1bGxSdc2iE3Tw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654214675; a=rsa-sha256; cv=none;
	b=DG2Bg5r6se03jDrBz7TS2A0N6+uvDQunVDyDyIc5GwdE9Bvjnr82GMBGKSQCaOVHq6IrlV
	8YtP2Vj/c4gXBkMPunqVa86yWrzL8YJmTNH318DgQEVKnrvpU6BIuHdDfpDbioHiKYQDCv
	VU89ccwvAgNcl2q7k7uxu+qzeH9ibctnv9Gd8Kqg4owgRmTQjdEhSHh9gVfy4Gr8wb9WNs
	+AySrufTofeP0hwjIGGTvmHid89fvBF9DqIdA9Tt51da/QHHwnBPPVSetRB5D4f6vh0nyg
	JGyaSEA1dFdeVKbj9veqVPECZoYJxMWS/JTsY3ZgczfWalJOn9ySFMFQlSohlg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1675
Lines: 49


--roRPt/Cw7eYGd+Rv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:
> On 2022-Jun-2, at 16:00, Glen Barber  wrote:
>=20
> > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> >> Does anyone know what hardware FreeBSD is using to build the ARM relea=
ses of FreeBSD 13?
> >>=20
> >=20
> > They are cross-built on amd64 hardware.
> >=20
>=20
> It was unclear to me if the original question was trying
> to span aarch64 as well vs., say, just spanning armv7/armv6.
>=20
> aarch64 may well have a different answer.
>=20

No.  All architectures are built on amd64 hardware.

Glen


--roRPt/Cw7eYGd+Rv
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmKZUAwACgkQAxRYpUeP
4pMdag/+KEXPl+1PeWb0yWbsMmCLrWuJYJecqIdybpT1z3OWmY3dPojwL8Nb1+tK
Q3axBTpdN4a3BfzUgACSMKxjNcvZ3RmOEhWbuGowMIr+NHJhG7hsEQ9wM8Gfub2Y
hUYBnyID1bgZ/wYN4xtEhiH4PTZ5kBlvuQCjlBEiJQ4vLorBt9zapOy6HKbDL45U
mo0qgCImwhBMQiD51LFaZDfWm3aOIQUGa4neJ6z+G3IS80dn0Od95IfqO3GDQgJ1
xUGmx3Yb5P+xgmwqAmfy27y4sQbG0easHRSjS/wCLXW6nbp74WBRX7xPwfAVyQua
0M8jwFAwBs9llZ85rRKPNhrP6Y2B64nmm32ga89WcqqV2g4DCDRlZUlaPr3Xdrbw
EndvXJE5EWCMByV900/k54TWrTcJmpolNf29tqCBQ8c+Zo1NT410lX4uNv3zGBy4
eFY+RvMnh9hY6rj2mvc4Mz2ihQzcS6JhvSTx5p+k6DXwpj7j3hVtLTURV2HL55Hv
JDfCc+IVtmSv8UCCEL2MoQx7K0BTuodCixhvxqha32MhwUmMJCd4q+8QRLlq3wUZ
/MBt4nARLDqptGmOSQKdNiN/m+2JV0TjFuAdwZNetpHash09JCxGXTf/h+cJBiL1
Tn8HmptBKHQ0d/o8N30Uax/4TIzXVJqf4hkr7picpLnhMjTBdng=
=Mrh0
-----END PGP SIGNATURE-----

--roRPt/Cw7eYGd+Rv--

From nobody Fri Jun  3 00:07:10 2022
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 451FA1B5DA54
	for ; Fri,  3 Jun 2022 00:07:25 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a])
	(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 4LDjqw5D1Rz3KTm;
	Fri,  3 Jun 2022 00:07:24 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yb1-xb2a.google.com with SMTP id l204so11083610ybf.10;
        Thu, 02 Jun 2022 17:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=u4mvMjAUj+AtBapZS9v9ISM7Fgs+MiIB++kcKk5Pr4s=;
        b=FXiieL3cv2T7dLuSSgrMvnpsZf2dW4Gs4caT79wSkSuPQ3leN9WWOBBaypnOOCumKs
         2HItZELGXtnv+Za/VI1QUqwMGmbsvY0QYKIh2FdNsh89sQF/XEed2+Clz15hMzePTubm
         TpGUoEy+4QraMkYExFJAyZQ6J8znxVWeyuEjxxpib3JArrS3ffyE7JyQVklc3nUH9aQ+
         CCfUVq940YLUurruJzk7bfof2ZzpT5g2g6pxXA8N2r2aP8/FEKvAS9KDbmFeXHWMzesS
         CRDH6nviBKgfb/v7pmyizjMR1s3H1+AYdZURuWgUueD3QJ+55CZw4vVBsMsl1vXQ+Dhh
         /Qeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=u4mvMjAUj+AtBapZS9v9ISM7Fgs+MiIB++kcKk5Pr4s=;
        b=J8BZ73bsfJcN5E+gmPKbBep9QwiHIa9u/QDY8JBjTJuH0NR6GCCQ+53zo8gapE15AE
         T3z6vWLDR214ER2d8HcAkD8wKd4AekA740rbbZ5wSZOkSS9SuHHIrf2ArTC2cjPDS6/n
         kR86fIXs38yO4BRpPBBDQXdfvAjZDWh0Wpnf7u3vsbuiyF/MWJfqkcmdo+mo9nEgwEa8
         YcmpaVb/4xiji0rQVWdF13sIIEEF9U2LbkpnEuBj1qr7Ikn2llwcjCWMyOq481HWEVqQ
         SzMC+rNudg7aU34tPXuZk42TcSstONymJAGPVm9B5Cbg7RJ9QL6VKUvmGHxag3EIbdBs
         YDdg==
X-Gm-Message-State: AOAM533QVGXINd+gCYVlp84mw+ok1fpF3iUaImjehqHIpPsXISM14ft+
	IsSMUD+Dx/VOPHyHl/AlxvHEDcm2iy2OW2PwtVuVFBG8jy4=
X-Google-Smtp-Source: ABdhPJyZWQR7cOY6lU7RA4NlHGsZziRqb0SQbfD/ClYSyORd2yw+Eu0PFYZ7Qqj4S03EFzhA1Jtt4y1Wqx57NT+sOUY=
X-Received: by 2002:a25:6155:0:b0:65d:3a65:a801 with SMTP id
 v82-20020a256155000000b0065d3a65a801mr8321332ybb.224.1654214844172; Thu, 02
 Jun 2022 17:07:24 -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: 
 <20220602230000.GL30607@FreeBSD.org> 
 <20220603000428.GM30607@FreeBSD.org>
In-Reply-To: <20220603000428.GM30607@FreeBSD.org>
From: Robert Montano 
Date: Thu, 2 Jun 2022 17:07:10 -0700
Message-ID: 
Subject: Re: FreeBSD build hardware?
To: Glen Barber 
Cc: Mark Millard , "Wall, Stephen" , 
	"freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="0000000000002b54e905e07fe88c"
X-Rspamd-Queue-Id: 4LDjqw5D1Rz3KTm
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=FXiieL3c;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-2.91 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.91)[-0.910];
	 FROM_EQ_ENVFROM(0.00)[];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2a:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_CC(0.00)[yahoo.com,redcom.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 2545
Lines: 71

--0000000000002b54e905e07fe88c
Content-Type: text/plain; charset="UTF-8"

Glen this software was side loaded on my phone without permission. I'm not
sure if arch program is default or added because arm 64 wasn't there in the
beginning that I could see. It's like a entity has control of my phone with
google software and Apache also

On Thu, Jun 2, 2022, 5:04 PM Glen Barber  wrote:

> On Thu, Jun 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:
> > On 2022-Jun-2, at 16:00, Glen Barber  wrote:
> >
> > > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> > >> Does anyone know what hardware FreeBSD is using to build the ARM
> releases of FreeBSD 13?
> > >>
> > >
> > > They are cross-built on amd64 hardware.
> > >
> >
> > It was unclear to me if the original question was trying
> > to span aarch64 as well vs., say, just spanning armv7/armv6.
> >
> > aarch64 may well have a different answer.
> >
>
> No.  All architectures are built on amd64 hardware.
>
> Glen
>
>

--0000000000002b54e905e07fe88c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Glen this software was side loaded on my phone without pe=
rmission. I'm not sure if arch program is default or added because arm =
64 wasn't there in the beginning that I could see. It's like a enti=
ty has control of my phone with google software and Apache also

On Thu, Jun =
2, 2022, 5:04 PM Glen Barber <gjb@fre=
ebsd.org> wrote:
On Thu, Jun=
 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:

> On 2022-Jun-2, at 16:00, Glen Barber <gjb@FreeBSD.org> wrote:
> 

> > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> >> Does anyone know what hardware FreeBSD is using to build the =
ARM releases of FreeBSD 13?

> >> 

> > 

> > They are cross-built on amd64 hardware.

> > 

> 

> It was unclear to me if the original question was trying

> to span aarch64 as well vs., say, just spanning armv7/armv6.

> 

> aarch64 may well have a different answer.

> 



No.=C2=A0 All architectures are built on amd64 hardware.



Glen






--0000000000002b54e905e07fe88c--

From nobody Fri Jun  3 00:14:37 2022
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 1A12D1B5F7FE
	for ; Fri,  3 Jun 2022 00:15:18 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LDk112lSnz3LWq
	for ; Fri,  3 Jun 2022 00:15:17 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-3.109, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, T_SCC_BODY_TEXT_LINE -0.01,
	URIBL_BLOCKED 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 2530EbKJ003974
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [10.14.0.12] (static-198-54-132-55.cust.tzulo.com [198.54.132.55])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 2530EbKJ003974
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
	for ; Thu, 2 Jun 2022 20:14:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1654215278;
	bh=kEbP6ZAsTrERrs10ZCWD1NyD+tYa5hsRGnhSRrS86o4=;
	h=Date:To:From:Subject:From;
	b=SE2hQwJH2sg2wFIY4KBLHq8sed/sEb1MAV6ShLTS5j/oCqvKmv35vVzoozv44uOKb
	 qjcEW/zthGuPT/sDd3xZnhi2716/eqjTKeeReW87DDySFbgtqtpBL4tfwQwWXBwUBm
	 so/VLxw22iMbtOMCMyom1GlZKbvF+OjHNfb8tyrx+OsJ+TS8PmLvig5jJKMI5M68fA
	 IfpthDOstwgfh5gLIJkkg11C6wahwg4xAyEhXxWZ6z65KvhMC2kUinBM68CP5irWkx
	 Mqz1a7191wgV2o6DMXDX1yffIMAUVYbSK7QrNU2aJoqnh4z2HAHzpK8GNQcujBYg1a
	 78lUw0PeEE5Ww==
Message-ID: 
Date: Thu, 2 Jun 2022 20:14:37 -0400
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
To: "freebsd-arm@FreeBSD.org" 
Content-Language: en-US
From: Dennis Clarke 
Subject: a small report from the Amazon AWS world
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LDk112lSnz3LWq
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=SE2hQwJH;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-4.70 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[blastwave.org:+];
	 RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	 DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1382
Lines: 31


The Amazon EC2 experiment with FreeBSD 13.1 on aarch64 :

Today I bit the bullet and trudged through the baffling config options
on the Amazon AWS EC2 interface to get FreeBSD 13.1 up and running. I
went with the r6gd.xlarge type instance which provides some mysterious
four core config and 32GB of memory. There is also a 237 NVMe SSD in
there but I had to search around to figure out where that was after the
instance booted up.  I did not see any way to get at the console and do
the installation myself because I would have gone pure ZFS. What I did
get was a 32GB root device thing at /dev/nda0 and the blank SSD was the
device /dev/nda1.

Performance is not thrilling.  Nope.  I am still doing a few compute
tests and also a file thrash on both the UFS and the ZFS filesystems but
there is nothing to write home about thus far. What is far more scary
about all this is the cost of network traffic which could go well past
the four hundred USD a month mark on a halfway decent busy website. My
calculations could be way off the mark however.

Not sure what else to say but I am still running some baseline tests.
Very happy to see the AMI instance offer exists for FreeBSD 13.1 on the
aarch64 platform but I have no idea what I am getting for my money. Yet.

Any questions ?

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From nobody Fri Jun  3 00:22:49 2022
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 B44F11B60D8C
	for ; Fri,  3 Jun 2022 00:23:03 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f])
	(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 4LDk9z00Tbz3MK1;
	Fri,  3 Jun 2022 00:23:03 +0000 (UTC)
	(envelope-from irontree043111@gmail.com)
Received: by mail-yb1-xb2f.google.com with SMTP id l204so11131073ybf.10;
        Thu, 02 Jun 2022 17:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Y5tD7nQ8U64gQmRiietL35l8xBKp6IkBRCi5SIn49ts=;
        b=lkX4KM/LR0/VMAD67Ftt2N+OqlD4cBjot8LF94znHpyVnQL7146NPRuuKmdHUc+sO9
         pT0QhiXOn0K5z1GfScXu1OB9vQSfjUmc0+k/2tfpsEihZO+J8Tl/cP+ttICvHKYFpB7m
         JdjtDQsL2rdG4+4csfA6CQu3wJ0lcUioRaHKiARFJ04AOg3krFpPN7oeFCG7eJAsSXg3
         eA6ekatTiswgjU48rxvEhLijesCoeW9Z8oDcmQw+sqogySZ7+RH8baSAb5UAkVtghpqs
         9Nt36RCu/kP56v7M3HUyU7L2IDmQzFz1UD9kslsK8QH5xvtYksitGt/Gt/wRNvZbUWPk
         h0mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Y5tD7nQ8U64gQmRiietL35l8xBKp6IkBRCi5SIn49ts=;
        b=RdT6sAOXc2pIDkdfKImZT9iXiAW6tOAXEC2bdwdGp4ybDIxv73D4gCDFJoYyZ4Nmwb
         Iv8QOwntxpMED8BCI5nSvejRi9+oqsTXyGAepLNTNV3woEGRwACM8c9gTicEOgB6nX2+
         Jd3lPqk8x89hyUSnJ/i02N/QdErTAjsLaOtlD9+EyMnBobmicImobOHDmByTZagP3jKL
         6T8c6eJSZ3b0GmTU3kTU4f7rAVXBKdZv6ioUc09337tMo+W0TVElbPUXJhxeE/95JnWi
         g/VRIXIKZQMYrp0+Wuheiv7wm4mwvFZgWrHP+SU0xLHlqW1jLrtvAfZeI07sN6a5+6Os
         /TMQ==
X-Gm-Message-State: AOAM5301QB1lLzzjxFT9RubRcMk+kaprnXjPLiht+pf5LiT/+fIrLNku
	WCZrPqhcY1+Dc8Hu+b9OPG7+5ZJ7aIytHDni064B9pGDYsw=
X-Google-Smtp-Source: ABdhPJzbI1YhjrDnTjiE9gJVVkwSq87Nncb3NZlTMZhlc8eAWhp6wSvrLFLNFWaIX8qrkc0j5jwopBnu2WibRctikEA=
X-Received: by 2002:a05:6902:110e:b0:644:daff:1e6f with SMTP id
 o14-20020a056902110e00b00644daff1e6fmr8758387ybu.569.1654215782308; Thu, 02
 Jun 2022 17:23:02 -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: 
 <20220602230000.GL30607@FreeBSD.org> 
 <20220603000428.GM30607@FreeBSD.org> 
In-Reply-To: 
From: Robert Montano 
Date: Thu, 2 Jun 2022 17:22:49 -0700
Message-ID: 
Subject: Re: FreeBSD build hardware?
To: Glen Barber 
Cc: Mark Millard , "Wall, Stephen" , 
	"freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="000000000000161fa405e080207e"
X-Rspamd-Queue-Id: 4LDk9z00Tbz3MK1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="lkX4KM/L";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of irontree043111@gmail.com designates 2607:f8b0:4864:20::b2f as permitted sender) smtp.mailfrom=irontree043111@gmail.com
X-Spamd-Result: default: False [-1.96 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 URI_COUNT_ODD(1.00)[3];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.96)[-0.956];
	 FROM_EQ_ENVFROM(0.00)[];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2f:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_CC(0.00)[yahoo.com,redcom.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 32721
Lines: 561

--000000000000161fa405e080207e
Content-Type: text/plain; charset="UTF-8"

This is what I get when I try to do anything basically.......,.......
# Overrides for Extension Preferences
# Tor Browser Bundle
# Do not edit this file.
#
# This file is modified from a file included in the Tor Browser Bundle.
#
# Copyright 2017 The Tor Project.  See LICENSE.tor for licensing
information.

# HTTPS Everywhere Preferences:
user_pref("extensions.https_everywhere._observatory.popup_shown", true);
user_pref("extensions.https_everywhere.toolbar_hint_shown", true);

# NoScript Preferences:
# In order to disable all scripts by default, uncomment the following
line...
# user_pref("capability.policy.maonoscript.javascript.enabled", "noAccess");
# and comment out the following line
user_pref("capability.policy.maonoscript.javascript.enabled", "allAccess");
user_pref("capability.policy.maonoscript.sites", "[System+Principal] about:
about:tbupdate about:tor chrome: resource: blob: mediasource:
moz-extension: moz-safe-about: about:neterror about:certerror about:feeds
about:tabcrashed about:cache");
user_pref("noscript.default", "[System+Principal] about: about:tbupdate
about:tor chrome: resource: blob: mediasource: moz-extension:
moz-safe-about: about:neterror about:certerror about:feeds about:tabcrashed
about:cache");
user_pref("noscript.mandatory", "[System+Principal] about: about:tbupdate
about:tor chrome: resource: blob: mediasource: moz-extension:
moz-safe-about: about:neterror about:certerror about:feeds about:tabcrashed
about:cache");
user_pref("noscript.ABE.enabled", false);
user_pref("noscript.ABE.notify", false);
user_pref("noscript.ABE.wanIpAsLocal", false);
user_pref("noscript.confirmUnblock", false);
user_pref("noscript.contentBlocker", true);
user_pref("noscript.firstRunRedirection", false);
user_pref("noscript.global", true);
user_pref("noscript.gtemp", "");
user_pref("noscript.opacizeObject", 3);
user_pref("noscript.forbidWebGL", true);
user_pref("noscript.forbidFonts", true);
user_pref("noscript.options.tabSelectedIndexes", "5,0,0");
user_pref("noscript.policynames", "");
user_pref("noscript.secureCookies", true);
user_pref("noscript.showAllowPage", false);
user_pref("noscript.showBaseDomain", false);
user_pref("noscript.showDistrust", false);
user_pref("noscript.showRecentlyBlocked", false);
user_pref("noscript.showTemp", false);
user_pref("noscript.showTempToPerm", false);
user_pref("noscript.showUntrusted", false);
user_pref("noscript.STS.enabled", false);
user_pref("noscript.subscription.lastCheck", -142148139);
user_pref("noscript.temp", "");
user_pref("noscript.untrusted", "");
user_pref("noscript.forbidMedia", true);
user_pref("noscript.allowWhitelistUpdates", false);
user_pref("noscript.fixLinks", false);
// Now handled by plugins.click_to_play // Not in this one.
user_pref("noscript.forbidFlash", true);
user_pref("noscript.forbidSilverlight", true);
user_pref("noscript.forbidJava", true);
user_pref("noscript.forbidPlugins", true);
// Usability tweaks
user_pref("noscript.showPermanent", false);
user_pref("noscript.showTempAllowPage", true);
user_pref("noscript.showRevokeTemp", true);
user_pref("noscript.notify", false);
user_pref("noscript.autoReload", true);
user_pref("noscript.autoReload.allTabs", false);
user_pref("noscript.cascadePermissions", true);
user_pref("noscript.restrictSubdocScripting", true);
user_pref("noscript.showVolatilePrivatePermissionsToggle", false);
user_pref("noscript.volatilePrivatePermissions", true);
user_pref("noscript.clearClick", 0);

user_pref("intl.locale.matchOS", false);

user_pref("extensions.https_everywhere._observatory.enabled", false);
user_pref("extensions.https_everywhere.options.autoUpdateRulesets", false);
user_pref("extensions.https_everywhere.globalEnabled", false);
user_pref("extensions.https_everywhere._observatory.submit_during_tor",
false);
user_pref("extensions.https_everywhere._observatory.submit_during_nontor",
false);
user_pref("extensions.https_everywhere._observatory.use_custom_proxy",
true);
user_pref("extensions.https_everywhere._observatory.proxy_host",
"127.0.0.1");
user_pref("extensions.https_everywhere._observatory.proxy_port", 4444);

user_pref("extensions.torbutton.use_nontor_proxy", true);
user_pref("extensions.torlauncher.start_tor", false);
user_pref("extensions.torlauncher.prompt_at_startup", false);
//user_pref("", false);


//For socket conversion: in the future, I'll need to make TBB communicate
with
//i2p over a unix socket. Fortunately, this is how you do that. It will be
//configurable in a similar way to the host:port configuration when that
happens.
//user_pref("extensions.torlauncher.socks_port_use_ipc", );
//user_pref("extensions.torlauncher.socks_ipc_path", "");

//user_pref("extensions.torlauncher.start_tor", false);
//user_pref("extensions.torlauncher.default_bridge_type", "");
//user_pref("extensions.torlauncher.prompt_at_startup", false);

// Resist-fingerprinting and first-party isolation enable

user_pref("privacy.resistFingerprinting", true);
user_pref("privacy.firstparty.isolate", true);

// Use i2p http proxy for all connections and set homepage to safe local
form.

// DON'T allow access to the admin panel from the profile we browse i2p
with.
user_pref("network.proxy.no_proxies_on", "");
user_pref("network.proxy.type", 1);
user_pref("network.proxy.http", "127.0.0.1");
user_pref("network.proxy.http_port", 4444);
user_pref("network.proxy.ssl", "127.0.0.1");
user_pref("network.proxy.ssl_port", 4444);
user_pref("network.proxy.ftp", "127.0.0.1");
user_pref("network.proxy.ftp_port", 4444);
user_pref("network.proxy.socks", "127.0.0.1");
user_pref("network.proxy.socks_port", 4444);
user_pref("network.proxy.share_proxy_settings", true);
user_pref("network.proxy.socks_remote_dns", true);
user_pref("browser.startup.homepage", "about:blank");

// Privacy-harden and disable irrelevant features.
user_pref("app.normandy.api_url", "");
user_pref("app.normandy.enabled", false);
user_pref("app.update.auto", false);
user_pref("app.update.enabled", false);
user_pref("beacon.enabled", false);
user_pref("browser.aboutHomeSnippets.updateUrl", "");
user_pref("browser.cache.disk_cache_ssl", false);
user_pref("browser.cache.disk.enable", false);
user_pref("browser.cache.offline.enable", false);
user_pref("browser.disableResetPrompt", true);
user_pref("browser.display.use_document_fonts", 0);
user_pref("browser.fixup.alternate.enabled", false);
user_pref("browser.formfill.enable", false);
user_pref("browser.library.activity-stream.enabled", false);
user_pref("browser.newtabpage.activity-stream.disableSnippets", true);
user_pref("browser.newtabpage.activity-stream.enabled", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.highlights",
false);
user_pref("browser.newtabpage.activity-stream.feeds.snippets", false);
user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("browser.newtabpage.activity-stream.feeds.topsites", false);
user_pref("browser.newtabpage.activity-stream.prerender", false);
user_pref("browser.newtabpage.activity-stream.showSearch", false);
user_pref("browser.newtabpage.enhanced", false);
user_pref("browser.newtabpage.introShown", true);
user_pref("browser.newtab.preload", false);
user_pref("browser.onboarding.enabled", false);
user_pref("browser.pagethumbnails.capturing_disabled", true);
user_pref("browser.safebrowsing.appRepURL", "");
user_pref("browser.safebrowsing.blockedURIs.enabled", false);
user_pref("browser.safebrowsing.downloads.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.url", "");
user_pref("browser.safebrowsing.enabled", false);
user_pref("browser.safebrowsing.malware.enabled", false);
user_pref("browser.safebrowsing.phishing.enabled", false);
user_pref("browser.search.geoip.timeout", 1);
user_pref("browser.search.suggest.enabled", false);
user_pref("browser.selfsupport.url", "");
user_pref("browser.send_pings", false);
user_pref("browser.shell.checkDefaultBrowser", false);
user_pref("browser.startup.homepage_override.mstone", "ignore");
user_pref("browser.startup.page", 0);
user_pref("browser.toolbarbuttons.introduced.pocket-button", true);
user_pref("browser.urlbar.speculativeConnect.enabled", false);
user_pref("browser.urlbar.trimURLs", false);
user_pref("datareporting.healthreport.uploadEnabled", false);
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("dom.battery.enabled", false);
user_pref("dom.enable_performance", false);
user_pref("dom.enable_performance_navigation_timing", false);
user_pref("dom.enable_resource_timing", false);
user_pref("dom.event.clipboardevents.enabled", false);
user_pref("dom.gamepad.enabled", false);
user_pref("dom.indexedDB.enabled", false);
user_pref("dom.min_timeout_value", 400);
user_pref("dom.push.connection.enabled", false);
user_pref("dom.push.enabled", false);
user_pref("dom.serviceWorkers.enabled", false);
user_pref("dom.serviceWorkers.interception.enabled", false);
user_pref("dom.storage.enabled", false);
user_pref("dom.webaudio.enabled", false);
user_pref("extensions.autoDisableScopes", 14);
user_pref("extensions.getAddons.cache.enabled", false);
user_pref("extensions.getAddons.showPane", false);
user_pref("extensions.pocket.enabled", false);
user_pref("extensions.screenshots.disabled", true);
user_pref("extensions.webservice.discoverURL", "");
user_pref("geo.enabled", false);
user_pref("geo.wifi.uri", "");
user_pref("gfx.downloadable_fonts.disable_cache", true);
user_pref("javascript.options.shared_memory", false);
user_pref("layout.css.visited_links_enabled", false);
user_pref("media.autoplay.enabled", false);
user_pref("media.cache_size", 0);
user_pref("media.navigator.enabled", false);
user_pref("media.peerconnection.enabled", false);
user_pref("media.video_stats.enabled", false);
user_pref("captivedetect.canonicalURL", "");
user_pref("network.captive-portal-service.enabled", false);
user_pref("network.cookie.cookieBehavior", 1);
user_pref("network.cookie.lifetimePolicy", 2);
user_pref("network.dns.disablePrefetch", true);
user_pref("network.http.referer.spoofSource", true);
user_pref("network.http.referer.trimmingPolicy", 2);
user_pref("network.http.referer.XOriginPolicy", 2);
user_pref("network.prefetch-next", false);
user_pref("privacy.donottrackheader.enabled", true);
user_pref("privacy.donottrackheader.value", 1);
user_pref("toolkit.telemetry.archive.enabled", false);
user_pref("toolkit.telemetry.coverage.opt-out", true);
user_pref("toolkit.telemetry.enabled", false);
user_pref("toolkit.telemetry.server", "");
user_pref("toolkit.telemetry.unified", false);
user_pref("webgl.disabled", true);
user_pref("browser.chrome.errorReporter.infoURL", "");
user_pref("breakpad.reportURL", "");
user_pref("browser.newtabpage.activity-stream.default.sites", "");
//user_pref("browser.newtabpage.activity-stream.default.sites", "
http://planet.i2p/,http://legwork.i2p/,http://i2pwiki.i2p/,http://i2pforums.i2p/,http://zzz.i2p/
");

On Thu, Jun 2, 2022, 5:07 PM Robert Montano 
wrote:

> Glen this software was side loaded on my phone without permission. I'm not
> sure if arch program is default or added because arm 64 wasn't there in the
> beginning that I could see. It's like a entity has control of my phone with
> google software and Apache also
>
> On Thu, Jun 2, 2022, 5:04 PM Glen Barber  wrote:
>
>> On Thu, Jun 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:
>> > On 2022-Jun-2, at 16:00, Glen Barber  wrote:
>> >
>> > > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
>> > >> Does anyone know what hardware FreeBSD is using to build the ARM
>> releases of FreeBSD 13?
>> > >>
>> > >
>> > > They are cross-built on amd64 hardware.
>> > >
>> >
>> > It was unclear to me if the original question was trying
>> > to span aarch64 as well vs., say, just spanning armv7/armv6.
>> >
>> > aarch64 may well have a different answer.
>> >
>>
>> No.  All architectures are built on amd64 hardware.
>>
>> Glen
>>
>>

--000000000000161fa405e080207e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This is what I get when I try to do anything basically...=
....,.......
# Overrides for Extension Preferences
# Tor Browser Bundle
# Do not edit this fi=
le.
#
# This file is modified=
 from a file included in the Tor Browser Bundle.
#
# Copyright 2017 The Tor Project.=C2=A0 See LICENSE.t=
or for licensing information.

# HTTPS Everywhere Preferences:
user_pref(&quo=
t;extensions.https_everywhere._observatory.popup_shown", true);
<=
div dir=3D"auto">user_pref("extensions.https_everywhere.toolbar_hint_s=
hown", true);

# NoS=
cript Preferences:
# In order to disable all scripts=
 by default, uncomment the following line...
# user_=
pref("capability.policy.maonoscript.javascript.enabled", "no=
Access");
# and comment out the following line<=
/div>
user_pref("capability.policy.maonoscript.javasc=
ript.enabled", "allAccess");
user_pre=
f("capability.policy.maonoscript.sites", "[System+Principal]=
 about: about:tbupdate about:tor chrome: resource: blob: mediasource: moz-e=
xtension: moz-safe-about: about:neterror about:certerror about:feeds about:=
tabcrashed about:cache");
user_pref("noscr=
ipt.default", "[System+Principal] about: about:tbupdate about:tor=
 chrome: resource: blob: mediasource: moz-extension: moz-safe-about: about:=
neterror about:certerror about:feeds about:tabcrashed about:cache");
user_pref("noscript.mandatory", "[Syst=
em+Principal] about: about:tbupdate about:tor chrome: resource: blob: media=
source: moz-extension: moz-safe-about: about:neterror about:certerror about=
:feeds about:tabcrashed about:cache");
user_pre=
f("noscript.ABE.enabled", false);
user_pre=
f("noscript.ABE.notify", false);
user_pref=
("noscript.ABE.wanIpAsLocal", false);
user=
_pref("noscript.confirmUnblock", false);
u=
ser_pref("noscript.contentBlocker", true);
user_pref("noscript.firstRunRedirection", false);
user_pref("noscript.global", true);
user_pref("noscript.gtemp", "");
user_pref("noscript.opacizeObject", 3);
user_pref("noscript.forbidWebGL", true);
user_pref("noscript.forbidFonts", true);
user_pref("noscript.options.tabSelectedIndexes", "5,0,0&quo=
t;);
user_pref("noscript.policynames", &qu=
ot;");
user_pref("noscript.secureCookies&q=
uot;, true);
user_pref("noscript.showAllowPage&=
quot;, false);
user_pref("noscript.showBaseDoma=
in", false);
user_pref("noscript.showDistr=
ust", false);
user_pref("noscript.showRece=
ntlyBlocked", false);
user_pref("noscript.=
showTemp", false);
user_pref("noscript.sho=
wTempToPerm", false);
user_pref("noscript.=
showUntrusted", false);
user_pref("noscrip=
t.STS.enabled", false);
user_pref("noscrip=
t.subscription.lastCheck", -142148139);
user_pr=
ef("noscript.temp", "");
user_pr=
ef("noscript.untrusted", "");
us=
er_pref("noscript.forbidMedia", true);
use=
r_pref("noscript.allowWhitelistUpdates", false);
user_pref("noscript.fixLinks", false);
// Now handled by plugins.click_to_play // Not in this one.
user_pref("noscript.forbidFlash", true);
user_pref("noscript.forbidSilverlight", true);
user_pref("noscript.forbidJava", true);
user_pref("noscript.forbidPlugins", true);
// Usability tweaks
user_pref("n=
oscript.showPermanent", false);
user_pref("=
;noscript.showTempAllowPage", true);
user_pref(=
"noscript.showRevokeTemp", true);
user_pre=
f("noscript.notify", false);
user_pref(&qu=
ot;noscript.autoReload", true);
user_pref("=
;noscript.autoReload.allTabs", false);
user_pre=
f("noscript.cascadePermissions", true);
us=
er_pref("noscript.restrictSubdocScripting", true);
user_pref("noscript.showVolatilePrivatePermissionsToggle&quo=
t;, false);
user_pref("noscript.volatilePrivate=
Permissions", true);
user_pref("noscript.c=
learClick", 0);

use=
r_pref("intl.locale.matchOS", false);

=

user_pref("extensions.https_everywhere._observ=
atory.enabled", false);
user_pref("extensi=
ons.https_everywhere.options.autoUpdateRulesets", false);
user_pref("extensions.https_everywhere.globalEnabled",=
 false);
user_pref("extensions.https_everywhere=
._observatory.submit_during_tor", false);
user_=
pref("extensions.https_everywhere._observatory.submit_during_nontor&qu=
ot;, false);
user_pref("extensions.https_everyw=
here._observatory.use_custom_proxy", true);
use=
r_pref("extensions.https_everywhere._observatory.proxy_host", &qu=
ot;127.0.0.1");
user_pref("extensions.http=
s_everywhere._observatory.proxy_port", 4444);
<=
br>
user_pref("extensions.torbutton.use_nontor_=
proxy", true);
user_pref("extensions.torla=
uncher.start_tor", false);
user_pref("exte=
nsions.torlauncher.prompt_at_startup", false);
=
//user_pref("", false);


//For socket conversion: in the futur=
e, I'll need to make TBB communicate with
//i2p =
over a unix socket. Fortunately, this is how you do that. It will be
<=
div dir=3D"auto">//configurable in a similar way to the host:port configura=
tion when that happens.
//user_pref("extensions=
.torlauncher.socks_port_use_ipc", );
//user_pre=
f("extensions.torlauncher.socks_ipc_path", "");

//user_pref("extensions.to=
rlauncher.start_tor", false);
//user_pref("=
;extensions.torlauncher.default_bridge_type", "");
//user_pref("extensions.torlauncher.prompt_at_startup&qu=
ot;, false);

// Resist-f=
ingerprinting and first-party isolation enable

<=
/div>
user_pref("privacy.resistFingerprinting", =
true);
user_pref("privacy.firstparty.isolate&qu=
ot;, true);

// Use i2p h=
ttp proxy for all connections and set homepage to safe local form.

// DON'T allow access to the=
 admin panel from the profile we browse i2p with.
us=
er_pref("network.proxy.no_proxies_on", "");
user_pref("network.proxy.type", 1);
user_pref("network.proxy.http", "127.0.0.1");
user_pref("network.proxy.http_port", 4444);
user_pref("network.proxy.ssl", "127.0.=
0.1");
user_pref("network.proxy.ssl_port&q=
uot;, 4444);
user_pref("network.proxy.ftp"=
, "127.0.0.1");
user_pref("network.pr=
oxy.ftp_port", 4444);
user_pref("network.p=
roxy.socks", "127.0.0.1");
user_pref(=
"network.proxy.socks_port", 4444);
user_pr=
ef("network.proxy.share_proxy_settings", true);
user_pref("network.proxy.socks_remote_dns", true);
user_pref("browser.startup.homepage", "about:=
blank");

// Privacy=
-harden and disable irrelevant features.
user_pref(&=
quot;app.normandy.api_url", "");
user=
_pref("app.normandy.enabled", false);
user=
_pref("app.update.auto", false);
user_pref=
("app.update.enabled", false);
user_pref(&=
quot;beacon.enabled", false);
user_pref("b=
rowser.aboutHomeSnippets.updateUrl", "");
user_pref("browser.cache.disk_cache_ssl", false);
user_pref("browser.cache.disk.enable", false);
=

user_pref("browser.cache.offline.enable", false=
);
user_pref("browser.disableResetPrompt",=
 true);
user_pref("browser.display.use_document=
_fonts", 0);
user_pref("browser.fixup.alte=
rnate.enabled", false);
user_pref("browser=
.formfill.enable", false);
user_pref("brow=
ser.library.activity-stream.enabled", false);
u=
ser_pref("browser.newtabpage.activity-stream.disableSnippets", tr=
ue);
user_pref("browser.newtabpage.activity-str=
eam.enabled", false);
user_pref("browser.n=
ewtabpage.activity-stream.feeds.section.highlights", false);
user_pref("browser.newtabpage.activity-stream.feeds.snip=
pets", false);
user_pref("browser.newtabpa=
ge.activity-stream.feeds.telemetry", false);
us=
er_pref("browser.newtabpage.activity-stream.feeds.topsites", fals=
e);
user_pref("browser.newtabpage.activity-stre=
am.prerender", false);
user_pref("browser.=
newtabpage.activity-stream.showSearch", false);
user_pref("browser.newtabpage.enhanced", false);
user_pref("browser.newtabpage.introShown", true);
=

user_pref("browser.newtab.preload", false);
user_pref("browser.onboarding.enabled", false=
);
user_pref("browser.pagethumbnails.capturing_=
disabled", true);
user_pref("browser.safeb=
rowsing.appRepURL", "");
user_pref(&q=
uot;browser.safebrowsing.blockedURIs.enabled", false);
user_pref("browser.safebrowsing.downloads.enabled", fal=
se);
user_pref("browser.safebrowsing.downloads.=
remote.enabled", false);
user_pref("browse=
r.safebrowsing.downloads.remote.url", "");
user_pref("browser.safebrowsing.enabled", false);
user_pref("browser.safebrowsing.malware.enabled", f=
alse);
user_pref("browser.safebrowsing.phishing=
.enabled", false);
user_pref("browser.sear=
ch.geoip.timeout", 1);
user_pref("browser.=
search.suggest.enabled", false);
user_pref(&quo=
t;browser.selfsupport.url", "");
user=
_pref("browser.send_pings", false);
user_p=
ref("browser.shell.checkDefaultBrowser", false);
user_pref("browser.startup.homepage_override.mstone", &quo=
t;ignore");
user_pref("browser.startup.page", 0);
user_pref("browser.toolbarbuttons.introduced.pocket-button",=
 true);
user_pref("browser.urlbar.speculativeCo=
nnect.enabled", false);
user_pref("browser=
.urlbar.trimURLs", false);
user_pref("data=
reporting.healthreport.uploadEnabled", false);
=
user_pref("datareporting.policy.dataSubmissionEnabled", false);
user_pref("dom.battery.enabled", false);
user_pref("dom.enable_performance", false);<=
/div>
user_pref("dom.enable_performance_navigation_ti=
ming", false);
user_pref("dom.enable_resou=
rce_timing", false);
user_pref("dom.event.=
clipboardevents.enabled", false);
user_pref(&qu=
ot;dom.gamepad.enabled", false);
user_pref(&quo=
t;dom.indexedDB.enabled", false);
user_pref(&qu=
ot;dom.min_timeout_value", 400);
user_pref(&quo=
t;dom.push.connection.enabled", false);
user_pr=
ef("dom.push.enabled", false);
user_pref(&=
quot;dom.serviceWorkers.enabled", false);
user_=
pref("dom.serviceWorkers.interception.enabled", false);
user_pref("dom.storage.enabled", false);
user_pref("dom.webaudio.enabled", false);
user_pref("extensions.autoDisableScopes", 14);
=

user_pref("extensions.getAddons.cache.enabled",=
 false);
user_pref("extensions.getAddons.showPa=
ne", false);
user_pref("extensions.pocket.=
enabled", false);
user_pref("extensions.sc=
reenshots.disabled", true);
user_pref("ext=
ensions.webservice.discoverURL", "");
user_pref("geo.enabled", false);
user_pre=
f("geo.wifi.uri", "");
user_pref=
("gfx.downloadable_fonts.disable_cache", true);
user_pref("javascript.options.shared_memory", false);
=

user_pref("layout.css.visited_links_enabled", f=
alse);
user_pref("media.autoplay.enabled",=
 false);
user_pref("media.cache_size", 0);=

user_pref("media.navigator.enabled", fals=
e);
user_pref("media.peerconnection.enabled&quo=
t;, false);
user_pref("media.video_stats.enable=
d", false);
user_pref("captivedetect.canon=
icalURL", "");
user_pref("networ=
k.captive-portal-service.enabled", false);
user=
_pref("network.cookie.cookieBehavior", 1);
user_pref("network.cookie.lifetimePolicy", 2);
user_pref("network.dns.disablePrefetch", true);
user_pref("network.http.referer.spoofSource", true);<=
/div>
user_pref("network.http.referer.trimmingPolicy&=
quot;, 2);
user_pref("network.http.referer.XOri=
ginPolicy", 2);
user_pref("network.prefetc=
h-next", false);
user_pref("privacy.donott=
rackheader.enabled", true);
user_pref("pri=
vacy.donottrackheader.value", 1);
user_pref(&qu=
ot;toolkit.telemetry.archive.enabled", false);
=
user_pref("toolkit.telemetry.coverage.opt-out", true);
user_pref("toolkit.telemetry.enabled", false);
=

user_pref("toolkit.telemetry.server", "&qu=
ot;);
user_pref("toolkit.telemetry.unified"=
;, false);
user_pref("webgl.disabled", tru=
e);
user_pref("browser.chrome.errorReporter.inf=
oURL", "");
user_pref("breakpad.=
reportURL", "");
user_pref("brow=
ser.newtabpage.activity-stream.default.sites", "");
//user_pref("browser.newtabpage.activity-stream.default=
.sites", "http://planet.i2p/,ht=
tp://legwork.i2p/,http://i2pwiki.i2p/,http://i2pforums.i2p/,http://zzz.i2p/=
");

On Thu, Jun 2, 2022, 5:07 PM Robert Montano <irontree043111@gmail.com> w=
rote:
Glen this s=
oftware was side loaded on my phone without permission. I'm not sure if=
 arch program is default or added because arm 64 wasn't there in the be=
ginning that I could see. It's like a entity has control of my phone wi=
th google software and Apache also

On Thu, Jun 2, 2022, 5:04 PM Glen Barber =
<gjb@freebsd.org> wrote:
On =
Thu, Jun 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:

> On 2022-Jun-2, at 16:00, Glen Barber <gjb@FreeBSD.org> wrote:
> 

> > On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
> >> Does anyone know what hardware FreeBSD is using to build the =
ARM releases of FreeBSD 13?

> >> 

> > 

> > They are cross-built on amd64 hardware.

> > 

> 

> It was unclear to me if the original question was trying

> to span aarch64 as well vs., say, just spanning armv7/armv6.

> 

> aarch64 may well have a different answer.

> 



No.=C2=A0 All architectures are built on amd64 hardware.



Glen








--000000000000161fa405e080207e--

From nobody Fri Jun  3 01:01:01 2022
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 7DBD01B66E66
	for ; Fri,  3 Jun 2022 01:01:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4LDl246Q0tz3PrJ
	for ; Fri,  3 Jun 2022 01:01:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654218069; bh=RbE5zx5d7QnlpdrbRL3h3iNdVUosCATr8E9WgrqMyi0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sNHVADSy5YuriIlRdGOJBikZ8baZ3NjXt7hyMkcludXF11xcaIAOLEp8poIg429vdDxge1qZcITvtdIhuq1GYJcAL09z9kiK6mx1UHXJv3fJn7RDjb5URe0Ju4eRH4cpWx9LJROt4sfbwxd3F9C9KQ/PnpirpE3QLyTHNMQa+JZ/Xjrb4cT+JQdOkQ6E/imdLCcWhhBTFdSvlpNPDQbiOUzdjun28qg1cREOgHHJyivH60hijBex2Lm1Q/hKQrLpt3mf3htR7TrlOjx34sc0pcRyYET5hILbJ8CJeACQRXSCNfPyPrKAYslhYwV1dc5oo/hdHQMYnF2u8GMpjbNXCQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654218069; bh=yqCXmQQLmC3q19oa4oRHjznNaglHUyvCBTMYJSqTR5n=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CZtCEsKD10CCyKPkKgHhRndPglPvWY4ryChbxHp/HytzhmxNt8YJA13uesszyl/C7TA71AIzA0+NCDZs+eD3g/upFT6c29r1LId7GgXY9hEPSf9W+VPEl6+hJSRU57PBOqUt9oRRuWRgftHvmU5ObR9r1F2IA8HXEdTJ9iDPr5v4oB2JL/gmyhlJiZTumV91M+VHVyCxmoP5lS+MfBe69Ncw87VijrI57S4bUd0pUtE/DSFh0WWqp/i9hciWTK7OVFV16qoBAuDTJJop9fbPo6dVKTPb6AG28tkeyHWWeQM7S1LK38zA/HO19/JS9wY73tPz8nc45kmTOLUSnxgYmw==
X-YMail-OSG: SKmg7ncVM1nAcG1oohxzBMBDe4nKpiE_RVSx5QKXwDg9ETt_voXBIiXaWxw05rg
 eVjhaVbwOzd51vBA40rnbI8M49USDZV06T1MKuFxGGJpeUEBFvgRpF3BJsj7h7_EqbaxG8WyH65S
 WGwR7GpytouFidSW_aUfn.P9VoIhCEasTgRmr88O3XdNOihgiRnwBMuCVu6BCd8WcZxIev0yoZ51
 pkPnLLeIFWbMmdK8zEhZIMyE6xLB589WTwctdduoioN8D8EE5SxZS9MuxzYBa7hk_F7.2lIKARQq
 NHDEl8qS7CgTm1RgfUHj3frthnl1y1sTj8iuptfxVDMCyCMS01jhLbUnaI5ZPP8_amClHFKiz5bO
 YP9xlggEhnW7eADPsZQhtiKR__ZWe9Bhh7WKCXMmaO12Jo.dOWBuPOypRoTxwi3c0rX5b_M5SP24
 9XSIX4EymamSclpkZSP4frz2wYbR_euJjlwPKarFNB6jxyv8.haXMVsdXU.jJ4SbUY1nsnEcODSz
 n69QZqA7tMnkDYeMqo_Krsqer7Z2Ba87k9ZtWRbKy2muhlqN69IeJVOg_iTyY583nEXOxOJEikXf
 aYJ1pxMLvCflxOyHwkBvlxrwJsPh8nnt1GM1qpMx4ouAyTEZV3OHk65CmCN5NKnmVUb1Oh2wwhRE
 Cy1OoJGHRO6kjfgbqW2jTQSBKTKuYOFQXhcOqMTETOCYlIMMmhJLjbDXtFsz8Yu67Jm8Ftniv5Qu
 nic8D8WydqmZP1FC8u3iiBv8MLeQyKlJBIoXcglHN5ZgJU..RfZisIy9n5JKXGudspYLxnUeNf3r
 n7HLAbZG7V87aPiztIYkw9LBlUyJkPPMA1b2L6T9plr1De0SoVQjxNZwj5tkjYBaRZNb6o26Vvnm
 ZZuIYfbUjqzo8vRvI8DbFD1tM.eEdv3tX8iija1ooJhIs3DASHJyMzqrCgRaBcC3f3hV9RkIe33q
 7fM9_F0LyETdxKkcOXF2XGH1ocSPrhvAQA7q0s.vhH7L6BnLZYPHMNkUyQHgU6QH1Cduw9Ur17ih
 cjn982P_ShUUKrzPphHxm2oiHcQfqN37V.EwIJ6JSaY_fPNXkQ7ciHbP7PoHhhEv8R9ksIv67_Yv
 Qrqr_nYb_TUDXU1BP9mdHF.c_vIVdt6P0QJ5Wu7sd4r3R78q7nW12wezTS1q6aTgRWGw1DMM_98w
 uqK1GBZ0Dw_ckl13xmppSr4o9dNs4wwRDn1xLhlxkoScnF1jUgQlW2IXOVJZzDComtx0Irww6BwX
 8UWFYHzzK0gbFIszUw13qgoDD26oP4620GWMWfxOVVHqXaJnxun536Dqx4PtuMlR6ZKUhJv0jH0G
 oHmpjNp6W1Q9RQjuIwkawU5VL07f8eWVl62RXDxyBOO7uZ.6LiTTsTXp9LdRpJaXO1koH36dbpSb
 pLb6qoq93q3eym46RSSj8MEHDvly2ff7mFJav6U3bSKMWaJ4wphJHN5FJz3YLOkxrAwgFWxLBIR7
 i4TZx7B2Kf4xwFPtH.3xpfvbrFKlSUYMCYOCUyd9v8_zeegl60R5505wyx3rRVYIKviv5.fJk9XD
 XNw7VXazLOCO137NWcztkhiYe3RZd7SFAH5.b7UTUaC34uRRwXcfIv8O1w8RK7oC_ZrIh9OCXrLq
 20V4mkGQgEnBcnSihsI5o8N6HNr58DiaaA3TsVPeCYxmYykY5O48_Wa8LCYPeYQrvZWslB_ylGr9
 pjAgl6.m5U5_ccK7QeF7YsjOeTSzc2MMKEsj1QIUnOOSg8jE3RtAUllHDH2.BYV7_y8zH_nBUssk
 wnxSFtHVekox72G6GkbAs.wfjOeobs9i1bSooz_d7kbKPRvCl5UkYYW6N2WWd4OK2dFwhoyehy2f
 ucej6Eufsrpzvt3mV5D8rNrAEbR6n99bC5AWj1pioL4B2JjrtjooBHQ.NY1ZUl7H8hjVocu.Ip0p
 baO4C.0dHQGQIQIyqvgZl2d.Jkkcf23TsqdH3Z3EE2hRsyUa891gcOoqDsbeAMpOwSM8lTe8Y1rw
 WYeh6ybb8.8N.c04f4P_40JBlSkyucizojkUB6vu6QU65emLL9YSRqQ0SdRAM4PAS.j11ywe22YU
 s8XowRVdfBQ4Q7vxPupZLKxmhXiDmTBo14.3E8hV36hqp9NZtAimkKl_4JhUQDb28_bXclfRg4nw
 TVfoj3np26NsAHLkzBXbyBa7j6tWVf9tLA7W36kXxmhclwEOr5i1A7KX84QUALsjyWeTIOUo98pP
 qMbVUV6N0h9TBx188JpJJnub4cLhMMqZMI0Sjc3DTOeYOazOOttILEmt_MF7Yfp_OU27Nbp0TRaz
 .fPvlCN0dVoNK
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Jun 2022 01:01:09 +0000
Received: by hermes--canary-production-bf1-856dbf94db-mq9q8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b07021320cb623a45b4717a8725c3dba;
          Fri, 03 Jun 2022 01:01: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 14.0 \(3654.120.0.1.13\))
Subject: Re: FreeBSD build hardware?
From: Mark Millard 
In-Reply-To: <20220603000428.GM30607@FreeBSD.org>
Date: Thu, 2 Jun 2022 18:01:01 -0700
Cc: "Wall, Stephen" ,
 "freebsd-arm@FreeBSD.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <00729D21-5971-4595-B1D5-D8AAC8F98B97@yahoo.com>
References: 
 <20220602230000.GL30607@FreeBSD.org>
 
 <20220603000428.GM30607@FreeBSD.org>
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LDl246Q0tz3PrJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=sNHVADSy;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-0.58 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.92)[0.921];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 996
Lines: 34

On 2022-Jun-2, at 17:04, Glen Barber  wrote:

> On Thu, Jun 02, 2022 at 04:10:23PM -0700, Mark Millard wrote:
>> On 2022-Jun-2, at 16:00, Glen Barber  wrote:
>>=20
>>> On Thu, Jun 02, 2022 at 09:04:28PM +0000, Wall, Stephen wrote:
>>>> Does anyone know what hardware FreeBSD is using to build the ARM =
releases of FreeBSD 13?
>>>>=20
>>>=20
>>> They are cross-built on amd64 hardware.
>>>=20
>>=20
>> It was unclear to me if the original question was trying
>> to span aarch64 as well vs., say, just spanning armv7/armv6.
>>=20
>> aarch64 may well have a different answer.
>>=20
>=20
> No.  All architectures are built on amd64 hardware.

Interesting for FreeBSD system builds vs. FreeBSD port
builds (into packages):

aarch64 ports are built into packages via aarch64 hardware,
but targeting armv7 and armv6 for port builds is via amd64
and qemu for producing the packages.

Thanks for the background information.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jun  3 01:23:06 2022
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 A14441B6A6DB
	for ; Fri,  3 Jun 2022 01:23:17 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2044.outbound.protection.outlook.com [40.107.91.44])
	(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 4LDlWS2lRfz3hDN
	for ; Fri,  3 Jun 2022 01:23:16 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=VheKsJZBMAtiPiL/kLGjvfA70MGu1AHQYsf4kiLeGmxbwTg/8fbqMxdh/rJM3LDOizk4ZrFU5yycifhI6jywTCJRCnF/y/cu2/PmstzbzfvfAIJT/GZBe0Y1feM6WcPfxqCiM5LSDo8bjK4Jls/hMXT+Y6iWTgkzh71qxZJhyEgL6nl86IDrvahb3oBavV+k89LP2QxZYFHETbVOmlATdLDJ8Fu39JttrHarBMTKkXG2VczTaeSUx45NBeh2zAMazWBak2fiebYYPMQqEGH0mz9I2zp6f1Hr4yVkIhe4ZZmxypgHzruaftpXG7LfmqkYfCr10dJ50hhbJVFzIUEIfw==
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=nQOlAaeEmSU+jGfR4/n/WDvyUJd2vdsup3kLaTzeFJc=;
 b=TrZtKTAdgf8CylX/GsNPcKEDImDAc0B776/ofFrt6bCtDjni521czRbmlyAGQDHZNDKQYmiSaSv+qpIpmMW1Zxk80EroVOydIe7ldSNw76aPG9OOGVYcMHKjdFIfJTVLB5S+URkAfwBlmqUqfA1wdbLaTn4wfV3toau/ThPyQNwwoWOedtcmSs3wJbR0ziPZEC53ptUN2oVjk5Kc3zGkXMm13LFvkp6U49ngHlRvGdNStV6y3vRJufgPXN/sxWh28SuXYEMXlsC2fOKbkn/YbXCmdtPJqF26iXXM6WRZ73m/rKeTPLlVYHEjfCqhpusKmy45AwUzZyThVnFS+N/kZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nQOlAaeEmSU+jGfR4/n/WDvyUJd2vdsup3kLaTzeFJc=;
 b=WKCdbK7mDbf1xMIrtecvjjKKqfglgodDn3DlAHkAj09HDMwkss0Pf12KrbSZtv50xrcgpKq/5MyKJtWDZ6neouYAOPxTQej7PqLwHsqLp8HttKalVWeRCbUFJMXN8EA1DV2qLfZpoQ5F32POrej1nLLe7k6CdeMGaqzFWJ+EapgTn1wqeDzrYEHsggTuVaoR3qBHiZm2m9znzYfmdqLKk/oF531QJcrXinHLOGl+TQkKeqq6CyqBIQwJQX697AM53MZ41C2+VqvuyCdG/gKqeQw2dSSR7IeGy2LpccWhwvQdBFrJezZg6YBLJknirL6gOrEgHr6P0OTf4g8YJAAMJw==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by BY3PR09MB7666.namprd09.prod.outlook.com (2603:10b6:a03:342::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.13; Fri, 3 Jun
 2022 01:23:07 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::c4fe:8ed8:9b92:766e]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::c4fe:8ed8:9b92:766e%8]) with mapi id 15.20.5314.014; Fri, 3 Jun 2022
 01:23:06 +0000
From: "Wall, Stephen" 
To: "freebsd-arm@FreeBSD.org" 
Subject: RE: FreeBSD build hardware?
Thread-Topic: FreeBSD build hardware?
Thread-Index: Adh2xEPuOivVNUqpSYm7PfLKvCE7eQAEDh8AAABc1YAAAeOLAAAB+ZmAAAB08qA=
Date: Fri, 3 Jun 2022 01:23:06 +0000
Message-ID:
 
References:
 
 <20220602230000.GL30607@FreeBSD.org>
 
 <20220603000428.GM30607@FreeBSD.org>
 <00729D21-5971-4595-B1D5-D8AAC8F98B97@yahoo.com>
In-Reply-To: <00729D21-5971-4595-B1D5-D8AAC8F98B97@yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9c69afdb-0a61-412f-4a86-08da44ff9d11
x-ms-traffictypediagnostic: BY3PR09MB7666:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 1ZJuQEnmpZzfTO+ae4E8oBAwq8e9q9P/mRfMUlOquqsAqI0yVuWxaaH/TVqWPzCmd0Z8+NcaYvYsFjAYtOK3cztr+BuTA2WqD6Jzl98BCCtiUbMrBdMpZrZQAL8UIgFK36KuGdpBFSd7Y4U3uz3q0VWgHtVrYLBKeWTG+dydyaDA0RtkhsAsDCwycQcs7hTn2oFk6LOKeCaU+XFU7zD1inAFBLAaGlMRZg3s/KEpgAF88Tf/I5MmPUXszJX6pwCEzU1VklQ2TmCO27K3bFdS+k/TFsQ+PKETN/Qg8v1ohQ2tUMPftRGUMk4AVU2kv2hEjFhotC+0hqKCRVcZ7EsspDb8qGsX++auzWaKnBXgGYCPglugBKdwemAAtFVXe0TGj25fbNe/67RmuJmK3kV/i/1Lpr3UEXpif5ShXHfCUcIAxB5EloUABr33q1bNAe2RlXRNcK+MZOshskK3EmjkdI8K5G8HT/tQwGCAvHu72FmZu1TPAjycJFZNHkrIpsz0eKgsMRXvQIC9ChXNuDMcHSmy1+PGANYYNXwIo4fAox6yXoeUsMLzCLTLTIKJfzXtZMC0K36WBxe5TIxhJ815A0F5Fpp/ZKTNCZos1kP0Vs0fFBZQ9QySQH7OIjTOU7v/FuCeARoHA3PXSsZv4BHYf4uw3K71n0fb1IJpfHw24c9OPe2iPy0t2RY58CJyRWVNVIRcKu+Ic9CiO1HNsVA82A==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(76116006)(316002)(55016003)(38070700005)(64756008)(66946007)(66446008)(8676002)(66556008)(66476007)(71200400001)(3480700007)(6916009)(7116003)(38100700002)(2906002)(33656002)(52536014)(8936002)(186003)(86362001)(26005)(7696005)(9686003)(6506007)(508600001)(5660300002)(4744005)(122000001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Sy9xUWlnc1k2c1VsUkxsdWwreXlGUk0wQnpXSm02amRleCs1VDVRcVVHR1lz?=
 =?utf-8?B?VHhDd1A3cG5DWmNvYjZQTG5jN2lvR2FkaDBBbW9hSWREU240NlBNTkloN0dI?=
 =?utf-8?B?SGpzbjdubTI2UnJNMDBBdUpiQml1Vm53UVdwOURvUlRQL1NSWEJLcTFvbllK?=
 =?utf-8?B?SUJZak1NbnEzQlZaWnl5UW9lMS8vSUt5SHJQV3R6UTBYN0k1WEdvUmc1Ukgv?=
 =?utf-8?B?MVc0c1pEaGxOcFFHYmkzWDhGUUVYYXB6KzVvRTd2c1p4b3pNamkzejZwR1RL?=
 =?utf-8?B?am9CYUNWUFM4Q0hlb21CSndzekhwUGUyejIwNHd5TncrcXNlcTIxS0hhUFVa?=
 =?utf-8?B?RGFYeTZFNHJJQWRodFQ4R01NRCt6SjRyTmNXUzRQVklHWnMrejllWU9oQndj?=
 =?utf-8?B?bnI1Q1VtRHhUTVRmeUhCQ1pPMkdXZGdLcGQrNE5kckVVd1UwWERaQ0djdGlP?=
 =?utf-8?B?clZGNGdiamxhLzc0SDNoRXVodHl6Wkl0cG9td0RpeHU2d0ltNzV4QXpDajIy?=
 =?utf-8?B?YmUwSW5CZDhYSjlZVlNpajM2OWhGMHZTWFZlU1RTb3VzUWNIWWIrQS80Nzln?=
 =?utf-8?B?VDZkRExqMDFDOWtBQitvMld4QXhmWHA1SHRZTWRKT0NpOThobVFuejdHanA3?=
 =?utf-8?B?Wmkrb3NnVFJXU3IrWGZlblVwbk1xYWFXb2JEUEdMazBuNVJFU2Yyd3NwRXVE?=
 =?utf-8?B?QjFHVm9qL3B5SCtvaWxQazVIZXB0L3JGNUpsOWJZRkVUYjFHVWdobjE5TFZp?=
 =?utf-8?B?WURzNk4zVHBHbTZwSzNSMytKQWtIaWRrQ2NPTEFsbDJ4WVRiVmNCbmV1Q3NQ?=
 =?utf-8?B?R08rWVBoaU9ESWhZZC9GZkJiNEZJWFJmcEFMNER0cmVNOEZMVDl3akVkWmxB?=
 =?utf-8?B?S1NpMWtHSTdMNEIyTFQ0M3VtM1NLekVvUEVydDNkUDQvWXY4VGtSTEsyTnF4?=
 =?utf-8?B?WUR5ZXo4WDJJOGxMeUZDeGwzT2syNWtORnhNWmM1bERmTkNOVGhMVFI4NE9E?=
 =?utf-8?B?SFpHVFBDUGI4Y2pqVzNiaElzbjZHLzZ0VUhwc0tMRnh6d29HWHl2TUU4NEdZ?=
 =?utf-8?B?VkJ3aFZtcnBBSlNYZnByMmJmRDUzcHZsUlg5amVkajhKYXQrN3FCOUhHNS9Q?=
 =?utf-8?B?MHlleWZxcUNpWjBaT29ub25PSmtIN05TQkRKWTdheWwwMDhMUHlBM3BjNS9a?=
 =?utf-8?B?VUkyWFpsQ1NZOVE5VVBrcjFzNXN3bklqdFRVWDRLK0hBSEFUdzZTdjhFVlZn?=
 =?utf-8?B?R3k5d0pnWVA1OW5ySG1UbExJTThVbStKYnM0VE1najA3ajZIUG53S1dTaGJK?=
 =?utf-8?B?dEdYUlNkcUp0TjBmVXZyZUIvcDlKK21xMVRtM2tmL084V3FtVG1CN2wzK1RX?=
 =?utf-8?B?OU5ucTEvbjQrWG1RdGhxMFNaRjkwR0R0OFFFRWpsQlR5bzZqczNzazhzVmtP?=
 =?utf-8?B?MW4wT3hxdzJQTjBjZ3dUc3NhSGVza3R2UWJiT1E3QVNRb3NuRmR4WVNlejdK?=
 =?utf-8?B?U3djMXZKTUwwR3kxTjJOQlZFQ04wTnZyM0hrZTVaelIrV21iNjNtM0JkNUVP?=
 =?utf-8?B?OWp2WDRQR2kzL1R1NjMyazVxdnJjMGRRZkJmRnNYTHRGd3B1b3UwYWRqNVFq?=
 =?utf-8?B?MVpPWDFHOFduLzVObnRnTVkrVmNtUkJkZUpLWXR1bEpYYjdKUjUvdDhhaytT?=
 =?utf-8?B?eG9IYXg0NEZGR0ZRWTNmdng0eldDdjY0dFVjSUErc1BZVnRuU2oxK0Y3NnZT?=
 =?utf-8?B?c2JmN1NiRjloNUcwY1J4WlgwR0k1Sm11TTYwYmtvTk51alAvdGxrMVBKUEM4?=
 =?utf-8?B?bG5mT0pSMmhEMlFTUzNmdmwxMUJwV2k5LzIzSW9EckdZUnFIN0lCOGdNVER4?=
 =?utf-8?B?eWpsdUwyUFNwaHlGdEE4eTVUOG8xQmZ0MzhnRnhHbFZ0TFZMSDBGMlc2RWJl?=
 =?utf-8?B?U1dES28zcytZMmg1Sm9RWkN0RUZaK2hyN29yeFlMWFFJc05pTWxTMVRXSG0r?=
 =?utf-8?B?Y2RNWVZ6TENjcmsrb0FsL29rUFZJTlk4Uzh4UWw2blllRzRMK2xjRkY4VXEw?=
 =?utf-8?B?cm1QOXYvRkdVL0NQSi9MR3hqYkYxZ3MrbytqMVBxRFlkVFhicWg2bElZNHpK?=
 =?utf-8?B?Ukc3UjN3bTU2N1N1UTl5UXphdzVsU0d1SmN0Nmg5R0Y5Rm5MaEsyb2NPTEhj?=
 =?utf-8?B?V21zN0k0akNneGpHYllpc3BnOXB3VTVLNWhtQUVXNzZKbkFmM1dHQ0l0Sisw?=
 =?utf-8?B?OEh2d09STStUUXZZTkNCTUtmdEZDR0dhNXh2akVjWHFmNGNwMkNYSlNzSk5J?=
 =?utf-8?Q?XNKh960pc0lrrRraG/?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c69afdb-0a61-412f-4a86-08da44ff9d11
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2022 01:23:06.8695
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR09MB7666
X-Rspamd-Queue-Id: 4LDlWS2lRfz3hDN
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=WKCdbK7m;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.91.44 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-0.40 / 15.00];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.91.44:from];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[redcom.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(1.00)[0.998];
	 DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.91.44:from];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 880
Lines: 12

VGhhbmtzIGZvciB0aGUgcmVwbGllcywgSSBndWVzcyBJIGNvdWxkIGhhdmUgYmVlbiBjbGVhcmVy
LiAgSSBhbSBpbnRlcmVzdGVkIGluIGJvdGggYmFzZSBzeXN0ZW0gYW5kIHBhY2thZ2VzLCBhbmQg
NjQtYml0IGFybSAoYWFyY2g2NCkuDQoNCj4gYWFyY2g2NCBwb3J0cyBhcmUgYnVpbHQgaW50byBw
YWNrYWdlcyB2aWEgYWFyY2g2NCBoYXJkd2FyZSwgYnV0IHRhcmdldGluZyBhcm12Nw0KPiBhbmQg
YXJtdjYgZm9yIHBvcnQgYnVpbGRzIGlzIHZpYSBhbWQ2NCBhbmQgcWVtdSBmb3IgcHJvZHVjaW5n
IHRoZSBwYWNrYWdlcy4NCg0KRG8geW91IGtub3cgd2hhdCBhYXJjaDY0IGhhcmR3YXJlIGlzIHVz
ZWQ/ICBJIGhhdmUgZm91bmQgY3Jvc3MgYnVpbGRpbmcgYWFyY2g2NCBwYWNrYWdlcyBvbiBhbWQ2
NCB3aXRoIHFlbXUgaW4gcG91ZHJpZXJlIGlzIGV4Y3J1Y2lhdGluZ2x5IHNsb3csIGFuZCBzb21l
IHBvcnRzIGp1c3Qgd29uJ3QgYnVpbGQgdGhhdCB3YXkuICAoMTcgaHJzIGZvciBnaGMsIDEyIGZv
ciBnY2MxMCwgcnVzdCBmYWlscyBlbnRpcmVseS4gIEJlc2lkZXMgdGhhdCwgYSBmZXcgb3RoZXJz
IEkgd291bGQgbGlrZSB0byBidWlsZCBuZWVkIHN1cHBvcnQgZm9yIEFSTSB0byBiZSBhZGRlZCwg
YW5kIEkgYW0gbm8gQVJNIGd1cnUuKQ0K

From nobody Fri Jun  3 02:18:35 2022
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 291981B4C310
	for ; Fri,  3 Jun 2022 02:18:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4LDmlW2xDfz3mjr
	for ; Fri,  3 Jun 2022 02:18:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654222719; bh=utYQ3K/F+jTZ1GC3vVnonjC/hPaDxg1+r5acuHCz/SQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WNDwlom2hWfBs4QLokBilXd+kJ653aZbvO8tuvbaf6WQ7ayxzwoM0tIhE3dIRw+PptEYEEU2kdyFhun6t6qv0QwM5kN6D2KlTd96MLj2ZoqCijdn2h/RqLHAEBpJdap0dgGlPMhcD1wBxTL/9ARc04VPBVDb4n3MSgJnJc2dpT9cDyZVOq1jcRsAuAaakRz0aQguzBetucY603arv3gFme4AdqRPLcT6WgvcFYgRbXN+JolSQSmh6KTXArdm/3bpRAEYuSUFtxYdPKQhYZ6BYPxxZ50K0kFhPMPgJEHco+RafDEwAVVC3lf84fALdqES6FP0e/RBvLkRgWURokUItw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654222719; bh=CUFVMEd+aCFSQktKk/H4Z5r2pXk0uBgYsbDqAZpx86K=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lwbLJBFw/Jv9aYprTBbK6JKvtnqaapTBpNPFf32a657YVOmj9mbuLjDadehod0X8C6Nauoy/57MSlCzwMYoBvZXZwidhEx6SCyKUItGLRr+WT1O2vcBs9889rDEGek23stKCbQNGdXFOKwhKBuHzmkLD/NEU5IUV9splOFvv/eN8ssibgECNx5AlMmmGDXm7FqMjnd28D7XNXtcF5hEX8Pa2Os++MxWm5z+qH3+e5PAt0aHOuDa9t5tRa2y+oMLU1JGhNJTXHuUHypuatfJpEJmieCtG77LrSOfGfUtKD09XKxF1S/K387Xj31eFYKyHK/lv5S84gD5+e26Aplz8MA==
X-YMail-OSG: tOXmTSkVM1k5GNYp1ZzKaCyOkNojcPff9UYAkW.vthORlIQVME0mcRju2UHPbyZ
 QQ_8jifB59BKH8brmgJaotGxCCNU4.vh4TgjnWrQ60Hf7.Zqf2GNJbawGqty7Goj8mSZs.HapNE1
 8Z1BcOS6qVVRLNRMRwTbbWvHXOpyZ9B.ndcF9jj6ShhEtZ.22Gs1WjKB_QjvKZJstz3lTDptloFw
 TgMIWWeFFqTzlLGhZzLm4YWS2GBwWD.1.APlJgIQ6Uvlb2Cj5OaTAcLkFR78wak0xvRniPbZWDRs
 NWGzNLmbhRfioYVKUlLszeSfbrfu0m4M4pejlTYnF.R1uxXFZ49LAic4rDurk1GCS6QagQUDGt.c
 .HCa.XxFXAajpbdGm.1n0wJPPGOz64eK90hw0Pjo8iIfc3Pxc2oQymNoRIg46OdDDSJcIl.mcvSe
 .PHppMCabQYLo99BRTHXNHVBTp5n0iPojEC9yNEVa0qFm6B3Z0H24ABJyEQa0Zmruwvmo30DZDTG
 pRRm65hmhPrxDw_OAGAT96Y5iPkOuMa0T8C9ntCUSM5nK7hcCs4bzLr9DLeAC629hVlLWy7svDU0
 o.HpbRM1I5j5H7v3UeliBDy5EbcEMhIkame8y.6Y1Xk6QgaxH2sLWB54FKHVCueKKZKe1asZw.yJ
 FM3Z1uKiWHmyhOP_iMHb8XobyQ0Cs2BawjbAtjI9ruz91Y4sNL26D_TzL7BTxUTxrTkYmpFQ1xXU
 p0F4mqsQH3Q4OmBWU1hPgFNwYF4x1U3u8PQ1fkqiabH9uFUV53FePFHQkrloQCOYTsxhzg4U8fQp
 ZxR0LV4sl8K_LdO46GwxDIWzIJxb7GyB6i1GMlyHMwlStvBWTqA4AfxUia07pRe8uk53lm3PIsDg
 SDSM6EgXykHV7mXua9sH6M8bVfXAu8K2Jo8.ifjXX_nI8ekXzbbU1gpjYBI4MTfLIoI4HoGkKAga
 ELuc44hOtfO5x67SbNinf4l7AXbCC.fCe7jIv1B._C4pSHnHBs9_EFDUsL4jHYPBtslDUFNA54qW
 jbN5PeNz4kJGUW5lEJErCjS0JxnGpPNJEDkxg6w1MDgFc_YqHZrMXrcdLIf8G15VQdi9KepVjqsD
 7PQFX7YYgWB9Py2GX2Nt3FXicEcTCCTmChUU3sN_9eEjoZUFApQzYiVh_z_EUqT1F4W_aL3Pp7iA
 W88vEt_V0qjQoerJNd6iKTe8n6UOSzJgndw9J..sH0rA4um0Kl79mXGEQT0riJk063YPfa7SlNou
 NOjKFTDnyPweBjZzWhh4TVN4b8rhgX9w2bdxEBXTt2DWjd1ei0Ey3llqE2nCrb8K1s1Lv0F71qnN
 Cn0.0KeCwTk_edcVOKXuygEr_GwQ6WTCTbaVHN583VZGPFcRnnE4gQh50nM2gNO._xjRoWTdkSkc
 A.baZ7RoL9Rq4hEW7yBADn2wFKXgDZ6ZJbWUteNZ8CnF.T6wumEL_U1Tf4sXsW6yqlkY3HFhZeNf
 NV2obJId9cPkCzznjhLTxo8CUCBQXhwozKMBXd.jckeuTxzv7dxrpgn308o4JvkjNZPIoYNAaDST
 iqYVGIWhX2QRKg4XPktFwv2IFXjwoniH3sCSTTHUpFNjSEeh3WQew1vGdF699ESk56ychhjoX2GQ
 BiwkKciw4BvEuDUnaIgVQMC3ql3JHF4pvqbpHSwU0193UVKRIlVPiZrQKFmj2cCD6CvuB6H67T5r
 yoYiTbFp0yJWowyOfpiMHXAFi18a3x.VCUn0qPOJrL87_8lIvp1WYztjbPwNSQzCYgxc9N4tdMqG
 d7GVVqlJqA2wvd3G7ZUsHy9KeLFkgnVS46e2ChHiDqBGeFBytj_n85uBQjFegjRR0L0zdhjt73cZ
 uAhj20S9qL5gMnxoaCDoeAa_fD982pJP1s7ejOkDAYFyQxaLZ2n3lKcVW8exZMHcOzPQj9nD8m2u
 hqZGhFIO3mPYagwxb1e.y0VVBGaurqpamAbaNdybdC.4Mx1acYB0hpkuOzN12TqeEf7.YY00hSQr
 t_2ycFTi.G2Twf6xuFh15Jqhnw6fB8t9NPS1LJRmWtfQlsSitHpvwr8Ufg48Dkn7S2vnhozOLlV0
 EcNpNpmDtjUFh2lGKF_ehHGg.q0w.Wo6W7JxDwH_fVbfFhFopVX9qQw6MjyJzsh8_D3itlRi4bD8
 8.GShK67X12_KzhefB7fLm7SNhPNFAStHROW5TYdmJXaFMFanzxtGrDTmdXgsJXtVMSemoAuTlCi
 H8BZAQ0fD5.LqxXkTOGImgj6_WRNEloHMYfD9XHYsx2nJ7LMt4XI7H.NeYFWecE8WMy5ydEUmdIy
 CKHZH_wa5phq6nXCbK9BgscGo43k-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Jun 2022 02:18:39 +0000
Received: by hermes--canary-production-ne1-799d7bd497-nrsk4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c6ab327fa969d71a66977c84deae8b1d;
          Fri, 03 Jun 2022 02:18: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 14.0 \(3654.120.0.1.13\))
Subject: Re: FreeBSD build hardware?
From: Mark Millard 
In-Reply-To: 
Date: Thu, 2 Jun 2022 19:18:35 -0700
Cc: "freebsd-arm@FreeBSD.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <54AFC504-FC92-4FA7-A061-7226E3DD256C@yahoo.com>
References: 
 <20220602230000.GL30607@FreeBSD.org>
 
 <20220603000428.GM30607@FreeBSD.org>
 <00729D21-5971-4595-B1D5-D8AAC8F98B97@yahoo.com>
 
To: "Wall, Stephen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LDmlW2xDfz3mjr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=WNDwlom2;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.38 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.12)[0.116];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1934
Lines: 58

On 2022-Jun-2, at 18:23, Wall, Stephen  wrote:

> Thanks for the replies, I guess I could have been clearer.  I am =
interested in both base system and packages, and 64-bit arm (aarch64).
>=20
>> aarch64 ports are built into packages via aarch64 hardware, but =
targeting armv7
>> and armv6 for port builds is via amd64 and qemu for producing the =
packages.
>=20
> Do you know what aarch64 hardware is used?  I have found cross =
building aarch64 packages on amd64 with qemu in poudriere is =
excruciatingly slow, and some ports just won't build that way.  (17 hrs =
for ghc, 12 for gcc10, rust fails entirely.  Besides that, a few others =
I would like to build need support for ARM to be added, and I am no ARM =
guru.)

The aarch64 (arm64) package-building servers are:

http://ampere1.nyi.freebsd.org/
http://ampere2.nyi.freebsd.org/

The "ampere" part of the names likely names the
company that they come from. But I've no clue
of the details of the configurations of the
servers.

A recent recommendation for aa aarach64 developer
machine was made in a bugzilla report exchange:

QUOTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261977

--- Comment #45 from Piotr Kubaj  ---
. . .

(In reply to Robert Clausecker from comment #43)
. . .
Regarding your earlier question for a capable ARM hardware, I'd consider
getting something like
https://www.ipi.wiki/products/ampere-altra-developer-platform .
END QUOTE

Note: ampere naming again. No claim that the hardware
matches the FreeBSD aarch64 package-builder hardware.


Separate note: if you look at the build times on the
FreeBSD servers, note that the build configuration
used limits the builds to 2 make jobs per builder and
the number of builders is smaller than the number of
hardware threads, if I remember right. (Not unique to
aarch64 for such configuration properties.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jun  3 09:55:40 2022
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 B0D4D1B6450D
	for ; Fri,  3 Jun 2022 09:55:53 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020026.outbound.protection.outlook.com [52.101.128.26])
	(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 4LDytw0x7Mz4Tj6;
	Fri,  3 Jun 2022 09:55:52 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SXqcvGbIW3WZvPOxyVuzx29sf3He5IS07SBfLVAdA9ng7wzMcTU2Lx8TrouiG46G66H8GeR3fXXet6+KI9wfikuFdHLHBKiw6QfW8CL5ZWZRdsKOgx77LJJjJFFziN80iPX/2R175sTndUls71+92v0SA+XMCZuDOBrOehL+58EEDWNVBa4qce2B8wdtU/Fsu9oJHmsYV3b5qeKdXOYVt4JEuqsoWaR8geM0PpHKe2omXA3QwrqsKZDUJ6Ev6FoeYl6q5xAZiY2I3N61pgSe++cPTCcgPI6qq33gUF5AoGeyyTRXo/MGnpnMzp6J0hqo07ZRAOO+lQ78hCQB5sqExw==
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=UxdYOZTgt4uzAOBK6lX3lxsRP9o0xzEs8CefcPt12s0=;
 b=S3XhBse1nirg4S2VJ0fvHBmFf9hPqjDDfgTcJuysc1Eh7Y/jXEfNnoBUuHNvFXJ1mLY5EI/SPeGXOrLLwn5Pfpp7B4zKrCevluPBRBizIYWWIgUzzRuKmnHcvK0DBWVOhweGmEjQDVDJHPnpanOwV2oYkVgtfqTO1K+qk9yNY23VLhsQjEMV6TFkcqvk0evF5+Ue0zAlcB6gwHXX26GVer/QRvA1UE90tLpTGJERuyMcGuHp+3Ypg3TVFQgfd7HaGQLRZYkVq6S7HYqc5bBiaKhoW4EI8OPhBL90FQO5yGIV9Is96R116EwKjq0q1gWnml6DXqffwxLaP/AsnYMIBw==
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=UxdYOZTgt4uzAOBK6lX3lxsRP9o0xzEs8CefcPt12s0=;
 b=OG726IAU77gIiY1rj3U0ZQ0sKzs+Cn7HXToI4ahu/3TFemJOboBQrWD2rWEw59Fxim95ejTwXYj4fxYCB+J3oA2uHI4Ab6xFbK47reqCkeBkSkXr5X0D5h1SPg3FXUF0Wb2AxSy8pMIoi7mdcWUNATtcfvtWbyxLu6oAWoopzos=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by TYZP153MB0447.APCP153.PROD.OUTLOOK.COM (2603:1096:400:23::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.1; Fri, 3 Jun
 2022 09:55:40 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::b1b6:de83:b69f:2826%6]) with mapi id 15.20.5332.007; Fri, 3 Jun 2022
 09:55:40 +0000
From: Souradeep Chakrabarti 
To: Warner Losh 
CC: "freebsd-arm@FreeBSD.org" , "tsoome@FreeBSD.org"
	, Wei Hu 
Subject: Re: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Topic: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64
Thread-Index: Adh0Btw+eCL//YDTTLGpdoefjTg5UQAJq/UAAHVgdIUAAZcjAABJFjd5
Date: Fri, 3 Jun 2022 09:55:40 +0000
Message-ID:
 
References:
 
 
 
 
In-Reply-To:
 
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-03T09:55:39.713Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 196816c2-dcca-485f-33c0-08da454737bc
x-ms-traffictypediagnostic: TYZP153MB0447:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 6JGFQViVCBA3nZHU+GpY3lkk/KLj2IbquUN9fYv8Ouapt9wmwC50cEQrjkYbe3VaVlI48ocbPog00/cWTWhmkl1oQsXLPuxbrnfMoqJC8vyrjIkgZglk3QZV3vmND03+QcvcuWNNjl9JXRbKPvO9mpakDrUrZ5fuBVabn31JpHlEQEkQ+qioMvPQYj2udF6k9Iz2HV86QY2KwAh2qU5zef8zVyiD2LzND1mNQhljSyPYH6jMq9NIhDYcdbRGHc/aMX9C2w0wA6hB29invDM07oIGZUp/tXdGiKWWt6y2l5dhf9+IEvfITtHSwlkjrfqqcWMGzoPPa/WqXkScxQ8tm9YotDkPrBe8wdLxGuaEgvwQTF4W6x1l3PI9WtijfF0sCQXw/rhDJzlgb7b3bPfJJg4ZUGEdQldocPgwyKQl5uy7rkBKv+/NZuoeFT1QvWAL7CRX6lbKuxIncO4cYrtIkL3b+VU8xx9Na2ivqFMkQBnD9hJQOYNCwZfAAn9SPwO02V4lA1Jkp/IzMwnN4b7eX5WQmKnWgzrL8qvJCtDIQSpDnraeAVcGP5W+XsMyV8+qb4bMLcXggZKj2coJcvC3f6Mk88cPxe+wlp7736LuOWXZ11XFfJm5HTC4KK8nW07kEl/fsvXPJR9zi25NwHfL8oqL9TMOxksfdiqpU7uR7jEkCUgXVoxz5l8QnC0e8t9C5kC5otrE+F/9CoszYee/uF55U4uwz/Bi9JvMI459iO9vV2rcUhrgmEl+Bljxhvit0WKGsHTjkTeDE/2C9XjeTitMZd0V+Cfu11EGL1aGdOI=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(508600001)(71200400001)(55016003)(26005)(6506007)(38100700002)(19627235002)(9686003)(10290500003)(82960400001)(316002)(82950400001)(33656002)(6916009)(186003)(7696005)(54906003)(86362001)(107886003)(91956017)(5660300002)(83380400001)(52536014)(64756008)(66446008)(8990500004)(38070700005)(8676002)(76116006)(53546011)(4326008)(66476007)(66946007)(66556008)(2906002)(8936002)(122000001)(460985005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?Windows-1252?Q?lzkEA0pvcaWMpFqPjgW4lWSokwJSJY+7Drs4nevMWUKILtQTOo4w6uac?=
 =?Windows-1252?Q?dYszKlbF6TXbxYVyustjzjJimJnMfOhoSdXdspD7UhJJ6mH/rE71hM/3?=
 =?Windows-1252?Q?FamPjhBS/qtc8/G6e61pMiA9tMZi4yQbOz9Y4k7DfUUqbpzXvJ5mQKFh?=
 =?Windows-1252?Q?yMHDHg5noH7OPoD5l5NcEqwyFd4lBvPHDa2CUIvrXH4i3D5yfkKPTlN7?=
 =?Windows-1252?Q?EnR9LurGUQcQeOFLXmUH+WZ69twpfauqh5noxadoiqgNDQbcUp9Ol9qQ?=
 =?Windows-1252?Q?BX+UiKVwkI1i5nZI7uR6RXpx4QjLMVI4Ft4OYI4mfwH6MdcuoYWrqgLh?=
 =?Windows-1252?Q?s01LO89q67XLDY8uS0XXr9JeRUqWv9gumpacUQsthkdqzdTkbxR83bfW?=
 =?Windows-1252?Q?bTfGNQlmop8pa9DKou2s4K2/tklO73iRdEtgUVn0TUxmuwmtPejbnTIQ?=
 =?Windows-1252?Q?nd2FVYgJWL0YL9mY5ePMNaetb2HOTXJoVPj2ZGwotFPhujBV0pzAr7/i?=
 =?Windows-1252?Q?stHnImq0sKbp1qJS4aegIQOb23+lpYEO4Yt3RKZc6K7jyf9ppSnRskud?=
 =?Windows-1252?Q?DtGlmDT37l7GtfhyLp47b2GbQ+47a76p20cLAjvXYfdtOq8K3G2Z49aN?=
 =?Windows-1252?Q?7LOSvnZ2o0HcXzRxNyNUfAi6JJ/0Ji4Kos4uarV21EpWA21z/TwhG/6p?=
 =?Windows-1252?Q?bvofmwLb7ouRhcwakaFaqfxnTtKq4jtZy88xcfql7vS7SsXlMErnWLD1?=
 =?Windows-1252?Q?rM3o2RWg8YYD6GZ6D6Mxx+ir6fVVprKpvyBEeNnuYJFF5xyeTHNEJOPZ?=
 =?Windows-1252?Q?ecTt+RA8aoR0HGxH48S0j2TT+ZgcMT0/JKDC6rpvOTyiMhY08JukPrAu?=
 =?Windows-1252?Q?nHNzs6MizhrRRDnB2GDDTnrNQQRDpDPU0KnPUqZhQapG0rpzY4WB8bRG?=
 =?Windows-1252?Q?ytTihsM21LSsIOvjTPdJ9jCXGqacdsjZUiFX/C+OiYmk3qZiusKQl3XD?=
 =?Windows-1252?Q?f3ZkYtmdPKJxQKVTJH4MuskVqMLjksCF7ys0LP5N+BqfEpFLapGbxSjG?=
 =?Windows-1252?Q?rnFb9wypTuENghDvx3to55IsBqWOhblGSLwUIPkfWKyTiJ9B38N7bHFO?=
 =?Windows-1252?Q?OWdCcy3fzr0m6cW8hYRaZftUxD2CtT2V7D1CcRYrf3xsJw+cqY8Hw6h8?=
 =?Windows-1252?Q?lOSxE2T6CLtV3uxWtajwjMKcKuyK7IJOBMkVJ6tw/A7C4tZmR1XIlajX?=
 =?Windows-1252?Q?M4gtYlUio8uWKrhziy2Z43yJBA0H+FRcgitf3sAYc1W5LSk7Fn+W593p?=
 =?Windows-1252?Q?jO4jm8fqQKOryMo4tZ2sDB7F3ttn242a8bLfowCbhCnAxCShQ9VSSIAV?=
 =?Windows-1252?Q?wwqyKM6CBKK4L5paaRm6N4s28eHcVsvN9rfhPs46hly0PtItRg+OdxdK?=
 =?Windows-1252?Q?ge1i3PeT9FmdjM2KNTfoy6YUEo8EQw8qim8ZJOzk24HdLLqpo8LEhcMX?=
 =?Windows-1252?Q?IV0u7An+6BIaaLXg5VxhMWPi7DkwSCPDW6iKUnbQoLIZKT9fFx+ezc+J?=
 =?Windows-1252?Q?8vC6pYaVESduXDs7TxcA/bk2Ob15qUfXW1XFUUwrV93DrcoJ7LBhRenV?=
 =?Windows-1252?Q?CB0wsPi9jbA9onETgibGjDIHCZVbOdfE2d2H6Ik0vVMRI04gMsAZRe4f?=
 =?Windows-1252?Q?046oXJrLeR/9FtPgFWmPCXrCvwHf8endFNKlFLxsOKgD1cRb63DbHV9F?=
 =?Windows-1252?Q?+xm2KJGEYiltiAbXkCClz8uHh7fIFTHY6SnW/TTapmBgCLbO9MQylZ3H?=
 =?Windows-1252?Q?Mv3xtg=3D=3D?=
Content-Type: text/plain; charset="Windows-1252"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 196816c2-dcca-485f-33c0-08da454737bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2022 09:55:40.6109
 (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: hjIrnmFic07DgZFPRH5qldLbOFHHcFOCcxj5KFxYwLpKAWrCPDUhvT63IGxVWBb7zXMSEseC/Z+8FQOusVCJmpmYMa9btP9hsz7aTUwVfVQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0447
X-Rspamd-Queue-Id: 4LDytw0x7Mz4Tj6
X-Spamd-Bar: --------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=OG726IAU;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.26 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-8.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4981
Lines: 176

=0A=
Hi Warner,=0A=
=0A=
Device "ttyAMA" refers to a UART with hardware part # PL011.  =0A=
It's a UART that is specific to ARM processors.  =0A=
Linux has a driver for this UART at drivers/tty/serial/amba-pl011.c.=0A=
In a Hyper-V VM on ARM64, "COM1" refers to a virtual PL011 UART that Hyper-=
V provides to the guest.=0A=
Set-VMFirmware  -VMName  -console COM1 adds a ACPI table for SPCR.=0A=
=0A=
When we run =0A=
Thanks & Regards,=0A=
=A0Souradeep=0A=
=0A=
=0A=
=0A=
From: Warner Losh =0A=
Sent: Thursday, June 2, 2022 4:16 AM=0A=
To: Souradeep Chakrabarti =0A=
Cc: freebsd-arm@FreeBSD.org ; tsoome@FreeBSD.org <=
tsoome@freebsd.org>; Wei Hu =0A=
Subject: Re: [EXTERNAL] Re: serial console and comconsole in FreeBSD arm64 =
=0A=
=A0=0A=
=0A=
=0A=
On Wed, Jun 1, 2022 at 4:03 PM Souradeep Chakrabarti  wrote:=0A=
Hi Warner, =0A=
=0A=
Thanks for pointing boot_multicons, and yes it has solved the problem of Fr=
eeBSD kernel boot logs=0A=
=0A=
not coming in Putty in both x86 and arm64.=0A=
=0A=
Regarding FreeBSD 13, =A0yes loader.efi logs are not coming in Putty mostly=
 because of EFI gfx usage=0A=
=0A=
which is not supported in Putty.=0A=
=0A=
Now we can overcome it in x86 by setting set console=3D=94comconsole=94, as=
 it is using the different=0A=
=0A=
uart implementation of comconsole of loader, which is not the same in arm64=
. The implementation=0A=
=0A=
of comconsole in arm64 loader.efi is not supported in Hyper-V looks like. A=
s Hyper-V only supports=0A=
=0A=
ttyAMA0 for serial console in ARM64 but supports uart in x86.=0A=
=0A=
How is that connected to the system? Does it appear in dmesg? in fact, a fu=
ll dmesg wouldn't be bad to have.=0A=
=A0=0A=
Regarding ConOut, I have got it from x86 FreeBSD13, (as arm64 is in the pro=
cess of bringing up and=0A=
ConOut is same for arm64 and x86, confirmed by using efishell binary and Li=
nux shell).=0A=
=0A=
=0A=
efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut=0A=
=0A=
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut=0A=
=0A=
: AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,02780ada77e3ac=
4a8e770558eb1073f8c7e020566280ce4daeb7520c7ef76171)=0A=
=0A=
Thanks! That confirms what I thought I knew...=0A=
=0A=
Warner=0A=
=A0=0A=
=A0=0A=
On Mon, May 30, 2022, 3:31 AM Souradeep Chakrabarti  wrote:=0A=
=0A=
>>Hi,=0A=
=0A=
>>I am trying to access virtual serial console via Putty and in 13.0 it is =
not working=0A=
=0A=
>>for both x86 and arm64.=0A=
=0A=
>>=0A=
=0A=
>>It is very easy to reproduce:=0A=
=0A=
>>1) In Windows Hyper-V set a =A0FreeBSD 13.0 VM=0A=
=0A=
>>2) Use Powershell in Admin privileged mode and run following:=0A=
=0A=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Set-VMComPort -VMName  -number 1=
 -path \\.\pipe\Testpipe=0A=
=0A=
>>2) In another Powershell with Admin privilege run following:=0A=
=0A=
>>3) start the VM and open putty to connect the \\.\pipe\Testpipe in serial=
 mode.=0A=
=0A=
>>No output will be seen on putty.=0A=
=0A=
>Not even from the boot loader? That sure sounds like the automatic fallbac=
k to simple text output isn't happening.=0A=
=0A=
> =0A=
=0A=
>What does:=0A=
=0A=
>% sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut=0A=
=0A=
>tell you? (Or run as root if you don't like sudo).=0A=
=0A=
> =0A=
=0A=
>The boot loader grew a non-optional graphics mode that's disabled when the=
 boot code=0A=
=0A=
>detects we're talking to a 'serial port' between 12.x and 13.x. If you are=
 getting no output=0A=
=0A=
>from the loader at all, I suspect this is likely to blame.=0A=
=0A=
>But the same works in FreeBSD 12.3 and Putty gets the output from EFI load=
er for both x86 and arm64.=0A=
=0A=
>But during kernel booting the console output does not come in Putty, it on=
ly comes in vmconnect.exe.=0A=
=0A=
> =0A=
=0A=
>So on 12.3, kernel output doesn't come out of both? Do you have boot_multi=
cons=3DYES in your loader.conf?=0A=
=0A=
>If not, only one of the consoles will get output from the kernel.=0A=
=0A=
> =0A=
=0A=
>Warner=0A=
=0A=
>>Like below :=0A=
=0A=
>>=0A=
=0A=
>>Loading kernel...=0A=
=0A=
>>/boot/kernel/kernel text=3D0x931f24 data=3D0x187450 data=3D0x0+0x2d095e s=
yms=3D[0x8+0x138120+0x8+0x124824]=0A=
=0A=
>>Loading configured modules...=0A=
=0A=
>>can't find '/boot/entropy'=0A=
=0A=
>>can't find '/etc/hostid'=0A=
=0A=
>>No valid device tree blob found!=0A=
=0A=
>>WARNING! Trying to fire up the kernel, but no device tree blob found!=0A=
=0A=
>>EFI framebuffer information:=0A=
=0A=
>>addr, size =A0 =A0 0xe0000000, 0x800000=0A=
=0A=
>>dimensions =A0 =A0 1024 x 768=0A=
=0A=
>>stride =A0 =A0 =A0 =A0 1024=0A=
=0A=
>>masks =A0 =A0 =A0 =A0 =A00x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 <=
<<<=0A=
=0A=
>>=0A=
=0A=
>>After this log is not coming in Putty in 12.3 for both x86 and arm64.=0A=
=0A=
=0A=
=0A=
Thanks & Regards,=0A=
=A0Souradeep=0A=

From nobody Fri Jun  3 15:19:24 2022
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 4B2301B5945A
	for ; Fri,  3 Jun 2022 15:19:59 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 4LF64S1nMPz3hQx
	for ; Fri,  3 Jun 2022 15:19:35 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: by mail-vs1-xe31.google.com with SMTP id l13so6207793vsi.13
        for ; Fri, 03 Jun 2022 08:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=F32GkMVQX8dYKuz9mHBa0LL8OQ9TTjXXSD2KKN+dF8g=;
        b=nvmqv40BtT0BczOndeZhqSAfVraAmXl+5Z7sbCVWFGacWxzMYknlC+lgTz3W7C2Ez7
         e85vZpBphTPAA4BEeAtDKjIwSdPrpQ4eco6e85KZDvVpumAonB0QDM9adfVaVdkVs2cd
         HbRnnE1Cu2+TqQRrj81QAao8JGLRRHWCBx+iDcHcClG9DvEJnZ3culrSX3Nn6Va3jkA1
         yLBvAnrR5sqbTwLfcJviK3xep5sYGbfrBo0vRTeT3c8ytUYnTA+AwbjUdlglfxZQGtti
         Q9OQuVWyAC8/IVqlvODOc9rgun/8XREXXhpruxMH2G1UHs2gGcsFlgh3zLns1Lzab03G
         4cOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=F32GkMVQX8dYKuz9mHBa0LL8OQ9TTjXXSD2KKN+dF8g=;
        b=OKHZfzK6yqmpNpUYbU8meAPyQpBpX0cn+MFbatcgOWdITdlSgHccWiKnCcX4AOc8zK
         uW3Ywuk7/sj87bvtL9xLPcLtdRUIcMq2M1HTbBVxkh7vgdaIOUagZUq611TFvKd+pzhH
         j3bA+RKRatxRb3o3gRsb331BFUsgVYvGqMTqmCOmL+71SLi55bR6f5Q3xN0wtAePPUu3
         cObSz0uAGYK98J/eakmLL8Bf9KImj6nxcPg7bSXfbPUxKf9Np/7c1SDaPGqN0eW4hSEx
         NdbqNoDxkQhthvKIM0Tgg06I10O6HUFC4feCYGONo0JgELqxtJMCKNIVuITv17VrWNjF
         /qLA==
X-Gm-Message-State: AOAM531LEam/98Wck4HpbkSi4G6fM00d3GseSvy8E8qUata5+QR9BqP/
	zN9Q7duLnfs2RfPatKNuT8jLN/Vv4fsxJG7/Tjx4D5vG/x4bkw==
X-Google-Smtp-Source: ABdhPJxEw1R/prG0+aNBT6FDuDx3LdV0R8ot3qLcwWfLJH67pMN3ibBa3+nfihA97JEUaDTNE6qWpdL8pPaN0sY4jFI=
X-Received: by 2002:a67:ea85:0:b0:34b:912f:2c66 with SMTP id
 f5-20020a67ea85000000b0034b912f2c66mr2500212vso.42.1654269575226; Fri, 03 Jun
 2022 08:19:35 -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: Joe Nosay 
Date: Fri, 3 Jun 2022 11:19:24 -0400
Message-ID: 
Subject: Re: a small report from the Amazon AWS world
To: Dennis Clarke 
Cc: "freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="00000000000064ebd405e08ca65f"
X-Rspamd-Queue-Id: 4LF64S1nMPz3hQx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=nvmqv40B;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of superbisquit@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=superbisquit@gmail.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 URI_COUNT_ODD(1.00)[3];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3949
Lines: 93

--00000000000064ebd405e08ca65f
Content-Type: text/plain; charset="UTF-8"

https://aws.amazon.com/marketplace/pp/prodview-n65semc4zdkai

Boy, do some research

On Thu, Jun 2, 2022 at 8:15 PM Dennis Clarke  wrote:

>
> The Amazon EC2 experiment with FreeBSD 13.1 on aarch64 :
>
> Today I bit the bullet and trudged through the baffling config options
> on the Amazon AWS EC2 interface to get FreeBSD 13.1 up and running. I
> went with the r6gd.xlarge type instance which provides some mysterious
> four core config and 32GB of memory. There is also a 237 NVMe SSD in
> there but I had to search around to figure out where that was after the
> instance booted up.  I did not see any way to get at the console and do
> the installation myself because I would have gone pure ZFS. What I did
> get was a 32GB root device thing at /dev/nda0 and the blank SSD was the
> device /dev/nda1.
>
> Performance is not thrilling.  Nope.  I am still doing a few compute
> tests and also a file thrash on both the UFS and the ZFS filesystems but
> there is nothing to write home about thus far. What is far more scary
> about all this is the cost of network traffic which could go well past
> the four hundred USD a month mark on a halfway decent busy website. My
> calculations could be way off the mark however.
>
> Not sure what else to say but I am still running some baseline tests.
> Very happy to see the AMI instance offer exists for FreeBSD 13.1 on the
> aarch64 platform but I have no idea what I am getting for my money. Yet.
>
> Any questions ?
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
>
>

--00000000000064ebd405e08ca65f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, J=
un 2, 2022 at 8:15 PM Dennis Clarke <dclarke@blastwave.org> wrote:


The Amazon EC2 experiment with FreeBSD 13.1 on aarch64 :



Today I bit the bullet and trudged through the baffling config options

on the Amazon AWS EC2 interface to get FreeBSD 13.1 up and running. I

went with the r6gd.xlarge type instance which provides some mysterious

four core config and 32GB of memory. There is also a 237 NVMe SSD in

there but I had to search around to figure out where that was after the

instance booted up.=C2=A0 I did not see any way to get at the console and d=
o

the installation myself because I would have gone pure ZFS. What I did

get was a 32GB root device thing at /dev/nda0 and the blank SSD was the

device /dev/nda1.



Performance is not thrilling.=C2=A0 Nope.=C2=A0 I am still doing a few comp=
ute

tests and also a file thrash on both the UFS and the ZFS filesystems but
there is nothing to write home about thus far. What is far more scary

about all this is the cost of network traffic which could go well past

the four hundred USD a month mark on a halfway decent busy website. My

calculations could be way off the mark however.



Not sure what else to say but I am still running some baseline tests.

Very happy to see the AMI instance offer exists for FreeBSD 13.1 on the

aarch64 platform but I have no idea what I am getting for my money. Yet.


Any questions ?



-- 

Dennis Clarke

RISC-V/SPARC/PPC/ARM/CISC

UNIX and Linux spoken

GreyBeard and suspenders optional






--00000000000064ebd405e08ca65f--

From nobody Fri Jun  3 18:41:58 2022
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 C18751B54D31
	for ; Fri,  3 Jun 2022 18:42:34 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFBZd4cCJz4hwd
	for ; Fri,  3 Jun 2022 18:42:33 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-4.432, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.32,
	T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 253Ifwqd007337
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [10.14.0.8] (static-198-54-132-39.cust.tzulo.com [198.54.132.39])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 253Ifwqd007337
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT);
	Fri, 3 Jun 2022 14:42:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1654281720;
	bh=ExgSo0ZN1H2ArgOjg6FBYhMtJC6F6qVNdpQD4RYzse4=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=nlYE9dAZMJiJnQa6FwNFTGUfgRlbfkwccLXL/0niI7xA5uiTYvOzx32NGgsz8LzhW
	 dKNtRQgNV9VTpWfnabpbQ9wYUt15wwGHMdi647I8g1GVmkGQE8I/pytUpXL2U7HlkX
	 PoGcLNT+SimnddbSUlOTxH5q/T8hcUGrGt4KOmQOg1ER8z0seV8p2APWDChbUEsBPd
	 AvYiI6A9pAy3Jfy4EAQc+v0ppjJI4jT8XCEg5+MKrFb6jYZvaRW2ymhO+7LoC/ono2
	 oajIoV0rbZtmMI6++uVRnPxs+q1r4K5HMzdETEZvV/yMsgSVwpEeUbmir+vBJUmMsX
	 XtutwrO7Dl0yA==
Message-ID: <366338ec-e4a0-7d34-7937-351605f38be7@blastwave.org>
Date: Fri, 3 Jun 2022 14:41:58 -0400
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: a small report from the Amazon AWS world
Content-Language: en-US
To: Joe Nosay 
Cc: "freebsd-arm@FreeBSD.org" 
References: 
 
From: Dennis Clarke 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LFBZd4cCJz4hwd
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=nlYE9dAZ;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-4.70 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[blastwave.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	 RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 330
Lines: 16

On 6/3/22 11:19, Joe Nosay wrote:
> https://aws.amazon.com/marketplace/pp/prodview-n65semc4zdkai
> 
> Boy, do some research
> 


     I actually have it running right now and being tested by people with
  brains and experience.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From nobody Sat Jun  4 07:36:59 2022
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 251461B517FA
	for ; Sat,  4 Jun 2022 07:37:11 +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" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFWmP39pMz3G1B
	for ; Sat,  4 Jun 2022 07:37:09 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587])
	(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id E170D8D4A2E4
	for ; Sat,  4 Jun 2022 07:37:01 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 828FFE707CF
	for ; Sat,  4 Jun 2022 07:37:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587])
	by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024)
	with ESMTP id tqekAr4QQGfu for ;
	Sat,  4 Jun 2022 07:37:00 +0000 (UTC)
Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 49F6BE707AE
	for ; Sat,  4 Jun 2022 07:37:00 +0000 (UTC)
Date: Sat, 4 Jun 2022 07:36:59 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm@FreeBSD.org
Subject: dwc0 + 18GB limit?
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-Rspamd-Queue-Id: 4LFWmP39pMz3G1B
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-2.29 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 RCVD_COUNT_FIVE(0.00)[5];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[zabbadoz.net];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	 SUBJECT_ENDS_QUESTION(1.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 456
Lines: 14

Hi,

I have a weird problem that when transfering large files (up-to 100G)
from an arm64 with dwc(4) to an amd64 VM the transfer always breaks
after 18GB (using rsync / ssh).

Given I do the same from amd64 to amd64 without issues I am wondering
if there is a lingering dwc(4) problem and before I start digging I
wonder if anyone has seen this before or can reproduce it?

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Sat Jun  4 21:49:21 2022
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 E7AAC1BE2685
	for ; Sat,  4 Jun 2022 21:52:57 +0000 (UTC)
	(envelope-from saper@saper.info)
Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "q.saper.info", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFtls2942z4lPW
	for ; Sat,  4 Jun 2022 21:52:57 +0000 (UTC)
	(envelope-from saper@saper.info)
Received: from q.saper.info (localhost [127.0.0.1])
	by q.saper.info (8.16.1/8.16.1) with ESMTPS id 254LquQq073334
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sat, 4 Jun 2022 21:52:56 GMT
	(envelope-from saper@saper.info)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014;
	t=1654379576; bh=17JdTYDeaId6UAmwg+JDUTTOLbMq053A+bHZiTju4x8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References:ReSent-Date:
	 ReSent-From:ReSent-To;
	b=MK+YDOhzI+miQfDrkIgJ7XtBGi06M0Ped2jHMTGkadClvsVphRCXsowp7s/0Vixed
	 qeqTdDqmN01ulzxup8ZZCh99FENhNyxybnCy73VmLQtfLNMq5IwUfxfj4sYlzizva3
	 8lVAzrmB4PyiNcKOWqFRmOtu0Uk86RRUDpx9ASxg=
Received: from localhost (saper@localhost)
	by q.saper.info (8.16.1/8.16.1/Submit) with ESMTP id 254Lquu2073331
	for ; Sat, 4 Jun 2022 21:52:56 GMT
	(envelope-from saper@saper.info)
X-Authentication-Warning: q.saper.info: saper owned process doing -bs
Date: Sat, 4 Jun 2022 21:49:21 +0000
From: Marcin Cieslak 
To: freebsd-arm@freebsd.org
cc: bob prohaska , Mark Millard ,
        Mark Johnston 
Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running
 -current
In-Reply-To: 
Message-ID: <99rror60-3pnn-s3q6-2q70-5ss2p968r658@fncre.vasb>
References: <20220127164512.GA51200@www.zefox.net>  
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-15; format=flowed
Content-Transfer-Encoding: 8BIT
ReSent-Date: Sat, 4 Jun 2022 21:52:49 +0000
ReSent-From: Marcin Cieslak 
ReSent-To: freebsd-arm@freebsd.org
ReSent-Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running
 -current
ReSent-Message-ID: <795s9oon-865s-54r7-no49-323s76pq3o30@fncre.vasb>
X-Rspamd-Queue-Id: 4LFtls2942z4lPW
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=saper.info header.s=Sep2014 header.b=MK+YDOhz;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of saper@saper.info has no SPF policy when checking 2605:2700:0:2:a800:ff:fec7:5c61) smtp.mailfrom=saper@saper.info
X-Spamd-Result: default: False [-2.59 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[saper.info:s=Sep2014];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 HAS_XAW(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[saper.info];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[saper.info:+];
	 NEURAL_HAM_SHORT(-0.79)[-0.792];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 CTE_CASE(0.50)[];
	 ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US];
	 FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1359
Lines: 32

On Fri, 28 Jan 2022, Mark Millard wrote:

[ Reviving old thread ]

> After that I intend runs with 30 GiBytes of swap (so RAM+SWAP 38 GiBytes).
> Hopefully that will complete and I'll be able to report how much swap was
> observed to have been used.

I thought I will get LLVM14 + OpenJDK built quickly so I fired up
a c6g.4xlarge AWS instance (16 vCPUs, 32 GB RAM),
or even c6g.8xlarge (32 vCPUs, 64 GB RAM) and even these
are unable to build llvm14 under FreeBSD 13.1-RELEASE
with poudrire enabling MAKE_JOBS for llvm build.

The build proceeds on 1 CPU only now - and casual observation
with top confirms that compilation of certain C++ files
requires 7..8 GB of RAM. If 16 of them are built concurrently,
no wonder that there is not enough memory.

Files tha crashed my compiliation:

/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Evaluate/tools.cpp
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/clang/lib/Sema/SemaOpenMP.cpp
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Semantics/check-omp-structure.cpp
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Evaluate/fold-integer.cpp

Sure, poudrire could get Kubernetes-like capabilities to control
resources during the build one day, but aren't amounts of memory
needed to build the compiler excessive a bit?

saper


From nobody Sun Jun  5 00:28:07 2022
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 6EFC71BF68D0
	for ; Sun,  5 Jun 2022 00:28:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4LFyCF0NY7z3H7b
	for ; Sun,  5 Jun 2022 00:28:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654388896; bh=YwuC9ZyixVPy+Btx7B3nruDDp6cHOzO9Ps3YvjTOJpM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=giI3DyVUGfcP2JjTyx9/2ZaODzsaBjI2Lc3oLT3Z3Enixc6YLdl/luPlTBafHisXB0GohvDk1r83aSc8oCYrMLAFjgJwJ4Nu64yRNuJKSc2BDRhOsVa0rZXuJP0/4xvrR5GIISdS7ZPLxcwaF5lGrGpoOJEOysTT7F4iNxsCSMk72hAP9Jgzh6SBM85ibZXZwtUUp522Ac1c80JfApZcitxQtnZEoy8nQMtBhQrkK3XXxgDNAeV07DgZdcA04ofOd0GbUT8E8QLY8NjhHaWSElb/3SiLSuMTHjfoALmkjxgmsF74qHALw2G3djE6798lXqfQFQguanVoQTEjcKeKQQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654388896; bh=DKRBDfdooq13AgRWM4VReoZOfhqdf/nhThdD65e5Uqw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cP8jGRDbWEOn/Xe74g2mJXnL8vdFjK23f6ZcnpefbNZuW7KSNH3LB7QfzWpqzvj3JZipcLp1huJtYXRKgp8St20iGzrLiCedZPVb/0iQhRhKyDffhCTeRapP6+qkLaKnkoKDU/+LPZWncK5dx+9Ea8FqCR6s3UY5zOv6Opgt9vHUzwwxV8fLHsx+38BB55Nq7ALu44EcDcg+0mFqqvzAiaF4OK2mNv2lfs5oIhf2vLS7n9CeEnLFVDqa+cj+ZjD74ZjlQVgmi4RuDA92EsXUKtvrO8NId+oTPdoNpzPjfVY88AYM7KKxT6ekpgjY9Z/hnJPR9WEQB0Ei3cG1LBaAgg==
X-YMail-OSG: Fn7BOdIVM1kOSLGpon.Jo7fuo3avRFdWyRZ2j_qLONLolmpeLgmdAu5QI8.g6ko
 aZ59bq3JZE5.7Nf7lgl9JHDbC9pJe8hJxZk93ielW0i4exwrSa1Hk3tDozCw3m1A_RWuQbwiNJY9
 ud2ndEI8sl6WrOpA5O5ZyJLpbd7tDBZe5YE309blt0oEhwAi.O2JVCsC5ZCaluWDqkROkjBeu0Xn
 xvT5y88QZmIZ6wtB2ePpvBJy2A0m3y0WV_zx07Y6WUwLlAg7m97cw_.vLi23yFAwQ3T6tRvuS9ZG
 s8GhIYRINYDThbGFNRKhW8Z3k3lYVGiSMxhS0gJc6wZn2VYZLWwkwz73VPTmHCQ7Ln8.j._iG8KX
 yQvoLiKoFdrXz2nNNEvVgTEuNDMc0hAVyMFaiI._44iPtCDc0odpgXa0Ra.u6uNhRVdQ5p_x6t7Y
 oxYVVsIGrfTT3kKqGHerrD3xNAAmNYH.nEAKC7x.P6TaiuuxfM3h1H3ZIpujtVfrp2UshbzOOt4E
 5TTV_nUxp8tlp8nxzXGmxd_EaksN.4hiajtnpbsOs_Pvs3ubsbDIoAtoO.VMFdIHA.yAhJ8YGogk
 oiSAERKX3e94PN8RxlCzU36aEzRN8qrdHMn7R66dU6rIHVYzenZtaKA4JxPv2cXQrduF2XzOuvNA
 LR7.5bOOoi51OotKIN1lVOVghofQsnj.tV5cyeUgLQupD7ojZPrG7tZkBeHeP0XCt7SlHPNDNy2G
 Q3OXZGPkv7H8OzE3Kf5IZawT9eKPc8_u2AaGOv0GQS6tA5W82uGcbO_h9et_4kokr1_tm04gPUo9
 f7mTNmuMjC26oY_Hi_xzSfG3_YcfSiFvunYu79yBbl7kxLS2eBIBramqokwwF7ugA35SUAyWmeCQ
 fUzWhwhHwgWNqc1Z5zwrryxWG3v7sZQ70Ig3nV_YzvEda_loRwVC4eGWcSE.Wrexd.SwkaK5Camu
 XOSbrqzFe6XvrwFnUdDUfzS6wcq.zdALcGoyvNeMiUugXMwKRQj_HSv9XIouROAWCR_WxhfCQ2Ay
 6jqjDV6OMygQfrWJCWIKcoJC1y6QUfLrOkJk75.oGEiQzO41K9UlcfG40ba8ztiHliOU_1o7uVJ2
 jBt2QJMMXhKwvysqCvgs6oVnU02L6DrZy78jCPn9q365pfa9SoPoa8BxytXsXofmgU7mxYrcJpE1
 LC3yRbzXCjtD32fejTpLebyPuc5Sm2sWxjPB4o6GvTR6sRqRXeA3nrNwa3JhG.qW9ZME0oZ5zAK1
 .Vw1Xu26LrItKsLffSWgzIAcHXGi57Xthv81yP72fXAWmX929p.xq6SJeM8CLO9.1V22BTIG330M
 9V3L4tQk40Z4gdax5b4xiDoAll9fRqwfnAaW5.eKcIyhnmnqLB2SazZqLECtDCuvJjcqB0znMbZY
 SrJYnoYp0SxzyjoxE30d18Mo429Xrkdtp9_uarnuGGHXEYUOkHtLloWOK.HQ.8XtPImobBXiYBFe
 yuitxVok1QjDsfdfuJwYc_qGqYQepwbF7yOL90v5iu5jQLk6vBwxQe9x8S5J0IvjkUbrcXWHf1jF
 S2nVcblCtAql9ibxMmgTHADaPbMvy4igct2HtEva5NOt9jok5Ck._Rho_kEblrR_8gZy_QP22XZu
 N6aSkkzf62135ETgSPu13OQX7TlWluLMCy7Qk.YzA06DshAvYZvQMTt9yVeE89.B6M_zu0loxB.R
 nZaBrnbRyDrQf49aWPqRYr7sxJlgVo0oFNuchN6UU.shsvUUIw5CUKFra2dAd4zLo_5gn6q3k4_Q
 uwHVLQCNCI6KplzFJLq4rfVwB1SlyhmJVRsXecSYFyeSFOwD.EpC3gB2ZAIi0QS1k_m18W_owXcr
 lpMrZw3HOGEDPWs9SVPNP4j98X5PCioMKH5rdOQWNai2EI4aE7pPhvMYQihbz.uF81AKDQAsq87x
 gmZ593qjdrcEjeRy1ZAAaFLGG.km8tp3W2yjgyD.IEF3Q3gUyLOFSSvIvF1wlgrhGC5PGB6rpV3p
 S7YLXNqC6szTEMFpsn.DR6H6tCvJ0B.A2zwk2neLLDLCrhSX0SVlK4hqq_ZU4g4xxv5PS7Q0V.ax
 6RoG3TwQZvHa0obSibu1tPLTgmqZTkVhz9JpJmE0Xbda2.YjFrIdv0vkIhvfPQOnNrHN6RqVDHAg
 gdzBbLfhCNQowTyPK6Iy.nlq7QgPEmyNCoqNzmrrHisexXHo8Xy2hmgm0rw4HVRZAb3wZXL2q_hk
 FM9axOwnzkIrtgxnU1dem40V3vzIs6XHdXh9AhX91bxmZodJCPFwH8cNaxl3b2TcsIfx0L6b1E4p
 ZNZyMWBWHR2jvXUCp
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Jun 2022 00:28:16 +0000
Received: by hermes--canary-production-bf1-856dbf94db-lhjkg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d4cfc0f019c7bcda5784e3a734314e0d;
          Sun, 05 Jun 2022 00:28:10 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: devel/llvm13 failed to reclaim memory on 8 GB Pi4 running
 -current
From: Mark Millard 
In-Reply-To: <99rror60-3pnn-s3q6-2q70-5ss2p968r658@fncre.vasb>
Date: Sat, 4 Jun 2022 17:28:07 -0700
Cc: Free BSD ,
 bob prohaska ,
 Mark Johnston 
Content-Transfer-Encoding: quoted-printable
Message-Id: <324C9134-542F-4954-A0E6-E75A08491A8D@yahoo.com>
References: <20220127164512.GA51200@www.zefox.net>
 
 
 <99rror60-3pnn-s3q6-2q70-5ss2p968r658@fncre.vasb>
To: Marcin Cieslak 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LFyCF0NY7z3H7b
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=giI3DyVU;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.59 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.983];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.90)[0.896];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 6164
Lines: 171

On 2022-Jun-4, at 14:49, Marcin Cieslak  wrote:

> On Fri, 28 Jan 2022, Mark Millard wrote:
>=20
> [ Reviving old thread ]
>=20
>> After that I intend runs with 30 GiBytes of swap (so RAM+SWAP 38 =
GiBytes).
>> Hopefully that will complete and I'll be able to report how much swap =
was
>> observed to have been used.
>=20
> I thought I will get LLVM14 + OpenJDK built quickly so I fired up
> a c6g.4xlarge AWS instance (16 vCPUs, 32 GB RAM),
> or even c6g.8xlarge (32 vCPUs, 64 GB RAM) and even these
> are unable to build llvm14 under FreeBSD 13.1-RELEASE
> with poudri=C3=A8re enabling MAKE_JOBS for llvm build.

It depends on the build options. Do you need fortran,
a.k.a. flang ?

Building flang requires building MLIR because building
flang uses MLIR. Without needing flang, both can normally
be turned off.

flang does not build for armv7 and other 32-bit environments,
so recently the /usr/ports/devel/llvm14/Makefile was modified
to not have flang as a default for armv7 (or armv6). My
understanding, the intent is to later also turn off MLIR
for these.

I have built devel/llvm14 with FLANG and MLIR disabled on
a 8 GiByte RPi4B in an armv7 poudriere jail. This was
as part of an ongoing "bulk -a -c" on the RPi4B. (I will
not be able to let it run to completion but am testing
how things go until I stop it.)  The below notes are
somewhat biased by my also having used BE_NATIVE for the
devel/llvm14 build:

---Begin OPTIONS List---
=3D=3D=3D> The following configuration options are available for =
llvm14-14.0.2:
    BE_AMDGPU=3Don: AMD GPU backend (required by mesa)
    BE_WASM=3Don: WebAssembly backend (required by firefox via wasi)
    CLANG=3Don: Build clang
    DOCS=3Don: Build and/or install documentation
    EXTRAS=3Don: Extra clang tools
    LIT=3Don: Install lit and FileCheck test tools
    LLD=3Don: Install lld, the LLVM linker
    LLDB=3Don: Install lldb, the LLVM debugger
    MLIR=3Doff: Multi-Level Intermediate Representation
    PYCLANG=3Don: Install python bindings to libclang
=3D=3D=3D=3D> Options available for the single BACKENDS: you have to =
select exactly one of them
    BE_FREEBSD=3Doff: Backends for FreeBSD architectures
    BE_NATIVE=3Don: Backend(s) for this architecture (ARM)
    BE_STANDARD=3Doff: All non-experimental backends
=3D=3D=3D> Use 'make config' to modify these settings
---End OPTIONS List---

The RPi4B has 4 cores and I had poudriere using 4 builders
and ALLOW_MAKE_JOBS=3D with no explicit constraint on the make
jobs per builder, so implicitly 4. Thus it can have periods
with load averages around 16 when when things do as I said
to do. (Some ports do not limit themselves to the HWthread
count.) Result:

[54:41:45] [01] [13:40:48] Finished devel/llvm14 | llvm14-14.0.2: =
Success

Note that that is with 2 GiBytes of RAM per core, the
same ratio that your report indicates.

I will also report that I used a UFS context, not ZFS,
and that my patched top indicated little swap usage
during any of my "bulk -a -c" atttempt so far. (The
top tracks and reports various MaxObs???? figures,
i.e., "Maximum Observed" figures.)

My environments do have /boot/loader.conf ,
/etc/sysctl.conf , and /usr/local/etc/poudriere.conf
settings appropriate to avoiding OOM kills for long
running [but bounded duration] build activity for the
hardware that I have access to --and that is also
part of why I prefer UFS for 2 GiBytes/HWthread for
doing builds.

(I do have access to 3 systems with 4 GiBytes
per HWthread and on 2 of them I normally use
ZFS, including for build activity.)

> The build proceeds on 1 CPU only now

Such was not true of my build reported above.
Using one core at a time, the RPi4B would have
taken much longer to do the build.

> - and casual observation
> with top confirms that compilation of certain C++ files
> requires 7..8 GB of RAM.

My understanding is that such has a known status for
flang/MLIR being in use.

> If 16 of them are built concurrently,
> no wonder that there is not enough memory.
>=20
> Files tha crashed my compiliation:
>=20
> =
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Eva=
luate/tools.cpp
> =
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/clang/lib/Sem=
a/SemaOpenMP.cpp
> =
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Sem=
antics/check-omp-structure.cpp
> =
/wrkdirs/usr/ports/devel/llvm14/work/llvm-project-14.0.4.src/flang/lib/Eva=
luate/fold-integer.cpp

You do not report the related console messages related (or
dmsg -a output or /var/log/messages content). I can think
of multiple distinct possibilities for the reports that
would have different implications. (But such need not be
of any importance for you.)

I see 3 /flang/ paths in the list of 4 paths, not surprising.

(Your /usr/ports/ context is more recent than mine.)

> Sure, poudri=C3=A8re could get Kubernetes-like capabilities to control
> resources during the build one day, but aren't amounts of memory
> needed to build the compiler excessive a bit?

"the compiler" ignores a fair mount of what is built.
Part of what I'm suggesting above is to configure
the devel/llvm14 build to build fewer compilers/toolchains
(no flang, no MLIR). You might not want, say, EXTRAS, or
some other things I have "on". BE_NATIVE may not fit
your usage context well but BE_FREEBSD could be considered.
And so on.

Hopefully my notes above are of some use unless
you are required to use the default OPTIONS.


Side note:

The RPi4B bulk actually built llvm13 and rust with
a vast part of the time frames overlapping and other
things going through the other 2 builders.

It later worked on llvm12, ghc, and suitesparse-graphblas
with the vast part of the time being overlapped. Again:
all 4 builders doing something. (suitesparse-graphblas
does not last as many hours as the other 2.)

No kernel OOM process kills. Under 300 MiByte swap used
at any point.

(ghc's haddock runs out of 32-bit process memory in
a normal core-dump way, towards the end the ghc build,
so ghc failed. But the build had been going for most
of 24 hours before that point, as had llvm12.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun  5 01:43:54 2022
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 6EAD31BD95E4
	for ; Sun,  5 Jun 2022 01:44:07 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d])
	(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 4LFztZ3mRdz3jL1
	for ; Sun,  5 Jun 2022 01:44:06 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: by mail-vs1-xe2d.google.com with SMTP id i186so10786483vsc.9
        for ; Sat, 04 Jun 2022 18:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=d2eJlD6Z6u+IjbiUrPIa6EJfWSkJ4ctycaTqzPMXikw=;
        b=MYymlQP4qGc3WT2vL7D9sDJd04NDTNd1tsy3z1Az3+fBl9a4jk9DNa0UmndMMGlv/F
         niQSNhKqynA2BCrT1JHnJp++WtmSgWUBzXE1dkscOa9rg5YbwoOGaNlkxhNBOHkliCs/
         QihgiJA6h66U6f3/qsbIBz9Td2/4lgJjE2rFYQv1/NFg8b/2UfCH7mG4npGOsgkv3/rF
         4nX2W5VnEFN8RJ/YkvNWroPlj60IFl49nrGp6LYQL88fkGhNhbhr/NSAOSqoWrKB6xUU
         6UsAZewnJgQ5qImeT03EFOxmac4xenYCdD0TFaOXM4KMKEVeJyhZNaUqaSt+K87hsT1u
         uitQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=d2eJlD6Z6u+IjbiUrPIa6EJfWSkJ4ctycaTqzPMXikw=;
        b=Uuj/VEfOvUpd+n4knJEpLw9WNZQGUJ6D5j6OJmG4kNsvt+7wBlX2AOLdt+wx0kQ1tj
         bA3YWeg2ZL3f6xURcZX8d6w89g65s0DrMCXjGCSwzoUcTHzcYn0a5Ok+dF/64lkQhN+K
         djgZerCupEvPqflBbTwRXCoEQj5noOvU7P7+ZBY32e6xqJqR3N1UAoauFyTRf6QHpxhi
         IFLRqmfR0s+pxR79PkUk7er5Hh7G78iCqUjIab4RGV3smWW5qg9rTTFwzANKq5tCMtLt
         LrhHeFJs7eUOseJ+oMwOVltD5oG22qBzx4BJ1ZLtOTiYYu67kt+HQtDyViavtOjAn/EE
         h2mA==
X-Gm-Message-State: AOAM532lXTqxfDcJ17oUdYs0hMoZXrpwoGHmkSlzEFqJzkHiy+I8PXFE
	ppuqCGVfjcQMXCJb12piE4GBVR6bFfmQKkUVJZm/LU0kL8g=
X-Google-Smtp-Source: ABdhPJzCiUw7rO5YLheBF6tVuOMRtO8N/dFS2Ir5fS9S8jhwTF18195loJkWAY1m3jrndKm8Gvnn/65Ipkg/kazDZOE=
X-Received: by 2002:a05:6102:ac5:b0:320:9281:e7c0 with SMTP id
 m5-20020a0561020ac500b003209281e7c0mr7640542vsh.26.1654393445883; Sat, 04 Jun
 2022 18:44:05 -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: 
  <366338ec-e4a0-7d34-7937-351605f38be7@blastwave.org>
In-Reply-To: <366338ec-e4a0-7d34-7937-351605f38be7@blastwave.org>
From: Joe Nosay 
Date: Sat, 4 Jun 2022 21:43:54 -0400
Message-ID: 
Subject: Re: a small report from the Amazon AWS world
To: Dennis Clarke 
Cc: "freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="000000000000a9222a05e0a97da6"
X-Rspamd-Queue-Id: 4LFztZ3mRdz3jL1
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MYymlQP4;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of superbisquit@gmail.com designates 2607:f8b0:4864:20::e2d as permitted sender) smtp.mailfrom=superbisquit@gmail.com
X-Spamd-Result: default: False [-0.57 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.999];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.43)[0.428];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 3976
Lines: 96

--000000000000a9222a05e0a97da6
Content-Type: text/plain; charset="UTF-8"

1. Each human has a single brain made up of the cerebrum, cerebellum,
brainstem and other parts.
2. No creature on this planet would have "brains" unless:
a) It has two or more heads
b) It is a siamese twin
c) It is a symbiotic relationship
3. News is information about current events also known as Journalism with
cited resources reported
from Ruters, AP, or other sources of journalistic integrity including
Academia, the political Arena, etc.

If I did not have a brain, then I would not even be able to breathe because
the brain stem is part of the brain.
Experience varies from person to person. Due to my experiences as an
individual, I interpret many responses
in their very literal value according to their most appropriate definition
of its applied and understood -by me -
use.
My interpretation nis that you are a nerd that doesn't know shit about real
life and hard times about anything
outside of having pocket protectors and a suibscription to a youtube porn
channel about BDSM midgets
doing cosplay as gay alien invaders.
You don't know shnizzle about skizzle, boyeeeee!

On Fri, Jun 3, 2022 at 2:42 PM Dennis Clarke  wrote:

> On 6/3/22 11:19, Joe Nosay wrote:
> > https://aws.amazon.com/marketplace/pp/prodview-n65semc4zdkai
> >
> > Boy, do some research
> >
>
>
>      I actually have it running right now and being tested by people with
>   brains and experience.
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
>

--000000000000a9222a05e0a97da6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


1. Each human has a single brain made up of the cerebrum, =
cerebellum, brainstem and other parts.
2. No creature on this planet wo=
uld have "brains" unless:
a) It has two or more heads
b) It is a siamese twin
c) It is a symbiotic relationshi=
p
3. News is information about current events also known as Journ=
alism with cited resources reported
from Ruters, AP, or other sou=
rces of journalistic integrity including Academia, the political Arena, etc=
.

If I did not have a brain, then I would not even=
 be able to breathe because the brain stem is part of the brain.
=
Experience varies from person to person. Due to my experiences as an indivi=
dual, I interpret many responses
in their very literal value acco=
rding to their most appropriate=C2=A0definition of its applied and understo=
od -by me -
use.=C2=A0
My interpretation nis that you a=
re a nerd that doesn't know shit about real life and hard times about a=
nything
outside of having pocket protectors and a suibscription t=
o a youtube porn channel about BDSM midgets
doing cosplay as gay =
alien invaders.
You don't know shnizzle about skizzle, boyeee=
ee!

On Fri, Jun 3, 2022 at 2:42 PM Dennis Clarke <dclarke@blastwave.org> wrote:
On 6/3/22 11:19, Joe Nosay wro=
te:

> https://aws.amazon.com/marketplace/=
pp/prodview-n65semc4zdkai

> 

> Boy, do some research

> 





=C2=A0 =C2=A0 =C2=A0I actually have it running right now and being tested b=
y people with

=C2=A0 brains and experience.





-- 

Dennis Clarke

RISC-V/SPARC/PPC/ARM/CISC

UNIX and Linux spoken

GreyBeard and suspenders optional




--000000000000a9222a05e0a97da6--

From nobody Sun Jun  5 01:47:10 2022
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 A92EA1BDA3CD
	for ; Sun,  5 Jun 2022 01:47:23 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29])
	(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 4LFzyL4Q29z3jVp
	for ; Sun,  5 Jun 2022 01:47:22 +0000 (UTC)
	(envelope-from superbisquit@gmail.com)
Received: by mail-vs1-xe29.google.com with SMTP id l13so9359355vsi.13
        for ; Sat, 04 Jun 2022 18:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=0FVXEyONkRt7PdavG+m1iLuyFFHEXc2wRpb5dtuFeXg=;
        b=lu+WptemKYrwi8LLQt8gwMAEPgGuoYe/mFFsEPP4H4FpedckGOQSZDHsDQEddguPL7
         jSdkybbjdrK57WWT79WPmKLjwftqLOYOlp21HBvOCud+kaO4Wl85pdD601Q7caHh+DRh
         SBUx74bDjCBLaR74sgh0ffIdltqYdxzC6vVEUYqUxgD4Z5xUQA00HNmihfy88Gr/9vah
         a9+ClxvnPjBAk7DXtvSlo6P6eLwmGFNZ17N6QEthab73idb6zXemHcom+fvyEJ8s+Cbj
         rBit2Lxs20hnbU7mI0YLF8Q8ItDjNs3jfvSqT7sT47yt1RA6Se+R5daJOkJDpMW0qCIm
         8AHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=0FVXEyONkRt7PdavG+m1iLuyFFHEXc2wRpb5dtuFeXg=;
        b=8H8K4tol7ZpghQvWzXQiBLlKw2rO5E4a7W2Zb6zFrkG3SZEBGSICx5wQ++n2kNL5Pm
         6O3DQaspHiwyAVfECdUwsKQOf8Sl/fks8TD99Gc4N00pMN3RK1sCXEJiUgZ8SqTcbGXg
         a3zRU6/mw0QAnEkzSsKlMtp0CEk7ZMVMx5cI4+ofREdLtOYEC2S6NeLzdRZwcdSzlUBA
         gZQQ5b0x6EBiYD2lUbWB6mK6fmYlLfo0GOipsAMWHG2YrzA8Gr7CNFbnP9jlGlSq9mRd
         umAKTGP64KWK5lKaFwhSHlGMpmvnzhsgn0bXG8VCZC+VR6iEV2hk3ql2zF1Z91NEiqB2
         BxyQ==
X-Gm-Message-State: AOAM531ZMyrwdp/AFjQPOVG2AW+uJ46X34aeYXjq0kkWigik7N5PTS44
	pCvfb59bW9bHt2YubDfwdUXNS3IZ1vn4TkVCTckUqzhPlnI=
X-Google-Smtp-Source: ABdhPJxcZrNFbBi1+S2BRLtgNzsmp3WaH7Sh2kZ49UAE1WPK/8uP4QUxYCCtL5yLT43wNNbj7lvWWvPti6OUKFIIqZ4=
X-Received: by 2002:a67:ea85:0:b0:34b:912f:2c66 with SMTP id
 f5-20020a67ea85000000b0034b912f2c66mr5656036vso.42.1654393641658; Sat, 04 Jun
 2022 18:47:21 -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: 
 
 <366338ec-e4a0-7d34-7937-351605f38be7@blastwave.org> 
In-Reply-To: 
From: Joe Nosay 
Date: Sat, 4 Jun 2022 21:47:10 -0400
Message-ID: 
Subject: Re: a small report from the Amazon AWS world
To: Dennis Clarke 
Cc: "freebsd-arm@FreeBSD.org" 
Content-Type: multipart/alternative; boundary="000000000000546fcd05e0a98907"
X-Rspamd-Queue-Id: 4LFzyL4Q29z3jVp
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=lu+Wptem;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of superbisquit@gmail.com designates 2607:f8b0:4864:20::e29 as permitted sender) smtp.mailfrom=superbisquit@gmail.com
X-Spamd-Result: default: False [-0.68 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.999];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 NEURAL_SPAM_MEDIUM(0.32)[0.324];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 4775
Lines: 112

--000000000000546fcd05e0a98907
Content-Type: text/plain; charset="UTF-8"

Let me correct my spelling mistakes, Einstein.
Is not nis.
Subscription not suibscription.
Reuters not Ruters.

On Sat, Jun 4, 2022 at 9:43 PM Joe Nosay  wrote:

> 1. Each human has a single brain made up of the cerebrum, cerebellum,
> brainstem and other parts.
> 2. No creature on this planet would have "brains" unless:
> a) It has two or more heads
> b) It is a siamese twin
> c) It is a symbiotic relationship
> 3. News is information about current events also known as Journalism with
> cited resources reported
> from Ruters, AP, or other sources of journalistic integrity including
> Academia, the political Arena, etc.
>
> If I did not have a brain, then I would not even be able to breathe
> because the brain stem is part of the brain.
> Experience varies from person to person. Due to my experiences as an
> individual, I interpret many responses
> in their very literal value according to their most appropriate definition
> of its applied and understood -by me -
> use.
> My interpretation nis that you are a nerd that doesn't know shit about
> real life and hard times about anything
> outside of having pocket protectors and a suibscription to a youtube porn
> channel about BDSM midgets
> doing cosplay as gay alien invaders.
> You don't know shnizzle about skizzle, boyeeeee!
>
> On Fri, Jun 3, 2022 at 2:42 PM Dennis Clarke 
> wrote:
>
>> On 6/3/22 11:19, Joe Nosay wrote:
>> > https://aws.amazon.com/marketplace/pp/prodview-n65semc4zdkai
>> >
>> > Boy, do some research
>> >
>>
>>
>>      I actually have it running right now and being tested by people with
>>   brains and experience.
>>
>>
>> --
>> Dennis Clarke
>> RISC-V/SPARC/PPC/ARM/CISC
>> UNIX and Linux spoken
>> GreyBeard and suspenders optional
>>
>

--000000000000546fcd05e0a98907
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Let me correct my spelling mistakes, Einstein.
Is not =
nis.
Subscription not suibscription.
Reuters not Ruters=
.

On Sat, Jun 4, 2022 at 9:43 PM Joe Nosay <superbisquit@gmail.com> wrote:
1. Each human has=
 a single brain made up of the cerebrum, cerebellum, brainstem and other pa=
rts.
2. No creature on this planet would have "brains" unless=
:
a) It has two or more heads
b) It is a siamese twin
c) It is a symbiotic relationship
3. News is information=
 about current events also known as Journalism with cited resources reporte=
d
from Ruters, AP, or other sources of journalistic integrity inc=
luding Academia, the political Arena, etc.

If I di=
d not have a brain, then I would not even be able to breathe because the br=
ain stem is part of the brain.
Experience varies from person to p=
erson. Due to my experiences as an individual, I interpret many responses
in their very literal value according to their most appropriate=C2=
=A0definition of its applied and understood -by me -
use.=C2=A0
My interpretation nis that you are a nerd that doesn't know sh=
it about real life and hard times about anything
outside of havin=
g pocket protectors and a suibscription to a youtube porn channel about BDS=
M midgets
doing cosplay as gay alien invaders.
You don&=
#39;t know shnizzle about skizzle, boyeeeee!

On Fri, Jun 3, 2022 at 2:=
42 PM Dennis Clarke <dclarke@blastwave.org> wrote:
On 6/3/22 11:19, Joe Nosay wrote:

> https://aws.amazon.com/marketplace/=
pp/prodview-n65semc4zdkai

> 

> Boy, do some research

> 





=C2=A0 =C2=A0 =C2=A0I actually have it running right now and being tested b=
y people with

=C2=A0 brains and experience.





-- 

Dennis Clarke

RISC-V/SPARC/PPC/ARM/CISC

UNIX and Linux spoken

GreyBeard and suspenders optional






--000000000000546fcd05e0a98907--

From nobody Sun Jun  5 05:19:16 2022
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 EED7F1BD4893
	for ; Sun,  5 Jun 2022 05:20:03 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LG4gk08WLz4SW9
	for ; Sun,  5 Jun 2022 05:20:00 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-4.432, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.32,
	T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 2555JHkY030871
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [10.14.0.7] (static-198-54-132-75.cust.tzulo.com [198.54.132.75])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 2555JHkY030871
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
	for ; Sun, 5 Jun 2022 01:19:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1654406358;
	bh=8FprLPphUuFnj0uJ4diF3upSo9SjcQUzlLRGGhxIHfo=;
	h=Date:Subject:To:References:From:In-Reply-To:From;
	b=dsqXXNZUtRh/4HvViI5WaJtRV3/50/NichUKbnUoL5OrejBrASBhQqos3A7/qDtOX
	 r+ckhjwSJwsX6EqxAKdQcYtOrL7hI8hMO0N5cF00J3qHVfn5TcwTBzKYI1EpYdSF6k
	 dFXtt11j1ODmIqaelA+PKx/pCzWNek8ciFS7GdcCiZFTMwYVHPkIixSn6vJxkCqR/V
	 Ht67OK3lY515bmviV2znGvxRncb8B4IPCyUu9iA3atBHZ85Iyzk+5jD7kT7tF3ahR2
	 KISLt+wENLIiU39dBcRbIJIfr5oRvhY7UCzA/6ovzeSI0o2g9M0tBJE/2GhI6YRXql
	 7+MhccOsY1uoQ==
Message-ID: <1d18c6cb-413b-f3ef-6117-b505776144f4@blastwave.org>
Date: Sun, 5 Jun 2022 01:19:16 -0400
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: a small report from the Amazon AWS world
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 
 <366338ec-e4a0-7d34-7937-351605f38be7@blastwave.org>
 
From: Dennis Clarke 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LG4gk08WLz4SW9
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=dsqXXNZU;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-4.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[blastwave.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	 RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-0.80)[-0.795];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 82
Lines: 6

On 6/4/22 21:43, Joe Nosay wrote:

Someone ban that idiot ... please.

-- 
Dennis

From nobody Sun Jun  5 11:18:57 2022
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 5BC4E1BEAA0E
	for ; Sun,  5 Jun 2022 11:19:05 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c])
	(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 4LGDdy6tXGz3Pcr
	for ; Sun,  5 Jun 2022 11:19:02 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-fb1ae0cd9cso5461201fac.13
        for ; Sun, 05 Jun 2022 04:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=message-id:date:mime-version:user-agent:from:subject:to:cc
         :references:content-language:in-reply-to;
        bh=OAD90SpbXjOV3K56hXRlQPwYUNyhOiyRbMwzXcHmU7M=;
        b=P/S0ZenphVXqYElJGkSBBVgSd5pmnWTh2u5E73+O1O7vZw32HYe586TyfWx+GlzPe3
         fhYabLRdxbQ68ZwxuaEytHrr589rmNuVrQ6q2WW2G/Bc2ZXyaG4wUcCwVDY9CPGIaZl6
         /zWCVNSqi00AUGHRL9xvfPQcMVt9XW4lzL/sY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:from
         :subject:to:cc:references:content-language:in-reply-to;
        bh=OAD90SpbXjOV3K56hXRlQPwYUNyhOiyRbMwzXcHmU7M=;
        b=oyM5oEjX6p6iQ+sRPNBq+w6Kkp8ixuQSXLW2pf5Du+BG02EFXYiFbilHzI1828ybgx
         fDRL1r1xlytyF4zinmsoe36Zm404j8dKETTy/W5ynSWiYkORzsWVhwb0Tsuw7auvqVxi
         L/TXfgZ86yWYaEbID1k1U4Eca2s1k0DxHH5rua2JvZpMy2TBm29OMM7gAA2z6QwBIToU
         96sCx66zRCx/zeX+wtN7dA0HpwiOtCoH2ap5M/NQQYY/UlDc9tcseaLKMiVY1y80vfOQ
         29DVXho8X1vyc+iIMSWjVna/us6CFiKn8krKzGSZ5SUNYnEuWwXb1UJyy3XEQq4rKABw
         nouA==
X-Gm-Message-State: AOAM533swgw/l7IBYszJNjbr7oBc6myAtzrW3/Bho/bwOplmR0t7cOr1
	X18PlRX0mxN4cpGwRxNizh3tXC2zxVgvaQ==
X-Google-Smtp-Source: ABdhPJzk95HGhgaA5t62L+4YlBAQHPax467lmmua7Yr0qvQZvK7h6LT329rTjvpCfleT9Z48KOIiHg==
X-Received: by 2002:a05:6870:42c4:b0:f1:7bfd:b67c with SMTP id z4-20020a05687042c400b000f17bfdb67cmr10610101oah.177.1654427941884;
        Sun, 05 Jun 2022 04:19:01 -0700 (PDT)
Received: from ?IPV6:2804:29b8:5099:52c:378e:75f1:1e7e:4f18? ([2804:29b8:5099:52c:378e:75f1:1e7e:4f18])
        by smtp.gmail.com with ESMTPSA id m11-20020a4aedcb000000b00415a9971cfcsm6451482ooh.38.2022.06.05.04.19.00
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 05 Jun 2022 04:19:01 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------llpUrx2WEDPX6MwXfCsoCfr0"
Message-ID: 
Date: Sun, 5 Jun 2022 08:18:57 -0300
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
From: Otacilio 
Subject: Re: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
References: <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
 <1047394639.643.1654181685742@localhost>
Content-Language: en-US
In-Reply-To: <1047394639.643.1654181685742@localhost>
X-Rspamd-Queue-Id: 4LGDdy6tXGz3Pcr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b="P/S0Zenp";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of otacilio.neto@bsd.com.br designates 2001:4860:4864:20::2c as permitted sender) smtp.mailfrom=otacilio.neto@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsd.com.br];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsd.com.br:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2c:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 10738
Lines: 290

This is a multi-part message in MIME format.
--------------llpUrx2WEDPX6MwXfCsoCfr0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

After some debug I found that this routine is returning -1:

vi +50 /usr/src/sys/dev/psci/psci.h

/* Handler to let us call into the PSCI/SMCCC firmware */
extern psci_callfn_t psci_callfn;
static inline int
psci_call(register_t a, register_t b, register_t c, register_t d)
{

         return (psci_callfn(a, b, c, d, 0, 0, 0, 0, NULL));
}

/*
  * PSCI return codes.
  */
#define PSCI_RETVAL_SUCCESS             0
#define PSCI_RETVAL_NOT_SUPPORTED       -1
#define PSCI_RETVAL_INVALID_PARAMS      -2

Someone can give-me a hint about the function of psci_callfn ?

Thanks a lot


Em 02/06/2022 11:54, Ronald Klop escreveu:
> No solution, just a data point. My RPI3B+ works fine.
>
> $ cat /var/run/dmesg.boot  | grep CPU
> Starting CPU 1 (1)
> Starting CPU 2 (2)
> Starting CPU 3 (3)
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> bcm2835_cpufreq0:  on cpu0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> armv8crypto0: CPU lacks AES instructions
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
> CPU  2: ARM Cortex-A53 r0p4 affinity:  2
> CPU  3: ARM Cortex-A53 r0p4 affinity:  3
>
> $ uname -a
> FreeBSD rpi3 13.1-RELEASE FreeBSD 13.1-RELEASE 
> releng/13.1-n250148-fc952ac2212 GENERIC arm64
>
> $ sysctl hw.model
> hw.model: ARM Cortex-A53 r0p4
>
> # ofwdump -a -P model  | head -n5
> Node 0x48:
>   model:
>     52 61 73 70 62 65 72 72 79 20 50 69 20 33 20 4d 6f 64 65 6c
>     20 42 20 50 6c 75 73 20 52 65 76 20 31 2e 33 00
>     'Raspberry Pi 3 Model B Plus Rev 1.3'
>
> I don't know how to help further, but maybe this gives a difference to 
> dive into.
>
> Regards,
> Ronald.
>
> *Van:* Otacilio 
> *Datum:* donderdag, 2 juni 2022 14:04
> *Aan:* freebsd-arm@freebsd.org
> *Onderwerp:* Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
>
>     Dears
>
>
>     Yesterday I have finished a upgrade from source code of a FreeBSD
>     12.2 to FreeBSD 13.1 running on RPI3. After upgrade, this machine
>     only one CPU is detected.
>
>     RPI3 with problem
>
>     [ota@azul ~]$ cat /var/run/dmesg.boot  | grep CPU
>     Starting CPU 1 (1)
>     Starting CPU 1 (2)
>     Starting CPU 1 (3)
>     FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs
>     cpulist0:  on ofwbus0
>     cpu0:  on cpulist0
>     bcm2835_cpufreq0:  on cpu0
>     cpu1:  on cpulist0
>     cpu2:  on cpulist0
>     cpu3:  on cpulist0
>     armv8crypto0: CPU lacks AES instructions
>     CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>     [ota@azul ~]$ uname -a
>     FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE
>     releng/13.1-n250148-fc952ac2212 GENERIC arm64
>
>     Another system running on a rpi4 the CPUs detected and initialized
>     are ok:
>
>     RPI4 running OK
>
>     [ota@verde ~]$ cat /var/run/dmesg.boot  | grep CPU
>     Starting CPU 1 (1)
>     Starting CPU 2 (2)
>     Starting CPU 3 (3)
>     FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>     cpulist0:  on ofwbus0
>     cpu0:  on cpulist0
>     bcm2835_cpufreq0:  on cpu0
>     cpu1:  on cpulist0
>     cpu2:  on cpulist0
>     cpu3:  on cpulist0
>     armv8crypto0: CPU lacks AES instructions
>     CPU  0: ARM Cortex-A72 r0p3 affinity:  0
>     CPU  1: ARM Cortex-A72 r0p3 affinity:  1
>     CPU  2: ARM Cortex-A72 r0p3 affinity:  2
>     CPU  3: ARM Cortex-A72 r0p3 affinity:  3
>     [ota@verde ~]$ uname -a
>     FreeBSD verde 13.1-RELEASE FreeBSD 13.1-RELEASE
>     releng/13.1-n250148-fc952ac2212 GENERIC arm64
>
>
>     Someone can give-me a hint about how to solve this?
>
>
>     Thanks a lot
>
>     ------------------------------------------------------------------------
>
--------------llpUrx2WEDPX6MwXfCsoCfr0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
After some debug I found that this routine is returning -1:

    

    
vi +50 /usr/src/sys/dev/psci/psci.h

    
/* Handler to let us call into the PSCI/SMCCC firmware */

      extern psci_callfn_t psci_callfn;

      static inline int

      psci_call(register_t a, register_t b, register_t c, register_t d)

      {

      

              return (psci_callfn(a, b, c, d, 0, 0, 0, 0, NULL));

      }

      

      /*

       * PSCI return codes.

       */

      #define PSCI_RETVAL_SUCCESS             0

      #define PSCI_RETVAL_NOT_SUPPORTED       -1

      #define PSCI_RETVAL_INVALID_PARAMS      -2

    

    
Someone can give-me a hint about the function of psci_callfn ?

    
Thanks a lot

    

    


    

    
Em 02/06/2022 11:54, Ronald Klop
      escreveu:

    

    

      
      No solution, just a data point. My RPI3B+ works fine.

      

      $ cat /var/run/dmesg.boot  | grep CPU

      Starting CPU 1 (1)

      Starting CPU 2 (2)

      Starting CPU 3 (3)

      FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

      cpulist0: <Open Firmware CPU Group> on ofwbus0

      cpu0: <Open Firmware CPU> on cpulist0

      bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

      cpu1: <Open Firmware CPU> on cpulist0

      cpu2: <Open Firmware CPU> on cpulist0

      cpu3: <Open Firmware CPU> on cpulist0

      armv8crypto0: CPU lacks AES instructions

      CPU  0: ARM Cortex-A53 r0p4 affinity:  0

      CPU  1: ARM Cortex-A53 r0p4 affinity:  1

      CPU  2: ARM Cortex-A53 r0p4 affinity:  2

      CPU  3: ARM Cortex-A53 r0p4 affinity:  3

      

      $ uname -a

      FreeBSD rpi3 13.1-RELEASE FreeBSD 13.1-RELEASE
      releng/13.1-n250148-fc952ac2212 GENERIC arm64

      

      $ sysctl hw.model

      hw.model: ARM Cortex-A53 r0p4

      

      # ofwdump -a -P model  | head -n5

      Node 0x48:

        model:

          52 61 73 70 62 65 72 72 79 20 50 69 20 33 20 4d 6f 64 65 6c

          20 42 20 50 6c 75 73 20 52 65 76 20 31 2e 33 00

          'Raspberry Pi 3 Model B Plus Rev 1.3'

      

      I don't know how to help further, but maybe this gives a
      difference to dive into.

      

      Regards,

      Ronald.

      

       
      
Van: Otacilio <otacilio.neto@bsd.com.br>

        Datum: donderdag, 2 juni 2022 14:04

        Aan: freebsd-arm@freebsd.org

        Onderwerp: Wrong number of CPUs detected on
        RPI3 and FreeBSD 13.1

      

        

          
Dears

            

            

            Yesterday I have finished a upgrade from source code of a
            FreeBSD 12.2 to FreeBSD 13.1 running on RPI3. After upgrade,
            this machine only one CPU is detected.

            

            RPI3 with problem

            

            [ota@azul ~]$ cat /var/run/dmesg.boot  | grep CPU

            Starting CPU 1 (1)

            Starting CPU 1 (2)

            Starting CPU 1 (3)

            FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs

            cpulist0: <Open Firmware CPU Group> on ofwbus0

            cpu0: <Open Firmware CPU> on cpulist0

            bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

            cpu1: <Open Firmware CPU> on cpulist0

            cpu2: <Open Firmware CPU> on cpulist0

            cpu3: <Open Firmware CPU> on cpulist0

            armv8crypto0: CPU lacks AES instructions

            CPU  0: ARM Cortex-A53 r0p4 affinity:  0

            [ota@azul ~]$ uname -a

            FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE
            releng/13.1-n250148-fc952ac2212 GENERIC arm64

            

            Another system running on a rpi4 the CPUs detected and
            initialized are ok:

            

            RPI4 running OK

            

            [ota@verde ~]$ cat /var/run/dmesg.boot  | grep CPU

            Starting CPU 1 (1)

            Starting CPU 2 (2)

            Starting CPU 3 (3)

            FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

            cpulist0: <Open Firmware CPU Group> on ofwbus0

            cpu0: <Open Firmware CPU> on cpulist0

            bcm2835_cpufreq0: <CPU Frequency Control> on cpu0

            cpu1: <Open Firmware CPU> on cpulist0

            cpu2: <Open Firmware CPU> on cpulist0

            cpu3: <Open Firmware CPU> on cpulist0

            armv8crypto0: CPU lacks AES instructions

            CPU  0: ARM Cortex-A72 r0p3 affinity:  0

            CPU  1: ARM Cortex-A72 r0p3 affinity:  1

            CPU  2: ARM Cortex-A72 r0p3 affinity:  2

            CPU  3: ARM Cortex-A72 r0p3 affinity:  3

            [ota@verde ~]$ uname -a

            FreeBSD verde 13.1-RELEASE FreeBSD 13.1-RELEASE
            releng/13.1-n250148-fc952ac2212 GENERIC arm64

            

            

            Someone can give-me a hint about how to solve this?

            

            

            Thanks a lot

            

             

          

      

    

  


--------------llpUrx2WEDPX6MwXfCsoCfr0--

From nobody Sun Jun  5 17:31:46 2022
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 247911BE4B33
	for ; Sun,  5 Jun 2022 17:31:57 +0000 (UTC)
	(envelope-from greg@unrelenting.technology)
Received: from out1.migadu.com (out1.migadu.com [91.121.223.63])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGNwC11vFz4tNc
	for ; Sun,  5 Jun 2022 17:31:54 +0000 (UTC)
	(envelope-from greg@unrelenting.technology)
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology;
	s=key1; t=1654450306;
	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=LHJjfVkjcFTRJvioQzyvkfOikXbND+BRECEkRpBfnOM=;
	b=ZjLCtg2cJM0JtWhP6jU5X0lU+Uabzyb2TW5nT2x26SRYK2SJgsjzPqn2/zNN8puomSpzzE
	ghmz6sAbtTHY2ze0yysBBws1wdcpm5CWjhU+pZvDb+HtFVahOYJ4KItNKKVJFcSHE63AGX
	pS23izeg+0SFn17jgLKas7OrwIpwgmWKf9EQ8N4EK81jsY+CwZY45rvEmgUZES107/WKbo
	QVnpyhdehW0rC9IV9kaxOWkjOFyJ//j7HcF2oiyNNM6x/fbetNn/aUA0iSdBGYS2lWy14O
	w7B9UclQSd3JAQe9a7/4GNwkcajLL79n9b7O3oHqpkGAV6OmsChGIliUKdS3AA==
Date: Sun, 05 Jun 2022 17:31:46 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: greg@unrelenting.technology
Message-ID: 
Subject: Re: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
To: "Otacilio" , "Ronald Klop"
 
Cc: freebsd-arm@freebsd.org
In-Reply-To: 
References: 
 <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
 <1047394639.643.1654181685742@localhost>
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: unrelenting.technology
X-Rspamd-Queue-Id: 4LGNwC11vFz4tNc
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=unrelenting.technology header.s=key1 header.b=ZjLCtg2c;
	dmarc=pass (policy=quarantine) header.from=unrelenting.technology;
	spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology
X-Spamd-Result: default: False [-4.10 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=key1];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[unrelenting.technology:+];
	 DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,quarantine];
	 FROM_NO_DN(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[91.121.223.63:from]
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 664
Lines: 9

June 5, 2022 2:18 PM, "Otacilio"  wrote:=0A=0A>=
 After some debug I found that this routine is returning -1:=0A> =0A> Som=
eone can give-me a hint about the function of psci_callfn ?=0A=0APSCI is =
an interface for calling into power management firmware.=0AJust saying th=
at *a* PSCI call failed is not informative, we really need the arguments =
of the call.=0A=0AI'm not sure what firmware you have on the SD card but =
armstub8 from=0Ahttps://github.com/gonzoua/rpi3-psci-monitor should suppo=
rt:=0APSCI_VERSION, PSCI_CPU_ON, PSCI_SYSTEM_OFF, and PSCI_SYSTEM_RESET.=
=0AWhich should be all the calls that FreeBSD ever does=E2=80=A6

From nobody Sun Jun  5 21:00:55 2022
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 175DD1BDE58B
	for ; Sun,  5 Jun 2022 21:00:57 +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 4LGTYM75Nlz3pQy
	for ; Sun,  5 Jun 2022 21:00:55 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 AAA1C19410
	for ; Sun,  5 Jun 2022 21:00:55 +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 255L0thp032395
	for ; Sun, 5 Jun 2022 21:00:55 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 255L0tTf032394
	for freebsd-arm@FreeBSD.org; Sun, 5 Jun 2022 21:00:55 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202206052100.255L0tTf032394@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, 5 Jun 2022 21:00:55 +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="16544628559.06c9.29247"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654462856;
	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=n60kdynJVYb4GbQV11DgrPEcy/uW6amYwupbv4U/AP4=;
	b=lAxCM7rHcuC8w5NPlXy8TgYGe37ll4F/PXIIuI0zV7K4wyAvLXxG3HYK8o3ClO4qhUZwgO
	HidY5PWPz9zCh4PWTioMIxyTVTOkUVloOtPycP7CcBce9lN3ZGVGH9uHbTB0TTPd/My+2J
	RSXBpC0sMahMlUf/Bqa9ZYwULZeLra1lnq7IV2XunBb7lVQB4DQmgQ5fBNBKVMEOFKeRF/
	2dN5XBMHTEJUwHheu9Ra7lq5QAMcv7tyry+PEdMweAFfGAWFFGjNgoqxHqZVZXvHU0qQcp
	I0/mmtXp217M/OyjQ3Nk0+9SloCmqsanSVTyMiTppIjbTfkQO8K8IvwjWTUxCQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654462856; a=rsa-sha256; cv=none;
	b=xGOiOJVCel4WMZwZU48GRLcr/qnm0HESHmTCNIQ6v3hSQo4UoR5ZvBVe5ZFVJQ1H+S9RLx
	+gWaoLJMGOjZyoyJlmLT4pGPxf+guNmFRFCidxT3ei/NmW7cWuXgK7lJsWGcfLN8ylKu6G
	ENH6eV9/nribVaJtPZ4McJl6FYtH0avbzRM0dji7w8bwCOdvaaRQmQW1LbH7ZhG/B4fozA
	WFTySxmqEjIdez2jPRLmNlimSry2bY8sJVWelQNri4h7CuY82QwRyjTvy2EV75yKpgvd1Z
	MvVGfyfjI3hEww7H7enJxvezX+4jgmk5+qFl001oCk81Wf0FABi2tRHwW48ogw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
Status: O
Content-Length: 1793
Lines: 38


--16544628559.06c9.29247
Date: Sun, 5 Jun 2022 21:00:55 +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.

--16544628559.06c9.29247
Date: Sun, 5 Jun 2022 21:00:55 +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.


--16544628559.06c9.29247--

From nobody Tue Jun  7 08:23:00 2022
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 A5AF31BE4054
	for ; Tue,  7 Jun 2022 08:23:12 +0000 (UTC)
	(envelope-from chris@chrullrich.net)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2069.outbound.protection.outlook.com [40.107.21.69])
	(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 4LHNf73Zvpz4VpS
	for ; Tue,  7 Jun 2022 08:23:11 +0000 (UTC)
	(envelope-from chris@chrullrich.net)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=afS7xcHqKziaTp+2j5nCu3L5SYzEOxl3e6Dcex52X7tRf9Oy4tS2+lkK2NcU86JvliRXbVwiZZOTNVMicGcwvRd+8IDy+mV8BaKHl7/Dcvy/f0xjS3+7aLcy+SaZpxRAupSbBUNj/N7cT5FIp4wmXH8whfOIhLDh9TfqeaSGrfE6cUYY6joLwIA6tBi3vPP87ebW22eJ3AfAacYpL0Zv+bf0Roxwn5UT4d31Q8Br5uQSTcmOajjpH2we5M3sZsqci0+02/Gv3/ufjmQsBHWThW/qLyrDhzMPt2ke4MZzRTjkkMRU5kpHc/j0H2PALCVNsphlFoNJFuiUaVQgAEW2eg==
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=L3dhklamUaTXH70MDb/5e8W44R3OPNZiDqMFJbd8uZ0=;
 b=DbkKN69Vpglvble/3u0d3PbcQOLGtZJ8nAueaxmf2/hRvS5Yqcc0lYrFPd0YrUkb6OZGgLB6MdrlZMIXAzMaE4t9IbHq0UImSZbRx0jcgeE1hqb9O9/90FSUxULNr/CGsoUOMSfAIvgWZ0EO7VXxvBRzZGk69hqqJATSMbMddpM17GFWIL4ws9Qmclalh9U4UVff3DwuYpl3rJpkAd1StGuZP621FftJfT2zLKF55xbtLjkBUH+EHMl+FQfwqZDVxVDEtbfI2iM+12hKWp/8wb4CAv7ykan+Qu2E95nQpqoOYGNetYR9Lr09uf1kMnN4NiJswniHgBlh2KmJw16NbQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=chrullrich.net; dmarc=pass action=none
 header.from=chrullrich.net; dkim=pass header.d=chrullrich.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gloomberg.onmicrosoft.com; s=selector2-gloomberg-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=L3dhklamUaTXH70MDb/5e8W44R3OPNZiDqMFJbd8uZ0=;
 b=UVEwzjICxT95hi3XdOf9XC0WTKw+qwz2At8R7pRDsxOHWXmjaHEyfXx6h/AcPZmDsc4BHVOJCcgClDFiXcgZgP36IcCzNmj4lBSRZ1PoRHEtyqi7tOk8yIDmhubnujojY4JF1ku2MErszWKOEwyVZIYv1tVO8ddXlOwTAxENJfc=
Received: from VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:12d::15)
 by AS1PR10MB5579.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:477::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.19; Tue, 7 Jun
 2022 08:23:00 +0000
Received: from VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
 ([fe80::d0b:36ae:fd87:4a30]) by VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
 ([fe80::d0b:36ae:fd87:4a30%4]) with mapi id 15.20.5314.019; Tue, 7 Jun 2022
 08:23:00 +0000
From: Christian Ullrich 
To: "freebsd-arm@freebsd.org" 
Subject: Re: aarch64 and kqueue timer events
Thread-Topic: aarch64 and kqueue timer events
Thread-Index: AQHYekfMvjAIJfwg2UeUpSRQd3P3cA==
Date: Tue, 7 Jun 2022 08:23:00 +0000
Message-ID: <303b3e3a-7856-afdd-dd0b-9fd0d486215f@chrullrich.net>
References: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net>
 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 268408c6-6a0d-41e9-9b46-08da485eef66
x-ms-traffictypediagnostic: AS1PR10MB5579:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 8TPReHujWH1gulYApo+SjHwT0rYSga86sGwbd0kEGRt5H3Q4yt10TtmtH9if+z8nr83LiuuQjRMaV/FdjmVRKcYy9DPamSc8qhTefmJUhTK2JuIA/E0M3z2R/HRg02zaIUfaD+5ScLTGefA3Aqcc0ofSNN+42GxXTsb7+X7oF75eJDrK72HrF9lsNr+LLoZkRWpODP3vz0agJ1q32IE8sThIBM16n4fvK0wuNfgEyDirekOQ4JA3aOUyDfkYcffRFNA16T4zmgeoO0SsgKRKK+Zun1d9WgQvGnSeppy+rCMSogpKAtpl0ga1rXe5d7t5oiEsEepEa5onX/AIj8A6UtRCYyfXCsWu/JvfMWUbl/egY6E1/GPhhSEUY9TEhhNlPiPaa5iPGABo6WEc86hU/T2jkBYDgxWIQ7ZEggDIob5QOEZJUe3LQcOb9ZzXvG2wPHWHGFLQ/INVb2M0Z3a+8rEJBiWyP2ipOVfRLv3qYJMYh1vKmaKNicej8OFwuhESzYefQ+VmRRt8YPJXNKz9ySnx920jvWYKZ8n/FjEGAM56aSgIT9R0tzCelP2ytKGjsIDM1BXhmvQCifkY2usKgfEB9uJz6N9XVQIiFCsUCP9t+p7PFEY7igLumrFmVSDoFDU+SSWYsFzeHl68cpjTxMhX6nX8DHbMmQZ6wAeMev9n8U1TZ4GcQ6fuCWEXVYPEkszwAei7RDerFPWzEnNsduJv1oIYtrAcCwh5ZAVe4DIjjUfggXaelHpCdziyW0Z1psMkmiEzqNauTdO5iHaafg==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(346002)(396003)(136003)(39830400003)(36756003)(316002)(71200400001)(122000001)(8676002)(66446008)(38070700005)(4744005)(31696002)(2906002)(5660300002)(76116006)(91956017)(8936002)(66476007)(66556008)(6512007)(86362001)(2616005)(26005)(66946007)(508600001)(186003)(53546011)(38100700002)(6486002)(41300700001)(6506007)(64756008)(6916009)(83380400001)(31686004)(45980500001)(43740500002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UkZHUHVwNDErMldBZjdCc3QwaU5Fa2Q0bUdVT0IzSmxTMlFhOUR4b1J2THBo?=
 =?utf-8?B?QkkrK2dQMC90b0VVaTVqdkJHaVM2QURHVzJzenhJNlRGSDAvc241RlliMTBm?=
 =?utf-8?B?K3pHSjVDd1lrelhRYm00K3U3Q0pYWHFRb1M3bWNGVFVxbUNpNjYvYWVCTmI3?=
 =?utf-8?B?NWFrNWxwQ1l4OWJPMDIxQW9mMlZFeDhNa0s4blVqVUd3UGoxSTNyZW1yZ3pJ?=
 =?utf-8?B?MU5tY04zY2ZnMmx0cU9vSm9vdG84Q0xET1NKbUNiWlJMcTJTVUVGKy81L3RB?=
 =?utf-8?B?T2pJU0NhT1d3MHNXaitBNEFuZTcxcDIvNWpiekh4cUo4ZHc0L20ydWEwNkha?=
 =?utf-8?B?dEtGbjVjbzdFcmN3RzJwYTEwRVplUnBZTFhFYkNPbkN5ZVNFbEVBT1FVN3hL?=
 =?utf-8?B?VnJUbVh2T1RjMDRRSkNsaXdndXlGOTRqVm95bjdrekpQSHJHdGY1VExMOHY2?=
 =?utf-8?B?cDBOc2hiUU8rMDkvZndwNUVNRXpYUG1qUzFqdkR3bEZBSFAvaGNIWTYyRWJB?=
 =?utf-8?B?TWM2azRHcnFEaHIxWC9qWEdPdnFTYnZZZkVCN1VOQmJka0VMN1lFZjRsRG5W?=
 =?utf-8?B?blRIS0ZnTkVxMnBQaCtVTzRmRTZWZWNzb3ZmSTQyK2NqKzZsS0ptY1lPNnVL?=
 =?utf-8?B?TlJjL1JUZVpPOWNQT21sMzMvMGhqSVhSeUtQWGtreTJqNVRySklORENPUlNM?=
 =?utf-8?B?ejcwVERTNk5QNDVKMTJrS3dhOTBrYXQybkpBUmd6dW9Ubm9zbW12aWR5WjVi?=
 =?utf-8?B?K3dXN25IcXpmNFRheTZ4TGlpNVN4UnRkbUkvOFFPbTZXbDRwS0t2bVppRTkw?=
 =?utf-8?B?NWV6RXQyVGlPK1ROeGt1NGRJYmpSTjJ2eUdzSG5heDNoZnNob2xwUzhRS0Vq?=
 =?utf-8?B?a21DY3U3amx3NWdvZWhtc1FhMHM4cEo3OUlXUklCTUtMWHJodEdnblVrWjNV?=
 =?utf-8?B?blc4L0NEeE9vVUZ4bTBiM2ZSQlJ4VVdqWTdGMFV4aUxYUnI1Z3ZWNE9oSEdB?=
 =?utf-8?B?amcrVE5sWXZ3UFd0VTV3aWxzazV6cldhbDRwUlVrQUwwK1BaOFB4NEpZR0FH?=
 =?utf-8?B?NlZDV1BuMCtTZ3R0VmErQkpEWWV3RmNjZVVQQTI2RVlQWWNwQkZsWGRBR2h6?=
 =?utf-8?B?S2NjM3haZSt2a1NFWjBEYit5Z3RzQVV5V1JxSlk1ZjMySkk4MkFLZWc1cVV4?=
 =?utf-8?B?SkhuVVpOMWUvVnVMdVliOUhua3NRSVhUSjNUZkF0R2REYi93czcyMVllWSs3?=
 =?utf-8?B?b0N3ZWFSRHU2TUM0bDFrVjdhZnV5bzRhc3NSdU1ETlNCcXNKWm9IZnpHQk0x?=
 =?utf-8?B?eCtQUzJiSTh5T043cVhYOUJwUXMrYWVmZmtmN2xTbzdvS1R5cGtlNUQ0SHEv?=
 =?utf-8?B?Y1J5TWErcjZIUjk2R0o0ZE9LRnZCblowU25iK2FObWt0NDRjRjZIQUJjZUR4?=
 =?utf-8?B?czZXdkRCRms3ZTYwSWxwbVV6eWltVUJUekI3cVE5LzMydy9KQ2VoVGNvaEdw?=
 =?utf-8?B?Y1FBU0xML2hJbFJtRHVVdUdVSHB3MFJzS2NSMERmZ0pPeFZ6Zk5xemZwS0lC?=
 =?utf-8?B?VkRJS0hDRU8rTDhQdy9FWnJMeTZmWFZUSW43YWZTSnVUZUY0UWpqNm1leUxN?=
 =?utf-8?B?cG81bjJaT1Qvcm9xZS91NGNja0JiVWJFUTBXc0RwTGVaemV0ZEh4akErTUZx?=
 =?utf-8?B?cnB1QS83MjhNV1ZTMXdJR0lCSjFpUUhQOWtsMlptS0MzSG5UeWlnY3RlK1pj?=
 =?utf-8?B?bHcyS2JiUEgxK05QZmRiaVA2RUcyMlliVWpXL2lhQk1nQk42aXhvMlFlUFpt?=
 =?utf-8?B?RjlPTHNXdnNCQ0x4VFNJNlNBU2d0SGp3WjVCQ0YwRFRhYUEyT1diRnkwY1Ro?=
 =?utf-8?B?Mmcza2ttZDdnSzQ1bTE5VFlDdVlaaXpkdlJJUjV5NEgxM015YXcvamdSZlJQ?=
 =?utf-8?B?ZnZOWmRoMzYxS2U3aENldityOXdoOUF1UXVkOHFYdlV3UmpLSmQyaDMvR2hI?=
 =?utf-8?B?dEpNUGswS2tCL0NXNmJSekZTNDlvV1pzazhRM1R0a1BwV2J6UittV3lxN3hh?=
 =?utf-8?B?YWtreFRCMFJxaitHRjdDRWZUdVZrWXRqMm54REVKeWhJNGVNbHo4S0FuMnlw?=
 =?utf-8?B?Sy9vWlQzcSswVGlTWWFTamFpa3dnaXMyUTRpZUNrL0dhbE9uY3dTMTVFdjRW?=
 =?utf-8?B?NzJXVWpLamRLano0L3lUZTB0ZElIbnY1SHcwTVo1NnlkbDR1ckZGMmJxMHQ3?=
 =?utf-8?B?Q1NlbDZSZlNTVjhyY0R1L2oxc0FGS1FiRVJVWnBNY1pwbGtTOXl0MXZxRmhB?=
 =?utf-8?Q?mwDoQH5u6gAtGle1fT?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <359BE06334B5444F871D6398C002C13A@EURPRD10.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
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: chrullrich.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 268408c6-6a0d-41e9-9b46-08da485eef66
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2022 08:23:00.6638
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ee9b5e7-26b6-4fdf-9b47-cf4fbc6d4e3f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OdoBz8POy/GNujtdAnmCI10dycTXt+U5YNrc6YHwmogcLurL0zdaH1ZYdTuglNQ/JnUDkrx5YA6ww6gBPgE6Lw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS1PR10MB5579
X-Rspamd-Queue-Id: 4LHNf73Zvpz4VpS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gloomberg.onmicrosoft.com header.s=selector2-gloomberg-onmicrosoft-com header.b=UVEwzjIC;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of chris@chrullrich.net designates 40.107.21.69 as permitted sender) smtp.mailfrom=chris@chrullrich.net
X-Spamd-Result: default: False [-3.32 / 15.00];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gloomberg.onmicrosoft.com:s=selector2-gloomberg-onmicrosoft-com];
	 FREEFALL_USER(0.00)[chris];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[chrullrich.net];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_COUNT_THREE(0.00)[3];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.21.69:from];
	 DKIM_TRACE(0.00)[gloomberg.onmicrosoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.21.69:from];
	 NEURAL_HAM_SHORT(-0.92)[-0.920];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N

KiBNYXR0aGV3IEdyb29tcyB3cm90ZSBvbiAyMDIxLTA3LTI1Og0KDQo+IE9uIDcvMjQvMjAyMSA4
OjE4IFBNLCBNYXR0aGV3IEdyb29tcyB3cm90ZToNCg0KPj4gSSdtIHNlZWluZyBzb21lIHN0cmFu
Z2UgYmVoYXZpb3Igd2l0aCBrcXVldWUgdGltZXJzIG9uIG15IGFhcmNoNjQgDQo+PiBob3N0LiBI
ZXJlIGlzIGEgc2ltcGxlIHRlc3QgcHJvZ3JhbSB0aGF0IEkndmUgY29tcGlsZWQgb24gYm90aCBh
bWQ2NCANCg0KPj4gV2hlbiBJIGNvbXBpbGUgYW5kIHJ1biB0aGUgY29kZSBvbiBhbiBhbWQ2NCBo
b3N0LCBldmVyeXRoaW5nIHdvcmtzIGFzIA0KPj4gZXhwZWN0ZWQuIFRoZSBldmVudCB0aW1lciBl
eHBpcmVzIG9uY2UgZXZlcnkgMyBzZWNvbmRzIC4uLg0KPj4gSG93ZXZlciwgd2hlbiBJIGNvbXBp
bGUgYW5kIHJ1biB0aGUgc2FtZSBjb2RlIG9uIGFuIGFhcmNoNjQgaG9zdCAoIA0KPj4gcnBpNGIg
KSwgc29tZXRoaW5nIHZlcnkgZGlmZmVyZW50IGhhcHBlbnMuIFRoZSBldmVudCB0aW1lciBleHBp
cmVzIA0KPj4gYWZ0ZXIgMyBzZWNvbmRzIHRoZSBmaXJzdCB0aW1lLiBCdXQgZWFjaCBzdWJzZXF1
ZW50IGV4cGlyYXRpb24gaXMgZm9yIA0KPj4gZXhhY3RseSB0d2ljZSB0aGUgZGVmaW5lZCBpbnRl
cnZhbCwgNiBzZWNvbmRzIC4uLg0KDQo+IEZyZWVCU0QgZ2VuZXJpYyAxMy4wLVNUQUJMRSBGcmVl
QlNEIDEzLjAtU1RBQkxFICM4IA0KPiBzdGFibGUvMTMtbjI0NjAxNS1hZGU4YjgxMGIwMi1kaXJ0
eTogVHVlIEp1biAxNSAyMTowNDozOCBDRFQgMjAyMQ0KDQpIZWxsbywNCg0KSSBzZWUgdGhlIHNh
bWUgb24gMTMuMS1SRUxFQVNFIChyZWxlbmcvMTMuMSkgKGRvdWJsZSBpbnRlcnZhbCBhZnRlciB0
aGUgDQpmaXJzdCkgdnMuIDEzLjAtUkVMRUFTRS1wNyAocmVsZW5nLzEzLjApIChleHBlY3RlZCBp
bnRlcnZhbCksIG9uIGEgUGkgM0IrLg0KDQpEaWQgeW91IGV2ZXIgZmluZCBhIHNvbHV0aW9uPw0K
DQoNClRoYW5rcywNCmJlc3QgcmVnYXJkcywNCg0KLS0gDQpDaHJpc3RpYW4NCg==

From nobody Tue Jun  7 13:39:03 2022
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 457973EBBED
	for ; Tue,  7 Jun 2022 13:39:08 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b])
	(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 4LHWfg2Gd6z3kZl
	for ; Tue,  7 Jun 2022 13:39:07 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qk1-x72b.google.com with SMTP id n197so6136209qke.1
        for ; Tue, 07 Jun 2022 06:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=ybJpaw6lVVhtPZwlU3Ps31oJuJOnVxdrz4VoXlX2gwA=;
        b=l0htubjhpW570soxYJThXxYTWvD7WMBUojnHmnPQUCbBZ36ibuDWjyeUWG6+sjYiNm
         BrJctcjupBDKt+uX0vhvl2OW2uE+57NGcccsGzWeN4bnIqe0jdzF5GTDw1Rfa05IWfa5
         MU4RH1JJ7bycCq/cJx8BOk+qyvWZFCntGWs8Rn1y7+vw0VTcaTs7xVN/1JIJaiExzmDX
         NwFP4crCM0oQ05ynSi+b1owh0gTPWc1Xl+ruZQOlR/foiygDK989Iyr3TvDhroV/6yOo
         mbl7wYsr9Ron3QCVqIDWEZTdaC0DNt4VjJ0J2JlDMvEhelz8An7XigSrVzZC/Km5QY7/
         AFLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=ybJpaw6lVVhtPZwlU3Ps31oJuJOnVxdrz4VoXlX2gwA=;
        b=NHqTRPISqgGONUw0N0OtGZIrJJE2Miu01C+rvJT9mgklPI7qB34OQ4C54DkpWF1Rf8
         MH2lqByUUxyQptTYfE50JSNk3nPWU2+htKDWZKYVa7uUe90satil/j4Jf0U4F4mI7cIw
         2ko1Kw8ptEl65xtx/gzSo/ww0RQjXRXob8Dh0EVMPiUenPWgJuq2oxYbdpjkOnFOxxJ9
         wWCF++CUsUAO/Ktw2nsN02ah5mRlL1985LM+UvIaAYZA/z3JnmqqgySdPTPhy0vwTFcz
         MudCXmNVnRK35DwnnXmjkmnamaV6OPPsPZiV3OmaarEND4tCztcPbu+5cF/zSMQca9Q5
         buIA==
X-Gm-Message-State: AOAM533ZyAW6sxn/oWpWi2ki3ZhhkPyzUIOD6PZAhJnBp4CqS5fxTgOk
	yxXih3sGFQ0Oa67P0XmmIDZLHByrgMM=
X-Google-Smtp-Source: ABdhPJy+O6yv5O++UicQZ2ToYQ0TAyO37LVOqXhcWNgPhzglpVqXFUircazoejz1OLIp5l1jKFPxcw==
X-Received: by 2002:a05:620a:2903:b0:6a6:d578:afce with SMTP id m3-20020a05620a290300b006a6d578afcemr2595605qkp.703.1654609146843;
        Tue, 07 Jun 2022 06:39:06 -0700 (PDT)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id hh8-20020a05622a618800b00304f3e320f2sm1978632qtb.4.2022.06.07.06.39.05
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 07 Jun 2022 06:39:06 -0700 (PDT)
Date: Tue, 7 Jun 2022 09:39:03 -0400
From: Mark Johnston 
To: Christian Ullrich 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: aarch64 and kqueue timer events
Message-ID: 
References: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net>
 
 <303b3e3a-7856-afdd-dd0b-9fd0d486215f@chrullrich.net>
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: <303b3e3a-7856-afdd-dd0b-9fd0d486215f@chrullrich.net>
X-Rspamd-Queue-Id: 4LHWfg2Gd6z3kZl
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=l0htubjh;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72b as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.27 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-0.94)[-0.939];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.63)[-0.632];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72b:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jun 07, 2022 at 08:23:00AM +0000, Christian Ullrich wrote:
> * Matthew Grooms wrote on 2021-07-25:
> 
> > On 7/24/2021 8:18 PM, Matthew Grooms wrote:
> 
> >> I'm seeing some strange behavior with kqueue timers on my aarch64 
> >> host. Here is a simple test program that I've compiled on both amd64 
> 
> >> When I compile and run the code on an amd64 host, everything works as 
> >> expected. The event timer expires once every 3 seconds ...
> >> However, when I compile and run the same code on an aarch64 host ( 
> >> rpi4b ), something very different happens. The event timer expires 
> >> after 3 seconds the first time. But each subsequent expiration is for 
> >> exactly twice the defined interval, 6 seconds ...
> 
> > FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #8 
> > stable/13-n246015-ade8b810b02-dirty: Tue Jun 15 21:04:38 CDT 2021
> 
> Hello,
> 
> I see the same on 13.1-RELEASE (releng/13.1) (double interval after the 
> first) vs. 13.0-RELEASE-p7 (releng/13.0) (expected interval), on a Pi 3B+.
> 
> Did you ever find a solution?

The bug was fixed recently, unfortunately after 13.1 was released.  See
https://cgit.freebsd.org/src/commit/?id=524dadf7a8725dea144571843e611dbdbd59d668
We plan to release an erratum with a patch for 13.1.

From nobody Wed Jun  8 09:30:58 2022
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 2817A840C23
	for ; Wed,  8 Jun 2022 09:30:59 +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 4LJ25t62mMz4n40
	for ; Wed,  8 Jun 2022 09:30:58 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 B06665149
	for ; Wed,  8 Jun 2022 09:30: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 2589UwbW040902
	for ; Wed, 8 Jun 2022 09:30:58 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2589Uwq5040901
	for freebsd-arm@FreeBSD.org; Wed, 8 Jun 2022 09:30: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 263607] [panic] [arm64] [13.1-RC4] very early panic after
 Release APs
Date: Wed, 08 Jun 2022 09:30:58 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: dch@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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654680658;
	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=40JeBefP4t6xYjLx5YMKShNyJixv/Hq2CRqCtrBTkOI=;
	b=NZhyJgohmUXZuHcTeUTsfU9iCfG/Ew8XJIN6ajwFbgpfY5+UZA0RVDtid0eqSC4Hr5UMC8
	lFJwbJMBdBsT3Of99dfVSGofkkly3QacosHFyPsKuIXKJItUOfUp8UPvr/Dw7PF7MW1+y+
	G2bgamE3aAy8JnAvgrUjIPb+j1t48W3Baz9Rd8gBSRBOxXSfIPiUNmHD7+a5PTBqUARD7i
	MFwnXsf2Q2t+Xq3TtDDNUCgsNRsay2WQFrwKJLHlMVReZarcQ7QSoDYmDwY0t73gAcbZFz
	cK+QCis+afXzeoNZIK4Sem76tleFlqbnSOtS4Fy7c58OakbpCJelgrcL/uG8mQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654680658; a=rsa-sha256; cv=none;
	b=vWgWGlRA6HIHXpcJyLSdghXHskX1x7fsMFlI037bx5fpjuM0Uh0/BVgAamUnIp4U55eyQ1
	ADEZEP+AKx67mvgOG63jF4XEC2OEfHBZyc1SDTOoOqGazWYb3kk16zOn5XRGMK7Dqj622L
	BBYIDPe5FcVV8Prnz8eTniDyayQipr0DyYHhIIpfWojX6rBhykzdUj8+IY1didLKDmp7y4
	Vbkt6hdFJjHrxz0PxhtWpSoRsNq8QlfrGX/Z30GLgT65PTj7MldqClyIvQPUzEsWhZi2br
	N2R7/MQeqYbog4rJ/HughdiUnkYuQv6R+vdi+6Tou1hRvKUyLHss8EzRRxvXEg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263607

Dave Cottlehuber  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|New                         |Closed

--- Comment #6 from Dave Cottlehuber  ---
fixed by andrew@ in https://reviews.freebsd.org/D35084 thanks!

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Jun  8 10:21:47 2022
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 CB616850FA7
	for ; Wed,  8 Jun 2022 10:21:56 +0000 (UTC)
	(envelope-from chris@chrullrich.net)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2082.outbound.protection.outlook.com [40.107.21.82])
	(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 4LJ3Dh0C66z4vJP;
	Wed,  8 Jun 2022 10:21:55 +0000 (UTC)
	(envelope-from chris@chrullrich.net)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=oAFBfLbbcQ2k0tWXWvycnmkOiEsolyszrRko3QPwJXdETtQHL0HSn2ChSKF64sG/svzqGdxsYPih417GZJmyty8p5LciLZB7eTSFIMIbilLMNwByA1GoEPQDur5siSg5lcEfP6v6YIpDGqQjNgevCl+rffU9hjf+qzohWWVYQ60Mx5yBV2LtlA09Ke5ERPxSxLmWFKfc7gQlEkbWxpLDZiYjdQ/yLbupkiaziJvuLv5IGF6G6bmbSCARWT+eJujHLYszeozy4/bBNnKkVG4+juTvAJCm19kR+Kj23veFUtJtA7Na+lhk5gZXlrjBr/YPIWuJIxfYPbg8Sgq8p7o8ZA==
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=F3JKAFGZp2iQtKmMnIqclPHFwVdWZ25ckBWPNaJsxm4=;
 b=lBsOpWKlQg45Nvi8haocEMl+NKISLK8XFiwhoraZo3tNCb5EBSSMgVnrfW/VTU3esziSgFPa1bHRa+NOwCNoiNkWD3pE1p8eCVG5n49dJtIUFzus8RZIZyvSctfSG04oC3cyiH6ciK9o80RHzVorP0L+SIt/gwFb6grf0mPgctgSFOf0TF2Mj0Vjg4AcHoeGwT3F4HPy9RK2h+qlp06E2MjWqJLALzu4fH5MgOvFnkLCrDupjmvtKRIKywI2DVy3WuInvZTl0ySvtgRJ7c4wVYY/C1C/1cmP9JOJ6nb0gm0Irt5M+3CzzSJlaUYfj3ukLyoZWKUNl7KB31TMDjugRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=chrullrich.net; dmarc=pass action=none
 header.from=chrullrich.net; dkim=pass header.d=chrullrich.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gloomberg.onmicrosoft.com; s=selector2-gloomberg-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=F3JKAFGZp2iQtKmMnIqclPHFwVdWZ25ckBWPNaJsxm4=;
 b=nWlNdDoAxCySsWeFBp7BAS6ZND4bFfLqFxETPs3m3il/YhJhsIqW5UWFzH6KYPj0nnIYLX6zGfG6EMJnm6hbSIirtD+sZ5OMoFRVHPynOz2VwQHaw1DYRtKntQtPIXJIsbvQlNi2oB4gZI3yUu9I6jEKxRT1IOb8cEI/NqriZBE=
Received: from VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:12d::15)
 by DB9PR10MB4863.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:2c6::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12; Wed, 8 Jun
 2022 10:21:47 +0000
Received: from VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
 ([fe80::d0b:36ae:fd87:4a30]) by VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
 ([fe80::d0b:36ae:fd87:4a30%4]) with mapi id 15.20.5314.019; Wed, 8 Jun 2022
 10:21:47 +0000
From: Christian Ullrich 
To: Mark Johnston 
CC: "freebsd-arm@freebsd.org" 
Subject: Re: aarch64 and kqueue timer events
Thread-Topic: aarch64 and kqueue timer events
Thread-Index: AQHYekfMvjAIJfwg2UeUpSRQd3P3cK1D81eAgAFbN4A=
Date: Wed, 8 Jun 2022 10:21:47 +0000
Message-ID: <9128ad95-e895-50fb-e995-4873d81baaba@chrullrich.net>
References: <03ff40c7-b755-8421-713c-90aa4d8535fe@shrew.net>
 
 <303b3e3a-7856-afdd-dd0b-9fd0d486215f@chrullrich.net> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fb6bb1af-c8c0-4e53-2dcc-08da4938b1d9
x-ms-traffictypediagnostic: DB9PR10MB4863:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 V3CXXIEwrE7YjdmFnvk3pQhzwqEFnQFS8mYRr0C7vzONuICHNryWqVFTrtDJLELkVLEJ+YasKi0pf3W1jxkcmAxEX1H0BIhsIGxpQDPco82HxcJ3V3De7oLQUB1zFdZiiopOf4+/XReLhHe515rpF6aambeHYlF3E/aud9BGO0bDHAy7U21XnYx9C47rIc86vaCeKx0mK2J2ao+Byk0kjFZvCf0tpA1k7cThXlMIGPVNl3gP+oHuZdteUbD5XvOKlyrrhorfYkVbYl2d2m54liA9cFA/AdnMpDe8T2QyNIZQyE4mVKzd0krwgOZi5EscRmwUEod+RWJ98FOV3cHJL9pdrKwZHk1il97ade9hHDOQcj0bs242QG1PCdqV2/FHa1TgrZLWjCOQb9KCw/NC0FQqSXWdWP1/QJWt+kPElP6A2U17vpPQwqvo9pRzRONQiSTw6Q402mEi5xDr9NRRa3y8+ECqMJ09lgtIi8qDafLwVUwNk/xlN+MJ8FyZ0Xn6TATBBt0Y2hnqjK4mfUcXBVIDgXx56cTlL/lkuSQDK1ygxZba+9Ajp52Imb47jlRC19iD6G/FUzpb+zBej0Lgte+LK5x+Uw1C/9yYg04S4DX8lNxpw7BzbFNfYgG8lwEWk4aXr/Ix2YjmtXDgTgEazm4CbAKlG0X//V0Y0GcGrTXlifUQ00D3xuJLnHxJuUwj4DorV9mj6KBNy9d7v6Qk/mr6ivWl7GQbNNzyZcEheJWM/TF09sT4cUFZlrcM3GUOs4EYEb9ls205W8pA9p5HZ0E8NSIJWVtKaDCckkUVYP9dVja65PCFoymkOqxWMkrGM1cDFMn9O6MDKTyuu7lL1AcCAkfREemArdghfT2b60k=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(396003)(39830400003)(346002)(136003)(366004)(66556008)(66946007)(66476007)(966005)(38100700002)(2906002)(316002)(31686004)(6486002)(66446008)(71200400001)(64756008)(5660300002)(38070700005)(76116006)(8676002)(4744005)(122000001)(4326008)(91956017)(450100002)(36756003)(8936002)(41300700001)(83380400001)(86362001)(6916009)(186003)(26005)(6506007)(31696002)(6512007)(2616005)(53546011)(508600001)(43740500002)(45980500001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MW03K3ZDaXdibUYvM095MWVyeDBjNGhUcDFHTFR5ME1WVTI0RmhtczRzemFo?=
 =?utf-8?B?NUNOdEVuMFl2S3hjNDZrTERISFB1dDJLN0V1d2pMMVZ5ZzFXTk9VMEhKTnRO?=
 =?utf-8?B?NTB6S04weUNGOU1rTWp0d2ZiMVRSVlVIdEJ5MHFFRWVIbGY1VFVYWEplVW1V?=
 =?utf-8?B?MFd3cExTNzF3Sko4dXlib05EcURDb2tvK05PVFg1Q2lKN00zb0xmZSt4U2dH?=
 =?utf-8?B?MThrTEQyZVBiUWdMTE5nSkZNZjV0TzZ4akZPVHJvS0MxaFNqb3I5em1aVFV4?=
 =?utf-8?B?Mm16NHhxZ3pBVjhvVndSUmRiUyt4c0dnWTZqMVBRODVDbnl2TDN4SUZjNVF5?=
 =?utf-8?B?d1pBclphTDlqWUxGSFpLSnFtZm0rTUhFdGQ0ZXE0U3ROUlVIRkRUT1k1RWpW?=
 =?utf-8?B?alVub3I2SFc2dFM3c0VPeis1dzB6VGpvdk9Eekl6WlhGeUNsdDJFckdZTmM5?=
 =?utf-8?B?MHhaL1JmaVZteVpydDB3QVk5c1VzVEQ1NDhjT0RyK2oyRXQyTVNWK2dqNDhU?=
 =?utf-8?B?TnlvMDE2ajY3aTV6SWdkN1pTTjNZRHZWTVFnSko3S1p2bnRHcXVXWDFETW1s?=
 =?utf-8?B?MkRoMnZ2T2JDODdiaWxsQlhzZWR0MmE4aTZwSHFFTWo2a056M0c5b3VmeFJj?=
 =?utf-8?B?aXBURGNIelBUUC92Zk5oaUsreFVhN1pTWGRrUWlJSjBUNTgzelNHRDVsTDBI?=
 =?utf-8?B?cUR4Ni8vTzk0NnFZUGIydGQ4Sm1LeTRsYnNFS2gvUmgrY2lucXg4dUR6VERI?=
 =?utf-8?B?ZFpEOXprYUtkcXJ3WHZqWVp2OUcyZitYV2pHZnlDZFFqaVo0MHpQeE5HR2x3?=
 =?utf-8?B?RVorcC96NjdmcDhOMTlTUy94TkRIYXpKU2owQUt2c3ZHMDZmem1tVlhnTFRI?=
 =?utf-8?B?RERuSjdRT01kSytNR1Z4QmVMeTIya3NZc1JXSkg1WVhSZXhuTXJ1aUhIQmJm?=
 =?utf-8?B?dEVtMFFwc2NTek12RWtqb0NkOXJ1V2RtZVFQcTZLQ2Q4SW1JdmxnRktTMktY?=
 =?utf-8?B?ekRRQU9LTXg3MU9PYmdWbWhwUTZvL3kvcFJtVlkvRmhDTVBVK3hMc2N3Y1hD?=
 =?utf-8?B?a2FPSld4Y1VuRTQyUjhaU1B4dCt2azE2WmNZcUxVTDNCdTV5L2hWYWxFYmpZ?=
 =?utf-8?B?RWtrUVlOcWVYRlFWVUM3dngzRVBQRmpWVXlUL0tnMkZNU3hvSXdoaTV2YTdB?=
 =?utf-8?B?ZTVzM2Z5MlBEN2M1UW0vRUpVTmVqTkxHYllmS3BHTC9WMjNlVGFVMGFsY2o2?=
 =?utf-8?B?Qnd3dE9IV1lOUDI1WUNzR2RqTTBRWDcwSHlEaFlvME9lTXk0em9DZ0RyU1Bk?=
 =?utf-8?B?S2ZVYzVPTTJuRkpiQlJoa1IvTXc5clViaURQT3pRcFdBZEU0NFBKUnhFaVRZ?=
 =?utf-8?B?bm9wUmloZzVRUzAwTm11dHRoRkIyQU95UDdEeEJXUWlxUU0zRDl3bUx2V3ly?=
 =?utf-8?B?VHdDYWhWUzZhS1RzWnkwVG14RmphWGpjK1dubHhmN25wZ1FTNlJIYWxzSlJH?=
 =?utf-8?B?QlhoK3lpUzhaUDZjZ1o1cG5uRkU4M3ZPVlA5Wk9sZTE0Q25NUzRxRldGT2Jo?=
 =?utf-8?B?aTBxVmU2MnBvcDhTTy9MNU1wVEY5OWk5aHliaUMrKzR0S3o5OThPVjJjR01P?=
 =?utf-8?B?NXptbWZrL2xoWm8zMXlsdUw2dS9pUHpsc1NnakFoajV5cm9EVUZSS2t4emZ6?=
 =?utf-8?B?RTVBQThZZ0xaYlVWZlpmSjM3VW5hY2ZnLzMzSHJsTnBnTnZrUENDS3ZtN0hL?=
 =?utf-8?B?UUc4K01lY09iNkl3eXFkSWcvWGdDT3FRakcveU5IQ0pYWjV5cnZYODRRU3RY?=
 =?utf-8?B?WHpLTkJ0NnZ0ckc2VXdObVJUR004WHlTV1dBNGFEdFpVTmNqdGkrK21LZTNq?=
 =?utf-8?B?Vkl6OGhpS3VXeG56RjlueHRvemgwVWxsaGlGQ1BlK1ZKVjFMZW5xMUF5QVh6?=
 =?utf-8?B?MDQ4dWVhK0ZEMERSa29DMGU5T2NpQ0FiekNrVDBvRXVxMHVxd3YvRXV0dUx2?=
 =?utf-8?B?UkdVQVNWcE9yaXpaeUFORXUzajkrNW9BdHV6enJzV2N6eGVCOWx3K2syeFNl?=
 =?utf-8?B?bDdSRHZBSDhEbXFPa0g5WkxKQzJ4V1FRTFdrOE9rSGpITmRqcDZRSlNkb3B2?=
 =?utf-8?B?RnhqT3BLc3hMU3hoa1RLazlXSS82UGdLbXZOa1hKUWoyYllXWjBFZUxvL0Z4?=
 =?utf-8?B?R0Y1TVBIdW5QTXNFS2d5ZmtrU25WK1RuYkR0ZkxHSUIyRWdmcjY2ZmN2QkI3?=
 =?utf-8?B?UUtXZnA5VkxwZjZXMUlhcXp0bGx2UU5WTDlJck8xcnNibTVJZHZzRTAydU93?=
 =?utf-8?Q?nEqkGW2qI7VWwCjiGB?=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
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: chrullrich.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB3167.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: fb6bb1af-c8c0-4e53-2dcc-08da4938b1d9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2022 10:21:47.6674
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ee9b5e7-26b6-4fdf-9b47-cf4fbc6d4e3f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GBxRZtXiA3vvT2uq1bhiFSFHgYDviZdMgWV1JeUTNhmSUm1wcbNJsqLmaXSmCqs5bTA4XYi6wuut/hdesbVW3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR10MB4863
X-Rspamd-Queue-Id: 4LJ3Dh0C66z4vJP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gloomberg.onmicrosoft.com header.s=selector2-gloomberg-onmicrosoft-com header.b=nWlNdDoA;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of chris@chrullrich.net designates 40.107.21.82 as permitted sender) smtp.mailfrom=chris@chrullrich.net
X-Spamd-Result: default: False [-3.24 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gloomberg.onmicrosoft.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-0.84)[-0.843];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gloomberg.onmicrosoft.com:s=selector2-gloomberg-onmicrosoft-com];
	 FREEFALL_USER(0.00)[chris];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[chrullrich.net];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.21.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.21.82:from]
X-ThisMailContainsUnwantedMimeParts: N

KiBNYXJrIEpvaG5zdG9uIHdyb3RlOg0KDQo+IE9uIFR1ZSwgSnVuIDA3LCAyMDIyIGF0IDA4OjIz
OjAwQU0gKzAwMDAsIENocmlzdGlhbiBVbGxyaWNoIHdyb3RlOg0KPj4gKiBNYXR0aGV3IEdyb29t
cyB3cm90ZSBvbiAyMDIxLTA3LTI1Og0KPj4NCj4+PiBPbiA3LzI0LzIwMjEgODoxOCBQTSwgTWF0
dGhldyBHcm9vbXMgd3JvdGU6DQo+Pg0KPj4+PiBJJ20gc2VlaW5nIHNvbWUgc3RyYW5nZSBiZWhh
dmlvciB3aXRoIGtxdWV1ZSB0aW1lcnMgb24gbXkgYWFyY2g2NA0KPj4+PiBob3N0LiBIZXJlIGlz
IGEgc2ltcGxlIHRlc3QgcHJvZ3JhbSB0aGF0IEkndmUgY29tcGlsZWQgb24gYm90aCBhbWQ2NA0K
DQo+PiBJIHNlZSB0aGUgc2FtZSBvbiAxMy4xLVJFTEVBU0UgKHJlbGVuZy8xMy4xKSAoZG91Ymxl
IGludGVydmFsIGFmdGVyIHRoZQ0KPj4gZmlyc3QpIHZzLiAxMy4wLVJFTEVBU0UtcDcgKHJlbGVu
Zy8xMy4wKSAoZXhwZWN0ZWQgaW50ZXJ2YWwpLCBvbiBhIFBpIDNCKy4NCj4+DQo+PiBEaWQgeW91
IGV2ZXIgZmluZCBhIHNvbHV0aW9uPw0KPiANCj4gVGhlIGJ1ZyB3YXMgZml4ZWQgcmVjZW50bHks
IHVuZm9ydHVuYXRlbHkgYWZ0ZXIgMTMuMSB3YXMgcmVsZWFzZWQuICBTZWUNCj4gaHR0cHM6Ly9j
Z2l0LmZyZWVic2Qub3JnL3NyYy9jb21taXQvP2lkPTUyNGRhZGY3YTg3MjVkZWExNDQ1NzE4NDNl
NjExZGJkYmQ1OWQ2NjgNCj4gV2UgcGxhbiB0byByZWxlYXNlIGFuIGVycmF0dW0gd2l0aCBhIHBh
dGNoIGZvciAxMy4xLg0KDQpUaGF0IGRpZCBpdC4gVGhhbmsgeW91IQ0KDQotLSANCkNocmlzdGlh
biBVbGxyaWNoDQo=

From nobody Wed Jun  8 12:25:29 2022
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 321988396D7
	for ; Wed,  8 Jun 2022 12:25:42 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330])
	(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 4LJ5zS4FF3z3jm0
	for ; Wed,  8 Jun 2022 12:25:40 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: by mail-ot1-x330.google.com with SMTP id g17-20020a9d6491000000b0060c0f0101ffso2715898otl.7
        for ; Wed, 08 Jun 2022 05:25:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :cc:references:from:in-reply-to:content-transfer-encoding;
        bh=WDcyBq3JqjJWv8OJANUvLUE8AaC91ivgXJpt4v12buw=;
        b=JAApVDQ+wn6TnniZlFoC0zLQYxRFjCRNDf+GYva5m2cBTxFR7W0VY8g2ucQdpBqZRv
         qVndHa1gOgaFyd6j0u2WKHIAn0oRKupZXll2DtRvZHKTJZvAXJMZmHo5RWxS+2pHByhZ
         CFat7VCJ00o/EQLX02xF5GCmZUgVrB0x0/Gfs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:cc:references:from:in-reply-to
         :content-transfer-encoding;
        bh=WDcyBq3JqjJWv8OJANUvLUE8AaC91ivgXJpt4v12buw=;
        b=qyMb5lffvUXFzaLQXoloqyJXYyrZc5mvSerBtqt164S7JO8cupypzLZiGY2tM39CC5
         FKd3UtD8KZWKrr004eECbj/qB/fVYDN7i/EQUg159yXfztEZa5B7t+oJJ7KN0f1Na6ZY
         oiwFpfjeo77MwMXbsQV7SAKXFSKi0QAe7AEPm2HPcR653ZOJY/7OOztkw5b2FbWS3ozk
         Q7tIR1YFQXuU2//k8xXBbtzMmJSlxq6BrUqF5ymmltuRxXxXxlKKJD+ttHcJEmVEpGG9
         ZdlapwYBii3J0WfN4RNOcb0scoo//aRJuj2XZATsjoX6JRElruh+6mo1KUZkqkM5xDim
         D7rg==
X-Gm-Message-State: AOAM532GggghOKWpH5VpLEjPwWyaQlbhazmGUdp9nh8Gfmeow/DU0pN2
	ZXlOimp3LfcsHbeLT+/usIQQwlNWnTdmVA==
X-Google-Smtp-Source: ABdhPJyWg0Mj2mWIf2RVS41HY3xPahF7yg1qfGKeP62d9w1go76ndTN6Xxqn2Qrmg+KE2um2OEsu9w==
X-Received: by 2002:a9d:877:0:b0:60c:1b8d:9b90 with SMTP id 110-20020a9d0877000000b0060c1b8d9b90mr503837oty.214.1654691134002;
        Wed, 08 Jun 2022 05:25:34 -0700 (PDT)
Received: from ?IPV6:2804:29b8:5099:52c:378e:75f1:1e7e:4f18? ([2804:29b8:5099:52c:378e:75f1:1e7e:4f18])
        by smtp.gmail.com with ESMTPSA id t11-20020a0568301e2b00b0060bf9d6c060sm4343371otr.1.2022.06.08.05.25.32
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 08 Jun 2022 05:25:33 -0700 (PDT)
Message-ID: <11716ede-92fa-9a20-ace5-1fae854123b4@bsd.com.br>
Date: Wed, 8 Jun 2022 09:25:29 -0300
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
Content-Language: en-US
To: greg@unrelenting.technology, Ronald Klop 
Cc: freebsd-arm@freebsd.org
References: 
 <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
 <1047394639.643.1654181685742@localhost>
 
From: Otacilio 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LJ5zS4FF3z3jm0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b=JAApVDQ+;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of otacilio.neto@bsd.com.br designates 2607:f8b0:4864:20::330 as permitted sender) smtp.mailfrom=otacilio.neto@bsd.com.br
X-Spamd-Result: default: False [-3.34 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsd.com.br];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsd.com.br:+];
	 NEURAL_HAM_SHORT(-0.84)[-0.836];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::330:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


Em 05/06/2022 14:31, greg@unrelenting.technology escreveu:
> June 5, 2022 2:18 PM, "Otacilio"  wrote:
>
>> After some debug I found that this routine is returning -1:
>>
>> Someone can give-me a hint about the function of psci_callfn ?
> PSCI is an interface for calling into power management firmware.
> Just saying that *a* PSCI call failed is not informative, we really need the arguments of the call.
>
> I'm not sure what firmware you have on the SD card but armstub8 from
> https://github.com/gonzoua/rpi3-psci-monitor should support:
> PSCI_VERSION, PSCI_CPU_ON, PSCI_SYSTEM_OFF, and PSCI_SYSTEM_RESET.
> Which should be all the calls that FreeBSD ever does…

I did a ofwdump on the RPI3 running the sdcard with my local FreeBSD13.1 
build (bad) and the same RPI3 running another sdcard with a downloaded 
image from freebsd.org (good) and the results are very different.

The god one:

Node 0x48:
   Node 0x110: framebuffer@3e513000
   Node 0x1c0: psci
   Node 0x1fc: system
   Node 0x230: axi
     Node 0x238: vc_mem
   Node 0x264: aliases
   Node 0x6f0: chosen
     Node 0x878: bootloader
   Node 0x890: reserved-memory
     Node 0x8e0: linux,cma
   Node 0x94c: thermal-zones
     Node 0x960: cpu-thermal
...

FreeBSD generic 13.1-RELEASE FreeBSD 13.1-RELEASE 
releng/13.1-n250148-fc952ac2212 GENERIC arm64

======================

Tha bad one:

Node 0x58:
   Node 0x120: framebuffer@3e513000
   Node 0x1d0: psci
   Node 0x20c: system
   Node 0x240: axi
     Node 0x248: vc_mem
   Node 0x274: aliases
   Node 0x6e0: chosen
   Node 0x810: thermal-zones
     Node 0x824: cpu-thermal
       Node 0x888: cooling-maps
   Node 0x8a8: soc
     Node 0x934: dma@7e007000

...

FreeBSD azul 13.1-RELEASE FreeBSD 13.1-RELEASE #2 
releng/13.1-n250148-fc952ac2212-dirty: Sat Jun  4 22:14:44 -03 2022 
ota@azul:/usr/local/www/apache24/storage/FreeBSD/obj/usr/local/www/apache24/storage/FreeBSD/src/arm64.aarch64/sys/GENERIC 
arm64


The ofwdump output must be the same on both?


Thanks a lot


From nobody Thu Jun  9 06:53:41 2022
X-Original-To: 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 CCF8C839E3D
	for ; Thu,  9 Jun 2022 06:53:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4LJZZB3lYJz4RFk
	for ; Thu,  9 Jun 2022 06:53:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654757627; bh=GUGq2HBl2rd8j8kEZM6gL/SIHcVeyh4NynNqjbUgY/k=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=MXRjqqEUfd8fgMGdFi7QilLCKEo7kmXVk6RM+HbsN+kMoDauJAo8LTZRUF5i6AXCBIPTNvbJI1DILPmUZj2mnirASzaVpm90VJ1gpC2qadCLed/X2itn9Up1RUv2JvKHQMoUPoTxqV6T4QsNGDttnGIx8HUPyTbB9yeTW0zcbT4WBgM9u8HcKnrr1rfryFJ3Rp0ETYd6XOlqIBpaGgeyxufzigR4Q79KzEehvNYeKX6Mwm2v9JhLj01uER5YllEO4S0e2mk59CIriJSAT+1Z+BhgLgyuhNff7wxtX7ChyDER70WYb1argsfc14+OBfXidwv49XVODWFpxqT5Hp9ZbA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654757627; bh=m4uvo1BrnEbVJmVUhJzFFO+cYjSeMQq6YGP5LPJIevQ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kq3GjC+y3Px7qEcGM/rJvU3KvUz98cHvNMfZ6BtTRInX1TbEyj3Awhlhs1FvXLokVUEzjW+UpLnuXBpOYKiGgU/k8GusScPSyVrXVI1MZKEWNQRbjRjEeD0oKnX9SerTyVMDhiBk0+GnfkXRAENJOErF2sz0Jcfsj3ocI24XHrXVSZuVMRupfwNw4lLrz8GiMeDBu7/Vmd964icF7NvePBSEJTKGSX+S7AN0Ru+I6pLFnEzyJHALb0ytXrX70zsBu54HVyc4tqhB63WqEB0UOvO659a5ZzJIvBlPJZFx0Wfi+CPoumkbrMPL23ino1YUP/+DEuDVLImKAkDGz8D9Jw==
X-YMail-OSG: h_taxjwVM1ncPZXLpe3X7GzsUGseKNK_oIjIsDsMd2EmtgwPGBzMYCiuqu6_U8r
 kZRLQpQs3.gY0iPvkTBHrYcGy.BOBKV9RHGwN0suczAUAHjmxQXvGJ2UyUIj84EsFZ7cYHqCl1fU
 aG0X_2ewDHuiaYKijj8e8o6aFZXnW0OzOnZz2BBrytEYAUJei.ny5PBiyUDSbQKOkvKWobVGk8DW
 JstLvG_T1CeiyK5pIYQsd6oLgmFUH3uEafCEJV632rlbCly0CK14z3kRGFdUHT5v2DxHVtaJMG04
 4HgA9xb9aaRg6c6T.Dp5lVhaMDipxcZNeRxUHq9K_4DM0_NpvC2jH320qIXl8aOdF6E8hdrlVXdF
 QBleBfSmC5vBnbklkGlwnjki.erEVSyvUBTVmMKqGSb6C4J7BM2PXoiPtKJk0X2QE6hlvsgFyO_.
 sF9dD.3piGmIFxWfQ_jtxEjAL49JsqtHX8qjVp2Ex1uAMkWLdaRQPUY1AOoRRXdo6Ah5mIga_6gR
 q4gUBCokHsakPvl4eaqfJz_7Y8X1TvRKtR5RsaK4cCGrftxsh2RbdDj4yORdb6ItH5XCpODXUX_Y
 ZiXMBPBF3P_4TIeCc4ukGuUQgdXcZG_zf5fOzPEe2pwY9R0svxx5jvQaqjljuBWWZuNtwgqpZejJ
 eyAaeW07W0aBgO53bUe6vZoxy2Qts4U3nI5Rxmh2nGj2Sl7oyYl71CsLPHrY8uSsWUdJBe364Ubz
 WoEc_SwTE0.0.24DPL60Tvm5dzstl9SrORLpsG77SJo9eFoouHxHdGzpy018dpOuZahQLsFLVVCW
 r_Ora06Eko.xD43.2AjRC.NlgyqB6S6DA5A.6iK9XI4Xf_RdZbwtteUvbpd6PU7B4ARjmysAH9bH
 l.5X8_ap2qSbsUNwrtyYQHd4pimxWwALfESzThCCQLwzzcdB44.t1hJ4GFzdOoyUMuIHypK05p10
 QaxQWnkM3of7hrjA9ZlKsa.cFESEna1XUCfkQSkc1iB7Q_usAJb_5gvtGG9cfkzjWgmDhMdH_zjI
 fuMu0t8z14vpDvEBTOgyRYcMPfNyPVw3pvArH6C9aHW4LBlsPIb4cFVxjd8fkw.o99svEFFcotFL
 TSm43h3Z.DIQZTsbnO0I3Mxso73qcD2IMUlU5nYwT0jsdvuqWaVJBuGRZTuXoG.dC8RysTHNCFz8
 85SIFfGu82wb5BJ1B7FpBEFWUD429qj3tjOV.KUpliRffttZB.wXSZlSox.DU8iwf57j2RTFdaZM
 8sxbteAkaxPSvXYZbQrCuPq9lOrhxPB45kGnVh1OfbWecliEq8NEt.IT8ZiuisFs8w_tx2b17g4r
 vGDFWV502wyajAPFWNCnaOF7SXSaEvb29qWLE66_ScjOYWAWKs2d0Wyz4JKvys5T2C5t85SsthQ6
 2ilQosvQdwiWOZDF_DXUUHFakUNDBTPGHCRjc4rY2yN9.m8lolD6t4ubl3UPUfEYFljOkynCLSwN
 rySz5m5fbnD22GbWb2z_JZor5TR76Q1zv8S4Eh7PIOTvZNNWOBpaZRlB9B46xJvkJsVenuY2Ur6_
 BS2KXYGTDhJrwx1CF3h9rH2fO7VMLnYQAZA9tnpbVwpTExe3zBmVSj_e3kHbh9oxr8srwNUJzXZj
 J08WaTvDxaHqQwbfQSOFvqisbOb1B_98q74BisSjssrEluCQI7zlNi9KIbJF.baB.MgxWJTZJeAw
 EHWey0DkJG6LpmaImQzxugRFQsdtO2SUsKp3nV4ludaD22nnIxE5EGx_Yl9ug5AUgaGSxmx_Ftpw
 1M3ZNUF4ESfoRZxiFWzgYetzX_29Ei5XzBjSQVQ8oQI9yTEYEy26hUtqIzEol3Y4BjhCteTomK63
 A5Bj4eWCud1c6y2LwSN3jj6QZ4wDT26mjAujdPhL5dgXZwmPPsJkCHKMFqJEJEd3inf7gstWrxPz
 fnSuNGskNjl142IT1a4mbpla1zyWKsCUqIIK5JpqdM.9yV_MOUDknuU4Dm1IqcYSB9vjq.MQ45l9
 B25_Q5rSQJvZ3V.oRUEWvbdPd.Qixv.o9qn.vg5l09dHKFS4JwC2A.kffX.PLkUhwP0gIxrtoq4r
 wqLQZtJ6r.kGA.KJvfYJYEnQla8g04n6oxA5cPh5djexpRcZRsIHeTQcmwiV3LE_.Nq2xUw_GPup
 PaO0r4.DRUjFOf.3NeySk5C5zLjdMN3MCNfebkp98tWmcTd054JApqU7DFly91ZZw_KgRbP_1kaX
 QC1c98GrkvcJzdL0FvAyEAS1m.B4aWjSolbhSFjYilQY.1tTciA0kaVZpxrl8dHMfY5kDyqSAaGC
 1ohU-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Jun 2022 06:53:47 +0000
Received: by hermes--canary-production-gq1-54945cc758-mg5mc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ba6d90b324bde1f4b723cad549570487;
          Thu, 09 Jun 2022 06:53:42 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: HoneyCombs and such: looks like over time it will be switching to
 DeviceTree-based development from ACPI-based.
Message-Id: <4717091F-8CC2-4E00-A3BF-45021F6C4049@yahoo.com>
Date: Wed, 8 Jun 2022 23:53:41 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <4717091F-8CC2-4E00-A3BF-45021F6C4049.ref@yahoo.com>
X-Rspamd-Queue-Id: 4LJZZB3lYJz4RFk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MXRjqqEU;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.89 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	 NEURAL_SPAM_SHORT(0.61)[0.612];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

The SolidRun Discord message that is relevant said:

"After this next UEFI release, I will only be focusing on
fully SystemReady IR (not certified though) for our Aarch64
platforms"

SystemRead IR is DeviceTree based.

A related note relative to DeviceTree and being
rather Linux tied lead to the following:

"This is something I have already pointed out about
SystemReady IR and device-tree.  I will re-focus my
efforts on a global device-tree repository that is
separated from Linux"

As to why: In summary, getting patch sets through for
ACPI (SystemReady ES type of context) to enable
functionality has proved too much and too slow over the
years of trying. Thus the change of direction after the
next UEFI update.

(Read the recent Discord material to guard against any
misinterpretation on my part in my attempted summary
above.)


===
Mark Millard
marklmi at yahoo.com


From nobody Thu Jun  9 08:43:56 2022
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 40CD0846DE7
	for ; Thu,  9 Jun 2022 08:43:58 +0000 (UTC)
	(envelope-from samm@freebsd.org)
Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJd195Pl2z4cpZ
	for ; Thu,  9 Jun 2022 08:43:57 +0000 (UTC)
	(envelope-from samm@freebsd.org)
Received: by reindeer.net-art.cz (Postfix, from userid 65534)
	id 138176013D; Thu,  9 Jun 2022 09:43:56 +0100 (BST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,KHOP_HELO_FCRDNS,
	SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no
	autolearn_force=no version=3.4.2
Received: from owl.net-art.cz (surikat.net-art.cz [IPv6:2a03:6920:0:10::101])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "owl.net-art.cz", Issuer "R3" (not verified))
	by reindeer.net-art.cz (Postfix) with ESMTPS id CA25F5EEB7
	for ; Thu,  9 Jun 2022 09:43:55 +0100 (BST)
Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz)
  by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20)
  with ESMTPA id 1322735 for freebsd-arm@freebsd.org; Thu, 09 Jun 2022 10:43:56 +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
Date: Thu, 09 Jun 2022 10:43:56 +0200
From: Alex Samorukov 
To: freebsd-arm@freebsd.org
Subject: FreeBSD/arm64 on MacOS/arm64 QEMU
Message-ID: <3746ef0824223b7652f24b3d5d1f3e1e@freebsd.org>
X-Sender: samm@freebsd.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LJd195Pl2z4cpZ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:15e8:110:513c::1 is neither permitted nor denied by domain of samm@freebsd.org) smtp.mailfrom=samm@freebsd.org
X-Spamd-Result: default: False [-2.92 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEFALL_USER(0.00)[samm];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_COUNT_THREE(0.00)[3];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.82)[-0.817];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 TO_DOM_EQ_FROM_DOM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I found that running FreeBSD inside new M1 macbooks is stable and fast. 
I did a small article about it in my blog: 
https://smallhacks.wordpress.com/2022/06/09/booting-freebsd-13-1-arm64-on-macos-arm64-using-qemu/

Only issue i found is that when the guest is active it is causing very 
high CPU usage on the host, it seems that idle cycles from VM are not 
passed to the host correctly. Anyone aware what could be tuned to fix 
that?



From nobody Thu Jun  9 13:54:06 2022
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 13BA1856CCD
	for ; Thu,  9 Jun 2022 13:54:07 +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 4LJlv25KCjz3nsg
	for ; Thu,  9 Jun 2022 13:54:06 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 972FA25395
	for ; Thu,  9 Jun 2022 13:54:06 +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 259Ds6Fq049731
	for ; Thu, 9 Jun 2022 13:54:06 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 259Ds6qJ049730
	for freebsd-arm@FreeBSD.org; Thu, 9 Jun 2022 13:54:06 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 264574] FreeBSD-13.1 mountroot error 19 on Raspberry PI 4 UEFI
Date: Thu, 09 Jun 2022 13:54:06 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: neukam-bugreport@gmx.de
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654782846;
	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=cs/H3+W6/DMhAZDZw2hqtnEhQOU96ljbeGEXiSpTYOM=;
	b=COb73B9sIqqQpVCiqzXH6UYrlNOZWH29lj+7rs45FgH78/F/+ueHQ1NTdxHzTsV9jeVol/
	gfm8X0qFTbdUgDQHDGNNdmoNV8VVMSE3N+4C8yC17u66ZPOEgKxJ0+xlJsv8pntKX6Zczd
	OJfdRV/MjPMSP4qBNRlOOHLVpjV0CO0Lct2/ABOGypfHOdrIlrMgg6i162hFbXOAmaYTlX
	DzU/68aB7iw4SYW4IcdJ9BrG/nW48yb2dykRVchx7jFNY1rmeCG0L5ZNc010EcF5owt+My
	NDpr3ZymjeFURgi6I7VFNeAehhd+K6ikNZ/s42O5tFf4J5e/R/7ZsJC6jntevQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654782846; a=rsa-sha256; cv=none;
	b=NQf9IeyE0fh2gIIStaaCSE5zXb1FO+4kIVBmwv2zoUPq0HfNj6fMlvy0GuytujXA3QqcDz
	HiK7krSmkK+XgOeQEIxrBRwwS+KXwcRKB1HKk++NAXdrYZzUJLGhCfTnn599iktYehZGDn
	dnqmf5S9y55L6ey5Iv7tICuZzoMPxW0iJM28s5VyP3YpVgjkK3givyiCGwJOLFddCFQtq6
	NAFqPzmDSoIGuRuGQGuuiwIdwt5cvpnyzLQwRUer5DnrBxcuCJt41KC5OldPGJQk//Jf+H
	NLEdQqH4ysNW3zGQS+TYGXX5duJ+9aJ4ZiPxeifNyMRJZhG/Rb15mQSQXLVnzg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264574

            Bug ID: 264574
           Summary: FreeBSD-13.1 mountroot error 19 on Raspberry PI 4 UEFI
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: neukam-bugreport@gmx.de

Created attachment 234582
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D234582&action=
=3Dedit
This file is the putty output from the serial console while booting the
raspberry

Hello,

I am experiencing a "Mounting from ufs:/dev/ufs/FreeBSD_Install failed with
error 19." error on a raspberry pi 4 compute module board, when I boot into
https://github.com/pftf/RPi4 and from there boot the
FreeBSD-13.1-RELEASE-arm64-aarch64-memstick.img image.

It does not matter, whether the UEFI is on the integrated emmc or an sdcard=
 or
on a usb thumb drive, the error occurs. It does not matter whether the mems=
tick
image is on the emmc or an sdcard or an usb drive either.

I checked the following bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239876 but unlike this =
one,
my "List of GEOM managed disk devices:" is empty. Which I guess may be part=
 of
the problem.

I have referenced this problem here: https://github.com/pftf/RPi4/issues/219
because I am not sure whether this may be due to an error in the UEFI
implementation or Freebsd or a combination of both.

The RPI image of Freebsd 13.1 works without a problem, it is just the memst=
ick
version that doesn't work. (I did not use the RPI image together with UEFI,=
 but
on its own)

I have seen the same behaviour with 13.0

I hope someone has an idea how this can be fixed.

kind regards

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Jun 10 04:24:15 2022
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 EAA91842E5D
	for ; Fri, 10 Jun 2022 04:24:23 +0000 (UTC)
	(envelope-from gldisater@gmail.com)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d])
	(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 4LK7CB44Sgz4ShD
	for ; Fri, 10 Jun 2022 04:24:22 +0000 (UTC)
	(envelope-from gldisater@gmail.com)
Received: by mail-qt1-x82d.google.com with SMTP id k4so12009139qth.8
        for ; Thu, 09 Jun 2022 21:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :references:from:in-reply-to:content-transfer-encoding;
        bh=wr7I7EuZCJhTvsWiihtEUNbhGxNWWZcGUSBGS2+v7nI=;
        b=eIpBSZjGXOwtmsEz2u30TP5EzN58WixxX1N7qTKR7Tt40KstFMwD8KObK37yBZIWds
         LsmTrwK5bDEYIQ5cF8JNABUbyBgR3kEMc54lemdl+MmTW0ofYCtsA9yTOW+cs+gRmSZ7
         EJweoDiRGI8Usmegg3ZO7xnEsiARYWS1OuerpnsWsYS3U2xuicBiiI6UMq0rfr1Xb9/M
         H1qTAjL2jGTozgcvGBrgGOck4UNAmePg/xjp3s4gNH7lwfAOdryc0LnzXvMLf3JRudHv
         L9xe44eMDLVJYUy9HPWz74ktEXMmmwCAOPrro+NXGVIvfImV6b4ZBXBptJEa5SuWNQig
         EhaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:references:from:in-reply-to
         :content-transfer-encoding;
        bh=wr7I7EuZCJhTvsWiihtEUNbhGxNWWZcGUSBGS2+v7nI=;
        b=mFZ7SlPRFE7/NJXyNkoN2HJ+VeC9zCO/WKILQuVYM72k9v1aRRdZIseo/CKP5QKxEt
         Ml6ZIdEISr9h4Y1IsGJkOFIoBoEvzH823ydjyAnwgfKBEgairq9tp9IRLIIIL9+NXWSd
         ytW4WbfD+/MQfPATSjsSgHYL2WhHDmR2CRmlBq8+PsByU3KC+lRu5BNKbyhkD6FF0PIU
         d7Y257uLjL9HmZWHeoHoVyOtnQuzLZKz84r596fwsDb/CHKaZ+b3oRr87FbR/REbA364
         NTQ7MpjH1jCp+mRiWJmSAHM7mi30+VjoePItIhJ4KCJgPu/3PZ6FORb3l1XMavteYMOP
         Dg/A==
X-Gm-Message-State: AOAM531aSXPfUUjkIyqd6Ilra3vpiAfVgArN+7qm26B802IRbq4w6vDy
	SUQOZlWg9mcLM3ihO2K9YqQ4OHRJWr8=
X-Google-Smtp-Source: ABdhPJwXafVaQ8d+gPXLkSux2sng8faYcnxgbiPygiRpkrUHfmO5R9lscLkJwcVG+fdYmu0sxlZ//Q==
X-Received: by 2002:a05:622a:13d3:b0:305:1b8e:7c80 with SMTP id p19-20020a05622a13d300b003051b8e7c80mr1196232qtk.125.1654835056197;
        Thu, 09 Jun 2022 21:24:16 -0700 (PDT)
Received: from [192.168.1.201] (dhcp-198-2-84-7.cable.user.start.ca. [198.2.84.7])
        by smtp.gmail.com with ESMTPSA id l12-20020ac8148c000000b003050bd1f7c9sm3058380qtj.76.2022.06.09.21.24.15
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 09 Jun 2022 21:24:15 -0700 (PDT)
Message-ID: 
Date: Fri, 10 Jun 2022 00:24:15 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: FreeBSD/arm64 on MacOS/arm64 QEMU
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <3746ef0824223b7652f24b3d5d1f3e1e@freebsd.org>
From: Jeremy Faulkner 
In-Reply-To: <3746ef0824223b7652f24b3d5d1f3e1e@freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LK7CB44Sgz4ShD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=eIpBSZjG;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of gldisater@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=gldisater@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

kern.hz=100 in /boot/loader.conf

On 2022-06-09 4:43 a.m., Alex Samorukov wrote:
> Hi,
> 
> I found that running FreeBSD inside new M1 macbooks is stable and fast. 
> I did a small article about it in my blog: 
> https://smallhacks.wordpress.com/2022/06/09/booting-freebsd-13-1-arm64-on-macos-arm64-using-qemu/ 
> 
> 
> Only issue i found is that when the guest is active it is causing very 
> high CPU usage on the host, it seems that idle cycles from VM are not 
> passed to the host correctly. Anyone aware what could be tuned to fix that?
> 
> 
> 

-- 
--
Jeremy Faulkner

From nobody Fri Jun 10 05:28:08 2022
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 1CC5A8526C9
	for ; Fri, 10 Jun 2022 05:28:14 +0000 (UTC)
	(envelope-from samm@freebsd.org)
Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1])
	(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 "reindeer.net-art.cz", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LK8cs28n2z4ZLg
	for ; Fri, 10 Jun 2022 05:28:13 +0000 (UTC)
	(envelope-from samm@freebsd.org)
Received: by reindeer.net-art.cz (Postfix, from userid 65534)
	id 547265EF58; Fri, 10 Jun 2022 06:28:09 +0100 (BST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,KHOP_HELO_FCRDNS,
	SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no
	autolearn_force=no version=3.4.2
Received: from owl.net-art.cz (surikat.net-art.cz [IPv6:2a03:6920:0:10::101])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "owl.net-art.cz", Issuer "R3" (not verified))
	by reindeer.net-art.cz (Postfix) with ESMTPS id 43F075EEB8;
	Fri, 10 Jun 2022 06:28:08 +0100 (BST)
Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz)
  by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20)
  with ESMTPA id 1323233; Fri, 10 Jun 2022 07:28:08 +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
Date: Fri, 10 Jun 2022 07:28:08 +0200
From: Alex Samorukov 
To: Jeremy Faulkner 
Cc: freebsd-arm@freebsd.org
Subject: Re: FreeBSD/arm64 on MacOS/arm64 QEMU
In-Reply-To: 
References: <3746ef0824223b7652f24b3d5d1f3e1e@freebsd.org>
 
Message-ID: <4bf571b557cddf2d36d4a6bc24789232@freebsd.org>
X-Sender: samm@freebsd.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LK8cs28n2z4ZLg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:15e8:110:513c::1 is neither permitted nor denied by domain of samm@freebsd.org) smtp.mailfrom=samm@freebsd.org
X-Spamd-Result: default: False [-1.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[samm];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 NEURAL_SPAM_SHORT(0.50)[0.499];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> kern.hz=100 in /boot/loader.conf

Thank you, it helped a lot!

From nobody Fri Jun 10 07:41:01 2022
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 F0F09839B34
	for ; Fri, 10 Jun 2022 07:41:01 +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 4LKCZ53945z4lpQ
	for ; Fri, 10 Jun 2022 07:41:01 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4D10314987
	for ; Fri, 10 Jun 2022 07:41: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 25A7f1Fn041637
	for ; Fri, 10 Jun 2022 07:41:01 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25A7f1vp041636
	for freebsd-arm@FreeBSD.org; Fri, 10 Jun 2022 07:41:01 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 264588] [panic] panic: data abort with spinlock held on arm64
 ampere altra under kvm in OCI
Date: Fri, 10 Jun 2022 07:41:01 +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: dch@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654846861;
	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=0NXI3eLeyO2Ghi2s/9GYgP8+XCEr6AOIlwC6O23vQ0Q=;
	b=m8NHE1fwjXomPdIi7cN2wmv+KfwwtF15FsxfTFOgpglNuTmDmC+lH+CnLQJ4+nIfH3/DLi
	FaoMAnXibI6+P/29vrT0psTSpmT0SQTiRbO8DsLpgQosXPe4qK9FETG03NrdjJ8oGQWCkX
	FtPK09r79CHLOXpTyhyyqURfzrop+G0QhWhaIGpVnW/DALAltpX0priH6GV36N0ty2JF0o
	NiFylzkVUNUNMbLlKW/3fRvNbFaYD3iAvm1homHptsC36ZFnfvrMzZtjdD8MbA4JEZjYyc
	gvKPkAjbkVnlE8CvZz7DvnQfKCnPNOXt3Mog5TKMxaUf14jL8hph4JGkYfCmgw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654846861; a=rsa-sha256; cv=none;
	b=K1IDUul/Z97PQNflou2jNDEMiPoQyeZn2dtOBMWIWb27zne0wH0Sj3otlHpHcasQHP+7d7
	TYcv831G7nAukOI0eLTBT8ABrTpPKTbvU4sMxOUo+ZQJ8BmrhQnP+fQZAIqb84aODVbSR9
	SHqadvQ2h7BKM3jg8ASmF9HwXIQzmB6TUXorBhkwhOrTK9Z19dTvom9ZeFmuAB4KfkbNPF
	rjVEN5OibP+uMAVw5coZh2f3MuoD1F+4QVkdShrr6VXwYPe/I8UR2D9zfzC9vb9m5JBwd1
	2MVhwEaXfdRWbYP7Di/z2GX1uyCQ1leRxsFlCnmnGkkQ+ceWX+zO+6kQWkhtAw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264588

            Bug ID: 264588
           Summary: [panic] panic: data abort with spinlock held on arm64
                    ampere altra under kvm in OCI
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: dch@freebsd.org

Seeing these approx 9/10 boots.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CPU  0: ARM Neoverse-N1 r3p1 affinity:  0
                   Cache Type =3D <64 byte D-cacheline,64 byte I-cacheline,=
PIPT
ICache,64 byte ERG,64 byte CWG,IDC>
 Instruction Set Attributes 0 =3D 
 Instruction Set Attributes 1 =3D 
         Processor Features 0 =3D

         Processor Features 1 =3D 
      Memory Model Features 0 =3D 
      Memory Model Features 1 =3D 
      Memory Model Features 2 =3D <32bit CCIDX,48bit VA,UAO,CnP>
             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 Neoverse-N1 r3p1 affinity:  1
CPU  2: ARM Neoverse-N1 r3p1 affinity:  2
CPU  3: ARM Neoverse-N1 r3p1 affinity:  3
Release APs...done
WARNING: WITNESS option enabled, expect reduced performance.
ugen0.1: <(0x1b36) XHCI root HUB> at usbus0
uhub0 on usbus0
uhub0: <(0x1b36) XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
pass0 at vtscsi0 bus 0 scbus0 target 0 lun 0
pass0:  Fixed Uninstalled SPC-3 SCSI device (offline)
pass0: 300.000MB/s transfers
pass0: Command Queueing enabled
da0 at vtscsi0 bus 0 scbus0 target 0 lun 1
da0:  Fixed Direct Access SPC-4 SCSI device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 47694MB (97677312 512 byte sectors)
(da0:vtscsi0:0:0:1): READ(6)/WRITE(6) not supported, increasing
minimum_cmd_size to 10.
GEOM: da0: the secondary GPT header is not in the last LBA.
uhub0: 8 ports with 8 removable, self powered
panic: data abort with spinlock held
cpuid =3D 3
time =3D 2
KDB: stack backtrace:
db_trace_self() at db_trace_self
KDB: enter: panic
[ thread pid 18 tid 100120 ]
Stopped at      kdb_enter+0x44: undefined       f907c27f
db> bt
Tracing pid 18 tid 100120 td 0xffffa000078e4600
db_trace_self() at db_trace_self
db> th
[ thread pid 18 tid 100120 ]
kdb_enter+0x44: undefined       f907c27f

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Jun 10 13:14:27 2022
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 025E285E570
	for ; Fri, 10 Jun 2022 13:14:44 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.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 4LKLz63mzrz3G44;
	Fri, 10 Jun 2022 13:14:42 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=OUPcD8+eGEhZly0VtWf4n7PUcmlDQ5vKJgq5OiwVaMTLgE+fOkYqsKgn6AB/347Hat1tYOPFeSBoi7oXeTNLQhRKcLY6o5nfRaTTj88nxfuPLX2i98zk+El47hSgYmWDrVNzpjn7V1QRxouvi+1xDqPjjEB2sal2217zKDs/d47PDVvSE9A3eJgEGdN8a3KnaZeyTJWuAwGoY5+zc2jbBZpMN1I2Tp9+cRVkyH7kOEMkODbk4Nc00qGAa+vL+hBBkl5MRo1jTlxTjIph3HSidskCpDEkpsnumGFMaK4lIEGnFN/poobOC472p48Ux9LAxoLQEGp/rbohYe2YAqOOJA==
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=+ZAkbaDktIwnW/ZgWB+/Z+6w+gSBjKQ62HEqBzIn+xM=;
 b=nku1jSAq/cRmbdA/qUcsO3ZcE+sLBqWmDwVL1h1CvDhXkzzl0Y9c234RivkR0q/U9yAVcH+ATKWEK/sOL9gzT1RxUivS15ZwP8Uv/RuwUE3aI9DhIEed01udN94THD64lOyKdYKnxQXQ4Vv5d7vBroTW1TycWAcovnMvmQBTkD23lXveJ+LNkZrRHVtt5a2+IXn1WEY3W8cFqCBLzW+YIA1++ssFBEO6Bifch3RlnLbxsRj8Syxb+Eur0e7SkoMTTgx8ZTrTNdR0SqWdnvanq8KwfI+TY6Qen9vjthrNPF5hNtimr4Rjk9bR6dQi2Wxn1pnNCfijw542+tC/8pldAQ==
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=+ZAkbaDktIwnW/ZgWB+/Z+6w+gSBjKQ62HEqBzIn+xM=;
 b=AQSUmPzQ7pRnXOvfmuXUi8LqW5DotQnn+O3Y9QaleosQ/Zed7vsrHEU716Dt1jRJb6LKiQgzOAznVWYNGu538zF82OP0PpwshlmsyuNYZePEg2+H63tEfPIVkY+qT32HbQ7b7BwDmSS5BTNDRF2HxZ06jfx+B1Li2Tgq61fF/ZU=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by KL1P15301MB0417.APCP153.PROD.OUTLOOK.COM (2603:1096:820:24::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.3; Fri, 10 Jun
 2022 13:14:31 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9%4]) with mapi id 15.20.5353.007; Fri, 10 Jun 2022
 13:14:27 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , Andrew Turner
	, Li-Wen Hsu 
CC: Wei Hu 
Subject: bus_alloc_resource_any failing to allocate irq for vmbus in amd64
Thread-Topic: bus_alloc_resource_any failing to allocate irq for vmbus in
 amd64
Thread-Index: AQHYfMuQ20+KWgw86Uyk7M7UNJfNSw==
Date: Fri, 10 Jun 2022 13:14:27 +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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-10T13:14:27.001Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ede08d70-eb3f-4de9-8322-08da4ae325bf
x-ms-traffictypediagnostic: KL1P15301MB0417:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 MPmJ8pc3/bFGMb2pGKPML7Iohun3gA3JckFOYmlM2rZXLEdvCzHhnDruJbLYX/X4nX5Zti+rqADv37QMCdj6IIZfDdudzeANJ72H4QjlOLiACOy762TnkA1yyF4epibJIO7WZZMZBQHW5ZppjVBPQLJZUVaFB0fYWYqVcs/ll+OtajchjjD9kJoWwVlQN6jFhkOLPbINjRutBOOnuyVoGHf1HjQTSAb6/MJlxzkDlqZwO9ogJXkxZZRl5ckVRL+FW7P2tXwTS9p6eumfGEY3j6/3L/5ROTHvKrdW0WFfnKi8u/epKc1hbgTV0/cMuxgURhKnCC8mr/TgdlXwVRZDBjEyswFTxhmrubSqbzJprVrAwTD2ZiEwWa+G7ont/Vx5wOMrbBPvJBieWJybu77/mn7RxICDHHy6l3RtIMt+d8mkQvHoZSoauLu0DlaCYcbLlrU9JYaF1QU+uGQV+Ys8FpJ6efAcctQIPYtCtvfevbX4zOsUo36S6F5zMDqg5mg8bPlaeRF0sZByo3JJWaFPDD6zN42UcnqaPmqYinLweIOLIZjguCD05omBT/Dh9SXlMxSs2MjFg/KkHzehQCDCeoUQXjDWVWfKC9DXH3T8755pOlnZhiNfNtBRT2RfLE3w+00nwduYJVOkz7epQwIqPD3EGcrmZPvr6s11GXYeQ1l87FEQYUDp7qWA5w552Sh7eOe5dQciykZyAq5cvQdsHfs3Z/gwzdK00A4BEggAeq8mf8Iz4fLP39J1UjdZn8zd
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230013)(4636009)(366004)(451199009)(110136005)(26005)(9686003)(7696005)(6506007)(86362001)(55016003)(33656002)(71200400001)(316002)(10290500003)(2906002)(52536014)(38070700005)(450100002)(66556008)(66946007)(8990500004)(4326008)(76116006)(66476007)(66446008)(64756008)(8676002)(91956017)(508600001)(82950400001)(82960400001)(8936002)(107886003)(186003)(38100700002)(5660300002)(4744005)(122000001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?0mDNwznCtOrjTrOIzWHVsHG+pat5piXmC9e/R85GoIE7Ko36vcIOqKD1Lc?=
 =?iso-8859-1?Q?dDESIS88rvjZ1NMsIsModQ3ghLyLkfelvc+jYwUJbYGi224/RiEB1nl2Bt?=
 =?iso-8859-1?Q?VzmMf9M5TZF+6W/VlrScWLUEz3/ta8cqld7AnUp5ci7RCTBvIVD1zwqtUH?=
 =?iso-8859-1?Q?DW/Tqsx4ZwEg5K+hVjpwoAXEKGOyWbBszFnJv5dugjsD3aq/LUaAU/fHxd?=
 =?iso-8859-1?Q?alRPdP4IDCcbm1o3IdrE0aFXEgPre2ksZam3lslN/Ji5OkVqjW0rcCObI6?=
 =?iso-8859-1?Q?iPIcaui9atdqyYIISBYwJyLhNTbCa02dVOIaBAvD/s47tMb578Z5wgM2j3?=
 =?iso-8859-1?Q?GVExufxg+9e5UXNFm0IUDg6G87mlXvRgd6jJyfFl7rxlu0lCUaUvFkxIg+?=
 =?iso-8859-1?Q?ei7LYay0uwifEtdeaMYo61eKeyrxLZYvXq2yXxtLC+Ddskisv9zvQX6+Lc?=
 =?iso-8859-1?Q?G97DaQe0v/PrkA26w78b32ILq+a5AdKG2ywnJJBMcs8oKypYnd8BZ3PpFI?=
 =?iso-8859-1?Q?YeaN1YsNdowjXeKRRlgggXbhuum6apJpsIJH+KA6/H73kVlkdIhqVmcwud?=
 =?iso-8859-1?Q?G6JFyq1zCID3A6eOxEEJpJUAIuHlkGyvOfE9lrpN5+yxYJLQwCC141yxF6?=
 =?iso-8859-1?Q?Ll7zE691LXos4ZLO/ASqVZzsjSTeSLkVFDGnjkAxj7xkXqzrVCnU1RD1Vl?=
 =?iso-8859-1?Q?7GAxAL/XzRl0a8jPFQK9UtLhRt2EmnHNzNvvAcm/S9T+R14aTrsShET6BP?=
 =?iso-8859-1?Q?lAKSI5mD8iLG+kHTsD6Ttu/biu+xoyi8+6KvLyQA/fmeU9Krf/uSC8M3OL?=
 =?iso-8859-1?Q?wLg+gmvPG+cpsqXBSBD/a+FbxEdDxx+A6RdRhKUdc61ZTBv5e2xNP7xIwA?=
 =?iso-8859-1?Q?dO8mH81wZp8F0aNs0c7slboM+D2AW6OBRHW/06GeBCkUaFMqxqtikz4FCR?=
 =?iso-8859-1?Q?m1we7eEhXU9uB5ilYdLvNvLMLV3cytxx/xe64VVpzP8qIJ5uuNsL8QdRH0?=
 =?iso-8859-1?Q?2CoKyE2rh2608PMzVUch6mEWGeTD+6115YZoGX7/kHFJqeZE0RwnO3rSRR?=
 =?iso-8859-1?Q?xoHAVNDTsoP6Ma+cqp226ABw3FyYUgnMU3BwG7eJsH8R3xH/2g46I8KZDR?=
 =?iso-8859-1?Q?RDPgvANn5iHVauEJBlebYAAqg9D9RyI/SSSNGqF3pp48vsu2nPiJDtRtVU?=
 =?iso-8859-1?Q?1aQTiFbcnWZUwMMb1oK8COquUu70h/pnWJ94PwrJi7oFDE0pyMM/2fWw+7?=
 =?iso-8859-1?Q?V1FSQMd/HnktyTOdo/g0r7QmwyjfKqMpEdEc+irtlmk6Gj6MDchRsyFU5W?=
 =?iso-8859-1?Q?cMDmUiVjkuO+43NYSr1FucKZMTkufWKJznll9VfVdFzqUx46yMrViaV7aQ?=
 =?iso-8859-1?Q?WPfj6mhetfZfjQ1CK/vDpHBEn5ra0Z/6Aub4MzAuGvNfQYfRjMef3f6uJI?=
 =?iso-8859-1?Q?6/OmDOxhUcXjsoTjDR2YlrFUKa67ko/TViMIpHvYS1+qoDGVYXbW71gBr0?=
 =?iso-8859-1?Q?KOumoyw1/pRPJbsE0xPnKFKqU+pSr8ftA7GiXHDGHSHb7wCzLrlhl25f9V?=
 =?iso-8859-1?Q?GyNR7ptN58e8cQdHI2EUdZpz9pePcB4y6Ofep3Jd5cMud9kYxweCLKtV6j?=
 =?iso-8859-1?Q?mhmeDLd8RsYS5iBay9nIN3sk9uJjTyj+Y3fM8/5NFhKDFkeLxenTpYR8bt?=
 =?iso-8859-1?Q?UqvL4Wd+ZhUKetbOV/bduQUnN5QPrqKwq+XZCBbnrN6KRLfYhZNrtKrl4y?=
 =?iso-8859-1?Q?dijRsFfyB3jwMvmPlyQEl1bTI=3D?=
Content-Type: text/plain; charset="iso-8859-1"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: ede08d70-eb3f-4de9-8322-08da4ae325bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2022 13:14:27.7217
 (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: qMvAGD0Pir7rEvuGb0AtayszvSIXOKBGjVj61GIXAwL+xT9kj7QkPZE5QbFkR1A/8WH9Vej/e+0VWuPfHgWMwbwVYgnavFHffmTyPCWWRZY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0417
X-Rspamd-Queue-Id: 4LKLz63mzrz3G44
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=AQSUmPzQ;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.17 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N

Hi,=0A=
I am trying to use bus_alloc_resource_any() to allocate a irq line for vmbu=
s but it is failing.=0A=
=0A=
this is the patch :=0A=
=0A=
+ =A0sc->sc_vmbus_irid =3D 1;=0A=
+ =A0device_t parent =3D device_get_parent(device_get_parent(sc->vmbus_dev)=
);=0A=
+ =A0sc->sc_vmbus_ires =3D bus_alloc_resource_any(parent,=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 SYS_RES_IRQ, &(sc->sc_vmbus_irid), RF_ACTIVE|RF=
_SHAREABLE);=0A=
+ =A0 if (sc->sc_vmbus_ires =3D=3D NULL) {=0A=
+ =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could not allocate IRQ\=
n");=0A=
+ =A0 =A0 =A0 =A0 =A0 return (ENXIO);=0A=
+ =A0 }=0A=
+ =A0 error =3D bus_setup_intr(sc->vmbus_dev, sc->sc_vmbus_ires, INTR_TYPE_=
NET | INTR_MPSAFE,=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL,=
 vmbus_handle_intr_new, sc, &(sc->sc_vmbus_ihand));=0A=
+ =A0 if (error) {=0A=
+ =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "failed to setup IRQ\n")=
;=0A=
+ =A0 =A0 =A0 =A0 =A0 if (bus_release_resource(sc->vmbus_dev, SYS_RES_IRQ, =
sc->sc_vmbus_irid, sc->sc_vmbus_ires))=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could n=
ot release IRQ\n");=0A=
+ =A0 =A0 =A0 =A0 =A0 sc->sc_vmbus_ires =3D NULL;=0A=
+ =A0 =A0 =A0 =A0 =A0 return (error);=0A=
+ =A0 }=0A=
=0A=
What am I missing here? Any help would be greatly appreciated.=0A=
=0A=
Thanks & Regards,=0A=
Souradeep=

From nobody Fri Jun 10 13:16:32 2022
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 761A285E9F0
	for ; Fri, 10 Jun 2022 13:16:44 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2093.outbound.protection.outlook.com [40.107.255.93])
	(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 4LKM1R31mYz3G65;
	Fri, 10 Jun 2022 13:16:43 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UZta9GbXMlcMBGjCikHItHRbn7cioL9GM9EctdPPZYn0V2Ynhol81QA6vcfm6ArZAGAGdjNy/t/ejO0yUrKIJDoU3F1mHmONIQBWb/xiKsBdqiGCEJOvJ+aROAR9zmd2apN3rd8aa5DwNwl7Dxe82+XxZeZsPPGqbD3ZXLv0fmFfwYj+HnmvkIq36EQN4KHzsXTWaIHS4hSFu100NOYqwd+04X7rvwMaGGxP2lrmiZWbWTaPPpkFcpId2L3hL3RxKDNsKivCYxgLjfW0KC4mNFCp/XcpzffYA/1lSgmuPVJuJC4uTSWx+d9tk/SQZ4m0Kz3I5z10dDGkXsKmKw/cfw==
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=6idosPKX4aig8qq8qY/QKzyLiSqY/+M7QK8/wZ95kQo=;
 b=Y4btHnnvB6KydBPmiHZ8E9WzO4TUGDxfFay/uxvnGTPQpX4hVD1v9AKRbTx2Lj/BkIe25PmS9ykdM/9dQQFzGn1sHEHEdA8/Z5j/Hk78FWIXaWW3gIkCl7tkY8Oe/EDBLE9H3cRRbxhLXwGQjSb5rXW4td4NIuse64yw9s0DXfDajumM/FmhOSIMzovow1Y3WE1CQf5saxshPF2a0yu0MbgXJreL0syaTbS/OJMYivZ+0ATvZqeABRf5BrdDU8vw0rmv+hwfUI03ow3e0PJvA8QBfrjUzRWl+lIGcevPQDcuxJUCcBt0uuY50icBxRlJJNRIiiaZBj4x4IzERLqLqw==
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=6idosPKX4aig8qq8qY/QKzyLiSqY/+M7QK8/wZ95kQo=;
 b=OLf+wE/nLvdxhXgM5DZj3gauQ+ObjgO3PK/ug+Gf2Mwf9UxX1BK0W8QLi3tQNbt/wHgpp2M8qlaoaP4vp4L5o65e/eIkz3xDLuw+vImeGtJBIIL5oHm21rcLaAxivDQM//tAX50+XM3ZX/n6mhr1Tp68S8joufh7mHqQvyyFrDY=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by KL1P15301MB0417.APCP153.PROD.OUTLOOK.COM (2603:1096:820:24::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.3; Fri, 10 Jun
 2022 13:16:33 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9%4]) with mapi id 15.20.5353.007; Fri, 10 Jun 2022
 13:16:32 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , Andrew Turner
	, Li-Wen Hsu , Warner Losh
	
CC: Wei Hu 
Subject: Re: bus_alloc_resource_any failing to allocate irq for vmbus in amd64
Thread-Topic: bus_alloc_resource_any failing to allocate irq for vmbus in
 amd64
Thread-Index: AQHYfMuQ20+KWgw86Uyk7M7UNJfNS61Ins+b
Date: Fri, 10 Jun 2022 13:16:32 +0000
Message-ID:
 
References:
 
In-Reply-To:
 
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-10T13:16:31.983Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6f3c2ffd-2ea6-4682-033e-08da4ae37045
x-ms-traffictypediagnostic: KL1P15301MB0417:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 CtoR93zmFPlhQoYo+vAonVYp1zuZ2k1v4P/8n/4YwFjnd3O/HrXS1nypugx01DrJqVEJfU2z2NSc6RL7io3HnmpuS71hbIWD6Is9GtX3givHTTX96xHarAWE2t22nhHaFQ3vR8CbfRVLjkmJZgq78otKN9DgLTzsTsUzaA0+zdvlL0SuhlepsakSbcwIQH3pXAhTvQwP/wW8Txk3y6Tbuf+RSKF8HyhXUSOM7miOvp+CX2L1z+5eEbnWAc0mwE/zGT6rmP+u1FupEvvLftJpsUIp6RylXTQ2k2sWWWa0CsnJOCuCXY8OnUEMpkInob2RTs21dA7omZeSJNZgtpkPcVncmOziM4yCCnXydHiX9Bey3vRQx+A4HA8DgTcGadB4QuQmpw4/hKbPYbCuJAhEpvNFdMLYp5vfJjZ1yP9VySOaNgPq5kI2gT2GS2T9DT+iI+1O53+0MQ5j6IvOL8qmfYWq4K1ZsASrx5NWl1urMdSfhkCkf5bH9DoZ5pi8qB2olEd6TsOKEcGtX34g7U6w6HWcKPUQKruojqAqJDVc9nWd0XwvBGLahPCecJEtNEOnQciDuWXcU7KhyAJq8FGEqNusYb9UaX8xyT1AvbY+P/PHiU1SwZBpY/I1QAubkoRPzQu5OBO0kZY7wsv/z8ZcwAvcp0rDIMz7ogHpATql6y1DDYX5f7pp5M6WF6zimtI+cV8JJgEIXYna082S5JzjYkaev9ngxSE0Z8MNN6hFA+yyK0uwp90vKcRTCcAxEWQN
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230013)(4636009)(366004)(451199009)(110136005)(26005)(9686003)(7696005)(6506007)(53546011)(2940100002)(86362001)(55016003)(33656002)(71200400001)(316002)(10290500003)(2906002)(52536014)(38070700005)(66556008)(66946007)(8990500004)(4326008)(76116006)(66476007)(66446008)(64756008)(8676002)(91956017)(508600001)(82950400001)(82960400001)(8936002)(107886003)(186003)(38100700002)(5660300002)(122000001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?MCnsGz57hM3hGwlrZXGu/GiMyRLU+Fo/mj8Q1PJGp68Ncx+ESzJczNTmee?=
 =?iso-8859-1?Q?PmkC3O4l5LTRx0wzjEdilAwqRiimTimwTD2Q4iF6x6A0JYcd44uFAaAQPR?=
 =?iso-8859-1?Q?FZ/jeHBn4ai1cpJyUOMWDUiaWtzPCZevyNrcJrmL7iNNLQ/qt9uE6gLtze?=
 =?iso-8859-1?Q?cOT2HUbDA/g30oJHH3Zm+Ost+1pARdIhZTO78tC1kTqGUZB0DV5WbzrBZh?=
 =?iso-8859-1?Q?Qzaipm1Zp0CMR7C+lwvuM9r1ce6kZgwgeFa5xgBqzSvTflb4I/wb9q7cwe?=
 =?iso-8859-1?Q?FD8p3pjWc/Bk17O6qtDdJwSwn5WzoIctAy+glIwnHF4Ieq1V0Br0M2TJd0?=
 =?iso-8859-1?Q?zW375GHWuVregJTE44ZiTDE1qJyeMu4bltYk0PxfTW1hfHHfJXYzc4tXSQ?=
 =?iso-8859-1?Q?BOaMkOK9er+SC7n2xnraJl96doorV9otxv+e+bA7thgD7PuWV0FvntM/Mg?=
 =?iso-8859-1?Q?G7Y6WCSloLtEs87jU6WvNXj7YC7be1DLLFidWEJRqAthHrxyCEHwlzlvSO?=
 =?iso-8859-1?Q?TzhYGwVJINUjxCvP3RK1K8rKjMzdcuzKQayONZXdX0SBbluMH+oSeUzOsN?=
 =?iso-8859-1?Q?CZQtIAEWZGYezZ3cuK8pwLdTrcUJQdVTXMdgF0ie01p5Y95Br5lB1rxzyi?=
 =?iso-8859-1?Q?tC+DrBUfcqqpqAXdbn4DXWiiX9DEh9n5u5pgI7rimlCFKGWmSDc3q2z0vZ?=
 =?iso-8859-1?Q?ulzEpRiJ77Kabws3eeD7nF6EGmOFx39wkE0isQu8ff9zTrjVPw7fI3vR4w?=
 =?iso-8859-1?Q?PkWlK4lLZOJHmzubvbX3HzIxtJapdDBCwXmojshsARnwUEsH/JWWMvmfQU?=
 =?iso-8859-1?Q?B5O9MrFznOef6BcmTBVqYKUAxsDfpGXzcrV+02SVLSYnNk4mpnkG6rne1N?=
 =?iso-8859-1?Q?CQkmxeWAoxjsoSuaf7KlBuWu8qEVXOCouePxDih/eLXx0XaiBIXmJKEf4X?=
 =?iso-8859-1?Q?gC0Xswv/KANGT64HR8lDMJkowUp8P60E9Q6w1dHPJg1O/2COiKa3Ge3fxo?=
 =?iso-8859-1?Q?7I+wvHqbP+UpiFCsUmBRWha0ow9g6WOGQz+rD1sgIBvcCbcPbW9hTBLDYU?=
 =?iso-8859-1?Q?ogHXFo81i8ToAjEzARfqvSFfcrFBOMqf32002Yok/SvWyWuAv0I6CAU/ZL?=
 =?iso-8859-1?Q?Wds3IfrusSRYetZqSbjgNgGsFyADJalM27LZ69beLTH3lqYjbBtwCgNA7J?=
 =?iso-8859-1?Q?2ZtyMB78mI/3Gxx8X4bYAgS3DZVyPlXHFNp1Gmn1E4u1o40mMOwAcs/on0?=
 =?iso-8859-1?Q?NaNK9ALMCy6Lig4/mpxY64SjgSG9a4LLsEXW6XUycOB0Wbjj2nXEZS+gvg?=
 =?iso-8859-1?Q?mtoPIcvEjfLVfoyqI/KC7YdJJOnkWpEG2RxcA9Rmb2XbqPuvxFCfO7E0vO?=
 =?iso-8859-1?Q?DSMmGIXVDzMjcvt3VH297wMLKV1DQrV+almW/zM7ZuTw3aVhvM1KfkOe9x?=
 =?iso-8859-1?Q?cmsvkgO4L7nvCJPONEZUmL13DCky4GKaMVfEW/m7ohgpP6mVcMDSOOs0Ml?=
 =?iso-8859-1?Q?bYYlfLSTe6DJErKY4Xmuzpkwy1H7A+TyPVbQIqtwtHVwTFFvmjw7omzjBc?=
 =?iso-8859-1?Q?jk9GwJKZnag7+V1dfaub9furSuHjKlaTnwKfC3Lu0cjzQynlCXEujuynRf?=
 =?iso-8859-1?Q?zgHX5BrSkGLYfQj5oQfy9Lhr6MSPzeqg+fBVc1cJOCm561yqTYerAKvP50?=
 =?iso-8859-1?Q?l8aISg5aEpiiYAVbt8SmiJvJDVN0jifFypm2TBGSlbHLRqY3Lki7yi/TWJ?=
 =?iso-8859-1?Q?xzzCsp7HLfIgRF5mu3/wz5+XQ=3D?=
Content-Type: text/plain; charset="iso-8859-1"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3c2ffd-2ea6-4682-033e-08da4ae37045
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2022 13:16:32.7792
 (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: GYIRnbFl1LRP2UpZh3DWMMSGK73zG1FgLo2heOKygIaIuhaOWCXgzR+KosdmVpSLpSGu5sqyyPfzoz8GwY7Pfat4RJ6iF8A3P4QcMAFqoe4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0417
X-Rspamd-Queue-Id: 4LKM1R31mYz3G65
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="OLf+wE/n";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.93 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.93:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.995];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.93:from]
X-ThisMailContainsUnwantedMimeParts: N

+Warner Losh=0A=
=0A=
=0A=
Thanks & Regards,=0A=
=A0Souradeep=0A=
=0A=
=0A=
=0A=
From: Souradeep Chakrabarti =0A=
Sent: Friday, June 10, 2022 6:44 PM=0A=
To: freebsd-arm@FreeBSD.org ; Andrew Turner ; Li-Wen Hsu =0A=
Cc: Wei Hu =0A=
Subject: bus_alloc_resource_any failing to allocate irq for vmbus in amd64 =
=0A=
=A0=0A=
Hi,=0A=
I am trying to use bus_alloc_resource_any() to allocate a irq line for vmbu=
s but it is failing.=0A=
=0A=
this is the patch :=0A=
=0A=
+ =A0sc->sc_vmbus_irid =3D 1;=0A=
+ =A0device_t parent =3D device_get_parent(device_get_parent(sc->vmbus_dev)=
);=0A=
+ =A0sc->sc_vmbus_ires =3D bus_alloc_resource_any(parent,=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 SYS_RES_IRQ, &(sc->sc_vmbus_irid), RF_ACTIVE|RF=
_SHAREABLE);=0A=
+ =A0 if (sc->sc_vmbus_ires =3D=3D NULL) {=0A=
+ =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could not allocate IRQ\=
n");=0A=
+ =A0 =A0 =A0 =A0 =A0 return (ENXIO);=0A=
+ =A0 }=0A=
+ =A0 error =3D bus_setup_intr(sc->vmbus_dev, sc->sc_vmbus_ires, INTR_TYPE_=
NET | INTR_MPSAFE,=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NULL,=
 vmbus_handle_intr_new, sc, &(sc->sc_vmbus_ihand));=0A=
+ =A0 if (error) {=0A=
+ =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "failed to setup IRQ\n")=
;=0A=
+ =A0 =A0 =A0 =A0 =A0 if (bus_release_resource(sc->vmbus_dev, SYS_RES_IRQ, =
sc->sc_vmbus_irid, sc->sc_vmbus_ires))=0A=
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could n=
ot release IRQ\n");=0A=
+ =A0 =A0 =A0 =A0 =A0 sc->sc_vmbus_ires =3D NULL;=0A=
+ =A0 =A0 =A0 =A0 =A0 return (error);=0A=
+ =A0 }=0A=
=0A=
What am I missing here? Any help would be greatly appreciated.=0A=
=0A=
Thanks & Regards,=0A=
Souradeep=

From nobody Fri Jun 10 13:36:03 2022
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 CF7338333E4
	for ; Fri, 10 Jun 2022 13:36:18 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LKMS15Rkmz3LgM;
	Fri, 10 Jun 2022 13:36:16 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.175.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 9E7F32603D5;
	Fri, 10 Jun 2022 15:36:08 +0200 (CEST)
Message-ID: <57312f49-c6cf-868e-885d-c61ad8de7de1@selasky.org>
Date: Fri, 10 Jun 2022 15:36:03 +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:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: bus_alloc_resource_any failing to allocate irq for vmbus in amd64
Content-Language: en-US
To: Souradeep Chakrabarti ,
 "freebsd-arm@FreeBSD.org" ,
 Andrew Turner , Li-Wen Hsu ,
 Warner Losh 
Cc: Wei Hu 
References: 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LKMS15Rkmz3LgM
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [0.07 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 ARC_NA(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.85)[0.845];
	 RCPT_COUNT_FIVE(0.00)[6];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.53)[0.526];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.175.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/10/22 15:16, Souradeep Chakrabarti wrote:
> +Warner Losh
> 
> 
> Thanks & Regards,
>   Souradeep
> 
> 
> 
> From: Souradeep Chakrabarti 
> Sent: Friday, June 10, 2022 6:44 PM
> To: freebsd-arm@FreeBSD.org ; Andrew Turner ; Li-Wen Hsu 
> Cc: Wei Hu 
> Subject: bus_alloc_resource_any failing to allocate irq for vmbus in amd64
>   
> Hi,
> I am trying to use bus_alloc_resource_any() to allocate a irq line for vmbus but it is failing.
> 
> this is the patch :
> 
> +  sc->sc_vmbus_irid = 1;
> +  device_t parent = device_get_parent(device_get_parent(sc->vmbus_dev));
> +  sc->sc_vmbus_ires = bus_alloc_resource_any(parent,
> +                                                   SYS_RES_IRQ, &(sc->sc_vmbus_irid), RF_ACTIVE|RF_SHAREABLE);
> +   if (sc->sc_vmbus_ires == NULL) {
> +           device_printf(sc->vmbus_dev, "could not allocate IRQ\n");
> +           return (ENXIO);
> +   }
> +   error = bus_setup_intr(sc->vmbus_dev, sc->sc_vmbus_ires, INTR_TYPE_NET | INTR_MPSAFE,
> +                                   NULL, vmbus_handle_intr_new, sc, &(sc->sc_vmbus_ihand));
> +   if (error) {
> +           device_printf(sc->vmbus_dev, "failed to setup IRQ\n");
> +           if (bus_release_resource(sc->vmbus_dev, SYS_RES_IRQ, sc->sc_vmbus_irid, sc->sc_vmbus_ires))
> +                   device_printf(sc->vmbus_dev, "could not release IRQ\n");
> +           sc->sc_vmbus_ires = NULL;
> +           return (error);
> +   }
> 
> What am I missing here? Any help would be greatly appreciated.
> 
> Thanks & Regards,
> Souradeep

Maybe the IRQ is not sharable:

RF_SHAREABLE

--HPS

From nobody Fri Jun 10 15:13:46 2022
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 3839B8413CC
	for ; Fri, 10 Jun 2022 15:13:59 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020023.outbound.protection.outlook.com [52.101.128.23])
	(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 4LKPck1X1pz3pmk;
	Fri, 10 Jun 2022 15:13:58 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=bVrQz7spJkbxp/K8oCgHv0mV1GI8EgtKeOSTatZol8g0EO6wjbr45kWJgxZ7szCsWsWoOk8s5txrSWEmbkQB2cD4SCYMYOKsbUlJBXBaDxw1W+sf8tIXPNO6LdxAXHcsTj4px1N8ObmmWX4qZyGsq4josDWYVa75FTv/TOUokpfaX0WI/9dkQjrv/+TVBAaErv4524Zv4U/dqai+UPx/tHUFI1rH4/SDbMzx+8fch3YvBsVShonqC4K07FIUHu/peal+hWlT2aPYpxp+3y10Ct98RSUOO9w9xQPryy7ujwNuXCseITEmiMoUQNO/kg821mAz7TCo6aU6HBA0WGC5RQ==
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=ND/SePkwf7RUXLhcun/jUbWdxfPf6Ndhc8TJ6RE/RP4=;
 b=lpidHa0sp9P+ZvbOh/YMoBgEuGu+KrRzb7VB/ekiExbLQeLF/Um3vJoM6YzgxWu8fzo0fnNiZfA/Iy9pnRcd9hrBkjO5bjI2wJvj1X0nscUH2PwFq48Kru6o5IdJpEjdfm2wNntlQLoA0k/EP4qbbrEHlVvB1F0FM0TiOnZ4bIA02an0kIRqwjcB14vdZD4v/p8gUq+wdctfWV8Qwz2WIH1SkbJHBAQJ5OrF6jTJn7x8KAYykzy/UGfY+NYg2n9zUBVNaxjF14DNxMS8WhbAYRMe7tCiG+0RSNGvZ+7Tw85taaBiN2kRnq11xsMvnxPAF7yxNnAl6+ix1NG8WGcHGA==
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=ND/SePkwf7RUXLhcun/jUbWdxfPf6Ndhc8TJ6RE/RP4=;
 b=IDQAsKW/vsGCQeBuRwQMXl/jRcSlpBHvHCSm/6vmgu4QQ3uLfTjnSW/VmcWBq+535rTVpzmiKbSWvVLelqDKPM6yqcp3waqm01VzjPIm+BBU2ExNZxNAGfgdFlkXTx6MiUpswXtJLxHKrgEsyJv/i/L3BpInyCRxoMIVVdyrm1U=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by SI2P153MB0638.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fd::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.0; Fri, 10 Jun
 2022 15:13:47 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::ac6a:6a77:68b6:c5a9%4]) with mapi id 15.20.5353.007; Fri, 10 Jun 2022
 15:13:47 +0000
From: Souradeep Chakrabarti 
To: Hans Petter Selasky , "freebsd-arm@FreeBSD.org"
	, Andrew Turner , Li-Wen Hsu
	, Warner Losh 
CC: Wei Hu 
Subject: Re: [EXTERNAL] Re: bus_alloc_resource_any failing to allocate irq for
 vmbus in amd64
Thread-Topic: [EXTERNAL] Re: bus_alloc_resource_any failing to allocate irq
 for vmbus in amd64
Thread-Index: AQHYfMuQ20+KWgw86Uyk7M7UNJfNS61Ins+bgAAFqICAABpMYQ==
Date: Fri, 10 Jun 2022 15:13:46 +0000
Message-ID:
 
References:
 
 
 <57312f49-c6cf-868e-885d-c61ad8de7de1@selasky.org>
In-Reply-To: <57312f49-c6cf-868e-885d-c61ad8de7de1@selasky.org>
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-10T15:13:46.086Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: adfbfd64-9103-460c-df0e-08da4af3d0f9
x-ms-traffictypediagnostic: SI2P153MB0638:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 Ui+eKd8BwaKK2o0JcLo11L476ijzyJrhapsFQq50LiWl6/FLulJG5B3Ri9bU5evVcD0SRG3PB7uWakiEQNCtQxenMO+5VBXJe91HWP03gXDzc/1W208f4c7VGUhIQSOkNhjVUq9lraVIymBfHH5mfanXoaKrasWj4kWnV8/dFFVWmlUHHKbvcfy73bfp/wAFGKPhy0kMOL8EeEO2nOMEB4F/VKd9hqj8z/yt0L6cqdjd+C6hOT/8ZOj3IiKySaeE/yrDWH7CL12y9YFncCG/8VuAZv0iNHuC1jLzWL93uNZjhxXM9LsBVuinm4LXKjlXUQbD0P7XqO4fUPGBdZCHl8lXm3R1ceSPYo3uRbOthCE4uyXVvWtwKV5ujJmH8CUhwKs47QFvVcW3sZ3clTKB8kTroJlJmZil9AcNxYu2fLIwBaUNpuSfkjpCxiAOEe+2rN2iJz30CqDM/EIrP4/G+FBrtISODQb8xMCwwE0Ok6/JyQ6gUtkinSjSduWUa+ySBHRKsB9CZy20QQZj/Ae6yHwQaWk+VGBSPLV8Xt2Y7oFq3TVciMgXgMeVSQqUXaNNqlR1PBxmOxScCDiM77CGeVDrLCDlhknCzdYeDroOuVXkKpFBM9jpfvkrzAIOiY3NOoIIcEhsJz0I/vLxs3E9deVRkbHG4YOokzmSKbk+KX9FCuZ3GRLaQmdjkJLt1ckCXrgJjbXNJty0jJdINanb0b8pjizg+LNYPiumNexIu0bDbPPA2f5+bBY2OYqzzwUH
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230013)(4636009)(366004)(451199009)(8936002)(52536014)(38100700002)(10290500003)(5660300002)(8676002)(76116006)(122000001)(316002)(82950400001)(82960400001)(71200400001)(110136005)(508600001)(4326008)(38070700005)(64756008)(91956017)(26005)(66556008)(66476007)(66446008)(66946007)(86362001)(9686003)(6506007)(7696005)(53546011)(107886003)(186003)(55016003)(2906002)(33656002)(8990500004);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?attyZXKbuMd+Ry5rc4wxATB42FqK3R6cHTFlNW+64QsfQXpne8O+lxBZOo?=
 =?iso-8859-1?Q?hr1r6DvvHmUbiGxSbGtN1eFPaxn0/FcBGRa7UTbQOjGMfVpiyRMnJ5hY+9?=
 =?iso-8859-1?Q?10pMS00AexrZeCUYL22cHUJIHAmMKWS0aAHcEZ42C35S9qYrbc4KSkEDu5?=
 =?iso-8859-1?Q?9Ip83NqVaBi27L7impYLoYfH8IL3a/XKqSV49KnPXQS9dW1c2iKjqiTZ04?=
 =?iso-8859-1?Q?WeX8qb2vIojINQvR+ohJbw2eEWsFGPI8sbFiOPCl2z3/kw83h5pnHtG8Ta?=
 =?iso-8859-1?Q?tnhFo9W+sKXI4TeUJ/VXViID/rLgBCJzdlbhAO1nyCtXXFXRoMHfFv7OWF?=
 =?iso-8859-1?Q?63kYdwm9lkRjDVT21/Xf72nFs9qrShIQnGMEtoEOTGb9eiS9jgcI+lTyQB?=
 =?iso-8859-1?Q?tWbrQIILJB97ZDTsRxER2YVZmfoKmHNygXRghSLGDJ0r1OSNKUt7Kf8vZc?=
 =?iso-8859-1?Q?clPY9mce81pCHLf00e7Rc0Qxa6gbBsgFLvRbY4ae1aRlqjBjbsi8dsk67/?=
 =?iso-8859-1?Q?LX8HkO3PlMi1easegoY3MHrTYxdv+vLdrlNDy4J+hvUEtfTQreM4jUwyB4?=
 =?iso-8859-1?Q?SjJX24AkA0eM9ceR846a6Heo+IC7dptRE/huwdCAVABKiWqUiGfe3QqYbp?=
 =?iso-8859-1?Q?HOvbzxK1Y76LZRf+PP5kegiCbyfnfLz/soDMc7x2AyHX9zTB/KCh8BmOgw?=
 =?iso-8859-1?Q?wrHZkQFSZDrVQ7yCsV6t0cbuoyQ2YY04XvWAQ/mGlh0JOh7u1LBXGd7dUo?=
 =?iso-8859-1?Q?1qOT2s2ig48YOfgppY2b/ONkMQFF8q57CykzM8qWtn/Pct6BCzbgnv9Tc5?=
 =?iso-8859-1?Q?VtLG0cvuKoFc9cRsboZrVnHt5ztjM+ZAOzVhr2mkCQGJ3FKZ91t9/OeHJy?=
 =?iso-8859-1?Q?tSnqbUVf1Mp6I51FqtKZ8yiOHGKzKjCpAXoML5YH6q5sviuvE6do9OHVum?=
 =?iso-8859-1?Q?EWy/nk0ABgUgeGkLhxNQKAhom3tIpCjTHygUB4EssyDRrcEXabBKsnYUMa?=
 =?iso-8859-1?Q?lXQ5eTpHndLb1WGI8n4ngOCTfG9ux5UsE4zJFBOT3JPKB9bKlHZjPm4VkP?=
 =?iso-8859-1?Q?gawQe3ZckIjteBqPfRD+TYnXM07gXTEDj0uLX31cZ6RH/UyPDIOaHkIIgV?=
 =?iso-8859-1?Q?PmeY6Ny/USp90aZD1YCifAbigX9HtWaE1HRre24BjVDYF6WXnkUXIzwkGK?=
 =?iso-8859-1?Q?4G8n+kpLlkLyJ8Hm/tuxBSw/QLyRv9uncw4e71kTlOflr3x1iv6DQRXxmJ?=
 =?iso-8859-1?Q?mQDDnIoDeNDTYelpMjn2aNU2j97gwM9uO1V2OIZSIsZtE21mlTKsaW0MZU?=
 =?iso-8859-1?Q?wixm8I1GT0OFNJKNa2wENUwCuKw8LfcJlyOPJZdYDkpLpjqVqUsYnW/zkQ?=
 =?iso-8859-1?Q?6TvygYKWWtKPU8ypUqTWEsggpUQhB1RidyuHekRvDjV33NtT5NNA4qgPQT?=
 =?iso-8859-1?Q?MJvvIsBgaSej+Ba0kcecI88ur9y3mxPesxsWCyyJFLjPZX3gI6uXRmLlaE?=
 =?iso-8859-1?Q?y5oyZusSveVNU3FdI8hZoHBWOKUDPmyBX5tL44v4zEb5pHTkrbA0+dR+hO?=
 =?iso-8859-1?Q?YlShmwA4k/pp+aVnCf0qnH35QaDtRFFywRfSvAlppv0ntxj8bv163iDnOo?=
 =?iso-8859-1?Q?FgrruGvrMi76fC6izJ7dlkcb1eFDFC23206BnBbNwDxz0yc6Tn+Ik6+Cer?=
 =?iso-8859-1?Q?Zv2eIkXW5A+Zgo1Tl5VCfJCf/ZsSxLsz9sZl66gv4uDwj1FvO8zCbXAQOZ?=
 =?iso-8859-1?Q?Yc/2Km7HIjex8a+jcgGcZivg8=3D?=
Content-Type: text/plain; charset="iso-8859-1"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: adfbfd64-9103-460c-df0e-08da4af3d0f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2022 15:13:46.9422
 (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: ifmOT3vYBG0GZKuDDQsntnkKAzGySiwBvZrcaCTPUDmflzaeyGowrFF70NmyqhXtbSz/CcX+2rRpcn8TUNyDOXzNP5+uCRAyFEP2tBnZhbw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0638
X-Rspamd-Queue-Id: 4LKPck1X1pz3pmk
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="IDQAsKW/";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.23 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCPT_COUNT_FIVE(0.00)[6];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N

I have tried without RF_SHAREABLE as well, but it is failing allocate irq.=
=0A=
Also I have tried with sc->vmbus_dev, parent(sc->vmbus_dev) acpi_container,=
=0A=
grandparent(sc->vmbus_dev) acpi as dev. But it is failing.=0A=
=0A=
Thanks & Regards,=0A=
=A0Souradeep=0A=
=0A=
=0A=
=0A=
From: Hans Petter Selasky =0A=
Sent: Friday, June 10, 2022 7:06 PM=0A=
To: Souradeep Chakrabarti ; freebsd-arm@FreeBSD=
.org ; Andrew Turner ; Li-Wen =
Hsu ; Warner Losh =0A=
Cc: Wei Hu =0A=
Subject: [EXTERNAL] Re: bus_alloc_resource_any failing to allocate irq for =
vmbus in amd64 =0A=
=A0=0A=
On 6/10/22 15:16, Souradeep Chakrabarti wrote:=0A=
> +Warner Losh=0A=
> =0A=
> =0A=
> Thanks & Regards,=0A=
>=A0 =A0Souradeep=0A=
> =0A=
> =0A=
> =0A=
> From: Souradeep Chakrabarti =0A=
> Sent: Friday, June 10, 2022 6:44 PM=0A=
> To: freebsd-arm@FreeBSD.org ; Andrew Turner ; Li-Wen Hsu =0A=
> Cc: Wei Hu =0A=
> Subject: bus_alloc_resource_any failing to allocate irq for vmbus in amd6=
4=0A=
>=A0=A0 =0A=
> Hi,=0A=
> I am trying to use bus_alloc_resource_any() to allocate a irq line for vm=
bus but it is failing.=0A=
> =0A=
> this is the patch :=0A=
> =0A=
> + =A0sc->sc_vmbus_irid =3D 1;=0A=
> + =A0device_t parent =3D device_get_parent(device_get_parent(sc->vmbus_de=
v));=0A=
> + =A0sc->sc_vmbus_ires =3D bus_alloc_resource_any(parent,=0A=
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SYS_RES_IRQ, &(sc->sc_vmbus_irid), RF_ACTIVE|R=
F_SHAREABLE);=0A=
> + =A0 if (sc->sc_vmbus_ires =3D=3D NULL) {=0A=
> + =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could not allocate IR=
Q\n");=0A=
> + =A0 =A0 =A0 =A0 =A0 return (ENXIO);=0A=
> + =A0 }=0A=
> + =A0 error =3D bus_setup_intr(sc->vmbus_dev, sc->sc_vmbus_ires, INTR_TYP=
E_NET | INTR_MPSAFE,=0A=
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 NUL=
L, vmbus_handle_intr_new, sc, &(sc->sc_vmbus_ihand));=0A=
> + =A0 if (error) {=0A=
> + =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "failed to setup IRQ\n=
");=0A=
> + =A0 =A0 =A0 =A0 =A0 if (bus_release_resource(sc->vmbus_dev, SYS_RES_IRQ=
, sc->sc_vmbus_irid, sc->sc_vmbus_ires))=0A=
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(sc->vmbus_dev, "could=
 not release IRQ\n");=0A=
> + =A0 =A0 =A0 =A0 =A0 sc->sc_vmbus_ires =3D NULL;=0A=
> + =A0 =A0 =A0 =A0 =A0 return (error);=0A=
> + =A0 }=0A=
> =0A=
> What am I missing here? Any help would be greatly appreciated.=0A=
> =0A=
> Thanks & Regards,=0A=
> Souradeep=0A=
=0A=
Maybe the IRQ is not sharable:=0A=
=0A=
RF_SHAREABLE=0A=
=0A=
--HPS=

From nobody Fri Jun 10 15:25:44 2022
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 F207484367C
	for ; Fri, 10 Jun 2022 15:25:47 +0000 (UTC)
	(envelope-from danny@cs.huji.ac.il)
Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LKPtL6zm9z3sGl
	for ; Fri, 10 Jun 2022 15:25:46 +0000 (UTC)
	(envelope-from danny@cs.huji.ac.il)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128;
	h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From; bh=GHzxlY0z8wr66UG7/2lEl0ujXjb5Z4YMvBeIDNL5Ckk=;
	b=VeMsE95cfaw1lQD0z3NtLd4ig5Oo/wOx8P2Rcd+WNjR4cVHDXNU0XfWWaOPxUNchbR3wVdnC8A+qHbpYW09ZoHXT4rKxzOGjlV2jffOApunX/cI20Fxhnd7IdbM7wjbcq5rQqWUJcuW7jXdSA0DzTwm9Rt0tbvcK8sEZ22BzA0KwYOStuYaLtx9I2xazW28OiJzi8bqAVx3JoVOhQbxjspdswfwEPMzNEfTpbNwO+sj8S6WrHKroezxBb9oioWx/YDl6Pk5SrX9b8ZL9A6BPOpCZXFtmOpFU3Z6iTQpHAPonazkRIIkrT+zQQ143gvvOS72NCnAYyDGs9Kmw9TYJqA==;
Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple)
	by kabab.cs.huji.ac.il with esmtp
	id 1nzgW8-0008QN-MX
	for freebsd-arm@freebsd.org; Fri, 10 Jun 2022 18:25:44 +0300
From: Daniel Braniss 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_072397DA-2CF6-43A4-B06E-D405B2C569E0"
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 \(3696.100.31\))
Subject: h3/allwinner temperature
Message-Id: 
Date: Fri, 10 Jun 2022 18:25:44 +0300
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LKPtL6zm9z3sGl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=VeMsE95c;
	dmarc=pass (policy=none) header.from=huji.ac.il;
	spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il
X-Spamd-Result: default: False [-3.30 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128];
	 FREEFALL_USER(0.00)[danny];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[cs.huji.ac.il:+];
	 DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_072397DA-2CF6-43A4-B06E-D405B2C569E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

hi
any chance of getting it working on this little SBC?, I remember - long =
time ago, it worked but it was a hack
if I remember correctly.

i=E2=80=99m asking, because I just installed 13.1, and trying to compile =
pkg from ports, and it just hangs,
no panic, nada, just power cycle works.

danny=

--Apple-Mail=_072397DA-2CF6-43A4-B06E-D405B2C569E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

hi
any chance of getting it working on this =
little SBC?, I remember - long time ago, it worked but it was a =
hack
if I remember =
correctly.

i=E2=80=99m asking, because I just =
installed 13.1, and trying to compile pkg from ports, and it just =
hangs,
no panic, nada, just power =
cycle works.

danny=

--Apple-Mail=_072397DA-2CF6-43A4-B06E-D405B2C569E0--

From nobody Sat Jun 11 08:57:11 2022
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 1CEFD83FD33
	for ; Sat, 11 Jun 2022 08:57:19 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234])
	(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 4LKsCd6RFwz3pLg
	for ; Sat, 11 Jun 2022 08:57:17 +0000 (UTC)
	(envelope-from otacilio.neto@bsd.com.br)
Received: by mail-oi1-x234.google.com with SMTP id k11so2057240oia.12
        for ; Sat, 11 Jun 2022 01:57:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :cc:references:from:in-reply-to:content-transfer-encoding;
        bh=/dzrTv3kNS+RtWYb2rF6JyMAHreFYyCgDyX0CUBRkZo=;
        b=d0GJL9IXV2kXQuMi1DfPOKB5x0cTjp8SpprLpkmMm2AC6U52uKrX3fztD4oiNOaiCe
         11283TX+bOpsUERKU5OGSSzD9ge+a7cmg72w3zxyVeVFTps9jdqIpigly/azP6UXv5Hh
         O9MISQK7fxfQlfEieKxO8tkNaRDrJufBnsMxA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:cc:references:from:in-reply-to
         :content-transfer-encoding;
        bh=/dzrTv3kNS+RtWYb2rF6JyMAHreFYyCgDyX0CUBRkZo=;
        b=dD4RbhNXSTbENf1k+2mBX2BNLmdiv0c62YH4xM2TfbvNbfikPrFyxUZf/yUbnea2jt
         9gnmp9TggMCl2H7LPcOvDavI4VmeQZlncI+55c52gQfhlRr9Q9f+zidK41ADbXJ/gW+i
         tSPaYKyidbZyCvIIO1CmBV2jh0HJBARudXi+TCDKk0qdlr2n7dJCRGsPxP5n60eqOLBQ
         /cGf8iG1glGx+z2ejYVeMF/IPon3NWcRiC/AjpztvjLjfJFtDfv6imfaFjR4LWduvJUw
         b7yLFGQBEv4Fd6shNCWZYCWOKMhVcSLSnHJRJqWzwdb4M/ZHgBCj54X3u4faZkgCy2Et
         ibiQ==
X-Gm-Message-State: AOAM530ShuJXChnheXA9sXTfNkEIemnhuV047My/iimcwqeQ7tifIgvY
	9QucuSmtsSLpSBwB7a1Ug5HLUhkiZAVHuw==
X-Google-Smtp-Source: ABdhPJwHgHIjPcEw9tKanpl/fbh/RlGp3GcTUAmdQlwLtBsM5ZFXHRNduYZVgb+JTCW1VY12imxPjg==
X-Received: by 2002:a05:6808:1386:b0:32f:219c:bb2 with SMTP id c6-20020a056808138600b0032f219c0bb2mr558275oiw.146.1654937837018;
        Sat, 11 Jun 2022 01:57:17 -0700 (PDT)
Received: from ?IPV6:2804:29b8:5099:52c:378e:75f1:1e7e:4f18? ([2804:29b8:5099:52c:378e:75f1:1e7e:4f18])
        by smtp.gmail.com with ESMTPSA id m25-20020a0568301e7900b0060bf9d6c060sm678067otr.1.2022.06.11.01.57.14
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 11 Jun 2022 01:57:16 -0700 (PDT)
Message-ID: <62e9b445-5b59-9a61-a01f-a3f6624d407b@bsd.com.br>
Date: Sat, 11 Jun 2022 05:57:11 -0300
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; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Wrong number of CPUs detected on RPI3 and FreeBSD 13.1
Content-Language: en-US
To: greg@unrelenting.technology, Ronald Klop 
Cc: freebsd-arm@freebsd.org
References: 
 <8fcbebf4-60c3-0ccb-259b-3324b123245c@bsd.com.br>
 <1047394639.643.1654181685742@localhost>
 
From: Otacilio 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LKsCd6RFwz3pLg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b=d0GJL9IX;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of otacilio.neto@bsd.com.br designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=otacilio.neto@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[bsd.com.br];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsd.com.br:+];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::234:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


Em 05/06/2022 14:31, greg@unrelenting.technology escreveu:
> June 5, 2022 2:18 PM, "Otacilio"  wrote:
>
>> After some debug I found that this routine is returning -1:
>>
>> Someone can give-me a hint about the function of psci_callfn ?
> PSCI is an interface for calling into power management firmware.
> Just saying that *a* PSCI call failed is not informative, we really need the arguments of the call.
>
> I'm not sure what firmware you have on the SD card but armstub8 from
> https://github.com/gonzoua/rpi3-psci-monitor should support:
> PSCI_VERSION, PSCI_CPU_ON, PSCI_SYSTEM_OFF, and PSCI_SYSTEM_RESET.
> Which should be all the calls that FreeBSD ever does…


I have solved the issue following the procedure of this message. I think 
that the problem was the old firmware.

https://lists.freebsd.org/pipermail/freebsd-arm/2020-March/021430.html


Thanks a lot


From nobody Sun Jun 12 01:52:42 2022
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 B904B83112A
	for ; Sun, 12 Jun 2022 01:52:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4LLHlS3F0lz4jlW
	for ; Sun, 12 Jun 2022 01:52:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654998765; bh=vbTqG2eYanDW0aDADrJ6PdKPiWL5mVbgYW1rFUI7Yfg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KlEHvmA5mLtA4jBI8mqJrZ5DWeAc9mCbrDe7l4h1TcelURzhYkB8ZluIW7ZpdmBf1LWfDJ0SS9f8kYr0tXlvGB5O2pRnVqZcQt+DQV1pUupIaDxsxtbDgPiW+iKuIIbnk44OIG617NnDuzvLl/hyVc5Ea5VaqCDbt5JhR8xX7Sjo7AU0igWuLNQ04A07jDgkcRYCYZkJhXw0PbF1J1dZ6ZVAHf4xaAkw/TWJNIDgbSIxqgHG5vpxHg48j1FAaUj4/YLRsYYZHNuBYemm01sVpPOe/AqgAKvSrArTtzwE6FeA6hjSDsLIrCzJKM9v7ihQAOyafSMGk/x1/uHSFuTu4w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654998765; bh=KyNv3i4Y8Rq+CgQTfgKubGe7dcOOHXgaUPhVicTgHaO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MH5XZGWmWjBcDfR7zOaFM6GCevx0zpKVxv7z3A3BDdx7jHVa5+SeEKS70sPVVHJZ0LalNB61HeCV572/g14uArk1xIm4/vd/u8AZ1VZ+arMrgPmWHzUHXfDoysAY3zojQxSpjUFe5gS0uM3BZFEiolVVfRTBCY/eCM2fX5AALZ0HCBxE0OFyHuAWdl7lGvpOVWQZb/IBi1AoIGWvTxWjq3Bifn2iWgL0KM8fioZpULEiMjlgAJvmmW9+vPyTcPHjmvGPgZ9TRmuW6DvD0QdSSBsZSn8Lx492VNUthnP3VfPPP4DLjB7XEn5YX4+3SL11fHOlFezhf/V/Z301BwppiQ==
X-YMail-OSG: u6iuUjUVM1nB9M9F7n1yIKiJ_ij.SSPD3B2eBOg1tBkfAb.OiIaTKsJrnQnZjsf
 JuM.0pVhHrA0pVTCZQhsJ4nuEr3vPVUBtqua9MKk4gvGY1cCMmOvufyEN57Iam.i8Jc3iwc31f2F
 ux_YjjGV69BbHwhdCuSxiFqOFsEX4fWGVmCuE0k7iY.gbRwthknYRNQnoZg_jDjppNYpyk4eNDft
 sLbPWXY6o_iR0X1NGuZKwoFJNFku7B19gXe7Vo0d4LzyRltuD8JZtiQlSGUk5RGLiuQeVxyBriMS
 lVQCgC8aS.cFVfZwfrJE2kTSt7mwr8QXOQU.nlspdsNEutdfgYuYthFJZ7TT1ZWcHkxBKjD_7_1_
 0jsV011BVcbFMNq3nrk4gAmeJZw6UgLYCAKf8hb5vyTNKbvnz8Jj535HlfNwrDN.6ig.I4kAPB42
 WBtJFE3VxGHNc0UH7KBxcbCdP7lYBOkX.blCGIV.Nd8P.x9tJDNdp4MR9M8hIl.jAcXcZIbdd83Q
 Y65IQOaGZJUktwxSo1Mf_UoK9okFBtsQfhXGx2wwNpe_fSEj7md1xtib0ejRnhdzxep2hc9br5Vw
 rn4BzHcw8M0SITfJ5tOngC8IR9yfPAR6er_5POLuMyZaUY1_JQfj5cOHAes_C3T5hu2_g4uQ1G3p
 afrIoVPJblSCiOxYigx7sPB_pY7Ur6c9hfXlEUB85BXiwm2sxo4L37t_PflEd1.43ySSnMTRKP1l
 rRmhBQ5fp7k8uwxqA0l_sdR6xcPiI44DMMYS1qZ2PaQ4.JOz.ATizbCCYWdd1YpHsWcqdCERElQE
 jOvlI.lQF3JhckYYryasVBfddd5DEZR.O0ZT4TLXYrSOPp7ReoIJqV203SY0qM5keitvXFOJxihi
 weDwh9XHSa70jBiYQEo5RmXH3FsDFtzLwNT_Zx0hRW_ptc993UVUkYLCCmcAJKGY1FPO7IWjgbnu
 C3Z.2FWUdkw.WR5BkrXPgi3fwly8Sg39NpIOh3Xm8Cx7n7ozmO1EYvBIktAqUWt_CcJr9mWpGbKK
 rcj4ScA9b5MrIWjifGyrzlQI51p_NZj6ORFbLkweGpnCq2r01sU9wPYk7Jr2sdiaXtZQN_uvXgap
 kM5Yb_HMaQR.K.NXtdiwprJgp8tZBjITNnMHyL6yeRxt7Ra01zShDagNO7yXciw.fKK8wS699OZa
 DiYTcicI1Yf3rjKIBDpOsmHCFxoBfs159B9sH9uT5vot4tC7TlYZknvA1VTRq2TUjNOjDlKwouVb
 Z.I8KAnBdYvEJntkFlwGGc48NDSbhkd0yj181gWXZs0iLS4sIRzLPjXd5dWPoBWiQq7BZ4jyIL8G
 iZ4MdkSOhTOyuk02.BxHk79awoZAZoWi5UtklaMRyp5DvMCuAHD29BI91iPwrUkDtYfT4zrM.78M
 RQg9BFiBfVBExLa9GRfJl6wHOgQYZC5o1Z7xIkDQIKt7t.tNKSKBYmkLvFWMos6R9QbbrEqz390.
 1QqKuENa69NFK5Bh_zlwwuSlxFmJFynsOa9Zsv7FysYnZ54S7dDU1DjB41Cgij5d9.Nj69qpQRbM
 icxwXyZ5.kAjRbmxr30jBMJHXsSsvMSvPJ7WVe4vTzdMsmx3h.JNGF.m3Z9sOoR5aW.rNJn5RV6m
 ddIVaHum_GATcvF_qjBjXO6QP762p9WBwQnU2IGaLlr2c2V4RI_cx3IchM7SIMo.dC5ERpNc72kM
 Poev1JcrMgGjmLa4PXunghFpUCvKxX0wXqDt15P7Rmr0OCuUOCb2pspGhhWvPInhi69FTS3NiqZF
 MJyL1OcUTPI0EAjCes23PzljoiEMvK.xgPBeQ7rAv5x4WDYnjJTwmKKuL_lfW8PMhRww2YBaySe5
 _N3KdZZZKha6EPFO7T6TERsuqa_.Pq57_39tlXAhZqUQ4ZtsfCIiEs5wIoxvy6IR3oOnSYTojq9y
 RLsJMYQs3QgbQcUyfhH1_H52DK0oEJeJcUpmwVayOymI.4gprpzOcIYi4fh4io3munBf76VUHWsL
 ljbhbdGbAJNLU6Ws.ns9hbEJiangn3dsymqeYPqbM5dmTfYr6jpzh46cjTwJw9XGdfwTdndDC2dM
 bmM__cKluhsGh2Vt1z7y2ub9ELKCzQirT29J.7hqxSuRJrSB5S89.YsM3hbTdbokKTyZv7fpSHO4
 ul3zjjoqpNWzgaXtfAic7CQfXs9bjHPTEWssIj6lsyD5g3ecsa33pnLYH4PFYTPx3UMED56_Cy2R
 iP8rD5Rfxb29TTvO.9x6SA1sUPKfk2RhkHFpKnTuXmce8fIBNgMBJhFim8OBMwf6BaJr3KypVaOK
 a6l13isDlnuWXQGww0phCaoafLoeF1F2dkyI.Yr4lhMVfKOV6pnfnv1YJ5syKhzllwiUxyeW6pyr
 uYsZPKWriVNzNGpFSbCspaw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Jun 2022 01:52:45 +0000
Received: by hermes--canary-production-gq1-54945cc758-dgl4g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2889207da480926e18aa97eb936ab34e;
          Sun, 12 Jun 2022 01:52:42 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220602045202.GA44686@www.zefox.net>
Date: Sat, 11 Jun 2022 18:52:42 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LLHlS3F0lz4jlW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KlEHvmA5;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.89 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.61)[0.606];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

There was another UFS/FFS superblock integrity-check fix today.
Time to try again?

The fix was . . .

The branch main has been updated by mckusick:

URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D800a53b445e7eb113ba193b1ac986312=
99178529

commit 800a53b445e7eb113ba193b1ac98631299178529
Author:     Kirk McKusick 
AuthorDate: 2022-06-11 18:04:19 +0000
Commit:     Kirk McKusick 
CommitDate: 2022-06-11 18:05:14 +0000

    Bug fix to UFS/FFS superblock integrity checks when reading a =
superblock.
   =20
    One of the checks was that the cylinder group size (fs_cgsize)
    matched that calculated by CGSIZE(). The value calculated by =
CGSIZE()
    has changed over time as the filesystem has evolved. Thus comparing
    the value of CGSIZE() of the current generation filesystem may not
    match the size as computed by CGSIZE() that was in effect at the
    time an older filesystem was created. Therefore the check for
    fs_cgsize is changed to simply ensure that it is not larger than
    the filesystem blocksize (fs_bsize).
   =20
    Reported by: Martin Birgmeier
    Tested by:   Martin Birgmeier
    MFC after:   1 month (with 076002f24d35)
    PR:          264450
    Differential Revision: https://reviews.freebsd.org/D35219
---
 sys/ufs/ffs/ffs_subr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys/ufs/ffs/ffs_subr.c b/sys/ufs/ffs/ffs_subr.c
index f25a6cba12f4..3e31746c2cfc 100644
--- a/sys/ufs/ffs/ffs_subr.c
+++ b/sys/ufs/ffs/ffs_subr.c
@@ -385,7 +385,7 @@ validate_sblock(struct fs *fs, int isaltsblk)
 		roundup(howmany(SBLOCKSIZE, fs->fs_fsize), fs->fs_frag) =
||
 	    fs->fs_iblkno !=3D fs->fs_cblkno + fs->fs_frag ||
 	    fs->fs_dblkno !=3D fs->fs_iblkno + fs->fs_ipg / INOPF(fs) ||
-	    fs->fs_cgsize !=3D fragroundup(fs, CGSIZE(fs)))
+	    fs->fs_cgsize > fs->fs_bsize)
 		return (ENOENT);
 	if (fs->fs_csaddr !=3D cgdmin(fs, 0) ||
 	    fs->fs_cssize !=3D


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun 12 21:00:10 2022
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 CB9AE833099
	for ; Sun, 12 Jun 2022 21:00:11 +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 4LLnCH1XZ2z3nlY
	for ; Sun, 12 Jun 2022 21:00:10 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 C046C54B
	for ; Sun, 12 Jun 2022 21:00:10 +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 25CL0ARm096555
	for ; Sun, 12 Jun 2022 21:00:10 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25CL0AP2096554
	for freebsd-arm@FreeBSD.org; Sun, 12 Jun 2022 21:00:10 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202206122100.25CL0AP2096554@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, 12 Jun 2022 21:00:10 +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="16550676108.DcCDD09E.95617"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655067611;
	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=cko1C1y9mTAC0vb66h7pMiRQGBi20jvIZP87+K9WDYQ=;
	b=E9LSXR1hFgf1VzJ/OjB7G7F+PObe8HR5LzVv9jzL6qvvyMTucMihj0H8ptSTe1ohgmENVm
	umJVTTJmJu+IJcGd/8wWgUzH1qmjouJoOTzEg9hpWaFSgXOyNNRKZCPY4pbvmoLpFe4sYU
	XD/1W0G4d96uznrF3nSV3FOv9SOWfZJalzJcKN3Gq/ZSI6ndeFzx6NiRLuuR/bEvaVAZPq
	GcViQETLGQNHL0JAqU0fwYmYYzY5SvuUned8uBUPask6UFi82WNIG18IsNjCo53BoZxvLm
	9pr2hi9XFbG0TL5/D1ohH3aHTMJPYlq7xPBgmBCpvdJQn14XKuNAl4w4wNdAuA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655067611; a=rsa-sha256; cv=none;
	b=XYaA7MG+luGjnYB73PiXSnFfwFj2lzwOwoQqnWL/kci22u48euiGFByi/1H/iV+ubT8WG+
	EmfNWjULjK4wEWWD7sfQ7Ka7BoocdHiJZn3kQ/+w5dTOUiGhNcrB/fTLzcA79GKwDiiFtp
	FkUTVvJnwr0fV4vOZJuDDaOZ7yQWrID4XlBD7VN+/AKA7gnlbFqu313l9WEzT3c4H0rm2n
	idAv8WAOxSFELVcH7NQR9z6EAPa8BETEm3QMhMw9y5tvKlvD9/+wxLazb6MnIYyShJoVVA
	Hn+w9+yvTnANzKs6YLvC3ave6k6KDLtPa75uSYphmkRiM3lgZaVsm3CMZVBk0w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16550676108.DcCDD09E.95617
Date: Sun, 12 Jun 2022 21:00:10 +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.

--16550676108.DcCDD09E.95617
Date: Sun, 12 Jun 2022 21:00:10 +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.


--16550676108.DcCDD09E.95617--

From nobody Mon Jun 13 15:33:25 2022
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 A0DFA850E9D
	for ; Mon, 13 Jun 2022 15:33:34 +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 4LMFvx3fxzz4ZsC
	for ; Mon, 13 Jun 2022 15:33:33 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25DFXPUl012665
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 13 Jun 2022 08:33:25 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25DFXPAc012664;
	Mon, 13 Jun 2022 08:33:25 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 13 Jun 2022 08:33:25 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220613153325.GA12588@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
 <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@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: <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
X-Rspamd-Queue-Id: 4LMFvx3fxzz4ZsC
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [2.06 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_MEDIUM(0.90)[0.899];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(0.27)[0.265];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Jun 11, 2022 at 06:52:42PM -0700, Mark Millard wrote:
> There was another UFS/FFS superblock integrity-check fix today.
> Time to try again?
> 
> The fix was . . .
> 
> The branch main has been updated by mckusick:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=800a53b445e7eb113ba193b1ac98631299178529
> 

There still seems to be something wrong. It looked like git picked up the
change, but after a build/install cycle I'm still seeing:

.....
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0s2a
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> ufs:/dev/da0s2a
Trying to mount root from ufs:/dev/da0s2a []...
Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.

As earlier, hitting [enter] at the mountroot> prompt starts the debugger.

Booting a kernel from main-n255816-e26ef41f799 goes straight to single-user:

OK boot kernel.0529
Loading kernel...
/boot/kernel.0529/kernel text=0x2a8 text=0x82ccb0 text=0x24c4a4 data=0x1b9f38 data=0x0+0x34e000 syms=[0x8+0x132f18+0x8+0x15ac23]
Loading configured modules...
/boot/kernel.0529/filemon.ko text=0x1867 text=0x19b8 data=0x510+0x20 syms=[0x8+0xd38+0x8+0x7ea]
/boot/kernel.0529/umodem.ko text=0x20e0 text=0x1360 data=0x6d8+0x4 syms=[0x8+0xee8+0x8+0xb46]
/boot/entropy size=0x1000
/etc/hostid size=0x25
Using DTB provided by EFI at 0x7ef5000.
EFI framebuffer information:
addr, size     0x3eaf0000, 0x10a800
dimensions     656 x 416
stride         656
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
---<>---
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 compliance
Copyright (c) 1992-2022 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-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 PDT 2022
    bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 14.0.3 (https://github.com/llvm/llvm-project.git llvmorg-14.0.3-0-g1f9140064dfb)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 656x416
module firmware already present!
KLD file umodem.ko is missing dependencies
real memory  = 993984512 (947 MB)
avail memory = 944148480 (900 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
MAP 39f34000 mode 2 pages 1
MAP 39f38000 mode 2 pages 3
MAP 39f3c000 mode 2 pages 4
MAP 3b350000 mode 2 pages 16
MAP 3f100000 mode 0 pages 1
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
lintc0:  mem 0x40000000-0x400000ff on simplebus0
intc0:  mem 0x7e00b200-0x7e00b3ff irq 39 on simplebus0
gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 6 on simplebus0
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
usb_nop_xceiv0:  on ofwbus0
bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on simplebus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 9 on simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e2041ff irq 11 on simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
iichb0:  mem 0x7e804000-0x7e804fff irq 19 on simplebus0
bcm283x_dwcotg0:  mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0
usbus1 on bcm283x_dwcotg0
bcm_dma0:  mem 0x7e007000-0x7e007eff irq 23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0
bcmwd0:  mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023 on simplebus0
bcmrng0:  mem 0x7e104000-0x7e10400f irq 40 on simplebus0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff irq 48 on simplebus0
mmc0:  on sdhci_bcm0
gpioc1:  on gpio1
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.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 656x416(656x416@0,0) 32bpp
fb0: fbswap: 1, pitch 2624, base 0x3eaf0000, screen_size 1091584
pmu0:  irq 0 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
gpioled0:  on ofwbus0
gpioled0:  failed to map pin
lock order reversal: (sleepable after non-sleepable)
 1st 0xffff000000c49aa0 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298
 2nd 0xffffa00000dc1c10 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 0xffff0000004c9024 at witness_checkorder+0xadc
#1 0xffff000000464638 at _sx_xlock+0x7c
#2 0xffff0000007e1e3c at rpi_fw_gpio_pin_set+0xe8
#3 0xffff0000001c9378 at led_create_state+0x158
#4 0xffff0000001950ec at gpioled_attach+0x290
#5 0xffff000000494328 at device_attach+0x3f8
#6 0xffff000000493e98 at device_probe_and_attach+0x7c
#7 0xffff0000004961e4 at bus_generic_new_pass+0xfc
#8 0xffff000000496194 at bus_generic_new_pass+0xac
#9 0xffff000000496194 at bus_generic_new_pass+0xac
#10 0xffff00000049110c at bus_set_pass+0x4c
#11 0xffff0000003e2ab0 at mi_startup+0x1fc
#12 0xffff0000000008b8 at virtdone+0x7c
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9470 at witness_debugger+0x5c
#1 0xffff0000004ca66c at witness_warn+0x400
#2 0xffff0000006f8224 at uma_zalloc_debug+0x30
#3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
#4 0xffff00000042e230 at malloc+0x94
#5 0xffff0000007d70a8 at bcm2835_firmware_property+0x44
#6 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
#7 0xffff0000001c9378 at led_create_state+0x158
#8 0xffff0000001950ec at gpioled_attach+0x290
#9 0xffff000000494328 at device_attach+0x3f8
#10 0xffff000000493e98 at device_probe_and_attach+0x7c
#11 0xffff0000004961e4 at bus_generic_new_pass+0xfc
#12 0xffff000000496194 at bus_generic_new_pass+0xac
#13 0xffff000000496194 at bus_generic_new_pass+0xac
#14 0xffff00000049110c at bus_set_pass+0x4c
#15 0xffff0000003e2ab0 at mi_startup+0x1fc
#16 0xffff0000000008b8 at virtdone+0x7c
uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9470 at witness_debugger+0x5c
#1 0xffff0000004ca66c at witness_warn+0x400
#2 0xffff0000006f8224 at uma_zalloc_debug+0x30
#3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
#4 0xffff00000042e230 at malloc+0x94
#5 0xffff000000742d88 at bounce_bus_dmamem_alloc+0x50
#6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494328 at device_attach+0x3f8
#12 0xffff000000493e98 at device_probe_and_attach+0x7c
#13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
#14 0xffff000000496194 at bus_generic_new_pass+0xac
#15 0xffff000000496194 at bus_generic_new_pass+0xac
#16 0xffff00000049110c at bus_set_pass+0x4c
#17 0xffff0000003e2ab0 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 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9470 at witness_debugger+0x5c
#1 0xffff0000004ca66c at witness_warn+0x400
#2 0xffff0000006f8224 at uma_zalloc_debug+0x30
#3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
#4 0xffff00000042e230 at malloc+0x94
#5 0xffff000000742dd8 at bounce_bus_dmamem_alloc+0xa0
#6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494328 at device_attach+0x3f8
#12 0xffff000000493e98 at device_probe_and_attach+0x7c
#13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
#14 0xffff000000496194 at bus_generic_new_pass+0xac
#15 0xffff000000496194 at bus_generic_new_pass+0xac
#16 0xffff00000049110c at bus_set_pass+0x4c
#17 0xffff0000003e2ab0 at mi_startup+0x1fc
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
stack backtrace:
#0 0xffff0000004c9470 at witness_debugger+0x5c
#1 0xffff0000004ca66c at witness_warn+0x400
#2 0xffff0000006f8224 at uma_zalloc_debug+0x30
#3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
#4 0xffff00000042e230 at malloc+0x94
#5 0xffff000000742e60 at bounce_bus_dmamem_alloc+0x128
#6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
#7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
#8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
#9 0xffff0000001c9378 at led_create_state+0x158
#10 0xffff0000001950ec at gpioled_attach+0x290
#11 0xffff000000494328 at device_attach+0x3f8
#12 0xffff000000493e98 at device_probe_and_attach+0x7c
#13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
#14 0xffff000000496194 at bus_generic_new_pass+0xac
#15 0xffff000000496194 at bus_generic_new_pass+0xac
#16 0xffff00000049110c at bus_set_pass+0x4c
#17 0xffff0000003e2ab0 at mi_startup+0x1fc
armv8crypto0: CPU lacks AES instructions
Timecounters tick every 1.000 msec
usbus1: 480Mbps High Speed USB v2.0
iicbus0:  on iichb0
iic0:  on iicbus0
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmcsd0: 64GB  at mmc0 50.0MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
Trying to mount root from ufs:/dev/da0s2a [rw]...
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
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
WARNING: WITNESS option enabled, expect reduced performance.
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1 CAM
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:71:46:4e
Root mount waiting for: usbus1 CAM
ugen1.4:  at usbus1
uhub2 on uhub1
uhub2:  on usbus1
uhub2: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1 CAM
Root mount waiting for: usbus1 CAM
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:0:0: Attached to scbus0
ugen1.6:  at usbus1
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
umass0: detached
Root mount waiting for: CAM
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:0:0: Attached to scbus0
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
Warning: no time-of-day clock registered, system time will not be set accurately
Dual Console: Serial Primary, Video Secondary
Setting hostuuid: 30303030-3030-3030-3064-626136386435.
Setting hostid: 0x5cd40a6a.
Starting file system checks:
Cannot find file system superblock
Cannot find file system superblock
Warning! Some of the devices might not be available; retrying
Restarting file system checks:
Cannot find file system superblock
Cannot find file system superblock
Unknown error 3; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
2022-06-13T08:05:20.701056-07:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh: 
root@:/ # uname -a
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 PDT 2022     bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
root@:/ # 
root@:/ # fsck
Cannot find file system superblock
Cannot find file system superblock

LOOK FOR ALTERNATE SUPERBLOCKS? no

root@:/ # 
root@:/ # fsck -y
Cannot find file system superblock
Cannot find file system superblock

LOOK FOR ALTERNATE SUPERBLOCKS? no

Indeed, it looks as if the -y option of fsck is now gone.....
Yet, somewhat astonishingly:


root@:/ # exit
Setting hostuuid: 30303030-3030-3030-3064-626136386435.
Setting hostid: 0x5cd40a6a.
Fast boot: skipping disk checks.
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/mach/CORE /usr/local/llvm10/lib
Setting hostname: www.zefox.org.
Setting up harvesting: [CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
lo0: link state changed to UP
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP
Starting Network: lo0 ue0.
lo0: flags=8049 metric 0 mtu 16384
	options=680003
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
	options=80009
	ether b8:27:eb:71:46:4e
	inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
	media: Ethernet autoselect (100baseTX )
	status: active
	nd6 options=29
Starting devd.
Autoloading module: uftdi.ko
uftdi0 on uhub1
uftdi0:  on usbus1
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add net default: gateway 50.1.20.1
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Updating motd:.
Creating and/or trimming log files.
Updating /var/run/os-release done.
Starting syslogd.
Clearing /tmp (X related).
No core dumps found.
Setting date via ntp.
13 Jun 08:22:48 ntpdate[875]: step time server 86.3.245.8 offset -24453.100209 sec
Mounting late filesystems:.
Starting powerd.
Starting sendmail.
Starting sendmail_msp_queue.
Starting cron.
Performing sanity check on sshd configuration.
Starting sshd.
Configuring vt: blanktime.
Starting background file system checks in 60 seconds.

Mon Jun 13 08:23:00 PDT 2022

FreeBSD/arm64 (www.zefox.org) (ttyu0)

login: 

at which point it's possible to run well enough to update and recompile. 
Seemingly this is a local problem unique to my systems. In the meantime
I'll try another git pull and recompile....

Thanks for writing!

bob prohaska
 





> commit 800a53b445e7eb113ba193b1ac98631299178529
> Author:     Kirk McKusick 
> AuthorDate: 2022-06-11 18:04:19 +0000
> Commit:     Kirk McKusick 
> CommitDate: 2022-06-11 18:05:14 +0000
> 
>     Bug fix to UFS/FFS superblock integrity checks when reading a superblock.
>     
>     One of the checks was that the cylinder group size (fs_cgsize)
>     matched that calculated by CGSIZE(). The value calculated by CGSIZE()
>     has changed over time as the filesystem has evolved. Thus comparing
>     the value of CGSIZE() of the current generation filesystem may not
>     match the size as computed by CGSIZE() that was in effect at the
>     time an older filesystem was created. Therefore the check for
>     fs_cgsize is changed to simply ensure that it is not larger than
>     the filesystem blocksize (fs_bsize).
>     
>     Reported by: Martin Birgmeier
>     Tested by:   Martin Birgmeier
>     MFC after:   1 month (with 076002f24d35)
>     PR:          264450
>     Differential Revision: https://reviews.freebsd.org/D35219
> ---
>  sys/ufs/ffs/ffs_subr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sys/ufs/ffs/ffs_subr.c b/sys/ufs/ffs/ffs_subr.c
> index f25a6cba12f4..3e31746c2cfc 100644
> --- a/sys/ufs/ffs/ffs_subr.c
> +++ b/sys/ufs/ffs/ffs_subr.c
> @@ -385,7 +385,7 @@ validate_sblock(struct fs *fs, int isaltsblk)
>  		roundup(howmany(SBLOCKSIZE, fs->fs_fsize), fs->fs_frag) ||
>  	    fs->fs_iblkno != fs->fs_cblkno + fs->fs_frag ||
>  	    fs->fs_dblkno != fs->fs_iblkno + fs->fs_ipg / INOPF(fs) ||
> -	    fs->fs_cgsize != fragroundup(fs, CGSIZE(fs)))
> +	    fs->fs_cgsize > fs->fs_bsize)
>  		return (ENOENT);
>  	if (fs->fs_csaddr != cgdmin(fs, 0) ||
>  	    fs->fs_cssize !=
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

From nobody Tue Jun 14 17:58:41 2022
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 8F44184621E
	for ; Tue, 14 Jun 2022 17:58:33 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMx4m3Vjdz3lP9
	for ; Tue, 14 Jun 2022 17:58:32 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=vFrvuiq/PTMXF8Yqnj7fISI1Ap8nUBJM/aaQnZye8Fw=; b=FYGBge3xGQMe290YCwPVaEo8gd
	pzTFHFufxg+rO+jcOEnhZlZ8jge/3O3B5BW1jZjZQCtyCzJmglyFRl/VnGVat2ufOFCoOBlq3IosC
	4PDYE+Gk8U3HPqJ6n/fwpzOymCHIgfVxKDHhguM4yYz/5OKyFC/9PgHV043QgZkQslyI=;
Message-ID: 
Date: Tue, 14 Jun 2022 19:58:41 +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:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Mountroot problems on RPi3/aarch64
Content-Language: en-US
To: bob prohaska , Mark Millard 
Cc: freebsd-arm@freebsd.org
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
From: Ronald Klop 
In-Reply-To: <20220613153325.GA12588@www.zefox.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: -
X-Spam-Score: -1.6
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 0cf14f8480d580d3e3eafcfe68ba1008
X-Rspamd-Queue-Id: 4LMx4m3Vjdz3lP9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=FYGBge3x;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-4.00 / 15.00];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	 MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 6/13/22 17:33, bob prohaska wrote:
> On Sat, Jun 11, 2022 at 06:52:42PM -0700, Mark Millard wrote:
>> There was another UFS/FFS superblock integrity-check fix today.
>> Time to try again?
>>
>> The fix was . . .
>>
>> The branch main has been updated by mckusick:
>>
>> URL: https://cgit.FreeBSD.org/src/commit/?id=800a53b445e7eb113ba193b1ac98631299178529
>>
> 
> There still seems to be something wrong. It looked like git picked up the
> change, but after a build/install cycle I'm still seeing:
> 
> .....
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 12345678D558
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=0x2
> Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
> Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.
> 
> Loader variables:
>    vfs.root.mountfrom=ufs:/dev/da0s2a
>    vfs.root.mountfrom.options=rw
> 
> Manual root filesystem specification:
>    : [options]
>        Mount  using filesystem 
>        and with the specified (optional) option list.
> 
>      eg. ufs:/dev/da0s1a
>          zfs:zroot/ROOT/default
>          cd9660:/dev/cd0 ro
>            (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> 
>    ?               List valid disk boot devices
>    .               Yield 1 second (for background tasks)
>        Abort manual input
> 
> mountroot> ufs:/dev/da0s2a
> Trying to mount root from ufs:/dev/da0s2a []...
> Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
> Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.
> 
> As earlier, hitting [enter] at the mountroot> prompt starts the debugger.
> 
> Booting a kernel from main-n255816-e26ef41f799 goes straight to single-user:
> 
> OK boot kernel.0529
> Loading kernel...
> /boot/kernel.0529/kernel text=0x2a8 text=0x82ccb0 text=0x24c4a4 data=0x1b9f38 data=0x0+0x34e000 syms=[0x8+0x132f18+0x8+0x15ac23]
> Loading configured modules...
> /boot/kernel.0529/filemon.ko text=0x1867 text=0x19b8 data=0x510+0x20 syms=[0x8+0xd38+0x8+0x7ea]
> /boot/kernel.0529/umodem.ko text=0x20e0 text=0x1360 data=0x6d8+0x4 syms=[0x8+0xee8+0x8+0xb46]
> /boot/entropy size=0x1000
> /etc/hostid size=0x25
> Using DTB provided by EFI at 0x7ef5000.
> EFI framebuffer information:
> addr, size     0x3eaf0000, 0x10a800
> dimensions     656 x 416
> stride         656
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<>---
> 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 compliance
> Copyright (c) 1992-2022 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-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 PDT 2022
>      bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> FreeBSD clang version 14.0.3 (https://github.com/llvm/llvm-project.git llvmorg-14.0.3-0-g1f9140064dfb)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 656x416
> module firmware already present!
> KLD file umodem.ko is missing dependencies
> real memory  = 993984512 (947 MB)
> avail memory = 944148480 (900 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
> MAP 39f34000 mode 2 pages 1
> MAP 39f38000 mode 2 pages 3
> MAP 39f3c000 mode 2 pages 4
> MAP 3b350000 mode 2 pages 16
> MAP 3f100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> bcm2835_firmware0:  on simplebus0
> ofw_clkbus1:  on bcm2835_firmware0
> psci0:  on ofwbus0
> lintc0:  mem 0x40000000-0x400000ff on simplebus0
> intc0:  mem 0x7e00b200-0x7e00b3ff irq 39 on simplebus0
> gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
> gpiobus0:  on gpio0
> gpio1:  on bcm2835_firmware0
> gpiobus1:  on gpio1
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 6 on simplebus0
> 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
> usb_nop_xceiv0:  on ofwbus0
> bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on simplebus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e2011ff irq 9 on simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e2041ff irq 11 on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> iichb0:  mem 0x7e804000-0x7e804fff irq 19 on simplebus0
> bcm283x_dwcotg0:  mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0
> usbus1 on bcm283x_dwcotg0
> bcm_dma0:  mem 0x7e007000-0x7e007eff irq 23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0
> bcmwd0:  mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023 on simplebus0
> bcmrng0:  mem 0x7e104000-0x7e10400f irq 40 on simplebus0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff irq 48 on simplebus0
> mmc0:  on sdhci_bcm0
> gpioc1:  on gpio1
> 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.0.
> VT: Replacing driver "efifb" with new "fb".
> fb0: 656x416(656x416@0,0) 32bpp
> fb0: fbswap: 1, pitch 2624, base 0x3eaf0000, screen_size 1091584
> pmu0:  irq 0 on ofwbus0
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> bcm2835_cpufreq0:  on cpu0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> gpioled0:  on ofwbus0
> gpioled0:  failed to map pin
> lock order reversal: (sleepable after non-sleepable)
>   1st 0xffff000000c49aa0 LED mtx (LED mtx, sleep mutex) @ /usr/src/sys/dev/led/led.c:298
>   2nd 0xffffa00000dc1c10 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 0xffff0000004c9024 at witness_checkorder+0xadc
> #1 0xffff000000464638 at _sx_xlock+0x7c
> #2 0xffff0000007e1e3c at rpi_fw_gpio_pin_set+0xe8
> #3 0xffff0000001c9378 at led_create_state+0x158
> #4 0xffff0000001950ec at gpioled_attach+0x290
> #5 0xffff000000494328 at device_attach+0x3f8
> #6 0xffff000000493e98 at device_probe_and_attach+0x7c
> #7 0xffff0000004961e4 at bus_generic_new_pass+0xfc
> #8 0xffff000000496194 at bus_generic_new_pass+0xac
> #9 0xffff000000496194 at bus_generic_new_pass+0xac
> #10 0xffff00000049110c at bus_set_pass+0x4c
> #11 0xffff0000003e2ab0 at mi_startup+0x1fc
> #12 0xffff0000000008b8 at virtdone+0x7c
> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
> stack backtrace:
> #0 0xffff0000004c9470 at witness_debugger+0x5c
> #1 0xffff0000004ca66c at witness_warn+0x400
> #2 0xffff0000006f8224 at uma_zalloc_debug+0x30
> #3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
> #4 0xffff00000042e230 at malloc+0x94
> #5 0xffff0000007d70a8 at bcm2835_firmware_property+0x44
> #6 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
> #7 0xffff0000001c9378 at led_create_state+0x158
> #8 0xffff0000001950ec at gpioled_attach+0x290
> #9 0xffff000000494328 at device_attach+0x3f8
> #10 0xffff000000493e98 at device_probe_and_attach+0x7c
> #11 0xffff0000004961e4 at bus_generic_new_pass+0xfc
> #12 0xffff000000496194 at bus_generic_new_pass+0xac
> #13 0xffff000000496194 at bus_generic_new_pass+0xac
> #14 0xffff00000049110c at bus_set_pass+0x4c
> #15 0xffff0000003e2ab0 at mi_startup+0x1fc
> #16 0xffff0000000008b8 at virtdone+0x7c
> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
> stack backtrace:
> #0 0xffff0000004c9470 at witness_debugger+0x5c
> #1 0xffff0000004ca66c at witness_warn+0x400
> #2 0xffff0000006f8224 at uma_zalloc_debug+0x30
> #3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
> #4 0xffff00000042e230 at malloc+0x94
> #5 0xffff000000742d88 at bounce_bus_dmamem_alloc+0x50
> #6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
> #7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
> #8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
> #9 0xffff0000001c9378 at led_create_state+0x158
> #10 0xffff0000001950ec at gpioled_attach+0x290
> #11 0xffff000000494328 at device_attach+0x3f8
> #12 0xffff000000493e98 at device_probe_and_attach+0x7c
> #13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
> #14 0xffff000000496194 at bus_generic_new_pass+0xac
> #15 0xffff000000496194 at bus_generic_new_pass+0xac
> #16 0xffff00000049110c at bus_set_pass+0x4c
> #17 0xffff0000003e2ab0 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 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
> stack backtrace:
> #0 0xffff0000004c9470 at witness_debugger+0x5c
> #1 0xffff0000004ca66c at witness_warn+0x400
> #2 0xffff0000006f8224 at uma_zalloc_debug+0x30
> #3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
> #4 0xffff00000042e230 at malloc+0x94
> #5 0xffff000000742dd8 at bounce_bus_dmamem_alloc+0xa0
> #6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
> #7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
> #8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
> #9 0xffff0000001c9378 at led_create_state+0x158
> #10 0xffff0000001950ec at gpioled_attach+0x290
> #11 0xffff000000494328 at device_attach+0x3f8
> #12 0xffff000000493e98 at device_probe_and_attach+0x7c
> #13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
> #14 0xffff000000496194 at bus_generic_new_pass+0xac
> #15 0xffff000000496194 at bus_generic_new_pass+0xac
> #16 0xffff00000049110c at bus_set_pass+0x4c
> #17 0xffff0000003e2ab0 at mi_startup+0x1fc
> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
> exclusive sleep mutex LED mtx (LED mtx) r = 0 (0xffff000000c49aa0) locked @ /usr/src/sys/dev/led/led.c:298
> stack backtrace:
> #0 0xffff0000004c9470 at witness_debugger+0x5c
> #1 0xffff0000004ca66c at witness_warn+0x400
> #2 0xffff0000006f8224 at uma_zalloc_debug+0x30
> #3 0xffff0000006f7d98 at uma_zalloc_arg+0x2c
> #4 0xffff00000042e230 at malloc+0x94
> #5 0xffff000000742e60 at bounce_bus_dmamem_alloc+0x128
> #6 0xffff0000007d9b24 at bcm2835_mbox_property+0xdc
> #7 0xffff0000007d70dc at bcm2835_firmware_property+0x78
> #8 0xffff0000007e1e54 at rpi_fw_gpio_pin_set+0x100
> #9 0xffff0000001c9378 at led_create_state+0x158
> #10 0xffff0000001950ec at gpioled_attach+0x290
> #11 0xffff000000494328 at device_attach+0x3f8
> #12 0xffff000000493e98 at device_probe_and_attach+0x7c
> #13 0xffff0000004961e4 at bus_generic_new_pass+0xfc
> #14 0xffff000000496194 at bus_generic_new_pass+0xac
> #15 0xffff000000496194 at bus_generic_new_pass+0xac
> #16 0xffff00000049110c at bus_set_pass+0x4c
> #17 0xffff0000003e2ab0 at mi_startup+0x1fc
> armv8crypto0: CPU lacks AES instructions
> Timecounters tick every 1.000 msec
> usbus1: 480Mbps High Speed USB v2.0
> iicbus0:  on iichb0
> iic0:  on iicbus0
> ugen1.1:  at usbus1
> uhub0 on usbus1
> uhub0:  on usbus1
> mmcsd0: 64GB  at mmc0 50.0MHz/4bit/65535-block
> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>                     Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
>   Instruction Set Attributes 0 = 
>   Instruction Set Attributes 1 = <>
>           Processor Features 0 = 
>           Processor Features 1 = <>
>        Memory Model Features 0 = 
> Trying to mount root from ufs:/dev/da0s2a [rw]...
>        Memory Model Features 1 = <8bit VMID>
>        Memory Model Features 2 = <32bit CCIDX,48bit VA>
>               Debug Features 0 = 
>               Debug Features 1 = <>
>           Auxiliary Features 0 = <>
>           Auxiliary Features 1 = <>
> AArch32 Instruction Set Attributes 5 = 
> AArch32 Media and VFP Features 0 = 
> AArch32 Media and VFP Features 1 = 
> 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
> WARNING: WITNESS option enabled, expect reduced performance.
> uhub0: 1 port with 1 removable, self powered
> ugen1.2:  at usbus1
> uhub1 on uhub0
> uhub1:  on usbus1
> uhub1: MTT enabled
> Root mount waiting for: usbus1 CAM
> uhub1: 5 ports with 4 removable, self powered
> ugen1.3:  at usbus1
> smsc0 on uhub1
> smsc0:  on usbus1
> smsc0: chip 0xec00, rev. 0002
> miibus0:  on smsc0
> smscphy0:  PHY 1 on miibus0
> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ue0:  on smsc0
> ue0: Ethernet address: b8:27:eb:71:46:4e
> Root mount waiting for: usbus1 CAM
> ugen1.4:  at usbus1
> uhub2 on uhub1
> uhub2:  on usbus1
> uhub2: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus1 CAM
> Root mount waiting for: usbus1 CAM
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  on usbus1
> umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:0:0: Attached to scbus0
> ugen1.6:  at usbus1
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> ugen1.5:  at usbus1 (disconnected)
> umass0: at uhub2, port 4, addr 5 (disconnected)
> umass0: detached
> Root mount waiting for: CAM
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device ASMT ASM105x (0x174c:0x55aa)
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  on usbus1
> umass0:  SCSI over Bulk-Only; quirks = 0x0100
> umass0:0:0: Attached to scbus0
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 12345678D558
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=0x2
> Warning: no time-of-day clock registered, system time will not be set accurately
> Dual Console: Serial Primary, Video Secondary
> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
> Setting hostid: 0x5cd40a6a.
> Starting file system checks:
> Cannot find file system superblock
> Cannot find file system superblock
> Warning! Some of the devices might not be available; retrying
> Restarting file system checks:
> Cannot find file system superblock
> Cannot find file system superblock
> Unknown error 3; help!
> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> 2022-06-13T08:05:20.701056-07:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
> Enter full pathname of shell or RETURN for /bin/sh:
> root@:/ # uname -a
> FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 PDT 2022     bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> root@:/ #
> root@:/ # fsck
> Cannot find file system superblock
> Cannot find file system superblock
> 
> LOOK FOR ALTERNATE SUPERBLOCKS? no
> 
> root@:/ #
> root@:/ # fsck -y
> Cannot find file system superblock
> Cannot find file system superblock
> 
> LOOK FOR ALTERNATE SUPERBLOCKS? no
> 
> Indeed, it looks as if the -y option of fsck is now gone.....
> Yet, somewhat astonishingly:
> 
> 



Hi,

Do you have a mix up with labels and partitions/slices on your disk? Could it be that a label was written over a filesystem and instead of mounting from the label your are mounting the corrupted filesystem.

Regards,
Ronald.






> root@:/ # exit
> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
> Setting hostid: 0x5cd40a6a.
> Fast boot: skipping disk checks.
> Mounting local filesystems:.
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/mach/CORE /usr/local/llvm10/lib
> Setting hostname: www.zefox.org.
> Setting up harvesting: [CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
> Feeding entropy: .
> lo0: link state changed to UP
> smsc0: chip 0xec00, rev. 0002
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> Starting Network: lo0 ue0.
> lo0: flags=8049 metric 0 mtu 16384
> 	options=680003
> 	inet6 ::1 prefixlen 128
> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> 	inet 127.0.0.1 netmask 0xff000000
> 	groups: lo
> 	nd6 options=21
> ue0: flags=8843 metric 0 mtu 1500
> 	options=80009
> 	ether b8:27:eb:71:46:4e
> 	inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
> 	media: Ethernet autoselect (100baseTX )
> 	status: active
> 	nd6 options=29
> Starting devd.
> Autoloading module: uftdi.ko
> uftdi0 on uhub1
> uftdi0:  on usbus1
> add host 127.0.0.1: gateway lo0 fib 0: route already in table
> add net default: gateway 50.1.20.1
> add host ::1: gateway lo0 fib 0: route already in table
> add net fe80::: gateway ::1
> add net ff02::: gateway ::1
> add net ::ffff:0.0.0.0: gateway ::1
> add net ::0.0.0.0: gateway ::1
> Updating motd:.
> Creating and/or trimming log files.
> Updating /var/run/os-release done.
> Starting syslogd.
> Clearing /tmp (X related).
> No core dumps found.
> Setting date via ntp.
> 13 Jun 08:22:48 ntpdate[875]: step time server 86.3.245.8 offset -24453.100209 sec
> Mounting late filesystems:.
> Starting powerd.
> Starting sendmail.
> Starting sendmail_msp_queue.
> Starting cron.
> Performing sanity check on sshd configuration.
> Starting sshd.
> Configuring vt: blanktime.
> Starting background file system checks in 60 seconds.
> 
> Mon Jun 13 08:23:00 PDT 2022
> 
> FreeBSD/arm64 (www.zefox.org) (ttyu0)
> 
> login:
> 
> at which point it's possible to run well enough to update and recompile.
> Seemingly this is a local problem unique to my systems. In the meantime
> I'll try another git pull and recompile....
> 
> Thanks for writing!
> 
> bob prohaska
>   
> 
> 
> 
> 
> 
>> commit 800a53b445e7eb113ba193b1ac98631299178529
>> Author:     Kirk McKusick 
>> AuthorDate: 2022-06-11 18:04:19 +0000
>> Commit:     Kirk McKusick 
>> CommitDate: 2022-06-11 18:05:14 +0000
>>
>>      Bug fix to UFS/FFS superblock integrity checks when reading a superblock.
>>      
>>      One of the checks was that the cylinder group size (fs_cgsize)
>>      matched that calculated by CGSIZE(). The value calculated by CGSIZE()
>>      has changed over time as the filesystem has evolved. Thus comparing
>>      the value of CGSIZE() of the current generation filesystem may not
>>      match the size as computed by CGSIZE() that was in effect at the
>>      time an older filesystem was created. Therefore the check for
>>      fs_cgsize is changed to simply ensure that it is not larger than
>>      the filesystem blocksize (fs_bsize).
>>      
>>      Reported by: Martin Birgmeier
>>      Tested by:   Martin Birgmeier
>>      MFC after:   1 month (with 076002f24d35)
>>      PR:          264450
>>      Differential Revision: https://reviews.freebsd.org/D35219
>> ---
>>   sys/ufs/ffs/ffs_subr.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sys/ufs/ffs/ffs_subr.c b/sys/ufs/ffs/ffs_subr.c
>> index f25a6cba12f4..3e31746c2cfc 100644
>> --- a/sys/ufs/ffs/ffs_subr.c
>> +++ b/sys/ufs/ffs/ffs_subr.c
>> @@ -385,7 +385,7 @@ validate_sblock(struct fs *fs, int isaltsblk)
>>   		roundup(howmany(SBLOCKSIZE, fs->fs_fsize), fs->fs_frag) ||
>>   	    fs->fs_iblkno != fs->fs_cblkno + fs->fs_frag ||
>>   	    fs->fs_dblkno != fs->fs_iblkno + fs->fs_ipg / INOPF(fs) ||
>> -	    fs->fs_cgsize != fragroundup(fs, CGSIZE(fs)))
>> +	    fs->fs_cgsize > fs->fs_bsize)
>>   		return (ENOENT);
>>   	if (fs->fs_csaddr != cgdmin(fs, 0) ||
>>   	    fs->fs_cssize !=
>>
>>
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
>>
> 





From nobody Tue Jun 14 21:15:32 2022
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 A52168459F7
	for ; Tue, 14 Jun 2022 21:15:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4LN1SK2nwCz4hf2
	for ; Tue, 14 Jun 2022 21:15:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655241338; bh=36pvEHHKpQc73xacfH0LbqcDrxZ5xTM6wTtyqDVD5fI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Tk6RU4Zz6WQ+EAVIN1+9LP72nhzfOQBymi61i8kgGhQQo+p5X8CP/PDw4BD746RfAMQcMwsrTCalKQU7g6d9zpgAQiZECVYKQgjUhQZS3+E23ajV5EMLtRVjFo3/kmAe3ZYIc0AGvDulGCKtWLfDZOMC8kZdSgWSpQ6dDuZqJRaMNVBuvTqW9+H+5bOTcueJ/KElhzLxwVCNGstD4R6stjBlngPQ39O/cLoaXXQlQRKOeeOpe6rbJkvE40MviyH0jlDjMsXi/Mn1zZkn0L0wkZ4BK82OnlnINMyzmhL/wwCrIezPUftB4AO2etlzaNkbOLsIzgidVmDTX3XQIRw1lQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655241338; bh=lwOS0EbfspbAsl1N394smA2tkuL0FcQUKDomds5Mggu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Iy88pvuYiiEkQd9xJ33hw7raFLw181pNq+gF8kq31hKvEnnzZ4BwF2urE3iLTmR0K++0AYkkzNoMk4vEHY/anNCNa81Ea1JvTFEK6Byct+wOrIbo0g/AEHBp2LlPprRII6BAmXzi+wfDUQtfzP2rjqV8VUSVal0NfPWpC6juZRU0geMQr2Im4+O3A4MF4o7inbxqgTIjA/y19S6p9SlrxeFpOgzPPay/45pclxqnjo5sLrQcQN1Qr3LC8EAcTZi3qa9FYedVk1cwXidVV5FiZ2xZFojf31vFSFOqtPfIAAgmljXwzBcW5MQ5+yHN6su2TVwwcI+rVhvFaIjbn64jTQ==
X-YMail-OSG: LR.OSm8VM1mEmsLtaoKdp2Fnh6q9B.5gFLfwKxQlchbVZWlvfDafJ5m40UgFLMl
 B.gs6A8MHpNaMaQH2c.aP9S4HsQ57dKfcaS_WyTcZnYvEZ_A3gB6TbXFfVR0yCg7Vz_ZRmlRaISm
 oOF6bdooaEKlcEkvtpIZP_5SllYsN314nDL47F8ihsglV6VpmCu82HBhB8Z1sj3S8fwvVGgsTtnQ
 Sz6uvzAo_PCO1cRieoieAPTgLr.SciaoYun_NH8CmBUWuYgjP8ujgpwFaQOiQqMKR4DS1l8eegzT
 4eUrSe8TJ7HLMmdpar68erU2JglZ.SN06Kr5o1wRCp1_pWn55rF5c2pQpsgtR7quUiQ2eo09ix8t
 UD6mSrdAhCgmISGYZoFbrwlLCWtFZZXlS6kz_pYNudVT4P6suPjh.2N96mbnLw9tVQ8jTNFJ9Aob
 d8APj43T2C1RwCbiVEl1EAuT9Rnjth4VKrSapdmoNtnXYEzxWYOJKS_EYPqc_uwTMJO.wzHiHAG6
 _arh7j7X42NKhINFHVdP8TEXi9KLF9LHq3eORSXYgzJIIbYRGgEwNijTEpWBaJy2XzfwxAlhJy..
 nwMndlv1THe_Tubsv93WNwp57MLztCFMrPYOzPhfZbCCrg8209sS7vZ5JOgt_3BrIrMSw7QYdoMG
 zHNiKNOEBFERR6oWN6iFr9T5UMJbMg6UyFp0go9nwLVEZt7ASB8eKcYMgjLICRw8KWlriaVJRQne
 INOFc7cp9cXdkBegsjpOpAKH9e5R_JEPJbFncewBOI20vP6vhhGqf0knAzXBA0UO2Ar4_QhY9Mxy
 ro09cAr2_ns5pTeCk7z0IyCz1G0In8NNQ0nQXxxEhEIHDV2qy5X9kc6mfFGMi7NGqqvmHU0ewHME
 bbgjJf2iPMjx38isEjuyjXmR5gmG34PStj2WIzGrgF_wuieUmekrcMcnlxLI0SCo00n6eKU5luon
 NkdcOBXHXF1JUaHI6mg13GZIQzvQjjF9j6_ZMh6EgoW5TEZaZD5ZDGi2RzcSEStYPRfcOGckZIc8
 hHz38QgRtfwsVd6e.gszfeKUHQkayxlaJhAWBQpWg3CAyodXtgaDswWWmP7rFA28xZ0vWEVhX2l1
 SxOa0ZDhJQ1S3DDBgYX.mGWCYk7ZRkYmttGq6WaDs6VTKA5dLuWKjw0Eo7lEtQFpXt0SYVMWewgH
 cZVStnssu63dYZAWBlMYkKNnuv_u8TvMuZJs7oXRGmOSNdH04_eVeIWI8hnbGtzdkcY7bO1W2Gq3
 yWgYvp.D4_upuPeAcX8LJpifVRZZsTmBjpgV1kad2g_kCqZcuTalxhCqSnJ.nMMFm68vndFTGWsu
 QvETIVzKFzCM5asZyTsQsciJ2lZBF5C44Op0wAsbRfYBVBr0Sc6Gbrwi8fCHO8rg3IlGXUunP.6Z
 jjkM0gJ5LuFuDXqz.Z.Dt7L3TnCMSA2soodxWtZxFH3wndb_rpp7D8OsiUFKbpXN9LqyTFecCjWO
 cmcB2uN19aKb5dnVFjDIJ5sEdZ4hIPOGuF.y0pf7Rg_mxRIdRZ8aQhXYzB_lR584Zri5TTWi8lYG
 UXBHY.fmWFKCwh_b91t6e_ypR6UNEd6llqK2CH6dmbp.Ax3muumudSibpWp5dZPc_gf7ti0Oerdq
 Vh6nXZ5zwtQgIpgRsfT8oTK20bW9SO45B8SouT8MnvdUKB9bpbHRKul3YorWEsJdkqx0DWRtkkfL
 9VeETWS0PYtRDkn_Hxpc6ZMCcpH3BjColHqn1Uc9ChjAy406rKGi8prMVz7tj0NeXHmFrl21qv_C
 Uln5_zRxDUCjlU5RlWIXA0YQYw8ya30DBCkuDR0II2_Zaq314LPNlcEhdxZPaIMEudD8ZY6bjBRv
 Ee4Uk3ND1LYCLnRuU_ixp8gHgiI4zm.i90pJeX3v1BLFuc_WmqGUgIoSykBJJhUBmnl5WN398V0U
 USqv2q4S2QeRnq8LAI4HYWwm4p7aI263Jb2fTv1Smd4A3pqpYO.Sm_EZ7yPX9xYfcMSlyc6kDKsz
 vrJrHTrlPbv5MNNmus36O.2jqkxdgT0axJr.CsUhfescAsYvtFzJMPu8QR.xmRqrxa22oKPB3aME
 vrfDmVuPK9no_7kkdM_6HIQG8bXAR5t4tYXYeTVGkyBxd8QfC_3.7F9XCsbtVacaZ1odd1rAKPWN
 dz9nCfrEYqXPaB_L0LV2fW7C5wcjExdnp68NWRnoOlULA4pem75Tr0lI1KvAsv3vP_Q7HFTtH6Uk
 lOJH4aZA6aziKcaur.YD.WfMpsPmPXODz9YzjzuAcuzlJRlEqqv1vi.4eh8410ykDC787ncjWpj3
 JP15hHUENc_YKhv9p_V1aBvn3DqYtqW4YT3ikHJkbGodAECL32VBDjU_dVOUsUlvSS9xMCV0AXZa
 Dz0KcidKRLOPI0ECV
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 14 Jun 2022 21:15:38 +0000
Received: by hermes--canary-production-ne1-799d7bd497-nrsk4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8c4fbb07e7bfb8da750b53b6366a6743;
          Tue, 14 Jun 2022 21:15:34 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220613153325.GA12588@www.zefox.net>
Date: Tue, 14 Jun 2022 14:15:32 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LN1SK2nwCz4hf2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Tk6RU4Zz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.99)[-0.987];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-13, at 08:33, bob prohaska  wrote:

> On Sat, Jun 11, 2022 at 06:52:42PM -0700, Mark Millard wrote:
>> There was another UFS/FFS superblock integrity-check fix today.
>> Time to try again?
>>=20
>> The fix was . . .
>>=20
>> The branch main has been updated by mckusick:
>>=20
>> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D800a53b445e7eb113ba193b1ac986312=
99178529
>>=20
>=20
> There still seems to be something wrong. It looked like git picked up =
the
> change, but after a build/install cycle I'm still seeing:
>=20
>> . . .
>>=20
>>=20
>=20

May be an appropriate problem-isolation test (not fix)
would be to make a microsd card with an system somewhat
older than all the recent superblock validation test
additions. Depending on media types, you might need to
use a USB media reader to look at the problem media with
when booted from this older system.

If that older system has no problems with looking at your
problematical media, it would suggest that their are still
more compatibility issues for the more modern superblock
validation code.

But, if that older system still has problems handling
the problematical media, then the issue is something
else with your media.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jun 14 21:26:26 2022
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 3D911850455
	for ; Tue, 14 Jun 2022 21:26:26 +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 4LN1hd6z5lz4kwS
	for ; Tue, 14 Jun 2022 21:26:25 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 CBACA120BA
	for ; Tue, 14 Jun 2022 21:26:25 +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 25ELQPWw058925
	for ; Tue, 14 Jun 2022 21:26:25 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25ELQPBa058924
	for freebsd-arm@FreeBSD.org; Tue, 14 Jun 2022 21:26:25 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 264673] aw_if_dwc does not support current versions of u-boot
Date: Tue, 14 Jun 2022 21:26:26 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: src-2016@bikker.homeunix.net
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655241986;
	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=AYj/ogjLe1FrwBi78Sw9HAZGdeXg2DTnoahF4i6Bd0Q=;
	b=fI84jydHcN0uheGcH+D3g5Jy/zORZNMTAJmWJLH9pCu8OKwjgwePzsZO5RWoEaE9y58pfP
	HF/rA/hNZnYDWeTCeWprP45v+SvjMshqQYsjtXrG/UF0StU9z1LCxaarSVd29uNcGEgiaH
	Nd/RQmjTDb24ivC82SpPEclSn2BlkVnRMkE3YarvhnDwUolcZORKj3oQlK/AfbHLdNf/bE
	6D2gWemOxdJajEzuNeUsSe/uGLj1SG5BsoHVfb0jETUZnQRirTbbPk2PU72tKqvHuQWJsy
	n5oE/3OFHFzYqxGSL4oWtFPyO/YWDIIZAxD4wRBN55qjdkX9Dcidsf/QtwJERQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655241986; a=rsa-sha256; cv=none;
	b=PNCfVCusU9SHyihf+U1uxifH7NWcmpVViGcc2dCfahRahMhQUQi4W+eptQQtP6+EvDwOh2
	nKg0A8dgnNDKoglx2AhhGIpUz+y2ffTd+dcyHH5BCwRh7jOzQRceqNTz3RDFkuerEi5wl2
	zL9eZvAmKYmInFAxFSmQqGrloOswBVcxM7ijGqS1wGOPP/Sj43r3fwsUWF784Woe9J2s+K
	FU24pQK1fKBrSRt7RD7vGyEMWNqabEJC5VQenWdVAA7HZfQV9s4JK/lD0Tt0RPBx/WGPJd
	A+IF4vlj/tV1T3UL/TzVLlcN89+ND1cNO2R50Ejat9dIDOm7Bs98uzZsAXo3HQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264673

            Bug ID: 264673
           Summary: aw_if_dwc does not support current versions of u-boot
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: src-2016@bikker.homeunix.net

Created attachment 234692
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D234692&action=
=3Dedit
aw_if_dwc and rgephy patch for rgmii-id mode

Current u-boot uses phy connection mode "rgmii-id" for some boards.
Driver aw_if_dwc.c does not support that and erroneously falls back to mii
mode.
This breaks network access for several boards including allwinner a20.
Failure verified on pcduino3-nano with dwc boot message:

dwc0: Can't reset DWC.

2 problems:
First: src/sys/arm/allwinner/aw_if_dwc.c incorrectly assumes that fdt suppl=
ied
phy-mode is always "mii", unless it literally is "rgmii". For supplied phy-=
mode
"rgmii-id" it falls back to default "mii" and selects wrong clock.
Remedy is simple - instead of 'strcmp(phy_type, "rgmii")' check for any rgm=
ii
interface version via 'strncmp(phy_id, "rgmii" ,5)'. which matches also
"rgmii-id".

Second: None of the phy drivers support rgmii-id.
The supplied patch adds rgmii-id support for rgephy (realtek 8211E).

This was tested to work on pcduino3-nano

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Jun 15 00:04:38 2022
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 C21FB838A12
	for ; Wed, 15 Jun 2022 00:04:48 +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 4LN5CM2qrLz3LKX
	for ; Wed, 15 Jun 2022 00:04:47 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25F04dqb020176
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 14 Jun 2022 17:04:39 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25F04c0i020175;
	Tue, 14 Jun 2022 17:04:38 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 14 Jun 2022 17:04:38 -0700
From: bob prohaska 
To: Ronald Klop 
Cc: Mark Millard , freebsd-arm@freebsd.org
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220615000438.GA19936@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
 <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 
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: 4LN5CM2qrLz3LKX
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.92 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.83)[-0.827];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.990];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	 MID_RHS_WWW(0.50)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jun 14, 2022 at 07:58:41PM +0200, Ronald Klop wrote:
[big snip]

> 
> Do you have a mix up with labels and partitions/slices on your disk? Could it be that a label was written over a filesystem and instead of mounting from the label your are mounting the corrupted filesystem.
> 
If I understand your question, the answer is "no": /etc/fstab contains:

bob@www:/usr/src % cat /etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
#/dev/ufs/rootfs   /       ufs     rw      1       1
/dev/da0s2a     /       ufs     rw      1       1
/dev/da0s2b     none    swap    sw
#/dev/mmcsd0s2b none    swap    sw
#/dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0
/dev/da0s1      /boot/msdos     msdosfs rw,noatime 0 0
#tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0

Once u-boot finds the USB disk, I use
run bootcmd_usb0
to boot it.

There is a microSD card in the slot, with a bootable 13.1-RC4 image
on it, but AFAIK it doesn't come into play once u-boot finds the
USB storage device and is told to boot that.

Far as I can tell the USB filesystem isn't corrupt, but if it does
get corrupted the -current version of fsck on the USB device still has problems
finding superblocks. If I boot from the microSD card and use that system
to run fsck it has no problem running fsck on the USB filesystem.
The filesystem was created in June 2020, could that be incompatible
with the recent changes to UFS?

It's maybe worth noting that both -current and stable/13 behaved
similary until a few days ago. Stable/13 became able to mountroot again
hands-off, -current is still having trouble. The -current machine
uses an ASMT usb-sata bridge, the stable/13 box uses a Jmicron bridge. 
Both hosts use Seagate Barracuda 1 TB mechanical disks.

Thanks for writing!

bob prohaska
 

From nobody Fri Jun 17 03:09:03 2022
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 5332683EC21
	for ; Fri, 17 Jun 2022 03:09:03 +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 4LPPC30PzSz4qKb
	for ; Fri, 17 Jun 2022 03:09:03 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 E0E4B179C0
	for ; Fri, 17 Jun 2022 03:09:02 +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 25H392kd062363
	for ; Fri, 17 Jun 2022 03:09:02 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25H392Lf062362
	for freebsd-arm@FreeBSD.org; Fri, 17 Jun 2022 03:09:02 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 264727] Upgrade to 13.1-RELEASE fails on arm64 system
Date: Fri, 17 Jun 2022 03:09:03 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: corey@electrickite.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655435343;
	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=mwM+LoIDsBGFHnSoh4kQ77ugborsoqwnE9mHq728G4c=;
	b=UikpmwX1yTrHxgkOwaeshyFelEMTSgFanwY7YAxQmPo3VST5KcHPqljtsRyBuTBZYM3ixS
	3uzMLvFAD8CmUFi1UU0CPtenKiCxg9pi8w0MXcMUcOfMjdW92xJznXpRa4rz44kps+g0OU
	ou3gCvigYOa0Tno4LQHepIPYuZnd+F3DzpEYma3sqqQ6RnKb/+Bf83KwISArgRGApw/4cR
	YhS4hFTmR/qJDUuvFxWjL553g2vLrXs2dDZdZm/TLNy/Rkoyb4RGS01nefBG8sGCz2QHYU
	Mx9PdMY5YMd7jNgH7VODuannuJDYVtGw75s5/iccVAG7YvlzCN9H+bFz9xYFaQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655435343; a=rsa-sha256; cv=none;
	b=tYDdwg0mtIAEd9Fs/NJRLsAK885V12JMJeYGrIPaqLlGWpT1pEy80i87+PGMKZVUyQJeRG
	R3bgVm+xyXiv0vDpt/1xHuiA+PRhHUun/BYx+eSCYfNXWVKzCmkmuyswSB9AsVIR04xKTg
	/dfb1m+gyVlb0rSVxtPVyF48UwUmcDvn/jvplQdJylCby7LnCUguEe1rBYdOCOaAenAh5f
	xh26KjSPugHQiBs2FSOIF7ehX5KhdPzLpdV7BWcPOXY18ooUs9ztDu8TzP9yc1SzntYxYt
	516V3Jrh4i5yHXMgcPP4QrZl5BwgtAfAsgvMRdTAh8ukjiPRTQSVZslDjVMakg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264727

            Bug ID: 264727
           Summary: Upgrade to 13.1-RELEASE fails on arm64 system
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: corey@electrickite.org

Attempting to upgrade from 13.0-RELEASE-p11 to 13.1-RELEASE on a Rock64 aar=
ch64
single board computer fails with the message:

ld-elf.so.1: /lib/libc.so.7: Cannot set relro protection to 0x1: Permission
denied

This system was originally installed from
reeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img

output from freebsd-update follows:

# freebsd-update -r 13.1-RELEASE upgrade
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.0-RELEASE from update2.freebsd.org... do=
ne.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic kernel/generic-dbg world/base world/base-dbg

The following components of FreeBSD do not seem to be installed:

Does this look reasonable (y/n)? y

Fetching metadata signature for 13.1-RELEASE from update2.freebsd.org... do=
ne.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
ld-elf.so.1: /lib/libc.so.7: Cannot set relro protection to 0x1: Permission
denied
ld-elf.so.1: /lib/libc.so.7: Cannot set relro protection to 0x1: Permission
denied
client_loop: send disconnect: Broken pipe

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Jun 17 14:58:54 2022
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 E7EAB8356D3
	for ; Fri, 17 Jun 2022 14:59: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 4LPhyG3C6Tz3nXK
	for ; Fri, 17 Jun 2022 14:59:02 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25HEwtRr035938
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 17 Jun 2022 07:58:55 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25HEwtUp035937;
	Fri, 17 Jun 2022 07:58:55 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 17 Jun 2022 07:58:54 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: ./bus_if.h:1:3: error: invalid preprocessing directive
Message-ID: <20220617145854.GA35906@www.zefox.net>
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-Rspamd-Queue-Id: 4LPhyG3C6Tz3nXK
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.90 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(1.00)[1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

Here's an example of a persistent buildkernel failure on a Pi3 tracking stable/13.
This particular failure has been persistent over the last couple weeks with new
builds attempted every few days. 

Logfiles are at
http://www.zefox.net/~fbsd/rpi3/crashes/20220617/

The initial error is

--- bhnd_pcie2_hostb.o ---
In file included from /usr/src/sys/dev/bhnd/cores/pcie2/bhnd_pcie2_hostb.c:59:
In file included from /usr/src/sys/sys/bus.h:764:
./bus_if.h:1:3: error: invalid preprocessing directive
# Meta data file /usr/obj/usr/src/arm64.aarch64/sys/GENERIC/modules/usr/src/sys/modules/bhnd/siba_bhndb/siba_bhndb.o.meta

That looks like the result of a stale file, but repeated updates
don't seem to clear it and the aftermath of the error is a flood of non-ascii
characters in the logfile, which I've not seen before during OS build attempts.

The build command is 
make -j2 -DWITh_META_MODE  buildworld > buildworld.log && make -j4 -DWITH_META_MODE  buildkernel   > buildkernel.log
which has been used for some months without visible difficulty. The use of filemon
has been continuous, generally without global cleans though I have used make clean
in selected subdirectories under /usr/src from time to time. 

An otherwise-similar Pi3 running -current exhibits no such behavior.

Thanks for reading, and any suggestions. 

bob prohaska



From nobody Fri Jun 17 15:41:22 2022
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 4339A83D102
	for ; Fri, 17 Jun 2022 15:41:25 +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 4LPjv83vqBz3tX3
	for ; Fri, 17 Jun 2022 15:41:24 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25HFfNin036118
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 17 Jun 2022 08:41:23 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25HFfMA0036117;
	Fri, 17 Jun 2022 08:41:22 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 17 Jun 2022 08:41:22 -0700
From: bob prohaska 
To: Robert Clausecker 
Cc: freebsd-arm@freebsd.org
Subject: Re: ./bus_if.h:1:3: error: invalid preprocessing directive
Message-ID: <20220617154122.GB35906@www.zefox.net>
References: <20220617145854.GA35906@www.zefox.net>
 
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: 4LPjv83vqBz3tX3
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.90 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(1.00)[1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jun 17, 2022 at 05:02:11PM +0200, Robert Clausecker wrote:
> Is the typo in -DWITh_META_MODE something you wrongly transcribed or is
> that the command you typed?
> 
That typo was in the command. 

Thank you for catching it! Still, it was in buildworld, not buildkernel.
Fixed now, I'll try again.

Thanks for writing!

bob prohaska


From nobody Sat Jun 18 22:54:19 2022
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 85336838C80
	for ; Sat, 18 Jun 2022 22:54:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4LQWSS1nrJz3Md1
	for ; Sat, 18 Jun 2022 22:54:32 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655592863; bh=7WW/qKd6CF+Xu+m7E26dUHxM0cA4QyZuBqrtXPOJUHI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qX3gPhOW3h4fGTlMIdJuATR7Dr/BhJteZrrhdvAw6ei1i39nKUXp/kWOoN/0KrvT/2Q4XJjL7o6HbzTg6C4gWF1Mm78ud0PPTcis/GxeIbfR1aDljYDGbC0eJ8HUxK5Py+po98utwLvMWyRHYTo3jKzue4m+tO04JXN6V7DKUrFuLRqO4yK0BcwSQpYuQPfdC02Z9MaHwxvN8uVl2vgX1FaPqkCQio8VBr+/sKap+fIWDP8uRniKUgsZ9gXXb+GljBlpHvG5Yi9fyHHjAT0H0Bkdfu0sK95HkeTJj0Oy9+55SncCC/k6oMcJgrVoOaIJ8gXI7cyb9/XPj1LDVwsZzQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655592863; bh=wLl7Fu0arkWDKCSdJaHjrFXjWaW4qdKTSNyAM9pXYAG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=omzn8i5Wobz+glmfqcVapa+ge1BEgTS4bC/2qTL2azfPJ7QiRAvkmAxiTHdywqyuJYtld9a73GS0lCmrgNtUUOJrANNbe9v8X4D5HtSc2JoEOxZErL8oQXrtXe9hihgxO5THs4g6HnM23Hm4EGWESYvf5RUhOg5Kr2gTY5bq6wPeNovtzyZHPMBtQ6fIj1pkUr7MqkfhXlcFZ2lSshXNr0qw8U4ZPQhpYViHnj/bRiRgmgCC2qMnEjGI1lMUvg5OTn++l16mOwYtOgO0kw3q4YpVgu/Yg8yzfxiE4D2z56PTwANbCukwjBz+QnGlzpw+qRLKXjOXGEAkYqru2cXKTQ==
X-YMail-OSG: K.akURYVM1lIv83QFpXOOlGyr7XU_6qGFGv4wS8G7bGCcYOnYxQhY5DgY7Tr6Xi
 hYwe7p4h1dQqP81DXcqbkCQnXTzQ37sI.r2EWDMObFnIyHTDx_LfUi0pZsbbGe16kTmf9Wqwe3OT
 Uf.Zbd1byod898alkRS1V0HsY8COl1AtCOujfTB73Nof7YSCl.bwPRi.IEiEcF.orqDJofdA1F4o
 71_ATSMxetMAx7SMLoziUAa.eZ7b7kOomJ2j832HHDbqHo.HMPVLXP2WNKg68dVIXf0sbZ6CRwI5
 siT0oKDdpP.860Z6qtuPJUbHEpQTr2lkig2eR.YNY8xhpBWOEo4KWweRa42DoAOy2uUQzRX7Qmtl
 _T4Di3WWMSQ8KcnWMZfXtV_YGig5JASC8iR01jPkMpPWGixo1oM9vTzGMe8NoKxSW5Hdbk5cRzCy
 bqciC2zxDZx.yCNb0gkwbKNb6e9ZRl8sD8XB7_XSCkQhBsa9SH2UOtrenANZI2GDC.gQeDqKKwXt
 m2UP_XJ71qdC8cTRQpV0uCvBltkahsgl_ZZufGHL_e29sE.LKRhRtva8SwnhdrfL8rUGG.joFzJs
 o70x137qPD1D_hIVDRaRKpaiPwl1MJYk5dggeJr4mtpj1HSMJ8b.rb8D4vg.wGvCuAQIUSLGmD2U
 jaiSo4hR86h0LmEbL7pvMF9lWaGZMaIB8E_jV9phy5TQ6qXk_DJCr5eYyVwoJHs0HDo9DLlCP.JX
 y0UH0E9l2hP6a9tFn8ybx0O4IrqrxHuHBo6OJRFDbL78fdsT4L3T3ASAdROx9lLgVutmpRe1GKj0
 kuITAYXaRdDldy6wdFswNiTbDBwTSCn9Oo9fzw.ByHVTTQNBY_n_IqPBiiMnOB5mSj4.dOeRoPrY
 GdW11MGl4Z3XPCCjlKxAOrQc7p9NIs8XzrjLrv9GM7AhS5h7_TB9qWkzoFc.PFqgmWT_1fDo2__z
 zIRL1w1T4Si5B1NYYlMrE6QI4iel1WE.uqUIobDaRgaQldfMBqhzLoI2qRCIdv3lrYZDDs376aEt
 0KM1H7Oo6MEw72o26uTs7X7EfLjCY0KZV8IGc0V_6II1iQAq83sTX09mxBmQNk29eGVdq9fYTLWy
 GrZKYroGMJFFLV.dvSL.AGlGJDFzoV9MhhWEF40ItzhuAr28PpboKnYRq0XTPUh0vcswTiRZFzQG
 I3JgQ5VPer10n.hKQvzUmxEGVXMt5LC3or3Fi9qV7YjABHsDNnIZMnZUoUhIjkh3HderDMzvzVpe
 wbIV20.SC5fJtkwzNWKzdzQ9Um42HdMNaW1rHeBfbp7qIx3B2uULTANtLgrhyKGezFVdI8dAuFtj
 5oDwrV1om1ApgaJGcufgfD4PONC0FlPRs0CBrmjwF90fif7gmPvQ91oA88mCg0_p9H6TqY83AhPO
 7gr8MrW_gK9_IuVVi95OJ25q7_9qpXGG5qeRVyHDMZW92Bf0iE.2Zujkt7zsTdvvMBQV0Otr70J4
 gVQUCraurkRtaStQgkQwhuGeSJLrmi5NflJ.PdvoQ9ZvteTTeTAy4LgplqAMUwcO4iB4r.ZunmUj
 1ywKtW2Hb9ezytyaVsegukFshLgyeN3Ncj8Y0EzTIcmTpLwO2mVwBS76X35fQxvrH69R4Y9zgPgr
 oAtKkf.8wrXVCVdmCPTFGOlyFU7SKkwdTEYwW_sn.0rjMdMMTE46yFIdHe6bZ.ezVMiqLM8sNWoQ
 Xfde.cbRVug.Gfxby_LWyXw6owEKNLdwL7CQzyc3rwxAfTU0rwMfqAmss8xrVZjafjPO4zwQxIwx
 hglBWtl67.0maNDhMXoxla14dFpJv9on9H4utCyO0yBtSzZhm5X2dCB4JsC.klbhFzIlsyoWVace
 Lh0i9oItlAc66UFS8l1U1WGhp8FffepuIHueQ3vDozXhasyhg_7cI8NVAZflnRVefopSS8FlgQvS
 .SNdP9Ue6iUisH0Ub941eHMY_29nRhn9gcgGvmQiUGwrUUWCjkDSqh8pKgVEDSI5y1eUb3DM03T2
 XiqRqVVaqSjkrOiyHKYHyWtdcncU3eCQQlAk.sXCtzgNN5AA8Et6tvWLq3dM2NfwkU77itJja_hA
 LzUW_JbX5xlx7rcWGV6PaFMe2rJPOC8XL.tpeiv0XDWxzk3KM0wazabZEZL3.fUQ1MCEqN4DY37r
 CHovj4hgOGiSCzHElILRKMEVnWZ1gbsFEXWrjt6NhU1hrlVd6u5GGffFgKxXSWOuNRva0ixwnfwn
 mcSvbPpHlBUIf6bTl_AtDkib3r7L8DN0FCo3EI_rQK05E4nZoS8u35ytmFP29ITfo9uzsMJoHpWY
 rl3ejt7aq
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Jun 2022 22:54:23 +0000
Received: by hermes--canary-production-bf1-8bb76d6cf-nnbm8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4cb4eee4805558ccdee4523656d7bcc3;
          Sat, 18 Jun 2022 22:54: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
Date: Sat, 18 Jun 2022 15:54:19 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LQWSS1nrJz3Md1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qX3gPhOW;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

I finally started my round of updates from:

main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022

to:

main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022

So far all the UFS media that I've tried (older and newer)
have worked fine with the update, including fsck_ffs not
finding any problems.

It does not appear that I'll end up replicating your problem.

===
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun 19 04:22:25 2022
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 91C2B83B6BF
	for ; Sun, 19 Jun 2022 04:22:34 +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 4LQfkx5694z4dys
	for ; Sun, 19 Jun 2022 04:22:33 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25J4MQUt002532
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 18 Jun 2022 21:22:26 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25J4MPNC002531;
	Sat, 18 Jun 2022 21:22:25 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 18 Jun 2022 21:22:25 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, bob prohaska 
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220619042225.GA2267@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
 <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@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: 4LQfkx5694z4dys
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [1.62 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.25)[0.254];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_LONG(0.10)[0.097];
	 NEURAL_HAM_MEDIUM(-0.63)[-0.630];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
> I finally started my round of updates from:
> 
> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
> 
> to:
> 
> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
> 
> So far all the UFS media that I've tried (older and newer)
> have worked fine with the update, including fsck_ffs not
> finding any problems.
> 
> It does not appear that I'll end up replicating your problem.
> 

When one invokes fsck at the single-user root prompt what actually
gets used on a UFS filesystem? Maybe I've got a name problem.....

Thanks for writing!

bob prohaska


From nobody Sun Jun 19 21:00:19 2022
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 3726085F092
	for ; Sun, 19 Jun 2022 21:00:21 +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 4LR4tD0bNyz4Ymj
	for ; Sun, 19 Jun 2022 21:00:19 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 73D7010178
	for ; Sun, 19 Jun 2022 21:00:19 +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 25JL0Jwa057547
	for ; Sun, 19 Jun 2022 21:00:19 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25JL0JJQ057546
	for freebsd-arm@FreeBSD.org; Sun, 19 Jun 2022 21:00:19 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202206192100.25JL0JJQ057546@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, 19 Jun 2022 21:00:19 +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="16556724194.CB1C5d.56439"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655672420;
	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=auoPiOvJ9HTPcGRNCzzyvtZH96h3rV1hUQ5hfhKRuTU=;
	b=vC8onRPmIH8RqPXqXBWBxdNWWi0y2RIOOniKNp/1I6R7Ui32cvrKDy1ffuWWrB71a6y5bC
	qROksffYQxKp3N1HHwtPSgS/vxZyugmBv5ZXGuIqnO/4b5PJd4ilxrRVSPOFKjAlDM4w2A
	e7omXVvhkR07wdaZTOQXBBnfdacJsnjUnNwatO3cXOzEov+BYwEXjvEBsFWWDpMPnKJ0bE
	Rh7AqvOyZtyq/mQu53e6Dj8RqS+FW8ytLvyBkcE7JIfcElwLOMJxpt3IdPEeMtrR6i1ipA
	L85yws7J83znBg3litzA570IbRaxTOPya+JOvMn7s98Y2sTGR7ykX9b7z8Geug==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655672420; a=rsa-sha256; cv=none;
	b=IkwCYBaUqX0GKHqUOT4CXP4logteOy3cTCNPACfFATtwg0Ds2x0tPpjPZcJRl/QoU0lWpF
	Z+31VGdI+3kjF4cqPBa1pwtRsRocaXg55rK2yNeah/xLx7rSbCtqDp0jWZLcSYCkynyh8H
	ddvYHEUK+M2RngkKR8jQojGvOM5mVth9rUbaHs/I7n5wFXjAmAB5irtE7UWEwaIioyKGtq
	evxPOpxtYoFeKnDSRC8KukpyAhcimWrqB9xcNVrBOUqQKW8sLo81LVYzEeaPLcMr7bimVD
	0cOkdvCZzpe6BNLMezRHWV52/5IuovwpoQCA9HGPp4bv/39+ZMSMAWzqll7VTg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16556724194.CB1C5d.56439
Date: Sun, 19 Jun 2022 21:00:19 +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.

--16556724194.CB1C5d.56439
Date: Sun, 19 Jun 2022 21:00:19 +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.


--16556724194.CB1C5d.56439--

From nobody Sun Jun 19 21:20:35 2022
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 5DD3A8647D9
	for ; Sun, 19 Jun 2022 21:20:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4LR5Kr1bcwz4hHX
	for ; Sun, 19 Jun 2022 21:20:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655673641; bh=appN3tXmlfSnN3FDjcIXDSAv0twnd5Ot2aAPliqxoD8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CoD3KG9fWB+mcuGhVNKXv+Jz0TklvYYBwddvO4IUKT68DB4DmK/1MOfgVQ+xsgqAFIM33w6d6OP1GzyvOweTTk9dlFWuZ0NIJ2JN1L8UFCRNWXNd9C1l8INPDJfz3h6dNdrAET25bPv9hXXbrS6ApU84Jjh6hK1uuq2tvXl2S7AWUgGyM7K9CsZMuGt2vQ/7I4fsKYATIzIcvpJXpuxtkqmC4POL8SO1avnQLYA2TFpgKy6ILGPuPpu/VMRJ+y/fobEBcDkuOOlvxkyyCncOtKjlgGrbqtr3oj7AH/jKJF7VO7/LSQE4nFvghqZalJCW6VBoYqL2MC5yj9hijuou9A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655673641; bh=LTZyoqFVWEm896vOkiOdTzb98sF69Rct6XpYaqcnSag=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SAEDTclTuhbvfvrar+YJwil+2pd4YbFDZ8wbkyPdi+CH035xXKj3iPKxpwEz2gyUERFaIvOPo2Qja8+gJxLemiP//pNvrs0CD4HTHG0Raa2X3a16cQYJDqYoUsBjMegIYeWMSytTmXYHbA5mde4CQBhdcoHvEYbN+RIb9u8RFGVDC7bajdZzaN8lU8o5IcO/gu3aErxzEWDLEpMyfen73u4L9462KoxNmRIsdqwUNfhAdr4BK6kElM7czQHTLG6rtnbHgRpW4qCQ6TtKyq2f67l2AUMjtQVCmKYcLC17szbxAedxOWrR5mCVpelp3L2Qnihz4I4OnLm0EKE5BEr/wA==
X-YMail-OSG: 0NKI.nsVM1nJzk6dRh70VOeukKOWs_4UvD4PjWjF7SBc.RjHnALrYD7UM.o201Y
 AoDFDjmtqpLasjjsTHlVYaBG0tRtSyKspTfBOo7SlFgYFsPuegoxizx5ZCFKBN9.c5ukearjEueB
 7coekHoH0Nq4njRpVAMNGYqAc7Tnifa6eI.ndaukmapG.FY8q.lF1gwoAzgZ1SHwEYXoD0nh41dt
 _O57ZUhVUWJTx6VbS3o1BF9_MaFWET2jmbfa8pdwvC2TO7tbb4rCXAypKYxmUhFKcpdwj3TtvSXr
 5WBQwGF67MpfD2UAqBSum9rrY10CX90Y6DPR9pwsxsOkt9TD39_Q9cMe.eLsYm_DbpHRh7eBGSpf
 7Cjs.PH0AnsH8tUfWtilg2rzVfp20TzoA0lY_7n3STehCLj_G0JUN.zg9ROOgZzyLbQ4dktukyE.
 3zY0RNwcRj2j33xAq8a7N49ABHCAga4WQtVgjgePCKNBrDupWkQpsiD.tNuSQowq8kQH3SpfPHU_
 uusDT5gaUm7wm7s7bfaNyFKEAx8jx8ogP._Ad7Mtd5BPfNdicWRcGklbgYbUhwfLeHKc2EMfskl7
 zPgRxg8S.TAnTLeYfhlI8NkMwIX_mKBIXr4J0Ms69bVagm95EP5meuYH1wo6O3PHO7VEY0uXkbpt
 k18SUYs6BjHrSPr1AUbNO0yrjX6uz2yOXkdbAPPtvBwI9_nbEAshETrXn6W_GMRsgN8oTaLOS71Y
 6giPMIuNKgJRkjHLT64BuPSwN4CxyXxqa0C47IMNqTrqrB_WlWaUY7x06Vm0La150jXS0XYFqV2t
 1ad9Yw.T90D_KDYK8euuwQvZQ8t8QwJkVIAgCp5JJrtN95sP6ph3l5o3DnZQBwFH91YATUbEfry5
 Ch.u3qyd1.1zFT2k320ko664aLfecQKNLo6wR7D1zwQ3Uo7teQgjbDvvdXNXxOvOxhveJByvX6v2
 UaNxzTJ5MBZOfRHPBoz6UFn1lKL9D8gi6Y.DrLqXEQE7angJ8VAwKqk9J_7WPBHvYtZaeygpS_X4
 Dn4t5utdUmtJnmiBQvYZUG7sa0r4jeX5YorwHvpXtgpCDULVrs0u8JLudmK306WK4SJiNvOuSqVw
 wav6edgsFE9zF89qJpTzA4Amkru4zeH4n3KW_JsJtYgkNMkdvm1plXpMaVO0C3lKvJIsrExaFS2H
 rkSg1Uku9u7ABcsnh_jFCK3DKeX5FctB.lcFOjSmqwQ_J5gXrnYZmGqjkaIUwdYoN6_JuFnE_I3q
 RcInqDheLvxqgZmqkrvHt.nFdOoeOf1VjpK5U5OkqLC.fibSZxj..fET84svJWrklXxV0_xNlpAz
 4o_._yMkCt8FRUgONiDSEBbgPOPBoKlGREpvwWVjOr8CLAVmQqHGmmwRvAufFGS8omAYv1LP9CNY
 z39VHkMqCXVfSRCzI8quetKT4qAJDy.SuVUf82sRp3l.c0jdIOIA06_N_avlq1t5CGgF0YPRVf7M
 8TsKnJ3OoJpUipoJQ.30Ernuod1yN1JEBaQ0CdcqQTACW0Lk4ZEpGENRZ.sSzRoM.HcsriYS8Yfa
 bHZ4Y9rZGD8p.g8tVNtxmOgPqc2i4RkiE1MdmM_dMjCq.3Yslao3HehUqwEeUu3xa956veiTGlk4
 9IqWnT9QjCX.oYfpBBwxV_EWPnfJx9zWzX9Pudf_oAHhJCUl1O__mBxRnMFHdzR.wF9VWZIExf32
 NH3.8QbQTr3dHyc_EMOBW9ZarNpfw9q.3EK20Sgg4h9L_U_BdbxPoxJ78Stx_GykJdHfGyfFt2a5
 eAVe1bzDtB7fjODnsSAvpLwaxOXoRFDuIaNlrC81t6uzr3wje29MW36HP0dx0W6881jbov8mUHao
 Fjrushss8UFtcyjsQz4wi9b_CYM.oPObaZIYyXIjRJqJD6Yb4gOGsemV9qlQWBFW03XvgSbO5ATA
 h1g2LfdenA9pAxTr5gu1lC41qut1NN.7e7KJO.1x2ly5ULbcmCeZSELvGJZncKMQlHLL9eju5jFA
 9bkyUlfYWsNqKfZLwWdQXTG64dAgMImvTSEIpJ.C4CFPtqPwcJ2WVLGjR6cnt9XeRlimV3DoHS.l
 2nnmycbmVHGqVnbnB1QpZ4xdjyv7pI2GCRGnzTo5a5j076l8R8Rb85z8JFS9_UdJy1mBrfUkYsly
 ecO2W27ql_3PxtSawsYeAnVcLbW7upKtYpKi97ezW3if1HFXzQigkmFNOX2RLS3F0ufrvwEr9EnH
 5CgiH5rHpQF6bV3XTMi7pC5vM12zx_1vQv8jCBIM4GHHuewz9yPZTrRq57yTsE7KCzQloaYzdsoV
 FwuT2IG5PHoWB2a.1ld3uSnndE815QN2CFEVt64rzxvAzzQ7CBnvEb4vMsGh0ZOb7RP8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Jun 2022 21:20:41 +0000
Received: by hermes--canary-production-gq1-677bd878b7-85vm8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bc8501b21ade799736a2e9bda0691852;
          Sun, 19 Jun 2022 21:20: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220619042225.GA2267@www.zefox.net>
Date: Sun, 19 Jun 2022 14:20:35 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LR5Kr1bcwz4hHX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CoD3KG9f;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-18, at 21:22, bob prohaska  wrote:

> On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
>> I finally started my round of updates from:
>>=20
>> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
>>=20
>> to:
>>=20
>> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
>>=20
>> So far all the UFS media that I've tried (older and newer)
>> have worked fine with the update, including fsck_ffs not
>> finding any problems.
>>=20
>> It does not appear that I'll end up replicating your problem.
>>=20
>=20
> When one invokes fsck at the single-user root prompt what actually
> gets used on a UFS filesystem? Maybe I've got a name problem.....
>=20

The below is for a single-user boot, showing:

A) That / is already read-only at that point
B) A fsck_ffs that just reports (no repairs)
C) A fsck_ffs that repairs (and reports)

The context that was handy was not a RPi* but that
should not matter.

Note that I avoid being the one to type a device
path to the root partition: I just use "/" and let it
find the partition it is already using for the
boot sequence.

. . .
Enter full pathname of shell or RETURN for /bin/sh:=20
# mount
/dev/gpt/CA72optM2ufs on / (ufs, local, noatime, read-only)
devfs on /dev (devfs)
# fsck_ffs -n /
** /dev/gpt/CA72optM2ufs (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 =
blocks, 0.2% fragmentation)
# fsck_ffs -y /
** /dev/gpt/CA72optM2ufs
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 =
blocks, 0.2% fragmentation)

***** FILE SYSTEM IS CLEAN *****
#=20

I will note the warning about -y use (in the man page for
fsck_ffs):

     -y      Assume a yes response to all questions asked by fsck_ffs; =
this
             should be used with great caution as this is a free license =
to
             continue after essentially unlimited trouble has been
             encountered.

So, if at some point you had -y "repair" a large number
of issues, it might have included bad repairs based on
already bad data. (Such could be an automatic repair,
rather than one manually run.)

However, the (lack of) background knowledge for answering
each question and the volume of questions that can
happen, tends to lead to -y use, even for manual runs.


Note: recovering from a building power outage sequence
      and other issues delayed getting to this.

But the power outage sequence happened after a 8 GiByte
RPi4B had spent between 17 and 18 hours short of 3 weeks
working on a "bulk -a -c", having built 16343 ports (and
171 failures) in the UFS context. The automatic fsck
that happened once power stayed on took a rather long
time for the large number of repairs involved, likely
slowed by the serial console scrolling the reports.

(The bulk run was an experiment with building for armv7
and the results were not to be kept.)


Side note on RPi2's/RPI3's:

https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/

reports for Fedora's default configuration choices:

QUOTE
The serial console is disabled by default on the Raspberry Pi 2
and 3 because it requires the device to run at significantly
slower speeds.
END QUOTE

I've never explored the specifics of the tradeoffs involved
and they do not seem to document them. (I assume this is more
than normal serial output related time. But I'd also expect
that it is not something fedora specific.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jun 21 19:24:48 2022
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 7D6EF87318E
	for ; Tue, 21 Jun 2022 19:24:57 +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 4LSGgD1mztz4gk1
	for ; Tue, 21 Jun 2022 19:24:56 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25LJOmPf002455
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 21 Jun 2022 12:24:49 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25LJOmQJ002454;
	Tue, 21 Jun 2022 12:24:48 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 21 Jun 2022 12:24:48 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Free BSD 
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220621192448.GA1874@www.zefox.net>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net>
 <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@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: <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
X-Rspamd-Queue-Id: 4LSGgD1mztz4gk1
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [2.49 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.956];
	 NEURAL_SPAM_SHORT(0.55)[0.547];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(1.00)[1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote:
> On 2022-Jun-18, at 21:22, bob prohaska  wrote:
> 
> > On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
> >> I finally started my round of updates from:
> >> 
> >> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
> >> 
> >> to:
> >> 
> >> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
> >> 
> >> So far all the UFS media that I've tried (older and newer)
> >> have worked fine with the update, including fsck_ffs not
> >> finding any problems.
> >> 
> >> It does not appear that I'll end up replicating your problem.
> >> 
> > 
> > When one invokes fsck at the single-user root prompt what actually
> > gets used on a UFS filesystem? Maybe I've got a name problem.....
> > 
> 
> The below is for a single-user boot, showing:
> 
> A) That / is already read-only at that point
> B) A fsck_ffs that just reports (no repairs)
> C) A fsck_ffs that repairs (and reports)
> 

My question is perhaps more naive than you expected 8-)

I'm just asking how we get to fsck_ffs (or _whatever) from
fsck. There's no explanation I recognize in the fsck man
page, though fsck_ffs is mentioned in the fsck man page.

> The context that was handy was not a RPi* but that
> should not matter.
> 
> Note that I avoid being the one to type a device
> path to the root partition: I just use "/" and let it
> find the partition it is already using for the
> boot sequence.

My habit has so far been the reverse, on the notion
that if root isn't where I expect I'd like to know.
Next time things don't work as expected I'll try /.

> 
> . . .
> Enter full pathname of shell or RETURN for /bin/sh: 
> # mount
> /dev/gpt/CA72optM2ufs on / (ufs, local, noatime, read-only)
> devfs on /dev (devfs)
> # fsck_ffs -n /
> ** /dev/gpt/CA72optM2ufs (NO WRITE)
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 blocks, 0.2% fragmentation)
> # fsck_ffs -y /
> ** /dev/gpt/CA72optM2ufs
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 blocks, 0.2% fragmentation)
> 
> ***** FILE SYSTEM IS CLEAN *****
> # 
> 
> I will note the warning about -y use (in the man page for
> fsck_ffs):
> 
>      -y      Assume a yes response to all questions asked by fsck_ffs; this
>              should be used with great caution as this is a free license to
>              continue after essentially unlimited trouble has been
>              encountered.
> 
> So, if at some point you had -y "repair" a large number
> of issues, it might have included bad repairs based on
> already bad data. (Such could be an automatic repair,
> rather than one manually run.)
> 
> However, the (lack of) background knowledge for answering
> each question and the volume of questions that can
> happen, tends to lead to -y use, even for manual runs.
> 
> 

I've never seen any discussion of how to answer fsck's questions
and thought the knowldege required became extinct with the end of
ST506 disks 8-)


> Note: recovering from a building power outage sequence
>       and other issues delayed getting to this.
> 
> But the power outage sequence happened after a 8 GiByte
> RPi4B had spent between 17 and 18 hours short of 3 weeks
> working on a "bulk -a -c", having built 16343 ports (and
> 171 failures) in the UFS context. The automatic fsck
> that happened once power stayed on took a rather long
> time for the large number of repairs involved, likely
> slowed by the serial console scrolling the reports.
> 
> (The bulk run was an experiment with building for armv7
> and the results were not to be kept.)
> 
> 
> Side note on RPi2's/RPI3's:
> 
> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
> 
> reports for Fedora's default configuration choices:
> 
> QUOTE
> The serial console is disabled by default on the Raspberry Pi 2
> and 3 because it requires the device to run at significantly
> slower speeds.
> END QUOTE
>

That's quite a surprise. 

Thanks for writing!

bob prohaska


From nobody Tue Jun 21 19:45:23 2022
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 CDEED875EC8
	for ; Tue, 21 Jun 2022 19:45:37 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LSH746GRXz4jf9
	for ; Tue, 21 Jun 2022 19:45:36 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 6BEBC7E60A;
	Tue, 21 Jun 2022 15:45:25 -0400 (EDT)
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 \(3696.100.31\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Paul Mather 
In-Reply-To: <20220621192448.GA1874@www.zefox.net>
Date: Tue, 21 Jun 2022 15:45:23 -0400
Cc: Mark Millard ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E37B905-2627-469A-BA20-32FD79F8D12D@gromit.dlib.vt.edu>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
To: Free BSD 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LSH746GRXz4jf9
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 2001:468:c80:a103:2:5000:5555:5555) smtp.mailfrom=paul@gromit.dlib.vt.edu
X-Spamd-Result: default: False [0.51 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none];
	 FREEFALL_USER(0.00)[paul];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-0.15)[-0.150];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.84)[-0.836];
	 NEURAL_SPAM_LONG(1.00)[1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US];
	 FREEMAIL_CC(0.00)[yahoo.com,www.zefox.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Jun 21, 2022, at 3:24 PM, bob prohaska  wrote:

> On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote:
>> On 2022-Jun-18, at 21:22, bob prohaska  wrote:
>>=20
>>> On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
>>>> I finally started my round of updates from:
>>>>=20
>>>> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
>>>>=20
>>>> to:
>>>>=20
>>>> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
>>>>=20
>>>> So far all the UFS media that I've tried (older and newer)
>>>> have worked fine with the update, including fsck_ffs not
>>>> finding any problems.
>>>>=20
>>>> It does not appear that I'll end up replicating your problem.
>>>>=20
>>>=20
>>> When one invokes fsck at the single-user root prompt what actually
>>> gets used on a UFS filesystem? Maybe I've got a name problem.....
>>>=20
>>=20
>> The below is for a single-user boot, showing:
>>=20
>> A) That / is already read-only at that point
>> B) A fsck_ffs that just reports (no repairs)
>> C) A fsck_ffs that repairs (and reports)
>>=20
>=20
> My question is perhaps more naive than you expected 8-)
>=20
> I'm just asking how we get to fsck_ffs (or _whatever) from
> fsck. There's no explanation I recognize in the fsck man
> page, though fsck_ffs is mentioned in the fsck man page.


The fsck man page (at least the one currently on 13-STABLE) says this:

     If no file systems are specified, fsck reads the table /etc/fstab =
to
     determine which file systems to check.  Only partitions in =
/etc/fstab
     that are mounted =E2=80=9Crw=E2=80=9D, =E2=80=9Crq=E2=80=9D or =
=E2=80=9Cro=E2=80=9D and that have non-zero pass number
     are checked.  File systems with pass number 1 (normally just the =
root
     file system) are always checked one at a time.

and this:

     If the -t or -T flags are not specified, fsck will attempt to =
determine
     the file system type and call the appropriate file system check =
utility.
     Failure to detect the file system type will cause fsck to fail with =
a
     message that the partition has an unknown file system type.


I don't know what precise mechanism fsck uses to determine which =
fsck_XXX binary to invoke to check a file system, but I can posit at =
least two possibilities:

1) It uses the "FStype" field from /etc/fstab as its guess;

2) More likely, it invokes "fstyp" to detect what file system the device =
contains.

The fstyp man page includes this description:

     The fstyp utility is used to determine the filesystem type on a =
given
     device.  It can recognize BeFS (BeOS), ISO-9660, exFAT, Ext2, FAT, =
NTFS,
     and UFS filesystems.  When the -u flag is specified, fstyp also
     recognizes certain additional metadata formats that cannot be =
handled
     using mount(8), such as geli(8) providers, and ZFS pools.


E.g.:

# fstyp /dev/mirror/efi
msdosfs
# fstyp /dev/mirror/swap
fstyp: /dev/mirror/swap: filesystem not recognized
# fstyp -u /dev/gpt/zfs0
zfs


Cheers,

Paul.

PS: This guess is worth what you paid for it. :-)=

From nobody Tue Jun 21 19:55:22 2022
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 6CD118772DD
	for ; Tue, 21 Jun 2022 19:55:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4LSHLb1P5zz4kq3
	for ; Tue, 21 Jun 2022 19:55:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655841327; bh=2P1m9pMTtw144KSa8xaOzHCZOxOhyqnUEIRh9ON2fMM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WrFfP2AZxvE44mJwBhDDjG0nZDrG5UTTYxHX/bt3LGuyX1lkzg9RmrJAccCHMr+UI7LQObynRLo7xmbXZL9gkkQUiFDoIgfaxucJN4AKDHjRPVhBGqBHULoSjvz+VRibLU+ZWRyiGG1Av89j/ixDU2afOxnZ6GHMkSruyr/VgFpLLACBPmft6tkAWX22KiiNXPSYHNj9DW/MWqZGjtvMTdRFTlC1PRypQfD45wNtiCMYdIymL5y4C7jhJzGKQX3Zu9fZyzcSR9q1tUj/sKSnbrET65Q4MWJlDm3I4/OwPGqa1MLuI7oR2LVui9hkDhfmI7BOR7usMQNc7v1A0ndPrQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655841327; bh=02jbhM0fbwA8HvLWI5yll8oQp6UTZst7l90pNC3qkQN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZAlY+F9tyAB18r96BYn5spNxXqKqVqQYCdQmja3MQaHDwXeH1x3bPDXQFAOXH/gMojoPb0B4YKjCwF+AtxYyjjho6D3KMFFu0Le2QdaowdvoWlLXvO10eSi+pt+6JfDbYqTx5s1AZjLHYhiN6J97yxGdHAi14wVZ28rT+eEHa9DseDDRN7Xm2nS83W0Q0ynZE+Sgkm/svRUmPnMBziaf4CdszaNZan5nKU5eeoWfKclThF5GQAHwW0bFXF1dQhNtp8SAS1o0MsB7jXsbSZN/KghTD3lA16tNrT+dZn5QTROL8OgcS42x9SILiXdS6+b0NVKWoXS14s5g0lw2SZQ63Q==
X-YMail-OSG: VskcXmkVM1lL.MKrJfk2kUrRiOh1cpSItoqqUefG.y5TlQHcHYf8zJ47x7qFe5O
 KY7rGFxvB8Bn5B8ytTlflMlCYKNdAI.7KqRkOYmhx3v0fdNLDMnKEEuzUteIVs25w4fX_EQvu.Dd
 rZO1koGY.3iK3a9VXCYavuAjXXnGXx31_Z8Ppm5xUx6tG8M3FdcYYfPE3NiUOUQ8bOWEUagrXZ38
 o04lZ0x80wd0MZQSzhHYxcqSLtiREThnIeiVNeb06ZpkCn8y4HGp5P1zxKbwfswi4tbSkCCsvrG7
 Kic1sV43MZl6dRLAp7vNJi_8dugjFlIjvPz.28fp.QO6SFTZAWc2MzKLk8KPbRQBxpK.KiWyjs3I
 h3chTh9fyGHwpU2VmSG_1wP9WYK7vWIA021Cq8i4qd1a9w6YRWLYmkJFoc9KfUu0voBG82_46io5
 st239fUilvvcrjaYKM9Luzp4rxAmcpO3IscdsCNukw1VRBRFetvOAyGyoLb69vjL_nkyVzVZvevl
 MBYZIL4h.JzoOKzqgc5p2BtzjhNAFhpQGBD_SbZJU1gV9GXc41ERejMSc6kvt1YH_3zl287jR9S6
 n6s2BISQZTFApZkhGt090X3g5FbYGNnnD1EEdJxfmjW_S3Tzhb07GxwJup9w4.0sLYUqsSEecshx
 iAFtiRzElj3FHP0q.uezI4r2VGnFDJ8yyvwWm2m2kjueuru578.F0uZntNqA.c8G76HD3140A68s
 t9YNan3blv8dlu4.mJHkMnpALmNuQApkBUGVJLD28tsLVAJmk.LzzYd2jx0OdB46PqRHS4gOiHfq
 c4yRNBP5KxRWipDLfQEDh1Sqq5dlljNDGIeGdvjpwk9VvDI9_X4qdMiX9uLNCc60BreynLcEoMB8
 WVTtjRWZU1G4qm2B3wzF0T.J5GnwQcvC5GpOuzzLw.1hV2SuPId79F31pVdJ6eSMQdQtu9aL2h2.
 LyZUYp3yGF.OPMzjcBkMHlCBF0ztSZJgmN3guTgZ0gNtkl7FQqX1mMxObGAUUxNNTtyhKSX.eI4U
 pAWBp_kUGr2I4l.avXVZwMg6d5KRCqYZHYYbnjlLKPjUGVtrsbUkI_diVgOmfqXc7uy5mqrYNghp
 vs1aJkScvC5WSpdmio7okePjxkt2p.cuC3dIbAChAcfY0cmLocgJnihzjg6PuT_kC9aKo4pqoSeY
 _9vqY7iMiszfmgFeQFgVlrl1o87uehttdCuu3A2l7RFV21WCohLuIv8x70YIRBD93ywGJH3_yJpe
 V3Oine2iZpGScY4VEfmz.6A02q5rf59.vDCKC0QQBrEraJRZeWNVbJo82NXXa46cu3Gk1dssnrVU
 g_K.agIydEvPDF0lnUYC0Ze1APa15Z3Mf9GFLWNepkzbUndb.pd2mG2ZzKwYTvKPuxJQ3hdU9ZpA
 4oIY3jAzfJQLU2loUU4GR3Ziln2Yw4uajBvFdtdi2LJAY_kBt.JFKQuzC2wieXsrBxzc8wMuf5YY
 qth40zZN4umZNIs1qiCcvMWx9IaVyV6v9oDXzUzyIINFHLJBJ0TesuubRcoLpq6bMGng.ZiAJ5bK
 TahGPDCdE3B1C9wdEz1lHl7ER_jsruo4uASiOJz3_okXOs6eMDknZhFAEtVlpOgmqC6LXqZhAGiu
 kGNrZ27jqJr2M.hx9d57Wf4GtD0zXbMnlm09_h1zAjUalOmTCEjHX3EkfSlA_AGIbuZlgoZz_z0W
 .705SVXMSLgiHThEp0G56hcE0NZq1b3egS9dIqb_GhEiYdjzCvrw9RfoE6CtzyiSvSupin9THfBT
 .5jCyZUrIbGacliER2zJC0i8bynPjvtUv6YusKCQ3QUdPmBzhybe0INv0HVgqdz2KLrwOsz2oyju
 7Y8XDHJJH1My9lfz5IXr98oU9csGdZ9ca7No1K7o.WvrgJcYloyJ.v7LGgpBjhqa8HYKz5Ktonm8
 Zjr_.eZr5wIeM5H2BLQ26GN7empYEIlHO9DqHNI0qxlPhJ2AI.08ioOBoPmFOCbEpW0pZY7yyafq
 vReHTW1gTihdg84ydFS4zb.3B.PyLGzI79pm6foTC0kHcu0gf4A34cNzofWg5WIoT5Diu9dHoSW8
 hanTct98BlsrIwXSJYMTx6OjXFUWSZTATtTU8YySexCJfuN6_dUZTC01ogRiFtf70rvXVXAbJROB
 fWVon4NfVI7LPqf8Ys3TAaWhRauaMA2oSAP_p.P7_zA3bluvsSLfRL4RclWHDCN_qs6MycZgpG9v
 Ty3qhUzL4.NUh_xFvxl8hJxg14KQgU1WTUNzurKJRWY68PIFQOixynROiIE7X2ZkU8BcXfmvaIq6
 BI0B4QiZtDC60Bivn9DxSufXGzP2BeDA.dbL0f6guJvltrcOqhY5STZcrARH7H3M-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Jun 2022 19:55:27 +0000
Received: by hermes--canary-production-ne1-6b56569f5b-q4ddm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9ba34ff29d655c1d76ce2046826c0b93;
          Tue, 21 Jun 2022 19:55:24 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220621192448.GA1874@www.zefox.net>
Date: Tue, 21 Jun 2022 12:55:22 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LSHLb1P5zz4kq3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=WrFfP2AZ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-0.93)[-0.933];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-21, at 12:24, bob prohaska  wrote:

> On Sun, Jun 19, 2022 at 02:20:35PM -0700, Mark Millard wrote:
>> On 2022-Jun-18, at 21:22, bob prohaska  wrote:
>>=20
>>> On Sat, Jun 18, 2022 at 03:54:19PM -0700, Mark Millard wrote:
>>>> I finally started my round of updates from:
>>>>=20
>>>> main-n255745-77649f35a7e5-dirty: Sat May 21 18:48:32 PDT 2022
>>>>=20
>>>> to:
>>>>=20
>>>> main-n256189-4014365e4219-dirty: Sat Jun 18 01:47:44 PDT 2022
>>>>=20
>>>> So far all the UFS media that I've tried (older and newer)
>>>> have worked fine with the update, including fsck_ffs not
>>>> finding any problems.
>>>>=20
>>>> It does not appear that I'll end up replicating your problem.
>>>>=20
>>>=20
>>> When one invokes fsck at the single-user root prompt what actually
>>> gets used on a UFS filesystem? Maybe I've got a name problem.....
>>>=20
>>=20
>> The below is for a single-user boot, showing:
>>=20
>> A) That / is already read-only at that point
>> B) A fsck_ffs that just reports (no repairs)
>> C) A fsck_ffs that repairs (and reports)
>>=20
>=20
> My question is perhaps more naive than you expected 8-)
>=20
> I'm just asking how we get to fsck_ffs (or _whatever) from
> fsck. There's no explanation I recognize in the fsck man
> page, though fsck_ffs is mentioned in the fsck man page.

One way to notice the fsck_ffs man page:

# man -k fsck
git-fsck(1) - Verifies the connectivity and validity of the objects in =
the database
git-fsck-objects(1) - Verifies the connectivity and validity of the =
objects in the database
fsck(8) - file system consistency check and interactive repair
fsck_ffs, fsck_ufs, fsck_4.2bsd(8) - file system consistency check and =
interactive repair
fsck_msdosfs(8) - DOS/Windows (FAT) file system consistency checker

fsck_ffs is a separate command. fsck is a wrapper that can
put fsck_ffs to use:

QUOTE (from man fsck)
HISTORY
     A fsck utility appeared in 4.0BSD.  It was reimplemented as a =
filesystem
     independent wrapper in NetBSD 1.3 and first appeared in FreeBSD =
5.0.  The
     original filesystem specific utility became fsck_ffs(8) at this =
point.
END QUOTE

QUOTE (from man fsck)
     -T fstype:fsoptions
             List of comma separated file system specific options for =
the
             specified file system type, in the same format as mount(8).
END QUOTE

Using fsck_ffs directly has more explicit options, such as:

QUOTE (from man fsck_ffs)
     -E      Clear unallocated blocks, notifying the underlying device =
that
             they are not used and that their contents may be discarded. =
 This
             is useful for filesystems which have been mounted on =
systems
             without TRIM support, or with TRIM support disabled, as =
well as
             filesystems which have been copied from one device to =
another.

             See the -E and -t flags of newfs(8), and the -t flag of
             tunefs(8).
END QUOTE


>> The context that was handy was not a RPi* but that
>> should not matter.
>>=20
>> Note that I avoid being the one to type a device
>> path to the root partition: I just use "/" and let it
>> find the partition it is already using for the
>> boot sequence.
>=20
> My habit has so far been the reverse, on the notion
> that if root isn't where I expect I'd like to know.

I took the context as requiring that I (first?) check
that the boot file system in actual use. Later other
checks might be done.

> Next time things don't work as expected I'll try /.
>=20
>>=20
>> . . .
>> Enter full pathname of shell or RETURN for /bin/sh:=20
>> # mount
>> /dev/gpt/CA72optM2ufs on / (ufs, local, noatime, read-only)
>> devfs on /dev (devfs)
>> # fsck_ffs -n /
>> ** /dev/gpt/CA72optM2ufs (NO WRITE)
>> ** Last Mounted on /
>> ** Root file system
>> ** Phase 1 - Check Blocks and Sizes
>> ** Phase 2 - Check Pathnames
>> ** Phase 3 - Check Connectivity
>> ** Phase 4 - Check Reference Counts
>> ** Phase 5 - Check Cyl groups
>> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 =
blocks, 0.2% fragmentation)
>> # fsck_ffs -y /
>> ** /dev/gpt/CA72optM2ufs
>> ** Last Mounted on /
>> ** Root file system
>> ** Phase 1 - Check Blocks and Sizes
>> ** Phase 2 - Check Pathnames
>> ** Phase 3 - Check Connectivity
>> ** Phase 4 - Check Reference Counts
>> ** Phase 5 - Check Cyl groups
>> 2019019 files, 45278396 used, 116718936 free (345928 frags, 14546626 =
blocks, 0.2% fragmentation)
>>=20
>> ***** FILE SYSTEM IS CLEAN *****
>> #=20
>>=20
>> I will note the warning about -y use (in the man page for
>> fsck_ffs):
>>=20
>>     -y      Assume a yes response to all questions asked by fsck_ffs; =
this
>>             should be used with great caution as this is a free =
license to
>>             continue after essentially unlimited trouble has been
>>             encountered.
>>=20
>> So, if at some point you had -y "repair" a large number
>> of issues, it might have included bad repairs based on
>> already bad data. (Such could be an automatic repair,
>> rather than one manually run.)
>>=20
>> However, the (lack of) background knowledge for answering
>> each question and the volume of questions that can
>> happen, tends to lead to -y use, even for manual runs.
>>=20
>>=20
>=20
> I've never seen any discussion of how to answer fsck's questions
> and thought the knowldege required became extinct with the end of
> ST506 disks 8-)

I assume that the primary folks that work on UFS
changes (and historically did so) would have a
clue.

>> Note: recovering from a building power outage sequence
>>      and other issues delayed getting to this.
>>=20
>> But the power outage sequence happened after a 8 GiByte
>> RPi4B had spent between 17 and 18 hours short of 3 weeks
>> working on a "bulk -a -c", having built 16343 ports (and
>> 171 failures) in the UFS context. The automatic fsck
>> that happened once power stayed on took a rather long
>> time for the large number of repairs involved, likely
>> slowed by the serial console scrolling the reports.
>>=20
>> (The bulk run was an experiment with building for armv7
>> and the results were not to be kept.)
>>=20
>>=20
>> Side note on RPi2's/RPI3's:
>>=20
>> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
>>=20
>> reports for Fedora's default configuration choices:
>>=20
>> QUOTE
>> The serial console is disabled by default on the Raspberry Pi 2
>> and 3 because it requires the device to run at significantly
>> slower speeds.
>> END QUOTE
>>=20
>=20
> That's quite a surprise.=20
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jun 22 21:53:03 2022
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 D35EE872D36
	for ; Wed, 22 Jun 2022 21:53:03 +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 4LSxvg3v0Hz4YpT
	for ; Wed, 22 Jun 2022 21:53:03 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 659A46713
	for ; Wed, 22 Jun 2022 21:53:03 +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 25MLr3Rq067893
	for ; Wed, 22 Jun 2022 21:53:03 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25MLr3AA067892
	for freebsd-arm@FreeBSD.org; Wed, 22 Jun 2022 21:53:03 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 264836] arm/arm/busdma_machdep-v6.c: bounce page accounting
 leak (noticed with high traffic ftdi usb serial devices)
Date: Wed, 22 Jun 2022 21:53:03 +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: 13.1-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: jcfyecrayz@liamekaens.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655934783;
	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=u6w6rUBZ1LBlMAZDbhBLHw01QlRb0Zv4m1gdX0zcN0c=;
	b=tHOKRRKe/MVljzBfuttphb3RIiUPuIS0D7YM4sHGr6ewTF/F1FNPT83M1YDM4X0tYg+HRL
	0qPNVZZhNkUvqDctY9aBm5kicPmNlgcflep0GKsYEe8il5Ot7hZqEFf0utilpuIcU03blN
	ctcd6reCw02BpuBg7GqYCh1LhA0NKH1Sd8lurKVlL7LRTaHhZ9LsT8ddpzTwMcyiJVWT5g
	AR7vdXOE0uyb6hCtfxROA3Mhbsjw34SpTEQnz0rLjU3BIgjUnovAFX31pji5zD9AKHEZy6
	1/4xWLtaD8wkNv/3MyoexX68iwg8Z9IFbb2O33woHqrEHVYHyeTxh/2N1M16Uw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655934783; a=rsa-sha256; cv=none;
	b=FGTCrvVizLkb1g99pwZnQsBLChKgwaNjRjuZzbIMmPNC/Mq+Jtq43rlnoy++f5WkRsaa/w
	bwYAffbcBaQR1eAy9EcoKDFcE+zP932jGAF4qdCsN5zHXX9ZLbmkA+y2FnKETHW1uvL1n4
	gNonJJm7IbFcA4AuzStCAyYXNPVv2bX3XQGrM4fMIAWY7MUh2QQCClrFEsW8HIZTvrqBEp
	arFaJg9RB8Y+YZqQR7kKIA0jv9hPZZcJ0OvjAtfN+3oYqEGE+RTkDj9RC16IOpVg8c8hf2
	b6rX5KAMneUqZYqBmZBgSYXrhaKwvQbPd4G1VklwqRn3jqCahBy0p8UvC3P7tw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264836

            Bug ID: 264836
           Summary: arm/arm/busdma_machdep-v6.c: bounce page accounting
                    leak (noticed with high traffic ftdi usb serial
                    devices)
           Product: Base System
           Version: 13.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jcfyecrayz@liamekaens.com

In bus_dmamap_unload(), the counters for free_bpages and reserved_bpages ap=
pear
to be vulnerable to unprotected read-modify-write operations that result in
accounting that looks like a page leak.

This was noticed on a 2GB quad core i.MX6 system that has more than one dev=
ice
attached via FTDI based USB serial connection.  This system happens to be u=
sing
FTDI US4232H quad port chips, but the problem is more general.

There is a latency timer setting in FTDI chips that is used to set the inte=
rval
at which short packets of data are flushed from the USB endpoint by the FTDI
chip (which has some internal buffer memory).  The default latency is 16 ms=
.=20
We had set the latency to 4 ms to get data more quickly.

We started noticing problems with slower USB responses and eventually the
network stack would be affected as well.  In the system in question, it fai=
rly
reliably "locked up" (couldn't ssh any more, trouble spawning processes when
logged in on the serial port).

In the locked up state, the usb/usbus0.xplr thread of the usb system process
was hung and the system could not process usb messages (this i.MX6 system h=
as
an ehci USB controller).

The typical stack dump for usbus0.xplr when things were hung is:

   13 100029 usb                 usbus0.xplr         sched_switch+0x9d4
mi_switch+0x184 sleepq_wait+0x2c _cv_wait+0x1bc usbd_do_request_flags+0x4bc
usbd_req_get_port_status+0x44 uhub_explore+0xc4 uhub_explore+0x8f8
uhub_explore+0x8f8 usb_bus_explore+0x150 usb_process+0x124 fork_exit+0xc0
swi_exit+0

Once we noticed that hw.busdma.zone0.free_pages was steadily decrementing -
eventually down to zero - we started investigating (dtrace was helpful here)
why there appeared to be a leak of bounce pages.

That's when we found what appears to be the vulnerability in
bus_dmamap_unload().  This code has been this way for more than a decade, b=
ut
it takes a lot of transactions for this to occur and was particularly hard =
to
find.  For a long time, we would work around the problem by detecting the
symptoms and just reboot this system to recover - hardly ideal.  It would t=
ake
weeks to months depending on USB traffic load.  Adjusting the FTDI latency
timer to 0 ms (force packet delivery on every high speed microframe) finally
made this happen more quickly.

Even if someone else has enough traffic to experience the same problem,=20

I will submit a patch for review.  Early results seem promising (in particu=
lar
the free bounce page accounting now does not show what looks like a leak).

This was originally noticed quite a while ago on 11.x, but it has been
confirmed on 13.x as well.

As an indication of system load, with the 0 ms latency timer we see more th=
an
100 bounce pages per second (based on hw.busdma.zone0.total_bounced), and t=
he
load due to interrupts is about 15%.  The high rate of bounce page and
interrupt activity gives lots of good opportunity for preemption at just the
right time to trigger the accounting leak.

Work sponsored by: Microchip Technology, Inc.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Jun 22 23:23:11 2022
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 258E88606D8
	for ; Wed, 22 Jun 2022 23:23:12 +0000 (UTC)
	(envelope-from daemon-user@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 4LSzvg6mDtz4l2G;
	Wed, 22 Jun 2022 23:23:11 +0000 (UTC)
	(envelope-from daemon-user@freebsd.org)
Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:606c::16:b])
	by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id 9B0927B68;
	Wed, 22 Jun 2022 23:23:11 +0000 (UTC)
	(envelope-from daemon-user@freebsd.org)
Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346)
	id 9A49C2891F; Wed, 22 Jun 2022 23:23:11 +0000 (UTC)
Date: Wed, 22 Jun 2022 23:23:11 +0000
To: Phabricator 
From: "rfyu28uyeg_snkmail.com (John Hein)" 
Cc: freebsd-arm@freebsd.org
Reply-to: "rfyu28uyeg_snkmail.com (John Hein)"
 
Subject: [Differential] D35553: protect arm busdma bounce page counters with bounce page lock
Message-ID: <076fbbef1e10018b84b27c7fc05cc395@localhost.localdomain>
X-Priority: 3
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: , , , 
X-Herald-Rules: <28>, <31>
X-Phabricator-Projects: <#arm>
X-Phabricator-To: 
X-Phabricator-To: 
X-Phabricator-To: 
X-Phabricator-To: 
X-Phabricator-Cc: 
X-Phabricator-Cc: 
X-Phabricator-Cc: 
X-Phabricator-Cc: 
Precedence: bulk
Thread-Topic: PHID-DREV-t62r2jryxp6wkotvmxh2
X-Phabricator-Mail-ID: 3231842
X-Phabricator-Send-Attempt: xugswkkk542wvsuq
In-Reply-To: 
References: 
Thread-Index: YjNhOGUyMmQwODA3NjNhNzUzYzczZjViNGM2IGKzpF8=
X-Phabricator-Stamps: actor(@rfyu28uyeg_snkmail.com) application(Differential) author(@rfyu28uyeg_snkmail.com) herald(H28) herald(H31) monogram(D35553) object-type(DREV) phid(PHID-DREV-t62r2jryxp6wkotvmxh2) reviewer(@hselasky) reviewer(@jhb) reviewer(@mjg) revision-repository(rG) revision-status(needs-review) subscriber(@andrew) subscriber(@freebsd-arm-list) subscriber(@imp) tag(#arm) via(web)
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/mixed;
	boundary="b1_076fbbef1e10018b84b27c7fc05cc395"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655940192; h=from:from:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:in-reply-to:in-reply-to:  references:references;
	bh=vWfUp64aYG2O0OkjcQZkDysvIbPCvhQAe35jca/BJiw=;
	b=kgpEexdPKseXjB4uog+YyqV/7zCbV3PAIglXnsDkKo/r4EI7rzA9refySQbICLeyrBYeze
	Ne8ixtU2dfx8v8mZkIichLbZx2i7ou4lQmQitoXBJb61aeV0+jykgMdha1UBwRAG/2hoQo
	Wu3GcZxbbeODesrHjOaYXNyHGunJxZs/fdT1CK4arehC2cxUzQPOidHBUVFoynskmdeheg
	w+k2bJkdLCa/CZ/pi7EnOghdhbdR2QX6SQHuzHVWhqrSKWna6tnVrJ0hthR2RhejNNq1gM
	fjJwUTGtbTKsjUgygLhHPAHTY3F7MlrRlhVzF9B20uRMrOUtwmnY91xtIA2C4g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655940192; a=rsa-sha256; cv=none;
	b=K4k3+ujqK2ThppL3m8VmlXlNG4/LuqQqiE6O1jCb5PhKGueIUWQR2hU3Kea8pK+zGSDHTJ
	65GbzD/ZWwoLJml+XHBrkpzE/jtZY51Bt2ZwTh2oVzQ8kUhempAprid3Yn7Kh5h+Ruq482
	gt1nlOUr+dGJtocvLrjVFYY+Loa8QlbM3ZrsvWx8ADDXgcrQGJD/Ty74A8hmLdos5iTzSR
	JzZkiT46REhcjpcY/Bx2vHVOJEGqggBS67yGNjI8KzsgsBPWXKCwdMDsYgIKUskz0pOZsP
	bfPtp1XN2iE4dO3/DvgF0eagepnhKPNyiidv93ans/jE8vhq+DvqExMGihTfmg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--b1_076fbbef1e10018b84b27c7fc05cc395
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: base64

cmZ5dTI4dXllZ19zbmttYWlsLmNvbSBjcmVhdGVkIHRoaXMgcmV2aXNpb24uCnJmeXUyOHV5ZWdf
c25rbWFpbC5jb20gYWRkZWQgcmV2aWV3ZXJzOiBtamcsIGhzZWxhc2t5LCBqaGIuCnJmeXUyOHV5
ZWdfc25rbWFpbC5jb20gYWRkZWQgYSBwcm9qZWN0OiBBUk0uCkhlcmFsZCBhZGRlZCBzdWJzY3Jp
YmVyczogYW5kcmV3LCBpbXAuCnJmeXUyOHV5ZWdfc25rbWFpbC5jb20gcmVxdWVzdGVkIHJldmll
dyBvZiB0aGlzIHJldmlzaW9uLgoKUkVWSVNJT04gU1VNTUFSWQogIEluIGJ1c19kbWFtYXBfdW5s
b2FkKCksIHRoZSBjb3VudGVycyBmb3IgZnJlZV9icGFnZXMgYW5kIHJlc2VydmVkX2JwYWdlcyBh
cHBlYXIgdG8gYmUgdnVsbmVyYWJsZSB0byB1bnByb3RlY3RlZCByZWFkLW1vZGlmeS13cml0ZSBv
cGVyYXRpb25zIHRoYXQgcmVzdWx0IGluIGFjY291bnRpbmcgdGhhdCBsb29rcyBsaWtlIGEgcGFn
ZSBsZWFrLgogIAogIFNlZSBhbHNvIGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxsYS9z
aG93X2J1Zy5jZ2k/aWQ9MjY0ODM2CiAgCiAgUGxlYXNlIHN1Z2dlc3QgYXBwcm9wcmlhdGUgcmV2
aWV3ZXJzLgoKUkVQT1NJVE9SWQogIHJHIEZyZWVCU0Qgc3JjIHJlcG9zaXRvcnkKClJFVklTSU9O
IERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMzU1NTMKCkFGRkVDVEVEIEZJ
TEVTCiAgc3lzL2FybS9hcm0vYnVzZG1hX21hY2hkZXAuYwoKQ0hBTkdFIERFVEFJTFMKCmRpZmYg
LS1naXQgYS9zeXMvYXJtL2FybS9idXNkbWFfbWFjaGRlcC5jIGIvc3lzL2FybS9hcm0vYnVzZG1h
X21hY2hkZXAuYwotLS0gYS9zeXMvYXJtL2FybS9idXNkbWFfbWFjaGRlcC5jCisrKyBiL3N5cy9h
cm0vYXJtL2J1c2RtYV9tYWNoZGVwLmMKQEAgLTExODQsOCArMTE4NCwxMCBAQAogCQlmcmVlX2Jv
dW5jZV9wYWdlcyhkbWF0LCBtYXApOwogCiAJCWJ6ID0gZG1hdC0+Ym91bmNlX3pvbmU7CisJCW10
eF9sb2NrKCZib3VuY2VfbG9jayk7CiAJCWJ6LT5mcmVlX2JwYWdlcyArPSBtYXAtPnBhZ2VzcmVz
ZXJ2ZWQ7CiAJCWJ6LT5yZXNlcnZlZF9icGFnZXMgLT0gbWFwLT5wYWdlc3Jlc2VydmVkOworCQlt
dHhfdW5sb2NrKCZib3VuY2VfbG9jayk7CiAJCW1hcC0+cGFnZXNyZXNlcnZlZCA9IDA7CiAJCW1h
cC0+cGFnZXNuZWVkZWQgPSAwOwogCX0KCgoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jl
dmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBy
Znl1Mjh1eWVnX3Nua21haWwuY29tLCBtamcsIGhzZWxhc2t5LCBqaGIKQ2M6IGltcCwgYW5kcmV3
LCBmcmVlYnNkLWFybS1saXN0LCBiego=

--b1_076fbbef1e10018b84b27c7fc05cc395
Content-Type: text/x-patch; charset=utf-8; name="D35553.107262.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="D35553.107262.patch"

ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLmMgYi9zeXMvYXJtL2FybS9i
dXNkbWFfbWFjaGRlcC5jCi0tLSBhL3N5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLmMKKysrIGIv
c3lzL2FybS9hcm0vYnVzZG1hX21hY2hkZXAuYwpAQCAtMTE4NCw4ICsxMTg0LDEwIEBACiAJCWZy
ZWVfYm91bmNlX3BhZ2VzKGRtYXQsIG1hcCk7CiAKIAkJYnogPSBkbWF0LT5ib3VuY2Vfem9uZTsK
KwkJbXR4X2xvY2soJmJvdW5jZV9sb2NrKTsKIAkJYnotPmZyZWVfYnBhZ2VzICs9IG1hcC0+cGFn
ZXNyZXNlcnZlZDsKIAkJYnotPnJlc2VydmVkX2JwYWdlcyAtPSBtYXAtPnBhZ2VzcmVzZXJ2ZWQ7
CisJCW10eF91bmxvY2soJmJvdW5jZV9sb2NrKTsKIAkJbWFwLT5wYWdlc3Jlc2VydmVkID0gMDsK
IAkJbWFwLT5wYWdlc25lZWRlZCA9IDA7CiAJfQoK


--b1_076fbbef1e10018b84b27c7fc05cc395--

From nobody Thu Jun 23 10:49:36 2022
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 8870E876735
	for ; Thu, 23 Jun 2022 10:49:36 +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 4LTH7h1rsWz3jlS
	for ; Thu, 23 Jun 2022 10:49:36 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 194831989A
	for ; Thu, 23 Jun 2022 10:49:36 +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 25NAnZdG009123
	for ; Thu, 23 Jun 2022 10:49:35 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25NAnZW3009122
	for freebsd-arm@FreeBSD.org; Thu, 23 Jun 2022 10:49:35 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 264842] kernel core generated due to VM page fault
Date: Thu, 23 Jun 2022 10:49:36 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: aadhya@cisco.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655981376;
	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=aiuXdDyHgchQQETbMAG5SacNcNL7r1e1fUGRNxOU/FQ=;
	b=q9DuJolNuldxsjo6m/kGS4M7M4B1LUWPp059swzjrlwftanciG2lD0cqkR4Sx1WmZxaQ9L
	tWQ4UbhnruMoPQ5y+wnFQghl7twI3oE5zGylI94+c4KNfZ+INzG+lXmfXVcJOnphaJei8v
	AAFCaiErwnWSnqLijAAK9O5nvNjFeTTx3O6LQrIMs3IUhKeRQ9TIxba7QxplV93qUEP80J
	skaIencfqFdr9qVqoUWfyavvrRq0aD6TM+UbaAopdxX4Moc0EU3iFfpDE/WC0QstOzDUe7
	jnn7F0tmU/gVXVN7p677FQ9yM8Ka37up+rB0ZyoQjEPuG54rPyKjSwDj90ZvMw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655981376; a=rsa-sha256; cv=none;
	b=IlZ2vy5HbIGXTJ9UdK88Aiys19PoGnfE2tpCxg5DFVkJbsy4GoJGOYezHChwUH3WI2IUGj
	C35zLjFk+a8EpbvPZem6+jR8Y8rAQc51YnYNm5NCmX9GXsV7a8fx9+Po/OvP4W/F36CG7r
	wa/EgNWxLGihyXboDmai4aCDMJz10+lLE+i+HBs1X8LcA8XkQiHib+eFRAs5wi2L4Eypj6
	XDDsofbed+pQnwXh/xgzSjr/vkZBvyI+2Rx5iLYPbzQtohUyPBNQl1F/hMSBdpWRHPQNn+
	KyTAELg/y8i6PNUp9tzfZdDfpwUoDSJj5X0fXPXXF8yKjOgBKyVLRNXaI3xcDg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264842

            Bug ID: 264842
           Summary: kernel core generated due to VM page fault
           Product: Base System
           Version: Unspecified
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: aadhya@cisco.com

We have observed core generated several times due to page fault.

Environment :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
hw.model: Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz
hw.machine: amd64
hw.ncpu: 24
FreeBSD 11.2-RELEASE

Here is the BT :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(kgdb) bt
#0  0xffffffff806110e7 in doadump ()
#1  0xffffffff80610f5b in kern_reboot ()
#2  0xffffffff80611459 in vpanic ()
#3  0xffffffff80611193 in panic ()
#4  0xffffffff808967df in trap_fatal ()
#5  0xffffffff80896839 in trap_pfault ()
#6  0xffffffff80896028 in trap ()
#7  0xffffffff8087535e in calltrap ()
#8  0xffffffff8085c9b1 in vm_page_alloc_after ()
#9  0xffffffff8085f450 in vm_page_grab_pages ()
#10 0xffffffff806aa6aa in allocbuf ()
#11 0xffffffff806a8a99 in getblk ()
#12 0xffffffff80801b4f in ffs_balloc_ufs2 ()
#13 0xffffffff8082b39b in ffs_write ()
#14 0xffffffff80950dc3 in VOP_WRITE_APV ()
#15 0xffffffff806da6e4 in vn_write ()
#16 0xffffffff806da223 in vn_io_fault_doio ()
#17 0xffffffff806d82a1 in vn_io_fault1 ()
#18 0xffffffff806d6518 in vn_io_fault ()
#19 0xffffffff8066b330 in dofilewrite ()
#20 0xffffffff8066af48 in kern_writev ()
#21 0xffffffff8066aed6 in sys_write ()
#22 0xfffffe103e0271e0 in ?? ()
#23 0xffffffff00000001 in ?? ()
#24 0x0000000000130000 in ?? ()
#25 0x0000000000010000 in ?? ()
#26 0x0000000100000000 in ?? ()
#27 0xfffff80012f3d620 in ?? ()
#28 0x00000008139dc000 in ?? ()
#29 0x0000000000010000 in ?? ()
#30 0xfffffe103e027330 in ?? ()
#31 0xffffffff80896f3c in amd64_syscall ()
(kgdb)=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

After adding symbol file the bt gives the following details :

(kgdb) bt
#0  doadump (textdump=3D1) at pcpu.h:229
#1  0xffffffff80610f5b in kern_reboot (howto=3D260) at
../../../kern/kern_shutdown.c:395
#2  0xffffffff80611459 in vpanic (fmt=3D, ap=3D)
    at ../../../kern/kern_shutdown.c:799
#3  0xffffffff80611193 in panic (fmt=3D) at
../../../kern/kern_shutdown.c:719
#4  0xffffffff808967df in trap_fatal (frame=3D0xfffffe103e026890, eva=3D90)=
 at
../../../amd64/amd64/trap.c:875
#5  0xffffffff80896839 in trap_pfault (frame=3D0xfffffe103e026890, usermode=
=3D0) at
pcpu.h:229
#6  0xffffffff80896028 in trap (frame=3D0xfffffe103e026890) at
../../../amd64/amd64/trap.c:415
#7  0xffffffff8087535e in calltrap () at ../../../amd64/amd64/exception.S:1=
96
#8  0xffffffff8085c9b1 in vm_page_alloc_after (object=3D0xfffff80297ab42d0,
pindex=3D307, req=3D,
    mpred=3D0xfffff8103310e3d8) at atomic.h:219
#9  0xffffffff8085f450 in vm_page_grab_pages (object=3D,
pindex=3D304,
    allocflags=3D, ma=3D0xfffffe0f81090bc0, count=3D) at ../../../vm/vm_page.c:3397
#10 0xffffffff806aa6aa in allocbuf (bp=3D0xfffffe0f81090ac0, size=3D) at ../../../kern/vfs_bio.c:2759
#11 0xffffffff806a8a99 in getblk (vp=3D, blkno=3D, size=3D,
    slpflag=3D, slptimeo=3D, flag=
s=3D8) at
../../../kern/vfs_bio.c:3769
#12 0xffffffff80801b4f in ffs_balloc_ufs2 (vp=3D0xfffff8041e470760,
startoffset=3D,
    size=3D, cred=3D0xfffff80020140700, flags=3D, bpp=3D0xfffffe103e026d28)
    at ../../../ufs/ffs/ffs_balloc.c:1001
#13 0xffffffff8082b39b in ffs_write (ap=3D0xfffffe103e026e88) at
../../../ufs/ffs/ffs_vnops.c:749
#14 0xffffffff80950dc3 in VOP_WRITE_APV (vop=3D,
a=3D0xfffffe103e026e88) at vnode_if.c:1000
#15 0xffffffff806da6e4 in vn_write (fp=3D, uio=3D, active_cred=3D0x130000,
    flags=3D, td=3D) at vnode_if.=
h:413
#16 0xffffffff806da223 in vn_io_fault_doio (args=3D0xfffffe103e0270a0,
uio=3D0xfffffe103e0271b0, td=3D0xfffff80012f3d620)
    at ../../../kern/vfs_vnops.c:965
#17 0xffffffff806d82a1 in vn_io_fault1 () at ../../../kern/vfs_vnops.c:1083
#18 0xffffffff806d6518 in vn_io_fault (fp=3D,
uio=3D0xfffff8041e4708e8,
    active_cred=3D0xfffff80020250078, flags=3D, td=3D<=
value
optimized out>)
    at ../../../kern/vfs_vnops.c:1187
#19 0xffffffff8066b330 in dofilewrite (td=3D0xfffff80012f3d620, fd=3D91,
fp=3D0xfffff802151c5b40, auio=3D0xfffffe103e0271b0,
    offset=3D, flags=3D0) at file.h:307
#20 0xffffffff8066af48 in kern_writev (td=3D0xfffff80012f3d620, fd=3D91,
auio=3D0xfffffe103e0271b0)
---Type  to continue, or q  to quit---
    at ../../../kern/sys_generic.c:506
#21 0xffffffff8066aed6 in sys_write (td=3D, uap=3D)
    at ../../../kern/sys_generic.c:420
#22 0xffffffff80896f3c in amd64_syscall (td=3D0xfffff80012f3d620, traced=3D=
0) at
subr_syscall.c:132
#23 0xffffffff80875bad in fast_syscall_common () at
../../../amd64/amd64/exception.S:475
#24 0x0000000801ef5e8a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)

=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

What could be the possible fix for this crash ?
Thanks !!!

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Jun 24 01:43:24 2022
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 A085E875805
	for ; Fri, 24 Jun 2022 01:43:37 +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 4LTfzD1lmpz3mNB
	for ; Fri, 24 Jun 2022 01:43:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656035008; bh=FfnL3D/TxQjAEzjoNF2TYlmcCc7HX7NSoZ0/ab4u2Gc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Xmklvc4r53qAGqrJZkUMs8TuR6BhrPvmCD/NX82DDbc2EIC6Mz3GFskUDcH5AQdWx9mSz2FoxITD3MAl/lnTHZYoPfg7wHJRfMZTMGPjmUF1Pt4/dHTJ5GHTfM6SsiSmC8/y1f4MxBcORbeQIzm0GS16B35jVzAxOKxs/vJSC/YKdK5T1wVX/hLMWwXFp0vodModBv8H2KYTPfPiZH82XCpvdATcwW7yKhDTEgUXk7H69haBmB3Pr52RDAeQnKvOmh3HyoNXk06X9IOGRenw16Pgw+n7hTIytOZhGC9EIUCGf7lfoq4KbhjAbQi/nI3Ubw3i+cEUIjzFlRVDKOkVgA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656035008; bh=g5UT4TfIWiM9Rwvl/eVswBH/Qwso+98ZElGRsjL70QY=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IEg6cu1i4oDvy8FRdUwjNJNn/m0RHfIBGKdBqPbZqtwfoEHA3ewJ/TGJcK8a3uFxWUllRwOJaejQvL83tjSvB3vnkdiJygs9U4K1j80qeoeRDOTzW4NxJ8VXGAg6kRuakcNUnTrSOgxqQ5499n923p6MegXNQec82J7Sv3MTQ1XA89EKahdDy0hR0R0iDy0bzlDPe+ENKBgNDhXy2866m2fgf53P14GRovaD9vPQhh7R0U8G8A5K7yrrnowNj95bDkdatOw/o1qoSZfJiZdvYpHqFUU7ML0Ej6btE/5TW/JPObofPf27kZG0pR6RtZK/YpWax+boi4lp7UMrDObyrQ==
X-YMail-OSG: 3FQ9IgAVM1nMSEV9G8wfKpnLRh_Khf_q4yEHNXR8i446M40e7vU2wBcM2thE.RJ
 YCTJmuKDwmU1so4mfgAhJEykhq8F5bKehqJF2cuviwD61HD_Oc6DOt7PeScu5tU7FY0Kne5uAeZD
 SwERqXrjIbLcu01YgMT.64yuZseYLR8tuH3MN.ziOrOGFp.1W6uL5qDl0Mxa0JERhq5OGTM9ZNg8
 Ml2zdgO2vTJ4RAQx5wd6MVVQZDvPVvd2pMxfc3PqFCgILiF1v40ktciK1MctHMcMgomKQBG5exwp
 o6HpUuRm4Tvs89iDDoo08fV8asgQIY72Y5nY4HKT_WO.QrfqRJXSg0ubGxERuNxLHeIfmbG27pJs
 J9gVzBxS_QvQYdhXD_ZpQyPNlLMAMdajQwRa0kuDSpNJzah5n.gsse2OA1TVH6GzTmAIvFzoem9c
 ialBRB7O_AHMoEfcJm5stNJJ13YsA0ueTU14L04UAYkhM2xJ3trAmQxtYVUxq5W5gacBKT1w2Ueo
 pSnIleL5FDV1I3aqxjrIePyTtrJDE.pgDuqiiw79C.f8objQnAqfT0P87IajiZbPMZQG_ziCvF.7
 HO.JsKtj8vOLZt0E2o6b3P89OM4HYwsLEK8Vk0PBbIdQ5kLE6MXSegfRUEmjx3ACSDCIKAare.7h
 YZ_dB3UoGmA5Yo1.5oHMTUOTnTHYum90_1bnPET0PBymEGCf5OYShDJfBuFKeLmPpSqsbyxqlw6q
 xyEIkZg3DTCNf6oxcReQt8XZHoMaoH6u2VKcfyy1qbqTOrQKP8I3dUBdpa2Nk1VGlbvQlPR.jgPu
 D.8zuw77zCY.DaK64VyeXgqLTq2AT07bs.tMntZtBBe5RBi_rOpiP.ZSDGEh_FaszXNqjvJx3X9e
 gLYhjmFxjobz4ONdJq76aJXXoDbHeVntFgTFuYYemNl2RcSMLva1nQFK9kkQ83OtToq86yhUPBd0
 BS5hlm6I6DmUslS7UrNn4p_PxiNIX9PpjgaWUDjvhxyDK67Otkc9CNE2AC5UnFUTalHE_uZIuPLJ
 W1Aq6FlQ10xQB9Mggmgw08YYqyOA0itjftAvAMQ3cak2Ks01KvuvO6d0nHHh3B.v8fup0lPvw_tK
 d4K5a.84rcA1Vrw5rS6vcKkVtrbC6rPrOqvdEfV7L_ybsLvq6Wgv4QAYlKf1VFKXrZH_zaH3hq2u
 _rpCcGNB7tHIPZXkZuANm79w0rLO33kntP_69TEKbSGnAKE6u6XfwRHuxp6_haF2blwLyfTaiJ2F
 b8JxTZpG6I6NCDJyDJO4sAyND5zFpcpEFcSsjBshs65wMHXr6yrFvRtXlwMdPztz82GSxXynttjB
 TU_L5V38MqbGcGHYhOgj7dQr78lRJyYj8_0L6_yXanTw9RsQHxhk1VFnFxY1SfZDeSesuvejwubk
 aKAP2KMHUEVnIgaPNgabtGNkQ0ARbMPPNOqaEAdxN.xi9dwwGM0_1PIqFgMCBFvrUiLfu5QML4TL
 0KhmhFYhfYyT2vKv5gHuAnQuG_Z.AuiUJcBwHQEVfmx.10L4lcOypC0pcQUoPEYsg.ZZAo0g1DVc
 PAeoNol_nW4Le0.eZhb6uMgzi5NS56Z3Hb9Ihd4n7P1VYmWKVzLB3w8Wp2f7QXz.rK3vjXdHcvJC
 fgWs_jEQUWl8qYj1mHrfhjezlnrLtiix06.za5EpiWaBaw.rt5PAOX_avVQGY5D5X3VwTe6OVuji
 NeP.zA0r32zlzJrfMyaMh7l_B7QIMWt9w.PMQ_Oq6RwEw10v2y2h4Y_HXxW_M36tn8hMQTQoCYJG
 pqD4ilrG.j63g8qAxss31gR.pZHnG5mB747mgm.OSihicLnCdUtDgpGwsaeicKcrRqVfklJeEG_L
 YSydUNTSQU3uLX8OaY0Z.yg2r573i9CeUinfC0VCMkpemyZ8kCaf6CZhJ.pJKM.bkLlHrX70WQ_b
 gZhWp4YKD01HMOyiJGTJpkwP0JH3S2fW..vFG9mXKF4p5cmBIsjqZJy4iwW0TQeFH06ijbqjnvXz
 LMzchr6SpNWplF7oO_8xLYf1rc6pUqIkwlhe7QPJ6sQod8u9pKXtSC8XaFsNJZ2r5l_1Powh2oMY
 xkBNTaoYV4GvKh7HzwrAW_Hn4i9e5n8qx.bAnxIug5LZyXN08oJElXfehgYurq7GL_nEJjckhG_1
 l3dgwKonGpdMIi1eBQhKxCpGfpUnmOax2Q7f4jtzNkO_o0nKc0LpWNUN9KTULvIrlRRYUZ8TGu4l
 gCxP.mUaArujFlQIlx.s690PQSFhL06XKXuO4Ilj5y0ABnI1W9YkTgyPrNB9hPmjIxeMBHbTRRAH
 hoUxCTf.dX4.uW6qUQYE1jRdIU6y6tvhVYWlOJ7F23n7UgvwEX9dCLV2cOmql.JGR1.9vwySuWFR
 w1R_Yg00.K1zS7vCIvqk-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Jun 2022 01:43:28 +0000
Received: by hermes--canary-production-gq1-677bd878b7-bn7wr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 04c88f6994d8f2b59da0f18c72bc1c14;
          Fri, 24 Jun 2022 01:43:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
Date: Thu, 23 Jun 2022 18:43:24 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
 <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LTfzD1lmpz3mNB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Xmklvc4r;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.51 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.99)[0.989];
	 NEURAL_HAM_LONG(-1.00)[-0.996];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

There is another checkin to main for superblock handling:

QUOTE
The branch main has been updated by mckusick:

URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D50dc4c7df4156863148e6a9609c03e85=
2e2aeb35

commit 50dc4c7df4156863148e6a9609c03e852e2aeb35
Author:     Kirk McKusick 
AuthorDate: 2022-06-24 00:39:05 +0000
Commit:     Kirk McKusick 
CommitDate: 2022-06-24 00:39:53 +0000

    When a superblock integrity check fails, report the cause of the =
failure.
   =20
    No functional change intended.
   =20
    MFC after:   1 month (with 076002f24d35)
    Differential Revision: https://reviews.freebsd.org/D35219
. . .
END QUOTE

So, not a fix but it should make it obvious:

A) each time a superblock check fails
B) what type of superblock failure each failure is for.

It  might help isolate if your failures are superblock failures
vs. some other tpye of failure.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jun 25 10:07:28 2022
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 26FA8864A4A
	for ; Sat, 25 Jun 2022 10:07:28 +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 4LVV6771YCz3LyT
	for ; Sat, 25 Jun 2022 10:07:27 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 D127E226AD
	for ; Sat, 25 Jun 2022 10:07:27 +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 25PA7Rxq090854
	for ; Sat, 25 Jun 2022 10:07:27 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25PA7Rs4090853
	for freebsd-arm@FreeBSD.org; Sat, 25 Jun 2022 10:07:27 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 264836] arm/arm/busdma_machdep-v6.c: bounce page accounting
 leak (noticed with high traffic ftdi usb serial devices)
Date: Sat, 25 Jun 2022 10:07:28 +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: 13.1-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: hselasky@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: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656151648;
	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=3nUbSByIx/1aTmN/1PokBjxiKa/nB/VITc6K44+Uom0=;
	b=Avj3AxQxoMVlRuN/eDY217sLk03Xy8jMRHdI6q/8cuCtmx5JeHDdai2IvBhP0VhNaF7PPE
	ytkcghepKDjomtJp++PD7IcfRMzUpBVIebOQe06yhNHhoaIFLVLjreHbErRrqBtYN3EGv2
	tFbFMVo+JtrOhWKQWzdhfKeLQwd2mx5RW9lEJ5v12jSZf25ufQYAflPha5w3CLzsgpGdNg
	H9NN+6HxZql+KbFMpgQeadeRGtCUCtCpzPEVvTeVF202DlVbee+t/NDEM8GN/UFugYeWVO
	sv00kZB4aSZEH3GoPENRw2zi/dgyeKNx8JLVz9blHGWOMHRFuY6m6hpUA/1+dg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656151648; a=rsa-sha256; cv=none;
	b=eOD8XJ4oRj4UVERJSEc4BIKjua2BISOYnMCaRLAZV/JchBXQKxpUYDSc64secdDq01flRX
	90gXZAE4m2L2fVxrC7dkApBvsNM3uYf3wL2smX+VrDYfOzgAvKwWOTYzu3f2qfCLVO1xpJ
	UqzEMIUhsHwYXflPapY4KgGoSUZkDJ22OH8vRnf4k4bxUsaIRokRTQshKOPapPSsrKQIpo
	M4W16kFHGcnq1POcbrDNfuUPBmet+PHBW4SHUjhah5TdQYzLPBJMyBIvCUnSRShwNstPKQ
	aOV7D+O9fKa63jdcZs1t5f8HQRDU43yNccdQeBmnMSzQ4IY8o8ONxpkj8L6HHA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264836

Hans Petter Selasky  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|In Progress                 |Closed
         Resolution|---                         |FIXED

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Jun 25 21:51:19 2022
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 BF7FE87D73E
	for ; Sat, 25 Jun 2022 21:51:28 +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 4LVnkR2vJYz4Tn0
	for ; Sat, 25 Jun 2022 21:51:27 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25PLpKgj017808
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 25 Jun 2022 14:51:20 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25PLpK7p017807;
	Sat, 25 Jun 2022 14:51:20 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 25 Jun 2022 14:51:19 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Free BSD 
Subject: Re: Mountroot problems on RPi3/aarch64
Message-ID: <20220625215119.GA17770@www.zefox.net>
References: <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
 <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
 <47AFE262-8425-4A4D-A425-41CF39AA381E@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: <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
X-Rspamd-Queue-Id: 4LVnkR2vJYz4Tn0
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [2.16 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_SHORT(0.34)[0.339];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(0.92)[0.920];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jun 23, 2022 at 06:43:24PM -0700, Mark Millard wrote:
> There is another checkin to main for superblock handling:
> 
> QUOTE
> The branch main has been updated by mckusick:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=50dc4c7df4156863148e6a9609c03e852e2aeb35
> 

Here's the tail of the boot transcript:

Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more seconds
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0s2a
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> 

Rebooting using a kernel of:
 
FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 PDT 2022
    bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

stops in single user with:
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
Warning: no time-of-day clock registered, system time will not be set accurately
Dual Console: Serial Primary, Video Secondary
Setting hostuuid: 30303030-3030-3030-3064-626136386435.
Setting hostid: 0x5cd40a6a.
Starting file system checks:
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Cannot find file system superblock
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Cannot find file system superblock
Warning! Some of the devices might not be available; retrying
Restarting file system checks:
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Cannot find file system superblock
UFS2 superblock failed: fs->fs_csaddr (806456) != cgdmin(fs, 0) (5056)
Cannot find file system superblock
Unknown error 3; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
2022-06-25T14:23:46.792050-07:00 - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh: 
root@:/ # 

However, simply exiting the single-user shell seems to bring up
normal multi-user operation. 

Network connectivity remains sporadic, but is much helped by an outgoing
ping process. 

Could it be significant that this filesystem was created on June 4, 2020?

Thanks for writing!

bob prohaska

 



From nobody Sat Jun 25 22:47:26 2022
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 8D6C2864B81
	for ; Sat, 25 Jun 2022 22:47:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4LVpzG3qZ8z4b0j
	for ; Sat, 25 Jun 2022 22:47:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656197251; bh=ORQE5f7uQOS+Z1T9lUbA4qL5Efs7elB3aq987nrMmEE=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=TLasrRa+phJxVwViXF0Wd0nSRJeIiYQIKofgcW/V+uokb/Ivpx2yoez+lKxJJlcXBQemKhxGOA8ZKd17jOIZtkY9b+/UMq4KHQyaskbaPzo2HzTcb2ifGLZ15f7033uxp3DMkdckiNwp36J71LBIQBIIUZLSZKGxCdUvfl5lBMA198OFHeZBEOhszBIeLnK7aHT02FgQAsGHN/zKwUaGgU5fot8sXsn3UXr2R+UoYrznBbcAoAuINC7vLF5ZjSx8og88nFPSxJBPiWKrTd9UXPOvEvuZcxCPbvV6iPLFGmLMIomjm+4nyEd9aI+HOG5WhjYw/IXEsHCde047kUpf+w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656197251; bh=Lr1BY+f2SFylvyRaYoaqJ2zKVSbAMuxYmuIRKM+rJ4N=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Xi0/ZgjTKJQRAnwF1KE4f9Z6FsgZ4nHLORr8XnLlYNwHR/ATH11hr09QmFenV00xYPCEOvDRUe8s+aZkUU8iGtEaZMm9ngd81/lywbaVE0V+0eSZIzDPPRimobiaxScqpwp80BA83129mbsKrLMB7LYs5hgez7eZ0br5DxIQkYx0sb8JnoWvj+xOaQ6eELbFHWgiGhEs5HFYnoPygschpTqijv7BVrfEGSbnG4dABnHeInE/I+VjbhotCAXBtBTyQ6ev1EA8uQASpdRjabd3wonIxtcQPPn0pg9lzKtSCnf+ivO1WXB9PtdRCmyUdY8ftZwaZo3RLvCB/CaFu2CFGw==
X-YMail-OSG: oi5ecrkVM1mkQqBZcJ2dUl0sObqgtcpl8G8gc66PbkLTLy0TozSLeIk7lX3ab5R
 ODMD8pCsVpRTd4eeYzhFUlyorK2dv1xLhkJjsO5zbC82lLadWePTdZk9wbq8S5WsSPZ5AYNSCeG8
 AlkVLbrK.tm0ZOkqIRhQIkpi3mVT8tyqd2aawNBwE8oX_nBc6WUnEbpm.Jw84JoedkCFGZVYSIdX
 bL7lnuYBXnJTzbBFhGIny9hNS8bMqHhn45Kg0cMq9ZBqwUmTDCg5p7uZX_S3DlJJO4Wr1PIgmW_L
 bTgD1FemUJPqwpvTKlpZfF_uxjmE.jp7Rgq46Y4jE3.Pd1Lqv6WJiP5sy2KxqAVeh0A6eTS3sszD
 jpjAWCd9EFrovDOYx4vFTV.qmluColBMmsA76jvPEUikT3sEQahfJZ96OSpPxaRdLyZxVRvPgjo2
 07J183Cv10FVC4hvtaI_R6jv0urx633HkFo3HMtou9jwcismM6qbLguB335nZGZL6SZQaYkW5MTp
 yr_LWOaBw8btuXs7WbCywYPkhW14Ur3jcgY2W8q3zg2wkrOICtXOOy7AL07V7GfxkfZKzaizz7KE
 J9LDg6ie9hOZIqhJtS2DV_NaF0Y7roSuz4N2jnLWZUG3OPJH4e9H9eR9n9t2UA0XNNLJ.wneZhJz
 9w32eZJiSTkLWD1FyHC963RzJZODOxWVUlvjTd5RZDiEO6eVQ5IK1_8DbHQml._T7.x4LwzD9MGm
 OJNL0QHdgZW5BtjZiSt7BykUcfPBXRWG1woRNMUoIzVRSkBxqJHmj8vuL45WZLPGV1sYNJCjiSEX
 ZkPWTYaNZWt5NIZCGW_ArXWMwxOAxLffPF_QfbBlo81Yfom4O5KXeNzpIwoLQb8QXLX0pAtT92Z_
 dIbyftC61k_IOJmuX1kbnwrNIQY3xbqU.EXuHG15HtWy8WQ7o1LB5lgK3WoUKMYJ2HCo8H46dBNf
 B4O_p6zh4.t7MoZKI99vCHxnmE1NKfikWCdvTl.UuZre0i9P2S9lrsOSuy37lCwfC2wZ4z6ZW9Ee
 s_37yvna4xMN1eU1hIgZWW4tT1FF1rjNOW7bLXJpbRHjdE7u_A1zwYKeScEufNnEyYEeu2VdH7Uz
 8SPHR7xWb6Lxi8H9NgyVAkITYVeAR9ndiddgqDifo8Nk_2QMNhv7NjlnLWzy21Z.gJdjSANQNTLo
 M.dWHQap6bSn8_Fsoum.i.aZX2C3o7sfaUI_EfwOGzpgJYGmyBeiGRnAeDGvOtO4vqWamEPr3Sb5
 dUjZM3Eo9RyxYQYK_bxL0TFLMHiTzyvlbdvgNtKVYWP0XLofOBef0MJFTbtU_tWm74fxv7Oeskm6
 hRPj_2xWAk5guE3EWsrBQF9hSK_IKV2rm.H4UnKlvPM4AyuGWyc7ZfqQv3PgolskpMDv712ERcad
 4SjuZWS447abitfYmqf5hjpr0n_NMcRlNyBc68p66ANsIBTMgzQoeI45jhgMA4oJCFWDarJJ00O9
 SLTWdLA_GI2diSphNocKkzWMQIhU_ieeBLlssjh0pqaPOgeXi6vPWT3z2ZBO2EL3VoJbMi8DXc.N
 s7JDJhYgaIXP9IhLE__iLkbNPCf5AdoGSdZbUey.2iDg522FVcHoJeDeN6qrR5S9bdhvm7IpUV.f
 Iyjc81v3uqoOYtPcNeGSvzQ08YsR7GvnhK36GstZpnYmLW5EppfLpEdGRxNWip0Lq2iGN.zgrBpR
 10TvTMkV9OBKK96rG.r1OVFDqC9c5sUMpBhwQMPqHieLFDcWijqnAJS.KV5lrNyw2dYcIygVgMUc
 F5KAkUbnnAVV0UJqNRdQPM9zYJInomrRuuq1y.Nh8y.09nz5CZ3oDHN1.51Ok0HssclRW2SKp_nj
 ooZ5VBuUU9ZTJxlJvqf5b53Ag.MMRJj2eJJ6VtInIvB3UcD9y4vNbNLsiJIcdpFywMOT1mJ0RyA0
 ERF.zx10P3yY_gxySalKa3yYoxCByUjAugjkqxKRHN3uwUZmvGVrjSn3wQVo0xq04W2jZYlJGsBM
 F0Ofr9z7c4FQj.rqx8Zwjgf_Web_4jVPPMZ2blrmcA3RTVLAnicx0FTInpY2hNqdI_Op0XVoSSzu
 Xhz1v7JYUX.DA9QsJSl1ekEZ_IYTcIw2kxFAVtk0Po51KZLSas_e8kwo74XmTvkeKm2icuvCqArB
 DGFmCyWkA_sEJgb_1pRJqzOrR9ZivWgBzfq24zLvcI9DCXtJ58clCSj61qZqPWgpBKfe0iJrjj7v
 IeeIyce9ZK8VPIGRMijur7P9zd.2.g9NIiZsP5WcGAKoJPpDomqQQaKmUjfrvTR_BmQeZuf1sWr1
 SNq52HO_m5uNJUJPlQeyvRFMDjZRPgNxlKlBo1sxn8UrqdSeK5oqg8OcHgxb0ujAlkHyYDnUxFN4
 iaotBsrXZUnxD3_hAmQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Jun 2022 22:47:31 +0000
Received: by hermes--production-bf1-7f5f59bd5b-l2zks (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 971c72b051ac43ff188840143fb4a2d7;
          Sat, 25 Jun 2022 22:47:29 +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 14.0 \(3654.120.0.1.13\))
Subject: git: 50dc4c7df415 - main - When a superblock integrity check fails,
 report the cause of the failure.
Message-Id: <65CEBAEA-189F-467D-972F-4ADF45DAAEE7@yahoo.com>
Date: Sat, 25 Jun 2022 15:47:26 -0700
Cc: Free BSD ,
 dev-commits-src-main@freebsd.org
To: "mckusick@freebsd.org" ,
 bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <65CEBAEA-189F-467D-972F-4ADF45DAAEE7.ref@yahoo.com>
X-Rspamd-Queue-Id: 4LVpzG3qZ8z4b0j
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=TLasrRa+;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.94 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.47)[-0.471];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.973];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Kirk McKusick  wrote on
Date: Fri, 24 Jun 2022 00:40:20 UTC :

> The branch main has been updated by mckusick:
>=20
> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D50dc4c7df4156863148e6a9609c03e85=
2e2aeb35
>=20
> commit 50dc4c7df4156863148e6a9609c03e852e2aeb35
> Author:     Kirk McKusick 
> AuthorDate: 2022-06-24 00:39:05 +0000
> Commit:     Kirk McKusick 
> CommitDate: 2022-06-24 00:39:53 +0000
>=20
>     When a superblock integrity check fails, report the cause of the =
failure.
>    =20
>     No functional change intended.
>    =20
>     MFC after:   1 month (with 076002f24d35)
>     Differential Revision: https://reviews.freebsd.org/D35219
. . .

One of the people active on the freebsd-arm list (Bob Prohaska)
has been reporting problems with UFS rejections and now that
there are error messages for the superblock check failures,
more can be seen after his update that includes those changes.

(Note: Recently at least one of Bob P.'s list Emails seem not
have shown up on freewbsd-arm but I'm getting copies from being
explicitly listed. In this case the message made it to the
list so I can refer to it.)

https://lists.freebsd.org/archives/freebsd-arm/2022-June/001453.html

reports now getting messages like:

UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
. . . (lots of them) . . .

The more overall sequence, being:

. . .
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 12345678D558
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2
UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
. . .
UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 more =
seconds
UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
. . .
UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) (5056)
Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/da0s2a
  vfs.root.mountfrom.options=3Drw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input


Booting an older main-n255816-e26ef41f799 kernel (May 25 build date)
stops in single user. I'll not repeat the details here but 4 of those
messages occur before getting to the single user prompt. Exiting
single user mode gets to multi-user.

(I'll ignore the network connectivity issue that is mentioned, which,
as I remember, predates this UFS rejection issues but is ongoing.)

See the message referenced:

https://lists.freebsd.org/archives/freebsd-arm/2022-June/001453.html

for more. Bob would like to get back into a good state for his UFS
partition. Such related notes might help others as well.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun 26 02:22:26 2022
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 82A1C8A6523
	for ; Sun, 26 Jun 2022 02:22:44 +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 4LVvlQ6BlCz3LTl
	for ; Sun, 26 Jun 2022 02:22:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656210154; bh=cW5Zjl5sGtwkL5NVhoX9bnhPD7BzgC0Kae4ndRn1p5I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Xu477silS8ti2s3cpyedH+ijnuIJfJa5Y5wuYX5csMFzSU91LVLwv6pCtRXDxJYALp7f0Idd20FEzAyRw8hHEjrtJRfuUTbxkzAlL1SLwEt7Sr0Mh2bIXewc9MF1FCkCk0bGvQjTgG3wpYQ1IkWjV45tmYj91jAWp4CFe1X6w9OrNknSUbmz07baKS0v3hteGjRXNUhLf4yySrOylrRwU/8iRjTJvAhgh2irZM/1fCEiMZE0QKbxquApHDkoAcGZqNJS9+O6MAXJ1OQkhtmJcXU9OP+NXpWqnFFJt8n8xK5IJYNEu3UCkiUjE0B+ShB7Xxbd/saNp4FqqFZd3MpSeg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656210154; bh=Nl/7e8fHal2E/smr2cD4JXZduhnaCIakNrG5hqcD4zN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ms3uXTGidYlHIlPO30eT1kyZ8rN0DkHMf6VXlODn+mIQWq5rGSsQE7ijtH6QYNTlJSaN/W2v1LtH7T76V0T+9/OSr/YD4HT2pHg/0Es5mg/sXkqmBhsO6djKR7VKp9CC1joLh1M7mlWvJ2spOEojiAU+EOc7r+CH49cl3g7OvChqT46sYMSAbKxRBbWgpCQd2DIy5McoDtpVHYPVMInWM4rVHlGt7Y1dFWlJU+zZWqFP6HFIKipL52Nj2I2Iou8S65egwjtgFrS5pgzGMRrnLYonpnWUcGlPMkUkndAoKyCg0SUJehO/Tu9yGfLCUEK9+/18RZWc+mhKwOWLJFz/3Q==
X-YMail-OSG: eP5IkIEVM1k84BsBoOA3Q_t13Pt2dnZcPJQX7iIsQdasMS9lftZ5klnAuCvPLCq
 xdPcE.lKiNWOJi1RSUi0AJ6IfbXBX1gU5ZiMRppkefG6gZ0R9FrIQRE5vToLFIq1AjtFlSad.32P
 D19TwdH0oa5krK12MFKcwBbVha4qr2wJlkcefQXVybBSW1VOngcsn12jr5FIDWCH25IbUrd.Zi57
 YDPiefjRJxUh4C6IeC.ixCEexq3MRIq2f5JuQbDS5S5HhT4XFYklk2dE4MV68mHLDC4qSm9snBF8
 dO.2FUYYCyE8d8M0Xf_lfLmL6WwpfmZu5Sz7kYc.Bm_OkbCPYdcdYc5zOW.nibxp52ZExTqyJils
 7cC_0JCw4tftYSH28E00s3MyceyhINGas2PMmdw2P6jGEideL2kdISnPDzBQv6KCtEi7Ja_klgW3
 clAT6Jk.udDAUdd8Suw5XE1MbMJ45vrqvC86Gre4ZpWBoIucZecdafeRMxx6cJqdsTDmkBokXTCn
 uXbWohCJfZKnt6QrLgH.bVAUENH42zx.UIL2z_WzS4ujzyJbD2rYm5cu9SQ2HzMO6ykBfLlkyIeb
 gJpNcSuJQt0RBvgFmYHsgbOaB9rjDkOTCzGoVdQXj4e9XMry7aR3JR0aZgFJNXte2QFgnMKHcBcg
 YRD5vf_yBgyipnOVI.HI7eBHWcL8f9yrpSv8vQIqEK17bL1NiRcsTDH5S2hzTuO_WFWrRiuON06h
 xQCsibZ8EsUgiuQrXZdI.L6cywOZZBYbA16d9MPo1KnVLP_Lmp3K0RAjQmpm_VLfaYNKjLTc9Fdu
 hby1ZEoU.yb5bsb6XdvXdrvS_TqfoRsGi1LkoAGQgU5c51pnuPCI5Wpc2PsMNOwa0uHp8aJcUyiU
 Y4wYcs4KMjqs_fsKiEaeZva7lSEcTo1_d7ZXYw3NHxHhMmc_Q.jfW_VDaUaYOfTnaHmYEbjRKcFR
 JLSq0tNwfKBqkZ1IIo88_2y6I8ApQi.FhdBzy2bqGklGrHiOK742cjIV4EXb049Aq9ROF_iFRYoF
 6ewN2jtOGLLylCZ.cMjVJKwhmLP2auIzphScENLhRx6A8bHLlRzN37uBm_Wss8SCS7OS8aaA..0E
 LA9uBIgUN1Beef.w.HLyC2eR10rEiqLDJhGUpwerSA1toh0kln3hOb4qxmPZo4wNSc8UxXSMgUcA
 DVyaeBQV2KOGcH1F9vdUYRyg03SPMsSZj5vAeD1w_1hU51EjVtJmjhJ8QGmkXQwxYgN604xR1pIA
 cwUdROE2fHRGF2mun6X_MkLoNbOSUiiZieNd92uPOtuWivc7KBnv0.mTUxJz34bmskxp.FRh2YCs
 EOFp3B_W7c1zqjrY1AizFDO39Y_pjyaJatLS7T4bao4ebJjSIgyrCs23MT7F0RSSmM8_t7VeU2m4
 VqnaNhV7OsvTSkIyXVK2dOxrjAidILwLdekigfXDM8yi9HVbOc6Lx_SJSC4yK8FamHLMtuVA8uB7
 0lqJKrQ.sFGLpXkv5xmz86TnGwKkgG5jd_GQexaGnB_XFmnQaLpJ08m2CfJHZUZtpuxVpV5Y4eeS
 BLZ8dHl49rz1ebrxlw.M5fr9sCyv1Ra3x40Ne4c0fthchIRFYlq964vxePJLV9iVSvReA1mE0c4v
 bULgNmZMhVKRAtzHfTNHn5XVbwpdv.gRcp9EGYbjyvW5O2XKe8g64Og3DR8IriKrS7od50DQfkCu
 eIV0znuWJvQWZ9j6A5NW7BO2ZC2GGBJ97EBxXMZDjDomvltgQC9OvTQYESQs4Yz3NNpeyduOdZ0_
 XyrR_mSNYk9DwW1WZt6nLb1.Fg.jfVo8GUcABtVo7JSj_tU4s1JEhSfoWm_G5mLMpEhaGz4FTsoW
 fVhyVuuzXsryJUpiLG_ehCUR3jR03yWyyP.slML4lkA3sJUMBZSPQu.svU7I2GAKjh05ageX50ai
 U6BVvjWp3ERl9rFLFs20tqQNjDw0XIll3XK9l6_J9PAsZWj.33Yx4Y3WWlfm7LaKHF0NS7EL.2t.
 V7wrCJTfhbsaj.Ub01sy89Zwk4mtLuUUJQLCNDuzKGe615M519RU3_gJsNR9iCIxr1q9Ign.U9AB
 fcAPGJHRZ7nyhzeDOZE48M77a9qakH2D7sBJxt6ytUXHBalCsNSIGU.PQ.XWHkNOywBf2E52fYUK
 lWJIzozzwWBNLMZdWC9AKn9KygZnDEkjNkyzLAG9geJs29eu6mkxledNYn2_nCrfz5k53HPy2xcd
 Y8STvhYgUAmxrY6NmpoE7RhdInQNu2JyqYgFinKQZwqidNPqq7ftaPUn.A1QxbjjyuB.Zwsba2_.
 mD6WoD.rouyhdxb5Hsz97YI021UWF8fUc3Qrdye0PHGIw3rwgjTAr2203T0HTot0m9P7kE_kvW0W
 WrTREADQTXQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Jun 2022 02:22:34 +0000
Received: by hermes--production-bf1-7f5f59bd5b-wjb4g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de57950bcf6ef793c7bf20e773ed1593;
          Sun, 26 Jun 2022 02:22: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <20220625215119.GA17770@www.zefox.net>
Date: Sat, 25 Jun 2022 19:22:26 -0700
Cc: Free BSD ,
 "mckusick@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
 <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
 <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
 <20220625215119.GA17770@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LVvlQ6BlCz3LTl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Xu477sil;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.78 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.72)[0.715];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-25, at 14:51, bob prohaska  wrote:

> On Thu, Jun 23, 2022 at 06:43:24PM -0700, Mark Millard wrote:
>> There is another checkin to main for superblock handling:
>>=20
>> QUOTE
>> The branch main has been updated by mckusick:
>>=20
>> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D50dc4c7df4156863148e6a9609c03e85=
2e2aeb35
>>=20
>=20
> Here's the tail of the boot transcript:
>=20
> Root mount waiting for: CAM
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 12345678D558
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)

I'm not UFS/FFS implementation literate but I can show what I
see when I look up some of the related source code. Looking up
cgdmin leads to sys/ufs/ffs/fs.h material:

/*
 * Cylinder group macros to locate things in cylinder groups.
 * They calc filesystem addresses of cylinder group data structures.
 */
#define cgbase(fs, c)   (((ufs2_daddr_t)(fs)->fs_fpg) * (c))
. . .
#define cgdmin(fs, c)   (cgstart(fs, c) + (fs)->fs_dblkno)      /* 1st =
data */
. . .
#define cgstart(fs, c)                                                  =
\
       ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) :            =
   \
       (cgbase(fs, c) + (fs)->fs_old_cgoffset * ((c) & =
~((fs)->fs_old_cgmask))))

=46rom the cgdmin(fs, 0) I learn that the cgbase(fs, 0)
involved is 0 (i.e., zero). =46rom that, looking at
what cgstart(fs, 0) would be leads to concluding that:

(fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask))

is in use and ends up being 5056. =46rom that I see that:

(fs)->fs_magic =3D=3D FS_UFS2_MAGIC

is false.

But the messages produced via:

	CHK(fs->fs_csaddr, !=3D, cgdmin(fs, 0), %jd);

implies that the code did validate the (fs)->fs_magic
value and it passed. For reference:

# grep MAGIC /usr/main-src/sys/ufs/ffs/fs.h
#define	FS_UFS1_MAGIC	0x011954	/* UFS1 fast filesystem magic =
number */
#define	FS_UFS2_MAGIC	0x19540119	/* UFS2 fast filesystem magic =
number */
#define	FS_BAD_MAGIC	0x19960408	/* UFS incomplete newfs magic =
number */
#define	CG_MAGIC	0x090255
#define	cg_chkmagic(cgp) ((cgp)->cg_magic =3D=3D CG_MAGIC)
       ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) :		=
\

=46rom the code structure and messaging I infer that:

(fs)->fs_magic =3D=3D FS_UFS1_MAGIC

or the code would have done:

	} else {
		/* Bad magic number, so assume not a superblock */
		return (ENOENT);
	}

without producing the messaging.

Why it would be a UFS1 file system that was created originally,
I do not know.

> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 =
more seconds
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.
>=20
> Loader variables:
>  vfs.root.mountfrom=3Dufs:/dev/da0s2a
>  vfs.root.mountfrom.options=3Drw
>=20
> Manual root filesystem specification:
>  : [options]
>      Mount  using filesystem 
>      and with the specified (optional) option list.
>=20
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>=20
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>      Abort manual input
>=20
> mountroot>=20
>=20
> Rebooting using a kernel of:
>=20
> FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 15:05:14 =
PDT 2022
>    bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20
> stops in single user with:
> Root mount waiting for: CAM
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 12345678D558
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
> Warning: no time-of-day clock registered, system time will not be set =
accurately
> Dual Console: Serial Primary, Video Secondary
> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
> Setting hostid: 0x5cd40a6a.
> Starting file system checks:
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Cannot find file system superblock
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Cannot find file system superblock
> Warning! Some of the devices might not be available; retrying
> Restarting file system checks:
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Cannot find file system superblock
> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
> Cannot find file system superblock
> Unknown error 3; help!
> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> 2022-06-25T14:23:46.792050-07:00 - init 1 - - /bin/sh on /etc/rc =
terminated abnormally, going to single user mode
> Enter full pathname of shell or RETURN for /bin/sh:=20
> root@:/ #=20
>=20
> However, simply exiting the single-user shell seems to bring up
> normal multi-user operation.=20
>=20
> Network connectivity remains sporadic, but is much helped by an =
outgoing
> ping process.=20
>=20
> Could it be significant that this filesystem was created on June 4, =
2020?

June 4 is after:

2022-05-27: Do comprehensive UFS/FFS superblock integrity checks when =
reading a superblock.
2022-06-01: Two bug fixes to UFS/FFS superblock integrity checks when =
reading a superblock.

but before:

2022-06-11: Bug fix to UFS/FFS superblock integrity checks when reading =
a superblock.

(and before the later additions of messages about superblock failure =
details).

But I can not tell what the status of the system was that created
the apparently problematical file system. It could be much older
for all I know.

None of these messages suggest code changes to creating UFS file
systems, just to validation.

I will note that the 2022-05-27 check-in does report:

QUOTE
. . . Although
it appears in only one place, the new code will apply to the kernel
modules and (through libufs) user applications that read in superblocks.
END QUOTE

This gets into why the older kernel behaves differently when used
with the newer world and why there are messages from the newer
world code even with the older kernel.


Of course, none of these notes provide any solutions, just
background information.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun 26 02:43:58 2022
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 B33BE86178C
	for ; Sun, 26 Jun 2022 02:44:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4LVwDF2gkJz3NZT
	for ; Sun, 26 Jun 2022 02:44:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656211445; bh=TpJ17wmNizI7N6AGSfiCfj89EQgxk8Ph7AQA0veYqn0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OFVLgpYzOgEKHNHd33O7Yz7HtZ7SZitrXxT3kBM18ezz4xrFfOniwAnP+iS4qzRUv78CZKSF/kBk5ghqXxNHxlDtR0/0YxsSmX/805ALW6710GNOOzN1LJa4KanKyIovp8tbQvW4H/749Q+QyzlWN7JbRTK29wmzTc1Q7tF4V1ysQFGK9YB35QLAYG3mKXPv22JMmYlFFQtwwqszzobYGjWqVd/w0d4+9Z8CTZKnnElhvuDy1Pwq7Tgqw+5zu4Y2ZCBVWX3Ix5aYRhDXwPErvU9K1coFjCu3r7NeWRTDw+2TkbGKZtr5AvNau0yPJ3m52cd+B8lGVNqiNPecYjW7fw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656211445; bh=Ti8So17vmG7Eghi+dAzAE+u+ac9t5i5SC4YOJE8PP1n=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=knTdIp5sNCscdsH8YdbXc8/vRpOKzzACAgLCAazTt1Bkjc9ReTjwNKvYLZiCYnXoF8ZMeZZSyst+ojUxOCtsNk0bEEIej9iMCgHaB2dGTbKd6jeOc7gTAd1ZTy6KnolcFbW+lcVd6LSXdh3NahmPZguwy/WlLPw70vMTCEEPxiv98Jel8w49lVRGSevMu2CZmD1iSTBm2rG9a1MMuhl7JUVmsytxEXAjR2GeIJgrS013Gwp1hiFAThOtKAKz3GlpBKvgIy1RNhZmauJP2m+ykGCT8caR102yLm7a5P0XYFw/70bspmScGaCiJpn0W6fD4AyYPqua6NubPVCg+7ZJng==
X-YMail-OSG: j0OqX6AVM1nSENbny4tetr18yHUbib8iGaDUJsnhfmmeoVd2015FZg_Hp3Kl7FE
 navrkfP5bnk0XfREGCdWR2bBz_5fs4YOw46BXWr25pD8bf1EiO.XKjx6VqwLiodiwpqSiG6H_am9
 v96LS7RopEY.8YTmvkx4nwomIC3wPNlirKBBv8HsadqwsA8NY.AeQsVxaxJplrX2askdeej0taTX
 IrpWx2rWclK1Rc_AZHCHPx5lBBLZh.QqXD6a_6QcdzlGhdi9Ce08muokCnNJ0XhFoz40syF5C0v9
 UPrm3aCEaQwBMAPz7Blc2TQawRgPyXfgczju.p._CzzEv5n_PRB43jBUE6Tamj8BFA4l.tzSKBcR
 tSaI.Ch2UiVzm.m6TVQXpCVED7IBpZcor6cQQhvB17fnBWm4EGS3qwY6Az._K_hre4jsnr2cgDT1
 QoOsFf0a6XPRbAg5mAp20r23rgjGRWuqm8a1HbR2yRx3JeSr6rCbm2nlDZNQoV0rAb785yNVqi6H
 66D9JBGO0o8bUqGuPuafNUbaYlh1aXxt5WiowCrGkzp6rqiafwucRlMGLeGwWVWs8yCgwccaWdSW
 1zWd6kgAPy3O3DFiGfYjmxV6VDOXCz1ZXr.OSEnBXgAgmfDIgoKp9607oXwNUhcFb2JjrpXN_kzj
 L3CreSoGsX9ER1khpUW8lb1X85ga.4DC6zBGMqeyRBiNNqq3cPalIWS.iv8nK1SMtChXQVY6sqfg
 _6uQckZd7m0_KBkWQgp5kqVd7SH284qbMAqk4dLqPcoW.AC6qZzdkBlr65q.GmWzJI8RIVnVJxFn
 .dkqpkA2Vfr8xMnnrAvcuyX1Q4tkwq3748wHnHqfP3DzUm6xg4WigWyesJAlz_adkiDHlL17nWZ.
 hx83Vxtc_O8qr5cxB3JJXlFIxfymnMMNSQeydqNrOQDQB5JYG6mbn9fA.NY.Y.ycpsLiX_7J0Cym
 capVZ12pksnQg0pAGpIeK4udMVAmB07w17J957QJl32OkyJ64H5UDlRfCF1_77Wos8nUUVrifFHV
 HS4OBoF9HXE85hB187S4yfIMLOP7bvXzcUrqVq70OsPu_osczNE5JJrzV5G8Czt14zhCjFpuMfFu
 U.RmHuMm1nVsZUkf84upYYIxqzaJl52QX8yCO6ykkvHXLqcoIQZGvUhgQqYizMFb0izf2GQBAwfC
 FzixmRMxPG2VwTUM0_xwAUlBPDHFWHo7vjtorap7zb_ybhlZ7qhgMv17GOiymHgH3TTtTJhzYqK4
 d_h8QxQL1OX.JAEKJaf_f93RjIGEnopqUL1eftD9nqRJe2hjinFTqjq74H.VTHQHYRVnFirbiz3.
 YMI1Gyb8VHh_aihu_D5DEKz.V0AHTqYhJyL3PIqv40nlNAr87gM7piqgmIPKccSkBN9ChGGccAHq
 wjuYXECTRFLJgendKI7F67ZXDzzTUrHjH2hWGoxWw962SDqN2vRPqRm1.5fNuGbIzbviPGZJLP2u
 Amfs_iDFeHpWgVeOLyUVnYIw4aLUpYfDOUcHtIsglxkM3D0E3agpVLWAew8Zg2eG8j_KRgKDdLol
 krgse9JetLnjr5MEzpCHHCBsCwiy1lTNRtYwQsA_KE9_F8poTOWKBuASi0rQzZY.Au6AYSZahCOS
 hZaOVFjNbtq46BYuoNJ7ylGnZd1HjxaUMMzHvF8sZ_zNYydk_k030ONcGEgoR2L2k19CNzSZ1x57
 DSwJLMM7umeslfyvKwW9QGgON.5KSlHcBGK4xYVSHDuUMRyAQPys_XdrnrDMoeu63q_0g.d7iaRo
 BQiCx9S2u3RO9Y7WD00zvpaiZQFmUQSu8Cd_5mnZ5thjESdG4Gdu9KF9pKxtBvqGsJNg1je_12MP
 7xxbtl6NDKsN_3hJdIvf9MeSq1Yf_xbYgIvw3B2sg7ETIcOmYkbxfzx7iInM0TJXFcwb9Ife0pmc
 60w73T2PAhKODDyrLriDUgaRwh9Wvd4sHfivSw2_flm8l2VE9NU8.6zzbfJUUTYi8HmkLbD72AiS
 h6687fOzfAX.Fwt_1WcISLkm_FOAuqv_hxDBShPDUvAfpwPP646CajHJa5UbmdbzIyqoEaLovEaK
 IUHoza.uxVVWmrTsQFvxvenfMy13XHqu6Y_kAkQa3H2BgLE5ReRiggyLiYRxqHn3A8rS3pzZBGZ7
 3DJxaAkMxNXQhUFWYHkU.uzcwd6F_CVcBVsxJaYtfemNTbACbx_.y6XunbMBTHxtdlz.YQjM8RMT
 iBqG3aYO3tV3nObCGm5t8W23wvn11WC5S3Anu_j7UJYdRvAMZvxy7VjVV7qd2dh04yEmAm0U0V4V
 lsxN5Vze_WQyIq1k2Tigz9gNMicOfoL3ErMQbduOlBT_VL75m0yh2tjH685bZDAjILD12AMzJkIT
 HiNv2RN9BpFk-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Jun 2022 02:44:05 +0000
Received: by hermes--production-bf1-7f5f59bd5b-l2zks (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fd5683d4a2ec2a47caa246cd8c30d3ca;
          Sun, 26 Jun 2022 02:44:00 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: 
Date: Sat, 25 Jun 2022 19:43:58 -0700
Cc: Free BSD ,
 "mckusick@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <962A2166-BEB2-443A-A01D-1617F7D8AF49@yahoo.com>
References: <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
 <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
 <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
 <20220625215119.GA17770@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LVwDF2gkJz3NZT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OFVLgpYz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-25, at 19:22, Mark Millard  wrote:

> On 2022-Jun-25, at 14:51, bob prohaska  wrote:
>=20
>> On Thu, Jun 23, 2022 at 06:43:24PM -0700, Mark Millard wrote:
>>> There is another checkin to main for superblock handling:
>>>=20
>>> QUOTE
>>> The branch main has been updated by mckusick:
>>>=20
>>> URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D50dc4c7df4156863148e6a9609c03e85=
2e2aeb35
>>>=20
>>=20
>> Here's the tail of the boot transcript:
>>=20
>> Root mount waiting for: CAM
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 12345678D558
>> da0: 40.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>=20
> I'm not UFS/FFS implementation literate but I can show what I
> see when I look up some of the related source code. Looking up
> cgdmin leads to sys/ufs/ffs/fs.h material:
>=20
> /*
> * Cylinder group macros to locate things in cylinder groups.
> * They calc filesystem addresses of cylinder group data structures.
> */
> #define cgbase(fs, c)   (((ufs2_daddr_t)(fs)->fs_fpg) * (c))
> . . .
> #define cgdmin(fs, c)   (cgstart(fs, c) + (fs)->fs_dblkno)      /* 1st =
data */
> . . .
> #define cgstart(fs, c)                                                 =
 \
>       ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) :           =
    \
>       (cgbase(fs, c) + (fs)->fs_old_cgoffset * ((c) & =
~((fs)->fs_old_cgmask))))
>=20
> =46rom the cgdmin(fs, 0) I learn that the cgbase(fs, 0)
> involved is 0 (i.e., zero). =46rom that, looking at
> what cgstart(fs, 0) would be leads to concluding that:
>=20
> (fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask))
>=20
> is in use and ends up being 5056.

This was wrong: (fs)->fs_dblkno provided the 5056.

See later below after the "JUNK" text block.

JUNK FROM MISTAKE:
> =46rom that I see that:
>=20
> (fs)->fs_magic =3D=3D FS_UFS2_MAGIC
>=20
> is false.
>=20
> But the messages produced via:
>=20
> 	CHK(fs->fs_csaddr, !=3D, cgdmin(fs, 0), %jd);
>=20
> implies that the code did validate the (fs)->fs_magic
> value and it passed. For reference:
>=20
> # grep MAGIC /usr/main-src/sys/ufs/ffs/fs.h
> #define	FS_UFS1_MAGIC	0x011954	/* UFS1 fast filesystem =
magic number */
> #define	FS_UFS2_MAGIC	0x19540119	/* UFS2 fast filesystem =
magic number */
> #define	FS_BAD_MAGIC	0x19960408	/* UFS incomplete newfs =
magic number */
> #define	CG_MAGIC	0x090255
> #define	cg_chkmagic(cgp) ((cgp)->cg_magic =3D=3D CG_MAGIC)
>       ((fs)->fs_magic =3D=3D FS_UFS2_MAGIC ? cgbase(fs, c) :		=
\
>=20
> =46rom the code structure and messaging I infer that:
>=20
> (fs)->fs_magic =3D=3D FS_UFS1_MAGIC
>=20
> or the code would have done:
>=20
> 	} else {
> 		/* Bad magic number, so assume not a superblock */
> 		return (ENOENT);
> 	}
>=20
> without producing the messaging.
>=20
> Why it would be a UFS1 file system that was created originally,
> I do not know.
END JUNK FROM MISTAKE.

When I looked at the messaging code for CHK to see why it
reported UFS2 I see:

		printf("UFS%d superblock failed: %s (" #fmt ") %s %s ("	=
\
		    #fmt ")\n", fs->fs_magic =3D=3D FS_UFS1_MAGIC ? 1 : =
2,	\
		    #lhs, (intmax_t)lhs, #op, #rhs, (intmax_t)rhs);	=
\

but that implies that fs->fs_magic did not hold the
value FS_UFS1_MAGIC .

Looking back I see that I incorrectly attributed the:

(fs)->fs_dblkno

value to:

(fs)->fs_old_cgoffset * ((c) & ~((fs)->fs_old_cgmask))

End result: The file system is UFS2 with (fs)->fs_magic =3D=3D =
FS_UFS2_MAGIC .

Ultimately: fs->fs_csaddr !=3D (fs)->fs_dblkno seems to be the
failure condition for this UFS2 context [given the 0 in
cgdmin(fs, 0)].

I've no clue about the implications.

>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Mounting from ufs:/dev/da0s2a failed with error 22; retrying for 3 =
more seconds
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Mounting from ufs:/dev/da0s2a failed with error 22: Invalid fstype.
>>=20
>> Loader variables:
>> vfs.root.mountfrom=3Dufs:/dev/da0s2a
>> vfs.root.mountfrom.options=3Drw
>>=20
>> Manual root filesystem specification:
>> : [options]
>>     Mount  using filesystem 
>>     and with the specified (optional) option list.
>>=20
>>   eg. ufs:/dev/da0s1a
>>       zfs:zroot/ROOT/default
>>       cd9660:/dev/cd0 ro
>>         (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>=20
>> ?               List valid disk boot devices
>> .               Yield 1 second (for background tasks)
>>     Abort manual input
>>=20
>> mountroot>=20
>>=20
>> Rebooting using a kernel of:
>>=20
>> FreeBSD 14.0-CURRENT #74 main-n255816-e26ef41f799: Wed May 25 =
15:05:14 PDT 2022
>>   bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>>=20
>> stops in single user with:
>> Root mount waiting for: CAM
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 12345678D558
>> da0: 40.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>> Warning: no time-of-day clock registered, system time will not be set =
accurately
>> Dual Console: Serial Primary, Video Secondary
>> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
>> Setting hostid: 0x5cd40a6a.
>> Starting file system checks:
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Cannot find file system superblock
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Cannot find file system superblock
>> Warning! Some of the devices might not be available; retrying
>> Restarting file system checks:
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Cannot find file system superblock
>> UFS2 superblock failed: fs->fs_csaddr (806456) !=3D cgdmin(fs, 0) =
(5056)
>> Cannot find file system superblock
>> Unknown error 3; help!
>> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
>> 2022-06-25T14:23:46.792050-07:00 - init 1 - - /bin/sh on /etc/rc =
terminated abnormally, going to single user mode
>> Enter full pathname of shell or RETURN for /bin/sh:=20
>> root@:/ #=20
>>=20
>> However, simply exiting the single-user shell seems to bring up
>> normal multi-user operation.=20
>>=20
>> Network connectivity remains sporadic, but is much helped by an =
outgoing
>> ping process.=20
>>=20
>> Could it be significant that this filesystem was created on June 4, =
2020?
>=20
> June 4 is after:
>=20
> 2022-05-27: Do comprehensive UFS/FFS superblock integrity checks when =
reading a superblock.
> 2022-06-01: Two bug fixes to UFS/FFS superblock integrity checks when =
reading a superblock.
>=20
> but before:
>=20
> 2022-06-11: Bug fix to UFS/FFS superblock integrity checks when =
reading a superblock.
>=20
> (and before the later additions of messages about superblock failure =
details).
>=20
> But I can not tell what the status of the system was that created
> the apparently problematical file system. It could be much older
> for all I know.
>=20
> None of these messages suggest code changes to creating UFS file
> systems, just to validation.
>=20
> I will note that the 2022-05-27 check-in does report:
>=20
> QUOTE
> . . . Although
> it appears in only one place, the new code will apply to the kernel
> modules and (through libufs) user applications that read in =
superblocks.
> END QUOTE
>=20
> This gets into why the older kernel behaves differently when used
> with the newer world and why there are messages from the newer
> world code even with the older kernel.
>=20
>=20
> Of course, none of these notes provide any solutions, just
> background information.
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jun 26 21:01:27 2022
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 2065887A814
	for ; Sun, 26 Jun 2022 21:01:29 +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 4LWNZJ1tVzz3Lpm
	for ; Sun, 26 Jun 2022 21:01:28 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 957FD1B45E
	for ; Sun, 26 Jun 2022 21:01:27 +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 25QL1RTp029289
	for ; Sun, 26 Jun 2022 21:01:27 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 25QL1RRr029288
	for freebsd-arm@FreeBSD.org; Sun, 26 Jun 2022 21:01:27 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202206262101.25QL1RRr029288@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, 26 Jun 2022 21:01:27 +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="16562772874.f2fd.25461"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656277288;
	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=QGyu39lm9o3SyT94V1Cj/KzbjcaYXx/3T0mpJUU84M0=;
	b=UmDugbZw24XRyowelxugLQwkGtAPZJqm971s2jNHEYtXkL5E00zBR2yG/WeZvCaP6qlsiE
	EH87UTAmL9Tmx18v0mYWX/fj1Je9qr1+76BjJ94XNkReXY3+AVK8no7HQiX4aoX+nI4ZuG
	bILbr8KUmDO08+1Mjad13z7M9aCtPuESpHQRLSuvJshJY3JcuTnfg7ndOqv8JyrRH6STDu
	RiJNN/+45u+hmNF0bzUzhNpBTP6rZEKWQkr01wxDlAPQHdQfLd/QPO3CUmV1n11KGi26SQ
	+eU96EOjV8MlIfr8wVmXXbj1oLXG6VPM2Owfx7APrwoQdg19BtfokZlFWBZ0uw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656277288; a=rsa-sha256; cv=none;
	b=e+zFLpfKBuGPrd62hBTDyPu36vBnbh2IVQARdnObnsZX74HvvNiWn8aY/YpGBA3nWZnTOh
	eHzh3psV6wwAQ60c4/3uJhPBemmBubpql6Pmwvpf0XR8MVRul2WIyUlFLO+7JYWkzho/qb
	ev2RKF7rWTFtNe3HzQYqmMso6dpQ05wisWuRi0OBP5NPeJF91IxQKgJ/2nBD+eJd5UxV8T
	e+j46ALfdZjmzVqgrJkuMvl2AytvilmIfzYAuQM8rfkmWn1vDcPsTsy1DRJZbjyFcQnlR1
	0yIcSzNBhz3wav38WNQKyV/kAykyMqUlZTuYv6VufmkxVrSLxokalvA1djPlsg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16562772874.f2fd.25461
Date: Sun, 26 Jun 2022 21:01:27 +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.

--16562772874.f2fd.25461
Date: Sun, 26 Jun 2022 21:01:27 +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.


--16562772874.f2fd.25461--

From nobody Mon Jun 27 08:57:47 2022
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 2EE83879DE1
	for ; Mon, 27 Jun 2022 08:57:59 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2117.outbound.protection.outlook.com [40.107.255.117])
	(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 4LWhT212jdz4krw;
	Mon, 27 Jun 2022 08:57:58 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=FqbGacH1enVeTzE5ONsNqncuUO/aB5Fuu4aIwiPTR4So+M5kkMguXKstCPgxYLePOD8xR8eUo8aqIkcN5JTLcBgWP8GZpc0E2fyg8Mxm6pf0x/7ezCvGG1cdteXmb2+4payqsKi1CRB/jZ7R/1xJDuc/GcfZhxRDbcEhqDHkjbOrvMMrSEusiOda6vYGYXqc1xmAkP6FjzBJFIo5tS9lagDXgNmuyE7LkzGTeMUN3UKu3UgfVB3Hy/rPOLYWXkMxqMcc4kfgvBQnBX3gBM1sRUMrMi2VEQjnFTdJyu1F/u3rdncYGfhqR38N7ZdIdiqlbsO/0jdVZTvtnuuhqm2slg==
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=nE2u0nZPsMg9OHrtgqFqBAR+zHB7CSmChGTF01Gnf98=;
 b=Rlw1wzUYjEFwIG9HkJTTl0Ll6iMLL5Jp4vl/cAZuvjhmqoiNitPEn0PXzbNwtMj+mbHNE1vxTg9OLcGc2N78m+GUbOj/awYqxKj2zSWiyXC1OX5snEVQOMJOs8UpCMaJJduTwActnmDbzVL+2UGkoyjvtBxoXLQhlqB9fqJOa2yQVQU97WNfVPI/Ds5342wZjI2TYUn8ylxMcG+oW4sW7cHsmMvcWxQhqupyNPfLE3aEeqjYHJwylNo3O8aXAvN+90V0J2Mz/aM2r1XiJyviC+2DPwj7qM1WWD5sdDP341QEE+wq/tVUAJqYR1QLWpsAOjeGggoo/PWJRy1K2lAw+A==
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=nE2u0nZPsMg9OHrtgqFqBAR+zHB7CSmChGTF01Gnf98=;
 b=dwLj0PCNj63gbQ3EepfZ1dvm296uh9I8OFzW4H+n8XS7w+e+tl9ow3J5edCh673NR0lZeSbNXWL93h8UonPsqfo4fMiSDGf/E4nnCAlkw77cgh1d6bBrAuZXXH6tyLn7gIdkFJMzNRqnsWoMKUVz6gtTiBTrjD4cxNstC2bpdso=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by SI2P153MB0637.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fc::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.5; Mon, 27 Jun
 2022 08:57:47 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::bda2:79a7:8be8:b026]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::bda2:79a7:8be8:b026%4]) with mapi id 15.20.5395.011; Mon, 27 Jun 2022
 08:57:47 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , Andrew Turner
	
CC: Wei Hu 
Subject: SMCCC v1.1 compliant HVC call
Thread-Topic: SMCCC v1.1 compliant HVC call
Thread-Index: AdiKA2Q7WTo8sgKeSKGdouN0obA7iw==
Date: Mon, 27 Jun 2022 08:57:47 +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=65dbb190-b593-4487-94bb-e1ebfc239a79;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=2022-06-27T08:52:51Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 10b5024e-6902-40c2-ddf0-08da581b1b93
x-ms-traffictypediagnostic: SI2P153MB0637:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 AfLsa/0a1wHK2C5zto+cpCLyQQ3mji+JHYQO5De8VTqm3Fgqhw0i2F+HuK76qlloMK1arpOpnrSiyNaA9lRl0sXnSfs1MdSIkofsbtMPruhWZuEWFVssaN/AbRDr55zjtU5EsnPzRDtANbge4vrsdS2qCVjm00/JoId3m1hhxqyUIh9a97ENkT2xE0IFniilWJvH3KdYwq8KQg9sd2826rAX1el8oKt8r9ANcNTj0OU5MTcEu9MfK2XJYeW/iJfeNUdYF9mJPAOG6/cYLES46o/67bYGuRBjTx2/ozlgeUIvoDY1PUnrDMciLR42soswzqFCjPD5ycM+AUViz8PeGaSeat8NHOn5Ft+NwRoX0XpGoFy/OlZtlPIhhN0VZqLgCytGKQTrxqqJq35K9Le6H+QHOVub/vbajzWm0wjJOni54Y1yCP3G72Aul3q8sRy4Lky/zLufEmrUrEs1IhAnETbxphZxGeZla2/yicV6LE5ngj9ePjQYjAY2+HRUnEa7/HdFC20l3qAFyIvH+DpE3uMIc4juohT/DVxqiZX9DnaxErIMfzoaWvyg0j6yufNH1jc4gPZM8sz68LLEKHRBT7Fh6j4u05uIGWo6AIJu9F2rQUmGmdZmT26astR7+buG3gRINB0tqUbMQ/x/KA2XFI9jSWLwbbtfnBAUBjUOUpPmoC4ZDB9djf2kDB3v4Yh44sEwqsUTWHaCF7V4lBt82n9xQr6jqwIykFFCKxfLRp73xTWkBFlZs4jKIqYk/PIZZ3e+vnemA+9sGg2tX9G1hDi2jfioX2670SXzI3fK4+9QuA73BCaE8BX4tt1DIdxWL3wxk4TS7z2boQ3Veq2tZejEoAMPvQ1QUd2ydKHB2ik=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(451199009)(33656002)(10290500003)(966005)(64756008)(478600001)(41300700001)(38100700002)(5660300002)(66446008)(71200400001)(30864003)(186003)(110136005)(107886003)(66556008)(66476007)(66946007)(122000001)(8990500004)(83380400001)(6506007)(8676002)(9686003)(82950400001)(82960400001)(2906002)(7696005)(316002)(55016003)(4326008)(450100002)(86362001)(8936002)(38070700005)(52536014)(76116006);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?sg+atw62wcD4tklGzslB3BfGkpzOYbN8fJc2ocyXllutpfBv/xjFgRMGrNoB?=
 =?us-ascii?Q?kxwa6T4Xkq521keVTFC2F4SDZSGlewGUMghdGMELBTfBfh9KnVTDjnf/SUC+?=
 =?us-ascii?Q?MeE6szltvPJeapgOSkcJs3SmehSZ0Oq738G3Jiq3Q/JyTH3g4rnt8amwaf84?=
 =?us-ascii?Q?XnKk6S+ZFA/cKs+hi0jS8rXw1+MPSgu6ispLV81o5HC4Mv3uD98ivpjtusFa?=
 =?us-ascii?Q?K+EzgY5i4jYBTXxX/MRLWAmzGemet9b8o8zR8PVSGR3Keha1yTJgCxh6SAfo?=
 =?us-ascii?Q?jmcoqNpCK2JH1HexNaAbPvZvRZkcoViqd565Q3LG40Pkywq4m3MFk+u+Aw9D?=
 =?us-ascii?Q?KxO+SAVua3hGqCZO90dh0saJgIsJcnGJ4W8uom431V2HwbmwTYEWBppuMJyM?=
 =?us-ascii?Q?2OAgMEyyIrvoRX6Xt1EvpjVNziucCdfDwcBt+V23ppvwlrjMM6GSxEISjp4T?=
 =?us-ascii?Q?1GHO+hCaylDQow30uk1wuMEjrlZHjCieiqqFarr8VBPPbeNNmBvXbTg3Pc2Z?=
 =?us-ascii?Q?89bjVVtQG8ohLPfmxbmQIsebVxO5NqLX4OzhgzYnX05DoTeQyuu4C9Yy7v10?=
 =?us-ascii?Q?i3YwSM+OAfvx4Tl84dn8o7KtKbKj7ThQF9QzN6ILI240rqbhEfmWhLgPhTnq?=
 =?us-ascii?Q?R1p8wGCgwJ0MDqtxb7bnD3EHIFh8Ek+IjxkDqV8BA22uDhRuhw5O6hkt36Ie?=
 =?us-ascii?Q?FbeDTiNpE81sE+bnWAK0+j0GpTtm+02f3vhc1WDidlNB5MIzWl6do67gXaBb?=
 =?us-ascii?Q?lR5xcn4yOcJmE9alWm6rOqAHEyhhU7XrnxwXnqLBTegV1mLlMxiN1xpLKSo6?=
 =?us-ascii?Q?ATtibQgAAm+Qo7kYcOlh2UQMHXqsKH4lqmkNIkBtyF29gPW10gAbWwj22jly?=
 =?us-ascii?Q?UsaGIl8uYK5FFwnlSE9RIUBYUznIgm6D1fCxVHztzBvVIcDYtA3hILyeY5Ym?=
 =?us-ascii?Q?THfTJSmTQalyPGv/Lerp3uTqi4TBEDDyQ0f7LzmMFq9noQs0z5pYxwL14RCA?=
 =?us-ascii?Q?zmmVh0x1PydHWTnw/3NCMt8OnX1sxGXiW1vKwNXxaopLdYtfmEekEA5uMDwR?=
 =?us-ascii?Q?BKUDST1agl7i8eFciBhvY7gNwfEpuq3Uq80NqDRxCdOWb/xlbveSyeBodYYL?=
 =?us-ascii?Q?BP50uAmGdw4b9V5jJw2gGbWX4RxJZvLh8cVpZUgQKv84vSslucoB4O4Ntgk+?=
 =?us-ascii?Q?RM27klEMbfjzIkQk4ky6z5hbei73a7w/Zd6se6XFZgq6jzD9Y01rO/WbvIWu?=
 =?us-ascii?Q?mfyZNOc3gN9vekZiR+Y2CRoAE0LJjVQpgvDcZr4ISh4k99zWMGyOpILw/2ka?=
 =?us-ascii?Q?fGq65ooYisXctTWMSvzM3bv2sJqck0sEfVRXvYFVSC+7gUztjv+qrH9GhG2p?=
 =?us-ascii?Q?3Wm84vM1cntrjwbAwS0FZ3IpnQWEYxDUIF4U7bnim4gM5857y3NWJfBTGEfH?=
 =?us-ascii?Q?xYybQX463G1gW5vK8GyhTDDoxuiW4zSNe3W94V48WRy2lTvfroIGgU+0u0sW?=
 =?us-ascii?Q?cXSVDCQsU0j4uvbWGQ2e21T+hpwKg/A9c9LEiOq9AlJZprEhUxNHiNvSicE8?=
 =?us-ascii?Q?d+wjYO/R8uGMoatifNnlj1vDQWhAJ5I/af15R9Iz?=
Content-Type: multipart/alternative;
	boundary="_000_PSAP153MB05364B5DEC6F1379B71C3758CCB99PSAP153MB0536APCP_"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 10b5024e-6902-40c2-ddf0-08da581b1b93
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2022 08:57:47.6071
 (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: ar22mXJlze35EVrVtGq5+ARLIGcgQ8TWvBpJgBPPQjHNkr6xkCG/SlSjuBqwkEfWXglsSG1NjR17sBidsR+teG6OtOhW6oU/DFqbCdl8n0g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0637
X-Rspamd-Queue-Id: 4LWhT212jdz4krw
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=dwLj0PCN;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.117 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.84 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.117:from];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.117:from];
	 NEURAL_HAM_SHORT(-0.84)[-0.837];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N

--_000_PSAP153MB05364B5DEC6F1379B71C3758CCB99PSAP153MB0536APCP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Andrew,

In Linux we have SMCCC v1.1 compliant HVC call arm_smccc_1_1_hvc(), which i=
s used for SMCCC and HVC call convention.
In FreeBSD do we have something similar?

I can arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the imple=
mentation details of it. If I need to use SMCCC compliant
HVC call, what API should I use?

Thanks & Regards,
Souradeep


--_000_PSAP153MB05364B5DEC6F1379B71C3758CCB99PSAP153MB0536APCP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Andrew,


 


In Linux we have SMCCC v1.1 compliant HVC call arm_smccc_1_1_hvc(), wh=
ich is used for SMCCC and HVC call convention.


In FreeBSD do we have something similar?


 


I can arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the =
implementation details of it. If I need to use SMCCC compliant


HVC call, what API should I use?


 


Thanks & Regards,


Souradeep


 





--_000_PSAP153MB05364B5DEC6F1379B71C3758CCB99PSAP153MB0536APCP_--

From nobody Mon Jun 27 16:29:05 2022
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 7B24887956E
	for ; Mon, 27 Jun 2022 16:36:02 +0000 (UTC)
	(envelope-from andrew@FreeBSD.org)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LWtdY65ZDz4psK
	for ; Mon, 27 Jun 2022 16:36:01 +0000 (UTC)
	(envelope-from andrew@FreeBSD.org)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id A18184E67E;
	Mon, 27 Jun 2022 16:29:06 +0000 (UTC)
From: Andrew Turner 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5E6DBBF9-54AB-482F-A909-36108AC2442A"
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 \(3696.80.82.1.1\))
Subject: Re: SMCCC v1.1 compliant HVC call
Date: Mon, 27 Jun 2022 17:29:05 +0100
In-Reply-To: 
Cc: "freebsd-arm@FreeBSD.org" ,
 Wei Hu 
To: Souradeep Chakrabarti 
References: 
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Rspamd-Queue-Id: 4LWtdY65ZDz4psK
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 139.59.165.16 is neither permitted nor denied by domain of andrew@FreeBSD.org) smtp.mailfrom=andrew@FreeBSD.org
X-Spamd-Result: default: False [2.99 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 GREYLIST(0.00)[pass,body];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_SPAM_MEDIUM(0.98)[0.977];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 VIOLATED_DIRECT_SPF(3.50)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.989];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_5E6DBBF9-54AB-482F-A909-36108AC2442A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 27 Jun 2022, at 09:57, Souradeep Chakrabarti =
 wrote:
>=20
> Hi Andrew,
> =20
> In Linux we have SMCCC v1.1 compliant HVC call arm_smccc_1_1_hvc(), =
which is used for SMCCC and HVC call convention.
> In FreeBSD do we have something similar?
> =20
> I can arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the =
implementation details of it. If I need to use SMCCC compliant
> HVC call, what API should I use?
> =20
> Thanks & Regards,
> Souradeep


You can use arm_smccc_hvc to hard code the type. Both the hvc and smc =
versions are implemented in sys/dev/psci/smccc_arm64.S. They depend on =
the arm64 ABI to put the arguments into the correct registers to be =
passed into the hypervisor.

If your code is running after the psci device has attached you can use =
psci_callfn. It is a function pointer to either of the arm_smccc_* =
functions depending on what is in ACPI/FDT.

Andrew=

--Apple-Mail=_5E6DBBF9-54AB-482F-A909-36108AC2442A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On 27 Jun 2022, at 09:57, Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:

Hi Andrew,
 
In Linux we have SMCCC v1.1 =
compliant HVC call arm_smccc_1_1_hvc(), which is used for SMCCC and HVC =
call convention.
In FreeBSD do we have something =
similar?
 
I can =
arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the =
implementation details of it. If I need to use SMCCC compliant
HVC call, what API should I use?
 
Thanks & Regards,
Souradeep

You can use arm_smccc_hvc to hard =
code the type. Both the hvc and smc versions are implemented =
in sys/dev/psci/smccc_arm64.S. They depend on the arm64 ABI to put =
the arguments into the correct registers to be passed into the =
hypervisor.

If your =
code is running after the psci device has attached you can =
use psci_callfn. It is a function pointer to either of =
the arm_smccc_* functions depending on what is in ACPI/FDT.

Andrew
=

--Apple-Mail=_5E6DBBF9-54AB-482F-A909-36108AC2442A--

From nobody Tue Jun 28 06:06:19 2022
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 AE1B1876C71
	for ; Tue, 28 Jun 2022 06:06:30 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from apac01-obe.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 4LXDcj2wjVz4RSt;
	Tue, 28 Jun 2022 06:06:29 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=SgsVSweAAPfCI9Nw1oaBlrZG310CcI/I4sUeMZOLoYBetiyYkyBmrUnyZDuVYaS5TG6zJafDvE4BH2h3iySecsrNSUGkJB1c5FiSgrz48PSdCvetXZVv52NqxKYGjpglju8go/Izpive2AcRh71EFha/AwHhu0BFerrNiU0X/x3o41n839IUsPCwQTdA4budGTgxliYHPhAfeF+GpaAi2JiO19eBsanJSe7w4wgXRkLxiDnaLMv53ajGx5yz0vjXh3t672IC3jZJrgA8gTMCZ8En5e/esUP12BwmJFB+iAP3iEEVecjet6boXufRfV7QvJbr7jjhUlPIvB0CjncBGQ==
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=WBfd9oFu3GujTgt762d1vHYICYMCqCN+g3gIP1FAexk=;
 b=miWrEeXjC6D7houo7uuHA2GmecwJo/jc5zeqJ5tqmSYWul/t7ES9O47B2j2QLySlgirkcxGPtk0wtOM2Eh2AnnkmjOgepR+kuvrraHshzP7Gvugm6OZknGmYiTHyn5O/hioEPRmcVxDw7BhsOw50+TeYrabCibGINBB6c/vVxMhmEqkwnFOIvTR1JvvQRwdGpniiiu459ViF/wW3RDKOo6fC/+6pLp7ZRgYHJhuqBZgKlE83A3LdcA2R1s2W3zEaAt+DfmeeO/ujm3e/IWNRfD41kkkurWalSMS6+DimiDGvHXwjgDTTpbTOsEpvXa6mNVWqj1jFLRwZgPrGEth/pA==
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=WBfd9oFu3GujTgt762d1vHYICYMCqCN+g3gIP1FAexk=;
 b=M0Fi8lMSp325xdu06c90V5LXxb6yrFsbpDVJnE7R5Qp33E0roiMgFXEChUBYzHCwlvtpGp4HQ63rtRjsfXx5V2IrXYbSTL6EHoaVejt+gulIosmAS4PjJDVUbspg4KAjntes3rpJxOAvBI1JSU8F6PMXGTqMnTACI35tyTL8OBI=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PUZP153MB0751.APCP153.PROD.OUTLOOK.COM (2603:1096:301:e0::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.5; Tue, 28 Jun
 2022 06:06:19 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::bda2:79a7:8be8:b026]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::bda2:79a7:8be8:b026%4]) with mapi id 15.20.5395.011; Tue, 28 Jun 2022
 06:06:19 +0000
From: Souradeep Chakrabarti 
To: Andrew Turner 
CC: "freebsd-arm@FreeBSD.org" , Wei Hu
	
Subject: Re: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call
Thread-Topic: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call
Thread-Index: AdiKA2Q7WTo8sgKeSKGdouN0obA7iwAP6A+AABvz3ZY=
Date: Tue, 28 Jun 2022 06:06:19 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-28T06:06:22.010Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 810b862e-4dc6-4610-6e61-08da58cc5188
x-ms-traffictypediagnostic: PUZP153MB0751:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 WZyJicE+gTey1ZoKKLI22BKjQ9EpoXqqYdiZ2OoL/dJyPttk2J1NyywuCZm35/QsD72kD63qkWFTGPKA7Tn0HNxVTDwwXCRXMRUXI/QCxCmL8UQCKwgFS+/OddPj1yXenEdYY5OuOW39mWlMt6MjJ9ZLh3zEmH+ysYkVhhl1Re3a758Y68KyMBeqjQz2tR6sGaex3Jd+QMx8+OntWbwtGsulEveaAOROIIjxImfFg4Xx4uSZuOsnLk1gOp9NG/wONElKYrYBO+dRByNH509rEhBeLNk+CIGhU61FY1UHAK9yx0T/rLGT6yQUcCVU6twod1Hn8QZBOgVH53W3xxhzPZbJiBDVdFR7TA+6DDmVgv+paoLkl0bKR+9CAf4jbXdtt5jZiipUdjHi1vSO1LjsLSVeo+iifG5qA0vgGNs1befn4dKzgBWuEIANZU3RsG9sNdHNBCtTuG6UemzDpYegajm6L5W7iP9dhS0+0VY8zIuQxihs0sFIgDAaCbGLs8KsUayraUExOz5ai4GX3AePcvR9by08XvfQDrBz5Ym3NjoCdfudKyAXbGEmIzWutkJH3CLBRkuBBIZ5Z4eyXNiIPTxqJ/7byZshLukeVaNR6OrEXK1Vu8bDj8aH+Wd8Bv2xpuMhuoRFPl+Ym9K8AcuiU/qHrcHG4cnpNI+qbi0BhIAyLxhknJMZVmyI0mNljDtqY0Jaiv5HfwM6FLdtivEuRlAL5dnVCc8iSbf9ulJ6AxraRc9qdUTBkxISyTsPlPk6bJSy6w8SljCl0h362SZWNwy+vU3iFEaLLstEqD87QUkrGoNzeEeAkQk95w2AG7fDOuY4sQtnaogi44p3yLGO+w==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(376002)(136003)(346002)(396003)(39860400002)(366004)(451199009)(66476007)(450100002)(4326008)(66446008)(8676002)(71200400001)(64756008)(53546011)(91956017)(66556008)(66946007)(76116006)(6916009)(10290500003)(316002)(26005)(54906003)(33656002)(9686003)(86362001)(2906002)(8990500004)(186003)(5660300002)(52536014)(38070700005)(8936002)(107886003)(55016003)(122000001)(7696005)(38100700002)(82960400001)(82950400001)(6506007)(478600001)(41300700001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?Myz24p3LckgRb6iMZDBYxV4G0nofsCw5dRR92So72Y46BZafN1VUMkW4ZC?=
 =?iso-8859-1?Q?YbXa4VIqsTy/uznWzlO9LpwRNx3KtqSv+1NfKpCc/sstuTb3iQo33cw/0s?=
 =?iso-8859-1?Q?iYOiiIjP/fqXMyksnIuTbHPvYjNfWdiqhbnLySfbjH3pEljwS3TRM8iAiq?=
 =?iso-8859-1?Q?osYoNQTsAGXed2RrnaYH6ploGtlwDqzlMf/xKIBgBAm7OgHshLV3hgPh1H?=
 =?iso-8859-1?Q?hMMswpZCM/kYMPk/5zK46hUN7HQyFOcUKvw7q0a8+fRUHHMwrgU7IIN+vm?=
 =?iso-8859-1?Q?SCykyL4x8f0AcKpbh49bhWQ2xAocPrHNTM0iouv8pzrjbUzvHQxqg1wk5D?=
 =?iso-8859-1?Q?M3ttZMA3580KGd2jOOycGH3SWg92jgtuOrua9ldFiNThWgwAtwxvI7GJTl?=
 =?iso-8859-1?Q?uzkyPBjrQx/Xqsd47HTUUsNmRjxXnuQgfB6hPtvz9fba+ZkqslhUaaxdrc?=
 =?iso-8859-1?Q?ls5CvdSyHLklEzWo7rB99QJEDenx6QxkDtWruo1y55y0f/yGZpbhwAE++l?=
 =?iso-8859-1?Q?szyplKDZAbkNBUA6464z7rIGQKS8wXj7iV27/MGsLab0UVCLYTkbsQ6OO2?=
 =?iso-8859-1?Q?WpQlxCT/Wa7SBAsbPEQKfzdhccub9w+HKKI4L533qhhpGqgYjfNYBtXFYj?=
 =?iso-8859-1?Q?uG1geG9m7OESc+y5CUy3lrSaOfl8v99K5oVOupOFC+bXoBsxGK/X0zKZre?=
 =?iso-8859-1?Q?TnrE3x42q6gLslkChCEWmfAWAznAX0axIycGl+KNjnT9zzGP2MYUeqHJ1V?=
 =?iso-8859-1?Q?rlKniLkHQTmZCGgHTq8UkIq+02ML1iR3rhhvvHXBKADG3kUExdUnljxak7?=
 =?iso-8859-1?Q?t1FsDBP5xcpoLrmY1nppXKqgbyb5QSRdoovTVqUDr/MMaMva6shrW2kzg6?=
 =?iso-8859-1?Q?XbIzXGDU2LqIkBdNMb1ZaCqBVROIvhikJQXKEeVi85yMrxvoZsmt+Nmujy?=
 =?iso-8859-1?Q?p+eMdKBc4LpS0BWQXVeYSUF2OohianRtMstseFuxUREfSRfiakpLFC0Zyg?=
 =?iso-8859-1?Q?LR37GadW/8OBX3nO60ikea4Fpz1eslCxXavqyng83WvO+1+ZyFFoTcl6Ei?=
 =?iso-8859-1?Q?S2htMijsj/AT4jVDc0m1FfafrBRtLkLPkT6QpVNsqHFinGc0DefvJqoPLX?=
 =?iso-8859-1?Q?jT3JncZ+oXkSm/xcJtGqQ43+7j+r6EWWuLWxwbTWB2mObiyoBfqq7jcO+/?=
 =?iso-8859-1?Q?Pu1ozhhSJDElJ3l/PRZt1EJf02aF2wdvbU8Ped2iGBjz5gUMrnK3bdZYzo?=
 =?iso-8859-1?Q?RBSJr22m8OwfRFYZ+8ubJZodrHsumPI3JnTAbQPiou4qukqvPXlpBuiHpP?=
 =?iso-8859-1?Q?ADb5HCiHiDTzAqivY+6ZO8qo9A+bhELXCp59ZxJq7N+3RHrJVfauiDA33O?=
 =?iso-8859-1?Q?ZiR4YRVtxF7loZscBU7AivwqkMzM5GqdCKK8lvKnGJ86SU+SKyY4a1m/Xm?=
 =?iso-8859-1?Q?zhExAPmBPP+i27Cc/0lkupJiWc2D5vSln0GIzikby2azvz833sm+bnGTfY?=
 =?iso-8859-1?Q?H2duQGMdAfGhaa8EQglwjPUb12qXvFdS7nq8o/mOPBIFHl2OJ06600cmT1?=
 =?iso-8859-1?Q?o0BlkMCGCZu8NUZkNhyD9FgaZTSM?=
Content-Type: text/plain; charset="iso-8859-1"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 810b862e-4dc6-4610-6e61-08da58cc5188
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2022 06:06:19.0659
 (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: svaDxJXNXKJjG7Z+FU6031SpuXI7oy+B5P4zhHYfUHGK3CifoOcnAIObZ4nMbaViokOLm55IJv1+zYXL9yTxoKGzhyNNCGLfZRgilhv0u58=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZP153MB0751
X-Rspamd-Queue-Id: 4LXDcj2wjVz4RSt
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=M0Fi8lMS;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.17 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[52.101.128.17:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N

=0A=
Hi Andrew,=0A=
=0A=
Thanks for your response. While looking into the code, it looked to me we h=
ave smccc version till 1.1 implemented.=0A=
But for hyper-v hypercall implementation we need to read registers beyond X=
0 to X3, which is implemented in 1.2 version.=0A=
=0A=
Is there any plan on version 1.2 implementation ?=0A=
=0A=
Thanks & Regards,=0A=
=A0Souradeep=0A=
=0A=
=0A=
=0A=
From: Andrew Turner =0A=
Sent: Monday, June 27, 2022 9:59 PM=0A=
To: Souradeep Chakrabarti =0A=
Cc: freebsd-arm@FreeBSD.org ; Wei Hu =0A=
Subject: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call =0A=
=A0=0A=
=0A=
=0A=
On 27 Jun 2022, at 09:57, Souradeep Chakrabarti  wrote:=0A=
=0A=
Hi Andrew,=0A=
=A0=0A=
In Linux we have SMCCC v1.1 compliant HVC call arm_smccc_1_1_hvc(), which i=
s used for SMCCC and HVC call convention.=0A=
In FreeBSD do we have something similar?=0A=
=A0=0A=
I can arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the imple=
mentation details of it. If I need to use SMCCC compliant=0A=
HVC call, what API should I use?=0A=
=A0=0A=
Thanks & Regards,=0A=
Souradeep=0A=
=0A=
You can use=A0arm_smccc_hvc to hard code the type. Both the hvc and smc ver=
sions are implemented in=A0sys/dev/psci/smccc_arm64.S. They depend on the a=
rm64 ABI to put the arguments into the correct registers to be passed into =
the hypervisor. =0A=
=0A=
If your code is running after the psci device has attached you can use=A0ps=
ci_callfn. It is a function pointer to either of the=A0arm_smccc_* function=
s depending on what is in ACPI/FDT.=0A=
=0A=
Andrew=

From nobody Tue Jun 28 07:29:11 2022
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 2EE9F8635D0
	for ; Tue, 28 Jun 2022 07:29:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LXGSN4bdYz4cgT
	for ; Tue, 28 Jun 2022 07:29:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656401357; bh=kh++T9rq5Mjw75FWNP+a1evc/c3p69ZMlBpNAyvTlxw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iFa3juydYi0VpX8tmbvAO9YSlzag6cGRkc+S1nTY5nJci42q+79mVMjVnI4p2ZWt5pZwhC8EZGSYJLFTFp85afBrRyDuMMD6xynUTl8whKSY8uWHo3tw5Z82Eo+i7WPEDp8aXOwuxBGpRfNGXnYmJXKbI4TgHmEH5lxNxQMCSQtDZHEfd1F8HEALkywzqIylLEnigBQ6Jsc/YsO3+Lt6eKaknJnld7DD9fu42C9r1UGLTDoVLBfjLbrKEF52QJgWOApkBwcTz7HGn2wFbF4VxTwMrayd6H/MErcdA2VbQFTJM77z+/cVTJLaRaTmW1W8i7lQ47rqOvW9eawWzMNlpg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656401357; bh=4ipYjrgucoj+HHYAeYlhAH23nmiEcumpNjSuBr3ojU7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gQDhY8RsFw37geTPVPGSfZY7JRrXHxEVZ7NJ39qXuuPqWLuCvM4nGtQrfQi1YXNOGYbrL9d7K3pxd7LOu1zUnpVEo8Fwvmup7HfT2GeoJVU6e+NiUc1m3vIucGtWsL9ej5avpB0dPsxjhtbdDnXORU66tasl2jMH6Hz4kSHErTebJzyIZ7DG4j7EPMlQU3QDpcMaVUr6g/QPVXKD5MIJbQgZzGyISKPCAypUTFrMgnccDlB9vcbwYdoqD7y6xMpXTC3Gd3LVzglssnn8TSx6ETUPPiURrJfLccSLKKrKEiXwr3bqMUSsduIyrHnbo5bAj6iMQZ/1YdvSHF0nmDwsug==
X-YMail-OSG: VPDo8kEVM1lbIOTvC66.BWJRPFEWex1dktbJbX6ZF1wVTE8XR9L9qafRP_OrW5g
 VP90HH71KiDNLTtMsF44YLBs.Zy21MTTkFHKn8fRCkcwUK35kbuX9Zxqi2vIf8NIC8SRQEeLVku0
 fevY2J0hzD_FZSqlu4Lt_w941UqgINNzgxXEpiBEBSDiEzADSNxEX3LDslhuz7uQgYlNzSppzoLC
 AMJ_nTHnV4EEnXO9vcaTI.VtzkpoGW2ADM2ubnjpHSv9.vG_TA2_OfeBYiuKBiAjJSV5izI.FCs7
 RUUUuwlIYWCxkao_wqbKMtGZAqCVMTGfh1XaAOmhzQZAAAuhin89V_0LSBapJEkUl6t6l.dWHPnl
 SonrDbFEyueMNgTMqT5gGmKO6q_qWP9OfJ1ayCoXGFfypulQN1SsvfHDU3wGye61zcXsd3fHiojg
 OY4TROe9WkGh1sfcAG_jY4P0QCxEfC6M92PC1VeM0OKvtBpywVxywr4uR.8Svp4445xGF_joipca
 jZpfdsdxS38voZsldbg2Y.dyyqpUBjbcviGIMA4vhJ8KnGTl8d7wbsHtMYDn9jQd9KuNA.JoyjG9
 poLzcU3xZ078K.SO3KvvIrTBecJiFkwvpa_eLECDCF.z8VI_Rb5Izfs3wZcgGZcSPtbRcPy9J8VR
 S0HuwDDp6H4S0LGrgip._0C1LqFTnTVyzd9aBzm6BiCAZ0kVh67a52RLAugy5ZT7yC0p1Pjyx3C8
 lynhAv7U5EzhM.UHHJQOBTVV8sZl8sJFYq4wqFhhW5wJBRoVytLa3_evrXnxS9IZQiXO8gfnjTEF
 cLnvdBQxYJgpNKHs4wLv7Y5AsHn.R4SGQQntK3DKNrtE6UPV28RUEHn3_XgZS.hXYdjrusFaHndK
 HHO4YkAOWml50VPMG4IPiA_WX81YgdIQqrriqDdBN_vlEqsqGXmYSjagNL0X6UNRMYPVLTab7BEK
 psHEoBp2zBUyfbGd6HJNAZThCmGpti.45y21N3.H.kFu2VxjYdn0Ix.7Xsxp_YO_nxP_DiUKn_FC
 q3U7Y81hWiJkfrqUjSwBNWnV6HVuc7BzLP9Seg1hxMNveMa5BC8dzoJ.MSm0QprV0SMWpsEjJll1
 5ygSb2zb3e4QjdWOG5r2HF8dAmyMagmrOIvGhObv7M4IxWF5uKxojB.aA4lrNgQiYK0LV8s9IeLJ
 VN7G5Pp9k5hLILjQR5_JYR1e_1Dw4c13JdhhRee_XBFtMDyn2Hd9dIPT54Lbs_nFEXxv.WjBFjuL
 Z7diSawq9_JH9iMb387z_w6JsHYDe_OsXqKRgDUwMrtj4kR3uCtDWbYK99DWZ5kA9eYdIBnoK.eh
 q58KZw7rPNzY6hGmUkIpJaKwKu.qFRuRPAt2jhR2HItAVsMSTttgfmc08yvmTWOQKu6E85M1gyiA
 Tn0Ep.2fA7u1b_Sgso0Y9yjlo7vRIlQlwIuUOPX9Htnakn4bRJ2ZTJ.GSxcGxYosiHERdNr7MXuI
 v5xPzsIoeQilAF9xIEKkAxbefTY4pVpiYN4uowxfPY7XvyGxsoNtPUCJ_Ybg_N3dt3IaCCQ8BSiw
 fehae.Q1HlM6uXVWb1c8RaE0YPraBLSU_h2OubGlh0OCvjlQHsaismcwzfBR3qdynThKFILKYxTA
 oBdQRymFsW4OVeW4ABMcJ9uJqJyaUVhHqgp.7nRXdRO6DwQH9.DoIcvpRPE.WckHCko3yS_dU.qR
 9Ygdw.gIVQ_kaBDYR2FvxQR6A3KxmWjrUkchRX214w4zU92fC77dO44jHXd4qBHctQ9czAS1pLQx
 GadDuFihkS5MBWWMfPE4APwsJfrFoSXB9vC0rdK6hK0MteZnXjC3x3Ck9F9XMJKoWd2mIdr.2Tqt
 0tMFIXTzWAK7krDWVFNy9kxoIujza69RdHqumVkjOnxyhxmIyYJTVyLVL8VUV0oLXmW8vtvIuJ_M
 myMQe4ePDdtBSReWtqDdN9MA1ryrde2EWlMc250BVV_wJY9kqYbqvGdwNaSRYqiwd4LznyziBo01
 eAPx0kLb7pyTfxlNM2qNyGxg0QGxen1a.2i29p4mWHOd9C408sDL0Lp4-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jun 2022 07:29:17 +0000
Received: by hermes--production-bf1-7f5f59bd5b-wklkv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d518d29f196c8f4cf9a316acc1498336;
          Tue, 28 Jun 2022 07:29:13 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Mountroot problems on RPi3/aarch64
From: Mark Millard 
In-Reply-To: <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
Date: Tue, 28 Jun 2022 00:29:11 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3108CA8F-55B4-461C-9CFA-7F80BD88A85D@yahoo.com>
References: <20220601154142.GA41835@www.zefox.net>
 <5FA108CF-0973-4A53-A3B7-FA7BE41EB16D@yahoo.com>
 <20220601214401.GA42494@www.zefox.net> <20220602045202.GA44686@www.zefox.net>
 <1B845A0C-EDDC-407C-96A8-AAF4E92C2A4D@yahoo.com>
 <20220613153325.GA12588@www.zefox.net>
 <50CE21C4-CBE5-4ECB-A27E-42B7AAF71822@yahoo.com>
 
 <20220619042225.GA2267@www.zefox.net>
 <3458F90E-CFC9-4B91-8C4A-DD5788239172@yahoo.com>
 <20220621192448.GA1874@www.zefox.net>
 <54365257-9DA2-4058-9354-B5D76E7AAC70@yahoo.com>
 <47AFE262-8425-4A4D-A425-41CF39AA381E@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LXGSN4bdYz4cgT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=iFa3juyd;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.26 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.76)[-0.757];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Well, there is another check-in, but this time it is
a fix to growfs:.

=
https://lists.freebsd.org/archives/dev-commits-src-main/2022-June/007525.h=
tml

shows:

Kirk McKusick 
Date: Tue, 28 Jun 2022 04:48:39 UTC=20
The branch main has been updated by mckusick:

URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D2049cc3218151f8d4108d878196905c3=
4bbf15bc

commit 2049cc3218151f8d4108d878196905c34bbf15bc
Author:     Kirk McKusick 
AuthorDate: 2022-06-28 04:46:15 +0000
Commit:     Kirk McKusick 
CommitDate: 2022-06-28 04:48:24 +0000

    Correctly update fs_dsize in growfs(8)
   =20
    When growing a UFS/FFS filesystem, the size of the summary =
information
    may expand into additional blocks. These blocks must be removed from
    fs_dsize which records the number of blocks in the filesystem that =
can
    be used to hold filesystem data.
   =20
    While here also update the fs_old_dsize and fs_old_size fields for
    compatibility with kernels that were compiled before the addition
    of UFS2.
   =20
    Reported by: Edward Tomasz Napiera
    MFC after:   1 week
. . .


Unfortunately, testing this looks like it would be going back
through your sequence/usage pattern that lead to the problem,
to see if it is avoided. It is not a way to fix an existing
UFS2/FFS problem.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jun 29 09:06:14 2022
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 22B6886ECD6
	for ; Wed, 29 Jun 2022 09:07:25 +0000 (UTC)
	(envelope-from bproffit@amaranth.digital)
Received: from mail.amaranth.digital (mail.amaranth.digital [66.23.237.42])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LXwZz5gdzz3KrC
	for ; Wed, 29 Jun 2022 09:07:23 +0000 (UTC)
	(envelope-from bproffit@amaranth.digital)
Received: from [192.168.1.32] (unknown [73.83.240.71])
	by mail.amaranth.digital (Postfix) with ESMTPSA id 2DD93FBBB2
	for ; Tue, 28 Jun 2022 22:08:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=amaranth.digital;
	s=amaranth; t=1656468504;
	bh=STIreOzpdsxZSXuBMjAGz7G08mgk7m4uqnmiYPzesLI=;
	h=Date:To:From:Subject;
	b=eoIL2xULnmAjzyeltUyA8BV5hHJ6Pe2EKrn0BW4Ww7hMne01sI0jvQ+MVed81iohM
	 Iw3YXtnoDCVp++OtIiz1aGxuBVoSXlOn+/3zj9FDwZ41SU8ZjqAyRJSDrnKH1xmpNs
	 7gvF1BQo+mgMfZIolR8whJkSmIz1ErHe9BBsd8muIJDI7yb/X7S4+m8WKID0tVGMRC
	 jFmeCQe0OpSetpvDv8ps80+PsbxpRlPYS502O13xxxR/Ayno8r8l2uVKKhpcIt7/HA
	 DY7/7EPBHyZ5mdHWJIvmiBLve9wcDW/7oM7jwReZgT05ToO41xjoYyvohf8C48LJAA
	 6m7xU4wohGfPw==
Content-Type: multipart/alternative;
 boundary="------------c268bajFDQH6Lt4n6MzfzKaV"
Message-ID: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
Date: Wed, 29 Jun 2022 02:06:14 -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
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
To: freebsd-arm@freebsd.org
Content-Language: en-US
From: Bradley Proffit 
Subject: U-Boot fails to load from SD when a USB dual HDD device is attached
X-Spam-Status: No, score=5.8 required=10.0 tests=DATE_IN_FUTURE_06_12,
	HTML_MESSAGE,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_NONE,SPF_SOFTFAIL,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.5
X-Spam-Level: *****
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on
	mail.amaranth.digital
X-Rspamd-Queue-Id: 4LXwZz5gdzz3KrC
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amaranth.digital header.s=amaranth header.b=eoIL2xUL;
	dmarc=pass (policy=none) header.from=amaranth.digital;
	spf=pass (mx1.freebsd.org: domain of bproffit@amaranth.digital designates 66.23.237.42 as permitted sender) smtp.mailfrom=bproffit@amaranth.digital
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[amaranth.digital:s=amaranth];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.amaranth.digital];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[amaranth.digital:+];
	 DMARC_POLICY_ALLOW(-0.50)[amaranth.digital,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:19318, ipnet:66.23.224.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[73.83.240.71:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------c268bajFDQH6Lt4n6MzfzKaV
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual 
SATA-to-USB hard drive docking station, and I've noticed a peculiar 
situation: U-Boot fails to load FreeBSD from the SD card when the 
docking station is plugged in and has two hard drives in it (presenting 
two USB storage devices to U-Boot), but still succeeds when:

 1. the device is not attached;
 2. the device is attached but only has one hard drive in it, presenting
    one USB storage device to U-Boot;
 3. when the device with one hard drive in it, and another USB storage
    device, such as a flash drive, are plugged in.

Any clue what might be causing this problem? I wonder if this might be 
an issue with voltage sag/over-voltage on the USB interface causing the 
SD card not to select, or something similar, although the docking 
station has its own power supply and so should not be drawing a 
substantial current from the pi.

I've included what errors I collected through the serial interface.


    U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)

    DRAM:  3.9 GiB
    RPI 4 Model B (0xc03112)
    MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
    Loading Environment from FAT... In:    serial
    Out:   vidconsole
    Err:   vidconsole
    Net:   eth0: ethernet@7d580000
    PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
    starting USB...
    Bus xhci_pci: Register 5000420 NbrPorts 5
    Starting the controller
    USB XHCI 1.00
    scanning bus xhci_pci for devices... 3 USB Device(s) found
            scanning usb for storage devices... 2 Storage Device(s) found
    Hit any key to stop autoboot:  0
    U-Boot> boot
    switch to partitions #0, OK
    mmc0 is current device
    Scanning mmc 0:1...
    libfdt fdt_check_header(): FDT_ERR_BADMAGIC
    Scanning disk mmc@7e300000.blk...
    Disk mmc@7e300000.blk not ready
    Scanning disk emmc2@7e340000.blk...
    ** Unrecognized filesystem type **

    ...

    run bootcmd
    switch to partitions #0, OK
    mmc0 is current device
    Couldn't find partition dhcp 0:1
    MMC Device 1 not found
    no mmc device at slot 1
    MMC Device 2 not found
    no mmc device at slot 2

    Device 0: Vendor: ASMT     Rev: 0    Prod: ASM1156-PM
                 Type: Hard Disk
                 Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
    ... is now current device
    Couldn't find partition dhcp 0:1
    BOOTP broadcast 1
    BOOTP broadcast 2
    DHCP client bound to address 192.168.1.33 (1246 ms)
    *** ERROR: `serverip' not set
    Cannot autoload with TFTPGET
    missing environment variable: pxeuuid
    Retrieving file: pxelinux.cfg/01-dc-a6-32-90-1f-1e
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A80121
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A8012
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A801
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A80
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A8
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0A
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C0
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/C
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/default-arm-bcm283x
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/default-arm
    *** ERROR: `serverip' not set
    Retrieving file: pxelinux.cfg/default
    *** ERROR: `serverip' not set
    Config file not found
    BOOTP broadcast 1
    BOOTP broadcast 2
    DHCP client bound to address 192.168.1.33 (907 ms)
    *** ERROR: `serverip' not set
    Cannot autoload with TFTPGET
    BOOTP broadcast 1
    BOOTP broadcast 2
    DHCP client bound to address 192.168.1.33 (1312 ms)
    *** ERROR: `serverip' not set
    Cannot autoload with TFTPGET
    U-Boot>


Thanks!

Bradley

--------------c268bajFDQH6Lt4n6MzfzKaV
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual
      SATA-to-USB hard drive docking station, and I've noticed a
      peculiar situation: U-Boot fails to load FreeBSD from the SD card
      when the docking station is plugged in and has two hard drives in
      it (presenting two USB storage devices to U-Boot), but still
      succeeds when:

    
    
      
  1. the device is not attached;
    2. 
      
  2. the device is attached but only has one hard drive in it,
        presenting one USB storage device to U-Boot;
    3. 
      
  3. when the device with one hard drive in it, and another USB
        storage device, such as a flash drive, are plugged in.
    4. 
    

    
Any clue what might be causing this problem? I wonder if this
      might be an issue with voltage sag/over-voltage on the USB
      interface causing the SD card not to select, or something similar,
      although the docking station has its own power supply and so
      should not be drawing a substantial current from the pi.

    
I've included what errors I collected through the serial
      interface.

    

    

      


      

      
U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)

        

        DRAM:  3.9 GiB

        RPI 4 Model B (0xc03112)

        MMC:   mmc@7e300000: 3, emmc2@7e340000: 0

        Loading Environment from FAT... In:    serial

        Out:   vidconsole

        Err:   vidconsole

        Net:   eth0: ethernet@7d580000

        PCIe BRCM: link up, 5.0 Gbps x1 (SSC)

        starting USB...

        Bus xhci_pci: Register 5000420 NbrPorts 5

        Starting the controller

        USB XHCI 1.00

        scanning bus xhci_pci for devices... 3 USB Device(s) found

               scanning usb for storage devices... 2 Storage Device(s)
        found

        Hit any key to stop autoboot:  0 

        U-Boot> boot

        switch to partitions #0, OK

        mmc0 is current device

        Scanning mmc 0:1...

        libfdt fdt_check_header(): FDT_ERR_BADMAGIC

        Scanning disk mmc@7e300000.blk...

        Disk mmc@7e300000.blk not ready

        Scanning disk emmc2@7e340000.blk...

        ** Unrecognized filesystem type **

        

        ...

        

        run bootcmd

        switch to partitions #0, OK

        mmc0 is current device

        Couldn't find partition dhcp 0:1

        MMC Device 1 not found

        no mmc device at slot 1

        MMC Device 2 not found

        no mmc device at slot 2

        

        Device 0: Vendor: ASMT     Rev: 0    Prod: ASM1156-PM      

                    Type: Hard Disk

                    Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)

        ... is now current device

        Couldn't find partition dhcp 0:1

        BOOTP broadcast 1

        BOOTP broadcast 2

        DHCP client bound to address 192.168.1.33 (1246 ms)

        *** ERROR: `serverip' not set

        Cannot autoload with TFTPGET

        missing environment variable: pxeuuid

        Retrieving file: pxelinux.cfg/01-dc-a6-32-90-1f-1e

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A80121

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A8012

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A801

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A80

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A8

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0A

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C0

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/C

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/default-arm-bcm283x

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/default-arm

        *** ERROR: `serverip' not set

        Retrieving file: pxelinux.cfg/default

        *** ERROR: `serverip' not set

        Config file not found

        BOOTP broadcast 1

        BOOTP broadcast 2

        DHCP client bound to address 192.168.1.33 (907 ms)

        *** ERROR: `serverip' not set

        Cannot autoload with TFTPGET

        BOOTP broadcast 1

        BOOTP broadcast 2

        DHCP client bound to address 192.168.1.33 (1312 ms)

        *** ERROR: `serverip' not set

        Cannot autoload with TFTPGET

        U-Boot> 

      


      

    

    
Thanks!

    

    
Bradley

    

  


--------------c268bajFDQH6Lt4n6MzfzKaV--

From nobody Wed Jun 29 14:09:34 2022
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 77F3A868DAB
	for ; Wed, 29 Jun 2022 14:09:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.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 4LY3Hr2kD2z4dLd
	for ; Wed, 29 Jun 2022 14:09:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656511777; bh=aUceiRjXSoktlzxttGecTpdqvoRImAJCaCRbFHrqgdE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qOf5mAPAzxsfcdK2TpeKwKXYnenjIwEfm3apL/9atyjt7LLHgIzcSF3cAYlfOlqqqL3xa8QkFC+JI9c6QlJ32zx5qaK3OmZujyO+BqkUJWn1c8M+CmGmHdoyEEMw9rqvZ9GVZzFdFbcRhEMOObonlzZHB3qXazCI2E03rohh7giBG5YVJO7XfpD1cTPhU1GqkJCJjNJeO0ttySE1Tg4FiB0MVciL23LIJFzpkpGT+eoCelkU2W8GGeus9fO7tXHllYlDh/442vd8zm3vjFkU6jAM/FbLQMonupEldCThxA2YNhOi4ReHx8JopqnyOk6vGwY0wM4/LjdAanoqhOmsGA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656511777; bh=+QMbxoxb4DYGVLwhtSlmVuNF5/mi2nP7xNVVPUW7aPd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=beXsB6W09bqyOUeAWWH3eYNCb9TD/lcLqRMvdCphelDFgZDTFhckx8ewQYDX/oQv/mdVQ47O8O9rN4MN08BQZTEGqhmnSyI6GTLOq/cEXCy9L6AeEZaEIXVd1BbbLep5rTSmNg7GWAMIq15YYAOYG+Rm9+VXTRQ9r60CwhSh0MT6FqtGIAP+FYmjd4O5Wv+3Vmgq99gsumoygefYaYc7jDjOmR7o9LmYTE9L6hqvJr5yHrPywONgA4s2CAswSV4agwYmbNaFLBf2eeavQy6hesvvWWYkaNxM/OJjOM6K1/Nmf9S+LblAWrvKG+35Ut2lBOojq9jsOuWHQk7WiJGPDA==
X-YMail-OSG: 9Ngv8IwVM1mBsNmGl5opxWc5lCW_Vl_3BmyXQvv7GhKt_YD2cqwKp.9YGR456l4
 Jg6CwJslX2Oh_gzdvzzfLu5tfVSpbAJH1cHsWGHYdkijvzOiX.FEHUTuxpFAhI8qcc6c276o6BOz
 TPD2fgKK0_0dOF6s3MH507wKpVmVhhzeEJDKYl3CfOEjHHv7bbSpQukl40mRHrkOSW8FPcKBXIMg
 _8gN8tEfqZUAkpNR40ufpg7R7whTaiDIkjn4LgUee44md7nCOKpzHMTkMtO2AWRV5wC7EuyPf1k5
 9NeI_lHZZXmVfw3tdOpPAMXtg_TNd1fDP3VKnEWt3k2VxCaDuKoB7aYeAptzk0qIXiYXyrLBBjEI
 XdmK1Uo.RqZCK6Q0.vGTl.nFF6l74tFBaRz22wbvWC1h7tg4by2u4nimdw25OBXdNLCidHDInODd
 3uebl3poQDn9fDQTZ1YYkojKWOsh_WxXvmOuEfeLPWKcbLkPHN_3tD9H4ZOXCLwUtLxE3dBAEArg
 vLMzbblrUc5d3vYunGdhpZzeD2fdmEbihMBcrwka3QBEql.0IPEF2CTMdT5rXq4zqjIQMWYz0B4h
 zuyNi4kHavBYBc.vQpOYKyXNb9H4t7TJcd0fvOnQaGumWXESNzh0ynhvi1pT3P29i.lY13bwjx5K
 RCPqCyezso8IuC6Vv_FkQ4r3Ek9ZGEegMdSuRKRA5TICsRlYbuoQaeRoR7D5YzSF__Bf4yL1s2EB
 dPfaQN1cSiJ0WauLYAEyWrU61mwGxumxU3C7IQ5dRAbEyPpHZMFATm8dgFjX4VlRrreGz9_GyFgA
 7U.oZfTyPf1kxWsD0t3RgNk2pV9U_qhdGdf2QS.ZBccBYyGvN.jj3GthHT8v5ihQu87Q9YVp1riV
 O_Yc048WUAucCUa8oDr0w4UNHAsfhVC1ynPFfpTC4b2B5O38mTWfR680qizLpGuyHpK0hk5ofONR
 JWFARYdkiDM33mwWcqrGhaycfUqPODWbFNRcJyB2wDW6llQG_0yEdAcJRk7Y8iZr8IqyPeVpmruN
 5PNMSxrr4p8lqjSR7VnNZclH.FyUyMR3y8GRD62o2MN6I7DMcmvHIAC0YZmfkgUZVjyVSnY8CBx0
 Dg3W6vfYuB8pGICA2PTQsg2HSQwQCHmr1HTV8U8cC3sWaEm6TL9ZQW0gE5ZfZxabb8cE_OsLPGkB
 Jrp_FiyN7zstBT2XmW0gIonx3BRwhaLrMvYLFqADmXs.vQFd4qlMaZAH4sHZXX.BaE.qVQfQ9WJC
 jSCkquwVBHSPSysr69h2BuHsoeNCbfSnp.YKE1zh7wZ5h98ljFmF6MQNG5s1H9vV13oGkBj0.jkd
 C7Tn1Kcr4lIa6O.uKZHhDKMSoMJ707clMyeqbtN0tqoKjinmQGY3Mc2gbk4lYQpHdRczCN5pNWg8
 A.uhk0ZR4PXrGfPJDJ0qJ0LTdGNkBeYVR6VCsLkv9skv_4QDMM4gr14BwA_9WjXGQmICOGumAMkg
 RifDLNBXadsXZWk1M9FG.dnL4HzQNxrpPebaw.s2XtwPOtGGqDRoUE6b_Q8t90Wz5BszOnL0BJfp
 q.L2u3izOHIVtDzOVzP6bSAI5VwPhhlgYMeTMvqYqB8sgq987CiVSmaWm53bvxMwQhIycssX3EB4
 Bvi.iDu8ZoITKy9y.LPAXX0_0PDbiBpNo9AX0noOsd06cOGNMrZHKHCfuYASIN7DXfSkazuPf115
 tM6wi6.9mP5IN1DwMAHfwq4n5PLEt2E86Gq_6py2LAPKd3REUMblfgotu4B4GfiVOF5bnBYXT3ia
 ARpX1MtsXdf40uZGRdcxTjaNaePkBx8.cgfV0V0ilKqhMYrpH7wrdX1rp8gKuFTBfe8q74W.SRUw
 yWfFesGt9gTsVWdmknrVoSxk4Qev_Qo_QGReMCJQYBySiDWpNgqMwXxmew5OGvrVz9pNSrKBzAlX
 NNKhXB8H2asfXW2BvYevxcNtPCvZlTUAqLm9olO4lfUcYqriRkvgK_lk2SLmKbRU8bAZw8v54AId
 ix9Ue7ZCKvyGVqFRbnPWNRHi2CpsFZMkFwTETucBVIs929lPzrH.Ztr.46IPcWJg9piW.XYSq3Ex
 GlRD_G058dHStiqo.KXMNna95s6kQ6zC.ZrkwM_M3l_YUkqDKtZlc31_nsBUCr5hMdf2IwnDbL_D
 XpCecJtcFmAqjmyeuDM0Iq.m7kinXuPl5AhG8dOcGWTwnkZBmull_uZD4gi4GcNddbGknJW9STxU
 ddf8B_pOEqSi57AvU_Lz_FfB7UUvwyoGJ34XldsiPqbAOfy6HfITWuLQOyAbgA5kcbyJzEIqvl7b
 NentGka7gxLfSUOSljMn0MnlS.yrMGH78hzFBlf9FxzRoM09KjdZn
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Jun 2022 14:09:37 +0000
Received: by hermes--production-gq1-56bb98dbc7-6v5v5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a9a8e8769e650464bf642aee32d0df6d;
          Wed, 29 Jun 2022 14:09:35 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is
 attached
From: Mark Millard 
In-Reply-To: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
Date: Wed, 29 Jun 2022 07:09:34 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
To: Bradley Proffit 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LY3Hr2kD2z4dLd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qOf5mAPA;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from];
	 NEURAL_HAM_SHORT(-0.97)[-0.966];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jun-29, at 02:06, Bradley Proffit  =
wrote:

> I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual =
SATA-to-USB hard drive docking station, and I've noticed a peculiar =
situation: U-Boot fails to load FreeBSD from the SD card when the =
docking station is plugged in and has two hard drives in it (presenting =
two USB storage devices to U-Boot), but still succeeds when:
>=20
> 	=E2=80=A2 the device is not attached;
> 	=E2=80=A2 the device is attached but only has one hard drive in =
it, presenting one USB storage device to U-Boot;
> 	=E2=80=A2 when the device with one hard drive in it, and another =
USB storage device, such as a flash drive, are plugged in.
> Any clue what might be causing this problem? I wonder if this might be =
an issue with voltage sag/over-voltage on the USB interface causing the =
SD card not to select, or something similar, although the docking =
station has its own power supply and so should not be drawing a =
substantial current from the pi.
>=20
> I've included what errors I collected through the serial interface.
>=20
>=20
>=20
> U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)
>=20
> DRAM:  3.9 GiB
> RPI 4 Model B (0xc03112)
> MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 3 USB Device(s) found
>        scanning usb for storage devices... 2 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> U-Boot> boot
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Scanning disk emmc2@7e340000.blk...
> ** Unrecognized filesystem type **
>=20
> ...
>=20
> run bootcmd
> switch to partitions #0, OK
> mmc0 is current device
> Couldn't find partition dhcp 0:1
> MMC Device 1 not found
> no mmc device at slot 1
> MMC Device 2 not found
> no mmc device at slot 2
>=20
> Device 0: Vendor: ASMT     Rev: 0    Prod: ASM1156-PM     =20
>             Type: Hard Disk
>             Capacity: 305245.3 MB =3D 298.0 GB (625142448 x 512)
> ... is now current device
> Couldn't find partition dhcp 0:1
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.1.33 (1246 ms)
> *** ERROR: `serverip' not set
> Cannot autoload with TFTPGET
> missing environment variable: pxeuuid
> Retrieving file: pxelinux.cfg/01-dc-a6-32-90-1f-1e
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A80121
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A8012
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A801
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A80
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A8
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0A
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C0
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/C
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/default-arm-bcm283x
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/default-arm
> *** ERROR: `serverip' not set
> Retrieving file: pxelinux.cfg/default
> *** ERROR: `serverip' not set
> Config file not found
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.1.33 (907 ms)
> *** ERROR: `serverip' not set
> Cannot autoload with TFTPGET
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.1.33 (1312 ms)
> *** ERROR: `serverip' not set
> Cannot autoload with TFTPGET
> U-Boot>=20
>=20

See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256441

The problem is not limited or specific to FreeBSD's use of
U-Boot. For example, demonstrated with Fedora 33 and some
openbsd version as well. The problem is not new.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jun 29 14:33:37 2022
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 E864E86C34D
	for ; Wed, 29 Jun 2022 14:35:05 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LY3s50srVz4gkl
	for ; Wed, 29 Jun 2022 14:35:05 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 25TEXbxr026509
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 29 Jun 2022 07:33:37 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 25TEXbOm026508;
	Wed, 29 Jun 2022 07:33:37 -0700 (PDT)
	(envelope-from warlock)
Date: Wed, 29 Jun 2022 07:33:37 -0700
From: John Kennedy 
To: Bradley Proffit 
Cc: freebsd-arm@freebsd.org
Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is
 attached
Message-ID: 
References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
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: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
X-Rspamd-Queue-Id: 4LY3s50srVz4gkl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.75 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.95)[-0.953];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Jun 29, 2022 at 02:06:14AM -0700, Bradley Proffit wrote:
> I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual 
> SATA-to-USB hard drive docking station, and I've noticed a peculiar 
> situation: U-Boot fails to load FreeBSD from the SD card when the 
> docking station is plugged in and has two hard drives in it (presenting 
> two USB storage devices to U-Boot), but still succeeds when:
> 
>  1. the device is not attached;
>  2. the device is attached but only has one hard drive in it, presenting
>     one USB storage device to U-Boot;
>  3. when the device with one hard drive in it, and another USB storage
>     device, such as a flash drive, are plugged in.

  At the risk of sharing totally irrelevant experiences, here is mine.
I just got what should be a 4B.  It very happily "just worked" USB-only
(no SDCARD) out of the box.  I've got it connected to a single USB M.2
carrier that's made me very happy.  I'm not sitting in front of it so
can't provide more useful comparisons at the moment.

  I see that reference to (e)mmc and think of your SDCARD.  If I just
had an empty carrier I tended to see OS-level media-not-ready errors,
not sure what u-boot would report that as.  If it's just an empty slot
and that's uboot's way of noticing that, great.  Red herring.  If I
was sitting in front of mine I might be able to compare.

  I'm a little worried seeing those DHCP type alerts.  That implies to
me that it is trying to network boot.  Great if that's what you want,
distracting if it isn't.  If this was my traditional BIOS, I'd be
reaching for the boot-order knobs but since mine just worked, I haven't
dug into that type of setup yet.

  Sandwiched inbetween the failed MMC stuff and the DHCP stuff is it
seeing a reference to "ASM1156-PM" Hard Disk with a realistic size.  I'd
take that to mean that it's gone and properly scanned it (so no missing
media).  As you theorized, maybe exceeding USB port-power could cause
the device to disappear soon after probing (and maybe uboot wouldn't
note that in a way we could see here).  I didn't see a probe of the 2nd
drive (but maybe being done sequentially and we haven't gotten to it
yet).  I don't know if you have the option of pulling it off the dock
and plugging it into a differently-powered USB port or if that was the
whole point of the dock.

  I could swear that I've seen some long RPI-boot-from-USB threads from
Bob P that might help you eyeball this at the uboot level.  If you can
have it booted up and enumerate everything at the uboot level then it
probably isn't a power issue, especially if you can boot it manually via
that interface, but you still want an unattended reboot.

  After probing that one drive, it looks like it just goes right onto
trying to PXE-boot off the network and fails.

  Can you tell from the output which drive it found?  (Basically size,
but maybe brand)  In particular, is it the drive with the next-stage EFI
boot that I think uboot is looking for at that point?

  If the non-boot drive powered up faster than the boot drive, uboot might
see it first whenever it was plugged in, and maybe it'd get ignored if
it didn't have the EFI partition.  Wouldn't explain why the other drive
wasn't probed, of course.


From nobody Wed Jun 29 14:35:58 2022
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 ED22086C420
	for ; Wed, 29 Jun 2022 14:36:07 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432])
	(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 4LY3tG5jrNz4gvB
	for ; Wed, 29 Jun 2022 14:36:06 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-wr1-x432.google.com with SMTP id i1so18292781wrb.11
        for ; Wed, 29 Jun 2022 07:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=bBdH5+yHaYATfND63jPF+uQoAlqVSNlXOou2pypdMbc=;
        b=OVFkBTug4O9qFgYMiM+AWx1N4yLXs68fUs0A6IVpv4lYL3A3BPOFtKBYQfJncI+rPK
         8Zz/OVhuSl2A+iEqJOhwpfwC+/YA9OcTkxOErr2pSg5GHBNpTBU3u1IM0Hg5ri6lQHeW
         Ou8Mai10l39q2I0VEsMV12YP3nnymq+ZBdg5qHozuL8qNkbjlsdCwgwXX1u2BtwfaaTU
         +RHAMHxcfdqNBdXsRnmyhF7fO9SMJnWj6fJ4sFcgJVQJvk3COOn1KPsFLnzFuerLPagE
         t7QmEU0NJrajhgMP7O4V36uEOyis8E8fKzFany9ksHMTIHi3vf69m8DFXGES0k45UBr+
         FYqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=bBdH5+yHaYATfND63jPF+uQoAlqVSNlXOou2pypdMbc=;
        b=zFUHzkjaJCKIZzlDlerFxzmijTteuWXJmcDWFUnwAy3eoNCZtUw5qDE7b9tlR/+z0z
         DiVaFW5PVq3EMIaI7nt9wNf0lgmkTMCxxg79WWEwPs6wLqoTuWG6/v8wm1zzUyf/d5A8
         up8or/+9Ikc48HdjjlKGz4TomqZ2K1vl6SA+LPhiDAYr704WCpAoUCk3BJ6gjV3SPID9
         dS8+uvg4MKy3l6k53Oz10bwNs34KgW0ITTL4WpNtzJJrjIMCCIWmSXVAWSCqhbvDYOt1
         PHCYuOc2OvMoR5OgvpxPv1a3yrRQNEmuR81HAuia6cpJ6g8x30RKkH0qa4+3n5yAiTPc
         +O2A==
X-Gm-Message-State: AJIora8HacPn6sZkT+ecnkhdfBRHWYwyLVLFa7PLKddgg5FVrIp5glsT
	xaWFmEV5fCkodH0VqsAFlVfVjOG9yZEI6Q==
X-Google-Smtp-Source: AGRyM1u0kIFaKXkDRU8QOymMQa2ASpRYmgj4hK9Aiy0uxd5hG8iIJAY+YPbu7C12zQJ6klhwXHmgPw==
X-Received: by 2002:a5d:5984:0:b0:21b:a858:3678 with SMTP id n4-20020a5d5984000000b0021ba8583678mr3488672wri.293.1656513360487;
        Wed, 29 Jun 2022 07:36:00 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-191-244.46.114.pool.telefonica.de. [46.114.191.244])
        by smtp.googlemail.com with ESMTPSA id w17-20020adf8bd1000000b0021a3c960214sm17845781wra.6.2022.06.29.07.35.59
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 29 Jun 2022 07:36:00 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is
 attached
Date: Wed, 29 Jun 2022 16:35:58 +0200
References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
 
To: Mark Millard ,
 bproffit@amaranth.digital,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LY3tG5jrNz4gvB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=OVFkBTug;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[googlemail.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[googlemail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[yahoo.com,amaranth.digital,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[googlemail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	 RECEIVED_SPAMHAUS_PBL(0.00)[46.114.191.244:received];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-29, at 02:06, Bradley Proffit  =
wrote:

> I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual =
SATA-to-USB hard drive docking station, and I've noticed a peculiar =
situation: U-Boot fails to load FreeBSD from the SD card when the =
docking station is plugged in and has two hard drives in it (presenting =
two USB storage devices to U-Boot), but still succeeds when:  =
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6...



> Am 29.06.2022 um 16:09 schrieb Mark Millard :
>=20
>=20
> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256441
>=20
> The problem is not limited or specific to FreeBSD's use of
> U-Boot. For example, demonstrated with Fedora 33 and some
> openbsd version as well. The problem is not new.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com


didn`t we workaround a similar issue ? :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983#c59

K.



From nobody Wed Jun 29 16:29:42 2022
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 9F0D087EE65
	for ; Wed, 29 Jun 2022 16:29:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.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 4LY6PZ4C09z3FNq
	for ; Wed, 29 Jun 2022 16:29:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656520186; bh=A786+SLmvvKIt2u5Xp7kBiCYwKYeyCfoA49jz4Sf7Qs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QVQniAk9M8BpCGRSabjZ3zIhaLONuE6zb7Rv4iBA9QYRL3KjCZ6FhjXprDyptHV3ghZWQ8yzpyjbJb9BXkURlI5V2Ekry9b0bxu7piiOSzERgpwfNr0kAl9NGRW/UfJazTqi7qHqqswCga52zDtf7TSTLaXhgmhkrwesxUcifP1ls9qhMW4pRvqLbmY9Q69ZAE1EOTyXuUef/zBvU/WeMIVL3g3dHqgzW8EY09nQ6IBuZS6FANQBcHWHnPvcCZPNpwB6YAqRmdJHImeLwK41jQ+R2wgKvCRz9FeaETMTDs2bLNZ+Tj4sIdldIRw/edzHMvLb4X+JvPlPe6q55TzOEA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656520186; bh=LYGr2Q2WW5SEFpZYSBMCeDH/hWnf3vqaXS+dACAQg+U=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HkQxa3/PStBl821F13Fo5DlhpXzPj2am/iAbBvLaaAtVtU5BhhFfCeb15D+GLBCMUaWptiE1WLY4cSPn48TNkgT2btPru7f0nRl1vypFPnzs64hdublTv/SqhO8rGeS//GfVXfv0B+3w6fPu+WhFsTqNo6JLOA577vCO4eVCcIsCw+p8c7bHVoo27Z/GbTA1u3twKnXo+JAFVztrUqNCFnxHyvC8GjdBlNuI1vRE/hQz+SGJhz219QAK4GmDPbGdI9mVtM8PZkV+o7HEoAXokrikeemwWhl7guumYMJXX5zk+Lyesy7MKGafI8+ugu4FbGR9znODD+SEqQyXLaPUiQ==
X-YMail-OSG: HtiAx_EVM1lQX2H7ZBdoB5nDE81axzpULu6M_KwmwgVoa33NpsPkqothgp21rVY
 Y2urW7.Mpcg.PhcIsIPaRhhREHNdKLWAMgx25SLjgGgHnlCRIpJTmWFVlJEARYkGDiifCR_kG_wf
 u7jUcfxQjVXnF.VgB0ygq6GqxeC_743SH1nEteDlaCa04UJgdPg3_x.r1aKmYj7N543g6klOu69g
 GI4LROtVad6MV5GCSiEmT.RxY2_UY8q7.8_T9SZXsQVn0H2A5mSs.N_L.tTWQ08SYy.zot9OX9rp
 ti78wpiu01iz9RUcGA.sJfeejh4Vf6JrGOsMYZ19CzSQzzBcWnFjmvZyOnzWjGoqVbKSD1M53fOE
 fsYg0Wbum2KcCzc6501jV.SgVahA1uknW1fNWhhzq4mxetQBBXv3UmrWT6tGK4Jqgmiy6uKcfV_R
 VJun_E2yXBs1tW3svLxo.Q54n1wBIpJA7p9pIIv0cm4YCiLoNMZrl6imxO.hx2trodGo.PhWsiRy
 cEBYiCXtdXXybcuI6lj9UImBbkJExfCbji4G1RAlB8fT5mCUYUmC8yfdPQMIXbplH9NFaqKt3fqo
 K5h3vskwKuCca6Sj7GRM8BGf4wTVPGhPOJEfgjODWYOc4yYuNl_q2ogkquWyAO1e_OawLT2_MTZy
 CODNVd2GMIhHpoeegrWnmMehuCDt5WXRvrK5JUYyMVo0DFZYRWJ_Dqih3rc8ug8wKbBF3YrGLu24
 3vLe8_dEk70IGy8QrWjFE.7lJ37XOfzAFHME8HpkYNeT_Yev211HpUo2Ahf8HcgwtrrrNPqrXKga
 oh42HMa7mG_UFDZf5gxE86B3UYjlOotu7Q5qD3HckwzVjgj_br3_p7JfodNSsgIFNinFQQ7cN6FO
 08ofV_sEFqBLtyfv8EyHCfOmPCtD6EJM.zYOqWHECTjxI0rvMnRCeklwp4rANC1UlE1Lvb6E13_C
 0TQCGztGBWlr4TFAftIR4C0L7A6RIWMFWlA4iCo5Ms0J_DR067a7jTvwhbDbHnxHys07lVIxvFiC
 4IEusERw9t8PZ.eyXOyRovNz5GSHOg1QcP3LJy47QrqPYfHtKfEmrwdnQsALXI9PtkZ.tp8sXEQW
 JYv2nfW.8BnbstTLq2btsTMDQ2bLvjN0x0PHtfvVfPcxgo39dSt.Fi591EGfPAqGBB_R2ef7mmbT
 QXThxKN81nWfz5ZHtYdyo1GoHmGZU2kOnsyPWpWUXAQoV1Jlmr3fT1QA9UGvmkKRxJY3PwQHrnIN
 SDmDRKHXATfFKkeUSsgtYhZQTdHcKvJWXGFgvKHjyTD1kQgKodClmA_U08eh0HjshHNtCFa14Q7p
 fKcSypxQCv5X33OhcQie2Fxkg8T0TVDI0GSmdwDs9nlPZ3NjTm5Qxayg9ZIDJoCUwG9Qq7K4CQu1
 ER5XbEr_Yrqp9d3no_YbUr.6ijFahcFPsjBB1eQDuBe8n_kiYXIumJd7CVbPGDA8A7IyMCwolSGR
 NoWw8fa1TZgkarOS.D1VW9AlbO7qgBF3irevrWtwm9umLMnJf1gPp3APJJceFUKiPinLAZTKXpjG
 83faeaIv1e0iHOLxPXLFG5oi2lvMVrj21JpCZfq6fb0dNuJGyrYzFhotK.4LE42Jp1yzGhF5nyly
 XUY72W2Rzp4DXJHXW5S_eCk_pPpv5JMv9P2ZPDjrwF7Sa8G60yfx5qJHuvRNgVVjDyoTw0.oqtAK
 dMzrkf09RAnBS4NnN6yngFlZTAZkBwmNq94Z2OoQdjQ1LfBjzpS2fPLy0gRuilhbPMyDS7dlPNyb
 6vjEcRO5IiV.WUeYgsKTW4aCej0PPDlm5r8BIFSaJtHMo8Bo3uvswZoU.9REbTJtqXoOAlPoCFDF
 9EnuhtnDJX7fdVpXXjrgjy.43wxHCsT0Nx1qN2rXwbxFDvgUhcwSuEz_yw78yTcCeapn7MvFyx3T
 YxX.jHO6Ij.felRYeklTFlmY_jRrryB9po_WHae1Y1zethk2KWcqjBhlsLIDQL6EntqyujFfzpwJ
 ixL5xm47WQiC8vhY_S1Re88_jeYzJli7S6lSbNGjVIuaHjjRcMmaKekyA6Iwd_.PZUjlqv.Bx4X5
 usynbvbygV3yLtZnPVog1yOtx9GnRUlU3b_XaOGAz5k_T.UITBdmHrDRvc2VAFC5EWAVPqm0yBl4
 KWxXRUw6RW2qUG7M7E1c7zbgppNmIFvqpnsZHJnCXEEmiQJ_VCtWH9A1v3Mo7g4nGw9JJBw.iteT
 pd2g7lImtDV4hFhJR_A6DQ57GBKH4W650iuRo0Xbjgv5YSPwPeyQOtxAI933MRLs3KqXjMIYjwlA
 e_EeN8g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Jun 2022 16:29:46 +0000
Received: by hermes--production-ne1-7864dcfd54-lx66j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a06d52c7c1ca2e997bf7b8f5b248398e;
          Wed, 29 Jun 2022 16:29:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is
 attached
From: Mark Millard 
In-Reply-To: 
Date: Wed, 29 Jun 2022 09:29:42 -0700
Cc: Bradley Proffit ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <17F5F696-A1D2-4952-9163-BF7D185B8A27@yahoo.com>
References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
 
 
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LY6PZ4C09z3FNq
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=QVQniAk9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.68 / 15.00];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FREEMAIL_TO(0.00)[googlemail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.82)[0.815];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-29, at 07:35, Klaus K=C3=BCchemann =
 wrote:

> On 2022-Jun-29, at 02:06, Bradley Proffit  =
wrote:
>=20
>> I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual =
SATA-to-USB hard drive docking station, and I've noticed a peculiar =
situation: U-Boot fails to load FreeBSD from the SD card when the =
docking station is plugged in and has two hard drives in it (presenting =
two USB storage devices to U-Boot), but still succeeds when:  =
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6...
>=20
>=20
>=20
>> Am 29.06.2022 um 16:09 schrieb Mark Millard :
>>=20
>>=20
>> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256441
>>=20
>> The problem is not limited or specific to FreeBSD's use of
>> U-Boot. For example, demonstrated with Fedora 33 and some
>> openbsd version as well. The problem is not new.
>>=20
>> . . .
>=20
>=20
> didn`t we workaround a similar issue ? :
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983#c59

I forgot to look up and reference:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983

as well. I should have listed both, for sure.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jun 29 16:47:13 2022
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 5884D86C53C
	for ; Wed, 29 Jun 2022 16:47:34 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2124.outbound.protection.outlook.com [40.107.215.124])
	(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 4LY6nw0XrVz3h4d;
	Wed, 29 Jun 2022 16:47:31 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=arcQ7Z5nUAClCnhXSEz/ja0IbV3+IClZxEKFVBJ6a7oOoA0skgkCISmq9M0L86w7as3wQ36DUzALuIzZzeH4Tw4fjzwrWgvIcbCBPznZLrFkq8NbFiN4a+dd1viQ21G5SwG+oLTAJqQCKRVFW4K3B7aH8LxlOc3ED1yaP1cOMv6SGNZFLqowtKvdFsgwU4B7nyqPRqEWKvI88Tbudk1zWO6KeOAenpiOvx2WV8SphJvwS9f49Jddy4Ck1yV+UCI3SPOTf/XTEcC8ROgzdxcgeu90LvvCK2P6MFXf3X817ITnOe20TQXRDaouA1l2kJy6kywohf/VPRy4DFb3QIk9jw==
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=tUmvwTEzWL69eruvXL2eyc4BhW9iMIAJ/Skf0y2Qy/E=;
 b=cBNoIOiSHwryXlr2WNpHGviDMktLdwo7ikx6n/LlIVNF/5snaoF0A8uqV9PHpx6MQj1zlDrlBLRh3saDW1mAB1mpdUmuS87yzTvX7wGdfDuo81OWh/Cpf04dc9A6oeIIOYCjWqdN0qt7FkTL107H/PTGvzbbIRdjGOioG3bC8WEXZeimEaW+HyJRiPlYBfsEqd3e/hsF/L8UoTK5szgJfwsD8/K0AEcMZkeWrIxmD8dbMZEoks6kYWKIvu9Yd4kOYdIT7Qs4gKJyKFtVTWIWG+JDaLylQUJ03BBi49FQlyjMll7Sx7X3mEhebQs7tj+k8XUMl4UlUt4r48U50ku8AA==
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=tUmvwTEzWL69eruvXL2eyc4BhW9iMIAJ/Skf0y2Qy/E=;
 b=A4L3GJNNIRjpE7izBJBG+Be5Tn17DP6sqYCW+O35LCHJYcmy7G4AFdGG65N5PZez3Cn1VfMav0v8D6MokNCZN1a8BNHVVElNdGpR/ygkKkSmrydQXK8A0L2oxalP0PWrBC0DB56VeTLS8imCLYkVQJ1pPzEOgMLDWoGy/aS4p0c=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by SG2P153MB0378.APCP153.PROD.OUTLOOK.COM (2603:1096:0:8::7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5417.6; Wed, 29 Jun 2022 16:47:13 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::793a:342:7dbf:9919]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::793a:342:7dbf:9919%4]) with mapi id 15.20.5417.006; Wed, 29 Jun 2022
 16:47:13 +0000
From: Souradeep Chakrabarti 
To: Andrew Turner , "freebsd-arm@FreeBSD.org"
	
CC: Wei Hu 
Subject: Re: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call
Thread-Topic: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call
Thread-Index: AdiKA2Q7WTo8sgKeSKGdouN0obA7iwAP6A+AABvz3ZYASRvJhw==
Date: Wed, 29 Jun 2022 16:47:13 +0000
Message-ID:
 
References:
 
 
 
In-Reply-To:
 
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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-29T16:47:12.822Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8debb211-2f29-4100-57ca-08da59ef0480
x-ms-traffictypediagnostic: SG2P153MB0378:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 k1wdnakJGlZQ1FnYzV9B6RMDiw9l2p1gNMwrQ5SV+vvwME9lmjIzneHVseiKQ+9oePjGwPfM6esDX5vqX7ImKGSPms+yO0jC3EMk2mDxZoXSXD7FaupVWRhEA1ebaeVMK2fMYBFkdy/T0XSznkKuiZz+RGFzkVmYTTMD72HyTslBEgAXFiMaDZP+plAhLgJ6s/CsBhg9eTwPVg96zSVjaw2/nckgL/3vM9y0K1u+/MuuUBGlIfU+HFc5ivYwTRoQ21ecqBryqUChQxFUh51UgEu8TJw/2z5JsuIOSFbLPoR8KdfUd1actBKduS13kMBsZ8f0BnAsfKOkGWBSizIzhNaPQDNBt3i+Z8jtoFVA10p0egd9vaxhilmjxT0Lys2U47LsP9bA9CG1nFKD7h/wDIxHO2uiBl0Lx7O1NhecIFKIkwjSC5yypB4z7POpE5jdifeediRgcvuGevHMao1tr2m7bMcCff+4qCQUduTBzkvllMKigGT6KoNXXyQQoM4/y5CpuPu2XKKoTXHb/8yj9Pg3ol5tmRIF8yFcEGm5JR0dN45JER/KZyxhr4UoLkNaRMqvAFOU54Kf0ErssCkjJtLw52Qlzr6SLYiDGDln2hhDt3tq30/+Gd+lewn1VqyExcY2SxQzrewTd43sG4l39GgKiQsjHLfsXh83BbFVdli5wUarhEWvg3vrgavz/CpntjZNoxpNWklJe4eiWEqUtXEwtrsb5vJKFBaK1AhfT9sU6zKoxKCVEi6vp1cFT6TdqmLWZj/t/tXMb+uYU20SVtNt8y3BlYI2YOZAjgsT1gRvrfn4XjCh7cyD7yVCCPDYsCboK1RPJw/BH1h73IExgA==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(346002)(396003)(39860400002)(136003)(376002)(451199009)(91956017)(10290500003)(478600001)(316002)(8676002)(450100002)(38100700002)(26005)(86362001)(66556008)(33656002)(71200400001)(64756008)(76116006)(186003)(66446008)(66946007)(107886003)(66476007)(6506007)(41300700001)(110136005)(7696005)(55016003)(4326008)(9686003)(5660300002)(8936002)(2906002)(52536014)(122000001)(82960400001)(8990500004)(38070700005)(82950400001)(53546011);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?LQxGi27D7sJyRuZUNpsLFTJXDtR1ooXV4RMAWBVZMhyvsLQ/LDDxpujqZi4n?=
 =?us-ascii?Q?KFEVvIIjbJ+VJNdBIz4R2j/YOiFGGP9hNDpamRaQcfFL2PL4ofLoyR+tsGXI?=
 =?us-ascii?Q?huNNMfsmnwgUuZioLFuzjbvpKpOdg26nlxce4hvit3SYCkftKl4W7O2Ma/hx?=
 =?us-ascii?Q?JHW78xjWQooEFqGCFZSBWxDAzF360dmERVCBlRy6SxMwmY937QbtX3KvvHDU?=
 =?us-ascii?Q?AJNaDpJ4xVDLW1vI3hE88Vz1vg0IOWjzZZjdxFbAzfb/L9aYRTsi/wrIqehf?=
 =?us-ascii?Q?jHjFQdcL5KFIWRcbsc7trANS6NvGrpbPSQdTdJZYeghIy33NLbeXHPMrKOFj?=
 =?us-ascii?Q?UjnnOefFKgpeBBbeUlR4cj/3tMDNBTLPh2KBHIs8w+jHkDcpx10zmREgyJnd?=
 =?us-ascii?Q?Z9cHDJ8P3Z2XIFIaRz3ABH+retZJdFY2sDyALREy23fcBF2rdvroWaVYh1pw?=
 =?us-ascii?Q?FICNa1uj8/mHiMq5xJ61PZHDa2KCAw7TN2yyBQZkDcRwDVmky4AO7MQ3XI66?=
 =?us-ascii?Q?1yb4rOhNu47rv7N3otfwbxYi+zA1EMbrEL+XaEGZjim63tWfndJqjnU7A0+9?=
 =?us-ascii?Q?uBDwLmwA3EwHH8riKHIeOFC9wZQx9+A01cCN5JK9cn9mAxyjjPZguFvXpFTS?=
 =?us-ascii?Q?107Efj674Z68q78NUHiWxVkwpVtVIt561Yigxnzsk7GoQFY1FWZMt4MOmUqo?=
 =?us-ascii?Q?uqhbsnfx/9bGv69yCqkH5RJLaXpagUHezNxYliWG3F8nVr1OAmz/I9zmmeZO?=
 =?us-ascii?Q?fsyjuKIb1EkWG72faAV5CIqQS/IxdnimcxkkqxXbAtkdexb60TEpPEdSRiAJ?=
 =?us-ascii?Q?2B7kbAvJeBSae6QCO7e6+IURzTV00GljwbSsHp1FhfDfLcXQKkMFvI/Npiw8?=
 =?us-ascii?Q?YgePrnhCthCLiPPVOKcAgGpMdjoVrYiYBS9NNTbsJhAxuT8SztAqKZ/J0Z1p?=
 =?us-ascii?Q?uwHS9xY99nllZ+PlQCvvvaVicslWZSuvBI8fttTW259iaRYESpy+JeNNoNkb?=
 =?us-ascii?Q?Qai5hv8JehR+DNRo8sMw37z7NBxDX9xvNEf8aTez6FuIfCZcjaD8EjyUYmsC?=
 =?us-ascii?Q?YEq9u8k9BSti275mOhbbJyoARUOWHsm9pz0xyXOuTLDESrkbvrN132ZFOKPR?=
 =?us-ascii?Q?+F8ITqA7FdKJE2J27WGyiNxhAFE3d5Mvb4WxzrIXCblk81DfpShLyvq0Aevc?=
 =?us-ascii?Q?bjUY8wRsPym8FHDx3mGbVEsdhhvLliL3K4IkBNRV23Qd5BHNS9ENfkVbJe6Z?=
 =?us-ascii?Q?ajjMfRhXjcZ38+/msHpYtwJU68A12pkFibzARLGSgIAofbmBgEVOfZNa0SEa?=
 =?us-ascii?Q?pT2UVvuv2PpprrKtt1c4erqaNgPvNKVxrXoKIg4lJ5l/VoVcZBfUmg2Hrtf4?=
 =?us-ascii?Q?YItA0I35Bgp1NFvcT/2q+GX+GY8qyeB+VkdmXEIdwG1q3TYKDYTNhVdz8HoI?=
 =?us-ascii?Q?AfJ/u9ff5yr6RjhfSDwepiCSUFT6WtWPco0eydene+dLNmJ5cBFSuEK1YiN5?=
 =?us-ascii?Q?ERUHlUqmaBCwG7pt/OzgYBB2fEjLcoVu90Ke?=
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 8debb211-2f29-4100-57ca-08da59ef0480
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2022 16:47:13.3766
 (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: h+M/O5Q0iDQgu7C05bvEwjHRbPHL/Mw+09HTEY6lf7mS8JPba5M3QcrLQyh7D2AR6z9Sgel8sEV2TIOebJdxmmP7u7QfeLbz3yhqi7YlnME=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2P153MB0378
X-Rspamd-Queue-Id: 4LY6nw0XrVz3h4d
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=A4L3GJNN;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.215.124 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-10.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.215.124:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.215.124:from]
X-ThisMailContainsUnwantedMimeParts: N


Hi Andrew,

It will be really helpful if arm smccc hvc 1.2 version is implemented in Fr=
eeBSD. It is required for Hyper-V HvCallGetVpRegisters hypercall. Please le=
t me know if there is any plan to implement smccc 1.2 version anytime soon =
or not.

Thanks & Regards,
 Souradeep

________________________________________
From: Souradeep Chakrabarti 
Sent: Tuesday, June 28, 2022 11:36 AM
To: Andrew Turner
Cc: freebsd-arm@FreeBSD.org; Wei Hu
Subject: Re: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call


Hi Andrew,

Thanks for your response. While looking into the code, it looked to me we h=
ave smccc version till 1.1 implemented.
But for hyper-v hypercall implementation we need to read registers beyond X=
0 to X3, which is implemented in 1.2 version.

Is there any plan on version 1.2 implementation ?

Thanks & Regards,
 Souradeep



From: Andrew Turner 
Sent: Monday, June 27, 2022 9:59 PM
To: Souradeep Chakrabarti 
Cc: freebsd-arm@FreeBSD.org ; Wei Hu 
Subject: [EXTERNAL] Re: SMCCC v1.1 compliant HVC call



On 27 Jun 2022, at 09:57, Souradeep Chakrabarti  wrote:

Hi Andrew,

In Linux we have SMCCC v1.1 compliant HVC call arm_smccc_1_1_hvc(), which i=
s used for SMCCC and HVC call convention.
In FreeBSD do we have something similar?

I can arm_smccc_smc() in sys/dev/psci/smccc.h, but could not find the imple=
mentation details of it. If I need to use SMCCC compliant
HVC call, what API should I use?

Thanks & Regards,
Souradeep

You can use arm_smccc_hvc to hard code the type. Both the hvc and smc versi=
ons are implemented in sys/dev/psci/smccc_arm64.S. They depend on the arm64=
 ABI to put the arguments into the correct registers to be passed into the =
hypervisor.

If your code is running after the psci device has attached you can use psci=
_callfn. It is a function pointer to either of the arm_smccc_* functions de=
pending on what is in ACPI/FDT.

Andrew

From nobody Wed Jun 29 16:53:46 2022
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 C5E0A86E84F
	for ; Wed, 29 Jun 2022 17:00:45 +0000 (UTC)
	(envelope-from andrew@FreeBSD.org)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LY7585PRfz3rYR
	for ; Wed, 29 Jun 2022 17:00:44 +0000 (UTC)
	(envelope-from andrew@FreeBSD.org)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id 7D4B44E663;
	Wed, 29 Jun 2022 16:53:47 +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 \(3696.80.82.1.1\))
Subject: Re: [EXTERNAL] SMCCC v1.1 compliant HVC call
From: Andrew Turner 
In-Reply-To: 
Date: Wed, 29 Jun 2022 17:53:46 +0100
Cc: "freebsd-arm@FreeBSD.org" ,
 Wei Hu 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
To: Souradeep Chakrabarti 
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Rspamd-Queue-Id: 4LY7585PRfz3rYR
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 139.59.165.16 is neither permitted nor denied by domain of andrew@FreeBSD.org) smtp.mailfrom=andrew@FreeBSD.org
X-Spamd-Result: default: False [1.61 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 FREEFALL_USER(0.00)[andrew];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 GREYLIST(0.00)[pass,body];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 VIOLATED_DIRECT_SPF(3.50)[];
	 NEURAL_HAM_SHORT(-0.42)[-0.422];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.968];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 28 Jun 2022, at 07:06, Souradeep Chakrabarti =
 wrote:
>=20
>=20
> Hi Andrew,
>=20
> Thanks for your response. While looking into the code, it looked to me =
we have smccc version till 1.1 implemented.
> But for hyper-v hypercall implementation we need to read registers =
beyond X0 to X3, which is implemented in 1.2 version.
>=20
> Is there any plan on version 1.2 implementation ?
>=20

I don=E2=80=99t know of any plans to implement it.

Andrew


From nobody Thu Jun 30 05:41:03 2022
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 539B986D3BA
	for ; Thu, 30 Jun 2022 05:41:11 +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 4LYRyZ2vWvz3DMr
	for ; Thu, 30 Jun 2022 05:41:10 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 25U5f3IE034630
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 29 Jun 2022 22:41:03 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 25U5f3Te034629;
	Wed, 29 Jun 2022 22:41:03 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 29 Jun 2022 22:41:03 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Curious serial console behavior on armv7 running -current
Message-ID: <20220630054103.GA34603@www.zefox.net>
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-Rspamd-Queue-Id: 4LYRyZ2vWvz3DMr
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.94 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_LONG(-0.84)[-0.840];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

While connecting a serial console session between two Raspberry Pi2
machines some strange output emerged.

The connection was via ssh to a Pi2 running stable/12 connected 
via cu through a usb serial adapter to a Pi2 running -current. 
When the connection became complete the screen filled with pages of

...
Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:Password:

Eventually I typed control-c and got

Jun 29 22:28:46 www login[945]: in prompt_tty(): caught signal 2
Jun 29 22:28:46 www login[945]: pam_authenticate(): Conversation failure
Login incorrect

Eventually the normal login prompt returned.

Not sure what to make of it, but it sure looked odd....
I think the flood of password prompts came from the -current machine.

Thanks for reading,

bob prohaska


From nobody Thu Jun 30 13:34:48 2022
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 038648B261D
	for ; Thu, 30 Jun 2022 13:34:59 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2129.outbound.protection.outlook.com [40.107.255.129])
	(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 4LYfTG0M1yz4m1B;
	Thu, 30 Jun 2022 13:34:58 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=HeQ0SekBNpNy8aIpU8YHlBJ2EwfHDhDgRiVvq7gQVulFPsEuq5HFBnvMUo+xU5WRcO0YnWqGHNpOdsDB62PQCdUUw5Hakw+hGqbu+s6xhM1tXg0BNi8XZlh88cjOgxVnzSLVH0gZNY3R43i/CVnWbiewoDCe1mOIdPXOVBQChYpkNwXy3dliVGrBxQJHEay5SUHoWOhQM1R5YN1Py2pP/Cs7L3jLE2R18aeQ81v2vIunfIagWfqf75osTgxJWT5Nse3ZlLMdJFzv2SisD2hoSSQ7A4KHi+VH5iVXy0SfUXnIWRhDinLOpjMVjMk9bRmHkGxhMFe9kAjLg3qX+LJ/Xw==
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=cI67AQPCkc07yTvJDZtZ+DlT5Lz92iaNATaNpf0bOZA=;
 b=gRsQulQAiTXS42P/7bQkmoA7jjjgVBdmh8+vcuMBmwvvrhlF9VvEHdEzeUdKsVZdDQODKz4UlBFkHOnEcxG2i1/1v+4+Is4vMhN1/By4er9NuL+l3BDbEb353bI0eHXrnRcbv65FuyBvMxgfV1hjzHyQqd2MQE2A1GEgUjCBYwU30HU3l0CpsHhjGcn/GNL+n6vkXvmWhIcI5CnjpzXsamcKxDwnKEh6tal64CtlMi6++m/QFkFC3/LZcAXduP4gkbnnHgu2LXS+uETr3hcug1lwll7l6VGUIVD0xxIUa8xto7tIu5NJiFl/nAAlAJHnCx+AJRqmeLZ9LGV6vWFt9Q==
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=cI67AQPCkc07yTvJDZtZ+DlT5Lz92iaNATaNpf0bOZA=;
 b=EzXAi2ZwbXd592H6fmm774t3fREEphvONELpi0tazCx6OfeUd2e0PtjlUh6N/q/LY4D+XzLfzzmj8IYik0l5NBm8a/y7YKOiZ9UstfeCsJ/zSGKSO2VvEb5WKwER5qUydxUk2bo/l3F7kUppSpkgF1Jzr7MNFCIDup9ZnpGKbDY=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PSBP153MB0374.APCP153.PROD.OUTLOOK.COM (2603:1096:301:1::7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5417.6; Thu, 30 Jun 2022 13:34:48 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::793a:342:7dbf:9919]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::793a:342:7dbf:9919%4]) with mapi id 15.20.5417.008; Thu, 30 Jun 2022
 13:34:48 +0000
From: Souradeep Chakrabarti 
To: Andrew Turner , "freebsd-arm@FreeBSD.org"
	
CC: Wei Hu 
Subject: hv_vmbus.ko loading in arm64
Thread-Topic: hv_vmbus.ko loading in arm64
Thread-Index: AQHYjIWwhn1ESTFwik6l1QWNZo8SWg==
Date: Thu, 30 Jun 2022 13:34:48 +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_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-30T13:34:47.643Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 057226c7-48ec-43f8-fbe5-08da5a9d4d99
x-ms-traffictypediagnostic: PSBP153MB0374:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 Hma4sLLKLD66M2mc5kUzQvwShAeT2YY0S95vtaeybBhbObNGDByb5k6BDliEgtC2i42tyQAMxHYCx6pkag5M4hz2PjfZU4uY38V2OMYSuLyTdd9Q/gNYxOz0Hv4Qn5Lpqfu4AjvHKzn6kr7Xo5fxom6rD1YEVrpZqgbYLu6AbpH+27wcwXoH2jd5aAj2qeksrToCLHCvmsuWWjNRRgcF6t96nZWIwHBiBzga7BEMyjiKL9YpQVrFK19XzEwToo3DCea7uzI10goyNAzzY3E53U+M8pNfLYPM8yRJ5ByLx6hzCI4UwV/ZOq8f0wI7AM/aetFSKxLbymqIq+vPQPAeDp+h5Arepv4thSz5Qud5KV3TypfObzmgePhnX2TooM+/nXj9EzMuxd5I+8MmRB8gL2DoiU5obgN5/0ct2GCPGNyqZ0ezquxAneLXmQR+HG6d4X+USYlGmH9VGBt79ir1yVtE4O6HhftTdDisACnOjXOlp02JXhWVygJnaLv21iU0q743E0F7xhnnJYr3BR5FicNfolik5Lyu44r7XFkSIkP2GulY5Vyj6iIKCH69I87RADPGZJ125SgP3C23Yf7GjeiOMHN6sen6PtV+YGV3Bd4ZXpEi6gQUBXHakPna4MZ8XEihvvWCiSU6s241sNtqpOtsjV+MSWveySmCioErbAphXTYw320pIK2WDIYCnBY55A71llrWysn7LjbcFEN11ARnXOZQvmb5LLBYrmgQ+DRr5wRH5CoADOyqWnXvw6jX8q0pjYQMyh/pbMg/qRh/2T3cFfK0XNqX8psB6oOxBDz6uEus7qHqtsDkzoQZ1ADBQZNpJKohvRQUdOJSpekVHsdFyGeozOA29P3hz0+HZWA=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(376002)(39860400002)(366004)(136003)(396003)(346002)(451199009)(478600001)(71200400001)(64756008)(66556008)(186003)(4326008)(8990500004)(55016003)(86362001)(66446008)(33656002)(66946007)(41300700001)(558084003)(8936002)(316002)(6506007)(38070700005)(38100700002)(2906002)(10290500003)(110136005)(107886003)(7696005)(9686003)(82950400001)(122000001)(52536014)(450100002)(91956017)(82960400001)(66476007)(8676002)(76116006)(26005)(5660300002);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?8C9lvEmclVOI/R7klNe0EEHfHL0rxwqKOMzme7grGYJy+R5qYlPTBSJG0z?=
 =?iso-8859-1?Q?qlxA7vU5TifFZ43IgGuAFPMmdMUOCttXi6hrvkGxWFX8VE89MaFnJ/jO9n?=
 =?iso-8859-1?Q?B5kfyidm723I7XLOMm3sLMEHfimvGT7CgsHK3WPjdEBt5ZZvTJnFOZnSrp?=
 =?iso-8859-1?Q?4qsPycRkgpNsOWBZlJ+qIZAJZQzCXv/3Dzfxb0iDLjxtV2Dtg/pArfYZ0Y?=
 =?iso-8859-1?Q?WVdI8VuoJoZgfWtvuHL9np6Lf9gHty1YM9QAyRwTXpPPlFKsfCUHN986Ku?=
 =?iso-8859-1?Q?d3FX6Y/Th3lIv4ztCR5vjFNbRUNGpeVbvr5Vx4KJ18KEAUReehNqd5kPnz?=
 =?iso-8859-1?Q?b6dXgc4KHzULnQpOi8pP7famHAr8l99b5P8HQfBRHVbdNiXabI2g76N2zz?=
 =?iso-8859-1?Q?5I8LLCr4DspPSfUKZOaBJQL4FicWiMEOLl6QuW1CRm2UiisvdXiKF0fxwT?=
 =?iso-8859-1?Q?TfHruvdoyDI6CPtKmXbNElnIQKpeh5SP02rGjacspOLc8ZAb1U/h0FZPYG?=
 =?iso-8859-1?Q?l9aKp3LF4mlrF5kobWqvUoLviBD1jFBeIZnveaejn5m8UwbCHOKYpQ8vRu?=
 =?iso-8859-1?Q?n3NJ8+RCS6o04PJUU04KOlX5jwObs2rDzqvCtXXh9kqMoQQqI7zTMYvOqk?=
 =?iso-8859-1?Q?SmfaV+hQx1zqzXyRAwyNZWIr4Q1p5RvqmZvEQVEiont4i4Yj4ek9umiqhQ?=
 =?iso-8859-1?Q?GuDlJV0sGNVQAvGL9gdgbJI7EB0V1PTQVe8LD/q+kSdBn3uhZam0LV3JMd?=
 =?iso-8859-1?Q?R40xUutmzSNz1LqwP7z2vzcO41eRyn9vcK386b21RMQLC7QMV7R47srRy0?=
 =?iso-8859-1?Q?H/yA7GR6pWhWMJ3CWKprZCT4wTt56SHx0zWJfqO+rJhYLAV867dGc/Bgqh?=
 =?iso-8859-1?Q?XLccW9wFQjmqn9otnY02O1e33Gze+tXIVJ/CHeiyGbExvYOCYXXip4iAh9?=
 =?iso-8859-1?Q?gaHP4DvyTga6LX/EIC5Gl/r4R3y5I+ZgsJWbnZE8K0t6EwyQOIrcIwiZ//?=
 =?iso-8859-1?Q?yYtqqOxNVl9cpFumLEWdBMbBJJKucTw08YLX6evNiNnadYh0WrA3cWLv2G?=
 =?iso-8859-1?Q?DD8cXqC1jANEGXoToe172gWq5GzsOeUibIkTCnGfF/Nh1oK3frby8RZm4q?=
 =?iso-8859-1?Q?1vtakrKXEcFEmqRnCpQ1nDjZdQiwepBC427pnlPHq3fmYlGh2zxbbTi2ba?=
 =?iso-8859-1?Q?oWqcZallxvv5Ocjf/CTpvMQKT/2Z5thEfbWtbP/i0XtyockqvRzf0Qwwl8?=
 =?iso-8859-1?Q?aMCcqbDyglT2snRPleZDPp1fexcHzvPav8m4rV2g7RtEMG/hloFOC7emT1?=
 =?iso-8859-1?Q?TSxFi3uYVAy3cvPRmK912ZBNkBMi1zdGEQe9s1Ny2HIGV4nd7l64/qifqk?=
 =?iso-8859-1?Q?fJADa7odjl5bXtGPL1b3pfCqUV0+HWpmp5PkW03JpaR7ycgd9LuBi9qdxd?=
 =?iso-8859-1?Q?2YEdtE2tVttsVkIYxDGdDur68bohhu5nx+UhTdAXQfTW7g1rWgKWX02DEJ?=
 =?iso-8859-1?Q?RszfQxoVFAqreTYeUACvx7PXfqHXFsGF7TREn7XTU8jK8+64t/P9nBzYxZ?=
 =?iso-8859-1?Q?76nqHSahN5CDuQl9AS/MNjoN8ePJ?=
Content-Type: text/plain; charset="iso-8859-1"
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 057226c7-48ec-43f8-fbe5-08da5a9d4d99
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2022 13:34:48.4023
 (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: 99queKyniwwm523E0oNHPvwifDnBzr5+W2zEIb/lnTbHQD2TpjmCHn/+dLU5apb/4YxlPLHBoDsLdN2iE6x5hMJoWiD+3mucTrXgKe9Cs0s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSBP153MB0374
X-Rspamd-Queue-Id: 4LYfTG0M1yz4m1B
X-Spamd-Bar: ---------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=EzXAi2Zw;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=microsoft.com;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.129 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com
X-Spamd-Result: default: False [-9.98 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.129:from];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[microsoft.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.255.129:from];
	 NEURAL_HAM_SHORT(-0.98)[-0.980];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]
X-ThisMailContainsUnwantedMimeParts: N

Hi Andrew,=0A=
=0A=
I have compiled the image with hv_vmbus.ko for arm64, but it seems the modu=
le is not getting=A0loaded during boot. I have already added "device =A0 =
=A0 =A0hyperv" in arm64/conf/GENERIC file. Is there=A0any other place which=
 needs to be modified to load hv_vmbus.ko during boot?=0A=
=0A=
Thanks & Regards,=0A=
Souradeep=

From nobody Sat Jul  2 04:02:05 2022
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 29B1A8A41F2
	for ; Sat,  2 Jul 2022 04:03:31 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LZdhy15wqz3JZn
	for ; Sat,  2 Jul 2022 04:03:30 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 262425HJ045267
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Fri, 1 Jul 2022 21:02:06 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 262425Y2045266
	for freebsd-arm@freebsd.org; Fri, 1 Jul 2022 21:02:05 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 1 Jul 2022 21:02:05 -0700
From: John Kennedy 
To: freebsd-arm@freebsd.org
Subject: RPI4 + ntpdate + unbound
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-Rspamd-Queue-Id: 4LZdhy15wqz3JZn
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.78 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.984];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 DMARC_NA(0.00)[phouka.net];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

  So I've got a RPI4 (no system time stored in NVRAM) that I did a stock
type FreeBSD install on setting the time with ntpdate and the unbound
DNS server (aiming for DNSSEC).  As many people have noted before me,
that setup is sort of broken because you can't look up DNSSEC hosts if
you think it's 1970.  No NTP time servers == no date reset == no DNS.

  This example is probably terrible, but starting talk point:

     $ grep -E '(ntpdate|unbound)' /etc/rc.conf
	ntpdate_enable="YES"
	ntpdate_XXX_dns="8.8.8.8"
	ntpdate_hosts="0.freebsd.pool.ntp.org"
	local_unbound_enable="YES"

  I basically added ntpdate_XXX_dns (pick a better name) to trigger the
new behavior.  If it at the ntpdate_hosts are set (I needed something to
feed to the /usr/bin/host program), then I build a list of IPs to feed
to ntpdate bypassing unbound's DNSSEC lookup.

  The tee to /dev/console is just a way of showing what is processed:

    # /etc/rc.d/ntpdate restart
	Using domain server:
	Name: 8.8.8.8
	Address: 8.8.8.8#53
	Aliases:

	0.freebsd.pool.ntp.org has address 51.89.85.70
	0.freebsd.pool.ntp.org has address 23.92.64.226
	0.freebsd.pool.ntp.org has address 178.62.16.103
	0.freebsd.pool.ntp.org has address 130.255.77.87
	XXX ntpdate_hosts -> 51.89.85.70 23.92.64.226 178.62.16.103 130.255.77.87
	Setting date via ntp.
	 1 Jul 20:39:15 ntpdate[19554]: step time server 178.62.16.103 offset -0.006001 sec

  That is a totally insecure way of ingesting IPs (trusting DNS, which
might potentially find a way to append shell commands).  But again, just
a starting point to throw ideas at.

--- /usr/src/libexec/rc/rc.d/ntpdate	2022-06-25 15:39:37.070933000 -0700
+++ /etc/rc.d/ntpdate	2022-07-01 20:39:01.793869000 -0700
@@ -25,6 +25,12 @@
 			    else                    {print $2}}
 		' < "$ntpdate_config"`
 	fi
+	if [ -n " $ntpdate_XXX_dns" -a -n "$ntpdate_hosts" ]; then
+		host $ntpdate_hosts $ntpdate_XXX_dns
+		ntpdate_hosts=`host 0.freebsd.pool.ntp.org 8.8.8.8 | tee /dev/console | \
+			grep 'has address' | sed -E 's/^.* has address (.*$)/\1/' | xargs`
+		echo "XXX ntpdate_hosts -> $ntpdate_hosts"
+	fi
 	if [ -n "$ntpdate_hosts" -o -n "$rc_flags" ]; then
 		echo "Setting date via ntp."
 		${ntpdate_program:-ntpdate} $rc_flags $ntpdate_hosts

From nobody Sat Jul  2 08:49:33 2022
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 DE8CE8A648D
	for ; Sat,  2 Jul 2022 08:49:51 +0000 (UTC)
	(envelope-from dave@dogwood.com)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031])
	(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 4LZm3L5r4zz4SRm
	for ; Sat,  2 Jul 2022 08:49:50 +0000 (UTC)
	(envelope-from dave@dogwood.com)
Received: by mail-pj1-x1031.google.com with SMTP id g16-20020a17090a7d1000b001ea9f820449so8619258pjl.5
        for ; Sat, 02 Jul 2022 01:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=dogwood.com; s=google;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc:content-transfer-encoding;
        bh=NZVUPANCgI3Zm+3cKP3JB8555gOJmhQnla+6MFmI81k=;
        b=Id0nFn8gS/15orcyCCBxeDGr1pOC5WafeLY0No8HYnI+Rf0WrV2ALPiEzVjmebdALr
         xN+RI28gmMKL+RQPukP63AzvHyGCGyHO4vqKj+l8L5xeqcdX5gq6fO7YF9lUwUbPg7o8
         Y2gjG1w/pojfk8sa2A8HhZcpZlvWOJ2itsO3k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=NZVUPANCgI3Zm+3cKP3JB8555gOJmhQnla+6MFmI81k=;
        b=f4UQpkhQfxZUvbizls+Abt41kYoAgFiLgPKJENMc45LDbLzCaJrDNhhrkad0ZW1hCr
         CwP2Im5KOhK6GExrCAyhs5MjXNiK4c9VzRWERVLiAUwD5J7EzzhACM3EuLwzRTHqKEcs
         oNs3kb05rUk+0AJWbbnmf1wp2BvBr//wQEeh7PQZCFWqpybBGxAR7fMnOVw7RHaz4Vmb
         nz5hQ/goGF60yd/tByiAIjOK5fR8WdkbV71c1qme6amwFDqqcFFvEHOXZXjP/q3dGwfP
         eO6mweoVHL+eqotuc4tvUcLkUuTv+PtK292ah2CCDg2PB3kOm+no8YcoJKcjAal2NvK4
         iS1A==
X-Gm-Message-State: AJIora/BX3Ypiy+eutmxBslHkbUPmWdmv2+RxccJ5h3c22zONi6mZ7hb
	xxoKs7rpxQDyELMixhuFhK0glZHzNOQWWv72F6pvV4ntzo4=
X-Google-Smtp-Source: AGRyM1u7Z5T4uY57yhhJa52kqoJuvJRiFixsuEK8yxkxjRcslr3OiO0KVBJK0l/3IwO2OCRWYG/ncuAyvO9BTzcuSvU=
X-Received: by 2002:a17:902:7e86:b0:16b:bcde:7cf3 with SMTP id
 z6-20020a1709027e8600b0016bbcde7cf3mr7756456pla.88.1656751784002; Sat, 02 Jul
 2022 01:49:44 -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: David Cornejo 
Date: Fri, 1 Jul 2022 22:49:33 -1000
Message-ID: 
Subject: Re: RPI4 + ntpdate + unbound
To: John Kennedy 
Cc: freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LZm3L5r4zz4SRm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dogwood.com header.s=google header.b=Id0nFn8g;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of dave@dogwood.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=dave@dogwood.com
X-Spamd-Result: default: False [-3.29 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[dogwood.com:s=google];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[dogwood.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[dogwood.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from];
	 NEURAL_HAM_SHORT(-0.79)[-0.788];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 1, 2022 at 6:03 PM John Kennedy  wrote:
>
>   So I've got a RPI4 (no system time stored in NVRAM) that I did a stock
> type FreeBSD install on setting the time with ntpdate and the unbound
> DNS server (aiming for DNSSEC).  As many people have noted before me,
> that setup is sort of broken because you can't look up DNSSEC hosts if
> you think it's 1970.  No NTP time servers =3D=3D no date reset =3D=3D no =
DNS.
>
>   This example is probably terrible, but starting talk point:
>
>      $ grep -E '(ntpdate|unbound)' /etc/rc.conf
>         ntpdate_enable=3D"YES"
>         ntpdate_XXX_dns=3D"8.8.8.8"
>         ntpdate_hosts=3D"0.freebsd.pool.ntp.org"
>         local_unbound_enable=3D"YES"
>
>   I basically added ntpdate_XXX_dns (pick a better name) to trigger the
> new behavior.  If it at the ntpdate_hosts are set (I needed something to
> feed to the /usr/bin/host program), then I build a list of IPs to feed
> to ntpdate bypassing unbound's DNSSEC lookup.
>
>   The tee to /dev/console is just a way of showing what is processed:
>
>     # /etc/rc.d/ntpdate restart
>         Using domain server:
>         Name: 8.8.8.8
>         Address: 8.8.8.8#53
>         Aliases:
>
>         0.freebsd.pool.ntp.org has address 51.89.85.70
>         0.freebsd.pool.ntp.org has address 23.92.64.226
>         0.freebsd.pool.ntp.org has address 178.62.16.103
>         0.freebsd.pool.ntp.org has address 130.255.77.87
>         XXX ntpdate_hosts -> 51.89.85.70 23.92.64.226 178.62.16.103 130.2=
55.77.87
>         Setting date via ntp.
>          1 Jul 20:39:15 ntpdate[19554]: step time server 178.62.16.103 of=
fset -0.006001 sec
>
>   That is a totally insecure way of ingesting IPs (trusting DNS, which
> might potentially find a way to append shell commands).  But again, just
> a starting point to throw ideas at.
>
> --- /usr/src/libexec/rc/rc.d/ntpdate    2022-06-25 15:39:37.070933000 -07=
00
> +++ /etc/rc.d/ntpdate   2022-07-01 20:39:01.793869000 -0700
> @@ -25,6 +25,12 @@
>                             else                    {print $2}}
>                 ' < "$ntpdate_config"`
>         fi
> +       if [ -n " $ntpdate_XXX_dns" -a -n "$ntpdate_hosts" ]; then
> +               host $ntpdate_hosts $ntpdate_XXX_dns
> +               ntpdate_hosts=3D`host 0.freebsd.pool.ntp.org 8.8.8.8 | te=
e /dev/console | \
> +                       grep 'has address' | sed -E 's/^.* has address (.=
*$)/\1/' | xargs`
> +               echo "XXX ntpdate_hosts -> $ntpdate_hosts"
> +       fi
>         if [ -n "$ntpdate_hosts" -o -n "$rc_flags" ]; then
>                 echo "Setting date via ntp."
>                 ${ntpdate_program:-ntpdate} $rc_flags $ntpdate_hosts
>

I always hated this about the RPIs - I put a DS3231 on mine and the
problem disappears. (there are cheaper chips, less temperature
compensation that should work fine). Your solution also requires a
working internet connection. I've also added a junk-box stratum 1
server on a UPS, while this was not expensive, it is a lot more than
an add-on clock, When completely isolated from the internet I can
still sync my clocks.

dave c

--=20
Kailua, Hawai=CA=BBi

From nobody Sat Jul  2 16:58:00 2022
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 A1E8887B0FF
	for ; Sat,  2 Jul 2022 16:58:09 +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 4LZytm5hxQz3pK5
	for ; Sat,  2 Jul 2022 16:58:08 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 262Gw0wT010755
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sat, 2 Jul 2022 09:58:01 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 262Gw0SN010754
	for freebsd-arm@freebsd.org; Sat, 2 Jul 2022 09:58:00 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 2 Jul 2022 09:58:00 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Subject: RPi3 usb boot hang on stable/13
Message-ID: <20220702165800.GA10701@www.zefox.net>
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-Rspamd-Queue-Id: 4LZytm5hxQz3pK5
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [1.76 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_SPAM_SHORT(0.29)[0.293];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[zefox.net];
	 NEURAL_SPAM_LONG(0.26)[0.265];
	 NEURAL_HAM_MEDIUM(-0.70)[-0.696];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

Lately an RPi3 running stable/13 has started hanging on boot from USB
The disk is on a powered hub.

When gracefully rebooted it ends with:

.....
MESS:00:00:03.166523:0: Device tree loaded to 0x4000 (size 0x63cd)
MESS:00:00:03.172180:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.178716:0: uart: Baud rate change done...
MESS:00:00:03.182145:0: uart: Baud rate change done...
MESS:00:00:03.187830:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
MMC:   mmc@7e300000: 1
Loading Environment from FAT... OK
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 

Device 0: 

At that point the console is unresponsive. 

The machine has a history of not always finding the USB disk, but this
appears to be new behavior. As with the disk discovery problem, the
error can be worked around by simple repetition. Once booted it's 
stable but network response remains erratic.

There's some indication that power-cycling the hard disk helps.

At the moment uname -a reports

FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #5 stable/13-n251597-7c500f98b8d: Fri Jul  1 21:52:12 PDT 2022     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

Thanks for reading,

bob prohaska
 



From nobody Sat Jul  2 17:34:11 2022
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 606C08A165E
	for ; Sat,  2 Jul 2022 17:34:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4LZzhd25gsz3scX
	for ; Sat,  2 Jul 2022 17:34:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656783258; bh=w9E9rvsPqnkjsb8WkeSLwlAeKkFyKF/bjpYEnWCo1ug=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZSn0dknqH9cb7yBaePWnes+wiGVF2iWt60goTlH/i6p3RxvhiYt7jK1j2WJXNLpOnsYo1N5+gUM+C2gUYQzY5pTVrjx/IC2NtDLi969Krpx+ToSuIk2EkNKbo+MmMlTZy74Y0nvrsvJoI4bd7BJaV3yHSHfry10/hUSComEzia//rSkUg6btmBrT4pRkZaYOQ8XWOnHW4d4CSRIH/5qzTeYzv7s1ZdoFFoDTdI22tCGiNMWC6fN6jrSl7A1NJcn0lx8/OpWgvvkpw5Nlscl5pcmbAeeWaMDeujMYk6PWmK91Qkv8BGt7kE8Ej8dSIlnHOAh+DkUIDAxgWvwFXF0utw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656783258; bh=1NFrD0lCoEqS6wtG0mStUblCHgcuYrhn8hnnlpDYFVt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZkHbb0hLy/zOah+PLcdWTa8BmU4CSbwX2JYOHu80PyRJTka63pWXXC1bFQ8n830uTNRVeXkAn9CgOpkWvyycfYbRP7mj4CM9qKpZEN8dFp7oWJdOQ9Qvno1SpK62pwybIvvOvGqd887enEapWGUckNxzmLPg+9sn7m61svCF2Gc3RwoWCp9otYdaRLntKEYD49X6qM6hsvvm/k6xDuSSqNiyf/i+v0M0hge6JMXQhZUjcNnB4CGOIad9G1NxZ2Y5ayVFte1Wy8oF2aiuINvmUgr0zA0mLgRoIxQ+sQt8vD3Hy0qIYTTacvT80k0rTrBA1G1Gp6EiD+mZOLbiOkcNzw==
X-YMail-OSG: lK38ADwVM1m6hogSxzK4d3XEF0TozJFmT.qmQ17rXts7n6RVO4pjiYDNIW4LhiP
 HKc1LblxycLkH94Ddc4QsOG3pTKekNRDmKNy.IJbdnNfQJvGPnoc28uwIf4dK2aFvyetTUoF2252
 2q8Qyz47hvWDUhrLO0expgLQ88KhiaCbY5Fo0ILl.R2GY8BUDqXFbsG20NJdqBlbA_cS7hcOV72x
 obumgeCaJZvOZfZTxRGX4nQefNTCxmJGQZZyrj2GmpdOMDm6dk7P1OWC3_M1J4DQWQyiMlWlkFRX
 GKYftpPTmrqkB_GKKYp52a4lnbVM4WFwUOHZvTWZuqqH05Oaqb1_n7FmoQSlFgWAkTPvEWDaJ56o
 9_kWcMhyD1RonsPel1AAZmHYlvbrogMBmTGoMQTCj2BTTVOCCOT6YY9lE0qkVOVIOA7AFuJyU.LH
 PAO2eO7.hbkRI9VXKYbAi1Raek1OCI33guiVB0FZdwZOg1Jr8PNgkTYVjRMGqGoOIbtE0ynadv7I
 A3eh9DfpOgqqLZjtIUU0IiCVzjNs6LKAxXd_gFws845dcy2Hrs2ImbwtAY4u1OIcqhSXa.dZuVzP
 UBUNIiOWqe1qxTlhAULZaqpf1YpG8L2OjM6FyMewg6l01DKR64MnOyawxxwoyTRVSi720Rbls0z0
 mDASYbEnmW3lBZ9dOnVhI55UkOzK4YUjm67RVNxeI.nvz9ixBdMiTIE2CptPoj9B2qACGzKQc4aF
 0SuHfH8p6nKrLnvBGRdG0L1ypf6rlXYGD6LsqtscCK30zIUS1vsDI9c0YVbiCBjo5gviGC.JZ3Dv
 z8dXdgAWt9GLqZ2rJcPjHIVL2M3uJU_O4DISuzVQ9Lnko.kmxTH5awhgS5MxzFkLbVuRM3VadrHP
 R_oJpL3mr932qifJhprwhLtvk61WUdWnPnCjQidNMuITq_zF_yhpIGPkMwbP.vRpRi3PW7ewVF5P
 Iby5ls9ZPOeP6VKjbzEg7ppvb4wFf5HHh3qzW3bRsf06ESCNz3Ckpt.W0ASaUpAZ60TipCwJFe5X
 7ToqSdzmym3fCp0mDAMP9prASjOhZr4IaLefD6JKtWweV5i3UpSyI_OjTW0u0Dr6ATCUjR1O1sg8
 2krnPDLMCAuUWC10UFOjUe_1WJIWtIicfr8661oqNWjH.sU3nKtqWgZkz____JgIBqF2zC51iVlM
 _MzOyat85KRVbNUZaXhsGUVg_Ja4qpmnAcBQm2TFZbnwu.ht9iAqip0ipNcVhQPuBNacWxSgNBJ5
 95RuAhaYKAwcYK.KtA.1Z2mXf9vnhj7IXmPYGvI9qCTEZa541r0NKPJy0F_cltAExd9jDm98eJS_
 .iFBGPVgEqsTm98JxjJs.d2ycvdUHH6mWzMKA47u8HYvJFtnn7p5AkO75j19cnIXvv6syfKLI49F
 PfibEyWSCFFXVGz_dbaW6mklGzvVszxffI0_bLPevpz3pJmYImuQ8QdaKT0feZOF4oLjsiKyhvEc
 MAPSpQb1FENi.srpSmDK4ovAtxuKWe3o6v3s78SmBj6n4pmUSPUzBAnjAOKudQz1AccE05Y4auOG
 dPQciTpG5fjen.2.RGP35v2ZAXt.q8R3GT1_VID.j9n.qLvxeuxti89__wWefAlJzlh5axUnryxx
 Y_DISxfJudfC6p_erNa.UVrEiZWRokQWPm7yiBnc.ixaA06aopNuNdaJ5i.SP37CDMnRbcSodQ43
 6BnGUSF9_MLbDhYnTTJHTtV_0XOnsH9FKKGgESeY6PuD8r5qiOh3j9hcOHKBvk8p5vlRltZ4cGxY
 lkSEeL2KsJfTuze1XRlYZrIwli4kyJu3EkH2GiWTsVy0MAHd0bmYK2qmJXE6.vqbCSmkjYzw46T0
 xo9SgaJuzGNmq7qGNFSd5zlpRMxFZ555UjzXlJbBCV9nnvj43YqaavQQfHTV4rresEsp37Xq5CpI
 qqKGZ_xuwY80P86qDkW5LlPi4iAqCNi0_q1jveuE9HqIVNegJy1Qeie_gSzIT7P15e6AwkE9UsYx
 HOp2aMVRoCTn06ok3aU9ZpTh1fp5Y32Z6cQ_j_48jHFy_vKd_CSTWh7Q8kb4PXN5mlUMsg67o.Zj
 gFhtN9z6.VxgecW3rxSYBPcQZOFmw1RJLh8.wPJtxLeWnGmYuK6oO4dZuWDnYauJ81a2G8zWzuqz
 Nq6ZPI_JZVfCWor2KGKxHum2C0Q3JI0.ymZ79wqvDwIBK0ztoADhQDhgRxaz1Uv5L5Bj0csANV9n
 xV.0tXvhkDp7lcFqiiLGwYaeI_9MlM5JqEgWS052cVVvcxXX5dkPq4ykIft5e1aQjsWSpMTeCug-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 2 Jul 2022 17:34:18 +0000
Received: by hermes--production-ne1-7864dcfd54-hwfdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1703430ffcba335b41e7fef98a79c414;
          Sat, 02 Jul 2022 17:34:13 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPi3 usb boot hang on stable/13
From: Mark Millard 
In-Reply-To: <20220702165800.GA10701@www.zefox.net>
Date: Sat, 2 Jul 2022 10:34:11 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
References: <20220702165800.GA10701@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LZzhd25gsz3scX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZSn0dknq;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(1.00)[0.996];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-2, at 09:58, bob prohaska  wrote:

> Lately an RPi3 running stable/13 has started hanging on boot from USB
> The disk is on a powered hub.
>=20
> When gracefully rebooted it ends with:
>=20
> .....
> MESS:00:00:03.166523:0: Device tree loaded to 0x4000 (size 0x63cd)
> MESS:00:00:03.172180:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:03.178716:0: uart: Baud rate change done...
> MESS:00:00:03.182145:0: uart: Baud rate change done...
> MESS:00:00:03.187830:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined
> MMC:   mmc@7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
>=20
> Device 0:=20

That is U-Boot output. Looks like the output stopped before
the load of even the FreeBSD loader: FreeBSD is not involved
yet so it is not a FreeBSD problem.

> At that point the console is unresponsive.=20

Nasty.

> The machine has a history of not always finding the USB disk, but this
> appears to be new behavior. As with the disk discovery problem, the
> error can be worked around by simple repetition. Once booted it's=20
> stable but network response remains erratic.
>=20
> There's some indication that power-cycling the hard disk helps.
>=20
> At the moment uname -a reports
>=20
> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #5 =
stable/13-n251597-7c500f98b8d: Fri Jul  1 21:52:12 PDT 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

But FreeBSD is not involved yet at the failure point.

What vintage of U-Boot?

# strings u-boot.bin | grep "U-Boot 20"


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul  2 19:00:02 2022
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 4065E8ABA0B
	for ; Sat,  2 Jul 2022 19:00:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4Lb1bh1GQqz4VGC
	for ; Sat,  2 Jul 2022 19:00:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656788409; bh=YtrRQR6voBwM7heK6x6Cv0K1MqT6+aBYPJsWPzOBh7A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ou1I/8FcDvFydKqE49IqRrXXzTtNno+ooDbapRE8bH3IAA7Vo1W+2h2bvXmtFhwpr60H+iLBF6GzFMd0BvJaqKjjUdfNfpbmNgYlxb7Yc7XH4aX0rq0JZAyFBeluQVqhuv9GY+6nTlu1n/WfoT220m85pGN5f0t5xOE8lb3H2SXPfstLxooi87rLq8A9Mjm0Qsu+wThLIbM1D7oEHRuv+KlU83wOD9uq+ULvl/L3kJVp27k+MvB3ToWrUBLeQyuRdH2NxabbIeP9nCS10HvIgqPOdWi6BS8fEfrpyO8p/2E5SM+UgrbtwaRSqWGayxjhEsMEGXVN/BtEsaJWRKSovw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656788409; bh=UaHR+UAMXoji7Qq0RWI0alMq16QHElCF5YJqOxfv8d7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Kv0SqrXur9/Zha7tF9TzMMJcnsO90T/OEbmWAAe0JFVevF/AzruW3WJIpem2heYkUqcIL2+wbLbdOkXCDEZHTn9lx0bizPE+fr0BL+f6dP98U61QR7UIXEY+SrQaRri2mB+KMfrGy8HsQnvK5aTXvaGalLkdI4yI0DtZQ3Bq4Vfzmu0ZQhdiDQQm3JvwhTrzb0VY2lEV/yTowFX4fi27QpOmZ3dRiDgWL7/yfPG3x5Jd7XgoFGQcl5ICE8NlwGE6zL23GmhONb4/hE/S2/ELQ4CLCwR+7z5KJF4g20lYSM5d91+EAjw6+TcGGshqb72TpI8XDECd5xJOUVDzPISUjA==
X-YMail-OSG: VopI_CEVM1neAq31yIiaHWiNdOQwudf0poW2_J9HmvKLczEcWrs3hU4c2ZCFwwQ
 F_abPMpHonBdeFKJrpndFvwaMPJtFzh6HxWP9g1uaXbxnOl4fASGXwORyG.7SLUMu7cuTWpVT3VN
 q2fFWlZDVj1JF9.4_Bl0rZu1s34.lrqJ0P6ommmnb4QnC12vrP1h2uK.eMi0BR7wyMZY_.56ojko
 0nPX6KJF.5wkSQRpQ6niPS9q0OBHvEyOOjC95MPsgL_sn4rVjCRpXHO1m4zbbtumsB4gRDZJamK8
 Iq31YtWtk0YN0wLuFJ4IUhOZCa676ZRjt70Ox92jSXZVh..zDc.oq.ipvY22QlBn1ezUeoA9Qw2b
 WML2_qYjJ3D_FkSKmcdUoZHI4_kIjm1EfqrfUU8vGLAFY0ylnFt2hrRUDWg4NjL9OpLfrLqNr.Pj
 LPpHmk5RQid_qHEp1pfyz5Az0H_NI0I64Ez_Q2iqBWwUs9eVDJsQAN952e8yNdbqQrTadCTWp2kg
 LW6gIt2_qgFPd8ppqgTBPWSNDpG16IJ1MMKIfDMVpwY3FcqvEdlZu5Zd7U5xSA5uWTfUX038V_wv
 K2gNMchRAgC5SULukuHFGW4s_EvuPWJJmR7SfvfDy1B3Rnk3ksKhgy3V3LCOvIrXF5bQuZ3P_R7T
 P0pXLM82GEIQkjAXkqd5EgMLCRV_CeWTdisPQWb_KyRAWO_iBlNUfa9kiYZxh13JplKm0Vvt7I0f
 Xmg4Vk.fSs7GcLVN4io_ALRULkcsNVwq8qIO4OBbTKvgv8TLeHnU6R5Ju22NI2Rpz02aGe6EzRYD
 gFbAS35OiO7KwRYIsenmEzemMm1kcjYwiy.xkl0ZjvByp5OR0frotT8vjMwrMxNon5GmeKwnw7hx
 lbspoa4_3j1US5joTviDjc7t5BybQ3iFwsuzseann5L4B9zWWPlFRzgGDoI1.ngsoqA4C9mOMISo
 mVVpzrMPCeLa3XRc1oItfNNKAnU9GUcqdzMbJgqEvElsbvyogcFNIqNwaPdm3ZRgm88zQb7XZHAW
 w3Ut079YP4Woc5ThrVGhp5RRxyFQK1Ry5eWAaRcQv7dl4P8.lQlVEvxAJncuQQo4iDTS93L.F1yN
 3GKRoa4d2PoiMmyd01qpeCqlS2Zin1q6j9sjYcxqMuPfe74cIy1bYBXvn_wl8zGW30s1J9I5wGT0
 mJwHlWtot33ovu4SC29xac6_QfT2WaVyrmUtvKWhPo6tuhh_mm.3mt0pOR_7LacL.19QZ6wnZAXT
 R_zWk.hlkA8dNiL64RKwNxBbc7yiQQhFJf7PQcB6z8FSVww654NjNuqePLaZfAYYTTtubt6eMR_9
 6ibfONE8WhjXr7kH0mSyHk7jxPAPRKXzyvseF3qNrGcth..tI9e_axnowQtjd.yDRCaWaT5vwt6X
 IodFiZitAeNhYdZOcuJrk1FnTcp.mBrPH5MW.quqvdTT_6DG9_YOr9hwV9XCVtmRjOy4KVSbWwZ6
 TjSF2DROiMXpDZzwnHi9hn_AubPEJJhsmTBYk5YlhjcqnO0H4FNYtHQVgRUq6TdZ1_VQtJywT1_C
 kTTpqu2MwKQjHD.m9KgzA2tHh97rfXuTIAbNnFtezFXg5rmmy6SZ1L9vBod9d7SHXiISHN.PAGDY
 15LD08sPUvVtSgTT_qJfEMzT7cwZuLBWs7dQPwgG5ouct7xujEzNDMvglONabljXXru820eOTv95
 5nQW7io1H152pKfngHAeOfGo6rFTEmhnPO2OjzLhU16HKynNNE3Te4FBAW.hdyzkN4VkJVs419gl
 Q6_CQocWkL0yrPE3BbOlwqVemAqUE0xSret7_6d.ivwtv_udEMZbv8g9RtYFfZhGI4gCb1ugiSu7
 uWsmFjI1OyNFDYRk3jQxDnb3jn7E3b2QyjRCupK6V.9XfNGfc7HxA2ggs3RYqJVzUnBvr6x_uarv
 w_pZoizdhoAs3WrNEz7IOApqm4LRz5qA4dxm7fem7vYoPP0GSwclNHi2NtPndh0ygy0KvuIy4rya
 Y3eQv_8VwGFEIR55yA7LZs7pe0gCFhVieDbr4m2mpfPWQes.C3VASIcJjRdHEQNq6RHIdRw8BHet
 1KoaNdsTrYixC9HCJTQKzzjI2I.b67nZT2eDH3GIJetwTuC1EXrlttmLoSyf_x5c8kMNjBQ8UEVD
 phMzil1l1_zOk4NQKSyyQ7Mxrauq7f36lS.B4wWamwiy2YNGB1TmLtdEmbfXChxkESirVEXdo5gv
 jeocwc_gNqbMbDt5phRQWi62TOFP5pj85kep_lZ6DXDTYliIhlsWTpTCl24LIVkmSSpQ19W9eGke
 EZA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 2 Jul 2022 19:00:09 +0000
Received: by hermes--production-ne1-7864dcfd54-mdwhz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 87f564464f20f5e1e07c8125370ff282;
          Sat, 02 Jul 2022 19:00:04 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPi3 usb boot hang on stable/13
From: Mark Millard 
In-Reply-To: <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
Date: Sat, 2 Jul 2022 12:00:02 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D669B0-728D-4910-884A-B2230AE442F9@yahoo.com>
References: <20220702165800.GA10701@www.zefox.net>
 <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lb1bh1GQqz4VGC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="ou1I/8Fc";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-2, at 10:34, Mark Millard  wrote:

> On 2022-Jul-2, at 09:58, bob prohaska  wrote:
>=20
>> Lately an RPi3 running stable/13 has started hanging on boot from USB
>> The disk is on a powered hub.
>>=20
>> When gracefully rebooted it ends with:
>>=20
>> .....
>> MESS:00:00:03.166523:0: Device tree loaded to 0x4000 (size 0x63cd)
>> MESS:00:00:03.172180:0: uart: Set PL011 baud rate to 103448.300000 Hz
>> MESS:00:00:03.178716:0: uart: Baud rate change done...
>> MESS:00:00:03.182145:0: uart: Baud rate change done...
>> MESS:00:00:03.187830:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined
>> MMC:   mmc@7e300000: 1
>> Loading Environment from FAT... OK
>> In:    serial
>> Out:   vidconsole
>> Err:   vidconsole
>> Net:   No ethernet found.
>> starting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 1 Storage Device(s) found
>> Hit any key to stop autoboot:  0=20
>>=20
>> Device 0:=20
>=20
> That is U-Boot output. Looks like the output stopped before
> the load of even the FreeBSD loader: FreeBSD is not involved
> yet so it is not a FreeBSD problem.

Hmm. I looked at an old RPI3 boot-session log I have around and
it shows more text than you report. Is your serial connection
having problems? An example that is missing is the line
"U-Boot . . ." that identifies the version and build time
of U-Boot. That is rather generic material to be missing.
(I did not have a microsd card present. Such could be an
example of expected differences.)

QUOTE (of a similar range of text)
MESS:00:00:03.285409:0: Device tree loaded to 0x4000 (size 0x7640)
MESS:00:00:03.292968:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.299261:0: uart: Baud rate change done...
MESS:00:00:03.302695:0: uart: Baud rate change done...
MESS:00:00:03.308421:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined


U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000)

DRAM:  948 MiB
RPI 3 Model B (0x2a02082)
Core:  72 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0=20
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc2 is current device
Scanning mmc 2:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@7e300000.blk...
Scanning disk usb_mass_storage.lun0...
Found 9 disks
Missing RNG device for EFI_RNG_PROTOCOL
** Unable to read file ubootefi.var **
Failed to load EFI variables
BootOrder not defined
EFI boot manager: Cannot load any image

Device 0: Vendor: Samsung  Rev: 0    Prod: PSSD T7 Touch  =20
            Type: Hard Disk
            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
END QUOTE

There is the difference (yours then mine):

MMC:   mmc@7e300000: 1
vs.
MMC:   mmc@7e300000: 2

I wonder it if is some sort of clue about something.

>> At that point the console is unresponsive.=20
>=20
> Nasty.
>=20
>> The machine has a history of not always finding the USB disk, but =
this
>> appears to be new behavior. As with the disk discovery problem, the
>> error can be worked around by simple repetition. Once booted it's=20
>> stable but network response remains erratic.
>>=20
>> There's some indication that power-cycling the hard disk helps.
>>=20
>> At the moment uname -a reports
>>=20
>> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #5 =
stable/13-n251597-7c500f98b8d: Fri Jul  1 21:52:12 PDT 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20
> But FreeBSD is not involved yet at the failure point.
>=20
> What vintage of U-Boot?
>=20
> # strings u-boot.bin | grep "U-Boot 20"
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul  2 19:12:12 2022
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 C51B58AD935
	for ; Sat,  2 Jul 2022 19:13:33 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lb1v03dclz4X0G
	for ; Sat,  2 Jul 2022 19:13:32 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 262JCCAT047322
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 2 Jul 2022 12:12:12 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 262JCChe047321;
	Sat, 2 Jul 2022 12:12:12 -0700 (PDT)
	(envelope-from warlock)
Date: Sat, 2 Jul 2022 12:12:12 -0700
From: John Kennedy 
To: Mark Millard 
Cc: bob prohaska , Free BSD 
Subject: Re: RPi3 usb boot hang on stable/13
Message-ID: 
References: <20220702165800.GA10701@www.zefox.net>
 <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@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: <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
X-Rspamd-Queue-Id: 4Lb1v03dclz4X0G
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [2.19 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_SPAM_LONG(0.98)[0.985];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-2, at 09:58, bob prohaska  wrote:
> Lately an RPi3 running stable/13 has started hanging on boot from USB
> The disk is on a powered hub. ...
> FreeBSD 13.1-STABLE #5 stable/13-n251597-7c500f98b8d: ...

  For what it's worth, on my RPI4, single USB (M.2) only.  Only had it
since ~6/25 so it's run 13.1-5ce13b8aa51, 0e897d87f73, 70fd40edb86 and
currently 13-n251597-7c500f98b8d like you.  I've rebooted it a fair
amount as I'm playing with config.txt settings and other stuff.

  I'm not using a serial console either, for what that is worth.

On Sat, Jul 02, 2022 at 10:34:11AM -0700, Mark Millard wrote:
> That is U-Boot output. Looks like the output stopped before
> the load of even the FreeBSD loader: FreeBSD is not involved
> yet so it is not a FreeBSD problem. ... What vintage of U-Boot?

  In my case, uboot was seeded from this image:

	FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220603-185159f77c9-250958.img.xz

    $ strings -a < /boot/efi/u-boot.bin | grep "U-Boot 20"
	U-Boot 2022.04 (Jun 03 2022 - 02:14:43 +0000)


From nobody Sun Jul  3 01:38:24 2022
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 7FB658B34D2
	for ; Sun,  3 Jul 2022 01:38:37 +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 4LbBRJ2Ys2z3MV3
	for ; Sun,  3 Jul 2022 01:38:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656812309; bh=Eb+f+M7A0siamkRaZXrB9BzUYDGiWj2Kd2bqMEMO5RU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Aj9hhDd9I2aOWoeOjzp37wdj7uzb+busEgJ107lSsJhWR5H3h/i6acSTH6vlh4WbwG/rTeOmtaRSrT2diHDY3iODFiB/HpxMt+c9mQPQbWVOuFAIE5APMo6A5yhll9jNrDt8s6sQZ9+W2yLwK1mQ/SlhaCfn/9MK25RYxXZc3NypE9FzFDesxs80wuJvJldnyHyuP6FPCRBaEFzyVMdpqdNNxf4TMKw7kKGzApDlbvy6esPKF94LF6sBDoT/OEoS4IQgCNXRy6vDVD9rQ0TJb4J68NUPGxWfnQZZ+cLcuVTjfAWvhwosInan+vSl4WJh65/51sIBGzPIdXQBSZyNWg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656812309; bh=b+rdsYVC9viUXdyz7MRO79Yh9UwtyXXcZ7jAg+35aaQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pGL0S+u8hvuS2N6fD9tvAl+VeCx+Ki9J8xYm3bYDRgPZP/S1miaoASbpBs1G2zLMnFB5/UnZKWtyEv0f5VoMnXCTMRCKpqapqqgc4N00J/WnI29zLqmG9qDcG1Ai3/Jjrf7RdliWtd51v0cFwmSTxBHE84VctkzjCMCXz+WhZcGM4or42zeebUAmhy+s/wAS8xj94Xjg/7zQfE6Y2drS4CElEJDF/BNa45tIgl2IR02Jqff4+fPEtAUMosX+2mpLmDASAXBiTrqWulaqTlxYRnXzM3RUE/TX9ztpIGyxfJtrKWQa4HY7403WVCI7cPwV8zA0GhCGbXjPdHZHNr0KdQ==
X-YMail-OSG: VAAHGiIVM1mV6CjdC7MbmKnp_PaxaPkpDEc9Bu6PfEkTWvtvZIfYMuzThxZXp5A
 Y08vosAfojDr.ng_ej8K9gwP.BcHRSeYoTiWPJiKckSXQnqhn1lpYJ3MWryA828nOx9XMD182cvS
 AJhBYh5gQTb9AV0CEIy7wfeb4AceUMc_FjyPySFIWah7C.2XycHXmOgZ1_56NoVMiSmGcLinpcO5
 JqnwjS9m6C4bCOi0hBCjl5mmlCEkZuEW9zSHuiypRMM6J.o6xXpBlK1fqZ.16uCW.4xeSCnr8lUN
 TLalku2qybKqC8wDu1hyWIkGbF_EEG6QoxQtJMOfxCUGiZmhoLQTKrk7CUC77.XqYcGgU3yook6v
 2txTXxNY5f.zpoDSFHANMmfEOb6iBKUrur_m9uh0lgBdQi5fxkRvgp19q7ia7_.j8hl1j0GTO8CD
 PaCYNXJhhqyNoWsp6je6B5knI8uTlGLSN8OENh4fHVgNu8Zr7EInNUPnI7xrc5UXKaUJTp7VLP7R
 T.LEhGttDQMjq_9knUlzHs5xU3wnLqQvfVh3EegMMB5VBlqGL4B3CZEmomHq9.fLxQ8yHAEPjerg
 5SZjMRZm6i_iFInVrZ699xLG_idyrnuZoAYpnSFDxooDeSYolG13BDwB9DBqaeEt3ORbnX8kW8KK
 uhh6Aac8FQ7hpUx_5O6kxwfKylIF3YBs_XhU4bA53lZxkrrBEigIxFm4oLyZsUpmNgz4As7hU40l
 ZV5jqcHryl8HMuFJM_sr52S8N_ewko.kYiiqMTTkLiGuKytE7WqdILFvrQw69n3ezkqVy4IGly3y
 xBhUMl_kLHrMXVGqd611yiUL8JyxJ2Nie5qTqMPsQMtj.3fQSw95nSFHqY4GTHLx_0ciq5ohIEvC
 s7CHh93fLLbzP6YWQVIIVxpMefj8O_qoRjUDcwjVT8n1HNledM5JCygZoD2zAm3jopxJell1LuUu
 sURl_mya3kZqmngDclSaDd52lgxw8cOCY8a1.rlh6umUn6lAG8SKW4HUSGfMzsNtC4xKBXy3Hloy
 CvEOmXXtpofshjtVMvVk4NlNZVbXX4BuRT4O8FzAn6Be4YmzFt9x45HOSqZQSo1Y_45Kq7AfCu59
 EiqkALvi2SqDbFkgue3g.OmSvH7uxk.vvW7DYdcBPgxogXoJqwjH_gphVYGBy8Q3jg.aGKqLvVBI
 sT32AaG40tXZxQBdOzhSLe_x.oqkfQBLSTDqYxOTMBNiKWZrauXSR2yipL3bCF1XRuiSy1wgmydB
 HXxAmrChbEoj.9h.UhnM_EspoeBlgLJ9Uh21lUgfeoTg5TpUjgVndZBBogjQ.z2cV6yJM.rgcUBC
 KWlf7hj6pjlfkUVghJwsxwqYe0mIxeP3dBw8zONuqvUpNMK1tE76M9CvLxvT2TqD3qXhzjaZtxWb
 lmxrCtxmDEF2KbWrIGQfMCNVYNIs70qqcjvpzVDY3M7kR3omIcXvrweOqtdfBMZvBlsHTmM8kNA5
 umVSrj53hDDECWuGbNMWuxx3jX4R7V5XE5DgDymGlYxskkfJR_H1CljHXY2cIktnHKQ1itqj4gBC
 2y1ibP_ruvu7CVLL.fhaB.SGs.S63IgjG3.v8dHie5LCgzHC4pXSt9ODCDTNuRp7MyEqUDnTBB6U
 xRNOcFFhF0xwmNqjyLmDpjwD3jg6fR3y782YbLt5.OPZYV0POcVSeuzFVW.xBIfJ9sNUYZ4QvCuD
 aXrJ1KUHHkGvnOBm1EIeB7vGkFoo6ikPx5noteE4z_Oh5.2ZwZh0Cuxyb6m8YLpBxjd86sJ7OwX1
 QSFocxdTtVdRjR1anqOkRMlSQ7.BCr2Zksahi5FUufA6wnQ_A7MGA_z7cXN14R0miqmMNCdL82Rl
 NGah.ZXS9EcCIGsGDioGZ9AYQsIIdQdoXq8T_RiaMKkavC0IM41Qhz0WGe3OHUNhh5FC7dxgmljZ
 U_ezZKYQSZXShibqTHUFx._oU5DFIr3wN.CnYjTeKRFuAlV1j1w5r93JYLkjZUp4ccHey9TFEmUK
 9r3Iv6RzVhAb6UTJx_aokb.V48JNNoMUpGrVysQ2DzOX1TIy7Owqn.Hj3DNMWv7d_WSSnY6BHAvU
 _f_kT6jL4tZHBgDbtFUw8smMqNNd8KIdVFUao7kMDE8aE5YbT9MIPt1hWyAOT8J4ZkBn3NmPDuCm
 WZJcs9cNrg.Y9G.Fnpf7r3nLTdx4m1UnVOPcluhwnovpEFfABUg7C.b2NSXNncXYq0yhraiG814c
 uqy5hHriHjubVOB1QBhkZAVFhsyaH6.ucRh0eX_aeP9hsvOJNyNUm6qhM8kW9JZxZ4IhhXvr8i8o
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 Jul 2022 01:38:29 +0000
Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94c36636198973bd27e89819296413b9;
          Sun, 03 Jul 2022 01:38:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPi3 usb boot hang on stable/13
From: Mark Millard 
In-Reply-To: <20220702222139.GB10701@www.zefox.net>
Date: Sat, 2 Jul 2022 18:38:24 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220702165800.GA10701@www.zefox.net>
 <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
 <24D669B0-728D-4910-884A-B2230AE442F9@yahoo.com>
 <20220702222139.GB10701@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LbBRJ2Ys2z3MV3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Aj9hhDd9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.18 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.68)[-0.679];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Jul-2, at 15:21, bob prohaska  wrote:

> On Sat, Jul 02, 2022 at 12:00:02PM -0700, Mark Millard wrote:
>> On 2022-Jul-2, at 10:34, Mark Millard  wrote:
>>>>=20
>>>> Device 0:=20
>>>=20
>>> That is U-Boot output. Looks like the output stopped before
>>> the load of even the FreeBSD loader: FreeBSD is not involved
>>> yet so it is not a FreeBSD problem.
>>=20
>> Hmm. I looked at an old RPI3 boot-session log I have around and
>> it shows more text than you report. Is your serial connection
>> having problems? An example that is missing is the line
>> "U-Boot . . ." that identifies the version and build time
>> of U-Boot. That is rather generic material to be missing.
>> (I did not have a microsd card present. Such could be an
>> example of expected differences.)
>>=20
>>=20
>> There is the difference (yours then mine):
>>=20
>> MMC:   mmc@7e300000: 1
>> vs.
>> MMC:   mmc@7e300000: 2
>>=20
>> I wonder it if is some sort of clue about something.
>>=20
>=20
> It just dawned there are two u-boot instances: One on the microSD,
> which I think is the "special USB boot" version, which reports
> U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700)

The above is what you are using when you use the microsd
card. See later.

> and a second on the FAT partition of the USB disk, which reports
> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000)

You are not using the above one when you use the microsd card.

You are using the above one if it gets to U-Boot without a
microsd card present.

> Just tried removing the microSD card and issuing shutdown -r now.
> The console got to "Resetting system..." and stopped.=20
>=20
> Put the microSD back in and tried again from the beginning. It looks
> like the machine starts from microSD and transfers control to u-boot
> on the USB drive.

No: See later.

> The USB boot OTP was set IIRC, haven't checked lately.
> Maybe it's time to reformat and start over.....
>=20
> What follows is a fairly typical startup session:
>=20
> Resetting system ...=20
>=20
>=20
> Raspberry Pi Bootcode
>=20
> Found SD card, config.txt =3D 1, start.elf =3D 1, recovery.elf =3D 0, =
timeout =3D 0
> Read File: config.txt, 178 (bytes)
>=20
>=20
>=20
>=20
> Raspberry Pi Bootcode
> Read File: config.txt, 178
> Read File: start.elf, 2835780 (bytes)
> Read File: fixup.dat, 6639 (bytes)
> MESS:00:00:01.108743:0: brfs: File read: /mfs/sd/config.txt

/mfs/sd/ is the microsd card in your context.

The above is config.txt being loaded from the microsd card.

> MESS:00:00:01.112989:0: brfs: File read: 178 bytes
> MESS:00:00:01.126707:0: HDMI:EDID error reading EDID block 0 attempt 0
> MESS:00:00:01.132784:0: HDMI:EDID error reading EDID block 0 attempt 1
> MESS:00:00:01.139029:0: HDMI:EDID error reading EDID block 0 attempt 2
> MESS:00:00:01.145279:0: HDMI:EDID error reading EDID block 0 attempt 3
> MESS:00:00:01.151529:0: HDMI:EDID error reading EDID block 0 attempt 4
> MESS:00:00:01.157779:0: HDMI:EDID error reading EDID block 0 attempt 5
> MESS:00:00:01.164029:0: HDMI:EDID error reading EDID block 0 attempt 6
> MESS:00:00:01.170279:0: HDMI:EDID error reading EDID block 0 attempt 7
> MESS:00:00:01.176529:0: HDMI:EDID error reading EDID block 0 attempt 8
> MESS:00:00:01.182779:0: HDMI:EDID error reading EDID block 0 attempt 9
> MESS:00:00:01.188792:0: HDMI:EDID giving up on reading EDID block 0
> MESS:00:00:01.206550:0: brfs: File read: /mfs/sd/config.txt

The above is config.txt (again!) being loaded from the microsd card.

> MESS:00:00:01.210671:0: HDMI:Setting property pixel encoding to =
Default
> MESS:00:00:01.216761:0: HDMI:Setting property pixel clock type to PAL
> MESS:00:00:01.222920:0: HDMI:Setting property content type flag to No =
data
> MESS:00:00:01.229520:0: HDMI:Setting property fuzzy format match to =
enabled
> MESS:00:00:01.236297:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK =
not defined
> MESS:00:00:01.439246:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK =
not defined
> MESS:00:00:01.445328:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
> MESS:00:00:01.453811:0: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading =
EDID<<<<<<<<<<<<<
> MESS:00:00:01.461557:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 0
> MESS:00:00:01.469289:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 1
> MESS:00:00:01.476056:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 2
> MESS:00:00:01.482826:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 3
> MESS:00:00:01.489597:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 4
> MESS:00:00:01.496368:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 5
> MESS:00:00:01.503138:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 6
> MESS:00:00:01.509910:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 7
> MESS:00:00:01.516681:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 8
> MESS:00:00:01.523451:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 9
> MESS:00:00:01.529985:0: hdmi: HDMI:EDID giving up on reading EDID =
block 0
> MESS:00:00:01.535499:0: hdmi: HDMI: No lookup table for resolution =
group 0
> MESS:00:00:01.542084:0: hdmi: HDMI: hotplug attached with DVI support
> MESS:00:00:01.548262:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
> MESS:00:00:01.557298:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 0
> MESS:00:00:01.565030:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 1
> MESS:00:00:01.571802:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 2
> MESS:00:00:01.578573:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 3
> MESS:00:00:01.585343:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 4
> MESS:00:00:01.592115:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 5
> MESS:00:00:01.598886:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 6
> MESS:00:00:01.605656:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 7
> MESS:00:00:01.612427:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 8
> MESS:00:00:01.619198:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 9
> MESS:00:00:01.625732:0: hdmi: HDMI:EDID giving up on reading EDID =
block 0
> MESS:00:00:01.631505:0: hdmi: HDMI: hotplug deassert
> MESS:00:00:01.635919:0: hdmi: HDMI: HDMI is currently off
> MESS:00:00:01.641039:0: hdmi: HDMI: changing mode to unplugged
> MESS:00:00:01.646605:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
> MESS:00:00:01.656008:0: *** Restart logging
> MESS:00:00:01.659280:0: brfs: File read: 178 bytes
> MESS:00:00:01.665054:0: Failed to open command line file 'cmdline.txt'
> MESS:00:00:01.672773:0: brfs: File read: /mfs/sd/armstub8.bin

The above is armstub8.bin being loaded from the microsd card.

> MESS:00:00:01.676824:0: Loading 'armstub8.bin' to 0x0 size 0x1700
> MESS:00:00:01.682667:0: brfs: File read: 5888 bytes
> MESS:00:00:01.718268:0: brfs: File read: /mfs/sd/u-boot.bin

The above is u-boot.bin being loaded from the microsd card.

> MESS:00:00:01.722146:0: Loading 'u-boot.bin' to 0x80000 size 0x7a2d8
> MESS:00:00:01.731830:0: No kernel trailer - assuming DT-capable
> MESS:00:00:01.736078:0: brfs: File read: 500440 bytes
> MESS:00:00:01.743877:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb

The above is bcm2710-rpi-3-b.dtb being loaded from the microsd card.

> MESS:00:00:01.748535:0: Loading 'bcm2710-rpi-3-b.dtb' to 0xfa2d8 size =
0x5f12
> MESS:00:00:01.889271:0: brfs: File read: 24338 bytes
> MESS:00:00:01.892986:0: brfs: File read: /mfs/sd/config.txt

The above is config.txt (again!) being loaded from the microsd card.

> MESS:00:00:01.897876:0: dtparam: audio=3Don
> MESS:00:00:01.919689:0: dtparam: i2c_arm=3Don
> MESS:00:00:01.938056:0: dtparam: spi=3Don
> MESS:00:00:01.954303:0: brfs: File read: 178 bytes
> MESS:00:00:01.959758:0: brfs: File read: /mfs/sd/overlays/mmc.dtbo

The above is overlays/mmc.dtbo being loaded from the microsd card.

> MESS:00:00:01.981176:0: Loaded overlay 'mmc'
> MESS:00:00:02.030370:0: brfs: File read: 1099 bytes
> MESS:00:00:02.034426:0: brfs: File read: /mfs/sd/overlays/pwm.dtbo

The above is overlays/pwm.dtbo being loaded from the microsd card.

> MESS:00:00:02.051824:0: Loaded overlay 'pwm'
> MESS:00:00:02.087719:0: brfs: File read: 946 bytes
> MESS:00:00:02.091725:0: brfs: File read: =
/mfs/sd/overlays/pi3-disable-bt.dtbo

The above is overlays/pi3-disable-bt.dtbo being loaded from the microsd =
card.

> MESS:00:00:02.115336:0: Loaded overlay 'pi3-disable-bt'
> MESS:00:00:03.175615:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE =
not defined
> MESS:00:00:03.287931:0: Device tree loaded to 0x4000 (size 0x63cd)
> MESS:00:00:03.293589:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:03.300125:0: uart: Baud rate change done...
> MESS:00:00:03.303554:0: uart: Baud rate change done...
> MESS:00:00:03.309236:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined

There is missing text from U-Boot here.

But the below is from the U-Boot on the microsd card.
Try renaming it, copying an alternative version,
and seeing what it does? Repeat . . . ?

> MMC:   mmc@7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
>=20
> Device 0: unknown device
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot> power-cycled hub
> Unknown command 'power-cycled' - try 'help'
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot> editenv usb_pgood_delay
> edit: 3200
> U-Boot> editenv usb_pgood_delay
> edit: 19000
>=20
> [saveenv results in "saving to FAT failed"]
>=20
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> U-Boot>=20
> resetting USB...
> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> U-Boot> boot =20
>=20
> Device 0: Vendor: SABRENT  Rev: 1214 Prod:=20
>            Type: Hard Disk
>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi

The path is not explicit enough to directly indicate the
microsd card vs. the USB drive. But the above is one
of the (possibly) 2 FreeBSD loaders you have in your
environment.

> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk mmc@7e300000.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 5 disks
> BootOrder not defined
> EFI boot manager: Cannot load any image
> 1259212 bytes read in 676 ms (1.8 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>=20
> [whitespace omitted]

The below is from one of the FreeBSD loaders.

> Consoles: EFI console =20
>    Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk1p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
>=20
>   Command line arguments: loader.efi
>   Image base: 0x39e06000
>   EFI version: 2.80
>   EFI Firmware: Das U-Boot (rev 8217.4096)
>   Console: comconsole (0)
>   Load Path: /efi\boot\bootaa64.efi
>   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(1,MBR,0x76573018,0x81f,0x18fa8)
> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(1,MBR,0x76573018,0x81f,0x18fa8)
> Setting currdev to disk1p1:
> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(2,MBR,0x76573018,0x197c7,0x746ed5e9)
> Setting currdev to disk1p2:

"disk1p2:" is from the USB drive (based on the long line before it).

I expect that this means that the FreeBSD loader was also from
the USB drive.

> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=3D0x2a8 text=3D0x89ef40 text=3D0x1fb30c =
data=3D0x1a9358 data=3D0x0+0x2a8000 syms=3D[0x8+0x121740+0x8+0x1454aa]
> Loading configured modules...
> /boot/kernel/filemon.ko text=3D0x1574 text=3D0x272c data=3D0x500+0x20 =
syms=3D[0x8+0xcd8+0x8+0x7c5]
> /boot/kernel/umodem.ko text=3D0x2160 text=3D0x1400 data=3D0x6e8+0x10 =
syms=3D[0x8+0xf48+0x8+0xb75]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=3D0x249f text=3D0x3360 data=3D0x8a0+0x858 =
syms=3D[0x8+0x1188+0x8+0xb19]
> /boot/entropy size=3D0x1000
> /etc/hostid size=3D0x25
>=20
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...              =20
> Using DTB provided by EFI at 0x7ef6000.
> EFI framebuffer information:
> addr, size     0x3eaf0000, 0x10a800
> dimensions     656 x 416
> stride         656
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<>---

This is about where the kernel output starts.

> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance

The dtb files used do not have freebsd specific content. As I
understand, for RPi*'s, the above is expected.

> Copyright (c) 1992-2021 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 13.1-STABLE #5 stable/13-n251597-7c500f98b8d: Fri Jul  1 =
21:52:12 PDT 2022
>    bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64
> FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
> VT(efifb): resolution 656x416
> module firmware already present!
> real memory  =3D 993988608 (947 MB)
> avail memory =3D 947646464 (903 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
> MAP 39f42000 mode 2 pages 1
> MAP 39f4d000 mode 2 pages 1
> MAP 3b350000 mode 2 pages 16
> MAP 3f100000 mode 0 pages 1
> kbd0 at kbdmux0
> ofwbus0: 
> simplebus0:  on ofwbus0
> ofw_clkbus0:  on ofwbus0
> clk_fixed0:  on ofw_clkbus0
> clk_fixed1:  on ofw_clkbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> bcm2835_firmware0:  on simplebus0
> psci0:  on ofwbus0
> lintc0:  mem 0x40000000-0x400000ff on =
simplebus0
> intc0:  mem 0x7e00b200-0x7e00b3ff irq 20 =
on simplebus0
> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
22,23 on simplebus0
> gpiobus0:  on gpio0
> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 21 on =
simplebus0
> generic_timer0:  irq 0,1,2,3 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality =
1000
> Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000
> usb_nop_xceiv0:  on ofwbus0
> bcm_dma0:  mem 0x7e007000-0x7e007eff irq =
4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 on simplebus0
> bcmwd0:  mem 0x7e100000-0x7e100027 on =
simplebus0
> bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on =
simplebus0
> bcmrng0:  mem 0x7e104000-0x7e10400f on =
simplebus0
> gpioc0:  on gpio0
> uart0:  mem 0x7e201000-0x7e201fff irq 24 on =
simplebus0
> uart0: console (115200,n,8,1)
> spi0:  mem 0x7e204000-0x7e204fff irq 26 =
on simplebus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> spibus0:  at cs 1 mode 0
> iichb0:  mem 0x7e804000-0x7e804fff irq 37 =
on simplebus0
> bcm283x_dwcotg0:  mem =
0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 43,44 on simplebus0
> usbus1 on bcm283x_dwcotg0
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 46 on simplebus0
> mmc0:  on sdhci_bcm0
> 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.0.
> VT: Replacing driver "efifb" with new "fb".
> fb0: 656x416(656x416@0,0) 32bpp
> fb0: fbswap: 1, pitch 2624, base 0x3eaf0000, screen_size 1091584
> pmu0:  irq 50 on simplebus0
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> bcm2835_cpufreq0:  on cpu0
> cpu1:  on cpulist0
> cpu2:  on cpulist0
> cpu3:  on cpulist0
> gpioled0:  on ofwbus0
> gpioled0:  failed to map pin
> gpioled0:  failed to map pin
> armv8crypto0: CPU lacks AES instructions
> Timecounters tick every 1.000 msec
> iicbus0:  on iichb0
> iic0:  on iicbus0
> usbus1: 480Mbps High Speed USB v2.0
> ugen1.1:  at usbus1
> uhub0 on usbus1
> uhub0:  on =
usbus1
> mmcsd0: 32GB  at mmc0 =
50.0MHz/4bit/65535-block
> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>                   Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
> Instruction Set Attributes 0 =3D 
> Instruction Set Attributes 1 =3D <>
>         Processor Features 0 =3D 
>         Processor Features 1 =3D <>
>      Memory Model Features 0 =3D 
> Trying to mount root from ufs:/dev/da0s2a [rw]...
>      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
> uhub0: 1 port with 1 removable, self powered
> ugen1.2:  at usbus1
> uhub1 on uhub0
> uhub1:  on usbus1
> uhub1: MTT enabled
> Root mount waiting for: usbus1 CAM
> uhub1: 5 ports with 4 removable, self powered
> ugen1.3:  at usbus1
> smsc0 on uhub1
> smsc0:  on usbus1
> smsc0: chip 0xec00, rev. 0002
> miibus0:  on smsc0
> smscphy0:  PHY 1 on miibus0
> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ue0:  on smsc0
> ue0: Ethernet address: b8:27:eb:71:46:4e
> Root mount waiting for: usbus1 CAM
> ugen1.4:  at usbus1
> uhub2 on uhub1
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus1 CAM
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device JMicron SABRENT (0x152d:0x0583)
> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron SABRENT (0x152d:0x0583)
> Root mount waiting for: usbus1 CAM
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  on usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
> umass0:0:0: Attached to scbus0
> ugen1.6:  at usbus1
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 000000000000A
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
> Warning: no time-of-day clock registered, system time will not be set =
accurately
> Dual Console: Serial Primary, Video Secondary
> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
> Setting hostid: 0x5cd40a6a.
> Starting file system checks:
> /dev/da0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/da0s2a: clean, 291525 free (4757 frags, 35846 blocks, 0.6% =
fragmentation)
> /dev/da0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/da0s2d: clean, 225584444 free (104508 frags, 28184992 blocks, =
0.0% fragmentation)

/dev/da0s2a vs. /dev/da0s2d ? But both seem to have worked.

> Mounting local filesystems:.
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib =
/usr/local/lib/compat/pkg /usr/local/lib/compat/pkg =
/usr/local/lib/perl5/5.32/mach/CORE
> Setting hostname: pelorus.zefox.org.
> Setting up harvesting: =
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A=
TTACH,CACHED
> Feeding entropy: .
> lo0: link state changed to UP
> smsc0: chip 0xec00, rev. 0002
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> Starting Network: lo0 ue0.
> lo0: flags=3D8049 metric 0 mtu 16384
>        options=3D680003=

>        inet6 ::1 prefixlen 128
>        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>        inet 127.0.0.1 netmask 0xff000000
>        groups: lo
>        nd6 options=3D21
> ue0: flags=3D8843 metric 0 mtu =
1500
>        options=3D80009
>        ether b8:27:eb:71:46:4e
>        inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
>        media: Ethernet autoselect (100baseTX )
>        status: active
>        nd6 options=3D29
> Starting devd.
> Autoloading module: uftdi.ko
> uftdi0 on uhub1
> uftdi0:  on usbus1
> add host 127.0.0.1: gateway lo0 fib 0: route already in table
> add net default: gateway 50.1.20.1
> add host ::1: gateway lo0 fib 0: route already in table
> add net fe80::: gateway ::1
> add net ff02::: gateway ::1
> add net ::ffff:0.0.0.0: gateway ::1
> add net ::0.0.0.0: gateway ::1
> Clearing /tmp (X related).
> Updating /var/run/os-release done.
> Creating and/or trimming log files.
> Updating motd:.
> Starting syslogd.
> Setting date via ntp.
> 2 Jul 15:05:36 ntpdate[805]: step time server 212.7.1.131 offset =
+1584.319871 sec
> Starting powerd.
> Mounting late filesystems:.
> Starting sendmail.
> Starting sendmail_msp_queue.
> Starting cron.
> Configuring vt: blanktime.
> Performing sanity check on sshd configuration.
> Starting sshd.
> Starting background file system checks in 60 seconds.
>=20
> Sat Jul  2 15:05:44 PDT=20
> FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
>=20
> login:




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul  3 02:42:43 2022
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 479968730FA
	for ; Sun,  3 Jul 2022 02:42:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4LbCsY0YqZz3hn6
	for ; Sun,  3 Jul 2022 02:42:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656816168; bh=6KSZKqK/vhsUNmyax00gUwh9Jbe/mvLv20g3rwCnXss=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=l2/g0/II6v5Q9+QuG/mLtgshHO1p0X3IXDqlkOFdYUxK28X/VrxGgmkFeGVxzDrumjMSjKKnTliZ24HZQNLzjb+JEqkxij7PuQKZ9M4EIKxI+kEVxCuoSa1ko/gvtxqDg5jnaYKD3ZmTI2Vi1AYKOEtSjOiRZEQTH27+gfdAFmYiEGboEmB5rqut8eYLycyRadvhh87osN4fa3HdGPOgVzGyj/zl3E5I3/xnCytv7sVMFmfWYVFEDPjCCYgdQ8g1VeAgxPSL+/Mo6S8dQ1AmfwHjQ618dtdwUfhYWr16KkLxxvmhOnYPWQNqrXMqR3qcXmOqMmiIC+i1sgBQ0OsSUQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656816168; bh=hnzMuUAsGB2W+Nl1TlrWSiDCWZnFyLWGGed05GD4uUs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rHEaSu8LFaZcMGGBiWBVDc2R48Grn9hdHWSC/ib0sjpcPeJXdS1ycDHLY6YdN7Y91H71KMqe6peaESs0PEsAMyiH51L71GYRcqQr8h2eWR86RYe9nczleFyEforFj9Mtyef82zKy0Qmly1nmdyli8HeKylIhcvGWolJULwucM9xoYs9h1btYOPcVIno8Wt3ZR2JjBXY89t+LkZ30CtihDEAGl2SkhfKzlQ4KBvfPrduYkiZ2X72kE1A7NUOBs5sq9hTIg2uP8yLeqZ9wRA84xkctWRbu/eO2iV7V99jwiWhEsWgso3cBZwT/bs7dJHx3HIQ6q+lrh8kPjS/zSbwySQ==
X-YMail-OSG: XAGcaKMVM1kv6zvCivibe18rFfQx1ezenopQKaAY0G1JtxY7nEQg3rV.qQ_R3nk
 KTsPAc.6TnjAdvCa506XP6fPwmUl_HDuzg5avGcKQfixWAC9lDl4x7I44YFO1QYs9_4wA1czghqr
 gntxNNwgyr_kUh8f7zjz7qmDsKwAOahWZH9TcyTCBxXZ6nmNHkvhP57svXeVGZ1FI8ak4WqyvkXS
 qgcE2qx71W6og2T7iiC952MGSYZplNzf.W5Cm6326wF3Z2D4O_BCGLXsUlC39SGJ_XPoGN1d.U8Q
 hEQ8mr0aDGxYA7k7MAxexqnWJZv6pQLcAOp9AEpNo5YKPmBx6sHgSVFykx6Lke2UOwkVoTbB20f9
 xXUvR.8KfsiyHw3uzjCp9UNDECeuX15J6HEhep5gLrh1aRLcDpXTvJMRk8Q9U4_zuHBlELxGCCHt
 u9gpUu2MjJteOeXB1jM5VL.fHMk7RJ2wdl5iP3dfcupYjY4G9CjUYEbnfzWJUIIjyr6joYuLs.bA
 3CRxJ_Vmga891p2qK.qbWXztHk0TOwaN2ACG.3o2XBotc8HkAmRPvxSnCYfdfeJDeUyP3IylLPmr
 PvFWTerFA8553zqmkWz9Mn6ha9Zb.dsceDIBXtjeAhS33tRWTrh8Y4_UiVH4tdvjHDpsTXEPZJjb
 syla6Xkz.DHYnki92qsYWis41DlFmbQ57BmZFuEJFVkzFujIlzAc577Q3CuV8XYUOKaDmZshNalu
 DCDCVu39RnLhdLnjRHT3AyA8bLRvIPPiwQVc_8lX8vQC4Dr3Jeh5hRvHuwzFRqZIXUwaMy1GMr18
 wyCJJD0JsqWhsbFP.EOluT_Qh60SnNR6llwiJlDSQ.7Uv.XWVJJS_p8kup5Rg4Qt0SfxGQZ3oLl9
 t3KSVsg3R67_x9nCiBLBnl39yhaW558zvA_kVRJfOKBXbCA_K06KmDzYDZpOxhFmdIQfJL.1Q2Wo
 txVg_mrTdUA4HdFtV0W39JSPiYzPHvVz5gysBJTwFepKA6wOYpiGQYESFZHNkmfV9rzpEl44o_8r
 PrlHZrIW5seqilKI.Uf4IyzLntIyzE_jIxaUFCK7SuqOtt_g8_IxGpfywcgE0LiGp.hX6RXdZ5pd
 lXA2g1ES7it4oMVHQGzez5e9hfYhzeQ79EF6.iQvvul2ho0ULMcENZzh.IBSe51OYWKDmVeJC3Qr
 qvtOWVv_Lg7OK1Bxqoi3SnKS9QY231fN4OuNHH7gBya7WZ7U.2Qr3CKEKFSUODzTHVTSaRobvVjq
 mwSvxZqIWwKyfpXZAwDqXPFcSbLT26A6NYZ_98bfGsJVwhoQYqv2gfZbEr_Qirr64G7aRFSx.WuB
 I2wLKKrXwS8.SxnfyTcw.0HELzys94lXcT1oootaOKKU9UY1yITBDoxawjnrDJ4HIc4_mDdEUq5c
 2hY_RAwfozSw6SP_F5rH3Tt673psqiTlRMgGyhFymoghNBgm1ivOnhqmVLIAwjlNP7rKzbNouQKU
 sckKU_g4xlaoITXSJ1BItiUYPDz46vqamMFlAHRWDvNjRLOsf.qFjSVNnSqIORwCsY69gSRNxlea
 eoRBenMhdEbF8KYDp1jRWfEY1ObxwjsseSI5I3WR4gE6Zg7xWM25J3VaKISCpXL_ln3rcBZWPjzs
 NfpaPdCR8NDfKGn.QgC8FqfEhOOpmWjFaQB6ta5_oYlFn6rPEsPe9LshZjv1OHgMk7emtR_8AGxE
 ggN40jNThnZbgMBzt6mwy6bGxOcv1cTAVsbvZTKL.hTic3l0jIi20fZ11Lj3nT4MvTRmBSXyQctm
 MGyplC9nijmD7.8OFPT7qVlTJzGdy1kflLroPOcV9TLF9QYe9Hk1vt8Q7IV84MwRjpAV5.hQ70DB
 QuJtXaUQvbO5nUqe4EVaqnHew9gmGnXACIa4.ILMAc0l2vydWwfSblREBc1Z8WXKU2ncGxOzC0Bc
 PxsED6qgb92XU6q_QGezFmGCmOs84VkVyxIDHFSA7M_3Kw7PwX0kmAlwN2qPEU8t82Z1XherY9lm
 XiT3c7mVWWrg0fXwDLD7gc8IX2qLgd5pO8RTXxN0VuL0mGPz8cEs0o7m6gin43.55H5lnK5eN9KS
 goU99RWBrZ863J4vCej4YQWgKrJqhnDrGWXLIJr1geFrAxOvZbu6Rmdx4D_A7fFIBagsCWf6nJxC
 Pkom75..0at30tAVQJjMGo23cRfNMDsnXxzclOML78zO30QKoApe4WI7DME4xVIuRHE5zH4tVdZg
 LG_eVgwahBLn.RiO0mFr_ioaRszQ4WvmAt0fi7yNGaxuuwH6r5iXrRaP9qTPm8zSekS8UpXyjoYI
 Mwg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 Jul 2022 02:42:48 +0000
Received: by hermes--production-ne1-7864dcfd54-kgsw5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 989f70e7b3dea65a4282082d1e658344;
          Sun, 03 Jul 2022 02:42: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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPi3 usb boot hang on stable/13
From: Mark Millard 
In-Reply-To: 
Date: Sat, 2 Jul 2022 19:42:43 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C389C8E-3F44-4F25-BDF4-44313026E2F8@yahoo.com>
References: <20220702165800.GA10701@www.zefox.net>
 <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
 <24D669B0-728D-4910-884A-B2230AE442F9@yahoo.com>
 <20220702222139.GB10701@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LbCsY0YqZz3hn6
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="l2/g0/II";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.18 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email];
	 NEURAL_SPAM_SHORT(0.31)[0.315];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jul-2, at 18:38, Mark Millard  wrote:

> On 2022-Jul-2, at 15:21, bob prohaska  wrote:
>=20
>> On Sat, Jul 02, 2022 at 12:00:02PM -0700, Mark Millard wrote:
>>> On 2022-Jul-2, at 10:34, Mark Millard  wrote:
>>>>>=20
>>>>> Device 0:=20
>>>>=20
>>>> That is U-Boot output. Looks like the output stopped before
>>>> the load of even the FreeBSD loader: FreeBSD is not involved
>>>> yet so it is not a FreeBSD problem.
>>>=20
>>> Hmm. I looked at an old RPI3 boot-session log I have around and
>>> it shows more text than you report. Is your serial connection
>>> having problems? An example that is missing is the line
>>> "U-Boot . . ." that identifies the version and build time
>>> of U-Boot. That is rather generic material to be missing.
>>> (I did not have a microsd card present. Such could be an
>>> example of expected differences.)
>>>=20
>>>=20
>>> There is the difference (yours then mine):
>>>=20
>>> MMC:   mmc@7e300000: 1
>>> vs.
>>> MMC:   mmc@7e300000: 2
>>>=20
>>> I wonder it if is some sort of clue about something.
>>>=20
>>=20
>> It just dawned there are two u-boot instances: One on the microSD,
>> which I think is the "special USB boot" version, which reports
>> U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700)
>=20
> The above is what you are using when you use the microsd
> card. See later.
>=20
>> and a second on the FAT partition of the USB disk, which reports
>> U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000)
>=20
> You are not using the above one when you use the microsd card.
>=20
> You are using the above one if it gets to U-Boot without a
> microsd card present.
>=20
>> Just tried removing the microSD card and issuing shutdown -r now.
>> The console got to "Resetting system..." and stopped.=20
>>=20
>> Put the microSD back in and tried again from the beginning. It looks
>> like the machine starts from microSD and transfers control to u-boot
>> on the USB drive.
>=20
> No: See later.
>=20
>> The USB boot OTP was set IIRC, haven't checked lately.
>> Maybe it's time to reformat and start over.....
>>=20
>> What follows is a fairly typical startup session:
>>=20
>> Resetting system ...=20
>>=20
>>=20
>> Raspberry Pi Bootcode
>>=20
>> Found SD card, config.txt =3D 1, start.elf =3D 1, recovery.elf =3D 0, =
timeout =3D 0
>> Read File: config.txt, 178 (bytes)
>>=20
>>=20
>>=20
>>=20
>> Raspberry Pi Bootcode
>> Read File: config.txt, 178
>> Read File: start.elf, 2835780 (bytes)
>> Read File: fixup.dat, 6639 (bytes)
>> MESS:00:00:01.108743:0: brfs: File read: /mfs/sd/config.txt
>=20
> /mfs/sd/ is the microsd card in your context.
>=20

Note: The above was based on your reporting that the
microsd card was used. If no microsd card was present
and USB was being used, it would still say: /mfs/sd/
as the path prefix. That notation in the RPi* firmware
output just means the boot media used by the RPi*
firmware.

Other than the "just bootcode on the microsd card" alternative,
the RPi* firmware picks one place and gets everything that
it loads from there. Any accesses to other partitions or
media are not by RPi* firmware once the RPi* firmware has made
its pick.

> The above is config.txt being loaded from the microsd card.
>=20
>> MESS:00:00:01.112989:0: brfs: File read: 178 bytes
>> MESS:00:00:01.126707:0: HDMI:EDID error reading EDID block 0 attempt =
0
>> MESS:00:00:01.132784:0: HDMI:EDID error reading EDID block 0 attempt =
1
>> MESS:00:00:01.139029:0: HDMI:EDID error reading EDID block 0 attempt =
2
>> MESS:00:00:01.145279:0: HDMI:EDID error reading EDID block 0 attempt =
3
>> MESS:00:00:01.151529:0: HDMI:EDID error reading EDID block 0 attempt =
4
>> MESS:00:00:01.157779:0: HDMI:EDID error reading EDID block 0 attempt =
5
>> MESS:00:00:01.164029:0: HDMI:EDID error reading EDID block 0 attempt =
6
>> MESS:00:00:01.170279:0: HDMI:EDID error reading EDID block 0 attempt =
7
>> MESS:00:00:01.176529:0: HDMI:EDID error reading EDID block 0 attempt =
8
>> MESS:00:00:01.182779:0: HDMI:EDID error reading EDID block 0 attempt =
9
>> MESS:00:00:01.188792:0: HDMI:EDID giving up on reading EDID block 0
>> MESS:00:00:01.206550:0: brfs: File read: /mfs/sd/config.txt
>=20
> The above is config.txt (again!) being loaded from the microsd card.
>=20
>> MESS:00:00:01.210671:0: HDMI:Setting property pixel encoding to =
Default
>> MESS:00:00:01.216761:0: HDMI:Setting property pixel clock type to PAL
>> MESS:00:00:01.222920:0: HDMI:Setting property content type flag to No =
data
>> MESS:00:00:01.229520:0: HDMI:Setting property fuzzy format match to =
enabled
>> MESS:00:00:01.236297:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK =
not defined
>> MESS:00:00:01.439246:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK =
not defined
>> MESS:00:00:01.445328:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
>> MESS:00:00:01.453811:0: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading =
EDID<<<<<<<<<<<<<
>> MESS:00:00:01.461557:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 0
>> MESS:00:00:01.469289:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 1
>> MESS:00:00:01.476056:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 2
>> MESS:00:00:01.482826:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 3
>> MESS:00:00:01.489597:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 4
>> MESS:00:00:01.496368:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 5
>> MESS:00:00:01.503138:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 6
>> MESS:00:00:01.509910:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 7
>> MESS:00:00:01.516681:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 8
>> MESS:00:00:01.523451:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 9
>> MESS:00:00:01.529985:0: hdmi: HDMI:EDID giving up on reading EDID =
block 0
>> MESS:00:00:01.535499:0: hdmi: HDMI: No lookup table for resolution =
group 0
>> MESS:00:00:01.542084:0: hdmi: HDMI: hotplug attached with DVI support
>> MESS:00:00:01.548262:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
>> MESS:00:00:01.557298:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 0
>> MESS:00:00:01.565030:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 1
>> MESS:00:00:01.571802:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 2
>> MESS:00:00:01.578573:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 3
>> MESS:00:00:01.585343:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 4
>> MESS:00:00:01.592115:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 5
>> MESS:00:00:01.598886:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 6
>> MESS:00:00:01.605656:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 7
>> MESS:00:00:01.612427:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 8
>> MESS:00:00:01.619198:0: hdmi: HDMI:EDID error reading EDID block 0 =
attempt 9
>> MESS:00:00:01.625732:0: hdmi: HDMI:EDID giving up on reading EDID =
block 0
>> MESS:00:00:01.631505:0: hdmi: HDMI: hotplug deassert
>> MESS:00:00:01.635919:0: hdmi: HDMI: HDMI is currently off
>> MESS:00:00:01.641039:0: hdmi: HDMI: changing mode to unplugged
>> MESS:00:00:01.646605:0: hdmi: HDMI:hdmi_get_state is deprecated, use =
hdmi_get_display_state instead
>> MESS:00:00:01.656008:0: *** Restart logging
>> MESS:00:00:01.659280:0: brfs: File read: 178 bytes
>> MESS:00:00:01.665054:0: Failed to open command line file =
'cmdline.txt'
>> MESS:00:00:01.672773:0: brfs: File read: /mfs/sd/armstub8.bin
>=20
> The above is armstub8.bin being loaded from the microsd card.
>=20
>> MESS:00:00:01.676824:0: Loading 'armstub8.bin' to 0x0 size 0x1700
>> MESS:00:00:01.682667:0: brfs: File read: 5888 bytes
>> MESS:00:00:01.718268:0: brfs: File read: /mfs/sd/u-boot.bin
>=20
> The above is u-boot.bin being loaded from the microsd card.
>=20
>> MESS:00:00:01.722146:0: Loading 'u-boot.bin' to 0x80000 size 0x7a2d8
>> MESS:00:00:01.731830:0: No kernel trailer - assuming DT-capable
>> MESS:00:00:01.736078:0: brfs: File read: 500440 bytes
>> MESS:00:00:01.743877:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
>=20
> The above is bcm2710-rpi-3-b.dtb being loaded from the microsd card.
>=20
>> MESS:00:00:01.748535:0: Loading 'bcm2710-rpi-3-b.dtb' to 0xfa2d8 size =
0x5f12
>> MESS:00:00:01.889271:0: brfs: File read: 24338 bytes
>> MESS:00:00:01.892986:0: brfs: File read: /mfs/sd/config.txt
>=20
> The above is config.txt (again!) being loaded from the microsd card.
>=20
>> MESS:00:00:01.897876:0: dtparam: audio=3Don
>> MESS:00:00:01.919689:0: dtparam: i2c_arm=3Don
>> MESS:00:00:01.938056:0: dtparam: spi=3Don
>> MESS:00:00:01.954303:0: brfs: File read: 178 bytes
>> MESS:00:00:01.959758:0: brfs: File read: /mfs/sd/overlays/mmc.dtbo
>=20
> The above is overlays/mmc.dtbo being loaded from the microsd card.
>=20
>> MESS:00:00:01.981176:0: Loaded overlay 'mmc'
>> MESS:00:00:02.030370:0: brfs: File read: 1099 bytes
>> MESS:00:00:02.034426:0: brfs: File read: /mfs/sd/overlays/pwm.dtbo
>=20
> The above is overlays/pwm.dtbo being loaded from the microsd card.
>=20
>> MESS:00:00:02.051824:0: Loaded overlay 'pwm'
>> MESS:00:00:02.087719:0: brfs: File read: 946 bytes
>> MESS:00:00:02.091725:0: brfs: File read: =
/mfs/sd/overlays/pi3-disable-bt.dtbo
>=20
> The above is overlays/pi3-disable-bt.dtbo being loaded from the =
microsd card.
>=20
>> MESS:00:00:02.115336:0: Loaded overlay 'pi3-disable-bt'
>> MESS:00:00:03.175615:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE =
not defined
>> MESS:00:00:03.287931:0: Device tree loaded to 0x4000 (size 0x63cd)
>> MESS:00:00:03.293589:0: uart: Set PL011 baud rate to 103448.300000 Hz
>> MESS:00:00:03.300125:0: uart: Baud rate change done...
>> MESS:00:00:03.303554:0: uart: Baud rate change done...
>> MESS:00:00:03.309236:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined
>=20
> There is missing text from U-Boot here.
>=20
> But the below is from the U-Boot on the microsd card.
> Try renaming it, copying an alternative version,
> and seeing what it does? Repeat . . . ?
>=20
>> MMC:   mmc@7e300000: 1
>> Loading Environment from FAT... OK
>> In:    serial
>> Out:   vidconsole
>> Err:   vidconsole
>> Net:   No ethernet found.
>> starting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> Hit any key to stop autoboot:  0=20
>>=20
>> Device 0: unknown device
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot> power-cycled hub
>> Unknown command 'power-cycled' - try 'help'
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot> editenv usb_pgood_delay
>> edit: 3200
>> U-Boot> editenv usb_pgood_delay
>> edit: 19000
>>=20
>> [saveenv results in "saving to FAT failed"]
>>=20
>> U-Boot> usb reset
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 0 Storage Device(s) found
>> U-Boot>=20
>> resetting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>>      scanning usb for storage devices... 1 Storage Device(s) found
>> U-Boot> boot =20
>>=20
>> Device 0: Vendor: SABRENT  Rev: 1214 Prod:=20
>>           Type: Hard Disk
>>           Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
>> ... is now current device
>> Scanning usb 0:1...
>> Found EFI removable media binary efi/boot/bootaa64.efi
>=20
> The path is not explicit enough to directly indicate the
> microsd card vs. the USB drive. But the above is one
> of the (possibly) 2 FreeBSD loaders you have in your
> environment.
>=20
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>> Scanning disk mmc@7e300000.blk...
>> Scanning disk usb_mass_storage.lun0...
>> Found 5 disks
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>> 1259212 bytes read in 676 ms (1.8 MiB/s)
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>=20
>> [whitespace omitted]
>=20
> The below is from one of the FreeBSD loaders.
>=20
>> Consoles: EFI console =20
>>   Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk1p1:
>> FreeBSD/arm64 EFI loader, Revision 1.1
>>=20
>>  Command line arguments: loader.efi
>>  Image base: 0x39e06000
>>  EFI version: 2.80
>>  EFI Firmware: Das U-Boot (rev 8217.4096)
>>  Console: comconsole (0)
>>  Load Path: /efi\boot\bootaa64.efi
>>  Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(1,MBR,0x76573018,0x81f,0x18fa8)
>> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(1,MBR,0x76573018,0x81f,0x18fa8)
>> Setting currdev to disk1p1:
>> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x5e3,0x610,0x9,0x0,0x1)/UsbC=
lass(0x152d,0x583,0x0,0x0,0x0)/HD(2,MBR,0x76573018,0x197c7,0x746ed5e9)
>> Setting currdev to disk1p2:
>=20
> "disk1p2:" is from the USB drive (based on the long line before it).
>=20
> I expect that this means that the FreeBSD loader was also from
> the USB drive.
>=20
>> Loading /boot/defaults/loader.conf
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> Loading kernel...
>> /boot/kernel/kernel text=3D0x2a8 text=3D0x89ef40 text=3D0x1fb30c =
data=3D0x1a9358 data=3D0x0+0x2a8000 syms=3D[0x8+0x121740+0x8+0x1454aa]
>> Loading configured modules...
>> /boot/kernel/filemon.ko text=3D0x1574 text=3D0x272c data=3D0x500+0x20 =
syms=3D[0x8+0xcd8+0x8+0x7c5]
>> /boot/kernel/umodem.ko text=3D0x2160 text=3D0x1400 data=3D0x6e8+0x10 =
syms=3D[0x8+0xf48+0x8+0xb75]
>> loading required module 'ucom'
>> /boot/kernel/ucom.ko text=3D0x249f text=3D0x3360 data=3D0x8a0+0x858 =
syms=3D[0x8+0x1188+0x8+0xb19]
>> /boot/entropy size=3D0x1000
>> /etc/hostid size=3D0x25
>>=20
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]...              =20
>> Using DTB provided by EFI at 0x7ef6000.
>> EFI framebuffer information:
>> addr, size     0x3eaf0000, 0x10a800
>> dimensions     656 x 416
>> stride         656
>> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>> ---<>---
>=20
> This is about where the kernel output starts.
>=20
>> WARNING: Cannot find freebsd,dts-version property, cannot check DTB =
compliance
>=20
> The dtb files used do not have freebsd specific content. As I
> understand, for RPi*'s, the above is expected.
>=20
>> Copyright (c) 1992-2021 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 13.1-STABLE #5 stable/13-n251597-7c500f98b8d: Fri Jul  1 =
21:52:12 PDT 2022
>>   bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64
>> FreeBSD clang version 14.0.5 =
(https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
>> VT(efifb): resolution 656x416
>> module firmware already present!
>> real memory  =3D 993988608 (947 MB)
>> avail memory =3D 947646464 (903 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
>> MAP 39f42000 mode 2 pages 1
>> MAP 39f4d000 mode 2 pages 1
>> MAP 3b350000 mode 2 pages 16
>> MAP 3f100000 mode 0 pages 1
>> kbd0 at kbdmux0
>> ofwbus0: 
>> simplebus0:  on ofwbus0
>> ofw_clkbus0:  on ofwbus0
>> clk_fixed0:  on ofw_clkbus0
>> clk_fixed1:  on ofw_clkbus0
>> regfix0:  on ofwbus0
>> regfix1:  on ofwbus0
>> bcm2835_firmware0:  on simplebus0
>> psci0:  on ofwbus0
>> lintc0:  mem 0x40000000-0x400000ff on =
simplebus0
>> intc0:  mem 0x7e00b200-0x7e00b3ff irq =
20 on simplebus0
>> gpio0:  mem 0x7e200000-0x7e2000b3 irq =
22,23 on simplebus0
>> gpiobus0:  on gpio0
>> mbox0:  mem 0x7e00b880-0x7e00b8bf irq 21 =
on simplebus0
>> generic_timer0:  irq 0,1,2,3 on ofwbus0
>> Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality =
1000
>> Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality =
1000
>> usb_nop_xceiv0:  on ofwbus0
>> bcm_dma0:  mem 0x7e007000-0x7e007eff irq =
4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 on simplebus0
>> bcmwd0:  mem 0x7e100000-0x7e100027 on =
simplebus0
>> bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on =
simplebus0
>> bcmrng0:  mem 0x7e104000-0x7e10400f on =
simplebus0
>> gpioc0:  on gpio0
>> uart0:  mem 0x7e201000-0x7e201fff irq 24 on =
simplebus0
>> uart0: console (115200,n,8,1)
>> spi0:  mem 0x7e204000-0x7e204fff irq 26 =
on simplebus0
>> spibus0:  on spi0
>> spibus0:  at cs 0 mode 0
>> spibus0:  at cs 1 mode 0
>> iichb0:  mem 0x7e804000-0x7e804fff irq =
37 on simplebus0
>> bcm283x_dwcotg0:  =
mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 43,44 on simplebus0
>> usbus1 on bcm283x_dwcotg0
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 46 on simplebus0
>> mmc0:  on sdhci_bcm0
>> 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.0.
>> VT: Replacing driver "efifb" with new "fb".
>> fb0: 656x416(656x416@0,0) 32bpp
>> fb0: fbswap: 1, pitch 2624, base 0x3eaf0000, screen_size 1091584
>> pmu0:  irq 50 on simplebus0
>> cpulist0:  on ofwbus0
>> cpu0:  on cpulist0
>> bcm2835_cpufreq0:  on cpu0
>> cpu1:  on cpulist0
>> cpu2:  on cpulist0
>> cpu3:  on cpulist0
>> gpioled0:  on ofwbus0
>> gpioled0:  failed to map pin
>> gpioled0:  failed to map pin
>> armv8crypto0: CPU lacks AES instructions
>> Timecounters tick every 1.000 msec
>> iicbus0:  on iichb0
>> iic0:  on iicbus0
>> usbus1: 480Mbps High Speed USB v2.0
>> ugen1.1:  at usbus1
>> uhub0 on usbus1
>> uhub0:  on =
usbus1
>> mmcsd0: 32GB  at mmc0 =
50.0MHz/4bit/65535-block
>> bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
>> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>>                  Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
>> Instruction Set Attributes 0 =3D 
>> Instruction Set Attributes 1 =3D <>
>>        Processor Features 0 =3D 
>>        Processor Features 1 =3D <>
>>     Memory Model Features 0 =3D 
>> Trying to mount root from ufs:/dev/da0s2a [rw]...
>>     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
>> uhub0: 1 port with 1 removable, self powered
>> ugen1.2:  at usbus1
>> uhub1 on uhub0
>> uhub1:  on usbus1
>> uhub1: MTT enabled
>> Root mount waiting for: usbus1 CAM
>> uhub1: 5 ports with 4 removable, self powered
>> ugen1.3:  at usbus1
>> smsc0 on uhub1
>> smsc0:  on =
usbus1
>> smsc0: chip 0xec00, rev. 0002
>> miibus0:  on smsc0
>> smscphy0:  PHY 1 on miibus0
>> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0:  on smsc0
>> ue0: Ethernet address: b8:27:eb:71:46:4e
>> Root mount waiting for: usbus1 CAM
>> ugen1.4:  at usbus1
>> uhub2 on uhub1
>> uhub2:  on =
usbus1
>> uhub2: 4 ports with 4 removable, self powered
>> Root mount waiting for: usbus1 CAM
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device JMicron SABRENT (0x152d:0x0583)
>> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron SABRENT (0x152d:0x0583)
>> Root mount waiting for: usbus1 CAM
>> ugen1.5:  at usbus1
>> umass0 on uhub2
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
>> umass0:0:0: Attached to scbus0
>> ugen1.6:  at usbus1
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 000000000000A
>> da0: 40.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>> Warning: no time-of-day clock registered, system time will not be set =
accurately
>> Dual Console: Serial Primary, Video Secondary
>> Setting hostuuid: 30303030-3030-3030-3064-626136386435.
>> Setting hostid: 0x5cd40a6a.
>> Starting file system checks:
>> /dev/da0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/da0s2a: clean, 291525 free (4757 frags, 35846 blocks, 0.6% =
fragmentation)
>> /dev/da0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/da0s2d: clean, 225584444 free (104508 frags, 28184992 blocks, =
0.0% fragmentation)
>=20
> /dev/da0s2a vs. /dev/da0s2d ? But both seem to have worked.
>=20
>> Mounting local filesystems:.
>> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib =
/usr/local/lib/compat/pkg /usr/local/lib/compat/pkg =
/usr/local/lib/perl5/5.32/mach/CORE
>> Setting hostname: pelorus.zefox.org.
>> Setting up harvesting: =
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A=
TTACH,CACHED
>> Feeding entropy: .
>> lo0: link state changed to UP
>> smsc0: chip 0xec00, rev. 0002
>> ue0: link state changed to DOWN
>> ue0: link state changed to UP
>> Starting Network: lo0 ue0.
>> lo0: flags=3D8049 metric 0 mtu 16384
>>       options=3D680003=

>>       inet6 ::1 prefixlen 128
>>       inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>>       inet 127.0.0.1 netmask 0xff000000
>>       groups: lo
>>       nd6 options=3D21
>> ue0: flags=3D8843 metric 0 =
mtu 1500
>>       options=3D80009
>>       ether b8:27:eb:71:46:4e
>>       inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
>>       media: Ethernet autoselect (100baseTX )
>>       status: active
>>       nd6 options=3D29
>> Starting devd.
>> Autoloading module: uftdi.ko
>> uftdi0 on uhub1
>> uftdi0:  on usbus1
>> add host 127.0.0.1: gateway lo0 fib 0: route already in table
>> add net default: gateway 50.1.20.1
>> add host ::1: gateway lo0 fib 0: route already in table
>> add net fe80::: gateway ::1
>> add net ff02::: gateway ::1
>> add net ::ffff:0.0.0.0: gateway ::1
>> add net ::0.0.0.0: gateway ::1
>> Clearing /tmp (X related).
>> Updating /var/run/os-release done.
>> Creating and/or trimming log files.
>> Updating motd:.
>> Starting syslogd.
>> Setting date via ntp.
>> 2 Jul 15:05:36 ntpdate[805]: step time server 212.7.1.131 offset =
+1584.319871 sec
>> Starting powerd.
>> Mounting late filesystems:.
>> Starting sendmail.
>> Starting sendmail_msp_queue.
>> Starting cron.
>> Configuring vt: blanktime.
>> Performing sanity check on sshd configuration.
>> Starting sshd.
>> Starting background file system checks in 60 seconds.
>>=20
>> Sat Jul  2 15:05:44 PDT=20
>> FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
>>=20
>> login:
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul  3 15:51:26 2022
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 4F9DE8ADC3C
	for ; Sun,  3 Jul 2022 15:54:10 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LbYQT190Nz4cTP
	for ; Sun,  3 Jul 2022 15:54:09 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 263FpQEQ049745
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 3 Jul 2022 08:51:26 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 263FpQTn049744;
	Sun, 3 Jul 2022 08:51:26 -0700 (PDT)
	(envelope-from warlock)
Date: Sun, 3 Jul 2022 08:51:26 -0700
From: John Kennedy 
To: David Cornejo 
Cc: freebsd-arm@freebsd.org
Subject: Re: RPI4 + ntpdate + unbound
Message-ID: 
References: 
 
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: 4LbYQT190Nz4cTP
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.65 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.964];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.997];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.89)[-0.893];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 01, 2022 at 10:49:33PM -1000, David Cornejo wrote:
> I always hated this about the RPIs - I put a DS3231 on mine and the
> problem disappears. ...

  Yeah.  Not sure where Eben would cram it (much less the battery), but
one of these days his form factor needs to expand a bit.  But with what
I do with the RPI4 it runs hot, so I've got a good passive case, but
this one hides the GPIO pins entirely and the active-cooling one I'm
looking at is a big chunk of aluminum + fans, which means some pretty
significant risers/headers to get it to clear the heatsink and some
contention with the PWR/GRD pins to power the fan.

  Haven't dug into what RTC driver FreeBSD may support to see where I
can stick the RTC.  I do want one, just not seeing options that jump out
at me.


From nobody Sun Jul  3 17:55:11 2022
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 DC23A8A7540
	for ; Sun,  3 Jul 2022 17:55:14 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230])
	(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 4Lbc6B2fLNz4qkB
	for ; Sun,  3 Jul 2022 17:55:14 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Received: by mail-oi1-x230.google.com with SMTP id s188so10165310oib.6
        for ; Sun, 03 Jul 2022 10:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=iitbombay-org.20210112.gappssmtp.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=7yLB5ZOjJohcpq+VykeJB0xPN24/yHa2zHF0ZyWmqxE=;
        b=jj4iBkQ0xeLnR+TD3WqsjdhSAbRVgv8IQqm49RKK0kMk97yEm47phAeTRrma8EHVbt
         C8De0dfPyYqqylRoTR2UiYpv9IpGEf0yWgtpS3h/Px/qQW+xVBZOkEWK8sM7Edi17wk7
         HM9TscNaTCxcgQPQrCmpdEmL4z3kJcnrcgHJutWTZ3LK6zoMrAEyMc6JwD8Wb2SDzER3
         gIIC1a2l7BtIjTkR0wqnIoLo9bvX+4LZ241GbtJY1DqbWQv0F6IUVIPABxhY8vvfbpcb
         97qA86AknPfkGKW5RFuyrEKJss6Zhf7T1FCRakrrN4RMybHJpJFsUdSnL+G6No5SyRKj
         coHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=7yLB5ZOjJohcpq+VykeJB0xPN24/yHa2zHF0ZyWmqxE=;
        b=pdQ8yEq6svyY4NbF7gx0KTK4++E/hrsIbAe0J0wofFxRXlkxuKOQBWjLirUs5z16W0
         YLhtI8DKZl0R/xUFP+LdxdGJB9wwJHWl5afpXhEZCDk97tfL5u0ApGX+gUXiud/JfNnf
         RHVUasihnqRA7WPLbUl435XIcF9gvagh7i0f7x3EPq1LSa1aUafnm87Ty5wuh7uKxVus
         fYP7zzDaGJ12ixDmB6te44gUqoTVgx4cGw5xk5/dFvoJWc6C81lA+AuaFnXVzcSS2xyQ
         eu4/5mNh08Ko/uO3Tkec743K8fVXq+xu7chXKtXnnLJXa6o39H7wE9pO7IFcrlcZm9Ck
         ltrw==
X-Gm-Message-State: AJIora81/3RZ97cAE18K3dvwbQh2cRI9bCSyDgNVKNySpbX1C5l0RKAV
	4PzvTu1l78yO467UI9gTFADerfFKmJY0eA==
X-Google-Smtp-Source: AGRyM1tsEQruUHKIQKJhO80jXDM2dC7t1/yR+VgUCJkvZQReejhz8wV6JnKUWBDOJwK6oHkaImi2WQ==
X-Received: by 2002:a05:6808:e87:b0:32e:3cfb:fad7 with SMTP id k7-20020a0568080e8700b0032e3cfbfad7mr15792920oil.197.1656870913740;
        Sun, 03 Jul 2022 10:55:13 -0700 (PDT)
Received: from smtpclient.apple (99-8-241-158.lightspeed.snantx.sbcglobal.net. [99.8.241.158])
        by smtp.gmail.com with ESMTPSA id a14-20020a05687073ce00b0010be09dc797sm1865458oan.18.2022.07.03.10.55.12
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 03 Jul 2022 10:55:13 -0700 (PDT)
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 \(3696.100.31\))
Subject: Re: RPI4 + ntpdate + unbound
From: Bakul Shah 
In-Reply-To: 
Date: Sun, 3 Jul 2022 12:55:11 -0500
Cc: David Cornejo ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4Lbc6B2fLNz4qkB
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=jj4iBkQ0;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::230 as permitted sender) smtp.mailfrom=bakul@iitbombay.org
X-Spamd-Result: default: False [-2.36 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112];
	 FREEFALL_USER(0.00)[bakul];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[iitbombay.org];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-0.36)[-0.360];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::230:from];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On Jul 3, 2022, at 10:51 AM, John Kennedy  wrote:
> 
> On Fri, Jul 01, 2022 at 10:49:33PM -1000, David Cornejo wrote:
>> I always hated this about the RPIs - I put a DS3231 on mine and the
>> problem disappears. ...
> 
>  Yeah.  Not sure where Eben would cram it (much less the battery), but
> one of these days his form factor needs to expand a bit.  But with what
> I do with the RPI4 it runs hot, so I've got a good passive case, but
> this one hides the GPIO pins entirely and the active-cooling one I'm
> looking at is a big chunk of aluminum + fans, which means some pretty
> significant risers/headers to get it to clear the heatsink and some
> contention with the PWR/GRD pins to power the fan.
> 
>  Haven't dug into what RTC driver FreeBSD may support to see where I
> can stick the RTC.  I do want one, just not seeing options that jump out
> at me.

A USB based GPS/GNSS dongle can be had for about $10. It will use up
one USB port + more power + its antenna needs to be near a window but
this might be the easiest way to get realtime on a Pi with no exposed
GPIO pins. You may even be able to run as a stratum-1 NTP server!


From nobody Sun Jul  3 18:22:29 2022
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 C7F0E8AB950
	for ; Sun,  3 Jul 2022 18:22:35 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lbcjl03p5z4tYb
	for ; Sun,  3 Jul 2022 18:22:34 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1656872551;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=FvDrQ4Giq5t1XwRIJFEaV7AhRJ6V/BGu1z/Mq1WCmaY=;
    b=JxNvA/mQxUshK6BJTnCrQdlBtyXMpCaENwprD6SbYWrbhQpJgDrEeSGKZU1hDlkqIj
    Jfrt0TTJkSLKGWGJ+27i9KzxaBXNIqPFkczwUKmtm96Vib18Z0gTvwg5NCeotknZ+7jI
    GtIqKLlwzumE+Xp8Pmywjz1paa4R7n5nWWOVfFdU/jGQtmLCzRwsJE/SgvVEQ34Y/qhY
    aSNvKjKn/Ls35uCBejy2OVSSMxlDZ/cnSJikQKeBX8QHhg1tf8r5+Juc9SCQ7Jj2NR7u
    ZZBBGDdSV6/og6BAg5h4WYamKNziedWWIhl82Lkga8CyXxqQUVtarWMysI1Favx6HnbW
    kOdA==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y63IMVAzd
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Sun, 3 Jul 2022 20:22:31 +0200 (CEST)
Received: from rolf-mini.obsigna.com (200-207-179-239.dial-up.telesp.net.br [200.207.179.239])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 713FC63847;
	Sun,  3 Jul 2022 20:22:30 +0200 (CEST)
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 12.4 \(3445.104.15\))
Subject: Re: RPI4 + ntpdate + unbound
From: "Dr. Rolf Jansen" 
In-Reply-To: 
Date: Sun, 3 Jul 2022 15:22:29 -0300
Cc: David Cornejo ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lbcjl03p5z4tYb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b="JxNvA/mQ";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.21 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-1.95 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24:c];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[cyclaero.com];
	 NEURAL_HAM_LONG(-0.95)[-0.954];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[cyclaero.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 RCVD_IN_DNSWL_NONE(0.00)[85.215.255.21:from];
	 FROM_NAME_HAS_TITLE(1.00)[dr];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[200.207.179.239:received]
X-ThisMailContainsUnwantedMimeParts: N

> Am 03.07.2022 um 12:51 schrieb John Kennedy :
>=20
> On Fri, Jul 01, 2022 at 10:49:33PM -1000, David Cornejo wrote:
>> I always hated this about the RPIs - I put a DS3231 on mine and the
>> problem disappears. ...
>=20
> Yeah.  Not sure where Eben would cram it (much less the battery), but
> one of these days his form factor needs to expand a bit.  But with =
what
> I do with the RPI4 it runs hot, so I've got a good passive case, but
> this one hides the GPIO pins entirely and the active-cooling one I'm
> looking at is a big chunk of aluminum + fans, which means some pretty
> significant risers/headers to get it to clear the heatsink and some
> contention with the PWR/GRD pins to power the fan.
>=20
> Haven't dug into what RTC driver FreeBSD may support to see where I
> can stick the RTC.  I do want one, just not seeing options that jump =
out
> at me.

Before this just ended weekend, I would have recommended the DS3231 as =
well, because it is working very well on my BeagleBone's Black for years =
now. It is very well documented and FreeBSD comes with a kernel module =
for it. Beginning on last Friday I started with FreeBSD 13.1-RELEASE on =
a brand new RPi 4 B 2 GB, and with that one, attaching the DS3231 became =
a major hassle.

Here is the whole story:
  =
https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html

On 19.02.2022 6:01, Brian Scott wrote:
> The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to=20=

> unilaterally claim anything at address 68. It doesn't understand the=20=

> DS3231 and fails to operate properly, but in claiming the device, the=20=

> ds3231 driver doesn't get a chance. This is compounded by the MAX77620=20=

> driver being compiled into the kernel by default so the loadable =
module=20
> doesn't get to try until after the wrong driver has claimed it.

As suggested by Brian Scott, I compiled a custom kernel without the =
NVIDIA Tegra option. Only, with that custom kernel my RPi 4 (0xb03115) =
stuck at boot right before mounting the system partition. Then I =
switched to FreeBSD 14.0-CURRENT in which the problem has been resolved, =
and with that my RPi and the DS3231 is properly working.

I got this one: =
https://produto.mercadolivre.com.br/MLB-971284468-ds3231-shield-relogio-te=
mpo-real-arduino-rtc-eeprom-at24c32-_JM

If you have a close look at the picture, you can see that I would have =
been able to change its address, by soldering the address pads A0, A1 =
and A2 respectively. Perhaps, I should have done this, since I would =
have liked to stay with RELEASE instead of CURRENT.

The DTS code for the DS3231 is given in said thread on the mailing list. =
Using the dtc utility, I compiled a .dtbo and placed it into =
/boot/msdos/overlays as ds3231-rpi4.dtbo. Then I added two lines to =
/boot/msdos/config.txt:

  gpio=3D2,3=3Da0
  dtoverlay=3Dds3231-rpi4

It is working now, but the operation felt like pulling teeth at the =
dentists. I am still surprised why we get the NVIDIA Tegra compiled in =
the kernel of a 13.1-RELEASE SD card image which according to its file =
name is destined to the Raspberry Pi's.


From nobody Sun Jul  3 19:11:31 2022
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 3D34F8B165C
	for ; Sun,  3 Jul 2022 19:11:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4LbdpQ0XvXz3FG1
	for ; Sun,  3 Jul 2022 19:11:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656875495; bh=nmKBsbdSUzFbxuF5/uC+2aown9w9860QFpg5jzSW5oQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Km6i25xJLccyFhLV5gddEKtEJuvG+HrOPBoCWEoJOJ1Gg1mIlp4JvwWg0PMrw4gQPfArrE71I53VXJmzuX+Wwr/9Vi96xKRgNG5+wEUUURFYCEo7z2nicdO5JBwSRFZHl21lBtyVJcJQ6YyW+0QIz9gSUr4FYRBgBNoQp40YAtiwzTHww4PfJpiWTxEY4gwbj2qKZpIZjTvGaG53AMQEopF7YQWyLCtgN6Dvep2P4akqZjKuV4ZUOwTYoI6nRIw0wPfVKChDqAtTM3KdGmDYp2nFofRR/cPTXP/RNdf1zdT8gj5PZGE5pt8+5Mk35ktT3mEJfzwncBhyoyrUnTKz5g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656875495; bh=Nk1Xh1AnI7XQ4/DelTXMMDDSReCnt+2i2RtTZAKWzDH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pL91ppxMucoyzywYlAfTKZOV7qDJF8vdMfDn/xzf0QwxOTsXvv5oaFI7GrT4pppsbMQYMP7smx8dvFlAiLwFpSjU19WTXUSIuvAt+oYjKb/42qMmlyNhn6jJxLv0GVI4gUz84oacaGNsSJDG/XEqpRgYrvN0PZhvuNWyix8aihbA/1bp/gh5CJAUfFo5jwWy/phGZxImy/YnzDfye3wfsAdw4ZGFJBEJdtwGEj1Txb/Optr4Q+uiyHDR6XiTBz8BxVslYLsgs+Izli3lLTzDClx4h1Da7fB3l3xD9KXncNCDnnhikD5XmjJLruJ3QOW2/+ZB5ZvesUsZ8r3jeeZg7w==
X-YMail-OSG: sEYBRsIVM1mDrHfN7T3u3i5G78jkg6OUWb_2W5r70Vg2JWttGcDzxgMLazvOYh.
 zRX1qkAt_26GcfKpSlBn04iYO3I3BHJ5DNzAHfgTw1IgYgGPuOD_l8E2uZULJRnuSDyqtIpjZI1j
 oI0e2yOCH6_BWnIoEWLu6tCIqa324GhkvkclVBB6wSDEmnUQyFRlczbJThtCXyArUus9Y29u_3F1
 5vP9oHNcoKfh9Bol.BDqB_gmQgo4xi095dOWwijZ6vlyf5B62RUxjWG4_tS3.J3PbObznMc2u8QI
 GScGGQDQmJxTgBEKwZbpKejlAR95vzIKtzGMk9BBpr11AQDUZjlyuc1ewQdtstFQJ1uqNzGs0McZ
 dp.yDilOkxlyddO5D.EYLp7kKz9QgGRZM2RsL.EqJ3JxUi_t5L62Y6IAAKdEm8phuXqWwh6MAZGa
 tJSANxQ_0gfdrQyFvPLq2CA87B5DUI6DdDETZzYrgxTEEThJ0WAigxWSVHuQaQyWH29AtKWD_EOW
 ZoxFwlx41PHdapnI6Du8OutlTIwLxLKg13DXPDtjzCQXA5LGPH1j4.y1XqTnW.FFvR5dHGOqYCwg
 UlZvnbP6PcM5FaoucDLMA12GiGVkXzO_UTE0CRGBdZV4vXdVvnRdqc_fEoGtXD5f7VLcuKOaDpj4
 FwSQ3MMBvBQASfBQcQ7_FJcX.sOm7W3yJgsGe9AHcWW7KHukaAyOf3fW_QybD4zfwhkvMUL.te_v
 72H3B7FKR8xFmcnt_aCRNJoTzsZMmpn7lO5po68ayWDBqWkM9KvqvDwQNBeSUXG3PB3LGBkk7iH.
 4wz3DJrTvkMdnCMlsloifql2b6hrYtA5joxqPtY3W77dBOlRGfHMPNXbujtPcgJXFrI3pOBORGI6
 QsqgLP_ydYyHD_G2r7hFA7PCVI06N5EFh9w907fMFPIVqfDvQGTrkhb1eVDV5vmFzU_LvqSlPsaL
 0v0qoPFzLbl992zrMp9ZyyK.atG3vxJDB63r87fUttBEfEhJJozkSE3BxX2pFG6misZdAXmOz4u_
 8Rr80TYcqC0mmpwZKSHk0FDKa5LzX5Yak14QDebo6MhmRxY_ZZbGe8mupQxRyOGZG807FSekFN6F
 e6R8E21Kb29iYS616.cxJVmakWkr2gh8D7ReaZZdn8Z_ufkduWvRPppwTJOd3zjxzIMg88DqXN4w
 R9Zb2JIkV20tPLv6Shly1jBFFEovQIlX2ejPagLR4GgtBEqqsOR_CWFegccrlihixv_UUM81whjy
 oVP.pRAWP4KvbLJS4.egaqza0xqCYN23MIJT7PXVLJ0UJDoOglEk86oi2nQnmFtkbACHUz9VhWSt
 b0aAp9z6txDCkDOSghnws.eeS01uoD0ByChrTbvj8hPprSCXP59J16pbe8r4TQrUGLRrScbXd_R1
 iQrbRlD0u4qyCHqqoWrMzgQXVL3fK5nATyoupIGTmKDVcN5b5815maEiikZ6vHEfvyCC5HCc2Ecc
 k_ojUGIVIFGX2x3vO4Mlrb0XpQfBvVjykh9y9zhwPLEbmKmdYQSXJEN6ASV8wTxpdnMdhB9BK0WA
 yYl9V_ao9expXKngBIc05wd2unNxNgYBKk8m4VZKY_kKi2P6UjSlFYZJNGzN0bdbQ9d_jkEYDQTu
 QnjwcrE1He32Gub_GZGCLYBreLbuFaC.yxrs0aWWjGOUUlUbV2yavp0gKoxaSoAIWS8TlXkk2WxX
 Z2lk4l7otoPdsHulvVPsj7uk2288F2ZETUvvAlF3Z5HRyDDIfaSJo5_phwmcWGOgOtAvAS713l86
 tx.zsPVrORy7Yn7jL90zHRhfMwcPr4IdSH12iXNL9G68W3p1.XnN8Zyesd66Za2Vba41XnlJdvFt
 t3VztVpI7AnQ9piTNdiXS3KmGDgFu4DkQiOCvZYS_kfeuanu4WJLzdQN5vSavrJnlw4XuJptlyZ4
 gCR0.lcDRzvnkW_qvLq6KOX60hJr_FCwLrKP4x3OEVE2.eE9F27tG2oKKYi2unN_BHAmqacfDJVb
 vYVthWrOiGVlRqwTPSrM_0CHphf.N.fNWFK.P66r5d2iL5JzzR2.vXsXKJwgLrl74PZRdvaIqO3K
 VaheMgGdaEVUsPvh.izHnhbKVpOFWwh0rjlm2jrX597tBq9hi45ERG.UPFUdvqgIbkAJTbAyvho5
 vbGQxLCR_buvQRYWrhBzv4GhCqJNvqiUJPwQl_6QJZflgPPeP.0XaHG_a4Wq_jrtnZAKLpXr9Z8y
 YzKDCQEobKo6ds0xz5vqzLj.VNI5gKqH8vbaSKdoGg40JM.pxnDh5WnQOI6b1gN_PlxlhgBKuvXC
 .GQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 Jul 2022 19:11:35 +0000
Received: by hermes--production-ne1-7864dcfd54-9xpdj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4117ab4f76dad64aa17dddf685850e57;
          Sun, 03 Jul 2022 19:11:33 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: RPI4 + ntpdate + unbound
From: Mark Millard 
In-Reply-To: 
Date: Sun, 3 Jul 2022 12:11:31 -0700
Cc: John Kennedy ,
 David Cornejo ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LbdpQ0XvXz3FG1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Km6i25xJ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.41 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.91)[-0.908];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jul-3, at 11:22, Dr. Rolf Jansen  =
wrote:

> . . .
> I am still surprised why we get the NVIDIA Tegra compiled in the =
kernel of a 13.1-RELEASE SD card image which according to its file name =
is destined to the Raspberry Pi's.

So far as I am aware, the 13.1-RELEASES (and other built images,
like snapshots) always contain the generic FreeBSD (non-debug or
debug as appropriate). The only tailoring is extra, generally
non-FreeBSD material required to have a booting context.

For RPi*'s that is RPi* firmware, U-Boot, and the FreeBSD loader
in the right place for the RPi*.

I use such to advantage to boot multiple machines from the same
USB media. For example, a Rock64 and various RPi*'s. This works
because the Rock64 U-Boot/whatever-else and RPi* U-Boot do not
interfere with each other when both are installed. (Unusual for
U-Boot and related.)

The same media also boots and operates the MACCHIATObin Double
Shot (using UEFI/ACPI) and the HoneyComb (also using UEFI/ACPI).


Notes:

The amount of space for U-Boot and such that goes outside
a file system does vary but FreeBSD has not standardized on so
much room on all images that all the possibilties would fit for
a U-Boot replacement. Thus the above ability to switch around
by outside-file-system U-Boot replacement is somewhat limited.

It at least used to be that images like Rock64 also
contained the RPi* firmware and such, if I remember right.
As I remember, I started with the Rock64 image in order
to have the single-media based Rock64/RPi* support. That
made sure it had the right amount of room for the outside
any file system U-Boot/whatever-else for the Rock64.

But . . .
The first stage able to deal with the USB3 on the Rock64
is the FreeBSD kernel (that must then have already been
loaded and operating). So my USB3 based booting sequence
does not fit the above description --and these days is
my normal way to boot the Rock64. Still, the same USB3
media is used, there just is more on some other media
for getting to the point of the kernel operating.
(That USB3 media is also valid for USB2 use and so is
used for both styles of boot.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul  3 21:00:12 2022
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 D483D878621
	for ; Sun,  3 Jul 2022 21:00:13 +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 4LbhCd1GWQz3k55
	for ; Sun,  3 Jul 2022 21:00:12 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 9F69A2BA02
	for ; Sun,  3 Jul 2022 21:00:12 +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 263L0C25011490
	for ; Sun, 3 Jul 2022 21:00:12 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 263L0C2Q011489
	for freebsd-arm@FreeBSD.org; Sun, 3 Jul 2022 21:00:12 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202207032100.263L0C2Q011489@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, 3 Jul 2022 21:00:12 +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="16568820125.eB1D6ef.10546"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656882013;
	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=27DD67sRiart8g9lr2jy2L+xju33c3W4PGVhksZsF5g=;
	b=pquNbifstS8ZS/lCLeI9ywC94Sgk1FQ8jzeB5rjfzgQwl3/htwYdq1ZE4AyT6PrkUqgqXb
	d5nA/Gpe5XSDnOvb+yvAWPP49rLGul4Ldr7LgPyBaLDMDRf7NZZ1Kzk4zJfDJibKlgJcbk
	kTc5MZ3k3WRrwUA0b4695iXRTPd1ccxT6eU0/xi3p+SgEiQ230/G8v53NWn9WZhLzNtYPf
	7KSNJbeSQIr3Bw5VwdvEJX+c9gHfLM5g6bA66imJhdIfDIg1j87C0J8d3V8UC/q8GODUHe
	KRLbME4hoqzinD0/lGi66WrEQw+7COV0ZnYLxXlLBae40jECqHQYaWVwLv6plg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656882013; a=rsa-sha256; cv=none;
	b=C7M5lE4a1wAILCUqDNq0L66W9ABB+iG8Y27uR5LyQqzj4ru97Apb/xpf/1r+OWUnWPT+AC
	KqgIN5eKqYWHec+up8m269HuyaAdAAX6NWRGGoIxbY5MBhjPgEDefCGra+FnpijpRW7J8i
	2qD4c2bpzspYlfwg7XB4vk67BIGFIWlar0WDIPzJLFcbUJ3rJg90G5z4l0HVqqtxyAQQzO
	icxUrSNfTP6grp9Uq3z5ApQk5u5BUpeSIQiNsu/cR5JlCv+oAxiRGjZUY6+U9bjPLHV1EI
	K9A7TYOs8yjoDWfRbRGtr4IoIUthsczEmWPbeHU391tNU2gqcZoJMizfc2z+Sw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16568820125.eB1D6ef.10546
Date: Sun, 3 Jul 2022 21:00:12 +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.

--16568820125.eB1D6ef.10546
Date: Sun, 3 Jul 2022 21:00:12 +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.


--16568820125.eB1D6ef.10546--

From nobody Mon Jul  4 00:36:39 2022
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 DF3BB87D8CC
	for ; Mon,  4 Jul 2022 00:36:48 +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 4Lbn1W6C4Hz4mgB
	for ; Mon,  4 Jul 2022 00:36:47 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2640aeDD001226
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sun, 3 Jul 2022 17:36:40 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2640aeSw001225
	for freebsd-arm@freebsd.org; Sun, 3 Jul 2022 17:36:40 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 3 Jul 2022 17:36:39 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Subject: 13.1R problems on Pi3
Message-ID: <20220704003639.GA1165@www.zefox.net>
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-Rspamd-Queue-Id: 4Lbn1W6C4Hz4mgB
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.44 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[zefox.net];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 NEURAL_SPAM_LONG(0.50)[0.495];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.963];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

A clean install of 13.1R on a Pi3 still exhibits three long-standing
problems also seen on a Pi3 which started from 13.1RC4

Attempts to saveenv under uboot running from microSD fail.
As it happens, I need to set usb_pgood_delay to a larger
value to let the machine find the USB hard disk. Thus far
the workaround has been to manually editenv on the console.

Inbound ping requests are not answered except for a few
seconds around the time ntp runs.

Inbound ssh connects prompt for a password and then time out.

The ping and ssh problems can be worked around by starting an
outbound ping process. A few seconds after doing so both ping
and ssh are answered, erratically but usably.

The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4
on the same network branch exhibit no such problems. Only the
pair of Pi3s seem to be affected, under 13.1 and -current.

The network is started with these lines in /etc/rc.conf:
 
hostname="www.zefox.org"
ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
defaultrouter="50.1.20.1"
sshd_enable="YES"

Reference to DHCP has been removed. Could that be a source
of mischief? It seems not to cause problems on other hosts.

Thanks for reading, any insights appreciated!

bob prohaska




From nobody Mon Jul  4 02:22:56 2022
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 842C18A9152
	for ; Mon,  4 Jul 2022 02:23:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4LbqN93YtQz3CbW
	for ; Mon,  4 Jul 2022 02:23:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656901378; bh=lKqOMS6nsdIme+uOF4JTwCTXyrIiOgvbA84kWc3jQ0g=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=gzQyyyI71SHhWFwUkUo2ZKaXinskX2sQHZj04RbQZoN4aehBd86MhBVLG0lZL0ZS/sD24FKAXFfu7nnby2ZuCAGTewsL4DCVu44ju9Q+qY/CWd7n2PnwB2GQB2bGVL6AyHkyH/qgG66lqwxGUFFcrf31yniTAoXvYHivslIe8Nx3SG6pn9lsMS4ftmJCjGq8309uiPbDgawx5tSL1Hx1wy5BuPRK1vDTThAY461K9S/Y4RRYPIoKkj8TmvwN6cNyL/mcAAV22wVoNhktBj8ZI79TipZX9ffCdDJxCRCUD3uZwd9I5+cao5zOfeOlY7nEZdc14FHeqnxGKLU3JMJHZA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656901378; bh=8OaWlQtgs0bzUgJzXKXhORqnAlJQguM42DfWEYnpa50=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rIYKkmbbiKfplUIz4NW85U5wi777UdOGXjdSCO4JDQV+88ANHj0GIp42IPtll5LqJQU/aMqpMIZGXAfRiumdrNmRx168bq8ACaNPYf2h7QSvfa2KE3o5M6fLOJu61iQaIPCGKuHk008tYcwSAnw484adIsyRfZ3AkdOP6t63q6KLBSmG0ydGKB2NM0DpnjfFVAjLJRhORigRJ8T1SqymWSLwMPMmr8mtjTsjIxW5/+0oOqC5PpGSVSj/oFMBQBAQwpIn5bTnotXoaClEYh7sJ7xCRFuXMupwnF/ncMe6oVr1fGurJXGfeDghDxtULR54/5ci3n9nrUoJuF8QFFyTUw==
X-YMail-OSG: OGnd8YgVM1k8YBkWAlN4JcTR9egUlvf5XpuBEKCOExrIj5q8uR5qNoU0XCVgTfv
 kqs_5TrneQXg82ZK181rKBq3nl5y9CuvLpZgjg3ZUw_ldIMDIHfOikJyOnvQvoEsvCC2Cmck7V5e
 0HfYSaH9mNdW1nSW2IXLERua3iA._wK18iGgCFQ9TMM8Fg.jWaocRfzAowP71hafyO3b5J_zpcX0
 5Rb8gR2r8ab5xpfuDlTL4Jg.qr_oq3avlNidstwRwCIfxtEmyce6BvXAN2NGYJ7XJlzqA7LyR3kG
 lR8B4ajUs0E8g5p.3M4m9ImIqRc2seYBZuCJV8cWkVjLvRVNdVEPcbobKQ5zP_w_Jsb6BRzybiyp
 DLs5cCFt3XodC2fC0ZRRwJSoc8VxYtqn0PHgraoS_uCTcoBpJtZF.LqAeNL_.ck6ucr5ITIQ.q0Y
 1Jqn_61rDKcQ3SvFHHuqW7JdkdhceO2HW4D5hzV7E6Jvgp0v7tmW9Vbtx6S8klta.eBTH9h_kP9L
 eCovtipmvifURV6SjUC7Q4N3l1t23bGHHCnlD_1Tb..85sEIDc74skuWiravxTnH8RhsKyogcjA8
 SHe3f2HdUW.a62kBbZoRZmtRgOUOeU9KqpJDv0450qrJWevKepwsHpOdEeKYTQXP8o5kVA9_KdON
 ogwylH9iHUsSxyWKUXr_JoWaMwTy.N5Mqoadvtm9yOKO1VBIiMtgQCxM2YvevtNb8riovD4nUn8D
 pgeltVA5HUVKzhyKvUm9jJ2DyoO8IBjVsvMbreBeGihrGRnIEixlw9TSAcMYtMDPzHCQVt6.9xJl
 UcjgIwS._YKb051QJw_ukQio4gPaJt3uK8pWy84QuvVuN5.ULjLquHq6Q_v3umiFMgsY83NZMN2t
 cykY0i8ZYBBqZ0AFSH3HN2Pk_9glTjI1A6I_JwLZdJFpChzP3B_IvbqZSGsg.WK9QNWoErJY3xIf
 2cXJXkUDsuBq3KcmIb3eRyAuwwQo7Hz8uZvm78Ilk_5Zm7Ia8A7fOOdgcCKc11_VhZWmXi0ifUqg
 8tWibElIOwv0NJGw3oKOkraU1iyaj0VBPoAuqHTpqrjPuWzB7U1IDbP.2yDFHGSeVq_ULyPTKYgn
 HrgW8ERPUC7RWTO_p7EdBsivxS8AxhBh8zqYcxmN3WtlJD2RrliB2Nkk9RHpI6yFM7eJpaLsY6JU
 TPhutTIMlAy72XlcMNpRwFcMWdOMCHfb0pQWXd9y_cqThkXaQY1sRuAL6fAqkjfSOvxIu4pDdMeO
 zXULSH8tloOwSyWuF8W9u2QvQ4355gK7ECkf.ZJudYRVtRPisAEqOm27fF0B9I5TFf_IAylYg2dB
 RAC3MhzGHdHaMUJOtskdc70Fxq5tTNivEHqfREy8MuV4xENzcWuf0NKilUABKoKidEKLCx73pgqO
 lwZNPI2G5GfcgeDvYRIUVALqpjFQQTpJ3DkC64WLxZeagCvDyCrReiPxQsRRArkGLk3fJGfCa8cI
 NK7IReCMUA8osXW_JuQ_XZlFHWA7a_tmN3WXWz10Gd.pVEXe.mXi4_umX62i5ZQ4IGjK0Hk_neTv
 OJPNrfhm5BABMWDo2wHaQO_nZTsgMSfLcXlO1Rqxnr0TSAEkami1sUUtdwfMo54KefFPt4jOXE8h
 lR4ac85WwC2nM.JkGS5cJ_4GackwPht7GR80HjGtf01UuXS9JmL2soOPXtWo55hfDavAINeg5uCg
 D30HCd6LhWe9mqxnJMg85fqro6Ih2tev701g6N9jsbWiOhQ7meMyoQBmin5aSJlw9vD_w23eX6Wf
 SXPuuXJQL7GYBDRnR.dUaNPpWgdvgRi.oYo2oiat5.wTiUYeP8c9kyz.W_voC7DFsaaAiusgULaE
 G0apuhF1zHLaTqcq4PY6Ag9fIUmLlYFqTSwo3hXI.oiMAQa89pW8M44gPE.FJwKuzPwPTdHFkUft
 M3bSLiaW_eMGtCx38akChWbHWN9CV2ZkBMupbC6ac86ExPHG2PCAONyj2tdbv_Vny.rvZMSAbrM9
 JaMD.FVmwSchGmKz4kCBdRPBtGoGWeFRlVs5UgA4ypaSZ34zeP47U4BFJaIJBbefDDmCMaWPCDKQ
 4ViGtD.jfl_h8VYsZgnCozUv7XRL5pyTp9i765uNsnu4927r6nEFYIOS5WWyzV_uWHs8jtv_kBgL
 dj8t_91rFC7ZwFAWz2Wv4l4q1_QQ_FJd26FBDPepWHx9F1heouQHkL4Bp.KBfWQjEFao.5Lw98tp
 yIhnRU68kzfsvWNHkKfxDu7UiXr8xpCZjITOVNtRBOibTGFLGXVccfoq2e6LN_v9wIPeVPf4poLo
 kq18A
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 02:22:58 +0000
Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f445e12d3480b4ad6c37c888bfde428c;
          Mon, 04 Jul 2022 02:22:57 +0000 (UTC)
From: Mark Millard 
Message-Id: <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_24D66972-8B17-4B8D-99DF-60972CF0F248"
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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1R problems on Pi3
Date: Sun, 3 Jul 2022 19:22:56 -0700
In-Reply-To: <20220704003639.GA1165@www.zefox.net>
Cc: freebsd-arm@freebsd.org
To: bob prohaska 
References: <20220704003639.GA1165@www.zefox.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LbqN93YtQz3CbW
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=gzQyyyI7;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-0.89 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 HAS_ATTACHMENT(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.07)[-0.065];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.93)[-0.930];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 MIME_BAD_ATTACHMENT(1.60)[h];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_24D66972-8B17-4B8D-99DF-60972CF0F248
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



On 2022-Jul-3, at 17:36, bob prohaska  wrote:

> A clean install of 13.1R on a Pi3 still exhibits three long-standing
> problems also seen on a Pi3 which started from 13.1RC4
> 
> Attempts to saveenv under uboot running from microSD fail.
> As it happens, I need to set usb_pgood_delay to a larger
> value to let the machine find the USB hard disk. Thus far
> the workaround has been to manually editenv on the console.

So far as I know, U-Boot's saveenv has never worked for any
RPi*'s. This is not specific to your context or to recent
times. Possibly not even specific to FreeBSD's U-Boot port
builds. (Fedora? OpenBSD? . . .)

We have exchanged messages before about building U-Boot
with the required changes built in, providing an extra
file that the build would use. Below I gave the example
of what I use:

/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h

that looks like:

# more /usr/ports/sysutils/u-boot-rpi2/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

I have also added the file as an attachment, which may be easier
to deal with since I also Email you driectly.

You can, of course, change the 2000 and/or the 5 as appropriate
or adjust other aspects of the "+" lines. Changing the number of
"+" lines gets into making the "@@" line match. Currently it
indicates to replace 6 lines by 8 lines. (There are 2 lines
with just 1 leading space after the "BOOTENV" line, those
are the last 2 of the 6 non-"+" lines.)

I picked providing u-boot-rpi-arm64 material because that
is what the modern images for aarch64 RPi*'s are based on
as I understand. It works on a wider range of devices.

> Inbound ping requests are not answered except for a few
> seconds around the time ntp runs.
> 
> Inbound ssh connects prompt for a password and then time out.
> 
> The ping and ssh problems can be worked around by starting an
> outbound ping process. A few seconds after doing so both ping
> and ssh are answered, erratically but usably.
> 
> The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4
> on the same network branch exhibit no such problems. Only the
> pair of Pi3s seem to be affected, under 13.1 and -current.
> 
> The network is started with these lines in /etc/rc.conf:
> 
> hostname="www.zefox.org"
> ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
> defaultrouter="50.1.20.1"
> sshd_enable="YES"

Is that only one of the RPi3*'s? Multiple machines with
that exact text would conflict with each other, all
such trying to use 50.1.20.28 and www.zefox.org as
identification.

Has whatever provides DHCP and such been configured to
reserve 50.1.20.28 and to associate that with the right
ethernet address? If you do not have control of such,
then, as far as I know, you should not be trying to use
what are effectively static IP addresses --unless you
have been assigned the static IP addresses by your ISP.

> Reference to DHCP has been removed.

Why? If you use DHCP on the others, can you check the
behavior of using DHCP on these? Does it match the
others --or does end up being distinct/problematical?

(This testing may not be able to cover the intended
use, depending on why you avoid DHCP.)

Reminder: I'm no networking expert.

> Could that be a source
> of mischief? It seems not to cause problems on other hosts.
> 

That reads like you might have tried not using DHCP on
the RPi2*'s and RPi4* . Did you?


===
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_24D66972-8B17-4B8D-99DF-60972CF0F248
Content-Disposition: attachment;
	filename=patch-include_configs_rpi.h
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-include_configs_rpi.h"
Content-Transfer-Encoding: 7bit

--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

--Apple-Mail=_24D66972-8B17-4B8D-99DF-60972CF0F248--

From nobody Mon Jul  4 02:36:35 2022
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 4C6508AA989
	for ; Mon,  4 Jul 2022 02:36:43 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Lbqgt1pY3z3DNB
	for ; Mon,  4 Jul 2022 02:36:42 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 70B042110B2
	for ; Sun,  3 Jul 2022 22:36:36 -0400 (EDT)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id EE4A34A7995
	for ; Sun,  3 Jul 2022 22:36:35 -0400 (EDT)
Message-ID: <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
Date: Sun, 3 Jul 2022 22:36:35 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: 13.1R problems on Pi3
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
From: Karl Denninger 
In-Reply-To: <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020005010202050209090704"
X-Rspamd-Queue-Id: 4Lbqgt1pY3z3DNB
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-4.84 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.06)[0.060];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a cryptographically signed message in MIME format.

--------------ms020005010202050209090704
Content-Type: multipart/alternative;
 boundary="------------wuIF7QSb2iptqHD4mYjH03Ny"

--------------wuIF7QSb2iptqHD4mYjH03Ny
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/3/2022 22:22, Mark Millard wrote:
> On 2022-Jul-3, at 17:36, bob prohaska  wrote:
>
>> Inbound ping requests are not answered except for a few
>> seconds around the time ntp runs.
>>
>> Inbound ssh connects prompt for a password and then time out.
>>
>> The ping and ssh problems can be worked around by starting an
>> outbound ping process. A few seconds after doing so both ping
>> and ssh are answered, erratically but usably.
>>
>> The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4
>> on the same network branch exhibit no such problems. Only the
>> pair of Pi3s seem to be affected, under 13.1 and -current.
>>
>> The network is started with these lines in /etc/rc.conf:
>>
>> hostname="www.zefox.org"
>> ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
>> defaultrouter="50.1.20.1"
>> sshd_enable="YES"
> Is that only one of the RPi3*'s? Multiple machines with
> that exact text would conflict with each other, all
> such trying to use 50.1.20.28 andwww.zefox.org  as
> identification.
>
> Has whatever provides DHCP and such been configured to
> reserve 50.1.20.28 and to associate that with the right
> ethernet address? If you do not have control of such,
> then, as far as I know, you should not be trying to use
> what are effectively static IP addresses --unless you
> have been assigned the static IP addresses by your ISP.
>
>> Reference to DHCP has been removed.
> Why? If you use DHCP on the others, can you check the
> behavior of using DHCP on these? Does it match the
> others --or does end up being distinct/problematical?
>
> (This testing may not be able to cover the intended
> use, depending on why you avoid DHCP.)
>
> Reminder: I'm no networking expert.
>> Could that be a source
>> of mischief? It seems not to cause problems on other hosts.
>>
>>
>> That reads like you might have tried not using DHCP on
>> the RPi2*'s and RPi4* . Did you?

This is crossbuilt but...

$ uname -v
FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May  6 
10:47:17 EDT 2022 
karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC

$ uptime
10:27PM  up 49 days,  7:10, 1 user, load averages: 0.14, 0.15, 0.13

Ping both for Ipv4 and v6 (along with everything else) works fine.

/etc/rc.conf:

ifconfig_ue0="192.168.10.214 netmask 255.255.255.0"
ifconfig_ue0_ipv6="inet6 accept_rtadv"
defaultrouter="192.168.10.200"
sshd_enable="YES"
ipv6_activate_all_interfaces="YES"
ip6addrctl_enable="YES" # Set to YES to enable default address selection
ip6addrctl_verbose="NO" # Set to YES to enable verbose configuration 
messages
ip6addrctl_policy="ipv4_prefer" # A pre-defined address selection policy
                                 # (ipv4_prefer, ipv6_prefer, or AUTO)

Ipv4 is fixed-address, v6 is autoconfigured off my router here. No 
issues and it is a Pi3; it is running a somewhat-customized Crochet 
build (boots from SD, runs using ram for volatile things on tmpfs, SD is 
mounted r/o) and a software package that is online and providing 
services 24x7.

hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2

I have "prefer v4" set due to it being dual-address and it has to 
register the gateway's public address, which it doesn't and can't know 
for IPv4 (as its dynamically assigned) thus it must send a message to a 
server which then can getpeername() on it to figure out where it can be 
reached.  Removing that doesn't change anything other than prohibiting 
that registration from working since it will then find said server on 
its v6 address instead.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------wuIF7QSb2iptqHD4mYjH03Ny
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/3/2022 22:22, Mark Millard wrote:
    

    

      
On 2022-Jul-3, at 17:36, bob prohaska <fbsd@www.zefox.net> wrote:



      

        
Inbound ping requests are not answered except for a few
seconds around the time ntp runs.

Inbound ssh connects prompt for a password and then time out.

The ping and ssh problems can be worked around by starting an
outbound ping process. A few seconds after doing so both ping
and ssh are answered, erratically but usably.

The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4
on the same network branch exhibit no such problems. Only the
pair of Pi3s seem to be affected, under 13.1 and -current.

The network is started with these lines in /etc/rc.conf:

hostname="www.zefox.org"
ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
defaultrouter="50.1.20.1"
sshd_enable="YES"


      

      
Is that only one of the RPi3*'s? Multiple machines with
that exact text would conflict with each other, all
such trying to use 50.1.20.28 and www.zefox.org as
identification.

Has whatever provides DHCP and such been configured to
reserve 50.1.20.28 and to associate that with the right
ethernet address? If you do not have control of such,
then, as far as I know, you should not be trying to use
what are effectively static IP addresses --unless you
have been assigned the static IP addresses by your ISP.



      

        
Reference to DHCP has been removed.


      

      
Why? If you use DHCP on the others, can you check the
behavior of using DHCP on these? Does it match the
others --or does end up being distinct/problematical?

(This testing may not be able to cover the intended
use, depending on why you avoid DHCP.)

Reminder: I'm no networking expert.


      

        
Could that be a source
of mischief? It seems not to cause problems on other hosts.


That reads like you might have tried not using DHCP on
the RPi2*'s and RPi4* . Did you?


      

    

    
This is crossbuilt but...

    
$ uname -v

      FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May  6
      10:47:17 EDT 2022    
karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC

    

    
$ uptime

      10:27PM  up 49 days,  7:10, 1 user, load averages: 0.14, 0.15,
      0.13

    

    
Ping both for Ipv4 and v6 (along with everything else) works
      fine.

    
/etc/rc.conf:

    
ifconfig_ue0="192.168.10.214 netmask 255.255.255.0"

      ifconfig_ue0_ipv6="inet6 accept_rtadv"

      defaultrouter="192.168.10.200"

      sshd_enable="YES"

      ipv6_activate_all_interfaces="YES"

      ip6addrctl_enable="YES" # Set to YES to enable default address
      selection

      ip6addrctl_verbose="NO" # Set to YES to enable verbose
      configuration messages

      ip6addrctl_policy="ipv4_prefer" # A pre-defined address selection
      policy

                                      # (ipv4_prefer, ipv6_prefer, or
      AUTO)

      

      Ipv4 is fixed-address, v6 is autoconfigured off my router here. 
      No issues and it is a Pi3; it is running a somewhat-customized
      Crochet build (boots from SD, runs using ram for volatile things
      on tmpfs, SD is mounted r/o) and a software package that is online
      and providing services 24x7. 

    

    
hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2

    

    
I have "prefer v4" set due to it being dual-address and it has to
      register the gateway's public address, which it doesn't and can't
      know for IPv4 (as its dynamically assigned) thus it must send a
      message to a server which then can getpeername() on it to figure
      out where it can be reached.  Removing that doesn't change
      anything other than prohibiting that registration from working
      since it will then find said server on its v6 address instead.

    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------wuIF7QSb2iptqHD4mYjH03Ny--

--------------ms020005010202050209090704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MDQwMjM2MzVaME8GCSqGSIb3DQEJBDFCBEDdW7F9tOT2eDHFM+mI
rbgjnaQf163ShMvySLMWA7jQUxuLldka3zrIpzzrodLl/YCvuL/jBFXb0z5EpnZRVdOQMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCPekxrobgkftDGl3jTGmxdT7hdG7zrtBksFoPN
Q9Fli9Hwhzi9zEccEaivaX5JWHCmQpCQgZ60ncWTVIaYLQhPx+2IKnWz4NznKvcuuEzcEZNX
TKcNHf5Y48eF4fwOJ4Tvy/QRMxtmb1/5GAkpFNCOlGUjCK+MknXZzgjOZIcHujYM4Wd/15CN
+/5EDJXbu2utZGKk4ga11Gyc9q6CLt9mt/gF/2z4MmuwcPs2J8iUBu9tcMPKY1RqKlZE4thD
C6T2Mq9Ax3no2x7hyjPGO5SfC7JBzxqZFDGHbGWVw4M/OuOqeFSMtmZShwAsVotwMjhhRAnE
V7i376SMiWP1OyG6KmFiK61bVjl02j3UkL8MvHccyO11aK9kPPmBX0GGkcB3rJ1NhK4Cjr+w
6PNqHRWBjqo2F7eWtITTG68Jf7ZF8prWSC5Y1zQf3hJEDJVbhPQskxQNXOHcBdAHM9obl6XP
lY5KEeoywXnzh/LS3p/j5HmFlH8Fr4uS1Lw3zoqOCsDB9iAroNMOAg3X0+KO4lmuBLMpppDL
QjPC+BxBeRE+fo7qofRHQ5VbNswqO/VzbfDIlRg9KdGzonEKdWM3TgooJr0U//qldvdwlmeN
JfuOtajZnMSLiGf3kuhLAGkPNW6eMmAZqHuBfwGTT7ZDPB3rqiyXrpLsVBUpE9PqpaS1pgAA
AAAAAA==
--------------ms020005010202050209090704--

From nobody Mon Jul  4 15:28:34 2022
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 7E1F3C7B6E5
	for ; Mon,  4 Jul 2022 15:28:40 +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 4Lc8pb4Kxtz3plQ
	for ; Mon,  4 Jul 2022 15:28:39 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 264FSZtG003685
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 4 Jul 2022 08:28:35 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 264FSY7L003684;
	Mon, 4 Jul 2022 08:28:34 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 4 Jul 2022 08:28:34 -0700
From: bob prohaska 
To: Karl Denninger 
Cc: freebsd-arm@freebsd.org
Subject: Re: 13.1R problems on Pi3
Message-ID: <20220704152834.GA1771@www.zefox.net>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
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: <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
X-Rspamd-Queue-Id: 4Lc8pb4Kxtz3plQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
> 
> This is crossbuilt but...
> 
> $ uname -v
> FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17
> EDT 2022 karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC
> 
> $ uptime
> 10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13
> 
> Ping both for Ipv4 and v6 (along with everything else) works fine.
>
 
That makes it unlikely the omission of DHCP services on my
machines accounts of lack of ping and ssh response. 

Can any sense be made of the few ping responses obtained when ntp
is coming up? It's looks as if something happens after ntp runs
that blocks subsequent network traffic, but why starting an outbound
ping should partly unblock things is obscure to me.  

To answer Mark's question about my network setup, I'm using an ISP
assigned network block of addresses, 50.1.20.31-50.1.20.24. All are
usable, there's no DHCP server. I assign one address to my router
for my LAN, the rest are taken by FreeBSD hosts. There are three
Pi2s running stable/12, one Pi2 running -current, (presently) two
Pi3s running stable/13 and one Pi4 running -current. So far only
the Pi3s are displaying network problems. 

Network traffic enters my premises via DSL, connects to a switch
and thence to the router and hosts. A second switch chained off
the first provides connection to one Pi3 and the Pi4. The other
Pi3 is on the first switch. So, one Pi3 is on the first switch,
the other is on the second, both Pi3s are acting strange and 
the Pi4 works fine. So, I don't think it's the second switch. 

Thanks for writing!

bob prohaska


From nobody Mon Jul  4 16:17:15 2022
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 7135A17E8409
	for ; Mon,  4 Jul 2022 16:17:48 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Lc9vH1kMrz3w0k
	for ; Mon,  4 Jul 2022 16:17:47 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id BD1D82110B2
	for ; Mon,  4 Jul 2022 12:17:16 -0400 (EDT)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 51B294AAC67
	for ; Mon,  4 Jul 2022 12:17:16 -0400 (EDT)
Message-ID: <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
Date: Mon, 4 Jul 2022 12:17:15 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: 13.1R problems on Pi3
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
From: Karl Denninger 
In-Reply-To: <20220704152834.GA1771@www.zefox.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060007010102000403050003"
X-Rspamd-Queue-Id: 4Lc9vH1kMrz3w0k
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-5.90 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a cryptographically signed message in MIME format.

--------------ms060007010102000403050003
Content-Type: multipart/alternative;
 boundary="------------pZn6rSC5SACFA7MTSHN0ugNj"

--------------pZn6rSC5SACFA7MTSHN0ugNj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 7/4/2022 11:28, bob prohaska wrote:
> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>> This is crossbuilt but...
>>
>> $ uname -v
>> FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17
>> EDT 2022karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC
>>
>> $ uptime
>> 10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13
>>
>> Ping both for Ipv4 and v6 (along with everything else) works fine.
>   
> That makes it unlikely the omission of DHCP services on my
> machines accounts of lack of ping and ssh response.
>
> Can any sense be made of the few ping responses obtained when ntp
> is coming up? It's looks as if something happens after ntp runs
> that blocks subsequent network traffic, but why starting an outbound
> ping should partly unblock things is obscure to me.

Yes.  The odds are reasonably high that there is confusion as to which 
MAC address maps to which device.  This implies there's a loop between 
the two switches (e.g. there is more than one way for packets to get 
into and out of each said switch to the other) or the two devices are 
claiming the same MAC address and thus when each "speaks" and performs 
ARP it "grabs" the map which works until the next one pipes up and it 
grabs it.

Each interface device from the factory is supposed to have a unique MAC 
address.  This can, for most interfaces, be overridden (modern Android 
phones "randomize" it if told to as a "security" measure) but for 
obvious reasons doing that can lead to problems. Collisions where 
multiple devices are using the same MAC will lead to exactly the sort of 
thing you're seeing because the switch is sending the packets to the 
wrong place.

I've got a decent number of Pis of everything back to the "2" here and 
most of the time several of them are on my network at once.  I've not 
seen this problem but I wouldn't exclude that both are claiming the same 
MAC and, if so, that's what's causing the problem.

Check here:

$ ifconfig ue0
ue0: flags=8843 metric 0 mtu 1500
         options=80009
_*ether b8:27:eb:4e:88:64*_
         inet 192.168.10.214 netmask 0xffffff00 broadcast 192.168.10.255
         inet6 fe80::ba27:ebff:fe4e:8864%ue0 prefixlen 64 scopeid 0x2
         inet6 2600:6c5d:5d01:8600:ba27:ebff:fe4e:8864 prefixlen 64 autoconf
         media: Ethernet autoselect (100baseTX )
         status: active
         nd6 options=23

That MUST be unique on your LAN; the prefix (first three octets) is a 
vendor code /*and the last three should never be duplicated by a vendor. 
*/If you are not setting it in /etc/rc.conf or elsewhere and there /are 
/duplicates then a very bad thing happened when those units were 
manufactured -- set one of them to something else.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------pZn6rSC5SACFA7MTSHN0ugNj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 7/4/2022 11:28, bob prohaska wrote:

    

    

      
On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:


      

        
This is crossbuilt but...

$ uname -v
FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17
EDT 2022 karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC

$ uptime
10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13

Ping both for Ipv4 and v6 (along with everything else) works fine.


      

      
 
That makes it unlikely the omission of DHCP services on my
machines accounts of lack of ping and ssh response. 

Can any sense be made of the few ping responses obtained when ntp
is coming up? It's looks as if something happens after ntp runs
that blocks subsequent network traffic, but why starting an outbound
ping should partly unblock things is obscure to me.  

    

    
Yes.  The odds are reasonably high that there is confusion as to
      which MAC address maps to which device.  This implies there's a
      loop between the two switches (e.g. there is more than one way for
      packets to get into and out of each said switch to the other) or
      the two devices are claiming the same MAC address and thus when
      each "speaks" and performs ARP it "grabs" the map which works
      until the next one pipes up and it grabs it.

    
Each interface device from the factory is supposed to have a
      unique MAC address.  This can, for most interfaces, be overridden
      (modern Android phones "randomize" it if told to as a "security"
      measure) but for obvious reasons doing that can lead to problems. 
      Collisions where multiple devices are using the same MAC will lead
      to exactly the sort of thing you're seeing because the switch is
      sending the packets to the wrong place.

    

    
I've got a decent number of Pis of everything back to the "2"
      here and most of the time several of them are on my network at
      once.  I've not seen this problem but I wouldn't exclude that both
      are claiming the same MAC and, if so, that's what's causing the
      problem.

    
Check here:

    
$ ifconfig ue0

      ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
      metric 0 mtu 1500

              options=80009<RXCSUM,VLAN_MTU,LINKSTATE>

              ether b8:27:eb:4e:88:64

              inet 192.168.10.214 netmask 0xffffff00 broadcast
      192.168.10.255

              inet6 fe80::ba27:ebff:fe4e:8864%ue0 prefixlen 64 scopeid
      0x2

              inet6 2600:6c5d:5d01:8600:ba27:ebff:fe4e:8864 prefixlen 64
      autoconf

              media: Ethernet autoselect (100baseTX <full-duplex>)

              status: active

              nd6
      options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

    

    
That MUST be unique on your LAN; the prefix (first three octets)
      is a vendor code and the last three should never be
          duplicated by a vendor.  If you are not setting it in
      /etc/rc.conf or elsewhere and there are duplicates then a
      very bad thing happened when those units were manufactured -- set
      one of them to something else.

    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------pZn6rSC5SACFA7MTSHN0ugNj--

--------------ms060007010102000403050003
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MDQxNjE3MTVaME8GCSqGSIb3DQEJBDFCBECusMg3SxkUyj7sWZPX
L1VCEjCvRtlyZHLpvoLH0FefBA1qiljGjg4KPGDKtNbgfBryqfk2jEjBHZ7b/MRl6s8jMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgC7sJbHrU/l3twgeWeE1BWsd7cIdIQvTfVO2wq7
ZIkvgy7S/5Td0o3jB649M+1MjzHnDULhKq9TYZ+2YxauSUA/YfI87++g7M7HdJj0yZpGs3Hy
hc0681b9hzuj65qL83F6x46YiIuYTS8ppnbImGcIKZHa1UJe6JFcIzmwxykX8HXzoF7CNfqx
+9TsqnLU36UDKUSZz2FBErBTCub/YzzVcHwUWG5iWtbrBfppkRkvXC+jMQguQMxX5KdLMk4o
Vu9jQOEbTHS3VcaR0KS21qQGDTCBmNNZynTxKV622FMnHzK7PIjnBhYQSx/09yIZCv+g49m/
p51Xl3qh1HdW9/iKSmJIu2ZuYFFdKM+MhdXfCwyzBLQcZfvTPjNpflY4Mtw6ckCtC0CntF8L
gy1RBzoW7tYo2MZ5IJ9i805Gbq8ACy6QcGlfFvs8Mz5uN5JzyC5ZpnM+/Xgfcce4SnhD5jA2
ATQ0vxoW1Zs/3caqMSvoVjF42OdaYZTUj3c3scaztP6rpgt/SKUaKU6Md+rD3/nj6VrMgkYI
XSzZgrLM5MsQIUON/P50193TRI0gp0In6lqnhNrfts3tzgl4LFFq5aYHY524I05SH/AjnLcm
UFWXGbdkhCcysGWcL4MctWmTDZkQoYxv4fXUm+6x1y8Ga9aZXrZMxhTYHd3KU+BGSWiTRgAA
AAAAAA==
--------------ms060007010102000403050003--

From nobody Mon Jul  4 16:32:12 2022
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 4D85A1822564
	for ; Mon,  4 Jul 2022 16:32:23 +0000 (UTC)
	(envelope-from nick@i11.co)
Received: from mx.i11.co (mx.i11.co [159.69.78.69])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcBD62QJkz4RSW
	for ; Mon,  4 Jul 2022 16:32:22 +0000 (UTC)
	(envelope-from nick@i11.co)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i11.co;
	s=omicron; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:
	In-Reply-To:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=YHrGsvHviD+8Qj0dmjutzNhRwqZkjqxkLEDUJRece3o=; b=KWpLLXMEWDPTlfLQ6bNPzdNrK8
	a8QHOZHNsJNZCRRr5VorHa9XHZvmksWghchADggVRtYUg2tdturNbS50oAFh3F+khmMJeJpkj0too
	IaYbQUqtFlYMKoU78xjQqh2SlRVDo7PGsg9gURNXKizPmNqtAntY4qcAf1SMJbfmPBJsT4npjUpqC
	/LQVbYe9nMtrIs40o85andEV46CXR1PASuX3a8EcNpQquaetQHW2h/1pWMIAZ+krvMKbXhfIBZlT8
	T/xdpZs5tvy6x/9SUDFQUr1PpiY0ku7RRMLn52UtBj8ow+k+5mmVdSjMHaoS4DAYc73lrzNIktq2Y
	oV048nSQ==;
Received: from [212.237.25.26] (helo=thinkbook)
	by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1o8Oze-0003OD-CE
	for freebsd-arm@freebsd.org; Mon, 04 Jul 2022 16:32:14 +0000
Date: Mon, 4 Jul 2022 19:32:12 +0300
From: Nick Kostyria 
To: freebsd-arm@freebsd.org
Subject: Re: uart1
Message-ID: <20220704163212.1545af3d@thinkbook>
In-Reply-To: <20220428151142.5c08cdec@thinkbook>
References: <20220428151142.5c08cdec@thinkbook>
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.3)
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: 4LcBD62QJkz4RSW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i11.co header.s=omicron header.b=KWpLLXME;
	dmarc=pass (policy=reject) header.from=i11.co;
	spf=pass (mx1.freebsd.org: domain of nick@i11.co designates 159.69.78.69 as permitted sender) smtp.mailfrom=nick@i11.co
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[i11.co:s=omicron];
	 FREEFALL_USER(0.00)[nick];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.1:email,0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email,0.0.0.1:email];
	 DKIM_TRACE(0.00)[i11.co:+];
	 DMARC_POLICY_ALLOW(-0.50)[i11.co,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 28 Apr 2022 18:11:42 +0300
Nick Kostirya  wrote:

> Hello.
> 
> How use uart1 ?
> 
> I want use MCU wiht UART interface on NanoPI NEO.
> 
> I use overlay:
> 
> /dts-v1/;
> /plugin/;
> 
> / {
> 	compatible = "allwinner,sun8i-h3";
> };
> 
> &uart1 {
> 	status = "okay";
> };
> 

It is bad overlay.
It works with the following overlay:

/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target-path = "/aliases";
		__overlay__ {
			serial1 = "/soc/serial@01c28400";
		};
	};

	fragment@1 {
		target = <&uart1>;
		 __overlay__ {
			pinctrl-names = "default";
			pinctrl-0 = <&uart1_pins>;
			status = "okay";
		};
	};
};




From nobody Mon Jul  4 17:08:20 2022
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 D20961AC4B01
	for ; Mon,  4 Jul 2022 17:08:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4LcC1s5D3bz4bSL
	for ; Mon,  4 Jul 2022 17:08:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656954506; bh=MGurh0L1FsGOmCgh41Vm8e0U+LjSFi05QsgETL4b4+4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=assMy+pyH1SQeuAp5+ji60z1K3TVnl51kV8GnXxEEOgD3m2ym6VRIlJdfTu/CLO8xeQzroWgR8qbLclRFuaggwWHpBsdZXBrj/TthPuAq3d166fM5Ag7QBiICSy8goSMEHFOHIrSYb5D9MrlykSCGR1NSuYWg2wgp5b+TKah/sNO2k8exFjQxZDonbzfOdgiCyBsB5qliq9FGii9beXfeBWNVMdWuSH5nnYjyMuLI/57YQIxlXIGMXVXqOaGZh7xOdtFhL3WnJywmk+Jf5jAEqxBzLuIO8GaGZpkykS5NsmrHhS9CiEW+sLtSH5KfZ4U9xPUOLOrxQp6WjNndRJEhw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656954506; bh=LJiWFjLK8LQwopFO6U4JcwLEQ3LfHU35FNA4ufJItTA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Q/V9WKLRv+f1OgkIRYE5yAYEXai3PnewiUIiQrX66pIKSlydzvVU6C2+OC2A0KMvxZrXlhxdRAu9A3ooAT2AfQIIITfDsLkS4rw/GuBBVM14mLHMHiewl1yZgoAHadOuagZqnOLGMqeQ620drUBm9w4p8Y6aIkWaPhrV+4SMuBa/U1qqrznJY6vbvtsyMg/MokVSbCoQBpAe4Y6wcm6ptsR+1RT5QOaxoJE8U9TEeni+P5yR+BlKFepvGoeqCqRa8U7zwCdzIegxcIURJPuy3DMh2M0x7YthbYRjJ9MDddrSI/tkFjyY5kwCkolUQiqxLrzAiQRa5Xyvn87YD0xwsQ==
X-YMail-OSG: xYoqr2MVM1kgJdjfIoq1TBKN.Wp2NSCju5ursgT2lJwcME0VQIPc.LOQltut84I
 Hr9ui0e63laH8FbegLDjK.UjASd6s6Y52RMHdru2KSBoO9D0lJRtBKtVFgG62njzzXSS5PX4Fe43
 7u68pb2YJixBuZb4rKi8b49GZ.zCP9fVEQJeuXKyMSsCfIyGRDPWHlym9DByNB5EFMdGujXWM09G
 t.qIjbz7aSJ5snMLR2_o2BcjHHOfv3_Lnr5Ew4bwl1D.Zmw9BRBwrRrNqbtoWyOrhExF_eksZ8rM
 ZCUM6H0noUZRfEDi5nP9C.E06IvahjO6vO4.jFnDv6lcXbitZi_acSZTU5lafNnTsjpbqA56ThES
 fk9kAecMDcZpPtMZ6S.aNv2IOk7nv95mdJ.5Bk7bWU94GrgSuVUW5JCS1eS2nTLigwxZSDI._l0P
 usdSN9fh.IuwHF1csNy8UNyO0Xl9i5VJu8UU2bUWpZ030DjUnwO.6dxF7Nd6vjVTuAESyVW8O8Vz
 NyfRt31rN3zVHJPzcNikcGjdoX9vp_7rmvF_pD1ESq6Lj74JqFrh6LApteyjYrXqYOBBxp9txOZX
 Hh8uKp1vkFRwzW8MmYI88npnK2I39DXlmDqgDZ4ZlNheTgMRGP2u9rZTp2Az3_3BXkkmtnrneVhz
 TqVg0UCeYXJX_pYgfarHBkFtYXuY1dSA6L2P9rBK574XdykOfAsYQ01kGWpgWpfI8FO_cW77zxKH
 iYGyPWybN_M052qaZsdoUw76.d9BFttJAhSYg104iP3vwz3aDjYlL.2WBpeAtOFJgBMFB4d5BMul
 F1GRwtDrnueST3xnsSo0gASqLVAiM169_uTWJvtlYlg3CS.8H2dmnrjf2soMqTiMyJRgvmAN.ExR
 AJa4tPyZJzWuTPMAVI2IlTZUU9XMlcxk2AtZNZVJXw6FFrxhhVqoScE6ymrWLMgulPfuaDt_j2fH
 o5ZguyjOL8WxVPapsoqb7ovc9ifw.eqrtFYjwqKDznFxMPZvr5PRXmv4.RlXBToGmyWidkuCrl3z
 f1SVYvcFWnEtiv8q33k14Y_3Z2oivh.b.8WABZ6SEE9DiUDMoAdeyMexaQ1ms93ahO_SPDUC.YnE
 W2opmpfoFB17av9NwvWSYpJ2CRcAyOZNS52J7AQnQA3bmEj253mF7lnkyk0jpXxLef40Ph_7oOE2
 a2XKzl3u7qslX.GYCrIvixC2fToIFWYqcwzTSEYVHAod0ZlK8P_Q.ukgCeasB5rHYTiuQu_2uawB
 lPUnlhFp3Lxh3h5GuZRINAizWfvx.VIW95GQSr_.IMCHukjbo0DWfMvZYT60Dn9ceUkaxjdYK_JQ
 _epNeeo0F_6lU1MZOBUgNzUGO8rxL1C7e6_Tr035JfZZiu48lcGxKLHbQu8leNmJSpAHkRA4nR0H
 1D9WKqPaWEFYkzjqk9I5bcX4.UIzxmbwxTgh_qImq4PrLgLUeDkpl2NiJp5vPxiU5e3_AvBIXVg_
 qyZO1YoUbO0jCd1UDjWMQAsA3bDiK0FQEb04uqUMwN.bggAo5lgrE1ig_qb8qPKHZ5wtU.6WS.bJ
 f1XlgolSSjzJlq1y6QzSH.lM2N_pvUyW3Tm2l_a7DrbaNZM0lLGhwyuUblTnTpxiOZn_teQR5Uw5
 Yh4JraxgTh1G8X8TIX1I3plTCBcqIja79.XzaDRM.7R1jbe_2LyWUqQYdBD4ubelp9h.Rh7d1g3Z
 l6FdFVp.Ds7HO_K6yOZ1iO1vgEaCetxlPCg19WJb7Ib9VvF8C7H92MCr_qNnTzu45Adc51ODjHnE
 v0kbVNwgAlMuZ_55PC9hAFJI8OB1jbA4fxJVrA97dyt8uYiLvAn5XdgCQgyyHIjffgHB0F8rp2Lz
 GGUx.frs.CzF8UHNLlPcTCnDStHRc.Jt0NRpXiF1cTILs4l9JyE4hwZ1uVEJ8_.uxDHwiOK2LRbg
 5fYkwhxtXdW_PCkdGGiJdSP5m9IYvzZ_N1LPuxCcwkiWkXk6tRQ4gIhk3RfHlxRn5H0tKEaYlAOE
 1OXE2tFyiNf4m.yfBFE8c0A7fFrDAkTdBrjW8vrtWygtDvJQ_ZO3Sfcv9wni4ebAll8Jebq8ukDj
 6DZVTMhy6AwOQZPUgW3NBG6Dgbfgoaa9FTjTn4ORc_b8iHgWynLgexpm1I4s2ubLPN0oHXMN11ti
 IAPik8_yCmC5gPIzSPG0gsr3lZx6wSpAkdYic0eHsEYnWM35JonC3iNWF_vbGwRHwot3QU4IBVK1
 ssQO_D1xKtoFRVJQCrDNY_5dceK9TKl6vrylqn6TBzebyTp2kp7KqkLPbj_zP.Qw3bqWKrFf9hjI
 Y7ir508znDKebpFLLwDo-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 17:08:26 +0000
Received: by hermes--production-gq1-56bb98dbc7-sdpv4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1b1a4e09ebc4dfb935953f1aa3bdf5db;
          Mon, 04 Jul 2022 17:08:21 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <20220704152834.GA1771@www.zefox.net>
Date: Mon, 4 Jul 2022 10:08:20 -0700
Cc: Karl Denninger ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DB31074-A3F3-46BE-879D-456A22D63B42@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcC1s5D3bz4bSL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=assMy+py;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	 NEURAL_HAM_SHORT(-0.97)[-0.968];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 08:28, bob prohaska  wrote:

> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>>=20
>> This is crossbuilt but...
>>=20
>> $ uname -v
>> FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 =
10:47:17
>> EDT 2022 =
karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE=
/arm64.aarch64/sys/GENERIC
>>=20
>> $ uptime
>> 10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13
>>=20
>> Ping both for Ipv4 and v6 (along with everything else) works fine.
>>=20
>=20
> That makes it unlikely the omission of DHCP services on my
> machines accounts of lack of ping and ssh response.=20

One difference in Karl D.'s context vs. yours is Karl is using
the private IP address range 192.168.*.* while you are using
a public IP address range. Not that I know such could make a
difference.

I had once suggested testing with EtherNet dongle(s). Such
testing could end up involving some different driver software.
You wrote on 2022-04-30 "A wired adapter would be more
informative, but I'll have to figure out what to order." Did
you get a dongle or two? Is such testing now possible?

I use CableCreation USB 3.0 to Ethernet Adapter-1Gbps dongles,
in part because I sometimes use EDK2 UEFI/ACPI style booting
and FreeBSD does not support the built-in Ethernet port for
that (last I checked). But, also, it used to be that I
would get occasional corruptions in transfers when I used
the built-in Ethernet (U-Boot style booting), something
I've never seen with the dongles. (But I've not tested
the built-in Ethernet significantly on any of the RPi4B's
or the RPi3* in a long time.)

> Can any sense be made of the few ping responses obtained when ntp
> is coming up?

Capturing and competently examining the protocol from other
machine(s) on the same Ethernet branch(s) is outside my
knowledge base, unfortunately. I could imagine that also
capturing on the device itself over the same time frame
could make for useful comparison/contrast material. But,
again, outside my knowledge base.

> It's looks as if something happens after ntp runs
> that blocks subsequent network traffic, but why starting an outbound
> ping should partly unblock things is obscure to me. =20
>=20
> To answer Mark's question about my network setup, I'm using an ISP
> assigned network block of addresses, 50.1.20.31-50.1.20.24.

Sorry, I misinterpreted the "Reference to DHCP has been removed"
wording, thinking that you had switched to involving some DHCP
use sometime after the April/May session and then had removed
DHCP use on the one machine's configuration.

> All are
> usable, there's no DHCP server. I assign one address to my router
> for my LAN, the rest are taken by FreeBSD hosts. There are three
> Pi2s running stable/12, one Pi2 running -current, (presently) two
> Pi3s running stable/13 and one Pi4 running -current. So far only
> the Pi3s are displaying network problems.=20

As I remember, there were some past experiments with booting
alternate FreeBSD versions and such. I'd have to look up the
results.

An interesting question would be if the problem still exists
when the only machine on the network is one of the 2 RPi3*'s.
It might require remote testing, possibly like I did once
before. This type of testing would suggest that the machines
are somehow interfering with each other if the problem can
not be reproduced.

> Network traffic enters my premises via DSL, connects to a switch
> and thence to the router and hosts. A second switch chained off
> the first provides connection to one Pi3 and the Pi4. The other
> Pi3 is on the first switch. So, one Pi3 is on the first switch,
> the other is on the second, both Pi3s are acting strange and=20
> the Pi4 works fine. So, I don't think it's the second switch.=20
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jul  4 18:25:26 2022
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 CDF791C53D36
	for ; Mon,  4 Jul 2022 18:25:32 +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 4LcDkg59kDz4rr0
	for ; Mon,  4 Jul 2022 18:25:31 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 264IPR0U004699
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 4 Jul 2022 11:25:27 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 264IPR2M004698;
	Mon, 4 Jul 2022 11:25:27 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 4 Jul 2022 11:25:26 -0700
From: bob prohaska 
To: Karl Denninger 
Cc: freebsd-arm@freebsd.org
Subject: Re: 13.1R problems on Pi3
Message-ID: <20220704182526.GB1771@www.zefox.net>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
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: <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
X-Rspamd-Queue-Id: 4LcDkg59kDz4rr0
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
> 
> On 7/4/2022 11:28, bob prohaska wrote:
> > On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
> > 
> > Can any sense be made of the few ping responses obtained when ntp
> > is coming up? It's looks as if something happens after ntp runs
> > that blocks subsequent network traffic, but why starting an outbound
> > ping should partly unblock things is obscure to me.
> 
> Yes.?? The odds are reasonably high that there is confusion as to which MAC
> address maps to which device.?? This implies there's a loop between the two
> switches (e.g. there is more than one way for packets to get into and out of
> each said switch to the other) or the two devices are claiming the same MAC
> address and thus when each "speaks" and performs ARP it "grabs" the map
> which works until the next one pipes up and it grabs it.
>
 
Looks like that's the problem. There's only one cable between switches, but
here's what I get from ifconfig on each host:

On the machine running 13.1-R attached to switch 2:
bob@www:~ % ifconfig
lo0: flags=8049 metric 0 mtu 16384
	options=680003
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
	options=80009
>>>>>>>	ether b8:27:eb:71:46:4e
	inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
	media: Ethernet autoselect (100baseTX )
	status: active
	nd6 options=29
bob@www:~ % hostname
www.zefox.org
bob@www:~ % 
bob@www:~ % uname -a
FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64
bob@www:~ %

On the machine running an updated stable/13 system attached to switch 1: 
bob@pelorus:~ % ifconfig
lo0: flags=8049 metric 0 mtu 16384
	options=680003
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 127.0.0.1 netmask 0xff000000
	groups: lo
	nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
	options=80009
>>>>>>	ether b8:27:eb:71:46:4e
	inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
	media: Ethernet autoselect (100baseTX )
	status: active
	nd6 options=29
bob@pelorus:~ % hostname
pelorus.zefox.org
bob@pelorus:~ % 
bob@pelorus:~ % uname -a
FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64


Thinking it over, I added the extra switch some time ago and didn't 
immediately notice any problems. Both Pi3s started out on the first
switch (NetGear), with no obvdious problems. Later I probably moved 
one Pi3 to the second switch (D-Link) and started to notice troubles. 
Does this story make sense? 
 
> Each interface device from the factory is supposed to have a unique MAC
> address.?? This can, for most interfaces, be overridden (modern Android
> phones "randomize" it if told to as a "security" measure) but for obvious
> reasons doing that can lead to problems. Collisions where multiple devices
> are using the same MAC will lead to exactly the sort of thing you're seeing
> because the switch is sending the packets to the wrong place.
> 
> I've got a decent number of Pis of everything back to the "2" here and most
> of the time several of them are on my network at once.?? I've not seen this
> problem but I wouldn't exclude that both are claiming the same MAC and, if
> so, that's what's causing the problem.
> 
[example ifconfig output snipped]
> 
> That MUST be unique on your LAN; the prefix (first three octets) is a vendor
> code /*and the last three should never be duplicated by a vendor. */If you
> are not setting it in /etc/rc.conf or elsewhere and there /are /duplicates
> then a very bad thing happened when those units were manufactured -- set one
> of them to something else.
>

Any pointers to MAC-setting methods appreciated.....

Thanks very much for writing!

bob prohaska



From nobody Mon Jul  4 18:47:23 2022
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 0F0461C75F42
	for ; Mon,  4 Jul 2022 18:47:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4LcFD845cKz4v35
	for ; Mon,  4 Jul 2022 18:47:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656960449; bh=5KrJthDPwdSr5urdB2FzZbak7tpyw6lofF6/NEBgALw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fmkDfY4LrqjImeR7/V2e8yf226ri0/VRIo8phOtI2vhIbIXhB5VPhJURp6iz4MxptrToNnUHuPpla9ueusYbKSbSIUZUSHf7x8XxpXb6s2R31eAyfKyQz4dD+KIHDjhtoqFmnjSstv9FG6ACYGDebGSU7rca2e/8lByKq2dkBK4zJyC+GBvUNaabIwVjsmti6fkXK+Qu3v3TjPFNLeoXH0s1gmbpuVZksCK6mf8kP9Cj8OWQPr/7DWrM2B7tCBBlifkAmJFwoFG01FnLUXGazRCW0NoCfzPLBEjsAmlxrC3x2jX0ZX5/+7uMVHHIQKejlvnEw6+a1cS8p2izCSAqDw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656960449; bh=3cHxNL/in6bFtXynZEEDEqr+ymE1XNKWe+iRYe5i7Qv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Mr244115ntl8uqirZGzTlfO5GJ++koWNqdfEX0udxAcU7qNo+z3UMU2e5piCgw6hqjoV09BJTBM6cK0HM5NMZXq69NVJJM8APE9hbaeQmhPKDFR7rpdsMrULOyrd3mXpnhNiBoS4QfGpwvKw6xYS9/JBTeySCS9CA9xhhULoG7QLXFGav4kTmGz6wHgAzGI9Kk3i1tCPe3DoFwAblpINbaE7QnME8oHTPfTqklTAGf91BYy8yqJ183ZIgxkpxOk+yGoCdvgGpI3OGPZxGZ97RXicM4fFHr++rNX1LXmvcrv3ePmxgZSoVYN5rqYOvMxhjO8KKczs3riJQtAmCqsiHQ==
X-YMail-OSG: UEmBjRsVM1mv.Y0i_Rsj_N6SHa4wGiNysjfsxMto5O5ngEwCPjNaswrzy0xfab5
 R1TzXvZQPsaLFGFitY5J3Z.0_YEzLYYNhvPVwYUm31I63RcN2YUldugVTqLLrtetGX20e3bQ4jtK
 c_WknM5J8KH1dMxczVaND5Zy306pIXY2BNePAOgelEgx5yFCpCx_I9qeUe8UPKvUR2mMKMuazbfo
 h.rPgqfp4dbyX6fLT9aaq0OHZKBFkwXJ5HK0jbUauXkgAujwc5f5yBYcC.MfrHOJjP0S5BThHEb3
 g6yBMJqXH2U.Bg7XRX5bTllxhKlo5YrGjT2dg3E9MGbon5E4unY4hXHYAGOaSHqhhSncjlBkwmWJ
 P775tOIPWZnLycsH.qBrrdCc5_kRHOMrgOH4WyhDWjghiItrwXaW1LaXveSZoZfgEtf23l8y2Sl1
 6AiAiV6Rw63OQiDrVZSwirPtzcSySDk14P1.bG23kDJ3a9s1WWkIC8uL8S80br6gPvdp1ln9MZVN
 ntnmsLr.aycZqI1m9RpM_CqOMgowOnMAIyPixRTztEetBw105PCOpDF83FBHf_8okcxlHuR.650k
 uGXFNTaykOErJfAegYx_ZxrxHYsavEVtn9uNbmlbN_I8nedWiXSWByYm14co5RzcugQWnpUyLqHg
 uFdZE5wUPw3EUO7nnfbSfR2.5nQaSwtou4t0CSzrWSO7JbUsr5eXr1s97SatmK.ypsQ5haPSKSmf
 zwdxgwdDlBFF1OQLJQ6kbnMLriXK9VhhX9YsOtPGe0GYCK6Cw8p.kXxHnAl5PJ2Nz.XgDrL8MfpP
 ctHVMpPF99dmxqFhsgHru8I4p11L56LK77DbC5HNMRhYyd0HGvVWTbGN6dMKhKsJCByVdJK6aTyl
 ud88QNYlBUNGopdvHHjg0bFXnVgNuurTv563J38PbYPoDoKGVntrU908mSOxyRpYL5hvPomIwFJn
 ZtNdtjtdLfZhv89jFpeyewTCLkJ37GbReo0D2Fx296oRNnUrBAXSYzskweLOOpm9JJmOsTsH4j5P
 bM5wWT84vujHnHN93jDMpzYUPch.UK2G_kGm_F5sx7EzYEOLbYIlGuLBe5hTXoZ7lED9UT1eDn.z
 d6_kx8vzvAsv8Wu3q9z44DfD6KGmxT_uUqEIzHrYaZr4rX7DxYQKMfftEmBvkJPq_0.VG8LJey0R
 Xew6gN0XPwvrZNJWqbKJFt2vq37QCioQ9s0CKPYYrzWEaRa0NtHnuxL_192OFQl1B4qnFV_Ff9Fu
 13MdHXPThMx50xmRCV9a_6bw99gSo7rIfJswePao7y297ikr64lOZbtvi.4Hngpjs9_1K4f1wSWO
 X6vn46apRhrCsPL.CPuVaChMOnHbq_IKlP0SLwev_mfR6422Wwq62X_loHJwc0pTS7kfyI4c_Vsg
 Ts5chXpJa9tkfSD3ny6bG5eIhvYPdFYDVjoM7PLKe7aBu6T2aR4uhwND3p2JBhSHCD3Yvt68IRTW
 ohLjXTXDco1.cg2kO0SFZWUqLWObpw5dKIa_EK.NdxjEHJEiDJuALtCcAQw5JB56Ed8PYpzfmajy
 F8.C9abmXM_mTqe4Pu7wfw3gJPQ3l.43yg0RzWwnE7.vI7jk0yzfaPYrwVHT1YwFitCbW.gRtR7n
 9SQBxdBkvEbtLO53lkoag1E5RQ96uPbcWClqMiA4YL6g9xU..FQ4zDRiu0hOr49ZCvOwPmdUjT.t
 cNUmYHkEObTkSrnqpb1Sv1QN96HvqXIZDzlKh06odhGAlu_L1WS1lvZKJrg4_pEelAaP7wgGidq_
 eZVEUAfH07h5KUyKFA1VLpfYxchn0MzRjuFz5ZfwGhJ19DOfNld2c8bOhpN_O.KjnW2BR3uEMRRS
 2BPXSWz.RsvJlcveguX9YkGVx0tWkEl65AtSRuppIQUqDn0qmnIOV8YhDU9YD4ehGzsS.cMjYANI
 8JGR2_qc3lrIifYD2P_yChakHL9v6z8AGP7_VqS8bI631W8nOGxmJ2cBKcx9gjvMxmIBSVOCH7LZ
 f_A978.dF317bLzfkcFLNOVGLjc8i1cNf37FlLg6TzXdJrjQahvhjiqbOpnfCjS_z_oMR4if8Z0O
 dOxYqK.mt_La2WrmmGzyr1YgX1xy9gwe_WeZosGiui_7WkRqw1l_ByCgV1IH0oL1JJiOntVgboIz
 QjSZQw201m5NZRUb8Y_XBdZd7KfFSueOeosheVz1iw1jVn0CiEnB67I2H2lC7rr6lfwA_5T4k9Ge
 W3gu0RSvvIVhDl0cZgvZ5Gns61l8uwlIjCFfywnsoZM_3ZM8_LD6tBZrgbnPyzOjzevgbCEKnsW.
 xaV4b
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 18:47:29 +0000
Received: by hermes--production-ne1-7864dcfd54-mdwhz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b407c1d08c1685a2dd3233ca9cfa693b;
          Mon, 04 Jul 2022 18:47:24 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <20220704182526.GB1771@www.zefox.net>
Date: Mon, 4 Jul 2022 11:47:23 -0700
Cc: Karl Denninger ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcFD845cKz4v35
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fmkDfY4L;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 11:25, bob prohaska  wrote:

> On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
>>=20
>> On 7/4/2022 11:28, bob prohaska wrote:
>>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>>>=20
>>> Can any sense be made of the few ping responses obtained when ntp
>>> is coming up? It's looks as if something happens after ntp runs
>>> that blocks subsequent network traffic, but why starting an outbound
>>> ping should partly unblock things is obscure to me.
>>=20
>> Yes.?? The odds are reasonably high that there is confusion as to =
which MAC
>> address maps to which device.?? This implies there's a loop between =
the two
>> switches (e.g. there is more than one way for packets to get into and =
out of
>> each said switch to the other) or the two devices are claiming the =
same MAC
>> address and thus when each "speaks" and performs ARP it "grabs" the =
map
>> which works until the next one pipes up and it grabs it.
>>=20
>=20
> Looks like that's the problem. There's only one cable between =
switches, but
> here's what I get from ifconfig on each host:
>=20
> On the machine running 13.1-R attached to switch 2:
> bob@www:~ % ifconfig
> lo0: flags=3D8049 metric 0 mtu 16384
> 	options=3D680003
> 	inet6 ::1 prefixlen 128
> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> 	inet 127.0.0.1 netmask 0xff000000
> 	groups: lo
> 	nd6 options=3D21
> ue0: flags=3D8843 metric 0 mtu =
1500
> 	options=3D80009
>>>>>>>> 	ether b8:27:eb:71:46:4e
> 	inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
> 	media: Ethernet autoselect (100baseTX )
> 	status: active
> 	nd6 options=3D29
> bob@www:~ % hostname
> www.zefox.org
> bob@www:~ %=20
> bob@www:~ % uname -a
> FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE =
releng/13.1-n250148-fc952ac2212 GENERIC arm64
> bob@www:~ %
>=20
> On the machine running an updated stable/13 system attached to switch =
1:=20
> bob@pelorus:~ % ifconfig
> lo0: flags=3D8049 metric 0 mtu 16384
> 	options=3D680003
> 	inet6 ::1 prefixlen 128
> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> 	inet 127.0.0.1 netmask 0xff000000
> 	groups: lo
> 	nd6 options=3D21
> ue0: flags=3D8843 metric 0 mtu =
1500
> 	options=3D80009
>>>>>>> 	ether b8:27:eb:71:46:4e
> 	inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
> 	media: Ethernet autoselect (100baseTX )
> 	status: active
> 	nd6 options=3D29
> bob@pelorus:~ % hostname
> pelorus.zefox.org
> bob@pelorus:~ %=20
> bob@pelorus:~ % uname -a
> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 =
stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20
>=20
> Thinking it over, I added the extra switch some time ago and didn't=20
> immediately notice any problems. Both Pi3s started out on the first
> switch (NetGear), with no obvdious problems. Later I probably moved=20
> one Pi3 to the second switch (D-Link) and started to notice troubles.=20=

> Does this story make sense?=20
>=20
>> Each interface device from the factory is supposed to have a unique =
MAC
>> address.?? This can, for most interfaces, be overridden (modern =
Android
>> phones "randomize" it if told to as a "security" measure) but for =
obvious
>> reasons doing that can lead to problems. Collisions where multiple =
devices
>> are using the same MAC will lead to exactly the sort of thing you're =
seeing
>> because the switch is sending the packets to the wrong place.
>>=20
>> I've got a decent number of Pis of everything back to the "2" here =
and most
>> of the time several of them are on my network at once.?? I've not =
seen this
>> problem but I wouldn't exclude that both are claiming the same MAC =
and, if
>> so, that's what's causing the problem.
>>=20
> [example ifconfig output snipped]
>>=20
>> That MUST be unique on your LAN; the prefix (first three octets) is a =
vendor
>> code /*and the last three should never be duplicated by a vendor. =
*/If you
>> are not setting it in /etc/rc.conf or elsewhere and there /are =
/duplicates
>> then a very bad thing happened when those units were manufactured -- =
set one
>> of them to something else.
>>=20
>=20
> Any pointers to MAC-setting methods appreciated.....

My example is not the best fit because it is for DHCP
but in /etc/rc.conf I use (but showing "??"s):

ifconfig_dwc0=3D"ether ??:??:??:??:??:?? DHCP"

to avoid its random assignment at power up.

So for you I would guess:

ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask =
255.255.255.0"


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jul  4 19:30:25 2022
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 428ED1CC0790
	for ; Mon,  4 Jul 2022 19:30:58 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LcGB937tjz3FlX
	for ; Mon,  4 Jul 2022 19:30:57 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 0EB2E2110A8
	for ; Mon,  4 Jul 2022 15:30:26 -0400 (EDT)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 90EF14ABA62
	for ; Mon,  4 Jul 2022 15:30:26 -0400 (EDT)
Message-ID: <35b616b9-6624-f3ad-6526-98fd0af31672@denninger.net>
Date: Mon, 4 Jul 2022 15:30:25 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: 13.1R problems on Pi3
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
From: Karl Denninger 
In-Reply-To: <20220704182526.GB1771@www.zefox.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080305060702020808050203"
X-Rspamd-Queue-Id: 4LcGB937tjz3FlX
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-5.64 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 HAS_ATTACHMENT(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_SHORT(-0.74)[-0.742];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a cryptographically signed message in MIME format.

--------------ms080305060702020808050203
Content-Type: multipart/alternative;
 boundary="------------taSOWlbHoIX0mdn3YEEe0dek"

--------------taSOWlbHoIX0mdn3YEEe0dek
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/4/2022 14:25, bob prohaska wrote:
> On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
>> On 7/4/2022 11:28, bob prohaska wrote:
>>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>>>
>>> Can any sense be made of the few ping responses obtained when ntp
>>> is coming up? It's looks as if something happens after ntp runs
>>> that blocks subsequent network traffic, but why starting an outbound
>>> ping should partly unblock things is obscure to me.
>> Yes.?? The odds are reasonably high that there is confusion as to which MAC
>> address maps to which device.?? This implies there's a loop between the two
>> switches (e.g. there is more than one way for packets to get into and out of
>> each said switch to the other) or the two devices are claiming the same MAC
>> address and thus when each "speaks" and performs ARP it "grabs" the map
>> which works until the next one pipes up and it grabs it.
>>
>   
> Looks like that's the problem. There's only one cable between switches, but
> here's what I get from ifconfig on each host:

"ifconfig ue0 ether xx:xx:xx:xx:xx:xx" (or the stanza "ether xxxxx" in 
the ifconfig line in /etc/rc.conf to set the address) SHOULD work.  Be 
aware that if it scrambles things you'll have to either use a console 
cable or pull power but that is supposed to work.  You may also have to 
drop the connection to the switch (either with power or by pulling the 
ethernet cable) for it to recognize that the port has "reset" and should 
be re-learned although once again that's not SUPPOSED to be required.

I recommend using the first three octets of some manufacturer that is 
basically impossible for you ever see on your network to prevent the 
possibility of stomping on something in the future by accident.  The 
list of manufacturers can be found here:

https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------taSOWlbHoIX0mdn3YEEe0dek
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/4/2022 14:25, bob prohaska wrote:

    

    

      
On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:


      

        
On 7/4/2022 11:28, bob prohaska wrote:


        

          
On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:

Can any sense be made of the few ping responses obtained when ntp
is coming up? It's looks as if something happens after ntp runs
that blocks subsequent network traffic, but why starting an outbound
ping should partly unblock things is obscure to me.


        

        
Yes.?? The odds are reasonably high that there is confusion as to which MAC
address maps to which device.?? This implies there's a loop between the two
switches (e.g. there is more than one way for packets to get into and out of
each said switch to the other) or the two devices are claiming the same MAC
address and thus when each "speaks" and performs ARP it "grabs" the map
which works until the next one pipes up and it grabs it.



      

      
 
Looks like that's the problem. There's only one cable between switches, but
here's what I get from ifconfig on each host:

    

    
"ifconfig ue0 ether xx:xx:xx:xx:xx:xx" (or the stanza "ether
      xxxxx" in the ifconfig line in /etc/rc.conf to set the address)
      SHOULD work.  Be aware that if it scrambles things you'll have to
      either use a console cable or pull power but that is supposed to
      work.  You may also have to drop the connection to the switch
      (either with power or by pulling the ethernet cable) for it to
      recognize that the port has "reset" and should be re-learned
      although once again that's not SUPPOSED to be required.

    

    
I recommend using the first three octets of some manufacturer
      that is basically impossible for you ever see on your network to
      prevent the possibility of stomping on something in the future by
      accident.  The list of manufacturers can be found here:

    
https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd3e4
    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------taSOWlbHoIX0mdn3YEEe0dek--

--------------ms080305060702020808050203
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MDQxOTMwMjVaME8GCSqGSIb3DQEJBDFCBECHAvZirGF4NCsQPArY
scC2FDRgat/pmcxP+G9rNGuhDvwZM8MFIRjiOBYuyE2YG6g+JwfyzAxF5/qvACoaOh1WMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgC9YXzQFwnO5PTJCNHVm9zMurOZx9S9qJEvGCHz
wxjJW24EbJW1Mi+VUW3r27Kf3dZ1h2CGb+MRkT2YpOxI4zUAyDtTO3cW6nh1qlJp77xTE23x
BiVNk5ZQxRmmQQeGqmkt8Vy40+idVXNhJmObN/jMFJO0yMMV5a8qV1k5Wd8zVGRfvpkwkowI
aEYxsJkkQho3TOh1CZ8JJlCHqaZ29Oz/VZZcsEDHXD0qlt/FW3mEO+glfcFf+pUDEsdb9mHZ
Gb/+8tt226cqzSUDIRrOYETgF3DZtRayF7LcXuRcDGONUoFN9TPkeU8S/rTsi2wnM8qdIzrT
6JHcQw7B4cZBQnneUkou6SLV6SE43CItGI2zLX0EmtotOv9tYyrbqvar3Ae8/4HZIX5rvnt/
oG+K7j8achlEM1oQM3geWeFmvFiUIdNVqmyjD571TJ46JmTS0IEWYpRR9wD9N1tmD4HSnq+e
uDtDkJTKJa8K7B19P853VSoUmEW8vgB0hGVWpIK4KldNTWnZimUiS46g+HymYNOE+WrwpANH
hBnLWKwyEd9FpGKGPf3ysY/0f+HjICf3HDyRqTXe82gR6kqiCE3DoEL43qvb4/J9gK9hXx03
4z7ZWITB40/sHDjEE+k4I2g6+7D83R+80Vqzmvn39/9TNRIyci8UutQC2xtjFxD1dlROgAAA
AAAAAA==
--------------ms080305060702020808050203--

From nobody Mon Jul  4 20:29:59 2022
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 5910E1CF8366
	for ; Mon,  4 Jul 2022 20:30:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4LcHVW1jkFz3MlF
	for ; Mon,  4 Jul 2022 20:30:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656966604; bh=NQn5Po4irgQUllBcv69at8Ea420J0BagA6TdDRntL+g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ftVNHM8ueJLy/x+m9Ie2NL5qI+JN+wmcNDbnJdNI+LHwkqNDurFcjn4EaFHPrtkQf/tqOlwI8X6UsnCPZI0pfXdxeXbRZpJqjPS0E/eIXTMw1neqLVweygfW9tP6bupyDofNVJIrgviuCEKgM/gBInHwBZg6ydlR1VGOWMooJpQqouxKb4V1jnyU9jBZhUcEvpUoKSi6mk6b/Njj4dXfm5jINCW4hwI7C5AAqMMNcaIoDl4o8vmJ886civiYTAeca+DXWSwe+px2KtKXwDC2brx/NPjk0594kSQwZB3oJcQFAWEmUh+CS+u45JUwCfeFhnaWlbduk7JjBXTbWN9OdA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656966604; bh=JGln6mTSCJs0kLgO1DQ2ztkceXxYsltq7LQMyWPndY1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QupEMW+w29mSnqN0fX88o9bDzJhuOFTg13A8hNMoG7YJKaHFe2fQgW1+jyFyFiGtFA9fx2brTqawRSCInivof3PoN6qmEUXMeLntBx+mk6Y/K9zNyqVoMsFkA2L7BASduXDcBqsnptgO5QieDR+Bpwo6+uGPts7qfICBz0ITY1qLYOlSH9Syq768bthm3jP+unJxvypFBUHDgCLdIKpqOBQV5lvjVJvEV5zjIL/+lqphTaj9RktIL248Ffq0wxmuk9ZcE5huBgtBq08K7VD/oXjrGriwVkQmsGGjrGGPxWeafIJdcLznUfx2g40kZieKAYlra2fXV9dPuf87R8Wvfg==
X-YMail-OSG: SNrLOy0VM1nXBtA6Lsd8TDOJbayrgHp4CXzNz0MDoXTdxPT4Ep7aiECEKWTCzGc
 RJ6bRY.QrE5UbtF8366hbkppxehiZ9EN6JEH3LOgWgOFAxCexBnsmBxmZ_J8JJh.OaXpO9bxjF1d
 .mRP_xf8cHBHXVd2B6JI5k9SqZUvg_BGmYoUm9A1HPrgOfANFSe3oHjqN8jS9mL6w5d0BPmuH561
 zjQJ4cPjQYCLa.Klq2Z4AgvwT6Re_LqDYWrVNjMU.PuO5Hs9I4iP_2cTatMgYh9FEWHt2KXy5tZa
 vsVTmiifSTKiJmsSUU8F45QwLpF5dTpqtxQbDXQr6e.MOU6OLCFdd7HJMnoeRPiZzBOqP4GlTDOH
 7UuF2X27Kf0j5poCywqcdm6EKrl5Mn8sTIdQEhrgsxOfVLasQair0XkCx7fCs8hCg1yw5zDyZqJi
 M9aey4E._I3OzBMECfCP5WN1kcs9eo3IPe.yeOKqPNbBAwWlMPBZR0x2jStDrnqdZxOcW1tJ.hgR
 LdwoT0qRBzBdyiAERyvn86izJJKYcCrcEnEZjw5DR1h062wTpPE47HsshBhtOcaypYRlBxxBfCcS
 4QAfnwOzavsQZWzeyJt2BQi5bA65OUGBVgCqxvl.srF_MAz8gfoe9bWOBXWdTETb_PQUDUVBXIv8
 XDZ1U2k64TWGcwvFksQe30dkZJ_hD8gK4ENmZXFXrORz.y4iSEzm04ogBAGeh1GwOzezvqMBwWWE
 3WH4YQwlWBSruH2rwHr5.eCwOC1WP0jX6hyW7tg3Ggpk.aofWptqeXJoQ50WrhQSN4HMsiaUyUsV
 JiC8RF_3Q_77BnV62nXRUfhnYBhrXNRSpKYn3JTYHXnbMewNai_FbFnbigS.Mw5oN.CdHLzrOjYh
 oO326ySRehSP6b8.1L8jx8jm923IFeDXiVbtp6ZTmyum5K5n_896fmp8iAzcwmCMuRzeXxMjm7mb
 8HHY4e.Pb_W8iKERYkcNxwSHFcW7lu30imdt5__f4JCLg2TnNYa7TqpVCtVWFtg_s6RcZQ_JhXoI
 WNM2OZbpLjzVYXWaOLSGHLUyuOMnQCXTCApJpqg7BwUaL3cCL1kwK7w6KHpYZGZzfnXS5VSQw5ky
 bLxrBC62j.s1NSMc.a3dXAljjGBSY7eFwXOWty1Hy9id0SjwzrDVGMoxc3Ef2BFVf4JLf7qOZFsJ
 VxhXt.Myr8CgkBYQeT3s1lsQ6KCgUlo1JSjUK5BCeERo.hhh316kr9p5LqoJvv61aYQMK6ahyhlb
 5NuhOTqrqPVpri0uqPpwPVsUeOe5s0MgzWZIgK2oLuKBark28knjbm2w.h2iugdRfpqdPkfYNRV7
 5pSkmHUeDvUYBkZtgzRNTC61QPu0ua3n4nQhjW.S9fSfep5HLCLThzFylk0Ut3.j.fmmb4kUqg4y
 i7yBRNRv3bwcjVU6vfMSWk25.CUcC5AIxEDTVfJC3yQKmcFDFB0Nyj80d_wX_6FxIq0rNZZFZv4s
 vV4KhRpnIGUSFH1H2ggMqImv6qUbDMDID2676p3XJky5SwbSwFskiGLcei3UakPVau.EmDNm9r94
 Jw8GuU9sqG_AdmGi1nsKQbZ0Y1BLCFzZvg9Xrlp7Xc1yNhC0HD3_RBE2BydK1bZpz6S124nuM1J5
 29R7kDS02WPEreynWjMupFQRMiKFRQ5tUaot1jv1_LhLIMDl55T_lD6grRGGvzBhbK0TRfGf0Sak
 7Sk5lO67Z8JdD2N5D92DimCs9ONrFHfNkbiv38bk9Dsxa6ZiFp0U0UHyceEYKwtK9cJpHkqMfD46
 25xa1eCkD7ChhyMht5dTJmXrqYYFpt9Xf2bdjQA2hNi9dhl8E8J4Yp4mY2MaL7AvF2UhOuVKyPrL
 EDK4kAlVlfZQXII0yHmT9e9DQ8ooktzvKR91FFZo9eQ0VlLr28Z1TwSO19YLyvXUiQUQ7ywbxAYS
 G34tG_zOnc_1DXzPpev3KCKVIv3mgPJ_OTmO4VcpofcY_cZ0TMO4vqpZNxD_g12qzHohg1izZn9k
 M2aDlZPjkXH0GbALBBCuG0mhDaz0EXvUPBEWG9EnqtF1slvBfkQLIx_FEnRVNAyj9zD2mhsqZuNv
 wuEqV0FoaLI1ZIWDyoWzAOT1lWDkU3vSFXJSzZsBgVt4b_vB4duCJdKm3LUYnym_yELwsCjPhlch
 s9YiM.C5fmyvhYcbxuC6Zc.tYx3UnSPyDWwjAFmpOzzPOO4GD3WH8QlpOu_FnD5hPp99QwogLMsu
 nukoGHhLELk5vW80SPbmSc5N62tqLTvEEvzJ6TRKMCDNtekxddsmLjKPPgD68TAgqAaTUGIU3r21
 LKnL8PRI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Jul 2022 20:30:04 +0000
Received: by hermes--production-ne1-7864dcfd54-dxcrc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45ce5fddcd8a01ee04aa87ef736860a1;
          Mon, 04 Jul 2022 20:30:01 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
Date: Mon, 4 Jul 2022 13:29:59 -0700
Cc: Karl Denninger ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8755F460-D5A5-4ED1-857F-37B894A9B875@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcHVW1jkFz3MlF
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ftVNHM8u;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.61 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.89)[0.887];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

[This ends with a possible config.txt way to control the
default Ether MAC address used, independent of which OS
happens to be running. Possibly better than using the
only-FreeBSD technique.]

On 2022-Jul-4, at 11:47, Mark Millard  wrote:

> On 2022-Jul-4, at 11:25, bob prohaska  wrote:
>=20
>> On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
>>>=20
>>> On 7/4/2022 11:28, bob prohaska wrote:
>>>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
>>>>=20
>>>> Can any sense be made of the few ping responses obtained when ntp
>>>> is coming up? It's looks as if something happens after ntp runs
>>>> that blocks subsequent network traffic, but why starting an =
outbound
>>>> ping should partly unblock things is obscure to me.
>>>=20
>>> Yes.?? The odds are reasonably high that there is confusion as to =
which MAC
>>> address maps to which device.?? This implies there's a loop between =
the two
>>> switches (e.g. there is more than one way for packets to get into =
and out of
>>> each said switch to the other) or the two devices are claiming the =
same MAC
>>> address and thus when each "speaks" and performs ARP it "grabs" the =
map
>>> which works until the next one pipes up and it grabs it.
>>>=20
>>=20
>> Looks like that's the problem. There's only one cable between =
switches, but
>> here's what I get from ifconfig on each host:
>>=20
>> On the machine running 13.1-R attached to switch 2:
>> bob@www:~ % ifconfig
>> lo0: flags=3D8049 metric 0 mtu 16384
>> 	options=3D680003
>> 	inet6 ::1 prefixlen 128
>> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>> 	inet 127.0.0.1 netmask 0xff000000
>> 	groups: lo
>> 	nd6 options=3D21
>> ue0: flags=3D8843 metric 0 =
mtu 1500
>> 	options=3D80009
>>>>>>>>> 	ether b8:27:eb:71:46:4e
>> 	inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
>> 	media: Ethernet autoselect (100baseTX )
>> 	status: active
>> 	nd6 options=3D29
>> bob@www:~ % hostname
>> www.zefox.org
>> bob@www:~ %=20
>> bob@www:~ % uname -a
>> FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE =
releng/13.1-n250148-fc952ac2212 GENERIC arm64
>> bob@www:~ %
>>=20
>> On the machine running an updated stable/13 system attached to switch =
1:=20
>> bob@pelorus:~ % ifconfig
>> lo0: flags=3D8049 metric 0 mtu 16384
>> 	options=3D680003
>> 	inet6 ::1 prefixlen 128
>> 	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>> 	inet 127.0.0.1 netmask 0xff000000
>> 	groups: lo
>> 	nd6 options=3D21
>> ue0: flags=3D8843 metric 0 =
mtu 1500
>> 	options=3D80009
>>>>>>>> 	ether b8:27:eb:71:46:4e
>> 	inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
>> 	media: Ethernet autoselect (100baseTX )
>> 	status: active
>> 	nd6 options=3D29
>> bob@pelorus:~ % hostname
>> pelorus.zefox.org
>> bob@pelorus:~ %=20
>> bob@pelorus:~ % uname -a
>> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 =
stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

Did you get the two RPi3*'s in the same purchase? Ending up with
2 that both happen to have b8:27:eb:71:46:4e seems odd unless
possibly the means of setting the values at the factory was
not varying the values like it should in some production lot (or
over some range of lots). Independent purchases at different
times would make it seem even odder.

>> Thinking it over, I added the extra switch some time ago and didn't=20=

>> immediately notice any problems. Both Pi3s started out on the first
>> switch (NetGear), with no obvdious problems. Later I probably moved=20=

>> one Pi3 to the second switch (D-Link) and started to notice troubles.=20=

>> Does this story make sense?=20
>>=20
>>> Each interface device from the factory is supposed to have a unique =
MAC
>>> address.?? This can, for most interfaces, be overridden (modern =
Android
>>> phones "randomize" it if told to as a "security" measure) but for =
obvious
>>> reasons doing that can lead to problems. Collisions where multiple =
devices
>>> are using the same MAC will lead to exactly the sort of thing you're =
seeing
>>> because the switch is sending the packets to the wrong place.
>>>=20
>>> I've got a decent number of Pis of everything back to the "2" here =
and most
>>> of the time several of them are on my network at once.?? I've not =
seen this
>>> problem but I wouldn't exclude that both are claiming the same MAC =
and, if
>>> so, that's what's causing the problem.
>>>=20
>> [example ifconfig output snipped]
>>>=20
>>> That MUST be unique on your LAN; the prefix (first three octets) is =
a vendor
>>> code /*and the last three should never be duplicated by a vendor. =
*/If you
>>> are not setting it in /etc/rc.conf or elsewhere and there /are =
/duplicates
>>> then a very bad thing happened when those units were manufactured -- =
set one
>>> of them to something else.
>>>=20
>>=20
>> Any pointers to MAC-setting methods appreciated.....
>=20
> My example is not the best fit because it is for DHCP
> but in /etc/rc.conf I use (but showing "??"s):
>=20
> ifconfig_dwc0=3D"ether ??:??:??:??:??:?? DHCP"
>=20
> to avoid its random assignment at power up.

"its": a Rock64, not a RPi* .

> So for you I would guess:
>=20
> ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask =
255.255.255.0"
>=20

Of course, I listed a specific inet of yours.


It appears that for before the RPi4B* based RPi*'s, the serial number
and the mac address were related. =46rom the network booting material
at:

=
https://www.raspberrypi.com/documentation/computers/remote-access.html#eth=
ernet-mac-address

there is:

QUOTE
Ethernet MAC address

Before configuring network boot, make a note of the serial number and =
mac address so that the board can be identified by the TFTP/DHCP server.

On Raspberry Pi 4 the MAC address is programmed at manufacture and there =
is no link between the MAC address and serial number. Both the MAC =
address and serial numbers are displayed on the bootloader HDMI =
diagnostics screen.

To find the Ethernet MAC address:

ethtool -P eth0
To find the serial number:

grep Serial /proc/cpuinfo | cut -d ' ' -f 2 | cut -c 8-16
END QUOTE

You might want to use some variant of RaspiOS to look up the
serial numbers and mac addresses on both RPi3*'s: Did you also
end up with duplicated serial numbers?

Another way to look is to use (in a RaspiOS variant):

# vcgencmd otp_dump

Row "28:" has the serial number and the last 6 digits
should match the last 6 from the MAC address for a
RPi3* . Rows "64:" and "65:" together hold the MAC
address.

Some folks have end up with rows "65:" and "66:" matching,
which should not happen but has been associate with odd
MAC address results: the MAC address ends up not matching
the 6 digits from the serial number, for example.


I've found references to an undocumented control in config.txt :

force_mac_address=3D??:??:??:??:??:??

See, for example, https://forums.raspberrypi.com/viewtopic.php?t=3D327562

Apparently, force_mac_address controls what value shows up in
the device tree for what the ethernet0 alias points to in the
device tree.

Note that having a odd .dtb file could lead to force_mac_address
not working. (The RPi* firmware reads the file and then makes
a device tree with some modifications applied.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jul  4 23:57:08 2022
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 BC32C1D09698
	for ; Mon,  4 Jul 2022 23:57:21 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.221])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcN5X4w5Vz4T1L
	for ; Mon,  4 Jul 2022 23:57:20 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1656979032;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:Date:Message-Id:Subject:From:Cc:Date:From:Subject:Sender;
    bh=aEdrj56s/DhHa2faix18ISBdQQbYgkiLTvayRMoqfH0=;
    b=A2GZXImgzB2O3BlCGtWceu0xrclxC1WxOe3K1ZZNGG6eTOtZHuA9CIAPMmsdUOZNrh
    j1L7jw9jb9LEGJVuZspFxuOoU5U9w9EoRdzMYBRRAoXTMRIMtlHCd7w6lVjXvmK4r+ia
    xkmPs5AG2ahIGiRl04awP85cJwxL368S1fz1NKkNxv5QcXw0NwbrhyDFvEN17stM1KmO
    bD0B6DJLd/gNOAWO7lzomnbB0khhBMsvEML3QgKYttMDdRmThznH5JwL5sWx3BS38u9I
    p5anrlOvjANFbT0YcdmVO4r3+g57LdwfGqcHxhK2L341AENp9vgjsy+2CfN3Dt8SghcT
    8ujA==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y64NvCHQI
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Tue, 5 Jul 2022 01:57:12 +0200 (CEST)
Received: from rolf-mini.obsigna.com (200-207-179-239.dial-up.telesp.net.br [200.207.179.239])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 7D1DF638CD
	for ; Tue,  5 Jul 2022 01:57:11 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-Id: 
Date: Mon, 4 Jul 2022 20:57:08 -0300
To: freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LcN5X4w5Vz4T1L
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=A2GZXImg;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.221 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-1.99 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[cyclaero.com:+];
	 NEURAL_HAM_SHORT(-0.99)[-0.989];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[200.207.179.239:received];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 DMARC_NA(0.00)[cyclaero.com];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[81.169.146.221:from];
	 FROM_NAME_HAS_TITLE(1.00)[dr];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello!

On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built 2 =
custom kernels, with kernel configs from different sources. Building and =
installing went through without issues.

cd /
fetch =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
tar -xzf src.txz
cd /usr/src

Here is the last kernel config which I used:

cat /usr/src/sys/arm64/conf/GENERIC-RPi4

   include	GENERIC
   ident	GENERIC-RPi4
   nooptions	SOC_NVIDIA_TEGRA210


make -j4 buildkernel KERNCONF=3DGENERIC-RPi4
make installkernel KERNCONF=3DGENERIC-RPi4

When restarting with any of the new kernels, booting stalls after these =
messages in the serial console:

   ...
   sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
   sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
   sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
   sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
   sdhci_bcm0-slot0: =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=

   uhub0: 5 ports with 4 removable, self powered
   mmc0: No compatible cards found on bus

The last line is not indicative for the error, since I see this as well =
with the original GENERIC kernel, only then it does not even think once =
and continues without pause in the boot sequence.

Is anyone able to build !!!working!!! custom kernels with the =
13.1-RELEASE sources on the very RPi 4?

Best regards

Rolf Jansen=

From nobody Tue Jul  5 00:57:36 2022
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 21D2E1D110F1
	for ; Tue,  5 Jul 2022 00:57:50 +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 4LcPRJ6xqcz4c2M
	for ; Tue,  5 Jul 2022 00:57:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656982660; bh=ogSMFVfMPYv81cKLLgEHWiCCX4VIE67588Rexd0qcI4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OVD+vxKGKImyNZJmGaiLkS//gOj0oEJLK7ujfcajsb/JGDqLGvXrMAZnKqH2m3SW7jhFCHciQYXvMAzbb/KAmxhFKF+UaI88JDUW4sPTSEmqC5c3LOWUuZooDHOFh4klw+T9nAlgLZ+9S9DlBckjfLVr/D3Zhj4jFmlVXp1bhETbrtMcTCa/FmkDAFJGkDbc5uqqRvmyb3HrIWniDF8PihfKefsqBvBtU5cUjUfEdG1YPy/idASVhPSCR3BQm1oUYMZzut8ooc43o2AbCiZBzPP6goNUsHNz8NwQuRbt1GCTAA9+u4glgGWb12WFa4a68JscEqYKkg3kVpdYWp31mg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656982660; bh=3vaDFixIbqsxKK5g9Fv62PgeHb3Wp74JMmCz/sDDySK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cyRqVAPWFFB+u83I76bMoxntG0Hac6g6DHlwjtJYwCsM/UZX4aS8VjoqkUuPWixhBSY84kAnsp0WOQFdbVC/y7ClsvTW+XqNORvoBze5NAGNgbSw0Lme3TQJyV8Zu6gJPynzzlgENQuQx27RmSTGZt5RjHtNsJCC95STbjlRbqycL9/SGjouDQsXlloiNC7XbdNXzXmzpfvI9gtSlXclngbVtUMWmTtGSJkGzBbZaBXyPwH8oWeKy9okQERTtylup+Bnz8xT9lDfxO9n6jqCRPXd6iWp/YWwqPZVzAaBcByfbBy6U675SDLVMFEcnbeDpj7/qvIxs25bzlJ9DlNXkA==
X-YMail-OSG: 1VOqTK0VM1k.Qu7sQlxYBiniFsFgrmcIXiEGioAJtRrFKbGX12tdtkIdjNUAvd_
 URTjNef23TiViR9E3kYAPc1AMPCKNDdoI6vuJKGTrZ3oYRO.akYa7T6XgXoTp0DwakVosovVl0X.
 g1BwL7ZNUERIyKgSAiUQ8YFvMS.qJWhBz2U72J2MKtJ05dv.HVoklfbcwhElrl1q5G6euQCHjjvN
 EDBgpT0O3L0WCF58TQWJn1STEWjZtdw6LWSha9FKSB8CmBQ.rJYGO0YH.y5Q6N9CfhV1uSpfJ8nJ
 po692wmr_If76CuoruX9_K0FF8ABVpruDx8E9T88psL3YHQd9JuUD9UbMbCdtzKpa7aE2BROviJ5
 f9tG.zIWaC8umOUcnN7iI5Zd1WrhJRG2FRehRrrmHTYR3k6Q2DObGD9ownCaN.U6Ulap_2vcs7.X
 .ZcB3aMTvUZYc5YxraRQpWiikIgTcBebDFSAEFas10ZPejHMZaanxAmlTsWfpGtGdXEqFE9hRpYr
 .LBnfM7tds1igcDT6E3bn4UL7NPyZCAk_w7y_666uR4.YV5QHQ89t7DEvrUTSr67bYpw8r1Wshfz
 zBud2eayAgyoPzt01_LtXpm4h43NiP_pDSnpLO7kDae7FL9JCzaVUV_t5ScpgyVpxWvR6ejPV.KP
 RLmGtzcpwdrlV_D20mBy4nx8CBqWpORUTqX1GpUygBIBI2Mb7qYbnPwZbCw61duyp7P8ev9ADf7A
 R4mngii0WXweJ7nQSBI97Sawp56XlXavCq7oZ1HJJA45YxylaASxzCY7S80XWHiXd2LY6q7iFoGi
 c9ta6gJACRLVoyNBUEfLyZlJXmL4N_hmbybc9MgO560VUbmk_kPepDCfBIYUGsO_CMA.Zk4mhRy9
 U0c5tMSnu6.thvJUjdxiaYGfDP2ZM1mHdmTWm_lwQOKRrFqgLBX99e2Y41z4oM6sj4IQ6A2IawW_
 XXjgN1GAWs5_k6dTqZ3e.kGiGE0EIBafMwrg19SoEJdKFAICoJEtnU6N0dP8oTQVZyvU2PqPKBKq
 MLRdJsxHake2p_4W_9h2a2gBH6DhOODo33kG0MFElawMTGE9ugmLDtuNRBo4sSCu1Oz3A5ukLY1s
 nv0tZd.y9riw8jpgBIvGg3Aoi66q4tBgTlu10zjrHEOBZo60bUYDB09m9twgP9dAQbORAwLlN.3N
 O.RZ8VFLFF4IrFCoSUAPagjEbGhQZ0rFm.GUkHlj_wjX2gcslgckJ1Q836H8ogRSIQVT3Lxpr68Y
 CtKZmB6dyjimoUKMkzWglhIKmqUEglQlOoOUa3cM1iyUZYmmsNjKW1EWc5tt.84RHBwlHZNLzgHu
 qdvmjE8J52DAsFypBeo5iHY5QGBW3gCq2AI3kVzYJTA7HoKfpXKA3sC.FN1ihikrfCWD0WZgfAru
 0VIixsDlXskR9z68WE7zEsvZmFfyPX0o_CyAimvWJTDQzB1fGWfRbmzNLt52wlwZPRdSt3OVTunF
 PtjnLN.IGWbFcW2HUzKziHOlVJaT27.gw4fgMq_7TYKmkOGTkmKXG.ChLKuaq.39CAs12bAJE.Qe
 rq6m1KVnGpOTXRZ08RiIi7N6nsGVM0rOaOQ89YMJeRoqecBTTsT1qMcB_WOwFmy_29z3ZzH.Mr64
 dVHEmYGeA56ryVzovcmwbSxk9Ky_9cPkGm4qojvjexqzHuRck8Mjzc_uuqiDwmhRD8g.bV1IVU7r
 3PlGmQkfTeZZCaOntjD0xB1XM5W5ibe2Xo3gzmvcfvGtU6uYurIkoYUgXjA417AVSaMSLmu5Bwrn
 DeTT6tyTgSlnNByCht9Qf1LhjOCxGMWVOluU.AAsvkOBX.exCk.Y9y2csYFbARqyFNYGG0MQ9rnL
 te4laRExWZCh64XrluAkgktYhzTYfOI7kM5yZfpsWGczvkEF8gUBLvyU6cNa7cU.4xouYV3woPFS
 Hqtlw7Lg5AehPRfd3BuuYBkbot38gC1DIQRV78DnZrzl37SG0O.vfhWkYSz0k.MwTxB8ObrW1de0
 4p8xE.udXSgOKnunaw5FPinKkaM.rg53NH1xC9MY.Q0rdM1.msSC_n7wCe0aSZ_wFGBajPilCuoW
 yQPNVAPGw6K9JFpiMcb8Zu_S4gAvWxQEGnOlIZM.A7d68icdT_Fo4lXXm.T7yvU.dzeArXxmf68P
 z2dfx_0baRWdHKHfSN0Pq4ESsWMA0wlKkcFOBA5SdmRfJTggMSiotrQiXMqXkUSvJa2k5OwCG4sO
 Txe7ILjKQRfJP8ZDNNfHn2_ry8vRc8yOfMXFbRo27FszBBSCavm9Xeg1P1MgoBojTcqTDlMH_xxC
 DwZiKDDqaGZ61q0b7YaSoCrW20Z32ykbELb8kbtSiiuC3u95rVue1C_V6CZTC2c3Qt5ZW1j2Y74o
 x
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 00:57:40 +0000
Received: by hermes--production-gq1-56bb98dbc7-x97s6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3c7db82fc258cd820a708ff93f47ca4b;
          Tue, 05 Jul 2022 00:57:37 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Mon, 4 Jul 2022 17:57:36 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
References: 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcPRJ6xqcz4c2M
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OVD+vxKG;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.24 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.78)[-0.777];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.976];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.990];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 16:57, Dr. Rolf Jansen  =
wrote:

> Hello!

Hello.

> On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built =
2 custom kernels, with kernel configs from different sources. Building =
and installing went through without issues.

Have you tried rebuilding the kernel without customizations to
see if the installed result boots? (Compare/contrast with having
the customizations.)

(I gather that the official 13.1-RELEASE installation does
boot the modern RPi4B okay. True?)

What type of boot media are in use in each boot test? microsd card?
USB3? USB2?

I have yet to have my hands on a 0xb03115 RPi4B variant (so: Rev 1.5).
It is my understanding that the RPi4B firmware vintage has to be
recent enough to correctly handle the new PMIC used on the rev 1.5
variants:

QUOTE (of RPi engineers on its forums on 2022-Feb-08):
The PMIC has been changed. Needs firmware from April 21 or later
. . .
The firmware in both Raspberry Pi OS - Buster (legacy) and Bullseye =
supports this. The bootloader has supported this since Apr 2021 =
(previous default release).
END QUOTE

See: https://forums.raspberrypi.com/viewtopic.php?t=3D329299

> cd /
> fetch =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
> tar -xzf src.txz
> cd /usr/src
>=20
> Here is the last kernel config which I used:
>=20
> cat /usr/src/sys/arm64/conf/GENERIC-RPi4
>=20
>   include	GENERIC
>   ident	GENERIC-RPi4
>   nooptions	SOC_NVIDIA_TEGRA210
>=20
>=20
> make -j4 buildkernel KERNCONF=3DGENERIC-RPi4
> make installkernel KERNCONF=3DGENERIC-RPi4
>=20
> When restarting with any of the new kernels, booting stalls after =
these messages in the serial console:
>=20
>   ...
>   sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
>   sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
>   sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
>   sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
>   sdhci_bcm0-slot0: =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=

>   uhub0: 5 ports with 4 removable, self powered
>   mmc0: No compatible cards found on bus
>=20
> The last line is not indicative for the error, since I see this as =
well with the original GENERIC kernel, only then it does not even think =
once and continues without pause in the boot sequence.

Looking at an old, saved capture of the serial console from a
prior RPi4B boot of main, I see the sequence:

. . .
uhub0: 5 ports with 4 removable, self powered
sdhci_bcm0-slot0: Got command interrupt 0x00030000, but there is no =
active command.
sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER =
DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00009902
sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_bcm0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci_bcm0-slot0: Present:  0x000f0000 | Host ctl: 0x00000001
sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00003947
sdhci_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb
sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_bcm0-slot0: =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
mmc0: No compatible cards found on bus
mmc1: No compatible cards found on bus
bcm2835_cpufreq0: ARM 2000MHz, Core 500MHz, SDRAM -1094MHz, Turbo ON
CPU  0: ARM Cortex-A72 r0p3 affinity:  0
                   Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 =3D 
 Instruction Set Attributes 1 =3D <>
. . .

This boot was via USB3, not the microsd card. Thus the

mmc1: No compatible cards found on bus

was expected in my sequence. Were you booting from USB3?
microsd card? . . .?

If the official 13.1-RELEASE image copy boots from the same
type of media, what displays at that point for the official
build? Is it a "bcm2835_cpufreq0:" line?

Note: the -1094MHz is from FreeBSD printing unsigned data
based on a signed interpretation. My configuration is set
up to run faster than the defaults as well ("ARM 2000MHz").

> Is anyone able to build !!!working!!! custom kernels with the =
13.1-RELEASE sources on the very RPi 4?

You might want to try a boot -v to have more stages
output. It might give more accuracy about the last
stage that can successfully output.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 01:33:48 2022
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 48D211D15B3A
	for ; Tue,  5 Jul 2022 01:35:25 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcQGg5vVhz4gd9
	for ; Tue,  5 Jul 2022 01:35:23 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 2651XmPD017773
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 4 Jul 2022 18:33:48 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 2651XmHh017772;
	Mon, 4 Jul 2022 18:33:48 -0700 (PDT)
	(envelope-from warlock)
Date: Mon, 4 Jul 2022 18:33:48 -0700
From: John Kennedy 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm@freebsd.org
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-ID: 
References: 
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: 4LcQGg5vVhz4gd9
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [1.12 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.79)[0.792];
	 NEURAL_HAM_LONG(-0.96)[-0.964];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(0.09)[0.091];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 04, 2022 at 08:57:08PM -0300, Dr. Rolf Jansen wrote:
> On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built 2 custom kernels, with kernel configs from different sources. Building and installing went through without issues.

  I've also got a new 8G RPI4, not sure how to get the exact model
number without popping the heatsink case off.  I haven't been running
13.1-REL since they haven't been incorporating some of the changes that
are in -STABLE (although for amd64, not arm64).

> fetch https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
> ... cat /usr/src/sys/arm64/conf/GENERIC-RPi4
>    include	GENERIC
>    ident	GENERIC-RPi4
>    nooptions	SOC_NVIDIA_TEGRA210

  I seeding my uboot (and ran initial bsdinstall to USB-only) from:

	FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220603-185159f77c9-250958

  I'm just building stock GENERIC:  I think I saw from another email
that you're avoid the SOC_NVIDIA_TEGRA210 (my ntpdate thread) because
it's messing with some extra stuff you're doing with your RPI.

  I'm using HDMI, vs any kind of serial console.

> When restarting with any of the new kernels, booting stalls after these messages in the serial console:
>    ...
>    sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
>    sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
>    sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
>    sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
>    sdhci_bcm0-slot0: ===========================================
>    uhub0: 5 ports with 4 removable, self powered
>    mmc0: No compatible cards found on bus

  I've rebuilt mine 5 times since 06-25.  Your serial console doesn't
sync up exactly what I see in my /var/log/messages, but Mark Millard
(who I think is relying to this thread too) just did a really
interesting breakdown between uboot versions for Bob Prohaska.

  Based on some of the threads I've seen recently, I'd:

	Make sure you have a recent uboot
	Make sure you're booting the uboot you think you are
	  (sim-cards having race condition with USB, etc)
	Just try with one sim or USB and, if that works,
	  start adding on extra bits
	Try HDMI, just for the yucks


From nobody Tue Jul  5 01:39:39 2022
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 53C241D16A5D
	for ; Tue,  5 Jul 2022 01:39:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(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 4LcQMn4qZTz4hr0
	for ; Tue,  5 Jul 2022 01:39:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656985182; bh=8y08io4RNBpMTLyY1II4fppWEJpPeGfzGT+hmC6cLh8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hU2H2ZeusI945hQapa0qMbCNre59NJeeZ/pTSC0wgOAPbbSLK/pL+IHukv7eKeT0VaRNZyqF5LNdzkiW7ln7ec0X6lxAO8ktcnbVEoGT2+CgOP0ezfXVY1jBw+wHOfveQfYhnB8ot5uV6Y6V+sCCaEG8Sd4qzqAazik3VIIThlahHt+digjpqI7i565H2aHYvxHAiQKs/kpg8zfr4ti6EwkAE4OD1Nfk4lfWQRJbSYNfnpkg1qKjqAFlLQy8F7r6ctZoXSI006SFC7wycG7MKkZD59I1fWwFOd4u5QoNPqu0DbxO9xV+GVJRDRMQ7pbRo/aKU27Q5kULvj0YGtmpTA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1656985182; bh=P/pKiwbCUjQCG0tSq7gfZ8t7yFOd0HPheFQDrsj4i8+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IkkFJYJ8p218mJkEnkQNYk1Zzo993VZnZuEjoe/ONqL/+L8UPo+iDW5tt+7CnNyVuMyIXPNjiwbu9T6aVAVNMN/nvOHk0VH293UId0ZnrUrMiikavKubZez1FnYJkJFSPwATXKR7QeIvRZDP8y5RGYXaR0F+Q38BvIGsWQqDdzo8tUKhzx8PUtuivKkOmkvYAgnLOs6/7DVzeBdBIoosBc6JJ2O10Q27ptDjKaZ2q1UOR3wq8RXGICDBdhbxn7BfC32dGHjSsNyh127cYcx/weuLB2JZ8ENFej8L1yC1+JX6f4wFGTKGUjkH1kUgWKffiYQljzQ30uZwkrs4zfKw+Q==
X-YMail-OSG: _qQA5QYVM1nTCFByzxi0ThQWbJ0y9i2XQ.7Jg8tvEHo3Vl6FTziE_sMqYfTLwKM
 L7WnV5H9Us88vMlnc3nznoizJDbqqldbNi6rKydXzkSUvqsyAqoBlmG0RnV8nbh_svIW2icOaGz6
 1tuytT9kqq1sxCWC.x81A1c8A5tJj77aao5MuO8wTevY60yFCdueZk9Xb4lA2QoI.7FAoMlFBe33
 1xaS5JYXO.FiOTeg_3VXAkgtyo.EGwL1y3YxHS.YQ819ABapSs3Yh2PRRCNMAPg7a25uUY_6BwF8
 .xbdmNCclvyOFXS7yhyruZh9oqQuTKAfuxP_u7gYODeSK_FyMkKmNkn4fAinrv_vPM6Hczm9tq6i
 2oi._40hOrCtMnCODdadzsMSli_mMvtl6e7Z4GTM7FHBbpmwM4nwZetey764VfZnD2droRQtuqvp
 ET5kV7j1jZGfd6xvAgFbMvZLctCQWG28sUPcvMaRLW8gRH1GjmqjB7.RPUl6TMjjiXFQNYmBbxNi
 9nAsZrUsKWYdKypwLCuowUfwJ_13hAPgAvORHOrWE8ymC6Kad4.Te1FQ7jBGV4_wArRnxWPr_Ft2
 V5PFepp2Ehu7s0ePAeI8xA4i2rOy53DkSjgCDUPry0RA4HZ_sy72ZZDyKiTQ3Uol4qANQdxnbNrf
 2hmLA7Xf_g6wYcJw5bo3q4XexB7FGXBvEO9T1ieUKx_M2elrbbvwFDUx6eKHBg2MA.FbhDBVh2RE
 uFfTYg2q1t.f.uB9FlA.5_0_zhI4ksS4.Iww7AjiEpLcQFgK2kJZ0OtX3tPSi0l7gjUXxlVx9JDH
 7_UvvHgzv.iLM6VO8xpkIJYKtChb6CnnPbFB8JBghNRWIwRs3rvFulvs26rK7xhjD0.tpF.g1sRR
 2UWsrBcxli7.Uz_Eq5QJP6y6eR.EkYaW_nhYfLbMyA5wzzVoyYjHiN2_b1AkNbqKPtdzLPFEOf6A
 8d3.bfO17GXPuf5h5C_x9ex_kO50EFRXhpGqqXeJlI5b6fBuFhkbIA_rTg8YCTggzr4zMfXkz7_g
 Ignss24VpdMUOZxwHOnO73zywhrDh1uIQQIYah.axH5lSKXzp_CS72VROy0VaQb2EWq6Shus1uLM
 uaj33f.fwBNhyF5QvP5BQssoUaPPnOG_AqhdIluiTDZrD1B0SmLf0qQ89_9ZnX3neT1xwCQAPKVx
 dzoYLtiFOnp1CKmF8EyMHxmUz1e2x3L7VLv5CFQi3lImXXp87E413aKu_uQhRjQFHa_bprTWNn5G
 o9.66sLVQspJhNFKfq_M41B8ensp7Sve1vaEikJ6cGh5eDOXWgy.TaUC8m2N6swJ27Ac_lCZhTnB
 xG9dytakDeBYkSNd3unSZjv.dzyoiqjJbYdnbCLZlOc84coHQ_cFNVwW5W9nsAMdXvD9owqoXNY0
 ei28uT4ZdVST8pC8_UkvxWa_GLu1MyexgnLp8HFHb9OZW7FKyM1_2iKLl63ibNVDm1X82D.5QZtC
 mrzFlMkuEtb3jcEpmJSd2IeugUpdzhF42C8mkURZdL5CxWb69ifuOhsXntHUZGh6jYonC5.KFVG8
 QeivvCteZ.8hTeUOpLOQ4n2njc2Ie0UVXEmDUeZ4AUYVHcfepHYh84.FaWhC2ttYIuArQddyiU43
 rK5op6Bx_vd48kn75Mze41iWD3EP587C28eZxM0ZKn..Wr1_zkng3mNaMQiEkuIrwvTSleBpRhK8
 Xb.Ww9CyrKAVaNqS654E30qscKzwV4._UV8Gd9iQFpjj9FZAWexVoh8.Swck2CIexrR1ePJ3gg1_
 GOjjDX0wuOikVx3zE_b1vBdj_hcjIaKtYpK2de8d6Aq42uqFzSIcKyb4dGFg8OlQEoEjoOz6qH6R
 a4HAKhpJoq4JHfgdqqcUarDRcin.z0OL1yrkA6sp5x7Ps0.ef.XJUIbsRItUG7EQQDP_8DZ5mvoL
 GfaTOXeBfZhfM3uissvIYqbD1apc7_OqZCdb5feFmAooDjnCu4TDPkXkqZTdaAQVg92WlncMVyuW
 _ZwtIjudTpXf5OzERR.O1FqY_Ed3Gwkm0kAtipBa1ryd1vijvrIp6q1L0X0LUpasa6UvbaZ3Eg_5
 ycWjizGEsE0wBPD9.iXiUNfkT1_QnkXpIeVB8MrDYVHqf9WD96hylswxGjN.Hbx31U92uCdq2enU
 VJkAdDyF6iifuENjrLN8JXcBAdzOJPYvDAJFDr_Ck_8xTn78tERc3zXuM9.VGFhBraNKwKU6soSm
 K44JeNGEllX.r0zZrtPeBx6CYzuCM4zQjRtVJSnhAURle0hD1TgsLt8v.djYiA5LVNlhMZzBu1eJ
 VY.5MWma7ypzvzU2N3H7CvEpKOiYn4CIjmXltMqSuetdiHW2qtrQFwbQ4Sl30WeNNIgZrnw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 01:39:42 +0000
Received: by hermes--production-gq1-56bb98dbc7-6v5v5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b1b09fffa619f236305c7e787e1de333;
          Tue, 05 Jul 2022 01:39:40 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
Date: Mon, 4 Jul 2022 18:39:39 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <531137B1-0501-47AE-BC2F-62F57067356B@yahoo.com>
References: 
 <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcQMn4qZTz4hr0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hU2H2Zeu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.34 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.84)[-0.844];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.991];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 17:57, Mark Millard  wrote:

> On 2022-Jul-4, at 16:57, Dr. Rolf Jansen  =
wrote:
>=20
>> Hello!
>=20
> Hello.
>=20
>> On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built =
2 custom kernels, with kernel configs from different sources. Building =
and installing went through without issues.
>=20
> Have you tried rebuilding the kernel without customizations to
> see if the installed result boots? (Compare/contrast with having
> the customizations.)
>=20
> (I gather that the official 13.1-RELEASE installation does
> boot the modern RPi4B okay. True?)
>=20
> What type of boot media are in use in each boot test? microsd card?
> USB3? USB2?
>=20
> I have yet to have my hands on a 0xb03115 RPi4B variant (so: Rev 1.5).
> It is my understanding that the RPi4B firmware vintage has to be
> recent enough to correctly handle the new PMIC used on the rev 1.5
> variants:
>=20
> QUOTE (of RPi engineers on its forums on 2022-Feb-08):
> The PMIC has been changed. Needs firmware from April 21 or later
> . . .
> The firmware in both Raspberry Pi OS - Buster (legacy) and Bullseye =
supports this. The bootloader has supported this since Apr 2021 =
(previous default release).
> END QUOTE
>=20
> See: https://forums.raspberrypi.com/viewtopic.php?t=3D329299
>=20
>> cd /
>> fetch =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
>> tar -xzf src.txz
>> cd /usr/src
>>=20
>> Here is the last kernel config which I used:
>>=20
>> cat /usr/src/sys/arm64/conf/GENERIC-RPi4
>>=20
>>  include	GENERIC
>>  ident	GENERIC-RPi4
>>  nooptions	SOC_NVIDIA_TEGRA210
>>=20
>>=20
>> make -j4 buildkernel KERNCONF=3DGENERIC-RPi4
>> make installkernel KERNCONF=3DGENERIC-RPi4
>>=20
>> When restarting with any of the new kernels, booting stalls after =
these messages in the serial console:
>>=20
>>  ...
>>  sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
>>  sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
>>  sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
>>  sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
>>  sdhci_bcm0-slot0: =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=

>>  uhub0: 5 ports with 4 removable, self powered
>>  mmc0: No compatible cards found on bus
>>=20
>> The last line is not indicative for the error, since I see this as =
well with the original GENERIC kernel, only then it does not even think =
once and continues without pause in the boot sequence.
>=20
> Looking at an old, saved capture of the serial console from a
> prior RPi4B boot of main, I see the sequence:
>=20
> . . .
> uhub0: 5 ports with 4 removable, self powered
> sdhci_bcm0-slot0: Got command interrupt 0x00030000, but there is no =
active command.
> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER =
DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00009902
> sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
> sdhci_bcm0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
> sdhci_bcm0-slot0: Present:  0x000f0000 | Host ctl: 0x00000001
> sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
> sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00003947
> sdhci_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
> sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb
> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
> sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
> sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
> sdhci_bcm0-slot0: =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=

> mmc0: No compatible cards found on bus
> mmc1: No compatible cards found on bus
> bcm2835_cpufreq0: ARM 2000MHz, Core 500MHz, SDRAM -1094MHz, Turbo ON
> CPU  0: ARM Cortex-A72 r0p3 affinity:  0
>                   Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
> Instruction Set Attributes 0 =3D 
> Instruction Set Attributes 1 =3D <>
> . . .
>=20
> This boot was via USB3, not the microsd card. Thus the
>=20
> mmc1: No compatible cards found on bus
>=20
> was expected in my sequence. Were you booting from USB3?
> microsd card? . . .?
>=20
> If the official 13.1-RELEASE image copy boots from the same
> type of media, what displays at that point for the official
> build? Is it a "bcm2835_cpufreq0:" line?
>=20
> Note: the -1094MHz is from FreeBSD printing unsigned data
> based on a signed interpretation. My configuration is set
> up to run faster than the defaults as well ("ARM 2000MHz").
>=20
>> Is anyone able to build !!!working!!! custom kernels with the =
13.1-RELEASE sources on the very RPi 4?
>=20
> You might want to try a boot -v to have more stages
> output. It might give more accuracy about the last
> stage that can successfully output.
>=20

FYI in case it helps . . .

Back in late 2022-Apr I sent notices to the list about
my testing what vintages of RPi* firmware FreeBSD would
tolerate/handle, the end result being:

https://lists.freebsd.org/archives/freebsd-arm/2022-April/001302.html

The pre-Rev 1.5 RPi4B's and the one RPi3B that I had to
test worked for the firmware tagged 1.20210805 but not
for tags after that. (So: after 2021-Apr and so able
to handle the RPi4B Rev 1.5 PMIC.)

Basically, FreeBSD presumes an ordering in the .dtb materials
that is not required and changed in the more recent .dtb .
files. The result for the more recent firmware versions that
fail to mix well with FreeBSD is that FreeBSD tries to do
something with something that is not yet set up for such use
and crashes. The relevant definition that needs to be looked
up to do the setup is later in the modern .dtb content order
but in older .dtb versions happened to be earlier so there
was no obvious failure at the time.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 02:12:38 2022
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 390B91CFAA22
	for ; Tue,  5 Jul 2022 02:12:54 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.23])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcR5x173Bz4lpr
	for ; Tue,  5 Jul 2022 02:12:52 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1656987162;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=lLIydNnGTx+ZbVD7NbdWovrQAfrwvOtykpqz5LZ1SAE=;
    b=c4XQ1tk53+dBJChlUMDaJzBdpi0NJ6g5NtgxeiI5eZo6jLH5A4RWBdcnTn8Ks2BE+L
    qKALiPCHP5IBiTzRztXHZBwFG4ZKlv3H+BjNQAxcNQQxrrh7Gvp2DAd031JxyCmf0Y39
    /J19EOAMPIGscDL+DraJXnf3HMRzZX24YwLt2eagiQknMXeIR8b4vosyV1wnL8Lj/G/V
    a5Khy9rZq1ayHICbnzSEM8C+YhxY/2ftFjxFHf1nErbHl22ohT8RVqC5Jrioclik+LJS
    udu0DkikmtZ7WXH98NkBmOGbHlGqfo6Wz035TxuC9Ne9h1xqkb7ODTaEFiuRD2crnYzd
    Wpvg==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y652CgHTM
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Tue, 5 Jul 2022 04:12:42 +0200 (CEST)
Received: from rolf-mini.obsigna.com (200-207-179-239.dial-up.telesp.net.br [200.207.179.239])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 89C20638E2;
	Tue,  5 Jul 2022 04:12:41 +0200 (CEST)
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 12.4 \(3445.104.15\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: "Dr. Rolf Jansen" 
In-Reply-To: 
Date: Mon, 4 Jul 2022 23:12:38 -0300
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LcR5x173Bz4lpr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=c4XQ1tk5;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.23 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[cyclaero.com];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[cyclaero.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[85.215.255.23:from];
	 FROM_NAME_HAS_TITLE(1.00)[dr];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[200.207.179.239:received]
X-ThisMailContainsUnwantedMimeParts: N

> Am 04.07.2022 um 22:33 schrieb John Kennedy :
>=20
> On Mon, Jul 04, 2022 at 08:57:08PM -0300, Dr. Rolf Jansen wrote:
>> On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built =
2 custom kernels, with kernel configs from different sources. Building =
and installing went through without issues.
>=20
>  I've also got a new 8G RPI4, not sure how to get the exact model
> number without popping the heatsink case off.

In the serial console I see:

   U-Boot 2022.04 (Jul 01 2022 - 06:22:22 +0000)

   DRAM:  1.9 GiB
   RPI 4 Model B (0xb03115)
   Core:  196 devices, 13 uclasses, devicetree: board
   MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
   Loading Environment from FAT... In:    serial
   ...

This was just, when stating 14.0-CURRENT. In the serial console I can =
scroll back, while on a HDMI screen this would rush away too quickly, =
but perhaps you would be able to take a photo, for finding out your =
model's revision.

> I haven't been running
> 13.1-REL since they haven't been incorporating some of the changes =
that
> are in -STABLE (although for amd64, not arm64).
>=20
>> fetch =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
>> ... cat /usr/src/sys/arm64/conf/GENERIC-RPi4
>>   include	GENERIC
>>   ident	GENERIC-RPi4
>>   nooptions	SOC_NVIDIA_TEGRA210
>=20
>  I seeding my uboot (and ran initial bsdinstall to USB-only) from:
>=20
> 	=
FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220603-185159f77c9-250958
>=20
>  I'm just building stock GENERIC:  I think I saw from another email
> that you're avoid the SOC_NVIDIA_TEGRA210 (my ntpdate thread) because
> it's messing with some extra stuff you're doing with your RPI.

In 13.1-STABLE the RTC issue was fixed as well. If I can't built a =
custom kernel on 13.1-RELEASE then I will stay with 14.0-CURRENT, even =
if I would have preferred RELEASE, but a working RTC is more important =
for me.

> I'm using HDMI, vs any kind of serial console.
>=20
>> When restarting with any of the new kernels, booting stalls after =
these messages in the serial console:
>>   ...
>>   sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
>>   sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
>>   sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
>>   sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
>>   sdhci_bcm0-slot0: =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
>>   uhub0: 5 ports with 4 removable, self powered
>>   mmc0: No compatible cards found on bus
>=20
>  I've rebuilt mine 5 times since 06-25.  Your serial console doesn't
> sync up exactly what I see in my /var/log/messages, but Mark Millard
> (who I think is relying to this thread too) just did a really
> interesting breakdown between uboot versions for Bob Prohaska.

OK, here I just found out the build of a 14.0-CURRENT custom kernel does =
execute without any failure.

I forgot to mention, that I tried to get the 13.1-RELEASE custom kernels =
to work by installing the most recent u-boot.bin from the ports. This =
didn't help either.

Best regards

Rolf Jansen


From nobody Tue Jul  5 03:14:15 2022
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 5835A1D017E8
	for ; Tue,  5 Jul 2022 03:15:43 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcSVQ50xQz4rct
	for ; Tue,  5 Jul 2022 03:15:42 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 2653EGd2017951
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 4 Jul 2022 20:14:16 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 2653EFs8017950;
	Mon, 4 Jul 2022 20:14:15 -0700 (PDT)
	(envelope-from warlock)
Date: Mon, 4 Jul 2022 20:14:15 -0700
From: John Kennedy 
To: Mark Millard 
Cc: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-ID: 
References: 
 <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
 <531137B1-0501-47AE-BC2F-62F57067356B@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: <531137B1-0501-47AE-BC2F-62F57067356B@yahoo.com>
X-Rspamd-Queue-Id: 4LcSVQ50xQz4rct
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-0.60 / 15.00];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.993];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(0.14)[0.137];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.94)[-0.939];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 04, 2022 at 06:39:39PM -0700, Mark Millard wrote:
> ... I have yet to have my hands on a 0xb03115 RPi4B variant (so: Rev 1.5).
> It is my understanding that the RPi4B firmware vintage has to be
> recent enough to correctly handle the new PMIC used on the rev 1.5
> variants:
> 
> QUOTE (of RPi engineers on its forums on 2022-Feb-08):
> The PMIC has been changed. Needs firmware from April 21 or later

  Mark, do you know how to find that info just using FreeBSD?
Looks like there might be some uboot stuff, but I haven't managed to
catch it during a HDMI boot.


From nobody Tue Jul  5 06:41:37 2022
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 08DC21CFD579
	for ; Tue,  5 Jul 2022 06:41:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4LcY4G0SFSz3pXT
	for ; Tue,  5 Jul 2022 06:41:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657003302; bh=xIkQ/4sZ+EEoCeQgrsmwiCu56mDVoO0rFgf+B2UsCvo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sg5KTfPMmzWbAAHR+emwG4DzL2eJQCdhig1aULtnNeME5DFR5SDUTJL1ss9dWjfQ+on5KveM2gPpTkT4Yv+WNRayQ8xC+C16X7tpZsTIIrqsmRDqwiCWs95PLH4HcxNeJkamADBjwNTWo5OieRjk7jm992V/1fNQuqwBXHA5Ye+nRreFhfbqcW2+TZfBOkemn2yAaqnxgKay2KSsd9vAvaw6E6Nkwre/TxWXDAunPTkcJpkhEPte5Yq8dIL8plSb4aTEGQizV3UdOlQq+TSURsOH8z6zotCxdlMz5aJh5zu8fxWPSVZGYRopyHyutr545t0zSyrmv/p+aQXO8IUtTg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657003302; bh=GvIgwuwIbUSrNooYPyh2/aYpOJdrGDTbhB9KOb2dQfW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kizEju6WIOu8JMuYihlfNXa9EptRoDehhH3e346efD/QI1c7RBub/risqS8PoINyC4+8Js4Ae/1TQjyTOEf6Rayb/ESayfXhGQZlUSO0d607LJHiiCRbult+yc+pGkQWwzwvtc7qO++OSw2ubNvGSAWHsv8XGHJEzye4ydvjK2Z9Lf/vm9mmvDWbLVPmHoaI6fUFNjYsNFlfbZsToQAKdbwJArdkoPsJed9IzAKFj2SNfGYhWIGGsRUufIdfvJTfl4XS0S+fzHusa87vat9OSQkeoWK6U6Z+vQSX5tfVwvFdExzY8SGi5wwaia0nw4IOXe6IZBb4DymwQpLmi/ZgRQ==
X-YMail-OSG: vZNBEcgVM1k2peUr0p1S0ml_q9oRBLee.TdzOG1zjk3N0dc0.GnZQSbn9N5aDF3
 YSLQ2aNu_VElUa8L_YI_VUMXP0hQNoUsgQWIFM9HTmO4yo5dEEpHZNEyuz9GyZIpR9GN7GQXVkku
 .6XluOefzKl1RniMk19Wj8Tz6..Bwmo3nEwl_WMqcwlGNieilpjjptuqbS6HOG0Gd4XL5PBqqLqw
 3Dc6EDtRybrEhXotVMXbuhhGCOTPmSXGQrkVI4eAC.onnfRxZExm4X2Ifaea0uU6vQgeXmN7LOIc
 .cHux_O403.k7d2jZqGnC1qeArzheayITof8pAANbGTZcoFajqpaOJIe0t0Mzg8F.kbDsDsk7dZK
 0f4WdhfAXQxRPJJhlsG8jlExeuiIgadChyVwmsFGppuR1eagA9SutQOeGdS2Nmi_jZFico65Ppp4
 7eVHreGKqKnMUKZkzNUDKFaOW7gNhiwFlLCyTDLF25MjovQYaywgdzr.hZ24d9C1UNuviBPTEdno
 mS54xBbzs06GMo4EWy8F8inVHBRpPq5Y.q1Ac.VLR8sCFI04ewdktm2S5e4SA.cfR43_dXVzx3qB
 7SFyjOrW96XnvS_K_Kw6R6cbKHNhMwTDIjRWsRFL_FXE6pRxr2BS5_jmk9Wnw4W2wKuIWQ4eBQgp
 1_jPbUp77ZZH5G8dC4r_LBJ7fT0.QHiCDhyuw.c5wE6gBfwjKBi2x9GWoI9LWHyLhZM0vcUVa1tD
 XHBNZPSeSocEYm8g8d6b2BYSIv6KHg.7DB7frX3hrzdL9euuBKUUvwDo1H3mZCIoy3_jFi6ivrAx
 mFlhR35HWUA.6cF04dm8LhvHPv9AEIsVyG_W5tGUFKHWWPVJqIYnYhXCGw40JOn3G3PU7kBDcIdo
 _9w4UaKVfFRo7kQP.BliQrwZ7JmZLZZH_1TEx4tsC2g2HmCKd10c38dsvlevkn4QYLDaRnwUWp4Z
 UZ86UDIVClMPtsdPAxDGrWZQY.hckkcZ7zx7lQ2k7WWCc6RAX_ECdEfzgQA8Xpz__LNji_IvN7EV
 A.oyxyRYeZQaKRx.F9QX9wC0.7dejttMvG5i6LsXW3zYkJsDorhkUSS9YM_c72FyEiITiHxfPs1u
 bSiUFoymuN8Nc9cfBKQVW17wiHePpW8dOsNcOLHzx8FY5r60NpQi9J0NptdyyejMxl1X2U11fcoC
 aa_xnLHw7Qk_PWmb0jOekHSUE5j31N2jicJ7gfmSpZ9gt3fnsm6jyKX2K7jzSv56SZdq7sXAWDvl
 RYeEqpE1BmBMC7ikOrZ5XE4BDdAHHLdOUk0M65zrItYwNZCfIQpbmMs5aEKVP6S4457HWDZj9N.n
 wamLaX0.Rkl_JiC29OBGJtaxMy4qGhxcrRaLsNvlRWOMMKLeCZbfmwzKqP9Gv2yPKYHviRvcEhfg
 axQB1OxV28md4Kc5u7HmhyVae.OZ08dugv7pHg9l5Y5LIiNnc8yLFZpLxuQUCCNhKx5xsohwm5wZ
 5WOtiNRLGXRaFYjYkdB4UcwtV24Ulx0sVltCa5lX_X95zNyjKhExS1BYL3ASio55Pcnih2lI2oB3
 dFWwLDMM_QFoa6v13fFWXvJN7H3YjFzgwA_a_cPWHoGgKSi7Q56sSwil98NbyB3zrOB0a0KnIqH3
 _Za9CMJNRsq6a7Ml4G4BwFbDCNgYoeeWRHMDuqcV6giV5wNpTTJU_Hhrpacz0O3iCPcFwG_yQcUM
 98nfl3G94Xby_6eIWOqqu7ICfhdQMghtBKZRmwKcV1.bHSeBX_HoMFOE6cuHJvRQ9yybf85Eo3oi
 mINNJtbtrN0DnV3oxdy90Sq2Oy6z33_tZKtHQlCrOX_OaniHbnWwRfSeBlGnbvhRYAJo4vUjjmiS
 ZS8XftI1yAnTiUsZlODBaUOZi9Ue2O8e7LZCFM_i106BA68XBpTgnV8AeaE7C6832LJDNmTRbqOw
 DoZNrOdXRCG6bB8VZ_eGHGIK2iaNum9EExV4ndzg9mNGdbYwrbGB4sEUjzeLJxfsvW6WoX5_5DPD
 n5s_VSKOgd_YFbZiEOORwte6zW4IMtBqZLj00VdKcvt_vPV0m_c6HCIsINfTztAGNZbliJz2CGZH
 XQyUJhhpapCm70vMwZgwerdUFxZNd_shRPn.4IJa.VOT0sWM6g9Jx5NsP0dxSw6muM6DIZwpZFdN
 3c8TML7lTiTEs2ctlvX37U4Aeqil7hUrCROSaU6hH_NNocR1kopgjwIAKjNEs2rMYJPKEPWefMq4
 XKpIMgYGwRmvEYYqISlPVv.4WxlcdZxmQbby9fFk1birCMQ93pYmmJ2l0BEonsm7gwVs3b5Rel1P
 JQ1ji
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 06:41:42 +0000
Received: by hermes--production-bf1-58957fb66f-bs7vm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 404c71b094db1ad9695b1d20170a0eba;
          Tue, 05 Jul 2022 06:41:39 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Mon, 4 Jul 2022 23:41:37 -0700
Cc: "Dr. Rolf Jansen" ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
 <531137B1-0501-47AE-BC2F-62F57067356B@yahoo.com>
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcY4G0SFSz3pXT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=sg5KTfPM;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 20:14, John Kennedy  wrote:

> On Mon, Jul 04, 2022 at 06:39:39PM -0700, Mark Millard wrote:
>> ... I have yet to have my hands on a 0xb03115 RPi4B variant (so: Rev =
1.5).
>> It is my understanding that the RPi4B firmware vintage has to be
>> recent enough to correctly handle the new PMIC used on the rev 1.5
>> variants:
>>=20
>> QUOTE (of RPi engineers on its forums on 2022-Feb-08):
>> The PMIC has been changed. Needs firmware from April 21 or later
>=20
>  Mark, do you know how to find that info just using FreeBSD?
> Looks like there might be some uboot stuff, but I haven't managed to
> catch it during a HDMI boot.
>=20

Note: I do my own builds, installs, and configuration
experiments. Do not expect my example outputs below to
necessarily match those for official builds.

For reference from my root-on-UFS aarch64 environment that boots
via U-Boot (not via EDK2 UEFI/ACPI):

# df -m
Filesystem          1M-blocks   Used  Avail Capacity  Mounted on
/dev/gpt/CA72USBufs   1322130 224991 991368    18%    /
devfs                       0      0      0   100%    /dev
/dev/gpt/CA72USBefi       259     29    230    11%    /boot/efi

Your builds or standard-build details may vary
for what I have as /boot/efi/.

# sysctl hw.fdt # Likely a RPi* specific sysctl name?
hw.fdt.serial-number: REPLACED
hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4


I'm not aware of being able to identify the RPi4B
EEPROM content version from FreeBSD, nor the configuration
defaults that are present. But it can be important.
(More notes later.)


Presuming that one has not mixed and matched RPi* firmware
files from different RPi* firmware builds, the start*.elf
files have version identification information (that predates
the tagging date when it is declared as expected to be good):

# strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 18:14:56
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Aug  3 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 40787ee5905644f639a2a0f6e00ae12e517a2211 (clean)

So it may take some comparisons to match up with
officially tagged versions or other specific versions
the FreeBSD ports may sometimes use. Similarly for
which FreeBSD port version it matches up with
(presuming it does).

I'll note that the PMIC issue is not a U-Boot issue
but just a RPi* EEPROM version and RPi* firmware issue,
as far as I know anyway.


I'm not aware of anything useful to find in
/boot/efi/armstub8-gic.bin (or armstub8.bin) for
version identification.


# strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20'
U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000)

The date here is the build date, not the version
date. So it can be useful in matching up with
FreeBSD port builds if you have used an official
FreeBSD port build's content.

This does not indicate which of the several
RPi* related u-boot ports is involved. For
aarch64 RPi*'s the modern one used by official
builds is:

sysutils/u-boot-rpi-arm64

It supports the widest range of aarch64 RPi*'s.


# strings -a /boot/efi/efi/boot/bootaa64.efi | grep 'EFI loader'
DFreeBSD/arm64 EFI loader, Revision 1.1

But, so far as I know, that one is nearly useless.


As for the RPi4B EEPROM mentioned before: I'm not aware
of a FreeBSD equivalent of either of the below for
identifying the CURRENT version:

# rpi-eeprom-update
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
   CURRENT: Tue Jan 25 14:30:41 UTC 2022 (1643121041)
    LATEST: Tue Apr 26 10:24:28 UTC 2022 (1650968668)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

# rpi-eeprom-config
[all]
BOOT_UART=3D1
WAKE_ON_GPIO=3D1
POWER_OFF_ON_HALT=3D0
DHCP_TIMEOUT=3D45000
DHCP_REQ_TIMEOUT=3D4000
TFTP_FILE_TIMEOUT=3D30000
ENABLE_SELF_UPDATE=3D1
DISABLE_HDMI=3D0
BOOT_ORDER=3D0xf41

I boot a RaspiOS64 microsd card for the related activity.

For reference for the default (a.k.a. critical) ones:

# cd /lib/firmware/raspberrypi/
# ls -ld bootloader/default/*.bin
-rw-r--r-- 1 root root 524288 Apr 29  2020 =
bootloader/default/pieeprom-2020-04-16.bin
-rw-r--r-- 1 root root 524288 Sep 14  2020 =
bootloader/default/pieeprom-2020-09-03.bin
-rw-r--r-- 1 root root 524288 Apr 30  2021 =
bootloader/default/pieeprom-2021-03-18.bin
-rw-r--r-- 1 root root 524288 Apr 30  2021 =
bootloader/default/pieeprom-2021-04-29.bin
-rw-r--r-- 1 root root 524288 Feb  8 07:07 =
bootloader/default/pieeprom-2022-01-25.bin
-rw-r--r-- 1 root root 524288 May  3 05:21 =
bootloader/default/pieeprom-2022-04-26.bin
-rw-r--r-- 1 root root  87940 May  3 05:21 =
bootloader/default/recovery.bin
-rw-r--r-- 1 root root  98904 Jan 22  2020 =
bootloader/default/vl805-000137ad.bin
-rw-r--r-- 1 root root  99224 Sep 14  2020 =
bootloader/default/vl805-000138a1.bin

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 09:55:56 2022
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 DEA521D16445
	for ; Tue,  5 Jul 2022 09:56:05 +0000 (UTC)
	(envelope-from SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LcdNN5rCpz4gVs
	for ; Tue,  5 Jul 2022 09:56:04 +0000 (UTC)
	(envelope-from SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 5 Jul 2022 11:55:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1657014957;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=aMsUCuOJpu46AlObVCcc+TbB5BbDITk1+jZnDnjjlmQ=;
	b=nqG11UQbJ3Okm5D7Q2Cl4afeKnztmS74joGjTtb3yYrWKRwsaIUopnzl53BSB6iFUBITSG
	0HYwyrR879xQcLEQb/g2v860ZVOG238AuQKlSko5KBz1fedIYbhHOcpqHo+NNZYEY/4BLV
	54vsAykIuyvS4E6FmRy/YLRAHphlk9ri6wMsrJNqCmNXvOTpzuU+/t2ano/3XzH893p8cr
	eRDF787VLUojc9oMYF9ZA4TE7IUjYpSVbYd9D9oDgjDlxfK2R8FeUf6M44z4NKjMiZRSjJ
	0DQvHsQiHx5mqPfF3cSwOQuRfe2SAj4ER3C4eR/ISc/5tadl7JEWzE9bjbSVRQ==
From: Ronald Klop 
To: Mark Millard 
Cc: Karl Denninger , bob prohaska ,
	freebsd-arm@freebsd.org
Message-ID: <1645012198.135.1657014956867@localhost>
In-Reply-To: <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
Subject: duplicate MAC - Re: 13.1R problems on Pi3
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="----=_Part_134_2008716236.1657014956808"
X-Mailer: Realworks (613.97.a0c3c70)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LcdNN5rCpz4gVs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=nqG11UQb;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Ua7A=XK=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_134_2008716236.1657014956808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mark Millard 
Datum: maandag, 4 juli 2022 20:47
Aan: bob prohaska 
CC: Karl Denninger , freebsd-arm@freebsd.org
Onderwerp: Re: 13.1R problems on Pi3
> 
> On 2022-Jul-4, at 11:25, bob prohaska  wrote:
> 
> > On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
> >>
> >> On 7/4/2022 11:28, bob prohaska wrote:
> >>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
> >>>
> >>> Can any sense be made of the few ping responses obtained when ntp
> >>> is coming up? It's looks as if something happens after ntp runs
> >>> that blocks subsequent network traffic, but why starting an outbound
> >>> ping should partly unblock things is obscure to me.
> >>
> >> Yes.?? The odds are reasonably high that there is confusion as to which MAC
> >> address maps to which device.?? This implies there's a loop between the two
> >> switches (e.g. there is more than one way for packets to get into and out of
> >> each said switch to the other) or the two devices are claiming the same MAC
> >> address and thus when each "speaks" and performs ARP it "grabs" the map
> >> which works until the next one pipes up and it grabs it.
> >>
> >
> > Looks like that's the problem. There's only one cable between switches, but
> > here's what I get from ifconfig on each host:
> >
> > On the machine running 13.1-R attached to switch 2:
> > bob@www:~ % ifconfig
> > lo0: flags=8049 metric 0 mtu 16384
> >   options=680003
> >   inet6 ::1 prefixlen 128
> >   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> >   inet 127.0.0.1 netmask 0xff000000
> >   groups: lo
> >   nd6 options=21
> > ue0: flags=8843 metric 0 mtu 1500
> >   options=80009
> >>>>>>>>    ether b8:27:eb:71:46:4e
> >   inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
> >   media: Ethernet autoselect (100baseTX )
> >   status: active
> >   nd6 options=29
> > bob@www:~ % hostname
> > www.zefox.org
> > bob@www:~ %
> > bob@www:~ % uname -a
> > FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64
> > bob@www:~ %
> >
> > On the machine running an updated stable/13 system attached to switch 1:
> > bob@pelorus:~ % ifconfig
> > lo0: flags=8049 metric 0 mtu 16384
> >   options=680003
> >   inet6 ::1 prefixlen 128
> >   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> >   inet 127.0.0.1 netmask 0xff000000
> >   groups: lo
> >   nd6 options=21
> > ue0: flags=8843 metric 0 mtu 1500
> >   options=80009
> >>>>>>>     ether b8:27:eb:71:46:4e
> >   inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
> >   media: Ethernet autoselect (100baseTX )
> >   status: active
> >   nd6 options=29
> > bob@pelorus:~ % hostname
> > pelorus.zefox.org
> > bob@pelorus:~ %
> > bob@pelorus:~ % uname -a
> > FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> >
> >
> > Thinking it over, I added the extra switch some time ago and didn't
> > immediately notice any problems. Both Pi3s started out on the first
> > switch (NetGear), with no obvdious problems. Later I probably moved
> > one Pi3 to the second switch (D-Link) and started to notice troubles.
> > Does this story make sense?
> >
> >> Each interface device from the factory is supposed to have a unique MAC
> >> address.?? This can, for most interfaces, be overridden (modern Android
> >> phones "randomize" it if told to as a "security" measure) but for obvious
> >> reasons doing that can lead to problems. Collisions where multiple devices
> >> are using the same MAC will lead to exactly the sort of thing you're seeing
> >> because the switch is sending the packets to the wrong place.
> >>
> >> I've got a decent number of Pis of everything back to the "2" here and most
> >> of the time several of them are on my network at once.?? I've not seen this
> >> problem but I wouldn't exclude that both are claiming the same MAC and, if
> >> so, that's what's causing the problem.
> >>
> > [example ifconfig output snipped]
> >>
> >> That MUST be unique on your LAN; the prefix (first three octets) is a vendor
> >> code /*and the last three should never be duplicated by a vendor. */If you
> >> are not setting it in /etc/rc.conf or elsewhere and there /are /duplicates
> >> then a very bad thing happened when those units were manufactured -- set one
> >> of them to something else.
> >>
> >
> > Any pointers to MAC-setting methods appreciated.....
> 
> My example is not the best fit because it is for DHCP
> but in /etc/rc.conf I use (but showing "??"s):
> 
> ifconfig_dwc0="ether ??:??:??:??:??:?? DHCP"
> 
> to avoid its random assignment at power up.
> 
> So for you I would guess:
> 
> ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
>  
> 
> 
> 


Hi,

My Rpi3B+ does not have a random MAC on ue0.

NB: It uses the muge driver:
# devinfo | more
...
      bcm283x_dwcotg0
        usbus1
          uhub0
            uhub1
              uhub2
                muge0
                  miibus0
                    ukphy0
...

Your current MAC is officially from the Raspberry Pi Foundation: https://hwaddress.com/oui-iab/B8-27-EB/ .

Could you have hardcoded the MAC in a *.dtb file or other config in the /boot directory and copied that over to the other RPI?

If you are going to assign some MAC yourself take a look at https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local_(U/L_bit) to choose a locally administered MAC.

Regards,
Ronald.
 
------=_Part_134_2008716236.1657014956808
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Mark Millard <marklmi@yahoo.com>

Datum: maandag, 4 juli 2022 20:47

Aan: bob prohaska <fbsd@www.zefox.net>

CC: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org

Onderwerp: Re: 13.1R problems on Pi3







On 2022-Jul-4, at 11:25, bob prohaska <fbsd@www.zefox.net> wrote:



> On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:

>>

>> On 7/4/2022 11:28, bob prohaska wrote:

>>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:

>>>

>>> Can any sense be made of the few ping responses obtained when ntp

>>> is coming up? It's looks as if something happens after ntp runs

>>> that blocks subsequent network traffic, but why starting an outbound

>>> ping should partly unblock things is obscure to me.

>>

>> Yes.?? The odds are reasonably high that there is confusion as to which MAC

>> address maps to which device.?? This implies there's a loop between the two

>> switches (e.g. there is more than one way for packets to get into and out of

>> each said switch to the other) or the two devices are claiming the same MAC

>> address and thus when each "speaks" and performs ARP it "grabs" the map

>> which works until the next one pipes up and it grabs it.

>>

>

> Looks like that's the problem. There's only one cable between switches, but

> here's what I get from ifconfig on each host:

>

> On the machine running 13.1-R attached to switch 2:

> bob@www:~ % ifconfig

> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384

>   options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

>   inet6 ::1 prefixlen 128

>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

>   inet 127.0.0.1 netmask 0xff000000

>   groups: lo

>   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

>   options=80009<RXCSUM,VLAN_MTU,LINKSTATE>

>>>>>>>>    ether b8:27:eb:71:46:4e

>   inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255

>   media: Ethernet autoselect (100baseTX <full-duplex>)

>   status: active

>   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

> bob@www:~ % hostname

> www.zefox.org

> bob@www:~ %

> bob@www:~ % uname -a

> FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64

> bob@www:~ %

>

> On the machine running an updated stable/13 system attached to switch 1:

> bob@pelorus:~ % ifconfig

> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384

>   options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

>   inet6 ::1 prefixlen 128

>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

>   inet 127.0.0.1 netmask 0xff000000

>   groups: lo

>   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

>   options=80009<RXCSUM,VLAN_MTU,LINKSTATE>

>>>>>>>     ether b8:27:eb:71:46:4e

>   inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255

>   media: Ethernet autoselect (100baseTX <full-duplex>)

>   status: active

>   nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

> bob@pelorus:~ % hostname

> pelorus.zefox.org

> bob@pelorus:~ %

> bob@pelorus:~ % uname -a

> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

>

>

> Thinking it over, I added the extra switch some time ago and didn't

> immediately notice any problems. Both Pi3s started out on the first

> switch (NetGear), with no obvdious problems. Later I probably moved

> one Pi3 to the second switch (D-Link) and started to notice troubles.

> Does this story make sense?

>

>> Each interface device from the factory is supposed to have a unique MAC

>> address.?? This can, for most interfaces, be overridden (modern Android

>> phones "randomize" it if told to as a "security" measure) but for obvious

>> reasons doing that can lead to problems. Collisions where multiple devices

>> are using the same MAC will lead to exactly the sort of thing you're seeing

>> because the switch is sending the packets to the wrong place.

>>

>> I've got a decent number of Pis of everything back to the "2" here and most

>> of the time several of them are on my network at once.?? I've not seen this

>> problem but I wouldn't exclude that both are claiming the same MAC and, if

>> so, that's what's causing the problem.

>>

> [example ifconfig output snipped]

>>

>> That MUST be unique on your LAN; the prefix (first three octets) is a vendor

>> code /*and the last three should never be duplicated by a vendor. */If you

>> are not setting it in /etc/rc.conf or elsewhere and there /are /duplicates

>> then a very bad thing happened when those units were manufactured -- set one

>> of them to something else.

>>

>

> Any pointers to MAC-setting methods appreciated.....



My example is not the best fit because it is for DHCP

but in /etc/rc.conf I use (but showing "??"s):



ifconfig_dwc0="ether ??:??:??:??:??:?? DHCP"



to avoid its random assignment at power up.



So for you I would guess:



ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"





===

Mark Millard

marklmi at yahoo.com



 










Hi,



My Rpi3B+ does not have a random MAC on ue0.



NB: It uses the muge driver:

# devinfo | more

...

      bcm283x_dwcotg0

        usbus1

          uhub0

            uhub1

              uhub2

                muge0

                  miibus0

                    ukphy0

...



Your current MAC is officially from the Raspberry Pi Foundation: https://hwaddress.com/oui-iab/B8-27-EB/ .



Could you have hardcoded the MAC in a *.dtb file or other config in the /boot directory and copied that over to the other RPI?



If you are going to assign some MAC yourself take a look at https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local_(U/L_bit) to choose a locally administered MAC.



Regards,

Ronald.

 
------=_Part_134_2008716236.1657014956808--

From nobody Tue Jul  5 12:47:12 2022
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 AFDDD1D050FA
	for ; Tue,  5 Jul 2022 12:48:41 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcjCX6KXgz3GVH
	for ; Tue,  5 Jul 2022 12:48:40 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 265ClClI019262
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 5 Jul 2022 05:47:12 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 265ClCIG019261;
	Tue, 5 Jul 2022 05:47:12 -0700 (PDT)
	(envelope-from warlock)
Date: Tue, 5 Jul 2022 05:47:12 -0700
From: John Kennedy 
To: Mark Millard 
Cc: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-ID: 
References: 
 <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
 <531137B1-0501-47AE-BC2F-62F57067356B@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: 4LcjCX6KXgz3GVH
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.79 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.995];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 04, 2022 at 11:41:37PM -0700, Mark Millard wrote:
> Note: I do my own builds, installs, and configuration
> experiments. Do not expect my example outputs below to
> necessarily match those for official builds.
> 
> For reference from my root-on-UFS aarch64 environment that boots
> via U-Boot (not via EDK2 UEFI/ACPI):

  Gah.  There is so much more out there than RPI4 now for arm64 I didn't
stop to wonder if bsdinstall set it up right.  I just reformatted
/boot/efi and slapped the uboot stuff in there because that was the way
the SDcard image was set up.  I left it as /boot/efi (vs /boot/msdos).

> # sysctl hw.fdt # Likely a RPi* specific sysctl name?
> hw.fdt.serial-number: REPLACED
> hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
> hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4

	# sysctl hw.fdt
	hw.fdt.serial-number: 
	hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
	hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5

  Aha, that is what I was looking for.  Wasn't even seeing that with
hw-probe, and I wasn't going to interrupt the 12-hour llvm13 compile to
reboot and see what I could with uboot yet.

  There is this guy, Mark Millard, who writes these really good mailing
list emails that makes me paranoid about uboot version mismatches.  :D

  I haven't even looked at the EEPROM firmware stuff.  Reading the list,
it's all been such potential foot-cannon fodder seeing some people's
issues I just knew it would be a potential problem, but happily it just
worked as I would have hoped.

> I boot a RaspiOS64 microsd card for the related activity.

  Yeah, I haven't been doing that.


From nobody Tue Jul  5 13:51:50 2022
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 2648E1D0F1E7
	for ; Tue,  5 Jul 2022 13:53:19 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lckf619mJz3hWJ
	for ; Tue,  5 Jul 2022 13:53:18 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 265Dpo0p019390
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 5 Jul 2022 06:51:50 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 265DpogP019389;
	Tue, 5 Jul 2022 06:51:50 -0700 (PDT)
	(envelope-from warlock)
Date: Tue, 5 Jul 2022 06:51:50 -0700
From: John Kennedy 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm@freebsd.org
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-ID: 
References: 
 
 
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: 4Lckf619mJz3hWJ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.78 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.98)[-0.978];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

  Let me take a slightly different track here...

  I believe you've said that 14.0-CURRENT (which works without hanging) and
13.1-STABLE have fixed the RTC problem but you'd specifically like to be
running 13.1-RELEASE.  I think you've implied that you've booted up on
13.1-RELEASE (but did have RTC problem, presumably because the changed
haven't been MFCed all the way into the releng/13.1 branch.  The delay
is the whole reason I'm running stable/13 myself, although like I said
for amd64 reasons and just keeping the arm64 systems par.

  While Mark has made me a bit paranoid with what could go wrong at the
pre-FreeBSD stages, if you can reliably recompile 14, those wouldn't
seem to be an issue, if everything else is constant.

  Personally, I wouldn't run 14 in a production environment.  It's been
very good to me in a bhyve environment, but it's not called -STABLE for
a reason.  The reason I like releng/13.1 over stable/13 is that I have a
Pavlovian urge to keep things patched.  So I can totally appreciate you
wanting to run something stable and secure that doesn't get too many
updates.  I'd just try to aim you at stable/13 vs main, at least if you
can't backport the RTC fix into releng/13.1.

  But that being said, still a custom kernel of sorts, yes?

  So is your 14.x setup the same as your -RELEASE setup?  When I
bootstrapped myself initially, I burned a SDCARD and booted up (passed,
so check).  Then I did the bsdinstall onto my USB disk, stomped on the
EFI/msdos contents with the known-good SDCARD contents.  Yanked out
SDCARD, booted up, ok, USB-only known-good there.

  Happily, I could pkg-install things (like git) to recompile the
kernel+world.  Reboot with that, "custom" kernel check.  Recompiling all
the packages locally was a nice stress-test.

  I don't think "downgrading" from 14 to 13 is generally recommended (in
my case, ZFS options would generally get me, but I believe you said
you're UFS).

  Basically, you've got situations where uboot can hand off to modern
FreeBSD kernels on your hardware.  I think you're seeing a lot of lines
of text because we're being paranoid about blind spots where you can't
see some missing error message that would pinpoint the problem.

  All else being equal, if you can boot a stock 13.1-RELEASE kernel
image, you should be able to recompile that kernel in place and expect
it to boot.  So we're looking for the "not equal", something that we're
assuming that is wrong.

From nobody Tue Jul  5 14:02:18 2022
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 8265E1CF8537
	for ; Tue,  5 Jul 2022 14:02:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4LckrZ1snpz3jtP
	for ; Tue,  5 Jul 2022 14:02:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657029741; bh=Tu436f7wYjKa5i9PKcuBVcIPUURtLopLzIHAfyf91ak=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tuZEs3lelQPYmsSK/i6sWz3gQlQ86hPNxu9JjVd48a8OnYhYaHEXt7RFilfdxqWDN9+Z8qyErztAxPB4GyWwKm4r8/x21PojsuPjmv2PI+HI1d+vzmsiV3WavzGKvyPcV9tcFj+QCN88GBPQJa9V4ysAleTdlqn7IAucKNbzQ9URX9J4ZoZiYpLH9JVXw3YRDXf/Zb4dj2DQt7lo9Rs3WwMO696ZhXBlppTIEA3/l45H+nmddhJwACJksBnBl3b0K9gz2aAom97jlF/7VEAT/kTr2hSCDrM9mhUHo216GNwaQ3rKiysR+r7oJdXnknVNYNSdLi9+PLg1yCuWWpX3Vg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657029741; bh=v+2GYBBIPe6BnUIbjuSqeRIL+qZ12ompP7HO/seb/FK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZXrDonHo3CPSie6SwchXFyfvG6KchCpYxAEy7oOQMalXMrpA9w+HsTjLSjWxoC1W75CKIahH77064ltiMa2gP7J1E36jd1IoKB2LsXo9kO/E2cWR3Um42MeBOX1VSMOsdGC3bA9LNGAV9u0rDocaIdltBnzL+XJ0Q4JHA620k/E50QBHrDBWfEx8nde64BIDt3WSXwhcHIP9zhe6RZDauJJ0wvqSdXV+CyKfYj1rCtXOI+XIEAdwH4TVYTcmx1WULLsxJpg4FWhrjfrtUQ0mBTM8/Rkumex4dy/fl/QqGwqRLC4VXbPfvag1CAhAeO+sMQc18u1CDA1wWJTwHLz+rw==
X-YMail-OSG: oblnvqcVM1kjfV2tiK6.SdVpWs_60wgjg5EiToDEG55h5efqA843MR8A6OIInPV
 SiWy4e4FSqgKENAFb7gaRu2Z2k1Vcv1zkhK.nX_8Qs2NuZh4Vo_j9OH5IW3olBU0M1DwNyWGcR.L
 11HW7LGAWK5P22dxTaFpoyFT_hrrp2f211xsQy8l6ZdLv_eBUjBwRslSl3NnfDibXOn8ZGO_0Yn0
 .IUNus4jEYBGRgZ2TxC0nQ6x_qQbWYOjMnUc7rVbVTtEtTy9lAjwRkw6R9wFDNStQYVyk6MFg1Gz
 CUfPoT0dluvkZPEx7HS1xFaW9vO0Ljb1RIkS47KYl_rbEaxzD3gb4ZStRsU3fMcUdiGs13HES5mk
 v3.RBYIZs_Vb4i.zyzljKC0kI_x2CWuv6iARW86Mtb3HZDNjKoy5qm9OpX9fyO1V2Qaf1_qo7Pkt
 9zKGJUCo2AnlABOadS_DbOXyIiNp9IjqY3J3.X0_o514Zr5RMvLQB.8_It.T2I6U5GLkOeWLbuUl
 yZSeqJpVHI4_tZQmUQ12Np9wJ67KFgvHIEUIwnFk74vo4RoQsmT9u5ZW_jTBxUXk.J6jvtiN4lIN
 CBWphd2GKVGhDQ9ji0ihXSBPB942B5B.clnJrkTKjrt6Sf_0my._Eskey6azpDrLGVaG3o3ZAdhR
 tRJKpRDgEUtBULGTBjpVo0rBfDujJ7Kwgjs0p4pd.bwPTYSDWx6PXj4X3iPr7o2ImTcpRK6c1yDE
 hqaVPX_JCAVXIOjaKbADf7KTgE.nlZd7XN7MMr8wxlM97yR.J4zzr1y_rF7OeXsqOm_s9p.CSui7
 X0VMdq.AcQiqH3fISQ06SREKGjl_vrmZlo1JJjH2LC1iY_KJtOJjRPIQGq1xN4Ket2wIelm5dJZ5
 Rg_ZAanq9MIf_iLo1GEG4.kZr9vN7ZQtE6QDB1xdhLA3WIH40O1CqpA0QBXkerXx7WPduZyGD2pC
 AA5.K0wt__rVZWB17_gAHCO_w1JhWlgGsfXPM1pazz2CXExV72R2ta8C6n2ErABr_IbELmtMlKph
 I2JPHkjWVKRS51WaMIZOXi9VdsQMpIQShpg.pA1tDI5al7.O4W7aEIdm_WGUPYTqCrnTzGZFjVZk
 N2mvIhBnUqmEpkn33h43H.ZH2W08hQ429k1.fhu.0ERBwk7itQgEb3O7eJu.DjnjlkBepYYrqUDP
 _RXjmCWnAqzFYBDrP9J3ZjZUbjcKde363nCq5sCmk0f4pR1IXJX.DAPLNnBohNYV89XU1lPvVpmJ
 RxeuIqOzK.FIspvTTVgvbJPHLCiOPA5JvXeLky0Zkzzhqs7jnCrXiHxU0sRZFvQpGRIBxRN.RPLC
 9onRGdGZ4OMfK95ZdfhWbiCR6yOoW8gu_FnVByMniA5zy1RrgBFR.KnvjwY_MsHhTjv.T7oFfJL9
 _9joo.HvTsOUGN6yJ.UYNgI.tUbvOxq.vXYGbKNuUr.gzVeZ7fn6zokC1rX_8ruLLsp0dTXaHN72
 jj.E8ulkikrwHk_jN0u_fedLlnnJp8ep_.H5SFDNJ2ljnj3oMkIQhW_zj3wuHgqwjey6GkOK67md
 IbM3p9TF7xyskqHA33jYOl8l8khZUbpHOWGx1lKQjObr0i1Dq5c1eH0fczwFhWy6ksEQgD_ZKyxL
 lXCnvhmwNfp95jfJFckGfm3BRDCyA2APHclzh3lRAmYgdfm1_ZhRQZ6HJnRhQVBGYn_R9uiNHOt_
 JOJMqVmiGoaqAMLapxvFqJI2zK0I7xWUoqJ6hTQ2UbutC5G6TX1_C703U5pmsAclmfNe4KG1K0ih
 w31ZTX7n5HZScwsmpNdP.eALLszDhNtOLt7Xgv01Hp0qHeCKaFrpF4p8RM4IqD0ZQrGpEOaoJNTC
 k8NkJn1M0Y8BxeEGOOBMQ6037WrZeVeG9xb.glyhYtrzGMMQjdjxWbzptrJHT9tOWCAG_2RClzIQ
 fTE8eJ214ZH0b7BcSB4kokvZADAkjTxKkqs1JdPSijl.4T0QFU0nufH0qINsbl8ORqWZYSCr3SIT
 YvskE.3Iiom4S04YreqCjnqf7D9Ul0mXjC3OUvfO3tYS8aDo4SZ4KsqO6hqoZQhp5UZYrjUKkxdO
 sXT8n2rqm4r..3AIEcUqqARu8vjlOuBf.mLqEhTTJgIVCOpYPky7XDUoa32Ja4fi_eypaGDoKezz
 BLSJlWPnnpa3H0712VcATiP.LQIzieKh0oHeNuFs2j5HH39o1BIxHnw.XPypUUqkuFNc9OdFDRIT
 o1dNtexUoZSlK0Pz9CEmP2Bwlak.Tjnc6xD98LVvKDoPYBP2sIkCx6W6S4m.2BtSHb.7ruciEBEw
 Q4Qxk8Z_LXM0ODAIe6vjxKwpyPDELbZDiwyeb96YeDo_eVeENoSGba.woLpRU
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 14:02:21 +0000
Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ef5c3a2dc2b54e76484b8337dba9b5f;
          Tue, 05 Jul 2022 14:02: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 14.0 \(3654.120.0.1.13\))
Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <1645012198.135.1657014956867@localhost>
Date: Tue, 5 Jul 2022 07:02:18 -0700
Cc: Karl Denninger ,
 bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <1645012198.135.1657014956867@localhost>
To: Ronald Klop 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LckrZ1snpz3jtP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tuZEs3le;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.69)[-0.687];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

[It may be that you got your TO: and CC: list a
little mixed up. But I was listed as the TO:
and Bob P. as a CC: . I'm answering on that
basis but Bob P. is one with 2 RPi* that have
the same MAC address in use.]

On 2022-Jul-5, at 02:55, Ronald Klop  wrote:

> Van: Mark Millard 
> Datum: maandag, 4 juli 2022 20:47
> Aan: bob prohaska 
> CC: Karl Denninger , freebsd-arm@freebsd.org
> Onderwerp: Re: 13.1R problems on Pi3
>=20
> On 2022-Jul-4, at 11:25, bob prohaska  wrote:
>=20
> > On Mon, Jul 04, 2022 at 12:17:15PM -0400, Karl Denninger wrote:
> >>
> >> On 7/4/2022 11:28, bob prohaska wrote:
> >>> On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote:
> >>>
> >>> Can any sense be made of the few ping responses obtained when ntp
> >>> is coming up? It's looks as if something happens after ntp runs
> >>> that blocks subsequent network traffic, but why starting an =
outbound
> >>> ping should partly unblock things is obscure to me.
> >>
> >> Yes.?? The odds are reasonably high that there is confusion as to =
which MAC
> >> address maps to which device.?? This implies there's a loop between =
the two
> >> switches (e.g. there is more than one way for packets to get into =
and out of
> >> each said switch to the other) or the two devices are claiming the =
same MAC
> >> address and thus when each "speaks" and performs ARP it "grabs" the =
map
> >> which works until the next one pipes up and it grabs it.
> >>
> >
> > Looks like that's the problem. There's only one cable between =
switches, but
> > here's what I get from ifconfig on each host:
> >
> > On the machine running 13.1-R attached to switch 2:
> > bob@www:~ % ifconfig
> > lo0: flags=3D8049 metric 0 mtu 16384
> >   options=3D680003
> >   inet6 ::1 prefixlen 128
> >   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> >   inet 127.0.0.1 netmask 0xff000000
> >   groups: lo
> >   nd6 options=3D21
> > ue0: flags=3D8843 metric 0 =
mtu 1500
> >   options=3D80009
> >>>>>>>>    ether b8:27:eb:71:46:4e
> >   inet 50.1.20.28 netmask 0xffffff00 broadcast 50.1.20.255
> >   media: Ethernet autoselect (100baseTX )
> >   status: active
> >   nd6 options=3D29
> > bob@www:~ % hostname
> > www.zefox.org
> > bob@www:~ %
> > bob@www:~ % uname -a
> > FreeBSD www.zefox.org 13.1-RELEASE FreeBSD 13.1-RELEASE =
releng/13.1-n250148-fc952ac2212 GENERIC arm64
> > bob@www:~ %
> >
> > On the machine running an updated stable/13 system attached to =
switch 1:
> > bob@pelorus:~ % ifconfig
> > lo0: flags=3D8049 metric 0 mtu 16384
> >   options=3D680003
> >   inet6 ::1 prefixlen 128
> >   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
> >   inet 127.0.0.1 netmask 0xff000000
> >   groups: lo
> >   nd6 options=3D21
> > ue0: flags=3D8843 metric 0 =
mtu 1500
> >   options=3D80009
> >>>>>>>     ether b8:27:eb:71:46:4e
> >   inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
> >   media: Ethernet autoselect (100baseTX )
> >   status: active
> >   nd6 options=3D29
> > bob@pelorus:~ % hostname
> > pelorus.zefox.org
> > bob@pelorus:~ %
> > bob@pelorus:~ % uname -a
> > FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #6 =
stable/13-n251601-2353343b324: Sun Jul  3 21:43:04 PDT 2022     =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> >
> >
> > Thinking it over, I added the extra switch some time ago and didn't
> > immediately notice any problems. Both Pi3s started out on the first
> > switch (NetGear), with no obvdious problems. Later I probably moved
> > one Pi3 to the second switch (D-Link) and started to notice =
troubles.
> > Does this story make sense?
> >
> >> Each interface device from the factory is supposed to have a unique =
MAC
> >> address.?? This can, for most interfaces, be overridden (modern =
Android
> >> phones "randomize" it if told to as a "security" measure) but for =
obvious
> >> reasons doing that can lead to problems. Collisions where multiple =
devices
> >> are using the same MAC will lead to exactly the sort of thing =
you're seeing
> >> because the switch is sending the packets to the wrong place.
> >>
> >> I've got a decent number of Pis of everything back to the "2" here =
and most
> >> of the time several of them are on my network at once.?? I've not =
seen this
> >> problem but I wouldn't exclude that both are claiming the same MAC =
and, if
> >> so, that's what's causing the problem.
> >>
> > [example ifconfig output snipped]
> >>
> >> That MUST be unique on your LAN; the prefix (first three octets) is =
a vendor
> >> code /*and the last three should never be duplicated by a vendor. =
*/If you
> >> are not setting it in /etc/rc.conf or elsewhere and there /are =
/duplicates
> >> then a very bad thing happened when those units were manufactured =
-- set one
> >> of them to something else.
> >>
> >
> > Any pointers to MAC-setting methods appreciated.....
>=20
> My example is not the best fit because it is for DHCP
> but in /etc/rc.conf I use (but showing "??"s):
>=20
> ifconfig_dwc0=3D"ether ??:??:??:??:??:?? DHCP"
>=20
> to avoid its random assignment at power up.

FYI: The example system that has random assignment is
a Rock64, not a RPi* . I got the example line from the
Rock64's /etc/rc.conf file in order to show it to Bob
P.

I do not have such a line on any RPi* that I have
access to.

> So for you I would guess:
>=20
> ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask =
255.255.255.0"
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20
> =20
>=20
>=20
> Hi,
>=20
> My Rpi3B+ does not have a random MAC on ue0.

Niether would the RPi3B that I have access to or any
of the other RPi* that I have access to.

> NB: It uses the muge driver:
> # devinfo | more
> ...
>       bcm283x_dwcotg0
>         usbus1
>           uhub0
>             uhub1
>               uhub2
>                 muge0
>                   miibus0
>                     ukphy0
> ...
>=20
> Your current MAC is officially from the Raspberry Pi Foundation: =
https://hwaddress.com/oui-iab/B8-27-EB/ .

Not for a Rock64 --but true of the RPi* that I have access to.

> Could you have hardcoded the MAC in a *.dtb file or other config in =
the /boot directory and copied that over to the other RPI?

Bob P. is the one that reported 2 fixed MAC addresses on two
RPI3*'s that are equal (duplicates). I was trying to help
him make the machines not present a duplication.

> If you are going to assign some MAC yourself take a look at =
https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local_(U/L_bit) =
to choose a locally administered MAC.

I expect that Bob P. will do something like that.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 14:14:00 2022
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 DE09A1CF9EAF
	for ; Tue,  5 Jul 2022 14:14:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4Lcl6D3LgYz3l3V
	for ; Tue,  5 Jul 2022 14:14:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657030444; bh=IXiRmnl+CBZ52u+1G5YptslFNrmbdIY4De45rMfMnkI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BPCnilKSZikB9SwYflZOuup9T+H88m0XMUfxrWMusuiOCmjmSCr0IQTyuXuUGCtaY8FAg7fUmIKULIWUlpOuDp1YHTdFv4YgeZiVY7fk+a0n/2V5IAiINHm7MUjYZTNnaXPx4fK+kXNBTTbioGp8daeMq1dscDjJyIR3o0CtWkAB2kSQl65njxxCKoZyv9myXxNCQea3S7LdwkQFTx3JV3OGPtIiAfYE382r7gsRnkO5KBMUNzN6ELYZVbuBF9GbIXexoRNvpbpq1x7ADm2UC6huS55WVz6Ra6VuCg8xDa/ZDOUz6nx+egyCyszvEMik8PRObeWLnTiJUekyBG6RsQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657030444; bh=NVIfcH8Hu0J32e9KA/cYMW7qQXFmzXalxR8gTWeGtZZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nz/1CYTLwrtovWtCizcWZPzA4L3EcRItI08gK8HHaG64hgPa1yIySHNFd3eySxKoiyBXydfknyz7VI9RECU5qANMemfLCzU8Qno3IBp1V9X48hjc1h0alNVpjwd3YokDMpoogP4OcJtxmi1fw7t9ssm3CC6h5rSyaVBnuuQkMpOoz9pZPHOgz8ukMroYIDgxAI0kYEfNkX5I3Lonm+uj15jMmxPhuMB2SQ+SCWvpsSCpFo84mLhrYrrF28xxZlRX6JgjjJASt5NZN1wrCTC0ydfYpBqWJ3f9Fsj0DiCAGTJBnqoUBrf46P6HhY7r4F2PlRwbqWmfPAfCXiRRrDfE3g==
X-YMail-OSG: 5xFKaLkVM1mxWwRo_eKzU1E2L6eoNxshVMuEQQF.1WMVP6BWeAQrVNZgDe2SJLC
 Fnz61izmncQLqG66e9EfcyXAEgVL1BmtIB3UGZubyj7Hk8BkU7Iyi1vJXOtu4fJs_qcQQcp7xoVl
 Au6u49vEXjTaxmODA7gkepETPj_BnRbyq8Znet7DqkfwCXnd08lyPqj78ePFhuOpPFHLoWucRk.V
 oYI0yf0w2euG_dXbIqESG1NB5djniSnZBfIVVtG_mC7BydVGFrOAaNMFuWxiDyw_ZdSns_hjZnMJ
 EBwp4mRBQu5tkvz04K27ZFhnTGudmC2g12SuYGIVbgjagXigdR9puKRcpewCRo8RzNo_IPpM63QE
 rnP1T4aTPja_Ck.cr6P6vOwpUDR9jpzoI0oeFnQuPIAd.TCOeMICSLCBMjprjP9ZccgltBZz7wpc
 NtZBFULtq9ihA2xChRjgxuo2um_r.47xfDeqoDImrN2TzOXUUDtvONT7LRpJ9reNVAan5cllrOEb
 2IrP4XZFVXp2X5_luBQjE_FUu6g.6TEQKJuZl5k3hLUKzizhHNAmDjsUtQsJEzOAjGl3KGpXt6.G
 ZzwBmDk9QWbu5G0RNKnXj9i_.jBSbpNLlgzncDEh8eb0Zxqz26d6o9Q4AuR9gusYd4BXrfKpGRiH
 mo0lFiWH7koSVX2SnjRs4_WGfQOI_sh6ijdjToZbG6xnvG2ymDu7wkleswLGXEweJ3vdO8R7VBpr
 5RivszdCft3ukNHtiUF6sY.p_xYXX4.GiLiGnSo3CMmZh6EnbRlJiHgRpnQ_zvgUP9KnoWTMlYaN
 fcVyIpPjoIp7Az0wQSZg0_ZFnpPlqWbaOIeM6mk7vk6hOTzPO2MqMZcol3EkwDTS3NkXE2Tnn5aH
 sKLsj8T7nPtc82eaXjF78RgJHQmgOrmWK7MmScmTOJNeCYgoieHtZG.7yp6ZBUmvhnwzr5agTdEy
 101FOrZ8DN8BBRNEHD8m78i27dHXQGCAVxTIYiuEEeJ8_r6zP9cQ3rgxVY9gTS6qwvpHPJg5oBNO
 Y8z58P6hFtIKWdXsRUfqz1aVpM3L0jQF97RPVcOnUpbXxVpj9BTs0cvWkA09wJ4fdVPBBw.3pyWh
 9Z9.pF.8T6letgn3pZLN.kQ.BuEnGzQy9G6qAv.OPCtnkSBaklBMCkebctDnQPl_J9xj5BZRdITB
 K7lAEBUtHxnZfa4lGa55KbttiKzP1z3Juk.PQx62mUE0Y.e8NCQ6vWEgjZJFtKllIkyjd.vZAHeH
 1arAJChrvHikhSsyltOrVJ_Ig1npDuUfPc9Z27OF15pljSXAPvNpCTLOZ757tdfItEm8xKOwQahI
 NxSaiLYWyrRlFRf3gY6EuLBeTXXF4yxheh6J.HXjiWwCCrk6jHZUEDCYNJIRSBodwy0HEEjBODzt
 oiCxOhb_1CPY9x9gwyFJVuXW021WPDCndbWQOxxDB6SZ.FdiwKk0ETsk3ngtdmCOTSh3SRXLzKXs
 26Yd7hUJAN8nM_XX9Nm4qUjJ9CADrzZWeCZ3QFhaZnzJae_SnFza29bhRXcLS771_.Jl21BAaqt9
 6gwSXBQX4C7XUjwMmnR.xlw18LXsRozyF0wf9nTfxT4tCPXkY6k9d_jxaCFF0hC.5jI61uFQG26L
 QhPiP_Dq6HahKVQoh01hNI1_VwYkRYZ3rfHWKyzwCxIC0DU5ZBFhNCXX0oMyiGfESiUczzAg3ab9
 1irozelF1_kpIhkAL2yh4B4K1ig8Bj9qrwUnR0dITdhpqnW8f_IwAlzx19zWalbL5C82CFPnJZ2p
 I9oG9uzPYHCEja9xYYc4eZN0NhdZp1clAvOkKSEPQIPuy486xGaUinsT7_fyLVhuUblbE17hlsA.
 Brmrzaj_ukYOizW1QBztnl25k9NEkQyUqr9NIEpXKl.IUt9f99lHJ2EsjtNxTqzdJ3LK.P0Z.eE7
 eL6kdta2BVa1gPjdIyA6SlolVVgNbyTXVrKK3zfYXz2BZmEWUfOpzKXA2Lfi6PRp4cUs54rZSEaF
 i8YpzSnZ7GRlQSmBz62fHcdBHlSnBEmbUJTCLH5qv02Umc1gWwK1aiVk2bY6blDrjsWRbUP5LBe9
 D9dfeZ2AkFY6SuQ3HYUXYDRNPHKYdQM1Y.bnnkwROlCwYFL7MfaUg8AkYQ7VoC3MUkgGhRNikKHD
 7AwyYdy6xPUb_lY4972BrtCRmOlzG2m_.fdP4PaUXIC6jbNBh1i3stBqclvuMH6pXuxb7ztMqFpJ
 XawUpaER7geIvBr.SxFbfT_G2rX1KBVBwVLTJEw_RN1eo1pD.NEaLyaxK3o2EqGiWZdNTZXYuAAe
 r
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 14:14:04 +0000
Received: by hermes--production-ne1-7864dcfd54-hwfdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b861fb5ea1c897f2f971d958ca681f14;
          Tue, 05 Jul 2022 14:14:02 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Tue, 5 Jul 2022 07:14:00 -0700
Cc: "Dr. Rolf Jansen" ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
 <0A80CA1D-A3B7-4565-A059-B55FF05DE51B@yahoo.com>
 <531137B1-0501-47AE-BC2F-62F57067356B@yahoo.com>
 
 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lcl6D3LgYz3l3V
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=BPCnilKS;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 05:47, John Kennedy  wrote:

> On Mon, Jul 04, 2022 at 11:41:37PM -0700, Mark Millard wrote:
>> Note: I do my own builds, installs, and configuration
>> experiments. Do not expect my example outputs below to
>> necessarily match those for official builds.
>> 
>> For reference from my root-on-UFS aarch64 environment that boots
>> via U-Boot (not via EDK2 UEFI/ACPI):
> 
>  Gah.  There is so much more out there than RPI4 now for arm64 I didn't
> stop to wonder if bsdinstall set it up right.  I just reformatted
> /boot/efi and slapped the uboot stuff in there because that was the way
> the SDcard image was set up.  I left it as /boot/efi (vs /boot/msdos).
> 
>> # sysctl hw.fdt # Likely a RPi* specific sysctl name?
>> hw.fdt.serial-number: REPLACED
>> hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
>> hw.fdt.model: Raspberry Pi 4 Model B Rev 1.4
> 
> 	# sysctl hw.fdt
> 	hw.fdt.serial-number: 
> 	hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
> 	hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5
> 
>  Aha, that is what I was looking for.  Wasn't even seeing that with
> hw-probe, and I wasn't going to interrupt the 12-hour llvm13 compile to
> reboot and see what I could with uboot yet.

I checked, and for EDK2 UEFI/ACPI the "sysctl -a" output does
not report such information under any name. The sysctl hw.fdt
output is empty for that type of boot context, for example.

>  There is this guy, Mark Millard, who writes these really good mailing
> list emails that makes me paranoid about uboot version mismatches.  :D
> 
>  I haven't even looked at the EEPROM firmware stuff.

Rev 1.5 RPi*'s do not have many valid "default" EEPROM
content alternatives yet: most are too old to be appropriate.

> Reading the list,
> it's all been such potential foot-cannon fodder seeing some people's
> issues I just knew it would be a potential problem, but happily it just
> worked as I would have hoped.
> 
>> I boot a RaspiOS64 microsd card for the related activity.
> 
>  Yeah, I haven't been doing that.
> 

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 15:09:57 2022
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 2F6C81D03BE7
	for ; Tue,  5 Jul 2022 15:10:15 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LcmLs6SX8z3vt3
	for ; Tue,  5 Jul 2022 15:10:13 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657033803;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=V98k1AaI3XPhqopPaXo1kwie2A72NVFPYz+VepeF3oc=;
    b=m5Fi6jjgrL+L3HrmsvcEO9FNAkuLeelFm1/Qk5RjBPNnd91vG2fkK7AF5QKHjZ2x0q
    1vslXL1Y2Dq+udBAT2X/jqtmOM1xSF2x4HucQfIhpRC965ww1IrEjDjVbqTN2K+TfYW3
    tHclf1evIkL67YOyJVx9avJmzKEY9qzIt0qI12dhXMThoG67gRSkRGNq/hzZsEghL+35
    mZF89wn7mxapjGtZ0wEbLTYCoPDmyfAYDErzrumTTFckQ6mDP3dgD9fpSmZlOvwkKAau
    NzH5Ip/kodUi0NRkxzzMUJFjSIHCTfu6WEMqRIOnWCTzfmLwaIfY56sgDHytbckV4dpN
    eE+g==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y65FA3MAz
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Tue, 5 Jul 2022 17:10:03 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id C5F5A638E6;
	Tue,  5 Jul 2022 17:10:01 +0200 (CEST)
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 12.4 \(3445.104.15\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: "Dr. Rolf Jansen" 
In-Reply-To: 
Date: Tue, 5 Jul 2022 12:09:57 -0300
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
References: 
 
 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LcmLs6SX8z3vt3
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=m5Fi6jjg;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.20 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[cyclaero.com];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[cyclaero.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[85.215.255.20:from];
	 FROM_NAME_HAS_TITLE(1.00)[dr];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[177.95.254.116:received]
X-ThisMailContainsUnwantedMimeParts: N

> Am 05.07.2022 um 10:51 schrieb John Kennedy :
>=20
>  Let me take a slightly different track here...
>=20
>  I believe you've said that 14.0-CURRENT (which works without hanging) =
and
> 13.1-STABLE have fixed the RTC problem but you'd specifically like to =
be
> running 13.1-RELEASE.  I think you've implied that you've booted up on
> 13.1-RELEASE (but did have RTC problem, presumably because the changed
> haven't been MFCed all the way into the releng/13.1 branch.  The delay
> is the whole reason I'm running stable/13 myself, although like I said
> for amd64 reasons and just keeping the arm64 systems par.

I like RELEASE, because with that freebsd-update does work (remember =
arm64 is 1st tier since v13). Therefore, keeping the system updated is =
less hassle with RELEASE, compared to STABLE or CURRENT. That said, I =
kept my BeagleBone Blacks for years on CURRENT without big issues, by =
using an approach, which I lined out in a BLog post of mine:

https://obsigna.com/articles/1530995431.html

Actually, I switched my RPi 4 installation from 13.1-RELEASE to =
14.0-CURRENT by this way, and if that matters, I could easily switch it =
back to 13.1 or something else.=20

>   While Mark has made me a bit paranoid with what could go wrong at =
the
> pre-FreeBSD stages, if you can reliably recompile 14, those wouldn't
> seem to be an issue, if everything else is constant.
>=20
>  Personally, I wouldn't run 14 in a production environment.  It's been
> very good to me in a bhyve environment, but it's not called -STABLE =
for
> a reason.  The reason I like releng/13.1 over stable/13 is that I have =
a
> Pavlovian urge to keep things patched.  So I can totally appreciate =
you
> wanting to run something stable and secure that doesn't get too many
> updates.  I'd just try to aim you at stable/13 vs main, at least if =
you
> can't backport the RTC fix into releng/13.1.

Again, I like RELEASE because I like the comfort of freebsd-update, =
nothing else. If I can't have this, there are reasons to choose CURRENT =
over STABLE. For example, Netflix does operate their streaming serves =
with CURRENT, and they explained why - hopefully I found the correct =
link here:

=
https://papers.freebsd.org/2021/eurobsdcon/gallatin-netflix-freebsd-400gbp=
s/

For me the reason is, if something becomes broken, I switch back to the =
previous snapshot (using said approach), I report the issue and usually =
wait one week until it becomes fixed by the next snapshot.

>  But that being said, still a custom kernel of sorts, yes?

With 14.0-CURRENT the main reason for building a custom kernel is to =
increase the performance by building the NODEBUG one. Since I also want =
to do some experiments with the SDIO stuff, I choose the =
GENERIC-MMCCAM-NODEBUG variant for now.

https://wiki.freebsd.org/SDIO#Get_hands_dirty

Depending on the milage, I might switch back to GENERIC-NODEBUG in the =
future.=20

>  So is your 14.x setup the same as your -RELEASE setup?

Yes, my clone utility (it is in the ports and a newer version is already =
in my GiHub repository: https://github.com/cyclaero/clone) allows me to =
pick exactly the system components from the SD card snapshot while =
leaving all my setup untouched.

>  When I bootstrapped myself initially, I burned a SDCARD and booted up =
(passed,
> so check).  Then I did the bsdinstall onto my USB disk, stomped on the
> EFI/msdos contents with the known-good SDCARD contents.  Yanked out
> SDCARD, booted up, ok, USB-only known-good there.

I build embedded mostly autonomous systems with the BBB and I will =
switch in the foreseeable future to RPi 4. These need a reliable RTC. 16 =
to 32 GB is more than sufficient, and when the customers need something =
updated or the SD card becomes broken, then I send them a new SD card by =
mail. Important data should anyway be frequently transferred via VPN to =
either my remote cloud servers or directly to the servers of the =
customer. In this scenario the SD card is a consumable. The BBB's are =
set up to run from the internal 4 GB flash, in case the SD card becomes =
broken. For RPi systems, I will need to ship spare SD cards witch may =
operate the system. If something goes wrong, the customer may replace =
the SD card and the system would be up and running again in no time.

>  Happily, I could pkg-install things (like git) to recompile the
> kernel+world.  Reboot with that, "custom" kernel check.  Recompiling =
all
> the packages locally was a nice stress-test.

I utilize a dual mode approach for updating ports and packages. That =
works very well for years now:

https://obsigna.com/articles/1519780374.html

>  I don't think "downgrading" from 14 to 13 is generally recommended =
(in
> my case, ZFS options would generally get me, but I believe you said
> you're UFS).

I hate ZFS. Overly sophisticated for no real benefit.

>  Basically, you've got situations where uboot can hand off to modern
> FreeBSD kernels on your hardware.  I think you're seeing a lot of =
lines
> of text because we're being paranoid about blind spots where you can't
> see some missing error message that would pinpoint the problem.

I don't want to mess around with u-boot. If the stock one does not work, =
then something is broken and needs to be reported. That said, I don't =
believe, that the present issue is an u-boot one.

>  All else being equal, if you can boot a stock 13.1-RELEASE kernel
> image, you should be able to recompile that kernel in place and expect
> it to boot.  So we're looking for the "not equal", something that =
we're
> assuming that is wrong.

That would be the second step. The first step would be that somebody =
else confirms my finding that building and running a custom kernel on a =
stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that =
was my initial question.

- In case somebody raises her/his hand telling, that this worked =
flawlessly on their system,
  then I would have a more in deep look, what might have gone wrong =
here.

- In case the issue would be confirmed, then I would submit a bug =
report, and the discussion
  may continue in a more productive way on bugs.freebsd.org.



From nobody Tue Jul  5 17:51:33 2022
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 026781D1C4CE
	for ; Tue,  5 Jul 2022 17:53:03 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lcqyk0bzRz4stg
	for ; Tue,  5 Jul 2022 17:53:02 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 265HpYUW019839
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 5 Jul 2022 10:51:34 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 265HpXIN019838;
	Tue, 5 Jul 2022 10:51:33 -0700 (PDT)
	(envelope-from warlock)
Date: Tue, 5 Jul 2022 10:51:33 -0700
From: John Kennedy 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm@freebsd.org
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Message-ID: 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.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: <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
X-Rspamd-Queue-Id: 4Lcqyk0bzRz4stg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.80 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[phouka.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	 FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jul 05, 2022 at 12:09:57PM -0300, Dr. Rolf Jansen wrote:
> I like RELEASE, because with that freebsd-update does work (remember arm64 is 1st tier since v13). Therefore, keeping the system updated is less hassle with RELEASE, compared to STABLE or CURRENT. That said, I kept my BeagleBone Blacks for years on CURRENT without big issues, by using an approach, which I lined out in a BLog post of mine:

  Yeah, I've been using FreeBSD on RPI's long before tier 1 and when
package repos for it were far less certain, so I did it myself.  I've
got a bunch of one-offs, and you seem to be doing this at scale (and
enjoying the benefits of it).

  For -CURRENT vs -STABLE vs -RELEASE, I was just thinking of what you'd
want to file a bug report (after X -STABLE works, -RELEASE missing Y).
-CURRENT has never burned me too badly, -STABLE is just closer to -REL.

> https://papers.freebsd.org/2021/eurobsdcon/gallatin-netflix-freebsd-400gbps/
> 
> For me the reason is, if something becomes broken, I switch back to the previous snapshot (using said approach), I report the issue and usually wait one week until it becomes fixed by the next snapshot.

  Not sure if that's the video you wanted, at least in the context of
what I think you're going for in a snapshot.  But again, you seem to be
doing something at scale with customers so you're not looking for
bespoke.  I seem to remember that you couldn't upgrade to the
ALPHA/BETA/RC/PRE levels, but that may not be true anymore.

> >  I don't think "downgrading" from 14 to 13 is generally recommended (in
> > my case, ZFS options would generally get me, but I believe you said
> > you're UFS).
> 
> I hate ZFS. Overly sophisticated for no real benefit.

  I mention ZFS and UFS in this context because of a bug that Bob Prohaska
was running into with UFS superblock corruption.  He could see that on
his serial console, so probably not your issue.

> I don't want to mess around with u-boot. If the stock one does not work, then something is broken and needs to be reported. That said, I don't believe, that the present issue is an u-boot one.

  I care about uboot (or not) in merely trying to eliminate it as a
source of the problem (if it hands it off to FreeBSD, probably FreeBSD's
problem but if it doesn't.  Again, just thinking of things you'd want in
a bug report.

> That would be the second step. The first step would be that somebody else confirms my finding that building and running a custom kernel on a stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that was my initial question.

  Yeah, guess I can't help you 1:1 there.

From nobody Tue Jul  5 21:17:17 2022
X-Original-To: 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 9E9841D10563
	for ; Tue,  5 Jul 2022 21:17:33 +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 4LcwVh3yCyz3sYh
	for ; Tue,  5 Jul 2022 21:17:32 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657055845; bh=HAcKHBkDPdfPRV0Ia4BB8d4EW1EGiT89bZTkQCHs+Yk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=mZN1IfHBc4iIoxTBcRIidj2c/y1zoKpEuTML+utSGwtlKpyJDae0G6hD6tVDCLgz+82fOQOzISCKs1eVxneXvzehAn1Sxm0dCE50FMWKhq+l3pFg1sVLV6pnmMbw83xqOpuaV30lkYWLCMZsw3OqjLikJCxtN4ZMRyEgMrzhf6i7PcImfMHthgjBTLB0S8wOpS1aQOZKY3FNEchiYtOC3zfAjQCvDklpYV9j8mPN/Jw/+kt4MacX1Z85WA7YBX/6itTJJkrjr84u3im4DN4MvqL9tMxnGCQ6s8UbCMi6fK2yhAV50Bd9SJihdFepJReR6vECsAXw4fsEEzPE43B5qg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657055845; bh=hcoG6eatMDgwAXJfgZwoO5dtK6CTUcRXsmEL/LDdhrn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=n3xMT1ECk2mp4puChGJCXR3mi3d5sSPdj9q5fkuZWaVi4Y0XfM9wHB5pXwevLbpKFlkpw3CyP/WCs5E0DctCSlmMTXztg/gO2g476LzpdBtL+bTGqMi1qjkNwRSSg8QJX8JBf0BK6Gk85k2yaZMuHTmxcKuUGetCPgY0COhSGWB/sh2fjEhPOiD98QZaOzo14Tug7nOv7Ka/2ZK1gd87RKd85cl30bV7XA8Ay49uuKoIE5JEUdSPg1q6HBoIU1BMJ47P60dNNuDYanFIzI6DCOBrBS0Q8yjKzVgT1DSoseUkQqquNDmHScbxldR7UU0Durchz70j8BbZTejBxATOcA==
X-YMail-OSG: 5Ml_KMUVM1lkHdTkZv_8I94CQ7SXUHyh12Y0Kc1Vo8SHk08feXtTkU1_Ze5IEKC
 BeP.kmHeP8KcFue0MiTjuEaJS2vwcKCMWzdJRb_TgAiTcsmhVHsh075RIiQOdp3A0sVYPtaNTZYY
 2aZeziHR9RsU1rvFyBeJDE3cwwQlL.OG_uGbcA73HM2YcAn8QGT1qTFaqB5rwtsx5aFfF9x.AHWU
 R9vZj0LNs0DXqgC0f22oWnpNDZEHhtIo8STNXmrL31XZxWPTK.4SvAMk9Vl1l.2ArekN3swgE3RQ
 daXTE8FapRkkdDqCvLfsi60IedKzm9uGkE4ROQh36YR1ImWCNwmlZad71XNfwfrBDlp83QPWIpzy
 E_s3PwDXfTC4wCAXojlSqj3VAzJTkNeUXLu45mX_zP7jiwADtmTjFZpORnSfhzYInUOpmOfoEZ2o
 TdLnLwqd_NJ3jKWYVrH39eHVR9s45MppE9FoyvCoNZHVx4L1aqZR77cUbJXNVSwYF4Q4m7Iwe9Fh
 sCQitA9zRxNAicZe_rPfMViPXYaR0Y5RSFtFFgA6SEjXQezNardbJQdlvHlTYryYAnvECRD8PDe9
 _wnTSHro5zq1fsZBwZkHVJCHe52wNfMsEkVkPLE93ntoXcmNNY_7S92bIUG_s_6FkEBx_vKB1e5C
 NH3IsYCvDnnBU1_hhu2U9EQV4W6Gte7HzLxi7_ETMeCEPqJUK436jt2lYii0YfcsyHDMXODVEXJu
 9lkfzTYf1YFniDi60ZRZydn9BtHJ5A9ca7JJ7BJzHdflSf5nzFAYut_z7.h21Pervyp_dzvhlcga
 Od9rsU4hnM489IijYEtknmZB3HlO.PcWVVMI9GSXQ.FC_pfp__LL29oTDhisqFd83Sv_qArV.pYM
 Lyi_x76LcjwGjckKehleIa7nBHhzISjUqxEiinyGMhcI8zLQ.h6oBs8xfq0pLdsH0Rve1oYuPkvv
 dM.VbsY_17BBudmeur2UVyvWcfCNOHZpNvugMUaCLZDBrJissDGo60.F4b1qcgiZIpYHGjnE7y5L
 Xp7Lqwx46dKKJNvDxup5k1PmXPNoiWrf_xGQJaUQukY70scrsydrzaRuXImDZjxGcg9qlhafhFGM
 NJsI6vcSBOze9BzDLvwXliJ577vNR4aWnJUtiQQ9pttewyN40nonz.ZicaK9jpghhRcrdhpchFVU
 acoeF.tD.DaNKAWVTVsAixZZn1QL82gjz7De6fGf7s_A1lGSvCB1OEFdbKvIKKMomVvv3c7S9qMd
 CnBBEZaL9eHguw6ZeLdKjc5Nq9m8414l68I9JUBzCztjCb7CK61u57qwegdFSjajx_OneN5YxJmI
 30FZidLSQSySRWzXBln2cQ87qZYpOmHzRORPnOrSRL6b6GZx93ewKqfsG_idRpPT1.bknMe7_eud
 3fd.06vKrtAOoXQSFtuCK5aFrstJ1o6YuBeli2ueWU_JFrCjwMSH5vcAWU6TWoKdL3r_HiNW272l
 Gj.LSCSpbFTuJFZjdczDJl16j3OBuij0SnY14NEBC_lcRPQEXEwb8lJTOSBGKbwfuh3adnSiCwxE
 edXN6BQdMYJhRKdss1q6XoiVMsmeeE4NFr9yj72EhRY92hr9AH72S8bMDAJEUMmdU0hcg1TyfbBF
 pT1KLYMSEmV05c7k6YOJxnlT4rROsC2oDvuxFBZMpBWFQeVncaLoYiIXpy.ycaM3XTiprENtL1MX
 UEMEgki2w1XjV46vx1GRfu31SYPy2O4c3lmysa0UzNentlM_v82Em7Du1dCtY64LwUyW56l8U9yn
 ys8hNxZf1i7gTocgEZFkftZjx5CMOF5lzVGQadb4iMPfXwpwBfyeIMoDLj4QQtCI17nR9jHxCnqX
 YeAiwvPAKfO9aBsq3Q7j6Jjn0P_6Ozn3rm7pdtvlA4.O1pfzdFYeYMo1ihSAJv.U4oZsE35Z_JsJ
 YE25A0yMQ04RBEtosVRkjXfh_OB5tVDM0MWSlNKP6wnksyvid_6wTcTlAOGzGS7o3LdGJ0cN.LEW
 2nX2RxlabZTjt4cvSUeM4BmRX4duiNpXJ6jx6jTEUo3YfZ8rPDbXxxQATaTDq6bV53O6ng.rnDup
 mxFHImGwWtt1bLZdteacAq5SCxxbYc2ju.F8uDsaaFWJ288voNz30tYb7oe_uSSPybTJlLOBoljL
 CG0yUPM5RVJFgkmpgZTbBrZStG3TlR1h.gr.BK7ayJcKlWqNAkTYIdns6dVmaGAaeabCtoTajzYd
 FE.0x838.Y5N8C7PyAWu4fwaDX1F3QJ3ndkXI.KPVkvbciEEMiwWLqm8Yd70CRlnRbOMUVB1D
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 21:17:25 +0000
Received: by hermes--production-bf1-58957fb66f-88chf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 81113c433e25440e2112ebbccca0e95a;
          Tue, 05 Jul 2022 21:17:19 +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 14.0 \(3654.120.0.1.13\))
Subject: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T vintage
 SOC) when dd'd to the example USB3 media then used to try to boot via USB3
 port
Message-Id: 
Date: Tue, 5 Jul 2022 14:17:17 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4LcwVh3yCyz3sYh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=mZN1IfHB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.979];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:

A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
B) The same media fails for USB3-port based boot attempts.
C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
D) An alternate type of USB3 media (USB2 compatible) booted via USB3 =
just
  fine via 13.1-RELEASE.

The details . . .

I intended for for use in the Rev 1.4 8 GiByte RPi4B's
by first going onto USB3 media (of the same kind I
normally use on the RPi4B's with main and the like).
So, I tried:=20

# dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \
bs=3D1m conv=3Dsync status=3Dprogress

and then tried to boot the RPi4B via the media and it gets
the following (the kernel loads and runs but . . .):

. . .
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
uhub0: 5 ports with 4 removable, self powered
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on =
usbus0
Root mount waiting for: usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=3Drw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot>=20

Plugging into the other USB3 port and attempting the
power on boot just changes the port numbers from 3 to 2
in the sequence.

Plugging into a USB2 port does not have the problem and
it completes the boot and operates. (The media is USB3
but USB2 compatible as well.)

Adding to /boot/loader.conf :

# First, 3 additions:
kern.cam.boot_delay=3D10000
vfs.mountroot.timeout=3D10
vfs.root_mount_always_wait=3D1

and retrying via a USB3 port just results in:

. . .
Root mount waiting for: usbus0 CAM
uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for 10 =
more seconds
Mounting from ufs:/dev/ufs/rootfs failed with error 2.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=3Drw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot>=20

So: same problem.

For reference, from the media being plugged into a different
aarch64 FeeBSD machine running main:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Samsung PSSD T7 Touch (0x04e8:0x4001)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2

The RPi4B is of a vintage that has the "3 GiByte DMA" issue
present, not that it would be likely to be contributing here.


So I then tried the sequence using a different type of USB3
media (also USB2 compatible), placed in a USB3 port to boot:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2

For this media, the sequence worked and booted successfully.


So the issue is somehow specific to some USB3 media=20
used in the USB3 ports but not to others. "reset failed,
error=3DUSB_ERR_TIMEOUT" may need more time or better
recovery if a wider range of boot devices are to be
supported. May be the T7 Touch needs more than the
standard amount of time to reset as a USB3 device or
some such. (I've no clue about the details.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 21:32:03 2022
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 6ECDF1D127B5
	for ; Tue,  5 Jul 2022 21:32:18 +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 4Lcwqj3r95z3tgQ
	for ; Tue,  5 Jul 2022 21:32:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657056730; bh=+gLxV1pcUVXAadAnQMIPKAcO8X+JBGzFUBLBoO4jWMU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YTrlvUXYL5luZfJ8/BLh2aQIxyfHQGe5e/mOwQiISxpNH16GJn7MurBKn1YJv+Mp9Z2Y3nILOvKZaJ5bJAI+zlmRGQSOlzoeBHtxT6KBPgah+nYFoaduCt5Q9rvoJDSnlnAbSk/zEhmQH8Tg5nOnKr7j6GZPPFDktbzcyI8nb6EUrI8vIpHFfx1yAZ5kAAI0p5f7zNSb59XUYeJtpIPI3rn4f73UKrU8KUVB2XPWqnPLkMV29ocaMP34JQUFz84nUIuyivNj95pVxMPrQBMD13PtaDqJtXc/UPshoV3LjAWgEpe0QyM+tzLak/ANJcgYrLFZXcuiyTg4LzDnBY91Bw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657056730; bh=JS6Pfw1nkU6W9yAw7LCGnid4hEMg1hQoBogI+sSHvhM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VEvqTYO64kHhnAot32NvmG5eIIdx0Wi7y2nj+wGcGU3uahJK+kAGdgmK/viIN5BO3xOafaDEoD0yI8p7hLcQGD/gy/Bbsd+Da2NYBxhN15+jM3jxc5o08iKmzdBLjL2QjAXZOAnscg0b6e/hjSe6vz/N8J2/KtA6SpsGS9hUmS554YRyaVzzBqxbbyK9e0Of8LgZMWZbosbM1S5Y6spO7mFM5k0YE9GOLyuianhq/8T/UJqwIakuWccCnlH05lDngOcnwZC5V1KSpC9frdkbvyN8+PVKctLwq5IgSRyGUvAIKjFIcPVM/FuIQAg+fvZxrdJZdZBgXhSk0rCbO5Hc0w==
X-YMail-OSG: 6qU_JYwVM1loCc04Eq.x_mHrPTM4uq58GgL.FcXwDuiEvWWxCkov87paqzASCg4
 zdAgBKrEC2MSdJ7oAdcDmW3GOmvDCbZvllrRpQFy694qeFM0zVJbUKrV4I8WXCx6Khu6l2Ce61T5
 ivD6gc7_wJPNxB7A7HHTvLuUacu1IIeUUy1CKoCKIqPATrgg14Ydyq0V6ZRi1cVsYgX0VGk_Yo8D
 y8tpadk6dkYlb6TS01q7dcufgVSJr1P1wevVAJCiadstpJ3uvM26iWjduQkzOjwn.ZP677UdjDcr
 UTGe2wQcRI7mMTBjLf8MMUPefXIa2BTvr471BKmYzV.g37t2DmUv4IVYOjKFzTM.AVSGUA2D7Kg.
 9thXO3IiXYiUuNl9VORpGWbtXxsIiMdel1Ev0poqGEfPVw8u0x56qeCgefCt9HIQdjDQz8EBRmgE
 oI0McMz1u.cWaDJh51FDlhsu_2Zd1w9RKiDVeZfSZ_YXFn60EpQaflWP2192v2N1TDgKSWR79S4o
 tkRKe0wVhsRk9ZGISqoaQ548mJiqZ.MDDjmgeXCa7OILJgMoz_X0AE5QBL_WZrXfslKrgSgZ8Xyn
 6I1Z9wrBCLALyuVVaze1rRbRBvA5LdFE5uXTF7o.wzGbMsrqOCXoCc4Z86A2jK0Zme0NFEfaeCkd
 rbHO8Qow_kfOhqOJDff6pYxBfRlE3wwXh2F96HyZsNzKQsyIRtYHyIVF8AeT5T34Utz474IpOSmB
 EWtqDKvupGMO3WmVE1unpSwh81yfw4z8P0hr3Wxgsco10pW4nSM.ef1bONPrtTJkUUKMJ1ueGsaL
 C6ZJtry59LhA7e.RH.0xLCAiPVMg9a.CgL3Q85afLvwb350Lkit5JZZG8gFQyXS2m71VaSjqLeqs
 cCzD2ExHfNUgRgfcMsQieD98.WJsE7FyhPoubzLa1nzXKHaYjypg7yhD.Iy03GWpaoFouWGM0CDj
 2lF.UTWu4C40oYoGq29Y7xbmuhTz1usgulkeEBz8uYYX9xFD1GN527UOUWY5v4mjhWsMCtv.IL4i
 EGs8G.QJDE_NKgvX8Eoa4DfYd2FVDd8RcGfTJpxqQC_v0WSuyhZ6zaVe3LWKpp0y9eJMvOH9MxmK
 R9ch6SI9fH9VUh7e335zmMjA0M6Knei6s6FhyfOFkGnl_tkgKdZ.9jN8I4rap8KDHpFynY7zGnbY
 58yE5EmVxgQ5eaVR3UyoaXRU6s3sJVeAcgiXslsB.71cxEnnOa5WqyW1NSUFbmETmzYbYcTzydfV
 qvUwKbl1zz8r.ZoS.Q1Gjk8aSbEIc4REYtuXXSMEBwGZmuwBPJ3eyYh8P1GVtRyL7LQz90.nc8mL
 OhqJpHJFcGq4EizWQZM6zHlCLtsfwRkYy1A.kXM_3D08at66aRoIAc86W.H.u2XpOoeBuLuz42j5
 kBfUCxOZUOBqj2uR2fBnH2hjhEphnlL8zsbjil.gmDR9hak.C634.pnVovryAqOEullt2bt7rqvn
 IK.ln0bbGkOq63jJQRdMRU.7I8r1rpZL.CJNyhlTxoPnwPUoRQ2gtaLsvwJ_HDZ_Z8zgp6rH0sZU
 2cVSO2ZrgNPJQQwu6AnPWu3NuKrY0NxOQgHXpPVX9gUKeGw04X6dSNENCABE6a1cESC6r50vEd7D
 hNa.JWpGtCtfSOvRvk31FsKY.md8YsyzR_90VbAE8COtMMd5z.qGpeJI303qY5yKvxWwTl1CBz9J
 SYlYtlrC7aZJXuUkUL4YJyY009JgCI.fZ9k4qGkKrMJtNBAnxL73jtoja5_TSLvHsF8a0xko1JHC
 TxPNILodQmV5TcR7AU5nqAQrD.9mZTrnmYJ3tMxBelCWby1EmvWQAOpGQaDZB8PV8IPMMbLWqWON
 kfJWwRuAvzWu0I7x0s53VZP5s2w2W1906Eq8RyjqQP1AD8yyPAaYic7mOD4pKCnC5TBauOxL3Ytz
 4plCXgo0Pj64_8s0mQs3TZnaZ7Jcr4g1Lfx46ymKjhVjqFun8FKrYAs4iSCfkLz4GTNvBJJ1xHTx
 eL8NDeMrbI6sMxGfQOZnXsWzr_f247UkdYSDy44aN3xLiKm_2U5RO2tU9GlODz8yb0tGcR75moYG
 4tWhxPwj8UySGx5hHwVh4tk7MZL8ubre_fr_Ux6zrvyESz0jfZIorgFIxp3nR9juDMMgIby2wY8U
 B3UB7rJjvvirMHt_InddvJRfMStrhXDXzdIBN1eW6Jmn3s9bLkouP2IGEKvTDFHQ2IsTKbIbaOiO
 w9d2UQHw6gRUV7U1Z4qIF8E3bTR1oz_ScogznG2SGo39.KkzZPaS6TRh32UMp1d1_5YWhI_2ZACt
 NpIxFCg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 21:32:10 +0000
Received: by hermes--production-ne1-7864dcfd54-hwfdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 784c31d2b8b22303ca9707915ee290fe;
          Tue, 05 Jul 2022 21:32: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Tue, 5 Jul 2022 14:32:03 -0700
Cc: Free BSD 
Content-Transfer-Encoding: quoted-printable
Message-Id: <02687A1C-37C3-4148-ABD2-3FB2188E7294@yahoo.com>
References: 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lcwqj3r95z3tgQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=YTrlvUXY;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-4, at 18:33, John Kennedy  wrote:

> On Mon, Jul 04, 2022 at 08:57:08PM -0300, Dr. Rolf Jansen wrote:
>> On my brand new RPi 4 B (0xb03115), operated by 13.1-RELEASE, I built =
2 custom kernels, with kernel configs from different sources. Building =
and installing went through without issues.
>=20
>  I've also got a new 8G RPI4, not sure how to get the exact model
> number without popping the heatsink case off.

The labeling now under the heatsink does not indicate
which Rev. 1.? the RPi4B is. C0T just describes the SOC
and they change SOC's without needing to change the
board revision.

Rev increases are board changes, not changes that can
use the board unchanged.

It may be that all 8 GiByte Rev 1.5 RPi4B's have
the SOC that no longer has the "3 GiByte" problem
for DMA, for example (SOC type ending in C0T). But
it might not be all. Some C0T SOC parts where put
on Rev 1.4 boards as I understand --but I'm not
sure if any were for an 8 GiByte configuration.

I'm not aware of anything in FreeBSD put in place
to detect C0T vs. before. There is DeviceTree
content that is different related to DMA ranges
as I understand. (The .dtb files are loaded and
some content is then adjusted by the RPi* firmware
before handing over the live DeviceTree. No new
.dtb files specific to C0T were made so it is
just dynamic adjustment for the issue.)

So your:

	# sysctl hw.fdt
	hw.fdt.serial-number: 
	hw.fdt.compatible: raspberrypi,4-model-b brcm,bcm2711
	hw.fdt.model: Raspberry Pi 4 Model B Rev 1.5

need not be sufficient to know about the "3 GiByte" problem's
status. But it does indicate the board with the modification
to allow the different PMIC.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 22:45:25 2022
X-Original-To: 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 E63AA1CFC175
	for ; Tue,  5 Jul 2022 22:45:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4LcySJ4wCJz4YLN
	for ; Tue,  5 Jul 2022 22:45:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061128; bh=iUERx/wfgyK5bBcU7iVNXxDun11c89Ck6m7TaCAiEjA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=InYxHSbzqZ6yU5BbBZ9kzz+VMVSQ1DZY50O3EwDs8jGPGO5ewcptiLaxET1QE9zA/WxPk0ghtZFDKrWOffzo6NQsQQgn2k25hu9ghQwjMw0puGEd9Gwuqc5o6R4+OF5M0Ijs2hwK079CCK4D1svip3tTjb/iuVdilVTLQKJ738zil4+yljhwcPgpUfCT1W5l6D0P4vw1O9DmD3XKu18dmar44BmdK5lInoyqNAe/JGnNzl04s8pbF0IaK8L9rroSSWrxebN4VqdAFsWqNy0mUEIOlvj7/t7i6RCSCzUs6TGB6MrIrQTVxtHXP2cUp97CckRjp4kaWtKajqMzAUGpdA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061128; bh=CRRi3RbPOX/DaTTQHQIb+YlFF8H/lMOVew5dSdex/2D=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=mg6LVK90nNaTPvG7580dvnCBXRXzyv/UI8hTIwyMQMR4IRzcqbrHfc7P3pF0h1LDHxh/7LyJrIDoF+VdmCO8K0fGCwY4oTcarDxj+YA5cSPkJuzVb/GO9zjjQq62GgDF3OcBLOy1HSvHRF+Oe9WecKPHdcZPwoZTPDe9Zn21dnIdSDWh9jngRGKw7y7QCep+Qz8K4ZD60xN3AZvA86GmP1Lyb4JT5GlwVGTtOr4KL9MZ/soHVwfg1HIkA1vq0+vfhs42LIpHNvqHRGORr7kPOzLB+kgORjAVHWknDzquOfFTXhT7p6VNgyRftV95FMvE36f+GewGvEWyfCamDMqwKA==
X-YMail-OSG: 3tW5vmAVM1moIT05h4jm8ZlFxoJ9SLprcRjQAwy2RGv0FZT4Z0GHS1khIDcRwlv
 TMsvA635GMJaED8dJsExoYy1etKPpIS3ny31jfG4vY8jZFj1r9OvZrKVPOHoFAa5wCqMKbCZOhNi
 xTX9LwCxxSJkXGeFEc2pOEqu.KMBYf_JwLCgVGhB52vD6f6FawM_IyUmBKHnT8hhzKCuuzh5ZUib
 q6GJB2d59HFgBXH7QYq0LKt8j5a9iTy3M7Ug2HEXDpdI0KL1cOxoo7ZUqoep2NxKpvXhXlu_cFTP
 Pd8Ny9EYsPenIBdYKacMwOopXYbbH6IIRJ0SRFsW_n10QALdx9oOq0JtHLWEWCKr_NP6HYH6AKBB
 nbW8ZTc03gRjl.m4zK0xpLxeysWPdGUVtm2gaBWWsiLg1qzaKptJFTXBd8LxmvXdTPGdh4JILwYd
 VJWP6j5VOxuTjcESTjN2Em_OY_vov..rF.z.SeoOTbQo5RZ9e5T4wKC5ueS1EojNZkhAAmf.D.IE
 C7WL1SQFObTb3DPdLU31qKe_VIsIICSwFlaN9B7atfFvQAK8C1GERT2EADqJwmkOOSZw_Bf9yxXG
 UYrbK7lI7wEwYAzqAALpK3cEvkNXnWhlHrI4_bmJ7_YQ65qvXB92I2YoJOnL6IVJlvWxHRN1pJ9c
 Qy.DFa4clFU9_CL7YXuVo_SwGYiSiF8VvEmeuetmbDSn_.kO5_p0OrWA3xXRUpQOTqa_VVwCs0zD
 BftIIurG9OGbV17DzldSngwve4wwC5d1mVVGX9nL28j94C0ftraS5HmeqyUX1Zh8vAVOnw9TgAt7
 wSRx9LC44Td_RljnLTHz8X26lp6B19MNqg7Td7kah45UnzslXKgu2WJEVLPkPCmni5_8BRGwXtcT
 Hvr4y5Crb3yfduwn304.wDXo4ZGE3hdZfX8JswB7Kp8feWtAMLCI7MY4u3Po5YHnqskMPxHW38DI
 jxX.JdNrUSioPdbFbmNbDU_cPabuX_R3IDlEKopB4R31Ynm0flD.podgVLgzNF6oo0sNWBJCLZhv
 xkKCbJHsFjZacRbI312I7ifpUrgBxR9FMdtdYPNPBL8nrRCMAy1Q_.i1yVNF0XyBm97U9CpuH6hq
 mdBmju_CWptTCIETcgAB4n8ve90A3BldVCpTHGhGV8rn1BesutZtvpECFTC9sxgZ3quhmqxe6_qZ
 OJ_8dq_FNex.l8gTmvV9vFsh.Mr_zCnf3usHb7vtEpCMk.pVtzHl7WuAkbZxmq63p1XAmQ_jDV6M
 2hKMSMFdw1uBzosaWEZBqrJf0kXLp6tPJSdDXgTdQUD_VNa_NIek3MHFkEEfJ_zX..PKW0p4MdXk
 WhjZLyFSvTKYuvO6w_UtfBGyznMks53Sh0uU..Mk9qnGlmgSFDIZbBes3q9jNL4coEl8sFLk20VI
 KdDp8fa0r2uo4.Ts3kDRB0Zh3R9AA9dyY2066phr7bnuX86oCII6dRwsstLwZMimmILmJVjE3yJ1
 eoIDnqMb.8WAf_Z3_4qFxddyOAeAAIDbyrLbwvy_bCPaTea7EO0xMdq5NPiLsucwSHhASSPUQIJI
 jWaAdcx1VsD5X9VIK_NJW6lX8zRBKvTHbI00ani7BkEzl.P4wU_PFfSRMPP2qeFzEjpBMkWqMQ0b
 kQc9ANkkd9HCaAzXIn1IAdGxFLKreKgtFte0KCteH26IaNM2Dwjcs48ln1QG4RjpZ4oz__pxOwAs
 gK_a4YES8Ac_yog6x6qfwtLjX2ZfYXovatbLuHUyLUNqU0l6VUqd5t59.13B1TafZLJsIp_o.AJW
 vbpOIQHFZqVBY8efch757TJRC6Mwx_uuSE4BIbj1VkDP3W8s.Gzt0KNb5t3VqSC1bq1TxMotFvKU
 ia0ZvmrdPbFr1_QWHbS84YdDzLV0gvt2lzuublL3AF9fVmGg5KlUlQEzoVz3WYPTd5tRkmYAai1P
 mCFmrIMKZgn.kG2otp1hUiOok2TfpFxDJdE4QcS0tx_HUfSK7fAqYuiO7tpZR4IzDTY5KCTEZdYT
 El3gtfjZKb5rPvjAvoI4aakoQoR5vb67jzMzxda3kBPUVKzHbeGU_LIpXyAyjAWKy7V2TJzFNu1.
 mqoHytdW2f8tKMRuH9B1ZMZ_8WPyffbugkXc4bZ423S9_1QaR4dqhm9tpilSRnHX9b7693dPaGsX
 0f2i8sSTOWs7.Jvy4n_4XepE8LqNO5LdulBwq97rIz9kg0xFIpQNDZlPPrMJQSdsbQPtfqbJnQAU
 qNZ6Q3CxdBsCtOVpLDD9HC7rAaa..MNla7SKIX_XDRULWJyCPwrJILc1EJyC1wTmIXuPFBqy4xg-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 22:45:28 +0000
Received: by hermes--production-gq1-56bb98dbc7-drkp5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f691ecddc1b36968f82a504478d7f1ce;
          Tue, 05 Jul 2022 22:45:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T
 vintage SOC) when dd'd to the example USB3 media then used to try to boot via
 USB3 port
Date: Tue, 5 Jul 2022 15:45:25 -0700
References: 
To: "freebsd-arm@freebsd.org" 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LcySJ4wCJz4YLN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=InYxHSbz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.27 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	 NEURAL_HAM_SHORT(-0.77)[-0.773];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MLMMJ_DEST(0.00)[arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 14:17, Mark Millard  wrote:

> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:
>=20
> A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
> B) The same media fails for USB3-port based boot attempts.
> C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
> D) An alternate type of USB3 media (USB2 compatible) booted via USB3 =
just
>  fine via 13.1-RELEASE.
>=20
> The details . . .
>=20
> I intended for for use in the Rev 1.4 8 GiByte RPi4B's
> by first going onto USB3 media (of the same kind I
> normally use on the RPi4B's with main and the like).
> So, I tried:=20
>=20
> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \
> bs=3D1m conv=3Dsync status=3Dprogress
>=20
> and then tried to boot the RPi4B via the media and it gets
> the following (the kernel loads and runs but . . .):
>=20
> . . .
> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
> uhub0: 5 ports with 4 removable, self powered
> ugen0.2:  at usbus0
> uhub1 on uhub0
> uhub1:  on =
usbus0
> Root mount waiting for: usbus0
> uhub1: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus0
> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
> mountroot: waiting for device /dev/ufs/rootfs...
> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>=20
> Loader variables:
>  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>  vfs.root.mountfrom.options=3Drw
>=20
> Manual root filesystem specification:
>  : [options]
>      Mount  using filesystem 
>      and with the specified (optional) option list.
>=20
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>=20
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>      Abort manual input
>=20
> mountroot>=20
>=20
> Plugging into the other USB3 port and attempting the
> power on boot just changes the port numbers from 3 to 2
> in the sequence.
>=20
> Plugging into a USB2 port does not have the problem and
> it completes the boot and operates. (The media is USB3
> but USB2 compatible as well.)
>=20
> Adding to /boot/loader.conf :
>=20
> # First, 3 additions:
> kern.cam.boot_delay=3D10000
> vfs.mountroot.timeout=3D10
> vfs.root_mount_always_wait=3D1
>=20
> and retrying via a USB3 port just results in:
>=20
> . . .
> Root mount waiting for: usbus0 CAM
> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for 10 =
more seconds
> Mounting from ufs:/dev/ufs/rootfs failed with error 2.
>=20
> Loader variables:
>  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>  vfs.root.mountfrom.options=3Drw
>=20
> Manual root filesystem specification:
>  : [options]
>      Mount  using filesystem 
>      and with the specified (optional) option list.
>=20
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>=20
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>      Abort manual input
>=20
> mountroot>=20
>=20
> So: same problem.
>=20
> For reference, from the media being plugged into a different
> aarch64 FeeBSD machine running main:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
>=20
> The RPi4B is of a vintage that has the "3 GiByte DMA" issue
> present, not that it would be likely to be contributing here.
>=20
>=20
> So I then tried the sequence using a different type of USB3
> media (also USB2 compatible), placed in a USB3 port to boot:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
>=20
> For this media, the sequence worked and booted successfully.
>=20
>=20
> So the issue is somehow specific to some USB3 media=20
> used in the USB3 ports but not to others. "reset failed,
> error=3DUSB_ERR_TIMEOUT" may need more time or better
> recovery if a wider range of boot devices are to be
> supported. May be the T7 Touch needs more than the
> standard amount of time to reset as a USB3 device or
> some such. (I've no clue about the details.)

I substituted a 13-STABLE kernel.txz expansion and got the
same result using that kernel. (There are not .img files
for this currently.)

But using:

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img

does not have the problem.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 22:59:52 2022
X-Original-To: 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 4847D1CFEA3A
	for ; Tue,  5 Jul 2022 23:00:02 +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 4Lcymw2f6vz4bd7
	for ; Tue,  5 Jul 2022 23:00:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061999; bh=lHGjhA2wLkIqadr0SggV6g5XLLMr0Z+wdQdOcNI9BrY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aN29icKCjWKNSCE0R7tVPFB7CU6KF/oW9d7sGiSDkQDq0S8fHtgi3RiEijCAFhbr53/OjuKE/uFpMeCaPg+YDqZ+NQXH85UY5OENs4didbTRBI5l/gz4e6f2YvCdVjwuQtQixnN0OoWVMv84ATsCBi1ZO/KP8RJ3V+wDEPdlQdE96Oh1wdrjNF6VDzLNF876ZXe4cwqHyHVDUWSzZa4vMZHuFcHDPxv9qwHIMpMsINpdGoZ868kAP2qXI9WWoM14vkEM0N4AekBRjOhN7QWa3zW0qWOFNCJU3JAYdBXjNKxcqEKq7uWeUdfCOor3SqIXlxxZidLzw592EVgsGzPNgg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061999; bh=cqUL3fXft8/vE4blKBnRFLeCjRqi3FZv6YlLhQRzcCD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G0t6T/LEj7xumZfQiR0NzXsaCNUTOGfHEQGnwLporlQvZvUvJ+ELEKJY+xxeGerlHd3oO8XtMhua80Az8AGavzeBm75hs2cBHO8KFQ/RjwRjE+b28gm1BZxFXBodfNr3nGFDT4bbdvEbyORtT3XyNa02Vd41BrdPzcnNZi7c17fx7qK/z2kO9uDVM/0Bp7I0vNy5hkiRGnawT+LMCHe0+GwIgnXtPQPkSaCsx/wbDkWgQDjrR4cNIweLhI69Yqbs8m0RvhuPmJDpRsVR5yifRsaoZveuIXaRzY1XOBFCSX8V2jiS70jBtm6LOC2S2s7T6V8YUXnbhNnl2lGErL+aNA==
X-YMail-OSG: lSdJMvEVM1lKw925GOKFoRYjnm0z1MntdLsTbqE1tqTTK5oNGhOVQJZ5OXbFV2i
 GaHw8NeM136aEijhoaBza7HFAz8l5f3AFmx0B.Dr3DOHnLkzdGrzjt8_Eo.D592Ua0kwqafGa98d
 6CMG7JbBlG.gvzC4sUUG5CflHohW42EBcMhr789VNv80DzfUqNK16EQPvO8OMJ5OxaeFTj3Q0Efe
 d5HiQ3KaeWB5gMSbX_CG.vty5nYkvcRqGW1PH5IZ76ppfFWNfeaSRcp44HB.nXfE5676PXuT08v2
 1h5b21zbru8685T3UfWqOpgrsRUPOj.6Hxd0kxlFCX3Tn5UmMYij4PhavSnqtp8gIq.LAvf958c5
 H0w1ch6K3JZQTitjHNFyfNK5VW3w3S1hHAlU7S5FujQjUK_CkvwRDcWR3ettQuH8JHUi0RLRCu24
 AJqtRjK.t1FcZwJDC2uwF4pCUyv23Wq5WXlAW1UIKPv1s4AvhA3Yxb1uAdtpXsifPlOX9H8SzR1X
 2wcEoDSQaC0P9vm0LSfLxFpaYHeUT_CRVBmxm_mNRojZQW4_wMKMtktkvBdxPrSUwx1sLGW7ywto
 tuuB_7MMa9sBIaShU5Qpd4G1BBCLvWCRtM5I.BmHnqnIH2OuPjm2ceN6N4B1h0FJCKy0z4bsjrUG
 Inq5_NUwJA9UpbduiYfPM_wVq_Irrh6T4C2Igty4D8h1TJ4P46X6jLKXojUbT04FaSHZhkfGvgWR
 kCKbnd_0vV83Ksup_.739wFxy4moj2iPZ8x_fz46jejQ7XzGAbQ0.mQi5BbUxFHpC9syORkeJ7Y8
 9.6zh3ZmbarKATZJl91cPxoSuGroIW6aDOlfYaKwpgpbGSX.8Zrtwuo9eQY0fvTQvyiB0WkktH5b
 cTJmapqGMpZRSqGggOjdODfsX.mwDG2.bewEt7oShtkxT_G7Mt.4VTpAem8FbZ8Uj0VD.ZK9vU5v
 D2gl4GMn_kLnkH1ts6tLW3h1ukrkFgfq_izNiAOHHmTF4K_gOVe8ENKtz0AZ59bqBDY.gi34PJ5G
 vwJV5JGF6eurDukKM8Zy7Wk.eB1ncgkNWUxuX.ZIi_DS3kgRPszDij3_VShT3Db5x1T2qftMT25W
 RoVptnhcE7HvK9Xx6tb8gr1d5GziHBZzOwyQkwwm7miv7XQvqVOq56zxoDfMUuh_cm9KiHwpabjz
 TtamXzu7C3j2oipzkFZxJQ_claHd5pzEMUFVVZ1LMtRS63Or1eqqB7LwpEuVsgWthVsqeTXiimyt
 o8TfCQzV.cRM0TfA46Owx9FpAxrhiIeM9zz1fgStIjwncC858n1p2cEquPSIYVfY4ZEVpuE7LjrK
 rsn4i8WeWHGBq0ZR.JjSe8TDYZTM3UBvb25gP3MCCHmdiLyDejinhlhLM6Th9NKUHTWrKWsL1WVp
 cAzCs3AvZbUYNYts4Nh_6sjijGtLxvmt7HhPavvHdwxo60B7jPTTMCMT9UBHpav1WrshsNOPkVRI
 RlomqiSTdKfkzZ3dMumSD2QSoIP1p2R.7UgMVcCt25q15MNy2rvwmhMbHwRvLmxql6SgKhZOny8z
 f4k_21IBbs_8omFwOZRYNmDvr59nuo9oElEouSdaNuBwFGDuDmYCytaF_gHT6D.3xNf9TAeihluE
 77dBq0snEbUWPW.P9Ciado8yD53NowGYcqK2q4Uin.uDI6Z1u7w1ggIZ7A1p5CYQcqXNcsND5T_b
 BVQ8U1a7R4NuMzpT3qDSkvr5C3tUF3Xid3mIpmsH1Ke2jKvMlwu4rY8cYSKnqK3twsozKDkJ_FaS
 5k9TIovJttALDNJeP5oetamq1SsRyGou9ceQxBXw5fh5zpTkRCk4EUqlvMTepHTcpIJjJvqmkfmI
 HMr8qSsVKfuwsHTyFYt3g4if6flr2vwBrSUaPWwFJKN.nZbTbtzW_tVE4u6VCRE_Y4...3GTFirC
 YCx6Go9cxXAiBfCJ1hn4RdUBs78GzEXsnclV2VeXt.FQ03t8yo10n23cjNiUckZB_sWOgE4kjrnT
 TbbE.n818elce1lQCFG_V0ColqqvhQP9OMIfUB68cL1PooEOmWTTC2XOc7JV1jD3DMFVsna0fviU
 b9XURP1eMhQaRVXw4UVisFQfTcjZYm02I.sKfzLTQqPRHyGbbGty52Y0MzUMaQDAU20wwSpL3PIz
 bnYb4adHyo6YjQsB0OD4bNuy0lxGT2uyr_dkQOQ584sWKLFsYy4RHx3LOSfHx1416.1HagJ6HIhv
 oE3UduorWzpsA69.f9H4l9Y6RbjF5TtnH8vp4FcENGas3BBAtc9.vr62zf4potBncN6beWztl7Ev
 6fb6rhQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 22:59:59 +0000
Received: by hermes--production-bf1-58957fb66f-dvwt8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f5ea83d09f41389f45dce58d4883a25;
          Tue, 05 Jul 2022 22:59:55 +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 14.0 \(3654.120.0.1.13\))
Subject: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
Message-Id: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
Date: Tue, 5 Jul 2022 15:59:52 -0700
To: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 "mckusick@freebsd.org" ,
 freebsd-current 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Lcymw2f6vz4bd7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aN29icKC;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.89)[-0.889];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	 MLMMJ_DEST(0.00)[arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

I did a:

# dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
  3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
3072+0 records in
3072+0 records out

to an around 1 TiByte USB3 NVMe based drive:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Samsung PSSD T7 Touch (0x04e8:0x4001)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2

On booting via the media the growfs happened but at its end was:

. . .
 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) (5048)
UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) (5048)
Mounting local filesystems:.
. . .

Unfortunately,

Thu, 30 Jun 2022
	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin

is from after:

Tue, 28 Jun 2022
	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick

so there still is some form of error in the growfs
activity.

At least there is now a known, specific way to produce the
problem

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul  5 23:34:40 2022
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 DF0211D03AF6
	for ; Tue,  5 Jul 2022 23:34:52 +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 4LczY72RzKz4hPg
	for ; Tue,  5 Jul 2022 23:34:51 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 265NYfC7009512
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 5 Jul 2022 16:34:41 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 265NYeGc009511;
	Tue, 5 Jul 2022 16:34:40 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 5 Jul 2022 16:34:40 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Ronald Klop , Karl Denninger ,
        freebsd-arm@freebsd.org
Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3
Message-ID: <20220705233440.GA9228@www.zefox.net>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <1645012198.135.1657014956867@localhost>
 <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@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: <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com>
X-Rspamd-Queue-Id: 4LczY72RzKz4hPg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.99)[-0.986];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jul 05, 2022 at 07:02:18AM -0700, Mark Millard wrote:
> 
> > So for you I would guess:
> > 
> > ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"
> > 
> >
 
I tried a few variants, all produced a dead connection. 

Using  one like you suggested:

# ethernet address increased by 1 in the last digit
ifconfig ue0="ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0"

produced a flood of errors during boot:
ifconfig: interface ue0=ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0 does not exist

There was clearly no network connectivity, but the serial console
remained responsive. The host sharing the same MAC address exhibited
no connectivity problems. 


Another suggestion was found in an old forum post, assigning the IP
in the usual fashion but adding an alias:

ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0" 
ifconfig_ue0_alias0="link b8:27:eb:71:46:4f"
(trading ether for link had no effect)

resulted in the gateway (and everything else) being unreachable. 

Thanks for writing!

bob prohaska


From nobody Tue Jul  5 23:37:42 2022
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 4D0481D040EF
	for ; Tue,  5 Jul 2022 23:38:20 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Lczd734mBz4hyr
	for ; Tue,  5 Jul 2022 23:38:19 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 130352110A8
	for ; Tue,  5 Jul 2022 19:37:43 -0400 (EDT)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 9B4CC1E0EB5
	for ; Tue,  5 Jul 2022 19:37:42 -0400 (EDT)
Message-ID: <0cd9ee13-9340-8bc4-2b92-171ca83534ee@denninger.net>
Date: Tue, 5 Jul 2022 19:37:42 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <1645012198.135.1657014956867@localhost>
 <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com>
 <20220705233440.GA9228@www.zefox.net>
From: Karl Denninger 
In-Reply-To: <20220705233440.GA9228@www.zefox.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010402030102010600010609"
X-Rspamd-Queue-Id: 4Lczd734mBz4hyr
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-5.89 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[karl];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_SMIME(-2.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_HAM_SHORT(-0.99)[-0.991];
	 DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	 ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a cryptographically signed message in MIME format.

--------------ms010402030102010600010609
Content-Type: multipart/alternative;
 boundary="------------e4eK8zv6PLvPt9naYuNhQ0pB"

--------------e4eK8zv6PLvPt9naYuNhQ0pB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/5/2022 19:34, bob prohaska wrote:
> On Tue, Jul 05, 2022 at 07:02:18AM -0700, Mark Millard wrote:
>
>>> So for you I would guess:
>>>
>>> ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"
>   
> I tried a few variants, all produced a dead connection.
>
> Using  one like you suggested:
>
> # ethernet address increased by 1 in the last digit
> ifconfig ue0="ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0"
>
> produced a flood of errors during boot:
> ifconfig: interface ue0=ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0 does not exist
>
> There was clearly no network connectivity, but the serial console
> remained responsive. The host sharing the same MAC address exhibited
> no connectivity problems.
>
>
> Another suggestion was found in an old forum post, assigning the IP
> in the usual fashion but adding an alias:
>
> ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0"
> ifconfig_ue0_alias0="link b8:27:eb:71:46:4f"
> (trading ether for link had no effect)
>
> resulted in the gateway (and everything else) being unreachable.
>
> Thanks for writing!
>
> bob prohaska

Crap - you have to see if you can get u-boot (e.g. in config.txt) to do 
it then.... that's not supposed to happen (manufacturing two devices 
with the same MAC address) and is EXTREMELY not-nice for the very reason 
you've discovered.  Linux's boot line has an override available for it, 
so there IS a way.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------e4eK8zv6PLvPt9naYuNhQ0pB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/5/2022 19:34, bob prohaska wrote:

    

    

      
On Tue, Jul 05, 2022 at 07:02:18AM -0700, Mark Millard wrote:



      

        

          
So for you I would guess:

ifconfig_ue0="ether ??:??:??:??:??:?? inet 50.1.20.28 netmask 255.255.255.0"


        

      

      
 
I tried a few variants, all produced a dead connection. 

Using  one like you suggested:

# ethernet address increased by 1 in the last digit
ifconfig ue0="ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0"

produced a flood of errors during boot:
ifconfig: interface ue0=ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask 255.255.255.0 does not exist

There was clearly no network connectivity, but the serial console
remained responsive. The host sharing the same MAC address exhibited
no connectivity problems. 


Another suggestion was found in an old forum post, assigning the IP
in the usual fashion but adding an alias:

ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0" 
ifconfig_ue0_alias0="link b8:27:eb:71:46:4f"
(trading ether for link had no effect)

resulted in the gateway (and everything else) being unreachable. 

Thanks for writing!

bob prohaska


    

    
Crap - you have to see if you can get u-boot (e.g. in config.txt)
      to do it then.... that's not supposed to happen (manufacturing two
      devices with the same MAC address) and is EXTREMELY not-nice for
      the very reason you've discovered.  Linux's boot line has an
      override available for it, so there IS a way.

    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------e4eK8zv6PLvPt9naYuNhQ0pB--

--------------ms010402030102010600010609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MDUyMzM3NDJaME8GCSqGSIb3DQEJBDFCBECGhLNi5evToudoMT8S
DJecUuHcRHYqdwtJud7JAwxIoNF4hXZHkPGBx5kutSZZK36PKhBlYd3Fc5LS1DcKbsVKMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgAShR57ucy38BrEsaQrCQZkoEmgE24iv1tesgKv
29IaAKp+ixKbRWhye+vg3TaB5vVi19f1PuMJLOq6BhUXPlgKLrWN1xlWWG95UR/CQZyl1q52
dDdpLSivSRHpd2dKAT69TDWO0WTC4fe77ZfLdp2oKpt5JSXPQ9nlXPYLkgcVSjOkg69e42Id
FVHVRSdwLpE7fXgmc3oIL9CdfWe9d+lx8Ykt4ieT4RmMwB8iGdZUw+lXdU8j1H1gX/OUWaXa
WIBNnwIIjt2CAo9/BeOtgJDM6yrENZyxEYq9sT8d10wDPk0j82Dd8v7LT8T65oyQ2kuYDAUU
Y81Ip3VgKl0Uq50f64yX93x3Ph9+iqQDtxqQVn0pH2K2nMaG89KbDwRqmL+7l4FBRPq/h1k0
5StDtfwlSXcT4qo5V/EwwBh5Igf7yZjJjtXlL7gkhoc+plSNuUBYrRA3+7i3KvvfNrPA99u3
nggE1y3QCFL4oLMIVbs/0oATPfXd7ZBUPAI8LWfMex+kN5yhqhAQKdePfzgIGOvbt2T0jMXq
0EGxD9QAdkdexktzwn33lyAkC8fLfFa3hwbFfa+EeSSPIV2BHlYKjgAi51OBREAUVKAd+zT8
dppWDub2fYuwTcQCxoNmZ8kk2UG8uDEKIlheAWViZn3+1zOMCYkZD0obuIVufhg5MF/degAA
AAAAAA==
--------------ms010402030102010600010609--

From nobody Wed Jul  6 00:04:08 2022
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 3EA051D07406
	for ; Wed,  6 Jul 2022 00:04:12 +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 4Ld0Bz28yvz4lP5
	for ; Wed,  6 Jul 2022 00:04:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657065850; bh=6aRcrTmwjpRg5HU+rOPhrIvAOt8aDviQFMlSO6T3xy4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=W6yHhOrl/zX+mMDCXMLHYDFsXtOaLdy1IQxk51pE2M6J+Hfcdw7F2n7NGv19iM2bB+UF4ySxErDpBmaR8oAxK3SPJEbvQBgxwkmQXyAPEttFwpRH/B52MnqnWMOs8ddliLlnx/poAIjgRI7satrqK2DL3g4/d+ZOnguQBstnwPiRdn0gdYlD9Z7cxK9hPVZ5eMSagajza2ePVI79FLPS5/zfU9QUSUXOG6CHRceAo9sXP6L0LrtAIA9VnqtymVRbFSuEM2+Wc7/Td7wNPXj5tzIbidoprYo1nE5pAi/LKo+Fhbm39j5LeLO+i2PUXZadYY236POibYF9xXzu2j+j0g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657065850; bh=K7mcRdnmQ5P9/I7JNcghO0vXheXDIgdbyZYvOKzEveT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ppUkFBbYGuieupceBaVHfZgb67QvZ51oQzOMdc14Ge4M5oJeRAeGKSAoT6G0Cm56/FD+i6L+hfJTx8PXcsaEBiDOATQOu7SzH7BkD2PhxuIqseo/4azSTnbtkGqSr88O9CxFtWpPtPfSYUlysQFd5urxifoBDKksIn27T+Bf7BaRpyiuJDl3MVMye5+VZ2KXDfeXmBWj3mB+Fa94WtVGoIvDMcDGiYy9g5nUcB0S7dHYF/aLatTBrOFmcB5pcZDD1G4vCRpo9LjyALRmTXOlM23XDZROg3CDRippLuEdkU7GXAhLXknqx8j1F89uS0SHgID9qzJCjMDlyouGsz7uMw==
X-YMail-OSG: Wn0AZjEVM1k7aEMRvWB2HgiQk3CWf9o7wObpLGzH3i26F0vxFkYbB2wJfTeSAMn
 IhdWylIs7Az_IFbSKFIy93TWyp5HxwpsEGfetdtq3LS79_sM7dfW_ayD67EjPdEUf9RmP26tIf1n
 34YnUnCZcf_YTaccFHXcZ.4HDliqQnl6Ovb.crpKVmS8fE_pbiGvjOHppOxxHBDsZCqamRWM1V1q
 AYVS0unoByd1fVpuW_PaMU8YK4S09KV32P_vpwfuFoEb4gzjvcIbneaPsFly3mSIVFk0EoE49Oer
 Pwf2tr.ozFsauB2YqfPVBlHf_vOZPmEcpCepa0qBXsMT0Wi6AljOx5VkP_DTjcfITw5OGm5IgZ9M
 gY4JHTccLUF5uHM4wPRHz3zCFnWXs_Y3S46BtK_edMLK52qpcfFyrhORk0i5TOoxzgjsb25vKJzc
 52AawbxIgU02VKJFCyKdIcfviO93o5xWkEvZEZmTf9LW0ROaZHG7nsiMc2UH6.tnTrII3PQbo4ZC
 UpoB_f9RxgKHiflX5jrTu2EOdxjv3IMRRazhLBHwfqYifR7ditc_Ac30qt3Tor6VMF7oIy652ahs
 NojC3VmR8.jRONG01Im90JIUCeFjDRB_eRQluIpkSM.YgE2xdJcC.QEbRFrOjW170KACe.erO_lj
 BS8GQp9KxVyC82gPMN6PKTArE_3W8iFodAtCVslCXHnrc1slUDOQBPSRM1a4O9JJzGlGAjVCzazm
 1VcaOKu2tcADspcHirFiKxBn_sWxsHFbyXahgaX2GLJqc4_zhxxz3MusqeD9oxiOXMXZaNim1t1b
 0nPYK5qHuDEAO1Q0wybqKgrGhT9Opf0THxBYItvm1xSReZXiypGSTeC0pW44oxB4l8AlaiYz9OK2
 0SAM0k26oESvOtYFybWcojOFeLLEEKLuJntDhOVlobSrgFV0tjwK9606j.iZ7MfeSbitn8mmohA.
 UdGJj7mHLu1.G1XQZvP5M9wDsiOJxDCOcFmqgg1x4o6GIoufEuxJjNKeZi4ZEG5ZjiRNEOifv4fN
 Q7dz25ZAufF6acUVLwZrEx8bQSquSG2A6FXTDCFdAZF_SX7G8LBtXB3dtWzM738yYc7AsYI1v7oS
 W0KAx7co2bWCAE_g.XufpRN12RodWkMV_obO4Z44VkjbSTAktHeRX4fJOAfneJesEyHczSi_mfhk
 bSXyJZieqO7sTpkqPvlTm.Z6ra.mGDYECkM5jxJcYs4GdSRZsCI9zgrwqsVcO52xCR3uFL8URSPm
 o5CFbkEcrD9.Wu_FYnBwFl6soHGKME_u8jarez1Wm31yeGm07bfyr3OpDXutVnXox1DSsn8aI2nS
 rv3fDhpqVr6yzEQyLSar3abIBKPoMMqG2e6mF4aSMkv0h2sCSL98MnYG9eUlB2lQacqLtO4uCc4C
 zSQBD8D0nZQwdkENIfpACx.8Khzpf_3sUo9mguXy7Wpsd9UtwXM8B72VC9GFxeFmM9H2PMLRudsN
 NndASx6DXyz1c3qM7Tqn2sAWnE1W.LZDg9Q6jRM3.QSNls0L0FUvOPEy0w3sQSHCMDRr9a_CFADO
 zV0RTBHI54q7i8U_MEe5R7ASrJ8HUU5rhTuMqxx0ZczC9I_boS3xTyOVH95HRl2ymNj5XwN2ItiT
 iAnKh7m3ouwu0yCohS8TLbQGL_TyUDIMenoc4JpUeb3fz15d72rxpt30CtFL56oyeaq2deOu5QTV
 lBSHy4Xrc9y6NlLMuRu9WXkngKqOli.O0MM3VrWjk0kGU2vZ47Obizk8hkUpoLxGZu8.LOslbbtC
 tVLeOpE66p3zpbomiuHmvHy5IDIXLEDeBtlOohuC3AUIjCFQ9GEjcwo.zSaZgq7YSjE3YQnyxhmK
 a5SsYiuYwwG8WLiWv9RM5a9wEItNYZTzut2a5jEanDOT91q3FEL7l9rjKAKoFuHLn3fC4AshNFmw
 mVeBEpVSUZTFABA39JTHkG5b68eKR7LNsr7l1G82VRBTSPfgDvTEj0uTj0OqQyNBQpFPODfkaw85
 k7sf8PUbA7.U_vUia6yvL8ruFmvNOMnfmWYQ2HlmutjybrWnwt0sKoKyHDQ7qCjBr3Tq8WQVmN0L
 cBcsyeZi310jM1amGg59hIUebkbQ9v2YbUqEldNf63veBhs6YXqa.tA7jLAGB52b57s2aVic7NHM
 1MsNs_xHPpkb_VwKTF.9pem23wa626hlDeuGVEjBgv_CqoHshN0AM1pzVjw6YHnp.cGMusaAamhz
 Ndvgq7czZQxtXwV6at4Re0YWonL9CMhT6TgLwbGYb8bO2sBy.CiDe3x8430ZRlIYjBsWAdGgSztY
 Oschajw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 00:04:10 +0000
Received: by hermes--production-gq1-56bb98dbc7-gxlbk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID db3844267180b8f08eb1b12f625fe76d;
          Wed, 06 Jul 2022 00:04: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 14.0 \(3654.120.0.1.13\))
Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <20220705233440.GA9228@www.zefox.net>
Date: Tue, 5 Jul 2022 17:04:08 -0700
Cc: Ronald Klop ,
 Karl Denninger ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E65607C-C8DF-445A-A000-5553D9BDBC70@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <1645012198.135.1657014956867@localhost>
 <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com>
 <20220705233440.GA9228@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld0Bz28yvz4lP5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=W6yHhOrl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 16:34, bob prohaska  wrote:

> On Tue, Jul 05, 2022 at 07:02:18AM -0700, Mark Millard wrote:
>>=20
>>> So for you I would guess:
>>>=20
>>> ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask =
255.255.255.0"
>>>=20
>>>=20
>=20
> I tried a few variants, all produced a dead connection.=20
>=20
> Using  one like you suggested:
>=20
> # ethernet address increased by 1 in the last digit
> ifconfig ue0=3D"ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask =
255.255.255.0"
>=20
> produced a flood of errors during boot:
> ifconfig: interface ue0=3Dether b8:27:eb:71:46:4f inet 50.1.20.28 =
netmask 255.255.255.0 does not exist
>=20
> There was clearly no network connectivity, but the serial console
> remained responsive. The host sharing the same MAC address exhibited
> no connectivity problems.=20
>=20
>=20
> Another suggestion was found in an old forum post, assigning the IP
> in the usual fashion but adding an alias:
>=20
> ifconfig_ue0=3D"inet 50.1.20.28 netmask 255.255.255.0"=20
> ifconfig_ue0_alias0=3D"link b8:27:eb:71:46:4f"
> (trading ether for link had no effect)
>=20
> resulted in the gateway (and everything else) being unreachable.=20

I also later sent notes about using the RPi* firmware's
config.txt to assign a MAC address to an RPi* . Have
you tried that? It is not in the main RPi* documentation
but RPi* engineers talk about it in the forums.

QUOTE
I've found references to an undocumented control in config.txt :

force_mac_address=3D??:??:??:??:??:??

See, for example, https://forums.raspberrypi.com/viewtopic.php?t=3D327562

Apparently, force_mac_address controls what value shows up in
the device tree for what the ethernet0 alias points to in the
device tree.

Note that having a odd .dtb file could lead to force_mac_address
not working. (The RPi* firmware reads the file and then makes
a device tree with some modifications applied.)
END QUOTE


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 00:14:26 2022
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 555961D08665
	for ; Wed,  6 Jul 2022 00:14:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4Ld0R12X85z4mPP
	for ; Wed,  6 Jul 2022 00:14:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657066469; bh=u/xI5sgjoZZy9wmL49ieq8yZWIP0TfE6StsWDizR5vg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Dd9rmkmZ0AlqVWemX+qxQkvfELOHi2+HashkI0sopDNzl1rbGMEh5NOuPXfpN/bsnGXAcgJoRkQXnFD4Pifp74rK4d50pduFMav2QxWDoS+1guGs1Vu6NYHMvsfJdYxeL6D9f7zN/5EJXLzyUF1cab3iADXtkrfdZilfeG2ukT9pSDJcmiRIihPiiiAJwzroGibU9YqNzldjKszx159ZkG0EzL2I1uNjZRcPs7I0sJquv2xjKqMKB1EfeII3wSx0C9sZpCtYbojuAgUKnGq7nm2EGqnEbw+ZLWi9gtCLySle+3w1/7BG7UgmsFBRRvduuNyUdk14NQhnd+OjHmG7ww==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657066469; bh=BZ41PdQKOz8Gd1gxL8CCasxWHjf0khUSkLpPKkS0iyE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=owIEmUblHAXk58W8jMYFb+VpQMeyIEjqAhgRpQhF3jlCwYzxvd4TPAAGvAVJF25e09PO5vgPd4fy0oylRijRFrUSJjAbjsVZiGfLnODB1IrVnesrtIBAUIr95Q524ZyvgCFO9b5Uelq4qNMP/i5gMGDysAZ0wZZhUnNOuLBnC/YVb/eDRuW7V92LGT2GPCSZ7bFmTPBLl9v12GMgPGJYtd76107zuio0vozk/+joIuY4Jt6MJCwbkK3cfu/DlVQLMj+ZHoJtVKKF08tgoc4TDW60g4gP3l+AY8dQQGQnReK3vtIt5yzUGCJYqyAJmLdML9e9RMiZmlROr4heE5mRJg==
X-YMail-OSG: Bd6z.IoVM1kLYjsTbVcZ4Ioll5CLxXtsuP70mA2gs2kECLr94tpnhMVXIbNHqYq
 JtnJ7gFDKYRtTJ79TzSlZIaZMLoTbXtLFIaG4nh7knzC3Y.WzlR.Tb7yCmkg4.nlJRaksG3lhEQB
 gXPYHfsUXe9yIbwERkNr5tu7GCoLkoI5DH_n4H7QAvozjxo9V8XjSqxwtc9_XZAqJMc_MEJ.C5SA
 _bF6qrZoVl.e_An9KLxGUinucMFxwEUirTXVUWudaXw8yE2s4AFrURKJMIc.TEls66gmCAh8ast1
 4xngGwYMF8Y8YoV_vzhvRUhUMXXR0NNVVliS52O3O16N8MApJ6ALU6xWEDzShTNCLf9o7Gwf2Ug4
 1BfEhsdtw1.VQz0r3k8IlI2PzOIJtVE6lgJ948KCb2uyXpBcs4upu_BK9puu2bF4_MT7gtXDK8r5
 o8FrZGQRTj3cVPZieai59sQmTBi8jKpMc9GWJJMXJRNXRHvodLQxdlqcVCJQFjmZlTh6sOCzDSdf
 ovRgdR5izRODyabSD1.WJbpqFz2CCPKzdUol.Aarlg3cZrBeWLHAJ1U47SyeT4uHVDFnUyyK0X3N
 0LoMaYOkK6Zw9Q3_3aPzb3B5UFX8VkCLD1XyK23Nzhv5eUTdIMJdSCVeyNpFPesNVOM7UFAC.aw5
 R7e6q5_7aBeTNeA1rucvIS0Wm9mg8SONViy07tOe1qf.tI7U8igmm6C5NmoiAsr.VGVcJsVNIyUR
 YGJvNO25LATog1xQHDQ8SBHDqzVG6HhHDuDuKEVn4I4mGlvmxCcuYfDUaecEXTepj3NZC82_VLMT
 l6F1gt3zrr48yZ16LbWxPcVUDg4MT4gaNdT7VBhVWHPxluvYqhF36HW.d6NSTG0Shwv.r27pS8Ws
 KdD_2UbXGOAjV.aFzYlOueiM.o6GT39Bk6Y8F9BISMFEdYzh72Dxirfo35LnvyhzzmBTVeXuUGkF
 hD3ycORFOcFhT0NTvt.L5I4TJ2TmiV76ZWJoRe_8wwYPmCOm25riqvrZE1wQKmg4tuf4VpvpyfNO
 Za3B4WtlL.7P0rm2B5hzsh72a.o5HoOlrXIyhGfZ.u9usxXxNooOejA4LC7EUHdKeTdEVRgjeLW8
 Pd7wK5R2bg4ylsniLe.TVzJVAfk9yzH9B7foehkstwQ21v2iNA9tOf34TOkoDAMTMLPHPW5S6a5l
 HaC8GiT1TPjAbDDY41_7oNf3uykkpuFtJtYZImYc5VMNgUvFLe2DXXX43sl.woylD79KIZvTfLM3
 d2gfpKsl_j3l42sWjHIoZ8VCGC4HHaAGmDC00LY5rLNMy1e7RIw.b.M2K6kICyvXwXKmgv_lH5ns
 s8lxpNdleNb5.bXPci5C_5.6.WU_vIhEispYnaS887X5cvntrUBrlOsdC4TuGWTGbAHHJaQhtyc_
 wgCicrdlRaiwWx0otnBAPdp4XuJX6ypIE4e0NgYqxU1UMl3SuAEuo2JrVYtYiXn0nLy2leeyhPCt
 W_86sO1YKqXcfS509ZB1ALKXvUA6U2rEWtBaFEpHc3LI0z7967D.2SSMfFUPAygfTGVVns8QKIYD
 y3gNqWfZjd05yiJgqqlR3ukRXFtsPInEISjgRvDnvo7LFF.Bph3AQA1_SqNXIXot02cyercx5sRO
 Sggq60x8HxmOLHaVDEbSdcC_XYAvpEod4PGO.8AzlqhsMUOXLkZNIq5e28HiLhtH7sNUPm1kJpMg
 _d54RkEIijUxVCs_BdIlEVML3jVSdatIVPtduXEAcHSQN8FcD5ib4p7HDygWRY6soOuY._yC0k_k
 jUiS0lGOwCWg1zIsi4K0EKIDIvHB5o.HewjoW7zZjHoEX998QObdoE447obYELHyUxDP2.ktng3L
 Zmh6HA_LnrYvBGPvAZYYjvb1EaX01yAItHMP2Ytm0ccjkfSPOPz7W4O5ut4_tN7xBDws6vTbMjRH
 6SoeRAXvcXH7gfz_0YfZWsSjRw4YH2VHzCE3WaNJkZizwB4Af.K6T1yc72NYqLsjbkBeQsvAn6I8
 8iLAxt7Djyyq8088C2eN0SrICZJ8V9Cl2jllq7QSXoyvjMWcXIDCmfkF3BvjzMBCpWYdeg.o8af8
 1hxA0QwJqGc1jiExpd9689S4iGPhBtga_zTd4PYB91HNNEA8uXGeBW6UPdvAKFnYwR9qrwdRIiTV
 hyLAWIXsS_vdvt5TPd7JrSf_ctEej0quC3ppHzcDWznBFn6XgRDQepf4JOpGWA384SA3EZkL8ml3
 IKX6k_LpQMZ0.5MwnMhUdv6dzFCluBxMbjy.M1U4MTIhjbiZUu7Y8Wn.zibXu1ZF7eQbZSuFoqDn
 PUg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 00:14:29 +0000
Received: by hermes--production-gq1-56bb98dbc7-fn7k9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eeb02c5400c22052f898b70bad5562f6;
          Wed, 06 Jul 2022 00:14:27 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: duplicate MAC - Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <0cd9ee13-9340-8bc4-2b92-171ca83534ee@denninger.net>
Date: Tue, 5 Jul 2022 17:14:26 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7663F129-6A84-469C-B89A-F24142E3CEEE@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <1645012198.135.1657014956867@localhost>
 <6B24FF55-7010-40ED-B32B-AA46F0E7ED80@yahoo.com>
 <20220705233440.GA9228@www.zefox.net>
 <0cd9ee13-9340-8bc4-2b92-171ca83534ee@denninger.net>
To: Karl Denninger 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld0R12X85z4mPP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Dd9rmkmZ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 16:37, Karl Denninger  wrote:

> On 7/5/2022 19:34, bob prohaska wrote:
>> On Tue, Jul 05, 2022 at 07:02:18AM -0700, Mark Millard wrote:
>>=20
>>=20
>>>> So for you I would guess:
>>>>=20
>>>> ifconfig_ue0=3D"ether ??:??:??:??:??:?? inet 50.1.20.28 netmask =
255.255.255.0"
>>>>=20
>> =20
>> I tried a few variants, all produced a dead connection.=20
>>=20
>> Using  one like you suggested:
>>=20
>> # ethernet address increased by 1 in the last digit
>> ifconfig ue0=3D"ether b8:27:eb:71:46:4f inet 50.1.20.28 netmask =
255.255.255.0"
>>=20
>> produced a flood of errors during boot:
>> ifconfig: interface ue0=3Dether b8:27:eb:71:46:4f inet 50.1.20.28 =
netmask 255.255.255.0 does not exist
>>=20
>> There was clearly no network connectivity, but the serial console
>> remained responsive. The host sharing the same MAC address exhibited
>> no connectivity problems.=20
>>=20
>>=20
>> Another suggestion was found in an old forum post, assigning the IP
>> in the usual fashion but adding an alias:
>>=20
>> ifconfig_ue0=3D"inet 50.1.20.28 netmask 255.255.255.0"=20
>> ifconfig_ue0_alias0=3D"link b8:27:eb:71:46:4f"
>> (trading ether for link had no effect)
>>=20
>> resulted in the gateway (and everything else) being unreachable.=20
>>=20
>> Thanks for writing!
>>=20
>> bob prohaska
>>=20
> Crap - you have to see if you can get u-boot (e.g. in config.txt) to =
do it then....

config.txt is for the RPi* firmware. I've sent notes
about doing this earlier.

U-Boot is not part of the RPi* firmware, it is an optional,
separate addition. (An alternative is EDK2 UEFI/ACPI
software.) FreeBSD choose to use U-Boot instead of
EDK2. Some linux based distributions do not use either.
But all use some vintage of RPI* firmware.

> that's not supposed to happen (manufacturing two devices with the same =
MAC address) and is EXTREMELY not-nice for the very reason you've =
discovered.

Bob P. has not reported on what a RaspiOS reports
for:

# vcgencmd otp_dump

Parts of the output should be interesting relative
to the duplication if he can generate and capture
the output.

> Linux's boot line has an override available for it, so there IS a way.

Quoting a prior message that avoid even boot line use:
I've found references to an undocumented control in config.txt :

force_mac_address=3D??:??:??:??:??:??

See, for example, https://forums.raspberrypi.com/viewtopic.php?t=3D327562

Apparently, force_mac_address controls what value shows up in
the device tree for what the ethernet0 alias points to in the
device tree.

Note that having a odd .dtb file could lead to force_mac_address
not working. (The RPi* firmware reads the file and then makes
a device tree with some modifications applied.)
END QUOTE

While the official documentation does  not cover it, RPi*
engineers talk about it on the forums at times when supporting
people with problems.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 00:27:54 2022
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 221931D0A23A
	for ; Wed,  6 Jul 2022 00:27:59 +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 4Ld0kQ313Qz4nW4
	for ; Wed,  6 Jul 2022 00:27:58 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2660Rs5g009657
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 5 Jul 2022 17:27:54 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2660Rsf9009656;
	Tue, 5 Jul 2022 17:27:54 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 5 Jul 2022 17:27:54 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Karl Denninger , freebsd-arm@freebsd.org
Subject: Re: 13.1R problems on Pi3
Message-ID: <20220706002754.GB9228@www.zefox.net>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <8755F460-D5A5-4ED1-857F-37B894A9B875@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: <8755F460-D5A5-4ED1-857F-37B894A9B875@yahoo.com>
X-Rspamd-Queue-Id: 4Ld0kQ313Qz4nW4
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [0.95 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 WWW_DOT_DOMAIN(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-0.96)[-0.960];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[zefox.net];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_SPAM_SHORT(0.78)[0.779];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.77)[-0.767];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_WWW(0.50)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 04, 2022 at 01:29:59PM -0700, Mark Millard wrote:
> [This ends with a possible config.txt way to control the
> default Ether MAC address used, independent of which OS
> happens to be running. Possibly better than using the
> only-FreeBSD technique.]
> 
> 
> Did you get the two RPi3*'s in the same purchase? Ending up with
> 2 that both happen to have b8:27:eb:71:46:4e seems odd unless
> possibly the means of setting the values at the factory was
> not varying the values like it should in some production lot (or
> over some range of lots). Independent purchases at different
> times would make it seem even odder.
> 
Oddness won this round. They were bought in 2016 and 2018

> 
> 
> I've found references to an undocumented control in config.txt :
> 
> force_mac_address=??:??:??:??:??:??
> 
> See, for example, https://forums.raspberrypi.com/viewtopic.php?t=327562
> 
> Apparently, force_mac_address controls what value shows up in
> the device tree for what the ethernet0 alias points to in the
> device tree.
> 
> Note that having a odd .dtb file could lead to force_mac_address
> not working. (The RPi* firmware reads the file and then makes
> a device tree with some modifications applied.)
> 

With the files on the 13.1R image force_mac_address seems to work.

Thank you very much!

bob prohaska


From nobody Wed Jul  6 01:00:55 2022
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 71BD71D0FD76
	for ; Wed,  6 Jul 2022 01:01:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4Ld1Sd1sbnz4vCx
	for ; Wed,  6 Jul 2022 01:01:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657069258; bh=5ISKKCAJfrJoqKHGgAdl0GoguBklCUxsmfiNTvXICRs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eat/H+B4jTxmaz4VcZoyMrxcCVKPRp/erMXSuaa+hdygoB+YrfJNClAX+mKHlrtUM5fS93jEQ4hkmJvbvUAcgiK9qX5MwPqFxeimFuClEFMS3xnmfvrDOq76TXFY7kQutrRaFX5k2w0VlC4VXEnMU+CGErZjFAHLLCErBcm0ZhRu3SmTe12rofjE7C8GXtwGcHCnrWbFW/tkI/OnraAC7BRytf2hn91rQ7Xe3X0vEiHaT4dZIGOeMGpq0tVcQw6ce+OiqYhzMjeZKpsGfQmCR1kIFN09ySYTNFPb2HBL+2AcdLH30Yfc4TUvdAmv2nD+UySXanemeQFw+meCCqLAbQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657069258; bh=ral66P6gZRzS37YOJAdJj8+wGVqvou/Y5G4NmZTsrG/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=s5AnRGwoEdxqIvZQlUms/AwryoPOoH1Zq3KxMPqBzvLwj1TfKaBZvSNvDGf6Ci7dvV4GuQCYdHUorJ+MNf8yg9gIWa+F3C75Ke6soTZYyR0PZCS5LjftdmIGIhRJ7Fn5a6HWExlyZks9Ru95P7agh+PFXpoF4Z5vrRpZhgmoEC4sgN17nq8XZVvsLx8ycWPf7AUNWb/q7gYRK6sbSGSuBvRzl0Ir+hpARAVgvfwKVjubAUp1n23KHR5OqX2uSt6Tg7sbwb9KpaS6dONGPBIIGFhN80BUjIgkG4SzvTQKMhUtRD8I5/GLTrT6PF4zTrp1xGUPNIKIADlVR8w+wVXrDw==
X-YMail-OSG: oXHdECIVM1mHsKr4PTAUxUIEP14PhxZkzTxNVVJxKVVI2BIB9JTvf.8g7AtXQew
 nB7o.hcAy0mNcCl04WbWsVBanDBxLPBI.nIguyk45qgJmbQiUzq0ItG57mRuT7ClRz7b.CmrO7xj
 ahdxOMrhMrCGi1MOyUFEkP5.DTCtobT1KvB.VMwFli9Qd1jWjltcfisXdpeObIWoCF_HaK0QbC06
 MLumUbRWnJcg7eTOe3WgRAtyYUf16XsTXXy4M8hiij0tufbyjL3GZh.DNzZbsS7x.Pxnp.xjcCDs
 ymODM6cqWS9SKbRKZCrrlgXKa3lyqM.5oDg50nL91LBA9dYxSUVwTR.oJyXoRy2xY9UBm42_r8sd
 9L7ZK6hB6Ptwva.v3091oIXiKc_aNEIZyiGMBQBXG3m38fkJI74McpumXfJIvycyU9etvmOI4B6U
 dzIh6mClfyjAmqKbiSMnNGNNIZ6scUZ8XEZhHu06j2pRD8E6jEJLBwsrxym9EbCoynURtGeGBiQb
 K0GrXWAJaT9AMYj5g89xdK3ECu__rpsmrOEGqQg5RHxOpjjpvp.8HCmnjwOHxYJ6k8H3AjLhPUAA
 6LxzukCHKL.1aj7rAdinycFYjAgRR_3XHQ_iBqgBwttzau6igO6.XRSRJOV1dmt7Oc97DTSJ0M3w
 cjdMbLawthKxFgq7neLXp7WUZ1WWr5zJuYb8F9yCUEFC4YODytFj7t.O8ZC4ZeW7NIeiPuYR608B
 nOLToByhB9XFDua35Xi3Y2Sgsv3SYs_V3M_zXOVmRHs_6OWYEfSvPfzZ83MZYIgihw1vU6fzRcpr
 nGD.5KOT5tcRSuz5MfJlXH_ak20hktq8KTZahnMwDc9Zm_Qwd329UuJ44u8.my9Wg52a9OkWOm1c
 VR0AoXygGfEzVboQPAgFQ2JEBEyiGuz58yc7G6He6g1Bqd5cBo4YQnmLSM5qK1KWXXgH9st4VBRo
 P_vVTocB0HSrogy9JfLeVZiIGgqnOChwD.8xM4m8qmiYgRi.fdz_OOrMxOYLiKMFyh2ptLq1bfvI
 WP2n0Jj77kOfxtKh6d8hZvD47Mg1GGMkbPRXwhBxzYWaV68bPa0XMVxaMkqL8IRpYIrhh3ToNCP7
 qSY7SiEPrz4_pB2S5SPlCTzWFzibN2EV1fFcMyOnPGqYz_M_mSWz5hhXufPAdAOsVdjd70LFQOL4
 JJ9zD.tLuIqdvafccpDsLd1fyROU.I.VyvACK6quVVI1Q2gyFdsbD1Yfk3iMI.0AsrGacbDdxg3K
 Rn6076_niqV7FdLdmbn1aW8AZjf.VN_8.N3xSOwvqPGifBFIFinG9jYGfy5ZU_gVL6VnRRctnnQ4
 oJGJ5NumHNtzD0GdJDjoHFX12yy5ID6xw6xFH3q07m0D7A_vciSVBK1wFsrmj4dV4xDCEUKBFrLY
 DzFPF.1oRHaMa7qnNmSUr6J2P2QtBWMUGFkb0m2Hjh4nq274Nh1KsLNTmLhkeWGvu0qmkrH33ZPn
 iK9bZD76tNFpVk6iawkwK68exVWjgAAnS_3x2VyfEC2ZPC_hBFyas0sozIP9tNso74OnHoK4Cmn6
 dXfgcDhqVb4O5K3cDRknqC6rMB474fL91T18hVFmwmhyAVbSe7av1I90.6naN.USZh9EAv.ZnKO2
 fKLC4fr31qq9kcMRAfEE8tjb3xNFHcKMq1MQ3MgEnoYMvA_OPyrO..AksOqADAh.CRKkgGfz4qGC
 E7qcKfiwkaZZ6VL0DIih8UVUMjK_rPBtAUPaGOgOvu3NQjzMwO3eNS.LNHz3LGDABOlaqyNxVlV3
 OBu19Di23H6HH6GEFs6goOapljtbyxo_oVYtyhXENukvo2DTqJTw2f2lTsObkalp76YHwBMMjiTO
 7.FbVf0SC0Y__XTU0fYMY0CHM1q7AuNMirt1a1NoMcTVH_POCe2LwMB5an_Q8jdFL0IWQBVgD5Ni
 UTTqlpVwQ0Br.3cihPlmkVpz2SpUjp4yEPMbOMrAOtV5I64HhiTfnQjtMltuSA8lcmSLiFuh.9Yk
 ZFjHd5y4BYWCLCls_U4Ii_BuIS6cgwtfL5XlK1ACjHi_qaUiHB.hM7gy4gbYfdHgez9bjCQNivP3
 _JJ1DPunyXFpAkuH_Lw2rZfxXtKCFoDqlktKczT2I4RZkWGVy7wGEXALifZaWwBX23xwP1n8uJSV
 Wu5UxjhA0Y6xzpcYhKjmutBWXWYoCaMC6zG_iV9Shep0GMCson7n3__YWQu_5UbOf.GjL8u3494q
 b4r6B1cNElwnlYAoEM9c6pr3vpvd9mCIP0AdjivHo3XBCQxfR2zSu171f_PMJ9Pd3BPZwZS2M1Qn
 xoJM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 01:00:58 +0000
Received: by hermes--production-gq1-56bb98dbc7-sdpv4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 57bdd805573f9bb2f6057a83cab1a0fc;
          Wed, 06 Jul 2022 01:00:55 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1R problems on Pi3
From: Mark Millard 
In-Reply-To: <20220706002754.GB9228@www.zefox.net>
Date: Tue, 5 Jul 2022 18:00:55 -0700
Cc: Karl Denninger ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <996A34D9-DF3F-4CBD-A69F-1E9840C56381@yahoo.com>
References: <20220704003639.GA1165@www.zefox.net>
 <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com>
 <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net>
 <20220704152834.GA1771@www.zefox.net>
 <7ce87eef-ded5-8b00-3f11-14407b8af78d@denninger.net>
 <20220704182526.GB1771@www.zefox.net>
 <212C86C0-17DB-45F5-A59D-8BDC1932378E@yahoo.com>
 <8755F460-D5A5-4ED1-857F-37B894A9B875@yahoo.com>
 <20220706002754.GB9228@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld1Sd1sbnz4vCx
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="eat/H+B4";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.85 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.65)[0.652];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 BLOCKLISTDE_FAIL(0.00)[98.137.64.84:server fail];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jul-5, at 17:27, bob prohaska  wrote:

> On Mon, Jul 04, 2022 at 01:29:59PM -0700, Mark Millard wrote:
>> [This ends with a possible config.txt way to control the
>> default Ether MAC address used, independent of which OS
>> happens to be running. Possibly better than using the
>> only-FreeBSD technique.]
>> 
>> 
>> Did you get the two RPi3*'s in the same purchase? Ending up with
>> 2 that both happen to have b8:27:eb:71:46:4e seems odd unless
>> possibly the means of setting the values at the factory was
>> not varying the values like it should in some production lot (or
>> over some range of lots). Independent purchases at different
>> times would make it seem even odder.
>> 
> Oddness won this round. They were bought in 2016 and 2018

Wow. Technically that means the two RPi3* serial numbers
should be of the pattern:

??:71:46:4e

with the ?? part being different. (I might have the
ordering wrong.)

Such matches is part of why the RPi4B's no longer use
part of the serial number to form the MAC address.

>> 
>> 
>> I've found references to an undocumented control in config.txt :
>> 
>> force_mac_address=??:??:??:??:??:??
>> 
>> See, for example, https://forums.raspberrypi.com/viewtopic.php?t=327562
>> 
>> Apparently, force_mac_address controls what value shows up in
>> the device tree for what the ethernet0 alias points to in the
>> device tree.
>> 
>> Note that having a odd .dtb file could lead to force_mac_address
>> not working. (The RPi* firmware reads the file and then makes
>> a device tree with some modifications applied.)
>> 
> 
> With the files on the 13.1R image force_mac_address seems to work.
> 

Cool. One advantage of force_mac_address is that all activity
gets the address assigned. Doing such assignment just in
FreeBSD's /etc/rc.conf means that any Ethernet activity from
any of the below would use the bad MAC address for the machine:

RPi* EEPROM/firmware
U-Boot or EDK2 UEFI/ACPI
FreeBSD loader

It is definitely the kind of assignment where earlier is better.
That makes the force_mac_address in config.txt for the RPi*
firmware to use the best place: everything later uses the
definition as well.

===
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 01:19:16 2022
X-Original-To: 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 E31BE1D12A60
	for ; Wed,  6 Jul 2022 01:19:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4Ld1sq3sjfz3DZj
	for ; Wed,  6 Jul 2022 01:19:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070360; bh=DKsTNeMxoBwjiGuDLquLjnX9Xqk2JVoOpCc2swYbMQY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=krnhcNftMm6HUcYfZxO+lH1Wtu339dDebMuu7SgCtAOg875oRMjqgJYLLuRjtTJvmYAMkPvrKQ3fyqdcfwTzAqH+DW5g2wgmtUyIW2WLT/5jFA4gDph+P6sOp4+oJGpqrQQDtZzQ0Th4bXpoXp2OBK7xaDhNkOeNOsrV8fA+e0NyYElI2vj70da2mJtWxo1ki6oqyY6JWrGHCKzNJ3oc358BTVmncofpfOY3AtDm0+4TavzEiv1Nca9gYOaLvyZrbuYoziU2QSFhROYYnKDveCwYYVdZgceOIDXebeFCswt4anUkpbjuLZ7QarlAPSkhYksJU8SYfghEoXnxc/kEEg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070360; bh=vQ+PvQTdb1yvK9G+35AuCZdVzCXBrjmCVh7vu0asvkh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZaK4mPgDCOK9vNDqJgMu6L5u5znXRLkIVcW3+0ukUHcAm5h20IQP+d4mc5cvyX3rRB/aUD9R4sedjlXqDLlC/XvOk0XgxJpT7Ejn4LUzcBSzyAl8JrXOAK0FYPOQntFwhSu0lUIHKUVuJot8Kyq0MS9zkoXg7kMVED4Tpa4rsAvGzIivy1+M6MakoQ7ts2QEfzTtqIKdn+7cDx/Zgn5bjnGKMYl7+bAUQg7mPTl+uAV9VC2UUnt8o6mdF+KiRIti0qH9fup+xEWck/VMIKHYxX/v/mJQqrQXK/tUBJjggfMkNEZmbuBQbs87i1E4X8v0QcOM4XuYHRerxGwiTDsFMA==
X-YMail-OSG: Ba8qBysVM1nGa9PvxNssFJ0C8zv0qDzG2jABOgpTI0nveVkNTkdpfH3sFKk0qo6
 t4.CFOBtw8j.PKiBnlSSDNKZMMI3ZSDCzcKFvA6WLK7LXQDZKAP3yMsBdZbE5mN51hcQkLhgr3_8
 G3oni5Jqe7VunGznghx9x.rt4fPO51RN_m1LEVaEHglhMIwABAWM11tBHl0onc3ku26IkV0nY_wq
 U1Qebs6SnykFyyqjInUFKSHIM_C0l4ZQ4ra8KpCyfQgbrOFmSJNXfXiy9xRAZssbpse92KxR28oz
 .vJ4UtlID0RbGrevvuZeiSxK5eD6FQ5YvE2ZBGiRDxBkdvuQ280tefp32vW0Eyun5Ah0..uegxor
 l0uiy6bYaeRwzUq3lb3.GsqjQoH0qUt7okjvfzthXAmAmDb4HnIi7yJGgA.eFNr2mEqsTrHD1oVx
 8RZUe3oUxFSTRzkm0v60xffcy6.WviKYoOZ8xA3P3XoKbrc9X2lzrx0vFqaqNe97BppLGUunVn.3
 LHmEQvE9NY3tlDQNOe7m3WJ1x1NATXeHog_QhpLheO.7f98Z6vF334TQvkkLK5vjkoGZHcPszYzu
 j.gdXk5eMZFPEFGn4R8EPXpf6q9zHg8cSsZsa16VgANPWcLbi_2UKnbM6EnqhSMAhh1Nm.WIpbvh
 wE8kGncDY2kqP43_97.iPJ8DgQStOADT9lguSZk5XRId_Q..lHE9JMqTJE9wR2nIFDh6vQI05Tza
 PY0_8u8MoQ7t21adTPM.1f5aOs3zxSG.A1jmgsyKOVcOrAfUecTZ_5A.bVwFw6_0stSQ2sqfCVa3
 QQ5Je0zAcLB.CVdIBMz1dpCUdep_KTPnqkDV4.r8e7WUTpObTmTW.5tzHBEIBgwxDsf79AMLAlc2
 FnXPeTOE43pGjy93WvUlzzicyVb_E2vaM25Z7.4kSwrwCGvVk78lbhBMI1c.4asXTJiC.2pvHhEF
 ReKkyX8YGt2vQgp0MN40bRfIv5TDCopSp_HihH9aBpiFPLnpAK5A6T_7SoGuzClz3G_hp_OaCNCp
 tU8wPssxgCUMgo2hh2L0GgFxaoQzqD8VHznoBZNujkyxJe8auF59KLt.xsW98jwyZcqx86fl6aQW
 j17HcNkeHf7J9AGKGjAFZoNasVrqSTNBKyaZRoBlde1QbUmFOYzI9zQeuwnoGlKhnHtribNbIAkD
 uLHnwDd9pSnchJhmmGTa5WrKRgFl3h4gihEB16tOfzN_EkF7lIvLt7m.jO95TU8ecXDWgEMFoCom
 NZME9X.n6gTBURTEMOqkAOhZD6S2JjrMvgVrYn53FUGJyAi90odOa6kxQ1e.ZeZgext0oYiSCc.J
 52bE6cmJtw3OWvsteGc2UOwMEZc8DOIM6lW5X4iwM9nKkzkwVqy0LPWQRxJFya2MJjgE2Ed.dYyf
 ATMhLu75Z9kMA3m7DW5pwZKy0ZvthyJvSiQM4136UBqKU8nHiVmdD5baaLYMRUSUF2StUs54IKQi
 YfI4UuiSd83mTmXFg361z9sONfMNkCatxgV_tnCSvz4ZjrlCiNzlg1TjezjfXHfK8for8cq2hPcB
 NnwUaP6minbUGAKsTf4tz98KQ.MMhSuXtzaLd4xT6k1oFpOUJV9Hw0eUy4z1rCG2wFzhvaG4rD65
 qQG7grOXzpgRlXcsJmIeb1ftgSki_zXhyV8MRm9C_DL8jdoOUqueYAQ4fRwQp1Pyf71Ll44Ah.qO
 WfoYB4WAyzGtZ9EqvuKzlRKNwuGDVz3PFSKeiug8T0IHi6yuh2IPUXht4QpawzL61zVQ4xPVMXBK
 A.9aD2s5PSp_5VKwTftyyvQgBjxXHXycFmcyMb4IqSmaLIAeXh7_8QSsT4DnIQ93_CTnsW8CgxHE
 8bGHsVxE7gCb.MTPh4G3rUD8YKsbsW30j47QbPjPG1VmqMIRcBFI.nHBpeGfROtfSSHOMjWLBPJ_
 wHnMOKKX1ckylaeWhZWjRKrVfNsfVSWh.Krr38ZZtfnSCSX9s8dwXQDjyBi_rB4mGJfVuD0UQHGx
 EqdxrZdiyGWSDJFovD2LOqvo.5fBU2X7FcWrp46BprgOFnuJdZUxbCRBkqy5OpukegGs5a2NAwC7
 hT1mAM9yYXYkhu4Y5.zf1ihWnfFJJWAQtrHT_qExugeKEmJ2eLxUJWjTsyK7I1qL5rSwNi64esbl
 .weGtTclWq_nQKy2MKT2DX.lXgD5YVzyrrCc27x.lRtn3cD1Xu8CX5EMZmBMFjUSqjXqMJQIyMyB
 G6eVoeqRqaJMQRHdzxRsCceVWbHdbCXqrHYJ_NP6Dqq6eelJbUvY7kX7pF2JNoTnWmMRS6TBdB.d
 DYHvgllCv1gYh
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 01:19:20 +0000
Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12d949a1d99732ec86d2cb049a8fe351;
          Wed, 06 Jul 2022 01:19:17 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
From: Mark Millard 
In-Reply-To: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
Date: Tue, 5 Jul 2022 18:19:16 -0700
Cc: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
 <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
To: "mckusick@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld1sq3sjfz3DZj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=krnhcNft;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 15:59, Mark Millard  wrote:

> I did a:
>=20
> # dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
>  3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
> 3072+0 records in
> 3072+0 records out
>=20
> to an around 1 TiByte USB3 NVMe based drive:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
>=20
> On booting via the media the growfs happened but at its end was:
>=20
> . . .
> 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
> Mounting local filesystems:.
> . . .
>=20
> Unfortunately,
>=20
> Thu, 30 Jun 2022
> 	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin
>=20
> is from after:
>=20
> Tue, 28 Jun 2022
> 	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick
>=20
> so there still is some form of error in the growfs
> activity.
>=20
> At least there is now a known, specific way to produce the
> problem
>=20

I tried different, smaller media:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2

I still got the problem.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 01:24:12 2022
X-Original-To: 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 6F3451D143CB
	for ; Wed,  6 Jul 2022 01:24:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4Ld1zY1ghyz3GFK
	for ; Wed,  6 Jul 2022 01:24:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070658; bh=yP3FYcOH1jlQ4yDIuSfbj/vXLiMAF3Z1Rdyo7zJgDRs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZYnfo1mkzeQcKNjpiZ5Ne/hK0Br4hgPwB6FtJEVZo0UwwKrQwMFBxGorkxh0yMJB6kIpqprvsIIBEHAU6HmyZcbMuCe7ssb8TX8SCR1bF1cUJ69xVUlzV6iTo1d7L8Y9/v6id5zMk8SBolj+NjnH8CjlsdVgUR3SwMOZp0AGeT+z+BWBOoD/TMTLByFoZpImWXUvQ+VqcE+LuuZ+DncwoCfiyvUCHwHiIOUcRDwjoEUj2gDvfStlM871YqSlmoSwBRZq7IhRIM9XpoTs7JqJEWPtTUyY/Wz0TFSr0c6Qwr7MwkdRxwsC00HQ4IsLUZlwISWU5mb5q3fddmB0rztN9w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070658; bh=cmUsYM0VB6WUVs/MorW7eNiM8jlKiGB5jaMf1gfmpci=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jpXOkUOoI+b5tHveaZpefH7fc7TWD16+UK2ovATfOXgKA0OyLjrkpqmcRQdmgmJkf1c21cHKzatueNm6JJLTVrUFx0nWnxFXBdw8DpUneehEbypyrKfiO6K4kxowKcm5Xx/yM9NtRxJ82EVbtY7L0NydRDM7O4YRPUhgOJ0HDl0pMwLpnLrHWEatIta6VfliJiwxqgY2q9OzlGorzd1WcB4NDlMFqtewbeARkFeK6JubjsPS2L518yxf9d8u+iX/Y9Sx0hLvnehcE6etpVVeza1mXVHn+R0CRfpNPkjZW53It4Ad+gVaX6r7aTH10Yn/Sri/jsvCKeMbjJMlSZtw0A==
X-YMail-OSG: 4S9eR20VM1mrgpygW8NmaQI5iMyHtwmOsIuAaWhjT2n9jpkYUOcDvjViEkZ0XLV
 Zpgp5U3kKClW_.NruBtUJYaa02l29rAPugAdLfDQ7ld_F6kADQr2vrzBohFQioBCMxOZxZWKeFwb
 veIPuIOxhHf1rco.neR1Gbef1kj0nrOBlLRaVTOZ8ggKK_XYFmlw8cWZg6yktEzlfgygRyj9_CHl
 uGXvUwSsjVvZYO8CUfma4XlSo6EhRXGpiMYW1ePre6S8GvBg6Rb81uz4krpLqLD6RdNpZHpekon2
 dp.LlJPfd1ouoiUUxIM7TEhtNTZ.BcDC5qnrloc9kJhkQvKWJMyekMRDHUCluLmFv5TvNx0UqbKM
 yhAh.RBQ9vlPJh0DOjoDyy5Sw1l.lX4uY937vqmFLZkcx3Glx4sokRNiCIwM1_K7HH9D3qPFHvDS
 u_6tXXbtU7SUDKs8dmKpwkO5pyaS4Z9JunRhZhGn1J_Y0N1HXVq5q4WcMB_AccLEgfHOHTIxknko
 sfgYwjYElZZyAHZwdKI4qfyQi_P7AH6cFf5CfI00TILSadEOo4Fj7os_M6y.Wil9vCWdaJSfy._0
 9pEP78.9a921EVLnmfHoCaQpjT4M.Vb_MawBsDk_QOoFVjUewTyHyEKarf0O07YPlgBP9pAu_.P5
 YeIDXme8apHDd.zCADhFI2w2JhCwmh9k2fIlMWOhR2Z3OkWTnGZgZvD7l91CEpWHj3KOZ234.SZk
 QG_aegFkUyLgp6H6YwH41MOz.5twuL8au60AsrLG4xb4c_5RLet7hEBtUcH1XDg5UJfyTNG1vwV5
 9rT2R24m.nw6uaVFXyX7eqxK1Ot9tx.ncuibOAmXmE.0871ge5w8E6ixTrLpjJQWDpxgUVUfX765
 kIn1yMxh3dqMhrMpCRbsMKEG2NqvwZBnQz32xw0Reva.oq3pIOogjgKkBZqtvafy2gzEe2ve3d_B
 3ZNEuZXm1FrTSbA.Cn6OPlwZIJHd0NNMyZdECWlet4WrFWmO6BUp1h5siTZyLzG5zKXZZvNJrZ9A
 3u6oTzCoQz2hNG.ECbjAj3Brnb9deJy1EKjo0ulopJsc25rTbDlHy1bvG9zGwkpiWrp18Yp72eZv
 axlxxI1iYcSTrdjcit9U.zue4XadKde_ezvngDiplA.pWQZL0kuyy5wkCbeXnqXx.zCNdxk_lvX.
 KX0F2Lr4xuzdDGPrbOb0X1V.Qb2fN7sLR_CSTn1Y431eBjvlZivep3qQhP.ugDJaFvMLCFiY5JcK
 JJBH6wTZJ2b3Wo7oCycX7YJljdT9Q9lU0qsPEapeutc88owoD4Zhu16ekJqRd7AJxQhPv.JS5lcp
 L_w9T38PxQ0R8Q7FyyYcP3XQQMUiRSUojBLdovHYS7leQyrpPOKmiv6gNwX22c26TZVJ9BJo9pVR
 iBAslLk.YKC.U5Nf18nHzCDe06jXqUrsj3FGF8qi9QetKxkdYKlc.If_rofBRW6xf3KVzXCe8YQm
 4_fkTMleh3axxDsWh23WBBnOyYI.T337sypy.IzVkCY_Z3dU5i43MCX6I7kGNa1h8Vj3t2YvP8XB
 JOdHxk2bQMRp.2FIwE9y.N28YNEWk5Sx_.Fbv20AyxGjZjFC0wPopWR.p3noT9BfhEZJfOsQXI3P
 VBRFomHj95UpGvFPOq5lYbBK4HN8LWkWa.stPNxnpjBUwt8Nff9Af.Ui4ynGsciAim.KxHPXr93E
 w3dLapVY08ByeIYEe_JM2M96UQLRRxv7CmKz4_rw62EvmlVddirSBLz8Jh9yXbqbWUqZ7FziqD0i
 kDKTXPVebg_GBYTU7rgQnQOan5XmxBxjoEjEVCRy8fFGUP3QSsGbOqW9tgqGxVgYQUa7rjSALCB3
 zHNOKIJRmzCo5c6ZTMSWVNE2sSzKbq6aXWUl.u.83gCATboZPLdhDed4LOU_gmT.0ayxzyGqTpdt
 _x0FBN4zI.3KtiKSNdjXprDfQzJoo8vbo18vNAdD67MisvrS3TgL8ZiyFnIy1JiDc
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 01:24:18 +0000
Received: by hermes--production-gq1-56bb98dbc7-fn7k9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd34fcce776c3ed5f64025b88287399b;
          Wed, 06 Jul 2022 01:24:13 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
From: Mark Millard 
In-Reply-To: <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
Date: Tue, 5 Jul 2022 18:24:12 -0700
Cc: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
 <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
 <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
To: "mckusick@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld1zY1ghyz3GFK
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZYnfo1mk;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	 MLMMJ_DEST(0.00)[arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 18:19, Mark Millard  wrote:

> On 2022-Jul-5, at 15:59, Mark Millard  wrote:
>=20
>> I did a:
>>=20
>> # dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
>> 3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
>> 3072+0 records in
>> 3072+0 records out
>>=20
>> to an around 1 TiByte USB3 NVMe based drive:
>>=20
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
>> ugen1.5:  at usbus1
>> umass0 on uhub4
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>> umass0:6:0: Attached to scbus6
>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number REDACTED
>> da0: 400.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>>=20
>> On booting via the media the growfs happened but at its end was:
>>=20
>> . . .
>> 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
>> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
>> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
>> Mounting local filesystems:.
>> . . .
>>=20
>> Unfortunately,
>>=20
>> Thu, 30 Jun 2022
>> 	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin
>>=20
>> is from after:
>>=20
>> Tue, 28 Jun 2022
>> 	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick
>>=20
>> so there still is some form of error in the growfs
>> activity.
>>=20
>> At least there is now a known, specific way to produce the
>> problem
>>=20
>=20
> I tried different, smaller media:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
>=20
> I still got the problem.
>=20

But the context was 13.1-RELEASE for this smaller media,
instead of main, so the context predates the growfs change
recently made in main [so: 14].

Thus, the details matter for if this newer failure was
expected or not. I do not know.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 05:01:07 2022
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 9EEBC1D0DA25
	for ; Wed,  6 Jul 2022 05:01:22 +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 4Ld6nq1Qcnz3rnr
	for ; Wed,  6 Jul 2022 05:01:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657083672; bh=fw7xopIuRSBwV4q6GSxOIG3p3Fp8se/rDA366ounGgs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fulhT/iclb/a+hdMNrT5uz17FhCtM3tv/3MYL5ofYtjkPrshpBGf3bsazfT02xMQ4/0Gf/P37sXZL3snRoQBfpMMlTkEByqbPSXYetgUl9NsaxCyXWcDh0hkOgXmNeS7VsbOLgIUX80IAZFwapSSIefgWs6oso5zuV5gbfTN8MBQ+5VBhbx8cckMSmW0A+KnOTrK36gtlrWc8d+MXs0+uwelAvdIOIyevEyKjPOrgH58/wg8Qv9y8+eFgsbud/dY6BNZN4QVBCg16uMEuItiyJAIkhMuGgi4lEjVCR5cYX5xM1HslkDJ5AlP7wi2zstuByBT0sOBAPmPGQ80W0k6Vw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657083672; bh=Dh+Cvw8sJdOkjYu1ZuMV5Ir4+xhyGkJra6ss4tY5kzX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UpDOxEYNsc3jNEJKZeIJ74lR0IOe+rPkVKN0jLdRwXbzt8ZA2F529bmFZWW2O8BGKhxKKE1fUZ3DMOjfcYSrfKfAMoPiY3LRnvxyK8bGM3zoig9FHjmn4VgUQ/OFZzKvB/90MwRuX6Z/G2qRwzT63AHgpM6RONy9I5oU94x2aT5aud3noW1meat1GbBornnyzwPYmzqJ/3Q/G/l1KZBVuJn0exDQ3uztY4Rw6lpVv0wXZB/diVZtLxdEm57F0tUNt8Fjq5y8WUwiTs4ELkKoP/a6IuERwaVRUMlJ61AJz64js7NhB0X7MG53iKq2bFuQwk0yapXryM6eThnW32qRNg==
X-YMail-OSG: cszwVngVM1ncR4JiIY.NN7NEnY0KV7eCK0w9_5tpd_828gMFf21H6V2OoPPXWQ6
 U9B9qY5St5U7Gn59_VRFSXjGjhz1IMsP16c2wh.BJPEoVi5LH1xd4.p1rhfgh9JC.mKVVsZJJvcr
 OqPR8UaJbgf05viP9CGjcx11zcaiN4imAhl4jd6DOh_EuPGJHYjpAr2A3VFcst.AE1KUHA9IbkGd
 woySwYSexLhZ2d2WIHUUWCDjhGNDD1TTMUDOuEEP8gA.8hfKBzGu9MgKSjuqn5gRLnqc8p37lRXB
 d1SZXDJTpMLQRQwJkLhHHc20JnXGSMPWiY5.neJHOFwzkUFsQcoa.ZdwD82PshUMg4GyOTvfXoF2
 jh9vjG5iOKabni1S6.ChfqzBpm.1YOSknA6tWwa.lImjKRfT2WN0R6LADCWDR.R2QrPjAbGYPKsp
 HDEHWMK9YznThoINShEU_UYFtsk.hswMCDwYMby04_4RlhLDGO.OAX_NrRE33JAYR0MxPTflqohx
 ITiJt0MZV6o4V1jR.tRXVB8P4EgkIq.v1pCfeSeUiaedaB2Y9BIIqgbyPgMylopTUWJ8or0EK2De
 Tl9WcKsD6OOW_NoNkwouTIEM8svWp1BbVGU81UMP872goPKKEXXvSSeLx9JVtENxQeID4pdqyK2Q
 5WS2PnsxERr134oQpDYd_O7zKu8qKw3it4yVci.yiMrFkF7tuVNv7SpaY42_TfvjRVGI3oU1VFTo
 HmEmDi1_YdpWBC_bS3HJs4Tx4D9uqTkoA4U2TY30IXBs5ZVUEOf3Q_HCbd_ZIb28IQsQb9HlC5cl
 YDnzKdzQGvT5266KGkBK4d3kXFieo8yb_uGIH7eAYwdpkB5nr_9dyrQe8GaXniGxFxhAEmZoGelG
 vm.XBXyP1RqoS7nVWthv1xXxdbf63emS01bwDgqqowvKQWmvnulbiMN0pqqiQMhoxHfOZuzTx44I
 X_SAGJzNBh4L8JX.WFajdFky34W6uLgJ8i_qwharivSFhiBpayKRMF92IrUdJRDsKI8Fyd.Sdudc
 KJzgo59Nmmt3WjR33Sxvvgw.lmTD8wxStg3Oz0Ss.5XXwgb2T6PX3CgrY7W_wovj_SJcn9LLZWgI
 JhLanJcJggfvDwI0ExGpWQyPRYaqt0eNztwoW.mCfS96ZXgBOliSkicVWxhIWlaFQyAJJHucxkE7
 JKxYJSzn7kL_xpRGbJraPqmEKrMgAM5rvRskbc63opkyUuQWr.jR.9p6L4PfNjPGHJQGEgefnUf8
 cbid2t13q1hI8tgHyhKwlRUZP2oW0qgh5JD7N445TZg0bcfQ0Rlfa9hXM0H1YRCAinQkLwFU1y1Z
 Y5xy_PIeAD9Jt_ZQraUUY0L3mubpsw.j1pUnr3lmHbuE5nmaGYkX36rRqYeDRK5avchc.vitSQvC
 rtzQoyFN9HOmbKymX.FsW8_K9yPNqH9u25tX1Mz1qEIFBjgRFUbyq9z2yUpd04lBUmswN_VJb9A9
 kvcBT7_5ZqFL0BdjmArZlNcjQ3Zv_ePJd7ZarK7OH5lsYNEtl3qh_eZUBUz_Cm7vMhoyvOrAmN0S
 GmiG4CFtccHcWJR2Csnrw75tZZPURRCQWU5m0AP.noqDJNMNcuPu3Ueut5IwGKigKmqjppegS7q0
 xaaafOPnPN1.uJis43m70MVkxnfFWnhc57DlsydpAHDaQMBaYGlFZhT3ENh2OWKYngoH00KJxkaF
 sBhOXFe7f1LSuwKLOoHd6GeyKsPWxHa.WYZN51NBeDtrTLKPmGD4MeCN0bij40.gf5OSpq5aovmm
 QxzkAoHcv4HTL_l_i4XJrmS3rEbwtIu2SkcxaDIAfEXPfFi4EaAqMnuOjz0QQaJT7s4.OpX.WY7D
 JTPiXLFHXcvAYFrLOHngI8XRkGBVddr2wYiUapkx2bLNgxZhJ0eh1bxi07QwRXosSig9PITGEtTs
 Uryklsy8D7NTQN8RJY0uwl_L7TRuI3R_fg4wdKXAXgtqgb5e0NNGdgBmwlLmalkBU0QOdFsYAEoD
 UjBxkECkU5y59rJv9NDSsLsDzhg1l2ot5eBcFGzNWdOR0601p9tvInbNxYumgIEGyr16UE3UTgnz
 JqzP4h3gWz2ikjgbqamY.LC_A3XEdZs_gQ8Hz_mitxnO2CX3SEmaaW38s4NoymiPKxCtT6e1gAYu
 VJHuBcLE7ZfUfkqF0vrOVw6wGDERwuFdBUG9CViw2uH3pKElCk6.re4iVPHFc3CIFqCCjcXgDjtW
 z_uuUxXbtgb8rS2rXT7YG5M9B7FNep6m1LaTHlx_ImIPi.tYJ9d0uKMCKH3QWe_EgID6zSYXWe1Y
 5iVw7pwZRH1UlJRPza50O
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 05:01:12 +0000
Received: by hermes--production-gq1-56bb98dbc7-fn7k9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e1504cc87327e9092aecbe3c06591785;
          Wed, 06 Jul 2022 05:01:08 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
Date: Tue, 5 Jul 2022 22:01:07 -0700
Cc: John Kennedy ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld6nq1Qcnz3rnr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="fulhT/ic";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 BLOCKLISTDE_FAIL(0.00)[98.137.64.82:server fail];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 08:09, Dr. Rolf Jansen  =
wrote:

>> . . .
>=20
> That would be the second step. The first step would be that somebody =
else confirms my finding that building and running a custom kernel on a =
stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that =
was my initial question.
>=20
> - In case somebody raises her/his hand telling, that this worked =
flawlessly on their system,
>  then I would have a more in deep look, what might have gone wrong =
here.
>=20
> - In case the issue would be confirmed, then I would submit a bug =
report, and the discussion
>  may continue in a more productive way on bugs.freebsd.org.

Summary of the later material:

It would appear that if building any kernels are
broken, it is specific to some custom kernel(s)
in question, not to building kernels in general.
13.1-RELEASE's install is able to build, install,
and boot its own generic kernel on a 8GiByte
RPi4B Rev. 1.4.

How I got to that conclusion . . .
(Written earlier.)

I'm doing (written as I go along):

Establish a USB3 media from =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz
and releases/arm64/13.1-RELEASE/src.txz . Set up some basic =
configuration.

(Note: growfs is broken for the large expansion. I used dump and restore
for the ufs partition from a mounted non-grown dd of the .img file to
other media. I also copied over the msdosfs partition content. I set
up to have partition-based swap space as well. I used gpt partitioning.)

Boot via that media on a 8 GiByte RPi4B Rev. 1.4 .
Do some live setup to finish things off.

Then:

root@13R-ufs:~ # cd /usr/src
root@13R-ufs:~ # time make -j4 kernel-toolchain #  630.15 real 2302.72 =
user  94.36 sys
root@13R-ufs:~ # time make -j4 buildkernel      # 1790.12 real 6488.26 =
user 526.25 sys
root@13R-ufs:~ # time make -j4 installkernel    #    8.17 real   14.94 =
user  12.00 sys
root@13R-ufs:~ # diff -rq /boot/kernel/ /boot/kernel.old/ #??? =
Reproducible builds ???
Files /boot/kernel/kernel and /boot/kernel.old/kernel differ
Files /boot/kernel/kernel.bin and /boot/kernel.old/kernel.bin differ
root@13R-ufs:~ # shutdown -r now
. . .
Performing sanity check on sshd configuration.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.

Wed Jul  6 04:22:01 UTC=20
FreeBSD/arm64 (13R-ufs) (ttyu0)

login: root
Password:
Jul  6 04:23:28 13R-ufs login[1210]: ROOT LOGIN (root) ON ttyu0
Last login: Wed Jul  6 03:18:32 on ttyu0
FreeBSD 13.1-RELEASE GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: =
https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the =
/usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting =
questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
root@13R-ufs:~ # uname -apKU
FreeBSD 13R-ufs 13.1-RELEASE FreeBSD 13.1-RELEASE GENERIC arm64 aarch64 =
1301000 1301000
root@13R-ufs:~ # freebsd-version -kru
13.1-RELEASE
13.1-RELEASE
13.1-RELEASE
root@13R-ufs:~ # gpart show -pl
=3D>       40  468862048    da0  GPT  (224G)
         40      32728         - free -  (16M)
      32768     524288  da0p1  13Refi  (256M)
     557056   29360128  da0p2  13Rswp14  (14G)
   29917184    4194304         - free -  (2.0G)
   34111488   33554432  da0p3  13Rswp16  (16G)
   67665920  356515840  da0p4  13Rufs  (170G)
  424181760   44680328         - free -  (21G)

root@13R-ufs:~ # gpart show -p
=3D>       40  468862048    da0  GPT  (224G)
         40      32728         - free -  (16M)
      32768     524288  da0p1  efi  (256M)
     557056   29360128  da0p2  freebsd-swap  (14G)
   29917184    4194304         - free -  (2.0G)
   34111488   33554432  da0p3  freebsd-swap  (16G)
   67665920  356515840  da0p4  freebsd-ufs  (170G)
  424181760   44680328         - free -  (21G)
root@13R-ufs:~ # df -m
Filesystem      1M-blocks Used  Avail Capacity  Mounted on
/dev/gpt/13Rufs    168604 8159 146956     5%    /
devfs                   0    0      0   100%    /dev
/dev/gpt/13Refi       255   25    230    10%    /boot/efi
root@13R-ufs:~ # ls -Tld /usr/obj/usr/src/arm64.aarch64/sys/*/
drwxr-xr-x  3 root  wheel  91136 Jul  6 04:17:59 2022 =
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC/
root@13R-ufs:~ #=20

The build and install seems to have worked just fine,
allowing booting and operation.


Notes:

The builds were done via being logged in via ssh. The
serial console causes more time to be taken waiting
for the build output as it progresses, so I avoid
it for builds.

This media will be around for some time to possibly
do other experiments with if desired. Provide
explicit instructions if you want a build tried. The
starting context would be as above but the instructions
might say to "rm -fr" various things first, if
appropriate.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 09:47:34 2022
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 0FB0A1D0EBAC
	for ; Wed,  6 Jul 2022 09:47:43 +0000 (UTC)
	(envelope-from peterj@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 4LdF8G6mgdz3G2D;
	Wed,  6 Jul 2022 09:47:42 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657100863;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=FFqJxaSmwXnmji/PxndmJUbSngcnkWTWglEpuRhsTHs=;
	b=KKZ/oEbnG+56zwRJVtrW97T5OJ/5045EbLjCjwH7GkaiSEfduTrFcgEMiiMnJUOFqWt1bu
	6kMwR28PCiIy21vQtZkUR4J/l2eyLLr+2wibbtw1hwEcMcZsQR0Ef7HJ9Xjp9P9570TJLv
	y3XteIDXoMx4AvMLlmWsjqg7kdDuzCUbXNEm3Z+OB/7OHLb0ABtexR2u+YTbJNZLUGWzac
	AsSgi1LaJzCwEY9z8ibNUY52jxwPwWiUF2X+yqQXP2oES2TM8opstNYRubQyrhdw4dd+gu
	hrmoEYikEEKMPsG0Q80DuKRH89fst0/D9RxTrNNB+sxJtFDIWR372nxJPucffQ==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id D79C3349C7;
	Wed,  6 Jul 2022 09:47:41 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Wed, 6 Jul 2022 19:47:34 +1000
From: Peter Jeremy 
To: John Kennedy 
Cc: freebsd-arm@freebsd.org
Subject: Re: RPI4 + ntpdate + unbound
Message-ID: 
References: 
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="4j4IsX0Cnb6tLfEa"
Content-Disposition: inline
In-Reply-To: 
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657100862;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=FFqJxaSmwXnmji/PxndmJUbSngcnkWTWglEpuRhsTHs=;
	b=Non4bcyUYdwe3fcbVqzwn/+E1FqrsV00aZ+iOTneo/ltKlT1LosQCHeWG5ASez8qpAofPw
	heexWk3qsbkq8K6ceApDS3rVj9KLD3LOI+X0lXBqx8yDloFz0On54waqutVNe8agR+xt8F
	bANRqNh8d3/oonXemXdA3DOsBnyXppstxxDfEfLJftDsFNK15/LSSLFbkG/o8f8CCquUVG
	hOld69CUH5loah6cVBy9ULSOHUEzxXX2vGgDMQOLdzwBgrVFulRNh5rdJMl3GgeoBueGjt
	7qdXiyK2tqS3BLAqfRUozGqUi9dfLDQwar9qH5qSyggYvDMaUjUehhIy/dP2IQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657100862; a=rsa-sha256; cv=none;
	b=bhlEVApFSBlVA+xPUN8NILZkVSJpPZjVq7P8+6/g9xdb7Xbpv2tUhLVhvjYl4z5Q86Yqs5
	WpWjETmwPWXBDZ8B960I/kuvtafcwfO3+pGoSyxtdVQCt7bGOEBXdXzcVizdjk3dmntZM+
	NYH/CScqqf6PDBBVpQn5Em2EVMHwmogfVfStzxpBZnLB3k7Lp8d1g5iIqq5viTqhjhqQ/u
	vrCyHhStTiIGEgSit0zQ8R+7PeeuuJ9lAzQaocfjlUZcbIaEXqQ2/TkL5+UWZFNae4O+6T
	9LVL0xZdxsHWZVOedTB7w/xpU1wbWxGElknTb982BBZ//cgEoPovR3FTtr7wgQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--4j4IsX0Cnb6tLfEa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-Jul-01 21:02:05 -0700, John Kennedy  wrote:
>  So I've got a RPI4 (no system time stored in NVRAM) that I did a stock
>type FreeBSD install on setting the time with ntpdate and the unbound
>DNS server (aiming for DNSSEC).  As many people have noted before me,
>that setup is sort of broken because you can't look up DNSSEC hosts if
>you think it's 1970.  No NTP time servers =3D=3D no date reset =3D=3D no D=
NS.

If you're running UFS, the system clock should get set to the timestamp
in the superblock.   That will be the last sync before the previous
shutdown so it'll be minutes to hours out of date but that should be
recent enough for DNSSEC to work.

Note that this only works on UFS - see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254058

As an alternative option, the RTC in both the Rock64 and RockPro64
are supported.

--=20
Peter Jeremy

--4j4IsX0Cnb6tLfEa
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmLFWjFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzRFfQ/7BJBpFjMybIyr+Lo/hAy2vIG5BaAaEMcPM2+e5yitd4Hz7+0hFVU4ovKV
tQYvkW4Zpc/6HMycp2G+zPDVBP5VuEMLrc17I+YWc63mWwjwBLsCImUGb/73HEjs
0X5TU5/qosf5qtUnFc/+wKa16BcF9Z49KH0sQVoBE/lM8x6cAkVJIgLfj7PQbHIA
kLz+8HmTGhypSNmYjSZwW2M213Rn+XMkAq55EWnILWyghgqgByBAwNFaPtLMmv49
NkBvgEWq3/cglDzGqL5klKkUr9MkGpMsqo6ZMP5KKgAAAj3gVDLRIXQPNLuRxs7g
n1YLrdFvqGLC/mZUYU7HXjEUgvNTOVMlnptgQH0YMCgVBpGB+X7BY3RFeoXmIfL+
FWhDbBuF9onA7Cr+YY9s4+r0MD+kF+rzSQSsGyFN8Lp6iCTaKAsbNANQGdZcmxKJ
PCTOTKpGJR1ol963GiLgosM+gLtv9thAS2yjp5WQFOrNwGdzfyPrsQQ1LCdQP2+a
Au0XIUWcmabDgdyyvwLeJ/+hhjxoxEd19D2FA+Zo5wJtuVOvIJJsD3aSX52kShxr
0hN3EsN+4EG/ZmgIionJ8dfWPAWguS9++5zz0rBhjVAIvqM32Fyo+xUxksa/bJF3
kCZt7MwtJrOoxgc6a0OWV1xa0wRyjKumvIkIpFwdyeReCUJN17o=
=RMQX
-----END PGP SIGNATURE-----

--4j4IsX0Cnb6tLfEa--

From nobody Wed Jul  6 15:29:23 2022
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 02B071D0024F
	for ; Wed,  6 Jul 2022 15:29:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4LdNkq0BdSz4lLh
	for ; Wed,  6 Jul 2022 15:29:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657121370; bh=+5keCzMC1b4A2GpBO4ltTwMJgLM1nczyQJouym8a7QI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HPqBckC0H70rlRE5aHdO3yGo0jWQKAigR0/iLgKVg11TKG7woD3+pYCSXN4raKD6fO9ZfagHbY4OeLJfh6z7+udvAAOXa/dVdgXvElttYkN3ITjxnG7ifdBYZNMNTdNZQ7/eGQO30a0FX9fObkkycedZTFG568wDbz9AI6UB+9bg3B7QbWV7UONKUQpafvBb51Y4goxcNfWO5/4WVEPXbdPp/4g1q5Fx3z91dB7qUMs1vX72eyvsrbobOGfaFAXkUBY/mA1L4jGeN7OVdT312S77UtbAZH/l4E4VGYFHbiiliPxcIlEXC7vQcnHmt+9dvDiqilSI8M8VjA+6I2bnuw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657121370; bh=L0dLe2ePX9Q2MkIsuvCg0sTAPNuwdQoNHdD2nHiHR2m=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lbFw5K4Xc+pnrSLUD9zqnnWJtvDbjwp+NYk89ap1RfpOO8x0xaX+VYfKth45TfvMrA4IG+/orSaKseViAg1/eKfsYYf3JHm2lHyqEDaEtkhClmFcNGU+7Aec8OdbpjGc/Frh0Q1cmlmlL3eMwYldHJaMc6YIjVKxwMf1903BmL7rHSB9Rdgrb2hEDK9gQkAV3S3srMcbtm2fV3a4ZxLGSruC+GDYPGwEYzbTU3KOInXzFOXSKwPHR1DYZ26qD1M6EoZui0dFQri5wjJY6adp3T0tcRV8fvF5e8tvRuPC7ljVnkvWJDuBski3XEK3AusFUbnlpNwBFJ2Xg96XnYP93A==
X-YMail-OSG: 17r9B_4VM1n7h7jXQNBo.Rj12mrhHVVtK3D6gG3oQy6o96PpytAi2xOwB7CEv0t
 .mZuN5zfW4Q5U8W4KTlXouqwPC2tdsLfi6a.qBtmeRBF.kNnEOQkbN3xFBqHZz3MLf8WeAAlHOPY
 j.1VHknV7KwtQNfmIVD453iLZ.TEqlNJzi1.41yTI0fbEAXJvJIISHBiNNcLFkBOEp3Jo1GGv25u
 lddg9y07Uv5lWEa7jS5WtaAvEXZT4NS7zPabksnXKvWHSoimh4p_xIrQcPPGzRoVr_eysDHTQlfK
 u6z6liFSLxUwUcVKLe7PwvjRF.UD2LwhqOrL7emXV3JYGFTk0CVpIQszMxC1jdyRJF758H6A0sau
 Y4MU2UVIncmXQrHdYO43Pmrj6tfiuGPbS5Mo5CFjX5OK0RTVPsomCjoIXe5e6JQIrpkIhF0sKkNP
 LwBROYW2nVYSGmkDPA0cScEIAvQP..53QW7ZzbEVNRPSXqqfEeJntnrkTJYTee73AZtjL4.SzG7z
 63OuDx6YZWH2tfOGU2cduNWmJcn5KQbXM88mBRAUmVTzWZmuG7ZYk8mUK5EzUr.ldMTxvsEOsM_4
 aqCJ24aJRSB_ymtf2mkC8yBX2EZvGXdS55v1zYGX0C1oOra5MfecDsgcEPyBla1j1qt2PsWHv.Su
 xwsoQIQCUV5sm80TuMONGHSNDlHhCd6F_K12JZZN1WG25G1qjT5_gtzUGYNC15LSbTLMZuibT.zK
 P_uwnu0aIkhipGBDz01h8kPhVz4y4wZ5k7hmI99cEURD15AW9qDijrzjJ1MdVIqOmOQ1WtHK1Gxh
 AkUI6iU3YYeBCJRA.d9UxwYVLDFy5Z.uJld_kRsmSACzAjAlAf6FJr09fW85LNTeN_xz9DI4c7Oi
 wigAk_hiosiO_x_oxwsDN_BhTLhul.Db0vvdJrP5IU8OgXO6MN4WlbIpPIbRsNKpUJ92dvf15ozn
 6lV33yJKMpvraci_ZWYHJuhx.lEcZL2bboO4_LRsyx0e_m0m9noI_M9bCYFpMTPFUvo1IYvv9uFq
 p3RbsiZilHWufxOuWLnyHm91wSVqvtzBmNMbewT34wiAX1CXr8WGndsmdZIKymIaRMMrwFPQ8kAi
 fPzLxGnUKDmD7irlbuTsmzyvUKcZoMVe5yZV3wX3660Pj0fbeSMKA_NLqpPt3jDhGGNFDz7e5uX.
 _PCprv1T2OITaRN5oCKjcS8.Cn2A84ttZ.mc1dQGU1rr9JHo2Yjuru4ZubInBkoTUv9FF.iuR9H5
 PXOu8OuOYkUVaYXxDcOuSX3avp1kH5w12lNbIDWOy3mdXpYBC2y0CYOlkiT7m9YrkiTUdBCkwXhx
 KQhuvMV1DZqF4uUi.7c2u_V50gyW5G8LDN.ruL4r.e__fX3SmK3QwHRJgt1SpYqPl7sqIc34iS6U
 j1hyAwuyduGdEpD9q9KoTIqg80uR0P7HAa6z83BYhXN.luyFUt43k2gvnaXB_3Cdm1f3SoEIwFJ0
 3.9sjn4Y8SKOLIn3cGwEl3_47O5o_53xM.YzMmbg.FRw7CUYyT3H4LSZbo9afLfrH1mCy4bbaO9L
 5uKTq9Sp4KqhuhY8pt2OY5RMfKwAKZz2WPghlqYaRvIPWCciFH_dfmnCB.EFB_8NXC9YB9jxYuxb
 6RbZsMyIQCRfS7ihHNY1H6b9VTqSaYYr7fVzd5kD5krgN5GGM6NbeUzrNXlIvkQh6jyxfTQqL5Uh
 OeD9vlYmuvaktLc4MoJpOgZ8MFqZIpx_RGNvxF5qT_W4d2_JXvZSVeR5_uZwhSU3xE7oNYJMgRW2
 ZNNmSm3qZANlpcz1ASeBhYN5N5hzLSf75ToNlvKx7Z5oK8NhZZ4128hnB2RRQhmorBX3vtoda0hm
 s2xhX7_x48cWBwHiuVKElqhxK3ZsuLteEAPjFf6E.TpVVmS3URBuQgLSxyeC0_UOKylniD2QcLW0
 BZ_Erapr3KFPR9J8dgNn4AIZzkkfbRSfNFCAw7jtbCmYN1hEiZ3b4pHoIFnofMkhaonhGrM_Mqqe
 avGqzHDe9dgn8eA._5RMiqjOq8pjct024hF6pRKsPiPb6AOo.28Mmtfx1aoQLfJN.LQxWVASUMf5
 FYtE4ZzhuUttSXE7WWY_Of7q3vhw2FwMAeouOrEda43pkbwf2h91ivI42iQSPt8obniwT3IQnqEL
 pLpdZhrI_QlmFwvdiY8bIM_VST7OQ9xzP11zXNeau3kD9_fqZLBxrW0JulKvvkpMkAPp.CTL1lkt
 Br_wYOVZUe.Ud1Z6PRw7f.Clmh.Ax3nXvtx9Ftd5vK8nzmLBQIerL_U9JCRZY_WqS5MHYAoD19.j
 2syzLYQ35BEusPwBRZ0Y-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 15:29:30 +0000
Received: by hermes--production-bf1-58957fb66f-bs7vm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1815854a20a4d7aacb8fcbad76664ce1;
          Wed, 06 Jul 2022 15:29:26 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Wed, 6 Jul 2022 08:29:23 -0700
Cc: John Kennedy ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LdNkq0BdSz4lLh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=HPqBckC0;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-arm];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 22:01, Mark Millard  wrote:

> On 2022-Jul-5, at 08:09, Dr. Rolf Jansen  =
wrote:
>=20
>>> . . .
>>=20
>> That would be the second step. The first step would be that somebody =
else confirms my finding that building and running a custom kernel on a =
stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that =
was my initial question.
>>=20
>> - In case somebody raises her/his hand telling, that this worked =
flawlessly on their system,
>> then I would have a more in deep look, what might have gone wrong =
here.
>>=20
>> - In case the issue would be confirmed, then I would submit a bug =
report, and the discussion
>> may continue in a more productive way on bugs.freebsd.org.
>=20
> Summary of the later material:
>=20
> It would appear that if building any kernels are
> broken, it is specific to some custom kernel(s)
> in question, not to building kernels in general.
> 13.1-RELEASE's install is able to build, install,
> and boot its own generic kernel on a 8GiByte
> RPi4B Rev. 1.4.
>=20
> How I got to that conclusion . . .
> (Written earlier.)
>=20
> I'm doing (written as I go along):
>=20
> Establish a USB3 media from =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz
> and releases/arm64/13.1-RELEASE/src.txz . Set up some basic =
configuration.
>=20
> (Note: growfs is broken for the large expansion. I used dump and =
restore
> for the ufs partition from a mounted non-grown dd of the .img file to
> other media. I also copied over the msdosfs partition content. I set
> up to have partition-based swap space as well. I used gpt =
partitioning.)
>=20
> Boot via that media on a 8 GiByte RPi4B Rev. 1.4 .
> Do some live setup to finish things off.
>=20
> Then:
>=20
> root@13R-ufs:~ # cd /usr/src
> root@13R-ufs:~ # time make -j4 kernel-toolchain #  630.15 real 2302.72 =
user  94.36 sys
> root@13R-ufs:~ # time make -j4 buildkernel      # 1790.12 real 6488.26 =
user 526.25 sys
> root@13R-ufs:~ # time make -j4 installkernel    #    8.17 real   14.94 =
user  12.00 sys
> root@13R-ufs:~ # diff -rq /boot/kernel/ /boot/kernel.old/ #??? =
Reproducible builds ???
> Files /boot/kernel/kernel and /boot/kernel.old/kernel differ
> Files /boot/kernel/kernel.bin and /boot/kernel.old/kernel.bin differ

Turns out the differences are mostly git-context text vs. not (src.txz):

FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
vs. just:
GENERIC

a couple of times in each pair of kernel* filed. (The shorter
text has null characters to make the space used in the file
pairs the same.)

There is one block of other byte differences in each pair of
kernel files:

11234201 323  346 
11234202 233 <9B>  54 ,
11234203 305  371 
11234204 216 <8E> 144 d
11234205  30 ^X 147 g
11234206 230 <98> 176 ~
11234207  75 =3D   6 ^F
11234208 335 
 302 
11234209 144 d   5 ^E
11234210  73 ; 276 
11234211 305  162 r
11234212 146 f 266 
11234213  55 - 213 <8B>
11234214  61 1 212 <8A>
11234215   4 ^D  45 %
11234216 235 <9D> 145 e
11234217  20 ^P 133 [
11234218 141 a 231 <99>
11234219 203 <83>  47 '
11234220 211 <89> 216 <8E>

That is it for the differences.

> root@13R-ufs:~ # shutdown -r now
> . . .
> Performing sanity check on sshd configuration.
> Starting sshd.
> Starting cron.
> Starting background file system checks in 60 seconds.
>=20
> Wed Jul  6 04:22:01 UTC=20
> FreeBSD/arm64 (13R-ufs) (ttyu0)
>=20
> login: root
> Password:
> Jul  6 04:23:28 13R-ufs login[1210]: ROOT LOGIN (root) ON ttyu0
> Last login: Wed Jul  6 03:18:32 on ttyu0
> FreeBSD 13.1-RELEASE GENERIC
>=20
> Welcome to FreeBSD!
>=20
> Release Notes, Errata: https://www.FreeBSD.org/releases/
> Security Advisories:   https://www.FreeBSD.org/security/
> FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
> FreeBSD FAQ:           https://www.FreeBSD.org/faq/
> Questions List: =
https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
> FreeBSD Forums:        https://forums.FreeBSD.org/
>=20
> Documents installed with the system are in the =
/usr/local/share/doc/freebsd/
> directory, or can be installed later with:  pkg install en-freebsd-doc
> For other languages, replace "en" with a language code like de or fr.
>=20
> Show the version of FreeBSD installed:  freebsd-version ; uname -a
> Please include that output and any error messages when posting =
questions.
> Introduction to manual pages:  man man
> FreeBSD directory layout:      man hier
>=20
> To change this login announcement, see motd(5).
> root@13R-ufs:~ # uname -apKU
> FreeBSD 13R-ufs 13.1-RELEASE FreeBSD 13.1-RELEASE GENERIC arm64 =
aarch64 1301000 1301000
> root@13R-ufs:~ # freebsd-version -kru
> 13.1-RELEASE
> 13.1-RELEASE
> 13.1-RELEASE
> root@13R-ufs:~ # gpart show -pl
> =3D>       40  468862048    da0  GPT  (224G)
>         40      32728         - free -  (16M)
>      32768     524288  da0p1  13Refi  (256M)
>     557056   29360128  da0p2  13Rswp14  (14G)
>   29917184    4194304         - free -  (2.0G)
>   34111488   33554432  da0p3  13Rswp16  (16G)
>   67665920  356515840  da0p4  13Rufs  (170G)
>  424181760   44680328         - free -  (21G)
>=20
> root@13R-ufs:~ # gpart show -p
> =3D>       40  468862048    da0  GPT  (224G)
>         40      32728         - free -  (16M)
>      32768     524288  da0p1  efi  (256M)
>     557056   29360128  da0p2  freebsd-swap  (14G)
>   29917184    4194304         - free -  (2.0G)
>   34111488   33554432  da0p3  freebsd-swap  (16G)
>   67665920  356515840  da0p4  freebsd-ufs  (170G)
>  424181760   44680328         - free -  (21G)
> root@13R-ufs:~ # df -m
> Filesystem      1M-blocks Used  Avail Capacity  Mounted on
> /dev/gpt/13Rufs    168604 8159 146956     5%    /
> devfs                   0    0      0   100%    /dev
> /dev/gpt/13Refi       255   25    230    10%    /boot/efi
> root@13R-ufs:~ # ls -Tld /usr/obj/usr/src/arm64.aarch64/sys/*/
> drwxr-xr-x  3 root  wheel  91136 Jul  6 04:17:59 2022 =
/usr/obj/usr/src/arm64.aarch64/sys/GENERIC/
> root@13R-ufs:~ #=20
>=20
> The build and install seems to have worked just fine,
> allowing booting and operation.
>=20
>=20
> Notes:
>=20
> The builds were done via being logged in via ssh. The
> serial console causes more time to be taken waiting
> for the build output as it progresses, so I avoid
> it for builds.
>=20
> This media will be around for some time to possibly
> do other experiments with if desired. Provide
> explicit instructions if you want a build tried. The
> starting context would be as above but the instructions
> might say to "rm -fr" various things first, if
> appropriate.
>=20

Trying GENERIC-MMCCAM also worked just fine.
(but the context is set up as USB3 media based,
not microsd card based):

root@13R-ufs:~ # time make -j4 buildkernel   KERNCONF=3DGENERIC-MMCCAM # =
1794.69 real 6478.07 user 552.92 sys
root@13R-ufs:~ # time make -j4 installkernel KERNCONF=3DGENERIC-MMCCAM # =
   8.25 real   15.21 user  11.64 sys
root@13R-ufs:~ # shutdown -r now
. . .
Wed Jul  6 15:17:49 UTC=20
FreeBSD/arm64 (13R-ufs) (ttyu0)

login: root
Password:
Jul  6 15:18:35 13R-ufs login[1211]: ROOT LOGIN (root) ON ttyu0
Last login: Wed Jul  6 05:31:00 on ttyu0
FreeBSD 13.1-RELEASE GENERIC-MMCCAM
. . .
To change this login announcement, see motd(5).
root@13R-ufs:~ # uname -apKU
FreeBSD 13R-ufs 13.1-RELEASE FreeBSD 13.1-RELEASE GENERIC-MMCCAM arm64 =
aarch64 1301000 1301000
root@13R-ufs:~ #=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul  6 22:49:34 2022
X-Original-To: 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 BEE4F87D379
	for ; Wed,  6 Jul 2022 22:49:46 +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 4LdZVd4NHyz4jDZ
	for ; Wed,  6 Jul 2022 22:49:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657147778; bh=42zms7m4InBy5ezCdpUM7z8G6pGEcu4U0NrSLpknKNU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=lrlz6Lz3qZEcYznomacO7EeRyZ4r58s8rcVb44FNv7IhMQKF4FSuUXxCLE+FxDMPGo1b+63x6UXuVkozhr7/tzBcAohqTH8ApRUTar43YM2aCjhhq3L/RIulT8N/lVU7gTt/MQSQMhhIpYm7WTIuyIgxJerc3rTCbfpyIL6UzS7NgjPX58gCmbljwNhbJ7JOpVGGrfpFCEfR5Cvqi/NXwjzZPK7JmRdmtDDLdXj9f5atCI7v9b1nrH5TQ+iOnuSg3kJUn+8G69nN0SS6nLxw8hlBVtlacv/j6o9UOE/uHPUYbCJojKvjgXyQ098CHdG09Ni9FC1BUzlbw3esg/t9eQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657147778; bh=mluXx706IhU9MacOeOJmQZ8noycvM5aEeBtc0Mv9w7b=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=agvZGZZdclEs5U9Wd7KNTK4AylesACOmt9bT6WJihkO4qwiQOvO2fvgkm7CJDFf7ST5eVBxcNkpZsO7xIhOh6R4SgiCsXf3Z7wh8/crKArm7SeTI2C4Ma9l/q6Igmzx5AUGP7RJItYci2a8OEz7tbefF3ppNrUU32NNxKiaLO6bvLB7kiCD1TjcAekGJFu3Hq+9FrfMGcTDYIh1v02FC/xjbtFOCe9AbSDEPDBzdgFb7gwIfSoCyurZdQslJW9aZjTuXgjMTc40cREWHr5TSLF6/WYUL8EyF6HfxsmXmYQvCGs+uoxWtu/JKl1tiUDp8icEpicoMLqypGFLWRJ7LNA==
X-YMail-OSG: svJwxq8VM1kU1x68EQfG94_XCiukk9XaANoS1g6gqKaYI3KsT_.aXtY18rVLact
 0vp0Dfs7.8uC3q76nZZ4DZ_X7a7gz8SoMy17l0dB0LwPF8VKrDZq5DuiIyAavHeBvms92aRQDPfQ
 TOZdFHCJvwCcPtUPCjwrecUCkd_lIc_9p6egotJiveFSaV0YrdC9CZMMXH4KaipxbO4XRVdir97G
 c1AdZL4U4LHnV5GbXouZ.S3UckLncDSyeizbTpu6ZRKvCJN9LN8yCOd_H0Xye7ikscac854Zhjmy
 3uNFetuIABjcypwQCbwr14ltaVOx4VHI2r7GkkSevoLSH50jR.jz7cr66jNZvQTDfc2NcSYmdGa4
 6QpwsAbB5W7A29qEGJthWa54SNwdBiOD3cuUMMD87iKjUqtwhtPrnfSHxaLUE8AvB.4wvoIJp1RY
 piP23T5pikeY933JFBYrU864yBzCVER4iJIJgfl7Z1UbWDYZiBdz246aLb1qt4rYBG_9ZrMCt6it
 PsK_rnauzI3ojAnYxx2.pld4_fKhone2BCBmY4b7z2e_V6BAPSXixDz9mLBmW0dTqfzX.0Mu3kh.
 zS8IYsR9jIcnQcCNGUrsxOad6NyCDePxgb6iWomU299bv5BgJH4yTWWrVnDDb_o6qawhb.fmmIAS
 IvpqhIoi1PU799sJzufDImuQJQqUAByyGP5dvSzviUmzi87agfslMjhb14nai_DuUcf6J0PQ1YEA
 okADYfAN3bR58cyG4W6pLoufhNeMkkSLEOa6Kjwm2nWwCAih9Ve_Ez9Ot05ybR1L.eelwLI6UaZ0
 iUWQg947v977byE0Tc61qlaIKl2U_zRGrR_jO4BDs.EL.mE3SEFpBPYLP_Lq3rxNSQveCiViDL5V
 3AC4kQkI_HQrT1ZpsaB_Z4bbdXoSQjfjxf9DhOvsc2U5p70z6Ila.47X4JrwEed.dAhn61OvDHky
 9eVB5T0DPwCGh3gHucddAEmCvWPztRz3qVtlzoZAG8SNL.Eh4eihRUj.7lEcU4JM3dX9Sf4KKIQR
 NpGEXAVMbNX4pRJe.L7VZ9gFN6q1VVkta.D1JlWtUGjPf5jsM7Eo3S_J_IgHG.B0VOzrdSmtLVd5
 rbcF_vaoce.i0Bg5RB60LX26w0pbI2RF7r1atUChDfmI1hvO0TYToBzK1zLGg.Sr80HnxyxjFG1Q
 rLBiTVaAG_SZLBnJ_W2nDTvU0d0sEdCz4H1QIShRfpHSM7rCXtsn41Bw47ZbTdfJ85t2bOGqJSqr
 OgAI_PBAqE4wdNZL9dt4L9f1MKABCJtoBKFlEk9Zot0L5uios00OuGss.qPM6TJPfKbpGAlW4_5P
 6CLeU6vAMltlKkFLvp5.mw06LhvxbfbBvktUm3w7u6PYwMQAwTDnSTHQBc8tgotU7HauCqdzAaSW
 VPqVNPZBkGQ1iwA7BaM0WUKcNPybQCz633sLPdQ5b.TLWWJjwjSjH0nCUlyeO7B4h_wVWO9m6mmF
 czl.ppV4RvPTTjjl9lcV2WBvYcoBxJRN9AdECGSPjq0fbCa6AGAKM1dsJ_dwn2M9KGMJ1NjLoiaY
 KCorBx9uK4jGUJ6B3O0nB3I.02kH1NSw6DgWJev.VHA3QV.Wck_sBuaqNfq0EJjVtEZxzYpuWQ.8
 7o1H7CUmsuNkEwff38lCaAyFY7aw6fLQc9j3U4dSokoG4hMLNgg_Y5SQM5jwlNxTcSY89dljQcI_
 ap54iaIx4.QxR6Bp2BCzs5ihmtlNaXZi8v4BKt2mFfwDl80gWHx5AROKB0YV68SY6Dn5431HrzIU
 WS9k5kdzMKqxbo7pB5sTbLZgJqCAYD_x3mTgpEBQgF4kEJUm_OBxCmOtHplZF510.Nx5RDs2t9Sk
 mSWOxASXXQU9Ndo0OkEPzbUx9l_8zCrPNCMPRqjefHmzup30S.xkz6K5c9z49XqtjgSqdBqiy8Ty
 h59buHyadFz1wHotBShlFGC4WXIgLtb4ZabnlKLfQQ0T9WextShjQbczih5q8Ga42SMG6SWWJ02z
 im9yu2k2C6MMalFMp7h3UFIftwPXD0fDNdOIioYGEWmRpdoiD5tfKPUE5fJgU3d1OTGI57CJsL7K
 Ie0CApxtOKnH1iZ7IUYInlELM2IILUiFPlCooub48kqpcIuOAT0BBc7Ay90VlIpzYepUfpJSn2V7
 6BAG__.B_Wc_gRR1Aezs_wCg_MheSBUiZkB8cD_Oiq_dwCQwyTP9_3L.y50DLKUGKk_anj.UKUWD
 21OwTtTuWzrcdgYV4i7H9eJcRnCH7PPYLQeMMDlmZrdALazIwjNTW1GQcZb6bhZpZDpfdJP3xn2e
 qLL8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 22:49:38 +0000
Received: by hermes--production-ne1-7864dcfd54-dxcrc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 30fb5d1698e895f93294e968ee6bdfdb;
          Wed, 06 Jul 2022 22:49: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 14.0 \(3654.120.0.1.13\))
Subject: 3 more commits in main of changes to UFS/FFS superblock checks,
 possibly no longer rejecting your case
Message-Id: <0F86C637-D302-4236-929B-3AB030236BAF@yahoo.com>
Date: Wed, 6 Jul 2022 15:49:34 -0700
Cc: "freebsd-arm@freebsd.org" 
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <0F86C637-D302-4236-929B-3AB030236BAF.ref@yahoo.com>
X-Rspamd-Queue-Id: 4LdZVd4NHyz4jDZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lrlz6Lz3;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from];
	 MLMMJ_DEST(0.00)[arm];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Wed, 06 Jul 2022
	=E2=80=A2 git: f3f5368dfbef - main - Bug fix to UFS/FFS =
superblock integrity checks when reading a superblock. Kirk McKusick=20
	=E2=80=A2 git: 9e1f44d044a5 - main - Bug fix to UFS/FFS =
superblock integrity checks when reading a superblock. Kirk McKusick=20
	=E2=80=A2 git: 5bc926af9fd1 - main - Bug fix to UFS/FFS =
superblock integrity checks when reading a superblock. Kirk McKusick

One of the things changed is the test you have seen fail
that I recently replicated a failure via using just main
9aa02d5120a :

-	CHK(fs->fs_csaddr, !=3D, cgdmin(fs, 0), %jd);

It has been replaced with later code:

+	cgnum =3D dtog(fs, fs->fs_csaddr);
+	CHK(fs->fs_csaddr, <, cgdmin(fs, cgnum), %jd);

So there is a chance that the rejected file systems
will no longer be rejected.

I've got other builds going on and will will be a while
before I can update to have this material involved to
test it.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Jul  7 09:30:20 2022
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 891AC10F90F6;
	Thu,  7 Jul 2022 09:30:29 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ldrjw0VlKz56j5;
	Thu,  7 Jul 2022 09:30:27 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=ZUYlyrXG7EUqmzxgHbbFDNwEBYbTFdztQUFVSpcji9I=; b=HfwVADl+ur5WD4uQ/KRzFZ8a8L
	EdjE2dCCN7ghOyZOYeBDrW4LrJoIGD3+JTPICbDdxl2zbpoVbEcm2KCjYiWcwOxkP2C6jfv2Y0ZQt
	GR8kBB8hjtfmZYOGnG/k0hkiC3V7tzQOYxK3n2+ZTYv4IEA4CjNZ3nGUo36kzy7j6BhI=;
Message-ID: <1d44f820-da80-8a65-ec5f-35632a7dd971@klop.ws>
Date: Thu, 7 Jul 2022 11:30:20 +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:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: set timestamp from ZFS-root - (was: Re: RPI4 + ntpdate + unbound)
Content-Language: en-US
To: freebsd-arm@freebsd.org, freebsd-fs@freebsd.org
References: 
 
From: Ronald Klop 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: /
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: c74461a82029b6293650421ecb57b64a
X-Rspamd-Queue-Id: 4Ldrjw0VlKz56j5
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=HfwVADl+;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-1.00 / 15.00];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-arm,freebsd-fs];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[klop.ws:+];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/6/22 11:47, Peter Jeremy wrote:
> On 2022-Jul-01 21:02:05 -0700, John Kennedy  wrote:
>>   So I've got a RPI4 (no system time stored in NVRAM) that I did a stock
>> type FreeBSD install on setting the time with ntpdate and the unbound
>> DNS server (aiming for DNSSEC).  As many people have noted before me,
>> that setup is sort of broken because you can't look up DNSSEC hosts if
>> you think it's 1970.  No NTP time servers == no date reset == no DNS.
> 
> If you're running UFS, the system clock should get set to the timestamp
> in the superblock.   That will be the last sync before the previous
> shutdown so it'll be minutes to hours out of date but that should be
> recent enough for DNSSEC to work.
> 
> Note that this only works on UFS - see
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254058
> 
> As an alternative option, the RTC in both the Rock64 and RockPro64
> are supported.
> 


This is a nifty feature I did not know about. Cc-ing freebsd-fs@ to try get some attention on this.
Is it possible to implement this on ZFS?

Ronald.

From nobody Thu Jul  7 10:40:14 2022
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 B76423E34BD
	for ; Thu,  7 Jul 2022 10:40:45 +0000 (UTC)
	(envelope-from bproffit@amaranth.digital)
Received: from mail.amaranth.digital (mail.amaranth.digital [66.23.237.42])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LdtGz4mVZz3RTv
	for ; Thu,  7 Jul 2022 10:40:43 +0000 (UTC)
	(envelope-from bproffit@amaranth.digital)
Received: from [192.168.1.47] (unknown [73.83.240.71])
	by mail.amaranth.digital (Postfix) with ESMTPSA id 29F70F9E45;
	Wed,  6 Jul 2022 23:42:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=amaranth.digital;
	s=amaranth; t=1657165338;
	bh=t+hVszL3XiN2mkenIEs0Q9KLoMW4RHHj3p9sJXs7ecc=;
	h=Date:Subject:From:To:References:In-Reply-To;
	b=YscWxhXU3pAK5NqNU0tMfaRIhgoAMGvFx31wl6o93xPUDJC/zEQKeTI+ftfbD1HqO
	 41FZoBdhQboPd6uhVLfqPN1NUkh3WLFbPg07UdscGiBbFC1XWZAitSfhfsiU6h8r4Q
	 o5abjaob/y2B4frjvi4drJ/Tb5Q28QMLe85lfb/kQeol2TUC+aH8bp3Yu6HolQfoN/
	 X3n090q5M62h9GizdfOoXWmpyQPI3Srf9BLpkFL1BzsQhxCSsLsj3ifPD7zx8EWivF
	 jdSRP0YaFug8OWGyIJNyGpUeR0hQwVZtgbYh+mfwcAv4Xkry5eq1y6uTB2wYMulSGI
	 rP1OBj0SIRpZg==
Content-Type: multipart/alternative;
 boundary="------------ZgxhFWtfVGAMAFdukIcJ3pSt"
Message-ID: <9c50da19-a0ae-7865-7d27-7f40727ec1ee@amaranth.digital>
Date: Thu, 7 Jul 2022 03:40:14 -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
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: U-Boot fails to load from SD when a USB dual HDD device is
 attached
Content-Language: en-US
From: Bradley Proffit 
To: Mark Millard , maciphone2@googlemail.com,
 warlock@phouka.net, freebsd-arm@freebsd.org
References: <12609da5-c560-f336-762f-32fc5fa71d48@amaranth.digital>
 
 
 <17F5F696-A1D2-4952-9163-BF7D185B8A27@yahoo.com>
 <6494efb2-6eae-b297-a0f2-ebef158b3b23@amaranth.digital>
In-Reply-To: <6494efb2-6eae-b297-a0f2-ebef158b3b23@amaranth.digital>
X-Spam-Status: No, score=-2.8 required=10.0 tests=DATE_IN_FUTURE_06_12,
	HTML_MESSAGE,NICE_REPLY_A,RCVD_IN_DNSWL_HI,RCVD_IN_ZEN_BLOCKED_OPENDNS,
	RDNS_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED,
	URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham
	autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on
	mail.amaranth.digital
X-Rspamd-Queue-Id: 4LdtGz4mVZz3RTv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amaranth.digital header.s=amaranth header.b=YscWxhXU;
	dmarc=pass (policy=none) header.from=amaranth.digital;
	spf=pass (mx1.freebsd.org: domain of bproffit@amaranth.digital designates 66.23.237.42 as permitted sender) smtp.mailfrom=bproffit@amaranth.digital
X-Spamd-Result: default: False [-1.09 / 15.00];
	DMARC_POLICY_ALLOW(-0.50)[amaranth.digital,none];
	R_SPF_ALLOW(-0.20)[+a:mail.amaranth.digital];
	R_DKIM_ALLOW(-0.20)[amaranth.digital:s=amaranth];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	NEURAL_HAM_SHORT(-0.09)[-0.090];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FREEMAIL_TO(0.00)[yahoo.com,googlemail.com,phouka.net,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:19318, ipnet:66.23.224.0/20, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[amaranth.digital:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RECEIVED_SPAMHAUS_PBL(0.00)[73.83.240.71:received]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------ZgxhFWtfVGAMAFdukIcJ3pSt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Update:

While the bug in question is not a FreeBSD-specific issue, I figured 
that I would share this update for anyone who might benefit.

I have built U-Boot from the ports tree (sysutils/u-boot-rpi4) with the 
following changes:

files/rpi4_fragment:

  * *CONFIG_USB=n*
  * *CONFIG_USB_HOST=n*
  * *CONFIG_USB_STORAGE=n*
  * *CONFIG_USB_XHCI_PCI=n*
  * *CONFIG_USB_XHCI_HCD=n**
    *
  * *CONFIG_CMD_USB=n*

U-Boot gives an error message regarding the unavailable 'usb' command 
since it's been disabled and I didn't remove a reference to it from the 
startup script, but it booted up anyway.

This workaround prevents the bug (if you don't use a USB boot device) 
while I wait for some feedback from the U-Boot project maintainers.

On 6/29/22 22:17, Bradley Proffit wrote:
> Thanks for the pointers, everyone.
>
> I confirmed that this particular USB device, being self-powered, is 
> not pulling a current on the pi's USB port. I think this rules out a 
> voltage problem.
>
> The U-Boot interactive shell still shows the MMC device, but refuses 
> to boot from it under these conditions. The one-liner workaround you 
> mentioned is unfortunately not resolving this problem.
>
> Until I can find time to try fixing the bug, I am building U-Boot 
> without support for USB storage devices and network booting, since I 
> don't need those features at this time. I'll let you know if that works.
>
>
> Bradley
>
> On 6/29/22 9:29 AM, Mark Millard wrote:
>> On 2022-Jun-29, at 07:35, Klaus Küchemann  
>> wrote:
>>
>>> On 2022-Jun-29, at 02:06, Bradley Proffit 
>>>  wrote:
>>>
>>>> I'm running FreeBSD 13.1 on the Raspberry Pi 4B, with a new dual 
>>>> SATA-to-USB hard drive docking station, and I've noticed a peculiar 
>>>> situation: U-Boot fails to load FreeBSD from the SD card when the 
>>>> docking station is plugged in and has two hard drives in it 
>>>> (presenting two USB storage devices to U-Boot), but still succeeds 
>>>> when:  …………...
>>>
>>>
>>>> Am 29.06.2022 um 16:09 schrieb Mark Millard :
>>>>
>>>>
>>>> See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441
>>>>
>>>> The problem is not limited or specific to FreeBSD's use of
>>>> U-Boot. For example, demonstrated with Fedora 33 and some
>>>> openbsd version as well. The problem is not new.
>>>>
>>>> . . .
>>>
>>> didn`t we workaround a similar issue ? :
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983#c59
>> I forgot to look up and reference:
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983
>>
>> as well. I should have listed both, for sure.
>>
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
Bradley Proffit
amaranth.digital

--------------ZgxhFWtfVGAMAFdukIcJ3pSt
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Update:

    
While the bug in question is not a FreeBSD-specific issue, I
      figured that I would share this update for anyone who might
      benefit.

    

    
I have built U-Boot from the ports tree (sysutils/u-boot-rpi4)
      with the following changes:

    
files/rpi4_fragment:

    
    
      
  • CONFIG_USB=n
    • 
      
  • CONFIG_USB_HOST=n
    • 
      
  • CONFIG_USB_STORAGE=n
    • 
      
  • CONFIG_USB_XHCI_PCI=n
    • 
      
  • CONFIG_USB_XHCI_HCD=n
    
          
    • 
      
  • CONFIG_CMD_USB=n
    • 
    

    
U-Boot gives an error message regarding the unavailable 'usb'
      command since it's been disabled and I didn't remove a reference
      to it from the startup script, but it booted up anyway.

    
This workaround prevents the bug (if you don't use a USB boot
      device) while I wait for some feedback from the U-Boot project
      maintainers.

    
On 6/29/22 22:17, Bradley Proffit
      wrote:

    

    
Thanks
      for the pointers, everyone.
      

      

      I confirmed that this particular USB device, being self-powered,
      is not pulling a current on the pi's USB port. I think this rules
      out a voltage problem.
      

      

      The U-Boot interactive shell still shows the MMC device, but
      refuses to boot from it under these conditions. The one-liner
      workaround you mentioned is unfortunately not resolving this
      problem.
      

      

      Until I can find time to try fixing the bug, I am building U-Boot
      without support for USB storage devices and network booting, since
      I don't need those features at this time. I'll let you know if
      that works.
      

      

      

      Bradley
      

      

      On 6/29/22 9:29 AM, Mark Millard wrote:
      

      
On 2022-Jun-29, at 07:35, Klaus Küchemann
        <maciphone2@googlemail.com> wrote:
        

        

        
On 2022-Jun-29, at 02:06, Bradley
          Proffit <bproffit@amaranth.digital> wrote:
          

          

          
I'm running FreeBSD 13.1 on the
            Raspberry Pi 4B, with a new dual SATA-to-USB hard drive
            docking station, and I've noticed a peculiar situation:
            U-Boot fails to load FreeBSD from the SD card when the
            docking station is plugged in and has two hard drives in it
            (presenting two USB storage devices to U-Boot), but still
            succeeds when:  …………...
            

          

          

          

          
Am 29.06.2022 um 16:09 schrieb Mark
            Millard <marklmi@yahoo.com>:
            

            

            

            See:
            https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441
            

            

            The problem is not limited or specific to FreeBSD's use of
            

            U-Boot. For example, demonstrated with Fedora 33 and some
            

            openbsd version as well. The problem is not new.
            

            

            . . .
            

          

          

          didn`t we workaround a similar issue ? :
          

          

          https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983#c59
          

        

        I forgot to look up and reference:
        

        

        https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983
        

        

        as well. I should have listed both, for sure.
        

        

        ===
        

        Mark Millard
        

        marklmi at yahoo.com
        

        

      

    

    
Bradley Proffit
amaranth.digital


  


--------------ZgxhFWtfVGAMAFdukIcJ3pSt--

From nobody Thu Jul  7 10:56:05 2022
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 DAD6B3E58CC
	for ; Thu,  7 Jul 2022 10:56:25 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ldtd45pjHz3Sx0
	for ; Thu,  7 Jul 2022 10:56:24 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID
	:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=7/UMzCwNbviXhBFbKU+pftaFTBDyeNThEtQ3fGL2Slc=; b=X5kSRRKEF9pR3gCSgAQMlu3KDv
	+VbWNMBDRpZfmZYGLioBwSzN832hIZV478hDNkkwjTDSbTBrYfidIcqsjTz/Omrywb61gDeAqEVfT
	4+2K3MJDxTEAkWLgTEyk4Ldq/stY8Zip19fASIj+n+SQiXWr+1tkP1hE7Lep38RSb58Q=;
Content-Type: multipart/mixed; boundary="------------Ma2upRyPPGUQimYRM1PCa798"
Message-ID: 
Date: Thu, 7 Jul 2022 12:56:05 +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:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: RPI4 + ntpdate + unbound
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 
From: Ronald Klop 
In-Reply-To: 
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: /
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2
X-Scan-Signature: 4cc6a862e0a753e674eb374334b394fd
X-Rspamd-Queue-Id: 4Ldtd45pjHz3Sx0
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=X5kSRRKE;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [0.94 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_SPAM_SHORT(0.84)[0.839];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	HAS_ATTACHMENT(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------Ma2upRyPPGUQimYRM1PCa798
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/6/22 11:47, Peter Jeremy wrote:
> On 2022-Jul-01 21:02:05 -0700, John Kennedy  wrote:
>>   So I've got a RPI4 (no system time stored in NVRAM) that I did a stock
>> type FreeBSD install on setting the time with ntpdate and the unbound
>> DNS server (aiming for DNSSEC).  As many people have noted before me,
>> that setup is sort of broken because you can't look up DNSSEC hosts if
>> you think it's 1970.  No NTP time servers == no date reset == no DNS.
> 
> If you're running UFS, the system clock should get set to the timestamp
> in the superblock.   That will be the last sync before the previous
> shutdown so it'll be minutes to hours out of date but that should be
> recent enough for DNSSEC to work.
> 
> Note that this only works on UFS - see
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254058
> 
> As an alternative option, the RTC in both the Rock64 and RockPro64
> are supported.
> 


Based on this idea I created a /etc/rc.d/fakertc script. It saves the datetime on shutdown and restores it early on boot.

Not polished yet. But it works on my RPI4 14-CURRENT.
With this script the time does not go backwards in the logs anymore. And it should provide a more reasonable time for validating certificates in DNSSEC/ipsec or similar processes before ntpdate kicks in.

Regards,
Ronald.

--------------Ma2upRyPPGUQimYRM1PCa798
Content-Type: text/plain; charset=UTF-8; name="fakertc"
Content-Disposition: attachment; filename="fakertc"
Content-Transfer-Encoding: base64

IyEvYmluL3NoCiMKCiMgUFJPVklERTogcnRjCiMgUkVRVUlSRTogRklMRVNZU1RFTVMKIyBC
RUZPUkU6IG5ldGlmCiMgS0VZV09SRDogbm9qYWlsIHNodXRkb3duCgouIC9ldGMvcmMuc3Vi
cgoKbmFtZT0iZmFrZXJ0YyIKZGVzYz0iUmVzdG9yZSBSVEMgZGF0ZSBhbmQgdGltZSIKc3Rh
cnRfY21kPSJmYWtlcnRjX3N0YXJ0IgpzdG9wX2NtZD0iZmFrZXJ0Y19zdG9wIgoKZXh0cmFf
Y29tbWFuZHM9InNhdmVydGMiCnNhdmVydGNfY21kPSIke25hbWV9X3N0b3AiCgpydGNfZmls
ZT0iL3Zhci9kYi8ke25hbWV9IgoKcnRjX2Zvcm1hdD0iKyVZJW0lZCVIJU0uJVMiCgpzYXZl
X3J0YygpCnsKCW91bWFzaz1gdW1hc2tgCgl1bWFzayAwNzcKCWRlYnVnICJzYXZpbmcgcnRj
IHRvICR7cnRjX2ZpbGV9IgoJZGF0ZSAtSXNlY29uZHMgPiAiJHtydGNfZmlsZX0iCgl1bWFz
ayAke291bWFza30KfQoKZmFrZXJ0Y19zdGFydCgpCnsKCgllY2hvIC1uICJTZXQgUlRDIGZy
b206ICR7cnRjX2ZpbGV9OiAiCgoJaWYgWyAhIC1yICR7cnRjX2ZpbGV9IF0gOyB0aGVuCgkJ
d2FybiAiJHtydGNfZmlsZX0gaXMgbm90IHJlYWRhYmxlIgoJCXJldHVybiAxCglmaQoKCWNh
c2UgJHtydGNfZmlsZTo9LyR7bmFtZX19IGluCglbTm5dW09vXSkKCQk7OwoJKikKCQlkYXRl
IC11ICQoIGNhdCAiJHtydGNfZmlsZX0iICkKCQk7OwoJZXNhYwoKCWVjaG8gJy4nCn0KCmZh
a2VydGNfc3RvcCgpCnsKCSMgV3JpdGUgc29tZSBlbnRyb3B5IHNvIHdoZW4gdGhlIG1hY2hp
bmUgcmVib290cyAvZGV2L3JhbmRvbQoJIyBjYW4gYmUgcmVzZWVkZWQKCSMKCWNhc2UgJHty
dGNfZmlsZTo9LyR7bmFtZX19IGluCglbTm5dW09vXSkKCQk7OwoJKikKCQllY2hvIC1uICJX
cml0aW5nIFJUQyBmaWxlOiAke3J0Y19maWxlfSIKCQlvdW1hc2s9YHVtYXNrYAoJCXVtYXNr
IDA3NwoJCWRhdGUgLXUgIiR7cnRjX2Zvcm1hdH0iID4gIiR7cnRjX2ZpbGV9IiB8fCB3YXJu
ICd3cml0ZSBmYWlsZWQgKHJlYWQtb25seSBmcz8pJwoJCXVtYXNrICR7b3VtYXNrfQoJCWVj
aG8gJy4nCgkJOzsKCWVzYWMKfQoKbG9hZF9yY19jb25maWcgJG5hbWUKcnVuX3JjX2NvbW1h
bmQgIiQxIgo=

--------------Ma2upRyPPGUQimYRM1PCa798--

From nobody Fri Jul  8 05:45:42 2022
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 D914D12ADD9E
	for ; Fri,  8 Jul 2022 05:46:40 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfMj95MWHz3XGT
	for ; Fri,  8 Jul 2022 05:46:37 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 2685jvq1042417
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Fri, 8 Jul 2022 15:16:01 +0930 (ACST)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1657259165;
	bh=7WtV9HsRvZvlvlX9ZOuT2TVyPYAIJJ8IBZGEoGmrgIk=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=gYSChVT7VGPdD4/+kvP6ur6PY2rM+gH1l/NJKKaWxVbtTTKuM2q5hrNA4si7+1Qwv
	 wfltgEbEVF6O6jxmEOvDr7MDU8Ot8S7Pl9sGHURBb7/C8wT5+RNWG8334sdX8iJ/cp
	 0o/t8Pj9RDcFmnfe7Du0//DwtqXUZqWOp8MGapTw=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 2685jo5C042414
	for ; Fri, 8 Jul 2022 15:15:50 +0930 (ACST)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:2505:d015:d36b:ade7
Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:2505:d015:d36b:ade7] [2403:5800:5200:4700:2505:d015:d36b:ade7])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 2685jojP042403; Fri, 08 Jul 2022 15:15:50 +0930
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 \(3696.100.31\))
Subject: Re: RPI4 + ntpdate + unbound
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Fri, 8 Jul 2022 15:15:42 +0930
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FBD6A2A-0A20-4DDA-A4D6-4D1DA8C469AF@dons.net.au>
References: 
To: John Kennedy 
X-Mailer: Apple Mail (2.3696.100.31)
X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-Rspamd-Queue-Id: 4LfMj95MWHz3XGT
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=gYSChVT7;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-1.50 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[dons.net.au:+];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 2 Jul 2022, at 13:32, John Kennedy  wrote:
>  So I've got a RPI4 (no system time stored in NVRAM) that I did a =
stock
> type FreeBSD install on setting the time with ntpdate and the unbound
> DNS server (aiming for DNSSEC).  As many people have noted before me,
> that setup is sort of broken because you can't look up DNSSEC hosts if
> you think it's 1970.  No NTP time servers =3D=3D no date reset =3D=3D =
no DNS.

If you are interested in a hardware solution you can add an RTC to an =
RPI4 quite cheaply.

For example: =
https://core-electronics.com.au/ds1307-rtc-module-with-battery-for-raspber=
ry-pi.html

I needed the trick from this thread to get it working though:
https://lists.freebsd.org/pipermail/freebsd-arm/2021-May/023713.html

I also needed a dtso based on this: =
https://github.com/seiyo/freebsd-rpi-b-ds1307/blob/main/ds1307.dtso
(Also changed brcm,bcm2708 to brcm,bcm2385)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum


From nobody Fri Jul  8 14:24:35 2022
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 407BA17D09E4
	for ; Fri,  8 Jul 2022 14:26:09 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfbDb3yKlz3lZl
	for ; Fri,  8 Jul 2022 14:26:07 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 268EOape098556
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 07:24:36 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 268EOaDE098555;
	Fri, 8 Jul 2022 07:24:36 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 8 Jul 2022 07:24:35 -0700
From: John Kennedy 
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
Subject: Re: RPI4 + ntpdate + unbound
Message-ID: 
References: 
 
 
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: 4LfbDb3yKlz3lZl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[phouka.net];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 12:56:05PM +0200, Ronald Klop wrote:
> Based on this idea I created a /etc/rc.d/fakertc script. It saves the datetime on shutdown and restores it early on boot.
> 
> Not polished yet. But it works on my RPI4 14-CURRENT.
> With this script the time does not go backwards in the logs anymore. And it should provide a more reasonable time for validating certificates in DNSSEC/ipsec or similar processes before ntpdate kicks in.

  None of these is perfect, but it does stop the clock from rolling
backwards and doesn't require a network.  It should solve the issue with
DNSSEC (since even days shouldn't matter for cert validity with enough
servers).  I'm not sure if ntpd will be happy (does the --force-step-once
work if you boot up, don't have a network for a chunk of time, then regain
network?).


From nobody Fri Jul  8 15:20:16 2022
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 1096917F9518
	for ; Fri,  8 Jul 2022 15:20:25 +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 4LfcRD1m4bz3rxB
	for ; Fri,  8 Jul 2022 15:20:24 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 268FKGY6024417
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 08:20:17 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 268FKGFQ024416;
	Fri, 8 Jul 2022 08:20:16 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 8 Jul 2022 08:20:16 -0700
From: bob prohaska 
To: Kirk McKusick 
Cc: Mark Millard , freebsd-arm@freebsd.org
Subject: Re: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
Message-ID: <20220708152016.GA24395@www.zefox.net>
References: <20220707012258.GA13599@www.zefox.net>
 <202207070319.2673Jo74005673@chez.mckusick.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: <202207070319.2673Jo74005673@chez.mckusick.com>
X-Rspamd-Queue-Id: 4LfcRD1m4bz3rxB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	SUBJECT_HAS_EXCLAIM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Jul 06, 2022 at 08:19:50PM -0700, Kirk McKusick wrote:
> >> 
> > Compiling now. Should know by morning.
> > 
> 
> Keep me posted. Thanks for your testing help.
> 

Looks like it worked. 

FreeBSD 14.0-CURRENT #5 main-n256584-5bc926af9fd: Fri Jul  8 05:16:34 PDT 2022

came up hands-off.

Many thanks to you and Mark!

bob prohaska


From nobody Fri Jul  8 17:40:23 2022
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 6074F12ADF39
	for ; Fri,  8 Jul 2022 17:40:27 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2045.outbound.protection.outlook.com [40.107.89.45])
	(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 4LfgXp1lXVz46v2
	for ; Fri,  8 Jul 2022 17:40:26 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=XthAuweakIMtsRL/JWkNWtrPL2WCNIaWHVpSK9VhWZttet/k0HTyYJimpJer03DowXDr+ftv9FDjJYxy9IRWQVZpI6un9q9aiYEJlLxvBNkLVOfyuLWkyOC28vDo9WYrKNioF+7/RuWXqb6SK2dMknDLBuKLc6BHAOPLvUVYpr2rSR0SE9meoLLIL4vc2AN6NFbcLscJuf/THoFXuWmAHR1WxdpPfCfYEaTHLQGaOLZZUHDiNmMo5JwX/phXQlFQ0Xyq3/iYMGZdHEfuBxROmnKMz7V88NKTFbzOMen1a4YSkTvtiAyREMD9hDBAjpFgPu8TxCxQxxnSVkhejOXy1g==
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=IpiSX1pv+58BajKhKf4aGW78d8D/FM5Z3zC6z5TUR+c=;
 b=auj8ijeNZIE/F3uUvaGdca9rvhoArx838He+vbSgctcFV3sp6QdnaW0nGMrrcQfOxuqG3iJgU7eLvQ9xMJ7jEfKH9ZHW8nOgW6A6yNYj2HER3zWQoK/9FQ+JEgvF6YNEdNa/jPr86Wt4MtySlvgxdPiNjB77iWwKdbkt6tCr65Q5ps6j3rPzV9RxF73iUPg3gu1ZYKZ7XeceiNNZQyQnipAijkdevgMSBTgtLh6DcxocW63taxe1lxbsA95l9b/4ZdikYbDkKjsfHg7Gi4Cp2gaxBfdM0Q+jOsjLy1MW1OPDWUnRzB9HPvTc7OT4K/y/Sw6SWbRFiOzjYOSNshmQRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IpiSX1pv+58BajKhKf4aGW78d8D/FM5Z3zC6z5TUR+c=;
 b=iecBLwWR5STuVD/WVxUE3OrvXJpfNVP4NCw68LLwkmulNZ7pIevzsx8p6nQfreisRul/E0mkoe2V+CRKz1QdBJWvMgHuKMsGObLlAKCrUyg5T723CW1piU4TyubEG9d84mOiR2RUgDrwo9W/RzPZVOHFXhweqjAxRoErypaOFGu5rQjRrbl9An1g4qyjPIbyTv5uWB0zYXkYUNicPuBb551U+JHF4scax6r5kn7bFuax+9ib0/fNVf4FbCxcjI1pseiMdTHPiQVLQGQMsihFlS940XVz7iqjfTJ+RB/8uTt6OPDZRPkZKd6g7ALoDWLgY+iXMhANop+mBE6PIH1xXw==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by MN2PR09MB4954.namprd09.prod.outlook.com (2603:10b6:208:220::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.15; Fri, 8 Jul
 2022 17:40:23 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474%7]) with mapi id 15.20.5395.021; Fri, 8 Jul 2022
 17:40:23 +0000
From: "Wall, Stephen" 
To: "freebsd-arm@freebsd.org" 
Subject: Installing 13.1 ARM on SSD
Thread-Topic: Installing 13.1 ARM on SSD
Thread-Index: AdiS8ERGKwQPlDhfQrOEvtCOXYsV4Q==
Date: Fri, 8 Jul 2022 17:40:23 +0000
Message-ID:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 23a2ef5e-60ff-491e-f13a-08da6108efa6
x-ms-traffictypediagnostic: MN2PR09MB4954:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 u85ILoe2AGMjSmmTh8cTCteSqb+YqeChMhgtcVcMvA+AZXVqxbrvDx8OK5ZT84C8eST6BNbCKttDatvFix/2ZJyXYEeSvgBRgYZjMGEpQzCiyhXgpaQyLrvhlFsKfuojyQkwNgKTkpAEvhLpPMBsAXSMZ3Vhnsc7hYCzu5wjt4rT2YhJD4GTS2esXv7fuoLU9/jx2ysMjSH/f2fgEUWh3NeXf3ptqmGkNBZ88fJk4Et9IFrFNRAUhoTi/KsDZEvB0K9Ciejw3Q8zHl6gMSud4VebfLBZ8RwKe6LkVkeEE+E/dLKj4ZIZARDQ1x9ji6gkIKZJz0gc3boqFFZicl2JRCzYkMRXS+Y4QqCRkn4Ru9c14JPGJOiyKPD6Ojz1XMsSnNNGvAqCQtTS5QwMO1TP3ZlLy9189nofaXUQbywoX7bMgqE9Re6gloFO1GgXkCiSfLj7YvypYJbm/t+suVnwnfrnbWg8/kmQxb9sEy2ugqSagqBCeU64zGMs1V6S3mudzpwRkvcPD4YkBKJc83DC4pipdV0ByozK4jSwIUC+Ns2icODvGCCcgIuRZdzSYScthtQ4LDIhBwpdHa2DSN+nkqILANeUyK3ObAMItvbYa3s4ARJf31lT9w7tjPtSi81qLBhMuQFeh9RfKlstLai79vv67A6PXNNYxylyaHqj6wymG/mqeEW/ehP45PMpBOknkx0XaYIVS6RQ/Pxf7pjGlo3NxAHQq6PHhLkPW6klKt1ufH+KGOjf2gBOHBpnAuzSP9Lk9mAkQvbT8V0/zKP+9+IoqkEpk+4B/lEHvq1EhhnHzhIkwGEn/8olP6g+QtrqBb42jGO8M27xzrf4jRmrGw==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(136003)(366004)(396003)(39830400003)(71200400001)(66476007)(64756008)(83380400001)(122000001)(8676002)(66946007)(5660300002)(66446008)(86362001)(41320700001)(52536014)(40140700001)(66556008)(186003)(4744005)(33656002)(166002)(38070700005)(8936002)(26005)(99936003)(9686003)(38100700002)(41300700001)(6506007)(508600001)(7696005)(2906002)(6916009)(55016003)(76116006);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?VFVTeFpheE9wZThSUzBOQzE3UkgwV0JqU29xVGVLZDJVVnFaQU1aOFlmN1BF?=
 =?utf-8?B?SFd6enBBWXpBSDFQbHJKYysyWTg4emJrMzkxRG1rTWt5clRYOFB2UDNlN2E0?=
 =?utf-8?B?aEs4RGVQb2VVdk95VkpCVXRwRnVTdTlMcG5WRDNYb213dUlGOHhXWjhndHJz?=
 =?utf-8?B?a0pVQWt0ZUE1cHJCNEZSTUYxN2NOOUVJSUk4dlVCcDg2czBNeUFLY0RYSzhQ?=
 =?utf-8?B?RXJFWW5IbWFEeHhQZHpvalJ3OWIyR3FUNk1vZmgrSUNwcUtLbFlEcGtZZTdk?=
 =?utf-8?B?Z3VmV3RmeURjSUlGMFBLTkZYdjFqWlNnYWZic3hzd3dBRHU5ZzlJWEpybFho?=
 =?utf-8?B?WE9lRmpGZDlaWkpmTTE1K20zMnhnVG5rcTVQUWpNYUc5KzBrSlV2WmN0L0VH?=
 =?utf-8?B?OFFLdTIyMVpqQmtGNlhSbHhPWTZYQXFjRnVQVEpxRTJZVDdFQnhNK09ubVBB?=
 =?utf-8?B?aHhiZnZ5ZzdXeFQyRGtOWVNmRWFZVUdLa3hGRVEraFJWNFlmenJMTWdjQlp2?=
 =?utf-8?B?Um42MlpVbW1BWUxrOCtxaEp1aHMvYWg1V2NKU3JXVG93QWRsQU14ZXpTYzhH?=
 =?utf-8?B?dm9aZ1BPRjhOOHBBTXNjclkxU1o4OEZHMnNCZTN5bTB1bitNTGhvMkZjTzZw?=
 =?utf-8?B?b1plR1grMmlOdVN0ckRhNzB4KzlYWSs4MFRhQ3NwR1RCcHJqSjdtNWxVc1Jw?=
 =?utf-8?B?Mjk4RlluRDhLeE9NdjVlYW9vK3ZaMGRWbXBtZVJUMlZiME0ydmRtWHZ0a2Fr?=
 =?utf-8?B?U1hSU2xBQ0wya1FheHp3QmptMU9vaWNscU9sVE43THJ1MWtJNFNKdElUY0Jq?=
 =?utf-8?B?QlVmQVJJWjN5TEZ3NCtUMndBSjMwVjY2TnRzUFNQSGdNdTF4TTRjTDJ2RTB6?=
 =?utf-8?B?TWpWZjlJM2ZBTnlkNDVlcTVOS0Q1ckFmUXMrQytzTlRxcDdlNnNXa21RcS9s?=
 =?utf-8?B?VFR2WnVQYzRNLzZrdjlxTWNxTk9hZEwxb3dzTGcvZm1xZFl3a2pqNElNVW15?=
 =?utf-8?B?ZjRvUjZuY21nUnpGM3ZuREdzd2ZPaWdwUmhyK3FBcG4wL2Y4WHlNU2dMcWx0?=
 =?utf-8?B?KzZCSEc3N3oyUXg1TUNxR2FtL3YxMHhueVFNc004akNyRXp0cjE4TW04d3Fj?=
 =?utf-8?B?T3ZQU2lWMVlrMWt5dUJPNGh4NUxPNXNJQnVlUUpXZkNtYkw5MmNFeTJEak9B?=
 =?utf-8?B?enU3VEZLYmF1Ym1SK0QySlVlSHZuLzJsTys5L0loME5rcmVoWmZNZ3NGN293?=
 =?utf-8?B?alFkWmpPOFpFbVB5Y0VnRHZSV1ZNWUs4L3dTTldWOGxCQ3R6TGZaWUxJYUti?=
 =?utf-8?B?N1RySXI0a3N0eVZUb2FXb2hjTDBvd3prZnY5c1BYeHNBcWhwT2picmRRL2hy?=
 =?utf-8?B?MjNrbkdXSHl1eFJnRE92U1pvaGthZmx6VnpRSVpZbFZvejgrUVByVkw3Nk41?=
 =?utf-8?B?T1FpcDUxbmNHNzIxa2xWOHhZendvZTNaU3RaL3ptUmFESGVmN0tZTXljQzg3?=
 =?utf-8?B?Y2NGVXJNTndEZCtUTCtPdmE5UUdTSDdJTVh0UXptOHhmVjNtZ01ya1JRSSs0?=
 =?utf-8?B?ZURSV1FSbkpDRjJVMEJmR0hoeHdQWXNLenRCRk5zcTRBN0JleGtlb2c0S2Vk?=
 =?utf-8?B?QXJQQW42ZWJsVmwzRXdwZ2VvOFB4QndKT0R4WTFKTTJxZmJxU3o4bnpGaFBW?=
 =?utf-8?B?UVp1Umh6N2YycjNKNmpBbzVqTHdQVit5b0dYdGIyblhoNXdHaHMzazRWYmUv?=
 =?utf-8?B?TWlaa3BDTDFrMUE0dDlzMDFaZFFya1IySEZmU2tPRGd2RGVCcHJIak1yaWtQ?=
 =?utf-8?B?YzFFcmxzb2J3QXA5bmR2dTlkNmJReXA1MStqT00yNDljTUs4MmdudnhaOWFa?=
 =?utf-8?B?dUlhYVdIVU51aFB3cFU3T001WlF5eU5DWVFNTmtsVWJiNlZYOGcyM2JiQlo3?=
 =?utf-8?B?bldVUW5sK1lXdnEwTDhCNW9Hcm1RbFVEQ0VLQkdlNzdMUENHTGhicXNpbDk4?=
 =?utf-8?B?bHU4cDJBajFMZExmQnFhNnhpajJKeWpjOFNJdGFKZjdCelF2MjFMbXc3YkZM?=
 =?utf-8?B?ZjVFbjFlOXFXMmcvL1JETkVSNlRsQ1d6a29vaDAyZ0Z4bm54M0ZQUitpZW1G?=
 =?utf-8?Q?iesw=3D?=
Content-Type: multipart/related;
	boundary="_004_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_";
	type="multipart/alternative"
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23a2ef5e-60ff-491e-f13a-08da6108efa6
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2022 17:40:23.3580
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB4954
X-Rspamd-Queue-Id: 4LfgXp1lXVz46v2
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=iecBLwWR;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.89.45 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-4.40 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.89.45:from];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[redcom.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.89.45:from]
X-ThisMailContainsUnwantedMimeParts: N

--_004_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_
Content-Type: multipart/alternative;
	boundary="_000_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_"

--_000_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhbSBhdHRlbXB0aW5nIHRvIGluc3RhbGwgRnJlZUJTRC9BUk0gMTMuMSBvbiBhIFJQaTQgd2l0
aCBhIFVTQjMgU1NEIGF0dGFjaGVkLg0KU3RlcHMgSeKAmXZlIHRha2VuOg0KLSBVc2VkIFJhc3Bi
ZXJyeSBQaSBJbWFnZXIgdG8gc2V0IHRoZSBib2FyZCB0byBib290IGZyb20gVVNCIGZpcnN0LCBT
RCBjYXJkIHNlY29uZA0KLSBkb3dubG9hZGVkIGFuZCBidXJuZWQgIEZyZWVCU0QgMTMuMSBhcm02
NS1hYXJjaDY0LVJQSSBpbWFnZQ0KLSBib290ZWQgYW5kIHJ1biBic2RpbnN0YWxsDQotIHNlbGVj
dGVkIFpGUw0KLSBzZWxlY3RlZCB0aGUgVVNCIFNTRA0KDQpJbnN0YWxsYXRpb24gcmFuIHRvIGNv
bXBsZXRpb24sIGJ1dCB3aGVuIEkgcmVib290IHdpdGhvdXQgdGhlIFNEIGNhcmQsIEkgZ2V0IGEg
4oCcRmlybXdhcmUgbm90IGZvdW5k4oCdIGVycm9yIG1lc3NhZ2UuDQpTZWFyY2hpbmcgdGhlIHdl
YiBnaXZlcyBsb3RzIG9mIHJlc3VsdHMgZm9yIGxpbnV4LCBidXQgSSBjYW7igJl0IGZpbmQgYW55
dGhpbmcgZm9yIEZyZWVCU0QuDQpIYXMgYW55b25lIHN1Y2Nlc3NmdWxseSBkb25lIGFuIGluc3Rh
bGwgbGlrZSB0aGlzLCBhbmQgY2FuIHBvaW50IG1lIHRvd2FyZCBzb21lIHJlc291cmNlcyB0aGF0
IHdpbGwgZ2V0IG1lIHN0cmFpZ2h0ZW5lZCBvdXQ/DQoNCi0tDQpTdGVwaGVuIFdhbGwNClNlbmlv
ciBTdGFmZiBTb2Z0d2FyZSBFbmdpbmVlcg0KNTg1LjkyNC43NTUwDQpbY2lkOmltYWdlMDAxLnBu
Z0AwMUQ4OTJDRi5CMzc1NjM1MF0NClJFRENPTSBMYWJvcmF0b3JpZXMsIEluYy4NCk9uZSBSZWRj
b20gQ2VudGVyDQpWaWN0b3IsIE5ZIDE0NTY0LTA5OTUNCnd3dy5yZWRjb20uY29tPGh0dHA6Ly93
d3cucmVkY29tLmNvbT4NCg0K

--_000_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7
DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJy
ZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgYW0gYXR0ZW1wdGluZyB0byBpbnN0YWxsIEZyZWVCU0QvQVJNIDEzLjEgb24gYSBSUGk0
IHdpdGggYSBVU0IzIFNTRCBhdHRhY2hlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlN0ZXBzIEnigJl2ZSB0YWtlbjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPi0gVXNlZCBSYXNwYmVycnkgUGkgSW1hZ2VyIHRvIHNldCB0aGUgYm9hcmQgdG8gYm9v
dCBmcm9tIFVTQiBmaXJzdCwgU0QgY2FyZCBzZWNvbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPi0gZG93bmxvYWRlZCBhbmQgYnVybmVkICZuYnNwO0ZyZWVCU0QgMTMuMSBh
cm02NS1hYXJjaDY0LVJQSSBpbWFnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+LSBib290ZWQgYW5kIHJ1biBic2RpbnN0YWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4tIHNlbGVjdGVkIFpGUzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+LSBzZWxlY3RlZCB0aGUgVVNCIFNTRDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbnN0
YWxsYXRpb24gcmFuIHRvIGNvbXBsZXRpb24sIGJ1dCB3aGVuIEkgcmVib290IHdpdGhvdXQgdGhl
IFNEIGNhcmQsIEkgZ2V0IGEg4oCcRmlybXdhcmUgbm90IGZvdW5k4oCdIGVycm9yIG1lc3NhZ2Uu
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWFyY2hpbmcgdGhlIHdlYiBn
aXZlcyBsb3RzIG9mIHJlc3VsdHMgZm9yIGxpbnV4LCBidXQgSSBjYW7igJl0IGZpbmQgYW55dGhp
bmcgZm9yIEZyZWVCU0QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXMg
YW55b25lIHN1Y2Nlc3NmdWxseSBkb25lIGFuIGluc3RhbGwgbGlrZSB0aGlzLCBhbmQgY2FuIHBv
aW50IG1lIHRvd2FyZCBzb21lIHJlc291cmNlcyB0aGF0IHdpbGwgZ2V0IG1lIHN0cmFpZ2h0ZW5l
ZCBvdXQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3RjdG
N0YiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojN0Y3RjdGIj5TdGVwaGVuIFdhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzdGN0Y3RiI+U2VuaW9y
IFN0YWZmIFNvZnR3YXJlIEVuZ2luZWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3RjdGN0YiPjU4NS45MjQuNzU1MDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojN0Y3RjdGIj48aW1nIHdpZHRoPSIyMDAiIGhlaWdodD0iNDAiIHN0eWxlPSJ3aWR0aDoyLjA4
MzNpbjtoZWlnaHQ6LjQxNjZpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2Uw
MDEucG5nQDAxRDg5MkNGLkIzNzU2MzUwIj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3RjdG
N0YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojN0Y3RjdGIj5SRURDT00gTGFib3JhdG9yaWVzLCBJbmMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3RjdG
N0YiPk9uZSBSZWRjb20gQ2VudGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3RjdGN0YiPlZpY3RvciwgTlkgMTQ1NjQtMDk5
NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojN0Y3RjdGIj48YSBocmVmPSJodHRwOi8vd3d3LnJlZGNvbS5jb20iPjxzcGFuIHN0
eWxlPSJjb2xvcjojN0Y3RjdGIj53d3cucmVkY29tLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_--

--_004_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=2640;
	creation-date="Fri, 08 Jul 2022 17:40:23 GMT";
	modification-date="Fri, 08 Jul 2022 17:40:23 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAMgAAAAoCAYAAAC7HLUcAAAKF0lEQVR4nO2ce1BU1x3HNz6m7XRS
9Z920oxNm07TmU4cp5NOV0SrqaRpxyQbNb6IKdGoWVCLoCtPIfJSlLfoAgvy8EFEQFASQAOoKBYI
7tZEcbNF0DWgiCAoIKj77R+4l7uvcx+7C2t6vjO/f86e891z7zmf3XPOPedKQEVFZVOS8a4AFZUr
iwJCRUUQBYSKiiAKCBUVQRQQKiqCKCBUVARJ1Fo9hMa3Le3o7uu3atjR1YuaJq3oGBwaZrxqNTrO
/HWXW6DW6qH5To/W9i48HHjE68IvfnMdkQe+xMrtWfjbv5IxZ30cZq6KwsxVUXBftweLAtKwNaUI
hdWX0D84xOn3H90tpB+vhX9SIdZE5cErIgdLAtMhUyghUyjhGZYF34QC7C2oQXNbh1UP/Z1uwfeL
3Q4Gg0Fw+VqNzqIew4+f8LqHABCuOum0iM4u53XvzSVTKCGRyh0TYgtOdPNBaFopDAaDSeWyy+rs
qlBrexfjNWWBnyiPGZ6RqGq8ZvXm/fdWJ/68epcgvxff3Iy4w6ctrhUAOnseYMHGJMF1XOifinu9
D028EvOrBPscq2oyqYvQ8lMW+DHlr7Z2wD+pELvyKhGiLEVKQTVnZ3zdMwI9fQNOidc9I/Dulv0Y
Gn7MWQ+2ZAol9hWeccj3iwbEGOY30RUAkUjlmDTbB0cqG0zqNvBoGL9dvF20Z9D+EhM/g8EAt7W7
RfvNk8ebQCcGEGXRWaZ8c1uHaEAGh4bhm1CAQxX1CNx3HCHKUpxuaEbuFxeJnXHmqihBnVeIZq6K
gkQqx7JgFZ48fcq7nEyhRHZZnWO+315Apnr4YeDR6LDIVQCRSOX46Xxf3H8wwPhlnbhgl99ENx/c
6uxh/Go1Orv8JFI5CqsvMX5iAInK/tKu+hgBqWq8hnNqHcJVJ1Gr0eHDsAPo7utHaFopZydyloyA
SKRyeEXkWP0HtyaXAkQilaOoZrSRXQkQ87p5hmXZ7ZdRUsv4hWWctNvvw7ADjJ8YQDbsyWfKF1Zf
cgggMTnlWBqcgSdPn2J7+gnOTuQssQGRSOXwjj3Cq5w5IINDw6Lmw79ZFOoYQNhDD1cDJFx1kvGb
9Ums3X5bU4oYv2XBKrv93NftYfzEAPL+NiVTPq34nGhABoeGsTlxZIh1p7sPhysaUHJWg4Pl9Zyd
mK158nhR94E9F2J7m+fjAhawBKS1vUt8G9nbwBKpHCu3ZzGVcTVAPok+yPi9ujjUbr+NcZ8zfo4A
jt3BxADyhlcMUz46u9yujnnlejv8kwoRm1eJ0DR+k/SxBoTPP9aYAfLyO4G4fa8XPX0DRBOZYvRX
jAuQ6e8FIbuszmY8YC3TkgB5a1MyWtu7OMfd7LpN9bDtN83DH4n5VUjMr8KP526ymc8rIofYgOw4
VFGP42c0xFUzewH5+d8VTPnNiQUO6ZiPBKwa/V8D8oosmPkSUr7lIZlMPi5AhIxZSYAYOz7Xxc/3
TuDlx75WUr41UXnEBmRHT98A02DOAkQilTMdWswcy1rHFCIKyDOR8rFXOlwNkHnyeF5+fAHxTSgg
NqAzAZnsvgHTPPwt0nX6TgDA274pFp+9+OZmCsh4A1J2/hsmHxcgE9y8MWWBn8240XGP8XIEILPX
7ublxxeQjyNyiQ3oTEAW+qciNq/SIv10QzMA4A2vGJP0uZ/GQVl0lgJio4+8tDAAr8iCiWE3IK8u
DjV50jlWk3S+gLBvKF9AZnhG2rxhW5ILiQ3oTEBkCiUKvmqySDcuPU9/L8gk3TMsC/mnGl0CkCWB
6Wht77IatRrduACi1uo5vewCRKZQ4rubd0wMXQ2QuZ/G8fJjXytfjQcgXzffsEg3LrObLy4EpBbj
+BmNSwDCXtwwV2t71/MJyEQ3n9G/mmdpE9y8sSuv0mQoxJarASJmDsJX4wFId1+/RfrK7VnoHxyy
SE89dgZVjdcoIM4CxFZM9fDDitBMFNeoLTaS/RAAIY1J18UcIjagswGxdh3SNbFo67hnkb/krAY1
TVoKyFgDwg72qg7ADcgMz0jEHzmNH83ZOOaAvLQwgBcgJL+lwRnEBhwLQP74UbRJ+i/+sQ0NV9os
8n/dfEMQILUaHbwicgTFWAMyzcOfs07GZ21s/3ED5HcfhJkY8l3m/f7ufatnTdj/SI4GhD1UFAuI
kAeFzgJkSWC6xWeq0vMWabfv9UKt1fMGJLusDltTigSdDbrWdtuk/R0JyLW224LPKhmDfZTAaYC8
MMsby0MyOSFh75h1tecgb21KZvx+KIAo9hZxtslk9w0wGAyCAUnMr+LdPtbkSEAcJacB8vI7gegf
HMJENx/iTTauwwNjB4iYrSaOAIS9t8sRgLixntPwBWQ/x7MNiVSOX78fAgAUEIzBMq/5Ayjz2Jlb
wRhyAcI1hrzb84DxcsRmRfak+vfLwm3mm+y+gTlyS/LzSzrG+P3p453EvL9cGIApC/wwabbtHxj2
EJDPg0IAqPz3Vc7rnrN+ZHlbKCAxOeV2ncJzX7fnuQXkgZXj2rwA2RR3lHiTlwSmM4autps3LGN0
u7vQo7bWYkdmGeMn5qitrU4PcANihEmn7+T0XRE6sj9OKCD2Xo+tIAHSfvc+fvKXTfBNKHBKrI7M
JQKSXVaHYGUJ4o+chl/SMZxTj57T5wXIkcoG4sVPfy/IZQEp+Gr0zPaaqDy7/bJOXHCo30efZQsG
ZGj4MSa4eRPzbkstfm4AAYBMK4sMzg61Vo9T9VeRf6oRir1F2JFZhsMVDQjcdxwdXb38AbG2xm4e
nc+GRq4EyKTZPiZDtoPl9Xbf1Evam4wf1w8Hn2APT/kCAgC/IsynJNLRdwU8L4AAQPLRaqd9v7VQ
a/XMiGB5SCa+bWnH6shcXP/+LrNMzHurCekZgkQ6umHRlQBhT6iBkXMOry21PQ/hiteWhpuci340
/Bh/WLFDtN9ENx9cbR19BZAQQOZ7JxDzFteonztAACAmR/ihL7Gh1urxmWoEkLd9U5D0eRXCVSeh
03cyL6vgDcgHQRnELzOS6CqAzFkfh96HgxYN0HLrLueig7WY5uGPC5dbLPw6unqxKCANL8wiD3nM
42d/3WzxxhAhgHAN7xqutAGA1QeI7HA1QAAgILXYafVgh1qrR02TFocq6qEqPQ9gZKi3LbWYGXlI
SC/uYi/51TRpiS/5Mr6fSa3V2/WyMOPSKDByhFTIZCwgtRjJR6txTq0jvgHDYDDgwuUW7MytwNro
g3h3y37Mk8ebhMfGJCwLVmHDnnxklNSi6/5Dm34AcPN2N3LKLiJYWYJlwSrIFEoTL5lCiX/uyEFE
1hcorlGjr98S3mNVTRb1YAd710Ja8Tlm1W3mqihI18Sa5DU2sFqrJ3qyFwlcBRAA8NmdPyaAACND
5aD9JYjOLseW5EI0Xm1j6kFfPUpFRRAFhIqKIAoIFRVBFBAqKoIoIFRUBFFAqKgIooBQURH0Px5w
2feGgsNbAAAAAElFTkSuQmCC

--_004_MN2PR09MB4667694B5C97EAFA1816901AEE829MN2PR09MB4667namp_--

From nobody Fri Jul  8 18:00:27 2022
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 BACC917D45D9
	for ; Fri,  8 Jul 2022 18:02:03 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfh1f1stWz3Fld
	for ; Fri,  8 Jul 2022 18:01:58 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 268I0RVL018740
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 11:00:27 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 268I0Rab018739;
	Fri, 8 Jul 2022 11:00:27 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 8 Jul 2022 11:00:27 -0700
From: John Kennedy 
To: "Wall, Stephen" 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Installing 13.1 ARM on SSD
Message-ID: 
References: 
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-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lfh1f1stWz3Fld
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	BLOCKLISTDE_FAIL(0.00)[107.170.196.116:server fail];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[phouka.net];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 08, 2022 at 05:40:23PM +0000, Wall, Stephen wrote:
> I am attempting to install FreeBSD/ARM 13.1 on a RPi4 with a USB3 SSD attached.
> Steps I’ve taken:
> - Used Raspberry Pi Imager to set the board to boot from USB first, SD card second
> - downloaded and burned  FreeBSD 13.1 arm65-aarch64-RPI image
> - booted and run bsdinstall
> - selected ZFS
> - selected the USB SSD
> 
> Installation ran to completion, but when I reboot without the SD card, I get a “Firmware not found” error message.
> Searching the web gives lots of results for linux, but I can’t find anything for FreeBSD.
> Has anyone successfully done an install like this, and can point me toward some resources that will get me straightened out?

  For my RPI4, I burned the SD card and initially booted off of that.
That approach got started from Mark Millard's approach here:

	https://marc.info/?l=freebsd-arm&m=162032836014677&w=2

  The image I seeded from was "burned" via:

	xzcat < FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220603-185159f77c9-250958.img.xz | dd bs=512b of=/dev/da1

  Probably could have used a much bigger multiple of 512 for the
blocksize, da1 happened to be what the disk-to-be showed up as on my
system.

  So that's a -STABLE (vs a -RELEASE), and that "arm65" was probably a
human typo I'm guessing (vs arm64).

  From the SD card, I did a typical bsinstall onto the USB-connected
disk, then stomped on /boot/efi with the SDCARD's /boot/msdos contents
(uboot).  I suspect that is what is biting you.  I yanked out the SD card
at that point, and have been USB-only ever since.

	root@rpi4:~ # gpart show
	=>       40  488397088  da0  GPT  (233G)
	         40     532480    1  efi  (260M)
	     532520       2008       - free -  (1.0M)
	     534528   50331648    2  freebsd-swap  (24G)
	   50866176  437530624    3  freebsd-zfs  (209G)
	  488396800        328       - free -  (164K)

  This was from the SD card booted, where the USB disk is now da0, and I
think that is bash-style environment variable declaration but you get
the idea.  Reformatted what will be /boot/efi, mounted it, copied over
uboot from SD card's /boot/msdos, unmounted it:

	export TGT=da0
	newfs_msdos -F16 -L uboot /dev/${TGT}p1
	mount -vt msdos /dev/${TGT}p1 /mnt
	(cd /boot/msdos && tar jcf - .) | (cd /mnt && tar fvx -)
	umount -v /mnt

  Probably a little old-school.

From nobody Fri Jul  8 18:05:29 2022
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 6D80117D578C
	for ; Fri,  8 Jul 2022 18:07:02 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfh7S0Vdtz3GgK
	for ; Fri,  8 Jul 2022 18:07:00 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 268I5T8s025438
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 11:05:29 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 268I5TJU025428;
	Fri, 8 Jul 2022 11:05:29 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 8 Jul 2022 11:05:29 -0700
From: John Kennedy 
To: "Wall, Stephen" 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Installing 13.1 ARM on SSD
Message-ID: 
References: 
 
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-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lfh7S0Vdtz3GgK
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	BLOCKLISTDE_FAIL(0.00)[107.170.196.116:server fail];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[phouka.net];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 08, 2022 at 11:00:27AM -0700, John Kennedy wrote:
> On Fri, Jul 08, 2022 at 05:40:23PM +0000, Wall, Stephen wrote:
> > I am attempting to install FreeBSD/ARM 13.1 on a RPi4 with a USB3 SSD attached.
> > Steps I’ve taken:
> > - Used Raspberry Pi Imager to set the board to boot from USB first, SD card second
> > - downloaded and burned  FreeBSD 13.1 arm65-aarch64-RPI image
> > - booted and run bsdinstall
> > - selected ZFS
> > - selected the USB SSD
> > 
> > Installation ran to completion, but when I reboot without the SD card, I get a “Firmware not found” error message.
> > Searching the web gives lots of results for linux, but I can’t find anything for FreeBSD.
> > Has anyone successfully done an install like this, and can point me toward some resources that will get me straightened out?

  ... I should also point out that there may be some issues with
multiple USB disks attached, or if your disk is slow to discover, so way
more context around the "firmware not found" would probably be key.  My
approach worked for me.

From nobody Fri Jul  8 18:26:59 2022
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 393BC17F8696
	for ; Fri,  8 Jul 2022 18:27:03 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2057.outbound.protection.outlook.com [40.107.91.57])
	(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 4LfhZY6t5Sz3JbT
	for ; Fri,  8 Jul 2022 18:27:01 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Y/5WCoSxQlNOKp6efpDVQwZh5pSKYQ2oCqxyTsUAR8TjVhJkNrxdeLeQWV0RrAyJorV+c454kliH+EE0slwn2eSe0lWwFdAXRse1g6/Z/SWNMDJHAFwCluVaM9KsAhfkd358kKZJl5hVFdaHHh6sZAi9Deku1RkwiHtQawMEMkz7ho+ocMegyO2LGt6TiEiCMIY+vFhHXqzKiD0jnhkGyMb5WySjyIwEtB/TF4QNOXKfY0RLkv4rjSgESeQWNvvn2WCOZZ9I8jSDehmdj2Cn3k/bKRBpHfLc2XcxvoUaWoNw1yu8mhHYHAC4LaMwZlrNxFPe8qveAuO9v4bXCXqTCQ==
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=6PkezgkslTtFZeC50UDxZ+ZE6Ch6v+wEIinreET2pEQ=;
 b=gOS4q+uwXqtlByCbq63C4Ckv55YsC87UEXPp09mJQiul1KSQ3eqQs6PmQAOMIvulxmHcu1dLlFUS58DBRuQnlJYb0+3N6G/Hy54mcqYTIPTkCrZGEEdaDgtEz7Q+A2AqhG/KJIIPsTJCbVv2wQL+yLxHEw/CJh5V+gYuSyNUGsQMZQPEs69/DgmhDVZrIABMAExDiqEyMuZjYt86yaGcF+qMo/jx01BgvyonF6bLA6+Qel4nIw9T0xJ9bFNllzE3/QEj3AsA4DmHYRi/tRhAZChOLAaPsDlzuKQll/ouSrLslIL+psX0fc5YqG2Lepb8OINIfS7OoYvqiXJ80MbMMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6PkezgkslTtFZeC50UDxZ+ZE6Ch6v+wEIinreET2pEQ=;
 b=E5ldTksHx7NPgNxeUzcaXErY4/PmTVbD65PKkQgASBNioQt7qtrKStyPafkhgkHvQcL8XhKLKJZqYr9pSorBJO63b5aYxSkDXCg+4YEuiySEHuAiSajWtg/uBPGZ997MaJo/CJnK39CaOJ27bwB2iuz5wEqqAWCzpnNwK3eJsO8vCA88iUxBdcIsCApc5voBRSAeLmkiNGOshsxwHlUTu1CjV5vsP2KqvaxX/y+PF1lp9l5uGRT919y5JBjapOhYzESwLAfY6mFi/zhPJ3BhvKyt0v7hcFsMhwvJUH8BvyGlvUfD4v1nw66t45nJzrw+Z0xS84LEn+PDoHq+zSIh/w==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by SA1PR09MB7392.namprd09.prod.outlook.com (2603:10b6:806:171::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Fri, 8 Jul
 2022 18:26:59 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474%7]) with mapi id 15.20.5395.021; Fri, 8 Jul 2022
 18:26:59 +0000
From: "Wall, Stephen" 
To: John Kennedy 
CC: "freebsd-arm@freebsd.org" 
Subject: RE: Installing 13.1 ARM on SSD
Thread-Topic: Installing 13.1 ARM on SSD
Thread-Index: AdiS8ERGKwQPlDhfQrOEvtCOXYsV4QABFZGAAABuaJA=
Date: Fri, 8 Jul 2022 18:26:59 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9deb7340-d649-4b43-8e9d-08da610f720e
x-ms-traffictypediagnostic: SA1PR09MB7392:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 XX/Wh0cjqldSf4lNmDgXM+qjFSeZUUlj7hHL5iT6hzRH055vcBxCarZ7EUc38YOWPRGBeHEs0D2kmCiMKstGEZKUlBL7Ujo5QzjEOrkx3SVQb5QX+6N6blqowTaDrPeZqjBY1YBws5NpUKRdylxH0kLpjSIIi3DSw2t/0xPNJaJbT+xiv8i+R/VhtHaoAdBBImp2LuLMTZQ5Vk7SiqOkFIrzbNgURclOGIj5QKgSvdmsWgpqoYALE8fomCLflJ9h52G/b2zk0uTkWVMpLHG/i5sJB0twHrqRTRpoHjNgaAqnrm3xeYR2z771efJQ6/bS7gOP/pL6RnO2cRXXtk28R272t3kNqq0UCkymxJvmcSTba8D1FF2SPAcIxj6IUaBEZPjzOm46tXhMVLM5QxVm0d1Kp1oFBcapktfmowttnk6+lmMJ6kFFMhXYPKMINZjNH+LV81zXGW2BaNzO56Th8ZHrIOTDtd46n5DPriR/oE+dHLzshyL/+s3/tr5z5eck8D0bCRt3Hnb/zZRaMy5HXZjkDw9oGYTyhIbOQ/LuAI6zWo9yH4EubO23ndKThgLRcdSJNZPV3/2/zRwqjeWpWAZhzhxtgR/NowJnV3vhvUIT7ODBN1QUV5VmHmBvhmd5ZfwgzsskL9XxI/hd6bbFGmVhHj6K2c/B3CSKpqnLW1p2q0SXA9XL/IGWMxiyVPFAc55yzX7zbwWM1hourFFud+0p4IQGP09Bg2tZiydWqIHRrbG3C79/6KLjWgZKOhBZR9xuSMZNyWIAik4ti7NL2YtPgaUvwb4A0TbQLkAkewQ4W1LFFZ3KL82G7d1QtyAj
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(366004)(396003)(136003)(39830400003)(6506007)(38070700005)(83380400001)(6916009)(38100700002)(9686003)(66446008)(7696005)(26005)(55016003)(76116006)(33656002)(66556008)(66946007)(5660300002)(41300700001)(122000001)(66476007)(71200400001)(2906002)(52536014)(4326008)(8676002)(86362001)(186003)(508600001)(4744005)(8936002)(64756008)(41320700001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?N0V4ZWtoMi94TDU1aHEvR0RpdG1XUFBGSWRqdnNpZFl6anZRc0N5cWMvazJE?=
 =?utf-8?B?MWdYOVM3MWc2SmhVMXV2VEsyNy94OGZuUTQwUWl6TFpzWlZmSkdCOEgyOVpr?=
 =?utf-8?B?N1RNYWdvc1NtTHA4czQyMy9XaVRHT1YveTRwY2E1T1FuQlVLNmthZnJxRDZ6?=
 =?utf-8?B?d3A2ay9NdFM5a1BJNGxNY2pUODJkeVE5ZURjZkg1dzUzMTlaa2pJdDdhTTBG?=
 =?utf-8?B?RmFQMjVmY2ZmZ1FSdkZ5TWZQL3pjSHVCMmFvbWxBMUp1WlppOXZIeXpUQXlE?=
 =?utf-8?B?eGFyVkFnaW1Lb1ZQWkJPYXpUMERYcGNtYlBZR1dxTEIrWnVpc1FyWUwzZW1r?=
 =?utf-8?B?YWhRcUhCdjlGMFNVamxlT1RJQ2RiMEVva1JIdzZQM2xaTDVqb2pMOGRiY2c1?=
 =?utf-8?B?WCszMkZ2azRMN2pNKy80ZjVHNGw1TE01NFRaT0xqYXBLb1Fxcm9seDVZTVl2?=
 =?utf-8?B?VDROdW1PYUFIdTNTdjdudlNEZENWam9iSlpxUU9JVWVXUGtXTzZNTDVSSks3?=
 =?utf-8?B?VE10c2RCdmw2VTR5cVBwS0ZPcnlVeHNzMW1YOFVXdDlOUy9HTmJYQWZ0cmdq?=
 =?utf-8?B?VHZyZ0IxKzhmMjJzbnpkRWhuMlp4WlNVNXJTN3U1Q1U4T2pTZHg3STl4M0Rn?=
 =?utf-8?B?Qndva1FWa1pOcEZzc1FRRHB0dEpDa2ZCTjJNL0JDYW1GUWZoalM5RG5BbXlY?=
 =?utf-8?B?QUVxVzdmK20yWU54Zi90bWd5UGFtNEoyMndnK096NHFOMTZCa2QzQ2xKdkJJ?=
 =?utf-8?B?emRQb3ZtRUt5ZXNnelZZYzVjOWtTREJjMUdjaVpndllpNHhEQkR1NXZSQ2lm?=
 =?utf-8?B?c1FiZ2R0SWRyVUdITUt2QkVGdXg4WmVNc2RkSVBHV1ZnRzhBcjJkWDlZMUdQ?=
 =?utf-8?B?NGpxaGN4S01mcWVlb1lVbGszZnJqUUdJSDNvRVNlL2RQYmtJZnRwVTkyQVRT?=
 =?utf-8?B?RGRVSGZpbWRWQ0hGWTBOcnNXdWxzaEUvTllkMzRUQ2kwMnR0QU04NzlWajhj?=
 =?utf-8?B?MHVMYzh0R2luTG5jRWhJN2NFaFhpRGpBTkRZU3J5c25uNzQrSzdpR3dtUVZ6?=
 =?utf-8?B?ZS9RVms4YUJuL1Fpd1k2d2M3RTJpb0ZyRkNOWmVLNk15akJlOUFvaVd4eFZh?=
 =?utf-8?B?d01LdEVOQURCbVMwa3JHYXFHS0tLNmpmZWFmTHF4bkZiYUtwVlcvakh3L3Ri?=
 =?utf-8?B?cXVqdlpKVzkwRHFWN3lkQVdxRDJscllBeVA2TUE0bWdBZGc0OWdXYkNxYitS?=
 =?utf-8?B?SEYxLy9mREx0dEptUk52K2dEQTBqM0pRSlMzalczekVFVW05a2VSeU0xNm9P?=
 =?utf-8?B?SnRNall1ODBDSjEzTHAzRHhxTEQ3cFpGbHJ6ZjRIOHZjbUN0L1k0Zk83bUt6?=
 =?utf-8?B?blZNSzJUUkcwNVE4OG5acWNDZGFEbXNpMmxCdkIybHJWanZlckVLMDgwb29o?=
 =?utf-8?B?Z01mZUhqc3h6NmYvb0FaTmFYQnQ3N1ZIb1lvT3RNeFQwTFlzSjJwWHRvcmN6?=
 =?utf-8?B?TTdwMmZjNlAyRmpLL3hxVEdwZ3c2MXNreDhVaWEzZW16WklDUmZxWXh2dGtn?=
 =?utf-8?B?dHhHUmNHY1VUQnVKalllUEE2KzNJT3hlRUsvbllpY0Y4Mmg3d3c2Q3NkVHNY?=
 =?utf-8?B?cW5MZ2pjV3pSa0JJMkZuUWIvNXNUMTlwMFUvbXdWemh0L3N6VUYwTm5LVHpq?=
 =?utf-8?B?dDBtYVZuc3JrODI3RnkwUTVzNml0S3RHVGpuYlJTblpGZ1BVMjlsRmNMd0ZW?=
 =?utf-8?B?NnJiUkRkRVB0WkY4NXpjenh1amZzbE15Rlk0RTNDQkRoYWxDWE1DVThUVjcz?=
 =?utf-8?B?UUROM0RpaGp2UTExWUx3MDIzbkl5UVVZMjkvcXg5eFlPRE82dVMzdWd4MUdG?=
 =?utf-8?B?RzNoWDlMM1FVMFQ5RURYUGdlZ0dYQzRvWG5xY2taWDJpV2tyWkI5VUM2Z0xD?=
 =?utf-8?B?K2VhdjdQWlAvS0JJT0QyNlFwOGxRL3hhNlByZkpjbFRkVktyeFQxenZQc3kv?=
 =?utf-8?B?NXlBMXRndDB0Nm85QkR5NkZDbjNsVkNJczZvZGRRaktoaHVIU3hTZDRjWmx3?=
 =?utf-8?B?cEo3bTBRTmZkZFh3QTM4Z1ZCWHV2dCtqdmVsWm5uVTJLMElsbzJlTUF5L1Nq?=
 =?utf-8?Q?f/gY=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9deb7340-d649-4b43-8e9d-08da610f720e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2022 18:26:59.1681
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR09MB7392
X-Rspamd-Queue-Id: 4LfhZY6t5Sz3JbT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=E5ldTksH;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.91.57 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-3.40 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.91.57:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[redcom.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.91.57:from]
X-ThisMailContainsUnwantedMimeParts: N

PiAgIEZyb20gdGhlIFNEIGNhcmQsIEkgZGlkIGEgdHlwaWNhbCBic2luc3RhbGwgb250byB0aGUg
VVNCLWNvbm5lY3RlZCBkaXNrLCB0aGVuDQo+IHN0b21wZWQgb24gL2Jvb3QvZWZpIHdpdGggdGhl
IFNEQ0FSRCdzIC9ib290L21zZG9zIGNvbnRlbnRzICh1Ym9vdCkuICBJDQo+IHN1c3BlY3QgdGhh
dCBpcyB3aGF0IGlzIGJpdGluZyB5b3UuICBJIHlhbmtlZCBvdXQgdGhlIFNEIGNhcmQgYXQgdGhh
dCBwb2ludCwgYW5kDQo+IGhhdmUgYmVlbiBVU0Itb25seSBldmVyIHNpbmNlLg0KDQpJIHRyaWVk
IHNvbWV0aGluZyBsaWtlIHRoaXMgLSBJIHVzZWQgcnN5bmMgdG8gcmVwbGljYXRlIHRoZSBTRCBj
YXJkJ3MgKG1vdW50ZWQpIG1zZG9zIHBhcnRpdGlvbiBvbnRvIHRoZSBTU0QncyAoYWxzbyBtb3Vu
dGVkKSBlZmkgcGFydGl0aW9uLiAgVGhhdCBnb3QgcGFzdCB0aGUgZmlybXdhcmUgbWVzc2FnZSwg
YnV0IHRoZW4gaXQgc3RvcHBlZCBpbiB0aGUgYm9vdCBsb2FkZXIgYXNraW5nIGZvciBhIHBhcnRp
dGlvbiB0byBib290IGZyb20uICAnemZzOnpyb290L1JPT1QvZGVmYXVsdCcgcmVzdWx0ZWQgaW4g
YW4gdW5rbm93biBwYXJ0aXRpb24uDQoNCkF0IHRoZSBtb21lbnQsIEknbSBydW5uaW5nIHdpdGgg
dGhlIFNTRCBpbWFnZWQgZnJvbSB0aGUgRnJlZUJTRCBSUEkgLmltZyBmaWxlLCBhbmQgdGhhdCBp
cyB3b3JraW5nLCBidXQgaXQncyBVRlMsIG5vdCBaRlMuICBJJ2xsIGdpdmUgeW91ciBzdGVwcyBh
IHRyeSwgYW5kIGlmIEkgZ2V0IG5vd2hlcmUsIEkgbWlnaHQgd2luZCB1cCBjcmVhdGluZyBhIFVG
UyBwYXJ0aXRpb24gZm9yIHJvb3QgYW5kIGJvb3QsIGFuZCBtYWtlIHRoZSByZXN0IG9mIHRoZSBk
aXNrIHpmcyB3aXRoIG15IGRlc2lyZWQgZmlsZXN5c3RlbXMuDQo=

From nobody Fri Jul  8 19:15:52 2022
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 9C85417FFC6E
	for ; Fri,  8 Jul 2022 19:17:24 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfjhg6Ynjz3Pnl
	for ; Fri,  8 Jul 2022 19:17:23 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 268JFqsm049529
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 12:15:52 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 268JFq1g049528;
	Fri, 8 Jul 2022 12:15:52 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 8 Jul 2022 12:15:52 -0700
From: John Kennedy 
To: "Wall, Stephen" 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Installing 13.1 ARM on SSD
Message-ID: 
References: 
 
 
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: 4Lfjhg6Ynjz3Pnl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[phouka.net];
	RCVD_TLS_LAST(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
> I tried something like this - I used rsync to replicate the SD card's (mounted) msdos partition onto the SSD's (also mounted) efi partition.  That got past the firmware message, but then it stopped in the boot loader asking for a partition to boot from.  'zfs:zroot/ROOT/default' resulted in an unknown partition.
> 
> At the moment, I'm running with the SSD imaged from the FreeBSD RPI .img file, and that is working, but it's UFS, not ZFS.  I'll give your steps a try, and if I get nowhere, I might wind up creating a UFS partition for root and boot, and make the rest of the disk zfs with my desired filesystems.

  So, bsdinstall should have set that up (zroot/ROOT/default).  From the
UFS disk, I think (off the top of my head) you can just do a "zfs import
zroot" and then you should be able to see it (and everything else) with
a:  "zfs list -tall -r zroot"  If you picked something other than zroot
for the pool name, you might need to do some more tweaking.

  In my case, my USB disk is only ~256G.  I don't know if uboot has any
BIOS limitations like old x86 did.  I've never had to be too wary, but
then I've never had BIOS-breaking SSDs laying around to attach to RPI.

  I think uboot has some commands that might let you do some zfs
exploration, but hate to point you at web resources because there seems
to be a huge variations in what we end up with on FreeBSD/RPI.  My RPI
is a few hours into a firefox rebuild so I can't give you some real
guidance from what I'm using at the moment.

From nobody Fri Jul  8 19:23:10 2022
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 7FA9F18096DE
	for ; Fri,  8 Jul 2022 19:24:42 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfjs52n1dz3QsZ
	for ; Fri,  8 Jul 2022 19:24:41 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 268JNAaN049553
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 12:23:10 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 268JNAvj049552;
	Fri, 8 Jul 2022 12:23:10 -0700 (PDT)
	(envelope-from warlock)
Date: Fri, 8 Jul 2022 12:23:10 -0700
From: John Kennedy 
To: "Wall, Stephen" 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Installing 13.1 ARM on SSD
Message-ID: 
References: 
 
 
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: 4Lfjs52n1dz3QsZ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.74 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.943];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[phouka.net];
	RCVD_TLS_LAST(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
> I tried something like this - I used rsync to replicate the SD card's (mounted) msdos partition onto the SSD's (also mounted) efi partition.  ...

  Also late thought...  did you use rsync options to delete files that
shouldn't be there?  If you just merged SD-card uboot onto whatever was
there, you might have "unexpected" results.  My format got rid of any
pre-existing files, then the tar just copied the stuff I wanted in, but
a "rsync -va --delete-during ..." should work too.  If you can read any
files off of it, I'd think the filesystem format was fine.

From nobody Fri Jul  8 19:35:11 2022
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 A63D0180B54C
	for ; Fri,  8 Jul 2022 19:35:14 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2051.outbound.protection.outlook.com [40.107.89.51])
	(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 4Lfk5F58tWz3SJt
	for ; Fri,  8 Jul 2022 19:35:13 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=H1bvZztidRH912PYfQO5RLT0avMu8VwmZVa+3LPK6IA/VPfZS0hs5bBBEJ6lPswTd25u4r9pnPeEisgUXqwCk3cRq+ernuFCa7NgGVGM4JAJBwCx27l1tuAEStVv+e0UZicviQk5NqoAzat0/UmyOAQhvSR8Hxk/luucqzAzr58T51uGDzeNnkVe1cXqenLxWwLe/vQlyrSkzn+NMxdz9Eaw04pUKQo+UTUo+Y2I7u7fB/m9NhDQX87Vw5jNHeHxF4Igya19zrMWb04+lXBmvxq4VnrPOo4fWZk2DGs1aeVSUJTaiDXX4LGwzw3NQWZEBdRnI5F1l35idthOPsEEdw==
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=nK1SKYEp6dRYZcaenMLVBexKioRqqRjSgmR9C1tOEO0=;
 b=Nl41IYpMjAa2yA8AdnGwTE8wkgKPkrDqqv0+pgoa4RRpVul3LffPgzGgPHI58uRS27t2kR8Q15fBM7OV9Se2J5+6hxKouvIP8dAhZi3yVpQOC/+2rmItzKVTKyd08YNRtJwEx8lwq0M+JaFKeq6U0B5nBMEQzx+nlZ8KDK08II3Ucv8r3u0IVnoBL/X/WH3eOgumDpXvIGiXmWuSZYio4nP1Mtv7u0xjdhNBIX8N5sUvCWQkU4L5fVEhw3U5yVoatevq3X9pf4zIPx9dOWVKGtMxUQFitnJ5aubMie6Q+6gmKkYtwGUllJtrT3SPtKHio5LTlSJplTbf5az+LmEj1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=nK1SKYEp6dRYZcaenMLVBexKioRqqRjSgmR9C1tOEO0=;
 b=XMp3Ucr+rvHyR+kiODx5tKdmrZnJS5Ayd5hLXo6sg8LUI2NuGaSB3kqPHTuSU+WyQPMMR51Bn8LRAzafzQnEEvFA20i75ZQ70CA2c6mcq+/BozD+4saisbVhGjR+T2fqDUznq61t6sYP6ZRzLza631SDkgVmW48Y+AtkfUAsoP9S/9NP8/5wPrDJWsKc00HEMagxzE6dKGgavq9MELn3IYFe6Xs1UjESBqas6Pl447hdLiZoJf4YNO5AyaxIbuhymwtyGHPF9TuKi6S22WP+MsSQ8AYI5siwb789xNctnbJ0XZxnXN8Ne0YhOCsN1drWXt8bsOafndHBToEuYZtV6A==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by SJ0PR09MB6095.namprd09.prod.outlook.com (2603:10b6:a03:258::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.20; Fri, 8 Jul
 2022 19:35:11 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474%7]) with mapi id 15.20.5395.021; Fri, 8 Jul 2022
 19:35:11 +0000
From: "Wall, Stephen" 
To: John Kennedy 
CC: "freebsd-arm@freebsd.org" 
Subject: RE: Installing 13.1 ARM on SSD
Thread-Topic: Installing 13.1 ARM on SSD
Thread-Index: AdiS8ERGKwQPlDhfQrOEvtCOXYsV4QABFZGAAABuaJAAAnUkAAAAFSqA
Date: Fri, 8 Jul 2022 19:35:11 +0000
Message-ID:
 
References:
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a0d1ab2f-92cd-4df9-21b1-08da6118f913
x-ms-traffictypediagnostic: SJ0PR09MB6095:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 TYtAPHqO6h5jZ/RBavEaXatTL6PtXBwPXHa8Fw/0H3iOzJURr4KuFRQseBM5Tt8I3SUMuEynThtwErtWyKRzaN8F1lgmUbCypyYHdRbcD4OSTxfTfKW6UVBvvt9OpbNvCssHO2YwNQSHt/XnaTEbNicSUxIkM0QInx92FUnGRgt9GKOHQ2cKJWo03e+yg/Xmhdzn+ioPTDo93r6x5H7Z7H67YttzBOcAcbLLYY0tjLLxtPNyeEk9zZDk/8c/qi7/FZw7MbuWKvJBvPz96nUo/yEpKocbKEj/YOR8FboKEqFFqS91I85iywa3rg2wzZG8Wryx3pQ3xsQFYsxko6RW3BDAcrbndyocXpAmgjojnFrhya6AaXsh4o2BEVzEcvBz/1AYvWLlp2ePKMQ/oZjTzLPgQxbcjMJIu5NkPNU/BICSgzWHAbB6ZThFPusJgFm2XdTlDDKoyGNlgnbirUoN2fpeBTx6PToaNr5hxJk7Pzw9UXtBPwLF6ceidqDs/xNVe4llGm10P6CyjQkpD4jZBcy8bwg/S7RHsY4MvHnTInoVOnyF+JciU+/YQ6f/RUHa3spAibWmcKcjzTlycR6/bP92AY7U7M9LBZW6eYMHhjhz0s2XAvKnuUNnZSy9MW9cDgILCEfo8CxnusmXWj4KxvuziQ3UTu7uQ/9jRyDxJyZPN1lqCWkffrtvtHyXy4ih39eZjaK6QqjGmdOTJmSFjbGwaFQ4h2ldB7vJhO3mtL/HpoiNb/uukf4tYjQni91SGeDvYRe+QUbJpc4TIPvKBVVgbDjyZGKdkIJGodkf85AYPuSZMiSnJq6SZb5QBcvf
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(366004)(136003)(396003)(39830400003)(33656002)(38100700002)(186003)(2906002)(8936002)(122000001)(5660300002)(52536014)(55016003)(4744005)(83380400001)(38070700005)(66476007)(64756008)(8676002)(66446008)(66946007)(66556008)(76116006)(4326008)(86362001)(508600001)(6916009)(9686003)(41320700001)(7696005)(26005)(41300700001)(71200400001)(6506007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?THFzYVFtaDVFUTJVa084Ymd2NER0aEpPdW8zSmdUcjExalFvR2U4RTZKN0M0?=
 =?utf-8?B?cDZ2bzVWbmczdzVhbWYzbEtLMlJtYU1MNllnRC8wNXI2ZDIyMHRJLzdBaVpH?=
 =?utf-8?B?c2NHYjd0QXo4QndBaXdZeWxEU2dRTUdWZk1ibVJuNXN1eHF0VmJxR0VQQld1?=
 =?utf-8?B?eGRDS3RkQ2FOTzV1c3dXb1JzK0xkWkdVSzlxYTlVV2xNTHcwMlNmY2Rwc1JI?=
 =?utf-8?B?WjJsVXRDbU1sbEVEVzFxYVRWVG1tYUxBcDBvMGR2WmZxRm1BOXJYRTBYUHlT?=
 =?utf-8?B?SHdyTDJkam9mdXNmZ0lGL2NDaGdTeld3dGUzT3QyYjdCRzNhUHpxTm1PUVo1?=
 =?utf-8?B?ZERsU1YzZFh6cUZmYVZjaTZYZURiM2pxU2hoQ05ObXROMzc5VmY5bXpwZHow?=
 =?utf-8?B?OTZidm1HZi9NL2xuL20wM2xhK2lSYXpsUGdIbmRxdmlEMTErV3BjUXNYNENZ?=
 =?utf-8?B?ZlRZWi93eTRVUVpRS2FsdVA3TmFWZkpQNkNrRi9kVWJiRVQweGhZd0ErRUxG?=
 =?utf-8?B?ZTlVV1dldU1ZNlo3aWdkWjVyQzRrWVdSNTAwTWNqeGd2dmxvNVBvY09rY3lE?=
 =?utf-8?B?TFI4NVlrT0tCeVJWV3pLSExSaW91Q0lxSjJlWXpWeG9aeEVvQ0V6OGtxV052?=
 =?utf-8?B?M3hlZGdpYi8xYkZoTTUxOHRpdFNFa084eFRkN1dTd2FPSGRQa21VNXQvQkJD?=
 =?utf-8?B?MGQ5ZExqYnJ3SjY1b0VGRERVS0gzdTlja3Zra3lIeHlmaHhKaDVUeGZ0emV4?=
 =?utf-8?B?WkIzS25BRFNUUFZZWU5qa1hkVjJUR0JPNHdsd1NBTTMwNkR1YXd1b0pxUmYy?=
 =?utf-8?B?akUzRlJTVHpNYmZTK01oRlFlL3BoK3k2SmhTOWp1eVEyZGdYVStEYzVnZHhy?=
 =?utf-8?B?VGhDOExYdFUyeXRLS0k4MlM4MTJuQUFXRTkrcUF1QUtSeHp6M1JzOWZWc0tC?=
 =?utf-8?B?S3Z5ZFN3RGRRWnFPaFFMK3ErWWdyenFMTVFJL29ROWUvSmhaeUlNaWtvUjM3?=
 =?utf-8?B?NHhLendvMXYrL21sYmRVYW9xV0ZjZERQcjNadU5laTlRcHdmVzl5Y2kvR2Fh?=
 =?utf-8?B?dUNNQ1BBSmZHWjMzRnRqdnpKV3BKaFVhY1BCMzJobEVobyt5WWQ4dXBKRG1F?=
 =?utf-8?B?dllwa0d1c3dkUmtVYmtOL1p3bE9DNGgzeVRzQ01EUWl1eFdhS1I1a3hRaEpk?=
 =?utf-8?B?THBvTFJzclJzVGt6WGlSb0g5dWFlOHE0Sngrdmx6UzBucU1ydFBvY1UwTDIz?=
 =?utf-8?B?M1NqNml1R3ZOUUNScmFBb3luUWNBZ1F0Z3QvWWJxcXFvdFhoRk1jNThNZVYy?=
 =?utf-8?B?NjY5VGxVTndMekdvdUlTOThXTGVNenBzVGpRL0xZclNZUzRJeWhpL1h3NTVD?=
 =?utf-8?B?YU1tOU9GTXBhN0dRdXE5U3BhU3c1SXF4dzdjSDYwaWdrL0haY1A5WXpHWFNV?=
 =?utf-8?B?RWM0c21NemhzRThUR1FpOVJBUVNhYXV1bzZWd3R3NW5rTDlqRi9QcGVEd3Yz?=
 =?utf-8?B?dzllaC9KNjNkOHNDYXF6aUdNMGZlY0ZGd0lLSDN1TDFUeDhRWWp1TnpVb1l0?=
 =?utf-8?B?cmhVdXpISWhMalNmd3EzTnhHWmdJaUdOY1FjSFBjQTRlbkpScGQvZXJSVXg4?=
 =?utf-8?B?Q1h5WWtYZnJQUHNjVTFHeXhvVkhFN2J3UGFxeTQrSGs0a0lLMEMrMXFlb2R5?=
 =?utf-8?B?ZFYybWhja0FWdmk3bW1FcTgrd0QxZXR0ejRGTlFIUGl1Mkx4VFVjOGdNVjdW?=
 =?utf-8?B?Z1dTT0VQZmxjVkxXUGxJeWRHSXB3VVB2a1hONGNRdjV6bUJuSTFMa0xyZFlD?=
 =?utf-8?B?bVhFZHBaRDdOSVV0aENMa1JkbWdac3BjUmRUMWt6eHdYQlUrY1E2czdvQkNq?=
 =?utf-8?B?eXdDblk5dUJPejZBcHJNYzh1TmhZZXdhcC96Ni9YSEx3a2w1ZEZPY05SbmVw?=
 =?utf-8?B?Ui9oYjBaSWtNd2FsejlhUXBCbU81QzJnanlDNXJKZTVaSHhrODFTTHpHMmRK?=
 =?utf-8?B?cEhHUHc4OXI4OURDd3pBM2xSUzRTZHQ4Y2VTV1hTR3dNWWVyTHh6d0o2a3F4?=
 =?utf-8?B?anN1OW45bWtscDZoaVptNDJBRFN2dWxBSHMrdmlJaXB2Q0w1RVJNclM5cjBr?=
 =?utf-8?Q?x3aQ=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a0d1ab2f-92cd-4df9-21b1-08da6118f913
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2022 19:35:11.1924
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR09MB6095
X-Rspamd-Queue-Id: 4Lfk5F58tWz3SJt
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=XMp3Ucr+;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.89.51 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-4.40 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.89.51:from];
	DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[redcom.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.89.51:from]
X-ThisMailContainsUnwantedMimeParts: N

PiAgIEFsc28gbGF0ZSB0aG91Z2h0Li4uICBkaWQgeW91IHVzZSByc3luYyBvcHRpb25zIHRvIGRl
bGV0ZSBmaWxlcyB0aGF0IHNob3VsZG4ndCBiZQ0KPiB0aGVyZT8gIElmIHlvdSBqdXN0IG1lcmdl
ZCBTRC1jYXJkIHVib290IG9udG8gd2hhdGV2ZXIgd2FzIHRoZXJlLCB5b3UgbWlnaHQNCj4gaGF2
ZSAidW5leHBlY3RlZCIgcmVzdWx0cy4gIE15IGZvcm1hdCBnb3QgcmlkIG9mIGFueSBwcmUtZXhp
c3RpbmcgZmlsZXMsIHRoZW4gdGhlDQo+IHRhciBqdXN0IGNvcGllZCB0aGUgc3R1ZmYgSSB3YW50
ZWQgaW4sIGJ1dCBhICJyc3luYyAtdmEgLS1kZWxldGUtZHVyaW5nIC4uLiIgc2hvdWxkDQo+IHdv
cmsgdG9vLiAgSWYgeW91IGNhbiByZWFkIGFueSBmaWxlcyBvZmYgb2YgaXQsIEknZCB0aGluayB0
aGUgZmlsZXN5c3RlbSBmb3JtYXQgd2FzDQo+IGZpbmUuDQpUaGVyZSB3ZXJlIG9ubHkgdHdvIGZp
bGVzIG9uIHRoZSBwYXJ0aXRpb24sIGRvd24gdW5kZXIgYW4gZWZpIGRpcmVjdG9yeS4gIFRob3Vn
aCwgSSB0aGluayB0aGVyZSB3YXMgc29tZSBsZWZ0b3ZlciBjcnVmdCBmcm9tIGFuIG91dGRhdGVk
IGluc3RhbGxlciAod2UgaGF2ZSBvdXIgb3duIGN1c3RvbWl6ZWQgY29weSBvZiBic2RpbnN0YWxs
LCB3aGljaCBJIGhhdmUgbm90IHlldCB1cGRhdGVkIGZyb20gdGhlIDEzLjEgdmVyc2lvbiBvZiBi
c2RpbnN0YWxsKSwgd2hpY2ggbWF5IGhhdmUgYmVlbiBwYXJ0IG9mIHRoZSBwcm9ibGVtLiAgU2Vl
bXMgbGlrZSBydW5uaW5nIHRoZSBpbnN0YWxsZXIgb3ZlciBhbiBhbHJlYWR5IGV4aXN0aW5nIHpy
b290IGRvZXNu4oCZdCBlbnRpcmVseSBjbGVhbiB1cC4NCg0KSSB3b3VsZCB1cCBtb3N0bHkgZm9s
bG93aW5nIE1hcmsncyBzdGVwcywgd2hpY2ggeW91IGxpbmtlZCwgYW5kIGl0J3MgdXAgYW5kIHJ1
bm5pbmcgb24gdGhlIFNTRCBub3cuICBUaGFua3MgbXVjaCBmb3IgdGhlIGFzc2lzdGFuY2UuDQo=

From nobody Fri Jul  8 19:24:04 2022
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 E6F21180B71D
	for ; Fri,  8 Jul 2022 19:35:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4Lfk5G6wcZz3SJv
	for ; Fri,  8 Jul 2022 19:35:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657308913; bh=UyZ4/oMAQnYAgT/V8ZqouIBOrHl5A9WSSuzEIwIXr2E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OEpjw2xpkqabd2T2de5jdxEcTus2d3K5sITmALomPWrp/Elap3jodbVnYqqdAYFNd0XjdbHjNeukBKIgqgpPyQgC5INmROgKWbSTFfb33naEEUNiMvbPRTAufZ3lS9zUmqE4KNWqmIHq8Wuql6oS7jF4HmSmKDcG56Q0jCub4YpTd9OWUCn4Q/PlUTc8eHYXKNPG/VNS0yeYpbAbu2qttbLbp8NS3MzvGKMhTxJaw3bcupjkl3gU4VRfusPlDiaCp6L6OOXVIW8gvrxrgVno9JIvIp/fbHM6zczu6H+P/r7VsR8oTLm9blMlnoV7rLbOJVf9O9z5Bn9hKCSDFCNsiQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657308913; bh=GEMTPss7LzEdRZP1ewbYevTHS/9HqNW1HEFcXHJ5Qbz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MvbIRGlZ+SZDwaSfQXCl086FBEeR9Ez5PGP1TXxa6A6ajXxlKaBTQTJIH5/eYkwhghArvonbHKPC+3DBmvEfdQa5gv40grTx4HrzfPXYUe3CDWdG4YvinCy73CNT//5/X1B6Eey9anuyYwAsKJG06s90QWQKvK0y/FsHtE9mVauHmtCYaze/qStDUVg6cMhdDlc5HwpgmDilbsdZJYRexq8XnIq+K7qUqZrrCeS0O6simykytkYJ26993uQ1wpVHErZi5nlgtHWNEBI9XNgr+9eGj06+9OiY1RCVoObV4Fwm9abS2R/RYT8zDbTczJsfKoIYetsRWWcps0WNryu+TQ==
X-YMail-OSG: aPNCMnQVM1mrLNeLwNKLXvrxb1xAk67pKHkalKSqjfAoyUF9fhfC1aIoScBx3YB
 L_tWCYCrCX9eI44D79Boh9.dICU0dTk6spT2iWAF3N2OhmS.u.JAfb77Az0493.1jc_kAFJYV6EU
 x_EEXlSBHM1TIm39i6MplxWoFM_PbtV19A6nQ51UJXLzc9j6IgqGC8mqB8ZmwsUWcvnO6fRRJNYs
 rY3CJ3McIj_G9Okg1j.THSQGjvQ4vYEkkBs3BmpyU7kQ25I.necxq92BeAqWffFV.jak0W9g0Z9s
 SV40g6yCUwqdULsg50TLRukejA1RCPxUJk_eLkDicWl_nq_h0lSZOylxrCGNpTlB6uwTfB.XK9ox
 i1uho5Vxvdpxs0gCki7sD0JJQsI8XsgHBmTUFQUIpErWOgI7zxuDqgG.GWerMMKU4PGnxf_NpM98
 pPpmjh9EoKrVRobmgL2As2e4WE2gNu3AUhZJ77NXCuluoTRjz2_3PsgNNteCp2Y_VhlogwE6To3U
 EooJj4hR.PHLR619QKjE3D8G1OGtKzbi6LDNL4Htf4gMRDsYJ3neRisXfys0hcd3K1Q.hxh5nJJ1
 4MA3cH1ri4bzP1JmQLsY2HfuaMHaknmNhNkPumzaDjlCXbECwSgVprzlPsbyEMSJs0gvrv1PhbBD
 3iRvAmckc6wheQRCW48RW3VukzbHiqkPzDuhBexhcMmb5Nzkw2vPrPD4Ai82ah0hVoEaR1WBYytG
 Ll7fHGR15Uc552jEEt_7TD475A6k9gLvpjbIxSBU8NuFfjx_7ArOD2.b2E5lj_.ZT2FSMRyLRcsq
 PX7yKCsO8CEPYKRgbLnS6nHphD0b.IgUD5lGXeEDSQhmLG.TGoA6y6W9gbL9oCo8AP6HaF6nsN98
 wuASpuqTROKZddhuvthwxjPy_Lykbx2A0Fbct352f84040kT4azmIXfIhZFGXNC4gvQyQYGhLOQ4
 4ZzrkzitRBpjeW_XHdkZt6_cQorNyIml4txZM7p8mbO8el1o_pjFE_gujp32w6WhZueVIyz4mtpz
 QCvRDxDXnwIAvDNEAEhl4KwTQyaZWnUw.RbgwmxXKpsMPF33fS6jmkjBX7LH.ADihc_bw_O2mF08
 ak6zAlJTlILhDujAyq8gUvcY4HMODFhH1pBh2z9z6ZJidkpM67jT1M6hj0KqkNd5BUw.tT1AXMXG
 oVFQmXp8tQQyINgOABtrnIdgrGleOUjD8G0lKr_mamhsStjL9YlQicBSIeayu_fhwmVS0CWUWRIO
 .1yWdLj22GwbXF18V19yhrOM4321KZutHBXMQzM9JlUs91lUlzFvrXFhEJ4_M.uE2WCX3C3zrSbO
 6LhNNoeQxidIOS8p0AUl6Dd1zRCnrF5R4jaI5LDT.D5c39bVaeZn7p2OjkG_8f5Pwhd4DwAYp16F
 AUKLwx66FdKopAzGSp0LewW9AeTZRBtOtX_Mfk6ywQ71_e5.wFhYrf0SPRVn37_xuoaVPZDqw6cl
 3K00g0pqZ2IM.KIJcchIo10mNWFC0ZPGlp8qiwtMwHK4oLBtju9b0xCPB6j4rcWPfozAaIcnJ_zS
 KdtTZmUTU3WOOU_rFrg6sidsPXkM8JHlVjouUV_qpjMba0EEsnOb_zalXDGUGlmsbrAqm49hLCJd
 AYSHvM19dFeu4RLF53p_p6inr1trYFB8xf_HSUqilIMAwTns2JvqZbasIzsPpP5ZdqJgkTsfiBV7
 YrMkaJB92hWLdOIXlZZ1hdLNXFFcW3K.qHWPf9Js9QRE2k_J98rugvGKZ0XfcVegzB3QBUaLCD44
 vks2f0Kelo8kcdZPllaVz7pLeEpIrVq9FA2iKITpx867VucO0IlBfPAddJgVGx93rMznut7nwYj4
 EP6F2OsStYPevADg1xvSNEJG52RIu9g0_1u4xFMkuyn60wTZtGTqlEbOKUTeV2kQK.oZvlym.I2r
 vfNp_MsNDCoy.OZ7kJmTB0bS23eeNu68R4Mt90WkG9pFQ2kVi8jXXUQPqTnCy1Sg3.7tcANrp1lV
 9vrLyVOE1d9M968eOZbk8JU3eXCEapbTMitFCDQsr9tVT028gjX4pBJfJwXeerXbnHlEJ9gSwiMb
 oq4XeoTP1WuXRy2TEMe6dbTxyZNJ.yic10LjgHiyaL2IDL6RnLhmqx.fvMqaHsIRzKBALGHa9Scn
 mCmu7bckx_J.uNz0l9igOs8VMCt.EpOT01aCDh91m6qC9rkTDe5Zmcdw68n6q_Jox35BSg4aGZ63
 7cZ9IJMOyFPEnNuD9L2L3gNJjTsnRDOT0K8gTp0TIgJIM.Th89YVKDDXfHsFBLED.7YC69VGLA1B
 eJJy2I.p3oMzcZRf3aJAV32mtRB2L0tItQDfxBvVpJSSJTrjIANzIisCDU.zH
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 19:35:13 +0000
Received: by hermes--production-ne1-7864dcfd54-8q7fk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e9c4dd6996efce00531862001c3e320e;
          Fri, 08 Jul 2022 19:24:06 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Installing 13.1 ARM on SSD
From: Mark Millard 
In-Reply-To: 
Date: Fri, 8 Jul 2022 12:24:04 -0700
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "Wall, Stephen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lfk5G6wcZz3SJv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OEpjw2xp;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-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];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-8, at 10:40, Wall, Stephen  wrote:

> I am attempting to install FreeBSD/ARM 13.1 on a RPi4 with a USB3 SSD =
attached.
> Steps I=E2=80=99ve taken:
> - Used Raspberry Pi Imager to set the board to boot from USB first, SD =
card second
> - downloaded and burned  FreeBSD 13.1 arm65-aarch64-RPI image
> - booted and run bsdinstall
> - selected ZFS
> - selected the USB SSD
> =20
> Installation ran to completion, but when I reboot without the SD card, =
I get a =E2=80=9CFirmware not found=E2=80=9D error message.
> Searching the web gives lots of results for linux, but I can=E2=80=99t =
find anything for FreeBSD.
> Has anyone successfully done an install like this, and can point me =
toward some resources that will get me straightened out?

I've somewhat generalized these notes beyond the
aarch64 RPi* specifics.

Various devices require more than FreeeBSD installed in
order to boot. aarch64 SOC based examples include:

RPi*'s
PINE64
PINE64-LTS
PINEBOOK
ROCK64
ROCKPROD64

These need to have RPi* firmware and/or U-Boot (and
sometimes other related softwaere) or other such
(e.g, EDK2) installed as well.

FreeBSD's installer does not deal with such non-FreeBSD
firmware/software installation: only with FreeBSD itself.

The FreeBSD project prebuilds images for the above list:

FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz
FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64.img.xz
FreeBSD-13.1-RELEASE-arm64-aarch64-PINE64-LTS.img.xz
FreeBSD-13.1-RELEASE-arm64-aarch64-PINEBOOK.img.xz
FreeBSD-13.1-RELEASE-arm64-aarch64-ROCK64.img.xz
FreeBSD-13.1-RELEASE-arm64-aarch64-ROCKPRO64.img.xz

(Some or all of these are MBR based instead of GPT.)

The images are available from the likes of:

http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/

There are also ports for building U-Boot for other
SOCs/systems. Similarly for providing the RPi*
firmware and related that FreeBSD uses in its prebuilt
images.

In many cases, one can use one of the above images
expanded onto media and then replace the U-Boot/whatever
with U-Boot/whatever from one of the other FreeBSD U-Boot
ports. But some, for example, U-Boot's may not fit in the
space some images supply. So picking one that does needs
to be explicit (presuming one of them is sufficient).


None of these media are ZFS based as far as I know. That
probably goes along with the material in "The Design and
Implementation of the FreeBSD Operating System" about ZFS
(pages 548..549):

"Like all non-overwritingfile systems, ZFS operates best
when at least a quarter of its disk pool is free. Write
throughout becomes poor when the pool gets too full. By
contrast, UFS can run well to 95 percent full and acceptably
to 99 percent full."

". . . [The ZFS] design assumed that the would have many fast
64-bit CPUs with large amounts of memory to support these
enormous file systems. When these resources are available,
it works extremely well. However, it is not designed for
or well suited to run on resource-constrained systems using
32-bit CPUs with less than 8 Gbyte of memory and one small,
nearly full disk, which is typical of many embedded systems."

The RAM and/or free disk space constraints (for example) are
likely still at issue sometimes in 2022, not just back around
2015 (the Copyright year for the book). Thus the bias to
UFS-based rebuilt images.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 20:01:52 2022
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 A39A53E1840
	for ; Fri,  8 Jul 2022 20:02:06 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1])
	(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 "fuz.su", Issuer "fuz.su" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfkh90GfJz3XrB
	for ; Fri,  8 Jul 2022 20:02:00 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (localhost [127.0.0.1])
	by fuz.su (8.16.1/8.16.1) with ESMTPS id 268K1qT8063649
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 8 Jul 2022 20:01:52 GMT
	(envelope-from fuz@fuz.su)
Received: (from fuz@localhost)
	by fuz.su (8.16.1/8.16.1/Submit) id 268K1qPv063648;
	Fri, 8 Jul 2022 22:01:52 +0200 (CEST)
	(envelope-from fuz)
Date: Fri, 8 Jul 2022 22:01:52 +0200
From: Robert Clausecker 
To: "Wall, Stephen" 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Installing 13.1 ARM on SSD
Message-ID: 
References: 
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-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lfkh90GfJz3XrB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su
X-Spamd-Result: default: False [-3.26 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.96)[-0.957];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	BLOCKLISTDE_FAIL(0.00)[2001:41d0:8:e508::1:query timed out];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[fuz.su];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi there,

Am Fri, Jul 08, 2022 at 05:40:23PM +0000 schrieb Wall, Stephen:
> I am attempting to install FreeBSD/ARM 13.1 on a RPi4 with a USB3 SSD attached.
> Steps I’ve taken:
> - Used Raspberry Pi Imager to set the board to boot from USB first, SD card second
> - downloaded and burned  FreeBSD 13.1 arm65-aarch64-RPI image
> - booted and run bsdinstall
> - selected ZFS
> - selected the USB SSD
> 
> Installation ran to completion, but when I reboot without the SD card, I get a “Firmware not found” error message.
> Searching the web gives lots of results for linux, but I can’t find anything for FreeBSD.
> Has anyone successfully done an install like this, and can point me toward some resources that will get me straightened out?

If I recall correctly, you need to once boot the RPi firmware from an SD card
with a specific configuration to burn a "look for boot loader on USB drive"
flag into the EEPROM.  After you've done that, the RPi can then boot from USB
with no issues.  You'll have to read the documentation of the RPi foundation
supplied boot code to learn what exactly to do.

Once other thing that bit me when I set up my RPi4B: when you set up a zpool on
an M.2 SSD mounted in a USB case, you might have to manually specify a 4k sector
size at pool creation time or accesses may later fail with strange IO errors.
This is especially annoying in that the error only seemed to appear starting
with the new ZFS code in ZFS 13, being absent when I created and populated the
pool on a FreeBSD 12 host.

Yours,
Robert Clausecker

> --
> Stephen Wall
> Senior Staff Software Engineer
> 585.924.7550
> [cid:image001.png@01D892CF.B3756350]
> REDCOM Laboratories, Inc.
> One Redcom Center
> Victor, NY 14564-0995
> www.redcom.com
> 



-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From nobody Fri Jul  8 20:10:30 2022
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 AA9E13E2CFF
	for ; Fri,  8 Jul 2022 20:10:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lfkt54jzMz3Ybd
	for ; Fri,  8 Jul 2022 20:10:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657311035; bh=e5WtYSSMXHVaCZaAEMqyZ2t38muodj57r57kSix/mho=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=efRD6fCaoiQGleNaWHs+auqqY3YnT1+aosAGs6Cm8xXiXjMETtnGd3GPuv8+mK+YkwURla/8P9cDBoYJn+vfHjM3U1xcnv4C07NDoAlwzYkCStCUM+SVUvzoBf0N2RBi1I1jHQy4us3pmTkxaftcTKdhAeq2DOAa41s1P//7L5Ir/pNS3CU9kwibByN9BbePDfLkiuuc5m3sadb0ce4ttO7OIxjFrfhDiqcvod3ETtRx5yfUryMsDkm0cB0h60ONbrL7NTT+hU0iDnQtWLPPy05AzO1UU+Ks1cYPncMN1z3hPkoUP0ZihjnhEfMEEnRROkXkPWOtmhCCG+dJ1LNCBw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657311035; bh=Zz90HbpYY+QGUZclcv0DKm2Td90I8zeWMXDPoh2Hyfe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qGumCmh3Wa/Mxf4UBPmg8qgZEusaMnM0yQcW7qE778S2wla2d7il87Rr/dJBMQmVFjnriUURuVRMYvVbQrLbSYmYjmT3yGPDj93a5VDBZOBKJTU5zTtwvStrWkkRl1o1BcKMLO/gkx2gfEg/IOFOWi8J0TM89l+5mCaGlEo+NVbyD2AWlkbOEJVAyrzuhK+6CHxwoEzXI8UEMez0lZkCc/nJuyGO5npKAGi9Wi5Viket8c71g3OJMwjuriCeO5nPYXU+n2QgEIV+5ubeeM7uctTr1XDxD1ePHRxmHtwbVuf+VVGT2qroRLRcZytVT9JtQIDzA7UGSjP/t2WezvrPFA==
X-YMail-OSG: mC2_xHgVM1mFioByBarA83xHod30Gw4QAokNdUhK4I_GLS7lKUIp4ndE5vFK4qe
 nywUiL5pFkURuDJHLrLR2RT2h4EcF4V2qXx.ZEdgDiU62ZOV7keW6bCNEvARpqWQHTpmr6RVGaqj
 irli7Z2V20sZE2t1haFZwn.GH60lUmc118ZJl2xAmjxyU8NJDLQpkYWi72CWhpnSYuhQH5_R_xxY
 vbfjC814yoCDW_k4IZUl3ARaBuTWYE1xQdKv8y4224D9s4jMRHYn_gpzNEEDB4MR7L.111ACP4o_
 IUMV8psjOd6kF8uC.OS9kVH8d0o1.Ntuj8nvp5Ylc6f0nrtxnTTM5XSfhqcssIsFxVVLPqmKOi_P
 ntN2pddn9vPfgYvKzmKgc.e2YS0CTKdL4fJibTR2QLpizPVx1meGNHo_ZD1G6Wc0TlPsuSp33Jh.
 KEcroAAi.TR7tfLwUvHAntUUEEyuAlhpiQ5fepF9wsGvmxTueyJm3BqeLs_t0NnG.z71cmpROSJE
 himKtGHjIyUUUn_vPS9Mu9RbryHi0evollu37U.ZBWKJQbBzHfP7ymWXNErJ9WAKmy1B.IfGPE7u
 GhyZ1z9kBpGg1fk_6HEtXIsyE1KYAm9KVdsuFCCa6nFCavzrZuYxTDa.CMzOwpozQ5wrXj4_7emw
 7OAZc8lj2j_AwP3paN5YYedKq2R9zbcXMa9eskXhS1I3Ik.OY32vDMXdHvAwhEVopVKseTIrJREf
 X3L.3rTyebwQeiO7CpKX2Q0WBzmgrl_0imfzF0fpBXfMgQz5PSWQXVbLOSc3SNEgtsSU_kdqNlSE
 dHIsV6C40Dr5qOyB6kou5pU_8wZRURP.bPo1ucylTaEN3km.u2m9yZdFvXLUMWqqHYrTzUgp14ef
 5EjcFP.qTx4bGjMXjPiv.o7DgAvXe1zhPlWV2SMFSJjRw8iglMpCjRDfZAF1FesYT8Ijky0stQqu
 fluw6exdqi.KLAecXBZgXuigm7wOmoFeAkeLbpl5Ppbhk4TOsf277rxhndcDnmbad4pg1HBXUGyB
 AVHIHxISzSkLa7NurcVQdjev9a2vtzJ95aHWwMI6B5EKeO_PrLIQibjFYjwY3iR4_c9zOE.j1tWd
 QyMTv6lawLjxZKkTV573MkZFMyqlOFZwsbkaF941L2uxIWYlBpj7e7m.zGYiamyPzeZOeUumMIJR
 UWJlEfN3On2zcncK.c0XbABuJOBja_6P0e4ir3rKujtFwlTSvRYsX.FTVL4bV3jxCjwaN0DkjLsu
 ydHYDShBPq8HpRzLbCDQy5WI3cVQPTaqcQFfvMUbanVKNtVgFfVZBuYHOQbZj1hic03T8L5OYthD
 uaYRyNd0G_BhH3sIHWqbGPt4XH_RBRoU4ouIux3dfe586gIwjs1RVpSvZ187lsHBRePhK8mMJUnz
 VWEbXsf2i1NcBi8BZf4f.dPce9dsEi.k3DaRr2MXYjHh7_mHJ0JgddhoAfegAi9o0YdiFBY7_N3w
 jKGegzHtG1Ju0D_xmUOYZw4vgATv5GNYDcG8DFQxrRpST8tJpd7b_2cg7Uvc_MHIGMUkORAlqn3E
 OKJnoe8l7Xeaegi4E19pi_8FQ8omkLPNC3DswEONX43ClSuS8YvibH4PFm1E6Ry1zGs5ncgPARLf
 nF6iAL.nQJVm6iqxutHwg9yM4TRnbsRJdcBYk8rezw8xHGskqk3VC8dViLfHz1U4.GrjHvhsE_0a
 luPQo9EpFRKEGdEC8rvKIe43A7T3WT3ITszMCErKfFVWprmK_eJ1eavUhh2CXcwUguz4P450RuUx
 5P03k7moCbrItGBE09_vIIC2O.2bTj1MUOexzaJvm8WgBtKNCCSYLmSoWgYSttjN2LTfxitV5beY
 2JzbgckX5FrR6gO.Pw_2V7rmB8ORnuS.gvPkYvrImQf7ONst35gxzVrZvbCBTd1EV4e74cV0KO2d
 6Iql9DUdDhCsWfMCOOKV49I1bRn2sSgULbWRPIgPfA1n0jBwXX9QsKkFKPhAEY.bRMLgZPlRBTQ8
 wNB76P1aIXfv26KnP1b_Tpxh.XPSqAqwtML6h2mdz2e7FPAgm7Cmd2EzMF6PW1eStxsi0WvxuB8D
 up7s94oczzd175oGMd_vXkbHjZ2rjDX1mCJXMjgEeD7yzgtAmdbbEMHJe_wuA6q4Pq7r346gev7f
 hEORGRfa2STQdI7kTIPUBamKMuyb5gK07sRJn_UbGnQKHx_dU9ZxWGdUZey0x4ycqrMomlEG.zl_
 WKb5eo5P8iGsxNI9388pltq4fbWM5wDmSG1_q0SZYIO44peeyB60vR2PdPhART21npyyljN8XgMo
 0G0w-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 20:10:35 +0000
Received: by hermes--production-gq1-56bb98dbc7-z59df (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f0932effc9e51e414cccb445a2cc0ce8;
          Fri, 08 Jul 2022 20:10:31 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Installing 13.1 ARM on SSD
From: Mark Millard 
In-Reply-To: 
Date: Fri, 8 Jul 2022 13:10:30 -0700
Cc: "Wall, Stephen" ,
 "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C93D01D-D316-496F-B1E0-B374C7E3CE88@yahoo.com>
References: 
 
 
 
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lfkt54jzMz3Ybd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=efRD6fCa;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.998];
	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];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jul-8, at 12:15, John Kennedy  wrote:

> On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
>> I tried something like this - I used rsync to replicate the SD card's =
(mounted) msdos partition onto the SSD's (also mounted) efi partition.  =
That got past the firmware message, but then it stopped in the boot =
loader asking for a partition to boot from.  'zfs:zroot/ROOT/default' =
resulted in an unknown partition.
>>=20
>> At the moment, I'm running with the SSD imaged from the FreeBSD RPI =
.img file, and that is working, but it's UFS, not ZFS.  I'll give your =
steps a try, and if I get nowhere, I might wind up creating a UFS =
partition for root and boot, and make the rest of the disk zfs with my =
desired filesystems.
>=20
>  So, bsdinstall should have set that up (zroot/ROOT/default).  =46rom =
the
> UFS disk, I think (off the top of my head) you can just do a "zfs =
import
> zroot" and then you should be able to see it (and everything else) =
with
> a:  "zfs list -tall -r zroot"  If you picked something other than =
zroot
> for the pool name, you might need to do some more tweaking.
>=20
>  In my case, my USB disk is only ~256G.

"The Design and Implementation of the FreeBSD Operating System"
says about ZFS (page 548):

"Like all non-overwritingfile systems, ZFS operates best
when at least a quarter of its disk pool is free. Write
throughout becomes poor when the pool gets too full. By
contrast, UFS can run well to 95 percent full and acceptably
to 99 percent full."

So, for a 256 GiByte USB disk used basically just as space for
one ZFS area (so nearly all the 256 GiBytes is available),
That would mean being careful to avoid having much less than
64 GiBytes free on the media: hopefully using less than 192
192 GiBytes of space at all times.


> I don't know if uboot has any
> BIOS limitations like old x86 did.  I've never had to be too wary, but
> then I've never had BIOS-breaking SSDs laying around to attach to RPI.
>=20
>  I think uboot has some commands that might let you do some zfs
> exploration, but hate to point you at web resources because there =
seems
> to be a huge variations in what we end up with on FreeBSD/RPI.  My RPI
> is a few hours into a firefox rebuild so I can't give you some real
> guidance from what I'm using at the moment.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 20:30:55 2022
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 8A1223E62A5
	for ; Fri,  8 Jul 2022 20:31:07 +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 4LflKh0grHz3bv5
	for ; Fri,  8 Jul 2022 20:31:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657312262; bh=yjzssn9Sb2rdRKqps5igAPgVp+75zEYuygg4iZlkQwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZO4NXw2UPI/zFO6FXpLFiM5yZo0T3rmWYBI4S1dgyxmLQRYM/a/75zSJnW+1gSurs8Ud8xD7wc4DzGqpLwKAVdSn8Qv8/STYGtfXDOrkW7/1r6Nf5Tm/RwHX6PnuQT4EWWaM0fR2aAAPzg9eQyKK4ap7rgOr6zM93P0KgHteLzRzsOu58ywjUCrC5tXCNTSR/1lYa06CM+n2xtFfEMuCNWoqnPsXbJJguZS7WMCi90KKnLC+uvj0HsM1ghw8RiIyfCY6WbR2OIKGR/emosDh0agFtMl9Z/0nGvwUebfhu0dG3zATwR6yuOTxJk2eC2IK4Ly962nfyNySG8TZnAFcfQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657312262; bh=1MpY1ycNZ1SEDlp4SHw7fgmwf8fhk5bW1KVMavmr2Is=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qS08CwVX6aEuc7x/v2pq0iBymdsqp4122fnw1W7vwAAHaUADSk2KLHC135f8kj3CVTsNomIDnM7Jp1yqx9GifD39ptWucS/dWghw3nGDvppcUF/eu61DMV+4vKhaXLMdK7dGpOUVISnr9yMslAMSdUxObe/hpumA0MapAOJAkKlnB3x0WmwFCZ+vnuRjH/vYEuQXyPFlyWns5i0dTa2WycrHEa6VudINZcvIV5xrMlN6tyZwcEvqqhdgwUloDtgr0gXgIAN7UoUZ2fxl4varTXUaRLJQv/rxyLTb0AtolvhbFqyd5VRC++wGDcaNv1DupNr66PffIfsv5Y5G+1SB/w==
X-YMail-OSG: 3MnlU6UVM1k.XT7sxVn1fXemJ4Il4r4VM9Nl3X5D6bGERt62WuUDRlOygTum20q
 YnfrMnY4bHJLJNVao408Sr_FLclesFgDIvcnucw6tqwEUIsXdhP4u14SToFHEPQvmQY17NRDJCus
 to6heyEF_MF9O3xnAJl.EEhIK1uus9Y84pokadTIkUjfxzbtO9DuS0lZA4GEjO5XAz5ygjaaCgpQ
 C.t_SbVm6_137UKz4ZPekx7pUqx1URDUMAPls4oOWYuRqIF4wDrhJ4rczDZMgmKtbcj1481S7gxD
 PwkFQZLQjjPyDmE0CeaTfaqLY2jiiU0YknAfPau.Y7a1HU.arZOjjPDj7CtPLRDplhl9ISBwA50i
 Y0fmM2.06Pg3hAmswDiTgAI4sJKQ0mc2TZ4Kcui6yEFeBdPl94Tc2YbHkUEq55OfABDBdBc.vgW8
 EUXmrXxcuwTKQpznJBcrayrtZTZvPI9gMZkc7HxJKn.m4uDxWOiikUUesblTPp3iV5uwodAZTJSN
 VxufVHtUGZZAwFtEah124wV8FkzP5yYdMeLTJU1.4KL6aCZeikfULI15cpCWHYyqrZ0lucq80B5K
 .v3.V1rrkFGW4H0UpJEk04W7Go31Tkztg_22CRRKWKBw0wuAJYOTeFuxJ0DLs6r15jXPKrPIHVLj
 eD82ESr9e_C6tQbbWO5uWcyy8I40qY8xdCqBt1TrdpAI59jmQdPuSKLgiQnqOKfBTLih_QlveJDD
 U00sYhG1qzeMvsw2k9rUx9s2Z10dMXOYqjQpCRlNlZYE4usaGSyvUQ2jBlxNnb9e70BVTzLmh97L
 xd_VlP8d0dHBdI2QUJgCehqdG5afT4IquUvJuLAHcRzZAP3v5.46S7TcqSDwlEoN75YcClJIDT8z
 EAv4jed84.Af20fJS7UV_ksy3DSArosC30swKvSe3SzhByqlzVw11xapdiMvkp_3DYyD9hCCgI54
 kjHFgdrVjKaZA87SuioNe6dkjXnhYV_.6RM5p7CvYMNeLdE_jxg.YuWUUwJrxF22yXYFAWVlAxak
 L59YmulAxiILb3Li.hKC43joCIVWbdpMEwxQz3jNwHUsPSuSQeC8MyGgRb7n_bjF43z2Uw.rP2os
 I1fJ3WLBaKmYn9OFzldPrvJRafCQ7eSp_36d__NbPYOQMYkpU_TlV6NLyQ3tS.GFkwhlcThr6CsV
 76tbdxCj4XRna6nevENnS7WhNtnR22_ZrJ9djDTBhs7uClbISNFkavcrOdujDObtKc4Hprh19ytp
 mYhvhIMM0UT8H2Gh7scOI0p8AIzRuMMiEDFpiy.Lmz8Pg2QeHC.Wa5DYss6vqu1gkT52W3.6ani2
 OisSMgKfipv2L.vBoxKOCsuKOfndt5wKA8CO7eYpTAAPxqXCf8x_yU5MPJuBm_w.BUCTwnjOUNP.
 agjVChJ5bdfdUNwqqX2KPfBUzdJZfzmB.PHX83JYi717dw5JObpwwVI3oIUPkDhsed93EKS7fiak
 Dbz7J7lb93qbWf6BdUcOuOUB.U4ArDVIJLL09vvV6bmqm7P39eedPmi8J9dnnRgXsmsdilZRHAoE
 VhWWugNqJpO55i95UOKJQg3OsI02Zxw_QPNv2dF5Pr6UK8RKrnwgFDtsaZfcXdtn.lRdAvM0fYvb
 owKUXo8CGEfyQWL_TeKu5cIgzQEQQgCRG8B26jHgnIF0zbaN0akErC9m.jO7BP1qRngd.7O8eSbU
 7ZgxVlR6u.HrJ6TGbXnNoClhXK_GrgBEaVHtAJ9FXGkSAWymGpwvnd9SWarpgsqp1ZO4KhBx.FoS
 tYXUprvjUHFHqiRBKT9W18veVo1t4MozjVfbVmUYpPNh9fUp3CURLa_hbFRiuew2sGohGpWsd43W
 pR4CxS_9gqeX7RWFACXP2GyewucYWEdBUyp4r0KwDRuYReYKIK_8y1FBBQ5czYM6a1UBdI5qt9FA
 FN.CRsrik39SuNe1PmofuW8G6X09NvzuvcLiMhidimR6LdLF.aEdonjGjRhz8RvI3k6GdMdnFp51
 D8CsZuqHnKiDbIgX2mpdHDyWQ7GqucxgAwOdPFqqEN_2.TVpsbAsAu316RJUtF4GMYigULSpNzlx
 IiQTkjKYP2egGX7kWmGihmuC4kX_5TPxcDtyCOh4xaaUQFXRhnWGo.U7C2rt1BliS9EjVaz3MpmO
 FkG231Dhl9tcIec_wuigY77sZOHd6A4tXP9m3bN7MrOeQpWhbYTnFsMXdj11OMBNS0bZkv9CGkRJ
 nkq9ZfdfWlg62qkqAfypChgR5zcAamHRxSKmHPc1lW078wihsndl9KNu_mxMy0v.fmYcnSXSV6B1
 niWYT
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 20:31:02 +0000
Received: by hermes--production-ne1-7864dcfd54-zcbtw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 138d1b1409beac6993b4a24e2f4cb7d2;
          Fri, 08 Jul 2022 20:30:57 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Installing 13.1 ARM on SSD
From: Mark Millard 
In-Reply-To: <1C93D01D-D316-496F-B1E0-B374C7E3CE88@yahoo.com>
Date: Fri, 8 Jul 2022 13:30:55 -0700
Cc: "Wall, Stephen" ,
 "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FE6C042-AC16-4726-A5BA-67408DE26739@yahoo.com>
References: 
 
 
 
 <1C93D01D-D316-496F-B1E0-B374C7E3CE88@yahoo.com>
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LflKh0grHz3bv5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZO4NXw2U;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	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];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	BLOCKLISTDE_FAIL(0.00)[98.137.69.83:server fail];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Jul-8, at 13:10, Mark Millard  wrote:

> On 2022-Jul-8, at 12:15, John Kennedy  wrote:
>=20
>> On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
>>> I tried something like this - I used rsync to replicate the SD =
card's (mounted) msdos partition onto the SSD's (also mounted) efi =
partition.  That got past the firmware message, but then it stopped in =
the boot loader asking for a partition to boot from.  =
'zfs:zroot/ROOT/default' resulted in an unknown partition.
>>>=20
>>> At the moment, I'm running with the SSD imaged from the FreeBSD RPI =
.img file, and that is working, but it's UFS, not ZFS.  I'll give your =
steps a try, and if I get nowhere, I might wind up creating a UFS =
partition for root and boot, and make the rest of the disk zfs with my =
desired filesystems.
>>=20
>> So, bsdinstall should have set that up (zroot/ROOT/default).  =46rom =
the
>> UFS disk, I think (off the top of my head) you can just do a "zfs =
import
>> zroot" and then you should be able to see it (and everything else) =
with
>> a:  "zfs list -tall -r zroot"  If you picked something other than =
zroot
>> for the pool name, you might need to do some more tweaking.
>>=20
>> In my case, my USB disk is only ~256G.
>=20
> "The Design and Implementation of the FreeBSD Operating System"
> says about ZFS (page 548):
>=20
> "Like all non-overwritingfile systems, ZFS operates best
> when at least a quarter of its disk pool is free. Write
> throughout becomes poor when the pool gets too full. By
> contrast, UFS can run well to 95 percent full and acceptably
> to 99 percent full."
>=20
> So, for a 256 GiByte USB disk used basically just as space for
> one ZFS area (so nearly all the 256 GiBytes is available),
> That would mean being careful to avoid having much less than
> 64 GiBytes free on the media: hopefully using less than 192
> 192 GiBytes of space at all times.

Corrections: "that" not "That". Only one "192".

>> I don't know if uboot has any
>> BIOS limitations like old x86 did.  I've never had to be too wary, =
but
>> then I've never had BIOS-breaking SSDs laying around to attach to =
RPI.
>>=20
>> I think uboot has some commands that might let you do some zfs
>> exploration,

I'm not aware of the RPi* firmware or the U-Boot that it
loads and starts being able to deal with ZFS of themselves.

The first stage that deals with ZFS, to my knowledge, is the
FreeBSD EFI loader (that was loaded and started by U-Boot).

The RPi4B sequencing for the normal FreeBSD way of
setting things up is:

RPi* firmware (I'll  not give substages in this)
-> armstub8-gic and U-Boot
-> FreeBSD loader
-> FreeBSD kernel
-> FreeBSD world

The FreeBSD loader goes on the msdosfs file system,
under efi/ . . . but that msdosfs file system also
has the RPi* firmware, armstub8-gic, and U-Boot
files at its top level.

(Most other SBC boards seem to have U-Boot [and,
sometimes more] outside any file system, needing to
be dd'd to the right place that the partitioning
and file systems need to avoid overlapping.)

>> but hate to point you at web resources because there seems
>> to be a huge variations in what we end up with on FreeBSD/RPI.  My =
RPI
>> is a few hours into a firefox rebuild so I can't give you some real
>> guidance from what I'm using at the moment.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 20:48:57 2022
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 943B912A9449
	for ; Fri,  8 Jul 2022 20:49:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4LflkS1nj6z3f0m
	for ; Fri,  8 Jul 2022 20:49:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657313342; bh=agclin24pLFfrbr8J2Tmo9QiPl5G3mKV65mhC96DX3o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=L7aU82rBGKVENLvWRD3B8mzaig2EwZ7zX1fNo/XKFdSLPskyQv6Vy0w+qwQye4AcjWb1UQRNEmmuHU0O2mmGwzxmL1oAgWxnsx4DD/GAhyCJCIr1umIBgh2JDaAxuIiVzq0+X4cKC5Y8Inmubt+mDRzhH+xJf/6Gv3Fc4cvSfO/aA6YmPGJyG9+tmPKGYHniGt7ejO776Ow7YhfGtI+2Rh+zY2cT1uFrbvZetRrlV0aRB8nS/1YQ929cYYRFyE4lfst7I44RnzG4Eah6NwB5LlvplTb+gqyTK8N/GIwWqoCYAV1F0PPEkaYIh57qPIW2uzQfdrh3eG+sWlNLPf++xQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657313342; bh=BU575OYQyoYmY/StCqfkBfI4HVKgVE9dgluq9l3EmIm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EXOdNY3k+c4yboX9TD4OZzAiZiGQrzcPEhoxN3Og5fAvReU9nBakvgtYVuyL02cAkfPuYCFEYV2DsnIZbtmb/64PS5RjNcH3Jv9gxb07wa5iF/XsmLQKIRasOLvnlwTFLfVDw0Jl6WOkuskjWerVWgwHQIAWwmlY2GQT4AV57Xv/kmSlCL3oDmjhntB5mmPwH4JRf+ALTuUbNvKCbUrHa//2hjegZF1zX0CTeUodPvQV0C4zcTuqXgwRgAcFVq/Jzdra1k1FJPzP13SPhj4nO6narD/q+JtvfSRpBw9rc3OW4QqzXsylYz2tSbtyrCLXkRHUhtjeeStCAfrTz6Jsbg==
X-YMail-OSG: buO3arYVM1kbPYskvPmXIdq5UfA52Raq_CA._8JQnGGS1ULvJouzIW3H1l2aUhW
 A3r5wlN5MWsXydIeJKhv4zuGvQMRmFRSmqza5JgJMKI27nrh30atKYNLHkuKo0TEu2RgHH9UY8Ou
 gIZk3gNPDjoNhyeaSSJ6e_jTlaKdayunt5kfZjF.W2FKnn8GFwkWQ_5UkhFvBj182QUifasfu9ee
 EgEz_J0o31otsmJrSmX4vh9x8HqBCrLQPw6iBff0PGMR47_FUNLVOi9PjBiQ.dnNr6eVRCHBZ5gs
 CbxomdOZ0nGiGfi2RKDKWY3RMAM5O_WHh4f3lPld8WFuHXfIc2TakVODjZ.G.2b_x9R4BFoudZr_
 QTsjaftbmXpvGfeHNSJP3ao70ELMecujBO0M86HEv8hJabpb6WLLgHdXdokTj2A2.QL95FjXaOmH
 nnyGozzjj.vU5dNNsHb488Y9Ja70rncpN7t2Gw2USN4P_7EE._00RNyUQs54VbR.yohCGO3s64AT
 FFJ1hhJXbTAiK_7O24C5F2lg6dzsbOvcm2obQbtvWSsUUkPpopL1f13Ds7XVmCq35PBB0cYPvQwp
 a2W7nae4XqyT3_V_Z7GLnC_GXXwCDEeqOBc25owZA21bsfv.VLIHnevlvBKOFWPA1o6LBQowjAYu
 vg8KL6vDCVyUQ15Yw9oBGVqiokACcq5EFzS.wdgtZH0tsLXrJlezkn9i876q65koW3M6m.hUdyiY
 J2qSjgBsakXKJ9_VsROZI3keDJoFYu1cYmKxTj4KAJBZvuNsez5vCYTFG9CCNfmQKiauijk6fhYq
 cNASalfYkBFvuXqjMpwmQxdoo5alWzbcbkT9AIsVOTgZVCEJhY6TgfDwqJDd3qPzJqnOW_jZVl1j
 Y8m9YzDk8W1uRhpdVNy.aeofedeNXvU.eVZ4kOmlttGiwKOhvxdtZ75WtPAXTXdwY_RAmG.2VoWI
 jYGdObknUAglhsY1ubBmb4QGgQbEBzugNVmNXDgwm5kr47kbWxY2oagKMTcedhuEjhK9s1uz7Krm
 .953urHDfbMjWSVmvNdEWbcbOWKpp3v0Wteb6ZOxDf_RUnzvi1LVmZYFhD9sUAMeriFNGsfHrIGl
 wyRNRDtCm4ZiJOMLcf9frPudqOf_VoORRhTrh1Hm6gUj7BvN4o2oQvwA79UFmR_Q2vqUu4kbgR9v
 v5qO7Rs.rFW_8pE5gSInSOhoBBTRJqAu5wuezcE7Xa83OUkOsVMy3KIEL0zV2PZfLLEEMjGIQSff
 c2yro5QC2ohNT0qDkXWjFJP3.iflX6g3ZHu6QVYEXvTJ88WZXU2EQYdiZuKmOnEjejMeTuPWXmql
 hpi3BktSy7OSofKSlbnbLuF.lZ7ToWNpOfSIp4e9tb0WdoA4SOT1cKywvnvycEWggR4g9T6iUqXM
 qUK8fnMoejX7sewJvZVSmmXlUkq6bZPdtYlSIMIMYi4dGIOd5iU_CnPRC2xq6SSuCedEP0Pw_vkH
 ekNXejSp8UPXik2fGtd8KkGhHfQF.1djSel24hORly0LndITR8j_ugspORrJ7AAZYAB2_4IE2gex
 Dca_Ssv5gZgyNE0dwSvpXdKIy1YoisCZMXXXv_lQMtjGrjJopcVlhtEgtZDR8QFHgq3.tbsUK2rT
 jwSVBj0yvPWHfnyE8b1NWrYuKtxcWh8FO1_zuKGrjByQVJYuF_7XFb51biqe9sZtln7htUQOoSwZ
 wcXHPm6na94yix.6bm5ovMDENtKt1Aj2xdfKaBzNrceDrL6LimtiEeTMOdkKQAW30UIfNnTxAjvR
 idTQJsFkdKRsZrQHcF54WLiikgOK8ycK2Kvk4IfQ1zFuAqdzs9ep8DPVIyc.byXUxr5Hltn.5_Hk
 sghxX8HAQntDZ3Iae9yQ8_keQYmKmZB0FiUsPX1pONx5KUDQTc9Tm..2gja..tCgdAUb8arz9N.Y
 sR1DoIyvG8kbbqtwq94j0P6D3jzKTeppRJKt0T2gAKTRiXUy_QEqG5fxM41XJXgza5Gk6tMV0XTO
 VOiqb_l7crqWWQ5H5xyMD8aiUWM_BkMiKH6qoU2pCwls0rebX6aqvrzTohXW8Jf2MXhS1DS2EhHK
 OZvT55m8C71CeQADWfDHG0XP0bQP5vdUggVTN7y2tHmdoBEW48YQ0G7Jhp1Yx9ASxpTxp3ckCPuQ
 g180Yr40f_GsBnUBK9.acYi_YdYup_QNgahNH1OnhlRUrUqsWc0rdh87rnNRwwHi2cjm4by95RX2
 Pst9idtrL1JYHQkMJ6_o9FD1DIYkXumfgtJjm4dRAiNRIdtlr1hhtAoroVuJdh9zBjaF2vFUur3c
 dgPKE
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 20:49:02 +0000
Received: by hermes--production-ne1-7864dcfd54-xmlhn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12073faa9eaef87bb894afd05b418913;
          Fri, 08 Jul 2022 20:48:59 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Installing 13.1 ARM on SSD
From: Mark Millard 
In-Reply-To: <7FE6C042-AC16-4726-A5BA-67408DE26739@yahoo.com>
Date: Fri, 8 Jul 2022 13:48:57 -0700
Cc: "Wall, Stephen" ,
 "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 <1C93D01D-D316-496F-B1E0-B374C7E3CE88@yahoo.com>
 <7FE6C042-AC16-4726-A5BA-67408DE26739@yahoo.com>
To: John Kennedy 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LflkS1nj6z3f0m
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=L7aU82rB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.87)[-0.871];
	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];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-8, at 13:30, Mark Millard  wrote:

> On 2022-Jul-8, at 13:10, Mark Millard  wrote:
>=20
>> On 2022-Jul-8, at 12:15, John Kennedy  wrote:
>>=20
>>> On Fri, Jul 08, 2022 at 06:26:59PM +0000, Wall, Stephen wrote:
>>>> I tried something like this - I used rsync to replicate the SD =
card's (mounted) msdos partition onto the SSD's (also mounted) efi =
partition.  That got past the firmware message, but then it stopped in =
the boot loader asking for a partition to boot from.  =
'zfs:zroot/ROOT/default' resulted in an unknown partition.
>>>>=20
>>>> At the moment, I'm running with the SSD imaged from the FreeBSD RPI =
.img file, and that is working, but it's UFS, not ZFS.  I'll give your =
steps a try, and if I get nowhere, I might wind up creating a UFS =
partition for root and boot, and make the rest of the disk zfs with my =
desired filesystems.
>>>=20
>>> So, bsdinstall should have set that up (zroot/ROOT/default).  =46rom =
the
>>> UFS disk, I think (off the top of my head) you can just do a "zfs =
import
>>> zroot" and then you should be able to see it (and everything else) =
with
>>> a:  "zfs list -tall -r zroot"  If you picked something other than =
zroot
>>> for the pool name, you might need to do some more tweaking.
>>>=20
>>> In my case, my USB disk is only ~256G.
>>=20
>> "The Design and Implementation of the FreeBSD Operating System"
>> says about ZFS (page 548):
>>=20
>> "Like all non-overwritingfile systems, ZFS operates best
>> when at least a quarter of its disk pool is free. Write
>> throughout becomes poor when the pool gets too full. By
>> contrast, UFS can run well to 95 percent full and acceptably
>> to 99 percent full."
>>=20
>> So, for a 256 GiByte USB disk used basically just as space for
>> one ZFS area (so nearly all the 256 GiBytes is available),
>> That would mean being careful to avoid having much less than
>> 64 GiBytes free on the media: hopefully using less than 192
>> 192 GiBytes of space at all times.
>=20
> Corrections: "that" not "That". Only one "192".
>=20
>>> I don't know if uboot has any
>>> BIOS limitations like old x86 did.  I've never had to be too wary, =
but
>>> then I've never had BIOS-breaking SSDs laying around to attach to =
RPI.
>>>=20
>>> I think uboot has some commands that might let you do some zfs
>>> exploration,
>=20
> I'm not aware of the RPi* firmware or the U-Boot that it
> loads and starts being able to deal with ZFS of themselves.
>=20
> The first stage that deals with ZFS, to my knowledge, is the
> FreeBSD EFI loader (that was loaded and started by U-Boot).
>=20
> The RPi4B sequencing for the normal FreeBSD way of
> setting things up is:
>=20
> RPi* firmware (I'll  not give substages in this)
> -> armstub8-gic and U-Boot

Sorry:

armstub8-gic is RPi4B (and related) specific.
The other/older aarch64 RPi*'s use armstub8 .

> -> FreeBSD loader
> -> FreeBSD kernel
> -> FreeBSD world
>=20
> The FreeBSD loader goes on the msdosfs file system,
> under efi/ . . . but that msdosfs file system also
> has the RPi* firmware, armstub8-gic, and U-Boot
> files at its top level.
>=20
> (Most other SBC boards seem to have U-Boot [and,
> sometimes more] outside any file system, needing to
> be dd'd to the right place that the partitioning
> and file systems need to avoid overlapping.)
>=20
>>> but hate to point you at web resources because there seems
>>> to be a huge variations in what we end up with on FreeBSD/RPI.  My =
RPI
>>> is a few hours into a firefox rebuild so I can't give you some real
>>> guidance from what I'm using at the moment.
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 21:34:54 2022
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 E26A917D0378
	for ; Fri,  8 Jul 2022 21:35:09 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.219])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfmlc6KBWz3kJ8
	for ; Fri,  8 Jul 2022 21:35:08 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657316101;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=DvZa/XHifvA8cw4HJoRWnCqki+o1DlCvpP8JeTyi7XM=;
    b=LLxArROspa5Mv4UmifoRE8roWdL41chaZoJ3wc4d/2Ltyp0yFtOY5WJtO4hkxdXkxr
    lpWWwEE7ff6dO2oEYL5hWQ959M73mbgOUT6KRTQpDaR6W4L2TVKsf4pbZuyUQqT1jE5t
    3oZW9w27sPwQcbXnQPkGlKR8jM/Vi/fb1om+VyfvMtasWZhiCpxFiB0G4X0xB0C7hNCY
    WTCZMxpmuL1/9H6bekRxh5xSfyEDwWTcwFvIFlF9oTtDICue4OIEA7vi7WBXJiApjrgX
    +kNWnyIfmIitLTk2EqgKhNDSq7FJRGheA2kWwINUIBM7DQmRUNVdR4wKrYK/rorrV7km
    oqxw==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y68LZ1akQ
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Fri, 8 Jul 2022 23:35:01 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 8297763921;
	Fri,  8 Jul 2022 23:34:59 +0200 (CEST)
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 12.4 \(3445.104.15\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: "Dr. Rolf Jansen" 
In-Reply-To: 
Date: Fri, 8 Jul 2022 18:34:54 -0300
Cc: John Kennedy ,
 Mark Millard 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
 
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lfmlc6KBWz3kJ8
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=LLxArROs;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.219 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	RCVD_IN_DNSWL_LOW(-0.10)[81.169.146.219:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	DMARC_NA(0.00)[cyclaero.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.219:from];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[phouka.net,yahoo.com];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 06.07.2022 um 02:01 schrieb Mark Millard :
>=20
> On 2022-Jul-5, at 08:09, Dr. Rolf Jansen  =
wrote:
>=20
>>> . . .
>>=20
>> That would be the second step. The first step would be that somebody =
else confirms my finding that building and running a custom kernel on a =
stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that =
was my initial question.
>>=20
>> (1) In case somebody raises her/his hand telling, that this worked =
flawlessly on their system,
>> then I would have a more in deep look, what might have gone wrong =
here.
>>=20
>> (2) In case the issue would be confirmed, then I would submit a bug =
report, and the discussion
>> may continue in a more productive way on bugs.freebsd.org.
>=20
> Summary of the later material:
>=20
> It would appear that if building any kernels are
> broken, it is specific to some custom kernel(s)
> in question, not to building kernels in general.
> 13.1-RELEASE's install is able to build, install,
> and boot its own generic kernel on a 8GiByte
> RPi4B Rev. 1.4.

So we are talking about case (1 - works flawlessly as expected), and as =
I promised, I will look more in deep on what might have gone wrong here. =
For those who want to reproduce building of kernels completely from the =
scratch on the RPi 4 in the shortest possible way, I leave a transcript =
of the procedure at the very bottom of this message (see: *** Installing =
FreeBSD on a microSD card and building a (custom) kernel ****).

Results with the thus builded kernels:

13.1-GENERIC does work
13.1-GENERIC-MMCCAM does boot from the microSD, but USB does not work
13.1-GNNERIC-RPi4 stalls when booting.
cat /usr/src/sys/arm64/conf/GENERIC-RPi4
   include	GENERIC
   ident	GENERIC-RPi4
   nooptions	SOC_NVIDIA_TEGRA210

In the serial console:
   ...
   mmcsd0: Error indicated: 1 Timeout
   mountroot: waiting for device /dev/ufs/rootfs...
   bcm_dma0: DMA error 4 on CH5
   Mounting from ufs:/dev/ufs/rootfs failed with error 19.

My conclusion is that we may not completely disable NVIDIA Tegra 210. =
And after all, my goal was not exactly to disable the Tegra, but to =
mitigate the egoistic behaviour of its internal RTC driver for the =
MAX77620 (all i2c-addr 68 is mine). I achieved that goal by replacing in =
the source file /usr/src/sys/arm64/nvidia/tegra210/max77620_rtc.c (of =
13.1-RELEASE) the I2C address from 0x68 to 0x7F. Nothing uses 0x7F and =
so the MAX77620 driver may claim it for itself without harm to other =
devices.

sed -e "s/#define MAX77620_RTC_I2C_ADDR.0x68/#define =
MAX77620_RTC_I2C_ADDR   0x7F/" \
    -i "" /usr/src/sys/arm64/nvidia/tegra210/max77620_rtc.c=20

13.1-GENERIC (patched) does work, including the DS3231 RTC on i2c1 =
address 0x68.

   ...
   iicbus0:  on iichb0
   iic0:  on iicbus0
   ds32310:  at addr 0xd0 on iicbus0
   ...
   ...
   mmcsd0: 16GB  at mmc1 =
50.0MHz/4bit/65535-block
   bcm2835_cpufreq0: ARM 1500MHz, Core 500MHz, SDRAM 400MHz, Turbo ON
   ds32310: registered as a time-of-day clock, resolution 1.000000s
   ...

Many thanks for all your inputs and efforts.

Best regards

Rolf


*** Installing FreeBSD on a microSD card and building a (custom) kernel =
****

1. Fetch the image and write it to a pristine microSD card:

   # fetch =
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBS=
D-13.1-RELEASE-arm64-aarch64-RPI.img.xz
   # xz -d FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz
   # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 =
bs=3D1m conv=3Dsync


2. Preparation before the first start which automatically would max. out =
the UFS partition.
   Hovever, I want to reserve space for a 2 GB swap partition
   (omit this step, in case you don't want a swap p.):

   # gpart resize -i 2 da0
   # gpart show da0 da0s2
   =3D>      63  31116225  da0  MBR  (15G)
           63      2016       - free -  (1.0M)
         2079    102312    1  fat32lba  [active]  (50M)
       104391  31011897    2  freebsd  (15G)

   =3D>       0  31011897  da0s2  BSD  (15G)
            0        57         - free -  (29K)
           57   6186880      1  freebsd-ufs  (2.9G)
      6186937  24824960         - free -  (12G)

   Calculate the base (start) of the swap partition, e.g. here: 6186937 =
+ 24824960 - 4*1024*1024 =3D 26817593
   # gpart add -b 26817593 -t freebsd-swap da0s2
   # gpart show da0s2
   =3D>       0  31011897  da0s2  BSD  (15G)
            0        57         - free -  (29K)
           57   6186880      1  freebsd-ufs  (2.9G)
      6186937  20630656         - free -  (9.8G)
     26817593   4194304      2  freebsd-swap  (2.0G)


3. Start the RPi 4 with the SD card and enter via serial console as =
root:

   login: root
   Password:
   May 12 08:46:57 generic login[1206]: ROOT LOGIN (root) ON ttyu0
   FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC

   Welcome to FreeBSD!

   Release Notes, Errata: https://www.FreeBSD.org/releases/
   Security Advisories:   https://www.FreeBSD.org/security/
   FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
   FreeBSD FAQ:           https://www.FreeBSD.org/faq/
   Questions List:        =
https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
   FreeBSD Forums:        https://forums.FreeBSD.org/

   Documents installed with the system are in the =
/usr/local/share/doc/freebsd/
   directory, or can be installed later with:  pkg install =
en-freebsd-doc
   For other languages, replace "en" with a language code like de or fr.

   Show the version of FreeBSD installed:  freebsd-version ; uname -a
   Please include that output and any error messages when posting =
questions.
   Introduction to manual pages:  man man
   FreeBSD directory layout:      man hier

   To change this login announcement, see motd(5).

   root@generic:~ # gpart show
   =3D>      63  31116225  mmcsd0  MBR  (15G)
           63      2016          - free -  (1.0M)
         2079    102312       1  fat32lba  [active]  (50M)
       104391  31011897       2  freebsd  (15G)

   =3D>       0  31011897  mmcsd0s2  BSD  (15G)
            0        57            - free -  (29K)
           57  26814464         1  freebsd-ufs  (13G)
     26814521      3072            - free -  (1.5M)
     26817593   4194304         2  freebsd-swap  (2.0G)


4. Donwload and install the sources:

   # cd /
   # fetch --no-verify-peer =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
   # tar -xzf src.txz


5. Build and install the GENERIC kernel
  =20
   # cd /usr/src
   # make -j4 buildkernel KERNCONF=3DGENERIC
   # make installkernel KERNCONF=3DGENERIC


6. Restart the RPi 4


From nobody Fri Jul  8 22:33:02 2022
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 CE85D17F977A
	for ; Fri,  8 Jul 2022 22:33:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lfp2c3myvz3rrK
	for ; Fri,  8 Jul 2022 22:33:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657319590; bh=4MWcEezVWN9PlKy8JsbGFJK16ZzyORbZ1Oq/CfHzm2o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=c/awgm5tJ0FuCzfd4jSOjU5V1FPrsqjsX0JIJi1H4vp230hIj1mTeHzEM/LMiW83sV/TK9YJjiIGVTcZGACQGQNEoz94djSqzFOzQWD2qmTu7R4dFykkyngrGiPxLACWWgnjF7pLxAg/KDQxY102vm4wd8daqnGFvbkc4YX126j6T/Vr7pNWKRj9JMMtFcuKN2FFaOAWhWzjCSpVDbgHHmwZvMh4CgOC6I+HrdmOvg+AA5wuPRC2Z5cahfVcvGX7z9WQ6gOWdXa11OCVoT/cqS4ZViGdhYk6PGqFglCPd3HNc9z234vBLYV1lmMB9TVl7QtiXLU7Q0kQd/9InoqNBw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657319590; bh=qv0nbnzKn/gAYLs0ILjYAlGbfOZIFxTtdVz2anlzGvc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=guwYJDJbrUxYuElTZd0/4Ag7yOPMsTXUtRFJUdV+igUdX3N2Z0ZXx+nmEeMNz7dd5uFDscmmV/Cv6OqG01kCDZxYUTVVPSORSvXbzukO3BqDo8H0zNYRZd1SEdmZvoH3RrBk4cE9I4HwZYF91GTYsbMSu6r9CtXNuMuPqVDfvN5AxU+dO/3wz9ma2c8EGrLpmAAfIFIeqDXGM/kACngrPUXTQg2ILBpfaCu47qzxHMR8tx+k5bSU1qMDfuU+t7YVLyix5QHNYTz8pZmQF2YSpNViFjTfYVnqdWedBLwPfPmF7PvMV3iv9SuExN0vaBQLk/YlzxZCqj7CyiaVFVN61w==
X-YMail-OSG: g9DpcQkVM1k7zoflVS_vp4_RxLgRivOQJsv1jBNBUG4klbdwMyDsdxJT7QspTxq
 Hw51h6i6rlnZbHmcEaKGzW.2cgAfaBmlohPybFLX_AcVUhYisLskB7NOdN_56JbPgqmiS.04CraV
 cZAaebu07f_Lz.aZYq5Ikycxg4u7c.NV7tbj6mvyJZo1NDZ3UZUrW5s1MjiwmzvMqaAaqvMvUdmz
 BkebNTBiqlcckml8PEKdikRuwz39z_uFWYC3UYD5N3xSKZYtGiTs9MRTMQUyxNPuU4ujXEGkj8n_
 GtgDjd51G.IEVycQSNFfVwYgSws.xrWl5N5cVJQTyfILBvZVjmxDwgo2o_Y1DbpkPg_Q193kMkno
 CJ7_BDFlm72lAumEU2ry0k_TVWAx9_LLIDeiRjg5Rj4fVnFgSJnUMEXmed.ihrWIXzLheBNisYpO
 9qotYjBbgxbLzWMK8_0wXhphBA9IGKFvBH._RqrwHU0dzZGt9Fa1SA7kd.yw1bmnvJ7Y3Rs8BDNL
 19.pv_aV4u8dyWKKiCYbJooCN9dWyLqNdffRtDcUB85qz8doKkqOo7xfZslX9gSZGnf0At4U5fFG
 SMFIh4gTbJRQd41_zW4mfbHtTdc.t3PV9_8_acC_h7fFKXTotFFbSiQ32VjOGnKUAD7D.uFVO4q6
 apbs1jalRaHPh5i4.ydwFBI3hDhFJd9WWrC3L9b4MUgns.n9A_gb6j4ECWAf.Bd0nHwHx0rObGy_
 miQe9bfM4zPoRtj2vtJ8B8WxkicBy0RRXd998PrV3npPcZlssXUyUBPwyOv6N.CTFrWI0K4qbh0y
 wAVHpfvxfevD7hxOH7eRq5f9bDHFCWPYxBUnN2sTlEZh0YnKA_otMgUfSDglNvmAx3cIjnfvDryW
 8TYjLsL_xZ6NHzZ9b1ULMNKSc580RcYgL7pgQyVWHDdlVCrnnNiZaguYg.AkNLA1lnSddIQ81W3H
 XsR4QyzDfBNAsHu2NYvHy._3.RnvBO.5Qcnoirb2I_Rt7xCao5dOdn.X8o9K9D0phLdcoM9DJK24
 Wnxp4SSejyyYFvWiVgALoCqdvZeTagardP07F2OaAffLdjL1G9emxe3C.S1tZFPbDpclJzBwDhEA
 z0wFGjoCrUmTaq_yy3sEWGVVnlOaE4GphbV1xIfwzgegP6b8Wx89Be4Z2kNjiB_WpnD5e7UWiSPF
 NyEnApclbjZxoXMvRqauWL1BsJVIt6KZ4bPJ3AFCEDdKKu6QuoJu.CkcAj3rrCu7fVJVtI1uh4KA
 60SYSNJkWPP7dCZcrX0OhTBLjILQjqmDIMTjBOt.sp0i6RYfuPZViUGLt3kf43CkSfj9gXLB9JjW
 RnpYQ0qIcrE5tX5N2Pb97kMFwhnOhv5dHZXhBn.ZceZS_WqXosO6aYm.mMvI1ffFQjrDoHhLqTTB
 hj8oke0cq3e88YrkZSfMemyBZ6SObA_iyCWOJc9jqLRGb35wug3Res2.Gt7AYH5SQeJBqD0EqZ.5
 A2ynfVF20iRcvFgoYy5U3PGsUhD6vymr0oEhrLI7Utv2hhd78Wf0ZyI9sUcZC2iFjtyztzRNhdRg
 Cd7WXwRdc40ORGRXHXmpo4rw2LEWVcajCqFSChqeqhdyk2J98cV9vY_oaPiffmn11KSzHfpi58W1
 1re6T.WRZdM0zROtxv57QLxiWnteE8Ux7yA_AyaJeraVWgWWlxpRPWXvp1zsgLIzr8__kN5JpNyP
 Hkcqr.pEcVDweFZmN25AIIVc5mW2s6EGfzJypFtvdDV3MwIQwsuwUq3s.1khlzczPKSs6QEZTZgK
 aodmhlryAyMCC2lYoCcez6VbXQczbXVfLzkPDy33PmjFDTl2_.Q8sstM8LfuU9Jlcn.Ts8DNws1T
 g3bvzKBTp.TCFmivOP.lz5ECQd3zCe8M_RXT06LOF9f_ybVUmccPViGYQk4DWokdpjGxYhyg4yOI
 u3vDCWlo9iNRu4FG86GWG0uJOVzExPYON43pqZHOjrufUmVAN1u0h5DvFha10yGTTdFsZu19tDWP
 a74zChw5dgIrNF7C8pUo4nE1UvLMfq0qTpTOlH0jWHWjwQQp5FyVfXmPQULKUwjTuPdrKNwUzVUi
 xEeJggv6po4sREkdUt6s9ClUfM03aqTVjy6fFkQB6fpIHnKi3KxcSvl4i.upSG9UAQIQo6pDYwQ8
 LzfHNdtSOVWZOk6To3JchTW88g60NmrdEu34kZj1j0iKahPo0If129TUzAc6HktHNgPEeEtmFCvD
 JhHSVixvhCXjanWNyVxb.qA2USM5k_UvpjCWho6QVbXoPr36ViThZa037r2qweZVrw.BGYF1YdwK
 qaZpOWEQyGa2RDIQ2aLrs9lA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 22:33:10 +0000
Received: by hermes--production-bf1-58957fb66f-dd4hs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f4e1dc7a5dc492bdca556755ead134df;
          Fri, 08 Jul 2022 22:33:04 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
From: Mark Millard 
In-Reply-To: 
Date: Fri, 8 Jul 2022 15:33:02 -0700
Cc: freebsd-arm ,
 John Kennedy 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
 
 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lfp2c3myvz3rrK
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="c/awgm5t";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-8, at 14:34, Dr. Rolf Jansen  =
wrote:
>=20
>> Am 06.07.2022 um 02:01 schrieb Mark Millard :
>>=20
>> On 2022-Jul-5, at 08:09, Dr. Rolf Jansen  =
wrote:
>>=20
>>>> . . .
>>>=20
>>> That would be the second step. The first step would be that somebody =
else confirms my finding that building and running a custom kernel on a =
stock FreeBSD 13.1-RELEASE on RPi 4 does not work out. And actually that =
was my initial question.
>>>=20
>>> (1) In case somebody raises her/his hand telling, that this worked =
flawlessly on their system,
>>> then I would have a more in deep look, what might have gone wrong =
here.
>>>=20
>>> (2) In case the issue would be confirmed, then I would submit a bug =
report, and the discussion
>>> may continue in a more productive way on bugs.freebsd.org.
>>=20
>> Summary of the later material:
>>=20
>> It would appear that if building any kernels are
>> broken, it is specific to some custom kernel(s)
>> in question, not to building kernels in general.
>> 13.1-RELEASE's install is able to build, install,
>> and boot its own generic kernel on a 8GiByte
>> RPi4B Rev. 1.4.
>=20
> So we are talking about case (1 - works flawlessly as expected), and =
as I promised, I will look more in deep on what might have gone wrong =
here. For those who want to reproduce building of kernels completely =
from the scratch on the RPi 4 in the shortest possible way, I leave a =
transcript of the procedure at the very bottom of this message (see: *** =
Installing FreeBSD on a microSD card and building a (custom) kernel =
****).
>=20
> Results with the thus builded kernels:
>=20
> 13.1-GENERIC does work
> 13.1-GENERIC-MMCCAM does boot from the microSD, but USB does not work

But for use of sys/arm64/conf/GENERIC-MMCCAM . . .
For my example context, booting via a USB3 port with USB3
media attached booted just fine. I reported this in a
later message. But it was an older "BOT" (3 GiByte DMA
limitation) SOC Rev 1.4 board RPi4B (8 GiByte).

(I did not even test booting from microsd media at
all.)

> 13.1-GNNERIC-RPi4 stalls when booting.
> cat /usr/src/sys/arm64/conf/GENERIC-RPi4
>   include	GENERIC
>   ident	GENERIC-RPi4
>   nooptions	SOC_NVIDIA_TEGRA210
>=20
> In the serial console:
>   ...
>   mmcsd0: Error indicated: 1 Timeout
>   mountroot: waiting for device /dev/ufs/rootfs...
>   bcm_dma0: DMA error 4 on CH5
>   Mounting from ufs:/dev/ufs/rootfs failed with error 19.

I will note that there are DMA related differences in
our contexts. An example that I know of is:

A) The "B0T" SOC's have limitations, such as the restriction
   to the lower 3 GiByte range.

B) The "C0T" SOC's do not have that limitation.

Normally (A) vs. (B) only matters for the 4 GiByte and 8
GiByte RPi4B variants, if I understand right.

My understanding is that the device tree handed over by
the RPi* firmware has differences for (A) vs. (B) via
dynamic adjustments to the .dtb content after it is
loaded. But I've no clue if such might have contributed
to what you observed.

> My conclusion is that we may not completely disable NVIDIA Tegra 210. =
And after all, my goal was not exactly to disable the Tegra, but to =
mitigate the egoistic behaviour of its internal RTC driver for the =
MAX77620 (all i2c-addr 68 is mine). I achieved that goal by replacing in =
the source file /usr/src/sys/arm64/nvidia/tegra210/max77620_rtc.c (of =
13.1-RELEASE) the I2C address from 0x68 to 0x7F. Nothing uses 0x7F and =
so the MAX77620 driver may claim it for itself without harm to other =
devices.
>=20
> sed -e "s/#define MAX77620_RTC_I2C_ADDR.0x68/#define =
MAX77620_RTC_I2C_ADDR   0x7F/" \
>    -i "" /usr/src/sys/arm64/nvidia/tegra210/max77620_rtc.c=20
>=20
> 13.1-GENERIC (patched) does work, including the DS3231 RTC on i2c1 =
address 0x68.
>=20
>   ...
>   iicbus0:  on iichb0
>   iic0:  on iicbus0
>   ds32310:  at addr 0xd0 on iicbus0
>   ...
>   ...
>   mmcsd0: 16GB  at =
mmc1 50.0MHz/4bit/65535-block
>   bcm2835_cpufreq0: ARM 1500MHz, Core 500MHz, SDRAM 400MHz, Turbo ON
>   ds32310: registered as a time-of-day clock, resolution 1.000000s
>   ...
>=20
> Many thanks for all your inputs and efforts.

Glad to hear that you got it going.

> Best regards
>=20
> Rolf
>=20
>=20
> *** Installing FreeBSD on a microSD card and building a (custom) =
kernel ****
>=20
> 1. Fetch the image and write it to a pristine microSD card:
>=20
>   # fetch =
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/13.1/FreeBS=
D-13.1-RELEASE-arm64-aarch64-RPI.img.xz
>   # xz -d FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz
>   # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 =
bs=3D1m conv=3Dsync
>=20
>=20
> 2. Preparation before the first start which automatically would max. =
out the UFS partition.
>   Hovever, I want to reserve space for a 2 GB swap partition
>   (omit this step, in case you don't want a swap p.):
>=20
>   # gpart resize -i 2 da0
>   # gpart show da0 da0s2
>   =3D>      63  31116225  da0  MBR  (15G)
>           63      2016       - free -  (1.0M)
>         2079    102312    1  fat32lba  [active]  (50M)
>       104391  31011897    2  freebsd  (15G)
>=20
>   =3D>       0  31011897  da0s2  BSD  (15G)
>            0        57         - free -  (29K)
>           57   6186880      1  freebsd-ufs  (2.9G)
>      6186937  24824960         - free -  (12G)
>=20
>   Calculate the base (start) of the swap partition, e.g. here: 6186937 =
+ 24824960 - 4*1024*1024 =3D 26817593
>   # gpart add -b 26817593 -t freebsd-swap da0s2
>   # gpart show da0s2
>   =3D>       0  31011897  da0s2  BSD  (15G)
>            0        57         - free -  (29K)
>           57   6186880      1  freebsd-ufs  (2.9G)
>      6186937  20630656         - free -  (9.8G)
>     26817593   4194304      2  freebsd-swap  (2.0G)
>=20
>=20
> 3. Start the RPi 4 with the SD card and enter via serial console as =
root:
>=20
>   login: root
>   Password:
>   May 12 08:46:57 generic login[1206]: ROOT LOGIN (root) ON ttyu0
>   FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
>=20
>   Welcome to FreeBSD!
>=20
>   Release Notes, Errata: https://www.FreeBSD.org/releases/
>   Security Advisories:   https://www.FreeBSD.org/security/
>   FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
>   FreeBSD FAQ:           https://www.FreeBSD.org/faq/
>   Questions List:        =
https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
>   FreeBSD Forums:        https://forums.FreeBSD.org/
>=20
>   Documents installed with the system are in the =
/usr/local/share/doc/freebsd/
>   directory, or can be installed later with:  pkg install =
en-freebsd-doc
>   For other languages, replace "en" with a language code like de or =
fr.
>=20
>   Show the version of FreeBSD installed:  freebsd-version ; uname -a
>   Please include that output and any error messages when posting =
questions.
>   Introduction to manual pages:  man man
>   FreeBSD directory layout:      man hier
>=20
>   To change this login announcement, see motd(5).
>=20
>   root@generic:~ # gpart show
>   =3D>      63  31116225  mmcsd0  MBR  (15G)
>           63      2016          - free -  (1.0M)
>         2079    102312       1  fat32lba  [active]  (50M)
>       104391  31011897       2  freebsd  (15G)
>=20
>   =3D>       0  31011897  mmcsd0s2  BSD  (15G)
>            0        57            - free -  (29K)
>           57  26814464         1  freebsd-ufs  (13G)
>     26814521      3072            - free -  (1.5M)
>     26817593   4194304         2  freebsd-swap  (2.0G)
>=20
>=20
> 4. Donwload and install the sources:
>=20
>   # cd /
>   # fetch --no-verify-peer =
https://download.freebsd.org/releases/arm64/aarch64/13.1-RELEASE/src.txz
>   # tar -xzf src.txz
>=20
>=20
> 5. Build and install the GENERIC kernel
>=20
>   # cd /usr/src
>   # make -j4 buildkernel KERNCONF=3DGENERIC
>   # make installkernel KERNCONF=3DGENERIC
>=20
>=20
> 6. Restart the RPi 4


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 23:02:08 2022
X-Original-To: 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 1269E17FDE34
	for ; Fri,  8 Jul 2022 23:02:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lfph64HLHz3tyQ
	for ; Fri,  8 Jul 2022 23:02:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657321333; bh=TIkPVtQeKJ90IkN6T5WN/qYkvDNKf2xk0cC9DlN544k=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=BJt1Q7LPmaZOU5Wm0a+47yVyPNInSdNt6WQvCpysdT06T2gB4SrrrwGo4tUm2HSoy6oe/q7T2gVQ1X1BeAOB1TRDpp67ww9xIm0uMEuGS11RcHtdRk6MB/xN5iqvRR8viTntglIdmKoFMQg0mCFcRJZF8JjbWHlGy+o+Th0HAb5raCWzIbjA6C88FtaNnIXiPXP83zOjRMcIdRlFpbqTMXnhp65D51LI2d//lFo6wa5Eyzdxp8fEEXgq1RfVJqKXg4Aw5AEDW+v9o6K0tsT5b594IfySUCFet5VUM7/ejaTMxf73gCSL8P0yqqlZDaHpnT2Mblp6sBL8aChcoAuXFw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657321333; bh=7wYYq73dWP9JHpUiH0p1KJMtw7lRvaeOTwC8X2FjUCO=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qjraJgsNTXyduYjK/3J0mhxZcUwMl+sa7lXXupblEvWT3EZnbAsxNksK2HQ1I+mwG/yx9UXHsRBySBhxdNz8CMmRFXBn9F2PXrfFITmGh4uY8O6/MDFnOdWFL6e09pyursJXo5f35GkVhvL1QDSivzP+tvAFOWVmCJCQYY4r9I1ybQmZQ6U/0V/+QmWTt5wtcvN1CJTUpHvhq8SL9YmqC+bFJXjCbf3shImZKenRP3gfeThlVdcjzAIUEzURKSg3z7eryefIxWq21l9+17DUjaKbnRv9LgYxeQ6mz1r1+u/5FVFWXUD0tI1fdoG1EjDzARHEJtvF/eq8EkSvPyMl9w==
X-YMail-OSG: 0ezur20VM1msshfmpvAOoj6xiVW.4QOBXMLwNKo8MjAFaBm0L.FXcacHnbo7CTt
 X.tiMcPQbYp8nkUFTM79KG3HFM5U5eJiVCMb.hTSJC3ISzyoRNPePykisx_7ZwGOeeIRessC4fRC
 YBV751ZAh7LgpfXD_B5N2.VGVRghI.AcqJQGMW7bD1JXz3JOt4X.UGUm5pJVognKjC9vSh5khg8G
 ckBOV15r76NnB8ItvV1CEHQWBNImBLBVbpvxuhW63kqhZn3yhH_fYNXli76Jb.OjdruFtCUYRfyP
 x.Dml4yBbG3MJ3VEuQ_BZW1RvaezX6mgWwPC4ffRyWnaFl7PYxkVZ2BTVHwK.T9BuUrMXoaynXL3
 LpR4gB2cmuz_UP6PGWD1u4HxaPZJR_MU4JxvmIGVxhPj3VgWPPgYA_S38dSBjGuPsbkLhOi7SUum
 5t9aLlkqiKm3Jpim.unVhITTEacipkX9iuqUdWrpZSa5cD0QiB9cpuu.N9UtsGXLi2WHhgilvfXA
 Yv3aUx.Fyo3AyS2YwFXnIR_eZ7gnyISf593amsE6axuD8z3An8Ndj4HAn5bnjDZlgk6p8Oud7AlS
 IkU3ps_8dUbeJ9osgD_YQcZ6Wv5UYEDMe_avYpOlc_foOOesHBjnfOAskhacy_D6zEr7_FSPlbih
 vVpDkHcVKq1lB5kYwUj8KE7jqiuMKC9V4X6KTKaRJ9NchMqE5j1GWpRUqtCiOE.DQjEMWMiyYzx9
 2xvsjq.vBIjjNdxvPwZlmTSum7.8OL7MzxVKi04wGCebn47PlYTrn8Xiy4KAHmfxABt.Fwhy8tbF
 F0S7F5ASkSWCvjvVrVQoLVZEg8qPfjjbFmPnLqxrC1T5_bLdlIILzllHEdnAxpzP046Uer2.zM8_
 kCH_3kZmjkgOhdVypRKxdDMUc2DNICEBBHJBYI6AIabKbLHYa6vJ0c0Mj5mdf2HJVjz9yrfAERQm
 Vyfh_CIfz241DlRkNztpAa9Jz5_qn.6sqyIyplVOApCcssAb.Xlu_35xYWeu6dQnT2vFat5o3q50
 yGLfhcRFwBn8IMUl5OHKd3A9_IgSCWaNYHmLKPUVanWFteo.qGPECFUHrCP3cCTvj3PLCwv2.Ijx
 69SY6Oh1fccsY4SkYlyUCY8bUkZSBcZ0_Aweh0ZWEkYgwqXyLl.b9xHqGd6hBSIYrg6_bU4IgpTD
 Fif5Qez4X6M5lS1VmLlKmZfEMU9nXw60QzphlP5VQvck83EmArvEAsE2BRZyQOP_gZn0sGEbfJwo
 jCDMZI8a7TOaDU06GoPG5hXlYFXSkWN9MFWm6rlBxMY.M3rFjKLGSbCY7exCo4kpBIhZcTe0mVA2
 unLw7SepOYl5Mmm5oeaT6llZ6tknwRkqvmMlYE2w.QEE5MK7ttjotjhvHpeVGa9zZAi1wKTt8Uje
 UZZAN9kRDVVHcAHDGgrNn6RIqLzKhBrGtJZDIjjD989IML5J15AurLWVBMM_hkTgj_.JBzkqFRPo
 e0a2EXt62_qm9Qvp2paNvCX7ZYEI9S_RlkYb.dnWoLOD6DrJ26N5QJxPAFBA_NDqynuV8Lfs2Iz4
 UXk_7xncDPbCqJW_kCm1fQTJ5p3JdHYQvZQa3iY7PJdB35lc9fXDneieBTFcv5B5CxDweIzrAdxp
 35noSrBOBTVS9kVA7Ph7K.pYQSGeT4G7LnrDsMNma2NlOmzQfs7zml3ggCSdT4iwthqgfSCwxZvc
 PRvOaeTQmpeWWRFN6A0UVQ2iJsbZ6mpdj5q_vSEPGx3m2bYl6cK9wU7LiLXQBolBncMBUPzNhX0h
 .zIhqSr1vdauatYp_iSRHifERe.OtQrSD6neChbmxS6RbmEHY_cAZ8.OtIYS_JiOC7HZNmNAOi9i
 xOKhbPsafaUU46XmjyFvlymHLY0MhcDCwQzcjr14.yoigFtb.CcC.jA16xD5Kz9xa8WI2TtwV_eE
 W96qzZGck2302WZSA8znZ8ySithE2NJgIEYtEeKPIOxmKqJKUdeix8FO8PPPFcbG3BigCMbGbKEX
 IoSo8Ql0qJi92Tcfy0vTk4gh7NEcLdhM1fM89D2kkJh8uQyc5eqIfL.bu3FOh_1b0EUBusBBzACk
 6YZ0wXS9cukP8DmQ.qlMxWEPnqqe3nVWVk7JzRwCfsSXi8pAlrhNrS.V_rwFBkFabwRtOOW.AeWO
 o9FMlAatvX2.qouQ65YDCy8eiHOYGKncQ2Hf4zQLLCqt4Mk6mH84fa_Vcv4CMxKD996HD5sG2CKy
 GBQSkHlb0.pj24fJNoKMxGcsLhnuBb80U4FZhWkB1AzzyVQzWZpjaevOUNiTjC8.9UBrKWX8InXY
 5_duGPMEZ21uMVT7LqCALHCHtESi218wqtwF8UHl5K62la5ktIzrV7y1aX5.4WRsZ_eo-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Jul 2022 23:02:13 +0000
Received: by hermes--production-gq1-56bb98dbc7-lvzl8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6db6c982e3ae88e3a80661d74ec74acf;
          Fri, 08 Jul 2022 23:02:09 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: RE: New FreeBSD snapshots available: stable/13 (20220708 77712e81bf9)
Message-Id: 
Date: Fri, 8 Jul 2022 16:02:08 -0700
Cc: "freebsd-arm@freebsd.org" 
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4Lfph64HLHz3tyQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=BJt1Q7LP;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.93)[-0.929];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N

Glen Barber  wrote on
Date: Fri, 08 Jul 2022 20:26:29 UTC :

. . .
> Installation images are available for:
> 
> o 13.1-STABLE amd64 GENERIC
> o 13.1-STABLE i386 GENERIC
> o 13.1-STABLE powerpc GENERIC
> o 13.1-STABLE powerpc64 GENERIC64
> o 13.1-STABLE powerpc64le GENERIC64LE
> o 13.1-STABLE armv6 RPI-B
> o 13.1-STABLE armv7 GENERICSD
> o 13.1-STABLE aarch64 GENERIC
> o 13.1-STABLE riscv64 GENERIC
. . .

Is the lack of the following expected to
be an on-going status for 13.*-STABLE
snapshot builds?

aarch64 RPI
aarch64 PINE64
aarch64 PINE64-LTS
aarch64 PINEBOOK
aarch64 ROCK64
aarch64 ROCKPRO64


Also, because old snapshot images are deleted even
when there there is no new replacement for the type
of snapshot, it has been some time since there have
been any snapshot images for the above 6. It might
be appropriate to delete the oldest image only when
there is a newer one to be added, there by leaving
some vintage of snapshot available, even if it is
older.


Hmm, looking, it does appear that:

http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.1-STABLE/

does have the .txz material for the latest snapshot
build attempt. So may be there is just an issue with
producing .img files for Small Board Computers after
FreeBSD is built or with building the involved ports
providing the extra material involved. (These involve
U-Boot and some involve other things as well.)

===
Mark Millard
marklmi at yahoo.com


From nobody Fri Jul  8 23:17:26 2022
X-Original-To: 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 6F12417FFDEF
	for ; Fri,  8 Jul 2022 23:17:33 +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 4Lfq1n2qbcz3wJ7;
	Fri,  8 Jul 2022 23:17:33 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15])
	(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 766714DF7F;
	Fri,  8 Jul 2022 23:17:27 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us 766714DF7F
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: New FreeBSD snapshots available: stable/13 (20220708 77712e81bf9)
From: Glen Barber 
In-Reply-To: 
Date: Fri, 8 Jul 2022 19:17:26 -0400
Cc: arm@freebsd.org
Message-Id: <4A5A97A8-2754-4E75-88BF-36667F9747AA@freebsd.org>
References: 
To: Mark Millard 
X-Mailer: iPhone Mail (19F77)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Lfq1n2qbcz3wJ7
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)[]
X-ThisMailContainsUnwantedMimeParts: N

On Jul 8, 2022, at 7:02 PM, Mark Millard  wrote:
>=20
> =EF=BB=BFGlen Barber  wrote on
> Date: Fri, 08 Jul 2022 20:26:29 UTC :
>=20
> . . .
>> Installation images are available for:
>>=20
>> o 13.1-STABLE amd64 GENERIC
>> o 13.1-STABLE i386 GENERIC
>> o 13.1-STABLE powerpc GENERIC
>> o 13.1-STABLE powerpc64 GENERIC64
>> o 13.1-STABLE powerpc64le GENERIC64LE
>> o 13.1-STABLE armv6 RPI-B
>> o 13.1-STABLE armv7 GENERICSD
>> o 13.1-STABLE aarch64 GENERIC
>> o 13.1-STABLE riscv64 GENERIC
> . . .
>=20
> Is the lack of the following expected to
> be an on-going status for 13.*-STABLE
> snapshot builds?
>=20
> aarch64 RPI
> aarch64 PINE64
> aarch64 PINE64-LTS
> aarch64 PINEBOOK
> aarch64 ROCK64
> aarch64 ROCKPRO64
>=20
>=20
> Also, because old snapshot images are deleted even
> when there there is no new replacement for the type
> of snapshot, it has been some time since there have
> been any snapshot images for the above 6. It might
> be appropriate to delete the oldest image only when
> there is a newer one to be added, there by leaving
> some vintage of snapshot available, even if it is
> older.
>=20
>=20
> Hmm, looking, it does appear that:
>=20
> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.1-STABLE/
>=20
> does have the .txz material for the latest snapshot
> build attempt. So may be there is just an issue with
> producing .img files for Small Board Computers after
> FreeBSD is built or with building the involved ports
> providing the extra material involved. (These involve
> U-Boot and some involve other things as well.

No, is not expected to be ongoing.

The images are failing because the md(4)-backed image is running out of spac=
e, and I have not yet figured out why.

That said, I remove the images from +17 days well before kicking the snapsho=
t builds.  I have no way to know what will fail or not.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.



From nobody Sat Jul  9 16:47:23 2022
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 050B1180DEAA
	for ; Sat,  9 Jul 2022 16:47:31 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2076.outbound.protection.outlook.com [40.107.91.76])
	(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 4LgGKF335pz3hcd
	for ; Sat,  9 Jul 2022 16:47:29 +0000 (UTC)
	(envelope-from stephen.wall@redcom.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=kXMpXRgeDqNFRAyFRlR6r82kxmMwrV3Lwxin/DF/TdJbdKGsjRIGz09VIitzMhbibpg/0SSiKsWI1WbL236jWcV2re3QE5rJ4CHUAvGrFBWyCliG2lDjIPaOiowMifhVlAnNU+ewNxf2THjcs1sww0tGaSNUT2vB50KkdlrvEjvD+q1BpedbSBgEdF48SfzdinTTjefJgaj8lHZv4815NoiekQjG8LPBum97pBa9ThKH2OQ6za5H2mbyNysM4iZczbjeZIqN5II9wduLwCB602P/7PnrNjNruMqMFiHgcx+46qu0iCRz9fiILp/IWwMndn6NdjsNlhoYgA1aSWN7Kw==
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=b1z8MM/JsPa+kXEQVwLhr83bSAa57cbTsrZsAwio/qA=;
 b=fBKKWALwWWu7J9HvtEjBp3OiVh8rTvfE1fLQpAWL9vfn20airkjLPwowgYQsOTQKjrpOZ8JuJpR+5/JSpw5Om/KzYrGcfVG0/+Qfyk9PUfZaQr6o4wqH9DYUm8py7nJQMf7rObiLv8sml6s3VMV4oeU+2cQKjDWqsgxv3ofCSVeIKGrTooP2omsZdSSu/Ld58v5Mtmu65VDb27Ln6iTbiOVJJ993pFHbah8Op4AjRB19mBMibRXuLx3E4eOw4qlA64zXDeAKMS8R8+tT7xzIaAjl87G+gctnCDXbmlspMYF6DJ7ZXDUX23kZFXR6HmHTi4sLPu48nVrYcIZFyRt3Lg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=redcom.com; dmarc=pass action=none header.from=redcom.com;
 dkim=pass header.d=redcom.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=redcomlaboratories.onmicrosoft.com;
 s=selector1-redcomlaboratories-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=b1z8MM/JsPa+kXEQVwLhr83bSAa57cbTsrZsAwio/qA=;
 b=s6CqIQwHNYE5XnxrUBhU+20vT8GVW3i7KPmpSGSuNGZNCG0Cc68o7mSAd4pA9sIw19fHLx/FLw7knL2EIFEH4mswrEvkWwGSy0vsgr6JpXq1JXVp1GiZYo4FJUJeOXRB5RL8+f3rLV6pUegYyKMqQpzmXx+XJFlRumL8qHmIpykW2myNEIlx8gmNEbtcbSwC6aUw48HIHAUCe5hsdPj/9lcK/VA1wbsr0LPJwmdU9pCvVvASx6+WXzF7Jph7Xzf28JsOQ6PVWKOdxOW2vbKo0x1ZI/xOybmK7kpydbgBB2JmVniX5zqsLCDyKUADZzoZd36oD8ZdOf5E1/I9q4DXVg==
Received: from MN2PR09MB4667.namprd09.prod.outlook.com (2603:10b6:208:216::16)
 by PH8PR09MB9327.namprd09.prod.outlook.com (2603:10b6:510:186::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Sat, 9 Jul
 2022 16:47:23 +0000
Received: from MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474]) by MN2PR09MB4667.namprd09.prod.outlook.com
 ([fe80::1ca4:ca52:3d0c:e474%7]) with mapi id 15.20.5395.021; Sat, 9 Jul 2022
 16:47:23 +0000
From: "Wall, Stephen" 
To: "Dr. Rolf Jansen" , freebsd-arm
	
Subject: RE: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Thread-Topic: Failed to execute custom kernels which where build on a RPi 4
 operated by 13.1-RELEASE
Thread-Index: AQHYkAHZT8pVR3NVj0Oze7DAleZlW61u/ogAgAAK2QCAAMNbAIAFOJOEgAFAZmA=
Date: Sat, 9 Jul 2022 16:47:23 +0000
Message-ID:
 
References: 
 
 
 
 <71D4E84B-5D80-43A5-BE22-8E4F6486B7E4@cyclaero.com>
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 51b6a593-5994-4e28-3ae1-08da61cab274
x-ms-traffictypediagnostic: PH8PR09MB9327:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 OtwRJ5o5xLo5TZfrIbSswpGJrzKy5ZSX2jFQaVt9TzRcN9fYpWXw4GPiHuIOt3G58Ubmi6umVvp89tm2WbrMdIqncBnZYklyjXujJ270cZ0OSiRcRUI+aDojzJBS7L5jxtI6sfsMQnUeL3AU2WmMu/hruckHFcu9CTTNgIC9Vhj7aJzXWKtRxhqLCrc1G1782RSxT8wNVTkaUTSE+vDrhFN7vo0UBfmp8+hGRQ7BC2oe69PUFsi9hZ8U3i1BlReFq/D+ZDmL3EU5QOYRdqLb01h8XNA9sFijMIm7eqijSaQxAOQ2s4tBrfoPg4sqyR4zHdfhmb+xJeKe1evz81L/9ObL2JKLloE1aS5K8L841Bfek1/qSoUAHC6FFMTTgo6zXI+4b+VzL9pO5a7jy0jfVFkKS/SrfLCVWuTx+UrBM5LpsRT5MX0rneP1V1EP1lNZDJg9Ot6gBlEUVgFkQnhAq4ROWPWTo7MXQ+O1iRDARxa8J3cWpTrwMWeS13FK4QPkAMXZztFkiaH3FVhozygGndzOaGvunOat/mdrc8KNGgmrRvJ9xgYoNIcu1PrkeZzH7ilqgHMaU0vyeqqm/4xu8sKDtwcLL6zmxR77UWk0+VV9EDOtwedQTZJYXlNF4vKqxn8K+JLP2sVVhxP8GbouidsuHN0EWrV3tIVz9L87VZ8K+qsbCDBq7183aD7P+sEaarZ4WDPpbFJ+1YBAE5VipN8lPTeqM65rfSo2b1uynYYhtVp6CvDxZDxyn0F15oipv8KOBUyBf8ovcOWNIZSc7O7yCRdglz83O5mBz8xkzQC8YMd0+QOlI9ot4uWzcUHB
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR09MB4667.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(366004)(8936002)(52536014)(38100700002)(110136005)(122000001)(66556008)(64756008)(66946007)(66476007)(66446008)(86362001)(71200400001)(55016003)(76116006)(498600001)(2906002)(8676002)(33656002)(26005)(9686003)(6506007)(7696005)(38070700005)(83380400001)(5660300002)(186003)(4744005);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?UWxKcnhGTktsR0JreGY3TGFkUGY4OWhKcXVBWUl3ai96ZEk4YUppTTQ0N3Jz?=
 =?utf-8?B?SUN4ajJKc1o5NHIwWlpEdEtxcmR4RXNMS2dFWlpoQTZFQTliQ3RCY044TXBD?=
 =?utf-8?B?aVA1aEpHZkt2QUEwRzFubFJtUFE3OTdYY1YzaUpka3N4RDBqM3JOMlA4VXpU?=
 =?utf-8?B?d2Z3eHVvS2xPL2k4aUlBRm5obXJWOTFGM1czeHVnaHNBT0hlR3hDelZmZy9E?=
 =?utf-8?B?bGNlSUhkUkpja2Faamx3QnNsQUxna2ZPdUpraDRoZXRrNWhXM3piUDBwVVBs?=
 =?utf-8?B?VUs3TlBoU1IzSzF0QUtNZlNYSjd3NUVkbGhYQzVrNFNlbFZ1aFFSa0hldDBE?=
 =?utf-8?B?UmZpM2ZYL2s5eEdWWkN5NzR4dzB4SERYSlNKUW40TDZ2L1A4TWtVOVVGYTZO?=
 =?utf-8?B?clVxdWJZMXh5K2M2VUUyeW1PZlZ0dUVWY1ZFaUt4aVg5NFNVMk5KRVpSaXkr?=
 =?utf-8?B?cU80emlEa2MyVWNndE9IQWtuRWQrY2lZVVI5VnFTUlNpTlJNbWNGeXMrOW4y?=
 =?utf-8?B?TlZYTW15QTMyMkNGL0xJTGFYU1B4ZmMyMEJTQzRSbEZGYXk4MjhwOVArbGZu?=
 =?utf-8?B?Z3NBSmExaGJIcHVyZkdpYzhoVmIxdFNwSm5weCtReHh6QjVtV0RkTlZPTi9U?=
 =?utf-8?B?cGZtL0Y2WmcyM0drNHBpdjI0SWhGMXMvdWJSM3FUdEFObWZPT1dtRnZUU0ZI?=
 =?utf-8?B?RERORldWdkx3Q2trc2ZXeUt6NnYyZFVJc3NWQkVtWWhDSW8vK2JETTFDZTdv?=
 =?utf-8?B?TXZKOWNkTFUweUtOSWliQm05U0dnaEI3SXFMaDdyKzFDS09KOFFuQnJ0NFpm?=
 =?utf-8?B?SnoyaUpJRkZRMFRtM0ptMnVGM3R4ZGsrZ29FaGUwOXNNclRRR1dVNUZQUVlN?=
 =?utf-8?B?bXVqL1hFN29wZk1sYzlBM3piYVVjN3ljcDRMWDdIS3pGMVhEcGtPZjU1MzE5?=
 =?utf-8?B?UjNZTE1VZFM3Y0NPWVFGMS9pcTBtc1hRc0FBcmFrTys4aEpxSXdBMjIxNTlp?=
 =?utf-8?B?VElhZzk2ZXNYK0ZadERyOGRCWG56d2FLMzlrRGFNN1pBbkt4SGdMdUlLdzc4?=
 =?utf-8?B?VHN3MUtTZDJhOWZzRWYrb0hrR05QQ3Iway8veWN1eVRZSFdyZkRMcFRVc1ZX?=
 =?utf-8?B?bTJ0dW1zenJhTW1GdGdZSzFlZUFmUmlEL2lWR3ZoYXQ2TVNMd0JaeUlLOWh3?=
 =?utf-8?B?aERqenA3bU5IZkZZS2haNFoyRUZFY2RVemtobDd2dC9KaUdlT2VZSkpUZTZp?=
 =?utf-8?B?VFVSQUxnaG9GV2pobXZQS28wTWNjTzF2TzlmSDhneFpFR09MU1hycUFlS0lr?=
 =?utf-8?B?bmcvb2RrelFRbzk4ZE0zUW5ydTZreTAydHEycFpOajF2bC9VM1VEa0lTL1dW?=
 =?utf-8?B?M3hJbnZWUXhBeEFCQ2xMRjdTT2lraVFFUjNja2pKdE1pN201NWFPOC96TU0z?=
 =?utf-8?B?WS9hbHpTZFdKQXJyeGNtTml5K2gzQXVhbWVnY2QwQnQ0S0hweElnKy9NdHll?=
 =?utf-8?B?MUlodjdRZ2tvMXk1bFVJK3F2Zk51TXNiSHdPOTgvNzdxd1lwdHFlTDN5TEhU?=
 =?utf-8?B?bFhydmF1amJUNllDVGtxUnM0cEhRbDc1MTFsWGpGVU1ZZXJaT1FRZ05xZ1dH?=
 =?utf-8?B?Y0Y3bmN2cit3ZU0rSWNHNDZSU2N6RFZLL1JLQTJLYUxDV3ZKN1hvQjNnVHo5?=
 =?utf-8?B?RW5nZ3Z1emNsczY3YlNTQzNZUjZNMDlnODV1SWt2blZnTFAzYTVweDBiMzdU?=
 =?utf-8?B?MDBmMENycmFiMTVOTlI2Vms2V3piREVXMDdDRUVSSEhzMDRJK1ZTdE12KzJ5?=
 =?utf-8?B?M3VQckJaTDV0ems4c05mTVpRQXdrclJxcGJHRjNkWkNjREVKc01ZZndFRElN?=
 =?utf-8?B?enVLVm4xZEVIRmsyRy9zZmJmd0RkUHB6QThvRFA0bDlzTFZvdnBHMDBBSW9V?=
 =?utf-8?B?RXJJZ29ITTFCcmtrVEhlckNpZ2UvZ0NEbXlVNlUzNlNjUkVncVZrcGgweEdF?=
 =?utf-8?B?aWJEbWdYajZvZXJtd3ZOMUxCMi9hdDg2MW4xRVFOc3BmNm0zVHJFb0NpOWpn?=
 =?utf-8?B?dGxqc0NidVFzNFZWRUpjVjdmL3FWaEE3YXNBNE1WY3NCOXN5UlEyK1Jja3RF?=
 =?utf-8?Q?y5yc=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: redcom.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB4667.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51b6a593-5994-4e28-3ae1-08da61cab274
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2022 16:47:23.0971
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 86200ba5-6348-4d6f-bdd7-96f43e8d9247
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR09MB9327
X-Rspamd-Queue-Id: 4LgGKF335pz3hcd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=redcomlaboratories.onmicrosoft.com header.s=selector1-redcomlaboratories-onmicrosoft-com header.b=s6CqIQwH;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of stephen.wall@redcom.com designates 40.107.91.76 as permitted sender) smtp.mailfrom=stephen.wall@redcom.com
X-Spamd-Result: default: False [-3.40 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	R_DKIM_ALLOW(-0.20)[redcomlaboratories.onmicrosoft.com:s=selector1-redcomlaboratories-onmicrosoft-com];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.91.76:from];
	DKIM_TRACE(0.00)[redcomlaboratories.onmicrosoft.com:+];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[redcom.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.91.76:from]
X-ThisMailContainsUnwantedMimeParts: N

PiA+PiBUaGF0IHdvdWxkIGJlIHRoZSBzZWNvbmQgc3RlcC4gVGhlIGZpcnN0IHN0ZXAgd291bGQg
YmUgdGhhdCBzb21lYm9keSBlbHNlDQo+IGNvbmZpcm1zIG15IGZpbmRpbmcgdGhhdCBidWlsZGlu
ZyBhbmQgcnVubmluZyBhIGN1c3RvbSBrZXJuZWwgb24gYSBzdG9jaw0KPiBGcmVlQlNEIDEzLjEt
UkVMRUFTRSBvbiBSUGkgNCBkb2VzIG5vdCB3b3JrIG91dC4gQW5kIGFjdHVhbGx5IHRoYXQgd2Fz
IG15DQo+IGluaXRpYWwgcXVlc3Rpb24uDQoNCkZZSSwgSSBoYXZlIGp1c3QgYnVpbHQgYW5kIGJv
b3RlZCB0byBhIGN1c3RvbSBGcmVlQlNEIDEzLjEtYmFzZWQga2VybmVsLCB1c2luZyBGcmVlQlNE
LTEzLjEtUkVMRUFTRS1hcm02NC1hYXJjaDY0LVJQSS5pbWcsIG9uIGFuIFJQaTQgdy8gOEdCIFJB
TSBhbmQgYSA1MTJHQiBTU0QuICBJIGFtIHJ1bm5pbmcgYnVpbGR3b3JsZCBhcyBJIHR5cGUuDQoN
CkhUSA0KDQotIFN0ZXZlDQo=

From nobody Sun Jul 10 01:59:47 2022
X-Original-To: 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 096E03E03B0
	for ; Sun, 10 Jul 2022 01:59:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LgVZc6t6Qz3nCr
	for ; Sun, 10 Jul 2022 01:59:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657418390; bh=EMFUDbG6EpASpYONw0+Py3zC1f/QClcd24thVTehAjg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jXHtjX8vSGWgGnO9GhX66ZzW49QlnkkZd6c1Vx55ByOHU9aXT5E1gwsI5FHafdPAUsfMD17UGGcZHbQP20afMluSvCm6rvUAZXk/DILNuyl5XEcv6hEkg78rzhWjLTfY2XOVNhod6e4j+9h9q8yADGwoJa6f6c96bMPgu217273rEwZJhILd+lr4L4p1UKjkMFjAZE2l/lSNtTJTlMnQ1tU5pY0BcGeh+//KSgHI5AnnjlhUtS3FLM0RoTS6zqebPqNtK2aBhHjnnMP8pgjI/1mZT+jluzstXxx00Vn2UE5jTana8b68yvynRpAME9MxSRlONF8jHhYBtCkZOptlEQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657418390; bh=OqfMM/WE5Ku85qsSQY+SCJNpDJFOyq/GD62cMs7ucoV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rDf84ELYTxi5uB8j307skYzQJa2k47JxiHK5b/CnFqhi5PDIpnpwV7sBwCkchiqTwlMsER/xuydQ6yJisMgyeqjQzEkkK6TCYvCUiHTHk8J1FD7dd0yA5R4hZwVMOxmx1+meAFDd78ES6SWMi/pn0egfDRRxk3utCHGbcZD7cj5NAT1/8IG0ae4VzyBaxp0Oi3bAlOmSpgg1W/thV1mm4GLV1YpqruWL5hH+aSP4ZDX+EAG0sMeDkH7cYld1EeS9zfTlqiLTHz0dkJHeI0zlDB0z6eg1SN0fd6HSJUOwGjw9rbFidT3B6oWkNUVp//7DVJLaIDaTFnUXTynZ5LAelQ==
X-YMail-OSG: 8b7.QaAVM1neYtdEUHO.3MkWabWXrztGzBYydZE_D8jA13rB.Ej_x1RQMS19cek
 BPjc0DlKJ0qEYjhon6jQKiqWK5Uuazi7HRtJyXNblw3nnTca7Nnx10PjjimNtBibSHGlVn27yXBl
 Thcjw03rwHiMw1Sx3vDK16cFr3g3wPIPq0MXjjbHbyY5XViKVIMw1dhQ4m7eJLDLm8U8saTNKCjt
 zyUCfw.qU1CL6t_qxyeeZoZ1CLR4tTyivuOS80u3tRuTSYatT8cny4Tdo2MiGscFjun5NEu4LDse
 6Fn80i.SWNWuytsl7f003uI_O.8PQaqreCV3Vu8kf3bP9PhCX9nWBjvx4BafDAaMQ0sk0weOL8E6
 aP4ovjc8.pYpPSF8BHP_1uHFZqneDeDVT2TLetAUgbNDuFVfVY8roVINP.vQhYb85UVaYjwz9PLQ
 j2ZphMbHKJZGLVETAg2fxIBgd5Sd00ojuUEhKeuUhDeKoUGfwrFr.I9Z5RHWPqeO5t4ViY.YyZ2u
 f_JhGjSonNg2mPlWRFpyrsl9TrpMUpF1f4oca37rUjiNsU.5lj8_p4CKLdIm7EbzsmQXuT9hV7Ks
 i.dGk7LKRq.pVzMSS6bimf.pP2Poxtj0H3twe9VWtg2OdmbVG6zWX69VnjRAepeO9oxzfhZow2XF
 lCc13EmiQPTBvsDyJtRrmWkbF_tdLAn2Xe9TqYLnx8Kv1LkDaikOpsyL_S.WLX0eqSSlljM99UQ7
 HwUkBv1_u_82Uh8AbCZGpogVtl4MNLauB8FjoLmBMA4_ATkom_5xi802DiTVlfc2LJf6JeAOcBdx
 vE9rnJ2_q5d0UB60YL_4vhR6Bt3WCyOGfs0IIRgUgDajdRoOZyPjTQRrY59UviTksu0CcSTn7rlG
 1p75gflav1IyKzq9oH637tsxCyb.ObE0yZVHI5_V82HWWp4Vmizq_hBeoROUj3NhddGUqV8sklSl
 m4X9NoZPhING5MEupQH1bOBVoBdac7dYoq7LqRQrq8uv.znizbnMJICTmSqtFOELAAYg6R6Asm7i
 Chbx7mRUWktYwXW5y.k7utFk8iOtwGqfFbxIYUq57J8Y.pK2bT3axjnnSAfEJXIRnrah.VLi4qf3
 a4RXdYmFQpgzgIo2Dfx__k9E8_NQApzyLBTwJyer3K6UvT2wiJUtgRddDF4io0rqkEN45UvfhW6z
 A92i5HVRdV0UzkTRSttlc3GArbNCsFloyAPZcrDSGAYTt.veNGlQ48ndvRjNiZeAjmTqT1GRi7MJ
 lsa3N1WLD8s.pYT2hlAV4zRfeLTntMXoTZWW.DEDiY12oL19gsqR.SB4K64FHGHu1p1ZMVHqp.Fk
 6YbTFZSxA7.OdZtvPQXjGYbXtZmb3ZkQC.pYeFuMxmFnhEBGx6j5l6vfIyTT76K9n6mQYHB62lZS
 X7jbvxtTR5oJx3Y5a3DdztlFbFiCsTTnQ9YjwqLHILkKUckTks_jReRpT4qCIxGQIL7SF26waXZW
 1pNbOJDpa8sfd5.KikRH1rQCZtZ9Vi.uHI76ZNOzywyaPPV6xLMykqtT3r4XTNOmsDJwOsb0f6WR
 xmB1R3Om4EktAMe9VGyfMnXeijtz7EJwrizjHQxrGDXrGewkDBRyIy8CMIE_VqVdT2c2bssm9fqM
 WUedxddYoVJsDAIJ_P6hA4YpncBPEoyZ.vUhNgLNIpJdzYjkKfK7NbygyRcGEWFnAbKpE13zZOIW
 GtgmygMjM6Zda7kMuVGueKUtW0fOrbcDgOV4HUUq5apTkUFakiHeEmhmtknO31o7WaIT_DYqwGup
 h95BpOyPMcro4sOiUCxKGN0yRO8zYj7g_47.ER.zRJQrRpZ.qX7wLKfr3VTLGVuWxMFv3cvAi.pu
 9Q9JZo7nD7fYVDeC36BsXqmk37aG10zrnhvbVPymFPySySDk4DksAVpqHl2_zVX5144ZfeL7_qy3
 BgjDtcu35NjrplocbmBBWApeRkeM3XbcYDLfCV70L_tJycqlijWEX52j2BS0SdsvS_5vYf2r3mSK
 4QUT_y4Rml19Yx26EBFN_PFs8Dh33TwVQLPRgFPzxktNwlDUiCKdE5v9WBScOuStYv2AJeillOgs
 IShUPGMgO32KjQxrWJ1O0b7CnSEUQxrlSyqgLIm7i5uogf7uYPLOl_n42NqcR8LBuW8YlHgw1Z8v
 ypiVBlYSym86M7zSH7iGypZkHbCIUiCoZ8PQQbyMFgFMxHtEvvmOyPOeHyvo8Ip8DisEcjtn3Fzz
 GxjcM7bf0CBLTvn8UGzhReUM39ZImRCnhmrnrTe6QEXDUkrXaBVkEcIgqR17wDWfXTg9KvNwY
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 01:59:50 +0000
Received: by hermes--production-gq1-56bb98dbc7-28prh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 53aac7eaa1534f6abdcb979599b69622;
          Sun, 10 Jul 2022 01:59:48 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T
 vintage SOC) when dd'd to the example USB3 media then used to try to boot via
 USB3 port
Date: Sat, 9 Jul 2022 18:59:47 -0700
References: 
 
To: "freebsd-arm@freebsd.org" 
In-Reply-To: 
Message-Id: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LgVZc6t6Qz3nCr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jXHtjX8v;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.98)[-0.975];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 15:45, Mark Millard  wrote:

> On 2022-Jul-5, at 14:17, Mark Millard  wrote:
>=20
>> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:
>>=20
>> A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
>> B) The same media fails for USB3-port based boot attempts.
>> C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
>> D) An alternate type of USB3 media (USB2 compatible) booted via USB3 =
just
>> fine via 13.1-RELEASE.
>>=20
>> The details . . .
>>=20
>> I intended for for use in the Rev 1.4 8 GiByte RPi4B's
>> by first going onto USB3 media (of the same kind I
>> normally use on the RPi4B's with main and the like).
>> So, I tried:=20
>>=20
>> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \
>> bs=3D1m conv=3Dsync status=3Dprogress
>>=20
>> and then tried to boot the RPi4B via the media and it gets
>> the following (the kernel loads and runs but . . .):
>>=20
>> . . .
>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>> uhub0: 5 ports with 4 removable, self powered
>> ugen0.2:  at usbus0
>> uhub1 on uhub0
>> uhub1:  =
on usbus0
>> Root mount waiting for: usbus0
>> uhub1: 4 ports with 4 removable, self powered
>> Root mount waiting for: usbus0
>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
3
>> mountroot: waiting for device /dev/ufs/rootfs...
>> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>>=20
>> Loader variables:
>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>> vfs.root.mountfrom.options=3Drw
>>=20
>> Manual root filesystem specification:
>> : [options]
>>     Mount  using filesystem 
>>     and with the specified (optional) option list.
>>=20
>>   eg. ufs:/dev/da0s1a
>>       zfs:zroot/ROOT/default
>>       cd9660:/dev/cd0 ro
>>         (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>=20
>> ?               List valid disk boot devices
>> .               Yield 1 second (for background tasks)
>>     Abort manual input
>>=20
>> mountroot>=20
>>=20
>> Plugging into the other USB3 port and attempting the
>> power on boot just changes the port numbers from 3 to 2
>> in the sequence.
>>=20
>> Plugging into a USB2 port does not have the problem and
>> it completes the boot and operates. (The media is USB3
>> but USB2 compatible as well.)
>>=20
>> Adding to /boot/loader.conf :
>>=20
>> # First, 3 additions:
>> kern.cam.boot_delay=3D10000
>> vfs.mountroot.timeout=3D10
>> vfs.root_mount_always_wait=3D1
>>=20
>> and retrying via a USB3 port just results in:
>>=20
>> . . .
>> Root mount waiting for: usbus0 CAM
>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
3
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Root mount waiting for: CAM
>> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for =
10 more seconds
>> Mounting from ufs:/dev/ufs/rootfs failed with error 2.
>>=20
>> Loader variables:
>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>> vfs.root.mountfrom.options=3Drw
>>=20
>> Manual root filesystem specification:
>> : [options]
>>     Mount  using filesystem 
>>     and with the specified (optional) option list.
>>=20
>>   eg. ufs:/dev/da0s1a
>>       zfs:zroot/ROOT/default
>>       cd9660:/dev/cd0 ro
>>         (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>=20
>> ?               List valid disk boot devices
>> .               Yield 1 second (for background tasks)
>>     Abort manual input
>>=20
>> mountroot>=20
>>=20
>> So: same problem.
>>=20
>> For reference, from the media being plugged into a different
>> aarch64 FeeBSD machine running main:
>>=20
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
>> ugen1.5:  at usbus1
>> umass0 on uhub4
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>> umass0:6:0: Attached to scbus6
>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number REDACTED
>> da0: 400.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>>=20
>> The RPi4B is of a vintage that has the "3 GiByte DMA" issue
>> present, not that it would be likely to be contributing here.
>>=20
>>=20
>> So I then tried the sequence using a different type of USB3
>> media (also USB2 compatible), placed in a USB3 port to boot:
>>=20
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
>> ugen1.5:  at usbus1
>> umass0 on uhub4
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>> umass0:6:0: Attached to scbus6
>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number REDACTED
>> da0: 400.000MB/s transfers
>> da0: 228936MB (468862128 512 byte sectors)
>> da0: quirks=3D0x2
>>=20
>> For this media, the sequence worked and booted successfully.
>>=20
>>=20
>> So the issue is somehow specific to some USB3 media=20
>> used in the USB3 ports but not to others. "reset failed,
>> error=3DUSB_ERR_TIMEOUT" may need more time or better
>> recovery if a wider range of boot devices are to be
>> supported. May be the T7 Touch needs more than the
>> standard amount of time to reset as a USB3 device or
>> some such. (I've no clue about the details.)
>=20
> I substituted a 13-STABLE kernel.txz expansion and got the
> same result using that kernel. (There are not .img files
> for this currently.)

I took a different path of setting up a stable/13 based
media, based on my own build context but upgrading a
13.1-RELEASE starting point. This stable/13 variant boots
the RPi4B's just fine via the USB3 media that 13.1-RELEASE
failed to boot with. I'm not sure what the differences
that matter are.

For reference for the working stable/13 context and
other content involved:

# strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_=20
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 12:10:40
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Feb 25 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)

(/boot/efi/armstub8-gic.bin does not have very useful
version-string information.)

# strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20'
U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)

Note: To my knowledge, the RPi* firmware, armstub8-gic.bin
file, and u-boot.bin file above are all as they were for
13.1-RELEASE's image, other that for 13.1-RELEASE I had
also tried adding /boot/efi/timeout and I've left that
in place since then and I've added my usual
/boot/efi/config.txt material (that had also not made a
difference for 13.1-RELEASE).

(/boot/efi/EFI/BOOT/bootaa64.efi and
/boot/efi/EFI/freebsd/loader.efi do not have very useful
version-string information.)

# uname -apKU # manually line split
FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1301505 1301505


Unfortunately, it has been some time since a

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img

(a snapshot) has managed to build and be distributed.
I'm not sure what the result would be like for such at
this point.

Once such is available, I may do an experiment based on
just a stable/13 snapshot.

> But using:
>=20
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img
>=20
> does not have the problem.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 10 04:23:42 2022
X-Original-To: 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 DCB6C1CFD005
	for ; Sun, 10 Jul 2022 04:23:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4LgYmg58DRz4304
	for ; Sun, 10 Jul 2022 04:23:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657427025; bh=vt54lmKJRwLqdxpxO0N9PC39NH8iG9wCFYVIlfJWqKQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=nkgQLxmBYH1N5XbRk9yadVBrcLt/UreDeiPfS4E+bZ+DHFJqGSpcFoudk/ogr/cucZNgKjI0aeRaB4AUT2A/KYnMdYwT+V+oulgZufRQ10zE/J5Z9Zwt24565fqbofYf9O4OQOuVqAj1kjiyFlvx45hgo2rqIQnTV2nkA90hnkqkqgqGgmIFi+yqkfjABvl0HlY7/tXSFlL3lvFl5k4IWF9uDxRcQbAdgOlqdD5zqFHjcj18uzKaGhXVkxo2MRcKncWtXiKBxcodSp+8PbJTRtXmZnlCI7xYXC9lW2DCH6T7BZQq4CxUXcv0SzdcBm0m/DkFop6hb8h8SYPuYukWpA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657427025; bh=qTjG606GezQfB/zrq8zULw+444GLOjxZUFLieBj2pEY=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qnOizHEFkkkSMdpZB/90ZsW0gcj+qQd5dXqIh4wsVkYkUHzL3elYq8v8qqs5jjD8Wvp5Pl8gjdMB8qXiFZInekjh6IGLu0DQqguGmDAJu0pgesm+orMOy4ILZnvBgBSIk72BKQp034DyPvXVTVuECd6It2nxLJokYSRHswXJBpf8agCwHmJ5cqCTsyMa7e3c89Uzg9DJKo5ABpMAHSxGE1GdFhDW644tUCbQXhoXuPCvP+iFEO4ThQHEiuXjdvuf+Jo7/nLERJ9bGwrp9iR0J5MLcsiNHroQDsfRJo6NnuQZrUpEl/8SiTzY1I6sNHPQTe0cpsRCNQo0L3e7CKUQBQ==
X-YMail-OSG: gYh2wKsVM1m4f.RI6sPJI8ozSDR1XEVte6B6kQl5RchF6AGmdi8e0mXV5h8neoU
 e8BT_6v7Ls3UADP0Z_tKfHyyAj8IuMhPnjVyC1m74kIo2j3F3JcbFThSl2V9wMGZNcjg.5EtWiFI
 AMGY0RzWKS0dVTzbZDoL3DNUTmhZOTD2lyRe7SAvx6bIWkwsXbQCUw2P3KI3Q7fZoclYCj6YWeTN
 1kNu34pQAakZrS146IhaejqzF9jSsiIDu0q2y81BVSTHjdNHVyiUVNUoTpCTtdvvztScFAyHfo89
 CtfquU9uezahePdlbOfsTqObG27_j.1rdhoTtc8TthdkwwAOkpcF6tssfsLxADM8_lKEfHocXa4H
 B7bF1JmGF7_290TL.v7Drfb9YC2vLSNidXeAeZgWpYdIHukCjQ.W.oK94pEiO6dItbV3j.eWVwqm
 w.12C9c9GsOXzbtxp65da.cuK0cuUSH4d.nByX.8G9JOPJCcza8mzW2sBg_EtuJmbJvjlid7oZ7R
 isrJnfkZBWvTYNXTDTHuFNsqB.t3Lw9c8ugMIDPk3Z01Dg5_jDLzndcMZxYKtpbeN6Mi1i7Iqm64
 0dBXpDdswbog.TqbDMtdN6o.gXyjBbXZ7g0JzDBxBO3WdFRf35HiX7CPzT5U2N.ZGAooGz6aqeGy
 bxvjLwDo1aXRHePxWXqmCgEGyAn2Ke6sMDKntGfrodXLw1jBdZXZr4Kz4VHY2b1N2WlbYqGYtfkU
 lVRGQ8qa57JMx5DpRuEFiClYfLyxO9CSTFOucWtVrpbk7zoPC.GyW0636CDxJytx9qJHDCqKBTu_
 ie4gWdEd6aP5BQa69q3v_HwWl.nuzBBK2XuCUt4BpM4NfSKjumsqgLv8IbUMjqaxStsBN8d.D7c5
 OQ4guICI7BruT67rx0XE5hePwYPQseKRvA_Yg1INcYTLmAdu4KiIEE25X1qy6Z8v8N5Xkfjy6ch6
 kokwdiB7W6RRJ6IRmgvprXrJhQTX1SRQgToFhNbdgd71PulIE59U9t2FKdX9IkyXyGAxNh0rlGQ3
 XCQgaWCrP_ZjwvMj6c0SlUOtPe6bnaPKWvUZkgk_CiKA9_Ph79Rr8x65uEuPtIK996Y1zMFn8CUF
 OqLCZRAglWydEFniBkVLYcnSIwLCSNjdf8hMISyqnt0BYFseQR.e2wBOKVTw._T1Pf4RARQcURq9
 4x9uW5tpNYniyUUubhcpBjtSkunhDDKhqNNtpRlWc2ZsJiVyGSveSKG426cyWB0K.xZ_5ZIwFXv1
 Jb77i3E58Pr5JSu.jRppn7ishVfyYZLd3SbawhE7NVS6.41arGWjwsB7UpIKyIb07ppWfcpmD9HS
 Gyv.wRRR1pjo.1Oam1hRf5gFL4JxenaKt7AEfic7oRLHs9XxGfK0I_4_SpYBKUdFpyfESthgSAFA
 PfmZqlZkE9N_Qs85M78voSggwGSWCCWQlxnqx1YHwUsWI.alSwqNtTq9_rTRwNWSXij6vhsbLy.n
 IvfXw.vp1ibSX4OkGwpc.oCWwIVAj.9mQT5urabN4jn2o5cp5P9pKyUnTwWBLO.niqS3XTlADta0
 ieOir1fORFHaol9PBNho9uPDBH9T.OOphuO6UQORx1TCKrZNjr8JdWSrn701FTLOYt3h4h0ifz.U
 XF129SRQcesrP6s9vOzZxgAKZymCAMcECtj79WMyrnmdP_J50mUqzBa5kputB3MFNIEvrx5R39BN
 OjHrdru6.FH6Xm04DQqKJ87Vh32l43MHNgp5vZuqgFfzq9Jig30Iu.l0XDUsmfu5uwxixMuXAdTz
 RNBIAEO5_ZldcvjxW68PMrBvJknrjkdlh_BhcV46vWLzXOVWYeMdMTrqr8jzjNiQpP_LVVLq7YCq
 Bmr0ukjK8PTSQ41RE4Z1FVBdz5BBiejiEDVpcLGY0tNqTPdUs8Uv727QSsYYoP8bXnR9FLGUrF69
 EW5X.0yKj5nTOyrZkGuMMwQKnCwOOOk7G_jWALUuoVvZZXC1nNviiUvM7N7H8hfPz7Tf_XtrMIZt
 Q5bOngUC6D_N_cyTSVrb4ID_PdgGl.Y8ZENk_seDVG1pttZBs3SNnnI8r44FG0clHJKY0Vq8oFgS
 GTKnaRrlchu7MJMr3Jsx2_anm6ssXTDWUiW0IdJXDY.gEVZoaMJj2vsN40clbcGpqY9cjUwnjctl
 xgiAJfFJu3VSbUJ38oKGMgdZqIgNS1zMXvj3SfpQxd7fUk3fhmANHvj1sEuCQqF8SAs8mEgOMJKJ
 yxj8eI3oS9VaFRA.NPKBU94hJAmaLcqEQHbT8RXXkSC45L.oUNAKY4k8NgYfRYmWTTXBxDzQ-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 04:23:45 +0000
Received: by hermes--production-gq1-56bb98dbc7-r7f9c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8522a468239f1b16f16898db547d0c40;
          Sun, 10 Jul 2022 04:23:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T
 vintage SOC) when dd'd to the example USB3 media then used to try to boot via
 USB3 port
Date: Sat, 9 Jul 2022 21:23:42 -0700
References: 
 
 <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com>
To: "freebsd-arm@freebsd.org" 
In-Reply-To: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com>
Message-Id: <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LgYmg58DRz4304
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=nkgQLxmB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[arm]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Jul-9, at 18:59, Mark Millard  wrote:

> On 2022-Jul-5, at 15:45, Mark Millard  wrote:
>=20
>> On 2022-Jul-5, at 14:17, Mark Millard  wrote:
>>=20
>>> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:
>>>=20
>>> A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
>>> B) The same media fails for USB3-port based boot attempts.
>>> C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
>>> D) An alternate type of USB3 media (USB2 compatible) booted via USB3 =
just
>>> fine via 13.1-RELEASE.
>>>=20
>>> The details . . .
>>>=20
>>> I intended for for use in the Rev 1.4 8 GiByte RPi4B's
>>> by first going onto USB3 media (of the same kind I
>>> normally use on the RPi4B's with main and the like).
>>> So, I tried:=20
>>>=20
>>> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \
>>> bs=3D1m conv=3Dsync status=3Dprogress
>>>=20
>>> and then tried to boot the RPi4B via the media and it gets
>>> the following (the kernel loads and runs but . . .):
>>>=20
>>> . . .
>>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>>> uhub0: 5 ports with 4 removable, self powered
>>> ugen0.2:  at usbus0
>>> uhub1 on uhub0
>>> uhub1:  =
on usbus0
>>> Root mount waiting for: usbus0
>>> uhub1: 4 ports with 4 removable, self powered
>>> Root mount waiting for: usbus0
>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
3
>>> mountroot: waiting for device /dev/ufs/rootfs...
>>> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>>>=20
>>> Loader variables:
>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>>> vfs.root.mountfrom.options=3Drw
>>>=20
>>> Manual root filesystem specification:
>>> : [options]
>>>    Mount  using filesystem 
>>>    and with the specified (optional) option list.
>>>=20
>>>  eg. ufs:/dev/da0s1a
>>>      zfs:zroot/ROOT/default
>>>      cd9660:/dev/cd0 ro
>>>        (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>>=20
>>> ?               List valid disk boot devices
>>> .               Yield 1 second (for background tasks)
>>>     Abort manual input
>>>=20
>>> mountroot>=20
>>>=20
>>> Plugging into the other USB3 port and attempting the
>>> power on boot just changes the port numbers from 3 to 2
>>> in the sequence.
>>>=20
>>> Plugging into a USB2 port does not have the problem and
>>> it completes the boot and operates. (The media is USB3
>>> but USB2 compatible as well.)
>>>=20
>>> Adding to /boot/loader.conf :
>>>=20
>>> # First, 3 additions:
>>> kern.cam.boot_delay=3D10000
>>> vfs.mountroot.timeout=3D10
>>> vfs.root_mount_always_wait=3D1
>>>=20
>>> and retrying via a USB3 port just results in:
>>>=20
>>> . . .
>>> Root mount waiting for: usbus0 CAM
>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
3
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Root mount waiting for: CAM
>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for =
10 more seconds
>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2.
>>>=20
>>> Loader variables:
>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>>> vfs.root.mountfrom.options=3Drw
>>>=20
>>> Manual root filesystem specification:
>>> : [options]
>>>    Mount  using filesystem 
>>>    and with the specified (optional) option list.
>>>=20
>>>  eg. ufs:/dev/da0s1a
>>>      zfs:zroot/ROOT/default
>>>      cd9660:/dev/cd0 ro
>>>        (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>>=20
>>> ?               List valid disk boot devices
>>> .               Yield 1 second (for background tasks)
>>>     Abort manual input
>>>=20
>>> mountroot>=20
>>>=20
>>> So: same problem.
>>>=20
>>> For reference, from the media being plugged into a different
>>> aarch64 FeeBSD machine running main:
>>>=20
>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
>>> ugen1.5:  at usbus1
>>> umass0 on uhub4
>>> umass0:  on =
usbus1
>>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>>> umass0:6:0: Attached to scbus6
>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number REDACTED
>>> da0: 400.000MB/s transfers
>>> da0: 953869MB (1953525168 512 byte sectors)
>>> da0: quirks=3D0x2
>>>=20
>>> The RPi4B is of a vintage that has the "3 GiByte DMA" issue
>>> present, not that it would be likely to be contributing here.
>>>=20
>>>=20
>>> So I then tried the sequence using a different type of USB3
>>> media (also USB2 compatible), placed in a USB3 port to boot:
>>>=20
>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
>>> ugen1.5:  at usbus1
>>> umass0 on uhub4
>>> umass0:  on =
usbus1
>>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>>> umass0:6:0: Attached to scbus6
>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number REDACTED
>>> da0: 400.000MB/s transfers
>>> da0: 228936MB (468862128 512 byte sectors)
>>> da0: quirks=3D0x2
>>>=20
>>> For this media, the sequence worked and booted successfully.
>>>=20
>>>=20
>>> So the issue is somehow specific to some USB3 media=20
>>> used in the USB3 ports but not to others. "reset failed,
>>> error=3DUSB_ERR_TIMEOUT" may need more time or better
>>> recovery if a wider range of boot devices are to be
>>> supported. May be the T7 Touch needs more than the
>>> standard amount of time to reset as a USB3 device or
>>> some such. (I've no clue about the details.)
>>=20
>> I substituted a 13-STABLE kernel.txz expansion and got the
>> same result using that kernel. (There are not .img files
>> for this currently.)
>=20
> I took a different path of setting up a stable/13 based
> media, based on my own build context but upgrading a
> 13.1-RELEASE starting point. This stable/13 variant boots
> the RPi4B's just fine via the USB3 media that 13.1-RELEASE
> failed to boot with. I'm not sure what the differences
> that matter are.
>=20

Well, the kernel.txz was based on:

Thu, 30 Jun 2022
	=E2=80=A2 git: 70fd40edb869 - stable/13 - debugnet: Fix an error =
handling bug in the DDB command tokenizer Mark Johnston

via:

Fri, 01 Jul 2022
	=E2=80=A2 New FreeBSD snapshots available: stable/13 (20220701 =
70fd40edb86) Glen Barber

while my build was based on:

stable/13-n251684-815db559eccc-dirty
(815db559eccc is from Wed, 06 Jul 2022)

Between those are:

Fri, 01 Jul 2022
	=E2=80=A2 git: 39cd7aa134df - stable/13 - USB: add quirks to =
XHCI Bjoern A. Zeeb
	=E2=80=A2 git: 66754c01ff95 - stable/13 - XHCI: clear warm and =
port reset Bjoern A. Zeeb

and that last mentions port reset handling explicitly.
It is, at least, suggestive.

> For reference for the working stable/13 context and
> other content involved:
>=20
> # strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_=20
> VC_BUILD_ID_USER: dom
> VC_BUILD_ID_TIME: 12:10:40
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Feb 25 2021
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
>=20
> (/boot/efi/armstub8-gic.bin does not have very useful
> version-string information.)
>=20
> # strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20'
> U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)
>=20
> Note: To my knowledge, the RPi* firmware, armstub8-gic.bin
> file, and u-boot.bin file above are all as they were for
> 13.1-RELEASE's image, other that for 13.1-RELEASE I had
> also tried adding /boot/efi/timeout and I've left that
> in place since then and I've added my usual
> /boot/efi/config.txt material (that had also not made a
> difference for 13.1-RELEASE).
>=20
> (/boot/efi/EFI/BOOT/bootaa64.efi and
> /boot/efi/EFI/freebsd/loader.efi do not have very useful
> version-string information.)
>=20
> # uname -apKU # manually line split
> FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
> stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
> =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72
> arm64 aarch64 1301505 1301505
>=20
>=20
> Unfortunately, it has been some time since a
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img
>=20
> (a snapshot) has managed to build and be distributed.
> I'm not sure what the result would be like for such at
> this point.
>=20
> Once such is available, I may do an experiment based on
> just a stable/13 snapshot.
>=20
>> But using:
>>=20
>> =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img
>>=20
>> does not have the problem.
>=20

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 10 05:27:50 2022
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 C0BA61D05701
	for ; Sun, 10 Jul 2022 05:27:55 +0000 (UTC)
	(envelope-from hello@paulwrankin.com)
Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LgbBf5PvWz49jG
	for ; Sun, 10 Jul 2022 05:27:54 +0000 (UTC)
	(envelope-from hello@paulwrankin.com)
DKIM-Signature: a=rsa-sha256; b=eJY3Fr3Kcm3Y/lS7qJtAicTyKh5uvxLPh9IDxkLiA9TiWbeXTHmTyH3DUoKbvlzqFmT3SzhUiMcJSky0z2wj02dfXkPZ3p32q0E47IWndNvUCUraLv1clrHcJiBbIPJwTQRtk6nX7FW2Acc4nJr3yJmpx2VZCHO7+vlbW8QtKwyyv0B6N1h2acyp55FlCKeCIo0FeYIVl9+atFu86fdlBNhCRNdcicPqbKOBG/MSTW2FgG/zMwpFydrrRxo1viCYCviEGridndy9vXIduLS667datZU0VliYsA2i+AWkqFoqB1c/cZ46JHVGw6fP4O7ooQb4jki3vH53BU1MQxDrvg==; s=purelymail3; d=purelymail.com; v=1; bh=OvPatwnBShYA13u0j1G0Q2xddUKZpnxQevgKmBYlNmY=; h=Feedback-ID:Received:From:To;
Feedback-ID: 791:353:null:purelymail
X-Pm-Original-To: freebsd-arm@freebsd.org
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 2127059562
          for 
          (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
          Sun, 10 Jul 2022 05:27:52 +0000 (UTC)
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
Date: Sun, 10 Jul 2022 15:27:50 +1000
From: "Paul W. Rankin" 
To: freebsd-arm@freebsd.org
Subject: Which aarch64 release image is appropriate for the Pinebook Pro
 (rk3399)?
User-Agent: Purely Mail via Roundcube/1.5.2
Message-ID: 
X-Sender: hello@paulwrankin.com
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by Purelymail
X-Rspamd-Queue-Id: 4LgbBf5PvWz49jG
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=purelymail.com header.s=purelymail3 header.b=eJY3Fr3K;
	dmarc=pass (policy=reject) header.from=paulwrankin.com;
	spf=pass (mx1.freebsd.org: domain of hello@paulwrankin.com designates 34.202.193.197 as permitted sender) smtp.mailfrom=hello@paulwrankin.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[paulwrankin.com,reject];
	R_SPF_ALLOW(-0.20)[+a:sendmail.purelymail.com:c];
	R_DKIM_ALLOW(-0.20)[purelymail.com:s=purelymail3];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[purelymail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello,

Which aarch64 release image is appropriate for the Pinebook Pro=20
(rk3399)?

n.b. the Pinebook Pro is a different machine to the Pinebook (for which=20
there exists a dedicated image).

I seem to recall seeing somewhere to use the ROCKPRO64 and replace the=20
bootloader? If so I=E2=80=99m comfortable doing this.

I=E2=80=99m aware of the custom image by SleepWalker on the forum, but I=E2=
=80=99d=20
prefer to use an official release image if possible. (Also this image=20
requires an old version of u-boot, which necessitates disabling the=20
PBP=E2=80=99s eMMC.)

Warm regards,
Paul

From nobody Sun Jul 10 19:26:02 2022
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 241A81D00363
	for ; Sun, 10 Jul 2022 19:26:12 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lgxnt5k7jz3jZm
	for ; Sun, 10 Jul 2022 19:26:10 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657481168;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:Date:Message-Id:Subject:From:Cc:Date:From:Subject:Sender;
    bh=rZ5gviWlhmznRpRypZgJd5Q+kHHMxunQgb+oTvA3sZs=;
    b=YOKqXWtlH0Zl4ZX1Z+W7NUaFl962TUup8fqha2s37efdghOA4sehVDkjOQqGeysFsZ
    yVifNZBbrmO6uQq1y9HSA1KPkXJ9d1NyvETiaFmcNEmSjcnhqDz8dSek0uncvbRjbcmd
    b6T1InSCnnJyJ5IftBrTnOmK4CYSvUzW8vUNIvx8Jc3Fti/SUJLWRbKqjTw5Kl1wdEUq
    EDmPtTrlKddb+G7qmk89AHs1ik3ebsaq+ay7c68q2Ff4VrSrDil4k+2OMDyd3f4+ZlF+
    MB8YdSsCoZp4S2T2u0p0QCrCWo0Xo9z3f4WZSGLjhhY68hYpojtavx7O4opIq7DAlkYl
    uQrw==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6AJQ8cwo
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Sun, 10 Jul 2022 21:26:08 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id F008863910
	for ; Sun, 10 Jul 2022 21:26:07 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Partition layout of ARM SD card images
Message-Id: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
Date: Sun, 10 Jul 2022 16:26:02 -0300
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lgxnt5k7jz3jZm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=YOKqXWtl;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.20 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[85.215.255.20:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[cyclaero.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):

# mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
# gpart show md0 md0s2

   =3D>     63  6291393  md0  MBR  (3.0G)
          63     2016       - free -  (1.0M)
        2079   102312    1  fat32lba  [active]  (50M)
      104391  6187041    2  freebsd  (3.0G)
     6291432       24       - free -  (12K)

   =3D>      0  6187041  md0s2  BSD  (3.0G)
           0       57         - free -  (29K)
          57  6186880      1  freebsd-ufs  (2.9G)
     6186937      104         - free -  (52K)

The start of the fat32 boot slice s1 (containing the u-boot) stuff is =
neither aligned to 1M nor to 4k, it starts on an odd base. The start of =
the BSD payload slice s2 and its size are odd as well. The padding of 57 =
blocks within s2 lets the UFS partition start on a globally even base, =
namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned =
(104448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =
=3D 51), however all this keeps looking strange.

Are there reasons for this partition layout besides making it look more =
interesting? If yes, some insights would be good.

For the time being, I created a second SD card from the initial one for =
my RPi 4, and it's partition table is as follows:
=20
# gpart show mmcsd0 mmcsd0s2
   =3D>      63  62410689  mmcsd0  MBR  (30G)
           63        25          - free -  (13K)
           88    102312       1  fat32lba  [active]  (50M)
       102400  62308352       2  freebsd  (30G)

   =3D>       0  62308352  mmcsd0s2  BSD  (30G)
            0  56623104         1  freebsd-ufs  (27G)
     56623104   5685248         2  freebsd-swap  (2.7G)


From nobody Sun Jul 10 20:05:54 2022
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 A63B81D0596F
	for ; Sun, 10 Jul 2022 20:07:40 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lgyjl69PLz3nKQ
	for ; Sun, 10 Jul 2022 20:07:39 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 26AK5tTk079390
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 10 Jul 2022 13:05:55 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 26AK5sYu079389;
	Sun, 10 Jul 2022 13:05:54 -0700 (PDT)
	(envelope-from warlock)
Date: Sun, 10 Jul 2022 13:05:54 -0700
From: John Kennedy 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm 
Subject: Re: Partition layout of ARM SD card images
Message-ID: 
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.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: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
X-Rspamd-Queue-Id: 4Lgyjl69PLz3nKQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.79 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[phouka.net];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:
> ... The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
> 
> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.

  I think there are historical reasons, probably more with not "wasting"
space on small SD cards (~512 byte blocks).  I haven't had it bite me
recently, at least, but I imagine the FreeBSD folks are trying (perhaps
vainly) to keep image count to a minimum.  I think I was tweaking my
images from RPI2 and later to 4K and 1M like you are to line up with the
storage I had them stored on and the filesystems inside the partitions.

From nobody Sun Jul 10 20:22:06 2022
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 25C8B1D07ACD
	for ; Sun, 10 Jul 2022 20:22:12 +0000 (UTC)
	(envelope-from jsm@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 4Lgz2X0cZBz3ppy;
	Sun, 10 Jul 2022 20:22:12 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657484532;
	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=Ih2oWh0eDyx9p+BNjhE2O2V9V1OcZru3Hli6hpd/Keg=;
	b=YS9P1WfuLE7MJ2yXOR77t6vflGnRqKxxLt0ql5BPteYkP5lR8Zvcwm+id92UE7T0CPUoTH
	KzlVkzw5Or28bP2GSDq36dNuMjIipbnQVIHHnzpVAM8aOwfeNractwO1C4snl0eJANr7DC
	5QuXOCdRLN8zVV8Ra/WxiSRs2LkV/kSO+qwDfD7hOofiXBQ+7MZMFToUY5NlMUfiVtZ6PE
	Sm5j7ANoOdnGrItmE+BWfzf7M8cxKuz5y3CLRjzWmK8CTsidaKdLEEzXsfvtpSAJF5bF8n
	fyWcN2aF1U3jrdzQDBvGYJugS0UACYkga3NXfKnKlQc9JZGBHPw64VYHc6htdA==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lgz2W4MKcz1LQy;
	Sun, 10 Jul 2022 20:22:11 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: 
Date: Sun, 10 Jul 2022 22:22:06 +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:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Which aarch64 release image is appropriate for the Pinebook Pro
 (rk3399)?
Content-Language: en-US
To: "Paul W. Rankin" , freebsd-arm@freebsd.org
References: 
From: Jesper Schmitz Mouridsen 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657484532;
	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=Ih2oWh0eDyx9p+BNjhE2O2V9V1OcZru3Hli6hpd/Keg=;
	b=k3Ex130auEoTPuG3Wza1qG4zoSbtqtBl+ftOJkQixNiPoNoz3afDgvIUijX6N5CbkpTeKT
	shkAbWIPpti+iVE/O2iL1zeUl+fWrm9kHWzgVdXZoteTqrsHIa4ZpieA5SMpgBzbbEdaj5
	/tAmQkCCJnRWbFE5RPx4f2WI9ffuZZHC/P8B+vDYcSiLV1eiJ7FNTWP9oujq/8ollA7vA6
	lwj8/4Rvzk6Qw4nWfPZTgGorH1BAsa2N+7ON3OiRPtkU8Do6zYUCDHJkQfXZp2uWvyCtFV
	CG1hto2OCnQ3Qnn6qNf+ROvLTJ/RayiHvH5Lb/7mmvfbdCTELPU5y7DgY+wVpQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657484532; a=rsa-sha256; cv=none;
	b=r3ojx2cpd9llvYqdIbGmqJfPurORzBf1KA6NEoro+URrXqwc4WCOQI7Do29sZHvpAZPmTW
	5nb7NnFrDFSg+nqdCn11iRVIOBYHhiHFDHlrRX4nMfd7Cw1tl3SSwkqAg+16UVAOc3AqQH
	HkWoX0zWnVHdoW+2Ql+k1cg+fZQE1YmmZCa+PoT34e5MC+wEvLm1ZQPovaFNtvanNwPYML
	qzSqbeM7mQmOfZTR8EKKmvUYExqtpmI0g/Rx8kDXYJlthqhdCXFlIx59JjZtau5uwNkS1W
	OfWR7bbkA8nSiJiGuqxLhh9cRwst6N6h4cEhhnbnPIZQQ+hFHfSo0wk75AiaKg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



On 10.07.2022 07.27, Paul W. Rankin wrote:
> Hello,
> 
> Which aarch64 release image is appropriate for the Pinebook Pro (rk3399)?
> 
> n.b. the Pinebook Pro is a different machine to the Pinebook (for which 
> there exists a dedicated image).
> 
> I seem to recall seeing somewhere to use the ROCKPRO64 and replace the 
> bootloader? If so I’m comfortable doing this.
> 
> I’m aware of the custom image by SleepWalker on the forum, but I’d 
> prefer to use an official release image if possible. (Also this image 
> requires an old version of u-boot, which necessitates disabling the 
> PBP’s eMMC.)
> 
> Warm regards,
> Paul
> 
Hi
An official release is not really available yet, I wrote about the 
subject in the FreeBSD Journal which tries to guide towards a recent
(mostly) official source build. The article is here 
https://freebsdfoundation.org/wp-content/uploads/2022/04/FreeBSD-on-the-Pinebook-Pro.pdf
It has sounds pathces and panfrost and not the least a working display 
port for the panel.
Some errors have probably sneaked in in the article please feel free to 
complain to me/ask me for details. It might also already be a little 
outdated IIRC for instance the mixer patch does not longer apply and is 
not necessary any more.

Regards
Jesper

From nobody Sun Jul 10 20:48:59 2022
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 61D2417FBB51
	for ; Sun, 10 Jul 2022 20:49:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4Lgzdd6C4tz3sbp
	for ; Sun, 10 Jul 2022 20:49:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657486147; bh=qOURTfGhCSCiMrv4VehZUaWXzHwargUKEEPaCHLGf4E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cMGHlrbmKTb4CtW2aUOBgznpqtyVLVdKZCQoxLlQCevaEW8Wt8JhUqIQ+M6shoWJ20NHrz8rfDNxq9TyQmvypyZZ2yfPI4S8H/JMWZHjv3quuJbSU1X9eD/S8yhVV4M5O8igm5EzyK8INF44I0ybC9lLV0tDlgAX5D9wBpR56rwXV1bTGkz5ALim7d1ImzPoBptCaWhW0NjqyoCLa/ryryxskc8fuc7CIWWH1vS7Gx0zACnhf5Yptt18T1vDBIVkw4qtSnQWDy0jVMYq0L+GcbAinhKRP3GJiXcOPVkw9CagXq6kCs0WeA4ptve9eIYVh79sOi3BX4DHSJvKKyq4Ow==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657486147; bh=ebwCrPkOMyUfjgnkU55ovTgCz6La56wQdWSlL+cqzZP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=b1vvdCoekJaRsgUe18wm+52Awpc9YlR4JzzRoKOT0OkVG3rXW4alnPv8rF7GYOGDkIFYGzi7vSk0ZVOMc4QgfTFa+8zR7DKqQ7Lpq+QxBnwavlywR3BnhQTc8OFKCmSFn8mAq01lAKuuKFy4XvJrmyX5/NYWU8okT0DUjsNY9le7ZdGVNbcBcvvTVuHiL99c+7HwJY0PAEjXCbexIdu784EvqkTzeUv+IZT9Ql0JRxR5gOPHiabtvwgbOFGV6SS+py2iw++AHIrKdcUR0jnl8pT4a9iMdYxBkfQvfpR5gRBd590F8XxjNWh+53yj5MGkEbOV1qRdSmsoV7fvZ9uRuQ==
X-YMail-OSG: yExvQ94VM1nzQZg4KtUaU7MggAT3g__p8kXmu_6gd6M7QBidA62nGw2e_P3p9Ti
 YecsmDwrYvQq_Ql41uj4oMxYiBc4QOwc63Ve.oUJIdxJbfP5PIx6FoArKUs_wK1x180dVkOKjSqF
 t4kTRPzk_vs8fdWKPUljVduG2PbwKtMhlEoKSZBv7ElCLHp2Bf60xQVybBgED6KbW4SkkgT6MJ1p
 vWTLJdhw8z5F5U_x9ajzPtOWROELC6PNHU3sYTe.DLdaiiGpBkivZyixtBg_m0VbdkiF2TH3j.Vv
 uo6YS00Fp_8yXYLVBljIW.Wwl.zl8T8YrgfPHJgC4jwURayyDlul3zf6wJw7xJs2WlEUho7Nbyt1
 5ZuPgOHNe8Ms5_Sc609hLJKFc2iUYU80UcPbP1hPi_eEXZgfI8XavQ57GKjNy.5_1ao0L8swlRwb
 _YIQNVEqU7x73BJtE0WTGxa3M.NgHNfcQjsGD9k72kx17mEcvsmmhBARPTom6BbDdRgy13wX.hx2
 4c.u_hi2tuemErHBn0pK9iHUiKitU6hBLBL5_P664PxiN_OB9CM9eGFnILIXYRXGvBUQ4sq01Fhz
 aTzbJEOcQkmalOvQybi.5wqBVfm1K.Vv4vMfJfNs4_9gbU4wBqRxUhXJvdZ2wo8fDjLPkB4g24bZ
 erzC0_ByMz70xDhKz4z0n0Ytntbi3pGS2B1f2YDCa4JKaGoZrMORVqHVdMCd0_uPORjNdXuK3SsJ
 z9xgyNnaTygYQHJ6yDvtiYze8ajvky5tNKo1ZCWoA96eRlGNPCnFM7jhW3P4Mm.MEXuv.2KahZdy
 VoFAU_8DWshkBAyOCzz9PX0Ib4O0fD.Ny2tnOvjSAdkI8XJ9Jc5KGiS4yZHuXi9mHOrBUZ2sfdbc
 BEwBX2J6c2fh4O.dd0qkIbMz2O_mX0ajibhxTpjcK0oyjKdgCEX3BM21jw8mzWp4cpnXiygdTbER
 XK2uc0M52aZ7ykkXGdNmCwQ2Uq0h2082uksX6ZFECxqPbjjjI0NHsZXh3w2HUG9r7nWNaEVxhcHV
 JvLgpbxgYk7k_BAeIk2EJIgSCWmB71DvVrAbDtDIsPVqIaoX42_nJfy4OeR9O1N6ACJq_y03a405
 4VFUl.XHP4CpSLiMQyfUeQ533aT5Dh4pdpCiwvxcCKRsamC4N4UjPY8LCG46ppUzjxp1lZ8TmPtb
 1.pIZ8SleGr.Q0vwpRJdvv53guGE81vrWEGWgw6t8b_YzIYNIZk2yRACD4Oj9rw9xyx_GxCcamlB
 CwlGKBzah8punUo_Qu9rkIjyQoFOblyOvTTFPR0ORnNzBJY..kJkGYX8dDqPviSfLFxUBZi98Yt6
 luKJ88qKSSld4QdcqsurcSK2lVnmZtoDW5CF1fbfll07K8PAgc199vkAAxKcxTte1Oe9DfyfwJyZ
 7rsQIEI4mJ6jCTxlzNdkriu.sZLGwH1oincZzAxWCAafHYk92qTLCtFZz5P.yc1VUYJCPeEzRcev
 wNr1wWbDqBC6QXbRmTwRjqm8a36cyA2RB5aATwpL1m_AL0Wjg_jFNS_8AuG5IXJe.gZB7aOAi9Wj
 Jn_g8Ph8n7Dg4O0nRNDPGoTQQv8BaJRAH1iTmg0TGdUSKb0U58IhhUdyr70mbUJTlr8SF6TM0VxD
 MYtuuVilAdJCoCOA_b_qx5LT8gREcuSRtOf0WGk4kjxgNjuyPF6IsbOK4JgkIVUJi_UicK8ZkoIP
 yEpGE4BoaTJida1MO2b1EkHJjwON.FUfYstn6J8i0ku3pyCetjoAjjDrVa5jr_vn6udT5skHezNb
 sDbmj0gxdTOACoimQucwmLCmxr8ZQHm9A6RYPjxAJTT1mFf11gk_LAlVuaEYkejasZgupkm1Hgkq
 bTXk065csQW5IkwKpFSlxNYdeviCb8uMlluHQn8jJ8exxhIyKZgYwGZlCwJtu8rEgXqrTmFaTak9
 H3i6U6VaPSA6dTALNIRT9TZmf_w2O38sCCiSzFL2ntgXLHde3cCyC9kAJWm3wcbAHxW1plx6NTvh
 900uCFrk35m5wPhbflVttOxLPPac9NZc9L5nwylBmuitbaGqPF3HLDo957T_34g0S1RhK.JztocR
 mYp9h7QwzTr988z2v7lI6rVt5Sb7IvM6SdTOIzuVOzMOslRljVnGEAupcJytyDUCPyuCwDDW8GBQ
 o_i9vB9F8nB8DdUhPWvVDmtbBM9hAJece8TV2DHGTmk5m76PdpZY1GrTvCb3RBsqflHrorPuf4BY
 _mRW.6oguyQJ25o7dcLJ_3eVThHJvOh_nTlJGaQGJia6vSMhxN30wcfpybcMggSLkrsbZKFvBx5M
 0Gw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 20:49:07 +0000
Received: by hermes--production-bf1-58957fb66f-2wrgg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e16054982ca398ef5855650a70327d6b;
          Sun, 10 Jul 2022 20:49:01 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
Date: Sun, 10 Jul 2022 13:48:59 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lgzdd6C4tz3sbp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=cMGHlrbm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.73 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.75)[-0.749];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_HAM_MEDIUM(-0.48)[-0.479];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  =
wrote:

> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>=20
> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> # gpart show md0 md0s2
>=20
>   =3D>     63  6291393  md0  MBR  (3.0G)
>          63     2016       - free -  (1.0M)
>        2079   102312    1  fat32lba  [active]  (50M)
>      104391  6187041    2  freebsd  (3.0G)
>     6291432       24       - free -  (12K)
>=20
>   =3D>      0  6187041  md0s2  BSD  (3.0G)
>           0       57         - free -  (29K)
>          57  6186880      1  freebsd-ufs  (2.9G)
>     6186937      104         - free -  (52K)
>=20
> The start of the fat32 boot slice s1 (containing the u-boot) stuff is =
neither aligned to 1M nor to 4k, it starts on an odd base. The start of =
the BSD payload slice s2 and its size are odd as well. The padding of 57 =
blocks within s2 lets the UFS partition start on a globally even base, =
namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned =
(104448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =
=3D 51), however all this keeps looking strange.
>=20
> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.

The layout details are more specific to the aarch64 RPi* context
than to general aarch64 SD card images. For example, the Rock64
image is different:

# mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
# gpart show md0
=3D>     40  6291376  md0  GPT  (3.0G)
       40    32728       - free -  (16M)
    32768   102400    1  efi  (50M)
   135168  6156160    2  freebsd-ufs  (2.9G)
  6291328       88       - free -  (44K)

The 32768 is associated with:

# more /usr/local/share/u-boot/u-boot-rock64/README=20
U-Boot loader and related files for the Pine64 Rock64.

To install this bootloader on an sdcard just do:
dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync

where the sizes are:

103411 for idbloader.img
793560 for u-boot.itb

In other words: assocaited with having room for
the idbloader and U-Boot as required by the Rock64.
[Most U-Boot's(/whatever's) are not placed inside
a file system and the positions/sizes vary. The
Rock64 is just an example that I happen to have
access to.]

[If I make my own partitioning, I tend to use the 32768 so
U-Boot/whatever fairly generally have room to be replaced.
But I've not checked if any u-boot/whatever ports require
even more space up front. I tend to set up to also allow
the RPi* to boot as well as the likes of the Rock64 (or
whatever).]

Looking at what the official raspios arm64 images look
like, for example:

=
https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_a=
rm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz

# mdconfig -a -u 1 -t vnode -f =
2022-04-04-raspios-bullseye-arm64-lite.img=20
# gpart show md1
=3D>     33  3907551  md1  MBR  (1.9G)
       33     8159       - free -  (4.0M)
     8192   524288    1  fat32lba  (256M)
   532480  3375104    2  linux-data  (1.6G)

Note the 256M fat32lba instead of only 50M. This dates back
to:

QUOTE
2019-06-20:
  * Based on Debian Buster
. . .
  * Boot partition size set to 256M
  * Linux kernel 4.19.50
  * Raspberry Pi firmware 88ca9081f5e51cdedd16d5dbc85ed12a25123201
END QUOTE

rpi-update has logic that can produce the following
kind of message:

QUOTE
Partition size $(( $PARTSIZE >> 20 ))M may not be sufficient for new Pi4 =
files
This could result in a system that will not boot.
256M FAT partition is recommended. Ensure you have a backup if =
continuing.
END QUOTE

It has had that since 2019-Jun-24, 882f5c1 in:

https://github.com/raspberrypi/rpi-update/commits/master/rpi-update

I do not know when the 8192 usage started.

It is possible that the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
structure just dates back to matching far earlier Raspberry Pi
images. (I did not look that far back.)

> For the time being, I created a second SD card from the initial one =
for my RPi 4, and it's partition table is as follows:
>=20
> # gpart show mmcsd0 mmcsd0s2
>   =3D>      63  62410689  mmcsd0  MBR  (30G)
>           63        25          - free -  (13K)
>           88    102312       1  fat32lba  [active]  (50M)
>       102400  62308352       2  freebsd  (30G)
>=20
>   =3D>       0  62308352  mmcsd0s2  BSD  (30G)
>            0  56623104         1  freebsd-ufs  (27G)
>     56623104   5685248         2  freebsd-swap  (2.7G)



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 10 21:00:42 2022
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 6E90217FF0C3
	for ; Sun, 10 Jul 2022 21:00:43 +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 4Lgzty71vZz3wWB
	for ; Sun, 10 Jul 2022 21:00:42 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4Lgzty660Gzdjv
	for ; Sun, 10 Jul 2022 21:00:42 +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 26AL0gxi025751
	for ; Sun, 10 Jul 2022 21:00:42 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26AL0g9p025750
	for freebsd-arm@FreeBSD.org; Sun, 10 Jul 2022 21:00:42 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202207102100.26AL0g9p025750@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, 10 Jul 2022 21:00:42 +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="16574868423.cbCbC0B.24073"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657486843;
	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=MOMOzL0P1plts6DuzXxCwUtbeFku9FkM1bWB4iDXEvE=;
	b=k2K6zFvzd7QH5XqimyvkuSWTaG8rK2dLaKCbXrNUJjyV0TJsvuR5C1yRxQCypPNJshzNm4
	ONJx+FvwfUudQg55Euy9f5r86QY8JgwU6U2lxbPdlZKMX8edw0PesN7wTSGkcfNzKyVDLF
	/cE31fT9tMBiqqvzInPYCuk9BlOQAafR/opj4r33LGYqjiUyZ7k5Z37OJLVxCgZn7WQMAE
	9fe6KJMlIlFc6Dutc5B6iULs4RqsxVspQCLB6xPVgIK1NKvBUnwBu1eybrkfzg5c6BjZ/A
	S6wRTpDNBIxMrDWlQ3Mt3xC3pB+UxicTKz3ONkn8qdLxuQG0B655jrVGddRJeg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657486843; a=rsa-sha256; cv=none;
	b=CIR40k7+JWTds8YhJvOut1ijUFBUqJO3t8jJiQmk0Netv5FS0Gh8DfRHV0yAMZ654z5BgZ
	lbtZE2+VrDzIo4oAfmiaXk07mXboeUacg5gaAZYa7eg6mH5ZiT61So/oTyqvRYdvqsmZCI
	Jomqz8VmVFZZlr7SkYfE9utmUEwRTlfrvUe8A8cPKUgql7MCmb2TLgljyorc6tmrhFeNB/
	UIam8WcpO0qVjIaXgPZvOG8d40gcfVCzswuOofGLfUjtt449hoAu4hFC3A3bo2neRTx2ST
	z1gX+uaY/RoIhRdRZ29EQCPBv2jJx7TceKBK5PdiIeuDENA1gouHD/Io4gKmUg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16574868423.cbCbC0B.24073
Date: Sun, 10 Jul 2022 21:00:42 +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.

--16574868423.cbCbC0B.24073
Date: Sun, 10 Jul 2022 21:00:42 +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.


--16574868423.cbCbC0B.24073--

From nobody Sun Jul 10 21:02:24 2022
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 57E571CF99B4
	for ; Sun, 10 Jul 2022 21:02:33 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.160])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lgzx34Zwsz41D8
	for ; Sun, 10 Jul 2022 21:02:31 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657486949;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=VrKJH3bGznJ/xpIU57OA3tYkEiTZwP5eBdsWZyIhYr0=;
    b=ibDA9Z1a/vABbMqhRBCtKQTFCP66i2dpyngaDiGbnWbiIvMOdSH1Haw3neyuKfuBv2
    0xitjTEc9ueTkkYoIVrcWFEVxMKKXkm8YxPnD3K0nOcgRPROuzxb5frT1F5DYAvnVKQO
    FJpH5WBDFz4N/pDHYJkiT+FfO6lUbM8tbbArky9uq/zYGAkxAoTFR7dVn7aM8CzMmxzw
    jIXuUR6sruWUS18D7DlLtu0YA/ydPyAMExymTB/wn4rSPawhps+21jHk604tA52P/jgK
    LcS20WS/hdzRjtn59Hhx6QbzrJgOiaJOGJSWMO2WSyfBxUEK7sHEuMmx/4O3HzFw4eTo
    5Yqw==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6AL2Td1K
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Sun, 10 Jul 2022 23:02:29 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id BDF6D63937
	for ; Sun, 10 Jul 2022 23:02:28 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Re: Partition layout of ARM SD card images
Date: Sun, 10 Jul 2022 18:02:24 -0300
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
To: freebsd-arm 
In-Reply-To: 
Message-Id: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lgzx34Zwsz41D8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=ibDA9Z1a;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.160 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_IN_DNSWL_NONE(0.00)[81.169.146.160:from];
	DMARC_NA(0.00)[cyclaero.com];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.160:from];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Well, I thought the arm64-RPi one is a general purpose layout becase the =
armv7 one is identical:

mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img
gpart show md0 md0s2

   =3D>     63  6291393  md0  MBR  (3.0G)
          63     2016       - free -  (1.0M)
        2079   102312    1  fat32lba  [active]  (50M)
      104391  6187041    2  freebsd  (3.0G)
     6291432       24       - free -  (12K)

   =3D>      0  6187041  md0s2  BSD  (3.0G)
           0       57         - free -  (29K)
          57  6186880      1  freebsd-ufs  (2.9G)
     6186937      104         - free -  (52K)

Must be something historical.

> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>=20
> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  =
wrote:
>=20
>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>=20
>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> # gpart show md0 md0s2
>>=20
>>  =3D>     63  6291393  md0  MBR  (3.0G)
>>         63     2016       - free -  (1.0M)
>>       2079   102312    1  fat32lba  [active]  (50M)
>>     104391  6187041    2  freebsd  (3.0G)
>>    6291432       24       - free -  (12K)
>>=20
>>  =3D>      0  6187041  md0s2  BSD  (3.0G)
>>          0       57         - free -  (29K)
>>         57  6186880      1  freebsd-ufs  (2.9G)
>>    6186937      104         - free -  (52K)
>>=20
>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is =
neither aligned to 1M nor to 4k, it starts on an odd base. The start of =
the BSD payload slice s2 and its size are odd as well. The padding of 57 =
blocks within s2 lets the UFS partition start on a globally even base, =
namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned =
(104448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =
=3D 51), however all this keeps looking strange.
>>=20
>> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.
>=20
> The layout details are more specific to the aarch64 RPi* context
> than to general aarch64 SD card images. For example, the Rock64
> image is different:
>=20
> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> # gpart show md0
> =3D>     40  6291376  md0  GPT  (3.0G)
>       40    32728       - free -  (16M)
>    32768   102400    1  efi  (50M)
>   135168  6156160    2  freebsd-ufs  (2.9G)
>  6291328       88       - free -  (44K)
>=20
> The 32768 is associated with:
>=20
> # more /usr/local/share/u-boot/u-boot-rock64/README=20
> U-Boot loader and related files for the Pine64 Rock64.
>=20
> To install this bootloader on an sdcard just do:
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
> dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
>=20
> where the sizes are:
>=20
> 103411 for idbloader.img
> 793560 for u-boot.itb
>=20
> In other words: assocaited with having room for
> the idbloader and U-Boot as required by the Rock64.
> [Most U-Boot's(/whatever's) are not placed inside
> a file system and the positions/sizes vary. The
> Rock64 is just an example that I happen to have
> access to.]
>=20
> [If I make my own partitioning, I tend to use the 32768 so
> U-Boot/whatever fairly generally have room to be replaced.
> But I've not checked if any u-boot/whatever ports require
> even more space up front. I tend to set up to also allow
> the RPi* to boot as well as the likes of the Rock64 (or
> whatever).]
>=20
> Looking at what the official raspios arm64 images look
> like, for example:
>=20
> =
https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_a=
rm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz
>=20
> # mdconfig -a -u 1 -t vnode -f =
2022-04-04-raspios-bullseye-arm64-lite.img=20
> # gpart show md1
> =3D>     33  3907551  md1  MBR  (1.9G)
>       33     8159       - free -  (4.0M)
>     8192   524288    1  fat32lba  (256M)
>   532480  3375104    2  linux-data  (1.6G)
>=20
> Note the 256M fat32lba instead of only 50M. This dates back
> to:
>=20
> QUOTE
> 2019-06-20:
>  * Based on Debian Buster
> . . .
>  * Boot partition size set to 256M
>  * Linux kernel 4.19.50
>  * Raspberry Pi firmware 88ca9081f5e51cdedd16d5dbc85ed12a25123201
> END QUOTE
>=20
> rpi-update has logic that can produce the following
> kind of message:
>=20
> QUOTE
> Partition size $(( $PARTSIZE >> 20 ))M may not be sufficient for new =
Pi4 files
> This could result in a system that will not boot.
> 256M FAT partition is recommended. Ensure you have a backup if =
continuing.
> END QUOTE
>=20
> It has had that since 2019-Jun-24, 882f5c1 in:
>=20
> https://github.com/raspberrypi/rpi-update/commits/master/rpi-update
>=20
> I do not know when the 8192 usage started.
>=20
> It is possible that the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> structure just dates back to matching far earlier Raspberry Pi
> images. (I did not look that far back.)
>=20
>> For the time being, I created a second SD card from the initial one =
for my RPi 4, and it's partition table is as follows:
>>=20
>> # gpart show mmcsd0 mmcsd0s2
>>  =3D>      63  62410689  mmcsd0  MBR  (30G)
>>          63        25          - free -  (13K)
>>          88    102312       1  fat32lba  [active]  (50M)
>>      102400  62308352       2  freebsd  (30G)
>>=20
>>  =3D>       0  62308352  mmcsd0s2  BSD  (30G)
>>           0  56623104         1  freebsd-ufs  (27G)
>>    56623104   5685248         2  freebsd-swap  (2.7G)
>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com


From nobody Sun Jul 10 21:09:58 2022
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 C7D0C1CFAA8A
	for ; Sun, 10 Jul 2022 21:10:07 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Lh05p3fGSz41Zm
	for ; Sun, 10 Jul 2022 21:10:06 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48])
	by colo1.denninger.net (Postfix) with ESMTP id 52F48211169
	for ; Sun, 10 Jul 2022 17:09:59 -0400 (EDT)
Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id D59294A72D4
	for ; Sun, 10 Jul 2022 17:09:58 -0400 (EDT)
Message-ID: <512e33ac-1165-61c2-62b9-717a67676873@denninger.net>
Date: Sun, 10 Jul 2022 17:09:58 -0400
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: Partition layout of ARM SD card images
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
From: Karl Denninger 
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010009010807030404090104"
X-Rspamd-Queue-Id: 4Lh05p3fGSz41Zm
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
X-Spamd-Result: default: False [-5.90 / 15.00];
	SIGNED_SMIME(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_ATTACHMENT(0.00)[];
	FREEFALL_USER(0.00)[karl];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a cryptographically signed message in MIME format.

--------------ms010009010807030404090104
Content-Type: multipart/alternative;
 boundary="------------7ajbfWPEyo0TIK0QGGZzvuwI"

--------------7ajbfWPEyo0TIK0QGGZzvuwI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/10/2022 16:05, John Kennedy wrote:
> On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:
>> ... The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
>>
>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
>    I think there are historical reasons, probably more with not "wasting"
> space on small SD cards (~512 byte blocks).  I haven't had it bite me
> recently, at least, but I imagine the FreeBSD folks are trying (perhaps
> vainly) to keep image count to a minimum.  I think I was tweaking my
> images from RPI2 and later to 4K and 1M like you are to line up with the
> storage I had them stored on and the filesystems inside the partitions.

 From my experience it is an EXTREMELY bad idea to NOT align SD card 
images; these cards are notorious for suffering from severe 
write-amplification problems and if you want to kill them don't align 
your partitions.  Never mind serious performance problems you may run 
into on writes.  This is true for both SD and uSD cards, but 
particularly the latter (e.g for Pis and similar.)

I align partitions for them in my Crochet builds on 4m boundaries (I do 
not care about wasting a few megabytes per *partition* or filesystem 
slice).  Yes, I know 4m is overkill (1m is probably more than sufficient 
for current cards) but I prefer not to screw with this in the future as 
card capacity continues to go up, and it both has and does, and I know 
of no way to get the *physical* block size that the controller on the 
card is actually using (what it presents to the interface is not 
necessarily what it uses internally.)

I have a number of devices that boot from these cards and then run from 
RAM, and if I update something in the booted area (e.g. "mount -o rw /; 
copy something-from-here-to-there; mount -o ro /") the time for that 
second command to come back if I do NOT align the partitions is often 
tens of seconds .vs. a second or two if I do.

That's a pretty solid indication that the system is waiting for the 
controller on the card to do the read/reallocate/re-write thing and its 
not real happy with what I just asked it to do. Thus I always align them.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------7ajbfWPEyo0TIK0QGGZzvuwI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 7/10/2022 16:05, John Kennedy wrote:

    

    

      
On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:


      

        
... The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.

Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.


      

      
  I think there are historical reasons, probably more with not "wasting"
space on small SD cards (~512 byte blocks).  I haven't had it bite me
recently, at least, but I imagine the FreeBSD folks are trying (perhaps
vainly) to keep image count to a minimum.  I think I was tweaking my
images from RPI2 and later to 4K and 1M like you are to line up with the
storage I had them stored on and the filesystems inside the partitions.


    

    
From my experience it is an EXTREMELY bad idea to NOT align SD
      card images; these cards are notorious for suffering from severe
      write-amplification problems and if you want to kill them don't
      align your partitions.  Never mind serious performance problems
      you may run into on writes.  This is true for both SD and uSD
      cards, but particularly the latter (e.g for Pis and similar.)

    

    
I align partitions for them in my Crochet builds on 4m boundaries
      (I do not care about wasting a few megabytes per *partition* or
      filesystem slice).  Yes, I know 4m is overkill (1m is probably
      more than sufficient for current cards) but I prefer not to screw
      with this in the future as card capacity continues to go up, and
      it both has and does, and I know of no way to get the *physical*
      block size that the controller on the card is actually using (what
      it presents to the interface is not necessarily what it uses
      internally.)

    

    
I have a number of devices that boot from these cards and then
      run from RAM, and if I update something in the booted area (e.g.
      "mount -o rw /; copy something-from-here-to-there; mount -o ro /")
      the time for that second command to come back if I do NOT align
      the partitions is often tens of seconds .vs. a second or two if I
      do.

    
That's a pretty solid indication that the system is waiting for
      the controller on the card to do the read/reallocate/re-write
      thing and its not real happy with what I just asked it to do. 
      Thus I always align them.

    

    

    

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]

  


--------------7ajbfWPEyo0TIK0QGGZzvuwI--

--------------ms010009010807030404090104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL
MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw
FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf
BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4
MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD
dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1
ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK
AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI
KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD
0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY
vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn
uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24
SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E
6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH
YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL
h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd
zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE
FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q
EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ
TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5
c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY
MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC
AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN
gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9
oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj
tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K
uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv
HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK
17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/
Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA
6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY
UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk
YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB
MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz
NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX
MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW
ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B
3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI
XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi
WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb
NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM
qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5
CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l
y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY
2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE
MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV
HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD
bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV
HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ
MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5
c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz
dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs
QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj
7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn
3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6
Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g
3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG
7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp
mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi
Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y
W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c
5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit
oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx
GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl
MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO
XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0yMjA3MTAyMTA5NThaME8GCSqGSIb3DQEJBDFCBECz0ZfXzFbytnDZSQas
pD8NwgDiAFzO+/+2lRqxP2IuoFPSecqH2n3410bqD9s77RfbLtx0TsVEcyeHTgE93NuVMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ
MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw
IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d
Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y
aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg
Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x
Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBj33eE7/Lyo7c/2VjjlDqiTIMyVSDBtyHpySTH
zrbJGJwA6B4y9seTAZj1Uagm0bdtPGPchQm5BbIt0CHwen2OVhTfUBI82g6orDOoKaB6zdYg
m9JCiONQsrxJkWxBe+q+FNJT6Y0ZuqQd1vdl2Y9UE0yNGQDtiIlR+jfPkDDpf4ReAMsMM6+D
Ytnc4we29jr0c9V1etZwxQgS9ZWzvj1O88c0Q89g3W7ix4RfcD9IvaWrZ9sviN8WU5NI7M61
3aBzkxgwT7z4k1JwPF3g4tp7glVGKCVO5DipibKVZt0jqLPlCrXLmDIkSolnVh33GV2FumTt
fcaO7zjEnIETa7xyrcHmUvQOXddGYJqrBfBJ8KmZziECyKhjuNV6DcDhskZgWVy5CXaCAUBt
7z3cOXeNNUkKdVVQTL8I1hXbu1m7jIxDl0s79ygEw6PW9mLtnPZFRun1jPZkoUM4ldvFtVHk
KQJELT2Ug1Gej5kHD6oP0HzlT4hRDXBXj40CAm207/ls3PGo4O7GYSBlNSBKWF7kKeqC2x4N
so/bptJK7bEo9JL2N8tDE3+L63mLp01GawOMcKRVullzZBTwrlGXTlW7ADuHkdnNvem9aFfD
f+v0mxbpV9IGSVr3o31rIUbRzM/gaJALvV61lR1ODrkom2Z/WOuFBRvukqZr7/YBHubFCQAA
AAAAAA==
--------------ms010009010807030404090104--

From nobody Sun Jul 10 21:20:05 2022
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 A40341CFBF75
	for ; Sun, 10 Jul 2022 21:20:09 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh0KN2sZPz42fX
	for ; Sun, 10 Jul 2022 21:20:08 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657488006;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=iroWrrViGhbKmZqeVpTEKurzBgu9UQPejp6ewaxFO4c=;
    b=FB5hgr+GIG5vZ9y4NiYgcT8BwSA5pP+5H/yB6hRgZQp1KZzPLXpuv7keW+0sR/ft+R
    VoIeXIDAawQhjz8D/wuEi7AjltsxhE33Wgw5jPXwNlVKTn0gPEA+etSMNEnhVVgGuEfn
    e/nudhtNT3tbDycnZkquWBvRpqn6/IJo2JGPXncUqMci8c3pZF0EdqrBH7AaDlV4dRMw
    rsWo5Xnhz6B3k/EsIs6c/pFxfRuXTLT+SGl07nH4Px0JQsYwws5brl8xdQUUJYUA0Fva
    6tQb2f/tAKz1OPBHfEcCPPfej+HlpziHKsrxmpzH8JDt7HpmW/AvSjY47le3exylZj7E
    +PCA==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6ALK6d23
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Sun, 10 Jul 2022 23:20:06 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id C91DB63937
	for ; Sun, 10 Jul 2022 23:20:05 +0200 (CEST)
From: "Dr. Rolf Jansen" 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D"
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.15\))
Subject: Re: Partition layout of ARM SD card images
Date: Sun, 10 Jul 2022 18:20:05 -0300
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
 <512e33ac-1165-61c2-62b9-717a67676873@denninger.net>
To: freebsd-arm 
In-Reply-To: <512e33ac-1165-61c2-62b9-717a67676873@denninger.net>
Message-Id: <45F48B1C-05D3-4786-B40E-57F281FDE558@cyclaero.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lh0KN2sZPz42fX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=FB5hgr+G;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[cyclaero.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> Am 10.07.2022 um 18:09 schrieb Karl Denninger :
>=20
> On 7/10/2022 16:05, John Kennedy wrote:
>> On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. Rolf Jansen wrote:
>>=20
>>> ... The start of the fat32 boot slice s1 (containing the u-boot) =
stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The =
start of the BSD payload slice s2 and its size are odd as well. The =
padding of 57 blocks within s2 lets the UFS partition start on a =
globally even base, namely 104391+57 =3D 104448, which as a matter of =
fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>>>=20
>>> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.
>>>=20
>>  I think there are historical reasons, probably more with not =
"wasting"
>> space on small SD cards (~512 byte blocks).  I haven't had it bite me
>> recently, at least, but I imagine the FreeBSD folks are trying =
(perhaps
>> vainly) to keep image count to a minimum.  I think I was tweaking my
>> images from RPI2 and later to 4K and 1M like you are to line up with =
the
>> storage I had them stored on and the filesystems inside the =
partitions.
>>=20
> =46rom my experience it is an EXTREMELY bad idea to NOT align SD card =
images; these cards are notorious for suffering from severe =
write-amplification problems and if you want to kill them don't align =
your partitions.  Never mind serious performance problems you may run =
into on writes.  This is true for both SD and uSD cards, but =
particularly the latter (e.g for Pis and similar.

This is common knowledge for more than a decade, and therefore I skipped =
the explanation on why this is important.

The question in the first place is why the official images, which the =
installation instructions tell us to copy via dd to the SD card are not =
aligned by 100%. However, perhaps I am missing some points regarding the =
internals of SD cards, of the MBR, of the Fat32 scheme. Perhaps the =
actual useful data here starts at an uneven block - I don't know =
therefore the question why, despite of the common knowledge, the =
partition table look strange.=

--Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Am 10.07.2022 um 18:09 schrieb Karl =
Denninger <karl@denninger.net>:

On =
7/10/2022 16:05, John Kennedy wrote:
On Sun, Jul 10, 2022 at 04:26:02PM -0300, Dr. =
Rolf Jansen wrote:

... The start of the fat32 boot slice s1 (containing the =
u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd =
base. The start of the BSD payload slice s2 and its size are odd as =
well. The padding of 57 blocks within s2 lets the UFS partition start on =
a globally even base, namely 104391+57 =3D 104448, which as a matter of =
fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking =
strange.

Are there reasons for this =
partition layout besides making it look more interesting? If yes, some =
insights would be good.

 I =
think there are historical reasons, probably more with not "wasting"
space on small SD cards (~512 byte blocks).  I haven't =
had it bite me
recently, at least, but I imagine the =
FreeBSD folks are trying (perhaps
vainly) to keep image =
count to a minimum.  I think I was tweaking my
images =
from RPI2 and later to 4K and 1M like you are to line up with the
storage I had them stored on and the filesystems inside the =
partitions.

=46rom my =
experience it is an EXTREMELY bad idea to NOT align SD card images; =
these cards are notorious for suffering from severe write-amplification =
problems and if you want to kill them don't align your partitions. =
 Never mind serious performance problems you may run into on =
writes.  This is true for both SD and uSD cards, but particularly =
the latter (e.g for Pis and similar.

This is common knowledge for more =
than a decade, and therefore I skipped the explanation on why this is =
important.

The question in the first place is why the official images, =
which the installation instructions tell us to copy via dd to the SD =
card are not aligned by 100%. However, perhaps I am missing some points =
regarding the internals of SD cards, of the MBR, of the Fat32 scheme. =
Perhaps the actual useful data here starts at an uneven block - I don't =
know therefore the question why, despite of the common knowledge, the =
partition table look strange.=

--Apple-Mail=_50CFE346-C2DF-485B-8723-DA15CDB2408D--

From nobody Sun Jul 10 21:34:45 2022
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 63F4C1CFE537
	for ; Sun, 10 Jul 2022 21:34:52 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh0fL71Jsz44Y7
	for ; Sun, 10 Jul 2022 21:34:50 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657488889;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=8u5opbHUh8/PQhNls3npLA/7U43Xg0eXgtl9YzmG0CY=;
    b=VFj2OaErbOMuOD/sX5tqlabI0eXcrmjoFPGF/z0K32c9kLh50bpTrzwLHdA9w/WURi
    BpkWGskU99/qgq1yUbMcaN/pReUCTQBZBNROP0G1mdYq5Ke8+eyLlb/ItlK7E9qVhftN
    PDiwVTInHeUI/zZIXJojFs4TPkYSpDQedijmWaiPheFLuqGb1OOdsvDj6UAEYshgTPLI
    KMprYOfiJn8Is+gOM0deX9FTNtK1DWLeHruU0dk7iEK/gsleDGLn6D3bLjfC4Nt0iQNK
    qe0CFEdlcMviUBujvXKqKPICHzkQ6tbBXVhRo9gyCP3ndRtqF6Y1O2H54YdljMfBmOXM
    NhpQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6ALYnd2O
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Sun, 10 Jul 2022 23:34:49 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id CE3B36393C
	for ; Sun, 10 Jul 2022 23:34:48 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Re: Partition layout of ARM SD card images
Date: Sun, 10 Jul 2022 18:34:45 -0300
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
To: freebsd-arm 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lh0fL71Jsz44Y7
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=VFj2OaEr;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.20 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[85.215.255.20:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[cyclaero.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>=20
> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  =
wrote:
>=20
>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>=20
>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> # gpart show md0 md0s2
>>=20
>>  =3D>     63  6291393  md0  MBR  (3.0G)
>>         63     2016       - free -  (1.0M)
>>       2079   102312    1  fat32lba  [active]  (50M)
>>     104391  6187041    2  freebsd  (3.0G)
>>    6291432       24       - free -  (12K)
>>=20
>>  =3D>      0  6187041  md0s2  BSD  (3.0G)
>>          0       57         - free -  (29K)
>>         57  6186880      1  freebsd-ufs  (2.9G)
>>    6186937      104         - free -  (52K)
>>=20
>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is =
neither aligned to 1M nor to 4k, it starts on an odd base. The start of =
the BSD payload slice s2 and its size are odd as well. The padding of 57 =
blocks within s2 lets the UFS partition start on a globally even base, =
namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned =
(104448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =
=3D 51), however all this keeps looking strange.
>>=20
>> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.
>=20
> The layout details are more specific to the aarch64 RPi* context
> than to general aarch64 SD card images. For example, the Rock64
> image is different:
>=20
> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> # gpart show md0
> =3D>     40  6291376  md0  GPT  (3.0G)
>       40    32728       - free -  (16M)
>    32768   102400    1  efi  (50M)
>   135168  6156160    2  freebsd-ufs  (2.9G)
>  6291328       88       - free -  (44K)

This is a GPT table, while the others are still MBR. Images which come =
with u-boot must have a different layout.=

From nobody Sun Jul 10 21:44:44 2022
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 244011CFFBE4
	for ; Sun, 10 Jul 2022 21:44:49 +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 4Lh0sr036Zz45XR
	for ; Sun, 10 Jul 2022 21:44:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657489486; bh=bi8tObtt6dkTKGeFyO+Q9DTpvWwCfhrVh3ZKf4X/1NQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gqHEFdH46tKNEQafzbfBCW3h0lxhNj3ATLb2VnTMaO42fyaJwD/RA/HhKYvpNAO1J7RhVRfp9DBMcJ4wgZLRS3eAhygjnKo7YSUeCsbmv5TIBjR0bXFS+oSAJyTErGp5nlYxLHcEpLp+XQuyg49TbC2dcqjnLE3EAgYWRTLkbSv1iIE/e2kLlvXaWPjWCVPAJOcT32V80IsmZTGqsbs2pUpSn60ucmS8TtmS3u1z4+K2JgitfI64oSpDtlEzWAcbAxlFPiPlVWlrmhzaDBJu0tpxr3m7DOZzAoK1eal6AWcxzoyUkrRrXgQck2gUSNQDaqhj73XfYYD9MnGOhgap6w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657489486; bh=w27ck5nmY41gxuDyGO8NOyzjXryMfxAUd0/QixfTa7V=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nPl6MViet/iytVpP9q4BCK6ENH2FtHowNrf4jqg+ecgXv+ENfieyULJidaCNXTe5c24zMGyXfTzZHsrCGqlu4X0wdCCgUwXqGYAn9+Yv0N3F/rCHZTcZJvhEoEDmJVmdWDaTaL4sWiFCXhcR3qn/0VmG3TYS5J42DYHHXa8VhlKq75vhAKE7BLHr03sPdOuC3GoPBUgkoXt+bmXIrc4bd0Atg1GRfxqUEomI4pZhwKAVjVt1cpUrDIY0GQbuy96EifQGGdbpLfmbmp3qlyDMk6672eCxSJw/DtrMdePy+IZKexkR3nOonzgH7QHs8BLAxwFOaKEv5yVBnvorFVEH4w==
X-YMail-OSG: Zwor45YVM1mGTGfdWOBB0PnowQ33Mvxzg4P3aICzj909TbpLPB3QD1pWCWLaZLa
 rR1v_jveyOMMrbVUINq2EqskgEicbfoaOGV5YUeh57zE9_bVU5nWqb_khsxzXEXs7AmPvYVDeUmc
 RBDRWEvvr0Gucph_UNGtFUKxdBdqZdsDusHwUlFhgVvQNwy6mIg69F1gMcOZwIRi6LrhoD8mvntD
 gPcG8bM72SRxvhJd82ZP5B0gCaMT2WKZquYIEKlND23LOR4DA1bRkH_lCTbUQ5mDRKla8j_JZj3A
 pw.dR.nBWJ_Vzawsg0Lek_sZPBXwlKdRDA6eVvjbif2151lRv47lFROKQMM.osThUBoN2_x4hEGe
 fE23pXGz977OAFyR8wDVsPhawMGkR0uQ6GFdFWmzAesWUdG1T06Y3WX0oU3H13jLyyacsxdXezTA
 bwVf0tE.sph1GYf45UVzQqrPewK9HUGxEJalLHfMF70.8NRENO3sMNLKTk.qZZOxhd5Lo.Vt4.VT
 QAouMGbFp3OtdyquyBJF7GPwr5GNmYsA398oYWLVGBJenHcKQtEEifouFA7KWbMlpU_cxGm2OWVV
 dynpV3qRSuqPTVkyBFPUFCsAmoLz4BsftwrOp0Ffhgy08ItR.iurnW38n3tyfqs4ins5pfBdZ0lJ
 XrIDlDY6Dj2Y7rt_kawlK.PDqOxjsZ_5s8DJr8f1SJqkB_EZeMDOwwKydRTkwS5CkvkPOqASUWBb
 h8amdZXtPNf90JQvcRgeq.MM1POKmGNHBQH7W8dKApEP9UjE2FzA9uVZiSvsAA_Hh4oIwwffDCJw
 FBhqFlKvwiCboUlki3IncRl4lwfFw5T8q5yDhZiIE4LZXWhuKBiR_t8n_Um_WN_jseU4AE7qaZL3
 miQ.5H4h6DkU78cC989mI8EC5ShxpxsEvGCur0S33Bcu5MEXSBDDsZ7vr_NC3_d2LtlB0mi.lghh
 HYVpJDr4dMC9JzQGZriuzBurbt96jTlTgThUjAGWRvza9t3ltkpE6fBEHPAIie.sAuN16XbgyCye
 AzSPAr0FH6Hg11oPGulwpfw8j2lqeUa0G5h_IixLV47GwDbjIldiw0FZgsKysI6iREAeKX9.tNv4
 Vk0bhbtJX72g2Jg9X0RGEJA2lHzoLYk4g6_EL.KOCiij9lj8Z_48Tprbxa7o7Dtt4cKdFB5BZeSm
 ouffsLqAWh8vNwiH3Oq0W5IfwhUcqxQr2uz3WuMCRwanU.y793MsHXNe35v6DRdCvA_igZWDU.p.
 QJ_hDqvzHFqCuMbWDmWcUhHACPK_yEcnc2JPFqxhem2Kgk_TQasO.9w7AeAyd4q7NYkB47mXSxqn
 VIB2IG6LtabaTFM9.yEkpmL.05UlKYAuM.w..m04TIoXGv6WtduKsFrGmZUgfhfLh0qt4Ox_VnPh
 5Din5hIqLUHyrCoLY3B4RXAStMcxhWQiv8UHqG5Uvz5ED8ysCqnke6eRrZeJBiPJhIWWB15nVSCN
 Nsh7xnN3HyYVg73E9P5ndT0Z_NmWKXIkfG1mSAKehi.hYN2UcsF98NlVuHscocNMMOpn4CYXtEK.
 SWPuVFt3aAR1cKGl9wTBNjnXvTrN2yz76TmWNWjbF.aRlEgr8Z2Vmej98WcK7U0iCk9YyovfeyrX
 6fgT8eVTlgR64LRIs27hpiEiTU1DIh2bxMhJ4_tnw5adD4tXpSbXDAZZjjloXgEAPAwo0uH.yo43
 JQFl12RqeylZUo7FNSl229Qmw5r0CPH8mnDF0NmcS.Csk2ACrKdxVQNiC6sKMuwkZVNYr0XKykxk
 HomwH9FVT2JL9MgP0Zm7KxUr4KFbNVyAuRVdaPzFB5Zt2ZF1nwr6hRDEBiQ7XOodLc61zxLHA3Vi
 cLX3PnlpA2e1UKNK.7J7H.QeWcYslYXdfX8zy9mzSJOly0JI8sFs8EyBltu7XIrU2Ca.VoX537Qt
 s1Yp63JcSNH.OeoGIWEizQ3Tx.BxVxdJS.N6nlwINUGmQu59xtkpK_BkYUEWTVpCYB.nz6UDOUOU
 Il3OLLAROksxm6NXoX_OOf9dTxHjVtA8cJl4Pr54J.wqbfVaFgyQVp0kO.dnb1ZzMlbRGgHa3rRj
 pkbjGSeUxsZMWqSRtJEPfIP98S9WOjtxBc.wRBG8CfYRq7bxf.PRYe9d8ZmxxvHoiMAArQGnx51X
 ozf_3VmNPrXcTkBeDDYeN1s0KGynLSLkF2G9y3cf_UMqvX8tCmAqAG4JRN6D5ylA3fg3sZUGghOt
 8sS4BzdcC5Nm5ikOx33Ag1pKNfOG52Y.QuL1BpLRkjgRRO1aYPkKQqBu6lRPuAHtF_zvbBOKZlrE
 cCeQI
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 21:44:46 +0000
Received: by hermes--production-gq1-56bb98dbc7-r7f9c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cfe02e1ac54bec5d55cd18ee1e1ad1a6;
          Sun, 10 Jul 2022 21:44:45 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
Date: Sun, 10 Jul 2022 14:44:44 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com>
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
 <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lh0sr036Zz45XR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=gqHEFdH4;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.21 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.97)[-0.973];
	NEURAL_HAM_SHORT(-0.74)[-0.742];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-10, at 14:02, Dr. Rolf Jansen  =
wrote:

> Well, I thought the arm64-RPi one is a general purpose layout becase =
the armv7 one is identical:

So far as I'm aware, the RPi*'s are unique in having all the
content in a file system instead of having some content outside
any file system. This tends to make them generally unusual in
various respects as far a Small Board Computers go.

It is also why I can normally add a RPi* dual-boot configuration
adjustment to a configuration for another Small Board Computer
(such as the Rock64): no conflict is generated by the 2 U-Boots
or other such.

> mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img
> gpart show md0 md0s2
>=20
>   =3D>     63  6291393  md0  MBR  (3.0G)
>          63     2016       - free -  (1.0M)
>        2079   102312    1  fat32lba  [active]  (50M)
>      104391  6187041    2  freebsd  (3.0G)
>     6291432       24       - free -  (12K)
>=20
>   =3D>      0  6187041  md0s2  BSD  (3.0G)
>           0       57         - free -  (29K)
>          57  6186880      1  freebsd-ufs  (2.9G)
>     6186937      104         - free -  (52K)
>=20
> Must be something historical.

Just for reference for 32-bit (hard float) raspios:

=
https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a=
rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz

# mdconfig -a -u 2 -t vnode -f =
2022-04-04-raspios-bullseye-armhf-lite.img=20
# gpart show md2
=3D>     63  3940289  md2  MBR  (1.9G)
       63     8129       - free -  (4.0M)
     8192   524288    1  fat32lba  (256M)
   532480  3407872    2  linux-data  (1.6G)

So the same use of 8192 and 256M these days for 32-bit
raspios.

The 256M may in part be from what some linux updaters do:
rename the original files with added .bak suffixes and
put down the new files with the original file names.
So: 2 instances of the files that do not have brand-new
names (some .bak/no-.bak pairs possibly being of 2
distinct vintages).


I'll note that a lot of the more modern RPi*'s can boot
directly from media that uses GPT instead of MBR. Some
older ones can do that only via a microsd card that has
a sufficiently modern bootcode.bin that loads first and
provides the updated context. There may be some that
just can not boot via GPT partitioned media at all.
(Unsure.) To avoid microsd card and bootcode.bin
requirements ending up involved sometimes, FreeBSD will
likely stick with MBR.

[I use GPT where I can if I'm setting up media for myself.]

>> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>>=20
>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  =
wrote:
>>=20
>>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>>=20
>>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>> # gpart show md0 md0s2
>>>=20
>>> =3D>     63  6291393  md0  MBR  (3.0G)
>>>        63     2016       - free -  (1.0M)
>>>      2079   102312    1  fat32lba  [active]  (50M)
>>>    104391  6187041    2  freebsd  (3.0G)
>>>   6291432       24       - free -  (12K)
>>>=20
>>> =3D>      0  6187041  md0s2  BSD  (3.0G)
>>>         0       57         - free -  (29K)
>>>        57  6186880      1  freebsd-ufs  (2.9G)
>>>   6186937      104         - free -  (52K)
>>>=20
>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff =
is neither aligned to 1M nor to 4k, it starts on an odd base. The start =
of the BSD payload slice s2 and its size are odd as well. The padding of =
57 blocks within s2 lets the UFS partition start on a globally even =
base, namely 104391+57 =3D 104448, which as a matter of fact is 4k =
aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>>>=20
>>> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.
>>=20
>> The layout details are more specific to the aarch64 RPi* context
>> than to general aarch64 SD card images. For example, the Rock64
>> image is different:
>>=20
>> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>> # gpart show md0
>> =3D>     40  6291376  md0  GPT  (3.0G)
>>      40    32728       - free -  (16M)
>>   32768   102400    1  efi  (50M)
>>  135168  6156160    2  freebsd-ufs  (2.9G)
>> 6291328       88       - free -  (44K)
>>=20
>> The 32768 is associated with:
>>=20
>> # more /usr/local/share/u-boot/u-boot-rock64/README=20
>> U-Boot loader and related files for the Pine64 Rock64.
>>=20
>> To install this bootloader on an sdcard just do:
>> dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
>> dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync
>>=20
>> where the sizes are:

The sizes below were extracted from "ls -Tld" output,
so "byte count" for units for each.

>> 103411 for idbloader.img
>> 793560 for u-boot.itb
>>=20
>> In other words: assocaited with having room for
>> the idbloader and U-Boot as required by the Rock64.
>> [Most U-Boot's(/whatever's) are not placed inside
>> a file system and the positions/sizes vary. The
>> Rock64 is just an example that I happen to have
>> access to.]
>>=20
>> [If I make my own partitioning, I tend to use the 32768 so
>> U-Boot/whatever fairly generally have room to be replaced.
>> But I've not checked if any u-boot/whatever ports require
>> even more space up front. I tend to set up to also allow
>> the RPi* to boot as well as the likes of the Rock64 (or
>> whatever).]
>>=20
>> Looking at what the official raspios arm64 images look
>> like, for example:
>>=20
>> =
https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_a=
rm64-2022-04-07/2022-04-04-raspios-bullseye-arm64-lite.img.xz
>>=20
>> # mdconfig -a -u 1 -t vnode -f =
2022-04-04-raspios-bullseye-arm64-lite.img=20
>> # gpart show md1
>> =3D>     33  3907551  md1  MBR  (1.9G)
>>      33     8159       - free -  (4.0M)
>>    8192   524288    1  fat32lba  (256M)
>>  532480  3375104    2  linux-data  (1.6G)
>>=20
>> Note the 256M fat32lba instead of only 50M. This dates back
>> to:
>>=20
>> QUOTE
>> 2019-06-20:
>> * Based on Debian Buster
>> . . .
>> * Boot partition size set to 256M
>> * Linux kernel 4.19.50
>> * Raspberry Pi firmware 88ca9081f5e51cdedd16d5dbc85ed12a25123201
>> END QUOTE
>>=20
>> rpi-update has logic that can produce the following
>> kind of message:
>>=20
>> QUOTE
>> Partition size $(( $PARTSIZE >> 20 ))M may not be sufficient for new =
Pi4 files
>> This could result in a system that will not boot.
>> 256M FAT partition is recommended. Ensure you have a backup if =
continuing.
>> END QUOTE
>>=20
>> It has had that since 2019-Jun-24, 882f5c1 in:
>>=20
>> https://github.com/raspberrypi/rpi-update/commits/master/rpi-update
>>=20
>> I do not know when the 8192 usage started.
>>=20
>> It is possible that the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> structure just dates back to matching far earlier Raspberry Pi
>> images. (I did not look that far back.)
>>=20
>>> For the time being, I created a second SD card from the initial one =
for my RPi 4, and it's partition table is as follows:
>>>=20
>>> # gpart show mmcsd0 mmcsd0s2
>>> =3D>      63  62410689  mmcsd0  MBR  (30G)
>>>         63        25          - free -  (13K)
>>>         88    102312       1  fat32lba  [active]  (50M)
>>>     102400  62308352       2  freebsd  (30G)
>>>=20
>>> =3D>       0  62308352  mmcsd0s2  BSD  (30G)
>>>          0  56623104         1  freebsd-ufs  (27G)
>>>   56623104   5685248         2  freebsd-swap  (2.7G)
>>=20
>>=20
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 10 21:55:28 2022
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 992691D03855
	for ; Sun, 10 Jul 2022 22:06:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lh1M02LDXz49DB
	for ; Sun, 10 Jul 2022 22:06:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657490794; bh=BO/r2rdI3HFdixCua9TaTWAgOYneoBXdJNSvnzvC1ug=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OFsYsPOp+MtuHWScd1FWWtGzTJtwp949Ku1vTMth6Mgw7A6kXPKbr/T24RSk/rwajKGlUcxEhDYc/BuSQ/hKqG3DqrPP8lt8rUvbN6gFZFT0ehtUI/CCRLKeM182n0b6dMk1bmlLAU0GJ8PRzgjNFNChOc/3+3b72+9IVR4opkqb0gzC0tXm4ke9F+Mwf/UoPTdd+dlEMvoyTfb0gTKhF04AhexJoZkYZErCPQO39nv0muNaKbk8ZS51FJEK1OmL24keN40DCDpZ3ak4+UikHHnyVbCkuKZ1BZ/NASrlwoN9b3eBYKCm74WBrBsnpnMrd6dKDaBA2G45G7T7VGR0GQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657490794; bh=cOQopzCnJJ7YzSENBa/wuEm3xJjOj+FtLRD+oseT9L+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iNt2ZJffYhU9wMISv0WBc8EUvmNhQvhpm60ByQj4Aga1GQYvIifcvqxIXvuUnEwJP7L3qFEQjV/2bD1N6cANWIj8h5iBMZXLAYDXOQS8cO5GujQlaAiiVd6XLqoDQqGYpmrqzS4yzzO20ytpq0tsqtBCOsZY5dvE+FJ/QabQG5rGrpSPc9nwVa8ZuSZqHBAvGYjMxt1VZn++NaFLQXlBy8DEgoGqH2njFzQjhqp+AYogrt7oOSz/UJWtFDgVZSC7nD+Ck8b1YEXZ2z6sVc/bwy6gz1LTkZwOhsa4Sx61PxV5rRmODQ68I9Nq0lkjrlrvpTigNEEM3eZ/zGH6aDFkcg==
X-YMail-OSG: 7g8g8xsVM1kKyZcKgFFeSWc2zC6_iXa_.4XtsvgF3kyAp.4rCTTk.83Pzisy5Vt
 nYPnE27GGMe_6PK2Y7XczlrdCc9vnYYGxShuhjZaITfykxuLSGHggsKtFyYelY6RN_eqyKNRjX2d
 0vHbO2In0mfMxKUK6XS93Ida0YAL7jnQIe9olMMxNOTjn7EH154QXokf7eMCWDK9tkmTG18k1p2r
 yGDj3WtEHHLpcSnsT0ABtEb3BYXPsRe2vNIw37GuzarTwBhDdOB29.cU7A7azqMEh9fmkR.qXoXl
 IrgbnbYQAIJFkxYP21RIXzLxb1WiBdTjZwASgnUw3sNQXzsdB9KlMZJ0scK3WsZvW.6HAcR3zCQM
 ApK8g7ggKK0cDdQURJystcWyKDC3VY5XeVKnezhgA9tjl.pbCI4IvK3AJouVQ4oEEY5xYD9stcOw
 fNkAJu5MYBkZye0KrGk7MEMmQlHOkvFAWHOIKIYjJ5Q2I5FHrESf9NnI0CQMHS65dmOgBMBAhKY7
 1p3bjKWHuzAr1P0B4HCburyCrMvWXVAVz6JFD4YnvROql6a8weJJJdKTImNI4MIDNcwQupYMKBT2
 Tz.fmEGilwpPZhEZZ3ylT5qDL9oHjj28_qhyQBJj03QMXDOza5qZcl1MVpsrVIWfMI09SlG0IGAl
 p0rafbMxhzc0RvWIQC.48O.yFP55hXgZ7OAkLws0ppIp7BSpCkMixw3xLtfIHm_Swfvgy_NvyAPh
 HNc4OLHaUxve5YRzNlTf7APrBBJNuS_j3GM.SyB4JmFPgpNkwx_Hw6G8imUsm7_U34U2LnAWCspu
 Txc4a13hO8fkcXQGiuY.0QT9w3bkMNQJProf0Y5EdKMuHyHuOIAwNzedwnMtsz.xYIfDjza.wNVr
 JluyJ808hdt9pmGfmLtg75.DS7_rmW1n8do0atnn7gr5kpJQkKzUH7T4LwDkYZEEmppp_7ayGlxL
 ESmdApe51w7MW0XONjkKLs1l_MVcarinw6q7iF4r0Z4ldZh2OWkxZZ40ELciz4tK6HiQ_w9gvxu5
 o8AG4auhSgH.OwSv4c.Is6UWiOP3BGTsg3cd2jDv18oYVc0G_27bWaUyIkuqt_p1CWnYuk_nyNit
 H8Vil7CbvhTPC2z0FWckkKWdLVlCCDUptMQvCpsdOA6pIz1gT.92V_dHTUsFvfPPBPnUVWLhNHTO
 sdicI0RBvgXeF4OX_GdIAGyxsrlU86JL_fAQElQPBtGFscLhr4D2atNeJZyvowSJS5oo2i05BRmq
 WIx8t7TaIclzCv8kcLo1UnFQezcol7T3R4Y6zfLtDbycS1N.CSdcxOgoEy.RQKk8MmWE_BBGtgeH
 18PiAjMpdTCLMIRO7UMrN.osEB5JJXX1uUBGKscj7DSeGTc4gNmfOQ1YoKbKxt1j1GAgyqQeZyKL
 _Ls7Eb.Zv1G6H.fywft7Daull6q1yrkBMwYyur4NDePj8qa9Qa2HBDGukyUr49huL2zin2HDMqg6
 IM3E.Xr4Dmrt.O.j2HDkesuSTwd_ElcSPaxVJN5fCSOE2Nlalgj9yCfA_v6kt_2Sljk1GZUAx3Zi
 qTByGDhLqahmoHq7KV3.zDmUFIIOzGzdIsZnfzj5FcR2.o9tc755UeBxynykQskbxKKhV5SShWR4
 HOCwqUoi4v6_mt40HKx0nmmreLg8WPW2MYGsn5vqfW6bxylNo5.BUSvPBiOcuT7t11I2JE64B2MD
 xtxUxozIQibOPUZpSMYrzRRZJyUOjkljRne.8Pn33GaIojRPfesXRo4V0cpUtw8Tl.vrNfhsDkWu
 Gv5c6VKK95oEyXOb3V5S36xLLa8OEwk_KjacPwveyAFtMtyrUa420yIAG37iveIlJisfqd.fvdK.
 IQoeEHN30n8ZCsKyLjegr84.EhvzKl.jQUQKXaKNHATZD1SqNwrmV0T72_SRxPhoKb0JXHyRQveH
 LkTO1iUNF85JLtRDbX2nVWAyXz3rjEHlotaworLZ6yHucDVkUxAzZnenZ2iVHnJs9KcI8Z1RWSir
 utg_C3eUpETdjF0mbGy9ZSiqg21fToVtlnjhmdnJ.1Aqnwukr8Q4jq4EmWnOrC0.tHM.FVI7SB4v
 xFcLgiLpSqx0_hG.zG0sgLeHzqxmG8ePXt.jpduZt1EysODi_JIXKOSAPyWoMYqYdkJTYWW7MfMw
 eNVyIb2iRtPjU0VC5naLPx.No5Jx8LR0xqewez6Nsg.cO2d1Xpd4p1Aw8Oh57.rOMgBNhA9UnGLm
 .4K.b1VdfUb4DZKRW7Eb92xplRSEl0tm339P6N2JBmx4dy50bmzfjg34.MjmWR4nBu4nQnbQLQwR
 5kQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 22:06:34 +0000
Received: by hermes--production-bf1-58957fb66f-dd4hs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 269811fb2977960aa25a6af455c657b0;
          Sun, 10 Jul 2022 21:55:30 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: 
Date: Sun, 10 Jul 2022 14:55:28 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com>
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lh1M02LDXz49DB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OFsYsPOp;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.12 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.63)[-0.626];
	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];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Jul-10, at 14:34, Dr. Rolf Jansen  =
wrote:

>> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>>=20
>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  =
wrote:
>>=20
>>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>>=20
>>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>> # gpart show md0 md0s2
>>>=20
>>> =3D>     63  6291393  md0  MBR  (3.0G)
>>>        63     2016       - free -  (1.0M)
>>>      2079   102312    1  fat32lba  [active]  (50M)
>>>    104391  6187041    2  freebsd  (3.0G)
>>>   6291432       24       - free -  (12K)
>>>=20
>>> =3D>      0  6187041  md0s2  BSD  (3.0G)
>>>         0       57         - free -  (29K)
>>>        57  6186880      1  freebsd-ufs  (2.9G)
>>>   6186937      104         - free -  (52K)
>>>=20
>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff =
is neither aligned to 1M nor to 4k, it starts on an odd base. The start =
of the BSD payload slice s2 and its size are odd as well. The padding of =
57 blocks within s2 lets the UFS partition start on a globally even =
base, namely 104391+57 =3D 104448, which as a matter of fact is 4k =
aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>>>=20
>>> Are there reasons for this partition layout besides making it look =
more interesting? If yes, some insights would be good.
>>=20
>> The layout details are more specific to the aarch64 RPi* context
>> than to general aarch64 SD card images. For example, the Rock64
>> image is different:
>>=20
>> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>> # gpart show md0
>> =3D>     40  6291376  md0  GPT  (3.0G)
>>      40    32728       - free -  (16M)
>>   32768   102400    1  efi  (50M)
>>  135168  6156160    2  freebsd-ufs  (2.9G)
>> 6291328       88       - free -  (44K)
>=20
> This is a GPT table, while the others are still MBR. Images which come =
with u-boot must have a different layout.

I know it is a GPT table. That is part of the point about
the variety of contexts that there are across the Small
Board Computers.

No SBC that has a U-Boot/whatever needing more space
than is provided below is going to use the same
2079 figure:

=3D>     63  ???  md0  ???  (?)
       63     2016       - free -  (1.0M)
     2079   ??????    1  fat32lba  [active]  (?)

MBR vs. GPT is not the fundamental issue for that.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 10 22:25:25 2022
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 316481D064CD
	for ; Sun, 10 Jul 2022 22:25:36 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.217])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh1mt4S97z3CwW
	for ; Sun, 10 Jul 2022 22:25:34 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657491929;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=E0RxV2jjWaRP1t8LxBQuvyWrMr32PoWxyuuiBFDPyVo=;
    b=YV/hDEM3AJf4gXLchwKO+Vam+PHBPrtbs0Rzsopw/oogeLFcGKaeI4S5GR/Hoh1cew
    8X7Xxc1MClO4P6dB8pguVzhlpNoL7jgcHC1MHzsK/Mxt4o3fJAnnc4MNyL9o2wmC4P2Z
    9zuW7LgkQMQg/lAxxzSEy/aJBJGdsxR73mhOxXGwJXo5JxkfW1LRMTSasOIIfLvXcu7y
    5vzUwd+eUuRsDlZbJ2h5E8Y94ndvZIQBXHtffuBmqiWJ9nkhOOEecjWUIhet7MB45Ckx
    8rE7tLYQiAQ8buYbUjDgw95YOcDz/aAiRawA7epSqgn4yQyXnZ8DCRSBpvWliFs/PUp0
    iLcg==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6AMPTd7F
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Mon, 11 Jul 2022 00:25:29 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id B484463935;
	Mon, 11 Jul 2022 00:25:28 +0200 (CEST)
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 12.4 \(3445.104.15\))
Subject: Re: Partition layout of ARM SD card images
From: "Dr. Rolf Jansen" 
In-Reply-To: <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com>
Date: Sun, 10 Jul 2022 19:25:25 -0300
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
 <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
 <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com>
To: Mark Millard 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lh1mt4S97z3CwW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b="YV/hDEM3";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.217 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[81.169.146.217:from];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[cyclaero.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 10.07.2022 um 18:44 schrieb Mark Millard :
>=20
> On 2022-Jul-10, at 14:02, Dr. Rolf Jansen  =
wrote:
>=20
>> Well, I thought the arm64-RPi one is a general purpose layout becase =
the armv7 one is identical:
>=20
> So far as I'm aware, the RPi*'s are unique in having all the
> content in a file system instead of having some content outside
> any file system. This tends to make them generally unusual in
> various respects as far a Small Board Computers go.
>=20
> It is also why I can normally add a RPi* dual-boot configuration
> adjustment to a configuration for another Small Board Computer
> (such as the Rock64): no conflict is generated by the 2 U-Boots
> or other such.
>=20
>> mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img
>> gpart show md0 md0s2
>>=20
>>  =3D>     63  6291393  md0  MBR  (3.0G)
>>         63     2016       - free -  (1.0M)
>>       2079   102312    1  fat32lba  [active]  (50M)
>>     104391  6187041    2  freebsd  (3.0G)
>>    6291432       24       - free -  (12K)
>>=20
>>  =3D>      0  6187041  md0s2  BSD  (3.0G)
>>          0       57         - free -  (29K)
>>         57  6186880      1  freebsd-ufs  (2.9G)
>>    6186937      104         - free -  (52K)
>>=20
>> Must be something historical.
>=20
> Just for reference for 32-bit (hard float) raspios:
>=20
> =
https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a=
rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz
>=20
> # mdconfig -a -u 2 -t vnode -f =
2022-04-04-raspios-bullseye-armhf-lite.img=20
> # gpart show md2
> =3D>     63  3940289  md2  MBR  (1.9G)
>       63     8129       - free -  (4.0M)
>     8192   524288    1  fat32lba  (256M)
>   532480  3407872    2  linux-data  (1.6G)
>=20
> So the same use of 8192 and 256M these days for 32-bit
> raspios.

2079 and 8192 are starting blocks of the fat32 partition, and 2079 vs. =
8192 is the difference between non-aligned and aligned. My concern is =
not the size but whether the partitions are aligned.

BTW, I use FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img for the =
BeagleBone Black's and for these I also changed the partitions so the =
fat32 becomes 4k aligned.


From nobody Sun Jul 10 23:27:34 2022
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 493851D0F2ED
	for ; Sun, 10 Jul 2022 23:27:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lh38V4p89z3Kyk
	for ; Sun, 10 Jul 2022 23:27:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657495656; bh=FVYk/Y3Ttj0nNqnwCbAzk55gxbgML/JI2akXVVLj818=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JUyXe62mKTdLB48odMGdqqVzs8wzvNqTjMP5+OcoJyMsHB9AVQ/O33oloofQjxOG5iOMg4iG8Fv5RF4tVa5si0GyinnuQrk8kB4Y7XQN1+vOj9pZL7khW86+VLfivPninFzpoIPGEtUzZUoQwdM4LH3dLS5iZUI9b/I0TG6aHp1RLWD0aHee3jVDJffODp1eFL1bgVFnB1syaoCuBXJGkJccgisN+zcRaYfXeqsrq4B4T3JnWGgYVxs5F3CXvWZAIIR/QXQ9db7XsIqY0S5u3mNmNVwPBD4HoUtqJZN5K5etnWxYPKbVdCxOT2/avz81p6S6bi8wi0dccEAsJqW3mg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657495656; bh=lyPBiCmFPZeDK6RRTc5i3QgogJm6kUHJGNQebSSyFXE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=f/p451XDYTkDPkM0XWfhfdoZxeqpe7OjfygWdSP8IRzQw/31jdCz02Vrozhpd6JgfOsi+rCYhFrnRoAVHy76OkaiqtwfDEmDwjU61a1RwIP4FDimGUar9+p1GDKRGq3+ZqWIa3nA+8dSJo1F+UR/YlRIxro2vKEWxVhu8dISJd+umlO5OOjZZqf1xlgNjJXuS8aWE5TWa6r7t3++PONRFRfd9H1EibDT/kVWAGnGtLXz+DghnPMxBRnoN7cr3j29Qte/sImngk4QZYqih5xYaxtLNseqyimmlDmzO4NH4iQxj4/1uHKldlSw2GcBJlji5xZsA5Pz2AK7bUsawoHV+w==
X-YMail-OSG: Wb.lNvMVM1m2wteBA6HQubLx9DadpkCmzXs5xfEWChEJWQH9Ehf0DHFiHrrVhmx
 Cy5v4sjdpLo4wBgXCVAifRTZTXQPTSKOJqobYR3JB9A6OZyX8hw2H3t.jcSbgs72J_Gt0OPGM5Sq
 G03zJ2qPNAM.0QqfZTg6BRzS4G7nFHoOfOH3fytk5is_APqfTywQ3rd4cwJhSnVSsJ6i9WYC4MoV
 mt8NAEkkKyJdcFbQ4joZeCuVngxkOd4B4E8my1DmkwKHE6v2qP.QQRL8SdKGOF7e2f_bC.DVmHZd
 fVrla19DJa2XUfIWBs_Crayc.cFUCQpgp7TOca3fobPSdOGYD3GpL1agNDFrohfXUER_Xo2Y8DUt
 dpHobWX.pG54ayuAQdasr0eQ.fz9mQjjQJx6JbrgyqvwtDYrVbUgRr9Y2BCZrpUWrvmfbGalL4fO
 PpxLPwk1zPFeisYt1y3CORA3txPtEQJZx4ye1Sw_zFFpTahgFaf_obwRAb5ufquJfnHfsXSSxVOS
 Nwj3xapJWavlV8s3XDYPLkYtX80c132mYJLwyWwMX5trWDOorzcPXeV.R.Q3ewgF_LGJ75C9tM2_
 ntQfNvJNxfTJ_RFeI9J2wNvhY0Ebm.hVQD4OSAeCHcaUbecIzK0pYxDKyFyUtO2Lxw1M_PVqDUiW
 Vz4jvZW4A8safrGs1SkZIVMOLbLwtZR_wghz64MuEsNQDP2aqx4mPIV7NFLekTGofbsCFr9wKtQj
 FITN9U.2gVKQswaEz0XMy7fozZ803sTs5gZNWsPRGaz2SXO9xwa_TKggjonEx2_vpXVyvXhw3md.
 JMoCzV0qLnDn_kVuXsULRN9r_wcaGyH_UfO9hBg3bl5xGfM.GapjMRp66NxSYDVHXHp3NiYOovlA
 bSCBtz_wNb0tIDzZA5UY3EGXFg92pKf7aLBB5VdNC0NjTV9wW2x_flRsVtszuY5cuTV.KA38yMRv
 WvsW54mOlDl4dwPEgl0vmzhxPpAlfSB_yuqiA6d4FIh7M88lQlZ8QlJwpmeu7.7xLQzdR9KCB0xu
 LnNbjs3vzo1LHMOytSanRcbjGJcdruzIS5Y8IpF_dDVAjtnEiv56DoWVT1P5XnBcKJ_mCi86lEua
 Eh1vt_TXfDakFAfJFl0AWytwWA.ygetysWbXbMDM27ZLal84u6BmtbmWJXTJK1qvBkvw5laxVKsw
 VJJ6.PVpS0D9BH5gYnyI3zIONrCovG21W7n6yCYs_RmltzifsgRkUsG6JiDOiK_xxIqkIU6.nx6.
 oK9qyg0U9UDs_6.QNREExmt.vYljBW7eGzRE6PX27MbfgGjDnU2aq62.Kc39xI2tLtWe4Qo.svhx
 3w7ynEu7nlBSggNMUbgfHDuU4L0BxSTWiM5D7vrqBVyaLSILbbvm0NCB1QN5rs1Ppc8gGM7ksFQK
 e0Z_uC7qxWN8bIAJUMfqU6jKKGQ8TLndJ4A7weuuSgM4A6hsz.YfTBsb.mXOZZeneQKdxzagBYyD
 a1jpqrpBNUshiChrz_RaxcUoBvdLhNOrJgegi4ph5rWeCevrH0lP79phUN7TlC4lujKpJHNAaJIO
 HMryq4AKYyZmzjPrPh0u1pw2JBX0xONsV4fgn_25.AstOH.8oDQX1hIGbQLPQtJtohvvM1lgUtmP
 UqMzvhNywrrdZOsr9Vs_plGJkJV0M.LPQO0qeeeOBIu.iPPbinv._3oc8z6tCG11EDXQYwh8wEZO
 vv8_scF3bDC5sZMBwPlX.O2Q_8BNFPvmyL.tJA58BTXwB4vyS4glaFfKTeKay3rdhjRdW708wkYv
 Lsi9aqw_DHBfqwwd9s1qbtcuLR1.YkrNtOnJDJlyNKXr_8tNe6NQC4F9RE5rVLpDmcIjWEAB_yBq
 m0Q9ouqeCOgQ2Q6uc_kS40pk8dRMMNBPk5YxPIi45r.yTLEz37GhHWpKX8Vky3GqTkk69dyEHicu
 977dgnRGZvzgWW8J6nOXgvYezWWLLQ6Qm9Ec_VgeJ_LKnSBxtjde.RfMpGrLrqiYy3rx1YZIlqo.
 zyZGM52NR_t4P8e_gdZfiMojaIIa6vh3RYivHpgoVfSoL32_2YITm94Xs.KqiCeOT15gkapxsuo2
 hEz8NMccF1qs_742tN.Oou3bH7_E9I2wdq.lKU7KoTswKYb1TpLSxO8vHq0c_ukqoMwMzhTMYBbr
 HZ9i2l5bbyYsDt3vby_JCOTkPG2dGRt3xfvM5RI4moKEk_slDMGpi.saHfYraBl6BqttTgY4DMVJ
 A7vxmoLHQZY7sQM9KDAHwWlVP11L7LG8Z67QrvtFP5FyyijIjeSyn.TZKqAyR2d4hNcFwWErrmtS
 kHuohHg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 23:27:36 +0000
Received: by hermes--production-gq1-56bb98dbc7-hx587 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 76f091862e9ac98f84a7fe3b488c9601;
          Sun, 10 Jul 2022 23:27:35 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: 
Date: Sun, 10 Jul 2022 16:27:34 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5547037B-20E2-44F7-9BC1-74A81B9F9463@yahoo.com>
References: <1F42EED0-B39F-4E33-986A-FB70A3AA4362@cyclaero.com>
 
 <45EC1E40-0615-4473-846F-8E9B5202FCC4@cyclaero.com>
 <598CB7EE-BFF9-4E8F-89CE-B51F3D1B4338@yahoo.com>
 
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lh38V4p89z3Kyk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JUyXe62m;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-10, at 15:25, Dr. Rolf Jansen  =
wrote:

>> Am 10.07.2022 um 18:44 schrieb Mark Millard :
>>=20
>> On 2022-Jul-10, at 14:02, Dr. Rolf Jansen  =
wrote:
>>=20
>>> Well, I thought the arm64-RPi one is a general purpose layout becase =
the armv7 one is identical:
>>=20
>> So far as I'm aware, the RPi*'s are unique in having all the
>> content in a file system instead of having some content outside
>> any file system. This tends to make them generally unusual in
>> various respects as far a Small Board Computers go.
>>=20
>> It is also why I can normally add a RPi* dual-boot configuration
>> adjustment to a configuration for another Small Board Computer
>> (such as the Rock64): no conflict is generated by the 2 U-Boots
>> or other such.
>>=20
>>> mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img
>>> gpart show md0 md0s2
>>>=20
>>> =3D>     63  6291393  md0  MBR  (3.0G)
>>>        63     2016       - free -  (1.0M)
>>>      2079   102312    1  fat32lba  [active]  (50M)
>>>    104391  6187041    2  freebsd  (3.0G)
>>>   6291432       24       - free -  (12K)
>>>=20
>>> =3D>      0  6187041  md0s2  BSD  (3.0G)
>>>         0       57         - free -  (29K)
>>>        57  6186880      1  freebsd-ufs  (2.9G)
>>>   6186937      104         - free -  (52K)
>>>=20
>>> Must be something historical.
>>=20
>> Just for reference for 32-bit (hard float) raspios:
>>=20
>> =
https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_a=
rmhf-2022-04-07/2022-04-04-raspios-bullseye-armhf-lite.img.xz
>>=20
>> # mdconfig -a -u 2 -t vnode -f =
2022-04-04-raspios-bullseye-armhf-lite.img=20
>> # gpart show md2
>> =3D>     63  3940289  md2  MBR  (1.9G)
>>      63     8129       - free -  (4.0M)
>>    8192   524288    1  fat32lba  (256M)
>>  532480  3407872    2  linux-data  (1.6G)
>>=20
>> So the same use of 8192 and 256M these days for 32-bit
>> raspios.
>=20
> 2079 and 8192 are starting blocks of the fat32 partition, and 2079 vs. =
8192 is the difference between non-aligned and aligned. My concern is =
not the size but whether the partitions are aligned.
>=20
> BTW, I use FreeBSD-13.1-RELEASE-arm-armv7-GENERICSD.img for the =
BeagleBone Black's and for these I also changed the partitions so the =
fat32 becomes 4k aligned.

FYI:

I happen to be looking around to see if I can notice why the
stable/13 snapshots fail to build images. So I happen to have
done the below that might be of interest:

# grep -r FAT_ /usr/main-src/release/ | more
/usr/main-src/release/arm/GENERICSD.conf:FAT_SIZE=3D"50m -b 1m"
/usr/main-src/release/arm/GENERICSD.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm/RPI-B.conf:FAT_SIZE=3D"50m"
/usr/main-src/release/arm/RPI-B.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/PINE64-LTS.conf:FAT_SIZE=3D"54m -b 1m"
/usr/main-src/release/arm64/PINE64-LTS.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/PINE64.conf:FAT_SIZE=3D"54m -b 1m"
/usr/main-src/release/arm64/PINE64.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/PINEBOOK.conf:FAT_SIZE=3D"54m -b 1m"
/usr/main-src/release/arm64/PINEBOOK.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/ROCK64.conf:FAT_SIZE=3D"50m -b 16m"
/usr/main-src/release/arm64/ROCK64.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/ROCKPRO64.conf:FAT_SIZE=3D"50m -b 16m"
/usr/main-src/release/arm64/ROCKPRO64.conf:FAT_TYPE=3D"16"
/usr/main-src/release/arm64/RPI.conf:FAT_SIZE=3D"50m -b 1m"
/usr/main-src/release/arm64/RPI.conf:FAT_TYPE=3D"16"
/usr/main-src/release/riscv/GENERICSD.conf:FAT_SIZE=3D"54m -b 8m"
/usr/main-src/release/riscv/GENERICSD.conf:FAT_TYPE=3D"16"
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
newfs_msdos -L efi -F ${FAT_TYPE} /dev/${mddev}p1
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mddev}s1

# grep -r "gpart " /usr/main-src/release/ | more
/usr/main-src/release/tools/arm.subr:   chroot ${CHROOTDIR} gpart create =
-s ${PART_SCHEME} ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t efi -l efi -a 512k -s ${FAT_SIZE} ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t freebsd-ufs -l rootfs -a 64k ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t '!12' -a 512k -s ${FAT_SIZE} ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart set -a active -i 1 ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t freebsd ${mddev}
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart create -s bsd ${mddev}s2
/usr/main-src/release/tools/arm.subr:           chroot ${CHROOTDIR} =
gpart add -t freebsd-ufs -a 64k ${mddev}s2

This was source from main [so: 14]. But it looks like
stable/13 and releng/13.1 match.

Looking, it seems that efi (GPT) and msdosfs (MBR)
have -a 512k specified and that each freebsd-ufs has
-a 64k specified. Looks like it is trying for an
alignment. (By contrast freebsd and bsd for MBR do
not specify such.)

But I'd also expect the various "-b 1m" and "-b 16m"
and "-b 8m" to override the -a ??k usage.

But, if nothing else, the above gives an idea where
to look at the scripting for FreeBSD's producing
of SBC images.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jul 11 02:18:13 2022
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 25CCF1D06BED
	for ; Mon, 11 Jul 2022 02:19:31 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh6yp0wCRz3d48
	for ; Mon, 11 Jul 2022 02:19:29 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 26B2IDQb006496
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sun, 10 Jul 2022 19:18:13 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 26B2IDbv006495
	for freebsd-arm@freebsd.org; Sun, 10 Jul 2022 19:18:13 -0700 (PDT)
	(envelope-from warlock)
Date: Sun, 10 Jul 2022 19:18:13 -0700
From: John Kennedy 
To: freebsd-arm@freebsd.org
Subject: i2c bus via USB adapter
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-Rspamd-Queue-Id: 4Lh6yp0wCRz3d48
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-0.26 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_SPAM_SHORT(0.54)[0.544];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	DMARC_NA(0.00)[phouka.net];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_DN_NONE(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

  Along with trying to attach some I2C devices to my RPI4 (which has
GPIO-pin exposure issues due to heatsink-case), I tried attaching this
device from Adafruit:

	Adafruit MCP2221A Breakout - General Purpose USB to GPIO ADC I2C Stemma QT / Qwiic
	https://www.adafruit.com/product/4471

  When I plug it into my box, I see this info:

	kernel: ugen0.4:  at usbus0
	kernel: umodem0 on uhub2
	kernel: umodem0:  on usbus0
	kernel: umodem0: data interface 1, has no CM over data, has no break
	kernel: uhid0 on uhub2
	kernel: uhid0:  on usbus0

  I've got a /dev/iic0, but that doesn't seem to be from this device:

	...
	iichb0:  mem 0x7e804000-0x7e804fff irq 26 on simplebus0
	...
	kernel: iicbus0:  on iichb0
	kernel: iic0:  on iicbus0

  Simple recursive grepping didn't get me any hits for MCP2221, and there is
a TON of hits for Microchip, so currently assuming that FreeBSD doesn't have
a driver yet.  Total ignorance at this point, but if there was a driver, would
the expected behavior (assuming right drivers are loaded) would be for the
system to figure out there was an I2C bus hiding behind it and make another
/dev/iic# available, devoted to it?

  A ugen driver (generic USB) seems right.  The umodem driver seems
reasonable (serial device).  The uhid driver seems wrong, at least in
this case, but of course most of the hits I see on the forums are mice
and such, so maybe misidentified in this case.

From nobody Mon Jul 11 03:18:59 2022
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 BB1141D0F110
	for ; Mon, 11 Jul 2022 03:19:03 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh8HV2fkwz3kXd
	for ; Mon, 11 Jul 2022 03:19:02 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657509540;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=8w5lp7EdSM6sooPTWiAkyYcAUMWmiJWXRoJn8F1dS6c=;
    b=cIb8TkJu73kTyv+9r1TobOw7HNnlf/UfmjpMDcppfxB0BrQZe6r/k5H7Vj7FiiBxrR
    zzW0IZpj878iJY1ioQ9KbzNfx7z/GHFUi2iUWSvBkeL/O3H9c8Q/YCtY85X0pwixXCmi
    LBOspKRhuoHO5mnwbHdrOWaNFeWhhrslYr+a7ojI+DnIJlFElKPuO3gAIYImAV6Ew990
    oZ4JaU6JRIdQ4hVWKERG+hVyOtfHKTQfDwDOVhU8B2Q9bivsTYz66QiJ257vJD4beQbf
    rKlq/uu0Ey3Xz9Xzwcc9ykWe0paOipZhe+vnHcDMLGwk52NTwD+1quy0DJGzuubIhe3S
    N99g==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.46.1 AUTH)
    with ESMTPSA id kcd9d5y6B3J0dCh
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Mon, 11 Jul 2022 05:19:00 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 2471463942
	for ; Mon, 11 Jul 2022 05:18:59 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Re: i2c bus via USB adapter
Date: Mon, 11 Jul 2022 00:18:59 -0300
References: 
To: freebsd-arm 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4Lh8HV2fkwz3kXd
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=cIb8TkJu;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.161 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.20 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25:c];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	RWL_MAILSPIKE_GOOD(-0.10)[81.169.146.161:from];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[81.169.146.161:from];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[cyclaero.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 10.07.2022 um 23:18 schrieb John Kennedy :
>=20
> Along with trying to attach some I2C devices to my RPI4 (which has
> GPIO-pin exposure issues due to heatsink-case), I tried attaching this
> device from Adafruit:
>=20
> 	Adafruit MCP2221A Breakout - General Purpose USB to GPIO ADC I2C =
Stemma QT / Qwiic
> 	https://www.adafruit.com/product/4471

I cannot help you with this piece.

However, did you know that we can easily enable just some more I2C =
busses of the RPi4 using other pins on the header. For example I enabled =
I2C5 running on GPIO12/13. This works concurrently to the default I2C1 =
on GPIO2/3.

The respective numbers of the physical pins on the header for I2C5 are:
  17: 3.3 V
  32: SDA
  33: SCL
  34: GND

These pins are on the other end to where you connected the vent of the =
heat sink, and chances are that these are still accessible.

Anyway, for enabling I2C5 (we may choose from I2C3, I2C4, I2C5 and I2C6) =
on a Raspberry Pi 4, we do:

# fetch =
https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/ove=
rlays/i2c5-overlay.dts
# dtc -I dts -O dtb -b0 -@ -o /boot/msdos/overlays/i2c5.dtbo =
i2c5-overlay.dts

Then we add the following 2 lines to /boot/msdos/config.txt:

  gpio=3D12,13=3Da5
  dtoverlay=3Di2c5,pins_12_13

While my DS3231 RTC breakout board worked on these pins (phys. #32,#33) =
without any problem, I needed to add 3.3 k=CE=A9 pull-up resistors to =
the SDA and SCL lines for other modules. Most probably said RTC breakout =
came already with pull-ups on board. Anyway, finally I left the RTC on =
the default I2C bus.

In dmesg:

  ...
  iicbus0:  on iichb0
  iic0:  on iicbus0
  ds32310:  at addr 0xd0 on iicbus0
  iicbus1:  on iichb1
  iic1:  on iicbus1
  ...=

From nobody Mon Jul 11 06:26:34 2022
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 DAF921D0E8DB
	for ; Mon, 11 Jul 2022 06:54:19 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "dons.net.au", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhF3s2Jj9z493b
	for ; Mon, 11 Jul 2022 06:54:16 +0000 (UTC)
	(envelope-from darius@dons.net.au)
Received: from midget.dons.net.au (localhost [127.0.0.1])
	by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26B6R56g034051
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 11 Jul 2022 15:57:15 +0930 (ACST)
	(envelope-from darius@dons.net.au)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au;
	s=default; t=1657520839;
	bh=q4kzkDCgh7zPmJEIkEyAbgnaNP7Kti5Arye99InkLOk=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=jZ6N5gXmnH/c82wMkK+IR+gyS1obSmE7sobDjf9f4heHc7M8TkhHSVs+JFDHBZ2Bj
	 waxf5ZB3JZllfGPASSzGhepXCGSS3I0iDbmjvA7zZenCgeeGnWfxh0OA5TlkkGGhQt
	 +csX21c+lj4aFtDqjVpUIjT0u3ozErRWU875bt0U=
Received: (from mailnull@localhost)
	by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26B6Qisv034041
	for ; Mon, 11 Jul 2022 15:56:44 +0930 (ACST)
	(envelope-from darius@dons.net.au)
X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:d5ee:63bd:dd7f:a5c3
Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:d5ee:63bd:dd7f:a5c3] [2403:5800:5200:4700:d5ee:63bd:dd7f:a5c3])
	by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26B6Qi55034029; Mon, 11 Jul 2022 15:56:44 +0930
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 \(3696.100.31\))
Subject: Re: i2c bus via USB adapter
From: "Daniel O'Connor" 
In-Reply-To: 
Date: Mon, 11 Jul 2022 15:56:34 +0930
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <22B46606-5269-4691-A030-2F07BF0E45BF@dons.net.au>
References: 
To: John Kennedy 
X-Mailer: Apple Mail (2.3696.100.31)
X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5
X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1
X-Rspamd-Queue-Id: 4LhF3s2Jj9z493b
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dons.net.au header.s=default header.b=jZ6N5gXm;
	dmarc=pass (policy=quarantine) header.from=dons.net.au;
	spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[dons.net.au:s=default];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[dons.net.au:+];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 11 Jul 2022, at 11:48, John Kennedy  wrote:
>  Simple recursive grepping didn't get me any hits for MCP2221, and =
there is
> a TON of hits for Microchip, so currently assuming that FreeBSD =
doesn't have
> a driver yet.  Total ignorance at this point, but if there was a =
driver, would
> the expected behavior (assuming right drivers are loaded) would be for =
the
> system to figure out there was an I2C bus hiding behind it and make =
another
> /dev/iic# available, devoted to it?

I don't believe there is a FreeBSD driver for it.

>  A ugen driver (generic USB) seems right.  The umodem driver seems
> reasonable (serial device).  The uhid driver seems wrong, at least in
> this case, but of course most of the hits I see on the forums are mice
> and such, so maybe misidentified in this case.

Checking the MCP2221 data sheet shows it does present itself as UART =
(since it is a UART) and HID (for I2C control)

HID is common because it means you don't need a custom driver (and the =
associated cost/PITA factor with signing one for Windows & OSX).

Something like this should work on FreeBSD: =
https://github.com/ZakKemble/libmcp2221
(Might take a bit of porting though)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum


From nobody Mon Jul 11 14:08:02 2022
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 58D261D0B7A7
	for ; Mon, 11 Jul 2022 14:10:46 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhQlT2LR8z3xfn
	for ; Mon, 11 Jul 2022 14:10:45 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 26BE8204079736
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 11 Jul 2022 07:08:02 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 26BE82VE079735;
	Mon, 11 Jul 2022 07:08:02 -0700 (PDT)
	(envelope-from warlock)
Date: Mon, 11 Jul 2022 07:08:02 -0700
From: John Kennedy 
To: "Daniel O'Connor" 
Cc: freebsd-arm@freebsd.org
Subject: Re: i2c bus via USB adapter
Message-ID: 
References: 
 <22B46606-5269-4691-A030-2F07BF0E45BF@dons.net.au>
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: <22B46606-5269-4691-A030-2F07BF0E45BF@dons.net.au>
X-Rspamd-Queue-Id: 4LhQlT2LR8z3xfn
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [-1.79 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.989];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[phouka.net];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Jul 11, 2022 at 03:56:34PM +0930, Daniel O'Connor wrote:
> Checking the MCP2221 data sheet shows it does present itself as UART (since it is a UART) and HID (for I2C control)
> HID is common because it means you don't need a custom driver (and the associated cost/PITA factor with signing one for Windows & OSX).

  Hmm.  I think you're getting my brain on the right track.  Yeah, this
is totally intended for people to plug into any old desktop and
interface with i2c devices in an OS-agnostic way.

> Something like this should work on FreeBSD: https://github.com/ZakKemble/libmcp2221
> (Might take a bit of porting though)

  I know Adafruit generally makes their code available, although I think
they're more GPL (and aimed towards arduino).  I was initially trying to
keep my brain license-clean if I was going to mess with kernel code.

From nobody Mon Jul 11 14:31:33 2022
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 CEE301D0ED85
	for ; Mon, 11 Jul 2022 14:31:48 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhRCl66P2z41bj
	for ; Mon, 11 Jul 2022 14:31:47 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26BEVXXR037802;
	Mon, 11 Jul 2022 07:31:33 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26BEVXCf037801;
	Mon, 11 Jul 2022 07:31:33 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net>
Subject: Re: Partition layout of ARM SD card images
In-Reply-To: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com>
To: Mark Millard 
Date: Mon, 11 Jul 2022 07:31:33 -0700 (PDT)
CC: "Dr. Rolf Jansen" ,
        freebsd-arm 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4LhRCl66P2z41bj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net
X-Spamd-Result: default: False [-2.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[dnsmgr.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> 
> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen  wrote:
> 
> >> Am 10.07.2022 um 17:48 schrieb Mark Millard :
> >> 
> >> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  wrote:
> >> 
> >>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
> >>> 
> >>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> >>> # gpart show md0 md0s2
> >>> 
> >>> =>     63  6291393  md0  MBR  (3.0G)
> >>>        63     2016       - free -  (1.0M)
> >>>      2079   102312    1  fat32lba  [active]  (50M)
> >>>    104391  6187041    2  freebsd  (3.0G)
> >>>   6291432       24       - free -  (12K)
> >>> 
> >>> =>      0  6187041  md0s2  BSD  (3.0G)
> >>>         0       57         - free -  (29K)
> >>>        57  6186880      1  freebsd-ufs  (2.9G)
> >>>   6186937      104         - free -  (52K)
> >>> 
> >>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
> >>> 
> >>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
> >> 
> >> The layout details are more specific to the aarch64 RPi* context
> >> than to general aarch64 SD card images. For example, the Rock64
> >> image is different:
> >> 
> >> # mdconfig -a -u 0 -t vnode -f  FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> >> # gpart show md0
> >> =>     40  6291376  md0  GPT  (3.0G)
> >>      40    32728       - free -  (16M)
> >>   32768   102400    1  efi  (50M)
> >>  135168  6156160    2  freebsd-ufs  (2.9G)
> >> 6291328       88       - free -  (44K)
> > 
> > This is a GPT table, while the others are still MBR. Images which come with u-boot must have a different layout.
> 
> I know it is a GPT table. That is part of the point about
> the variety of contexts that there are across the Small
> Board Computers.
> 
> No SBC that has a U-Boot/whatever needing more space
> than is provided below is going to use the same
> 2079 figure:
> 
> =>     63  ???  md0  ???  (?)
>        63     2016       - free -  (1.0M)

I read this thread.. and it keeps nagging me in
the back of the head, I know this 2016 number.
It is common when the sectors per track of a
drive is reported as "32", its an attempt to
1M align such a drive, is somehow the image
creation code picking up 32 to do the align
calculation wrongly on a 63 sector/track
image?

>      2079   ??????    1  fat32lba  [active]  (?)

The OP is correct, this is a horrid state of alignment
and the cause should be tracked down and fixed!  I
can see no valid reason to have an approx
1MB free hole that causes this missalignment,
that free hole should be (2048-63)=1985

AHhhhh thought hits me... did the code get changed
to make the images larger, and somehow the image
creation code went from a 32 sector/track fake C/H/S
to a 63 sector fake C/H/S, and the code has all
along been assuming 32 sector/track drives?

> 
> MBR vs. GPT is not the fundamental issue for that.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Mon Jul 11 14:38:33 2022
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 55DEB1D0FC75
	for ; Mon, 11 Jul 2022 14:38:47 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931])
	(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 4LhRMn73mYz422B
	for ; Mon, 11 Jul 2022 14:38:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x931.google.com with SMTP id s7so439277uao.4
        for ; Mon, 11 Jul 2022 07:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=LH+/W2POoOaJ/ofqV5a+uAMocJthirOl6TDLNxpBzn0=;
        b=rI2m5QdeLzxY0iZYeBRaqUhbUH1Z6qBNY0qJuyQhZYpncskYnakM8aMHizoVn5d0P3
         iLTryZ/e5xhmYrkEiYyD6+Kl9A7SF0QvDPXQBiJ9rbldIznmFHQ93kfIOXUjdOpZnjAU
         2PUaXxM3NdXmb7n0dReTEXv6Z36fWKGbsZxf1tEr1MiO4OazvzuJ550HnShAo7j9iY/0
         FOFwBzhBBx+UxGDTca1qobec3enr9zGw2WPztjbQrjDvRWtUjdcGz029ArMe4bqHHz3E
         34cOeoiKWzof9wSy4AgkdwJ9gJei4m2PUPMZDIMAJpk20EC/gGiu/pu0kenDuX34kMPo
         Indw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=LH+/W2POoOaJ/ofqV5a+uAMocJthirOl6TDLNxpBzn0=;
        b=7ETki/IPkwASM3Sfv8R+qdrEFI4ojcoJyOsuK0hlChLZKW6iUHpf6ZcwB1vBm3bmCn
         TYSSPE4WcdRZuE0f0CASYafJ8at4nvsGALvTpNVYeK4UO2+r+wDB1dFNOgBLqpI/Cbde
         niaqt2dwJ+bmveim/9Je9zJmjVbRPucKusQfnLT49X1fK7mWMu9dG/zH4CW/raFoW6hN
         GtaeKKUEZHlkmC3ywCIA0w2vYEr9Zy6dUYzeyX0+jm7B93u1bODD/EV4EbgLBg+f/RkI
         2QZD4mCLotePST37APT376Oz5eoMIZjvs/xmdAL2iFo911kFbQPlLjQJ8onarBwqSXiC
         HT4w==
X-Gm-Message-State: AJIora8lhIj9LMclAgZ7w0OLWTkRFgGfPTWW5zsI7GsyGI0OX3lzjvSt
	okVbUfkJgjFcZm9K26qLO+SmAOiCnAGKi21df+fYiQCxYbY=
X-Google-Smtp-Source: AGRyM1tZIy1oqAuDLsV7RXONAybT5meX8zWpjZhAxi1NXnEYr9dOpqiLojZg77T2FEFeSAX9YPSfzu/cYBdk8emS6o4=
X-Received: by 2002:ab0:2a06:0:b0:379:96c7:bf4f with SMTP id
 o6-20020ab02a06000000b0037996c7bf4fmr5731773uar.8.1657550324576; Mon, 11 Jul
 2022 07:38:44 -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: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com> <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net>
In-Reply-To: <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net>
From: Warner Losh 
Date: Mon, 11 Jul 2022 08:38:33 -0600
Message-ID: 
Subject: Re: Partition layout of ARM SD card images
To: "Rodney W. Grimes" 
Cc: Mark Millard , "Dr. Rolf Jansen" , 
	freebsd-arm 
Content-Type: multipart/alternative; boundary="0000000000004b4a7c05e388827f"
X-Rspamd-Queue-Id: 4LhRMn73mYz422B
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=rI2m5Qde;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[yahoo.com,cyclaero.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000004b4a7c05e388827f
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes <
freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> >
> > On 2022-Jul-10, at 14:34, Dr. Rolf Jansen 
> wrote:
> >
> > >> Am 10.07.2022 um 17:48 schrieb Mark Millard :
> > >>
> > >> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen 
> wrote:
> > >>
> > >>> For example let's have a llok on the partition layout of,
> FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
> > >>>
> > >>> # mdconfig -a -u 0 -t vnode -f
> diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> > >>> # gpart show md0 md0s2
> > >>>
> > >>> =>     63  6291393  md0  MBR  (3.0G)
> > >>>        63     2016       - free -  (1.0M)
> > >>>      2079   102312    1  fat32lba  [active]  (50M)
> > >>>    104391  6187041    2  freebsd  (3.0G)
> > >>>   6291432       24       - free -  (12K)
> > >>>
> > >>> =>      0  6187041  md0s2  BSD  (3.0G)
> > >>>         0       57         - free -  (29K)
> > >>>        57  6186880      1  freebsd-ufs  (2.9G)
> > >>>   6186937      104         - free -  (52K)
> > >>>
> > >>> The start of the fat32 boot slice s1 (containing the u-boot) stuff
> is neither aligned to 1M nor to 4k, it starts on an odd base. The start of
> the BSD payload slice s2 and its size are odd as well. The padding of 57
> blocks within s2 lets the UFS partition start on a globally even base,
> namely 104391+57 = 104448, which as a matter of fact is 4k aligned
> (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 =
> 51), however all this keeps looking strange.
> > >>>
> > >>> Are there reasons for this partition layout besides making it look
> more interesting? If yes, some insights would be good.
> > >>
> > >> The layout details are more specific to the aarch64 RPi* context
> > >> than to general aarch64 SD card images. For example, the Rock64
> > >> image is different:
> > >>
> > >> # mdconfig -a -u 0 -t vnode -f
> FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> > >> # gpart show md0
> > >> =>     40  6291376  md0  GPT  (3.0G)
> > >>      40    32728       - free -  (16M)
> > >>   32768   102400    1  efi  (50M)
> > >>  135168  6156160    2  freebsd-ufs  (2.9G)
> > >> 6291328       88       - free -  (44K)
> > >
> > > This is a GPT table, while the others are still MBR. Images which come
> with u-boot must have a different layout.
> >
> > I know it is a GPT table. That is part of the point about
> > the variety of contexts that there are across the Small
> > Board Computers.
> >
> > No SBC that has a U-Boot/whatever needing more space
> > than is provided below is going to use the same
> > 2079 figure:
> >
> > =>     63  ???  md0  ???  (?)
> >        63     2016       - free -  (1.0M)
>
> I read this thread.. and it keeps nagging me in
> the back of the head, I know this 2016 number.
> It is common when the sectors per track of a
> drive is reported as "32", its an attempt to
> 1M align such a drive, is somehow the image
> creation code picking up 32 to do the align
> calculation wrongly on a 63 sector/track
> image?
>
> >      2079   ??????    1  fat32lba  [active]  (?)
>
> The OP is correct, this is a horrid state of alignment
> and the cause should be tracked down and fixed!  I
> can see no valid reason to have an approx
> 1MB free hole that causes this missalignment,
> that free hole should be (2048-63)=1985
>

Yes, we should be aligning at a 1M or 2M boundary on the
root device, not within the partition. The offsets are supposed
to do that, and if there's a problem we should fix it.


> AHhhhh thought hits me... did the code get changed
> to make the images larger, and somehow the image
> creation code went from a 32 sector/track fake C/H/S
> to a 63 sector fake C/H/S, and the code has all
> along been assuming 32 sector/track drives?
>

63 sector for 'fake' C/H/S has been a thing since at least
FreeBSD 6 and maybe a little longer. There's no cutover
based on image size of the device. The older ATA code,
pre-cam but post SOS rewrite, would try very hard to return
the values from the underlying device that it reported. And that
would lead to mismatches because it was different than the lies
that md told by default. But that only mattered for really old
BIOSes that couldn't handle LBA/packet mode in booting (which
is the primary reason the old fdisk program could set the ending CHS
of partitions since the FreeBSD code used that to guess the CHS
of the drive itself in the absence of other information).

I don't think the kernel has changed in this area in a very long time.
At worse, we're seeing a mkimage bug.

Warner


> >
> > MBR vs. GPT is not the fundamental issue for that.
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> >
> >
> >
> >
>
> --
> Rod Grimes
> rgrimes@freebsd.org
>
>

--0000000000004b4a7c05e388827f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jul 11, 2022 at 8:31 AM Rodne=
y W. Grimes <freebsd-rw=
g@gndrsh.dnsmgr.net> wrote:
> 

> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:=


> 

> >> Am 10.07.2022 um 17:48 schrieb Mark Millard <marklmi@yahoo.com>:

> >> 

> >> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen <freebsd-rj@cyclaero.com&g=
t; wrote:

> >> 

> >>> For example let's have a llok on the partition layout=
 of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
> >>> 

> >>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEA=
SE-arm64-aarch64-RPI.img

> >>> # gpart show md0 md0s2

> >>> 

> >>> =3D>=C2=A0 =C2=A0 =C2=A063=C2=A0 6291393=C2=A0 md0=C2=
=A0 MBR=C2=A0 (3.0G)

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 63=C2=A0 =C2=A0 =C2=A02016=C2=
=A0 =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (1.0M)

> >>>=C2=A0 =C2=A0 =C2=A0 2079=C2=A0 =C2=A0102312=C2=A0 =C2=A0 =
1=C2=A0 fat32lba=C2=A0 [active]=C2=A0 (50M)

> >>>=C2=A0 =C2=A0 104391=C2=A0 6187041=C2=A0 =C2=A0 2=C2=A0 fr=
eebsd=C2=A0 (3.0G)

> >>>=C2=A0 =C2=A06291432=C2=A0 =C2=A0 =C2=A0 =C2=A024=C2=A0 =
=C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (12K)

> >>> 

> >>> =3D>=C2=A0 =C2=A0 =C2=A0 0=C2=A0 6187041=C2=A0 md0s2=
=C2=A0 BSD=C2=A0 (3.0G)

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =
=C2=A057=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (29K)

> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 57=C2=A0 6186880=C2=A0 =C2=A0 =
=C2=A0 1=C2=A0 freebsd-ufs=C2=A0 (2.9G)

> >>>=C2=A0 =C2=A06186937=C2=A0 =C2=A0 =C2=A0 104=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0- free -=C2=A0 (52K)

> >>> 

> >>> The start of the fat32 boot slice s1 (containing the u-bo=
ot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The=
 start of the BSD payload slice s2 and its size are odd as well. The paddin=
g of 57 blocks within s2 lets the UFS partition start on a globally even ba=
se, namely 104391+57 =3D 104448, which as a matter of fact is 4k aligned (1=
04448*512/4096 =3D 13056) and 1M aligned as well (104448*512/1024/1024 =3D =
51), however all this keeps looking strange.

> >>> 

> >>> Are there reasons for this partition layout besides makin=
g it look more interesting? If yes, some insights would be good.

> >> 

> >> The layout details are more specific to the aarch64 RPi* cont=
ext

> >> than to general aarch64 SD card images. For example, the Rock=
64

> >> image is different:

> >> 

> >> # mdconfig -a -u 0 -t vnode -f=C2=A0 FreeBSD-14.0-CURRENT-arm=
64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img

> >> # gpart show md0

> >> =3D>=C2=A0 =C2=A0 =C2=A040=C2=A0 6291376=C2=A0 md0=C2=A0 G=
PT=C2=A0 (3.0G)

> >>=C2=A0 =C2=A0 =C2=A0 40=C2=A0 =C2=A0 32728=C2=A0 =C2=A0 =C2=A0=
 =C2=A0- free -=C2=A0 (16M)

> >>=C2=A0 =C2=A032768=C2=A0 =C2=A0102400=C2=A0 =C2=A0 1=C2=A0 efi=
=C2=A0 (50M)

> >>=C2=A0 135168=C2=A0 6156160=C2=A0 =C2=A0 2=C2=A0 freebsd-ufs=
=C2=A0 (2.9G)

> >> 6291328=C2=A0 =C2=A0 =C2=A0 =C2=A088=C2=A0 =C2=A0 =C2=A0 =C2=
=A0- free -=C2=A0 (44K)

> > 

> > This is a GPT table, while the others are still MBR. Images which=
 come with u-boot must have a different layout.

> 

> I know it is a GPT table. That is part of the point about

> the variety of contexts that there are across the Small

> Board Computers.

> 

> No SBC that has a U-Boot/whatever needing more space

> than is provided below is going to use the same

> 2079 figure:

> 

> =3D>=C2=A0 =C2=A0 =C2=A063=C2=A0 ???=C2=A0 md0=C2=A0 ???=C2=A0 (?)<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 63=C2=A0 =C2=A0 =C2=A02016=C2=A0 =C2=A0 =C2=
=A0 =C2=A0- free -=C2=A0 (1.0M)



I read this thread.. and it keeps nagging me in

the back of the head, I know this 2016 number.

It is common when the sectors per track of a

drive is reported as "32", its an attempt to

1M align such a drive, is somehow the image

creation code picking up 32 to do the align

calculation wrongly on a 63 sector/track

image?



>=C2=A0 =C2=A0 =C2=A0 2079=C2=A0 =C2=A0??????=C2=A0 =C2=A0 1=C2=A0 fat32=
lba=C2=A0 [active]=C2=A0 (?)



The OP is correct, this is a horrid state of alignment

and the cause should be tracked down and fixed!=C2=A0 I

can see no valid reason to have an approx

1MB free hole that causes this missalignment,

that free hole should be (2048-63)=3D1985

Yes, we should be aligning at a 1M or 2M boundary on the
root =
device, not within the partition. The offsets are supposed
to do =
that, and if there's a problem we should fix it.
=C2=A0
=


AHhhhh thought hits me... did the code get changed

to make the images larger, and somehow the image

creation code went from a 32 sector/track fake C/H/S

to a 63 sector fake C/H/S, and the code has all

along been assuming 32 sector/track drives?

=

63 sector for 'fake' C/H/S has been a thing since at least
FreeBSD 6 and maybe a little longer. There's no cutover
based on image size of the device. The older ATA code,
pre-cam =
but post SOS rewrite, would try very hard to return
the values fr=
om the underlying device that it reported. And that
would lead to=
 mismatches because it was different than the lies
that md told b=
y default. But that only mattered for really old
BIOSes that coul=
dn't handle LBA/packet mode in booting (which
is the primary =
reason the old fdisk program could set the ending CHS
of partitio=
ns since the FreeBSD code used that to guess the CHS
of the drive=
 itself in the absence of other information).

I do=
n't think the kernel has changed in this area in a very long time.
At worse, we're seeing a mkimage bug.

Wa=
rner
=C2=A0
yahoo.com

> 

> 

> 

> 



-- 

Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org






--0000000000004b4a7c05e388827f--

From nobody Mon Jul 11 16:50:11 2022
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 9AF691CFC74C
	for ; Mon, 11 Jul 2022 16:50:21 +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 4LhVHc2FHjz3Mn9
	for ; Mon, 11 Jul 2022 16:50:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657558218; bh=P78lZ0GDuTfgIwYkJTmKJ49B/g38IVGpgPU4ExVX5M8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AmYE46C1xgZe7s4a7oeLGSL6pI6L3x3jlfbVpUD1LZhJQNx/8JEIsYTcbG81lrHCL+W/Lpae6Becz9D1vAt+CuVcB/8OmFzziYRWenvkiyyDyj2B+dmX1cjZNXZu03ALl4SFHW9nlb3MAm7MROX+ULec2mXd2KvEJpj9eAPgZ4zMd7fYixxFLS+6yvHfSC+kLpKb2cb6TWQvvF2EsgRvOAUXiAFrNejNV3ab9ocqoiwdZRLwlxOXoYfDPPfqAa26Sb8zchf/3cvx8YEsSOivXLHhdJjMYuGCz6UxAssazpV/Aj4MAH8tbdwWFEQ4opfJ54J8DNJHIV7QdFFNeEt+qg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657558218; bh=rdLGS8nipx/pGNPsOV+iVqVy5pdRA+0VwwAq9wsb/Qh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OCTkAniWbc/0oP72vWMub4SdJBBeGkznbY5K1iQznV0KvfDIKVrQeCyHpTlT3/VvBKU7Fx3sY4TnAiS/3pH21G65KUS+WiCo6nt5s/5uWYYkY7kGGnU7SjvqWA5moTFjLR8CO9SNX1KxivJnqP/MnrBgzuOMB+V9wpGwUJ4krHtfeVdCn3FY2w1U60wxj3DSkPXSbALoz8e5fAAnvqF3sRgqrm+9KtjBYYmsWNlG7GK6TrWYj9e7phRQOqR3rAKrGZ27iCzH2TsaTqX0+jRI3QbvBMvSKqptzes/eGLyemw32lV6r+h1NYUOTpsnCMHyVZe3cz1XslXh6MpK49V1VQ==
X-YMail-OSG: ZuiBPYYVM1m.DRIZifpZWlOvgaVwPNXNFQjUax9EJTxSmW49njisslM_tjMxKHn
 hXADrCebFEa56AjJpp9SBpbpqScj0ghJ7TmeFlU6o5aUvdvMeavfz5PfysWe2kYuGZE1R4Hcmapm
 iQL0FmH0Gssc1KOGEQY9b6c5qdYoUy7AjfSd8v6fzK2bt0HD6gIhb8ylfxB3r1.CZFKHUY2TY5qn
 KkqNKKwC3t306GHAZBeRio3UtBRFYgodm3HxgFDmPnA7DzarG3Uyvuh2cZDNo_4poBjBO0vza3Uh
 e73vnzfQ9CAEpSncjVriWr5d5o74t5jWoC9k29mNQ7kTAkMOy_ZuQEcN13g4ePpESyeFT6lcChik
 AjExI2XJEDjs3_7DZiJuROhAw3KjpXViaIPRtgTeGCgjmgssxP4EMxriGTC49MfasAMo1MFlOMN1
 XFRBFaB.4q4d1TKfFip11NAaQ.D30lGAFvfTyCy1Fs3r2JMqgk3guBFUXZ4R3aDz3VxIemv5IfBS
 2qSuTFUZ2OR9nc4cgM9a4OEHCgVj6HvRW.6tUo5bMLEub0m5UwRff3reDfJJxigO.JdLp9go6ZMT
 _BU2sg3KsyhKLOH4bvvUlD_YFJRoo1uA8Qyns0pXbfTWRl0P9oTU2EdrahMrbbSUT.aOP5.iHQpi
 kLRZCW3kXuhHzmjBUCJMgzcOJxEOg_kuvvFjCX8vUnxmAXJExJPSRExvVRqNxKPY5YwCvDLXPnrx
 OPi1vzaRdfAu.ASS1ZebLf_INRuRZETUVBMAxUiGZWjkTrFbwMZS4c5ev4_0m3dGqwsRza16xf0l
 6DSIZbw9KRGZ4st6rxO2GOeH6vi.WKA18lVfLkXMp9wko7uljPkhCJ40tAir17.XFCkriJBg0SJK
 kzNjIQrjAYs9kh7dfGSZ6zG_ckWQ88rfYYjmSZs9M5vzMakarraQd7DwMUM0sFFrge3BGLj38UTX
 .qzl.vXPy93u.uI9MsgWIbqkC6siM8M44cLPhOXfv.KwPzSpTUPEd9RF3yz9qJAQpuv9Yi2UmoXG
 7xEOFZY3M0nR8HLjJZm2RsN6nKWwk891VLElQzAkGwfAxPMMeWBeeMGbDJXjV6jLiFITOtVRud1z
 QVPa54ZvILz8x7r69KA56LuQ47.dof8BrflAMYUHnPTuvuspKweFq0ApJEovBuznUT9yUHHtJ2hG
 HsF4Wgv4JioURSKRdrMZiuZiR6vt8ujJnhsWpy5tZuxxsQC8R40QyA..dEGJ0MJSv740harewwzC
 8R6hzyfpB36t6.Ow7JmK10V1s4ATO0Sc5XNZQFISP3JSwUPGlkA_UUdhMxT1AI8m1LGvMtSEGCIk
 ClCJY4TxKDfwuDbJOpobswpzvtICpFreOp0xY8_mQ60_eWXwggVgiC2kyx_Vz1JF4MQVK8BEAJRv
 zrAKMde_TrsJ2zEG0E7CFx.ZvmK4m8.8DPtRxM3cPs2O5EcrwbGOg9b.KGPXuFPuvQDbKrfU0Ibr
 zwKn.jNMQJTNzlrqkczzcdpBkoV27Hnx93F1JykFaD8aHH.LOcJPhcUjnq4CA765kvfRUzeiH8gH
 SDRiq9eFn4QNZ_cLtVgaFRXPTRj0BTK2EIheiKOaGeoKIoE9YVQF0Yhhj_sTPBVUApXznMpKNOGY
 qCvI1fiE847xQ5J7sq98bOpdsxVoJFmyp7ypkUvzKi0luq0E6WGT12VdV0YHSbjBImuxhJwAhcya
 ocffOt1ISpelX_Xzx5b9RF3ebjbmFnrz8PyqGc9z6MMJ2z_O_KdfGLeNWAOBMoOUGEMKy1oOUj5D
 0gLA6sm2M4q6ymFhyVk_Zi4JGxmnC3.V64Rl4f281IFDWfAL7fpJs5HcxHUTaNOk7LQT670Io3ST
 8IV3iv0Hj00NeHUcedpyihAO24pwhfukbObOAcQk2wSfFexmoJogiUxbbm7hgHG92cP4jXf4GhZx
 _2MQ5jHeqjs7D58vFEeovpOSzrZYzo8XUrl3jY8QvFiQmDsc96gBtlfujvEG9oSIs9lexwMqvNHW
 LUOLSGhvT6VyK3npXuTgeArvcygo7X_IR4RctMeLa0.pM_2HFOhQ8tlWg88UIx80KO_tWpk7QTox
 g_hfxBy_6CfxrJHyXsdivLf3RJFJ9n0.rkiqwp7ZTZzPbvHEHQIOj70JH2490xhKL7sP4LHdHsr9
 pi6mN13.7uaZ6Km8lTalZvwA6hVE.muHO9tpHMySzPcY5XaNQiF57RE5RCPiXNqSCLrkw4F1lm8B
 rCkzSCYXN84RoYpvh.o3a.FFu.TwZdbmsU1h5ds5o.kKRNdCtDgqg7QFn9B6TLpnOPE0pSRu9ZHV
 sEdN2GtU-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 Jul 2022 16:50:18 +0000
Received: by hermes--production-gq1-56bb98dbc7-mpzkq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8eb7b21379b76d947eaf393a5f757367;
          Mon, 11 Jul 2022 16:50:12 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: 
Date: Mon, 11 Jul 2022 09:50:11 -0700
Cc: "Rodney W. Grimes" ,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com>
References: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com>
 <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net>
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LhVHc2FHjz3Mn9
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=AmYE46C1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.64 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_SPAM_MEDIUM(0.86)[0.862];
	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];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-11, at 07:38, Warner Losh  wrote:

> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes =
 wrote:
>> >=20
>> > On 2022-Jul-10, at 14:34, Dr. Rolf Jansen  =
wrote:
>> >=20
>> > >> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>> > >>=20
>> > >> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen =
 wrote:
>> > >>=20
>> > >>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>> > >>>=20
>> > >>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>> > >>> # gpart show md0 md0s2
>> > >>>=20
>> > >>> =3D>     63  6291393  md0  MBR  (3.0G)
>> > >>>        63     2016       - free -  (1.0M)
>> > >>>      2079   102312    1  fat32lba  [active]  (50M)
>> > >>>    104391  6187041    2  freebsd  (3.0G)
>> > >>>   6291432       24       - free -  (12K)
>> > >>>=20
>> > >>> =3D>      0  6187041  md0s2  BSD  (3.0G)
>> > >>>         0       57         - free -  (29K)
>> > >>>        57  6186880      1  freebsd-ufs  (2.9G)
>> > >>>   6186937      104         - free -  (52K)
>> > >>>=20
>> > >>> The start of the fat32 boot slice s1 (containing the u-boot) =
stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The =
start of the BSD payload slice s2 and its size are odd as well. The =
padding of 57 blocks within s2 lets the UFS partition start on a =
globally even base, namely 104391+57 =3D 104448, which as a matter of =
fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>> > >>>=20
>> > >>> Are there reasons for this partition layout besides making it =
look more interesting? If yes, some insights would be good.
>> > >>=20
>> > >> The layout details are more specific to the aarch64 RPi* context
>> > >> than to general aarch64 SD card images. For example, the Rock64
>> > >> image is different:
>> > >>=20
>> > >> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>> > >> # gpart show md0
>> > >> =3D>     40  6291376  md0  GPT  (3.0G)
>> > >>      40    32728       - free -  (16M)
>> > >>   32768   102400    1  efi  (50M)
>> > >>  135168  6156160    2  freebsd-ufs  (2.9G)
>> > >> 6291328       88       - free -  (44K)
>> > >=20
>> > > This is a GPT table, while the others are still MBR. Images which =
come with u-boot must have a different layout.
>> >=20
>> > I know it is a GPT table. That is part of the point about
>> > the variety of contexts that there are across the Small
>> > Board Computers.
>> >=20
>> > No SBC that has a U-Boot/whatever needing more space
>> > than is provided below is going to use the same
>> > 2079 figure:
>> >=20
>> > =3D>     63  ???  md0  ???  (?)
>> >        63     2016       - free -  (1.0M)
>>=20
>> I read this thread.. and it keeps nagging me in
>> the back of the head, I know this 2016 number.
>> It is common when the sectors per track of a
>> drive is reported as "32", its an attempt to
>> 1M align such a drive, is somehow the image
>> creation code picking up 32 to do the align
>> calculation wrongly on a 63 sector/track
>> image?
>>=20
>> >      2079   ??????    1  fat32lba  [active]  (?)
>>=20
>> The OP is correct, this is a horrid state of alignment
>> and the cause should be tracked down and fixed!  I
>> can see no valid reason to have an approx
>> 1MB free hole that causes this missalignment,
>> that free hole should be (2048-63)=3D1985
>=20
> Yes, we should be aligning at a 1M or 2M boundary on the
> root device, not within the partition. The offsets are supposed
> to do that, and if there's a problem we should fix it.
> =20
>> AHhhhh thought hits me... did the code get changed
>> to make the images larger, and somehow the image
>> creation code went from a 32 sector/track fake C/H/S
>> to a 63 sector fake C/H/S, and the code has all
>> along been assuming 32 sector/track drives?
>>=20
> 63 sector for 'fake' C/H/S has been a thing since at least
> FreeBSD 6 and maybe a little longer. There's no cutover
> based on image size of the device. The older ATA code,
> pre-cam but post SOS rewrite, would try very hard to return
> the values from the underlying device that it reported. And that
> would lead to mismatches because it was different than the lies
> that md told by default. But that only mattered for really old
> BIOSes that couldn't handle LBA/packet mode in booting (which
> is the primary reason the old fdisk program could set the ending CHS
> of partitions since the FreeBSD code used that to guess the CHS
> of the drive itself in the absence of other information).
>=20
> I don't think the kernel has changed in this area in a very long time.
> At worse, we're seeing a mkimage bug.
>=20
> Warner
> =20
> >=20
> > MBR vs. GPT is not the fundamental issue for that.
> >=20
> > =3D=3D=3D
> > Mark Millard
> > marklmi at yahoo.com
> >=20
> >=20
> >=20
> >=20
>>=20
>> --=20
>> Rod Grimes                                                 =
rgrimes@freebsd.org
>>=20
>=20

For reference:

# grep -r MD_ARGS /usr/main-src/release/ | more
/usr/main-src/release/arm/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm/RPI-B.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/PINE64.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/ROCK64.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/arm64/RPI.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
/usr/main-src/release/release.sh:               mdconfig -f =
${IMGBASE##${CHROOTDIR}} ${MD_ARGS})

where:

     -x sectors/track
             See the description of the -y option below.

     -y heads/cylinder
             For malloc or vnode backed devices, the -x and -y options =
can be
             used to specify a synthetic geometry.  This is useful for
             constructing bootable images for later download to other =
devices.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jul 11 20:03:42 2022
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 8512617F9DCB
	for ; Mon, 11 Jul 2022 20:03:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4LhZZs23F9z3ldk
	for ; Mon, 11 Jul 2022 20:03:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657569827; bh=zUX3mCcWYCdv9OdpciKLHHaI/4gjFOuLqVINfB7kMdY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tRS0FOWuvu7gUM/DpwkOtlGpJ9uvRKtiVEBxiyJTcRuRh4T2cEPaEf1Gf7v5ciPrrIAgZIkW9VwR6DkABXh4SzDPF8YPNqjZlbA8lhwMVsQhBXgaULDlpw6i4P3KjR5cHvJZt/jF5WXGbOe33wUnTeMjIwh784uKvxXKXCDRZ2DUM/hGkcGS1mUPfo4XRAUZPTej6g8nMAxIHWNxBwiHro3YFGg/pnIaBMfkCcBEc3C2OvTpyiPwWvAKlfn+J13UiApB3c5f9OehJ00XVaaL5HCCWE4SDJ5H+5Jrc3iUG/6XcpEfE1FvlFyn1vcv27CIFr18q94Q7A3hhv58JjGzSg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657569827; bh=r716ZfLJ4+JpIeFgKIt6oi5UQ97F2Qr3COOe0FK09/f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ojhgQyn3EpsYX6Nl5AJ01XkIPZyY+jX716hxznwD7b385zqPKaKAuYhg8yQ8wYiyW+UNrosTuc3MdFNlF5eYU5du8+5HUjSDZaaiKEadblOVr/IHwvnivhwX/wCSU4+ZcktQHDCQP5x30zqWEqW6tGVtfY9KUEp8DWNVPmhzQHgOXCi9wJdPXfWXGWOO68wRyEwZw9b5vXQTGGYu7+1Sd4d223BOUEEf2qrZ/iKJ32mfFiBY0jAJt9N6oLTxCAw0h0XDdDqeTCymJyhs8eLX+rbH5OtYVnVCNMSFFanrwkyWKXGXi6jflITNQYSqwPweYx0OAz9/jzXT8OIW4HSyyw==
X-YMail-OSG: fRz6s6cVM1mU6CJTDpGmIN73wv48fZ5aq9GEroh1HXLwyKeCFjPacCzgblCxmeE
 UBCfANIzhomHyrYU2qHQ4Tg05N1IPjp1DhvepDjMdVWJjPVXHXCujbBtTt35HUw6XtRdzUnlRXLs
 ujsYKC.oYJz8JPUOSxDV7UrMyuY0026IXtm40.q2MogzntjBlVNXliCvtZwzPKhDevqX6.Alecnw
 fbLJEcauSsxchEDTkBKWFK7UX_O5aZNLjVVcrnPcYM4QR5XwBOA6y2qLPzFpA1oyLou90RFl6woW
 0GEeE8XydUV_avLT_OFqac9AkkFcoNY9MYe71XxfHCjnHb4AD_EyaBbBuDr9prfrC5bQ6VOl7gY3
 xmtTIeXYockGBgNW.3WirQiOsMQlhgSKLGnC6Z8mEvADQXT4s4pMnGuUigHoAkHEF7U7yHKtpY5p
 1CHCz_z8T2zSkSsZXsYYbZTBsCA56KO_s6SomV67wLdWyHyFL5L9dClp9gVdbeX1ByFeLAFdId2m
 mmps0lR3SG_POoPjGKl_tbUdleIb9EUXhtRtl8VIwVrm.r4vKjxanyRiuG8BGPqG6D04omlLBMYO
 6EuH0m3uLHYbNOWbQoNbgho0Xx4IkOg1n0V1QzS0IXinCX4xlRcpkiRn7WvM2j0dR3.7HcMak8Sc
 Lw6RAYk_JOuyaa3WUn8XnxB1Ugt3NfnzBN_j7odeHXizOCmjyhZDRnq5Tp1SrqdO4po6L84r3DgE
 1acEL21ilOKOdGsLi.2R.ONky4B0y7akMnjUqOlFw3rqwrdzgK1ChfeMoUVhtd6KOxWyAO2vEhTv
 lo3L.wYf9VAlXrHwXAYcLfDN6dR6GBs2x8dIYuBhNUdps8N.mb1M7VhNakU84.U0WdlCLC0kEYcH
 IZqDBJwi2uu8yGNg6HRsO2sKDd6karu_rbwOXOHxvhpzNqRM4jJTjMgnN_00sn7uPTmcLuy2Reh0
 1bcaEr05rKlEnD7cgb7.LAy0nJ4v1XlupKlwSPv8lhFseQC6nCaMB8zYQkQ.ONSTBgqNSee2fbVj
 mVapNYhevQfNvzo2gMgnmtPl2UNMtReD4A3nhVXMrRk0KhpPvD1euQiR.5FLMGaAO.jjWT4p0Tux
 JYP37tjmuZ9Gx9I03OzpS2uREcC_GzUrWuFzkJ8Ar3RllKPPXv5LGDDAMBBe1k_mpBWl390vVSML
 N3p_xYxuIy6RzH_i6stytbVAxtrNmmGmrpmWuQsK_H72q3qRANwgD8l03brpuBP37C8NXGUSNmtJ
 .OJgCKu.pjIUE0BkUpD.rnQXUcROfLciqYtWdvaMwjwYPJcvZyiGNjWtOX9UybKYND2wlLwgUr46
 jpGL1yuQYa2Jz9.ZMeVe_mM7rRCdkWdziT9e72K0SziUwVfYcAPgjrYYXluuQpxzdit_jVHkHhZk
 WBzLwU_UXChvaZcTp5zsOd7L__SVsGGOiCoz.nkaWnGWt6keBiSKvOMHlTuMKb.MpM1.5oMRNpns
 BfxMPNcWD3fry9m60f606NrNV7ZNV0bnAtJu5Ph.FAO2tW.HNJulrknCZXTva4jOJIEhOctMkdRK
 Su7T5yVoDYfNzz7fNx3plkeoD8IWIP3FnO3ieWajmtz031nvZ6aJURXm0.RMCq.dN4Mk3FVB.ufo
 haeEicmf4Qs9wAqBJ_UrQF8a6j_M63oAd5R0ULqYVu3Fyk7_FY1e0d2fesBShbNoWAm6yONkZfmk
 NMa7nTUREu6TX1M3CUUWEFKSRfZL9JYURSyzmduNoecPGslB64XY5nXWZRvrFklPGhyiwWG2S8OU
 hB316WsHxqcEQUJVazYPWuoiKGfZvalaBNxnmR2HGh1Uhv0GGWvudpVNXkxWu.w6PFzC3H5Jz37d
 VtzVutByCoLuWxY.KOQ0eZ7dcUch63FNVKDLNheHtg2KpphXBR.42KI0XmLCinjo87cACsrgAz6a
 EjnNOf42fN.vVb.9FgRj9Jh2XBRiTy3Nkewd9SGj0wNK4cRzGs6yLWXpaUFr4Py0988c0FyE7yVT
 U2w0XrCWvU2JoQ.hmdpnjXrBZDub9xa3JUx8V7ogoJZxHvwE7tiIECLmpApchQbaZwuVZOxuvOl7
 WesNe5lXFw9F6HpOW63rqtXXUDrwx9KaSfBhUqCVu8JZVRR8JhHnCIIQgd7DNdw__nq4o3bPNwO.
 4bVDHv.qO5JcQPF6bzw77Uq5uhIWMITAUJQpmC_yiv8oXHBS2zUM5gPHzD3ACD6Eu5iZWc24BsyA
 HZFYRukW5GO1zqCIq2IrMSFuFzuIjyf4BmJXKc72ePERla4mrYtOE0EiI.ajDOcuaNZpjDJuJ6Bx
 3l6nf
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 Jul 2022 20:03:47 +0000
Received: by hermes--production-gq1-56bb98dbc7-8vq2m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9094ecf1bc91f4cbceacd7f5ec328022;
          Mon, 11 Jul 2022 20:03:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
In-Reply-To: <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com>
Date: Mon, 11 Jul 2022 13:03:42 -0700
Cc: "Rodney W. Grimes" ,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <491AC0F5-2A0F-402D-A503-6A9E34F20E1D@yahoo.com>
References: <97AEE0AA-7EB1-44B6-9175-841425077974@yahoo.com>
 <202207111431.26BEVXCf037801@gndrsh.dnsmgr.net>
 
 <2B2004D4-268C-446B-86B8-15AD12C152C9@yahoo.com>
To: Warner Losh 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LhZZs23F9z3ldk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tRS0FOWu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.96)[-0.964];
	NEURAL_HAM_LONG(-0.91)[-0.910];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-11, at 09:50, Mark Millard  wrote:

> On 2022-Jul-11, at 07:38, Warner Losh  wrote:
>=20
>> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes =
 wrote:
>>>>=20
>>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen  =
wrote:
>>>>=20
>>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard :
>>>>>>=20
>>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen =
 wrote:
>>>>>>=20
>>>>>>> For example let's have a llok on the partition layout of, =
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
>>>>>>>=20
>>>>>>> # mdconfig -a -u 0 -t vnode -f =
diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>>>>>> # gpart show md0 md0s2
>>>>>>>=20
>>>>>>> =3D>     63  6291393  md0  MBR  (3.0G)
>>>>>>>       63     2016       - free -  (1.0M)
>>>>>>>     2079   102312    1  fat32lba  [active]  (50M)
>>>>>>>   104391  6187041    2  freebsd  (3.0G)
>>>>>>>  6291432       24       - free -  (12K)
>>>>>>>=20
>>>>>>> =3D>      0  6187041  md0s2  BSD  (3.0G)
>>>>>>>        0       57         - free -  (29K)
>>>>>>>       57  6186880      1  freebsd-ufs  (2.9G)
>>>>>>>  6186937      104         - free -  (52K)
>>>>>>>=20
>>>>>>> The start of the fat32 boot slice s1 (containing the u-boot) =
stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The =
start of the BSD payload slice s2 and its size are odd as well. The =
padding of 57 blocks within s2 lets the UFS partition start on a =
globally even base, namely 104391+57 =3D 104448, which as a matter of =
fact is 4k aligned (104448*512/4096 =3D 13056) and 1M aligned as well =
(104448*512/1024/1024 =3D 51), however all this keeps looking strange.
>>>>>>>=20
>>>>>>> Are there reasons for this partition layout besides making it =
look more interesting? If yes, some insights would be good.
>>>>>>=20
>>>>>> The layout details are more specific to the aarch64 RPi* context
>>>>>> than to general aarch64 SD card images. For example, the Rock64
>>>>>> image is different:
>>>>>>=20
>>>>>> # mdconfig -a -u 0 -t vnode -f  =
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
>>>>>> # gpart show md0
>>>>>> =3D>     40  6291376  md0  GPT  (3.0G)
>>>>>>     40    32728       - free -  (16M)
>>>>>>  32768   102400    1  efi  (50M)
>>>>>> 135168  6156160    2  freebsd-ufs  (2.9G)
>>>>>> 6291328       88       - free -  (44K)
>>>>>=20
>>>>> This is a GPT table, while the others are still MBR. Images which =
come with u-boot must have a different layout.
>>>>=20
>>>> I know it is a GPT table. That is part of the point about
>>>> the variety of contexts that there are across the Small
>>>> Board Computers.
>>>>=20
>>>> No SBC that has a U-Boot/whatever needing more space
>>>> than is provided below is going to use the same
>>>> 2079 figure:
>>>>=20
>>>> =3D>     63  ???  md0  ???  (?)
>>>>       63     2016       - free -  (1.0M)
>>>=20
>>> I read this thread.. and it keeps nagging me in
>>> the back of the head, I know this 2016 number.
>>> It is common when the sectors per track of a
>>> drive is reported as "32", its an attempt to
>>> 1M align such a drive, is somehow the image
>>> creation code picking up 32 to do the align
>>> calculation wrongly on a 63 sector/track
>>> image?
>>>=20
>>>>     2079   ??????    1  fat32lba  [active]  (?)
>>>=20
>>> The OP is correct, this is a horrid state of alignment
>>> and the cause should be tracked down and fixed!  I
>>> can see no valid reason to have an approx
>>> 1MB free hole that causes this missalignment,
>>> that free hole should be (2048-63)=3D1985
>>=20
>> Yes, we should be aligning at a 1M or 2M boundary on the
>> root device, not within the partition. The offsets are supposed
>> to do that, and if there's a problem we should fix it.
>>=20
>>> AHhhhh thought hits me... did the code get changed
>>> to make the images larger, and somehow the image
>>> creation code went from a 32 sector/track fake C/H/S
>>> to a 63 sector fake C/H/S, and the code has all
>>> along been assuming 32 sector/track drives?
>>>=20
>> 63 sector for 'fake' C/H/S has been a thing since at least
>> FreeBSD 6 and maybe a little longer. There's no cutover
>> based on image size of the device. The older ATA code,
>> pre-cam but post SOS rewrite, would try very hard to return
>> the values from the underlying device that it reported. And that
>> would lead to mismatches because it was different than the lies
>> that md told by default. But that only mattered for really old
>> BIOSes that couldn't handle LBA/packet mode in booting (which
>> is the primary reason the old fdisk program could set the ending CHS
>> of partitions since the FreeBSD code used that to guess the CHS
>> of the drive itself in the absence of other information).
>>=20
>> I don't think the kernel has changed in this area in a very long =
time.
>> At worse, we're seeing a mkimage bug.
>>=20
>> Warner
>>=20
>>>=20
>>> MBR vs. GPT is not the fundamental issue for that.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Rod Grimes                                                 =
rgrimes@freebsd.org
>>>=20
>>=20
>=20
> For reference:
>=20
> # grep -r MD_ARGS /usr/main-src/release/ | more
> /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm/RPI-B.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINE64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/arm64/RPI.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS=3D"-x 63 -y 255"
> /usr/main-src/release/release.sh:               mdconfig -f =
${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
>=20
> where:
>=20
>     -x sectors/track
>             See the description of the -y option below.
>=20
>     -y heads/cylinder
>             For malloc or vnode backed devices, the -x and -y options =
can be
>             used to specify a synthetic geometry.  This is useful for
>             constructing bootable images for later download to other =
devices.

I'm failing to reproduce the problem when I
try my own commands on:

# uname -apKU # manual line split
FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1301505 1301505

I tried what it looks to me the /usr/src/release/
code would do initially for arm64/RPI.conf (but with
my file naming and an explicit -u0 style of use):

# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63  6291393       - free -  (3.0G)
# gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63     1985       - free -  (993K)
     2048   102400    1  fat32lba  (50M)
   104448  6187008       - free -  (3.0G)

I tried the same sequence in a chroot into a 13.0-RELEASE-p11
tree on an aarch64 main [so: 14] machine. I got the same result.

But such is not what the 13.1-RELEASE build produced, for
example:

# mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  [active]  (50M)
   104391  6187041    2  freebsd  (3.0G)
  6291432       24       - free -  (12K)

(There are no 13.1-STABLE snapshots available to download
and look at.)

Looking at the recent 14.0-CURRENT snapshot:

# mdconfig -u0 =
-fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img =
-x63 -y255
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  [active]  (50M)
   104391  6187041    2  freebsd  (3.0G)
  6291432       24       - free -  (12K)

So, also not matching.

Is there something odd about the environment for official
snapshot/release builds that leads to getting a different
result? Possible lack of use of some of the modern
/usr/src/release/ material to build the images? Some issue
associated with amd64 -> aarch64 (or armv7 / armv6 / . . .)
cross builds?



I've always thought that it was too bad that the build logs
for release and snapshot builds were not publicly available.
Multiple times I've wished I could see what a build failure
or other oddity looked like in the snapshot build logs in
order to see if I could track down part of what was leading
to the failure(s)/oddities. (I may presume that there is more
log output than is actually set up?)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul 12 03:27:25 2022
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 53F551D234C6
	for ; Tue, 12 Jul 2022 03:27:37 +0000 (UTC)
	(envelope-from nick@i11.co)
Received: from mx.i11.co (mx.i11.co [159.69.78.69])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhmQw1GCYz3gyZ
	for ; Tue, 12 Jul 2022 03:27:36 +0000 (UTC)
	(envelope-from nick@i11.co)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i11.co;
	s=omicron; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:
	In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=3vntKMvTf1py/ILu+C1HVJ1vEsvpWgpM2EfYgdluDNM=; b=BRjog8XNkZWNpdnm4gRLR8iocn
	cDbPT+jgnEknwOT7T0CLALbf6DzxBU9vPPzT+kCsUBE9SsC4C8cPv5SFuaEgOj/cs55UV1XWqDNtM
	pvRpWi3jw5jrSlA4v8ZdqhqKaUya02k9Q0XAEyNnaIW2bcShdknB9vrVoN4gB1E1/BRn7E86amLvw
	gWBvHSTJyQSminSwuKftXctzQUtR/3Mrr0Z3Dlvw9J60DHNhDbVYqRQrvgjBSYDEV+gURLCFSLlXV
	8IBpqsbNbw+B/XvjCyBoWoBXmqwy8IKtKWRhASGD7G/twhF2DN2dO4ANeHyDoLcW+PaefYruv26VF
	eBH0ww/g==;
Received: from [212.237.25.26] (helo=thinkbook)
	by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1oB6Ya-0006sz-Ep; Tue, 12 Jul 2022 03:27:28 +0000
Date: Tue, 12 Jul 2022 06:27:25 +0300
From: Nick Kostyria 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm 
Subject: Re: path for overlays
Message-ID: <20220712032725.49684889@thinkbook>
In-Reply-To: 
References: 
	
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.3)
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: 4LhmQw1GCYz3gyZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i11.co header.s=omicron header.b=BRjog8XN;
	dmarc=pass (policy=reject) header.from=i11.co;
	spf=pass (mx1.freebsd.org: domain of nick@i11.co designates 159.69.78.69 as permitted sender) smtp.mailfrom=nick@i11.co
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)[-1.000];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[i11.co,reject];
	R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69];
	R_DKIM_ALLOW(-0.20)[i11.co:s=omicron];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[i11.co:+];
	FREEFALL_USER(0.00)[nick];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 11 Jul 2022 00:18:59 -0300
"Dr. Rolf Jansen"  wrote:


> 
> Anyway, for enabling I2C5 (we may choose from I2C3, I2C4, I2C5 and I2C6) on a Raspberry Pi 4, we do:
> 
> # fetch https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/i2c5-overlay.dts
> # dtc -I dts -O dtb -b0 -@ -o /boot/msdos/overlays/i2c5.dtbo i2c5-overlay.dts
> 
> Then we add the following 2 lines to /boot/msdos/config.txt:
> 
>   gpio=12,13=a5
>   dtoverlay=i2c5,pins_12_13
> 

Hello.

I see you use /boot/msdos/overlays/ for overlays.
I have a question for a long time and I can't find an answer.

What is the difference between /boot/msdos/overlays/ and /boot/dtb/overlays/ (fdt_overlays in /boot/loader.conf).

What is more correct?
What should be used?

/boot/msdos/overlays/ or /boot/dtb/overlays/
/boot/msdos/config.txt or /boot/loader.conf

Thanks.

From nobody Tue Jul 12 05:16:44 2022
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 581E117FAE39
	for ; Tue, 12 Jul 2022 05:16:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4Lhprw0DYsz3sTZ
	for ; Tue, 12 Jul 2022 05:16:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657603006; bh=DJcV/XnsvCYbI1z5caxNI95w7KaYQH7zpEHTni5UHns=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=py0iWxcxl+KoJWrSG8hsxsGR+9kCt8GIhdsjiD1CWDXtz9U98c4mOTZdo+qJWdlbSmgRhdqFp4+7Z0xkl52QFswmkG3AQYMxZPIOD7STHr0RGS0ol6Jctxd4pjj2faFs5ZJ98+gvnIdlJe+j7/HUZebTtgt5wwxcJCp6qwK+Jfj27iDcxEZItL40Im78/ubzHFzeBRXQN9nmGLDsVaYCoOoXH5saEcQNO8KxWR+wetHIkGD1ES9zR73hogHfc2VOuIaPApPKYRd6bzCjRxool2nzv7lAnU5ugEHCOgKSrbrKZoHnflFWy8VyO362yboBtIKebbDFI0Z5iiV+63JRHA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657603006; bh=AFS9nIdlnHbtprXrxPM4qGpBfMYcofSzwavgSgQAsOV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hf67/IXNKqwAymBcPI7W22ncuxIYwQPczKwdoBcyc3kQFlAyUOTpxmbUTdEwdrauVuytBSKUhABfxfLbEEFRMHLPLi7eBD2z5hwf1cPkZd1e1gZdKwCRW4WgUIR31Xt2MNyPLJOT1IALX2hYaCCJ1PA9jnSKkJh86xV0PLuKrUGT6nJFpssdAyWkeMAVr1J9OtFiXsfajfvgar8+XRlKe2UiQyApxmKyyQq8gMdbhYXigfVrprS8iv31VjR4RDxmExOyF1Ff3Jv130aLCqc+JNvfzyn9WloDGCfNp53BRD/jIHpbulW/qndhATu230S85hO3KJ18oIQ5MSwckRgUQA==
X-YMail-OSG: bY51QGoVM1myUaVB8FpQ9qnAq1MbFkwBZJjOIX5kNz1ZlrImVFqoFb7w311qeTe
 jS7SBoUNV_gXinLcNGRYN3wY9qMKp63NGiu9l70SS.u8GyEf6aMNhDiXVnW8dvEyXWk0Dl4wW7Q9
 g48vQ15wxsKjhUltg_b9WpG8siVngXDPj8mg_XG9grdLQxYyp7ONyNK3zm7_tcSuRcbbdkuDby4E
 3TlWAmy20MCTd2999ztVOG5a2W3SFJjyne9JGM.9PZebtWa8Ry.UCnn0nmEleBvrXWCqAmmhVret
 fmnMdCkWVYpYzzIpGP.epzQIIhlpQaelJbArqY_StyRwd.RMGm7R8_VX9HUmFkspcqTrn75jhW.Z
 vJErf5puUtlEnS09tmlhtXQM2bEmuuvItJgf1M5.zG.Qzs_.9kVIz6T7Uuiyu5nEg5EFnjcadPA6
 pyR2iCmKHpYbcFtoPS.gteW2M1uLzDBD0JqD8GaTVBHvHqF5RCVOG2_7Z_rHyvHQXE91W3nLzrIA
 sTTYwqsm5K9grPvaBiv6rCVCheG_k3TgX3vVmbGM3JVpqqFqunMV9gGqSdiURjYl9i5HO4w2XfGG
 MXCAnoy9yhiIkyxM9Yx7Tw8ybhIBI3jvwZuQDFcR6drLF95pzLShXOVoemB0pjjCT_Avfrd7oFM5
 YMrxbqW3fObZx8Lo9wndovlLl2vFsFpSlHYkffr_2KPLK_5WuPidnudAPbDwZb4KCqbyBToYuJQo
 lXaN1txd6JZ27v8DjP2MY1wsWKEfZASzfcVFkJZO2NytNjd9dPvalPgZIwvt_mHMR9H6SPUjcVPG
 TkubQOGwBOOVhYgcoHQmZZjOHnGCOkq6jh5r1kanxYDzEWAvqB._jxj4xCM0ngZ1KuelG9Y2fdUU
 5C44dI3szv7qVm46amonzggJplj1oRl0ITOUBO7IIE_m4oyXyY.lM0.DyVZ9_8YpHDA4OwQ8rfTA
 7jC6M_rzS7rqFbLg9sVYq_gg4ONyb.kY7ZjQ_6sjGog._pXXCu.9iLaGIFkkchKJMpdpasI1elDB
 EMIgqamgx8S1dtfDXBJnwFSDNMG2DknSdg5g_AIj6TArQR1BbwpP_OLtiq_rZrSfu9JS5eYPfjQD
 9l.lBtSLa_KxcfXbA2ux1byW_XeeIOV80hTGAUUtHGxUW_0bA7VPZ.97Zs5EOUzJQ3wfpQAw6rV_
 Ym18dgFIYLe1GlthbDqsHxxc7bj6_eAA9lHFSyVc_U5nJO1gnRh4jmBfPqqo4To6wdXEXAoeO_1y
 _LckAsxXHd2MKC97O0a0Cbmcx1yre1IoLPnxhIHfhCKMYiOZc4IDts4gS7A3Si4TacoUYyPrpWF8
 RdkyYbeSj6C8SAJ.JRBmo2YQC1MSi5mi1MDExq6MX.AZJBvhHVswhUouyRVUh199JAn65zB6dtB9
 ak4o4zIjT3o3yMNGlyvpsu8oVEY8LacrWaYm6Et.B1w6JWSaXSlPSzje18P6PjCpeBfNrdCZYWcM
 TJzVdzXLYbYEr2eSZ53eHh4VYk14EiNdzYiwd0MdXGmEvZ8wlfsyNh1ojruKVr7G4nrqUX2d0W7R
 FOH2qyLfw21DwwSvMAv5pdZ.WNrcWtayrFkDPxEfsmERIMHHspmz7sumc9BUcREscDo9NpljYdal
 9oNgX1y5Wk_.DZaTq6GwBOa8bgcqJlfJh4Z_iK4xuvaddx2nAU_tN4l3g0U3Ox1XZzZX_7Si0VQQ
 ldPWbBvTDtAa40GKlP7pnGypugtr1TIG4PsJPvFv7mIxQOvKeC9Pn1s4yxIvTEpFTfwjsXJJsVaJ
 SRSnXp_D9QH3Hm22z3XekphcIAl0O74l3rGxWKLyGLAtaj3p6kaqeIn99diN_7ichdahgghxSQ8G
 5lcJ9RPfh3KpPnZcriakM1uXciC.bd0O8cYc.RFUGkr0pmNF07FleRYpyjgcpDTEwT19hOkwbCvN
 1lFKfhfWKasMkSVL6nlQk9Hk7tn7Qll0FIy2vD3Ex8NpoWkRLretRfsuNacz5G082PPzVoNv_K_q
 otR9bUw16.11kdc3.sXHKlch1TumAZzqvKZH4VFx8TxEqi6vBUP.UiUWVZj04MEZKyrAEO7cjqe5
 mvRZYJdY8O2E20xmX5geWI8Qp24m7isRh2lk4RnnvtOhAdG.M9B7LA7KLcDGYDzh9CkFuJ8NiaFm
 kXypT46BIUQXEPcy2al.YZaOsHIfiB709XdsUp79Jwfq9fMrYhGE0ZbCYknA1Z_7EvAr1ewPOz70
 EpHDjzPAaHf8IXjnv92kY6u97zNRZk3sGrtAlZJKuOWuorShWIgX7SS0Iudj0LBz6F0Gl3n8yIKo
 kiA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Jul 2022 05:16:46 +0000
Received: by hermes--production-gq1-56bb98dbc7-b6h6x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43538254ff072f2eb55fb66c09abfec9;
          Tue, 12 Jul 2022 05:16:44 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: path for overlays
Message-Id: 
Date: Mon, 11 Jul 2022 22:16:44 -0700
Cc: freebsd-arm 
To: nick@i11.co
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4Lhprw0DYsz3sTZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=py0iWxcx;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.87)[-0.873];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]
X-ThisMailContainsUnwantedMimeParts: N

Nick Kostyria  wrote on
Date: Tue, 12 Jul 2022 03:27:25 UTC :

> On Mon, 11 Jul 2022 00:18:59 -0300
> "Dr. Rolf Jansen"  wrote:
>=20
>=20
> >=20
> > Anyway, for enabling I2C5 (we may choose from I2C3, I2C4, I2C5 and =
I2C6) on a Raspberry Pi 4, we do:
> >=20
> > # fetch =
https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/ove=
rlays/i2c5-overlay.dts
> > # dtc -I dts -O dtb -b0 -@ -o /boot/msdos/overlays/i2c5.dtbo =
i2c5-overlay.dts
> >=20
> > Then we add the following 2 lines to /boot/msdos/config.txt:
> >=20
> >   gpio=3D12,13=3Da5
> >   dtoverlay=3Di2c5,pins_12_13
> >=20
>=20
> Hello.
>=20
> I see you use /boot/msdos/overlays/ for overlays.
> I have a question for a long time and I can't find an answer.
>=20
> What is the difference between /boot/msdos/overlays/ and =
/boot/dtb/overlays/ (fdt_overlays in /boot/loader.conf).

[I've written these notes to presume a RPi* context based on
U-Boot, not EDK2 UEFI/ACPI or the like, and  not for other
platforms.]

Some of this is just convention, and these notes are from memory,
but:

A) If the partitioning is MBR, /boot/msdos is a mount point where
   the msdosfs is mounted by FreeBSD. The RPi* firmware has access
   to the msdosfs (MS-DOS  file system). The FreeBSD loader gets a
   copy in the msdosfs (that is started by U-Boot, which in turn is
   started by the RPi* firmware) but the rest of FreeBSD does not
   go in the msdosfs.

B) If the partitioning is GPT /boot/efi is a mount point where
   the msdosfs is mounted by FreeBSD. The RPi* firmware has access
   to the msdosfs (MS-DOS  file system). The FreeBSD loader gets a
   copy in the msdosfs (that is started by U-Boot, which in turn is
   started by the RPi* firmware) but the rest of FreeBSD does not
   go in the msdosfs.

C) /boot/dtb is not used as such a mount point. It is part of the
   UFS (or ZFS) file system. The RPi* firmware and U-Boot do not
   have access into the UFS or ZFS file systems. This is a reason
   why a copy of an appropriate FreeBSD loader is put on the
   msdosfs. The FreeBSD loader, in turn, can access UFS or ZFS.

(A)/(B) are used for the dtb files so that the RPi* firmware loads
and sets up the dtb material to be in the DeviceTree, well before
FreeBSD is involved. The RPi* firmware and U-Boot hand over a
version of that DeviceTree to the FreeBSD loader and, from there
the FreeBSD kernel sees it.

(C) would be for only the FreeBSD kernel seeing/using the dtb.

FreeBSD does not have full control of the RPi* and some types
of overlays have to be processed by the RPi* firmware, if I
understand right. For RPi*'s /boot/dtb/ use is likely rare.

Do not presume all the content of these notes apply to other
types of FreeBSD platforms.

> What is more correct?
> What should be used?
>=20
> /boot/msdos/overlays/ or /boot/dtb/overlays/
> /boot/msdos/config.txt or /boot/loader.conf

config.txt is for the RPi* firmware use, not FreeBSD's
direct use. loader.conf is for FreeBSD's direct use, not RPi*
firmware use (nor U-Boot). Nothing says that the notations
used in the two files would be compatible. Moving text correct
for one file to the other (but unchanged) is not likely to
work.

In this case, the config.txt text "dtoverlay=3Di2c5" is tied to
the file placement (as seen via FreeBSD's /boot/msdos mount
point):

/boot/msdos/overlays/i2c5.dtbo

and "pins_12_13" is a configuration parameter of some sort.
The "gpio=3D12,13=3Da5" is also defined for and handled by the
RPi* firmware, not directly by FreeBSD.

The lack of a /boot/msdosfs/ prefix (or, possibly, /boot/efi/
prefix) is a clue that loader.conf is just for FreeBSD's use.


I'll note that the RPi* firmware accesses the msdosfs long
before FreeBSD starts. The FreeBSD mount point use (for
access to the msdosfs from FreeBSD) happens later.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jul 12 08:05:21 2022
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 9DF1C17FC32D
	for ; Tue, 12 Jul 2022 08:05:29 +0000 (UTC)
	(envelope-from SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LhtbX3LLdz3Gnc
	for ; Tue, 12 Jul 2022 08:05:28 +0000 (UTC)
	(envelope-from SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 12 Jul 2022 10:05:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1657613121;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=IVoL1hcvMHg+nAV8iS5QGaqbe4mvR2oddwSUWbLM34Y=;
	b=bR/N7cTSq5AK96wkwABUgj5m6AVoPzwBwHabFJj6YA2jaeGrY60TxDzckTBhZ0xamAdgGx
	9kiscJxBJ5jSpg7yS4BYWOJpmsYJw6A9sIhffsVmz5AK1O9BanRsf3+/ZOFoHDWUIddxMY
	pENDqXQCrPsRxljKQ5s0q1mPjHsWRCFsN2SP8M30szIzL2FiFo2affXynpwUE72qhIJXAt
	S45ALAZ64W5Q5+PvArDUFMKkgcgUg6ookpc6CxYXDqX51nmOG8olwFmrK/EFz5ma7wES/3
	HIs7DL3JfqZZQl1NxWJ2UtdMVHclhSsmj3ZLCwo+HuXCs92pHeVXXb0QRT+Yng==
From: Ronald Klop 
To: Mark Millard , Warner Losh ,
	"Rodney W. Grimes" ,
	"Dr. Rolf Jansen" ,
	freebsd-arm 
Message-ID: <1169617916.2919.1657613121111@localhost>
In-Reply-To: <491AC0F5-2A0F-402D-A503-6A9E34F20E1D@yahoo.com>
Subject: Re: Partition layout of ARM SD card images
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="----=_Part_2918_2130341816.1657613121106"
X-Mailer: Realworks (614.98.9856e01)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LhtbX3LLdz3Gnc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b="bR/N7cTS";
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FREEMAIL_TO(0.00)[yahoo.com,bsdimp.com,gndrsh.dnsmgr.net,cyclaero.com,freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[5];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=XciD=XR=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_2918_2130341816.1657613121106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Van: Mark Millard 
Datum: 11 juli 2022 22:04
Aan: Warner Losh 
CC: "Rodney W. Grimes" , "Dr. Rolf Jansen" , freebsd-arm 
Onderwerp: Re: Partition layout of ARM SD card images

> 
> 
> On 2022-Jul-11, at 09:50, Mark Millard  wrote:
> 
> > On 2022-Jul-11, at 07:38, Warner Losh  wrote:
> > 
> >> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes  wrote:
> >>>> 
> >>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen  wrote:
> >>>> 
> >>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard :
> >>>>>> 
> >>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen  wrote:
> >>>>>> 
> >>>>>>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):
> >>>>>>> 
> >>>>>>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
> >>>>>>> # gpart show md0 md0s2
> >>>>>>> 
> >>>>>>> =>     63  6291393  md0  MBR  (3.0G)
> >>>>>>>       63     2016       - free -  (1.0M)
> >>>>>>>     2079   102312    1  fat32lba  [active]  (50M)
> >>>>>>>   104391  6187041    2  freebsd  (3.0G)
> >>>>>>>  6291432       24       - free -  (12K)
> >>>>>>> 
> >>>>>>> =>      0  6187041  md0s2  BSD  (3.0G)
> >>>>>>>        0       57         - free -  (29K)
> >>>>>>>       57  6186880      1  freebsd-ufs  (2.9G)
> >>>>>>>  6186937      104         - free -  (52K)
> >>>>>>> 
> >>>>>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.
> >>>>>>> 
> >>>>>>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.
> >>>>>> 
> >>>>>> The layout details are more specific to the aarch64 RPi* context
> >>>>>> than to general aarch64 SD card images. For example, the Rock64
> >>>>>> image is different:
> >>>>>> 
> >>>>>> # mdconfig -a -u 0 -t vnode -f  FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img
> >>>>>> # gpart show md0
> >>>>>> =>     40  6291376  md0  GPT  (3.0G)
> >>>>>>     40    32728       - free -  (16M)
> >>>>>>  32768   102400    1  efi  (50M)
> >>>>>> 135168  6156160    2  freebsd-ufs  (2.9G)
> >>>>>> 6291328       88       - free -  (44K)
> >>>>> 
> >>>>> This is a GPT table, while the others are still MBR. Images which come with u-boot must have a different layout.
> >>>> 
> >>>> I know it is a GPT table. That is part of the point about
> >>>> the variety of contexts that there are across the Small
> >>>> Board Computers.
> >>>> 
> >>>> No SBC that has a U-Boot/whatever needing more space
> >>>> than is provided below is going to use the same
> >>>> 2079 figure:
> >>>> 
> >>>> =>     63  ???  md0  ???  (?)
> >>>>       63     2016       - free -  (1.0M)
> >>> 
> >>> I read this thread.. and it keeps nagging me in
> >>> the back of the head, I know this 2016 number.
> >>> It is common when the sectors per track of a
> >>> drive is reported as "32", its an attempt to
> >>> 1M align such a drive, is somehow the image
> >>> creation code picking up 32 to do the align
> >>> calculation wrongly on a 63 sector/track
> >>> image?
> >>> 
> >>>>     2079   ??????    1  fat32lba  [active]  (?)
> >>> 
> >>> The OP is correct, this is a horrid state of alignment
> >>> and the cause should be tracked down and fixed!  I
> >>> can see no valid reason to have an approx
> >>> 1MB free hole that causes this missalignment,
> >>> that free hole should be (2048-63)=1985
> >> 
> >> Yes, we should be aligning at a 1M or 2M boundary on the
> >> root device, not within the partition. The offsets are supposed
> >> to do that, and if there's a problem we should fix it.
> >> 
> >>> AHhhhh thought hits me... did the code get changed
> >>> to make the images larger, and somehow the image
> >>> creation code went from a 32 sector/track fake C/H/S
> >>> to a 63 sector fake C/H/S, and the code has all
> >>> along been assuming 32 sector/track drives?
> >>> 
> >> 63 sector for 'fake' C/H/S has been a thing since at least
> >> FreeBSD 6 and maybe a little longer. There's no cutover
> >> based on image size of the device. The older ATA code,
> >> pre-cam but post SOS rewrite, would try very hard to return
> >> the values from the underlying device that it reported. And that
> >> would lead to mismatches because it was different than the lies
> >> that md told by default. But that only mattered for really old
> >> BIOSes that couldn't handle LBA/packet mode in booting (which
> >> is the primary reason the old fdisk program could set the ending CHS
> >> of partitions since the FreeBSD code used that to guess the CHS
> >> of the drive itself in the absence of other information).
> >> 
> >> I don't think the kernel has changed in this area in a very long time.
> >> At worse, we're seeing a mkimage bug.
> >> 
> >> Warner
> >> 
> >>> 
> >>> MBR vs. GPT is not the fundamental issue for that.
> >>> 
> >>> ===
> >>> Mark Millard
> >>> marklmi at yahoo.com
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Rod Grimes                                                 rgrimes@freebsd.org
> >>> 
> >> 
> > 
> > For reference:
> > 
> > # grep -r MD_ARGS /usr/main-src/release/ | more
> > /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm/RPI-B.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/PINE64.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/arm64/RPI.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS="-x 63 -y 255"
> > /usr/main-src/release/release.sh:               mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS})
> > 
> > where:
> > 
> >     -x sectors/track
> >             See the description of the -y option below.
> > 
> >     -y heads/cylinder
> >             For malloc or vnode backed devices, the -x and -y options can be
> >             used to specify a synthetic geometry.  This is useful for
> >             constructing bootable images for later download to other devices.
> 
> I'm failing to reproduce the problem when I
> try my own commands on:
> 
> # uname -apKU # manual line split
> FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
> stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
> arm64 aarch64 1301505 1301505
> 
> I tried what it looks to me the /usr/src/release/
> code would do initially for arm64/RPI.conf (but with
> my file naming and an explicit -u0 style of use):
> 
> # truncate -s3072m mmjnk.test
> # mdconfig -u0 -fmmjnk.test -x63 -y255
> # gpart create -sMBR md0
> md0 created
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63  6291393       - free -  (3.0G)
> # gpart add -t'!12' -a512k -s50m -b1m md0
> md0s1 added
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63     1985       - free -  (993K)
>      2048   102400    1  fat32lba  (50M)
>    104448  6187008       - free -  (3.0G)
> 
> I tried the same sequence in a chroot into a 13.0-RELEASE-p11
> tree on an aarch64 main [so: 14] machine. I got the same result.
> 
> But such is not what the 13.1-RELEASE build produced, for
> example:
> 
> # mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63     2016       - free -  (1.0M)
>      2079   102312    1  fat32lba  [active]  (50M)
>    104391  6187041    2  freebsd  (3.0G)
>   6291432       24       - free -  (12K)
> 
> (There are no 13.1-STABLE snapshots available to download
> and look at.)
> 
> Looking at the recent 14.0-CURRENT snapshot:
> 
> # mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img -x63 -y255
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63     2016       - free -  (1.0M)
>      2079   102312    1  fat32lba  [active]  (50M)
>    104391  6187041    2  freebsd  (3.0G)
>   6291432       24       - free -  (12K)
> 
> So, also not matching.
> 
> Is there something odd about the environment for official
> snapshot/release builds that leads to getting a different
> result? Possible lack of use of some of the modern
> /usr/src/release/ material to build the images? Some issue
> associated with amd64 -> aarch64 (or armv7 / armv6 / . . .)
> cross builds?
> 
> 
> 
> I've always thought that it was too bad that the build logs
> for release and snapshot builds were not publicly available.
> Multiple times I've wished I could see what a build failure
> or other oddity looked like in the snapshot build logs in
> order to see if I could track down part of what was leading
> to the failure(s)/oddities. (I may presume that there is more
> log output than is actually set up?)
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
> 
> 
> 
> 


It seems the image builder of aarch64 13-stable is disabled. 
https://ci.freebsd.org/job/FreeBSD-stable-13-aarch64-images/
Other architectures are enabled. 


Regards,
Ronald

------=_Part_2918_2130341816.1657613121106
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Van: Mark Millard <marklmi@yahoo.com>
Datum: 11 juli 2022 22:04
Aan: Warner Losh <imp@bsdimp.com>
CC: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "Dr. Rolf Jansen" <freebsd-rj@cyclaero.com>, freebsd-arm <freebsd-arm@freebsd.org>
Onderwerp: Re: Partition layout of ARM SD card images


On 2022-Jul-11, at 09:50, Mark Millard <marklmi@yahoo.com> wrote:



> On 2022-Jul-11, at 07:38, Warner Losh <imp@bsdimp.com> wrote:

> 

>> On Mon, Jul 11, 2022 at 8:31 AM Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote:

>>>> 

>>>> On 2022-Jul-10, at 14:34, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:

>>>> 

>>>>>> Am 10.07.2022 um 17:48 schrieb Mark Millard <marklmi@yahoo.com>:

>>>>>> 

>>>>>> On 2022-Jul-10, at 12:26, Dr. Rolf Jansen <freebsd-rj@cyclaero.com> wrote:

>>>>>> 

>>>>>>> For example let's have a llok on the partition layout of, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img (the others are similar):

>>>>>>> 

>>>>>>> # mdconfig -a -u 0 -t vnode -f diskimg/FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img

>>>>>>> # gpart show md0 md0s2

>>>>>>> 

>>>>>>> =>     63  6291393  md0  MBR  (3.0G)

>>>>>>>       63     2016       - free -  (1.0M)

>>>>>>>     2079   102312    1  fat32lba  [active]  (50M)

>>>>>>>   104391  6187041    2  freebsd  (3.0G)

>>>>>>>  6291432       24       - free -  (12K)

>>>>>>> 

>>>>>>> =>      0  6187041  md0s2  BSD  (3.0G)

>>>>>>>        0       57         - free -  (29K)

>>>>>>>       57  6186880      1  freebsd-ufs  (2.9G)

>>>>>>>  6186937      104         - free -  (52K)

>>>>>>> 

>>>>>>> The start of the fat32 boot slice s1 (containing the u-boot) stuff is neither aligned to 1M nor to 4k, it starts on an odd base. The start of the BSD payload slice s2 and its size are odd as well. The padding of 57 blocks within s2 lets the UFS partition start on a globally even base, namely 104391+57 = 104448, which as a matter of fact is 4k aligned (104448*512/4096 = 13056) and 1M aligned as well (104448*512/1024/1024 = 51), however all this keeps looking strange.

>>>>>>> 

>>>>>>> Are there reasons for this partition layout besides making it look more interesting? If yes, some insights would be good.

>>>>>> 

>>>>>> The layout details are more specific to the aarch64 RPi* context

>>>>>> than to general aarch64 SD card images. For example, the Rock64

>>>>>> image is different:

>>>>>> 

>>>>>> # mdconfig -a -u 0 -t vnode -f  FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20220708-a0b956f5ac5-256605.img

>>>>>> # gpart show md0

>>>>>> =>     40  6291376  md0  GPT  (3.0G)

>>>>>>     40    32728       - free -  (16M)

>>>>>>  32768   102400    1  efi  (50M)

>>>>>> 135168  6156160    2  freebsd-ufs  (2.9G)

>>>>>> 6291328       88       - free -  (44K)

>>>>> 

>>>>> This is a GPT table, while the others are still MBR. Images which come with u-boot must have a different layout.

>>>> 

>>>> I know it is a GPT table. That is part of the point about

>>>> the variety of contexts that there are across the Small

>>>> Board Computers.

>>>> 

>>>> No SBC that has a U-Boot/whatever needing more space

>>>> than is provided below is going to use the same

>>>> 2079 figure:

>>>> 

>>>> =>     63  ???  md0  ???  (?)

>>>>       63     2016       - free -  (1.0M)

>>> 

>>> I read this thread.. and it keeps nagging me in

>>> the back of the head, I know this 2016 number.

>>> It is common when the sectors per track of a

>>> drive is reported as "32", its an attempt to

>>> 1M align such a drive, is somehow the image

>>> creation code picking up 32 to do the align

>>> calculation wrongly on a 63 sector/track

>>> image?

>>> 

>>>>     2079   ??????    1  fat32lba  [active]  (?)

>>> 

>>> The OP is correct, this is a horrid state of alignment

>>> and the cause should be tracked down and fixed!  I

>>> can see no valid reason to have an approx

>>> 1MB free hole that causes this missalignment,

>>> that free hole should be (2048-63)=1985

>> 

>> Yes, we should be aligning at a 1M or 2M boundary on the

>> root device, not within the partition. The offsets are supposed

>> to do that, and if there's a problem we should fix it.

>> 

>>> AHhhhh thought hits me... did the code get changed

>>> to make the images larger, and somehow the image

>>> creation code went from a 32 sector/track fake C/H/S

>>> to a 63 sector fake C/H/S, and the code has all

>>> along been assuming 32 sector/track drives?

>>> 

>> 63 sector for 'fake' C/H/S has been a thing since at least

>> FreeBSD 6 and maybe a little longer. There's no cutover

>> based on image size of the device. The older ATA code,

>> pre-cam but post SOS rewrite, would try very hard to return

>> the values from the underlying device that it reported. And that

>> would lead to mismatches because it was different than the lies

>> that md told by default. But that only mattered for really old

>> BIOSes that couldn't handle LBA/packet mode in booting (which

>> is the primary reason the old fdisk program could set the ending CHS

>> of partitions since the FreeBSD code used that to guess the CHS

>> of the drive itself in the absence of other information).

>> 

>> I don't think the kernel has changed in this area in a very long time.

>> At worse, we're seeing a mkimage bug.

>> 

>> Warner

>> 

>>> 

>>> MBR vs. GPT is not the fundamental issue for that.

>>> 

>>> ===

>>> Mark Millard

>>> marklmi at yahoo.com

>>> 

>>> 

>>> 

>>> 

>>> 

>>> -- 

>>> Rod Grimes                                                 rgrimes@freebsd.org

>>> 

>> 

> 

> For reference:

> 

> # grep -r MD_ARGS /usr/main-src/release/ | more

> /usr/main-src/release/arm/GENERICSD.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm/RPI-B.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/PINE64-LTS.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/PINE64.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/PINEBOOK.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/ROCK64.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/ROCKPRO64.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/arm64/RPI.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/riscv/GENERICSD.conf:MD_ARGS="-x 63 -y 255"

> /usr/main-src/release/release.sh:               mdconfig -f ${IMGBASE##${CHROOTDIR}} ${MD_ARGS})

> 

> where:

> 

>     -x sectors/track

>             See the description of the -y option below.

> 

>     -y heads/cylinder

>             For malloc or vnode backed devices, the -x and -y options can be

>             used to specify a synthetic geometry.  This is useful for

>             constructing bootable images for later download to other devices.



I'm failing to reproduce the problem when I

try my own commands on:



# uname -apKU # manual line split

FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40

stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022

root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72

arm64 aarch64 1301505 1301505



I tried what it looks to me the /usr/src/release/

code would do initially for arm64/RPI.conf (but with

my file naming and an explicit -u0 style of use):



# truncate -s3072m mmjnk.test

# mdconfig -u0 -fmmjnk.test -x63 -y255

# gpart create -sMBR md0

md0 created

# gpart show md0

=>     63  6291393  md0  MBR  (3.0G)

       63  6291393       - free -  (3.0G)

# gpart add -t'!12' -a512k -s50m -b1m md0

md0s1 added

# gpart show md0

=>     63  6291393  md0  MBR  (3.0G)

       63     1985       - free -  (993K)

     2048   102400    1  fat32lba  (50M)

   104448  6187008       - free -  (3.0G)



I tried the same sequence in a chroot into a 13.0-RELEASE-p11

tree on an aarch64 main [so: 14] machine. I got the same result.



But such is not what the 13.1-RELEASE build produced, for

example:



# mdconfig -u0 -fFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img -x63 -y255

# gpart show md0

=>     63  6291393  md0  MBR  (3.0G)

       63     2016       - free -  (1.0M)

     2079   102312    1  fat32lba  [active]  (50M)

   104391  6187041    2  freebsd  (3.0G)

  6291432       24       - free -  (12K)



(There are no 13.1-STABLE snapshots available to download

and look at.)



Looking at the recent 14.0-CURRENT snapshot:



# mdconfig -u0 -fFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220708-a0b956f5ac5-256605.img -x63 -y255

# gpart show md0

=>     63  6291393  md0  MBR  (3.0G)

       63     2016       - free -  (1.0M)

     2079   102312    1  fat32lba  [active]  (50M)

   104391  6187041    2  freebsd  (3.0G)

  6291432       24       - free -  (12K)



So, also not matching.



Is there something odd about the environment for official

snapshot/release builds that leads to getting a different

result? Possible lack of use of some of the modern

/usr/src/release/ material to build the images? Some issue

associated with amd64 -> aarch64 (or armv7 / armv6 / . . .)

cross builds?







I've always thought that it was too bad that the build logs

for release and snapshot builds were not publicly available.

Multiple times I've wished I could see what a build failure

or other oddity looked like in the snapshot build logs in

order to see if I could track down part of what was leading

to the failure(s)/oddities. (I may presume that there is more

log output than is actually set up?)



===

Mark Millard

marklmi at yahoo.com














It seems the image builder of aarch64 13-stable is disabled. 
Other architectures are enabled. 

Regards,
Ronald


------=_Part_2918_2130341816.1657613121106--

From nobody Tue Jul 12 16:46:35 2022
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 BB3E417F8F15
	for ; Tue, 12 Jul 2022 16:46:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lj6911Drcz3TB5
	for ; Tue, 12 Jul 2022 16:46:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657644403; bh=JHIMKNz7cPbObjIfQEvXh46Qv5W5v2oQMEIrXDw1iGA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=byBVeMcX+qF2Y834Rsd4nXu6SSkxkGACrT2cRZ8AU2y+ama6118c8ILxai95DLmzPUsoY/2SQVwGSszM/p8xuMyMUSpnnUxeWQFkmW6WE88FEFLyC53THZSA9m6Uto8x61WXVv3lRpyJthd5+9V3UDt2orYUg64lhmm444uEWhISUu1WWdqEG6rnOxB4raMFZoj6e2YzRA+jjBINVs/MktkX4lT93AqB6i/p41lefVbIGbm/RrGwQo+Fq4mG/IJS3hAoeY0ahIReLwFKu5RbDIMNTl0FitqcIg33FiP/Uh9QyHCShuXNNjUTlI3frasYsR6eSmQ5ZP2WRFGLi3nMOQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657644403; bh=4rOLio6EOBm4rWI6a/c/+bN/O791vAIHR8ASrXfA1Pv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e6xh1p/qmyL86lnrnlRUsxedin+QEvdo/1VKVIewP5ViBke9sOKwPGVFpaMBDAcfCyseQ9Ob9/nzpDdtbMUOLLnK222Ak328We8t9n9uHey07lwucDx6wT6E6iuJAkopNELunGvDt4evQTnGiFhN+/4FNi9WJLzS9sDTBMV85YEjP/PpYKtHejNTM7ua5ntRhIVpuOkUNIRpC0xiv4bUEHqXJWhFw54fJae+5uyWylEHLjcjewsbN3Iv+UKIF8U1derUF5rziGGYXzajB8ssQeZKTWKFjyH+mnw6tghu09/XbjPLLsilxBxBY6qkIOMjR8D9iX3WTwfaevIajIUb/w==
X-YMail-OSG: lo9mv5MVM1kACjB04Wdzsl6HR9uInAq3s5Q5pZdt0TM1vn6w3rcKckWJ.B2FyIW
 URM6oOQxJRdk8xmGhAjDJxTQdfYbzD.M6c3LT4MxrnYVKCYDP0ezu93qRFMgeLIyQEtA1Sqd6FYd
 SH8lTcvHwIotsuwqJNZvP55QcdDdCceI20R90e6zT7F2zvnPU7HJsI4b.vdrVTYIHy7.VxA4iYwo
 S0z8aKQV2A2EBP0ztXSstBFUUkgZg3kR.s8zl.rxJr337zLQhTX7Bg7KmRM4_MF8SqYi4aM570pH
 2rUpLktVaCSG1ha.zii0k7qp50jmF0u_7zY6MBvHnZQ6n2553Xv2V3FHsnqlXL43T6vMieuQ3hG4
 c8Pch_2ywt1l.v6jym6VMEk7ZFHFgjePioUb1RxdOVHyxvoEU40c4sUEGIgkB5q_pi0Uj8oizDdy
 renZ_P.siXm8iI6ViwkbZDqEPKIjv7lougtkvoW_V7YuzMWLsIlq8t89jXVMvcdiRoooL6.TMgH2
 YJUkgztw.DZLvjPc21kws_brvj78n3lo4bFK.iBOvKAgHzIR7n8q_N7.2p97vAFPrxpAKiRCzuGC
 BjGUb1THxzmhq_MFbJquc18W2B3tY1QXezXLOjTYK7DJKTLYfAzY4Kphn3l3MsZeHzxSgyyv3VsF
 PVNiYykoFoi9FVT2kwcvTbX7EBWbZot6COv5TY5O.Qh1TPAWshtOwnwkBrnKUwg5ZswJV7zwoFqp
 GanR3S5dRTbdemLUx8R6DxM_t21d7LfbvzsBpjbs55yiXMkI1akDZvcCmXG6JHGffSB9KzfnDk9Y
 QlhgsArxTewNqfy_6xA8igATlPrgs3DOGERmIsl1PYmGkfKGbXOGRHJ6evZUg8hRfiHbUqbDI2Im
 BMfChQJRrbyYPrxQKbPo3xWBoNkludDo4Kvm.q_Gt5bYLToyy6GSWS_bnJcUMw1400Enx23u2yUN
 82qgnBBqcJoUF5JPkMjUinjLDEqJWmt9.5GWSwht_xdhJwPlbXRBYW1HWOH3Wb4Wpv3pYxksfgOg
 _TGFVOwWxp_.R02gF35xI_Bmp120kPhuK65EBYP1hBIhAAoa4TeDHivZMcUH_JtR38MpI0jAe4Lg
 wamG0fZ.yOl..MYzjuBVj48APSO7TnPDFA1nYg1ShtMFAE5J63OD5ilCuaELXAbnQWHuAWjMZdtv
 jlzxkoIagYUkXQR7tfuj78u3Xh04f6otErixOI3DZCFalLQYJDx8MZU.dHsOLKe6mItABMsh5LmE
 AIboPF8wrvBe5kanyCJzOMWgca_2B.Shkcm3KXU0nW84URPsIl_CPF6ae9Pmtlk_OdsfMGUGtO7R
 82YZgVKl2QBUJUgsYJioTsi4d2jzQRH.PX9q3qRKDzhS8RJ3gerLeKtgueG8ubRLeQKWgTlPcWRy
 XgWzF_3BhRukC1l9muX7oreVZ.K_F5lLugVp_Kx8HQQAK5Rj9J0mAJpRlW1gTlY2R7eGQLTXUrz.
 T5uc0jkmIC_Wml9eukts_2pmZJunx2.Eh3a0pK6sAhFgNXPXfOSLXRXOUUDIO2xCDtfTtJABXLbg
 _WWvicoL8_hyAWNuKdk.3qa_R85H169feQ11MGF.sJuf2bb.9kX9N_JJv8HwWTgehXbLkr6U5a0n
 8fXgSW3bNMrZA5NKIsDLa4QhIkRumOxdsqu2dwU9CPxvqaIeayCcIfgPvp60yvs26gUtFScSDPf3
 nesQBVKR4NErfzruHbrL270fTwIa11tKJ2Qx2cczqRHg_BuRk3TJOOTLGtTizr1D1XfYn8PprQQx
 UvdvFCXRmjfSw_cUdVGKU0HFXukyW8rrG.EPWlyYiqLl_mxzX_0WHpdTYMJpfgsGgbftjgvPSv_g
 Se72sqwzAEdDWrqfnX_g_ry8oWMp5.dZjFJtxS9phwR46Hzd.Qq9YrU6ctqicUhHIZq59MwexZIu
 0Zwu2r6RJHi_IkM2Sq6jweBHFK5ouXULtLaDQNfgTAU0qFrLRTlEspcQGs4itg_WzAoVh0Veh43k
 co.nmZY5LldRyb3475P6Q1m_65SfdGgqEzDLBmq1IW9NrwTp5BGgMMPZMT.5gteRl_mHB4GheBnv
 rzbDkMTeuuTFUK52NGK.wpS0WgeSdLwULVRJDZqm8knS3R1X1K8ukjzIRcN5DGA1mkUROwJqWFYs
 PYOZQs7G6HM60hIKk5GrGaMZSNoQUztChFv8UtOEkvDxNlXg6gRw8QUnwwEvqox00Gu9M6Tey07V
 M.BHf9gAF3MAgILOtWoZIqtTv6T8VQ_OYoeqy9EqctDkml2ViYIqoPCerlnrLXA_Y4s51aX6z7Xt
 xJsRlLHNVkq5pGvmvbwG9nGh2frh7d2wUUH7r8il9g32CDjM.XQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Jul 2022 16:46:43 +0000
Received: by hermes--production-ne1-7864dcfd54-hwfdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 11e4dece7afb4a53f8106e99c54af54b;
          Tue, 12 Jul 2022 16:46:37 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Partition layout of ARM SD card images
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <1169617916.2919.1657613121111@localhost>
Date: Tue, 12 Jul 2022 09:46:35 -0700
Cc: Warner Losh ,
 "Rodney W. Grimes" ,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1169617916.2919.1657613121111@localhost>
To: Ronald Klop 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lj6911Drcz3TB5
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=byBVeMcX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_HAM_SHORT(-0.30)[-0.297];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[5];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-12, at 01:05, Ronald Klop  wrote:

> . . .
>=20
>=20
> It seems the image builder of aarch64 13-stable is disabled.=20
> https://ci.freebsd.org/job/FreeBSD-stable-13-aarch64-images/
> Other architectures are enabled.=20

Looks to me like even if the:

https://ci.freebsd.org/job/FreeBSD-*-aarch64-images/

were being run, the activity would not seem to test
what the likes of:

           cd /usr/src/release
           sh release.sh -c arm64/RPI.conf

does in chroot_arm_build_release for producing an image.
For example, chroot_arm_build_release does not use mkimg .

It appears that:

=
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-imag=
es.sh

is only set up for where passing "-b ufs/boot/pmbr" to
mkimg is useful. In fact:

https://ci.freebsd.org/job/FreeBSD-main-aarch64-images/

shows runs failing for:

mkimg: ufs/boot/pmbr: No such file or directory

before they disabled the project.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul 13 01:17:00 2022
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 524FC1CFCB0A
	for ; Wed, 13 Jul 2022 01:17:09 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.217])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjKTw0sTTz3lrN
	for ; Wed, 13 Jul 2022 01:17:07 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657675025;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:Date:Message-Id:Subject:From:Cc:Date:From:Subject:Sender;
    bh=dk+iBNDhJ/GND58CuGPsJnTRT3kZJX2lfSzfbQEQteE=;
    b=K3EwnZYPJiyOkgVHmLQ44tbT6ptMCEC0Y66BsaAjSB2YAnDNRpLJglJpgF1mUkp0rh
    o0oUZq05A1rGWQuF0+Bchjm2G4voD+VnnrvBK4p0WICgiRtPC/jC4hU1HCXI2Rexaxuq
    1lNPDjc4FmZmZaz7sk+EwfURjP5pgtJcKT4AjmCDkh7foIfXxsOsVqt4g4RAQJJGyDM6
    WDTQ5n15ranPZrKzAaPDi1/COmMexcJR/gRSkCS+SbZ+xVq1DwBwms0SJFf4uXg+VtRJ
    4vPsM9m0VvNmXPdAz2NdSVWJ1sHlpYydWFTcAZYUMMw/yXFjS5Ypv5W+texg2Ez3uYeL
    XimQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id 5bc9a3y6D1H40dh
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Wed, 13 Jul 2022 03:17:04 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 3D845631C3
	for ; Wed, 13 Jul 2022 03:17:03 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Startup-/Shutdown Button for the Raspberry Pi 4
Message-Id: 
Date: Tue, 12 Jul 2022 22:17:00 -0300
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LjKTw0sTTz3lrN
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=K3EwnZYP;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.217 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[81.169.146.217:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[cyclaero.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

One week ago I started with exploring the Raspberry Pi 4 B, which might =
be a substitute for the aging BeagleBone Blacks for my future projects.

I very much like the built-in power button facility of the BBB, and =
unfortunately the RPi 4 has nothing comparable - the one button to rule =
it all.

I read a lot of howtos and blog posts (mostly for Linux) and nothing was =
really worth to give it even a try, compared to live without the button. =
Well, this is not becoming an elaborated question, but here I am going =
to elaborate my solution for FreeBSD.

1. I Prepared a momentary push button for connecting it to the RPi:
            ___=20
             | /
             |/
             /
            /
         +-o      o--------+
         |        |        |
         |       [R] 100 =CE=A9 |
         |        |        |
         o        o        o
       Pin 5    Pin 6    Pin 13
      (SCL 1)   (GND)   (GPIO 27)

2. I created a shutdown daemon in C for FreeBSD, lurking for push button
   events on a GPIO port: https://github.com/cyclaero/shutdd

   clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses shutdd.c =
-lgpio -s -o /usr/local/bin/shutdd

   shutdd [-p file] [-f] [-n] [-b] [-g] [-h] =20
    -p file    the path to the pid file [default: /var/run/shutdd.pid] =20=

    -f         foreground mode, don't fork off as a daemon. =20
    -n         no console, don't fork off as a daemon. =20
    -b         GPIO bank id [default: 0]. =20
    -g         GPIO line id [default: 27]. =20
    -h         shows these usage instructions. =20

   echo "/usr/local/bin/shutdd" >> /etc/rc.local=20

Restart and ready for testing the RPi's Power Button.

shutdd does not poll the state of the GPIO port, but instead utilizes =
FreeBSD's user space interface for GPIO interrupts for lurking on state =
changes of the GPIO line - default GPIO.0.27. Therefore, no significant =
load is imposed on the CPU's.

After 2 hs of operation, in output of ps -ax:
...
550  -  Is     0:00.03 /usr/local/bin/shutdd
...

- No CPU load !!!

- Pressing the power button does the same as shutdown -p now

- Pressing the power button when the RPi is down but still connected to =
the 5 V power supply lets it starting up.

BTW, I left the RTC DS3231 on I2C 1. That means, the RTC and the power =
button share the same pins for SCL 1 and GND.


From nobody Wed Jul 13 03:54:45 2022
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 8BE0C17F9591
	for ; Wed, 13 Jul 2022 03:54:57 +0000 (UTC)
	(envelope-from nick@i11.co)
Received: from mx.i11.co (mx.i11.co [159.69.78.69])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjP003bFkz422y
	for ; Wed, 13 Jul 2022 03:54:56 +0000 (UTC)
	(envelope-from nick@i11.co)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i11.co;
	s=omicron; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:
	In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=E+T0GKVsx6Y2AGQ+9UNgAB1XPVRvKEHUcgTrJu41ZFc=; b=a08/CD9UEXW4YiwOpGFpOLGB6i
	ui+xio9nUpzN/f5sWbyAniBxnCtpptAgNbSvdv/tdPrP3x3Nw+ddrrpn2PQbZAhK/G4GEx3gAhk8t
	TdCcldOlmBNmsHbyh+frDX4omB4Rdti1HaLIsjRlNje3PS/eVkA6sOU3cXxeQxzQlyaWV7lpx+IKf
	OgqYd0sG8XyPBDr0bhoaPGfJW3qPo5JOAxwt4BQ4T4phZ28NKzqVgcLd+N/Se6Jf6ADgCd4SEbxLR
	T/Q1vUl+fsSgO5VybgYuUT5p9HOMUq9anlo3Vb0NCmoDGRm8SqQLEFovgEMufMIfKtYdBRqiPELWB
	Xka3CWig==;
Received: from [212.237.25.26] (helo=thinkbook)
	by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1oBTSa-0002Vp-JD; Wed, 13 Jul 2022 03:54:48 +0000
Date: Wed, 13 Jul 2022 06:54:45 +0300
From: Nick Kostyria 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: path for overlays
Message-ID: <20220713035445.3a22da0d@thinkbook>
In-Reply-To: 
References: 
	
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.3)
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: 4LjP003bFkz422y
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i11.co header.s=omicron header.b="a08/CD9U";
	dmarc=pass (policy=reject) header.from=i11.co;
	spf=pass (mx1.freebsd.org: domain of nick@i11.co designates 159.69.78.69 as permitted sender) smtp.mailfrom=nick@i11.co
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[i11.co,reject];
	R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69];
	R_DKIM_ALLOW(-0.20)[i11.co:s=omicron];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[i11.co:+];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[nick];
	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_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 11 Jul 2022 22:16:44 -0700
Mark Millard  wrote:

> Nick Kostyria  wrote on
> Date: Tue, 12 Jul 2022 03:27:25 UTC :
> 
> > On Mon, 11 Jul 2022 00:18:59 -0300
> > "Dr. Rolf Jansen"  wrote:
> > 
> >   
> > > 
> > > Anyway, for enabling I2C5 (we may choose from I2C3, I2C4, I2C5 and I2C6) on a Raspberry Pi 4, we do:
> > > 
> > > # fetch https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/i2c5-overlay.dts
> > > # dtc -I dts -O dtb -b0 -@ -o /boot/msdos/overlays/i2c5.dtbo i2c5-overlay.dts
> > > 
> > > Then we add the following 2 lines to /boot/msdos/config.txt:
> > > 
> > >   gpio=12,13=a5
> > >   dtoverlay=i2c5,pins_12_13
> > >   
> > 
> > Hello.
> > 
> > I see you use /boot/msdos/overlays/ for overlays.
> > I have a question for a long time and I can't find an answer.
> > 
> > What is the difference between /boot/msdos/overlays/ and /boot/dtb/overlays/ (fdt_overlays in /boot/loader.conf).  
> 
> [I've written these notes to presume a RPi* context based on
> U-Boot, not EDK2 UEFI/ACPI or the like, and  not for other
> platforms.]
's

Thank you very much for the clarification.

From nobody Wed Jul 13 06:14:53 2022
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 CC24A1D04097
	for ; Wed, 13 Jul 2022 06:15:03 +0000 (UTC)
	(envelope-from hello@paulwrankin.com)
Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4LjS5g4rKvz4J1d
	for ; Wed, 13 Jul 2022 06:15:03 +0000 (UTC)
	(envelope-from hello@paulwrankin.com)
DKIM-Signature: a=rsa-sha256; b=GRq0kLcrtohNuGj/zkwcxolBnUV+npDm8/wQgQazNsgqmD7clHIjBedKs4C0nJ4x0xdfca5iuS9L6UL/4NDc8T0yN7rXizlPpXqLa+Yc1gKgiU4oZAdXqH10pJziU9DLs+hNU8+r04ZrJ8HsYQOlrZm3QJrxrPg8MWO3j04vR8/vz93hZ4rGXG6baAYt1JlIgSPmW3BV5yJnBNNwAPfMx5M2Sygm1j/PPwa+NV6XyqQ6bslnFHOrGJv4spaH5T77UUSaxep2gdbuRmMY4Te5ZJqt2HFIdQXdhgkWIFBumtMv1clu6IeIGLjTq9Uug+abSA+wKk7Kyuvp5FH3p12vrA==; s=purelymail3; d=paulwrankin.com; v=1; bh=hRocSmClFpVCzM2kgcbQB2degQ8CCzxH/tLyJjb1jVY=; h=Received:From:To;
DKIM-Signature: a=rsa-sha256; b=gQQED+bT4izMZOOD+GC6K69TEEz8LdrDTmSbTsZkQzYRND1Ve9RhBh4x4eX2jDOT9tzURPQM0FCIs6YUDTwHahbazytkdXL2oA7vXb7hcr1IhtOQWcx9fkHNAy2PRV4S1ga5V8cdVaHtnHHI1hzmoFtr3LsBBWy5rYTOvO73euLRHHGd5lGnH9s8ZuXnZ1olbNj85CnY6IwS9+Oni/UtU4shfIIjX1hH2IskPrEso6hPk+sv/XcvaXRlnQdBG4b9xowbqQWO4InOeCYc2omrPySYQSS7TXTbl2QsyRMIwFtDnt2b34Tg5I+tu6UW+eGTjy6mheV6bmHm3F7yhvzF/g==; s=purelymail3; d=purelymail.com; v=1; bh=hRocSmClFpVCzM2kgcbQB2degQ8CCzxH/tLyJjb1jVY=; h=Feedback-ID:Received:From:To;
Feedback-ID: 791:353:null:purelymail
X-Pm-Original-To: freebsd-arm@freebsd.org
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 19457483;
          (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
          Wed, 13 Jul 2022 06:14:53 +0000 (UTC)
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
Date: Wed, 13 Jul 2022 16:14:53 +1000
From: "Paul W. Rankin" 
To: Jesper Schmitz Mouridsen 
Cc: freebsd-arm@freebsd.org
Subject: Re: Which aarch64 release image is appropriate for the Pinebook Pro
 (rk3399)?
In-Reply-To: 
References: 
 
User-Agent: Purely Mail via Roundcube/1.5.2
Message-ID: <04fcfea157f720c5c23d07831a3c3a8b@purelymail.com>
X-Sender: hello@paulwrankin.com
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LjS5g4rKvz4J1d
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=paulwrankin.com header.s=purelymail3 header.b=GRq0kLcr;
	dkim=pass header.d=purelymail.com header.s=purelymail3 header.b=gQQED+bT;
	dmarc=pass (policy=reject) header.from=paulwrankin.com;
	spf=pass (mx1.freebsd.org: domain of hello@paulwrankin.com designates 34.202.193.197 as permitted sender) smtp.mailfrom=hello@paulwrankin.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[paulwrankin.com,reject];
	R_SPF_ALLOW(-0.20)[+a:sendmail.purelymail.com:c];
	R_DKIM_ALLOW(-0.20)[paulwrankin.com:s=purelymail3,purelymail.com:s=purelymail3];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:14618, ipnet:34.192.0.0/12, country:US];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[paulwrankin.com:+,purelymail.com:+];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	HAS_WP_URI(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-07-11 06:22, Jesper Schmitz Mouridsen wrote:
> An official release is not really available yet, I wrote about the
> subject in the FreeBSD Journal which tries to guide towards a recent
> (mostly) official source build. The article is here
> https://freebsdfoundation.org/wp-content/uploads/2022/04/FreeBSD-on-the-Pinebook-Pro.pdf
> It has sounds pathces and panfrost and not the least a working display
> port for the panel.
> Some errors have probably sneaked in in the article please feel free
> to complain to me/ask me for details. It might also already be a
> little outdated IIRC for instance the mixer patch does not longer
> apply and is not necessary any more.

Thanks Jesper!

I flashed your image to the eMMC. The big problem I ran into was that 
the display would corrupt on a reboot, requiring a hard reset. I believe 
NetBSD have fixed this?

From nobody Wed Jul 13 06:33:26 2022
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 AE4AF1D07DCA
	for ; Wed, 13 Jul 2022 06:33:31 +0000 (UTC)
	(envelope-from jsm@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 4LjSVz4J9Zz4Lp1;
	Wed, 13 Jul 2022 06:33:31 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657694011;
	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=0dr/WrQg0Hvorq8U1OQWL/zD8F7kf+cS/UeyFuskO4I=;
	b=HVN1Ns2zwFxKXmijqGuFSV3WJ08E4t/+GQcMsm6j525KOGeqyTNyqr8LtOjfd7tXfP6QVU
	0EBI51JM5wzBEfUCmvc/reIT5yGiPJ8sys9J7C5+4tOn5hNVY3HEAGlshHkjtpDMVQhXN5
	geo/foLSVCgvlW+MGAp8Ihz/DWDE88YkMRx393vSDTCUKUXH5gIzXa0bPFSRQKHihARsK/
	XbJyYJ09AJXN7Dhiz6iswP545OjMgD4840D8BB80fW+CMdxaw3fhTP/+OTgAGBLXQIKggu
	keGdQI6TLYHwW6/89w/pbJ/IIFiu8J9RJtaVwGz+U65e4qr98GBFepf//8MgUQ==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LjSVz0rFlz14v1;
	Wed, 13 Jul 2022 06:33:30 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: <956ab020-adad-092a-5ee2-6c12a4f45862@FreeBSD.org>
Date: Wed, 13 Jul 2022 08:33:26 +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:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: Which aarch64 release image is appropriate for the Pinebook Pro
 (rk3399)?
Content-Language: en-US
To: "Paul W. Rankin" 
Cc: freebsd-arm@freebsd.org
References: 
 
 <04fcfea157f720c5c23d07831a3c3a8b@purelymail.com>
From: Jesper Schmitz Mouridsen 
In-Reply-To: <04fcfea157f720c5c23d07831a3c3a8b@purelymail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657694011;
	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=0dr/WrQg0Hvorq8U1OQWL/zD8F7kf+cS/UeyFuskO4I=;
	b=fPCJdSlEE516wrJFwQSE4HDSuKkRE91mFPPY6BvpiiXnCczatcIwcM3XdiK086KzJwTbAk
	MA+UtLdUyU1eorN1B3kZjoCOLP39yENYL121F6X2COxBBmERVXe/dPEqpeoAaOLg7ZUT0o
	X9qgmYDyrCGvkVrc4bLqx5/hI0lWTXDtb1KeWwf2eQyXAjJClk9V7uyPHY6vci0JPZkWTN
	GKP6bMl5rs9DWfl/tN5Hq4tpJlFVh8igZUfiQ+IhA0JxGPM4vDLmRZTcEDtALCH2kIKk7x
	muwt7G7AFAS9G8OoG6zaelyo7ZEJfRGMp87NTZr3EFiFu9pnGRKF7yyKVuaQWw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657694011; a=rsa-sha256; cv=none;
	b=mpKlCHkWVBHmgnSC/NLDaZyhiYa32d6VbAuaPbRLQNAiQglw/F0cG8TV4ZNALmPEg+p1x+
	5FHPow0MkKOsQ42Ecd7bo78dx/NU//Uix5cKKVB2jgjoGlKGNJgCjdcDZ8dzzPjxdHCzUK
	9MzoB80QpNNAC8hu/BM88ftmJATx7vBzWz6qo3s4RcqkBta/LSEWZFKrRCBNOtznrwyJvN
	qxG6zlV4PatQ6VChAzWpHFKKswwpfXEZ0AC18MX5M7DHYaGBWyx2kUA52k6gZEZEc3CV36
	C0R8/4tlsGrLhgVKNDaGmYmLEIb7rKOLFjcP1MLzazeOU2+i/BRgAuaID0MUng==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 13.07.2022 08.14, Paul W. Rankin wrote:
> On 2022-07-11 06:22, Jesper Schmitz Mouridsen wrote:
>> An official release is not really available yet, I wrote about the
>> subject in the FreeBSD Journal which tries to guide towards a recent
>> (mostly) official source build. The article is here
>> https://freebsdfoundation.org/wp-content/uploads/2022/04/FreeBSD-on-the-Pinebook-Pro.pdf 
>>
>> It has sounds pathces and panfrost and not the least a working display
>> port for the panel.
>> Some errors have probably sneaked in in the article please feel free
>> to complain to me/ask me for details. It might also already be a
>> little outdated IIRC for instance the mixer patch does not longer
>> apply and is not necessary any more.
>
> Thanks Jesper!
>
> I flashed your image to the eMMC. The big problem I ran into was that 
> the display would corrupt on a reboot, requiring a hard reset. I 
> believe NetBSD have fixed this?

Yes, perhaps my image by mistake does not contain the patched u-boot, I 
did transplant the NetBSD fix into u-boot.

This should be it https://github.com/jsm222/u-boot-pinebookpro/releases, 
note that u-boot in ports tree has moved on, so you might

simply try to use the binaries.

Regards

Jesper


From nobody Wed Jul 13 16:55:54 2022
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 267DE1CF9EA3
	for ; Wed, 13 Jul 2022 16:55:55 +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 4LjkK64L94z3fd8
	for ; Wed, 13 Jul 2022 16:55:54 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4LjkK638HPzWsB
	for ; Wed, 13 Jul 2022 16:55:54 +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 26DGtsLe016858
	for ; Wed, 13 Jul 2022 16:55:54 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26DGtsUE016857
	for freebsd-arm@FreeBSD.org; Wed, 13 Jul 2022 16:55:54 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 256468] reaching a breakpoint on an armv7 binary on arm64
 causes a SIGBUS
Date: Wed, 13 Jul 2022 16:55:54 +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: 13.0-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: fuz@fuz.su
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: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657731354;
	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=Ztm5kDSx5rDlGp69fFyJz2W4OS4NDRzs6bR0n2OgLL8=;
	b=KbWRDCPNdmtUnKT+GqhFpJvoB1mqS8NFTj+0SiFaltryRMmOCGePF15ojlMTJ1jh8v5/qw
	1Qn/GkAee2ba1N4zh23caIM5ByR9f1no5nOBfs4Eu2tg/A426438DNydcMMh+W+m1Z90zw
	L8AcUkoYGYu5eTbloKCZT2VieYtmaxiZtuuCBR2q9GaEa1WJCz0Cx2ayJW2Ge6m5/Y0SWo
	j++edsrlIrG4I7YQeCp5gsra0GciHFc6Ke1hdXjYQa74AAd/yhhbiP6j9SL6Q+mRmQVodG
	CNCksq2sSXRYccNy7DFmjMd3VGV5T9Li7dYYdUAV6FO6gdINefiPCego5LfErw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657731354; a=rsa-sha256; cv=none;
	b=HSMMlWsWmz+1ZZfmPU9NpjcZhS3+NVY4x1orxAdJrtvzqVW9wgZPqbj+PiBW6ZDsbLEsH0
	5BJ73ayvBptUid9LPsusNFzj8I9G5ipXXf8OEPAAhyiC2/yxoXhJU8hv1H/pEt6F6+AfDo
	7H92YiSwApi5B9HwerUWWwNohvYfCwi6vXxL5uJvKGLxUf++apCc78vIBFykRDQ+iHvh/9
	tt1JcDmX2QhpBXxOZeg7qN0sDkqnUsUvelJ3rmDB1zP9HRsSX77PlVKJupKVDo+5Xd9aHZ
	Gs3jMW1+dgNoPYmytsz9yqJneK+XROXRDRLueHbkxZywCVsEejPoS5TjjEXe8w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256468

Robert Clausecker  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
         Resolution|---                         |FIXED

--- Comment #8 from Robert Clausecker  ---
Seems like we are done here!

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Jul 13 23:19:57 2022
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 A69AF1D06FCE
	for ; Wed, 13 Jul 2022 23:20:11 +0000 (UTC)
	(envelope-from sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com)
Received: from mail-200160.simplelogin.co (mail-200160.simplelogin.co [176.119.200.160])
	(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 "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjtrV2mn2z3Xvv
	for ; Wed, 13 Jul 2022 23:20:10 +0000 (UTC)
	(envelope-from sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qoruscant.com;
	s=dkim; t=1657754402;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=VAk7DnVx0njscwZqfaLBlVjqykGy2XvuLbnwq100xxw=;
	b=DBWPtCTSri/MZjQg8+qVncPOfR5sJClo/WTUclVMxFWJEzKgOFK60hOYXMHCRM4uv5d80G
	vp/mW6mHDGUAuyRVm0btgPYeSu3azyL8wL7fN7t8EAATfBeWbBlgqZiT1mswdyohB8IVAl
	amtD/gMJLMAXcHe9Q/ZhTU2xIyhJ5cI=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Startup-/Shutdown Button for the Raspberry Pi 4
Date: Wed, 13 Jul 2022 18:19:57 -0500
In-Reply-To: 
From: Jedi Tek'Unum 
To: "Dr. Rolf Jansen" 
Cc: freebsd-arm@freebsd.org
Message-ID: <165775440275.8.4265153478134935826.51718197@qoruscant.com>
References: 
X-SimpleLogin-Type: Reply
X-SimpleLogin-EmailLog-ID: 51718197
X-SimpleLogin-Want-Signing: yes
X-Rspamd-Queue-Id: 4LjtrV2mn2z3Xvv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=qoruscant.com header.s=dkim header.b=DBWPtCTS;
	dmarc=pass (policy=quarantine) header.from=qoruscant.com;
	spf=pass (mx1.freebsd.org: domain of sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com designates 176.119.200.160 as permitted sender) smtp.mailfrom=sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com
X-Spamd-Result: default: False [-1.70 / 15.00];
	MISSING_MIME_VERSION(2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[qoruscant.com,quarantine];
	FORGED_SENDER(0.30)[freebsd-arm-list-2022-fea3@qoruscant.com,sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com];
	R_SPF_ALLOW(-0.20)[+ip4:176.119.200.160/29];
	R_DKIM_ALLOW(-0.20)[qoruscant.com:s=dkim];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:62371, ipnet:176.119.200.0/24, country:CH];
	MLMMJ_DEST(0.00)[freebsd-arm];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[qoruscant.com:+];
	FROM_NEQ_ENVFROM(0.00)[freebsd-arm-list-2022-fea3@qoruscant.com,sl.lmysyibvge3tcobrhe3syibsg44tgmrqlu.6e6oohdr67d6k@qoruscant.com];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
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

> On Jul 12, 2022, at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.com=
  wrote:
>=20
> =EF=BB=BFOne week ago I started with exploring the Raspberry Pi 4 B, whic=
h might be a substitute for the aging BeagleBone Blacks for my future proje=
cts.
>=20
> I very much like the built-in power button facility of the BBB, and unfor=
tunately the RPi 4 has nothing comparable - the one button to rule it all.
>=20
> I read a lot of howtos and blog posts (mostly for Linux) and nothing was =
really worth to give it even a try, compared to live without the button. We=
ll, this is not becoming an elaborated question, but here I am going to ela=
borate my solution for FreeBSD.
>=20
> 1. I Prepared a momentary push button for connecting it to the RPi:
>            ___=20
>             | /
>             |/
>             /
>            /
>         +-o      o--------+
>         |        |        |
>         |       [R] 100 =CE=A9 |
>         |        |        |
>         o        o        o
>       Pin 5    Pin 6    Pin 13
>      (SCL 1)   (GND)   (GPIO 27)

Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.

I imagine that the resistor is a current limit for the gpio pin and not the=
 pullup.

Regardless of how it is wired, why use SCL1 which is pulsing? And how can a=
ny of this cause a boot?

Is this =E2=80=9Cmagic=E2=80=9D dependent on some quirk(s) of RPi? Will it =
work with others, like Rock64?

> 2. I created a shutdown daemon in C for FreeBSD, lurking for push button
>   events on a GPIO port: https://github.com/cyclaero/shutdd
>=20
>   clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses shutdd.c -=
lgpio -s -o /usr/local/bin/shutdd
>=20
>   shutdd [-p file] [-f] [-n] [-b] [-g] [-h] =20
>    -p file    the path to the pid file [default: /var/run/shutdd.pid] =20
>    -f         foreground mode, don't fork off as a daemon. =20
>    -n         no console, don't fork off as a daemon. =20
>    -b         GPIO bank id [default: 0]. =20
>    -g         GPIO line id [default: 27]. =20
>    -h         shows these usage instructions. =20
>=20
>   echo "/usr/local/bin/shutdd" >> /etc/rc.local=20
>=20
> Restart and ready for testing the RPi's Power Button.
>=20
> shutdd does not poll the state of the GPIO port, but instead utilizes Fre=
eBSD's user space interface for GPIO interrupts for lurking on state change=
s of the GPIO line - default GPIO.0.27. Therefore, no significant load is i=
mposed on the CPU's.
>=20
> After 2 hs of operation, in output of ps -ax:
> ...
> 550  -  Is     0:00.03 /usr/local/bin/shutdd
> ...
>=20
> - No CPU load !!!
>=20
> - Pressing the power button does the same as shutdown -p now
>=20
> - Pressing the power button when the RPi is down but still connected to t=
he 5 V power supply lets it starting up.
>=20
> BTW, I left the RTC DS3231 on I2C 1. That means, the RTC and the power bu=
tton share the same pins for SCL 1 and GND.
>=20
>=20
>=20


From nobody Thu Jul 14 00:36:03 2022
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 872311D21B35
	for ; Thu, 14 Jul 2022 00:36:14 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjwXF0Dz4z3kB4
	for ; Thu, 14 Jul 2022 00:36:12 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657758970;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=okWYdgaGu6r18em66uDjnfbEcD1HsWk9AfSnZdMF9fo=;
    b=UTXtoYfv5domrlQ7Sm/5qxoUr7YY9A0/p6ut8r4XlBqnhW+P5IvGKzD9gJeuzvxjUY
    Rsuzo5HwRzrKPVOYaRofOOJ5b7MEDTouTxyWEu4UWwvHL3lgd1n1XOPREHcsV1DKVWMt
    RkbCVPtjppoeE4HzZjlQzLRjvslqY3DzH4J0zTfS2xU4P0Q+RpHLjYVKZOWzCYBpCt9Q
    Bt8tbGBTEaosYNG2z4Hh6HVOfY0eEvH2xwYTLsB+x2LkOLAAvFuU4IE0FfSZBhM2UhZ9
    n01L76yQS6HLvgqGwq6knzCZe9sFmTgpLTvWRsSQpEwmo7W8KDAxLvPx7HGFpdKDT/L0
    FKvQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id 5bc9a3y6E0aA4e8
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Thu, 14 Jul 2022 02:36:10 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id A64BE63931
	for ; Thu, 14 Jul 2022 02:36:08 +0200 (CEST)
From: "Dr. Rolf Jansen" 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_936E5512-84CF-4CAE-BADE-F9D8BE751C0F"
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.15\))
Subject: Re: Startup-/Shutdown Button for the Raspberry Pi 4
Date: Wed, 13 Jul 2022 21:36:03 -0300
References: 
 <165775440275.8.4265153478134935826.51718197@qoruscant.com>
To: freebsd-arm 
In-Reply-To: <165775440275.8.4265153478134935826.51718197@qoruscant.com>
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LjwXF0Dz4z3kB4
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=UTXtoYfv;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[cyclaero.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_936E5512-84CF-4CAE-BADE-F9D8BE751C0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 13.07.2022 um 20:19 schrieb Jedi Tek'Unum =
:
>=20
>> On Jul 12, 2022, at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at =
cyclaero.com =
 =
wrote:
>>=20
>> =EF=BB=BFOne week ago I started with exploring the Raspberry Pi 4 B, =
which might be a substitute for the aging BeagleBone Blacks for my =
future projects.
>>=20
>> I very much like the built-in power button facility of the BBB, and =
unfortunately the RPi 4 has nothing comparable - the one button to rule =
it all.
>>=20
>> I read a lot of howtos and blog posts (mostly for Linux) and nothing =
was really worth to give it even a try, compared to live without the =
button. Well, this is not becoming an elaborated question, but here I am =
going to elaborate my solution for FreeBSD.
>>=20
>> 1. I Prepared a momentary push button for connecting it to the RPi:
>>           ___=20
>>            | /
>>            |/
>>            /
>>           /
>>        +-o      o--------+
>>        |        |        |
>>        |       [R] 100 =CE=A9 |
>>        |        |        |
>>        o        o        o
>>      Pin 5    Pin 6    Pin 13
>>     (SCL 1)   (GND)   (GPIO 27)
>=20
> Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.
>=20
> I imagine that the resistor is a current limit for the gpio pin and =
not the pullup.
>=20
> Regardless of how it is wired, why use SCL1 which is pulsing? And how =
can any of this cause a boot?
>=20
> Is this =E2=80=9Cmagic=E2=80=9D dependent on some quirk(s) of RPi? =
Will it work with others, like Rock64?
>=20
>> 2. I created a shutdown daemon in C for FreeBSD, lurking for push =
button
>>  events on a GPIO port: https://github.com/cyclaero/shutdd
>>=20
>>  clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses =
shutdd.c -lgpio -s -o /usr/local/bin/shutdd
>>=20
>>  shutdd [-p file] [-f] [-n] [-b] [-g] [-h] =20
>>   -p file    the path to the pid file [default: /var/run/shutdd.pid] =20=

>>   -f         foreground mode, don't fork off as a daemon. =20
>>   -n         no console, don't fork off as a daemon. =20
>>   -b         GPIO bank id [default: 0]. =20
>>   -g         GPIO line id [default: 27]. =20
>>   -h         shows these usage instructions. =20

The power management of the RPis is quite non-sophisticated, and pin 5 =
(GPIO 3) of the Pis (3 or 4) happen to be the start-up-only pin when =
pulled down to ground. Now, the SCL line of the default I2C bus 1 is =
also routed to pin 5, and that cannot be changed. In case we don't need =
I2C1 otherwise, then we are done with connecting a simple momentary push =
button without resistor, and we would start shutdd with the flag -g 3. =
In this case pushing the button would start up the Pi when it is down, =
and it would stop the Pi by the way of the daemon when it is up. Only =
shutdd configures the given GPIO pin for exactly this purpose, and =
therefore I2C1 could not be used anymore.

In the Linux world it is common sense to simply assume, that you can't =
have your cake and eat it, and either I2C1 is either abandoned or =
double-switches or even more complex button assemblies with a n-channel =
analog multiplexer like the CMOS4053 are used.

The 100 =CE=A9 resistor together with the auxiliary GPIO line lets us do =
this in a more simple way. Pin 5 is internally pulled-up, pin 13 is =
internally pulled down. Now pushing the button would do a fractional =
pull-down of pin 3 and a fractional pull up of pin 13. The fraction is =
determined by the values of the internal pull up/down resisters compared =
to the 100 =CE=A9 resistor. The point is, that shutdd does not depend on =
accurate logic levels are reached, but instead reacts on rising and/or =
falling edges on the configured GPIO's.

Now by experiment, for my RPi 4B, the 100 =CE=A9 resistor is =
sufficiently large for the pulled up fraction of the level on GPIO 27 =
(pin 13) produces edges which can be recognized and yet it is =
sufficiently low, so that starting up the RPi by pulling down GPIO 3 (=3D =
SCL 1, pin 5) does work as well. For example a resistor of 1 k=CE=A9 =
(and above) does not work for starting up, while shutting down does =
work, and without the 100 =CE=A9 resistor, starting up does work but =
shutting down does not.

I do know nothing about the Rock64, except that it exists. In case the =
power management is comparable to the one of RPis, this might work as =
well. In case it is comparable to the sophisticated one of the =
BeagleBone Black, all this is not needed, you even don't need the =
shutdown daemon shutdd for that. In case Rock64's power management is =
completely different, then you would start with reading the specs.

As long as nobody pushes the button, SCL 1 and with it I2C1 does working =
normally, and once somebody pushes the button, it is not that important =
anymore, since the RPi goes down anyway.

BTW, right now I am working on implementing a double-push facility into =
shutdd. This would then restart the RPi instead of shutting it down.


--Apple-Mail=_936E5512-84CF-4CAE-BADE-F9D8BE751C0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



Am 13.07.2022 um 20:19 schrieb Jedi Tek'Unum =
<freebsd-arm-list-2022-fea3@qoruscant.com>:

On Jul =
12, 2022, at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.com <nxtzmchnyjrirskcrisaafakxcekosgmhdcricnnjyxomsvwpn@simplelogin.=
co> wrote:

=EF=BB=BFOne week ago I =
started with exploring the Raspberry Pi 4 B, which might be a substitute =
for the aging BeagleBone Blacks for my future projects.

I very much like the built-in power button facility of the =
BBB, and unfortunately the RPi 4 has nothing comparable - the one button =
to rule it all.

I read a lot of howtos and =
blog posts (mostly for Linux) and nothing was really worth to give it =
even a try, compared to live without the button. Well, this is not =
becoming an elaborated question, but here I am going to elaborate =
my solution for FreeBSD.

1. I Prepared a =
momentary push button for connecting it to the RPi:
  =
        ___ 
      =
     | /
          =
 |/
           /
          /
  =
     +-o      o--------+
       |        | =
       |
       | =
      [R] 100 =CE=A9 |
      =
 |        |        |
       o        o =
       o
     Pin 5 =
   Pin 6    Pin 13
    (SCL =
1)   (GND)   (GPIO 27)

Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.

I imagine that the resistor is a current limit =
for the gpio pin and not the pullup.

Regardless of how it is wired, why use SCL1 which is pulsing? =
And how can any of this cause a boot?

Is =
this =E2=80=9Cmagic=E2=80=9D dependent on some quirk(s) of RPi? Will it =
work with others, like Rock64?

2. I created a shutdown daemon in C for =
FreeBSD, lurking for push button
 events on a GPIO =
port: https://github.com/cyclaero/shutdd

 clang -g0 -O3 -fsigned-char -Wno-empty-body =
-Wno-parentheses shutdd.c -lgpio -s -o /usr/local/bin/shutdd

 shutdd [-p file] [-f] [-n] [-b] [-g] =
[-h]  
  -p file    the path to the =
pid file [default: /var/run/shutdd.pid]  
  -f =
        foreground mode, don't fork off as a daemon. =
 
  -n         no console, =
don't fork off as a daemon.  
  -b     =
    GPIO bank id [default: 0].  
  -g =
        GPIO line id [default: 27].  
  -h         shows these usage =
instructions.  

The power management of the RPis is quite =
non-sophisticated, and pin 5 (GPIO 3) of the Pis (3 or 4) happen to be =
the start-up-only pin when pulled down to ground. Now, the SCL line =
of the default I2C bus 1 is also routed to pin 5, and that cannot be =
changed. In case we don't need I2C1 otherwise, then we are done with =
connecting a simple momentary push button without resistor, and we =
would start shutdd with the flag -g 3. In this case pushing the button =
would start up the Pi when it is down, and it would stop the Pi by the =
way of the daemon when it is up. Only shutdd configures the given GPIO =
pin for exactly this purpose, and therefore I2C1 could not be used =
anymore.

In the Linux world it is common sense to simply assume, that =
you can't have your cake and eat it, and either I2C1 is either abandoned =
or double-switches or even more complex button assemblies with a =
n-channel analog multiplexer like the CMOS4053 are used.

The 100 =CE=A9 resistor =
together with the auxiliary GPIO line lets us do this in a more simple =
way. Pin 5 is internally pulled-up, pin 13 is internally pulled down. =
Now pushing the button would do a fractional pull-down of pin 3 and a =
fractional pull up of pin 13. The fraction is determined by the values =
of the internal pull up/down resisters compared to the 100 =CE=A9 =
resistor. The point is, that shutdd does not depend on accurate logic =
levels are reached, but instead reacts on rising and/or falling edges on =
the configured GPIO's.

Now by experiment, for my RPi 4B, the 100 =CE=A9 resistor is =
sufficiently large for the pulled up fraction of the level on GPIO 27 =
(pin 13) produces edges which can be recognized and yet it is =
sufficiently low, so that starting up the RPi by pulling down GPIO 3 (=3D =
SCL 1, pin 5) does work as well. For example a resistor of 1 k=CE=A9 =
(and above) does not work for starting up, while shutting down does =
work, and without the 100 =CE=A9 resistor, starting up does work but =
shutting down does not.

I do know nothing about the Rock64, except that it exists. In =
case the power management is comparable to the one of RPis, this might =
work as well. In case it is comparable to the sophisticated one of the =
BeagleBone Black, all this is not needed, you even don't need the =
shutdown daemon shutdd for that. In case Rock64's power management =
is completely different, then you would start with reading the =
specs.

As long =
as nobody pushes the button, SCL 1 and with it I2C1 does working =
normally, and once somebody pushes the button, it is not that important =
anymore, since the RPi goes down anyway.

BTW, right now I am working on =
implementing a double-push facility into shutdd. This would then restart =
the RPi instead of shutting it down.

=

--Apple-Mail=_936E5512-84CF-4CAE-BADE-F9D8BE751C0F--

From nobody Thu Jul 14 13:26:38 2022
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 4LkFdb6XkDz1J1kM
	for ; Thu, 14 Jul 2022 13:26:59 +0000 (UTC)
	(envelope-from sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com)
Received: from mail-200163.simplelogin.co (mail-200163.simplelogin.co [176.119.200.163])
	(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 "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LkFdZ6SLPz3wgD
	for ; Thu, 14 Jul 2022 13:26:58 +0000 (UTC)
	(envelope-from sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qoruscant.com;
	s=dkim; t=1657805211;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ft6tEPw750tfZGVKRCRCxR1PV0FIeer6jn7x/Xlf2nM=;
	b=hWUwuc0ryoJC5v2DzlSJjCDlUCcqeIUX3ySBfesUTFzVMeXxyKRf9S2nZInCm4dTfB2eUc
	YrRLiWEZVBRT7PVR/UL7EsZIBijh6pZhnDjj4QI+WvOBp7dLxYm5Vdwbl0J/TWItWQBhAr
	OGebii5EC8HSeMcXNidzHO1n1vVxHdk=
Content-Type: multipart/alternative;
 boundary=Apple-Mail-A247728D-319B-4FEE-B8DD-9328EB68D6BC
Content-Transfer-Encoding: 7bit
Subject: Re: Startup-/Shutdown Button for the Raspberry Pi 4
Date: Thu, 14 Jul 2022 08:26:38 -0500
In-Reply-To: 
From: Jedi Tek'Unum 
To: freebsd-arm 
Message-ID: <165780521135.7.10590681011079085662.51797902@qoruscant.com>
References: 
X-SimpleLogin-Type: Reply
X-SimpleLogin-EmailLog-ID: 51797902
X-SimpleLogin-Want-Signing: yes
X-Rspamd-Queue-Id: 4LkFdZ6SLPz3wgD
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=qoruscant.com header.s=dkim header.b=hWUwuc0r;
	dmarc=pass (policy=quarantine) header.from=qoruscant.com;
	spf=pass (mx1.freebsd.org: domain of sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com designates 176.119.200.163 as permitted sender) smtp.mailfrom=sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com
X-Spamd-Result: default: False [-0.50 / 15.00];
	MISSING_MIME_VERSION(2.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.60)[-0.604];
	DMARC_POLICY_ALLOW(-0.50)[qoruscant.com,quarantine];
	FORGED_SENDER(0.30)[freebsd-arm-list-2022-fea3@qoruscant.com,sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com];
	NEURAL_HAM_LONG(-0.21)[-0.206];
	R_DKIM_ALLOW(-0.20)[qoruscant.com:s=dkim];
	R_SPF_ALLOW(-0.20)[+ip4:176.119.200.160/29];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-arm];
	ASN(0.00)[asn:62371, ipnet:176.119.200.0/24, country:CH];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[freebsd-arm-list-2022-fea3@qoruscant.com,sl.lmysyibvge3tsnzzgazcyibshaydcnrwlu.zgzhagnq27dm2@qoruscant.com];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[qoruscant.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N
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


--Apple-Mail-A247728D-319B-4FEE-B8DD-9328EB68D6BC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Jul 13, 2022, at 7:36 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.com <=
nxtzmchnyjrirskcrisaafakxcekosgmhdcricnnjyxomsvwpn@simplelogin.co> wrote:
>=20
> =EF=BB=BF
>=20
>>> Am 13.07.2022 um 20:19 schrieb Jedi Tek'Unum :
>>>=20
>>> On Jul 12, 2022, at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.c=
om  wrot=
e:
>>>=20
>>> =EF=BB=BFOne week ago I started with exploring the Raspberry Pi 4 B, wh=
ich might be a substitute for the aging BeagleBone Blacks for my future pro=
jects.
>>>=20
>>> I very much like the built-in power button facility of the BBB, and unf=
ortunately the RPi 4 has nothing comparable - the one button to rule it all=
.
>>>=20
>>> I read a lot of howtos and blog posts (mostly for Linux) and nothing wa=
s really worth to give it even a try, compared to live without the button. =
Well, this is not becoming an elaborated question, but here I am going to e=
laborate my solution for FreeBSD.
>>>=20
>>> 1. I Prepared a momentary push button for connecting it to the RPi:
>>>           ___=20
>>>            | /
>>>            |/
>>>            /
>>>           /
>>>        +-o      o--------+
>>>        |        |        |
>>>        |       [R] 100 =CE=A9 |
>>>        |        |        |
>>>        o        o        o
>>>      Pin 5    Pin 6    Pin 13
>>>     (SCL 1)   (GND)   (GPIO 27)
>>=20
>> Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.
>>=20
>> I imagine that the resistor is a current limit for the gpio pin and not =
the pullup.
>>=20
>> Regardless of how it is wired, why use SCL1 which is pulsing? And how ca=
n any of this cause a boot?
>>=20
>> Is this =E2=80=9Cmagic=E2=80=9D dependent on some quirk(s) of RPi? Will =
it work with others, like Rock64?
>>=20
>>> 2. I created a shutdown daemon in C for FreeBSD, lurking for push butto=
n
>>>  events on a GPIO port: https://github.com/cyclaero/shutdd
>>>=20
>>>  clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses shutdd.c =
-lgpio -s -o /usr/local/bin/shutdd
>>>=20
>>>  shutdd [-p file] [-f] [-n] [-b] [-g] [-h] =20
>>>   -p file    the path to the pid file [default: /var/run/shutdd.pid] =20
>>>   -f         foreground mode, don't fork off as a daemon. =20
>>>   -n         no console, don't fork off as a daemon. =20
>>>   -b         GPIO bank id [default: 0]. =20
>>>   -g         GPIO line id [default: 27]. =20
>>>   -h         shows these usage instructions. =20
>=20
> The power management of the RPis is quite non-sophisticated, and pin 5 (G=
PIO 3) of the Pis (3 or 4) happen to be the start-up-only pin when pulled d=
own to ground. Now, the SCL line of the default I2C bus 1 is also routed to=
 pin 5, and that cannot be changed. In case we don't need I2C1 otherwise, t=
hen we are done with connecting a simple momentary push button without resi=
stor, and we would start shutdd with the flag -g 3. In this case pushing th=
e button would start up the Pi when it is down, and it would stop the Pi by=
 the way of the daemon when it is up. Only shutdd configures the given GPIO=
 pin for exactly this purpose, and therefore I2C1 could not be used anymore=
.
>=20
> In the Linux world it is common sense to simply assume, that you can't ha=
ve your cake and eat it, and either I2C1 is either abandoned or double-swit=
ches or even more complex button assemblies with a n-channel analog multipl=
exer like the CMOS4053 are used.
>=20
> The 100 =CE=A9 resistor together with the auxiliary GPIO line lets us do =
this in a more simple way. Pin 5 is internally pulled-up, pin 13 is interna=
lly pulled down. Now pushing the button would do a fractional pull-down of =
pin 3 and a fractional pull up of pin 13. The fraction is determined by the=
 values of the internal pull up/down resisters compared to the 100 =CE=A9 r=
esistor. The point is, that shutdd does not depend on accurate logic levels=
 are reached, but instead reacts on rising and/or falling edges on the conf=
igured GPIO's.
>=20
> Now by experiment, for my RPi 4B, the 100 =CE=A9 resistor is sufficiently=
 large for the pulled up fraction of the level on GPIO 27 (pin 13) produces=
 edges which can be recognized and yet it is sufficiently low, so that star=
ting up the RPi by pulling down GPIO 3 (=3D SCL 1, pin 5) does work as well=
. For example a resistor of 1 k=CE=A9 (and above) does not work for startin=
g up, while shutting down does work, and without the 100 =CE=A9 resistor, s=
tarting up does work but shutting down does not.
>=20
> I do know nothing about the Rock64, except that it exists. In case the po=
wer management is comparable to the one of RPis, this might work as well. I=
n case it is comparable to the sophisticated one of the BeagleBone Black, a=
ll this is not needed, you even don't need the shutdown daemon shutdd for t=
hat. In case Rock64's power management is completely different, then you wo=
uld start with reading the specs.
>=20
> As long as nobody pushes the button, SCL 1 and with it I2C1 does working =
normally, and once somebody pushes the button, it is not that important any=
more, since the RPi goes down anyway.
>=20
> BTW, right now I am working on implementing a double-push facility into s=
hutdd. This would then restart the RPi instead of shutting it down.

Clever solution. Thanks for the explanation.

I should have looked before I typed. The Rock64 has a button. Your solution=
 is likely very specific to the Rpi chip.


--Apple-Mail-A247728D-319B-4FEE-B8DD-9328EB68D6BC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Jul 13, 2022, at 7:36 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.com =
<nxtzmchnyjrirskcrisaafakxcekosgmhdcricnnjyxomsvwpn@simplelogin.co> w=
rote:

=EF=BB=BF

Am 13.07.2022 um 20:19 schrie=
b Jedi Tek'Unum <freebsd-arm-list-2022-fea3@qoruscant.com>:

On Jul 12, 2022, =
at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at cyclaero.com <nxtzmchnyjrirskcrisaa=
fakxcekosgmhdcricnnjyxomsvwpn@simplelogin.co> wrote:
<=
br class=3D"">=EF=BB=BFOne week ago I started with exploring the Raspberry =
Pi 4 B, which might be a substitute for the aging BeagleBone Blacks for my =
future projects.

I very much like the built-in=
 power button facility of the BBB, and unfortunately the RPi 4 has nothing =
comparable - the one button to rule it all.

I =
read a lot of howtos and blog posts (mostly for Linux) and nothing was real=
ly worth to give it even a try, compared to live without the button. Well, =
this is not becoming an elaborated question, but here I am going to el=
aborate my solution for FreeBSD.

1. I Prepared=
 a momentary push button for connecting it to the RPi:
 =
         ___ 
      &=
nbsp;    | /
          &nb=
sp;|/
           /
          /
      &=
nbsp;+-o      o--------+
      =
 |        |        |
       |       [R] 100 =CE=A9 |       |        |  =
;      |
       o   &=
nbsp;    o        o
  &nbs=
p;  Pin 5    Pin 6    Pin 13
  =
  (SCL 1)   (GND)   (GPIO 27)
Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.

I imagine that the resistor is a current limit for=
 the gpio pin and not the pullup.

Regardless o=
f how it is wired, why use SCL1 which is pulsing? And how can any of this c=
ause a boot?

Is this =E2=80=9Cmagic=E2=80=9D d=
ependent on some quirk(s) of RPi? Will it work with others, like Rock64?
2. I create=
d a shutdown daemon in C for FreeBSD, lurking for push button
 events on a GPIO port: https://github.com/cyclaero/shutdd

 clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses sh=
utdd.c -lgpio -s -o /usr/local/bin/shutdd

&nbs=
p;shutdd [-p file] [-f] [-n] [-b] [-g] [-h]  
  -p =
file    the path to the pid file [default: /var/run/shutdd.pid] &=
nbsp;
  -f         foreground mode, =
don't fork off as a daemon.  
  -n     &n=
bsp;   no console, don't fork off as a daemon.  
&n=
bsp; -b         GPIO bank id [default: 0].  
  -g         GPIO line id [default: 27]. =
 
  -h         shows these usag=
e instructions.  

The power management of the RPis is quite non-sophisti=
cated, and pin 5 (GPIO 3) of the Pis (3 or 4) happen to be the start-up-onl=
y pin when pulled down to ground. Now, the SCL line of the default I2C=
 bus 1 is also routed to pin 5, and that cannot be changed. In case we don'=
t need I2C1 otherwise, then we are done with connecting a simple momentary&=
nbsp;push button without resistor, and we would start shutdd with the flag =
-g 3. In this case pushing the button would start up the Pi when it is down=
, and it would stop the Pi by the way of the daemon when it is up. Only shu=
tdd configures the given GPIO pin for exactly this purpose, and therefore I=
2C1 could not be used anymore.

In the Linux world it is common sense to simpl=
y assume, that you can't have your cake and eat it, and either I2C1 is eith=
er abandoned or double-switches or even more complex button assemblies with=
 a n-channel analog multiplexer like the CMOS4053 are used.

The 100 =CE=A9 resistor together=
 with the auxiliary GPIO line lets us do this in a more simple way. Pin 5 i=
s internally pulled-up, pin 13 is internally pulled down. Now pushing the b=
utton would do a fractional pull-down of pin 3 and a fractional pull up of =
pin 13. The fraction is determined by the values of the internal pull up/do=
wn resisters compared to the 100 =CE=A9 resistor. The point is, that shutdd=
 does not depend on accurate logic levels are reached, but instead reacts o=
n rising and/or falling edges on the configured GPIO's.

Now by experiment, for my RPi 4B, th=
e 100 =CE=A9 resistor is sufficiently large for the pulled up fraction of t=
he level on GPIO 27 (pin 13) produces edges which can be recognized and yet=
 it is sufficiently low, so that starting up the RPi by pulling down GPIO 3=
 (=3D SCL 1, pin 5) does work as well. For example a resistor of 1 k=CE=A9 =
(and above) does not work for starting up, while shutting down does work, a=
nd without the 100 =CE=A9 resistor, starting up does work but shutting down=
 does not.

I do k=
now nothing about the Rock64, except that it exists. In case the power mana=
gement is comparable to the one of RPis, this might work as well. In case i=
t is comparable to the sophisticated one of the BeagleBone Black, all this =
is not needed, you even don't need the shutdown daemon shutdd for that. In =
case Rock64's power management is completely different, then you would=
 start with reading the specs.

As long as nobody pushes the button, SCL 1 and with it I2C1 d=
oes working normally, and once somebody pushes the button, it is not that i=
mportant anymore, since the RPi goes down anyway.

BTW, right now I am working on implementin=
g a double-push facility into shutdd. This would then restart the RPi inste=
ad of shutting it down.

Clever solution. T=
hanks for the explanation.

I should have looked be=
fore I typed. The Rock64 has a button. Your solution is likely very specifi=
c to the Rpi chip.


--Apple-Mail-A247728D-319B-4FEE-B8DD-9328EB68D6BC--


From nobody Thu Jul 14 14:45:24 2022
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 4LkHNF599fz2pJ05
	for ; Thu, 14 Jul 2022 14:45:33 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.221])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LkHNB65kXz468p
	for ; Thu, 14 Jul 2022 14:45:30 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1657809927;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=psC6PSOGQbIBFAYksfciXl2AQJUZxF/w6VygRsFU5e4=;
    b=eNph6rQ0BaGIP6wH3obQ2reOFrVQeFbd6OkYnbb03FP58VLJqKbyq4/1RnqCzJm09G
    +biVJQzgVpNfMyDYmwo+N6OrisxA4uOk3o7CRR53CXAi9zccEhGx2+YIQA4PRgLWScw4
    mID0DGoeBdTI5Ocq4oJCg+t4UjiBE4kVqHjsIX82B8+lkUpqSqW8AMTxWgv9Vba6ksFD
    ANUmiMQNID+CF1Cp4MpcZJPSiaANzNJTCz5rXt9I2IWjy1HS10oi0UKGf0Wk23JUb8ir
    fQJzm7AhhSZULN5eCjOna8vegNLNdW7Mp1vFKH2/hL9se9RvqRNwtAv0pj0V6vn57P7C
    5nxQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id 5bc9a3y6EEjR7kg
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Thu, 14 Jul 2022 16:45:27 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.95.254.116])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id EE19562EB5
	for ; Thu, 14 Jul 2022 16:45:26 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Re: Startup-/Shutdown Button for the Raspberry Pi 4
Date: Thu, 14 Jul 2022 11:45:24 -0300
References: 
 <165780521135.7.10590681011079085662.51797902@qoruscant.com>
To: freebsd-arm 
In-Reply-To: <165780521135.7.10590681011079085662.51797902@qoruscant.com>
Message-Id: <3F174C46-A377-4D90-92CA-55BF242A6017@cyclaero.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4LkHNB65kXz468p
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=eNph6rQ0;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.221 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	BLOCKLISTDE_FAIL(0.00)[81.169.146.221:server fail,177.95.254.116:server fail];
	DMARC_NA(0.00)[cyclaero.com];
	RCVD_IN_DNSWL_NONE(0.00)[81.169.146.221:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-arm];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 14.07.2022 um 10:26 schrieb Jedi Tek'Unum =
:
>=20
> On Jul 13, 2022, at 7:36 PM, Dr. Rolf Jansen - freebsd-rj at =
cyclaero.com =
 =
wrote:
>> =EF=BB=BF
>>> Am 13.07.2022 um 20:19 schrieb Jedi Tek'Unum =
:
>>>=20
>>>> On Jul 12, 2022, at 8:17 PM, Dr. Rolf Jansen - freebsd-rj at =
cyclaero.com =
 =
wrote:
>>>>=20
>>>> =EF=BB=BFOne week ago I started with exploring the Raspberry Pi 4 =
B, which might be a substitute for the aging BeagleBone Blacks for my =
future projects.
>>>>=20
>>>> I very much like the built-in power button facility of the BBB, and =
unfortunately the RPi 4 has nothing comparable - the one button to rule =
it all.
>>>>=20
>>>> I read a lot of howtos and blog posts (mostly for Linux) and =
nothing was really worth to give it even a try, compared to live without =
the button. Well, this is not becoming an elaborated question, but here =
I am going to elaborate my solution for FreeBSD.
>>>>=20
>>>> 1. I Prepared a momentary push button for connecting it to the RPi:
>>>>          ___=20
>>>>           | /
>>>>           |/
>>>>           /
>>>>          /
>>>>       +-o      o--------+
>>>>       |        |        |
>>>>       |       [R] 100 =CE=A9 |
>>>>       |        |        |
>>>>       o        o        o
>>>>     Pin 5    Pin 6    Pin 13
>>>>    (SCL 1)   (GND)   (GPIO 27)
>>>=20
>>> Ok, I=E2=80=99ll bite. I=E2=80=99m not understanding this.
>>>=20
>>> I imagine that the resistor is a current limit for the gpio pin and =
not the pullup.
>>>=20
>>> Regardless of how it is wired, why use SCL1 which is pulsing? And =
how can any of this cause a boot?
>>>=20
>>> Is this =E2=80=9Cmagic=E2=80=9D dependent on some quirk(s) of RPi? =
Will it work with others, like Rock64?
>>>=20
>>>> 2. I created a shutdown daemon in C for FreeBSD, lurking for push =
button
>>>> events on a GPIO port: https://github.com/cyclaero/shutdd
>>>>=20
>>>> clang -g0 -O3 -fsigned-char -Wno-empty-body -Wno-parentheses =
shutdd.c -lgpio -s -o /usr/local/bin/shutdd
>>>>=20
>>>> shutdd [-p file] [-f] [-n] [-b] [-g] [-h] =20
>>>>  -p file    the path to the pid file [default: /var/run/shutdd.pid] =
=20
>>>>  -f         foreground mode, don't fork off as a daemon. =20
>>>>  -n         no console, don't fork off as a daemon. =20
>>>>  -b         GPIO bank id [default: 0]. =20
>>>>  -g         GPIO line id [default: 27]. =20
>>>>  -h         shows these usage instructions. =20
>>=20
>> The power management of the RPis is quite non-sophisticated, and pin =
5 (GPIO 3) of the Pis (3 or 4) happen to be the start-up-only pin when =
pulled down to ground. Now, the SCL line of the default I2C bus 1 is =
also routed to pin 5, and that cannot be changed. In case we don't need =
I2C1 otherwise, then we are done with connecting a simple momentary push =
button without resistor, and we would start shutdd with the flag -g 3. =
In this case pushing the button would start up the Pi when it is down, =
and it would stop the Pi by the way of the daemon when it is up. Only =
shutdd configures the given GPIO pin for exactly this purpose, and =
therefore I2C1 could not be used anymore.
>>=20
>> In the Linux world it is common sense to simply assume, that you =
can't have your cake and eat it, and either I2C1 is either abandoned or =
double-switches or even more complex button assemblies with a n-channel =
analog multiplexer like the CMOS4053 are used.
>>=20
>> The 100 =CE=A9 resistor together with the auxiliary GPIO line lets us =
do this in a more simple way. Pin 5 is internally pulled-up, pin 13 is =
internally pulled down. Now pushing the button would do a fractional =
pull-down of pin 3 and a fractional pull up of pin 13. The fraction is =
determined by the values of the internal pull up/down resisters compared =
to the 100 =CE=A9 resistor. The point is, that shutdd does not depend on =
accurate logic levels are reached, but instead reacts on rising and/or =
falling edges on the configured GPIO's.
>>=20
>> Now by experiment, for my RPi 4B, the 100 =CE=A9 resistor is =
sufficiently large for the pulled up fraction of the level on GPIO 27 =
(pin 13) produces edges which can be recognized and yet it is =
sufficiently low, so that starting up the RPi by pulling down GPIO 3 (=3D =
SCL 1, pin 5) does work as well. For example a resistor of 1 k=CE=A9 =
(and above) does not work for starting up, while shutting down does =
work, and without the 100 =CE=A9 resistor, starting up does work but =
shutting down does not.
>>=20
>> I do know nothing about the Rock64, except that it exists. In case =
the power management is comparable to the one of RPis, this might work =
as well. In case it is comparable to the sophisticated one of the =
BeagleBone Black, all this is not needed, you even don't need the =
shutdown daemon shutdd for that. In case Rock64's power management is =
completely different, then you would start with reading the specs.
>>=20
>> As long as nobody pushes the button, SCL 1 and with it I2C1 does =
working normally, and once somebody pushes the button, it is not that =
important anymore, since the RPi goes down anyway.
>>=20
>> BTW, right now I am working on implementing a double-push facility =
into shutdd. This would then restart the RPi instead of shutting it =
down.
>=20
> Clever solution. Thanks for the explanation.
>=20
> I should have looked before I typed. The Rock64 has a button. Your =
solution is likely very specific to the Rpi chip.

In the course of the work on the double-push feature for shutdd, which =
causes the RPi to restart instead of to shutdown, I figured that heavy =
bouncing of the button may affect the interval between multiple pushes. =
I could reduce the bouncing of my button significantly by adding a 1 =C2=B5=
F tantalum capacitor in parallel to the 100 =CE=A9 resistor. Depending =
on the mechanics of the button this is not absolutely necessary, though.

I finished the work on shutdd by now and the updated version can be find =
on GitHub: https://github.com/cyclaero/shutdd

Perhaps in the future I will add triple and quadruple push features, for =
example to cause the RPi to go into Single User Mode, and/or to start a =
user defined executable. For now I need to do other things.


From nobody Sat Jul 16 06:14:17 2022
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 4LlHxW2ncqz4WYmQ
	for ; Sat, 16 Jul 2022 06:14:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4LlHxV1BCCz3rxs
	for ; Sat, 16 Jul 2022 06:14:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657952060; bh=NzIaaMX0GooTbbWA32ZtxRRiKZML5qMzw/PrMpW7eXQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=i01b4E3gkb3NEsOq+svwAVkl/ClzXivNfzhjS9J3jKrgWMgybLHhaavo6RkIROhJfgjSZ97dOgqiQHbI6nVTPEF/I+N8+WxvJ317OfZKKkgtpPlYsNysi8s+jOu9LgY5CHT5kQPFoWAQ6f9dE9Q9s6gx9o9cbqtfpaJ6edX32UxwsCeneR4jnQ+1fOxwScKsGfHM2NBcIFIke3FL0VUTVPPWx94zabmrmVVCMj9pJQ1mW6TdWcVQxwbET6IPrWDWqht+vgn+HCVICi/VdKGMOL5zfgef8mkatwiWCEAbEszndz0dWOZhSEe+daElzUxEjacq6TajLVtFixA7Ot2FrA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657952060; bh=nboKxlZsU8UxxEob93wp9I8rEDhmD9lJDHcUMgn6NHg=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KqfpQ9fPppHdgdp96kSNXtUOlMEC7IRosMsO8tt71xNFrimCcNjWp52buh4hI1v5lqTeoRbTaIkPZxhrzEr+9WleRIPv6Eqe0FON/p/sFjnZSS8Xva2yUNPVe8ZY4jOMEYOUPPfKdr1J6fwEiOlVwqFEHd+ni9C+NPv9xEdZbFUyvo/R2fa+Rq2dJwIL2/2FVSosUcNejFqgBFEfCgKPyyfDPF4aaEiKA/9jSBAHr55nwdeUBIg9rxqQNAMxcHkWPGHmLLtpNY9obpnhrBLfBz3G6cvjYFVVL03ORy8vSFyfGpBvYcGLTdOlEd/k2M93V+ME6tsDsHqKICaLXjN+jQ==
X-YMail-OSG: YWuSlIEVM1mlzdOxI2AXSJdaC6TFK1ESILjyx8cmUPNUYdqGuMtCWMUDpKv_2dn
 bywhlWwe_708WFiKWNC_PhCWpQJEohYs6.YAVELpe6Ki7PZX5gXI_1r1d4Z9nJVz483ApLXvPQKl
 PQhx0Ibdu3xgllJ9uJNL2ldgWoXxnkQZEwXxA93VSBoXlQtbBn_VSjiLMF56cc3UYUMNaXH1MNIk
 EthHsEx5xJFCPxpjEbe63K.OWxLQ_fyQHeH8C5sQ4s7K3jjm0KO7KZvNBUzioKBn4LhfSi_uxU_4
 CBSqs14yarXzPixQ5pdFXJgTAn.iAuOrrs.RtUOmdwDBQPWfF2bntlY7e11GGj_HSetKnb6Nd8sE
 RSLlQ7EMZJ3CTJ80M_TywbaEB2djlC_RpkENswsg5LrB0JM8qcHQZNdRYeEqBU6ilhUqNRKzrzcw
 LyqdXDRmVutl1vbMjxrHGKRTQzaigDuHtovfdbi7jlTDO5MuwcMjQiNPBByPzbOGhACYI11SmfW4
 BtxL8P1_bMK6eQRkuH44P1qI1gGyZQvFiCsRwO26_vbZ1eqksU68LoPX21VZuTcmki6teD.Djs91
 _3Pr8SsXW8u54iWTfH9NFtvgSf012SbZoMwJviikUxxDKhMQ70b6z9Qx39HDfxqFygr.SLn8pAox
 t1TNkhTgPyYDYuPuCy29VV0S29sK5rj5UQxRca32t1FbizkzJlHh1bZoGA4pLKupK31Y2zG3QPso
 3qL1oODanjokkCLLgFkOENrmhvLhaHTCfvSqcaa71YaJt3t3h5ReLJpYMptjG61bydiYUGyDyt1u
 WvT8Fr4TbRruRVnwBgZcvxKHeULTZt.1vgyyrTuxvaz60vStdui.inq.eHjoF2LhjXP3oQk1qVst
 IYZWUBvxH8hds9dWII_MC3vDw0mwCzRryqHSopyRBasCrMLoUdZS.OaE4xH2jTCogFdKSTFi43PB
 s7N8f1rWUlvxyDA9BI0AH48RnenjQ4t8xUryOlgYt6acYcBFNSvlKLnAwZYt.Sg1wDVD2bIhLMoE
 Sl0lpRbTy46lFdXT78yfc3Qjhhsfh7QLneeqAkSehIY9CeQFCfzQ6RWyEIDtIYQh5zpAjNda12Cw
 E7w0St3x_H9onfGR_ejff2ZWqBm2UM3xhvplR5L.Uh3xwptaWNMI2LsNQENFnwVeFnZOk5sWOa.7
 zEvQSRl1YC5EhBJ4yqSQX0ZRP3uypXZ1kpTlMYPmi61GusPB9hdJaWjhSBcLOsDI4oTpLIsdTQiV
 dEvv4UXuPd_9cqI6M021yGPLmTcACIbVwuSUzZDLXl6GNihE7mpIsZKs_N6s4RHKB7BkgP7uAdpu
 LTqHpLPxCVlzYjuBWtQHh29XlsxDX0cwY7l_JKEpTe6JKBAoE9fWt__kEApBFOUaC5HjRKuQyJwL
 NsmpkS9UR6nd.nrtmReKFCT.iZtTZy8Yq999Y1u6T.4K51YEMWFryoNdYcesxfDG_p9COBlggqDj
 US_9g46oAvBgKhqjasnr0TwT5w1CDeWoG4a3J7bWA7OhGcZEFuF6JEtBt8RzTngXfIe8g_3DEM1I
 jqoBoVGp3tOjRF554ntBDVRQ7EkLNVCmW.4ZAxwUMpLx.HYSsr2T5Hbj67D6jYCwfAXYBAG3OJYV
 Z0dA5S8TgHpInt0qHkIeYLShu_GwMyOxw_RzIVEpeYbz4a9Z2pwc9mDqDAoOLG1rHmNORVJG66._
 a16L5HHHxasKDn3Se0zeufavhgYHApSBwbBkNNOTAwei5rWQWVOW5jGmgwzL3mM_9YP9GiOKZXkW
 IhQK_P0_BgQJyfSM4brvihfYGiV1sO31kHdjNdEdmJGJNRkfLYN0ei9TGO8pAbsaG3a5s_Ro2djp
 EQQMal6MbVRyYe3blX7uA8QHZQlFXZrx9SS4dcvrKEWh7Z.CRJsZTqnGh89BrkXDG1Cd9FHRBOC7
 yTpitoVH20s_2_DJtf0OujwmUAFa2c_Gp0Qzz4hr0e2t459lelNxWgqcbovcUGHuQbXghY64zN5o
 JUcofKnYZ3HpbIG0BUOxcffiQfmrX.LLJTPgsRvDSehkBXVsPHzWGuVKGC2pMhBrpBjRe1b7rEry
 ShAB0rTF1ow.5OsJGN4OnfvMlArJEMyY323npC7bynITXD3fJ6tDuOjJt7RFXeQrNSlyjg_JkdsR
 s7eVyjB.9ayGhiNITyaTq9mGB33pIWOhPG6s7ed7FxfyW4wVWdDQJ7kUJqs26_6rvIfwtvEY4g9i
 11wRIvmEVXqoHgBDiOfswq9V8PE9ziU5XHch6MFrQzFi6m.tK17ZYiiTdlQ4L
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jul 2022 06:14:20 +0000
Received: by hermes--production-bf1-58957fb66f-wkmxs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bf92602c39aeadb9bebc36d209338087;
          Sat, 16 Jul 2022 06:14:19 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 14.0 \(3654.120.0.1.13\))
Subject: Workaround for a
 FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img (and 
 more) USB3 boot failure on 8 GiByte RPi4B Rev 1.4, B0T SOC
Message-Id: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com>
Date: Fri, 15 Jul 2022 23:14:17 -0700
To: freebsd-arm 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D.ref@yahoo.com>
X-Rspamd-Queue-Id: 4LlHxV1BCCz3rxs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=i01b4E3g;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.33 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	NEURAL_HAM_MEDIUM(-0.85)[-0.845];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]
X-ThisMailContainsUnwantedMimeParts: N

I've reported the following boot problem to the lists
before but for older stable/13 and releng/13.1 versions.
I thought it had been fixed but it turns out something
else I had done hid the problem.

Both before and now, it turns out to fail or not based
on using the original config.txt vs. using one with
at least one specific line added that for some reason
avoids the problem. (I'm not blaming RPi* firmware.)

The failure looks like:

. . .
Release APs...done
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
uhub0: 5 ports with 4 removable, self powered
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on usbus0
Root mount waiting for: usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
uhub_reattach_port: port 2 reset failed, error=USB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> 

Both types of USB3 SSD boot media that I use get the problem.
One type I've used for many years and another for over
a year. Both USB3 ports lead to failure.

Similarly, more than one U-Boot version makes no difference
to the observed failure.

The workaround I've found is as shown below:

root@generic:~ # diff -u /boot/msdos/config.txt.orig /boot/msdos/config.txt
--- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000
+++ /boot/msdos/config.txt      2022-07-15 04:39:30.000000000 +0000
@@ -9,3 +9,8 @@
 [pi4]
 hdmi_safe=1
 armstub=armstub8-gic.bin
+#
+# Local addition that avoids USB3 SSD boot failures that look like:
+#   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
+#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
+force_turbo=1



I do not claim that is the only possibily, just that it
has sufficient in my context.

As my normal configuration uses "force_turbo=1", I would only
have ever noticed the issue if I'd tried to boot before making
the config.txt changes I normally have in place. Thus, the
issue might have been around for a notable time without my
noticing.


I've tried my U-Boot based main [so: 14] boot media without
the "force_turbo=1". It booted just fine.

===
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 16 06:32:07 2022
X-Original-To: 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 4LlJL85t1Gz4WbPv
	for ; Sat, 16 Jul 2022 06:32:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LlJL734S1z3tRM
	for ; Sat, 16 Jul 2022 06:32:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657953133; bh=kJW0notRRNGjh04a6mGHlg2Bl4ORfehu7fKBJ2QV5b4=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=lGKoHFEWNOkRlhMe9mlTVQM3n0rFkok49/R/64gs6ZGaV905iphxA37B3pt2AW8eoY9eG0/014e3tCt7gWx5Jba9OqvFHXY+nh3sj6vLF6acFde/bQMXHTSvKGSa90qKn03J9d8rSLnCIVB3hyBCNgsO00R6yw90p61gKNheSSeKjXPcKqfL+1ZEuvHL8swPFPICDfFXhcgTXhZcO6pgxyju/CxAB/ackL9c+13dcTpWlP63jlqwCuWvuLLOGzYjNmFF8Kpyo/zxmEMlQ1ZABFTkgsI817Eq30GdXpyqy0NkGZboIGOAowFn0BRNwEp6q+wSymQ2/XXi2/R6NY06Vw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657953133; bh=ehl23IisRT8Yj44XT1P46myO4XgldCwBli740ZxtwK/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Lgz3TpTazuPb8I1fWPqFV20rqfrS4LJncang8g5NWQ2mrMUjckHbPiKwm6JsOQGroFac1YgytMCVaD0evhiCJ+N96EGLummXmXoDLs2FWJ4z4lMaHDhoNvqvhlqo/Joq40WO3PCgkWVFBLyZU4J+x8IO/QxBmeUcvPE60TH+g1XgZq/Ao0GdSeXLS4a9DmClDJcXzsyjZU+k8+7m8XhjUMU1YcGL4UBGKQW0rN61P1gWLbT3FoWwNqNvyKmp5CN7Cmu6R/QD4ek/dMdgCrLLORe/xKlrR7VOtxXkm5p8kL5tcvsz3vjmKXjw1/57e48nBUeJw6SKNIpwGQDhnOQ5Cg==
X-YMail-OSG: gxARXcEVM1k_GpvM_z6BiffLAU6FHGKlwxe9qKjXT0j5_fADXfmez4ywditKI4p
 dJS8XdrkenaE65rsqc9vDTtFdOkD6Y3fYDHxKmE3PY3LOUvBWSU.18hIbhfvxonGhV_navuArbDL
 pwPaJlaitGuhP0o49KVOYTvoddtkzCF4I5b3p8R3X7Pp.wj.BhlO2e0QUitymy2pn.BjS7zPsTtw
 z_DpjZWxblwfQiJcaMj7XBp5k.qxjmgdmaZuc7I0gDNsvMSJtPbiKIxmgCvhFJ8U4TK6zg9n17_4
 4RQDKwqfRqk.pPNz748UQ77.FW4eAEK5uiGorU2YlR5IhRbxPz4md2Os_lDyaVswHc1qpQJ9jtEi
 aIE7Oul49RdRfe98tyAvn4bK3tiDGbwBf_Q4iI.pJQ_NBvkCxthxKpMpbC7PB3tsFFDOtShnO4vU
 7B_GGWq2mG3e5tMpvfgPoA3728IRB51BbjkrimDb3TcvPWYjH04uJY8ffJxBBwqifefXUr.AeR27
 KgPlxWq7Ts2mLtNtjR0Xbrb2Q5zqCRU.6rxPinz00drxBb2I6mXfpcm4rk5r9jYb5ocsmwlsWunc
 LxOI13IeIkkbphlmF6gYGmJX0XlSDFfDr2bLubQUPw2CGfiFYiAlUPlF2u6vm5MPC1KQGj9QxmTq
 byZIoGQ3hi5uEEzuj0fn9_kKM8LU2..WR33_sRvUwgFgmapVUk0SsBliGNxFUMNBAg05ngDfohE8
 BRr_TrejBJ9ZqFZX4wN6l7ySYz8enV6xow72xhMZEHGxYYb476lF9ymKRBpKoPaERTlflXLMOVji
 m4EHAL9Klf5WuC85Rb8keFHTizxDVMTzVmAP2z8X_v0LaJNXwngACwwZDT5bfSrEO49BC8aeQ498
 _zjvDjt1dXvjeO4eUm.BTCAe9aqXCfLOreUUWOSgFPTFSJFhIVes.1EASozTexrAiduHDezfUgCT
 C4s1TFAobbK6mf73MqmzH.3M0JqDMd.FnOSq.z2nnui8uawu0o.B89G8yhwaYa2pbjedNqy0EVpz
 3kNm6SmFsnJObAJmigS784Q.uo.jpVj8.xZmSAqPZ6.o6QOGSRdlr2ZEAfW1og7LXNu5baYW1AAO
 SUoG9PNw20.Tcqf3rM0q9KZxbIGuUtvxJnPpBhCla7AxczjBrKq4r34jqXcXMDOzMkVZxmLk67Xv
 JXGmSm_irHZc.zx6hfdGXaC6ZhqZoi5Phc6czIhrrg7pYkaNz0hrDBNvEL87sKfwt04BhAncvw8P
 m36zi0L30SWiC0O1KOXf4p4KoX2uNRe8uriGy7MFsk4xKAeOQj0_ceoEC0vtEeHqbog45hpfTt50
 2VasEzji_DQLr8V1fp1wMzArBWxPq4RP04i_ueA3XyNbhLE5tUwszzYxWDJjAGbfGXpQ6Sy3cWCL
 CjKNITZwPLYKsQ7LuKh8mpadyuxnmRxziEnyX5olOk7NF0_SwKvnl4xc1iWxjW3K5EiUulzOk4ws
 NL20mkZ92IZB0ru9FX.0AK_hmPfwgAxlMZbScM8xig2JXvkwfFrtYXuko9coFBzY_fcDDz2unyw6
 xUNZslVYSlNVW4nzVJgzkht_EbLjsF90q1R2QflO.4Iin1tZ5wInR1M1IwRAd74ua4qTBDsUpBJQ
 MaUpNqdNu.SxY5cNcPvT3vjeKBcYtT3RsVn0bvwCgEfeHbJEVw48fgzkK4Qj.exWr2rTpy5ZSZzp
 XSJTI5rObAbNGdx_xN.GA.f0y388NQBWJVf1M5n0jMzWKBgFVCe1J_vazJP6RwW.izI1d0tFdUpG
 7OkLAsSoBhrF4a7d9h.rKPltJIHzrB9ERT597w0doZJcNhaUDBzeQ9gzyOcX4leaajwZF6ShHP_W
 u3PpdlPXCi9.PuOPlmxSVxUd4Tyre.D5JXoPRx0q2bgqne9UeSbz07bwkA3mUers2UoFmmO5wjCq
 CKfZWutdyjfiXpZ_q0P94nGekI.4NcINTfWoNZguTbtd64aNfgJZjZpUUrosj78cuQ4Cvjr7kViP
 WTByZ3yejFJoM.n6uEcIwIzV4sdJsVBo9sN2z_2xsTxjVLqa_1jxv6IQqgZguoxZtxHYIpSs0t1X
 CXtrDJ3vpKO4JlAJscLIEAl_KScKZ7Cw2NwtUCtjODb1zTy9IOIMXeWA9vGTzBjoaAzvXSSAxS0t
 H6ypLjQwU1Re7x8d6OOgZHKtSvWo7mqiYVYWeOx1sxSbe41dPOPZplz0kvywY3jHMeGgRyU0Cmb1
 SRG.TQqcEg0qRYNrOhHmjoLsFOZtAE9i5jckfbdtHTWGXr1RJcH4YbxrHoMrlh9C2bwKNMkOPnnX
 q11TFKIlj9tantQKuzbCVc3GnFJM_Veb1XmVXe6JBhpbMFwEkPu5oxA9RGQw_
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jul 2022 06:32:13 +0000
Received: by hermes--production-bf1-58957fb66f-qrtmg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b5ba8c9ac817423d9ea2b2238e7577f;
          Sat, 16 Jul 2022 06:32:09 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T
 vintage SOC) when dd'd to the example USB3 media then used to try to boot via
 USB3 port
Date: Fri, 15 Jul 2022 23:32:07 -0700
References: 
 
 <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com>
 <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com>
To: "freebsd-arm@freebsd.org" 
In-Reply-To: <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com>
Message-Id: <62DD9052-449B-4FA6-8669-0FF1EC1D8D3A@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LlJL734S1z3tRM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lGKoHFEW;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.93)[-0.931];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[arm];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Jul-9, at 21:23, Mark Millard  wrote:

> On 2022-Jul-9, at 18:59, Mark Millard  wrote:
>=20
>> On 2022-Jul-5, at 15:45, Mark Millard  wrote:
>>=20
>>> On 2022-Jul-5, at 14:17, Mark Millard  wrote:
>>>=20
>>>> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context:
>>>>=20
>>>> A) One type of USB3 media (USB2 compatible) works for booting via =
USB2-port.
>>>> B) The same media fails for USB3-port based boot attempts.
>>>> C) I boot the same type of media for main [so: 14] instead of =
13.1-RELEASE.
>>>> D) An alternate type of USB3 media (USB2 compatible) booted via =
USB3 just
>>>> fine via 13.1-RELEASE.
>>>>=20
>>>> The details . . .
>>>>=20
>>>> I intended for for use in the Rev 1.4 8 GiByte RPi4B's
>>>> by first going onto USB3 media (of the same kind I
>>>> normally use on the RPi4B's with main and the like).
>>>> So, I tried:=20
>>>>=20
>>>> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 =
\
>>>> bs=3D1m conv=3Dsync status=3Dprogress
>>>>=20
>>>> and then tried to boot the RPi4B via the media and it gets
>>>> the following (the kernel loads and runs but . . .):
>>>>=20
>>>> . . .
>>>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>>>> uhub0: 5 ports with 4 removable, self powered
>>>> ugen0.2:  at usbus0
>>>> uhub1 on uhub0
>>>> uhub1:  =
on usbus0
>>>> Root mount waiting for: usbus0
>>>> uhub1: 4 ports with 4 removable, self powered
>>>> Root mount waiting for: usbus0
>>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port 3
>>>> mountroot: waiting for device /dev/ufs/rootfs...
>>>> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>>>>=20
>>>> Loader variables:
>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>>>> vfs.root.mountfrom.options=3Drw
>>>>=20
>>>> Manual root filesystem specification:
>>>> : [options]
>>>>   Mount  using filesystem 
>>>>   and with the specified (optional) option list.
>>>>=20
>>>> eg. ufs:/dev/da0s1a
>>>>     zfs:zroot/ROOT/default
>>>>     cd9660:/dev/cd0 ro
>>>>       (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>>>=20
>>>> ?               List valid disk boot devices
>>>> .               Yield 1 second (for background tasks)
>>>>     Abort manual input
>>>>=20
>>>> mountroot>=20
>>>>=20
>>>> Plugging into the other USB3 port and attempting the
>>>> power on boot just changes the port numbers from 3 to 2
>>>> in the sequence.
>>>>=20
>>>> Plugging into a USB2 port does not have the problem and
>>>> it completes the boot and operates. (The media is USB3
>>>> but USB2 compatible as well.)
>>>>=20
>>>> Adding to /boot/loader.conf :
>>>>=20
>>>> # First, 3 additions:
>>>> kern.cam.boot_delay=3D10000
>>>> vfs.mountroot.timeout=3D10
>>>> vfs.root_mount_always_wait=3D1
>>>>=20
>>>> and retrying via a USB3 port just results in:
>>>>=20
>>>> . . .
>>>> Root mount waiting for: usbus0 CAM
>>>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
>>>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port 3
>>>> Root mount waiting for: CAM
>>>> Root mount waiting for: CAM
>>>> Root mount waiting for: CAM
>>>> Root mount waiting for: CAM
>>>> Root mount waiting for: CAM
>>>> Root mount waiting for: CAM
>>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for =
10 more seconds
>>>> Mounting from ufs:/dev/ufs/rootfs failed with error 2.
>>>>=20
>>>> Loader variables:
>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>>>> vfs.root.mountfrom.options=3Drw
>>>>=20
>>>> Manual root filesystem specification:
>>>> : [options]
>>>>   Mount  using filesystem 
>>>>   and with the specified (optional) option list.
>>>>=20
>>>> eg. ufs:/dev/da0s1a
>>>>     zfs:zroot/ROOT/default
>>>>     cd9660:/dev/cd0 ro
>>>>       (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>>>>=20
>>>> ?               List valid disk boot devices
>>>> .               Yield 1 second (for background tasks)
>>>>     Abort manual input
>>>>=20
>>>> mountroot>=20
>>>>=20
>>>> So: same problem.
>>>>=20
>>>> For reference, from the media being plugged into a different
>>>> aarch64 FeeBSD machine running main:
>>>>=20
>>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
>>>> ugen1.5:  at usbus1
>>>> umass0 on uhub4
>>>> umass0:  =
on usbus1
>>>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>>>> umass0:6:0: Attached to scbus6
>>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>>>> da0:  Fixed Direct Access SPC-4 SCSI =
device
>>>> da0: Serial Number REDACTED
>>>> da0: 400.000MB/s transfers
>>>> da0: 953869MB (1953525168 512 byte sectors)
>>>> da0: quirks=3D0x2
>>>>=20
>>>> The RPi4B is of a vintage that has the "3 GiByte DMA" issue
>>>> present, not that it would be likely to be contributing here.
>>>>=20
>>>>=20
>>>> So I then tried the sequence using a different type of USB3
>>>> media (also USB2 compatible), placed in a USB3 port to boot:
>>>>=20
>>>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
>>>> ugen1.5:  at usbus1
>>>> umass0 on uhub4
>>>> umass0:  on =
usbus1
>>>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>>>> umass0:6:0: Attached to scbus6
>>>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>>> da0: Serial Number REDACTED
>>>> da0: 400.000MB/s transfers
>>>> da0: 228936MB (468862128 512 byte sectors)
>>>> da0: quirks=3D0x2
>>>>=20
>>>> For this media, the sequence worked and booted successfully.
>>>>=20
>>>>=20
>>>> So the issue is somehow specific to some USB3 media=20
>>>> used in the USB3 ports but not to others. "reset failed,
>>>> error=3DUSB_ERR_TIMEOUT" may need more time or better
>>>> recovery if a wider range of boot devices are to be
>>>> supported. May be the T7 Touch needs more than the
>>>> standard amount of time to reset as a USB3 device or
>>>> some such. (I've no clue about the details.)
>>>=20
>>> I substituted a 13-STABLE kernel.txz expansion and got the
>>> same result using that kernel. (There are not .img files
>>> for this currently.)
>>=20
>> I took a different path of setting up a stable/13 based
>> media, based on my own build context but upgrading a
>> 13.1-RELEASE starting point. This stable/13 variant boots
>> the RPi4B's just fine via the USB3 media that 13.1-RELEASE
>> failed to boot with. I'm not sure what the differences
>> that matter are.
>>=20
>=20
> Well, the kernel.txz was based on:
>=20
> Thu, 30 Jun 2022
> 	=E2=80=A2 git: 70fd40edb869 - stable/13 - debugnet: Fix an error =
handling bug in the DDB command tokenizer Mark Johnston
>=20
> via:
>=20
> Fri, 01 Jul 2022
> 	=E2=80=A2 New FreeBSD snapshots available: stable/13 (20220701 =
70fd40edb86) Glen Barber
>=20
> while my build was based on:
>=20
> stable/13-n251684-815db559eccc-dirty
> (815db559eccc is from Wed, 06 Jul 2022)
>=20
> Between those are:
>=20
> Fri, 01 Jul 2022
> 	=E2=80=A2 git: 39cd7aa134df - stable/13 - USB: add quirks to =
XHCI Bjoern A. Zeeb
> 	=E2=80=A2 git: 66754c01ff95 - stable/13 - XHCI: clear warm and =
port reset Bjoern A. Zeeb
>=20
> and that last mentions port reset handling explicitly.
> It is, at least, suggestive.

Nope.

Turns out that the problem still exists but my config.txt
content was hiding the problem. Once I have "force_turbo=3D1"
in config.txt , the problem stops. Without it, the problem
occurs. This is for stable/13 based and releng/13.1 based.
main [so: 14] does not show the problem wither way. (The
boot contexts being U-Boot style, like is normal for
FreeBSD.)

See: =
https://lists.freebsd.org/archives/freebsd-arm/2022-July/001585.html

>> For reference for the working stable/13 context and
>> other content involved:
>>=20
>> # strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_=20
>> VC_BUILD_ID_USER: dom
>> VC_BUILD_ID_TIME: 12:10:40
>> VC_BUILD_ID_VARIANT: start
>> VC_BUILD_ID_TIME: Feb 25 2021
>> VC_BUILD_ID_BRANCH: bcm2711_2
>> VC_BUILD_ID_HOSTNAME: buildbot
>> VC_BUILD_ID_PLATFORM: raspberrypi_linux
>> VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean)
>>=20
>> (/boot/efi/armstub8-gic.bin does not have very useful
>> version-string information.)
>>=20
>> # strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20'
>> U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000)
>>=20
>> Note: To my knowledge, the RPi* firmware, armstub8-gic.bin
>> file, and u-boot.bin file above are all as they were for
>> 13.1-RELEASE's image, other that for 13.1-RELEASE I had
>> also tried adding /boot/efi/timeout and I've left that
>> in place since then and I've added my usual
>> /boot/efi/config.txt material (that had also not made a
>> difference for 13.1-RELEASE).
>>=20
>> (/boot/efi/EFI/BOOT/bootaa64.efi and
>> /boot/efi/EFI/freebsd/loader.efi do not have very useful
>> version-string information.)
>>=20
>> # uname -apKU # manually line split
>> FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40
>> stable/13-n251684-815db559eccc-dirty: Sat Jul  9 14:02:23 PDT 2022
>> =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72
>> arm64 aarch64 1301505 1301505
>>=20
>>=20
>> Unfortunately, it has been some time since a
>>=20
>> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img
>>=20
>> (a snapshot) has managed to build and be distributed.
>> I'm not sure what the result would be like for such at
>> this point.
>>=20
>> Once such is available, I may do an experiment based on
>> just a stable/13 snapshot.

Done, using:

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img

That is when I figured out the "force_turbo=3D1" issue for config.txt
being involved in hiding the problem.

>>> But using:
>>>=20
>>> =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img
>>>=20
>>> does not have the problem.
>>=20

I still do not see the problem in main [so: 14].


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 16 18:19:06 2022
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 4Llc1s5FL2z4X8TZ
	for ; Sat, 16 Jul 2022 18:19:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(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 4Llc1r60Fkz3wtv
	for ; Sat, 16 Jul 2022 18:19:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657995550; bh=By+rSL4znBoX3XBPjBFtGEnOsPtbUyxTS92WpeSImoc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J06NGJ2/qQFnucyuyh4ocp43Il3qHlNFCLssV+KKXjIKpqnGOF/R9n5BOHu7joU3S9y+q9puvwbX6cK+vq1FYRBuOapN6fO7sRuFci74inMTeyGIz8USOOv+vvJ+yV2uIMIM4VP0qo3q59wjrJiVLJAFQAjd6dOydR0q1U7R761PurlKRVHWP8+dzwFstkpSWvox8W5Tyb+0plT+/SPx2Oa1UpCZc3Ir8xvJV5WjeTtzKsxmFYVXf4zJpALU6q/2wNvy8oj3gDWn1883gw3Du2H6jWIdfj4C7HBWTf83jDEf3IuR/ul6+g0czGXm4ur07n641qFvAk9+2mi5u7C3lw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657995550; bh=Giuc6fhc4F8pkFdcwWVcySQiOvjXhREyedm4caJDYSi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Spe7rWwtAT5gdKqrDmnHdJMhlXldyUwyYd3ftW7jwoWdngNAwm5sOQRBdxBuFuOhqcR5Xs4propNBOeks+5+pw+3uD1UeXGCMHKaGPmC39sq43M+x+Ul8YSu8OMYqekUFHRnWIDbMET0Hzcm3/uYrS58pE+biSr4r6uTyrsb9E8Ka3TBSIXfoy58GVkcVro6LCg5dZteRnCj4nqUAAR/JqUoNrYXHFuNAJxBTmVi+AotoejwkxWuIBA1PPMyv8xkV7qo5tm9bslsI3hBkpVktWYVe1MZQy5+m4WRbTc8DRfu/VyAqF7vYvUam1apAbvAk4m1yrl2HFz2Yqjrizwicg==
X-YMail-OSG: WcOb_54VM1lDPfEfTHWorGO_FkFIM6iF8.01rEQjkijsa9zMpnmeAKGTfLDcR_m
 Xad8dx8mZRj3c_5nsUp1oxld7Dn6sNawyfICNFcGXfwc0e4vp5FaUB6LTsD4xXE1zQlS8QAqRPIJ
 7eJ4RpWC64fOR7jeeEoUf3WqgzHuvhCYJ5JTRfusVyamjMyQIVdi.UxN2BPuNKrsEJq8Cbq5cRm9
 t27YzOlKQW.5AasRhbuixeiZdmoHcLlXCK4w5qU0fXn46f5CMoD.hPd1PrrbS7mM2XetiwSX0x1Q
 fMzCjXOmwsGg6DaYOuqBjcFFe_Ho4egwDbnFbejVwXBhBNIpeSbwLoDvGv.MkzzUzeDuQKdpFFOh
 bmgRm_W0itmxTOPRBmDF0H5l49VnBLjbzxaUrX5zoqO7hElPKZFpEKsO9sfwOAjhnAlUW198._1R
 jp5oeov2zFnyB2NjrQJBmT9vDGTQth2bK.k343xMEBpDhH1pBti3O2mTN1GHdsBglmhqF4sNe6Cd
 qqiA2DrzTjKparKi.tqDlN2Y9yuX_YHoD_wnd4naowNkv_IvIQf.p4ki_AAr6LSY3pT6Cgtgu7an
 i7ZTxyBEa.hunObImW3NOJkljdjg.YRFOrGwNLO4XpbcrMXdkdlaJg1l6KnFPnFJzoB7fAwhyRUQ
 zzoMxUJ8Y4ZjpAU1xU1xN4MuhjWfpD7Y3_RsLRtbhdVSaDam51JZyVGJPka1kfVh39IvvYQnvsZY
 lXFsJD_Zy3hOXEdTpmeo2v5HbK7CUt7Vtp76o5fmxBolW4aUKUqLeO9n0MQUrGkWkiGTy1PbK_QS
 RktystMQftHzyZoM0l_J2_BhpMKwRxn1ZS_n511IN0lGT3HBjsFxUhXyAvedvFOx3QWp_BpeUH4x
 22Y7gDyDoTibpPi2_5O0t1qf.H_GURZL3U3l.tSlu_MErxP9.0EZFjFpBeVZ6T6V_xt8KXVGofCk
 NpdAECjTzRlpxM1qRs8Zqb.dvgbNUpNDLaNEmft7jOK9o6zJ.n1OZYZTNkC9VyPRxWeOo.vx5hyt
 KHhkEVVyF6mhMWqHoqbvvPEKnXBMqcHZ5.VHaxw77p3YYzevD2vBzSrvFeJdMMuAzTWw2PuUIeaP
 IsGXyrJTzmKF5N7325YOYBllfRCWLQg12SnQ.9jOAJYElWDKx4cfY9G94r5kfjyUa4BJfdKL7YJe
 EiN2gafXHzFdIRBTFvvgLVW0QoIxHWB2LEevcH4OMgNvK.viJn74RGYu677fRwoFIEjxL7qQyy3D
 sErsRct4pdzzn6Tsh8SS5OKK31u4SOPGusCR4esqzntEpjirxqz3hTkQ.5YydSI147oXVsVyVPKD
 cDYf1KCdYSBX6v6D5MvOApnwgdHGg3iUAZFc1b5Apw_fa6Q93zwDflT9MpyIOeRJ31eSfUvBPoCd
 VQP5mR8JrjcWp5sC9Z_vgP3yTZkrAChe6tPdYp1rKEiBuCD_4FfjqBqcf6qACh44MVFw0_OmdtNY
 gEPj8XXen9P0Oh90ZuA5le4hoyEdMoaDJwctuSSj69Wt91UihtfS45KO69mIHfa7hfy7v07xlKQK
 e5NFxvATVwas64M6tDzaLDky09obZligSd9RW9YlgZrvQFninPozGUIgl3c3L2rYF0trDQSztBcJ
 cKApfKtNYXRzouwMvz1Dgy2WtUP5rYh9OnP9MxnK5oTT6hVbyXXtT4_LiUqf5J5EAt7Xp3nKnyE7
 DsVxVy0xpr2ERN9Z82vjDiel6zkod5b83x3YgCWN_kxUWXkMQn6nvx.0oHxLz4_O4Puc7slyN2df
 aj6vsmTvoGazkOh0XMXDxH9UVcDW.Nn7abSwMfGjpANCnrG9K.ovXDv1mCgYHtNokkIvIn1FXm1A
 eZYvNDFDfjDTQDPEW76cYz2.Wqfw6bqgqaE898fCsxyZUV_L_IE9luRywCkhPkkEYroaoIMfvIfo
 1RrOvUahLImJ7.dcCWfy4nk_aqOUabkpH_vlfv.9HXP_x6KIuC2SAeAe0NvaTf2jJu6yy5QwVRbr
 EU9CZ6yB0yasX4174GJKXiqhYK2anDhdrbCG0aEdti7x2TNwZx9bKU2yYJ.k1Sa5E238oklLXeKs
 tZnc.sY81R8GMZrvwtGGWo.POyMnMi9uCVcVezZLlxIRlExjyrSjOAH_aPc0TC.zoBc4wDxG13GE
 ua2K5EjgKWS_gGqkimFWsI5oZyCU_v9ql.D8CnIkux.wVROiqzA4Mofj5yiZ_F0s8fRHY5TMj0wX
 iFwV_2MRiJRldYGUkDlv0gug9nF.zvby8iJbeWL2qt84gDyp1rwEj4FE0vqnZWmY7WYOEbk8rWjg
 P
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jul 2022 18:19:10 +0000
Received: by hermes--production-gq1-56bb98dbc7-b6h6x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3c61db86134d61df00c898ec645431f2;
          Sat, 16 Jul 2022 18:19: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 14.0 \(3654.120.0.1.13\))
Subject: Re: Workaround for a
 FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img (and 
 more) USB3 boot failure on 8 GiByte RPi4B Rev 1.4, B0T SOC [inaccurate
 timeouts]
From: Mark Millard 
In-Reply-To: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com>
Date: Sat, 16 Jul 2022 11:19:06 -0700
Cc: "manu@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Llc1r60Fkz3wtv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="J06NGJ2/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.36 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_MEDIUM(-0.87)[-0.871];
	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];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

[Less invasive workaround and an explanation of
what may be going onto mess up (some?) timeouts
from be as long as intended, in this case one
for USB3 activity.]

On 2022-Jul-15, at 23:14, Mark Millard  wrote:

> I've reported the following boot problem to the lists
> before but for older stable/13 and releng/13.1 versions.
> I thought it had been fixed but it turns out something
> else I had done hid the problem.
>=20
> Both before and now, it turns out to fail or not based
> on using the original config.txt vs. using one with
> at least one specific line added that for some reason
> avoids the problem. (I'm not blaming RPi* firmware.)
>=20
> The failure looks like:
>=20
> . . .
> Release APs...done
> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
> uhub0: 5 ports with 4 removable, self powered
> ugen0.2:  at usbus0
> uhub1 on uhub0
> uhub1:  on =
usbus0
> Root mount waiting for: usbus0
> uhub1: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus0
> uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT
> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2
> mountroot: waiting for device /dev/ufs/rootfs...
> Mounting from ufs:/dev/ufs/rootfs failed with error 19.
>=20
> Loader variables:
>  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
>  vfs.root.mountfrom.options=3Drw
>=20
> Manual root filesystem specification:
>  : [options]
>      Mount  using filesystem 
>      and with the specified (optional) option list.
>=20
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>=20
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>      Abort manual input
>=20
> mountroot>=20
>=20
> Both types of USB3 SSD boot media that I use get the problem.
> One type I've used for many years and another for over
> a year. Both USB3 ports lead to failure.
>=20
> Similarly, more than one U-Boot version makes no difference
> to the observed failure.
>=20
> The workaround I've found is as shown below:
>=20
> root@generic:~ # diff -u /boot/msdos/config.txt.orig =
/boot/msdos/config.txt
> --- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000
> +++ /boot/msdos/config.txt      2022-07-15 04:39:30.000000000 +0000
> @@ -9,3 +9,8 @@
> [pi4]
> hdmi_safe=3D1
> armstub=3Darmstub8-gic.bin
> +#
> +# Local addition that avoids USB3 SSD boot failures that look like:
> +#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
> +#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
> +force_turbo=3D1

Following the implications in:

=
https://forums.raspberrypi.com/viewtopic.php?f=3D29&t=3D6201&start=3D425#p=
180099

QUOTE
. . . is done early in boot, before the cpufreq driver is loaded, and so
measures the stock (700MHz) frequency. Now this is value is used =
elsewhere
in linux when calibrating delays. E.g. the sdcard driver might call
udelay(1) and expect to get a delay of at least one microsecond. However
if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which
could cause a problem.

To help investigate this, I've add a config.txt parameter, =
initial_turbo,
which means turbo will be enabled from boot for this many seconds (up to
60), or until cpufreq driver sets a frequency.
END QUOTE

I've switched to trying:

# diff -u /boot/msdos/config.txt.orig /boot/msdos/config.txt
--- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000
+++ /boot/msdos/config.txt      2022-07-15 05:10:06.000000000 +0000
@@ -9,3 +9,8 @@
 [pi4]
 hdmi_safe=3D1
 armstub=3Darmstub8-gic.bin
+#
+# Local addition that avoids USB3 SSD boot failures that look like:
+#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
+#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
+initial_turbo=3D60

and this was enough to avoid the problems. (I've not tried to
find a near minimum for initial_turbo, I just used the maximum.)

It looks like stable/13 and releng/13.1 are sensitive to scaling
time based on early clock rates that later change to faster
rates, making timeouts happen in the wrong time frame. I've not
seen evidence of this for main [so: 14].

Or that is my guess at this point, not having driectly verified
a time scale difference at the involved code..

I've no clue if it is better for FreeBSD to add-in initial_turbo=3D60
to its contig.txt vs. doing something to avoid the sensitivity to
initial and later varying clock rates. Covering releng/13.1 without
an EN (or whatever it is called) would happen via initial_turbo=3D60
use in the port's config.txt .

I do not know if main [so: 14] has different timeout handling
that might explain why I've not found the problem in that
context.

> I do not claim that is the only possibily, just that it
> has sufficient in my context.

Turned out initial_turbo=3D60 was another workaround.

> As my normal configuration uses "force_turbo=3D1", I would only
> have ever noticed the issue if I'd tried to boot before making
> the config.txt changes I normally have in place. Thus, the
> issue might have been around for a notable time without my
> noticing.
>=20
>=20
> I've tried my U-Boot based main [so: 14] boot media without
> the "force_turbo=3D1". It booted just fine.
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 17 06:45:41 2022
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 4LlwbM4SC8z4TPfc
	for ; Sun, 17 Jul 2022 06:45:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4LlwbG6FG8z41fN
	for ; Sun, 17 Jul 2022 06:45:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658040345; bh=L7Ao+BpBKWiuWKWbJGu4G59nJSWbbKhE/0mlqYYSuqE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TRVNlIII+xEW9EhylvetPGoGvRav+ZF8r4layudeMK9Zrg3Re70U0GcXaYOmxVWaFZY1AlNxKYl3Fa/0mUspOwztPBC+n6XRL/9Ne8krQsY5TmzKXcNMdQGPXrzCSkja+4fnoMQjHQFjA5SuCO+opO7jyzFYpCwVm9dFqsxUeb2/U9/4Xvk7qjDYOfKMSfTwDv8N7xqRYndxgEE+/oOtxRk8W2pMqkGAEsTWCA6ivnqY0Odc8Rmqif/oHrdPDCTD0zQgpeTYEHRZ9CzNNb2sRVW6nyWs/R/W+uxpHdDUAYMZmKaijZIFJMzioqpxaZFfnA+YjcbrKCBlrAt28dtwrQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658040345; bh=nsjImyqvP/BpQcxYlzr0wDsQ3D3DZjcPKqi/ljGoFLx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N6uHjVlDWR7tFwFIQrk3uYr8kKf9qIoi53rT2B0Vsjdy/K/N9IgbxNDmM3xlc02S2dGj8NdOsHVM+tWfMDKiW0C9IkmJPtCY+CbLyHHWnFxUj++69xJ6TJfHhl4Q/K+IKfIx0AZ6ea12/G4P4V0Gjs67PcP1CXeQIdpERiMUvXF7QfdiG0iUjBG4SYhCWsJ7EaHlNV7nTL0TZmNEDd/vtF4uh48D+vgkNV0WCF+HkbBrAhjsChDP6cVAexzquDebJQ41x7pJXi4Iv1uzbSaIwQg2WCdOxJlF7Vcm51aLSnjBKexz0iaB3EEeHjMxePta9vrq9Y1U68W3MEDrvV9C2w==
X-YMail-OSG: aaJYHfIVM1k_Li.ULt5EggCzeoS2iqIEjzkHPmQDEYd6E0WNtM7oNCuT72BtIwj
 UgAv3XM4hfgH8WdVukRIzonMve.U1eVx_6cshgoKJ.YWmKAykira9c5q.FodX4XEXIjc6_IhprY1
 F3eK8qRuRJA_9GUbcI4tZGZ1SAxhuaMAMJ7QxH.jZpK_Vrr.UPAQjHx3Q0.2s.SBW44LkAvWuS3B
 q9aw8LhBRsVc8PfQW5tElQMbePiltZaSX738fRhgE2bAk5YmSUdpGR16TCMY5nuAIX4qG1vmARmT
 MT_YBmdOiUTW0VZS5mSuxki6noNmmsRmOoeiYWsgTRRAKnj7aKmxjibtLDsG0RJWh4Qr2wIhGo7t
 hpMKmgcW4ZAwXNMM2gk50Jvw0Jcd21Y6Ssitu1wqaNQ.a858chXPmyXBFz5Z2zma4TTaCdKO_EUN
 H7Q3DqFo9IM.KgbP2cw_ZpEAMNZeJmcjKlDADyBPlX0iUY9rSskE8bxcXXlePh7PuBhO3ErAtOV.
 CeT8hBLdGClpoznAvNoVcUmh73fGwMlPnImzZEKIlXDT.pzPOOA8evnQbJ0MlPhHKmp9iQ5ZCKdy
 vJA2jQ6mz0P5ZcgxQTAXwLo5QEV2S4h3PKX_4LhHVhXSY1GD7g9MbPodYu8wH7aG_aWoaPRqBHZt
 y6LHAsoRSrZnAtLpoK62ga1SGWKBtGNpgzWnR5jva9NOsw8he1FIgOGNq_gk0B7vYaV3wyGUQPzY
 iCt1ZX9Wi0wMYzCoR3Rl5TkUKuswJCm7lbODlEbqPXFsr5yyE2zhYObYwjFGz15npknq0PCPGb5S
 WEuTNQ7whwmGC9no7KS8nTVVJ1dbG7D89GUD8oLCDn7hBnbsZRhQLXwIur_IcpyfVpgDk6TNtr_f
 _1f.sb.XkzKmQfTUOovLzzR0EsLlOtufruRs0AXxx_5KJn8A2NMg7xQ34gUFwDnwal_wDPzSHJRI
 cc2jXn8.tSnhgXUEKoMCHG5u70wgcQpyHaKo0BLMR2AF_gOrVWrLX14RWHWk374Io1QRb9OGDkai
 Cin6nDAWtVZAmjRqBdupJ.kH.dt5d1k8sTGN1QDZk.5nYa43abJT8ZObeHbid2ZZJ9r61R4APjOV
 k6V69sV5FdaocsxanytHL26ixkys79pgU7qN_.1Kmh.0tCScsIJBXaTRSnfwXx9qGRIbm64Gqouw
 kkGUG72fvwTsWVmBJcs4RgILwcmzVCGyK7UcGyPtAct0BkFzXsxIeTBo5jfXvRV9wPcT_L5zKtyg
 Ky7B6ifyJla6JV57ewEwOgA9sDN5c3SwiwTcJRTDHrV3nmp6j8vfA0EZU3UhD6Mk08LT10Ngashq
 NV1_u2jMnjhB_o9M8aoSerzeJ34yZl65ROpKazVmf3Ix0I_gqccFpunqCwcNnpNDDy5k742McTt6
 qiTBpWUSncA41QIZzWSNY4uLTRbrtlMbHqqELDbZbj6qrnP5Iq08n1BHHkSlnR3hDi3VVGFzioTU
 Wny.3vQ0P5_yPIiTxQXKJvm4qPyt.I6IHK_0CGw72BiCk2q9stxn63RThxAlxjYCZjGObO46Dhlj
 iXBshIpNI6AoT4ZsY4yAggPwmENl1xyvFrY1dcVegtU78XtkosIQDaCDW8_sCns0w31mb0SLiRQQ
 J2eMNmXudZhaP2q7qysSEPRQJ5zKFBH6Dle1x3objW8DfcTfoq4rY84MavNa_IPQdT4oLyVUfgDn
 b_qfbZBgj581kp9QvmyDi1c9qq12MLqExFlvQ9i2xyv50cegZvwoUrS8LC_F8T0OBpZr8wRZV5G_
 hFh1LOCfpCmISlsZ0o1dVPCrwVWmCz3VMdEVstuGNDIunNSqeO6g_d09wfXDx76OVwf9gy.PADfX
 exRXvuOYQiGSHrD9gl6vHwNa_qmr0NG8VQt2HWSRwRZi3xtAEzpJxLDGnGYD.uRiiLTjHa_0wKbV
 eoRSn4.OKBhndE0C9QouhmVwicGVGxyZytAGbqhB6zqnQV0YCglts3F3HV8kR4qWZIpexOyqG.qF
 jHNAN5VC04QE8NCNbmMiFNJSoANJSVV_WDGzg0X4YtaKWzIEAyVEszeXxMbsFN3lGnv5j3mF_BxQ
 dCi1xxIx27VLZB0kXJwctBYhasIyT.g.UoFXJuHhB02akLtihezi_JcYkKQUMBc2A1w03PUixsms
 MrKSowEc5JvkjX13Xyk46TRHeOMeMtgwSAkiVWjo4ldd9yEZ.vPtVHjP26ob1dN9Eg1QjxYeiqDA
 9bSRPAUJKyun20RL8P.8YRA.Ohp6CB.WFHoWhm_v0uyGgYTIWhdqoSeBTm2t4ydX4rpBNoYYM6m3
 9H4g-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Jul 2022 06:45:45 +0000
Received: by hermes--production-gq1-56bb98dbc7-28prh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2f74c6f4928df2986b0e57e4ef4fb5a2;
          Sun, 17 Jul 2022 06:45:42 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: 
Date: Sat, 16 Jul 2022 23:45:41 -0700
Cc: Warner Losh ,
 dev-commits-src-main@freebsd.org,
 "Rodney W. Grimes" ,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
References: <84410D65-6F86-44E5-8B14-8A523C9919C7.ref@yahoo.com>
 <84410D65-6F86-44E5-8B14-8A523C9919C7@yahoo.com>
 <20220713201327.GY30607@FreeBSD.org>
 <7F4F9683-B4DE-4F65-BBD7-027039A0C270@yahoo.com>
 <20220713204227.GA30607@FreeBSD.org>
 <8A02A4A4-9F3A-47F2-9985-EA2151043BB7@yahoo.com>
 <4D903E5A-58FB-4516-AC53-AEDFF48564A7@yahoo.com>
 <20220714152125.GB30607@FreeBSD.org>
 <3E2DCFBD-CC8F-4C13-B18C-B7DA26ED8E84@yahoo.com>
 
 
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LlwbG6FG8z41fN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=TRVNlIII;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.38 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.89)[-0.887];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	BLOCKLISTDE_FAIL(0.00)[98.137.68.82:server fail];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-16, at 23:24, Mark Millard  wrote:

> On 2022-Jul-15, at 17:41, Mark Millard  wrote:
>=20
>> FYI for the new snapshot build of 13.1-STABLE:
>>=20
>> # mdconfig -u0 -f =
FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img=20
>> # gpart show md0
>> =3D>      63  10485697  md0  MBR  (5.0G)
>>       63      2016       - free -  (1.0M)
>>     2079    102312    1  fat32lba  [active]  (50M)
>>   104391  10381329    2  freebsd  (5.0G)
>> 10485720        40       - free -  (20K)
>>=20
>> So: still has the 2016 and 2079 that do not seem to match
>> what /usr/src/release/ materials would indicate --and the
>> 2079 leads to poor alignment for a microsd cards, for
>> example.
>>=20
>> But, at least something was produced this time. There is
>> now a 13.1-STABLE snapshot to test the handling related
>> to the new UFS/FFS superblock validations.
>=20
> In the live build environment that makes the images,
> what is:
>=20
> # sysctl kern.geom.part.mbr.enforce_chs
> kern.geom.part.mbr.enforce_chs: 0
>=20
> I ask because of the description:
>=20
> QUOTE
>     kern.geom.part.mbr.enforce_chs: 0
>             Specify how the Master Boot Record (MBR) module does =
alignment.
>             If this variable is set to a non-zero value, the module =
will
>             automatically recalculate the user-specified offset and =
size for
>             alignment with the CHS geometry.  Otherwise the values =
will be
>             left unchanged.
> END QUOTE
>=20
> In particular, the text about non-zero values leading to:
>=20
> QUOTE
> the module will
>             automatically recalculate the user-specified offset and =
size for
>             alignment with the CHS geometry
> END QUOTE
>=20
> This sounds like a potential way to not end up with the
> what the /usr/src/release handling requests for the
> small board computer images. It might explain the
> mismatched alignment that I've been reporting.

I tried it locally and it reproduced the problem alignment:

# sysctl kern.geom.part.mbr.enforce_chs=3D1
kern.geom.part.mbr.enforce_chs: 0 -> 1
# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63  6291393       - free -  (3.0G)

CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart add -t'!12' -a512k -s50m =
-b1m md0
md0s1 added
CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
       63     2016       - free -  (1.0M)
     2079   102312    1  fat32lba  (50M)
   104391  6187065       - free -  (3.0G)

Note the 2016 and 2079 (instead of 1985 and 2048).

Reminder of the old result, reported before, that
implicitly had:

# sysctl kern.geom.part.mbr.enforce_chs
kern.geom.part.mbr.enforce_chs: 0

as its context:

QUOTE
# truncate -s3072m mmjnk.test
# mdconfig -u0 -fmmjnk.test -x63 -y255
# gpart create -sMBR md0
md0 created
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
     63  6291393       - free -  (3.0G)
# gpart add -t'!12' -a512k -s50m -b1m md0
md0s1 added
# gpart show md0
=3D>     63  6291393  md0  MBR  (3.0G)
     63     1985       - free -  (993K)
   2048   102400    1  fat32lba  (50M)
 104448  6187008       - free -  (3.0G)
END QUOTE

Looks to me like the environment that uses
/usr/src/release to produce Small Board Computer
images has:

# sysctl kern.geom.part.mbr.enforce_chs
kern.geom.part.mbr.enforce_chs: 1

and this is leading to the misalignments for the MBR images.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 17 17:08:01 2022
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 4LmBPR0nVRz4Wnd4
	for ; Sun, 17 Jul 2022 17:08:11 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LmBPQ64bgz3xx1
	for ; Sun, 17 Jul 2022 17:08:10 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26HH81RE062304;
	Sun, 17 Jul 2022 10:08:01 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26HH81bA062303;
	Sun, 17 Jul 2022 10:08:01 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
In-Reply-To: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
To: Mark Millard 
Date: Sun, 17 Jul 2022 10:08:01 -0700 (PDT)
CC: Glen Barber , Warner Losh ,
        dev-commits-src-main@FreeBSD.org,
        "Rodney W. Grimes" ,
        "Dr. Rolf Jansen" ,
        freebsd-arm 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LmBPQ64bgz3xx1
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> On 2022-Jul-16, at 23:24, Mark Millard  wrote:
> 
> > On 2022-Jul-15, at 17:41, Mark Millard  wrote:
> > 
> >> FYI for the new snapshot build of 13.1-STABLE:
> >> 
> >> # mdconfig -u0 -f FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img 
> >> # gpart show md0
> >> =>      63  10485697  md0  MBR  (5.0G)
> >>       63      2016       - free -  (1.0M)
> >>     2079    102312    1  fat32lba  [active]  (50M)
> >>   104391  10381329    2  freebsd  (5.0G)
> >> 10485720        40       - free -  (20K)
> >> 
> >> So: still has the 2016 and 2079 that do not seem to match
> >> what /usr/src/release/ materials would indicate --and the
> >> 2079 leads to poor alignment for a microsd cards, for
> >> example.
> >> 
> >> But, at least something was produced this time. There is
> >> now a 13.1-STABLE snapshot to test the handling related
> >> to the new UFS/FFS superblock validations.
> > 
> > In the live build environment that makes the images,
> > what is:
> > 
> > # sysctl kern.geom.part.mbr.enforce_chs
> > kern.geom.part.mbr.enforce_chs: 0
> > 
> > I ask because of the description:
> > 
> > QUOTE
> >     kern.geom.part.mbr.enforce_chs: 0
> >             Specify how the Master Boot Record (MBR) module does alignment.
> >             If this variable is set to a non-zero value, the module will
> >             automatically recalculate the user-specified offset and size for
> >             alignment with the CHS geometry.  Otherwise the values will be
> >             left unchanged.
> > END QUOTE
> > 
> > In particular, the text about non-zero values leading to:
> > 
> > QUOTE
> > the module will
> >             automatically recalculate the user-specified offset and size for
> >             alignment with the CHS geometry
> > END QUOTE
> > 
> > This sounds like a potential way to not end up with the
> > what the /usr/src/release handling requests for the
> > small board computer images. It might explain the
> > mismatched alignment that I've been reporting.
> 
> I tried it locally and it reproduced the problem alignment:
> 
> # sysctl kern.geom.part.mbr.enforce_chs=1
> kern.geom.part.mbr.enforce_chs: 0 -> 1
> # truncate -s3072m mmjnk.test
> # mdconfig -u0 -fmmjnk.test -x63 -y255
> # gpart create -sMBR md0
> md0 created
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63  6291393       - free -  (3.0G)
> 
> CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart add -t'!12' -a512k -s50m -b1m md0
> md0s1 added
> CA72_16Gp_ZFS aarch64  1400063 1400063 # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>        63     2016       - free -  (1.0M)
>      2079   102312    1  fat32lba  (50M)
>    104391  6187065       - free -  (3.0G)
> 
> Note the 2016 and 2079 (instead of 1985 and 2048).
> 
> Reminder of the old result, reported before, that
> implicitly had:
> 
> # sysctl kern.geom.part.mbr.enforce_chs
> kern.geom.part.mbr.enforce_chs: 0
> 
> as its context:
> 
> QUOTE
> # truncate -s3072m mmjnk.test
> # mdconfig -u0 -fmmjnk.test -x63 -y255
> # gpart create -sMBR md0
> md0 created
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>      63  6291393       - free -  (3.0G)
> # gpart add -t'!12' -a512k -s50m -b1m md0
> md0s1 added
> # gpart show md0
> =>     63  6291393  md0  MBR  (3.0G)
>      63     1985       - free -  (993K)
>    2048   102400    1  fat32lba  (50M)
>  104448  6187008       - free -  (3.0G)
> END QUOTE
> 
> Looks to me like the environment that uses
> /usr/src/release to produce Small Board Computer
> images has:
> 
> # sysctl kern.geom.part.mbr.enforce_chs
> kern.geom.part.mbr.enforce_chs: 1
> 
> and this is leading to the misalignments for the MBR images.

Very nice digging Mark,
Perhaps an assert for kern.geom.part.mbr.enforce_chs not
being zero in /usr/src/release scripts is in order so that
the builds blow up rather than produce BAD images.  Just
becuase this gets fixed on the projects systems does not
mean some user running release builds can not stumble into
it.   Please Please Please!!!!

Again, thanks for digging down to atleast this one
potential cause!

> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Sun Jul 17 18:46:08 2022
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 4LmDZZ4Qp1z4X1Z1
	for ; Sun, 17 Jul 2022 18:46:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LmDZZ3DpXz477V
	for ; Sun, 17 Jul 2022 18:46:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658083572; bh=v0ihfuLGDiib8XNW/cAjXAfl2BIAbCfcOyU4cnaa9bA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oga/bJrlAAEBXj6LpSs5buR9uMyfdNeMN/3NCma3e1Jjd2xrxXm7qVz3K/zDVLn5+1xLLdqFEJrDV2svDAtNnbq+QFp1prs53HSzYaBBUj2OPify5pjc6EZtmUMNQmo3BZ5sG5pc5DMENOb+uh4ZhghDCueQugW1QD6Siry86b+ZWzjpliBGoJiaCKWJ1W+m2+ZIQrPkBiiK53S0gY3xc56z8sE7lEHv9O5rx5wbjiSmiXNNr/z7zTi7Im3HuozDOcFyaky6+6YWLqHvA/qkkqivBSyBT5decMeyy+B2MQT2Y2cdPQjgESCyp+0jI060cxHl80E9pYztULYx+fGKIw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658083572; bh=JQDT2xqzEeIEzf+v32QPS1jkev1DRE37Bg7gQdzYIPD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Pgn/kn6u1p40GWhO0VcK9pP2FyicDU38Svn6vZcxogYLvda8SDpZa6Fqzph3Cd3TohUjasqltm3AGkjQwPpfofjvNzEz6N43OTycq5fzAf7pKlsfw0q3eVxHQ84gtp1lCylIxwpSDOwpZLBXkrjUZvGUKlE2tE4fER3fk3do+hAcBrsYAUWuCx3asgFe3Vjy98EmqhGS4Lb0c4CJ9WHyESTmdBDtr1el54KhEYCsBsLWKx7xGFqTETQVdWbzXXlZVY+c4Dy/uubwEJrgpZqZWjVvrr6tFkRdbD14lTUxtRSu2FXrgUrTYdD80gD6uq0X7/xUbbm2Ug9tgQ7jSPRxTw==
X-YMail-OSG: dd4I0PcVM1mnoekpYyxsFPWKayHrspfEMebwqQoh9g1aSbSxXi2v.x8roNqGDfG
 KmStk3QcgUA5V0YfznMECJX1_RAK6YVz6Bu9c0U6BYMCa3.Wpe6zoCpVOEGl4Ri9SmxRMSUEet1P
 X5PfVc2F3RoH_hNSghPPXnB5vQL.wlUI0_DhkRPgQ5be5B8Er727.i47fWCJeoDUdIpL4h_EKnDX
 xIoVB3B8LMJEXc19vdwANJ40zVwTs6s53vL2oSZwq0Soha0Vm.kR5ZT6l5z1jjxPu0v7deq0Xlx1
 .0vy3FRpCIOb9aIUrWwVFkXyoXtTI5uE3cJVPGjlSu5FOrMunyL9pRYKKLXkxdK6ETfeHMGfnwH7
 vTSZ.nFa60yVRTbLVrXqFAchpbVr3WeRHZUiCcJ7feBHFeKJewOtYiddomzZ2pPFsFXkgd_nUwAK
 GY.9vXYDXxJXMt9TRQtXa9CkkqlHKjfuyvMV93loyE1ML2woNa.jbdfeumybJRrvpjHqemzjvJwk
 JkGAU13pZF2XIp3Ar5hftVGXItj9WqpI5YyqkJAaaeF60LwZgc2RC1FnBqnMj46R9MTOYj5cTg8K
 LuD0mueybDVqrmIeF_ojeFl.G5gflICpC_FR5w0dcONeZGdmHncCov5UagyYoQAlMOkIBfA0Q3dk
 v.HOXkWlCIDzgVQQPhS7yLhgCtjLn2qjBlWq5SiAFGlrV1ZXmhVKuNgfoGuHZ2kmqNcSdYdGrafC
 UxtosQ3wcrQPou3S2X3Gq8xHgB7dS2CqsZ3j8aw.EnsZcFEs08EoSZ9JK6J.I88twBAI74sQqIs5
 cW5bewfjZBlzb59gSncQ2WtCcm2VfWld9jwfsXe0MmNggs53Gf8flodWEIKx.gU5kXVayBOyAqQG
 tmZ8wc01t2xq3r3uQxEM9YS6fxCD4wgcy6GNjKW3tzD7ld5ZKJT1Ju538NpbKTRlN__5Vpvd25s_
 N52sIWFCtMh.RPftK4yNt1YmVhwxqG1zKxCcFj_1WaOVB3QW2_XYN2jTsEnX8VlZBwzlKyhi9mtd
 irZzq_gI0c1eZh9XBYJ.czR9naenvzn3RMFf7YYiLKhFQT5tLWDhdOFucRmGLQu1ROP4mabYFdFh
 PGobF_GXRwJc584XB_zUJCWw5e49y6z8VXvE6UuyQqXpliyDxZcO_5MobX.bXt1bod_hjmK2lDG9
 qZv2kEWTAqIr38yazvCOZOK71RR_U4P3SDBL_aQjwZoMYgKaLmE2P8OfBX5auP1NyLb9GbT5Ya.v
 lWUSt.m99LGzrF9ioKFyZWSCVjOr52UdWkhaSjFdVFuXzA_h5Ij5fTAMATU._1lv35HqYM0H16tu
 u3us4TZDZ62xVgUosXlrZdFUs1vuaXqzIknnzDm8aQnSJF_5pmPDikFm3owZP6CIPzVu9Z3hjD9J
 I2yWkjqKpcs0OJTG5._hLBU_TkTLTgKqYAXgj.XfXldUJiEfxfjvcdulk7NQ1ceaqxjSsHZQZ2_8
 njA_lgknsh0n.kS5XQUnZPWXhlWHttbFQP.kJqHkISQrXC_ulfDsYM7ogu8qy6322hYna9I3JSnN
 5N5enRkvTbIXKTn7Xh946HDuIOIFEgArA239qWYoaZLzD95OIIZidg0DcDgBEGIzEu7QZFO6Gx6e
 EXHKyCyGXJPvn1iQ5QWmaST4BPaH_F8BIKNWTKKbQ1MkzEMO8E4uK8na8jDyGwGfU04D.owZAVKh
 MP7ujMRAcPVswjWsHBz0.973wXwN4ejWHkWwlfHQn3afOcycXAFCBDHD2Mbc_IA._tyIySD72TI.
 D4mTLN97A2NGDMwhpaUCfiq_kQOK6BdeqAFgYEUQBwyf8ENqWjWb4.qJ9hVI5gS7cPKnabfg4DWv
 GnIQyBpQ6XtMlUPQicZ2EXKSvz2fkYrzocVg3yIA1JaspGQ36OvC5t_8weJnJFZ8q8Ptt5iDjm8f
 eTswNqYvvXenxIon3HuQo1GEwEMfk2TsTBjaXmoMHNn_QTQm6BEP7Z03OgUz8wzqbLm2_j76FdH9
 s4597fE1rCU7VNRt.R4F1i1DvM31YRtQVQmb2p7ESRrybj.m50ACsKpTF3iDTb4tvU4bX_c21BNE
 b51GPUHF2EiTLCqsLRoMb2Q3MV86y8lX0FzzQbAeWvcQK0_ZNN2kmxJ.zwqLH1ouJbmZ1k9H0QGH
 i77O9ZkCo_AzmilY7Js1gOJIM7XAfWfJnujwdslkypvutDMWRScnAX_Cy7JXEDos4UTfkfnGmpxd
 yFwHLidc5AdwWrF1BwGqdq0iQ3ZY0IM35GAe_96wylV01zAqR5TVLp2I9aGCt7TFIhZMfzcPdkGZ
 olFxWY3c-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 17 Jul 2022 18:46:12 +0000
Received: by hermes--production-ne1-7864dcfd54-5p9s9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 322e3e7f0e20eab5731ebbe0789df5fb;
          Sun, 17 Jul 2022 18:46: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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
Date: Sun, 17 Jul 2022 11:46:08 -0700
Cc: Glen Barber ,
 Warner Losh ,
 "dev-commits-src-main@freebsd.org" ,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
To: "Rodney W. Grimes" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LmDZZ3DpXz477V
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)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-17, at 10:08, Rodney W. Grimes =
 wrote:

>> On 2022-Jul-16, at 23:24, Mark Millard  wrote:
>>=20
>>> On 2022-Jul-15, at 17:41, Mark Millard  wrote:
>>>=20
>>>> FYI for the new snapshot build of 13.1-STABLE:
>>>>=20
>>>> # mdconfig -u0 -f =
FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img=20
>>>> # gpart show md0
>>>> =3D>      63  10485697  md0  MBR  (5.0G)
>>>>      63      2016       - free -  (1.0M)
>>>>    2079    102312    1  fat32lba  [active]  (50M)
>>>>  104391  10381329    2  freebsd  (5.0G)
>>>> 10485720        40       - free -  (20K)
>>>>=20
>>>> So: still has the 2016 and 2079 that do not seem to match
>>>> what /usr/src/release/ materials would indicate --and the
>>>> 2079 leads to poor alignment for a microsd cards, for
>>>> example.
>>>>=20
>>>> But, at least something was produced this time. There is
>>>> now a 13.1-STABLE snapshot to test the handling related
>>>> to the new UFS/FFS superblock validations.
>>>=20
>>> In the live build environment that makes the images,
>>> what is:
>>>=20
>>> # sysctl kern.geom.part.mbr.enforce_chs
>>> kern.geom.part.mbr.enforce_chs: 0
>>>=20
>>> I ask because of the description:
>>>=20
>>> QUOTE
>>>    kern.geom.part.mbr.enforce_chs: 0
>>>            Specify how the Master Boot Record (MBR) module does =
alignment.
>>>            If this variable is set to a non-zero value, the module =
will
>>>            automatically recalculate the user-specified offset and =
size for
>>>            alignment with the CHS geometry.  Otherwise the values =
will be
>>>            left unchanged.
>>> END QUOTE
>>>=20
>>> In particular, the text about non-zero values leading to:
>>>=20
>>> QUOTE
>>> the module will
>>>            automatically recalculate the user-specified offset and =
size for
>>>            alignment with the CHS geometry
>>> END QUOTE
>>>=20
>>> This sounds like a potential way to not end up with the
>>> what the /usr/src/release handling requests for the
>>> small board computer images. It might explain the
>>> mismatched alignment that I've been reporting.
>>=20
>> I tried it locally and it reproduced the problem alignment:
>>=20
>> # sysctl kern.geom.part.mbr.enforce_chs=3D1
>> kern.geom.part.mbr.enforce_chs: 0 -> 1
>> # truncate -s3072m mmjnk.test
>> # mdconfig -u0 -fmmjnk.test -x63 -y255
>> # gpart create -sMBR md0
>> md0 created
>> # gpart show md0
>> =3D>     63  6291393  md0  MBR  (3.0G)
>>       63  6291393       - free -  (3.0G)
>>=20
>> ... # gpart add -t'!12' -a512k -s50m -b1m md0
>> md0s1 added
>> ... # gpart show md0

[I normally strip out long shell prompts but missed the
2 that had been above.]

>> =3D>     63  6291393  md0  MBR  (3.0G)
>>       63     2016       - free -  (1.0M)
>>     2079   102312    1  fat32lba  (50M)
>>   104391  6187065       - free -  (3.0G)
>>=20
>> Note the 2016 and 2079 (instead of 1985 and 2048).

I'll note that I've no clue if the 2016 and 2079
results for kern.geom.part.mbr.enforce_chs=3D1 are
correct/appropriate vs. not for the context.
"-x63 -y255" was listed in the mdconfig command.

I'm just reporting what results and that it matches
the odd SBC image alignments in snapshot and release
images. There could be more to it.

>> Reminder of the old result, reported before, that
>> implicitly had:
>>=20
>> # sysctl kern.geom.part.mbr.enforce_chs
>> kern.geom.part.mbr.enforce_chs: 0
>>=20
>> as its context:
>>=20
>> QUOTE
>> # truncate -s3072m mmjnk.test
>> # mdconfig -u0 -fmmjnk.test -x63 -y255
>> # gpart create -sMBR md0
>> md0 created
>> # gpart show md0
>> =3D>     63  6291393  md0  MBR  (3.0G)
>>     63  6291393       - free -  (3.0G)
>> # gpart add -t'!12' -a512k -s50m -b1m md0
>> md0s1 added
>> # gpart show md0
>> =3D>     63  6291393  md0  MBR  (3.0G)
>>     63     1985       - free -  (993K)
>>   2048   102400    1  fat32lba  (50M)
>> 104448  6187008       - free -  (3.0G)
>> END QUOTE
>>=20
>> Looks to me like the environment that uses
>> /usr/src/release to produce Small Board Computer
>> images has:
>>=20
>> # sysctl kern.geom.part.mbr.enforce_chs
>> kern.geom.part.mbr.enforce_chs: 1
>>=20
>> and this is leading to the misalignments for the MBR images.
>=20
> Very nice digging Mark,
> Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> being zero in /usr/src/release scripts is in order so that
> the builds blow up rather than produce BAD images.  Just
> becuase this gets fixed on the projects systems does not
> mean some user running release builds can not stumble into
> it.   Please Please Please!!!!
>=20
> Again, thanks for digging down to atleast this one
> potential cause!
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 17 21:00:52 2022
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 4LmHYx3smvz4T5xf
	for ; Sun, 17 Jul 2022 21:00:53 +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 4LmHYx1kF8z3RQN
	for ; Sun, 17 Jul 2022 21:00:53 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4LmHYw6xdPzDrD
	for ; Sun, 17 Jul 2022 21:00:52 +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 26HL0qgx045032
	for ; Sun, 17 Jul 2022 21:00:52 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26HL0qGg045031
	for freebsd-arm@FreeBSD.org; Sun, 17 Jul 2022 21:00:52 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202207172100.26HL0qGg045031@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, 17 Jul 2022 21:00:52 +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="16580916526.D084e.42306"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658091653;
	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=wuSuOkVxqvKtfIhbfi1KrijYpzLpKLgqp7aVs2YqmjA=;
	b=v/3Jn+g6cZLOHLykIGU1y8Y31FBAG75FjpManevg0pd2j4JuauKpQMmVa0VFPyU24PjVHF
	KiOJDZScak/pOi6yrQK59fNGZr/+b+zYeVq33W7ocLI3p3+kr7wDaEHisYBRJSAuo2ntBZ
	uk5UmjJ9afr93sOw5csWdfJ8V78S+vWGzI5cG3E4TW9Nn0lLOw8/1MgxDgYz1VngqtshZG
	XMtYkvXgJuSbEsb6EDCvhwITVIyga6I1UQjNTp+GiWcJLf7mrmBdbhCjTHKH3uzBDfvp7v
	/884yC99T8gt0B83oaM0upCDTaA2LmVoAPZRxSpUgUD/k+Fe43Iv9RlEgO2PoA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658091653; a=rsa-sha256; cv=none;
	b=kNB4tb1pfpBckHoCeWc9gpZcvYonbBqu5U9x0smg9Kn7O8jN/t7IFjs3FIkywNyJZmgFG0
	BsqtTlWBWCX53wkBIvCVc37MVsBhsdpuK0xiXngk/Gf16V3V/TDqqjz9LoJ9thfU/VLWrN
	UFVSSKx1Twu1urg8WXPWp2EgFszv1E3ilGhwj7nuBSAnqPgaek5fvZIPzZmEburuQySQxS
	mlK3N/zAqwkncYZF7zmdcpXEj0gWbK1J+mlaAuAoPCw7SSmojQ9DMIzm+ayTs6yNtRjNZm
	IKslpipVpjm4ZVEWs4x86RnFUdA7VUqJzMJTXqOhY2Lg/Iq0uCQ+jF8veGTseg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16580916526.D084e.42306
Date: Sun, 17 Jul 2022 21:00:52 +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.

--16580916526.D084e.42306
Date: Sun, 17 Jul 2022 21:00:52 +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.


--16580916526.D084e.42306--

From nobody Tue Jul 19 20:35:36 2022
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 4LnVw73lkQz4X0md;
	Tue, 19 Jul 2022 20:35:51 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48])
	(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 4LnVw63MJrz4QLM;
	Tue, 19 Jul 2022 20:35:50 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f48.google.com with SMTP id z23so29409504eju.8;
        Tue, 19 Jul 2022 13:35:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=/w+G9yN0XfU6xm0/rIyncP46gaeXu6c7Hk1jK7m4nRI=;
        b=m1Q1hAmIesT3a6SPoS/6UEK2UfR0Mjl8c5KWua3XxJt7ErvqL/o2gV0j8b2FiWYDpe
         ANFFADltWvruFlAtA41pQOrGTREf2t5Te44BH42cddcIymxAQpDND1N/7Rwzo93W4gJf
         hb0yaQjZew6KoVU0sbjHqPiruxKsDCH952LJa2/zJ3SvtJFG+WVrT45bD4leyIyHyJg0
         Ei0RiZ5YVf+El1gRPYEYBguM9xDIwLIBJujscqQZBboouv2Xu9dzroDDvCXpTYw6Ak05
         B//FcclKA8XUPPHdqXfcX0j4SYZ24RQGQ4uZMBJTy65bJhStk8Sz+AreDGmxxnInI3ty
         22MA==
X-Gm-Message-State: AJIora8bTbegtVdcyC3eooY8maxGZrJGXR5Tw29cZDjuBpZr1wdj+R0v
	a5Knbuc8b3fUZjLjBIEjaWYZZxmcv1OAPLMMK9w=
X-Google-Smtp-Source: AGRyM1tJubQQy4BW0nkMYz4SHiol328DqLtRY/cPplibGlgrfHDirBccm0YgDr9TpuATDg4EmiaSu1f/jjqju2DeRGM=
X-Received: by 2002:a17:906:ff48:b0:72f:10c:bb3f with SMTP id
 zo8-20020a170906ff4800b0072f010cbb3fmr21198024ejb.718.1658262949089; Tue, 19
 Jul 2022 13:35:49 -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: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com> <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
In-Reply-To: <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
From: Ed Maste 
Date: Tue, 19 Jul 2022 16:35:36 -0400
Message-ID: 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
To: "Rodney W. Grimes" 
Cc: Mark Millard , Glen Barber , Warner Losh , 
	dev-commits-src-main@freebsd.org, "Dr. Rolf Jansen" , 
	freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LnVw63MJrz4QLM
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
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)[-0.996];
	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)[dev-commits-src-main@freebsd.org,freebsd-arm@freebsd.org];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.48:from];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.218.48:from];
	RCVD_TLS_LAST(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCPT_COUNT_SEVEN(0.00)[7];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,bsdimp.com,cyclaero.com]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes
 wrote:

> Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> being zero in /usr/src/release scripts is in order so that
> the builds blow up rather than produce BAD images.

This is a good interim step (before switching to mkimg).

Perhaps:

diff --git a/release/tools/arm.subr b/release/tools/arm.subr
index 77b708bca4a2..94e0ee89deaf 100644
--- a/release/tools/arm.subr
+++ b/release/tools/arm.subr
@@ -62,6 +62,10 @@ umount_loop() {
 }

 arm_create_disk() {
+       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
+               return 1
+       fi
+
        # Create the target raw file and temporary work directory.
        chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
        if [ "${PART_SCHEME}" = "GPT" ]; then

From nobody Tue Jul 19 20:42:45 2022
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 4LnW4F0RqHz4X1Cn;
	Tue, 19 Jul 2022 20:42:53 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LnW4D72Cvz3CHb;
	Tue, 19 Jul 2022 20:42:52 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1658263373;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=tt8J8a1tGH7+XB0PM+8W+qvV8DAqtVVd8oP/omb2Y1g=;
	b=W4Tz9c57268KU2ABTiafXZ1F1NxNdtej4mSz/w3nWd8pTg3XFAuDDs8g5/TaeZ/24HzfOK
	cUYlLfqXY/fTNFyE9iGlMXkxH2X9HnOAmdzPRt8NN+G75hRkyn00nL5nbMX/9tmJyn5sHr
	Nhd76TqbWV5VnMpu8urm87JwSd4GwfYKjbXcilee5T5rXHLcSIpuS3BWwSm+3m33Vxf1ce
	8uluAEfsGWCgvXRmiZIZoq+4h0y8mgsabXx7MaiDr5D3JGiYoB0nL5ahhUuVmy3mh+TpUY
	Iw9TsbVjeZaLgMBlJ1rZgQ7Tx5DRifBYcyLTsZkcbbEj3ZdxKdd9m3c0kaSlVA==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id 47A1F18472;
	Tue, 19 Jul 2022 20:42:52 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Tue, 19 Jul 2022 20:42:45 +0000
From: Glen Barber 
To: Ed Maste 
Cc: "Rodney W. Grimes" ,
	Mark Millard , Warner Losh ,
	dev-commits-src-main@freebsd.org,
	"Dr. Rolf Jansen" ,
	freebsd-arm 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
Message-ID: <20220719204245.GL30607@FreeBSD.org>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="N5vNW3dQ2P5lHuuL"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658263373;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=tt8J8a1tGH7+XB0PM+8W+qvV8DAqtVVd8oP/omb2Y1g=;
	b=NBQT+vhK86Shpq2hYzY3ByhJLA0t2oiRiHJ26/nYRFmxJr1fiTUcNqReRQmR0UfvZg/j0K
	L11u8TwH1lRHxdp0tTst9K43+CVExzDB1c9O116L7NDd+U1glfWOjjPXYzEHrnx32SNU1C
	fTmp7LR7cgTk/sploNdhRrnyqnGYwXLEPmFtFtbwb5KRk4jwJjSV3ySq3ncXS2hDJGp4CZ
	9jGJgBnJFeDjLonETvYMbE3PssdJcqQiKBqAeznisVuZfshnKpzVCF7/BbjiaxJ4IJhOlI
	UA3Aaz0XWTSiVbnuW3QN0YpudYQEsU+Nz4RaF3vySoFrMSfcS49HluIimdVL2A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658263373; a=rsa-sha256; cv=none;
	b=VwAQm5VnUP/VJ5447RodYrm4Hr3tcm21d78ND1fYANTFAX7J/F8R1yFjUGddtIKrtcNG46
	bWLgWttRXA1WXwW7oAjDvh2LYTVpjHtButuuaqhUCRSPei/bnJx3Bd6TXeGla88JdLqX1R
	GFuiziDtPpJE7QjWmY+n7PSKw438lFzRzIS9kvdX9S75RZdfoqcS9dxTgxV/Ma3sia6k8u
	oIUBAjJL4pWWUqDjmrqRWDpACdYdkxBMLtA1SxP+4X/eJtjrUD7gKxecVpD9RvvAerYSdk
	huuLNjFNVyaxgOWvi/nfincbd9oQMqQTFMIsDCvtfG75ML3PucjNkbdx86o6jQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--N5vNW3dQ2P5lHuuL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste wrote:
> On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes
>  wrote:
>=20
> > Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> > being zero in /usr/src/release scripts is in order so that
> > the builds blow up rather than produce BAD images.
>=20
> This is a good interim step (before switching to mkimg).
>=20
> Perhaps:
>=20
> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
> index 77b708bca4a2..94e0ee89deaf 100644
> --- a/release/tools/arm.subr
> +++ b/release/tools/arm.subr
> @@ -62,6 +62,10 @@ umount_loop() {
>  }
>=20
>  arm_create_disk() {
> +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; then
> +               return 1
> +       fi
> +
>         # Create the target raw file and temporary work directory.
>         chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
>         if [ "${PART_SCHEME}" =3D "GPT" ]; then
>=20

My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
the builders, which effectively means all arm builds will fail every
time.  I think we need to get to the actual root of the problem here,
versus applying band-aids to a shark bite.

Glen


--N5vNW3dQ2P5lHuuL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLXF0UACgkQAxRYpUeP
4pP0Xw//dXvzRH/1zx6wY1RT/2R5sGBlwnfrPdeeqH35cC7OJqWiwe3O3ZarDO1D
Z7LNQmufk4vKAJZNhZQFljbCCoHUNttc4p8uycBI7FYDDDscRGiZOcVW7t2c5qEx
pqR9cSOHzptBbcjlSNh8iMBy4/8uDPlmcPV4ziLkH5+tQYIjNjoCZ/9fECy4eHRP
SubclHPx9e9ZKqqTd86Iry3MUdgNI8B8x032RRUPAmIzgiLo1fEhdDY/tzTrqIvj
usOS+XOLRRTNNWw1oL2+thDVscsXE4cpJjZ7+5xElssUQG5upKVOg+zNnStAJmtC
IodWmEb8rasyo5I3Ho/ILLo5Rw5o1jIk4cAeGhfWgP+OBviq+6SGSq83PKD4f92X
zHzW+aqSDOZSZNTRwg2/nUoNVsl22IVX5G7QkNacOCcBZMZ0iLTLkRcXtOe2cVlZ
8Yp9WuJnCmZPe8J5j+x8wt6wcD93VnlCbhNfYE4+z3ZXoMVacAad5SeV5jWTX/b8
4sODcOqQsPUQwXsqby0P0+DB52G3EzneF6xTm2iFB/mVo84q6zw8qrXyw371RlG9
DxJL+x7EZSM7rZ3jutoDxEQGrdf95D4zv5GdP2qhYFMD8DVVqutbzV7twnrx2goS
Bolo0Y9XbJMgg25xw8FXecJ5YxQRWtpnnLoSqIeUmq/TCcd7+zE=
=izbc
-----END PGP SIGNATURE-----

--N5vNW3dQ2P5lHuuL--

From nobody Tue Jul 19 22:45:13 2022
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 4LnYnf5yftz46lZQ
	for ; Tue, 19 Jul 2022 22:45:26 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c])
	(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 4LnYnf0cP3z3P21
	for ; Tue, 19 Jul 2022 22:45:26 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2c.google.com with SMTP id 125so4374582vsd.5
        for ; Tue, 19 Jul 2022 15:45:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=7IT3NKuZrf7x70WMY/wDvkQk3POtLJG6Cru2ya/2fQg=;
        b=jfhVWJkUy35znES0bxAfHWb6CRu2c2y18DMHUz+tcNrMUrkfhYvZGxVB+XSFMt2kSC
         qZbB22arKHqCLqHkB9H2UPCxEqKFSg7hhpaKLlzp/DGLrSblDfzu9wQtZeT7eUv4IgwB
         bwW8BAyBaXH08GYuZfpLjq0l36z3ldZDTgKKUyHvFVGG6UN0i7JvMSIyxftza4rfkwf1
         jbSbbovJGFOc4oVqn7rg9i4zUF0vhuR3kuxaYspx0WVzo0RET6O43UFpyYl6DdwqLCjj
         BHbG9JAtjfepOLJJv04E5JfIjxELphtgfNJii3GAolMM7xxHvd7PlgyGAj/h0Hgaj/C8
         d/Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=7IT3NKuZrf7x70WMY/wDvkQk3POtLJG6Cru2ya/2fQg=;
        b=yLYb59+FxKcHYFWs9vCTsUSX8HEgTu/VmMe4ZyA7SayodqEdKFGA52pZQDlyrgLNsI
         E+nV3PBJXpg75y06bCBDHqL8G8rxeQIx/HzkLgMmT8rsi62aQ9mjvJ9BVqEbgPQphq+W
         9qRdQmSfk1eOiIhHhIem62bhEw79uxVKR42jN5W/kgOgcxOYNyV3DGpzxUCdXWnu8LmX
         gepdGaoYV8YnBW6GysCRLUFlKFLfZ8+P3MrgmfuS55wvn6nAsHFT13nXN2AWeeKJaTUo
         ZcGuTXg/2yFnU1X91HX4jBq/mLSZJw10te3qAlZvvn3loCvcIsDHfVGe/KbHJHzcJWQS
         WN6g==
X-Gm-Message-State: AJIora+fO+wtKK/JdgfXALCSJ3ehB/W6s1TyDhna99Whr0mzuR1ALQN4
	qTjqVXF4Us3eDyBlxKnpdwcCmVLyHqYPh15aidbABw==
X-Google-Smtp-Source: AGRyM1tLqaDHYBoaHfon0wh94tTiRaPaa0KjTRs0k+ICaa7ABQrH+YHmfc9LSv8YJHLAe24TM5rXAUHrJ69yoVgpYe8=
X-Received: by 2002:a05:6102:346:b0:357:79f5:63ae with SMTP id
 e6-20020a056102034600b0035779f563aemr13028175vsa.40.1658270725568; Tue, 19
 Jul 2022 15:45:25 -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: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> 
 <20220719204245.GL30607@FreeBSD.org>
In-Reply-To: <20220719204245.GL30607@FreeBSD.org>
From: Warner Losh 
Date: Tue, 19 Jul 2022 16:45:13 -0600
Message-ID: 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
To: Glen Barber 
Cc: Ed Maste , "Rodney W. Grimes" , 
	Mark Millard , dev-commits-src-main@freebsd.org, 
	"Dr. Rolf Jansen" , freebsd-arm 
Content-Type: multipart/alternative; boundary="0000000000008a131c05e4303d7f"
X-Rspamd-Queue-Id: 4LnYnf0cP3z3P21
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=jfhVWJkU;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2c) smtp.mailfrom=wlosh@bsdimp.com
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_CC(0.00)[freebsd.org,gndrsh.dnsmgr.net,yahoo.com,cyclaero.com];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2c:from];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008a131c05e4303d7f
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:

> On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste wrote:
> > On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes
> >  wrote:
> >
> > > Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> > > being zero in /usr/src/release scripts is in order so that
> > > the builds blow up rather than produce BAD images.
> >
> > This is a good interim step (before switching to mkimg).
> >
> > Perhaps:
> >
> > diff --git a/release/tools/arm.subr b/release/tools/arm.subr
> > index 77b708bca4a2..94e0ee89deaf 100644
> > --- a/release/tools/arm.subr
> > +++ b/release/tools/arm.subr
> > @@ -62,6 +62,10 @@ umount_loop() {
> >  }
> >
> >  arm_create_disk() {
> > +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
> > +               return 1
> > +       fi
> > +
> >         # Create the target raw file and temporary work directory.
> >         chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
> >         if [ "${PART_SCHEME}" = "GPT" ]; then
> >
>
> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
> the builders, which effectively means all arm builds will fail every
> time.  I think we need to get to the actual root of the problem here,
> versus applying band-aids to a shark bite.
>

I think this is the actual problem. While such pedantry can be useful for
ancient picky BIOSes, these days only the LBA fields of the MBR are used.
And the fake BIOS geometry is crazy weird. We can likely tweak it to be
more friendly.

Why is it == 1 on the builder? If people want things aligned gpart has an
option for years iirc to do that. And we want that off for the builds.

Warner

P.s. the last BIOS that I had to deal with where this mattered was a 133MHz
pentium PC104 board in 2002 or 2003.

>

--0000000000008a131c05e4303d7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 19, 2022, 2:42 PM Glen Barber <gjb@freebsd.org> wrote:
On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste =
wrote:

> On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes

> <freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> 

> > Perhaps an assert for kern.geom.part.mbr.enforce_chs not

> > being zero in /usr/src/release scripts is in order so that

> > the builds blow up rather than produce BAD images.

> 

> This is a good interim step (before switching to mkimg).

> 

> Perhaps:

> 

> diff --git a/release/tools/arm.subr b/release/tools/arm.subr

> index 77b708bca4a2..94e0ee89deaf 100644

> --- a/release/tools/arm.subr

> +++ b/release/tools/arm.subr

> @@ -62,6 +62,10 @@ umount_loop() {

>=C2=A0 }

> 

>=C2=A0 arm_create_disk() {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ $(sysctl -n kern.geom.part.mbr.enforc=
e_chs) !=3D 0 ]; then

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 1

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0fi

> +

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# Create the target raw file and temp=
orary work directory.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chroot ${CHROOTDIR} gpart create -s $=
{PART_SCHEME} ${mddev}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "${PART_SCHEME}" =3D &=
quot;GPT" ]; then

> 



My concern with this is kern.geom.part.mbr.enforce_chs is always '1'=
; on

the builders, which effectively means all arm builds will fail every

time.=C2=A0 I think we need to get to the actual root of the problem here,<=
br>
versus applying band-aids to a shark bite.

I think this is the actual proble=
m. While such pedantry can be useful for ancient picky BIOSes, these days o=
nly the LBA fields of the MBR are used. And the fake BIOS geometry is crazy=
 weird. We can likely tweak it to be more friendly.=C2=A0

Why is it =3D=3D 1 on the builder? If peo=
ple want things aligned gpart has an option for years iirc to do that. And =
we want that off for the builds.

Warner

P.s. th=
e last BIOS that I had to deal with where this mattered was a 133MHz pentiu=
m PC104 board in 2002 or 2003.




--0000000000008a131c05e4303d7f--

From nobody Wed Jul 20 16:34:19 2022
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 4Lp1WG6hqvz4XNvl;
	Wed, 20 Jul 2022 16:34:34 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lp1WG4S1vz3yZ0;
	Wed, 20 Jul 2022 16:34:34 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26KGYJPq074209;
	Wed, 20 Jul 2022 09:34:19 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26KGYJjv074208;
	Wed, 20 Jul 2022 09:34:19 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202207201634.26KGYJjv074208@gndrsh.dnsmgr.net>
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
In-Reply-To: 
To: Warner Losh 
Date: Wed, 20 Jul 2022 09:34:19 -0700 (PDT)
CC: Glen Barber , Ed Maste ,
        "Rodney W. Grimes" ,
        Mark Millard , dev-commits-src-main@freebsd.org,
        "Dr. Rolf Jansen" ,
        freebsd-arm 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Lp1WG4S1vz3yZ0
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
> 
> > On Tue, Jul 19, 2022 at 04:35:36PM -0400, Ed Maste wrote:
> > > On Sun, 17 Jul 2022 at 13:08, Rodney W. Grimes
> > >  wrote:
> > >
> > > > Perhaps an assert for kern.geom.part.mbr.enforce_chs not
> > > > being zero in /usr/src/release scripts is in order so that
> > > > the builds blow up rather than produce BAD images.
> > >
> > > This is a good interim step (before switching to mkimg).
> > >
> > > Perhaps:
> > >
> > > diff --git a/release/tools/arm.subr b/release/tools/arm.subr
> > > index 77b708bca4a2..94e0ee89deaf 100644
> > > --- a/release/tools/arm.subr
> > > +++ b/release/tools/arm.subr
> > > @@ -62,6 +62,10 @@ umount_loop() {
> > >  }
> > >
> > >  arm_create_disk() {
> > > +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) != 0 ]; then
> > > +               return 1
> > > +       fi
> > > +
Yes Please, once the builder issue is addressed.

> > >         # Create the target raw file and temporary work directory.
> > >         chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
> > >         if [ "${PART_SCHEME}" = "GPT" ]; then
> > >
> >
> > My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
> > the builders, which effectively means all arm builds will fail every
> > time.  I think we need to get to the actual root of the problem here,
> > versus applying band-aids to a shark bite.
> >
> 
> I think this is the actual problem. While such pedantry can be useful for
> ancient picky BIOSes, these days only the LBA fields of the MBR are used.
> And the fake BIOS geometry is crazy weird. We can likely tweak it to be
> more friendly.

I do agree that this appears to be the actual problem, and given that
it is now known that this value is set to 1 on the builders just goes
to confirm that.

> 
> Why is it == 1 on the builder? If people want things aligned gpart has an
> option for years iirc to do that. And we want that off for the builds.

Thats a question I would like to see answered as well.

> 
> Warner
> 
> P.s. the last BIOS that I had to deal with where this mattered was a 133MHz
> pentium PC104 board in 2002 or 2003.

Concur, CHS is pretty much ignored since 2000ish, other than a few bioses
may blow chunks with a divide by zero if you leave them empty.
NOTE that the ending CHS address in a partition entry is often used to
decide the "fake" geometry of an LBA device by the BIOS, so IMHO if are
going to do 1MB (2048 sector) type alignments we should be using fake
CHS values that are something like my favorive S=32, H=64, which comes
from very early SCSI translations, and tends to "just work everywhere".

The magical value 1023 for Cylinders is often used to indicate it is fake,
the other value less often used is to just use the low 10 bits of what
ever the translated value comes out to be.

Please lets not continue to produce these wonky images.
-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Wed Jul 20 17:08:20 2022
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 4Lp2GP0pnKz4WSVp
	for ; Wed, 20 Jul 2022 17:08:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4Lp2GN6qj7z44SB
	for ; Wed, 20 Jul 2022 17:08:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658336906; bh=du2I10dZaWj2qykTkeVnLtdVbksYpNQ/X0QzTGUXToY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=K/ErEVb3f4rMu8hNskxFUwq+TcwVuH9z016FrqSdrfNS1OJ563uoc94w0zk/qrk46y94nlboSAXMcA4ilErP9I61ioMSTLa3kEnitFpmnNSSvrPkBayc+qZjU3440gchccPpuCksQfL16YP3FAME2RLfEKhrAcOKll4ZbIYregeea/0ifMhT7tIqtlOprFDFyDt+/6fQJfPPGx2NNNWDhBIziX8VXmX6oQvsU1jw8ddTP54R2nfNMZwwr7iPZmUkcC+OxQPYr6GnmKQKjmez2u8k0+wKp13bvQIUh0g8cZqnV35cxUyEZwmFeBowfj3qbRzN/laFBTgmuwdNvW0F+w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658336906; bh=MCPhrJarjqVmhPWxkoS0UF/mYKuE4uFlRc862fcwtTG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AW0N1lPESUPs3vZh3YtXM5hJnTa3erGZFAAQJgAnYqhGr9Sp4iMFGenMqAfjmTy1Ad7XZRZ0j+YSPfrutGRVrr9Bo7J9EG3ThRTH3ph6AxEfv/O1HcWBkX1orPCnFjHarnqH4PApQ3X/Gorl/bh+UWk/HPOaWncdHvn3bjSPkWGXhz0A5sEnuhMmP0c97mXYK+jJ7dU6wYGN5UEK2h7wy2Z90Tz5gLjywqvu3kUkttQ8yUO/Inn/WOIr9AoKdihWqhHSXt0lt+0arnv9xXTk3KiDpYzLYyEVkAg50Pqpkwx4UIauX03xy/2TbC0yHa7DEWpnym+fQDSmagHoUqbYJg==
X-YMail-OSG: 1SCylW0VM1kubPyWp6OinVIi8BBal81hF1c3rgkP8CdP6qpeYhHVUfcHgNUyCfk
 e5PM8LGwphMN.kV9u_uJ3dJv46x4d_veZO7sFiSlPVec_Zf.kZJkN87tEMoOtx0p2k6vSgyLJbY8
 SYx9AxF0H29bDYzWL7yqDY4_IoRCT6cfqmjGBom1yBjdBpu6JL103zdNxGSlQQSEID8ARrP4h7_N
 0tTpSULq_Gf6C6leU7Vzl54iKLd.VRpo8R1Qk_GdZyg8Iei_4uWDGWnpWaiPkTJo2va1axUVQ5bL
 yRLOswPqfwEKcmqU3eHJzaHUDAlFEUxFjouT1fSk501mW.Pk1BblzB1wcdn8GsE58Wc7S2NCRWRF
 K8lZZX0MPLS.YDXLKDmemhekoD49vq089I3Ix.TBVFLi8yymxD2kqx1Afo_3fHyZ_41FC81BB0rL
 8MnoGipsmowA6.IXZO.2q_OfQOeHYB32qWp9mGHbK4lH4nRq87oB.AP6fwEI0OsJFFfzCzhafS4L
 PR52B9_edDxPXvqVScC0RyX.vyEWpxMgy5F20O9Jiyom1eiUEr9fBbiC6WxZPWqT_KIbuBSFkiSs
 PMIYQcJfXEiyd9U9UmexBU5YqgYxmL75zoJycO0jgxY2xEd4iecEbuisJi65.d_dXniv3mBlUhvT
 5SEwzio81LgaOw4RXXI4y49huvzkAIPYkU4s9P5aPAPmLSj8REkZuvaACqnI.f9KfDbZQkRvzuOX
 95oGwv9fAO5xogRM3BN3C8JZN6E_7vNtlTQ1s3ycY7QHx8vlzimKtDfKfAXnfozfibcSG3C4jbVT
 VPlPHVbLkKRhNTsqDGZu85iZ.Kg_jvdNmyMt1yw5yKPeDpmoxgPxvr7TIN2c5eSBV4oAD4n1U3rl
 alNaEexkau8FkPQbAgMaPeslX91ljOeRublaiXumSaQFw9W1VCpsGWR11AqLnpDVLJM7RHLvu79I
 2zwAfV7e6mJQ3lAXrgFJhZnnnbmJJB8csS0Y1OR65t68p6Zhv1qmsi4XQZs4o3hq0FVRAFtdc3Xy
 BuhkC6cP_9gLtUNL667sIb6GSyKYUine4beLDAUDvO.hsRziCHvWAive_bw1rghSEQNqRk_hL7pA
 Wy0BDKvws.GNJzx6ZWvjECMEldTJpx1oUchIvwWbUVF9RTKIaGNoumEqWIwpMOT_0Z.znZIsghFR
 95C88kZi5NQsFpq84HrjOigVYOCD0KgOl_LyAUaOsZKZwbVY6iJSS4p0nPbggPwbqcTuJxhSxKr2
 xWoDbxyc6IJMxWniJpSORU_TwUfEhAata3s8ZbffTijTbn6oLoCajNIRnyMoxL7hJuRpnnve1nLc
 ysn2gUXOsR8oSPZHeanYBeOpS35cCSEQ28pYviZa6pbNDpk0TS6qksPyyFraUDY8mumG3N0OaAB3
 nckzOlzsZl9G8q1Gt_h2LQ0c95Adby9U0JM_L2cYo.rDDXAk08QVAGMsjv9nIMNr9CTcb.kQyV8n
 IqDJtI2S1ehld2g9MA49kF5DmQ_v6N0Gn1PhZyYnaJ5hpT4T8mrV7utkAHnk6LVGj3wWmuBPzSig
 T2Kw_Dyy9pK9AH5NeVCfsrJwFkCPgdbReYA3Oeuo8ba01iMUw4KH_2f02JMZGfDVLPIluA7PodZt
 A1CRR924mhJNoxFRpcb3AS.k9Hp35K7qcDQW8BFBp_mHru94UEwVf.NEu6UoJWuDSpeMHkmseOxD
 CieMsSzlAT2Qi.x5Nmo.OFOAM_DGoCiEAmq_CSIiAPlbajnmuT0cthkaFyl.juzBsQc2z6abRZ2c
 j12wromakWqxgd7Nna.ia504OXs9T46IvTp5yzBpLZC0MuOj2NqDmh8My50l0aP3g3MVBN5kICrX
 MxqypfFHxysgu5jABSd8yLWkxmd.aWb0PRj3z9A0dkIfRwiQgqVcQs5WBejVvWWpXmUZKWo7OTF2
 C2QHChQzSk5mmyoGLxyOUKo4VTtVYiXvqoRhJF2.NUcu4JvNaNyWK3dp3i.4zq2NZXNPKn_tLk9M
 iTynybgYC6tvI6Ej34gopyS3tSxQoVBKRgybWuevSAlgarXIQwoe_r2oLIaowHVGVkpjYF_yB4cS
 UwcD6_1LTCA34br_DujBQGnz9elgG4fDYja12I6rUvPDKzTzWSbG2Hwiz8dgCmZV.swPSi2n7..U
 mXh5rEQrDceUTGN6Fgjt84B9gRjFdW1GlV3meYpXQWwHQY4iFFs7Yid_k3FGfYKA1uKPldIqhS8u
 awjK_SMX8pcLK1SzRMubnVWr43i_QFx21K4MpUnmuMe.neZJpbf5pJgz5ehmFHJ723meKgsQ.1q.
 OD3C2Gp17Z6Dp
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Jul 2022 17:08:26 +0000
Received: by hermes--production-ne1-7864dcfd54-8q7fk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2fc6f97c262351edb2c1ea28535e5c66;
          Wed, 20 Jul 2022 17:08: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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: 
Date: Wed, 20 Jul 2022 10:08:20 -0700
Cc: Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
To: Warner Losh ,
 Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Lp2GN6qj7z44SB
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)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-19, at 15:45, Warner Losh  wrote:

> On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
>>> . . .
>>=20
>> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' =
on
>> the builders, which effectively means all arm builds will fail every
>> time.  I think we need to get to the actual root of the problem here,
>> versus applying band-aids to a shark bite.
>=20
> I think this is the actual problem. While such pedantry can be useful =
for ancient picky BIOSes, these days only the LBA fields of the MBR are =
used. And the fake BIOS geometry is crazy weird. We can likely tweak it =
to be more friendly.=20
>=20
> Why is it =3D=3D 1 on the builder? If people want things aligned gpart =
has an option for years iirc to do that. And we want that off for the =
builds.

Would it seem appropriate to use a week (this week?) to do all
the snapshot builds with the builders all set to have
kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
(Sort of a snapshot exp run.)

More than just the SBC images might be involved for
kern.geom.part.mbr.enforce_ch consequences, for all I know.

> Warner
>=20
> P.s. the last BIOS that I had to deal with where this mattered was a =
133MHz pentium PC104 board in 2002 or 2003.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Jul 21 03:46:20 2022
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 4LpJQd4dSSz4WT1N
	for ; Thu, 21 Jul 2022 03:46:33 +0000 (UTC)
	(envelope-from nick@i11.co)
Received: from mx.i11.co (mx.i11.co [159.69.78.69])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LpJQc3lMkz3BsP
	for ; Thu, 21 Jul 2022 03:46:32 +0000 (UTC)
	(envelope-from nick@i11.co)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=i11.co;
	s=omicron; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:
	In-Reply-To:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=dQBmH6H87I3oQfATzsOA+ohggbdBYZhWml8IYt86Hgg=; b=YJspJHTUy//zuiKs3lx3XAdbNn
	0Zq4BfCOwH12XBBTDDJ62BXWpKKUBGAuIhGVT3LB7I5OCZgmlBrHj1Kf31V6rFDYzm14FSvCDnB64
	NZIYyWGW/IN7Nb3u7ucma0nYuwzOfHh+wsKKrR4xim4iZqh8BEyNzJg53kMRY2ApRCzacNY/p6wBb
	3dEKh6C+ZX53XjL0/oDbHpN+wDATdsXWypcb+29YOUy39q7whMRWmxPhaQHRX2N8F+yK9p1Jd4J2K
	+RiUmfZQy2MYIQMHaLrgjHygAucKqas2Atm/MnPHEx/kVXLqGHqp2F2e1StMeZgY5C+NTRwAnxi+/
	tjS8u2Yw==;
Received: from [212.237.25.26] (helo=thinkbook)
	by mx.i11.co with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1oEN8r-0007pY-0G
	for freebsd-arm@freebsd.org; Thu, 21 Jul 2022 03:46:25 +0000
Date: Thu, 21 Jul 2022 06:46:20 +0300
From: Nick Kostyria 
To: freebsd-arm@freebsd.org
Subject: Re: SPI and si4463 radio
Message-ID: <20220721034620.5d1e5372@thinkbook>
In-Reply-To: <20210401173801.5021704d@i11.co>
References: <20210401173801.5021704d@i11.co>
X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.3)
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: 4LpJQc3lMkz3BsP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i11.co header.s=omicron header.b=YJspJHTU;
	dmarc=pass (policy=reject) header.from=i11.co;
	spf=pass (mx1.freebsd.org: domain of nick@i11.co designates 159.69.78.69 as permitted sender) smtp.mailfrom=nick@i11.co
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)[-1.000];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[i11.co,reject];
	R_SPF_ALLOW(-0.20)[+ip4:159.69.78.69];
	R_DKIM_ALLOW(-0.20)[i11.co:s=omicron];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[nick];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[i11.co:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 1 Apr 2021 20:38:01 +0300
Nick Kostirya via freebsd-arm  wrote:

> Hello.
> I need help with SPI and si4463 radio.
> 
> si4463 radio works great on Arduino Pro Mini.
> FreeBSD 12.2 (armv7 r369379) on NanoPi NEO no not work with it.
> MISO always has the HIGH state.
> The logical analyser says that values of CLK, MOSI, CS is identical to Arduino.
> The only difference is that interval between CS and CLK is much bigger on FreeBSD.
> 
> By the way BMP280 works fine on FreeBSD.


I found the reason!
Si4463 radio works on NetBSD 9.2 on the same ARM board.
I compared signals and I saw what clock polarity in idle state is logic HIGH on FreeBSD 12.3!
NetBSD 9.2 have LOW.

Why does BMP280 work fine on FreeBSD, but not Si4463?
BMP280 support SPI_MODE_0 and SPI_MODE_3, but Si4463 support only SPI_MODE_0.
SPI_MODE_0 implies logic LOW in idle state of clock.

I haven't figured out how to fix it yet...

Question.
Other boards have same behavior? 
Or is it only on Allwinner H3?

From nobody Thu Jul 21 14:50:05 2022
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 4Lpb8W1YJGz4Wp79;
	Thu, 21 Jul 2022 14:50:19 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42])
	(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 4Lpb8W0kF0z4663;
	Thu, 21 Jul 2022 14:50:19 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f42.google.com with SMTP id ez10so3508981ejc.13;
        Thu, 21 Jul 2022 07:50:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=fxVkX1HhQGGUImoEPd4Y+D9gY0vu5dERKZjMQdg2mww=;
        b=Chq/blsGEe+5pn33SyxLPYI6H1mPHcp6yFu9ZPhtso4UwDZxmVus7tw/AtV+azXHas
         oUV2XdhkWrYreLYMZJkaQIClHC+Sn94uCfMAj7s3bJLqeFI2KSDNWsGi2BPqVWdNd2U4
         3J9i31I7K79HpsyEHb6McivJiDk65/cD3dFc+KXBV6Imjygh4yiSOBJ987Cp82Av2J8g
         q5MqZPV56R8E4kxXaiWXAMU8BUTG4bvdvWfrDcFS+FexBb8tPU2kKR1WdYrbyOwKIWCn
         i9OXs/Hpiv+nLne5FNne+XK1Cg8pBW9ugomA2Nmc6FN5w+TDfzPKt4mVEpFNXoUeH9yq
         QZlg==
X-Gm-Message-State: AJIora9b5so78BKnH5918Zygoeaw9j+KUMhvT0WAFABEHfj1T1aBs3T9
	+1nznnAW+vB+obadpNDu5BWaEALshLfNUWD+s7iwM1L9XMg=
X-Google-Smtp-Source: AGRyM1uLiC/PgzZ2Vlwui7DBP5vdZVboR/uSUOOn1mhegI3qD0/mjrbZErtgP/DRXWSZBKfAY3zJOyUYS8R7T8yYSC8=
X-Received: by 2002:a17:906:8478:b0:72b:4f81:29d8 with SMTP id
 hx24-20020a170906847800b0072b4f8129d8mr40861483ejc.179.1658415017512; Thu, 21
 Jul 2022 07:50:17 -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: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> 
 <20220719204245.GL30607@FreeBSD.org> 
 
In-Reply-To: 
From: Ed Maste 
Date: Thu, 21 Jul 2022 10:50:05 -0400
Message-ID: 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
To: Mark Millard 
Cc: Warner Losh , Glen Barber , 
	"Rodney W. Grimes" , dev-commits-src-main@freebsd.org, 
	"Dr. Rolf Jansen" , freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Lpb8W0kF0z4663
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)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 20 Jul 2022 at 13:08, Mark Millard  wrote:
>
> More than just the SBC images might be involved for
> kern.geom.part.mbr.enforce_ch consequences, for all I know.

Searching release/ for `gpart` and `mdconfig` turns up only the use in
arm SD card images, so I wouldn't expect
kern.geom.part.mbr.enforce_chs=0 to have an effect on anything else.
(But doesn't hurt to confirm, of course.)

From nobody Thu Jul 21 14:55:40 2022
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 4LpbGD4CFxz4WpYB;
	Thu, 21 Jul 2022 14:55:16 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LpbGD3LSPz47PR;
	Thu, 21 Jul 2022 14:55:16 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1658415316;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=vKIRwXH+XsX4Mm18O/A4JgKg8cWA3KTTJbw+EtwS6lg=;
	b=lUX8SGW3ypCdAiKm6FRfOQ0WVhG+n0+4OMsCJu+ySyn1yd7fdJ90xk/S13RU7Ve2cj+t2H
	x4xT/DL61aICpRH8pdi50232U0h4uIyxJn44bouIO2d+IC5Dw7KfDKQJ45+Y4DbkB4Cc/Z
	8ETdU+G8lCMgcQ75dxl2NlUWlfpbyXActTtlnoyQ0HZjjOps6TMknPV+Jr5Jrv5Cc2+OjU
	jOGTOMzv+EJLBO2qNfXwDquZnv8A03V3iIR/B+RwL1KD8oQAkInEIZs9LJzwDhDrtIXLw6
	kDNJQvm7IGJZTSyPCzqsdskZu/Ur6c0bloq9bIGAemwHaGpO06jHQ7vtjDgEwg==
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49])
	(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))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LpbGD2K1WzWbL;
	Thu, 21 Jul 2022 14:55:16 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-ej1-f49.google.com with SMTP id j22so3638748ejs.2;
        Thu, 21 Jul 2022 07:55:16 -0700 (PDT)
X-Gm-Message-State: AJIora98WTikC+BHbO1PWu2gZdu9g8vKEj/gP4+4QDZ6ED9l3mOiOb9G
	WnNfvtvqYm12nPi9jt8ot1Uz6EbjKNyl7BKbedw=
X-Google-Smtp-Source: AGRyM1vVdehzEhUfSmXn6KbnvM7QYo4vPIa4tllRX0pOlgMtVKXGIZ3Vxk72CMhm5wnORIWHd0ICbZafH2rXv9ug39I=
X-Received: by 2002:a17:907:2c74:b0:72b:5ba7:d96f with SMTP id
 ib20-20020a1709072c7400b0072b5ba7d96fmr41772076ejc.33.1658415315304; Thu, 21
 Jul 2022 07:55:15 -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: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> 
 <20220719204245.GL30607@FreeBSD.org> 
 
In-Reply-To: 
From: Kyle Evans 
Date: Thu, 21 Jul 2022 07:55:40 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
To: Mark Millard 
Cc: Warner Losh , Glen Barber , Ed Maste , 
	"Rodney W. Grimes" , dev-commits-src-main@freebsd.org, 
	"Dr. Rolf Jansen" , freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658415316;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=vKIRwXH+XsX4Mm18O/A4JgKg8cWA3KTTJbw+EtwS6lg=;
	b=X3x6xb1YCwiSqqQQNKVKjlywkx0N/driblgHszKyBHrBBMWGf54VejcJWEvgPlVBaa2901
	72wVUsznjuQshBGkghHAKZaf/7T38QFaKEaEyKIgcGbX8Pog4HcqJrSiCXCb2qnvp6j9xt
	b1qMby/P5Pk8AV7Ci88z2LWb7SpOTyVtL4JhUDDVZm7VLnGdAKQkD+j7srAG9AHDBrUUro
	hBrZoTJ+PSHucCtMYw7VyRqrZtL6Lv5P5xD4dvjtSkxn7iSh8SoEL7fzRF0b4qI4QunX7h
	2AaSrT5oJgRM9l7ykV9KqnV+kNxSil23EiWhEC5Tfimpzc2gGSXMS2djUQqPzA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658415316; a=rsa-sha256; cv=none;
	b=eTxVHEUYCn42/4QWy3u2FQz7+2OhRVdZTvqwqxlY2bLdKhBHpt3sT8lmApXViAa4p7ZaJK
	6H1By0QPK0SaeRZZYeNwBK7hE6Qn8Xdi39CdpIlcFC/H2O3b7/8jOkq+58QGqhJuibZbjP
	uUByNX99WajVpquQatQoj1K5AyP6xq8OYUvPI8mK44oOe8JAhnqJlSl6Y2eHX5MsqeW4vZ
	pCRGqXCjIn19WbyREQd202mm+96ctHtRjGD1wtMEO8t8lk3T+Qm/98GwyRcVi9OLT8ZUY+
	dGJB0sM+lhXFB13FaIj3rsX5k2gHajV4ubebjEFvGo3RGsKgKEOqPn7HDu1RnQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Jul 20, 2022 at 10:08 AM Mark Millard  wrote:
>
> On 2022-Jul-19, at 15:45, Warner Losh  wrote:
>
> > On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
> >>> . . .
> >>
> >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
> >> the builders, which effectively means all arm builds will fail every
> >> time.  I think we need to get to the actual root of the problem here,
> >> versus applying band-aids to a shark bite.
> >
> > I think this is the actual problem. While such pedantry can be useful for ancient picky BIOSes, these days only the LBA fields of the MBR are used. And the fake BIOS geometry is crazy weird. We can likely tweak it to be more friendly.
> >
> > Why is it == 1 on the builder? If people want things aligned gpart has an option for years iirc to do that. And we want that off for the builds.
>
> Would it seem appropriate to use a week (this week?) to do all
> the snapshot builds with the builders all set to have
> kern.geom.part.mbr.enforce_chs=0 and see what breaks, if anything?
> (Sort of a snapshot exp run.)
>

https://svnweb.freebsd.org/base?view=revision&revision=332731 says:

Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has
been enabled on the build machine to mitigate against the issue in
the PR referenced.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536
("glabel/partition mixup on sdcard images")

From nobody Thu Jul 21 15:24:57 2022
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 4Lpbwk5XdPz4WshB
	for ; Thu, 21 Jul 2022 15:25:10 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33])
	(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 4Lpbwj5RStz4DPw
	for ; Thu, 21 Jul 2022 15:25:09 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe33.google.com with SMTP id t15so1828100vsr.12
        for ; Thu, 21 Jul 2022 08:25:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=xDxcZrOpWVqGI39ngQOAyJrfuN1IB5bELlJJFEi0uq4=;
        b=MxRC30mLiqELW6VmM4ciimKGF6uNLMpr2ZgjZ36fNA+PjwwRxj+0wD+n0LpTE6qiWC
         SsUmShm/p5blFbHOr+fqLPJ8X4Px5bfgKC3Hcx1C6VJShngk7xJDNZz55J7r39suqV+z
         dSiHefcAEBn3iPpwoT3T7ku/EA4h4B0luOUSN+usrFN2Wz7C+Vm5V9+C7CjCjZzk34w9
         eMv6FxypJYQMCn7uqtuWKkdtn7NemDMTeNPgExHejpLsQpusMF2Ozl8DAknBhxDDYIxK
         6lB4EifRzhbIARrvev9ZfotKxDNg7CEj0wGr9KOsU79/MkOMud63XTIeRNiKmllY10p2
         jWQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=xDxcZrOpWVqGI39ngQOAyJrfuN1IB5bELlJJFEi0uq4=;
        b=qv+GNRHNe4wg2eA3b8e4h4PcvTKQarG/Q2/yk122d4IATNGVw9hPhRqw31JnvqvTy8
         V6qpWqyX597Z9i9VVOzCcXchh+FKPjTt96EHHVaqCXBngkVupr2/zsOVsYoaf+l+xpCo
         dMsAxMmvUq2m0dqXKIMjXCf9YwlwQffdFa8TQUuORU668YcWSilycgNjtKRC1Zk0vH/w
         50LM/m3bkpWBAb0cNcwB8XwMPQ9wjTRBNp/ZgApYFCU6+07eXavVegKvRc8aByEA3+jo
         npIXbNboC+sbi4qs8bQSgOAksm1rZOsaMn18vXsaJfxfF7EzMfalTbfl7UT1agMBuvsK
         2/nA==
X-Gm-Message-State: AJIora8UyXDmb0A5WJ6QryhpvVFWwDP1N2QlCDnMSe0NUbIF/WtzQqcB
	31fl9ZB8pVt2OqFbZOqw4cnG8XUgqa8sWAPxU/9Qzg==
X-Google-Smtp-Source: AGRyM1vZXwxCgAIYJLUYvB2ep5MX/42kLp6gMK8MsIYGOiSQwUOEOhsV9TTwID4WKSJmxeHnC3CX5/yOr0cFA12BX8Q=
X-Received: by 2002:a67:ec88:0:b0:357:83f:e0f3 with SMTP id
 h8-20020a67ec88000000b00357083fe0f3mr15853086vsp.76.1658417108965; Thu, 21
 Jul 2022 08:25:08 -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: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net> 
 <20220719204245.GL30607@FreeBSD.org> 
  
In-Reply-To: 
From: Warner Losh 
Date: Thu, 21 Jul 2022 09:24:57 -0600
Message-ID: 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
To: Kyle Evans 
Cc: Mark Millard , Glen Barber , Ed Maste , 
	"Rodney W. Grimes" , dev-commits-src-main@freebsd.org, 
	"Dr. Rolf Jansen" , freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000ab6c0105e4525284"
X-Rspamd-Queue-Id: 4Lpbwj5RStz4DPw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=MxRC30mL;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e33) smtp.mailfrom=wlosh@bsdimp.com
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,gndrsh.dnsmgr.net,cyclaero.com];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e33:from];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ab6c0105e4525284
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 21, 2022 at 8:55 AM Kyle Evans  wrote:

> On Wed, Jul 20, 2022 at 10:08 AM Mark Millard  wrote:
> >
> > On 2022-Jul-19, at 15:45, Warner Losh  wrote:
> >
> > > On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
> > >>> . . .
> > >>
> > >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1'
> on
> > >> the builders, which effectively means all arm builds will fail every
> > >> time.  I think we need to get to the actual root of the problem here,
> > >> versus applying band-aids to a shark bite.
> > >
> > > I think this is the actual problem. While such pedantry can be useful
> for ancient picky BIOSes, these days only the LBA fields of the MBR are
> used. And the fake BIOS geometry is crazy weird. We can likely tweak it to
> be more friendly.
> > >
> > > Why is it == 1 on the builder? If people want things aligned gpart has
> an option for years iirc to do that. And we want that off for the builds.
> >
> > Would it seem appropriate to use a week (this week?) to do all
> > the snapshot builds with the builders all set to have
> > kern.geom.part.mbr.enforce_chs=0 and see what breaks, if anything?
> > (Sort of a snapshot exp run.)
> >
>
> https://svnweb.freebsd.org/base?view=revision&revision=332731 says:
>
> Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has
> been enabled on the build machine to mitigate against the issue in
> the PR referenced.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536
> ("glabel/partition mixup on sdcard images")
>

Having read through all that, I think it's safe to disable it again. We
changed the build process
to avoid the original bug, so no longer need the rounding to prevent the
situation from happening.
There are no old branches or legacy reasons to keep it enabled unless
there's another side effect
of it that I'm not seeing...

Warner

--000000000000ab6c0105e4525284
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 21, 2022 at 8:55 AM Kyle =
Evans <kevans@freebsd.org> =
wrote:
On Wed, J=
ul 20, 2022 at 10:08 AM Mark Millard <marklmi@yahoo.com> wrote:

>

> On 2022-Jul-19, at 15:45, Warner Losh <imp@bsdimp.com> wrote:

>

> > On Tue, Jul 19, 2022, 2:42 PM Glen Barber <gjb@freebsd.org> wrote:

> >>> . . .

> >>

> >> My concern with this is kern.geom.part.mbr.enforce_chs is alw=
ays '1' on

> >> the builders, which effectively means all arm builds will fai=
l every

> >> time.=C2=A0 I think we need to get to the actual root of the =
problem here,

> >> versus applying band-aids to a shark bite.

> >

> > I think this is the actual problem. While such pedantry can be us=
eful for ancient picky BIOSes, these days only the LBA fields of the MBR ar=
e used. And the fake BIOS geometry is crazy weird. We can likely tweak it t=
o be more friendly.

> >

> > Why is it =3D=3D 1 on the builder? If people want things aligned =
gpart has an option for years iirc to do that. And we want that off for the=
 builds.

>

> Would it seem appropriate to use a week (this week?) to do all

> the snapshot builds with the builders all set to have

> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
> (Sort of a snapshot exp run.)

>



https://svnweb.freebsd.org/base=
?view=3Drevision&revision=3D332731 says:



Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has

been enabled on the build machine to mitigate against the issue in

the PR referenced.



https://bugs.freebsd.org/bugzilla/show_bu=
g.cgi?id=3D226536

("glabel/partition mixup on sdcard images")
=

Having read through all that, I think it's safe to disab=
le it again. We changed the build process
to avoid the original b=
ug, so no longer need the rounding to prevent the situation from happening.=

There are no old branches or legacy reasons to keep it enabled u=
nless there's another side effect
of it that I'm not seei=
ng...

Warner


--000000000000ab6c0105e4525284--

From nobody Thu Jul 21 16:43:14 2022
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 4Lpdg54dsnz4X2MY;
	Thu, 21 Jul 2022 16:43:29 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lpdg5243Fz4QXH;
	Thu, 21 Jul 2022 16:43:29 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 26LGhE5r078164;
	Thu, 21 Jul 2022 09:43:14 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 26LGhEsF078163;
	Thu, 21 Jul 2022 09:43:14 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202207211643.26LGhEsF078163@gndrsh.dnsmgr.net>
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
In-Reply-To: 
To: Warner Losh 
Date: Thu, 21 Jul 2022 09:43:14 -0700 (PDT)
CC: Kyle Evans , Mark Millard ,
        Glen Barber , Ed Maste ,
        "Rodney W. Grimes" ,
        dev-commits-src-main@FreeBSD.org,
        "Dr. Rolf Jansen" ,
        freebsd-arm 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Lpdg5243Fz4QXH
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> On Thu, Jul 21, 2022 at 8:55 AM Kyle Evans  wrote:
> 
> > On Wed, Jul 20, 2022 at 10:08 AM Mark Millard  wrote:
> > >
> > > On 2022-Jul-19, at 15:45, Warner Losh  wrote:
> > >
> > > > On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
> > > >>> . . .
> > > >>
> > > >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1'
> > on
> > > >> the builders, which effectively means all arm builds will fail every
> > > >> time.  I think we need to get to the actual root of the problem here,
> > > >> versus applying band-aids to a shark bite.
> > > >
> > > > I think this is the actual problem. While such pedantry can be useful
> > for ancient picky BIOSes, these days only the LBA fields of the MBR are
> > used. And the fake BIOS geometry is crazy weird. We can likely tweak it to
> > be more friendly.
> > > >
> > > > Why is it == 1 on the builder? If people want things aligned gpart has
> > an option for years iirc to do that. And we want that off for the builds.
> > >
> > > Would it seem appropriate to use a week (this week?) to do all
> > > the snapshot builds with the builders all set to have
> > > kern.geom.part.mbr.enforce_chs=0 and see what breaks, if anything?
> > > (Sort of a snapshot exp run.)
> > >
> >
> > https://svnweb.freebsd.org/base?view=revision&revision=332731 says:
> >
> > Note: In addition to this merge, kern.geom.part.mbr.enforce_chs has
> > been enabled on the build machine to mitigate against the issue in
> > the PR referenced.
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226536
> > ("glabel/partition mixup on sdcard images")
> >
> 
> Having read through all that, I think it's safe to disable it again. We
> changed the build process
> to avoid the original bug, so no longer need the rounding to prevent the
> situation from happening.
> There are no old branches or legacy reasons to keep it enabled unless
> there's another side effect
> of it that I'm not seeing...

I have come to this same conclusion after reading as well.

> Warner

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Fri Jul 22 12:45:30 2022
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 4Lq8L933bFz4X99n;
	Fri, 22 Jul 2022 12:45:37 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lq8L92VZMz47Pk;
	Fri, 22 Jul 2022 12:45:37 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1658493937;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=NnJ8lEqdJCuFZpt9e/wxLzLYrRQXukPqKx84HIRFrho=;
	b=foB8dNU8AlLO/h7qNozF3bri4SOvydDEF3Q/lZgUA28EYwy6M8mU0+GO2HASXsDQ+kxsu7
	7IJEOFRD5h2xqJZlLbB4gmSYVIo3rmTASRQYSJhmdYRVzqc7Z5slpIk7vFKV37qF3E895p
	TyqJyS0h5s9rpE82MxF5oBGptnqrNLk06SlnWXBVtxMm4RIjL+BNUFPLN2O7JdT/CU/jRc
	Vv3f6m/F22ftYQMRb7KExLGSOtHgd0Cfu1rgsvRQje7cpsx1n1eBo7xwfl5sGPjd1Excmy
	C9Z4db2yDrsQHEH1XwZIWlKIpUg6Yia04VT6oFN2eI7LMSKMrYDIlB19OFDM6g==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id AD6D1131C;
	Fri, 22 Jul 2022 12:45:36 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Fri, 22 Jul 2022 12:45:30 +0000
From: Glen Barber 
To: Mark Millard 
Cc: Warner Losh , Ed Maste ,
	"Rodney W. Grimes" ,
	dev-commits-src-main@freebsd.org,
	"Dr. Rolf Jansen" ,
	freebsd-arm 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
Message-ID: <20220722124530.GM30607@FreeBSD.org>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+YUU1pJ1U2q9bSvj"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658493937;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=NnJ8lEqdJCuFZpt9e/wxLzLYrRQXukPqKx84HIRFrho=;
	b=UgCF1JZH424aTKW7AZmdxoXGlewH/5l5xafiwY0tFwQF9EOiMrFvCzORJpS4e7kn7ABIiE
	tR9UTZh5alnsJIApSEqaUjEJfk9PzDRedV48cCJR1pniQjV+cGC9ygHAnh0fX85kkmVkub
	h3Gz826DacEtKkv4q5jw7q7NjKj6VWhSPeDXttwb/qkEbehvWGKgpOnNPr8DuyLxteQmBo
	iwwq5Y7pj4gUnmAOy+wN0vbNYQMsGyAI4kWQnTI4WUuMrk+AWypcaHtV7pGQTRyDeaUg4t
	87q+1XUu3lSQb+zhHppGsxN3+xTmP2NlEyGY5bm3KE5p4xGow33hLvV705Nn2A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658493937; a=rsa-sha256; cv=none;
	b=lnlEqMVCsJ7MrKUET9HsNqIYEqHrUr51paVTSys6uBX9kYY32UJ+wkK6UfD7RdV8q0ogAW
	7JamVMRLb8QzYN4gHodscB19dDtRRutClvMkD4LsBHAErd3mScrg+/+KXa8GwIXB5Uj9N9
	EJVAt0aBPaacgebIUePkqJe6O4TID2RPHCYfAykHx9n0TqQkRVvqGFM6aTgvTf6DkjvmfZ
	3NcrTnzr1Qf4n8a5hbdLziPxXL8qMA56PXpbSIN3BjZlSme141ExZDowbWKp6vSdR/+xfS
	zRIA7kpVkAt6u98Zq1aFpxlmh76CcWHj44THoEEzEm1qslGzcDWD2oQFZDRcWA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--+YUU1pJ1U2q9bSvj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
> On 2022-Jul-19, at 15:45, Warner Losh  wrote:
>=20
> > On Tue, Jul 19, 2022, 2:42 PM Glen Barber  wrote:
> >>> . . .
> >>=20
> >> My concern with this is kern.geom.part.mbr.enforce_chs is always '1' on
> >> the builders, which effectively means all arm builds will fail every
> >> time.  I think we need to get to the actual root of the problem here,
> >> versus applying band-aids to a shark bite.
> >=20
> > I think this is the actual problem. While such pedantry can be useful f=
or ancient picky BIOSes, these days only the LBA fields of the MBR are used=
=2E And the fake BIOS geometry is crazy weird. We can likely tweak it to be=
 more friendly.=20
> >=20
> > Why is it =3D=3D 1 on the builder? If people want things aligned gpart =
has an option for years iirc to do that. And we want that off for the build=
s.
>=20
> Would it seem appropriate to use a week (this week?) to do all
> the snapshot builds with the builders all set to have
> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
> (Sort of a snapshot exp run.)
>=20

Sorry, it is too late for this week's snapshots, but I will set it to
'0' for next week's (I was out the past two days, so did not see this
email until now).

> More than just the SBC images might be involved for
> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>=20

This vaguely rings a bell.  I am still trying to find the original
problem being reported that caused me to set enforce_csh=3D1, but I have
not had much luck.

I do recall it being a strange case that enforce_csh=3D1 had apparently
fixed (or masked something else going on).

Glen


--+YUU1pJ1U2q9bSvj
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLam+UACgkQAxRYpUeP
4pPlgRAAiqGGR4NL+bdFSruB/9DycuO7ZyVVUMb7hFMcQDiCzBF3cR30WVRzsWtW
KGaXttwBMC7dMPsYdChR8K6PZeQALWRbov5SoVW4xoh64jGLuYDimVY955C0t9P1
Sha0wnp+JYDkXZEnxI43MTBaJKEob9HHUqJJrowEkFQkDyL37wYsruVg2TcmTyjV
a9PoNumpIlRX8bsZAcRLNLL70Yl9MFw+bEIJsVhJpPC0Y+k7sxq1pEolOrZJWO+z
mrjRByNASZwiBy1qolTDhhCFXdc4jie3hFzr+D8sHM1/phr/rkmG9nv7qlQyP5+b
SE9ld/qrHzoes60jWw8j9fJp+w4GwCjHV9ZkrLl2lfBMRd9+HW5sJzKuSG73wftJ
nZW2bm+2FAfpwzLQZKPJeFKcHcBnmRpGU/ffPtzWO8yeVTC+EMTYxfabIYcuJ/ZY
keNQ+DCIf6OByqacILOy2WrPFJt8fncI/JTwWjFTXZuhahk/0ZK2R327fV9zREXc
FoHBm2TEAo5gUICNcnozdP9PNH3F15VfALn1S4Uh3oB5TAtUSnASyYrHIwCJ2Dif
jImyajnj8Ml8ioawWpRxMhOdmRPVDTngLPZhB9X4FZ89i1jt0CNNbrZ00CKqWfwR
28uBqUy3luB8+zY6SHAJSYFfIV9Idz7LXcw0jQ3SmonKs+tar+M=
=OPeq
-----END PGP SIGNATURE-----

--+YUU1pJ1U2q9bSvj--

From nobody Sun Jul 24 18:09:10 2022
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 4LrWQZ2DnYz4XBVB
	for ; Sun, 24 Jul 2022 18:09:10 +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 4LrWQZ0Q8zz3RFx
	for ; Sun, 24 Jul 2022 18:09:10 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4LrWQY6ZndzSCR
	for ; Sun, 24 Jul 2022 18:09: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 26OI99EG043210
	for ; Sun, 24 Jul 2022 18:09:09 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26OI99r5043208
	for freebsd-arm@FreeBSD.org; Sun, 24 Jul 2022 18:09: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 265422] redefinition of enumerator '_UVRSC_CORE' on armv7
Date: Sun, 24 Jul 2022 18:09:10 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: yuri@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658686150;
	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=Z+2l2n83jMccaSR+G1d2Au/hwsE6/vz5GRSY3koY6sI=;
	b=tP9WZaWc8IaIp1Wgpob3D0PqEnzmWhEME60bU72iUzxkRkyjNIowiF78tgiieEffAz4bOb
	1R5H23P19LdM1bmomU/n2inVXBwg2B2V+4MDxcSqwDPxQQRl1Bf4FxghQD3SbZf0waJ90Y
	KOb4gEoFm7ZeyDjlCW+iRME0wFBxCSL9hHGNWnwjLbpwWeV4A8jrS0GkaaG0qNP1nuKDTQ
	smmmdAbUruv49sRM3Cqp6NT62Il/gcO6yGsnGasCNmlK4GzrlT86txrBuxWV/Ymk1wFuCL
	rFKemNZjLGhwn6FL1ssFUtd3tEm4K3qpYTKZP6Fq8loJK+kcF1MDbc8boc41iA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658686150; a=rsa-sha256; cv=none;
	b=Ei3KuhH93jIGv/eYkVRvl67R9S1PFZ+rJXv3IjYs0elDGHcNojgjzaktdq30LNkHHsox9F
	tHFC7NuceNz4E8KryrZF7zDqVgztGAKH1GaSnhbMfgZDt6dLhxDEUbnglM2X4tH7nl6/6E
	xWklkbI4NHOVXfXwOlrRWmyJapYH4+EXEZ9eFrNR0nUSiZtXsuIUWN/lUz7CsB4v3Id6JO
	fdz/pLUw4pgnxv8HAMKEDAVbKlLM1oT/9rNyqqaZ/utVUhaht9EuXJxIAplZ0Oo4eY1hjm
	IaV/4gJHfjpBadmozSEaGJHWPE+oLsVBGWefEX9IiYtmFeA5ax7cg3f/1I7EzA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265422

            Bug ID: 265422
           Summary: redefinition of enumerator '_UVRSC_CORE' on armv7
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: yuri@freebsd.org

Testcase: science/simgrid

The code includes boost/stacktrace.hpp which in turn includes cxxabi.h and =
it
fails:


In file included from
/wrkdirs/usr/ports/science/simgrid/work/simgrid-04e3ca46dcefdd19f2f1fee3e75=
c27fb2f7fc2ec/src/xbt/backtrace.cpp:23:
In file included from /usr/local/include/boost/stacktrace.hpp:15:
In file included from /usr/local/include/boost/stacktrace/frame.hpp:61:
In file included from
/usr/local/include/boost/stacktrace/detail/frame_unwind.ipp:20:
In file included from /usr/local/include/boost/core/demangle.hpp:32:
In file included from /usr/include/c++/v1/cxxabi.h:27:
In file included from /usr/include/c++/v1/unwind.h:31:
/usr/include/c++/v1/unwind-arm.h:116:2: error: redefinition of enumerator
'_UVRSC_CORE'
        _UVRSC_CORE =3D 0,
        ^


Log:
http://ampere3.nyi.freebsd.org/data/130releng-armv7-default/a51002eeb3d0/lo=
gs/SimGrid-3.28_1.log

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Jul 24 18:34:27 2022
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 4LrWzl2pdwz4XFsT
	for ; Sun, 24 Jul 2022 18:34:27 +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 4LrWzl13htz3VWZ
	for ; Sun, 24 Jul 2022 18:34:27 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4LrWzl05L4zSZ4
	for ; Sun, 24 Jul 2022 18:34:27 +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 26OIYQVU062659
	for ; Sun, 24 Jul 2022 18:34:26 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26OIYQQl062658
	for freebsd-arm@FreeBSD.org; Sun, 24 Jul 2022 18:34:26 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 265422] redefinition of enumerator '_UVRSC_CORE' on armv7
Date: Sun, 24 Jul 2022 18:34:27 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: yuri@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Not Enough Information
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658687667;
	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=S4d8W2WRqnTLjj0UvaBcJeq+kxZ+CxEtBGVTXelg17o=;
	b=DRLvijV0bbY1OxtSJZmHJil9IeWIb+ZWfqV5VQ2p2W9UN5+XY8N769wFz8kvtXs/6dgVIU
	seslR6DHt82MF9WEE1eZ5Qp2DsSYXTvzUvJslPBRPg9jektBJkxePpSISP5ARuqLz+h7x2
	KrYovutehhj6de1cJ3L9BQ5dSY+m9xhQsNebDqyPDq4ncMMAU476eU9P6+JO/lLZvc8fqW
	PWBY+tGJjF6YEg1hPvF/aT9An6MKpL3C284S2paC+CFkBwydbQoCev4BmaUXhCWVoJ9OBz
	ztPcxQ4SLOEoGdNw9tFl/5t3NLOtPBfPM3uyyGdAvOo0JHJIdXc+1F6ZxBnxjA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658687667; a=rsa-sha256; cv=none;
	b=o7KpApCRJP9aXrRnB5Uuw87pjTYJ5D3daNMWstmCBpeIcTstbSYcTc5p2JajRwt4v1ZC+/
	uxfHFjVtoN6WoUIXu0lzZyc0rf3S1Kc9pXRRiuui2yzW2r0xLQKmgQchwL1Fy7jnj2oUab
	zMMjds1ADgobLQN/VEizobZDr5G8KTavqwPYgiAeQ2y13gm4rdhlP6wYNzn6wT+BBUmCSJ
	niWjLUkWtAq1Ep3P+B3SwTsgdLZFvQSYXwTlUIMO4mj7AjZOG1g1iOaKplPW6M5VeG47Q4
	RjBR5v8lBpHgL53C+k5ubx/i5enjhv8oCBwg1mQ9lkPlaCAs+mtChl4Picbrog==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265422

Yuri Victorovich  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |Not Enough Information

--- Comment #2 from Yuri Victorovich  ---
(In reply to Dimitry Andric from comment #1)

I'll remove dependency on devel/libunwind and will see what happens then.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Jul 24 21:01:15 2022
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 4LrbF80dHSz4XXnB
	for ; Sun, 24 Jul 2022 21:01:16 +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 4LrbF75T1Sz3k47
	for ; Sun, 24 Jul 2022 21:01:15 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4LrbF74Vj8zXlJ
	for ; Sun, 24 Jul 2022 21:01:15 +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 26OL1FPc050961
	for ; Sun, 24 Jul 2022 21:01:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26OL1FKt050960
	for freebsd-arm@FreeBSD.org; Sun, 24 Jul 2022 21:01:15 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202207242101.26OL1FKt050960@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, 24 Jul 2022 21:01:15 +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="16586964751.DF3fd7.46589"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658696475;
	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=Zpv61I38sB1BURL2xohlMIsNM1bi//Gouw/fQEziJYI=;
	b=IG7DCleIZoYQeKNurR44SOPa7lFFts/+IcE2ftBMCvrpCYYjybcaAOe1oY8JkcJYYLd3Hu
	t7qxT7M1TeKAmWKhBOdNQWxcJp9on5SDiBbnVjjxs7zn5Xujb1mdqL0Egxl8TpitHo3rGz
	FgQpH0d/vwUheN+TIMl6FMbY2Zcnf3DDyjEcPFYmthqNlpsYO2qBW+ZPfwvq4anYI7Qhmd
	o7/kzKQbjQJ5e4q+gdKBWH53pt4lF3sMD0u9ZJDpqdqMn67wiBfWHImu9JFavn2ynOqPXB
	ZQ+7ivLxiaqKwilZdewg9yjjaaBgOdEK6TOXrKTO9a7Zk8HmgvJZtjEoUdNJCA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658696475; a=rsa-sha256; cv=none;
	b=Cw6DzWc9R7nEYH6gtKG5NtTeMaXS8L0J/v2SYaJqyYM4quwza4WL+9FvbAozKILEjcfP07
	fYtvX4vKUcrrkfdFeh8K8AeSJZ4LzshNihXDBzVTvq5Kw/JA6C2XwgVrxA3RJkMA9e5Hrq
	/zoNu2A2woM5bQwSyP+vQ6Dh3ZZmEKscGkJ+CuRRmse0CL3hvNE84b8AwoizgkId5S9KKy
	3GScHK1mzOySzm+T6cR7j3/QH+GBCEpE07++c6V6C6iYn7k+ela50acBjGYuykYmEr9FDE
	jIoRblUGk7zf0XzpJQjkFF39IapoeKztNZApbhDS4dIuHZcvEsX0OLcrHsfxsg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16586964751.DF3fd7.46589
Date: Sun, 24 Jul 2022 21:01:15 +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.

--16586964751.DF3fd7.46589
Date: Sun, 24 Jul 2022 21:01:15 +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.


--16586964751.DF3fd7.46589--

From nobody Tue Jul 26 20:14:50 2022
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 4Lsp6p5k4jz4X4Fl
	for ; Tue, 26 Jul 2022 20:14:58 +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 4Lsp6n4RMkz3MPq
	for ; Tue, 26 Jul 2022 20:14:57 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 26QKEpMD004006
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Tue, 26 Jul 2022 13:14:51 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 26QKEpft004005
	for freebsd-arm@freebsd.org; Tue, 26 Jul 2022 13:14:51 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 26 Jul 2022 13:14:50 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Subject: ld: error: undefined symbol: xdr_domainname in stable/13
Message-ID: <20220726201450.GA3984@www.zefox.net>
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-Rspamd-Queue-Id: 4Lsp6n4RMkz3MPq
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[zefox.net];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Just had a buildworld stop with 

ld: error: undefined symbol: xdr_domainname
>>> referenced by yplib.c:471 (/usr/src/lib/libc/yp/yplib.c:471)
>>>               yplib.o:(_yp_dobind) in archive /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
c.a
>>> referenced by yplib.c:471 (/usr/src/lib/libc/yp/yplib.c:471)
>>>               yplib.o:(_yp_dobind) in archive /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
c.a
>>> referenced by yplib.c:0 (/usr/src/lib/libc/yp/yplib.c:0)
>>>               yplib.o:(yp_maplist) in archive /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
c.a
>>> referenced 1 more times

A re-run of git pull on July 26 around 1 pm PDT didn't fix it. 
I'm using -DWITH_META_MODE, could that matter?
Any suggestions appreciated,

bob prohaska
 

From nobody Wed Jul 27 01:40:25 2022
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 4LsxLW5gnxz4XtMt
	for ; Wed, 27 Jul 2022 01:40:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4LsxLT65psz3q0q
	for ; Wed, 27 Jul 2022 01:40:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658886032; bh=n73/9hEc9+xTNz9lIxkEjVxgzlFQB76C/R9N1b4j90I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KnXhIF1kD0wV59qOit9hW6WAOaWA2A8fQpLU9xF3NsoPpJtdiNwm9KK0Ee6YJzXpwM803Ymumfm2+Jtc5gMnVD0bovNixRG9lCx7ODPCHBSbpD+yvHITNcaAcvW1dLxUV0vQrZBFZ01RC6lMvgvZvT0cxWTbh6UWpJ/bn8f0E8d1JBpVjlQv3CTC/Pxc8pOZHiX1Y2Jn/TyvXVcbwH9KwKQ/RKXLnE42dlDQl6uh2hiNrzmj9IV+tA9FYTsBPY/puBr6l8WhhZydga+jjsdmGDw6gai1z4Dlk7JuPKunFuGUyiCoS4Te5apKtE0xvgjWTJw1qReQc2dWMpASQlTZxw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1658886032; bh=pCG9QihvaRbgJHpvRbKZjmNOiXWZqjJm8n/+Og6clGZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VwaYnBJX1EYAViN62ypTAkJO1OGssU14pDj88fLrZh91+RQe6AQkG3cwV+xR1Llr8vr0zAv3/fxk1ELggbveKjFqBvoKe/l+OpEv1cMAtHoj07zYybJatq6+DwhSRk60qFwhxVVKPxWd5+aQxlgHr2V/MQvz0wNKtd5l1ZjQye4QGIFrCnTxrigk5u1RSgJ5+itc/8M9oMZsYPYH0iQrxa/dNqMsLidqahHc3yXCGzliJ1yaz+ykbFVGDX8lRHGW6mvBLfkAKLr/85BWePSGOKgJyuQxyTGiDHXUtAKUA9U9CMvqHdldXTLmy3f9wZzNKfYhIb90WLgMXmp/LcrA1g==
X-YMail-OSG: FElSMSYVM1l_Ri41symHFKNdzwAgDBS9dqiVzXXXJVsbHDpEIY4pWpAsZ_.QLv4
 0HYIR5h_AaZzAdKMNwz6zjB9NZrMCDLZRknlsUGnkg87kFHS3tabnPfjgFfejjhWzFEr5hj.jh5h
 6NMRdMVaIQp_VhyOvWmDVzUdmxQxvCVwXPedu68z.WGz59K2az7H_RlbfrszI57ObeVoLjirK_W6
 Tym91PNQvpRwBGQSGqWTH8Z_ZR7weDZddMlk5DlW_cMP0T9wLHBMy3lOmTLeXLlUzkGopEu.rqq9
 YULpi9uC39_Pyb5.re6dV1Hz0LI8CReGH0keLomrJhlUC371B_AmIGMAlgjcWv.kcwl2joxjfxn5
 we2gTOBEBZbXLKGbBWM_JLJhWhGsmZlqfoHnSMakratyPWui91OU1EcDJDCyAzXP6mpy.g5dTc2L
 nheeOeVRM9.E5oBKbA..aE0P9sy.pWUWcwV6rHBnhAzjXCDSDhl9hN_msJVq1tJA.0WUv1z9nXdh
 Hm.sqBXLZN7hDckIgH5bnrYTiDqPqzluPamwej16FpISR08HooAi_mpGGlVx_MIXxE0ym_qpuCcy
 B8qEUAZd7hvF2eUpyG5zl23kjv6wjfr2y6.OEw7NQpNS9aASww_gKRR0B6jKtTp78V0gUy4sYXxv
 _jPP6OQKY6Xe6Igs4xH2iLzB8HvkzCL.YSdW8MuPGPhF_3GD4.zyP49uRT5ZErkSQOkkWSg_C53O
 Q12_uUDCjQtsGLjn1Ta1FUZAEcIDUubgTgBcsC5dAP4258R1cw9Axl8EjZum1sI8hkQ4bU3wTgDm
 wv.jPQUyEMX6sKsRZ9gLBrjmENeo6JUTQgYr_DmdSNXt19H3JZc_4EzG_u.EOXMVZP5vgGw2jJOB
 8FqONLYHp9SOv2xR.VeV3zEHmiY5zWRNNYOn6s2eUh9QQ_AZ6nrT0FErI6gpq9dcvsx.YnHQ1RUD
 bkVoyEXZuBjHZyPrqOh2KM2eEf8.a7khuZTUCC17VqTy1WBIOLoQqpqXPdR5WdjB2Sxx1yb4IMyU
 .mMMbR.nJ2r1r9cVRzXmIcpTWH06YgqOz4hN.WQQ6b._yMz4arb3nP5swhqFmvxo0wX3fzelNj8k
 HLnvecsBtHObIxyIKTVoNomrFYimOExp3WAqjV568B6uQzppieF_zkcd339bxcd5H.7.K8gF8cDB
 OZLWscA3glPI9Ao_Yywygqomcn5M4OpNj8e513pwEaX2IZb054yAlo57hXTlvm6SC0jiW_VKEBI4
 E8wEcVS5x7nObwh9CPiO7jS4Zl2L_jmDeyT5vE.fiv6TyN7TMFihbjgSBRODc0FS3ZG6SiHHJZlN
 uE22i9LCwslIZ1o6scBqZE8foYnQMWWFMS4q6JVff9mq5HS0401TvEE2p7jKNM0WZy6sxhS5a4WQ
 igffwYYli501m._HodKb8r5yBkF_K_vDT4AnpnwjuT4uqdrToZ7lU5PLkGinmJ_.B8o8pcm_Rgf7
 iktZRCbL0vjshdUs_QAe.Qyb71ZzoiJPZUdoW.1XCaDfE06txbtD8sMUZEokk.UKEIXI9bnGSpUj
 .bjmUPceTzDyITW6gkekW9DVwFdGs4IpxHTSbOBx6ir6M6K.Tkaz51SoJr1TMPxrhcBM8RrMzH5Z
 47d_ixIibClFfXzy6PSKuf9hIUQ2INpyMw8D6HyywJZJy32CX8COo0RvcJuM3hrMQtfSYLedCQ1S
 6uc0o9XWI1PeA4miwCzVi5KpQSNkSvyxPtrHZfpmdzh4XmP5ojpziT22ai2Kf4lrUHJ0cd5hcDPx
 ztYmLiWC6NGpfGgI6YVdhVBGAkKvCoB19kjLZEjsXAb7oJpUMfenR2yo4CoTaYDK6_LVREPVVBhF
 .SBsDUfYNGcbXf9a6GGEUZ4k8LFF1zqCQlcaK.6d1ftzDVsrnH32gpvLc7ucV1z2kdbYr_PYI4je
 .LZySgk0qsUUtGGH8LKIeMeLoBIXzY0sDyOPufVEhTXfImAsK8NpmPLi93CoZACa7Fl6nbN9jPB8
 MiFDs3qAqFMPa.zSTRBrNe1sbSGmu5ZwunSvZFEt0Ci6cVTCA296kp50FHeTWLkskLCqv5TWV61D
 0SHD7SnsCRQe2DToCXucoLx0VLw68Gkck6PU11tgYSIq8fgkvPuhE3mjUO98ZEAudo8ArFm_mhIZ
 K.o6tvTGmy5wH8FaLa4I4mE4QJmdc9HIJXWxhdrgpKrWNuGuwPRW1CNSpUoReT27Vb5gjUblJJUM
 DmCOSRW4sxRX1sdbNHERJW8ZRIpxZ7gdeo.QPienZiz9NJ5CH.yYoXZDREIqQ6t1ExJCU4HUwifL
 Cpurm
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Jul 2022 01:40:32 +0000
Received: by hermes--production-ne1-74ddcb6b46-vfl4k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 849731f49722be8db743e3d4596ae557;
          Wed, 27 Jul 2022 01:40:27 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: ld: error: undefined symbol: xdr_domainname in stable/13
From: Mark Millard 
In-Reply-To: <20220726201450.GA3984@www.zefox.net>
Date: Tue, 26 Jul 2022 18:40:25 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220726201450.GA3984@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LsxLT65psz3q0q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KnXhIF1k;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_MEDIUM(-0.93)[-0.931];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-26, at 13:14, bob prohaska  wrote:
>=20
> Just had a buildworld stop with=20
>=20
> ld: error: undefined symbol: xdr_domainname
>>>> referenced by yplib.c:471 (/usr/src/lib/libc/yp/yplib.c:471)
>>>>              yplib.o:(_yp_dobind) in archive =
/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
> c.a
>>>> referenced by yplib.c:471 (/usr/src/lib/libc/yp/yplib.c:471)
>>>>              yplib.o:(_yp_dobind) in archive =
/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
> c.a
>>>> referenced by yplib.c:0 (/usr/src/lib/libc/yp/yplib.c:0)
>>>>              yplib.o:(yp_maplist) in archive =
/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/lib
> c.a
>>>> referenced 1 more times
>=20
> A re-run of git pull on July 26 around 1 pm PDT didn't fix it.=20
> I'm using -DWITH_META_MODE, could that matter?

I do not know overall, but the source code for the routine
is generated by a tool. Your build tree should have ended
up with a:

arm64.aarch64/lib/libc/yp_xdr.c

that contains the source code for that routine --and for others.

It is the compiling of that source and linking with the result
that should provide the definition.

For reference:

# grep -r yp_xdr /usr/13S-src/ | more
/usr/13S-src/lib/libc/yp/Makefile.inc:SRCS+=3D    xdryp.c yp.h yp_xdr.c =
yplib.c
/usr/13S-src/lib/libc/yp/Makefile.inc:CLEANFILES+=3D      yp.h yp_xdr.c
/usr/13S-src/lib/libc/yp/Makefile.inc:yp_xdr.c: ${RPCSRC}
/usr/13S-src/lib/libc/rpc/Symbol.map:   /* =46rom yp_xdr.c (generated by =
rpcgen - include/rpcsvc/yp.x) */

# more /usr/13S-src/lib/libc/yp/Makefile.inc
#       from: @(#)Makefile.inc  5.3 (Berkeley) 2/20/91
# $FreeBSD$

# yp sources
.PATH: ${LIBC_SRCTOP}/yp

SRCS+=3D  xdryp.c yp.h yp_xdr.c yplib.c
CLEANFILES+=3D    yp.h yp_xdr.c

SYM_MAPS+=3D      ${LIBC_SRCTOP}/yp/Symbol.map

RPCSRC=3D ${SRCTOP}/include/rpcsvc/yp.x
RPCGEN=3D RPCGEN_CPP=3D${CPP:Q} rpcgen -C

yp_xdr.c: ${RPCSRC}
        ${RPCGEN} -c -o ${.TARGET} ${RPCSRC}

yp.h: ${RPCSRC}
        ${RPCGEN} -h -o ${.TARGET} ${RPCSRC}

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Jul 27 16:02:01 2022
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 4LtJSX4yDhz4Xvr9
	for ; Wed, 27 Jul 2022 16:02:04 +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 4LtJSW51mWz3wKc
	for ; Wed, 27 Jul 2022 16:02:03 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 26RG22Fp007956
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 27 Jul 2022 09:02:02 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 26RG21IU007955;
	Wed, 27 Jul 2022 09:02:01 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 27 Jul 2022 09:02:01 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Subject: Re: ld: error: undefined symbol: xdr_domainname in stable/13
Message-ID: <20220727160201.GA7920@www.zefox.net>
References: <20220726201450.GA3984@www.zefox.net>
 
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: 4LtJSW51mWz3wKc
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jul 26, 2022 at 06:40:25PM -0700, Mark Millard wrote:
> On 2022-Jul-26, at 13:14, bob prohaska  wrote:
> > 
> > Just had a buildworld stop with 
> > 
> > ld: error: undefined symbol: xdr_domainname
> > 
> > A re-run of git pull on July 26 around 1 pm PDT didn't fix it. 
> > I'm using -DWITH_META_MODE, could that matter?
> 
> I do not know overall, but the source code for the routine
> is generated by a tool. Your build tree should have ended
> up with a:
> 
> arm64.aarch64/lib/libc/yp_xdr.c
> 

It looks as if it was a local artifact, probably caused by a
robustness test (plug pull while running buildworld) a few
hours earlier. A simple "make clean" seems to be the fix.

Apologies for the noise!

bob prohaska


From nobody Fri Jul 29 15:04:07 2022
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 4LvW506qRsz4XR1w;
	Fri, 29 Jul 2022 15:04:20 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43])
	(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 4LvW4z4kfpz3Jbt;
	Fri, 29 Jul 2022 15:04:19 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f43.google.com with SMTP id l23so9012182ejr.5;
        Fri, 29 Jul 2022 08:04:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=pTYK92VpyXKekIHr9jtfDpymIAioz12t7Bs8dKTGHOA=;
        b=wD3nbbywwz31GmS3ukqFJ2fEOhNeajBlv2ig8xCqtVSCdM2d6gIJr14bqorEmX4FqG
         qLCr/tGYZX3KUnTdvqHvFOhNB+JEfMD4Xu4AWgZURVuPYL9Chxf5SzsqBEa1p1LNJs4T
         KGKXyAB/QiLgEf8m3XZmXNSRZI23xbbLus6w+7igPXClwlwVc//u2kfM5ZEUT4RGz05y
         4rz7nd7dHx+jTPdzyKhDnE0WC+VmdDlEMfDbPnI6+NKStzbrtz0JovF5+FKPTDOb4kze
         LjouVAbt+PD2a/VQGPzYK6SieKgCykpabZ9eYjm59wTutkZMRNWWwBDzXIUVcXgSsQJq
         9RbQ==
X-Gm-Message-State: AJIora9fDQtoYuM0dtln35zErbGhiPvj7cshh11fF7+/z0F4V+f7YEjC
	P9yjafWpRaSQuvbj1oGoIe1zG+KvTqx3kwbtgw38PaWF
X-Google-Smtp-Source: AGRyM1sXGOIaamdrauuptLOtxC2kLOwPPa/0yO8oAX8g6ZMYc+7bs2Z01RKf6vMtvXnAa7Q8tRJj6n7yTPD6XQoNq9s=
X-Received: by 2002:a17:906:ef8b:b0:72b:4a67:8ae5 with SMTP id
 ze11-20020a170906ef8b00b0072b4a678ae5mr3221475ejb.763.1659107058143; Fri, 29
 Jul 2022 08:04:18 -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: Fri, 29 Jul 2022 11:04:07 -0400
Message-ID: 
Subject: Re: UFS checksum error during arm64 VM installation
To: Wei Hu 
Cc: "freebsd-arm@freebsd.org" , 
	"freebsd-hackers@FreeBSD.org" , Li-Wen Hsu , 
	Souradeep Chakrabarti , "andrew@FreeBSD.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LvW4z4kfpz3Jbt
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
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)[-0.996];
	FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.43:from];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.218.43:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEFALL_USER(0.00)[carpeddiem];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 19 Jul 2022 at 02:31, Wei Hu  wrote:
>
> Hi,
>
> We are trying to bring up FreeBSD on ARM64 Hyper-V.  We are seeing the is=
o image booted up fine and we can install the root disk with ZFS. However, =
when choosing to install the root disk with UFS, we are seeing UFS checksum=
 errors as below and the installation just failed.
>
> ...
> UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 41, cgp: 0x45721f90 !=
=3D bp: 0x23b0cc8
...

Hi Wei, I assume you're trying this on relatively recent main? (There
were some cylinder checksum issues some time ago, I think related to
growfs, but as far as I know they were all fixed long ago.)

From nobody Fri Jul 29 20:49:43 2022
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 4Lvflf4LMKz4CJvl;
	Fri, 29 Jul 2022 20:49:50 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lvflf3qK4z3JGZ;
	Fri, 29 Jul 2022 20:49:50 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659127790;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=BBou+W7p3PhIfJtVtTCZwKptN83F5BGslbFkhZ1pfAU=;
	b=a+rqnNQ4O7R9lpdmd1fw0QaSpXhGdqB1PYu42IAjh5O5KI+kQCjbgzdchmRs8CZk9tgs7I
	oqyluakk0MU/BcBoppDUpPql3bTcVSnXK8rLkg68/QH2AEJQRaz6xNJmUp5MfrhAvnq9kW
	6p5tcnpnSBlB/FXmDXkNM8eTq90mUmmrVSGnLQJQxmQi/MnhqTj5+Mw8NQr0VFnUZfZzdo
	/9iZhIg1SuB7B1S6KG9WS4nEhpWn5Pux92/aLmLicsH5jy8czas3mom7Q3kC87d+cCdaP+
	PMX+77ErgIQb8KKwK2WyQG+5if2IeTf76WPagPW9SLcS/7hdlO/IPQUGIrsWsg==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id D33711719D;
	Fri, 29 Jul 2022 20:49:49 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Fri, 29 Jul 2022 20:49:43 +0000
From: Glen Barber 
To: Mark Millard 
Cc: Warner Losh , Ed Maste ,
	"Rodney W. Grimes" ,
	dev-commits-src-main@freebsd.org,
	"Dr. Rolf Jansen" ,
	freebsd-arm 
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
Message-ID: <20220729204943.GT30607@FreeBSD.org>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="7xyTZubjuTCeHyoH"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659127790;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=BBou+W7p3PhIfJtVtTCZwKptN83F5BGslbFkhZ1pfAU=;
	b=IuBNPT1pGJRbMJkMuqDNSS2KFjDmCQCnUnnjELAllI9BnD93VdzNgPYK+n+NOcZZRxQzUc
	NHyJZRtyHaX2R4fe3zXl2NfIT6hk+qF6un8VoXfrarMQKy5Lxyk/PwbzVve98d45GdyOnI
	AAVUAK2Zm9MinhXPKx7XEi9muYRipvmxDZ4emwUbpigJ79Uo5RtOIC5G4gnr5GKy3hrvLS
	alfnH4fJppUbYTG63bg308jUMy/STxeqvL8B6fgAcmkKGr42+cqGKCjVfEr40PHEE9Vqp1
	G84cb9gKNOjCwW+lZBJ2Xp1qfMld42h1ita4ypsHU2fcE7OuD5KUj2gORnBf9Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659127790; a=rsa-sha256; cv=none;
	b=El2gs+/gYzMlaQexdiCz+/YEjzKMct/u1vqC5Et+TVOQ7usNtCB8eYe9shgtTv/jvesEqL
	Lg1TWHDJp9AEF1+Q9ObZfmdt/M08mjzEDnZBlv9HichN6EpBLGwMzlEmyfoylHIGxgtjkx
	3MWP5ggd7YJOaCRfDzdOVZrUU1C2fnUWlUaCpgwSLorQd6GVKrjFaHKeVsUyrvVXrKBAiS
	YQv2X6iCpWMGHtXcU3BxK9GLYBJGrenBoe5pP4EWpS0bFqJ73iFo4xXMIyh+DrQEERpktm
	4b/y1KT7lgPHT44Ub/FlOBUHLYxd/7mnwETsq6m8Tri+JBF7LbPdYBtw2EpSnQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--7xyTZubjuTCeHyoH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
> Would it seem appropriate to use a week (this week?) to do all
> the snapshot builds with the builders all set to have
> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
> (Sort of a snapshot exp run.)
>=20
> More than just the SBC images might be involved for
> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>=20

Hey, Mark.

New snapshots for 13 and 14 are up now.  Is it possible for you to check
if the issues you had run into are indeed resolved, after setting
kern.geom.part.mbr.enforce_chs=3D0 on the builders?

Glen


--7xyTZubjuTCeHyoH
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLkR+EACgkQAxRYpUeP
4pNl+Q//QOOYTXtNMMiJHI8yB0pWIHslCHEp4+nxPRrjYBFpxhZn23I//dup3h7F
ULUY0Q+B1wGKYRyl+wEhH2dQDtpre8xRDW3PQxLV/waM1+DSRuupauYZs2y4OLr2
f2+HGS2ID27uE88QiZ16rOADTeXVUa7ltziIUQfugs7Q47dfJ1xErA4OQmml1sQC
sLJ35IRsuwAke+0sDu+cR9QK6PbkNB8bpI5kX/b7S8KwoiMuteZv8wWQi+pJBZCX
SLIcda8x7izvZD+4GrKxeWYRiYZ428QBipzTnwPPsNXDOCtHwfu0PDLMK3eZvF+0
M+n7SdswXUgEOsHbTnMNaOy/NL3t2DJuTvvkCp5o68R86Qw7UUN5DWI3hg7cY9o8
npfbbKIkTngyiT/Jz3bM/9TA6nDdy8tEPlxfQfaREH1QP3/x/jBJvXqvgjMt2hft
jo1Rma+2DRFWhQuton04Cyx/fByswx8uGmmDhDA71Ci3eh7pkc/gZHRik1AVToBE
7o0x19xhfYz/V3WGZRw1o4dZB9ejE1ObACCs3Ls7zxC3PcY+B5MGaQGzazEfvHh5
pVq4MrW2bnTOExBYx1PliX95/71g1lZsJtRFEBuwZhs+1Ncr3svzyyGOrDb8ZY0w
BjcUp1WzakPfYXrbOHhskV1jvfPXHSeli9JhmVgy0drYOFMGBVA=
=HJQJ
-----END PGP SIGNATURE-----

--7xyTZubjuTCeHyoH--

From nobody Sat Jul 30 02:56:18 2022
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 4Lvpth3pggz4XsLG
	for ; Sat, 30 Jul 2022 02:56:28 +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 4Lvptg1Dzbz3wS4
	for ; Sat, 30 Jul 2022 02:56:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659149785; bh=ywhUQTUmq7UUvNtS3jMcNgpU67c3hoM4iFiwr81OKS8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=q9iu6xy8gXJHRnZQAz5Zotqm9ncDM+h09F9fLee33VbFWejJgI0RV+6aNlwQlRgirPLwj6BthDZJ5xTebL8BE/OS623LHYJcO7iW9tgGuSWFkMAoJUXxqIe0LH/OUjLhT3aZ4Im1gcbYhyaAlYwoIENLAL2/fopVEJt0zPbF+5H+6FM/R1ejUiMBRTylU+Qh5nu7I+xY6VC0uhkpC5vJNJaculooitVfdOkd0jqujumZ69RhtrLWl1VRxV33KZaFPG/SuJlzFAcU2iy+FP2TDqDjCWaprO1ItA/xGb6Q2B1WzzUJxfNhIr0zgDuimgf9HUC4NxhFattFWxeLw0gt9A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659149785; bh=4Y6elui4ICR65NbqHellP7v3AutWJBj5YD00RZAZeVg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Hcry8Ln9bM56gu4HCBpAHpGLs6igbberM0EtLd/kvsYa1roxVHd3rBw3Qs4VrsnYC6bQgq+SVPS8Zj+IE31mbVBBa6lcppUFry5H5yszp5j0FU8V5tyJYzbFhej2T1Jz/FXQkYSONl7rraLnrNBN/Ljv23yg+s0kekXyCpQKIFjv7DD0fFWE8GqiDym5wlbZu9uFHOQ+7/ie6g7NMwH0bCwHUtEb8d5+soI0j8KxT+1oAgGtiJDn5pEfGv1kPpBM3ME44W6870NJENTO3C4RF5G80sxJBwgbVp9NyL9x2Y6RpYVnFxDP5z+2/YGjvXVgTOPWrhzIyO/KuxuQzFhZ4A==
X-YMail-OSG: yssl.HIVM1kmVK9UqXQ.Dp7rgVpiHANFHyo5RP.vWJHAXUYmwty7A7S5yrekhqg
 _6YvCz9BgZbbgLHDyGC5SuTJXUUBv0PJ9Jcj._8VFydNVPHpZFGGqMO.ovLjpa2pvOwr035S8kwu
 27KpM_nSGMZ8sc9lmIvq9FcRPCUn9KutTZw7mTIkFaYxQybvu0fZlcD_EaxeOGaSWxuyaM2NxvXC
 _85GpRsXCS_Hz0wCvm0of.rTDRmiwTRJKCujtfhdeeOQj0SREfjkUs4hYVass6.6AWJw_7kO.Q2a
 tWetacdTRWyRr7pj2b1kvXDgSukyqo.lEtTSOJrbX8ApIFq.ZuSjcr3EjnMXeQJ3qGpGRy30Ix2K
 jmPtC1hLE9TDsXmC.ka6GMRoKZZoeqiGWIA6mSZk4NUEHs54pKZPypLRhLLcQmFMAg1n2ETdFrY6
 vHOkCVrkt5n6aiT1oZXAE_jRtEb3J5SIGJrSgXo2EbkS8TkfaIQry5qkxB6Qw2RwWVxK.g.0fRXh
 VEIer6b8MXIYGRi6BB5RlsJ5gQDVp42vjOMtfivttdZ.h2NWIRAhYWtkn8f2nK9AFhOif6BDm1AW
 Ls43yEu.sMHg.Y1qwh8BvtE2_4pwJcafQR8WJBZbG9bSU_wTqmt0sNIiF0Y7rUr_fAU3.cLbC_Ud
 9SK4omVnpe4SIR7pufeDv9SvttUIXi15bhAINSkHCAEiF_hUekDcBJ9fphIlg4_zAe1G7DwaAXCt
 By1G79ctPg2AQ1x2uEYJj8pQ8HKxkygrFE8T7LvivUm_RZB2gPPLSEXLpC.EtssjwAgG_U7ggjyJ
 CVarby14uEUF830xwC4UQoOTeksEK6GW4SXd3vD3GurAxbzQOQEFB7Yslqp_i7ASn590T96vlrSR
 i1Or9P4xcHuMzh.Y25DuFs9q3Qs01WexC5IPDC0WBkELqytJn.fcsjN8MtTu6krpLrP25ATJb6Re
 Vl5YQAVQlD5kEJkUcfoHFrBClFzlrR03oZ0chBDYgJS8.1qSNaVoYo4mHs9idnM3tlUhsBV1QVh.
 J0e7wXxwlsqBUctIkddOilLfRPMHhdbXtce2uUvkm2ia_lvglIReI_VmCj3GtPBk95CDjELKYZZu
 XML0ItoGHg.hJdsNPcAPEOVekroXPIJMadRxrynKBlhtCcHAhjytVcQzCSUoixFfbXQNlJ9JBVcy
 BqXqi7wsAnRXMULP2ueM7p2jd4G73qqfHfQtJvuse1rn_GleUhEWb4g7hhk1XKQ2FYSPAnFMUOpl
 OcRtCamHmdidW8RQADO0Q2DyVfXqAAEGpiDRAukrn6JOAFez5ajgHAuXM_TS99UISY96t.WMSUfa
 VGDlfz_3kpRS2oKPTH2x8SAgsGENclmK4A14rcnfd6.GWUrbmh.kXHmEszdrD4P8ZNS.oOmStGj2
 3hk2geDPH1AE5umYd7FXVBbsIq75wpNMlfIOsmXyS2tFvc7M0J64qbHEakmJ_hUqhyUeWfED0xYD
 6PUTCZmq_cR.zh1Bl8dGUGVKf5uv_uln76DnvMsz4uaIhvM6GDNs70EhlX32zE6F7_ubygB7sKl1
 hJOs0IuDGkfA4mbTkY.XMCfkHKbnD5xhqs8zi_DpJZgPFLg8AABuzTvXeJjKkai9NV9uIctPiXMm
 hyoaS1sW2CoaHtKWIB.A78OUupusqa9JhtyEfRiIc4eKXfWxHHdCR2hZp8NUckHf0sVeupn4VeWP
 c30g1JJssg8zQdlPpB1X3pIeAIrIUW1e7OaSWAG54jrueJfunRlG6gGx4Tv6FCsXtz7MSJ7EBeQ.
 mDMfDnKIgMEGoMLc6ubJxXygnyln03xEmCbhakj05DoanHC6MPMP7EW3vFXG40ABvUPaCCsBnCft
 p3gTcqF8AY2PR2vSoB5YqtsbgbQB0HFdVciughA8vxQu0lg_GImLIWmMu7oal075AcaLf.KnvvAi
 k13nCYjcqDXnw.r.Hhn4qbeMowNvpPmwJpVZIGRIZHPei98A1aK8ViRUQUPKRpyDL0nG2P_q3m6G
 IQVVZY7PFY62O7QHMJG6i0F_gq09tU0kJzqBfzvn2fZbVH1vkuy7R4pEpL9D05gDNGjGcLZ95tt9
 PDYJh67KTsU0PW_EC2vvkqC8jgJ78ckzfBjIYY3HJB.tQXla458pfuh7DhXCUqkB9OaxfF29Ih38
 OLsp20DjDHQEL.2Ln7qG95vTqpq3XV.71ClHvMxWFHGrsFWIhRsaminQjJ4RCFjjarHufszlbOGu
 WmuBaSD09GOuvLb8WtIZ1MPY8RXUw0hSOuVc8ekXbCSVuX_vELF0j7yUyAEfPKA1jXp7J.xCsbEh
 z
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 02:56:25 +0000
Received: by hermes--production-bf1-99ddd9c9c-dvg85 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d221d3fe02f280466eedab9b22f3d821;
          Sat, 30 Jul 2022 02:56:21 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: <20220729204943.GT30607@FreeBSD.org>
Date: Fri, 29 Jul 2022 19:56:18 -0700
Cc: Warner Losh ,
 Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
 <20220729204943.GT30607@FreeBSD.org>
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lvptg1Dzbz3wS4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=q9iu6xy8;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.91)[-0.907];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-29, at 13:49, Glen Barber  wrote:

> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>> Would it seem appropriate to use a week (this week?) to do all
>> the snapshot builds with the builders all set to have
>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
>> (Sort of a snapshot exp run.)
>>=20
>> More than just the SBC images might be involved for
>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>=20
>=20
> Hey, Mark.
>=20
> New snapshots for 13 and 14 are up now.  Is it possible for you to =
check
> if the issues you had run into are indeed resolved, after setting
> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>=20

Well, it is a mix, I think (unsure).

I started with:

# dd =
if=3DFreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img=
 of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress
  5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s
5120+0 records in
5120+0 records out
5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec)

I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted.

. . .
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 blocks, 0.1% =
fragmentation)
Growing root partition to fill device
random: randomdev_wait_until_seeded unblock wait
random: randomdev_wait_until_seeded unblock wait
random: unblocking device.
GEOM_PART: ufs/rootfs was automatically resized.
  Use `gpart commit ufs/rootfs` to save changes or `gpart undo =
ufs/rootfs` to revert them.
da0s2 resized
super-block backups (for fsck_ffs -b #) at:
 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912,
. . .

But, after logging in:

root@generic:~ # gpart show
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

root@generic:~ # gpart show -p
=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

So 1985 and 2048 are there, as intended.

But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up
in gpart show's output.

I wonder if this is because of a lack of a distinct
starting offset vs. the BSD. For example, the old 2016
and 2079 alignment had showed:

=3D>        0  468757737   da0s2  BSD  (224G)
          0         57          - free -  (29K)
         57  468757680  da0s2a  freebsd-ufs  (224G)

where the 57 was, appearently, for alignment. May be now
the distance from the da0s2 to da0s2a is zero and so
BSD and its contained da0s2a is not now shown?

I've yet to try the 14-CURRENT.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 30 03:11:23 2022
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 4LvqD20T5Xz4XvJp
	for ; Sat, 30 Jul 2022 03:11:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4LvqD11R2Nz3yYV
	for ; Sat, 30 Jul 2022 03:11:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659150687; bh=LZ8xvORRyfGTWFwGrcJ/OTtL90tMeJ4pyB+uiYlqHPs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mX928mMifRoAf7vSjO5dK9Bqz++1Vti2mvDD3jwvFVQyA0W3IgMeNBcqJQ8VttmilGi/ChEo2Cxw3TmOE9dKB1KTrZRECh/ycXWNbYqSD/HZBeEwU+Sz9Js/Nvo5bIwpUSb9Q1zuNXxqU8LF09uEn2+TVihOFlB5unM0b46muqjyoxewWZ7ykzJa86906KcdZSynhAB8lSjDXx4OP0vOPVM4oUjZTuv6pij2HCeW9sUlMe67ggeHUTfcuePJ5TIv7FYnDPvTTCrAS9QGqrfD/c8XQzUPmPwWb/KZhqpUVKNbblaMriRzPRZuOAWKKVa8ZYazIdYdZs/n5CyQOUqQ9Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659150687; bh=bi1xHrepn0+8Q0n0NcMzoBqvDKeLt+Ow//8XvB7/2J0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dJfoIhkSCzu3LHy+xjlYv+Q6hpwCGU/acXfhq0B0IdQRQizpDVMLJAmcIj3CCXt9T07HSXTNsTsOB/DRhii7zotatkae9WHY3NQwZTVDfPcSsq8i2pgV58AQkfryiw2vojdIiF6/x81Oojmre4T5wmjtvjBQIMF/Ukz3CNOF+RTrZgxYT1Z/njC8IAqw72PbGOmEb2egeKufrtxINEFlaQGcHIpU6f0WIMP5DlUJf62PGLGMJ+TYci5RM3N71oK1mJ4Nx+DxRBddszuf+mZDdjH5Tt6lJJm+oyOe3/DUlfh1/u1BSCwlogZT99VSbE57ZfMbG9ySKIQns8EWkR+0UA==
X-YMail-OSG: GyP6LW4VM1nJhiZptBQ38jl9YvdhRk26h8Pwd5UfAZxRBhq8akRDX9uCkxiy4DN
 vy.s5YIWaORl.1ea2LwfH_kVDuiVk5FSX_tuL3dHJOSY3QUKnomzkUZ.sr7uV9jJP2.DNiE9I1.u
 eSHdJkNr8K8CTh0WVmCCJB57or8bnup9pKvSE3xmJuuJy5ShJn33bfy20PMHLKupnQwxZgLgdXxb
 NILMuiGcNNtRo1ffiebxFZAHT8AhdJhwWwUUMU04ie8Jwldax7ibx3h8XdqwM.aI.7106o_5Li1j
 jKcTL468psAH8NhHUHo1s3Lx6yqUH69w4GvsyNBd9B4yC7ABTjY.4KvuferO7f6d0JFijW3CQCkT
 BOznNsu1di6b_hMVHYiD55FA89EapV7_VnSQdOct_gLJucsJbbXp5xlSdSK21.MTfGl_XYQ49D3r
 Pqi76RE9VjWfKiumowlC0FRj4MW4yny26_KT4xRBZAPaBgXaZz5VsCv9H9FZ1innfKPoJl2_cD2x
 5umUhcK4nDoD6Aj5nq9BhyiNmCnQch.M2uN.fp_n9Bs4HiQJ6XOeNjHeailZkr5hqRW5RZkJsq4f
 EqPCxdEVmDBONmYDdOAF4UuNr.D.59EvYAnHLG8GtIGeXKLvZ7LTutHssmIt0ukK6moCnS7Pte4W
 2dU6aEPtGX19TeWx5VTzz3sgiF5veBqauic9MES.6bxwqAPxCC6kU94pi6N.rRumFc4rIMPLfsfR
 QWhORCM2j0P.l.abU7Hypw5ddUYBEgfdHOBXGh_TWNmkZBpkKCYI_MZV6vZqLZKMUCbkSK4PzIiT
 B5OA9pY_NqTAtiisgpX3Lva7Je79FmPGtAW22_qZMegBWTEG2APrHPb3tnd_CAxeSzbL.5MP.y2w
 .cKnIWVHL1JOrqXEVZwd7hMv9rozZbuIpM_N4GN1tl4SFQquA7wQejp8cFpgen_CVZgKxD1Becw1
 61GWLDy8apc6K7cMF1hxk_jICrm4rU49NQoGR6PUbj_1LSOh50W5yx15DYSciSbyzfUmAH_90D1K
 T5s0WmrVx59DAkps5gJ.iu6s2TqAd4H7G9.HQujwcx6uW2Mu_96UDPw27ndWbNnT.6xIW3VGZggO
 jiZajkufmm92Md9LIDJTGtwcK5coynrR7LUGCA9.2OnF2hTC19C6xmIXk1qFveG2weS5Mj5PIw4h
 k3_EH.RENZHEUGnEs3fQL18nhUkKoHDCbJRtQfUlQBl4O.nj3pHMZ51DZzB8tOMNnF8B1k3ZpcXt
 OPebvcl7Z47VhJ8KMWtuApdjcc752i1j0M_fugyLLofIiZ09xDrGnFmwhWEAxjQZNH0HmZsbr8Uw
 0MB8fMImEDmpY0N06tYw.x8404J_Ocx1JWJTDY.._svWkaODJpi5uA9vVckifJ7K7m9C1W3b3xpj
 FDfNo7xrDc7n3d9MB4dfQEI09Du_kMX5judV1QZAVaHARP7WWHH5jUKpUOUVF0JEI1whyA_kYZ0B
 ehUBy9W3ND8iOHryIVGl8FSKCfODi6Rd2ZKUNLFU2s3sZgMxN.8OmIYWjg.KrC55yCjEtgJP8T1I
 B6UcsoSwfl1qG9l1L4GO3qKgl3.qy_jekpBRFK26.bR_eBt.XiugFuXai.jdXVa85U8g1pC5eFmA
 1EXeXSCdCEQbq8RrzJWKXboC7KB6HIBwI6Z82EMwAR2rCODGDZ1ys5zhHnhRRtOF80e7qbbgJkZZ
 lwyXtlFM7qL4q6ywclx1zqN1.FdD2p2JDEPRI86ddUHPAbY2DShtUScghZOhctI48eyLTFB6eYxZ
 I2NFtGNzbnmPZKpOv5iiDx3aac6e5kUvPRt4oC_8aQVvK3dsHTfjqk_yyQmRvogwornh8ZFRVc2F
 KXQQB4dKOhbZLgZV1HHwL7ENzGtvIbzDcsaFeiAc76rjCEfgj26dOSqHt.h9AbpwmvrCPZ2MbLLS
 I8g_LV8qcPFLJvOOeqRFw8vMogdd6c18TQIegxFNSm8JIa453UgDg1amK
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 03:11:27 +0000
Received: by hermes--production-ne1-74ddcb6b46-t2ktp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 851187d86f7ca13265d6addcc6ce3bee;
          Sat, 30 Jul 2022 03:11:25 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: 
Date: Fri, 29 Jul 2022 20:11:23 -0700
Cc: Warner Losh ,
 Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
 <20220729204943.GT30607@FreeBSD.org>
 
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LvqD11R2Nz3yYV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=mX928mMi;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.26 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_MEDIUM(-0.77)[-0.765];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-29, at 19:56, Mark Millard  wrote:

> On 2022-Jul-29, at 13:49, Glen Barber  wrote:
>=20
>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>>> Would it seem appropriate to use a week (this week?) to do all
>>> the snapshot builds with the builders all set to have
>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if anything?
>>> (Sort of a snapshot exp run.)
>>>=20
>>> More than just the SBC images might be involved for
>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>=20
>>=20
>> Hey, Mark.
>>=20
>> New snapshots for 13 and 14 are up now.  Is it possible for you to =
check
>> if the issues you had run into are indeed resolved, after setting
>> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>>=20
>=20
> Well, it is a mix, I think (unsure).
>=20
> I started with:
>=20
> # dd =
if=3DFreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img=
 of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress
>  5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s
> 5120+0 records in
> 5120+0 records out
> 5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec)
>=20
> I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted.
>=20
> . . .
> Starting file system checks:
> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 blocks, 0.1% =
fragmentation)
> Growing root partition to fill device
> random: randomdev_wait_until_seeded unblock wait
> random: randomdev_wait_until_seeded unblock wait
> random: unblocking device.
> GEOM_PART: ufs/rootfs was automatically resized.
>  Use `gpart commit ufs/rootfs` to save changes or `gpart undo =
ufs/rootfs` to revert them.
> da0s2 resized
> super-block backups (for fsck_ffs -b #) at:
> 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912,
> . . .
>=20
> But, after logging in:
>=20
> root@generic:~ # gpart show
> =3D>       63  468862065  da0  MBR  (224G)
>         63       1985       - free -  (993K)
>       2048     102400    1  fat32lba  [active]  (50M)
>     104448  468757680    2  freebsd  (224G)
>=20
> root@generic:~ # gpart show -p
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> So 1985 and 2048 are there, as intended.
>=20
> But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up
> in gpart show's output.
>=20
> I wonder if this is because of a lack of a distinct
> starting offset vs. the BSD. For example, the old 2016
> and 2079 alignment had showed:
>=20
> =3D>        0  468757737   da0s2  BSD  (224G)
>          0         57          - free -  (29K)
>         57  468757680  da0s2a  freebsd-ufs  (224G)
>=20
> where the 57 was, appearently, for alignment. May be now
> the distance from the da0s2 to da0s2a is zero and so
> BSD and its contained da0s2a is not now shown?
>=20
> I've yet to try the 14-CURRENT.
>=20

It did not survive a simple reboot test:

. . .
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x39b08000
   EFI version: 2.90
   EFI Firmware: Das U-Boot (rev 8226.1024)
   Console: efi (0x1000)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Setting currdev to disk1p1:
Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0)
Setting currdev to disk1p2:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


Type '?' for a list of commands, 'help' for more detailed help.
OK lsdev
disk devices:
    disk0:    60258304 X 512 blocks (removable)
    disk1:    468862128 X 512 blocks
      disk1s1: DOS/Windows
      disk1s2: FreeBSD
        disk1s2a: FreeBSD UFS
http: (unknown)
net devices:
    net0:
OK ls  =20
/
 d  EFI
 d  dtb
    README
    u-boot.bin
    armstub8.bin
    armstub8-gic.bin
    bootcode.bin
    fixup_cd.dat
    fixup_db.dat
    fixup_x.dat
    fixup.dat
    LICENCE.broadcom
    start_cd.elf
    start_db.elf
    start_x.elf
    start.elf
    fixup4.dat
    fixup4cd.dat
    fixup4db.dat
    fixup4x.dat
    start4.elf
    start4cd.elf
    start4db.elf
    start4x.elf
    bcm2710-rpi-2-b.dtb
    bcm2710-rpi-3-b.dtb
    bcm2710-rpi-3-b-plus.dtb
    bcm2711-rpi-4-b.dtb
    config.txt
 d  overlays
OK show
COLUMNS=3D200
LINES=3D60
autoboot_delay=3DNO
boot_serial=3DYES
console=3Defi
currdev=3Ddisk1s1:
efi-version=3D2.90
efi_com_port=3D0
efi_com_speed=3D9600
hint.smbios.0.mem=3D0x39c2e000
interpret=3DOK
loaddev=3Ddisk1s1:
prompt=3D${interpret}
script.lang=3Dlua
smbios.bios.reldate=3D04/01/2022
smbios.bios.vendor=3DU-Boot
smbios.bios.version=3D2022.04
smbios.chassis.maker=3DUnknown
smbios.chassis.type=3DDesktop
smbios.planar.maker=3DUnknown
smbios.planar.product=3DUnknown Product
smbios.socket.enabled=3D1
smbios.system.maker=3DUnknown
smbios.system.product=3DUnknown Product
smbios.system.serial=3D100000007151395e
smbios.system.uuid=3D30303031-3030-3030-3731-353133393565
smbios.version=3D3.0
twiddle_divisor=3D16

So definitely not working for a 2nd boot.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 30 03:42:44 2022
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 4LvqwK6rZjz4X1V1
	for ; Sat, 30 Jul 2022 03:42:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4LvqwJ5kdMz41w6
	for ; Sat, 30 Jul 2022 03:42:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659152574; bh=pn2+NuIluOXck3UaUnvHyEIm2teRlVU1aw4jYW0Wot4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CtAz+0c/W1S/cCfVZm3b3mtF8d55uuxHi0Dc3QLqlN76z+tkxi1RdzmEN25iuyPSxCOgyqNoVQK6I2jI7JyCJvHvgamjBBdX8WVCgepAh7F+7yMe8pGTOVK4Ovw2EgSiFeBE8DKBw+xe46/L9/WNMFE/iTBXYta+J6FYIkYee4NhJqDZ/zucvXbHLT5Ig9SZJNjS2+yhNUQf+6XW0PzBkS8VacaPh0DHdCU/oHGcOm/SEHOWE4vAQ1Z6gonPy2bYhUTTWSPljZSNFCM3LsRvkAun+wZNx5wZvQAg7sGpK0j75jORLHrHs8v/05HNKp3kccTrKksmG3ox53ZjcRwYzg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659152574; bh=mASN6zA6BcPKDrKlH+pcFl2JZwuJuEHvz6T6NbDQJMx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M0c6lPF7Yx/KVKccKBmjmgPMdfwAEcho1BDdcSCaYuxgjJKmLoj3X2ZqTvgT7odNtYUUnXJg24dGSYIsFPfUNp+cFGehjErDIU+cwp1FD1ZM8vZiDnI2vKS6HW0COuzMaWQWbqoM26s65THO+ZUoOBLCsQF2DrfbmK/XoRoMlZO4InjYMOIbTJnr2LRAuXPWYn2o9JvqciFB/tpYOP5fYLfK+Jor2+gAI6f6OvBsJ4b3d4JV7sNuvHMN4ddOxAt0Ncd53AjkSYIGN1ALN9+JzXafxdWhaNhZgu3pjBzmEIlNzagOjcj+KwDnlyydTzL6UWSJsM+psrWTNzuCJs65aQ==
X-YMail-OSG: Qi0Dci8VM1k7swTxCBX_DEbTGs5VpTvzhtBVOrDlQczDH.JmnWPuXLpB3cOfDrT
 A0wveSbA_7b4TvkNmEg31CtYKPcODwdwnomdiE7uiuMXEV3RLa4W2wcGm9OIbxcLLZXhzYFKO2fy
 WLrFXHcxZhqER9LMJSum0c9rXh3X8azSzyN41jRz6Qmsa1f0P_P063y5CSSuo.bp6qhV.es2ULSl
 WzARbe5DoHNo064KXlnN8OABxBhHyGHVCAyIH_qDpt3qWCkMwWlO0NPeV86rin_s9p4JBopSVH7o
 L6G_ojawogWxtxv9O8sFVrxk7y44NnQrHTvINRW8F1uiPN876x4HINDxIOObcg4TDgHKkkKk2bIf
 Im00cJ8xd5cJv9oMS.l4JpqZEjqS7qtUn6IhZ4zxNkjL0SlR1ZZjKyp7M2JhIXJDJ0c7X_vwsgvS
 M67HIR9Xk9zdo9T8WxenjHY3XaT3SYNWyf9CHAYoQXwA.kUi7fa7WCi4fldfX8gXzQte_YDas2f5
 1rYjMxTrIT.Q5pfjqKTzU7y0NwpexzFkzCvAuSXdC9Fa_GTC68ymE.GXdUTnYTHVbyNNOw5BM30Q
 l1Gs4ULdGXhvooJG8BTOqYmSWRTOPXelvKaAEdP0CRhCCM6VZjrjDL9i6m0fN7oWd2KuQbUfIZYY
 7QEgVLQIu9GKfQk09us.2dp1GQZxgvt0s5bEMJuQvSioDsU_Jqoo35gaSLeCquG5h1dqV311X3GG
 7p00Lbmu9hzRlzm0IlFNyUkOfM_FZusi8vDe7sXLdcY6Sr8A2XWp5POgY7sFu1X4_PCatZA6Wzo7
 j_bC1FZpkhqjFwk6dE8XUP2zbIhbXPWR2MzrEw9mNUPlygBg8aV.1HDS5rWE_RGaSkpJysJqhhBE
 .qshHt5poJbFpV7tf4UkIVRNHqe421otS63aStUdvE7JDzhgkR5dDxw0QHAuPTpCqgbZFGofWS5c
 FZ1zwxTCFBmS69VEYa8MmSwwly_m1PuWPb9oejwko4y13x85O8W15CiZSOEzWrra8zT6zS9Yqy61
 _x34RHbd5iGSAUGm.y2rpzPw0hiHq8NkowGxtQwOwXgb654.PR..vpick5qT6UFMD89S74zjy.rs
 wKBPYjOhZ_yTMNvWvNKjLFjZkTPGZORsO0iEwkz5D9CoRI.rIINtBqn9Tpmkraml3PgRvl1bIUuo
 31_4f_yvD_fuiQKzApeaCfflSMsqm2GAWB1wEaI6ilQ03JCp1tMryjDq0_z2C9H12tkSoQnxJy.x
 xrqyCIz8IVArNjGClC2TLg9Ws2rZmuAQYN6KJrzOhtAtB1pJt7GGtdEyiDBME_sKIGaPP_XYntUV
 fHqNFAMvJQvS1xutEUn444OaEpeVnvWoROaEWaphO8qmzProeI_7Sf97_LdrpD6xvsCVcadmWUap
 KLCjjMLg8ZLmTDVa_z6kOQC_taSIRp9zXw2ByeZmEnXy8HPsYp68kAFeYGdwrP7l_wgBb1C7qnmo
 Jedxcr9g4hS.hVgK.8AuBSI8HzS9mlojv7VtXAuN5aCdsuHtiIfY26nY6iDDlWvdIf0HseuYEwwi
 EPZOvUbY5u8ogAf7WGosj7YFIl1aGbdqNaYXs0f1vLbj7e7XcTsUYEPeQCMz9UUC5n9uXcIOYbhN
 PYcaTMmWgy0A7Io0cjadCzSrARCoIFFfU1YLn7QIeUxqZFhGbIz8GkBOShDRBl_eYnWVRB1Z5Yxv
 ZaSldtgri5nr3QzaQVDZmW.s3opH2mmSgv2YJ_LfZ0sezFsZ4xq6uy8wCkR3oWtfBFsh2yHyPhT4
 FiIeItzq2BMyaWOn5vLlUPqqvw3ywNS222AuDSeOYmiN3jj667TuKXgHki1wi9xrSASIh6kBoRwv
 A7aSCudeXx0Ge2mrEvBMyFNH2nniGErjPU8fSZrOwneuWOp5J4d6D0SQH1NcyIXeRV6bEF2XiNE_
 moGkD33xDwsd2Nzi7w1g2bOLO6_gbI64hLYIDmujONuyfC2T.F51.oT5j9oRUucKyXWGCDXDDt3d
 _8xFWvg885OgXSWtJ4AlTrgUfM_lE0i1T7xa9zwFACuH_oaAYDsLkTPj9q.qwu9c.7C14G6dHMSN
 xuasEFuU_HEJJfYkHeIVZaHtiLJ.dhu8Jb7S3RDV7iiTJmHxYo_CGWtPJqA.cfX0z6lfavp3m8ZJ
 ICHd7xQ67VZeclvB.TAY5nPXiwwBUzGSu90a6eAyH7w0s1uiyvPYwLzOCEpohaO_TksgqucPUe.G
 enxovi4g1V5KsfY6UL6kOCg9uWURf5CvWZIDALHg2EymS0XLJN_2173U5_P4EHrepOfWmu7_tzen
 BQtXMb.WrsCPmL6cNffwv8CDkqYp_23xD
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 03:42:54 +0000
Received: by hermes--production-bf1-99ddd9c9c-vpswh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c8a0e52e3bde3a5ed38abe4ae1bb1b61;
          Sat, 30 Jul 2022 03:42:48 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com>
Date: Fri, 29 Jul 2022 20:42:44 -0700
Cc: Warner Losh ,
 Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
 <20220729204943.GT30607@FreeBSD.org>
 
 <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com>
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LvqwJ5kdMz41w6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="CtAz+0c/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.38 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	NEURAL_HAM_MEDIUM(-0.89)[-0.893];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-29, at 20:11, Mark Millard  wrote:

> On 2022-Jul-29, at 19:56, Mark Millard  wrote:
>=20
>> On 2022-Jul-29, at 13:49, Glen Barber  wrote:
>>=20
>>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>>>> Would it seem appropriate to use a week (this week?) to do all
>>>> the snapshot builds with the builders all set to have
>>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if =
anything?
>>>> (Sort of a snapshot exp run.)
>>>>=20
>>>> More than just the SBC images might be involved for
>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>>=20
>>>=20
>>> Hey, Mark.
>>>=20
>>> New snapshots for 13 and 14 are up now.  Is it possible for you to =
check
>>> if the issues you had run into are indeed resolved, after setting
>>> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>>>=20
>>=20
>> Well, it is a mix, I think (unsure).
>>=20
>> I started with:
>>=20
>> # dd =
if=3DFreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220729-db2eff1cff8-251976.img=
 of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress
>> 5222957056 bytes (5223 MB, 4981 MiB) transferred 21.027s, 248 MB/s
>> 5120+0 records in
>> 5120+0 records out
>> 5368709120 bytes transferred in 21.816899 secs (246080301 bytes/sec)
>>=20
>> I plugged the USB3 SSD into an old 8 GiByte RPi4B and it booted.
>>=20
>> . . .
>> Starting file system checks:
>> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
>> /dev/ufs/rootfs: clean, 499417 free (1153 frags, 62283 blocks, 0.1% =
fragmentation)
>> Growing root partition to fill device
>> random: randomdev_wait_until_seeded unblock wait
>> random: randomdev_wait_until_seeded unblock wait
>> random: unblocking device.
>> GEOM_PART: ufs/rootfs was automatically resized.
>> Use `gpart commit ufs/rootfs` to save changes or `gpart undo =
ufs/rootfs` to revert them.
>> da0s2 resized
>> super-block backups (for fsck_ffs -b #) at:
>> 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912,
>> . . .
>>=20
>> But, after logging in:
>>=20
>> root@generic:~ # gpart show
>> =3D>       63  468862065  da0  MBR  (224G)
>>        63       1985       - free -  (993K)
>>      2048     102400    1  fat32lba  [active]  (50M)
>>    104448  468757680    2  freebsd  (224G)
>>=20
>> root@generic:~ # gpart show -p
>> =3D>       63  468862065    da0  MBR  (224G)
>>        63       1985         - free -  (993K)
>>      2048     102400  da0s1  fat32lba  [active]  (50M)
>>    104448  468757680  da0s2  freebsd  (224G)
>>=20
>> So 1985 and 2048 are there, as intended.
>>=20
>> But no explicit da0s2 BSD or da0s2a freebsd-ufs shows up
>> in gpart show's output.
>>=20
>> I wonder if this is because of a lack of a distinct
>> starting offset vs. the BSD. For example, the old 2016
>> and 2079 alignment had showed:
>>=20
>> =3D>        0  468757737   da0s2  BSD  (224G)
>>         0         57          - free -  (29K)
>>        57  468757680  da0s2a  freebsd-ufs  (224G)
>>=20
>> where the 57 was, appearently, for alignment. May be now
>> the distance from the da0s2 to da0s2a is zero and so
>> BSD and its contained da0s2a is not now shown?
>>=20
>> I've yet to try the 14-CURRENT.
>>=20
>=20
> It did not survive a simple reboot test:
>=20
> . . .
> FreeBSD/arm64 EFI loader, Revision 1.1
>=20
>   Command line arguments: loader.efi
>   Image base: 0x39b08000
>   EFI version: 2.90
>   EFI Firmware: Das U-Boot (rev 8226.1024)
>   Console: efi (0x1000)
>   Load Path: /efi\boot\bootaa64.efi
>   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
> Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
> Setting currdev to disk1p1:
> Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0)
> Setting currdev to disk1p2:
> ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
>=20
>=20
> Type '?' for a list of commands, 'help' for more detailed help.
> OK lsdev
> disk devices:
>    disk0:    60258304 X 512 blocks (removable)
>    disk1:    468862128 X 512 blocks
>      disk1s1: DOS/Windows
>      disk1s2: FreeBSD
>        disk1s2a: FreeBSD UFS
> http: (unknown)
> net devices:
>    net0:
> OK ls  =20
> /
> d  EFI
> d  dtb
>    README
>    u-boot.bin
>    armstub8.bin
>    armstub8-gic.bin
>    bootcode.bin
>    fixup_cd.dat
>    fixup_db.dat
>    fixup_x.dat
>    fixup.dat
>    LICENCE.broadcom
>    start_cd.elf
>    start_db.elf
>    start_x.elf
>    start.elf
>    fixup4.dat
>    fixup4cd.dat
>    fixup4db.dat
>    fixup4x.dat
>    start4.elf
>    start4cd.elf
>    start4db.elf
>    start4x.elf
>    bcm2710-rpi-2-b.dtb
>    bcm2710-rpi-3-b.dtb
>    bcm2710-rpi-3-b-plus.dtb
>    bcm2711-rpi-4-b.dtb
>    config.txt
> d  overlays
> OK show
> COLUMNS=3D200
> LINES=3D60
> autoboot_delay=3DNO
> boot_serial=3DYES
> console=3Defi
> currdev=3Ddisk1s1:
> efi-version=3D2.90
> efi_com_port=3D0
> efi_com_speed=3D9600
> hint.smbios.0.mem=3D0x39c2e000
> interpret=3DOK
> loaddev=3Ddisk1s1:
> prompt=3D${interpret}
> script.lang=3Dlua
> smbios.bios.reldate=3D04/01/2022
> smbios.bios.vendor=3DU-Boot
> smbios.bios.version=3D2022.04
> smbios.chassis.maker=3DUnknown
> smbios.chassis.type=3DDesktop
> smbios.planar.maker=3DUnknown
> smbios.planar.product=3DUnknown Product
> smbios.socket.enabled=3D1
> smbios.system.maker=3DUnknown
> smbios.system.product=3DUnknown Product
> smbios.system.serial=3D100000007151395e
> smbios.system.uuid=3D30303031-3030-3030-3731-353133393565
> smbios.version=3D3.0
> twiddle_divisor=3D16
>=20
> So definitely not working for a 2nd boot.
>=20

14-CURRENT got a different result: a pair of . . .
"/dev/ufs/rootfs: Operation not permitted"

Setting hostuuid: 30303031-3030-3030-3731-353133393565.
Setting hostid: 0xd2468d7e.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 601308 free (436 frags, 75109 blocks, 0.0% =
fragmentation)
Growing root partition to fill device
random: randomdev_wait_until_seeded unblock wait
random: randomdev_wait_until_seeded unblock wait
random: unblocking device.
GEOM_PART: ufs/rootfs was automatically resized.
  Use `gpart commit ufs/rootfs` to save changes or `gpart undo =
ufs/rootfs` to revert them.
da0s2 resized
growfs: /dev/ufs/rootfs: Operation not permitted
mount: /dev/ufs/rootfs: Operation not permitted
Mounting root filesystem rw failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
2022-07-29T11:17:56.567464+00:00 - init 1 - - /bin/sh on /etc/rc =
terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:=20


The boot media was set up via:

# dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220729-467d3e2e8aa-257025.im=
g of=3D/dev/da0 conv=3Dsync,fsync bs=3D1m status=3Dprogress
  5187305472 bytes (5187 MB, 4947 MiB) transferred 21.025s, 247 MB/s
5120+0 records in
5120+0 records out
5368709120 bytes transferred in 21.884283 secs (245322600 bytes/sec)

The same 8 GiByte RPI4B was used.

root@:/ # gpart show
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  ufs/rootfs  BSD  (224G)
          0   10381312           1  freebsd-ufs  (5.0G)
   10381312  458376368              - free -  (219G)

root@:/ # gpart show -p
=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   ufs/rootfs  BSD  (224G)
          0   10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
   10381312  458376368               - free -  (219G)


However, in this context:

root@:/ # gpart commit ufs/rootfs
root@:/ # gpart show
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  ufs/rootfs  BSD  (224G)
          0   10381312           1  freebsd-ufs  (5.0G)
   10381312  458376368              - free -  (219G)

=3D>        0  468757680  da0s2  BSD  (224G)
          0   10381312      1  freebsd-ufs  (5.0G)
   10381312  458376368         - free -  (219G)

=3D>       63  468862065  diskid/DISK-00000000000A  MBR  (224G)
         63       1985                            - free -  (993K)
       2048     102400                         1  fat32lba  [active]  =
(50M)
     104448  468757680                         2  freebsd  (224G)

=3D>        0  468757680  diskid/DISK-00000000000As2  BSD  (224G)
          0   10381312                           1  freebsd-ufs  (5.0G)
   10381312  458376368                              - free -  (219G)

root@:/ # gpart show -p
=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   ufs/rootfs  BSD  (224G)
          0   10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
   10381312  458376368               - free -  (219G)

=3D>        0  468757680   da0s2  BSD  (224G)
          0   10381312  da0s2a  freebsd-ufs  (5.0G)
   10381312  458376368          - free -  (219G)

=3D>       63  468862065    diskid/DISK-00000000000A  MBR  (224G)
         63       1985                              - free -  (993K)
       2048     102400  diskid/DISK-00000000000As1  fat32lba  [active]  =
(50M)
     104448  468757680  diskid/DISK-00000000000As2  freebsd  (224G)

=3D>        0  468757680   diskid/DISK-00000000000As2  BSD  (224G)
          0   10381312  diskid/DISK-00000000000As2a  freebsd-ufs  (5.0G)
   10381312  458376368                               - free -  (219G)

So it looks like the growfs did not actually happen.

The following seems to have gotten me to about the
same type of context I got to for 13-STABLE:

root@:/ # mount -u /
root@:/ # gpart show=20
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)
root@:/ # exit
No suitable dump device was found.
Setting hostuuid: 30303031-3030-3030-3731-353133393565.
Setting hostid: 0xd2468d7e.
Fast boot: skipping disk checks.
Growing root partition to fill device
da0s2 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,
. . .

Do a shutdown -r now form of reboot from this context also got:

. . .
FreeBSD/arm64 EFI loader, Revision 1.1
(Fri Jul 29 09:39:44 UTC 2022 root@releng1.nyi.freebsd.org)

   Command line arguments: loader.efi
   Image base: 0x39b02000
   EFI version: 2.90
   EFI Firmware: Das U-Boot (rev 8226.1024)
   Console: efi (0x1000)
   Load Path: /efi\boot\bootaa64.efi
   Load Device: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Trying ESP: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(1,0x01,0,0x800,0x19000)
Setting currdev to disk1p1:
Trying: =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x1e91,0xa2a5,0x0,0x0,0x0)/HD(2,0x01,0,0x19800,0x1bf0acb0)
Setting currdev to disk1p2:
ERROR: cannot open /boot/lua/loader.lua: no such file or directory.


Type '?' for a list of commands, 'help' for more detailed help.
OK lsdev
disk devices:
    disk0:    60258304 X 512 blocks (removable)
    disk1:    468862128 X 512 blocks
      disk1s1: DOS/Windows
      disk1s2: FreeBSD
        disk1s2a: FreeBSD UFS
http: (unknown)
net devices:
    net0:
OK ls
/
 d  EFI
 d  dtb
    README
    u-boot.bin
    armstub8.bin
    armstub8-gic.bin
    bootcode.bin
    fixup_cd.dat
    fixup_db.dat
    fixup_x.dat
    fixup.dat
    LICENCE.broadcom
    start_cd.elf
    start_db.elf
    start_x.elf
    start.elf
    fixup4.dat
    fixup4cd.dat
    fixup4db.dat
    fixup4x.dat
    start4.elf
    start4cd.elf
    start4db.elf
    start4x.elf
    bcm2710-rpi-2-b.dtb
    bcm2710-rpi-3-b.dtb
    bcm2710-rpi-3-b-plus.dtb
    bcm2710-rpi-cm3.dtb
    bcm2711-rpi-4-b.dtb
    config.txt
 d  overlays
OK show
COLUMNS=3D200
LINES=3D60
autoboot_delay=3DNO
boot_serial=3DYES
console=3Defi
currdev=3Ddisk1s1:
efi-version=3D2.90
efi_com_port=3D0
efi_com_speed=3D9600
hint.smbios.0.mem=3D0x39c2e000
interpret=3DOK
loaddev=3Ddisk1s1:
module_verbose=3D2
prompt=3D${interpret}
script.lang=3Dlua
smbios.bios.reldate=3D04/01/2022
smbios.bios.vendor=3DU-Boot
smbios.bios.version=3D2022.04
smbios.chassis.maker=3DUnknown
smbios.chassis.type=3DDesktop
smbios.planar.maker=3DUnknown
smbios.planar.product=3DUnknown Product
smbios.socket.enabled=3D1
smbios.system.maker=3DUnknown
smbios.system.product=3DUnknown Product
smbios.system.serial=3D100000007151395e
smbios.system.uuid=3D30303031-3030-3030-3731-353133393565
smbios.version=3D3.0
twiddle_divisor=3D16

So the primary difference seems to be getting the 2
"/dev/ufs/rootfs: Operation not permitted" notices
and so getting the:

Mounting root filesystem rw failed, startup aborted

and such. After the "mount -u /" and exit, things
seem similar again.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 30 05:09:43 2022
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 4Lvsrb3KHDz4XGX9
	for ; Sat, 30 Jul 2022 05:09:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4LvsrZ2vKzz3C9C
	for ; Sat, 30 Jul 2022 05:09:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659157788; bh=xjWXWNYN2XlzJ985i3jyx9H1feRQx6nmOwO8grqf3Zo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GmmuFGoJEFEoZCYN3XUi0NasM6Ug67yogZBZLT/APpQd1Iq8cJjERRlxxXDhYn2zg73VtF6WwT7PfW97nFYXPtz0juXtXRceEgDbv7MVvgyos4yZk9+2OUXvlLcq+XbLesnLzL3T93bTg6we4Zr2kT8X0BHQduo6hNzjrBHj+xUYA74WjRtMyQVC37763gUBqJJw6BxRBXrgiAdnliGwKMVYgE2DEObaDAnGvl86MvYB/TzbGzz9a1IeULbspcDRrqAOS/3IgU4Yz7YUd7fr9pKp5b70BAvy4rVOzXANgNi+dxVq8iRPvJuXeYb42uHRzF7lMun004bQ7xoD4ZuHPQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659157788; bh=ilB/LJ4tksUD7zUaVDj1+z9qezNqDi3QLSIVQvzq/fA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=COOW9EzWMeA9Ty+b2Ea/K9jB8Hm5X/79FsWXJHTLkcBMcURBVbosKbokUZU7eAYfx3GffzohsTpUM/ZGVBB4yyFmJ7Ce9GAGjywq3pXIKCEm8Y8/LOWMYZionrf0OZ2LT/VwzGYEnwFd5PQpGEVv0SvG9arblTzS8JLL/PDrsVwDIqeHgHJzHiMLbKTpKQbNPn80Z2lwjD1BPnVGQkbhcRMaX5gO/dp9k5oMibmpEOL2YRye26mkEURU/Fpne9sDN+rMhkKJMK2QCi0s45J78syMSLjQEd/8XhrYIbzsLe1dSZuFv0AkKtmEWjECxvMcJxe+dcGWMW08Hncy0CMd5g==
X-YMail-OSG: wd_KdvgVM1nOKawRDLNg1l5Q4qTMZSSH_jVN3vDYt22L.ulzN1f9XvIHhlyQ5ac
 OambhCIFLMWc2Lne8cnSgSCOi0MQk1FMdjjjWy104v77Za7kg8GIpC4gu45GjK7hrK_a_rp0EvO7
 u6oghn67XPx0SYVI9gphB8AGYvdfJ7cM1DDZVsDaQk9EfqLmJ1UNPIbPk_Qf.OZJQlSr2x1V7NC9
 UQ9zFpq_8cXzb.UlZxH.EQ0Sb3Q9oLotK3tZIC4Hjst.HfuXYly8_4XMxS8sFpbSUBmwzrjjLKsm
 TjIHywX8yXPSgX45LuWKBNKOHxeGg5p3_dFh8N.QiepLzx4DPXbbPUBn8PMqu827bU78iqYHMDgc
 ZueOaQPP8XxvDR.n6mbXFcPLi28lPKuK8XxGsNybQHrloTuzde5hcmHb2gMaCnn4h1nq2zAtwesy
 mdilEVa5N8dcUxfNGqc9ffbdkcrIdwR6_JI4ZcJO3GqD03hKqBBINI.8VaZycir1bbQzsPeAtIlb
 RfXjtIrM3vGZGyb9vuRscgUqdz9xopxrshSLn5sHMGwOBPAIEbhvOp0AXz2ksTZciUc9FpLaQKDq
 BOR9Nh7sVru_r.DJsjbL6DJeisyLmnTiTVYvR_O_WhifNLshUs8KQokiGIS0DUzNGtEKSpMFTDVK
 xF3n_XB9m4_G.JK_VVnsjzlu18hBaxe6NS1A6QKPgQzxRPHDi02sEjSFYnmWqBUbYSdMwP_ZwAc.
 aaSE49m8mrmpZpJU7Bzu8mTRvQFuOoxOyJVaCBahf0XVevJuMfrF0eBo.Y966iWiBduUjCl4Zm6_
 1nDKOfGKgHmyza1aPYCiVLPLY94FwSliE2M55dVtqBy63SJgXXgfg_LWmS_N45MQqVC_ODfGPghW
 SVYwiqnIg2qWJKTr_lPzdSML4l0s1PaivNhLuLGyJQC4xqQwQs12FZKH5lG_RcWJxtyD837vgxAL
 rjwR8UhA.mGb8364LfQ2OMJhFFcBjxKrcyaefVIkxy8Up9DG7eTr6fwO6Y.qd1tB7csP2iJZAah_
 laPNYuBZXolUY7c3OGzgU.sLdG3ydRY.58CDU.H2fZSH0ZpTiLc.6fHRGxupUcwRl2fQj4_7gqSx
 MnqOt.0lifhFJu41KPmYYO89Gchwgzs43BC.JnXZJX5_tZbA2hvoZTBX8yt_fjbFQjUxzLVoLmLd
 0c1QIUyvsnnbNNx9N7lO3PXhYBfhkqJCALGbPKtW9PAEVtBNJCCZmnmSY7ruVtE9Z8rwR0y1su6_
 6ZLyP_dw0LDX2pke6V5_ErJq4zGc642iGiohGAEgqerJWzILestURz5k.1_qU1FO_StW7wMhyQL2
 UBFvC1Hx49ceS3ZYmAe_T06QvVUOnLitPs.Y22wAgupD4BsoEatjuyJ1ggT4v2nzXZTGhgy6MBLv
 pw8HxCa.U2o6pczVb6VWabziCHfL0RWFSRhyxZ3LwIT2e79JJpDfzbvullCqZxQog.76TEirpQRg
 OhMwdTR5aic95.mC_NVT.B69vqm2tWGy9TzD5JmpHdVyvHH_tmtlB4.qpRZ30dx5OcDDsyMURnnn
 8CPGFXpP3wk4amDlq0Xwo23i2HDUNFlapIz_oSPJPpJtgqL7c9YCRFr9gWP5uSIm9yqgpBs.2OZz
 B7oXO_SQl3SCzKs2PT2aQa1vjSiGJfpxWN42bdK4w.YZhajoPfkiadrRLKfmrTnPidzBA2bcqp9t
 p9PfRIfIwITK2eedwdAGF3MBrTadvAUPeXjiOfGwAKBK4T6rrHgkWA26deZgFRiQ4_pP10SCI_q_
 Y76HO15EQmt4Ny8nKxAjmH8XD5.Ir9rl3c4vNOWyabw3.BPlmsJiGUSiDD0Pvs0vvDRONEBagWYi
 2ORlPw7ElcxDfs7L_Ml5X2pgSkgp1asSTyjM2M.vjPUuGnu717JOxoxJM4o6IC_eOYiyFIkjiTSk
 5G7JKBTG0DUwbWwZOdVmCsqm65ReDZeAgVXOypNh0jPRrEAirtsXLphuz3pNrwABcHM3EoI9vGRD
 n79ybvQkvTV2kUjiBUwzyDXESMmdSk_hE44Ht1eL0gyi6W0oXJQT9DFJyTUgychaxeMvG2NO84cy
 rjwI.hYb23H4zjKLtUfIUDzLONebsIRE2rk3_oZztf0eHoE5i1gAL9Nt..VZ9.y245.5rO83dZCe
 8j7VkJm4qLl9qAt5avmWNHSEupY5U1h0_YcAoXaAgsF0rvdp5PWtLaQyWwW_9kaoMO2iJyE4xXRY
 88LYamZF4LdDI8i13SkDGxx0zz4mcrgFbkNh1qz58lQ8LnJ0gIFXq25US_sooZOum_.rWkCnFJAh
 sRPlv3tQdJg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 05:09:48 +0000
Received: by hermes--production-bf1-99ddd9c9c-lzhlr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 050e04ba26f32070bbf455fc45a051db;
          Sat, 30 Jul 2022 05:09:46 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com>
Date: Fri, 29 Jul 2022 22:09:43 -0700
Cc: Warner Losh ,
 Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
 <20220729204943.GT30607@FreeBSD.org>
 
 <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com>
 <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com>
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LvsrZ2vKzz3C9C
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=GmmuFGoJ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.27 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_MEDIUM(-0.78)[-0.782];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Jul-29, at 20:42, Mark Millard  wrote:

> On 2022-Jul-29, at 20:11, Mark Millard  wrote:
>=20
>> On 2022-Jul-29, at 19:56, Mark Millard  wrote:
>>=20
>>> On 2022-Jul-29, at 13:49, Glen Barber  wrote:
>>>=20
>>>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>>>>> Would it seem appropriate to use a week (this week?) to do all
>>>>> the snapshot builds with the builders all set to have
>>>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if =
anything?
>>>>> (Sort of a snapshot exp run.)
>>>>>=20
>>>>> More than just the SBC images might be involved for
>>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>>>=20
>>>>=20
>>>> Hey, Mark.
>>>>=20
>>>> New snapshots for 13 and 14 are up now.  Is it possible for you to =
check
>>>> if the issues you had run into are indeed resolved, after setting
>>>> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>>>>=20
>>>=20
>>> Well, it is a mix, I think (unsure).
>>> . . .

I got a little more evidence about the type of problem,
I think. (Not that I know the interpretation to give
the evidence.)

Instead of booting the 13-STABLE media I put it into a
booted system to look at it:

=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   da0s2  BSD  (224G)
          0   10381312  da0s2a  freebsd-ufs  (5.0G)
   10381312  458376368          - free -  (219G)

(I've ignored ufs/rootfs ufs/rootfsa, ufsid/*  above.)

Compare/contrast:

# growfs /dev/da0s2a
growfs: unable to read superblock: Input/output error

# growfs /dev/ufs/rootfs
growfs: requested size 224GB is equal to the current filesystem size =
224GB

# mount -noatime /dev/da0s2 /mnt
# umount /mnt
# mount -noatime /dev/da0s2a /mnt
g_vfs_done():da0s2a[READ(offset=3D5920980992, length=3D8192)]error =3D 5
mount: /dev/da0s2a: Input/output error

# gpart resize -i 1 /dev/da0s2

# gpart show
. . .
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  da0s2  BSD  (224G)
          0  468757680      1  freebsd-ufs  (224G)

# gpart show -p
. . .
=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   da0s2  BSD  (224G)
          0  468757680  da0s2a  freebsd-ufs  (224G)

# mount -noatime /dev/da0s2a /mnt
# umount /mnt

After that I can again use it to boot the 8GiByte RPi4B.

But, having booted itself, it shows . . .

root@generic:~ # gpart show
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

root@generic:~ # gpart show -p
=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

So, again, no da0s2 BSD or da0s2a freebsd-ufs .
(Unlike gpart show on the normal-boot main [so: 14]
system.)

After shutting down and plugging into the normal-boot
system . . .

glabel list on the normal-boot system with the USB3
SSD plugged in shows:

Geom name: da0s1
Providers:
1. Name: msdosfs/MSDOSBOOT
   Mediasize: 52428800 (50M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 102400
   length: 52428800
   index: 0
Consumers:
1. Name: da0s1
   Mediasize: 52428800 (50M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1048576
   Mode: r0w0e0

Geom name: da0s2
Providers:
1. Name: ufsid/62e358b6cff37c76
   Mediasize: 240003932160 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53477376
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 468757680
   length: 240003932160
   index: 0
Consumers:
1. Name: da0s2
   Mediasize: 240003932160 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53477376
   Mode: r0w0e0

Geom name: da0s2
Providers:
1. Name: ufs/rootfs
   Mediasize: 240003932160 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53477376
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 468757680
   length: 240003932160
   index: 0
Consumers:
1. Name: da0s2
   Mediasize: 240003932160 (224G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 53477376
   Mode: r0w0e0

while the gpart show -p on that system lists:

=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   da0s2  BSD  (224G)
          0  468757680  da0s2a  freebsd-ufs  (224G)

=3D>        0  468757680   ufsid/62e358b6cff37c76  BSD  (224G)
          0  468757680  ufsid/62e358b6cff37c76a  freebsd-ufs  (224G)

=3D>        0  468757680   ufs/rootfs  BSD  (224G)
          0  468757680  ufs/rootfsa  freebsd-ufs  (224G)

Having managed to expand da0s2a seems better, but
it is still odd, including the mismatch in what
the self-booting 13-STABLE shows via gpart show
vs. what the normal-boot shows. The normal-boot
is of (line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #59
main-n256584-5bc926af9fd1-dirty: Wed Jul  6 18:10:52 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400063 1400063.



FYI: for 8 GiBye RPi4B's I add at the end of the config.txt :

#
# Local addition that avoids USB3 SSD boot failures that look like:=20
#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
?=20
initial_turbo=3D60=20

I also comment out the hdmi_safe=3D1 line. (Assigning 0 instead
also works.) But it is rare that I have video plugged in so
I'd not normally notice the problems that hdmi_safe=3D1 can lead
to.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jul 30 06:03:31 2022
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 4Lvv2g4PYKz4XQbP
	for ; Sat, 30 Jul 2022 06:03:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.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 4Lvv2f0Bh2z3Rrr
	for ; Sat, 30 Jul 2022 06:03:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659161015; bh=Ppw+3e6xglEmvzEokwq2tbg/nL+xLvhLKDH/PEevUdk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G0vfxJnMuDx9wq+p8AoBW9aC67q2jMflHW8smJVYGRBOXr+yLT2C2VlOZiKYdVET/3ULsxBKgsjxNFv2jnhYdUq30BlYfGpWNr+WBKmsdcOdjUuEAhKZYNxYw27kxYKOCJlIs2QMCHzfFu3K808szuZioJqo7um+ip3A5hbPI3fRSiMRSZYcptXgWWPW7jNgo4JY162UElsLeAGrnRjF2fCcvNq/ItBk+tiRgIkWdhTs+7Yfo26G4P9esa2mJDgKm8eL+QMVRf902m5kG0DdgQKs8ZSqmb2iBVl0BvzSWF9j3ECdgE2bgLMM/RX84VusAjJybSvBrA8RT5oM2HMs+w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659161015; bh=jVtjGz8pkn3O/RRCFEy47EWA5qrAqCdjpHCVPYbVWge=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=txjxUc0iMQvP3yUhPem5XZuTXqaox0Oi8sNsVSFJ2mghTH6+faO2joui+q09r7obWEnspH8BgsnzErfrl8MHNRh1fU0ZJZq/nF83Qe+ibygQRPCcBb20hQROETWSsSQXOoykrOdve0cbY71QRggt5LED0u347oK2eif0prTG5m4JuwqRgIH7kh4MGGcm6wIbaMAaQFPr8VVpQhAC1Io0QY6UahMa8wdJ3Bcx/hSQYax0IA0WksTgqA2ls5qJvT1lyjKxV4cwLEua9ydTWSSc+nPXb3Ba8J6l6+TfcnJCOlI19hSFr4/Lr0osLR70/rhD4Skm37WvvfWzmRyOW1AcxQ==
X-YMail-OSG: nF.JTmQVM1lhOtAjNzUORUpDsi4Z7qQwjXvdK7PTK75oV3aSw3JI9v3bmo_Npxm
 VfbuVs6M73DMtfxPPwz41i6OBP_7gkVPQ_nDJe2KYGF7dwaVTF9IOdegzd7Hrnl4Ef10xS8gRti6
 ULQ1TVgdBf.fDoSA9gybhq2GB_p2eZ5XLm0jgIxP3DnCY98CZGJe5kGFOFlWQ43E1qGb0mSwRzyX
 YC6CVMD3KmMDbfj0AoWvF6_lg1t8zkbmcfxaWS03Ow5Kd2fmdcNYo4skMSZhtzx0tOK_nJDKUOLn
 cCqS6o3T4iA744tDozWriyhgRm4kL4w2.IHRpYjby9l5hVYEGlsiZotgVTHTo1xCgvcB06.7vT0G
 9ywpEfQ0N8nb9TIj94D2kekmorOmkw9q4t8IiZgUfRUkMVI1DhYkJLTxaSoGDbik7VA.Ql.2ZMZv
 6rXT3i7PH1Y.m2BMvTiK_swGNPE7Szo7VT5WY5jVP8_FlGAPHiO3yJX2DmLaVhQYmMMXxod55.Vr
 MaxccbA4FJympQWHoo6UE8KIspUKaurwzEleo73rfvgbnk_ubqGm5.i0hI4jXNtsL7gCcUrzOJSZ
 FOr4Y8095rR01at5d5FGu0a.p9VLIB6Gi6hGrs094ImDZH7gHd0ltVCODWz8xrbqfom7CbbouupL
 Fg2w1zaCh8Q15UaR1HRjU.NsVWUGQq8yNymDbNpbuYWPiLNI.pklEmriDEb8FzO14qMq9aEsuFkK
 6YAZM3w5FvcZMYLLNpWGD1wOt9Nij3ZG_eYUtkfXtWY0X7IZSXBxt8tdjgx3BA0kpEZ4wvuf8Ion
 WhZE1nDP_y6NBbBizkXnIRx_U6YcRvEQAtBBf1EyJVHmig2pR_tR0vxU7pMo5I5pe2cB_TduN7av
 b8kFeFwfc7upztHf8b31XrbWIUcL4ftXq25xddKm0N.1UJgGKznmqo6ElQpFuwPkLsYZ5UU81KfI
 FG.7mCYIbSPpYwm4MXJ4A6zkLKmKp0sYxf1LL8hRliY4hZnX58oNkYn3kUFbWUBrAab4ulWeQMRy
 oIlb8QoL9WC2TLBjasAZSUV_XOyeHMsk9NI1M9qZbvRYb0EKAwwmBfYtHt63t7udYj1slelxsEVj
 p5vvjJirRw9d92nJkKlPdfouRW5Sw0Izw.V95snu.b2LP9TxXBM2FYglhhcw.5wwCRw_VzatBJh_
 jp7pvmcJC9VF3_rOQZFC6VB1UyQ7LmVDSuCpOnQw1kfRumo0gYkH5t_cj8v9Op.Y.B8RAzmdKeLE
 M2kc35VO.tK8CENJ4mUx.pdKlvH3MTpwCyzPm0p2ZlM0__KWZRHZnh0owSozKFt1LI3ovOpVrXC4
 .YdSf.PmgG7aCM9YOU68cyDXRbAPop11Cyx_9kQEnx7HfMefIkYTkmheAMugLM_jxpWAXemIPrO6
 GrfVGySxuIdfx9BqYKHSRs2GDXsrl4jNOCkeuCCQ7_YV0x2o4.OL1yTMV7v_Ev_TU4JHwyZhlALJ
 UZsgWES_yNJEjVH97kxYqR0t03_PsJWdF1bY8SMrd_DkIand9xHFk_cxFUxt.R40pg8VTrrY7ey8
 9N.G7bkHBk57rDisO.Bsuy9rmFVN2uq3llG0CTPbn1RyodxPh3PSP.vHgx_C7J9Aa4kqLY8C4RDD
 8elGwHySbyLFzsmEIiQt5.ovGJUceWFxM4hwVJk0lix0Rp_awSq2nmSFmw.C3s8hlpnIRBkYeZ1H
 8dKhW7XFyDr16VahLCSacpsPZ6ZmsZkCSeLVigii0OniIuiai6mgE4_1G_kauXLNDifL2Lzr7HHe
 oT2ycd.61y.70i4CyLNKaC3530QPGUHaCtnZzo3vcbXqDfQ1IlCxA9wTgt8Mp2oZispSAnFTq_8H
 kZ1TJSxg7kf3PIz1_Z7w_CGMginVBUs2H4mEVwKIMQYwbQ9i37T8ZcK1AHm6l9gvOQrQp.NrjKSn
 b6yB0iR02Ws9lgmrWLNNkngap8kzkc.XtNqbiyCiaM8VWOnPX89L_Q_NHfgWwpFFBL.BXMCj69Ds
 tdco0dTwOsu.ooHEUriMf4AgKcs5iHCPLZ4YwRX.6cSIbm_DzHbfG_0dn1FK73hN83BrdLJzh_IE
 jlilWype2pwDdzq9gbcBHIFvGLPZDqOEzJm0UKeI75_iJfnctNweuILNovfUTi71oeCQyQZ45ERz
 EQzyEsNnnuScnBcot4CJ.WlbSbQ7RMCuExLoeo6Vl6gnV2d5yBF3GO3I0vxi3VUFjmMDmGusJCLI
 fcJBbdBjas9iJqMNF0KEhHRi39sv.oEZFj05d2DBwANVcRpYbZJ5uoyGn2_PHxS418VpSLyjPtQN
 xhCBe
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 06:03:35 +0000
Received: by hermes--production-gq1-7b45fb68df-xzq9g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0f93d63cbc93d069b7c3bff7e1e63adb;
          Sat, 30 Jul 2022 06:03:32 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: git: 1dfcff294e44 - main - release: increase IMAGE_SIZE for arm,
 arm64, riscv [odd alignment for SBC images]
From: Mark Millard 
In-Reply-To: <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com>
Date: Fri, 29 Jul 2022 23:03:31 -0700
Cc: Warner Losh ,
 Ed Maste ,
 "Rodney W. Grimes" ,
 dev-commits-src-main@freebsd.org,
 "Dr. Rolf Jansen" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <83383E16-29B2-4181-B666-B0A9C4D5451A@yahoo.com>
References: <16906DFD-286B-4D59-9438-CA9CD9026C55@yahoo.com>
 <202207171708.26HH81bA062303@gndrsh.dnsmgr.net>
 
 <20220719204245.GL30607@FreeBSD.org>
 
 
 <20220729204943.GT30607@FreeBSD.org>
 
 <7E1AE740-FA45-4889-BD70-8EABB0725B39@yahoo.com>
 <3BF6B9DD-26DF-4C82-B2CE-E460D94F6C95@yahoo.com>
 <3B32D8E3-A436-4CF6-8CCB-6798EC7F50DC@yahoo.com>
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Lvv2f0Bh2z3Rrr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=G0vfxJnM;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.36 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.87)[-0.868];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-29, at 22:09, Mark Millard  wrote:


> On 2022-Jul-29, at 20:42, Mark Millard  wrote:
>=20
>> On 2022-Jul-29, at 20:11, Mark Millard  wrote:
>>=20
>>> On 2022-Jul-29, at 19:56, Mark Millard  wrote:
>>>=20
>>>> On 2022-Jul-29, at 13:49, Glen Barber  wrote:
>>>>=20
>>>>> On Wed, Jul 20, 2022 at 10:08:20AM -0700, Mark Millard wrote:
>>>>>> Would it seem appropriate to use a week (this week?) to do all
>>>>>> the snapshot builds with the builders all set to have
>>>>>> kern.geom.part.mbr.enforce_chs=3D0 and see what breaks, if =
anything?
>>>>>> (Sort of a snapshot exp run.)
>>>>>>=20
>>>>>> More than just the SBC images might be involved for
>>>>>> kern.geom.part.mbr.enforce_ch consequences, for all I know.
>>>>>>=20
>>>>>=20
>>>>> Hey, Mark.
>>>>>=20
>>>>> New snapshots for 13 and 14 are up now.  Is it possible for you to =
check
>>>>> if the issues you had run into are indeed resolved, after setting
>>>>> kern.geom.part.mbr.enforce_chs=3D0 on the builders?
>>>>>=20
>>>>=20
>>>> Well, it is a mix, I think (unsure).
>>>> . . .
>=20
> I got a little more evidence about the type of problem,
> I think. (Not that I know the interpretation to give
> the evidence.)
>=20
> Instead of booting the 13-STABLE media I put it into a
> booted system to look at it:
>=20
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> =3D>        0  468757680   da0s2  BSD  (224G)
>          0   10381312  da0s2a  freebsd-ufs  (5.0G)
>   10381312  458376368          - free -  (219G)
>=20
> (I've ignored ufs/rootfs ufs/rootfsa, ufsid/*  above.)
>=20
> Compare/contrast:
>=20
> # growfs /dev/da0s2a
> growfs: unable to read superblock: Input/output error
>=20
> # growfs /dev/ufs/rootfs
> growfs: requested size 224GB is equal to the current filesystem size =
224GB
>=20
> # mount -noatime /dev/da0s2 /mnt
> # umount /mnt
> # mount -noatime /dev/da0s2a /mnt
> g_vfs_done():da0s2a[READ(offset=3D5920980992, length=3D8192)]error =3D =
5
> mount: /dev/da0s2a: Input/output error
>=20
> # gpart resize -i 1 /dev/da0s2
>=20
> # gpart show
> . . .
> =3D>       63  468862065  da0  MBR  (224G)
>         63       1985       - free -  (993K)
>       2048     102400    1  fat32lba  [active]  (50M)
>     104448  468757680    2  freebsd  (224G)
>=20
> =3D>        0  468757680  da0s2  BSD  (224G)
>          0  468757680      1  freebsd-ufs  (224G)
>=20
> # gpart show -p
> . . .
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> =3D>        0  468757680   da0s2  BSD  (224G)
>          0  468757680  da0s2a  freebsd-ufs  (224G)
>=20
> # mount -noatime /dev/da0s2a /mnt
> # umount /mnt
>=20
> After that I can again use it to boot the 8GiByte RPi4B.
>=20
> But, having booted itself, it shows . . .
>=20
> root@generic:~ # gpart show
> =3D>       63  468862065  da0  MBR  (224G)
>         63       1985       - free -  (993K)
>       2048     102400    1  fat32lba  [active]  (50M)
>     104448  468757680    2  freebsd  (224G)
>=20
> root@generic:~ # gpart show -p
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> So, again, no da0s2 BSD or da0s2a freebsd-ufs .
> (Unlike gpart show on the normal-boot main [so: 14]
> system.)
>=20
> After shutting down and plugging into the normal-boot
> system . . .
>=20
> glabel list on the normal-boot system with the USB3
> SSD plugged in shows:
>=20
> Geom name: da0s1
> Providers:
> 1. Name: msdosfs/MSDOSBOOT
>   Mediasize: 52428800 (50M)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 1048576
>   Mode: r0w0e0
>   secoffset: 0
>   offset: 0
>   seclength: 102400
>   length: 52428800
>   index: 0
> Consumers:
> 1. Name: da0s1
>   Mediasize: 52428800 (50M)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 1048576
>   Mode: r0w0e0
>=20
> Geom name: da0s2
> Providers:
> 1. Name: ufsid/62e358b6cff37c76
>   Mediasize: 240003932160 (224G)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 53477376
>   Mode: r0w0e0
>   secoffset: 0
>   offset: 0
>   seclength: 468757680
>   length: 240003932160
>   index: 0
> Consumers:
> 1. Name: da0s2
>   Mediasize: 240003932160 (224G)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 53477376
>   Mode: r0w0e0
>=20
> Geom name: da0s2
> Providers:
> 1. Name: ufs/rootfs
>   Mediasize: 240003932160 (224G)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 53477376
>   Mode: r0w0e0
>   secoffset: 0
>   offset: 0
>   seclength: 468757680
>   length: 240003932160
>   index: 0
> Consumers:
> 1. Name: da0s2
>   Mediasize: 240003932160 (224G)
>   Sectorsize: 512
>   Stripesize: 0
>   Stripeoffset: 53477376
>   Mode: r0w0e0
>=20
> while the gpart show -p on that system lists:
>=20
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> =3D>        0  468757680   da0s2  BSD  (224G)
>          0  468757680  da0s2a  freebsd-ufs  (224G)
>=20
> =3D>        0  468757680   ufsid/62e358b6cff37c76  BSD  (224G)
>          0  468757680  ufsid/62e358b6cff37c76a  freebsd-ufs  (224G)
>=20
> =3D>        0  468757680   ufs/rootfs  BSD  (224G)
>          0  468757680  ufs/rootfsa  freebsd-ufs  (224G)
>=20
> Having managed to expand da0s2a seems better, but
> it is still odd, including the mismatch in what
> the self-booting 13-STABLE shows via gpart show
> vs. what the normal-boot shows. The normal-boot
> is of (line manually split for readability):
>=20
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #59
> main-n256584-5bc926af9fd1-dirty: Wed Jul  6 18:10:52 PDT 2022
> =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
> arm64 aarch64 1400063 1400063.
. . .

So I tried plugging in the 14-CURRENT media into the
RPi4B while it was booted from the 13-STABLE media.

root@generic:~ # gpart show
. . .
=3D>       63  468862065  da1  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  da1s2  BSD  (224G)
          0   10381312      1  freebsd-ufs  (5.0G)
   10381312  458376368         - free -  (219G)

=3D>       63  468862065  diskid/DISK-00000000000A  MBR  (224G)
         63       1985                            - free -  (993K)
       2048     102400                         1  fat32lba  [active]  =
(50M)
     104448  468757680                         2  freebsd  (224G)

=3D>        0  468757680  ufsid/62e3bdbe47334896  BSD  (224G)
          0   10381312                       1  freebsd-ufs  (5.0G)
   10381312  458376368                          - free -  (219G)

=3D>        0  468757680  diskid/DISK-00000000000As2  BSD  (224G)
          0   10381312                           1  freebsd-ufs  (5.0G)
   10381312  458376368                              - free -  (219G)

So: BSD and freebsd-ufs visible.

root@generic:~ # gpart resize -i1 /dev/da1s2
da1s2a resized
root@generic:~ # gpart show
. . .
=3D>       63  468862065  da1  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  da1s2  BSD  (224G)
          0  468757680      1  freebsd-ufs  (224G)

=3D>       63  468862065  diskid/DISK-00000000000A  MBR  (224G)
         63       1985                            - free -  (993K)
       2048     102400                         1  fat32lba  [active]  =
(50M)
     104448  468757680                         2  freebsd  (224G)

=3D>        0  468757680  diskid/DISK-00000000000As2  BSD  (224G)
          0  468757680                           1  freebsd-ufs  (224G)

Note that ufsid/* disappeared.

So only the boot media seems to stop with:

=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

(no BSD or freebsd-ufs or such).


Unfortunately, the 14-CURRENT media seems to consistently get:

. . .
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on =
usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
Root mount waiting for: usbus0
uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=3Drw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot>=20

This is independent of if I use initial_turbo=3D60 or
force_turbo=3D1 in the RPi4B's config.txt . (These
avoid variability in the actual timeout time frames
in the early activity.)

However, my normal use of main [so: 14] is not via
WITNESS/invariants or such but the snapshot build
is. So I might not have noticed and this might not
be new for WITNESS/invariants main-kernels.

As stands, 13.1-STABLE is my better test context.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jul 31 16:55:37 2022
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 4LwnSb1Znwz4XjWP
	for ; Sun, 31 Jul 2022 16:55:43 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LwnSZ2WMdz41mT
	for ; Sun, 31 Jul 2022 16:55:42 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18])
	by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 26VGtead020054
	for ; Sun, 31 Jul 2022 12:55:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
	t=1659286541; bh=xgrkf+aQVhDBx70QzLYGa7udVQXePMgpkxjJQuoQ3Oc=;
	h=From:To:Subject:Date;
	b=a38Rx4PlwhqXIeHhPUCqbQttZPUkYvjeUz/rnH7czK5yCiv3B7NBo/ex5p7w75PHE
	 MGG2Ls4hhcFSbTlN9OSQogWmn9NjDkKHRTtDAHQKaHd1JzOXlOLy76g0++ktyMplS0
	 nsQiRB7XSQElY/gk5WP4Hx0G5XhgkuhSH/wD3t4cq1tYRJdWt4i2cCeYmQb5tQTmox
	 /VzN5RICTnlV3plK30HYSGPyX60/s7ChYuuG05lauMrrfHytRvN1qHZDr1nFsFpl4z
	 eGL6E9rDbHrPm9l/McODy7jfnCKWE8QXByby0BwV/7fNHDL3ozctrI8BKfBGmdHwJo
	 M3gJhCr4qSvDA==
Received: from w92exhyb8.exchange.mit.edu (18.7.71.113) by
 oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id
 15.0.1497.36; Sun, 31 Jul 2022 12:55:33 -0400
Received: from oc11exhyb7.exchange.mit.edu (18.9.1.112) by
 w92exhyb8.exchange.mit.edu (18.7.71.113) with Microsoft SMTP Server (TLS) id
 15.0.1497.36; Sun, 31 Jul 2022 12:55:40 -0400
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (104.47.73.41) by
 oc11exhyb7.exchange.mit.edu (18.9.1.112) with Microsoft SMTP Server (TLS) id
 15.0.1497.36 via Frontend Transport; Sun, 31 Jul 2022 12:55:40 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=N41bnDQTxCQndrWfo6uL/AuFikA3+NZpiGVJeBQctsDJQQYBggApzaeqUPFcmBOzWN6Ly6OMryeVKLmQ4Xi+lwLQ/wX8WVjGME8ARtC77EwtrnIbiJrkCI523wm00gyoMbnFsHXRUSSZ2twXxvO7UGpQs0L9HGOztD+pYf3KK+kw/jsfwvfTM1gM0Um2Rr739JA55si1hRXGujX/l5V+J4FrmmeBJf/3xggcEgvi6TzYU8Bz9BGZpP0sS3qA5PZFGivWKcy+9+1m3XOG6aDuvbhLB0Qv2Q6NWzq9aMgEdhV9LadMkuyqvJhByvGesIjg2qVysWdhJpf+T86i1f0AKA==
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=i1InLHqu8txgpHnNrpEVnvovuNGANWRChJaUeEGY/LM=;
 b=KPwlY6AlVglqaG6NTtrG3cCL5vq74xghehB57N+JIdm4UGkSU3eXFw5Xb7pas6qNufWmuMThqhy0VtUptzDoY+Itt1nNBKlEipWmYFyLyOsAe/exPM8/qhK+xAEFenFdfi/E0mDv5RKSeK0hPPvz8GJWZYmyicMKBY+6yFqHFBneSRk0MtF44nT71UBsqy3SnU69v3qdOSslZuL/+Zh4Y84oe67LQWHzFVmo4QAdu1r5DVvQm4fRTKJJrGRvPu4+Ee+JcHhhWlWOCqjPjYRqUeRmjzxu5GIkSg3Zjywzcq7OeVo8nfqbREfhXUcynguJRCm0ovijwtApUo1vGgdWqA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass
 header.d=mit.edu; arc=none
Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by
 BY3PR01MB6628.prod.exchangelabs.com (2603:10b6:a03:369::17) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5482.11; Sun, 31 Jul 2022 16:55:37 +0000
Received: from DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::691a:67ca:e872:17b]) by DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::691a:67ca:e872:17b%5]) with mapi id 15.20.5458.024; Sun, 31 Jul 2022
 16:55:37 +0000
From: John F Carr 
To: freebsd-arm 
Subject: ARM64 system error
Thread-Topic: ARM64 system error
Thread-Index: AQHYpP5bGvJv3qqrN0SSt+UpzxtySA==
Date: Sun, 31 Jul 2022 16:55:37 +0000
Message-ID: <82D60642-4087-4EED-B790-F8FE81A188C5@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7f869667-e190-4ae5-9f13-08da73157e5f
x-ms-traffictypediagnostic: BY3PR01MB6628:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: T6cAdYuqH0IT9ReMuUqqXszJEgVjBHCiqkNonPIjP1DClVD30SbEGHsvrwB7NTuAdx9DWMzyiXg6+IvqrJj0j+N5jLZs0IrkwWYzZX+KHH6z84e7CG4JJK9W9G4BsBuhGGzpMj98pJb4mmDvPNbYmqO8sNvefAvj8C9Vpc33s1UX4eaH0D4exlN3nvNMkq00tVMyC6TJhFha/vNqG7rvvhyC6wwAtv1FdjSFahUAOxVPqHvnvBLQoFBaWHOEc46575kc0m/b1FCEQ9VgjB8KufVf1xw6w2kEr4mUGU0/u3SjSV6h/88Dx+TUkahQHHyGrkjGNPGvWvr4dWiTbkuvLVVY6HGHu+20aMiAYEzc9un7uA19t3+1XOX6ODz+XVtxehowbrhQbYSXgn8A36hQesAdUxAhp4U7sqyKBqtmXbDLK44WneVs2Jm7l5Kwb6NL4BUsNFCVSvSgAUWsInUbXNgSLj6OARVmIgleIzec+EL084kKocgf9Nm8Jkt60NJsdaoyUbRPKIyPPXe5jNMkr4U0BYQQ+RIqHvM5eFvarLFptrspMVYN3Y5wRWi5QMNxfsA2+l62i8oKw5SH88z4P3R4+peouyl8+omz0DeihDVeqQEA0+1+eeie5+JR0qrFaN98VZTJU38glAxSyqnqbUZwbLzWJgVj0YF2oNdNEr+MwITSXMnApp9On0ycQkokGCuYaGLnSZ0hvaX28a8egE7aVbVXmWfL20JJttcw0hfayTgIn6JgP9hAK1E8EsVe4n9cI/xXe2AMHr/ks8hJjZSJDycyyz24FSf/TO+72g9BL6Yd1XIT+xu4m+XcWOkW
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(396003)(376002)(346002)(39860400002)(136003)(2616005)(26005)(6512007)(186003)(38100700002)(86362001)(122000001)(75432002)(38070700005)(99936003)(83380400001)(8936002)(5660300002)(91956017)(7116003)(66446008)(41320700001)(76116006)(8676002)(36756003)(64756008)(2906002)(71200400001)(66476007)(66556008)(478600001)(66946007)(6486002)(6506007)(41300700001)(6916009)(33656002)(786003)(316002);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tSFsDMc9MJH/Rd9pZam4tgFvihSqcfJXuh5cMMfXnKt1tv0RmN8dyN9scb17?=
 =?us-ascii?Q?qFE+Y2YBdwmx5XyvGhgyoaqk5675cK0/bZp1vkNeeQfDEvQ/FC8UTI21NQVA?=
 =?us-ascii?Q?VUU4GMoOsbjo8yePMvh+GQ/KSDmcKMwXGHzEae5Nwr/eFpnQoxXHa/tVUEPC?=
 =?us-ascii?Q?HUhuhEDihXDaXjl81Pz4xXKl4ghv3V8Pv1e4RJdZm9MgtcAI1dJ9wnFnS9g0?=
 =?us-ascii?Q?AyhsAbjPCm7jIPyUBAhkoaxrP9mYpDbvRH2NZV9XjuNlhjkAFc+i7222ni4P?=
 =?us-ascii?Q?EPMAceC2eNjJ/HJvJz17qBbNaHQqvvC+aKB0QnFshU73+tKC1BSyLflqi/3n?=
 =?us-ascii?Q?mdL5YlJrZlNPfVow4IAlDQNbFmUQLrb5XA20KVLlkunZZk5/yyE27jHiSOp7?=
 =?us-ascii?Q?KMdKtjHKvoFGYfpOmMtfOk2fgMeZEabnP4NrCcwkVgac1oIRve7EHhaiVJ9H?=
 =?us-ascii?Q?jczUIZ84pvivkjZQoTUW2esLHtqKD1Ypu2EhyStrQkR/gBFnIlQanztGrCIj?=
 =?us-ascii?Q?LzB5NMjOoE91+oeC32Ympz8S4Uid5qZca0Km/XzxEZ0P2BVRgS2DKaKT/VxU?=
 =?us-ascii?Q?viq55tpIMdYvAODpCIcPiZz+x9jmnYFeA9eYVrJwf7WPEnbUamg45bMnygps?=
 =?us-ascii?Q?j+J2oEU1+l5opBhLgqlbwfPBg/yVPmg6OUz2SmbAZgTTY/WUvVTa7KcicIQL?=
 =?us-ascii?Q?jr1SodbVZopOkKD7G0jJncZn526DiLiYEAK7pN2POuOgWkF6XezAiqmX1ICv?=
 =?us-ascii?Q?PYvWGfTALahUnoeQsUDLZ3bJXcPH3j9VEQx7EIRxQDi1lkRHvPwo5BdI8gLR?=
 =?us-ascii?Q?3grWrHRD2UH6BYkpXibXCxkc30YWhPJqsIDtqOvvW5VIP8FTyf0XQULk1YAs?=
 =?us-ascii?Q?v3+daNCp7U6ztwQnHCkP+wKeQxbtIYH9hvJQJpFSBYyzm5kYeXLWqPjqSwrz?=
 =?us-ascii?Q?IvJmU02XYR+Lk8QnkeFNrvHgqlotKdYTdGBYTGbyEWAlhcK+4EWIQ+XffcyS?=
 =?us-ascii?Q?ryLpVRYN2arxBjcyKbeCtL32jpWEQLKKAIA5LP+TRWDOwosOUiwlgQIpNvML?=
 =?us-ascii?Q?CUfAdJWKrWK9EAaoWHOPlOg06j/s2U4rQkq8lmP+D3Ha4mQzBrsRsafD4RET?=
 =?us-ascii?Q?iJGHHag2BUt97LtqCqKaxvkWP6vGNIApUe6olMDtpDHeD8fsp0pqOXVNHmAs?=
 =?us-ascii?Q?KVbQX3bJp9ACkXZjvHanT+zpCw9rVFMLxCFECm/eqX0epWKREdyzzSZMXa25?=
 =?us-ascii?Q?SBcOft6IKAVAX6xrIgwXyB/14I9zXWy2tgL7IRFPGGafJ9gEajz1FyqTf7cS?=
 =?us-ascii?Q?TDenwz7kuTQwzRYRjQmVhQeFUZUcM2figo2YgWhuFul9YVvqmyT4em0akDGb?=
 =?us-ascii?Q?0iT/IqfEE5e6MYC23kApcjEOclXRluonWrAf4fNdH2F3k3MpGC70eVovhOQO?=
 =?us-ascii?Q?254tmh21tburfnoqXaMVJoI3Rf8xYh1PFuo7coiHdF4/en0DWfJIDO7NTUXs?=
 =?us-ascii?Q?rS7hmLaI3mSc6Z8CQBvmUlrujrsAjALAaxvb8CIldsyhTFS5Je/yYZi4ZARZ?=
 =?us-ascii?Q?Fw6kFO3JV0RQ0GnfN9Q=3D?=
Content-Type: multipart/signed;
	boundary="Apple-Mail=_93AB9036-D9A6-4D8F-AFCE-42DC4E901BC8";
	protocol="application/pkcs7-signature";
	micalg=sha-256
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: DS7PR01MB7712.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f869667-e190-4ae5-9f13-08da73157e5f
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2022 16:55:37.7736
 (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: uN/bexqR4G3n+t/MyZ99ABIHpWc6ePrqytzEaVI88tgq+We23iba9KNJKlH7dLS3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY3PR01MB6628
X-OriginatorOrg: mit.edu
X-Rspamd-Queue-Id: 4LwnSZ2WMdz41mT
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mit.edu header.s=outgoing header.b=a38Rx4Pl;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}");
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [-6.79 / 15.00];
	SIGNED_SMIME(-2.00)[];
	DWL_DNSWL_LOW(-1.00)[mit.edu:dkim];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.992];
	DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing];
	RCVD_IN_DNSWL_MED(-0.20)[18.9.28.58:from];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.73.41:received];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	TO_DN_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[mit.edu:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_SEVEN(0.00)[7]
X-ThisMailContainsUnwantedMimeParts: N

--Apple-Mail=_93AB9036-D9A6-4D8F-AFCE-42DC4E901BC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

My OverDrive 1000 (Cortex A57) running CURRENT just crashed with the =
unhelpful message "panic: Unhandled System Error".  Is there any way to =
get better information?  The ESR value bf000000 translates to "system =
error with implementation-defined code 0" so that's not much use.  The =
instruction associated with the interrupt can't fault ("subs w22, w22, =
#0x1") so it must be an asynchronous error.  On other systems I've seen =
bits you can test or registers you can read to get details.

  x0:                0
  x1: ffff0000b55bd000 (crypto_dev + b3f34ec0)
  x2:             2880
  x3:               20
  x4:               d3
  x5:                0
  x6:              100
  x7: ffff00011063daa0
  x8: ffff00000077218c (generic_bs_r_2 + 0)
  x9:             2880
 x10: ffff0000001ff9f4 (msk_phy_readreg + 84)
 x11:         a0000045
 x12:         56000000
 x13:         5e4a6f28
 x14: ffff000000c4d038 (vnet_entry_ipport_stoprandom + 0)
 x15: ffffa000016b3000
 x16:         40ef9400
 x17:                a
 x18: ffff0000b550e560 (crypto_dev + b3e86420)
 x19: ffff0000b57dc000 (crypto_dev + b4153ec0)
 x20: ffffa000029dc800
 x21:             2880
 x22:              3c4
 x23:             796d
 x24: ffffa000017f4100
 x25: ffff000000ad3da0 (miibus_readreg_desc + 0)
 x26: ffff000000bb6000 (vop_deallocate_desc + 28)
 x27: ffff000000e36980 (cc_cpu + 80)
 x28: ffff000000b1b828 (lock_class_mtx_sleep + 0)
 x29: ffff0000b550e670 (crypto_dev + b3e86530)
  sp: ffff0000b550e560
  lr: ffff0000001ff9f0 (msk_phy_readreg + 80)
 elr: ffff00000077806c (handle_el1h_irq + 8)
spsr:         a00002c5
 far:                0
 esr:         bf000000
panic: Unhandled System Error
cpuid =3D 2
time =3D 1659270153
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
do_serror() at do_serror+0x40
handle_serror() at handle_serror+0x38
--- system error, esr 0xbf000000
handle_el1h_irq() at handle_el1h_irq+0x8
--- interrupt
msk_phy_readreg() at msk_phy_readreg+0x84
e1000phy_status() at e1000phy_status+0x114
e1000phy_service() at e1000phy_service+0x420
mii_tick() at mii_tick+0x50
msk_tick() at msk_tick+0x44
softclock_call_cc() at softclock_call_cc+0x128
softclock_thread() at softclock_thread+0xc4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 2 tid 100026 ]
Stopped at      kdb_enter+0x44: undefined       f907c27f


--Apple-Mail=_93AB9036-D9A6-4D8F-AFCE-42DC4E901BC8
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA7sw
ggO3MIIDIKADAgECAhEAllRUaZWy44T/aVEsqzSrczANBgkqhkiG9w0BAQsFADBsMQswCQYDVQQG
EwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0
aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMB4XDTIyMDcwNTE2NTQ0
NVoXDTIzMDczMDE2NTQ0NVowgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQL
EwxDbGllbnQgQ0EgdjExFDASBgNVBAMTC0pvaG4gRiBDYXJyMRowGAYJKoZIhvcNAQkBFgtqZmNA
TUlULkVEVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Ka5+9REw1B9JXThajulqv
SjDFK1pNpGB2nljRQy5iTTTVddq/4+s+uC88etHWbMquFd/i9sCIxLHgDFhlGZRhcORhzDfwIxLA
P8q4KMsAPeXO2kgh86pGH+DEsUPEbEtdkN2cnT9kt+BE2cPCOiqAR+YBWZX3ebDLc4+eWiPfErg7
WEr4XcIraxxxtLuUR6sVbN7nG7WCtBCalzbAxryy5GmWZ1z4OawzylJVb+qLKeMi3XN+H/d+shdm
6PmyqGeCu7jpN3+g/eAuWk/PWhIUhDwABK9JGWW2+xWCtDHxutzRt8vDMZK2GaE6MzpBpTFR1P1o
IdodVtrHGtVnKq0CAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBQCc+0gYnBj
WRsOZgQ78pmO+ojOaDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRj
bGllbnQuY3JsMA0GCSqGSIb3DQEBCwUAA4GBAAm/9fT9H4n5ks4q9cGE5FWIwAQmEGre6gMVU+VL
V4p2Qfd4eZki0uKg+Vi6BWeHL2GMQQpnpjgm1Xx6q7oSruPTkkrs75X7oTW5Nf550U5qEKXSqboK
y+6dkw8fNvNci0tYs0j+Ev6JPU4VgDK/NSWtRFrndFzLI2SgJ6k+Ess4MYIDRjCCA0ICAQEwgYEw
bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1
c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZU
VGmVsuOE/2lRLKs0q3MwDQYJYIZIAWUDBAIBBQCgggGVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDczMTE2NTUzNlowLwYJKoZIhvcNAQkEMSIEIJf8Mv4vDFme
Rsj7MFPj/hasHFFJYI+ixtAwhDFzNomBMIGSBgkrBgEEAYI3EAQxgYQwgYEwbDELMAkGA1UEBhMC
VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0
dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZUVGmVsuOE/2lRLKs0
q3MwgZQGCyqGSIb3DQEJEAILMYGEoIGBMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo
dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw
EwYDVQQLEwxDbGllbnQgQ0EgdjECEQCWVFRplbLjhP9pUSyrNKtzMA0GCSqGSIb3DQEBCwUABIIB
AE3WQAzLfG9jwm5+99O8oMrt7WdQpV3pQo1WDHe58KaFIaSGomt7qAeubFE+zMn+F13oYj55u34E
MQwxhb2GusLs3eEGp68QWbw1Ah9FWXySvo40Rc/Fdqr8YQ37gpvjyriU2AnOy26XJi/F6sWop1/J
Iq6gseG2MO7TnGBtAMWmQB7JeuB5UmS6WINKMTo6vvgykjTXfEU4alNGJCr9Uqi+hp5mWme9p+x7
cMniiaoa9Sm5FmvaXjjf2OyMhOk9G0TUQGSKDIR5ByG5X4y+hIOvwTN6hb3hSYe3bL6pcafMfOC2
LwXnq5Hi2ABoC2KDPdHscq72eFcE8UmH3KQqayIAAAAAAAA=

--Apple-Mail=_93AB9036-D9A6-4D8F-AFCE-42DC4E901BC8--

From nobody Sun Jul 31 21:00:53 2022
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 4LwtvT5vDtz4XB3L
	for ; Sun, 31 Jul 2022 21:00:53 +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 4LwtvT2Nj9z3bdW
	for ; Sun, 31 Jul 2022 21:00:53 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4LwtvT1W0Cz17Cg
	for ; Sun, 31 Jul 2022 21:00:53 +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 26VL0rKs007393
	for ; Sun, 31 Jul 2022 21:00:53 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 26VL0rlV007392
	for freebsd-arm@FreeBSD.org; Sun, 31 Jul 2022 21:00:53 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202207312100.26VL0rlV007392@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, 31 Jul 2022 21:00:53 +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="16593012531.7d8DEF.4587"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659301253;
	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=hLTzUI+WkplVh9o5UjvQYt3/2L4uRnlVWg9PgxymXik=;
	b=BbOkX4oIHMSMnIMJ0O/Kwo2PMKTQgxuHP2tMsXLh25CTnyWTofHgGADvN73NX7UTo7DJYg
	dBtlAoHHCt2NyVTQf0qsLqknBZBOG2ckhB4Qmaq66Si+E0HfSkP0bsjJQx2mqRCP3Nx7NC
	xUaSK5rVNe4nfKU0HolsEnDPqykZADzSJNv/NvJ5O0xx3PKvmXZCS7PDR2/FFpQl1Cy11d
	sj5bW6h4Ks9gUfLo2Qlp5siUujkBYM5o8+RvSMbAHx54wkgiUX4McFcSzF9S+XkQLelCYH
	mo//C1B+8mOEP/dBAQLuugqvOK2SAaIyOW9OTY1qPgyXJZx0cZIIO8xzN7IiLg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659301253; a=rsa-sha256; cv=none;
	b=TRpTGU8dZpCpz4/iamQAz6ETonuLgLSr4GaRSoVnlZbs4vyskd2tfTLu/0htQ00ucjQ59F
	YrqllONaXgDWun3e3DP5B9SixN8QdDS7k7MAGkpkGblyxYE2bWxvW2Dx86oTDDxP2/7ouk
	EmNil1G0bE/5AA1j5vyldV7TEj5vbY/jU9u1Qp0DgU5n3lnjrjk8xYK3MheGX7Ro9W1xsb
	OpXeJWfNcTznScL6PcywN8zgIXmtOVrZ9eiAf9IYNFf3oPF4s4PD0/CyebJMmjULAuLvzS
	0eAMnpuzXaT01fmqoESQjcf+9iPb+T8r5zVWk2Bl3KVIcDvw9pWGxhAJLxEEgA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16593012531.7d8DEF.4587
Date: Sun, 31 Jul 2022 21:00:53 +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.

--16593012531.7d8DEF.4587
Date: Sun, 31 Jul 2022 21:00:53 +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.


--16593012531.7d8DEF.4587--

From nobody Wed Aug  3 16:28:21 2022
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 4LyckR22zpz4Y5Cy
	for ; Wed,  3 Aug 2022 16:29:03 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LyckP0XMmz3vv5
	for ; Wed,  3 Aug 2022 16:29:00 +0000 (UTC)
	(envelope-from andrew@fubar.geek.nz)
Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43])
	by fry.fubar.geek.nz (Postfix) with ESMTPSA id C3D784E706;
	Wed,  3 Aug 2022 16:28:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz;
	s=mail; t=1659544102;
	bh=PPNIWnZkk3ZDhcU8aZX9/LyLu49gNrIv4HOjz3EEO0k=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To;
	b=Tk1IpzBdGsv5RpQQItJ/LHFWl+U9JG8fLD9cmy77+SqJftwlOcjiOFCqb1R58uWw8
	 EuvCbboBEKCmrdFqSsFiTRem+Qqqu9rQk4axMEU3yxagh4lcn+i7s95N3Xjkx2+z1I
	 oz1wHRTV4x3TzO6DsItEL1866L4tKg7aQj0wQvfk0OVAg2ccNbnWEFO8btjP0C73/5
	 m7eC/hEV8uNbQslYGBF5nZSTVgJIv10nM6NVT6CLsr76d1Ww/LBp645hE+zbQnE/X/
	 RfE8bE/aP5pnI+kasq1VBgLn89Ku0cTAUf5arb/Fbj0w0qmoJbf0zP1j38zoky1J4z
	 axEdWpGbXSiCffuzHbvNcLS0hf81Tls3Jw+3EcPQ1YxxqQCrS2SRp3PKaBxF5a2DhD
	 plfhCq1rTLBuheduoLxTyLxvp4Q67C5etGDU2/FbSPxR4YwE6Rl4GXxN+obV08LDJk
	 DpW2twod8PKCKjXsbYAtYwtRl/y5EU1CSLaqR1lZ+zMF3FEt2xvjqPBstr4ScDMMDy
	 1KLks6BIStkUPiCYrYD9uXnwpbHRuroubF9NvphcbWA+lrn3GV4UaarniMXzZ3aQ1x
	 e9x/UWgd5ytdNlvt8/MErT4Q7nXgSBAeW6aEj5cfeXRvfkt335V15PrX0rvFBe5jM/
	 uv5SCfrh5xEQxTsIsicPQxBY=
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 \(3696.100.31\))
Subject: Re: ARM64 system error
From: Andrew Turner 
In-Reply-To: <82D60642-4087-4EED-B790-F8FE81A188C5@mit.edu>
Date: Wed, 3 Aug 2022 17:28:21 +0100
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <82D60642-4087-4EED-B790-F8FE81A188C5@mit.edu>
To: John F Carr 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LyckP0XMmz3vv5
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=fubar.geek.nz header.s=mail header.b=Tk1IpzBd;
	dmarc=pass (policy=none) header.from=fubar.geek.nz;
	spf=softfail (mx1.freebsd.org: 139.59.165.16 is neither permitted nor denied by domain of andrew@fubar.geek.nz) smtp.mailfrom=andrew@fubar.geek.nz
X-Spamd-Result: default: False [0.30 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US];
	DMARC_POLICY_ALLOW(0.00)[fubar.geek.nz,none];
	DKIM_TRACE(0.00)[fubar.geek.nz:+];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEFALL_USER(0.00)[andrew];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	TO_DN_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 31 Jul 2022, at 17:55, John F Carr  wrote:
>=20
> My OverDrive 1000 (Cortex A57) running CURRENT just crashed with the =
unhelpful message "panic: Unhandled System Error".  Is there any way to =
get better information?  The ESR value bf000000 translates to "system =
error with implementation-defined code 0" so that's not much use.  The =
instruction associated with the interrupt can't fault ("subs w22, w22, =
#0x1") so it must be an asynchronous error.  On other systems I've seen =
bits you can test or registers you can read to get details.

By my reading of the Cortex-A57 documentation [1] I think the ESR value =
shows the exception can be attributed to the current core, is =
containable to a given code sequence, and is a decode error.

It=E2=80=99s likely due to msk_phy_readreg accessing the phy, but it =
doesn=E2=80=99t respond quickly enough.

Does an older kernel boot? If so can you try bisecting to find which =
commit caused the panic.

Andrew

[1] Bottom of =
https://developer.arm.com/documentation/ddi0488/h/system-control/aarch64-r=
egister-descriptions/exception-syndrome-register--el1-and-el3?lang=3Den

>=20
>  x0:                0
>  x1: ffff0000b55bd000 (crypto_dev + b3f34ec0)
>  x2:             2880
>  x3:               20
>  x4:               d3
>  x5:                0
>  x6:              100
>  x7: ffff00011063daa0
>  x8: ffff00000077218c (generic_bs_r_2 + 0)
>  x9:             2880
> x10: ffff0000001ff9f4 (msk_phy_readreg + 84)
> x11:         a0000045
> x12:         56000000
> x13:         5e4a6f28
> x14: ffff000000c4d038 (vnet_entry_ipport_stoprandom + 0)
> x15: ffffa000016b3000
> x16:         40ef9400
> x17:                a
> x18: ffff0000b550e560 (crypto_dev + b3e86420)
> x19: ffff0000b57dc000 (crypto_dev + b4153ec0)
> x20: ffffa000029dc800
> x21:             2880
> x22:              3c4
> x23:             796d
> x24: ffffa000017f4100
> x25: ffff000000ad3da0 (miibus_readreg_desc + 0)
> x26: ffff000000bb6000 (vop_deallocate_desc + 28)
> x27: ffff000000e36980 (cc_cpu + 80)
> x28: ffff000000b1b828 (lock_class_mtx_sleep + 0)
> x29: ffff0000b550e670 (crypto_dev + b3e86530)
>  sp: ffff0000b550e560
>  lr: ffff0000001ff9f0 (msk_phy_readreg + 80)
> elr: ffff00000077806c (handle_el1h_irq + 8)
> spsr:         a00002c5
> far:                0
> esr:         bf000000
> panic: Unhandled System Error
> cpuid =3D 2
> time =3D 1659270153
> 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
> do_serror() at do_serror+0x40
> handle_serror() at handle_serror+0x38
> --- system error, esr 0xbf000000
> handle_el1h_irq() at handle_el1h_irq+0x8
> --- interrupt
> msk_phy_readreg() at msk_phy_readreg+0x84
> e1000phy_status() at e1000phy_status+0x114
> e1000phy_service() at e1000phy_service+0x420
> mii_tick() at mii_tick+0x50
> msk_tick() at msk_tick+0x44
> softclock_call_cc() at softclock_call_cc+0x128
> softclock_thread() at softclock_thread+0xc4
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 2 tid 100026 ]
> Stopped at      kdb_enter+0x44: undefined       f907c27f
>=20


From nobody Wed Aug  3 16:50:49 2022
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 4LydDQ5L2nz4Y81D
	for ; Wed,  3 Aug 2022 16:51:34 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LydDP5pYxz3xl3
	for ; Wed,  3 Aug 2022 16:51:33 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15])
	by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 273GpSvY000768;
	Wed, 3 Aug 2022 12:51:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
	t=1659545491; bh=l5fnNgOGbNYKj3PHhnGR37xwahCn+lJuJsZK11APBjI=;
	h=From:To:CC:Subject:Date:References:In-Reply-To;
	b=dBmbPTV8GvNCCWIEP2pHWq9exTK4zEicb0Y0u5i6EI+2mZFPjDMF2KANEuOgAzdnm
	 oUVp6m3j76l/IUz7XUxBqOmLVs7hedlyDykSAbCVMdPaOOhvqgCe8EHTGmTMYWIGMR
	 hWWhWMJWjWSRqlmM0tACW+SYdrSzR/MvjTjpxqtdRkB338dwtOZMnBxGAOdUiFQI87
	 +F64R5IJU0p7G65zgl3tYyZNHa9c5qFbFpnUHk20AFDwa3B9Mhjg0mRT8wL34pVPFH
	 q3pYCDrs67NaEh9DpmEXE/h0Yd+/2y3m7DCoO205bh3aZa9RfdJjCqm0wqyn6e/oOS
	 Od1M2OQtULfwQ==
Received: from oc11expo22.exchange.mit.edu (18.9.4.84) by
 w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id
 15.0.1497.36; Wed, 3 Aug 2022 12:50:43 -0400
Received: from oc11exhyb1.exchange.mit.edu (18.9.1.60) by
 oc11expo22.exchange.mit.edu (18.9.4.84) with Microsoft SMTP Server (TLS) id
 15.0.1497.23; Wed, 3 Aug 2022 12:50:57 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176)
 by oc11exhyb1.exchange.mit.edu (18.9.1.60) with Microsoft SMTP Server (TLS)
 id 15.0.1497.36 via Frontend Transport; Wed, 3 Aug 2022 12:50:57 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UoTn5v8bpV1dPt9ySvvMoofgCi/tkgcuyZH4iRz0LiPAK6TGr3jE2PmqQCCisjaTDXdUGAU6Qdg/tb83KNHzwPTNMxo9OsBJ79XM+SpnEbUCK+hKns7j995gvGA9RiGFHKOgrk0ZdEl/1qmHI0i7Mv8xC8gcXMAbZaXZza1hJWugOOX3cNJpsM3IZUo+vAnqx99A+Qnhhs+njnwHH0amGuapcvoUsL3S0wzBR9+Q/wXHFzfHM45vpeDo1XP8x4QYvfEIzgQEBxQnE55si0nARGsTuDz998LX4plIXVlgmZDhXOrAGcBWvrQICERfBSCwS4VC681lHU21ZKxmHnc+qw==
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=Vau4cnO5eRrg4JYr8+ZlEpY2rwgPTbFYDzroUVrq6GM=;
 b=dgtpCo31/6yDkjRWJU43NpS3HcwgVyc5RMzj2BxGkjKJk91sqPlEEOxjCz0tK5hEubsuupi6ulo67e7WkBG2I9Mi8xHzaEEkG1X1BJ8ClfHDqWX1rO5/pxaF72MHU5vSawoGUsQJm/7S44eEnHj+7q5/tQ09x2TQIBCGGYTj5bVy+FjuJuUDzenK2SS72UjW2c2xqNnKnz8CWlNs3iqJ2TWrkkmw6+jH2i0Gblc2QGlUKhNta139+7dDcX2fMfp2Yin+b0+VrEHchMhGX1satJq68vx8ntchXQIDvEyD5ElK5+AXP6VphI1GH6D4wLSlNjqs0EH76aMSCDCc94UJpQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass
 header.d=mit.edu; arc=none
Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by
 SA0PR01MB6473.prod.exchangelabs.com (2603:10b6:806:ec::8) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5504.14; Wed, 3 Aug 2022 16:50:50 +0000
Received: from DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::441:a967:718c:a33f]) by DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::441:a967:718c:a33f%2]) with mapi id 15.20.5504.014; Wed, 3 Aug 2022
 16:50:49 +0000
From: John F Carr 
To: Andrew Turner 
CC: freebsd-arm 
Subject: Re: ARM64 system error
Thread-Topic: ARM64 system error
Thread-Index: AQHYpP5ct5Z+5/daoUaDqyaLZhUVs62dYhqAgAAGRIA=
Date: Wed, 3 Aug 2022 16:50:49 +0000
Message-ID: 
References: <82D60642-4087-4EED-B790-F8FE81A188C5@mit.edu>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5fb8ef9a-c02e-4190-a2c7-08da757051e0
x-ms-traffictypediagnostic: SA0PR01MB6473:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ckC+ZUNhomLOIYgrjy5Au2NAjMgge08Ktu5kRjeb/LoPUpqWmFeTNMGEfUSr0HHmKgC1T6Ey2a6ksVMWBI/H4VKoo5tWhHQZpZEVq/GebCwcD7vfSnBOEpPpft6tNHxd84Zf29gCzh4h3a6J7uFwbDrvGqiXXlr1kSuget7oXO69Ko62XQLJCaq99APi6huRXqG9tOXs5tiEBoa8vgA/yT1OuamaAYjD+wAZZdg7cyMI7C1Lc4AWsP2ZW1avD/GOAhMW2RurxFLWFCyfiSotVR+N4rXUYxk7RsiVLtEWWjuOBwuHn/gImsWa3q4hJpFaOf9yy8OQpEUUsC3FuSV1Pyp/jCB7K4ubnSxX31UPj1YIwQEvm4YsJwe+bY25uHFs0qwXCRTk2S/rcxkHSnYJ7B5Hmr8sokEkXhKE7vcUztmv2+GLfDTqthQt61LxDi2RQlikcX3nZw/b9znklzn+K3Ywewl5Z+vgfcHuYrzjTwOc7njVO3sxhVC6UjYnLwuGshQFJ6AGKvGvoCL5OkX0F66SR7JTnCUnzMfh65EuYv/ETrtB6cjeY4S8fx3joyKmiA8NYB9KcAKL6iDZmAV1PJkOmG/7KYL1+rLzjS7QOlilZLelK6begpnQ8RUBQYmTCdViteJiTdlLzJvrzeciFNhdo7Jq21X1GXCtrDzv1+DHpGybfFsXgPlqZhtwaap7/eSwUjRJTUwAH/4YCZ/SFvIegTUwXIrm/q2DA87C0OY7AHeYspV1FH98Oq7hU0nli7X6zauTVJoPulAoriK2e2G4NhWirYg1SaD+RDrrusVhp3t0H1XyjpsdKxNul5n6
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(39860400002)(346002)(136003)(376002)(396003)(366004)(66476007)(8676002)(66556008)(66446008)(64756008)(99936003)(66946007)(2906002)(2616005)(76116006)(4326008)(91956017)(36756003)(41320700001)(83380400001)(71200400001)(53546011)(5660300002)(6916009)(33656002)(8936002)(6486002)(786003)(478600001)(316002)(86362001)(6506007)(75432002)(186003)(7116003)(38100700002)(122000001)(38070700005)(6512007)(26005)(41300700001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NXMvTW5KNlZ1dXd3M3JORmlDK3RjYWF3UkhuM0J4VjlWVDVvTlRuUHlWcHFj?=
 =?utf-8?B?S0JUeGtzaFNGMkJ2SmFnYWhYaDl5Nm1GOFRjVFAyalhXU1hYcXlSbjF4RDdI?=
 =?utf-8?B?SkxBdHh3VWJySExORTA0UDVrcmhsRWhnbjREVGpSaWkzTHl4SWJlYVhLU08y?=
 =?utf-8?B?K3RmMFYxUWNpR2dOUnJsdVIwZHppTHNaOFhZS1QreXNVeU5VOTNXR3h1QWc2?=
 =?utf-8?B?YThrTkJCdUVXelBqSkxMYkVJY01OckNORGh5RC9yRTA2L1V4UW5FN3QzUVhT?=
 =?utf-8?B?R3RGUzJLWFpCLzhsT29zYUtOdWFjSGFKdnlJWVQzVUNWckxZNGQ4TEM0OUY4?=
 =?utf-8?B?V1V1MTRyWmRoMTA4dFZRbFRiNmwwT2Z0eitTUEk2M3IzNEdqNGx4WHRjekN2?=
 =?utf-8?B?cEY5cHV0Rmhhc3JjSU1OQkI3QnZJTE9qUXk2RVlHcjJHdmY2NzljOExIYjMy?=
 =?utf-8?B?RjFqTDBGU3VkdHkvcHJPTEptNWFSalZxU0dCcjV0Q0czM3ZHR1F6L0JDUUNj?=
 =?utf-8?B?UGliMjZzS0t4UU5MT2NEdThkU05LVjBqTFdFM3JxY3VIeVpsTnhvZVU1NUJX?=
 =?utf-8?B?T2JxUmFibUtYYzZ6TlluaVN6TkJrNW96aHEwT1JzVFA1ZVBNWktuN3VVaTRp?=
 =?utf-8?B?eDhOVys3Z3BiRzNINHJDQVc3R3lMVWh2d3V0NHZQakUyL3VxVXNhOGJRVTlj?=
 =?utf-8?B?Rml2T2xhN0dvUEQxcnhTcUZTVmJRa0FBYnNwZXBPRGFTcmwxWnJKNVZmL0hK?=
 =?utf-8?B?cG1Ra0IvcEdUWDBEcDF0OU5FVTUxWldtZGF0VGIxNEZsaDdYTGRzL2RyNjN4?=
 =?utf-8?B?ZSs5UmtPamhOYjlVcnIzOStpNDZZOE1VQzlkOE9wTHQ0cVdsMG9XSm1VYUp0?=
 =?utf-8?B?L29UbEN3MXlaYUttMnJZK0l5UExrcUd1S2kyL3FtQzJGaTNZVVNsTDJCUjJx?=
 =?utf-8?B?T0RnY011WklYbWNnTWNaWDJFczNhdU5USWQrM01PK3ByVXVxSmZOUjYyYjhq?=
 =?utf-8?B?VHRMYTk1T1RJOFZ2UkZiMHNSeUcxbUxENm1MRjdWRHVlYnFSSE5ZMDE4VUtB?=
 =?utf-8?B?UisxRnJDbUNkK3hnY0kvTG5YVkdoS05JZjVVWnN3d1QybVlESjVNdTZ5YXVp?=
 =?utf-8?B?TTZDM2wyM1c5Sm9nbHh6TWhYakkzK2FuNTZwVjBNSFVNSzRrbE9RQWZ0bjNX?=
 =?utf-8?B?TnFjZGxRQ1d5TWFuOVdGTlljeDhudzJJZ2kxaTNleGVFUHBGRWd5ME9SOHhR?=
 =?utf-8?B?TitOME9aZEIxZWt4SUpSaHNDWDE3Z0VYbkQ5UENoVUlvVzV1blZwdklFMUlM?=
 =?utf-8?B?c29sU0FRdWhVUXkzSE9WSTNoZ1FERVA5a2RTRkdlcW9QZnd3a04yVHlONU94?=
 =?utf-8?B?N3RXMC81N2xxejM2Y2tHdTJobVg0WU9BVUxQUklIUTBFWU5RbWtwWDB3d1Yw?=
 =?utf-8?B?eWhkNnhqUEpOYWpCZ2M2R1E4ODdNMGNUa1dsMEJER3FId1Bmb2xNVG5yNjlm?=
 =?utf-8?B?OTlUazk2a0J1L2EyOFJuZEI2VWViWXp4R1N3NVVLVllzbjluQlBzcmR1Q2Z1?=
 =?utf-8?B?RnptZ1puaE9NVFRnRzJ0ek5xRGZ3N2pzRjRkRk1qUUUzVFBId1Y0N242d0Zw?=
 =?utf-8?B?ekhJdC8rNDNMeXBVanEzKzlsMnJmZXUwV1Z3Q3RpeEhHSWV2VTFpVTVFYXNW?=
 =?utf-8?B?dE9wdSs4YXIyU1MzSVZpVTlVSnBkYkpSUit5aHU5MVdSQUNIdVhpSDFKTWtD?=
 =?utf-8?B?bG1QU0dxaEFTUk52R0hHY0hDZGhKYTN2R1JrcE5zYTZXR1ltYUtpU1dCeEFn?=
 =?utf-8?B?elRORW0ycWZIRWpzays4SVdFck9hZkdsaXhXNUFNTzJwWDhPZzdTVUhBUnhW?=
 =?utf-8?B?Q1Q4YTk1TDkzeTlHVGtwQlI0Vk8wcTA2eGtNbDRIUTFiSlk5ZmxwdmgxZWdL?=
 =?utf-8?B?U1ROWmZ5SGhiMEJVZGhrdk13bDlBWXRxd2oySVo2S0xCOUtYUmxjQ0Z4OG1k?=
 =?utf-8?B?dmVhdUJoVDdQTmhZb0ZVYjlRUXV3UmlBVFhwTTNXQ2pKUVBQYnF1NDJhUStn?=
 =?utf-8?B?OWxpZ3I2bTdIMFozR1Q0YkQzNG0raVdRZ1JJWjdZZSsrME8zOWo0aVRQZEtU?=
 =?utf-8?Q?bbdw=3D?=
Content-Type: multipart/signed;
	boundary="Apple-Mail=_FE49E218-7AE9-4269-BBD7-2FC455520586";
	protocol="application/pkcs7-signature";
	micalg=sha-256
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: DS7PR01MB7712.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5fb8ef9a-c02e-4190-a2c7-08da757051e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2022 16:50:49.6497
 (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: mupCoaKfbxgxNKLcRAdUx55gp9Jcke0YhqbOQMtWK6w0RYHNdYamx0acXC9tNO8i
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR01MB6473
X-OriginatorOrg: mit.edu
X-Rspamd-Queue-Id: 4LydDP5pYxz3xl3
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mit.edu header.s=outgoing header.b=dBmbPTV8;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}");
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.15 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [-6.78 / 15.00];
	SIGNED_SMIME(-2.00)[];
	DWL_DNSWL_LOW(-1.00)[mit.edu:dkim];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.98)[-0.984];
	DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[18.9.28.15:from];
	R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.56.176:received];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[mit.edu:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_SEVEN(0.00)[7]
X-ThisMailContainsUnwantedMimeParts: N

--Apple-Mail=_FE49E218-7AE9-4269-BBD7-2FC455520586
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Aug 3, 2022, at 12:28 , Andrew Turner  wrote:
>=20
>=20
>> On 31 Jul 2022, at 17:55, John F Carr  wrote:
>>=20
>> My OverDrive 1000 (Cortex A57) running CURRENT just crashed with the =
unhelpful message "panic: Unhandled System Error".  Is there any way to =
get better information?  The ESR value bf000000 translates to "system =
error with implementation-defined code 0" so that's not much use.  The =
instruction associated with the interrupt can't fault ("subs w22, w22, =
#0x1") so it must be an asynchronous error.  On other systems I've seen =
bits you can test or registers you can read to get details.
>=20
> By my reading of the Cortex-A57 documentation [1] I think the ESR =
value shows the exception can be attributed to the current core, is =
containable to a given code sequence, and is a decode error.
>=20
> It=E2=80=99s likely due to msk_phy_readreg accessing the phy, but it =
doesn=E2=80=99t respond quickly enough.
>=20
> Does an older kernel boot? If so can you try bisecting to find which =
commit caused the panic.

Thanks, I missed that bit of documentation.

The same kernel worked after reboot with the same networking =
configuration.  The theory of a slow response from an I/O device sounds =
good.

Is there an easy way to trigger a system error to test error handling =
code?  For example, I once debugged a machine check handler (IBM lingo) =
by using a control/debug register that could intentionally write bad ECC =
to RAM.



--Apple-Mail=_FE49E218-7AE9-4269-BBD7-2FC455520586
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA7sw
ggO3MIIDIKADAgECAhEAllRUaZWy44T/aVEsqzSrczANBgkqhkiG9w0BAQsFADBsMQswCQYDVQQG
EwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0
aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMB4XDTIyMDcwNTE2NTQ0
NVoXDTIzMDczMDE2NTQ0NVowgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQL
EwxDbGllbnQgQ0EgdjExFDASBgNVBAMTC0pvaG4gRiBDYXJyMRowGAYJKoZIhvcNAQkBFgtqZmNA
TUlULkVEVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Ka5+9REw1B9JXThajulqv
SjDFK1pNpGB2nljRQy5iTTTVddq/4+s+uC88etHWbMquFd/i9sCIxLHgDFhlGZRhcORhzDfwIxLA
P8q4KMsAPeXO2kgh86pGH+DEsUPEbEtdkN2cnT9kt+BE2cPCOiqAR+YBWZX3ebDLc4+eWiPfErg7
WEr4XcIraxxxtLuUR6sVbN7nG7WCtBCalzbAxryy5GmWZ1z4OawzylJVb+qLKeMi3XN+H/d+shdm
6PmyqGeCu7jpN3+g/eAuWk/PWhIUhDwABK9JGWW2+xWCtDHxutzRt8vDMZK2GaE6MzpBpTFR1P1o
IdodVtrHGtVnKq0CAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBQCc+0gYnBj
WRsOZgQ78pmO+ojOaDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRj
bGllbnQuY3JsMA0GCSqGSIb3DQEBCwUAA4GBAAm/9fT9H4n5ks4q9cGE5FWIwAQmEGre6gMVU+VL
V4p2Qfd4eZki0uKg+Vi6BWeHL2GMQQpnpjgm1Xx6q7oSruPTkkrs75X7oTW5Nf550U5qEKXSqboK
y+6dkw8fNvNci0tYs0j+Ev6JPU4VgDK/NSWtRFrndFzLI2SgJ6k+Ess4MYIDRjCCA0ICAQEwgYEw
bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1
c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZU
VGmVsuOE/2lRLKs0q3MwDQYJYIZIAWUDBAIBBQCgggGVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgwMzE2NTA0N1owLwYJKoZIhvcNAQkEMSIEIPlVV/FxpdBE
8LHlfmamsV6rR927qVje2HLXyTIG0KfiMIGSBgkrBgEEAYI3EAQxgYQwgYEwbDELMAkGA1UEBhMC
VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0
dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZUVGmVsuOE/2lRLKs0
q3MwgZQGCyqGSIb3DQEJEAILMYGEoIGBMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo
dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw
EwYDVQQLEwxDbGllbnQgQ0EgdjECEQCWVFRplbLjhP9pUSyrNKtzMA0GCSqGSIb3DQEBCwUABIIB
AJ4u+JBmV57HEOV3vDZ+IhfpjNhoU8D8GnJ4Evq1bhQmLhskXTODxotWRMcWlT0L5YItBGp+LaIy
DTXSSEVF79/0Oua98WOctivDu3O+yQNCM+yI+RZGaqhgWbwE8YgGq/uwvDRB35O6ugNW8zf+fY+G
TY1UBFct2gdWTMyZ3nR1tP136izrtgSsDNSw0jUteP+7AgUq4LmRDMA6OIu2q9cGXnz7pHgD984Z
apKdCf5TlG1IrSv/fWLlEsAssl0OSwxwPqTWWwOYZ4yLiiXDNdUviroXp44GxP52oust+nIFdPxo
zSH6hfetiyp/HSrJrU3fw7kS9Tjg9h5olQKF5YsAAAAAAAA=

--Apple-Mail=_FE49E218-7AE9-4269-BBD7-2FC455520586--

From nobody Fri Aug  5 07:31:04 2022
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 4Lzchm5yhlz4Y7qD
	for ; Fri,  5 Aug 2022 07:31:04 +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 4Lzchm4JnJz3kcQ
	for ; Fri,  5 Aug 2022 07:31:04 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4Lzchm3MzJzlhC
	for ; Fri,  5 Aug 2022 07:31:04 +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 2757V4Jp064097
	for ; Fri, 5 Aug 2022 07:31:04 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2757V4eI064096
	for freebsd-arm@FreeBSD.org; Fri, 5 Aug 2022 07:31:04 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 265639] PF panic on armv7/BBB with 13.1-R
Date: Fri, 05 Aug 2022 07:31:04 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: phk@FreeBSD.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659684664;
	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=hfabGM0bXB2Nk/7USLOmmHIvvc7HAGOkgnVenwXYUiY=;
	b=auR2RQKQCogqjvwfbFKbkHsYB4LnEQjFQI4G92m0uY1FrgCblvaUnPoIZ5pGLa0DNIimN2
	OGTzsz8gPpnuv2EQVk4o0/SRaps5T0ckLinHrexsOFv8HA9aW/OTiWhwGd6Mm85PmIuM1u
	sLFkW+mt3dja8f1ik2TY201R9aZWeEKzWVVB1zBAn52TzmqlRYvWgi9GVKMkBpLjwrWS2G
	1T81/2twFIO5M1q4P6CUL0AufpQWMWqP7oKKzmi+qxxKmgP3brn9/+RCu8ZLGSJ1XYNhPd
	ClUKGZ4muHJRLCkjpxWjbvujqewrx2SZynteb+nJjaU8hSAHPzxs4roy5VkO2Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659684664; a=rsa-sha256; cv=none;
	b=r+vqgRBc6hYHMFdgCZOF1Ux3Xlcgr5MT0xpxPzPh61V4B0ki5zLq8oqV5QAc3KeRPecrNe
	zDzls7xeEj5CYqIUptA4CVYM9ALzZ+RZDS48xZFcSRY+1W8HDvWqxz39Hb57vR4fZOEtHP
	L9NlRcZWjsooyif/Nha++vXS9fuUCI84ts7iml3d9mNVQ37/3egsbM2tU7V7GedgKUqsEv
	7ejQweCLvMWjcmcVzoRP9cDDKkblUl4Pz6E8q74wV5lPq46WnwrfH45yYMqO16NflsoMeH
	HB1zqUxZDJqTswyI6Mbq6dySUE5N4AoWZkb4KnjgwOw3HIZiKXPdAEvGwx+XgA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265639

            Bug ID: 265639
           Summary: PF panic on armv7/BBB with 13.1-R
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: phk@FreeBSD.org

Beagle-Bone-Black, 13-1 GENERICSD release image panics in PF:

    login: Fatal kernel mode data abort: 'Alignment Fault' on read
    trapframe: 0xd71a7930
    FSR=3D00000001, FAR=3Dc3328224, spsr=3D60000013
    r0 =3Dd71a7a48, r1 =3D27244242, r2 =3Dbf798103, r3 =3Dc3328224
    r4 =3Dd1494200, r5 =3Dd14db000, r6 =3D27244265, r7 =3D00000000
    r8 =3Dc092c92c, r9 =3Dd71a7b68, r10=3D00000001, r11=3Dd71a79d8
    r12=3Dd7297918, ssp=3Dd71a79c0, slr=3Dd724a5e8, pc =3Dd7282800

    panic: Fatal abort
    cpuid =3D 0
    time =3D 1659683836
    KDB: stack backtrace:
    #0 0xc0355b70 at kdb_backtrace+0x48
    #1 0xc02fcb50 at vpanic+0x170
    #2 0xc02fc9e0 at vpanic+0
    #3 0xc061bc14 at abort_align+0
    #4 0xc061bc70 at abort_align+0x5c
    #5 0xc061b8e4 at abort_handler+0x480
    #6 0xc05fac68 at exception_exit+0
    #7 0xd7282800 at pf_syncookie_validate+0x3c
    #8 0xd724a5e8 at $a.110+0x20
    #9 0xd726c868 at $a.166+0x34
    #10 0xc0441f68 at pfil_run_hooks+0xa0
    #11 0xc046e808 at ip_input+0x694
    #12 0xc0440c70 at netisr_dispatch_src+0xf8
    #13 0xc043863c at ether_demux+0x1a4
    #14 0xc0439cd0 at ether_nh_input+0x480
    #15 0xc0440c70 at netisr_dispatch_src+0xf8
    #16 0xc0438b08 at ether_input+0x50
    #17 0xc0cfbee4 at $a.6+0x5a0

pf.conf available on request

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Aug  7 04:10:23 2022
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 4M0m8P3YTmz4YqBZ
	for ; Sun,  7 Aug 2022 04:10:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4M0m8N1KnGz3fZH
	for ; Sun,  7 Aug 2022 04:10:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659845426; bh=bmHbW3sPeRBpfU9vA8OI06SuzWfFIdasijJ3IgsIQEU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=YFH2nSXVWl5f8wEuJ7QdcM1AxGEnJPxVXgZiN3jGyuOQc+A0+roKRLRmZEiIqHzIJWN4Mfzqm930m2L/ei/s5H6iqUBywtXlNC60K7d1mvPqlHUW/2wedqAOjoxOZSpDn8htEd8TB7/ZNK87ChQ8yrsUOkFk7Yrvl2eChOfemLoyC1v8ZA/RTFWFHuUA7pv1TSS0XQGpGhGmHvxbtEkpRpAEHnKADXJIoSWWj1HasTGfcya2lzU31jdnu+As10sspUV1IUcw4y0/3aJhan72Z4rQiqelg4rSYK4Z07G2P9WIhwSq+Ayl2jTYVC1fA0Ve2D0IoRVzm9O6hJxyg4JRjg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659845426; bh=sC+pju6YII/xT4ifjD4XEAjlfIlUDD7pxe3H+4+ew6/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QSBUQrCFqKUDoDXEYpPRbNfWJh+yzV+EjDGIkbw3B+WShdzHkXru9dJG8dt4AfXURlBkh396S+B2dMheIR61oLAYFrCQO32bcuDso6NGWsd3WQ+tg1RTLvpKgQDghpWOfyjl6QX69O+gzr6k7X7NXx4FU+RMaFffEHINVpkWja3mRsoAJ3aeObEBUJ7eTfjOYVGsGF9czMcqoLwk1Kl7IZbNiiOsGm9SB2VS/zOT0czFzN0qYShtSaVOUWWaQ/L7nvrBRBR41HNOYgh7VuN0auuU77LztPMh/e9dfQzowLpfxeju4nzIIrhemtmNOkvj/kMI9P2Dms4mxcvpV/YxcA==
X-YMail-OSG: l23YtJkVM1lUkfPnWEeepVheQwpQR37QgsJmsbj8VEMHHCinckMQazxEMkTQOdB
 YanFy.jNq.A_y6oFdTSN1SpLMxbN9C4_rKgkmLhlj3..RYBmJklvdWU1GEnzAaJGzmLIsGUSe9dM
 QMH5KN_A9JD9B1YM0_n.mkedJGtgCHZuMZrui9n.f3nDa8Kv_mxwAS62D4wNjVQ6QqfKlSvQHffc
 S3pQ1qH60avUhw2cxdVOHH8li76G2RooYW8n86CWsEBbyn1mrZqZWOHVHcYPMswQvBVdqaRCr521
 9VON0gdlkn2INNbfT658PKqvVNgHHz2nXjuyiSENXrAk3iWMgq7ooLj7_bmLFV7eOCOHtvQ8bJ4Q
 Ynf4SrYrM4p3AgZz4P8tHKKUdi5uVeK4483wevc0OiNC_Zfl4fDJtnxcIqa41QIA217DsFRKIx1y
 Mosm90mIUIbTxBOTSZ2OcwMO1TZoWNFHQkSjnYsecjWybIw3Xs990JuOjCYzc3n1riSasjywp2LD
 SnwPC5hS3lc57QHEvIuZ4CfrN8mEuKeHDjvQftsI6r4qwspOKOJUmYkQOeMC.XofZ07QAFOw9LSB
 I9WVkBd8kFtaSihVC8ytD9qtDEVrYma7QVPUgT1_.Mw6Oafc.xs_oqH.n8KYQ.v5xYDO9c8RM8ge
 IyEt2OHekJS10lioaJeh.GyHlkR4AYg4Hg3ZVu0jlDMRQqM9azYIW1ctIkSA.KstZzW0CmFqLfUR
 7YOMYQooPSnPWPskdQZ1wJzQ5lCEznvawMpIOlRu_0MCM1JkbrmV2kIHdJPoUJ7oc3WMKxmmakxA
 VIc8fU1IEMuCKZPFVZF5MOzdeXus55yRD3tJqUFFrjST3cFeGHyTcib2tD9.TSDAPZBOMPPaiXGF
 vGGztEdj2Ay6x8GfojtMYagNDZYdnyn4HtMO9cGv7aLJkqB.Le9HIiAeyj8rVLFVCfntawFhZN6a
 1XqjkE.L2U5yz2PsAEVWAaAVLlpQNUsoccOEZ72qRCoT6NOYB_Kfjq.HLCKTGohOOytvlu33WUEc
 YlH10Kvez2YhCh_3Ay4UDMq7vkBWQ_VfKfvmkrw581lj5rY9A2jGvobhXaZuQop5hA2AxV2EQmor
 ZbRNLKV9bi29HilYGfu2m8yS65kEvA2wUCACjjNcv7RTqTSnpkCBVkFTQmQ9.qWhLAj0_I1aOmFe
 0FeI1W5U24Y04mlcJ_NgqavLGVxzenk1uFkRbP_spDHS0yN8NKzGQB0tKKI38R84YcMl3n4DcVez
 ADEvXkIiFWbDHRg7nZ1brnByJ0CwQ7JRZNF9eoMr._U9xw11u3JWMEtzsTqSsQv26UPC1KCTz.gS
 adqdZome7pw1L_OuVdwbgWrExR2TMDDX8GifoAF8ZE_uIKpDWFUflNw5fc1ParVo0OfCwZOe.SZs
 qX9Vzn5n_ycaYUfvrteIVC2u7bvz0fYmiktAg3m_AAjsEGk6cg57eHK5qwfBW8kfdLROvU3WYaMI
 Rzjrc3cx00jZZHQja9qux3VC7abUMVCSj_0EeW7QAoTpU8adxDewgYBpd7Jqhil.HRTpGuW7Esyn
 9eo8kZJruBR5RP_px_8o1cw_5xAZj9OucFFfAELA8.gE1msoeA25rptpETrX_3unxh5zuVWdR4se
 duHpGK41Ic5cXUy8QQnjOKd3eu0XApsSnBZwGJ56DQng36Zo0anUHfRMNgfjfSWsflDYVCQe6eD0
 aSLCprLSEmNUpTZdGkA1CQLR.6g0lK0QyI1klp3zXahQmVQuRwyF2BbaZ3hX4SX6L3jI1CEd6qHB
 y89xBXw4z5pB6ath8kyl73fQnsF0quJ87EvqrSMqE9i1XMPoMWxUEk709dsY580uDKThD_VhyO3B
 h9jp5TNV.8phTZdJ.st43sBQwL1KkVmIJfGjhfyjhd.YwIILlxVzzgi9E_fHkBEPCVdNPeg0hGWB
 dOYolltSirxloZEdrR.Pon5zIPCfCCPsSwgA53qf3o2_f9Q_iRLVVcoQE7oe6UR3bOXBlTGxuebG
 dCRL.67oFmBEBcWQSU7vheGUf9CekbaevrZKFiv6Hj5_FCbvCKkB8ZjA_rknPChoZvWPrYH.8jxD
 0KaPk9fwH5EjzVWPT81AtonAsheOScNr7Vo2lNm7TMsfNcSGRx3bzghR2YKrIXoUn2I8qJJnlIwE
 TKKH7jJKn50TqtLkZbto5xo4oYR7T4npgpwZG1QMcOEzm4iLXOUxOiy3vwfvUTjHs9usHqEuYAlC
 wPtdDXcrNT6X8EVgzJHF1VgG0OIkDjS_gECyoRLiZjtZo5nYPFcltM8Maema4.XkFG6BRGMoiFgH
 ZRTWQcfB8UX0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 04:10:26 +0000
Received: by hermes--production-gq1-686964ccb6-5tbjz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef41e137f23b21105f6b2a1a702bd2ff;
          Sun, 07 Aug 2022 04:10:24 +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 14.0 \(3654.120.0.1.13\))
Subject: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
Message-Id: 
Date: Sat, 6 Aug 2022 21:10:23 -0700
Cc: Ed Maste ,
 FreeBSD Hackers ,
 freebsd-arm 
To: Glen Barber ,
 Warner Losh ,
 "Rodney W. Grimes" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4M0m8N1KnGz3fZH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=YFH2nSXV;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_HAM_MEDIUM(-0.94)[-0.941];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

The oddities look like indicated below.

# mdconfig -u md1 -f =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
# gpart show
. . .

=3D>      63  10485697  md1  MBR  (5.0G)
        63      1985       - free -  (993K)
      2048    102400    1  fat32lba  [active]  (50M)
    104448  10381312    2  freebsd  (5.0G)

=3D>       0  10381312  md1s2  BSD  (5.0G)
         0  10381312      1  freebsd-ufs  (5.0G)

=3D>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
         0  10381312                       1  freebsd-ufs  (5.0G)

=3D>       0  10381312  ufs/rootfs  BSD  (5.0G)
         0  10381312           1  freebsd-ufs  (5.0G)

So: ufs/rootfs apparently identifies the BSD instead of the
freebsd-ufs . Same for the ufsid/* . This leads to:

# gpart show -p=20
. . .

=3D>      63  10485697    md1  MBR  (5.0G)
        63      1985         - free -  (993K)
      2048    102400  md1s1  fat32lba  [active]  (50M)
    104448  10381312  md1s2  freebsd  (5.0G)

=3D>       0  10381312   md1s2  BSD  (5.0G)
         0  10381312  md1s2a  freebsd-ufs  (5.0G)

=3D>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
         0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)

=3D>       0  10381312   ufs/rootfs  BSD  (5.0G)
         0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)

freebsd-ufs has the unexpected label: ufs/rootfsa

# ls -Tld /dev/ufs/*
crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 /dev/ufs/rootfs
crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 /dev/ufs/rootfsa

Things were actually set up for ufs/rootfs naming as the
identification of the freebsd-ufs content, per the
release/tools/arm.subr commands ( from last month's
main-n256584-5bc926af9fd1 ):

        if [ "${PART_SCHEME}" =3D "MBR" ]; then
                chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s =
${FAT_SIZE} ${mddev}
                chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
                chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F =
${FAT_TYPE} /dev/${mddev}s1
                chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
                chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
                chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
                chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
        fi

Note that the newfs command references /dev/${mddev}s2a instead
of /dev/${mddev}s2 but the rootfs label ends up referencing
/dev/${mddev}s2 .

Is having "0 10381312" for the md*s2 and for the md*s2a a
fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
to be moved to a different (non-zero) offset inside BSD?

Or is this a different kind of bug?

I'll not repeat the kinds of explorations that I reported last
week unless someone wants to request something.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Aug  7 08:58:06 2022
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 4M0tY14DXTz4YG4P
	for ; Sun,  7 Aug 2022 08:58:45 +0000 (UTC)
	(envelope-from marietto2008@gmail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4M0tY04wmvz43YB
	for ; Sun,  7 Aug 2022 08:58:44 +0000 (UTC)
	(envelope-from marietto2008@gmail.com)
Received: by mail-ej1-x629.google.com with SMTP id k26so11747058ejx.5
        for ; Sun, 07 Aug 2022 01:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc;
        bh=smg2K2Mh8grZ+gC+431QHa/km5leY+woI77a0jsk0dU=;
        b=LUnizFaeOogrTjaUyUpP9/buIkfWrZJn9VhcbsAUlBSAcBL0/SceS65po/Y+pxIGsj
         DcSAkXtJOnB2eR5B7PUS3XyoyK5UhhSozgDfvFVicg6xincuQCY3g8gKCYf6qGsUY+jg
         cpe9htgEdwMQwrv6qWiT/KOcIpJ+x9TiP5AqTRe6APhvF2HMt3nDNkQVteG35qerxsZs
         h6Q3WZ3QHIZXtUOjpmuTwhV9+jNkugWcNo3nly1mS9d6/uGiRg2HjfL54Nm2Xn1Sp8ay
         XZzyBcjZNTJfv6s4NNK2XWW0qiY9EwCpvPbiUPmNR0p/PMD0K+DxxnjoD6TObn3aK6Qb
         sRkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc;
        bh=smg2K2Mh8grZ+gC+431QHa/km5leY+woI77a0jsk0dU=;
        b=qkt6HoEGpqUvd8Q+0UbXHcVvHuqeYKzXCC4OjeUzO8DiuF7BOBMi78xpaTlIG5LS+F
         8HP2HuWEFC2TijZOFPBOgdBg85/IYNnVyDW6hgAVeZGhNFLnxpLzaf+2niOIBcTMnr6H
         56Qi+35uwgUYLX77xYnwYO9hv+KnvdiZk14LWmtxgjJsUKqYg8VHlfjcjbGYLzjIBWWS
         xeCSU9g77zdVfMbUNh0ySNQ9NWy1IMf2klvVln++unaTwtpmu8jAL2or4x72dr5aBDV6
         evTorzgfZvmXN2afqR9MCwxlGxRn5GsbpiPoevFUMozyN92DL4jee9mzRHBm5snL4vxd
         gr6w==
X-Gm-Message-State: ACgBeo16i8N80uO5lATt4ie0UZaTKBLSTbqVXZcoDc6gCb+CcEmdNB0I
	B0mMzlJV0Bg7dyHDSqvRTUVuV3mLSdVCowfgxcapNlYpHOolWw==
X-Google-Smtp-Source: AA6agR4zpshRqvGIylHaYZ9SsWTHSH7Vi3h3HoRkV8zdY+hR2+koC31LE6/gmVQiyZ8u1g04eZmHcIZFB/i8Hm7quWQ=
X-Received: by 2002:a17:907:b19:b0:730:b0d8:750 with SMTP id
 h25-20020a1709070b1900b00730b0d80750mr10432759ejl.46.1659862722621; Sun, 07
 Aug 2022 01:58:42 -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
From: Mario Marietto 
Date: Sun, 7 Aug 2022 10:58:06 +0200
Message-ID: 
Subject: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f5364705e5a2e7f8"
X-Rspamd-Queue-Id: 4M0tY04wmvz43YB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=LUnizFae;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=marietto2008@gmail.com
X-Spamd-Result: default: False [-3.96 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_MEDIUM(-0.97)[-0.972];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f5364705e5a2e7f8
Content-Type: text/plain; charset="UTF-8"

Hello.

A lot of years ago,I bought the cool notebook "Samsung Chromebook "SNOW"
model XE303C12" where it seems that only ChromeOS and Linux can be
installed. The specs are the following ones :


   - CPU: Samsung Exynos 5 Dual (5250)
   
   (Cortex A15; 1.7GHz dual core cpu)
   - GPU: ARM Mali-T604
   
   (Quad Core)
      - 1366x768 screen & HDMI external connector
   - RAM: 2 GiB DDR3
      - The memory is not upgradable as it is soldered directly to the board
   - Disk: 16 GiB SSD (connected to eMMC)
      - SD & USB expansion slots
   - WiFi: 802.11 a/b/g/n
      - USB slot can handle Ethernet dongle


I'm trying to look on Internet to understand if I can install FreeBSD
without having all the troubles explained here :

https://wiki.freebsd.org/arm/Chromebook

Which options do I have to have a fully working FreeBSD system on that
machine ? If it can't be installed natively,maybe these two options are
feasible ? :

1) to virtualize FreeBSD using qemu and kvm
2) to install FreeBSD using the crouton chroot method ?

What else ? What do you think ? Maybe you know some specific tutorial
that's more updated and that can allow me to install freeBSD on that
machine making almost everything work as expected.

-- 
Mario.

--000000000000f5364705e5a2e7f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello.


A lot of years ago,I bought the cool notebook "Samsung=20
Chromebook "SNOW" model XE303C12" where it seems that only C=
hromeOS and=20
Linux can be installed. The specs are the following ones :


			
  • CPU: Samsung =
Exynos 5 Dual (5250) (Cortex A15; 1.7GHz dual core cpu)
  • GPU: ARM Mali-T604 (Quad Core)
    • 1366x768 sc=
reen & HDMI external connector
  • RAM: 2 GiB DDR3
      The memory is not upgradable as it is soldered directly to the board<=
/ul>
    • Disk: 16 GiB SSD (connected to eMMC)
      • SD & USB expan=
sion slots
    • WiFi: 802.11 a/b/g/n
      • USB slot can handl=
e Ethernet dongle

    
		
I'm trying to look on Internet to understand if I ca=
n install FreeBSD without having all the troubles explained here :


Which option=
s do I have to have a fully working FreeBSD system on that=20
machine ? If it can't be installed natively,maybe these two options are=
=20
feasible ? :



1) to virtualize FreeBSD using qemu and kvm

2) to install FreeBSD using the crouton chroot method ?



What else ? What do you think ? Maybe you know some specific tutorial=20
that's more updated and that can allow me to install freeBSD on that=20
machine making almost everything work as expected.

-- 
Mario.


--000000000000f5364705e5a2e7f8--

From nobody Sun Aug  7 17:46:32 2022
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 4M16G63Bczz4YXj4
	for ; Sun,  7 Aug 2022 17:46:38 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M16G55KxTz3vWJ
	for ; Sun,  7 Aug 2022 17:46:37 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15])
	by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 277Hk6Rb029698;
	Sun, 7 Aug 2022 13:46:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
	t=1659894396; bh=nGR7gjSJawHwQNhf8k2wPdMBg1GG7nzuQPMilcg9He0=;
	h=From:To:CC:Subject:Date:References:In-Reply-To;
	b=YsUPLThA3AlaUs1kRzov1G3AYYPBQtlSD4sUFhrUidtDjOJW/R4Eax/wN18yQIfSz
	 InsMuWye7eejlprMDS6amz+YLYKgbYj5FDAUGXSz8ZvCCONA3hLhG8BZCjwN6X510C
	 9oEax9eCMTk5/GtS1fN65VPa8ZWfUtkkhSj4ZiLGXfCOsBFnf4r+TKwts8pbjSOvGb
	 N3XBPeFuno2NKYFwIPj3nTu0oNubbUHczJxlDCk8F1Y/GaEq1IUmpyU0GVAYzuv28y
	 IINQgj/BhAWKrtIKww/ifTFMNGuGHFRGpdsRpl4TGlV/9Y8N2x9gROrkpPUvhKzNJO
	 F7bHkS7pYQPPQ==
Received: from w92exhyb1.exchange.mit.edu (18.7.71.12) by
 w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id
 15.0.1497.36; Sun, 7 Aug 2022 13:46:06 -0400
Received: from oc11exhyb2.exchange.mit.edu (18.9.1.98) by
 w92exhyb1.exchange.mit.edu (18.7.71.12) with Microsoft SMTP Server (TLS) id
 15.0.1497.36; Sun, 7 Aug 2022 13:46:35 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174)
 by oc11exhyb2.exchange.mit.edu (18.9.1.98) with Microsoft SMTP Server (TLS)
 id 15.0.1497.36 via Frontend Transport; Sun, 7 Aug 2022 13:46:34 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=LFqFi2NWQB3opB98anU4Ov7EhBwiX0CQ24ZooNMQB346VMBrPsjzamKE5nj7dt4hWH7OzRCCN5GiuxDAMO+tzOQp2BcMYcsX1O4Pju9v1RwMSnrKcc/H+kRDRkTlIfd53P0J5mYfjTuGpC98k72FUputKXTQ/WnYx4X+3pz0gqTb/GM/9pnvd0hHys/1DzDNYApq3W1JoE1pQAEg3w6a+gQyiJGhETZnShrEt90A2kTlow4xni4CzS/tH3jgaZSLCUPtI9j5Hp8AjPYX1OvyvpIoFnxYzeJA7xhVRDUIYexPhdj9pk/vpn2VRQfl7+gr2SxCCyARD1OYuVz9zuCA7w==
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=eoIRpyKqkq6QN1lDGCYMJ81Yba4OzoOSG6KT/oyXdTI=;
 b=hH8pv5CxQjOOogeHQgqxVGX/g0G10NULOq2pMq5N7OZpvPyqqLxB3+46nBJkdQDANP4ThaaqMrvy0pgPvt6pVKVAiZcLnvgxoPjBSAi9C4ha1rka+QSj/kcKtToGE8/a8q/JBf28BCWzXAqsLYeB4fPd/Mz3SwATf3SIdscs6BV4UoVVbGMcXjKCG6zSlkOx8xn1KWw5wo8DMgMLedpFmhfT7dVV/vCQ6w3f9WeuL3di+fgt208ZGF3pCDNVgPnUmLbGUKX/3F3BKSc9/EYp/qAjX2D9PPjwil8i5fX4Ak7uiPKiVvjfO4nIwjIR9cSQ8TbukCHOtMvniTPfvzRxGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass
 header.d=mit.edu; arc=none
Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by
 BYAPR01MB4808.prod.exchangelabs.com (2603:10b6:a03:85::19) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5504.14; Sun, 7 Aug 2022 17:46:32 +0000
Received: from DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::8847:24fe:3693:dada]) by DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::8847:24fe:3693:dada%9]) with mapi id 15.20.5504.019; Sun, 7 Aug 2022
 17:46:32 +0000
From: John F Carr 
To: Mario Marietto 
CC: "freebsd-arm@freebsd.org" 
Subject: Re: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
Thread-Topic: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
Thread-Index: AQHYqjvunPIA0mly3U6Q9RErBuNK9a2jtsmA
Date: Sun, 7 Aug 2022 17:46:32 +0000
Message-ID: <2C3AB90B-6A82-4C9B-A2B0-E54B093E5083@mit.edu>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 817127b9-677d-48cf-43d9-08da789cc3e7
x-ms-traffictypediagnostic: BYAPR01MB4808:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Zxq+u/hVi0koqSndngzpomKOoHcwfS5G1c4H2ZkYy04EMQbM2gy8i8SsbjlMkER3ne4ICa50NtZ/fFA8QNCUu/T/bZMfK7EltCacquJcYJjdoWBphj10dr5CCOTQ4y1GcDZXKxmaVUGXDzrYfSQApbF7B0FHSTxSK3VxwnknetOpdrwrmEuQkXx3yFLS1CSuyaLNYyK9qsz6hGy5CkPpH3a8bRXjXD+uCDQkBJ8IxJqaViGJTLYW8Ni8qWQsJ4rp4bair8yhmEiEOkbbsUaFcOIfxIB7QJHO+kwpt8EGl+sP//wtlWyh+vKHycgXxGA3JU0XkDZ86vCEfSNelxXHMxzyRQksJbo9dcZh+D0CQsqsyqk+nOOpe4KtIeCm/nWrXQ9Ri+Xaq+FoXAvMgGUPNbA1Zyq1ze/TP+utAnqGX5gNkKfn1PK5zg3wHfdIsGgmDvDEEvDAsGDPRzYOZ5ldKG+W3PiaqKpuzaZ8DSRamk8n4EPzQWDoyxOIlG7AIfy35HdAi4ZW0pwyL2OdmTVEFAkYAqvb9b36IYXeoC32EpysE4VEdEMZrUt4JLGLWY9rTRNDtZZpn0BvysteVQTrD8XTnllKAD0UFg5yDKhP2T/WbpHRVsZmxf7UeNlbzZagztC9P2XgSsePC3xiCwMyLip4YzSGjGhq0ch23tU0hi1NDVau1ZpnjMQwi0qwcBiWQ8xU4XLET4GYw74BvjKM9n451ET9O97vTq+PFR3OrbQ6IijZ9JHjyQ89jYapCjFQtsM9yrmw2ANgCRTdg8toDtRRnhPhCLQx5uumyfKY8zq/jk6QF+gK/yO/7VIFJHj1O6URRQbDng8TXDcdgsnAsw==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(136003)(39850400004)(376002)(346002)(396003)(86362001)(38070700005)(2616005)(33656002)(66574015)(99936003)(41320700001)(186003)(6506007)(53546011)(75432002)(2906002)(6512007)(26005)(38100700002)(122000001)(83380400001)(316002)(786003)(4326008)(8936002)(8676002)(36756003)(71200400001)(66446008)(76116006)(66946007)(66556008)(66476007)(64756008)(91956017)(41300700001)(478600001)(6486002)(5660300002)(966005)(6916009);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Yjg3Y3Y1MDJOMWU1SXpILytzeVh5Vk9DbTM0SXdPa3JWbU1FTjZNekxhL1FF?=
 =?utf-8?B?Rm9nOHVQWFBJQWJ0MHNZdnpTb1AvbmhISWQvRnJpand6YXB4d2dCR3g5dFFj?=
 =?utf-8?B?b1BMcHkyR3FwcTdOV3NUSlVna0xCYkVGT0FWVTE2SUEvTWRsanFOWk1BUzVP?=
 =?utf-8?B?RjBZSmhRQ2xQYm1YRkJ1cGZBV0dlb2ozMlNUZnVYcGpMS1hZU0FTaTJ5NThV?=
 =?utf-8?B?YzNaK2tMTWFpYUppcE5kR3pxQWdjWVA2a0w4UGNoQ1o2elc2cmNhWnA5dUl2?=
 =?utf-8?B?SWY5ZnpMRVJHaXJJZVBEOEppaW1NRnNGOEs5OUJrZUlXN3c0dFJ1a0M1bVFY?=
 =?utf-8?B?TVNyck1VbTdoMU1ZenVYMFZpNDZJcXJQNlk3dEc0K05pV2xvWDU0SVV2UzZa?=
 =?utf-8?B?Y2RocE9GSzN2YytzU21GbHVTaWk3SmRGK0VCZ0FMT09FcXEyOW1selZKaTVi?=
 =?utf-8?B?ZmtOWUVFR1BJRGR2NXo4ZVJXWnBQc21VLy84MnNJdjNPOWk4RlpqQk5YSmZo?=
 =?utf-8?B?NjcvUGJhTGlEbEU1Umtkc3FoOWcwckhnL3pwTUNFWmlPeHplUDlsUUxtemo5?=
 =?utf-8?B?amc3RkVxeCtRZ1ZGVXk3bGJaSmFMbzJIZzdweW5WT25OQ0JiWjFiaFBoc1Rs?=
 =?utf-8?B?cEdES2RlMjVxTUkybFo4dTR5cXZpQUFGQ1NGVTZvRi9EYzdqSFM1LzhONFBq?=
 =?utf-8?B?UUFWY1BaNzg5bUFnUHduSzF5M3lPZnBoUy91VVFMbEVldVhZRWJyOTZ5S0dM?=
 =?utf-8?B?YnhJU1VoNnZoREU4dlhZSGhLbTEwYjYraGpYaTVKTTV4NGwzMlN5dDVaenMx?=
 =?utf-8?B?cWp2bldxcUhBVkdHK3IxSHNwM0ZaSm9kWVhiSU9tQXA5UmFVa00zNEltNm1o?=
 =?utf-8?B?UW44WHJ2dWpPcE9haktOY2NJT2xlYUVndDIyVXc1MmNoWUxqeU9nK1dYSDFp?=
 =?utf-8?B?dUVrMmpNd2pLYTZRYVM1YkZ6MG5NR3hlUmR3TnJYN3I4eW4wNmJLVWNiMmx2?=
 =?utf-8?B?S01JRm02SWF3ajM3eXJjYlJhVkU1NFRsbjhiUzBaWUllUEpSY3Bzdkt4VlNG?=
 =?utf-8?B?S2xJTDduRk5oNlVGelYxQitSN0xaNTAvOWdhZVV4bHpHeG9iNGdYeXRoK1p3?=
 =?utf-8?B?ME1oWXFKMW01OWF6a1RpRW03VWZicVBIZ1RqQ3RkbGR0ZnhtMmE5dENuWDNY?=
 =?utf-8?B?ZjNOQlk0OXhwYmQxNE9yZU1HT3Ruc2tWSEkxWWI4RjhsTVZCOEwrQndxa0pi?=
 =?utf-8?B?bGY1S2wzdmJqQ2ROTWpyUm5VL3RQbjk3SFdpZkNhNEJpazFBeE9wN1N5ekJB?=
 =?utf-8?B?UXU5V3FNdk16YW1vdks1Qkp4SjREaERKU1lIWERkUlErTDVnUUFabmt1WHRy?=
 =?utf-8?B?QW9nU2dXVThIS2lBd0NlejlrM1VvOW13cmUxUWRqTFNERzNLSjZZTWJvZWwv?=
 =?utf-8?B?VXZtZkEwcFphQXlVcEFqMDMzc1hwWWNKMTNEeTgxaTRlaVZGeldoSjdQUXBv?=
 =?utf-8?B?ekJpblpyU1BpVmtDaUwrbERqRVNoN21IN1ZPaUQyVTY2WVVPeGdWb0l1R0Rn?=
 =?utf-8?B?dDEweWxDc2xOTTN1VDR5S1RMaW9tWHJKNXVvTU00V2tRdDg5aEo4TktQaVc4?=
 =?utf-8?B?ZXBoUEtraDVpMlZHYXl4VzFzbjh6M3I4NnY2amZTSFJzSWhDblF0Z0JnbmU1?=
 =?utf-8?B?TGlZYWJNemdBQzFhUmRRZzNIbDNOZWRXcEZ6YWd4cmRhZGsyNFd4ZERkT0hi?=
 =?utf-8?B?RVI2NTFyL3dIRlFNcXRsRTNSYzVVeTlQdW04THZEcEJSUm8zRzg0OTVsaFVY?=
 =?utf-8?B?dmkwdHk2blozZE1KTDJIQlFCd3VQSEVPQTdiZzBpd1ViMjFHSWJOb01STlpa?=
 =?utf-8?B?RmhURTlFMnZGcGk4YVY5RVE3NERzbTJHd1huNEZZUmNRQUxEWi82c3l5eEZP?=
 =?utf-8?B?cG1JNExNaDlYWU9pME5UUHVGbzY1aUwrTVpnNzZWakpCM3lRSUpsa3VRL3I5?=
 =?utf-8?B?azZCVGlJNFlPRGQ1ci9tMHVrdWFDT3d2SDg3M0xsRWg5MTBRWEIraEtOMDV4?=
 =?utf-8?B?TSsyWGZtMHArVFlqR0YzQmNqeVdTaElFTnhkYm0ybFg5U2JySTc0MnZKbzNh?=
 =?utf-8?Q?OmiM=3D?=
Content-Type: multipart/signed;
	boundary="Apple-Mail=_A892D013-2118-4C01-A3F1-7C6B2D921A69";
	protocol="application/pkcs7-signature";
	micalg=sha-256
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: DS7PR01MB7712.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 817127b9-677d-48cf-43d9-08da789cc3e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2022 17:46:32.2822
 (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: rQNzUgFErejyHJQ+dC2IEgfq/zxpyhkS4Ol0bNiuFuJHPisQrrUY91ar07zIUObJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB4808
X-OriginatorOrg: mit.edu
X-Rspamd-Queue-Id: 4M16G55KxTz3vWJ
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mit.edu header.s=outgoing header.b=YsUPLThA;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}");
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [-6.78 / 15.00];
	SIGNED_SMIME(-2.00)[];
	DWL_DNSWL_LOW(-1.00)[mit.edu:dkim];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	RCVD_IN_DNSWL_MED(-0.20)[18.9.28.58:from];
	R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.56.174:received];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[mit.edu:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_SEVEN(0.00)[7]
X-ThisMailContainsUnwantedMimeParts: N

--Apple-Mail=_A892D013-2118-4C01-A3F1-7C6B2D921A69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I have one of those Chromebooks but I have not tried to boot FreeBSD.  =
The wiki page is obsolete.  It references a configuration file =
CHROMEBOOK-SNOW which was removed in 2019 by the commit below.  I don't =
know if the Chromebook kernel was in the "not working" category or =
"switched to GENERIC" category.

commit 9a042e7d03ae13425132966cd3f3416775157aed
Author: Emmanuel Vadot 
Date:   Wed Apr 10 19:27:14 2019 +0000

    arm: kernel: Remove old kernel configs
   =20
    Follow up to r346095
    All those kernels are either not working or the release have =
switched
    to GENERIC


> On Aug 7, 2022, at 04:58 , Mario Marietto  =
wrote:
>=20
> Hello.
>=20
> A lot of years ago,I bought the cool notebook "Samsung Chromebook =
"SNOW" model XE303C12" where it seems that only ChromeOS and Linux can =
be installed. The specs are the following ones :
>=20
> 	=E2=80=A2 CPU: Samsung Exynos 5 Dual (5250) (Cortex A15; 1.7GHz =
dual core cpu)
> 	=E2=80=A2 GPU: ARM Mali-T604 (Quad Core)
> 		=E2=80=A2 1366x768 screen & HDMI external connector
> 	=E2=80=A2 RAM: 2 GiB DDR3
> 		=E2=80=A2 The memory is not upgradable as it is soldered =
directly to the board
> 	=E2=80=A2 Disk: 16 GiB SSD (connected to eMMC)
> 		=E2=80=A2 SD & USB expansion slots
> 	=E2=80=A2 WiFi: 802.11 a/b/g/n
> 		=E2=80=A2 USB slot can handle Ethernet dongle
>=20
> I'm trying to look on Internet to understand if I can install FreeBSD =
without having all the troubles explained here :
>=20
> https://wiki.freebsd.org/arm/Chromebook
>=20
> Which options do I have to have a fully working FreeBSD system on that =
machine ? If it can't be installed natively,maybe these two options are =
feasible ? :
>=20
> 1) to virtualize FreeBSD using qemu and kvm
> 2) to install FreeBSD using the crouton chroot method ?
>=20
> What else ? What do you think ? Maybe you know some specific tutorial =
that's more updated and that can allow me to install freeBSD on that =
machine making almost everything work as expected.
>=20
> --
> Mario.


--Apple-Mail=_A892D013-2118-4C01-A3F1-7C6B2D921A69
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA7sw
ggO3MIIDIKADAgECAhEAllRUaZWy44T/aVEsqzSrczANBgkqhkiG9w0BAQsFADBsMQswCQYDVQQG
EwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0
aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMB4XDTIyMDcwNTE2NTQ0
NVoXDTIzMDczMDE2NTQ0NVowgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQL
EwxDbGllbnQgQ0EgdjExFDASBgNVBAMTC0pvaG4gRiBDYXJyMRowGAYJKoZIhvcNAQkBFgtqZmNA
TUlULkVEVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Ka5+9REw1B9JXThajulqv
SjDFK1pNpGB2nljRQy5iTTTVddq/4+s+uC88etHWbMquFd/i9sCIxLHgDFhlGZRhcORhzDfwIxLA
P8q4KMsAPeXO2kgh86pGH+DEsUPEbEtdkN2cnT9kt+BE2cPCOiqAR+YBWZX3ebDLc4+eWiPfErg7
WEr4XcIraxxxtLuUR6sVbN7nG7WCtBCalzbAxryy5GmWZ1z4OawzylJVb+qLKeMi3XN+H/d+shdm
6PmyqGeCu7jpN3+g/eAuWk/PWhIUhDwABK9JGWW2+xWCtDHxutzRt8vDMZK2GaE6MzpBpTFR1P1o
IdodVtrHGtVnKq0CAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBQCc+0gYnBj
WRsOZgQ78pmO+ojOaDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRj
bGllbnQuY3JsMA0GCSqGSIb3DQEBCwUAA4GBAAm/9fT9H4n5ks4q9cGE5FWIwAQmEGre6gMVU+VL
V4p2Qfd4eZki0uKg+Vi6BWeHL2GMQQpnpjgm1Xx6q7oSruPTkkrs75X7oTW5Nf550U5qEKXSqboK
y+6dkw8fNvNci0tYs0j+Ev6JPU4VgDK/NSWtRFrndFzLI2SgJ6k+Ess4MYIDRjCCA0ICAQEwgYEw
bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1
c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZU
VGmVsuOE/2lRLKs0q3MwDQYJYIZIAWUDBAIBBQCgggGVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgwNzE3NDYzMVowLwYJKoZIhvcNAQkEMSIEIBPM1QzyIEqD
QLIZHtzyZCMH9W0lUhNCF7qXCzeGHbkaMIGSBgkrBgEEAYI3EAQxgYQwgYEwbDELMAkGA1UEBhMC
VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0
dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZUVGmVsuOE/2lRLKs0
q3MwgZQGCyqGSIb3DQEJEAILMYGEoIGBMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo
dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw
EwYDVQQLEwxDbGllbnQgQ0EgdjECEQCWVFRplbLjhP9pUSyrNKtzMA0GCSqGSIb3DQEBCwUABIIB
AAbbdNOO2aqJTnifrDk+pyfKivXiGrBsMcCbzWZ6oVC2uYKCKQUes71jjADeSrdUQ5zjT/h5auCc
FDz+zrckqHwqCD0Gv30WStIDEz+ko7Bkfl9YGUNxSu7ZtCnfN5EfzWCNgdO0Dp2T/zoaR/RGtJ6M
S+TmBMmmcetAZ0Juw2TgQ2Kt2An3S8eplUnIR3HEXXK1vJle1Y8bDoTeZlNRBSJacMjMEUHeDe+x
gcz9Azsyhzzjvv+UZjyZoM2Her0SpLZdt+bTOXTucQGBMdZMMY9dLRuyxdbqzbmimOSCvK95bJtO
qBSOxLZWq6ULJB3s5/Cyu4P7SfLPSL85RB/DMQEAAAAAAAA=

--Apple-Mail=_A892D013-2118-4C01-A3F1-7C6B2D921A69--

From nobody Sun Aug  7 18:43:56 2022
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 4M17Y00PqDz4YgLg
	for ; Sun,  7 Aug 2022 18:44:36 +0000 (UTC)
	(envelope-from marietto2008@gmail.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
	(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 4M17Xz32ZFz432T
	for ; Sun,  7 Aug 2022 18:44:35 +0000 (UTC)
	(envelope-from marietto2008@gmail.com)
Received: by mail-ed1-x532.google.com with SMTP id t5so8950383edc.11
        for ; Sun, 07 Aug 2022 11:44:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=v7HoBgMIrZq2Ev6nVsirfmFGSn9C+lX99W5+cNvkqKA=;
        b=TU6zLQqahyCAFuA3psF6g4TFq+SVZdPBHmU0GAVxleoIwQ0pYrQwyMvtREro+LbT3c
         or3s9D8PvEEW/QATcX8nUyyGSe+w133T+crFE273dhohCdRL7Fsvya1hfyGNOjjbfi6j
         rBJ0zg8k9giLjIZdiRP8lO10fXbvLtLd17SN5KcBMywtFDrwGKTQFf0+3sFX41e57s0T
         D4f/k5GjofRoFpfXikVrF6qGSL1Celv8uF5rs+6KWjaRJzUpfYW9PCAc13TJh835Nk3t
         WNislLSSrZYwk114S2ON8BPIPz5diftPuEABs808kpB0ptUQRGT8NWYbuhVTL1DbNZXr
         yHsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=v7HoBgMIrZq2Ev6nVsirfmFGSn9C+lX99W5+cNvkqKA=;
        b=u24TYpCk21sGjEMhuv7k3Y8KdbH7saFLRF4zYZtkC/xdt1ocAu1hV2dO9PC7Rdgfa5
         YyoKrnmUUCaAAFpQPZQ5YMObVItPz5/9fT7llAaV2nP+FjP2KeSIWFfOjyb9q7gu7F3/
         KnTqg1hpkFRktqIzct7c+tp7rWyedrIseA/M9UBcN1RpcPDupCZyJQje4dDp18XUbw1o
         eQe2N3KimskIAXWaNm9Q16uWed4SnRrX6pWYbNSHYXVNIdX670vailcQ2UqRpQHgy43Z
         bypvGFQkqllk7ocyw5c618aSgK7XyG0RijL9XCI3FAmiePpnd4/bA9LkXcCOxbUjU1Kn
         OeTw==
X-Gm-Message-State: ACgBeo0rwkKdQqEFmKV2LYRg+ACriLOMR7jDpEHrHhNWwbnjUxoz5Vyk
	BX12LrzRegO9YewqHUBpMA2S3gluMJLBDaWWfoo=
X-Google-Smtp-Source: AA6agR6XqCEQKeUzWOV/3d8b7JZ+IxJZ2z8PNNwe8M1H52sG2SNQl9xK0LvsavaZNR/rSLW5jM4doXNqURkanOsbsc4=
X-Received: by 2002:aa7:d49a:0:b0:43c:fed4:c656 with SMTP id
 b26-20020aa7d49a000000b0043cfed4c656mr14946554edr.312.1659897872586; Sun, 07
 Aug 2022 11:44:32 -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: 
 <2C3AB90B-6A82-4C9B-A2B0-E54B093E5083@mit.edu>
In-Reply-To: <2C3AB90B-6A82-4C9B-A2B0-E54B093E5083@mit.edu>
From: Mario Marietto 
Date: Sun, 7 Aug 2022 20:43:56 +0200
Message-ID: 
Subject: Re: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
To: John F Carr 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000000f1d1105e5ab17e2"
X-Rspamd-Queue-Id: 4M17Xz32ZFz432T
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=TU6zLQqa;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=marietto2008@gmail.com
X-Spamd-Result: default: False [-3.94 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_HAM_MEDIUM(-0.95)[-0.951];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000f1d1105e5ab17e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It seems more complicated than I thought.

Il giorno dom 7 ago 2022 alle ore 19:46 John F Carr  ha
scritto:

> I have one of those Chromebooks but I have not tried to boot FreeBSD.  Th=
e
> wiki page is obsolete.  It references a configuration file CHROMEBOOK-SNO=
W
> which was removed in 2019 by the commit below.  I don't know if the
> Chromebook kernel was in the "not working" category or "switched to
> GENERIC" category.
>
> commit 9a042e7d03ae13425132966cd3f3416775157aed
> Author: Emmanuel Vadot 
> Date:   Wed Apr 10 19:27:14 2019 +0000
>
>     arm: kernel: Remove old kernel configs
>
>     Follow up to r346095
>     All those kernels are either not working or the release have switched
>     to GENERIC
>
>
> > On Aug 7, 2022, at 04:58 , Mario Marietto 
> wrote:
> >
> > Hello.
> >
> > A lot of years ago,I bought the cool notebook "Samsung Chromebook "SNOW=
"
> model XE303C12" where it seems that only ChromeOS and Linux can be
> installed. The specs are the following ones :
> >
> >       =E2=80=A2 CPU: Samsung Exynos 5 Dual (5250) (Cortex A15; 1.7GHz d=
ual core
> cpu)
> >       =E2=80=A2 GPU: ARM Mali-T604 (Quad Core)
> >               =E2=80=A2 1366x768 screen & HDMI external connector
> >       =E2=80=A2 RAM: 2 GiB DDR3
> >               =E2=80=A2 The memory is not upgradable as it is soldered =
directly
> to the board
> >       =E2=80=A2 Disk: 16 GiB SSD (connected to eMMC)
> >               =E2=80=A2 SD & USB expansion slots
> >       =E2=80=A2 WiFi: 802.11 a/b/g/n
> >               =E2=80=A2 USB slot can handle Ethernet dongle
> >
> > I'm trying to look on Internet to understand if I can install FreeBSD
> without having all the troubles explained here :
> >
> > https://wiki.freebsd.org/arm/Chromebook
> >
> > Which options do I have to have a fully working FreeBSD system on that
> machine ? If it can't be installed natively,maybe these two options are
> feasible ? :
> >
> > 1) to virtualize FreeBSD using qemu and kvm
> > 2) to install FreeBSD using the crouton chroot method ?
> >
> > What else ? What do you think ? Maybe you know some specific tutorial
> that's more updated and that can allow me to install freeBSD on that
> machine making almost everything work as expected.
> >
> > --
> > Mario.
>
>

--=20
Mario.

--0000000000000f1d1105e5ab17e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It seems more complicated than I thought. 

Il giorno do=
m 7 ago 2022 alle ore 19:46 John F Carr <=
jfc@mit.edu> ha scritto:
I have one of those Chromebooks but I have not tried to boo=
t FreeBSD.=C2=A0 The wiki page is obsolete.=C2=A0 It references a configura=
tion file CHROMEBOOK-SNOW which was removed in 2019 by the commit below.=C2=
=A0 I don't know if the Chromebook kernel was in the "not working&=
quot; category or "switched to GENERIC" category.



commit 9a042e7d03ae13425132966cd3f3416775157aed

Author: Emmanuel Vadot <manu@FreeBSD.org>

Date:=C2=A0 =C2=A0Wed Apr 10 19:27:14 2019 +0000



=C2=A0 =C2=A0 arm: kernel: Remove old kernel configs



=C2=A0 =C2=A0 Follow up to r346095

=C2=A0 =C2=A0 All those kernels are either not working or the release have =
switched

=C2=A0 =C2=A0 to GENERIC





> On Aug 7, 2022, at 04:58 , Mario Marietto <marietto2008@gmail.com> wrote:
> 

> Hello.

> 

> A lot of years ago,I bought the cool notebook "Samsung Chromebook=
 "SNOW" model XE303C12" where it seems that only ChromeOS an=
d Linux can be installed. The specs are the following ones :

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 CPU: Samsung Exynos 5 Dual (5250) =
(Cortex A15; 1.7GHz dual core cpu)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 GPU: ARM Mali-T604 (Quad Core)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 1366x7=
68 screen & HDMI external connector

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RAM: 2 GiB DDR3

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 The me=
mory is not upgradable as it is soldered directly to the board

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Disk: 16 GiB SSD (connected to eMM=
C)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 SD &am=
p; USB expansion slots

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 WiFi: 802.11 a/b/g/n

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 USB sl=
ot can handle Ethernet dongle

> 

> I'm trying to look on Internet to understand if I can install Free=
BSD without having all the troubles explained here :

> 

> https://wiki.freebsd.org/arm/Chromebook

> 

> Which options do I have to have a fully working FreeBSD system on that=
 machine ? If it can't be installed natively,maybe these two options ar=
e feasible ? :

> 

> 1) to virtualize FreeBSD using qemu and kvm

> 2) to install FreeBSD using the crouton chroot method ?

> 

> What else ? What do you think ? Maybe you know some specific tutorial =
that's more updated and that can allow me to install freeBSD on that ma=
chine making almost everything work as expected.

> 

> --

> Mario.






-- 
Mario.


--0000000000000f1d1105e5ab17e2--

From nobody Sun Aug  7 19:32:35 2022
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 4M18cQ3qqVz4Ymfs;
	Sun,  7 Aug 2022 19:32:38 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face])
	(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 4M18cQ2p3wz48jC;
	Sun,  7 Aug 2022 19:32:38 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15])
	(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 D695F56052;
	Sun,  7 Aug 2022 19:32:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us D695F56052
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: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use
From: Glen Barber 
In-Reply-To: 
Date: Sun, 7 Aug 2022 15:32:35 -0400
Cc: Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 FreeBSD Hackers ,
 freebsd-arm 
Message-Id: 
References: 
To: Mark Millard 
X-Mailer: iPhone Mail (19G71)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M18cQ2p3wz48jC
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)[]
X-ThisMailContainsUnwantedMimeParts: N

Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.

I honestly do not have any idea where the problems you are seeing are creepi=
ng in.

Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure how to p=
roceed otherwise.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 7, 2022, at 12:10 AM, Mark Millard  wrote:
>=20
> =EF=BB=BFThe oddities look like indicated below.
>=20
> # mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5=
c60d72-257129.img
> # gpart show
> . . .
>=20
> =3D>      63  10485697  md1  MBR  (5.0G)
>        63      1985       - free -  (993K)
>      2048    102400    1  fat32lba  [active]  (50M)
>    104448  10381312    2  freebsd  (5.0G)
>=20
> =3D>       0  10381312  md1s2  BSD  (5.0G)
>         0  10381312      1  freebsd-ufs  (5.0G)
>=20
> =3D>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
>         0  10381312                       1  freebsd-ufs  (5.0G)
>=20
> =3D>       0  10381312  ufs/rootfs  BSD  (5.0G)
>         0  10381312           1  freebsd-ufs  (5.0G)
>=20
> So: ufs/rootfs apparently identifies the BSD instead of the
> freebsd-ufs . Same for the ufsid/* . This leads to:
>=20
> # gpart show -p=20
> . . .
>=20
> =3D>      63  10485697    md1  MBR  (5.0G)
>        63      1985         - free -  (993K)
>      2048    102400  md1s1  fat32lba  [active]  (50M)
>    104448  10381312  md1s2  freebsd  (5.0G)
>=20
> =3D>       0  10381312   md1s2  BSD  (5.0G)
>         0  10381312  md1s2a  freebsd-ufs  (5.0G)
>=20
> =3D>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
>         0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)
>=20
> =3D>       0  10381312   ufs/rootfs  BSD  (5.0G)
>         0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
>=20
> freebsd-ufs has the unexpected label: ufs/rootfsa
>=20
> # ls -Tld /dev/ufs/*
> crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 /dev/ufs/rootfs
> crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 /dev/ufs/rootfsa
>=20
> Things were actually set up for ufs/rootfs naming as the
> identification of the freebsd-ufs content, per the
> release/tools/arm.subr commands ( from last month's
> main-n256584-5bc926af9fd1 ):
>=20
>        if [ "${PART_SCHEME}" =3D "MBR" ]; then
>                chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZ=
E} ${mddev}
>                chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
>                chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE}=
 /dev/${mddev}s1
>                chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
>                chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
>                chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev=
}s2
>                chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>        fi
>=20
> Note that the newfs command references /dev/${mddev}s2a instead
> of /dev/${mddev}s2 but the rootfs label ends up referencing
> /dev/${mddev}s2 .
>=20
> Is having "0 10381312" for the md*s2 and for the md*s2a a
> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
> to be moved to a different (non-zero) offset inside BSD?
>=20
> Or is this a different kind of bug?
>=20
> I'll not repeat the kinds of explorations that I reported last
> week unless someone wants to request something.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20


From nobody Sun Aug  7 19:50:21 2022
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 4M190z2mt7z4Ypr5
	for ; Sun,  7 Aug 2022 19:50:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4M190x71sbz3D9d
	for ; Sun,  7 Aug 2022 19:50:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=ms5YE/uSFH+aKxrPdovtf3vsgMPHoVwUDElZ79Qhfbw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S+FKvDyQsLawrAXVH1sjM3NfmEqIaaXqzB9DMbYxA3ee8AJ0wj/DgB/S18ECfkwk+Ao2diS6sy0t1u1bUjA7WPvRLFD7CZzNplzwfth75YXKXJFsqH58onFfx8FE3B16kL7O5kqI125ayw6FpkKptuTVGkR086YjUNQ6bHCzn8GHAy9f6UZi/aGMzFTWb2R5VVuL0tzOFjX6kBgsWfH1mMBKKFJ9zNIVI70WLsE66XhiZMBSeB8pCi8eUksi5zckIbyj7Q8vAZbnm/CJXR5h1J6dsRIO9y09htsFc0QwQfNNJFCkYZ4sgoOAQEYEG1sPdF3wzk1UoSCZ+wWmT3BPxQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=3QxCHxTyPL3MLHpREC+T3GQ98nYyJvUanGkiHP7w2N4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F7+nbVC3HCzI7OC14VVhDjAxx38As6gjobOfUpwTNap41leZjZyd4wQijb3ljXBQARKnHotUqVa+gmgT9N8tRVnqnmRjE+QvGPf1t0ucZMWNRlMC9SEyywWpDAlMzf4dDUZ9a2AfRyCBJIbH27fNOcJ523eCan3eBeXp6uBo0GF/9HqdXPF+DJwKtpl9762tJHbXGwSgEbzlvWWlQdqVipV6TYodYCjMolLHmKCaPdxUCYMmx+1oWXS71uYB3i6zKGb/VcXREaCK9r4xQasCP39DtDYuByWQ0qaMIZ4dSRsWht9ssPHu1GAS9evVQtbh4Agnn8rcLvBDoEihktxv8Q==
X-YMail-OSG: ZzC3IsEVM1l7CpyWcLEgIlYIs2FDPxGUJkcQqF1YB6U5lz9yHkWqKburQyZz4O7
 iJCkN_QuOwr_ePfZPHnBfcKqdwkVRxo4TqZVeIYBJMtV16YAHv3j3QW6U9GnNC.7nlRYjK6eBOfC
 HRtIXRYPHJMQSXsC9fy7nN3OcFgWRKzW0Rze785B51Ggt1alzTLbM5VaxYh3.PpVrucKMak4q4AA
 H2zFetwc2nTU2jVuK4ccD7HSEG7QHztMK9kQIgQZTxUhP3qESKncx6pSvdHQaVmS6bIYdO7y5wRE
 Ll56HM4mX5EEjX_2E9E2N.ZAuqTb33X00LV_6LVYm2r9vfVUFGAwOBNRWXBBVy_OSOFp0H8My_cb
 BqASdRV.tqVaZRAlydMlI8JX88rlIN1YVUemuuxyqnDS7rAM7JipydFwEpev6DmJ8TVbndU_J7KF
 pzME_Y7RMKkEpCd3uiyiobvSOPUVbV9u4hOEA0dkkX3lu1ct_lEX9daz0OV5SOakMJlFPKtSTbY9
 peL3Ma2xEdqOJSVPx.H_mjUzhGTgZkuMoH2zWhCE_f9GOb3KXvAJEQnpj8Zo6CsZJ4YG_f9mI_Wo
 3U9kPCdrJPQPPiKvKBQM3YKDc5sUKrMtMD9htRoloEQQG3TkvO2gSc4hdKLe94By3fteTlxCrU6h
 _5SERDQc9ksU1jBypLjAienzVJcfxyVLP39z7FUgdfwrRJUDDNaS05A4gKN8TqwMR3O077zJTsWa
 j7RXdDq3uhC5nsWpO8AWUQtHorMswVoAvZaKum4jT4z_WyQILdssHe7jks9g0T9UtoMeEirRanVy
 E7hMmRxTI3rXjNcr3TsUrWtVXxLuA5fXP8HS6e7B2MPFcV.p9IPmAf5tLHwsRQJO4RoXfbnqogXq
 2LWUYr1dTeVLEjYIlFydKEbVPu3.x3RpBDJrdtHEJijsXwRexrVxvrkLpMQeqUWT6Rb6SaICaVqP
 VuBNXGicY8ETQC5Z79Nlz0XAfXWC0ZyTGme4KE9GawcBCYUwVRwx5ovQVOJgvAQSLX75xqsk5zLq
 w4FGyRQsmLiKcZMROKubpHBatvDOhGsoMViPOmnhzG2mUc_k2PUdR9QR0lg6GjWIr2o2gqXhslgc
 hbTvk27tlluKJjA7XYw4NOqqZSivIhpFIpgTdbXgpwFSvGVivRrZLuJ9PYEJ3pKcj1fHV3S5VTD2
 SpbfW2epN9yMVwY0_0QsBjEktLs6bp0xPxozz3hLJ1Vgc6zjUZoeiB7DE03LydIvKZn.3aAI11r3
 kCnskgGFFpFm0IT0FkD.1Ye66tpuJOoeUYvLHS2Byc3F1GRZmfubHD3ZU5bb4_U.9mFuguXye8UT
 Ph9QO4tdSKOVuwQurFC2NH6dxqmYfgnb9jPQQg9Yete7T29vKlS1m6b.sEYhydCbSstN2WLd1M4Z
 Xl_bR5c_z2Xr.SoSnrJ8SJm4KfuDCPzO.8aPpTVahvOJvgLc4Se0tafk0xrZV1ORg7kIqFrJnDju
 EqkF0TXaq55PpnsaKD1z4dqKsvJmG7rAwZPuP_nYiKewHcXMa7J6h66FrE4LL7lshuiCZNYbjjcQ
 riGnRyJtaGPXNXaDMbJ6gakxpobH5CvhlYW2nWD_1j0hGcn8LNVqb7ZLh.WYY0.2F52pvA4jO1xo
 965iwcXHH_DqUvp.jZfsHwmAsdFH12Xv6Pw5PJG.cGD9SbZDy1r5L5vsLArF_uxXmFdpGwZoRyce
 vR_bTjzRPLIZZypQ3crBG_JVjxOGbJ1aDDj9RxJH06R5RuzdJsfunYBtRMBT8mf5Zx4OwEdwCj9H
 ne2wkBgHjtsanbnvzc8U04qyGU6Zw8Ma2uP0RLKDjBlT_j6B.OtmoqiTDHaEA4mAPS5TmqsEW2uU
 jtKm_4dIBB5X1ky8NPWmvLWKXww7vTd9mTMtxZSQ7SJeRM91IAtey4hbRv7c9A0oYUcBGTLyJrZD
 0Ik_PvGHSPqj0HPvQ97n88l54lezgopnDvQC2AKNchz9cSBRumCEGhFMqS7a1fmfuCMIddtwFdTc
 pGN15U61MejvoLAZndfGjbBuneTSsR8JQSiuek8Y9srIrk6yVf7ZXYcfkOZrBg0wtWASGZHEun35
 awN6neHJHSZv_kqfmYG3O0svB6NV5cXJkwwweEIMmX6c5khkOAN9ASb5SHavtRcI7JH1t6UgcWPO
 qdQC.._oC4Gn54BYODxymZCKOjzldJRGvc2pNDohfc7q_AFc23V0dq_cTBauKut8VJFr3FIYu6NK
 rS3WPiS8xJfNv0v1eYBDAqI6HoZI.YYMgs8OGLyuBwfvOEOXy6NLF_i_oQgM7ObvDskZOT2uyCid
 WLt9vNYcS
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 19:50:23 +0000
Received: by hermes--production-gq1-686964ccb6-fq25x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4960ff856c766e649e2ea3f0ff4987e8;
          Sun, 07 Aug 2022 19:50:22 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: Mark Millard 
In-Reply-To: 
Date: Sun, 7 Aug 2022 12:50:21 -0700
Cc: Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 FreeBSD Hackers ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
References: 
 
To: Glen Barber 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4M190x71sbz3D9d
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=S+FKvDyQ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_HAM_MEDIUM(-0.30)[-0.304];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Aug-7, at 12:32, Glen Barber  wrote:

> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>=20
> I honestly do not have any idea where the problems you are seeing are =
creeping in.
>=20
> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure =
how to proceed otherwise.

My guess is that if the release/tools/arm.subr line:

              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2

was instead (note the added -b use):

              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k =
${mddev}s2

then the line:

              chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a

would work as expected and things would still be aligned:
no aliasing of BSD vs. freebsd-ufs. (In part this is by
prior steps already having achieved alignment of BSD.)

But I do not know how to classify doing so: Work around?
Known required-procedure for -L rootfs to correctly
identify the the freebsd-ufs /dev/${mddev}s2a ?

Absent better information from folks that know more, I'd
suggest trying such an adjusted release/tools/arm.subr
next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in
place, if such an experiment can be reasonable.

> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>=20
>> On Aug 7, 2022, at 12:10 AM, Mark Millard  wrote:
>>=20
>> =EF=BB=BFThe oddities look like indicated below.
>>=20
>> # mdconfig -u md1 -f =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
>> # gpart show
>> . . .
>>=20
>> =3D>      63  10485697  md1  MBR  (5.0G)
>>       63      1985       - free -  (993K)
>>     2048    102400    1  fat32lba  [active]  (50M)
>>   104448  10381312    2  freebsd  (5.0G)
>>=20
>> =3D>       0  10381312  md1s2  BSD  (5.0G)
>>        0  10381312      1  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
>>        0  10381312                       1  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312  ufs/rootfs  BSD  (5.0G)
>>        0  10381312           1  freebsd-ufs  (5.0G)
>>=20
>> So: ufs/rootfs apparently identifies the BSD instead of the
>> freebsd-ufs . Same for the ufsid/* . This leads to:
>>=20
>> # gpart show -p=20
>> . . .
>>=20
>> =3D>      63  10485697    md1  MBR  (5.0G)
>>       63      1985         - free -  (993K)
>>     2048    102400  md1s1  fat32lba  [active]  (50M)
>>   104448  10381312  md1s2  freebsd  (5.0G)
>>=20
>> =3D>       0  10381312   md1s2  BSD  (5.0G)
>>        0  10381312  md1s2a  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
>>        0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312   ufs/rootfs  BSD  (5.0G)
>>        0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
>>=20
>> freebsd-ufs has the unexpected label: ufs/rootfsa
>>=20
>> # ls -Tld /dev/ufs/*
>> crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 =
/dev/ufs/rootfs
>> crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 =
/dev/ufs/rootfsa
>>=20
>> Things were actually set up for ufs/rootfs naming as the
>> identification of the freebsd-ufs content, per the
>> release/tools/arm.subr commands ( from last month's
>> main-n256584-5bc926af9fd1 ):
>>=20
>>       if [ "${PART_SCHEME}" =3D "MBR" ]; then
>>               chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s =
${FAT_SIZE} ${mddev}
>>               chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
>>               chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F =
${FAT_TYPE} /dev/${mddev}s1
>>               chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
>>               chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
>>               chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>               chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>       fi
>>=20
>> Note that the newfs command references /dev/${mddev}s2a instead
>> of /dev/${mddev}s2 but the rootfs label ends up referencing
>> /dev/${mddev}s2 .
>>=20
>> Is having "0 10381312" for the md*s2 and for the md*s2a a
>> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
>> to be moved to a different (non-zero) offset inside BSD?
>>=20
>> Or is this a different kind of bug?
>>=20
>> I'll not repeat the kinds of explorations that I reported last
>> week unless someone wants to request something.
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Aug  7 19:53:29 2022
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 4M194k6XN6z4YqFN
	for ; Sun,  7 Aug 2022 19:53:42 +0000 (UTC)
	(envelope-from maficccc@gmail.com)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d])
	(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 4M194j6GRGz3Fps
	for ; Sun,  7 Aug 2022 19:53:41 +0000 (UTC)
	(envelope-from maficccc@gmail.com)
Received: by mail-ua1-x92d.google.com with SMTP id s7so2832804uao.4
        for ; Sun, 07 Aug 2022 12:53:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=KuhaVb8WzNbCaUUap7rbBABUyKno9nDilpI0AZZWMb8=;
        b=pGDHPW2eUAK6OrnmiJZ3HHu46IG+Ufu3gJBIqE4xYRgc1ltotemtP3CMfYbzjBfoLA
         RIUoobmEnvUljrX4+phNHxelusG5OX9NbnDBiuHNQT3xywZ9CNsVI70X92GRVDytzjaD
         eYGi/izqRopmewME52By6FQTcMAP172eA3W5N9xk3N5+KayF9YehlVjB2OeOjknl2TXT
         LYvHulVotqruw0eqw2Fqi5XYssOSBZIqgYqyeb1aNPMMVbXu6dKKMN3TVpcxSFZevP2C
         KSV8WocSHT1XiF0Yk7VEFDmTwrxBDfYOhf5RxzYM4M+IZ17a38paQeFgrpGCruSO2RJN
         yBsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=KuhaVb8WzNbCaUUap7rbBABUyKno9nDilpI0AZZWMb8=;
        b=7nP6FQReNGyt69RdRtbFV4sYsIvytqyIK5Y19AZ78iuRPkeFXrHPtc7EsaNV5UGFhe
         j8RRN5CfqfeWhbu1ZEvgbrQX14Ahd+NVIbBUW0HAUGKQjKvxmVpSjQsZ78DNtyjbrobW
         YxE9ELXx4yuLZKUvGqYSayAwrXPi0ZsVzxVuLq4pDcRlohFaCxAgN6IYQ90q3S48P0Qf
         0f3wanuA343cA+p+wNMzJj08fALUyJA2XLM7xze4c569KBbh+08lquT/QgSJBvmgRBRi
         rcP0LiZXWEK1coLxfi3qpFPyM6MeNmATfBqkOvIXxILFX5R1A7wTDQC0wLGQU33XmfcT
         yhAg==
X-Gm-Message-State: ACgBeo2alQBjbyi2D3n0P3QGPl/FVEu3jSdv6QC6GCFRbA+NT6a/XZk9
	Mkx9XssF5lJiQrcv+DqGjVVJBAU542asmQzZNUo=
X-Google-Smtp-Source: AA6agR4VZnHtlI89fbINMgev2Ez92YO7ZPF/D50PKEcmMycMQe3nuE+3/mVc16Q7xVvyfe6xuPNanOgF69sPhOWaT6I=
X-Received: by 2002:ab0:3da5:0:b0:382:7933:fdcc with SMTP id
 l37-20020ab03da5000000b003827933fdccmr6569672uac.88.1659902020977; Sun, 07
 Aug 2022 12:53:40 -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: 
 <2C3AB90B-6A82-4C9B-A2B0-E54B093E5083@mit.edu> 
In-Reply-To: 
From: "M." 
Date: Sun, 7 Aug 2022 21:53:29 +0200
Message-ID: 
Subject: Re: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
To: Mario Marietto 
Cc: John F Carr , "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000528b6c05e5ac0e9d"
X-Rspamd-Queue-Id: 4M194j6GRGz3Fps
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=pGDHPW2e;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of maficccc@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=maficccc@gmail.com
X-Spamd-Result: default: False [-3.93 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.97)[-0.966];
	NEURAL_HAM_LONG(-0.97)[-0.965];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92d:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000528b6c05e5ac0e9d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You can try checkout release/12.3.0 back and compile the chromebook kernel
for now.

make TARGET_ARCH=3Darmv6 KERNCONF=3DCHROMEBOOK-SNOW buildworld buildkernel


ne 7. 8. 2022 v 20:44 odes=C3=ADlatel Mario Marietto 
napsal:

> It seems more complicated than I thought.
>
> Il giorno dom 7 ago 2022 alle ore 19:46 John F Carr  ha
> scritto:
>
>> I have one of those Chromebooks but I have not tried to boot FreeBSD.
>> The wiki page is obsolete.  It references a configuration file
>> CHROMEBOOK-SNOW which was removed in 2019 by the commit below.  I don't
>> know if the Chromebook kernel was in the "not working" category or
>> "switched to GENERIC" category.
>>
>> commit 9a042e7d03ae13425132966cd3f3416775157aed
>> Author: Emmanuel Vadot 
>> Date:   Wed Apr 10 19:27:14 2019 +0000
>>
>>     arm: kernel: Remove old kernel configs
>>
>>     Follow up to r346095
>>     All those kernels are either not working or the release have switche=
d
>>     to GENERIC
>>
>>
>> > On Aug 7, 2022, at 04:58 , Mario Marietto 
>> wrote:
>> >
>> > Hello.
>> >
>> > A lot of years ago,I bought the cool notebook "Samsung Chromebook
>> "SNOW" model XE303C12" where it seems that only ChromeOS and Linux can b=
e
>> installed. The specs are the following ones :
>> >
>> >       =E2=80=A2 CPU: Samsung Exynos 5 Dual (5250) (Cortex A15; 1.7GHz =
dual core
>> cpu)
>> >       =E2=80=A2 GPU: ARM Mali-T604 (Quad Core)
>> >               =E2=80=A2 1366x768 screen & HDMI external connector
>> >       =E2=80=A2 RAM: 2 GiB DDR3
>> >               =E2=80=A2 The memory is not upgradable as it is soldered=
 directly
>> to the board
>> >       =E2=80=A2 Disk: 16 GiB SSD (connected to eMMC)
>> >               =E2=80=A2 SD & USB expansion slots
>> >       =E2=80=A2 WiFi: 802.11 a/b/g/n
>> >               =E2=80=A2 USB slot can handle Ethernet dongle
>> >
>> > I'm trying to look on Internet to understand if I can install FreeBSD
>> without having all the troubles explained here :
>> >
>> > https://wiki.freebsd.org/arm/Chromebook
>> >
>> > Which options do I have to have a fully working FreeBSD system on that
>> machine ? If it can't be installed natively,maybe these two options are
>> feasible ? :
>> >
>> > 1) to virtualize FreeBSD using qemu and kvm
>> > 2) to install FreeBSD using the crouton chroot method ?
>> >
>> > What else ? What do you think ? Maybe you know some specific tutorial
>> that's more updated and that can allow me to install freeBSD on that
>> machine making almost everything work as expected.
>> >
>> > --
>> > Mario.
>>
>>
>
> --
> Mario.
>

--000000000000528b6c05e5ac0e9d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You can try checkout release/12.3.0 back and compile =
the chromebook kernel for now.
make TARGET_ARCH=3Darmv6 =
KERNCONF=3DCHROMEBOOK-SNOW buildworld buildkernel

=

ne 7. =
8. 2022 v=C2=A020:44 odes=C3=ADlatel Mario Marietto <marietto2008@gmail.com> napsal:
It seems mor=
e complicated than I thought. 

Il giorno dom 7 ago 2022 alle ore 19:46 J=
ohn F Carr <jfc@mit.edu=
> ha scritto:
I have one of those Chromebooks but I have not tried to boot FreeBSD.=
=C2=A0 The wiki page is obsolete.=C2=A0 It references a configuration file =
CHROMEBOOK-SNOW which was removed in 2019 by the commit below.=C2=A0 I don&=
#39;t know if the Chromebook kernel was in the "not working" cate=
gory or "switched to GENERIC" category.



commit 9a042e7d03ae13425132966cd3f3416775157aed

Author: Emmanuel Vadot <manu@FreeBSD.org>

Date:=C2=A0 =C2=A0Wed Apr 10 19:27:14 2019 +0000



=C2=A0 =C2=A0 arm: kernel: Remove old kernel configs



=C2=A0 =C2=A0 Follow up to r346095

=C2=A0 =C2=A0 All those kernels are either not working or the release have =
switched

=C2=A0 =C2=A0 to GENERIC





> On Aug 7, 2022, at 04:58 , Mario Marietto <marietto2008@gmail.com> wrote:
> 

> Hello.

> 

> A lot of years ago,I bought the cool notebook "Samsung Chromebook=
 "SNOW" model XE303C12" where it seems that only ChromeOS an=
d Linux can be installed. The specs are the following ones :

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 CPU: Samsung Exynos 5 Dual (5250) =
(Cortex A15; 1.7GHz dual core cpu)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 GPU: ARM Mali-T604 (Quad Core)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 1366x7=
68 screen & HDMI external connector

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RAM: 2 GiB DDR3

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 The me=
mory is not upgradable as it is soldered directly to the board

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Disk: 16 GiB SSD (connected to eMM=
C)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 SD &am=
p; USB expansion slots

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 WiFi: 802.11 a/b/g/n

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 USB sl=
ot can handle Ethernet dongle

> 

> I'm trying to look on Internet to understand if I can install Free=
BSD without having all the troubles explained here :

> 

> https://wiki.freebsd.org/arm/Chromebook

> 

> Which options do I have to have a fully working FreeBSD system on that=
 machine ? If it can't be installed natively,maybe these two options ar=
e feasible ? :

> 

> 1) to virtualize FreeBSD using qemu and kvm

> 2) to install FreeBSD using the crouton chroot method ?

> 

> What else ? What do you think ? Maybe you know some specific tutorial =
that's more updated and that can allow me to install freeBSD on that ma=
chine making almost everything work as expected.

> 

> --

> Mario.






-- 
Mario.
=





--000000000000528b6c05e5ac0e9d--

From nobody Sun Aug  7 21:00:11 2022
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 4M1BYS4Qhzz4Xl4w
	for ; Sun,  7 Aug 2022 21:00:12 +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 4M1BYR67G2z3Mmd
	for ; Sun,  7 Aug 2022 21:00:11 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4M1BYR570nzQrj
	for ; Sun,  7 Aug 2022 21:00:11 +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 277L0BXF086074
	for ; Sun, 7 Aug 2022 21:00:11 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 277L0BK7086073
	for freebsd-arm@FreeBSD.org; Sun, 7 Aug 2022 21:00:11 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202208072100.277L0BK7086073@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, 7 Aug 2022 21:00:11 +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="16599060112.ad8Cfba6.85182"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659906011;
	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=6dc8Fd4opct3yhl+aBBEQ715B/5f5ijWFQAIHOXgeVY=;
	b=U/rdmKzrouPd+tHhWLI21oqHDY8Hx7Z+Z4aUpH4MBSrr32Qe6ILUOkiz4CtLPngmi1vgjU
	0+q+JgQdqQ2aEZ8KBvhE+Q5FBNr31yUi6HOaAaMNN53o6L0Tt5S1eBlMPnkchUVu1SSxxx
	Gum0RFMQtuAF1YHj1vNiyf/bda1waZOEe9yexFHAhMJnjaU3a5npE4qU0LZhLDjTG5ToPm
	nSgOdWFaul3sImcLtGtZagaNCAyzp2OyWRS3DtWr1/HE+b6YyIMtrLUc24RNeXEP50DNcm
	ufeMgKmJPecuUHa4+DfM+MQFKUDP2oA3TqyXlE5n+cwfH1BD1Fpo/53n4Amq+Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659906011; a=rsa-sha256; cv=none;
	b=OnHLm4f9nuWjBIE5keX1forDm3c43EJSzlWhtsqWezYtvcz3Mc5ODmYjTpasIjOh47MgGF
	+ctq9PGH6UaIbTzGaSK78990069qPelRl6aIXYIHM3n7KwHJe7X+bDwhvJEKRSU27nAyop
	tElcQoKpbetOMo9dtmg1zkYPl1aaoX4/CPcI/ODIDljRQs3tGuY02mlE7M8/8XJdqdBUcs
	rDFWOkzRPaLgvabX55NRE6bfnc0wvVRtyOP/sbOsM4LpXISxIcoh2YZZNN82QZGiWxGIsr
	Z3o1G2czeb5l1G051VgqrB9G6I8wu8WSZp+p76z7QNh4ekxi4EUr9XGUcqksIg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16599060112.ad8Cfba6.85182
Date: Sun, 7 Aug 2022 21:00:11 +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.

--16599060112.ad8Cfba6.85182
Date: Sun, 7 Aug 2022 21:00:11 +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.


--16599060112.ad8Cfba6.85182--

From nobody Sun Aug  7 21:51:02 2022
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 4M1ChQ0KHyz4XtHG;
	Sun,  7 Aug 2022 21:51:18 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.54])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1ChP3t5pz3XQt;
	Sun,  7 Aug 2022 21:51:17 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1659909068;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=+ehPSXnZIpzdU5rTlkPFHwuIMSGCcb9VZXQe16DIkl0=;
    b=nUbSmM476DPGagoTIk26XBHdUAF2RvRi32Twx//aITXOD/KEFuLYViLJG2seDqfAlh
    fuXcYOjK3LmH0PNiYyC8D7xkbnMSHlRcvWLMUamDFdcLrMu0HDlziJQZdsYkikJMByd/
    a5ZNbkn1B/PKjZY6GaNTlosm8/Fa2lutTiU0AxPO8o4Y1TdjUW4zmERvtif/aDvvwMV/
    jZnZ0NJF0HsM4fmik1hlgzWsrMttUkQpcel30Au1KYDVjIaBYGFOtWYDbbwIm3eFKeUY
    ZTEt9Cx8YdT9RSu+Kls9uwRzkhvECRQkSxHSwgKcHgc4K3lfOFAvZXRqDVhPznIJVDnQ
    VYkg==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id q0201fy77Lp8tci
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Sun, 7 Aug 2022 23:51:08 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.189.198.217])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 2E72C63AAD;
	Sun,  7 Aug 2022 23:51:05 +0200 (CEST)
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.15\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: "Dr. Rolf Jansen" 
In-Reply-To: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
Date: Sun, 7 Aug 2022 18:51:02 -0300
Cc: Glen Barber ,
 Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 FreeBSD Hackers ,
 Mark Millard 
Content-Transfer-Encoding: quoted-printable
Message-Id: <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com>
References: 
 
 <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M1ChP3t5pz3XQt
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 07.08.2022 um 16:50 schrieb Mark Millard :
>=20
> On 2022-Aug-7, at 12:32, Glen Barber  wrote:
>=20
>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>=20
>> I honestly do not have any idea where the problems you are seeing are =
creeping in.
>>=20
>> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure =
how to proceed otherwise.
>=20
> My guess is that if the release/tools/arm.subr line:
>=20
>              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>=20
> was instead (note the added -b use):
>=20
>              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a =
64k ${mddev}s2
>=20
> then the line:
>=20
>              chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>=20
> would work as expected and things would still be aligned:
> no aliasing of BSD vs. freebsd-ufs. (In part this is by
> prior steps already having achieved alignment of BSD.)

=46rom a strict mathematical stand point of view, -a is not necessary =
when using -b with an aligned value.

Personally I don=E2=80=99t use the -a option of gpart anymore since it =
started to do funny magics in front of face. If I remember correct, =
gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, =
I align all my storage media by employing -b with a reasonable value.

Best regards

Rolf=

From nobody Sun Aug  7 22:16:19 2022
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 4M1DFS2QBRz4Xxr8
	for ; Sun,  7 Aug 2022 22:16:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4M1DFS1Fjnz3ZYH
	for ; Sun,  7 Aug 2022 22:16:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659910586; bh=q1/2YIMYpXRcIrFkcVOiazxroVFTq+djsanbzkZTRA8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CsitsPvrTeqoMEv1OTMEccJbnviA2LJFfkgr+mKNpO7o7JnBbLzNEUqt2HrVPfU/wtl5mDhJat+hbqXd+HdF8PswssZk2HWw6OpyXbC6JPK4d+fIkHDWi54fpUv6LHHZMWuRixgqWEvaFoyKUet72N3KkXsrh1JdKpedMAg8/Q4bNkuFVxjWsi7/2wO3Ch9frji8yjbUeHYjSbSNRFCatXjJxslX/xp5ufkds3nE0YF5bUdjUZA+xpJ+fiJv4GrdSVfsZbzCvqYbTulwVZWuqsDEK8MTPgJIbYnYnV5WtjDjSTR/jdCE77bCr9yVvjB/uS69T3IWpdSKTeRTeYg08A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659910586; bh=57pN1WQ9GzQB09QQBikyGMlyPAO1ZH87JxigUw1O5o8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cmPqIgpQMwDEnqeHGKKh4kGGF463lcjh9Rg6GwySy3yqDANwCpLWQVGpoVF5jb6V5nsHJJK+VOAXfR/tokgRsFfCML+DSov0loVncHOU3WAIMOlyvcs/ElY/86D4oC6gM6F9+p5/oayzZBuVmxJZQfyM5jMUICwINx8oMPldu0E/vq5q/DRTFQa86xyMT94IHOwl+U3h7Ut6xMTw+PynYJ34HRr1FxBLTqWGzsOzDaHU75A/1kF9D+4k8Xv4//tdkjTCn9JaxymFcp+Clh3rhjPzzX61rv8yqgYHgQN7eSu22RTJCwXqv6zjQZndXXuGFFxGb1ww0m2f1+cOKdIoCA==
X-YMail-OSG: 4B_Md_YVM1mADBAJvyUQOp1H7JC.1HvkDGM0A36vTQQs7v70jQL4PBxQhoZI8ga
 3h1TQjk0c8Q.Lsp5ShxBuHoRMcFrx2sIf.HOC1V3LJXewTK3kX4a1Nz4ixpVW4ue70EaQe5swM5e
 6OMrnxQwq5Aug_KJT52cHMm9BiJkumbd0vqSqr1czsPUZh7Naz106dJ9dR7KD9_maYUpGoWyxe0K
 wC5bJhdHmZUtV1XuaxgZ5ADb.PKFhYdlJ9QmibNQHKwSKnTz8CaR5.4m5r0DaeeDWvmUM6cmt39q
 BQzywbznUqNzcr2fUp2MxvXBt0Yy97wH9KNCobXGh1f_obwpi2yHXtR8CxpsJVQEe2ralbcMInVo
 LpyUBdSTs.xRSSUXVhiJLeDnq82Amm0y2su2LQFt9dxWENHDxB4XS.odkQtgIIGX_LmKy7dG.yDq
 hAjGJDmTF6L.Z6HZnXUVSz4b9qoa_ZkV6mj3Zw8gc8hgIW0yCeBY5xB4laGqV7UioJ7fhGUEwMKv
 X7g2Tpb3eAG9OPh5JW_7qI4NyIqkAp9HKVjqYcGMkZOJ1Ucn1Dc132U40qCHN6PP3MWka_vNrf3j
 rmOeJjzcxbfLDGBuDfatDn52R40qa5acUxF940IUHZBp4eBsY10pcCXJZTLUpY6kmZwPnokapoFr
 4mSXaM2PXfj8gG.Q1z3q__3rgW4w7cSFBiaewl7zjLw7OY_PKjkIIbxBGiiLtWLqtHqnUK2iZSJI
 B51yperhyVZvikufxjugLK5Uu1aPxa6sM9wwIaH.Udx_TAPiwVN1xZnVGRFXhtfx8zsJ1bg2z73L
 703kcubsQt.Ka7Hv2A1uMkbmZXLLE6YLBTP35ToDDcU0mpY4yAM5z2ChWJxpFx5VJTZuenzqzJPX
 lF5V5q4gu_.yRVNJ83MyqnyKI7hV9osxeHagnuEW_4b4JZotAC9I7_isf9JzlL49eCOfATbhM08B
 lniX8wjSsGHP3cE1ZsycjrKShhVpYt5CeD47DorDqRXHGd_J3uFysG6SM6LRrsiH.3tp.aedEZjj
 CKPrY19RSzB9EIfaMA5uKG_F90wVOpKDG2bWlwU2NhuFKeOWu8EesUQorfbiozdWVkgItu0.Jk5N
 trDjkuQXtnCAiIXtpOpwpO06nH0nqT_jFSa.jZqUoOfFoa2gj1vu5mSqyjBhIstcxbHrC9VLGogF
 3.KP9TZXFqzo.E0L0giXddYOFWWmPHtNsbsFiClwiUMEbN.Rmn6XzzyEZPuC2DO4dVC6bAhP5xwH
 HHdOOBnF_j2pu617amw5F54JJF3Tdwl7Kll2I.wckBF.GP9IiIpYxPNyurPcEasDNzzERLqW4klR
 AutIW2B6G5A6QqSx2H0gci_KPVTZQNlWaemoiT376K_1xQVFwermhd7f9pI3qw5BxZ8P2Ul3pcGe
 Kulkq6kP3dXjUIwyIAie.xH6AAekTSW0FfG4iyYJ65D3wRNdhJuTiRbqqpwy_INKzxLCHiB3U4RA
 SVcUlc.Q_DjFjhrpGDM5eXmLRMEfp_uqiXBp8h9VheBzNMw6AQwj3h0Qemea2kCLiUzPkDJbjc0D
 GvqJjlU8Os0Mk0Up9L2TYD9JEw4xJMFT0wdOXF4H9k0kAYnD3cUYUu.E.X9ZgnLX.BxjCQVCsg._
 IS1kTzR5c652qBUiyeP_lvwJ1Lq541.GqXvyfQCLGSwe8n5kydU.k1LxYv.B8YGlemfSsMvE_5FH
 ABjlzZg7OCjE1iq1gHrGOlP0wm6XrJ3MIpHfVmgr1ag.rroVOXi0zd_sD3.AoPNTOmoUw35EUuuT
 LZcUYEaiqVMfmfUKrJvHc0fmD4fWzX8it5Y_X8jnUhZrSBRVg2Fip.1fytiyqpzb1pTj3wJGfgzU
 fVfzNAO8rSfWRKmSsNDkLV7mCpO9xR.becYjRIdZ5DFYX0ToofeMUZlg54cbyvAGAi7KtylBmpcb
 iQzo8hjWVK3A2CeirmjSUVy0cxPXY_Ue6F2yXShMda87ncWl6qKQvbStalw0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 22:16:26 +0000
Received: by hermes--production-ne1-6649c47445-znbvb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID afe50112fc0d2df2592cf31fd213da77;
          Sun, 07 Aug 2022 22:16:21 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: Mark Millard 
In-Reply-To: <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com>
Date: Sun, 7 Aug 2022 15:16:19 -0700
Cc: freebsd-arm ,
 Glen Barber ,
 Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 FreeBSD Hackers 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com>
References: 
 
 <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
 <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M1DFS1Fjnz3ZYH
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen  =
wrote:
>=20
>> Am 07.08.2022 um 16:50 schrieb Mark Millard :
>>=20
>> On 2022-Aug-7, at 12:32, Glen Barber  wrote:
>>=20
>>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>>=20
>>> I honestly do not have any idea where the problems you are seeing =
are creeping in.
>>>=20
>>> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure =
how to proceed otherwise.
>>=20
>> My guess is that if the release/tools/arm.subr line:
>>=20
>>             chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>=20
>> was instead (note the added -b use):
>>=20
>>             chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a =
64k ${mddev}s2
>>=20
>> then the line:
>>=20
>>             chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>=20
>> would work as expected and things would still be aligned:
>> no aliasing of BSD vs. freebsd-ufs. (In part this is by
>> prior steps already having achieved alignment of BSD.)
>=20
> =46rom a strict mathematical stand point of view, -a is not necessary =
when using -b with an aligned value.

"-a" controls more than the start offset: also the size.

QUOTE
               -a alignment  If specified, then the gpart utility tries =
to
                             align start offset and partition size to be
                             multiple of alignment value.
END QUOTE

I expect your statement would at most apply to the start offset, not to
everything "-a" does.

> Personally I don=E2=80=99t use the -a option of gpart anymore since it =
started to do funny magics in front of face. If I remember correct, =
gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, =
I align all my storage media by employing -b with a reasonable value.
>=20

I've no clue of the specifics that you are referencing and so can not =
check.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Aug  7 22:43:44 2022
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 4M1Ds46nylz4Y2BB;
	Sun,  7 Aug 2022 22:43:52 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face])
	(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 4M1Ds46Nvsz3cxM;
	Sun,  7 Aug 2022 22:43:52 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15])
	(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 BBF3D56203;
	Sun,  7 Aug 2022 22:43:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us BBF3D56203
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: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use
From: Glen Barber 
In-Reply-To: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
Date: Sun, 7 Aug 2022 18:43:44 -0400
Cc: Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 FreeBSD Hackers ,
 freebsd-arm 
Message-Id: <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org>
References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
To: Mark Millard 
X-Mailer: iPhone Mail (19G71)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M1Ds46Nvsz3cxM
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)[]
X-ThisMailContainsUnwantedMimeParts: N

Will do.  I=E2=80=99ll commit the suggested change to main tomorrow.

Thank you for your vigilant investigation.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 7, 2022, at 3:50 PM, Mark Millard  wrote:
>=20
> =EF=BB=BFOn 2022-Aug-7, at 12:32, Glen Barber  wrote:
>=20
>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>=20
>> I honestly do not have any idea where the problems you are seeing are cre=
eping in.
>>=20
>> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure how t=
o proceed otherwise.
>=20
> My guess is that if the release/tools/arm.subr line:
>=20
>              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s=
2
>=20
> was instead (note the added -b use):
>=20
>              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k ${=
mddev}s2
>=20
> then the line:
>=20
>              chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>=20
> would work as expected and things would still be aligned:
> no aliasing of BSD vs. freebsd-ufs. (In part this is by
> prior steps already having achieved alignment of BSD.)
>=20
> But I do not know how to classify doing so: Work around?
> Known required-procedure for -L rootfs to correctly
> identify the the freebsd-ufs /dev/${mddev}s2a ?
>=20
> Absent better information from folks that know more, I'd
> suggest trying such an adjusted release/tools/arm.subr
> next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in
> place, if such an experiment can be reasonable.
>=20
>> Glen
>> Sent from my phone.
>> Please excuse my brevity and/or typos.


From nobody Sun Aug  7 22:51:35 2022
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 4M1F2F1PY6z4Y3cs
	for ; Sun,  7 Aug 2022 22:51:49 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.163])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1F2D5THgz3fs1;
	Sun,  7 Aug 2022 22:51:48 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1659912701;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=BdTelD50G7EK5G7Qhs/TBKUTJubJrTuqmDcqKaXgWEI=;
    b=pwZ5vYFcCx/DFgzq7XN6FF0RIqVaJsKP7lTk4r+hPSP7SqaoHwBYj18NzSAACLJP59
    YUULHW+sq6UGws+LrJtsna1Cz3ejkIe1tCVB5kvA1BsyKsaZW5I6dlSCBQj3O4ICd7vt
    gQXoyeCWgkOHhhr97wXecdie7/JcJEkTeVHBEWxne762qHZDZP2uJDXgzwfGAuHZpnmB
    ZcTFhhayC7hVtkuwa56NvfWMpnHTcIjOdlHBSFUnvm/f4bARY9hVHbZ9VxytNHy4oKBH
    I4LOtCqYkdiJ/AgiH7mVy9S0AkWEEbPAHXHTY1SSEiQR4pU/h6z1UfZ4DZ3LaSnwFk9i
    CWIA==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id q0201fy77Mpeths
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Mon, 8 Aug 2022 00:51:40 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.189.198.217])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 9FD8763AD1;
	Mon,  8 Aug 2022 00:51:38 +0200 (CEST)
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.15\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: "Dr. Rolf Jansen" 
In-Reply-To: <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com>
Date: Sun, 7 Aug 2022 19:51:35 -0300
Cc: Glen Barber ,
 Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 Mark Millard 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com>
References: 
 
 <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
 <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com>
 <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M1F2D5THgz3fs1
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 07.08.2022 um 19:16 schrieb Mark Millard :
>=20
>> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen  =
wrote:
>>=20
>>> Am 07.08.2022 um 16:50 schrieb Mark Millard :
>>>=20
>>> On 2022-Aug-7, at 12:32, Glen Barber  wrote:
>>>=20
>>>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>>>=20
>>>> I honestly do not have any idea where the problems you are seeing =
are creeping in.
>>>>=20
>>>> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure =
how to proceed otherwise.
>>>=20
>>> My guess is that if the release/tools/arm.subr line:
>>>=20
>>>            chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>>=20
>>> was instead (note the added -b use):
>>>=20
>>>            chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a =
64k ${mddev}s2
>>>=20
>>> then the line:
>>>=20
>>>            chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>>=20
>>> would work as expected and things would still be aligned:
>>> no aliasing of BSD vs. freebsd-ufs. (In part this is by
>>> prior steps already having achieved alignment of BSD.)
>>=20
>> =46rom a strict mathematical stand point of view, -a is not necessary =
when using -b with an aligned value.
>=20
> "-a" controls more than the start offset: also the size.
>=20
> QUOTE
>               -a alignment  If specified, then the gpart utility tries =
to
>                             align start offset and partition size to =
be
>                             multiple of alignment value.
> END QUOTE
>=20
> I expect your statement would at most apply to the start offset, not =
to
> everything "-a" does.
>=20
>> Personally I don=E2=80=99t use the -a option of gpart anymore since =
it started to do funny magics in front of face. If I remember correct, =
gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, =
I align all my storage media by employing -b with a reasonable value.
>>=20
>=20
> I've no clue of the specifics that you are referencing and so can not =
check.

It started at unexpected offsets and then left unexpected space at the =
end - sorry, I don=E2=80=99t use -a anymore for years, and I don=E2=80=99t=
 remember the very details.=20

That said, why then would we use -b in addition to -a, if -a would show =
the expected behaviour on its own. That is because either -a adds some =
"funny magic" to the logic, that is stated in the man file, or there is =
a bug in gpart.

Anyway, using -a and -b together bears the danger of the equation being =
overestimated, namely in the case base is not a multiple (incl. 1) of =
alignment. Although, that is not the case with your suggestion. -b 64k =
-a 64k is OK.

Finally, I still wonder what might be the technical reason for aligning =
the size.

Best regards

Rolf=

From nobody Sun Aug  7 23:06:36 2022
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 4M1FMZ0KGVz4Y5MD
	for ; Sun,  7 Aug 2022 23:06:50 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [81.169.146.167])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1FMX6yrzz3hJ2;
	Sun,  7 Aug 2022 23:06:48 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1659913601;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=3Itu8SpEDOKHTgBfS1L2LWEA3ei3kXvMwdRl13+jgZ8=;
    b=PFu1mspn99D3VlLAGLg0wKkaFmTCWtQLJ4wCbyiv6MYb5Xp6AssjoEtb14fBm6hanh
    xPGB6Rt7IqXMd+5RMOSAB5hX/Jv47iceqh30LIS4Pvi/jCAAlvUTMPj/B0cgw+YewJx0
    1Sd7JUblonznODdyauZvK1rO/GvfHIueBMfXRKleX1sIGNQ4OvAaXOFRaLXAK+Nd6b9F
    v+mIq0GO/VSkeBYUVJjBsltuQCJWucja1LxEcic/VwlRVS0D9aQkWuLFZqMgb9yd4gZF
    a2524FQF68BgtBZyxz5ct89EItlOOIESqwlQcsQ20CDv7RxU7Zs+u2NGfeEgrFHXQa0C
    tfAQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id q0201fy77N6ftiL
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Mon, 8 Aug 2022 01:06:41 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.189.198.217])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id A471C63A78;
	Mon,  8 Aug 2022 01:06:39 +0200 (CEST)
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.15\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: "Dr. Rolf Jansen" 
In-Reply-To: <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com>
Date: Sun, 7 Aug 2022 20:06:36 -0300
Cc: Glen Barber ,
 Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 Mark Millard 
Content-Transfer-Encoding: quoted-printable
Message-Id: <71BFB117-151A-4970-A9B3-9BCD14336A64@cyclaero.com>
References: 
 
 <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
 <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com>
 <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com>
 <6483BD0C-AFDF-443D-BEA2-9F599C9B8C07@cyclaero.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4M1FMX6yrzz3hJ2
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=PFu1mspn;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 81.169.146.167 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	RCVD_IN_DNSWL_LOW(-0.10)[81.169.146.167:from];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[freebsd.org,bsdimp.com,gndrsh.dnsmgr.net,yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	DMARC_NA(0.00)[cyclaero.com];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 07.08.2022 um 19:51 schrieb Dr. Rolf Jansen =
:
>=20
>> Am 07.08.2022 um 19:16 schrieb Mark Millard :
>>=20
>>> On 2022-Aug-7, at 14:51, Dr. Rolf Jansen  =
wrote:
>>>=20
>>>> Am 07.08.2022 um 16:50 schrieb Mark Millard :
>>>>=20
>>>> On 2022-Aug-7, at 12:32, Glen Barber  wrote:
>>>>=20
>>>>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>>>>>=20
>>>>> I honestly do not have any idea where the problems you are seeing =
are creeping in.
>>>>>=20
>>>>> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not =
sure how to proceed otherwise.
>>>>=20
>>>> My guess is that if the release/tools/arm.subr line:
>>>>=20
>>>>           chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>>>=20
>>>> was instead (note the added -b use):
>>>>=20
>>>>           chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a =
64k ${mddev}s2
>>>>=20
>>>> then the line:
>>>>=20
>>>>           chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>>>=20
>>>> would work as expected and things would still be aligned:
>>>> no aliasing of BSD vs. freebsd-ufs. (In part this is by
>>>> prior steps already having achieved alignment of BSD.)
>>>=20
>>> =46rom a strict mathematical stand point of view, -a is not =
necessary when using -b with an aligned value.
>>=20
>> "-a" controls more than the start offset: also the size.
>>=20
>> QUOTE
>>              -a alignment  If specified, then the gpart utility tries =
to
>>                            align start offset and partition size to =
be
>>                            multiple of alignment value.
>> END QUOTE
>>=20
>> I expect your statement would at most apply to the start offset, not =
to
>> everything "-a" does.
>>=20
>>> Personally I don=E2=80=99t use the -a option of gpart anymore since =
it started to do funny magics in front of face. If I remember correct, =
gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, =
I align all my storage media by employing -b with a reasonable value.
>>>=20
>>=20
>> I've no clue of the specifics that you are referencing and so can not =
check.
>=20
> It started at unexpected offsets and then left unexpected space at the =
end - sorry, I don=E2=80=99t use -a anymore for years, and I don=E2=80=99t=
 remember the very details.=20
>=20
> That said, why then would we use -b in addition to -a, if -a would =
show the expected behaviour on its own. That is because either -a adds =
some "funny magic" to the logic, that is stated in the man file, or =
there is a bug in gpart.
>=20
> Anyway, using -a and -b together bears the danger of the equation =
being overestimated, namely in the case base is not a multiple (incl. 1) =
of alignment. Although, that is not the case with your suggestion. -b =
64k -a 64k is OK.
>=20
> Finally, I still wonder what might be the technical reason for =
aligning the size.

PS:

Now I am in nit picking mode - "... the gpart utility tries to ..."  =20

Don=E2=80=99t try it, do it! Otherwise, hasta la vista, baby!

Hlv,b is meant to the -a option, and not personally.


From nobody Mon Aug  8 17:45:53 2022
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 4M1kBz1Jw3z4YdZG
	for ; Mon,  8 Aug 2022 17:46:03 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1kBx6sN6z3SHX
	for ; Mon,  8 Aug 2022 17:46:01 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 278Hjrmw049948;
	Mon, 8 Aug 2022 10:45:53 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 278Hjrn2049947;
	Mon, 8 Aug 2022 10:45:53 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202208081745.278Hjrn2049947@gndrsh.dnsmgr.net>
Subject: Re: FreeBSD on Samsung Chromebook ARM "SNOW" model XE303C12
In-Reply-To: 
To: "M." 
Date: Mon, 8 Aug 2022 10:45:53 -0700 (PDT)
CC: Mario Marietto , John F Carr ,
        "freebsd-arm@freebsd.org" 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4M1kBx6sN6z3SHX
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net
X-Spamd-Result: default: False [-2.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,mit.edu,FreeBSD.org];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[dnsmgr.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> You can try checkout release/12.3.0 back and compile the chromebook kernel
> for now.
> 
> make TARGET_ARCH=armv6 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel

Last time I played with a Chrome SNOW it had issues with keyboard
interrupt storms.  Using an external USB keyboard made it possible
to get logged in and do a few things, but I found this rather annoying
and abondoned the use of that machine in favor of a little Acer 1410.

> 
> 
> ne 7. 8. 2022 v 20:44 odes?latel Mario Marietto 
> napsal:
> 
> > It seems more complicated than I thought.
> >
> > Il giorno dom 7 ago 2022 alle ore 19:46 John F Carr  ha
> > scritto:
> >
> >> I have one of those Chromebooks but I have not tried to boot FreeBSD.
> >> The wiki page is obsolete.  It references a configuration file
> >> CHROMEBOOK-SNOW which was removed in 2019 by the commit below.  I don't
> >> know if the Chromebook kernel was in the "not working" category or
> >> "switched to GENERIC" category.
> >>
> >> commit 9a042e7d03ae13425132966cd3f3416775157aed
> >> Author: Emmanuel Vadot 
> >> Date:   Wed Apr 10 19:27:14 2019 +0000
> >>
> >>     arm: kernel: Remove old kernel configs
> >>
> >>     Follow up to r346095
> >>     All those kernels are either not working or the release have switched
> >>     to GENERIC
> >>
> >>
> >> > On Aug 7, 2022, at 04:58 , Mario Marietto 
> >> wrote:
> >> >
> >> > Hello.
> >> >
> >> > A lot of years ago,I bought the cool notebook "Samsung Chromebook
> >> "SNOW" model XE303C12" where it seems that only ChromeOS and Linux can be
> >> installed. The specs are the following ones :
> >> >
> >> >       ? CPU: Samsung Exynos 5 Dual (5250) (Cortex A15; 1.7GHz dual core
> >> cpu)
> >> >       ? GPU: ARM Mali-T604 (Quad Core)
> >> >               ? 1366x768 screen & HDMI external connector
> >> >       ? RAM: 2 GiB DDR3
> >> >               ? The memory is not upgradable as it is soldered directly
> >> to the board
> >> >       ? Disk: 16 GiB SSD (connected to eMMC)
> >> >               ? SD & USB expansion slots
> >> >       ? WiFi: 802.11 a/b/g/n
> >> >               ? USB slot can handle Ethernet dongle
> >> >
> >> > I'm trying to look on Internet to understand if I can install FreeBSD
> >> without having all the troubles explained here :
> >> >
> >> > https://wiki.freebsd.org/arm/Chromebook
> >> >
> >> > Which options do I have to have a fully working FreeBSD system on that
> >> machine ? If it can't be installed natively,maybe these two options are
> >> feasible ? :
> >> >
> >> > 1) to virtualize FreeBSD using qemu and kvm
> >> > 2) to install FreeBSD using the crouton chroot method ?
> >> >
> >> > What else ? What do you think ? Maybe you know some specific tutorial
> >> that's more updated and that can allow me to install freeBSD on that
> >> machine making almost everything work as expected.
> >> >
> >> > --
> >> > Mario.
> >>
> >>
> >
> > --
> > Mario.
> >

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Tue Aug  9 18:06:14 2022
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 4M2Lc71RjQz4YjZW;
	Tue,  9 Aug 2022 18:06:31 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41])
	(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 4M2Lc55NK7z3LJw;
	Tue,  9 Aug 2022 18:06:29 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ed1-f41.google.com with SMTP id w3so16177670edc.2;
        Tue, 09 Aug 2022 11:06:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc;
        bh=rzDGOXSJ4uuw/0ccw/r4aB3KQrA+4wGcWWEZ7zJIs30=;
        b=xocnNyjZ7PncKdDOrlzeAM3wB/iMk1UTMvEqKli6sSLeiww45tjb01jOBNNkH8JsuU
         Hvd4fQvT4DK3EkCTixEfpY5oMIbe2dhUYX5U2xbC3g7uRRRKPOvoz5LByfwR78EkP2w9
         P+1QhUsrD/Rhx1eJUWZYBehev6v06th/Dg5BHA35EgkcFJaHQQ3jBCfcVMY09kIxjs1w
         dDq2XB32NQcZgUZwyuZ+rnXlWRkyEBSE1/oLddIZm59E8VItkIWo4yiNiu+xXm+hy4E+
         fslQBIZCv3xLRF8UuvQsaNdzuaxXsLX7Q1FK4N9+K05PR7qr1HH28EV9QD1q7cdQd2yR
         jsGA==
X-Gm-Message-State: ACgBeo0Ozq4pTKT/qBuY+Zof4nvdd0EUyE6BNQz1+KNPsXacpjauThzo
	eTBR94Coa9GMpHaeRaGdUnIwohPGzb+Gx4/saHk/JiXMYME=
X-Google-Smtp-Source: AA6agR4ajXhg5R7hs9Ep2mpj2bGYGynsOSrq1BqjE+V+5zCNEjK9XAod1MJY//UXaeWTC1eRP1RnDV+83dSYp4p7828=
X-Received: by 2002:a05:6402:27d2:b0:43e:3ff6:ad58 with SMTP id
 c18-20020a05640227d200b0043e3ff6ad58mr22607256ede.234.1660068387315; Tue, 09
 Aug 2022 11:06: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: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org>
In-Reply-To: <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org>
From: Ed Maste 
Date: Tue, 9 Aug 2022 14:06:14 -0400
Message-ID: 
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
To: Glen Barber 
Cc: Mark Millard , Warner Losh , 
	"Rodney W. Grimes" , 
	FreeBSD Hackers , freebsd-arm 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4M2Lc55NK7z3LJw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
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)[-0.996];
	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-hackers@freebsd.org,freebsd-arm@freebsd.org];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.41:from];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.208.41:from];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_CC(0.00)[yahoo.com,bsdimp.com,gndrsh.dnsmgr.net,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 7 Aug 2022 at 18:43, Glen Barber  wrote:
>
> Will do.  I=E2=80=99ll commit the suggested change to main tomorrow.
>
> Thank you for your vigilant investigation.

Shall I commit the enforce_chs check now?
---
commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a
Author: Ed Maste 
Date:   Tue Jul 19 16:47:49 2022 -0400

    release: ensure enforce_chs sysctl is 0

    We do not want CHS-based alignment for VM or SD card release images.

    Sponsored by:   The FreeBSD Foundation

diff --git a/release/tools/arm.subr b/release/tools/arm.subr
index 6e4ae731a0b9..01c5303cd4e1 100644
--- a/release/tools/arm.subr
+++ b/release/tools/arm.subr
@@ -62,6 +62,10 @@ umount_loop() {
 }

 arm_create_disk() {
+       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; then
+               return 1
+       fi
+
        # Create the target raw file and temporary work directory.
        chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
        if [ "${PART_SCHEME}" =3D "GPT" ]; then

From nobody Tue Aug  9 18:15:13 2022
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 4M2LpK1Z5gz4Yl8C;
	Tue,  9 Aug 2022 18:15:21 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M2LpK0xl1z3N9q;
	Tue,  9 Aug 2022 18:15:21 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660068921;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=wKmAGPrZc3JTHzSg0KUKiXU1myAjP1ULcgxHocVHjmg=;
	b=TfyBezOSS+QExbCdGsnqPsXCZFS+GwjJBOmu63++Gytj8+JtHyr3oKL633KZNDq7Oya0F0
	OZJdR8pntJF+YAQ/RwlsK33saHIHPM89rPYP/xbmnND0poSGj3xqWqOnWbjTirdeXi3Ucq
	PkEAUZc9mt3trKyMZKrTAveCXjHlQYmyDvuRVaccioMAeTJedpsyoLNZ8w1aEtuymMFwBy
	Hg2SczEt4xCN/2ievcLOZaXYu8YXf+hk94HsTu+PXpMZ6QYv2jrAGs/11Wp08cZmG2YS/e
	229PBvXgHvm2ydMWXG0i0baTratn29kPD9rJCZvGhPxi8xCDBnwMHDLupgRUvg==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id 74B2816220;
	Tue,  9 Aug 2022 18:15:20 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Tue, 9 Aug 2022 18:15:13 +0000
From: Glen Barber 
To: Ed Maste 
Cc: Mark Millard , Warner Losh ,
	"Rodney W. Grimes" ,
	FreeBSD Hackers ,
	freebsd-arm 
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
Message-ID: <20220809181513.GG30607@FreeBSD.org>
References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
 <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org>
 
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/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="JO68zLCmjMElvUWJ"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660068921;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=wKmAGPrZc3JTHzSg0KUKiXU1myAjP1ULcgxHocVHjmg=;
	b=ueJLJZXGdYy+1fetMMfTTzv5zLwWws8ww6TgNA7KcTZ3Q4Xhi85R8o4+4TQ8PR3VF99hJJ
	946fUqgFn/JgB2uRZdLHtRQfE1uFw0q6exfjgD+LOxZgRD0MeoIj6o5+yBk6RmtAg/6P++
	cZlN/9i8/+c7uWqh5Xfp3ngsbSBxTHulvhThFyW6xXvurOxc2h98p66PWEyVtA5dCqB9F2
	ZyhDljUkOmngECacuP/Nw/HLcHVa25ln0wwfERsS3DQ1nFDIdADLKDbPdzMmnYYAqq1k14
	HSmS28K0C2G4WI2uXR5fQf9oXihccZkWOFZif1zJfysitdUQp39Pc30QPsuJVQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660068921; a=rsa-sha256; cv=none;
	b=rMMSVo/jvzfdFpH7oV2+2tphdbCbE4bhLospwO8rYoGTjYjHX4zyKWdold0+ogECOIJ1T0
	r3rpSij3iDqsCHDPb+eVoxUQGlvXaEz5npq6GsDzBzUjoaXeH5MP9DPGklfEYLc+EW2rBI
	eitAjUzAfF0KEkVQAmZmgNG/FKPd668oD7fPucgyw0trRPmzJpjG5VPD2ueHqtX3L3l8k4
	yTQ8OKVlMEm+M2hdZ0kI8yZBwTQYzbNpAUn3zkF1GGSISCNGEWWOEQk61ITHZDQoA+NsUN
	gmi8G56taAuGRD3awF4jU/YVUQ7Hpnvd5DqQ6ynmuzx84xZnrqXpjeBmq52rUQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--JO68zLCmjMElvUWJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote:
> On Sun, 7 Aug 2022 at 18:43, Glen Barber  wrote:
> >
> > Will do.  I=E2=80=99ll commit the suggested change to main tomorrow.
> >
> > Thank you for your vigilant investigation.
>=20
> Shall I commit the enforce_chs check now?
> ---
> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a
> Author: Ed Maste 
> Date:   Tue Jul 19 16:47:49 2022 -0400
>=20
>     release: ensure enforce_chs sysctl is 0
>=20
>     We do not want CHS-based alignment for VM or SD card release images.
>=20
>     Sponsored by:   The FreeBSD Foundation
>=20
> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
> index 6e4ae731a0b9..01c5303cd4e1 100644
> --- a/release/tools/arm.subr
> +++ b/release/tools/arm.subr
> @@ -62,6 +62,10 @@ umount_loop() {
>  }
>=20
>  arm_create_disk() {
> +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; then
> +               return 1
> +       fi
> +
>         # Create the target raw file and temporary work directory.
>         chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
>         if [ "${PART_SCHEME}" =3D "GPT" ]; then
>=20

Good question.  Do we still want to ensure it is set to '0'?  I'm a bit
confused from the back-and-forth on the original thread.

If we do want to ensure it is set to '0', yes, please go ahead.

Glen


--JO68zLCmjMElvUWJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLypCwACgkQAxRYpUeP
4pPj4A//fpME+l0kRIO41QC6b/TFUDVGi7cNITaNjYr27uaqKVyub9A1Hx4OlUuj
VpIZhjm7zmvdscd02HZKqg5LiZyNopH2fd4Y9pXvFBoUamBqX6QwYzUlPN6WKkEF
wXwcquYFZ355F3fN/2iJTkyvMEbhzcHRods+IupJkOC0Lbfxg4hXkv/9Ro2nEw0D
uITxwgpfQUL9v/l7D+gd7XL/6HRY+Hx8s4LUt4GZDMqEWZX9r5d1GUHEZAEu3AWf
yWuFMDsxygI3U2n+zrSG9L+kDEKKAzrORGVfDiAkN5Y/kIkSueitZer0Wyk0Kf+W
InhZvFZZvfBBRw0b5ZUWQRoNXVrSydRFEAKrxOvh1uaC3WTZuc44lJVttuL0wLIW
6m2lJU9hvGJSYwv9xd3lwak9JXjYIfc0GhrpvPjIYaIQdUL7ahsvExJrSvlWYlm+
Ncil0a32gb0uwPJQPxFwdpH9DUmukJd2JfeenSIoaNYFWsUD6pJ2o9oIsNrTr4ZE
ffDK+0qFhS2dQfshZwK/E4GNBinLeuJPsBBr5/dVUC2LIs3glYUwcTpkwNiLZZAS
v/Qrt6ytjXwmjAvD2Xt2FU9Fvn1/44Uc/+5p0WG52g0W76Dbw3PIsknHoTKzMlE+
9EpQBP2bR6ca8eWz4qiaGxBb+LtDEGsHwMsknRcaU820h3JXvYA=
=Rsh+
-----END PGP SIGNATURE-----

--JO68zLCmjMElvUWJ--

From nobody Tue Aug  9 18:55:12 2022
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 4M2MhS0Mknz4YsQm
	for ; Tue,  9 Aug 2022 18:55:20 +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 4M2MhQ4ykrz3WWm
	for ; Tue,  9 Aug 2022 18:55:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660071316; bh=NRgVoKv5+OL81YH/b6LG64w+kMwiHk7+qpARnEL4TxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=q8snKVIalyJJJgiK0t7P3YKEcC5XG8KfG9PXlo5po6cn0yyu03713WqyUcEKhOrdCgI/GuyfYfGzIFOlZRGdFxrqNE/dgUOcIGb5DdIkPo3lxqW8njrUrajJ7aT0eAPN0MwtF8vMQNN7yYZV3KZtNwbjUoyIZ20ll4ePblC0TOhr7D4cmyElOehYHPOFTrd1FGcyWbRl6g8l03V/T3ZA0pAaOzMoQ2Z5i1I1QtU3L7WeG6kxAATUOp4fI+HpiMdyMnxTBDIGhLcXXVhRWifHGmwzkFndCazzxhbUQSN5FV46Ysq6N2kbxpEhCWEE/9Seh++PJ7Qs9zH8B0hIbBGXjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660071316; bh=A674o1kYvDojDoa0atcVRgSbp6Ku4sSU+GPaJ3/rAZn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=f6s1iCoG43j21OHXgXm6gGxi6GWI31RNNhuysM5d6oxd21QKLaKSzHIJ5Mj36IzS9WYuZP38dQQmBq8CLsNnywRCNopHhILubjYxp7q6jgSHrdIfiEqqzDeuMwAASbWkwuy42NH53hJ8KBzzO3NYmht1hwt09LxnNjI7GW4g2RYXuK8rfsnCgevSDEfXLIxUj6kc43zibetVJ66LeMH2UD6CqcvADFm7BQb/mBjHswhhNavclvI31N1KMGMaPPcRVgXJDMNpVpxPvYnoHJzQPdilsfLcyRpGTe2o6LmAFEFVk0u5pYf37uWvtl3ICM/hoUo1Z8XBluALp6DTLRv2Vg==
X-YMail-OSG: 0obiDwcVM1mzOCpp7kv0KHlHDaVLRTLQ9scDxAe7Il3lJGre_KRHfkmYNhC6ICM
 3Ifkx7i0aiShx99zNBD1hh28JsshRFtdiqDPNLAtUpBt9R9cCXnQJ0a1JE2qemvE3SrkCnC0Sm1Q
 ZqGew_3k3fi0FaD5NYnoa4RZwqfzxmp_rFUQ7bKQuFYvCUARdBFfqUdQR1CGv7kRTy61DvL3_eEg
 6ysfrEcOkBw.N5ua5ylnvv3dhgg2vp6lkGQmgQQ5Xue1GZXyn96MsNT4xM_ars6I6Ixy4ck9C_P7
 zX6Q31P7aiFGEj6etsgAS2eb7iuqyiKAW63kWWQG01E_gusjliNvA4hpjTfgtX4PEpw2uiJE._5o
 Jq8qiZLOLtQo7OWFfySscvihbBzO7cINEM1be.E3vS4rG.xzcpXbhAfu1jnJNti5EVLDc.cSJnc1
 7IfTvnpNY2VCoDOq3cSUejrhX7jgzM18O.5XqC5fSEPpVK1VKCMMINxz8drkzeSdwk7c6Vk2DXqG
 VOTPCzxVeTyOD3M1HIIDfA3lcMJibMhEt6D7xHFztR8LYepv1TycQSQ7u1xnpxRRB8kjit0WzoPn
 zm74NoupRyjgISyVvb8z5AV9wO1SP2JYBO6azfOCbVXwkL6KkUwNvZVF9_q.drkBLTpjTPUS_MYd
 dd3v4oVzINAt6UqEuoaghC7LWnQ7fkh_F4vIMp6qLTDAJaARNO3hr7CKxcfgYPMj8MJw3z91XnEz
 10H0ft9yQqtYXMyHIQ06sn_0g2CFXFZSrlP.mDLD9on2vFEU_z_6dgji9ssZFWdJ7_MtkPVaL7I1
 LDpeE0zZx7c6r7ee5kAjrmAIxN3Ic4umA54p3zgOIX7emgBGq2ZGemniYowAu7oEqvUGrBxODZE_
 keVMLyibSGgM_OTT8p8xQPIUrp0UZAFiIgosAjOp.p4hGHDCRXYnSDACVVz_zXTgQ5vxAeldVoHu
 kLHcIG_xfI.rQKnSyOwOAWo3tme178K9f23g307lMurwDZy2n1.8xKSnbiiHLIJfqqh8xpYlAL2r
 eV_F23oTxqO8oM_fsaZ3tbowpZj43HZJKncwl.qhZ8o8vuFKN3BEB9yc37EfA7e5_gs4DQd.LRi0
 XBduCsbC1K_lLhMTnYVDziiS78035IQdc7TdhH6lehfXUnrOw5F.57.D_FroCm2j3kcKnmKMBw3Q
 1N.GbG4.uOFO1uFMEloWGvh_JZA75cifmvjEmRTMGFGgXjuAp_yHPq9YNPCtSdQl_Df0zRqhmLHo
 p20K.QS7bbJE8J3hQOYjKEULnfiBtvTFNYi0.jNtdmLvv3wnoF6ItVhKxCA91lFGkuRP2p8_cu3l
 _qmC6WQ1Kii6JuCyQG0bc3F3qWWt7yvetQRPQ_btljyt6WDs6fE_7WdzwoYYJMejNVyT0Bk1PGy1
 epruufnFll7rQv_u04hx5WS.kPuqISdKWhoNBsCNqJ2F08U4JjIeit7q2YDqtBtn8JlI8xJ4AVTX
 vyFMKcuXACjaQ5zY1iogNMaJoGSNccPeJ16rWgF0isIJGhV8i5TI1KLp8NXMNvynNO1sS8MwQIpc
 R53cGbbVKvagv88jmKNGKbS73rbbun5Ul3At3cJNX7EecxDTtdp6NAh2H.PlY556z1inAaVzM0PK
 cHxhAdffkW4LNdg_joKHwLoLIiGAOh6oxLVrz0T7awzj0T9iq8VnDSiWoC3WJciJz2pwYqt7I97g
 ijT3S1IJvKVBuRJf_xTa5dMKxBBC_ZIEAtK4ohOd72UEn0nIuQNHrE1kwlcMxVEVeKM5z8qrvWLS
 NQP3ihb7V4UiJjQ3drh6hm7QEGRcVna2f3iPr6GIGGwzuNKwGcjKL4AbkseJqADnQDvQf7VmVGtf
 Fn3xvRFSxFpXXg7T.wDtXfH0MECw4cM8kWX6QnvpoMqYcSBDn1KIlabE57uRBSiwj5cQx1zqgMK0
 UXafsjUQZaZ6FBjISjk4FBL01EPb96hlCzNadYcGCbb7_1eu5Qh0CvLzUZzxvw46XlJa.Z1BivI_
 cDJ.zj.xgeln4jOGpcQL7mm6eufHn.LlCV5NKEN11jwWZ0RuJuURUsX7YJ1K16TwyAeZLbDoeUC3
 alk.BENx2QlVPmnLmM.0KwvWkyV9W7ozkARckL9wv2Jve2mc9n8SeTZieviWS0M.xDoTcPs0YzyZ
 NK6sok8zzyWsnaEWKB.hX3oFIVWcOJAd7eb0dln_vbLbUDVjeJY.4ySBDl_V6Z0I41hCwrYBYn5b
 KyskpxPaI_Hd1S9NKhZZrhRs.uYyeUarwoC3_43aQHCMj1MXzFiwxjC5y6pPolgdp2z7_TiFPEdG
 OUOwbBTI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Aug 2022 18:55:16 +0000
Received: by hermes--production-ne1-6649c47445-zp4l8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 67d7542a3b0ff56c91b8a724acf0e36c;
          Tue, 09 Aug 2022 18:55:14 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: Mark Millard 
In-Reply-To: <20220809181513.GG30607@FreeBSD.org>
Date: Tue, 9 Aug 2022 11:55:12 -0700
Cc: Warner Losh ,
 "Rodney W. Grimes" ,
 FreeBSD Hackers ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com>
 <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org>
 
 <20220809181513.GG30607@FreeBSD.org>
To: Glen Barber ,
 Ed Maste 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4M2MhQ4ykrz3WWm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=q8snKVIa;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.23 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_MEDIUM(-0.74)[-0.741];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Aug-9, at 11:15, Glen Barber  wrote:

> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote:
>> On Sun, 7 Aug 2022 at 18:43, Glen Barber  wrote:
>>>=20
>>> Will do.  I=E2=80=99ll commit the suggested change to main tomorrow.
>>>=20
>>> Thank you for your vigilant investigation.
>>=20
>> Shall I commit the enforce_chs check now?
>> ---
>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a
>> Author: Ed Maste 
>> Date:   Tue Jul 19 16:47:49 2022 -0400
>>=20
>>    release: ensure enforce_chs sysctl is 0
>>=20
>>    We do not want CHS-based alignment for VM or SD card release =
images.
>>=20
>>    Sponsored by:   The FreeBSD Foundation
>>=20
>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr
>> index 6e4ae731a0b9..01c5303cd4e1 100644
>> --- a/release/tools/arm.subr
>> +++ b/release/tools/arm.subr
>> @@ -62,6 +62,10 @@ umount_loop() {
>> }
>>=20
>> arm_create_disk() {
>> +       if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; =
then
>> +               return 1
>> +       fi
>> +
>>        # Create the target raw file and temporary work directory.
>>        chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev}
>>        if [ "${PART_SCHEME}" =3D "GPT" ]; then
>>=20
>=20
> Good question.  Do we still want to ensure it is set to '0'?  I'm a =
bit
> confused from the back-and-forth on the original thread.
>=20
> If we do want to ensure it is set to '0', yes, please go ahead.
>=20

Hopefully this week's experiment with explicitly avoiding BSD
and freebsd-ufs having the same offset inside BSD (avoiding
both offsets being zero) will allow the UFS labeling to work
right: freebsd-ufs being tied to a unique offset inside BSD.

I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to
cause the offsets to be different is reasonable, despite that
it happens to make them distinct: the freebsd-ufs offset is
better controlled explicitly elsewhere.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Aug 10 23:02:57 2022
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 4M357n485pz4Z2vD
	for ; Wed, 10 Aug 2022 23:03:01 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.52])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M357m36JNz3Kqs
	for ; Wed, 10 Aug 2022 23:03:00 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1660172578;
    s=strato-dkim-0002; d=cyclaero.com;
    h=Message-Id:In-Reply-To:To:References:Date:Subject:From:Cc:Date:From:
    Subject:Sender;
    bh=Y/t4JuS2ANjEbllIW70tRRq3VYAZpnepCepxk8CX9gI=;
    b=Bae09qfQwlxUZF8Ejr3pu8EUAQ078b1ccoilREo9yXDSlPGFXkD7s04BG3ACWD8qoj
    +q57dNn1DycUYhn0hyxN8M+3D1Kbfk8DiSMFW+1KdQlnUMKGzbpuknfbVv3stxY8w6xl
    v8Ph5O4eQ/gKPSqSsTvq5gg3g09UkRSnlW4MgkbZwAl3tf4pAnsWXC6PYnRXdFwElzzM
    T4ic5PAtVvzt1GyO7lwIngKsFjOirAT3aSabfUdPbQoDz+Xu58nrknICHUi/oeZhiPO1
    /spAXQ8kyIKbWk0XYCm/8oEqjBYmpNDZ0Izq8P3UaLzIsfDqSFT5ZiXUV3O4XKBPp56a
    x9JQ==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id q0201fy7AN2w6Wo
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate)
    for ;
    Thu, 11 Aug 2022 01:02:58 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.188.53.38])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id CB18A63B4E
	for ; Thu, 11 Aug 2022 01:02:57 +0200 (CEST)
From: "Dr. Rolf Jansen" 
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 12.4 \(3445.104.15\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
Date: Wed, 10 Aug 2022 20:02:57 -0300
References: 
 
To: freebsd-arm 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3445.104.15)
X-Rspamd-Queue-Id: 4M357m36JNz3Kqs
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cyclaero.com header.s=strato-dkim-0002 header.b=Bae09qfQ;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-rj@cyclaero.com designates 85.215.255.52 as permitted sender) smtp.mailfrom=freebsd-rj@cyclaero.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FROM_NAME_HAS_TITLE(1.00)[dr];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24:c];
	R_DKIM_ALLOW(-0.20)[cyclaero.com:s=strato-dkim-0002];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE];
	RCVD_IN_DNSWL_NONE(0.00)[85.215.255.52:from];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[cyclaero.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[cyclaero.com];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I just a BeagleBone Black which was in my drawer for more than a year or =
so. I partitioned the internal flash (here mmcsd1) manually some years =
ago. The u-boot stuff was still quite tiny at that time. Now look what I =
found:

=3D>      63  62410689  mmcsd0  MBR  (30G)
       63        25          - free -  (13K)
       88    102312       1  fat32lba  [active]  (50M)
   102400  62308352       2  freebsd  (30G)

=3D>       0  62308352  mmcsd0s2  BSD  (30G)
        0  56623104         1  freebsd-ufs  (27G)
 56623104   5685248         2  freebsd-swap  (2.7G)

=3D>     63  7471041  mmcsd1  MBR  (3.6G)
      63      961          - free -  (481K)
    1024    15360       1  fat32lba  [active]  (7.5M)
   16384  7454720       2  freebsd  (3.6G)

=3D>      0  7454720  mmcsd1s2  BSD  (3.6G)
       0  7454720         1  freebsd-ufs  (3.6G)

=3D>      0  7454720  ufsid/5c9c24b911822409  BSD  (3.6G)
       0  7454720                       1  freebsd-ufs  (3.6G)

=3D>      0  7454720  ufs/system  BSD  (3.6G)
       0  7454720           1  freebsd-ufs  (3.6G)

ls -l /dev/ufs

crw-r-----  1 root  operator  0x6a Aug 10 17:52 system
crw-r-----  1 root  operator  0x56 Aug 10 17:52 SYSTEM
crw-r-----  1 root  operator  0x6d Aug 10 17:52 systema

The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE on =
/dev/ufs/SYSTEM, and /dev/ufs/SYSTEMa does not exist here. While I see =
/dev/ufs/system and /dev/ufs/systema for the some years old freebsd-ufs =
slice on the internal flash.

The BBB starts without problems from the internal flash once I remove =
the SD card.

I just partitioned another SD card without the swap partition, and after =
applying newfs -njU -L rootfs dev/da0s2a, I see /dev/ufs/rootfs and =
/dev/ufs/rootfsa. Both can be mounted and work without problems.

I tend to believe now, that we don=E2=80=99t see a bug when rootfsa =
besides rootfs appears, but a mostly unknown feature. If this disturbs =
somehow, growfs could perhaps be enhanced to either leave some space at =
the end of slice 2 or optionally add a swap-partition of size X. Both =
measures would effectively prevent the additional label rootfsa.

> Am 07.08.2022 um 16:32 schrieb Glen Barber :
>=20
> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds.
>=20
> I honestly do not have any idea where the problems you are seeing are =
creeping in.
>=20
> Should it be set back to =E2=80=9C1=E2=80=9D?  I=E2=80=99m not sure =
how to proceed otherwise.
>=20
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>=20
>> On Aug 7, 2022, at 12:10 AM, Mark Millard  wrote:
>>=20
>> =EF=BB=BFThe oddities look like indicated below.
>>=20
>> # mdconfig -u md1 -f =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img
>> # gpart show
>> . . .
>>=20
>> =3D>      63  10485697  md1  MBR  (5.0G)
>>      63      1985       - free -  (993K)
>>    2048    102400    1  fat32lba  [active]  (50M)
>>  104448  10381312    2  freebsd  (5.0G)
>>=20
>> =3D>       0  10381312  md1s2  BSD  (5.0G)
>>       0  10381312      1  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312  ufsid/62ed01f3345560d8  BSD  (5.0G)
>>       0  10381312                       1  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312  ufs/rootfs  BSD  (5.0G)
>>       0  10381312           1  freebsd-ufs  (5.0G)
>>=20
>> So: ufs/rootfs apparently identifies the BSD instead of the
>> freebsd-ufs . Same for the ufsid/* . This leads to:
>>=20
>> # gpart show -p=20
>> . . .
>>=20
>> =3D>      63  10485697    md1  MBR  (5.0G)
>>      63      1985         - free -  (993K)
>>    2048    102400  md1s1  fat32lba  [active]  (50M)
>>  104448  10381312  md1s2  freebsd  (5.0G)
>>=20
>> =3D>       0  10381312   md1s2  BSD  (5.0G)
>>       0  10381312  md1s2a  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312   ufsid/62ed01f3345560d8  BSD  (5.0G)
>>       0  10381312  ufsid/62ed01f3345560d8a  freebsd-ufs  (5.0G)
>>=20
>> =3D>       0  10381312   ufs/rootfs  BSD  (5.0G)
>>       0  10381312  ufs/rootfsa  freebsd-ufs  (5.0G)
>>=20
>> freebsd-ufs has the unexpected label: ufs/rootfsa
>>=20
>> # ls -Tld /dev/ufs/*
>> crw-r-----  1 root  operator  0x6c Aug  6 20:19:58 2022 =
/dev/ufs/rootfs
>> crw-r-----  1 root  operator  0x6e Aug  6 20:19:58 2022 =
/dev/ufs/rootfsa
>>=20
>> Things were actually set up for ufs/rootfs naming as the
>> identification of the freebsd-ufs content, per the
>> release/tools/arm.subr commands ( from last month's
>> main-n256584-5bc926af9fd1 ):
>>=20
>>      if [ "${PART_SCHEME}" =3D "MBR" ]; then
>>              chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s =
${FAT_SIZE} ${mddev}
>>              chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev}
>>              chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F =
${FAT_TYPE} /dev/${mddev}s1
>>              chroot ${CHROOTDIR} gpart add -t freebsd ${mddev}
>>              chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2
>>              chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k =
${mddev}s2
>>              chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>>      fi
>>=20
>> Note that the newfs command references /dev/${mddev}s2a instead
>> of /dev/${mddev}s2 but the rootfs label ends up referencing
>> /dev/${mddev}s2 .
>>=20
>> Is having "0 10381312" for the md*s2 and for the md*s2a a
>> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need
>> to be moved to a different (non-zero) offset inside BSD?
>>=20
>> Or is this a different kind of bug?
>>=20
>> I'll not repeat the kinds of explorations that I reported last
>> week unless someone wants to request something.
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>=20
>=20
>=20


From nobody Thu Aug 11 03:22:43 2022
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 4M3BvX3xqsz4Y7LP
	for ; Thu, 11 Aug 2022 03:22:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4M3BvX281Tz3v4R
	for ; Thu, 11 Aug 2022 03:22:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660188165; bh=fxmdVH7koVaHYWWA6ERWNM0IfgnKS44T7eTTx6nUC1g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OFazpqKFIdUuamO6yR3bTP3ZTaeecvlUimZcw6fffoBVn7FDMdhX8oa4/QCk1upFJ9KdUNAlpKeRUNdxzOoARdWrYdXWA4K7mPDurKcZ1S0gMT399B9+8wDywEppdJvOTlIElBirPC0IZUH+VjZzHkgAhc4tX4vM4CUe0MLwsRvc4uglkb8xWprJ0O5342hz37kXqzNJgl85R1i2uXiwaFlcvJK3Scf72ecsv438/hzcWkCscCCm0u83q5yGu70tRIwMVG93KKdSIX0THNP4nFzY/wdQ0Z/pifCjwGgc/gzpQtUWjI4IcG+WCD/3RnptYwDwd9xsMdmkmEsJv2w3dw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660188165; bh=px+gA3WqItrNcHn0mM3c6aNEHXbdWpdwOwsKFOl13QM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ElNbQzhGyX9Wjmvg4M6jD57fWdMsr8KTckMAxfsyPs2D3wUiucACHulv7Cb0CY+yvRD2sfTRJJzMlFUR/CmixPM7yrLlwW08OlU97TlDdudRJeRyX+ADSQw1yspUyo4duU4dfBrjgHRbjW8CEEGquhwzNfCARTdPg43JO6K78I5pa9WgTTpU0w4vAR8gFwnAUaGmmJLs+VcQDh2XeRxEh9CYN2pPoy+xBc3T7e7E9QsvDWmjf9ACXGpN3KW2LH7gOHszBwjzR6x14pB7zWg309rWCkffKuK9bQZMvF2xqhzT58007dJd0cBk4Hb66E4kSyq13dYlfvrsXJvbKXXXeQ==
X-YMail-OSG: ahp0iX4VM1kpbNWtIP15TKBCZ8Y7nFrVdH7pzWNQrYIhBZOhLrrWpSEg2JYv10i
 HLTwgBBcwp2o8A7TCGyIefado73aej5jLy6z6TJNNrX2cI2ZpcnZVX8hWqwZU3w9h0RC9Q9ftynr
 dm8NOZhKgYYN.8a.FDvVOIO28jJg2Xj9z3iTIbSue3_v3.aEy9xsDgXWrbA5fxRiEew5OX5yeJjK
 trgWm6Q4NKLzvHA4dNf1nOuzmNi2nTdosJNwOz6qcCCwXmMwNEPPq.jNltoKpwzrkzEmu_Uob2k9
 ygCM7SWYOhQ6a8xPWMLyCHhJW2wQdHdlmj.hfG08mYotQPgSVg1UAI4kVuUPI8pP8cHWk1ytRpfG
 Db9cAc..KmH4EENwRb6CMoo.cUk5wbhPDD6jKkJTrKtLHWD3V5Y3Yqju1HAkjcx.XIZ0LipAAxv9
 adlbL29mbLOZOYTli.Gfa6SotUH3XVCmsznvHdTIminaMaZTS6CEVJ3vO8N3q42alWDeZQCerO7b
 lBoMYjLS0V86.tiUob5dsqBVHik_zDXrJwziIh4IyXK8uO3gHNaK3NL1jF.YRrkiHLcMtwaFrOPn
 1IKrAhWPWa48jfj9uJfKPnScslVD.KTB_ZT64etZfR3EYavGuiYs2wuFdGInoAV7VD0tLMUvXV0v
 mrQYXlEV0X2S7Y8aONQHIKIQ361LWjwPWHrC4Qr9PGsWj54g6zFX2WibzAxjG7PEFABhHKI6MbPH
 RtS.2XXeWmhQtocDBqM9zzj53sz8iZVN9ojt9OpU8y6BjpTwg3d6F1YEJb_AAom4X_PFGlkkfo6y
 Fet7jU9pdzNMGyxhbdP1PpzUKBPM_5zl.SVA_Wpu1imhC2iGQCwCmnsutKLwu2gvsUuFBFr6U_vy
 ibmEJE5Qy0YPEIS_D_PKG8yp6VBWFbzvzY7bbqa18ahckKKRDjOOaukjZ_vO9ScmiaFG0DFc4IP5
 EUzY.eS7yIMKTiTCSJxZSAU5QBRKFSZ72euUyLYeNcfJulUb750QaiCjxPnu7JLil6bVopHXLSDO
 g54BrvAkzZRhTJxirHmQhqf8rrBCSQnFIfkKiFNJ6tq8cXmfhvmjb7kPYoHLUwt8KeVmGKOpTDeO
 K54m7osycWSZCepOBBL4H7uo1TVRMmWIklxe9GKvBg6UnFfof3OsmTUSiZf5oZ1rUCEgDOqQA2.3
 gUealIeAIaNVe0XkV76LFYo4RQmntWKxE35rZxJ_6RR2x8TNuavArXoEUEBbsqOXSO75Qm.BCKGr
 JMRQYa2ljeHsDkX5hjLxGPWoy945EwIPmIa8f2jjt92Bz84Ny0t99g_3ykj9fAjH_oGd1EAHgET_
 rjt4lztdVp1DULaE94kU9Vjv5dElMYwojqBAyp5gDIyhv3KUl.JV4Xa1KE4s5wWsXnhTaE.09RKc
 Thsi7wOKxGm5Blj_Jfr.7w2ujVzodYfmqWt4bj793BoI4spAn1zcwb4scDS9c78clUBeUspkw7fq
 FQfaFMVY46NviIkO8fXP6a7orEBIrVy7cyz.3IizcvdNHKx.BsyhaYwthENaG9GT3BAqAQ18pZlE
 bcQ95DWVTYHCkn6ZypwwEaDCLnkTxXehnpfplHIS5BOxqopSbfwSbTURf_NzdG1At6XfAXz0AyOS
 qzUg9FC5oGH.5CE7p3hlsSVxRBimu8fRUn90TVsRlBxMXErk.aZQsTDJ.xbowdMemwBuEzTd_iBu
 tl_ppEqMrQOi.DkG4ABxZHza2.Gau6mcSePYwig9J1nwTjhu0hqOV0UMnpVa0D.Fo0T32EpkDG6F
 lu3tyQH1JMYrmp4ItIRpXNaEhSHiUGbfr5ZkndzjndZpHoXPA00JNuDisyRkES2UqWM8mFDSTIF0
 lo_j5oHIz7NagnAU1tbO61EsDPE6l1g2o95Ct0Qk61Ociu9ZC0bp32w7xsGFRT9u5vTedVAPsMGI
 DUg5_RSIVLGnlRGJ8bLYP5t_g8HWIG3CyYS6dtmpMtdns9F1xmYsXpP7ySEr.1cDfiZWGbZvIC3V
 kP.VXY.jTEQyED8N4TR1Rw2MboXTwykAiyl1WGCSWT5rbrd_eNXc2FwGRfCwlJ7k2eV__9PoBlSd
 lgP1uU24hy.TwdB_uxqNsgqJXhU5v.w15uLpOYUVvOY.h26oWNjPMpX8rlo3A1J1yrDYR.RFasKq
 IyXU8omLWy59mvIv0AwemNBZy0lYUw3pzEajBBCprcbR9UtHeT7tVR2hJtt5IgYdX2JeBEaY.XGT
 AH3eo_W9UpVXqbEe81FzuPzil_Q1mbDkW67FUVVDS93EcyAAco94uwyioff_4NixS5xv3E.Io5gR
 6IkWo
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Aug 2022 03:22:45 +0000
Received: by hermes--production-gq1-686964ccb6-kqxvm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6e5cb75874fd46ce280505b819ebcdce;
          Thu, 11 Aug 2022 03:22:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: Mark Millard 
In-Reply-To: <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com>
Date: Wed, 10 Aug 2022 20:22:43 -0700
Cc: freebsd-arm ,
 Warner Losh ,
 "Rodney W. Grimes" ,
 Ed Maste ,
 Glen Barber 
Content-Transfer-Encoding: quoted-printable
Message-Id: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com>
References: 
 
 <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com>
To: "Dr. Rolf Jansen" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M3BvX281Tz3v4R
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)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Aug-10, at 16:01, Dr. Rolf Jansen  wrote:

> I just a BeagleBone Black which was in my drawer for more than a year =
or so. I partitioned the internal flash (here mmcsd1) manually some =
years ago. The u-boot stuff was still quite tiny at that time. Now look =
what I found:
>=20
> =3D>      63  62410689  mmcsd0  MBR  (30G)
>        63        25          - free -  (13K)
>        88    102312       1  fat32lba  [active]  (50M)
>    102400  62308352       2  freebsd  (30G)
>=20
> =3D>       0  62308352  mmcsd0s2  BSD  (30G)
>         0  56623104         1  freebsd-ufs  (27G)
>  56623104   5685248         2  freebsd-swap  (2.7G)
>=20
> =3D>     63  7471041  mmcsd1  MBR  (3.6G)
>       63      961          - free -  (481K)
>     1024    15360       1  fat32lba  [active]  (7.5M)
>    16384  7454720       2  freebsd  (3.6G)
>=20
> =3D>      0  7454720  mmcsd1s2  BSD  (3.6G)
>        0  7454720         1  freebsd-ufs  (3.6G)
>=20
> =3D>      0  7454720  ufsid/5c9c24b911822409  BSD  (3.6G)
>        0  7454720                       1  freebsd-ufs  (3.6G)
>=20
> =3D>      0  7454720  ufs/system  BSD  (3.6G)
>        0  7454720           1  freebsd-ufs  (3.6G)
>=20
> ls -l /dev/ufs
>=20
> crw-r-----  1 root  operator  0x6a Aug 10 17:52 system
> crw-r-----  1 root  operator  0x56 Aug 10 17:52 SYSTEM
> crw-r-----  1 root  operator  0x6d Aug 10 17:52 systema
>=20
> The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE =
on /dev/ufs/SYSTEM,

If I gather right, this is some sort of personal setup of
FreeBSD 13.1-RELEASE . For example, release/tools/arm.subr
uses:

chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a

No attempt to create a ufs/SYSTEM label that I see.

(The gpart output above does not show ufs/SYSTEM at all.)

As stands, I can not compare/contrast the command sequences
used vs. the results across the examples.

> and /dev/ufs/SYSTEMa does not exist here. While I see /dev/ufs/system =
and /dev/ufs/systema for the some years old freebsd-ufs slice on the =
internal flash.
>=20
> The BBB starts without problems from the internal flash once I remove =
the SD card.
>=20
> I just partitioned another SD card without the swap partition, and =
after applying newfs -njU -L rootfs dev/da0s2a, I see /dev/ufs/rootfs =
and /dev/ufs/rootfsa. Both can be mounted and work without problems.

Interesting that the swap partition vs. not makes such a difference
in what labels show up, referencing where. Being strictly after the
freebsd-ufs area (if  your example gpart output above applies), that
complicates interpreting things. Just start-offset-in-BSD aliasing
is not going to be an explanation for that, for sure.

FYI:
I booted the original test snapshot. But after its initial activity,
the following reboot attempts could not complete. I sent a messy
series of list messages from exploring/learning for this, including
a sequence of adjustments that eventually got things to back to
booting.

> I tend to believe now, that we don=E2=80=99t see a bug when rootfsa =
besides rootfs appears, but a mostly unknown feature.

My test case got boot failures --after the initial boot appeared
to work and basically operate. No later boot attempt completed
until I'd made adjustments. Testing of my "move the freebsd-ufs
offset to be distinct" hypothesis is expected to be set up in
this week's snapshot builds. But it may well end up not be any
sort of final test fixing all the issues --or even identifying
them all. Time will tell.

> If this disturbs somehow, growfs could perhaps be enhanced to either =
leave some space at the end of slice 2 or optionally add a =
swap-partition of size X. Both measures would effectively prevent the =
additional label rootfsa.

There is the possibility that the week's snapshot test will
end up having ufs/rootfs referencing *s2a like it should
but that there are still problems observed. That is one of
the reasons for doing the test: trying to isolate separate
problems if things still are not working well overall after
the change.

I did get an off-list E-mail asking about the issue and why
I had my hypothesis. My hope is that the person ends up
being someone else looking into the problem(s). They likely
would have significant relevant background knowledge.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Aug 11 14:22:53 2022
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 4M3TYM1M5bz4Xy1W
	for ; Thu, 11 Aug 2022 14:23:03 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161])
	(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 "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M3TYL74Lbz3KqW
	for ; Thu, 11 Aug 2022 14:23:02 +0000 (UTC)
	(envelope-from freebsd-rj@cyclaero.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1660227778;
    s=strato-dkim-0002; d=cyclaero.com;
    h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date:
    From:Subject:Sender;
    bh=wdAOBtkRcb3rtT1/bCElFXgIw1y91c7b94vSvldX1zc=;
    b=My5inXuNNzSrEzbW3nI/D/EfDjuygZN+br+CE835V561SklnBhrWy7q2scUNh3eTOK
    EkLVEF7Sijsg2l85yWz9DW2IYf9mtTIGS8TeWYOJbN1YK2O8P+58xcNBSuwrPRsSSfNY
    A/bZm/+v5sH9k5hp0flFpcyjIwFfWJmHMYnzafujSQ0kHC3ZjeSNj34Ana+O2xgGw1DA
    BPIRxLlvsLYuR06qEk4ONtElpJTcQQBNEodE3ZrWGbS4oFcct42RKAYFyNfJNtGYJIB6
    5phR2+yKWhCP+O9KS4a8bIhh/ZRyyuq2Jwd6G9n1FKdtqJVKgLed66cv8/uaUyUp0uQZ
    yySA==
X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio08NTPnK5bNCibgxfnBg="
X-RZG-CLASS-ID: mo00
Received: from mail.obsigna.com
    by smtp.strato.de (RZmta 47.47.0 AUTH)
    with ESMTPSA id q0201fy7BEMwAZZ
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits))
	(Client did not present a certificate);
    Thu, 11 Aug 2022 16:22:58 +0200 (CEST)
Received: from rolf-mini.obsigna.com (unknown [177.188.53.90])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.obsigna.com (Postfix) with ESMTPSA id 31CD463969;
	Thu, 11 Aug 2022 16:22:56 +0200 (CEST)
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.15\))
Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably
 kern.geom.part.mbr.enforce_chs=0 was still in use
From: "Dr. Rolf Jansen" 
In-Reply-To: <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com>
Date: Thu, 11 Aug 2022 11:22:53 -0300
Cc: Mark Millard 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 <619709DF-C1B6-4B86-A6A3-A8F66090F92A@cyclaero.com>
 <82C4CD12-A9F2-4DEB-86BB-1D12FF21DEE3@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3445.104.15)
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4M3TYL74Lbz3KqW
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)[]
X-ThisMailContainsUnwantedMimeParts: N

> Am 11.08.2022 um 00:22 schrieb Mark Millard :
>=20
> On 2022-Aug-10, at 16:01, Dr. Rolf Jansen  wrote:
>=20
>> I just a BeagleBone Black which was in my drawer for more than a year =
or so. I partitioned the internal flash (here mmcsd1) manually some =
years ago. The u-boot stuff was still quite tiny at that time. Now look =
what I found:
>>=20
>> =3D>      63  62410689  mmcsd0  MBR  (30G)
>>       63        25          - free -  (13K)
>>       88    102312      1  fat32lba  [active]  (50M)
>>   102400  62308352       2  freebsd  (30G)
>>=20
>> =3D>       0  62308352  mmcsd0s2  BSD  (30G)
>>        0  56623104         1  freebsd-ufs  (27G)
>> 56623104   5685248         2  freebsd-swap  (2.7G)
>>=20
>> =3D>     63  7471041  mmcsd1  MBR  (3.6G)
>>      63      961          - free -  (481K)
>>    1024    15360       1  fat32lba  [active]  (7.5M)
>>   16384  7454720       2  freebsd  (3.6G)
>>=20
>> =3D>      0  7454720  mmcsd1s2  BSD  (3.6G)
>>       0  7454720         1  freebsd-ufs  (3.6G)
>>=20
>> =3D>      0  7454720  ufsid/5c9c24b911822409  BSD  (3.6G)
>>       0  7454720                       1  freebsd-ufs  (3.6G)
>>=20
>> =3D>      0  7454720  ufs/system  BSD  (3.6G)
>>       0  7454720           1  freebsd-ufs  (3.6G)
>>=20
>> ls -l /dev/ufs
>>=20
>> crw-r-----  1 root  operator  0x6a Aug 10 17:52 system
>> crw-r-----  1 root  operator  0x56 Aug 10 17:52 SYSTEM
>> crw-r-----  1 root  operator  0x6d Aug 10 17:52 systema
>>=20
>> The BBB has been booted from a new SD card with FreeBSD 13.1-RELEASE =
on /dev/ufs/SYSTEM,
>=20
> If I gather right, this is some sort of personal setup of
> FreeBSD 13.1-RELEASE . For example, release/tools/arm.subr
> uses:
>=20
> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a
>=20
> No attempt to create a ufs/SYSTEM label that I see.
>=20
> (The gpart output above does not show ufs/SYSTEM at all.)
>=20
> As stands, I can not compare/contrast the command sequences
> used vs. the results across the examples.

I don=E2=80=99t use system scripts for partitioning, formatting, =
labelling installation

1. Partitioning using gpart, here a SD card via an external USB reader =
on da0:

gpart destroy -F da0
gpart create -s MBR da0
gpart add -b 88 -s 102312 -t fat32lba da0
gpart add -t freebsd da0
gpart create -s BSD da0s2
gpart add -s 56623104 -t freebsd-ufs da0s2
gpart add -t freebsd-swap da0s2

Note, the size of the FAT32 boot partition has been chosen to match =
exactly what=E2=80=99s on the distribution images. Then the base of 88 =
is mandatory so the BSD payload partition may start on a perfectly =
aligned boundary of 102400=C2=B7512kByte =3D 102400=C2=B7512 =3D =
52428800 byte. Perfectly, because this base is 4k-, 8k-, 16k-, 32k-, =
64k-, 128k-, 256k-, 512k-, 1M-, 2M-aligned. It only stops being perfect, =
in case somebody needs 4M-alignment.

2. Formatting and labelling

newfs -njU -L SYSTEM /dev/da0s2a
glabel label -v SWAP /dev/da0s2b

3. Installation - here from the ARMv7 SD card image, but it does work =
almost the same for any of the other ARM images as well:
mdconfig -a -u 0 -t vnode -f =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220805-e24c5c60d72-257129.img

a) for the FAT32 boot partition, dd does the installation and labeling =
in one breath:
dd if=3D/dev/md0s1 of=3D/dev/da0s1 bs=3D512k

b) File system cloning from the SD card image to the freebsd-ufs volume =
using my tool sysutils/clone (s. also https://github.com/cyclaero/clone:

mount -o noatime /dev/md0s2a /media
mount -o noatime /dev/da0s2a /mnt
clone -x .sujournal /media /mnt

c) edit /mnt/etc/fstab:

/dev/ufs/SYSTEM		/		ufs	rw,noatime		=
0	1
/dev/label/SWAP		none		swap	sw			=
0	0
/dev/msdosfs/MSDOSBOOT	/boot/msdos	msdosfs	rw,noatime		=
0	0
tmpfs			/tmp		tmpfs	rw,mode=3D1777,size=3D50m	=
0	0

d) disable growfs in /etc/rc.conf

This looks a little bit more involved than just calling a script. After =
all it takes a few minutes more than by a script, and in case something =
goes wrong, then I know whom to blame, namely me :-)

The benefit is, that I end up with a journaled FS and a swap partition.

>> and /dev/ufs/SYSTEMa does not exist here. While I see /dev/ufs/system =
and /dev/ufs/systema for the some years old freebsd-ufs slice on the =
internal flash.

The internal flash is too tiny for adding a swap volume, so the whole =
BSD slice was used for the UFS volume. And actually this difference gave =
rise to - hmm..., wait a moment.

>> The BBB starts without problems from the internal flash once I remove =
the SD card.
>>=20
>> I just partitioned another SD card without the swap partition, and =
after applying newfs -njU -L rootfs dev/da0s2a, I see /dev/ufs/rootfs =
and /dev/ufs/rootfsa. Both can be mounted and work without problems.
>=20
> Interesting that the swap partition vs. not makes such a difference
> in what labels show up, referencing where. Being strictly after the
> freebsd-ufs area (if  your example gpart output above applies), that
> complicates interpreting things. Just start-offset-in-BSD aliasing
> is not going to be an explanation for that, for sure.

Exactly, and in a previous message you stated already:

>> Am 09.08.2022 um 15:55 schrieb Mark Millard :
>>=20
>> I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to
>> cause the offsets to be different is reasonable, despite that
>> it happens to make them distinct: the freebsd-ufs offset is
>> better controlled explicitly elsewhere.


My finding support your view. Only it seems now, that we may choose on =
how to make the volume distinct from the slice, namely both or either of =
offset and size. =20

> FYI:
> I booted the original test snapshot. But after its initial activity,
> the following reboot attempts could not complete. I sent a messy
> series of list messages from exploring/learning for this, including
> a sequence of adjustments that eventually got things to back to
> booting.
>=20
>> I tend to believe now, that we don=E2=80=99t see a bug when rootfsa =
besides rootfs appears, but a mostly unknown feature.
>=20
> My test case got boot failures --after the initial boot appeared
> to work and basically operate. No later boot attempt completed
> until I'd made adjustments. Testing of my "move the freebsd-ufs
> offset to be distinct" hypothesis is expected to be set up in
> this week's snapshot builds. But it may well end up not be any
> sort of final test fixing all the issues --or even identifying
> them all. Time will tell.

Well, I can only tell that my systems boot fine, either with or without =
the second ufs/


=

On Sun, Sep 4, 2022 at 4:51 PM void &=
lt;void@f-m.fm> wrote:
On Sun, Sep 04, 2022 at 07:31:=
59PM +0000, void wrote:

>

>On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

>> You need a newer boot loader...

>

>I was thinking - getting latest -current image, booting to it then 

>copying the contents of /boot from the image onto the mounted zpool ...=


>

>feasible?



Seems only EFI/ needed replacing from a recent snapshot. I thought it might=


be all of /boot but I was wrong. Thank you Mark!

<=
/div>
Yes. You'll need to update EFI/BOOT on your ESP. The rest of =
/boot is updated
when you do an installworld.

Warner


--00000000000002977a05e7f3a23a--

From nobody Mon Sep  5 22:21:09 2022
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 4MM2zg1vH7z4bqtR
	for ; Mon,  5 Sep 2022 22:21:19 +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 4MM2zf1qSlz3n7t
	for ; Mon,  5 Sep 2022 22:21:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662416475; bh=kU0brUiNqPilyaGqXQ39xyjQMGWrb/Egl1hz/+GHQzw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=kWfQrMquLskmrEZ9R+SCHPxPaHSxgDZ+PfslcCFYvBt15zpwad3Et0MK2RLqjbCSxEkMLt+VFONpw/SVTAwDl21nvurC1csDcdzFVK0GqbVRzLu2eAhm1tF3XE1PJ8PkkmXIt7W0aSwKfTfSJ9AGstWieOuXryUYcD9gDtYIodtUtMQ8OAsYwg82pXp0LDi0Flz5VDENIt+7MfLTDb+V1uVHb+8FpzKjnpgpaejkYaKcKvzSvMVc9GalcoJaLk1BQJiazHc6PrGU7UyNZqUXYC7XslQRkbLxF/TTi1VHzGOWlMTFfdwluHC/J6HPHU1pY4lbRy53U/I7tM2bfn5WpQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662416475; bh=L6u1ABYcvK4Pc6x3mRF7SytsCc42MVltU7CVC/junze=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=REe0EMcTMfwL8wtT2qeTh8OipE5JpjSk4jyuRfVbDCwAZgdtG5n5TFge79Et5XZana+HHm2c+IeHav/uUx7aDV06Af51DWpX/C2Q5V4oy8JpWufzwLziUP99YdKeG+l8lFi7kgEjkMKP3o0/mSIxBrh/GEBxXbJnOO7FGjjFaDoJ1TyO2YW5liDTbgTrMwVahQ93aP55baltMIUkGMezLrIotaCMDlwGgiFc84lzj8GaqUgPLmx8v4P0M+C+TDVG/d+5F9xIwT2vummE4qpxXnt1rHy2zBgHo3W1X0VyYA5yaMJY4sSR7cC3hZaYSx6QfhN6ebdC2O73kqDy8y3MUQ==
X-YMail-OSG: LzNC260VM1kM.CBvrUXx.AOsbZQzKJInFAmSbE3JYWRxC3xyhMubijO7qBIE3E2
 bc9MBWvYPjFj1PwG8PBPQT6S96FwS._a23PBbsPEK1z3lmy2Igd0pcklE1Xta1zEJevM2Xc5BwrC
 DV0kcuJ5eK.o1ip0TIxwu5wElQM7PzDf.r2KZhX1lGpZ3RTvKbKMFYBjkYBHkwSFOUv05SRjRM0g
 R7HlpePKoE2TaSI5UI7byVLQJOTjf5e_.h3SQswWpyCnc1Ymu1AuJ99XrjDwpXP3PGjvFHw8pGp7
 OWPFZl4UHJ.y0tU3.gcqffdGWqaT26A0xy7wagymtnog.wEP15FbTxNEDgHB2dsYhKP3_fNZvY9K
 0zJc7noCLJASrME5SoEXkY3mFXtwgTNE6RVpWWPqXAcKUNxzTfzULPTjhKP3BmbOxhBYHk1mhhz.
 TVAVDiPH8c4MRW0D.HN3pw1nfIqthQVejjfBFf5NRghz70DRf4w.z_XPdKN69xkyUlA5acZJbmsE
 27BRtGtRGcefmqEvyz0M_GcOzq2epGPdrV.w.mlDuDmJ6uejaWphA0FzruZp.2Eon_NOsxQ9_jKH
 cp6t3jrPD7krlgIg26LYzohvKCywHNYsb1jgjjrlOZfoHnA_XsBjUYg3csevjKDitLflf5fbPnpw
 QQhHZ9Dgx.JbTdSj9ux6ySalcXOIDMXlaP9MsOpRH5SqGCsPOEpEFKsUYsxbKLnWrmrNlfi3o6P9
 con8ZNMhGcqXqFzEg_Rr37gZuwG5_AnlMUn8clNFDAmRz558LFwb2NoBclQ6QTGKSTdutCFsZiIS
 tIgfDG9PYhAmzB53uzJNMr6WRoknPQ3eOWoqp6fhggsT8T7u6bAzEwUVPvedm2ZuVJAfkfgLMofc
 FZzIAvlSRnlzdJ46yHED4xrMSHi_I7MDGl4N6LGIMpAuadVoZVoYP7Vd5GTYGXPWg1mD59onB3Jk
 TuhD1QaDT1RT0YL4wEOydWxj73XweeAJGs64hcW6eW2ZWL8MC52GG0ySEHRy6iFrAlCBqYqlNC.x
 lypjW0s7QgY9ZrP9DVBlRBp1N8K1TmBy3qb3a3tTO8OWxgEY6bvsKeaBqpyWOOTpz.yKeqPBv0oR
 Aans3qpiTBfzXohtyq.AEycGA_4hfxzZYDXgHVetUADYb1AfFW__DchRWYmWU7XR_QR_8rA32FdH
 _YNRQaVeHe1NtbG7mueGsjD7crI0LT.K_1aUxMeMTvWTODH476TPz34kKxwHaXf2n10ovsVocfpC
 yMJiFOmX95Z7Np1eNnUCFeOS7ERAR5Z1l7u5Hy3e2hw4QK6MvEvzl7tHh4RYdY2SYce23TqCbP7u
 xgl2uYe6ZCOP0F_FwxZMUmdGK_2rk2RpsEhBQPE55wlf__J9hu.GtqP1dcoUuimS2hlHVPPJ2usV
 iJW_.eSpq23rdgOMQPq5fClMSKAwB3Z27NzkbwUkkhKTC_FoBXhY58LmRn7ktsXn3W3CxoD3TKLa
 Q2QO_8JWMpxDTVpVVg0CpHiNQSIR9s0P91ZFLA684qSSxjqEcLgozu037..DvQslNojrZVnZbwpJ
 ghcoyMk6EciKNOAUSmiPiKYmI4vo1xx21mA7HohFg9IF2KpiFE80D10Hj7Dg5jI1TbWrIBv8UMh7
 Fpy9eFdaHvysFYxtV4KZ7kYGwvm9O1VspzVkcQmdAcphL0yGKTNc8FpOeXIG8dfw91JB6IInKc6H
 SqFSh9Vk9rp0w5rdLEyG6W6CJr1vwajzJ9dNlgCJaxS_3IEbKpz0lfS7iA6Qis_su4Y59aRamNmX
 7jN.8iV.q6dPSFoO42NBnIUbLPys.Ta.n.GCTsqVn_a.gJZmrwlZ4ihI9ukq9RZq1hAEfwhNA3DV
 1I2UyU2TuDK.2Fuz6.aonkgf.tRVLgmPzvNlgrkamqMR6X2xa_oM7JRWBa1oWHVLJkR.dIpJo4FI
 QvsJsxR_NXpXmpLCZvXvff7nSm3WzkpGpx8D2b1KQXFxDJMy8rKCzOxLPx5Xx0RqizdHMgS0WO4X
 sh1Bq6OO8f7szgMDewYDXbsASaAyjBeTvevNU73TZUs2Xc.D8eXIRgeM5.ElbUm5srm9LbBHbRK.
 OkprKuCCRRa5H4CYbAwjgYHKgdME431KXItPGnX9i4FBSba0oIHp.JFWyYC4ltgU8binjYd2g5G4
 VHlczTWEqUBb9bmWlcfv0YUhwcPjdgM2BkBevdvFhBh5aHDcPndS8V.9x7By2wudO4.yLMhxPS2l
 pzbmXpgdY8MRZDd0Q_HxZF.GDGSQ8U3CUWiRCka3ukkMFDRYK4pZ2AsFQsJ4N3kEO3e23Y29q
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Sep 2022 22:21:15 +0000
Received: by hermes--production-ne1-544744cc75-m62bc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 38b64058e7fff2b461a6a038bf92fc8c;
          Mon, 05 Sep 2022 22:21:10 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: kernel update broke -current
Message-Id: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4@yahoo.com>
Date: Mon, 5 Sep 2022 15:21:09 -0700
To: Warner Losh ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4.ref@yahoo.com>
X-Rspamd-Queue-Id: 4MM2zf1qSlz3n7t
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=kWfQrMqu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.32 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.93)[-0.927];
	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];
	NEURAL_SPAM_SHORT(0.11)[0.109];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Warner Losh  wrote on
Date: Mon, 05 Sep 2022 20:07:33 UTC :

> On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
>=20
> > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
> > >
> > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
> > >> You need a newer boot loader...
> > >
> > >I was thinking - getting latest -current image, booting to it then
> > >copying the contents of /boot from the image onto the mounted zpool =
...
> > >
> > >feasible?
> >
> > Seems only EFI/ needed replacing from a recent snapshot. I thought =
it might
> > be all of /boot but I was wrong. Thank you Mark!
> >
>=20
> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
> updated
> when you do an installworld.

One of the oddities of the update sequence instructions is
the lack of coverage of the likes of:

Load Path: /efi\boot\bootaa64.efi

What step of the sequencing for the overall system update?
When is such an update required? (Here the example would
be: Before rebooting when the ZFS pool(s) possibly used to
boot gain new features?) When is it not required to update
the loader in the ESP (or analogous)? Even just knowing
the stage at which one should do the update indicates some
about when to figure out if an update is needed and so
prompts to be ready.

Part of the sequencing gets into having needed to do a
installworld to have a from-same-build content replacement
for the likes of /efi\boot\bootaa64.efi . So installkernel
already done, a reboot already done, and an installworld
having been done as well in order to have something to
copy over. (There are no pointers to alternate places to
get copies that I know of. One can find copies in the
build tree when one builds from source locally. So waiting
is not really required for that context.)

This also make it seem that updating ZFS pool features
should wait until after a system upgrade that spans both
the loader and kernel being ready for the new features,
even if compatibility with other systems is not a worry.

Do any of the system upgrade instructions cover such
relationships? Do any of the ZFS pool upgrade instructions
cover such? Does zpool or the like suggest such issues
when it reports there are new features that could be
enabled?

Part of what I expect happened here was contributed to by
a lack of being prompted to even think about the relevant
issues, leading to a pool feature upgrade that had not
been prepared for.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep  6 03:56:28 2022
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 4MMBR64zdPz4c0rh
	for ; Tue,  6 Sep 2022 03:57:06 +0000 (UTC)
	(envelope-from furaisanjin@gmail.com)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535])
	(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 4MMBR60lQMz46m0
	for ; Tue,  6 Sep 2022 03:57:06 +0000 (UTC)
	(envelope-from furaisanjin@gmail.com)
Received: by mail-ed1-x535.google.com with SMTP id z8so13478436edb.6
        for ; Mon, 05 Sep 2022 20:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date;
        bh=XJlWa953wbVHn9+5mYo/hpttqbT3u5ASfG07TbsnArc=;
        b=e/BQYPsIwWSvinlPATezhMVcwnPJQJabHAnVx5rwTnKiHbN9tEOwvPiyutMmLRh2A8
         QbFJhxZJcf/wybhvNPt/8HqnppQRXSO2cFXgJB2CBI5hzzA4uaxedvPPsZZxlz/UyNw0
         m9+NsmRk9wdEuYRBG9T2uamv9XFJEa6blKqmU/Sa2AiO+WG4Odce2jHddCSiIFQCxoP5
         ypZV24rzQfWNUuh9oaB3w0Dwf75nOivkpVSdOF9qulHBvwJk3AycdjRRyaao2Vxrkbi6
         0DkyBsPsrAEFqX4uXi1NR5RKNBwBlx2OJPnMgdD+vZewZUB4CR9It9EspaGsMNQTbmG7
         xPuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date;
        bh=XJlWa953wbVHn9+5mYo/hpttqbT3u5ASfG07TbsnArc=;
        b=08lDdoxBbLnKjJKzIQCqrbg7R+2Xk1G2yYTBQMdxS2EUA7PQ2hQSPzv6P7KmLXPDNp
         IiehvMRSz7WJHrkcSaMbrSMH88yXyiiCtMaYFrpA576YcjlYcZrZA2jef3zTeSjRbpfk
         V2BvdwuZThjsUSRKYAQiy/gh5ZbAMeUztpYv+ttMIGATrnWgd0mHBBVTagFWBo0bGN0a
         GIJXUcY5j/p+fzKLSs0u+CNGnsIs3C0GoQHxtdd2YKSNaFWybx2e0H0KXVvFoaZa8F/i
         nCwuCYNCsUlKWApamhmpKnXU2XW+Q/M6l2/W07Ytm7K+Pk8B6in281KBEMtqw6TYBO2J
         8I1g==
X-Gm-Message-State: ACgBeo2CO4nC+mMVAn2HwAUw8MaVJ+z10qd4WBm7yi3+EYuAEdbLJGUr
	wQqQnBqaMfwtWq4aIFPD2LP5DxXzyTc1c5GJJYwf0cnE9wE=
X-Google-Smtp-Source: AA6agR6rvMuAMx0zCH9upyvBhPWtR0Pu2nKSuSuOvup2XHn022RrBm8lNMV82aMcqn02Ki5Gr2ArLCMz29YP4grMMFo=
X-Received: by 2002:a05:6402:2a06:b0:447:820a:1afe with SMTP id
 ey6-20020a0564022a0600b00447820a1afemr46179710edb.291.1662436624658; Mon, 05
 Sep 2022 20:57:04 -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
From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= 
Date: Tue, 6 Sep 2022 12:56:28 +0900
Message-ID: 
Subject: RPI4 HW pwm
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000007977c905e7fa301c"
X-Rspamd-Queue-Id: 4MMBR60lQMz46m0
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="e/BQYPsI";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of furaisanjin@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=furaisanjin@gmail.com
X-Spamd-Result: default: False [-2.13 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_SPAM_MEDIUM(0.86)[0.862];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007977c905e7fa301c
Content-Type: text/plain; charset="UTF-8"

Hello all.

Sorry for bringing up the old topic again. There was an email last year.

https://lists.freebsd.org/archives/freebsd-arm/2021-June/000143.html

This patch isn't included in the 13.1 and later versions. Is there any
chance we can have it?

Thank you.

--0000000000007977c905e7fa301c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello all.

Sorry for bringin=
g up the old topic again. There was an email last year.


This patch isn't included in the 13.=
1 and later versions. Is there any chance we can have it?

Thank you.


--0000000000007977c905e7fa301c--

From nobody Tue Sep  6 11:23:08 2022
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 4MMNKt4XCpz4bZSw
	for ; Tue,  6 Sep 2022 11:23:14 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b])
	(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 4MMNKs53Yhz3p21
	for ; Tue,  6 Sep 2022 11:23:13 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: by mail-wm1-x32b.google.com with SMTP id n23-20020a7bc5d7000000b003a62f19b453so9381881wmk.3
        for ; Tue, 06 Sep 2022 04:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date;
        bh=2T1eW61m3ICP/rbDw2nIswfHJb8gJRGPPHcgaj4fbBs=;
        b=ne2nlLNN/Fokw83zK2GIXMSHDJlbgIkhVN/vLVN2BGrJMkFI6pvfhpnkYOr1wGxmeN
         fZCLimyGO0Hvsx75qnA2Kyd3TGiJVJcYnLY0lBoqlZKdh+mQRtLv//1JwLhh82LyEPWc
         UJW7RVPN4hjNd/2xdZYKyzrm3NSobtKuNpEuvY8sA+G+Rvq8FyllhKJkVlPHxfI7xPKZ
         nCmParB/6J33zL43tkWX57hp64aSJXPmbrHLz13Y4aIWKyDNGNZb3ZVXqb/jVzMZlFrB
         XnBsWNmMRubTKGOg9U6+utxaMORV9tE8Vcw6KEgXmscJk+QwgKEHqtXPHuHYsX9NyXTl
         Mkvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date;
        bh=2T1eW61m3ICP/rbDw2nIswfHJb8gJRGPPHcgaj4fbBs=;
        b=UN4nUpsyoyACqV2XFB3KJvfRRiOqqx+Li5x0r3LvDZN7AGwqwn05J2iRRQtevdkv6o
         1ozrBzAGY/txUc5xtpZ89aUZJ2ATGMzvLhs4baq4fn2S1qKXrBrpGZtN51edzfYbNiiJ
         Rlv9T/oy23zito3ZInlpp3iq5aDNyEYKSiAvUVYajWX5U54Ce/MJWk4IzV5kbiawaVbZ
         L4oaDShNUC1B9lDaU50x59dU2mpfWmM04BsdsSWaHl3QmoXYKYAjTfM988znIHO5gbSc
         l2qb11d2eiQZspeoMixfOf6Pc8HXU9s3fdm7uvNDL32U7V0SqwCWbHBgD0OdgjnrDSc6
         E+1A==
X-Gm-Message-State: ACgBeo0hXe8Ggc2FN2cx9TfrZ3A35DWrJvv289AEEEDiPthkV9np2IVd
	aPMNbdOSwNLFB0NlHqYDmJwQWOgtZ9Q=
X-Google-Smtp-Source: AA6agR6K7kmn2Kpx4n1GM5mWKcpsd26gb9NLEeOUC+FhVV1msiADZb2SaYSK7zFB82FgqPTr4xSFPw==
X-Received: by 2002:a05:600c:5105:b0:3a8:3f3c:ca90 with SMTP id o5-20020a05600c510500b003a83f3cca90mr13113135wms.81.1662463392193;
        Tue, 06 Sep 2022 04:23:12 -0700 (PDT)
Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181])
        by smtp.gmail.com with ESMTPSA id m15-20020a7bcb8f000000b003a83b066401sm20021627wmi.31.2022.09.06.04.23.11
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 06 Sep 2022 04:23:11 -0700 (PDT)
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 14.0 \(3654.120.0.1.13\))
Subject: Re: VCHIQ sound on Raspi4B. Which DTB to include on config.txt file,
 Any other missing pieces?
From: Marco Devesas Campos 
In-Reply-To: <0ec5a701-908f-fc15-ef8b-401c1553e194@thegalacticzoo.com>
Date: Tue, 6 Sep 2022 12:23:08 +0100
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0ec5a701-908f-fc15-ef8b-401c1553e194@thegalacticzoo.com>
To: Fred Finster 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MMNKs53Yhz3p21
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ne2nlLNN;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of devesas.campos@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=devesas.campos@gmail.com
X-Spamd-Result: default: False [-2.50 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from];
	RCVD_COUNT_THREE(0.00)[3];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi

> On 7 Sep 2022, at 06:04, Fred Finster  wrote:
>=20
> VCHIQ sound on Raspi4B HDMI audio.  Which DTB to include on config.txt =
file, Any other missing pieces?

stock confit.txt and dtb-s.=20

dmesg should then show

vchiq0:  mem 0x7e00b840-0x7e00b87b irq 72 on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0:  on vchiq0

and=20
  cat /dev/random > /dev/dsp
should play static

If nothing=E2=80=99s playing, flipping the sysctl dev.pcm.0.dest through
 - 0: both hdmi and headphones
 - 1: headphones
 - 2: hdmi
usually brings the audio back to life.

Best,
Marco=

From nobody Tue Sep  6 16:13:04 2022
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 4MMVmX5znwz4c7M1
	for ; Tue,  6 Sep 2022 16:13:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30])
	(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 4MMVmX131Gz3GR9
	for ; Tue,  6 Sep 2022 16:13:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe30.google.com with SMTP id o123so12213214vsc.3
        for ; Tue, 06 Sep 2022 09:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=FqkbuO42xWfsyAMrYOu7oMYybQWuCoaSmuP48pWyLpE=;
        b=f+oOV/ngBM53QBW/thCtLOv6wJDaSy6/H/NJ7aQ8gt6A4R85C30NjxjB07OUIZLKBL
         JdpLjSRchO+ZoCAxjq48khP5UwGoY50OlxBgEwdsRtVyCCfkQFGCw9DAwNElu7pyQF6q
         CaOiw435N1rhtrtBNd7Qi0PYcexdx0q14QbsX35v69JGKw3WE0y98fgO+V7mVm00K0R1
         S3Q6OfdQRpjtoLamwetj25sVp0sTYtpU/l/Vy3K9c+4xNyb7p97oRTpN7YtvOtZh8NJs
         WXxvyUnJrzsjcwd1NE7FKBMZvtdbk0fUqld6sn20Ha8XjKtgfrG3CemasYeNwlq6QGZ6
         VayQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=FqkbuO42xWfsyAMrYOu7oMYybQWuCoaSmuP48pWyLpE=;
        b=4Pvpd19TNW6bTV4iQVoaWv8gyR0W4nxUnFDrqU45FVJmy01FxHDoTI7Y8IYGXk7PB1
         o+bflHymHqQfyjrg/GK6b6wXskBqEjJ2O+eIA4ZIr5M79VHDv21ABmmoLHf2LvAwDsF4
         xSiTtF0jeZYDl7IrPLDLhS8La3JK9O1PJq73Vt0uXYtLooem0wffuU2ER2Z3tXk90vT0
         RMpeo98+0hq8TTlZHNOWIMZzuAjf9ca6JFNagUhpTzINNA88HEfi9FAmUp/zrFjYwWJ7
         ttRQL1cQp++80vCHpcsrYHtI11BAVZbez6Z2u8lqrywV0Km8rBCuGKhhSwLwMr/9dADW
         hmRw==
X-Gm-Message-State: ACgBeo0lQSvmZcAswnZpHTE1A2+L/ieDy/zLUZwpgPUs58h1lif+hSfU
	jdFsGrzETyKeGUMUHHvIwYrp/nsJ7y/pXWKeTo0MOg==
X-Google-Smtp-Source: AA6agR4+ByNu1r2/Lqipvjo7Od7TcGII0sgXF7f3gQPpDOM/wzbsKFTf+RrgLni+obqD47bA9RHelEppd7tqk9252E4=
X-Received: by 2002:a05:6102:345:b0:390:9ebf:3d2c with SMTP id
 e5-20020a056102034500b003909ebf3d2cmr15272383vsa.11.1662480795295; Tue, 06
 Sep 2022 09:13:15 -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: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4.ref@yahoo.com> <79278D35-F3CE-43F9-BB85-1D1798B6B1D4@yahoo.com>
In-Reply-To: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4@yahoo.com>
From: Warner Losh 
Date: Tue, 6 Sep 2022 10:13:04 -0600
Message-ID: 
Subject: Re: kernel update broke -current
To: Mark Millard 
Cc: freebsd-arm 
Content-Type: multipart/alternative; boundary="0000000000003ff7c405e804796f"
X-Rspamd-Queue-Id: 4MMVmX131Gz3GR9
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="f+oOV/ng";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000003ff7c405e804796f
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:

> Warner Losh  wrote on
> Date: Mon, 05 Sep 2022 20:07:33 UTC :
>
> > On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
> >
> > > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
> > > >
> > > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
> > > >> You need a newer boot loader...
> > > >
> > > >I was thinking - getting latest -current image, booting to it then
> > > >copying the contents of /boot from the image onto the mounted zpool
> ...
> > > >
> > > >feasible?
> > >
> > > Seems only EFI/ needed replacing from a recent snapshot. I thought it
> might
> > > be all of /boot but I was wrong. Thank you Mark!
> > >
> >
> > Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
> > updated
> > when you do an installworld.
>
> One of the oddities of the update sequence instructions is
> the lack of coverage of the likes of:
>
> Load Path: /efi\boot\bootaa64.efi
>
> What step of the sequencing for the overall system update?
> When is such an update required? (Here the example would
> be: Before rebooting when the ZFS pool(s) possibly used to
> boot gain new features?) When is it not required to update
> the loader in the ESP (or analogous)? Even just knowing
> the stage at which one should do the update indicates some
> about when to figure out if an update is needed and so
> prompts to be ready.
>

Today:

make installworld installkernel
mount -t msdos /dev/ /boot/efi

and then one of three scenarios

(1) You have the old boot1.efi. This will *always* be in
ESP:EFI\BOOT\BOOT${ARCH}.EFI.
(see uefi(8) for the values of ARCH). You can automatically detect this for
most installations
that were done since about FreeBSD 12:
% sudo efivar | grep Boot1
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

In this case you would do:

% sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you are
done.

Please note: If your system was installed a long time ago, you should also
check to see if
you have a LoaderPath variable set:
% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
/boot/loader.efi

When Boot1 isn't set and it is set to the above value (or something
similar), then you are
booting with a really old copy of boot1.efi. You will need to update it and
may need to arrange
for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was
hard to grow. Steal
space from swap for a larger ESP, etc. Documenting that is beyond the scope
of this email.

(2) You are booting with loader.efi and it is in the bug-compatibility
place. Some UEFI BIOSes
don't respect or can't set BootXXXX variables set by efibootmgr(8). In that
case, many people
are booting from the 'compatibiltiy' location for removable devices. This
will almost always be
a single boot scenario because you can't easily boot other systems like
this (well, unless 'quit'
works from the OK prompt to go to the next one on the list, but I digress).
You will see something like:

% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
\EFI\BOOT\BOOTX64.EFI
(or AA64)

when you are booting this way. In this case the update command is:

% sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi

to upgrade. Some people may be doing this already on systems that can
support efibootmgr(8) and
they can of course upgrade to using that, though that's also beyond the
scope of this email.

(3) You are booting on a working system with a FreeBSD installed by the
boot loader, or some other
custom arrangement. In that case, you'll see something like:
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
\EFI\FREEBSD\LOADER.EFI

(or some other place for custom setups: I assume if you are doing that you
know enough to
update my instructions as appropriate). To update, you'd do

% sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

Automating all these cases is, needless to say, tricky.


> Part of the sequencing gets into having needed to do a
> installworld to have a from-same-build content replacement
> for the likes of /efi\boot\bootaa64.efi . So installkernel
> already done, a reboot already done, and an installworld
> having been done as well in order to have something to
> copy over. (There are no pointers to alternate places to
> get copies that I know of. One can find copies in the
> build tree when one builds from source locally. So waiting
> is not really required for that context.)
>

Yea, I have a branch that has an 'installboot' target that updates the boot
loader regardless, but given the 50-odd combinations of ways we can
boot, it's a bit bogged down.


> This also make it seem that updating ZFS pool features
> should wait until after a system upgrade that spans both
> the loader and kernel being ready for the new features,
> even if compatibility with other systems is not a worry.
>

Yes. ALWAYS update your boot blocks before zpool update.


> Do any of the system upgrade instructions cover such
> relationships? Do any of the ZFS pool upgrade instructions
> cover such? Does zpool or the like suggest such issues
> when it reports there are new features that could be
> enabled?
>

See above. :)


> Part of what I expect happened here was contributed to by
> a lack of being prompted to even think about the relevant
> issues, leading to a pool feature upgrade that had not
> been prepared for.
>

Yea, so far 100% of the 'help, I upgraded and now the boot loader
can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
properly after zpool upgrade.' It was mandatory when we had the
OpenZFS rebase, but it is also necessary every few OpenZFS
updates from upstream as nnew features are enabled.

I'd love for someone to add this information to the handbook, and I'd
happily review such an effort. I have time to do a brain dump, but not
to make it pretty / formatted for asciidoctor and won't for some time.

Warner


> ===
> Mark Millard
> marklmi at yahoo.com
>
>

--0000000000003ff7c405e804796f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Sep 5, 2022 at 4:21 PM Mark M=
illard <marklmi@yahoo.com> w=
rote:
Warner Los=
h <imp_at_bsdimp.com> wrote on

Date: Mon, 05 Sep 2022 20:07:33 UTC :



> On Sun, Sep 4, 2022 at 4:51 PM void <void@f-m.fm> wrote:

> 

> > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:

> > >

> > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

> > >> You need a newer boot loader...

> > >

> > >I was thinking - getting latest -current image, booting to it=
 then

> > >copying the contents of /boot from the image onto the mounted=
 zpool ...

> > >

> > >feasible?

> >

> > Seems only EFI/ needed replacing from a recent snapshot. I though=
t it might

> > be all of /boot but I was wrong. Thank you Mark!

> >

> 

> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot=
 is

> updated

> when you do an installworld.



One of the oddities of the update sequence instructions is

the lack of coverage of the likes of:



Load Path: /efi\boot\bootaa64.efi



What step of the sequencing for the overall system update?

When is such an update required? (Here the example would

be: Before rebooting when the ZFS pool(s) possibly used to

boot gain new features?) When is it not required to update

the loader in the ESP (or analogous)? Even just knowing

the stage at which one should do the update indicates some

about when to figure out if an update is needed and so

prompts to be ready.

Today:
<=
br>
make installworld installkernel
mount -t msdos /dev=
/<mumble-esp> /boot/efi

and then one of thre=
e scenarios

(1) You have the old boot1.efi. This w=
ill *always* be in ESP:EFI\BOOT\BOOT${ARCH}.EFI.
(see uefi(8) for=
 the values of ARCH). You can automatically detect this for most installati=
ons
that were done since about FreeBSD 12:
% sudo efiva=
r | grep Boot1
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
=
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

=
In this case you would do:

% sudo cp /boot/boot1.e=
fi /boot/efi/efi/boot/boot${ARCH}.efi and you are done.

Please note: If your system was installed a long time ago, you should=
 also check to see if
you have a LoaderPath variable set:
% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
<=
/div>
/boot/loader.efi

When Boot1 isn't se=
t and it is set to the above value (or something similar), then you are
booting with a really old copy of boot1.efi. You will need to update=
 it and may need to arrange
for a larger ESP since FreeBSD's =
boot1.efifat was a tiny image that was hard to grow. Steal
space =
from swap for a larger ESP, etc. Documenting that is beyond the scope of th=
is email.

(2) You are booting with loader.efi and =
it is in the bug-compatibility place. Some UEFI BIOSes
don't =
respect or can't set BootXXXX variables set by efibootmgr(8). In that c=
ase, many people
are booting from the 'compatibiltiy' loc=
ation for removable=C2=A0devices. This will almost always be
a si=
ngle boot scenario because you can't easily boot other systems like thi=
s (well, unless 'quit'
works from the OK prompt to go to =
the next one on the list, but I digress). You will see something like:

% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae=
99-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
\EFI\=
BOOT\BOOTX64.EFI
(or AA64)

when you are booting =
this way. In this case the update command is:

% sudo cp /boot/loader.efi /boot/ef=
i/efi/boot/boot${ARCH}.efi

to upgrade. Some people may be doing this already on s=
ystems that can support efibootmgr(8) and
t=
hey can of course upgrade to using that, though that's also beyond the =
scope of this email.

(3) You are booting on a working system with a FreeBSD ins=
talled by the boot loader, or some other
cu=
stom arrangement. In that case, you'll see something like:
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-=
LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
\EFI\FREEB=
SD\LOADER.EFI

(or some other place for custom setups: I assume if you are doing t=
hat you know enough to
update my instructio=
ns as appropriate). To update, you'd do

% sudo cp /boot/loader.efi /boot/efi/=
efi/freebsd/loader.efi

Automating all these cases is, needless to say, tricky.
=C2=A0

Part of the sequencing gets into having needed to do a

installworld to have a from-same-build content replacement

for the likes of /efi\boot\bootaa64.efi . So installkernel

already done, a reboot already done, and an installworld

having been done as well in order to have something to

copy over. (There are no pointers to alternate places to

get copies that I know of. One can find copies in the

build tree when one builds from source locally. So waiting

is not really required for that context.)

Yea, I have a branch that has an 'installboot' target that updat=
es the boot
loader regardless, but given the 50-odd combinations =
of ways we can
boot, it's a bit bogged down.
=C2=A0=


This also make it seem that updating ZFS pool features

should wait until after a system upgrade that spans both

the loader and kernel being ready for the new features,

even if compatibility with other systems is not a worry.

Yes. ALWAYS update your boot blocks before zpool update.<=
/div>
=C2=A0

Do any of the system upgrade instructions cover such

relationships? Do any of the ZFS pool upgrade instructions

cover such? Does zpool or the like suggest such issues

when it reports there are new features that could be

enabled?

See above. :)
=C2=A0=


Part of what I expect happened here was contributed to by

a lack of being prompted to even think about the relevant

issues, leading to a pool feature upgrade that had not

been prepared for.

Yea, so far 100% of =
the 'help, I upgraded and now the boot loader
can't see z=
fs pool' issues have been 'I didn't upgrade my loader.efi
=

properly after zpool upgrade.' It was mandatory when we had the
OpenZFS rebase, but it is also necessary every few OpenZFS
updates from upstream as nnew features are enabled.

<=
div>I'd love for someone to add this information to the handbook, and I=
'd
happily=C2=A0review such an effort. I have time to do a br=
ain dump, but not
to make it pretty / formatted for asciidoctor a=
nd won't for some time.

Warner
=C2=
=A0

=3D=3D=3D

Mark Millard

marklmi at yahoo.com






--0000000000003ff7c405e804796f--

From nobody Tue Sep  6 16:41:23 2022
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 4MMWPB5mPQz4c9s4
	for ; Tue,  6 Sep 2022 16:41:34 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MMWP95l37z3Nlc
	for ; Tue,  6 Sep 2022 16:41:33 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 286GfOAb079039;
	Tue, 6 Sep 2022 11:41:24 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id l83gCzR4F2O9NAEA4+wvSQ
	(envelope-from ); Tue, 06 Sep 2022 11:41:24 -0500
From: Mike Karels 
To: Warner Losh 
Cc: Mark Millard , freebsd-arm 
Subject: Re: kernel update broke -current
Date: Tue, 06 Sep 2022 11:41:23 -0500
X-Mailer: MailMate (1.14r5913)
Message-ID: 
In-Reply-To: 
References: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4.ref@yahoo.com>
 <79278D35-F3CE-43F9-BB85-1D1798B6B1D4@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: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 286GfOAb079039
X-Rspamd-Queue-Id: 4MMWP95l37z3Nlc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[karels.net];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 6 Sep 2022, at 11:13, Warner Losh wrote:

> On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:
>
>> Warner Losh  wrote on
>> Date: Mon, 05 Sep 2022 20:07:33 UTC :
>>
>>> On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
>>>
>>>> On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
>>>>>
>>>>> On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
>>>>>> You need a newer boot loader...
>>>>>
>>>>> I was thinking - getting latest -current image, booting to it then
>>>>> copying the contents of /boot from the image onto the mounted zpool
>> ...
>>>>>
>>>>> feasible?
>>>>
>>>> Seems only EFI/ needed replacing from a recent snapshot. I thought i=
t
>> might
>>>> be all of /boot but I was wrong. Thank you Mark!
>>>>
>>>
>>> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
>>> updated
>>> when you do an installworld.
>>
>> One of the oddities of the update sequence instructions is
>> the lack of coverage of the likes of:
>>
>> Load Path: /efi\boot\bootaa64.efi
>>
>> What step of the sequencing for the overall system update?
>> When is such an update required? (Here the example would
>> be: Before rebooting when the ZFS pool(s) possibly used to
>> boot gain new features?) When is it not required to update
>> the loader in the ESP (or analogous)? Even just knowing
>> the stage at which one should do the update indicates some
>> about when to figure out if an update is needed and so
>> prompts to be ready.
>>
>
> Today:
>
> make installworld installkernel

The procedure documented in the Handbook (section 24.6), and which
I have always followed, is to install the kernel, reboot, and then
make installworld.  The reason is to add any new kernel facilities
used by libc or sysadmin utilities before installing components
that require them.  I think that loader updates need to be an
exception to the rule, not the rule.  This means that notes in
UPDATING are crucial for required loader updates (e.g. when zfs is
updated in a non-backward-compatible way.  Of course, the handbook
does not mention upgrading loader.efi in the efi partition in the
section on upgrading from source.

Fwiw, I thought that incompatible zpool updates were not supposed
to be enabled until =E2=80=9Czpool upgrade=E2=80=9D is run, so that older=
 kernels
could access them.  This seems like it show go for loaders as well.
This may be difficult during a development cycle, hence the need for
UPDATING information.

		Mike

> mount -t msdos /dev/ /boot/efi
>
> and then one of three scenarios
>
> (1) You have the old boot1.efi. This will *always* be in
> ESP:EFI\BOOT\BOOT${ARCH}.EFI.
> (see uefi(8) for the values of ARCH). You can automatically detect this=
 for
> most installations
> that were done since about FreeBSD 12:
> % sudo efivar | grep Boot1
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev
>
> In this case you would do:
>
> % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you ar=
e
> done.
>
> Please note: If your system was installed a long time ago, you should a=
lso
> check to see if
> you have a LoaderPath variable set:
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> /boot/loader.efi
>
> When Boot1 isn't set and it is set to the above value (or something
> similar), then you are
> booting with a really old copy of boot1.efi. You will need to update it=
 and
> may need to arrange
> for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was
> hard to grow. Steal
> space from swap for a larger ESP, etc. Documenting that is beyond the s=
cope
> of this email.
>
> (2) You are booting with loader.efi and it is in the bug-compatibility
> place. Some UEFI BIOSes
> don't respect or can't set BootXXXX variables set by efibootmgr(8). In =
that
> case, many people
> are booting from the 'compatibiltiy' location for removable devices. Th=
is
> will almost always be
> a single boot scenario because you can't easily boot other systems like
> this (well, unless 'quit'
> works from the OK prompt to go to the next one on the list, but I digre=
ss).
> You will see something like:
>
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> \EFI\BOOT\BOOTX64.EFI
> (or AA64)
>
> when you are booting this way. In this case the update command is:
>
> % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
>
> to upgrade. Some people may be doing this already on systems that can
> support efibootmgr(8) and
> they can of course upgrade to using that, though that's also beyond the
> scope of this email.
>
> (3) You are booting on a working system with a FreeBSD installed by the
> boot loader, or some other
> custom arrangement. In that case, you'll see something like:
> sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> \EFI\FREEBSD\LOADER.EFI
>
> (or some other place for custom setups: I assume if you are doing that =
you
> know enough to
> update my instructions as appropriate). To update, you'd do
>
> % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
>
> Automating all these cases is, needless to say, tricky.
>
>
>> Part of the sequencing gets into having needed to do a
>> installworld to have a from-same-build content replacement
>> for the likes of /efi\boot\bootaa64.efi . So installkernel
>> already done, a reboot already done, and an installworld
>> having been done as well in order to have something to
>> copy over. (There are no pointers to alternate places to
>> get copies that I know of. One can find copies in the
>> build tree when one builds from source locally. So waiting
>> is not really required for that context.)
>>
>
> Yea, I have a branch that has an 'installboot' target that updates the =
boot
> loader regardless, but given the 50-odd combinations of ways we can
> boot, it's a bit bogged down.
>
>
>> This also make it seem that updating ZFS pool features
>> should wait until after a system upgrade that spans both
>> the loader and kernel being ready for the new features,
>> even if compatibility with other systems is not a worry.
>>
>
> Yes. ALWAYS update your boot blocks before zpool update.
>
>
>> Do any of the system upgrade instructions cover such
>> relationships? Do any of the ZFS pool upgrade instructions
>> cover such? Does zpool or the like suggest such issues
>> when it reports there are new features that could be
>> enabled?
>>
>
> See above. :)
>
>
>> Part of what I expect happened here was contributed to by
>> a lack of being prompted to even think about the relevant
>> issues, leading to a pool feature upgrade that had not
>> been prepared for.
>>
>
> Yea, so far 100% of the 'help, I upgraded and now the boot loader
> can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
> properly after zpool upgrade.' It was mandatory when we had the
> OpenZFS rebase, but it is also necessary every few OpenZFS
> updates from upstream as nnew features are enabled.
>
> I'd love for someone to add this information to the handbook, and I'd
> happily review such an effort. I have time to do a brain dump, but not
> to make it pretty / formatted for asciidoctor and won't for some time.
>
> Warner
>
>
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>
>>

From nobody Tue Sep  6 19:52:28 2022
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 4MMbdh6TWnz4bYHV
	for ; Tue,  6 Sep 2022 19:52:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929])
	(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 4MMbdh0r28z3jyJ
	for ; Tue,  6 Sep 2022 19:52:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x929.google.com with SMTP id d14so4711206ual.9
        for ; Tue, 06 Sep 2022 12:52:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=e7bJnSSkMJ9j3TsjzngxeoQm2LXOqqtJD553quTWWz4=;
        b=C7qSdRVV3MQhkUClCOhLU9WG1ktpGKGVBeQ8HKMTOn43nVaMk2Iuvu05mDiO+O66as
         /dFSL09d++D2aKsO1s9ELOo75qv/NZOvqwbKDRem/3XkWWW3dyo0pynEeOi8DSS/tkPy
         R2NaC3Fytl+Eutstk9AhaK5C290JdETeuAnTt1y0m4Og7AS1+d6a2qZYByBhCn+dVZhN
         fLn2r9wAsWMUqk2x/Z351jXhqBDcft2h71YhH2n44BmjaK7AWjnlcTLe32pFNTjFni7V
         1Jirv2kbrChjIheqNsJf02DwzD6O4S2P5B9hIwafKdFT19C0pwm6NbPy8j83Q92/TG2Z
         v2HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=e7bJnSSkMJ9j3TsjzngxeoQm2LXOqqtJD553quTWWz4=;
        b=OfV56wASg3ee1Ug4mGKuKWL0e6JrMEl4gdNjAs6BWoyClZ/0tbj3cVrp9iPE8XtYz8
         KMk4Nf2uN9EjpweurOzoFPX9dI4ooaOyUKB4VAsa6U8K0ujGwbBe3ISOUT9OK47C9MiH
         KMsKotB351DBgLTejfvFCkGgloSjgOXtoUFnHo0JA7O8FVkKDmsNoWOFelgoDkO5i0rr
         gA/b0cm/0DbgaHSO6CPbvEhHEMhFNXQlq8oAxyRVK6iyCaUufVsMI5TfTDplgOPaxGEj
         RgvKi9fcmlIiFdpGZHSMkvp7q0kSu/6XsV1kzTPSVN8P7HZMC5rGUsMlt2LrFhMTdqr2
         2+1w==
X-Gm-Message-State: ACgBeo1RgHeRCnD/YoBGCspkqVER+ZFq2mKFy1GYTR8DDQki+ki3Cgrz
	3SAwpYwUOUGOrsYr/BNlYm+SQ0Goq9Wp+Q9XymuvPg==
X-Google-Smtp-Source: AA6agR6xbZVbElvcX+dyH8uNl9fqbVwNoCAyrZNRwSfGzi3vsJjezk0Ftaq+VBlSh+QYl6dW8yI/n/xR8VIDA0QBVcY=
X-Received: by 2002:ab0:15ed:0:b0:365:f250:7384 with SMTP id
 j42-20020ab015ed000000b00365f2507384mr69473uae.44.1662493959284; Tue, 06 Sep
 2022 12:52:39 -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: <79278D35-F3CE-43F9-BB85-1D1798B6B1D4.ref@yahoo.com>
 <79278D35-F3CE-43F9-BB85-1D1798B6B1D4@yahoo.com> 
 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 6 Sep 2022 13:52:28 -0600
Message-ID: 
Subject: Re: kernel update broke -current
To: Mike Karels 
Cc: Mark Millard , freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000e2818c05e80789c5"
X-Rspamd-Queue-Id: 4MMbdh0r28z3jyJ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=C7qSdRVV;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::929) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e2818c05e80789c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 6, 2022 at 10:41 AM Mike Karels  wrote:

> On 6 Sep 2022, at 11:13, Warner Losh wrote:
>
> > On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:
> >
> >> Warner Losh  wrote on
> >> Date: Mon, 05 Sep 2022 20:07:33 UTC :
> >>
> >>> On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
> >>>
> >>>> On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
> >>>>>
> >>>>> On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
> >>>>>> You need a newer boot loader...
> >>>>>
> >>>>> I was thinking - getting latest -current image, booting to it then
> >>>>> copying the contents of /boot from the image onto the mounted zpool
> >> ...
> >>>>>
> >>>>> feasible?
> >>>>
> >>>> Seems only EFI/ needed replacing from a recent snapshot. I thought i=
t
> >> might
> >>>> be all of /boot but I was wrong. Thank you Mark!
> >>>>
> >>>
> >>> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
> >>> updated
> >>> when you do an installworld.
> >>
> >> One of the oddities of the update sequence instructions is
> >> the lack of coverage of the likes of:
> >>
> >> Load Path: /efi\boot\bootaa64.efi
> >>
> >> What step of the sequencing for the overall system update?
> >> When is such an update required? (Here the example would
> >> be: Before rebooting when the ZFS pool(s) possibly used to
> >> boot gain new features?) When is it not required to update
> >> the loader in the ESP (or analogous)? Even just knowing
> >> the stage at which one should do the update indicates some
> >> about when to figure out if an update is needed and so
> >> prompts to be ready.
> >>
> >
> > Today:
> >
> > make installworld installkernel
>
> The procedure documented in the Handbook (section 24.6), and which
> I have always followed, is to install the kernel, reboot, and then
> make installworld.


Yes. And that reboot is tricky. Do not zpool upgrade at this stage. That's
the only reason you *MUST* update boot blocks that we don't put in updating=
.
And so far, there's no reason to put something specific in UPDATING,
though we did with the OpenZFS import since there was the zpool upgrade
issue then for sure.

Well, the other reason you'd need to upgrade your boot loader is if you
create a new zpool to put root on...

I think we likely need a generic note in UPDATING...


> The reason is to add any new kernel facilities
> used by libc or sysadmin utilities before installing components
> that require them.  I think that loader updates need to be an
> exception to the rule, not the rule.  This means that notes in
> UPDATING are crucial for required loader updates (e.g. when zfs is
> updated in a non-backward-compatible way.  Of course, the handbook
> does not mention upgrading loader.efi in the efi partition in the
> section on upgrading from source.
>

Correct. Generally, we try very hard to not make incompatible updates
to the boot loader. Generally, it can boot old and new kernels, can cope
with the different scripts that might be present, etc. The zpool upgrade
thing is a new wrinkle that we might want to, honestly, revisit policy
around (eg, have a treat unsupported features of the zpool as a warning
and give it your best shot). While we've had ZFS support forever, upstream
OpenZFS seems to accumulate more new features than we did at a faster
rate than before we switched.


> Fwiw, I thought that incompatible zpool updates were not supposed
> to be enabled until =E2=80=9Czpool upgrade=E2=80=9D is run, so that older=
 kernels
> could access them.  This seems like it show go for loaders as well.
> This may be difficult during a development cycle, hence the need for
> UPDATING information.
>

To date, that's been 100% true of every instance of this that I've
investigated.

UPDATING likely needs to only be updated to admonish against zpool upgrade
without updating the boot blocks.

Warner


>                 Mike
>
> > mount -t msdos /dev/ /boot/efi
> >
> > and then one of three scenarios
> >
> > (1) You have the old boot1.efi. This will *always* be in
> > ESP:EFI\BOOT\BOOT${ARCH}.EFI.
> > (see uefi(8) for the values of ARCH). You can automatically detect this
> for
> > most installations
> > that were done since about FreeBSD 12:
> > % sudo efivar | grep Boot1
> > cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
> > cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev
> >
> > In this case you would do:
> >
> > % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you ar=
e
> > done.
> >
> > Please note: If your system was installed a long time ago, you should
> also
> > check to see if
> > you have a LoaderPath variable set:
> > % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> > /boot/loader.efi
> >
> > When Boot1 isn't set and it is set to the above value (or something
> > similar), then you are
> > booting with a really old copy of boot1.efi. You will need to update it
> and
> > may need to arrange
> > for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was
> > hard to grow. Steal
> > space from swap for a larger ESP, etc. Documenting that is beyond the
> scope
> > of this email.
> >
> > (2) You are booting with loader.efi and it is in the bug-compatibility
> > place. Some UEFI BIOSes
> > don't respect or can't set BootXXXX variables set by efibootmgr(8). In
> that
> > case, many people
> > are booting from the 'compatibiltiy' location for removable devices. Th=
is
> > will almost always be
> > a single boot scenario because you can't easily boot other systems like
> > this (well, unless 'quit'
> > works from the OK prompt to go to the next one on the list, but I
> digress).
> > You will see something like:
> >
> > % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> > cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> > \EFI\BOOT\BOOTX64.EFI
> > (or AA64)
> >
> > when you are booting this way. In this case the update command is:
> >
> > % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
> >
> > to upgrade. Some people may be doing this already on systems that can
> > support efibootmgr(8) and
> > they can of course upgrade to using that, though that's also beyond the
> > scope of this email.
> >
> > (3) You are booting on a working system with a FreeBSD installed by the
> > boot loader, or some other
> > custom arrangement. In that case, you'll see something like:
> > sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> > cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> > \EFI\FREEBSD\LOADER.EFI
> >
> > (or some other place for custom setups: I assume if you are doing that
> you
> > know enough to
> > update my instructions as appropriate). To update, you'd do
> >
> > % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
> >
> > Automating all these cases is, needless to say, tricky.
> >
> >
> >> Part of the sequencing gets into having needed to do a
> >> installworld to have a from-same-build content replacement
> >> for the likes of /efi\boot\bootaa64.efi . So installkernel
> >> already done, a reboot already done, and an installworld
> >> having been done as well in order to have something to
> >> copy over. (There are no pointers to alternate places to
> >> get copies that I know of. One can find copies in the
> >> build tree when one builds from source locally. So waiting
> >> is not really required for that context.)
> >>
> >
> > Yea, I have a branch that has an 'installboot' target that updates the
> boot
> > loader regardless, but given the 50-odd combinations of ways we can
> > boot, it's a bit bogged down.
> >
> >
> >> This also make it seem that updating ZFS pool features
> >> should wait until after a system upgrade that spans both
> >> the loader and kernel being ready for the new features,
> >> even if compatibility with other systems is not a worry.
> >>
> >
> > Yes. ALWAYS update your boot blocks before zpool update.
> >
> >
> >> Do any of the system upgrade instructions cover such
> >> relationships? Do any of the ZFS pool upgrade instructions
> >> cover such? Does zpool or the like suggest such issues
> >> when it reports there are new features that could be
> >> enabled?
> >>
> >
> > See above. :)
> >
> >
> >> Part of what I expect happened here was contributed to by
> >> a lack of being prompted to even think about the relevant
> >> issues, leading to a pool feature upgrade that had not
> >> been prepared for.
> >>
> >
> > Yea, so far 100% of the 'help, I upgraded and now the boot loader
> > can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
> > properly after zpool upgrade.' It was mandatory when we had the
> > OpenZFS rebase, but it is also necessary every few OpenZFS
> > updates from upstream as nnew features are enabled.
> >
> > I'd love for someone to add this information to the handbook, and I'd
> > happily review such an effort. I have time to do a brain dump, but not
> > to make it pretty / formatted for asciidoctor and won't for some time.
> >
> > Warner
> >
> >
> >> =3D=3D=3D
> >> Mark Millard
> >> marklmi at yahoo.com
> >>
> >>
>

--000000000000e2818c05e80789c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Sep 6, 2022 at 10:41 AM Mike =
Karels <mike@karels.net> wrote=
:
On 6 Sep 2022,=
 at 11:13, Warner Losh wrote:



> On Mon, Sep 5, 2022 at 4:21 PM Mark Millard <marklmi@yahoo.com> wrote:

>

>> Warner Losh <imp_at_bsdimp.com> wrote on

>> Date: Mon, 05 Sep 2022 20:07:33 UTC :

>>

>>> On Sun, Sep 4, 2022 at 4:51 PM void <void@f-m.fm> wrote:

>>>

>>>> On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:

>>>>>

>>>>> On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

>>>>>> You need a newer boot loader...

>>>>>

>>>>> I was thinking - getting latest -current image, bootin=
g to it then

>>>>> copying the contents of /boot from the image onto the =
mounted zpool

>> ...

>>>>>

>>>>> feasible?

>>>>

>>>> Seems only EFI/ needed replacing from a recent snapshot. I=
 thought it

>> might

>>>> be all of /boot but I was wrong. Thank you Mark!

>>>>

>>>

>>> Yes. You'll need to update EFI/BOOT on your ESP. The rest =
of /boot is

>>> updated

>>> when you do an installworld.

>>

>> One of the oddities of the update sequence instructions is

>> the lack of coverage of the likes of:

>>

>> Load Path: /efi\boot\bootaa64.efi

>>

>> What step of the sequencing for the overall system update?

>> When is such an update required? (Here the example would

>> be: Before rebooting when the ZFS pool(s) possibly used to

>> boot gain new features?) When is it not required to update

>> the loader in the ESP (or analogous)? Even just knowing

>> the stage at which one should do the update indicates some

>> about when to figure out if an update is needed and so

>> prompts to be ready.

>>

>

> Today:

>

> make installworld installkernel



The procedure documented in the Handbook (section 24.6), and which

I have always followed, is to install the kernel, reboot, and then

make installworld.

Yes. And that reboot is =
tricky. Do not zpool upgrade at this stage. That's
the only r=
eason you *MUST* update boot blocks that we don't put in updating.
And so far, there's no reason to put something specific in UPDATI=
NG,
though we did with the OpenZFS import since there was the zpo=
ol upgrade
issue then for sure.

Well, th=
e other reason you'd need to upgrade your boot loader is if you
create a new zpool to put root on...

I think we=
 likely need a generic note in UPDATING...
=C2=A0
The reason is to add any new kernel=
 facilities

used by libc or sysadmin utilities before installing components

that require them.=C2=A0 I think that loader updates need to be an

exception to the rule, not the rule.=C2=A0 This means that notes in

UPDATING are crucial for required loader updates (e.g. when zfs is

updated in a non-backward-compatible way.=C2=A0 Of course, the handbook

does not mention upgrading loader.efi in the efi partition in the

section on upgrading from source.

Corre=
ct. Generally, we try very hard to not make incompatible updates
=
to the boot loader. Generally, it can boot old and new kernels, can cope
with the different scripts that might be present, etc. The zpool up=
grade
thing is a new wrinkle that we might want to, honestly, rev=
isit policy
around (eg, have a treat unsupported features of the =
zpool as a warning
and give it your best shot). While we've h=
ad ZFS support forever, upstream
OpenZFS seems to accumulate more=
 new features than we did at a faster
rate than before we switche=
d.
=C2=A0

Fwiw, I thought that incompatible zpool updates were not supposed

to be enabled until =E2=80=9Czpool upgrade=E2=80=9D is run, so that older k=
ernels

could access them.=C2=A0 This seems like it show go for loaders as well.
This may be difficult during a development cycle, hence the need for

UPDATING information.

To date, that'=
;s been 100% true of every instance of this that I've investigated.

UPDATING likely needs to only be updated to admonish =
against zpool upgrade
without updating the boot blocks.

Warner
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike



> mount -t msdos /dev/<mumble-esp> /boot/efi

>

> and then one of three scenarios

>

> (1) You have the old boot1.efi. This will *always* be in

> ESP:EFI\BOOT\BOOT${ARCH}.EFI.

> (see uefi(8) for the values of ARCH). You can automatically detect thi=
s for

> most installations

> that were done since about FreeBSD 12:

> % sudo efivar | grep Boot1

> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path

> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

>

> In this case you would do:

>

> % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you a=
re

> done.

>

> Please note: If your system was installed a long time ago, you should =
also

> check to see if

> you have a LoaderPath variable set:

> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> /boot/loader.efi

>

> When Boot1 isn't set and it is set to the above value (or somethin=
g

> similar), then you are

> booting with a really old copy of boot1.efi. You will need to update i=
t and

> may need to arrange

> for a larger ESP since FreeBSD's boot1.efifat was a tiny image tha=
t was

> hard to grow. Steal

> space from swap for a larger ESP, etc. Documenting that is beyond the =
scope

> of this email.

>

> (2) You are booting with loader.efi and it is in the bug-compatibility=


> place. Some UEFI BIOSes

> don't respect or can't set BootXXXX variables set by efibootmg=
r(8). In that

> case, many people

> are booting from the 'compatibiltiy' location for removable de=
vices. This

> will almost always be

> a single boot scenario because you can't easily boot other systems=
 like

> this (well, unless 'quit'

> works from the OK prompt to go to the next one on the list, but I digr=
ess).

> You will see something like:

>

> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath

> \EFI\BOOT\BOOTX64.EFI

> (or AA64)

>

> when you are booting this way. In this case the update command is:

>

> % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi

>

> to upgrade. Some people may be doing this already on systems that can<=
br>
> support efibootmgr(8) and

> they can of course upgrade to using that, though that's also beyon=
d the

> scope of this email.

>

> (3) You are booting on a working system with a FreeBSD installed by th=
e

> boot loader, or some other

> custom arrangement. In that case, you'll see something like:

> sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath

> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath

> \EFI\FREEBSD\LOADER.EFI

>

> (or some other place for custom setups: I assume if you are doing that=
 you

> know enough to

> update my instructions as appropriate). To update, you'd do

>

> % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

>

> Automating all these cases is, needless to say, tricky.

>

>

>> Part of the sequencing gets into having needed to do a

>> installworld to have a from-same-build content replacement

>> for the likes of /efi\boot\bootaa64.efi . So installkernel

>> already done, a reboot already done, and an installworld

>> having been done as well in order to have something to

>> copy over. (There are no pointers to alternate places to

>> get copies that I know of. One can find copies in the

>> build tree when one builds from source locally. So waiting

>> is not really required for that context.)

>>

>

> Yea, I have a branch that has an 'installboot' target that upd=
ates the boot

> loader regardless, but given the 50-odd combinations of ways we can
> boot, it's a bit bogged down.

>

>

>> This also make it seem that updating ZFS pool features

>> should wait until after a system upgrade that spans both

>> the loader and kernel being ready for the new features,

>> even if compatibility with other systems is not a worry.

>>

>

> Yes. ALWAYS update your boot blocks before zpool update.

>

>

>> Do any of the system upgrade instructions cover such

>> relationships? Do any of the ZFS pool upgrade instructions

>> cover such? Does zpool or the like suggest such issues

>> when it reports there are new features that could be

>> enabled?

>>

>

> See above. :)

>

>

>> Part of what I expect happened here was contributed to by

>> a lack of being prompted to even think about the relevant

>> issues, leading to a pool feature upgrade that had not

>> been prepared for.

>>

>

> Yea, so far 100% of the 'help, I upgraded and now the boot loader<=
br>
> can't see zfs pool' issues have been 'I didn't upgrade=
 my loader.efi

> properly after zpool upgrade.' It was mandatory when we had the
> OpenZFS rebase, but it is also necessary every few OpenZFS

> updates from upstream as nnew features are enabled.

>

> I'd love for someone to add this information to the handbook, and =
I'd

> happily review such an effort. I have time to do a brain dump, but not=


> to make it pretty / formatted for asciidoctor and won't for some t=
ime.

>

> Warner

>

>

>> =3D=3D=3D

>> Mark Millard

>> marklmi at yahoo.com

>>

>>




--000000000000e2818c05e80789c5--

From nobody Tue Sep  6 21:41:47 2022
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 4MMf3w6xWkz4blPL
	for ; Tue,  6 Sep 2022 21:42:04 +0000 (UTC)
	(envelope-from SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MMf3v6PXVz3xJp
	for ; Tue,  6 Sep 2022 21:42:03 +0000 (UTC)
	(envelope-from SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 6 Sep 2022 23:41:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1662500507;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=akiZ28KRadgp58ennafSVsj9t3fKmPIl2noqZQyPEJg=;
	b=TI3Eoc9cOZx4ILQka52CQdT8nLrWeYtZUeRGFdlm5P3YqwcmYpK5lCKvha7+/g5kcHR9y5
	Yv2exPqmQMg0FOiLpUWOdpbgcrwFvaRPRZgD9F4LAiSERktzC0DqAwkd/KHiFtuLygxCGO
	D2C0zCgB4mw7U6HyjF/fBTTQGqvD+J53z6lVKRz3cu57Y/hKq20CzY89TguL5EN0WTSXDv
	XB4451dsycy7kIF5AZOTOV3p8laDfeujExnp0y4BkcvZg4oqTnzUaqRWaV5BjOqQbC4RaO
	i8fjJTA6NnFlFYLyBvDTGHJrf1hyJpTLEDBjMCmXNJiNMT5TfXw4KBs/todrig==
From: Ronald Klop 
To: freebsd-arm , Warner Losh ,
	Mark Millard 
Message-ID: <1098569247.12297.1662500507113@localhost>
In-Reply-To: 
Subject: Re: kernel update broke -current
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="----=_Part_12296_882797294.1662500507110"
X-Mailer: Realworks (623.121)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MMf3v6PXVz3xJp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=TI3Eoc9c;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FREEMAIL_TO(0.00)[freebsd.org,bsdimp.com,yahoo.com];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_12296_882797294.1662500507110
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable

Van: Warner Losh 
Datum: 6 september 2022 18:13
Aan: Mark Millard 
CC: freebsd-arm 
Onderwerp: Re: kernel update broke -current

>=20
>=20
>=20
>=20
>=20
>=20
> On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:
>=20
>> Warner Losh  wrote on
>> Date: Mon, 05 Sep 2022 20:07:33 UTC :
>>=20
>> > On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
>> >=20
>> > > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
>> > > >
>> > > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
>> > > >> You need a newer boot loader...
>> > > >
>> > > >I was thinking - getting latest -current image, booting to it then
>> > > >copying the contents of /boot from the image onto the mounted zpool=
 ...
>> > > >
>> > > >feasible?
>> > >
>> > > Seems only EFI/ needed replacing from a recent snapshot. I thought i=
t might
>> > > be all of /boot but I was wrong. Thank you Mark!
>> > >
>> >=20
>> > Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
>> > updated
>> > when you do an installworld.
>>=20
>> One of the oddities of the update sequence instructions is
>> the lack of coverage of the likes of:
>>=20
>> Load Path: /efi=08oot=08ootaa64.efi
>>=20
>> What step of the sequencing for the overall system update?
>> When is such an update required? (Here the example would
>> be: Before rebooting when the ZFS pool(s) possibly used to
>> boot gain new features?) When is it not required to update
>> the loader in the ESP (or analogous)? Even just knowing
>> the stage at which one should do the update indicates some
>> about when to figure out if an update is needed and so
>> prompts to be ready.
>=20
>=20
> Today:
>=20
> make installworld installkernel
> mount -t msdos /dev/ /boot/efi
>=20
> and then one of three scenarios
>=20
> (1) You have the old boot1.efi. This will *always* be in ESP:EFIBOOTBOOT$=
{ARCH}.EFI.
> (see uefi(8) for the values of ARCH). You can automatically detect this f=
or most installations
> that were done since about FreeBSD 12:
> % sudo efivar | grep Boot1
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev
>=20
>=20
> In this case you would do:
>=20
> % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you are =
done.
>=20
> Please note: If your system was installed a long time ago, you should als=
o check to see if
> you have a LoaderPath variable set:
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>=20
> /boot/loader.efi
>=20
> When Boot1 isn't set and it is set to the above value (or something simil=
ar), then you are
> booting with a really old copy of boot1.efi. You will need to update it a=
nd may need to arrange
> for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was h=
ard to grow. Steal
> space from swap for a larger ESP, etc. Documenting that is beyond the sco=
pe of this email.
>=20
> (2) You are booting with loader.efi and it is in the bug-compatibility pl=
ace. Some UEFI BIOSes
> don't respect or can't set BootXXXX variables set by efibootmgr(8). In th=
at case, many people
> are booting from the 'compatibiltiy' location for removable devices. This=
 will almost always be
> a single boot scenario because you can't easily boot other systems like t=
his (well, unless 'quit'
> works from the OK prompt to go to the next one on the list, but I digress=
). You will see something like:
>=20
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> EFIBOOTBOOTX64.EFI
> (or AA64)
>=20
> when you are booting this way. In this case the update command is:
>=20
> % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
>=20
> to upgrade. Some people may be doing this already on systems that can sup=
port efibootmgr(8) and
> they can of course upgrade to using that, though that's also beyond the s=
cope of this email.
>=20
> (3) You are booting on a working system with a FreeBSD installed by the b=
oot loader, or some other
> custom arrangement. In that case, you'll see something like:
> sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> EFIFREEBSDLOADER.EFI
>=20
> (or some other place for custom setups: I assume if you are doing that yo=
u know enough to
> update my instructions as appropriate). To update, you'd do
>=20
> % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
>=20
> Automating all these cases is, needless to say, tricky.
>=20
> =20
>> Part of the sequencing gets into having needed to do a
>> installworld to have a from-same-build content replacement
>> for the likes of /efi=08oot=08ootaa64.efi . So installkernel
>> already done, a reboot already done, and an installworld
>> having been done as well in order to have something to
>> copy over. (There are no pointers to alternate places to
>> get copies that I know of. One can find copies in the
>> build tree when one builds from source locally. So waiting
>> is not really required for that context.)
>=20
>=20
> Yea, I have a branch that has an 'installboot' target that updates the bo=
ot
> loader regardless, but given the 50-odd combinations of ways we can
> boot, it's a bit bogged down.
> =20
>> This also make it seem that updating ZFS pool features
>> should wait until after a system upgrade that spans both
>> the loader and kernel being ready for the new features,
>> even if compatibility with other systems is not a worry.
>=20
>=20
> Yes. ALWAYS update your boot blocks before zpool update.
> =20
>> Do any of the system upgrade instructions cover such
>> relationships? Do any of the ZFS pool upgrade instructions
>> cover such? Does zpool or the like suggest such issues
>> when it reports there are new features that could be
>> enabled?
>=20
>=20
> See above. :)
> =20
>> Part of what I expect happened here was contributed to by
>> a lack of being prompted to even think about the relevant
>> issues, leading to a pool feature upgrade that had not
>> been prepared for.
>=20
>=20
> Yea, so far 100% of the 'help, I upgraded and now the boot loader
> can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
> properly after zpool upgrade.' It was mandatory when we had the
> OpenZFS rebase, but it is also necessary every few OpenZFS
> updates from upstream as nnew features are enabled.
>=20
> I'd love for someone to add this information to the handbook, and I'd
> happily review such an effort. I have time to do a brain dump, but not
> to make it pretty / formatted for asciidoctor and won't for some time.
>=20
> Warner
> =20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>=20
>=20


Interesting.=20
Does the loader pass a hint to the kernel about which loader was used to lo=
ad the kernel?

Regards,
Ronald

------=_Part_12296_882797294.1662500507110
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable


Van: Warner Losh &l=
t;imp@bsdimp.com>
Datum: 6 september 2022 18:13
<=
strong>Aan: Mark Millard <marklmi@yahoo.com>
CC:<=
/strong> freebsd-arm <freebsd-arm@freebsd.org>
Onderwerp:<=
/strong> Re: kernel update broke -current








On Mon, Sep 5, 2022 at 4:21 PM Mark Millard <=
marklmi@yahoo.com> wrote:
Warner Losh <imp_at_bsdimp.com> wrote on

Date: Mon, 05 Sep 2022 20:07:33 UTC :



> On Sun, Sep 4, 2022 at 4:51 PM void <=
void@f-m.fm> wrote:

> 

> > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:

> > >

> > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

> > >> You need a newer boot loader...

> > >

> > >I was thinking - getting latest -current image, booting to it=
 then

> > >copying the contents of /boot from the image onto the mounted=
 zpool ...

> > >

> > >feasible?

> >

> > Seems only EFI/ needed replacing from a recent snapshot. I though=
t it might

> > be all of /boot but I was wrong. Thank you Mark!

> >

> 

> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is<=
br>
> updated

> when you do an installworld.



One of the oddities of the update sequence instructions is

the lack of coverage of the likes of:



Load Path: /efiootootaa64.efi



What step of the sequencing for the overall system update?

When is such an update required? (Here the example would

be: Before rebooting when the ZFS pool(s) possibly used to

boot gain new features?) When is it not required to update

the loader in the ESP (or analogous)? Even just knowing

the stage at which one should do the update indicates some

about when to figure out if an update is needed and so

prompts to be ready.

Today:

=

make installworld installkernel
mount -t msdos /dev/<mumble-esp> /boot/efi<=
/div>

an=
d then one of three scenarios

<=
div class=3D"do_not_remove">(1) You have the old boot1.efi. This will *alwa=
ys* be in ESP:EFIBOOTBOOT${ARCH}.EFI.
(se=
e uefi(8) for the values of ARCH). You can automatically detect this for mo=
st installations
that were done since abo=
ut FreeBSD 12:
% sudo efivar | grep Boot1=

cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boo=
t1Path
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

In this case you =
would do:

% sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and yo=
u are done.

Please note: If your system was installed a long time ago, you sh=
ould also check to see if
you have a Load=
erPath variable set:
% sudo efivar --utf =
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
/boot/loader.efi

When Boot1 isn't set and it is set to the above v=
alue (or something similar), then you are
booting with a really old copy of boot1.efi. You will need to update it an=
d may need to arrange
for a larger ESP si=
nce FreeBSD's boot1.efifat was a tiny image that was hard to grow. Steal
space from swap for a larger ESP, etc. Docu=
menting that is beyond the scope of this email.

(2) You are booting with load=
er.efi and it is in the bug-compatibility place. Some UEFI BIOSes
don't respect or can't set BootXXXX variables set =
by efibootmgr(8). In that case, many people
are booting from the 'compatibiltiy' location for removable devices=
. This will almost always be
a single boo=
t scenario because you can't easily boot other systems like this (well, unl=
ess 'quit'
works from the OK prompt to go=
 to the next one on the list, but I digress). You will see something like:<=
/div>

% =
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee=
69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIBOOTBOOTX64.EFI
(or AA64)

when y=
ou are booting this way. In this case the update command is:

% sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
=


to upgrade. Some people may be doing this already on syste=
ms that can support efibootmgr(8) and
they can of course upgrade to using that, though that's also beyon=
d the scope of this email.
(3) You are booting on a w=
orking system with a FreeBSD installed by the boot loader, or some other
custom arrangement. In that cas=
e, you'll see something like:
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee6=
9ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIFREEBSDLOADER.EFI

(or some other place for custom setups: I assume if you are d=
oing that you know enough to
=
update my instructions as appropriate). To update, you'd do

% sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

Automating all these cases is, needless to say, tricky.
 

Part of the sequencing gets into having needed to do a

installworld to have a from-same-build content replacement

for the likes of /efiootootaa64.efi . So installkernel

already done, a reboot already done, and an installworld

having been done as well in order to have something to

copy over. (There are no pointers to alternate places to

get copies that I know of. One can find copies in the

build tree when one builds from source locally. So waiting

is not really required for that context.)

Yea, I have a branch tha=
t has an 'installboot' target that updates the boot
loader regardless, but given the 50-odd combinations of ways we =
can
boot, it's a bit bogged down.
 

This also make it seem that updating ZFS pool features

should wait until after a system upgrade that spans both

the loader and kernel being ready for the new features,

even if compatibility with other systems is not a worry.

Yes. ALWA=
YS update your boot blocks before zpool update.
 

Do any of the system upgrade instructions cover such

relationships? Do any of the ZFS pool upgrade instructions

cover such? Does zpool or the like suggest such issues

when it reports there are new features that could be

enabled?

See above. :)
 

Part of what I expect happened here was contributed to by

a lack of being prompted to even think about the relevant

issues, leading to a pool feature upgrade that had not

been prepared for.

<=
div class=3D"do_not_remove">Yea, so far 100% of the 'help, I upgraded and n=
ow the boot loader
can't see zfs pool' is=
sues have been 'I didn't upgrade my loader.efi
properly after zpool upgrade.' It was mandatory when we had the
=

OpenZFS rebase, but it is also necessary every=
 few OpenZFS
updates from upstream as nne=
w features are enabled.

I'd love for someone to add this information to the h=
andbook, and I'd
happily review such=
 an effort. I have time to do a brain dump, but not
to make it pretty / formatted for asciidoctor and won't for some=
 time.

Warner
 

=3D=3D=3D

Mark Millard

marklmi at yahoo.com











Interesting. 
Does the loader pass a hint to t=
he kernel about which loader was used to load the kernel?

Regards,
Ronald



------=_Part_12296_882797294.1662500507110--

From nobody Tue Sep  6 22:31:03 2022
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 4MMg8T608cz4br4w
	for ; Tue,  6 Sep 2022 22:31:05 +0000 (UTC)
	(envelope-from SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MMg8T1CZsz41K8
	for ; Tue,  6 Sep 2022 22:31:05 +0000 (UTC)
	(envelope-from SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl)
Date: Wed, 7 Sep 2022 00:31:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1662503463;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=I1OlrR/liORCbpuyyNVQhCdDrCobjv/iXEO4fYdG8Ik=;
	b=F6ie/Vf5W/RudDigz22VGOK7DOP9rnBihXTdj5hf5Y9OKuWa1zcbyPT/BRNp4LNWuO8YC+
	DxkqdqDbxDzVLBPzGxr8M5HrIbchUjRE5hAzFEhRldro39F7NP6hCOmPUR68v2ha90aELT
	Kkqo6XOC/pyDgCnARz4wcjxx/9uE1TE5vVbXeMrxOsC6abeKlkMjH1R8XOYIpijbXqMVmm
	Fn5udb4u9EXOAyYyJWUPHur7dg/FcUb52g7En/MxVx2D6WCfyVNY0AefbX1DfoO31vaKBb
	sKoCKcD8wyXNUarQu0wwcLJND753jnfL5iQFeFbJA36BUkFRkwlZD7NINgzvfw==
From: Ronald Klop 
To: freebsd-arm , Mark Millard ,
	Warner Losh 
Message-ID: <1146974959.11767.1662503463234@localhost>
In-Reply-To: <1098569247.12297.1662500507113@localhost>
Subject: Re: kernel update broke -current
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="----=_Part_11766_902161602.1662503463230"
X-Mailer: Realworks (623.121)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MMg8T1CZsz41K8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b="F6ie/Vf5";
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FREEMAIL_TO(0.00)[freebsd.org,yahoo.com,bsdimp.com];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=HFBQ=ZJ=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_11766_902161602.1662503463230
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Van: Ronald Klop 
Datum: 6 september 2022 23:42
Aan: freebsd-arm , Warner Losh , Mark Millard 
Onderwerp: Re: kernel update broke -current

> 
> 
> 
> 
> 
> Van: Warner Losh 
> Datum: 6 september 2022 18:13
> Aan: Mark Millard 
> CC: freebsd-arm 
> Onderwerp: Re: kernel update broke -current
> 
>> 
>> 
>> 
>> On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:
>> 
>>> Warner Losh  wrote on
>>> Date: Mon, 05 Sep 2022 20:07:33 UTC :
>>> 
>>> > On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
>>> > 
>>> > > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
>>> > > >
>>> > > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
>>> > > >> You need a newer boot loader...
>>> > > >
>>> > > >I was thinking - getting latest -current image, booting to it then
>>> > > >copying the contents of /boot from the image onto the mounted zpool ...
>>> > > >
>>> > > >feasible?
>>> > >
>>> > > Seems only EFI/ needed replacing from a recent snapshot. I thought it might
>>> > > be all of /boot but I was wrong. Thank you Mark!
>>> > >
>>> > 
>>> > Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
>>> > updated
>>> > when you do an installworld.
>>> 
>>> One of the oddities of the update sequence instructions is
>>> the lack of coverage of the likes of:
>>> 
>>> Load Path: /efiootootaa64.efi
>>> 
>>> What step of the sequencing for the overall system update?
>>> When is such an update required? (Here the example would
>>> be: Before rebooting when the ZFS pool(s) possibly used to
>>> boot gain new features?) When is it not required to update
>>> the loader in the ESP (or analogous)? Even just knowing
>>> the stage at which one should do the update indicates some
>>> about when to figure out if an update is needed and so
>>> prompts to be ready.
>> 
>> 
>> Today:
>> 
>> make installworld installkernel
>> mount -t msdos /dev/ /boot/efi
>> 
>> and then one of three scenarios
>> 
>> (1) You have the old boot1.efi. This will *always* be in ESP:EFIBOOTBOOT${ARCH}.EFI.
>> (see uefi(8) for the values of ARCH). You can automatically detect this for most installations
>> that were done since about FreeBSD 12:
>> % sudo efivar | grep Boot1
>> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
>> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev
>> 
>> 
>> In this case you would do:
>> 
>> % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you are done.
>> 
>> Please note: If your system was installed a long time ago, you should also check to see if
>> you have a LoaderPath variable set:
>> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>> 
>> /boot/loader.efi
>> 
>> When Boot1 isn't set and it is set to the above value (or something similar), then you are
>> booting with a really old copy of boot1.efi. You will need to update it and may need to arrange
>> for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was hard to grow. Steal
>> space from swap for a larger ESP, etc. Documenting that is beyond the scope of this email.
>> 
>> (2) You are booting with loader.efi and it is in the bug-compatibility place. Some UEFI BIOSes
>> don't respect or can't set BootXXXX variables set by efibootmgr(8). In that case, many people
>> are booting from the 'compatibiltiy' location for removable devices. This will almost always be
>> a single boot scenario because you can't easily boot other systems like this (well, unless 'quit'
>> works from the OK prompt to go to the next one on the list, but I digress). You will see something like:
>> 
>> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>> EFIBOOTBOOTX64.EFI
>> (or AA64)
>> 
>> when you are booting this way. In this case the update command is:
>> 
>> % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
>> 
>> to upgrade. Some people may be doing this already on systems that can support efibootmgr(8) and
>> they can of course upgrade to using that, though that's also beyond the scope of this email.
>> 
>> (3) You are booting on a working system with a FreeBSD installed by the boot loader, or some other
>> custom arrangement. In that case, you'll see something like:
>> sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
>> EFIFREEBSDLOADER.EFI
>> 
>> (or some other place for custom setups: I assume if you are doing that you know enough to
>> update my instructions as appropriate). To update, you'd do
>> 
>> % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
>> 
>> Automating all these cases is, needless to say, tricky.
>> 
>>  
>>> Part of the sequencing gets into having needed to do a
>>> installworld to have a from-same-build content replacement
>>> for the likes of /efiootootaa64.efi . So installkernel
>>> already done, a reboot already done, and an installworld
>>> having been done as well in order to have something to
>>> copy over. (There are no pointers to alternate places to
>>> get copies that I know of. One can find copies in the
>>> build tree when one builds from source locally. So waiting
>>> is not really required for that context.)
>> 
>> 
>> Yea, I have a branch that has an 'installboot' target that updates the boot
>> loader regardless, but given the 50-odd combinations of ways we can
>> boot, it's a bit bogged down.
>>  
>>> This also make it seem that updating ZFS pool features
>>> should wait until after a system upgrade that spans both
>>> the loader and kernel being ready for the new features,
>>> even if compatibility with other systems is not a worry.
>> 
>> 
>> Yes. ALWAYS update your boot blocks before zpool update.
>>  
>>> Do any of the system upgrade instructions cover such
>>> relationships? Do any of the ZFS pool upgrade instructions
>>> cover such? Does zpool or the like suggest such issues
>>> when it reports there are new features that could be
>>> enabled?
>> 
>> 
>> See above. :)
>>  
>>> Part of what I expect happened here was contributed to by
>>> a lack of being prompted to even think about the relevant
>>> issues, leading to a pool feature upgrade that had not
>>> been prepared for.
>> 
>> 
>> Yea, so far 100% of the 'help, I upgraded and now the boot loader
>> can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
>> properly after zpool upgrade.' It was mandatory when we had the
>> OpenZFS rebase, but it is also necessary every few OpenZFS
>> updates from upstream as nnew features are enabled.
>> 
>> I'd love for someone to add this information to the handbook, and I'd
>> happily review such an effort. I have time to do a brain dump, but not
>> to make it pretty / formatted for asciidoctor and won't for some time.
>> 
>> Warner
>>  
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>>> 
>> 
> 
> 
> Interesting. 
> Does the loader pass a hint to the kernel about which loader was used to load the kernel?
> 
> Regards,
> Ronald
> 
> 

Oh I pressed send too soon. I now understand all the tools you already mentioned.
Sorry for the noise. 

Regards

------=_Part_11766_902161602.1662503463230
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable


Van: Ronald Klop &l=
t;ronald-lists@klop.ws>
Datum: 6 september 2022 23:4=
2
Aan: freebsd-arm <freebsd-arm@freebsd.org>, War=
ner Losh <imp@bsdimp.com>, Mark Millard <marklmi@yahoo.com>
=
Onderwerp: Re: kernel update broke -current






Van: Warner Losh <imp@bsdimp.com>
<=
strong>Datum: 6 september 2022 18:13
Aan: Mark=
 Millard <marklmi@yahoo.com>
CC: freebsd-arm <=
freebsd-arm@freebsd.org>
Onderwerp: Re: kernel updat=
e broke -current








On Mon, Sep 5, 2022 at 4:21 PM Mark Millard <=
marklmi@yahoo.com> wrote:
Warner Losh <imp_at_bsdimp.com> wrote on

Date: Mon, 05 Sep 2022 20:07:33 UTC :



> On Sun, Sep 4, 2022 at 4:51 PM void <=
void@f-m.fm> wrote:

> 

> > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:

> > >

> > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

> > >> You need a newer boot loader...

> > >

> > >I was thinking - getting latest -current image, booting to it=
 then

> > >copying the contents of /boot from the image onto the mounted=
 zpool ...

> > >

> > >feasible?

> >

> > Seems only EFI/ needed replacing from a recent snapshot. I though=
t it might

> > be all of /boot but I was wrong. Thank you Mark!

> >

> 

> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is<=
br>
> updated

> when you do an installworld.



One of the oddities of the update sequence instructions is

the lack of coverage of the likes of:



Load Path: /efiootootaa64.efi



What step of the sequencing for the overall system update?

When is such an update required? (Here the example would

be: Before rebooting when the ZFS pool(s) possibly used to

boot gain new features?) When is it not required to update

the loader in the ESP (or analogous)? Even just knowing

the stage at which one should do the update indicates some

about when to figure out if an update is needed and so

prompts to be ready.

Today:

=

make installworld installkernel
mount -t msdos /dev/<mumble-esp> /boot/efi<=
/div>

an=
d then one of three scenarios

<=
div class=3D"do_not_remove">(1) You have the old boot1.efi. This will *alwa=
ys* be in ESP:EFIBOOTBOOT${ARCH}.EFI.
(se=
e uefi(8) for the values of ARCH). You can automatically detect this for mo=
st installations
that were done since abo=
ut FreeBSD 12:
% sudo efivar | grep Boot1=

cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boo=
t1Path
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

In this case you =
would do:

% sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and yo=
u are done.

Please note: If your system was installed a long time ago, you sh=
ould also check to see if
you have a Load=
erPath variable set:
% sudo efivar --utf =
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
/boot/loader.efi

When Boot1 isn't set and it is set to the above v=
alue (or something similar), then you are
booting with a really old copy of boot1.efi. You will need to update it an=
d may need to arrange
for a larger ESP si=
nce FreeBSD's boot1.efifat was a tiny image that was hard to grow. Steal
space from swap for a larger ESP, etc. Docu=
menting that is beyond the scope of this email.

(2) You are booting with load=
er.efi and it is in the bug-compatibility place. Some UEFI BIOSes
don't respect or can't set BootXXXX variables set =
by efibootmgr(8). In that case, many people
are booting from the 'compatibiltiy' location for removable devices=
. This will almost always be
a single boo=
t scenario because you can't easily boot other systems like this (well, unl=
ess 'quit'
works from the OK prompt to go=
 to the next one on the list, but I digress). You will see something like:<=
/div>

% =
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee=
69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIBOOTBOOTX64.EFI
(or AA64)

when y=
ou are booting this way. In this case the update command is:

% sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
=


to upgrade. Some people may be doing this already on syste=
ms that can support efibootmgr(8) and
they can of course upgrade to using that, though that's also beyon=
d the scope of this email.
(3) You are booting on a w=
orking system with a FreeBSD installed by the boot loader, or some other
custom arrangement. In that cas=
e, you'll see something like:
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
cfee6=
9ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIFREEBSDLOADER.EFI

(or some other place for custom setups: I assume if you are d=
oing that you know enough to
=
update my instructions as appropriate). To update, you'd do

% sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

Automating all these cases is, needless to say, tricky.
 

Part of the sequencing gets into having needed to do a

installworld to have a from-same-build content replacement

for the likes of /efiootootaa64.efi . So installkernel

already done, a reboot already done, and an installworld

having been done as well in order to have something to

copy over. (There are no pointers to alternate places to

get copies that I know of. One can find copies in the

build tree when one builds from source locally. So waiting

is not really required for that context.)

Yea, I have a branch tha=
t has an 'installboot' target that updates the boot
loader regardless, but given the 50-odd combinations of ways we =
can
boot, it's a bit bogged down.
 

This also make it seem that updating ZFS pool features

should wait until after a system upgrade that spans both

the loader and kernel being ready for the new features,

even if compatibility with other systems is not a worry.

Yes. ALWA=
YS update your boot blocks before zpool update.
 

Do any of the system upgrade instructions cover such

relationships? Do any of the ZFS pool upgrade instructions

cover such? Does zpool or the like suggest such issues

when it reports there are new features that could be

enabled?

See above. :)
 

Part of what I expect happened here was contributed to by

a lack of being prompted to even think about the relevant

issues, leading to a pool feature upgrade that had not

been prepared for.

<=
div class=3D"do_not_remove">Yea, so far 100% of the 'help, I upgraded and n=
ow the boot loader
can't see zfs pool' is=
sues have been 'I didn't upgrade my loader.efi
properly after zpool upgrade.' It was mandatory when we had the
=

OpenZFS rebase, but it is also necessary every=
 few OpenZFS
updates from upstream as nne=
w features are enabled.

I'd love for someone to add this information to the h=
andbook, and I'd
happily review such=
 an effort. I have time to do a brain dump, but not
to make it pretty / formatted for asciidoctor and won't for some=
 time.

Warner
 

=3D=3D=3D

Mark Millard

marklmi at yahoo.com











Interesting. 
Does the loader pass a hint to t=
he kernel about which loader was used to load the kernel?

Regards,
Ronald


<=
/div>



Oh I pressed send too soon. I now understand all the tools=
 you already mentioned.
Sorry for the noise. 

=
Regards



------=_Part_11766_902161602.1662503463230--

From nobody Wed Sep  7 00:13:29 2022
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 4MMjQt2DRzz4c25n
	for ; Wed,  7 Sep 2022 00:13:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b])
	(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 4MMjQs4gdnz47mY
	for ; Wed,  7 Sep 2022 00:13:41 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2b.google.com with SMTP id d126so13288946vsd.13
        for ; Tue, 06 Sep 2022 17:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=tttq3CkPU1Z7OPk0C07hjzt2vTqZbb9PhRQ3O7+74W0=;
        b=3WS+3vECiG8uC0k612pHlm5QLP1EphwQ2FILASr57MXZwWgKtiofFGKzXJvtSO1rFV
         TzFSey/LkQC1w1WYjSzYdke02eiUdQ1flZORiRuErESh/jT81PSyQ2cF3e8hJcl9i7cj
         p1pb2Ct2q9Oiz9i2aD6EhmSfwb8mg83xyOJ1edZeKFVshZFirmcZ7xYFbxMegtEhgTaI
         uPcueaVnXZR3frsEx0X0mKK6xEh8tzlV5s/DkN1MF1R4bHWWhoSvI/D2JjwPz0cg0Q06
         rQ/SVfm+p54SZKFW9YiddwsiwFbisEJGVlylrQZhkfy3+pnDmDASpvevHdF0mB48pClP
         j/Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=tttq3CkPU1Z7OPk0C07hjzt2vTqZbb9PhRQ3O7+74W0=;
        b=n2Bc4EC4WO+jvTJBlDntxatW5+Nu0TNMV/X50ncZ2r7pd8uhdg9CiLBNDZkQQbz2P+
         tZYanLVpjKo68r1wOqRQp/pJj23w85+a7yIu4oMSWHZUxpj6G9ESfos6oFspiP6VVP31
         iayVH6TNTrxMDSaEMFfJzd8Hfreic8cZR294UjPKZBWEYVel1b5k0G1Zb0CnOyNxghrN
         c+wd2MoephWrZsaAGHr+z6TUVypZOmr+x5f80NYOR217d2TUfPj/yUImJKHHTp2a8ARE
         +Hz/OtjB0ESXm2LUvFZbOD9HXJ0/Nnqggarvb2jfowF5u8dfjU17o243hAQfB+lF9tB3
         bA9Q==
X-Gm-Message-State: ACgBeo2TmYhh/Y4Er8uSonEtIt9aARV2Bwlw5uyrnNvfPeDT9u9ekGPe
	93d2k3p/iJGElFVg1dUMKwxfCZtEYiDlq5Uq5YhM7g==
X-Google-Smtp-Source: AA6agR77DgX6j4lTRjDg++4aBIksnZzUEy52xEpstV6EIjvMAC+KnxsswJQbABjdUi2K7GwU2FfTozuUf/UxQqhz7cA=
X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id
 n5-20020a67ac45000000b00388a1ff7e89mr335347vsh.42.1662509620829; Tue, 06 Sep
 2022 17:13:40 -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: <1098569247.12297.1662500507113@localhost> <1146974959.11767.1662503463234@localhost>
In-Reply-To: <1146974959.11767.1662503463234@localhost>
From: Warner Losh 
Date: Tue, 6 Sep 2022 18:13:29 -0600
Message-ID: 
Subject: Re: kernel update broke -current
To: Ronald Klop 
Cc: freebsd-arm , Mark Millard 
Content-Type: multipart/alternative; boundary="00000000000062b97b05e80b2f52"
X-Rspamd-Queue-Id: 4MMjQs4gdnz47mY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=3WS+3vEC;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2b) smtp.mailfrom=wlosh@bsdimp.com
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)[-0.998];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2b:from];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[freebsd.org,yahoo.com]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000062b97b05e80b2f52
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 6, 2022 at 4:31 PM Ronald Klop  wrote:

>
> *Van:* Ronald Klop 
> *Datum:* 6 september 2022 23:42
> *Aan:* freebsd-arm , Warner Losh ,
> Mark Millard 
> *Onderwerp:* Re: kernel update broke -current
>
>
> *Van:* Warner Losh 
> *Datum:* 6 september 2022 18:13
> *Aan:* Mark Millard 
> *CC:* freebsd-arm 
> *Onderwerp:* Re: kernel update broke -current
>
>
>
> On Mon, Sep 5, 2022 at 4:21 PM Mark Millard  wrote:
>
>> Warner Losh  wrote on
>> Date: Mon, 05 Sep 2022 20:07:33 UTC :
>>
>> > On Sun, Sep 4, 2022 at 4:51 PM void  wrote:
>> >
>> > > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:
>> > > >
>> > > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:
>> > > >> You need a newer boot loader...
>> > > >
>> > > >I was thinking - getting latest -current image, booting to it then
>> > > >copying the contents of /boot from the image onto the mounted zpool
>> ...
>> > > >
>> > > >feasible?
>> > >
>> > > Seems only EFI/ needed replacing from a recent snapshot. I thought it
>> might
>> > > be all of /boot but I was wrong. Thank you Mark!
>> > >
>> >
>> > Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot is
>> > updated
>> > when you do an installworld.
>>
>> One of the oddities of the update sequence instructions is
>> the lack of coverage of the likes of:
>>
>> Load Path: /efiootootaa64.efi
>>
>> What step of the sequencing for the overall system update?
>> When is such an update required? (Here the example would
>> be: Before rebooting when the ZFS pool(s) possibly used to
>> boot gain new features?) When is it not required to update
>> the loader in the ESP (or analogous)? Even just knowing
>> the stage at which one should do the update indicates some
>> about when to figure out if an update is needed and so
>> prompts to be ready.
>>
>
> Today:
>
> make installworld installkernel
> mount -t msdos /dev/ /boot/efi
>
> and then one of three scenarios
>
> (1) You have the old boot1.efi. This will *always* be in
> ESP:EFIBOOTBOOT${ARCH}.EFI.
> (see uefi(8) for the values of ARCH). You can automatically detect this
> for most installations
> that were done since about FreeBSD 12:
> % sudo efivar | grep Boot1
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev
>
> In this case you would do:
>
> % sudo cp /boot/boot1.efi /boot/efi/efi/boot/boot${ARCH}.efi and you are
> done.
>
> Please note: If your system was installed a long time ago, you should also
> check to see if
> you have a LoaderPath variable set:
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> /boot/loader.efi
>
> When Boot1 isn't set and it is set to the above value (or something
> similar), then you are
> booting with a really old copy of boot1.efi. You will need to update it
> and may need to arrange
> for a larger ESP since FreeBSD's boot1.efifat was a tiny image that was
> hard to grow. Steal
> space from swap for a larger ESP, etc. Documenting that is beyond the
> scope of this email.
>
> (2) You are booting with loader.efi and it is in the bug-compatibility
> place. Some UEFI BIOSes
> don't respect or can't set BootXXXX variables set by efibootmgr(8). In
> that case, many people
> are booting from the 'compatibiltiy' location for removable devices. This
> will almost always be
> a single boot scenario because you can't easily boot other systems like
> this (well, unless 'quit'
> works from the OK prompt to go to the next one on the list, but I
> digress). You will see something like:
>
> % sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> EFIBOOTBOOTX64.EFI
> (or AA64)
>
> when you are booting this way. In this case the update command is:
>
> % sudo cp /boot/loader.efi /boot/efi/efi/boot/boot${ARCH}.efi
>
> to upgrade. Some people may be doing this already on systems that can
> support efibootmgr(8) and
> they can of course upgrade to using that, though that's also beyond the
> scope of this email.
>
> (3) You are booting on a working system with a FreeBSD installed by the
> boot loader, or some other
> custom arrangement. In that case, you'll see something like:
> sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
> EFIFREEBSDLOADER.EFI
>
> (or some other place for custom setups: I assume if you are doing that you
> know enough to
> update my instructions as appropriate). To update, you'd do
>
> % sudo cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
>
> Automating all these cases is, needless to say, tricky.
>
>
>> Part of the sequencing gets into having needed to do a
>> installworld to have a from-same-build content replacement
>> for the likes of /efiootootaa64.efi . So installkernel
>> already done, a reboot already done, and an installworld
>> having been done as well in order to have something to
>> copy over. (There are no pointers to alternate places to
>> get copies that I know of. One can find copies in the
>> build tree when one builds from source locally. So waiting
>> is not really required for that context.)
>>
>
> Yea, I have a branch that has an 'installboot' target that updates the boot
> loader regardless, but given the 50-odd combinations of ways we can
> boot, it's a bit bogged down.
>
>
>> This also make it seem that updating ZFS pool features
>> should wait until after a system upgrade that spans both
>> the loader and kernel being ready for the new features,
>> even if compatibility with other systems is not a worry.
>>
>
> Yes. ALWAYS update your boot blocks before zpool update.
>
>
>> Do any of the system upgrade instructions cover such
>> relationships? Do any of the ZFS pool upgrade instructions
>> cover such? Does zpool or the like suggest such issues
>> when it reports there are new features that could be
>> enabled?
>>
>
> See above. :)
>
>
>> Part of what I expect happened here was contributed to by
>> a lack of being prompted to even think about the relevant
>> issues, leading to a pool feature upgrade that had not
>> been prepared for.
>>
>
> Yea, so far 100% of the 'help, I upgraded and now the boot loader
> can't see zfs pool' issues have been 'I didn't upgrade my loader.efi
> properly after zpool upgrade.' It was mandatory when we had the
> OpenZFS rebase, but it is also necessary every few OpenZFS
> updates from upstream as nnew features are enabled.
>
> I'd love for someone to add this information to the handbook, and I'd
> happily review such an effort. I have time to do a brain dump, but not
> to make it pretty / formatted for asciidoctor and won't for some time.
>
> Warner
>
>
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
>>
>
> Interesting.
> Does the loader pass a hint to the kernel about which loader was used to
> load the kernel?
>
> Regards,
> Ronald
>
>
>
> Oh I pressed send too soon. I now understand all the tools you already
> mentioned.
> Sorry for the noise.
>

boot1.efi and loader.efi set the UEFI environment variables I used above.
No further hints
are passed into the kernel...

Warner

--00000000000062b97b05e80b2f52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Sep 6, 2022 at 4:31 PM Ronald=
 Klop <ronald-lists@klop.ws&=
gt; wrote:

<=
p>Van: Ronald Klop <ronald-lists@klop.ws>
Datum=
: 6 september 2022 23:42
Aan: freebsd-arm <=
freebsd-arm@fr=
eebsd.org>, Warner Losh <imp@bsdimp.com>, Mark Millard <marklmi@yahoo.com>
Onder=
werp: Re: kernel update broke -current






Van: Warner Losh <imp@bsdimp.com>
Datum: 6 september 2022 18:13
Aan: Mark Millard <marklmi@yahoo.com><=
br>CC: freebsd-arm <freebsd-arm@freebsd.org>
Onderw=
erp: Re: kernel update broke -current








On Mon, Sep 5, 2022 at 4:21 PM Mark Millard <marklmi@yahoo.com> wrote:
Warner Losh <imp_at_bsdimp.com> wrote =
on

Date: Mon, 05 Sep 2022 20:07:33 UTC :



> On Sun, Sep 4, 2022 at 4:51 PM void <void@f-m.fm> wrote:

> 

> > On Sun, Sep 04, 2022 at 07:31:59PM +0000, void wrote:

> > >

> > >On Sun, 4 Sep 2022, at 19:07, Warner Losh wrote:

> > >> You need a newer boot loader...

> > >

> > >I was thinking - getting latest -current image, booting to it=
 then

> > >copying the contents of /boot from the image onto the mounted=
 zpool ...

> > >

> > >feasible?

> >

> > Seems only EFI/ needed replacing from a recent snapshot. I though=
t it might

> > be all of /boot but I was wrong. Thank you Mark!

> >

> 

> Yes. You'll need to update EFI/BOOT on your ESP. The rest of /boot=
 is

> updated

> when you do an installworld.



One of the oddities of the update sequence instructions is

the lack of coverage of the likes of:



Load Path: /efiootootaa64.efi



What step of the sequencing for the overall system update?

When is such an update required? (Here the example would

be: Before rebooting when the ZFS pool(s) possibly used to

boot gain new features?) When is it not required to update

the loader in the ESP (or analogous)? Even just knowing

the stage at which one should do the update indicates some

about when to figure out if an update is needed and so

prompts to be ready.

Today:
<=
br>
make installworld installkernel
mount -t msdos /dev=
/<mumble-esp> /boot/efi

and then one of thre=
e scenarios

(1) You have the old boot1.efi. This w=
ill *always* be in ESP:EFIBOOTBOOT${ARCH}.EFI.
(see uefi(8) for t=
he values of ARCH). You can automatically detect this for most installation=
s
that were done since about FreeBSD 12:
% sudo efivar =
| grep Boot1
cfee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Path
cf=
ee69ad-a0de-47a9-93a8-f63106f8ae99-Boot1Dev

In=
 this case you would do:

% sudo cp /boot/boot1.efi=
 /boot/efi/efi/boot/boot${ARCH}.efi and you are done.

<=
div>Please note: If your system was installed a long time ago, you should a=
lso check to see if
you have a LoaderPath variable set:
% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
/boot/loader.efi

When Boot1 isn't set =
and it is set to the above value (or something similar), then you are
=

booting with a really old copy of boot1.efi. You will need to update i=
t and may need to arrange
for a larger ESP since FreeBSD's bo=
ot1.efifat was a tiny image that was hard to grow. Steal
space fr=
om swap for a larger ESP, etc. Documenting that is beyond the scope of this=
 email.

(2) You are booting with loader.efi and it=
 is in the bug-compatibility place. Some UEFI BIOSes
don't re=
spect or can't set BootXXXX variables set by efibootmgr(8). In that cas=
e, many people
are booting from the 'compatibiltiy' locat=
ion for removable=C2=A0devices. This will almost always be
a sing=
le boot scenario because you can't easily boot other systems like this =
(well, unless 'quit'
works from the OK prompt to go to th=
e next one on the list, but I digress). You will see something like:
<=
div>
% sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99=
-LoaderPath
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIBOOT=
BOOTX64.EFI
(or AA64)

when you are booting this w=
ay. In this case the update command is:
% sudo cp /boot/loader.efi /boot/efi/efi/=
boot/boot${ARCH}.efi

to upgrade. Some people may be doing this already on syste=
ms that can support efibootmgr(8) and
they =
can of course upgrade to using that, though that's also beyond the scop=
e of this email.

(3) You are booting on a working system with a FreeBSD installed=
 by the boot loader, or some other
custom a=
rrangement. In that case, you'll see something like:
sudo efivar --utf cfee69ad-a0de-47a9-93a8-f63106f8ae99-Loader=
Path
cfee69ad-a0de-47a9-93a8-f63106f8ae99-LoaderPath
EFIFREEBSDLOADER=
.EFI

(=
or some other place for custom setups: I assume if you are doing that you k=
now enough to
update my instructions as app=
ropriate). To update, you'd do

% sudo cp /boot/loader.efi /boot/efi/efi/freeb=
sd/loader.efi

Automating all these cases is, needless to say, tricky.
=C2=
=A0

Part of the sequencing gets into having needed to do a

installworld to have a from-same-build content replacement

for the likes of /efiootootaa64.efi . So installkernel

already done, a reboot already done, and an installworld

having been done as well in order to have something to

copy over. (There are no pointers to alternate places to

get copies that I know of. One can find copies in the

build tree when one builds from source locally. So waiting

is not really required for that context.)

Yea, I have a branch that has an 'installboot' target that updat=
es the boot
loader regardless, but given the 50-odd combinations =
of ways we can
boot, it's a bit bogged down.
=C2=A0=


This also make it seem that updating ZFS pool features

should wait until after a system upgrade that spans both

the loader and kernel being ready for the new features,

even if compatibility with other systems is not a worry.

Yes. ALWAYS update your boot blocks before zpool update.<=
/div>
=C2=A0

Do any of the system upgrade instructions cover such

relationships? Do any of the ZFS pool upgrade instructions

cover such? Does zpool or the like suggest such issues

when it reports there are new features that could be

enabled?

See above. :)
=C2=A0=


Part of what I expect happened here was contributed to by

a lack of being prompted to even think about the relevant

issues, leading to a pool feature upgrade that had not

been prepared for.

Yea, so far 100% of =
the 'help, I upgraded and now the boot loader
can't see z=
fs pool' issues have been 'I didn't upgrade my loader.efi
=

properly after zpool upgrade.' It was mandatory when we had the
OpenZFS rebase, but it is also necessary every few OpenZFS
updates from upstream as nnew features are enabled.

<=
div>I'd love for someone to add this information to the handbook, and I=
'd
happily=C2=A0review such an effort. I have time to do a br=
ain dump, but not
to make it pretty / formatted for asciidoctor a=
nd won't for some time.

Warner
=C2=
=A0

=3D=3D=3D

Mark Millard

marklmi at yahoo.com










Interesting.=C2=A0
Does the loader pass a hint to t=
he kernel about which loader was used to load the kernel?

Regards,
Ronald






Oh I pressed send too soon. I now understand all the tools=
 you already mentioned.
Sorry for the noise.
boot1.efi and loader.efi set the UEFI=C2=A0environment variable=
s I used above. No further hints
are passed into the kernel...

Warner


--00000000000062b97b05e80b2f52--

From nobody Wed Sep  7 04:46:59 2022
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 4MMqVJ4q13z4bW9B
	for ; Wed,  7 Sep 2022 04:47:04 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.registeredsite.com", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MMqVH6BSfz3W7x
	for ; Wed,  7 Sep 2022 04:47:03 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from atl4dcobm03pod7.mgt.hosting.qts.netsol.com ([10.30.35.45])
	by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id 2874l1AQ008798;
	Wed, 7 Sep 2022 00:47:01 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 atl4mhob10.registeredsite.com 2874l1AQ008798
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thegalacticzoo.com;
	s=default; t=1662526022;
	bh=g6AHuVkhmdYlymV/vL3PqH+Xr2xmlZmn+Na9JhkMSYM=;
	h=Date:From:Subject:To:References:In-Reply-To:From;
	b=t2kGGQ2+Kw3GGayTBinss67+ABkN+9yONvltLd4Y3NtbOjbKxIW1dU6QfGHpjn/ft
	 fIlJFaXrrwOXv/BuCQYE8EANSdKuLngMK6l7AyALjIVKR8eOZPzSVrNxWYPR2eRc9n
	 F+gqA9SZm96hl54pvP8w+dgpW8s3zkkbSejExqnI=
X-TCPREMOTEIP: 76.14.221.149
X-Authenticated-UID: fred@thegalacticzoo.com
Received: from [192.168.1.37] (76-14-221-149.or.wavecable.com [76.14.221.149])
	(Authenticated sender: fred@thegalacticzoo.com)
	by atl4dcobm03pod7.mgt.hosting.qts.netsol.com (Postfix) with ESMTPA id 6751380E6933;
	Wed,  7 Sep 2022 00:47:00 -0400 (EDT)
Message-ID: <64423b82-7ec1-f2c6-344b-25a48ea4fa37@thegalacticzoo.com>
Date: Tue, 6 Sep 2022 21:46:59 -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
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
From: Fred Finster 
Subject: Re: VCHIQ sound does WORK on Raspi4B 2711 CPU chip. Which DTB to
 include on config.txt file, Any other missing pieces? NO
To: Marco Devesas Campos , freebsd-arm@freebsd.org
References: <0ec5a701-908f-fc15-ef8b-401c1553e194@thegalacticzoo.com>
 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MMqVH6BSfz3W7x
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=thegalacticzoo.com header.s=default header.b=t2kGGQ2+;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com;
	spf=none (mx1.freebsd.org: domain of fred@thegalacticzoo.com has no SPF policy when checking 209.17.115.48) smtp.mailfrom=fred@thegalacticzoo.com
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine];
	R_DKIM_ALLOW(-0.20)[thegalacticzoo.com:s=default];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:19871, ipnet:209.17.115.0/24, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[209.17.115.48:from];
	DKIM_TRACE(0.00)[thegalacticzoo.com:+];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TAGGED_RCPT(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


On 9/6/22 04:23, Marco Devesas Campos wrote:
> Hi
>
>> On 7 Sep 2022, at 06:04, Fred Finster  wrote:
>>
>> VCHIQ sound on Raspi4B HDMI audio.  Which DTB to include on config.txt file, Any other missing pieces?
> stock confit.txt and dtb-s.
>
> dmesg should then show
>
> vchiq0:  mem 0x7e00b840-0x7e00b87b irq 72 on simplebus0
> vchiq: local ver 8 (min 3), remote ver 8.
> pcm0:  on vchiq0
>
> and
>    cat /dev/random > /dev/dsp
> should play static
>
> If nothing’s playing, flipping the sysctl dev.pcm.0.dest through
>   - 0: both hdmi and headphones
>   - 1: headphones
>   - 2: hdmi
> usually brings the audio back to life.
>
> Best,
> Marco


Thank you so very much for this missing piece of setting up the Sound 
for VCHIQ and the GENERIC_VCHIQ.conf  file.   I built the kernel 
GENERIC-VCHIQ in the following manner:


login as "root"

cd /usr/src

patch -v  (play) default
No devices installed from userspace.
root@Fred_RasPi4B:~ # uname -a
FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n257130-c0665d5c824-dirty: Tue Sep  6 23:52:55 PDT 2022 
fred@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64
root@Fred_RasPi4B:~ # freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
root@Fred_RasPi4B:~ #

root@Fred_RasPi4B:~ # dmesg | grep -i vchiq
fred@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64
vchiq0:  mem 0x7e00b840-0x7e00b87b irq 72 on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0:  on vchiq0
root@Fred_RasPi4B:~ # uname -a
FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n257130-c0665d5c824-dirty: Tue Sep  6 23:52:55 PDT 2022 
fred@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64

I hope this little bit of feedback helps you.  I need to go to work, now 
for 12 hours.  Thanks ago so very much.   This FreeBSD has come alive on 
the Raspberry Pi 4B with 8 GB of dram memory, to be able to play video 
and HEAR SOUND!!.  Youtube.com comes alive!


I can share more test data if you need, Marco.  Just ask and I will 
test.  https://www.frankspeech.com is a good site to test video hardware

Fred L. Finster  probably missing something here, Marcos.

fred@thegalacticzoo.com

971-718-9144

https://ghostbsd-arm64.blogspot.com

ps.  Looking forward to this VCHIQ code patch being included in the tree 
and in a new snapshot FreeBSD 14.0 arm64 image.
  https://freebsd.org/where


From nobody Thu Sep  8 05:37:13 2022
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 4MNSYy5Sd9z4c9yg
	for ; Thu,  8 Sep 2022 05:37:26 +0000 (UTC)
	(envelope-from macromarship@gmail.com)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34])
	(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 4MNSYx5xMXz3Mjy
	for ; Thu,  8 Sep 2022 05:37:25 +0000 (UTC)
	(envelope-from macromarship@gmail.com)
Received: by mail-yb1-xb34.google.com with SMTP id 130so24746251ybw.8
        for ; Wed, 07 Sep 2022 22:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=yGzzT8Y79hInJ3bsnSW57a5suZ32xazEucT5EPOWNBk=;
        b=kp7ZbPPTHMYDLmB9EL9V38sDPURJz79pL9RlStYPFoHJQ87ytBY0yKELMoPAEWHZRb
         WEUD8+bNvBQWvdPXndm/hhLZmCwM1l4qF0QU7cMxOt5eXWsJCTDPFNUQUA0B6cVIUnPt
         sVFehEkOEQ5sz69A0JzWaUu/ImfTgxrw67sncN68AcjEibcTYqQykWbnXyYvu24t9JTs
         EjkabhpXFoK+ne4b92LE+yNzgJ7rXdrYlY+CHFAje5Szdu+cYBFWxzqYPO13vQX8jOpa
         +3UKiO4ENDvu0aDdqqbf3lElo4v07RpFBFk1mhkjwJt4FIMEMDANeDkrOjJ1HshQfzDm
         TF/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=yGzzT8Y79hInJ3bsnSW57a5suZ32xazEucT5EPOWNBk=;
        b=FODZbAXVRJoFzAglrsdkUUtbN0cs73yIQabkQqjlOumZfYN7WHNLRFAFTjr1miyXRb
         iCcxKjFBJ+xOsyf/J2sLodM6biGvW0s39loiQds+pSO8X7GNMAsIT0y1b7qJPCMMrZ09
         nasfKXwocSs7MWYBcsibldOPavYam+gTUTO3bRK+4tW7d/n2kFhK4GtvXNcGhDscv330
         +z2vxKKgQ9P2u68me802CAcgTjmfDLNiuVPu3Qd/DFIdhnChe2GXcifPAJpZx2Mf5HZI
         xAKqvSarVB3H8CraM5khVcxxOiIZt1a9rCeqvNDgiYaXaSvznhf7PmBzpGVukdISBh68
         68TQ==
X-Gm-Message-State: ACgBeo2zF2iddCggSChNuOEy6hc8jR+yNtT2pWsXr0hZeFrJKv/7UDH9
	3v5AkoSxGse2CxlxAP5v6fuW6vyAqWGQsn8XAT/ciU3tFU8W7g==
X-Google-Smtp-Source: AA6agR6YALVtJF2cEeiRMz18RluCAczlnsz7jK0RqqJBhoSumTd0aDA/yeL5Bw1L6RuuTEgrr+bRBMDp9P00ClxltJA=
X-Received: by 2002:a25:4fc2:0:b0:680:f309:48e5 with SMTP id
 d185-20020a254fc2000000b00680f30948e5mr5750019ybb.0.1662615444922; Wed, 07
 Sep 2022 22:37:24 -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: Scott Zhang 
Date: Thu, 8 Sep 2022 13:37:13 +0800
Message-ID: 
Subject: Re: Is there a port manual for port freebsd to arm/imx6 board?
To: freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MNSYx5xMXz3Mjy
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=kp7ZbPPT;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of macromarship@gmail.com designates 2607:f8b0:4864:20::b34 as permitted sender) smtp.mailfrom=macromarship@gmail.com
X-Spamd-Result: default: False [-2.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b34:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 8, 2022 at 10:31 AM Scott Zhang  wrote:
>
> Dear Everyone:
>     I am personally very familiar with linux since 2003. And in last 8
> years I have good experience for porting linux to arm/imx23 arm/imx6
> port for linux kernel 2.6,3.0,4.0,5.4, so familiar with nxp/freescale
> imx series chips and linux kernel/driver tweak.
>     I know freebsd history well but not very familiar with its use,
> especially desktop, command looks same as linux so not big problem.
>     I want to port freebsd to the arm-board we build on imx chips,to
> try freebsd more. I thought the idea should be same as linux, make
> cross-compiler then build kernel. But first thing I dont' see where to
> configure the compiler. Comparing to the crowded stuff relating to
> linux, the freebsd document is quite rare. The documents on website
> are mostly entry level.
>     So is there a port manual?
>
>
> Thanks

From nobody Thu Sep  8 07:16:55 2022
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 4MNVn5217Dz4cMNT
	for ; Thu,  8 Sep 2022 07:17:13 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MNVn4073qz3Z0X
	for ; Thu,  8 Sep 2022 07:17:11 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: (Authenticated sender: valery@vslash.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 286A11C0006;
	Thu,  8 Sep 2022 07:17:07 +0000 (UTC)
Message-ID: <0641c027-aceb-4389-4e8b-e82ebfacef20@vslash.com>
Date: Thu, 8 Sep 2022 09:16:55 +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:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: Is there a port manual for port freebsd to arm/imx6 board?
Content-Language: en-US
To: Scott Zhang , freebsd-arm@freebsd.org
References: 
 
From: Valery Seys 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MNVn4073qz3Z0X
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of valery@vslash.com designates 217.70.183.197 as permitted sender) smtp.mailfrom=valery@vslash.com
X-Spamd-Result: default: False [-2.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[vslash.com];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

the wiki https://wiki.freebsd.org/arm tells us:

- Supported SBC: NXP i.MX6

and provides a link to the "Embedded Handbook":
https://wiki.freebsd.org/EmbeddedHandbook

where you will find out how to compile the base system.

UBoot port has some slave ports, like the one to boot on imx6:
https://wiki.freebsd.org/arm/U-Boot-ports

see sysutils/u-boot-master

BR

v/



On 08/09/2022 07:37, Scott Zhang wrote:
> On Thu, Sep 8, 2022 at 10:31 AM Scott Zhang  wrote:
>>
>> Dear Everyone:
>>      I am personally very familiar with linux since 2003. And in last 8
>> years I have good experience for porting linux to arm/imx23 arm/imx6
>> port for linux kernel 2.6,3.0,4.0,5.4, so familiar with nxp/freescale
>> imx series chips and linux kernel/driver tweak.
>>      I know freebsd history well but not very familiar with its use,
>> especially desktop, command looks same as linux so not big problem.
>>      I want to port freebsd to the arm-board we build on imx chips,to
>> try freebsd more. I thought the idea should be same as linux, make
>> cross-compiler then build kernel. But first thing I dont' see where to
>> configure the compiler. Comparing to the crowded stuff relating to
>> linux, the freebsd document is quite rare. The documents on website
>> are mostly entry level.
>>      So is there a port manual?
>>
>>
>> Thanks
> 

From nobody Thu Sep  8 14:12:36 2022
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 4MNh0c5y0Sz4cBjd
	for ; Thu,  8 Sep 2022 14:12:48 +0000 (UTC)
	(envelope-from macromarship@gmail.com)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31])
	(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 4MNh0c063xz3LZp
	for ; Thu,  8 Sep 2022 14:12:48 +0000 (UTC)
	(envelope-from macromarship@gmail.com)
Received: by mail-yb1-xb31.google.com with SMTP id c9so26630158ybf.5
        for ; Thu, 08 Sep 2022 07:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=rv8Oyb26B4WSa+ds3PVIU0zQ2EOLqr26GNco4WEEjz4=;
        b=q7sZJXf2wMcDvvq+09HTkCFbM6DXIKO9nMLf+LSGAIqkc5qtvNbKvBOR/bmvFSf0x9
         ejHIANrg/A4ND5p60hwx24dQVUkmG3Q78cR+NEZzS+TU4/4jkigE62S0kMBKfWoUdDYU
         wp+vTK4/gN29NCGXM4erubKVzg9MNyXglEbj+nGTM0IMTiAirLm9agXnRh+bb2K8Sy6j
         FILf9xek8S1JA384SthlddDI7+tzXLHT7IfbKTTbpZiTQTjfHF9OR9MW+ifLJ80ybhG6
         hqB4egwpOfJXJG5D6Q1Jj/ecgRo0SpEUAkRx9sF/McIMJxaqoYB75/KEPTRWEIrNCpmJ
         p1GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=rv8Oyb26B4WSa+ds3PVIU0zQ2EOLqr26GNco4WEEjz4=;
        b=FXFBLBrv9BeszaYXaRqqFd+Zizj6E/m9D7TgiI8e14idP3Hr/cNdWSKWFx71AU3lp6
         yNwqhJ9YpZVFaOFDp3c92+0MwmhKZYKCPd0wbiqdDs2MRb4aqFrfnjpTIX5dYbtw7Cf1
         W6wpClugqy5UEaxpyEzhB4fL3ZA2w5bp9B76Cm1F5nj7NX3VeJR+ShgEfO5d48//eOHM
         tmNyPclSSauMDmSvb25w0b6qVNw9w3bN6RQJdWK5NnK5rHcNVM2670GllKNorRy05wDs
         Tk2Arw3GVi7IhCK4R3jNCtagh2Vdi4SCUOtfe5jQRA4RdurdwhG3FloUTBaik+QKcu8g
         t09A==
X-Gm-Message-State: ACgBeo3MS2IBah8IEPzPJ6N39rvJLaidqJ3SyXpZSh8vUWExxxQvM5fL
	zehhgwZoUuDNw/td4hH+Q8p75UXUDeUvWVNq2gPdC2hskb2Pgw==
X-Google-Smtp-Source: AA6agR4SlkRNLVY444agwbBde7bPD0YEewpqfOJV5S0BJOf08+pmCgR/z0pYH/p75E6Y47y80GuDBsQKx1ZpXiAUlEM=
X-Received: by 2002:a05:6902:1502:b0:6ac:e639:4507 with SMTP id
 q2-20020a056902150200b006ace6394507mr6978458ybu.306.1662646367096; Thu, 08
 Sep 2022 07:12:47 -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: 
  <0641c027-aceb-4389-4e8b-e82ebfacef20@vslash.com>
In-Reply-To: <0641c027-aceb-4389-4e8b-e82ebfacef20@vslash.com>
From: Scott Zhang 
Date: Thu, 8 Sep 2022 22:12:36 +0800
Message-ID: 
Subject: Re: Is there a port manual for port freebsd to arm/imx6 board?
To: Valery Seys 
Cc: freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MNh0c063xz3LZp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=q7sZJXf2;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of macromarship@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=macromarship@gmail.com
X-Spamd-Result: default: False [-2.98 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.978];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Thanks, I'll check it out.

Sorry I am still a stranger for freebsd build system.

On Thu, Sep 8, 2022 at 3:17 PM Valery Seys  wrote:
>
> the wiki https://wiki.freebsd.org/arm tells us:
>
> - Supported SBC: NXP i.MX6
>
> and provides a link to the "Embedded Handbook":
> https://wiki.freebsd.org/EmbeddedHandbook
>
> where you will find out how to compile the base system.
>
> UBoot port has some slave ports, like the one to boot on imx6:
> https://wiki.freebsd.org/arm/U-Boot-ports
>
> see sysutils/u-boot-master
>
> BR
>
> v/
>
>
>
> On 08/09/2022 07:37, Scott Zhang wrote:
> > On Thu, Sep 8, 2022 at 10:31 AM Scott Zhang  wrote:
> >>
> >> Dear Everyone:
> >>      I am personally very familiar with linux since 2003. And in last 8
> >> years I have good experience for porting linux to arm/imx23 arm/imx6
> >> port for linux kernel 2.6,3.0,4.0,5.4, so familiar with nxp/freescale
> >> imx series chips and linux kernel/driver tweak.
> >>      I know freebsd history well but not very familiar with its use,
> >> especially desktop, command looks same as linux so not big problem.
> >>      I want to port freebsd to the arm-board we build on imx chips,to
> >> try freebsd more. I thought the idea should be same as linux, make
> >> cross-compiler then build kernel. But first thing I dont' see where to
> >> configure the compiler. Comparing to the crowded stuff relating to
> >> linux, the freebsd document is quite rare. The documents on website
> >> are mostly entry level.
> >>      So is there a port manual?
> >>
> >>
> >> Thanks
> >

From nobody Thu Sep  8 15:42:43 2022
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 4MNk0c4sJkz4cM0k
	for ; Thu,  8 Sep 2022 15:42:56 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929])
	(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 4MNk0c0GSnz3RW1
	for ; Thu,  8 Sep 2022 15:42:56 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x929.google.com with SMTP id r17so6860611uat.8
        for ; Thu, 08 Sep 2022 08:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=4mTCoJOB1b/9q9rQteubnCWVT8jLsQzrfVTUgbX8PDU=;
        b=EEqp8RC+pDQvRykz84Kf+xedojc0IK3Zg6rUsRCE7WTdT95udZzBvts8fXYxlSUvr5
         REFsL8JCdIl6hUfrRcISay0pXfEzwqJ1QjrQD+VhmFCWlrH90a6uZseXcmFr0esG3ijU
         t5sBZidBll8ILooH8QBqJI/XQElmaFmOyHNH8usZ/VT/fNOsg9NWkFWerr3Sev87phhZ
         GKi3aSQPkiPQMkHVcy+Lo1XPiEkU+12ihpi9wHmtnipaz7ReH23BFXbyLtNKKIyYa0wF
         niYrjcnlO56Daw+NHjUW2nF6xTuTIxr9A4XQr4axWS31PFsczJXr+GFl7azoz5sSR2+i
         9+iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=4mTCoJOB1b/9q9rQteubnCWVT8jLsQzrfVTUgbX8PDU=;
        b=zAnyqUGdOl3JQHiNgYI8gmGgl9SPNWx6rz0sgjId5SR+q0a97zti2cLWb37BCnZcy4
         VeOvvEJcHSWetJY+rmN+5TnWr6c6Enq3YRpubSVwWERHXaZ00rIgUPdNsjFmQJfSWoKK
         KbrUDDjOGz+8xKNC3a6ghlU7Buy5xNTFSymJjiQQCgb0eZosiQX5KOHTcfJZnuZiO/9l
         T3bkeQ4iCIssGkl7cY4qyG6xLG2QoQxPo/aZ+5+LhVeqwbfdEJZQfhXXNzu0YOwsxlqD
         C05mKons+GDoqSU0D5BHSEhGcbm3E5qqeiZMJKKf6MxUoD/cui222IPyH2Rnr2NMA9Lf
         vqCA==
X-Gm-Message-State: ACgBeo0aLYJJdgGiVLjeRk7kLs6HOv/xdqen9yZBLidjmi3o1YYnJBZx
	8CkSqxo0t4/G3lxA4S2t58nU8/FgjnVVFbN8UVTtNEGNWulgAw==
X-Google-Smtp-Source: AA6agR50i1KPTQRnWcsnKos8mbdqJFqnGbA8MA0oO1qqXk5VXw5FBRMoKBHJTSNIqLNF90GkcCv8Vo6STajbNKaCcHo=
X-Received: by 2002:a9f:2067:0:b0:387:984d:4a8e with SMTP id
 94-20020a9f2067000000b00387984d4a8emr3423911uam.60.1662651774457; Thu, 08 Sep
 2022 08:42:54 -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: 
 
 <0641c027-aceb-4389-4e8b-e82ebfacef20@vslash.com> 
In-Reply-To: 
From: Warner Losh 
Date: Thu, 8 Sep 2022 09:42:43 -0600
Message-ID: 
Subject: Re: Is there a port manual for port freebsd to arm/imx6 board?
To: Scott Zhang 
Cc: Valery Seys , "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000066eed505e82c4807"
X-Rspamd-Queue-Id: 4MNk0c0GSnz3RW1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=EEqp8RC+;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::929) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[gmail.com];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000066eed505e82c4807
Content-Type: text/plain; charset="UTF-8"

In the past, you needed an IMX6 kernel. these days, all of that is in
GENERIC. The board
bring up often times is making sure that you have a good u-boot and the FDT
that it provides
matches what FreeBSD expects.

Warner

On Thu, Sep 8, 2022 at 8:12 AM Scott Zhang  wrote:

> Thanks, I'll check it out.
>
> Sorry I am still a stranger for freebsd build system.
>
> On Thu, Sep 8, 2022 at 3:17 PM Valery Seys  wrote:
> >
> > the wiki https://wiki.freebsd.org/arm tells us:
> >
> > - Supported SBC: NXP i.MX6
> >
> > and provides a link to the "Embedded Handbook":
> > https://wiki.freebsd.org/EmbeddedHandbook
> >
> > where you will find out how to compile the base system.
> >
> > UBoot port has some slave ports, like the one to boot on imx6:
> > https://wiki.freebsd.org/arm/U-Boot-ports
> >
> > see sysutils/u-boot-master
> >
> > BR
> >
> > v/
> >
> >
> >
> > On 08/09/2022 07:37, Scott Zhang wrote:
> > > On Thu, Sep 8, 2022 at 10:31 AM Scott Zhang 
> wrote:
> > >>
> > >> Dear Everyone:
> > >>      I am personally very familiar with linux since 2003. And in last
> 8
> > >> years I have good experience for porting linux to arm/imx23 arm/imx6
> > >> port for linux kernel 2.6,3.0,4.0,5.4, so familiar with nxp/freescale
> > >> imx series chips and linux kernel/driver tweak.
> > >>      I know freebsd history well but not very familiar with its use,
> > >> especially desktop, command looks same as linux so not big problem.
> > >>      I want to port freebsd to the arm-board we build on imx chips,to
> > >> try freebsd more. I thought the idea should be same as linux, make
> > >> cross-compiler then build kernel. But first thing I dont' see where to
> > >> configure the compiler. Comparing to the crowded stuff relating to
> > >> linux, the freebsd document is quite rare. The documents on website
> > >> are mostly entry level.
> > >>      So is there a port manual?
> > >>
> > >>
> > >> Thanks
> > >
>
>

--00000000000066eed505e82c4807
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In the past, you=C2=A0needed an IMX6 kernel. these da=
ys, all of that is in GENERIC. The board
bring up often times is =
making sure that you have a good u-boot and the FDT that it provides
<=
div>matches what FreeBSD expects.

Warner

On Thu, Sep 8, 2022 at 8:12 AM Scott Zhang <macromarship@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Thanks, I'll check it =
out.



Sorry I am still a stranger for freebsd build system.



On Thu, Sep 8, 2022 at 3:17 PM Valery Seys <valery@vslash.com> wrote:

>

> the wiki https://wiki.freebsd.org/arm tells us:

>

> - Supported SBC: NXP i.MX6

>

> and provides a link to the "Embedded Handbook":

> https://wiki.freebsd.org/EmbeddedHandbook

>

> where you will find out how to compile the base system.

>

> UBoot port has some slave ports, like the one to boot on imx6:

> https://wiki.freebsd.org/arm/U-Boot-ports

>

> see sysutils/u-boot-master

>

> BR

>

> v/

>

>

>

> On 08/09/2022 07:37, Scott Zhang wrote:

> > On Thu, Sep 8, 2022 at 10:31 AM Scott Zhang <macromarship@gmail.com> w=
rote:

> >>

> >> Dear Everyone:

> >>=C2=A0 =C2=A0 =C2=A0 I am personally very familiar with linux =
since 2003. And in last 8

> >> years I have good experience for porting linux to arm/imx23 a=
rm/imx6

> >> port for linux kernel 2.6,3.0,4.0,5.4, so familiar with nxp/f=
reescale

> >> imx series chips and linux kernel/driver tweak.

> >>=C2=A0 =C2=A0 =C2=A0 I know freebsd history well but not very =
familiar with its use,

> >> especially desktop, command looks same as linux so not big pr=
oblem.

> >>=C2=A0 =C2=A0 =C2=A0 I want to port freebsd to the arm-board w=
e build on imx chips,to

> >> try freebsd more. I thought the idea should be same as linux,=
 make

> >> cross-compiler then build kernel. But first thing I dont'=
 see where to

> >> configure the compiler. Comparing to the crowded stuff relati=
ng to

> >> linux, the freebsd document is quite rare. The documents on w=
ebsite

> >> are mostly entry level.

> >>=C2=A0 =C2=A0 =C2=A0 So is there a port manual?

> >>

> >>

> >> Thanks

> >






--00000000000066eed505e82c4807--

From nobody Fri Sep  9 12:27:30 2022
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 4MPFck3vKnz4cXBl
	for ; Fri,  9 Sep 2022 12:27:34 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MPFcj3rKjz3bjb
	for ; Fri,  9 Sep 2022 12:27:33 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.nyi.internal (Postfix) with ESMTP id 013C15C00DE
	for ; Fri,  9 Sep 2022 08:27:33 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute2.internal (MEProxy); Fri, 09 Sep 2022 08:27:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; t=1662726452; x=1662812852; bh=WMhci7Rjal
	NciBKknBtRa2S4M6YPhg9eDQYxDzdIB5E=; b=TAsdNXntXz5S2MyUXl6tWlWoAA
	1a+XVlx2GuUQidkBzYRuUfZoZFjpeZ0Ft2j8plxv6r7OYrQZ9iYfZSdOCX8GVc+h
	entW4i68X3tTGYA2shsqSw2G8zrXMNR3HbQmbFt83L5AM012+kJRBccius/th0mb
	gaFFIJff/VpMXui0W22oJ2fqarkefUHPvFtj2ceQDO89P7wjegRCO68bPa0wkuaH
	p/8rp0yVKTxMQea8NGjsMoIVxpC2meFmSWwfqyLO5+soJk6EpebIYzlBMflBFB/g
	FQILwpKdfubqH6CJj+PdimhUUI5bDGLGkm8CgBXqdRgkAGGOtV+3kxQVimfA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1662726452; x=1662812852; bh=WMhci7RjalNciBKknBtRa2S4M6YP
	hg9eDQYxDzdIB5E=; b=mMJlDbU4hjq6BoAU0c40BfQTCL+rJunRQn8O5MAB1mSX
	HiPdir9ZBGq7Yi1ClJ8gQU1UOMPNM1O9ZPOjE48UOOAH/9RcLdb1dMSTAuoHNaj6
	L8xHHvYY8IVsybYbjeF7/t9uc2J09crib1YllQyKZm1EwD2mpzB5aggUF3Ni2kLj
	pTrEj6uQuPfZc6DmHKb40jVmNSs/2dPl0plbyHXjMGl6hOQ/AYkOzLkfMZof8Kaa
	Yejl08B9N+MP/p1kWbQJyHEOKe2aQuTotNf0LAHpcXusV+WQ+xv2RYwajY5dn9Rq
	DdejVCKTeKxxrvL3uAE+MSFaRYGFY97YPTAidxrlhw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedthedgheefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtro
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepieevgfefgeffhffggfeitdejjefhteeffefgleefieevleevjeeuieduge
    elgffgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
    vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Fri, 9 Sep 2022 08:27:32 -0400 (EDT)
Date: Fri, 9 Sep 2022 13:27:30 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Re: VCHIQ sound does WORK on Raspi4B 2711 CPU chip. Which DTB to
 include on config.txt file, Any other missing pieces? NO
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: <0ec5a701-908f-fc15-ef8b-401c1553e194@thegalacticzoo.com>
 
 <64423b82-7ec1-f2c6-344b-25a48ea4fa37@thegalacticzoo.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; format=flowed
Content-Disposition: inline
In-Reply-To: <64423b82-7ec1-f2c6-344b-25a48ea4fa37@thegalacticzoo.com>
X-Rspamd-Queue-Id: 4MPFcj3rKjz3bjb
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=TAsdNXnt;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=mMJlDbU4;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-5.06 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.96)[-0.961];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	SUBJECT_HAS_QUESTION(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

You may be interested to also know that it works on 13.1.0
on armv7 rpi2b+ (board version 1.1)

Here, on a headless rpi2b+ audio/mpv playing internet radio

-- 

From nobody Fri Sep  9 16:24:01 2022
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 4MPLsb5lk5z4bmZt
	for ; Fri,  9 Sep 2022 16:24:03 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4MPLsb5DM2z4263;
	Fri,  9 Sep 2022 16:24:03 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662740643;
	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=BQwUTkxX1ZD+F77YQKfxsxASkiRMviLJ13oEnWNGKxg=;
	b=DlOyFvV7qqnZim2on4UCmR8LCsJY8iItEaBHmdD3vLFGBeNCGHOgKeWqBvmckvgSVbn1Ms
	dZbUdiBuhgOo8gyUHHYtD0g4p+U5iizwFauq3nwFcjDy/RU72tZavb+w5NhHkGNzb029Ie
	paNKgShIPElne0pV/TXgVuS74vNfMnb1zMFk42u8QsUQWHYAg3kFogcFF2aN3J7fMqeVNR
	KIdshBTdLx+f2HElRhpbAU2SAsNet4IPvvPHZA5hPuOvfcW8EaOHTKoT0gcKnSf3lrBOXS
	g8K8MKLL9uDPg4RuroTySv4TNxBBc22S3+/cC3Njmo8vMXuGL5H8CyXoCiKTtg==
Received: from [192.168.1.106] (host-173-212-68-18.public.eastlink.ca [173.212.68.18])
	(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: mhorne)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MPLsb32P0z1F86;
	Fri,  9 Sep 2022 16:24:03 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
Message-ID: 
Date: Fri, 9 Sep 2022 13:24:01 -0300
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:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: RPI4 HW pwm
Content-Language: en-CA
To: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= ,
 freebsd-arm@freebsd.org
References: 
Cc: mgrooms@shrew.net
From: Mitchell Horne 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662740643;
	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=BQwUTkxX1ZD+F77YQKfxsxASkiRMviLJ13oEnWNGKxg=;
	b=XBlsZLXbtBCCoJitJK9GXRYVUVa5b7L1F15VuN/IVAknIFK9cUv+VPGMr8QWNubU6+gawL
	onU9JXnjiX08HyPbcNIRn5fXnbTl05Z9A/Jsi8ks7aqw6ODygvgSy802ZJqs/N/nWc1BWO
	Zpb6VRUMIpBj6IH7sjBN0YK+aQez1XockY4oLLBHSEjyk/k4yVVebPk0KUYequ7usM11BK
	1LjT9Ktn4lh9uJ/yQGBgUG4vhE6ABPbdRPm7VQKXeyQk1UTFxiHCqzS2oyhtBhXXQa3wab
	olGqq/boWW0QtFIuzoRHWUuUj8Edg0/m4vHRVGuORIouH7WCy9atWQJsDUjT5Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662740643; a=rsa-sha256; cv=none;
	b=WakIgNvkcAn3fFBYvC9YDSvGCmgu6BTxKW/Y72L7V0LcyeE3PoU099oUegCcVEJgfT9Za3
	MCOEP+FlDNTMFsDdfKQHKr6d7X0IWfUxhL/UjCUO7odyo03dOyFGw+OuR8w2V8Rpr0CqxX
	cIDtFOhbrtHs5a/OuDA6ilEs8P/c6EJ/C6aqp23S8HxmsLFMSb0WiZOQ2XCeoSZcRIVRZR
	aNF/V34/eI0Y/QL/he1G8IdLgknZRDVzZ3LBkcUw+nLhuB/41qfHv3esdVgktbR96XBSND
	OrSQ+UYGN+aMOc4gQy7RsmooMaU6mTsjqRi7ceIIrOLA6LTdrcPQGvOFYDjZsg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



On 9/6/22 00:56, 風來散人 wrote:
> Hello all.
> 
> Sorry for bringing up the old topic again. There was an email last year.
> 
> https://lists.freebsd.org/archives/freebsd-arm/2021-June/000143.html 
> 
> 
> This patch isn't included in the 13.1 and later versions. Is there any 
> chance we can have it?
> 
> Thank you.

Hi, thank you for bringing attention to this. I have committed the change:

https://cgit.freebsd.org/src/commit/?id=87705c5c21784c401a8d425b2780bb8b1c37d431

Cheers,
Mitchell

From nobody Sat Sep 10 05:00:48 2022
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 4MPgfv6TBCz4cJJS
	for ; Sat, 10 Sep 2022 05:00:55 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4MPgfv5xG4z44Gm
	for ; Sat, 10 Sep 2022 05:00:55 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662786055;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=scQ5BZ+DkW0+zTBrFcJGvkCiJCS9gagiaCaladAJ+sc=;
	b=gGjooLmdDn6xkEjY1lUANF1ek0zg9d477pOuZckxxmyrTCRGHxt2qUHZrRtrC/4CF6H/LR
	brCdP7r7tGyAguY02ivA8Qo7QldSIW1etnnw9Nb1erwint62U+fSW+HOOi9w5HWZPDsQbD
	Kr7+faa2EHkIyB+ThFVIR564FfGA/DydvcOK2tcBGM7SJLCjH4RF2elYtVv9+NmMxlcKfv
	20CiXKz7KC2hwafHbzYz6KAWnMXByOScVRfLg6uFId4KwtX/2/dh1uyjnyARp7rWNSsfm6
	up9II5zKHQzNhlEcKsnZqQfOt81RRtqkuY8ejQEEN8+l0/fo3R6uHnwwJ9By7w==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512)
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MPgfv0GDBz1HgV
	for ; Sat, 10 Sep 2022 05:00:54 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Sat, 10 Sep 2022 15:00:48 +1000
From: Peter Jeremy 
To: freebsd-arm@freebsd.org
Subject: Pine H64 won't boot with DTB version 5.13
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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="qRNmYJpGmYjsY6ts"
Content-Disposition: inline
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662786055;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=scQ5BZ+DkW0+zTBrFcJGvkCiJCS9gagiaCaladAJ+sc=;
	b=rOfmWFjD48lW0atK5fXO9ED46WDvF6j8AXTv9UkqpPgPaG0ErM+t2O+8/XVbdLzEfEHPAM
	iGmLiP3/KR4BanjqzG8oiXyAnvXiym7ukqJvuZCsfB565TeK+b2G8F4fT6q1OunWXD7hEr
	3opKTALdg+6+kccOHkgkbV+ddBu4+BhNezC19BpmNlr93r19cmruVGhANK0u7Y6J1YhZZg
	fdWx2qx70HpR4AhmAJSk30gE8F/eeO9+NkY4nTarF2AlENj1QuBIBTweQ1G/ddDd4r5gHg
	kCJPEHBBkmfg68fv8PvGjdUKAn5Lc+IgEorbTcDaI2tAn6GMaRopPJkKUtSeeQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662786055; a=rsa-sha256; cv=none;
	b=Tn/3sqJ+HPW25cal4Bn32ZlDliOvJTmGvwcj66WWNM1BNWtxFjZftPQ0oQwyGtvWUrLjeh
	bxxY8nFyiakm6ZYLI4A4hp/CLKsjSpDOiqzvrRXmerjLSMMSTVxoOSdFv8jwc+4ApGlI4r
	NpfE9um//NuCqC7gLcCeIsCtAixCzispkYHQtBrcHcz0AXQg65qgaAnzfWUCXdDTkiZH2z
	zGzuuffFXqK30k2WH9U+g4MPH8MgPHkkOaiv+ovfrLHvY3LBRI69Rxr3y2F8sOnmCKnrHc
	jy5Qdegb6evdJ4U2hBu7sq6z9vnejBvncWUBSRfA9zT/nRYeiatoI8IpV9xxIw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--qRNmYJpGmYjsY6ts
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have updated my Pine H64 to -current and the kernel advises me:
WARNING: DTB version is 5.9 while kernel expects 5.13, please update the DT=
B in the ESP
unfortunately, when I do so, it fails to attach mmc1 to aw_mmc0 (the
microSD slot) and therefore there's no root device.  The onboard
flash mmc0 connected to aw_mmc1 probes normally.

I've compared the boot messages and the critical difference seems to be
that with the newer DTB, the following device is missing:
aw_r_intc_gicp0:  mem 0x7021000-0x70213ff irq 48 on simpl=
ebus0
Instead, I get:
simplebus0:  mem 0x7021000-0x70213ff irq 51 c=
ompat allwinner,sun50i-h6-r-intc (no driver attached)

Looking through the DTS changes the crucial difference is:

--- /tmp/zzz/5def4c47d4bd/sys/contrib/device-tree/src/arm64/allwinner/sun50=
i-h6.dtsi    2022-09-10 12:49:39.000000000 +1000
+++ /tmp/zzz/src/sys/contrib/device-tree/src/arm64/allwinner/sun50i-h6.dtsi=
     2022-09-10 13:24:13.751345000 +1000
=2E..
@@ -927,10 +929,9 @@
                };
=20
                r_intc: interrupt-controller@7021000 {
-                       compatible =3D "allwinner,sun50i-h6-r-intc",
-                                    "allwinner,sun6i-a31-r-intc";
+                       compatible =3D "allwinner,sun50i-h6-r-intc";
                        interrupt-controller;
-                       #interrupt-cells =3D <2>;
+                       #interrupt-cells =3D <3>;
                        reg =3D <0x07021000 0x400>;
                        interrupts =3D ;
                };

The problem is that the FreeBSD interrupt controller drivers
(sys/arm/allwinner/aw_nmi.c and sys/arm/allwinner/aw_r_intc.c) only
recognize "allwinner,sun6i-a31-r-intc".

I tried adding "allwinner,sun6i-a31-r-intc" back in and the resultant
DTB works.

I'm not sure if the correct fix is to locally patch sun50i-h6.dtsi
or fix the interrupt controller drivers.

--=20
Peter Jeremy

--qRNmYJpGmYjsY6ts
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmMcGflfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzSYSA/8D70JQQFngxOs7501NCyUVuR6w8Tr4E0Ib9l8WqSfTwKOH6X17OZEyBpv
+SJOGwKUn6VsEm37IfxvQPe2VmbVMwCa/4dC3p3YNjt/MigQKNy2khveco+y4L2J
LDiBwZJnHvF0QWT1ZYES2/esy2cPpLDiIa7V8hYP9qxRdkEVw+noZVIJQ7fb/00c
gTFiaELCj1qw7GfHQKEXQjgDqN4N04gfTo1l9u5QnUGBXOS5V3nuP7aMBj6nIpzv
3qQh7PnooWl9QTL+NDuKifB472lBJ0LOoNaMCfJ4ae/G2wNmQu1Feexj387lFh3c
yXTpmU1KyvmfoEwIK5px6mFnBzSgdejlVuAkezIWus0CHbtL51xOjl8hyaN+H7f5
HlmxxZvL3Z73Y+G6bMHy92vO9sZLausurC9udeZt7oVoFWMJ/T2j69HWZZdE3FGc
niQvPNITXTN5t/FMIfyc5mVIqBXHNDxO0/cMKqbY0OEpfV0sFr5dG4aU0WUTKeFK
NwkgKg6tr3Kbyjjtb4JPGKQlv80lBswlBQ+87E+J6lMznRT3bQ5Cc6RcArY4DMvn
Duob46O5S3xTZW1ly3ZJttcEyukKK18KmKDI5xwhYfzXPZ5u0fkoPtDU0575cvWI
1kCzqSgJ1wetXZiY693Ex8yX6mhVqD3C2/YVizAx9wXm7T/5DYk=
=rtLH
-----END PGP SIGNATURE-----

--qRNmYJpGmYjsY6ts--

From nobody Sat Sep 10 07:28:50 2022
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 4MPkxq1C80z4cZ8t
	for ; Sat, 10 Sep 2022 07:29:03 +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 4MPkxm5xHcz3GXL;
	Sat, 10 Sep 2022 07:29:00 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1662794932;
	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=P0taQcqVc2VwkEAkodWNwf9iddOLbe9M1XvYzZgUDJY=;
	b=NxXyy27aQPz7xg5y47NF6r8hNHiVYNWnVADTQF7pmyFXEPnRpCoRx+nT3edoMXw/DTBbfR
	iqO+2GwCig3AUb2DidqWIVZnDlScwqb+gTetXO03HUgQnZdqZoTPHRlgNCrI7MRE4Fd11G
	P+e26rrqIZwoYL6NMLY1sSQrlDxLRIY=
Received: from skull.home.blih.net (mtl93-h04-176-174-252-202.dsl.sta.abo.bbox.fr [176.174.252.202])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 61e5afdb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Sat, 10 Sep 2022 07:28:52 +0000 (UTC)
Date: Sat, 10 Sep 2022 09:28:50 +0200
From: Emmanuel Vadot 
To: Peter Jeremy 
Cc: freebsd-arm@freebsd.org
Subject: Re: Pine H64 won't boot with DTB version 5.13
Message-Id: <20220910092850.244fbdb448678642e7ae321e@bidouilliste.com>
In-Reply-To: 
References: 
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: 4MPkxm5xHcz3GXL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=NxXyy27a;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	MV_CASE(0.50)[];
	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];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	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];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[manu];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bidouilliste.com:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


 Hi Peter,

On Sat, 10 Sep 2022 15:00:48 +1000
Peter Jeremy  wrote:

> I have updated my Pine H64 to -current and the kernel advises me:
> WARNING: DTB version is 5.9 while kernel expects 5.13, please update the DTB in the ESP
> unfortunately, when I do so, it fails to attach mmc1 to aw_mmc0 (the
> microSD slot) and therefore there's no root device.  The onboard
> flash mmc0 connected to aw_mmc1 probes normally.
> 
> I've compared the boot messages and the critical difference seems to be
> that with the newer DTB, the following device is missing:
> aw_r_intc_gicp0:  mem 0x7021000-0x70213ff irq 48 on simplebus0
> Instead, I get:
> simplebus0:  mem 0x7021000-0x70213ff irq 51 compat allwinner,sun50i-h6-r-intc (no driver attached)
> 
> Looking through the DTS changes the crucial difference is:
> 
> --- /tmp/zzz/5def4c47d4bd/sys/contrib/device-tree/src/arm64/allwinner/sun50i-h6.dtsi    2022-09-10 12:49:39.000000000 +1000
> +++ /tmp/zzz/src/sys/contrib/device-tree/src/arm64/allwinner/sun50i-h6.dtsi     2022-09-10 13:24:13.751345000 +1000
> ...
> @@ -927,10 +929,9 @@
>                 };
>  
>                 r_intc: interrupt-controller@7021000 {
> -                       compatible = "allwinner,sun50i-h6-r-intc",
> -                                    "allwinner,sun6i-a31-r-intc";
> +                       compatible = "allwinner,sun50i-h6-r-intc";
>                         interrupt-controller;
> -                       #interrupt-cells = <2>;
> +                       #interrupt-cells = <3>;
>                         reg = <0x07021000 0x400>;
>                         interrupts = ;
>                 };
> 
> The problem is that the FreeBSD interrupt controller drivers
> (sys/arm/allwinner/aw_nmi.c and sys/arm/allwinner/aw_r_intc.c) only
> recognize "allwinner,sun6i-a31-r-intc".
> 
> I tried adding "allwinner,sun6i-a31-r-intc" back in and the resultant
> DTB works.
> 
> I'm not sure if the correct fix is to locally patch sun50i-h6.dtsi
> or fix the interrupt controller drivers.
> 
> -- 
> Peter Jeremy

 Sorry I've missed that when I updated the DTS.
 The correct fix is to add the new compat string to the aw_r_intc
driver (sys/arm/allwinner/aw_r_intc.c).
 Not really sure why the a31 compat string was removed upstream as it's
not said in the commit message tought.
 Feel free to commit this change.
 While you're at it also add allwinner,sun50i-a64-r-intc to the list
just in case they remove the a31 compat string in the futur.

 Cheers,

-- 
Emmanuel Vadot  

From nobody Sun Sep 11 02:36:00 2022
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 4MQDQ21VgNz4bdm3
	for ; Sun, 11 Sep 2022 02:36:42 +0000 (UTC)
	(envelope-from furaisanjin@gmail.com)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536])
	(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 4MQDQ13BbWz4Mc7
	for ; Sun, 11 Sep 2022 02:36:41 +0000 (UTC)
	(envelope-from furaisanjin@gmail.com)
Received: by mail-ed1-x536.google.com with SMTP id t5so8058686edc.11
        for ; Sat, 10 Sep 2022 19:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=R+BD5+jexpeSg3blYx83gIjblY1MuOanIbL8zeKwikM=;
        b=GdDvj8H2L/j26Qk9QkG7Z8F6pr3Refhp6qr/nNayBZhplgISCTVyuLeeN9OLHF6OoB
         x+rFwT8eMV9O3rYnWhfkuCvOGQHu1hVLTGY66Me6CKtkcWmRL2X3XAcUoRrNTQ983qAv
         67SDHPgLnjQgzCGMB/OMBM1FBCeSffOtITJieBY4NEAycwqCfMKzuc2ECwhWFi6ykjcz
         +c4Bk9MvFg2yDCt6VDhqCwkbr+fwsZOc/ow5bAvt5NjrK/jhiR4CQwkbRviXI4mkTiI1
         8iC9KmRZeCWuG8fZTldH9MY04OWNqqT/Pe2w77W5KERhBziCXlfSPx6pwHavWzcTVgJu
         IRKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=R+BD5+jexpeSg3blYx83gIjblY1MuOanIbL8zeKwikM=;
        b=20oKOipJQPgaM19N35bjen7swxnQtd4VqAiRjPM+3scdCvHJ92oCgGuAnnsdLy285N
         +7ZlxKQ/PzL0vQbNmqfI9DL12z7K9lLOM6XB23YikLHeCtMOlh8Km62kyi9o0qt26rL6
         dlGXUjHnz8NKfdzyYG6nqH/8TnEnmhKlM+2LFhKqKjepGYaKxY6UAA0HArvm8bIpKioB
         BkOT11BEm7ze6hFrMB11BEx7o3y4skNLqtdLChCwQbW19iskmm5MiKLVw4Tn/EI+RtY2
         9jWLO8OPcq+u8JONEJNNWJD1djvbJ/eWA+gbKLqs67kfXDrXCZc9+2ojyUPq8unNFr9z
         12/g==
X-Gm-Message-State: ACgBeo1lrqyMyr6ygLZdkyb3kQO3OxeDNgo+IQfsElg6XBXFfjbzAnPA
	gG6qMfZAoP969kctsPy18AjdV7cFzbLfqKed1/5zuCBsFRU=
X-Google-Smtp-Source: AA6agR49nnlBOtmBE3MYg+9c2GOfwFxRyocYWL+6EgaADnyugsAfvoTODdxX2bv4/i38n9SAbytz8KPJyUFqbHXtocc=
X-Received: by 2002:a05:6402:2947:b0:451:32a:2222 with SMTP id
 ed7-20020a056402294700b00451032a2222mr8546444edb.376.1662863798733; Sat, 10
 Sep 2022 19:36:38 -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: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= 
Date: Sun, 11 Sep 2022 11:36:00 +0900
Message-ID: 
Subject: Re: RPI4 HW pwm
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000088e5f05e85da60d"
X-Rspamd-Queue-Id: 4MQDQ13BbWz4Mc7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=GdDvj8H2;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of furaisanjin@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=furaisanjin@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000088e5f05e85da60d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Mitchell,

Thank you for your work. I hope it will be released soon.


2022=E5=B9=B49=E6=9C=8810=E6=97=A5(=E5=9C=9F) 1:24 Mitchell Horne :

>
>
> On 9/6/22 00:56, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA wrote:
> > Hello all.
> >
> > Sorry for bringing up the old topic again. There was an email last year=
.
> >
> > https://lists.freebsd.org/archives/freebsd-arm/2021-June/000143.html
> > 
> >
> > This patch isn't included in the 13.1 and later versions. Is there any
> > chance we can have it?
> >
> > Thank you.
>
> Hi, thank you for bringing attention to this. I have committed the change=
:
>
>
> https://cgit.freebsd.org/src/commit/?id=3D87705c5c21784c401a8d425b2780bb8=
b1c37d431
>
> Cheers,
> Mitchell
>

--000000000000088e5f05e85da60d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello=20
Mitchell,

Thank you for your work. I hope it will =
be released soon.


2022=E5=B9=B49=E6=9C=8810=E6=97=A5(=E5=9C=
=9F) 1:24 Mitchell Horne <mhorne@f=
reebsd.org>:




On 9/6/22 00:56, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA wrote:

> Hello all.

> 

> Sorry for bringing up the old topic again. There was an email last yea=
r.

> 

> https://lists.freebsd.org/a=
rchives/freebsd-arm/2021-June/000143.html 

> <https://lists.freebsd.o=
rg/archives/freebsd-arm/2021-June/000143.html>

> 

> This patch isn't included in the 13.1 and later versions. Is there=
 any 

> chance we can have it?

> 

> Thank you.



Hi, thank you for bringing attention to this. I have committed the change:<=
br>


https://cgit.freeb=
sd.org/src/commit/?id=3D87705c5c21784c401a8d425b2780bb8b1c37d431



Cheers,

Mitchell




--000000000000088e5f05e85da60d--

From nobody Sun Sep 11 21:00:53 2022
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 4MQhw62q3Dz4cgNh
	for ; Sun, 11 Sep 2022 21:00:54 +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 4MQhw55vdxz3XQL
	for ; Sun, 11 Sep 2022 21:00:53 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MQhw5514mzm7p
	for ; Sun, 11 Sep 2022 21:00:53 +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 28BL0rXu010978
	for ; Sun, 11 Sep 2022 21:00:53 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28BL0rTB010977
	for freebsd-arm@FreeBSD.org; Sun, 11 Sep 2022 21:00:53 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202209112100.28BL0rTB010977@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, 11 Sep 2022 21:00:53 +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="16629300533.49eCceD.7189"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662930053;
	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=Ea/lhRaqa786tlYsHdl7KaEIUF1x+8H6lWs5z8u23+c=;
	b=dX3HFIU5ts4rGB9QZ4YuPiMPnHdcEgcbhsCeBrKs8Fdo5xcSYylOIESOLIlzN8WQSvqL50
	O1EQEgJ2vi5HPvcEIIYW7vmh4sOEyCSpWET0hPt+iF8wQqVVmKo8dqJ38jBLISTbBsYa9T
	+alyTxKf8hShK+7OsFLnStYCF5SNSeDxbncniYq2TVxhqjQkLvT9ZdCe/4wlPNoLCSON4e
	IlRL44eX4ROPncamKJgVI4hPrvN1OjgJ0t8GN9XZ/5W3hjIYdMqN9I76WlBDnZn4AESAE9
	RWzjh/zER4ms13XTkYtkYeFbrR0QjJkEnB5riAmb+kSQg8A3ULxaxhsUlTM26w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662930053; a=rsa-sha256; cv=none;
	b=qX4uWLpPQfJGqqqkNCM7Lud/pbqM+J4eLQ14b+VcZ3v7oyhWGZW2avdXM7i78AJMXz2105
	Sm6EN1swxzlMmj3l73L3lT6Z6m28uxn6jRc4vJuQl6LEEzBGLcth2VbQwLKvSFhxZQ8fmY
	CvIkUV/e+f+emUwsYKNoUrSRpVkBTkl1tWIrJutanjmD32MJTD4rgtRMYAaVTXPjhLQ1dM
	UBT43Lxme6pRwz/EjsQFnikqcp5xVA4Bm2mewJMZnhCsfoFgARC05LBOZwGTlkulrUF0TO
	Wz0JtyygeF3i1Ow5TL/5eVzgSk4LlsM4PFcChqJDK9rafYPOcV0jsGVmGxaW6Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16629300533.49eCceD.7189
Date: Sun, 11 Sep 2022 21:00:53 +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.

--16629300533.49eCceD.7189
Date: Sun, 11 Sep 2022 21:00:53 +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.


--16629300533.49eCceD.7189--

From nobody Mon Sep 12 12:10:44 2022
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 4MR63m2qfGz4cRLT;
	Mon, 12 Sep 2022 12:53:56 +0000 (UTC)
	(envelope-from dsl@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 4MR63m2S95z3nkT;
	Mon, 12 Sep 2022 12:53:56 +0000 (UTC)
	(envelope-from dsl@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662987236;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=vLp+XGXa+qCOi+kDCBACiyV2vhs4+LMtmCGw8l06dyY=;
	b=nXh15A1NCc0YSrlHe3bayr7yMVOtXDXweM9csa1yWgbizB+ZsMOnxqo2cPlzKWIgLqy7w/
	IBr+3SEwkp5Qy7XbAnOE3vD0QpGiiW8ZRK7U8jFGbuALB1jj++f90yLdB5TqrUfsEzee9q
	zXVO+HeCb5pse+gqzaP4qkfFYjDFJLGsoxKOURV5CJUgarzJxTPpM+WQtNhZc0wjDi0IaB
	cH7qVys4wdkTqFRGa1vKwj+0TLqPiSUkddalRkhlLoDRYrbiP04262ivsh/oAvkPXYbHbH
	KqsIoCaXjhVai2TLygq21lCQFF0i/lT9NbwDZgLyr6n7djFOtfJKI1WqSEXsTA==
Received: from localhost (bmj149.neoplus.adsl.tpnet.pl [83.28.229.149])
	(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 did not present a certificate)
	(Authenticated sender: dsl)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MR63l3KrnzTrr;
	Mon, 12 Sep 2022 12:53:55 +0000 (UTC)
	(envelope-from dsl@FreeBSD.org)
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay> 
 <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
  <20220308154204.GA37265@www.zefox.net>
User-agent: mu4e 1.6.10; emacs 28.1
From: Dmitry Salychev 
To: bob prohaska 
Cc: Mark Johnston , Andrew Turner ,
 Ronald Klop , Mark Millard ,
 freebsd-arm@freebsd.org, freebsd-current@freebsd.org
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64
 Feb 28))
Date: Mon, 12 Sep 2022 14:10:44 +0200
In-reply-to: <20220308154204.GA37265@www.zefox.net>
Message-ID: <86czc0eotc.fsf@peasant.tower.home>
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/mixed; boundary="=-=-="
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662987236;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=vLp+XGXa+qCOi+kDCBACiyV2vhs4+LMtmCGw8l06dyY=;
	b=qT3NCvCwgF6PbUkcfLsb3AKWznrCCvQo0vIl27bGcrnRy1vvHNnsHiZB0YJenX9SbvQMl5
	gpBKz6V1SIT0frhyKRdeu6NV886MeA3n7Q5BzPD9NnPriI54sjQLaa9s/6CcEym3k/Clwd
	GyhjbS7d+BRDxetj/xidgZDZ3AcUo4Y8zOFasAW8rwjwkhNmWscUiYMWjxbfXidr0lMJ5Q
	j0yxEcLpFpE8lCuafWC34aYlG3e5qTeaCWq4O4Zki4k1792qbNwBfgt22jNwDputpvHeRB
	a3MYdkrYibDEqk8KZIk8wZ1IXI35T5DoFDxiLeEEJUxyNGJH6V6b+GY5u00m4A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662987236; a=rsa-sha256; cv=none;
	b=fSnK2WajqNveM8tkHybFOtK0HeGsPpnRbt6WJyNvOB93uehPQe0I0vBmXYF9dEOjca2VAV
	pleLTGJ0465zvP92TgC3dWa9nwgL25t6xrSHHj7JM4HRxp3tjNSqSnT/stiVzUyojAzdw/
	sW2AizgiWm1k2Z8O2tsyTP0QGUDmoXSdsaHdjuUHFSKwQWa0OKw6dO5Rf3pQ3lsi/KtPpm
	4cAgYe9tk/LU+FRV/PluivGFG2DRuBKfgFBMSpwlX29JOeQFBFq5B+3ftlHC2lu7wcqJ0o
	NtYD2gvwJn9E9plzYyw1+GTx2CXJkKJVy24xowOEpZs1/kQqI8tNGFpvSzurfQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=dpaa2_panics.txt

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000006d8000, frame=0xffff0000b23a24c0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff000000760d40 in arm_gic_v3_intr (arg=0xffffa000021ab000) at /usr/src/sys/arm64/arm64/gic_v3.c:505
#7  0xffff00000074be4c in intr_irq_handler (tf=0xffff0000b23a26e0) at /usr/src/sys/kern/subr_intr.c:327
#8  0xffff00000074be4c in intr_irq_handler (tf=0xffffa000006d8000) at /usr/src/sys/kern/subr_intr.c:327
#9  
#10 cpu_idle (busy=) at /usr/src/sys/arm64/arm64/machdep.c:257
#11 0xffff000000491ab4 in sched_idletd (dummy=dummy@entry=0x0) at /usr/src/sys/kern/sched_ule.c:3070
#12 0xffff000000416440 in fork_exit (callout=0xffff00000049163c , arg=0x0, frame=0xffff0000b23a2990) at /usr/src/sys/kern/kern_fork.c:1102
#13 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000024b5600, frame=0xffff0000bcda29c0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=lock@entry=0xffffa0000056ca20, flags=8, file=file@entry=0xffff00000093011e "/usr/src/sys/dev/dpaa2/dpaa2_swp.c", line=line@entry=795) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000043a3a8 in __mtx_lock_flags (c=0xffffa0000056ca38, opts=0, file=0xffff00000093011e "/usr/src/sys/dev/dpaa2/dpaa2_swp.c", line=795) at /usr/src/sys/kern/kern_mutex.c:290
#8  0xffff0000007d60a8 in dpaa2_swp_enq_mult (swp=swp@entry=0xffffa0000056ca00, ed=ed@entry=0xffff0000bcda2c70, fd=fd@entry=0xffff0000bcda2df8, flags=flags@entry=0xffff0000bcda2c6c, frames_n=frames_n@entry=1) at /usr/src/sys/dev/dpaa2/dpaa2_swp.c:795
#9  0xffff0000007d445c in dpaa2_io_enq_multiple_fq (iodev=, fqid=, fd=0xffff00000093011e, frames_n=1473863424) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:343
#10 0xffff0000007d7e3c in DPAA2_SWP_ENQ_MULTIPLE_FQ (fqid=205, fd=0xffff0000bcda2df8, frames_n=1, dev=) at ./dpaa2_swp_if.h:45
#11 dpaa2_ni_tx (sc=, tx=, m=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2717
#12 dpaa2_ni_transmit (ifp=, m=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2374
#13 0xffff0000005878bc in ether_output_frame (ifp=ifp@entry=0xffffa00002550800, m=0x8, m@entry=0xffffa00032552900) at /usr/src/sys/net/if_ethersubr.c:513
#14 0xffff0000005876f4 in ether_output (ifp=0xffffa00002550800, m=0xffffa00032552900, dst=0xffffa00028010b68, ro=0xffffa00028010b48) at /usr/src/sys/net/if_ethersubr.c:436
#15 0xffff0000005dff2c in ip_output (m=0xffff00000093011e, m@entry=0xffffa00032552900, opt=, ro=0xffffa00028010b48, flags=, imo=0x0, inp=0xffffa000280109f0) at /usr/src/sys/netinet/ip_output.c:793
#16 0xffff0000005f7204 in tcp_default_output (tp=0xffff000111f72590) at /usr/src/sys/netinet/tcp_output.c:1542
#17 0xffff0000005f0ca4 in tcp_output (tp=0xffff000111f72590) at /usr/src/sys/netinet/tcp_var.h:407
#18 tcp_do_segment (m=0xffffa08004b26d00, th=0xffff00011d8ec0e2, so=0xffff000111f27d80, tp=0xffff000111f72590, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:3294
#19 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#20 0xffff0000005eee70 in tcp_input (mp=0xffffa0000056ca20, offp=0x8, proto=9634078) at /usr/src/sys/netinet/tcp_input.c:1520
#21 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#22 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1153
#23 0xffff0000005a44c0 in netisr_dispatch (proto=5687840, m=0xffff00000093011e) at /usr/src/sys/net/netisr.c:1244
#24 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002550800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:925
#25 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002550800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:711
#26 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#27 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1153
#28 0xffff0000005a44c0 in netisr_dispatch (proto=5687840, proto@entry=5, m=0xffff00000093011e, m@entry=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1244
#29 0xffff000000587f24 in ether_input (ifp=0xffffa00002550800, m=0xffffa08004b26d00) at /usr/src/sys/net/if_ethersubr.c:832
#30 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000be8f5000, fq=, fd=0xffff0000befb1360) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#31 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000be8f5000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#32 dpaa2_ni_poll (arg=0xffff0000be8f5000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#33 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c7c00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#34 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#35 ithread_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#36 ithread_loop (arg=, arg@entry=0xffffa000006c0a00) at /usr/src/sys/kern/kern_intr.c:1306
#37 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a00, frame=0xffff0000bcda3990) at /usr/src/sys/kern/kern_fork.c:1102
#38 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000024b5600, frame=0xffff0000bcda2db0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000005dee5c in ip_output (m=, m@entry=0xffffa00007036700, opt=, ro=0xffffa0006d1f5e98, flags=0, imo=0x0, inp=0xffffa0006d1f5d40) at /usr/src/sys/sys/mbuf.h:1533
#7  0xffff0000005f7204 in tcp_default_output (tp=0xffff00011e090450) at /usr/src/sys/netinet/tcp_output.c:1542
#8  0xffff0000005f0ca4 in tcp_output (tp=0xffff00011e090450) at /usr/src/sys/netinet/tcp_var.h:407
#9  tcp_do_segment (m=0xffffa00007036700, th=0xffff00011d71e0e2, so=0xffff00011cd8d680, tp=0xffff00011e090450, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:3294
#10 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#11 0xffff0000005eee70 in tcp_input (mp=0xffffa00007036770, offp=0x1, proto=9323951) at /usr/src/sys/netinet/tcp_input.c:1520
#12 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#13 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1153
#14 0xffff0000005a44c0 in netisr_dispatch (proto=117663600, m=0xffff0000008e45af) at /usr/src/sys/net/netisr.c:1244
#15 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002550800, m=0x1) at /usr/src/sys/net/if_ethersubr.c:925
#16 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002550800, m=0x1) at /usr/src/sys/net/if_ethersubr.c:711
#17 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#18 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1153
#19 0xffff0000005a44c0 in netisr_dispatch (proto=117663600, proto@entry=5, m=0xffff0000008e45af, m@entry=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1244
#20 0xffff000000587f24 in ether_input (ifp=0xffffa00002550800, m=0xffffa00007036700) at /usr/src/sys/net/if_ethersubr.c:832
#21 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000be8f5000, fq=, fd=0xffff0000befb1260) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#22 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000be8f5000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#23 dpaa2_ni_poll (arg=0xffff0000be8f5000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#24 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c7c00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#25 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#26 ithread_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#27 ithread_loop (arg=, arg@entry=0xffffa000006c0a00) at /usr/src/sys/kern/kern_intr.c:1306
#28 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a00, frame=0xffff0000bcda3990) at /usr/src/sys/kern/kern_fork.c:1102
#29 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa08070a06600, frame=0xffff000111df33d0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=lock@entry=0xffff00011d2c2420, flags=8, file=file@entry=0xffff000000860324 "/usr/src/sys/kern/uipc_socket.c", line=line@entry=2240) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000043a3a8 in __mtx_lock_flags (c=0xffff00011d2c2438, opts=0, file=0xffff000000860324 "/usr/src/sys/kern/uipc_socket.c", line=2240) at /usr/src/sys/kern/kern_mutex.c:290
#8  0xffff000000508f54 in soreceive_generic (so=0xffff00011d2c2200, psa=0x0, uio=, mp0=, controlp=0x0, flagsp=) at /usr/src/sys/kern/uipc_socket.c:2240
#9  0xffff00000050a57c in soreceive (so=0xffff00011d2c2420, psa=0x8, uio=0xffff000000860324, mp0=0x8c0, controlp=0xffffa08157d8c800, flagsp=0x10) at /usr/src/sys/kern/uipc_socket.c:2839
#10 0xffff0000004d37f4 in fo_read (fp=0xffffa0002f5215f0, uio=0xffff000111df3780, active_cred=0xffff000000860324, flags=0, td=0xffffa08070a06600) at /usr/src/sys/sys/file.h:341
#11 dofileread (td=td@entry=0xffffa08070a06600, fd=fd@entry=5, fp=0xffffa0002f5215f0, auio=auio@entry=0xffff000111df3780, offset=, flags=0) at /usr/src/sys/kern/sys_generic.c:369
#12 0xffff0000004d3460 in kern_readv (td=0xffffa08070a06600, fd=5, auio=auio@entry=0xffff000111df3780) at /usr/src/sys/kern/sys_generic.c:290
#13 0xffff0000004d3400 in sys_read (td=0xffff00011d2c2420, uap=) at /usr/src/sys/kern/sys_generic.c:206
#14 0xffff00000077c8c4 in syscallenter (td=0xffffa08070a06600) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189
#15 svc_handler (td=0xffffa08070a06600, frame=) at /usr/src/sys/arm64/arm64/trap.c:199
#16 do_el0_sync (td=0xffffa08070a06600, frame=) at /usr/src/sys/arm64/arm64/trap.c:603
#17 
#18 0x00000000859c9ef0 in ?? ()
#19 0x0000000088c00000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000022b3000, frame=0xffff0000bcd79f90) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=0xffff000000e31b00 , flags=8, file=0xffff0000008e30ac "/usr/src/sys/kern/kern_timeout.c", line=582) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000047d4ec in callout_lock (c=0xffff0001121792c0) at /usr/src/sys/kern/kern_timeout.c:582
#8  callout_reset_sbt_on (c=0xffff0001121792c0, sbt=, prec=, ftn=0xffff00000047d4ec , arg=0xffff000112179000, cpu=0, flags=256) at /usr/src/sys/kern/kern_timeout.c:962
#9  0xffff0000005f0480 in tcp_do_segment (m=0xffffa08089e89c00, th=0xffff00011c8150e2, so=0xffff00011cd40b00, tp=, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:2913
#10 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#11 0xffff0000005eee70 in tcp_input (mp=0xffff000000e31b00 , offp=0x8, proto=9318572) at /usr/src/sys/netinet/tcp_input.c:1520
#12 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#13 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1153
#14 0xffff0000005a44c0 in netisr_dispatch (proto=14883584, m=0xffff0000008e30ac) at /usr/src/sys/net/netisr.c:1244
#15 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002350800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:925
#16 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002350800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:711
#17 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#18 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1153
#19 0xffff0000005a44c0 in netisr_dispatch (proto=14883584, proto@entry=5, m=0xffff0000008e30ac, m@entry=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1244
#20 0xffff000000587f24 in ether_input (ifp=0xffffa00002350800, m=0xffffa08089e89c00) at /usr/src/sys/net/if_ethersubr.c:832
#21 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000bf737000, fq=, fd=0xffff0000bfdf30a0) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#22 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000bf737000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#23 dpaa2_ni_poll (arg=0xffff0000bf737000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#24 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c6180) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#25 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576500, p=) at /usr/src/sys/kern/kern_intr.c:1205
#26 ithread_execute_handlers (ie=0xffffa00000576500, p=) at /usr/src/sys/kern/kern_intr.c:1218
#27 ithread_loop (arg=, arg@entry=0xffffa000006c0a60) at /usr/src/sys/kern/kern_intr.c:1306
#28 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a60, frame=0xffff0000bcd7a990) at /usr/src/sys/kern/kern_fork.c:1102
#29 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001d61000, frame=0xffff0000bc7b26a0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  sleepq_switch (wchan=0xffffa00000724780, wchan@entry=0x0, pri=0, pri@entry=7489536) at /usr/src/sys/kern/subr_sleepqueue.c:613
#7  0xffff0000004b8994 in sleepq_wait (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#8  0xffff000000469134 in _sleep (ident=0xffffa00000724780, lock=0xffffa00000724800, priority=0, wmesg=0xffff000000885cee "-", sbt=0, pr=0, flags=256) at /usr/src/sys/kern/kern_synch.c:225
#9  0xffff0000004bed64 in TQ_SLEEP (tq=0xffffa00000724780, p=0xffffa00000724780, wm=) at /usr/src/sys/kern/subr_taskqueue.c:126
#10 taskqueue_thread_loop (arg=arg@entry=0xffff0000bd74e5a0) at /usr/src/sys/kern/subr_taskqueue.c:834
#11 0xffff000000413568 in fork_exit (callout=0xffff0000004beca8 , arg=0xffff0000bd74e5a0, frame=0xffff0000bc7b2990) at /usr/src/sys/kern/kern_fork.c:1102
#12 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001ab8600, frame=0xffff0000bc7a2f50) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  mb_dtor_mbuf (mem=0xffffa0001d418800, size=256, arg=0x0) at /usr/src/sys/kern/kern_mbuf.c:681
#7  0xffff000000703e4c in item_dtor (zone=zone@entry=0xffff000041b5f000, item=item@entry=0xffffa0001d418800, size=256, udata=udata@entry=0x0, skip=) at /usr/src/sys/vm/uma_core.c:3488
#8  0xffff000000702a08 in uma_zfree_arg (zone=0xffff000041b5f000, item=item@entry=0xffffa0001d418800, udata=0x0) at /usr/src/sys/vm/uma_core.c:4493
#9  0xffff0000004332cc in mb_free_ext (m=m@entry=0xffffa0001d418800) at /usr/src/sys/kern/kern_mbuf.c:1212
#10 0xffff000000431c2c in m_free (m=0xffffa0001d418800) at /usr/src/sys/sys/mbuf.h:1523
#11 0xffff00000043303c in m_freem (mb=0xffff000000432194 , mb@entry=0xffff00011d95f590) at /usr/src/sys/kern/kern_mbuf.c:1571
#12 0xffff0000005012fc in sbdrop (sb=sb@entry=0xffff00011c921310, len=, len@entry=2896) at /usr/src/sys/kern/uipc_sockbuf.c:1654
#13 0xffff0000005ebfec in tcp_do_segment (m=0xffffa08148514300, th=0xffff00011bbee0e2, so=0xffff00011c921000, tp=0xffff00011d95f590, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:1850
#14 0xffff0000005e829c in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#15 0xffff0000005e9078 in tcp_input (mp=0xffffa0001d418800, offp=0x100, proto=0) at /usr/src/sys/netinet/tcp_input.c:1520
#16 0xffff0000005d60dc in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#17 0xffff00000059e3b0 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1153
#18 0xffff00000059e760 in netisr_dispatch (proto=490833920, m=0x0) at /usr/src/sys/net/netisr.c:1244
#19 0xffff000000581dcc in ether_demux (ifp=ifp@entry=0xffffa00001b57800, m=0x100) at /usr/src/sys/net/if_ethersubr.c:925
#20 0xffff000000583430 in ether_input_internal (ifp=0xffffa00001b57800, m=0x100) at /usr/src/sys/net/if_ethersubr.c:711
#21 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#22 0xffff00000059e3b0 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1153
#23 0xffff00000059e760 in netisr_dispatch (proto=490833920, proto@entry=5, m=0x0, m@entry=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1244
#24 0xffff00000058228c in ether_input (ifp=0xffffa00001b57800, m=0xffffa08148514300) at /usr/src/sys/net/if_ethersubr.c:832
#25 0xffff0000007d3bc4 in dpaa2_ni_rx (chan=0xffff0000be1d1000, fq=, fd=0xffff0000be88d060) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2879
#26 0xffff0000007d37a8 in dpaa2_ni_consume_frames (chan=0xffff0000be1d1000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2770
#27 dpaa2_ni_poll (arg=0xffff0000be1d1000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#28 0xffff0000007cc2a8 in dpaa2_io_intr (arg=0xffffa000006bfc00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#29 0xffff00000041707c in intr_event_execute_handlers (ie=0xffffa0000056e200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#30 ithread_execute_handlers (ie=0xffffa0000056e200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#31 ithread_loop (arg=, arg@entry=0xffffa000006b8a00) at /usr/src/sys/kern/kern_intr.c:1306
#32 0xffff000000413568 in fork_exit (callout=0xffff000000416dd4 , arg=0xffffa000006b8a00, frame=0xffff0000bc7a3990) at /usr/src/sys/kern/kern_fork.c:1102
#33 

---

Undefined instruction: f9401bf9
  x0:                0
  x1: ffffa0000073ae50
  x2:                1
  x3:                0
  x4:                0
  x5:                1
  x6:                0
  x7: ffff0000bc795c8c (_end + bb7e4c8c)
  x8:         9de11000
  x9:                0
 x10:                0
 x11:              1ff
 x12:              5a8
 x13:               42
 x14:         9ac68042
 x15:                1
 x16:            10000
 x17:          83cdd00
 x18: ffff0000bc795c50 (_end + bb7e4c50)
 x19:               1d
 x20: ffff0000bdebfc18 (_end + bcf0ec18)
 x21: ffffa00043275a00
 x22: ffff0000bd478000 (_end + bc4c7000)
 x23: ffff0000bdebfc20 (_end + bcf0ec20)
 x24: ffff0000bdebf1a0 (_end + bcf0e1a0)
 x25: ffff0000c0211000 (_end + bf260000)
 x26: ffff0000bde0e000 (_end + bce5d000)
 x27: ffff0000bde0e000 (_end + bce5d000)
 x28: ffff0000bdebfc08 (_end + bcf0ec08)
 x29: ffff0000bc795e20 (_end + bb7e4e20)
  sp: ffff0000bc795c50
  lr: ffff0000007cf584 (dpaa2_ni_transmit + 2bc)
 elr: ffff00000049c5c0 (bus_dmamap_load + 114)
spsr:         80000045
 far:     129a54403538
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 3
time = 1662915749
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
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
bus_dmamap_load() at bus_dmamap_load+0x114
ether_output_frame() at ether_output_frame+0xd4
ether_output() at ether_output+0x640
ip_output() at ip_output+0x1264
tcp_default_output() at tcp_default_output+0x1eb4
tcp_do_segment() at tcp_do_segment+0x1da4
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0xb8
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100104 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Undefined instruction: a8c17bfd
  x0: ffffa00001ab6000
  x1: ffff0000bc78aaa0 (_end + bb7d9aa0)
  x2: ffff0000418f4300 (_end + 40943300)
  x3:              8e4
  x4: ffff0000bc78aaa0 (_end + bb7d9aa0)
  x5:                0
  x6:                0
  x7: ffff0000bc78a5dc (_end + bb7d95dc)
  x8:                0
  x9:                1
 x10:             2710
 x11:         7ff8d402
 x12:         7ff8a9fb
 x13:             2af8
 x14:             2a07
 x15:                0
 x16:                1
 x17:              100
 x18: ffff0000bc78a790 (_end + bb7d9790)
 x19: ffffa00001ab6000
 x20: ffffa000006d0000
 x21: ffff0000418f4300 (_end + 40943300)
 x22: ffff000000bb3000 (sdt_vfs_vop_vop_spare3_return + 58)
 x23: ffff000000e5ea58 (group + 40)
 x24:                0
 x25: ffff0000bc78a7b8 (_end + bb7d97b8)
 x26: ffff000000e00000 (thread0_st + 380)
 x27: ffff000000e55000 (kdb_why + 0)
 x28: ffff000000c3ee80 (pcpu_entry_tdq + 0)
 x29: ffff0000bc78a790 (_end + bb7d9790)
  sp: ffff0000bc78a790
  lr: ffff0000007734b4 (cpu_switch + 60)
 elr: ffff000000775540 (vfp_save_state + e0)
spsr:               c5
 far:         8649a000
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 7
time = 1662916027
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
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
vfp_save_state() at vfp_save_state+0xe0
cpu_switch() at cpu_switch+0x5c
mi_switch() at mi_switch+0x184
ithread_loop() at ithread_loop+0x9c
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100100 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

panic: mutex  not owned at /usr/src/sys/kern/uipc_socket.c:2187
cpuid = 7
time = 1662916786
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
__mtx_assert() at __mtx_assert+0xf0
soreceive_generic() at soreceive_generic+0x54c
soreceive() at soreceive+0x44
dofileread() at dofileread+0x7c
kern_readv() at kern_readv+0x50
sys_read() at sys_read+0x80
do_el0_sync() at do_el0_sync+0x54c
handle_el0_sync() at handle_el0_sync+0x40
--- exception, esr 0x56000000
KDB: enter: panic
[ thread pid 1991 tid 100180 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Undefined instruction: b9805668
  x0:                0
  x1: ffffa00001ab8600
  x2: ffff0000008998ad (do_execve.fexecv_proc_title + 10764)
  x3:               7e
  x4:               6d
  x5:               cb
  x6: ffff0000bc7a2cd8 (_end + bb7f1cd8)
  x7: ffff0000bc7a2cd4 (_end + bb7f1cd4)
  x8: ffffa00001ab8600
  x9:                2
 x10:                0
 x11: ffff000000ead678 (w_locklistdata + 3ff30)
 x12:                3
 x13:                2
 x14:            10000
 x15:                1
 x16:            10000
 x17:         f5fa4dfb
 x18: ffff0000bc7a2bc0 (_end + bb7f1bc0)
 x19: ffffa0001e44a400
 x20: ffff0000bc7a2cd4 (_end + bb7f1cd4)
 x21: ffff0000bc7a2cd8 (_end + bb7f1cd8)
 x22: ffffa0003b0379a4
 x23:               42
 x24: ffffa00001b5f400
 x25: ffffa0003b037962
 x26:              6c0
 x27: ffffa0003b038022
 x28:              962
 x29: ffff0000bc7a2be0 (_end + bb7f1be0)
  sp: ffff0000bc7a2bc0
  lr: ffff00000074da20 (bounce_bus_dmamap_load_buffer + d4)
 elr: ffff00000074db1c (bounce_bus_dmamap_load_buffer + 1d0)
spsr:         20000045
 far:         82f3fdac
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 4
time = 1662917050
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
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
bounce_bus_dmamap_load_buffer() at bounce_bus_dmamap_load_buffer+0x1d0
bus_dmamap_load_mbuf_sg() at bus_dmamap_load_mbuf_sg+0x88
dpaa2_ni_transmit() at dpaa2_ni_transmit+0x190
ether_output_frame() at ether_output_frame+0xd4
ether_output() at ether_output+0x640
ip_output() at ip_output+0x1264
tcp_default_output() at tcp_default_output+0x1eb4
tcp_output() at tcp_output+0x38
tcp_do_segment() at tcp_do_segment+0x28d8
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0xb8
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100103 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Fatal data abort:
  x0: ffffa00001ab6000
  x1: ffff0000bc785fb8 (_end + bb7d4fb8)
  x2: ffff000000928fa8 (console_pausestr + 24fd1)
  x3:               7e
  x4:               7e
  x5:               60
  x6: d28938770a080101
  x7: fc7aaec8d2893877
  x8:                0
  x9:                2
 x10:                2
 x11: ffff000000eada30 (w_locklistdata + 402e8)
 x12:                3
 x13:                2
 x14:                0
 x15:                1
 x16:                0
 x17:               28
 x18: ffff0000bc786030 (_end + bb7d5030)
 x19: ffff00011c52ecf0
 x20: ffff00011bb4a680
 x21: ffff00011c52ed10
 x22: ffffa0812fc9cd00
 x23: ffff00011c52ed08
 x24:              5a8
 x25: ffffa0812fc9cd84
 x26: ffff000000857a08 (cam_status_table + 4b60)
 x27: ffff000000bb3000 (sdt_vfs_vop_vop_spare3_return + 58)
 x28:                1
 x29: ffff0000bc786190 (_end + bb7d5190)
  sp: ffff0000bc786030
  lr: ffff0000005f126c (tcp_default_output + 1d18)
 elr: fffefffffc7f2b70
spsr:         20000045
 far: fffefffffc7f2b70
 esr:         86000004
panic: vm_fault failed: fffefffffc7f2b70 error 1
cpuid = 7
time = 1662983268
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+0x2ec
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x86000004
(null)() at 0xfffffffffc7f2b70
tcp_do_segment() at tcp_do_segment+0x1da4
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0x140
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100100 ]
Stopped at      kdb_enter+0x44: undefined       f900027f
db>

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001ab6000, frame=0xffff0000bc785a30) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  bounce_bus_dmamap_load_buffer (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, buf=0xffffa0005200ea62, buflen=66, pmap=0xffff000000fa1050 , 
    flags=, segs=0xffff0000bc785cd8, segp=0xffff0000bc785cd4) at /usr/src/sys/arm64/arm64/busdma_bounce.c:868
#7  0xffff00000049c7c4 in _bus_dmamap_load_buffer (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, buf=0xffff0000008998ad, buflen=126, 
    pmap=0xffff000000fa1050 , flags=2049, segs=0xffff0000bc785cd8, segp=0xffff0000bc785cd4) at /usr/src/sys/arm64/include/bus_dma.h:129
#8  _bus_dmamap_load_mbuf_sg (m0=, nsegs=0xffff0000bc785cd4, flags=1, dmat=, map=, segs=)
    at /usr/src/sys/kern/subr_bus_dma.c:252
#9  bus_dmamap_load_mbuf_sg (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, m0=, m0@entry=0xffffa0005200ea00, segs=segs@entry=0xffff0000bc785cd8, 
    nsegs=nsegs@entry=0xffff0000bc785cd4, flags=flags@entry=1) at /usr/src/sys/kern/subr_bus_dma.c:530
#10 0xffff0000007cf45c in dpaa2_ni_tx (sc=0xffff0000bd478000, tx=0xffff0000bf0c51a0, m=0xffffa0005200ea00) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2683
#11 dpaa2_ni_transmit (ifp=, m=0xffffa0005200ea00) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2374
#12 0xffff000000581c24 in ether_output_frame (ifp=ifp@entry=0xffffa00001b57800, m=0xffffa00001ab6000, m@entry=0xffffa0005200ea00)
    at /usr/src/sys/net/if_ethersubr.c:513
#13 0xffff000000581a5c in ether_output (ifp=0xffffa00001b57800, m=0xffffa0005200ea00, dst=0xffffa000495734c8, ro=0xffffa000495734a8)
    at /usr/src/sys/net/if_ethersubr.c:436
#14 0xffff0000005da134 in ip_output (m=0xffff0000008998ad, m@entry=0xffffa0005200ea00, opt=, ro=0xffffa000495734a8, flags=, imo=0x0, 
    inp=0xffffa00049573350) at /usr/src/sys/netinet/ip_output.c:793
#15 0xffff0000005f140c in tcp_default_output (tp=0xffff0000fe9fc000) at /usr/src/sys/netinet/tcp_output.c:1542
#16 0xffff0000005ec720 in tcp_output (tp=tp@entry=0xffff0000fe9fc000) at /usr/src/sys/netinet/tcp_var.h:407
#17 0xffff0000005eb9e0 in tcp_do_segment (m=, th=, so=0xffff00011c7d9680, tp=0xffff0000fe9fc000, drop_hdrlen=52, tlen=, 
    iptos=) at /usr/src/sys/netinet/tcp_input.c:1963
#18 0xffff0000005e829c in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#19 0xffff0000005e9078 in tcp_input (mp=0x0, offp=0xffffa00001ab6000, proto=9017517) at /usr/src/sys/netinet/tcp_input.c:1520
#20 0xffff0000005d60dc in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#21 0xffff00000059e3b0 in netisr_dispatch_src (proto=1, source=0, m=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1153
#22 0xffff00000059e760 in netisr_dispatch (proto=0, m=0xffff0000008998ad) at /usr/src/sys/net/netisr.c:1244
#23 0xffff000000581dcc in ether_demux (ifp=ifp@entry=0xffffa00001b57800, m=0xffffa00001ab6000) at /usr/src/sys/net/if_ethersubr.c:925
#24 0xffff000000583430 in ether_input_internal (ifp=0xffffa00001b57800, m=0xffffa00001ab6000) at /usr/src/sys/net/if_ethersubr.c:711
#25 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#26 0xffff00000059e3b0 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1153
#27 0xffff00000059e760 in netisr_dispatch (proto=0, proto@entry=5, m=0xffff0000008998ad, m@entry=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1244
#28 0xffff00000058228c in ether_input (ifp=0xffffa00001b57800, m=0xffffa00052009c00) at /usr/src/sys/net/if_ethersubr.c:832
#29 0xffff0000007d3be4 in dpaa2_ni_rx (chan=0xffff0000bf014000, fq=, fd=0xffff0000bf6d00a0) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2879
#30 0xffff0000007d37c8 in dpaa2_ni_consume_frames (chan=0xffff0000bf014000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2770
#31 dpaa2_ni_poll (arg=0xffff0000bf014000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#32 0xffff0000007cc2c8 in dpaa2_io_intr (arg=0xffffa000006be180) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
--Type  for more, q to quit, c to continue without paging--
#33 0xffff00000041707c in intr_event_execute_handlers (ie=0xffffa0000056e500, p=) at /usr/src/sys/kern/kern_intr.c:1205
#34 ithread_execute_handlers (ie=0xffffa0000056e500, p=) at /usr/src/sys/kern/kern_intr.c:1218
#35 ithread_loop (arg=, arg@entry=0xffffa000006b8a60) at /usr/src/sys/kern/kern_intr.c:1306
#36 0xffff000000413568 in fork_exit (callout=0xffff000000416dd4 , arg=0xffffa000006b8a60, frame=0xffff0000bc786990) at /usr/src/sys/kern/kern_fork.c:1102
#37 
(kgdb)

--=-=-=
Content-Type: text/plain


Hi,

It seems that the recent 14-CURRENT/aarch64 (866e021) with DPAA2 drivers
panics under network throughtput stress test in random places with
unknown kernel exception 0 esr_el1 2000000 on Ten64 board (based on
NXP's LS1088A, Cortex-A53), but the same code doesn't panic on HoneyComb
(NXP LX2160A, Cortex-A72) even after ~10h long tests.

I've gathered some stack backtraces from ddb and kgdb (attached).
Panic itself can easily be reproduced after several minutes from the
start of the test. I've tried to change PCPU_PTR macro to use get_pcpu
again (as discussed in the thread earlier), but it didn't help.

If you want to get your hands dirty, DPAA2 stuff I'm using is at
https://github.com/mcusim/freebsd-src/tree/lx2160acex7-exp (branch is
lx2160acex7-exp!)

Any ideas or places to check would be really helpful.

bob prohaska  writes:

> On Mon, Mar 07, 2022 at 11:45:02AM -0500, Mark Johnston wrote:
>> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
>> > 
>> > > On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
>> > > ...
>> > > A (the?) problem is that the compiler is treating "pc" as an alias
>> > > for x18, but the rmlock code assumes that the pcpu pointer is loaded
>> > > once, as it dereferences "pc" outside of the critical section.  On
>> > > arm64, if a context switch occurs between the store at _rm_rlock+144 and
>> > > the load at +152, and the thread is migrated to another CPU, then we'll
>> > > end up using the wrong CPU ID in the rm->rm_writecpus test.
>> > > 
>> > > I suspect the problem is unique to arm64 as its get_pcpu()
>> > > implementation is different from the others in that it doesn't use
>> > > volatile-qualified inline assembly.  This has been the case since
>> > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
>> > > 
>> > > .
>> > > 
>> > > I haven't been able to reproduce any crashes running poudriere in an
>> > > arm64 AWS instance, though.  Could you please try the patch below and
>> > > confirm whether it fixes your panics?  I verified that the apparent
>> > > problem described above is gone with the patch.
>> > 
>> > Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks.
>> > 
>> > diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
>> > index 09f6361c651c..59b890e5c2ea 100644
>> > --- a/sys/arm64/include/pcpu.h
>> > +++ b/sys/arm64/include/pcpu.h
>> > @@ -58,7 +58,14 @@ struct pcpu;
>> > 
>> >  register struct pcpu *pcpup __asm ("x18");
>> > 
>> > -#define        get_pcpu()      pcpup
>> > +static inline struct pcpu *
>> > +get_pcpu(void)
>> > +{
>> > +       struct pcpu *pcpu;
>> > +
>> > +       __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
>> > +       return (pcpu);
>> > +}
>> > 
>> >  static inline struct thread *
>> >  get_curthread(void)
>> 
>> Indeed, I think this is probably the best solution.
>
> Just for fun I tried the patch on a Pi3 running -current, updated a day or two
> prior. The patch applied, compiled and seemed to run acceptably, but when I 
> left a -j2 -DWITH_META_MODE buildworld running it crashed overnight, reporting
>
>
> login: panic: rm_rlock: recursed on non-recursive rmlock sysctl lock @ /usr/src/sys/kern/kern_sysctl.c:193
>
> cpuid = 0
> time = 1646720264
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> _rm_rlock_debug() at _rm_rlock_debug+0x214
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
> sysctl_root() at sysctl_root+0x1ac
> userland_sysctl() at userland_sysctl+0x140
> sys___sysctl() at sys___sysctl+0x68
> do_el0_sync() at do_el0_sync+0x520
> handle_el0_sync() at handle_el0_sync+0x40
> --- exception, esr 0x56000000
> KDB: enter: panic
> [ thread pid 869 tid 100091 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
>
>
> I tried typing bt at the debugger prompt but got no more output. 
>
> I've put the buildworld log file at
> http://www.zefox.net/~fbsd/rpi3/crashes/20220307/
>
> Hope this is of some use....
>
> bob prohaska


-- 
Dmitry Salychev

--=-=-=--

From nobody Mon Sep 12 22:08:03 2022
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 4MRLMJ3hy4z4cSKp
	for ; Mon, 12 Sep 2022 22:08:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4MRLMH3K9Zz3nPY
	for ; Mon, 12 Sep 2022 22:08:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663020489; bh=Juet28JHQoTk7pUt6F14Xiwobbzqd1dn7xB7vgJkxsc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KH5KpTB/zF2zuCbwJtc7XGwxbLlrqpFV/ePDyMcxuYgG8+vCZirb1Fa76j5nkpefEP4yzCRhRZrwzNHX3wsUDs/EKYx8DOK8vk+0y3a2BSxpO0o+0O1B4CXlFRNwp/ygZrt6QxZyyUH4zN2GB+T3ZR5JE6EHdr21b7vE592wrCqrOFi0WWlGe4YlELGWzSrn6/0l0KYSoLngVCDmJpbOCO+V+Hd+IqsksuXzJDE7QEaJ4SYE8PUjvy+ii7Lg8iQOAOzpOJHEN/lH+UiCeC+KDbqwunBwXam74uM6ERH7VcOQ4REHGGdKqmEphTyTv9TiG/Dsa9onFm2/w+DtwYBQbw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663020489; bh=9MF9J5Fwq2IggiN/dpBKn/At/qon/3irl8EmVs5ZwLC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SBee2E/msP3WKuvcLVXhtocCvkzyN4DpymGRUymSizSrhrr7k6MpxQNcLTQzfdmpV/6Am35+NnKQAaE5u4ifrBjL/EtotEqwky+xvRiVArldcJJV/zR/cK2G86Q3IXWjQyOvOHaNr2MZ45tRM+pXIlBPZx2Mo312N3XXZz0FTshrxMiI5HlTkayoSFczyWGPUqNiV/wpMnT/8tBVgXV9jXrvixZHCm0LHpPYQmgzIqPDGwfZjDUALryDrxL+zkNAHbhv+din7ybheUCT1Pof0ekTAJHlvPTWPha8A5n99K0dSfTmZzdOwmRCYaCn4S6Ko6gX2caNdFBotDLQo6+rJw==
X-YMail-OSG: k1FghOsVM1k_pE9Cr1T3r55xkXQTlHmc2MQ7IQ2ci41yJB0cnKuuJiOlwEgjgtP
 ajLGYM.TGyQkwBoMk178Wf7X02x.IpCzPNXi.nTayVtVPSamzILlDA0K934vFTrm4T7yqqV.GUIN
 rN2TZaMSGpr1fCnuT8GQs6jqc0VJtbpd8lHOa5JeDcHjwggMc5J655PkLkfh889Gx9UX4qmVQVJ4
 54lFdjLrdFxckHDOfE.kS0BQvdtHphJu.UKQth1yJTb8xBK_Z5wYPOMmp2173nJ9aaTRmLZ0CyLl
 rkdps0sLvoI2tRyjF.3WHOZSqz4Z64iPgGwrR0DPDh3WWoz.JiLwjvoYlAfqHC.96_eQryM8yLng
 LEuXxnHrdbJP5_CSCAgtTSg8eGUiF9Ry8aDBz7.b3Q4KOsS4cWxOn6VhbxGsTKe9zli54JZSMGMm
 El4QWu0NsFAhAuCs8sTSt9I7Z9y0LmgABzDVZN8hG4aPqmrm8yqzxyvxMnNccOslJoE6z0EjUhG7
 cQUkC0SM7n.55Bm_5w4czLI80gQmhImw2g.kT7uO1hJ6L0jvEa4f64kqdbqLBybL7VWFjlhEvnOm
 0VCBjXuEw5HyAkcxBHH5wtYwNGGce4XOIMMCEFHCraEcDzCs0A3o8fDjYuw8uNnZsxwhDvLAgmN4
 5ALvimLknO.j9fZaR8Mke2zWw_mGuuec7iq1eWGYCpY5HgqrzpCXYn9hn_aQQGCyAe0guvLMaE25
 vd5jVgmvoBuz8X5NnxHIFYCmfWkXbRLXDBzrXJMe0hLghgQVj7Qm9YfTHUSRKDDWU8.tpeN1.P3j
 55x5ofaNzauPwFglRcBDWg2UCpPkabSRUKPytoVPk2okj2dZZcKyHvQBerBZAVhN78LIVfi8sbWQ
 EvO0fDMO72bem0B.Q3lKpijqHgDXSNebriiu5YaVO2H494AEePBaWXo.Pi7JCSIlkjPPPaL7faSm
 C3_N2Cnc2YMW6D7CMgW8ApmTc41jpAIgtlmsZhivYKTII3oFxYDpKBehHsoJfxqPOmcK8JKMGZ12
 VDg10Z_UIYi.B63ATQ_rvxCatT301.cZ8.EUzC2TNlwCqvpG8K3RTbDCIeRZtUJktbDRW76eCGKo
 euwadv7vjiHooqoMAOYrMyIIQW298I4AWKjUjb_8khYV4jctY5Y99bl8GXM4XO.x2xhxj.fsCUxk
 M3ACOR90vond1taVmN89l6cXoeqwwQ6KoSY5RYo8Jo3rakHNUjEXCFN5e8PXfpwQYA8GDH99dGEl
 dUbr3beHGSAML9v8gerItLxI7gockVr4BbJ.pgwbSajs3dMo5_KIrUdPBxcDy_8ZYvhLU7P2Mm3_
 95gzfNNYRQ8.uezNRlv7VLQgpiaPjh9OkxVz1QuUTTM3EnDcgqKs3uLcEMY2a5IlsO52doVUK1Ht
 U4yprxLiKtXgWrHdFXO9fSx5HN8G2PuvMNIfr0ociDYyeRjpeFu7PI_QRrPEU8VGAXjrjj3jkpEY
 Go0HfOS6d_ZTLKsIPOjo8EyEi0vVrMt9ZQYYEE6YVzZj6d4nTt6E.YBNgq0TEPfziiGbU7_a4s3U
 4TuATJGbnWkH57n0HBOQfAp2SHsWskD_9gScfA34D2iXnswWaptRf6tGbrz49KDFy71zMRraZn12
 dWeG2ddU9pXKx6lJzQ9b8_00uup1R36rx1C.VqYaJu2xwTBxSWfV4a6v9OtsrNB4XPmoXFK3sJ2r
 jHYZvZrow4lTen7oEOzcnrleUEh.qqfNevYV4iBS74A2aB2xNwXAXEd5zhIvXZgUnAVtqnl9skqP
 hH1m.veGPWoJJg84hdSGqFYjBhbZRE7_.t43pNPRYcwlwbxBVtCFDwZiOXJodDa3dpprcKTnsK99
 1AqWoeg4EC6gks6n6MklY7HkXuMkb8GSAy4DEBf0kKozNmSAjJoLNDTaIYlt5zDUitzwXu2ik8hX
 95bRc5g3QZsn5n36KfMw_qmvlKgXkWmZkcuBDM5RJQcShQYXB8G1H.29xAPq9I2sZatHXquO94BQ
 Noyflevo8zejEzIC.d5Mu4RpKkkMYx.cZvoQbO_9uPALz9Zn9J3lwB0eA5uFq7I0.wX.MCYluYtn
 9wgS6YLOfChHoCYm8GlKFASYapXU50iyV5GqzpJ1X.ZrSpKpG8Gf.6joF_a7L9rDGVplr7fVQ9US
 _mEZNSXoJPYtfBZscxx0K9erP7eOp0Tfcm.4toJiyx7rKrQwY7ad4RBYXddhy6avKvlHcst1EPfi
 0856v4a9066Nn9fk.MbbSam0Th6xC2lWd0PeLYFQyPgETgqqzrJTY54xBvTZ3NAMYSr3.iCGVg66
 NM1XwY9M-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Sep 2022 22:08:09 +0000
Received: by hermes--production-gq1-5499fdd576-49dgt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 84fd9d53cc1b48dc6ce704638f11ed39;
          Mon, 12 Sep 2022 22:08:04 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
From: Mark Millard 
In-Reply-To: <86czc0eotc.fsf@peasant.tower.home>
Date: Mon, 12 Sep 2022 15:08:03 -0700
Cc: bob prohaska ,
 Mark Johnston ,
 Andrew Turner ,
 Ronald Klop ,
 freebsd-arm ,
 freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E1552DB-4A65-4DFF-BC79-CFE045ECF972@yahoo.com>
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
  <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
  <20220308154204.GA37265@www.zefox.net>
 <86czc0eotc.fsf@peasant.tower.home>
To: Dmitry Salychev 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MRLMH3K9Zz3nPY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="KH5KpTB/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-12, at 05:10, Dmitry Salychev  wrote:

> 
> Hi,
>=20
> It seems that the recent 14-CURRENT/aarch64 (866e021) with DPAA2 =
drivers
> panics under network throughtput stress test in random places

3 of your examples get a signal handler called at the
exact same instruction:

#6  0xffff0000004ced5c in witness_lock

The parameters vary, as do the callers:

#7  0xffff00000043a3a8 in __mtx_lock_flags
(twice)
vs.
#7  0xffff00000047d4ec in callout_lock
(once)

Showing one more level, where all are distinct:

#8  0xffff0000007d60a8 in dpaa2_swp_enq_mult =
(swp=3Dswp@entry=3D0xffffa0000056ca00, ed=3Ded@entry=3D0xffff0000bcda2c70,=
 fd=3Dfd@entry=3D0xffff0000bcda2df8, =
flags=3Dflags@entry=3D0xffff0000bcda2c6c, frames_n=3Dframes_n@entry=3D1) =
at /usr/src/sys/dev/dpaa2/dpaa2_swp.c:795
vs.
#8  0xffff000000508f54 in soreceive_generic (so=3D0xffff00011d2c2200, =
psa=3D0x0, uio=3D, mp0=3D, controlp=3D0x0, =
flagsp=3D) at /usr/src/sys/kern/uipc_socket.c:2240
vs.
#8  callout_reset_sbt_on (c=3D0xffff0001121792c0, sbt=3D, =
prec=3D, ftn=3D0xffff00000047d4ec =
, arg=3D0xffff000112179000, cpu=3D0, =
flags=3D256) at /usr/src/sys/kern/kern_timeout.c:962
(no address shown)

Perhaps looking at what the code at 0xffff0000004ced5c
(and before) is doing with what kinds of data would be
useful compared to the less frequent example signal
handler invocations. It is common to all 3 call-chains
above. If dumps for them are around, more than the code
might be able to be looked into.


> with
> unknown kernel exception 0 esr_el1 2000000 on Ten64 board (based on
> NXP's LS1088A, Cortex-A53), but the same code doesn't panic on =
HoneyComb
> (NXP LX2160A, Cortex-A72) even after ~10h long tests.
>=20
> I've gathered some stack backtraces from ddb and kgdb (attached).
> Panic itself can easily be reproduced after several minutes from the
> start of the test. I've tried to change PCPU_PTR macro to use get_pcpu
> again (as discussed in the thread earlier), but it didn't help.
>=20
> If you want to get your hands dirty, DPAA2 stuff I'm using is at
> https://github.com/mcusim/freebsd-src/tree/lx2160acex7-exp (branch is
> lx2160acex7-exp!)
>=20
> Any ideas or places to check would be really helpful.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 14 10:24:54 2022
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 4MSGfw4HTGz4bhf2
	for ; Wed, 14 Sep 2022 10:24:56 +0000 (UTC)
	(envelope-from t_uemura@macome.co.jp)
Received: from mail.macome.co.jp (mail.v4000-114.mailsecure.jp [203.138.86.114])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MSGfv5tK0z3dVs
	for ; Wed, 14 Sep 2022 10:24:55 +0000 (UTC)
	(envelope-from t_uemura@macome.co.jp)
Received: from towerrecords.dyndns.org (unknown [111.90.40.59])
	(Authenticated sender: t_uemura@macome.co.jp)
	by macome.co.jp (Postfix) with ESMTPA id 95E1E224C7
	for ; Wed, 14 Sep 2022 19:24:54 +0900 (JST)
Received: by towerrecords.dyndns.org (Postfix, from userid 58)
	id 5FA139B8774; Wed, 14 Sep 2022 19:24:54 +0900 (JST)
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on
	towerrecords.dyndns.org
Received: from [10.141.30.100] (20f9cto.shiba.local [10.141.30.100])
	by towerrecords.dyndns.org (Postfix) with ESMTPSA id 172869B876E
	for ; Wed, 14 Sep 2022 19:24:51 +0900 (JST)
From: UEMURA Tetsuya 
To: freebsd-arm@FreeBSD.org
Subject: Fix for I2C RTC nxprtc, broken since 2019
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-Mailer: Becky! ver. 2.81.04 [ja]
Message-Id: <20220914102454.5FA139B8774@towerrecords.dyndns.org>
X-Spam-WB: 128
Date: Wed, 14 Sep 2022 19:24:54 +0900 (JST)
X-Rspamd-Queue-Id: 4MSGfv5tK0z3dVs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of t_uemura@macome.co.jp designates 203.138.86.114 as permitted sender) smtp.mailfrom=t_uemura@macome.co.jp
X-Spamd-Result: default: False [-3.17 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.974];
	R_SPF_ALLOW(-0.20)[+ip4:203.138.86.114/32:c];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[macome.co.jp];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ASN(0.00)[asn:2514, ipnet:203.138.0.0/16, country:JP]
X-ThisMailContainsUnwantedMimeParts: N

I've found a timing issue in nxprtc.ko and filed a bug with a patch.
Please someone look into the issue following and hopefully commit the
fix.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266093

Thanks in advance.

-- 
Tetsuya Uemura 


From nobody Wed Sep 14 13:42:29 2022
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 4MSM354Pj7z4c8dS
	for ; Wed, 14 Sep 2022 13:42:41 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 4MSM346HYBz3vyQ
	for ; Wed, 14 Sep 2022 13:42:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id h1so15898900vsr.11
        for ; Wed, 14 Sep 2022 06:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=7EMo3ed0knSwqHPoqz4eqrVsoQe3PLm3ivS+e3/dhyw=;
        b=Ds0hdaT3KYRltiz+7SKZ3CmmV7zvjA0Eh+teOTivg4Ybr4eBR4eflzEXphgIbCWMz/
         NPW2849Wdvp9hDCCoz3VzNJJIert/bxyjPJoR8fyEskqrLIAcVuhVC0Nfy0OmXVZn8CW
         FdIu0wXEg4zlnZcpUDya0+lvAJHlyqG+lILv9QJzmMYY0AkEs4uVni44cmeg6i0KyZuo
         0+hb0XNMtyMDC+vy5Q7yJzPV82DD1fOiOSju3ZJtVPDjlPe+Vo3yFb+ITS60TMHWSYrf
         Y3SI2svhLY9+b6OlIsDJnzqmYoanFBj0uoRMSAP9GmZMdpCQaD8TsRP4kcHl/iB5qt2b
         i/qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=7EMo3ed0knSwqHPoqz4eqrVsoQe3PLm3ivS+e3/dhyw=;
        b=wcaGlqnRyeozHuBE/dQlkhotQi93r6gT07Ryy91jPunYU89vJ4/JDHrNxN/++J2wMK
         4IUGo/a3szdS8OZGTwZLSeuy7/RinwP4iBROzqsH+SZFdaatMZPw3n63htkErUNZzZ1D
         W1PFdQAaVuWgjqhVp0LPh3xX5j+K7eiywYcoZ5VCkICzoDOwF9vtBOqJfMm3hHTb+JiK
         NDaK89w50FYj1/guGChhXKJYvZ35yxmYMk2pthr2yG7q+RRircUBKQ8QT8aIs+nqttin
         Az1xbU9yuMohByY6m32Pux2Ycr+hnKIotXtU7EB+4JSkkjjJb51MwPZmQ6VVqSJP+IZT
         U/UA==
X-Gm-Message-State: ACgBeo1Vw8VhML1SJi11/bk1rUfFR4o0LIAq9pebg/A+caimv+e+onZk
	hDjUuY5Ellyv3LLaLFA7tGDdc+wT8e6DuQM0acdrkarbZKHUiLGp
X-Google-Smtp-Source: AA6agR6cqyeI1Et9kSMCPys8VM4zX+MM4GHrcGuohwZHGGrszWuO2PAe9eToM3H/ES6/kbQbDAMF8zyhZNpKUhRlovo=
X-Received: by 2002:a67:fb8a:0:b0:398:9d72:bddf with SMTP id
 n10-20020a67fb8a000000b003989d72bddfmr4457565vsr.38.1663162960308; Wed, 14
 Sep 2022 06:42:40 -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: <20220914102454.5FA139B8774@towerrecords.dyndns.org>
In-Reply-To: <20220914102454.5FA139B8774@towerrecords.dyndns.org>
From: Warner Losh 
Date: Wed, 14 Sep 2022 07:42:29 -0600
Message-ID: 
Subject: Re: Fix for I2C RTC nxprtc, broken since 2019
To: UEMURA Tetsuya 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000007401a605e8a34d5b"
X-Rspamd-Queue-Id: 4MSM346HYBz3vyQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Ds0hdaT3;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007401a605e8a34d5b
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 14, 2022 at 4:24 AM UEMURA Tetsuya 
wrote:

> I've found a timing issue in nxprtc.ko and filed a bug with a patch.
> Please someone look into the issue following and hopefully commit the
> fix.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266093


Thank you for your fix UEMURA-san. I have committed it as e2386f18eca2.

Warner


>
> Thanks in advance.
>
> --
> Tetsuya Uemura 
>
>
>

--0000000000007401a605e8a34d5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Sep 14, 2022 at 4:24 AM UEMUR=
A Tetsuya <t_uemura@macome.co.j=
p> wrote:
I've found a timing issue in nxprtc.ko and filed a bug with a patch.
Please someone look into the issue following and hopefully commit the

fix.

https://bugs.freebsd.org/bugzilla/show_bu=
g.cgi?id=3D266093

Thank you for your=C2=
=A0fix UEMURA-san. I have committed it as e2386f18eca2.

Warner
=C2=A0


Thanks in advance.



-- 

Tetsuya Uemura <t_uemura@macome.co.jp>








--0000000000007401a605e8a34d5b--

From nobody Wed Sep 14 16:20:18 2022
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 4MSQY272ljz4cVBr
	for ; Wed, 14 Sep 2022 16:20:22 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MSQY13nHGz3LpK
	for ; Wed, 14 Sep 2022 16:20:21 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.nyi.internal (Postfix) with ESMTP id 74CE95C0105
	for ; Wed, 14 Sep 2022 12:20:20 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute4.internal (MEProxy); Wed, 14 Sep 2022 12:20:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=
	1663172420; x=1663258820; bh=eKJBJYZk7ECiEIhy0JwWT86EE2DV58ZgOfO
	Lwb71ldk=; b=T4QGl5/2lUkwMKln15qJsap4sYUexPHIRVqzqHoiVWPYEC9bR6V
	7hrs5OKxuXZl9mnaBXUfK8uyvWk+ujNwqiCknQDsdUnO+M8FvImJu2y2G9ofSs3t
	76UAf0zWO4C2bVkYchSXnc9WRQPGsxiIaHce9QHR/+TXTcyU1gW9IWBvgWBF+dNF
	pwCWYqLfbNXgG/x6a8h6JB7vLCCXg3GoUjEeDWE0jsx7pbq+Qu9aSDAk4SOalFZ7
	92mrcI1KpaZQAg+qkwPF9OzyX+C9m5JjIWJidYbX3ZfepfGVhUxgB9gl+SRnHgH/
	RbRCx1x52dVE4HBtXGdE8FF8itUroYnTv6A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663172420; x=
	1663258820; bh=eKJBJYZk7ECiEIhy0JwWT86EE2DV58ZgOfOLwb71ldk=; b=N
	r9pBB6fJFruDZLNIhdzWLvbqPAycYf4RDObvRXpM6AVTL429E+jBE4pjSkSm52CO
	ECLMKii2UisHpDj/f7OLzs1YYKG/oNkVI1tAC1mn4rR4CJgvCxOG9gAfHM0wE8R8
	tJf8RYy/QVnFDU3TiCUaX9fjXJ6JbteLIuGpQR3F9hxL7coGHjV7EJiwGk6pgShm
	86bJStkC5q2bdWaDat3TN2sbS/x4ju0jxypiuRpILq3etnP39rMtKy4QsdovWRRT
	G+M2PHZ+xDiVbhk6W37/qsaflX84fIvJOjF2Y9s7zQEAom7aZO0HS+eOZTTqzbIC
	SJfA9FMAzZoSvb2NkswSw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduiedguddtudcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
    necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertd
    dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght
    thgvrhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehge
    ffueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv
    ohhiugesfhdqmhdrfhhm
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Wed, 14 Sep 2022 12:20:19 -0400 (EDT)
Date: Wed, 14 Sep 2022 17:20:18 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: gcc failure on -current on aarch64
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
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
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MSQY13nHGz3LpK
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b="T4QGl5/2";
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b="N r9pBB6";
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-5.09 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

I'm not sure whether to raise a ports PR for this, or if it's
an aarch64 problem or if it's a -current problem so if this is the
wrong list, please advise.

On a php80 installlation running recent -current using ports
built yesterday in poudriere with a fresh ports tree, php80-gd
upgraded but now php complains like this:

PHP Startup: Unable to load dynamic library 'gd.so' \
(tried: /usr/local/lib/php/20200930/gd.so (/lib/libgcc_s.so.1: \
version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not found), \
/usr/local/lib/php/20200930/gd.so.so (/lib/libgcc_s.so.1: version GCC_4.5.0 \
required by /usr/local/lib/gcc11/libstdc++.so.6 not found)) in Unknown \
on line 0

Sure enough, GCC_4.5.0 isn't there

# strings /lib/libgcc_s.so.1 | ug GCC_

180: GCC_3.0
181: GCC_3.3
182: GCC_3.3.1
183: GCC_3.4
184: GCC_3.4.2
185: GCC_3.4.4
186: GCC_3.5
187: GCC_4.0.0
188: GCC_4.2.0
189: GCC_4.3.0
190: GCC_4.6.0

# strings /usr/local/lib/gcc11/libstdc++.so.6 | ug GCC_

6111: GCC_4.2.0
6112: GCC_3.3
6113: GCC_3.0
6114: GCC_4.5.0

Is the problem with base/ports/gcc{version}, gd, php?

freebsd-current is main-n257818 built 5th Sept
-- 

From nobody Thu Sep 15 03:49:52 2022
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 4MSjrl45cKz4bq2D
	for ; Thu, 15 Sep 2022 03:49:59 +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 4MSjrk58HPz4J9l
	for ; Thu, 15 Sep 2022 03:49:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663213796; bh=qfzPh3bBX9xSbuZO1+A/iiCwemLA7qwYBYva7n1459c=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=qymznty1Ne2O1G8mVwM1fHzuXQo4V4lNYaKmid+tAXrtk3nqRXAjybZ31D1QuZtt8Pv2dcx5ABlXmVSl01+315+rPtc/YZrRqa8RLYZIUptlNSWlUpk5W2tqa6f9ddpHJ0nOfDRy79pi9yS5LsisA3khRpVSSJSC1i5HHsOpK8v4AS3Ro/KTyZmBiQTZ789KyU4F9Ot/jk/WZEhM+vtqihgxQ/jB+1vaKv2LMRjRtHM3PsxJ0qGC7vP0NVKQJjaBaBJ4hKQdMMehlOgdCi4jjtBQxExtrbA2/pmLxwVfZlkOHmxqCiKxCc51xfONzYNF2oLI5HNo38LEPUkoa1IWtw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663213796; bh=PwlejnMmGCglFrOJ7KLOlBGL4ZNdBOUdlS/0OfI0a4C=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=e2NqCBLXtPh8zCLnSdAnkMOgaNzmE1v7Qz/q4GY4yZEynutRIvP15ID9L8AjJ9H5oug0XIgrNCYFd1U90m+HBpSdTKl7l64oVu/XQalmfF9w5jVEeRFDl6J6uBVWE0RT2GvoMWS03mBkA1j0DQpqNYG4b2vQFn5t6nqVRUpfBf7Wtf5XDpcXVW+/OqycoJDQ74gcUCMIzP/CbEvf6pbjnwb3mPpO5p6pX/roQGUIShnVvmq1Vf//IT5wdyHD92frX1NRMtmJ0uJIMcU4gBa7H5YIj48QS5G3bMAnzATnGgWHZI8POBCR55mgpY0XQhxGPag6XhzrCpNLnE1CdPQxFQ==
X-YMail-OSG: DE03LmoVM1kr8duwx0paEtZ6_cqBTVGf_5Ruh8LNPtm.nchq6n3Cz03bvjvx8sb
 2VK0RDTIGkkWbp1qfMdQdX8loe1YtvpBwx2vvUMdKF1IEaHLZI3cTtAcql.htEPMssi3F1eg48uC
 op7GV8rIo.Bg5zisl5RigspRoeyZDQKMT6Ptr.KhscCTTjge51CR7JGK74.Xasvpg2nfW5UUIIgy
 kn7iMaBMJrZr0._k9tJ7wZPg7qd2IYzQ3PVZYWrnmHJbBYHYezh4boVj.n4tA9s3YdaPrKatNv4F
 sxbN7NelOfivO2sHfFEfgrPlqiFGEse6b0iq_nzMmz1OfJiQzBBHhfsVVFqok_vbW.4S0GwGHj.K
 e5K8PxdZSM.F6_MXrl3r4oeveoMXI9I51IfFrY0ULixyBV.uFruofEvKKWyIKl9SRJ6X5D4pwIFp
 fSTPRZklbnuvKVuECbqGpoO0Jl4bzNrU.pvg2jYU7DeO6JylBg98Pf745SWEDf3WKhrgMkeGSRf4
 VOWrUiYq6Smd8.4mzs2XPuhTdkskawWURwNKKZqXThiDIWP0lQ9y_45Gp6_FtR8aOjSAvNsLBCXN
 PPD0G25U7MaeYou1cA8wGtTUAjXgzINFSjCsuxgFQKLTmeNtFIFROSz8X62NzQGrlghGLk4eqAio
 kQak4B74koXQrfe8NA2lnP9AA6GZccG1nSJIayzh1CPNb1nl_vbwEeUph7yUiv9nctj3ZKDGOZqo
 BbHd1DA9DRq4XDjpsKbIn0RoS6oh5_HA8.F7SpDZMSUa4pogHJRrS2qMrFrljLrttpTQAEwubsXJ
 Rl8GhnJ6KH8oTLNjbpAy6N185HQGmnf8To8A6zAyWmWwTlLBpJahXsOh540ibgO0b4CKmpUXj6AF
 6dNF.an6WMzwKiUfNCNV.YarVVK.aAFg2Ko5M.OUTyaCtVIH0yQVyvs11GA82FrM61N3sVj72D7f
 7aei7PsXgajqKKOdgrUG6Riu6fzq0.KehOTEFvh_eYnTF2qOfuWUo7LyWYs_ddcyxrKma95QrH..
 Pk0aDUChmgrk9e46OywHwpHVjW_ErfYhMypbFRjxaVyUz.wFr4ogGtqC65CYe4QoeO.LhqLrSKm1
 r00zg5cro39AKW.k1KEjJ3V0sPz4bDWrqjhUrW1hreB17OWesuq2zJYt1N1HaWMdPQyM0d0YBW4e
 pfsBQ81VfTmAyIPiTQWMkzTf9rSKcrPaTUn3m0knRJ02aoJrRu17gb_f1jKQkQ6NADbHlaYwvMVE
 Ult_DThYpY4fqi4fzfwTJzcEMs41ktS.wxqIMSWApKf7hb_VtXq2K4C4riOeX6gou3trE5Xdlh4N
 e95QhWni2ZFV3Cc1osr8wHYJmIXMbigQz8yTBpb5K0MB_OPi2fUutwhuiXc5qZNM0Jt0OjnT_DNQ
 RovqPzZktCY5QEJT.4pDFYBVDr.4t0N1NANjd2SvwNzjWZ.JzaZgtTwasSQ_Q70tQC953loGwxHC
 6Uq0Z3hRdszIkRkJs.jzrozyyzo6qeeDm.WtRMGmjr_jrR4VVzEpaOrl7KyKSELFlhNpCVijGqrJ
 8eHc6G_peQ1sqae0tAmMeKP3YSFpettAx.k_oz7gL0WRJjiFFuWVEBxAqW7F430rpsO.yo4crqwq
 4kjG_pmbfy9.ueTqm2eyihud9vXXaZlwx6vAr1HqsucfLSoQ6acyNvuy_V5_sYtAZqkY5sF4gQpd
 dA6rfl9aB.0MBvfg.iKnBXVBxi6czLs8434sAIbLhV3YIqc1WPzkeggNsx_pHmsVz5mZ.dGXBHBK
 N.Ima5pYVx7Men7sp7q5HHhL2FCJzBMcHLpuwAZojfbvz2taeY1xdN1vkcpq5UurWLx_AGo59Saw
 y2jDeRFkkUoJxRPv56O7bRWrodTbhHmLOZ_jsi97RfuOJBgE_Six3PIbpKd_OIKpNT3nNEtssS6Q
 EDKCE0dCM228Mpg6pTWILk6tnr5.43ThFoKbbj7DU6TKy08yPW20R14_LYUpFILK386kMApi_Srg
 XQVry8xkTXp462Gbupgvw2tHzrpoH360Df8wdDYJl4DkFNLg907KKiTSmNlu9F0SapfezvAiseaP
 ODTvbZ6W9QkOoeot_EXj9q4E.7tChXU.3hJ25FhzQYbCdebKjlKljDoNaXR0KYGZhLfqvOfDqbTd
 2ylQMBD0LjxbHq.H.XzLEcKprpqXqnubHf3trcP1aNqj_cUJPR2VFB.j9k09f0Ncdedz7YDrJvcF
 eXtCyIOuzPVEtnil1W5mDWZBkSMCZN1ALG3NNc9W.H6_jXk687IItzQBHobGIWkVxCXyvwIRciA-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Sep 2022 03:49:56 +0000
Received: by hermes--production-ne1-544744cc75-kxtjx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c0ef286edc2a331454f8718187234c5a;
          Thu, 15 Sep 2022 03:49:54 +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 14.0 \(3654.120.0.1.13\))
Subject: RE: gcc failure on -current on aarch64
Message-Id: 
Date: Wed, 14 Sep 2022 20:49:52 -0700
To: void ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4MSjrk58HPz4J9l
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qymznty1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-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];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[f-m.fm,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]
X-ThisMailContainsUnwantedMimeParts: N

void  wrote on
Date: Wed, 14 Sep 2022 16:20:18 UTC :

> I'm not sure whether to raise a ports PR for this, or if it's
> an aarch64 problem or if it's a -current problem so if this is the
> wrong list, please advise.
>=20
> On a php80 installlation running recent -current using ports
> built yesterday in poudriere with a fresh ports tree, php80-gd
> upgraded but now php complains like this:
>=20
> PHP Startup: Unable to load dynamic library 'gd.so' \
> (tried: /usr/local/lib/php/20200930/gd.so (/lib/libgcc_s.so.1: \
> version GCC_4.5.0 required by /usr/local/lib/gcc11/libstdc++.so.6 not =
found), \
> /usr/local/lib/php/20200930/gd.so.so (/lib/libgcc_s.so.1: version =
GCC_4.5.0 \
> required by /usr/local/lib/gcc11/libstdc++.so.6 not found)) in Unknown =
\
> on line 0
>=20
> Sure enough, GCC_4.5.0 isn't there
>=20
> # strings /lib/libgcc_s.so.1 | ug GCC_
>=20
> 180: GCC_3.0
> 181: GCC_3.3
> 182: GCC_3.3.1
> 183: GCC_3.4
> 184: GCC_3.4.2
> 185: GCC_3.4.4
> 186: GCC_3.5
> 187: GCC_4.0.0
> 188: GCC_4.2.0
> 189: GCC_4.3.0
> 190: GCC_4.6.0
>=20
> # strings /usr/local/lib/gcc11/libstdc++.so.6 | ug GCC_
>=20
> 6111: GCC_4.2.0
> 6112: GCC_3.3
> 6113: GCC_3.0
> 6114: GCC_4.5.0
>=20
> Is the problem with base/ports/gcc{version}, gd, php?
>=20
> freebsd-current is main-n257818 built 5th Sept

[I've run into this issue in multiple contexts recently.
But I figured I'd leave notes here on the list as well.]

For aarch64 specifically, FreeBSD's /lib/libgcc_s.so.1 simply
does not provide everything that the various

/usr/local/lib/gcc*/libstdc++.so.6

require, including for g++11 use. (Even plain C code can run
into the general issue --but usually does not happen to use
something that does. libstdc++.so.6 from older lang/gcc* and
g++ code generation also run into the issue.)

Because of this /lib/libgcc_s.so.1 mismatch for aarch64,
/usr/local/lib/gcc11/libstdc++.so.6 needs to find:

/usr/local/lib/gcc11/libgcc_s.so.1

instead of

/lib/libgcc_s.so.1

That, in turn, means that if g++11 (for example) is used as
a front end command for linking,

-Wl,-rpath=3D/usr/local/lib/gcc11

should be involved in the command as well.

An example of without and with ( lang/gcc12 context ):

# g++12 trivial.cpp
# ldd ./a.out
./a.out:
        libstdc++.so.6 =3D> /usr/local/lib/gcc12/libstdc++.so.6 =
(0x400000)
        libm.so.5 =3D> /lib/libm.so.5 (0x400000)
        libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x400000)
        libc.so.7 =3D> /lib/libc.so.7 (0x400000)
# ./a.out
ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by =
/usr/local/lib/gcc12/libstdc++.so.6 not found

vs.:

# g++12 -Wl,-rpath=3D/usr/local/lib/gcc12 trivial.cpp
# ldd ./a.out
./a.out:
        libstdc++.so.6 =3D> /usr/local/lib/gcc12/libstdc++.so.6 =
(0x400000)
        libm.so.5 =3D> /lib/libm.so.5 (0x400000)
        libgcc_s.so.1 =3D> /usr/local/lib/gcc12/libgcc_s.so.1 (0x400000)
        libc.so.7 =3D> /lib/libc.so.7 (0x400000)
# ./a.out
#

This means that the ports using libstdc++.so.6 need to deal
with getting the builds to have the required rpath(s) in place
for the g++* involved. (gcc* generated code can also end up
requiring such.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 16 08:03:23 2022
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 4MTRQg5j2cz4bsFZ
	for ; Fri, 16 Sep 2022 08:03:23 +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 4MTRQg4Rhkz3r3t
	for ; Fri, 16 Sep 2022 08:03:23 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4MTRQg3WFhzJ2j
	for ; Fri, 16 Sep 2022 08:03:23 +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 28G83NtN036539
	for ; Fri, 16 Sep 2022 08:03:23 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28G83NAS036538
	for freebsd-arm@FreeBSD.org; Fri, 16 Sep 2022 08:03:23 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 266037] reading xhci_devd  structure dynamically
Date: Fri, 16 Sep 2022 08:03:23 +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: 12.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: nitin.gupta981@gmail.com
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: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663315403;
	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=318qAlC5osTWUzz5VapcvTx1KTgOEg89+II8QBIxogk=;
	b=pEKJ+2PQWh8/AlYTJFAKi1PiIZ6OtF4Xtc5UAs6pFjvwIAxVd2FGNfFJ74lTgA6qdV5Ov5
	4TlXb0HGpJBC3wQvVkafiJK9A9v0T8Ei71Zoo2eFtK9t0nojnEyGF89a9tFqvjppCGaDPy
	UDaXoYZCrzqboGFqKSdXDjdsEmLtcqC8ioAxlqyl2935n5yQ/LHPfH80VLoFDDQ+BCkY5Z
	cRMk8jfn/29GoNBSzqbiQkOyzPPaf/Kb2lpK26PQuxdsbLKkMfzcJIhwOepYmuyPe6/Y5k
	7ADGijaFbv8BIWox3hcYtO/5pFUUW9F3eF/6//bg/7bBYW1Tt+U2uUW+Gf2qdw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663315403; a=rsa-sha256; cv=none;
	b=QF/l4ZPDu/xtKhvejNH8bgc4qxsakWS+RWvbk4dhfA4Es7zmoTM47KPniMd0nFFHbqQa1R
	fUABTV4+rzMLzpwPdP4AsZnJzVg+K/ds7rz88AoDjfrEy3J1aZbQfqcSy0b784DlFA8lUL
	D9f+6qwcR18a0fTIEDD/4ZC3e9VQvioyw8p6tb2UjJRh6ItZb+VCZteuyj3wvtnyD9z44n
	UcFmr7h5mRBFHvENY770herTGQug5gfwoOkY7QnUfrpnOPpdGbz1DK8oN26w4DxDfN8B3l
	p9b858JuZo4fcD9pJP092ZR7REu5fyq28n5dCqeRNUYl0/OsBeVqMiBEu4L2Gg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266037

Nitin  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |FIXED

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Sep 17 16:09:10 2022
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 4MVG8q2w2dz2kwBQ
	for ; Sat, 17 Sep 2022 16:09:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MVG8p1K1pz3Scp
	for ; Sat, 17 Sep 2022 16:09:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663430951; bh=HU28ZmlrtanvBHv1X+dhwZ+Uhc4+ac1tJZP7eR+vaes=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=l+WBSe7Lw18VqXoz65b5/CxsAvyNlpnge+Ihmy+9CYZvCQ43dOES4Fc6DvcG/Up+5BZv+YQVUqFpXiXNExoIzHJ4fiAUedIoz00rONCYF7+ObJLV/CySM64IKNLN6ClyFUbsiEEjRe4jA6KXi+0XF92OOv+Zw1uS6TF13foL+FR8MVzJULNF+jV8FuNljqMj3gP0oUtKihiVxNX91I+oP9bCfXe5wojNDUjmWsVw6ptk9KoN7PNoYIYgZJn7D8xit1rpGC9s/b7xSRkgr5NsdP8HLNjr0A8kA5CrfCKPFCIdEeWbSGEOKTUUu0qDUOunU/APpEhJW8Nplhk6yX27Aw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663430951; bh=Fe0mCX4OZ61iSgg8G8WzTxu9Cns9mtVdNhV1tIRFW7o=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TckZ4nsaR5GDvXz9FBOPsK26hp0jrDD6By6nBpyz6FoRsO2AxuyP2cFm77JdnnL8UzmMIAFRwHG4Z1kmdaVMUDUs6uQ9+tNYKhBjkxaEh0m82FMgHP5RcB8nvXSlyUkGZWJy1wn/4BtxsCPX0UVEBMjEEbM/C0yncyVTvZ7e3lRNoYxpay/ai9ReurhesR1fcB8s3b4tMIFvTdDh7bph7nV5L21IFDJ1xxBgH47w7DyvmD4wdzvI3/+udtxciCC+dkrowkLBd7ssP3QilUmIDyN0uruBnqEzOZe0wF6gS9aUbD03V/RKXn6GwFZrS1RzkpV7tDeCwQadbqCoSdUvJw==
X-YMail-OSG: J4Eae.gVM1kiIs.FgtK.zqBo.MwG7acLjN4Gpkjyy7dAeZv7TpZB0BzAmFwGueO
 vTdEEzFoNGV91HqJYsYK.kvL2g8URX7OrfibwX4CD97bAGVOLbFVgopFsq8IkeyuW1iUfPGsgg24
 EnxjsrfNc52WlKPWjMso3VCOleA1mM3.XbhwpRR3y.x_5Oin.wdChI_2Pp1Oo0FAQ_crNFdhfq3B
 SHjtcprI1Kd7YFnPRdoWJGgQI4Elt9.PR_tmo9XtBMrVTV2mYq81EWWa4pavZYHSt2Hz_5sP.iBP
 BwhKcmysv19FjQdc6WsnC4IDqgmbHfLEma3phwUuP.XAnXi74PxTYnheJlF1U54VVh8XMaqzWVay
 o54Qp24uQPUUyTI9HT5aYF9hIEkg00m99iis9y875a20Sgo5Y9R4GzaD6ergU5Ki.tKo1WhDD6Y5
 hd6FRi41DdfH57WZgdMgaQZ._nQ4VKhFk6sd1dohjOeyNcDqCMf7a6otUzeZ0VDU18p1sjpIN3He
 WWArLDWlMNYUG7yUIb1wm6028bQMCkgPLd.77Xx0t7EByTI5uQ48j.RP88ZSHKYsAlc9idO2msAK
 foVr4N.CT5dXaA3ZoWuX3J3PCSyxRuiBppn_nXL9PRev1FfDaOX2x26ajFEFQHl32baeAWRsGMEw
 UxEucXFOxjVWejr6w0_2pzKySvfXB8hzK8cYqAF1jpYwWE6tJNzakLiVTn18UW_vmRKfQet_miFt
 8kWz2_M2Wt_GiF5GuPMjCvf.VkQKOpJabIIMSdyWxU7cNXXKspj7_tDvpzwQQy65q4_jyWTQS22c
 qOGVeNPzEnJg3F.KfYhqc7JjQyXdD9KptZFK8kj39_ouL_ogvc.UfwIJ58x1oVYp79L8CTo4wb_6
 6nGzmvniUFldXtFULuDXT6odd89XOoadxjf8jEXo70RWaBIKGCVbK6paBbviFNd97K146voW23dl
 IoRvK3wyt71KgV2qOIQOS_1kEeaEFxzjWeVt2qpnIwDYoGYMWCo2Gld8Al_M00QnJWU6ivsjriD_
 ILr9nzz.0akxpq_REmPsimPTpkxN7dh7DJ3pbOjma_6uMfNbe1wEX_mhQ5giV6htCymX7vHVP6Lk
 txQPu8zsye4Wl34QEpo23jt7p.bdeiVChRtbz.Chau260ob9L_B1udOPfeptVS1Y9Y9io3YtNnTy
 unBjLSUcVYqgzpKp4oPR8d592lsJfLWyfkwOo4x8Pc3SeJM3E9rcxJgV8dcVjzwiB1cDdcRsT_za
 omsNWrjAVYsfnFHjrS9Fj.nih33AExsP4iDCAfsE2Cbi9IyWZTCmpBg.gpvf1wt.l8l5RV150vFC
 4DxhQB8bV6ObV.se94B3jQdBPFjVrnBkk_veZTKmk.55zFhPPp1Pc._jpUVkIip4ICWiTaunWCMO
 .K2ZnNZMNEqx4ULQQiFeK3NMQ55nhogKam.92IAWkepHb8yJG3_DrlKDM8m0t86qcjplZbKr9PwQ
 wp6iF0nlaV_bdH4V_Tc9gnMrQnxK04FMpCGbBqIBtgsKmXHECD9NtGyJS8D.PnQslLrYgqzbRlVz
 QKwOOqGmlk_bdAJnTsJFjmpt8vSCYMYsGhPYmD4UfbRvHKOFFY5Ypxs_vP79Z3QGqKVMAqEfsw42
 O4cfSibxm_p2s4IIE0ZJgi4SeKsgKb90hPUI3tsvSIhvXQ0a0OXs_X9oFo9swwZbonFUh4B5VGVP
 hA.6.tCNq7fpe2KqLLG4KLR2mduJY98gtT6oxwJwW.6F0ADGdiIUNz8Njo9Ydy.pm6HlwRpXXEEk
 rRM9rUQIUbxy0Oa1m_dHCwg_P1QsIPU._468GxscAQVAzfFr_pG_x1TQxhLaFwINkAOMJ7im4E8q
 KP8G8FN5fhMEUYzo2bwxUviDHaIgdo8xp9gRVif1P7LYoBMRQaO.aYjjoYCqIbZE56W6eOCEmGvs
 1yalKax84vHOEjF5pqONvykN5TKcR2PwSSKvUJF2WMe5JLPUY1gxxcpg7uBhYymuVPBtinwQmbIo
 wuPQVHO1IOU9fXI0i4I_328uDFITSEhByJbOgPUIVRtJfY3Mha.BNhLnZcpKzjtmUK8Ko4Ep2BrX
 1majkWOSpEgo8LSx1WI3pq8rGCZnvV.xMCAaFgp2S6.LZDQkD5yLuDPl8pVixuDIEkkufowH_7V0
 sZs7uyRvHeUZvUZNOn88dhZC6i0WM_u_8p4BugVDav1ENS0o6KxsuD3uj8va0Gscxzt_.hCt1GOO
 ruMJ_e2Bg5.b_qmLXcqTxXeZJ9LmPJRepKJUpZUHhFEIBcuyoTcWsvkSq0lbzqqw-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Sep 2022 16:09:11 +0000
Received: by hermes--production-gq1-5499fdd576-49dgt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0c963d3e107db8075da25b378210d9d1;
          Sat, 17 Sep 2022 16:09:10 +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 14.0 \(3654.120.0.1.13\))
Subject: FYI: RPi4B's and such: VLI_SS_BULK_OUT_BUG quirk handling vs. VL805
 (linux example)
Message-Id: <34A55B2A-1351-4D9A-B5E1-536F32F5F559@yahoo.com>
Date: Sat, 17 Sep 2022 09:09:10 -0700
To: freebsd-arm 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <34A55B2A-1351-4D9A-B5E1-536F32F5F559.ref@yahoo.com>
X-Rspamd-Queue-Id: 4MVG8p1K1pz3Scp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=l+WBSe7L;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.28 / 15.00];
	NEURAL_HAM_LONG(-0.97)[-0.971];
	NEURAL_HAM_MEDIUM(-0.94)[-0.942];
	NEURAL_HAM_SHORT(-0.87)[-0.870];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

https://github.com/raspberrypi/linux/pull/5173 reports:

QUOTE
After several months back-and-forth with VIA, we have a candidate =
root-cause for #4844 and a suggested fix. My known-bad pendrive now gets =
written to endlessly without suffering data corruption.
END QUOTE

and:

QUOTE
usb: xhci: expand mitigations for VLI_SS_BULK_OUT_BUG quirk =E2=80=A6 =
c9e051a

The VL805 can cause data corruption if a SS Bulk OUT endpoint enters a
flow-control condition and there are TRBs in the transfer ring that are
not an integral size of wMaxPacket and the endpoint is behind one or =
more
hubs.

This is frequently the case encountered when FAT32 filesystems are
present on mass-storage devices with cluster sizes of 1 sector, and the
filesystem is being written to with an aggregate of small files.

The initial implementation of this quirk separated TRBs that didn't
adhere to this limitation into two - the first a multiple of wMaxPacket
and the second the 512-byte remainder - in an attempt to force TD
fragments to align with packet boundaries. This reduced the incidence
rate of data corruption but did not resolve it.

The fix as recommended by VIA is to disable bursts if this sequence of
TRBs can occur.

Limit turning off bursts to just USB mass-storage devices by searching
the device's configuration for an interface with a class type of
USB_CLASS_MASS_STORAGE.

Signed-off-by: Jonathan Bell 
END QUOTE

and the drivers/usb/host/xhci-mem.c change has the comments:


	/*
	 * VL805 errata - Bulk OUT bursts to superspeed mass-storage
	 * devices behind hub ports can cause data corruption with
	 * non-wMaxPacket-multiple transfers.
	 */
. . .

		/*
		 * Slight hack - look at interface altsetting 0, which
		 * should be the UMS bulk-only interface. If the class
		 * matches, then we disable out bursts for all OUT
		 * endpoints because endpoint assignments may change
		 * between alternate settings.
		 */

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Sep 18 06:05:40 2022
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 4MVck23l2rz4bypZ
	for ; Sun, 18 Sep 2022 06:05:46 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MVck14510z3Smt
	for ; Sun, 18 Sep 2022 06:05:45 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id C89B8260A4F;
	Sun, 18 Sep 2022 08:05:43 +0200 (CEST)
Message-ID: <6babc840-0efa-8e89-4273-1a835f06edb7@selasky.org>
Date: Sun, 18 Sep 2022 08:05:40 +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.2.2
Subject: Re: FYI: RPi4B's and such: VLI_SS_BULK_OUT_BUG quirk handling vs.
 VL805 (linux example)
Content-Language: en-US
To: Mark Millard , freebsd-arm 
References: <34A55B2A-1351-4D9A-B5E1-536F32F5F559.ref@yahoo.com>
 <34A55B2A-1351-4D9A-B5E1-536F32F5F559@yahoo.com>
From: Hans Petter Selasky 
In-Reply-To: <34A55B2A-1351-4D9A-B5E1-536F32F5F559@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MVck14510z3Smt
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.19 / 15.00];
	NEURAL_SPAM_SHORT(0.99)[0.991];
	NEURAL_HAM_LONG(-0.98)[-0.981];
	NEURAL_HAM_MEDIUM(-0.90)[-0.897];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/17/22 18:09, Mark Millard wrote:
> https://github.com/raspberrypi/linux/pull/5173 reports:
> 
> QUOTE
> After several months back-and-forth with VIA, we have a candidate root-cause for #4844 and a suggested fix. My known-bad pendrive now gets written to endlessly without suffering data corruption.
> END QUOTE
> 
> and:
> 
> QUOTE
> usb: xhci: expand mitigations for VLI_SS_BULK_OUT_BUG quirk … c9e051a
> 
> The VL805 can cause data corruption if a SS Bulk OUT endpoint enters a
> flow-control condition and there are TRBs in the transfer ring that are
> not an integral size of wMaxPacket and the endpoint is behind one or more
> hubs.
> 
> This is frequently the case encountered when FAT32 filesystems are
> present on mass-storage devices with cluster sizes of 1 sector, and the
> filesystem is being written to with an aggregate of small files.
> 
> The initial implementation of this quirk separated TRBs that didn't
> adhere to this limitation into two - the first a multiple of wMaxPacket
> and the second the 512-byte remainder - in an attempt to force TD
> fragments to align with packet boundaries. This reduced the incidence
> rate of data corruption but did not resolve it.
> 
> The fix as recommended by VIA is to disable bursts if this sequence of
> TRBs can occur.
> 
> Limit turning off bursts to just USB mass-storage devices by searching
> the device's configuration for an interface with a class type of
> USB_CLASS_MASS_STORAGE.
> 
> Signed-off-by: Jonathan Bell 
> END QUOTE
> 
> and the drivers/usb/host/xhci-mem.c change has the comments:
> 
> 
> 	/*
> 	 * VL805 errata - Bulk OUT bursts to superspeed mass-storage
> 	 * devices behind hub ports can cause data corruption with
> 	 * non-wMaxPacket-multiple transfers.
> 	 */
> . . .
> 
> 		/*
> 		 * Slight hack - look at interface altsetting 0, which
> 		 * should be the UMS bulk-only interface. If the class
> 		 * matches, then we disable out bursts for all OUT
> 		 * endpoints because endpoint assignments may change
> 		 * between alternate settings.
> 		 */
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

Hi,

It doesn't make sense that this only applies to USB mass storage 
devices. Doesn't it apply to all SuperSpeed USB BULK transfers?

What about other OS'es, do they also get a fix?

--HPS

From nobody Sun Sep 18 06:42:20 2022
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 4MVdXR3SHdz4c5nj
	for ; Sun, 18 Sep 2022 06:42:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4MVdXQ1TTMz3hJ8
	for ; Sun, 18 Sep 2022 06:42:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663483347; bh=Q28Gw2bYV5bu4qGL/YdFRDOtrxEFEA5thD5rHWE1qrI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=huGHmfTzgJ/EOJozC01cP2iGiW0jBsBjBm1Plv4mRAhSaw/KuxtFmB6CkL/9wSiB2CDi9gAFlL1EHPBd3oDIJiWWtYJm6S1AnluYhUJAhYb3/BiFYhQLVyDhk6GqP1i+cKCdhh168eoW0ZrdPnKMv9MerPrgUhwxWl+ZvqzhF51pftB+OrOWDFPMi6F5Gk+0v8stuFPce9O/Yz1kRUF8foYE2qLWZe4oyKarDiyiWfki3OhjrQaeUxWMQSEWPOmBAVLfngHW0jlbQUKHnRipbFVPt9PBeh6NGYFEOb008ckwA1S0zO62Tx5swhGw8dMnItRsZBxyew4jK6OESJv5Fg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663483347; bh=PNtLvggp7/hqNzRMOjwbTLZ+gC4BYVDsxXU8Kd4jwhg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KiLtqsojf0n2FvnCt94hf0GUwbdWRn4Y25aIjqSxvJ00ryMbLZrt0/zHrSDId03ScxRf331LW8qKv000XhzPDSqAmF+B/xsWsBWpHj9leslPp6voFDx4+878v+wMbY4JMOxFUtkKzwJdr+arouNN5LhOiCeqdM4zbnjTJT+XkC8d/cXLhcGndypN/PxPqNNo2l1VvwFZ4NxW9j3hd2RD6IZcd5ZG+Dm6ZMEVZ8Af7eX6e4PhMLWYsD7oTbTt6N05qrN/hi139K3l2hV9N3K/DIoCoHSAmWCuYySzsi5BhHf465pCGah1nLhepuJrkXZlu89jPlh30zPGPIAaFnQmeg==
X-YMail-OSG: fKEwLi8VM1kXYPy3gl38OsDI7XdX2OEfHADTJfvRMHK_lXYYjYrQaBIvAlaDBkS
 w8JPJ.tXlIPR0dDBUQ11Kavqr6o3sYEnwEiawp60FFh4IhwThizuFwKLthgHqoWtjGtGO7m4dGr.
 iUNWR3rznS7yEQKx6k3CjfdLm_ISKtjjeFVMvATcsUex9GBWTud3tHiQT3evJwsPcMP7LDs8h57Y
 X.oLLsNf5B8ZcX9EgHDTVAtvO5SDid5gk5SZs_ieMYIeaxN2obAkxKesPHddb4Mu97dfwuAMqBvn
 x0.wOcGdokG_7qKKdTnmMUFdm0VunDNFf1OmCcuLSiKFo9dhBdpqXw0VJ.BR3Vx2f6_w5Xb7o_Vo
 Xy9kidZDQnIIxNudAzhJrOUmxKCW.4enxDxb3rnTyn0b8M3SL8o0UF6VBMNzHp.rpaQBBQzeL.si
 ksfWRE2dagitSZv.zmMLgc4gV4dQ9Kzd7IWE4du04cFTI7_eYhzSHVLm0qWgHA4eo_oVJXtJGo.k
 NEHtWihaeeeazalvCeCcSNb7iuV3ZF2eciJ0HblMJP3FUnA2JD_0A5tKEi29_XVq1yikaWlXrNwh
 iKvEY2lml.NICqHK_.IyWx4m_WQZOOp3D0Mwvl7QK8oglPmZdhEclmzePvrVO4zekzkOshboMZ_Q
 QxSyKwwiAcTmdl1.Xz8X0C1IMMkWJF4Jl8Rv1Kfsb0scBqCH7XiO5jas_JvnaqAQb0YWe7g2KMRg
 TVo_gGZylPS1SgkgRmK1DW5WOh.oCvqIpgQE6Ay1Uua908lhvi.s6NvSho6up.QZrwOzVQ30LQgr
 7ax71Xg7dX0tcUU9Pfb.U.TRZ3yS.rUCexNi9g59pv4lBESfuh.zTu7Pbwcn_TqUI999dSgB0292
 jtRLnCWZySHSWXf_P9D8f6ybVzGMfsq21R3BrBto5BgB6wdcY9byZzSbbsxeTOZjzeAtbkxl4Bdw
 ldnmt2wPb.5S38h0u7doJkED5ItDaLi_gI4NGZb2r.HACmPt8j39UiRdQQcNJnq89Zp7.bJ2dV6q
 6O1wmzbR3hAb4E95UQsFQkKLrLK8AmHDeWt0ZNIYuY581kk6G4vWjcCWOFp5O4fFx_HflEnhOEE5
 hXX93PzsJ06wENSuczxB27AvjvSABvLjlE3wrPGRQ43xfAw4zOzd.S9FxLLwtRuSHSiRnTD3MhGQ
 sffpsPBUh19R_0ydhZhqdJeUWTpdB0dQNsv4XY.aex0E4GP6ldBH0kI9EAdEXZb1mEdHLR8LTLUi
 .iL0Me9jA0vD2oUU95eP4YNWr6Pm2toE6UEODPoqscdGgRSi8XlK4EeMZbBYILu03jT6NeEjHsum
 nGOKCk4zLnLroKRjAG6a9oE9fc7iJQULhpJG1QsmGgjsCpZgKTra0GownysNVKEqmog_qoNSmCw.
 FeLyOOSawL5YCFGdSCMpccLHZj5tOYTdJ2jvzMXsn1YuZVrTGKRnbTjjujaxBi41UbUo7LwJ0i9E
 me6OLItUgc3SfUucrxNEMpW.TqdkaDorgrvLf.9d1NorUGDiAEboe9eDH1OxwT9qRsUdMfb431XL
 iJdeWOCodfg82cOLVRlI7KGNguxbyf3Te4vO0bWs7t8et811n7u.IGoPNyB_8pPvrgD61ZGNt1Pk
 1JJjO6VoaMYqPeWgLt3lpavFmFU0.0Eyf_SPoBMT54WawsyIO38aDyE72xOWfden_e3AVbb3MHB1
 Xea2hnGoF6CENKHTBhYkbnYLBH.PqTxSU0LPEdKRzEG2APIV0JxPvCVAqtaKGt03oS40bDEfrTzm
 8USOKS1VwER4gxSH88X4eYwWMl9DMG0K3gi9xVNkz.UNPaRJqbLeYw1GuJgx0wRe_BPdiXrx4ZQG
 sXeYx4IKUKICJ0wQpdbI4NJ6W09jdDPJJwDNf0QDBWebOyGfSnlt1HwCAWFQhP2jNwWOv3SX6QvK
 f.qFat5kPJ6tM7h_1T0dPTYG7.m_z7aES0dI7qsf8SzaHzCXvGkKX45P4JELSGEWLfttRkRswzc2
 2ygZ5JrAsXX6kofww4B3cUgQzi660EWheSW9GA4FIHMFLQmH2LNFHfGgaHv3iz8SWkhQW1jNXmNq
 MbdE3MyNbcD1MUJu8gskTvVI3Pt74zW6KPso3h7MRyAKtS5Z.DmldmxDpdzaO31aPjmaKqx1LGwJ
 kBPmmYY0hS9BuhAb0ptlLg0uECWlXrTBQ9gCFfddjjbTymqlBJD.S0AleH6IN0sZZAMSsxKvi_qL
 eOwHjHnGZwaeZkPzJlEYJrDfF9gUKhi4LDieVjHZIcBFSZj8bhZdq_RqHDAdNM4t63vvFaqZieut
 TzQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Sep 2022 06:42:27 +0000
Received: by hermes--production-ne1-544744cc75-zkxbp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d56076e61afe2d1147e1c54fb6d71ff4;
          Sun, 18 Sep 2022 06:42:21 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: FYI: RPi4B's and such: VLI_SS_BULK_OUT_BUG quirk handling vs.
 VL805 (linux example)
From: Mark Millard 
In-Reply-To: <6babc840-0efa-8e89-4273-1a835f06edb7@selasky.org>
Date: Sat, 17 Sep 2022 23:42:20 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <34A55B2A-1351-4D9A-B5E1-536F32F5F559.ref@yahoo.com>
 <34A55B2A-1351-4D9A-B5E1-536F32F5F559@yahoo.com>
 <6babc840-0efa-8e89-4273-1a835f06edb7@selasky.org>
To: Hans Petter Selasky 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MVdXQ1TTMz3hJ8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=huGHmfTz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-1.07 / 15.00];
	NEURAL_SPAM_SHORT(1.00)[0.998];
	NEURAL_HAM_LONG(-0.92)[-0.922];
	NEURAL_HAM_MEDIUM(-0.64)[-0.643];
	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];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-17, at 23:05, Hans Petter Selasky  wrote:

> On 9/17/22 18:09, Mark Millard wrote:
>> https://github.com/raspberrypi/linux/pull/5173 reports:
>> QUOTE
>> After several months back-and-forth with VIA, we have a candidate =
root-cause for #4844 and a suggested fix. My known-bad pendrive now gets =
written to endlessly without suffering data corruption.
>> END QUOTE
>> and:
>> QUOTE
>> usb: xhci: expand mitigations for VLI_SS_BULK_OUT_BUG quirk =E2=80=A6 =
c9e051a
>> The VL805 can cause data corruption if a SS Bulk OUT endpoint enters =
a
>> flow-control condition and there are TRBs in the transfer ring that =
are
>> not an integral size of wMaxPacket and the endpoint is behind one or =
more
>> hubs.
>> This is frequently the case encountered when FAT32 filesystems are
>> present on mass-storage devices with cluster sizes of 1 sector, and =
the
>> filesystem is being written to with an aggregate of small files.
>> The initial implementation of this quirk separated TRBs that didn't
>> adhere to this limitation into two - the first a multiple of =
wMaxPacket
>> and the second the 512-byte remainder - in an attempt to force TD
>> fragments to align with packet boundaries. This reduced the incidence
>> rate of data corruption but did not resolve it.
>> The fix as recommended by VIA is to disable bursts if this sequence =
of
>> TRBs can occur.
>> Limit turning off bursts to just USB mass-storage devices by =
searching
>> the device's configuration for an interface with a class type of
>> USB_CLASS_MASS_STORAGE.
>> Signed-off-by: Jonathan Bell 
>> END QUOTE
>> and the drivers/usb/host/xhci-mem.c change has the comments:
>> 	/*
>> 	 * VL805 errata - Bulk OUT bursts to superspeed mass-storage
>> 	 * devices behind hub ports can cause data corruption with
>> 	 * non-wMaxPacket-multiple transfers.
>> 	 */
>> . . .
>> 		/*
>> 		 * Slight hack - look at interface altsetting 0, which
>> 		 * should be the UMS bulk-only interface. If the class
>> 		 * matches, then we disable out bursts for all OUT
>> 		 * endpoints because endpoint assignments may change
>> 		 * between alternate settings.
>> 		 */
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
> Hi,
>=20
> It doesn't make sense that this only applies to USB mass storage =
devices. Doesn't it apply to all SuperSpeed USB BULK transfers?

No clue.

> What about other OS'es, do they also get a fix?
>=20

I doubt that the raspberry pi folks will go around fixing non-linux
kernels directly. I do see evidence of the XHCI_VLI_SS_BULK_OUT_BUG
name existing in some other linux kernels and past adjustments by
them to track past changes by the raspberry pi folks.

However,

https://elixir.bootlin.com/linux/latest/A/ident/XHCI_VLI_SS_BULK_OUT_BUG

does not find the symbol so linux does not have it in general.

(I'd not known of renaming or the like.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Sep 18 21:00:07 2022
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 4MW0Z02TH6z4cDcS
	for ; Sun, 18 Sep 2022 21:00:08 +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 4MW0Z00b8mz3wdC
	for ; Sun, 18 Sep 2022 21:00:08 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MW0Yz4NDNz18fv
	for ; Sun, 18 Sep 2022 21:00:07 +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 28IL07j9052511
	for ; Sun, 18 Sep 2022 21:00:07 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28IL07oW052510
	for freebsd-arm@FreeBSD.org; Sun, 18 Sep 2022 21:00:07 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202209182100.28IL07oW052510@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, 18 Sep 2022 21:00:07 +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="16635348074.2EEB31d03.50743"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663534808;
	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=Er9phfdLC3csdOnZk0AILIRGuP3F3VU7QiHoyVPW5XQ=;
	b=e6pPVc8MZ/BoUO1uZALbNrC3QFTdyGZM+DkOH/oo109bMaXSJEz44Pyu6TlpqvZR/o2D+N
	by+O4evkmV/vRL5xMHRNwJ5bJkkoJUI2/P5VIcrJTiFk+Uz5EmkJ6SlvIlLTF11cPaLjsO
	IXrLIz5738JKXO/Jkg+1O+208NRGaSB1K4Xc+z/0+zXRkeufsRxc6ywT/+d2EJuIbfzOZW
	+R/M5AxCQYaoUg43/iwFyeV8rE91n9NgzzEyCoTGi4nL0ydSUg4bWRVtUZj5CXrj/VAy+3
	XMB3ZJtuBakrhYCJBydKHTM9lC4t3HXdf4NppM7o1TDrSJfXZML09VafsiuC9Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663534808; a=rsa-sha256; cv=none;
	b=TaO1aVXg4ZfVqM68biSI5qTwdTl8ASAavzod0PqNE6ZP7B7FnGm2TSMZzjwXXYT4jd/FFQ
	EeplCEgH1KifjSSJFg59+VrVTyBgl8+cXmvOMsAL7UpSk6X0ol6N412yHqZKZfR3GOo6wp
	YvjRwtCX397y8xb2oE8+eLaTNqeyRo9bn6f45auFFBwiBw0oBeHhZLWrEvKEqP4j7Quu5F
	oJV2Prw27rgN9ce7l4XGFQLLGoz4dCOyt4x6Ga6VZqPLfW2R3y9MzE0HRtxpZkGR99/fGm
	OZ+gGJesuYWIWzPyC4NUfGXtG3ipwz+OvIdX3nB9GOcM8K+EDDPOIRac0adAzA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16635348074.2EEB31d03.50743
Date: Sun, 18 Sep 2022 21:00:07 +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.

--16635348074.2EEB31d03.50743
Date: Sun, 18 Sep 2022 21:00:07 +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.


--16635348074.2EEB31d03.50743--

From nobody Mon Sep 19 22:15:53 2022
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 4MWfC35VNVz4d2FF
	for ; Mon, 19 Sep 2022 22:15:59 +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 4MWfC242tZz49MF
	for ; Mon, 19 Sep 2022 22:15:58 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28JMFstw034106
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 19 Sep 2022 15:15:54 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28JMFr9k034105;
	Mon, 19 Sep 2022 15:15:53 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 19 Sep 2022 15:15:53 -0700
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220919221553.GA33878@www.zefox.net>
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-Rspamd-Queue-Id: 4MWfC242tZz49MF
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Dealing with a Pi3B running stable-13, current as of today.

Root device is a USB hard drive on a powered hub, no microSD.

About half the time it boots hands-off via power cycling or
shutdown -r, other times it stops in u-boot reporting:

U-Boot 2022.04 (Sep 05 2022 - 16:28:34 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

This looks a bit strange, since u-boot was loaded from the USB disk....
Next:

MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: unknown device
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-b8-27-eb-ba-68-d5
Retrieving file: pxelinux.cfg/00000000
Retrieving file: pxelinux.cfg/0000000
Retrieving file: pxelinux.cfg/000000
Retrieving file: pxelinux.cfg/00000
Retrieving file: pxelinux.cfg/0000
Retrieving file: pxelinux.cfg/000
Retrieving file: pxelinux.cfg/00
Retrieving file: pxelinux.cfg/0
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
Retrieving file: pxelinux.cfg/default-arm-bcm283x
Retrieving file: pxelinux.cfg/default-arm
Retrieving file: pxelinux.cfg/default
Config file not found

At this point one can enumerate the USB devices:

U-Boot> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub 
  |
  +-2  Hub (480 Mb/s, 2mA)
    |
    +-3  Vendor specific (12 Mb/s, 90mA)
    |    FTDI FT232R USB UART AM00KE3E
    |  
    +-4  Vendor specific (480 Mb/s, 2mA)
    |  
    +-5  Hub (480 Mb/s, 100mA)
      |  GenesysLogic USB2.1 Hub 
      |
      +-6  Mass Storage (480 Mb/s, 500mA)
         
U-Boot> 

The obvious oddity is that clearly a mass storage device has
been found (indeed, u-boot was started from it) but u-boot
does not recognize it as the device to boot from. 

So far it appears that rebooting from multi-user via shutdown -r
works about half the time. If the disk isn't recognized, an immediate
reset command usually ends the same way. Simply waiting for 15-30
minutes before rebooting _usually_ results in successful disk 
discovery and boot. 

Can anyone suggest simple experiments that might shed light on
what's going on? The u-boot employed was compiled from ports
and system up to date at the time. The same type of disk on a
Pi4 running -current (no powered hub needed) boots without 
problems. 

Thanks for reading,

bob prohaska

From nobody Mon Sep 19 22:24:47 2022
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 4MWfPT2gsCz4d3Jv
	for ; Mon, 19 Sep 2022 22:25:01 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256)
	(Client CN "m5p.com", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWfPS2wyHz4BpG
	for ; Mon, 19 Sep 2022 22:25:00 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26])
	(authenticated bits=0)
	by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 28JMOl6o093199
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 19 Sep 2022 18:24:53 -0400 (EDT)
	(envelope-from george+freebsd@m5p.com)
Message-ID: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
Date: Mon, 19 Sep 2022 18:24:47 -0400
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:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: "freebsd-arm@freebsd.org" 
From: George Mitchell 
Subject: Where are the Raspberry Pis?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-0.0 required=10.0 tests=HELO_NO_DOMAIN,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com
X-Rspamd-Queue-Id: 4MWfPS2wyHz4BpG
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com
X-Spamd-Result: default: False [-2.29 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[m5p.com];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[freebsd]
X-ThisMailContainsUnwantedMimeParts: N

I'm as happy as a clam at high tide to see all the FreeBSD work going
into supporting Raspberry Pis of all sorts.  But at the moment, it
seems to be that there are no Raspberry Pis (of any model) to be found
at any of the usual sources in the U.S.  Am I missing something?  Does
anyone have a clue as to when they might reappear?  Thanks!  -- George

From nobody Tue Sep 20 00:26:08 2022
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 4MWj5R5p9Pz4cPFJ
	for ; Tue, 20 Sep 2022 00:26:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4MWj5Q5qvDz4JtH
	for ; Tue, 20 Sep 2022 00:26:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663633575; bh=+Mbk9AHxLeJlEvczBiWfcRPZ33JBOSYqWzHUTkLw0QA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=moI9dHydM6pTz5qcc+QFvBVYncvqoV3zxQvyqxMBNJ1942U/Gw5TQiXTVypUaXJkryANgfLBHeb23HuODN60e9nEKNg5WGufw2al8cyE9pVNewFpI4/3l5HEwQ3/aMKstVoRo4rnqMI3OXskR9ExJIPzhHTaTYfDJxRRDisxI/H+tA4vNsPqOyLjiAjqa+h0cXC3gDcS0EXS5BAVKsikjVymgeQdlXxDT0HjVhAAQ7v5YDDixdkDhYp05Why+KkDH4YOIwckUazTQ5sBKFzJKyJW81gr3P/WRffkbDIQJkXTmYv3GDSONkGfzIRlP1ZzQBhTFWX1c9nUT9L2XpobZg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663633575; bh=G6oiGiAFRlYEvFN+NpdypoAM3l6dU27zlz3WZeHq27x=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HTK8Q0nxVWmpII69fRsuE6h/oQ9qMx1/Q+AcSjCKUgHYpOTJjB9GK9bZVdEo0CWzeJoi4eVSLXovZCQ0CCNPDtIE3v/ItZnutMC6NAk0+9uRljUuLyqfKRV+EwXvOXjgjLmyB5enQbkKj6S/GvbPLhnw9CGYkVhyuNWQxmNXocHsPg46qODvMwmsQrg/+7dNxXm46sjT0APb0FX3QUdmrih4CwgSCHmIi6M/jrXujtXofchZKWMaKs8mmzUY4Zn6zGO+2k6HHTaq2wLwGT71QY1iDCokOVmaNbU76r8Accpvokb8FAGCSJ0pIfghvCwSXjAMUwgeh9i4HoAGKdkJhg==
X-YMail-OSG: 2apP_ZgVM1nuywx1syXfV1SYSEYMRGw7FAyEBFpoE4JhXgjEIjvdrOTZQeS7ZJt
 exVd2I1iiz4xZVhizEfW.PCCYPTQC0c5udTorwUtYWgzuWJb1mC8.HoAr9M7AOjDL0rr5Fr.v5mx
 xqc4d1zao78UuRnX.a_wAucxV1ubSpzWrOnEx_uqiOmzeWK4g.VHqmnmPA1cd2imroQvc1RjBy.V
 .KgYU1JfXnRyK5VM285lcii2Sct0FLE1O0LoBj4sZqD4k8EcPvqp0Iu1an.9cyUkGoNSQHEr8X6r
 xCqfXuwTMLzLlgh2eYk7KqeOJdomSSsKt7MWIYgrZ9ZlcJ_0sEM_AfuqJqmkNP_WnE5.DX2U0xgs
 aQNwB97EaSsjYYLI6ZXCnF0wswBLuNfCd4p_svYL59mrfFW0JFRDPwHvJeM7fBfGpmhT1NDAJOzb
 _j1vI_3xPfZYTlUw2a7BysFN3I.rA8hhiOll5C_WAEosjcGJmTYIdBfhNx41L01FDj2pfWYAf0X3
 mW5NUxFF74_BZDkX9gQRkoJ89G1hCEN8a9aXdQxT_vPIkX5voi4_p7Sn_VEbnpFyI_RorHeaX7_M
 702mS3j.FqNWOd8AvqXY7W7QAwyyoPtL4tAZUPee_lkIPmtc_Pz0F.qV8pt_MedwaVUmWX3D_r1R
 UOAHcVn7XMLKAeT_TbQN6QOR1DacNDggQODOKQxqnsBRwyDSb94VEtdHpjPtfkc0rn1EQ0ZLgyjM
 5paGRendvdkWbfXRgM4vPhnmYy8asoSia0WT6iwGlBbKd5_r9eFqL3KLJb_9dc05XrPH3UhtRrVf
 zvyBWLJu8RnIDZzRVBsLWUlfbJppwSOL9Bo7IXfPmT_sSjCwgkZaXSVIWSa4CELUWmmcbxWoVASZ
 OKStEO8PV11xLvPj0ps7njCV5bLOI00T8D0FuI.XDHi60IWO6sSo.JsCUa_0UnYCs6fO0KGirnL5
 x7Er3AlWDnbYXJdAuWS7T7G81fmYxy5Jo4_qUTTWk68eTty1Y.RwCv_ukX61_IfdkOZEd.vnMw1a
 zyLuCecO9wvufY1QtI.cYG8G0PlR6qsCzgdCtjyy4XOW632tq3TyQuOqle7_p8usbjhIhcO.gb.K
 kvyNV92IC53Y10J6fsa1rOXvxI63dbdQ30oziiNZEHrk.DZ8RT6wDwOspKDQE73EUze1KvwcspUT
 S735YipsrzooBK9HAyRunfnZ3K5UASDopdDVqt6BU6ineoGS3BM6ELB7Gw3rDFs8ubBp0atjHzX7
 3qGwdV6KP4R1vTRjcHn6v6Bu2SbkRwRss0jeQO9x_1Oa72p_41Y7QOJ8l8HJtXP5pqdgzHmkcd9d
 pxPzu69mSijwRE8fK.2SoH9GbxNVKM0LO.Ei6CTRoJLyxdH8UAFYGDB3tVFVmwaetHSGqp8KnaUr
 OX3lORla72zNsoQYnMuYGwmS4m3Fq_NNDmolgBArFSLC14SQVdEWwaI3bsByMIupYDr9I44l4q16
 1xkmUazX0bSdmuITthm6GjUYxgcdLXU32orSpvNl.ocaOZI5.vRb2ojZ6N0jYchEzQ8MDTsS78JV
 XcJFowWsCEb7sn.JYRJMGb.1TgVAM1Nhmjn6d7mgkiMBHPxdJoLf2y1M6opZmVtjBEGz3oFEXBOr
 4ZhT_ESrW0kZ8be2lJiRtNVc6LSVZL9hjF2C66KG5h9zj_szb9_C8VhzvxvHvSsueGQjneUdya70
 JCy8rYH4fcPiFo.SgJl.l9GJtUXUAw7930XJI8DT8rFPFqhrV9KF9lSDDR7DGy92KjM3sjwh4kas
 0pOCTFV_vxFuMseqK2qEPnq4KHWnqWqd9sveybwztYnX21RFgkQ0FFw5FxnKN5RBMd6VMb9.eKSg
 zur7GiS3Z7bFqL.ihRxvoHXPdqYRjrN7W.J4DrC3wBzVApQzq1kTOw1gDKxd4wXJegUkFVnlgpCn
 RIaqbUfxeBO6PXQi2NGbI_oUrOd6Mv48EtVtix2HYDC9LHFN3PI9e2anBRWvVAT7TRa2h_WbVzFH
 c5p.lM1IT7aiZ4THpx9WBb6q6baNMPoJKiVB7EhAdN1_YErAfCyzJZd24S1puoI0s5tSw3VxaG0S
 sYyk__12w8gSB3yGw0kzaEPEjzmt2g4rtQG18pgt4JFSMs8TjNrIbe1jOz84Kd_.BkWISxUQfExo
 1k1OKV8_VzAzbduAQpLHoEbDokgtQAEtJmNiR44Ca5.klsv7l8.5yeiT7FyjIBSMCdNNV8A6_piE
 YAOWK5RWFBwJzzD2vSaiKwgcxPeF8GpGoR4XQuy18Dhs34yUyKhOANjVA0x2ZCKIuPkGhzpEmWLx
 Q6WM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 Sep 2022 00:26:15 +0000
Received: by hermes--production-ne1-544744cc75-mbjj6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 494ae54db8e2e99bcb020b33f491467b;
          Tue, 20 Sep 2022 00: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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <20220919221553.GA33878@www.zefox.net>
Date: Mon, 19 Sep 2022 17:26:08 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MWj5Q5qvDz4JtH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=moI9dHyd;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	NEURAL_HAM_LONG(-0.99)[-0.995];
	NEURAL_HAM_MEDIUM(-0.95)[-0.953];
	NEURAL_HAM_SHORT(-0.94)[-0.943];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-19, at 15:15, bob prohaska  wrote:

> Dealing with a Pi3B running stable-13, current as of today.
>=20
> Root device is a USB hard drive on a powered hub, no microSD.
>=20
> About half the time it boots hands-off via power cycling or
> shutdown -r, other times it stops in u-boot reporting:
>=20
> U-Boot 2022.04 (Sep 05 2022 - 16:28:34 -0700)
>=20
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
>=20
> This looks a bit strange, since u-boot was loaded from the USB =
disk....

I have 2 directions for this . . .

#0:

U-Boot resets the bus, re-enumerates the  devices, etc. This
can time out or otherwise fail despite prior activity by the
RPi* firmware that managed to use the device.

My NVMe USB SSD media have such issues with RPI4B's, also
getting 0 found in U-Boot. This is why I build U-Boot using
the patch:

# more =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20=

--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
	ENV_DEVICE_SETTINGS \
	ENV_DFU_SETTINGS \
	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=3D2000\0" \
+	"usb_ready_retry=3D5\0" \
	BOOTENV
=20
=20

It may well be that the Samsung T7 Touch's are outside of the
USB specifications in some way that requires such. I can not
claim that U-Boot is wrong relative to the specifications. It
is just that the adjustment is needed for my media.

#1:

I'm unsure if this applies to more than RPi4B's and the like . . .

Booting an RPi* can have the clock speed(s) vary during booting
and this can mess up timeouts/waits/etc. during booting, timing
too early, for example. I use one of:

init_turbo=3D60 # or other sufficient number of seconds

or, if I'm always after turbo mode for general operation,

force_turbo=3D1

in config.txt to avoid the failure.

On the RPi4B's I have to boot based on both #0 and #1 being
in place. Either not being in place can lead to the 0 found
status.

A powered hub being involved adds complications not invovled
in my context.

> Next:
>=20
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
>=20
> Device 0: unknown device
> missing environment variable: pxeuuid
> Retrieving file: pxelinux.cfg/01-b8-27-eb-ba-68-d5
> Retrieving file: pxelinux.cfg/00000000
> Retrieving file: pxelinux.cfg/0000000
> Retrieving file: pxelinux.cfg/000000
> Retrieving file: pxelinux.cfg/00000
> Retrieving file: pxelinux.cfg/0000
> Retrieving file: pxelinux.cfg/000
> Retrieving file: pxelinux.cfg/00
> Retrieving file: pxelinux.cfg/0
> Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
> Retrieving file: pxelinux.cfg/default-arm-bcm283x
> Retrieving file: pxelinux.cfg/default-arm
> Retrieving file: pxelinux.cfg/default
> Config file not found
>=20
> At this point one can enumerate the USB devices:
>=20
> U-Boot> usb tree
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub=20
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00KE3E
>    | =20
>    +-4  Vendor specific (480 Mb/s, 2mA)
>    | =20
>    +-5  Hub (480 Mb/s, 100mA)
>      |  GenesysLogic USB2.1 Hub=20
>      |
>      +-6  Mass Storage (480 Mb/s, 500mA)
>=20
> U-Boot>=20
>=20
> The obvious oddity is that clearly a mass storage device has
> been found (indeed, u-boot was started from it) but u-boot
> does not recognize it as the device to boot from.=20

What the RPi* firmware does to get U-Boot in place is not
used by U-Boot for its activity. The RPi* firmware need
not work the same as U-Boot, allowing for differing results.

> So far it appears that rebooting from multi-user via shutdown -r
> works about half the time. If the disk isn't recognized, an immediate
> reset command usually ends the same way. Simply waiting for 15-30
> minutes before rebooting _usually_ results in successful disk=20
> discovery and boot.=20
>=20
> Can anyone suggest simple experiments that might shed light on
> what's going on? The u-boot employed was compiled from ports
> and system up to date at the time. The same type of disk on a
> Pi4 running -current (no powered hub needed) boots without=20
> problems.=20

I warn that my notes above are based on RPi4B activity, not
RPi3B use. Also, no power hub use is involved. How much
applies to your context is a valid question.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 20 02:31:50 2022
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 4MWltL6l2rz4ckW7
	for ; Tue, 20 Sep 2022 02:31:54 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MWltL2stMz3Dpd
	for ; Tue, 20 Sep 2022 02:31:54 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id 05EB75C048F
	for ; Mon, 19 Sep 2022 22:31:54 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute1.internal (MEProxy); Mon, 19 Sep 2022 22:31:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=
	1663641114; x=1663727514; bh=6rcEmrYsOagJOGItI6AmW5ZSIRyXZ03eaX7
	9dTQqywU=; b=fpIyEfrs2fby8o1sn3cXLWooanzQaUBP2m18mEccA8LGTWU79wr
	ZVoH13mL5wlL5igtKLcwrraT8lLZiC7beWuV/zC4UBg1xktz/mIJbS8kqpJEskm8
	Uo+3/CD9tLYbDYONnzhblIyyoiQGObh8Ro6/J6ni1DJJB/TVlOAHp8hOfZiH184Q
	LkdCXWpwaPI2FhsrHERGmzH10TlVVJI0wgkUARDHDh09bx1GjLLiCmm5g1YdhJfP
	9gMhOyGOoF+Xo1n+40+J5G+op9/F6/gXADznQSFEPQbBhCjpV5NLfCirdX22RYSg
	/2d/KepW8xm3Eqm5WmH6N0CKUF4qF+PkRxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663641114; x=
	1663727514; bh=6rcEmrYsOagJOGItI6AmW5ZSIRyXZ03eaX79dTQqywU=; b=a
	XxZNssI9rQ8RGsVH5HOqZAIteq0/KhPtVw4i6C2f63DUMvQYCMC4ZS3yBrKxY9LB
	4KNqnfhFMW5opTAPiQcQrSMBzwssVayRxcOImAHCP2nX0Bo5hHtnZoKXlkUgNE94
	alwhrsM0egKqmI8/ajuP9PcULhEBDevp1VnB9USSewfQsCIKL6FYRujimUfrOFVT
	+X9LTg8FdKXLUUjt9t6xBRXXVA4V7KLtqVZZx/pNm3Jgxwti6uajqhXAXM4nyKVg
	hw3JxYIzN1OAVMUvy+UacnNoo8Rqas3SK2HA7hqJ0+NaxW11xWBxnvyI3IXwcjXk
	rixGn7F4jd91pmXYI8mxw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedvkedgieduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd
    dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht
    vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff
    eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho
    ihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 19 Sep 2022 22:31:53 -0400 (EDT)
Date: Tue, 20 Sep 2022 03:31:50 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: following -current on rpi4 with zfs-on-root
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
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
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MWltL2stMz3Dpd
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=fpIyEfrs;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b="a XxZNss";
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-5.09 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	NEURAL_HAM_LONG(-0.90)[-0.904];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

In /usr/src/UPDATING, there's this concerning
zroot booting after buildworld kernel cycle:

+++++
2.) update the ZFS boot block on your boot drive

    The following example updates the ZFS boot block on the
    freebsd-boot partition of a GPT partitioned drive ada0:
    "gpart bootcode -p /boot/gptzfsboot -i $N ada0"
    The value $N will typically be 1 (if booting from BIOS) or 2 (if
    booting from EFI).
+++++

BIOS in a rpi4 context I read as u-boot. I thought it hands the boot process
over to bootaa64.efi, which I thought was efi. Is this correct?
Its initial boot screen shows u-boot. Is this bios or efi?

TIA,
-- 

From nobody Tue Sep 20 02:42:01 2022
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 4MWm641z4tz4clwL
	for ; Tue, 20 Sep 2022 02:42:04 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWm635Szpz3FpM
	for ; Tue, 20 Sep 2022 02:42:03 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.nyi.internal (Postfix) with ESMTP id 802185C0334
	for ; Mon, 19 Sep 2022 22:42:03 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute2.internal (MEProxy); Mon, 19 Sep 2022 22:42:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; t=1663641723; x=1663728123; bh=qN+1/Udddk
	XYxvbz36slq2TsK8C5wlMFIbKUkaxq3YQ=; b=Wntdhseh/lSxKjj48ebSzUxWj4
	AihGEUT6ypeI69cnH34yCfO+Tkits3M7CV3FHEqjI27jEyQ9qxrF/H6VnWKgnIot
	/hLJehZv3AFyXWs7XhFYHygESJ2Gozpd9iMHvN66UgG47Gp3QORI5EZ0SzAETbQU
	CGN+Xj8JBywCnTA0lftILKaW3GCfeop5680yWc+yPQq8TtpiFE8Z4L27BU34ZAQh
	7Md3ElKsGeRI5ISAE/sKNAeSSrHXTIykslF6ix/iO3q37aKC9U6bE2QwCbOrR545
	2TaFxLuDzUHs0XbWE9VU5+43TffjfQWZJVpsAKySa0YVulJgR8JG2WB7EGtA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1663641723; x=1663728123; bh=qN+1/UdddkXYxvbz36slq2TsK8C5
	wlMFIbKUkaxq3YQ=; b=xaJBCQV39I55+krJGfUHF8iAmpFw6l9E2Qcpj0kd24sb
	fwDg1Ny8FaNFz2d0osH/Ta92iWBkAN63GlQSuIv4hAF6mPNxlKe9uItLHQ1Y0ojj
	3QeaKY8Ho0xg7KogsXlIlhxxRibu2QuKkeVO89iCGEOgS9GlSmphFwUfNVorRcjt
	pl2EbIgAPpkoiYQv0S30+gMljC8wZ0Xtqteu5Od/FBPGCQQIUNwqMCPKxmsfz71+
	k6CojWzlliJ6qR1J9t6JyuvzY5fdM7dbfyVk6dc01MxTiSV0gUyyElAsuq/EnkPm
	PfszQFuPZABHG6WTRvYKTtsoyAz2iAepqJW1QSgeAQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedvkedgieefucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhephefhkeetkeffgfdtheetkedvkefggefhkefgvdetffduledtkeduvdeuve
    elleeunecuffhomhgrihhnpehrrghsphgsvghrrhihphhirdgtohhmnecuvehluhhsthgv
    rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 19 Sep 2022 22:42:03 -0400 (EDT)
Date: Tue, 20 Sep 2022 03:42:01 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Re: Where are the Raspberry Pis?
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.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; format=flowed
Content-Disposition: inline
In-Reply-To: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
X-Rspamd-Queue-Id: 4MWm635Szpz3FpM
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=Wntdhseh;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=xaJBCQV3;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.14 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	NEURAL_HAM_LONG(-0.95)[-0.952];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 19, 2022 at 06:24:47PM -0400, George Mitchell wrote:
>I'm as happy as a clam at high tide to see all the FreeBSD work going
>into supporting Raspberry Pis of all sorts.  But at the moment, it
>seems to be that there are no Raspberry Pis (of any model) to be found
>at any of the usual sources in the U.S.  Am I missing something?  Does
>anyone have a clue as to when they might reappear?  Thanks!  -- George

https://forums.raspberrypi.com/viewtopic.php?t=337568

-- 

From nobody Tue Sep 20 03:08:26 2022
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 4MWmhh16xFz4cppl
	for ; Tue, 20 Sep 2022 03:08:36 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256)
	(Client CN "m5p.com", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWmhg2d1tz3Hw3
	for ; Tue, 20 Sep 2022 03:08:35 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26])
	(authenticated bits=0)
	by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 28K38Qin094074
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 19 Sep 2022 23:08:33 -0400 (EDT)
	(envelope-from george+freebsd@m5p.com)
Message-ID: 
Date: Mon, 19 Sep 2022 23:08:26 -0400
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:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: Where are the Raspberry Pis?
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
 
From: George Mitchell 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=0.4 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A,
	SCC_BODY_URI_ONLY,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com
X-Rspamd-Queue-Id: 4MWmhg2d1tz3Hw3
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com
X-Spamd-Result: default: False [-2.19 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.95)[-0.951];
	NEURAL_HAM_LONG(-0.94)[-0.936];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	DMARC_NA(0.00)[m5p.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 9/19/22 22:42, void wrote:
> On Mon, Sep 19, 2022 at 06:24:47PM -0400, George Mitchell wrote:
>> I'm as happy as a clam at high tide to see all the FreeBSD work going
>> into supporting Raspberry Pis of all sorts.  But at the moment, it
>> seems to be that there are no Raspberry Pis (of any model) to be found
>> at any of the usual sources in the U.S.  Am I missing something?  Does
>> anyone have a clue as to when they might reappear?  Thanks!  -- George
> 
> https://forums.raspberrypi.com/viewtopic.php?t=337568
> 
Thanks for the link!                                    -- George

From nobody Tue Sep 20 03:17:50 2022
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 4MWmvb4jMwz4cr1M
	for ; Tue, 20 Sep 2022 03:18:03 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36])
	(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 4MWmvZ6P7Rz3LM3
	for ; Tue, 20 Sep 2022 03:18:02 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe36.google.com with SMTP id m66so1647205vsm.12
        for ; Mon, 19 Sep 2022 20:18:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=bfgO2I0sYgs2Uh8PdvN3ar6OmHaGYHd43tgcAcJEB+E=;
        b=YS0ZB9KBOngD/yclxgWkCOPylKWs7otVKhZpqno6FUUSmTSNI0EyWgwo5yTCTLMu2+
         mG59uUhpfzJQEMt2AUUTM952z7S/wCnaRgICZM3qGpTtigMuWXD8tBHMJKXrh6x8qs78
         4kK5YbFWWpBogIAZ8ZPXhxqILwUbqycFsMef4JhlInA3kYsIV0HAnirspIC6nOiP8XLd
         Gto+pgtDVFxU2eQMFteOhMZvqOShCxQSg7IhXFBHg34396s/NMuZwJWFPN6ggzSfsASW
         70YFZyHziDreYjPvsAJZ0p11GCIu0Qo8VHOVgMUA7bhOalh+gawVse50ArBELCDv1eoz
         8ktw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=bfgO2I0sYgs2Uh8PdvN3ar6OmHaGYHd43tgcAcJEB+E=;
        b=yWCLy92MwzwmXjAstrInsN6skYMAlBLyOZEgkz0hDCt1i4P3WoeX35y8Q0jGHfHM3f
         8c//KdUB3A3WPWeTA1uhV421rKu3LQvP5PAEw2iCKidwEtAsOXimF0TdQKU8e3BylsB/
         mfdHhwXyPu5vE+K6OpxtyTvYhpmdUQn9wVkvk+NLd/p9SEUP2jr3ysfLcXGfv3Hh2oAv
         Be9mg8mWYY4rrVmRA1Wg0ogKfCTrPYAs988QQHY8RXE5FJvNESAiHCmEFbMxFRfDuRbm
         5K9WdsqvAR4mWJEhk39c/CvZli3eqg2VhHXfxyRW/gwTiULMuw47OXHzcTyc7EJjvfwM
         X6ww==
X-Gm-Message-State: ACrzQf1rN0KMsdCCjZd++5aKV0DXhKN8+Mn5M1ltRVeloq76wB9OYMqd
	n/38vbH+LrCxTtPwEJHmc6blJ0m4qFarZM6DxXn8X/9FbT0=
X-Google-Smtp-Source: AMsMyM4Y3i0d1kSM4lRMMr6aIScPBdhEWUILxANydy5ZkQz8ZKjcYPQZ7NLCDM4Lf1HiGD/dz2o3Py459dHQyHTnclk=
X-Received: by 2002:a67:d28e:0:b0:398:2d88:65ef with SMTP id
 z14-20020a67d28e000000b003982d8865efmr6702689vsi.11.1663643881876; Mon, 19
 Sep 2022 20:18:01 -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: Mon, 19 Sep 2022 21:17:50 -0600
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
To: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000009cc3a005e9134673"
X-Rspamd-Queue-Id: 4MWmvZ6P7Rz3LM3
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=YS0ZB9KB;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.89 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.95)[-0.947];
	NEURAL_HAM_MEDIUM(-0.95)[-0.946];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e36:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009cc3a005e9134673
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 19, 2022, 8:31 PM void  wrote:

> Hi,
>
> In /usr/src/UPDATING, there's this concerning
> zroot booting after buildworld kernel cycle:
>
> +++++
> 2.) update the ZFS boot block on your boot drive
>
>     The following example updates the ZFS boot block on the
>     freebsd-boot partition of a GPT partitioned drive ada0:
>     "gpart bootcode -p /boot/gptzfsboot -i $N ada0"
>     The value $N will typically be 1 (if booting from BIOS) or 2 (if
>     booting from EFI).
>

ignore everything after 'or'.. it's bogus. Gptzfsboot is unused outside of
BIOS booting on x86. In this case BIOS is irrelevant to EFI.

+++++
>
> BIOS in a rpi4 context I read as u-boot. I thought it hands the boot
> process
> over to bootaa64.efi, which I thought was efi. Is this correct?
> Its initial boot screen shows u-boot. Is this bios or efi?
>

It's EFI and you need to update the file in the ESP (MSDOS).

Warner

TIA,
> --
>
>

--0000000000009cc3a005e9134673
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Sep 19, 2022, 8:31 PM void <void@f-m.fm> wrote:
Hi,



In /usr/src/UPDATING, there's this concerning

zroot booting after buildworld kernel cycle:



+++++

2.) update the ZFS boot block on your boot drive



=C2=A0 =C2=A0 The following example updates the ZFS boot block on the

=C2=A0 =C2=A0 freebsd-boot partition of a GPT partitioned drive ada0:

=C2=A0 =C2=A0 "gpart bootcode -p /boot/gptzfsboot -i $N ada0"

=C2=A0 =C2=A0 The value $N will typically be 1 (if booting from BIOS) or 2 =
(if

=C2=A0 =C2=A0 booting from EFI).

ignore everything after 'or'.. it&#=
39;s bogus. Gptzfsboot is unused outside of BIOS booting on x86. In this ca=
se BIOS is irrelevant to EFI.


+++++



BIOS in a rpi4 context I read as u-boot. I thought it hands the boot proces=
s

over to bootaa64.efi, which I thought was efi. Is this correct?

Its initial boot screen shows u-boot. Is this bios or efi?
=


It's EFI and =
you need to update the file in the ESP (MSDOS).

=

Warner


TIA,

-- 






--0000000000009cc3a005e9134673--

From nobody Tue Sep 20 03:48:42 2022
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 4MWnbC72yMz4cwNF
	for ; Tue, 20 Sep 2022 03:48:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 4MWnbC0q3Zz3P1l
	for ; Tue, 20 Sep 2022 03:48:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id h1so1695107vsr.11
        for ; Mon, 19 Sep 2022 20:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=vqA2tuiL8aQFPHwEOWnG5piTMu70UpnCFstBni/5GTY=;
        b=X/kq75ZJoz4VMMcpeRT4fRZgTapotm8dBfv68DNC8Y/3KbBIgCTslvTDP+SSFO8LEc
         2jxedXnnlcq21bnCVIemPkIP+c8lGG4gpEYrvI5/AwBUw5shaJbMSBEenrmnJNq5tlUO
         Wub/XAcFj4JuaM3rptYfmGE9ehLxW4K7UqS0uYGaTQMJeX0DePzqVAi3QXl5vRtFB3TP
         fPOhICbRQUYTdLWzUdPSrt0tCH6zQnblTdJurRJCUmFhG3BWfsCxzozf0RevRiSYVOUn
         AyoreIcTkkrGDeF3g1Uo/GwMujcuBrug4U9V3Qrx5+9RePmZeytJRNR0CCjNEIGHvwet
         CilA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=vqA2tuiL8aQFPHwEOWnG5piTMu70UpnCFstBni/5GTY=;
        b=JL+adxjcIxkYquJ9+8LzdD9FmnjaxY+UKFfj3tzlVwpz2RIU/CK7NwRjLmasyvIB5/
         dIDt1QBcako4GULmqRMeis5DAEF6rNCQSpbhghfPK9PlooiwycK0jaeTDJfi6k6esKrt
         gz5KW3uedMkbx9jTBMwxabGRT0CMzBYRFMgfKtfaF+4zGbSa6QkeZbvjrnkxLfWn/vna
         B7ZdkqZPHiYmE/cWxOC+ZYUptrGXm/Pa+QiJxbSdFRvlD+IyfiiamaIMUvbGXDuYxHQN
         CuQZ3vXPtwE1s0S0ntAiSXt7efZuvhYDJpXznKn0RZjGwiUiCidenBAebLwtOLBkr6/Y
         8DYA==
X-Gm-Message-State: ACrzQf3AlA1FxvOKOvh8ofTJOB4YYGRazgomvu/D9sLV0LXSAf4f1bAj
	pHb1KkJiYvBQu+j+mWiF7QhcRYOPWEnokQWUBahH1SMd7ATLQw==
X-Google-Smtp-Source: AMsMyM7Uww8W0iK45rHDW4l+BWH9nEsq9jvtHQ1/g7oF7ttMc++c+B+nV85V6s858S2lfSNw5RP8bz23TH8QsYSCn3E=
X-Received: by 2002:a67:fb8a:0:b0:398:9d72:bddf with SMTP id
 n10-20020a67fb8a000000b003989d72bddfmr7367717vsr.38.1663645733535; Mon, 19
 Sep 2022 20:48:53 -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: Mon, 19 Sep 2022 21:48:42 -0600
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
To: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000fadb8905e913b4ed"
X-Rspamd-Queue-Id: 4MWnbC0q3Zz3P1l
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="X/kq75ZJ";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.95 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.95)[-0.951];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000fadb8905e913b4ed
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 19, 2022 at 8:31 PM void  wrote:

> Hi,
>
> In /usr/src/UPDATING, there's this concerning
> zroot booting after buildworld kernel cycle:
>
> +++++
> 2.) update the ZFS boot block on your boot drive
>
>     The following example updates the ZFS boot block on the
>     freebsd-boot partition of a GPT partitioned drive ada0:
>     "gpart bootcode -p /boot/gptzfsboot -i $N ada0"
>     The value $N will typically be 1 (if booting from BIOS) or 2 (if
>     booting from EFI).
> +++++
>
> BIOS in a rpi4 context I read as u-boot. I thought it hands the boot
> process
> over to bootaa64.efi, which I thought was efi. Is this correct?
> Its initial boot screen shows u-boot. Is this bios or efi?
>

I've updated UPDATING in https://reviews.freebsd.org/D36629. Please review.

Warner


> TIA,
> --
>
>

--000000000000fadb8905e913b4ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Sep 19, 2022 at 8:31 PM void =
<void@f-m.fm> wrote:
Hi,



In /usr/src/UPDATING, there's this concerning

zroot booting after buildworld kernel cycle:



+++++

2.) update the ZFS boot block on your boot drive



=C2=A0 =C2=A0 The following example updates the ZFS boot block on the

=C2=A0 =C2=A0 freebsd-boot partition of a GPT partitioned drive ada0:

=C2=A0 =C2=A0 "gpart bootcode -p /boot/gptzfsboot -i $N ada0"

=C2=A0 =C2=A0 The value $N will typically be 1 (if booting from BIOS) or 2 =
(if

=C2=A0 =C2=A0 booting from EFI).

+++++



BIOS in a rpi4 context I read as u-boot. I thought it hands the boot proces=
s

over to bootaa64.efi, which I thought was efi. Is this correct?

Its initial boot screen shows u-boot. Is this bios or efi?
=


I've updated UPDATING in=C2=A0https://reviews.freebsd.org/D36629. Please re=
view.

Warner
=C2=A0

TIA,

-- 






--000000000000fadb8905e913b4ed--

From nobody Tue Sep 20 07:55:39 2022
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 4MWv4f2PHpz4cJKS
	for ; Tue, 20 Sep 2022 07:56:18 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130])
	(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 4MWv4d3V1yz3p0G
	for ; Tue, 20 Sep 2022 07:56:17 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: by mail-lf1-x130.google.com with SMTP id a8so2361165lff.13
        for ; Tue, 20 Sep 2022 00:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=ACIp92Tuqx2k7u7bwViiFiJTFQZ5l/rx7q6euPGU9Dg=;
        b=k3OMyzK2sT+DOGITd/DMB3lQcPE2qB8ucBZzQtS+Row3BCE7bEWHptPUh/41mBJy+w
         pyeHtcdJTgbnCFOB4f8BUxewytAEnZ3PVU6XJu0hc9qYJHd84agTYJs27cCq1erRQ1IG
         AWBIyT+xk+/Cvw5GsCSpBpQNe2nsQ3FlkaAF/wJl93SNgKbHZ3Ii/gBbdYeIJarYUcyn
         Xg5NLzSl8dBkf9+Gzkh1QeX5sNec/CUUPNMGSM4CAbN2X9Smqr/ARY9pamD/rftHWghv
         P3m4JX9zwXTApmZqrW0MGWDLXUUZ+YuJ4xNV4LfDqxlrSpO/dSZAyVYe7nKgSr9rXzdN
         65GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=ACIp92Tuqx2k7u7bwViiFiJTFQZ5l/rx7q6euPGU9Dg=;
        b=aksdLcLuu5UhwRDY7A+2Fq6p8NbEeije3EAgJn/uNx7y6JbKAqOo4iJqAkYJ3GPbU2
         dbjP9XlwctABSjo1JnDf9jbVBbpozO7qbQt/Foux1651RQUJE5At8lWqIcqgiFFn2PaF
         2pcFIxBIB9GPtF3/U7wKRKBHGaT+aKzJeqsuRo7Q66ud4NSEbN/4CaeVBK0SpWTHvN/8
         anGlWflhSixgXVyuAt3VN7tEj1zNFALlnRPn1YMyLTbDUnvT4cqCaxAHIgPkzQ2EdJ3+
         10CUta7o5SYBr39ABICB6qmEVAXhQveiON1UWNKe9CaFxv0KoX7VnEQNHVvdxG9E1PRq
         jd/A==
X-Gm-Message-State: ACrzQf0TWVZqF0bK35Upa3r9afXlyvMfqG/48DAch0uKqLR/hIVuqb8j
	Vlrybs0JzZC8WvNEVaRmWhR97ugu4NoC+r/keZRdccgNJCcrVNnK
X-Google-Smtp-Source: AMsMyM5cClu7qZEPv5fdTSWuhAyw7OOWQO6XfbZQEQn7ukRNMPwseCMbLY5quMoYhNkfo6BNcq79HMj774OrThC7Qcs=
X-Received: by 2002:a19:4918:0:b0:48c:e6a0:c8d8 with SMTP id
 w24-20020a194918000000b0048ce6a0c8d8mr7684566lfa.679.1663660575056; Tue, 20
 Sep 2022 00:56:15 -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: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
In-Reply-To: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
From: Odhiambo Washington 
Date: Tue, 20 Sep 2022 10:55:39 +0300
Message-ID: 
Subject: Re: Where are the Raspberry Pis?
To: George Mitchell 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000009a677705e9172983"
X-Rspamd-Queue-Id: 4MWv4d3V1yz3p0G
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=k3OMyzK2;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of odhiambo@gmail.com designates 2a00:1450:4864:20::130 as permitted sender) smtp.mailfrom=odhiambo@gmail.com
X-Spamd-Result: default: False [-2.95 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.99)[-0.988];
	NEURAL_HAM_LONG(-0.97)[-0.967];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::130:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009a677705e9172983
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 20, 2022 at 1:25 AM George Mitchell 
wrote:

> I'm as happy as a clam at high tide to see all the FreeBSD work going
> into supporting Raspberry Pis of all sorts.  But at the moment, it
> seems to be that there are no Raspberry Pis (of any model) to be found
> at any of the usual sources in the U.S.  Am I missing something?  Does
> anyone have a clue as to when they might reappear?  Thanks!  -- George
>

The first option is to start following this link:
https://rpilocator.com/?instock for notifications.
Another way is to keep a watch on microcentre.com which always have them
every Tuesday.
The third option, if you have a friend in Kenya, they can easily arrange to
buy and bring you one. The
dealer in Kenya has way so much stock and they are slow-moving.
The fourth option is to try your luck at
https://www.facebook.com/groups/375185217353448
The fifth option is to pray for the chip shortage to ease :-)

PS: If you want to consider buying from Kenya, you can also talk to me
privately.

--=20
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-)

--0000000000009a677705e9172983
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Sep 20, 2022 at 1:25 AM Georg=
e Mitchell <george+freebsd@m=
5p.com> wrote:
I'm as happy as a clam at high tide to see all the FreeBSD work g=
oing

into supporting Raspberry Pis of all sorts.=C2=A0 But at the moment, it

seems to be that there are no Raspberry Pis (of any model) to be found

at any of the usual sources in the U.S.=C2=A0 Am I missing something?=C2=A0=
 Does

anyone have a clue as to when they might reappear?=C2=A0 Thanks!=C2=A0 -- G=
eorge

The first option is to start foll=
owing this link:=C2=A0https://r=
pilocator.com/?instock for notifications.
Another way is to k=
eep a watch on microcentre.com which=
 always have them every Tuesday.
The third option, if you have a =
friend in Kenya, they can easily arrange to buy and bring you one. The
dealer in Kenya has way so much stock and they are slow-moving.
=

The fourth option is to try your luck at=C2=A0https://www.facebook.com/groups/3751852=
17353448
The fifth option is to pray for the chip shortage to=
 ease :-)

PS: If you want to consider buying from =
Kenya, you can also talk to me privately.

-- 
=

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0=
004/+254 7 2274 3223
"Oh, the cruf=
t.",=C2=A0egrep -v '^$|^.*#'=C2=A0=C2=AF\_(=E3=83=84)_/=C2=AF=C2=
=A0:-)


--0000000000009a677705e9172983--

From nobody Tue Sep 20 12:33:20 2022
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 4MX1DP1Q2Bz4d3T8
	for ; Tue, 20 Sep 2022 12:33:25 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MX1DN3HV3z3CL9
	for ; Tue, 20 Sep 2022 12:33:24 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
	by mailout.nyi.internal (Postfix) with ESMTP id 2329F5C00C2
	for ; Tue, 20 Sep 2022 08:33:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute3.internal (MEProxy); Tue, 20 Sep 2022 08:33:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; t=1663677203; x=1663763603; bh=Y2E4OX4Apm
	HNtAkFDgW+D7h2U1nD55+zNZc1ilEIUNU=; b=mqggmqbxL02LwM2/RWjPMctT/z
	aPqeD6scO+Xlubjx/Jm5YZFDJNyPo+c9UgLNlv9ynUTTACdNE7/TrCe/NCWsJF05
	y8Sh5GRIvsE30waXej/hV0troa1R74LcIlWQkWQYMvq18vnx63+v8VM3eDNB+EEj
	nIGy6nHaitjF2H8lzkDa/MbQLwL4pS9rLsepW/RXfW9tTDCAryicfkhYY3FnsEMl
	bkZXbLTtO8NK3VeEapIclgPPzJOm/rag1+h0TaRZN3lYGAEMp54QGWZViNCNyR7v
	89L5IEBwTFB70EvY6Os7Q30mWuCgS6zlgNkwoU6ZWSrPEtsGWbq/Kjom2qXQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1663677203; x=1663763603; bh=Y2E4OX4ApmHNtAkFDgW+D7h2U1nD
	55+zNZc1ilEIUNU=; b=cKCuoXYvm994q6PQl+k85xOvimPWuyynWFmK+XM2QDps
	dv+PYW5QmY+ZpIkNKteWqpEOOth/PNhvuCkKOs5237/zL2vhxUKEKfUD6Sr5mGUu
	sSvwgIZv3UJSsFQzoicCmmN5Kcuz9UB6fF8rYROv1suexQME3sIM01AL2liP8g9o
	sp0k5dNumd6tlQQwWhu9DoYoxVmenxkUwK9AuTOqU+XIIjZ3aEgAeZ+FXUmxVShT
	ZsarUtxexFks5rflfytkrqgs7J6pMjgjH7KFjjKNeUTWtNEkcGHcZKbHY+lRGIIF
	XOTDTqZpsKS4A3cWMxCjKV5iOWw1268eo/BfwCziYA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedvledgheegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnheptdfhheeuteejudffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuie
    eltdeinecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Tue, 20 Sep 2022 08:33:22 -0400 (EDT)
Date: Tue, 20 Sep 2022 13:33:20 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Re: following -current on rpi4 with zfs-on-root
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: 
 
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
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MX1DN3HV3z3CL9
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=mqggmqbx;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=cKCuoXYv;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.99 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	NEURAL_HAM_LONG(-0.96)[-0.963];
	NEURAL_HAM_MEDIUM(-0.93)[-0.931];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 19, 2022 at 09:48:42PM -0600, Warner Losh wrote:

>I've updated UPDATING in https://reviews.freebsd.org/D36629. Please review.

> For EFI, there are many choices. The default installation places
> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
> updates it (assuming the ESP is on p1, and isn't already mounted):
> mount -t msdos /dev/ada0p1 /boot/efi
> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
> If you have a non-standard setup, please see the EFI notes section.

My non-expert opinion:

1. ideally there should be an indication in what circumstances
    the above is required, because it might not be possible to infer
    for the non-expert (with regards to the above) user  
     
2. if it needs to happen, where in the buildworld/kernel/install/
    etcupdate/reboot sequence is it required? I would guess after
    etcupdate and before reboot, but guessing isn't the same as knowing.
    It would be great if this was in the Source of Truth(tm).

thanks,
-- 

From nobody Tue Sep 20 14:24:58 2022
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 4MX3jJ2hYsz4cN5M
	for ; Tue, 20 Sep 2022 14:25:08 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256)
	(Client CN "m5p.com", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MX3jH53Bdz3clV
	for ; Tue, 20 Sep 2022 14:25:07 +0000 (UTC)
	(envelope-from george+freebsd@m5p.com)
Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26])
	(authenticated bits=0)
	by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 28KEOwgK096849
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Tue, 20 Sep 2022 10:25:04 -0400 (EDT)
	(envelope-from george+freebsd@m5p.com)
Message-ID: <1785604b-faf3-e286-df12-ac744823ebc9@m5p.com>
Date: Tue, 20 Sep 2022 10:24:58 -0400
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:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: Where are the Raspberry Pis?
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
 
From: George Mitchell 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com
X-Rspamd-Queue-Id: 4MX3jH53Bdz3clV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com
X-Spamd-Result: default: False [-1.20 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	DMARC_NA(0.00)[m5p.com];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_FROM(0.00)[freebsd];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

T24gOS8yMC8yMiAwMzo1NSwgT2RoaWFtYm8gV2FzaGluZ3RvbiB3cm90ZToNCj4gDQo+IA0K
PiBbLi4uXQ0KPiBUaGUgdGhpcmQgb3B0aW9uLCBpZiB5b3UgaGF2ZSBhIGZyaWVuZCBpbiBL
ZW55YSwgdGhleSBjYW4gZWFzaWx5IGFycmFuZ2UgDQo+IHRvIGJ1eSBhbmQgYnJpbmcgeW91
IG9uZS4gVGhlDQo+IGRlYWxlciBpbiBLZW55YSBoYXMgd2F5IHNvIG11Y2ggc3RvY2sgYW5k
IHRoZXkgYXJlIHNsb3ctbW92aW5nLg0KPiBbLi4uXQ0KPiANCj4gUFM6IElmIHlvdSB3YW50
IHRvIGNvbnNpZGVyIGJ1eWluZyBmcm9tIEtlbnlhLCB5b3UgY2FuIGFsc28gdGFsayB0byBt
ZSANCj4gcHJpdmF0ZWx5Lg0KPiBbLi4uXQ0KRm9yIG5vdywgSSB0aGluayBJIGNhbiBydWxl
IG91dCB0aGUgdGhpcmQgb3B0aW9uIC0tIGJ1dCB0aGFua3MhDQotLSBHZW9yZ2UNCg==

From nobody Tue Sep 20 16:28:59 2022
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 4MX6SW34Rwz4ckZb
	for ; Tue, 20 Sep 2022 16:29:15 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(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 "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MX6ST52fMz3p8x
	for ; Tue, 20 Sep 2022 16:29:13 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from [IPV6:2001:678:618:c1::2] (mzar@[IPv6:2001:678:618:c1:0:0:0:2])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 28KGT1pA071438
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
	for ; Tue, 20 Sep 2022 18:29:01 +0200 (CEST)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1663691341;
	bh=bLdY1CTEpi7JrJ+NlyOPmDwDgD+ODfbJ45lr2/ats9M=;
	h=Date:To:References:From:Subject:In-Reply-To;
	b=aJQ/jVQnBon7N3MPYT20ANKWX+KinVJyXUMXWqtlnUluPx8un9hMMNRS4pLh50LKQ
	 pa2WLGbO7BkNPA7BzDHigMoQiIbwT1Gi/cAyG17iP3jQa/Gr/q02B/7znXvepBGovN
	 2CGJAaHZ3FWXDAYo0SV7Y2ckcjtcMhM/bO0UPE49pYmgt+aGTDoUCvhzOWxsfIBPbG
	 cLZqH9SmFRAvh+vYTU1ybNCDzx+L+Qolk0W8kfSbwrxNZ4qTjomHrMGD6wxKcusinj
	 hI3N3UL9jikioHsXrT2hZt9FEvDQQdgHyGPlWBORWo1TsvtdtDq6tAeye9C42rS9D3
	 ZcD6XEG1Rv3ww==
X-Authentication-Warning: plan-b.pwste.edu.pl: Host mzar@[IPv6:2001:678:618:c1:0:0:0:2] claimed to be [IPV6:2001:678:618:c1::2]
Message-ID: 
Date: Tue, 20 Sep 2022 18:28:59 +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:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
To: freebsd-arm@freebsd.org
References: 
 
 
From: Marek Zarychta 
Subject: Re: following -current on rpi4 with zfs-on-root
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------1XxJP0BvNDiU2i678Q1D081t"
X-Rspamd-Queue-Id: 4MX6ST52fMz3p8x
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b="aJQ/jVQn";
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl
X-Spamd-Result: default: False [-5.80 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	MIME_BASE64_TEXT(0.10)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	HAS_XAW(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------1XxJP0BvNDiU2i678Q1D081t
Content-Type: multipart/mixed; boundary="------------L0lRilM7VzN08zuYxBUMNpFB";
 protected-headers="v1"
From: Marek Zarychta 
To: freebsd-arm@freebsd.org
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
References: 
 
 
In-Reply-To: 

--------------L0lRilM7VzN08zuYxBUMNpFB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VyBkbml1IDIwLjA5LjIwMjIgb8KgMTQ6MzMsIHZvaWQgcGlzemU6DQo+IE9uIE1vbiwgU2Vw
IDE5LCAyMDIyIGF0IDA5OjQ4OjQyUE0gLTA2MDAsIFdhcm5lciBMb3NoIHdyb3RlOg0KPiAN
Cj4+IEkndmUgdXBkYXRlZCBVUERBVElORyBpbiBodHRwczovL3Jldmlld3MuZnJlZWJzZC5v
cmcvRDM2NjI5LiBQbGVhc2UgDQo+PiByZXZpZXcuDQo+IA0KPj4gRm9yIEVGSSwgdGhlcmUg
YXJlIG1hbnkgY2hvaWNlcy4gVGhlIGRlZmF1bHQgaW5zdGFsbGF0aW9uIHBsYWNlcw0KPj4g
bG9hZGVyLmVmaSBpbnRvIHRoZSBFU1AgaW4gRUZJXEZSRUVCU0RcTE9BREVSLkVGSS4gVGhl
IGZvbGxvd2luZw0KPj4gdXBkYXRlcyBpdCAoYXNzdW1pbmcgdGhlIEVTUCBpcyBvbiBwMSwg
YW5kIGlzbid0IGFscmVhZHkgbW91bnRlZCk6DQo+PiBtb3VudCAtdCBtc2RvcyAvZGV2L2Fk
YTBwMSAvYm9vdC9lZmkNCj4+IGNwIC9ib290L2VmaS9sb2FkZXIuZWZpIC9ib290L2VmaS9l
ZmkvZnJlZWJzZA0KPj4gSWYgeW91IGhhdmUgYSBub24tc3RhbmRhcmQgc2V0dXAsIHBsZWFz
ZSBzZWUgdGhlIEVGSSBub3RlcyBzZWN0aW9uLg0KPiANCj4gTXkgbm9uLWV4cGVydCBvcGlu
aW9uOg0KPiANCj4gMS4gaWRlYWxseSB0aGVyZSBzaG91bGQgYmUgYW4gaW5kaWNhdGlvbiBp
biB3aGF0IGNpcmN1bXN0YW5jZXMNCj4gIMKgwqAgdGhlIGFib3ZlIGlzIHJlcXVpcmVkLCBi
ZWNhdXNlIGl0IG1pZ2h0IG5vdCBiZSBwb3NzaWJsZSB0byBpbmZlcg0KPiAgwqDCoCBmb3Ig
dGhlIG5vbi1leHBlcnQgKHdpdGggcmVnYXJkcyB0byB0aGUgYWJvdmUpIHVzZXIgDQoNCldo
aWxlIGZvbGxvd2luZyBDVVJSRU5UIGJyYW5jaCwgdXBkYXRlcyBvZiB0aGUgRVNQIGxvYWRl
ciBoYXZlIHRvIGJlIA0KZG9uZSBxdWl0ZSBvZnRlbi4gRm9yIFNUQUJMRSBicmFuY2hlcywg
aXQgbWlnaHQgbm90IGJlIHJlcXVpcmVkIGF0IGFsbCANCmZvciB0aGUgd2hvbGUgbGlmZWN5
Y2xlLiBSZWFkaW5nIFVQREFUSU5HIGFuZCBjb21taXQgbWVzc2FnZXMgY291bGQgaGVscC4N
Cg0KPiAyLiBpZiBpdCBuZWVkcyB0byBoYXBwZW4sIHdoZXJlIGluIHRoZSBidWlsZHdvcmxk
L2tlcm5lbC9pbnN0YWxsLw0KPiAgwqDCoCBldGN1cGRhdGUvcmVib290IHNlcXVlbmNlIGlz
IGl0IHJlcXVpcmVkPyBJIHdvdWxkIGd1ZXNzIGFmdGVyDQo+ICDCoMKgIGV0Y3VwZGF0ZSBh
bmQgYmVmb3JlIHJlYm9vdCwgYnV0IGd1ZXNzaW5nIGlzbid0IHRoZSBzYW1lIGFzIGtub3dp
bmcuDQo+ICDCoMKgIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoaXMgd2FzIGluIHRoZSBTb3Vy
Y2Ugb2YgVHJ1dGgodG0pLg0KPiANCg0KVGhlcmUgaXMgbm8gb2ZmaWNpYWwgSE9XVE8gdXBn
cmFkZSBmb3IgYXJtNjQgb24gWkZTLiBVcGdyYWRpbmcgZnJvbSANCnNvdXJjZXMgaXMgYSBw
cmV0dHkgc3RyYWlnaHRmb3J3YXJkIGFuZCBzdGFuZGFyZCBwcm9jZWR1cmUgZGVzY3JpYmVk
IGluIA0KdGhlIGhhbmRib29rWzFdLiBVc3VhbGx5LCBzdWNoIGFuIHVwZ3JhZGUgaXMgZG9u
ZSBub3QgaW4tcGxhY2UsIGJ1dCBieSANCmNyb3NzLWJ1aWxkaW5nIGFuZCBjcm9zcy1pbnN0
YWxpbmcgb24gYW1kNjQgbWFjaGluZSwgc28gcmVib290aW5nIGlzIG5vdCANCnJlcXVpcmVk
Lg0KDQpUbyB1cGdyYWRlIHRoZSBsb2FkZXIsIHlvdSBuZWVkIHRvIGNvcHkgX25ld2x5XyBi
dWlsdCBmaWxlIA0KL2Jvb3QvbG9hZGVyX2x1YS5lZmkgdG8gRUZJL0JPT1QvYm9vdGFhNjQu
ZWZpIG9uIEVTUCBwYXJ0aXRpb24uIFNvIA0KdXBncmFkaW5nIGxvYWRlciBvbiBFU1AgcGFy
dGl0aW9uIGNhbiBiZSBwZXJmb3JtZWQgbm8gZWFybGllciB0aGFuIGFmdGVyIA0KY29tcGxl
dGluZyBpbnN0YWxsd29ybGQsIHdoaWNoIGlzIHRvbyBsYXRlIGlmIHlvdSBhcmUgZ29pbmcg
dG8gc3RyaWN0bHkgDQpmb2xsb3dbMV0gYW5kIHJlYm9vdCBiZXR3ZWVuIGluc3RhbGxrZXJu
ZWwgYW5kIGluc3RhbGx3b3JsZCBzdGVwcy4gSWYgDQp5b3UgYXJlIGdvaW5nIHRvIGZvbGxv
dyB0aGUgaGFuZGJvb2ssIHlvdSBjYW4gZmluZCBpbiB0aGUgT0JKRElSIGZyZXNobHkgDQpi
dWlsdCBsb2FkZXIgDQooL3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3N0YW5kL2Vm
aS9sb2FkZXJfbHVhL2xvYWRlcl9sdWEuZWZpKSBhbmQgDQpjb3B5IGl0IHRvIHRoZSBFU1Ag
cHJpb3IgdG8gcmVib290aW5nIGFzIGRlc2NyaWJlZCBpbiByZXZpZXcgRDM2NjI5WzJdLg0K
DQoNClsxXSBodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svY3V0
dGluZy1lZGdlLyNtYWtld29ybGQNClsyXSBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcv
RDM2NjI5DQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg==

--------------L0lRilM7VzN08zuYxBUMNpFB--

--------------1XxJP0BvNDiU2i678Q1D081t
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmMp6kwFAwAAAAAACgkQHZW8vIFppoKg
HQgAl9jvj8jQoWNOqGN1ZQd1A6Wyvo7VV+yg2qxG1WemQ+Z16u+5C5CIEqBF3+I3OqmlmWTP5d6q
eYANVmH3tvFPEHxZoC1f1B06/AZul4E9B8aav66mqu5W/H/eenTXazVZWX6kdCFVUQyR6WKjr5e2
yv2+a3dYKJnSHWnNJPIdjhF+pB+LEzbGRhI3nP9upPaf2INYk7j4g3UjLK5vu84OjzjSCXezqcy3
yYO2ILgKdw7V8XkSLWCSHMK8c+6PJR3HQadqU6/9Nwl+D068ZYxGl8K6yXQQOTgNA9c3UvxdI/ft
9pTBTE1X6Lb2TGoJkyQaiknshiqWIIGowaFor1N+yA==
=b0Vd
-----END PGP SIGNATURE-----

--------------1XxJP0BvNDiU2i678Q1D081t--

From nobody Tue Sep 20 17:37:41 2022
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 4MX7zh285Wz4cw90
	for ; Tue, 20 Sep 2022 17:37:52 +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 4MX7zg0V4Bz3tdD
	for ; Tue, 20 Sep 2022 17:37:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663695468; bh=UpnRMJncpA7rcRp2/Cx2a2WsYqCF+KnlOjUs/8un8zw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jnH9jfit1m9YmLg/ZXuqIHnYG6HNSC2KLZSpM8x5zv6+sZyr2LLTHjWxIh+H9y3VwzRWzO3PHt8YV/zWfdz5oPbwbRG5tQmS7g/tl1Yyf04bLmaFZwft+nGQsZwRvPYEL2R9WGSAJ2nrVaT2GQzuNXy9dIHTHDi0ZxW/NeTCYOiZ5JPAhb/SMNmiY7fyB+wJK2rQ36v6PCcI9qgfLQXSyDh/C0IwR1f98X3FehScSEkqSs3s9hAbc4+CK+yDN03OW+6AHohyLOReLLYcgOiXDGCitVaKlvcPEm3ngVtQPPkEi4GuZwVGRV8MbNKswTeCtAlvKYdsTV+KlFVXa+cARA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663695468; bh=0H0x1zzl7pNVhIYNM31jU0pjiiBVVkKMnojZlo+J13M=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rIW/Hj0m5zsG9SVybzAWN3cj8cFKjqt7EqqpAazN7HQ8VksnH++YdNfDZchb0tZT/lKJDM8aXEn97vAd6RUVDQ+BKbk90hp1bD78Q7BhgL6PknhBAuaWcki89Mt4m5S4QokvvY3HjqimeE4R63FH8WyXqcQb5vPSBsDNIJjFoh5gJB+uJfVQsY+GxyQleh3twESYR1Vm1IMEJn8k3K+u8zAq7C8E0hJoegkB0awS8J4TnlMIH6ZSUOKPf0V0x/cplJkBD5Rqj3ZVYc2xkUJoPg8TrNsn2kadRS2Wnqe/wjKPvBivKavNlq6ZUVnVFFaNO2gHPlXDkxYaN7oZ61bu2Q==
X-YMail-OSG: pI99R64VM1lcVxcdE9HhIHL_cKNFnxjWVG9cRlGjP0TbYZ9q9VHiZ1gSBrFFMNC
 seBOcr8LHGcQ7bkXOkizB3it38wFLuI1LJKVfCiM0iEoyuHQoW1U497k_C87aM4vnf8LFz4N2xa0
 i4EO3arg7Egg6ZyJtO8tmJR_ci1euoY2_QAEPUKTeLbtFhymZKMS2p2N3MX5RRdwnhCaN1AlmmzW
 f2lJotycL3FH0Zusddqu4Wd6dOFQbOgXBYSPBiaivzAkHLvgtmc48tY4qX.GDlbAaw0CIAjKi9Ly
 5Qg2tdgE.D.zo3nza3tlfar5VyvuzPM0yc9TajOfzkSFBsguiwvtefNj1oaYlYqBsLmaJuihYZvv
 FeWk5w200W_JS7W_izcrEMxAiFr2aABnUEicAwFmR8I5unodsSJwJKw3YeGHUOqkW8YISYyN2.mQ
 kF2KmIupQ9aDuP3kP8tkySzP_uenzGzlzPoH5ux_wwP9BjtYhUZugLOpwvydbPaaWbS7eUjsaDT1
 BRntveYPdBPh.D5DxlcAKvPezPyxsKuefYc69mrinLegAcliySo6OeM7zlAGle1v2ceLnzHXN6XW
 oJyJZlkDl_Ohbw1CkVqs38VqaLHDcWDCiyXWdFbrZIESgBAxaG8REJjRLR8J.aArD5cF.VQwFhjw
 Iwrv9FT1xuozrNTXvgBd_ySIKZt51gEjDrFjSKPrhEQn8GtIQ_sq5HzQrXCKGUmF73NuWRrqnjI8
 utKfyBhqr3aXVEelcBC1sr17Z5VoVEW7HU5SSz0wfiToaxK7ziIu1izRfVNHxXtELkEb1N0EW2ee
 DBKNyuLNOqYO_ZnorhQqXYUVmhw_AP_ruoPfzpcm0Avw0gzicZygnkbLaBcF7wTCsxVuEyFB2R9A
 u4J1B71pUgRSUZ9x_HnfiRzg80Sp6fxo.PyMs5FniiV1CejgFudekT8mylUJRnD5jDqICQ0BZoig
 JO7XjmS_r4.8tl0TRGO5NkzQMdAbXJV4OYxXdkeRrabnHqiloiHSreOLaTF8krftOYfpY11YmE4_
 02SXBRO7oUWwXWM6_a.u1HWuWSGxQn0UJ6AZGHL3iJgVuZBPvCSmYdH8xOkSmi4V6kURgDyFFTzB
 2VJCCgYrRKTiI66aO9rVF7YzR5f.9eINOQomYvr31.IzFnAtOK3ZEGBVEfbVFmSZspjEZwYP6Dgr
 Q...MGY5kpjWLGJ1Sqas2P.nNewVQAOvHuZJpuez3eByig..El0TkkhHYkRUGLYYpvjCqXOXuKWl
 j7mljL7m7Jnx8oValwQ7157xeXGS01sIA00ldvx6tTm.CktSIwyUqdG5lS4ZK8IUNHiCixIMshWz
 xr6jIQY8VF7OG5IjSKmaoydLU.XyyPENpt4aaVK_5O9ZbDHsbD4d7G25dMkesJziV7THcHpby8on
 jxfcuZBVVQ1i_2qRizjystjwqeHBRE.D.Xt4qeDUHUKPLvyUH60CvLs1tKV2XAim9Wp7eBHO3GOH
 sTyuO9SOQPfGXwf_9GlnWCvAqigQctnMcPSYz3u13qh73XhG3Ms4PFAaaSSRC8LCX0m4ZdapBXdk
 kafYgy04YCgvBJEddoUAwgRJhxbXhux.G0kZjZ.4GtydMKnnOuAYLR58qgQgoNYB262M7UwmSDZk
 jVx.3n96MAUzLhY9V3R986ZFG4GiqRPYbJsVs07N5YFMoL7kIC75iWBxqy7PuyEkXIwovy8Kz0xn
 S_IFrtWWwD_eA7L5i.Ni4OUGP161u6UeEwz045iAdS6iGr.qrPVC1yBJUweBxUtiGoRZiCn2XfZE
 WJLotA.gH6DoUZafEMoKoVTHNr_U3oWPCLtbF86nFYU38s45EnBdK5EkTz5q175rr7b0Hpomhyai
 Qirt6_MaDUcUEkCUApLyRAHxbSe6aOc.H5HVMkwKRLvUbtBUQ8MJneh8GCD.exDeCtIXze6GlKUC
 CXzjrxFRwgD5ENXVCoIGyGJ4RDqwXHuKYS37.oaFWpghsJsSP7WrnKm8B._oqeaJKf.vX.bTL0sc
 ahtxfNWbS4_aKVQAKlm8OnverASTNNjzbKyi5nH9T5NIYba9bLUHJKiIzqULzW9uW43w4yhigyWO
 Dfa_GJ04nPEI4o181HvjirQkPlwrkQopxQs.cZwMP3fEP3m9SgnFBcO37pCzyCQ5mIh9n.DhiXmM
 lJkQuId2aeDRBSc5mdvlalYpfTMJGEAY_zxZZrdcFv8MQ2rZFHAYLaRzO5ZMzFdK_YXY2qv4ql_f
 7BBtD9xOv1xHsD7sOvbMwR4G_uO4nLp6XYg30lKE_OUwuI8mc7_Q2xR5WKHwQlLmbqbBip6b.mzC
 X7tHYN4Hxv.2ampnId0nTWeNsfJu1LCKTAcvnq8ZizAmNgoccEhnD4crdnq21
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 Sep 2022 17:37:48 +0000
Received: by hermes--production-gq1-5499fdd576-fw6rc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e436dbe857c00f1411fde156322e5e2b;
          Tue, 20 Sep 2022 17:37:43 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: Where are the Raspberry Pis?
From: Mark Millard 
In-Reply-To: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
Date: Tue, 20 Sep 2022 10:37:41 -0700
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0652ee87-7dfd-0707-ad45-5df2b486c2ea@m5p.com>
To: George Mitchell 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MX7zg0V4Bz3tdD
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jnH9jfit;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.36 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_HAM_MEDIUM(-0.86)[-0.861];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TAGGED_RCPT(0.00)[freebsd];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-19, at 15:24, George Mitchell  =
wrote:

> I'm as happy as a clam at high tide to see all the FreeBSD work going
> into supporting Raspberry Pis of all sorts.  But at the moment, it
> seems to be that there are no Raspberry Pis (of any model) to be found
> at any of the usual sources in the U.S.  Am I missing something?  Does
> anyone have a clue as to when they might reappear?  Thanks!  -- George

Going to:

https://www.raspberrypi.com/products/raspberry-pi-4-model-b/

and, selecting "8GB RAM" and "United States" as an example,

=
https://www.raspberrypi.com/products/raspberry-pi-4-model-b/?variant=3Dras=
pberry-pi-4-model-b-8gb

and clicking on CanaKit got me to:

https://www.canakit.com/raspberry-pi-4-8gb.html?cid=3Dusd&src=3Draspberryp=
i

There are 3 kits and a Board Only listed, but, as stands,
usually some of those are not available at the time. Some
may be preoreder and others "Add to Cart".

So this can get into if the extra material for a kit
happens to be of interest for the price for the overall
combination.

Currently the Starter Kit has pre-order status and the
Extreme Kit is "Add to Cart" for 8 GiByte models.

Even if no combination is currently of interest, it is
a place to monitor for availablity.

I use their power supplies: 3.5A 5.1V .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 20 20:36:02 2022
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 4MXCxW2JL4z4dMFF
	for ; Tue, 20 Sep 2022 20:36:15 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a])
	(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 4MXCxV3lh7z3J2b
	for ; Tue, 20 Sep 2022 20:36:14 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2a.google.com with SMTP id m66so4461149vsm.12
        for ; Tue, 20 Sep 2022 13:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=AWbPqSH+k+9G31tGoFda1Tej9TrahrH8WgFd42ZEE6c=;
        b=79S7JNDXGXb5FlSUf7fwNdM1jyYaTdP4ACoG/Uca1DdnhEgMPV5s8jAe5saJuLZDbU
         CChTaUJYOBZifDOKhQ7VGiNymVKLWn8eTNM5X4OkM31YYPX9L4feyci+RpXfEQ0jPHa5
         skrC6rBckNl6SfCyaP4v2SdManw445Cj7oX5+2MqTR2Z/VY+wMOUVVLEOmH6oXh4+4EA
         TVhD5iNOnqR/VAIabopld/Dar++OZerWaS5BjvFzNE1UtfBEFZx/EZ6zS0z4o78aVw2x
         r3fc+anb+fhFoo37Cv6HlmTBrOBe4m3XJVYhNb24m/aYd/1KGOaXAvzDMglNw/eTkfri
         sz8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=AWbPqSH+k+9G31tGoFda1Tej9TrahrH8WgFd42ZEE6c=;
        b=nVwCKsNTiq12uGqCklHJRuMffPpEilh/rm8AT6Ezn4RwB58TVhjUJYzrx0xfjVPUqN
         u6Gkx2ry7SiL5uehORbad00dAZgpYa8CnsnqbydwWrEQXyKew6bC9z2J5UbHHI8DaEKw
         WIgU/HeSaTIAX9Y65SmsG0pyWCpo2mDDSfqnNd448gXoMCXUNckAiIjQ56zIQQCzKy6c
         YAPQbgimZCAj75FB6UrsP1N/MuHx3WPhT3gO3kevtJmtjHgarqJqSafufWkbMvasKHhj
         rIkh9v4b2hHqLmRwGONzmkd+qkR/sWIp8YcJNUcx46ifVQ+xh5ucxZcq0raR43BiUK8o
         ggLg==
X-Gm-Message-State: ACrzQf0Aw/oV2e8MV3J5xWw2AH60i5gWFI5ouUnmJNoUXGVVnte+pgka
	uREHbZfA4NQL4gU6HDqJKtqblCdDuKXZPG+XhQ6/flzYjWc=
X-Google-Smtp-Source: AMsMyM6e7e7piwkHO9x5TCCvzayTbQkIa95AT0wN8IW35Ph96kqDJ9S+thEsFdkvzk7NliXZIeg/iY5Qa9e/I9KlNFg=
X-Received: by 2002:a67:b209:0:b0:397:1b01:4223 with SMTP id
 b9-20020a67b209000000b003971b014223mr9143993vsf.67.1663706173732; Tue, 20 Sep
 2022 13:36:13 -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, 20 Sep 2022 14:36:02 -0600
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
To: Marek Zarychta 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000007f0fe905e921c7eb"
X-Rspamd-Queue-Id: 4MXCxV3lh7z3J2b
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=79S7JNDX;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.97 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_LONG(-0.98)[-0.984];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007f0fe905e921c7eb
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 20, 2022 at 10:29 AM Marek Zarychta <
zarychtam@plan-b.pwste.edu.pl> wrote:

> W dniu 20.09.2022 o 14:33, void pisze:
> > On Mon, Sep 19, 2022 at 09:48:42PM -0600, Warner Losh wrote:
> >
> >> I've updated UPDATING in https://reviews.freebsd.org/D36629. Please
> >> review.
> >
> >> For EFI, there are many choices. The default installation places
> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
> >> updates it (assuming the ESP is on p1, and isn't already mounted):
> >> mount -t msdos /dev/ada0p1 /boot/efi
> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
> >> If you have a non-standard setup, please see the EFI notes section.
> >
> > My non-expert opinion:
> >
> > 1. ideally there should be an indication in what circumstances
> >     the above is required, because it might not be possible to infer
> >     for the non-expert (with regards to the above) user
>
> While following CURRENT branch, updates of the ESP loader have to be
> done quite often. For STABLE branches, it might not be required at all
> for the whole lifecycle. Reading UPDATING and commit messages could help.
>

They are only ever needed after 'zfs upgrade' on the zpool that you are
booting from.


> > 2. if it needs to happen, where in the buildworld/kernel/install/
> >     etcupdate/reboot sequence is it required? I would guess after
> >     etcupdate and before reboot, but guessing isn't the same as knowing.
> >     It would be great if this was in the Source of Truth(tm).
>

Yes, the order should be:

buildworld, buildkernel, installkernel, reboot, installworld, install new
ESP
loader, zfs upgrade. You don't need to do the last two steps if you don't
do the last step.


> There is no official HOWTO upgrade for arm64 on ZFS. Upgrading from
> sources is a pretty straightforward and standard procedure described in
> the handbook[1]. Usually, such an upgrade is done not in-place, but by
> cross-building and cross-instaling on amd64 machine, so rebooting is not
> required.
>
> To upgrade the loader, you need to copy _newly_ built file
> /boot/loader_lua.efi to EFI/BOOT/bootaa64.efi on ESP partition. So
> upgrading loader on ESP partition can be performed no earlier than after
> completing installworld, which is too late if you are going to strictly
> follow[1] and reboot between installkernel and installworld steps. If
> you are going to follow the handbook, you can find in the OBJDIR freshly
> built loader
> (/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/loader_lua.efi) and
> copy it to the ESP prior to rebooting as described in review D36629[2].
>

My order doesn't require copying from the objtree :).

Warner


> [1] https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
> [2] https://reviews.freebsd.org/D36629
>
> --
> Marek Zarychta
>

--0000000000007f0fe905e921c7eb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Sep 20, 2022 at 10:29 AM Mare=
k Zarychta <zarychtam@p=
lan-b.pwste.edu.pl> wrote:
W dniu 20.09.2022 o=C2=A014:33, void pisze:

> On Mon, Sep 19, 2022 at 09:48:42PM -0600, Warner Losh wrote:

> 

>> I've updated UPDATING in https://reviews.freebsd.org/=
D36629. Please 

>> review.

> 

>> For EFI, there are many choices. The default installation places
>> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
>> updates it (assuming the ESP is on p1, and isn't already mount=
ed):

>> mount -t msdos /dev/ada0p1 /boot/efi

>> cp /boot/efi/loader.efi /boot/efi/efi/freebsd

>> If you have a non-standard setup, please see the EFI notes section=
.

> 

> My non-expert opinion:

> 

> 1. ideally there should be an indication in what circumstances

>=C2=A0 =C2=A0=C2=A0 the above is required, because it might not be poss=
ible to infer

>=C2=A0 =C2=A0=C2=A0 for the non-expert (with regards to the above) user=
 



While following CURRENT branch, updates of the ESP loader have to be 

done quite often. For STABLE branches, it might not be required at all 

for the whole lifecycle. Reading UPDATING and commit messages could help.

They are only ever needed after 'zfs=
 upgrade' on the zpool that you are
booting from.=C2=A0
=

=C2=A0

> 2. if it needs to happen, where in the buildworld/kernel/install/

>=C2=A0 =C2=A0=C2=A0 etcupdate/reboot sequence is it required? I would g=
uess after

>=C2=A0 =C2=A0=C2=A0 etcupdate and before reboot, but guessing isn't=
 the same as knowing.

>=C2=A0 =C2=A0=C2=A0 It would be great if this was in the Source of Trut=
h(tm).

Yes, the order should be:
<=
div>
buildworld, buildkernel, installkernel, reboot, installw=
orld, install new ESP
loader, zfs upgrade. You don't need to =
do the last two steps if you don't
do the last step.




There is no official HOWTO upgrade for arm64 on ZFS. Upgrading from 

sources is a pretty straightforward and standard procedure described in 
the handbook[1]. Usually, such an upgrade is done not in-place, but by 

cross-building and cross-instaling on amd64 machine, so rebooting is not 
required.



To upgrade the loader, you need to copy _newly_ built file 

/boot/loader_lua.efi to EFI/BOOT/bootaa64.efi on ESP partition. So 

upgrading loader on ESP partition can be performed no earlier than after 
completing installworld, which is too late if you are going to strictly 
follow[1] and reboot between installkernel and installworld steps. If 

you are going to follow the handbook, you can find in the OBJDIR freshly 
built loader 

(/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/loader_lua.efi) and 
copy it to the ESP prior to rebooting as described in review D36629[2].
=


My order doesn't require copying from =
the objtree :).

Warner




[1] https://docs.freebsd.org/en/bo=
oks/handbook/cutting-edge/#makeworld

[2] https://reviews.freebsd.org/D36629



-- 

Marek Zarychta




--0000000000007f0fe905e921c7eb--

From nobody Wed Sep 21 15:42:40 2022
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 4MXjNR1h9bz4cpld
	for ; Wed, 21 Sep 2022 15:42:47 +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 4MXjNP6qvPz3G2f
	for ; Wed, 21 Sep 2022 15:42:45 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28LFgfCm040517
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 21 Sep 2022 08:42:41 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28LFgfrb040516;
	Wed, 21 Sep 2022 08:42:41 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 21 Sep 2022 08:42:40 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , bob prohaska 
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220921154240.GA37735@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@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: <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
X-Rspamd-Queue-Id: 4MXjNP6qvPz3G2f
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.99 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_LONG(-0.98)[-0.980];
	NEURAL_HAM_MEDIUM(-0.92)[-0.917];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
> 
> U-Boot resets the bus, re-enumerates the  devices, etc. This
> can time out or otherwise fail despite prior activity by the
> RPi* firmware that managed to use the device.
> 
> My NVMe USB SSD media have such issues with RPI4B's, also
> getting 0 found in U-Boot. This is why I build U-Boot using
> the patch:
> 
> # more /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h 
> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
> @@ -210,6 +210,8 @@
> 	ENV_DEVICE_SETTINGS \
> 	ENV_DFU_SETTINGS \
> 	ENV_MEM_LAYOUT_SETTINGS \
> +	"usb_pgood_delay=2000\0" \
> +	"usb_ready_retry=5\0" \
> 	BOOTENV
>  
>  
> 

You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3.
Does that matter? The description seems to imply not.

> #1:
> 
> I'm unsure if this applies to more than RPi4B's and the like . . .
> 
> Booting an RPi* can have the clock speed(s) vary during booting
> and this can mess up timeouts/waits/etc. during booting, timing
> too early, for example. I use one of:
> 
> init_turbo=60 # or other sufficient number of seconds
> 
> or, if I'm always after turbo mode for general operation,
> 
> force_turbo=1
> 
> in config.txt to avoid the failure.
> 

A few experiments with either (but not both)
initial_turbo=60 [spelling per rpi docs, hope that's right] or
force_turbo=1 
didn't have obvious effect. Sometimes found disk, sometimes didn't.

For what it's worth, I've been using a timeout file, essentially out
of habit. Renaming it to no.timeout seems to have no obvious effect. 
It's unclear to me if timeout affects both firmware and u-boot, or
just firmware. 




> On the RPi4B's I have to boot based on both #0 and #1 being
> in place. Either not being in place can lead to the 0 found
> status.
> 
> A powered hub being involved adds complications not invovled
> in my context.
>

It might be possible to boot without the powered hub, seems to
me it has worked in the past. I'll give that a try again.

 
> 
> What the RPi* firmware does to get U-Boot in place is not
> used by U-Boot for its activity. The RPi* firmware need
> not work the same as U-Boot, allowing for differing results.
> 

Ahh, I thought u-boot inherited at least some environmental
details from the firmware. Thanks for the clarification!

> 
> I warn that my notes above are based on RPi4B activity, not
> RPi3B use. Also, no power hub use is involved. How much
> applies to your context is a valid question.

Thanks for writing,

bob prohaska

From nobody Wed Sep 21 16:17:31 2022
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 4MXk8j2QlQz4cv6r
	for ; Wed, 21 Sep 2022 16:17:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4MXk8h3lxvz3KKC
	for ; Wed, 21 Sep 2022 16:17:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663777058; bh=gNbJkkqrUGlNwwHB/U2p4Gb6cr3oUFDWYaETiy+A3Tc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IM1TPaE1xEQ7UoALEL2+Z3W2qyDWAA2dUfMvA+LSXmqxKV8oVvcbQqc9kr8EauEboRmMonXCkOLn1TDIYX8D0NffA1CcC7gpTFp9WlT9j5GaRr/q2XPzK0oEMPfvWBXEwa9lqxcU3lMo/e0BmfXfC5asi0ErfCcHyH5Ns628P4d7FrZVHMI6DovY6UqQPBZ9Wq8qC6PrmZ//+FGSwc6xwfKNGpLAxgp6/L5B/rSPUdDKjXsW+5L2P9TxxBo+NefxEYFH38vuCcyqfqa3TArA3DtGKUjheJay5+SDbn4k13NrE+w/gYlwvWSU1jIMwI9s4iWOyJyowY/h33pjnpqBvQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663777058; bh=GX75nRfoz3vKhMg75L7n+rvWnJdSWP+w/X0yOOdUr00=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hAQfaN4ljX6T5GRBKClru0hWMfD8apGxAYDCoPgMm4WoYDC546U1UCfdEAGBqDF1Dp05oFnN7kqbxTDmWWvyG2G43jCPPjk+rxHBWUEO4sC6dlgmYjm6rMsGgshli+j5Pwhx8ZT8V5LBL66wwZYv0SSnyVI6tyWGOjNTsKZ0ZEr2nOZJB38dZ1Un8YowcVARxLXqmezaQJ3PduccNlEqorMUnksXgQkltC/EGfQn0DFaRcu2SdQH4IihA96vkwH2XN6s5C1RUBiSmlCPFWkGpOmBEAG/OpNCB7vuOvYTP/OMT2mESsdRHzuHmX1UlN0GsqQ2dXRVRBwBuR8sC6IOyA==
X-YMail-OSG: 1VIrilsVM1m0Om3lT_nwYeLcGsxtsqCc_axRUUGzOqW1HPbEkdQZIRkbSGcls_0
 aEZjvv0c7I9.8gcyEuS8CXBYdeW0q2ATwfbVFwSwNAZwZCQwiSOj22If1SRVFAmGGjg2MhWlazJR
 MK0BI0ZPZrwExYlxyBf6vUYsaXGlK6hXqngPDIciZDaDxTo6AMNo..Bud39fLiSNvfchFh8toNbJ
 e69L8USGKJqBjJboSdDhIptztSlMCEE2t8GlvW0sOp9ik4afsPZ0xQfTnOpf4E1C6Ju6Z.BRxBlw
 wT0Xb7w2etD0Jp4QvP36.oWdh_mdr3Pvt6KqEuQtI5fIf32_x_6_4StwUYvlbvY9QNV6ewVPP4Y2
 ZlQpLch9gskV2meunGrOO5W74he4SKDNw8YHRtx5NQg.nu5ISHlR0zYGF44aPPBvWtKAWCUO4MqB
 UWs4sZ4wCmhjkapfCO9igx_6iNg6F4WuDE.6.JL4pzRz6_N2x2UDm9sHDa13S8Gjq4_YBe0OwgxY
 I4kDY8acZho1MuXPHX7MvQgdJqSZ7yw.i6MSNcO_Nla_OTEbkmV7qDJJq7e1I625CFu_2UarUy_D
 ikRj.G4vBHzZz5dva51uyFSD_p1DRyua6aAETmnFjgT5UlG04KmxBRatxVu3aegMQU3MU4h0r1sh
 vs6wsuZ2t8fbKKzhleDjDhmBojGymYTsefFT_EmujCp6u.zidUpHlo.q5o_GRmWW_FoW4Z6IT2ow
 Y2TMOmszOjjh.Uu6KjS3HoW9p3SMYWZHXaPj7_2IMPUdQhrwM_V0z4.H5YagoEhT_ZD5B_lEHI.n
 csGziWJgavcjV7V1fU39a5F.rxtxx8nQib3UaF9lDd.v4y3R0LfITT8OiJCDpMDQkv6sbPnJPvLp
 TZjyOkKVBxJqlwcBeuI44J0_dR5xnU9leLNdssIVDZZ5LSqb3nIC3qwsbHPNfxNcSVjJ0N8xTN9d
 bQvoZKPmdfZAR61JMk4s9LZ_5kTWWKVAbmJ_vBIshrSBuTfYMmNoqqAh8n8lpSjJ1_lQVLcIGS5N
 s3BZGf_Zc19RpoqYM06odVyvzQDiUgwimcCJpPm7X4IfQFQMU38rCLj73oTEbtlqRyiFjXWSmGT0
 kMm2yrAdstDKaiQo2eXBSq3oDI9P4Kax3gd3ec.ooRW_ikuqjq69ZJS1pAeI1Zys5ylCZ44TYTgM
 iMaqzziXrQstv1XFJkfiksjBDzi__NuEj_iLykTffJBxgfsZcoRjKcwZ9s9AxvgLEtxPjyU67Pvr
 s2yG_eMUcDMvqH8h0Tki9NfcU7S2ZoJQgHP4s_RF5ypGvLPc25NWbnNDa9Y3.r7fkl6pXgVtUeK0
 IcNpEebA9HPg5SudDEpKSoRrBepnbDWjWaBJ1kpj1mBcypuZXkJQi1tCZp6vIo.w5c2a2TBm21eT
 U5DCRp30iqbYmpmipkjXPu2O8XnYlhUyyJG3LogIhVtIDtlmPXVcguWGadcAcwTnw3k2Bykv15qe
 J9RUb_O1Lq_j.KM_qbO1MzhWJwLXPVjKz4yhjtyuHis.R1g7oXvbLLzbEF.ukXbX2EAWnTVrYR.o
 _95CjAsAYpw640Uv2dmT_LHFs.qNrTmoipTo.xoa8bH87_lIgwimz5ZWvjwE.WxFbc6RO.QF1JKG
 Wxj9fDdXrmR9zN4r0a1mKIjcEf3hLp22ULt._.9xJo5PiBXwavpkBU3zjIFbBoWdIGQY.Gjb_Aht
 dSSfqwB3bFl7GNxYXUd85WuqVjkMxAYXI0s5iwhCW87D4j6J9NA8bpLiDJizg3mCIEpYtiqc84vs
 jEBhyS03C8oNVXvoIw0bzHRg_0idJFVSKSIs.iUq5Am4vw6VlSaPJcRWjzymNZQJuTmpfvfWUI.M
 BprnH0897B8Y39G7VDgSZeNSWWfx2qxU0U8DIWuTPWgW3qEq6ZttLVGGH7wzTnmyeezTGHHbHzOX
 DJa4MH4_QWgzK7Qi2LIq1Vk0cd2Jsk3zLd_LzHisPl33DMEqMJDMP1OEh6stmKDJotVUi55dNBuV
 8ljOOWCQGj65.n.NdQX2n.H2A1zMFfR2I_3znxUp6q2Lq77oE29FKcLxd9RvOxF8xPm5dYGBj0lw
 tSpFRC_n0TE0u_Q92DIInRpkbj0_qyjE0tad6O_79PM.qYVP8iI5P2DD.5K3TwfIWHN_9lSc9oR5
 yDqTJcFcbsLDvhBN5vTw.tiJBPcPmUJt74I3R3uh4QbxVlr7kufbpeR8R9rBL_uZZedQ95G0pOyC
 k4PMVDEqH5eZm31RsdyPFaI5SGsdRMtgWiQqYEfnqwcMy5dKCqYQIgvuoq8JvEok85aJwL2REUw9
 l7ilB
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 16:17:38 +0000
Received: by hermes--production-bf1-64b498bbdd-jgj48 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4e1531a1f5eaefb46c54afbd975eda05;
          Wed, 21 Sep 2022 16:17:33 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <20220921154240.GA37735@www.zefox.net>
Date: Wed, 21 Sep 2022 09:17:31 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXk8h3lxvz3KKC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=IM1TPaE1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.86)[-0.863];
	NEURAL_HAM_SHORT(-0.83)[-0.830];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-21, at 08:42, bob prohaska  wrote:

> On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
>>=20
>> U-Boot resets the bus, re-enumerates the  devices, etc. This
>> can time out or otherwise fail despite prior activity by the
>> RPi* firmware that managed to use the device.
>>=20
>> My NVMe USB SSD media have such issues with RPI4B's, also
>> getting 0 found in U-Boot. This is why I build U-Boot using
>> the patch:
>>=20
>> # more =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20=

>> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
>> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
>> @@ -210,6 +210,8 @@
>> 	ENV_DEVICE_SETTINGS \
>> 	ENV_DFU_SETTINGS \
>> 	ENV_MEM_LAYOUT_SETTINGS \
>> +	"usb_pgood_delay=3D2000\0" \
>> +	"usb_ready_retry=3D5\0" \
>> 	BOOTENV
>>=20
>>=20
>>=20
>=20
> You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3.
> Does that matter? The description seems to imply not.

u-boot-rpi-arm64 works for both RPi3B and RPi4B and is what the
snapshot and release images for them are based on in modern times.
I used to have my RPi* U-Boots be based on u-boot-rpi3 and
u-boot-rpi4 before u-boot-rpi-arm64 was created and used for
snapshots and releases. But I changed to track the actively
used variant as the basis for my builds and installs of
U-Boot for the aarch64 RPi*'s.

But I still have the same patch in place for u-boot-rpi3 and for
u-boot-rpi4 :

# more /usr/ports/sysutils/u-boot-rpi3/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
	ENV_DEVICE_SETTINGS \
	ENV_DFU_SETTINGS \
	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=3D2000\0" \
+	"usb_ready_retry=3D5\0" \
	BOOTENV
=20
=20
# more /usr/ports/sysutils/u-boot-rpi4/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
	ENV_DEVICE_SETTINGS \
	ENV_DFU_SETTINGS \
	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=3D2000\0" \
+	"usb_ready_retry=3D5\0" \
	BOOTENV
=20
=20
For my boot media, all 3 U-Boots need the patch. For RPi4B's in
my context, the turbo status is needed for both RPi4B U-Boot
variants. (Unsure for RPi3B's.)

>> #1:
>>=20
>> I'm unsure if this applies to more than RPi4B's and the like . . .
>>=20
>> Booting an RPi* can have the clock speed(s) vary during booting
>> and this can mess up timeouts/waits/etc. during booting, timing
>> too early, for example. I use one of:
>>=20
>> init_turbo=3D60 # or other sufficient number of seconds
>>=20
>> or, if I'm always after turbo mode for general operation,
>>=20
>> force_turbo=3D1
>>=20
>> in config.txt to avoid the failure.
>>=20
>=20
> A few experiments with either (but not both)
> initial_turbo=3D60 [spelling per rpi docs, hope that's right] or
> force_turbo=3D1=20
> didn't have obvious effect. Sometimes found disk, sometimes didn't.

As I said, I had problems unless both the patch and
the turbo status were in place --but on RPi4B's. I
do not actively use a RPi3B but do have access to
one.

If needed I could at some point try the RPi3B via a
powered hub being involved.

> For what it's worth, I've been using a timeout file, essentially out
> of habit. Renaming it to no.timeout seems to have no obvious effect.=20=

> It's unclear to me if timeout affects both firmware and u-boot, or
> just firmware.=20

I also have and leave in place the timeout file. But I've
not tried to determine if it was necessary for the RPi4B's
in some time. Having it just means one fewer thing to
deal with possibly contributing.

>=20
>=20
>> On the RPi4B's I have to boot based on both #0 and #1 being
>> in place. Either not being in place can lead to the 0 found
>> status.
>>=20
>> A powered hub being involved adds complications not invovled
>> in my context.
>>=20
>=20
> It might be possible to boot without the powered hub, seems to
> me it has worked in the past. I'll give that a try again.

I seem to remember discussions of startup current requirements
for some spinning rust in your RPi3B context. (The power
situation for RPi4B's is far less problematical.)

>>=20
>> What the RPi* firmware does to get U-Boot in place is not
>> used by U-Boot for its activity. The RPi* firmware need
>> not work the same as U-Boot, allowing for differing results.
>>=20
>=20
> Ahh, I thought u-boot inherited at least some environmental
> details from the firmware. Thanks for the clarification!

Resetting the bus and reenumating the media is how the
not-found status happens. That is what the block of output
from U-Boot is about for the 0 found message (and somewhat
before).

>> I warn that my notes above are based on RPi4B activity, not
>> RPi3B use. Also, no power hub use is involved. How much
>> applies to your context is a valid question.
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 21 16:43:10 2022
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 4MXkkG0mZyz4cy5v
	for ; Wed, 21 Sep 2022 16:43:18 +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 4MXkkF2CHbz3Pfq
	for ; Wed, 21 Sep 2022 16:43:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663778595; bh=siazBv0SdvJXGcO5Geton0wJz+/oGfoGDb/sy3/1/aw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JqAaHbHIeFFUZ7rNJxhrsPIB1067mr+DhXvnUhFHK0IDn9V8eUt6C0TJ+7SLw5QfA2AZ7OnYqiioCOjFBAwF6Q6hOlCzWlME9Cm6Rv8I4IYzpz7Voz2NDmqaBhKpnI/abTVs13zwdPI+U6t073QfAgVluE1OUo9n/FK2nPjViaxti3PA1/GWi8TyHxBlfMccT8aSINoK0PSUuDTlYFl0JuObbJwEgN1SQaLjQjnlNcGyIX94JQdlLgSo5ais7F+wx5IIs910DXhaN0ZOaMiwyzrBF93NJ1hLNU1q3JXneDvR13D1LvCNfLHieg5Mok2do4xJ4eN3h7KLJuVpX6mxlQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663778595; bh=pjEKkEOLDE0CcTEKoej5N8PFwLK1UYMPcx5mR7KHtvz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BPcpLkSmJniVj5Efcj1W61Rxo6P8Mb5OjV8Il6vnRqRU0GsqSIrG22Ri9icJCJ5B8qnoQNRNf4Y1ZLoIv+pZybSfmDl/jl2SLW3qva4bGrihqa2Oug3zyaCTC1eeBCZ+KkND04HvmMGc7BIqYifXcsM/l6+Nr9XAi686lmbzIeBhQJeqjwCdlf2GBzlKuoIJoPJT/CHrKCe7yahHJPrsXSchevG7Qn8n4fsWa88oP27iFNzcbQ4H7aqPM+MsmrpndmOlkpw82tA7iDemQEckIYr4jTkK2w9ySehDRNUgeeDErgNblsIlerJgTY34iBkxMR8UYAs8JzlxiLRtMmLw/g==
X-YMail-OSG: 400FggAVM1ljM7t6O0NHulO5iBxyWqQH_KjMmlgNb3M2hLNy3ZajlQ3nMzN15kF
 BIRhf8Kpc6OtK68cvDlKSy55z_jStm9QAJWnYCxLYpvjFeTcL0e2ZED3HvDy6._J8vIRvjemDAA7
 taDmAEEH9QaXHNkLbn2Hrw5sjC5qRuKFql282QN_UuyHdmY1CKv5NTSAVtuZ23i.xshTypj4.B_L
 oFrQxBVwlhmlvqncIY9W_Pjp5m_1Uc9yEJahe_MvUsyStkS4YihuCGx_pvuW99TEKG7trjBHb51Y
 zk4GhcGgPQ60zLEMCbBiYgmC2s4KMFM.TGOCKIEBCUwcDqsmZzJi.gVIjrFtbnIbrcgqOYUZgRkY
 u5q0X8hodCymHDoAXF82UiuQNSZ2_.WVvMdIQ0ekM0OOfGJTY3F12SkbR3a9uMpAM8WRXEpoHJAp
 PmZenoyI4Mc_IEIiyEezkDt6Z89jFtN1jQcCmqmq2.BDSMsppKFNJ_ZiNSkObtgfZ7V2ZgUvqFX6
 E9Ly07KeZXvfztBs__yqjmAmbfyqWNZozyb3PP99PtRkd2ZUB_YwMQcamq6_QZ7epKQmkyikQ5H9
 sHcEOBh.WobrCp.zWSu7sXz1r98MLpsmi7r4VwnlfBKq8T209xRTP0UKTQlbaWEC6KVfwS8892Hw
 35f37WxiAKdIdZNcvZfzlPI3LB1XD5yiLCEupjQNptYqvAue_xsDGgbpcCZXV5Hooo.WM_erF1B4
 nl6LOcqWu_AisbLRO6Nke2P59k_42rRbVDu0yht_fyxPBOdKJCNd5O5PH0KbYDCUKMhc6W7nmH5p
 unbat5zAqbYG0zxc.NM_OZrVF5AcS9WwGU6Xof0zAt4ctxhxIdjMoh4XWEmDzti6KMjMosuL26kC
 AL_x7ziuwdvAxpaaF00cn9bz1G0oECnFqrHPtH_E1vrFBbS9aXOM9A9A1DemCTIUKsqQd3Ivnmc3
 SqKxD1_tibznLct5Zo2DiFyxmFx2oVqXE.yA4DFfbAUuYKF9k.0KXHOQWPAAljzBjuLQBNja_aMP
 4s61f8OW_PHr1DlamrvHaKHAeHTxbGSIErdkYVzJgwvaegNIlWZZ6eNrHr580NH.rPW88Tap_Wci
 EhxDmjBpO3NnaRTzgUnXSFRDzT.rhsw85cSdtw9SBh6CXlxI4m_FnIEH2Y6a7MGEvhMeWXqUKJjT
 H6cU3NPnvbTRdZ3dGKXCxqVLcYvkEbnaxAmxWOOTB.zAWHyMHyRZ0BqMzP2BtsQRVtUQijt6c6Ty
 ejExiuzvUrpabSyN_e8GAnr.5eXEGeb8qefMisbxSqounXQviAk8uJRa0keGWl4sFqH.Y21FvvXK
 qO99b.TNVPBqR5PUdSBVEhDdA54iirlHWRrVLxFsR5rZb9mTXBu4_vyBEJBwm9Q7xGcaTPd6xM8h
 3MkuPyiZFD6_xt2ciZwRuUBq0EJwKxEpFUeZNw4OARmojj5WJ4LJCtz2HH10e6dZSL5FMpyAkBeG
 D9nYz3nGliYxxvZyaWb.nmKJqs825XuyPT.yr7tEhnBt8QB1cSt.VcuDy.9Td3vlyxLinlHvzrjH
 qzVUNpTbJ9r_saP8ig_tUQQ7Nzd30esz92h2ZMOrryvxg7rBUTjYpUBKs9h4nveZgDHDnwnmKyAH
 ESdBByU8nJWqGPsJ7SfwPJNYWmTYf4ukTenGZGl.35bJFz6PdtHdwjQWQ8w2CbIiBBp3oxAdssye
 5IjXh.IRFgLiIN4NQP.wbdprVfvnBOc.ThnYIpVQqSoIsurZUorfSENL3rn67W9_SBy.X2udOHVz
 HDxa_EJd9QRjAh7Ajt9MPMHXxkAaZ3RUW7meDpBQzIrLGKEaYuufnnfHzk5El_JiZXe_V3v9mI0X
 7gmia_i7_gfj5k0bN9qW6PBODSXDLyFNcrT5kMDv5qbMFX_YuT8GKHJaev6TlMjAFjnBo03IBzJO
 PnNAnhAIUK_atyiqXI1bnfMiOUiCCEvNypgiwcBB0B4j0mcruLx_Ks8ccvX2yHAZsDC65AIKm.Ug
 IfHXYBmE2TzWIbt5D.cOFGkgYRVJpTZrzltxOt.Y7zQayIM.gcwIfeMFPawn0zyYWMPLhBTNZP.1
 KtkYvOIZCL_ialv7f6UtQWHniUHjSkUbj_AjB6LoQk6vU6Ph676QQPNkIENdaaSm1DAX.wY1HRHD
 yEGrUhylvIb5FuY754upILQ4JmJw9usYXAgBjm8xnur5IMOGvenZ_LO8szcbpU4c_Y4bk80Rqgc2
 6LgGaN4BVK_mFT2nBWlQYBI7nNx8XOjLoAYjgG0juE7LcSIMrT4VOa0qz21CvJCP8EmY37GGT1K0
 .mQo-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 16:43:15 +0000
Received: by hermes--production-bf1-64b498bbdd-646jj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bc7b70b472e8f4dcaa85ee75b73fded9;
          Wed, 21 Sep 2022 16:43:12 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
Date: Wed, 21 Sep 2022 09:43:10 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: 7bit
Message-Id: <852A7B4F-EE5C-4E41-A95E-0CD2FE3B9339@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXkkF2CHbz3Pfq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JqAaHbHI;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.93)[-0.933];
	NEURAL_HAM_MEDIUM(-0.87)[-0.868];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

The whitepsace on my patches did not survive. Trying again:

# cat /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

# cat /usr/ports/sysutils/u-boot-rpi4/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

# cat /usr/ports/sysutils/u-boot-rpi3/files/patch-include_configs_rpi.h
--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

I do not know if this will actually provide the space/tab sequences
correctly or not but we will see.

===
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 21 17:09:20 2022
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 4MXlJV30KFz4d2Z8
	for ; Wed, 21 Sep 2022 17:09:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4MXlJT2cm5z3SPW
	for ; Wed, 21 Sep 2022 17:09:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663780167; bh=d9sWcMUF+72SYM6nxl6EWSAJTUjYVKzyJmV2QJn5f3I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bUZFhzEO5dZ7LdXAXgDlCeqd0KHIMmbcmsU2DzYwa9imGZmHjh0xHaeu67qf8LiKXPWewulaEdMsdf7uu+HvgL8sR/3ZMaJAKEfW5b30pVOBDcc+m2vUROBDqlS7JFSbFkJGFkKNF87HbmpskGMEpiCUSvsT3r29VugOsrAj4p+PndnuAr0UVZfva+V1nAW7RThZL1Sj9U1xKaWtoXosMV2wmUhzTW4ROKggBZ4pNDDu+mrfVN8/Bue1Gb2jhauNZ+wt9WOe3f8OOuNNoWOkHEdmGFxudx4gBFkX7MMD/P8fDp39G464KdLMhN67zHTfkcjoCy1Hejiij84M+dCoug==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663780167; bh=0h6/BCRIiIyfNLTDodeKMy9E3h46Xcid/QrnIlj5dnD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kX2x8Flm2proWqY6Q8qtrcKnAc0vr3UrpCZ3MwVzdVFrlUnpL+l5HijZZAcmQZxtkYkRAYeIU2PemIWxBcjR0Z8m966SXY/kdlM70URJu64SUJJV1BhqkL1fQ8XbLDYk1fRTXIyUlLTS8PBYWEZeg/SSZtMEbEPdQ30KkjqQEP5IYUfhjzGojuDOfqRCTqmzNEiCp3lkdVuB3wG5EiCInkBEDNjhWVIzWoccJg10/r506h6wPT3ZqcbeJ9dbagVrdfGASCGVxNJgDcZAXi20fVwdfcCNQDHXgmaaScOwo6CYFKsP+HA4hL++jB77lBvth+yNC4w0CUV8P7l81wPsvg==
X-YMail-OSG: zdOBXPwVM1lSEPmYqZValFzf22Jd8wbqSd12YXAryEbwmCab7n8a9SFvLemC32S
 o_XN5MfkfIcjYXAXFoluMOiIkPlOY10ZmJ1CjOXeHhWRPOVSStsA3dHy0wtUJcf0rS0y4lHCBsNN
 ZVxb_EA.RsWQaC796m_UTJI_6Dy6VvWTFINItbShYXIPu.vsD9rx9f6BmTs9Nc81m21Ni1fi2M2o
 TYFewraHN0zQHKC.nP0e4uLo1yuNTVSIocKyXFuUlDDGmo2PvO30uIPKdKNAYFBoMCBeNQC4fJbf
 tAkhPKE3hBE2BbtiU3oVw4IXigL4PDjn2HL3oRpqa0vtxGgvMZWVKUg8QYi1QXLlhtwLz2QHqSUQ
 m5RlHkzh1BkbNtMS3pMBnLPAXxK651hzrQZHuMREl2Py4G9hZkDAWJHwP2NWa6ZvulpUUE9xP9d9
 mLeMr.Lntks1aUWpcJXIx4rFBU0jFWdW0D.jk.mYK7uCW_D2t7Bv2uedu13rnGFsxXdx5QLv7o8u
 8c0AZD_zpBv5wWxLQdGF6ucLq0GstXTlwvOEi5PAFAHGxy5zrb5w8pXQOyojTzHtCoAwomxHntUZ
 aUNBwyUBu3G3lk02o.kG1OHWJc.Gq9sOh5bxSLarNxznksoZGYFQyyjR4vhIZRSWlPpx6EY2lo1k
 GdDomNwn9iZF.7uItN.fmWE891B3GaQOz4gPIav4vwyFOSbPqrFSKNLOF519KUtv66o.7Otbe5Ts
 jcfQHmG7vP_ufdMBPudbMMsT2s99YQu7.s4YUfPTTb0VNN3FXj4kM9JTZzyu4gwS4KSFQ.WZV5K_
 AtrRtP.u5RBMyFgW5g4R7bQQQu9NVu3ibVVlldNtxnLaCBXyEjfYFY3xgFNchxC3nRFIK_Jo98dJ
 BY3vcINf7KxMY9z4bGD7vG9YV.SgAt4SRbkCFDk1ip7TLWf.371xQwihYV84Ll.GkXXBbFb1fcVh
 F8lM_Kmw95SJJLb2KC2oBBjFukAT2gRRigJDfFwlN1fZSgNx7azQ4RsVLpjbLyhWioB61Pb.2zpE
 qTMYu7ZS1Tch0raO3Qe5JwUVZJcJDzphxDNOfKruc_UAkJLev_sJy8vqrnDPcxlsioI0nXerEaeW
 ShfcUpXLZAgz5CeCcFwzzWaAEL_j6BVDl5qWZa9k8jYsM.S4Ed0OspF_uUEBe_supLgYuSYQnLRO
 ktf5xIDy7PIsBjPSnZz9NyDgz7bxVmtTGRGPD_2pSm2lIo2yR2wZdUP92Q8l0To72oJT8VM25_mq
 wCCnXBkdenOYDPRekb51uuP.sZ1QeE.9qX0bwyD0zrAfuy71RhlM9KB4ghk1I00hdycKeVOFYe6l
 Tfrid4_OPjMv7VML8DiM1w1tK4BTti3R0vknPL5EeWWruZ9Zgckc5y1KDRu2LhMihI8mGMOFZTmr
 u6frNQ598uGuctUuEoL5fkV6AGZcUgLlMJxid6PxL8ZDGbawpxPWpbiD8dn.h_2Jf5UmGx1_J3bj
 lrK0j1ZiGb3YwSoczHAjP5xXQFb3ypk4Rl0.BrYVHsOur5gdtyRrs0K5QRTTmFtHnjI2Ivd2fSou
 6Y21lHCDboPOI5k4elMUUe8mPyd_Qky6.WLdmVmodDfT0GofWlrr5StiB6lYOozC6z9mdusju6aJ
 J7MB58tEiqEkCKHhGy520y1fjiVy0EahsoNgPQN3s9FUaNq709xBNPnCrEVesjgM9V53hnC5R1Bo
 iHzYTvtt6Hd4dN3WP3ZOjLawOEDjNRyJtKJuyo_oDdpS1EmEqmPl7P9bwj1I2nuSk7NzNJqw.T6d
 86bZwgp2.thJBwnnwJw801F7aBIR4_3s8J5vM9PzksG3k_fce5C3FjZo5zjPym5I2p5W39Mbo6Xl
 M_12S6zFTZ8jFXf1BfypU_MEhnHXOukOBeidm9uAEhy9PHD8quuq0rsTT4oZRglAnSLCMJlTf8JH
 7VKCIAm97i.bbQ9XxZHqXbRQtUnlcx.Ynh.r62Qx54df9Stg38p.058EXpe2oozoUhYQFidhAeOB
 gNUl8CPGePR8pNCOau75AsdzsGc386TI.Y7KYQvJRTawrZw37zqx7x1ea6ZK0olvDedfpmrlfjCd
 R.duN27O3FD58Twd6LlpeKaSfEeU_8cQ6UhyzZbMyNoHMUxIlaTnwawJEMXHpTyN5y_wjPP_ZAPl
 .9L4XDBCizvsY5GjxpGshC1.gLW50nbRrWsQFSWO6hWRYSQTTbWrkVPge9D_sODB5WuerOB9.YKx
 kUWc5I2PomAOeACrX3bL4glW7qi0JQ6UmUShsnr7mN2bkItpn2u1K_3H0iBNmxjxtMZxxSE3E7RF
 EKA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 17:09:27 +0000
Received: by hermes--production-ne1-544744cc75-mbjj6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f1ab9fc97dfb7b2a976cf6ce9e9fa51e;
          Wed, 21 Sep 2022 17:09:21 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <852A7B4F-EE5C-4E41-A95E-0CD2FE3B9339@yahoo.com>
Date: Wed, 21 Sep 2022 10:09:20 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <67A2266D-9BF5-42B6-8597-C2CA8FCFD7B4@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <852A7B4F-EE5C-4E41-A95E-0CD2FE3B9339@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXlJT2cm5z3SPW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bUZFhzEO;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.98)[-0.982];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-21, at 09:43, Mark Millard  wrote:

> The whitepsace on my patches did not survive. Trying again:
>=20
> # cat =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
> --- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 =
-0800
> +++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
> @@ -210,6 +210,8 @@
> 	ENV_DEVICE_SETTINGS \
> 	ENV_DFU_SETTINGS \
> 	ENV_MEM_LAYOUT_SETTINGS \
> +	"usb_pgood_delay=3D2000\0" \
> +	"usb_ready_retry=3D5\0" \
> 	BOOTENV
>=20
>=20
>=20
> # cat =
/usr/ports/sysutils/u-boot-rpi4/files/patch-include_configs_rpi.h
> --- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 =
-0800
> +++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
> @@ -210,6 +210,8 @@
> 	ENV_DEVICE_SETTINGS \
> 	ENV_DFU_SETTINGS \
> 	ENV_MEM_LAYOUT_SETTINGS \
> +	"usb_pgood_delay=3D2000\0" \
> +	"usb_ready_retry=3D5\0" \
> 	BOOTENV
>=20
>=20
>=20
> # cat =
/usr/ports/sysutils/u-boot-rpi3/files/patch-include_configs_rpi.h
> --- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 =
-0800
> +++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
> @@ -210,6 +210,8 @@
> 	ENV_DEVICE_SETTINGS \
> 	ENV_DFU_SETTINGS \
> 	ENV_MEM_LAYOUT_SETTINGS \
> +	"usb_pgood_delay=3D2000\0" \
> +	"usb_ready_retry=3D5\0" \
> 	BOOTENV
>=20
>=20
>=20
> I do not know if this will actually provide the space/tab sequences
> correctly or not but we will see.
>=20

Nope: still lost the space as the first character of any line that
had one there.

Add a space before any tab that starts a line. Add a space to
the 2 empty lines after BOOTENV. That should restore the original
content. The 2 "+"-then-tab lines should not have to be changed.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 21 17:50:26 2022
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 4MXmCk0m4bz4d7Dv
	for ; Wed, 21 Sep 2022 17:50:26 +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 4MXmCh5hMVz3WqB
	for ; Wed, 21 Sep 2022 17:50:24 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28LHoQr7045602
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 21 Sep 2022 10:50:27 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28LHoQKb045601;
	Wed, 21 Sep 2022 10:50:26 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 21 Sep 2022 10:50:26 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220921175026.GA45144@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@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: <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
X-Rspamd-Queue-Id: 4MXmCh5hMVz3WqB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 21, 2022 at 09:17:31AM -0700, Mark Millard wrote:
> 
> > On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
> >> 
> >> U-Boot resets the bus, re-enumerates the  devices, etc. This
> >> can time out or otherwise fail despite prior activity by the
> >> RPi* firmware that managed to use the device.
> >> 
> >> My NVMe USB SSD media have such issues with RPI4B's, also
> >> getting 0 found in U-Boot. This is why I build U-Boot using
> >> the patch:
> >> 
> >> # more /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h 
> >> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
> >> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
> >> @@ -210,6 +210,8 @@
> >> 	ENV_DEVICE_SETTINGS \
> >> 	ENV_DFU_SETTINGS \
> >> 	ENV_MEM_LAYOUT_SETTINGS \
> >> +	"usb_pgood_delay=2000\0" \
> >> +	"usb_ready_retry=5\0" \
> >> 	BOOTENV
> >> 
> >> 
> >> 
> > 

I seem to have fumbled the attempt at replicating your patch. It's
recognized but fails with:

===>  Applying extra patch patches for u-boot-rpi-arm64-2022.04_1 from /usr/ports/sysutils/u-boot-rpi-arm64/files/
No such line 209 in input file, ignoring
1 out of 1 hunks failed--saving rejects to include/configs/rpi.h.rej
===>  FAILED Applying extra patch patch-include_configs_rpi.h
===> FAILED to apply cleanly extra patch patch(es)  patch-include_configs_rpi.h
*** Error code 1

If I open the local patch with 
vi /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
it's displayed as:

--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
        ENV_DEVICE_SETTINGS \
        ENV_DFU_SETTINGS \
        ENV_MEM_LAYOUT_SETTINGS \
+       "usb_pgood_delay=2000\0" \
+       "usb_ready_retry=5\0" \
        BOOTENV

The text was transferred from your email to vi using copy-paste. 
The ports were updated last night, might that be the problem? 
Prior to adding the new patch u-boot-rpi-arm64 built successfully.

Thank you!

bob prohaska



From nobody Wed Sep 21 18:38:57 2022
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 4MXnHh72sxz4dDvw
	for ; Wed, 21 Sep 2022 18:38:56 +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 4MXnHh2HLSz3bdM
	for ; Wed, 21 Sep 2022 18:38:56 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28LIcwX1045733
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 21 Sep 2022 11:38:58 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28LIcw2D045732;
	Wed, 21 Sep 2022 11:38:58 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 21 Sep 2022 11:38:57 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220921183857.GB45144@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <852A7B4F-EE5C-4E41-A95E-0CD2FE3B9339@yahoo.com>
 <67A2266D-9BF5-42B6-8597-C2CA8FCFD7B4@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: <67A2266D-9BF5-42B6-8597-C2CA8FCFD7B4@yahoo.com>
X-Rspamd-Queue-Id: 4MXnHh2HLSz3bdM
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.92 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_LONG(-0.99)[-0.988];
	NEURAL_HAM_MEDIUM(-0.84)[-0.843];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 21, 2022 at 10:09:20AM -0700, Mark Millard wrote:
> 
> Add a space before any tab that starts a line. Add a space to
> the 2 empty lines after BOOTENV. That should restore the original
> content. The 2 "+"-then-tab lines should not have to be changed.
>
 
No luck, same error in the case of u-boot-rpi-arm64. Haven't
tried the others. Could the sources have changed since you
developed the patch? 

Thanks!

bob prohaska
 



From nobody Wed Sep 21 18:52:33 2022
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 4MXnbX5BVZz4dGWM
	for ; Wed, 21 Sep 2022 18:52:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4MXnbW4bxPz3csH
	for ; Wed, 21 Sep 2022 18:52:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663786358; bh=CiXQ1s4aOJyD5awZ+sGVjfhGLwpk4YB7KfVo1iPYhc4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hm6+0N0DYmJaC2EUitzp7e2HtFpweyIAfxMExyEd/cEwvGUZ2bJyznUp0kAUP4FEuVU9ajh4rWpyVxg2ZWDb2+ygik8PaRbENKNCUMlYIKkiPWbDVQDwxyxIjXkAOFp2KVQEQmgzo1g13e1jEN/REJkas310Mo/J9YRtBbCO+ImPLj0S7k2DRPJrcOLBfwOO3Z2lkdyG8F73dUGLporuksajO+jNFUBei7arLbylZMyeSqIJS/csfBsgyqUNsz8m0MpAuD3lrR3+h7/95fDKJkSIekey0cSWHHxWMvhApt5ORuIBYW6RWagJFj3V0WCkNVqlsQuzZnC8YI1rcPH25w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663786358; bh=Vu4+93GKVIcAumzk7Fm87Mg1lahSWkE/i8lntwdBdj0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GtnGy08bDJ/y/FhWUlnlopILoz2Sqe/Lh+unj3FGgSKjY3kjW7dQZcZUYVAZld5p2MSxpEp+Bmkjg16LmC9I8gpyHgIkBEqXmCMDb0w0KldmnX/pvniTwqISRRn2JLAtoJdqZww6TjJT++4TyFhue/8emSOCBBApuuHbSuD7Zu7RMUtQduPu6btzRlaPNTeVER0ls4xcV5SmB0K34ozL5WXy4qO5ul8Es5gL21OGo4P86xg0/QksYc8yDa7+bR2SYNmIIdOl/uLprzcRFFMv2qDmpJCw9MRHKt6d5PNP2BJ/xSrD4aDCeat6rIw5H5Kcs+1RzkxBVO7DmjfhN/CVpg==
X-YMail-OSG: Hh9tLmIVM1mThWHsvxnHrtW3uQCuDvSSGrehhF7GFcVzlQKQmL4N6I7PF.eN2of
 Mza78JL8Ag7NhfDa7PD30iSmFyLZ.QVWC5iPFpytThBaThibmLy1SHOoSA4UdF5hUKu1WGkqR2rF
 VsyxzTzfLwfjcrUzKDM8_lE2DvyH9RZHALNMYG46fy3SJBNVYrAuarcXHHU0qr42Cub4Xhxc1YYm
 a99Jnd4UFRysu1aOUVpI6mf3_eS3rN4c.QYclvo14lEwq8pukIGrxAIH4S0_IneMZUyDlK1qdpOW
 rBqAEFebjy0bzc0K_wJGgQSaiNz4Gbxkl5Hkm3shk_0Y4tSxILREYqI9fvAnFywGZ3orHhMb5gZd
 Jt8ZW_P3sbcLqr2bLYQ15qSWt4a6AUz8Pwp0peDNp0siAZu36sAX3yO0r6Ny1o_8jvOteV.xIovt
 gY2Bz02Ic2r74LGY7XDHk3H4hw29j6_f9mUSFRMqE2_KFISKtjuLjn_Ldpb7PFirjQcs019EtcP8
 P9apBmIVsrYlPvv1DLUijRPwi_J0PlCxcwEhCkhyPtTfjQurkFCxE17WXz1Qd7Fyte4CDxN5y_UH
 ecUWQtjc0lBs8JwG2_T1w7bWgyutIxS.hY0goyWK0EdqQMR_huAm.w.9YBuc727GkjMDozgmPT9m
 KvWoemrTfXEcZP7xKMrcWLcTHv5VDjP06gtiwMlmj_stqL1gdz8Hn7yxCDUoBeGeIDdG1duLjrXl
 Qw37FIXh1v68U.1RAHlwzDv0Ii_QiDZrG_4QPF.nU_1cClER3nJq9H8h4UWQ2jZsG150wton0Z2l
 2X6ny1rVpCldt9f4blLFN8kWGQhJx9ADesXtwj0bZdpvEOHbwmHshCH757nueYX4v8iNnenPI3Q_
 jChB3ANvB1wB7.bQrfonl3Pysv64naHF.1PtXCPKuz8EsDH6P4OtKcjcWfLmxVhKdPDTpPcHOGFi
 kszYqDFFUXN9YjELGhOMw5.yhUHUDUppW_RGgK8s__sdarK35UUoGst5K4FM4V8DtXFL8SBWtkkz
 RYV2lnhoNxRWhY2Mt.7WU5mSmz.KiuV0iYAysDK9zgW1mGiQNaiiieMd595beIn3JL6VCbV7WqDF
 xQg7qkg7j8ZKoPrdCXIAjuzHRtiV3mGJEFyjTZ7UO2sicwFkOKgqBXSUEmXRK.vGwiMe6DJLsFuw
 WisMM2v1e5ws_HJ5j1siOZH.zHE5dO5c4xLe6byKY0nE1QSl0PuFZ06J6z4kega2HYzKYRdWk.Nv
 v1rbin8CUar2tbM8.w1SxHAHfCDW_MLpYXPzaxcOxyIPX8MQyldILx2GUG0XahR7LPojxu2RSCFU
 JC_zBtVqaRmSNEb1.R2gDlpLkhO_Cg7Lbg0gVTvwIUNVU8pMq7dalEneT8roSE_d4zaknJKA_A.Q
 9VyNrsqolCOSzkg76WpF6GMMSsGnCXZPeoA2DcKe4pY.DY18ZPw6sYK8J5.3MOtlTzqKtaiWa7.s
 xfGAL85R7CfAZp0HuSU3Y3CaCEMY806rq9X7XMwMiGlpOqW8D9wg2QPjf_HvpwascVZ_P8lbE.aL
 1tavc_C_abX1gIf38ZFP2muzVrqHgwyEESrwmwsL6wNILbOR8UOqYQnJe7BQBk4egF8.8Zx5q9RV
 f3N_PnTZwrNQ8IphnkyEJHyZmPW.1AbIBKAgsMDI_8NwFusNe6o7.pFvmQT6mGhldUp2LDhtgGtx
 hIQx94ivN4VxOTgYzmyUi9JbhNE7NHGAJzZEsd580OxmvZfTCtguUNKUHcfKtQ5ScJ0wGyxiFtJ.
 6pfcWwjH9xH9te0Rni46LyigEBgCcIA6PSmVNXp6SYPsCc0XcldxsoL3SDbvaMzve7YFO..5KZ14
 aTBrWPY2TE68b8Xuvi3JZ7jBywyKNxpaZ.x0P1PL6p4RimYneCZNXZ1zpeg7wPFoGMN5TjpaNbKm
 yIEbeVGH9BlMhqM0cYsfLlh9m7I3QwkJZ5X1f42SP0jd2OHZ4kbc0Ar5x_TQadiISr.hS_lBr1Vt
 jAQyr6_GIsjqbHNSgBH6KcYbmYpNpUZg41mHFMmPmRCTjm.LRKtvOfdRPWE0Mz.dULyErEe0geM5
 U0A.zmlTh9JOUKOVuBrz31zWzNwXvfAc_dP23GyctHuS9V6EIZ8ShtLh5fAyTUJ7Wet.q627XOv6
 fjZhx4zEtKGfYRupjKfweqBY4uiBSF9EsOmy5WCncFniJbUY705DK2kQEq4LIm6bh3jrf8caOTmE
 fU5NEmJ7iPs.207BP2G.2ScjjwcZrSk4Xu3M0_1UkF4Yw_dpwovqAZKi3eEcwSjeDxuCTWjl_p6H
 4HVDv
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 18:52:38 +0000
Received: by hermes--production-ne1-544744cc75-tx7vf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ee350aac7a928448950d4213c9c1c83a;
          Wed, 21 Sep 2022 18:52:35 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <20220921175026.GA45144@www.zefox.net>
Date: Wed, 21 Sep 2022 11:52:33 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXnbW4bxPz3csH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hm6+0N0D;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.26 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.96)[-0.964];
	NEURAL_HAM_SHORT(-0.79)[-0.794];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Sep-21, at 10:50, bob prohaska  wrote:

> On Wed, Sep 21, 2022 at 09:17:31AM -0700, Mark Millard wrote:
>>=20
>>> On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
>>>>=20
>>>> U-Boot resets the bus, re-enumerates the  devices, etc. This
>>>> can time out or otherwise fail despite prior activity by the
>>>> RPi* firmware that managed to use the device.
>>>>=20
>>>> My NVMe USB SSD media have such issues with RPI4B's, also
>>>> getting 0 found in U-Boot. This is why I build U-Boot using
>>>> the patch:
>>>>=20
>>>> # more =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20=

>>>> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
>>>> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
>>>> @@ -210,6 +210,8 @@
>>>> 	ENV_DEVICE_SETTINGS \
>>>> 	ENV_DFU_SETTINGS \
>>>> 	ENV_MEM_LAYOUT_SETTINGS \
>>>> +	"usb_pgood_delay=3D2000\0" \
>>>> +	"usb_ready_retry=3D5\0" \
>>>> 	BOOTENV
>>>>=20
>>>>=20
>>>>=20
>>>=20
>=20
> I seem to have fumbled the attempt at replicating your patch. It's
> recognized but fails with:
>=20
> =3D=3D=3D>  Applying extra patch patches for =
u-boot-rpi-arm64-2022.04_1 from =
/usr/ports/sysutils/u-boot-rpi-arm64/files/
> No such line 209 in input file, ignoring
> 1 out of 1 hunks failed--saving rejects to include/configs/rpi.h.rej
> =3D=3D=3D>  FAILED Applying extra patch patch-include_configs_rpi.h
> =3D=3D=3D> FAILED to apply cleanly extra patch patch(es)  =
patch-include_configs_rpi.h
> *** Error code 1
>=20
> If I open the local patch with=20
> vi =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
> it's displayed as:
>=20
> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
> @@ -210,6 +210,8 @@
>        ENV_DEVICE_SETTINGS \
>        ENV_DFU_SETTINGS \
>        ENV_MEM_LAYOUT_SETTINGS \
> +       "usb_pgood_delay=3D2000\0" \
> +       "usb_ready_retry=3D5\0" \
>        BOOTENV

The lines that begin with spaces should instead begin with
a space and then a tab instead. (Whitespace does not
necessarily survive unchanged through E-mail or such.)
The space is not from the patched file but the tab is:
the first column is a form of instruction indicating
what to do for the line.

There should be 2 more lines after the "BOOTENV" line. Each
has just one space. The 8 in "+210,8" indicates how many
lines below are for the specific line replacements. So
there should be 8 lines. The lines with the "+" then tab
sequence are new lines. The ones with a leading space
should have the text after the space matching the original
file content: no change but checks for matching context.
A "-" then tab line would be for deleting a line if it
matches.

Similar points go for the other two patches that I sent in
later E-mail.

I'm unsure about the "No such line 209 in input file, ignoring"
message details. But I'd not sorry until the patch file
is correct.

> The text was transferred from your email to vi using copy-paste.=20
> The ports were updated last night, might that be the problem?=20
> Prior to adding the new patch u-boot-rpi-arm64 built successfully.

My ports tree is as of:

# ~/fbsd-based-on-what-commit.sh -C /usr/ports/
branch: main
merge-base: 7e8044bf1f9999f77ac2e1fc2e688df9250dc9ae
merge-base: CommitDate: 2022-09-13 06:28:06 +0000
7e8044bf1f99 (HEAD -> main, freebsd/main, freebsd/HEAD) =
graphics/drm-510-kmod: Update to drm_v5.10.113_7
n595518 (--first-parent --count for merge-base)

u-boot-rpi-arm64 has not changed since:

author	Emmanuel Vadot 	2022-05-02 15:15:40 =
+0000
committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000

u-boot-rpi3 has not changed since:

author	Emmanuel Vadot 	2022-05-02 15:15:40 =
+0000
committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000

u-boot-rpi4 has not changed since:

author	Emmanuel Vadot 	2022-05-02 15:15:40 =
+0000
committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000

u-boot master has not chnaged since:

author	Tobias Kortkamp 	2022-09-10 17:41:16 =
+0000
committer	Stefan E=C3=9Fer 	2022-09-10 =
17:41:16 +0000

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 21 19:30:17 2022
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 4MXpR80DTKz4dLb5
	for ; Wed, 21 Sep 2022 19:30:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4MXpR70cXZz3gHs
	for ; Wed, 21 Sep 2022 19:30:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663788625; bh=fJ0R7KO6EFn524tACIHre1i/anZZOQeqLQgJRNha8R8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iSwcOaQP96f1IO5lB88xIYYn848j3MPch31Ji2aPOLij91p6Z8GYKvRm9UX1lwq/PedFT2K0M1lm150J0mE6mag/5yvM05sa+p1JTgFgX3+F6DUd+XXNZf2teq5/GOHnaDocFfHVUg0VNEwosAwzUofTKq3wBsu+YvR6hTnex1iS/yw3l20bj3UftuMGBmL2HnMPlFCJQe51JOPQDoQeLfCT1+tanIsKPTKakxKVQW7q6lnNdU/sPPpGo5PKE0H/fRXMUxzmvt9Q+c4YPaOumAuZl3Z0TqDQOOd4lUZUL71XAvkdpVUavb4NhmHnRo1MpXRQrI2BwczC07d421aT0w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663788625; bh=183ijFO77GXLFrBj8J/mwJmsk+k95DbQgq+mqOJMsVF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=q3qTfLXpn/pbigqTPsCKGqEpgRojB5MwVqEFpyX+xKE73q6rqzz50AgMs39C9URXUERzWd+C9tanXZdgNqfn0GqI67joHwGjg3UX40qDOha3dsIpPgJ0wMf+VQagfje/HFRzMq6K5F7h60ljloJNFqPvGFzLJA9k8hsFQZIz+YIhXNNrACNGOVuUV1Bjghzl4ch7EuOmSRsjug0rWzYyYx7SR/j+dHnj1ClNm0QsXt/nwP7cUmCu76Gjim2uEyXWEVPHsTfdjBj6/dDrOHjZDcVq7BjMl3Lxwpek8C+OSuhBfE8UYvtbUcNDzJSQk9BjvN64LXS4gR79rK6KjkT6QQ==
X-YMail-OSG: .4H6.JgVM1mSx2x3Qwju5Ln3J5tGWhLc.NZFzHAFN0.51b_rbYMdB1c060sAr45
 _ivDfsmWcfqAVNrlAe.IWQ6Qqu3zuNfl3PD_p62tlTzm8mXZ3YODkyu9et9_OG6xBKmmaMNrrIu4
 CAB5P3St67b6dzYDNaB2Mi_eRls80ZD6conTUg.e4_wjt2m9Z0PCt6bisvV_NN9SorCRbq35Oxdk
 ovAimdPMs9eDIaMZAKKu1yqEqe_vklTIxLKdnYgV0qJxumnUrWEmzddkWAeq7YDGtzGNrmsvCEqd
 z1Yj35KEjSdv_HdzfW7UfDe92pIOBeY7N_048j9J2kVKw6vmo2WppE2emn_hLoAFRjgWrUCc..a2
 wzWBKJdsRe8v6Ci7eduEaV8IhyxiHg8heDtWobKBcSTj4fJ2bk1B88OZKsf0D5DIdno8rZUNhngN
 I0zHuQMmdqXbnmKx7gk1NOtegjJlIRee_SoXcoHw3o8JY5El8Gvg7gJvmVZClM18PPgcTboqyD4h
 uI9PpsQjkAATM2kVoHEK8i6zPTIu.mQ4m5R8e5IDkKn89s8vanaBlsoK.W._agOeAlQQ_CC8_3j4
 yP7yjnkLFZrmyyOPDbcATDCSMy1FH1DNcpE1_T7stppiRkcpb1j.iSuE95chxLQ6qSnbFPuToXxU
 mO5gAqoLm2FYmDQUfFtq3bXGXOR9djZmjn1y1muzRylSG1WZPb.EFvTN7s2Tuptzapf7aZy1QlGC
 2IiCJdiTS5rpP4QW.GCUpXgJbqot62titHmOPPkC5vaZ3wB5NfV6F.j8YOUyjBrnzW.ekjYty4Yx
 vNvDwrgrFKpflIJsXrkNzPuohG4UjiAnVI3gL0mrRJS7QxjbcVMxi8ef6oO9Jzx7T.e7TEj8ht67
 vWzDL38aUBbDjviP0_mLl_5tQhTyg9Abf7iSZCSRJj_VyRNwJTc6f3b0bS.JBrEA7J.LO_dQeov3
 pl4QNvkiqUvs94ZmnYNUW52jGX9lfNQ7TtYFJKIy34PGgyCLk59Lbj60Q90ELmG15OslpZ55t53n
 5eYQ6HxWH81UlY1smkqB0oWFf4yy4rEA36uYgsfsgMCLJWae1eREQL7twlbbWq36F9Jths8151pB
 KR0NBcFISMMPTxNhqKHhJNVbZuGbo0zQ7bipqJ1uVd.KuNSrqIMtajUek5zLfyqHL7S.aH9wUCFl
 Yu.eDwrEBHMTcYJjoPa4cAXMAYAIB1fjuevwZWMmF8c7aDcT2vDNSUQq1zO0YIHCJxnhz.qmw5Fh
 3Jx2bJS7p2oWgJAKH_NR71JTEldwAr5g5PIvfRtlBLjYTmRrZbkPhfWoCjrU8V7nZzc63jgKi.5m
 zyd4nztgPP6Wifc.MdbeYLW4kG0WeQhUJW9O6Auy5uR3ArEBiqBDEb0i.byGRIXf15SGPlI0qaTM
 eF0ZoQgIg3Ui1b1pv4N_mgNa1z6vUIyDC9l_Dw_vnrH7tI7La3bzP6I51w4EdZJxKxQXP78E5C7O
 0VLt04Ax4WxQ3eB_SaZT.daIJnTDC1TxO2JdOE.MeaLndwRlmybs52wAP8PknDeYypmWqKehT_XB
 jT4vm98neB2u2jri2UZIVUTPzZaRBbOsBWymOIYQq2OX.8I50YKHInahWj2yKFgOTIlE80iYv9Wx
 PeCW5cPpVzI4_sO1FBhf86PXOdmb3WRygskAyOQKLzGZSMJ9XEF.xkT8ZQMZ9NsH4K0hFwUK89rF
 dfLhzH1BEpsaT8e5ixeSzrn7O41dF_aNHwmiVT.u86eFfcAm.etfdGsC2AxHX9MPpL7el7C8mnFS
 PjIm_P3X2dm5VYy5PyC630wrH2M.8jyaWkzaGTXRzxH.DAyUJpKCp6PHcxyQCyuoc0VytQi.Q.av
 5U4g9tv__1i0lWHWAaW6GWd3MqwSPBiJQHgRCSC6CfLxLjnPqIVcaSYcY1CF2o074k6AWJmxfjCr
 FATvtqkYNoodDPqZF4d7l51FnY739OAUJ448ENx5hdAkqcS3x7.g5eGDfWlfzOZTFuUpKAPx2ckz
 3.oa58qZ_57itSMyB5.MrOc7B5FmFcEzj4tqjc6Sx6Z0LLiqt.laBkHGrjMfY1AqS7m_4sfvhq4d
 mxOqoiFFnWzt1QPmJWT0ATBqhTb9usyNNRkiBn29kk2ZmUMkvfibp0xWzpe2KCIV_e6ZtcUiSfBD
 Hz0F2zkvOAWj4iubREYWmmpaLAFYaC9QN9jQQF45NCveKKZzoxtaJCxBNTz2C6azka9tDqgk3I5D
 X3SP9YeL3amWKjrWROpIjdHZl1Z_MfkmQbUwY6Mxl9Efh7xYb2VhEUlviIrsr0tibtSptEq_pc2d
 IUG7h
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 19:30:25 +0000
Received: by hermes--production-ne1-544744cc75-m62bc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b0b111a8de5fcf9436c294fb7df55aa;
          Wed, 21 Sep 2022 19:30: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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <20220921183857.GB45144@www.zefox.net>
Date: Wed, 21 Sep 2022 12:30:17 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0408D041-73BC-4450-BAE2-5490CA734A64@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <852A7B4F-EE5C-4E41-A95E-0CD2FE3B9339@yahoo.com>
 <67A2266D-9BF5-42B6-8597-C2CA8FCFD7B4@yahoo.com>
 <20220921183857.GB45144@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXpR70cXZz3gHs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=iSwcOaQP;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.44 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.94)[-0.939];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-21, at 11:38, bob prohaska  wrote:

> On Wed, Sep 21, 2022 at 10:09:20AM -0700, Mark Millard wrote:
>>=20
>> Add a space before any tab that starts a line. Add a space to
>> the 2 empty lines after BOOTENV. That should restore the original
>> content. The 2 "+"-then-tab lines should not have to be changed.
>>=20
>=20
> No luck, same error in the case of u-boot-rpi-arm64. Haven't
> tried the others. Could the sources have changed since you
> developed the patch?=20

No update had caused a rebuild of the sysutils/u-boot* ports
I build (including u-boot-rpi*-2022.04_1.pkg ) since
2022-May-13. So I tried forcing rebuilds:

# poudriere bulk -jmain-CA72 -w -C sysutils/u-boot-rpi-arm64 =
sysutils/u-boot-rpi3 sysutils/u-boot-rpi4

The result (after 3 other build prerequisites rebuilt first):

[00:13:49] [03] [00:01:39] Finished sysutils/u-boot-rpi3 | =
u-boot-rpi3-2022.04_1: Success
[00:13:50] [01] [00:01:44] Finished sysutils/u-boot-rpi-arm64 | =
u-boot-rpi-arm64-2022.04_1: Success
[00:13:52] [02] [00:01:46] Finished sysutils/u-boot-rpi4 | =
u-boot-rpi4-2022.04_1: Success

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 21 20:27:45 2022
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 4MXqjQ4dGyz4cDnp
	for ; Wed, 21 Sep 2022 20:27:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4MXqjP4wzrz3kl8
	for ; Wed, 21 Sep 2022 20:27:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663792071; bh=NFnGaQ1A4ZP4ofuWHcLYMNwayQQalL7VNGzdFsyRxSA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=g5a4lIxTjIPpHItzd9cw1MKdhjTonT4gq/+U3HwE5DJPTHlq/Ucnu7CWwA72aeg2O1vN8vfdeJXhXdLWapF0FrEin8u3g6fWQJp63t90c9Wd/THuIznWqWnWgWqaB0RDrA4MmRBv7V112PiB4RZ5KmArjtOU2uONRypV3HSPO6x2FgtmQt+JqlLnz0cAoY29plIHMC0RpdXCazhAhOLpQz4++RmScVZzsXiuZ5tj/VXnh7ecyUJsN4vL85tNvMULD5swPSK7zNAr4SWHuxkvnz1VEW98xWrtyVmFd1A4XczMCsSbhjaP5Gkjr2jOQ/K52ik7nMMKd72cz+oyKiLTrg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663792071; bh=Ddkw9aRucaNiNpnEfRp+PbxQbq0Qtp8ugRsz0FTFA6w=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G+lBMGNTS+0i1nj1H6mPxTnT1F0zBk8oqSNvDJCCCkXGLcnGTFgni8dq8fCCbig186Ma3Is3w7Hvll8u4IALXk1LbV/bZ9UpzyrZ0dh8WtP1ecDtEdVhqUAqq4CUBVpivy4KdHMULT8+eLdLqbuVZZlPjbjiG7WdGRbdWffoZb+0M28r63k23lJif4Xsx9oy93fLRo4H7l2UUgSTthgAxrJUxMuOtJpb7zSWbhnqMQaP3CraAgxBWLe1V7AlcEf1PMNFvP+Hj7zaXMZeoIVajXmLFHv7qWw3YcohaFZc7dI8tu3Vj4RguuEd3QGn2O5iPpi/H+A+x78bRysNzF7+yw==
X-YMail-OSG: 9yzKlF8VM1mUtVntPX0TQ6w.gUY9c5jma5i7HKSXhKRoa2H8P1.Clv8CqL_Eh_s
 mHCiwLHwZscf1Sklxk1opvo1277a8pPgrFPA7XhkSD.LV7aEUV59jAEBWWT2XvFG9GnojBpif.zS
 U8uChyfhBA0rXTQbZcV4WuOGess6XsfE3MWS6p3vPHrBbzNwUJsWjeBm_A.TQ9tuIsk1.rD3RRdw
 Fu.nV7EENjeJIzSb5HesTaZOURv4nMfOnJJZ.26a8.wSiQFIYlj9FICdVwFspeB5TjXUFXqkpPSQ
 DBKtQkrmSzEyh4q_0Lufg2TvnoPQ1IrzEIp7u.PKL9ScgLQlXD3DqmfzkXwR..G45CnphQyui4g7
 dTD8uFYPESgm.b2T.QtTVzN1P3L_5FMyErHr_drx14xulzW1JSxZ4C7DmM6iiaw2iPqRt_CfHQjR
 m813Q49_Iof2jCjH0uPfTaoBRwA_11Jea1SXCaFuiWHJqe5qn8KpAlAcRHj4UpK6ciRSRr8y2p2U
 762qYwMdjzd3EVRepW2JubaIRi1cPx_rUphjsmVCvOf4ZKJdLkgjmZuTxKE5OIF8ZVTAwet.rN7h
 nJpkFHaMu1nC7kr6E6.6oB0u24MsimDkenWddHWfJB6vnfmjlIxCSnFJk5Ioo_dvBhSXoZZLuZdR
 KmWUd5IItKyaqYwvplFEGr.hTkVzwswEDc8ViwffSyY6HGPJ8Z8AE0EimSGki5FMDrzFp63wZFfp
 Se2kU67dp7MdRmgreu5PEkpzgfIMZExTTpDgNl5sYKP3Albq4vZ1prviZT1nYtUfL0DHdB6bsZMo
 YgJmlFtgaWoFDtubFG2BrErYqC_rbaGUgRDIdNkzAs48XrvbtMAjNa4ZHu5zblf6EwxhVFTC2LuZ
 v2kg.6EQK0D9tvK_Hswx6SQiZbJIUNic_03oEaNaVrPNXtcnBLK_UAxkxm8fVJ6qs92p3WEOsnXV
 pdYkxsZr9qQLYBS2.pm6Q.jbXI1.pdA0ptuUdHgc3JO8z.wM43I8og8MfggepbzcQtgmwY5wkrJt
 AVOgE8vyEaqGPdqWFr8EK9WOkuuly1Clr1ipp1m43GFyZKG3Xtc.FcqO.x.AR9v3AnmNmpLN.qBD
 FSuIyOqsFTH7nASYh_XzsRs2WrjTzWoQdV.4Xokeb86KrpBy0ZguKdnRgXSgzx6p2wtGhX4nS.EH
 dlEFWnXOZBCg7mZLv9q9F9fOzGWLtyYyYtamb72xyiSjwXf8h8m6KBFi5hBuNis7VMzjUT8bda3b
 TgMprBA_2yZ8qBt9GIhs17dotjilpxS59I8KgDqfoI.DrFCarNt7.WgX.REfHdZTYxdJHl1lucy5
 XuhHGOtrdlcpos6os9VaF0V0f6jFc8sqrJsyYbjcyi6U14d7zLkdk_dX6Ovt1UFhMBeXD1AC3zLA
 bn44Ybcl5B56SQN1uQ38ZNzhyMhQ3X9gWfQQi_hfMiMfxeIYAC22gSL5PJ0h759HNZvtPwieiBJO
 eOAVJHUnAeavSR9n8vAqHzBu.jZE2Eyai_hbsu4zIiuwwR2WScqCx3K6YZb8DrNyTUMKXfDv10VM
 EYvgXzOHuK_zXj7fVwu34BtZU9go5euxxtrRLFjoXZ7943OxXHX_dBCk1gCScqXWHI1ZCe0pqjeN
 dMBlwlLLZdOb_TczFsI0sCjNFRIA7w_R7wfDUUP_Gewm2RjpFRFf8AYg.uofsruQb2wkidsroxqY
 Ik23dwKW0vU3zvIsqc_FCVED7aTcZ4V1fms8A1K6XFNuCSe3OP8oIJmWMHaTz8BM9UmOWLUNXLab
 2Z3h2rmcLQpM8m0rhRYtt0UUCyZx4jH_2JGJqd6h.hyDzTXYyXt5BD.bsTMKifM7nIb0ltB.Trlq
 S8cafoe0u.__AAV5LjmouUlL3CDoSwvpu1AnguzlVcUhjJocF430rYEmWFYi4h3G8K_mbpJlat9Q
 9a_uZwICdT8KX911s2wrDtJUDR.xlmyMTqNuM9Jv3CW.I1OiDkfbMebzSgpMmqiQGmNpElncko0W
 OakEEJkBvs362yUImawse3d1nIE9ec9ekHB1hD1pitClMYthKCh5GVzwaFRLsQU0tvLe_Z2UaGuc
 iz61U8scgz2c_c.Vv4_KGmTqm0pOEQlyMj.mKoC73GsTqYkHACpCFLUayGlENMpr3bw.XrVWqwih
 7nKrB4bzLObk0EzHAS1JydMaWViLMEfYvuB8HNR1VDcQNnsMmRpuJ9CS2agVT1W0AzOQjr11e80t
 4tWzuceOQvXoSN6RxOwwdKfp_mBsS3Ux7X2Fv1zJQThtr3in2HFNGB5R8cILAqQIVZEcO4NyJKG6
 2z._9Jw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 20:27:51 +0000
Received: by hermes--production-bf1-64b498bbdd-tl26t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c5904217a6e0b218c0625561a168f8ac;
          Wed, 21 Sep 2022 20:27:47 +0000 (UTC)
From: Mark Millard 
Message-Id: <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_5214F6BF-C69F-47AF-9598-756FEBEB5C6A"
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 14.0 \(3654.120.0.1.13\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Date: Wed, 21 Sep 2022 13:27:45 -0700
In-Reply-To: <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
Cc: freebsd-arm 
To: bob prohaska 
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MXqjP4wzrz3kl8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=g5a4lIxT;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.98)[-0.976];
	NEURAL_HAM_SHORT(-0.95)[-0.948];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_5214F6BF-C69F-47AF-9598-756FEBEB5C6A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 2022-Sep-21, at 11:52, Mark Millard  wrote:

> On 2022-Sep-21, at 10:50, bob prohaska  wrote:
>=20
>> On Wed, Sep 21, 2022 at 09:17:31AM -0700, Mark Millard wrote:
>>>=20
>>>> On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote:
>>>>>=20
>>>>> U-Boot resets the bus, re-enumerates the  devices, etc. This
>>>>> can time out or otherwise fail despite prior activity by the
>>>>> RPi* firmware that managed to use the device.
>>>>>=20
>>>>> My NVMe USB SSD media have such issues with RPI4B's, also
>>>>> getting 0 found in U-Boot. This is why I build U-Boot using
>>>>> the patch:
>>>>>=20
>>>>> # more =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20=

>>>>> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 =
-0800
>>>>> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 =
-0800
>>>>> @@ -210,6 +210,8 @@
>>>>> 	ENV_DEVICE_SETTINGS \
>>>>> 	ENV_DFU_SETTINGS \
>>>>> 	ENV_MEM_LAYOUT_SETTINGS \
>>>>> +	"usb_pgood_delay=3D2000\0" \
>>>>> +	"usb_ready_retry=3D5\0" \
>>>>> 	BOOTENV
>>>>>=20
>>>>>=20
>>>>>=20
>>>>=20
>>=20
>> I seem to have fumbled the attempt at replicating your patch. It's
>> recognized but fails with:
>>=20
>> =3D=3D=3D>  Applying extra patch patches for =
u-boot-rpi-arm64-2022.04_1 from =
/usr/ports/sysutils/u-boot-rpi-arm64/files/
>> No such line 209 in input file, ignoring
>> 1 out of 1 hunks failed--saving rejects to include/configs/rpi.h.rej
>> =3D=3D=3D>  FAILED Applying extra patch patch-include_configs_rpi.h
>> =3D=3D=3D> FAILED to apply cleanly extra patch patch(es)  =
patch-include_configs_rpi.h
>> *** Error code 1
>>=20
>> If I open the local patch with=20
>> vi =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
>> it's displayed as:
>>=20
>> --- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
>> +++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
>> @@ -210,6 +210,8 @@
>>       ENV_DEVICE_SETTINGS \
>>       ENV_DFU_SETTINGS \
>>       ENV_MEM_LAYOUT_SETTINGS \
>> +       "usb_pgood_delay=3D2000\0" \
>> +       "usb_ready_retry=3D5\0" \
>>       BOOTENV
>=20
> The lines that begin with spaces should instead begin with
> a space and then a tab instead. (Whitespace does not
> necessarily survive unchanged through E-mail or such.)
> The space is not from the patched file but the tab is:
> the first column is a form of instruction indicating
> what to do for the line.
>=20
> There should be 2 more lines after the "BOOTENV" line. Each
> has just one space. The 8 in "+210,8" indicates how many
> lines below are for the specific line replacements. So
> there should be 8 lines. The lines with the "+" then tab
> sequence are new lines. The ones with a leading space
> should have the text after the space matching the original
> file content: no change but checks for matching context.
> A "-" then tab line would be for deleting a line if it
> matches.
>=20
> Similar points go for the other two patches that I sent in
> later E-mail.
>=20
> I'm unsure about the "No such line 209 in input file, ignoring"
> message details. But I'd not sorry until the patch file
> is correct.
>=20
>> The text was transferred from your email to vi using copy-paste.=20
>> The ports were updated last night, might that be the problem?=20
>> Prior to adding the new patch u-boot-rpi-arm64 built successfully.
>=20
> My ports tree is as of:
>=20
> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/
> branch: main
> merge-base: 7e8044bf1f9999f77ac2e1fc2e688df9250dc9ae
> merge-base: CommitDate: 2022-09-13 06:28:06 +0000
> 7e8044bf1f99 (HEAD -> main, freebsd/main, freebsd/HEAD) =
graphics/drm-510-kmod: Update to drm_v5.10.113_7
> n595518 (--first-parent --count for merge-base)
>=20
> u-boot-rpi-arm64 has not changed since:
>=20
> author	Emmanuel Vadot 	2022-05-02 =
15:15:40 +0000
> committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000
>=20
> u-boot-rpi3 has not changed since:
>=20
> author	Emmanuel Vadot 	2022-05-02 =
15:15:40 +0000
> committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000
>=20
> u-boot-rpi4 has not changed since:
>=20
> author	Emmanuel Vadot 	2022-05-02 =
15:15:40 +0000
> committer	Emmanuel Vadot 	2022-05-03 =
08:10:43 +0000
>=20
> u-boot master has not chnaged since:
>=20
> author	Tobias Kortkamp 	2022-09-10 =
17:41:16 +0000
> committer	Stefan E=C3=9Fer 	2022-09-10 =
17:41:16 +0000

I used:

tar -xf /usr/ports/distfiles/u-boot/u-boot-2022.04.tar.bz2 =
u-boot-2022.04/include/configs/rpi.h

to create a local u-boot-2022.04/include/configs/rpi.h
in order to look at the modern file. The
ENV_DEVICE_SETTINGS line from:

#define CONFIG_EXTRA_ENV_SETTINGS \
	"dhcpuboot=3Dusb start; dhcp u-boot.uimg; bootm\0" \
	ENV_DEVICE_SETTINGS \
	ENV_DFU_SETTINGS \
	ENV_MEM_LAYOUT_SETTINGS \
	BOOTENV

appears to be at line 173.

A correct patch file finds the matching lines despite the
difference in line numbers, a difference that is not too
large by its matching criteria (given correct text matches).

The modern FreeBSD lists might allow text attachments so
I'll try that publicly. (It still has the 210 line number.)



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_5214F6BF-C69F-47AF-9598-756FEBEB5C6A
Content-Disposition: attachment;
	filename=patch-include_configs_rpi.h
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-include_configs_rpi.h"
Content-Transfer-Encoding: 7bit

--- include/configs/rpi.h.orig	2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h	2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
 	ENV_DEVICE_SETTINGS \
 	ENV_DFU_SETTINGS \
 	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=2000\0" \
+	"usb_ready_retry=5\0" \
 	BOOTENV
 
 

--Apple-Mail=_5214F6BF-C69F-47AF-9598-756FEBEB5C6A--

From nobody Thu Sep 22 01:45:00 2022
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 4MXylJ5R3Lz4cwY1
	for ; Thu, 22 Sep 2022 01:45:00 +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 4MXylH4K0qz3CFX
	for ; Thu, 22 Sep 2022 01:44:59 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28M1j0cI047090
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 21 Sep 2022 18:45:00 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28M1j0oI047089;
	Wed, 21 Sep 2022 18:45:00 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 21 Sep 2022 18:45:00 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220922014500.GA46697@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@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: <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
X-Rspamd-Queue-Id: 4MXylH4K0qz3CFX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 21, 2022 at 01:27:45PM -0700, Mark Millard wrote:
> I used:
> 
> tar -xf /usr/ports/distfiles/u-boot/u-boot-2022.04.tar.bz2 u-boot-2022.04/include/configs/rpi.h
> 
> to create a local u-boot-2022.04/include/configs/rpi.h
> in order to look at the modern file. The
> ENV_DEVICE_SETTINGS line from:
> 
> #define CONFIG_EXTRA_ENV_SETTINGS \
> 	"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
> 	ENV_DEVICE_SETTINGS \
> 	ENV_DFU_SETTINGS \
> 	ENV_MEM_LAYOUT_SETTINGS \
> 	BOOTENV
> 
> appears to be at line 173.
> 
> A correct patch file finds the matching lines despite the
> difference in line numbers, a difference that is not too
> large by its matching criteria (given correct text matches).
> 
> The modern FreeBSD lists might allow text attachments so
> I'll try that publicly. (It still has the 210 line number.)
> 
The patch emailed as an attachment applied without a problem.
Better still, it seemed to help with mass storage device discovery
for the first five or so tries. Around try six, the system lost
the ability to recognize the USB mass storage device and then
seemed to get stuck in a loop, with repeated attempts failing. 

After setting initial_turbo=60 in config.txt the first reboot
found the disk, the second did not. Running usb reset then
found the disk, but run bootcmd_usb0 seemingly caused a reset
that  _then_ found the disk. 

The display of usb tree output isn't always the same. On a failed try it 
looked like
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub 
  |
  +-2  Hub (480 Mb/s, 2mA)
    |
    +-3  Vendor specific (12 Mb/s, 90mA)
    |    FTDI FT232R USB UART AM00KE3E
    |  
    +-4  Vendor specific (480 Mb/s, 2mA)
    |  
    +-5  Hub (480 Mb/s, 100mA)
      |  GenesysLogic USB2.1 Hub 
      |
      +-6  Mass Storage (480 Mb/s, 500mA)
           JMicron  
         
On a successful try it looked like 
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
U-Boot> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub 
  |
  +-2  Hub (480 Mb/s, 2mA)
    |
    +-3  Hub (480 Mb/s, 100mA)
    | |  GenesysLogic USB2.1 Hub 
    | |
    | +-6  Mass Storage (480 Mb/s, 500mA)
    |      JMicron SABRENT 000000000000A
    |    
    +-4  Vendor specific (12 Mb/s, 90mA)
    |    FTDI FT232R USB UART AM00KE3E
    |  
    +-5  Vendor specific (480 Mb/s, 2mA)

Not sure if this is even relevant, but it does seem odd.

Thanks for all your help!

bob prohaska




From nobody Thu Sep 22 12:38:16 2022
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 4MYFFG1yL9z4dFsW
	for ; Thu, 22 Sep 2022 12:38:26 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from land.berklix.org (land.berklix.org [144.76.10.75])
	(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 "land.berklix.org", Issuer "land.berklix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYFFF2PTNz45qX;
	Thu, 22 Sep 2022 12:38:25 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (p4fc2a75e.dip0.t-ipconnect.de [79.194.167.94])
	(authenticated bits=128)
	by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 28MCcHAo043690
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Thu, 22 Sep 2022 12:38:17 GMT
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (localhost [127.0.0.1])
	by lapr.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 28MCcGSq034387
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 22 Sep 2022 12:38:16 GMT
	(envelope-from jhs@lapr.no.berklix.net)
Received: (from jhs@localhost)
	by lapr.no.berklix.net (8.16.1/8.16.1/Submit) id 28MCcGIH034386;
	Thu, 22 Sep 2022 14:38:16 +0200 (CEST)
	(envelope-from jhs)
Message-Id: <202209221238.28MCcGIH034386@lapr.no.berklix.net>
To: freebsd-arm 
cc: "Gary.Jennejohn" 
Subject: FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220916-f42139db639-252407.img
From: "Julian H. Stacey" 
Organization: http://berklix.com/jhs/
User-agent: EXMH on FreeBSD http://www.berklix.eu/free/
X-From: http://www.berklix.eu/~jhs/
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-ID: <34384.1663850296.1@lapr.no.berklix.net>
Date: Thu, 22 Sep 2022 14:38:16 +0200
X-Rspamd-Queue-Id: 4MYFFF2PTNz45qX
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com
X-Spamd-Result: default: False [-2.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	HAS_ORG_HEADER(0.00)[];
	FREEFALL_USER(0.00)[jhs];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[berklix.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi freebsd-arm@
I just booted & loged in as root on my Pi 3 Model B+ with
 FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220916-f42139db639-252407.img
Thanks to Gary J for the Pi, & all who contributed to the installable image.

I had trouble shuffling 2 x USB to PS2 converters, & 3 PS2 keyboards
before a keyboard worked. Cold booting after all was pre-connected
worked.  I'll configure ethernet & sshd so I can remote login before
I risk changes to keyboard.  Then extend the MBR to use the rest
of the SD card, & add WLAN etc.

Thanks,
-- 
Julian Stacey  http://berklix.com/jhs/  http://StolenVotes.UK
Arm Ukraine, Zap Putin.  http://berklix.eu/ferries/#dover_solution

From nobody Fri Sep 23 02:11:18 2022
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 4MYbHL2c0Fz4cwtS
	for ; Fri, 23 Sep 2022 02:11:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4MYbHK3178z3CMd
	for ; Fri, 23 Sep 2022 02:11:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663899082; bh=APqbKJzXiPs70qHnmp3w1xYDcnFwMNYYUWkUBY6vv6I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Mt58Yh5DimWv5xFAYmAFgL4ZIJH6+7sDf8pLAsfeHbK8HtzgZIZX0+EENiURv/cAzZ/GrfiBb3Zwek1/nPtVizZhzTuzI8sYMnJLPJEFNH3e9V0XNXBbAnFybeKHhYCERml5AZzSTnt7KanOKrehsrIRB51de4dBVhX+PyFe8wajytTxbpjTbTjg/u8MKcriW5fWiVaqUtRcUJU6SiF8nydwQT1Oe6Ts9uqAu730wfbeipZl6GXzAmHUqDM9r/vL3QCEdFgf7EYbKQZa73qJKqUmoBscmxB8mj/OHZd3LLcxARXC6DW03acLMryIVbfEzENy8SxnXuoMpxnBaVN9ng==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663899082; bh=oJ6bSNpJSBowZ7BJ7FNb42taW8hqJHofDrCLBMhXk4R=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cY+3pBk/uTcnitjmtBf6NnSPwxZdltkS8SqCytBOAVpgeotS+v/+E7nmHqbZUc9YKh5QmbNEgnu3HmDNcAfksHaHfLdXFlXEVxCrWK41P7bXil2N5QtX9ZiP6U7QjDzfz8NvJcVF3IIUIPfveOVxRqUQjxDuVfoKKpuT0I3HFwATUnEzda/UZCJsE+fknC+LV7u53uRRvsAPoNK2S6Xsor8L5hxgMe3kHv95i9fupJ8GiSTLM1kMZgvK2EcDeZbv6R5xWfAUc2MZWJdIt4+04TnToK70iIbhD2zDPVh4yaqjoF4B4j7r4dN9KhvJxW82bFf6RVPcLvKQtLhvykfzgA==
X-YMail-OSG: jNvEWGcVM1lJx_JJ9hVi_zoeOMQBGLGkUUKfAwNtljfwQb6dNQpZYeNaq4yYUET
 l.WXOUWFi0yvegh0jDHMVNp3efwqOINxYeFvVqipiIKneZ.IWUi4wEOIlbpYL1org0lwSBe01Ebm
 qUliIGflu6HRT.N_4iZ4G92eYeYEOJ57kx3UHfOPlIE3eXjZcJizfd2PfCb7LsY.szJw0Z2ZJimt
 zCEIUd.pJl1tgj.QH67OiWN2fr18Yy7iG_LPzCfzSxseFmNZcG7COgZyt_1W9gsS9u16wS5WY3aM
 nQK_sJuzALvK4T_agvcQ1WB1QlRYm0XQVqK_b0AXd_3oMZpkz_Jbaa08lL291sYBV2paeqYq3vf8
 EhBAhNL4vQ_bqXdEScEB5MCmnrG6lyIu1tBqlkog8voRNH2Fdc5n5gklUqv0UwqdejK4E7zS7E3K
 4nHj8J7xHQ9fK5tfUI.awYtcUEhYL8bcaTS5u4QVtzigzfJwJI67jugoX7c_2Jx90DyeYhdWCocK
 hiajApfH.mMw9ukxXSV5yj12f_9WA.mPJTK30IS9sNdwZ7zbBzQopRIc_aZTc2N_9TE1FipUNekm
 UTY_JKEUr6TlzeT.wyN8wuWCgaR5haL9w1Kr9JiPxF0aruFbNwWAXt92UUxBCHPLbexBZlAzFJ.s
 4QmeXtSJbakR2audUnL5GPfdZpcrSFQAvjUeelU8hDWMiEv2MmpQWdSfcj.uIEo1mvfF5U1sIP1T
 NqVUUgkQajTwb3hYo1q02gw.Jx40kPbiA2yqNHq08XNk2GibEgwG.RbIpHyybSNYjiow1clk1u.6
 cP.GqWGhvDLWm8HLOvLkX31lBvzp5I2u_.le13Pe7J2pitWLGQT0EwaUB9UVBXZvWaKSLATzavkO
 cPU4z4XbTtanZr03ZJS4M8eJEp6NYuPqHC6rIkoDAscWu3Ui9rpF6JmPbfMcS8RGGr3x_wskITxH
 hdqhzGIUbI6eGXR2W.16qzjjYvCafKUne0XiE8VADyTWc2gscxgvasFVmbPv6DzJZ3pZVkxlsCm_
 PQEctqF9bXSHDIW4vM0m0NywUmphZ02vzZPcStHG8xNkSgWU.K0euO8aoKeMVu6bEl0kMcdYuv0a
 mAi3P5XgpPi0dm0BK9Klrc3PEQFGYV9RGqLRlDpfMa8J1OVB5AdLUJzLj93onKG6OyewYmXGu.RC
 .XgZBNpx5dzkw1TzC57i4JtjV5Wbm417inXuwxdHNnOovgtmxGaKxUUKUbQsH9ZVrJW2cumNtODU
 KcgpjhXidDyeTpEIy.M64YWP3mL2YDbe9GEavbq4gKTRXCYC1h1xfgUoaFG7WMxawgC7ms6KH9f1
 nw3jtzlgKv_KyN0ypJp5SkPE_ZYazfrOv4Fgi3f47l0w_kXy6rsVJbsbm.WoIW9UwdXyTi3TU2sG
 HFNRazAkSuaanAOqD8WH_bOaOqOHRM9pYtvo1AxkhDX9PRVrMVIrJ.Pnjis9Y7WhKEvcZvVKfgU9
 I8jMIpdgTR6BQ6FLipvILkzJbzKjcwDIuLNQW3.GMIxl3cDABrUo32mqTJJSbjQZZpOOzln1CtS.
 jYi6cK3gv0txVy9k2aLr5IeBGbXJuKjx8LIMSpv7nEUkD4iH_ZJf_9.5FHcTkDv8CDwtiQzpSLqD
 hpATl0M9NjyHm8SNaEFGXCmu7EynlQ69nTlSDcEQxy7oTHct52xyNeB3KGMIq1pYlmz2iC2ztAJF
 gHoNDOw_2w0hw.X_Ic6sv0LZX90r6C8JIb28CO2KN33b19L5bMHKvVcARZe7czPyH_t3iNkahtZX
 kHifh28wwnmj1lHRzjOO7Rgo2ufN9WXG2FH2SUKHXvhaFQ2EOc1QqF5PRx4q5OgtZaOJrD_QPvGe
 txiynjt9YEdWwnHH1sa1fVlZ7T6toyb4wAY7pl.SoXhZkKNsLFOirpOMs1oZlcGGPMqbr1bcPLQN
 nnQwk5mqLt149u5CHhlfyeToUlO0KtVGHz2onQb7YhrmI8TE0pHwAlsCuqH6v46kVMxidFqk7cok
 X9PVzWpbFnb93ZejRPMypUZrZTF5rCO2DhKFlDq0vgA3SJGHp97_XwIU_Q4GCd4ozJkjcxc1Vsji
 9kvNx180HM5PIv459K79JRTB6hbW2Mtw5R85iET_DU_zPMetEjsDRZe0VTROpTct3sz5MgXngLf6
 d.FCvDJJwPVQBuQMiR_PRRTScPWM.5uPuJy5Bc9RL.9FAhqJQa2d0XsDzcHFdO3ll2moM0UaLOmM
 16RspkUZ3JjxETBdGE8itITsY4mYILntOzuf_avNgmIldo33LYuRoYFn_a.aq107w0BiV_I664Zb
 TmEL3u.o-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 Sep 2022 02:11:22 +0000
Received: by hermes--production-ne1-6dd4f99767-hqzzl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 84a2febc1fa17ad5d12536eeecc100d7;
          Fri, 23 Sep 2022 02:11: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 \(3696.120.41.1.1\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: <20220922014500.GA46697@www.zefox.net>
Date: Thu, 22 Sep 2022 19:11:18 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MYbHK3178z3CMd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Mt58Yh5D;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-21, at 18:45, bob prohaska  wrote:

> On Wed, Sep 21, 2022 at 01:27:45PM -0700, Mark Millard wrote:
>> I used:
>>=20
>> tar -xf /usr/ports/distfiles/u-boot/u-boot-2022.04.tar.bz2 =
u-boot-2022.04/include/configs/rpi.h
>>=20
>> to create a local u-boot-2022.04/include/configs/rpi.h
>> in order to look at the modern file. The
>> ENV_DEVICE_SETTINGS line from:
>>=20
>> #define CONFIG_EXTRA_ENV_SETTINGS \
>> 	"dhcpuboot=3Dusb start; dhcp u-boot.uimg; bootm\0" \
>> 	ENV_DEVICE_SETTINGS \
>> 	ENV_DFU_SETTINGS \
>> 	ENV_MEM_LAYOUT_SETTINGS \
>> 	BOOTENV
>>=20
>> appears to be at line 173.
>>=20
>> A correct patch file finds the matching lines despite the
>> difference in line numbers, a difference that is not too
>> large by its matching criteria (given correct text matches).
>>=20
>> The modern FreeBSD lists might allow text attachments so
>> I'll try that publicly. (It still has the 210 line number.)
>>=20
> The patch emailed as an attachment applied without a problem.
> Better still, it seemed to help with mass storage device discovery
> for the first five or so tries. Around try six, the system lost
> the ability to recognize the USB mass storage device and then
> seemed to get stuck in a loop, with repeated attempts failing.=20
>=20
> After setting initial_turbo=3D60 in config.txt the first reboot
> found the disk, the second did not. Running usb reset then
> found the disk, but run bootcmd_usb0 seemingly caused a reset
> that  _then_ found the disk.=20
>=20
> The display of usb tree output isn't always the same. On a failed try =
it=20
> looked like
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub=20
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00KE3E
>    | =20
>    +-4  Vendor specific (480 Mb/s, 2mA)
>    | =20
>    +-5  Hub (480 Mb/s, 100mA)
>      |  GenesysLogic USB2.1 Hub=20
>      |
>      +-6  Mass Storage (480 Mb/s, 500mA)
>           JMicron =20
>=20
> On a successful try it looked like=20
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> U-Boot> usb tree
> USB device tree:
>  1  Hub (480 Mb/s, 0mA)
>  |   U-Boot Root Hub=20
>  |
>  +-2  Hub (480 Mb/s, 2mA)
>    |
>    +-3  Hub (480 Mb/s, 100mA)
>    | |  GenesysLogic USB2.1 Hub=20
>    | |
>    | +-6  Mass Storage (480 Mb/s, 500mA)
>    |      JMicron SABRENT 000000000000A
>    |   =20
>    +-4  Vendor specific (12 Mb/s, 90mA)
>    |    FTDI FT232R USB UART AM00KE3E
>    | =20
>    +-5  Vendor specific (480 Mb/s, 2mA)
>=20
> Not sure if this is even relevant, but it does seem odd.
>=20

(Response delayed by an OS upgrade mess [not FreeBSD].)

As I understand it USB* standards do not define a stable
order for devices to enumerate. So even if all the boots
worked, if you had a record of the "USB device tree" for
each you would likely find that the trees varied in what
the numbering (and, so ordering) was.

More significant might be the distinction:

Mass Storage (480 Mb/s, 500mA)
          JMicron

vs.

Mass Storage (480 Mb/s, 500mA)
JMicron SABRENT 000000000000A

where the one that does not say "SABRENT 000000000000A"
(less information) is the one that failed. Seems like
it could not complete its SABRENT related activity
successfully/completely even though the rest of the
tree looks normal (ignoring numbering/ordering).

Overall your description seems to be "still varies
based on a seemingly random basis" and the problem
was not fixed by the patch / initial_turbo
combination. It does not even seem obvious that a
long run failure rate would be noticeably improved.

The "SABRENT" aspect might be the only part that is
varying in a manor that matters. But I do not know
what to do to investigate that aspect.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 23 23:32:30 2022
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 4MZ7jc4YKkz4dCn0
	for ; Fri, 23 Sep 2022 23:32:36 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MZ7jb5JpJz3pGY
	for ; Fri, 23 Sep 2022 23:32:35 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailout.west.internal (Postfix) with ESMTP id 8A75832008FA
	for ; Fri, 23 Sep 2022 19:32:33 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute5.internal (MEProxy); Fri, 23 Sep 2022 19:32:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; t=1663975952; x=1664062352; bh=E+34k8gbIi
	h+qFKBuhjwTaDtj625PalWsCeHrJDKuLo=; b=DcUROMCkUHB8INBQXHKM7SqyIg
	2Q//2hNeVozmzuNf6IiD0J3r0Cblwcjf46psfcsyh/XTmq+QMQerjU6McmfzS30A
	+kYSpwMAH8lO21M5vaBp4cRhs7khVQqrfkZVmk3jaU0T1dqD4mYNKLMVjuR+kGkL
	Vh+xO4yVJWZGn1dg9B4H4EK5GnmqnVSr00Z1d/UVyaxqhv9+SXnn0c7oNW0laATS
	1tMkH/IQu+SxlPtmY1fqhLa/jVetCUamxjxKybDEKcmc6yFpqyqhRsBBRM0pIubG
	KUi93ukSr1BJKLWiSTC9pQ8fAm5L/g70VJaqLcwp16NRWMfrUT5hNm8U/Jpg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1663975952; x=1664062352; bh=E+34k8gbIih+qFKBuhjwTaDtj625
	PalWsCeHrJDKuLo=; b=jphpAKPfaZQc7riPP22A76+qJK48jUJPg22b0lN9GWKT
	+vBlvFwEEv9ItDGnWAc7ware2dx703+Bbb6sV5+KtSDpYqORECqDwSdyKHSMe8M4
	r3w6DJ5RvLjKrZR174QmK7zOh3hmgu+dIXXmCgxF3quDsfCZFlWg00sjEkNb99jU
	4qL5YKwgkxpzbqcpQG1pVP1nve1ovE4nmYtpLNJUV7kOfALUIrtBB24E/iqEQBER
	JYA7sS5t4/lPCi5y2icg6cJLCdS/rZ18xczO93Gjj6F5eA2NrCd8thexj1wlIcRo
	UK26JiKXeu10Pi3RZq88OIQOxK2Viz9BIggMuitIcA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefjedgvdehucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe
    ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
    vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Fri, 23 Sep 2022 19:32:32 -0400 (EDT)
Date: Sat, 24 Sep 2022 00:32:30 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Re: following -current on rpi4 with zfs-on-root
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: 
 
 
 
 
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
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MZ7jb5JpJz3pGY
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=DcUROMCk;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=jphpAKPf;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-5.10 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:
>> >
>> >> For EFI, there are many choices. The default installation places
>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
>> >> updates it (assuming the ESP is on p1, and isn't already mounted):
>> >> mount -t msdos /dev/ada0p1 /boot/efi
>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
>> >> If you have a non-standard setup, please see the EFI notes section.

Hi Warner,

On a freshly rebuilt system after make installworld (but before anything else),

# mount | grep msdos

/dev/da0p1 on /boot/efi (msdosfs, local)

There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi 4

bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's 
instructions and copied loader_lua.efi to bootaa64.efi from
/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/

-- 

From nobody Fri Sep 23 23:52:01 2022
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 4MZ88F050kz4dFr8
	for ; Fri, 23 Sep 2022 23:52:13 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MZ88D0X85z3qsc
	for ; Fri, 23 Sep 2022 23:52:12 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id D685C260244;
	Sat, 24 Sep 2022 01:52:03 +0200 (CEST)
Message-ID: 
Date: Sat, 24 Sep 2022 01:52:01 +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.3.0
Subject: Re: U-boot on RPI3, sees disk but won't boot it
Content-Language: en-US
To: Mark Millard , bob prohaska 
Cc: freebsd-arm 
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com>
From: Hans Petter Selasky 
In-Reply-To: <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MZ88D0X85z3qsc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/23/22 04:11, Mark Millard wrote:
> As I understand it USB* standards do not define a stable
> order for devices to enumerate. So even if all the boots
> worked, if you had a record of the "USB device tree" for
> each you would likely find that the trees varied in what
> the numbering (and, so ordering) was.

FYI

LibUSB defines :

      int libusb_get_port_numbers(libusb_device *dev, uint8_t *buf, uint8_t
      bufsize) Stores, in the buffer buf of size bufsize, the list of 
all port
      numbers from root for the device dev.

Which gives you are more or less constant path.

--HPS

From nobody Sat Sep 24 00:35:15 2022
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 4MZ9612YfHz4dL7b
	for ; Sat, 24 Sep 2022 00:35:21 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MZ9602CD4z3xPp
	for ; Sat, 24 Sep 2022 00:35:20 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 5183E320029B
	for ; Fri, 23 Sep 2022 20:35:18 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute2.internal (MEProxy); Fri, 23 Sep 2022 20:35:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=
	1663979717; x=1664066117; bh=zkK+CDCLdegr33rpLEr1dRxtTOZ/EdIYW3z
	uar+zJEc=; b=m0+WQJOwVXv4tWm+1PaJSNexsFez2UG1iof4aBOg+SlfOH6G9d5
	jGcihLK2gb+5LJOnmGe2Tf/1KQfQDgJ1bdolanLtSZAF60rnuQ2Qys+LbTye0qqH
	MLwR3O0CJUPxzxdhSd+Xmu4lZaBpGzVGuHTce8EDI71er8mZMkAP38u9N38sAVwk
	wmPmifvx1eA45kzZ0cib8d12P3A0zdL0+E0T6CqoKdRRL6rMZwqqm5yslB705OP2
	t4P25uKk80x8x1LA2SlYhaj6uR/EUNWE0xTYE8OEv10TD81xgp5c89FxSVUGLH61
	ghnjtCYo7HgD0znm4Pl3FROijEoBYByWxog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663979717; x=
	1664066117; bh=zkK+CDCLdegr33rpLEr1dRxtTOZ/EdIYW3zuar+zJEc=; b=J
	dER5pYEUj9/xZT4JIVDwHgfWOskyIhzIFB+CkK5GDlbKp5xb/jAqeIvmVBuRbnib
	t4/K8OlCaOOqvXAx+3yXzasAEJRLWDEWl0WXUJACDIV5dTAGxrbRXFUegs0oPgYO
	XBqtoEnFDLVsIbSnMPmtLvzI2JpHbUgBCvYp8wZm/gTvCyyPAkJVscJyN0EdhkEo
	gBvfw4FeJ0IIyRKs5smioTpj7KRs3r/LqCsYCNi8leufofNAcCoA9FYwBiWBUyzM
	/D6uGbm72ZWr30FgmAuhrZDpJnYKiWDdkzsV7+hpeJvYhfnGjrFNB3TyrfJyDz+N
	Kf6yhdFdTgnZx44Uuy2LA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefjedgfeejucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd
    dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht
    vghrnhepkeejlefgfeekteffieettdfhleegudfftdejjeetffffjeehueeileekffduue
    einecuffhomhgrihhnpehttghprdgttgenucevlhhushhtvghrufhiiigvpedtnecurfgr
    rhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Fri, 23 Sep 2022 20:35:17 -0400 (EDT)
Date: Sat, 24 Sep 2022 01:35:15 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Khelp module "ertt" can't unload until its refcount drops from 4 to 0
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
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
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MZ9602CD4z3xPp
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=m0+WQJOw;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b="J dER5pY";
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-5.07 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.97)[-0.971];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hello arm@,

I see this just when my 14-current rpi4 reboots

#####
Uptime: 6d9h12m34s
Khelp module "ertt" can't unload until its refcount drops from 4 to 0.
Resetting system ...
#####

The closest I could find to it was h_ertt(4) mentioned in man khelp
This led me to look at sysctl net.inet.tcp.cc.algorithm

I notice that net.inet.tcp.cc.algorithm=cubic in 14-current but it's
newreno in 13-stable. 

Does it need a PR, and if so, where? 

TIA,
-- 

From nobody Sat Sep 24 01:34:24 2022
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 4MZBQM6yg4z4dRl7
	for ; Sat, 24 Sep 2022 01:34:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4MZBQL5mYzz46c9
	for ; Sat, 24 Sep 2022 01:34:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663983272; bh=glCJUlNK463lx3azTE7cXOdH1+Jtf5r0ePFJD78Avb8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XqH83W4QD90iFxlFcNangqtvyTJ9KZsk96hV4kSid+8WiHNhS1dUJ3Bf4iJ3V7cwPp4r3Cn59mkzNcpmg7xGvFTtTyM8/Fb+e/Bv3uMwW1gflX/oYUsc9WjAu2Lh1/YGncnKb2pNHJA1OSNwOOHHjHcGt70XVG66mBGW/zMX7i5BL2BohrRNQqtskRqwM01bPrbEVHW5ebxp1i0wlvBbabrdn3zHzRZywOUM3/7KNc74TPAalR7tm6/nbUjDWaFlBahuW0zY9oW8OK8yLYJjVTDBPaqWBs/vSbMasVbAfh0cXFBkAstXmlALtSIxLeJsJRLHRp9jdW9SpMtYHCC5XA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663983272; bh=NUY4F9AJRBvZECCUatV0DK5xNmM8VPJEXYrkz8SDF4W=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mv88Z1CskuKBqhtrkeiONvV85Orb/sE1vmMrcC7YGi98rQZarX0I1fbaEC4LeAJxsivM00AaVhkr2FCuQt8NUno/w4l/ThETwqN0WOUaf867o0qR3scSE9jePU9YFYV7NgCqrTsj++2x4HkgxTQWOz+YDNLTcB4XiXFcYAK2vKm4gCY5Z6IXhKkjY7PBAVhM52zOLYOGiMc8jtQZq8CGEwq/Ou0tYtZ+6BANlZwk/Q7mKshRSCLuHgH0vSw+cxqSym3D/cWuQ3F7xlLHrO6o0L3YVta81PZUAtzXdcXKYXoaRv2JVAqLo3/xopbyC/oOGvkWuPPcFeVNQX4pCHskbA==
X-YMail-OSG: DIWpnnkVM1mx2wVu545aBgQJRTlZez5VU_pzyHb.S4LVbzS6LTY__uKsVeyHsJ5
 mXkbU55h3poHjs9PzXUvEnBxETE7ekI7PtqE3EpEcl..eefxnEmaGIvfpAxrjZfd20lMqBzj1iZ9
 5ZpPoJGXqtXhm_u16yCRCQWktrCCazIZa5w8YxvyodVrBAnRzGDzUDW8rSgXPD0oc0CbFBZNkEKg
 ypj6sRPJFTRukcjFGlHUGi1f3_NoIiOcYXXn.Z0yEIMrbklRTFCOzi4SaUQ91CZdLIWBShqqAxnP
 Yu5C4IfPHTSHV_lMCYoPbuQwZmNoO_douH8pDNIM.E1L0t3KLY14FrgvQ68BfEfDhSSwqccur0fw
 MKLheO_fUqDDQkvx1kV.IxFVxNGiR5idHcMJDMIn6McSrNu_qc8IgvEo1du40P9_LHcDZ.jzAV5w
 oV.8Va837OllaPEqlyAzuIQhGl3DTUh8kRSXwN3h2JBWoE01uaBOPT1E.EPMggNieAyEMe1.y74w
 csHw5ZeDTODhO1UhlbYe_tnnb.gG9xUTvESYNAYkfNjkz0NjVeBGmK.wkXnu4JaG1uRKQxx_scui
 Hvn_WNsTuA1Mo3_KPd.yYvToB22x5yeJOWe.s3cfxH3l.zlmK_Lkm9MGwVsM7IYXDpHIEaXKteA9
 Euc2bFE.Ufmb_2JsRqsFIku6jdJVIBJ2FowXiFavvYEgl916GNa0cUusy1hUt33QNG7S3XTJZemE
 9o3s_mC9PSKq_C0jkyoP0PIzjcgul4Y6HAbudAdJDepnW9B07TJzMMhJnXaOOt4I7w5OO9IyeA21
 LbOMy8cRxvL0clAHL0LRwF3tbPck2EX0HrELoBLnwpXv9kwkDlJtyfBaaUMAlAxTzgf95_nz2kcn
 tJ9umZC3Y8yldLSURSyO2xExwLpmCSeG_TG.C0yit3JNJjH.zTNK33Zntw39p.dd0k8z7Q8BYTKF
 QK6Ffinms7x782Yy7e9G0h_p_XaHohS58ZjSKFyhVDtvdUxOFzzbBgCLNKhJ4UF6IQRcBxH9rG2I
 oCuUTQL7asiiSTSzEL4qCQxx7JS6dPmpyf.L_NFxsNLzDhPDXd8tjsO_hiI2m2j38z1fXUQj.olO
 GlmkruCFQ.0neRSARIZdf_gnvaePyt3CKYxXTqO_wHkDqiJQtonr749goRkBbKPMEIqLPtxiOZLb
 AuM96t0tDLNbvy81Ci4kaF_SbitlTiAiq1VOYab.67LatUmF_XDm9mTTpzZPmHez4XLdN7xZQSYD
 t.oTClja4KJiWLb7g4o2_rsRSuTxVbyiP5Lpvyp3u0Hc_6QvWQ9TcsBkagcp.PcymvrJ2ne_N7dz
 y7twAZTWSk_fg9steu9QIKtuaxAal_1xzcm5.GMLn6cCqIE9IPRWyry6ViD1Oju7Spi6RJQGAjAp
 sJmVEuSsm58vBSQhV9bQ3IJB54IHdwF4WuP4PeeGAu4QggxZ18hHJPJBKJPCq37EVLWI2CrC4nW8
 LUDP5oMQnabFyABsaIzdbZveGQq3friSzoxQtfeTIe9FrDvtcmsQuauxI.RilYNaIUuBOpMQ8Dvt
 H5tVxM5SbhkPiuKFv.lCyO71gjwrLElr_mQfZCwvpZgurHvneT.2OYtYo0cQ9nyLMPxq_EWsgB0i
 vwawoGukrhyr2e2kx1CV1xPWsqhgr1pnyIHtWUt2RoFAUGHqhoRXVgTptb28Y9m7Ktdq2d169phl
 0I7L5W4peZE2HrSatiM8Ark4iKvmrlfnHdcpL7mKpmG6iz3PVLOdnUF4mA6__p5QoE3ZYVvo.g_y
 8x_0GBXwWG7kbRdZ_Y9mG_ykEZcBMAQmpW1razVuohyHXd.ZDnlIi2TWiF7lblv7OWpksEte4ZhR
 8t6QlkTemgA5BFYfUMsfSwpWX.LWfRO3mtViDQAm4Y1ZwHFlPtt8LBHzSzOHn55o7qWh1TR3ROhU
 4nTqibLGPbr1nof80QWPGs8q7tdMEdthVsi46.B3176hbvlc3d8lLWMRph4up5SK1O85WSJS_c7B
 1pLHK_Veko5BYVBjQNBNMQtel3.QCvclyiB8RsU8mmAmk.bAToHOcVoAQEoiHeQ4emBaXSJ8JZFR
 NXfmSYkHafQ9uhVGSOQKDchisCNpZCnKdidyReJlbstuS6T06l_0LZUAIXVjeOVJ6ZFc3rLisvJB
 xRg2Al13DXhVdz3QyyizucLjd59v3O2fXJn7XuXRwcAJnsX.vB4VgQhKz6BMYdrQKEEMVkLE7RI1
 lvrCNdsZXogHBOXy7teaIS7QOkZvhOyM8jkoBNJwfocSzTCXXvVredURzu2RZgC.anzHtyfRnCFR
 1
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 24 Sep 2022 01:34:32 +0000
Received: by hermes--production-bf1-759bcdd488-njfbl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b89db906b0bee40741ca8c37502ce5f3;
          Sat, 24 Sep 2022 01:34:27 +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 \(3696.120.41.1.1\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it
From: Mark Millard 
In-Reply-To: 
Date: Fri, 23 Sep 2022 18:34:24 -0700
Cc: bob prohaska ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com>
 
To: Hans Petter Selasky 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MZBQL5mYzz46c9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=XqH83W4Q;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@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.991];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-23, at 16:52, Hans Petter Selasky  wrote:

> On 9/23/22 04:11, Mark Millard wrote:
>> As I understand it USB* standards do not define a stable
>> order for devices to enumerate. So even if all the boots
>> worked, if you had a record of the "USB device tree" for
>> each you would likely find that the trees varied in what
>> the numbering (and, so ordering) was.
>=20
> FYI
>=20
> LibUSB defines :
>=20
>     int libusb_get_port_numbers(libusb_device *dev, uint8_t *buf, =
uint8_t
>     bufsize) Stores, in the buffer buf of size bufsize, the list of =
all port
>     numbers from root for the device dev.
>=20
> Which gives you are more or less constant path.

You may not want to spend the effort educate me, as I've no
detailed knowledge in the area to relay on. Also, I've no
clue if U-Boot uses the routine (or related ones).

The original context here was a RPi3B, so USB2 ports on the
RPi3B itself, not USB3+ (in case it matters). Ignoring that
for the below . . .

Looking up the routine at:

https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html#details

I see the description:

Get the list of all port numbers from root for the specified device.

where:

Parameters are:
dev			a device=20
port_numbers		the array that should contain the port numbers=20=

port_numbers_len	the maximum length of the array. As per the USB =
3.0 specs,
			the current maximum limit for the depth is 7.=20

Returns is:
the number of elements filled
LIBUSB_ERROR_OVERFLOW if the array is too small

But the original device trees reported showed:
(unsure how well the text and its whitespace
will go through in the trees)

USB device tree:
 1  Hub (480 Mb/s, 0mA)
 |   U-Boot Root Hub=20
 |
 +-2  Hub (480 Mb/s, 2mA)
   |
   +-3  Vendor specific (12 Mb/s, 90mA)
   |    FTDI FT232R USB UART AM00KE3E
   | =20
   +-4  Vendor specific (480 Mb/s, 2mA)
   | =20
   +-5  Hub (480 Mb/s, 100mA)
     |  GenesysLogic USB2.1 Hub=20
     |
     +-6  Mass Storage (480 Mb/s, 500mA)
          JMicron =20

and:

USB device tree:
 1  Hub (480 Mb/s, 0mA)
 |   U-Boot Root Hub=20
 |
 +-2  Hub (480 Mb/s, 2mA)
   |
   +-3  Hub (480 Mb/s, 100mA)
   | |  GenesysLogic USB2.1 Hub=20
   | |
   | +-6  Mass Storage (480 Mb/s, 500mA)
   |      JMicron SABRENT 000000000000A
   |   =20
   +-4  Vendor specific (12 Mb/s, 90mA)
   |    FTDI FT232R USB UART AM00KE3E
   | =20
   +-5  Vendor specific (480 Mb/s, 2mA)

without rearranging any connections, if I understand
right.

Both "USB device tree"s have:

1's device (a hub) contains 2 directly.
2's device contains 3, 4, and 5 directly.

But the correspondence with the devices
associated with 3, 4, 5 is not the same.

I do not see anything in the libusb_get_port_numbers
material that would imply they should be the same.
Any permutation for the correspondence of the 3
devices relative to the numbers 3, 4, and 5 appears
to be valid, even if it varies from power up to
power up (for example). Just the set of numbers in
the array {3,4,5} is observed to be invariant as I
understand.

May be something in the USB 3.0(?) specifications
nails down such relationships. But if it does, then
"2" is not behaving correctly if the numbers 3,4,5 are
port numbers.

Another possibility is that the numbering in the two
"USB device tree"s is not technically the port numbers
but some other form of id-number, possibly U-Boot
invented even.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Sep 24 02:29:33 2022
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 4MZCf22M8nz4dXtJ
	for ; Sat, 24 Sep 2022 02:29:46 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 4MZCf14rm8z3FDj
	for ; Sat, 24 Sep 2022 02:29:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id m66so1607623vsm.12
        for ; Fri, 23 Sep 2022 19:29:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=0/AluCsE2CJ8xV81aDrvH4mP771VMA3mhblUpWZ9Q5w=;
        b=XgAoQSgeSL5mDyqYFdlNVs9ZCU1iewtVUduROszNhy52RSTMi/VgziY3Tyz8RuG7nm
         Eqn8lw2Yuoyj9mx7ArMm0m0JHaOyBdMXobE0jD7ncRqbuFytaOqlUDzTmaUcfjk6Tqqz
         es+eBFoKxwuNrNQO2wC+nDtJeDmjo73o8Wnw/L8jIRpRMpXZi07dvc60kkINR8plqd3/
         eOGSBBTncNL1UgUPZFItxErbtbl7QzAoOYDXlyRYZrjN7We+faHZ7vk2naRV9CAL4rsV
         3G8CPwIENBr2+TDtbPAQ8iD4uCi8hUKwxJd8zWnoIoPQlgzNiwsKImdwhbyQ7HHEcuiB
         TNWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=0/AluCsE2CJ8xV81aDrvH4mP771VMA3mhblUpWZ9Q5w=;
        b=SAZaaXLKuuT48od9syIVly8Ddvvz097sJ/5leQHMijecKYqHFyNjw/hHuo4+PpZ99V
         d5dXzBqoI8em5PmoVTfVT/59iCL+iKVENf9CVj71cAL//zF4tnuA+2jY4/aGulWoEIBu
         7Pi0cqBiMn4RkVb/yjGb0n7nlS3SOoNIBsBiLtocjpJ1eJxPIypXHLVVK+YnMWrVUSRV
         I4hMKMQ4DAmLTObcC1H2Q2GjENAMcOTc23tkUoXby72XjddlUEx9/VD6Q4m1Ok9AI1A7
         uQRQGj6vdsLEJ43slgMNoxnNKPxqvDxSPMYjw5Bkm+yO10xwc5nazofw/N+fbdYYjkob
         Re0g==
X-Gm-Message-State: ACrzQf0yAauUvff9wxEFSGnsKyw48KZa1SbaD3mdNjEViI9IgtESY9jj
	DKAZDrEIRAWvH010n1HWQauLvrVW8B+o6FvIjC/DEb/g6gE=
X-Google-Smtp-Source: AMsMyM4/aQgp+VGSqxl2VgIjTNa7D49nn1is0mxgKFur1nE4fIxGZ8Fdh/s8eKILHgVx0xlrnFZOJ6Rxwu9hKA1UOT8=
X-Received: by 2002:a67:3c7:0:b0:39b:45c2:6875 with SMTP id
 190-20020a6703c7000000b0039b45c26875mr4352390vsd.6.1663986584545; Fri, 23 Sep
 2022 19:29:44 -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: Fri, 23 Sep 2022 20:29:33 -0600
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
To: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000048829505e9631107"
X-Rspamd-Queue-Id: 4MZCf14rm8z3FDj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=XgAoQSge;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000048829505e9631107
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 23, 2022 at 5:32 PM void  wrote:

> On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:
> >> >
> >> >> For EFI, there are many choices. The default installation places
> >> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
> >> >> updates it (assuming the ESP is on p1, and isn't already mounted):
> >> >> mount -t msdos /dev/ada0p1 /boot/efi
> >> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
> >> >> If you have a non-standard setup, please see the EFI notes section.
>
> Hi Warner,
>
> On a freshly rebuilt system after make installworld (but before anything
> else),
>
> # mount | grep msdos
>
> /dev/da0p1 on /boot/efi (msdosfs, local)
>
> There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi 4
>

Doh! I let an extra '/efi'  slip into my directions. /boot/loader.efi is
where it
lives on the host.


> bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's
> instructions and copied loader_lua.efi to bootaa64.efi from
> /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/
>

Yea. that's what gets installed into /boot/loader.efi

Warner

--00000000000048829505e9631107
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Sep 23, 2022 at 5:32 PM void =
<void@f-m.fm> wrote:
On Tue, Sep 20, 2022 at 02:36=
:02PM -0600, Warner Losh wrote:

>> >

>> >> For EFI, there are many choices. The default installation=
 places

>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The fo=
llowing

>> >> updates it (assuming the ESP is on p1, and isn't alre=
ady mounted):

>> >> mount -t msdos /dev/ada0p1 /boot/efi

>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd

>> >> If you have a non-standard setup, please see the EFI note=
s section.



Hi Warner,



On a freshly rebuilt system after make installworld (but before anything el=
se),



# mount | grep msdos



/dev/da0p1 on /boot/efi (msdosfs, local)



There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi 4
=


Doh! I let an extra '/efi'=C2=A0 s=
lip into my directions. /boot/loader.efi is where it
lives on the=
 host.
=C2=A0

bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's 

instructions and copied loader_lua.efi to bootaa64.efi from

/usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/
<=
br>
Yea. that's what gets installed into /boot/loader.efi

Warner


--00000000000048829505e9631107--

From nobody Sat Sep 24 02:30:14 2022
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 4MZCfm20stz4dY0F
	for ; Sat, 24 Sep 2022 02:30:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4MZCfl2P8Xz3FLW
	for ; Sat, 24 Sep 2022 02:30:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663986621; bh=hjdYHyKmNcFarL0dTyM0qRnr+K6LzAku17/gfMf4sZk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AyqQXP8/55LzaJoORNIjSymMrLGPHia73xceMAO0b4dUUIWPb1OxfZv2wQ+FEZCh+I5qe1ifXamK+eE/nkJ4HLo8jzHaNcrXVbq1TJ+ipWOF3iy9F4oj/4WTYhfDCIku+qIYMT9Au7Aaq5EDrQGriqjJLn1kCPhf5hG5bOtY8tOj49WUZmTGZO3Mhjon/SUkSnbYWEGgNQpw79J6q7RmZ1QiaFeIPpK2S/wznZtYFUTw/fmTgiD0cPRjciKGuApaQCZxznvU1EFa5uCk2R3JTTYfbmnkb8Np8gX3FIQqV3coYPM4S2Kdqxry+41LNNCkTFyhypQIxb8I/cjiXs5COA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663986621; bh=ZdQlktypVayC/hzwX0ybmWZzsXWNavmUlBH3aZDPOnW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XrlbITrWFlR5rqfGfnfA7RnEvRrqkJh4YgHZYuwPFihCTvG40d8Qr1xocJLOX8APFQg/Aw8hatlCqNJj4WvLkOhy0D9Qd8v1Ss3BhoNHoUdyUWfMe5pEBE6I1fjcQbD/VNBNCUGSvuK3rq8qjVcdfc+GGq21iGYbMWxeuGmZWoTQTAFYI5k73gluWDFtvhs1TOZzh4LUSBJEBdjEl1RCPz4sWE0L11s/puaUJ7I0YUS43XjVxVog1u22nvlqzcks70HxJknNyGj0k/7HCfkk0z/Av7UEvPdRIs72w2MieXO2MVrC+YiDw3KImy9rRWu9gwO/3upuQ229tYEMmYUXcQ==
X-YMail-OSG: eAj4QzQVM1mAQqNUerSRZuscU9jZBFSX1RdVZKF_eXTkm8JvDxWP2d6VjSVD8dM
 QXVg2FrrcnMws.cIRlcGsGMO5Vfir_FGZXgbrSoj0Kmbf5C.3Q8Yy4KtTsixK7D1v795Q6bq5bVt
 0toaYDYYl4l9amM1cHzlChSkdVZNo.yoUfnuPNl7gqKWbI1B7CHW4VhaJ333MZnFxgVriUX.2MKr
 wB2QPV.JdLbV143lLb8_siCC0quLz.iNgZVYs.aIQLUJ1ej5bRq9YpCN0Cs_MkcGP8VEQ0.LLIDa
 8tN5_63_XYoKpR2svU85Iykw1c6DAOefSrxv5XOcLeWZXDNmJDxfc.Z4SE68w1PmMgZn.LhAXU8p
 d8oVJp4s_8sZGs1SZ8jnZs7e0z0jlL8lbCREbpiGgx3zJ3scfLRgE9TGKlMH1PS3FeOzrtEQeOAw
 x4Jlc4TWf.sRz5IZI37XeaygWxEW3Lm2JUJwEIzAEFfNn2RDErSunTo7YX_gZBzdzhIGbxL6MJDi
 I5HaEhD543w4m3ZnCDp2UUfEwJV6.v8ey7DY7SenoA1sY5GLY7Zffqr6uEEO.Rk3.yxd5fpVAuBC
 UlQwYEhFflacMFlyTG7gFJ6wHm6jh9fZj.iSQ65Zfq5W5XeL2is1_Y6ip4Pcg_JPHq5D.I21_bDd
 209hJJkdjnYeiB6p6WxNaEIyCKwWE5lPPkCDR_DegiuaKeKIA_FFb5zjglO6h5izUw.8IJ6CwFWZ
 G0nwrdkj9p4TAfFFCQArOYp15m2.kcBXv3.CmcsHFknir_y7GfvgvvQuhTDuIyBUjqwy4Wli0t8F
 MU6EUlwFwzmwpPWKlBZbbxkiL9xc2LkrE3vInf.cZeYQWrqo9pN_OhKp837R17FkD9dzZ80DkEc_
 Y4Ok2IA44XuyH9w8svTkb2AmXGwPbka1yCh.ydy3tnip9shNm_.MMqLqXbYIsW5JmlU1.9oauo0q
 BSTii2_K4KAPpIjk7mWn7lKbY79HCw_uxHaQ9IumX_E_uY1sfesIhIVFNly4kKmBlbWfHlElSfot
 Jx7rJXaSNREhztYgs70ry_v..wKxg8CiBun6moWS4FEZB4cTS5p3q5UdZUENXYtlCaonRysCxyfh
 PI.6zvbQLbr4eVdGIRLUXw8Dphf.4czbU8Ppi_D7o23_IOS9oUqYMUYnnPWzZsFwszVFzBVmdPRu
 h0uLYn_QJK3xjARzo.WUIjc.Jrw6CWFGktIjw8uIUewfV1p2XoajD5Tou.emgjWKtYK5xZcYS.Rc
 pWBSINF_aFKyhQdpv_K.tLYTizrD.E6MLjUqDBprserisYl30.XpSq54tr_2CDpBNro_RK0hq.87
 L.ei_J8_3s9ridJSk.uKyfdOsSy29JDmD728q4Q.zs_w99XeeDFc4F7m3sq8c7Avhn6LkZPshPhP
 ORyHSGvByi4Okra_mCNrRL_UFFsIJkp34gN4NfcWxi1udwVTiGDwmGoV_kAsqVm863y1cw6aGMrd
 6coxA6Vo7qrsGRyABN0y3kqxXnOvp3QB08z86Ax0i2jPNojFz8pyZdU88_SU84EjXwKxi_VtJ2lZ
 mCdJHvtXFpXoeZBqOOlCCJn81jnQIxYgt30yQsP6fWfv0qA4DMvaSmuoGvfX3Ku.44PXClUTiDXE
 Fm4rk3EWPVqAQz1ThvkCPQ8jkpgwvxUeGu.1TkDDFw6xUJ5KV9qNCaFe3VQXijc_6MaXnbJYttP5
 Edg.Utb1BTLsLq6PsbRJEVPJ4jZsOo7XO.S6G7sYGOCrQoe8DmtsB8ZNmuR05nqxT7IFzG23ZlBZ
 t5F9HcjFZRE7WolZKR_QsKTFazpMsqKOxHhMyGP3Tta4_6yw5m.qk9.shFs80o.fyeK5X_o1B7aT
 YPDRHm6zajcOecVym.FpxK1BCh3iuLhFMaTCIow8Vadra3icL4cuuYjLcCInauG0.KaHb6qSPC.2
 tZVeWAvHC0.9ynweiqVG8jhmszFAdB7UXBP.jc6VKNBdSjiExu7SaruFo2ct11TIURDE_qwLO4Kg
 NvsBz3HwRItAwEbvzZhXZDo0HOMinDqlOKeQ0JxrjdEgSc44tU9gN2PGxVvIeMK9_a7wpSeqXpCl
 qicSibcsgcXphtsKsri7S4Ju5Vybpi322qJvh7I1hOMi1TRozxHPaKBN5i66yNUmfDj1AXI91YRv
 fwyENCVo7_p8.VzjdesuqESw148WSRh80vn0109i82.8yiBt_wccX7YLd8ivBoMgXEACT2v4dCnm
 PwWo1o1IZLffuO4e57KLmYls0liAz32rlC2VoUxVJt_fqynbwdGOQ_SBdwgUq9vnPFhJrfcI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 24 Sep 2022 02:30:21 +0000
Received: by hermes--production-ne1-6dd4f99767-4dqfp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3d09c4f8621c5b958be7e8b8d3652fb8;
          Sat, 24 Sep 2022 02:30:15 +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 \(3696.120.41.1.1\))
Subject: Re: following -current on rpi4 with zfs-on-root
From: Mark Millard 
In-Reply-To: 
Date: Fri, 23 Sep 2022 19:30:14 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
 
 
 
To: void 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MZCfl2P8Xz3FLW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="AyqQXP8/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[f-m.fm];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-23, at 16:32, void  wrote:

> On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:
>>> >
>>> >> For EFI, there are many choices. The default installation places
>>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
>>> >> updates it (assuming the ESP is on p1, and isn't already =
mounted):
>>> >> mount -t msdos /dev/ada0p1 /boot/efi
>>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd

I expect that should reference ( unsure for EFI vs. efi ):

cp /boot/loader.efi /boot/efi/EFI/freebsd/

The point being to copy from ZFS/UFS to the ESP
for environments that use EFI\FREEBSD\LOADER.EFI .

-t msdos vs. -t msdosfs ?

>>> >> If you have a non-standard setup, please see the EFI notes =
section.
>=20
> Hi Warner,
>=20
> On a freshly rebuilt system after make installworld (but before =
anything else),
>=20
> # mount | grep msdos
>=20
> /dev/da0p1 on /boot/efi (msdosfs, local)
>=20
> There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi =
4

So far as I know /boot/efi/loader.efi is never the right
path for ZFS, UFS, or the ESP under the msdosfs ( given
mount -t msdos /dev/ada0p1 /boot/efi ). /dev/ada0p1 would
contain an EFI directory that has more substructure.

> bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's =
instructions and copied loader_lua.efi to bootaa64.efi from
> /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/

After the install world, cp /boot/loader.efi /boot/efi/EFI/BOOT/
should work as well. ( /boot/loader.efi having been updated in
ZFS/UFS. )


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Sep 24 02:31:56 2022
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 4MZChp6Gblz4dXvD
	for ; Sat, 24 Sep 2022 02:32:10 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936])
	(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 4MZChn6NmNz3FtM
	for ; Sat, 24 Sep 2022 02:32:09 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x936.google.com with SMTP id p89so683459uap.12
        for ; Fri, 23 Sep 2022 19:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=Pt1arvzSINBKrawn3tDAXjbHq3LqhhmKtqtfBQ7zFZU=;
        b=tNiY4sUfcfiJRPfHYiDmF9nA/Jk1wakxEQpdIoCXwIFsPcazp/Y7K699DOLCrP+f06
         X6NL0eyAbVPTOSQ3D4OgvMuGdJI0XfHcKDyNZj4GFZTtpxbLqAbFJeODHZd99zcjluHn
         sWIdJmon02tIypIfy4sUvfEogucAQct7jBqrI5PTCilca7qDY5Iplyd92id/J+uxZzf0
         dDCEpYOnbPvPlSz7XejyCQLA3nWqv7XDrPiPFgWEYnXIWrAObqeQgjbW8j8ocKZEtHof
         o18e50PEPYTY4NktIf4GppV+BI3UOUfMjNJoSsGgke8YiZ/pDglu0roRckBFCsJJ8tvP
         pjTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=Pt1arvzSINBKrawn3tDAXjbHq3LqhhmKtqtfBQ7zFZU=;
        b=EVapnnDQveQZ4TkRDbfRRMIWf7t4Mj9iakhZ03zmVowM8Yw9/9cKQPQ3WFQFRVuqb7
         JAwzNdibPPg0X4PLZHzp6ckTq2KcVqjA+bfpdxfBefQCdGQofg+VG0dqWvnvWrTQOQm7
         HwignvLNwhzD9OpcMRQWmJyY3kBGQyk635HfmPvtwLLqMJqtFGpMQLGac6FHQ3aLBH3T
         9u5G9iPl3zXaayhwUeEogPfAK+fQ0n2sSxLWEr5FuWDCrCR1BN6vyT7gyT5ZUg0heLgr
         Vs32qyPHMTAn9BthdqeDWVksnKqrvs8iefUd/Cnd6A8SpGrwUfVhsUYyk4NHz3J4Oiw7
         LeXg==
X-Gm-Message-State: ACrzQf1ew3cAW78MlrnH3y63pOCdujGrm9Q4UcO36PCSoeXi/alx7ERz
	WkIww9MsuwOLQznlDA/eD6kFGuNG4AZpjjPBDFqB1Q0RV8E=
X-Google-Smtp-Source: AMsMyM4oGns5oEBCEeuRXtl2TvmpXeLMdo8U0zpqK4e0oHIRJapQILOgc+OupP6EWaqaRX/hZIOuFd8gNHK/3ix66Fc=
X-Received: by 2002:ab0:70c6:0:b0:39e:ed14:806b with SMTP id
 r6-20020ab070c6000000b0039eed14806bmr4736198ual.82.1663986727093; Fri, 23 Sep
 2022 19:32:07 -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: Fri, 23 Sep 2022 20:31:56 -0600
Message-ID: 
Subject: Re: following -current on rpi4 with zfs-on-root
To: Mark Millard 
Cc: void , "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000c79fb705e96319d5"
X-Rspamd-Queue-Id: 4MZChn6NmNz3FtM
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=tNiY4sUf;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::936) smtp.mailfrom=wlosh@bsdimp.com
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)[-0.997];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::936:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FREEMAIL_CC(0.00)[f-m.fm,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c79fb705e96319d5
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 23, 2022 at 8:30 PM Mark Millard  wrote:

> On 2022-Sep-23, at 16:32, void  wrote:
>
> > On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:
> >>> >
> >>> >> For EFI, there are many choices. The default installation places
> >>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
> >>> >> updates it (assuming the ESP is on p1, and isn't already mounted):
> >>> >> mount -t msdos /dev/ada0p1 /boot/efi
> >>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
>
> I expect that should reference ( unsure for EFI vs. efi ):
>
> cp /boot/loader.efi /boot/efi/EFI/freebsd/
>

Yes.


> The point being to copy from ZFS/UFS to the ESP
> for environments that use EFI\FREEBSD\LOADER.EFI .
>
> -t msdos vs. -t msdosfs ?
>

Both are valid. There was an unwise attempt to convert everybody over to
using the latter, but too many people stubbornly used the old style that we
left it as an alias and deleted the warning... :)

Warner


> >>> >> If you have a non-standard setup, please see the EFI notes section.
> >
> > Hi Warner,
> >
> > On a freshly rebuilt system after make installworld (but before anything
> else),
> >
> > # mount | grep msdos
> >
> > /dev/da0p1 on /boot/efi (msdosfs, local)
> >
> > There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi 4
>
> So far as I know /boot/efi/loader.efi is never the right
> path for ZFS, UFS, or the ESP under the msdosfs ( given
> mount -t msdos /dev/ada0p1 /boot/efi ). /dev/ada0p1 would
> contain an EFI directory that has more substructure.
>
> > bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's
> instructions and copied loader_lua.efi to bootaa64.efi from
> > /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/
>
> After the install world, cp /boot/loader.efi /boot/efi/EFI/BOOT/
> should work as well. ( /boot/loader.efi having been updated in
> ZFS/UFS. )
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--000000000000c79fb705e96319d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Sep 23, 2022 at 8:30 PM Mark =
Millard <marklmi@yahoo.com> =
wrote:
On 2022-S=
ep-23, at 16:32, void <=
void@f-m.fm> wrote:



> On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:

>>> >

>>> >> For EFI, there are many choices. The default installa=
tion places

>>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. Th=
e following

>>> >> updates it (assuming the ESP is on p1, and isn't =
already mounted):

>>> >> mount -t msdos /dev/ada0p1 /boot/efi

>>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd



I expect that should reference ( unsure for EFI vs. efi ):



cp /boot/loader.efi /boot/efi/EFI/freebsd/

<=
div>Yes.
=C2=A0

The point being to copy from ZFS/UFS to the ESP

for environments that use EFI\FREEBSD\LOADER.EFI .



-t msdos vs. -t msdosfs ?

Both are vali=
d. There was an unwise attempt to convert everybody over to
using=
 the latter, but too many people stubbornly=C2=A0used the old style that we=

left it as an alias and deleted the warning... :)

=

Warner
=C2=A0

>>> >> If you have a non-standard setup, please see the EFI =
notes section.

> 

> Hi Warner,

> 

> On a freshly rebuilt system after make installworld (but before anythi=
ng else),

> 

> # mount | grep msdos

> 

> /dev/da0p1 on /boot/efi (msdosfs, local)

> 

> There is no loader.efi in /boot/efi on arm64.aarch64 for raspberry pi =
4



So far as I know /boot/efi/loader.efi is never the right

path for ZFS, UFS, or the ESP under the msdosfs ( given

mount -t msdos /dev/ada0p1 /boot/efi ). /dev/ada0p1 would

contain an EFI directory that has more substructure.



> bootaa64.efi is in /boot/efi/EFI/BOOT, so I followed Marek's instr=
uctions and copied loader_lua.efi to bootaa64.efi from

> /usr/obj/usr/src/arm64.aarch64/stand/efi/loader_lua/



After the install world, cp /boot/loader.efi /boot/efi/EFI/BOOT/

should work as well. ( /boot/loader.efi having been updated in

ZFS/UFS. )





=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--000000000000c79fb705e96319d5--

From nobody Sat Sep 24 03:03:34 2022
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 4MZDPC488Pz4dbtd
	for ; Sat, 24 Sep 2022 03:03:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4MZDPB0p3mz3HTr
	for ; Sat, 24 Sep 2022 03:03:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663988620; bh=7zfmwiHJcfpK+613tAhecThhu7xkS3i/zYhqc0HtXxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QW924nrZdN6rLpiyKB9CP519aM12KkYzbx0y0wGIEyse1uCbZepI7bleKAIH+C/VD1wZEcDQAsZogv+EII7212++qzeTBRXMAIRGiC0MejNpswXSHFt13c/UT1QcdoFOV1aUeQkXGk9fs1ELsL0rrLQ9hfGGnkbObtI+L6NoY3/HP6cYy5WYhuc2MKtdngE/WUfszV24hkG7BlnUYHqZtVMWgem9jVFkEXrc5YmLlq6F1/91QvY9vYhEJ1oTx8rHLO9H/insRVLyTDUPUlBoOWfVVzE730emtGOoby+bLATR/RQSl7asbosvQ5nkDeGbKSpnSKMvo3QKx5ZmWy2E6A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663988620; bh=1DrI8RwdEbsHx1dzDgZptaS8bioN64R5N8ioaGWSxlj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mBKE2Q7TlBEv9BXjV/eteCOEq0bodzABq/F87/eXC9ged5AlKTxmNVZWlJt0tKXZLhkCKCT8d76fteFve73kWjBnYcGeIseafeooiOX/XcpbvbcaRy9YjUoNomOyH8SeMzsNza8lWH80P/ZWEuGnywGNO/YwKeOtTOTY5eU4n/xt9A0ygpX+FOUMDyKb0gBMf3cplvigs0dhY6bu2NwPDEBo2tGZ+RQQg/0LlPM9mUQFJPNq2OV/kuHpxTcIzHzHVPh927hUvTzDX0qHA7EFXckgD1J22V9690+jfq6v8qqsuyFEiZ/CRS9nBWn7gUDbM5TqcQzuDJpi8HQMwIzE2w==
X-YMail-OSG: lCM6ZwcVM1kxQYlB6Tx8VeQZJ8_En0.NWYul4t9AMCaDI.k7SP1muaD4YFII3hk
 0eiIhbXUST3tHXxdr3HXyE7EQ4C8fNOt9_kKV5Q7eRweTbpkLmP2vvN_QKP6zcnRvI9Eci6SdAwS
 cD5LqVMtDuQBUcB7zqtdx9699sykXkl7yqfH2FILyhXomqPYGp9nkIYpDa445h0t18qNIaIFylf0
 rVqd0DbG.0nvYYSsNIQoVtm7kXsFeEeKz2ZimexxX6CCQxcO7BMgKJCH84ytEeIy7wA2LSs9URjh
 iOMWuVVNAb32qG75hD86qB2W7.2ZEo4QwQzn2pia_eLNPXVGj.i42Nuc87lsDu_n30Rv5o4FNjI5
 7P4S8.l0pDL9JQ54jj021kYBh3ioSg588uUO36O2oHgW6h6Fi0M_aaEG8kraKuZ4.ncmpt199qCA
 HA3h62rjHhDWhTjK.MjgBShY8WNT5LO07mIgrpc7P2FP41YjZRrSmDXaN_3T9qm6LgJT4.jtQLVI
 ptziXZYyUZCFxLfSI6tSdANXr6aqDZikA8tdtj_30_DCSW75vWHN9pZcFSe98XtpPEN1VSnX7LzB
 ENyVTbLl1UCux9_97TQWVgzQaklHaVnPyjmr7_UuRaoFz6mBfVuIIA8OhDUWivcZZSx5ZLlcPxmJ
 bDyobjc0ek9z1k5edhrZoqHkUiTwE9MQmcWpoBaQ0ZavMEFxUsTp4AnRxuOy2OlEYl4hUFi9xStD
 bST9wfRYJKPJpZDUNgOAYUm7it8m9XzsDqef6qc7_SKqC.YlLUs3_Gy3TYOPtEiLUUKJqErR6AHm
 aTqzzPTulP6cyGURv3quaxjK_jDSZAoYWtt89Qcjs3IOykzwZRyMNdgRZL_nJGITim.lwy.jnoiX
 344UyGji7._yFSxjrQC07ylMKj0ZwPTduedrLin7_GlJsL4y4VnuVRzn4Ox37iR3.uYXSuk1kqTM
 V5c.t2tXoxL1AWoMzXli0MJdzV8IYcioF.Gn5xjv_x4aJdyfQfnntrhZoJa53FRYPyXqaP.l_V08
 HP7NhtSieZjdz8sQ5RRBEpVEV7czBsC9BhG3f6BbcZdSmjVYvW4JSFVJSnKCENPp1D8NeZp7EEI5
 yisng0jlQRGhEGLyhGAB_8fvQ42BasvK4B64Rs1KB02ploSv.BFCCajrRGCn7JrPZbmuTrB8GBGF
 yTW30XQZkemKJi17TwMPiIsEl0WOTnauU4Eoalk1ui_RV9fv9YtDE.ETJvG_DMdJSg1cFwlAv38T
 pWgexHGHD1u_fLcRfAWqWaN2v9g15a.bz3HvpzwJspKQskLFuENYLY6IhKKmFofuyCrFhjLeHcGv
 ztJXS9wjcwkFdHYq81ikUpIqHCAeEfPZObc2YiBDbToILlHxCtIOPvGtdmMKKf1Kake.HXSwjyQ3
 oLu4cNy9ic7g.VzKXiKc989KzJGxRtFxeV9vK2b.zRP39yYsZNcq0OBS5GY_HzNJaNC0mSUigh7K
 AmnZOmKcwvE5DckY2WwNOJhC3yLAAJIeT160OC_Mho6pE81EK0h04kNBNsIsuMW3A138fN6.gYwo
 7_3jsrXvhK6zTknm3FXQfb_PyhhRrz61aMIj0l98sSN97UO_DuIELwsrjOV591TGtdJXRQ31mzpo
 pvuVlNMX5wLbEQFuRcLUq28LuOz1IqV4.SAf5TpO2_Ox4onRA3TwFFWWXtIE3pW1PBey8WuyJ2nT
 8r.Iflhk58zux01DJ8nQL7N2YsqdUVfQq4eqtfLkgwsAvZJmvT8WN6zWx_N8TR.TSRqiXetmgJeb
 JSEIlPoE_ukYa3DUqypUU3XlPoMg8rYrtHOPtaNGZteQpIlg8yr6BdnBpqbfiOO6ME3H9s17hWaQ
 GX5LDAI8X9rAzwW3eEyvv8I0r_K92YubhPbDDHLu.FiUMCfCOAqohqoWbyHd3eXON2ActO8Nf0h_
 xUUSWabQuwMO813JDgJ5hJFKvtZiGrvte8ABqiFrJbYZ.FxEeF0FzDaGK9Tz6QwCGe3LRRbcZZoJ
 7_DOPfUoVZGo9GaKEtEdlJzUgVc8xrAA__amN10FRd1U1puU07dvu6EC8vKOdPDpD1YPsjQLe0t9
 VTKPe7nG2ZzkUcGkiAqfQTsvjrpt86HHA_2XNrBRM1obdVi3D1AdHSOwj.NSIN052n3_e4HywRu8
 1BntT_LB01vvO497FLl0giHWmxMkNdgK_0WDE4DYCqUmrM949N8zoIQgJWG2T_S7OgVKoux9hccx
 _eS.DeG6Z7Zj5XDCFlji4dYF8LmROGHqmzIKINnyu.al2lruOYuH5L_nzc63lk5ACo47l
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 24 Sep 2022 03:03:40 +0000
Received: by hermes--production-ne1-6dd4f99767-4nkm6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d1bcd990ebccb72207bf2e945116314c;
          Sat, 24 Sep 2022 03:03:35 +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 \(3696.120.41.1.1\))
Subject: Re: following -current on rpi4 with zfs-on-root
From: Mark Millard 
In-Reply-To: 
Date: Fri, 23 Sep 2022 20:03:34 -0700
Cc: void ,
 "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
 
 
 
 
 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MZDPB0p3mz3HTr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=QW924nrZ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(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.206: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.206:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[f-m.fm,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-23, at 19:31, Warner Losh  wrote:

> On Fri, Sep 23, 2022 at 8:30 PM Mark Millard  wrote:
> On 2022-Sep-23, at 16:32, void  wrote:
> 
> > On Tue, Sep 20, 2022 at 02:36:02PM -0600, Warner Losh wrote:
> >>> >
> >>> >> For EFI, there are many choices. The default installation places
> >>> >> loader.efi into the ESP in EFI\FREEBSD\LOADER.EFI. The following
> >>> >> updates it (assuming the ESP is on p1, and isn't already mounted):
> >>> >> mount -t msdos /dev/ada0p1 /boot/efi
> >>> >> cp /boot/efi/loader.efi /boot/efi/efi/freebsd
> 
> . . . .
> 
> -t msdos vs. -t msdosfs ?
> 
> Both are valid. There was an unwise attempt to convert everybody over to
> using the latter, but too many people stubbornly used the old style that we
> left it as an alias and deleted the warning... :)

"man mount" does not document -tmsdos but does document
-tmsdosfs . Thus my confusion.


===
Mark Millard
marklmi at yahoo.com


From nobody Sun Sep 25 16:05:31 2022
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 4Mb9hv3zZ0z4dYtB;
	Sun, 25 Sep 2022 16:05:35 +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 4Mb9ht1Tqvz45dJ;
	Sun, 25 Sep 2022 16:05:34 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28PG5VgN063330
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 25 Sep 2022 09:05:31 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28PG5V70063329;
	Sun, 25 Sep 2022 09:05:31 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 25 Sep 2022 09:05:31 -0700
From: bob prohaska 
To: freebsd-ports@freebsd.org
Cc: freebsd-arm 
Subject: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
Message-ID: <20220925160531.GA63213@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
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: <20220922014500.GA46697@www.zefox.net>
X-Rspamd-Queue-Id: 4Mb9ht1Tqvz45dJ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-arm@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
> 
> After setting initial_turbo=60 in config.txt the first reboot
> found the disk, the second did not. Running usb reset then
> found the disk, but run bootcmd_usb0 seemingly caused a reset
> that  _then_ found the disk. 

It looks as if u-boot is somehow restarting itself unexpectedly.
This is an RPi3B running stable-13, system and ports up to date
as of yesterday.

Here's an example session following a failed boot attempt:

U-Boot> usb reset
resetting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> usb part

[I think some information about the disk should have been displayed]

U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700)

DRAM:  948 MiB

[...usual startup output]

Are there any debug switches for u-boot? I've looked a bit and
what I find is either stale or not implemented. There's a reference
to a "log" command, but it does not seem to be recognized.

It does seem clear that the presence of a timeout file makes no
meaningful difference. Boot succeeds rate is less than 50%

This is using an unmodified u-boot-rpi-arm64 built locally. The
system has no microSD installed, u-boot is started from the USB
disk (which is found by firmware without trouble). 

If setting up a microSD to start u-boot alone would simplify 
matters that seems worth a try. Hints much appreciated! 

Once the machine boots into freebsd it seems to work just fine.
The problem appears to be with u-boot only.

Thanks for reading,

bob prohaska


From nobody Sun Sep 25 17:39:23 2022
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 4MbCnG6vG2z4cWdC
	for ; Sun, 25 Sep 2022 17:39:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4MbCnF68P8z3FH9
	for ; Sun, 25 Sep 2022 17:39:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664127567; bh=OF3x2Sz1DSm1y9JkBTy6doXqcbvGke1YfnudzIk6kPU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Zg6R0iFvFvAzuGpbGoSq1n6aqmgB7eNC9KcjKz+/1s4Fyk6Q5AAS7O9v4j8JudHtgexsLAIO/bn/2HZHNBYHWX0pWgtv0x3/YEAtsA7FfuYODSDmHvoIc5qkrc2Gv5gsDTdw/m9M3F41yvDe7MK9aLsodnT5ArAF4WWHY2vCQC5Qr3k+O/7I1xEzN67/PUdkVKgoWMucjNHyCrpsPGLwbv3zrtvXkqPryvF/zhupD1iwOj68jVzLABnA0dcjrwLXl07mPU2T9TiSpHTTgKngXffRnCA4Dfg5Pvlcj7XXV0QXzEx4HzXydPggutim75JBpnHjQpdxaf+T8TfcLTR14w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664127567; bh=wJ6ShCBq7kYu6fTt9/QeYu0YRUkIFaoATaW9noqcnCb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EloCBH7aEkmK/WsNiqE7gaJnCvmwaI8NW0VA7HNY0lkYuSluKXQAXAWsc5lTzRffSAIKBEYcx85U8TSE47CZmNXd73m9nEP2ooYgBh98K8r0GGlz7gQ7Rja5zZa/woUQCpaiE1fc4PXeUH1nlK/o1hOtgwzAGhHHYlmVeuHP9gwiMLoi5QnfbQPOIH0DEEZsC0KGyBf0eUVWAYzCpqEWeVThmfabMloINl2YdXQQgh4VRm7RJQHSNCiXkjGgauuE4E07GAnLUVe7nxyl39XF/z5DYiyu0GWEaHbYJ+4XvfkqZ7xJK+h9w1YdgOjeTV8PjspHGRP8u5m/YxwJth1VTw==
X-YMail-OSG: trbxIJYVM1mpKX1JU3D6j0HbID4CVlOSyUxr4X7Um4WKDZNiFFyQItjkYyac6e5
 MbnqhpvZKCZOV7VqKfWt1vSYz6jp6BYU6rd.O2DeG4o0yeM_1206Ixs0Eu7q9WBsYY4SrINKg6IX
 y15GcJOtRk4BFKKtePhcyxIo5U4bt1j2FFeEpsNd1PXmDLO_4EezFVOZxbJK08pdLcP.i0n7BCg4
 bb37m8HmIZtjVWeaBDkT8J8ofbCNVhy8XzoP4E90jPPcHnLqMRqEfPlPXBTPqFWCgrV3qf71KnY1
 F.IWDHb4_L7FAwhZDeDtRB2QdXf1_O3VICUOno9BzKjJ_Z09kYgf.GKjYjlo2WZgco.6SlF8FOxD
 3iaXEK4Th6iqSP69Lndq82dhazrGBViA6q1DIi_rg7GDrgfQ37B0rP37o3We.qvtKWPJPMLolfsm
 6M.CpNp5Nl3TEc6TZjv40L7_XC7UvPyOsSy9STSZ1EapmZ2ZyDRzqaDOg7urQ3JLVIeMLKifHDMQ
 EWvSkRYOsEYCpW9AWSsxH0zrCKqZi_23yLv1rnwbonsBOljG3HxV.f8fGenRbjZ8Iok5j3mBV01r
 EnMrfdSi4J36cEPkG.oGRz2NlfujEA.sxL4iqK31AiYAqp6s_8cQjkTTD59e_vw.bwy5PijrJzuS
 8ZLJvOES3LJdmmglTf3_5wY6WABqinMDa4Clw8gYIC.Tf51wKdAsyxk0Rt3ISzzyJYEHTnG.ovPz
 F1yNEUoeVfpOFfF9z_GWW9L2IVVleWKybrMRIF5tNMhR_MikiDSMLI3FhdeIbUskhNqmM8lgwxw9
 c9QwvNJ7gaiyqApgEuXhNg5Mlc51w.dPtkQJJMMdGc5BzrRidVpxSdzaIciH8weKbLGkM1Ut0F43
 Ff3Z47JcexEWFbUR8vK02yt2EhWucWmE4o_kYR_7N9s.pHhkKqfbGIkQIs8.B30tgAL7s2kypaly
 nY0NZStvMSc3FrC1zowH5kCOp6BVRvUlvXUo3ppbI7DnKz4i_Rg3N0bdVEZCImcGsUdf76WoawN6
 Tb7d8Hpfv10SwvUou0ZmJO4XV115MevMbNtASUaRRdmZw_tds_17dc1nsu8mSyHCOwhLHXQSzxum
 2Iuw4ImJFNDJnX4bk04u93aNUg8LZqrnu_VoEE_Ds2joyYgwSQX4Yax6yI1A6g7mwX_mOxjrKSMh
 Begvod_4TROe7KpeIfKp_d5G_fgeo1pqbZcKFTAQTq1brHOsTgSKN1FIr2NKJQUxIT3BP5yBIyRr
 u62011cCjIbWFlBHIbhVmVof3IINNAg80BF7hqGSVVm1zEnFrQdKv1rHUt.9NZtGS8QTLoPGAXeo
 l0wldBGVKe_jahBjIHtx9X6zq8166swcPbYlWGZBkcwrIXgQ6gb2m8NrzTRAheSobImnrgHUDZmI
 Qct8N6vjCc4veKHAEjG2xvwaM19TuNBh_IfZUN5k1WPh8EghrDpfgy2UPFtyelfcCR6VmL0BNh2C
 KfHRa2ljiaCg2Tawiv4h4OsY988xLakn0NWz9yz9Glfs9ZxaRP8uLlroUUWPkCkp_6eoDMM8jnhY
 n8aSM0V_jRuzoNBKqraoAnjYHPGYyISsMeVlUUyBICpWzfQ05lAHrOsHKLRGh3_n6Y.6L7Dh6.tY
 Fue1SiDRMUpYjdXrMMp3V06PXXVCiBknl5La0Au4o7qtCZ0Zzz4H.ASyJvpP70PyN0qmZjFs1cLZ
 CVOdvObgZFIW18wvJxf0.2vfUb4a1MhCYjlq.TdMnAHNwODm1dE3JG4jyKWudjYBfwS_Bhm87L7R
 f6jQOtcxE_raiwlAICZ31GKSOWcDSpEET4boGfkwqZ6lrZqVuI3Bi_4x1Leywqj_AX0Qgmr7LHC2
 oqf9se6esv3oHmoZereJvT6r_O4nx5Hy5AsTBg86AMwbIbcGqsvNmY1XCBlVc9SH0iffpFF2nPJo
 Ul61GfQxBVpfOz1hlkBYXffzgE9bRKRhfM99wu0Mqs8rdeoIuW8pxknuvzB5Sqzn9Zujy1LkwCWM
 BFfXquO7aK0XX7WNnXPFvPMmLxWWmItP.52swUFbkOzxP3uJeUmYq25EImnnwgEabtoUCBqi5cCx
 JfU_XglmPCESDNaJJ4wYa2kETSNjpicwmShLArIyZ9eSHoLBEGjl7w.pTDXnqW4fShTkGlMFA.4N
 Pb5.zMKl_VcMB_9KGVxmr39n5kKl0KhpAvCfijOGLZ5M7Sdq3.ymu4cMhH3DCRYnJmlg.5GjlYAQ
 KFuKZcDRMtmDDjUyuyLgZTRyWesFhCNJaRrOaajVVK1lJWpYZlCjd0eqpm0OFIqfh4630NPNhj7E
 OrTkY
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Sep 2022 17:39:27 +0000
Received: by hermes--production-gq1-7dfd88c84d-bw26r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4dd339a09048b32709e5be7bf5c7c9a3;
          Sun, 25 Sep 2022 17:39:24 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220925160531.GA63213@www.zefox.net>
Date: Sun, 25 Sep 2022 10:39:23 -0700
Cc: FreeBSD Mailing List ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbCnF68P8z3FH9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Zg6R0iFv;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.46 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.96)[-0.959];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-25, at 09:05, bob prohaska  wrote:

> On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
>>=20
>> After setting initial_turbo=3D60 in config.txt the first reboot
>> found the disk, the second did not. Running usb reset then
>> found the disk, but run bootcmd_usb0 seemingly caused a reset
>> that  _then_ found the disk.=20
>=20
> It looks as if u-boot is somehow restarting itself unexpectedly.
> This is an RPi3B running stable-13, system and ports up to date
> as of yesterday.
>=20
> Here's an example session following a failed boot attempt:
>=20
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found

For:

> U-Boot> usb part
>=20
> [I think some information about the disk should have been displayed]
>=20
> U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700)
>=20
> DRAM:  948 MiB
>=20
> [...usual startup output]

This could suggest power problems. Was this with powered-hub?
Without? Powered enclosure? Without?

Was this a full RPi* reboot, going back through the RPi*
firmware stages before U-Boot started again? Or did the
RPi3B avoid starting the firmware sequence again?

> Are there any debug switches for u-boot? I've looked a bit and
> what I find is either stale or not implemented. There's a reference
> to a "log" command, but it does not seem to be recognized.
>=20
> It does seem clear that the presence of a timeout file makes no
> meaningful difference. Boot succeeds rate is less than 50%
>=20
> This is using an unmodified u-boot-rpi-arm64 built locally. The
> system has no microSD installed, u-boot is started from the USB
> disk (which is found by firmware without trouble).=20
>=20
> If setting up a microSD to start u-boot alone would simplify=20
> matters that seems worth a try. Hints much appreciated!=20
>=20
> Once the machine boots into freebsd it seems to work just fine.
> The problem appears to be with u-boot only.

If I understand right this is the same JMICRON context we had
an exchange about back in late 2022-Jan (and before). Back then
there were two RPi*'s to potentially involve in testing.

QUOTE
The enclosure is simply marked SABRENT EC_UASP,=20
The usb-sata bridge is marked   JMS576
                            2026 QH8A3A A
                            E76H20013
END QUOTE

Back then I warned that:

=
https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi=
rmware-updates/

reported (and still does):

QUOTE
Sabrent and Orico both have the worst track records for working storage
adapters for the Pi. I don=E2=80=99t recommend them at all but they can =
sometimes
be fixed.

The following Sabrent JMicron adapters can be updated with their =
official
tool:

	=E2=80=A2 EC-SSHD*
	=E2=80=A2 EC-UASP*
	=E2=80=A2 EC-UK30*
	=E2=80=A2 EC-UM3W*
	=E2=80=A2 EC-DFLT*
	=E2=80=A2 EC-NVME*
	=E2=80=A2 EC-TFNE*
	=E2=80=A2 EC-TFNB*
Important Note: After the update the Sabrent adapters often work but
usually only with quirks mode enabled (see bottom Quirks section of
article).=20

For Sabrent=E2=80=99s version of the JMicron firmware update tool: =
Sabrent
JMicron Update Tool
END QUOTE

As I remember, there was some discussion of possibly getting and
trying alternate equipment not based on the EC-UASP, for example.
Possibly a powered enclosure, avoiding a need for a powered hub.

Back then I had requested various device swapping tests to see
what the problem followed vs. what it did not. The types of
tests could be (all are worded in comparison to your existing
configuration, not relative to each other):

A) Swap just the bridges between the RPi*'s: does the problem
   follow the bridge? The RPi*/disk combination ?

B) Swap just the RPi* 's leaving the disks and bridges paired as they =
are:
   does the problem follow the RPi* ? The bridge/disk combination?

C) Swap just the disks, leaving the bridges and RPi* 's paired as they =
are:
   does the problem follow the disk? The RPi*/bridge combination?

(Other context held constant, such as the powered hub status
of the disk drive.)

With 3 devices involved, it takes multiple tests to try to see if,
overall, just 1 device is always involved across the failing
configurations or if it is always a combination of, say, 2 specific
devices.

As I remember, no results of such tests were reported.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Sep 25 19:34:15 2022
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 4MbGKf6l4Mz4clxd;
	Sun, 25 Sep 2022 19:34:14 +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 4MbGKd6MPwz3Qjr;
	Sun, 25 Sep 2022 19:34:13 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28PJYGu1063876
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 25 Sep 2022 12:34:16 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28PJYGYj063875;
	Sun, 25 Sep 2022 12:34:16 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 25 Sep 2022 12:34:15 -0700
From: bob prohaska 
To: Mark Millard 
Cc: FreeBSD Mailing List ,
        freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220925193415.GA63733@www.zefox.net>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <20220925160531.GA63213@www.zefox.net>
 
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: 4MbGKd6MPwz3Qjr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Sep 25, 2022 at 10:39:23AM -0700, Mark Millard wrote:
> On 2022-Sep-25, at 09:05, bob prohaska  wrote:
> 
> > On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
> >> 
> >> After setting initial_turbo=60 in config.txt the first reboot
> >> found the disk, the second did not. Running usb reset then
> >> found the disk, but run bootcmd_usb0 seemingly caused a reset
> >> that  _then_ found the disk. 
> > 
> > It looks as if u-boot is somehow restarting itself unexpectedly.
> > This is an RPi3B running stable-13, system and ports up to date
> > as of yesterday.
> > 
> > Here's an example session following a failed boot attempt:
> > 
> > U-Boot> usb reset
> > resetting USB...
> > Bus usb@7e980000: USB DWC2
> > scanning bus usb@7e980000 for devices... 6 USB Device(s) found
> >       scanning usb for storage devices... 1 Storage Device(s) found
> 
> For:
> 
> > U-Boot> usb part
> > 
> > [I think some information about the disk should have been displayed]
> > 
> > U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700)
> > 
> > DRAM:  948 MiB
> > 
> > [...usual startup output]
> 
> This could suggest power problems. Was this with powered-hub?
> Without? Powered enclosure? Without?

USB 3 powered hub driving USB 3 powered enclosure. I've checked
voltages on the Pi and found no evidence of power trouble.
There's no ready access to the hub and disk power leads.

> 
> Was this a full RPi* reboot, going back through the RPi*
> firmware stages before U-Boot started again? Or did the
> RPi3B avoid starting the firmware sequence again?
> 

I think the sequence was a full shutdown -r, u-boot didn't find the
disk but usb reset did find the disk. Then the usb part command
seemed to restart u-boot. 

Repeating the experiment just now the sequence was shutdown -r now,
no disk found, usb reset, disk found, usb part, u-boot restarted
and successfully booted to multi-user.


> > Are there any debug switches for u-boot? I've looked a bit and
> > what I find is either stale or not implemented. There's a reference
> > to a "log" command, but it does not seem to be recognized.
> > 
> > It does seem clear that the presence of a timeout file makes no
> > meaningful difference. Boot succeeds rate is less than 50%
> > 
> > This is using an unmodified u-boot-rpi-arm64 built locally. The
> > system has no microSD installed, u-boot is started from the USB
> > disk (which is found by firmware without trouble). 
> > 
> > If setting up a microSD to start u-boot alone would simplify 
> > matters that seems worth a try. Hints much appreciated! 
> > 
> > Once the machine boots into freebsd it seems to work just fine.
> > The problem appears to be with u-boot only.
> 
> If I understand right this is the same JMICRON context we had
> an exchange about back in late 2022-Jan (and before). Back then
> there were two RPi*'s to potentially involve in testing.
> 
> QUOTE
> The enclosure is simply marked SABRENT EC_UASP, 
> The usb-sata bridge is marked   JMS576
>                             2026 QH8A3A A
>                             E76H20013
> END QUOTE
> 
> Back then I warned that:
> 
> https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-firmware-updates/
> 
> reported (and still does):
> 
> QUOTE
> Sabrent and Orico both have the worst track records for working storage
> adapters for the Pi. I don???t recommend them at all but they can sometimes
> be fixed.
> 
> The following Sabrent JMicron adapters can be updated with their official
> tool:
> 
> 	??? EC-SSHD*
> 	??? EC-UASP*
> 	??? EC-UK30*
> 	??? EC-UM3W*
> 	??? EC-DFLT*
> 	??? EC-NVME*
> 	??? EC-TFNE*
> 	??? EC-TFNB*
> Important Note: After the update the Sabrent adapters often work but
> usually only with quirks mode enabled (see bottom Quirks section of
> article). 
> 
> For Sabrent???s version of the JMicron firmware update tool: Sabrent
> JMicron Update Tool
> END QUOTE
> 
> As I remember, there was some discussion of possibly getting and
> trying alternate equipment not based on the EC-UASP, for example.
> Possibly a powered enclosure, avoiding a need for a powered hub.
> 
> Back then I had requested various device swapping tests to see
> what the problem followed vs. what it did not. The types of
> tests could be (all are worded in comparison to your existing
> configuration, not relative to each other):
> 
> A) Swap just the bridges between the RPi*'s: does the problem
>    follow the bridge? The RPi*/disk combination ?
> 

Far as I recall the trouble followed the bridge.


> B) Swap just the RPi* 's leaving the disks and bridges paired as they are:
>    does the problem follow the RPi* ? The bridge/disk combination?
> 
> C) Swap just the disks, leaving the bridges and RPi* 's paired as they are:
>    does the problem follow the disk? The RPi*/bridge combination?
> 
> (Other context held constant, such as the powered hub status
> of the disk drive.)
> 
> With 3 devices involved, it takes multiple tests to try to see if,
> overall, just 1 device is always involved across the failing
> configurations or if it is always a combination of, say, 2 specific
> devices.
> 
> As I remember, no results of such tests were reported.

I did a few experiments but didn't find a way to clearly
record/report the various combinations and behavior. 
Very roughly, the Sabrent enclosures work fine on Rpi4's,
both RasPiOS-32bit and FreeBSD-current. On RPi3 the Sabrent
enclosure isn't reliably discovered but works once found.

My setup makes swapping hardware around somewhat awkward,
as the Pi's are daisy-chained via serial console. The Sabrent
equipped Pi3 is the terminal server for the Startech-equipped
-current Pi3 that has been my reference.  There are only two
Pi3's available for experimentation, plus one Pi4. I'll have
to think carefully before making much in the way of wiring
changes, lest the confusion grow worse.

IIRC I did try replacing the Sabrent enclosure with the Startech
enclosure, which worked and seemed to implicate the Sabrent as
the culprit.  Thus my interest in u-boot debug information.  

Thanks for writing!

bob prohaska



From nobody Sun Sep 25 21:00:13 2022
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 4MbJDt4FCpz4cwTZ
	for ; Sun, 25 Sep 2022 21:00:14 +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 4MbJDt0ycWz3ZbC
	for ; Sun, 25 Sep 2022 21:00:14 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MbJDs6xr8zY4x
	for ; Sun, 25 Sep 2022 21:00:13 +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 28PL0D6F035648
	for ; Sun, 25 Sep 2022 21:00:13 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28PL0Dip035646
	for freebsd-arm@FreeBSD.org; Sun, 25 Sep 2022 21:00:13 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202209252100.28PL0Dip035646@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, 25 Sep 2022 21:00:13 +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="166413961313.E6f5DccB9.33633"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664139614;
	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=J/Mc8dJ5fBi+9kBvBNM9Aq4G3zONAqH1Aroiv9pI0AE=;
	b=vlEYQQXjacnPT0qg+G/PKaBs1JDK27Xv4eZmyVyHBBXN8yo5s0Wg+PnNIvJfvJP4TiF4B6
	KGkGrAdT1NG2okQfkwzPKzew38578JYUhiSnzA5KiNC224N/2AYxs0FB2Q/vkszm/6y5GN
	YnqAx+dNVC+4BeQXxP2D3S0Nyk3VvFckuR9BQn0ooh0glL+3QlIzuJTew3gQKtY3Boh0M2
	8IyDyI2lZL3Pb6SZiwMvJSdBvSEnJ6a8ENqe8uJPjGEjB3ASv/GIH7eN5Gz3IGIVuYt0ER
	0Lf59FCldK9BMKl1punzaLNKYrsTbVwK8KMlLUpfARrNS4FQgnidJ7yaau+bkQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664139614; a=rsa-sha256; cv=none;
	b=ZKgOyRtQFfajXLmxPcJs3KY1Yk1td1PwatYmnOryeh0mtM5nTtOPhV9ZaVdquvVNOrYsqF
	7J775+pXCStVZnm4mmVLj8gBrqN/exjeFvsUmpTyElB3SjAAjH6IBsXjYwtDgSdL96zask
	2GaU84ZJu0tLz7lEn7jXPmyq0hDDbU4HhGNDUY3k1BZLQsYf0EiUBdmkSH1VJrmBrrXPXA
	QmGfaIesRr6MvoKJGTbwDW1iBwen1JhpK1ShvR1PnT0eA/nQ87Q6FvJuk6buDyFFhDPI6x
	ZZsjfnEDHCI64KH7cLWSKIcYQ5w+SHqDpam1yczXVaw2Drxi4XuFLBs7Nhtd5A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--166413961313.E6f5DccB9.33633
Date: Sun, 25 Sep 2022 21:00:13 +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.

--166413961313.E6f5DccB9.33633
Date: Sun, 25 Sep 2022 21:00:13 +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.


--166413961313.E6f5DccB9.33633--

From nobody Sun Sep 25 22:57:34 2022
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 4MbLrR1QZqz4d9Hw
	for ; Sun, 25 Sep 2022 22:57:43 +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 4MbLrQ0QzGz3rRQ
	for ; Sun, 25 Sep 2022 22:57:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664146660; bh=kXuTi0fDCCl+q9MJ7p2naMpftzA1UjraQSgcwocra4w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VV6/qj//oimDa8rHPsSd9hwbVzEqx3hWH7D5rdf1m3sX+E837hFm1qJ3+SvsPAsi6cso9fZMFNUyQeZWLvLNbPS/Pxk6o3bnhkCNfV6tP3oLwj2V2XILRrYfp3ekcx4jVl/1H0Op3bFKPti8Nei+GPYn8wHpqGZQvVmjKXjNZX0CAmxQtqMdEtjm5+mLvDUPFsevXP2XmYmkBICFeoEHQqvmGqKsRCXfJiSY9cOW8HuuNibkcrzRQl7yLhVI6jhvLGwwL8Ad1fZPwyRQHEtVhkw+zL32/2GCzXdGycT17Fjoq1kIX+knrT/RlJwrc+I64Jw89dGCejYTHpjNdbRBYQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664146660; bh=VEaUHSTbhb5fchbRqU9dS2q/16s6QlRCU1cddyYqnCh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KepPTNuFtAU24gDqftWXYU1y/sPXEVV+kCx0XEcHqqhXh+0rhTT0rhOlNL0mHbtCWPkV4PcJ6EfZUfbN3/1mss0BbQxefEQasvdjVduU3NfkDnYKmfDaPv876BJVcaU9C/vSZyUp1sMlxAU93rHW8vUU0cjhVaHYegMK8zkFSn4BJaPfqXLwoyKooUcJnj3MttttgQvKndO+JJk6jx//0+jKpQdbOZKJue3Tkf3w/SBf0BWsoCZOZW6Ii8+SELq7pEW/94d6WJBSzTNueg5OKwguAsLHU1pVxR2hAvUKhr49cLHUW29btwPXB82zlXr/gcsq0I0qyKsRkxug38g5VQ==
X-YMail-OSG: 9IFp7k0VM1nSqIfYG0die9GoRYTUEUK8uRKRjWEKQ7iNe4YobbHmZz5XOXU0bxb
 GjZ5K1ED_lsvEZQjw7G3NyFj.Rsvo.7WiUbgKs_zI0cDCZxe65HQ2reUFTWDgZzq0PEOdS6psoUU
 HAvnpJFWwMHfkkZH2jQToNsBowwXfSRxtuqZgmeLwyISHWYQlZnXd4ZyWnCrMuM3PimN0p9sslCm
 wCYJS41Z8je18VhW1fYvaUu44b4Eak.adsKwjnW0gq15qu1i4ncQXLjI6pHID_uv79z8zJfLBHi.
 cXqizDkCZB6AmOtxs1zpN9w8dHD89I1B5DzIj0oMer6LLge9fWhvwqkLJmsjsBwbZxUJ7EJgXLFH
 Jye71XI_AA6MIMMJ2S7JNGcvH7CPDD6E.shalhGjkTE5aPZDOakN.Kb7az9S5B7m0SiC8si3yDgZ
 PTcJHOTHBpCCWK.5HQmBOtUmx1oeegRfTySI93B5Y9OFOyk9zyjS4kGo58EVp129aIXAzNWtj8N3
 Y_sA7_0x0e6.s5P8bD92igSE7TkmLy7s8wSZ.4DQaVGxCWjy.5ikE7PtyGMyIgEnG7u_EGaHL._K
 N2GqK1wArCh6a7nfME7JNft8AvS46VQAvLKsSsrO3rbhX3xsM3CWExCqBtWWOVFdNr6uqYvDEHoK
 R9GPPJDC7hqy2mAzHNqRJcDXE14TcW77WkAWwYk8hG3r6sy9YQ92s7R3aAThzADQ8aQluGZfHXUD
 V4qV4OQ_v4PMHHdg7gV1fB1vBtJty95ZHe9tDN7lDThHdhCOBSBnbNs0lUj43wtfwqQfbvbhg815
 U25.fxjSWbDLh1n3JLmAeJQBvdtYTm0cv1cj_.uq1xfi4bifcMOkI0YCYY9gTc3EHGgcxZbfgtnc
 u1QYwtPMUZM_iOUQPNbkrvm6.DV_mnRsCIBS4L_G44mHqfl0VRxuKGKhQoLHYoV8kEgsh67FI2gs
 iB0OCWGjQoHbjiq7yplfWecib7.y_kC2cbsv1OQFrjbhjzROZDuU5BisyrmlYTrNPdN0AmIxhw9S
 OhaBWxSTEJ0rlRe_hZ__3ekcxvt65y9_XJsx5QngvHTsNAD0C_yzxOfuBQy1Wy8wnFuSFoaxT8LA
 SxB4GHxa7RIX8CkgmyXGhQ2GvPvKORB23VeOtMEXpj81p82czJWYCuD1eRYE7S9Qh2ruqDxA6T5A
 xSuskv34qabgQ7ulEVKSPy2XZyKiiFax2HcYFgl3fMIXw74Y36nKlGQ.mwk0MNudkiOZLUl_Xl6M
 EjU.os8Bb9ltARxwN4W8FKpeLrnxLPNfIsSB2l58dU2iViaBiIBMrE_hvgJI57CGvqGSnegueTKl
 WX2DoQ1u0QjD02AHK1gXQ3WCHivaGHZPs0nir0UzTJdUrbvvtCdYUtsH2LwR4JBDZZDcW.B81Qwr
 Tp6uoVdbiOtjDvFVyUXzxiBi0Npe23xIYVs9TaYuIFSRqpuyI4kb60XB5Og_dH3lMJA7bdh8B3Bb
 xO5N8b4pzV4SmnR7F4drulkV.cK81mJ1wiOrdEbqJPep4OW43GicmNWUzTEJq5akD4shjcpGVzp7
 gCGvuFUD0IcpEg_AiGHDe9cLIHb488EJ2IgnZd5GuWGc42XRXasNyPAYe8r2LrvT49ZEvMihCz5x
 izsQFHAaY2xkhtC0TeR1u1zEXdQH3LzijOK0pEPoGpc9iBZY.iO7sdwxNd6K0Q5CzoGrRzxrsSZ2
 9l3HUCErUsrDIfe9Pa1OVnvSe3oN7xol5zNEHduJFJ8iYDpUxw8IT0moOFPQ1T1puFWf6Hh6Jb21
 OLWdJxBV37otHGtdA9DddxjEaOCBOt6BAat3X48swhC.N5r6LAIEUkckHt7rukEzJK.cM6U2mTg_
 n8b0Vb_1Y_eXafA.AAwCqCYzuQbzhoY8BqR1gU1ifX5DANs4VVo8KgujHXJTh2D_eEfe1m5ST0nk
 gyAPzdpqJaUVssQCv2nzaQpL6vapGLR6X1iHzmClUx.uk5Voo96Bj0RhpLt2OUACkvGLvkRI6E5j
 jhht3qTwrUJLi._PXIPiUzgmP.ZOl5zTayB8HBwfUrzkIL4Sa2.46TfbhMd3RUT_sPmyK5NEruAM
 XKXlM89a6tndr9uHw2_7CLXmfrnehcN7kpWgsHdHl3rvn1hWlbrK8O9jWW6ZvMmS4Sfav4QYAtFS
 QG.uoO5XKKMygSbZJ1WQRXnixQ7tbEwdPYwCQ4xxmqtCjqRPVGCbB_3rtKnInLng9bGQcEpOlVTI
 lYvuUVwZKNurJG1IHRjPoigqnbQTwPXCJri96O2KelFsR5iA2_WfeNETMqQkrLecn5wWrW63boF1
 k
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Sep 2022 22:57:40 +0000
Received: by hermes--production-ne1-6dd4f99767-4dqfp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b7900d7cb0c43cd00c621ef708e6ce2d;
          Sun, 25 Sep 2022 22:57:36 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220925193415.GA63733@www.zefox.net>
Date: Sun, 25 Sep 2022 15:57:34 -0700
Cc: FreeBSD Mailing List ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbLrQ0QzGz3rRQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="VV6/qj//";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.23 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	NEURAL_SPAM_SHORT(0.27)[0.273];
	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)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-25, at 12:34, bob prohaska  wrote:
>=20
> . . .
>=20
> IIRC I did try replacing the Sabrent enclosure with the Startech
> enclosure, which worked and seemed to implicate the Sabrent as
> the culprit.  Thus my interest in u-boot debug information. =20

Looking at https://u-boot.readthedocs.io/en/latest/develop/logging.html
it appears the logging availability has to be enabled at compile time:

QUOTE
Enabling logging

The following options are used to enable logging
at compile time:

	=E2=80=A2 CONFIG_LOG - Enables the logging system
	=E2=80=A2 CONFIG_LOG_MAX_LEVEL - Max log level to
		build (anything higher is compiled out)
	=E2=80=A2 CONFIG_LOG_CONSOLE - Enable writing log
		records to the console

If CONFIG_LOG is not set, then no logging will be available.

The above have SPL and TPL versions also, e.g.
CONFIG_SPL_LOG_MAX_LEVEL and CONFIG_TPL_LOG_MAX_LEVEL.

If logging is disabled, the default behaviour is to output
any message at level LOGL_INFO and below. If logging is
disabled and DEBUG is defined (at the very top of a C file)
then any message at LOGL_DEBUG will be written.
END QUOTE

(There is more about "Using DEBUG" vs. LOG_DEBUG and the like that
I'll not quote.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Sep 25 23:43:15 2022
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 4MbMs93BL4z4dFj4
	for ; Sun, 25 Sep 2022 23:43:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4MbMs84jxhz3vZq
	for ; Sun, 25 Sep 2022 23:43:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664149402; bh=i7StZLrhq4EveZdCe2JdXxii/wlebp0jcnh+u+Fcl6A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qhvF7HTFLNrwxs4aSkrpA8StHXMCrA07QpjFliCKZAxAinpgNh8DNct4AEOxnJHmljHb3+0zm3ixTssrnYHuvAh/fkClVufncXhF7Bba1exrT9+D7XVXNLbjajsOTVsQP7DIKSyOMU/UeM7UhT5+itEaWS4FXrvVzeOE8N75aXCo/Boj9LhQ9oAALIvsL2CXz/o3RvoYoMxxLxpFPg83Mup8OW4yjTTZLElR4ckFUU4oAu5W4ukmzzKOAC72v8RITx0TOH3m44OK95U7XEJQb6/twWcbPgtGeSzNHoqgK1KciIMJkzqAEpLxO5GV7UQ/Ayv6NzVthGORB1GtOQeRQg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664149402; bh=YxP3FLHoT1MKIVtL9+t1ueP5WlYwLHMbt4nCRtRNT+h=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YGIKP/lb431GaW/y11DYFqN0WPSD6DCHz+1e1vnCax3Zw9dZAY3alIX7uAeSKuPBTEfvBylu5ZyOnlAAW9qCah4J70ly0ZemggKG5SRC0oMIJaD90sGQSNmMeUn2BVnlEiaiFRtZTqwFOTg5MCZ06SS6iwrMoBW2Sl2RNZc50hRaQ5QBqtgHA75znMpTVTLLfXvlq0g4D7Vdl5dHDhxmLUiCLoaBX1OJhjk95BBG/uGMVszwtQfXYBpcyd7ht9RdCoFrsWabPuTeshCUGUbsCeGeS8ng5rW1LVfrYbfjmAPvTePLZ9eH872+yFdD634HfP6mC5Gaw4v4mWLVXOvPvQ==
X-YMail-OSG: azvc8a0VM1nlUQBJV7oMrjX78Hg9XKSBs99NkMG9GYX_RXodppfyJUWmgrGamyi
 Ii3KgSJrP_Dk.0LOFNpgqgJqHA8mVeKGyLvm0f0fUlV5M5nb2Z.lbrlZhsBv7gHv5DtXarLYidYh
 ylMiwZTYSrHnpX6mEeVzCnTslQ1T2fKFOKrxVsn7F_UhxCVT5SoWZnHXaOvZdTxSNiJ.gfKgBvQ4
 GgZRyeJSKEpvm23EWQyn1zJwKlVoaTzalJthFdjF8ngUTTd4972a3mkIvBAEDJuv0wVk6Tk9jOg_
 NHhY9CvhuZ8omnOg44CF2c9K1.iqWKt_6OanJniGyxKKJZ3ODFVpgGFXjvnl9yLb.nym7j.ksNn2
 9Yhu8BkfS_vTSielNm0oCBKdNBMuHBMrXoA_6qFAghI96VsxNdQ1SLFtbeMBGyQwWLxY6O.i5sRP
 xLZAkIw_RrXdMZjb8wEJeWtOWJwAMyjsCc5ZLsPw5BX9Q0Y4_XGwyxm0v6GjZe6WtfmEzjRM240P
 oPt7RpLxCv1OkGNVg86_CuLVvxu85uwqa04H2ikLJVYCywn35bBvqnJEipC7UgkKfW13k5hlcwkc
 Puiz41LzVC5VAs0B8.PZI3tqW18.4wuam47gG3C3MBSElxPSwzI1WiCGRcmvdyY9pyJW7.FJ0A5m
 C7pjYSl75Nq_J9UE.YJM9KeM_mvTD7RCEQLovN97CX3MXGEEa9CIlXTNnlPix9ldOfeMRKP7IyF_
 kyOpd0Liox4CcLDlfbNkH2TYA6ch3l3IB9li6ttTFlVcLBoH2UuCA.FX4YtTyqqQqR7SI6lQRdUN
 YaiuKJYW0YlUbn4u1cr22nTsiwfpDqswBy7x9ijYQd7d3Aqt5V_PwbOtIzLmEZXLAtvdJIQctA0W
 y_JjvAdADoh8GZkZrwoTLNUOcC3RqmUXnUsCU3PC39sYqAwTHgKkunUgU8mrwq0clM8GAbHPM3u3
 7oo_9eFPlW3THQeKE4BTXcYNL1B4mUayIzckLWWk0gSnvEO5VpfBcPC_4i_hM8Mw3tJty57q.E2Y
 I4_hAKgpMu1VDaju1bfR1TBruLFoRegeVxeLTZqAfc.6ZneeLZI7R4vjuMGgCGyWMiI0m7HjlC5K
 7SWRAz9VQPqofqVLUu9n.8g6Dbplt1XFNVkpHDJRqCvQLrfuGIPmgR0AH0nWdwx.ovJyE0MAqed4
 ZKk2gQka9FHspf8v1m..X9P9n1IWpYTcUMHCu_polyqYEK5kUWA1wReSNqrhiNYJwvbeOpepgW69
 5hJjwKe8WMG.CTGMBZJW5kFcGGK1MeH270ieFCcGmQtQZb7oEjtE3XEmC2fkTrGtgy_FQuvbSuQW
 Cq6Y.ockNwCi9bpYLxj92pKDLruYPjvDdb6XjYNsl2tW3k_Fl2upVk683_kOxKy.MceqdH3EO9dp
 bMwuEN1hAUQIdlRWDQSz4tODwusUnxOhxfdenA5e2_H_EY_48uZGBO7vKTVUELmtTLoFmLdlekYp
 dwmYfdVHlTGaehc1QckQz41ea9RIAvtn5oVkIFIgNUW9CmWAC7W2FIP8zgR9UmOcLw7u9xVqTx4k
 HLswkChhw8NEF4wVSEhgP.A9TWIgRqNBCGashcpsRluo.12dH2bXfY57bSMfEKDH0b20mifLxmRB
 DXiPMV2F_hhk3.V9OP1T13MwRgaP5xWCQoY.TeiUMh4CpAqchZV.nSEHVHHCumqcCP9pAmp75fNO
 Q78hP93z0mMZkkJHevLwZP4SLVgKGskCTWvdzenBxl7IcJ549Bn3p2PUv7Q55KDlf1XaFp85EZYe
 GtO.W4Gz_fsXMgOiJhvLjVul9F7pcq0fEphxXaOKrxTk5IqoPHJh9L34pKRIOoqI9f97lRo5gZDy
 ZvxxWcsxErWjJry1GfaGNPvLsPkWSHFv5x1Hwlk6ib0_UNuyG8KfZYMSUcaS.uernYZMqOmMGx5K
 8GDR1Rct7f7jDTSgt7D8Qrirb1ABO4tQ5aworJWbe7qA2Oqg5x5HF8yu6xGOfoEe9BmGBqDKCils
 K3i39lmAIlQ3FP9SWLJIzIoBsnea90D0ocwsQpjXcaZvMDC5GwAVXfZnTsFtM53qdgjHvS._Jk_G
 zI9.G_9UkCYcNgRl6Ry20edNp6g_7wevjMkn0JIp4VYqhObD914gQOZAAaaIwt84V8EF4v1X_wnv
 1q8IPRdwE4Ss8o3wZxg2KHaUIgCXL07HoeyzBAHlaS96kD7_ZqChFBsYrCGPqIZXBVgcbl5iJvTB
 MwGGj2W1jvr3GNlYjdB9pMvbw3uGTye2NGSlqEY0dBBOT_ZjflRc024GceAaOlz_BPeGEIFydNYN
 dHUMj0A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Sep 2022 23:43:22 +0000
Received: by hermes--production-ne1-6dd4f99767-w779p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6139be1c5984a10cf159552092e5c29b;
          Sun, 25 Sep 2022 23:43:17 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220925193415.GA63733@www.zefox.net>
Date: Sun, 25 Sep 2022 16:43:15 -0700
Cc: FreeBSD Mailing List ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbMs84jxhz3vZq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qhvF7HTF;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@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.988];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-25, at 12:34, bob prohaska  wrote:

> On Sun, Sep 25, 2022 at 10:39:23AM -0700, Mark Millard wrote:
>> On 2022-Sep-25, at 09:05, bob prohaska  wrote:
>>=20
>>> On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
>>>>=20
>>>> After setting initial_turbo=3D60 in config.txt the first reboot
>>>> found the disk, the second did not. Running usb reset then
>>>> found the disk, but run bootcmd_usb0 seemingly caused a reset
>>>> that  _then_ found the disk.=20
>>>=20
>>> It looks as if u-boot is somehow restarting itself unexpectedly.
>>> This is an RPi3B running stable-13, system and ports up to date
>>> as of yesterday.
>>>=20
>>> Here's an example session following a failed boot attempt:
>>>=20
>>> U-Boot> usb reset
>>> resetting USB...
>>> Bus usb@7e980000: USB DWC2
>>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>>>      scanning usb for storage devices... 1 Storage Device(s) found
>>=20
>> For:
>>=20
>>> U-Boot> usb part
>>>=20
>>> [I think some information about the disk should have been displayed]
>>>=20
>>> U-Boot 2022.04 (Sep 23 2022 - 17:28:32 -0700)
>>>=20
>>> DRAM:  948 MiB
>>>=20
>>> [...usual startup output]
>>=20
>> This could suggest power problems. Was this with powered-hub?
>> Without? Powered enclosure? Without?
>=20
> USB 3 powered hub driving USB 3 powered enclosure. I've checked
> voltages on the Pi and found no evidence of power trouble.
> There's no ready access to the hub and disk power leads.

I'll note that if replacing a RPi3B with a RPi4B (without
other changes to the configuration) leads to a working
context, this again could suggest power problems.

But a test here is if that "working" status applies both
to when a USB3 port is used on the RPi4B and when a
USB2 port is used on the RPi4B. The USB2 standard does
not require as much current to be supplied. However,
if I understand right, the RPi4B (not otherwise loaded)
easily supplies more current on USB2 than a RPi3B can
reliably supply --and more than the USB2 standard
specifies. (Similarly for keeping the voltage up.) Still,
there might be some distinction for USB2 on the RPi4B.
(I doubt the RPi4B USB2 ports could supply as much as
the USB3 standard says is required to be allowed. But
I could be wrong.)

Because USB3 introduces various differences, some testing
via the RPi4B USB2 ports is appropriate.

>> Was this a full RPi* reboot, going back through the RPi*
>> firmware stages before U-Boot started again? Or did the
>> RPi3B avoid starting the firmware sequence again?
>>=20
>=20
> I think the sequence was a full shutdown -r, u-boot didn't find the
> disk but usb reset did find the disk. Then the usb part command
> seemed to restart u-boot.=20
>=20
> Repeating the experiment just now the sequence was shutdown -r now,
> no disk found, usb reset, disk found, usb part, u-boot restarted
> and successfully booted to multi-user.
>=20
>=20
>>> Are there any debug switches for u-boot? I've looked a bit and
>>> what I find is either stale or not implemented. There's a reference
>>> to a "log" command, but it does not seem to be recognized.
>>>=20
>>> It does seem clear that the presence of a timeout file makes no
>>> meaningful difference. Boot succeeds rate is less than 50%
>>>=20
>>> This is using an unmodified u-boot-rpi-arm64 built locally. The
>>> system has no microSD installed, u-boot is started from the USB
>>> disk (which is found by firmware without trouble).=20
>>>=20
>>> If setting up a microSD to start u-boot alone would simplify=20
>>> matters that seems worth a try. Hints much appreciated!=20
>>>=20
>>> Once the machine boots into freebsd it seems to work just fine.
>>> The problem appears to be with u-boot only.
>>=20
>> If I understand right this is the same JMICRON context we had
>> an exchange about back in late 2022-Jan (and before). Back then
>> there were two RPi*'s to potentially involve in testing.
>>=20
>> QUOTE
>> The enclosure is simply marked SABRENT EC_UASP,=20
>> The usb-sata bridge is marked   JMS576
>>                            2026 QH8A3A A
>>                            E76H20013
>> END QUOTE
>>=20
>> Back then I warned that:
>>=20
>> =
https://jamesachambers.com/fixing-storage-adapters-for-raspberry-pi-via-fi=
rmware-updates/
>>=20
>> reported (and still does):
>>=20
>> QUOTE
>> Sabrent and Orico both have the worst track records for working =
storage
>> adapters for the Pi. I don???t recommend them at all but they can =
sometimes
>> be fixed.
>>=20
>> The following Sabrent JMicron adapters can be updated with their =
official
>> tool:
>>=20
>> 	??? EC-SSHD*
>> 	??? EC-UASP*
>> 	??? EC-UK30*
>> 	??? EC-UM3W*
>> 	??? EC-DFLT*
>> 	??? EC-NVME*
>> 	??? EC-TFNE*
>> 	??? EC-TFNB*
>> Important Note: After the update the Sabrent adapters often work but
>> usually only with quirks mode enabled (see bottom Quirks section of
>> article).=20
>>=20
>> For Sabrent???s version of the JMicron firmware update tool: Sabrent
>> JMicron Update Tool
>> END QUOTE
>>=20
>> As I remember, there was some discussion of possibly getting and
>> trying alternate equipment not based on the EC-UASP, for example.
>> Possibly a powered enclosure, avoiding a need for a powered hub.
>>=20
>> Back then I had requested various device swapping tests to see
>> what the problem followed vs. what it did not. The types of
>> tests could be (all are worded in comparison to your existing
>> configuration, not relative to each other):
>>=20
>> A) Swap just the bridges between the RPi*'s: does the problem
>>   follow the bridge? The RPi*/disk combination ?
>>=20
>=20
> Far as I recall the trouble followed the bridge.
>=20
>=20
>> B) Swap just the RPi* 's leaving the disks and bridges paired as they =
are:
>>   does the problem follow the RPi* ? The bridge/disk combination?
>>=20
>> C) Swap just the disks, leaving the bridges and RPi* 's paired as =
they are:
>>   does the problem follow the disk? The RPi*/bridge combination?
>>=20
>> (Other context held constant, such as the powered hub status
>> of the disk drive.)
>>=20
>> With 3 devices involved, it takes multiple tests to try to see if,
>> overall, just 1 device is always involved across the failing
>> configurations or if it is always a combination of, say, 2 specific
>> devices.
>>=20
>> As I remember, no results of such tests were reported.
>=20
> I did a few experiments but didn't find a way to clearly
> record/report the various combinations and behavior.=20
> Very roughly, the Sabrent enclosures work fine on Rpi4's,
> both RasPiOS-32bit and FreeBSD-current. On RPi3 the Sabrent
> enclosure isn't reliably discovered but works once found.
>=20
> My setup makes swapping hardware around somewhat awkward,
> as the Pi's are daisy-chained via serial console. The Sabrent
> equipped Pi3 is the terminal server for the Startech-equipped
> -current Pi3 that has been my reference.  There are only two
> Pi3's available for experimentation, plus one Pi4. I'll have
> to think carefully before making much in the way of wiring
> changes, lest the confusion grow worse.
>=20
> IIRC I did try replacing the Sabrent enclosure with the Startech
> enclosure, which worked and seemed to implicate the Sabrent as
> the culprit.  Thus my interest in u-boot debug information. =20

I've no clue what information to enable to learn about the
type of failure in the Sabrent enclosure (if that is where
the problem is).

But, again, if RPi4B works via USB2 but RPi3B does not, the
difference once U-Boot is started on the two is likely(?)
mostly power quality/sufficiency as far as I can tell.

Going the other way, if the RPi4B failed via USB2 use,
that likely would point in a different direction than
power quality/sufficiency and might suggest USB3 handling
is required for some reason.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Sep 26 01:04:20 2022
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 4MbPfW65Lhz4cPwS;
	Mon, 26 Sep 2022 01:04:19 +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 4MbPfV3sL6z41D3;
	Mon, 26 Sep 2022 01:04:18 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28Q14Kdi064781
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 25 Sep 2022 18:04:20 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28Q14KhW064780;
	Sun, 25 Sep 2022 18:04:20 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 25 Sep 2022 18:04:20 -0700
From: bob prohaska 
To: Mark Millard 
Cc: FreeBSD Mailing List ,
        freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220926010420.GA64437@www.zefox.net>
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@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: <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
X-Rspamd-Queue-Id: 4MbPfV3sL6z41D3
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.82 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_LONG(-0.73)[-0.733];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Sep 25, 2022 at 03:57:34PM -0700, Mark Millard wrote:
> On 2022-Sep-25, at 12:34, bob prohaska  wrote:
> > 
> > . . .
> > 
> > IIRC I did try replacing the Sabrent enclosure with the Startech
> > enclosure, which worked and seemed to implicate the Sabrent as
> > the culprit.  Thus my interest in u-boot debug information.  
> 
> Looking at https://u-boot.readthedocs.io/en/latest/develop/logging.html
> it appears the logging availability has to be enabled at compile time:
> 
> QUOTE
> Enabling logging
> 
> The following options are used to enable logging
> at compile time:
> 
> 	??? CONFIG_LOG - Enables the logging system
> 	??? CONFIG_LOG_MAX_LEVEL - Max log level to
> 		build (anything higher is compiled out)
> 	??? CONFIG_LOG_CONSOLE - Enable writing log
> 		records to the console
> 
> If CONFIG_LOG is not set, then no logging will be available.
> 
> The above have SPL and TPL versions also, e.g.
> CONFIG_SPL_LOG_MAX_LEVEL and CONFIG_TPL_LOG_MAX_LEVEL.
> 
> If logging is disabled, the default behaviour is to output
> any message at level LOGL_INFO and below. If logging is
> disabled and DEBUG is defined (at the very top of a C file)
> then any message at LOGL_DEBUG will be written.
> END QUOTE
> 

I looked at the page but didn't understand where/how to set
those parameters. Do they go in a configuration or Makefile 
somewhere?  I tried using 
setenv CONFIG_LOG 1
setenv CONFIG_LOG_CONSOLE 1
setenv CONFIG_LOG_MAX_LEVEL 4

[The numbers were guessed at] 

All showed up in an env command, but the the resulting u-boot.bin
executable did not change size and behaves as before. 

Apologies if I'm being dense!

bob prohaska


From nobody Mon Sep 26 04:47:55 2022
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 4MbVcj755xz4csBZ
	for ; Mon, 26 Sep 2022 04:48:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MbVch4lQMz4K5K
	for ; Mon, 26 Sep 2022 04:48:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664167681; bh=HuEJX6SnEfkuw/AI1j0pP+e5OKNmMrS1ObHwfeYc6Zg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RFpgvbGxoqzidRDvmHUZ6bps1sjNIa+kQtlG1M69WmRtsMx+599pDn/OK9eh8OGdN8WufOWdVM5ssbKQsvQ3QTI7PEj2eXb9ntOS3f18rgwnDVaib0164jePphONguFpcYUhS/u1KU0klBU4HGvEYUvVYJVa3xS/u0lgiHiv4cBGCkjskziHguFQoNNgVJI6ovfhphxZWIu5NGqULlzAMeIDA49Ct0aghPtgSiEXIk7iSBqTmN6cAX7DVju9hwA+9gOn9q/HTbBES3cOARER9M0inKvQJLwovkm/Go1JaWU1Ihf6EtUi5n4XhtNf4C2poD8pd5vS08nlqT2NF1J8Gg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664167681; bh=6TxlzXCmXWpSURoaY/83YqwEzQqodM6Sgjr0LwLZdVx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e3Pz3dKZrz2o1QKLSRoFdJDYj/pDXkB6NLtlIMRgSruY2bD8qldzg8RL7tfAXYjuAWV20L5Oqzerdfh0iOfRoSj7W8qhZKdQCpHTo4chtTbZmhVcOkAuriRyfPHycGYV3BtQG+mfsyPA8Q9Zta78WsY1q2RF1VPLptrzBFxa8aeAiOSGS3LbHR6CwdaDI8bXdl/47fTRUlXX7TfG92sFuaf6uLbB+YK/uCXyKBgKDVOo2zIPYYalROS2swKoZ/Oq309biBKfeg0tBpbTnh6/W0vcWo1ib1R/dljU+b4Cb5JprXlDvpmM4hjKCRbGosSZd8oSjNOpP8SgouZqymKl9Q==
X-YMail-OSG: VfD548kVM1mropNyWoSTvteZ4gEPqVfZajQ5SGI12KG97xTzdre3OxNkBfkR2sk
 WNCQfqwvuWd9PSaSMZQtG19_X6MmiSs2XJgDQp_Vgh1xTQeUS8uRUA9haedxo9mzrNgdDg1hHcY1
 sexqHOAN3FnfX520_6VJs123oaaLaL9sIbSzhERIK9g8NrNwz.kHNScY8u0mNAIhEdRxDnAgJ8va
 qNu0cMJD1OJ3Q4ENf6YMO1EAYDFQreyey5euKXOB50XT2tF9CFOcghjQx5xd.M7rt0po9i63mIRj
 EtUvNNdg99edP2mfPsUSu_6yukSY3ux4T6YusaHiFI0zrlmyKU6SH48fhHwHh.7AFyLyqJRV_ja4
 sYgamNiUE5HJpGy0wWJsZMty1q8pzuOYyU3uOpavQZAihaQlkAoMoo4244EGeeSb_mWrR00oif9p
 yZzisJd52KLnvIc6dTtB5QNq0nYDwkOLrWBNUvmMQ6CYGEh3qaFBvB13ThtW0aSMZqmHBo_LJ99z
 vauQgRcOwzFgDwghKrkbNUp7PpWuFR9d9MDoQekFURmTH6zJO0IBZH3BfLGzPlJdMuawEAU_dL7n
 iBbFC1rI8v7HIHl0DtZjzZaf6Cx1lxKgfq0gNGUOskrO1Myci2J_RtIGulD72zse2GVXCBxxgdzC
 flvW3yANrUIc4V4Y1RUJyVqn8Eylh9LRFfEKU4TmOu3lDgRlf8mcEgVMuO6WCz_xWcnCllsc1DLB
 vkLPvywpRIHz1ADKEEDXmBnJ910ijMRR6eub7jxasvn4hNxPwoPuJ2HEr7qQQyQSeWEBeFGdymjV
 M_oRQaygPR95zLAQ.1WwsC4O.TfV9fZcG6UEQOmCscj0qNB0WU.vWZKlJ8ssZteQE7rD98Bfc8VT
 eAxcuxts3c50TwdY1tY.ynXOQMgnJH0xgbDo51ipi8WIEyUhwkjh00XEXxdVBtGp4l_BiDsJabf6
 86Ypv4SvFBcPylKcmOOUeSMQLfa_cPcvsiIZIrKJz6hLB.CaCQcOSQ71V703rDkggxwWN._IKnjd
 CbsyDGWpeLjLuLY2Ph2Px7Keh3T6dPkQCQgEzF.MGcnzrs.ie8md2U3EWwnkIcttDw8MyZoVcSFe
 sMQdqK_MJBWo7g90lCft9C2KgEUM4334Ynf_u8FiVftag2JP_pvHKcaaT6m6CH_IOEwZM6n3XaYI
 n7eM6HU5bvb577_oagGPy11JMHpo9tlh25UKb78zRzJuF6T_frauEJsNNvGdsvhSG.ehLsyJQ_xu
 rlQ8FdvrC0Bu36y0MrgjgxY3rvnWN9QadR6EtnTOrVn5hKP_snES1jefeZMS1eCx_7NBC5q.Oih7
 hNcuAyV5PbCrzZga6g4oBY0Nih_UF6bKnqrKGr8LDZBH0YD4knsAyXbXh_w_bmy39WbckmxNpQtC
 8FrM4dho6XQy3Lern3o1QR.zS.RBsBaKpwjEB9715fhhaWNmxM_SX2i8AP7DJ7VuhYOoctXEpfwS
 JPavr1fi6LWQp6ulQihNeIHCDk6o3cafjAQzXV6FA7couyYXuOfkZpydb5CWIygGyJcc92Sbu3Nc
 5sHEsmRXbLUcDZbrozuRKctyvQSiSXBO462whgySzSDxrR5evqIrwwOL_fDcr79QPDP8V1wg89aN
 klXwMlOoDSbsfHBjfjuxjxZx2Tf4w73z2LvN1UKfKNHIgD5_r89It0eXcHJ_ORbtXryicW3KSlqV
 qB26rdOsj5lQsmkyp8FQ1X_MTB6cGP62J2DDHvGKM0X6xovUvp.v37n3tQA6yFejD9OQ9Fg3afLp
 j67zMAoZsJRPiKOa16sPhJsqGbBryFfZ_QCPXt0HPF4549YVzxAY1mAH8BSdbCyelGUqQ2wlOi1k
 v0DnEoQaOQ3vhLdqB4fDI9uvLI3wQ6aTjE6rDz.LjcIzft11IGEeMoz6fxmjBTGLHVXAMAdTOC2u
 6Tl3ui0MwFaGCwwff8L45Rh97Fjaw19j_lliRrs_DcjPyca5N7bcO9ktz4NdqC1DK1IFcwmgiNKE
 xvc8pLoi0eHdFkF.O5hiYH4Fg0Y46bZfSpAea4UKA8HbDZGaQtOUmi1.lVN.6VfDTE78oty.jnWS
 r5DjABkSdG2W4mVjHDrfC5VAycBmIBR8bVwyqq.CDxnUujGZq5a5AITaVi2YU4N.6oEUQxG5Ay.h
 tFJBU.4.TPqJxqeGu6DGrSDYQcz9Pw13qJ83xGdscBsqaxtWpIFH1pexI88ZC2M7KrTEhD1f0YkW
 kTZRECYYdXVo2mc3RShO6qv0SQz6w5Z66CwG7XKGDeACyE2Be798sSl3CLVJYTbrJsGhXxY5SG6K
 Qm4zU3g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Sep 2022 04:48:01 +0000
Received: by hermes--production-ne1-6dd4f99767-x2f2n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 77668da53ee25b4a16206626a77b7c08;
          Mon, 26 Sep 2022 04:47:56 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220926010420.GA64437@www.zefox.net>
Date: Sun, 25 Sep 2022 21:47:55 -0700
Cc: FreeBSD Mailing List ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
 <20220926010420.GA64437@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbVch4lQMz4K5K
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RFpgvbGx;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.32 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.82)[-0.823];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-25, at 18:04, bob prohaska  wrote:

> On Sun, Sep 25, 2022 at 03:57:34PM -0700, Mark Millard wrote:
>> On 2022-Sep-25, at 12:34, bob prohaska  wrote:
>>>=20
>>> . . .
>>>=20
>>> IIRC I did try replacing the Sabrent enclosure with the Startech
>>> enclosure, which worked and seemed to implicate the Sabrent as
>>> the culprit.  Thus my interest in u-boot debug information. =20
>>=20
>> Looking at =
https://u-boot.readthedocs.io/en/latest/develop/logging.html
>> it appears the logging availability has to be enabled at compile =
time:
>>=20
>> QUOTE
>> Enabling logging
>>=20
>> The following options are used to enable logging
>> at compile time:
>>=20
>> 	??? CONFIG_LOG - Enables the logging system
>> 	??? CONFIG_LOG_MAX_LEVEL - Max log level to
>> 		build (anything higher is compiled out)
>> 	??? CONFIG_LOG_CONSOLE - Enable writing log
>> 		records to the console
>>=20
>> If CONFIG_LOG is not set, then no logging will be available.
>>=20
>> The above have SPL and TPL versions also, e.g.
>> CONFIG_SPL_LOG_MAX_LEVEL and CONFIG_TPL_LOG_MAX_LEVEL.
>>=20
>> If logging is disabled, the default behaviour is to output
>> any message at level LOGL_INFO and below. If logging is
>> disabled and DEBUG is defined (at the very top of a C file)
>> then any message at LOGL_DEBUG will be written.
>> END QUOTE
>>=20
>=20
> I looked at the page but didn't understand where/how to set
> those parameters. Do they go in a configuration or Makefile=20
> somewhere?  I tried using=20
> setenv CONFIG_LOG 1
> setenv CONFIG_LOG_CONSOLE 1
> setenv CONFIG_LOG_MAX_LEVEL 4
>=20
> [The numbers were guessed at]=20
>=20
> All showed up in an env command, but the the resulting u-boot.bin
> executable did not change size and behaves as before.=20

It may be that they could go someplace in the same file
that u-boot-rpi-arm64/files/patch-include_configs_rpi.h
patches. I'd have to go exploring to find out.

I'll note that:

https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h

shows it #defines some other CONFIG_... names, including
the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ).
This is at least suggestive. But it may be some other .h file
would have to be used instead.


Going in a different direction: Having the RPi* firmware and
U-Boot load from a microsd card but the EFI material from
the USB media likely would do you no good. U-Boot would still
have to get the USB media working for its activity in order
for U-Boot to find and load the EFI material that is on the
USB media. It is the same problem again.


Side Note:

I actually boot the RPi3B that way. Note the "efi_disabled" below
that prevents trying to boot FreeBSD's EFI material from the
microsd card. Instead it finds and uses the EFI material on the
USB media I use and EFI in turn finds the kernel on the same
media as the EFI material (so the USB media).

# mount -onoatime -tmsdosfs /dev/mmcsd0s1 /mnt
# ls -Tld /mnt/*
-rwxr-xr-x  1 root  wheel    18693 Aug  5 04:11:18 2021 =
/mnt/COPYING.linux
-rwxr-xr-x  1 root  wheel     1594 Aug  5 04:11:18 2021 =
/mnt/LICENCE.broadcom
-rwxr-xr-x  1 root  wheel      240 Apr 20 19:18:14 2022 /mnt/README
-rwxr-xr-x  1 root  wheel     5888 Apr 20 19:25:22 2022 =
/mnt/armstub8-gic.bin
-rwxr-xr-x  1 root  wheel     5888 Apr 20 19:25:22 2022 =
/mnt/armstub8.bin
-rwxr-xr-x  1 root  wheel    27425 Aug  5 04:11:18 2021 =
/mnt/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    29542 Aug  5 04:11:18 2021 =
/mnt/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root  wheel    28923 Aug  5 04:11:18 2021 =
/mnt/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root  wheel    27421 Aug  5 04:11:18 2021 =
/mnt/bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root  wheel    49825 Aug  5 04:11:18 2021 =
/mnt/bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root  wheel    49821 Aug  5 04:11:18 2021 =
/mnt/bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root  wheel    50499 Aug  5 04:11:18 2021 =
/mnt/bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root  wheel    52456 Aug  5 04:11:18 2021 =
/mnt/bootcode.bin
-rwxr-xr-x  1 root  wheel      968 Sep 25 12:49:00 2022 /mnt/config.txt
drwxr-xr-x  1 root  wheel    32768 Apr  9 01:06:08 2021 =
/mnt/efi_disabled
-rwxr-xr-x  1 root  wheel     7278 Aug  5 04:11:18 2021 /mnt/fixup.dat
-rwxr-xr-x  1 root  wheel     5407 Aug  5 04:11:18 2021 /mnt/fixup4.dat
-rwxr-xr-x  1 root  wheel     3211 Aug  5 04:11:18 2021 =
/mnt/fixup4cd.dat
-rwxr-xr-x  1 root  wheel     8416 Aug  5 04:11:18 2021 =
/mnt/fixup4db.dat
-rwxr-xr-x  1 root  wheel     8418 Aug  5 04:11:18 2021 /mnt/fixup4x.dat
-rwxr-xr-x  1 root  wheel     3211 Aug  5 04:11:18 2021 =
/mnt/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10262 Aug  5 04:11:18 2021 =
/mnt/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10262 Aug  5 04:11:18 2021 /mnt/fixup_x.dat
drwxr-xr-x  1 root  wheel    32768 Aug  5 04:11:18 2021 /mnt/overlays
-rwxr-xr-x  1 root  wheel  2959904 Aug  5 04:11:18 2021 /mnt/start.elf
-rwxr-xr-x  1 root  wheel  2235712 Aug  5 04:11:18 2021 /mnt/start4.elf
-rwxr-xr-x  1 root  wheel   799964 Aug  5 04:11:18 2021 =
/mnt/start4cd.elf
-rwxr-xr-x  1 root  wheel  3731528 Aug  5 04:11:18 2021 =
/mnt/start4db.elf
-rwxr-xr-x  1 root  wheel  2987720 Aug  5 04:11:18 2021 /mnt/start4x.elf
-rwxr-xr-x  1 root  wheel   799964 Aug  5 04:11:18 2021 =
/mnt/start_cd.elf
-rwxr-xr-x  1 root  wheel  4803496 Aug  5 04:11:18 2021 =
/mnt/start_db.elf
-rwxr-xr-x  1 root  wheel  3711432 Aug  5 04:11:18 2021 /mnt/start_x.elf
-rwxr-xr-x  1 root  wheel        0 Apr 24 03:58:58 2022 /mnt/timeout
-rwxr-xr-x  1 root  wheel   582752 Apr 22 14:56:24 2022 /mnt/u-boot.bin
-rwxr-xr-x  1 root  wheel   582752 Apr 22 13:14:58 2022 =
/mnt/u-boot.bin.2022.04.arm64

The above does not have FreeBSD present and has made the EFI
material on the microsd card be not-found (via using the
efi_disabled directory name instead). This leads U-Boot to
find the EFI material on the USB media instead --where it
has the normal path related names.

Note: Mostly I use the most recent RPi* firmware that FreeBSD does
not mishandle for the 3 configurations of RPi*'s that I have access
to to test. I also use my patched U-Boot build because of an issue
with the USB media that I use needing more time than normal for
something. For any later RPi* dtb set that I've tried, FreeBSD
crashes via use of a nullptr (plus a small offset, as I remember).
It has been a while since I've checked any new dtb vintages. I
also add timeout, needed or not. config.txt is my variant as
well.

(FreeBSD mishandles the dtb's by presuming that in the order it
processes the dtb material that there will be no references
before definitions, an order that dtb's are not required to
follow. When FreeBSD processes a reference before it has seen
the definition for what is referenced, it uses the nullptr that
it has not replaced yet.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Sep 26 17:09:13 2022
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 4Mbq3x4hq9z4YJGM;
	Mon, 26 Sep 2022 17:09:17 +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 4Mbq3w4kgPz3Fn6;
	Mon, 26 Sep 2022 17:09:16 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28QH9D61068553
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 26 Sep 2022 10:09:14 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28QH9DOf068552;
	Mon, 26 Sep 2022 10:09:13 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 26 Sep 2022 10:09:13 -0700
From: bob prohaska 
To: Mark Millard 
Cc: FreeBSD Mailing List ,
        freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220926170913.GA68300@www.zefox.net>
References: <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
 <20220926010420.GA64437@www.zefox.net>
 
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: 4Mbq3w4kgPz3Fn6
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.06 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.961];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Sep 25, 2022 at 09:47:55PM -0700, Mark Millard wrote:
> 
> I'll note that:
> 
> https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h
> 
> shows it #defines some other CONFIG_... names, including
> the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ).
> This is at least suggestive. But it may be some other .h file
> would have to be used instead.
> 
Looking at
root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/configs # more rpi_arm64_defconfig

CONFIG_ARM=y
CONFIG_ARCH_BCM283X=y
CONFIG_SYS_TEXT_BASE=0x00080000
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_TARGET_RPI_ARM64=y
CONFIG_ENV_SIZE=0x4000
CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
....

the entries in the file look to be of the right format, although it
it's a .h file. Adding a few lines looks like an easy experiment, 
even if it's not the "correct" way.  


> 
> Going in a different direction: Having the RPi* firmware and
> U-Boot load from a microsd card but the EFI material from
> the USB media likely would do you no good. U-Boot would still
> have to get the USB media working for its activity in order
> for U-Boot to find and load the EFI material that is on the
> USB media. It is the same problem again.
>

U-boot seems biased toward booting a microSD, which works very well.

Given that the FreeBSD kernel seems to have no trouble with the
disk, might it make sense to boot a small FreeBSD system from a
microSD and then run some sort of single-user script to find 
and re-boot from the USB device? All the machinery of the kernel
and system would be available to gather system information for
the (re)-boot step. I originally thought that's how it would be done. 
However, I'm no programmer. As you've doubtless noticed 8-)

It's roundabout, but u-boot seems to be a fairly black box.  
Great when it works, inscrutable when it doesn't. 

[snipped]
> 
> The above does not have FreeBSD present and has made the EFI
> material on the microsd card be not-found (via using the
> efi_disabled directory name instead). This leads U-Boot to
> find the EFI material on the USB media instead --where it
> has the normal path related names.
>

Can you explain a little more how renaming /boot/efi to 
/boot/efi_disabled works? If that forces u-boot on the 
microSD card to search for usb devices again it might do 
the trick for me. Or, do I misunderstand your intent?

 
Thanks for writing!

bob prohaska
 

From nobody Mon Sep 26 19:44:12 2022
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 4MbtVv15Tqz4cbrg
	for ; Mon, 26 Sep 2022 19:44:23 +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 4MbtVt0J7wz3dt1
	for ; Mon, 26 Sep 2022 19:44:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664221459; bh=52fmxc/b/haiIQTOpGFeq8yJla1ZVCG1Irfu+vjBR+Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OwVC9yVmuI8kBiu1U4OEcPpu4RcdSHTm7sfUMDojnv1lAjDHGaCGh4n746kvJwsPpKVoL3q51EJnqMZb/0oz+faRAzWtbp+ez14yLrvDLitIqUnG9omQnDYcFyffsdQKmPriEdYFoYhWLBVAxsBsNzEwFCeZDiN/sTv0tFmRwl9vCnrYIxZJpydp/oJHaf7rhVPUgcGvakVdAMFCOoza1VdYUtb+VJcOed3LwrOjcZH3Qpp/57IvEOdPpMNbyjgEmWv4yLJZgvOguSs2fwenUE6ZYQSr7qMieXziA075x4MVsPSRmsyfXTMAD6XOLIGJBBnbT/HAMLYSKiZ7JIHjnA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664221459; bh=mkQJ/4LacTALPHdwLRVKdefbbjg5tzFL+9lg0GjJ+ST=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VDWnIkpz7MCgmpzQmWLYxjcPK3mMWwJJYhUbcvdBBDvMo5Xc9RJjKmF+mNTSF0Kw/XmN6i8hsiTjVMYal0/Im3sJQRTE3tvtHu4vT71Pc7oXoZvxUoGmJzkMbzm5VwmFmsHHlmE+Q9SaA68X0KuMwoniG83nj7PKlEmaJbsQzZoBaMoSGoCOE2X+jTsCpF1OeLcQmvpbX/NWgSWVjLW+QfWGr91JR+OSJhGgG2rAugfHdpp3tLay6j5zcO4uvQAUCRM3Z28BjVl7idldmIHiaZVgGwvxuAxKDKH1JJjsHZCvsGHHm+PhnxjNmjj4iQTz2++vgmzVwD/FIKdA20eLaA==
X-YMail-OSG: nxz3uFYVM1lea6mf.K2gY1fwoc_uv91OS96s0z.hyovo8hIY8Sus1V6iAw1UwUn
 QlyPI.TBgBqZLnqthGaw_umKju.SmoCYR.k09NNpBJKC8KJmgFU2o9KDRlR_MEAtat3Y.81zu8CK
 jH7lN_KMvm_EEbzf5cgqeYed3KrxmgJyL5LgnPfookXgCgwEwSthdhd0ovclrzHeT_9Tjc1.96Wa
 5M3p_wkCJSkKqjvCgIfdAhqyVdQqMi8w77KlSiCKh.C4k981wLXgXSCqN5Fe0vqSNbTcRAuv7AIP
 h.Un03TZVfClIRZkk3.f6382B3OjyITmqlL2qVw.sfRauSiNI4DI62mwNLP_UMju4E6_JjAFFp0V
 zkZhPeL5v4zoAh31F4Bdbmh08Eyr1GXZRLyTLIQ.t25cDsHZvdQm8Q2zgsI.HyD2dKB1bGZTuNPQ
 oyQzMuxPaAhUgERYGdIUBvyCPsydhH49uPinlfdB6dpQH6l3z_k7K4Ki5xUURZQiBMQEoEoSFDX4
 zS9upDqwISK7hfHcO3snEY3Ii4a5swojWUhCEO15NOzixM2FJj6_B0APi9qsDvskekJb3OYgxRTA
 12iIQyzNZKbe9MsLUSLDDSICkZySZBPFrEe6oPJ35mHdISA3VrebkDS1fJLdFTFuI4hJB0pZxlP.
 w_.cz5PFe47_jv_2TEFJBczG6WETIyh6aYMQSmWTNWKsyF1q4Y6rYX4M8lKhTimnb9fJNPPb2R7K
 cqvKFvunFZ0yd1gYG99HgV98uvAFU94EmR3lrQikb4D81hdciPIrBL..5i.cuFFe44mXqQzu.fhi
 Ptou1XktfqV98i0gVrwK3sVJ50ZQ0evt7nC24v29An_hZ5I7jVai09IrzeCYMORoRJAtAyUmLMnd
 dCIR.RUJFGKgfTBXTPHgCN0PMoF21YfRyi3khix9z4jvAYTUspyewRnbvoLq2ynS6y8RbVzMXAK9
 MkHmvIOV7HDW3_GY1ZNU9a_WP__gKorjbnqP_JXgZfrGgURQiT6oiYjuz3kFoFD4CXh6GiVd2vtl
 ggS2mv22eG7RqrnIbd1F3qVxtlbw7s2zZD67BOvQaeDL9w1vJH5alz2ovxZqiTBHET17ZHVfXRh5
 64w6TYnzYX8kzctK87C2qGAZH7cJOXXDyEOTNIu.694hKrmiNk_ZpJjXCPCuwRCYc6oncV9M5bat
 ed4hNzBy._hJRSMTWrB._McxHRXOksLXrjGj8YCaomWZtVYlsiluG7erjSqTze_5i5HQQ6teoJ9k
 IQIsVjerUyQaHMSKh3lHR7oWHEMDS1o1LdtEVQTSAUcTDXZxMfRBllFEqoT4otsZyPoFJxgqqv4c
 PLjh4.WoyNUfrnPtRNdffIyR4.8Mnk39bb40Nf.kGigrQ2qTyxWry7HyobYMPCfYflt.dWHGQz7.
 jykpnhqbkQFIVUyH4c84sCjkbo2uwdlfCkgGl8xle5XYPGd29m6XIlE6ajRzD1dhPxeCg0jWq0m8
 VHIi7gncKxbSriSxmr53Sh2CswkekyDTId43FCqyfATLLJ2Fz74PF8GFg6Vwudcfs9oF7Q7Kr7Cf
 MrddpTWuZ2bgxaYD2Vd05E7gagfcDCjZoxsv4uoUgD.xC12F8rdSGXbxujw82HIJ0J9PSoV.i83G
 E7EzPwo87jxnWdTce1XdDKuiZjlNJlx7f6aklZnM7KMsLP6OPCCY_SPFPah9meHomY942cijr32Y
 AQfQAtCBIT6SlwRahwyom3BZSVOa51763b6L2XewgHS7zKtMpos7WS5SNekXh7NhXlsx5p0ym.fs
 0kjJUyC4xJ6dOGxXlvXVekZKym_0Utar3OXs78RYRNCE4xcCkATXQ8gOFd9Xedii.xRMil7s2aLz
 sIRHY.wvo7pdrpmn3rFmKF1lNU4rruWULdPIca3w96.GTM4GBo.MxkOFl5LkpTGCbWV3ZY_nwYNs
 sF938URaI9RfkL0wxp.utse8NWEheA0U8fmnjXB2daiAsIqt4_72f8Xfe1vzr9oU4IWsOgueAjCZ
 KeEj.IsHE4QkRGUDCdflyd9NQbBAcfNM7spJaN301otDiu7rxwGUtH1RrOobgEXTC1HajkPaBPNZ
 bpjvDWO0SxQ1HDyArqPKdELFYEqJK74qkrlBo.HCifBQP9r3WaSFPevbD3acM0mt7oS3fdwWxZL7
 W4y_fC7pNY3abF3z1260Kkdp9O_ZAebcnvM2IOQGSjh_U_bvKscoW3Dq0WPTXNaXepfsl4402RYm
 juFTDUfLaLKWB3AxEr2CmqvqLLVYrQX7D1lc5IW2q8Kk8AuxGg.Br0cQm48goOhcG7l9T5psZmx2
 qDc3aIQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Sep 2022 19:44:19 +0000
Received: by hermes--production-bf1-759bcdd488-hrxt2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43f5bc15294caab6aff254f9548d36f7;
          Mon, 26 Sep 2022 19:44:15 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220926170913.GA68300@www.zefox.net>
Date: Mon, 26 Sep 2022 12:44:12 -0700
Cc: FreeBSD Mailing List ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <39AAE1A4-8065-49EE-9DD2-C6C6736E3D8F@yahoo.com>
References: <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
 <20220926010420.GA64437@www.zefox.net>
 
 <20220926170913.GA68300@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbtVt0J7wz3dt1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=OwVC9yVm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@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.988];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-26, at 10:09, bob prohaska  wrote:

> On Sun, Sep 25, 2022 at 09:47:55PM -0700, Mark Millard wrote:
>>=20
>> I'll note that:
>>=20
>> https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h
>>=20
>> shows it #defines some other CONFIG_... names, including
>> the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ).
>> This is at least suggestive. But it may be some other .h file
>> would have to be used instead.
>>=20
> Looking at
> =
root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/conf=
igs # more rpi_arm64_defconfig
>=20
> CONFIG_ARM=3Dy
> CONFIG_ARCH_BCM283X=3Dy
> CONFIG_SYS_TEXT_BASE=3D0x00080000
> CONFIG_SYS_MALLOC_F_LEN=3D0x2000
> CONFIG_TARGET_RPI_ARM64=3Dy
> CONFIG_ENV_SIZE=3D0x4000
> CONFIG_DEFAULT_DEVICE_TREE=3D"bcm2711-rpi-4-b"
> ....
>=20
> the entries in the file look to be of the right format, although it
> it's a .h file. Adding a few lines looks like an easy experiment,=20
> even if it's not the "correct" way. =20

Remember that, overall, I'm not familiar with building
or developing U-Boot.

Looking around it seems that there is a file:

https://github.com/ARM-software/u-boot/blob/master/Kconfig

that includes other files, such as:

https://github.com/ARM-software/u-boot/blob/master/common/Kconfig

that contains descriptions of things like the below under its
'menu "Logging"' section (not directly #define names here: CONFIG_
would be prefixed to the name on the right):

config LOGLEVEL
config LOG
config SPL_LOG
config LOG_MAX_LEVEL
config SPL_LOG_MAX_LEVEL
config LOG_CONSOLE
config LOG_SPL_CONSOLE

It looks like this is used as part of seting up what to
allow to be controlled via the likes of:

# make menuconfig

in a normal U-Boot context (which ports is not).

rpi_arm64_defconfig looks like it might be a result of
use of that.

So, specifically for the symbols:

CONFIG_LOGLEVEL
CONFIG_LOG
CONFIG_SPL_LOG
CONFIG_LOG_MAX_LEVEL
CONFIG_SPL_LOG_MAX_LEVEL
CONFIG_LOG_CONSOLE
CONFIG_LOG_SPL_CONSOLE

you are likely right about where the definitions go.

But it seems likely that only things described in some
used Kconfig file ( such as common/Kconfig ) would go
in rpi_arm64_defconfig . So other symbols I(if any)
likely go elsewhere.

>>=20
>> Going in a different direction: Having the RPi* firmware and
>> U-Boot load from a microsd card but the EFI material from
>> the USB media likely would do you no good. U-Boot would still
>> have to get the USB media working for its activity in order
>> for U-Boot to find and load the EFI material that is on the
>> USB media. It is the same problem again.
>>=20
>=20
> U-boot seems biased toward booting a microSD, which works very well.

So you blame U-Boot instead of your drive/bridge combination.
I've no clue what the detailed issue is that leads to the
mismatch.

> Given that the FreeBSD kernel seems to have no trouble with the
> disk, might it make sense to boot a small FreeBSD system from a
> microSD and then run some sort of single-user script to find=20
> and re-boot from the USB device? All the machinery of the kernel
> and system would be available to gather system information for
> the (re)-boot step. I originally thought that's how it would be done.=20=

> However, I'm no programmer. As you've doubtless noticed 8-)
>=20
> It's roundabout, but u-boot seems to be a fairly black box. =20
> Great when it works, inscrutable when it doesn't.=20

The kernel and world do not have to be on the same media but
splitting them makes for a non-standard updating sequence to
be needed. Somewhat more than the kernel must have
copies/variants on the same media as the kernel because a
couple (or so) files are accessed so early.

I do this on the Rock64 in order to allow world to run from
the USB3 port. (Its U-Boot did not know how to deal with
that USB3 port last I checked. But the FreebBSD kernel does.)
So the kernel used is not on the USB3 media but the world's
materials are.

Going this sort of route of not getting the kernel from the
USB drive, you would need to figure out how you want to do
updates to the kernel and world. Some things may need copies
in both places.

The EFI material would go on the same media as the kernel but
in a msdosfs file system with the proper path in that file
system.

> [snipped]
>>=20
>> The above does not have FreeBSD present and has made the EFI
>> material on the microsd card be not-found (via using the
>> efi_disabled directory name instead). This leads U-Boot to
>> find the EFI material on the USB media instead --where it
>> has the normal path related names.
>>=20
>=20
> Can you explain a little more how renaming /boot/efi to=20
> /boot/efi_disabled works?

That is not what I did. (Warning: In my environment I use
lower case names in places where FreeBSD by default uses
upper case. The below shows upper case. This makes clearer
just which thing is being referenced. My use of lower case
was not a good idea.)

/boot/efi is in the UFS (or ZFS) file system and is a mount
point. The thing mounted to/in it is the msdosfs file system.
That file system contains the likes of a path:

EFI/BOOT/bootaa64.efi

(which is the path that U-Boot looks for to find the
EFI material).

Having the msdosfs file system mounted at /boot/efi leads to
the path:

/boot/efi/EFI/BOOT/bootaa64.efi

(starting from a UFS/ZFS context and reaching into msdosfs).

Note that in U-Boot /boot/efi is not involved: FreeBSD has
not even been started that that point and there is no
active UFS/ZFS file system yet. So no /boot/efi is active.
U-Boot directly deals with the msdosfs itself.

What I did do was to change (on the msdosfs):

EFI/BOOT/bootaa64.efi

to the likes of:

EFI_disabled/BOOT/bootaa64.efi

This prevents U-Boot from finding/using that copy of the
EFI material --so U-Boot looks elsewhere until it finds
an example of:

EFI/BOOT/bootaa64.efi

if it manages to find such. That EFI in turn finds
FreeBSD's kernel in other partitions on the same
media as that EFI (at least by default).

So I have an msdosfs partition on the same media as the
kernel and that msdosfs contains a proper file with the
path:

EFI/BOOT/bootaa64.efi

> If that forces u-boot on the=20
> microSD card to search for usb devices again it might do=20
> the trick for me. Or, do I misunderstand your intent?

The point of the note was that it would liklely *not*
do the trick. In your problem context you have to avoid
U-Boot trying to use the USB drive at all or the problem
likely would just repeat.

The problem is not where U-Boot is loaded from. The problem
is U-Boot and your USB drive configuration do not work
together overall when U-Boot tries to get the USB drive
set up for U-Boot's use. Avoiding U-Boot trying to use the
USB drive at all would avoid hitting the mismatch
consequences.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Sep 26 22:50:34 2022
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 4Mbydq3gKjz4YFWd;
	Mon, 26 Sep 2022 22:50:39 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4Mbydp6H2wz3yhp;
	Mon, 26 Sep 2022 22:50:38 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62f.google.com with SMTP id z13so17165424ejp.6;
        Mon, 26 Sep 2022 15:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=MbMPA7x/A2yAPgohIXLok+OJlYfZYa43rw1kdTd9prQ=;
        b=kNT46Ng1d0caEuodDsp7rf6OoD4KGhpQ5SYzMOk88YwXRtGxQ+ulK10+RLHtqOva9e
         xfj2bu62XsQrCARFfgxdkIGqHs5w6O495otxNVnIHI19URLGA6+pHrMpVcOkCUmDM/7K
         YsFGvZxmoV4I2wS/VooD3zlfXuupG1EqkNOP84+OQNPrMrDtUwZVTrZ1ErPkWiSkNlZ/
         W9wPv9vf3t/gAKcZM7IZLzEzHtXCmGJkvHz8iK8qVIvHW7zx9TP1tGbd1cR1LQnveiKv
         CgpF78vimnAiK9agfhRXu+ipHzPqCwgQqA1jmYUFSQxWrR7CDSoi44I/zWqcaSsT9K8P
         onwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=MbMPA7x/A2yAPgohIXLok+OJlYfZYa43rw1kdTd9prQ=;
        b=mMcfHEBfcJx3islGBS9QeF0fbZVDFyFPsSp2FRbi+PXzdKoc/C7TwVwRcBCdouAHuY
         bSdvpUgmxezyUyS3/giH0bMvIrHTD0D1X175N1Gap1wHii2SBb9t6Co6bSJQZZnJMltT
         oVMVtGER5em9lmJ008Y9ga2hFVrmCMxuPg1f3kRSMpwiER+C8xR+4a6NhsC1qjcNqy6Q
         Rcw3Sf98PzzojV7DbRZak5fKce22BuSgJgCpMZeNZDgNA3uQgU58iG2GavR7iP7q71Al
         X30/fJkgGtfQwk532h2gZ6aWMzOnefHtBFH2rZYpgJ6VdtsvrizX+RFGcy3Vzz803u5H
         ipsw==
X-Gm-Message-State: ACrzQf29cLK4N7o3+KOKEk+7TiEWHe0sLiPvCbwvTAOq06a47wlFuDcY
	b2m/HQRY5q2zGfj5UKu1vKY=
X-Google-Smtp-Source: AMsMyM5m7BJxlVcUd9mHG6lQfBouuZTaw5PKttx2RQeInFSSxendxT+gCreU8GJDUpE5kSo6EVrNug==
X-Received: by 2002:a17:906:4bd3:b0:731:3bdf:b95c with SMTP id x19-20020a1709064bd300b007313bdfb95cmr20477134ejv.677.1664232636902;
        Mon, 26 Sep 2022 15:50:36 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-186-229.46.114.pool.telefonica.de. [46.114.186.229])
        by smtp.googlemail.com with ESMTPSA id p13-20020a056402044d00b00456d2721d93sm7119651edw.64.2022.09.26.15.50.35
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 26 Sep 2022 15:50:36 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 00:50:34 +0200
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
To: bob prohaska ,
 marklmi@yahoo.com,
 freebsd-arm@freebsd.org,
 freebsd-ports@freebsd.org
In-Reply-To: <20220925160531.GA63213@www.zefox.net>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mbydp6H2wz3yhp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=kNT46Ng1;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-ports@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

> 
> bob prohaska===Mark Millard / u-boot debug

hint for you both :
based on my experiences from the past
you could ( or should) focus on u-boot`s  
common/usb.c  file.
e.g, you can enable debug and e.g change or expand the usb boot scan delays.

Regards
Klaus







From nobody Mon Sep 26 23:41:48 2022
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 4Mbzmw1nwMz4YLdN
	for ; Mon, 26 Sep 2022 23:41:52 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636])
	(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 4Mbzmv2tdKz42x9
	for ; Mon, 26 Sep 2022 23:41:51 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x636.google.com with SMTP id dv25so17284244ejb.12
        for ; Mon, 26 Sep 2022 16:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=Uf06Lipeo6c5vKsA3o3HEGt7sFxxhLNUbH+eQZy9m50=;
        b=ajXRm/KlyFN7fMzeCrm4TKwVhDrG5IzuJ2WxZDjukmOzid9v/ntZ36eRviWo20+oUZ
         T+mCV7P0DtyxJWzqKZvIqKLyY0GAV2WpOSisuF9Fomd5mkgZTsJQ/Ep+BkGBHXX/kA9B
         rQgUdV+dTzsz8AnCaQhSVzmSe5tHv+pxuaVX5L0lly296Q6YMvUkeVO7G49/KvgP9PGw
         DN30xYbkF3NTCBpFv1YqM9b/IWdcMXbYO0q5Z2IlRSkEUuW8m0Ae22hSHbM4AXIqRIoP
         jpEYPcMLpTHbfbxcUgFaH2nAS6kI2O0XDsaZptMPH+Oc/dJJP1v2xN5b/EPlKhoik5oy
         yEdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=Uf06Lipeo6c5vKsA3o3HEGt7sFxxhLNUbH+eQZy9m50=;
        b=3TNI30Ft+c+V2gVRtOvXP2jF6rmOAtwthQlxvlF/OsojUEp37DaP/PxhWZVzUtUlbF
         3ciCZ3HHkSCLs8Z7ghh7dYtrHoJJwu+8rNngLQmEltJgRVfJVD3WLQdJVX17WIllcxb5
         xEW0ePx5zFxxf50k5PIjBweiEOsqmihJbGZSEDU3I0mbc7rj3OqdKOiRXOCM3h5gFCGJ
         IQDh1w0pGSLv/auhnfEtBL+ygbmwAta1dhrcGURDjuLc1tyW2bEXPOtXM/vePg0FQfFh
         p7jErg3wrXO2TRGcy/PtdvM/c6EYgqWnpmTAbhq/pR6wTqxv1CQpDjyrCHOnMrdjeKzj
         BiNg==
X-Gm-Message-State: ACrzQf3PO88McW9ozAfVEi1fyaUtlNSU0sM7DvV5MFQEjbJ6GSGOBoFX
	WEM+p3O6sQbIZtwk0cSrgJf214ZAEO0=
X-Google-Smtp-Source: AMsMyM7Bq51i2794ZkPu+hPT7DaZP3p8MK1xC2f3998kq6iTc5LnGxUE41CGnzWuyVXr9TgbosP+bA==
X-Received: by 2002:a17:906:cc10:b0:77a:fe95:eae2 with SMTP id ml16-20020a170906cc1000b0077afe95eae2mr20674149ejb.466.1664235710127;
        Mon, 26 Sep 2022 16:41:50 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-186-229.46.114.pool.telefonica.de. [46.114.186.229])
        by smtp.googlemail.com with ESMTPSA id s11-20020a056402164b00b0045754cd5e08sm38307edx.39.2022.09.26.16.41.49
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 26 Sep 2022 16:41:49 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 01:41:48 +0200
References: <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com>
 <20220926010420.GA64437@www.zefox.net>
 
 <20220926170913.GA68300@www.zefox.net>
 <39AAE1A4-8065-49EE-9DD2-C6C6736E3D8F@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <39AAE1A4-8065-49EE-9DD2-C6C6736E3D8F@yahoo.com>
Message-Id: <6667A6C6-500D-4287-98F4-1A712A0A4C85@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mbzmv2tdKz42x9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="ajXRm/Kl";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 26.09.2022 um 21:44 schrieb Mark Millard :
> ..
> in a normal U-Boot context (which ports is not). ...

the port downloads a totally normal u-boot file and unpacks the =
(unpatched) original sources from there.
As far as I remember for even the RPI-specific freebsd-patches were =
mostly(or all) removed.
While a bit fiddly then to configure you can download every u-boot =
version you want and compile  from within the port.

good luck hacking common/usb.c.    :-)

Regards=20
Klaus

=20



From nobody Tue Sep 27 13:23:18 2022
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 4McL0l2zlhz4d0Dv
	for ; Tue, 27 Sep 2022 13:23:19 +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 4McL0k62vzz3T6F
	for ; Tue, 27 Sep 2022 13:23:18 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4McL0k4yPkz17R6
	for ; Tue, 27 Sep 2022 13:23:18 +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 28RDNING009350
	for ; Tue, 27 Sep 2022 13:23:18 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 28RDNIIJ009349
	for freebsd-arm@FreeBSD.org; Tue, 27 Sep 2022 13:23:18 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 266657] Clearfog pro boot hang
Date: Tue, 27 Sep 2022 13:23:18 +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 Many People
X-Bugzilla-Who: trees@neti.ee
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664284998;
	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=bhI3fdRoKg86kXvNwCb7/uO5Hoq+pgeMO3bc5QDh6LI=;
	b=QKkm4EZ3dXT87nwFrXWLU8tdkcqDkYEX+kPmz8x/hUZ+Vvy+CMmiK8gVJHi5jEpepu+w2h
	Vmzf+RyUkSPhCxDg8NSSqufaRM3eQP+ZErm5VxEOm7fHcIdNrkwI9w34aEootqeO3irh1U
	r4h5z7sp0wmIQFjceWRhM5nKPKNlhvUefBoEF8ZhGOkxhhhwvC9PTXKLqjfr/a88gMwHjE
	WGVKS47zRyL85foTVwSiHBiPV0cQ1vuSu4mKfK3jq5Rl7Iyv9hFumNph6hTStxE4IPmHv/
	Oz/V/AGm+i2Upi7mDczfRQERRGxcYwCkhXVXkV5/nguPV4IdSKztf8g76ti+bg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664284998; a=rsa-sha256; cv=none;
	b=JlIEE8bejrD/WuDmvft9hYdx/bjj8D4SVrwrW278ksvFwFKAmXXf8nKji9N6b50daHrm6v
	c/riq4yB2pXZmrQZIAACoY7kVqW5LNP1JyRtIHl22YK/4CB9mXFDzbeZdGBOCPeizjYdNY
	k2x8nM9pgrZNahX9RVnBH+rBCeRO+mDj/pQIYJPqih1FcW5Z6LOB/F0AJIvmujAQnIb9KL
	bd2P432vVQswjgu7TfNn3KQzks+lDldlsSsUag2usf11SklmDFxBECVd8VxMAdxfMYrUww
	XraFpse7RL3QlZLvHL7EER4aVpgamF3YIGluUur/QBjF8CxaeazGJ0HOP82Dlw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266657

            Bug ID: 266657
           Summary: Clearfog pro boot hang
           Product: Base System
           Version: CURRENT
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: trees@neti.ee

Created attachment 236875
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D236875&action=
=3Dedit
staller clearfrog pro dmesg

After commit 'Import device-tree files from Linux 5.17'
(https://github.com/freebsd/freebsd-src/commit/e67e85659c0de33e617e5fbf1028=
c6e8b49eee53),
Clearfrog pro not boot up any more. Then I make rollback
sys/contrib/device-tree/src/arm/armada-38x.dtsi file all start to works aga=
in.=20

The stalled output is on file staller_clearfrog_pro.tst


diff --git a/sys/contrib/device-tree/src/arm/armada-38x.dtsi
b/sys/contrib/device-tree/src/arm/armada-38x.dtsi
index df3c8d1d8f64..9b1a24cc5e91 100644
--- a/sys/contrib/device-tree/src/arm/armada-38x.dtsi
+++ b/sys/contrib/device-tree/src/arm/armada-38x.dtsi
@@ -168,7 +168,7 @@
                        };

                        uart0: serial@12000 {
-                               compatible =3D "marvell,armada-38x-uart",
"ns16550a";
+                               compatible =3D "marvell,armada-38x-uart";
                                reg =3D <0x12000 0x100>;
                                reg-shift =3D <2>;
                                interrupts =3D ;
@@ -178,7 +178,7 @@
                        };

                        uart1: serial@12100 {
-                               compatible =3D "marvell,armada-38x-uart",
"ns16550a";
+                               compatible =3D "marvell,armada-38x-uart";
                                reg =3D <0x12100 0x100>;
                                reg-shift =3D <2>;
                                interrupts =3D ;

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Sep 27 16:03:28 2022
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 4McPYW2LgPz4V7Nq;
	Tue, 27 Sep 2022 16:03:27 +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 4McPYV0hx2z3lqx;
	Tue, 27 Sep 2022 16:03:25 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28RG3SvX071825
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 27 Sep 2022 09:03:29 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28RG3S0j071824;
	Tue, 27 Sep 2022 09:03:28 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 27 Sep 2022 09:03:28 -0700
From: bob prohaska 
To: Mark Millard 
Cc: FreeBSD Mailing List ,
        freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220927160328.GA71742@www.zefox.net>
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@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: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
X-Rspamd-Queue-Id: 4McPYV0hx2z3lqx
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.00 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.90)[-0.904];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Sep 25, 2022 at 04:43:15PM -0700, Mark Millard wrote:
[snip]
> 
> Because USB3 introduces various differences, some testing
> via the RPi4B USB2 ports is appropriate.
> 

That turns out to be an easy experiment. Here's a summary: 

I have two identical mass storage devices (Seagate Barracuda 1TB)
in identical Sabrent EC-UASP USB-SATA enclosures. One runs an old
installation of -current and is connected to a Pi4. The other runs
a recent 13-stable via a Sabrent USB 3 powered hub to a Pi3B.

Neither machine has a microSD card installed.

For as long as I've had them, the Pi4 running -current has booted
reliably and the Pi3 running 13-stable has failed u-boot's disk
discovery on reboot around half the time. When u-boot succeeded,
the 13-stable system ran perfectly until rebooted. 

After swapping the disks, enclosures and cables between Pi4 and
Pi3 (including the hub) both machines booted on the first try,
every try.

Moving the 13-stable (troublesome) disk to the Pi4's USB 2 port
didn't cause any problems either. The disk continued to boot.
Restoring the original setup restored the boot failures.

The u-boot versions are different: 13-stable uses u-boot-rpi-arm64,
compiled yesterday. The -current disk still uses the u-boot that
came with the snapshot used to set up the disk, reporting
U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)

Config.txt is identical apart from force_turbo=1 on 13-stable,
which didn't make any visible difference when added. 

Using the older u-boot on the 13-stable disk didn't have any 
effect. Are there any other files that alter u-boot behavior?

It's hard to see how the hub's at fault, since it works with 
-current.  

I did look at common/usb.c but it's far from obvious how one
can turn on the logging feature so as to report more errors
to the console.

Thanks for reading and replying!

bob prohaska


From nobody Tue Sep 27 17:58:31 2022
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 4McS6N636Yz4YKhS
	for ; Tue, 27 Sep 2022 17:58:36 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4McS6N0BTjz40DL
	for ; Tue, 27 Sep 2022 17:58:36 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62f.google.com with SMTP id lh5so22312769ejb.10
        for ; Tue, 27 Sep 2022 10:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=J6wjBZadOa9WVON6rQPHpvzFVodrCLdcfHNv74ybmqY=;
        b=jwRkQfTcS5erQ3Ijxhw5YlYGQXntG+HfEr+p4udaFY99I3//V5t1rO50U5LXIEFc3V
         bTnBY/IWlRVFyMXDKyrLIGtdifx4LQXmxstP99sglQSiXCXyL8PydZWQbivP43zvEtNE
         z4+ol7QbvU1kRHwY2YL4S29QtoSLGvjdjy0V9aV1wLpAv85pjzO/YPRjpg6i+x+yD4P9
         g+uzEa6/vtDrhiTlLc5GnwTu4V0IVrV65KXCRmzNeiJAASjnfq1HE8U4i+odN1w/+7s0
         +it5L3yIohG0AG7WYhX5aeIQk3VToOoseBVoUrwtwMR1pfrYdRWTS5KSsBaVWjPVXtIH
         gDBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=J6wjBZadOa9WVON6rQPHpvzFVodrCLdcfHNv74ybmqY=;
        b=g3UmXjyyjKGJu8f+tltK9JZXo+fxfaul6ixgio8iZNSpy5C9TZAr0fEXwVebOwc9rN
         SOHWEYEgeLqXvyFAgZRnVox3qwrzgdAuV89g5PxZ7Xa7EQ6TegajX0VJ3WqyvcHDb6lR
         FzlI4Y6krOL9xKlSVZOW4K0kGnOvQP6W8oeJ3sCE9RU+8X1PQ6B8hC9iAoQ66fAkpfdM
         TfXguClewQRzUrn6yYywNGky9GYLSG8dySUJ2bvJZ1vafunvnVxgvW9LH9mO0SoILeYW
         7M/+KYd8FB8bs9AgqJnN3CgfXOfqYQ6m3vO/lWRa/tsNZnPNawBNRBwCCu06eI7nt9Oo
         9fdw==
X-Gm-Message-State: ACrzQf2fzfpphkEo6B6UL0AsxDsLnkuwtG6FCVV74GdiwO2rsGWf4ZsQ
	bKtGhCCOkQfZVwuRtI+AjDKQoPiI7X8=
X-Google-Smtp-Source: AMsMyM5iIDi8ppH1gyjz7CminqWme/BG2VGVuwFoZjpyzlAgpzDs7inBCxRQM/Ex7mqBG2ZuAJ4KXA==
X-Received: by 2002:a17:907:a07a:b0:77c:f98e:ab8c with SMTP id ia26-20020a170907a07a00b0077cf98eab8cmr24289676ejc.69.1664301514714;
        Tue, 27 Sep 2022 10:58:34 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id a3-20020a50e703000000b0044657ecfbb5sm1693958edn.13.2022.09.27.10.58.32
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 10:58:33 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 19:58:31 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
To: bob prohaska ,
 freebsd-arm@freebsd.org,
 Mark Millard 
In-Reply-To: <20220927160328.GA71742@www.zefox.net>
Message-Id: <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McS6N0BTjz40DL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=jwRkQfTc;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,freebsd.org,yahoo.com];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>=20
> I did look at common/usb.c but it's far from obvious how one
> can turn on the logging feature so as to report more errors
> to the console.

you can add the following to common/usb.c (e.g. insert in line 44):
=20
#define DEBUG

--

that should then print out all debug functions inside the usb.c file to =
the console=20
after recompilation of u-boot.

Regards

Klaus=

From nobody Tue Sep 27 18:33:33 2022
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 4McStp2Lmzz4YPZ9
	for ; Tue, 27 Sep 2022 18:33:38 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4McStn42XDz43p8
	for ; Tue, 27 Sep 2022 18:33:37 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62a.google.com with SMTP id bj12so22471237ejb.13
        for ; Tue, 27 Sep 2022 11:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=sweIS2d1XVqCTo4o9Ae/KkG0XzUc3l21GA39+riPzII=;
        b=Pb+6+13Cb3cfGB8j30i5Hw3ZedFQivyigaNTNHTUeK2gG24aL9O8DPdnHwN9Ia2uAX
         ROuPhfpXm4wlABsn6BNZ0Y2kwZAtTVgVZEEfM0mDiFixKteXockHyPVs883EmRpzfEF8
         9eBf5rf61a/yt6snc3k7XqZxuZdPYOWM+G8bdQjfMTmZwD28cin0VjB6Ga1xhAh+Kdp8
         cnYUk08JipVZvLmPXU/8eLzwtOU+yvQOjBZVTdecPjUic/2OcocHg/9tfow9WWFakpje
         kXxykcpPZY5mBHmTnRlmwFdObXNrbmY8whd7Vhba291Ma7+tNurvw4/c6gW40jGy+sKy
         GM6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=sweIS2d1XVqCTo4o9Ae/KkG0XzUc3l21GA39+riPzII=;
        b=gKz5T9gscvEnKBUE2ULehQR9ZtGVg4OM1DVyUlU3WC5GMIIMQY5izUa8nzjd/8NNzx
         U8a5iX0myQMQjKZUfGBTj03tKHA1rfwVpes+EcGUT3cUx7x8VRigGrGV3sGMU2148gLF
         S0KIr2/vnqm07D/Vbf0iPI5GVPsS06pB1yo4vYdCyUHcFfs3DD9p5hYTeBU5Zloj76wu
         w7vDNoPZrEaaFgyipTWykPlaBBe/lcOIFhBUxIeGCTu2xTa9EyZajiDflDkzlIIGXZfW
         Xd/EG4kTJw4B9aPcPExEIJAcRyE8rBar+q6TsqkF2Aq6lbz20vsqw4L4dsP4LQedjDMp
         w3Yw==
X-Gm-Message-State: ACrzQf2mU3E+XDdM6QJ7YiD4Dy9a/dVEt7LMkoTZ5kCFbQPD/u0bLpfE
	TMCPAv17WxXoudLM16tW7qI=
X-Google-Smtp-Source: AMsMyM60wfKi1tEkORrKsx2XNwELqfhufaFCnN8l9Dkp+xi1QPIzARDBAlhneth6cY/qsDX8jl+VTQ==
X-Received: by 2002:a17:906:5a6a:b0:77c:2c7f:bd69 with SMTP id my42-20020a1709065a6a00b0077c2c7fbd69mr24379193ejc.283.1664303616239;
        Tue, 27 Sep 2022 11:33:36 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id gh33-20020a1709073c2100b0077d6f628e14sm1153444ejc.83.2022.09.27.11.33.35
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 11:33:35 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 20:33:33 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
To: bob prohaska ,
 freebsd-arm@freebsd.org,
 Mark Millard 
In-Reply-To: <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
Message-Id: <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McStn42XDz43p8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=Pb+6+13C;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.60)[-0.602];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,freebsd.org,yahoo.com];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>=20
>=20
>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>=20
>> I did look at common/usb.c but it's far from obvious how one
>> can turn on the logging feature so as to report more errors
>> to the console.
>=20
> you can add the following to common/usb.c (e.g. insert in line 44):
>=20
> #define DEBUG
>=20
> --
>=20
> that should then print out all debug functions inside the usb.c file =
to the console=20
> after recompilation of u-boot.
>=20
> Regards
>=20
> Klaus

I saw there is  /*#include */ available in usb.c=20
so you could also try to add :

#define LOG_DEBUG

to the common/usb.c file which should also then enable the debug =
functions
which then would be output in logging style.

You will need the debug output to to narrow down the issue.

just a guess :=20
electrical problem(of the Pi itself)  which could perhaps be fixed by  =
manipulating the scan delay time .

Regards

Klaus



From nobody Tue Sep 27 19:20:40 2022
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 4McTxD1rkdz4chxZ
	for ; Tue, 27 Sep 2022 19:20:48 +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 4McTxB5bhFz466q
	for ; Tue, 27 Sep 2022 19:20:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664306445; bh=3btk8fkch2w9FMs/8J9gzWskHhhKFUSZql8OoySjRsg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=s7V1YWR8CCP/jSQ3iIjHxDmc8D1Yudf3m+vSGmtkENUG2C6gCdOBwynXesthLaIBIfJruoqiOaFxrW1mr5iYAylV9YzZR7R4zZAQ//fz01rjmTW/UB/w3ZwX81hU7P1Iz41Orw/EPXHYByocS2RKUs6IoC2O8kbsbrptIIWDe0BIUApVg48jZxUyPiMxkBRucJMhwMIV9+rF/Q/rZHzZqK8fwZXdRI2j5cg6PHxHtHm8nDnMNIslBZCQILebqPi5O1q4YO/H5cP+AAhF2MKkMtyYlzNQ8zv796R1dsP6ubcetyLkIosm+aq5bjjmE1HZkdnM2IvGfnt7q+jCID3JRg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664306445; bh=yhvzshJSiun3Lp1YHMxp5zlfnr3sik2ZbvrX6HSSAjH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F2RIJ/d3YziA8m2xeFP+Niev0sNHYg6+4P7nP8EEWSVWG/JgkktR5pqe6Xk0aVA67RZY768roLUfmMmPUhEvJ46kMMJvPumdffRPuiOVASfeDbGmDJKw2ouD+DroeVcquFABedkYHysn/YJjdXxkx5UNxk5LceQjF8FeEhv1qYQ1Ca8f74dJcVTaPJT5XYx+GgV96U32bwoRlw0Z3VIFTE6tWG9CsjmjK/RxK0cjZU9CYCN2O6TolhTPE7M95Qgvu/i83RSPQmdIoWdshCRKiali5tI41jRDOVpXZXg6OtQoIiTqRajCcnwySTkOf0jF+2r/byienMtncXhxrf1yiQ==
X-YMail-OSG: bTPFAhIVM1mkTPhusFFxWl6Wqypln3Ll_d5N_GQt5HHIleoKGj911h2v82gg64a
 4AeQ9P8RVDvgeCXo_Ut5fxwb45GeMsqtaxrl.PRZ8rcO.CmDekMRyaMaqggn2uMoSj_Hik47GuRh
 VtNQu4iwwpamHOJ68NmekDmeGoFgxlrikZRURL.PqkIWI_SXKybjAFphBFddIPTxu1WI6pavjqYC
 AwJIpCbeXwcRVNTZUXUCy.zHHo6imHNjJR2po8gz5Sz4oGlI9XqDfIFSL8cvlS8NLIqUocWtwWiY
 RFJxvxIXu5f9w.1M_vwUcgYEiiCGEj107TzP72azTnnSmWhaBh4Yl_QjXa5dkSrsKRsWom.Lt1uj
 tQCTC_R6m9oBtMkoCq5qo5MPbVDaYZiU9Mjb9mpr6WKmDfJfxTi6QMESlaviAnEn9UrRPN7ejqkN
 MsOZTu68LP4waYfUvtfDjuXo6.uuBfow0jIWh3Eqcbjdv1VHIRP3NT91ns8U7j0yQ2vqwECbUs.H
 qwKDbgwpKY9odY6mb2BEzn73SO9TsJL6f94MrYfS_5kKvb5oWEpogh9KvU5hnC8d2mH9sD8SMq99
 .4gJL60L_K.0tkE5MvdpUu7K8hCEhZfMvnm5hrkionxoDlfLeHo3mxobXeQA.S78k8z9gyOosNX2
 1jMFjNBPtV8W6EPYwkTz6AeGnhUg54WTZ4SwDCLZrAEnVxziAueQCnLu4kUFbcp7Ky2Q3xqb1kxa
 AUNtK2RV96L7d8bRqkar9_UVW2w12eTs9nBEjSKyQyx6QyXMBSvdF_5fqzIlKgDOzXCp0gdQZaXH
 .XDKB24NQniljejogQvj5N3T6Wx2dqgN29_ec0oUB4aJkqjiwT3rT3H3bYz_jLcWsuJjR4kcDr32
 97AAPbfcdtoScPq6gY4GIC7Q68Hvqi3D0NapD.L99eOhaW.Q9Xs8ZSUZcvlmnaH.fQWMS1FeaUlv
 7gU.I7wno0S02nm0_Dfzf_JhBPqYVWEnNYFfYH26w3T_mSLeupHf_R2Sitiz7ZhN4hTSdnoA_kY7
 uBS9O8UGOkHMaY6vAdRskZE7ctoUF18LOGsmcqIlCWYZzW2GmtlOzGmOKwRmsZZrE7PEqVREF8eV
 NFySE4RkQ2fJWRZzWDm9hAZQNcYMkXO.DILfbluAH5YUswpCI4HACeaELOYPJAoY3j_xfSZ_x8y2
 Q6QY0aIWCO3b7tnzLLi9XDnMRqucmRqWodb1l2k56va.36wM3PA5S8bead4spyWgMCdogFMGlAaU
 s5ZbQm8lA7t.7X24nsWYl7fhEEmK7p9qGMsM3uz0T5066XLWeySm5k0YOxZ1JgyNPcroOpzG_n3q
 OZBoOyOC1Sm9sqmHqevQjMKDSSjAfu7vfW1_EliwvjkvJCvpvcSNtBaTjZRjruIgT6tFkggS5y8m
 qmmE21pNpEnwr2TbvQI9Zt82EDmjDIY4QBGCiv6d51JO8FZqM91Y4hSKac60mFu6xhyLdaBmFD0K
 ClUzm6XJdF.assZkG96Eh73eBoU8eQzuU.INvnOIRUyeCNSuRGiiz6uq56rlKzxD_ltcMHjhvNNP
 qVCITu1iOY4yJWP8Y5dJnocYhrlEYGSSsztI4DY0xsWwJ3l3ajsv4lvo_T6MOrCm9MWyuxySL3i9
 rimZnPmCFQeKmgZde5xoVxj2m2i9zIPCeKw_meMDqYndaYKf3h6IqA91lu__h.7es1n0uK1F8MVe
 dZBRblvhpppXXLl0LS5gOlVfl77y8ZM4aTS_slqbW6Eqt6yXPc8JBRM77nYqKJUe3gxLrb0SX5Ql
 I8dmLH.4IAv9H2RtwNbjHmWV.Y_ImdjZU5dk4K.4X.6grdRJGsE5jB58YmWD8MzyROFvNElTDDvx
 fXWOJA6MUWgHs9sIxiRFWX8nLxcwa1QaktQpYXNINo.fxNg0sxMGq3hJTO71lRkw4EIshpls4YDF
 8gG_1P7DY.8dDlB.QPwKP5MpPKAhlA708YqdcO9y3sZvAFnCB8Ybo1y39hruDCbgC3ESIEs.zMv5
 4ocPntj6VNQsJukM4XAOFkb179hiW8mcw6fAvb7SmdYt0FmkGlrZo1IgeSolhldZGq6Zhtx7RI2a
 cmqlxDci8io_rd3t.64pfAwzhF9XC8jI4HBzeVHtna1Go8P7K.qi.x0rGnzC5cTnNKmVOFcFQHks
 6sELQEGZB75rvnP3YcOvd_zdQ0lr8Jj6vo40BJ9BukTaQAlre2aYedJhXeDCKpyAW1uApTnA_kHU
 HHMKI_mcHdPssnJLqvAdOfhpDHNQGsPSBA1kxHMuzYB37DkQ.JvTkbTOBVBySKX91zo4MNDp3CdU
 VOmb_GSzc
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Sep 2022 19:20:45 +0000
Received: by hermes--production-gq1-7dfd88c84d-9chzc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c12e233e3654473d0d325959813d1d54;
          Tue, 27 Sep 2022 19:20:40 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
Date: Tue, 27 Sep 2022 12:20:40 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McTxB5bhFz466q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=s7V1YWR8;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 11:33, Klaus K=C3=BCchemann =
 wrote:


>> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>>=20
>>=20
>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>=20
>>> I did look at common/usb.c but it's far from obvious how one
>>> can turn on the logging feature so as to report more errors
>>> to the console.
>>=20
>> you can add the following to common/usb.c (e.g. insert in line 44):
>>=20
>> #define DEBUG
>>=20
>> --
>>=20
>> that should then print out all debug functions inside the usb.c file =
to the console=20
>> after recompilation of u-boot.
>>=20
>> Regards
>>=20
>> Klaus
>=20
> I saw there is  /*#include */ available in usb.c=20
> so you could also try to add :
>=20
> #define LOG_DEBUG
>=20
> to the common/usb.c file which should also then enable the debug =
functions
> which then would be output in logging style.
>=20
> You will need the debug output to to narrow down the issue.
>=20
> just a guess :=20
> electrical problem(of the Pi itself)  which could perhaps be fixed by  =
manipulating the scan delay time .

Looks to me like:

https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c

might be relevant, not just:

https://github.com/u-boot/u-boot/blob/master/common/usb.c


For example, usb_hub.c is where usb_pgood_delay is involved.
(My patch to enable my boot media assigns that, not that
such helped Bob.)

But I've not been able to uniquely identify all the specific
identifiers for all the (relevant) "usb boot scan delays",
although I'd expect that pgood_delay (and its usb_pgood_delay)
would be considered an example.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 27 19:48:42 2022
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 4McVYW2PSGz4cmPr
	for ; Tue, 27 Sep 2022 19:48:47 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4McVYV1Cllz488w
	for ; Tue, 27 Sep 2022 19:48:46 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62e.google.com with SMTP id z13so22914002ejp.6
        for ; Tue, 27 Sep 2022 12:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=p8ngN9B2gCLbwAa2V8PERpMu4XJkWys5sxQgQmO6KfU=;
        b=QTu/SgVzKRgRsUSajdw6+W9D0RhBNN78xC5YhiFYAHxhjRaAzNZiIS4QVka34jnbN0
         DeOPlpxx9ICLyOuSGRdxnOLpBD5lqTpCDWQbwpMbgq8EJ6TKaugVlnikf4ru5a7Urcyr
         nEwL0GiIp62gwJbARJGasrtBRdjcWZJdBbsRUq1VAHswnww8gM1yu19AhJu7hmkuOANr
         ojZSMsEX4HBvYeuw3qVA2gjJuAJpT3BZYEwlmYwpWLN/kiiO93xYxGKR/lrjLFJo3cu6
         KvhZfaXAHbp9G5KiBWB8Ap1pi0fKqTXE76rzfOHcJ08hKl/IfNGe+raDo/0C8fHteRrN
         Ub4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=p8ngN9B2gCLbwAa2V8PERpMu4XJkWys5sxQgQmO6KfU=;
        b=uvEK2xYLNj1avB/5XCRP7dbZRRxJjVno+HO4U22LTLA2qZXmqRjnSaogjH7MaR2rSb
         TMf5k23/7le8+T8ShPuzD5smTmyS9b8Gsgd/BnzFZYDD3W+smpyHMEsiIjU07sRQD3Ds
         2H07TPaUSlzA8Q5Y7icFpfGD/aHG8xRO/EHPpU7b/fC1ISvEtmTjulMaGGhpVeiJtJ5n
         2eqVI3hSCfbf7Fj1xkXu0TOJypjUoxg0gp9NvZmPstVXN9ONEx39zS+0pv3AFfwzveIj
         Q+3LRsyTdEdhV6PrDTOkBto0LH7xV1urDsClZnYnHhc7glIaA4bCusYU70dKpGIQWu34
         t2HA==
X-Gm-Message-State: ACrzQf3NDxOjTZ5q+1uQhypyruwIrdptebQoxTlmRat/GyfNGyZuFejB
	gjMBVn9Zbu3uWQyZF6wv3pA=
X-Google-Smtp-Source: AMsMyM7VwZyXh7wj6TNGQwHMNaW9aNOzI7u6EedSy5KCXBQFzzYrUuMQhOnEZ1r4ufMJngO0I1kcLA==
X-Received: by 2002:a17:907:94d6:b0:782:b10a:7e91 with SMTP id dn22-20020a17090794d600b00782b10a7e91mr19445566ejc.220.1664308124953;
        Tue, 27 Sep 2022 12:48:44 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id r15-20020a170906c28f00b0073d87068042sm1250672ejz.110.2022.09.27.12.48.43
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 12:48:44 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 21:48:42 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McVYV1Cllz488w
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="QTu/SgVz";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 27.09.2022 um 21:20 schrieb Mark Millard :
>=20
> On 2022-Sep-27, at 11:33, Klaus K=C3=BCchemann =
 wrote:
>=20
>=20
>>> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>>>=20
>>>=20
>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>>=20
>>>> I did look at common/usb.c but it's far from obvious how one
>>>> can turn on the logging feature so as to report more errors
>>>> to the console.
>>>=20
>>> you can add the following to common/usb.c (e.g. insert in line 44):
>>>=20
>>> #define DEBUG
>>>=20
>>> --
>>>=20
>>> that should then print out all debug functions inside the usb.c file =
to the console=20
>>> after recompilation of u-boot.
>>>=20
>>> Regards
>>>=20
>>> Klaus
>>=20
>> I saw there is  /*#include */ available in usb.c=20
>> so you could also try to add :
>>=20
>> #define LOG_DEBUG
>>=20
>> to the common/usb.c file which should also then enable the debug =
functions
>> which then would be output in logging style.
>>=20
>> You will need the debug output to to narrow down the issue.
>>=20
>> just a guess :=20
>> electrical problem(of the Pi itself)  which could perhaps be fixed by =
 manipulating the scan delay time .
>=20
> Looks to me like:
>=20
> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
>=20
> might be relevant, not just:
>=20
> https://github.com/u-boot/u-boot/blob/master/common/usb.c
>=20
>=20
> For example, usb_hub.c is where usb_pgood_delay is involved.
> (My patch to enable my boot media assigns that, not that
> such helped Bob.)
>=20
> But I've not been able to uniquely identify all the specific
> identifiers for all the (relevant) "usb boot scan delays",
> although I'd expect that pgood_delay (and its usb_pgood_delay)
> would be considered an example.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

good idea,
I would then suggest to enable debug also in common/usb_hub.c
by adding #define DEBUG or #define LOG_DEBUG ..

for the usb.c I=E2=80=99d expect something from the mdelay function as =
an usb scan timer..
so let=E2=80=99s see what debug logs  usb.c & usb_hub.c  will spit out =
..

Regards=20

Klaus




From nobody Tue Sep 27 20:06:50 2022
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 4McVyW0bvfz4cph6
	for ; Tue, 27 Sep 2022 20:06:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4McVyV1GSMz4Ccs
	for ; Tue, 27 Sep 2022 20:06:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664309216; bh=/ZLL/9WKb0rOmWNP+f0B8r6ra2EhZxRYocOKcUCI0LA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RGMAtGuJ/URk9Cjl/rMZoAj53xL5PjPfdqnNKM1wuastzroDz6tma/jFUsZu/4p+h7zRsS36YEwm+VyXZCR+1l/JZ8/ZJ3ZFlSugM8e+7b6JRKKCcQT1LCuoSXSc6wcrJoigPztBUMrqTeMZ5eNRaSsmB1YBIHpDHl8aMy4dyRsAHXtwrkzhiHl4PspCpMBE0T+ikK6E1ku9up67gqebXqP56IeIEOd7ZMvdTZlQWxlHY44mQW71Kuvgs9l2+lXXhJ5jMRMBCk/81XxquSDrDIPiNnohjeeg29OP/vtKIl1OHsuawRHm0t4c7Gi4dWQzmcWmbviH0fkqGkqfJCpN8A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664309216; bh=63PfjwwstGUQtzCcaBwG6IN8zNMnZ+DhDarSuF3YJ+9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rJ14OpbsBgl3Rr04a2qxvOUhW4bwI/F+6T4WwLHuaxyvWFsyBcxhcHWZBssdLrfKO88COuA99xhva7ylCKJUQpJIuCMC1Sr8R49z2Qm3qfJjgUZT64LSMAK0E5fCJX/QGYUjzX/clfDkyH/fJQHw/3Ow0Co6kOaoJaN1gSlY+nCY2KLSPPWgL5+01ie1qx5CW/dOue6lUkmAXOa6FOrB+50nZ/X92RUAg+7hiFP7C95q3xnO/D8YSlGZ1Y6TGbsE2z+0NNZdmX1I8zixE1owStluPbSHmbOH8FTZPqWT7RegEaIFANWtwip4PHN5OLyW2wFbQXTqAnJI33acCzjlUA==
X-YMail-OSG: qt9q0j0VM1l3Z3KByKC_0RXrLM2wglKlHGw8r7.PZrGB8DpGCgx0bw3ik0tcXb1
 0MZRLPujgygYwE.fvgxU2wAB0bfYKbDXPAlhidrfIWStupA6wGKsglLFIMVDiVxRbTIHPdNTKVgy
 1ejqg0UE9cd6q_yZEZ6gJoyt.V2MKhydUyBRjWkEsUWmyCwe42fAg8omCURL0qJgYuEyDeeLFWIo
 b50AKAo9k.WIiD.cJk842tiWRmiRfC45KZGAhsTn_9EyHoThp3wwppq_vpYNcTUH1Ja8ZALJTRcE
 qRIo8XYDeaYHnxjD5kg6O.kfMOl8rh5O1m5iQX.Lh31x64OZGKJReYyDMhs60Xv1YWg4TWY9lP2k
 LIFesaDxw8kbEZsA0ZDhKP3X2EtlTpz0vUbvtIlSNkuA3nuxvcipCRDWcorahO91LxQrgbMEYiKb
 nxQ_fyORTTCYB35L4XW5t6wlE92hOK2HubutwWE.rP7ATjxH8bzzlanggB_B1Qi.zmFyx_hqYxW0
 nLuWTgRAp5GY.IBGg.ro.ND4aHoqmyFUZ.Bm4UUBmXLvKWzaSHqZL0IGf6C2Ex_9OvT6NcZhkL5H
 wa81GfErcvTibeYBh.lDOc5iaUG3_r4.GkSRVinBL0cUfngKnHZvdHxv_ar07_YphAwSxfIxvmhx
 NfdFV2MYvkOYVKJ9CuZx_0r7hsT6nYn4XbP4tWAPkWNJuZ69__8DcZOhbtT0exvOHZJiShn5WXMc
 iaQfO5nHZTMNR9Z9Orzo1Rvdztx1YmBizogVjWiZ3oollPvJaa5dRn8G.PlIMGmMA1jQfpqs8OSa
 PVrHlqwU8BMWfcS.ESDdLWFVLK1_3MHCuSp.VHSqZFnfw5P8syHkUDIrWjNGYiVL7PT1N0JmsGXY
 et07FaN4m_V8FoKT8UVdvETxg9a1gWMN5gW0Sg_G61LFxmIBZDRkEm9GNOI3pWuAWBjzaYviW7w2
 XaNRI4QivUg_WhCC.yR0ONo6qr6f_PkKHLAK0c9RcUjRUiKn.xQUVk5fm8.vweWDqdTZpvR2t2uP
 QEsPoHZJ25D5fLKtjRsbadGU2g_m.ahzBGj0O_KxMqjByEwpfLbgl.wKQMjuMNNon50_mA9iFWT_
 RG5NBqoSSy86MLelaGGlWB9ArPR24axA3o0RAZ2xL37hP3NHNKfklBNODTpbrykhLiaIpJ2JzyCY
 Y6GehkMB47ITV8ucU4wFnAPbZ0r_aIHMjYmaXDQPfxUNeV_RP9okwhpybrUReUite3wQnQEmKWoG
 IPX4TaTEooS45KYF8DCSu6X8bAxXHztjhFE7c_8yIOLKxiUUg71eZZzA7uMuwt231FpBAHQqxR7h
 onthm74Ti9G90kJ0YAjtWUDf5bwXfOYALAKxAvDd7_a4w2GI7EO54Y0wCBEjDmFGB4fMQCpJdTqb
 MS4mu0Chd1tS1Frw6gwbxo8_KWS4UTGS88Aat9WTLxNSgJSE8HyWVKdaXN.pAZLC8cqMEMHUmmBV
 Bmt90NWGyGS76iHnSOntQ5Xihc4s7QtLZTGlRsHqnBuUOM6_2MBG57zot1FCNAC6b1iA00NIWghE
 8yfKqcY1Y67I95_VxA4PTer7xdrrURWELPPNZwX0RA31ZaHXh_zd64Bf07VDRH6wqKj0cBQbDWeo
 zVTBrMlDO16iJMDutGhEyOnpiVbX2cRBWTBPoev0MBSD7kXXYgcb1bKR.xWDX04UBh3hRYwA6Rs_
 L8piBIlMK4qHR9GZqtAYFFsHFhHXaBp5V17EJPQB42sDovRAf54pRQxBkqN3e8DLurdzz5RUQn2_
 iVUnppwqWRVN863h9JvlAPjVz8Xz5XU2EG4033959nBYSX6UkQexAHCSaqOiItiuHUMuxwYEPTiO
 Pk_QeMo389UAGGnp9dPW13.YXMNyy7COAbmXo9eI_wm2os2pEmUmKd72A05toeihzJFE59s_xnAI
 0VuZriPUgdSJEBjllVCSHBG4Y0Oip_u5ZcH4aJhy62tnvG6f1djbOmFY0AUgkw0vnOxuzE5m3ve5
 imxEJxnnAgPbaVwyWZ5O_OaC_z30tTOjrtEY7vgCJ_cLugUjF0YGz_7F076DQp1pv_.s8FKUff0J
 igeAt_VA0wFn.iisKuULzwQjcdva2goRLF4KeoKgkOias4T9t7TxXY7uxoc8.k10GqW0RTTDz3R4
 6rZP7ypbo51FENMPF.43PVCPCJLX600Soa7iz.TZWdoIlNsn1vioWGcNnuHOUlLIb1lTW5e5Hipa
 OWKZSywKn5sZc6X2hVQiECDP8jiDVAvJTUio4aV_qxKwoilG5aB0sfv0ObcURssf08gdN2N4DXKP
 SKz8kMdM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Sep 2022 20:06:56 +0000
Received: by hermes--production-ne1-6dd4f99767-x2f2n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea3fd34d610e07e9ffc4c8559d33b2c5;
          Tue, 27 Sep 2022 20:06:52 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
Date: Tue, 27 Sep 2022 13:06:50 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McVyV1GSMz4Ccs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RGMAtGuJ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@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.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Sep-27, at 12:48, Klaus K=C3=BCchemann =
 wrote:

> Am 27.09.2022 um 21:20 schrieb Mark Millard :
>>=20
>> On 2022-Sep-27, at 11:33, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>=20
>>>> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>>>>=20
>>>>=20
>>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>>>=20
>>>>> I did look at common/usb.c but it's far from obvious how one
>>>>> can turn on the logging feature so as to report more errors
>>>>> to the console.
>>>>=20
>>>> you can add the following to common/usb.c (e.g. insert in line 44):
>>>>=20
>>>> #define DEBUG
>>>>=20
>>>> --
>>>>=20
>>>> that should then print out all debug functions inside the usb.c =
file to the console=20
>>>> after recompilation of u-boot.
>>>>=20
>>>> Regards
>>>>=20
>>>> Klaus
>>>=20
>>> I saw there is  /*#include */ available in usb.c=20
>>> so you could also try to add :
>>>=20
>>> #define LOG_DEBUG
>>>=20
>>> to the common/usb.c file which should also then enable the debug =
functions
>>> which then would be output in logging style.
>>>=20
>>> You will need the debug output to to narrow down the issue.
>>>=20
>>> just a guess :=20
>>> electrical problem(of the Pi itself)  which could perhaps be fixed =
by  manipulating the scan delay time .
>>=20
>> Looks to me like:
>>=20
>> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
>>=20
>> might be relevant, not just:
>>=20
>> https://github.com/u-boot/u-boot/blob/master/common/usb.c
>>=20
>>=20
>> For example, usb_hub.c is where usb_pgood_delay is involved.
>> (My patch to enable my boot media assigns that, not that
>> such helped Bob.)
>>=20
>> But I've not been able to uniquely identify all the specific
>> identifiers for all the (relevant) "usb boot scan delays",
>> although I'd expect that pgood_delay (and its usb_pgood_delay)
>> would be considered an example.
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
> good idea,
> I would then suggest to enable debug also in common/usb_hub.c
> by adding #define DEBUG or #define LOG_DEBUG ..
>=20
> for the usb.c I=E2=80=99d expect something from the mdelay function as =
an usb scan timer..
> so let=E2=80=99s see what debug logs  usb.c & usb_hub.c  will spit out =
..

I'm not sure it would be relevant, there is also:

https://github.com/u-boot/u-boot/blob/master/common/usb_storage.c

But , unlike usb_pgood_delay that I recognized and it
being in usb_hub.c , I've no specific identification
of something relevant from usb_storage.c .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 27 20:25:48 2022
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 4McWNK02dmz4crQR
	for ; Tue, 27 Sep 2022 20:25:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4McWNJ0GkWz4Fts
	for ; Tue, 27 Sep 2022 20:25:52 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62c.google.com with SMTP id nb11so23077974ejc.5
        for ; Tue, 27 Sep 2022 13:25:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=qb0hXnu3iMrie7US9TcK8t+kMXfs/cjluQE5e9iRQg4=;
        b=kM5h1so5rLlkCKE5QibkFazcTZwrmyLnI8a5ayx60eyCoLX/xLACclqmO8WoL0vb65
         doK0RuRSU0qVBV0DjzYlgGAIQBbtKOfcCxtjhs4lerSrA/R5Q86e7vaDCZfkQY69lkba
         Z0tjeKQR0rFeiDRwZJWVpbWz8HVLcbPtdwff2QLzUA617y/Mnu2ImSbva7EQVt5BkrLl
         kg2W6ENmqEqJxzepBp4vNMkZGpSc9UnGWh4933lHTePeZD2qjqC5shjG5mHmUXhzXSIj
         r090lGyR9BM+Mu1y6Mi+n+gX30tjD03CMhZ1eKpEkG9jrRRa0OMiO0H9s6OQdVbQDOlB
         PR0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=qb0hXnu3iMrie7US9TcK8t+kMXfs/cjluQE5e9iRQg4=;
        b=Lp+CCARlK+Z6apayIhd8w7ZbxncB75gsinJMlKE67HeWG7/icUpgr1O+jWabjeUoVa
         3TopPaKBsJB0oPopvM+f5WqJbMt0CfFJ6mn3BrrtEZjDoy4NAsP/EqavOEvZnZF6c00m
         cW66LXMbYup8lI46IjcYCYUhSSheyzStepRm3BNuZB17ZcjWwH9CAl24u80o7el9MIKe
         vYDbYrz08A4hF75kDMySQUcA0Z1952zxQBNvh+9vWowETx9eGrCJYbU3rCK1IVrnUqGF
         yY6/edO6/I2Vi/s5Ta3H3DT5av2k+xCK5U+b8iWDUY6IYOC9skTSM1jsXhop52+QiHTs
         qxjg==
X-Gm-Message-State: ACrzQf1br4VxGrmwIBeH0eDyYcZN/WbzSDPutkI9+im9szIXueUaS7YB
	78GWb5eADeRhmm6160YGiVQ=
X-Google-Smtp-Source: AMsMyM5N7RCronca+5UWGdpnsZ8XYICf/toEKsI8XROcxNzVT45qzG/BdtFiZ+HYye9sGwCcMNORZQ==
X-Received: by 2002:a17:906:58c6:b0:782:bfb1:eae8 with SMTP id e6-20020a17090658c600b00782bfb1eae8mr18409740ejs.546.1664310350798;
        Tue, 27 Sep 2022 13:25:50 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id w1-20020a50fa81000000b00457c85bd890sm1263046edr.55.2022.09.27.13.25.49
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 13:25:50 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 22:25:48 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
Message-Id: <8B67D09A-C8E1-403E-9EF2-48FCBE2E5798@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McWNJ0GkWz4Fts
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=kM5h1so5;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.980];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 27.09.2022 um 22:06 schrieb Mark Millard :
>=20
>=20
> On 2022-Sep-27, at 12:48, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 27.09.2022 um 21:20 schrieb Mark Millard :
>>>=20
>>> On 2022-Sep-27, at 11:33, Klaus K=C3=BCchemann =
 wrote:
>>>=20
>>>=20
>>>>> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>>>>>=20
>>>>>=20
>>>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>>>>=20
>>>>>> I did look at common/usb.c but it's far from obvious how one
>>>>>> can turn on the logging feature so as to report more errors
>>>>>> to the console.
>>>>>=20
>>>>> you can add the following to common/usb.c (e.g. insert in line =
44):
>>>>>=20
>>>>> #define DEBUG
>>>>>=20
>>>>> --
>>>>>=20
>>>>> that should then print out all debug functions inside the usb.c =
file to the console=20
>>>>> after recompilation of u-boot.
>>>>>=20
>>>>> Regards
>>>>>=20
>>>>> Klaus
>>>>=20
>>>> I saw there is  /*#include */ available in usb.c=20
>>>> so you could also try to add :
>>>>=20
>>>> #define LOG_DEBUG
>>>>=20
>>>> to the common/usb.c file which should also then enable the debug =
functions
>>>> which then would be output in logging style.
>>>>=20
>>>> You will need the debug output to to narrow down the issue.
>>>>=20
>>>> just a guess :=20
>>>> electrical problem(of the Pi itself)  which could perhaps be fixed =
by  manipulating the scan delay time .
>>>=20
>>> Looks to me like:
>>>=20
>>> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
>>>=20
>>> might be relevant, not just:
>>>=20
>>> https://github.com/u-boot/u-boot/blob/master/common/usb.c
>>>=20
>>>=20
>>> For example, usb_hub.c is where usb_pgood_delay is involved.
>>> (My patch to enable my boot media assigns that, not that
>>> such helped Bob.)
>>>=20
>>> But I've not been able to uniquely identify all the specific
>>> identifiers for all the (relevant) "usb boot scan delays",
>>> although I'd expect that pgood_delay (and its usb_pgood_delay)
>>> would be considered an example.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>=20
>> good idea,
>> I would then suggest to enable debug also in common/usb_hub.c
>> by adding #define DEBUG or #define LOG_DEBUG ..
>>=20
>> for the usb.c I=E2=80=99d expect something from the mdelay function =
as an usb scan timer..
>> so let=E2=80=99s see what debug logs  usb.c & usb_hub.c  will spit =
out ..
>=20
> I'm not sure it would be relevant, there is also:
>=20
> https://github.com/u-boot/u-boot/blob/master/common/usb_storage.c
>=20
> But , unlike usb_pgood_delay that I recognized and it
> being in usb_hub.c , I've no specific identification
> of something relevant from usb_storage.c .
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

Also a good idea :-),=20
So enable debug also in=20
usb_storage.c=20
It also has /* #include  */  and /*#include */
And for the case of a debug output which points to a scan timing problem =
the
mdelay function appears 8 times in usb_storage.c .
So a big playground for manipulating the  delays ,
I hope not too big  for us :-)=E2=80=A6=20
let=E2=80=99s see what debug outputs...

Regards=20

Klaus=

From nobody Tue Sep 27 20:36:05 2022
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 4McWcG1zvLz4csL4
	for ; Tue, 27 Sep 2022 20:36:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4McWcF2tpgz4GHB
	for ; Tue, 27 Sep 2022 20:36:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664310972; bh=FIe39gqCmxqIY9dmfgTFL6Ge+c+FB0OlbAoaKewC7+g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J459nPD+frlYPLUZMz4Npz7iKoncALUQdCnq92xrSZDHexj9OBrGLOTOc0mmuPYWT7BQGZZM0jP0Cx3c3Evh43z9wDlwsRPhx6CFemwWgBqKJaUGM1S+n21IIEbn5BvHzs9JlQz6216Ger7eyT3aYjV1nPIRcHAAo1OsjeMIMqOBcfbsb42Z+PZEC3+WaQbOAfI1Vc27kPHyZjN7taNHIpTe8wGpVBj2hJ2qgo0HPNl7YPMcEIfpRFICrql44YywFiTXr1nCb/WR3SbyaPidMGEeVWyBOk1njOz04FckBj2H0gWx+W2BxXG3/jFUgTJweOFzUGU4WkV7qjbzZZgPNg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664310972; bh=kPiH3J7EjDOT5UKa24RPVJA4klL5my2UHnPkAClegRs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Jp/zTKplJOiu/sxeIK1ZkG7oRztJ6jR/Yhvc/7T/wK6dOAPzqbHZnwknZM+ksnyVy+4pqkvnS32nEQEFzCDhGPnuFuzbgWKN2Aw0VCD1z6tO7Lggf9J4Fvwv/bLEATKwrtve+eskS2jOk9CcDYe1IN9UHOtWdCfiMVi5nptsNyu3OPaZZutnI3ig+V8g03VoEayaiHHZNI4r1y/ljMn/5q+pdctrQ5Bz11maV278UBR1G08KWD5OsfPthK6YTdsHhP2R8sqOPAJnNEKtMq6Es+ayCjC3qGVCL+1l5u0Jze7bZzJ1nlKT5JlJGt4W+aOEdoSvna/MDCpIHnBjn3hI1A==
X-YMail-OSG: lSeNXE4VM1keS9l1oJB1IVaC.I4FEQiYVXHG1Vqk1gXm0Ry8YEXHNrvA9wUT30I
 486mrckV2egyrEvrFPTHakEV1.w3o3tlWP6tD5KDcQotvu5VNj6.4GfIe08Ch5rGr9EjiGZyUuxa
 UIx_yRSz7pglTKPVSawtKKYuu_9lQevn.wb6L6W5Be_NDCLD_s1vtpamfqxXidN8hfDhEekLtLZC
 8txIvmw5nUbIlq2WQPN2xMe_zF3C_rgSvYDMS6PvH24T9JlBxR9.I0Jiq_BHk6xqgPD5vHi61GTn
 IC8piho_NlyrTDIorU_KEnXrTrAR3FI3GCXbSIhmjNPSONMmznJIZyed4sMTD5U.lfwONg2pHN0T
 hXwkmbOEez8cwWNhdtBjW6d.WN4oO02ijsLZvosobiTjbeUjZ3.oFe3jGKaNGwCwZ4Nnyq8FXTiH
 oEP.dSvpBfJq0DLQXCEav09BKJPaONgMPJVwh3vf.uREHpf0dzpN8UeV5PPt5LC2KEhERIaS7_ln
 QjbPvTwO0nA5287vNlH71fAbhMN0GrHuryrgeuFDCEM5MCJLNyXI2DH3wRABGPmfgTfzHV7AGdhM
 ApM5fcGdcPqA1fioSS5sW02EDouW3C5A3CD2PTyZpIjzsciUUSawXQzBQ6KcD2R.C0NPfZAFbUwS
 oV.7RiM.rrzJMokbwMGH5qHnMdX4Lgh9O38N_tudlcJjTz35HYJmLfS8Hg_nxkEYSUpgvngvTwqp
 dLLI63Wk0vGNL5AH9lA__luITxz42GQlTIWzclY1feyMpe1x579qeO6B.IgpqEzV_S6W2c6fzmSd
 jfUIlhPvssHeuPboRpV1MWo_UWmyzP6VR14qjJpHWAiBhambPoi1VRgZQfpyGO01Jvf3Zs9URWSb
 uurV5cFNYKH5Ad2hPw.KZDUVHd6zWTDgLdLbMYPh5S45BeVjRfS35hJj6ntvTAahGW0yJDwi8E8N
 1dAq9UMwSJY8eOMtUG7iiUUb_khQMgnrkySDVKZ1TW68MUebucyfRFXs8D91NAyOM.zN0Q6USRsu
 BrhI_yst7Rd.1faU8PUrgli4HhCrRxYS9SF.87Kl607MICgswbj_TPThRB5u6vEgxeejrYxgfoZN
 P0Aj7HxUDd8foB7lKu3vxEVpTvyAPWqz9g5jYqt0r.A2V1lRDiCg_Bj_Bzc4luV1NySCh7ROuAnv
 jZIY1tDjpDW_W45uElRoU7JXulE2S57rhYk6XeULbiMGfBaiWJBEwmlOY_tdlOstJY.3GL06bAZA
 _COegevxrpy_9jQuNA25u.yfTp3pjkwYt4PNAov4C5pwWcUjjdBO2Bd.zhqaMibQIZCX7siuDp5d
 pfXWT_3sZiq3HnvBo4ZwoZ39R3mFeWf66_g7eTyrODeJiYmG5D37NncuNSQhEtm7uFdVDwx2IEdq
 4t7snHV9GCgeTXclDSu.alXeGuBRmfGM2ceXjFi.ErynM3LuHKWERJPlIOpE58BvugOotBWTDsLe
 VsGwXhLKyU0VNLrx2h9JvA3Gy6B3THlDhJzUw4dB.nbp26d.h50dy3ySl7mL8XQEcgJuFBgbTVmq
 .mXpcpq2YrufuCyu5ThlgJ3DDva76eXIzNpE6iSz9Usac2tiKpXXfN0jWtLb.NAiiU5ESQqYRJhg
 NyWAiv2kOOs8nStoERMC.9mqnL_gBm7lmfUTAwdID0In6fowAwqwDDiah.uynoaFQ1jr02_OZVy1
 AQcHRQSTGStPVSQSxSmq.tq.38rl226N5SQWKiloDIESh50d4MewP66sW31aZ4833AjetalAuh5L
 Aa7rcESjuAx2LN5_oflWKh45jxkRG7.K2w2us1tUdg7iA99ogJ9QBdu_kcWsn7pePHd21gkNsKGS
 iaX0zh0se67DjMQ1ydm2uZBPBMQ5XFyeRIlp0MjYDp.UhuUDKU66hYIhBVBsrl4HjeeYCjdf4Mpj
 EEaX_s76G_g.I2Z_xPqJmnVw0gxeWMrmgGq6IxKU..CMrTKrA8I2vWRzC4FaW6ChzLHFtn16M5Ww
 WMaqwqU1XPjWrZohAHjhzMXbm8TlYf97Z7JtNdWlji3cHnFPeskbTTJx8EXWL8iqpKO5QITJVnKp
 ABvbxGiniAn3QriroH135980siYnJ6AgQ8.kcTFVKNQBDCho2FPRoqODfAY6tv7R.8uJB2iG7h4A
 MwGpCM0xf4JmyxC.knclW7VWq9rpJA4s6mUegIQu5Va0L8nKgT4W0fwA6BWFLaRCT6UvtPmqkAW0
 b3vn1HNEtDfgiS4iTrDZShYuMZFC8AMou_dOtxI3guiODgDYaSVrAVqLkr9raXpul9uzjw.g6.fX
 iYF9q8g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Sep 2022 20:36:12 +0000
Received: by hermes--production-bf1-759bcdd488-2jz9z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bac2736957376163bd7e4836a84f0cfc;
          Tue, 27 Sep 2022 20:36:08 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
Date: Tue, 27 Sep 2022 13:36:05 -0700
Cc: freebsd-arm ,
 =?utf-8?Q?Klaus_K=C3=BCchemann?= 
Content-Transfer-Encoding: quoted-printable
Message-Id: <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McWcF2tpgz4GHB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=J459nPD+;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[freebsd.org,googlemail.com]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 13:06, Mark Millard  wrote:

> On 2022-Sep-27, at 12:48, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 27.09.2022 um 21:20 schrieb Mark Millard :
>>>=20
>>> On 2022-Sep-27, at 11:33, Klaus K=C3=BCchemann =
 wrote:
>>>=20
>>>=20
>>>>> Am 27.09.2022 um 19:58 schrieb Klaus K=C3=BCchemann =
:
>>>>>=20
>>>>>=20
>>>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>>>>=20
>>>>>> I did look at common/usb.c but it's far from obvious how one
>>>>>> can turn on the logging feature so as to report more errors
>>>>>> to the console.
>>>>>=20
>>>>> you can add the following to common/usb.c (e.g. insert in line =
44):
>>>>>=20
>>>>> #define DEBUG
>>>>>=20
>>>>> --
>>>>>=20
>>>>> that should then print out all debug functions inside the usb.c =
file to the console=20
>>>>> after recompilation of u-boot.
>>>>>=20
>>>>> Regards
>>>>>=20
>>>>> Klaus
>>>>=20
>>>> I saw there is  /*#include */ available in usb.c=20
>>>> so you could also try to add :
>>>>=20
>>>> #define LOG_DEBUG
>>>>=20
>>>> to the common/usb.c file which should also then enable the debug =
functions
>>>> which then would be output in logging style.
>>>>=20
>>>> You will need the debug output to to narrow down the issue.
>>>>=20
>>>> just a guess :=20
>>>> electrical problem(of the Pi itself)  which could perhaps be fixed =
by  manipulating the scan delay time .
>>>=20
>>> Looks to me like:
>>>=20
>>> https://github.com/u-boot/u-boot/blob/master/common/usb_hub.c
>>>=20
>>> might be relevant, not just:
>>>=20
>>> https://github.com/u-boot/u-boot/blob/master/common/usb.c
>>>=20
>>>=20
>>> For example, usb_hub.c is where usb_pgood_delay is involved.
>>> (My patch to enable my boot media assigns that, not that
>>> such helped Bob.)
>>>=20
>>> But I've not been able to uniquely identify all the specific
>>> identifiers for all the (relevant) "usb boot scan delays",
>>> although I'd expect that pgood_delay (and its usb_pgood_delay)
>>> would be considered an example.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>=20
>> good idea,
>> I would then suggest to enable debug also in common/usb_hub.c
>> by adding #define DEBUG or #define LOG_DEBUG ..
>>=20
>> for the usb.c I=E2=80=99d expect something from the mdelay function =
as an usb scan timer..
>> so let=E2=80=99s see what debug logs  usb.c & usb_hub.c  will spit =
out ..
>=20
> I'm not sure it would be relevant, there is also:
>=20
> https://github.com/u-boot/u-boot/blob/master/common/usb_storage.c
>=20
> But , unlike usb_pgood_delay that I recognized and it
> being in usb_hub.c , I've no specific identification
> of something relevant from usb_storage.c .

Also, it looks like having LOG_DEBUG force DEBUG is a recent
change for:

https://github.com/u-boot/u-boot/commits/master/include/log.h

Commits on Jul 26, 2022
log: force DEBUG when LOG_DEBUG is activated=20

So, for the vintage of U-Boot source that the u-boot ports are
based on, DEBUG would need to be separately defined.

The logic in question in the modern log.h requires LOG_DEBUG to
be defined before the: #include 


include/log.h

@@ -194,6 +194,9 @@ int _log_buffer(enum log_category_t cat, enum =
log_level_t level,

#ifdef LOG_DEBUG
#define _LOG_DEBUG	LOGL_FORCE_DEBUG
#ifndef DEBUG
#define DEBUG
#endif
#else
#define _LOG_DEBUG	0
#endif

The inner #ifndef DEBUG related 3 lines are the new
code.

So it may be best to always #define LOG_DEBUG in whatever
*.c file(s) before the line with: #include 

Even the old logic indicates such ( _LOG_DEBUG handling ).

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 27 21:20:20 2022
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 4McXbG4JRgz4cy0h
	for ; Tue, 27 Sep 2022 21:20:26 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d])
	(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 4McXbF0tNBz4LJg
	for ; Tue, 27 Sep 2022 21:20:25 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52d.google.com with SMTP id y8so14862762edc.10
        for ; Tue, 27 Sep 2022 14:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=v/6Y+mUtNdfXsTNoHtZXgdCOFtHi/QidMEbgs5dW1Ds=;
        b=Q+fZuYxThEzyt/KoY+ZSjYiehtdiWqGwECdv5fa7Ge0+jT/ZRU+tbXfcAqO9qHR5dK
         QTf3cKEO2XolGRXeDmI/nomRqoNSPZs03CZRHHUsz7UVxhdgPnA1Ixe1AEVtXEANaPoG
         2inPJeV5x6eIOarY0xzhok9ORWn4SHWZUtzr4eKkiApEZf90yMH2gYSlRn3ABg1MnNXu
         nVysBxAHvdgW6nkXC/td1YmgI7EUT6z79xsQchcsxuIIQOKAdke3+buicMJWqdebukD1
         dz7wCvIwB7zhtYiv/XyuiEGKHvB7tY5AT4aVi0KHjqUL2EqFU7yHFisFscCA/kS4omsw
         3mjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=v/6Y+mUtNdfXsTNoHtZXgdCOFtHi/QidMEbgs5dW1Ds=;
        b=XJNKhlWVt7nxC2HnGokWn5Yv6elensNrdw8R6o3k9c8UJTMWDvG6wpYjsR+BE7GEZD
         UBBwcvOFv8LISbkf6MZNfQ7qF4Ol33qTjN6d9Fb5tiwU2HC6oKEGvs+78A3A/DHCVRcT
         o3UHN7psm1LNPEmNFWthxdG3lHXE/+OndpGYfee95sS9w0m1zTN5gfgZFOiogtaILSWs
         MFCC+kHLxDIrMkgvw4Bi1RaCGOzW4gt9JaNDrl7ZwRKbSSuAHt5K2dXKJYHgC0t1SWL8
         myMiEwshGMWUCaGiJ67Sw9cTTQugPZjNQRKn1aGAQGgoCfNbV1Lh/H/4iX1hZR36LVzn
         GQEQ==
X-Gm-Message-State: ACrzQf2l8FKOfxgUVxO9oHOQZnAtmbjAsvPh9a4hKYOMKF+ZR96PKOwq
	dGvEHLdorQexpcQRyyTnfKllIbDQPRc=
X-Google-Smtp-Source: AMsMyM66fi4EqwV7xN/2+MQw2AgROkgKjygS2hy/Alu+6CkbrkTn1uceEYgYjUEXWalaAOpiRH48EQ==
X-Received: by 2002:aa7:c956:0:b0:43b:206d:c283 with SMTP id h22-20020aa7c956000000b0043b206dc283mr29836799edt.381.1664313623203;
        Tue, 27 Sep 2022 14:20:23 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id c40-20020a509fab000000b004571fc9112dsm2016432edf.83.2022.09.27.14.20.22
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 14:20:22 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 23:20:20 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
Message-Id: <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McXbF0tNBz4LJg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=Q+fZuYxT;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>=20
> =E2=80=A6..So, for the vintage of U-Boot source that the u-boot ports =
are
> based on, DEBUG would need to be separately defined=E2=80=A6.

If you mean the freebsd u-boot port, I would suggest to completely =
ignore older versions/vintages .
afaik Fbsd will not accept any device specific patch which didn=E2=80=99t =
made it (u-boot-) upstream.
And u-boot also won=E2=80=99t accept such patches if not extensively =
validated.
So you can use the port to compile but I suggest to use the master =
stream of u-boot as source
( I think that's what you had in mind anyway)


> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>=20
>=20
> So it may be best to always #define LOG_DEBUG in whatever
> *.c file(s) before the line with: #include 

Although that seems a bit unusual maybe u-boot planned it that way( =
placing the #define in line 1 of the files),I haven't investigated that =
yet =E2=80=A6
I would begin with a simple #define DEBUG in common/usb.c and then look =
what happens=E2=80=A6
and then I would continue with the other files you suggested if =
there=E2=80=99s no relevant output from usb.c debug=E2=80=A6
using the master stream of u-boot=E2=80=A6

Regards and good luck

Klaus




From nobody Tue Sep 27 21:33:42 2022
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 4McXtg1tDTz4d0Bn;
	Tue, 27 Sep 2022 21:33:47 +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 4McXtd6hqlz4MPd;
	Tue, 27 Sep 2022 21:33:45 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28RLXhVP072865
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 27 Sep 2022 14:33:43 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28RLXhDX072864;
	Tue, 27 Sep 2022 14:33:43 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 27 Sep 2022 14:33:42 -0700
From: bob prohaska 
To: Klaus K??chemann 
Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org, uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220927213342.GA72077@www.zefox.net>
References: <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.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: <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
X-Rspamd-Queue-Id: 4McXtd6hqlz4MPd
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.08 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	NEURAL_HAM_LONG(-0.98)[-0.983];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-ports@freebsd.org,uboot@freebsd.org];
	FREEMAIL_TO(0.00)[googlemail.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

[sent also to uboot@freebsd.org. If that's verboten or needless
please indicate]

On Tue, Sep 27, 2022 at 08:33:33PM +0200, Klaus K??chemann wrote:
> 
> > Am 27.09.2022 um 19:58 schrieb Klaus K??chemann :
> > 
> > 
> >> Am 27.09.2022 um 18:03 schrieb bob prohaska :
> >> 
> >> I did look at common/usb.c but it's far from obvious how one
> >> can turn on the logging feature so as to report more errors
> >> to the console.
> > 
> > you can add the following to common/usb.c (e.g. insert in line 44):
> > 
> > #define DEBUG
> > 
> > --
> > 
> > that should then print out all debug functions inside the usb.c file to the console 
> > after recompilation of u-boot.
> > 
> > Regards
> > 
> > Klaus
> 
> I saw there is  /*#include */ available in usb.c 
> so you could also try to add :
> 
> #define LOG_DEBUG
> 
> to the common/usb.c file which should also then enable the debug functions
> which then would be output in logging style.
> 
> You will need the debug output to to narrow down the issue.
> 
I tried running make clean, make extract, adding #define DEBUG and #define LOG_DEBUG
at line 44 in common/usb.c, then running make from /usr/ports/sysutils/u-boot-rpi-arm64.
The resulting u-boot.bin is still 582712 bytes, just as before. AIUI one effect of turning
on debug is a larger executable, so it appears I'm doing something wrong or those 
changes alone aren't sufficient. 


> just a guess : 
> electrical problem(of the Pi itself)  which could perhaps be fixed by  manipulating the scan delay time .
> 
Power issues don't seem prevalanet. Voltage at both the Pi3 and hub USB
ports is never below 5.0 volts, usually around 5.15, with 5.0 at the
time of power-on and probably POST.

I also replaced the powered hub with a second, nominally
identical, unit. That helped, shutdown -r worked 8 tries
out of 11. This with
U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)

Switching to a recent u-boot-rpi-arm64 seemed to
make matters much worse. Went back to the older
version of u-boot.

It's tempting to say the switch is the problem, but the
disk holding -current from which I copied the old u-boot 
booted reliably using the Pi3 and its previous hub and 
power supply.

That's where my question of supporting files came from.
Right now the stable-13 disk has an added
FORCE_TURBO=1 in config.txt, which seems to help. The
rest of the files in /booto/msdos are as provided in
the original image file. Do any of them, beyond 
config.txt, have an effect on u-boot's behavior?

Thanks for reading!

bob prohaska
 




> 

From nobody Tue Sep 27 21:59:22 2022
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 4McYSG3B9mz4d2Y9
	for ; Tue, 27 Sep 2022 21:59:26 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4McYSF5NKRz4P4J
	for ; Tue, 27 Sep 2022 21:59:25 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62e.google.com with SMTP id dv25so23410840ejb.12
        for ; Tue, 27 Sep 2022 14:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=9Cgjf9gpsemmpTqFAwMGnlt4ANEh/qdz1I86Y3/pn+c=;
        b=B1Ub66Gsr/u3P751/+Swc1BupwlwOD0f5Fg4hgVhNN94MeUIOsctL6s7pLTlYdsJaZ
         Yb1dvwnPzYkuPHl3MEDkpm48DjrGzZs4P0+3q/3tJ9io9y3kYfM5LC/DWnR0D+vIj1rc
         QujckR5dkGiwNCZWfuYgh4DW9jH0uuGZizphld7ZqI49/HiAMj5XycekdQW2dv39A4R4
         Y/O+OhzofVOf71EDSqHvJo48D0Mqsu0AXAoY2W1xI45Uo4uanzqxqHTxCwLN353Tato9
         VrAcJhus9g0Rtoc06Abtq1mmdocy49m3cNRX20HmVtLqmzOZ1it5Vj1Jv/vHFbP8bRoy
         3q6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=9Cgjf9gpsemmpTqFAwMGnlt4ANEh/qdz1I86Y3/pn+c=;
        b=FZa79XOm1bCLl51Zf8HjLkS+8nviniNDvNPN54AarGRBPGAKWZZnSPjyAoQrQ6T8z9
         EfIsxOhF2pjv8LPX7GIQuBrf7mUye2OpmPQcF7jPY4Kzc5o0gT7RKiDm7fYf1jUe9+ti
         DK7wN2KtNp3k/+PwWEoPdC2V0DkA9mfbmr6AUujdlyYwjJWLhzkn+EmWgpJypXzaVrM3
         CSnPDT8J64zzChRpwLgKtC60xc5ys7jlRDd2lRVM/BbKDOYic0TNVPkrIt0wsaAAfJNA
         r/UxC++xA4kqE5k9YRlWns0ct8X/PA9S35c1+9ST1muR2fBYgmH9zjnvrf3zF7MdrzLO
         2EIA==
X-Gm-Message-State: ACrzQf1aLj4nXmUFZBXeuSZ1apT282rPc+f+475oB/YaWZicuflnAs5Y
	nXjhkJrBYwSH6La5VZF8XJFqnBcepng=
X-Google-Smtp-Source: AMsMyM6Ew4G5FGSnjqQjOz40dIzgdlho/FhTreAJwLx78o5aT8IR22YxvVPdWLcAB0aVPVulS+0bIw==
X-Received: by 2002:a17:907:3f28:b0:781:e093:d0db with SMTP id hq40-20020a1709073f2800b00781e093d0dbmr24416548ejc.295.1664315964337;
        Tue, 27 Sep 2022 14:59:24 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id k20-20020aa7d8d4000000b00457d9c16fb2sm545404eds.23.2022.09.27.14.59.23
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 14:59:23 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 23:59:22 +0200
References: <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 <20220927213342.GA72077@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20220927213342.GA72077@www.zefox.net>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McYSF5NKRz4P4J
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=B1Ub66Gs;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 27.09.2022 um 23:33 schrieb bob prohaska :
>=20
> [sent also to uboot@freebsd.org. If that's verboten or needless
> please indicate]

Verboten :-) Ha Ha , you speak German, great !

>=20
> On Tue, Sep 27, 2022 at 08:33:33PM +0200, Klaus K??chemann wrote:
>>=20
>>> Am 27.09.2022 um 19:58 schrieb Klaus K??chemann =
:
>>>=20
>>>=20
>>>> Am 27.09.2022 um 18:03 schrieb bob prohaska :
>>>>=20
>>>> I did look at common/usb.c but it's far from obvious how one
>>>> can turn on the logging feature so as to report more errors
>>>> to the console.
>>>=20
>>> you can add the following to common/usb.c (e.g. insert in line 44):
>>>=20
>>> #define DEBUG
>>>=20
>>> --
>>>=20
>>> that should then print out all debug functions inside the usb.c file =
to the console=20
>>> after recompilation of u-boot.
>>>=20
>>> Regards
>>>=20
>>> Klaus
>>=20
>> I saw there is  /*#include */ available in usb.c=20
>> so you could also try to add :
>>=20
>> #define LOG_DEBUG
>>=20
>> to the common/usb.c file which should also then enable the debug =
functions
>> which then would be output in logging style.
>>=20
>> You will need the debug output to to narrow down the issue.
>>=20
> I tried running make clean, make extract, adding #define DEBUG and =
#define LOG_DEBUG
> at line 44 in common/usb.c, then running make from =
/usr/ports/sysutils/u-boot-rpi-arm64.
> The resulting u-boot.bin is still 582712 bytes, just as before. AIUI =
one effect of turning
> on debug is a larger executable, so it appears I'm doing something =
wrong or those=20
> changes alone aren't sufficient.=20

Perhaps Mark is right that #define LOG_DEBUG has to be placed in line 1 =
of the file ?=20
I didn`t investigate( all I say is from remembering past issues) .


>=20
>=20
>> just a guess :=20
>> electrical problem(of the Pi itself)  which could perhaps be fixed by =
 manipulating the scan delay time .
>>=20
> Power issues don't seem prevalanet. Voltage at both the Pi3 and hub =
USB
> ports is never below 5.0 volts, usually around 5.15, with 5.0 at the
> time of power-on and probably POST.

Well, I didn=E2=80=99t mean voltage in that sense, but it=E2=80=99s =
possible that the Pi3=20
has another voltage regulator chip onboard than newer PIs and that=20
this older regulator isn=E2=80=99t capable of handling power regulation =
correctly(e.g. for the specific Sabrent device)
 .. just a guess..

>=20
> I also replaced the powered hub with a second, nominally
> identical, unit. That helped, shutdown -r worked 8 tries
> out of 11. This with
> U-Boot 2020.10 (Mar 04 2021 - 04:32:31 +0000)
>=20
> Switching to a recent u-boot-rpi-arm64 seemed to
> make matters much worse. Went back to the older
> version of u-boot.

Very interesting, to be honest:
8 tries of 11 is not really bad, so I would continue with that setup=20
For the case that it=E2=80=99s not mission critical production system =
:-)

>=20
> It's tempting to say the switch is the problem, but the
> disk holding -current from which I copied the old u-boot=20
> booted reliably using the Pi3 and its previous hub and=20
> power supply.
>=20
> That's where my question of supporting files came from.
> Right now the stable-13 disk has an added
> FORCE_TURBO=3D1 in config.txt, which seems to help. The
> rest of the files in /booto/msdos are as provided in
> the original image file. Do any of them, beyond=20
> config.txt, have an effect on u-boot's behavior?

Yes, all files in boot/msdos (e.g.  dtb & start.elf) related to the =
device have effect on behavior=20
But I hadn`t tested that with Pi3

>=20
> Thanks for reading!
>=20
> bob prohaska
>=20

So  maybe that trial&error by switching to older/other available =
u-boot-versions or boot files may help as you said=20
But locating the real issue should only be possible by enabling debug =
output =E2=80=A6


Regards=20

Klaus



From nobody Tue Sep 27 22:27:10 2022
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 4McZ4P0hTBz4d5T8
	for ; Tue, 27 Sep 2022 22:27:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(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 4McZ4N0fRyz4QR8
	for ; Tue, 27 Sep 2022 22:27:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664317633; bh=4fGdf403mGGoZ8OmXcvjS7yBgcjv+S3i01Mk5iTbCZA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aT6EQd43PntGXMR/4pgJyZroPwajP+xVgU2XHgiSpsBtIWtWfIhLidchlCcItA0OhETx5LCADI33MRyrP0514XjuCWu4cSPJFEISkhhqwCXcj71hVsj5jcxpM3JdyIu/obZmDP/b9AmHfEsdP8scgCXc1xxQpkoWdaa/sA0ffXQaFjoeLDz68FiNbvVHkkG8DhWwEwPqX7hwORrX5CqCZYJm+pjCqqViVOgvT8h+08wy069G8RcUpUTCHcglPxKuE7pBdKs4QiDgsHcrKYgHKfp8Hvf63UzHwxkhm59Yg3srmCVhj+/iyEOs4hN4h3hBEboopj6qTIdVnxLMsASf5Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664317633; bh=3Y5zNyexItaFVKw+LYUaeRRCbzsBafrGAnOcVv+eVTf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D5SLw5+J1z+v+Y7ZPuC1H0i6G0YaQR4Mmj1hKKBprjyYrpNBValNu9Cl4fhjFvIpMF3S2zGU8L7a95y2ROE5tj7PrOKCuA8DCPMVm83dqj5qyWfAC4jYqGc46gdB2AaWTw7VF79JsLOicTQlhOQI+p/ebTdme1gT+u16PIpI8+2evLaueQcObbDxb7Rouqe+YMkRbe4SMF/y7a0P9dapuQPKzluo9zVWpwKyvlLpdxxcQ58Ki7uo2r8bDhg/eDS4j6uLWneu+7Ro/cot6YyyKbsqKqRMB67OjNRmumpuliFqs70P3IuSv5X6sybUmCZ61oTZws92YeeLWJC5pcB19Q==
X-YMail-OSG: rzh8bkEVM1nexUCXveTk8ltpxh3E0zjsCEmvHqmZ1SfE5p1kQZiqTffc730CpI_
 TUUotQ45N8meItDSETLvwyPquZmwK_9NoIqZ4_CRe3Szflgg6asFUIJdch7sebSYbhV2W7yXv2TS
 KBa15qi3uHHX4yIDvi2C5DiHpEJPLsf41epIWuwv._NDKbsqhR8gDx3zGZU00CThuHIbekHHH_XN
 YcPx0Pt7TMoLNd0tgZuOm1VLpBHDgmIyhdT6pcfIthgmitIMlrOCJbuFTbN.PQrCClswc5aObXn0
 HvOLlfHXr4OZxmWCIrf5x9BMumADq_yUzEBcINa1NhVcBYWoXyIfYy.1M00rdbReYbZ4e865drFu
 bRPdfVGi.NhD3HF5mI5U5D8MZzaNV.WsVsHSM.xwQiFRvdgVgPkyit4SS9E6LwepliSWJcodSBdF
 lLvJ.KYlpI4CXtA.4MCOg.K3X4YxzUmEF.7tNUR9DMIUIUuqSDttjVZ2dyY6RQ7yf_fT3gQKwOV1
 lMc8htCWtEjipRS6UpDV7729Vy0oPoiKzag9h8NSShUs_TUteEl_CbDtSUDJ9g_zaFab_99jJNKk
 VSEGedISdawocz5mtGdH9yN3T09JC4ZPMqkuBOQVJiOpUVqLcW920EUYk6w8YRgXJxhz8sG0_h8v
 Atnh6i0w9_Am7d.cV_WRtR4PsPsqofFLrQmXoYHYYy9BTwJl8tv62kyjRzr9qVWCOOZ0Pw2qmlkW
 b7IlSdHQf0xlGQXlXoQITrQZzCefQISOOxibYT_ZgxY86lsgg26pOQ4rPnufF9ee099SK3pWtsC_
 4TzGs_2o1JRLE.cbNssOFhmWgz05AebedKppw6OixSdNO8rLLScPSlaZN8w1RN2Lah9o64JnOp3G
 O.1xNwedfQsOig.9Y64STgvgHPxMlqLkOnDjm_6ehJZoRWsKmStzf5J_7qsoKPAdOQREA8VTVXj4
 ueFU5xm1lFOqAQ.YH1g9j_NaQlPavmU.zch2J16cAzT.2Bh18VcO95TWCssIRQxsCfGSYnY7QaEl
 j2aDnRFNt7rU9bzsepUh5IR2NQKPalSplxTr9.cNEu2Mv2zvn.nHYErPwlSsJql3ciWQwWZucZFz
 kkQerS8icRxXKCOwgeaXB6b7HvjPH3coxH0IG1jPqHx2j5BVAZj9tUbgrLLxN4AapziSC6p9b__8
 WXlBXuCyslzQimm6.6rUUCCer0aVVJtikHwJhTTN4_W54zwiMs9t..8ms26U6GBaFAFNc.fMvnk2
 .lFgaMt23OJLnVjDx9nK36EGviPsFLdBDGfM.0P6uWTWAPvwm6a1HrDwwepZZv_UbtpCN6.KuA0i
 hk0qQgHqaXw27h_EG6KycF2BcN10PcUfrF2Ss_QIRJWZYZMixAKm0CnhMBloKHGqmmGlWSb6vFQ1
 YUKapnCnX6i9_AN3EP9P6E_enU96fDD_6j_W8KAfiSd0.sNcenIOhmYLIlfQZEhgRbWz9zAeAYUp
 cEI32TZwEs2ocvEDMJn4Mo87xGbSjNmVT9DYpRHk14j0YMoW4xqQPLL48YS92ttwJ7wKeaSAvJAF
 9_JMiVQHOEiTL36TAQ.lpZvAmNIoVpmi_yTIfMK1EZxMpGU4kFKqtGWxngHWUU2_APtT0kfMrg_5
 r2BJMgcRHc_eObrdT3s2R4YS3ft_gtzJ81eWT1QY_SHBrE.OabEQrSxAmQYUkYY8_a.01Qm4XJNj
 VyAUbCGIvSUd1YgpSWRwEzWUjcFoBL3nd8Uouv.NTyDT4FCXmIydnUfwqLLQC0w9Sb02PcLDg.9w
 UNRT3I3DCBdZpt.c08yJjo9lIN1RVlsmmyFY5eItbfcfTPlPkr3KKwX8HQkfaKRpLn99ZUVvQ0t4
 ocL1oL3eOQQDgajrMzVUIBKYgB1nsC0l045YvXMvT2pqzK6deaaZgof4WGpYKZwfFOkfIAHdxVGH
 Rgke23b9s_Q.EFCRCTPvlBs9ZbZq4BCs.ww9MF5dCe1f6r65rZ_WiAqrI7ANiFLooAdJ4YanTXUG
 4oWNUYzgzyz_uId8WszglrfbcFHpC3x.iUlWLXCZqfLQNrPWSMb1uHgLaNQue0sExZqOXC_5XA65
 BkiU91IWD3nA3oh.LrCO8LykUg.hkC3b9PIOFfPlSlRV.EdIAzYPMmXLikdQiLq2OxKOCykfF3E7
 c7gd94xFXlOjrHn6L6gt8QuD2yTyxugGThMUJmu.WbsAj10ABa22CsZMclPa84vuQu0u1.1lPmgW
 OugIQ6L7Zkd9Q4gHwPyPGKywxQs2EgvNm2GDxxTUFx0gV.fpiCGX3qB61Gxvv46XB1p.TeKp4dQU
 wcni7odc-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Sep 2022 22:27:13 +0000
Received: by hermes--production-ne1-6dd4f99767-h2xxw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5dd6d662883df3403de580fd96c614dc;
          Tue, 27 Sep 2022 22:27:11 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
Date: Tue, 27 Sep 2022 15:27:10 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McZ4N0fRyz4QR8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aT6EQd43;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 14:20, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>>=20
>> =E2=80=A6..So, for the vintage of U-Boot source that the u-boot ports =
are
>> based on, DEBUG would need to be separately defined=E2=80=A6.
>=20
> If you mean the freebsd u-boot port, I would suggest to completely =
ignore older versions/vintages .
> afaik Fbsd will not accept any device specific patch which didn=E2=80=99=
t made it (u-boot-) upstream.
> And u-boot also won=E2=80=99t accept such patches if not extensively =
validated.
> So you can use the port to compile but I suggest to use the master =
stream of u-boot as source
> ( I think that's what you had in mind anyway)

sysutils/u-boot-* are based on:

/usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=3D      =
2022.04

I expect that Bob is working with that version for problem
identification (which need not be of a U-Boot issue).
Changes to U-Boot to improve things would be a separate
issue --if such changes are even possible. (Bob is not that
far along.)

My note was based on having LOG_DEBUG and DEBUG defined in a
way that works for 2022.04 and after without having to worry
about the status of the change in log.h .

>> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>>=20
>>=20
>> So it may be best to always #define LOG_DEBUG in whatever
>> *.c file(s) before the line with: #include 
>=20
> Although that seems a bit unusual maybe u-boot planned it that way( =
placing the #define in line 1 of the files),I haven't investigated that =
yet =E2=80=A6
> I would begin with a simple #define DEBUG in common/usb.c and then =
look what happens=E2=80=A6
> and then I would continue with the other files you suggested if =
there=E2=80=99s no relevant output from usb.c debug=E2=80=A6
> using the master stream of u-boot=E2=80=A6

Until the following are changed to have appropriate
values at the overall configuration level, it does
not appear that LOG_DEBUG and/or DEBUG will do
anything:

QUOTE
The following options are used to enable logging
at compile time:

	CONFIG_LOG - Enables the logging system
	CONFIG_LOG_MAX_LEVEL - Max log level to
		build (anything higher is compiled out)
	CONFIG_LOG_CONSOLE - Enable writing log
		records to the console
END QUOTE

I expect that means having them set appropriately
in rpi_arm64_defconfig for the experiments.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Sep 27 23:15:49 2022
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 4Mcb8W0bF9z4dSy6
	for ; Tue, 27 Sep 2022 23:15:55 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630])
	(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 4Mcb8T6kpFz3HdB
	for ; Tue, 27 Sep 2022 23:15:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x630.google.com with SMTP id nb11so23725909ejc.5
        for ; Tue, 27 Sep 2022 16:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=HgMy7b7EVSVtWsGWPuXY7vdWp5sj2B5J916eY9VwEHQ=;
        b=d+DHjobGpF5dh2Bi99IoXRyeXgUDYMicKeTykb5tpposcjYrRH4g3F012R2teXagG+
         wlhbqUniESc95+8i5eRT8Ru8AshiCoRe2bGLUjxmeVYn3DfjB4zWptUowmCBY0teb48t
         kWxMO0+t+LVAKw1plRxo1djnxUd2DcdkKaMDAWsCfE7eBCv46xveiuraa80knqzaNfw8
         Jhw9jRGPLX5Rem78Ge+1u9CkF7bSlmRJSFHzo7H7oyarDwDEnJuMbmYlaMJQBYL9nFms
         akMeLckRZg1M304PMJzqL+bp75LjPqb30Zcsw8QgkgQZvlVRsp1NwMjurmKLdvAV86SJ
         KxFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=HgMy7b7EVSVtWsGWPuXY7vdWp5sj2B5J916eY9VwEHQ=;
        b=bEBYGYSCq7bLwSMp+Fw9hjwhBjOfn5Ca8LtQKAoMqCHX9zbI0rZ75RyunfwdYLpWNi
         vPqnEQOhUEEvxkGdAfLgNjpZzB7/XWbF4STqEz4yZqyDpTsQmg7Megyhqp90P0+lKpE1
         KdxmnFrLa++kjbm5HgLS5XmbkAjnU5JvpYAcIBvPoPhK9GhXNAz9N267g+3ALVhNw5Wx
         RVJcMFL58+R0rZAeHa6jUxPZa2bSMrJwuQqBHomismp19n17+GNDQahOdpeGF+tLBGl0
         b3Z9sVnE9OQFr2MWqtmS30QT0IY90qe1IMSnMp/Je4IV/bYBIGDGZqGaaY+ICZ8K3p39
         TgOQ==
X-Gm-Message-State: ACrzQf2W7nifyB3gg67t0HvSxz1vZ3O1ho2O0VSmh2t4rCakeNuAE9MD
	r90mct7LkwUIERxdYuPoa6zb2qZt/HI=
X-Google-Smtp-Source: AMsMyM4/nXklAR/5RGOSFylygIFSud5XlPmhIgYVNwNzQJxe1wGFvAsNEv48nAUYn181fPJmGtQIkA==
X-Received: by 2002:a17:907:3f9f:b0:782:a14a:fdf9 with SMTP id hr31-20020a1709073f9f00b00782a14afdf9mr20037689ejc.49.1664320551926;
        Tue, 27 Sep 2022 16:15:51 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id p5-20020a056402044500b00457b9c55b87sm1895736edw.45.2022.09.27.16.15.50
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 16:15:51 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 01:15:49 +0200
References: <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net>
 
 <20220925193415.GA63733@www.zefox.net>
 <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mcb8T6kpFz3HdB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=d+DHjobG;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.98)[-0.980];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 28.09.2022 um 00:27 schrieb Mark Millard :
>=20
> On 2022-Sep-27, at 14:20, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>>>=20
>>> =E2=80=A6..So, for the vintage of U-Boot source that the u-boot =
ports are
>>> based on, DEBUG would need to be separately defined=E2=80=A6.
>>=20
>> If you mean the freebsd u-boot port, I would suggest to completely =
ignore older versions/vintages .
>> afaik Fbsd will not accept any device specific patch which didn=E2=80=99=
t made it (u-boot-) upstream.
>> And u-boot also won=E2=80=99t accept such patches if not extensively =
validated.
>> So you can use the port to compile but I suggest to use the master =
stream of u-boot as source
>> ( I think that's what you had in mind anyway)
>=20
> sysutils/u-boot-* are based on:
>=20
> /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=3D      =
2022.04
>=20
> I expect that Bob is working with that version for problem
> identification (which need not be of a U-Boot issue).
> Changes to U-Boot to improve things would be a separate
> issue --if such changes are even possible. (Bob is not that
> far along.)
>=20
> My note was based on having LOG_DEBUG and DEBUG defined in a
> way that works for 2022.04 and after without having to worry
> about the status of the change in log.h .
>=20
>>> Am 27.09.2022 um 22:36 schrieb Mark Millard :
>>>=20
>>>=20
>>> So it may be best to always #define LOG_DEBUG in whatever
>>> *.c file(s) before the line with: #include 
>>=20
>> Although that seems a bit unusual maybe u-boot planned it that way( =
placing the #define in line 1 of the files),I haven't investigated that =
yet =E2=80=A6
>> I would begin with a simple #define DEBUG in common/usb.c and then =
look what happens=E2=80=A6
>> and then I would continue with the other files you suggested if =
there=E2=80=99s no relevant output from usb.c debug=E2=80=A6
>> using the master stream of u-boot=E2=80=A6
>=20
> Until the following are changed to have appropriate
> values at the overall configuration level, it does
> not appear that LOG_DEBUG and/or DEBUG will do
> anything:
>=20
> QUOTE
> The following options are used to enable logging
> at compile time:
>=20
> 	CONFIG_LOG - Enables the logging system
> 	CONFIG_LOG_MAX_LEVEL - Max log level to
> 		build (anything higher is compiled out)
> 	CONFIG_LOG_CONSOLE - Enable writing log
> 		records to the console
> END QUOTE
>=20
> I expect that means having them set appropriately
> in rpi_arm64_defconfig for the experiments.
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

I don=E2=80=99t expect that changes made directly in source code of a =
file would need to be enabled in KCONFIG or elsewhere ,
not sure and maybe `m wrong  because my last u-boot compilation is a =
longer while ago , but I think that #define DEBUG=20
will enable console output (of course only of the debug functions in the =
file itself). By the way,=20
nothing is bad with e.g. : /*CONFIG_LOG - Enables the logging system*/   =
:-)

I`m curious if you and Bob will post your 1st debug output,=20
Then you can optionally ask e.g. expert  HPS to translate USB specific =
output ;-)=20

Good luck,

Regards=20

Klaus


From nobody Tue Sep 27 23:29:30 2022
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 4McbS837m7z4dTyY
	for ; Tue, 27 Sep 2022 23:29:28 +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 4McbS73nl7z3J3m
	for ; Tue, 27 Sep 2022 23:29:27 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28RNTU0k073129
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 27 Sep 2022 16:29:30 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28RNTUmC073128;
	Tue, 27 Sep 2022 16:29:30 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 27 Sep 2022 16:29:30 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220927232930.GC72077@www.zefox.net>
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@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: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
X-Rspamd-Queue-Id: 4McbS73nl7z3J3m
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.77 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_LONG(-0.68)[-0.677];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
> 
> Until the following are changed to have appropriate
> values at the overall configuration level, it does
> not appear that LOG_DEBUG and/or DEBUG will do
> anything:
> 
> QUOTE
> The following options are used to enable logging
> at compile time:
> 
> 	CONFIG_LOG - Enables the logging system
> 	CONFIG_LOG_MAX_LEVEL - Max log level to
> 		build (anything higher is compiled out)
> 	CONFIG_LOG_CONSOLE - Enable writing log
> 		records to the console
> END QUOTE
> 
> I expect that means having them set appropriately
> in rpi_arm64_defconfig for the experiments.
> 
At long last I did it correctly and got a u-boot.bin
that's just under 600kB. After issuing shutdown -r now
part of the output includes

Uptime: 1h38m7s
Resetting system ... 

U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
serial_pl01x serial@7e201000: pinctrl_select_state_full: pinctrl_config_one: err=-22
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial [there is no uboot.env]
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: unknown device
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
[snipped]
*** ERROR: `serverip' not set
Config file not found
U-Boot> 
U-Boot> 
U-Boot> usb reset
resetting USB...
Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
U-Boot> usb reset
resetting USB...
Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
U-Boot> usb reset
resetting USB...
Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> 

Issuing
U-Boot> run bootcmd_usb0

Device 0: 

[tens of seconds pause, looks like u-boot started over]

U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
serial_pl01x serial@7e201000: pinctrl_select_state_full: pinctrl_config_one: err=-22
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: Vendor: SABRENT  Rev: 1214 Prod: 
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
Missing RNG device for EFI_RNG_PROTOCOL
No EFI system partition
Found EFI removable media binary efi/boot/bootaa64.efi
1262604 bytes read in 31 ms (38.8 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC


[lots of whitespace]
[boot messages]
Eventually loader takes over and the system reached multi-user.

The only extra output seems to be the line
Can't get reset: -2
But, the disk was discovered successfully.
The maximum logging level was 4 out of 7, fearing bloat.

I've subscribed to the freebsd-uboot@freebsd.org mailing list
in case it's a better place for these questions.

Having modified sources deleted by make clean is a nuisance.
Can the behavior be avoided somehow?

Thanks for all your help!

bob prohaska


From nobody Wed Sep 28 00:14:48 2022
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 4MccSY0j76z4dYqV
	for ; Wed, 28 Sep 2022 00:14:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b])
	(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 4MccSX14NNz3Pch
	for ; Wed, 28 Sep 2022 00:14:52 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62b.google.com with SMTP id sb3so23871388ejb.9
        for ; Tue, 27 Sep 2022 17:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=Fg9hTKiY47wVcJ20EINizBsEH5Z8DJ1JELfZP8NPpPU=;
        b=FnxppfR0Z4SyIiVsbv0Wlh+VSzH235zz0FF4tWP+n0pLp8iei5kLycqnBP07pogRae
         kDk3AZpqdcLPiAb0yi8Xjbyr8kEILeBgjgGp3c8MXOr2KJxILar2BJGiWwc4yrtUQTBk
         IAnmpkFZXbyC/de2G/+ZIDV2tuToubz98FaTI0RHqnaw5/4nr9PUkaC3ujdzbnYL+rUE
         9QY0X6Js8Bt2v08PZYG59haiOgQNUrX1DlTTtsonm+i13yhN1QeGo39Acm9Fm+oAFeIv
         ZvSTMqOWx8MTHGCc7QxImD5SB+RqxgjrZV7NdeS8PDSQ5t0A+fTEmpKcJVlVg+fr3/WP
         MZNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=Fg9hTKiY47wVcJ20EINizBsEH5Z8DJ1JELfZP8NPpPU=;
        b=31AP9BJn8HL7g+dpF1KoAIGP90gaw/dNT3jKhZ8zuVUc6IqGc9z48eMV8EYoOgIFme
         wUL4x3UsT1I4e1c9tAxoylNBGyiyPzuP5j8ekp0J+vkVxnTYm64KxTk+a9BEWDJLX9Yk
         J5CwEisDX5XpTtYG7c7sMNDTaVvfKuLVYKB6Yzcq9kztrp4r0W5rLNvc3H1oEb+c9yeT
         VtiC3U5T9/iriofRqMxJIfI84eluMh025dTkf7kQgBQ2icTPp8VR20spssEWTaAIXoea
         tzZH8elBjWZV/jTCx0fPgrf1AAdk5jaoyFCT+9T18DuoaWj5JxNN0+CJ8/cdPHwBfPhc
         j8lQ==
X-Gm-Message-State: ACrzQf16G5m/0YT1HsemyIsOR3B17RdgQesC91DojmLeQmnGyU4Z50Q9
	G9rPkPPQ6u4dFVQzLLRSp2k=
X-Google-Smtp-Source: AMsMyM418lrni6jMYNjxHBVCMOV+zBO73iKsRfR8ADAyf09wRbjhwR/uY7eoX7hhUDAX+Sa2pZI5gQ==
X-Received: by 2002:a17:907:2d8b:b0:781:c864:fffd with SMTP id gt11-20020a1709072d8b00b00781c864fffdmr23561375ejc.681.1664324090916;
        Tue, 27 Sep 2022 17:14:50 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id m4-20020a17090679c400b0074134543f82sm1516107ejo.90.2022.09.27.17.14.49
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 17:14:50 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 02:14:48 +0200
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20220927232930.GC72077@www.zefox.net>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MccSX14NNz3Pch
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=FnxppfR0;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.45 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.98)[-0.984];
	NEURAL_HAM_SHORT(-0.97)[-0.968];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 28.09.2022 um 01:29 schrieb bob prohaska :
>=20
> =E2=80=A6...
>=20
> Having modified sources deleted by make clean is a nuisance.
> Can the behavior be avoided somehow?
> ..

Yes, you can take control over the whole behavior of the port if you =
want.
In this case you would take control over the content of the .txz =
file(the file from where=20
the sources are downloaded into the work directory), as far as I =
remember I did it like that in the past.

Regards=20

Klaus



From nobody Wed Sep 28 00:14:54 2022
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 4MccSm5w8bz4dZ0D
	for ; Wed, 28 Sep 2022 00:15:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4MccSl70LQz3Q19
	for ; Wed, 28 Sep 2022 00:15:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664324101; bh=nOQyGUdeQ51QvKgsAF//hitpWvLvnleb1LfMYNM+Ls0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KC4TFipR7YUv8PK31fWKRkN9jsm6Gz1ZCquwwBR738OymAIoCeZWMSd95mOb4xUwuDZtbZsIgJWZMvYWpv9wIfZaMR0OlUh+ZQ9RN5UDiRJLc1tOafQme1e84p98hmZQ3NGWVnBtiYTuIa+YYblpMw9rBo8szggzvPwHsLsAJUbe3u3HRhD+MK+0hG1GOFndQ3/4sYcpI+omzOEkW0EqSx5/Gz2cvDB1XG/3yAEVx5VmiqXEZHZwJ502IVteqopelEGP8ujnvMzWZXX4NlG5Uom/44j97ubq/JtmfE9bPZ9QAfEFeozDVsO028xE+bLDwNEKiiTKmNO/sC6efzU/uA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664324101; bh=Gf7DyL10Gp02DeXgFXGtUpxDKGDWY2M/DdZfuGqnd7f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eYXzmFZRxdB9ew3BmqglqoZ0qScfjmwC2hzhucEbH9+TOLp2w1oDNp/kIQx6DrTir0wgL2Icsyo5V9tuJ8OBV9tRfx0Zzx23K2l3c6WcSRENMK7Xfz/3qqGKZuGKjkwO7tEHYwNLeHH6YlpG1UYgwue6SHYk4nhT4/0VcaWECy35Ggws245kc1Zta0TVUipfAB9h6icDORzMmHgNRyEjgqjS1BoFLevoERyh1s3yHHPYZ2+eqwJHBmrTOZc7zR+ydRVM1xHaV1mEQMFJDU902CIvCom/rKnKFkQhTUEzLOJGv5Q4awCqFaTwSUrBZGm+wMY1oYUryjQAZX8nePQWow==
X-YMail-OSG: X6JGHQwVM1l4isYQSKE6gOamAHhGqO6afZG8_6lALa6VEQ93N8HVzotADkwyiBz
 kKlaz1pS.u5oZenyt5js.aKwRs.4bFpazsBSwsjX8M27Z2Xz7YUTsILqzKMKwviGAhMAP0z9hE7B
 2qpzjHzzmAxsYH2STxlzyBB_a9f9QGDu.hSe1AONhWTVhWrhoRC7eR3QZjZQIjbTbZce0Z0jiBFQ
 h4OmDnwk_jPeDTXDS1GKc7LHhBG1XRgt47H_osQUCq.AhSED8bdUljyV0EwmGTLJiSg6dlGkn8b.
 Ky1fo3poBjm9AuhCST6AL7DZZHd8le7t6ZKygoUeB9Nr3PY2.WxSwtlMQann.FEN_4SB3rioMQj7
 .OGX2h549lBU2Dp1rYHTw_UbCeuT0d3.wlGICCzHbvWUir4Q4divsGyanmzah.yyjIaQhuKtON.1
 UVm4kr0lkoJ5bZs4Td4e4muZZZSVYdLHF6wjlGpAOQnqg617lpkmnHCTMw32bKJ6hINJh5SZipvB
 JLr5xEfl_8a2O43C366twRNAaLJE1I41I6PalJ953q_cIbL1Gtjmesik8mTzCaiurTjTzMXtVgXz
 LegciSDzY_gMULIFf2q6G0ylmq226OgxgI7OrY0OEBkRLkN9dUxIoOcT86LgqUJGQYOVIRtYRUww
 HZFhta0d0Rf1WLkR6QhYLBLpsSgH_1IG2TA7ZWofx1dS5wPFXwOOGyjeAB4Jhm8l_v.NIvqVWrMY
 73J94AG4uI2UvfeimE2Oc_enzbXl8qzdWnynRCrxj1Ig.PTq02Z3mbPez3_ndkFdR1mrmz.uhvoa
 4YTutAELnoooI3tTDTwDFDC6m9.eBAWkOnovfGu.OVe0dgEogTMKq1MVryKvNs42R2GQsWDKxmo7
 m3.Mp3.3iID5RZQJm79SoG4y4iqzpNtttk.8XSrLqzAZqrOiXxyIsfuLL8f1oibI4tn.CamkebFG
 gOBA0D5JrO7Ge2R5ToecIVT1kJKmnujF2b7T2zkeOZFELCb1r5Q1_HOWYynKbX9EqavPsozdbMrq
 xc3K0CSnvnUic3LH.yydnCJ0yYW5DOxYL64O1mOi_hepoczZbrMrjut02IC21p.EviNkgvsyH8p2
 6JKVSegkRQAJd9xPu5RbfaSHgvmqqhqvVVyH7NKmgeYBx.wANySGK0j88TDYvPLTdhMrE0lDPms0
 N9QoJ1eB5PhXJXZ4U5JkGSLSZ7GDkmeVQs5fp5Cp.oGbesPFym1_0kH4Hauz.pxnUaBg1u68zQK3
 7lDr09B3w2SMAnSbdEYDaQw5N.I5_LGKX7j3_wdLCCRZBOIpb6_VwxPK_yBuk5mnMAVcV6i2_C1J
 cEn5Yma0cEeLtszGliTTQMwxQ3B2Bq6Nryc2Bvq1V54l8P13vhvcEwlbTkLvP0BXkleQ9Y_Ekt.u
 zfnFK1bCBtQtkLTpwb8PWHiW1Yw3ndaNN1iHfNvyqz1285KJioA7sCJ.LKmEz5UEnSuIUC.5EcIT
 UVSqR3hZHyFWSkYt9WaycK2vyTwgrBzHLuDYwjOqQS4ldOqNVFTDCi3U0Akp.b_bJKVBHXZwmMIG
 IGlTJcu.PzftsLJAzt7qPrsMp1xB0UmEkc4iw44sdqv1vejA5dQE.UUaleZ5KvoICKg2DyZzB6dp
 6TOVKE.ZBaTNxspIFY5zBsFCWpROX96WmO2zDAuUX86oZz85kMboLOWWY2MyJHrSNh82sQo5wrjI
 pUg3eifPgUmaLPHKjsH3ZuCqi60bE1BvCSzohuBilvnpZxLVwRtXamCtX8rZxEedj4v5EdYfnXkv
 xMk3E8q7gE9ELdLjR.tk60ON0RXTLfE_RBNWbeBfO1pDNz_yAOIJEPULybEfJlFi1XNVMlm0r3_k
 fwJub0CAgdecQ0zATF8MZW1ogBG2HgAMJBV1JWUtrAd.eQnAtQelUXwtQj.L_9.idqzDOPiBeH.K
 iZIhv75kQaEPqybgCoVlPPazvgVtmCQJ_x3.kl4fnagTGk.qlqnNOTVOQdeuoT8WPn_Mrp6YyLmc
 n8XGBQk6S_zdKJSKnhJ5SeU3g5ft68OeuAAryndOVl1jw8X5Hj8FUOt.aw7xWTGEObAZjMcwyg6S
 Ct1jHCbcvG3_BlbZenvNAWyrYSadXi6KVXFVtXemhL93MbEyP1ztYu9CcIXXy6tkREGqXSchTm4p
 4ZQ0CoV2Fz4difApjZ6Ii.zIOENkdmH6I6gCdJNWGraWBhbngRPCb4l3vQwllMjeS.vMo.ndnw55
 0cmZeUO3NqoSch1NCUemwME_Iu751cfkbUAgC3W.9qvfKUIrwAyGynjcRmaEMC5MqkfY5ZayAfKy
 D.Iq8CFY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 00:15:01 +0000
Received: by hermes--production-bf1-759bcdd488-4bs5n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 565ca6147cd23d592afa471034720bdb;
          Wed, 28 Sep 2022 00:14:57 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220927232930.GC72077@www.zefox.net>
Date: Tue, 27 Sep 2022 17:14:54 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MccSl70LQz3Q19
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KC4TFipR;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.40 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.90)[-0.900];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	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.31: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.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 16:29, bob prohaska  wrote:

> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>> . . .
> . . .
> U-Boot> usb reset
> resetting USB...
> Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
> USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> U-Boot> 
> 
> Issuing
> U-Boot> run bootcmd_usb0
> 
> Device 0: 
> 
> [tens of seconds pause, looks like u-boot started over]
> 
> U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
. . .

Do you have RPi* firmware debug output ennabled such that
you would see messages from it if the RPi* firmware started
over?

In other words, can you tell if . . .

A) The RPi* firmware and then U-Boot both restarted
vs.
B) Just U-Boot restarted, not the RPi* firmware?

If you can tell, which was it?


===
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 00:24:05 2022
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 4MccgG5Snxz4dZrc
	for ; Wed, 28 Sep 2022 00:24:10 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(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 4MccgG05Cyz3QgS
	for ; Wed, 28 Sep 2022 00:24:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664324648; bh=aB3ENRw61967Rp+KnOebx+CZH0awE333in5TxQQh7pY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WyHnClN+8guluTrSi/olAhf5pTgwDV32wgAxCxZYQ13qXOp7i3Fj3PM2s1fZzHHJjYAJFFE3Zz4owq3CR+h5trwsbQ42SbWVOfNPxB92EGLd4Dg4tmS31SgFr/3aX8ahGeH1KJhag40naD/0BFZvXQBWKO+5dQOz9t4GRa3TnkBYHY/J818zSDP6spZ8WpOvZEvW5l8SJ2CSlGJMf4bs3B7sjVxsRp+uqow5oIW1eU8IU6Kg7R5eOb4pUQGpaDHpuyyFRvMBsHfOm+BeMCjylW3JlSzxOPMVRaxHNUAgb6mJ9N1TRTuRzhAGp/EvFpU9/k58breKyH0raTSomEwdXQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664324648; bh=NKgd7jZ6AjCaHuWe+8zQkB/mIOumY4O2ojDy+NOc64G=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W9FQv6B7aF04D6L0A9deaNggWcWc/ZWs/j8fd2+NxD2xqm8ZZPutiOz43CJvqBqrO6x9Ikm4HJILi9g37ZdDuRGS+aR0bb6YcOwPjmEREhyEMHWXU5mQfghWeikBcefXYpDhkjjU5//gVV/2RjTaV8VWgh13Vo7U2Zt6K/MsmnqeZTD4XAlIZaG+3hNobV5ueOV53xTGt6r+3yZwCVeGTnehqJvx3if10HTTwLgl4+FanzoJZRgpvY5Z4rnHC0DqUgoT6bycmhXvAVm51N5cBlRnNCBQw1kFir0hXPk/G5MJk12QJ/EECkGw/miwRcllIGx1XU3PN1trElLCcmElhQ==
X-YMail-OSG: rHABl.8VM1nXDWKYeW3KOaAJN0BlUmy3c9eJunnmmTnZNYCfRTEoPOpNRkCr6Xh
 NjtN5OWPsmsAvfbtM3w3ojBR4ZwRrfmRmrVP_zW6y.AYIv9xnbo3efrnqKjZF_6lCSQOgcZIkds9
 EIrAcO6gMA5WSwZKXlzl6_e2fnG1fYOUSXKuNXq3GofIPxnB3phwQ7.2hFut855PoWc7NGCnPCIU
 T3j3AChcM0au.zWmqoItuZKd_O69LUBoYDviUfIo39eVc1MFfG6kkVQDK7blGuB130vJmhE1KkyY
 UaBngTK981o_rdmn6zUwlqFpXqR9pnKvLtjg662wRzgYZYqO.UwczWte8rOZYQ9H0qzAkTqTJZUs
 bCVt73qxnN5LF5r8ilggWbESV2bYmDxhDNbj2DkGLWiWUKMpC7eHl1iMHfK5v3kG9MGddbjPpdnu
 9vcNQCK30FYd2oWULO9E5xpLrcSvWujWfeR_dcUFuQz78YXzWkAm7oXaniZguakjeSSsq0.uFJHc
 J.DpBCUTESB2FhtWAWrVukXeWOpZBfCczeDgtlBy1jDqg6swMaimRVzEFfAau4T94PXBYq9OIRn1
 a2utX54bFMEngIyojT3yrBTLmC29lhNENjRvg.EibeNX6OTlMHsXeP8fASvXT4htCcZmHgrS2Ny8
 XmU4ktkcZmJXqLeG3JYtZx8Zdhe.HSqvthaZS7rTJ4KzbSveCmZ0Y1O56OanNYdVdjFjzQ.dgfge
 QZ.aAGwyioqQ8KQiygiG31EPoid33kk_lcWuLLvUEmsZxn5TZeYnnIB3uj_WYPUnWPw3GB0RULzM
 QlHcb5M_j1yxv89Wx5w03OLOddeOnLPmOng3BWbNpnkCHHK7y83Zqgd8SnPOytcguKmO6lhm5k20
 pN4orwsaBHbfG222vo6rsZLsobjJe3XhgddTQdkWR5TgtM1UOhFSlDmIPMwzW4k0FyKda1VpBQaT
 RQx5wh7oO_R_L_ivQTCUXTnkcCw5ycdax2X6JWkGsvhwSW5skqjKKKNgwbEl2X6MJGva4tjFNzp2
 yE2uwQV3UZ03Rco7LaLn8rU3phmvE.i97KJzX6vsmGGpVwTCLwwlzMhfeiY2eP2bC4qVYKENGsFU
 6eWQ2VchB8u03hweb7UYc3L2bCf_FcwazWMjHPd45wDBFy6rsC1FUTidixRUajs78RUhA0OmT7vq
 fODHKC7edVipjgFi.KgmgKiiWhJKCJN813zGlOAo_xHRkUevELbxZDwJAf91csnxIt1R1vwh90XI
 q7kHuHag35.ReFkuETEbgr1C53Ox3o.iJGJG6dTP6mzhvY3_RKdteKM4HAEn4wSkRvxJx9xR2x0d
 EYGtVPqBb5MeCVVHziSVPWzeo7JPFMo0k8DW46vaPk4WjW3za5nJm3npRv4T7QDld8xPg69PYY8y
 .yG13lYQXEt794U.ZnJRIlwb7ApkKJItUalRk2DYIJ0dfHYWlLvhBQF68R7jD0UO68AFhJ96VHMB
 WCYdvw1hv.pr6i8RwSiZ1c9P__Zn8Vrn9p_citlq1kDfLfmIcRcZguo.Kzgkv_kL_REgyWDTvCCv
 ui3jF.JcvVDGfU3DO05NcZNQ5J0Pm6evG86m4DIy47h6RdqcM1newLsh4l4bMYFEz7KiGJRyfqZV
 pn0LlZ00TlZcC76l7LMz4gChHqb9BBFoBhOIgK8gRHVk7O_o_PM0dKaawLbc7EXTWrKh7eqh5VHV
 SOne4Hq22loCU7WGaANG60iHe.m4QKfAzg1LyEbQ4rYZRyEsohJehXyKL3lB3c76Hbc4LLKDxfCR
 VGrGOYNSDPnsrZnaRUiRg5sgJDMb5MbYXBTAZI_TURO7iWRkvKi59ZJgGYHfOhhScBrFWikNSGgW
 MFnVl9qdEqqJlo6_.27kkEHvtVJljHhWRW12JvGeb7uHMj9hdeIs6QQp9teu.IacsMoi_94X85L2
 p4EefQIF8N1ZD5OpLAzbuk9PZgyHq0B4VYhh.748SNjwQMlZxSfcEbeg9DoCUB6obycqzgtfoxe0
 NBPoZn6HxLwnQWtH0yBekYcaQkXUmyq8Ksh8BgKteMyOKPK1jObA239LACJgd2qd34cg9jzqdLJa
 KZ2ytQRgipTlWAz8qqGV9kmeHh0jvwZYZeoQ9hTnYi5mQvHEItohsqj.LnNixTEfA1kLN_hXNi42
 pLhX93DOak1HRJxLqcnknechboNJyiYxeQx6EsJxkRrYCxdXJRKKBI.4jqSUaEAxCgKPto7oxOQu
 neXLvInLyd9nI0g2ysiNX5fF_vXbe7zNxX5GGNfauIsAponvGkc5esXcsfIuXDrCjINBBKPAxXdP
 DUVWCOig8
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 00:24:08 +0000
Received: by hermes--production-ne1-6dd4f99767-pwmjm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d525ec8265d30f4c11ecc679ffe4da90;
          Wed, 28 Sep 2022 00:24: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220927232930.GC72077@www.zefox.net>
Date: Tue, 27 Sep 2022 17:24:05 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MccgG05Cyz3QgS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=WyHnClN+;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	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.66.147: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.66.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 16:29, bob prohaska  wrote:

> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>> . . . 
> . . .
> 
> The only extra output seems to be the line
> Can't get reset: -2
> But, the disk was discovered successfully.
> The maximum logging level was 4 out of 7, fearing bloat.
> 

https://github.com/u-boot/u-boot/blob/master/include/log.h
has the below. The first level of debug messages is
LOGL_DEBUG (a.k.a. 7), 4 is LOGL_WARNING :


enum log_level_t {
	/** @LOGL_EMERG: U-Boot is unstable */
	LOGL_EMERG = 0,
	/** @LOGL_ALERT: Action must be taken immediately */
	LOGL_ALERT,
	/** @LOGL_CRIT: Critical conditions */
	LOGL_CRIT,
	/** @LOGL_ERR: Error that prevents something from working */
	LOGL_ERR,
	/** @LOGL_WARNING: Warning may prevent optimal operation */
	LOGL_WARNING,
	/** @LOGL_NOTICE: Normal but significant condition, printf() */
	LOGL_NOTICE,
	/** @LOGL_INFO: General information message */
	LOGL_INFO,
	/** @LOGL_DEBUG: Basic debug-level message */
	LOGL_DEBUG,
	/** @LOGL_DEBUG_CONTENT: Debug message showing full message content */
	LOGL_DEBUG_CONTENT,
	/** @LOGL_DEBUG_IO: Debug message showing hardware I/O access */
	LOGL_DEBUG_IO,

	/** @LOGL_COUNT: Total number of valid log levels */
	LOGL_COUNT,
	/** @LOGL_NONE: Used to indicate that there is no valid log level */
	LOGL_NONE,

	/** @LOGL_LEVEL_MASK: Mask for valid log levels */
	LOGL_LEVEL_MASK = 0xf,
	/** @LOGL_FORCE_DEBUG: Mask to force output due to LOG_DEBUG */
	LOGL_FORCE_DEBUG = 0x10,

	/** @LOGL_FIRST: The first, most-important log level */
	LOGL_FIRST = LOGL_EMERG,
	/** @LOGL_MAX: The last, least-important log level */
	LOGL_MAX = LOGL_DEBUG_IO,
	/** @LOGL_CONT: Use same log level as in previous call */
	LOGL_CONT = -1,
};


===
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 01:32:43 2022
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 4McfBY1DxBz4V3Gy
	for ; Wed, 28 Sep 2022 01:32:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4McfBW4xhwz3VhN
	for ; Wed, 28 Sep 2022 01:32:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664328769; bh=Fk+el1sqCQMOkalQUhchl0qBoT/ClWmXM1k92Tog+9Q=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=GkfjNOwqtAv1DLwCfor01ugUMusJ3M4LmXzNJ4I3EW/cOy4apzsC0iNm/6DKVZB5HaZr+EBwZwqSSp66eCob6wV6Wmio0qTCl5zxRZ3gT3rt48HHWiWvF/EzsQyVcglGPGOSWKFXhJ+w5mA08V7BJznotH+NnzYtTJhrsdwgEz0Nyjz/uDFYWHTPAuVeg0KB5VxQyeM+SvplgOkjn88UIBKL2yFl5gbi+7njfUprCHB9f3/SBQ3PkdwikLyH+rRhwNmebQljATw03gDpg5CvrklYxqIbDfIRVis4f35rVbVs4FMlv2LDSOBFvjBl5oQLlpOJxOuWsGK67BOYpcFryQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664328769; bh=R+ZjzoRXKPPvfVnxjAO2C/kLJ4A8SHyHH4ZM3mXaQIJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RsgcX/WEvDOsCZXlIiFehTdH6cT8E8YW9VMf6t7AASaREbPz6ywu8Q6RHgHBwOY75cIhfd1DiZ4SMYfZxYPoYjr5MHiKPOz6Giepx1a8YmkrT3j5c83DDfRJ5ApzRup4j1LGWl9lMnp8aeM+lPVyw51psVjkQ9DraeuE+ABUbWBqUyNsRRabwvZWUogHf+E9pFZ2P67QM7QTcahJFfLwRG3qTSc3kTKKHb5nsJhr/H7wf4EKSO2yNdlelhzD2BYd3lrcaNnkzO9E4zdB8SVExtadgztepWaHjkIZ3OqxdA94j4Rb0+Y7aU0/fsX6hVNzfXyvKrcO/WCfxUb4ek3UVw==
X-YMail-OSG: VuCllp0VM1n_0bA9ihdvrYgJmCmOMdadVAmhsrGaLwitKR8UBi21y2zG5yb7b7p
 lVaBCtClLOIb6Iw.6FPXBF0o.znx.q1Orkgg.hVwINRKD1G1mTbGgdcsZ_fGFi9KDrMk1jsSbInh
 h1.wMZnrMd3RHnpZYciYVQUtSpR0dSh5PigxZVrRotVvBQMoyWgFAvlm7wu1bOgrCbZ.__Gejl1Z
 VrSZxYzh7WQpAVRlepuBOs_VYaWKiUT9d6wAeF2AMxv.qboxrhb8e.iUwTKosCqZnZ9C2d_hPd9H
 ESIMsvOm2tF3jSuQwgUMtDiWg75qMwUpi51d1PIfuPfjmk96l11HhpPA05yaqHi9x_QsNJPohr29
 QoP0BmpY_BXQaVLImK1dbnkQpnI03mhw8SSh3vhRcH5JrLJpevRxHmn6xWWREwdfP0e6PxdDuwXs
 KcHa.0jCR2DXiKHJOUMQcyeGZjHDi1t5s14u5ZsbWRU3O_mIb6VGn9X0qbcC_wjZXMA_BXWRA1fT
 UCSEcHrx9O7skCc1dXAcGAde_Crx1Cx.L2I8K.9IRtC13FGXiGrnVRjtxKcDGnx.Or1ugLFvjugx
 07Rogtu9BqDgb78i443iuK2eocrFxe_cfMz5sBT5.uhQC3BYNGuocG3gdq3W_VXJyrFgfnEP4m7d
 ToI4GQqZetsKGH7yA9NgRe_qezWPk5YX44vHiw3fNgKBC69cVfA0foZozJjP3y5QovjxBlw5tiTf
 YH6fHW6cWYmG99f2H_LxOxifok2wmNTaRlLVoP0FK7nmqAn.bmXx.QWsthLTJT6maAyt5E0DkQak
 lw17g7JSANoBCttG0.UgCEILz11273vUSLeRgLAzeUeLJFQ_81kU0pj3RjGHgLx3I3pe.NSZh9Lx
 z6f66KPIVyFL4LQQK9Rj9DkF8BtF_sVFR2buaYpr5ryUUoye6.jqfZDHH8ev2qfM7j8FjDRDduYn
 OtgyfuWDVuN4mib4LmTg8jVE1Gz1m6ffBhvBFSCCTS4d.0Zeag.j_.FEKEbfB4eVCduTAajCQMp7
 uv92ny4xKhmeX7iavNmBSV3XQNPUJ7rb3Raw3wqf79utNRG85V_LJtf2m0NTdeWSe4kGnGZxSzbu
 uDlEhzqSCjYO_7FZyR_EudRca.sE5_JLfstgxflOtrO7r0p829d9RSXQF6AJT_q11.aXf39dQus7
 NpmLy5yra0XAm25.kogVdzj5BdUs3XqAbctdAkcXUJyKAp0NbgB9uFSxdI0puWLPGVeGh9UtB61x
 hI4XdJnnAoomM7X2tCMTgpL_sG2j0SzEUm_Zi3lmh6DAYiUOqMJk9cvSyltBZwGAd2IGUzDsHCXn
 NE2AeTigOYdiWl5nJyZyH8nVT90fwELWfqxdd7Z90MGCYR6vFWU8mlKRf4.i5ug8LARnf57XYpy7
 Vt3q9lDHL1Ya3Fx.3MjYzfCk8aH2FFJNTQkrQgnsRpKw7eGeqXnw2ChCjIH0zoBlsalXhi.HHqhL
 tRKUF7g2c4P3qZjr4Dn0aPe2cyaS2P81iF0YEAf_lkGwJBJIzKwfH3O0ISAby7Q2zcde7LaYyN63
 w_fi9k28PdAqVgWlLVpEXSFD3IQ9MnblhtrzS7xoepdAjwmjG.Zuax5uByr_6XRT6HPp5xGuIfcT
 RgbD77CiQtFgSreSPD1z_IgCC_h37HNaGDuBxZu4_BY..K0vVwaHF4gkEchRkIdAQjXXsehgELuz
 ucEffl4xT9Lf0aScew..yIZuqpliqLsFOqFsaenIvj9ZD39Go7D89fGDxO0c2e2CdOMVQpCCja6V
 5.USAHPnW9_OOdx9NGT7_on433jk9RU5f3UwAN0CzU9jOnaD6PQa5OZ_1EZJSFfkHrc4ir8BMuzA
 H0DUv02Ba30495RyM5yFCu.btFVgrBDlV11y8j2DLkfx8Pco09A3_PDSiYh3sTdE0aXukS9VOtoh
 eMK.gHRdP8U1AJEGfhXn8.HUNGur7tOuSDdEZd47tZBhN7OpGYEJ13gQ7UBqFDr_wHg4w5z0IMCx
 ybI.QMYe_kGbgXMuyfubnHDsfk0mfo6xyyfCnbQpZEMaZW.ww2SF6RNn5yzgS.VVpF9UstFEL0qo
 sen5049u2cR9gTLLU4QqxfgAOINtwKXHA5fnemBXx.0cOgB.d_ovut4zP8vytLickGsbh9XDWBxq
 0m8hS7mcGDgPsFpqWC54rhFx_nuTzk1WCg3D0NzMzF6e6cUslZLmjFs8arAmrKYN4YcQIjZR2xVX
 DBq61V7KX9stAQX7g4UxP7aktYCxG_bj7ruJALqX8ZcjMA6.lAKC7DSbOM6CYu_bDpKXNx27vNOj
 onomgkfWPfQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 01:32:49 +0000
Received: by hermes--production-ne1-6dd4f99767-97ndb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3cb3afad51fdff147607b1b9be4908e5;
          Wed, 28 Sep 2022 01:32:45 +0000 (UTC)
From: Mark Millard 
Message-Id: <304AC869-3B6F-4302-A206-73BA6B8E6B95@yahoo.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556"
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Tue, 27 Sep 2022 18:32:43 -0700
In-Reply-To: <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
To: bob prohaska 
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McfBW4xhwz3VhN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=GkfjNOwq;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.36 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.86)[-0.856];
	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)[multipart/mixed,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~,5:~];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I got a sysutils/u-boot-rpi-arm64 build to work based on
standard ports-style patching (otw files are not related
but are present):

# ls -C1 /usr/ports/sysutils/u-boot-rpi-arm64/files/*
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb.c
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__hub.c
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__storage.c
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
=
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-lib_efi__loader_efi__cons=
ole.c
/usr/ports/sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment

The rpi_arm64_fragment is updated by adding lines for:

CONFIG_LOG=3Dy
CONFIG_LOG_MAX_LEVEL=3D7
CONFIG_LOG_CONSOLE=3Dy

The 3 patch-common_usb*.c files are patches adding the
following 2 lines just before each #include 

#define LOG_DEBUG
#define DEBUG

I've included attachments for the above 4 files.

The patch-include_configs_rpi.h is my patch for allowing
my media to work. This may well do Bob no good but is
useful for me. I've not included it.

patch-lib_efi__loader_efi__console.c is unchanged.

I do have a different vintage of RPi* firmware in use
than sysutils/rpi-firmware uses.


The U-Boot part of the boot output looks like what
follows. But I can not replicate Bob's problem so
the output is just for reference. It gives a clue
just how much output to expect.


U-Boot 2022.04 (Sep 28 2022 - 00:42:50 +0000)

DRAM:  size=3D30, ptr=3D8a0, limit=3D2000: 7ffe690
size=3D8, ptr=3D8a8, limit=3D2000: 7ffe6c0
7.9 GiB
bind node psci
   - attempt to match compatible string 'arm,psci-0.2'
No match for node 'psci'
bind node system
Device 'system' has no compatible string
bind node axi
Device 'axi' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node chosen
Device 'chosen' has no compatible string
bind node reserved-memory
Device 'reserved-memory' has no compatible string
bind node thermal-zones
Device 'thermal-zones' has no compatible string
bind node soc
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node timer@7e003000
   - attempt to match compatible string 'brcm,bcm2835-system-timer'
No match for node 'timer@7e003000'
bind node cprman@7e101000
   - attempt to match compatible string 'brcm,bcm2711-cprman'
No match for node 'cprman@7e101000'
bind node mailbox@7e00b880
   - attempt to match compatible string 'brcm,bcm2835-mbox'
No match for node 'mailbox@7e00b880'
bind node gpio@7e200000
   - attempt to match compatible string 'brcm,bcm2711-gpio'
   - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches =
'brcm,bcm2711-gpio'
bind node serial@7e201000
   - attempt to match compatible string 'arm,pl011'
   - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011'
   - seq=3D0
bind node spi@7e204000
   - attempt to match compatible string 'brcm,bcm2835-spi'
No match for node 'spi@7e204000'
bind node aux@7e215000
   - attempt to match compatible string 'brcm,bcm2835-aux'
No match for node 'aux@7e215000'
bind node i2c@7e804000
   - attempt to match compatible string 'brcm,bcm2711-i2c'
   - attempt to match compatible string 'brcm,bcm2835-i2c'
No match for node 'i2c@7e804000'
bind node local_intc@40000000
   - attempt to match compatible string 'brcm,bcm2836-l1-intc'
No match for node 'local_intc@40000000'
bind node interrupt-controller@40041000
   - attempt to match compatible string 'arm,gic-400'
No match for node 'interrupt-controller@40041000'
bind node avs-monitor@7d5d2000
   - attempt to match compatible string 'brcm,bcm2711-avs-monitor'
   - attempt to match compatible string 'syscon'
   - attempt to match compatible string 'simple-mfd'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
bind node thermal
   - attempt to match compatible string 'brcm,bcm2711-thermal'
No match for node 'thermal'
bind node dma@7e007000
   - attempt to match compatible string 'brcm,bcm2835-dma'
No match for node 'dma@7e007000'
bind node watchdog@7e100000
   - attempt to match compatible string 'brcm,bcm2835-pm'
   - attempt to match compatible string 'brcm,bcm2835-pm-wdt'
No match for node 'watchdog@7e100000'
bind node rng@7e104000
   - attempt to match compatible string 'brcm,bcm2711-rng200'
   - found match at 'iproc_rng200-rng': 'brcm,bcm2711-rng200' matches =
'brcm,bcm2711-rng200'
bind node firmware
   - attempt to match compatible string 'raspberrypi,bcm2835-firmware'
   - attempt to match compatible string 'simple-mfd'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
bind node clocks
   - attempt to match compatible string 'raspberrypi,firmware-clocks'
No match for node 'clocks'
bind node gpio
   - attempt to match compatible string 'raspberrypi,firmware-gpio'
No match for node 'gpio'
bind node reset
   - attempt to match compatible string 'raspberrypi,firmware-reset'
   - found match at 'raspberrypi-reset': 'raspberrypi,firmware-reset' =
matches 'raspberrypi,firmware-reset'
bind node power
   - attempt to match compatible string 'raspberrypi,bcm2835-power'
No match for node 'power'
bind node mailbox@7e00b840
   - attempt to match compatible string 'brcm,bcm2711-vchiq'
No match for node 'mailbox@7e00b840'
bind node mmc@7e300000
   - attempt to match compatible string 'brcm,bcm2835-mmc'
   - attempt to match compatible string 'brcm,bcm2835-sdhci'
   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches =
'brcm,bcm2835-sdhci'
bind node gpiomem
   - attempt to match compatible string 'brcm,bcm2835-gpiomem'
No match for node 'gpiomem'
bind node fb
   - attempt to match compatible string 'brcm,bcm2708-fb'
   - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches =
'brcm,bcm2708-fb'
bind node vcsm
   - attempt to match compatible string 'raspberrypi,bcm2835-vcsm'
No match for node 'vcsm'
bind node clocks
Device 'clocks' has no compatible string
bind node phy
   - attempt to match compatible string 'usb-nop-xceiv'
No match for node 'phy'
bind node clk-27M
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-27M'
bind node clk-108M
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-108M'
bind node emmc2bus
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node emmc2@7e340000
   - attempt to match compatible string 'brcm,bcm2711-emmc2'
   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches =
'brcm,bcm2711-emmc2'
   - seq=3D0
bind node arm-pmu
   - attempt to match compatible string 'arm,cortex-a72-pmu'
   - attempt to match compatible string 'arm,armv8-pmuv3'
No match for node 'arm-pmu'
bind node timer
   - attempt to match compatible string 'arm,armv8-timer'
No match for node 'timer'
bind node cpus
Device 'cpus' has no compatible string
bind node scb
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node pcie@7d500000
   - attempt to match compatible string 'brcm,bcm2711-pcie'
   - found match at 'pcie_brcm': 'brcm,bcm2711-pcie' matches =
'brcm,bcm2711-pcie'
   - seq=3D0
bind node pci@1,0
Device 'pci@1,0' has no compatible string
bind node ethernet@7d580000
   - attempt to match compatible string 'brcm,bcm2711-genet-v5'
   - found match at 'eth_bcmgenet': 'brcm,genet-v5' matches =
'brcm,bcm2711-genet-v5'
   - seq=3D0
bind node dma@7e007b00
   - attempt to match compatible string 'brcm,bcm2711-dma'
No match for node 'dma@7e007b00'
bind node hevc-decoder@7eb00000
   - attempt to match compatible string =
'raspberrypi,rpivid-hevc-decoder'
No match for node 'hevc-decoder@7eb00000'
bind node rpivid-local-intc@7eb10000
   - attempt to match compatible string 'raspberrypi,rpivid-local-intc'
No match for node 'rpivid-local-intc@7eb10000'
bind node h264-decoder@7eb20000
   - attempt to match compatible string =
'raspberrypi,rpivid-h264-decoder'
No match for node 'h264-decoder@7eb20000'
bind node vp9-decoder@7eb30000
   - attempt to match compatible string 'raspberrypi,rpivid-vp9-decoder'
No match for node 'vp9-decoder@7eb30000'
bind node leds
   - attempt to match compatible string 'gpio-leds'
No match for node 'leds'
bind node memory@0
Device 'memory@0' has no compatible string
bind node sd_io_1v8_reg
   - attempt to match compatible string 'regulator-gpio'
No match for node 'sd_io_1v8_reg'
bind node sd_vcc_reg
   - attempt to match compatible string 'regulator-fixed'
No match for node 'sd_vcc_reg'
bind node __overrides__
Device '__overrides__' has no compatible string
bind node fixedregulator_3v3
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_3v3'
bind node fixedregulator_5v0
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_5v0'
bind node v3dbus
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node __symbols__
Device '__symbols__' has no compatible string
bind node bootloader
Device 'bootloader' has no compatible string
bind node clk-osc
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-osc'
bind node clk-usb
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-usb'
RPI 4 Model B (0xd03114)
0
   - 0 'serial@7e201000'
   - found
0
   - 0 'gpio@7e200000'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm283x_pinctrl gpio@7e200000: set_state_simple op missing
simple_bus soc: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
pinconfig uart0_pins: set_state_simple op missing
serial_pl01x serial@7e201000: pinctrl_select_state_full: =
pinctrl_config_one: err=3D-22
Core:  198 devices, 13 uclasses, devicetree: board
MMC:   0
   - 3 'mmc@7e300000'
   - 0 'emmc2@7e340000'
   - found
0
   - 0 'gpio@7e200000'
   - found
simple_bus emmc2bus: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
sdhci-bcm2835 emmc2@7e340000: set_state_simple op missing
1
   - 3 'mmc@7e300000'
   - 0 'emmc2@7e340000'
   - not found
0
   - 0 'gpio@7e200000'
   - found
pinconfig mmc_pins: set_state_simple op missing
mmc@7e300000: 3, emmc2@7e340000: 0
Loading Environment from FAT... 0
   - 0 'fb'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm2835_video fb: set_state_simple op missing
In:    serial
Out:   vidconsole
Err:   vidconsole
0
   - 0 'ethernet@7d580000'
   - found
Net:   0
   - 0 'gpio@7e200000'
   - found
simple_bus scb: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
eth_bcmgenet ethernet@7d580000: set_state_simple op missing
eth0: ethernet@7d580000
0
   - 0 'gpio@7e200000'
   - found
pcie_brcm pcie@7d500000: set_state_simple op missing
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
bind node usb@1,0
Device 'usb@1,0' has no compatible string
0
   - 0 'gpio@7e200000'
   - found
pci_bridge_drv pci_0:0.0: set_state_simple op missing
starting USB...
Bus xhci_pci: 0
   - 0 'gpio@7e200000'
   - found
xhci_pci xhci_pci: set_state_simple op missing
Looking for reset
Looking for reset
   - result for reset: reset (ret=3D0)
   - result for reset: reset (ret=3D0)
0
   - 0 'gpio@7e200000'
   - found
simple_bus firmware: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
raspberrypi-reset reset: set_state_simple op missing
Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  2 1 0=20
Card did not respond to voltage select! : -110
MMC Device 1 not found
no mmc device at slot 1
MMC Device 2 not found
no mmc device at slot 2

Device 0: Vendor: Samsung  Rev: 0    Prod: PSSD T7 Touch  =20
            Type: Hard Disk
            Capacity: 1907729.0 MB =3D 1863.0 GB (3907029168 x 512)
... is now current device
Scanning usb 0:1...
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
8Scanning disk mmc@7e300000.blk...
Disk mmc@7e300000.blk not ready
Card did not respond to voltage select! : -110
Scanning disk emmc2@7e340000.blk...
Disk emmc2@7e340000.blk not ready
Scanning disk usb_mass_storage.lun0...
unhandled device class: xhci_pci (usb)
unhandled device class: pci_0:0.0 (pci)
unhandled device class: pcie@7d500000 (pci)
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
Found 7 disks
0
   - 0 'gpio@7e200000'
   - found
iproc_rng200-rng rng@7e104000: set_state_simple op missing
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
** Unable to read file ubootefi.var **
Failed to load EFI variables
Initializing EFI driver framework
Adding EFI driver 'EFI block driver'
0
   - 0 'ethernet@7d580000'
   - found
smbios_version =3D 0000000039c2403f: '2022.04'
BootOrder not defined
EFI boot manager: Cannot load any image
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
Found EFI removable media binary efi/boot/bootaa64.efi
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
dev=3Dusb, devnr=3D0:1, path=3Defi/boot/bootaa64.efi, =
buffer=3D0000000000080000, size=3Dd18dc
unhandled device class: xhci_pci (usb)
unhandled device class: pci_0:0.0 (pci)
unhandled device class: pcie@7d500000 (pci)
unhandled device class: xhci_pci (usb)
unhandled device class: pci_0:0.0 (pci)
unhandled device class: pcie@7d500000 (pci)
- recorded device =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x4e8,0x4001,0x0,0x0,0x0)/HD(1,GPT,9cdadf2a-de3c-11ec-8f37-a0cec=
8d68fdc,0x800,0x82000)
- and image /efi\boot\bootaa64.efi
858332 bytes read in 31 ms (26.4 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Loaded from disk
Booting /efi\boot\bootaa64.efi



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556
Content-Disposition: attachment;
	filename=patch-common_usb__hub.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb__hub.c"
Content-Transfer-Encoding: 7bit

--- common/usb_hub.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb_hub.c	2022-09-27 17:31:36.202280000 -0700
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#define LOG_DEBUG
+#define DEBUG
 #include 
 #include 
 #include 

--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556
Content-Disposition: attachment;
	filename=patch-common_usb__storage.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb__storage.c"
Content-Transfer-Encoding: 7bit

--- common/usb_storage.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb_storage.c	2022-09-27 17:31:49.314637000 -0700
@@ -37,6 +37,8 @@
 #include 
 #include 
 #include 
+#define LOG_DEBUG
+#define DEBUG
 #include 
 #include 
 #include 

--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556
Content-Disposition: attachment;
	filename=patch-common_usb.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb.c"
Content-Transfer-Encoding: 7bit

--- common/usb.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb.c	2022-09-27 17:31:25.890219000 -0700
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#define LOG_DEBUG
+#define DEBUG
 #include 
 #include 
 #include 

--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556
Content-Disposition: attachment;
	filename=rpi_arm64_fragment
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="rpi_arm64_fragment"
Content-Transfer-Encoding: 7bit

CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
CONFIG_RPI_EFI_NR_SPIN_PAGES=2
CONFIG_LOG=y
CONFIG_LOG_MAX_LEVEL=7
CONFIG_LOG_CONSOLE=y

--Apple-Mail=_F45195DF-0924-4905-B203-6182F2010556--

From nobody Wed Sep 28 01:57:21 2022
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 4Mcfkm5KPrz4V5Gh
	for ; Wed, 28 Sep 2022 01:57:20 +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 4Mcfkl67f8z3XB4
	for ; Wed, 28 Sep 2022 01:57:19 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28S1vMsL073497
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 27 Sep 2022 18:57:22 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28S1vMli073496;
	Tue, 27 Sep 2022 18:57:22 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 27 Sep 2022 18:57:21 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220928015721.GA73356@www.zefox.net>
References: <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@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: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
X-Rspamd-Queue-Id: 4Mcfkl67f8z3XB4
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.71 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.61)[-0.608];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 27, 2022 at 05:14:54PM -0700, Mark Millard wrote:
> On 2022-Sep-27, at 16:29, bob prohaska  wrote:
> 
> > On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
> >> . . .
> > . . .
> > U-Boot> usb reset
> > resetting USB...
> > Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
> > USB DWC2
> > scanning bus usb@7e980000 for devices... 6 USB Device(s) found
> >       scanning usb for storage devices... 1 Storage Device(s) found
> > U-Boot> 
> > 
> > Issuing
> > U-Boot> run bootcmd_usb0
> > 
> > Device 0: 
> > 
> > [tens of seconds pause, looks like u-boot started over]
> > 
> > U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
> . . .
> 
> Do you have RPi* firmware debug output ennabled such that
> you would see messages from it if the RPi* firmware started
> over?
> 
I do now, enable_uart=1 is set in config.txt

> In other words, can you tell if . . .
> 
> A) The RPi* firmware and then U-Boot both restarted
> vs.
> B) Just U-Boot restarted, not the RPi* firmware?
> 
> If you can tell, which was it?
> 
Looks to me as if A) is the case. After the 

Device 0:

line comes 

Raspberry Pi Bootcode
Read File: config.txt, 239
Read File: start.elf, 2952960 (bytes)
Read File: fixup.dat, 7314 (bytes)
MESS:00:00:21.191824:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:21.196253:0: brfs: File read: 239 bytes
MESS:00:00:21.252921:0: HDMI0:EDID error reading EDID block 0 attempt 0

The machine is headless, so I think the HDMI errors are normal.
Following the self-inflicted reboot the machine reached multi-user.

I'll see if I can figure out how to apply your patches shortly.

Thank you!

bob prohaska


From nobody Wed Sep 28 01:59:29 2022
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 4McfnN2pNwz4V5Wm
	for ; Wed, 28 Sep 2022 01:59:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4McfnM2Vtwz3XkX
	for ; Wed, 28 Sep 2022 01:59:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664330373; bh=NzpIrZDoYRTdYaBg1ilD14pVFELxnNx8j7z5ZTjIgaw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=V8mnGpVXWr5P9a0fmo/5t+kMLogDTEfQKue/4J6w0auuRWG1XCRNLoWNfU0wigMGk3Pv0tWNTr91O744mzfOFYuFC8el4UdXFZpMY5AJEVjBWFdKxmO1C/8Vbdmw00RJuLboB/6+h7g0v6FH+vBJTFi+v+7ThAJ7RsOuCND/olEfYbMlPQCfl0Cl7f2F0jPJZE0SBQ0RimASSZ/eBBn2CYcZyN4F0ev5uqUWpCOv0c0wx4qTpiUFa4sOWTyijUur5kxtZNAtqSz/QyKeHDJyYs4DXDuEdWkZCqSgJoXHytEU4Dhh3vGn1UQBqCNHLIeslnzCBtvIHa6zhy2iX15oMQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664330373; bh=6S/t9+6vIEPFZ0JfudcjJPrOGyTP7rhjq0+GiW2c+/u=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UqPKLc9jjqWKqJbk+sGy0p1dVEu6WLEldyeaotmJGiSm75ZF7OEVAH5m+FP8294/PkGknwU7/d35HgOBWKABWRVriBItUETUO00HD05m6yUHulshU7gnUfUTLceC6x7w9FWKWT7WTQF8dp9lXK9pZz9KDg4DS17780/9YRWm2UiEXv+Qjc5vMKLxhDRUtzZENL7DGdzVgqQHjuINp8e5+rxaCwaWA0n8a/f+1Me3M32hmd5UP6OApM/rxIlloBhWJPUViHBXR3GSNPaZ5Xbayq9MUsz4owGsm8Odjm3Dl12y/opVp/h0gN/ZljfAswNY1qYxKb2TSxqusr/kbnVHQA==
X-YMail-OSG: 166fml4VM1nt475.Z5YaP_.XixdV_8VmLMciEdqxxlDG076tuKzEud0F4hxVrhk
 Yl9DIBBzp8hHdNbih45VT0XW_2Hu_YTEMYpWeodbHAVGeaxs6phznRAoxYcfhYn3M_qMvqxjK17e
 NAkYBZrP8k7CMzv9KmRALFthmayQp0ctGkxyvdvfAE_girUboyUaYBqIaZqKkU.Vq8NOYvhsPVD5
 0.UUrNE.6xj5fLfnnD1AdFme_P97atNFZNZbEzp34xSfYtlCxlHDqlF0sDe1zB9XiSBNI8Frm5pd
 kwRnYO8jjicY1AnVkuyelHJRW7DhjyhM_ZvlDp3pObIZBj5giwT38ozyWDJr3.7cjeP1fDBadGd.
 .2pIiDsqAKw74xnNZa587WryvR9QYMJ_Tunx02gHLwGbKNPq1clPKUcJ5uz8zfKFmI0csQipcLNd
 lWbuktbh0lTacIil2H_tZ5HiCK7PAZumi8SG1yGCaU9CYg7_eHqdoybptz5f99XqFIW4Yu_FhrwE
 haisZjwtNbAxs8JNxrOYVsu5DSmTwCBWwlmVMTcvvIOJXDDLJIlViO9RDS6Q..L50f1nSeHy3zVI
 xBVAkZ40CC.rYDng0kiJb0AHEVAyZv5mPvUsHHfpV1QLDlY7X_WNQzDFb2WGZ.mK6Ff4_8Wx07lD
 WJSF6ZM2diqusq61LT_6weJ.JE3OG0KXkhbdNrN_Mt2eE.iGClC8BxKq8xdfwommLoJcJ7pagVA8
 X7k1AUJrtY8ql3kftQAEdEkDEM8M.u8DeWoYbvkihkL1K9iP.eLyXT5C6pvR4nwgbpoM_QPdg50b
 vt_lz1.bYMOUQFwbC3Q3OOzGGJUuDrhGWc83lBhtW5wbDo_nE52jcMYhUpZLKgKCfR8pWFHhQnYK
 vmZwb2DzdTBaM.4iJIwuiGbcxcDyhvVGSY6Rvm8NHdccBUoG0FxIMtBi.H_t3RI2SszgYUM.tXUK
 gWmuNS8Oj68ZT4n_VoNiTJ20YdlTcZ.p8ADuNtiFz4cVewnc410EpBx0ntidnT0odrIHlBgJhpaU
 3DQtXFuZUWuS0a4SXpJM5.PH0NWshv3Mtp3PwtwQ6JlJ38XPL54Dd9O5LkDfRu2ktdoPY7grXtPe
 .ic0v6_FgcWyVrKCerE6dllYlp0uCKQaLMKQuOzGs7etZjxI2DHP6dGif8VrolRlUOdUVtP69T5h
 5eTZZB.Iw.ovxeXkPbDjH82poXml3egVxCn6OoAvzsmTTpIwvDAi53TO4MLY39hr.fYj9q_aVtlH
 kWnx12RQ1KPv8UrHukC5RBR4HX91ffZceeMRLvubMyGcecE_MxGmD_0w.JVepoIfnRsRcI0vT_pP
 OkrtalUSOw50IBdl2MMO88_ZorvuW6hNwcEXywO5wEgR8kCp_s_fVx.SxQ.BPdkLWb_re4zISha4
 rTm20mTMjsNuQNAVk5aOFFLVvZRNn8GEXvcssniUtpF0y0bQIMaICy8vS7s_ENjHDeTWIsj05alP
 JwiGeZgHQBzjsQ0JfqnPbXhYt3t0PIufmaVcc8LlN5a7VYDKGoNEI_7VOHjb68NuerCanHngnjmo
 K1fUk9hP.0ljEBGhZSX_a1l0hM3_FfczQlbPHPbaU4mft7MZ3FRgfsZHVdjElpoiTafUIPYGOREP
 JJBPChIiOcBJ7bnSiU_slFBVg5MMBaNrZrKkaK0V8e4.OA1j341dedzNWqu8Ja7NfnHTSrhWcZno
 FfJLpOqcEGYmhG.iOMfeggYnvhLCespjEySXtkWPBDW4QwgJireMijnyFy152NDUpxzJLRkuFqNZ
 oBp08lWeLGZyoJVRY82Icz8.UcxuAc9gnhpyMNx7YXhOPeeq1YvEjIWsmw7vLLByAkX.QrUpj153
 TAV4AmG2rSOO20JftqDog46GSMau3.ViUo1pzDLTBpVyloo61Opp81SZk5mZfrUHouLq9YGMGmUn
 KoLpt0IFxj8j6okdC1K.W00tnn7on_kcEHJ7JICiYdOeWGhGmJn4iprJAtZf6_VZ_NrnbQ8BONw0
 AkPlx7ZRbtYOregbTT5RJShxXXE80wEbAqC3j_jMV7ExMrF3HvvbyVFEcunuAkDwE0d0CNWpQ0uG
 MaQAFmIRpXlwviTJZqCAqUyuQrqe.M5xowDW.J5HpgdAGalIPeMqEhgNgbs6QmERdv_oaMxc7ksV
 8nHcAfy74T6BzXXqNeFh.hJVq7OQG.nwT6iNXiYMYfO9WXVae2JAUie5S65qalLIWzku1K.ThOio
 UAztV1kU34myFx_46nC42.Fbxh1MkmAgLVEEMgkYAUhCJ1j2F0rnAtS2wAu55mN53KP_K_mm1LHR
 AJymKmCOC
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 01:59:33 +0000
Received: by hermes--production-ne1-6dd4f99767-w779p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51f457168e8cd1a106eed8b48effe2f1;
          Wed, 28 Sep 2022 01:59:30 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220927232930.GC72077@www.zefox.net>
Date: Tue, 27 Sep 2022 18:59:29 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McfnM2Vtwz3XkX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=V8mnGpVX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	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.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.69.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 16:29, bob prohaska  wrote:

> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>> 
>> Until the following are changed to have appropriate
>> values at the overall configuration level, it does
>> not appear that LOG_DEBUG and/or DEBUG will do
>> anything:
>> 
>> QUOTE
>> The following options are used to enable logging
>> at compile time:
>> 
>> 	CONFIG_LOG - Enables the logging system
>> 	CONFIG_LOG_MAX_LEVEL - Max log level to
>> 		build (anything higher is compiled out)
>> 	CONFIG_LOG_CONSOLE - Enable writing log
>> 		records to the console
>> END QUOTE
>> 
>> I expect that means having them set appropriately
>> in rpi_arm64_defconfig for the experiments.
>> 
> At long last I did it correctly and got a u-boot.bin
> that's just under 600kB. After issuing shutdown -r now
> part of the output includes
> 
> Uptime: 1h38m7s
> Resetting system ... 

Note the lack of output from the RPi* firmware at
the point in the sequence.

This answered an earlier question: you can not tell
a full RPi* reset with the RPi* firmware starting
over before U-Boot starts over vs. just U-Boot
starting over.

I expect that when you have said/shown U-Boot as
starting over that in fact the RPi* reset and the
RPi* firmware also started over (before it starts
U-Boot again).

It would help to enable getting some output from
the RPi* firmware as well so that you have evidence
for when it is (re)running.

> U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)



===
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 02:13:03 2022
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 4Mcg552nxSz4V6q5
	for ; Wed, 28 Sep 2022 02:13:13 +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 4Mcg541LHVz3YxX
	for ; Wed, 28 Sep 2022 02:13:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664331190; bh=UF7qBiDqQz1P9sVCgYP6hZnaizmxisQLl/Mz1EfRoPQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KMpXFFZGR/jUTQc0/cPYhA3XbK5MyB2SDjw8RfJ4wijL6+OmUNn7sE7JX6zwSeBj8fZq48yht4SA5zwwBN5lJoMebQj2ta4voi9XlmguQO80qtUS282LAmPUzVpXL3KXcCxdiKKEdC/tRDJ29ycMu6Wd/HYAYZjv+4EkIUNIIxnWkK4FovyE7l0Pq7QePVdIJxolDjLmHcZO64fmTVHtPXXI5zyGMrqHXJ9jJ+muw4+bxxM52ZiRjZN/mebVBld4lLr1HgKAgDZVmloJMWDGAOmjRPzDWqDDB36P0dAZKMiXkpQKeJvJH+M9BPUIcwcJuNtEFaUgmF6LbUV9samtLA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664331190; bh=R20BxY9lphdpaiTaU313sM0sEzZyMkDMvM/E7VVMexm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kczxotF3/Gn7pKUEY6l+GTeu19QndifAkZm82UWOoluD/hrGWPb4LqBBCds1OYikF7gVRja4NAwbyW8pmSG6zKSpyigvPa79eWVKIODG+xm9CvHy68gmkBgEw52kwkgI/HFVcaZilQ/kxXjeDMDHehZodn+7VtEnle8vweQNPTjUgUO5HoByLsDic9/Nb7DMf6VZvytXPi/CKv9199aPJVWhogbajcmH/ZZUfN1WRNMsMI2V34rj7iKCXTEpbnQNu9UFDag1Dey13YdzjHHo31eHocVE4JJ3/IqQppQ3B9gHtE3LugnQwiLIsBQ/YhSrE3c/HnhLixalKYqZ51WHYQ==
X-YMail-OSG: ws5lOcwVM1n._oc1DE5Zd4itpw5ok.Hk__ck_CJnAibg2F8WJr.84BZeksJmTKK
 KjHr3McDYe7t4TvLhEKoZzNUFo2SjZqO2YokVq_lOa1NVzCi_KeTl24Zy.jLTZsttTlhrJ.rOgPp
 h7pPQUde9XZsgjl7Yrab_ABiMwnnc1XU_83GsQbzAZNhlm_qrZk3P7dTOW0VTMH6LzAXFb1qTYr6
 YbF60D8e81Td_wuJ4ekQER8XqxGBlWYnyT1CUpi4Ui4bXcSyrmJ1w_oA.v.xJ6zxSSgLpSI7.syv
 lWrFDtUduvoeG19MlqR7i7xqv8o_t0rXtq3ZuVt69RvvNfTQbTkZNmdQHj7ScUrb76eoa_jiV9C0
 dgCo7c3lsxzzJMrhQMhYg18w8SO21dvd5jhOhTYRUf.LMuRh8tz4IXL1aFv_bnn9A6vlhioZKM8V
 d6vvnByGc7WLKIP2QULXJi0AsMkfxYUqjFSo4CGqJbHOdnf.q2ko_Gs6TB0M0EbDGYPhj4zjb.oK
 vJWa46x3mScAWocT1xjmsOjJbfUAALaREp2MxfLJLdCTa0GrUhv59RnVe3F_nbKVRMVO5MihBdhm
 acFiHef0AhH4rx7Dt6QPV03g32.Dsro5pKfBRQz2zW4qXz7aoCA6XP5YLkTfqybX8ksoxCq7e8Hd
 L9g3N_DB72oAgW6njXDidgfxCSrg2aHJaZzAO1Uli6oG3A_pbLPyWf7CXGCqfYXGdlkRipMIcf6v
 xti5omTKYooCWWdrXnHd9Lud7Dc_HToNRQMbTyOLYPZVydx7gz8QlUu6iP1pes_cmn6L7P3d9dbI
 sueZ1rayJljalN8xS.fSjAX1GX590lkS5hpmVbNARwjfyzGFKmbBwbYeN_wH0UPsPqC5rgEbEhA3
 LeMD_7YoYMLQEElqgAV3GFTkZm4KM2pnP33d3BxvtNC_RV6x3bT_tnM925HuW21FKTjtdL6EJA1t
 sw9CXvfsCKhDMSSlJ9D3zzBwOOIhZKi.vZKXkb2JAfHB0gLf4Pt0DJa2Gvv_DDfEizJe51wTojhx
 Q8qccAyg89DqVKfSsOFKCTEckq6wwPCgNtQkievBJteqpe69Qgz.OwXJc08BOM58Yp9oBkexJR6B
 UIvVAqytuST4xr5yD.vz6ewC04idfRU2VRD2TQCIryjr1fVXG9hKOVjmwbF86cAlPPe6iscedZGN
 Ujhcc1IwSYZEI8qYz7XrMmjY3qvCkJvkv3Mc6cfloUUSLtTYPsLaGcifIO94RUEXWaU84XBvOxmv
 Dm.Hsxfsi1iO2gR.2D_IstVB56XBIr6XOTzz39OweX0Kg0dBFDonjWDnwkirTQsmtq5Q.i8TrM2Y
 w5uGUpaVLNSJTzo0jHLv5qbc1KXpxxzrLNqUULE8MawqSI0Ox08XVunYxtST7eTu9R15efMtyZiU
 t1hmHW_C_RLiifcRtkMayKBcZMYJNnfErfnaL4FVHO_NvANJbuc5GF3ThEyDcOKzIRD0tMGpGoyc
 GsFRkC6F494ns5Y8lI82wQPoQR5hyzvggUWo44vP7teVSQvSeMSL8z6vKDGHUHmh.z_z_xTXPKbC
 D6VgMQSUH9XYBmZUSguUjJgMqbD8BOxte3C9GVkrmpavBOOD7RHdoFb3sJtCSy9rW3kVdHnCs4si
 weNJwtz1jwkAqGIG_h1AO.jPs9RNry9815Uh2PZJALWP7vujyVAzm8Sp8YZJizcZpA66rXct4Zue
 0rFbUuy3kl6DSfEsMPRoSQALytT7seGMoU9ptsdG1w8fqjWmUa2ORGaVwbIZ3ZW5fLQm3g9fubrF
 tTB_KQspO3d.iZYZrB3YymzbvivcPKbXIk4HumiTKpc4hi3XrbGuFSgV0O1Ixcnzx8G30ijIOCG_
 zigPl85F80_2uD7gkohF_ddiKHFInAwvnOQEp.TIVyVIuDybuJv4K12UYmIX1X8Vs20iHxNMPSCf
 vfAsBXyopfbyg7UKvjD5sXT0YZP8c4j6aFq3jH8oJp0agpHKLwodbBv2jkYyl_J2BwqB.lDf2eNN
 qYiiYQXAVaDGOtxF.i_Q0zJ6nSJxMB7a0hk2d94kVZcFGgBUHjDO69U3b3WwhBRl.u3WmqYL4pFb
 2AMgUAsaDoebV5QxDdcoSEqOzQ.fMhsS4Sh9xCPf27beyNxilgtPMf5PSYya3AEdVQKOYvawZK9_
 w61Q9XGKFr5unMoWMmO_mZg8oV9tzz6W_CShTYL1SwAfTv3JnnvPhXrvSQ6RaIK_XlQe.fLQFeXA
 7_NHnpLZ81ZOOezn.uItir.rLXMHQlkiw_Q.l.EnUfQRIoC7l1fZeA83_OBZ8m0dK3zY3C2OEHC0
 S5Ajr9maR
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 02:13:10 +0000
Received: by hermes--production-bf1-759bcdd488-4bs5n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b7523ce67b2a23cdd1a1ebacebcf575;
          Wed, 28 Sep 2022 02:13: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220928015721.GA73356@www.zefox.net>
Date: Tue, 27 Sep 2022 19:13:03 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mcg541LHVz3YxX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=KMpXFFZG;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	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];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 18:57, bob prohaska  wrote:

> On Tue, Sep 27, 2022 at 05:14:54PM -0700, Mark Millard wrote:
>> On 2022-Sep-27, at 16:29, bob prohaska  wrote:
>> 
>>> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>>>> . . .
>>> . . .
>>> U-Boot> usb reset
>>> resetting USB...
>>> Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
>>> USB DWC2
>>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>>>      scanning usb for storage devices... 1 Storage Device(s) found
>>> U-Boot> 
>>> 
>>> Issuing
>>> U-Boot> run bootcmd_usb0
>>> 
>>> Device 0: 
>>> 
>>> [tens of seconds pause, looks like u-boot started over]
>>> 
>>> U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
>> . . .
>> 
>> Do you have RPi* firmware debug output ennabled such that
>> you would see messages from it if the RPi* firmware started
>> over?
>> 
> I do now, enable_uart=1 is set in config.txt

Good.

>> In other words, can you tell if . . .
>> 
>> A) The RPi* firmware and then U-Boot both restarted
>> vs.
>> B) Just U-Boot restarted, not the RPi* firmware?
>> 
>> If you can tell, which was it?
>> 
> Looks to me as if A) is the case. After the 
> 
> Device 0:
> 
> line comes 
> 
> Raspberry Pi Bootcode

That indicates that U-Boot did not initiate the reboot
of the RPi3B: there should have been messages from
U-Boot for it being about to make such a request.

This again looks like a possible power problem where the
RPi3B uncontrollably restarts. Even a very short power
problem can lead to such.

Another possibility is if the RPi3B firmware has a
watchdog running that initiated the reset after
something took too long in the watchdog's protocol
for monitoring progress/activity.

I do not know a way to get evidence for which.

> Read File: config.txt, 239
> Read File: start.elf, 2952960 (bytes)
> Read File: fixup.dat, 7314 (bytes)
> MESS:00:00:21.191824:0: brfs: File read: /mfs/sd/config.txt
> MESS:00:00:21.196253:0: brfs: File read: 239 bytes
> MESS:00:00:21.252921:0: HDMI0:EDID error reading EDID block 0 attempt 0
> 
> The machine is headless, so I think the HDMI errors are normal.

Yep.

> Following the self-inflicted reboot the machine reached multi-user.
> 
> I'll see if I can figure out how to apply your patches shortly.

Like when you tried my usb_pgood_delay related patch,
you put the files in the files/ directory, allowing
the one replacement to happen. (I do not cover the
attachment to file conversion part of the sequencing
for your context. As I understand it went fine last
time.)

===
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 02:25:09 2022
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 4McgM41Vwvz4V7t6
	for ; Wed, 28 Sep 2022 02:25:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4McgM26gjjz3Zbq
	for ; Wed, 28 Sep 2022 02:25:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664331917; bh=LP2zQwCtKp418SSDQeJqXS8dbM00fQDAm+K2taYFw9U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gTuM99ijriC8umej2OTeP2IWiteuPyH0oeE7ZTecxMAikDXH+oWJfjk2r3xklNDbZNufxNOEASLyxXTltfgsaZKpZGPj3C5iNHlM2o5tQBdSubtGJ+ca7j+fhdj3BppOWa73GyNyLDyEY7RlbyaYjPvVhDYpeiKeOBzVIIUIhgQ+HhDpphSahDk6+BDpdYS7737DuY34jqo+EfkvK22OketaNHNA1h9JNL5CCQ29u/2T3UECQrCaAQi4IOAri46N2bfijfGle8Mt21htDqDMkey0FlepjyiSXINCaJZaQ+4NbzEYG26lisMHS01eFkkFx8pxdghJ8LXK+GepgdaVLQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664331917; bh=j3pBNGp1mTUTjj/Le6/idOr9w4294mMRIIkJOkB5+lb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j91C+0n6q3c9tp69OGL9GVZGPpgSxMv4PKz4e4lPSFe47D9dbmP8rCeAnFA/ZOW05jZskUqhPCPeuTDtmvEP48LPjl139XVVA3KMhjFVcVkwHEtmJo3xwd2kr4IFKKic1lhxrEWvkgyFy8uXRMaiCLxgdZUZFF/j+/zG0hhheGOcWAZQBZS8s/LJ//w9aXKjO7N4c5ZHKGz+B3jaImouVQB8TqPqrc+okBq7H//AWXkzxMakiweyVMlChRdN1nKLEl2Wdf3wamI8XyRXF2msYfAEmB5flvgIEXJ0S8zUk85D9AWTZqrlxNweC6TKUTk8wOCb2NlwjvjSKhHfEur//A==
X-YMail-OSG: xbRjRcMVM1mfUzyhLRLMPozDQwvmISbAobAn3cLxjEx0wYDZrolvZzmjkcZ0ZfF
 rYw4h5lQ6rQEhKjJf0gk4K_cGtVvJyouOKhWFo59TRYTcr8vZns4gQSzfUYpTKJTV71PxtYyWw2S
 NsED.HW4HoktLKfII7tLpiieMD7sPUVL394Rj8gus6wV0sFrtmv2oGnnNf0ITeNKrRP9CKrVnhTs
 ztRpAScQEbGYPFu3yQGxb0uHsnyfAtSkgM5FVIQcdSBuPbPYgNpMbZ9L7fCxvEReaEGOP1cmOPp9
 nAptW_vPKKrhxqrdYbX9oyBFUNdFyofp_9CbmNJMTvzPOAmz2T2e5JCder_gKMW1yV3bcbeO_5Iy
 bafsjjCIHayno.xqpj8B6ac2TYib7cpSpezqrFZpH5oZFHOj.xVubw8TQF8tGzocMxNKu0XDB9ao
 ShW6vC0c5YeWzxwBbzwc6WW5SeeoayueQ3_1qzDyLBW45cQBQ_jP24yzDFO1N18QCBbP2FoDSWvl
 hmzqKBcs.6AMNzCIOCVZkKU.f2saIFfTZqiVb6kZMGW.NVhOZ2ZAzU5U1zEk5rFTdLQ0hes_EA7e
 Z2hFClOdQsW4lUalxRIUGftizJ4_nKAEhf56mF.3RaBcnElNkTbL3TzODMwX6QOww3pSj9CKGrN8
 v0ficz9_21c9Ja5Nldg4Dwtouw3uX0qmd4b0jY6SFYvKvT3Fmilx4mQujxVO7qD9TWwwC05hkk_s
 fJi.HYYcPUq0vp4Btn2RAWAU2s4jqcRXuceqR.K_K3AzzBYq..GMU0XrjXr9Ej7kIKeoeYIONxkm
 q8Dce3Y_FCrGdWig_Rqfgq9YJh5yMBZcXYVl5wwLp577Z1n1TDJhQNYSjOj.3XMx7.k84AHMh0m0
 mHQ3L5dUaCKFNDDSVGLT9UbVs0hec2L0njJwom0hVM6eRNmAEkuDOGggv5_9rlKUjjaIWKeCFz0g
 bvE0IDQWxpgEj2V6_cLpYCbXB8gTY5a4t0rz9cICMVfM0KJqipS5piFsYLGuLHEzB2X.gikasDWL
 uFfVUV3r7LYJoAIg0V01HomLxcJ0N5NmdFdEhMqohXHY4lf1oB5uBdXhb1FuMABwxWukVGkxKk0.
 k0tE696mYTzhETSonIIq_2bxN6b3x4IcmP_QP589rxK3hBBYRmSUQBdaZSeXKArOwmd_80QQn9nN
 wohOkP9E1SedEHoCKizeudcNqmEmY2olXWL7uq7KDFKCfHPB0SvPOARvUbvek7J7maeWOl7MX2br
 .rKL2KMitc2mT9U6pUIRvUOQK_qoRt_B9FpJ3pAQTKkFY04t7r4YkcB5gplFWtcxw6SOrxuFfC_Z
 JsGly9EN9w0nlyTsPL76qWitUnfSWzgCnOM4GD2SAkU3GiXdEeEMnfVHIMr7pI3L3vXmarJpW2Q_
 OPNEEivqb_wUvnKHxoivxQVXypQKjgetOm8zVyamMfZV2tgI2ic81Wc8KZzo4xTUT48aEvtaxQoX
 TlFqbfRV52.TbpxcAVlPdNSVh8gnmkZFL7yrhqQCJwmTWr9wdw1QEVAHog70K.Ib.u0FBLl9z5AR
 AYbCCh2qFZzyxGhFQXTfS1o.R5H8iGf1jM6BES7pRfmJBZwWnOo4BVH9vkRXSZaAt4bbQs9oj8b4
 cUUn68AZIFhoD0VYPimSzhVhsFqlc0Yq7IcdC2NxeMVVez79JBWDqpTplY5.gy2EYiFVMG2GnJzr
 I.qjA6XEE1Wz.ITCKY1OnwhwPFpQG1p7aSnwzgOfhuH9Vo7xhuoJjMSSLi_mwNZIR96Ku6SYCz0H
 kRRtG.6srKawjXJq1EF_mPVLLyN4znjnpuCzlLsvNVSKA5yTuEGunUAnISkzrGaXJD21NZQ6DSbq
 Eu.Tuf3oD3BH2DfqbkIkBeAL9mKm0BrDyhYNM3CdWFIeOM.Rq80k49wG_jWCUIxbX9.RzPT5HVSu
 pJW4CGBHsNs85dchT5vSm4UCnC52.brMzSJBbb63BXFvuceDAg360LxkHG0BkIIahJJx.x5sYFb3
 24RInIcTFfIAWpWDpQoWUukEziFEKZvatynAy48UvI0ArFXY6P69spzUXD6mNe6FKlmt6fwyzuSG
 eZc9lwK1RJfQmHuexSAvwoKhKNWKQmbk.KlrRMhkVW5xNkRAxh.X3_7jisZkfDUGkdcf_V2pwHJH
 etwoWUkW2nshjh30uZL1rB8mfyDaTv_TAhzrZhkuJUnmMGPgS6e6PunP.v4xA80QyO7K_nmO_6VL
 5xVmQ4wMwsgEx3WPkmp_V33eKzt_s1_.uRGFrZ9ElyXGS7OnXas.35tjpuak1LrPfBX_y4y0HtqF
 vHghCVIF5
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 02:25:17 +0000
Received: by hermes--production-bf1-759bcdd488-v8j49 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 35b2e023577342379fe6dfd1e51b063b;
          Wed, 28 Sep 2022 02:25:12 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Tue, 27 Sep 2022 19:25:09 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McgM26gjjz3Zbq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=gTuM99ij;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	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.146: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.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 19:13, Mark Millard  wrote:

> On 2022-Sep-27, at 18:57, bob prohaska  wrote:
>=20
>> On Tue, Sep 27, 2022 at 05:14:54PM -0700, Mark Millard wrote:
>>> On 2022-Sep-27, at 16:29, bob prohaska  wrote:
>>>=20
>>>> On Tue, Sep 27, 2022 at 03:27:10PM -0700, Mark Millard wrote:
>>>>> . . .
>>>> . . .
>>>> U-Boot> usb reset
>>>> resetting USB...
>>>> Bus usb@7e980000: dwc2_usb usb@7e980000: Can't get reset: -2
>>>> USB DWC2
>>>> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>>>>     scanning usb for storage devices... 1 Storage Device(s) found
>>>> U-Boot>=20
>>>>=20
>>>> Issuing
>>>> U-Boot> run bootcmd_usb0
>>>>=20
>>>> Device 0:=20
>>>>=20
>>>> [tens of seconds pause, looks like u-boot started over]
>>>>=20
>>>> U-Boot 2022.04 (Sep 27 2022 - 15:47:57 -0700)
>>> . . .
>>>=20
>>> Do you have RPi* firmware debug output ennabled such that
>>> you would see messages from it if the RPi* firmware started
>>> over?
>>>=20
>> I do now, enable_uart=3D1 is set in config.txt
>=20
> Good.

Beyond enable_uart=3D1 there is, quoting from:

https://github.com/raspberrypi/firmware/issues/1301

QUOTE
"uart_2ndstage=3D1" causes the second-stage loader (bootcode.bin, Pi 4 =
EEPROM) and the main firmware (start*.elf) to output diagnostic =
information to UART0. Output is likely to interfere with Bluetooth =
operation unless disabled ("dtoverlay=3Ddisable-bt") or switched to the =
other UART ("dtoverlay=3Dminiuart-bt"), and if the UART is accessed =
simultaneously to output from Linux then data loss could occur, so this =
is not a feature to activate except when trying to diagnose a loading =
problem.
END QUOTE

It is possible that this extra output might put
out messages about watchdog activity if such is
involved in the restarts.

For the current purposes, dtdebug=3D1 probably does
not provide anything of interest. But it is
available to enable as well.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 02:46:58 2022
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 4Mcgr72TRbz4VB7W
	for ; Wed, 28 Sep 2022 02:47:03 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
	(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 4Mcgr64Rzrz3cdY
	for ; Wed, 28 Sep 2022 02:47:02 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x532.google.com with SMTP id z2so15565020edi.1
        for ; Tue, 27 Sep 2022 19:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=OuvXJa0JvPUD0DBzoOB0r2UYvJqiVE0g5c+wdFC+a5I=;
        b=UOo3B1qWdArpcigdgVbvJehbBCtsjJU51mVrrNWoDQOQnCWcvNzh/Yc/QtuiV9sOkp
         R1ZhAElgM67chpyN+/eU2BzXU4SwSYNw9s5ud5YyPD+s8tWhauQuX5PguOlvGNoC7pYl
         5SCaBRQGXgSo5WbSFC6xWXmsh061wgO2v+Rl9bXDLMQICGStxoFsR/IGLwqSlbI2aGo5
         18z5ejQtxwI8IZE+6dMsMl/0bzYG9x0qGxwTVSfHAEXNzE4rqs9JxG7BaABb/SgRXt4z
         sITmYc12y8CxYZ972PtzaD5ZHMNaeQ7F6CARa++FcRuxOpxADAQ1okT1KEuLKh2rScvW
         LLxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=OuvXJa0JvPUD0DBzoOB0r2UYvJqiVE0g5c+wdFC+a5I=;
        b=hGLLBSaN2xDn42AcMGyb+yVynuILgj9/78SDoWI9ZKqGeD9TAI1IohgkqcMFjipeFv
         utvLvxfQj1f3v44Pbjmwetj/yEm0uw5chgMDAPXxcAO8+tHKh8rrnYsL5EaqGYs0UrP8
         do224EFV0P680QdEZvRoowaBQM3bGrwnv0HiykC0pxRWXUyY3UCq8380oPsff2VEcVKV
         QOEyE9h2rM1JvLAnYkA3eFUwC8Zdxd95zLH04f3vFFBeKr2rOlJzPNfaGlipcb7RcXPe
         A3mwhpo2xS4XraLDAsevo3Vian5aiRVuFSC1BhWVjQ84C0goa6VwTOW0QYTeRryKVRgl
         XUmg==
X-Gm-Message-State: ACrzQf1tOL7vBWU9bP3+h4OcHs23RHFGkJGhpsP0nRCh5Eiq2uAFqaYJ
	y4W6GPf9ZKNzePNDEjlyFM8=
X-Google-Smtp-Source: AMsMyM7dBnRP63/AQgl6woSVOwyiBei26jsoAFCofG8U1nnR6rYPTPVSRzL6ZYtF1RdzCz0d5CJ5Rg==
X-Received: by 2002:a05:6402:3552:b0:451:2037:639e with SMTP id f18-20020a056402355200b004512037639emr31675030edd.136.1664333220984;
        Tue, 27 Sep 2022 19:47:00 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id 5-20020a170906300500b0073d6093ac93sm1664132ejz.16.2022.09.27.19.46.59
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 19:47:00 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 04:46:58 +0200
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
 <304AC869-3B6F-4302-A206-73BA6B8E6B95@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <304AC869-3B6F-4302-A206-73BA6B8E6B95@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mcgr64Rzrz3cdY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=UOo3B1qW;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=maciphone2@googlemail.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.986];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 28.09.2022 um 03:32 schrieb Mark Millard :
>=20
> I got a sysutils/u-boot-rpi-arm64 build to work based on
> standard ports-style patching (otw files are not related
> but are present):
>=20
> # ls -C1 /usr/ports/sysutils/u-boot-rpi-arm64/files/*
> /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb.c
> /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__hub.c
> /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__storage.c
> /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h
> =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-lib_efi__loader_efi__cons=
ole.c
> /usr/ports/sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment
>=20
> The rpi_arm64_fragment is updated by adding lines for:
>=20
> CONFIG_LOG=3Dy
> CONFIG_LOG_MAX_LEVEL=3D7
> CONFIG_LOG_CONSOLE=3Dy
>=20
> The 3 patch-common_usb*.c files are patches adding the
> following 2 lines just before each #include 
>=20
> #define LOG_DEBUG
> #define DEBUG
>=20
> I've included attachments for the above 4 files.
>=20
> The patch-include_configs_rpi.h is my patch for allowing
> my media to work. This may well do Bob no good but is
> useful for me. I've not included it.
>=20
> patch-lib_efi__loader_efi__console.c is unchanged.
>=20
> I do have a different vintage of RPi* firmware in use
> than sysutils/rpi-firmware uses.
>=20
>=20
> The U-Boot part of the boot output looks like what
> follows. But I can not replicate Bob's problem so
> the output is just for reference. It gives a clue
> just how much output to expect.
>=20
>=20
> U-Boot 2022.04 (Sep 28 2022 - 00:42:50 +0000)
>=20
> DRAM:  size=3D30, ptr=3D8a0, limit=3D2000: 7ffe690
> size=3D8, ptr=3D8a8, limit=3D2000: 7ffe6c0
> 7.9 GiB
> bind node psci
>   - attempt to match compatible string 'arm,psci-0.2'
> No match for node 'psci'
> bind node system
> Device 'system' has no compatible string
> bind node axi
> Device 'axi' has no compatible string
> bind node aliases
> Device 'aliases' has no compatible string
> bind node chosen
> Device 'chosen' has no compatible string
> bind node reserved-memory
> Device 'reserved-memory' has no compatible string
> bind node thermal-zones
> Device 'thermal-zones' has no compatible string
> bind node soc
>   - attempt to match compatible string 'simple-bus'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
> bind node timer@7e003000
>   - attempt to match compatible string 'brcm,bcm2835-system-timer'
> No match for node 'timer@7e003000'
> bind node cprman@7e101000
>   - attempt to match compatible string 'brcm,bcm2711-cprman'
> No match for node 'cprman@7e101000'
> bind node mailbox@7e00b880
>   - attempt to match compatible string 'brcm,bcm2835-mbox'
> No match for node 'mailbox@7e00b880'
> bind node gpio@7e200000
>   - attempt to match compatible string 'brcm,bcm2711-gpio'
>   - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches =
'brcm,bcm2711-gpio'
> bind node serial@7e201000
>   - attempt to match compatible string 'arm,pl011'
>   - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011'
>   - seq=3D0
> bind node spi@7e204000
>   - attempt to match compatible string 'brcm,bcm2835-spi'
> No match for node 'spi@7e204000'
> bind node aux@7e215000
>   - attempt to match compatible string 'brcm,bcm2835-aux'
> No match for node 'aux@7e215000'
> bind node i2c@7e804000
>   - attempt to match compatible string 'brcm,bcm2711-i2c'
>   - attempt to match compatible string 'brcm,bcm2835-i2c'
> No match for node 'i2c@7e804000'
> bind node local_intc@40000000
>   - attempt to match compatible string 'brcm,bcm2836-l1-intc'
> No match for node 'local_intc@40000000'
> bind node interrupt-controller@40041000
>   - attempt to match compatible string 'arm,gic-400'
> No match for node 'interrupt-controller@40041000'
> bind node avs-monitor@7d5d2000
>   - attempt to match compatible string 'brcm,bcm2711-avs-monitor'
>   - attempt to match compatible string 'syscon'
>   - attempt to match compatible string 'simple-mfd'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
> bind node thermal
>   - attempt to match compatible string 'brcm,bcm2711-thermal'
> No match for node 'thermal'
> bind node dma@7e007000
>   - attempt to match compatible string 'brcm,bcm2835-dma'
> No match for node 'dma@7e007000'
> bind node watchdog@7e100000
>   - attempt to match compatible string 'brcm,bcm2835-pm'
>   - attempt to match compatible string 'brcm,bcm2835-pm-wdt'
> No match for node 'watchdog@7e100000'
> bind node rng@7e104000
>   - attempt to match compatible string 'brcm,bcm2711-rng200'
>   - found match at 'iproc_rng200-rng': 'brcm,bcm2711-rng200' matches =
'brcm,bcm2711-rng200'
> bind node firmware
>   - attempt to match compatible string 'raspberrypi,bcm2835-firmware'
>   - attempt to match compatible string 'simple-mfd'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
> bind node clocks
>   - attempt to match compatible string 'raspberrypi,firmware-clocks'
> No match for node 'clocks'
> bind node gpio
>   - attempt to match compatible string 'raspberrypi,firmware-gpio'
> No match for node 'gpio'
> bind node reset
>   - attempt to match compatible string 'raspberrypi,firmware-reset'
>   - found match at 'raspberrypi-reset': 'raspberrypi,firmware-reset' =
matches 'raspberrypi,firmware-reset'
> bind node power
>   - attempt to match compatible string 'raspberrypi,bcm2835-power'
> No match for node 'power'
> bind node mailbox@7e00b840
>   - attempt to match compatible string 'brcm,bcm2711-vchiq'
> No match for node 'mailbox@7e00b840'
> bind node mmc@7e300000
>   - attempt to match compatible string 'brcm,bcm2835-mmc'
>   - attempt to match compatible string 'brcm,bcm2835-sdhci'
>   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches =
'brcm,bcm2835-sdhci'
> bind node gpiomem
>   - attempt to match compatible string 'brcm,bcm2835-gpiomem'
> No match for node 'gpiomem'
> bind node fb
>   - attempt to match compatible string 'brcm,bcm2708-fb'
>   - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches =
'brcm,bcm2708-fb'
> bind node vcsm
>   - attempt to match compatible string 'raspberrypi,bcm2835-vcsm'
> No match for node 'vcsm'
> bind node clocks
> Device 'clocks' has no compatible string
> bind node phy
>   - attempt to match compatible string 'usb-nop-xceiv'
> No match for node 'phy'
> bind node clk-27M
>   - attempt to match compatible string 'fixed-clock'
> No match for node 'clk-27M'
> bind node clk-108M
>   - attempt to match compatible string 'fixed-clock'
> No match for node 'clk-108M'
> bind node emmc2bus
>   - attempt to match compatible string 'simple-bus'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
> bind node emmc2@7e340000
>   - attempt to match compatible string 'brcm,bcm2711-emmc2'
>   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches =
'brcm,bcm2711-emmc2'
>   - seq=3D0
> bind node arm-pmu
>   - attempt to match compatible string 'arm,cortex-a72-pmu'
>   - attempt to match compatible string 'arm,armv8-pmuv3'
> No match for node 'arm-pmu'
> bind node timer
>   - attempt to match compatible string 'arm,armv8-timer'
> No match for node 'timer'
> bind node cpus
> Device 'cpus' has no compatible string
> bind node scb
>   - attempt to match compatible string 'simple-bus'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
> bind node pcie@7d500000
>   - attempt to match compatible string 'brcm,bcm2711-pcie'
>   - found match at 'pcie_brcm': 'brcm,bcm2711-pcie' matches =
'brcm,bcm2711-pcie'
>   - seq=3D0
> bind node pci@1,0
> Device 'pci@1,0' has no compatible string
> bind node ethernet@7d580000
>   - attempt to match compatible string 'brcm,bcm2711-genet-v5'
>   - found match at 'eth_bcmgenet': 'brcm,genet-v5' matches =
'brcm,bcm2711-genet-v5'
>   - seq=3D0
> bind node dma@7e007b00
>   - attempt to match compatible string 'brcm,bcm2711-dma'
> No match for node 'dma@7e007b00'
> bind node hevc-decoder@7eb00000
>   - attempt to match compatible string =
'raspberrypi,rpivid-hevc-decoder'
> No match for node 'hevc-decoder@7eb00000'
> bind node rpivid-local-intc@7eb10000
>   - attempt to match compatible string 'raspberrypi,rpivid-local-intc'
> No match for node 'rpivid-local-intc@7eb10000'
> bind node h264-decoder@7eb20000
>   - attempt to match compatible string =
'raspberrypi,rpivid-h264-decoder'
> No match for node 'h264-decoder@7eb20000'
> bind node vp9-decoder@7eb30000
>   - attempt to match compatible string =
'raspberrypi,rpivid-vp9-decoder'
> No match for node 'vp9-decoder@7eb30000'
> bind node leds
>   - attempt to match compatible string 'gpio-leds'
> No match for node 'leds'
> bind node memory@0
> Device 'memory@0' has no compatible string
> bind node sd_io_1v8_reg
>   - attempt to match compatible string 'regulator-gpio'
> No match for node 'sd_io_1v8_reg'
> bind node sd_vcc_reg
>   - attempt to match compatible string 'regulator-fixed'
> No match for node 'sd_vcc_reg'
> bind node __overrides__
> Device '__overrides__' has no compatible string
> bind node fixedregulator_3v3
>   - attempt to match compatible string 'regulator-fixed'
> No match for node 'fixedregulator_3v3'
> bind node fixedregulator_5v0
>   - attempt to match compatible string 'regulator-fixed'
> No match for node 'fixedregulator_5v0'
> bind node v3dbus
>   - attempt to match compatible string 'simple-bus'
>   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
> bind node __symbols__
> Device '__symbols__' has no compatible string
> bind node bootloader
> Device 'bootloader' has no compatible string
> bind node clk-osc
>   - attempt to match compatible string 'fixed-clock'
> No match for node 'clk-osc'
> bind node clk-usb
>   - attempt to match compatible string 'fixed-clock'
> No match for node 'clk-usb'
> RPI 4 Model B (0xd03114)
> 0
>   - 0 'serial@7e201000'
>   - found
> 0
>   - 0 'gpio@7e200000'
>   - found
> 0
>   - 0 'gpio@7e200000'
>   - found
> bcm283x_pinctrl gpio@7e200000: set_state_simple op missing
> simple_bus soc: set_state_simple op missing
> 0
>   - 0 'gpio@7e200000'
>   - found
> pinconfig uart0_pins: set_state_simple op missing
> serial_pl01x serial@7e201000: pinctrl_select_state_full: =
pinctrl_config_one: err=3D-22
> Core:  198 devices, 13 uclasses, devicetree: board
> MMC:   0
>   - 3 'mmc@7e300000'
>   - 0 'emmc2@7e340000'
>   - found
> 0
>   - 0 'gpio@7e200000'
>   - found
> simple_bus emmc2bus: set_state_simple op missing
> 0
>   - 0 'gpio@7e200000'
>   - found
> sdhci-bcm2835 emmc2@7e340000: set_state_simple op missing
> 1
>   - 3 'mmc@7e300000'
>   - 0 'emmc2@7e340000'
>   - not found
> 0
>   - 0 'gpio@7e200000'
>   - found
> pinconfig mmc_pins: set_state_simple op missing
> mmc@7e300000: 3, emmc2@7e340000: 0
> Loading Environment from FAT... 0
>   - 0 'fb'
>   - found
> 0
>   - 0 'gpio@7e200000'
>   - found
> bcm2835_video fb: set_state_simple op missing
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> 0
>   - 0 'ethernet@7d580000'
>   - found
> Net:   0
>   - 0 'gpio@7e200000'
>   - found
> simple_bus scb: set_state_simple op missing
> 0
>   - 0 'gpio@7e200000'
>   - found
> eth_bcmgenet ethernet@7d580000: set_state_simple op missing
> eth0: ethernet@7d580000
> 0
>   - 0 'gpio@7e200000'
>   - found
> pcie_brcm pcie@7d500000: set_state_simple op missing
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> bind node usb@1,0
> Device 'usb@1,0' has no compatible string
> 0
>   - 0 'gpio@7e200000'
>   - found
> pci_bridge_drv pci_0:0.0: set_state_simple op missing
> starting USB...
> Bus xhci_pci: 0
>   - 0 'gpio@7e200000'
>   - found
> xhci_pci xhci_pci: set_state_simple op missing
> Looking for reset
> Looking for reset
>   - result for reset: reset (ret=3D0)
>   - result for reset: reset (ret=3D0)
> 0
>   - 0 'gpio@7e200000'
>   - found
> simple_bus firmware: set_state_simple op missing
> 0
>   - 0 'gpio@7e200000'
>   - found
> raspberrypi-reset reset: set_state_simple op missing
> Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 0
>   - 0 'gpio@7e200000'
>   - found
> usb_hub usb_hub: set_state_simple op missing
> 4 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  2 1 0=20
> Card did not respond to voltage select! : -110
> MMC Device 1 not found
> no mmc device at slot 1
> MMC Device 2 not found
> no mmc device at slot 2
>=20
> Device 0: Vendor: Samsung  Rev: 0    Prod: PSSD T7 Touch  =20
>            Type: Hard Disk
>            Capacity: 1907729.0 MB =3D 1863.0 GB (3907029168 x 512)
> ... is now current device
> Scanning usb 0:1...
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> 8Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Card did not respond to voltage select! : -110
> Scanning disk emmc2@7e340000.blk...
> Disk emmc2@7e340000.blk not ready
> Scanning disk usb_mass_storage.lun0...
> unhandled device class: xhci_pci (usb)
> unhandled device class: pci_0:0.0 (pci)
> unhandled device class: pcie@7d500000 (pci)
> <2, 0, 1024>
> Unrecognized filesystem type
> <2, 0, 1024>
> Unrecognized filesystem type
> <2, 0, 1024>
> Unrecognized filesystem type
> <2, 0, 1024>
> Unrecognized filesystem type
> <2, 0, 1024>
> Unrecognized filesystem type
> Found 7 disks
> 0
>   - 0 'gpio@7e200000'
>   - found
> iproc_rng200-rng rng@7e104000: set_state_simple op missing
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> ** Unable to read file ubootefi.var **
> Failed to load EFI variables
> Initializing EFI driver framework
> Adding EFI driver 'EFI block driver'
> 0
>   - 0 'ethernet@7d580000'
>   - found
> smbios_version =3D 0000000039c2403f: '2022.04'
> BootOrder not defined
> EFI boot manager: Cannot load any image
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D163), clust_size=3D32, read_size=3D32
> FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
> Found EFI removable media binary efi/boot/bootaa64.efi
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D163), clust_size=3D32, read_size=3D32
> FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
> FAT read(sect=3D131), clust_size=3D32, read_size=3D32
> FAT read(sect=3D163), clust_size=3D32, read_size=3D32
> FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
> dev=3Dusb, devnr=3D0:1, path=3Defi/boot/bootaa64.efi, =
buffer=3D0000000000080000, size=3Dd18dc
> unhandled device class: xhci_pci (usb)
> unhandled device class: pci_0:0.0 (pci)
> unhandled device class: pcie@7d500000 (pci)
> unhandled device class: xhci_pci (usb)
> unhandled device class: pci_0:0.0 (pci)
> unhandled device class: pcie@7d500000 (pci)
> - recorded device =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x3)=
/UsbClass(0x4e8,0x4001,0x0,0x0,0x0)/HD(1,GPT,9cdadf2a-de3c-11ec-8f37-a0cec=
8d68fdc,0x800,0x82000)
> - and image /efi\boot\bootaa64.efi
> 858332 bytes read in 31 ms (26.4 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Loaded from disk
> Booting /efi\boot\bootaa64.efi
>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> =
=



If you later want to change from 2022.04 to master stream, you can e.g. =
change the content of the .xz file which unpacks the sources =E2=80=A6.

` Happy to see you both are on the right way !   I think I can now leave =
the discussion. ;-)

Regards

Klaus







From nobody Wed Sep 28 02:52:33 2022
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 4Mcgyb4kG7z4VBkm
	for ; Wed, 28 Sep 2022 02:52:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4McgyZ3hg7z3dC0
	for ; Wed, 28 Sep 2022 02:52:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664333557; bh=EyLLmMEtHqt3kgrf3bMLxT5KEYkw+arjjl6ZqlVaqoM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=c8/KmiF6Ta2O4SOcGMjwXgjPFiTfFYYuElnmWgdHIzM+68Su+1b5+srdyQZO6nhOz8NM7xU3PVT0IYh8VjZcoGEAXz7GV0bm1RWftuczq+gNqADUd9dlwwR+K13Mic7/Vg3jBqYrkHP2DnUi8Z6VBrKAw0XlBMbMyGlj0KF/gWqnyY40XacBZYujtdfAmIgCSY+n9KiwO7+TwqIlxIGNBgfXAc+lk8TjzbgovjNJRekaDIgoXJgaoExyAMXNNyJqdTxnscA1bD+b1GEdxOUjTsi1CeMkrI86ABaarUqlJTOF6YuOiFjTPkISlrjD3UgKvhFFvzLojR3GpOCaDMtDhA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664333557; bh=MdNpGOnm2dKJSMXueQOCYSk6pZBE+UdO3XB4WtxuDJP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VRqDHuG4oJ0HoCTWIRmgCoiee47Al+moVCvu9H36WMLR9Oq6y0+cE62yzFWG+t1Aw6Svr1ahbe+RwPeJgUDnCOAJxGLBmX1e82ZXdOXNbvIMe/8XWPY0ubg3VNp6o0m0wufkFSF9x2xfQa7Qks5FS9+9IweC26Lft6oHCC9gRhYvkHrdcPnZz9sL1FjsYC5B/3CpTcgcUyMQTAtNuwVwb0JNXLxobp1BESu1Z+TUY5n25DiMs2Ect/U3r7JLu9jJ2dkPuW7sS8irH4LIoLj+ehYMqgcWfh95c10Gifm7J1rMG1+PAgs5VYmRR+bSi8vrGU7uJ5EAI3k4je9YnuvXaw==
X-YMail-OSG: o5YZ.c8VM1k5aIg5v.FtaFlK88sCmyb3H_7433dcoU7wN2rXwRZLVZWnr.sKLJK
 lXxXkiSU7NDomG57.QMr33jVsxUjFG4BxGRgIC0IOmwj1mWqJHND4Zk8S5ZbulEvbY315_xuFxqw
 HWCEseskKoSQoDurWg_UR7VCUfXJ5otXhd4DoITnc2sNn2FxpVld2D4PZiAftkL2k7EF0QD1yk84
 z3gHuNbqzLs4eLJbwXyShRQFGhBePDtKoQlgmYFMXqFt88QU6lrG.ooqA1Pqw5jv.cZ61wQWEYOU
 G5SRNed7uFZKTgZ3WmXh9J59z3xImTkgrrUcRRe9pI4bwQyJpbNQKep6O5.WXtiIEjhvvA0.587q
 n00J_hIs5c5gZwFzIak7mdODrzbg0c4mGEt8SGDUtlJmMHV9bwgzATKFZh_3v6wLX0Q3LyBwE9BE
 WK1VpLlx1pIumWPaHYNLXGOV.LTOrdNpbRCjBA7LZUbZyFDgq5gIOlwK7MO8yPGkycmAOqwiA3oQ
 JiNYgX8duLkGuqcYklo4yThSyQ8lOZO4a97zJZJ5Woza1GjbUmVy1RLZJAHGxBTUoD_X4RK2SDln
 4Z2FD8klWZfiMn6GG7mMFI53nLTyHc4jv1ZpVKcouaL2JGtZ2U2qzI7qxIlmBwaRQrhdM6PsGNiX
 HsMN.a_Mv2AAjCvR34JUunjH9McC.JlVILMJjzYIIKteTZUavtAMGBQamvn4LINqDNtoaSm0DSo4
 _JWYx6ZH13T2i9KPaZrBuimSf0DO9jEg16y_3Zpj98PxZSaWD_6HPwLi_acQ2MgduoagzqCA7TMy
 KKXUW7Nw53rdFlmCI3qzLmFReNu4CPqko7WaGlXyUZDPSWiffk6KFmvs4yn2dKv5BBYUfNNgmn0_
 ElMtvSkCQ.uZfSdXQsWZv8IbcCVwcjDWECjX.u9UnshofRuB2X.2r3FNmftD8lOvKKAFaVCNn334
 ArAQEgYX3hP975Diz9hk0yaE0YXpRdPWBYKp3t9m76xhEXrerDExuC83YJNL3Anv4XdsUv5N7NbU
 vxsOZRdutjApzX8eLZyr2CIGg5u85vY.4MUJ_z8R3f.kWQYRy9zkJOAZVuSIO1xvBB7fFp6L3xXi
 i5kft0KTF4mNMQSLgoXqoP5JiJvEcXV.AHhaoF99AtzMhPvCZhnOd_EPgdl2olJsQtvT2_9uKmVs
 EKtmf63Rt4Xz8rnfVXbJkOT3b0FrQlUVQe4iAMnS6U.Smf.mEowS3OpPT7Q4Z6bYhFlLfVcn5EW8
 7RwYGdIRyxNYuecRX_4e4GR5g6G9R4wvejclPMH5A6dpwi5sA5F3mll_vy6gywKMnRlh3qtrcXmr
 ni8Iq93ulFuxNqKmJ2J.Nhwu8olJpekU0u9iVLHLVMRZh4y1NoLrJQqhnEiAe4HfFp5RLWT1pgC1
 utZpzQdvaj8Gop4dZQQUc2fvX2J5qU8D9B8sqG8AliPzq4Wv4lxDibmyunZ1toIkLO9wf08Al8_v
 4I3_m5MbYvJ9RkNd.I_n.cgs6V2VRUtZjX_r2HW5lombLixQqhC_2rexp5l71YWuMcKLXNqNEIdc
 bToHSm6uAciWNIAzAbxlWP5NAZwqajjexAXi4GHoWVB28JcV0uA0m89ml62u0JJj0rJpj1gozNUW
 wjDJeylt6xywRpYSvufccB4omoqKqVNMzyCnBo7NGv9gVL385vQPXmRbpEh5n7tja_zWNPBAB4bs
 IwLu.cBS5qqha3j.6H6itzdkOEq79VIItT_TPZTRZnbCgXafBEQhcYAyuq7o1FWGXnaBg_4MrQxw
 Fa7k9hi0BEbpHuDEUOcKcFDdN6_jvmGjgqmVkH0LmfSqFMtGN8dnY5YOS5ghrpgStIHUL7Mf4qrq
 w3jbdnkVpzToECrOgCZV0zo1MIXyC1JS08ph1fPIWWr37QGcZohncyLIzKHZSaR_iBQ8Qe7x.nem
 wbI5EYt.p_TwRDtzleSG1IBZ0NhBy_sDAG7wR24RMDf5XxLdFUFhU1zqMKBx8K2Gl1TfOgAD6Cnb
 8eV3m6Iy0R5AoZAXjjIYb4Vsq5RLGJuCOdPIFzNl26LtIx.oX0.ZeYjIw74psqEgbQFkkAHAjX9k
 6jeE3u.bdgrtEMSpw0pwHDy4LCNp.1PqUGxr7JNlzvIpq2pHXW1zW9f0Cqrb.VfN38kpmRfM7ZzQ
 aY3l3Le2YImXy4RkB84uCDxLd.qpypbRkiVhG0weC3ebJU9xFRtYaTuEvTxIuCq9pkNXbHmbzhib
 SpkX7r62guFUZmJ_zkMOCKX41pKHUdMjSbA0Nm.kUXcNMnNOQiH0MJOlwhmLwqETr7cKJm1SQiQl
 b0MOC8ciH
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 02:52:37 +0000
Received: by hermes--production-gq1-7dfd88c84d-bd6qh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12c6806902f56b47b4f2ae195f78fe3c;
          Wed, 28 Sep 2022 02:52:34 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Tue, 27 Sep 2022 19:52:33 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
 <304AC869-3B6F-4302-A206-73BA6B8E6B95@yahoo.com>
 
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McgyZ3hg7z3dC0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="c8/KmiF6";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.987];
	NEURAL_HAM_SHORT(-0.93)[-0.933];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 19:46, Klaus K=C3=BCchemann =
 wrote:

> If you later want to change from 2022.04 to master stream, you can =
e.g. change the content of the .xz file which unpacks the sources =E2=80=A6=
.
>=20
> ` Happy to see you both are on the right way !   I think I can now =
leave the discussion. ;-)

Thanks for pointing us at usb.c and the like.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 02:59:41 2022
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 4Mch6m5DgZz4VCSF
	for ; Wed, 28 Sep 2022 02:59:44 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4Mch6m08bnz3dl8
	for ; Wed, 28 Sep 2022 02:59:44 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x629.google.com with SMTP id lc7so24489082ejb.0
        for ; Tue, 27 Sep 2022 19:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=mtzyYiemsvTprPCc4lUa2yiC+nrfC6fw6G4KCN9cqNE=;
        b=low4aipjaoD26r7JfzMncfUxzlxPWs06duxEuzsRb1ehebwl4a9Hz8v59tPGuEWgkC
         I6jpMEys87YP8KruPyeKKkGkRO8Hf8bwVmp1Hcl/2nt56Jodz/7bP2xp54ubsHN2xGi3
         3f/VY2j4IG0P7hHIAgXxq23rYYJ7JcOz4hDrmp/x+47+p+0eegsE7KhhW5U69WkqjZ7w
         80h4ZgqqIa7lunz0temVkyIAPV6MfqL84qasbHJURGR1ZrMQz0S+Pyy65i3cRiQc7dD8
         WzEp1fW9YRHIyFBkQBM5baWwfHYomvP11wUmAnhx5M8KSQUH3D7mvzdlvDqEoYK5t/8s
         QoLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=mtzyYiemsvTprPCc4lUa2yiC+nrfC6fw6G4KCN9cqNE=;
        b=0ChszxXKHcdJpitIVTdtNw9DQUx7BPi0S6Z9Y+0t5fqbTczjo2CM0DeWQN8IlULVLw
         jxIUVgSysWRz2nCCkM6LK3Sv0t3mIrTDAU5Mv3DNnmVg5H6aBvsBQ+F2DB73goHFpGiB
         wlbXgAMaJEdL8VxRrpGYTQYDuSNTX3XI/zpC4+tXCSvm50NxQ0xJkL80qMHQoGZjo86v
         +2aVXSSdn4OR6dYrIlCVoj0+2gUowAJO5m8RJeyUt3r4wpfLXHx29loW0KmThh5WeQ/k
         3LLELWr/U7Dmot4vwRH/Z3gCVA5OTL7QDN3e+H73kQIHj4Rjc1axWLcAXqfXwMahBReI
         Kvxg==
X-Gm-Message-State: ACrzQf0IqQwvJGVPuKTXATDYF0/1PNPkdtrZoBi6fvaGdN13X9riqU66
	8yLPP5GpoZmVpcLfiJvFnBE=
X-Google-Smtp-Source: AMsMyM7aZlkF1GccQEXVnt/Od0eElLu4CP7e5TROUefbHg0WCw3vnibMDFh5KxMn+env7EWXlr9Aqg==
X-Received: by 2002:a17:907:16a4:b0:783:a3b4:2cf6 with SMTP id hc36-20020a17090716a400b00783a3b42cf6mr10395451ejc.620.1664333982732;
        Tue, 27 Sep 2022 19:59:42 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-185-233.46.114.pool.telefonica.de. [46.114.185.233])
        by smtp.googlemail.com with ESMTPSA id la5-20020a170907780500b00781dbdb292asm1620224ejc.155.2022.09.27.19.59.41
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 27 Sep 2022 19:59:42 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 04:59:41 +0200
References: <3D6CF13E-261D-41D2-AC5B-923C0BF54087@yahoo.com>
 <20220927160328.GA71742@www.zefox.net>
 <67C09E9F-AD1D-4D0D-9E6F-9C1B046D8952@googlemail.com>
 <4154AFCB-7428-4005-843A-4EF8C0EBCCB8@googlemail.com>
 
 <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <1199E8C4-81E4-43F4-82BD-EE98C8CAC83E@yahoo.com>
 <304AC869-3B6F-4302-A206-73BA6B8E6B95@yahoo.com>
 
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mch6m08bnz3dl8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=low4aipj;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.41 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.91)[-0.912];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 28.09.2022 um 04:52 schrieb Mark Millard :
>=20
> On 2022-Sep-27, at 19:46, Klaus K=C3=BCchemann =
 wrote:
>=20
>> If you later want to change from 2022.04 to master stream, you can =
e.g. change the content of the .xz file which unpacks the sources =E2=80=A6=
.
>>=20
>> ` Happy to see you both are on the right way !   I think I can now =
leave the discussion. ;-)
>=20
> Thanks for pointing us at usb.c and the like.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20

Always brings fun and success to work with you, thanks for that as well.

Regards

Klaus


From nobody Wed Sep 28 04:51:45 2022
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 4Mckc01gjVz4YNvg
	for ; Wed, 28 Sep 2022 04:51:44 +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 4Mckbz2SDMz3kwr
	for ; Wed, 28 Sep 2022 04:51:43 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28S4pkP7074027
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 27 Sep 2022 21:51:46 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28S4pkUe074026;
	Tue, 27 Sep 2022 21:51:46 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 27 Sep 2022 21:51:45 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220928045145.GB73356@www.zefox.net>
References: <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
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: 4Mckbz2SDMz3kwr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 27, 2022 at 07:25:09PM -0700, Mark Millard wrote:
> 
> Beyond enable_uart=1 there is, quoting from:
[snip] 
> "uart_2ndstage=1" 
Also added to config.txt

> 
> For the current purposes, dtdebug=1 probably does
> not provide anything of interest. But it is
> available to enable as well.

Added to config.txt as well. 

In general there isn't much additional output from u-boot. 
On a successful try I see what begins as (I think) bootcode.bin output:
.....
MESS:00:00:24.909927:0: Device tree loaded to 0x4000 (size 0x7374)
MESS:00:00:24.918100:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:24.924351:0: uart: Baud rate change done...
MESS:00:00:24.927765:0: uart: Baud rate change done...

Next u-boot takes over

U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: Vendor: SABRENT  Rev: 1214 Prod: 
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
Scanning disk mmc@7e300000.blk...
Disk mmc@7e300000.blk not ready
Scanning disk usb_mass_storage.lun0...
Found 3 disks
Missing RNG device for EFI_RNG_PROTOCOL
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
Found EFI removable media binary efi/boot/bootaa64.efi
1262604 bytes read in 38 ms (31.7 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Booting /efi\boot\bootaa64.efi

But, that's it. Is that what one would expect? 

Failed attempts are more terse:

U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: unknown device
Waiting for Ethernet connection... done. 

I imagined u-boot would be more talkative,
similar to the MESS..... output from bootcode.bin

The output from make reports
===>  Applying extra patch patches for u-boot-rpi-arm64-2022.04_1 from /usr/ports/sysutils/u-boot-rpi-arm64/files/
No such line 209 in input file, ignoring

Strangely, it doesn't report which patch didn't work.
The directory contains
patch-common_usb.c        patch-common_usb__storage.c  patch-lib_efi__loader_efi__console.c
patch-common_usb__hub.c   patch-include_configs_rpi.h  rpi_arm64_fragment

No idea whether it matters. 
 
Thanks for reading,

bob prohaska


From nobody Wed Sep 28 05:45:36 2022
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 4MclpJ1QrPz4cj1k
	for ; Wed, 28 Sep 2022 05:45:44 +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 4MclpG59rBz3qs4
	for ; Wed, 28 Sep 2022 05:45:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664343940; bh=GBpYMA0N/Xg8ZoKHH+PFmkhFeYfh3O0bvuUt/YXbPUA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jSeOpds+07lZbuC5pXbT5qeX97WNzk8YUC7uyIFgbEklgyQk/22EjQPhvprUXQcl7PIzQJGdg5EsOK7ayExYIHTmHHlATwDjcJ4PnQ+jD6h3RRB8LBI67pSYYQMHU10xDan8G/T6SZ1LQM475TqYs6X3oNafBnUymyrDK/u7ZyjIl6z8CxwrdKoz90qyp3KepT5tkZHrAWo+aCI/MAbZhPI6sCvpbaH9R7ko1juCC8gPQHbOECOmnlH7m9n56h13YNQy8qX7E8gFADDPXPTKfDRjgqbyjVlkUKlvUNE744PjjYDC49cV7qBf5bwHjm6E2Oxtwy/MYMSZqUp+itWoyw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664343940; bh=ssy/IIN/OH4Enj+ErJRXVO+EKDK90wPptmlWTXmx+F3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NAqcebvmIMDYzNh5t1CrIOltGMJRuC/FLzJCD4w1rSALr0ijVn2Cfou6kG45VKFxlZaR0avKBP9Xb3SImaEs/YojoOTMW6i3ebyHgmDRP5e9coIah4Re6suqByUQTnMo3zUH1JEgXCem1SlH43dr48cOxsUv0ytN2IB7PERfvcFD8g0Q9WdoBqYBmtlNXdcczd5dOmYhH9DM6mirwOk67VzWgTek21FYDcZyaDD1UfAjI7zWR2IfN0H9Zj65Vcss+n8R/ZCIJA5x3T518vHtHS1yGCZyvXNDwgz5clZsT+YVZkRUqGcqiSAmHm90oBDE2abUL/oN03s9TAferBOHCw==
X-YMail-OSG: _sriJxoVM1kMeUK.oHxkOgRAX5nsSxKm2vqxVkeGj7Q6cZR6AD3wcfJioVKbIiK
 xxnVKvTuaEE9bkMpRAa29ao75ARernqoHjMt.H3Zeh2y51x8YxeH5i8yYIZ0KrU4MiQH6eDcAtAn
 TqU9TFThCuZIP.c1rNy1FC7IS0Yet736OcHMWPpToTGOja36jb5bLPlwf7LSkUbGjl3xtkM9CiMH
 m8kUzR.VWNkQC_jZOtr26rs1L8so918ki225WkFia5U5U1Knb4cYkW45DkkU7xaMyofloAzX1N3_
 aB5HMMGxOyYAfiaykUqX3EqYYzbVIoRuIJ7s0344xgA_KWqBV08q8Hw_kONU_O.lHfMQRDWQPIUs
 CSn41FuBO9ebXQ2xRX4GY7YtH2.I..Ji4JN08kpqFo9OVCAUS1XjMsouP.O9lsIkjv7S.ZvdGosn
 1oza4LjAbLaM23fl82wfNJaIIDjD5SiutQoYmpQWJi8GdZg.1PIsB0YDhSzTsoX7Z_UVl3mFcg.0
 7bCc2HOHGAdpZC3zpLYW5ErR23HWDRsE2X5z6NnzPfxaq9EUXpR67qr9OIsWj65NLpMCxTHWWcV3
 VbjpkqCtnfF4J1REmt81HfgJ.E9804fK7SVPTB_oLrPI_VJXhJ_DWH8J.MQbCkKXerKFCDPukHDS
 pDQEdUW7fi8CiylqCUsmerBVLEw5BkKdymDUIghyJig1gLd3SmxljaMoxjvW3e4R09dBF9S2GT7D
 fB0TMEDrY0aOcQYpjMSLJk3DsgmAD4ihdqulU27Z2eomHqarswQaBeN9I._5SjZWu.G1Ku7j3E2p
 JeoUogNw.WvWG8JSZds_hFUxYo7aeUdifmGcZMcaFX7HjvR.MFmJ_XucuDsceL4u9465DQDGqYgM
 4XYVAIfKPtLlMdooL43d_g2AJJ8vIQFRe_FL5tguCT.9_zsOitMEr5awXauhCRWCCpjllv_dzjWp
 riOLa_Q6F_RTolzL7QflxdNBsbbUEoFfqsNtgxrPI8Uib1NYELyOoox6Av_c78TvH5ZrHSqTY_cL
 WJwOpJMGPV_ety8BWV26W423uUiix98e6ovIoe30CnBjd9lrD6NBraaToRjLgJOG.EH8dlOKzJE0
 kR2HK4KmeS3HYu52BcLNhPchl__fknCgPLcBVpkNb13di2sWFTtbIhasQibSn4jLFDHixjAstrSl
 l2nOfqSKdaDQKrpnfLeFBXUX9re0eUaQp9WgzBEEOO4R_E1g5xAx0LUv1a.u51KWXhSzpJf_fe1S
 imEQ6R1OQadDH4PW3hZfOTJfY3bIUfNiPtfK4A55e3UfhRDItbu5kUvOGuNKiyyWwOM8xcVtczL8
 qRFYgOAsJ02.GRFqeOHGu3gpWKG1UN1RthaQtChC17ob6_fV4A9bJQlDNRScYurH5IAZYvJVy4Yf
 1G7pdFuGZwYzGoN802SAeEnMvpvSX3ZA8MF5VqwtiJabADID8D0COg1mXet6BbY4rFIYQscvpO4P
 dEGuq9N4FRhfDSEIePwuyFN5hX29kVtvTrZtUy_XyFh_ausfPf5zKh1gKhPN0KzI2leLh2VfdrSv
 86.jZOaLvgp4tZj45V8g3ejvw83JEWTQcsPAokPXcdaZOuDFqHzgtcuC_cD1HZcX7dcKMQWGzDoX
 SZNENSxh.tEV2FGAh2CkMYxYlVbDsQ_Xn5VXP0T_LIU.p6_VSx9iNg6QDMRRpw622f0RqspYYjXZ
 WrQt7U_3HPeZ4c2M3UNJ1BRJfDTxolRraqx_.LVHleEKeEuIq9sDpNHahHjSecXuJaMEuY87jieP
 WZdypifMge4NQk_EefTg0b8Nin6y2E7ul7DICoGCcYvr.FW74UtOYa8zggGDbF_8uSsXgOPVQJQU
 9x9APMspDUaqbDYkjl2cSEzAl_lxvOWG9CXnEIREoXxRvDQdiOy5XankS74i.u7x.FKfNHQcqNgw
 DSWFqYEmXNjx8OVqb54Ah67e0CfgDms1issKYTZy.PvUDmBVMraebho8ijq4CpAncb9PjrrmpltP
 W9IzvmmXXOI6sxlvI16bngZ2Fm0m5fxDwaq7HrjDQabv5XMWXwrI3h.h3JQdT0XqwYHYfEBGU0Oo
 45Uh2szj7oNSq310ENsF1tNOklxuACfwPvHUH.TesAbCgu7x.TWm_M_fTCVFDUd9T5.b23bKWFmv
 QZ_WFzOXr.vteGMlgfjCqh8HArIuVXg3nJ4t2FfEj6fgzhhSj9Wm8Yy3dGbvmsR3Y4W8KWfE0hzj
 z4zwDOSaNoVs.gN8yiiAYRiDYEK_QUKun64Lg0XvtTArWWqZ8pSji7m6dX7df.e8PPr0wh3fXK37
 SdK9zT33sOjE-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 05:45:40 +0000
Received: by hermes--production-ne1-6dd4f99767-hqzzl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c282ad7f9489dd1a9b80af8dbb7f2742;
          Wed, 28 Sep 2022 05:45:38 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220928045145.GB73356@www.zefox.net>
Date: Tue, 27 Sep 2022 22:45:36 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
References: <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MclpG59rBz3qs4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jSeOpds+;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	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.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.69.84:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-27, at 21:51, bob prohaska  wrote:

> On Tue, Sep 27, 2022 at 07:25:09PM -0700, Mark Millard wrote:
>>=20
>> Beyond enable_uart=3D1 there is, quoting from:
> [snip]=20
>> "uart_2ndstage=3D1"=20
> Also added to config.txt
>=20
>>=20
>> For the current purposes, dtdebug=3D1 probably does
>> not provide anything of interest. But it is
>> available to enable as well.
>=20
> Added to config.txt as well.=20
>=20
> In general there isn't much additional output from u-boot.=20
> On a successful try I see what begins as (I think) bootcode.bin =
output:
> .....
> MESS:00:00:24.909927:0: Device tree loaded to 0x4000 (size 0x7374)
> MESS:00:00:24.918100:0: uart: Set PL011 baud rate to 103448.300000 Hz
> MESS:00:00:24.924351:0: uart: Baud rate change done...
> MESS:00:00:24.927765:0: uart: Baud rate change done...
>=20
> Next u-boot takes over
>=20
> U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)

There are almost 2 hours between 20:04:31 -0700
and the 21:51 when your Email arrived.

None of the output that I reported as showing up
shows in your report. YOu can look at:

=
https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html

to see the U-Boot output that I got (via use in
an RPi4B).

Are you sure that the u-boot.bin on the msdosfs
has the new content?

> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
>=20
> Device 0: Vendor: SABRENT  Rev: 1214 Prod:=20
>            Type: Hard Disk
>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning usb 0:1...
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Card did not respond to voltage select! : -110
> Scanning disk mmc@7e300000.blk...
> Disk mmc@7e300000.blk not ready
> Scanning disk usb_mass_storage.lun0...
> Found 3 disks
> Missing RNG device for EFI_RNG_PROTOCOL
> No EFI system partition
> BootOrder not defined
> EFI boot manager: Cannot load any image
> Found EFI removable media binary efi/boot/bootaa64.efi
> 1262604 bytes read in 38 ms (31.7 MiB/s)
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Booting /efi\boot\bootaa64.efi
>=20
> But, that's it. Is that what one would expect?=20

No.

> Failed attempts are more terse:
>=20
> U-Boot 2022.04 (Sep 27 2022 - 20:04:31 -0700)
>=20
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
>=20
> Device 0: unknown device
> Waiting for Ethernet connection... done.=20
>=20
> I imagined u-boot would be more talkative,
> similar to the MESS..... output from bootcode.bin

Look at:

=
https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html

for some of what to expect.

> The output from make reports
> =3D=3D=3D>  Applying extra patch patches for =
u-boot-rpi-arm64-2022.04_1 from =
/usr/ports/sysutils/u-boot-rpi-arm64/files/
> No such line 209 in input file, ignoring

That is the same 209 reference from patch-include_configs_rpi.h
use that we exchanged about before. patch deals with finding the
match at the new line number (that as sufficiently close to the
original line number): there is no line 209 or 210 and the
matching text is at a smaller line number.

> Strangely, it doesn't report which patch didn't work.
> The directory contains
> patch-common_usb.c        patch-common_usb__storage.c  =
patch-lib_efi__loader_efi__console.c
> patch-common_usb__hub.c   patch-include_configs_rpi.h  =
rpi_arm64_fragment
>=20
> No idea whether it matters.=20
>=20

By itself, it is just an informational message and
is expected.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 06:55:42 2022
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 4McnMC0zz2z4crGY
	for ; Wed, 28 Sep 2022 06:55:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4McnMB0D0kz3v1b
	for ; Wed, 28 Sep 2022 06:55:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664348147; bh=3ar0v8tKuttLv9cL0sJ2GrRdbFDHabd2UMnJ82o4nvQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Tx9om8YuMP1VkOHN34/PBdTNXaX6OOukTEcs/LQy2ijNHeLLGXvPaRIb5RGz8Kk7+BP9/0OJ7f60Mb9h3NoTcz26oZYj4kD+sfcpYgXl9ZHb604HFDuMpncUCvaHSmUsL4zOOiY0y4LpnKADRUrFLomzFY8cvC+kUZt/Ko0j8T+H99EMSLyiOdJ+6NV/VJI4Qbk0JdIPFVGGy3GXPI6R7zSA508pkI1am3WwXKEy9vc+u0sygiCqsjmWlDue83H9vQVIYzosZ38ZRX74pU95inlNYyiGC5N3l9gAmJPmVjdQvCVhognqo+vE7Fu4MVfwlFD4xDqp4NB3ae6nSfsrlQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664348147; bh=CDc8YlVLH0g6kRFPsyt9T7D33Fm8FcBxCKRVYJNB3wl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pGJCmQ8Hs8YkNZE3s8g/zGKYdeQTM3KHFmlJj5wldlvvRWAtbCEEwBGfHttWjeYE3nDIDBk8DXM4deDat7k9vpYRq5vIic2RMe7rRjHXiLK1MbvdcEWAw1l92SFQ+jdsOMdsPhgQD6Gp0OCbIY08Lk9itQwAKjikIppqK5DXSBGQdkKWLJ+FKyCGe5TVgH0hqlq7pr0iKwDc3PHyyyHGyk/gJeeD07oOoFtFoIcSqCxIPFN3u4K6xosPJE9L0ggtS7KCabTnuV0zhU7n6n1c7zaDSV6RRw8oOcL0t//dJcc5bpmQqPpLT1Dtz8r6a6I0+Wp5olsWUSP0ddsjDqbvBw==
X-YMail-OSG: o5sTA5AVM1l4Ary0aEi6MlW9M4H05KtDi9GCWifre9cUQa36_1J1lmp5SMVRLay
 p4n_dUVSGrG.nOR8TxEjjmPl9HkrPVKn7GruH2ro3hsC1fGirOetmBdv5psZAYo96GMFoX3rdHx8
 6vbxG9sNCw.w7cRzGP6rTv0QcPjq1CqOpV7BX7P51hQIek7kbh03SOm4dTzLjwnJY9aaMllv8q6t
 f33D40KKrxHSIOsh.G2opSzjNvGFQpY4ttLUKDlBTM_Px62tAZGKlxBwj500ujtwcYRUX_y7PI8b
 AlxfDTEyzA.fwtl9mpLV50iO3dPiJGssxq.ImGYLHYisC8Soau2pewfg6jwQYb7kHuwyELXlQmtY
 _4GQqYIoMBuwZIYY1y_DtRKg9Y.KSZiXPm7h_yRQgviMDhMQNbDf4BVzfGQ5FN0JcQArIgcxXLlp
 lJJxCrTSmnC8ZwwrhdrwO9Myf0CwAbNmhNFe.iu.DJVub0s5bMuW.CpyjEIhEKMZC5P409LL316C
 JxN5PUAB5mlsgX1i1KicsYTuydqDoXVrApvEy3em0vDY67g4Yx95A6ea17kyGza1H.UyDH8YxAAw
 hovls8yTiU2SLDup5va3Gsu78POsboGJGAlNurdzdW9LLf08HvVCaNoL9l.y1BuNS2iKkZlF.WGA
 zVjG.pcWLu0afyBOMITPuUGYpapK6aj5AoTNmEd_EU4KtUxw42pHmu1YvuVELL9uh6l15cRw5b0U
 yKhH6q6JFLOQgNqpOOR9UeZoQl_lkx0UFwPITD.TaGoyOG79PT0FNT5dzFJeaRAmLAS2by9nQeE2
 zUUFOe4BZ3S2WLPLy8Y2zwfPH0cUx9Edmpg3Jv37Q6eC3cadNSkFTfsOZB6axm5eQShfDsuvEHzE
 Lt95e5VsWUKYqnLP_8_JW5oc96c3S8L9Nof4Uwp9rWPN533zGfAA2vMa7jFSLhA.0LAYBtJSW8UT
 hNL3DDbdmEz.CEBb_hizRyaunNpJqp_Eh2L6SE5fFpME3L6ed1OixV6LozWKvG8i2FceBeE4KALQ
 cY48GownLj1dFjgKwwkYdpXDC6fQIxGRFGsGrZ5xxf8IfnKjWF3gqGfcr5NP6cbP0CuVesqqNLzN
 hO77ow2B79pQWi3kORVN.Wgh19OoHhCXB9_PXWCORLEF1.Q_RuG279.S6hn1SyEpsiPA0i9KlDmn
 JcOc_ZvL5QhozFNhM29nJDncfgSfnxGw7RWjvzwTqQE.WUpV2Er_LSxvMpVImZu77W8e3O9_bscp
 BOrpOYQGpir9TdvmBfWp6EpULRKPxz6N3ltHMuZecS4qj2M6bUPu0BXK52uybNIWfEJvgSnGKyv7
 N1rsnRx0m.AfTF54N7pQFDvkNcBQABymc23zACN7KkcdSDnEPoNuopeKaKgiKuult3JN6Ee7Ubmb
 .fQgmA3VYOwrVMtU.djU0lAizP_CHyjBFL1Av2ax54ljAlKXicx59kG0qOdhPmkL0hii0ddO3wau
 PgSWgj6IHH2EOT0WhCUws0FQnUnSDvNZSvTx9fJxSzHlsIGyYFAVCHLtCiv9q7hsyMUl9m_DQH4S
 dyLuXDQD5Bsn_8dS0lKiWe7vlx_KOfEX8fbCd0GySyyTFJaTwZ1jlcoEHiN3kZF3vd0eZoHlK.IP
 EGxnTSoMMgC0Vwfb.y9G6C.KrjMTB1_iUIrdSg0zsqzD7wARHoCsX476uSS6LHx1UrbjlxTPB2Oh
 Ae8sCya0FIuEp1XylMDDVf8rxqX5IzLWuQXiTGfC57liq_pbvfAXOXXnfLbd_GbACW4J..6rwHi6
 gOVmyoBkC4MM5MnhM9JZKpOTgtVTp9L1XgFZrUisYmaz8OEEg6pHNB70zQJTAqndZtR1J4.CuPS7
 bF7KyhpAqikxkgWyhBcgs11MLf7dT4yGWyzt7Uaa9V8dCEF7eprjO7FenZahGK2RfkUvNqe3OGi.
 F1AvIVQUF9VYrIqspEcP.CW_HcO.b5lwbPSzf9H0P.Nyt0HMqZb1IUo_0M3VX8YEqvd0c4oNocWE
 7ogOYEbqcGoZmtmbI52WwIjj3AfZpBEaz8oOzJKz0IWglk70cB0RxNQIpeT7fBmkLYlmCmBFH9S5
 d0vhpE.yA_pQqvR6VP8sI71FcY1S1siQ8taL01sqJrFxJ98BMIBSa44IJbN3NLxk22EkuXjHNWqW
 sSYua9MSl2jQ3PIZbbfo39F9CQBUUrqt7grgApK68zBcFBgqc2XeZ491_O4fonUa_xQuyRvqAdN.
 EBXwvlyBAIUowp7WqWZxXKJtRvIirGBvvOHgHZBuZFu.QntNgb6cyNyhbJK5vQJQaU1WGt0CKBoO
 IR6avHzh5
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 06:55:47 +0000
Received: by hermes--production-bf1-759bcdd488-4bs5n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ad53f6c7d2cb685cc4f7486999edd8d7;
          Wed, 28 Sep 2022 06:55:45 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
Date: Tue, 27 Sep 2022 23:55:42 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <25CE9BAF-97F4-4AEA-9D70-7B2532D1F314@yahoo.com>
References: <9A3609DF-D873-4712-A61D-C351C162EF2A@googlemail.com>
 <61CFA9D4-8DFD-41C5-A2B4-E5B3CD78C327@yahoo.com>
 <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4McnMB0D0kz3v1b
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Tx9om8Yu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

FYI: from an RPi3B (same USB3 media but RPi* firmware
and u-Boot from the microsd card, EFI and later from
the USB3 media):



U-Boot 2022.04 (Sep 28 2022 - 00:42:50 +0000)

DRAM:  size=3D30, ptr=3D5c0, limit=3D2000: 7ffe3b0
size=3D8, ptr=3D5c8, limit=3D2000: 7ffe3e0
948 MiB
bind node psci
   - attempt to match compatible string 'arm,psci-0.2'
No match for node 'psci'
bind node system
Device 'system' has no compatible string
bind node axi
Device 'axi' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node chosen
Device 'chosen' has no compatible string
bind node reserved-memory
Device 'reserved-memory' has no compatible string
bind node thermal-zones
Device 'thermal-zones' has no compatible string
bind node soc
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node cprman@7e101000
   - attempt to match compatible string 'brcm,bcm2835-cprman'
No match for node 'cprman@7e101000'
bind node mailbox@7e00b880
   - attempt to match compatible string 'brcm,bcm2835-mbox'
No match for node 'mailbox@7e00b880'
bind node gpio@7e200000
   - attempt to match compatible string 'brcm,bcm2835-gpio'
   - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches =
'brcm,bcm2835-gpio'
bind node serial@7e201000
   - attempt to match compatible string 'arm,pl011'
   - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011'
   - seq=3D0
bind node spi@7e204000
   - attempt to match compatible string 'brcm,bcm2835-spi'
No match for node 'spi@7e204000'
bind node aux@7e215000
   - attempt to match compatible string 'brcm,bcm2835-aux'
No match for node 'aux@7e215000'
bind node pwm@7e20c000
   - attempt to match compatible string 'brcm,bcm2835-pwm'
No match for node 'pwm@7e20c000'
bind node i2c@7e804000
   - attempt to match compatible string 'brcm,bcm2835-i2c'
No match for node 'i2c@7e804000'
bind node usb@7e980000
   - attempt to match compatible string 'brcm,bcm2708-usb'
   - found match at 'dwc2_usb': 'brcm,bcm2835-usb' matches =
'brcm,bcm2708-usb'
bind node usb1@1
   - attempt to match compatible string 'usb424,9514'
No match for node 'usb1@1'
bind node dma@7e007000
   - attempt to match compatible string 'brcm,bcm2835-dma'
No match for node 'dma@7e007000'
bind node interrupt-controller@7e00b200
   - attempt to match compatible string 'brcm,bcm2836-armctrl-ic'
No match for node 'interrupt-controller@7e00b200'
bind node watchdog@7e100000
   - attempt to match compatible string 'brcm,bcm2835-pm'
   - attempt to match compatible string 'brcm,bcm2835-pm-wdt'
No match for node 'watchdog@7e100000'
bind node rng@7e104000
   - attempt to match compatible string 'brcm,bcm2835-rng'
No match for node 'rng@7e104000'
bind node thermal@7e212000
   - attempt to match compatible string 'brcm,bcm2837-thermal'
No match for node 'thermal@7e212000'
bind node local_intc@40000000
   - attempt to match compatible string 'brcm,bcm2836-l1-intc'
No match for node 'local_intc@40000000'
bind node mmc@7e300000
   - attempt to match compatible string 'brcm,bcm2835-mmc'
   - attempt to match compatible string 'brcm,bcm2835-sdhci'
   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches =
'brcm,bcm2835-sdhci'
bind node firmware
   - attempt to match compatible string 'raspberrypi,bcm2835-firmware'
   - attempt to match compatible string 'simple-mfd'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
bind node clocks
   - attempt to match compatible string 'raspberrypi,firmware-clocks'
No match for node 'clocks'
bind node expgpio
   - attempt to match compatible string 'raspberrypi,firmware-gpio'
No match for node 'expgpio'
bind node power
   - attempt to match compatible string 'raspberrypi,bcm2835-power'
No match for node 'power'
bind node mailbox@7e00b840
   - attempt to match compatible string 'brcm,bcm2836-vchiq'
   - attempt to match compatible string 'brcm,bcm2835-vchiq'
No match for node 'mailbox@7e00b840'
bind node gpiomem
   - attempt to match compatible string 'brcm,bcm2835-gpiomem'
No match for node 'gpiomem'
bind node fb
   - attempt to match compatible string 'brcm,bcm2708-fb'
   - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches =
'brcm,bcm2708-fb'
bind node vcsm
   - attempt to match compatible string 'raspberrypi,bcm2835-vcsm'
No match for node 'vcsm'
bind node virtgpio
   - attempt to match compatible string 'brcm,bcm2835-virtgpio'
No match for node 'virtgpio'
bind node clocks
Device 'clocks' has no compatible string
bind node phy
   - attempt to match compatible string 'usb-nop-xceiv'
No match for node 'phy'
bind node arm-pmu
   - attempt to match compatible string 'arm,cortex-a53-pmu'
   - attempt to match compatible string 'arm,cortex-a7-pmu'
No match for node 'arm-pmu'
bind node timer
   - attempt to match compatible string 'arm,armv7-timer'
No match for node 'timer'
bind node cpus
Device 'cpus' has no compatible string
bind node __overrides__
Device '__overrides__' has no compatible string
bind node leds
   - attempt to match compatible string 'gpio-leds'
No match for node 'leds'
bind node fixedregulator_3v3
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_3v3'
bind node fixedregulator_5v0
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_5v0'
bind node memory@0
Device 'memory@0' has no compatible string
bind node __symbols__
Device '__symbols__' has no compatible string
bind node bootloader
Device 'bootloader' has no compatible string
bind node clk-osc
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-osc'
bind node clk-usb
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-usb'
RPI 3 Model B (0x2a02082)
0
   - 0 'serial@7e201000'
   - found
0
   - 0 'gpio@7e200000'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm283x_pinctrl gpio@7e200000: set_state_simple op missing
simple_bus soc: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
pinconfig uart0_pins: set_state_simple op missing
serial_pl01x serial@7e201000: pinctrl_select_state_full: =
pinctrl_config_one: err=3D-22
Core:  72 devices, 10 uclasses, devicetree: board
MMC:   0
   - 2 'mmc@7e300000'
   - not found
0
   - 0 'gpio@7e200000'
   - found
pinconfig mmc_pins: set_state_simple op missing
mmc@7e300000: 2
Loading Environment from FAT... 0
   - 0 'fb'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm2835_video fb: set_state_simple op missing
In:    serial
Out:   vidconsole
Err:   vidconsole
0
   - not found
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: 0
   - 0 'gpio@7e200000'
   - found
dwc2_usb usb@7e980000: set_state_simple op missing
dwc2_usb usb@7e980000: Can't get reset: -2
dwc2_usb usb@7e980000: Core Release: 2.80a
USB DWC2
scanning bus usb@7e980000 for devices... bind node usb1@1
   - attempt to match compatible string 'usb424,9514'
No match for node 'usb1@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
bind node usbether@1
   - attempt to match compatible string 'usb424,ec00'
No match for node 'usbether@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
   - seq=3D0
0
   - 0 'gpio@7e200000'
   - found
smsc95xx_eth smsc95xx_eth: set_state_simple op missing
4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  2 1 0=20
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc2 is current device
Scanning mmc 2:1...
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@7e300000.blk...
Scanning disk usb_mass_storage.lun0...
unhandled device class: usb@7e980000 (usb)
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
 <2, 0, 1024>
Unrecognized filesystem type
Found 9 disks
Missing RNG device for EFI_RNG_PROTOCOL
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
** Unable to read file ubootefi.var **
Failed to load EFI variables
Initializing EFI driver framework
Adding EFI driver 'EFI block driver'
0
   - 0 'smsc95xx_eth'
   - found
unhandled device class: usb@7e980000 (usb)
smbios_version =3D 0000000039f2503f: '2022.04'
BootOrder not defined
EFI boot manager: Cannot load any image
FAT read(sect=3D16384), clust_size=3D64, read_size=3D64

Device 0: Vendor: Samsung  Rev: 0    Prod: PSSD T7 Touch  =20
            Type: Hard Disk
            Capacity: 1907729.0 MB =3D 1863.0 GB (3907029168 x 512)
... is now current device
Scanning usb 0:1...
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
BootOrder not defined
EFI boot manager: Cannot load any image
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
Found EFI removable media binary efi/boot/bootaa64.efi
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
FAT read(sect=3D131), clust_size=3D32, read_size=3D32
FAT read(sect=3D163), clust_size=3D32, read_size=3D32
FAT read(sect=3D4963), clust_size=3D32, read_size=3D32
dev=3Dusb, devnr=3D0:1, path=3Defi/boot/bootaa64.efi, =
buffer=3D0000000000080000, size=3Dd18dc
unhandled device class: usb@7e980000 (usb)
unhandled device class: usb@7e980000 (usb)
- recorded device =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)=
/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x4e8,0x4001,0x0,0x0,0x0)/HD(=
1,GPT,9cdadf2a-de3c-11ec-8f37-a0cec8d68fdc,0x800,0x82000)
- and image /efi\boot\bootaa64.efi
858332 bytes read in 51 ms (16.1 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Loaded from disk
Booting /efi\boot\bootaa64.efi


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 07:49:31 2022
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 4McpYJ5b5Nz4cxJb
	for ; Wed, 28 Sep 2022 07:49:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4McpYH6Skwz3y55
	for ; Wed, 28 Sep 2022 07:49:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664351377; bh=G9vEaLyYfz3P3r+Zwyr52S88V5Zo71Xra0tUddSXIbU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=fwNIaOoePgSELGoEsS7XkXxKNyg/dtQ9jvMBB/AkYPXAfbT9Wwb4GLnvF6Fym0VHOwEMyG+0yP+fhEn9aZurWTS+7QbfCRwmL1WIA9kYTlHK978abhWHuvsXxkfdplqWUBHQIzbEybwyjabiEbCbZeV6ZxIXWen5Tluhe7mKrY72LLm1uLx1nQqauQTaP8JDEJggynAjcmSX9ZEYE38xMSFGXkqG9NkiYttM4s/BVERJlAPptCcobCCfFXZz58dsleK8iTLAPIOiv0o6fCKNn7+hNGXfsrJ0Uj/nYdkZ/UQq9CiXJFlseGH8go8uKi2w8Zwz6/Jco4dZEU91/2aOWg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664351377; bh=d0/tGXIbVYKtlR9e3BKWxXhN5UMhJWO0meFAPrF8/24=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TjKEBVZ/Bo1wJ5zasqYO1IpTrI3TE6/UQKAWMcBr1BihiaEgRmAFO5WjpmpxtLGY8w7mFBzVeKVF11I1x4eH5qXZEy6NKmMHyijHEEPtDQesHQQDaNQ8PfKHJU7c7Onhhj88Or93kdfyQlFBbmpBUaTVuCrl4VhYCRjPSdpMX85EWtw768ddSRmHBYw5oL/rxmBngOcEsUI+QxkuPcB+bn66KvNX8CgKEscIF69bQy0mcHSQ15WS7ypkSFchyfsRqARBXPqNPr9c5t+XFde+hG7esdYG2cDSblZztU3IgUpn6TUwk8gcpgFy65yglOgOXL4RoV2ZQ8q3N8SGlA9Hfg==
X-YMail-OSG: qMhpZUoVM1kT.9YFUoOYzWcs__9i9Ae84Vj7KuwLLSxmecfs6obf2k_kJ67v8jT
 DYzTKJu3iGgJb.4mTW9aIuefsJGWs858C8ePHhrsCXuilm3aQdhO70JOO9qkMkxtXbBUX42HOmV1
 fi37D1cH9PZYTCLMhCUR0H394b8ybzLwifQyfMJVNIxyDOajK58PEO9n.4ZKw8bqOa8dWG3qLSih
 0aHQZe4M1i_A8EDv.NnQSc539hMvGKtGRUuGIo9lZBC7It61OlfPLx5UBpA2Tv_CsdzCmTxP_S58
 YKWRZUtK6UAFvJs7akXxU_rWPbuFAP88Yx0SLZ68qXjI69oXeX0lMP9xvxLF235x_6pQ03HD5XFD
 46yTVPbW.Su6Zxr0crzcWJmVIIXQV60B6kH4qKWPIvHZv67xGEFn3eY_WZkoQ5JZ8wQwcyO0Y7dM
 B9qWjvp6nBMy8keYs8q3WnuuNPlJZ7eiiC9HXXmgDUq0reGr6.Cc0T9KGgEtVPd3.V_LkEgxni4C
 dxVyK_7PMou7buWdY6Bv_WYMsmwobYHBvVFVttg8o4n6m2T8dgUvqFK90jGMcto09K9VkcEPHsvE
 jO2tg04kRJfqHtutICVn6sjdYbbk5QoVe9p6UFQag89ix3MuQ1U_0Elqbe7EIbhGjOMrosNIlika
 vGaD_tG.6GP24Gvaf236B7nrGVmJ4GkvoYKVv1WOlQ45r2b9FFGMTDoeLxaJ1Tyzb1zxDuXHfdQO
 Gphz8IDEDO6xLTjFr_HVWNj8Q4jrWwqXuv6d.unn3oTSmaZDJc2sG1nTora_SeFSxaezTcpOkt9r
 aDvWAGBEVaYDsBIwwZ_ol_3DKOQw2lGfcrj7.tPZz3A7p.OHcM0YBukAOR_4qAh7owUYjKTotedG
 12obTPzZmKwbsh4TcvFeY0jWtixu0i6bROFr3emfPy8EXSujJZhgPxQYCplxypKQjWfasDeU8jLd
 VtmC4fHGb56fFm0XBbQUIajly5gN3IyG9i4IttrPGA200McTqbJmyc3J77RvXdsPx8631O9t1yEm
 DURbIK_TvAXaYfh5Q3zVRqeWu6UlIJUatwS_t5A_Kf80QoF1lV.s0HIbfDjvT7Ku0jBMRWqZmbGV
 U._2x.q0.hHHFnVbKRxr6cAoUb0WDIEAg28pRK8RCVbaYkJB5URdwHHeFIGHx60Y9majZREpwTNe
 nhhRUT6bWQhH3E7Of4zKRaOJzHP5AXAbiOAhYkbHBbohEqT6kLezIeQJJt2Sd9fPt.3rFizmKZhe
 JxvzgO.mupe2dhjPCSankiHmTJS9tFAtSz.xpcyUMaImrxpsezcS4Bnz9F4YyIBp.8pxL.PLMB4H
 a9wzPzqeVyRI3llKR6UMJlBBwdZyn_lN.Ypy6GfQ6e5r2GeVIVqxRAHxNVJwddBDEaKosXY6OgwH
 ZWghgOop4I3xdDA_mfwHMmFroxVa0zLWm.khyi_QnVp.I_oGmQfSDvWAT4KPkG_hxkSNzpuCG4wy
 ikkiHaB0VxaXO6xNaESmWV4v_uxLrPFjU9gv0wN_4O64xqBf.PGbpr6NSFxKrA.4Wpm0Bv3IujOO
 65N7dg6gckYScnqpUV.IqYcCoGpBHQsaJbdlPsVkWMQMZbj3WhAlud0f3_JQuUrmsxZ9UEGcHrzg
 cFRGZFSJwzka.tFxT8vrTyz6jAI0T.79cywsrA3EO8sQ.ipMhUH6wg_HuhYZjBr1MxJYm0.oR5bC
 KwqeZRVmUZW4ZAQ_8KEtw4DcoeZrBRanK2CEvrkQxDCQwo7ZVcw33KwKkxGQ7AvLcSxvIbP4urJu
 IMjXo_SOS1sOUHOFQif91C_SFKjgRMFbVN3pm.sOxkVbvov77Ah7yHj0ZZ0xnxu9MbirswjHihrE
 fLCYIyXF55ZfFj9.vH7SiZ6X5NDSiW0Oy400Kgnb6eTN_usaqE.THvc0b0B0rDvBnKjRV_gUf_kv
 1fvyGfqQL27lV.meO.pODJH1OJ6bxxvpu.qAMql_fraNM56TdEmMsAbbKfuGE60xTHnLVJhWcpaV
 DimvGJfQiIDqRis0rdG4OGFBvf1TuHSonCF.Qj0O5Pmv21Kj3HN2VGjOmpDwqAWT2BBoi9aJHRQ0
 5pPMdlC4XKqu.TOvNnUN5812kdWAbrPXbQGL3YKKNjhjG7nu3VXAQNL.Z0wQ6HLLIz6qLMfMMRc_
 VeSs5CwVM.OeNDKJhW45S_0FZwy587E_TRfcqzwQSRX9rSrIMlzhvXX2ofjb67YmzzAYYTC7zh0T
 e2bNW6KQcJLurOYjboRVjIleKi6pDKBvrp25w1zxkoJmieiJqtQrAPb_85B1PPOv0WxM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 07:49:37 +0000
Received: by hermes--production-bf1-759bcdd488-x5z77 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d243015480c0a8c676dd463751a6de0b;
          Wed, 28 Sep 2022 07:49:34 +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 \(3696.120.41.1.1\))
Subject: FYI, RPi3B: da0 vs. pass0 for same USB media based on
 initial_turbo=60 in config.txt ?
Message-Id: <66AA8ACF-5763-4035-B467-98BE42832D99@yahoo.com>
Date: Wed, 28 Sep 2022 00:49:31 -0700
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <66AA8ACF-5763-4035-B467-98BE42832D99.ref@yahoo.com>
X-Rspamd-Queue-Id: 4McpYH6Skwz3y55
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fwNIaOoe;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.26 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.92)[-0.915];
	NEURAL_HAM_LONG(-0.85)[-0.850];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]
X-ThisMailContainsUnwantedMimeParts: N

With initial_turbo=3D60 in config.txt content used by RPi3B's
I get:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REPLACED***
da0: 40.000MB/s transfers
da0: 1907729MB (3907029168 512 byte sectors)
da0: quirks=3D0x2

Without initial_turbo=3D60 being placed to be used by RPi3B's:
(so no initial_turbo assignment was made)

pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
pass0:  Fixed Processor SCSI device
pass0: Serial Number ***REPLACED***
pass0: 40.000MB/s transfers

(The pass0 case does not end up with mount root working:
timeout results. For reference, the Serial Numbers did
match.)


In both cases, those lines are just after the text (diff
of serial console captures used to establish sameness):

uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  =
on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1 CAM
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: ***REPLACED***
Root mount waiting for: CAM
Root mount waiting for: CAM
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Samsung PSSD T7 Touch (0x04e8:0x4001)
ugen1.4:  at usbus1
umass0 on uhub1
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 15:29:22 2022
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 4Md0mQ2xvsz4YNyK
	for ; Wed, 28 Sep 2022 15:29:58 +0000 (UTC)
	(envelope-from dch@skunkwerks.at)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Md0mP6LD6z3kN8
	for ; Wed, 28 Sep 2022 15:29:57 +0000 (UTC)
	(envelope-from dch@skunkwerks.at)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id A159E320094B
	for ; Wed, 28 Sep 2022 11:29:55 -0400 (EDT)
Received: from imap44 ([10.202.2.94])
  by compute2.internal (MEProxy); Wed, 28 Sep 2022 11:29:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at;
	 h=cc:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=
	1664378995; x=1664465395; bh=o4YagMeOl0tz2kTi761fpTpCLUcGdqA+N3r
	MnyDMaTs=; b=jgJwppwuAP4IC+CoS2nlbE3dKa/Kxm0UdXRkPxUcW3izylO3y3J
	t4Ym5g1zEcVnh8mC/cJjrzJjEBmgLX9bKhLRNfkc6gBr73akmkblKEMQkdD9iFEw
	qn1zA7IfDfrmAgthU0BXja1YkbHH9jVFWS/VGkoRpNr4M899tMH9fgVvkPJO9Eov
	qzGhD+otkRYzd7C9DJKMQQ/PEW6GBL5036XRg/vQ1IQ69rQgohtqr9aKBVOCfcqS
	8OoizsvUVVMf5IKtUix9jPxiWrRR4EXlNB81PXTZ/6+ejBgK/JjgUuDpxTRyC+oI
	w9JfFRijoMlrjVjOO/D2vBcO/6P3SgLwoeQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664378995; x=
	1664465395; bh=o4YagMeOl0tz2kTi761fpTpCLUcGdqA+N3rMnyDMaTs=; b=o
	ZQ6w6na4SqGED/OZ1DxHemCfQJds0Kwji7ZLxTBbJbruW22F2205Igk540YYFpyO
	3MOKtNrpjuCo30+2yBYAfnDzKVl9sgB4m5vZyD7dThWe6MB3j5c4/9lAetKEOhk5
	8dozUB6//R+1VFffDIKbfZXvIv5TXM7AiGnOGzBRQDftQBUM9GRUtBkA3I0gWXOW
	iuOv56H+NQFATx8MuijPzvWHPif3kvKBV376VGkgnW81ghT3q+8KdKT5Tsit3oIF
	o909qnE/7TGN+heHplsNhKhn0UzIF4Ch1POYnDQUsUatymbhl/lH4htMNGQjSB6x
	IrZgel63DWZN/rN1ll/uA==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegkedgleduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd
    erredtnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghhuhgsvghrfdcuoegutghhsehs
    khhunhhkfigvrhhkshdrrghtqeenucggtffrrghtthgvrhhnpedtveffgfetveffjeegle
    ehuedugfekffettedvtdekvdfhhfekffeffeekjefgveenucffohhmrghinheplhgvnhho
    vhhordgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
    homhepuggthhesshhkuhhnkhifvghrkhhsrdgrth
X-ME-Proxy: 
    
    
    
Feedback-ID: ic0e84090:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id B1E9136A0073; Wed, 28 Sep 2022 11:29:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807
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
Message-Id: <64263e19-7592-47cb-9408-f6361b233f6b@app.fastmail.com>
Date: Wed, 28 Sep 2022 15:29:22 +0000
From: "Dave Cottlehuber" 
To: freebsd-arm 
Subject: fans & ipmi on ampere emag with lenovo bmc
Content-Type: text/plain
X-Rspamd-Queue-Id: 4Md0mP6LD6z3kN8
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=skunkwerks.at header.s=fm3 header.b=jgJwppwu;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b="o ZQ6w6n";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 64.147.123.25 as permitted sender) smtp.mailfrom=dch@skunkwerks.at
X-Spamd-Result: default: False [-4.09 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25];
	R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm3,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from];
	MIME_GOOD(-0.10)[text/plain];
	XM_UA_NO_VERSION(0.01)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	DMARC_NA(0.00)[skunkwerks.at];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FREEFALL_USER(0.00)[dch];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]
X-ThisMailContainsUnwantedMimeParts: N

With recent exorbitant price hikes for electricity in Austria, I'm
looking how to reduce the fans on my eMAG HR330A when its idle.

There's no obvious sysctls related to fans, but there are IPMI
raw sequences available[1] which I can send to the remote BMC:

ipmitool -I lanplus -U ... -P ... -H ... raw 0x3c 0x14 etc

Has anybody got a better solution to managing fans & temperature?

# demsg
[14935] ipmi0:  on acpi0
[14935] ipmi0: SSIF interface not supported on ACPI

# sysctl hw.ipmi dev.ipmi
hw.ipmi.cycle_wait: 10
hw.ipmi.wd_pretimeout_countdown: 120
hw.ipmi.wd_startup_countdown: 0
hw.ipmi.wd_shutdown_countdown: 0
hw.ipmi.wd_timer_actions: 3
hw.ipmi.wd_init_enable: 1
hw.ipmi.on: 1
dev.ipmi.0.%parent: acpi0
dev.ipmi.0.%pnpinfo: _HID=APMC0D8A _UID=0 _CID=IPI0001
dev.ipmi.0.%location: handle=\_SB_.I2C4.IPI_
dev.ipmi.0.%driver: ipmi
dev.ipmi.0.%desc: IPMI System Interface
dev.ipmi.%parent:

there is no /dev/ipmi device btw.

main-n258204-33de921ca874

[1]: https://download.lenovo.com/servers_pdf/bmc_command_list_specification_v0.1.1.pdf

A+
Dave

From nobody Wed Sep 28 17:28:39 2022
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 4Md3PL3zRtz4crD2;
	Wed, 28 Sep 2022 17:28:38 +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 4Md3PK2Jtgz3tq0;
	Wed, 28 Sep 2022 17:28:37 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28SHSd67076055
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 10:28:39 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28SHSdMK076054;
	Wed, 28 Sep 2022 10:28:39 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 10:28:39 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220928172839.GA75564@www.zefox.net>
References: <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@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: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
X-Rspamd-Queue-Id: 4Md3PK2Jtgz3tq0
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

[removed Klaus from cc, added freebsd-uboot@freebsd.org] 
On Tue, Sep 27, 2022 at 10:45:36PM -0700, Mark Millard wrote:
> 
> There are almost 2 hours between 20:04:31 -0700
> and the 21:51 when your Email arrived.
> 

The delay between compile and email seems ok. 

> None of the output that I reported as showing up
> shows in your report. YOu can look at:
> 
> https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html
> 
> to see the U-Boot output that I got (via use in
> an RPi4B).
> 
> Are you sure that the u-boot.bin on the msdosfs
> has the new content?
> 

I'm still doing something wrong, but haven't found it yet. 
After cleaninug up old files and re-running make and make 
install, find locates:

root@pelorus:~ # sum /boot/msdos/u-boot.bin
4933 570 /boot/msdos/u-boot.bin

root@pelorus:~ # sum /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
4933 570 /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin

root@pelorus:~ # sum /usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin
4933 570 /usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin

root@pelorus:~ # sum /usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
4933 570 /usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin

At the same time:
root@pelorus:~ # ls /usr/ports/sysutils/u-boot-rpi-arm64/files
patch-common_usb.c       patch-common_usb__storage.c             patch-lib_efi__loader_efi__console.c
patch-common_usb__hub.c  patch-include_configs_rpi.h             rpi_arm64_fragment

There' still no additional output from u-boot, although with enough
re-trying the machine still boots: 

U-Boot 2022.04 (Sep 28 2022 - 09:02:56 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: Vendor: SABRENT  Rev: 1214 Prod: 
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
[normal boot follows]

A file copying error on my part seems most likely. I'll try again
this afternoon.

Thanks for your patience!

bob prohaska


From nobody Wed Sep 28 17:57:41 2022
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 4Md4332m5cz4cv0X
	for ; Wed, 28 Sep 2022 17:57:51 +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 4Md4310qM7z3wh2
	for ; Wed, 28 Sep 2022 17:57:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664387867; bh=CmkL4pYRzbihovovf5qISG+CkjQJcz8Z3RK8r1J7Jy8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DRvY+DaN4pqjnZtJXJycKSzykflEVBo0rQgPyHG3sa6+01GTJqYJbhX4/72D98BYGwk8fHhUam+kqcti5xbRDbzT5pewOgBnBBaEAyUD2ljhtOftz0oetQlZ3p+NzvZEB7jkUslFikwH/zSmQSQ6CZWf7FK9swPP12cdu27xLBu+4N2mzm+c+sJmFfvsiyyAiquUNcbv7Wm8TKWLMeZ1wQ/Yl/NtYpjUegMKDA/KpUfh5vTC2WycrerZYIC37He0FCNtGeBFIsSaFhq/0it8FH3irhq0ewrIAuhXfjT8YfC366fX/k6rZqmn9brIX6lT0u/5lutLiHuG1atAheyCGA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664387867; bh=IMZP5QNVGyT56Eppxox0p9/gKiGudg5I44QZSTP8Bpe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JnUHP4PAZ5TWlM0bHmKVhoPeyvxOTtf2ZRl4DTonzJsFsb99d43Ie0K5f8zdRgsU1gBTGSK0klV2gkNzpkrKmzsUOpM1Q8l9MRBaTQsVl46MFGBrGdXL0ZYEUjnAtz2wVlcmk6K98urLZ0pzWYLXF2jjUZgYAW57WuBN8sferSe/CwWq6a+wHz59rJIiUYaiFU4PiFsHEKwRt3w0UZ+PllOPkOxQfRHW9HH5o5S1cL1+vVwJPYJQ4a5/I31hXbRaRlAb1RQF8D9WCdcV5Qmbm8TBUnm2ehNQyvCD5ODidpr1hjuoykHmNm9bVA17Cdsp9lfDbCiuiWt4L7IREuhUAA==
X-YMail-OSG: BBDp9_wVM1mOVHo9qvqF5rpKpIa.RKa_cJmwVU8bnBTYCEtcVo3diFkcn51Efa2
 Fat4GD6HMw6cdFn0KEmpCrEKUGozui9mYCWPsqO2nE17AAkBSjAdzLvGCv8WRYrA4SAEJ6qMSjEo
 FNhqzD2WHXhT_M.5.EW3MQcoEaNkNyFD1kF5KHhw64Xl6R5anUbMpDs3lw4hxGoO4z2m5yc3TBiB
 jnTtxJCPJWrda9evYInJnZLflHQ3U.0pBWTUldQKhE5gUJu0T3VVKWMu9f1CDMHpVRBXT8IMYwbh
 uL35iCK.6P.M6AJVJ7Qe2g9On14HNBDhScbt6nRKpzXcEr4C6XCy3DPawFYw936HCOvWZghSe69g
 1KPIDXNgnr90FrRwJGZfmeEkQ5Om7XYal8nkwar9xb59SYNfxc2aU37Cc3idYiM07pQcH7diW8ju
 ZnPi47IK0FWGquC5vG9Gclt8oQJ8gcY3VFcMHkdxtPDwdCMZbLQ_0CIwU1gpL7UJTCKadEwxowZj
 lS8.SGGoUSGwzskakji.h7qnHMyKxdZ1IsTW_oVaq5tZ2mqHQvTdR6f8qFHeDjYbVg6Hi95jiiPP
 lu4dV6dW7wA0kRDSOmUJhErTaTWJy67621XjKz9Rvt7TyGpSLJzasXzttssAjncMldKNOX1jKuLZ
 R2Mr23URI1YnrZfbC6mTmDkcJeYiSgl1XWEKTXQXotsSUaBqyWgCr7sLQdAxZrl9dwEAy_ViJJxR
 _PKKF_LCZ3cCGWwc2EtNVxxyvAGCz9WxzNOws1MBEJisFTmCcSawy5fPJjJs0tPvPEjGxqtyrkYX
 VBz9DGMEjzMfdWNA6uCrGAqGtprAa3E0C_X_hCHKtExscgXpm_dsIXz5XvWZREeHPNZ2Jeapbm95
 mP1IY4bVWRUEFHWSq8s7Qn3m9DbSKM9v8zh8TRpJyDpDijzLEAjCYvZMBasfU_cUw8OusUSD9vir
 .d7dQ.KKk_IkTSQVRzmu9HjrCiONQbfH2hl1gLshPrNvuoeWTF3J9GLmKKIbJuWYwJVRMXkkxeUv
 hAzTYCHMwt8xPoz_lKN7mCG5lvFqBXI.hxn2.DXceRvLVQHE4x.6RPXTE56l6DcxdIFzGgYIhxux
 h4iCe308kU14_XLQQlCWMSbvdV_ol8yp3zHt9dBRODOh3OTpSNh6gzoUDVwG8a.4bL3NBoR5adU4
 Lqs5qJcObgfwutONZZbM_9A5dgYMn1maPN_AyXHPS8Y.NS1DCnrUQWa3iUGQGS111U50wEC6XlgY
 aDTzWYO9dlNjrwfBH7uD7LNgvGp8CVfO3jhA4sw0Ncp7o3YnWV6p7l58_ZNXzlwRvhkD1.QRpQDn
 N33oRfypGgrKpiU47SAC7LlryD2yHf95pQIX3JEJf8udxzGio7T35rmIzULRbDHE1a4MQeCTk2Uj
 01RuxQ5Y2636tuYxgHVB9tFP7Clv5nekZEkACQOZrXRLwWgZIh1vfrq.t0FHf7z_2ktcUShcEe_L
 oiUwzSMzgxT2Qu8Zi_96LXebM6AdVonqU.fc7Si.4dD4BZwvR_9.1v2Sln.PuuPRv45UtgHaXwbr
 sx_nWaIeVNHNkk4FYTd3Qj.D5IGMKaN6ZZjkDWb6a.Edqdn0gB1.CDN57kvdTT17Pp0ez8rxkNUG
 i9rSgnH_lgXQK58X6bbggAUP9FX3_3Fiz8EpW8ntvvoW4Kcy0z6i8j3ByrGUpffhJ5H06e7gHV1Z
 7MFHkdXCl8DZkVY6Ivj4QMHKFbFAN8R8jrQfNR7uzvDPYWGuKQ1FvwzEjSkXhVxrZDKA0CQr_.kd
 LPBqGjx3qE42smu92_.eEc6Qsjxc_Fo_INABoRNlPzMIm3.9I31PFo4oyijQVm.fveHmlZhX4WEj
 EX2eznfCWbknEZssh5fhZsNHI2i1vGqxex.76Ep_w9C2R1Khfnb534je3TTTQCGS2awFXd9ieoIZ
 PLZSlHa7Xd4quKV39NBsxTvymGGQUMFu2K3ffFPytANPQ1hd1OturusLTKUcGUP3GxqFWfvqtU3I
 0H.m9LeEQ05qcbW4Mk0CGgT8wq3Fz8NmlK4n6JXRBeuI7xs9K5PLUH8F4I4u_m0EsiKHGTI.gJ_X
 SxiSYgmeEgVzfRLtnqpEyrpZP0KgKXN0WxpKRLIKJtI6sWzge4YzESH.MtcAsjPu6ig1P5gTK5bW
 wnF3DI1aJpVbT767_Yg0l7OxyYQRLYdXGOp1il0vDtgS9.knEEVa4qakYBIFwD9mlHgtKN.Z04pb
 7FeXLJA_sSfjuDTCr.7Su2Q9lG9w2G16otB7HcFXHPTb6eEoDW4PbfEsBNHnaxIVZKzH9RoahDVE
 ejKqVkcO.IfDMFoGDG8s11vM43kI10jbiWHKBXFvIb1a29UHz7s2P8Yo1Gpq7U2kOXSQkhPCnbF.
 AFNY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 17:57:47 +0000
Received: by hermes--production-gq1-7dfd88c84d-mvm5c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f9a274347cdf9d0550fec6fe81a5027c;
          Wed, 28 Sep 2022 17:57:42 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220928172839.GA75564@www.zefox.net>
Date: Wed, 28 Sep 2022 10:57:41 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
References: <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Md4310qM7z3wh2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=DRvY+DaN;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.972];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 10:28, bob prohaska  wrote:

> [removed Klaus from cc, added freebsd-uboot@freebsd.org]=20
> On Tue, Sep 27, 2022 at 10:45:36PM -0700, Mark Millard wrote:
>>=20
>> There are almost 2 hours between 20:04:31 -0700
>> and the 21:51 when your Email arrived.
>>=20
>=20
> The delay between compile and email seems ok.=20
>=20
>> None of the output that I reported as showing up
>> shows in your report. YOu can look at:
>>=20
>> =
https://lists.freebsd.org/archives/freebsd-arm/2022-September/001804.html
>>=20
>> to see the U-Boot output that I got (via use in
>> an RPi4B).
>>=20
>> Are you sure that the u-boot.bin on the msdosfs
>> has the new content?
>>=20
>=20
> I'm still doing something wrong, but haven't found it yet.=20

If the patch files are in place for what poudriere uses
for /usr/ports/sysutils/u-boot-rpi-arm64/ , poudriere
based port building should then work.

Is there a log file of the port build output that you
could post? For manual make activity one can use something
like the script command to also have the output sent out
to a log file.

> After cleaninug up old files and re-running make and make=20
> install, find locates:

The output during the make would be a good cross check
on what is in the build and if the patches are being
applied to a fresh extraction of the source code.

> root@pelorus:~ # sum /boot/msdos/u-boot.bin
> 4933 570 /boot/msdos/u-boot.bin

Those 570's indicate the smaller file size. The larger
size from being a debug build is likely to be more like
587.

(Your and my checksums would be unlikely to match
due to details of build environment differences
that control some aspects of code generation. But
the sizes should be similar.)

The sum output, of itself, does not show file timestamps
and more detailed size figures that would also be evidence.

> root@pelorus:~ # sum =
/usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
> 4933 570 /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin
>=20
> root@pelorus:~ # sum =
/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin
> 4933 570 =
/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/u-boot.bin
>=20
> root@pelorus:~ # sum =
/usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-b=
oot-rpi-arm64/u-boot.bin
> 4933 570 =
/usr/ports/sysutils/u-boot-rpi-arm64/work/stage/usr/local/share/u-boot/u-b=
oot-rpi-arm64/u-boot.bin
>=20
> At the same time:
> root@pelorus:~ # ls /usr/ports/sysutils/u-boot-rpi-arm64/files
> patch-common_usb.c       patch-common_usb__storage.c             =
patch-lib_efi__loader_efi__console.c
> patch-common_usb__hub.c  patch-include_configs_rpi.h             =
rpi_arm64_fragment

Did the build sequence re-extract the source code and
apply all the patch files to the result?

> There' still no additional output from u-boot,

As expected, given the u-boot.bin is too small to be
a debug build. Until you produce the bigger variant
of the file, there will be no debug or other logging.
Probably no reason to even copy over the smaller file
variants to the boot media.

> although with enough
> re-trying the machine still boots:=20
>=20
> U-Boot 2022.04 (Sep 28 2022 - 09:02:56 -0700)
>=20
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> Core:  69 devices, 10 uclasses, devicetree: board
> MMC:   mmc@7e300000: 2
> Loading Environment from FAT... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> Bus usb@7e980000: USB DWC2
> scanning bus usb@7e980000 for devices... 6 USB Device(s) found
>       scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0=20
> MMC Device 0 not found
> no mmc device at slot 0
> MMC Device 1 not found
> no mmc device at slot 1
> Card did not respond to voltage select! : -110
>=20
> Device 0: Vendor: SABRENT  Rev: 1214 Prod:=20
>            Type: Hard Disk
>            Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
> [normal boot follows]
>=20
> A file copying error on my part seems most likely. I'll try again
> this afternoon.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 18:36:41 2022
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 4Md4w24ZH2z4cyMj
	for ; Wed, 28 Sep 2022 18:36:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4Md4w149mPz410h
	for ; Wed, 28 Sep 2022 18:36:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664390206; bh=VtOaStH3P5JES+hdv6oik6ficYe3RnWMs6M6gazX75Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=O1/b2ErcD5FNWD5eWOGiRJZIlIYVVSSVTbHtH8y515AP1oVuEDNrcxOpA6KG80bQbrTzSaIAC2bTQTP0wn5XKpR0Nw5gCTwDHva2Mg4IIquR0ydPDDTRH6HVzV3LLQDNZTR8NZ2KXvCH/NEhyWppBB9ZyiCZLksTd5t8Y0/4gBPrl6bf76QRKJLVCIaXZ8x+I/QSntk5snSBDDYlVdpiXYSePWOKk+SjQQVnaoWEwE/h6XXrtSyJTNthv38DDnkJui3/8RhxbzI23py1+JDLS8u9H46ZdgIoGmHhcaLd1KKSMEqqJ0AGu9YDT6zXkiTPLBmCNughbAKjCowtsFNfqg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664390206; bh=Vy+BvwQTCorQzxgh1nLKBYEDYQJAb9rRkmM0WJXJRNo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fmPVN7z+kSoQRO9oIqhW17MraN3hTGPAOevZy9NAwAZ2jfbQUkPYFGoGLGV43MVW64xEaKrJ9ZTus5ryh5v9dqYSkOcYqC15Dzw0afaiQg6dhPNahd6wXoHIKsq/Bp4twkxyO4aqvOCSa2yfquKAftEQBwQXDShi/S5OR7CjOSrKqtBTC72cAyT09UOuaqukQLeM2Wl6IDhiNT+F2LLSDFRM/hw0O+wzlPhTumiCNxLXqoz5TdDta2cy2aHwfkHy/I1AFPw2/x/qkBdRtbopas9dvw54cUAhUG7CoVEPSNuJ9p4ijZC1TZMMJEAMV6gqoZWpHUzwp1rTeCCAIGp4CQ==
X-YMail-OSG: 50jpo7oVM1lnSuEpclGZyl._DK6h.DhRyZgrEMnwvPrst_Q7iBwWlrStX5N6sCE
 rgYu00J.uAzme4DcViy7ZHu9dSRySAauTuAlE.p.bO5xpCSNAs8NDrEcEBlutrFk1yp4vQhlsysA
 Jy0mxPfNXxxiOyoyzy4RecqhE_QbhmaMMqiw0hyySj2wSl.Gk2sRxY_nd8D8.aeOyTlWTBizU2mM
 qG7WMADsQ86Qt4jJDYGmbf1BwJFQL2NYCBlDCZCYzkZ9LWfCC5rm6R4ArHlYEEo3MsshrHwa4rd2
 vPDn1udZ2E3z8wf4BFvWFdlxu.fNLAXijDT1_eQnfTCZqxUKKR4YHRABJCArFPn7DBWBC_Wud4GC
 SET2X9q.I6ByBPi5JTJNkOmbcaERQjCBcM8VP4Q5cqHKQNloPx1TMGMGl9CaFFIsOEWuREMJCz1y
 sAi5Jcpsb5eTYhAYrfpoJbja8OxTW2GemXA4YG1LN_0aZyScuFyri6IVi6X3ekVRDqfqZWsEzhjl
 kT_9tMpBNP.zrX1p1X3P__3inI.XSa3A6VO0FyC_pFlbTZSxQwlXHHt4ilk13txytyZ015wOPZZb
 t7FSyfcJPrtWM3kkOM5WFkUPQ9ZCkLkhRg5IMs2YNMXjHkUnZ1MWiBoTTYm8ZjPxFyhqMvFfNFuu
 xyFrJmp1xCx24EIdjqSWagw5ukCb.DCNzObXpSHIeOndUGk7Y3i4bBm6HWJ1P9xalq1PIYcVPEQ_
 x_qE3VsxArQdm61XMNpfwFTF9igbqyFVwV4lzG4DpxPMjMZKZpW4pNc05ZQtWp1Rx8bl3GWFHp55
 K0ro7K54Is1TFKQX.XhW2.loM2biAYpg4hjiQmKVr8b8Gaf2BduAom9DLOvXDHnKzKAi_MON8dUc
 hnRLjTpFgZIrU14lvYyJrZb4VY9Hg5BkrGVcwQY1yiGdtJWAliyRdeIu81KQx7mVeUQ3cC84MxpJ
 4rXwZFheZp9aOpHLclkJA2swHCryuvWKwcwSnaVNyNa6Ni.ijyfBaNNbp73DfWZzTZYddtt531JV
 .D8HdU8mKmXvfVTbWDC4gSm7ZklKD60M7CHX3cFD9huVykBI38XGK63DP3SMKnk6HFK1DzLCFaz5
 ZFcQrpxUejIND7L_mVwib_K3HMdi66ZK4tssHJKhA6NxYrgFlfvy8iMzocpEkg6mxgknMu3Kk.bf
 0FbfD3CAcZRtTBdZ3IjUViZQJ3NCLL62CSKhUQ5wwEMP1Sd.rM8Q0LUnnJ_LZ2h_yoRDR86pdV0w
 LjIh7NsXdZ3VTsUsz5dDsBXyPPW_DfYGcBslJzXeTUCrhq7Ty4DX5MdeXxQ9WoWQdzCqpNxYRfba
 Am65x45r6zA2THBe1qVwmfpCxvBWUEjcQxrhi1cvdiX.H0i1aFBPIQlyLmUhYUqGdllPCSJhKC45
 mo0yuA6M5Gr36P1V_LW9ZNU5AUbXP13uRjg55J6FAl.iEZMBGBxxSveysjrMDh.SQkNzweQp6bLc
 t7VCBQX22u_6OPpm6L.ViI0LK7o6ipBQJr.7UIUCiGx6veRriV1DxlQ6_i5E3teDHYJSK7fRlDLG
 LahUF4RwTXPga02Td.FsrbzK8dviUMSfy.4TQ3xWpzGBQMZ3xmt1ZFMYLE5I.sTHP4Mw2R.nn33X
 KcQiK5hw4e9d6uZWiuILBatsTL0gHgVQDwT_4.Kiv8p3BW69NhLmPoF_W_UoeGdEwlQbt2_m46cf
 jYQGEX_HG3EJlnoo6ZVcca5P7YN4fwUtl5iGSOnVp5tQdR1BMp4wQd1Z9vKVgN5kR1SLB6mLAdxe
 vVOQGWsEX1mTp728MltnHhK6H4WW_WP8C5ks.RWcfSTDWlIagqD27jYdMyeeT2QBWLWcU6KAfBL3
 vqhqoXM14Rj1eGDPdndTWd3wMnpg1_ZqcJzngmhLE3_GE1fabfy5L9x.atHiam2BGIihQGUDk9jS
 MUuHGI9SSXW9zgGrWhhkgHgZAfl6RleJ7.pda8crFVAYoRx6_QwWLxcbDOe3n6H71dgxBf_cKfSK
 0EUG8D8kKpS6Az6M257yAQyNeK0.46ORK_N2AlataN_L1DjI1fOHy7kShGvqL60yaGKgjKtti_0T
 IOp1unLVQPCRxc2lT5Oa6wkiH4u4i2CfWRtFmn.9jhAYce9v5WZ4p1KM5U3bNJ6zEOIJQPNVdNqg
 Tc_ZGouoHkjzmKft4oMMVO5eCbuAS654y_eZONl8W6_uzcIpTV1W8aYA7rC15z.TrxRHdtf0V2DU
 l7.AbYA9QkmM8aKAmAsk59J..x_MsUjMum6zcytwT87cQFWW3Jn99v8PU0ZwUZjCETT2KNNG0Neb
 NkPsPhCo-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Sep 2022 18:36:46 +0000
Received: by hermes--production-bf1-759bcdd488-v8j49 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d5f7d91b292b0b4205b0d76d9d9c714d;
          Wed, 28 Sep 2022 18:36:43 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
Date: Wed, 28 Sep 2022 11:36:41 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
References: <650FD030-783D-46C4-8CC9-50D608569898@yahoo.com>
 <81C8A094-8492-41DC-A74E-486A9225A2A3@googlemail.com>
 <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Md4w149mPz410h
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="O1/b2Erc";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 10:57, Mark Millard  wrote:
>=20
> On 2022-Sep-28, at 10:28, bob prohaska  wrote:
>=20
>> . . .
>> At the same time:
>> root@pelorus:~ # ls /usr/ports/sysutils/u-boot-rpi-arm64/files
>> patch-common_usb.c       patch-common_usb__storage.c             =
patch-lib_efi__loader_efi__console.c
>> patch-common_usb__hub.c  patch-include_configs_rpi.h             =
rpi_arm64_fragment

A question here could be: was the updated rpi_arm64_fragment
replaced by a copy of the official one so that the additional
3 lines are now missing?

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Sep 28 23:26:17 2022
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 4MdCL63kBnz4YHmN;
	Wed, 28 Sep 2022 23:26:22 +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 4MdCL451hXz3QPk;
	Wed, 28 Sep 2022 23:26:20 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28SNQIHr076991
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 16:26:18 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28SNQHcp076990;
	Wed, 28 Sep 2022 16:26:17 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 16:26:17 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220928232617.GB75564@www.zefox.net>
References: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@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: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
X-Rspamd-Queue-Id: 4MdCL451hXz3QPk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 28, 2022 at 10:57:41AM -0700, Mark Millard wrote:
> On 2022-Sep-28, at 10:28, bob prohaska  wrote:
> 
> 
> If the patch files are in place for what poudriere uses
> for /usr/ports/sysutils/u-boot-rpi-arm64/ , poudriere
> based port building should then work.
> 
I have poudriere set up on another Pi3, you might remember
it from the duplicate MAC caper. I'll try over there once
ports have updated.

> Is there a log file of the port build output that you
> could post? For manual make activity one can use something
> like the script command to also have the output sent out
> to a log file.
>
Yes, at
http://www.zefox.net/~fbsd/rpi3/u-boot/make.log
It contains the lines:
===>  Applying extra patch patches for u-boot-rpi-arm64-2022.04_1 from /usr/ports/sysutils/u-boot-rpi-arm64/files/
No such line 209 in input file, ignoring


I showed the output of find and sum as a sort of audit, hoping it would turn 
out I was manually copying files from or to the wrong place. Since the sums
agree between the stage directory and /boot/msdos it appears that hope was
mistaken. 

Speaking of the MAC fiasco, is USB subject to similar conflicts? The Pi3
giving me trouble with u-boot is one of the two with the MAC conflict.
That might be consistent with the successful disk/enclosure swap.

Thanks for all your help!

bob prohaska


From nobody Wed Sep 28 23:43:41 2022
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 4MdCk34nT4z4YK7x;
	Wed, 28 Sep 2022 23:43:39 +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 4MdCk25tCkz3R9x;
	Wed, 28 Sep 2022 23:43:38 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28SNhgKM077071
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 16:43:42 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28SNhgSR077070;
	Wed, 28 Sep 2022 16:43:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 16:43:41 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220928234341.GA77046@www.zefox.net>
References: <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@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: <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
X-Rspamd-Queue-Id: 4MdCk25tCkz3R9x
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 28, 2022 at 11:36:41AM -0700, Mark Millard wrote:
> On 2022-Sep-28, at 10:57, Mark Millard  wrote:
> > 
> > On 2022-Sep-28, at 10:28, bob prohaska  wrote:
> > 
> >> . . .
> >> At the same time:
> >> root@pelorus:~ # ls /usr/ports/sysutils/u-boot-rpi-arm64/files
> >> patch-common_usb.c       patch-common_usb__storage.c             patch-lib_efi__loader_efi__console.c
> >> patch-common_usb__hub.c  patch-include_configs_rpi.h             rpi_arm64_fragment
> 
> A question here could be: was the updated rpi_arm64_fragment
> replaced by a copy of the official one so that the additional
> 3 lines are now missing?

Yes! The original has size 68, your patch has size 125.

I'll clean up the mess and try again.

Thank you!

bob prohaska


From nobody Thu Sep 29 00:21:31 2022
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 4MdDYj6Y5tz4YNm1;
	Thu, 29 Sep 2022 00:21:29 +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 4MdDYh5zBDz3TbL;
	Thu, 29 Sep 2022 00:21:28 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28T0LW4s077154
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 17:21:32 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28T0LWA8077153;
	Wed, 28 Sep 2022 17:21:32 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 17:21:31 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220929002131.GA77106@www.zefox.net>
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
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: <20220928234341.GA77046@www.zefox.net>
X-Rspamd-Queue-Id: 4MdDYh5zBDz3TbL
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

With the correct patches finally in place there is some
extra output from u-boot:

U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700)

DRAM:  size=30, ptr=5c0, limit=2000: 7ffe3b0
size=8, ptr=5c8, limit=2000: 7ffe3e0
948 MiB
bind node psci
   - attempt to match compatible string 'arm,psci-0.2'
No match for node 'psci'
bind node system
Device 'system' has no compatible string
bind node axi
Device 'axi' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node chosen
Device 'chosen' has no compatible string
bind node reserved-memory
Device 'reserved-memory' has no compatible string
bind node thermal-zones
Device 'thermal-zones' has no compatible string
bind node soc
   - attempt to match compatible string 'simple-bus'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
bind node cprman@7e101000
   - attempt to match compatible string 'brcm,bcm2835-cprman'
No match for node 'cprman@7e101000'
bind node mailbox@7e00b880
   - attempt to match compatible string 'brcm,bcm2835-mbox'
No match for node 'mailbox@7e00b880'
bind node gpio@7e200000
   - attempt to match compatible string 'brcm,bcm2835-gpio'
   - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches 'brcm,bcm2835-gpio'
bind node serial@7e201000
   - attempt to match compatible string 'arm,pl011'
   - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011'
   - seq=0
bind node spi@7e204000
   - attempt to match compatible string 'brcm,bcm2835-spi'
No match for node 'spi@7e204000'
bind node aux@7e215000
   - attempt to match compatible string 'brcm,bcm2835-aux'
No match for node 'aux@7e215000'
bind node i2c@7e804000
   - attempt to match compatible string 'brcm,bcm2835-i2c'
No match for node 'i2c@7e804000'
bind node usb@7e980000
   - attempt to match compatible string 'brcm,bcm2708-usb'
   - found match at 'dwc2_usb': 'brcm,bcm2835-usb' matches 'brcm,bcm2708-usb'
bind node usb1@1
   - attempt to match compatible string 'usb424,9514'
No match for node 'usb1@1'
bind node dma@7e007000
   - attempt to match compatible string 'brcm,bcm2835-dma'
No match for node 'dma@7e007000'
bind node interrupt-controller@7e00b200
   - attempt to match compatible string 'brcm,bcm2836-armctrl-ic'
No match for node 'interrupt-controller@7e00b200'
bind node watchdog@7e100000
   - attempt to match compatible string 'brcm,bcm2835-pm'
   - attempt to match compatible string 'brcm,bcm2835-pm-wdt'
No match for node 'watchdog@7e100000'
bind node rng@7e104000
   - attempt to match compatible string 'brcm,bcm2835-rng'
No match for node 'rng@7e104000'
bind node thermal@7e212000
   - attempt to match compatible string 'brcm,bcm2837-thermal'
No match for node 'thermal@7e212000'
bind node local_intc@40000000
   - attempt to match compatible string 'brcm,bcm2836-l1-intc'
No match for node 'local_intc@40000000'
bind node mmc@7e300000
   - attempt to match compatible string 'brcm,bcm2835-mmc'
   - attempt to match compatible string 'brcm,bcm2835-sdhci'
   - found match at 'sdhci-bcm2835': 'brcm,bcm2835-sdhci' matches 'brcm,bcm2835-sdhci'
bind node firmware
   - attempt to match compatible string 'raspberrypi,bcm2835-firmware'
   - attempt to match compatible string 'simple-mfd'
   - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd'
bind node clocks
   - attempt to match compatible string 'raspberrypi,firmware-clocks'
No match for node 'clocks'
bind node expgpio
   - attempt to match compatible string 'raspberrypi,firmware-gpio'
No match for node 'expgpio'
bind node power
   - attempt to match compatible string 'raspberrypi,bcm2835-power'
No match for node 'power'
bind node mailbox@7e00b840
   - attempt to match compatible string 'brcm,bcm2836-vchiq'
   - attempt to match compatible string 'brcm,bcm2835-vchiq'
No match for node 'mailbox@7e00b840'
bind node gpiomem
   - attempt to match compatible string 'brcm,bcm2835-gpiomem'
No match for node 'gpiomem'
bind node fb
   - attempt to match compatible string 'brcm,bcm2708-fb'
   - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches 'brcm,bcm2708-fb'
bind node vcsm
   - attempt to match compatible string 'raspberrypi,bcm2835-vcsm'
No match for node 'vcsm'
bind node virtgpio
   - attempt to match compatible string 'brcm,bcm2835-virtgpio'
No match for node 'virtgpio'
bind node clocks
Device 'clocks' has no compatible string
bind node phy
   - attempt to match compatible string 'usb-nop-xceiv'
No match for node 'phy'
bind node arm-pmu
   - attempt to match compatible string 'arm,cortex-a53-pmu'
   - attempt to match compatible string 'arm,cortex-a7-pmu'
No match for node 'arm-pmu'
bind node timer
   - attempt to match compatible string 'arm,armv7-timer'
No match for node 'timer'
bind node cpus
Device 'cpus' has no compatible string
bind node __overrides__
Device '__overrides__' has no compatible string
bind node leds
   - attempt to match compatible string 'gpio-leds'
No match for node 'leds'
bind node fixedregulator_3v3
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_3v3'
bind node fixedregulator_5v0
   - attempt to match compatible string 'regulator-fixed'
No match for node 'fixedregulator_5v0'
bind node memory@0
Device 'memory@0' has no compatible string
bind node __symbols__
Device '__symbols__' has no compatible string
bind node bootloader
Device 'bootloader' has no compatible string
bind node clk-osc
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-osc'
bind node clk-usb
   - attempt to match compatible string 'fixed-clock'
No match for node 'clk-usb'
RPI 3 Model B (0xa02082)
0
   - 0 'serial@7e201000'
   - found
0
   - 0 'gpio@7e200000'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm283x_pinctrl gpio@7e200000: set_state_simple op missing
simple_bus soc: set_state_simple op missing
0
   - 0 'gpio@7e200000'
   - found
pinconfig uart0_pins: set_state_simple op missing
serial_pl01x serial@7e201000: pinctrl_select_state_full: pinctrl_config_one: err=-22
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   0
   - 2 'mmc@7e300000'
   - not found
0
   - 0 'gpio@7e200000'
   - found
pinconfig mmc_pins: set_state_simple op missing
mmc@7e300000: 2
Loading Environment from FAT... 0
   - 0 'fb'
   - found
0
   - 0 'gpio@7e200000'
   - found
bcm2835_video fb: set_state_simple op missing
In:    serial
Out:   vidconsole
Err:   vidconsole
0
   - not found
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: 0
   - 0 'gpio@7e200000'
   - found
dwc2_usb usb@7e980000: set_state_simple op missing
dwc2_usb usb@7e980000: Can't get reset: -2
dwc2_usb usb@7e980000: Core Release: 2.80a
USB DWC2
scanning bus usb@7e980000 for devices... bind node usb1@1
   - attempt to match compatible string 'usb424,9514'
No match for node 'usb1@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
bind node usbether@1
   - attempt to match compatible string 'usb424,ec00'
No match for node 'usbether@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
   - seq=0
0
   - 0 'gpio@7e200000'
   - found
smsc95xx_eth smsc95xx_eth: set_state_simple op missing
usb_new_device: Cannot read configuration, skipping device 152d:0583
5 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
U-Boot> 

I've placed a complete transcript of another attempt at
http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-failure-debug-log
For some reason only one usb device is reported found. 

Thanks for reading!

bob prohaska




From nobody Thu Sep 29 00:26:20 2022
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 4MdDgS2jQVz4YPYP
	for ; Thu, 29 Sep 2022 00:26:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4MdDgQ739tz3W8n
	for ; Thu, 29 Sep 2022 00:26:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664411185; bh=B9DQ/e1ZztkvN0kTPCxg5UDAT04vPrCc993ZqT+FpCs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JEMdUYglcR2K1b/MYVPS5wTr0fA7zYelmaLCr4DVJc+50gHihoUg5iJTqxlcHwf5Z9fbKs2nmbv5LokqgYF8vKzMB+89XkLR/BllxIkoLDFZAtP0x32Atwn9E0DBFfnSOJCR84a9eeZRJNo4VbdmM+NybGrZWl9d8YMFke2etaGGqZEAPdEemhxVG0aq4aGcdO6Q41Rp+IxHXiUwfs+XhrX8spcf/olMxlET6A4KrfexIn8SI6UJURKbxHb8K9BqzmU2pEH84t3eDAG0Nv3YzCtm4fjaJqHmvOlGbCa8cCG9WL54ryKLqW7QRT4OTummkBOQzaTocaFNhls/giihGw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664411185; bh=XqkkGdkIopV7VcWkKY1dnSyupvKgCGNVL1/nmMN87yY=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rdnLP/Bxz4omOlNHyyMd6xVmdaL/+yY+58TgZ0e/iG4lfnKZoTtQmIRb6NmkItg7IwDDoPN65ZiBgtrn2l+opL09bTgrwVHLskPrwxiA+O6T0LBXz+XbcDTWftRveRjEJWw9DPB9aSk48sBlJ/rL0Yzqt1dKRHJJ27K6ici+usxB8roT/WNAzer8BjhlHKUmZNaguxcCpIkg2hV7nV2JRxCN559YuLEktaAW2GaAZS4pONGXYnIO/5tFsWQhZ3/UNkuobqF02GNZtfRrOa8HXOOkbVQkS3vewed//RErQ5EolWPcyKMiMcDtWaFlheRlKG6AICcgcRTi1Kk1aJ8TMw==
X-YMail-OSG: V6UyJG8VM1l9d6VZdn.YsswPlefTg.av85HHysJHtb6V1nvWVC67r4XFdR72CuO
 kW.iM9lrtYfQhKcPKKhO3wI3i5b4t.RtMIPrLgKdOHsPCXmeKLXAA8Dk3IuZkshbbul1URo2.Wgb
 a5_DMmhQoFbIBoD2WA2D.bZaJZ2X9zOcaSD8FGZHDAvUxwZEkBW_771gNRxWAA3aZ9OLBtbX3kpL
 f9Xq3kK99VXAY4exUXdebvGO9C0sXGYiPbSoVGBLZodGiLQavw1ik_U6gNgw_on9Sxh.A11tfqHY
 MMSZxPDNfLkXO5TgUgE40yaSEjvhIGjXFM6YOm2ekwIcXJdFeQP1.9e8Wtt4oDlY7iC6dz3jsQ0W
 f3bEZnAvCSlnGG.Uuob_lF8d3D48uUE8kpMOy3hZ7EaLSdyFx357ovCcrbpMepdPmOCNkzuUl1sV
 eNcHglupYDbeAPp5DbN78kK_5ZtAEZgirjlPBm2IiZ6IBgCdEUxxs2X5IAVJ.jI2of5j64htOxVc
 XUlbzrTpcJWIuj.dzYVEK9C5h1yY344MeVB91DjBkVAM.InMPrCG_UlKZAKS8wVxbOF0Ye.bGJpd
 imbPcarMEfMvmGu_xIiekCRucJnROqLi1nop.7lkWkZ4mdFzSPepTjniUCTrZW5la025iNRFPt7Q
 o1EVOpJ_2hvxMhNvxc8g95dyvyVDJ9nMUaJs34mLCMOrykL9ktTsXlpnZLO8Lab6g.ZN40pacDK9
 fUDBOWn2d7YPiW8ohtJivFBI8TW47HdIAHBxfj2CKRVNhLLB4jlKpbIiJVZOaacC7anN40_JgmvZ
 QeltYrJgWGVS2vJ3juZTU13pDec5JeFs2vk.PjExqufbeT7_CPwCkk7IHMnC5nm8zl8vwUsiwooy
 XnpCFbocMsYvx_9ph15L0HHCM7vAbYfIRIRZgO.Trh2z4n3leiqWGCD.KMUxsmVedJTRWqEInzuu
 a_WXU8GuJEaqtF8NjTmclP1KaNgKw4zpGDRDffbaGsVohARMoAmoTIllG.LDcfeZ4yccsXdqhzTL
 hggYYRrr4Fo4IMy7r0zZUNvoiwac5R8cTi.A6arK4eQPyKS237gatExs8o5HFpV5ogwhB8cnSUPD
 8161KuELNDJLEnUfc46KP7idxHQjjz9e9GY6LfW0qpSaXNGb2dgeQNOYF8Aqd5iVjnFPxKces7W6
 lM2tEpZgHbyiK2_r_wT.I7yJQg6bPpInByYIapLNLnWfQTlHKcurLDbzkxIuJ6DB0ReQlO4Pr7yO
 9KZphTkOpX5oLancW2hnaLwOku.vyxHCIlfcctmIBBlSM5Y1i7DBeNwxqsZZaONZIBUrmrcnRXyT
 hpd9W8jtj61OFma0UayggMu.w3IdwB8cHCBH_5S1hzss8wsJknU0QwqZkeEw5Gwr6xuufHzShwIl
 4OOfGvtdqiTQ0BHvKCefyT.4tUdDTl6XWztd7pZp0zOvvPc4Z.2BCKAzx8Fb.2qzb3obXsma4Cdq
 GKwPiQK5Bak0cet5eZ5NdzRayZ2V27QkAE0a62gASkcQLEkmOiQ.lLafyWELlgUFI0FER184_nMf
 t3OCk9EvWmlMG1WNFlfnUVp__bhErEWAqliDKnLA7chL0.0Lrvw81tS2eY.xHImkhyJWx.M43KIb
 76mXdlw08zbR0EPTr7WzJd8iVqlvWnwDViTvlgufSL4r0uI3WEtTf_bAopFvvPd.dF311.qANAhR
 ZfuilJpJG4R4rG4L4EyPZL0sewTE96WkCB7kXPaTKDX0jnOsjSkdX8G7KnHdBbhA_OxCzAo1JYp.
 eW9Kh_c3mM7wh2qYNu7VeZNc5tiVJzZrjrkZfs4Ii8Ou8xwhUFSPMQQGkbnCVMY_FTqYSF1tG25.
 OZ5.E2lNRqwwik3yPmTEyhmmPPnY2kxriPPErp80p6YiD2KqnEz0KO0zGggNmA.xX_4G0svuQ41t
 iSsBbG_.NLw2WtG9Lof99GEONJXD_569sMmZoUzN9UpAGLsR_uoIprP2FdfbPGxGnyf2.9WkrNFI
 LqE3yRpJ7vafPE0cEIHc51VqiQ0b8px5dAwSCVrDdlOoRbNbrOQTKgruHtyhPpdumXF24_FAs9ww
 B7nRLZt6K9yDQrW5QS7lI05cWPP30cgJwoWURy19Y2ytbulT08pbFOCi_b2Mc8ai_RAUcOjAQT7V
 Uad_GyOIz8s9LLh5UqhWoqLhsEYXekc2hneA6B8DsMjgMbgsyS4j7caP57vucsLEXvKT6tar_oNt
 lVLHuuirDOMhrB3uRdPH8FnB1v4BUcFeR3CLC9jmpdzfgezR_cwxVC9U15mI4HNvpDZSf53mHYHh
 .6UHw1SRJ
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 00:26:25 +0000
Received: by hermes--production-ne1-6dd4f99767-pwmjm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6a6097b0f61e93f1dcd9f8ff6729453b;
          Thu, 29 Sep 2022 00:26: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220928232617.GB75564@www.zefox.net>
Date: Wed, 28 Sep 2022 17:26:20 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <760FE9D5-7A1D-40C2-B4CC-E90B300F5B3B@yahoo.com>
 <20220927232930.GC72077@www.zefox.net>
 <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <20220928232617.GB75564@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdDgQ739tz3W8n
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JEMdUYgl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.966];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 16:26, bob prohaska  wrote:

> . . .
>> Is there a log file of the port build output that you
>> could post? For manual make activity one can use something
>> like the script command to also have the output sent out
>> to a log file.
>>=20
> Yes, at
> http://www.zefox.net/~fbsd/rpi3/u-boot/make.log
> It contains the lines:
> =3D=3D=3D>  Applying extra patch patches for =
u-boot-rpi-arm64-2022.04_1 from =
/usr/ports/sysutils/u-boot-rpi-arm64/files/
> No such line 209 in input file, ignoring
>=20

I get the same "209" notice in my builds. It is expected from
the other historical changes in the number of lines in file
in unrelated areas (pre-patch). My (poudriere based) builds
work fine.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 01:03:23 2022
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 4MdFVG4QRvz4cgd6
	for ; Thu, 29 Sep 2022 01:03:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4MdFVF39ZFz3YRx
	for ; Thu, 29 Sep 2022 01:03:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664413411; bh=ZhIBdLhkG3g5BkEUePike5E7Gubr0uB7bc4gRZa0eeE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HsZ0R6nG8phPZy8CumohsatCedhOQi1RIr2dWwI6730P3eqQoGxxnbochhHdUIt3oXbCiDf9EX/sT3Y89flEs29fk1Ifey4bxYVyhgWU+OC8CXOWQsiakd+YzhZ2zQHLh4iMmQeuYseWQgQkshQmdAbRDimlClWPWBJ8/ofXsNmhcy7sXz1doXV9tgyhA/89/FykybOqzsx2WuZanki/fm0cb3NpWABgXscQfaD6D5d0+ZDm4H91Men1nnuYNF138BVQ0GDGDsyb+V7GI/4EmmomD04Paxx8uxxtVopcP2UL5fodC4SNwGiGieH4JJPhxRCVFz4+8KfMXG0PFk9PcA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664413411; bh=BbPt2CucSk6M12NC2WywimHy98Yj+1wr2119WaUps0A=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NyecleDtPwIQmJamIdymeybNuSEblf+8ch/jJvpv2/cBpliAX8jEkM/Wlu1YTmkR6ObR37sj9DLdlkerceHHAQ7t5Ufs7QJxe4yFp+wRAn214NzKTGsI2wqsqjMZc0ry/LzS7D9wyCSQCaiBDaToF0Ty1Ab8kqavLI6XrlYW+hGWXGKWDnDIAfjRoTunRmaW/2FTnAlnIGy5eNNA4CKCujRbnDq3SxGTcvObJcewfFUekBTjLy9PJXAwb7qmUoY+SH1xMEQ9pZ9rQDpHhCGFknd6Y1ka79xEW65hvk4jg+0ZqBYGdeDiks3CC22mwDFT8595zQ2UzD12wux1lZ+Iww==
X-YMail-OSG: 1A9YkfkVM1nJDUiZDfl2d4CKtA2.jKRljahOA_oD.KHs4E4fxacFiA43fpv.1lN
 vbLfyzKGvg7kd4PSUOk4qql_VZ482EihqbUaUUJB0CLzFzKPaPIakXUmMZbMmW3KmCMBo91.jH0F
 wnZ1zvP9.5gGPDvYAGo6IAZbToP4_4wOsGiBMNGNrHtpqoHpaEAGoRdZzF2rIPdYosXI.ckYsLGi
 MtQeJPkKvQhEOocDbyKBsbfrLYkzu.e9t9QVrcTjjoO8WcS5lf6kotNn3c63qytGGkz9R3YuCSbk
 GW8SU._hxw0LZz2yOZjdF4OpUswy9SWq1N_L6LXAuclDL1j4o6OLmedmsRRvGUyoa1C4KI4FI3NO
 vgM1_GIFNzy9FguGgd0CL7pnQSQoiuG5lKIV_kUiFhaClZk..GmhJYwZBg5H.9Y2uBptyOPqvYZP
 oJsQ_m74o9uPZEtyUpALWOpJZN94vqIq3YWsgAvi99z0BuzvdbkjH4HX0tkmpWtzjmXayVavCZaT
 xjuES6R0aZDCj7Ya6H6NUDiiNa_6QcGAzcN__8YJM8YOkisgXWHVSs95DLfVy.RZw8EbEZmTwtS3
 uPb6LFfA3eRgh8fL.L6qXynLWl5p.wsmlI2T.gllxo8yG_W.sdCCRPXb.YJY9Sf0gnEugGHIdBm1
 jl7VWsjDHrJBBTE_YpcDZe.L_9qdjzAia9vctV2.qOEMIyTPdR9x5dkyaiAxdUo3.pMU_qNxeGvY
 Sv3_rBDdMDuMQ55mrG2a5IgJ5YAhME3n5TIbvLsMZIFMUy76vwpSYKF8_..cKffNaB_uZbN8wmOr
 LtLem9T4uZUMtU3Abp41zzhBncfUnSh7_q_m_rgV.juRoPOOGQF1nBFFySyAvRLfXhJRhZdI67BW
 4mA._VoQnyVwgZ7q9MDkWait3oefFEHfOakb0bSemDi8AMaDyKc95yUDG.V7xb63uxwpoQSF1636
 ..JHpkfQ5.WP98pWkaptTLqFhe99DemlgDc1VOuGX9y76Xll0eRBhj7XTNJuxiz.xuyUHosTjRfQ
 9psns.Qfs1uVgQoUGiRcX6VUnJPblWulEDV73I55s6TfVGGcJC5iUF2l8GD6XFy5sm5Ht.32IhFZ
 Dbi9yYYDkLQckQ4fg6u7l5uO5.reKHSJ4SyDJdvfBQWGBGgFNEYOXC0wtB48CVDUb.4VgxvEnqBt
 4UAyFQyCUc5Ys.lLNd2mVLNSS4_4ZgiFYE8Hgide.ZuW6TVj5ulYQBNDLlWk12fd8DtKi69AeMPp
 UCbTnVGVQZ5MOBg2S8sDOAoBak4Hc9.jTROd_q0G1Aw01.9.zAahlcqZTOkHnEvAHsSqhy5k2kom
 uEB83XP256H55d02PiG2dyDARoXN.Cj4ThrlH9cOPF8MhGgtVCvl4kbrPnt5USYEj_X8TofkwRSA
 WLs1XhpvB.4qFUwdROZTJsXM3bhDG5VOF2ZSZoaG_4E8dg8zwywH8IzY4bKtVMXvWggZtKt0HNLz
 EGOpdgVdhmjjO_b1d2CyO3V.DwKRJPACj7vW4bcwPT8B1WZzdf7FrOpGuDccVTOByFrRU5qv9h6t
 o2prU7oH4aLVf4hwgiCr_zWO7DTPWVv5IJrUh1anV8vmGmdku5OPF2ak0Ov0UqLLA0Zlt__XhVZr
 0VzCdFmSORZFhsNHIS7w6hev_MsJNj_YiRH8MZjVEVITDgzhVtMOC0xHYA1YqeiIdynZ5GnUCRKk
 z6SkGYuIoDD9Puho9KZTV.aIzP_C22018aH5xARbpnJ_Yj9sTKDmuhgqkXlYp7ks8jKTNWNVRGB0
 vMsy.tggeqirvnusJhVfu2wGCgHWKVwzxEKPFjMdywne9z1RbNaw0lmXfeocWUwB1IDV3860Mh.V
 QRQO497ts3_Ibg1jY4LhFOwylEmi1x9HBIf4evQbPT2G2mj9ewWlRRvrWdT8CvbDH8_YFQ5mXaxi
 07QbBgtZAS6k4TuXlhZU31GVz7QfUXQeKrl6DiH5ayqHbPpU_KLx1M2wCZb2JXVqYVsdqaLVIKhT
 4VWzgukhBjV.JjRRTi1nnoYLCXNh0S5mO0LrT53Nz5BbJZeTezgm8CdY5TKDyIbGa1RKLeByLBhq
 8rSeVtAHnN3nI1Rr8lm1hm57AAKtEkOxjVcJbNAkK2lXecP4HHAXq.dqEqC95L4r.1JEaJ88YUbD
 PABEMt0N0GCWBQvUhQHMBEgxnJ4JUCLml8PP7oaiDNVtmf8R9EJczuP324UwN4Cy8B2ok4H_eMlZ
 3JcNCxYATwsapP17odGiuHmaQxf_dmaroy3OHqZ6Pc_Ky0KqUwmJD6J5eaxYpDaNpRXWhv8QIpVc
 N_Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 01:03:31 +0000
Received: by hermes--production-ne1-6dd4f99767-hqzzl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b99522133e8d416a7747a54bbdc16078;
          Thu, 29 Sep 2022 01:03:25 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220929002131.GA77106@www.zefox.net>
Date: Wed, 28 Sep 2022 18:03:23 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdFVF39ZFz3YRx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=HsZ0R6nG;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.965];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



On 2022-Sep-28, at 17:21, bob prohaska  wrote:

> With the correct patches finally in place there is some
> extra output from u-boot:
>=20
> U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700)
> . . .
> starting USB...
> . . .
> usb_new_device: Cannot read configuration, skipping device 152d:0583

The above is reporting U-Boot having a problem dealing with
your bridge/drive combination as seen via bridge access,
presuming that I recognize the 152d:0583 correctly.



Interestingly, that message is not from the routine usb_new_device
but is from:


int usb_select_config(struct usb_device *dev)
{
. . .
        /*
         * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely =
sensitive
         * about this first Get Descriptor request. If there are any =
other
         * requests in the first microframe, the stick crashes. Wait =
about
         * one microframe duration here (1mS for USB 1.x , 125uS for USB =
2.0).
         */
        mdelay(1);

        /* only support for one config for now */
        err =3D usb_get_configuration_len(dev, 0);
        if (err >=3D 0) {
                tmpbuf =3D (unsigned char *)malloc_cache_aligned(err);
                if (!tmpbuf)
                        err =3D -ENOMEM;
                else
                        err =3D usb_get_configuration_no(dev, 0, tmpbuf, =
err);
        }
        if (err < 0) {
                printf("usb_new_device: Cannot read configuration, " \
                       "skipping device %04x:%04x\n",
                       dev->descriptor.idVendor, =
dev->descriptor.idProduct);
                free(tmpbuf);
                return err;
        }
. . .

where:

/**********************************************************************
 * gets len of configuration cfgno
 */
int usb_get_configuration_len(struct usb_device *dev, int cfgno)
{
        int result;
        ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, 9);
        struct usb_config_descriptor *config;
                   =20
        config =3D (struct usb_config_descriptor *)&buffer[0];
        result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, buffer, =
9);
        if (result < 9) {  =20
                if (result < 0)
                        printf("unable to get descriptor, error %lX\n",
                                dev->status);
                else
                        printf("config descriptor too short " \
                                "(expected %i, got %i)\n", 9, result);
                return -EIO;
        }
        return le16_to_cpu(config->wTotalLength);
}

and:

/**********************************************************************
 * gets configuration cfgno and store it in the buffer
 */
int usb_get_configuration_no(struct usb_device *dev, int cfgno,
                             unsigned char *buffer, int length)
{
        int result;
        struct usb_config_descriptor *config;

        config =3D (struct usb_config_descriptor *)&buffer[0];
        result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, buffer, =
length);
        debug("get_conf_no %d Result %d, wLength %d\n", cfgno, result,
              le16_to_cpu(config->wTotalLength));
        config->wTotalLength =3D result; /* validated, with CPU byte =
order */

        return result;
}

(I'll skip more nested routine usage.)


We apparently do not have enough output enabled to see the debug
routine's output. We are seeing the printf output.

There might be a way to set the output message levels while at a
U-Boot prompt, up to the maximum compiled in. But it may also be
that we would need, say,

CONFIG_LOG_MAX_LEVEL=3D8

instead of the 7 we are now using.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 02:35:04 2022
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 4MdHWp4QL6z4crxC;
	Thu, 29 Sep 2022 02:35:02 +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 4MdHWn3VpMz3d21;
	Thu, 29 Sep 2022 02:35:01 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28T2Z41q077488
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 19:35:04 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28T2Z41Y077487;
	Wed, 28 Sep 2022 19:35:04 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 19:35:04 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220929023504.GA77327@www.zefox.net>
References: 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@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: <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
X-Rspamd-Queue-Id: 4MdHWn3VpMz3d21
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 28, 2022 at 06:03:23PM -0700, Mark Millard wrote:
> 
> We apparently do not have enough output enabled to see the debug
> routine's output. We are seeing the printf output.
> 
> There might be a way to set the output message levels while at a
> U-Boot prompt, up to the maximum compiled in. But it may also be
> that we would need, say,
> 
> CONFIG_LOG_MAX_LEVEL=8
> 
> instead of the 7 we are now using.
> 

Somewhere I got the idea that 7 was max,
but I've replaced CONFIG_LOG_MAX_LEVEL=7 
with =8 in rpi_arm64_fragment and 
recompiled. It didn't make an obvious
difference, but you know better what
to look for

The output is at
http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-fail-level-8

The warning message "...cannot read configuration..." does not
appear in the new output and the disk isn't found anyway.
That's a bit surprising.

I just noticed there's still no log command at
the u-boot prompt. IIUC there should be. Maybe
another missing config?

Thanks for reading!

bob prohaska


From nobody Thu Sep 29 03:04:31 2022
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 4MdJ9x0qj9z4cvly
	for ; Thu, 29 Sep 2022 03:04:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4MdJ9w04Ssz3hDy
	for ; Thu, 29 Sep 2022 03:04:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664420673; bh=lpzm6r258jhPv3ojS8P04Jo3uIO6FowSJbQ41FUAH3g=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=Wk53gjrhxusWuKSjrsL+LXc4DWDfion+aCUH6lNT4nR4CJ76Zg+Gxbap+xCIIFdu9hTQV+oRdj0w5zBNzZSTWXAwP06oZ/j2EkYUzx0BdQWS3JVfM2QTilLhd5gwJsgK4wtMs1ecYWNdkXsdfNDmiuXilfgXt2Vnd7rjsmirQ6r7NAAZU4OTKaiCpCTdttzgrB7vDABKlahbqanBXRfwZ1fgoEBCRs9Yg2hvf2AypcisS51+Gf7WAr5O0HtV0SLWT6d6ZCRLkJo/GssqqAWRE5cPaaitQPCjshgFBcthPlq/k60r+yZHmLjHIny2vciyUahrYg1+/+/o993HlgNifg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664420673; bh=sY294cJNmcELm52eVhKhRYTSyxaVOzLupCsuEADNpiq=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pi+3jDTB979rE3JoFZJt0s5BlQ6I5J6YsdnlUv/x5girNEL4qxYsyj9+JYoJRVBf/wvIzvDtHRVudZ+bi/r26OLdinlqjB94J5pgdSxJFT6MxiPMNneBnfd54bnbZ/I8mhbaYW3x/0m51T6Pa0j0qL4MpKzbkADdjT8YlUeHb7UuOqnEgKCEKmI9A0TjIFogU/UFZEJ+gDRf4joZ9fwoF0Ev3TUDHcO2vEq23w47zUhSv8GwmRxswJQZzqHeB8ne8l85PCSgJElvHWMgMJD/dencVsfRUyCkNlQXlV1WosBMc25/bx+XRXRYrOolW/iu3RFmgA8d4nTz8WcfHuMvsg==
X-YMail-OSG: J49z6EAVM1mzPQp6UBYkTzJFoNfJdbRFGyI1VQCSJUMKZIFdfNTm7B12nL4qb87
 hOkln7HXRiQxPl4ZoRZU6kpa44G75.fyJHouyFprytUSv88c8DZTi2hnzGihKoKAB5rUivWAhSn5
 RJCMxkVMby2QROsR.a.pwHqjoi7FhT9iwGlQ0xI5N61AmPxZzK8TUsiay1PYGA808seTXqihbTCR
 OaIBmZvAscRC4OPttGS27GbqYjH.tlBEgLoVWQMGpL.8bjjoPUBmXKfjS5q1USmFQj3M3e4tdlp3
 nXMb0rgjE0nlOH4SutU1WwovwF9ZpQXr8XvXew93HCKYkqFcqyfdsWvLZbTS7lbs0CVy6P9dQHQ6
 vBjwvGJzEKLDCyY3uXyKQxB13ZHybV3F_sXb3wBMoNW8pWiiM_XauF5BiG6_gXt862HHItWe8XW8
 QhCUT83dEhoR8.3eiE9pJ3kNVAzC7f8SZ35MmSrv5qLT1nQp.XNwnTIkOCdAFbmiApUNsXC8YQtW
 g0Z9vLVue88DTtY6xaP5RWjRTC.3iioV89xPF0Os.6Mto0u0lfcAZSxGDglmibmiaAb1vjdv4imP
 .BfmpR25XTuWKRNX3eUTRohAo0BnpearFUTy4GIuLetU_3mi.N0zW0CQC1bUMeQPPdZ1MBqMdOP0
 ANuyhTare7lZlQZ7TkDULw7GpdKGxKviEQbX46CIAa_ud0J_DCFzKuLcfNvOscM1WO0Of7cwA4fE
 5XVK0ALbnkRgOe9FZMbEbu9_JwfELzWgircjGkG1ARD3hmOx7.3RgwFjEkuIbiEK7TpC1tk3upOk
 GIl4PwroV.wqekerhjFMN.HohAScVhSCS5Td.qa.6SC_zy8jFMIkr_OtbshaEUCxeCkqCSSZfvhk
 zdZ45TU81Oo64pLcGxwQC40707TBlmqndAD8WOXQtItVlJcvuswRGTPy9FNaJS_rI_eiZd_M2dS3
 qjbRGEnNlh2iUizn8lKRpnXwEp6b1fcD59HWn71tCYSig7ZYjgng.uEpHg1XWXOdk4y3h5mZ110r
 wibpdVDGzFMB2uDrcN0evT1NvJ6oGpydtbpWi2H7sKGNayl0hU.en5xVwDDjS1vKPLA5ZdAU0C08
 NLwfaR_L_unicWZWB1MhXRWq9Rt9uZnwTiPf._hnK4eWDQGaaUrIksISt7Dh12AnAZimsXFNL_j5
 HRcT9oGWTg.FscRcrRlc.7SUCSx5EsTZY5O_A6Et2qikgiPA7RAMe68NaaJrU3XzysIRnfesiOg4
 sk0F0dq8fw2WryxE5Sgd_eskY6gD1bC1zi7ZOVNErQ1DJKWbDq_ZWgJGcwCnQrZzPsACmdLLdl4l
 7zkgz4SgNo.8y7gBKLcjpT9Mr_.QH4Z82dD8mwncIrZA2dkLI.sigrdfpM5W.7ag07L4XPh0uGBL
 9J1gX3j2wfdi6UJdjCgCIMPib.E6.dOZP0KWJhbhhb5b7fEpROyCsIvgpwEddM3YL6SyUTm7YVm3
 iXspzOFKEkUQuq1TZL2vzGmGsXtoQ3396XfEUrFUxx.1T_HmAQLpPfEjmxOFY5zoVb_o3QJv213U
 URs_RpKPerw9rptupyaAoUWJmWaf9dMEew.KBTolGN7TsPV.QVg6bAvNxPPPuf72zJpF9GlhjMkU
 K2KjQ9L4tf0KyoNF1M.MYubnZ2YW1QQg3ZXUAX9Pm42OY7WfM_5K83KDHtf7A0C5ntWvbkUzxTxh
 EnUx80n22n3WaLRzmux6NOOCPAYzzypy4raMpRbSW4xHvsXlH51h9IGOtCs4lkeLv3S9OZqJv929
 7louYVJ_Pc8qbKwKnUX9T.evdGRhh_p_PASkqmEI7DgR3cfcKzBtg05mCdFqyzbtqYW4Pw7Gi7li
 Gr1GYCOP7iPo8mdfJNgrR3crsy9ZdOhDa2nN28MfIdModecSaMhhaFYpfgWtI2UjEUqsnJgWjrHK
 yDq__tGQxfxA_PHU.sqyGaxqlDMc4FSJz0DeNpgMloOskhHmmf7UDYUzzGsn7OOYv2GolQNYhB6c
 qKMe9rjjRjuOmM15A6s9KEAy5N1hwJ9qIfxp3r7AKmPRnCTHwCBqBwPQY2Mm_21JfLPbsDGPODnv
 jh9fFvvwneMimuCdXDZ5NeMRhgGqMhBb8FP2x5QKGr4_tPlhy1qCVb_zy0ZqCWqK3tVUVK3AhuBy
 0yxV6Q.v5p1Ti4uetQ3CttMPiP4nTzMlaEXjnMZJSAzaMHxncUxJFheqQPQvLAuFw_4MZlACM_ol
 SMkj7P3P.M6mMEWWdVLX527RP60P4slOJ9cfqG4gcmW5eSlP4fixSri1ucmCtzQF8Y8t8tcNtBge
 b
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 03:04:33 +0000
Received: by hermes--production-gq1-7dfd88c84d-65ptt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4621a60777e16c24717c8799c8e1c865;
          Thu, 29 Sep 2022 03:04:32 +0000 (UTC)
From: Mark Millard 
Message-Id: 
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8"
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 20:04:31 -0700
In-Reply-To: <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
To: bob prohaska 
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdJ9w04Ssz3hDy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Wk53gjrh;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.978];
	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)[multipart/mixed,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~,5:~];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 2022-Sep-28, at 18:03, Mark Millard  wrote:

> On 2022-Sep-28, at 17:21, bob prohaska  wrote:
>=20
>> With the correct patches finally in place there is some
>> extra output from u-boot:
>>=20
>> U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700)
>> . . .
>> starting USB...
>> . . .
>> usb_new_device: Cannot read configuration, skipping device 152d:0583
>=20
> The above is reporting U-Boot having a problem dealing with
> your bridge/drive combination as seen via bridge access,
> presuming that I recognize the 152d:0583 correctly.
>=20
>=20
>=20
> Interestingly, that message is not from the routine usb_new_device
> but is from:
>=20
>=20
> int usb_select_config(struct usb_device *dev)
> {
> . . .
>        /*
>         * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely =
sensitive
>         * about this first Get Descriptor request. If there are any =
other
>         * requests in the first microframe, the stick crashes. Wait =
about
>         * one microframe duration here (1mS for USB 1.x , 125uS for =
USB 2.0).
>         */
>        mdelay(1);
>=20
>        /* only support for one config for now */
>        err =3D usb_get_configuration_len(dev, 0);
>        if (err >=3D 0) {
>                tmpbuf =3D (unsigned char *)malloc_cache_aligned(err);
>                if (!tmpbuf)
>                        err =3D -ENOMEM;
>                else
>                        err =3D usb_get_configuration_no(dev, 0, =
tmpbuf, err);
>        }
>        if (err < 0) {
>                printf("usb_new_device: Cannot read configuration, " \
>                       "skipping device %04x:%04x\n",
>                       dev->descriptor.idVendor, =
dev->descriptor.idProduct);
>                free(tmpbuf);
>                return err;
>        }
> . . .
>=20
> where:
>=20
> =
/**********************************************************************
> * gets len of configuration cfgno
> */
> int usb_get_configuration_len(struct usb_device *dev, int cfgno)
> {
>        int result;
>        ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, 9);
>        struct usb_config_descriptor *config;
>=20
>        config =3D (struct usb_config_descriptor *)&buffer[0];
>        result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, 9);
>        if (result < 9) {  =20
>                if (result < 0)
>                        printf("unable to get descriptor, error %lX\n",
>                                dev->status);
>                else
>                        printf("config descriptor too short " \
>                                "(expected %i, got %i)\n", 9, result);
>                return -EIO;
>        }
>        return le16_to_cpu(config->wTotalLength);
> }
>=20
> and:
>=20
> =
/**********************************************************************
> * gets configuration cfgno and store it in the buffer
> */
> int usb_get_configuration_no(struct usb_device *dev, int cfgno,
>                             unsigned char *buffer, int length)
> {
>        int result;
>        struct usb_config_descriptor *config;
>=20
>        config =3D (struct usb_config_descriptor *)&buffer[0];
>        result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, length);
>        debug("get_conf_no %d Result %d, wLength %d\n", cfgno, result,
>              le16_to_cpu(config->wTotalLength));
>        config->wTotalLength =3D result; /* validated, with CPU byte =
order */
>=20
>        return result;
> }
>=20
> (I'll skip more nested routine usage.)
>=20
>=20
> We apparently do not have enough output enabled to see the debug
> routine's output. We are seeing the printf output.
>=20
> There might be a way to set the output message levels while at a
> U-Boot prompt, up to the maximum compiled in. But it may also be
> that we would need, say,
>=20
> CONFIG_LOG_MAX_LEVEL=3D8
>=20
> instead of the 7 we are now using.

7 vs. 8 was not the issue.

I had the:

#define LOG_DDEBUG
#define DEBUG

lines too late in the 3 usb*.c files. Moving them to
before all the #include's in each leads to getting
all the debug output too, at least if I set the
default level to do so.

But if it gets far enough to make use of the USB media,
then it reports, for example, every usb read via output
like:

usb_read: udev 0

usb_read: dev 0 startblk 87878da0, blccnt 20 buffer 381a1200
read10: start 87878da0 blocks 20
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 87878dc0, blccnt 20 buffer 381a5200


It is a rather large amount of output (after the failure
point you are hitting). The output messes up the loader serial
output. The EFI loader loading the kernel is done via
U-Boot services and so all those reads are present. Once
the kernel is active, U-Boot is not and the serial I/O is
back to normal.


I've included the updated usb*.c files and the rpi_arm64_fragment
update with an extra line explicitly for setting the default
log level.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
	filename=patch-common_usb__hub.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb__hub.c"
Content-Transfer-Encoding: 7bit

--- common/usb_hub.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb_hub.c	2022-09-28 19:08:42.261977000 -0700
@@ -16,6 +16,8 @@
  * (C) Copyright 2001 Denis Peter, MPL AG Switzerland
  */
 
+#define LOG_DEBUG
+#define DEBUG
 /****************************************************************************
  * HUB "Driver"
  * Probes device for being a hub and configurate it

--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
	filename=patch-common_usb__storage.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb__storage.c"
Content-Transfer-Encoding: 7bit

--- common/usb_storage.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb_storage.c	2022-09-28 19:09:02.566277000 -0700
@@ -20,6 +20,8 @@
  * FreeBSD.
  */
 
+#define LOG_DEBUG
+#define DEBUG
 /* Note:
  * Currently only the CBI transport protocoll has been implemented, and it
  * is only tested with a TEAC USB Floppy. Other Massstorages with CBI or CB

--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
	filename=patch-common_usb.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb.c"
Content-Transfer-Encoding: 7bit

--- common/usb.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb.c	2022-09-28 19:08:34.423048000 -0700
@@ -16,6 +16,8 @@
  * (C) Copyright 2001 Denis Peter, MPL AG Switzerland
  */
 
+#define LOG_DEBUG
+#define DEBUG
 /*
  * How it works:
  *

--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8
Content-Disposition: attachment;
	filename=rpi_arm64_fragment
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="rpi_arm64_fragment"
Content-Transfer-Encoding: 7bit

CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
CONFIG_RPI_EFI_NR_SPIN_PAGES=2
CONFIG_LOG=y
CONFIG_LOG_MAX_LEVEL=7
CONFIG_LOG_DEFAULT_LEVEL=7
CONFIG_LOG_CONSOLE=y

--Apple-Mail=_F4C37AD8-1917-4C76-8895-153697F7FFD8--

From nobody Thu Sep 29 03:11:33 2022
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 4MdJL65Nq2z4cw81
	for ; Thu, 29 Sep 2022 03:11:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.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 4MdJL54BmRz3hdB
	for ; Thu, 29 Sep 2022 03:11:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664421100; bh=65VkeCmF2GRLmoLDD86VtP2aCCyjLeBpuTfm6JbMf1M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fMm4vbfHa0nR7K3oZy5zXYfQm50apxJH5L+RvsMCl3s90jT5dWhNwTnYNhuJioUVpUtFY4gTqJwf2BPh+sbvnDFybrbYkkId/aAE5dErFyAAkmJJdvmO4iiNbZtdzfxGehvIVkSGCztc+EhlBmnRiH1JXZKKOd+BNLwynVXNnse+UtlByfa8ANku6tfxmc7PAlYLIPVpxvXQlvUbuO/7bNZ+uw9gEOSDjpsxmBhfC1sFUriZUV8GJi/Q6nMDZdaiX0zXHQbZuTxdFTiZ+XGVSJWakGQ3sBdTqXlVyKjk2mvAe7WR3TrgCom6sYJ7VLs2TTEiZJF1HXCCebGK4yvr1A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664421100; bh=vEhTXMgQcOugT1oWUrvargcnyxzKdC4Or7KXjL5Pgt8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dLGj32Vbs8KyyAaCgU+5/qPmAy/lDKFrS04QFDpxW41PqTgxdRg1mZuQbmqOtqMhBA5+idkYDBR6Rn6HbCIQErKHD0aMT1DLxagAP752DBeT+u785E+TRsmczVNKjE7HP+/FpD6QzxaqXskNdCu+uzjmkoVgru3xUz9iKkzJnmm3rQGrzU8ejtdILtn3dXXxNB2EkvIcoTIri4Vm+dmnDc9Mpoq7ajDH1wY8XffRIL8gg0DdpoficKTQpg7MqAuVb2eHqw9T+rn6hC0PXKz9jp5zeHBFA+o4CtUmy69OhJqyNCpQSyYK/QU1Yj13YgZj1zVG14+BhUIjpxSTbngyGA==
X-YMail-OSG: w8DdZ0MVM1mZHeZfkAfSpO9_pwxz32O6N5UhYEW7vl6rqEofZUrCayBymE5OutV
 SLD4efjrUmv.Kax5dSyEb6h1uBRPM9wpIKGZpVpenXVg9RGQljDmemzexpOwCy8P6lE8LpI2j6QH
 9UTdOIkFZBaFq8FXBPveu6k9kLBotFiis4jV7k2MSTWLkPuECp3pVAGOpFlebxE0cnLc3PlGJxeg
 9w.yDZkrzQtu4.vLauQ5nQ08zz.kEWs41kF3Ll0dvwxfqjzHMXNvXE4.FS39SqBd2qgHnNI5_.el
 53EKuLy6EILGP6MmEcZHWxBMgCGTLxXuQRcuengxAbXqtJ4t.e2mPC1CqqcmnX64.CdRtXNeOtpq
 PvMlefkf4TSSZKnJX0F7nGRx7Rw54jM2u5k1I2ioy7vief3sjgBy24jrLGoC.lCsYAqDR9I5CdOc
 A7Dv74s6y.KSylKgJI8MRFt0giQoFWRjbB9CXMpjWi4Ptr64RqsaSQFa2cD0wIbOC4QbMgQlt3CU
 TDjb9g9E9uQmwPKfGK0MB0rNohgRVHCHVfERVdAvAmIqTYa76ZZKFY5geyPafv_QPAYf_VPxgXxB
 Sdj0XrRyWk9VQkpqwaFz3vgFl8_QN2bI0pgXRjTzcScDndShTKTHaQizVeJ8h2xfyW8oFrv_1F5.
 U2qZOB1r9MISQlyJi2JuhgEhl_MvFvHWQf4CQ6gCcyM_mvA.p3LOYonkpWo2tVVyboBPaNKb3Vu.
 Pyaa_eDJfaHrNME0dDvuq9LcFeiE53Rl4X_b04R7V32My9vjUxxEsiZK_2cMdzCO.D372IXdhqoq
 52FZTa69AZ.5uCIyfmzvdjkvH35dgDZtv1vLXNJiIVungfTpS1NVjiyMFOKJ_.a2r.TS2zSl.c3L
 Bnb8Su09hTS4nUHqPnbu3V8a5mVTEtxvtMQCjHsO2gdcPpfDkxn5TYBvLMjcvEZsBeUnWkN.6XMN
 ovcO099akh_yH..wqnKRsmOA5Nk_EPSgHccoU0MFlfpIl7WE5Iq1MXZeTb0Xu_3uIDsWFte_v7OK
 ZealmeG_Ovb_dzrTONe2zw76Aur1wWZWPL7CaCELTm26LkkKv6fiMtluxBufZZApdHNziVASdJc1
 2S85RbUTt2SkZly.8nK3SweDU2j_2Ie_c3HSOjJ0JCl_nymCO8f13x7Kc6eYi76jil0btPgEcGYf
 BCFtvNhncCx89CSDY3JkZNDkEOAMU.FvQZe4JwJcReWu1yyph4_7290d3FfItSq9pLB_1Pmtugz0
 Hz5cWacQZ7FrtVg5mHqgRFMyi7SHnfn_i58CcSWWWs2t97f8aoPvZCKWSrU4MwykUd7ZJmFq05nY
 .OHTat6ooD1sCHxBCGDFVrhCPwQklcmF9piIP80DFfNLWifB7xADs2tf5ebKEfssU_emWJa1NBd1
 EvBOxCd_ftnZWGQS8T4DaX4JB0L6hmvpDKqxIR_Ig.iTIlUWXz0EJua9wmRLn_5NLn9o.V77BhWV
 5PkogtFV9cJKHh.3TNE98V7vpafcNIYBtayMKBjSb2qaEImW2Q28e1UDBNJ651yzK8CSEI0ORuAR
 q8LPpwnDi60sUtBWLb6RXyDV0RPTFNqSedmfH8ixza92n84pUSqjGvUWdr5zEounfOeWkBWOjvHo
 PFdD_lpGlx3QJJ6FmrtXq5MBvHfEw9XimPtBeKodd2JcAQh5u57S64dYyWEFbILmkmBZ6qxT4CIy
 YKDfWZYhW7r64VKQFcLN.ufgtnb7sbiRJjDE7BnAs2VH53AS5ouqivggmlmyQ8jsvkkLvAZo45P0
 RzYFAfCtTuhAlVYFi.qavFlfvhxi0DQEDzuqwDQ_8gV9kpY.XTBOT7YUKDTXyG_NvPPYo4doYFWB
 ylja7vMLGnrTHVsJROnZCfMAN8E_FWn_YUag26gw3K5Qydl2HlVDBi9YMY52DQkIE4uzZ.6n15gB
 WXsKRAMy9BP2oiQ4Ra57qVXF3XL7KAhQQdtFmOis7MbnZ0lN2IRKRc2NpjWxewCQp1OyNfKzPiCl
 KmMJzqCWtaEMim6WU_E1t0g0bI4HQRSbm_AUMRf_5N5mwm5TRWk3Ck1tDb7icoZ4OZvyFlr58Y1J
 3a3WUcnsDWRdGC7EBs6sIuktjlb2YQ7I3kBYMyzD5O0LazdGw2Nc1x1nkdZdb4cz8Mt6RMEui9Jj
 RaTr3HfAQdWtm2XgMN9hTw_mtbJ_8tfJOcp1qM7n607yT4extEZD5tMomfEI_OB4xr0tbG0NFczp
 0OXPq7D._nrp_IpSKcD7H6JTCaNIXofAVDzB98eh5d4Rrry6FA3EQHIto0wEKJazNFHYMBJtCn_L
 4
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 03:11:40 +0000
Received: by hermes--production-ne1-6dd4f99767-wffr5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9aba3affc29c588ffdeee6a2d1127e1c;
          Thu, 29 Sep 2022 03:11:34 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Wed, 28 Sep 2022 20:11:33 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdJL54BmRz3hdB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fMm4vbfH;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@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.986];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

For reference, just "starting USB" through "Hit any key to stop =
autoboot":

starting USB...
Bus usb@7e980000: 0
   - 0 'gpio@7e200000'
   - found
dwc2_usb usb@7e980000: set_state_simple op missing
dwc2_usb usb@7e980000: Can't get reset: -2
dwc2_usb usb@7e980000: Core Release: 2.80a
USB DWC2
scanning bus usb@7e980000 for devices... usb_control_msg: request: 0x6, =
requesttype: 0x80, value 0x100 index 0x0 length 0x40
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 =
length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 =
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x19
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] =3D 2
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 =
length 0x0
new device strings: Mfr=3D0, Product=3D1, SerialNumber=3D0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 =
length 0xFF
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index =
0x409 length 0xFF
Manufacturer=20
Product      U-Boot Root Hub
SerialNumber=20
bind node usb1@1
   - attempt to match compatible string 'usb424,9514'
No match for node 'usb1@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
usb_hub_post_probe
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 =
length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 =
length 0x9
1 ports detected
ganged power switching
standalone hub
global over-current protection
power on to power good time: 0ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 =
length 0x4
get_hub_status returned status 0, change 0
local power source is good
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 =
length 0x0
port 1 returns 0
pgood_delay=3D2000ms
devnum=3D1 poweron: query_delay=3D2000 connect_timeout=3D3000
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
Port 1 Status 511 Change 1
devnum=3D1 port=3D1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 511, change 1, 480 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 =
length 0x0
usb_hub_port_reset: resetting 'usb_hub' port 1...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 =
length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 503, change 2, 480 Mb/s
STAT_C_CONNECTION =3D 0 STAT_CONNECTION =3D 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 =
length 0x0
set address 2
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 =
length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 =
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x29
get_conf_no 0 Result 41, wLength 41
if 0, ep 0
if 0, ep 1
##EP epmaxpacketin[1] =3D 1
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 =
length 0x0
new device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0
Manufacturer=20
Product     =20
SerialNumber=20
bind node usbether@1
   - attempt to match compatible string 'usb424,ec00'
No match for node 'usbether@1'
0
   - 0 'gpio@7e200000'
   - found
usb_hub usb_hub: set_state_simple op missing
usb_hub_post_probe
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 =
length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 =
length 0x9
5 ports detected
individual port power switching
part of a compound device
individual port over-current protection
usb_control_msg: request: 0xB, requesttype: 0x1, value 0x1 index 0x0 =
length 0x0
TT per port
TT requires at most 8 FS bit times (666 ns)
power on to power good time: 100ms
hub controller current requirement: 1mA
port 1 is not removable
port 2 is removable
port 3 is removable
port 4 is removable
port 5 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 =
length 0x4
get_hub_status returned status 0, change 0
local power source is good
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 =
length 0x0
port 1 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 =
length 0x0
port 2 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3 =
length 0x0
port 3 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x4 =
length 0x0
port 4 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x5 =
length 0x0
port 5 returns 0
pgood_delay=3D2000ms
devnum=3D2 poweron: query_delay=3D2000 connect_timeout=3D3000
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
Port 1 Status 101 Change 1
devnum=3D2 port=3D1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 =
length 0x0
usb_hub_port_reset: resetting 'usb_hub' port 1...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 =
length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION =3D 0 STAT_CONNECTION =3D 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 =
length 0x0
set address 3
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x3 index 0x0 =
length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 =
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x27
get_conf_no 0 Result 39, wLength 39
if 0, ep 0
if 0, ep 1
if 0, ep 2
##EP epmaxpacketin[1] =3D 512
##EP epmaxpacketout[2] =3D 512
##EP epmaxpacketin[3] =3D 16
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 =
length 0x0
new device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0
Manufacturer=20
Product     =20
SerialNumber=20
   - seq=3D0
0
   - 0 'gpio@7e200000'
   - found
smsc95xx_eth smsc95xx_eth: set_state_simple op missing
usb_control_msg: request: 0xA0, requesttype: 0x40, value 0x0 index 0x108 =
length 0x4
usb_control_msg: request: 0xA0, requesttype: 0x40, value 0x0 index 0x104 =
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 =
length 0x4
Port 3 Status 101 Change 1
devnum=3D2 port=3D3: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 =
length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x3 =
length 0x0
usb_hub_port_reset: resetting 'usb_hub' port 3...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x3 =
length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 =
length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION =3D 0 STAT_CONNECTION =3D 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x3 =
length 0x0
set address 4
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x4 index 0x0 =
length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 =
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 =
length 0x55
get_conf_no 0 Result 85, wLength 85
if 0, ep 0
if 0, ep 1
if 0, ep 2
unknown Description Type : 24
04 24 03 00=20


if 0, ep 3
unknown Description Type : 24
04 24 04 00=20


if 0, ep 4
unknown Description Type : 24
04 24 02 00=20


if 0, ep 5
unknown Description Type : 24
04 24 01 00=20


##EP epmaxpacketin[1] =3D 512
##EP epmaxpacketout[2] =3D 512
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 =
length 0x0
new device strings: Mfr=3D2, Product=3D3, SerialNumber=3D1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 =
length 0xFF
USB device number 4 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index =
0x409 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index =
0x409 length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index =
0x409 length 0xFF
Manufacturer Samsung
Product      PSSD T7 Touch
SerialNumber ***REPLACED***


Probing for storage


USB Mass Storage device detected
Transport: Bulk/Bulk/Bulk
Endpoints In 1 Out 2 Int 0
usb_control_msg: request: 0xB, requesttype: 0x1, value 0x0 index 0x0 =
length 0x0
usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 =
length 0x1
Get Max LUN -> len =3D 1, result =3D 0
 address 4
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 6, Response Data 2
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xaf88e0e8, 0x00020000
Capacity =3D 0xe8e088b0, blocksz =3D 0x00000200
 address 4
usb_stor_probe_device: Found device 000000003af68f20
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5 =
length 0x4
Port 5 Status 100 Change 0
devnum=3D2 port=3D5: timeout
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 =
length 0x4
Port 2 Status 100 Change 0
devnum=3D2 port=3D2: timeout
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4 =
length 0x4
Port 4 Status 100 Change 0
devnum=3D2 port=3D4: timeout
4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 03:31:12 2022
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 4MdJmn63mjz4cy5M
	for ; Thu, 29 Sep 2022 03:31:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4MdJmm73Zmz3kdM
	for ; Thu, 29 Sep 2022 03:31:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664422279; bh=cyGhQOLIdzrN3clOdkJj7UnVKQKgA9h07bvSfWJFK5g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p5iy6l1jGmtmcBsMwhZxBm9K83EX78o0DBtnI0p3aANVXAVK+vpCQJbieQC+ERMaVgXI3VyFFrWf4UvAhtx7DSV9CYYfh1+JpVKNjyDgt4PxgWW1o9SScpK0g4Yw3p2nE1BbqCm8dbHGKzL0rqj6tSnRdXoDTff3DHGeiycbMUPJCN0GYmlgkcz7ddWfgtz4+KTTTpbrBU3lwv+OnKA0qamLmPVfAJwlZYdZUIIeD/rTpvxNQsgHk/DpaU0Zw6KpiJzgy2kTCMxFE8PaE4NObVuLMmCilYPTwWbJoDKOJUFxIeJw4yKkjpaYgYmBXUNKnW2K7N6mMMLc0HOULRimrg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664422279; bh=Ip+zpfjwnoJyMPNsr0cl89dfiHYp+zWmLRTWrHc+nKf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Kum4ZmPh8lh+I34pXChO8SxtDbosaFWj/EtAMfCavE3VZUh0owPmHBE9hXdiZ/Iw6Ep4yxxqN6wYSoFFIfNOo/+RlBcJNDuwdYffooW0sWOjc5DV6wnDfIhDsmEdQ+pDM+6HXg4fQ9Na63DRtUU9UT3tma/JpasW1t0rvj0RJHLY5jB+vUWb5wZhWp8g8NfoMwOv68MhPRBr1MINPm9rtRuGqxEEHaIY7vnF4AiFju09az84HPkKnzSPwbiAU3MYgqN8+fF7XK+OpNFAjLNx5FJPRN+u31ExleoXwFJkijNpnatK5bml2+rWW3wse4xNdUsy9joUh+kvuQT0CeT3Xw==
X-YMail-OSG: E8WCe4YVM1lnryw3.SuSHt3rP3VPQvxqP0Bh1V8loJ7CiBeueIB69s8cP2fUQSx
 pofKiHkz9GWJWHZdUY4CWmuJDmR5plOvNaIdFQiZNpktNIjr7Yzu09J0oCNEj4BY8nASPETsuwWo
 NVCI8lC7PDiJ24I8UGTR8Ywm1XKa1OUl8.CMmSoWhTjBDuIxx90aHGQ7kCu81jgcjCbNGoUHxHvJ
 r3Umx8zYg2LcGmzPG48vAOMgd38aER8kbQG1ON168mR2NLItYeVLSPfjuxOegIZVlovn4wGiIXiV
 P3yI88GInD8b0LxQ_95uGAXoeFx9XroHuHhZ_0sQAoNxXC7.RwaWf7x4fs93.P9iIbT53FgAkmVm
 p2nP9F6vPX9ftYRj5Q9aOesdI8bJhU0wtqTQ4ePxVbEfFT_Xb5p4puMwF5aOJZ_RdsHoCB0syg2p
 Zd_W4tfgkTXix5wwx93QRu9F4G.N8VieBD4sqECOa1AHldAVizJZtwo3XvT.12sTgLsGsvbAmsT1
 X3UqO10tMXsu0XpgBsetZylt81U516pVte4tgJQvBfhgTlSBR4gLhH8E9br.WFI44EBbM2bmdHJI
 4hnIHYoF8TsKGLOWzStDlTuso9.d37Sr06XGEE5q2zd11Uu08jz7Ww6x2Qjl940F61ioHj8Uni3d
 63uj289yotAZOxBgFPxESS4U9dyvisvSN3xWvjJkOyJUSF9AQF7kadvPN8pcGNkYCUSDA8Xi.fZo
 AoEcC5Es9etf_ffhzdKHguiALG3bqt1YAMu5Mtjlavqyuz7M0GU3tD9ThjTDxH6waATrrTtq7RA0
 hOGGm5jjDThUdPPQ_eosYh6GJOzJyYVs9JNZVvHbgqZGKWJQsi4WH4w5qSvHZSVHUv1H60u.B8To
 AE4t9VNqdjjxUfkCT40AL0OsU9Umf.Vpqj7iRZDgUCoAMoxYKrfeLF.ppMGrLD8g1i8MJu5fL2LB
 Vn7lYN9nEjIEHGrOB_iS.ryFlkhm2PvDPy8j_6P0Q6yIrBiCY0nyio2xjXyJ_iHkixfL6A3NxyhB
 hlMJCQUySOa22Qw3Kns_sYwqakbZZ8zQoLoruKBIi9hkXBBJRhTx88UbW1.9Ac8kHRqwxy8si5g7
 CotbIlslxv2wwFpq.pZ55s_0iEtTwAre7Ur44BdS5_MDeLHlV6oMMovrUHzO4O1MESiVB1xg_ywR
 Us1ApzmGCtJAJ0p6Rq9hTxbCq7GBLPMUIFR_.lgkPPgf5M1RAimeLNofdt.ZAclDBwOnpIrpYsXX
 ueK93KNvDqNL7jVBepM0vscledSFCfM.2RoSgYu6i65dLdfLBZZyumITnwdQ1s2IIQUx1tZI4nZL
 yA51t.v4_1.363c7oEMFGPGC5t4dGvWrImqlvbAkgO7gZ6bWqWb3n0vq36P9q8uBxe1W.ojdwdM8
 egua7tlfEkHHUjfAXnQznHyS4sVQ0u3kSO3hOeb9QYtW6RlBCUEVnnza_ArS3qHW8UU64L3nkW8C
 9EUjTkDuTqF90OiSXZB0YX7Rfzdq4wbUoN2dVBX7JG0fyE_Sg_SJm3bp1kZdl7kdg4zh1mTddnjU
 h1.7uBqF7_KAqcPBI9EaP2SUl7OD7JCqcPWoXy1kx9mNbvRVGBrQq.Gb45fvtzST5LJouWvI8M0w
 TX.O4sHWCjZ8hIn2u6Ekkr93Ro6ZKU0v6Nt0r58uQWqhNLm4SavTuGOP9KAQEHGWmqalmkTNp1mf
 sS8Ao1sGCwf4XoO5fKkEG5qaOXORcuT1j1Vuja6zOo4WyAnYmhto03VwYFLeGC3ZAXnwlFU9YH16
 YPdNqmYXcvp4MPuD6YQKHuQOxNijABNrYXnBkULVRIzFBq5BQscnEauDF8jxsQRwSEX0QdxcDotn
 50eT2hzv6Q1UpeufWutrQlJh_X1Oe8As1wMeu_pGK7YuKyOXCVvto5_vCjBtLJEHmzoBUcgdpgPh
 TqpH_kTr.zUf5BE8IVCYJAAXOjMIOK0gJRhjl5o6QtCUC1bSEuKbTS5g824LIXWReaYxn9nY2ltA
 LC85QrHCvSA3Wx.OQL1RfSbAT06alo5MCIGPeE1aLIYnTzY13l9X9M6PszDy6mMhZ7Zv8TZt8M8i
 lbST2M__hVNPuJE3_MhV4bsRwzjsn6Dl1fcXqi8aZyMLmlRrGK9HlCvSR_acjP6b7.T8J738gp8x
 nnyvWlVlycBL4oCQBmrv66xBU4xLMlUSQ9DlqKxtc32rv3TX2PCAepdyblQWQlwvjjs3_awJfqLx
 PTBWKNGtyjF3DhmXB.6WU.UqLSG3xvudvale6K2DNAY7nOWof3FX2kRRtalHFVqlVSzO_zIF.3J9
 Vm.Q-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 03:31:19 +0000
Received: by hermes--production-ne1-6dd4f99767-97ndb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5a79aca97780e9efbe5897450ed11a14;
          Thu, 29 Sep 2022 03:31:14 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Wed, 28 Sep 2022 20:31:12 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdJmm73Zmz3kdM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=p5iy6l1j;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.43 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.93)[-0.930];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 20:04, Mark Millard  wrote:

> On 2022-Sep-28, at 18:03, Mark Millard  wrote:
>=20
>> On 2022-Sep-28, at 17:21, bob prohaska  wrote:
>>=20
>>> With the correct patches finally in place there is some
>>> extra output from u-boot:
>>>=20
>>> U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700)
>>> . . .
>>> starting USB...
>>> . . .
>>> usb_new_device: Cannot read configuration, skipping device 152d:0583
>>=20
>> The above is reporting U-Boot having a problem dealing with
>> your bridge/drive combination as seen via bridge access,
>> presuming that I recognize the 152d:0583 correctly.
>>=20
>>=20
>>=20
>> Interestingly, that message is not from the routine usb_new_device
>> but is from:
>>=20
>>=20
>> int usb_select_config(struct usb_device *dev)
>> {
>> . . .
>>       /*
>>        * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely =
sensitive
>>        * about this first Get Descriptor request. If there are any =
other
>>        * requests in the first microframe, the stick crashes. Wait =
about
>>        * one microframe duration here (1mS for USB 1.x , 125uS for =
USB 2.0).
>>        */
>>       mdelay(1);
>>=20
>>       /* only support for one config for now */
>>       err =3D usb_get_configuration_len(dev, 0);
>>       if (err >=3D 0) {
>>               tmpbuf =3D (unsigned char *)malloc_cache_aligned(err);
>>               if (!tmpbuf)
>>                       err =3D -ENOMEM;
>>               else
>>                       err =3D usb_get_configuration_no(dev, 0, =
tmpbuf, err);
>>       }
>>       if (err < 0) {
>>               printf("usb_new_device: Cannot read configuration, " \
>>                      "skipping device %04x:%04x\n",
>>                      dev->descriptor.idVendor, =
dev->descriptor.idProduct);
>>               free(tmpbuf);
>>               return err;
>>       }
>> . . .
>>=20
>> where:
>>=20
>> =
/**********************************************************************
>> * gets len of configuration cfgno
>> */
>> int usb_get_configuration_len(struct usb_device *dev, int cfgno)
>> {
>>       int result;
>>       ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, 9);
>>       struct usb_config_descriptor *config;
>>=20
>>       config =3D (struct usb_config_descriptor *)&buffer[0];
>>       result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, 9);
>>       if (result < 9) {  =20
>>               if (result < 0)
>>                       printf("unable to get descriptor, error %lX\n",
>>                               dev->status);
>>               else
>>                       printf("config descriptor too short " \
>>                               "(expected %i, got %i)\n", 9, result);
>>               return -EIO;
>>       }
>>       return le16_to_cpu(config->wTotalLength);
>> }
>>=20
>> and:
>>=20
>> =
/**********************************************************************
>> * gets configuration cfgno and store it in the buffer
>> */
>> int usb_get_configuration_no(struct usb_device *dev, int cfgno,
>>                            unsigned char *buffer, int length)
>> {
>>       int result;
>>       struct usb_config_descriptor *config;
>>=20
>>       config =3D (struct usb_config_descriptor *)&buffer[0];
>>       result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, =
buffer, length);
>>       debug("get_conf_no %d Result %d, wLength %d\n", cfgno, result,
>>             le16_to_cpu(config->wTotalLength));
>>       config->wTotalLength =3D result; /* validated, with CPU byte =
order */
>>=20
>>       return result;
>> }
>>=20
>> (I'll skip more nested routine usage.)
>>=20
>>=20
>> We apparently do not have enough output enabled to see the debug
>> routine's output. We are seeing the printf output.
>>=20
>> There might be a way to set the output message levels while at a
>> U-Boot prompt, up to the maximum compiled in. But it may also be
>> that we would need, say,
>>=20
>> CONFIG_LOG_MAX_LEVEL=3D8
>>=20
>> instead of the 7 we are now using.
>=20
> 7 vs. 8 was not the issue.
>=20
> I had the:
>=20
> #define LOG_DDEBUG
> #define DEBUG
>=20
> lines too late in the 3 usb*.c files. Moving them to
> before all the #include's in each leads to getting
> all the debug output too, at least if I set the
> default level to do so.
>=20
> But if it gets far enough to make use of the USB media,
> then it reports, for example, every usb read via output
> like:
>=20
> usb_read: udev 0
>=20
> usb_read: dev 0 startblk 87878da0, blccnt 20 buffer 381a1200
> read10: start 87878da0 blocks 20
> COMMAND phase
> DATA phase
> STATUS phase
> usb_read: end startblk 87878dc0, blccnt 20 buffer 381a5200
>=20
>=20
> It is a rather large amount of output (after the failure
> point you are hitting). The output messes up the loader serial
> output. The EFI loader loading the kernel is done via
> U-Boot services and so all those reads are present. Once
> the kernel is active, U-Boot is not and the serial I/O is
> back to normal.
>=20
>=20
> I've included the updated usb*.c files and the rpi_arm64_fragment
> update with an extra line explicitly for setting the default
> log level.
>=20

It looks like that if you remove files/patch-common_usb__storage.c
and rebuild/install the large output reporting usb reads will not
happen.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com
=
=


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 05:10:20 2022
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 4MdLz55yGFz4dQvT
	for ; Thu, 29 Sep 2022 05:10: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 4MdLz44wNBz3qwD
	for ; Thu, 29 Sep 2022 05:10:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664428222; bh=F95gW81GD4sk+ab3E7SdJ2GxS/cRA2ywFqunV/5P6s0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=O/4jZwjWqzV6F/dON0awRJGJJ8HXqd+vI7kPUy2+0OOrYk7VRCad6OhdNsEcJuHXv9wKsgL5IRzM53zYvDBAWS2UEv8N/rNJkRvfg0Ri5GqVmaeLIYdRmylH7Lv1aKSlJRwLlghp8ZovtFIe2bq7MofTB7R0apKs5JDUvW25/y28m7HkrcvC+35S2Q/3foPdhDPiPLXFOfERCzF29ym/sHSQ6QNna0MYYsW85lFpaocAErPkFVaF4wB4RYO7uQy/dR78aoSpjanit4dsdhLmNGXm2we8ELRdv4LfzJiDOhqyRRKb3kAETy3ssGwzDss5fmO3P7YatqUNg1bVCLsv2w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664428222; bh=rDnVqRpOJx66N83ELGJK5xn+jN4gytJOcTmcS48Osr7=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=lDC+HrlzLaltCXnlbly7//qPtRYW+Oq2JJazVm7n+lxx1MHT050sKFdJ4xWbTy1rlnpz3f6tlJoSVlpyYlg82T+BQKhRwkftggJ84Hcfwn9rX6exebOvdppky3Xz1Ab63siu6GbghJ4vUQw2sb0TplRm2spEWZUgBqR/mSW4qHri5qP4X50kye84fU1+cAPofXWCwBMMr8WT8kl8RZGB/BwV842VnZLZwFzeZr4VQ269yLkxwkxxMYpBIs676XaePNcmtQee5ZCAz27oT9MgV5uNIH0wZ0gkWbo0ahjq1I7QYC/MllaOggbDxlgyJih6evnvzNdNbfN9xXdA9i4EAQ==
X-YMail-OSG: Rux6liUVM1nTzKW9Lopl3.Bl9Fv42MZVlc.guGaXzDV6.NKiRcK4WCd7uHulQFk
 7hrz3yyJ8N703k7wyppNXix.gxNQSdmuRg5alTgTsYemtsXECLH4UiS6JIziqDCjhLf2XpsRNO4K
 _c6SZrpPsszbW42Iqn3Inx5oM3EoyKKgX_HxEtJyBndY6ts9q0W8u5uQULDHFQ66vf0oWCHy0alI
 8O.VO3dpmzGm.sR3dlh26_OXCZYNTS5WZQgJ3K7hSXuDgI8Q3g25TA5paDYAgsVz4QPJWeJg7Xqp
 d7XwUHmwYIS68z9cjAehfzeBI5If9pABIR_8NeJ4mLP_YRUa8e.T.hZcFCawxzXV0TrxP3xAX7D4
 Hx_zzGG80r6k9jMzLVNFvdKHnflDNIQhBFvGNhDRtlnnwIRSdQPfqEB8mtUg1483KT6MjJNWmO9L
 41cImcYuJ3y7a8Ml9GX27BYsZXxzxQnj687vLUlgR3rrSx9jFfA.xm2QBVlNj7ws4FD2qEkK41w4
 2qffM0aPzluc.lDpfBbUXsHkmhth4_3dDWTjIz.2qFxfhHCD5cE4tuDb8HWxfRDFBh2Q0toFzBU2
 ojaVSeAcfkgXJmvNREcKgBgRvH9bn2PROwTaqfn9oe3ydjn9xOadu2F7tNLPptFm.9W0fQTnPmNT
 cYnzEkHxYo.b4rrz7Y_VOzAvQMA0e2mKz35oQBmYoRtT.nBRgOnkbzAhG7O1asCNTdKoN.THYcTi
 UgipiAw5AfAjavkhuqRTeEyigKw5i99i7DthtUwYYuR3gUQakLQWjddwlthiaGBlqSGZ79Tx4ex9
 xPHNbld3eyYE5Hdvgmre_Fnp2zEx.5KBeAWlv6GVv4LRQc7UGpbPsGa4kLBYk3azoDOwwLgRYoo7
 8vtQ1_gACc_11LwsZ.ZWryrHoXZIu0fvUKF7g_6b6Kyyl78I2XnyOK4Sa8fTcTxeMSd.cxVNmaLj
 rQgjHdE8kR84a3Q4CjgeW8kl1eNHbr7rVMuOj0quafjjRj2wHMWrYEkwrfIXYt18YDNutwMmRh14
 WdidxV.dv6DMhGFRLMjC2bnEkWk96FA5psHpYt1VpXs6JpZsegQmvg28rUKiJE2ZxPC4aAv.RDVd
 zui8DUt6BonD3zNTzMSfcxlsHxz.c.ZAaC8XER7h2RQJ1SmHjOlRGUM740yxf7k6N.0Mn6s_tHC6
 miIVy80fQNJAl9cfB3CH5dmpFzAOAkPnHMxWtIhNymAfZE..O8n5CMMa0oL14FgrIDcXek_aqxfR
 w2E8THUr1nqvWnHjtg_qk2PWUOrVCFccDNpwN6lLe_8hSOzAAxW5CEeOCq06ATI5D.EYn8sE0259
 LdB6DaATQQiIiZ8GPZHkbj18KHUR7guwkMkDaIi3pYxhEFA1.1d8lkfrJKCZJ0jgksz4mAN_XC4t
 aPUkjSlEkx_ZOy3J3sGCrDx9DczwRtuiK7KAAL00NDFp2FEQ9JqmUgaQJpt9e3vqUUqmlhv1PNpw
 Vou0bS5V21C91pRx0EwD68EeeX0ricO_IXCFnXRQodA9.mEtFAhPT9iUYKyQyxj4z6K6J3QsWgwB
 c1r.9q4YSNi8oDovWM7BmCg4h72B9XEO82O12lvdGzVh19vQRzceci5fiEwgfKmwVrG1DhohddAj
 TZybYjUnlYL2fjVmI7UEesVTyHlR_Wu_U9wTlNHjthdGUIGkuwhyQSSRe2bwjs.Y5ctzI_bOSdt2
 gwjQ3wF4GeDwGl07o0ri8PbRQhBCTai8azfwszv4GeVEKTJ8B2FDFbDLqoeQQ4.._9jSQn5O3YPf
 VbRS1sTqD_B4cRiWhKOXkbE9W8Vz_WOCwgadagdrLeJX0FSnkIxVXSA3mT5Gpkf4dat0uYNIECqi
 12HI_CQMT8Fm..dBPGfP7bDtbFLWrzARjTkXOmpvd0atEXW1.UvXPZszKr4vlEb80G6MoGeP9Kpq
 sAbIK9EYGGNJkhjowbFfy4XX6.RDY5fE2ubwQoCfbn5J8XzQcD4emkfM8sW7foc4T4WgvVisPn84
 Cftc1F3U_0ZHX5nbl1zbjkyrpWJoXKu4K1qQRLsukyOQ7vqeCsK2qFEVwbrOvV.Ev1MwAm3Fy3QE
 NE0p5EYBtV5kM3UVf1YLPHtuDk9Z3Dr7ASRn2r3AQ5s5XsaNw9twAyirg1_WWwLzpTtflUjuNc7D
 MNH6p.UtzuAmxIF_AwOBja7MyPzvArAMnPGpgGe.3d0WMuqiZgjT2gW1C.I44AltdE.Kh_OSEPse
 8XOT0qMurOnkhFp6O6RBszGC9Whcj3Ocsqlrqg26utbj6OJkM.eP9zF3N7Zl1jS51nHoN8V9RPpQ
 g4Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 05:10:22 +0000
Received: by hermes--production-gq1-7dfd88c84d-mgq76 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID af44686c290faf94349afce9508a6e77;
          Thu, 29 Sep 2022 05:10:21 +0000 (UTC)
From: Mark Millard 
Message-Id: 
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_1272EC13-0536-4365-9E7F-BBFDB2DE6D00"
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Wed, 28 Sep 2022 22:10:20 -0700
In-Reply-To: <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
To: bob prohaska 
References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com>
 <20220928015721.GA73356@www.zefox.net>
 
 
 <20220928045145.GB73356@www.zefox.net>
 <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdLz44wNBz3qwD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="O/4jZwjW";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.33 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.83)[-0.827];
	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)[multipart/mixed,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_1272EC13-0536-4365-9E7F-BBFDB2DE6D00
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On 2022-Sep-28, at 20:31, Mark Millard  wrote:

>> . . .
> 
> It looks like that if you remove files/patch-common_usb__storage.c
> and rebuild/install the large output reporting usb reads will not
> happen.
> 

I've included a patch-common_usb__storage.c that comments out
the few high volume debug(...) instances but leaves the rest
in place. A dozen or so lines are still output via this source
file now and I was not sure if any might prove important. So
this way they are present to consider if this file is used
in the build.

===
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_1272EC13-0536-4365-9E7F-BBFDB2DE6D00
Content-Disposition: attachment;
	filename=patch-common_usb__storage.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb__storage.c"
Content-Transfer-Encoding: 7bit

--- common/usb_storage.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb_storage.c	2022-09-28 21:46:42.289455000 -0700
@@ -20,6 +20,8 @@
  * FreeBSD.
  */
 
+#define LOG_DEBUG
+#define DEBUG
 /* Note:
  * Currently only the CBI transport protocoll has been implemented, and it
  * is only tested with a TEAC USB Floppy. Other Massstorages with CBI or CB
@@ -719,7 +721,7 @@
 	dir_in = US_DIRECTION(srb->cmd[0]);
 
 	/* COMMAND phase */
-	debug("COMMAND phase\n");
+	//MMJNK: debug("COMMAND phase\n");
 	result = usb_stor_BBB_comdat(srb, us);
 	if (result < 0) {
 		debug("failed to send CBW status %ld\n",
@@ -736,7 +738,7 @@
 	/* no data, go immediately to the STATUS phase */
 	if (srb->datalen == 0)
 		goto st;
-	debug("DATA phase\n");
+	//MMJNK: debug("DATA phase\n");
 	if (dir_in)
 		pipe = pipein;
 	else
@@ -769,7 +771,7 @@
 st:
 	retry = 0;
 again:
-	debug("STATUS phase\n");
+	//MMJNK: debug("STATUS phase\n");
 	result = usb_bulk_msg(us->pusb_dev, pipein, csw, UMASS_BBB_CSW_SIZE,
 				&actlen, USB_CNTL_TIMEOUT*5);
 
@@ -1079,7 +1081,7 @@
 	srb->cmd[7] = ((unsigned char) (blocks >> 8)) & 0xff;
 	srb->cmd[8] = (unsigned char) blocks & 0xff;
 	srb->cmdlen = 12;
-	debug("read10: start %lx blocks %x\n", start, blocks);
+	//MMJNK: debug("read10: start %lx blocks %x\n", start, blocks);
 	return ss->transport(srb, ss);
 }
 
@@ -1149,9 +1151,9 @@
 #if CONFIG_IS_ENABLED(BLK)
 	block_dev = dev_get_uclass_plat(dev);
 	udev = dev_get_parent_priv(dev_get_parent(dev));
-	debug("\nusb_read: udev %d\n", block_dev->devnum);
+	//MMJNK: debug("\nusb_read: udev %d\n", block_dev->devnum);
 #else
-	debug("\nusb_read: udev %d\n", block_dev->devnum);
+	//MMJNK: debug("\nusb_read: udev %d\n", block_dev->devnum);
 	udev = usb_dev_desc[block_dev->devnum].priv;
 	if (!udev) {
 		debug("%s: No device\n", __func__);
@@ -1167,8 +1169,8 @@
 	start = blknr;
 	blks = blkcnt;
 
-	debug("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF " buffer %lx\n",
-	      block_dev->devnum, start, blks, buf_addr);
+	//MMJNK: debug("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF " buffer %lx\n",
+	      //MMJNK: block_dev->devnum, start, blks, buf_addr);
 
 	do {
 		/* XXX need some comment here */
@@ -1197,13 +1199,13 @@
 		buf_addr += srb->datalen;
 	} while (blks != 0);
 
-	debug("usb_read: end startblk " LBAF ", blccnt %x buffer %lx\n",
-	      start, smallblks, buf_addr);
+	//MMJNK: debug("usb_read: end startblk " LBAF ", blccnt %x buffer %lx\n",
+	      //MMJNK: start, smallblks, buf_addr);
 
 	usb_lock_async(udev, 0);
 	usb_disable_asynch(0); /* asynch transfer allowed */
 	if (blkcnt >= ss->max_xfer_blk)
-		debug("\n");
+		; //MMJNK: debug("\n");
 	return blkcnt;
 }
 

--Apple-Mail=_1272EC13-0536-4365-9E7F-BBFDB2DE6D00--

From nobody Thu Sep 29 05:41:20 2022
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 4MdMfl4QlJz4dTPy;
	Thu, 29 Sep 2022 05:41:19 +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 4MdMfk4gbgz3rwX;
	Thu, 29 Sep 2022 05:41:18 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28T5fL72077966
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 28 Sep 2022 22:41:21 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28T5fKQt077965;
	Wed, 28 Sep 2022 22:41:20 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 28 Sep 2022 22:41:20 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220929054120.GA77803@www.zefox.net>
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@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: 4MdMfk4gbgz3rwX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I've put the full output from a failed (no storage
device found) attempt at
http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-log

The obvious error message is:
Cannot enable port 1 after 5 retries, disabling port.
Nothing about device 152d.

Tomorrow I'll try to capture a complete log of a 
successful boot for comparison. The boot success
rate is so far is 7 in 9 or 10, depending on how
one counts. 

Thanks for all your help!

bob prohaska


From nobody Thu Sep 29 06:59:16 2022
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 4MdPNq5RDXz4TyGc
	for ; Thu, 29 Sep 2022 06:59:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MdPNp41yqz44xP
	for ; Thu, 29 Sep 2022 06:59:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664434760; bh=a0nRj36/N8N1FwIwffcqPWWS93A9EpQKm4/kWMecyTc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LRHfx78SYApJbBeACLrv0fVpGsT8hT7KFdvIr/XOYqgrRrWfkYuZXhChD/rlSZ52thQa0YESc1AC725pEv+3Zt6t0Ql7bJK+HJ5y3GhaDZUDxbu/KIF1zITPZLjikCABwpR5nB5vu2KPglyXG/ZYt0uM3YGBBOh2bC8qe2RGx1VO4BS9SkUfd7FzpvwMMfD50vTiciyIzM77dRQg75NX3EHmAw42ndDcfYnVTpaHsy0FWC2Ny4p9KHu9ckhL03zNJHGkafDT6psRQG9px13JhtYehwEHqewDiMcGifs16kFON0++9OOUIr6QXZd77XTK+qVHWPMXw0XQicdobw540w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664434760; bh=Kqgds6YfHePam9Iw9lzkSj0vCnrMW+E6FJ+rByduvWy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZkGdgJvgY9yS4xJEV/7VdM90DhRgzKJLYPo2cvh8WDruHUnK3D3i7Ox+1aUKrg4gaadB8K4amLKKMvSKdVzR8IGGkjVmXhmcmo8NCJHGPD9TnIBvrW1bmzsQudLA8owhm8k+3oAyHlqW6UGQZ2/SM5jjlrzG6og9F45J8kzPt+m3XdQDRX3NR43xvsuRYqEaSZhnCw6oNLVna4d1CtyTMVGkEuJqboWwyz5JGXDZU6P1gMuNz801HNpz0LWzNPQmjVbEm4uWXDRROo1tQaBdcHGZI/VKn66bhR74uft+mSs1NZkgxO1iRE+QMqQzLRKEjfS1FH0GfGCHyQD22zAIpg==
X-YMail-OSG: UZaON9QVM1nB8Uh3sxmce.wEml93q8Dj2LNio5CUkRNUNGQiBIf4Rtjc5J6GNzJ
 1aCz4qhrFiXqRKzZTgsOvZwuvLBy7fsZvgGY41k1feh52XuaSx9E7WAKtdav3jdzxURpCd9Q9xhT
 .YKSo0v0U..RGY6Fhl9DNp0VnChwjfvtA84Ju7_jvD8YQ88rnlt9eYRfMm8.Ogh2z8ZGt0NrNWFQ
 Bm4Bj8cC5_H9_holOS0YTv65GMjnkKt5IlxrtwEhIZBgphYrvZwMp47SzTLy2LveZTdClqQzDFz4
 gdm5p5vz8Hz69d_swKQ_zi5zRLiJLh8MDt9Sv7Aq8HQvyK0jkSucx06HNA7n54BFgY0IbuABzex6
 B_qOX6K5G.eV0vCQ6a_uAtrU8PgIhTTxyFUYRW0PXcCag02mImk1TIEAuiccte53SXHbQGD.7bev
 OsLG7K7z_kjdonFojSflYEQLrnGoktv5u9WNtFOavqW1wz_AJntInMBwYtEzMqr1D6n39_QV8nZU
 TADcjoD4bGBPiE5oVqZCOG5Ma6kj1lQXTEF2fzgvi5eLfP5O17CPsSNylMb3KCwzshpy46xN1hOY
 Q40AUmihkba._1ImEZ2F6QyLQEYasz1IHxLlWsLGWnAwLdrJrKSdUJndKd9SlbsTTkqIVmz0muug
 cXcZSJQh0ajFiysAJW0j0GttrjyDsJGjPTkqd6UvSFKQXGjSDwo4lnRbZDpl0XEmj1SL5avwFqw_
 CyXUDOaE0L_3UBc2KAVX8g1JbNCRVRl.sFK3AddArR9DtInIKEhC80.W_bX0zhpiw37M.ybaL1wz
 ruRmLu8eDqKpu6q7H59tW1nqgAgw.X3CLOdWRkT5TYUWXGM2Y4ZaC7g9hBMLVrW7AWGWWQj2J_wh
 UqQsASddJJbe7Dg4iyHu3CyfHtDOqftSy5BmXQ4JqVHMt1fyfkonb0vyajV75bXFuHk03F55pkaH
 v_jjR5thinfSaR6dRe2wG4WHKVQgqVkaY86vYgkZeMY4gfqK3IhRHftcjJR0naBQgGy0lIiT.m9A
 3ZBqyEBaiyONMhu5JiqTxbg52q1zjWFGx_EKWmfeXjHNYKiQeBLuCOcoLitvBuu5MWFwp2HnL_el
 dR2sTDJQzvft3fN90Zsot268yLDszoY8gzivqggo30VAlKJ5tfYjgjBfJpUSgPTz_8oz8k8A5.ce
 97LQi0m_tafi7umom_2GqPJQG7EKU_o4lHz.WrqT8l6bjB9XNw66a049w5rYqRBtxxrrZiiMbzia
 2JXbhP14sP5Reaj0meytCIwKtSHma.Uqt21iDBbjCN7jM4XQFMFTRKEpQYFEzGHwGenY7r9shph_
 ZVKZSTk1qF.T6L2Nyx5u5iSNrfWyGeYSgR_fbYo4_ORyJGo1mX_aXHv0EqQBsu6rOQ7Ab80SzWAT
 qrkfFN.08yTh0pj5XGv2yGuM0KMjYIDYuHSXd2siCZBdN5QsRMCvQxhtYrejK_WaIUMxfmHxrG1y
 1D3Poy2dpqhmkcyIxLXPV9.owmscvnLcQmfda__bGFBTK7dVU2yqjHFLVgDFIgyRl9rzZtgcI3sN
 .1_SAX_0X9Lq5HD3tKjsVp9daR4mn4dU3W.4u7FGfsku7JbamaL8Vs_VMPy_puSMIrTfFM.5GFQO
 50XZZTnjN0qQAZoDMSjQrq4FYIDJKTii.rvzcJu6nbpy6RgQ3zW4NVhfzwwd.gabSKpof0H7oQJf
 Jofd5zX1brgn2AByPV97xO7U3DSSRabFEmqX_vAZyxNrDILaQsmWgxVtZLLe6IC9pAt_kBH0wsB7
 xIHiVyuvSbkER8euhRZyaJui8EhN0icAWENNsBNKI._TfhVu_ZIq4_GPjKXb7DdMbw0DNVvTKO4R
 0Dm7luVHN10WS6qg6lvcb0QxEbwxk2R9_3xA_lgvTNJuV4DKe7jJh4RhuZ06PawEH02RLz_Yg4PY
 mWtKROfpcXR3YAQ_nzlG1Krm_z6zDlLLIDfmUzQgQdySJy4ugrJlq9bwym1Ej4mkn2XAV_IcKbFx
 AEA6p7XEIO4beqMfJvizAnbNlMTxsQrEG9wRK7RKV4m9cu91x61up.5az6FmidpXWwyApaEhbuKF
 .gml4zFzQzeM.wi4SymcfPmoas3Unc0Rve1hkIq3cglq_bBHc3m9SNTcaeIIzAITuIdQ31f4E_6h
 Ztnx3YzFvgksTL.BstNWUhMbnhQo7seM9aPow47xH9d_ldbU.hFnLGvkKmN4_eek1VsOxnhoxZFr
 Yb.Q65Kqkvptvg_s2Jzd8pfQTIgFYuOZ024GYP3lgFctQW.1zxMyiVuvi83WrFARFQPeEp20WUtj
 Ypkc-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 06:59:20 +0000
Received: by hermes--production-bf1-759bcdd488-njfbl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b33bd44823033709dbade7643512d0b4;
          Thu, 29 Sep 2022 06:59: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220929054120.GA77803@www.zefox.net>
Date: Wed, 28 Sep 2022 23:59:16 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdPNp41yqz44xP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=LRHfx78S;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 22:41, bob prohaska  wrote:

> I've put the full output from a failed (no storage
> device found) attempt at
> http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-log
> 
> The obvious error message is:
> Cannot enable port 1 after 5 retries, disabling port.
> Nothing about device 152d.

The RPi3B has 5 USB ports for devices, one being internal
that is tied to the EtherNet port if I remember correctly.
It also has a root hub,6 six overall.

Your failure log is about failing to get the root
hub working --which in turn blocks all the other
ports form being accessible.

> Tomorrow I'll try to capture a complete log of a 
> successful boot for comparison. The boot success
> rate is so far is 7 in 9 or 10, depending on how
> one counts. 

I'd also recommend recording a bunch of failures
and seeing what wort of variety exists in the
details of them.

FYI: My log shows a Root Hub Port 1 status
sequence: 511, 511, 503. Yours: 311, 311,
(5 times:) 301. So it looks like what the
status encoding is and what the implications
are.

===
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 07:18:51 2022
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 4MdPqS0Y9Gz4V11s
	for ; Thu, 29 Sep 2022 07:19:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4MdPqQ6gJqz47hl
	for ; Thu, 29 Sep 2022 07:18:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664435936; bh=BU63Hby/UuDfpAYz6lFi+FFjC6kXshVi7yx2/WBHxE0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sSqJ1VZ1b4Y1TlVn6uOQd785bfszewiiatCp4lWycuqOECVuCCIdv/M1lRNf9So8L8mwRsvWwjhgMQocNOXPtphtEjOX/4MyJOMp1vGqqLX0Dz6uuCkhrPM46pHGSjAZPpOye35gp7bXyaCtcLw2Nvj7u/VvppDm/ihMCOC/qj7WgEPI3xU0TUXfRS9qRFOUeuHrd6X781H72bf4bDC7K4UhwWuBsYUFNl5L2neGL8D1gaTcNivhelgkpqkQdEoSVlFUS0u1wMRZnyK/j8gmJPIbiXD0lDhwEopHV+FTsZ1WUfWQRNZjDRZECophdXiiZah/azLsnW9vPE5qbDyLaQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664435936; bh=z8h9vh9ncHhV+msp6pMWMB/ElND+2v6siFXXSO2J87b=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IUSuEqg4Nqj2RFW4wKRgW8v4DrqhpXmtts9dIuvRsx8ie0pYde6jFXL1PYVbZR3KzuLz6KL49E1jDf5K/xBb6U1ewuJQY+uQFOsljobNBcGnM+e5eRJN0Nf3py4g3KUghdOKehwcXQckGod05ewar5RxSI5IDJCpzqHLdDokJwMxfK5aLPjh4KEBhS4rnal3Oi27v+UZ3VZ3Kxro74SBhx1K0lPXm1xTfL6z+FcMa6T02WLyZXx+9ssxo4NmOIJOdYjMDOdVojeeUtlCCZ8p4YRr0RIf3CgoUy6tjw4fnVVYD2tHm/KDom7F4+qP7cnAbhiLkTFnL5ho5kdnGRKW2w==
X-YMail-OSG: EtXUQjMVM1kGeN6n5v6xcbWhLAEc_N8VWrG1JgESLVKjm2j3SbIexzTdgPtfPh8
 LZnf2V_PoiuNCBPoc5gZos0ebPrx5xn8vKtYJ_HPcXwfEOjruQ5SMXQvcLBpWfwV6a5kw7nqjzOP
 GUMPUCsNVXBonlYg4JJRf22sKB_Os7lFtjFFSErkS4m6aJClWFf_r.yxXmCaaK_NBzpHBj9UAF99
 3unUBvHKwRpk5DkwojPr34HrjafxvvX.rxeOiy7PmgdSyFb1IhOc4CPHGWUaXhxR9y9pTuAuC3RD
 EyHN0W8mbNQYH5qGxg771D3kGVyFbfFxJZ7a27SCtSlIF1l_MEICWqKoPFwEUnNnT5fjwN1cA61O
 sjsScoSxzG9l8aEvoTWVwDqkLVdD5Y..HhAh6iYLDuLY.0uthtIBs96q3BMQ6jjHwixo0dBdkAMy
 ERZkwJFL2SnOvnjpDIwJUc9Aqso2m4Ru2JnaYNfKbHkOjpt5nPcksWdQjYFIiCkiZRlDgfIi7.hx
 dC.blE0FvYtgDB_H82m9_4cYh2.TcZcs0HEpMpGoyroF.5si3XLzdPygRQW1PcZTZeRYQwfvIMLN
 Nm5sb1DsBw8k0J5ReMT5yEle5I2_drVW09Le0YHh.fZQ.aha6WXKAMtGVpa3TV8XO33fy6qSTT9.
 rxTM299jUnWT6k6fKfrEgGV0kGDOtubdkXsYjUJHRgirTxbixcCqqAsQXmwM_9gXQuNTiaiQOm70
 EwaB0B5gIktdN7cHRgwXbtRdAYRfh6X7A3wgfUcDDjxaSmFuA9JwjLoBTaQdeUk8THhp_hzbTWiw
 UuLMsRBfWB5EcjyJryIvwI8jm84yleh_AKd2H.Wu.7pLwW_GqyzdmF_waiLvFTuxmZ_hmw_WlxTx
 Zoy.Il88PyjiJmHAQgQdzKL5kc5vQ0DgHifocLOuWcIZvwinSuIhntKrG3GnoerHmJn_F58skNN8
 3iPQKqlFA5VpGCmeq5CFg0oZlu4wpLcsrUsPCM2zA94yyxGYgwRWyIHlBOjIXFbbbR3.biFJPY.D
 l8rLlzd7AO9nkDaFmFIdPp3.qL1Ij5yEfE0yfKnUHEb9sLkF_Fgv6r0NvG_.5KQw4S1GQ1M.tomB
 7oPwPq3lXkCAPdIKhYZc5imXI27Gtnytps0kH7vGjncr973CvM40M8b935cF.IYJ0w0RgL1Ssun0
 Y0j040DGSHdvQYx6AOiJEmBz2SF8RCmNfxR5JFn1Oksu2DnQ9PpNPiZslLjO8.eUTL2rUT.HrR2N
 ATG2K3dEsC2sZbZPJMVd3P1QOP3eqlRLoxaLng9DSv85kUYvc9p22GqwSZ7m7crVf6kWRjvjWIGQ
 uHpjSOUKp2rLadklMm0gXK.iAGdS552fHHTWmYAF9iXETIVfKpj.zXq.ILo9kr8wo4F4_T6ieNyV
 IMBPpY6hDU5kw5onoQfs6lzXqkv2VDpiWvlyC6Q6E31PC9lIOBd0m3kdPD5T4RawYANxCwTquWOI
 nlJADzhR31ZXCNW8Vt_YrVerl22kI.RLERXOqNV8pNZV3zI9a3NpLLABlggdNle9oKknsLY4hxD0
 ZP1QWSRIoTg.VuEtyUDBHHmAZ.miM9EUJ4ld7bEZJD6wQ9sqgrtWGd1D1n.Aw9Nm5IMnUgSYjWsM
 voWQKSDz_5qDwKGcyaECnWqpg4Gh6dNWTQyk4jkYylxHv67F6MLdxTtmGjI0kdqZmJdDdqb_2YQ_
 vfD8iQD37zclY0VOIdoV42kXSLUC1Fs9K3OfcboOci3sSoc3UZk0HKBdCOs35QhXfvY0ZvJA.hAg
 HIkBF.tzqjkLz42tN4dcSbdt13i261MN9L5bzPWRoKroz9309vW7BYHxnEvFcBkFJ5Mlczxnbmh8
 nwZMvAXufF1o0x2SaWYtNd96adYartJeu1RAaftrbZ5t6MQI7oQYfBzoAi79axqfXc7Dge6x8L_0
 j00eTgkPmLFJy1G8wSN3o_RNwpkKFnvcL1FyxhJe.VK1AQZUot0LONRRzcDjtGUy6SUM0Y21N74F
 YWvabQ5cVXKKVC57CsnNZBAR1bMgspPhnZTKdjtmmSFDmmtiwvQUr9RF014qFwUz.wTjRDogLHkq
 UghglEPcKWy5sCHZbbUwpmghVyd6xtAXnM1oxrZuWoxBEevk.iKzcde23mnjabkg1UqiJbeK_Tx4
 Eh9L4WGkGsrrvxA9wt3wU_iUKlOeLCYwYxXgUgVyOMuYvWccPzc3H91jdwwxdVgX2cVTnTfjLHVb
 Qde0jOOlIhhemQQQcWlSRGmFe8rsHPn413e2DuTfvqdPXze4ra7BrOGO4TyZ5wq5emnlhlzAjRpB
 tnA4-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 07:18:56 +0000
Received: by hermes--production-bf1-759bcdd488-6vlh5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ca61200380e24ec2a832679b62d24835;
          Thu, 29 Sep 2022 07:18:54 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Thu, 29 Sep 2022 00:18:51 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdPqQ6gJqz47hl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=sSqJ1VZ1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-28, at 23:59, Mark Millard  wrote:

> On 2022-Sep-28, at 22:41, bob prohaska  wrote:
>=20
>> I've put the full output from a failed (no storage
>> device found) attempt at
>> http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-log
>>=20
>> The obvious error message is:
>> Cannot enable port 1 after 5 retries, disabling port.
>> Nothing about device 152d.
>=20
> The RPi3B has 5 USB ports for devices, one being internal
> that is tied to the EtherNet port if I remember correctly.
> It also has a root hub,6 six overall.
>=20
> Your failure log is about failing to get the root
> hub working --which in turn blocks all the other
> ports form being accessible.
>=20
>> Tomorrow I'll try to capture a complete log of a=20
>> successful boot for comparison. The boot success
>> rate is so far is 7 in 9 or 10, depending on how
>> one counts.=20
>=20
> I'd also recommend recording a bunch of failures
> and seeing what wort of variety exists in the
> details of them.
>=20
> FYI: My log shows a Root Hub Port 1 status
> sequence: 511, 511, 503. Yours: 311, 311,
> (5 times:) 301. So it looks like what the
> status encoding is and what the implications
> are.

Accidental send. Continuing. . .

The output uses %x (so: hexadecimal). For reference:

./include/usb_defs.h:#define USB_PORT_STAT_CONNECTION    0x0001
./include/usb_defs.h:#define USB_PORT_STAT_ENABLE        0x0002
./include/usb_defs.h:#define USB_PORT_STAT_SUSPEND       0x0004
./include/usb_defs.h:#define USB_PORT_STAT_OVERCURRENT   0x0008
./include/usb_defs.h:#define USB_PORT_STAT_RESET         0x0010
./include/usb_defs.h:#define USB_PORT_STAT_POWER         0x0100
./include/usb_defs.h:#define USB_PORT_STAT_LOW_SPEED     0x0200
./include/usb_defs.h:#define USB_PORT_STAT_HIGH_SPEED    0x0400 /* =
support for EHCI */
./include/usb_defs.h:#define USB_PORT_STAT_SUPER_SPEED   0x0600 /* =
faking support to XHCI */
./include/usb_defs.h:#define USB_PORT_STAT_SPEED_MASK   \
./include/usb_defs.h:   (USB_PORT_STAT_LOW_SPEED | =
USB_PORT_STAT_HIGH_SPEED)
./include/usb_defs.h:#define USB_SS_PORT_STAT_MASK              =
(USB_PORT_STAT_CONNECTION | \
./include/usb_defs.h:                                    =
USB_PORT_STAT_ENABLE | \
./include/usb_defs.h:                                    =
USB_PORT_STAT_OVERCURRENT | \
./include/usb_defs.h:                                    =
USB_PORT_STAT_RESET)
./include/usb_defs.h:#define USB_PORT_STAT_C_CONNECTION  0x0001
./include/usb_defs.h:#define USB_PORT_STAT_C_ENABLE      0x0002
./include/usb_defs.h:#define USB_PORT_STAT_C_SUSPEND     0x0004
./include/usb_defs.h:#define USB_PORT_STAT_C_OVERCURRENT 0x0008
./include/usb_defs.h:#define USB_PORT_STAT_C_RESET       0x0010

Note: USB_PORT_STAT_C_* is for port status change information.

0x311 and 0x301 indicate USB_PORT_STAT_LOW_SPEED instead of
USB_PORT_STAT_HIGH_SPEED. They also indicate lack of
USB_PORT_STAT_ENABLE.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 15:19:26 2022
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 4MdcTn0XjQz4d4XP;
	Thu, 29 Sep 2022 15:19:25 +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 4MdcTl6vprz3vYv;
	Thu, 29 Sep 2022 15:19:23 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28TFJRSY080043
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 29 Sep 2022 08:19:27 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28TFJRR6080042;
	Thu, 29 Sep 2022 08:19:27 -0700 (PDT)
	(envelope-from fbsd)
Date: Thu, 29 Sep 2022 08:19:26 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220929151926.GA80020@www.zefox.net>
References: <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
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: 4MdcTl6vprz3vYv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

There is now a transcript of a successful hands-off boot at
http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-pelorus-success-log

The text "152d" appears only in three places. The first, somewhat early,
is a block of text containing the words "unhandled device class", which
seems suspicious. However, the string is isolated, not a device ID. 

The other two are long after mass storage discovery completed and name
both Sabrent and JMicron. 

I'll try to gather a few more examples.

Thanks again!

bob prohaska
 


From nobody Thu Sep 29 16:31:33 2022
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 4Mdf5k2gY4z4dgZx
	for ; Thu, 29 Sep 2022 16:32:10 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mdf5j3s4mz42Rb
	for ; Thu, 29 Sep 2022 16:32:09 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15])
	by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 28TGVmQ2025950;
	Thu, 29 Sep 2022 12:32:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
	t=1664469127; bh=KZNYs94kPTZaS1DhcX49aJblesv17uLq/H/2xI5ONGg=;
	h=From:To:CC:Subject:Date:References:In-Reply-To;
	b=P42kkrPCBCx790TELz+TuvulxVaUq/8mMAj/sMDm96ZNuYMCzNuTU0aI3M8mEK2jq
	 Squ+ojPhk/ltwC8EGZ0XqIutJfLoejqdRvQhHKAUSU00rbZub0/22ReB/ZKGsNl6/w
	 ZYFqA8UPCtTbdSfRgP13qkKm7czRXik+GhkX2u2up4cgcrhTqJrv++PKPM1vcNAWqE
	 L9dqTx/kGCmrPrgYKwP90ZE+cVXUDIEqEyaIJ9SgvCJIcRmE8AaqyuoTU+P48+OXy+
	 wqr1EOSNqUfIG0CSodLjk6Fky38ubMSwIQ9v8zKo/yXe0mXx7tb1UuEhcrWHhunWiN
	 TNMfQbNkg3wUg==
Received: from w92expo16.exchange.mit.edu (18.7.74.70) by
 w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id
 15.0.1497.38; Thu, 29 Sep 2022 12:30:43 -0400
Received: from oc11exhyb1.exchange.mit.edu (18.9.1.60) by
 w92expo16.exchange.mit.edu (18.7.74.70) with Microsoft SMTP Server (TLS) id
 15.0.1497.23; Thu, 29 Sep 2022 12:31:36 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107)
 by oc11exhyb1.exchange.mit.edu (18.9.1.60) with Microsoft SMTP Server (TLS)
 id 15.0.1497.38 via Frontend Transport; Thu, 29 Sep 2022 12:31:36 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=BwTY3c8aNFGo3fiNn3J0UzPTZo9+DKdlo/jn3adLfyWNpPC768cvRnM7Nr3tUB6WTNGsTq/Eo2w+C5XTPwjkl9B0UDzzXRwi+/6ILZBtN8qw0h7W4s3S9GFY05RfAa5AI7ASFVihyyXz8EZ/mmSZr/mMK7Cae0jY9wv6n8sxat1gFsD8KVvf7jpW4OYWXcj+ndNmR/Q+vTmIzefqSxYsmh3WDstvby8U+WmAeReUsVGNrK3xVsADy//1Eg4vSh3Z5QqGHTDow3VDTmfsNZNd1Wvf8ORX8LEnCiygVbqFiDI7GcME9+XCIxoyaMwgT/9TGLhgvpIVW5swhPT5T0iIJw==
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=F7fJbzjaDK1jcIN8s13Dynfw1FIkgGewU9QVOWejmFs=;
 b=A3efTrFWPJmAfSs2bv7sde0sFFXpZa0uBNl7k7ioZniIAY5HkMWmzlpouv0CwoPlDtlMIS2WNMZnnqvsb0OT+zo5rMaGDtdWoXeofF2iWFmtBUjw0fwPuCvMx2zKOt4kXOIXg5agbBEDAEN9FsehtABWZ6VsMeMkkAT+nOdeBkL7Z1GVXpODn5KUP2offEOBBaQ2KFcKgq/dXMR6SD0EiuUgi9DEZ2lMiDvufwXGk4h03W81TSSuX+tog8PKCaBlSFkO2Jlg68ePxcUphZQYTu5pq0J7FhNgPGwy58UD0G+s0z3Nu3OWLLB5bk5EXjVM8BolD6pe1cdIo0lUmmIhIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass
 header.d=mit.edu; arc=none
Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by
 PH0PR01MB6651.prod.exchangelabs.com (2603:10b6:510:7a::7) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5676.15; Thu, 29 Sep 2022 16:31:34 +0000
Received: from DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::de23:a192:c673:96ee]) by DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::de23:a192:c673:96ee%2]) with mapi id 15.20.5676.020; Thu, 29 Sep 2022
 16:31:34 +0000
From: John F Carr 
To: Dave Cottlehuber 
CC: freebsd-arm 
Subject: Re: fans & ipmi on ampere emag with lenovo bmc
Thread-Topic: fans & ipmi on ampere emag with lenovo bmc
Thread-Index: AQHY009DdLl3C+NqjkW4riqXBFzSjK32m0CA
Date: Thu, 29 Sep 2022 16:31:33 +0000
Message-ID: <260322DF-705A-48E5-A33C-D07C22971B31@mit.edu>
References: <64263e19-7592-47cb-9408-f6361b233f6b@app.fastmail.com>
In-Reply-To: <64263e19-7592-47cb-9408-f6361b233f6b@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|PH0PR01MB6651:EE_
x-ms-office365-filtering-correlation-id: e2904fba-981c-49da-d584-08daa238129e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 34kVUgtHNN820g9qNwWiHChBz/4MSa8m3qr9ejJqw7QrD7hiJySDlSLFaK7NSAt5V3vwhJ7tBQXJXryZmSh1Fr9/FmHyXugHk6yZZ2Zkw5ZTLxSPyQIImKEIe3y++hA4kg8HhNRbvSGQ7Dxr0bPU9vFqzNavLh7wFzhjrrBJQzsgCaF+BCvBcMXqv3wJF1wQBQu5I597M8AS1VL24z4pxvwogXfjgb4+JtoopU2YG5rpzC9IXIrMjJ/gsvslG194K5EgK6jKkgbG1Hau/sx2cD/VgYeKvBeIY7VEr6aADT07FyuCQkJTcCVEF3iFXOmHho8+287gJF9JvpTeMo2ceH6w4cEeU6KoY5/pisUXujAS1NUk1cJ+jdnNJls26lPCLmCn9HcLul1fumb86nhQt0pIKl3qGcye4qQ5glrJddrGigQgMMzYPlibrAerK7HeSFI2lE9w919hGarjBh39GKhUF/fnC8kjOau+easQgwDGsi/k+Ykr+DSEi13o2rFvp9jsIxO/tkdX2/LGBBkYEOV1144V9fn62Wsm2e5/wOox/nE6RzPOA6Qwva/s3ZF85lkowcLQ5D1LKSGxaeDYx6PpR3ww+Jw9Re8WG27j4jOF//yFJdGWuypuhNbsA+xEjj7lFVZ62WSMyqmLk9TRIDO2LLzNKyRPceSU4vvPN+9GQDZ91+Mcu8nYhHSLFXd1Ogh9c7iU3T04Nh/f4f4ONSKlgf2uru17F7cxhou2hHKepX2iHaoEAVJOxB8BtpjMV31FyxbNYRwwNS/DCEcs3g==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(376002)(396003)(346002)(366004)(39860400002)(451199015)(186003)(6512007)(2616005)(75432002)(6506007)(53546011)(91956017)(6916009)(38100700002)(316002)(8676002)(66946007)(66476007)(76116006)(8936002)(478600001)(33656002)(64756008)(66556008)(4326008)(6486002)(36756003)(41300700001)(86362001)(4744005)(66899015)(2906002)(99936003)(66446008)(786003)(5660300002)(71200400001)(83380400001)(122000001)(38070700005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+HyepOs6yFZ/VFsAN03my01JzX+fNrAHucWXGVe6Y1t7x6DSyryRJ7Fb5Vmn?=
 =?us-ascii?Q?raR4Jlf5XZIeqqu9lYiDGIdEIWXoi38coxmSpgo+O9DUParPIFhl+87ZLSC9?=
 =?us-ascii?Q?mYo0ls/mruzGus8Buox1gRvV96A0hn5P3W+1DVMQ4chYUYC7MSeJnGlrF+Wi?=
 =?us-ascii?Q?ewIwPUEmwBcU7R1BvsPyKmAS2cviy9ULycUrZI26FQf/No6oTiEbGqAK8IBk?=
 =?us-ascii?Q?h+K/W2TjiwQoeCwAJuFXypuPzXk6wZdHZUo3GeutGHI887iXzjzd9p94dz5m?=
 =?us-ascii?Q?HoNDl8DkY6DvRZvmjsqxJWI3XAK5QYq3YnoDzlaA+idoyPjbm2lJcvMAsoDl?=
 =?us-ascii?Q?B4isKlvISIJF3n1LGLv/ePjjyBxhbVqh0/aCXl4Dm3XxRbjhlM/4pNbwW9xQ?=
 =?us-ascii?Q?jXzjAzsbBM3a1HKSEJvyQ38xJvXujZZOnkxjpvU2DlqZNGz1GcXo9tm5YKwz?=
 =?us-ascii?Q?U7V7IsGo8iwTKOyZW4Gb+r43UYSLksVnUzSfPURlNGIzLQjyhWJ10eb9shuY?=
 =?us-ascii?Q?jFV/9ojCw6IoOxI/qZQM7NdyW5xFNL3HEV2yGpoLoNq1M/afQdj1qvgCnxA2?=
 =?us-ascii?Q?dgzgnZMwcFEkKbSPrEKdctME97iEgYrvjdfkppDrbsMipPAdp0qyfV9H+r0u?=
 =?us-ascii?Q?drzVl3k6cUt96SriXKikcB1FFVeS1BZZHgt6DouqI8BXM5CHA71H0ZNyYxDc?=
 =?us-ascii?Q?uvBfh8xXQgyslw5IYwlW0lnG/lLQVm8rW7oO25p2Y+wAKVzOTj89+7bokBTo?=
 =?us-ascii?Q?8tjvg2sQAprmgXACgfHLzj4H4821Po0bXDZAeniGHemvo3bK9D+BOTRc2jQe?=
 =?us-ascii?Q?B05xZ8KZqHQRzHdvOXLshlfD01lKH+dl/TgVLng7cJCB4w/OeUkD5Md/B+li?=
 =?us-ascii?Q?QzsOSX8O5NAdJ2pmu+utmTj2sWc2XQdXCNE3seW3wkacGLa1nStkH52xSxO5?=
 =?us-ascii?Q?0vrUb5f34rW54ISG7+wsCwAnNl2tVzqt/L+qNJZI7q5YvTyl57xNxceYFG6r?=
 =?us-ascii?Q?PU8sN+7nDg5trOCl7M9RoC0GaRRvXgx92pX/wpkTOORKlkt37VXggHyDVPT/?=
 =?us-ascii?Q?27iSo/LLdlGZy1Vql2K1SFegNJFDp5rF1q4dUtHN5J+1wuA31+9KlLCqLgqy?=
 =?us-ascii?Q?GTxuG6Sy+gJNiNWmE6MFJa5YMG6Myi+BPyvNjOsajC+F1LvwRJKlucWLD39b?=
 =?us-ascii?Q?1EdauMHocVDlMTvD91+PEHNbxRv4U7iwg7cSR9hfq4m/wHxZDleURz79bWF/?=
 =?us-ascii?Q?H8EhALGuzk7rvCHuhmW34NdimYCbz4+BdLeB3utLE2ynhU6rB7OqQhm8BXCG?=
 =?us-ascii?Q?KcQkCQpjvi8cHwVs0MqLmQSmUVyzihatpX9jTRfii6tpOwM3NkI/TZQHRjhw?=
 =?us-ascii?Q?ya5pfWaDxS7d/SG9jT6mY0wIgUnsdC3Ieru2YYcgtgCgOxslRBxHnFWSMSHB?=
 =?us-ascii?Q?FRfN8n0LWjAvR5oDgtdTkORO6xMMl4gKKxE9u4mACcjt+O1Yo/GjXl4p3QBJ?=
 =?us-ascii?Q?JzWWxTuRzoix6NAdxHxsq08xihrDrznXABR5gdG5TIS7chO6pnTUqdBcGTIX?=
 =?us-ascii?Q?pc0AR57HPfnWl33vIeU4wzqQxoszJFUE0JeLCOUZPn+JoksUM939A3YDuM3T?=
 =?us-ascii?Q?89FfS5vufSOlNLsOjnFHAlVOKeTjZZ3COLo/IHA1f7ve?=
Content-Type: multipart/signed;
	boundary="Apple-Mail=_9304E0A8-C4D1-4CF8-A9EF-5CAC81EE08C0";
	protocol="application/pkcs7-signature";
	micalg=sha-256
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: DS7PR01MB7712.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e2904fba-981c-49da-d584-08daa238129e
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2022 16:31:33.9989
 (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: TwzYwqdwXpl+W6wOrOJOKp8uzdVU0XgLUKiDcjT4B8Xj94Oo98ftWV+dgzKujVb1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR01MB6651
X-OriginatorOrg: mit.edu
X-Rspamd-Queue-Id: 4Mdf5j3s4mz42Rb
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mit.edu header.s=outgoing header.b=P42kkrPC;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}");
	dmarc=pass (policy=none) header.from=mit.edu;
	spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.59 as permitted sender) smtp.mailfrom=jfc@mit.edu
X-Spamd-Result: default: False [-6.75 / 15.00];
	SIGNED_SMIME(-2.00)[];
	DWL_DNSWL_LOW(-1.00)[mit.edu:dkim];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.96)[-0.956];
	DMARC_POLICY_ALLOW(-0.50)[mit.edu,none];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[18.9.28.59:from];
	R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.58.107:received];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[mit.edu:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_SEVEN(0.00)[7]
X-ThisMailContainsUnwantedMimeParts: N

--Apple-Mail=_9304E0A8-C4D1-4CF8-A9EF-5CAC81EE08C0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Sep 28, 2022, at 11:29 , Dave Cottlehuber  =
wrote:
>=20
> With recent exorbitant price hikes for electricity in Austria, I'm
> looking how to reduce the fans on my eMAG HR330A when its idle.
>=20
> There's no obvious sysctls related to fans, but there are IPMI
> raw sequences available[1] which I can send to the remote BMC:
>=20
> ipmitool -I lanplus -U ... -P ... -H ... raw 0x3c 0x14 etc
>=20
> Has anybody got a better solution to managing fans & temperature?
>=20
> # demsg
> [14935] ipmi0:  on acpi0
> [14935] ipmi0: SSIF interface not supported on ACPI


Looking at the source code (ipmi_acpi.c) the "not supported" message =
means what it says.
The driver does not offer the user an IPMI device for the combination =
(ACPI, SSIF).
It supports ACPI and SSIF, but not in combination.

I am not familiar with this feature but I have one of these systems with =
loud fans blowing
all the time and I am happy to help.  Right now "SSIF" is just a four =
letter word to me so
I need to do some reading.


--Apple-Mail=_9304E0A8-C4D1-4CF8-A9EF-5CAC81EE08C0
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA7sw
ggO3MIIDIKADAgECAhEAllRUaZWy44T/aVEsqzSrczANBgkqhkiG9w0BAQsFADBsMQswCQYDVQQG
EwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0
aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxMB4XDTIyMDcwNTE2NTQ0
NVoXDTIzMDczMDE2NTQ0NVowgZ4xCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRz
MS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQL
EwxDbGllbnQgQ0EgdjExFDASBgNVBAMTC0pvaG4gRiBDYXJyMRowGAYJKoZIhvcNAQkBFgtqZmNA
TUlULkVEVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL2Ka5+9REw1B9JXThajulqv
SjDFK1pNpGB2nljRQy5iTTTVddq/4+s+uC88etHWbMquFd/i9sCIxLHgDFhlGZRhcORhzDfwIxLA
P8q4KMsAPeXO2kgh86pGH+DEsUPEbEtdkN2cnT9kt+BE2cPCOiqAR+YBWZX3ebDLc4+eWiPfErg7
WEr4XcIraxxxtLuUR6sVbN7nG7WCtBCalzbAxryy5GmWZ1z4OawzylJVb+qLKeMi3XN+H/d+shdm
6PmyqGeCu7jpN3+g/eAuWk/PWhIUhDwABK9JGWW2+xWCtDHxutzRt8vDMZK2GaE6MzpBpTFR1P1o
IdodVtrHGtVnKq0CAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBQCc+0gYnBj
WRsOZgQ78pmO+ojOaDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRj
bGllbnQuY3JsMA0GCSqGSIb3DQEBCwUAA4GBAAm/9fT9H4n5ks4q9cGE5FWIwAQmEGre6gMVU+VL
V4p2Qfd4eZki0uKg+Vi6BWeHL2GMQQpnpjgm1Xx6q7oSruPTkkrs75X7oTW5Nf550U5qEKXSqboK
y+6dkw8fNvNci0tYs0j+Ev6JPU4VgDK/NSWtRFrndFzLI2SgJ6k+Ess4MYIDRjCCA0ICAQEwgYEw
bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1
c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZU
VGmVsuOE/2lRLKs0q3MwDQYJYIZIAWUDBAIBBQCgggGVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDkyOTE2MzEzM1owLwYJKoZIhvcNAQkEMSIEILVbHZGO2UIV
NY85cgIn1qG+axXPWtrkxsHofDl+muUuMIGSBgkrBgEEAYI3EAQxgYQwgYEwbDELMAkGA1UEBhMC
VVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0
dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAJZUVGmVsuOE/2lRLKs0
q3MwgZQGCyqGSIb3DQEJEAILMYGEoIGBMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo
dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw
EwYDVQQLEwxDbGllbnQgQ0EgdjECEQCWVFRplbLjhP9pUSyrNKtzMA0GCSqGSIb3DQEBCwUABIIB
AHewyUJEPHgpq6/j66f+JYamStQYnS4TqOxExDGeRX7ow0Ov4BR7rHLKjJR6L/48BeoEjP5XVt3s
0vmKa2jzq2ULXmE8LLIsiwEUpPdc9usk0CCko9O0Eqf3RbTzs27CbqK4ZAniBCcbeTaejE+VQcaO
EklQ4QQWhK5kub+LRYNVhkFME0lEm3Wfp5BQRzmAJcIoS4f+tEppjiaMDIFU3ByiChXzp8qUv5JT
6lmJfcCsAoX0qvpBmw3SlNANOsTNRBmchFBfVSePUv12oWhMCeJgcBKIapdgumpyHRdlz14bwD3i
n5qW4rS6PkFwHjaG0rliQCh9hKdvzVzRVnZm7ukAAAAAAAA=

--Apple-Mail=_9304E0A8-C4D1-4CF8-A9EF-5CAC81EE08C0--

From nobody Thu Sep 29 16:38:04 2022
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 4MdfDk70hsz4dgrR
	for ; Thu, 29 Sep 2022 16:38:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(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 4MdfDj5bZ4z44c9
	for ; Thu, 29 Sep 2022 16:38:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664469491; bh=6lmBtTw/nUB0jNq0Qpue96EbxOzbHsIPiPHi5iN6QmM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I9out1CaCxGni8/psLNXqPOguxdN2tZGm3hBrTvDTp8gR/O2O9xQ/V2C9S0rE9mczoREd096Igh9WRPoM4n0hDAKkFSS4wodmnkaj5gvnrhSOB86rpvtL1Lwv2MHzv6O+joNH75vX07LpZXFFQSymNBVoBIk81K83kcQvZ8GSQtHTUPjo7kduieAstsYJ3feMwej2RSmdu0aBuRAvk8wWPRX96+mphQat6wD8yfFLqf9hJioS/sHDPGWryOfAPakJzcLD1N9GKKx9fdHRV6vMLfpVS9bLNb8QMoSDAU+adu4vj8ulZd+kK301n1G3pQSiXYJM+a0tZVhU/U4DPPTbg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664469491; bh=88JZhz9HRUb897sJt6uwNmNzIS2tQ98jrAvkR4C5D4W=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oCGt+Zop74+Wb9wqcp5dDkTWR5EX6AqkjPqtfNQHI2ltRYIDisedFdTt26+nLAIcaGUsbbsZ/NTJZ5z+38o/bfWQMmbZTjfHTUqnVinSaBqrngEo5LmfXDHoaxDS5FOCWpBoRTGsf00HWWFhmYzt5tZOTDe6bKuEhK6B3w80WcqBnxmfhiBTlNJz1OlEKKeW+IrVfHB+RqZjB363cYPIt8bC5oJtmXGL2k7HajgmxetifryDiTweSHeXnLCE+7FPlikjj2GIdJe2Sn/8n6eK6YSKRr+uQIeLELdp3uFDQrv39W0okduTmdekyssNJ5Jows3kbmoNWVIcps4dcOg55g==
X-YMail-OSG: nnCf3PQVM1k4vPz0bUrdncjLvdFvPE1OobTRpFnilM.f1zLEhYupfMARMxbRIWO
 voomU8xzb8JzlT3aNdADW8wwWC3xF1m_qvOFLxdxb9OFwPnrVtJVzezPLKAGps4yjAfBOdajX1gN
 eP_Z.v6zxNbiohkV.56Dw_bpfufFPFVFzwgzdBrH0MVyhzBA30ifqpjsrgRXjGYGjNQzpIGJz_hV
 abjDyefQ4H_p5ONsXUxdm6sK8vXEtGE6wJNIOaaUbO0ir1WAeEThkh7M8l4nZA9USkgDthEB3wQZ
 1KxicgzIT8lRbKmib.NMujcPitqYmLx_LJCbCEErAnS5Nm1bwKMnIm3_iBobfbYFhYF0ym0Mnvcl
 DbvRkLb6dR8EqyhlqXmL5eIXmDc.CAMH.c9RhOCaf4fwqwYLLkjIN7HpfM_LJ6sHXIyghbq8VBbP
 gsIoM.isMt2zQm87DmXrXBGCsnjghrk1Wh7.zktDHrsouhy6I8ww_c7EaQKmrHxv_RotHUmbU2aL
 1x1XNzyqGDoTl13U3Inqq_gjigF1efJrr.V7GzoxjM3HO7vRNY7_iGHRzztOQkWcB6SInb2.STRG
 4Js1ikr5KpOIFrhrN7qLvi8r5KrYpcGq8kBsuEqpkAc9zWWju.NJJUcHK5auDjc54MmbM_9NripM
 _wLY1qaiCRARaC_zmJU619GLRJ5HVa1V_jYUiuwmYATarp2x4j5hEZdDEeMf1P1QA3Jo.H6OiYQY
 Vrrad6mgVk2L_sTeSXV_vxQHMXUFuSHehWyThUUGE6N6FKLwqmjaFmArD3SRHJWzfj7iR0G9rg5F
 kVM61zRgY0Uh1SK.Mfanoz31UFHZThOrLtcqKzAGozNnTcSZpBjtTPkLJNYi9rDpGSyuJN0zgBia
 mpWEEv1K6F.3hqyl4XTGj8hCFC1ETAxAK3CHsfThuLo5cJgp6Dr9l728Rg0Oko3v9GW_32GHl6bX
 A5ciAZSPEHGOeJ9LEf_rF8L_e5COGgZOVEegm_dO9fOcwGbtANPCrm.iYVnftwf9qhk3RX9P_IXd
 CPV8fcjxqEPslygskK9_1dHHvv04pd9m3t_Z4DWmIJMZdxGm42TmGDJyQNeV.PJsPyIyiAU3GDUr
 hBZKEGK91idhoMluUJcnPXqHQeZdmdjKFhBJGMItkcelkIxPUbSeYrBrFwnnUrXuGyq6RpjaACW1
 J_nKddm2BoqOqEITa6lalJVclx2lE34oNylyWDj7oegrSGvSqY0XbvKKK2_NeuXfvh_ihbOIuLlU
 DHX239v9t.6ckpBRpa2y33rocHo86_T3EZJDVUoPe5XrVUwUxpHyHwQMGhwmqVeBzt3qrTHJTRYU
 erSQ9SxviRglr1h4WdriAqZHPZxoMVvKI3yi5db97sDr7qC1xUzVfa3HoXvkKBF0dmFsRPtMIFzF
 iQv5uyIGFr__t_1Fr5JW8DBHHBCX4S0RS2vTO.9mSuUuYKE4trxAQ3v_j52ST0RYSo74SlWMjMSl
 vYyr7rhBECX_rw8IfnUnGix2C3nbTwc4_jgQztcH25Rkb9NUsiUTP8FJjOQCQTfnN8Yb7Q_Jrzzl
 vAarAKVBIqIy_keLrSRFCboFab9kxCo8a_N1r.TmwO.S7Jv6SrQ.IfvHxub.XEnwiYnvJDBHDiHO
 pClqr7YqLtPtLUgDlYwE.YeF2Pj.WCVg54rMPdSErSjbYvayCWz_39aFc2M2J9TMYZ5ZD5_8IpQ9
 C11Tx_iV7QoL1XafRRJeI_Nw9iFnOZyA7cfO6IA2bHa_RrR76vmJIIneQlXZevlO.vMJ0NSYKBWJ
 Hn03vyPEaZw.hq46MLw7Kf8O.B5fcj6OsyWgF0p.IPJuhsosqCEWKxROJ1QD91NlgHb2j3w53Iuw
 xfmdaBQRWPTg06V4V9MrcscKrFK7OCiT0gm2DBOykK80ooFulDXn7ODClTu_roUsLSmlLWwuY8Ob
 0Y0aVighMxB7M7TY6afo3pFw.3QsX1tO0Cdz3TANWSxU_hf2rxDvEDsvDCLTdv3xg6T1P1.SpyuZ
 WkL2bBDzKtvECxDctiSlPPdkd7tXWwhXJjaEePG4CEOXFKdMW1kpIk0v7iY46FuPstw_2kTXW216
 xpktAs0hkVpDRmtSmz9tFPn.WAJXwQDdMGI5C2t3OthVVdFePQcRI1Ai.iuwdzstsVafjjmxnLYK
 eerZhhyW1D1MgTcJvLk4N17Fjjy7a8u8sSAOQ_Of1PtdIiOqQTNfsHnhMUhWSUzkR4UUcWU9xk01
 fxX2WtP1fOBYcFCpeL8xTP_g6sTi85aAxnIC95MEsyOjIomGcfiGQsC69pVpi2TsyIWo7XYlykav
 YWw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 16:38:11 +0000
Received: by hermes--production-gq1-94b89944-z6bd5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4cf68bca101e514f4da5d82a10d45264;
          Thu, 29 Sep 2022 16:38: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220929151926.GA80020@www.zefox.net>
Date: Thu, 29 Sep 2022 09:38:04 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdfDj5bZ4z44c9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=I9out1Ca;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.985];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 08:19, bob prohaska  wrote:

> There is now a transcript of a successful hands-off boot at
> http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-pelorus-success-log
> 
> The text "152d" appears only in three places. The first, somewhat early,
> is a block of text containing the words "unhandled device class", which
> seems suspicious. However, the string is isolated, not a device ID. 
> 
> The other two are long after mass storage discovery completed and name
> both Sabrent and JMicron. 
> 
> I'll try to gather a few more examples.
> 

FYI:

Building based on the latest patch-common_usb__storage.c
that I sent (by itself) would avoid the huge number of
sequences like:

usb_read: udev 0

usb_read: dev 0 startblk 40, blccnt 1 buffer 38098000
read10: start 40 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 41, blccnt 1 buffer 38098200

and make the log files much smaller. Any other messages
from usb_storage.c would still still be present.


===
Mark Millard
marklmi at yahoo.com


From nobody Thu Sep 29 17:09:27 2022
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 4Mdfwj1HcLz4dkg8;
	Thu, 29 Sep 2022 17:09:25 +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 4Mdfwh2RRkz49ZV;
	Thu, 29 Sep 2022 17:09:24 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28TH9R3g080351
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 29 Sep 2022 10:09:27 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28TH9RGc080350;
	Thu, 29 Sep 2022 10:09:27 -0700 (PDT)
	(envelope-from fbsd)
Date: Thu, 29 Sep 2022 10:09:27 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220929170927.GB80020@www.zefox.net>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
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: 4Mdfwh2RRkz49ZV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 29, 2022 at 09:38:04AM -0700, Mark Millard wrote:
> On 2022-Sep-29, at 08:19, bob prohaska  wrote:
> 
> > 
> > I'll try to gather a few more examples.
> > 
> 
> FYI:
> 
> Building based on the latest patch-common_usb__storage.c
> that I sent (by itself) would avoid the huge number of
> sequences like:
> 
> usb_read: udev 0
> 
[snip]
> 
> and make the log files much smaller. Any other messages
> from usb_storage.c would still still be present.
> 


>From my point of view the size isn't a serious problem, the
script command makes capturing output easy. It seemed more
valuable to capture maximum detail until the problem is 
better understood. If it's understood well enough now just
say the word and I'll recompile.

Size might become an issue, but there are larger capacity 
webservers available. I'm using www.zefox.net out of habit.

Thanks for all your help!

bob prohaska 

From nobody Thu Sep 29 19:55:00 2022
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 4Mdkbw0cYmz4V6Mk
	for ; Thu, 29 Sep 2022 19:55:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mdkbv0cMpz3CQp
	for ; Thu, 29 Sep 2022 19:55:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664481305; bh=82wRJATo+6SBUlZ7Exwr2xzuB7QCC1nm/aTV32J2zmQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PU/ORVpyuK3oNNlvEAP3cBPNaa4cBqHygn88SmsPCxkotPXXFgcMg8w0q+QaUBZaNys4dMxNAdZXz92yE9zL5hNgn2stSupQKIcV8Pe8zrMmaPp3hySAnFV26vTvlLh1LI70rYo0YEZ9Nk0FbPqunnqW4Takpy/ifWcv+mp0u+OaGgOJGjY5I/fuq50YrFXhvikhod13gUiNyJqPUHQ0nD1LIGoO36LlLtTWrbX1bQNfIC+QSwxcBik+36tRST5z0SOHgshokj5zaRuKaMZHA1aOBrZMEyV0yIQYnnFTMt0bfZz0fbidxQ6YOJYKUoTs2hvkPr+EWZfMkXh1PwMJXQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664481305; bh=tDbu7o1CzlFEIymlQohSlX6ffOds6TFsmBCi/RfMYwI=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JnlmxN7IbyG40g/ySGEilAmFHehBd1oaLXu+4pjD/w2CXI8WzgpoQhuLJxWrks+q2orbsc8T1sniJoZxjkD7dOqat8kXjnp8PPFVQSI0jjCcguDdrYf3pUTv13Zn1/Nn3fYeJgVCUV91so/VqAyYuPMANjt6+CubxMK/sgXpWKC94pw/TBnRCJRGkQGjNE9Mj2QOOQodnDnPC9wghU3MOwhn5EMRhe0wtDPbQs7nLHlcrz963w8nNFgfFIfDtjd71Hj+KkA4kWL9YuEyryvzWz/MAC3aYrQv+z5Dusc4uueC2s+O3CsbzTjAnZI/vzMK2U/QIAyJ6BWww8XCYBegtw==
X-YMail-OSG: vuYNPq8VM1liV79nT7.EzqLGiYDrfMoz6qNCYTcnq6PKhaUFvpTpsHXGGo.jHya
 kRF0S58HrRO3bA7OCb7hBAevuDh1X0jXVszQpy3cT7UVSxYZsKVZegYfiet1a0CVb608135CnNAr
 2OLkxr63ZJAcuwqKIgtV5viyQ38_Eap90BMmgJer8WccVgxPEXK679RLGbgpehCuKcpa_HSZdtxt
 lvuAo3qQJxmLWXN.rH8EXYDIGkjwKpP6cyEHPtZiVYfcL3TTC2celtjDtl1cbXiST3TjRz3qRrUs
 l9WIkXp92IY6Ja.gF0XiLbanweGyimdkrWebrIwoZ7RNi4JecelE.ZrK39XwIODtKKr59kKRYDL8
 ll8100_kWnhIKtTudikb6iFmAnVkDaf8i.7upPsjz.nHntV6WOpEbS22S3hT5B3d0Cyrzc_GX0m1
 cO48hpnI0DzmofrgvUf4lNzLyZ7D1Y7qbu9Fr.LEqhBROk7E5QGs1xq.YFb6PyYeGump8HA2Q2e3
 PI1SkvesB3frKUidpYYIaNhVO97sKFYdoHS0pjRkDEwXaCU9Pl3TkO.2iPk6fC2CQ4LP536HWfpL
 .PhMglVkYILQKxSGtDo4H0_hbFMHivIoFi6.Ur0Kbd1vpoDymLy68kpAb8atCqRhru_t0m6pq6Ps
 6klu4lSS5Yis6LC7h1tA.QAx_AJ_KcTEqRykiv2LbDe6ujicB8N_lw4Vc8dn8jDIvj0Tyl0pxSx4
 f3gRj3RMe391z6UcgZzzJuL9qYt16hDXQ_o5xk3DRFcncDu.Sen4n0xolwIBPo4r8EvCNnmU8qZq
 SDm0cnss4dyX6vyioIg5V5xiND0c1cSmbkCXTdUDm1ZLz3uxT1K_MIJvZCSmCxqznotiJWW4SlTh
 fbf4wkICv0nQqzchTRwIhHBy.pKtben.sCKpyvmmsd6d1.3Tg5NZVP0JWhGuqZcRWuZyMzmjZ8jG
 RME5fT5kyYD8VzJHWD.6kBCAskne_bPbsB4AbJVzh3Vig.SVyi5gTUuhcfQu48PSfm9sAASugFiw
 Ihe0KwM5uEIvbKNlhn_tW6D_5QQOPNNdXYX3mytkyjmCzqNumCPvwiga0znvdvBaZ1LgmNDp21Uk
 8tV3sODNweAWFvrxUHeSYlaS6Ff7lM1BgQ2a4TclH4nogwO2QGFVnoZ8ZtZVeMeWw8.RjpUviwcG
 kFm7yYcvBSv3c575QRRrD6gEsbWsq.R3vQN5bbuHVLS7SBI2hHDYjkcEff2lCyMXyizCirG12IcO
 3M9Fm0NvqmOICnxxbey7P3qSZolL637hCL9q4MKPM_dbY9g_sPE1SY9XLHaUqx35FNUld0hvFthK
 vKbSxzP40f20QIX8_rgwTi01S3z2gM0sUPOT_Jrgw9NI2uDgXV1jrMQ1ZHge.aNuMrGZDAD5klHt
 mY.8x0iGBXS.CjVEWe7k3f1AT1vquCbYmCqXqag_4pCh1GbJH5K6.wIRrmCUhaRvdy9juJVArsg3
 yZdhMB1Oz81j_1LriuXWf.6RcmQuqEzGMXe61_oBcaXwSfeyqGInLyMLAkmSHDReb.iJxFz9yIuG
 m73QVoYAxcVnKEHBMfiE.ll6O4xGw_ZhBFr9JmNfaIK6D0bAz3IrD5GgKDSp43tpotkrHKVD9vWv
 HhWgSAOdPRauFCSfAFssLZRRCjCff1ePyAC7LB4Dr_Osi4OSEUse4K2khivwhUshyzKOZ3c373Wh
 htARrpgHu.LkaoB75z__SS6MzMtK3rz10kmr5oem5s90tUqNrSCf4X6BMIrrNrXjk.99LtJwTK6f
 .O6XSIQOkUjQUpwfGskG4MSE9wa42TNTfTuPa5ZnJvfljtAh8I3Iu0KknbZNAVOuqFt_HA7Wc5fW
 TK0GvN6Cho7ss3PMRMfjbbEWzh7BCzrink0Y.DI8pAy41F4ste8MoDJWoN_bfh0vxSo2z4F.4zjg
 _a7VDucyuURG72qfzn6qhmSCPeW68IB0DXuZLn8hQqmCtVixHLsHQyCNJLLuPOXp.kC_q33tdtHN
 irZn3raGBscPGilV5nc02KlL6ch3ELGVHz1sYiyeJXGDP0l.CceMDKAnkL6l41QwFhTBVk5sPSc8
 M6j.bY1o6bOSVXOaSzIu0DrGrZfgginID1fkoKmCIXIhOeMRItz1ZI6GeWH7v0w0OPYvvELmc6Jb
 E79fmdk_oQE8Uvs2VBSThxIh.P6.H3ifTfZ9djmMC4O6WapA8JIil7Z5usbqSh22u7Qdmk8P6jhk
 QXLq5mFAhlls76wn28sCDjWXabFpaURPUmJbVexbK5On3Q1gjam2NNYwpP8fjNkkHLnruVITV2rO
 uMkIn8Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 19:55:05 +0000
Received: by hermes--production-ne1-6944b4579f-f6tkg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f0a59c08ab471576036e52ed4a3446b;
          Thu, 29 Sep 2022 19:55:02 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220929170927.GB80020@www.zefox.net>
Date: Thu, 29 Sep 2022 12:55:00 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mdkbv0cMpz3CQp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="PU/ORVpy";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.952];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 10:09, bob prohaska  wrote:

> On Thu, Sep 29, 2022 at 09:38:04AM -0700, Mark Millard wrote:
>> On 2022-Sep-29, at 08:19, bob prohaska  wrote:
>> 
>>> 
>>> I'll try to gather a few more examples.
>>> 
>> 
>> FYI:
>> 
>> Building based on the latest patch-common_usb__storage.c
>> that I sent (by itself) would avoid the huge number of
>> sequences like:
>> 
>> usb_read: udev 0
>> 
> [snip]
>> 
>> and make the log files much smaller. Any other messages
>> from usb_storage.c would still still be present.
>> 
> 
> 
> From my point of view the size isn't a serious problem, the
> script command makes capturing output easy. It seemed more
> valuable to capture maximum detail until the problem is 
> better understood. If it's understood well enough now just
> say the word and I'll recompile.
> 
> Size might become an issue, but there are larger capacity 
> webservers available. I'm using www.zefox.net out of habit.

In part I was going by your indication to avoid "bloat",
which I had guessed was a reference to the logging output
instead of the size of u-boot.bin :

QUOTE
The maximum logging level was 4 out of 7, fearing bloat.
END QUOTE

The first "usb_read:" is after the "1 Storage Device(s)
found". Prior to that there is one example of a:

COMMAND phase
DATA phase
STATUS phase

sequence and one of a:

COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase

sequence. I'd be surprised if these 8 lines proved useful
for the "0 Storage Device(s) found" issue.

For issues after "Storage Device(s) found" the status is
less clear and the output would be more likely to
contribute.

As long as you are happy with the size of the output, it
should be fine either way for "Storage Device(s) found"
observations.


On a different issue . . .

I'm also hoping that you will happen to also capture
examples of automatic reset/start-over sequences. It
may be that those requiring getting to the U-Boot prompt
and typing commands. (Has it ever happened otherwise?)


===
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 00:27:42 2022
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 4MdrfT51sdz4d10n;
	Fri, 30 Sep 2022 00:27:45 +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 4MdrfS2mSSz3YZD;
	Fri, 30 Sep 2022 00:27:44 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28U0RgYT081487
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 29 Sep 2022 17:27:42 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28U0Rgb3081486;
	Thu, 29 Sep 2022 17:27:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Thu, 29 Sep 2022 17:27:42 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220930002742.GA81169@www.zefox.net>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@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: <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
X-Rspamd-Queue-Id: 4MdrfS2mSSz3YZD
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 29, 2022 at 12:55:00PM -0700, Mark Millard wrote:
> On 2022-Sep-29, at 10:09, bob prohaska  wrote:
> 
> > On Thu, Sep 29, 2022 at 09:38:04AM -0700, Mark Millard wrote:
> >> On 2022-Sep-29, at 08:19, bob prohaska  wrote:
> >> 
> >>> 
> >>> I'll try to gather a few more examples.
> >>> 
> >> 
> >> FYI:
> >> 
> >> Building based on the latest patch-common_usb__storage.c
> >> that I sent (by itself) would avoid the huge number of
> >> sequences like:
> >> 
> >> usb_read: udev 0
> >> 
> > [snip]
> >> 
> >> and make the log files much smaller. Any other messages
> >> from usb_storage.c would still still be present.
> >> 
> > 
> > 
> > From my point of view the size isn't a serious problem, the
> > script command makes capturing output easy. It seemed more
> > valuable to capture maximum detail until the problem is 
> > better understood. If it's understood well enough now just
> > say the word and I'll recompile.
> > 
> > Size might become an issue, but there are larger capacity 
> > webservers available. I'm using www.zefox.net out of habit.
> 
> In part I was going by your indication to avoid "bloat",
> which I had guessed was a reference to the logging output
> instead of the size of u-boot.bin :
> 
> QUOTE
> The maximum logging level was 4 out of 7, fearing bloat.
> END QUOTE

No, actually I was then worried about getting a u-boot binary
too large to let me keep a few usable versions in /boot/msdos.
I had at the time absolutely no concept of output volume.

> 
> The first "usb_read:" is after the "1 Storage Device(s)
> found". Prior to that there is one example of a:
> 
> COMMAND phase
> DATA phase
> STATUS phase
> 
> sequence and one of a:
> 
> COMMAND phase
> STATUS phase
> COMMAND phase
> DATA phase
> STATUS phase
> 
> sequence. I'd be surprised if these 8 lines proved useful
> for the "0 Storage Device(s) found" issue.
> 
> For issues after "Storage Device(s) found" the status is
> less clear and the output would be more likely to
> contribute.
> 
> As long as you are happy with the size of the output, it
> should be fine either way for "Storage Device(s) found"
> observations.
>

There might be another reason for making changes. Apart from the
failure captured last night and posted, every graceful shutdown -r
has succeeded. The count is now 22. It's understood that debugging
code can alter the behavior of bugs, but I didn't expect it to
_fix_ an apparent bug. It's up to 22 successful reboots in a row. 

Ah, until now. The 23rd reboot got stuck at the outset, with
Syncing disks, vnodes remaining... Waiting (max 60 seconds) for system process `syncer' to stop... 2 1 0 0 done
All buffers synced.
Uptime: 1m16s
Resetting system ...
and then nothing. Plug-pulling time.
Came up just fine.

Is it possible the append a change to patch file
names, like "no.verbose.patch-common_usb__storage.c" as
a way to de-activate them with minimal typing? If it
won't fail to detect the disk some kind of incremental
backout of the diagnostics looks necessary, or at least
useful.  

> 
> On a different issue . . .
> 
> I'm also hoping that you will happen to also capture
> examples of automatic reset/start-over sequences. It
> may be that those requiring getting to the U-Boot prompt
> and typing commands. (Has it ever happened otherwise?)
>
Are you referring to cases where "assisted" boots fail?

There have been quite a few cases where on reboot u-boot
finds zero storage devices, but usb reset finds one device.
Typing run bootcmd_usb0 then results in a pause, a re-run
of u-boot and a successful boot. Sometimes the machine
silently hangs with the Device 0: message. Sometimes it
boots. 

I just captured an example now. Because of the file's
size it's at 
http://nemesis.zefox.com/~fbsd/ 
in a file named 

pelorus_console.txt

By my count the interesting part will be in the last 10% of the  
~9 MB file. 

For some reason the file is littered with non-ascii characters.
It can be viewed and searched with more, but the chrome browser
is only willing to download it. Attempts to view it fail with
"invalid byte sequence in conversion input". I'm posting it 
anyway because it's a rare event. If you've got any ideas for
cleaning it up so it'll display in a browser please say so.
Script seemed to work fine for the first capture, maybe the
huge size is the issue. Perhaps split would help, but I hope
there's something better.

Thanks for reading!

bob prohaska
 

From nobody Fri Sep 30 02:14:44 2022
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 4Mdv2741PLz4dfyV
	for ; Fri, 30 Sep 2022 02:14:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4Mdv260NPXz3k9r
	for ; Fri, 30 Sep 2022 02:14:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664504092; bh=6ZW1K5/4lrYw2F2j8ngpat6GonTqgpZYPVarFyzd/LM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CVb1bzgm62bPvxq/KbubqfLhq3G2tUua4RpHg1aV9zB8vMpbZos5ooovMo8YB2v9x6szq0AzaaNchjNHztGBYxaBXUZ46+UrfO5ieV03tgzWA6a48aQmyu7hHPOvWwObgWyzXrL8JOOEtfn1+zBIpklZvL6EGZtMHavcehvROJ9VAkw7mDOBbMgyuHyE7mzw+viM9SSB6vT7WD5U0j+f0naG+19fa/fujmkxgLkeL2gbk7n8blaf4H0rGiNt9HaevcIacRJxckxEvxpnsmorFvmiRGmddu58safEhQ1r2RrD1rA9X4vvaNaRNEb/mpFyKuKdDLHuBC3zUHEnavzt7Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664504092; bh=p2c6wzRel1nL9Y5/YXWdZt3MCKa7fvMgdTi2fIT2erU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pi8Y6DXcGHUjPNBvxl+A54skXC2rxGOhep6fcC8xdyaTbVq4FF4mshRTZxnNG7tBMPn7W0qbggNVjbFPP83/H1osmQSOZfjgmDQGJH99jbDrkEPsOUW6aF9Rw44I7o+Sl/X2FbnZykhln183WnEDcHEgzFXYPe8yNOx9F0YOztKAAjySDpKZ/GRd5RGVGCIqMlG4CVYnqIOwrTw7Qboa5Ep9dJyWvg6nEAVOMEPdCCxyX8IDFqss1qHM+fBT+l3aFqJDpBShQoAFCVWZM23U9yOK65jrOQD8nRXC0DZRGvqO4nG1HMn3c6Odbbh3aa8LtB7trRgmNpLqtVwwhKfvSg==
X-YMail-OSG: fjWfIsYVM1nITSgtXvU_x6CVNkbTKsiyS98eCUWNaCyExeg4cldW6UAKRuR1lKs
 Nt.e16A_W4L3rhhE2PrMC9a8SE7LPLb0dJhHUT.p2nqK9wsszxNV8RmoEDnVA.4twtQvYw1h2nHD
 vmVYjtHpCRvqPF5VoDhp1pxWD5fv7o5IhIcYdCawOPsBlFJzyM1D1dD12oUEgHu5ULjIl2xMlay2
 ArosUdlNOLZkNEne.Uw91lP1KlHSzeuxMMSds5g_rsKNQGmhPEFURFZLwJUeThDiOeOdeyvVYPbK
 tdc.6ff0EXMs_Ha_zzgTiQoz.KM7VmUPE0uDd5u3NN8mzVeRPovxTAjbXaZRThvGN_BhvfTDTZCI
 KXk.RNT5bCNBm9szlOqOkOpCHH9BY8xkTaZETaqQO1NkL4QDJta6VXTAo01Bx5VDo5jZwLLg9BBg
 vXxvOBtjqhhFogOtooKmuJLak9KbtbXY4FVEFIaDyWN2baj6YtkcBAsMyTZY4omLelyvqI9u2yl4
 pDXzyJ4FE426D1DS8s9lVoPo4KzzCeWtpDyKHusL1QtcStIln8o65zejnhKT0gJIyMBwFYlVRjUL
 r3E9rpJjJ3ZsyWSuDsx93fI2.PMMTS3dUNYp8oiNZWFzLU7.ij9Jx.UKvQNbXRcSoT5ryCYYSAvy
 CjGgzAgIx8PdsTLVAmcHGlIpfSdPf5VJKDqE2CgyaRMLvpgtmjIEZMsZdIiK9Ral2BqTP3VL0sUY
 lebpxLPyVcfmtzApBYHuizgtdWL6RG_BycoHbFWNpzXmRul.cHn8Gl3r6.zYvD84uzoJ1lGjbKun
 2dGNXR31TvbCAsPaK0ulT.x6uLKfuYjNNCYjF1hdfUX0aXaExhI8HdQfKR__UQgzN.R3STKL_UeC
 LrtFGBetank.tPRC0ocYJgfuVu_cHa73tVLBufw10S8hU5SQOsp7VUiysufdkBSveUjd3fyGQmlb
 9at5L_AlohcbmfS1tfzQhWjQ9zfGX3Efs2wN2.x6I3R7CPXrOSAuK1g.P.FwSw4dy8WI7wAE3w5T
 gsGtaEPtrxnjm56bxpOzvgt_SlkMb0vGhL1sRTwHGy4Z7AQSfWA4QUnlAo.8wPBlVrkPev4nB4DV
 ZrMCW_xjf6lQkErF5FThgnELU61rpXcnBXjbXerbVB1FObAkAGBgXHQkXgGBcqY8LPaGquaG_bzg
 HBxXJPy9bYomxNnR7NOHznh0aeg37QxBs24BwWS6_W_AFv.fX3b9pgfFvoE.gIJTTJiT3bzczuRU
 pd.u6T8oHDnyV50ZRHTngbLbYvawy5Pk4mjYhcUw.x7I0q1CHfEVJKAujzF_KEhiEbrN4KWaud5n
 hIlag94a8T5o6sK_ESD5HnRB.8C6FbVN66fbdsJmJbwdCC7Mf.W9lLQS45WDaUVkV6nklm5sFWP7
 oHn9VW0_PAMfTElkjSG9GBjAmMAxtpzP2XWwGJ8f0kGS9jT5UIOQ0LYLQMbjeScYyOkLRzuI0b0.
 Qqeaeluwk1Oo.sUgObEn8W_D1PAzwNJy_gKbn82Tbo2Hajp4Ndb5VFX.14zLgpnbhNnRqEYCiypr
 PmE6Tjg_h.tN8pE6ICsDKgM6XQTKw7Dvp_bz5tkNIPfWG16NBb9Qr3emliQROyH6BSfPKL6JCLIh
 UH7QvTouTOrVya0d_COOaMFVDcJHP1YvuXZX46atTKO7RoGNiwOmq.gaxJwG.FnLbqX5zCmbNe0A
 edjFOQTl8ROPB4jTsKmbQupdX6iniUs.1SiTm0IV6tVywlc0POeCs_qzNnISZobCv5G7_UAjo0Id
 nEZHMKPi.Mbe90DDx2Gix1GRgt9p4prX8i2yFeVI0qtp_L.crKaAv2hs.egqRFNkD1gjaEyhC.cL
 rlWrqcRGN4LdursS9A8MVQNsXTqFKIhfqI9HuGE0_U1Jw1m7fFzMBZKC78.XEgQSRT7krOYf_0K6
 EWd2Jug1D5NuQf4ntGCYWVx06agaw45C3aNjE0DNqTKeqED7qduLxO1Iil0d2wp6wg7D6O5DmuJR
 cAht3O62nhXAmNpnA7KzWRYUBbGBPSkjDzFs9Hw0Egj_K8WI0XaexKabTVQwRN8R4SpmMwxHApfd
 kDYuZcQUZwt905SWpTpMCWvtYAJzaFqg6YqWbV8HdKpEkFcpWsp9vIIzR_NBZOTupAwpsTctSF1X
 nWQ9GAWVGuxII66VsPb70dg.FEuEz1Kd2R1iu4nCk5JvW1qz6Ksz74rzhBucRWV0._9UCoZ_G3NV
 g4H1wpM2cmKS0oh_crsL7ICw_tKfqUVZfUae535nXVRgbmLfBPfpQo33hXl2fBgl11p2BpsBJBij
 f676jtRtIag--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 02:14:52 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-vstzd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3f3831060bf4f328a6b33aef608e58cb;
          Fri, 30 Sep 2022 02:14:46 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220930002742.GA81169@www.zefox.net>
Date: Thu, 29 Sep 2022 19:14:44 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mdv260NPXz3k9r
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CVb1bzgm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 17:27, bob prohaska  wrote:

> On Thu, Sep 29, 2022 at 12:55:00PM -0700, Mark Millard wrote:
>> On 2022-Sep-29, at 10:09, bob prohaska  wrote:
>>=20
>>> . . .
>>=20
>> In part I was going by your indication to avoid "bloat",
>> which I had guessed was a reference to the logging output
>> instead of the size of u-boot.bin :
>>=20
>> QUOTE
>> The maximum logging level was 4 out of 7, fearing bloat.
>> END QUOTE
>=20
> No, actually I was then worried about getting a u-boot binary
> too large to let me keep a few usable versions in /boot/msdos.
> I had at the time absolutely no concept of output volume.

Ahh, okay.

It turns out your capture of an automatic reset needed the
read activity details. It has:

. . .
6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0

Device 0:=20
usb_read: udev 0

usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
read10: start 0 blocks 1
COMMAND phase
DATA phase
usb_bulk_msg error status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -110: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -22: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -22: status 0 clearing OUT endpoint
BBB_reset done
Read ERROR
COMMAND phase
DATA phase





Raspberry Pi Bootcode

Read File: config.txt, 265

Read File: start.elf, 2952960 (bytes)

Read File: fixup.dat, 7314 (bytes)

MESS:00:00:21.193325:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:21.197789:0: brfs: File read: 265 bytes
. . .



So, apparently, the RPi3B (not just USB) reset during a
phase of a Read's activity over the USB bus. It never
got as far as reporting the STATUS phase of the read.
I've no clue if it is some form of watchdog based reset
or a power based reset. But one of the two seem likely.

I'm not familiar with the result codes, endpoint clearing,
or the like. But at some point I'll try to figure out what
-110 and -22 have for names. That might give a clue.



>> . . .
>>=20
>=20
> There might be another reason for making changes. Apart from the
> failure captured last night and posted, every graceful shutdown -r
> has succeeded. The count is now 22. It's understood that debugging
> code can alter the behavior of bugs, but I didn't expect it to
> _fix_ an apparent bug. It's up to 22 successful reboots in a row.=20

Serial console output takes signficant time and can significantly
change the timing of what is before vs. after the output request
in the code. The extra time can make various type of problems
either more or less likely to be observed.

> Ah, until now. The 23rd reboot got stuck at the outset, with
> Syncing disks, vnodes remaining... Waiting (max 60 seconds) for system =
process `syncer' to stop... 2 1 0 0 done
> All buffers synced.
> Uptime: 1m16s
> Resetting system ...
> and then nothing. Plug-pulling time.
> Came up just fine.
>=20
> Is it possible the append a change to patch file
> names, like "no.verbose.patch-common_usb__storage.c" as
> a way to de-activate them with minimal typing? If it
> won't fail to detect the disk some kind of incremental
> backout of the diagnostics looks necessary, or at least
> useful. =20

One way to deactivate patch files that are not explicit
in the Makefile is to move them one level up into ../
( so out of files/ ), as I understand.

Another way is to change names so they do not start with:

patch-

as I understand.

>>=20
>> On a different issue . . .
>>=20
>> I'm also hoping that you will happen to also capture
>> examples of automatic reset/start-over sequences. It
>> may be that those requiring getting to the U-Boot prompt
>> and typing commands. (Has it ever happened otherwise?)
>>=20
> Are you referring to cases where "assisted" boots fail?
>=20
> There have been quite a few cases where on reboot u-boot
> finds zero storage devices, but usb reset finds one device.
> Typing run bootcmd_usb0 then results in a pause, a re-run
> of u-boot and a successful boot.

The explicit evidence so far is that "a re-run of u-boot"
is better described as "the RPi3B rebooting", starting with
execution of the RPi3B firmware and later again getting to
the stage of u-boot.bin being loaded and started.

> Sometimes the machine
> silently hangs with the Device 0: message. Sometimes it
> boots.=20
>=20
> I just captured an example now. Because of the file's
> size it's at=20
> http://nemesis.zefox.com/~fbsd/=20
> in a file named=20
>=20
> pelorus_console.txt
>=20
> By my count the interesting part will be in the last 10% of the =20
> ~9 MB file.=20
>=20
> For some reason the file is littered with non-ascii characters.

So far it looks like a binary capture that has every byte
sent out in it, including escape characters (ASCII 27
decimal) that start escape sequences for controlling a
display. Also, every Carriage Return (ASCII 13 decimal)
and every line feed is explicit.

There is some text at the beginning (after the first
"login:" that looks to be junk so all the following bytes
up to the "Password:" after the junk should probably be
replaced by one newline or by nothing.

There is a sequence (using ESC to indicate an escape
character):

ESC[?25h

that occurs 73225 times in the file. In my normal binary
captures of one boot sequence I get somewhat over 4000
of them as I remember. There is interesting text between
the sequences, commonly one letter of some overall text.
I delete all instances of the escape sequence to read
the text with the letters next to each other. The delete
is via a find-and-replace-all that replaces them with an
empty string.

There are 522 more escape characters that were not the
beginning of that specific escape sequence. I've not
analyzed all the sequences so deleting the 522 ESC
might leave some not-normally-displayed text around.

The Carriage Returns, 344121 of them, can be similarly
removed.

There are some ASCII 8 (decimal) characters in the file
as well, 1348 of them. ASCII 9 (decimal), 377 of them.

I think that is all the characters that are less than
a space in the ASCII encoding.

But I use some text editors that are good at dealing with
such content (but I do not normally deal with such via the
headless or plain console FreeBSD machines).

> It can be viewed and searched with more, but the chrome browser
> is only willing to download it. Attempts to view it fail with
> "invalid byte sequence in conversion input". I'm posting it=20
> anyway because it's a rare event. If you've got any ideas for
> cleaning it up so it'll display in a browser please say so.
> Script seemed to work fine for the first capture, maybe the
> huge size is the issue. Perhaps split would help, but I hope
> there's something better.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 04:11:18 2022
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 4Mdxcb3bt4z4drDY
	for ; Fri, 30 Sep 2022 04:11:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4MdxcZ3Fv3z3q1x
	for ; Fri, 30 Sep 2022 04:11:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664511084; bh=naKN6G8iKunVVPpR73GeDGnaQUdxEc6QNZtLC8GciVo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jSpje49wIxs4XscpzlSUv8QrQfQXow0KxqsOnfg/vHaO1wBkg8vufg/ahTMC+x4lo0XejAYoWCapQEzFtbFnkVR55ED4MAtCDK/UZgkb75fV3+cxreCxB9TSfjvrKd67Bh0KEGuDyHexJRxc4zN95rtM/7eb06jEorferhUzilo+72Ht57pNbfRQWnglgICPHdBSMtor8lvIPsSRW4HNxoxwCWUgC9crjiQjPiv+/ptfV15sSMVCYbOYYu2trrACgb8AsfmPJlJipu/oGrFHDzQN7BD/3bIU8G99ukaCJtwGnaS5dqzhkYxD3wPb8SUWoj4vSF0U0EnaexyG1Q3OPQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664511084; bh=3lX73OoqBdT5iLGBBBhiq5T5BhCPWGXyKI/D0mxck3E=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F5ewyO4prfogcY8tih4yP1U2lI9qWMym7PKcyH5euupfXl8OldT3SlYK0IN5ZXYV37DIDNlOUjiTksQGfjxFNVSh/yBmarTSFW7xrkENXC+onKhQO+A10g0Ga/i/wazO/9B19AaN3jTfE7ED/TQ94uIFYAizdG5HMGdMhcd25Xe7cm0uIB+Zc6x/Dwt0mqUWSTk7tEJ5ISK5ZtLOl5Dm4PDku8zMGt4M/mLcut3mqiAW2Gcr6EcnN7ady6c9FQB3Jq3sbLKXhaGj3n2hMqcRxiYu0KZjGZPU7ayi666lXmIsTiF+d95/noDpX0kciUOhxVW4FOWXInBmmZfVtd+33Q==
X-YMail-OSG: gvXdmMMVM1mXskVfyG_b.7xvv7ZoCGhLq6aLKRWlDfjA68dd6xlg3vUdlpOiJCD
 4R_zX1lEeBZyReZ7kjADxccwit1Y5q4E68MTLQuhk5dA1HxhRaeQyML5fmJ8PwCVM5nraBmxTlPH
 1vcffKrDxSynypIDlxbH5kW6ef6vWhGAga7kIVkWrG3h.L5s6IBzOc0gdKh7W.f1tmneI9R8rbxM
 BlAOfPDN9FGsWX4oCpsYfcROubxqrGNNN86rgjjarKh_99A75HhtDcvdkzR8I3n3MVoOS8_EZmYv
 uaIT77m.OLnUUh.VDX0Tq3C1O_sDJ_TDRJLYwdRXKfsHYwEFAa.EBpZvZz5dWwQHApGmUMOackvH
 1_5Bajg12Mij1Xfk1EP14AOYbZ4beduw6AgoSf3GvN77aKd2EOnFP8TCZRSqJNJ8QZFPsnwrSIlc
 dkDDwHG.ZqDrCLAcy55Gdzic82gbucBakz6BeyITrZWTj.RrPGFBkS0XOyabCoVsaYj6TEM3ROJd
 znP9tMYNV.lsGvq4E_pXbLvCbDMufCTOe7axGZkvsnONznKXHWTFvkLOi2jwaJbPoT6859gLWMkP
 XPgqHDg0O69BfV900RKRVCw3zC5BSA4ZC2oxDXBGsN2U_1YC2Q7eLt2FffXFyxqKK1SEFhCQxJl5
 X045.KoRjLm3D3zPTfeykmES1ukSGWajbN_4X5fx_JYaBGwU1AFLhEby8Q.Q._3njy5lLToa8J8U
 fetSIHfagSwN1QJ0dbdXEcmvWy7HYa3XYTLRotBKyTzbBIZ7biKN1GdDFPz7FKBA1EmZWsjVh1cj
 9hyJWLT73i8UtZKfyMqCITsrnrSVq7Q8GyU6ZL0OAj0Fkn91QTms0q3kRvyizuYx1bHCsNHYU2FS
 a1webVsnTZueuWCl3IOsgJCuMOAJkblA4Ro7IlDuzHPrit5vhepT9L2zxrqzmRcO6oxDMXNstoJL
 8TtFw3zipvDmmq.748IbGF0F8ANYVdsHI8mlIsI5FndliNXT20D0Kn2JTTHjUzJka22arIBshUSb
 iCS6DpKV7OwewnWEUaKIO9d.N97ImG.T.gMLTDgBVZUBOHvUrq0R9IUWB419bmAXbduX2Wc1I85w
 YHJOF_ceCspcHPQi4cbeCih1_QhAg.tf7Uq.QNtvi8tzESO5JGJ9UAHHIKZUZpOQDljtbW_PzMx4
 1jb6ceTQ9RXQJvudHhAROeCFmz7rpOuU4gZuPmTOeoqLSEBkdTcY1j2WMtQ18.qyC8SKoPeIRQPz
 QUJnKkyPisf1I1ZBvYzAoh1U3BmIXZeqLWshsp9sgT3skhjybJCoE4qlvxBAGLK_UPWFtkVrT57u
 spNHMHQQeKoNOUYybXFL6sTgq1LwqUXDl3UtAlTQNyaqIzwNM6wbVeIx4JB_xsdCkgIuosZeF9wY
 ePB7aZKTSSkEAxKykpLc46uEIJzzV6LZjPqf2jXpSeiZCH1XsR.WW0veVtmGbgf4F8G3tGyrkefi
 Yg7EKU6mQqSnCRXoY7_8eMH1MEB1dCCpJd4M8Y8hH6bd7V6vMsD1OItpnQ1f5agvmFS2PhD2ADDm
 grl2nRHqjf1o4bsoRYOmj9JRux8wk6ajq0e501CgDDRR8IFDa4.nW0SYe7plFu7854HHlnrrnLIS
 LIC1ZGbbKpQ4ux1wz.AKCU6eeMuwTZaAL31ZMCN3Lz9HawNWlW58LdjKuYkq4giCbeDmU64DIhzm
 TJ4QNsBHcD.fErIy.5HBU1hAB74n.sr0NMmYIzoFtIbYzHko4M1Mchr7VG.NaKDBW_H9y5PVZvwh
 jT1rDOjsC4ggpg0hhlvw3S6Bbl1ft2pCTXrBfXchlspJe814o65AsdVMuJU9clitE0zBEpySE2Pu
 04AuZDFSzdVU1wWout1DJ_EaZME1_V0x_mTjDLMAGW9_QgpYebW9D10UiUvDdsOaJPZVhUfVzIrW
 1L1FZf2E0fznSVpyczPCejA8jLCnn8CpVX634pDB7vvEvq68BtShM6mVTTgERnQlbHjibM3kxmAh
 P.oiQixL_.9tS9u.37n5rjJBkpLL5t_YicJ3Vc78T3mQqzzR_dhhutLtN7uondkoIwYhCnnNfoQ6
 HBAlTR9eArvsBiiNZCO21sUlvG99rJ34geZkoDPiYNJ_X2QQFLyeuT9InxpBNN5UkQtaTxqSKqtF
 qGv8wsXnvFbnUNcM4Dt_Zp73Qzb5oV4sOJOFPhSx9FGcXgdiuc7jNJGxi.kZ6HC6bdanbcENrQo_
 iyYBL7LXLznoTRQI.eeu.4GTytohaUQ6m3htCkvf5s4SwCD68.soTOAIU17k2XMgpPC4rn7p5dw-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 04:11:24 +0000
Received: by hermes--production-gq1-94b89944-j9vs8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 85ba77f284506ddb7338690092eb41a8;
          Fri, 30 Sep 2022 04:11: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Thu, 29 Sep 2022 21:11:18 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdxcZ3Fv3z3q1x
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jSpje49w;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 19:14, Mark Millard  wrote:

> On 2022-Sep-29, at 17:27, bob prohaska  wrote:
>=20
>> . . .
> U-Boot> run bootcmd_usb0
>=20
> Device 0:=20
> usb_read: udev 0
>=20
> usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
> read10: start 0 blocks 1
> COMMAND phase
> DATA phase
> usb_bulk_msg error status 0

Looks like the above is from:

        result =3D usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, =
srb->datalen,
                              &data_actlen, USB_CNTL_TIMEOUT * 5);
        /* special handling of STALL in DATA phase */
        if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
                . . .
        }
        if (result < 0) {
                debug("usb_bulk_msg error status %ld\n",
                      us->pusb_dev->status);
                usb_stor_BBB_reset(us);
                return USB_STOR_TRANSPORT_FAILED;
        }

(result's value seems to not be reported.)

The above code's usb_stor_BBB_reset use initiated the below:

> BBB_reset
> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
> BBB_reset result -110: status 0 reset
> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
> BBB_reset result -22: status 0 clearing IN endpoint
> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
> BBB_reset result -22: status 0 clearing OUT endpoint
> BBB_reset done

Looks like -110 is from a:      return -ETIMEDOUT;

Looks like each -22 is from a:  return -EINVAL;

The -EINVAL results seem to be from usb_clear_halt
doing:

        int endp =3D usb_pipeendpoint(pipe)|(usb_pipein(pipe)<<7);

        result =3D usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
                                 USB_REQ_CLEAR_FEATURE, =
USB_RECIP_ENDPOINT, 0,
                                 endp, NULL, 0, USB_CNTL_TIMEOUT * 3);

        /* don't clear if failed */
        if (result < 0)  =20
                return result;

usb_clear_halt is used twice, via usb_stor_BBB_reset :

        pipe =3D usb_rcvbulkpipe(us->pusb_dev, us->ep_in);
        result =3D usb_clear_halt(us->pusb_dev, pipe);

        pipe =3D usb_sndbulkpipe(us->pusb_dev, us->ep_out);
        result =3D usb_clear_halt(us->pusb_dev, pipe);

> Read ERROR

This is from:

retry_it:   =20
                if (smallblks =3D=3D ss->max_xfer_blk)
                        usb_show_progress();
                srb->datalen =3D block_dev->blksz * smallblks;
                srb->pdata =3D (unsigned char *)buf_addr;
                if (usb_read_10(srb, ss, start, smallblks)) {
                        debug("Read ERROR\n");
                        ss->flags &=3D ~USB_READY;
                        usb_request_sense(srb, ss);
                        if (retry--)      =20
                                goto retry_it;
                        blkcnt -=3D blks;
                        break;
                } =20

The retry_it getting to usb_read_10 again lead to:

> COMMAND phase
> DATA phase

So it is the retry using usb_read_10 that ends up with
the RPi3B reboot happening instead of completing.


I'm not likely to manage to give this further interpretation.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 04:51:31 2022
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 4MdyVz74FCz4V1JP
	for ; Fri, 30 Sep 2022 04:51:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4MdyVz0WTdz3sjX
	for ; Fri, 30 Sep 2022 04:51:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664513496; bh=m50Uis0CW1IlML3uSmDiWJaQ3gIQRiOYvIO3CAmmqts=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bFcRbbQ1ou2OZVGKOMgAfgOBcwIaLR2UXcMflv/E9eTX1zZCiRom8nPY86jCsUuinDk38eHe/jcLNl0xWYBMHyheH5xFQ8r92OnT6pQXyNqstj2BBEcv4enh8eV1CcYiEXFWhmm4bsxahtbiVC5V/jyn1pd3N1YsPRBHdVF/XrFP1pSe727j5T1fPxLEY9YWkFyOlVa23tZ2ltvgZxnZ2VuwfO701g9u2LxqC9iaJBQL0+18LhmHMjb1Y5Sf07Yfq76/QsbTkUDrTBQMkvvJBLauUtlnNhDvjrpG3hM7PteKt0JOqNGIvFFARYNVqv4wNPq2UrL0eUe5fsI18+pLRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664513496; bh=QZtPhdQ2iOykevIqQGyiK86unJWFG7iKBOxY1DbWtcL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OAi1KKlwzZVCPXU/g3KUbXzWHW6fLQuuWS3TGNP66r2ls1YUnKLVW+eA9Bio9wtz9piTakglizf9LHuHCMedrwFCeW+2Y3nWSBsJOgp63mSCsg22l6LkQntJH8SXAk7fwwcxvvUvQbdJFmL+bywVTK2Ujf20EvYCovO3/KJBCmBPBbY2FLEubLz+qaFBw4Nb/xijizhd62aN+2CM0Se5DHr+UEJzJjzKV2DLhi/usnK5NzoWbKWRe7sJsFz42QCs4CBo8ABwG9QbswAyKMyG/vOuP55FU+uwpAnVlFZgVq3boUpW2ccMqqaWtfB+ZQKGBs/bjap74s2J3zPPa3FHJw==
X-YMail-OSG: NruW3qcVM1k5rvXDiEDxtWEgKejHOYnY3lk1uSbZ3FFOqCcRb11Frtjfbi3jhMe
 ejCmA5PUJRW3zKqvxA1GoWKt536tSDClyM47Ae_JTHR5jbCNFh.PDYE2t50z9T6946JWIKriBSMV
 .TmHMljsM4_ssxbyUo_GbNW2eUVQJhoNgwq4WQsoy0PsR8KqwEuY31eRevXgeVj9PVWklB1P07Uw
 1fN_XKeoOMvcOzFW4.BcaIAeomjlJ59zi.wDDf4mAxg7WFmLO3yxZA_jO4ssIbthgOGhCtJGKdOM
 Sv33m8jsqRT.FFcyl6lnvpIPuhVKfXBsS2tg8deGmWTGJKTlI__6uXUTAQ4lCi1DNXZiLOZ_Pa6T
 cPunSj3o0xxS2kBBKhL4A1YTnDJ0Q.VZKBVGVj_6xjKE.b1p5LcZEt9ITCkTWO7X_Bw2NcTIoi.0
 6f4qlm7F25g4CsQb8NCjyZjqms.UVLSAkkOOB7jmi2.WtgirHOGuBY074f.WZoWbR2i7pwlJEV.N
 cRUjO7BTeQDNkCuaMW2l2CuSDlr9PsDd.zCYfTmKXVj_wAbw9xURAS9QNRabKuVyJagO2qzlU4.Y
 2LfaSgGpEWq0k2kQ57EqcaXkdnT526ArutkvIEjXVIkqlahdDRFF6AEl5CT9ZGGiJnBBACn.Hyvm
 JF0wS6YTLApTkQwBRiuJ3Zvxuitw2TSiD9elE4dOci4Y6EJDtccqx11NrXXq8ul.RZ3f3BGF0pg8
 n.kn51S3gd8bC8qOV2SX5Pf7WzbwoFmcRptoWDWYXojtRKAZESVk66LFgeagFXeBOeYHWyeK5cat
 02AnlpNHF9EY20TkxaXXPNwlUZwMiOjd0hviQhNvddqwazZp0e7GVft4HMD0Z7c9amxXEFQmB973
 i08Pn5mSnBbzNN6N.DwExYFahYWAIqb0rDNBnN9WlPbmrASJsdPXDoVEbm9i8Wi.JLGGo3a528ZX
 9QzgEStOdrRM2f7WjzNH3azQuYrZk_iSzA7FwCB2_wwaoK7SgJ7GSY0vFkMKgXediZEWVXN4GUCR
 uTVw9X3tJX1Ih0nSUUsKT5AgfKhuZ8To9a.sQa.Z3MgYqMCRDwrdR6WraonOTDokeKE_4Vnv76UV
 6EAXJSNu7j_KgI4zh3lzemGD3g02rEFuw.q_JhWQIcneVXDoJo.12f8ykoF3n1HmEFkuObScvps6
 Fbytr3EOcAYYOa6iAo3kHWwmVRiMob4ElwNOiVyEIzbwzJNp6cGF0Wm5USP.B4g5DBpusmvL1JEG
 qWbTuEdGrKnrV_VgomZnV.uXPTsdur8MTODRXCB.tnXpVecjIpO7JpjaN08fu_abTNNHQzChiFk7
 0Fa0dOnCCKV_jU0he1lBUy4HDJp.ujfEj8ikY3jF.CO6HEAw9BmlVjrvaTk.WG3Ww6YgmSaa6MsL
 IhQLPIePL46uPPdnjyBiquJfx2Cl2VF5wm8DbUhDmoDQdNFADLNmVpS_ZBEZtGyWS681CUdLwFPu
 ImWjNFCLHXOiiIFjcEmpDkVJnHMZEExzbNAo0Dr3BvbPuhCLhOuxDlYIoyisBn8l0ri70YdN.6oq
 HkTntBBTmann53mWRvSpUNqar2B95rIVnx67rC7_ZuQ6ZpAkuuE9WWooIT2sy45Wj3vyYxT4xJ.k
 VSs3Ykt1NQHBFR37kpeHaHO_2nFvm5_SWpQ8fedn4DnHdezx10mURmVWx4rQwImiyzjRdF8aUDwu
 3GBtlPRLPEzc7wVUHESaq7pj.VyAqqzOJQWUX0f4rfFEydl70ip_mGtfhTRCK7j44npFx7_M4hNn
 TFHC9ATIwhE7HKnv_FQAib6b0c2Sb1KtqpLEPVLyPtbxrpLBbnIRz1Alas36ZsSqmAH2xB.lVQFl
 qxSGhs63JHPyyLXaMQAZpknYqq6zodUmjN.IYDSubdzxa2HFjZsOYYno3pxtQKEFARg.fKJrUczN
 siAl5wFVfrAWidijnIlNXxhvzTESEDPle5A4vxjp7P9Lz6ad9LoOCt7_Pgx8TBAsmEUHDj9O6nPp
 2ZKxOuc0KQoFHInUm.8O5qiL5sxuBVnUGcZ8pc33Bg2pK6cSj195AZ44zX.J11mDqWSM6fWrJFc6
 2O9Cphdp3scL0mYYFY5I0luIuNyZB9LzOSp4sQ8866Nl_94WxDe465c_1DQ2kO1.GjRE3ePLuJtk
 pPlF2DD_rf1.zLpxn5z4N9dE5ZgC9Egr5JMuURydg4MLbvHjUzE9NV.izM1lUPSG55wCY.IbeEkK
 V1QkSmgPN8UNR5ISL9BTdwsxgXH6XpztTpAdnaF6cSNLU2V1TgMbCTOwHB4HMZrIyVDDCN.nZ5w-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 04:51:36 +0000
Received: by hermes--production-gq1-94b89944-plgtx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72372fd14dd8f3db89e734b4b4641490;
          Fri, 30 Sep 2022 04:51:32 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Thu, 29 Sep 2022 21:51:31 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <748A5596-9F39-4036-8D07-5AF098AF0289@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdyVz0WTdz3sjX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bFcRbbQ1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.27 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.77)[-0.774];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 21:11, Mark Millard  wrote:

> On 2022-Sep-29, at 19:14, Mark Millard  wrote:
>=20
>> On 2022-Sep-29, at 17:27, bob prohaska  wrote:
>>=20
>>> . . .
>> U-Boot> run bootcmd_usb0
>>=20
>> Device 0:=20
>> usb_read: udev 0
>>=20
>> usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
>> read10: start 0 blocks 1
>> COMMAND phase
>> DATA phase
>> usb_bulk_msg error status 0
>=20
> Looks like the above is from:
>=20
>        result =3D usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, =
srb->datalen,
>                              &data_actlen, USB_CNTL_TIMEOUT * 5);
>        /* special handling of STALL in DATA phase */
>        if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
>                . . .
>        }
>        if (result < 0) {
>                debug("usb_bulk_msg error status %ld\n",
>                      us->pusb_dev->status);
>                usb_stor_BBB_reset(us);
>                return USB_STOR_TRANSPORT_FAILED;
>        }
>=20
> (result's value seems to not be reported.)
>=20
> The above code's usb_stor_BBB_reset use initiated the below:
>=20
>> BBB_reset
>> usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index =
0x0 length 0x0
>> BBB_reset result -110: status 0 reset
>> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
>> BBB_reset result -22: status 0 clearing IN endpoint
>> usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
>> BBB_reset result -22: status 0 clearing OUT endpoint
>> BBB_reset done
>=20
> Looks like -110 is from a:      return -ETIMEDOUT;
>=20
> Looks like each -22 is from a:  return -EINVAL;
>=20
> The -EINVAL results seem to be from usb_clear_halt
> doing:
>=20
>        int endp =3D usb_pipeendpoint(pipe)|(usb_pipein(pipe)<<7);
>=20
>        result =3D usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
>                                 USB_REQ_CLEAR_FEATURE, =
USB_RECIP_ENDPOINT, 0,
>                                 endp, NULL, 0, USB_CNTL_TIMEOUT * 3);
>=20
>        /* don't clear if failed */
>        if (result < 0)  =20
>                return result;
>=20
> usb_clear_halt is used twice, via usb_stor_BBB_reset :
>=20
>        pipe =3D usb_rcvbulkpipe(us->pusb_dev, us->ep_in);
>        result =3D usb_clear_halt(us->pusb_dev, pipe);
>=20
>        pipe =3D usb_sndbulkpipe(us->pusb_dev, us->ep_out);
>        result =3D usb_clear_halt(us->pusb_dev, pipe);
>=20
>> Read ERROR
>=20
> This is from:
>=20
> retry_it:   =20
>                if (smallblks =3D=3D ss->max_xfer_blk)
>                        usb_show_progress();
>                srb->datalen =3D block_dev->blksz * smallblks;
>                srb->pdata =3D (unsigned char *)buf_addr;
>                if (usb_read_10(srb, ss, start, smallblks)) {
>                        debug("Read ERROR\n");
>                        ss->flags &=3D ~USB_READY;
>                        usb_request_sense(srb, ss);
>                        if (retry--)      =20
>                                goto retry_it;
>                        blkcnt -=3D blks;
>                        break;
>                } =20
>=20
> The retry_it getting to usb_read_10 again lead to:
>=20
>> COMMAND phase
>> DATA phase
>=20
> So it is the retry using usb_read_10 that ends up with
> the RPi3B reboot happening instead of completing.
>=20
>=20
> I'm not likely to manage to give this further interpretation.
>=20

You generated 2 more error logs. They have (among other
things) . . .

pelorus_console.txt2_boot_loop ends with:

       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0

Device 0:=20
usb_read: udev 0

usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
read10: start 0 blocks 1
COMMAND phase
DATA phase
usb_bulk_msg error status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -110: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -110: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -110: status 0 clearing OUT endpoint
BBB_reset done
Read ERROR
COMMAND phase
usb_stor_BBB_comdat:usb_bulk_msg error
failed to send CBW status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -110: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -110: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -110: status 0 clearing OUT endpoint
BBB_reset done
Request Sense returned 00 00 00

(Then it repeats, starting with read10 again, over and
over.)


pelorus_console_txt3_bootcmd_0_failure ends with:

       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0

Device 0:=20
usb_read: udev 0

usb_read: dev 0 startblk 0, blccnt 1 buffer 3af42c00
read10: start 0 blocks 1
COMMAND phase
DATA phase
usb_bulk_msg error status 0
BBB_reset
usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 =
length 0x0
BBB_reset result -22: status 0 reset
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x81 =
length 0x0
BBB_reset result -22: status 0 clearing IN endpoint
usb_control_msg: request: 0x1, requesttype: 0x2, value 0x0 index 0x2 =
length 0x0
BBB_reset result -22: status 0 clearing OUT endpoint
BBB_reset done
Read ERROR
COMMAND phase
DATA phase

(Apparently it hung up instead of rebooting or repeating?)

So, at leasts 3 different patterns of -ETIMEDOUT and -EINVAL
results in the BBB_reset activity, each of the 3 having a
somewhat different overall behavior.

I've no clue why the mixes of -ETIMEDOUT and -EINVAL happen.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 05:23:20 2022
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 4MdzCf5bynz4V44J
	for ; Fri, 30 Sep 2022 05:23:26 +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 4MdzCd5wPkz3wl7
	for ; Fri, 30 Sep 2022 05:23:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664515404; bh=3pFJ6LrWaTw7fjioFySoMKRWI3D7+aZILtu/01QDqMc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tu+Y70gzqhrChWGXIoNyMYbghVxOi383rwX34mrVNIjVf8ucfgOOra6o8b8Bl5NAOXGk4zrTlqRKcWV62aI7F1ma6jKh2myI9IUDSzZOJU3HZHvdn5sPc5Yvw1te4FUaP/Ba9r+T2U1bcslFtnObEa0/WdxvbJk4s1HM5UjHnpvCWmDfYDmdnVrY9djqRrIg/mQLa8DMcEeSMcDLRaFkw1HLy9gO32I2C3nApcT6W9IS9S3YK2huEU0rvAl0+2grJOZDfr4a18T9fSXcsM1p7NvUQYQ6jzvNwzC8FdHOep78qGJBtPoNGD/LL90aYZItur7f0P2am9N44dfO/w3rrQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664515404; bh=hajLbrtYGDoWkfQtV3+0qhYySygH8yEyPr4ILacNUbG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oTfe4b2uo/Lch8E7EoRdgILYCsPL/xv5SsFwPwFDpKw3PrC734pe33R/dDf8iqNAmVrAyo/sQwarCyU07Db3ufctSoMIs6MCLGYCdm3jNBu8nFa6Ad+kXkd6hV6iC0q4GOsLIqoSDoTJzerhVKmf4nAx1hRVR4PqSL/phVOjFDk9J72Xd7dXcMz3Z8MQEXO0+8UfUDHBX3lRaKzPFq1locsYO9cdkuzw5xAebi9mhWVS1l4d0Bui/hpAMgCwBYwcASA425P0fd8bvilgP886nzR8YVITyikJV6/Ao6Im+8JjuVCc3B65uVAOIzDmItDW+goP6uCZVv56ta3PW7QLOQ==
X-YMail-OSG: bQVoYZYVM1mrdQkcBR30ulg1GQwT25Hy_k1gpUMS1IcByYl55xW1e9iU.gsQAZe
 Gzy912vzdsKA47MAW5_np3CWj5AscHaUnc0HmUV0mTUVOKJ2TOVPDzdVnd5hlaQd4l8QNaE7YaWM
 H.whrjy2csg.G9Gs5d9gQkaQ5oE9nUdOu8vP9WdqmfvwWFIpI4YpwD7dyy9qutAjQ4.t9N6qS.oE
 5SZ7OW.5xgmeV5KEP4oTfyIuKtZKea9rfTUmTKXzxFxDK4Ar03wIoR9LrADazD7y51ZSw0oOrh18
 kJVedXroOVHRIw0x27H_Zhb1tAckvOCSUdEb.K0qFgthXHUX8JeY3kHAe6XhJ09JgGZoVtJsJj64
 9eY4G3Izv1mT3Ai4wFeHLAFSNDstYPTPTeJbzO7N4p0ZF.Q8m7_6GzpPECBetT9qbFI6v4Pd9fxw
 Yh95XoXYZE18jNG1HbA8dSzR1_fKhT..7B9y.PiP32dTu1nVukuyp_wn7xx.MqVGI42m7OHNkRIk
 rTvpweMHs.vlE4BS7VqTIs70_yLW_rZHY7j7tbIbBJ4mv9gB57gtAF6a_MUOoVYvm79rLRNIA06O
 d3HU_XdIBZsIoOUgEI8KFDCdRgcOxVk4CyKYp._at9DCpbDjKwK0tSH3_MRA_xOwsPiodrAU1ooX
 bHW..S6exP96zaSNlvo596jWxRQh878fCrejSUZhJHNLKG93GHvJ_j1MOmFJ3clD8pEvcfQxQe77
 E3jGmcjYbdvy4lzaNOcqHcXBt6zavxTykiufAyhqJBVGNhO_MFQCUO1jlAEtKPdmcdrAIcMtNlvV
 l4_k.xIV_ng1EeIjKcBvwWAJ_YyANddpm91EAsLIGbmTDLVZOe1NDfmJcqt3DVRxBscD9gbsyXfY
 ycgir6M.H9AOfrX4zefTqkOnh4qjFyI7N_fCFnV5aPAGg4Drh.9R.jLqzNmutvlgYlU.7YG00SwY
 glOwhVpiHrDlZyzDfz1oUmCriLZSE1KSuvYXOr.SrQQXUCo0I6nMfgGVoXOQh3QqBZvKTtdF244d
 k.4iODNs3QvHHoq1HsOayRyEiJ6GxXfxiNhNANL4ZwdtIrHNOzi9rqFJDfL5.QJVubQryJNGPmBA
 dV3CPCqSV8XJSf7Carfs5hALBQV7MLMoS8pYHUXNdmgNwXIOf79WcHChbR7.4JQrF5IBD6.MSJZj
 5dCw0X6JC4UliJ_1PK4q1733ViYbgPGcbWXhBZpg1p4afX97IIhjV0A5kBSucvNJFzXliAjT7Ma3
 scbjbQHPh6QJ7IAkNikqyqseq3197V3CkqvxAsgiPWLc6z4NZLPKchqSN61.ZF2F5etmSdR.JWwa
 C.5GXJCt7xOEZRLWVb.EuFMhMnpqGFwS6QwuJaBoikhr.VAujECIAui.GdRXJ9fIgsQ0d4tEWfPG
 C9dX_qJ8D.zzeL0OKYwYkA9B6.NmKWZFDSKdCXFnB7hZZsvSJt6_M.5DEcXoB8XoRaUmi320Kird
 BxmQuMv0t3d82SBgCI1xlUUkiYZ9H.099i2YXtP92GsiSPbPZrp_NeMi7exQv3YyISk5d8_DF97.
 mpApPUphoD7zwkfvVnqk1_4MQMIZQI9gnzwo_ry.F6184vCX1cDVrb_RipV6hGiOtLKI.KkJWRQh
 F._oCPxb9UUQixt8AHPFeN21vwZtZW6.6myk973x_zvGren6iivFaveQnjmJ0s_kREd5Y.Xujtc_
 lazAMMk6GbxvstBib9er6rfxIRFwCXBP1DfLOhLpe4CA94pR5MisLDkI080o6IgVyIJZ6AIYKx4u
 uq2JDADMvQAqspm1O4YpyuGfyBvm2o4sYwVmDI8RcqvdcOj5jSG6QumDKuTSZlH_ukIAdkdieHTh
 Xu0FUkDH95e6Ywm4XqWtmsHkGAPxVVZ3dXnAkzVinU3g9E1NitDFIRRBTiy_2Hensb6Q2pDdRBjT
 7LIhDjCpuJlIoRYkwKqws9KlJsXdkgKYE37z6opx_6hT.s6QhkmvhlTCss.mINQ1hTpcB7EdamkZ
 s0JUcTsdW0hfcijsA8i0DWTqyOddEzy9QjquVrQd9hx5AQNKRpHnKJg3zHVUsNhdnRxpl6hSNqTa
 pmMv2iYAZUKj6mHdJRojHU6f_bcJMbAqNQOrasBPvbBS2DvfBPnEXmysnJWXWfH3OAnU0rXlcPUV
 wtj0fy4Wq9BA_rSUwpit5QEBuH7nGswsu3.sqEEi5888A11VSy280iZoxxX9UwTONG6rAJC8EC0F
 L5ve4wTLwV2xjWCAlhnTzkDDSqy.OuyAq9spkGVZGJ4havzGm5Ia99NtjMfFzSqdBKHm1RYlwK75
 2
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 05:23:24 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-5vhqb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3fd5b292d3d95c7721c2f21b153a6935;
          Fri, 30 Sep 2022 05:23: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Thu, 29 Sep 2022 22:23:20 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <894FEFBF-12BA-49CD-BE87-662CD110C03F@yahoo.com>
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MdzCd5wPkz3wl7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tu+Y70gz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-29, at 00:18, Mark Millard  wrote:

> On 2022-Sep-28, at 23:59, Mark Millard  wrote:
>=20
>> On 2022-Sep-28, at 22:41, bob prohaska  wrote:
>>=20
>>> I've put the full output from a failed (no storage
>>> device found) attempt at
>>> http://www.zefox.net/~fbsd/rpi3/u-boot/u-boot-debug-log
>>>=20
>>> The obvious error message is:
>>> Cannot enable port 1 after 5 retries, disabling port.
>>> Nothing about device 152d.
>>=20
>> The RPi3B has 5 USB ports for devices, one being internal
>> that is tied to the EtherNet port if I remember correctly.
>> It also has a root hub,6 six overall.
>>=20
>> Your failure log is about failing to get the root
>> hub working --which in turn blocks all the other
>> ports form being accessible.
>>=20
>>> Tomorrow I'll try to capture a complete log of a=20
>>> successful boot for comparison. The boot success
>>> rate is so far is 7 in 9 or 10, depending on how
>>> one counts.=20
>>=20
>> I'd also recommend recording a bunch of failures
>> and seeing what wort of variety exists in the
>> details of them.
>>=20
>> FYI: My log shows a Root Hub Port 1 status
>> sequence: 511, 511, 503. Yours: 311, 311,
>> (5 times:) 301. So it looks like what the
>> status encoding is and what the implications
>> are.
>=20
> Accidental send. Continuing. . .
>=20
> The output uses %x (so: hexadecimal). For reference:
>=20
> ./include/usb_defs.h:#define USB_PORT_STAT_CONNECTION    0x0001
> ./include/usb_defs.h:#define USB_PORT_STAT_ENABLE        0x0002
> ./include/usb_defs.h:#define USB_PORT_STAT_SUSPEND       0x0004
> ./include/usb_defs.h:#define USB_PORT_STAT_OVERCURRENT   0x0008
> ./include/usb_defs.h:#define USB_PORT_STAT_RESET         0x0010
> ./include/usb_defs.h:#define USB_PORT_STAT_POWER         0x0100
> ./include/usb_defs.h:#define USB_PORT_STAT_LOW_SPEED     0x0200
> ./include/usb_defs.h:#define USB_PORT_STAT_HIGH_SPEED    0x0400 /* =
support for EHCI */
> ./include/usb_defs.h:#define USB_PORT_STAT_SUPER_SPEED   0x0600 /* =
faking support to XHCI */
> ./include/usb_defs.h:#define USB_PORT_STAT_SPEED_MASK   \
> ./include/usb_defs.h:   (USB_PORT_STAT_LOW_SPEED | =
USB_PORT_STAT_HIGH_SPEED)
> ./include/usb_defs.h:#define USB_SS_PORT_STAT_MASK              =
(USB_PORT_STAT_CONNECTION | \
> ./include/usb_defs.h:                                    =
USB_PORT_STAT_ENABLE | \
> ./include/usb_defs.h:                                    =
USB_PORT_STAT_OVERCURRENT | \
> ./include/usb_defs.h:                                    =
USB_PORT_STAT_RESET)
> ./include/usb_defs.h:#define USB_PORT_STAT_C_CONNECTION  0x0001
> ./include/usb_defs.h:#define USB_PORT_STAT_C_ENABLE      0x0002
> ./include/usb_defs.h:#define USB_PORT_STAT_C_SUSPEND     0x0004
> ./include/usb_defs.h:#define USB_PORT_STAT_C_OVERCURRENT 0x0008
> ./include/usb_defs.h:#define USB_PORT_STAT_C_RESET       0x0010
>=20
> Note: USB_PORT_STAT_C_* is for port status change information.
>=20
> 0x311 and 0x301 indicate USB_PORT_STAT_LOW_SPEED instead of
> USB_PORT_STAT_HIGH_SPEED. They also indicate lack of
> USB_PORT_STAT_ENABLE.


As for what happens just before each of the 4 log
file's "0 Storage Device(s) found", all the
examples are the same. For:

Manufacturer=20
Product      U-Boot Root Hub
SerialNumber=20
bind node usb1@1

it ends up with the portstatus sequence of values:

311, 311, (5 times, 4 from retries:) 301

instead of what it gets when it later gets "1
Storage Device(s) found":

511, 511, 503

So no other port or device is found when it ends
up with "0 Storage Device(s) found".

311:	 USB_PORT_STAT_LOW_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_RESET
	|USB_PORT_STAT_CONNECTION

301:	 USB_PORT_STAT_LOW_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_CONNECTION

511:	 USB_PORT_STAT_HIGH_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_RESET
	|USB_PORT_STAT_CONNECTION

503:	 USB_PORT_STAT_HIGH_SPEED
	|USB_PORT_STAT_POWER
	|USB_PORT_STAT_ENABLE
	|USB_PORT_STAT_CONNECTION

I've no clue what makes the distinction happen
on/for "U-Boot Root Hub". Nor does it looks
likely that I'd figure such out.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 16:40:10 2022
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 4MfGDb0lGxz4TyQl
	for ; Fri, 30 Sep 2022 16:40:15 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d])
	(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 4MfGDZ2d5vz3s5C
	for ; Fri, 30 Sep 2022 16:40:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52d.google.com with SMTP id m3so6683046eda.12
        for ; Fri, 30 Sep 2022 09:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=6pk9oDiUviyNMzIduK9ylM5i7Cf3LjfzMdDJ3ssSm1E=;
        b=fnQLnmonYecWGTnqIl+SVWAq76wLOxe/D0c5ODb+fcEnN9rcCUiN++sJ+We+UFfLrO
         yFS50/9CSWcTn/BAAqB4un6Xup+yEVWN8cnIT3KtPNeMs3ceeiWZRAwl1HnL3S769Btt
         4zcZGTH49It9JO0OJM9/VIrX7nDij+V8rZ6x71MnXEiPL5/3VLIU1IBG7EE4YpudkqkO
         RH+9qmVPlqlwZJa7aMIRLs4Pt5GF3fR/vfrTDU65irXPMVrFKJsym4zZL7VtHal1UHu2
         XMKWr+idt7QOgVMWoxbN5rbhkX7C6ZpShlg2d7kn31z8eIghIhqsByzPkKAGxboNw4Dx
         MFQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=6pk9oDiUviyNMzIduK9ylM5i7Cf3LjfzMdDJ3ssSm1E=;
        b=wcwxnYnZ1Y/rfxUX6qBrPYSifE3VpFzdX4G/67FJ0oSEXsPVCNCWkPz6c+ij83ZSwe
         uw7z6xJNOTGcPBpvNgFmDZVIiYvLuxbQuzysc3o9hlExn5lMOg8/ODfLr5MHUzIy0bHs
         ltsPrOS2xAng53O3gY71hJ12+PpQxZ+jKcuE6CNVgrLzJa1/fpW5n11C3CMEphQUg+Rs
         x5mJO45VEm3Z8ImDRJOpETc6FwGvbwueVkJeTIMAK9zRisbH/x6UxqZK9z7WLjT0RLpi
         uAPyWaBR6oDSG0pUOtNkZWsr69w0YwOo1m9McmSlYaTz/gX0xOWOLdKQNtdbhmBvnh6p
         SoNA==
X-Gm-Message-State: ACrzQf2gVWjvfrJKsfhnvB2n4dFxzA4pAdecXfL+k+n9DRjNLHoguqWf
	dcv9iz0YSHKJVgZIfR770Y/8jZfI4VQKZA==
X-Google-Smtp-Source: AMsMyM4eVA8v7f+sVHGqA6Cx5uFadmflAwbidBAjekJdvROKRkDtm0UUZmYY8RzZkh07zLS4hRqoxw==
X-Received: by 2002:a05:6402:f1d:b0:458:8f4b:778e with SMTP id i29-20020a0564020f1d00b004588f4b778emr2054612eda.323.1664556013028;
        Fri, 30 Sep 2022 09:40:13 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id j14-20020aa7ca4e000000b0045723aa48ccsm1921338edt.93.2022.09.30.09.40.11
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 09:40:12 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 18:40:10 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
In-Reply-To: <20220930002742.GA81169@www.zefox.net>
Message-Id: <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGDZ2d5vz3s5C
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=fnQLnmon;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org,selasky.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 30.09.2022 um 02:27 schrieb bob prohaska :
> =E2=80=A6=E2=80=A6
> .
> I just captured an example now. Because of the file=E2=80=99s
> size it's at=20
> http://nemesis.zefox.com/~fbsd/=20
> in a file named=20
=E2=80=A6=E2=80=A6..

O.K., you now have extended logs..fine...
comparing success/fail we see:

-fail---
port 1 returns 0
pgood_delay=3D2000ms
devnum=3D1 poweron: query_delay=3D2000 connect_timeout=3D3000
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
Port 1 Status 311 Change 1
devnum=3D1 port=3D1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 311, change 1, 1.5 Mb/s
...
STAT_C_CONNECTION =3D 0 STAT_CONNECTION =3D 1  USB_PORT_STAT_ENABLE 0
Cannot enable port 1 after 5 retries, disabling port.
Maybe the USB cable is bad?
cannot reset port 1!?

-success----
port 1 returns 0
pgood_delay=3D2000ms
devnum=3D1 poweron: query_delay=3D2000 connect_timeout=3D3000
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
Port 1 Status 511 Change 1
devnum=3D1 port=3D1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
portstatus 511, change 1, 480 Mb/s
--

So we now know that when it fails, the issue consists of an underpowered =
port1 of the USB-Hub
( what doesn't necessarily mean that the hub itself is the root cause)

We see the values of query_delay / connect_timeout / pgood_delay=20
and some informative (device specific)problem descriptions ( as =
comments)
in the file :=20
common/usb_hub.c
...many possibilities to manipulate delays / max retries / force resets =
or whatever, even the log message: "Maybe the USB cable is bad?" is =
interesting ;-)...

I would consider to "force" the King of USB to read this file contents =
(usb_hub.c + usb.c):
So consequently I quietly step out of the discussion again=20
and put HPS to CC :-) lol

Regards

Klaus













From nobody Fri Sep 30 16:53:03 2022
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 4MfGWR755fz4V0JV
	for ; Fri, 30 Sep 2022 16:53:07 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4MfGWQ6b4cz3tk0
	for ; Fri, 30 Sep 2022 16:53:06 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62e.google.com with SMTP id rk17so10259727ejb.1
        for ; Fri, 30 Sep 2022 09:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=a2aQRvGTsNe34T/vIgXY1t7V40NWKX1WW9eh1A7qE8A=;
        b=TYFSdK1UanVKacIDJBW2rDRrFD44CwiZK3psJC59LFrOzsixlYYL9lB9zLi3N/G1jX
         yfEDVnFIr2Jh9IPyaQhAvHB3A1yxcPIb8QyOt5b94zNjceX6/9lyF619+oOYNLpQh+vf
         zKhYFcR/duXaic5K7cz1pyiL/MdKOcTzIHT6TYa2aT0Z9eoi3VW4I7uc6LzkRsdlzMBE
         LTnW9OuGD83wSg9FcANVbICbIGUERRj1lX69yb7v1r8We0SpJND5H4YeDoKHwoR+hKGi
         CUqI69VSaHYLNduilN8Zr9K9jwGU15vbxIta8MNpTd8tDySBF4bv4MpZdj1wwSqK3MuK
         k/TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=a2aQRvGTsNe34T/vIgXY1t7V40NWKX1WW9eh1A7qE8A=;
        b=hwM/R9nkq/C5Eg01KkjcwqAuUpddLEuHsDh2QjuY0KCrhVO+1o61vwa3o8mC2IILOl
         LWEMRHI5PXTBG22ErfRZSk523XVp3aob4zx9s0SCOLiFVC1QD8IqXQEHJZwjU059LxQP
         uvN9LVgIS/JbSjqtvx7STfDveA0wZJdyQILatHMDbXwHEnj1R2b+wwDnh+u/5W628dbh
         WKSMJUUYfczS7OltnrSlc48nHefRIcHOFYbj8pG9ZfhurYOQzCJm/qWZtyzUTyQUu5F+
         xmpWD9F+ud5ilPdVLSCA6zC8A0LUqHYcUz12tJQavRNm4fNbFGso0wA/7NonuGoqmfuT
         Fuww==
X-Gm-Message-State: ACrzQf2qeK3MG+HFX9GMAVI0LGK8RtIQpT/4o+qKY/d+eaix3VSKI+hN
	D5X2jxbF9ddKfSJyZm1iUUQ=
X-Google-Smtp-Source: AMsMyM5Q4141ps1FzpmwfdlbuNXnyz5RNFqb0fJgP9k2whLemDxuc7WeQBLfHGHTCpCCx2Or/cmo5g==
X-Received: by 2002:a17:906:99c1:b0:6fe:b01d:134 with SMTP id s1-20020a17090699c100b006feb01d0134mr6964405ejn.598.1664556785683;
        Fri, 30 Sep 2022 09:53:05 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id n2-20020a509342000000b0043df042bfc6sm2010483eda.47.2022.09.30.09.53.04
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 09:53:05 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 18:53:03 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
In-Reply-To: <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
Message-Id: <45CD14FA-A03E-45D4-A71D-A9E8E4FFEB24@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGWQ6b4cz3tk0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=TYFSdK1U;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org,selasky.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 18:40 schrieb Klaus K=C3=BCchemann =
:
>=20
> =E2=80=A6
>=20

well, since you seem to always get a successful drive detection by =
manually reset USB on the u-boot prompt:

A crude, dirty idea in pseudo-code which would never been accepted as a =
valid patch , lol :-). :

if ( connectionSpeed=3D=3D1,5MB) {
usb_hub_port_reset();
}
=E2=80=A6 or manipulating the delays=E2=80=A6.

Regards=20

Klaus


From nobody Fri Sep 30 16:58:18 2022
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 4MfGdd3TnFz4V16P
	for ; Fri, 30 Sep 2022 16:58:29 +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 4MfGdc0l24z3wHm
	for ; Fri, 30 Sep 2022 16:58:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557106; bh=jBAOWT7C0kK+XyOnenVJBFdDq0I0WYlpgaWvFJrcoPc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BFLD5C+4I56pVhLC03BQwoUQ9klzX3ijAmD09xkOQKd5UgF4rfs7uAFUPqp84ulcdIFWNztouJxxSGSw0cRq7qAlVpU6dKzjyeoM3dgI686OMd78NfUobXKaww22ZFLPem3M6pww/l7uoTTB9SsrYIpFBQGHRuxhfmXCBptXk9YngaBZmd3YWYx3gMBjBAD5Nn5dCzKolAV1gzwltG9oAQhBkQfWemxEo3nefVANG+ihLocNYVFMcgmZ0QMmtObXKZf9cGNkkfwUGoAfGyf2DsOtUMaGrCIuEtXOnMjX6D+viWcSk09MsYWjhpL98ykPdSo7iaECNwX/YMcbkcKm4Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557106; bh=d4d4X+5VZ22ccWEZMkhUpL7RKQzrlWgw7z6j1hByD7f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SnbbIRgbPztWcb6JWnq6gahvRVJyzwpvQsRUkVMinLX1k0wZJqj17rwKLBKfn5pkAHM5SfzwWo81pHLGMwQeRLhKYhWI998i4w2iVW4Bgv3m1l4SS7XMx7iVyY0Q1odjoWFdVx2RU6olOXezi4oMqELpw3lzcl+Woo2MdPF6wOaughOziAjwwGoviM8yfGFNfZnyjaaDw37BUn5HLa1gafDpau8cxuuD9tEISV3+FBSWRF5WaE1uApJs4sRHbGCgYoaLm45LrAMsUkdGxqY9rko9+kNtxF2e8h57/WkvjrMkkO+5dC44gNizgpF6Ka68KXMFDTEEybosJ+quB51W5A==
X-YMail-OSG: 74xZSxEVM1mvpKe8A8J8uRS7xJaywoLiunQnDedmZ3FHvzYB8cxJn50HPtfXLjm
 EEqzGLhNyd6riwTe7R1LrtfKY1nIKf28ujd897pzwpMOjf7f.8r2h0x8u9u58aUe4mBpeJw3pql7
 P1jBqX0kFfAnkY2OTCiS_R3X746PconMHwp9ZJLSmSoLoKwp7iv_zUlirf5EUVz5zYbuzelyABAk
 gjw1mjk5JNS63SfiV2hulgX8DR8B3QrP.5LHhwarh5htCaCXr0GEkGeVI5Ki9BFaptc_NQ0w0Fnd
 3jcFEd8vp0k4zmJ3CzGgXBWvGm02uELE0v63zyECxR0N7g9RXwXi8tDI9KUTEwtkgWkLu4o1Ceck
 3tiqJidR5H04vKsMWATD2Da.AU86uB26B_18fvw8T5LkxkU38Ajx1GCCNM__dNRPZR7_Qop8Zvax
 MH.1AZkEKR7edgMOW1uwSwngQw2oymAzEYsVJtVRUIvd8y71s2BE3oR8jPriHk0bBM2ERPUig4wF
 _ZJ583czEov03.Y6cG9ximpedH5aJVgruFGisTPrtM2CgYqGoqNZXzI9qjc0ocfJk_iv6j88ThRu
 NYymSE.lTQL9IkiaaXgm5DjAKhFL7GWJCODnEltu7ww1w1lBXc5UAz3mSmQE7ks21N.dFuIIDzuL
 1dgTmOEi388zpkLJefuRCDPiYl52sKGy0a8Zoc0fdSATwypKESMu7WmHabGjy3WMHtHN3o5llBy.
 ZFmKYT7HCAroZcmjLOqpN64SKVAbfh2.1L8E502cifk2Gte88rtFglCEyaPAHB7Cn.zK6sTLo1eC
 .uDqIBsGYjff9TGYtzZ.NKu0digOv7bk42tNihJN3ZOxu3Spj_yrYRa2cj5o0j91e8iPVwJvmDNg
 JvISryp8pnBkTjGf8iyqgndG6cu_fzjz43_2y0wfzBvFZOwHzDOsFubZNEoYYiPZVEc284XoJGvU
 QZzg2vXBggK79khIpD8q6MM7f4tm.0bsqIpHTPuC5VN.WlY4.bOj4CQ6sf6mpRepdmiqve9SCzt_
 .FaKv2tIdezk32JjCfQOcSkPKQeW4iCx5rMI9Nker43BRU3PLu0TApyGvahx.q891iRRLtxRHiyh
 R0uWZ.Vn.xDGhmhKNu2rVk.XGAW5KB97Zgjq_cJ.w6G4Bj4FdKmXKBCHEFU2H0RJJnE0YdTKzD2t
 V_vjCA.YnvCtIN9Jk1u0_uETLFBxdd2dwaZ0bzlaUev9XSbcrvU6.I19.EteyAp_8d20t5MUcOhY
 gEW5o2IYGuJtTflDvzPtaKlKNbuBKmotX0LBoOuwWSc7ZxNqpQpSQQSvTjLx4lXseUysT5w1TRaU
 l4Egi9uJOemsBWaxMkArBeDen9i4yxZeqYh_Z7p36xIGxFk0aaPmq0RJha.wsPG4BpA2YW.1fD8d
 K1p_OptKSLMsfg92mLvQOLHJmg_vFbwqNQzSo_P1zmvcCztNbrKkcVwXUKccRxYN7RM8ktVkTgQv
 spPm7x4Vi0AMdLTozWJJHZvecUkKoEjWIOUiRqfQ.8mJeU9zuHnxsnsx_XtwvGoqCl.qmMd4gAtq
 WQOaJM5ibEsWkBZaf68.8ixsg5npzDmN1tDhmJCKrSW55In4VNsqIWHxAZa3z8q.KD3P.GJmu6aA
 Voizs88fkDzW7Nwx4VlIEqCtGjf98U_tRQkh_11jUKB7c3yKfUaqWjZv3o.t97cWGbwuNjJhTiRI
 lyBadHRykKUujalByN_t.COjNj3GcskX6hYqmwU8lR.LpxK16gX_e21jQ5xzsHtkpH81Bg4d17tG
 qyDAAfIHQwksuvH1sBi5KGYYf_u5.75mJ36DOZKep6YuZaQXo6_SVbInRbxFAHHkdBDxsF7_vgH4
 znRn3QOmnImDSjx0msRsqBuLgQ_jde2jkZksW3R2vCxapVI2A2yrBd726bXzTx6bDW_yLyP1FU7R
 fI4qmpnyVXBE6JVta7xC.9ZYxIY_YA_0vaGSJhL7vA4KKqEsidNjN5LjAeZcGw00qp.s_N8s_nkA
 vRPMrxpdzFzhA9qEpNu4gk3wKHeSu_56r4JoIz63mi95AOKHemTsh2eDJln45lfrcl2h9Mmwk2gw
 vFoYgtn3isCbGV.RcYJcOPI4u.QiCPmOSlqr6DsTZSVVWa5vLGCTvyeuXR_FryV5MGovijDW8MTa
 LsDxEJr44B..nB5p50kTmpv97GEtPJt7wKN_CSApJ5wHwBpON3upgwk6.1mR5XA0gT2ZGXGhBdzX
 Jh8j6uwhUOlFspdDJzdEhO1KVnZSyMKhKVaBw128okNhfHGjIsgtQoDnru8QCUlYT3q8.gYGPmr3
 UA0Zl_Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 16:58:26 +0000
Received: by hermes--production-ne1-6944b4579f-p7xcb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c532b724a534ea1db6a017739b8c02cf;
          Fri, 30 Sep 2022 16:58:21 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
Date: Fri, 30 Sep 2022 09:58:18 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
Content-Transfer-Encoding: quoted-printable
Message-Id: <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGdc0l24z3wHm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=BFLD5C+4;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 09:40, Klaus K=C3=BCchemann =
 wrote:


>> Am 30.09.2022 um 02:27 schrieb bob prohaska :
>> =E2=80=A6=E2=80=A6
>> .
>> I just captured an example now. Because of the file=E2=80=99s
>> size it's at=20
>> http://nemesis.zefox.com/~fbsd/=20
>> in a file named=20
> =E2=80=A6=E2=80=A6..
>=20
> O.K., you now have extended logs..fine...
> comparing success/fail we see:
>=20
> -fail---

This is for:

Manufacturer=20
Product      U-Boot Root Hub
SerialNumber=20
bind node usb1@1

> port 1 returns 0
> pgood_delay=3D2000ms

The 2000ms is from the U-Boot build setting usb_pgood_delay
explicitly: Bob is using the part of the patch that I use to
get my every different devices to boot.

> devnum=3D1 poweron: query_delay=3D2000 connect_timeout=3D3000
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
> Port 1 Status 311 Change 1
> devnum=3D1 port=3D1: USB dev found
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
> portstatus 311, change 1, 1.5 Mb/s
> ...
> STAT_C_CONNECTION =3D 0 STAT_CONNECTION =3D 1  USB_PORT_STAT_ENABLE 0
> Cannot enable port 1 after 5 retries, disabling port.
> Maybe the USB cable is bad?
> cannot reset port 1!?
>=20
> -success----
> port 1 returns 0
> pgood_delay=3D2000ms

Same point again.

> devnum=3D1 poweron: query_delay=3D2000 connect_timeout=3D3000
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
> Port 1 Status 511 Change 1
> devnum=3D1 port=3D1: USB dev found
> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 =
length 0x4
> portstatus 511, change 1, 480 Mb/s
> --
>=20
> So we now know that when it fails, the issue consists of an =
underpowered port1 of the USB-Hub
> ( what doesn't necessarily mean that the hub itself is the root cause)
>=20
> We see the values of query_delay / connect_timeout / pgood_delay=20
> and some informative (device specific)problem descriptions ( as =
comments)
> in the file :=20
> common/usb_hub.c
> ...many possibilities to manipulate delays / max retries / force =
resets or whatever, even the log message: "Maybe the USB cable is bad?" =
is interesting ;-)...
>=20
> I would consider to "force" the King of USB to read this file contents =
(usb_hub.c + usb.c):
> So consequently I quietly step out of the discussion again=20
> and put HPS to CC :-) lol
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 17:07:08 2022
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 4MfGqh5VkTz4V1jF
	for ; Fri, 30 Sep 2022 17:07:12 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4MfGqg5qkPz3wsy
	for ; Fri, 30 Sep 2022 17:07:11 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62e.google.com with SMTP id sb3so10289813ejb.9
        for ; Fri, 30 Sep 2022 10:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=suRJwnTMN7QKxMLlzsCpO2uVEGDY/yDE4fMjObFZceE=;
        b=dd73/IaGSLeIvos0QX3qLcZ+txDKOrz6nH7mnMiMOO+RVST2uQG6SxKeHUo+DXF08x
         d8iPFhsOyHKTHZ20baneOiYSqqmqJBHQucxOD13ILf/i69hSuWuS8aAP4JFMT8u1jx1t
         9l/AOLOrcjZd4h+lXBvCRzJQ4+whUIq4toaKOP3kFC4fdAWv43+w4n/iwFW0vX8qSN+J
         wX0Y7ooXao/10kxkzSe3DmmgzYaYV4C6UcoHnWasfbNf/ZuPyZjn6wBbKqAx7n8aWPSC
         WwtiPGlMd6hWDRJvtbqY8OaknJhDQWsQQDNkQYBjtnZogdh8VqTzQTNBRokROVwUmmal
         QwxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=suRJwnTMN7QKxMLlzsCpO2uVEGDY/yDE4fMjObFZceE=;
        b=qzGw7/naB96uLW3PpskXnz/37TfNfCnxAqc7+CLtKiaWcF2djSP7H2voE0Py5EWJgp
         IRURbpz/nRMW2SJE8RdSeXNrjF8x/WS1Cl5zZMJlhrvGtpPJbqA/nc9N9hrrFotk1pnk
         CeP4U1yh4hITo0JQdofiICOXlUucGj2EFwjpmu38w9cSksFRtXPYl9ImpAVGJw90ZoJF
         pEQU2XoLeZQI9yUnqeqX8cb3p4JWVz77N5vSUdKoStIXc6Ro+buptKs9oZz378DJKuQg
         sTzuFjoIUu4sbxFfyR+/eCL2cRdtptF64qlfCPzDyJ1Ioq+4c6WzTG1f0Qzhm01u+wYN
         JiTA==
X-Gm-Message-State: ACrzQf228j8nSYPUzzx5hcksVljgdO5RbjWFFcMGRe9OHoAvBpwpPPok
	YDbagyzRAT+pobd00Q9iQ4o=
X-Google-Smtp-Source: AMsMyM7ivDkr51F5CeIDrhsz7iXrACrDXb5mqwfGwEKh5RRdfeUWAQXQWxPbTN0Y+52pkTm+bVDDdg==
X-Received: by 2002:a17:907:2c41:b0:787:6d66:b593 with SMTP id hf1-20020a1709072c4100b007876d66b593mr7267386ejc.401.1664557630672;
        Fri, 30 Sep 2022 10:07:10 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id wi16-20020a170906fd5000b0072b3406e9c2sm1452318ejb.95.2022.09.30.10.07.09
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 10:07:10 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 19:07:08 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
In-Reply-To: <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
Message-Id: <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGqg5qkPz3wsy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="dd73/IaG";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org,selasky.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 30.09.2022 um 18:58 schrieb Mark Millard :
> =E2=80=A6
> .
> The 2000ms is from the U-Boot build setting usb_pgood_delay
> explicitly: Bob is using the part of the patch that I use to
> get my every different devices to boot.
>=20
>> =E2=80=A6
Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will help,
But if Bob got improvements by setting your values ,=20
I would consider continuing to manipulate that values.

Regards=20

Klaus


From nobody Fri Sep 30 17:07:12 2022
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 4MfGqr3nvyz4V1tZ
	for ; Fri, 30 Sep 2022 17:07:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4MfGqq2D4zz3xBF
	for ; Fri, 30 Sep 2022 17:07:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557637; bh=GScj+NkP6KL7I5E0fkPaFKRChHT5QFczRD3AxBkgkQ4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NURJE8YbdjC0z0CngG/x61REz33M9qwJEU+HqjIijHHmCCjawljOxaFsxg4n5aa0uEo0NHbknUqQpEJxL/TSHawdgj1ywAz0vvM1e43KsoVAI3QlRCh3eXSs68qHPz9mA14fv+Bl0+e6ANkV+rUl7IzKRBjjcqJKcOdEVBesduXUmPhfXWkqCt2BjYOICqG1fwnZnt1tvxaIbwUS+QVj+vV7El+A8xpEf+6bSDX5HOExzrBCfAhhxnMr1OKP+lefNYUkHmogVZyQiFp1R9K1IN6idat/gNMfIZxDZZ3jkuMODkpST7dx8+rMDAECvUzHc1C5+R/vG3YNpCIJpsqP6A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557637; bh=E4ptXos98dCoTg3pXUlvE1GAj6uFCVGrYyKtjIIebfj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MdCFXH6Byzp8XbgAqpLp25q9kNajNciBx06DtDDlveVQqkhOo/NqSa05Lp+jTFqd2k8r0FYW9G8gPBtt+cuXHMkj1jtGpjMuCpEqFCY+qmugZ98OWiy4wT6SejOGCPEl9mzXW3cLdxPwF3i1W2P1IebxM/CIDpFCyi5WuCYMQ82f/2cH8n2qW4Rn70hhzEgPyda+GjjZ4eCwhiYqycfhB1r/2cfr83JsFXwQ5PvBRCMZmk4cOVdAqY3EjYqom1wg0z+cdjODOnXLuJ4SskVXs6K+fkl/hyuvkV5YAOjcFwHM6wisvlW9GZGUf753e6M8SiiEjS9Yk0n2R36mTP0lHg==
X-YMail-OSG: vzg2CusVM1mlZYBhSQjpoQ1vcene_HicGD3FRimjAdJqLAgMB3F.kE_QJHDy6LH
 5q4YqLlGMhJHD6l5ZKNUNW5Ac64TtLRzZe7CJBrKPQj.TgsctsLAPkgcdE.MrV_Zl6OvdD.SaZae
 R51VDepQKmM1Yb.bBMwjsMCPVc_O3NlmgvbEXXQiPifOtDGQyDgBx6B5wyfSYbM4CSCdc1HM.L0H
 s4Mq7sB6MVmSXlqhep9IDgdyuft4fSS0D70FN7xoRXKIGTRIn0XwAaxODXNnb6lpTh3iT8bVs.40
 SPDB4.UenAZ1akMbrGqDwWZUshqIpWRB3A0TUtnMi0QWrYIE.O99WwD6V9f.HvJ.amJRd.YYgutf
 r.wv8zdDvE6HojOWmXfkl.JtL91IFq6PVbS1Qgv0_oZ5vEVvtns8yvLF.9CxbwP05XJKRs0GzYa0
 wLMOG4Xi3E9zBSnqfVBsUVfz5vunSp7zcRojUK1Lb9cdGgP2.lDhEapUK1Ie35IVatkbG3ru0epm
 4VbWCyvXBfPuc4c9Y1oGXzLIGQ57HFDpeM_CO_X6J9q2F9oR6b4BFu3Vq_kvMZkqeZ.5KUTbhg4h
 lUB4IeRD4o5.23rn5wgZNks9Sq2zMqum60EmBtwk9eR8rcUw_DYhlaabRM45ZrO0ADSFKaAz9GkN
 ObZexmExPDEppS3fVi2QUPqFrG4ZX5vackbJlpRcHzThNO5hLobjqOXFfMd3jy5ULfH.IFqTPKVJ
 s146sOAo6GLUcdbwrtZDvj5EkRiq9I5XBZfoOBZHpDvmLJRQg1EsJIltE_Tnzn.UBcCNUnPa3ikx
 gcY9Z1foWBRijch3oBdV92y9MnIIvXNGWHh9Uo131H2Y5CaGrrCMdejvMFVbDzImw6ZEH.etp5Wv
 eMhQdV4QGcOoJk9GiOE68ZBXPSR46c09gJf66fX3tomJVNjfW_8m_w_bYOr_yzyMkMiwBwH_fYj0
 Av41L2nMhJ_M8H211osxTdWYMBAXuwxgWoIHMlZcE64M0NvCixUt.kqY9BH3xwVSCNwTsypwUW6I
 nirDdqnnOecixWYktfEsTcpqoC62qWmLjN8T7zzUAVoRxruRfZoVRw.IrpViU2gI2Y9vLj_54xRK
 qahIaETtmgYUn_cwjnEpl2u28oY10Mm3ZmHXPxAsjkvKcn7P5hHJ9W.ZYxtsyutrc5re83o0Hd6F
 Gy8Xy02uTUH4wJxLijv.f68XhibP6xrRURH_vHDP.qp.7YaQVu44oNK6HaJdxDF.V.W4GpJlBlTh
 YypEeO.qsyXZhPf7BoFIbUk9iBQbUtMssU.qEGQvV79_lWFxR8cJrpmaXBPOlrdc6NsOnifd_XIL
 JeZ74QSyrqFsS2JzU1ifSUN18y..F.LwAf3JEZw7rdyMJaMF.pKoow_UwaAUOll4fplY3aB8qbPm
 laUqLDxtntkdqvIRB9h1exW_pzK1mSi.EZ8m7ZCLc75UykO2I1LHGEo1BYkDGklZdhoq5.2A34Hk
 Zzng78SvmCjACTogbUZMN3KwGQy8qXgI2MsGPvaQ2dvUfkMZbzvxmvHybj2RsBTsXTpupcliKh2C
 2tEgoc.54P6La2isjqVHBapKgWhxHBFUs3L3JmLkJVzMLDcXUceu0CwYvod9G2H_WBmcglxaad9y
 Xuo5HkpKVHLb4GlWY8QeQV19mFgCCtD5nGckC_JEWJ0DuVsOa02.ii1dcyIXRMktnzRmlaZEMtX3
 w0TB8Ptfur_.LqwpAc7.KL799g_nhxQpelsK1aEC4.st7ZDVqfB58sgyjhpdfXSkUtmzh6r9O6Iq
 QS0OEjT9T9UzPHluBpVep.ZKHdkIQcPKePvTxrwvtgcW.z6wQD56IUIigd0LsuoR2t0HpOZU92h_
 NdqfEYjnGgQVOIC_bouuY7NHqYMFO0PydvJ3pJpWyMGlXmCpsFQyYDUCJdcP8oc5f6zMEYjJP6vU
 OiGffvxqeYiwOZCcissCBmzEIpZzMY3MzN3PVsy.Koek9apWyj0BdL9zkQPYTbH1LXiuM4vhVYr_
 1zpMbHWgtX_A3ZMPMqUYbCoGbRPd8CoYeVmXnUJHDxEq0KV9BK0A9x.9YCXiGiMVMqPkNDPZnDmy
 tJMZoZyVBNq3lVZoIqj9.r1WHjrfXvnFnN8kpmYYp_w.eAGTCGWNSiBLLIquml8TinULz5VsvHR3
 sviztZMFZEpPg8qcRPM7GLazEQvVz3cOsMSYRLtGzHayDFc2jqdFgpkGeQiomd4YcMKmn8iHaZP6
 A5Dh0CgkPUan7FaBbvkDxNBvk766Kl.ZwYzwsVGOy.wyOxQrt57VWRaCZ.ILvkp4Lkm7WfZT8fnh
 eCCK0Lg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 17:07:17 +0000
Received: by hermes--production-gq1-94b89944-j9vs8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 772825a8e45eae86304e8b85a008b714;
          Fri, 30 Sep 2022 17:07:13 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <45CD14FA-A03E-45D4-A71D-A9E8E4FFEB24@googlemail.com>
Date: Fri, 30 Sep 2022 10:07:12 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
Content-Transfer-Encoding: quoted-printable
Message-Id: <70ABF108-762D-42B5-8233-04C2BC935892@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <45CD14FA-A03E-45D4-A71D-A9E8E4FFEB24@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGqq2D4zz3xBF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=NURJE8Yb;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


On 2022-Sep-30, at 09:53, Klaus K=C3=BCchemann =
 wrote:

> Am 30.09.2022 um 18:40 schrieb Klaus K=C3=BCchemann =
:
>>=20
>> =E2=80=A6
>>=20
>=20
> well, since you seem to always get a successful drive detection by =
manually reset USB on the u-boot prompt:
>=20
> A crude, dirty idea in pseudo-code which would never been accepted as =
a valid patch , lol :-). :
>=20
> if ( connectionSpeed=3D=3D1,5MB) {
> usb_hub_port_reset();
> }
> =E2=80=A6 or manipulating the delays=E2=80=A6.
>=20

But after the manual reset USB there are 3 types of
result of attempting to boot:

A) Boots normally.
B) The RPi3B resets, starting with the RPi* firmware again,
    so the issues might repeat.
C) The RPi3B hangs.

See:

=
https://lists.freebsd.org/archives/freebsd-arm/2022-September/001841.html

So there would end up being more to it before it was
reliable for Bob.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 17:13:00 2022
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 4MfGyX35Vlz4V2CQ
	for ; Fri, 30 Sep 2022 17:13:08 +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 4MfGyW4Cldz3yNH
	for ; Fri, 30 Sep 2022 17:13:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557985; bh=Tofo9wTj67+FZ9V5V1EQ75fxmNMYH1i0uI8n5pLO4S8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pj/YbcHaMAzRP4hBMR86JrHR5rQIQJCSwjMjZqT1LkiHPezIdOgcfdiK8rhwM1hsNTDvyy8F+1RUy3O2DJRBt5O+Srx9Z4AlTi2v8FcTTM07teRdhsUsaILQ7yisqwwy4f6DTAKKXVgCzj3bgqqCbJe4mDd6Jlco0M53+Sqo9GRw4N1Lzwn9DfuszMgRqtC+yv+DWYZA66qZKZGJc7RVf5kTCjSoO1idkkPJO5ziLqKJ6EEjE4iQuZlrRKoXThP1HhVUDqKCmdwkxUDLPB6VD4JtN7IKFrG6wI5xizDSlxHxFeENsUBfWVw261cjTVw7TLEfs9xtDD8g2EhmVxP9ug==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664557985; bh=raIRqlxSAufUa48lnZsVVq9bkmlGZ9kQHo7bd2E1w5s=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Uk6r8QNzIjLXI/xtVaqFwv0PEnsOgFBKPnEXCrWfhcdOlggPL9X5owBZ16LgR2P1crhYA7sfeJ7j6n8a5whRIcDQF7SfIcFDALidwH+ESEkx/SJusU3Oya/Dh9fsSa+xNwZgO7WynXN6ZvT8A1zxtND6eUY4zSxvRiNbkVcHFvzGL4f8c5xKlklnkB+Yf9UuEeAQZMzeyJtaKYRCLuQE+6tS2q8yN05MStzcusJRjHpzw+y3/a0i5ZEXv47Bmtf0YabrJg5sJvS2aQ/x4qbr8gY7qt+lLCQtcMLgqiEHkH8hxLANjK99VfGdCfDTRMLMXwb89vD9rUZqto5s5EtNkA==
X-YMail-OSG: tHoGAmsVM1kWLBMCwkpwZ1uP.1cI8QuFRzN5HZaXL.rD6kaVLQ9g9_G0Xw1sjy1
 Yy0e78bAd8DiYkqVi923e246zUSUf1S1SU.J7RfWTkh0bDsCPSUx3jiUftLqXYiNbdxBMTUFokKY
 klTGHc1OT2KHPXbHybjMtKgmVXkDfJ2J.mCnG27dhAGDYZlHaiSXa87NLLMX1JEKUNQlwrDxyoUz
 dFZlTN.GpusxS1od7kroyjfElRMrVMvWjjDf4j4uNnfdLI2SJeVw0oZ_T7YUskBQRnOT2klULbgd
 HjSmbHFU2lb.whNKzOH1gXApdoMgZhifeTMago02pN9rdNuUznf4P.VXsYCQnW2X65P45l4BBc2b
 69U_PwxE1pPc4Y508ppvhWyh.Lkb.mVRwnyJLQutwCDhEzC7bA2PAnbrEv227NuHCvInlYru.RL7
 pMYNsNeLGV8Jq_GHWytBKfZ2lPUcDXYtzipIt_GiUUni9Vnc8ifjM5LZepw.E_zqPKuKibR7KOuK
 3YKkk3Ywm..KKotYFRKQK5dJXDNgOTv5mNcY4kJ.HWaRahsL9ni3XRlT0toImlYx6tQPCty0zPQX
 R3EKaLSuP_KfpIm5lfSfKoyqi3hRFHf2mLTQ5nIBfgMUoME6Zr3CX3GTFFFXo6.Wxmy0_AgG6fWR
 VHKEKv4KSbTRitPwWKkUmUHGzXh9X4a.w1Hga1ExbNawsbdPSxErSmjOLtWNPYG6VyyYIGpPiJ5K
 VMH6kR3IKsK1ngJae6UPzxxmXWmcNzuZby.IBE0G.WdM5Nv9HJCa7A8wVI9RIhSTXbNrPE3HhOc5
 ypHB3RMYOW7CO5uwr6LY8RzSI23y7vPI55S7jSMyQJFnTvpOKqoeY_erGhyOsQnB6p__0li_p4Q.
 zwBP4a8HYI.z0hBVBS.uT1tcEVRV1DagzBNSaEJmMKWsXqLWEuC92HCZkhHS06TAOhKGT86NNbTB
 41P8vXphx6fdtfqEFChXC_yreOhXqlrkKgJ0LMhGn08rYooqRTz6ruTlb2p20jei8VOk5ar5VooE
 Domz2OsLTdGtnH9RpOIZ8mCDzEMXif.I.q8ZoUE6o4zT08akBlSn4RTCuNOgw.UyAV91yKvj53XT
 1WIIAU6rSEVRpTbUeHzd5i08mRFVqNo5BajpSJKu_S7gaYmZAhF8Eeefab0VsUTxJeGQTkHS5WvO
 4R9fypsJjM0bVOKbOjBJPDGJrKf9napY5cvverOOPaCNgjJ7GhypsFBkS05jTP5QiAkqEFe8s_kv
 3zXabO823pNfaWuw53cRHmRCK0N45Zua66F0L4KXmJglAXNnV0dEL0nvzRM1UMJ.4vVwykX8xqBB
 hrcqbPPBSC0JCBfFKO2gUApKwHa.PSwwDmgKHh_8L4KDfIvEdbcwYarN8jHILuc01p_BUoTHFqNl
 IWwLUMveKkK549UHVYidpgVqUCVGnBpdXBbjRkW8IKOH5aQ9otCteaXug7bnHRN..WEUpboo.ZvD
 mTZhI6UXopNnLAQBY33zR_G2THx.BWcQov1c.j6UseQVYdBhoIM9GKNZ8OVukzfG__XPqpHYof0Y
 HXZ18A8TRm8llUy6Sjr8XD6YtNmshYjzveFh1.hMW8BCoi6UtgEeIXgi6hYFPlobsajulFpLko8.
 NWW5LLRVt7SoXC4OW_pXemzap8NnqAmGN8qAtMb46KIU1pOFuPmFfqsxetyyIgR6Y6SFirMQpURX
 bDqHozNAILUaFzptL6.KGlYp8yMCqHotRHvRThibGIiqEPGpcSDAZbtZkV4Nu0_umzJpCKgKBLKp
 Lj5X.Lw1oR_mHXxWpraA29qYLitgG5TvF9Eaz6IFXtw0MV7D33Fn.a48xsXfPp9xs_aoHjbG3ESc
 FrWvLQLZDQXg6WOjmAhNIlK02GFYBoV77CaPQMj2v3ERWqyOtA8Ng9wy7SGkLtlRGwuFQE6oY6F2
 ePsmhhZgZ2I0KE7NjMD01tcMGFFzSNgW1YCcXbvssKWVha6TZ9F2Gju0GrqraNWVNHtvwKWhpfvv
 Q3YkReDWJLCoIG2cVDruQKBuM9g6SXUFaM4DfVLG5.qY64AwcN5sCtWk39ekEIGdSqoFL7gZEb8c
 mdL3H9FU4uzC.hK0z4Td6l_zwkwmEUX6CHN7_NeY9_YVV9bf3fh9dYDGJ1UzxzjCKpo.fnNCRLyw
 SpljDn0XV8PnjFBxAq0uDvGy0k7.irKNjmAHwOs1.FcmJ5HFDACfqwFSo4rLO2vn7mHkCd_r70GN
 qA9eAGanguV3Zq.6HXNVOVKGCWZr8_i.w1sm.sMi7KPTpxkTSc03QQ3h1iw8icjDPopYDgIDXse4
 n.abwuRiQFg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 17:13:05 +0000
Received: by hermes--production-ne1-6944b4579f-2q8q8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9638b367e20a4103de62b8377fe0bdf8;
          Fri, 30 Sep 2022 17:13:02 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
Date: Fri, 30 Sep 2022 10:13:00 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfGyW4Cldz3yNH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="pj/YbcHa";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 10:07, Klaus K=C3=BCchemann =
 wrote:

>=20
>> Am 30.09.2022 um 18:58 schrieb Mark Millard :
>> =E2=80=A6
>> .
>> The 2000ms is from the U-Boot build setting usb_pgood_delay
>> explicitly: Bob is using the part of the patch that I use to
>> get my every different devices to boot.
>>=20
>>> =E2=80=A6
> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will help,
> But if Bob got improvements by setting your values ,=20
> I would consider continuing to manipulate that values.
>=20

It is more like they made no differences so we have not been
bothering to eliminate them. That way I can build and test
the build in my context, still with a bootable environment
for my media.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 17:21:26 2022
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 4MfH8H55YHz4V2pL
	for ; Fri, 30 Sep 2022 17:21:35 +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 4MfH8G5HSFz401R
	for ; Fri, 30 Sep 2022 17:21:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664558492; bh=I8ZQU1eR2uDNIlRMUbdrr1Kketqw6s3UeGpxDD5rER8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QvoIi6J1KasDD6Mi5D5/okpXDZ+z+zJAd/NuCuyMx7KYgL1nVCCLmMT+zr8heDpXafKckxv9stzI5BpcV0238UmUIOLojmJWFQU1W3kkHkeIvW+nYOozu+L+0ZoOVPUaLqZ2bpwHfZyvcyr7h2Dpzx/G1inuN94Hj7VJG1W/uSdm/oHuSlizGvkVKGgN040vXJuigE8ei4/uDA9jI+ZJ6i8XeoUSPFITLutdGud8Byb3YxNzxV72swx5d/7z7LLC40kXiTnczrgmZahBKjRV/f0Y0/X2M+ICGg34LpgshXcnfRWGARNjqAHOy3KE40UUxAGjDYjPx5ubIvMPiI/4uQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664558492; bh=Ln+jh0RjLey24XV81oe4k1GCY2qvTEJKpyLY+gGX4ju=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kfliMhpzUf3Jeh2GkSmCXRlPYlGau/lf/LcAzJxMqv467QaN6h9bH5lrs+g6ud2m4RBeb6p06KJmUmhYFzYdibgiGQzVkVFgnucdNuSbb9NgHnIc6chfKfrZCf7dTmsQwF3pzLmsxXal7sAt7MnORzCYowZ3yZeFLUc2mpj4d6oKmp6JQXA9DSCVp+spKRRBMCQcDwQcS8y9gB2oVijfCqUA8fsXaftASoOl4vgRCIMwjvok2dqy/p80jDd1eybyat56xpcacvZH4+ba8V1iUTXwByK89yxdSvOC+1snnmwZ0c/HQS01z6erC690qGVDEvmwhKtp93/iurmTL1ylTA==
X-YMail-OSG: M8R62C0VM1n6OPEAkoqXCqcgyLPzoqnnzSLG8hVslqTGRY4mDvnZ.L5IRCEsrjV
 42zYYkUJylFvdO6FHAeP_qxtlE.pldsGNkPhXGJ.CaynggW6jqkhKqbYMmmexc76BGZnRwdmHwyq
 p5d0Zn4_6P6VAvLi7phiv4V.CZg70Fz6yqSGhP8quAP9kkJTkZwjVAEtelk60E7ZfqvE2xNAk5nI
 zW.KRz0psgr_tzKqS5vrRSnDaaTcxpSd0QSUrAqV31z3gXUADRpbBKDeJqCDZi42tPq.17SNQEkQ
 ISdgd9mODErpPBVja3QYvKA5qwDrt_rAIDqkWn0UpbQzUf8iundzG.HfmvuSjgk_hgGs6EFNB.Vr
 FzsU_4tB1pcuFMLW_dOgeFn8VzKYTwNgGttTwthdALGfPKhUVc3qBFx6aRzq.jR5Cn4BvQix05hQ
 OevrZfonu3tcoB8V5y29mb11YZCm_RHqP6o4xW3mX_0SCgCn6D6IuKWINUpdwBV8J55twT6siNOH
 sro2adUQDCKcItF2gPpn6Oj_ngSdHBI3LUrLq6JLxTj4SmS0AWsTYwyx8WC_k8t29FARxDPyQBLz
 FoBB3ZjVOBMXamrRPKV3EMFls6I4wWNepAQh5oTW1KGtVFiZk04c20DGqnFdRZ6x.9JlwMha2UPt
 nSdRjIjgk1BTjymnCaPCuMVl_60QmqNp_dx8oVDVK8rZMP.DsTW38vOBKqD5aOKGkTeFoMmSomnj
 6LwuCoR_f_xLcZpVPWpEF.baV1eio8m.RuN4YTEQyi3XlqqP6x.RGE5RzH8DBHm3gV2m3ZG6nVml
 FHLSaNLhVKftIr9Z1KjrLQr05qLEUb7qGAhKk02vHEnVnC2iTuy__9UbbcH_yRV9R43pZGHQLC4g
 xcVn27pvgKYFKDvkCHVAlGGhiW6QZ6wJ9kRnZS0.L52mAWZh1TcGXZBGCE8qiMEGhfkyek_6NIQl
 mls18I4kiff0H9Qg9jqRBZCDYICepigbLfBmUi6zb9dupwGx3UokuFmIGY4Ag28_Y6FCyhb9dqI8
 KOYQOccC1mbOuv8zqJ1nOc9u7VXBXdv.ipzD_nnIGDLQAVsonjHDsy.py2hF3ugqSRtL9Crc.3wN
 ZeWM7M..LmlQQy4VS2rDmg6c5p156ev_uaUfUiuIn6UXsE7PVV8d4vmEUKlAldf8a1.b4sPDa4OK
 6g4GJGPkx_fzLgYezyYFsIc_ZdacbrzeQP8DTtH1CfR3z4VdwVvwV0J9VHWRKpe.SIsSkZAU7dhO
 f176f7VODCiuiG5PuuSj_WmpWhr.iA4cxux_omsp2Qs5LQsEU.k0k7TgIqE3C6Ad4cfs6A95OhGv
 o.r8c2jJ4vmsp3NUkKneKM1l6JlMpNPPxg0qsMz5VGS3J4EMa_E5pC2EzI.UzunSeOMrdNmBc0vS
 9pRA_F3KRTc5vJoqKVtiV3U8_tYo.sZ2WCpyd.pZYGYfrFx1ue0.Hs_v0LT5p4OpqxnKLj0NrHac
 qAoGSBJt5m8tZGjPrmk_JBXVeuxfZ8F1LYjD1KFD7IY6Yy05J0PsatLmLcGY4M68S1Frj87dTn4v
 6rG0Ti0uPlwj6zVRV7mctdcZVhZ_mComB4OmLx2x4SFaA2o6p2Cdmpr19ybT.WHYFIp7z.QPwk6T
 BGqOwchmIJYYjqKHdt5KSEsMTrh9CVQSggNXUoY0PmXX9qpLZTAoWCmf7yVQZfRM.VCRElC_8CcU
 Ir8NkSWpWfUdVV0.uJ9z8QS_f2h7OlLcHR2aYLJ0dHmCrEjw6P5akSLNTfkX_QBB4hItIOEZWDxS
 I9BFSVa9OGCMR5wj9.POnaw2QbqPcCD5lSml6L.zhfoxy8VZ_KyvZVAv6.Ed78RAevRRNjAuQrBA
 K7_QDVFJlEJWmpS5VqF1mhrO0Jt09CFrEvyIgjdWDuKqSbNxI0rw.f4Y3Qq7MufNliZ2ZebO8A3q
 PdNIpoKIpYQj5Ufbl.O1hV9BdAnOUOOECPDvjlHrAm9SLuzVJ2c3Misvdlc8DOLvgwUnpMD8B2yT
 P8xyTMB1LRA9s1fJAcPZOzQRxzWhaUV3SecS0G0.qOcn2PvbE6DBjLNI0H_b.6ANR0JZhW4OXmF9
 _uCNhuw.K6ZI6V5gvg3tD25iBe58shgUMuhNlqQNxenxiFFJUeg7tSQQ9e_.QqzSC_MyJhlc0owl
 kSrQOqKp1VShAR5J5Db43zQdH.HGYra3GTD7IesAa2TF6kbZX7L5tRSFlObd4P2qFefHG2CmaU_K
 FjBW_BcIsssM3bb2.MCJ2AFNjgZxm_3f.kpkMeEviGzd0P6r0FlBD4VTUzDm9ZpbtI89l6TiYy0b
 3KYCu_9CESw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 17:21:32 +0000
Received: by hermes--production-ne1-6944b4579f-8xbfz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 83274ef73cb9b56346984eb739925232;
          Fri, 30 Sep 2022 17:21:28 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
Date: Fri, 30 Sep 2022 10:21:26 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6327FBDD-538D-496B-907E-00D82D33AA73@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfH8G5HSFz401R
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=QvoIi6J1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 09:40, Klaus K=C3=BCchemann =
 wrote:

>> . . .
>=20
> I would consider to "force" the King of USB to read this file contents =
(usb_hub.c + usb.c):
> So consequently I quietly step out of the discussion again=20
> and put HPS to CC :-) lol

Since HPS has been made aware, and the exchanges tend
to be very noisy as we gather, report, and discuss
information, I suggest dropping HPS unless HPS adds
himself back in.

HPS can monitor via the lists if/as he wants.

So I suggest removing HPS in future messages.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 17:25:57 2022
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 4MfHFQ5TRTz4V3G7
	for ; Fri, 30 Sep 2022 17:26:02 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4MfHFP1dfqz40nv
	for ; Fri, 30 Sep 2022 17:26:01 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62f.google.com with SMTP id a26so10431933ejc.4
        for ; Fri, 30 Sep 2022 10:26:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=J2OwpPZcfhsH9sKOlUllMs8HE58b8ILJmT10a3PAz14=;
        b=PXP4UPfEYwIFK3bbV+GyheIIjpkI46rrMLMOjCwlZiUazXqxg35zxIxMPLXxspy7pk
         r15X/viqvx5Z1tAjfn45Gc4EzMmkTSQ8kV7h89Dkrs8CT6l9qaJDbQYyvQlKewtBQGCy
         IRqOq9umt1liy56T6x/8HdxqBTdkoHdT37MCnoi040W/xRJFyOBNiFoMm1FpRuE+p/Km
         dKPtHUgZ+pwa4TDgZuHLBerrLZgPo9ZkS/4dMMNb99fCes6xg7o1Nq5vsipt8ULotk0E
         x/3atJcn8InNawkslw7FBuUCq5SA9SSC8Uk2npwfHDXkWgbYRwxd3/pSm4BYuVt3uHvV
         jZKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=J2OwpPZcfhsH9sKOlUllMs8HE58b8ILJmT10a3PAz14=;
        b=4AECnTY+jlOpr54t+WMDBQPpInq0LUm/3eyfQ7nvcchsjHYk3SuBTzpEK4NtvntUbd
         dzWdNp2a6h9Ssvt/g2LCnGROZegH20D2ICsLgYfDT2vU2TXtn4appo5sVxEO+FpUhk9I
         sNwt9rM2IelkC3IxQpOvltUIlud2+IEOaTKSiArEQjCOBfOQR4uJaBQrQmuoJRTZGlfI
         FxUPhmgVCXVvrFwCtosaTZHA8+c+emnMB5+hzOwbs1Ua84sjU+JeEVO0HBO9MFz0IFUV
         xIwuBO6wFHwDyb7kMG5ItGBabdjHqimS5t3j3noyd4zmEv6GTrxC4OgyJSgiZ6wxHml0
         o7vw==
X-Gm-Message-State: ACrzQf1rFR51o3vMNAXY87n6LoFdggk1R7jzfoGkhmLrtpLJn8AssVgH
	oegqVckLm1EusCXf03P7S5N+7PLF7Y1MJw==
X-Google-Smtp-Source: AMsMyM6MR+R5Yy5V74ucg07vNJiBlfT0AJNk3kQ3L016GThLTg45u2gaJWonI1aeJtZ3Z0EOM20HsQ==
X-Received: by 2002:a17:907:60cf:b0:782:d3ab:55b8 with SMTP id hv15-20020a17090760cf00b00782d3ab55b8mr7218632ejc.6.1664558759801;
        Fri, 30 Sep 2022 10:25:59 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id m15-20020aa7d34f000000b0045722259584sm1975387edr.86.2022.09.30.10.25.58
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 10:25:59 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 19:25:57 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org,
 Hans Petter Selasky 
In-Reply-To: 
Message-Id: <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfHFP1dfqz40nv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=PXP4UPfE;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org,selasky.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 19:13 schrieb Mark Millard :
>=20
> On 2022-Sep-30, at 10:07, Klaus K=C3=BCchemann =
 wrote:
>=20
>>=20
>>> Am 30.09.2022 um 18:58 schrieb Mark Millard :
>>> =E2=80=A6
>>> .
>>> The 2000ms is from the U-Boot build setting usb_pgood_delay
>>> explicitly: Bob is using the part of the patch that I use to
>>> get my every different devices to boot.
>>>=20
>>>> =E2=80=A6
>> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will =
help,
>> But if Bob got improvements by setting your values ,=20
>> I would consider continuing to manipulate that values.
>>=20
>=20
> It is more like they made no differences so we have not been
> bothering to eliminate them. That way I can build and test
> the build in my context, still with a bootable environment
> for my media.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com


O.K., thanks for info=E2=80=A6
what we know now is that port1 of the Hub is (sometimes) underpowered ( =
1,5MB), has to be 480MB instead..
While even a broken USB cable can of course trigger this issue ,
I guess this is not the first time that an USB hub-port fails by =
underpower on those dev boards or elsewhere,
So `ring ring` HPS,... how to force inject more power to port1 in =
/common/usb_hub.c ?  :-) Ha Ha=20

Regards=20

Klaus





From nobody Fri Sep 30 17:27:08 2022
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 4MfHGm6xHHz4V3J3
	for ; Fri, 30 Sep 2022 17:27:12 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636])
	(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 4MfHGl3l9Nz40ng
	for ; Fri, 30 Sep 2022 17:27:11 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x636.google.com with SMTP id dv25so10396752ejb.12
        for ; Fri, 30 Sep 2022 10:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=eq3BSu+AuBu0AaMpRs2gXHUgiiTiD2rN1JlhT5h6z+A=;
        b=kj0wx5AcCLIJH++4qdZ9rRDAki146Ib8ny2LhN/sPZ5kBDNUxQaJtftIA1fgtt8qWv
         h6KawSDb70BdZdo2GZX6WilsTFKHO1eoT9iM39MF5s5wx170O+peiSZCEyRasCSMPR+u
         4D++kMKy9/9Z6RR0ocOsFcM3R/UKs/jBzUPb3WJOu/TGl2PevIGrfrXUTOceY1eoUB+R
         eXZNV0TbSoYBG8FcaJsPAfzArmGboG/5Dbf2EfUrfS8YAmOFZ9ubpETn2jpLraMcbYCK
         RW1D6hYM4OW2wBys7yHwqkpTQSTZDQ/UlfMmz3KxaaWDpUKitKrxfYQB6hEpJiQSqV+C
         VHdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=eq3BSu+AuBu0AaMpRs2gXHUgiiTiD2rN1JlhT5h6z+A=;
        b=Kn5nB8RTBfkqc/FdGAN+Uwxr/uAWxDGfbrE6OBf6Oj9bjkbOsBSElLeydrB1zUJREQ
         7ECUPeZJcrAwswphMiz6ntXayE1WmlxY0JpRlq9Di2119YEi+XwCqL5CgQQND2Hdp0hs
         LaZ4Fs82N9bTADyiJ1E8GaKoQcA4hlUqPTTCMxiGyf9tLYQk2/DuaYgx2s9KB7PVMOBO
         gfS6dUdyJyrbTNVAHFkj0HCY0qCdRPslBkk3gsPhChTcqyktebA0Ba9ZF7eOesh5R6q/
         72eQALvBsRIQqiB/vZUHGBAMjtzz2Q6/yATaw/g7KHBOod3mQokcNyGPsNlkPDxVwJsa
         Ln2Q==
X-Gm-Message-State: ACrzQf3LkQWE3IzBBFq5CLCOZpeGzfAuD3ROEnBYKujD+ts/0WcB6Hti
	wpJ9Iraqkr6Ap8QxlCABL7PJF2geCKXRmw==
X-Google-Smtp-Source: AMsMyM7RbVpVGGu4FSthfl8BjdrNSuAeBxI2Ptpsk/H7nAc+p5I7ByQlpaKDrJY7LcbLKd548RXymA==
X-Received: by 2002:a17:907:2711:b0:781:d13a:bd15 with SMTP id w17-20020a170907271100b00781d13abd15mr7283100ejk.669.1664558830533;
        Fri, 30 Sep 2022 10:27:10 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id ca3-20020a170906a3c300b0073ce4abf093sm1442904ejb.214.2022.09.30.10.27.09
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 10:27:10 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 19:27:08 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <6327FBDD-538D-496B-907E-00D82D33AA73@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <6327FBDD-538D-496B-907E-00D82D33AA73@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfHGl3l9Nz40ng
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=kj0wx5Ac;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 19:21 schrieb Mark Millard :
>=20
> On 2022-Sep-30, at 09:40, Klaus K=C3=BCchemann =
 wrote:
>=20
>>> . . .
>>=20
>> I would consider to "force" the King of USB to read this file =
contents (usb_hub.c + usb.c):
>> So consequently I quietly step out of the discussion again=20
>> and put HPS to CC :-) lol
>=20
> Since HPS has been made aware, and the exchanges tend
> to be very noisy as we gather, report, and discuss
> information, I suggest dropping HPS unless HPS adds
> himself back in.
>=20
> HPS can monitor via the lists if/as he wants.
>=20
> So I suggest removing HPS in future messages.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20


O.K., no problem, didn=E2=80=99t know that

Regards

Klaus=

From nobody Fri Sep 30 18:36:54 2022
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 4MfJqH0yq1z4V9PJ
	for ; Fri, 30 Sep 2022 18:36:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4MfJqG0vjHz451j
	for ; Fri, 30 Sep 2022 18:36:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664563016; bh=Axl20lTrdKbj5/wIz06nogQ6bfCcGyZ8LPpH2ZDHVb8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hJKxdjBl9jnx+6kxkI67RsYcHetwXmh3Lruqw2X5ONgGEkJADeq2jVeyN5c/5UGf+ySqb/ukNFXo8TGfbEuWR2kmS9kt1G+ckdfdZ63BXYdMEvOVvcn4oZsNQfLasrx4mu0qEPCltBF28B31ZG+2eSxLyNwM1GF7Q9u1Jlvu4wbo/TIfYP8jeQhi6AZA/01U2mR4PBOBmNY/p+nTJXgERjt8thFejwxRqNkpTzl1p7Gnib1SNmvk6N4MMaFDAx7vCpdOTPX9+fE82PHgBHQyOV+xzKXEi39q8kuDXIkt/ira916S7AnrqEAa9oxfIpm2tvr6xqxzOoIaTx9PpsXE1g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664563016; bh=GpDbnsVGavu/LEI7BxieaScdghDVrgLZWxI4fYKgnOm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gi5H5yHihLoA1XCjJn0GiYjmtVTQcNjThrPqFXx220SsDWEP10Naz9L5hWfgahUS3hMelgGM1x7Eckuv1Unvd1i9vgD/OIRTjL4SQoulJw4ajZ0WyIHMrY070RmhbzT4xM/p5rXKYol3usMz5r8TCF7jOXGpDpm0Ihq38Qi5/dNE076A6A116grflwV7O8Z9leacf4f6x0O1igDbCzwzN4I8bLSCXX3Z9bRWz/skt3uLH+f2hqbAfwaQNeG9gNfnoMCimMwmBQX+ZQM2JS+s5TwKHXi4bDZ2w8nZzyazxEJWBBPEJ2zveXQ/mFL+h6w/fUXihECSongjwc8qVb52jg==
X-YMail-OSG: er4Mi.kVM1kJm_iIULDWYj7zTG50dBEmmrVdpKfEv.dPQbbzqFn_Jw_0LeBGb.6
 58gd6xd8FWptbvblXX6og6l9RKUIodgO6NA5URazhrCwwpoaxslAfaE0qcrmv5WTrKLwPOoxKsMb
 iP3cH.u7ujIkKNvOiBFHftwPHOCPXbG1FZ_fbzbGv3yvPSiz_WlHjrjwidiBtwPXXh_C7_FA.JO0
 S8klg5hACGaygYCDMk.ei01hKigTEbVFClSkKz.oViBHUOxSXKTPsa9yTPP0DywAd0PDoMOcYPLd
 xXoZZ7THPSJSb4yEMyqKWcWV3iX0U7HJUf9n9L9xq1Paevmv0WCp98pxMy7IP_pPO9SzuWRoK4CV
 kJtoS4ZkIccsXYXKGnK60_n8jZusRbilI77pbXztDpe70FAnl9KFJzFSb9zeqsKBr55sb_x72Lbi
 FqHoHgrmZoiNfk5XD4jWszCtnzas0Rfdk78fB7feiwcih5VSrYIBUAocM526rtUIYhYdTh92UO_F
 UlLZxAZaLrcZdckYg6lL_cyjrtPzT_K8yuTkDGTBUUmSMMFJLy9HMbtf40qAf9.8XeLw25tApf4H
 ipdcMIjvViV3yih4eAOkrki.C0kAI_Nqp36lzTU_MEABvGasQB0nfJm6b.SBa_qiUeXecQtnwU6j
 Tfq0s_6SPHBZD9aeGFh8KE.89csPjc6MrXtObO61cw.xj0EaiNngO2KSu.ytgBhFbDFJ2n6nxz2N
 jIQhQ6n30nJqrZWEyiTn8Szm42b2THc3pwSzROkQUTeXgo76vWvlhxPIu37OYsxGPiP6zaUeqMjS
 L2D.FLtfxgKwCQqN0iHzDlK8t3ysMWjSAItzi3DpHXQMKQ6vlJP8uP7pcKevY9YAix_vaqG7BodJ
 F8Jyd7H5XjSswieXHDoz.ByItzinq7YyASrvc7GBX3oprwevDPRKksizzU_PmbwbtxffN6PufhoY
 dSLivSSLkqI3zOJwdNPYIGv4Ix9YrhgbefnelnsDLQ4hKWaOu1XGZ425CQ7_V5Zcr79gXaqprEUI
 VAtxlZ8K3OrVXgWRcpTfDWaY5wvP4ehnz7_G7xASygIihuBM7m1Cm5C.9yG1WYaV.f5N3IkMwgGK
 QQQV83LSGuY_pYLckT6eMrvKqoqye4DcN1vxvo37kjrIgNFDhHdWVFONxea4ylNXo_0PX88NPq.d
 dfX86NP0DtcYsejgxayzImhW0d2rm9e25YLZ8teJhHVKs9YCWfCAFrbYham.GMCcAAyPnmHqXFRp
 EfPRGff4G0usY3wiB9rkTWd4LpamccBn2vMl0sZDkdwGWXPLZAqUmC_AL.yj4IeIbN6xIsllzPKS
 WwoiCefUC8oPUEicp48nwShFVAcfzhQlm827jVhotksWV4dKL1h5sZcenqx46roTWw37a5b4uT8F
 ktTe9wJN5Bq0RbShDuPCuhnV0BXsmJKi5oHsTa.7vkY6j2x9cpZWLWUG5AlCB_vAfr8sqAD8R2.p
 efHNj4UIRsIz2MVUd6oVs7sfsqVeHyWWe_jdoOoTgTyUyMOGIg31xxhFW8msLfiPuP.PTjlvnafU
 P70MDlB2qnDM07TxmilwsN_cFccoXF969o2_93nJY93dZkRvJfrKtsmLi19Gww50HUs0rz0JhAAK
 Og33jqpCqBmzCggIt9JVa8_wdwx55DhpmhHsnS9PUkoEgksEi5NTAZMvSXb30uh3w_w8NkR.pevI
 9K_O1iyNaLeLEBV3oMJ4g2PfXPsv9rOdvhjRlhAwoUOEkdJtcCXkSkYy3C68xWDKxTRiR6d_Jwm.
 VescSUjQsB46mPi.Swuf3AaYq7YTvWEAYa1.jjHj5TASccOYPvEtYrlpJUhJWEzdA83BLXxNqZ77
 AFzZViunbCDOVGteKadhyJ5zLg4tzuJZxqNk4pAmCam3XxU_bMVOC84qtdET2X8SeHejCNgzjXIY
 0VeK.PB1PYvdCQc1_ImHZp15FEnuvpdtc2V9RS1qO4UKZZLxzlypyhmML3rubZng1zWNJ3v1AanE
 Ynki9yGP0epYYFyV0qKyCLZSLynJhTrEeHnPM_nzhOhKGO1o5cpCv2h9_KKeeffPUtD.diWPTCBS
 WF3VgpXGOKUqtOdekBAr3_aRPIMvaPK28g.OxL.80xnsg1qB0_bRT3xhlQBLrFuGyb6wUrz5wVi0
 usflc8tDAeO3sA1ii0_fI8fIXwS81YpvbUBMklMmpN6hgdmo9CYA2RZ0_Pg.Bb5cdW4Zv.wWii6d
 ofSnsz0nAAHJQUT8I5oxFARuPsJZXBDcmb4oxrYJrGeBJrxe9ISpNcJWXiYaBswNXubtxesG.Zz7
 3wMnjRhtn9A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 18:36:56 +0000
Received: by hermes--production-gq1-94b89944-9wm7v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 146446b5c251b66ad4bcc061c0caaba6;
          Fri, 30 Sep 2022 18:36:55 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
Date: Fri, 30 Sep 2022 11:36:54 -0700
Cc: bob prohaska ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfJqG0vjHz451j
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hJKxdjBl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 10:25, Klaus K=C3=BCchemann =
 wrote:

> Am 30.09.2022 um 19:13 schrieb Mark Millard :
>>=20
>> On 2022-Sep-30, at 10:07, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>>=20
>>>> Am 30.09.2022 um 18:58 schrieb Mark Millard :
>>>> =E2=80=A6
>>>> .
>>>> The 2000ms is from the U-Boot build setting usb_pgood_delay
>>>> explicitly: Bob is using the part of the patch that I use to
>>>> get my every different devices to boot.
>>>>=20
>>>>> =E2=80=A6
>>> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will =
help,
>>> But if Bob got improvements by setting your values ,=20
>>> I would consider continuing to manipulate that values.
>>>=20
>>=20
>> It is more like they made no differences so we have not been
>> bothering to eliminate them. That way I can build and test
>> the build in my context, still with a bootable environment
>> for my media.
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
>=20
> O.K., thanks for info=E2=80=A6
> what we know now is that port1 of the Hub

Which "the"? The Hub in question is internal to the
RPi3B. It also shows up on my RPi3B with no external
hubs involved. (But I've never had the failure mode
occur.)

Manufacturer=20
Product      U-Boot Root Hub
SerialNumber=20
bind node usb1@1

It is a hub with 5 ports, one associated with the
EtherNet port and 4 for plugging things in. Or,
that is my understanding.

I've little clue what would interfere with its
operation in this specific way.

> is (sometimes) underpowered ( 1,5MB), has to be 480MB instead..
> While even a broken USB cable can of course trigger this issue ,
> I guess this is not the first time that an USB hub-port fails by =
underpower on those dev boards or elsewhere,
> So `ring ring` HPS,... how to force inject more power to port1 in =
/common/usb_hub.c ?  :-) Ha Ha=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 19:02:58 2022
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 4MfKPN3HPBz4Y9tQ
	for ; Fri, 30 Sep 2022 19:03:04 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4MfKPM0cmDz3Bw0
	for ; Fri, 30 Sep 2022 19:03:03 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x634.google.com with SMTP id l14so10910499eja.7
        for ; Fri, 30 Sep 2022 12:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=zqHmN4KBNCJNqMNanP2gh/ONt5nkImZakqkoao0QRCU=;
        b=SMjXjK/IVfB1TN63z2Kg2aDbQfMbgGjTFD0McbvVAh6YxKjjHG1Y5K+OE2lT60ncV0
         olpzhxOWFfjJ/leOS5d+6IZEoN5EOoqxD1ZalA+ryKPEzDKglb2jUNfB409uIJ4xrAtC
         Z4hokYi0+Isv+KinxMsacAjzFGjcuh2nhj/PuCHrbl0+7uis+jrxnRzADYB4XSDQ3mN+
         OOAF5e8qkQDmADKEevR3UbWmRg204iSVFUNi61/LqVqOiPQx/9r7v72KiaSPwQ1spyXj
         od8TqkaOSS4fGGww9Tgxrwk2kAegFhSb2LVfF27dRY2/m2qiDPEaTCj6l4g8g/YF5+XZ
         nCQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=zqHmN4KBNCJNqMNanP2gh/ONt5nkImZakqkoao0QRCU=;
        b=StUQ0EbNkLdZhNW9yAQ6lJ0Q7TQsKNwF60kSRjOs+92J18kT2AASE7e6o1GbJCvCDS
         zculAN7Q9psZqsEfIKTodjrH91NLP4uTvDBHYqzxgDHlLu2CMJG3Ln9VK0ozLZKGXZ3o
         xg4xi8TY6juGBvJUtPf8mI9Pow0439UHAwiVFA/VT7kjmxzy7KzwSeGRORUzhmqLrUw6
         LOEIT/32QybYAVg6LebWy/v/2IvIcbHO7FVw21Tp+Am//igbG8oWv5I5y3BmzqobwzU9
         fuP+xio2Fm1AkmC54Pn6aIJPxBTl+YXSFwf0vHsMf7/Gir7I+gePmW2WZ1B5U5URVbkD
         +qNg==
X-Gm-Message-State: ACrzQf12EdS88tJtUep6ZWz8O3YQ8VniAZ0QDIN3AQchMa/MBm+tJG6P
	t1EvxMtbFEEWKNASYHGqVPs=
X-Google-Smtp-Source: AMsMyM6PiZuLswpbyB8yC7Kdo07ewmCmgbjh1jPvSy7PrswfWwgMOUNsnQNyKwAeRwEU6txoiYuE+Q==
X-Received: by 2002:a17:906:fd84:b0:730:acee:d067 with SMTP id xa4-20020a170906fd8400b00730aceed067mr7568989ejb.206.1664564581449;
        Fri, 30 Sep 2022 12:03:01 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id cb15-20020a0564020b6f00b004576e3aee69sm2205532edb.4.2022.09.30.12.03.00
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 12:03:00 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 21:02:58 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfKPM0cmDz3Bw0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="SMjXjK/I";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 20:36 schrieb Mark Millard :
>=20
> Which "the"? The Hub in question is internal to the
> RPi3B. It also shows up on my RPi3B with no external
> hubs involved. (But I've never had the failure mode
> occur.)
>=20
> Manufacturer=20
> Product      U-Boot Root Hub
> SerialNumber=20
> bind node usb1@1
>=20
> It is a hub with 5 ports, one associated with the
> EtherNet port and 4 for plugging things in. Or,
> that is my understanding.
:-), I started reading the discussion from the beginning because I =
missed the Hub-manufacturer in the logs,
Now I know it=E2=80=99s the internal, thanks for Info .
I  was absolutely sure from the beginning that this is a 3b-power-issue =
(regulator or whatever)=E2=80=A6
I guess you also wrote that.
Since my lowest model is 3b+, I never turned on any RPI during this =
discussion.

>=20
> I've little clue what would interfere with its
> operation in this specific way.

=46rom reading the logs  we end up in line 377 of common/usb_hub.c :
'cannot reset port=E2=80=98
The comment beginning in line 305 indicates that perhaps more attempts =
of a reset=20
could work around mysterious power or disconnect issues( although for =
nVidia not rpi).
 So by guessing I would say, a code injection of reset retries could =
perhaps help,
I would ask a long year known USB-expert if it=E2=80=99s worth to try =
hacking usb_hub.c=20
 but it=E2=80=99s better not to call his name so loud again :-) =E2=80=A6

Regards

Klaus







From nobody Fri Sep 30 19:19:12 2022
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 4MfKm56pvTz4YCbD
	for ; Fri, 30 Sep 2022 19:19:17 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4MfKm45Gwhz3FHY
	for ; Fri, 30 Sep 2022 19:19:16 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62e.google.com with SMTP id nb11so11019509ejc.5
        for ; Fri, 30 Sep 2022 12:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=waYWCYVaVN5Gd8Ogm0g9eBdcXzQIiK4sI9ghe/fIP1M=;
        b=LflTtNyvBWg3HmY3SxTznR/Mc4FzUgdO3qKAhXikNVoehTlszHWp0GYWD1OmSFmJBS
         0H+G1+izxk9Uv3R70imCULLk7h0plQxXv9r0bnHjGxaVBEI1viETLP1U8xgZkmSplG7p
         rO7C/sjBY8aoAj+xNUKLU57bJCK7xHZaLhdZoX1ouXh4nmQPMHr67UU1XDa2d/0mjXyG
         4zLn59fCvrdji6RL2MTrZXJQZUxtaH6TegXdCjzpUkbqEEYJzq6JHIWY2NssAdseUDID
         saEcQm8vGaI1sBMS9w0K0Rcw1Q3au539Wmnv1KLQEIi0brZJEwMgx5f7OSs4GsnbS9l2
         Dz5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=waYWCYVaVN5Gd8Ogm0g9eBdcXzQIiK4sI9ghe/fIP1M=;
        b=7UsaZuPM+buhbDiItgLqMKv8lA3JjTmJWn5Bejrf6PKCWIPSzWxabuXu8ZsPLHzyxK
         eYpkTD4NhtUk5ElMzCJW6kwO32J6z7wfCZtspiTXM8urM8LjNVqCxHNh4QZEq4ZEeKMx
         ahBebp+AA+pJAbr8k4dpJSlissm576f52BvFqTHhgp3nWETZ6A2G52fMjLt0141MgT8C
         91a69yJCgJbChxINL2tH+QR2P4m5PYuJQFADLY+HXtcQJIpy7VeVxOE+XhbATrAqYVV3
         kpuJmR+/Jix86AkJLwnP6a6v1SCin0ng9oGGEvai+RATBchuHRF5mZ3BwA5LjyQxhzBt
         +NxA==
X-Gm-Message-State: ACrzQf38ntHJw0boRhup4xM7FOYJxn9L4h07emaorU5+e7DEb/5OVWZW
	AbZWhab0y5LBujVP0qnEWkJcNmw/w3Mdkw==
X-Google-Smtp-Source: AMsMyM4BhSeTB+MDrFeiVQGYLH3NAW7YbMRCr4g3XAtslPRsdj8ssqMeMgwfxrIB+7ZY6OIWQaJBWQ==
X-Received: by 2002:a17:907:3e06:b0:733:693:600e with SMTP id hp6-20020a1709073e0600b007330693600emr7132753ejc.410.1664565554295;
        Fri, 30 Sep 2022 12:19:14 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id gl14-20020a170906e0ce00b0073da32b7db0sm1551298ejb.199.2022.09.30.12.19.13
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 12:19:13 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 21:19:12 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfKm45Gwhz3FHY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=LflTtNyv;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 20:36 schrieb Mark Millard :
> ...
> I've little clue what would interfere with its
> operation in this specific way.
=E2=80=A6also no clue but:
Some months/years ago I filed a bug report(RockChip) with a similar =
issue(pcie/M2.nvme),
where the nvme was sometimes detected, but mostly not detected(by =
u-boot)=E2=80=A6
I closed the bug report after the manufacturer posted that this was a =
hardware-issue,
caused by an onboard regulator chip , which was then replaced in the =
next hardware revision.
the question now is if we can workaround those issues by port resets or =
timeout-hacks inside u-boot=E2=80=A6 if we think it=E2=80=99s worth the =
effort=20
for this device.. USB expert help would be very appreciated ;-)

Regards=20

Klaus




From nobody Fri Sep 30 19:36:46 2022
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 4MfL8M3l7cz4YFWb
	for ; Fri, 30 Sep 2022 19:36:51 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b])
	(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 4MfL8L4xttz3L4c
	for ; Fri, 30 Sep 2022 19:36:50 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52b.google.com with SMTP id u24so7238975edb.11
        for ; Fri, 30 Sep 2022 12:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=f5sqi95Yts9yr1GSgdyKoI9w+Gp9CXWTMHm5wdK7a/s=;
        b=UDMm/tSgAjvFiKfhIexjbJcXORFZEPVAS8ifZwcClVx46flWizUipSl49e9ZtdbYR6
         2f+uIwltUHh3J8voOWwkTzZrb4AAsYFL+gvaJUMi6j0/s1IneNIDt3sS5+RRRcFO/mno
         BcDmszKTq7kv5pMR5SmGd1EDakr+cU/FaMsrU8NdB14NnEuFP1tQlYCyECRcTpGrRuoI
         zH+/TtQi97flWolnv9HVOkBDU6kL/69xQNoNCTuD/CjGKMSNOQ10dVxzZqx5SjooEQz1
         ZxomxloloUO+p7xE94QKgpiYhxHluURquKvWgzx+2wBDe1nOP6KLAVs2qJuIvTfgmNV0
         BNsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=f5sqi95Yts9yr1GSgdyKoI9w+Gp9CXWTMHm5wdK7a/s=;
        b=eROmtfCnULYAh92sD57LPo3EVW+xN8xFnqQNjlhklTzAMOMyNGlo6n/byjHmAmhswg
         5WHvpZsCB7W9Ams/HPTD9gWuqrXQm45dGpovMb86h9BbCIWaZgU4NLhZAgeWKVzFCU+n
         OIt9mXrfeo5ZqbyiM5E0sf/GDfVLanlbQp6LMIc8FCrRHElv/UGQy/s5uWlEs/k9vW72
         WdzSMenb92KYfZ+9CZDRDEvORpj+QKYEvfZOijz7dY9u5F2Kkwf61A4uuQtCJCxLFCs3
         ctpnxZ8aSzVx3MT99QnUb6hEKhBKzVn5+uU/VyTQ+G+cP1dT/VKMgnK9+JFqYg3jVXuI
         H4Zg==
X-Gm-Message-State: ACrzQf0ApbARne4eLUCQHNG2o5JM8l+OuSYS+1KypvVJZVQzGa+QGMMp
	bmhyznreIrsmOtuJbgOAgvI=
X-Google-Smtp-Source: AMsMyM5/S2wPdulgMIKRxUBbzpMGCVCD9COVcbd8sEW5NHMjxBsT3eyTbmM9fW6wegmqM/VFBlKHEw==
X-Received: by 2002:a05:6402:b4e:b0:458:9b11:da56 with SMTP id bx14-20020a0564020b4e00b004589b11da56mr1732241edb.140.1664566609426;
        Fri, 30 Sep 2022 12:36:49 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id ca3-20020a170906a3c300b0073ce4abf093sm1579142ejb.214.2022.09.30.12.36.48
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 12:36:48 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 21:36:46 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <939C6F7E-4B92-4F72-9AFD-C29C8B59B42A@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfL8L4xttz3L4c
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="UDMm/tSg";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

=E2=80=A6`found  someone in the WWW who fixed similar issues of an even =
earlier rpi-model=20
by increasing/adding mdelay values,  no clue if something like that =
would be a valid test worth=E2=80=A6
Like this :
* requests in the first microframe, the stick crashes. Wait about
         * one microframe duration here (1mS for USB 1.x , 125uS for USB =
2.0).
         */
-       mdelay(1);
+       mdelay(300);
=20
/* only support for one config for now */
        err =3D usb_get_configuration_len(dev, 0);
+       mdelay(100);

 usb_set_maxpacket(dev);
+       mdelay(100);


Regards

Klaus=

From nobody Fri Sep 30 19:37:00 2022
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 4MfL8g1qZ6z4YFPH
	for ; Fri, 30 Sep 2022 19:37:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4MfL8f37hRz3LVH
	for ; Fri, 30 Sep 2022 19:37:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664566625; bh=waxKo9SZmfWKwyDKxeA1jNtCbxvCowMG6TqsudOMZWU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uDSImt/Skt1oqGS13BeqaepQk52BjhkO0+C2lCaz6RWPHiX1njKXipMhxqAFrTVAgLXUTxiIOTUQZhPjV2+Z0xCYDkqVoASJQH4xJpjjlZwmLiFH4aX6/W+/tfekdgFEzR9YWEkNiIKxzHp6p6TW5ilsZOaZP/QPOJozfuqx1U5BHYL7MNiPPw+78PRaFFpzbsSzPxUAJL4M4Row4FYJ9UBehKIYOOQuz51NeDzP3q9C2fQOG5BPmX79pIwVzbMO8SYh3BeFeiydFWzYUgLyCJ1r03YT6LYkmIgTGjkWO/bBjsavKoU1mDoU69pF8zm1xCvPF9HhfSxBuSWK3DYDpw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664566625; bh=eM3r/zihLpiYNecQ+6NTyOB60SehdTSSoZqBd3pfdXo=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iwYUzsjx/hRSsjlfNRhjZidT9etjJnyFXc0tupPVJJYIj2zDdopySlEBbK5YMwYP7usLq29bk2gRXA5++Wpfs2KdjmJ5TrKofRBuGlHwPrkkZtB8nkGaE1WFuLUTuMgT6LnCW7XqqWTH3F+8VaBJVym+S/NYR4RWLTDkPaC1jrK9IJErWHdUTUyRY5DDTD+9BlAGUzOalndsyUqA4zkK5WY145Cq7BD+1XdVQndkr+ipAaPL7PJhJAOtDgFAoJrS82+9dhZbOa4s1UjhXFrdyX+s/N8/RhXTMZlHS2LveMncVo6v/A4H64h6LdbK5f1KRmSe0r0aRUrp8cHeo2kA+g==
X-YMail-OSG: NoW2wFAVM1l_5VHNSNaWcxgpii1k3ylOrw8tIQsvYCPAyx4n8344XFdp1IgPrtj
 cgwMfGfOE1xEWwUfSD0rsdc0kGTU1CAoj_5.jQY6m06C7Xk1RltnVu2HBsL_pSfVenUTOCOKKz2y
 DQK2CWSu0D7n_h.6XdKyZvcubqKF.KgUO4igqk4LSeFXgHwNGjLfOdRhtJEOxqvjktPQDZzIMP.9
 PtCsvOuVMr8UbNahvwoemWqiD3771uRWQkw4hurMa6s5ekrHOWFMIrJUmJM4yAaIzC0dMD27uhdc
 V7TGRohXOO6OfDnpozSNEpNUHzYuMLcL2xvU_9uZYKEjGpdrpg9P8pwEAqXjLtsMEvlrplL3ugG6
 uJ1qHEvEUFzYl1Q0_1x45FXgWsM2QqpY3BXgdrDbTWXRBt_kQdpeuovIE3_ysbK7FpOdIUu7aAaB
 sJ5SSioyA0R.R4AylYJTCO.qjNnevbzO7ksT1gsJmJJbrQOnxKeOwOLLV32OfQNn01yUlIR_lkTG
 utpd5zot.0n8MVRK4Ju7Is_BHCszfpdkac0gMRw3C1h.14aBvoBYt9bBEf60jx4L4H3fyIdsfF97
 ofKAwlPhnmzt7CuA8IgsVefQSuvvTCTrDg4OPTwibH3g9WZclzWzqBySno0yERHbJ.4hZkLi2AP6
 Jm4yqDneQHdfRcgJVQL7QdRlzSpuLPwFn15PNOtRRBky0Bm93qwj3.uggibXFFR_RZhUx0nqr9J0
 4kMdLVhi0C7iXODmYoo5kVNgMJjOfAC0ypganHNj9OhxeqzZs1x3nVD09xD_dBcIt0XGRs3j1bvG
 sKCoiGeF.AHNWzsw7e.Dcy.GQLNe65TP0F1v.vgSESiJgFfhXiFCA.ths67.UOFzQlRqa8LVW2L6
 _CvaxAtaP9iX1.FA4gJQlhfs0ZXp67byf1GpNCQCkZg3YO5rPcBSb9KuxJej6lei7Ae8aK51RcDn
 bjpBetyGDV_ul64v.bb0YNqT_2.i2AF4goFaJq6xml3TkSTPLmVbvXFdST77BVZyZTKN7dBoEBJ6
 _x8R3nmN3y_FKbXjA55Du0vGdFBJAqT8wz8NLc5dqJxIeLz7FDYbz1eQjO5Be9xZvcLyijn0tosQ
 OfMKCtskqfLlT8nZtdT18Zb0DIu_2ZPk8zYkKhj2j6FdtxgysUSklvNYu5ZPtft07gDaAHn.2SZ5
 XTkWZmmKatod0WZzRkrHsvgQyH6X529n4tX_hYBLOvZb_OZOgC5bDjhcTxyf0nf2u2rjPo4nARoZ
 80NMjWVpxDil2BmNxZbloky5A6OrUaAiQ07bsrEzfHzShPatPwWeTJX6VwDDOkxUt8MARZCvqgRd
 ESImTAAZYeyCXs7W84zvGNcoHB8P2LTQCOMPJEU.xGcsFlSWCXc0YJeX.Huh8XmWY9Y3quIpKbAN
 fL8w_ARDvK75vLm7tQd1IegUavWQNIM5nBbUGef.pnC_BQc1vaxpAMfkVs3I52S2JLUtvfIcX2eo
 zJM3xhsQvlp78bxngfAJlpRkJ4F3reGc_mO17CHViMRr7EMu4euOc262bpKGwpbIvMmYig.NpF1F
 OBkrqiZqxj.QGl8fiEvHq6ehregcurwq2hR.kowUHqiz6wLmm4FnFIfSyJp0wV8vdq.KLQIMYYSh
 wD_n4eX4GzrcjNNHzOuNyorHT_HdJo4oIc8m5.oH2HTP1LWKZRFE4p5RH9UdGxQecutIhh6FIdEj
 gwNkbvGKfNKRVv6E8J0zdWfQav3w86fy94o.OA7BJigrb.SMOCOGzZkfeExD7MGGUeW81beqMakt
 5CO4W_lDsZkbvXtuxOE6KlGXTtdLqNCalaZgiu5x.UIDmdFb0e0aVXgjSHhc41EGmwZMbfbBN0De
 voVwQGvm6hqPZDm0BKokRt8ohjU7dy_T.lJI8IHUx22V7KW2mLtKpHAM7W.UMaYc5ylv0R6poRww
 wzCiqgpp7o1Oq3jDnUPSS4SDGpclJjJgjSmhUvlteMawz2OGI4mw0pf0bfkKIkBSFyQ7IpfW0xPY
 A9_ZjfncY2v69bIJVheY5_HqSrvvZvC23oHmBmoNqa2q0s8uIhW0OPzOl4r04jtNaRxIF0pLtRTu
 K1ToGiRTjmVTqkYuzp6jLqjXtOrG8_uxmEvhDAQS4gRGmL.l8lC1uJ3zWDmk2as.ruoBmur2stED
 09ewzkcbTR82gESkgQfZYLLI9iGBirlPxqgkjYhzJHrHxkiHTvYEDRtY3NktJy4x7RePUu8ZZPAy
 iDJj_KonodoHFZ2ZfWThUG4JckCGYWE4y2VgBQTIS9kN2AttEQ4FxPOmpk_45FeOsRQ16ego52T1
 AFcl.N6J9
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 19:37:05 +0000
Received: by hermes--production-ne1-6944b4579f-bhhwb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c00c77fe83de37a8f0ed84755faee9cd;
          Fri, 30 Sep 2022 19:37:01 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Fri, 30 Sep 2022 12:37:00 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C6619C8-CE5A-4B3A-84F0-2F02BC2ED4D2@yahoo.com>
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
 
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfL8f37hRz3LVH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="uDSImt/S";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 12:02, Klaus K=C3=BCchemann =
 wrote:

> Am 30.09.2022 um 20:36 schrieb Mark Millard :
>>=20
>> Which "the"? The Hub in question is internal to the
>> RPi3B. It also shows up on my RPi3B with no external
>> hubs involved. (But I've never had the failure mode
>> occur.)
>>=20
>> Manufacturer=20
>> Product      U-Boot Root Hub
>> SerialNumber=20
>> bind node usb1@1
>>=20
>> It is a hub with 5 ports, one associated with the
>> EtherNet port and 4 for plugging things in. Or,
>> that is my understanding.

That description is a little abbreviated, skipping
a stage of hub. =46rom the RPi3B that I have access
to, with only a couple of USB ports with devices
plugged in (so some ports not showing):

U-Boot> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |   U-Boot Root Hub=20
  |
  +-2  Hub (480 Mb/s, 2mA)
    |
    +-3  Vendor specific (480 Mb/s, 2mA)
    | =20
    +-4  Mass Storage (480 Mb/s, 500mA)
         Samsung PSSD T7 Touch ***REPLACED***

Bob had reported seeing:

USB device tree:
1  Hub (480 Mb/s, 0mA)
|   U-Boot Root Hub=20
|
+-2  Hub (480 Mb/s, 2mA)
  |
  +-3  Vendor specific (12 Mb/s, 90mA)
  |    FTDI FT232R USB UART AM00KE3E
  | =20
  +-4  Vendor specific (480 Mb/s, 2mA)
  | =20
  +-5  Hub (480 Mb/s, 100mA)
    |  GenesysLogic USB2.1 Hub=20
    |
    +-6  Mass Storage (480 Mb/s, 500mA)
         JMicron =20

and:

USB device tree:
1  Hub (480 Mb/s, 0mA)
|   U-Boot Root Hub=20
|
+-2  Hub (480 Mb/s, 2mA)
  |
  +-3  Hub (480 Mb/s, 100mA)
  | |  GenesysLogic USB2.1 Hub=20
  | |
  | +-6  Mass Storage (480 Mb/s, 500mA)
  |      JMicron SABRENT 000000000000A
  |   =20
  +-4  Vendor specific (12 Mb/s, 90mA)
  |    FTDI FT232R USB UART AM00KE3E
  | =20
  +-5  Vendor specific (480 Mb/s, 2mA)

that are the same up to permuting which device
goes with which of 3,4,5. (The 3,4,5 being the
numbers directly under 2 is stable.)

> :-), I started reading the discussion from the beginning because I =
missed the Hub-manufacturer in the logs,
> Now I know it=E2=80=99s the internal, thanks for Info .
> I  was absolutely sure from the beginning that this is a =
3b-power-issue (regulator or whatever)=E2=80=A6
> I guess you also wrote that.

I treat it as a possibility. I'm not aware of a
good way to get solid evidence indicating one
way vs. the other.

> Since my lowest model is 3b+, I never turned on any RPI during this =
discussion.
>=20
>>=20
>> I've little clue what would interfere with its
>> operation in this specific way.
>=20
> =46rom reading the logs  we end up in line 377 of common/usb_hub.c :
> 'cannot reset port=E2=80=98
> The comment beginning in line 305 indicates that perhaps more attempts =
of a reset=20
> could work around mysterious power or disconnect issues( although for =
nVidia not rpi).
> So by guessing I would say, a code injection of reset retries could =
perhaps help,

FYI: Bob is using my rpi.h patch that enables my
devices. It has a usb_ready_retry in addition to
the usb_pgood_delay:

# more =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20=

--- include/configs/rpi.h.orig  2022-01-22 06:03:55.862541000 -0800
+++ include/configs/rpi.h       2022-01-22 06:03:05.435341000 -0800
@@ -210,6 +210,8 @@
  	ENV_DEVICE_SETTINGS \
  	ENV_DFU_SETTINGS \
  	ENV_MEM_LAYOUT_SETTINGS \
+	"usb_pgood_delay=3D2000\0" \
+	"usb_ready_retry=3D5\0" \
  	BOOTENV
 =20
 =20

I've never checked if my booting would by just as
reliable without the usb_ready_retry . Both usb_*'s
are from one suggestion I found on the web and I did
not explore further once booting worked well.

> I would ask a long year known USB-expert if it=E2=80=99s worth to try =
hacking usb_hub.c=20
> but it=E2=80=99s better not to call his name so loud again :-) =E2=80=A6=


HPS is aware of this issue and of the exchange, and
has commented earlier on --about how port numbering
works (at least in one particular library).

I'm also not sure that Bob would want to maintain
his own patching for sysutils/u-boot-rpi-arm64 as
it progresses U-Boot versions over time. If all
potential changes were not up-streamable, I do not
know what Bob would choose to do.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 19:58:52 2022
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 4MfLdx15ygz4YHZc
	for ; Fri, 30 Sep 2022 19:59:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4MfLdw2MN7z3NwN
	for ; Fri, 30 Sep 2022 19:59:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664567938; bh=D6fKcpzQuemVpyYG6FWs2sVluaJe3dMSf4d12WD0ZUo=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject:Reply-To; b=Lz/Wv0yOFaJKUb5/km9WY7QgGc42/j6cR8zNp6Y5SDCI1qanecCggLtQO7jheHJnJ2akwBg5aRdZ25M03SkdU6/+T4eF5Q8xW0wyyiOAi5Zo34rCeF6ZM983Ps+ysDDeUTsa3FuOq7Z2f13cxa1me7CSo4IsFazyiQ28DMkHD2R4NPhWbgo64v74p+sl5VMbFBGWT8UIRdvQ3LlYf1o361PjCBQVh9k0FOJwhQTANQx+24PqFqNWkqPQ6LwEGVbWAwjBolcijHV/g1ZA6SgX4b9da5SEMYaSdei9GI54dYctAR4ijjnxsQJHVVVkujsInZVHv465kCLwEElIopEU0A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664567938; bh=50UgU3lq1HkG/R1mt1v7yodTgmHJxwmvQdcj+U6tKne=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=B0Er5GINRHfYtqEuBVAKpxFnsq3OvWQ30DEsYZJVjs6FAt0unVLuyBSIdlAEB4w2dxpFu8PvbrDc6hREUP3obJmrXGElsCq700r7c55PASd5RWlTHK0RUNTXk2NSW+U+yw7cQO9tR15R1fcEaowaq32bF4VyBOgx/EKwVGknEG5g6u2Q9nFDYg9lkEzvRyomlSVNyaRac8BK5kSY70m+ef1204ZDnraTLCc3M8XubXrWKxYMduwmlvJ4O9fmK8xJUHVNUGwdk96f1Q6iI8yDx2MWF90hkRYtJslWDj36YcfH0a6mUR9N9j34lufkseC6TRrKUhA57RBhUlYxK3m0FQ==
X-YMail-OSG: 0JWl9gwVM1kZlb.nnjBlCc0ERna_kRDCLId2wt.StxW1EjeZz9yJJLqdBjUs4iZ
 1PirbXEGdMaAoDu2wRsWUWqHVo8LXmky3IjYNYd1ZGWEhVaafGshvvhI0ElxLdaBToillnZRWCko
 Ve6IgiEfZWOxV.SEgtoazd8anMH1Lid301oomR75.b_z.O6GRjjYj1Q.J_65mhxxhrfHfgNzIBwy
 8g3j7SG4GrSMmnKEjYur9UEDR07d5WsHzd0FbIzh3wjXQXDnndnJ2zDbrZUziQBQWqMi.TLielvx
 w2hw4av_bXU.pEjZu6g2kQifQwGPR_t354rs2wZht17sUWW54qUZTwN_ybL5E7uTn7c4SZFU6QQK
 qjLL1M8hMOE3lC77rvh9IjZkHcTMwLRGm9HTgBzD14ZodDAbckMhyw76Wk1APr79lPSg.ieB9.d0
 MMtijT_LQn9Q1E.Pp8iFmcQtWJeoCBf3wNmlig.oglhaA_bL2h1EjlJhKLEsXzUdxfF_ta6g8Fxg
 XCiMkhGQ3vbkHw3WwM0kSsYNK4JKrG5i9hjwfHvoU3pgRn7BrJMPewSHM_9l.29n17Q1B02iOTe.
 R05ge3OS6NQQO_hWb9WV3tyQs.450YkKLhm19T3py.SAhlVc0v.ZWnId8L7._UAR9UkNLoTPHDMZ
 UK8Vxes5U_raknx_khUC_Q8ttkjVPFhT.OyhZZLKJqdESrAjUUZVF6gAXYSRwwGnWNLluvdnaqiR
 B12iGhDV7xBZPCQM_4uS9CQ5Z6e21Ds6eJK2LQzVF1c8wNzaIWQwLA_SxcCbIU0TSf4Nio4Ni5Hl
 TFH9.r75JP6dObVGwsVQ7rlnAGlYhLIWnfnzW6rMwMZAinkfBfiNAe1v12pESVDxBqmjIBnHat5G
 6pFszLzpGzyQ076zNLPdheBG9xd7ZiOMBlnZyV6e16dnHVeLeZ9Ij0NEoQ.57fvg0ZTBfVk.BFyo
 sfqJ5ljmPCyVkivyY6xFKe6qUpBbHsRpn6YHaQ.dhw7_2DXSVAeyTRewX9JhQH4HYJy6HekymhTr
 0TaL1KWJrYos.Bv5s0Wqv3.ibGQAdsuOybfvFoeLGLIcus.SEkFRhZquvTDESNz6BQ0lGaDqYrbq
 araWaYwpi6aQ1_u7Mt4O35gmfOtXFLrEErapjb062ctdBfd4_zJNh1bBoioVBY8ldk93g20MWcbi
 bL4h_zYMfOcxgKAr.Pw0eRAdlGqXZgihWSD9yruWdVZpMEt_Weer0soFZj3Ck0ofpTh.A.9LyNO2
 9sZpzeiF9W8hXE_mAEnTPWXmoq9XSJsJK1xrZSmarHKdcztrot7rRXJQSCtfIoiWT4wCWvIdcB4.
 3uMlAq9ZSxlnesUn7xjBAnKXdhac4YrTLSc9LI5fbljh2KicBBiiJYSzbswjDGCeEU7iqR1V5I6W
 I8GqLBIh0x13gNneI3d56WdkVsGiPUk7ZdOTEnk08LW9rSZhYXR4YiJ2WlmmIz1VXFrkAnE_TxlH
 XdXIADSn9NFpw_FI19.jjCtRCZz4p6x5.r1J.C5wpaydXPxXWXFuOvPONVHAQffsFmxpe10AhK1A
 LbrF1BMaCk4xt3fD8UUONj4nxbv3LeDTq7p50DWpj2k6wMLwkTzN1HJd7SgiZGr0PrAXWZnVWMn7
 00F.DnXQFzIOoJnvy3KadMV3fKzxAHv5xWtmpEQvNevBGZuiqz58DYsdkBCv.3fv0._EHhRi2qAr
 h0yzh2St5RjT.RB2YL6BqbsOSEgLtaTMT4Rz_1VWw594P8qsOoSQt_kO4h4kZkA48ztBdQtxIS_1
 8f2xcLE2KMJremlciK487DMPjkKtQkJjpPFpO9awHNIaK8BXKFESkF.4f0cPWHuzYS1oa.vm_K0O
 auAQ3EAXzv7RIMDR1BLFVtQt_onF6Kheqk8Ro6jGU8eKD1fVyJv_qwhQAhJjSeYzNIUZ3gZbJClq
 frbwUMoM3jO5xUofD5nKAgOqY5dC7kiZPdPo7dA8ECjdFIdm8n_OcWqomJTHHDezc88I_oJXNOll
 jDzNkT_zipoSdpK7qetJo5OCr1iZhffQdDYHuNvQabLNREZ7JDmHqMuaqu3iyFCGhzUipwZSIASy
 aDYnXHKiTcqRulq7BGL8wGP2aI3QdK4isNZmNhNjiVRxblsd5v9ClkbzAeelekro0pi0PMBNt0V9
 8LrHHmsanKvOEGNA5d7QJtIUBuVH4VJeByakEJaGjHmRWA6fup0HKarFOltTcqVRAzavfL8Opcbk
 OpouYz6VU5eVl8vMh2WHRvHwxp88URfjfqGz_klaq6k0TSzGe2atYGoBW7FbfHbRNyR5rNH9.7UH
 64XmfchyzKQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 19:58:58 +0000
Received: by hermes--production-gq1-94b89944-5szfq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d7dd1ec8d403d56e2a0698f873654bf9;
          Fri, 30 Sep 2022 19:58:53 +0000 (UTC)
From: Mark Millard 
Message-Id: <38721E60-40DD-41F4-9E2E-73D6239ED268@yahoo.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_A59A7C89-AA51-46CB-96C3-C756A893A854"
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 12:58:52 -0700
In-Reply-To: <939C6F7E-4B92-4F72-9AFD-C29C8B59B42A@googlemail.com>
Cc: freebsd-arm ,
 =?utf-8?Q?Klaus_K=C3=BCchemann?= 
To: bob prohaska 
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
 
 <939C6F7E-4B92-4F72-9AFD-C29C8B59B42A@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfLdw2MN7z3NwN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="Lz/Wv0yO";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_CC(0.00)[freebsd.org,googlemail.com]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_A59A7C89-AA51-46CB-96C3-C756A893A854
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 2022-Sep-30, at 12:36, Klaus K=C3=BCchemann =
 wrote:

> =E2=80=A6`found  someone in the WWW who fixed similar issues of an =
even earlier rpi-model=20
> by increasing/adding mdelay values,  no clue if something like that =
would be a valid test worth=E2=80=A6
> Like this :
> * requests in the first microframe, the stick crashes. Wait about
>         * one microframe duration here (1mS for USB 1.x , 125uS for =
USB 2.0).
>         */
> -       mdelay(1);
> +       mdelay(300);
>=20
> /* only support for one config for now */
>        err =3D usb_get_configuration_len(dev, 0);
> +       mdelay(100);
>=20
> usb_set_maxpacket(dev);
> +       mdelay(100);

I've included a patch-common_usb.c update with these lines
adjusted/added (with a suffix comment for each).

Reverting to the official rpi_arm64_fragment could be used
to also test without the debug output.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--Apple-Mail=_A59A7C89-AA51-46CB-96C3-C756A893A854
Content-Disposition: attachment;
	filename=patch-common_usb.c
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="patch-common_usb.c"
Content-Transfer-Encoding: 7bit

--- common/usb.c.orig	2022-04-04 07:31:32.000000000 -0700
+++ common/usb.c	2022-09-30 12:49:31.876729000 -0700
@@ -16,6 +16,8 @@
  * (C) Copyright 2001 Denis Peter, MPL AG Switzerland
  */
 
+#define LOG_DEBUG
+#define DEBUG
 /*
  * How it works:
  *
@@ -1098,10 +1100,11 @@
 	 * requests in the first microframe, the stick crashes. Wait about
 	 * one microframe duration here (1mS for USB 1.x , 125uS for USB 2.0).
 	 */
-	mdelay(1);
+	mdelay(300); //MMJNK: was: 1, comment above not adusted
 
 	/* only support for one config for now */
 	err = usb_get_configuration_len(dev, 0);
+	mdelay(100); //MMJNK: new mdelay
 	if (err >= 0) {
 		tmpbuf = (unsigned char *)malloc_cache_aligned(err);
 		if (!tmpbuf)
@@ -1119,6 +1122,7 @@
 	usb_parse_config(dev, tmpbuf, 0);
 	free(tmpbuf);
 	usb_set_maxpacket(dev);
+	mdelay(100); //MMJNK: new mdelay
 	/*
 	 * we set the default configuration here
 	 * This seems premature. If the driver wants a different configuration

--Apple-Mail=_A59A7C89-AA51-46CB-96C3-C756A893A854--

From nobody Fri Sep 30 20:12:30 2022
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 4MfLxd59wNz4YJjN
	for ; Fri, 30 Sep 2022 20:12:37 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533])
	(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 4MfLxd0RP2z3QD0
	for ; Fri, 30 Sep 2022 20:12:37 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x533.google.com with SMTP id c30so7379880edn.2
        for ; Fri, 30 Sep 2022 13:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=9RUF6Mhj3V4e+k5lbNPkW/qV0z4tLq81ZTrfhqmLuBg=;
        b=pjGL8VHgkDnyLxufAdYCVnpRqsmiE8JtzRYpmV3Bi1wcAinlwHXJjEz8VJf4NlqM1J
         caRfX5XFAbsAeL84c1qYVWo9Ffi4hHdiof9ltrCHCGoyhbk0yEfrarv/1oUgMkgsYb8P
         t+Wea0qAIO19wOtCB5T7sRmZsztP53l3TPFKY3Oq4zVT9me9XjWxkDW1zpqQ4Lw/uoDy
         fbgTxh932Qxie6Tys5gP44qF83C5rgF4szvyS2FkoG7LCcsyYbYGRpGZJd0uX8d3+ou6
         xH6k2HcDBsjuvO2C4IFNiDxdGOkx0TOEMtdRvh8bygiRmIoD+0SIP0lLdUtLtxjPBGID
         04VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=9RUF6Mhj3V4e+k5lbNPkW/qV0z4tLq81ZTrfhqmLuBg=;
        b=1K9B7H/sc67mDxKh806KSb/l6E5GnW95gydtdbId+vKPdPjAjPLeZc5WxfynSsWApJ
         gF8/eAvaFuLaJtPSTmw9wni2a3Pxc1YDg96mzzfaqnNDy4q6HCeBXgMv55iEpB7HxKoS
         ulkYP4nm/5lgVos0+S170754XLVwlYBAD78+J5pcKybQ3nTcvUjlSNyEQtFfXbqD/pV/
         pv09oXONseVIRyilIEMVfPb1wmMzcEmsYzroapxRZhdVtSAd3XWrgjy4pzx+NXTr8t2y
         uR1lX+17mlUHUk4KSMcd0OGQPBBN9xHJhOOo16xe3yOiDmLQTtvfV210J/jeObHtHRCg
         TYhQ==
X-Gm-Message-State: ACrzQf3flAQ7C0d7i4f/UbLl3gTVstz0tYby9pDGZ2Ul+2aUec8xy45B
	fHfuNHd3ohpnODCRGDzr77g=
X-Google-Smtp-Source: AMsMyM7jBrbj0CLi/OocgAWeLggcLd2lxr8xQCMOiyFPUTD0aIL+tlYIkR9BvrQqyjn91fhMDODP6A==
X-Received: by 2002:a05:6402:1009:b0:456:f370:5263 with SMTP id c9-20020a056402100900b00456f3705263mr8988610edu.392.1664568755940;
        Fri, 30 Sep 2022 13:12:35 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id kx2-20020a170907774200b00781b589a1afsm1615218ejc.159.2022.09.30.13.12.31
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 13:12:35 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Fri, 30 Sep 2022 22:12:30 +0200
References: 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20220929054120.GA77803@www.zefox.net>
 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 
 <5F180C78-BC07-4605-A042-0BEC8A6FD185@googlemail.com>
 <8CE490A2-B512-4170-95BC-D0584F2B254A@yahoo.com>
 
 <939C6F7E-4B92-4F72-9AFD-C29C8B59B42A@googlemail.com>
 <38721E60-40DD-41F4-9E2E-73D6239ED268@yahoo.com>
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: <38721E60-40DD-41F4-9E2E-73D6239ED268@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfLxd0RP2z3QD0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=pjGL8VHg;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 21:58 schrieb Mark Millard :
>=20
> On 2022-Sep-30, at 12:36, Klaus K=C3=BCchemann =
 wrote:
>=20
>> =E2=80=A6`found  someone in the WWW who fixed similar issues of an =
even earlier rpi-model=20
>> by increasing/adding mdelay values,  no clue if something like that =
would be a valid test worth=E2=80=A6
>> Like this :
>> * requests in the first microframe, the stick crashes. Wait about
>>        * one microframe duration here (1mS for USB 1.x , 125uS for =
USB 2.0).
>>        */
>> -       mdelay(1);
>> +       mdelay(300);
>>=20
>> /* only support for one config for now */
>>       err =3D usb_get_configuration_len(dev, 0);
>> +       mdelay(100);
>>=20
>> usb_set_maxpacket(dev);
>> +       mdelay(100);
>=20
> I've included a patch-common_usb.c update with these lines
> adjusted/added (with a suffix comment for each).
>=20
> Reverting to the official rpi_arm64_fragment could be used
> to also test without the debug output.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> 

if you created this patch after my post, you are extremely fast ;-)=20
In Germany we say:
=E2=80=9EI press both  thumbs for a success for Bob =E2=80=9E :-)
If fails again , what to do? :-) ..puhhh=E2=80=A6sweat pearls..

Regards

Klaus







From nobody Fri Sep 30 21:35:29 2022
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 4MfNnR6XLTz4cx6C
	for ; Fri, 30 Sep 2022 21:35:39 +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 4MfNnQ43Z6z3fDP
	for ; Fri, 30 Sep 2022 21:35:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664573736; bh=NAhoEO0z3p5VlRS5EImrxiLwEc7WLFEBjqN2PrBEijw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RFZLxElXX6RhxueZ51dRK1rnswymQGsc5nphpLa+NeORyUf4PS8xREkXzFOrmQGPTXDEm3CbxGvQgfzpUt+LEAN005Pm8/Nv0poh+97yIRjtBygyH6txV1G6eNES+TpQBLV2KptYQTg9iECi60OdYzJbyWDNa9E0//TADGlBoe7BlIgvxekDolyM/T0hA5yyfsyTU0CceMt9wePxH+UZOHBP0fZHJD+7k0pORSE9KJz4Cps8qlSNLkS/ce0aDpgsY+bqMR3YiLYYz7JRZigNv2S3b/8H9ayBjxdudsEH0AGhmN6NmeQKwoQnpOQxr4BmzIitoNVhYWwiP0nb6uAfzQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664573736; bh=UW7OhpqPT5LVd7cuQfrRZ7hx9bC8ymQgg/RRfy8SIu4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ohl8Ck37PzFBSbiVACF6EQfyhcde0ZJKa0gMJuONEFffWF55osaK3+MdL/oUeG+B9RlVhIXDra2ig2qanR9XnU0H1bhMJyF8BSc/RMlKU+t4/nOdasfPL+KHKNGCMzcG/OFh6Xm0YbD1VGdrmUAEeotMzmE7J9j8NimzyLKD9EOKkZuWQY8F4w7YYngjXNeRMw6GaILYPV5LbDK9EQ3S3a4CyZA8x5wasNPP7Y+77fMhVtcr60Ib/69PIv3kIVWchtjyqL6HjIgwludCWx0kIB+a5ZGyO4j6aB7gd56NzU1SaslHQ+ydQMngO5uUdpDFPxp3yMWTCoQrSA8jE/MpFA==
X-YMail-OSG: qZ3bwgYVM1mSItRRSGcPl9lG_4IV2Hf0URcUKEDHNIQ7tuRuyUBZa7FyMGvZOSA
 3mo8scQ2FPhMN8YJBg8NSzmdz1b49a5cRYxFMacOXLN0.waxrTzsr260lYgsoqvJ0qkeKkWrLKVQ
 rfZgq_8hJQ4YLG9lY2U3_PDppkovfW_C92lL.h9sfeOXenPHsOjJAfqwd7MorsBuIO_gVIF0.jCy
 AEYnMWXhUsXn4nHJIDoq4EDnHKW1Yjwk2glSe.w9.6fR7kDcwlSjYFKE0x3SD_NmYEIYw2ilAcQn
 MWmyZjoSqPVQgYksMmrWRAeYX6tm5gylbAalIPnw.1bdPkcqYxFmCjwJal_A_tZmZ.eiJSFrx59K
 cgz.OVuEcuY8JKuXqAqPOwOF2uXoTGhkhw0w_Smy6aMpY9WoxhdRGFtjs8iqp.ZhhiniNDoBD8OO
 W0kPFqNzPFhq4gqBrjOk8MfTy2S_pRxYFY4Ns9_ytcAp2mbcwbnKGBlbgPuvsQL3uRKi1ekTvwRk
 Q6Rzg7KTtuH0LdEc4vXgOIwkWKObfb1amdpTwZK40Qq220SLEKj.sDHkmbMbc7pFajc04x1YQ5yr
 23bU9gSF3BDVWb8.1yTdcBgz1.65BjHLBNJC7Q60UGTtx03q6cNFEYpSOCGeybUnoM1W2PRGaNwe
 I1Hg_fqi5OPJZfa7EXAOO5pnYmP8WGaNNdrd8VtpMRunx_S_C_W58Q__UWdn3WEEetqZ2cPT4buh
 xPCf6le5ThsKvle2OrFQttxNmGKJhEcE3kfERX6j9vHy91500_868n3vp7JEMi4zWweQb3zup6Wd
 HvU5RNe3T4nkOVmbIL7aoCumi5o1ip1iOTlTAM_iZmpCmGuWu1aEiBseAHSvZuG.Ch0kxcl71DKA
 SaxizoZRx7j8nly5XOdDYDqwqol5oYpXgsBAjT7kpijdZ_JWinNvWuY5u.fHaDQuZPvwlFRgP6sx
 oVRjJaDoUhQugAxHG4nAAnY2q.ClAzrstOtlEr_3nUXLSBjQZSF68FH44kmsR5fIrNKloE4ai9sp
 MRjYIs.dyQCLuXa9g5fObfw9J9aAg2YDmFGWVlkBh0iswFndvx7.GgGkEWMsR2lU5afmNM3KlQrS
 v37xY9N79hccjNvuF5O9zpRvTdGlxesJBHehDWs0CSMuLf_n1XQRrGcHa0V.1z.oSb8yfcPPs2Ic
 OSkMG72GRMo_8kfOcy7YktxF99Zpewyg_gIpgbcHkHSxCEPDVAF_QvDD4gQhl9xZbUICypg1rgof
 a44UAhNi31PxNJX7tt5KOBxY0qd2FiQ5e6.z2eH7cRhJr4sn7T3a0Ddxq2NwXtILMEI3JL5i9yQJ
 HPYZkXFdv.JOscUHyhGlGjIBV_5_1ckoUMxfF34Z2AtPHMicbvMiBl01KWMLw41d4vjBanj0ZF5J
 Iyj9ydlVSkGlW6cWPyZDpgW6fWrMQRFkSge24fOKijHuzqXNY4CFzhx9f8g5Bq.V3NeSBnL8skT1
 cwgRKkCcKBO.FkF_MUCGSi5MsfrtTZiNn3IYzIvUseMK86l9jm8Q2DR8jAOr6al.ItcZsb0FeMtG
 krzq9nvLeZ4thjs0eGjE4id1C4YU7k30it9_vtZ5TCzXpNA2QaTnw7KUEXf.vlQXn3fCmZEeARyJ
 APqBf8jf4AASqPUWhJz8s1Nw7q9EJOhdUcbCiTvm75U_Zi4pwMWoL6lozNAYD1it_.3EpYmGEUfj
 36kDjZWdp9J8Q3NxsGX4DuKb.38yJ4KqbCFVJPCAmF6adxhaVN8c_QR4p4O8__yhCTGYJ5wnDM74
 L_4dAboLYUe44_Bvt_kh3UDdRc_dKTtx6MXoFsMQjPz8W1BsOxMXbS6FhPrag1rTF7HSrvqvGEZ0
 8l71ICWM02zo.Eptp115X8R0Hh0mcKBSmy.yfsBCFVQGKBUv8lIay4WEpVPBoLWSnqkLs9zmuhkF
 o_sy9_WwZp.aD.sQvSdcDYoDBpD56dXgoS2IWVRCh0QA9mH9UdnAYwYfBwB_1Rd9iQGZC5BeyjFC
 wS8REAWDC5Pp3xFPMJYNOBP3T3n5TD2yX7._VA3OgcFQnt7dPrHmKtC3Ccce65WgOUA7SV91YUh8
 HKePBhMbF0Ujz7A9MK82XorV.HXmRPT_VhYM6xl5LKT0oZBpG5hZD9dnP0P7zHNqTdKMavartXWB
 fBZb.3bMuUaOaaBrYoZune4u65nCyTVjbQMdLL7IQ7eiVVT.UtyBaFjJAyEH_s.qy4IzglA_Pk2V
 rzoy6XwApcK5331ZS6qZPxfpxN8w1LpM0NtmPW1UhEJtU6BrNHThCsqosNUmy2_xQFgilH6g_RwO
 kpKys8Hzt
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Sep 2022 21:35:36 +0000
Received: by hermes--production-ne1-6944b4579f-wdnx4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3491391e26980908b6a7927f6315c531;
          Fri, 30 Sep 2022 21:35:31 +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 \(3696.120.41.1.1\))
Subject: Re: U-boot on RPI3, sees disk but won't boot it [devnum/port paths
 vs. U-Boot address numbering]
From: Mark Millard 
In-Reply-To: <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com>
Date: Fri, 30 Sep 2022 14:35:29 -0700
Cc: bob prohaska ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <06FAA67B-D2A2-4899-8341-A019DE7F5EBC@yahoo.com>
References: <20220919221553.GA33878@www.zefox.net>
 <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com>
 <20220921154240.GA37735@www.zefox.net>
 <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com>
 <20220921175026.GA45144@www.zefox.net>
 <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com>
 <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com>
 <20220922014500.GA46697@www.zefox.net>
 <280D9065-A158-4E52-AA18-CA2CB1C247AC@yahoo.com>
 
 <0A773F91-BC73-49BA-BB7E-65EC00B954DB@yahoo.com>
To: Hans Petter Selasky 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfNnQ43Z6z3fDP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RFZLxElX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.46 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.959];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-23, at 18:34, Mark Millard  wrote:

> On 2022-Sep-23, at 16:52, Hans Petter Selasky  wrote:
>=20
>> On 9/23/22 04:11, Mark Millard wrote:
>>> As I understand it USB* standards do not define a stable
>>> order for devices to enumerate. So even if all the boots
>>> worked, if you had a record of the "USB device tree" for
>>> each you would likely find that the trees varied in what
>>> the numbering (and, so ordering) was.
>>=20
>> FYI
>>=20
>> LibUSB defines :
>>=20
>>    int libusb_get_port_numbers(libusb_device *dev, uint8_t *buf, =
uint8_t
>>    bufsize) Stores, in the buffer buf of size bufsize, the list of =
all port
>>    numbers from root for the device dev.
>>=20
>> Which gives you are more or less constant path.
>=20
> You may not want to spend the effort educate me, as I've no
> detailed knowledge in the area to relay on. Also, I've no
> clue if U-Boot uses the routine (or related ones).
>=20
> The original context here was a RPi3B, so USB2 ports on the
> RPi3B itself, not USB3+ (in case it matters). Ignoring that
> for the below . . .
>=20
> Looking up the routine at:
>=20
> https://libusb.sourceforge.io/api-1.0/group__libusb__dev.html#details
>=20
> I see the description:
>=20
> Get the list of all port numbers from root for the specified device.
>=20
> where:
>=20
> Parameters are:
> dev			a device=20
> port_numbers		the array that should contain the port numbers=20=

> port_numbers_len	the maximum length of the array. As per the USB =
3.0 specs,
> 			the current maximum limit for the depth is 7.=20
>=20
> Returns is:
> the number of elements filled
> LIBUSB_ERROR_OVERFLOW if the array is too small
>=20
> But the original device trees reported showed:
> (unsure how well the text and its whitespace
> will go through in the trees)
>=20
> USB device tree:
> 1  Hub (480 Mb/s, 0mA)
> |   U-Boot Root Hub=20
> |
> +-2  Hub (480 Mb/s, 2mA)
>   |
>   +-3  Vendor specific (12 Mb/s, 90mA)
>   |    FTDI FT232R USB UART AM00KE3E
>   | =20
>   +-4  Vendor specific (480 Mb/s, 2mA)
>   | =20
>   +-5  Hub (480 Mb/s, 100mA)
>     |  GenesysLogic USB2.1 Hub=20
>     |
>     +-6  Mass Storage (480 Mb/s, 500mA)
>          JMicron =20
>=20
> and:
>=20
> USB device tree:
> 1  Hub (480 Mb/s, 0mA)
> |   U-Boot Root Hub=20
> |
> +-2  Hub (480 Mb/s, 2mA)
>   |
>   +-3  Hub (480 Mb/s, 100mA)
>   | |  GenesysLogic USB2.1 Hub=20
>   | |
>   | +-6  Mass Storage (480 Mb/s, 500mA)
>   |      JMicron SABRENT 000000000000A
>   |   =20
>   +-4  Vendor specific (12 Mb/s, 90mA)
>   |    FTDI FT232R USB UART AM00KE3E
>   | =20
>   +-5  Vendor specific (480 Mb/s, 2mA)
>=20
> without rearranging any connections, if I understand
> right.
>=20
> Both "USB device tree"s have:
>=20
> 1's device (a hub) contains 2 directly.
> 2's device contains 3, 4, and 5 directly.
>=20
> But the correspondence with the devices
> associated with 3, 4, 5 is not the same.
>=20
> I do not see anything in the libusb_get_port_numbers
> material that would imply they should be the same.
> Any permutation for the correspondence of the 3
> devices relative to the numbers 3, 4, and 5 appears
> to be valid, even if it varies from power up to
> power up (for example). Just the set of numbers in
> the array {3,4,5} is observed to be invariant as I
> understand.
>=20
> May be something in the USB 3.0(?) specifications
> nails down such relationships. But if it does, then
> "2" is not behaving correctly if the numbers 3,4,5 are
> port numbers.
>=20
> Another possibility is that the numbering in the two
> "USB device tree"s is not technically the port numbers
> but some other form of id-number, possibly U-Boot
> invented even.

I see from the debug output from the investigation
going on that that last is the case. Something
like:

devnum=3D2 port=3D4: USB dev found

ends up with something like a:

set address 3

and the "usb tree" is showing these assigned addresses.
The order of the devnum/port events varies and the
set address numbers increase as they happen, providing
a flat indexing instead of nested. But addresses need
not be stable from power-up to power-up, for example.
devnum/port paths are stable from what I can tell.

It does not appear that normal U-Boot usb commands
generally indicate the devnum/port nested path
numbering. Instead showing the flat addresses that have
been dynamically assigned.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Sep 30 21:42:34 2022
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 4MfNxP4fgKz4cxnl;
	Fri, 30 Sep 2022 21:42:33 +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 4MfNxN3QdZz3g0D;
	Fri, 30 Sep 2022 21:42:32 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 28ULgZXr087220
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 30 Sep 2022 14:42:35 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 28ULgYpB087219;
	Fri, 30 Sep 2022 14:42:34 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 30 Sep 2022 14:42:34 -0700
From: bob prohaska 
To: Klaus K??chemann 
Cc: Mark Millard , freebsd-arm@freebsd.org,
        Hans Petter Selasky , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20220930214234.GA86711@www.zefox.net>
References: 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.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: <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
X-Rspamd-Queue-Id: 4MfNxN3QdZz3g0D
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FREEMAIL_TO(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_FIVE(0.00)[5];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,selasky.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Sep 30, 2022 at 07:07:08PM +0200, Klaus K??chemann wrote:
> 
> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will help,
> But if Bob got improvements by setting your values , 
> I would consider continuing to manipulate that values.
> 
IIRC I tried every usb_pgood_delay from 0 to around 15 or 20 thousand.
Nothing made a consistent difference, with the key being consistent.


> Regards 
> 
> Klaus
> 
> 

From nobody Fri Sep 30 22:22:46 2022
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 4MfPqx0QNWz4d2HB
	for ; Fri, 30 Sep 2022 22:22:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536])
	(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 4MfPqw1Rk8z3jZb
	for ; Fri, 30 Sep 2022 22:22:52 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x536.google.com with SMTP id e18so7706833edj.3
        for ; Fri, 30 Sep 2022 15:22:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=+RkhKE9wUjk+2tOE3R4QCjCWK9OqSlzezijQVVpmn9I=;
        b=kXtQ0PfT/71fAKD8v48Wx/mmSdjkzrUH75R/A7kGr1MKbvb20I6bAVmBeSPepV7zHL
         tOj/bhN3v38vOhle5p/8p1Q1djwpAoQ7Ygdo7CYHZfo48Irig01ZJuoRPpP78lD2ldU9
         Qh4qeVBlhTugXy3DEZTugDkHOVs0/OnF5aU5Of/ppzu+tvIqOgnUmoC94WYS8bdpdzQC
         zlEITvznmeHXoJQWGiBCP8eyn2rHcrSrYc5pke9QMmQ+GoIbU95Dm+XwmlRS3hFd+I8Y
         lYCAh7QuGcDZMF/EDfPIvGVfvnU2vov/Ndfjh2+jy32Zdu4o56BFxEntzCYTy+e7owLQ
         0Gdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=+RkhKE9wUjk+2tOE3R4QCjCWK9OqSlzezijQVVpmn9I=;
        b=Ji7rRHT7usUMWclfaFm0+KWhmujjlSg4KCEqyLUAhTGfyo9inFz35Y69AOZ+43GSAp
         pSrWclaalyJVGH6ZcZUb7b76LquBJzSH62Z27ZJS7XqBCRdgudzYV8pVEdT7/a0DG8UI
         N9hmrpqWi7tSdlknksTVppxCl+o3zcjp4q+Ij++8RArDiyaC+t0aa00Ff16/ugsa0HZZ
         usaifEMLPvx6AURINU44Yt62JljkutKHMTdIuPto0mgs/QXRCfQcxJljlUbmbMq4dq3p
         92feSRsfK6Qb1cH7DPrCBlkz8PAx0PodXwFIvvgMY6RbzdPoBkk/BPoG+ORDP3F/PvNC
         4gdw==
X-Gm-Message-State: ACrzQf0UnsK3rmhHyzpZAu6/AvVmcgM7N/URmpumLMilF7suF3dcbZ9M
	SLMbBN7fm6JHz8y8X2EH5ho=
X-Google-Smtp-Source: AMsMyM5MyIFprHCm5O2SFAM7zhRLzbMFc0aISkeB2lgHOI6HT4E1nscVBZJoiVl0qRuRTNcm/GRr1g==
X-Received: by 2002:a05:6402:400e:b0:458:29c3:ba34 with SMTP id d14-20020a056402400e00b0045829c3ba34mr8647942eda.294.1664576569344;
        Fri, 30 Sep 2022 15:22:49 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-204.46.114.pool.telefonica.de. [46.114.61.204])
        by smtp.googlemail.com with ESMTPSA id j14-20020a170906094e00b007417041fb2bsm1746920ejd.116.2022.09.30.15.22.48
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 30 Sep 2022 15:22:48 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sat, 1 Oct 2022 00:22:46 +0200
References: 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20220930214234.GA86711@www.zefox.net>
Message-Id: <6564FDD5-1F32-4398-9547-65D0ABA900B7@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfPqw1Rk8z3jZb
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=kXtQ0PfT;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 30.09.2022 um 23:42 schrieb bob prohaska :
>=20
> On Fri, Sep 30, 2022 at 07:07:08PM +0200, Klaus K??chemann wrote:
>>=20
>> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will =
help,
>> But if Bob got improvements by setting your values ,=20
>> I would consider continuing to manipulate that values.
>>=20
> IIRC I tried every usb_pgood_delay from 0 to around 15 or 20 thousand.
> Nothing made a consistent difference, with the key being consistent.
>=20
>=20
>> Regards=20
>>=20
>> Klaus
>>=20
>>=20

thanks for info,
`curious if the mdelay-patch will change anything,=20
If not it won=E2=80=99t be easy to fix it by more reset attempts..
I do not own a 3b (only 3b+) for tests...

Regards

Klaus




From nobody Sat Oct  1 00:51:03 2022
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 4MfT7130nVz4dm7l
	for ; Sat,  1 Oct 2022 00:51:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4MfT6z73qHz3v1D
	for ; Sat,  1 Oct 2022 00:51:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664585465; bh=612/1CoDoogsaMUlJkto5Y7aYqpZwJ2Sas9YdX9lu04=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=U432n7FnwcR5ZpFeiRJw5ZWBhjGcxd/LYd7ObsCa+lduXtnc4kFyVRsnGEZ+j9wbNUknmdmcdzsVR8/K1QLnFr6XFYNJHK0l+pzUUPLtS6gsGQDkVSFFYkjYvO/6/B0qTbvuNZxInfZNaryaHV7o4H7NFmJr+ScA0/axOwnYWRAw1NFrkoKDytQh6qh+xNCa9oHimt5xeriMm+Wx+QPqQlgR7GqmmNCKz69xWWn25jY/RyffCC1hzEJ0aVQ6W4Ucy7ivb2rnfY8vc9VOh8u6MpbbzZ20Wlcsa5TN7t3ul4z5Mk/mTH3jjV25uIWC+eIU6tFs3Lehu82hyK681f5O1A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664585465; bh=QiJtgweIlVxDvZi/cGw8A6jHEeCR/u6bRbsbAEm9I7f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VTsiyxlVuO+WVlPlpLw494KSJthFH0F80at7qgVTOMPAAOVSu6DHsQL9T2edjUhX6vJCetFo/rngguMK+WuAPzO6TqqIHqdJYrUxA73aKXJALwcZKsIWPgPAfDfAMH2LuIXa7OMF5611/zURoj3QTlQ2PjRNlrsa24Z/4A/2raTK/AJ7QPce0ocgmX50IUlObE8+4ZnsUEUcjTUS9+HuXsvxrFixWfayQSnVj1tFf/o2RqUw0TPA6he+C5WjMpllwMULa3hsoieqkhVv/veKN2LPwv360Q4Yp5d8pGRrfzJEPYyc3NBtBhKUNdIjRd8U11v0SLJ2WKNuGyGxsqVTzA==
X-YMail-OSG: _J_4TRMVM1mUS1cMvwEq0lGs1OU6cVq6vw92oA131C2Xz_BHIJJSwYCQrR8HjZk
 ..uM.IOT5X7JiH8OQho0aRVBcBeQdEmwn3v7WvjccDHa8KXSnapQvyHvrsQx9rGHJabRa6pn.4jR
 rFq93UUf43UsdUR6FpTQpvZBumc_I9faJHIrWc6gIkkOG0MH_HaU.LcR2lW4w0b15zeN1nQtMNGZ
 DGpkilHgcmGhjDRNXxpgJ5N.iSkizVQyynC.wTERqEpBjUM9Ejv45py3yr_ugwlmWazMjnuTa69h
 p.razPNvMXnOcSg2pS8EkD8n64y2Zvb5_I_i13vs.HjvNi9ywKgYPk_NTX0.j0dIjW4g5TmjIVWN
 Ff_6NiDbuo_xtG31SSIz_vTddTAyH_0spiT7zIo7GbPWpsn6J.a5x3MEWqfJvK6ggPjXnam4A_88
 MWWgLNQxjktO5mQJL6_Sd.UgybtmDhiPTRa.U1GugE7hxI9BxZUjFR5KbeNFV2A3EFckVfQbJZmN
 whdi.2wDUyDIV501fUqQIWaW3hXn389B45DEPLSifq7N.tMEDUUpjRbi0zVi4pZOjbpYDiXsdeiH
 82UDz19kZNgCq65tt3Pva9WWxDAbzvI_Cy7N_d4fXv.8zebVnhc6d5re9Yv.wD8ksiAY8NdeAiRO
 xnqqhP3JdstpcZ6xw7I.ejzOjJukhGfPorQyYQQA0WFDIiE40HMonZ2Obkv0pBZo_pP5wXAncqgA
 rQIR7UvXCRVcb_ggpQ5sbGgx_6xwQjXkDeJY.6Yr3ElM8xwMPCvBUVNlezdN5XdQrV2_djB0QNQq
 WfRQCNA7xWlJGrhrYIqPafVhsVv4PBBi3V6OFOhFjELLYqnQcwVavenQjAdwp6UEkaYOORVFmF45
 BygemyUMzayhkfkvj4A.doKRF6NJhT9B1cA5gB0wwN_8SbYlHbIQ_zIB7DGKoI7sAM3MxcrY8E7N
 mE21EmObwhZF.CW98xYuR81uwbGzRk6XpMUBct8UJoEN0v8uM6yV4XacuvNDHMht6h6._nhq5d.8
 0CJVEjPwFWCP1Wj0HV9ABoEzSn3JuMQMONXldnySbXlxjpLEF4WoOuzL8BpNOp59ZjJ2M.HmdxGU
 tz5Ps2KfrC6AtRsIPKMML57mZM_46KiTeLjMl3gHs_hDnwcMp0ssHeHhcF.MElSBrzKVYZA7KjeR
 xcUg.jp_Gs0tw3RCzzJzqHX6Wi.NVNdkkhy5XZlHd69YWZ.8lr4xALge73eR5JMLpf4ZmrvNv43I
 bAWGwk7G9f6EUWcyW5oCqj3e.HJQtwdjhRJOKU.dwPWg8frVHOAtiBYY.18WRW_Fh2PHDlpiDviV
 vVRteavlTU8z07s0CEHipSUuF2za2NkSkg3U23yw9AvGH3FozI4P6H2nUbWabZe7dZHU.bruNqzu
 VLZQT4wpT9dyCxoxzqgYCl.1mZAJs0Puct0v8SK16bwS694UgeyuNMDw6MWeq6trSK7bD8w9MtGL
 x_WsP7vCcSAfSKGn6yt7rM6DM0co0CbK7eR8KPL_x0NXXt0uh848w4uE9beF.UEDa6rTLhVhth7H
 OxawuVODVa0VWZiFuAt4JAKo6yVH3SwTDrI7YFXbdyU.dtQBBP2itynIbyVWLmRwg5QBamWfljlQ
 3ouCqa77UXE3k5lrjwfniLLvoFv1gwcGnQ1eOwxRkGElvXA.TwWwSWjL7Z.xUc8OmhGxAwRdO3SB
 89BJNsiAgWsF.vOWfCIhvQ1iTbXJiZ2R_yMv96QOZr1Cqx3gD0UHyc_8ovZ0yFQ1BeMXgWB6JBIM
 g0ynE7U4XJ_S9FI80.j8LcdFy7GEYw3VoczvKzRQEzIQ4A92Yo.MLKjZmhfOyOOhznw0outgUR8b
 qgpyem3DXjDw.sUJX7mya1FopUWPB_Sw4nvlP062_nGnZGFw1YhcHSpVf3.k6utiverwzh3z8EZc
 NdsJThnk1xMRzuFIdjaLSnMWYcXtnTQXlVKtSe5Dydg5GDS6Bk9pVyaR4CFZlc_e_Bj2XswyGA9a
 KSOO0MqpPk6r75b8n08bzUY3NqTElhH1NfJiATeKLp6kFuWMWS4bEPKj60dzknP8qz1qfplClFNq
 O_NLCS6anMuLQqkMs3FVYy2vGbc1IazPg4L0JYwCKs.obZSO3xT3bh7tV3yzkqNehqY4kMyABjWx
 kJCcYqF0BydPiYabSa2kMp6m45TYLnhc5g.t5TqzTnBdHs0DzOKP8Nka2gwTA6cNe89kPi1D0BEh
 Mw9r3n0ZcSYhRWPwCvRvutnTxb4MvuO3qflbeqc0SausasV4eX_.mVlXUM_Y1lyldTqVkDs4wBWs
 szs8TcQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 00:51:05 +0000
Received: by hermes--production-gq1-94b89944-j9vs8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 74b0c807b36d4e75fd0f718d1927f7a7;
          Sat, 01 Oct 2022 00:51:04 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20220930214234.GA86711@www.zefox.net>
Date: Fri, 30 Sep 2022 17:51:03 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfT6z73qHz3v1D
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=U432n7Fn;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-30, at 14:42, bob prohaska  wrote:

> On Fri, Sep 30, 2022 at 07:07:08PM +0200, Klaus K??chemann wrote:
>> 
>> Ah, O.K., no clue if giving e.g. 3000 instead of 2000 or so will help,
>> But if Bob got improvements by setting your values , 
>> I would consider continuing to manipulate that values.
>> 
> IIRC I tried every usb_pgood_delay from 0 to around 15 or 20 thousand.
> Nothing made a consistent difference, with the key being consistent.

By the way, it looks like having the line:

CONFIG_CMD_LOG=y

in files/rpi_arm64_fragment would try to build the
log command into U-Boot.

===
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 14:06:59 2022
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 4MfpnM657Zz4V171
	for ; Sat,  1 Oct 2022 14:07:03 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4MfpnM1FCNz3lBk
	for ; Sat,  1 Oct 2022 14:07:03 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62c.google.com with SMTP id nb11so14288019ejc.5
        for ; Sat, 01 Oct 2022 07:07:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=oXMg0fDrVzj5tKDCAIp9nPz0d3A2Atq+E4sUr6JDM28=;
        b=SXXILTjrpcDCpqKX9GCzseS2fCMH1qyh5G+oL/+vrIPEdzbphlZzHxYqUGqYygCzea
         OCeoPEe0JodqHYBVprsQIY9L5LGdZESfY77htzJplM0kew7X6OduJNMHqYmyVNLPmKaw
         5z9jb1xxfof/z4xgU3iug3lFju7o2Pyn1G/zjTgcpGqxxLji1fYsIOpQl4akUbPOdkpA
         sbcsCGoPbrZg6HitfVL5E6i0M/Po2E/yBnpIYPaIoNQJ5k06VUVKWdS8FjBGh/4H3vaw
         vedWmJ0PbrFfo1OHw8mR+qBvP7PCtXJraQ7oRriN/8vz9FDeOTi2m48Mz32XQRwTEZ/Y
         BYgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=oXMg0fDrVzj5tKDCAIp9nPz0d3A2Atq+E4sUr6JDM28=;
        b=y5VBpWWyEyajnt/LSBctSBqBJtCr5WxshQ/PNbPhzmU+/XgP79nYLdYD2KSG0Egvgt
         iYhzdTa8rZaI3R9S66mh1mQDnqgq4gzdDrFmPZ08z8We8Lb+Wjhf/J4aZd93hqrCpqsC
         b+ByvSTtsDE3iDZuTbQbPL5HWOnV+jAlzfYl6SJJxzqBT2MgALW5gZDlgfImsz1U2nyP
         C3jehnvLA+dFCtiqpQfPonpeuT/b5H86Y0lWv0IPVyf1huEPdrD4fuFus2TZso4abuzt
         OM97OECHtuZKGrn9rTwo4bHvYtbq2W2udf89L7IM+Sf3WUJG+oIVeEygvfoVhVsVH2P8
         AEQA==
X-Gm-Message-State: ACrzQf36GV3AEliI0GCH3Q6T2vrfeoZilcfAmC7JymCgdLZ9p1F3pJV1
	Q7tUvhwf9d27dqVM3OigM2U=
X-Google-Smtp-Source: AMsMyM7el/A4MTJmosTaoQ0rItlZq06iCZKo/NYuf7UP2WqyWHh+skIG6UIVcpq8a/yd+lPc5+1iHA==
X-Received: by 2002:a17:907:7b9a:b0:782:3dbf:1eef with SMTP id ne26-20020a1709077b9a00b007823dbf1eefmr10198831ejc.123.1664633221876;
        Sat, 01 Oct 2022 07:07:01 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-186-130.46.114.pool.telefonica.de. [46.114.186.130])
        by smtp.googlemail.com with ESMTPSA id g2-20020a17090604c200b0073d7bef38e3sm2752312eja.45.2022.10.01.07.07.00
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 01 Oct 2022 07:07:01 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sat, 1 Oct 2022 16:06:59 +0200
References: 
 
 <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfpnM1FCNz3lBk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=SXXILTjr;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Well, I think the u-boot mailing lists are made for=20
internal patch contributors. But it could be worth a try to subscribe to =
the list
and mark a message  as a bug report.
I would include  a short debug-log-snippet and ask if changing delays or =
adding a hub_reset function
could help out and then wait for answer.
I will not do that because I don=E2=80=99t own a an RPI 3B for testing.
https://lists.denx.de/listinfo/u-boot

Regards

Klaus


From nobody Sat Oct  1 15:13:27 2022
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 4MfrG84gqrz4V7dt
	for ; Sat,  1 Oct 2022 15:13:36 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536])
	(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 4MfrG75Bs2z3qNW
	for ; Sat,  1 Oct 2022 15:13:35 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x536.google.com with SMTP id a41so9402353edf.4
        for ; Sat, 01 Oct 2022 08:13:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=PIB/SW4zq9HqoWmcYFlqzvu7yz9LqAQj3xFqdTPbpc8=;
        b=bfo2f2wukXREydmL43+afEbkjnChLkY0UlPhyWRephn0rBNAFX72sT1eHLdUZ1icex
         +GJ7DBdH+U815n/8heKKNDEonq7Y1o9ax6wZJ8dLom3WQx3MAm1stpjhAcQdzgFsTsBB
         Mjmg/sEYeaCoEveU9m+L6Ja2RkGbRpd4dpzntfdcpQsAy5KNBSJEfBA8oKEasG/dk3vN
         RuLXhO//T4fj3IqJ9XehOPbs0SUb9E8Eh5YhEjHZr+gY868vQP/48UKV9sLa2Q9pRHsW
         OFGWBcQOWk6uBgrd5yhQZnpodXIVIuHwHkLaTYFxm1x5KP5ZI0pFcurUlpifJqzV/C8B
         C60Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=PIB/SW4zq9HqoWmcYFlqzvu7yz9LqAQj3xFqdTPbpc8=;
        b=DOCZt57yjqD8EnyOPJzW7ZnJJ9z5yiFcvfTR76cXb5p9fcpYDRBJrTZz1ibhibmTSr
         2nMEnh+62KVhoZzPsrpeXfIiVCvTr452w4k3prh/E0oV0LPVzcPgSCAPfv1QKF7ArOjL
         DO4iR0/+1HbeSC9U8MvLE1UYGcsPgJpGFjc8e/1Ah1bqTUP1qyYzOv0T7QhXxCNHS/tZ
         74mgE455JKirACpjPaWG7nlY7RHFLfSs3C/py9vyjaYxDeDs4iL8fJ7Z4Tyvn+N49FmB
         rjF0Twy6y1YhnkBRQ0HhAg+FRsSIf+FBiywx4++qEt7J08c7Jx11h1NSyR89j4wBhdQu
         wabQ==
X-Gm-Message-State: ACrzQf3X6EWg8PgvMus0aPHr4qwLVTgltkoem18EoVVejAml0AP8Aeq8
	MeQd70wql31AQIV9d58BHCY=
X-Google-Smtp-Source: AMsMyM7IZ7KZhzzIgxkW/IsYq3vQiRwa7rxXuHj4TrCTTexNcWfn0AAAEHobSM58Seil737Ncb03eg==
X-Received: by 2002:aa7:c509:0:b0:458:cb1f:b9e1 with SMTP id o9-20020aa7c509000000b00458cb1fb9e1mr1229007edq.369.1664637212369;
        Sat, 01 Oct 2022 08:13:32 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-186-130.46.114.pool.telefonica.de. [46.114.186.130])
        by smtp.googlemail.com with ESMTPSA id c17-20020a17090618b100b007826c0a05ecsm2761197ejf.209.2022.10.01.08.13.31
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 01 Oct 2022 08:13:31 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sat, 1 Oct 2022 17:13:27 +0200
References: 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 
 <20221001144827.GA97474@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20221001144827.GA97474@www.zefox.net>
Message-Id: <73A50178-F866-47DA-A101-393E3B388FBE@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfrG75Bs2z3qNW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=bfo2f2wu;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 01.10.2022 um 16:48 schrieb bob prohaska :
>=20
> On Sat, Oct 01, 2022 at 04:06:59PM +0200, Klaus K??chemann wrote:
>> Well, I think the u-boot mailing lists are made for=20
>> internal patch contributors. But it could be worth a try to subscribe =
to the list
>> and mark a message  as a bug report.
>=20
> Already subscribed to the freebsd-uboot@freebsd.org list, with cc's to =
it.
> No response and very little traffic on the list, mostly bugzilla and =
pkg-fallout
> robo-mail. I haven't taken the liberty of callit it a bug, however. =
Maybe
> that will catch the attention of someone-or-thing.=20
>=20
> Haven't considered the Linux-oriented lists, since my only example of=20=

> Linux (RasPiOS) works perfectly with an identical disk.=20
>=20
> Thanks for writing,
>=20
> bob prohaska

Freebsd-uboot list is not the same as =
https://lists.denx.de/listinfo/u-boot
All u-boot patches have to go into u-boot upstream itself (viewed from =
the fbsd-perspective) as far as I remember.
IIRC RasPiOS doesn=E2=80=99t use u-boot(that=E2=80=99s why the problem =
doesn=E2=80=99t occur there)  but=20
but e.g. Ubuntu does and afaik they have mailing list for u-boot =
stuff=E2=80=A6.maybe also worth a try like the denx-lists...

Regards

Klaus


From nobody Sat Oct  1 15:22:42 2022
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 4MfrSj4R5sz4V8X5;
	Sat,  1 Oct 2022 15:22:45 +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 4MfrSh3m1Wz3rQy;
	Sat,  1 Oct 2022 15:22:44 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291FMgnn097601
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 08:22:43 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291FMgpu097600;
	Sat, 1 Oct 2022 08:22:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 08:22:42 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001152242.GA97581@www.zefox.net>
References: <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
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: 4MfrSh3m1Wz3rQy
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Sep 30, 2022 at 05:51:03PM -0700, Mark Millard wrote:
> 
> By the way, it looks like having the line:
> 
> CONFIG_CMD_LOG=y
> 
> in files/rpi_arm64_fragment would try to build the
> log command into U-Boot.
> 

Done and working. Now to learn how to use it.

Thank you!

bob prohaska


From nobody Sat Oct  1 16:12:23 2022
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 4MfsZC2BZTz4cvyf
	for ; Sat,  1 Oct 2022 16:12:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4MfsZ961zLz3wLF
	for ; Sat,  1 Oct 2022 16:12:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664640751; bh=/gtLlJER7xERiBE56qb6jB70jFB0mre2sKwfCgyg+C8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Hty5OdxFIMhtxHiyje7b8qvXbQEMcUMaOV0IXtZEpV5X0QjleQTbySF/igCkOKC0rLXtLerApQwTGK+6VRlTarrCjHVjAxICnpWkKzq6xVvUpBagwRzML8GF8JawbMTwvJkgItt9xwL8adYI7wJzAiZ1VfGdzTW0C0XNoK5dQvWN7QJToN+6VtCbSH5/F50LA6P/ae/3WxWgl+DigSIGRBPXXXw81UlFTDyC76CFinJRpnoe2le01PCuARt2JJgBiwKrQaPyxOsu0FnZbfxuj/V7aeat/IMiwYMcqMRQwMBHFB1Zz2gUXjSUN4TtwV4KgVaonFyhvghDbEF77halyg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664640751; bh=iVKDkjjCtOtMnjZl3+wIr5C5Hy/EKBeuSYDVX8ZQtOq=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Vc71pqrsdepYVyi3PSqp30lrJ+YU/Y1+dbfMARfp8TEFxUWLo4klXJ/DoYXsqcszoJqHunW+FIUhcyfr8Gs1DkagAjwNmTrfH1cafTbD0lRNV9T59cwDrIGKaUgmXfYGlO0IqIdly0f1C9ltXcKJ4iOVxrOuNQYXnDr+BiKmDz42OpVVDxtKpFujNR/rIp+xiv58DtAGgGa6cgjB1iJiXLseKzvUSDZ58+2QhOWDp5z7bDlgXHAWndlnNakk1CcnB+u9dvfn8GR0hvd2+zN2nps4dSB0EgMAjyyiesvF2Q4mHXyOb37TCaqGMpzq5q5HmXGdQr68pDW+9zKcSD3/NQ==
X-YMail-OSG: MYzckd8VM1m3mMXgfMop1yJAbb3Dj_kUvoH1CDeL2VH_RoysJGaQVo8WRHycpgm
 EuROuk.ChIrdwWkd1svN4g0A3o4UJAcn7nWTFBgYvES2.7pi25n4pr2QeqwErQf.5i2MyvKpIF4o
 hZLUbRGgHFC1ihn5_lip44MsoMwBG2I1Zk2xx6T5otKJ_ACaGJf4Y.YyH3cMhA9OZuybJDYJqpJP
 pZnSFcuMzW9YtQshE2LYj8AFpB91f1qnzaR3tgsMpwCuDvaJoaBxs.IGeWACLlg.A8OCeG5vcuY9
 WtzwqGqtPyboMeYPwPKNi33RcW.AKlEciX3tU_sLCMKXOOK79PdDgYilbtFGMrkLB8IbIKTP60nB
 9VjWZFppF4o3mCq0wA1yDG2mslDv9gp8rxBl5CDmw2xOmTEN7Sd2bUX3XFxu_3HX87LTz5AO4cwx
 FUYKmO4ZjTVBdX7m_dTnVSd7gYCY5c9tKjNuFjuG7sHgx9ers7f0WhkSpJSiEdyu57IibZOOwLJS
 vN3EX6IQBThVi9DSlevbL6JvTR4O4lcrlcESV0ohzdZ4tMHuOyFM2S8wT1BFxhJZq92LvlfAY_mX
 q7th0aVTdRZEm4PxOb20vIWignr5M3GFfEhdrouRixlUFhEqwnyqQZLGZ3ImomTWce5GDK1lgZdu
 QcNYZ8eh3vU_R246rchGCPJvEyxQnZelKHEryU3AK6m2gOB8XLLfOwS3PGkH68CSQLDLwZi_77c9
 lZ17.OgKz1ipACEpz1NJXSDHscOYvPXqIqaFdIc7hkB3QQVwdyDvsbzgrJhaNL3_N0CtVSXGWOOi
 jbyvaCM9_qACCtkuyjaw70pnXGbw1u1ZxGfwwyWcd.AX3g8gIl2KIc4gzv0PNsT1SUqjA_5QPIVn
 ZVnXqKwoBNyeBsC6aCnLDcuKB1rymTWIyXnSJdG8JRGbXaOIeGaVb86vUp_.dy2o9a7oebOlE8Ts
 DfmDR_TG..2UewsFGxgFOgXI.TLamu8jFQgA35435HC1AyPMMyAM.qgbO58P1IxF7cabRaMskoKo
 rb_J.k_MwEN4E5hFlguhi3wEQH0hHHz0LQKWkmMk6XDoI72Wi.Ni7g9eZUos7SU_69PsX_LV4Zir
 vFenDVDQ1tlZWRvtW8A5EUCwSx5m4D4KCx9fZZLmrou4sCFLg2JuyIJcA8tc5uz4wv9t9awFDXHa
 rkUhl0FjA9qJLvOIA.FxwCouMZnBVyjLSJp6oZ6dRy6RXIjQyCs8XuP4fAP5hb7J3kBXpojk80Hr
 WLk0aXpQlloaaMSguluTmxpT2KqTFn7f4wEegXjaaB6yqRYq7JejteJhbL_l6YGq.LYRaYpJVJVM
 xrd53J4aoP5sITowc1sy8Qm71PpywuXf0uU69UYagD_bxRu_ZU7h0C2yXtAWSnMUs90QWR8x85Jy
 fcROMopre5ndSWy0u8u0NkXW3T.t5D6UTyZ0oneRoZ4mbzmOk18W81C0rP.f9GYC4e_5HkFF16PF
 dA0g0zWpvGizNDj1U_r1NYkT7RybVgDXih9lxrqJTArsXYa3yTIMGuqOCz.KXo8_nvvnSnGOxSv5
 JqQm4ZrC5P.vdM0MTpceY4IlBQNmZrn5zp785h5ohEf2H2f_Q6uvv6kNmPbUzmS2o4F6EeL_njIJ
 36GkA0bbLO4bpHVROJzlUe0IvGFvusZnjcTaTAEuKKxhgza20bzr2phN6OwXdZE3kRyT3A_gvvAn
 BZXmbFaZ2miXSB.abHZ2btUYF2SAsWciavmKvB1STk_YdRq4B8rZOZRNxlno1zO7mViX8pbMxBOS
 1eojS.dtmFlXFm2TTOxdi.f2ufowgX9HXST4wjC29MS38criXUGFT80xgqd1VorTs1osdE5h4RZv
 v4EXt0N3pTFauy8brKUbklg3TYNwEw7ZP68xnLYKtipO1SBfDKEGgZow2B3yymlsjttck13R8G7z
 NGsRuztHOJ4w7I_sfyT_dMoVC48SRQlJorKBkD5MPGMhaSuYvVQlft3CpnBsd2sXPydGd.RJjaPv
 mno5z6h2T5s8pnfxmCLQOeuQKTyJ.VdVZA44XVHZ7S1sm.pdEzpg6MHcn9AgSHVWyG3V7ai0wpHo
 ETfqPYp.s4i609I6XzVGAVzJ5f1ayRoTgfZIUyyNBPHPZvZDZQRdhkK8Y_EdgOz77iOkxuCBa9gu
 qFJ4PYpYXux0SH81pC3fGz0FxPHG88_ML9f_3.FSIs37quNg35QXw.lol1ySK2NdhL3zM4UwLVzv
 EmoKERQyJJ2Lxl_ghba_DqE54_j02xmAn5ysAF9aeyawcd2kJXjsk1AE2Mju8e3v0PUaKCcEPoZO
 VVcwb9A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 16:12:31 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-6jf92 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9213fbcc413c444dcb2a9b4479e5f3b5;
          Sat, 01 Oct 2022 16:12:26 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001152242.GA97581@www.zefox.net>
Date: Sat, 1 Oct 2022 09:12:23 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <51B729B0-3792-4870-9DEA-3E47F8BCB37F@yahoo.com>
References: <20220929151926.GA80020@www.zefox.net>
 
 <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 <20221001152242.GA97581@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfsZ961zLz3wLF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Hty5OdxF;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 08:22, bob prohaska  wrote:

> On Fri, Sep 30, 2022 at 05:51:03PM -0700, Mark Millard wrote:
>> 
>> By the way, it looks like having the line:
>> 
>> CONFIG_CMD_LOG=y
>> 
>> in files/rpi_arm64_fragment would try to build the
>> log command into U-Boot.
>> 
> 
> Done and working. Now to learn how to use it.

Good.

Have you tried the updated patch-common_usb.c that
has the 3 mdelay(...) adjustments? Does it lead to
avoiding the problem? Any change in observed
behavior?


===
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 16:33:23 2022
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 4Mft291JW1z4cySX;
	Sat,  1 Oct 2022 16:33:21 +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 4Mft282QHqz418R;
	Sat,  1 Oct 2022 16:33:20 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291GXOkB097840
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 09:33:24 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291GXNet097839;
	Sat, 1 Oct 2022 09:33:23 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 09:33:23 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001163323.GB97581@www.zefox.net>
References: <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 <20221001152242.GA97581@www.zefox.net>
 <51B729B0-3792-4870-9DEA-3E47F8BCB37F@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: <51B729B0-3792-4870-9DEA-3E47F8BCB37F@yahoo.com>
X-Rspamd-Queue-Id: 4Mft282QHqz418R
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 01, 2022 at 09:12:23AM -0700, Mark Millard wrote:
> On 2022-Oct-1, at 08:22, bob prohaska  wrote:
> 
> > On Fri, Sep 30, 2022 at 05:51:03PM -0700, Mark Millard wrote:
> >> 
> >> By the way, it looks like having the line:
> >> 
> >> CONFIG_CMD_LOG=y
> >> 
> >> in files/rpi_arm64_fragment would try to build the
> >> log command into U-Boot.
> >> 
> > 
> > Done and working. Now to learn how to use it.
> 
> Good.
> 
> Have you tried the updated patch-common_usb.c that
> has the 3 mdelay(...) adjustments? Does it lead to
> avoiding the problem? Any change in observed
> behavior?
> 
> 
Not yet.

However, with logging enabled (but still not understood)
there are more mountroot failures. Here's a list of tries,
where
S means I issued shutdown -r 
P means I had to powercycle
R means I issued a reset to u-boot
L means the Pi got stuck in a loop
U means usb reset was issued
M means the Pi stopped at mountroot (self-reset)
B means I issued a boot at the loader prompt

The sequence was:
PRSSSSBSSSSULPMSSM

I've placed the log script at
http://nemesis.zefox.com/~fbsd/ with mountroot in the filename.

I'll try your patch next.

Thank you!

bob prohaska

From nobody Sat Oct  1 17:47:24 2022
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 4MfvgZ3JZHz4dd37;
	Sat,  1 Oct 2022 17:47:22 +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 4MfvgY43Jhz4DZX;
	Sat,  1 Oct 2022 17:47:21 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291HlP4v098123
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 10:47:25 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291HlPMv098122;
	Sat, 1 Oct 2022 10:47:25 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 10:47:24 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001174724.GA98055@www.zefox.net>
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@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: 4MfvgY43Jhz4DZX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 28, 2022 at 10:10:20PM -0700, Mark Millard wrote:
> On 2022-Sep-28, at 20:31, Mark Millard  wrote:
> 
> >> . . .
> > 
> > It looks like that if you remove files/patch-common_usb__storage.c
> > and rebuild/install the large output reporting usb reads will not
> > happen.
> > 
> 
> I've included a patch-common_usb__storage.c that comments out
> the few high volume debug(...) instances but leaves the rest
> in place. A dozen or so lines are still output via this source
> file now and I was not sure if any might prove important. So
> this way they are present to consider if this file is used
> in the build.
> 

In testing the patch thee seem to be more cases of u-boot getting
stuck in a loop, not all of the identical. 

The first in the script file left the disk LED stuck on with 
error 22 prominent, the second left the disk LED stuck off, 
with error 110 repeating.

The script file is at 
http://nemesis.zefox.com/~fbsd/
in file pelorus_console.txt5_concise_loop_fails

Hope this is useful,

bob prohaska


From nobody Sat Oct  1 18:08:05 2022
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 4Mfw7g4ysfz4dfpm
	for ; Sat,  1 Oct 2022 18:08:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4Mfw7f1dDvz4G44
	for ; Sat,  1 Oct 2022 18:08:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664647692; bh=Yj6yfoBMzJKHMV43ZXZGCsC+aeswMc2ig6z/lhlLUs4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Adi7KWfXLcWumryhq1dR4BotZJEdotgfG5ZF6vZLUMPJfbx119WTQmwAvT5K42/28F0Wn+cp2FQyT+gFkPjbkqbHSYMwQm7mUZtErX14e86CvBiIzR6Pq2cIX17EWShtq2kPK9qrurpZd7b1B7lWKxYrhq+CzOPcaNL1a8NNYXnENmMpi5Nk8wNxNeVj0igruRIX7buR+JL/xty1qAKkZeiBwEx6ejFoXAtmkJ8GvjHYkYgP9AHVKh/E3sXROx3BM38p1a3VmlPu+WmsOeQDzfmtSRy48mGcNqAF5rny1hXn4SVm66jGdfg8/2wzkFAGzKgGFBD92/HpxVUhMTPr0w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664647692; bh=Zv9hG9ZJLgPwJ91AKr9L+n8nXtALPZ5wyOQ30h9WTyf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y3DlkgXaN7HfbdGYQp/P95wYYL98cAi5dWCXhcGkDn1+jS3WvjbU9Ju/65ZRNHbECY6TxOx1qB2Z1NBLLrP+2XiqAdORLX0cGQEeTxP42G5O9zo4QNbgQqSTvWBkeuyxvky3Id+6X2eDuNmyff/DvLTkaQJcHJV54ifB+6NjZEqZhdkagh/7GSB+tqcjZliMq4z1G/k0S782wgkQnW7Y3k0pYaDpjzbDMOfQthleF3WDHKjV+Zbmg5TzUJwImnv512KAoTsamzLZJHWAKqjLsBo17BRIy8Ywtlri+iga0IppEW5aUOtUWf5lYIYWc5iyq9B+o4m1JMRP39aTkyC7ow==
X-YMail-OSG: TzTneJsVM1meL2CGpXCPrnwQQ8m2SBHTvbDlNMg04RDljjoU7wxx0UsmvVaHWnv
 Sf_P0yIEti_14qNXOWpL_0kw3Rop8X.5pl1V9ZrTuUT1.xILxK0iJwFxs22udMErWrTd8fMs3x1d
 HwnQ1rLm_F1kUh16ZqUxBvdQb_srsWMbg0yj6eAgjdpmgcrBZ2CGI9JJ6aU6IL41TA4firtoK8B8
 ofk40RVSHtwLCwnELpVdu6gO.E3b3sQxeS_yL6ZitHuW1FSn4AZYTJVQ9JQ06jL54ZVFEEQ8X9Kr
 R6Vxh7mIPPQ.b7JO1SfbhoMWDAIPcSb6OyKRWgzJJPoKJSp2K.LCWWXvo3jUPvUdgZOeUdXPPvM1
 vvvMv_H7ZHbQW7ejlSQ.2TMHAXRn8iCVHtW_AHTTLKy25MFIQuMB1BvEExxfQfrA267Oi9rqC7VZ
 8CKMS.F68Kjvu2kMTPPdgZf8RkkL3pzTuCmMaB29dEBUsB02XJ8NBgQ1VmzjIQ1u_9PZfPbvVX_b
 XMhLc_RzktsINhUKfdO1thxkfUGTQ0e5XXyP3gro1txc1BNglL..v7ViuS9W_TDDB7zjz6TXU1U2
 CLQc77EPkHp9iXQlADzRvx0z5Oi_hINx0TlYOjvXfwDtoKcy4U.ON_uyTGxoGqZkE9AbiX0KMSYb
 Xu6rFxHUebFrbTbjR3f7wSfIqCGJ3mBnR7P67XYRypIXIorp_EyBYjpp3Ofme0KyoSJbMPPR01Hy
 Mzymdu6w4ZNrERFe8Xj_toBS3JOJD05G3fqXNkznIRK0jreEU1AtUQhYoOUC8cGO5h7pgF6GC6KF
 1XgBGP2xhPc5WkgOwFxhkPnE_bdtww1AdHBF3.zojlesZEUWV84xxRo7AApXhHvdk__0KApbzop_
 c7NKzlmUaCGkX2USHvVvDqYbzoWGzuO.5ZHLF15W24Yu443b_L9l1FvSQ2JalWm_FZUWlLaNGwg_
 __h12YFrOzWGmppJ1pML93Pr0rr8YK2HINky7_HHTHkAQBT8OphO7TlGNgg9YDK1.eqo45jjNXUs
 gkm4C71lp3KqLJbSF9oduCoEav4kRMDuT2n2b77ts_C9GA965ozGrthXq2X0yDfKK0a6RD4elh9Q
 zFIFvIVI7XAGu4C9DlBguj4TPyfv9Ki4aioDU4zbdY_UD7yFE4PuweqwHQCj3Eq4nm72NU0YROmX
 mf5JpsVoaR3Pe_MDFbJ_LZQWm6HwhYxFe14uF0dVZeT6T4ZR0bA9WmNW8pLl.z9JH.Z2xO_v4Jnt
 WfoTPdBQxUxz888Wjqq8Q3QwkHD7R6vFhgtzOJ65FrTVZR8ilyt_It0KF5_M58vznAdtLBlaqu37
 qycGGBq4Rgx78UEblQr1clFpjFWPPM2YlGuzgHb4wIfAQw89a72E2HdO8vBnMY9b899RM.Z.JpyV
 ebRYjAJzE1vjyyOXBgCepZs6jp6xgOkYIIpXfms5tGieKGkJKXJlHTXzk_u5cd6gHgSuKIYUXhxU
 lhQz2RfWh1LQxqghE1Az4i.lj3AwShDqu8wNCsQYoHm2wA_UsXcTvq5.LuOjN0gwkFuJEk6adxjO
 GkruEbLVabvpLuRUrjY1UTui.Fye43E84wkUi5yN1rVJUbJ8FF_gUb7uw4o_16ByWkHoKURpqpIZ
 LiGLN0PWa5aVNo2.0PxtaB0jujOefStXRmOBe2psJr2v7AalIHX5Bp5QBA5ddCs4tzVKoI243QrV
 3Qzp201JxxdZoJZPoyHqzN3FUmGKBXWUuP0xJYIz1TC44yqb4hBW2RI73PG6T0lHM_lyWYJvYH.m
 2boebQMJnkUQWEFnHz2HcBEuVskLp6R.aR.4lPIdjBKDEz9e3MmlRTavIi_jG1JxZ4KqdrztvuZE
 Rcja7btXA2WdgBngESSzr9C6URQaUGvZBHVGaPR_My09UeV7wfvTd7PBzlSkgrSnNm1o6u7fdYdm
 QRFwUYV6ZFpVumq1T08t0MQyWy71jPrQkbThJRik7UEeGYEPf67wTQeXahLLS62dIl5PzLzD6TTe
 kiLqS4HLMhujWBoP4lqM5LgZEBD.Vv65Uwby.lunQ6kXe_6DxDwO9ZUmztw2YqzUTu1gnyjWbDbc
 OPsRxE00y5pmuwCcKq7wmBB_zuTKAn.rF9fBhRdZVbBr4nMciPNDRWEtPL3Tae2MpiBb5gjs_zYL
 d_Op9CHdCXu8iva59fppmPpRt4A3BYbh_W1mbNH1BNaHQ4we7UUFr6VoKd1MdIxLh0sVspYPS.W5
 .WhpnVyETsPjfaeM0rOfBVauPptrFv5fX95N1TSL_HKDNfcBnSiSxV4bNoTBoOK90krllbOUgxPM
 rZ67rQw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 18:08:12 +0000
Received: by hermes--production-ne1-6944b4579f-9v6rl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c3a68fc71f6c357948a8162e33e25060;
          Sat, 01 Oct 2022 18:08: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001163323.GB97581@www.zefox.net>
Date: Sat, 1 Oct 2022 11:08:05 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220929170927.GB80020@www.zefox.net>
 <6C5019EC-B4A8-448F-9A85-4A98BC46F7DD@yahoo.com>
 <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 <20221001152242.GA97581@www.zefox.net>
 <51B729B0-3792-4870-9DEA-3E47F8BCB37F@yahoo.com>
 <20221001163323.GB97581@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mfw7f1dDvz4G44
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Adi7KWfX;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.970];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 09:33, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 09:12:23AM -0700, Mark Millard wrote:
>> On 2022-Oct-1, at 08:22, bob prohaska  wrote:
>>=20
>>> On Fri, Sep 30, 2022 at 05:51:03PM -0700, Mark Millard wrote:
>>>>=20
>>>> By the way, it looks like having the line:
>>>>=20
>>>> CONFIG_CMD_LOG=3Dy
>>>>=20
>>>> in files/rpi_arm64_fragment would try to build the
>>>> log command into U-Boot.
>>>>=20
>>>=20
>>> Done and working. Now to learn how to use it.
>>=20
>> Good.
>>=20
>> Have you tried the updated patch-common_usb.c that
>> has the 3 mdelay(...) adjustments? Does it lead to
>> avoiding the problem? Any change in observed
>> behavior?
>>=20
>>=20
> Not yet.
>=20
> However, with logging enabled (but still not understood)
> there are more mountroot failures. Here's a list of tries,
> where
> S means I issued shutdown -r=20
> P means I had to powercycle
> R means I issued a reset to u-boot
> L means the Pi got stuck in a loop
> U means usb reset was issued
> M means the Pi stopped at mountroot (self-reset)
> B means I issued a boot at the loader prompt
>=20
> The sequence was:
> PRSSSSBSSSSULPMSSM
>=20
> I've placed the log script at
> http://nemesis.zefox.com/~fbsd/ with mountroot in the filename.
>=20
> I'll try your patch next.
>=20


A failure leading to mount root failure:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
Root mount waiting for: usbus1
usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)
Root mount waiting for: usbus1
usbd_setup_device_desc: getting device descriptor at addr 5 failed, =
USB_ERR_IOERROR
Root mount waiting for: usbus1
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
umass0:0:0: Attached to scbus0
uhub_reattach_port: device problem (USB_ERR_STALLED), disabling port 3
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
ugen1.6:  at usbus1
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
(probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
. . .
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9


Another failure leading to such:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)
Root mount waiting for: usbus1
Root mount waiting for: usbus1
usbd_setup_device_desc: getting device descriptor at addr 5 failed, =
USB_ERR_IOERROR
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
umass0:0:0: Attached to scbus0
Root mount waiting for: usbus1 CAM
ugen1.6:  at usbus1
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
umass0: detached

Yet another failure leading to such:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)
Root mount waiting for: usbus1
Root mount waiting for: usbus1
usbd_setup_device_desc: getting device descriptor at addr 5 failed, =
USB_ERR_IOERROR
Root mount waiting for: usbus1
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2
ugen1.6:  at usbus1
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00=20
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n DD564198838F9 detached
g_dev_taste: g_dev_taste(da0) failed to g_attach, error=3D6
(da0:umass-sim0:0:0:0): Periph destroyed
umass0: detached


All 3 got:

usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

as the first failure of the sequence.

This establishes that U-Boot is not the only thing to
have problems with your equipment.

I'll note that the:

da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9

does not match other log files:

da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 000000000000A

but it may well be an example of garbage-in/garbage-out.

The same goes for the usual:

umass0:  SCSI over Bulk-Only; quirks =3D 0x8100

vs. the 3 odd examples:

umass0:  SCSI over Bulk-Only; quirks =3D 0xc105
umass0:  SCSI over Bulk-Only; quirks =3D 0xc105
umass0:  SCSI over Bulk-Only; quirks =3D 0x8101



You also got another "0 Storage Device(s) found". It again has
the sequence for portstatus:

311, 311, (sequence of 5 instanced of:) 301

for:

Manufacturer=20
Product      U-Boot Root Hub
SerialNumber=20
bind node usb1@1

So, just like the others.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 18:32:52 2022
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 4MfwhG1Nr9z4djRS
	for ; Sat,  1 Oct 2022 18:33:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MfwhD3lH5z4J21
	for ; Sat,  1 Oct 2022 18:33:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664649178; bh=w2kFd4Tprtj2S1l9WZsxg/JqYLb643XU3Gy1BuJEN1Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FULqyVIM/l9XushfaIUgr/QD+56NSeNKu0ai2VtJU1ZbJTYlYlbybh1JqqTYFzKGzg8c6o5rTaTvLtY/MIranLBp0lZVQ2r9ChQyJjiyJgXdPQGy4iYKHZH0DmsHDVUOoLvKD3mMp5gxc/WblbXd+gz4UGJO4wzJiLTY9+v1gmSIBnei46kkOkc5/N1etCMohSfIHayZB9her8XxEGla9Sx2MqLhFubdwyEiZE2fVevcyPLXIoREB4T5tM+WQuNJR4UMY+qmoIDJcJIqLskLymJWp9+QjJ3HchBxhHxTaJUzdoFvixodupwHrMx21KiGXol3BFMcq562brel4pwEbA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664649178; bh=U6/+Ag8BnkEiCWYBHX6zu41sMUmucRbPSMo1L0cam1p=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nTgl5svarqCq2kZBfR83uTpamksXIpiJkoExFMljR3rluVAef74CVZCiWYCJWPJChI9C6Aby4WM7ZEARbC1tf7gtzDhbMlrt7/do8XscSiJbUIzfjsadUpfBbujcCFbqeFFhqs4QXQystaD2TeaXB/21OY61B9+qGroY/a+BJFP0v+sciuD12L8tI4n8RXGgO/IEO3WD7J6g8+ifObeHkkMaoZJIGwi4K/zmnJisjxg+SPOZAj6HdcwdLPm7rW1VwnmPOgu2w12SROjEY20GH1xWoSzJ4ZSOx3ycG7GfzWKowkH65cZ4p7GN/aTC0aLqow9QqwyfwjlK/P2H2znbjA==
X-YMail-OSG: LnbAnoIVM1muYf2MqstPw5uMVtAhnRfbTmKrt2s5ti2_WJoAxrfAWwU0m8cFUGI
 6jRSY.6xkHxVGEGO8CoODtwyW0pYF33jzC705glO_0pP0HcJKaeQKPyO0DlhEKCDlJf0STXC7laq
 14D9Z6AkojwqXNA6dxN4t4.kvAK._udegxam.jLIp8PUoBvhT0MkpMtfqKR2jEzW3qmr7NG.2eTj
 pyL7Y1TDLhSrRaCJf4JxMNcKNMkPKelpMSf3F1YjMuP_W47ljd_DNSyHEm34w5DZG1M0PX15I7Ur
 5HlVYQIGEcT86iFarDoyHV0bq4rdu4ZAKpM6wg_zq.GUlY3K.XpXrQWopY4uYoi63adZcYhjbQe2
 EuNUjf8Ow8jn3QJ_v6MV01VBXUtfH2Fn27CYdI_dJXZncTWfytmy_kISiB1tFdTsA5sz4.fTRfbW
 uFY1c7QUR2oBIWOqu6VgwYJ4ILd5ssp_BBvjXe6k2Vgd9zHgPM_szpT5Qdkf2XTnG1UBxdI0Xn2r
 M7yUZN2I38cnxKqerX64Ol4HKtx3i_.4BKOq3y2EnzCRr0OBkL0JWImbcFYNRPQWLE42bOfLQ43E
 Dg86Qwgsli_rno3x80KxShwY1TtAIJhbbXbGKEAQPKTyOjDR8gPKoKgUH3qn69eT66xqZcFklLw4
 _DVHCKio9aMcCpNXbm4ckwnuQfZ0NOZMQxoOreOIrvZvhhjJPsZgcVUGqQqacnCueqj_1PtmJgx3
 C9tP.5DXfRaT0Y3VZbQCv_3_ZAPaBO8nK4kLvSgmp2swZ37kBElnnQyEjCxrb5brUZJj85HpP2bL
 Lc42qOYTMLavK.D31xQAenomEb4BYEXwlywXgHQYKYLA5uVXi5UP5qzCV7mOatxQ_.dKDytuEfYx
 s8fQ_pk0WmpeKAoumzRKydLrAoaJ690II5ZQE31DNT3sjtwolLc2Yuv9qqhjW6uMRBfwXBMFVu00
 5Yg94uY7jxTVAAXbf8WKa8UBeoGYNA.U70CHdHOlM22iWMWYTMWoAZ6jgP_7MgeGKHzNpznvcsRQ
 GCHNaNdCiwhbGijwebHlwFtRtS3WoghQCKI5sFYiyidN4eaWyNbSiBP9yhJeBQ8sztUb_81aU6Vv
 5uuAhFuxTr62yggwMk4KFb.zu7aboq9oSm9dwLDKgZkwC_UuLILwhqj1BPfi9xXqkXsU1UZttWlt
 ebDRHz7lvWWH58GuC9GSB2dV6tVyMHzaLM9i5m.WuPO6yeFfINOATw4Xzj4PmheU6iuS.DrUPH4o
 l6ol2P2YzcSRnTWHsEAvcIKY1SI5hlKQEMsXPfzeZ6cu_qiFuL2ojhC1J92Er6OxN1RAxbRfsH10
 PsZPb_IOKLk8hyS6fmjRtlYSxKRhRlOxcTzqxnfhRRbWT6N05GpbmRWgt3.Ne1qwcQWDTTeq3_o6
 LjyzZeD950hGIjL84.6DWLQOyOIVaF89IC0EWS77lwfGGLkhmXqK9wcbZVA98TsqU1Diiv9zAZea
 ziT1pwz4egvY8eTSjYgZP0YkK5_dF.nuF_N.CtZuqNbmqCAEBewIyQFb5KZeUHsZMJw5P9n0xi3T
 nXUao6W0si1yX5mQfn7TU2XxIawC9WaJ8psO2BuPZmWSRkJSfmY29vD1rCiZFnJgN24PMjhrvKVh
 zWpJA3C_m016L1BJy9b_aEpqFIevJX0WI9dzzsXM.7GNZ5MFFXGFI_5nm3PZoiMbTmwBtIko82uR
 c_NsOAdcGjtjU1TlydqfexajwcvKIk85VHcbSMuCSUb1CmO6uYoa35X4iPqqcRSNbvBZ783Qvbtv
 NDmhZLXJoZuRU2dgvMdhxYH6qHj4IUtK6HtAYhdNY0QR8lYnnrIAwFOhhOrs14w9dO_rswokgdV6
 y_fET6RanpmznXQtSLnLCQtSL0GQozB5j0V6pOqz8Zu8iISwowUrFpxCtwQH3p16bPsQ9eqxWg57
 N3Wu.sK8t8whbwM.JkqaUr52NR0lwjVmpKXI3PZ_v7hwJvWE8fQZvOGJkPh6HiIIW_H547zQxdQl
 Rk5KxnEVVawF_xaMc3GSM1qnhYj3LahrzZH1_yqafTBPkjOmGv7Ir5NibZUypSnBUtKyn4BsNClf
 7HUKH9XgRqrHQmCpslWXUnRWnkGtiClgSF5oePGcLQBKqu61Lp2zRLT86sz0_Kls7BWA1VrcLesN
 Dhs58F2t9dlv8pGKVeF7hsV62bMhtPjnqzbHMdWC_sS8rRGhQc42CxVjjKDo6ln_AAOm0qhKKNvE
 VLPqWIc9zAp4SOCIhYiBlQRRTR4XW.sxLi_VZmths_0nKSMzmEHU6ehnno4B_rNb0PHym1kqy.3i
 FkA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 18:32:58 +0000
Received: by hermes--production-ne1-6944b4579f-t822l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51216c24bd1db203621114d24c7fbc36;
          Sat, 01 Oct 2022 18:32:54 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001174724.GA98055@www.zefox.net>
Date: Sat, 1 Oct 2022 11:32:52 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com>
 <20220928172839.GA75564@www.zefox.net>
 <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfwhD3lH5z4J21
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=FULqyVIM;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.89 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_HAM_SHORT(-0.39)[-0.387];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 10:47, bob prohaska  wrote:

> On Wed, Sep 28, 2022 at 10:10:20PM -0700, Mark Millard wrote:
>> On 2022-Sep-28, at 20:31, Mark Millard  wrote:
>> 
>>>> . . .
>>> 
>>> It looks like that if you remove files/patch-common_usb__storage.c
>>> and rebuild/install the large output reporting usb reads will not
>>> happen.
>>> 
>> 
>> I've included a patch-common_usb__storage.c that comments out
>> the few high volume debug(...) instances but leaves the rest
>> in place. A dozen or so lines are still output via this source
>> file now and I was not sure if any might prove important. So
>> this way they are present to consider if this file is used
>> in the build.
>> 
> 

Wrong email for the patch in question. Wrong patch used
as well? (Actually, the log output still has the high
volume debug(...) messagess, so you did not use the patch
from the email that you replied to.)

The email with the patch is Friday's 12:58 PM email about
the patching involving 3 mdelay(...) calls.

> In testing the patch thee seem to be more cases of u-boot getting
> stuck in a loop, not all of the identical. 
> 
> The first in the script file left the disk LED stuck on with 
> error 22 prominent, the second left the disk LED stuck off, 
> with error 110 repeating.
> 
> The script file is at 
> http://nemesis.zefox.com/~fbsd/
> in file pelorus_console.txt5_concise_loop_fails
> 

As I understand the possible result of the intended
patch is it might avoid the "0 Storage Device(s)
found" problem but need not avoid the later -110 -22
error code related problems.

So if you no longer get "0 Storage Device(s) found"
problems, that is progress/good, independent of any
later issues. Otherwise the mdelay(...) changes are
probably a waste and would just be reverted.

It might not be handy to test lots of examples of
the "Storage Device(s) found" messages, independent
of what follows each non-zero one. But that is the
kind of thing needed to test the consequences of
the 3 mdelay(...) calls.

===
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 18:42:58 2022
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 4Mfwvg5KNWz4dkXY;
	Sat,  1 Oct 2022 18:42:55 +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 4Mfwvf72Ctz4JcR;
	Sat,  1 Oct 2022 18:42:54 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291IgwBl098293
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 11:42:59 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291Igwnb098292;
	Sat, 1 Oct 2022 11:42:58 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 11:42:58 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001184258.GB98055@www.zefox.net>
References: <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 <20221001152242.GA97581@www.zefox.net>
 <51B729B0-3792-4870-9DEA-3E47F8BCB37F@yahoo.com>
 <20221001163323.GB97581@www.zefox.net>
 
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: 4Mfwvf72Ctz4JcR
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 01, 2022 at 11:08:05AM -0700, Mark Millard wrote:
> On 2022-Oct-1, at 09:33, bob prohaska  wrote:
> 
> 
> 
> I'll note that the:
> 
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number DD564198838F9
> 
> does not match other log files:
> 
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number 000000000000A
> 
> but it may well be an example of garbage-in/garbage-out.
>
 
If you're comparing past yesterday, probably not. I tried
a different enclosure (same make/model) on the chance the
first one was somehow damaged. There wasn't much difference
in behavior, if anything it was a bit less likely to boot.
For present purposes that seemed helpful so I kept it in place.

Apologies for not mentioning it, I didn't think anybody 
would notice..... and then forgot.

As an aside, the new u-boot.bin does seem much better
at provoking loops, all with error 22 or 110 prominent.
So far nothing obviously new. 

Thanks for your patience!

bob prohaska
 



> The same goes for the usual:
> 
> umass0:  SCSI over Bulk-Only; quirks = 0x8100
> 
> vs. the 3 odd examples:
> 
> umass0:  SCSI over Bulk-Only; quirks = 0xc105
> umass0:  SCSI over Bulk-Only; quirks = 0xc105
> umass0:  SCSI over Bulk-Only; quirks = 0x8101
> 
> 
> 
> You also got another "0 Storage Device(s) found". It again has
> the sequence for portstatus:
> 
> 311, 311, (sequence of 5 instanced of:) 301
> 
> for:
> 
> Manufacturer 
> Product      U-Boot Root Hub
> SerialNumber 
> bind node usb1@1
> 
> So, just like the others.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
> 

From nobody Sat Oct  1 19:30:33 2022
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 4Mfxyc2D3dz4dpsj;
	Sat,  1 Oct 2022 19:30:32 +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 4Mfxyb11mdz4QGX;
	Sat,  1 Oct 2022 19:30:30 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291JUYH4098436
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 12:30:34 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291JUXEP098435;
	Sat, 1 Oct 2022 12:30:33 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 12:30:33 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001193033.GA98348@www.zefox.net>
References: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
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: 4Mfxyb11mdz4QGX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.06 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.96)[-0.962];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 01, 2022 at 11:32:52AM -0700, Mark Millard wrote:
> On 2022-Oct-1, at 10:47, bob prohaska  wrote:
> 
> 
> Wrong email for the patch in question. Wrong patch used
> as well? (Actually, the log output still has the high
> volume debug(...) messagess, so you did not use the patch
> from the email that you replied to.)
That's possible....
> 
> The email with the patch is Friday's 12:58 PM email about
> the patching involving 3 mdelay(...) calls.
> 
At this stage that's possible too 8-(

Right now sysutils/u-boot-rpi-arm64/files contains
root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/files # ls -l
total 24
-rw-------  1 root  wheel  964 Oct  1 09:39 patch-common_usb.c 

which contains 3 references to mdelay. 

-rw-------  1 root  wheel  382 Sep 28 21:31 patch-common_usb__hub.c
-rw-------  1 root  wheel  362 Sep 28 21:31 patch-common_usb__storage.c
-rw-------  1 root  wheel  291 Sep 28 21:31 patch-include_configs_rpi.h
-rw-r--r--  1 root  wheel  510 Jul 24 09:31 patch-lib_efi__loader_efi__console.c
-rw-r--r--  1 root  wheel  169 Sep 30 18:57 rpi_arm64_fragment

If the sizes/dates are right maybe I copied the wrong u-boot.bin to /boot/msdos.
If they're wrong a batch send of preferred patches is probably the best
way to put things right. 

> > In testing the patch thee seem to be more cases of u-boot getting
> > stuck in a loop, not all of the identical. 
> > 
> > The first in the script file left the disk LED stuck on with 
> > error 22 prominent, the second left the disk LED stuck off, 
> > with error 110 repeating.
> > 
> > The script file is at 
> > http://nemesis.zefox.com/~fbsd/
> > in file pelorus_console.txt5_concise_loop_fails
> > 
> 
> As I understand the possible result of the intended
> patch is it might avoid the "0 Storage Device(s)
> found" problem but need not avoid the later -110 -22
> error code related problems.
> 
> So if you no longer get "0 Storage Device(s) found"
> problems, that is progress/good, independent of any
> later issues. Otherwise the mdelay(...) changes are
> probably a waste and would just be reverted.
>

Out of the last 24 boot attempts there have been 6
loops and no failures to find a boot device. The
log file is at
http://nemesis.zefox.com/~fbsd/pelorus_console.txt6_more_loops 

> It might not be handy to test lots of examples of
> the "Storage Device(s) found" messages, independent
> of what follows each non-zero one. But that is the
> kind of thing needed to test the consequences of
> the 3 mdelay(...) calls.

It's one of the few things I'm marginally capable of 8-)

Thanks for all your help!

bob prohaska


From nobody Sat Oct  1 19:58:00 2022
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 4MfyZT4Dktz4dsRl
	for ; Sat,  1 Oct 2022 19:58:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4MfyZS2gLrz3F35
	for ; Sat,  1 Oct 2022 19:58:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664654286; bh=By0s1Ze6aXbYMkNUxkPw9h1YPYJBsL8jo17KPoceNkw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tBa5UGD1ZhMZNfqXgISZyi0ti1fqpg2y0J3CrZXk/JoOVslxUbc+j9kaCtWviu4/8kFqqu9D+YSjUD82d7sujSB36hdVoEFLiiZd4q/OeUSlxDNvpnBMergdIoesIYBoAUTErS/NDnfY9oRKuHR8X5k1rKo403OjlMAOxVkOsfrNIclkrC7WvNepPNM1/R38SVV7t1LfsDAjnMKh5kQ4VB+7rK9ZjyqplmZx1MG9MzN/NgjwkwQjT4iXSR4YjWEGu8I7mbIwgrAO9K4xJcHjA9zgpJGnExBLX9FYhQAXIek27WyVPpKvKwCbI8SuUtT1UAr6bcvpwcbA0B2sMTwc9g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664654286; bh=cl7dFyigNQz2uH3Np0uvJCPt/CsKGITq1k6aIusJ8yh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IM3wpn/sLhd/XgScEqfo0xULMcp2yXnrCC63UQJ5ZTk6sLReItlrHJv51TA9LxsrL8ZV3oUabB2rgUU63zfii6oAo2/TfOz3frp34Dsx8Lya4rM/nwxFSyD824dWIH546Q0f6Q9n5rF+w6LEn5KM0uW3gBtDvssCqQBsPSOsEVwYdUXOwl6DtQimaOOqRXK+AAmZ1vbtd9540dt5opE5kLjK7zVMAihAyiIDUvVmWO18rR/tMtQJvAUDtwWweSG52opasyatsPdNPkusXdn6iJ+nZCbL+LWyfDwKfN3FDETmZXggwJFn7ib7AM20j8dFwApKDkxbEVzoWGX2m5GaEA==
X-YMail-OSG: 9ZE2PN0VM1lP5aXaXA3TunxJkM3SHNc83HHXgWpApKIv5Nky0pWDCP.4SNLk7EA
 bV1ibL0aAmtM2usZr07hPj1Rtg02HCF5ZSYE9prbcUOwdX7_HZ2IEzMkpH1wxAAY_njAKIDghf8b
 BdYjitFALGvxnPoZ3V_mQRgiGfOxfOZ5vpUrX4UGgH891viYMM2LPvt8FQ3XLOTt.n9KPNX3tGCe
 w7rO7sA3DtUrHCim.QDjmxJAxnY4NBGUnlNKBF9QjxuUUIoiWXGxCp7jbyEr5aBSs4L3J_NZPRv0
 GkHd7t2gcTpyjMHrr5byiIHcpeoGwpWrHzJNXWCxK8uEwMudITh9AuP9sfhKfZNqxi3_McpeTJ.Y
 bMxoQrNzAXCry0pMB7wMMjsOUtuMEz_JdwoGTvEYWwyX3F34loFkPHHqVhvsWyHOP8DxNq4pwJxN
 G5yFHkl.pxPtDivZd7uGYMmdNw.wAyejYrXTa88OljRN9XuzdgQGm6zGryrBnpWJQqgvHir6U41S
 IHWG3u_4dBRUAI7ncoxf.mzqhq_DcOgZXD3NrcaNfaT_9rFZuUiYFpOFEyXRt.rsElsNmJzxdk4l
 E4CPOYqFn7wzh8FSSbqfaKNcsfw.6BDUj5ZraslYPaxn5NGln5JDRCg5dBN_TrdGYZo6o6lTRs04
 F5N59mdmgRcf0zJJGmWMAiOJn4mN_2ExGYfwOa2neMVTVYU1ljPN.FbQ3PsbLpQhwPrvHhVr2iVy
 MQsq.Yuqfs4t9osOoqdrHrmmMW8xUdIHbRTbe6LySlh5DK7YX89.UlG4QMkCFyQSbtnbbY0viI2M
 H7FYa6j5QxwnALOTJl69dI4FjQZPkCHaQf8kGPBxo.yUFjEWZ.paDlPLbkLtHefPyFzHW9rtSCMR
 zRu.gQg9rbttVWKTSg9cg0gqFyZ3nCPBDLNQhQ8j2JtkSF2c9sk8M7CmsUiV6JIrq.hOlxYH9hkZ
 .KsFGXMYJT3gzmpk6fVj3bZeF0SRrBnStKwSntLLOINGWZizkr7lI_UndEWPppKeIxLLW1wo0Ble
 j24F5P77OuovTTrd3jrvRWZxhjdUiXZ.HlabGbiZmweJaTd4UycDsRO.8ThBoQAphvkMhpv91zqq
 Es7dC5a8ztuZWPF9fELFaUBbavHXPCBzaCD7cTtB5Cz3I0ANvJ8uXHxdefnXz9G28oDWTWiEb_Fz
 uUyjrPQNiIhueQ3Km_9j5.3IZkp7bBZICXuT1h7W8f81Bm9m84Z1MRHdXuK1oIYn58O3ZAJ1tH49
 9jCrxtSoQ33NOn8uSRYGs16YqJBe3kVJVa_N1SCt82yMuN22b3O5toF8k9V0e6tUlSoHR3684_gu
 hfNi1tt.SHrFhrA3xP8useGKW9HIl_M3Y2UZS1RpjKUxac6Xl6P8sDzprUdm6PTmkGDg9p7dNMFk
 ZSR_6Jka2Rg0zna7yKFjuFmq.W3FIOE1BSwKcljX62w4oQXN_e89ndNNfaNBXNZ_jQ6ssPrrjye2
 L8dG6nHJSY7a8fPFz545kXVtvXLRyHJeke3LSOa2AQ59qYlN0.TE6W_IHC4pq4DyTbrhGZbaGIQu
 lr2E_phMurr9hAR8UyrRjcc1QuZRrTJWw3Ihhaaf4YCQUPmn1n.1kzciqgnT4YrRxKUBpN9pgKHg
 owNb0SPzIydzRYjZygaxxRENkQBcLv_nCjVIAmukbx8eZfWMJvcU4DwZRzBr8W_9iqUmmoqWnAQj
 klQ8uu4D7wCk1seaTHc5tzXhCFgv2QEZ72q4kR.Wmqq6Q_IAUSS4crZWaDMLqorxkez1F_8lYO0y
 kf3XM7rYJxPb2Owo4RIhp.f6MPpgz6HimCHTpanwy03tTS_DUvGNGmlkVhiGqSTmCEP9U_.mwx0H
 mEnAL5Kwfn4A0iewszGBaeDw8vUDYdTSSnWYNEUaj44JYD9iqZ._cEDL1.JJgh.pmI_PZ6d3lR0.
 ZQhjNSC59UuJE39T03xgRo0jIcD3LHP_e..9e_W9HpuTMoKtqWCCL6rTvjgP4qUw.McB9aQ05WWK
 dP4HXd6i4SbCgt5xnVJefb2oLGsGsB0gt_HXxa.qk61E6ejqOkDjvmwE66OMpMkGAOt31sXjniXh
 LV0_SIImapKKns5YaMQYxvutTLYUJQMyNIkogQW8R2800o1KGABUSCZ0TTNVygCjf4JJj8Hs5v9s
 CKvRGM1VzdYWKlfFyHfBmGv4yMRhz7.bQnjTm6V00m8hMwXorHC3S3anCammVdcz4rI39RlQdcAI
 yhammmxUCNdoiboxuAuLpLbA0Q_LsmNoyjm6LbmRN9Z99s_8gmwzUaki1Wbfm35p0xjoKOx0w8tS
 LlSk-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 19:58:06 +0000
Received: by hermes--production-ne1-6944b4579f-wdnx4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a06b490abc79c6960214c8de43b8cff9;
          Sat, 01 Oct 2022 19:58:01 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001193033.GA98348@www.zefox.net>
Date: Sat, 1 Oct 2022 12:58:00 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
References: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfyZS2gLrz3F35
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tBa5UGD1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@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.987];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 12:30, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 11:32:52AM -0700, Mark Millard wrote:
>> On 2022-Oct-1, at 10:47, bob prohaska  wrote:
>>=20
>>=20
>> Wrong email for the patch in question. Wrong patch used
>> as well? (Actually, the log output still has the high
>> volume debug(...) messagess, so you did not use the patch
>> from the email that you replied to.)
> That's possible....
>>=20
>> The email with the patch is Friday's 12:58 PM email about
>> the patching involving 3 mdelay(...) calls.
>>=20
> At this stage that's possible too 8-(
>=20
> Right now sysutils/u-boot-rpi-arm64/files contains
> root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/files # ls -l
> total 24
> -rw-------  1 root  wheel  964 Oct  1 09:39 patch-common_usb.c=20
>=20
> which contains 3 references to mdelay.=20
>=20
> -rw-------  1 root  wheel  382 Sep 28 21:31 patch-common_usb__hub.c
> -rw-------  1 root  wheel  362 Sep 28 21:31 =
patch-common_usb__storage.c
> -rw-------  1 root  wheel  291 Sep 28 21:31 =
patch-include_configs_rpi.h
> -rw-r--r--  1 root  wheel  510 Jul 24 09:31 =
patch-lib_efi__loader_efi__console.c
> -rw-r--r--  1 root  wheel  169 Sep 30 18:57 rpi_arm64_fragment
>=20
> If the sizes/dates are right maybe I copied the wrong u-boot.bin to =
/boot/msdos.
> If they're wrong a batch send of preferred patches is probably the =
best
> way to put things right.=20

What you report for behavior below suggests that you got
an appropriate u-boot.bin in place.

>>> In testing the patch thee seem to be more cases of u-boot getting
>>> stuck in a loop, not all of the identical.=20
>>>=20
>>> The first in the script file left the disk LED stuck on with=20
>>> error 22 prominent, the second left the disk LED stuck off,=20
>>> with error 110 repeating.
>>>=20
>>> The script file is at=20
>>> http://nemesis.zefox.com/~fbsd/
>>> in file pelorus_console.txt5_concise_loop_fails
>>>=20
>>=20
>> As I understand the possible result of the intended
>> patch is it might avoid the "0 Storage Device(s)
>> found" problem but need not avoid the later -110 -22
>> error code related problems.
>>=20
>> So if you no longer get "0 Storage Device(s) found"
>> problems, that is progress/good, independent of any
>> later issues. Otherwise the mdelay(...) changes are
>> probably a waste and would just be reverted.
>>=20
>=20
> Out of the last 24 boot attempts there have been 6
> loops and no failures to find a boot device.

Given the "no failures to find a boot device",
I suggest an experiment of (temporarily?)
reverting to the official rpi_arm64_fragment
(to disable the U-Boot logging) and seeing how
it behaves without the extra messages.

The timing changes from the messages could be
contributing to some of the behaviors you are
seeing.

> The
> log file is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt6_more_loops=20
>=20
>> It might not be handy to test lots of examples of
>> the "Storage Device(s) found" messages, independent
>> of what follows each non-zero one. But that is the
>> kind of thing needed to test the consequences of
>> the 3 mdelay(...) calls.
>=20
> It's one of the few things I'm marginally capable of 8-)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 20:19:38 2022
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 4Mfz3L6jW6z4dvbR
	for ; Sat,  1 Oct 2022 20:19:42 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633])
	(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 4Mfz3L1Vsrz3KF1
	for ; Sat,  1 Oct 2022 20:19:42 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x633.google.com with SMTP id r18so15296269eja.11
        for ; Sat, 01 Oct 2022 13:19:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=Vi+RBeGpXipl8VFlWAE3iF4cCp1pKku8zOjrHqLQIIE=;
        b=J0wLZ6k4zw2pdwHpfi/8VvXQt3RsFO/v6eR4KeIdZbo6CkuPMTg/Cqc0Men8tu+yfA
         kV7m6VDg4lXCDUVmu3C/G+/zfAvg12NRcIyHpyI+Ax0eL0GNCcDHyY/08CkC4V6s2yLy
         iRVBOiEpx4yz/cjF3ABqUfUpyGzROu48ZoUHp6lTbnZiAEOcryAIqVcryVNQy5u7UAca
         aYn3yfsU7p9EKGNUZ5WUu3sO13ha0rLM/+7UYybTRA/Q3re/Sc6z4K9eAWPMsn+/3Txo
         MyU8ZZSgY+m7M8iff+CC1S3VEidA+y2d4o5fozfbj9NPYtuZSCPeaQTm0fcZ/zLKn/xe
         fb+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=Vi+RBeGpXipl8VFlWAE3iF4cCp1pKku8zOjrHqLQIIE=;
        b=0fuDLUJQrnrYK2tsnTX4vd7t6Nd4cgs6+8BvyQFffwxY8Nwo/f36gERrZdyZAShaJ5
         ateQY+EY1Z/la4g84eq8lH6PYDGo7NaedCjgXaEHYoevSIdD3Qo1gGIVQGK01auS1jrv
         3nWixwt2nwHgd7TPUC5FzePP+qs0Sqdp0hZwQFJ6RTCqJQcfqy1QkJiydkBievXJE0W1
         mjokZpdJbMkco8Ixly+iQO7+8m2inKd3aDKW4V3KOnRNTxLOeisbcJ2x/VIRqKDDEVUT
         6kMukLNs/JizGBoBuFo6hoTk82OUxICnNnXJyQIIlW11YXiBaLRW12lOyYxibiuhz2uj
         eMjw==
X-Gm-Message-State: ACrzQf0IEg+aWr44IIfB1F/vg6OKSQTHxESuYUyzaZ5Etqb1/7YQ/y09
	zKsIya+YKqzxdPY4bjAvDULzjdolZcs=
X-Google-Smtp-Source: AMsMyM5G+0aF7RFBErnl2FxJfqowVcoyZHZ556RI/w+gVhB8+DSB97gcx1Sf3kpbO86oZF5V5yKt6w==
X-Received: by 2002:a17:907:6e17:b0:783:7839:ff3f with SMTP id sd23-20020a1709076e1700b007837839ff3fmr10493363ejc.300.1664655580827;
        Sat, 01 Oct 2022 13:19:40 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-026-059.46.114.pool.telefonica.de. [46.114.26.59])
        by smtp.googlemail.com with ESMTPSA id x2-20020a170906148200b00782e9943c99sm3039173ejc.219.2022.10.01.13.19.39
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 01 Oct 2022 13:19:40 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sat, 1 Oct 2022 22:19:38 +0200
References: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org,
 bob prohaska 
In-Reply-To: <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
Message-Id: <38FDE4AD-451B-468E-9CDC-4DF605858F99@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mfz3L1Vsrz3KF1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=J0wLZ6k4;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=maciphone2@googlemail.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.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 01.10.2022 um 21:58 schrieb Mark Millard :
> 
> Given the "no failures to find a boot device",
> I suggest an experiment of (temporarily?)
> reverting to the official rpi_arm64_fragment
> (to disable the U-Boot logging) and seeing how
> it behaves without the extra messages.
> 
> The timing changes from the messages could be
> contributing to some of the behaviors you are
> seeing.


You even take care of the Heisenbug syndrome :-),very good approach


Regards

Klaus

From nobody Sat Oct  1 20:52:29 2022
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 4MfznL0mvwz4dyrY
	for ; Sat,  1 Oct 2022 20:52: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 4MfznJ4ZZpz3LhL
	for ; Sat,  1 Oct 2022 20:52:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664657554; bh=1yqwpGZy7jBAAdw/PEuH63rIFn2FfzItgQ0dfbb649I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=b3FzyWwScX4gYOQkj6rnIGDLLjQ4ICQ1SUJVM1mJjQ/DG2z9z7768JQtWjyImaQaLY/cnjCTVIsk+pwu6lMOw7ZjpsDqak0Wg0P55OasAFo1A7OmgE9YFecKFSm1nOR8SLvXdnfSlvA3SNq+WG+IFnoQYMQPyY/dPw+Q/kXUqYxE6c9/eenq+3YBg0YH0TIKb6mKfczWjgSp2NLG8vLCmuSXTZemwiTVr9pEV4N3SjBy/g2ZVIP55/5Axx0aoIXRL1V7Yu2XWcTpp8v2t5C0pNQt+OsVQ942rH7lAsdX/VXXTKA7JbOrA05ep494fQMT28k2yZ8fB2CBeMGTOCtgTQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664657554; bh=51fhisQxKapY6xB5SjNuvhiOg2XcEawgFEQ3nBMuXSe=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Q7T1L9qH9+Y7aoqyCmhMBGIc7BtEOTxMmK8qPqw3egzI12E3mtnXJRTncCOUpFgI+yc8MojIMqGfCB7Rp7O/xgJYJzMeZalfQA9MzuMek3Vu+r3ZUk7szlMbNguBBCBrXJeGQtaIax1xev0BmZ3GWaEFizltBElOuCa441/z8gJepyfmQQbTRUfH4Ac/XrpWkyTrvmR4g7b06vY826FKNevW6Ac0XWtVe1PQsKcl+jGLx6Jj3ATanyNZhXwKiANeoq1sWkuFK4A1tFYwzF80aHljnHl5+BOIhWep8iEg1/f4ZIfPWUFKANLqPJNCn9zJsgyJz1iJojANTW6d5s+nnw==
X-YMail-OSG: DzB7QvMVM1klsF88MvFseDiV4YlRnqZm1J_1dG.Ais4APEuuhbaOfyE64f0c7uq
 vqQ6Y3AMg1W10ABhWnIUDtCBQoZpGrTiRahQnnzpGsZeUvwyeYU2gOvvsTg3BOAjY4qeaHAsK76m
 XU9SGeqYKx0unRc.lMS5LoPiKU0cFC09_Kpg_DFZ99ozgLAWFkewrT4qMjOBELdgz_mqt__XYFeT
 s1yoL7_m9ZjYDEG3Fgf2QihlF7r1R7gzhQCYg4eCwSef3Smh1f_Ndz58SCA8C55p_7mEWqmjvb8H
 wqF4Onux.4XhH0qRerEDuukXwSgdxYszXVvZDKmDxU53fjDTKjvCuX6xOO._2lvhdUe.kagvoqfG
 O.6LH5XZT.hIgKwNa03Rr2eufcOKPPrwaQbIh0T2fIvpQo2F_b1pY4eLt_vrQw28DfCiQByI82S_
 ZjSleQ5YeJEFKZVot_.uO_XyCfVDUv11Ye5RDF1wm4lzdRC1LzEck2eCE6vGQs5Yfyt3O6WHZ0as
 kIyYhe9NhyFMI48YcBHCTElr5GOmIlRkz8OvvTbKjbf_p20Od4gEvCpIrcOBLwtGlXVP3OMs2.gy
 mzy4.Qwwg.dE1tztt5F6Sn2w9SBR4NC_oQv7Qv6aj0BtZDClEubtCNZrQUgrXzW1p6C027xMD_vS
 rpN.2AqHChU4bbQJvjSru30YKL_x3ueYkN1JcnGFihjwVr8Gpx9gBocL.vcD5CWi.otMQ0JDBsfn
 aproylvJbyoG5H8hnJ4UKTvhqXDEVkSu7gj00ytK8LdaEBI7wziPtUq5A70GzrM..QAL._T2L8I2
 ilwvfG_n0dBTLgcKKtmsjtHA2BVgLg3ZW.M3r0VniRknXtZXy.9pajnAirKCmPgYA9IIBPz9JIdq
 s9A1l2o1IG5Mn4GD55rkYRUeYlBs_vGAjZO0f.WsCO2ZIfiw8N5avBGBHDjBQwEsMkpUO0bDEXp6
 xWILqRTYP9tMmapa3Iw05Rs8XbP1U8eZHb4O9HD7IWlW1RbEl52cd_lV.gdfENzNXzjlGQCuWC7p
 KwWtAz.NC8uNTN6uG3ax7kW1j_XJoVil0L5phAOPDaJdCAjlFI8TPiKHnWrKhWg8BODQueiEf7qo
 WuhwgICt5CPr7Gc1kIUsV0aenFrvP3TqPEweh72I.7PLypEKkNExlRDV.cwWCF4JJQErH0VZ_.GM
 1EXtCGoTry38HI3CGtFmPQ2qHHWt3zZwKzjJDYv7c3tHa1jY3jrdkJayqeFLQROsb6njYIJkrSfv
 GF0eDXAoG40OyfiLZwa4nOgtQ3I8ReVWyyTzuqPfsLMI6fuItt2Nmlp5L7D78m9Af_08hQOMCJ9q
 YoY4s8ePRDVV52RiG3IHVnJn2SXMwc2B5_cUMUAlDtfb9J8UkOQaOSdudFJGZrJ33XkX_Vs9FVTK
 jL03f0yTw31_MHBndNfQiQ2ME_nv65EQt6XaG3JGWtWn1m4sPLA5i__6pY3nkh0Tme9Wmbjz5bIR
 4kqzqC6w0ecJgr4JTCthaPu1Zr4smRmGTixLdLm62BTyc6mtV_NVJYRHbSfU9_ELReqoAE0t85AK
 89MpJw0B4G0biIWuDs4bx.YO3MMDf7xKRWi7Q2fLtoiXrqLBbPpvmKrkBbW_SIVIB4p7hmbjA2jC
 HZ3GgGsnR9ZpMnNRl.tklvbLh2ZHyd_Eo11QZmJo3kgWTLc.vpIgGgNInQqDRa.GNGu2.g1GoX1N
 5yo6lEbVN1fGyJgt5Kvfc6EwRJQi6KC1Wb5ZGL4_xcpqJT2KReHS9XYBuebqyaBSVSi561aUeSnb
 V5UShvOSqeRxdoMFokshsqbP8GiO8aFI.JbDgYMuOlO6N.ZyFbajLVeNhWPlevUc8HhtrvP4mqeu
 p5.M3mDAff_gtfCik7gZaaz2ZO1YuVV0uesy6u.cMAjkRkszrG5q2Ee34qYPwKGe5iYnsv2Yuwds
 p5rYD61QjjMQTn1tu7whTxREcQQ7mPswcn.m4mIulckw.AR7qWV1i1aV6daXn3UAcS50sTyhUQsv
 kBHnXXpKCySwR5DEfyhIjmvasQTUb4cBUyLQh.hCgngUXHEHXW9dUFCkqwjtJBL.p7iRQ31OhYio
 q1xX.ZkWyGUh0.yaeMM4WJQhqJEAUaPb10rW795COmFNcXcoDbNyvP.uMfpMMLKn0afYTexnEAxL
 u9Km6gBFU8REILzCKYkjJItU4SSxwklmJQjUEaRf_5St1eeWassr14PltVidQyUV3ki4Gi_O1W9d
 2bv2wHJ6Jf23.1RQdvISrC6T_.Y9wQ4Iwk.9HzW1VmJnGng0vBYb_UYjI3bE0kgx0u.ANiCeng40
 84dE-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 20:52:34 +0000
Received: by hermes--production-gq1-94b89944-tv947 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 500e4296ec3a97127073c9c1fb5a8fb8;
          Sat, 01 Oct 2022 20:52:30 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001184258.GB98055@www.zefox.net>
Date: Sat, 1 Oct 2022 13:52:29 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D8DF7FD-73E9-4DC1-9CC2-8B11F477C75E@yahoo.com>
References: <20220930002742.GA81169@www.zefox.net>
 <7A431698-1A8C-44BA-AFA2-EF5BAA69574F@googlemail.com>
 <924ED901-F9EB-4CFE-8376-1C2653FB6EBE@yahoo.com>
 <97AB11F6-2F4D-4026-8A96-50FC68B6EF8C@googlemail.com>
 <20220930214234.GA86711@www.zefox.net>
 
 <20221001152242.GA97581@www.zefox.net>
 <51B729B0-3792-4870-9DEA-3E47F8BCB37F@yahoo.com>
 <20221001163323.GB97581@www.zefox.net>
 
 <20221001184258.GB98055@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MfznJ4ZZpz3LhL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=b3FzyWwS;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.79)[-0.789];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 11:42, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 11:08:05AM -0700, Mark Millard wrote:
>> On 2022-Oct-1, at 09:33, bob prohaska  wrote:
>>=20
>>=20
>>=20
>> I'll note that the:
>>=20
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number DD564198838F9
>>=20
>> does not match other log files:
>>=20
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number 000000000000A
>>=20
>> but it may well be an example of garbage-in/garbage-out.
>>=20
>=20
> If you're comparing past yesterday, probably not. I tried
> a different enclosure (same make/model) on the chance the
> first one was somehow damaged. There wasn't much difference
> in behavior, if anything it was a bit less likely to boot.
> For present purposes that seemed helpful so I kept it in place.
>=20
> Apologies for not mentioning it, I didn't think anybody=20
> would notice..... and then forgot.
>=20

Your two enclosures need not be strictly equivalent . . .

Original:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron SABRENT (0x152d:0x0583)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron SABRENT (0x152d:0x0583)

Recent:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)

So there is 0x0583 vs. 0x0577 for the product ID ( same vendor: 0x152d =
).

You will likely need to validate the behaviors of both.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 21:21:42 2022
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 4Mg0R21dJCz4f2MR
	for ; Sat,  1 Oct 2022 21:21:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4Mg0R12gGbz3NZx
	for ; Sat,  1 Oct 2022 21:21:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664659307; bh=+v/ckZj8kJCcZFQoDp1/1NVpxM2aI8LfA43AH5wXOks=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=s8Bl8G0B8MWWxgm9J11SGhI9khGyjjyp8CHG88k5p5hfPG6gllCw2NEmdBbnu/90F+bX8vA16aJr8alGoktUqwmFvdU8WUWvbowiQqfMRNJIrv98Rc5Fe+k5GP0Z7ll9oDQzvnv+U0sOpnUd4oVqfIdLP2ifu/nTBp5ZbkgMjCYmrBBdQkrn7smKz34JNskH0mGMgzR4tEzRlpSRrtQvOvEwGpLeLemYsj0OJmA4VG2qAIhS/Qx5zLQgRiUUz+qhM6MnZFMZUioSvDjGG58H4oo4SMU2MtfnWjbOSpUq2cupd+MpZkQfcQ91dZQpuWY9/WcjNzfgdJww6OQPjwCzJQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664659307; bh=RKN3oQifkQbOQOCwxGbnCOsYCkwAc/QNgZAqZFzuL0D=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QeVpT9wf53KQrNFWRJn7Ip9J6JC/VvP32T+OPP8XOdlBiuAJfRFWvY/2iyJlnNgjetip30Zk3qe0dIjRxpWOV5q8nSVFDWXaVd7c2VNSuwR8uJulV/X4r1k/XZuoL/bhkSpTim5UbwvjrZvwAL7LiNlHHhBWFZwYMHYhoH1qVFZTR5R9P6I+xoIkfaW/ODsYP7TINzjWhVCOxp/skfy2hhMQ9r1MMZcc2AozEU3kc9js5LyJ1JfZhlFUHWCENoPVvLT1CxsQM9CqIWZNPNKT5g3Zj9fVIcLHK9pgQK/T5atI+cla1yqB4UeWjxrx1nXD2vgUDl5HT/gMl3kbq8N7/Q==
X-YMail-OSG: tYhAH3cVM1kUjIauO5wRGeCrSMKBwo7kOIkAVOzWEDyYkZXntlikzmulfRydVYi
 tYPMUf6rqfiTRg6YjAurE1GVCQ8h3QfEAnnhGUfjkcSGCQOjFwIOy9rtvmsnISjLSGTANw8WYQey
 ow56AZY2eG8NPbVMlf9clcEopkHHubqxq4dQtaVJ1An9jLqmdC8LBlv_3xEyLHqcSIthRnmT.CTW
 gHwVG5cxTNAA8TSM.Di5FLHVp4xUZVgHxwQ7MiRRUerUVJAkMMvtXdmD31hTA2CFJ_tBFXWUUJeW
 Ko1EngUvlH.wvrAjf229myUmEg3PTGsSY2gNkdPMuzfy0oeTCAxeGbnYc94sPjXMuxP.nzj4vW5A
 0xHnJQIkSwW4iq8VOjOkdKQl7CaT9FK9tjL6NWNcP8KchUMw1jsUF32J.sEiNmH9WmjEfLp4nGkZ
 3JtXZQVeGp2nXUM3HRNkp6kuyB7U3W5gFs1QhY3y8uprM.YBFpu2Pvk4RYg9o5bxX1zV21mx0equ
 WEO5jz8kElUGOmGbJMpqN.p8JTVlLvDCwdKDfKG55aDEKWaJDUMRpxHPYOLxgqYY8Ptua5xT.y_T
 pAn.frznOQYYqXWgZcoPj8XLTKSNl1ju1ltROSk_42lDWHLBXtM4ZwGkQPK.Cp27BWu9rbbhhdhc
 ZgScbhryqBb4hBXQQnPObr2IyERJ9GZ1jV7VaHyEdeWbaclhSTLerGkAQMLulXKXtItE1b7MZE76
 4wELQvpXQQWf.Fdo9WD2tFd.LcA6eq3G_6JXLZ82.b59i2Y7FL.EAu_LE_0a5.7pwMXcQdjQr99f
 _V7BQnY_eB83YH8_RL8.AGEaJTW6JipllOVRSzg8tI_Wo1au8GdmForUD9kzVFJI39IkHaSAIluu
 OLFa.InaWEO1tlbfVA.oK9RbqIvvVYRaTTWp4pIYxDmEzK.EnS1jwOIcng8Qc_7bjaqcXMllCtQZ
 CSKmkOyNYwl20_yLbYTOzR03BGF0yC_vrPm7LdLJbszfxAf1WHsaBia1bhD0wyLh.EZenmzIPB91
 TXDh5mjtiy7jq8mP2kB8YYieJ69crrnwU2qautvgSdnd_cNX82mC4Dn.5S0lmprzLCCS8Pay8zXB
 5ZUojoQ3UAwiVeT14rWR.OXFbcoRm1B.dzi7KL.qgjzxvzwpnAYfQqL2YcgosRqOQIOe8QP.ojM5
 5R_zBhl6LtF7M_3oWB5S23JMxDT3nW2Kk9ooThZ4oChiM_6Gnl_RPK7.hGojaU.0jELvYD6D3_9z
 rGxof5TmtfG7_jwvjRYViPPoyVlq1D5e28QfU2IaYo9rNseQ7jrlZ1sdaR_bftnozizInsD4VmHa
 txGUqHzv2WvCcXU4cUrhFk1i2N6s7xGaAW3L_qpq_Tj5LMIiC9y_RXnKti9Rss2d.4Rve3W.GmTO
 Pt7Vw1h_9PN52DkAEHGi7uVg1zPbcez8ULLV.GG.2YlI2BP3QP7QFgEEqRFp9E5PCisxpwki8v8h
 rI4cLUR0baGRVyqNQ7gb.YftW3vKODkEGeTl1WgmOulixBFyFM_1jSOsYstYmFRu7RZ3E_CN2sER
 APVJPGjxamTuovHb9XrXJ06pa3pU7HyDVUX47RgVV50cICUL1bPGKI_wUbf1LmSnTVE5O590l9qj
 x.d0Q4lyE.VpBYHdfFeeJbHqrdYAZpUkSN.so.hH2NjPc37FCGDDRQNoAbqcGbKelCqJftQynLB2
 dShfkZiQg5W98DPOzg9nMUQQgAYKgxyjLliZwhUAfL5GTaO.mwd9oP5Yu_urRvXqLTXxYKwHNba2
 2wJSZSwNsYVuBNo6GGvNiOSPyDenYy8vg1m0q.pPLoQTPMCj97vgO7tmBuArvS0XQBEIfM_kRsn5
 GyvUGEJY9i6l5oVI05qGulvLWggQT74qd3rdk.wF5B3mzjOTxru6DYm_KQy6sneGUVZeULFXdvmf
 HJfSvkasF1S3tf_oL4Qc9VKsT6UJzMk237.MhyOakQeJXDthpzeuWG8gNlYW9b2c7R8MbzHLQJwj
 r_n9SlNzbSWuJCcMhdbNo72BM5Nu0Q3RV1rpEmS1gceBI3nzSzJPX1dcHJGFoh3PeHFuHWCrcRU7
 1vGLZl.ak.yLbeB_CyEN57RMeQX6Cd9WQ2QSchiwHpZvX53.BzcFOXe63b_0G9.ybkUXI_YQqp8A
 MJgwfM1PuIcbFkxHl7jYloCXRdT1KGXanzZzA4OGEtpWr.hmfbbnpnZPiRPFcBymxKS1_sGHnZ5M
 VwNuFJC3fa0EwSEpIgdcteNtvIEKwcYvdrQbjHkO4BFUOpKTYpzedLHImhYeCKbuYdQSBbPAd0Wi
 QMpo-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 21:21:47 +0000
Received: by hermes--production-gq1-94b89944-plgtx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 04c7b1786ec4ead2bad9997172d8f3a1;
          Sat, 01 Oct 2022 21:21:43 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
Date: Sat, 1 Oct 2022 14:21:42 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
References: <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com>
 <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com>
 <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mg0R12gGbz3NZx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=s8Bl8G0B;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.985];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 12:58, Mark Millard  wrote:

> . . .
> Given the "no failures to find a boot device",
> I suggest an experiment of (temporarily?)
> reverting to the official rpi_arm64_fragment
> (to disable the U-Boot logging) and seeing how
> it behaves without the extra messages.
> 
> The timing changes from the messages could be
> contributing to some of the behaviors you are
> seeing.

http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment

still shows all the debug output. It did not
avoid the timing changes.

You might need to not use either of:

patch-common_usb__hub.c
patch-common_usb__storage.c

and to disable the LOG_DEBUG and DEBUG lines in:

patch-common_usb.c

via turning them into comments by adding // as
indicated below:

+//#define LOG_DEBUG
+//#define DEBUG

===
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 21:21:55 2022
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 4Mg0R55Pthz4f2Px;
	Sat,  1 Oct 2022 21:21:53 +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 4Mg0R44DGVz3Ns8;
	Sat,  1 Oct 2022 21:21:52 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 291LLudF098827
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 1 Oct 2022 14:21:56 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 291LLuJw098826;
	Sat, 1 Oct 2022 14:21:56 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 1 Oct 2022 14:21:55 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221001212155.GA98793@www.zefox.net>
References: <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@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: <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
X-Rspamd-Queue-Id: 4Mg0R44DGVz3Ns8
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-0.70 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.97)[-0.970];
	NEURAL_HAM_SHORT(-0.63)[-0.635];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 01, 2022 at 12:58:00PM -0700, Mark Millard wrote:
> 
> What you report for behavior below suggests that you got
> an appropriate u-boot.bin in place.
> 

That's a relief!

> 
> Given the "no failures to find a boot device",
> I suggest an experiment of (temporarily?)
> reverting to the official rpi_arm64_fragment
> (to disable the U-Boot logging) and seeing how
> it behaves without the extra messages.
> 

Done, using a copy of rpi_arm64_fragment from
another FreeBSD box that's dated April 5th.
I didn't think it'd be that old, hope not!

Out of 14 boot attempts, about 7 ended in loops.
Only two shutdown -r now attempts succeeded. The
transcipt is at
http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment

I'll resume experiments in the morning after checking email.

With my thanks,

bob prohaska


From nobody Sat Oct  1 21:50:48 2022
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 4Mg14Y2jJmz4f5Pv
	for ; Sat,  1 Oct 2022 21:50:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mg14X2cB0z3Rch
	for ; Sat,  1 Oct 2022 21:50:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664661050; bh=ZM6KWwiuH4wNEvbNeO7ZclfVIQXJ2XZH0NiVEVbt9WQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lJF45hlL7eiNdeaAfnJ4T5Av5jYm3+bHWWf16wNxYuu9AhxhRM3aumGewAnMIxPP9J75zY20vM5ESwfKBGGAWX1gQCC3yxQsnDByz0FsBXSWyzfXlWYdd2JdH45qoI7ggKBujnNa4aL9B4OS+KxliCzDiTm3BjEstuCpGUsCGviL6JXEF+8z3ryQF6gV1js6QdSUQzavy7CrFNZwptba1T4A0xb7pood0xf+MkJ5Yj6rSy9k/0G+ZtoffYqe2bX2pv119klM9k28Ce0HUWoKf8d6y/rxUNm/cu+BkJjyU5e/V2B2Ssx7U+Of+edrXml9QH+a04Ada+tO6CuUcKOQhw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664661050; bh=FKgl28QJPA5JO//1K8mQSnNOGPwZf5VqlStmBm9vpeh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=O9Pw5OgBMFQPvsAcPJRE/7IWIXi2uwUlZ5ATIdmkp1rMP+Vx0d9GSeOu5QaG3n4Pgq4r79eMOiLYHPYDv9N/aEQqbQDD8ZRUpeuAIvNhHwZLORTur+skUvbpW8+0de2PJ1HGxAy0Sa22QrfEduvs39xjRtoullP9jXXG/pepdVcBYhqpMv+E/zivI0W3JAXWBYu9np00cdA1Q43T+fL75lZ91HQRX96EIiICI1VVPSlA+VKLL8YR2ue9lEq8jns2u4BTEqtvJTioginpj/VnI8OKYgL2nJrz5MSesNnt4QLMB45qbyMTIA/kl/80/sear0i9qmiLcQ12V7XATSHPnA==
X-YMail-OSG: KVqMo_kVM1mDbe.EDqhGfv.2gYpoWDpAxXVBGz6dTDgI2mPAZmGVFLSEr3sDgwW
 cVMbUEk.G5jE6Acvi_J7T6.q7qGUJ4Wf9w7ykpTpL11eAlWrgehqOi2EVdazfJP6OTROvHZaPGzG
 gkP6qkR7xtFFDfIcnbPanEKCyqpjCqB_h.M02UiNAusFoe_8yzylECMqGCTUvpRRtG7mm0iglR75
 XLxpfCNB0MSqbglNRgT5XLKSbCo1_fdAStV1sbAqz0xF32tdi2GNf821kXD.m04T81BLZeKOE0VK
 EwWoy7_2ID3dQ9EbOXOCZSj48d3p1WcZxggS.C5Fhn.Yf2uQdoPzTFCVJxd6k8LhSKDSJL_OUtPb
 HVC_PlavaIgIE3.JCbzKdDi6rHoJKnSlbcFfGuS_DaPD3ZTJfQRbx_XNAL.dD5_B9AQIXMp3pAUQ
 f582TV9gO4cCLwQTT132xrNk35vcB.BA_XbY2R_aLPy_F.FxBhMBbQhU6H1eEThGxpZLt_9mo_vy
 _EUlqP4Qz3zLAAsrN5gjKYQ45C1oZek1uHayMqXLzWPb4Cj7WTJObnb3xIR8TUpeoh.vhVwj2Lii
 PEVytcp04pF9oRsIaaZV8X88r5YGQQL7nHPPMJjgqzHWTvOxDIdtRD4fs3n0OaB5.x2W9MVEyZe1
 A1b7Rfg1iXFewrHutxs59WP_zlGAZmXbHKv_hcWZqkJlm2V0V3yCe_8kMjhCNh50PsVATFoUSX4S
 7c97m0nOUJLwC8390n8XsHN_RNCES5SneCKHv58XH0ddy1W7f7CNmCIuwOn739GaGPfvwR6SV0Qf
 JK1NTJGEQ6q3DNIOAVY9lB_59bRVOr1wNaSSxqqr0odDoUX0YLJuhH5YraV..wb7FC8wO2Hw4woU
 _kb8tQvkctHrXlStFzTciPN8YIhBCs29L25tfEetvblEqvbkwAkJDsv.h_sFuxsIjl6DaKiypo0t
 uLJmr68H7lmD4j_YFa_Y13YEsao2i7eFV6c4wGa_fVN.paFUgs5xW_wHBo9WoUTyE6.7WnenQLP1
 b8_Ox.L2.HqjMg7dYyRrJDU3Wp2FCKa_MNbncBuJtuzSLHtFFcxozYonmm46eAPC83Wb1NjQC1aw
 t_U_7mcxTbMf0bzeJ5iYBwrISJQ_IZPTCl9Y_vvtVktYPhAUGpjgwdDgpJa2hJMQjZTuA1corDNh
 8etJp8s3euxyVpkHg_CKWK1MqQT5SWDSibVc7Lud_maujKjrRGUmz_8PruE4i1wwpiWlM_rWs.TF
 utioogsSO_vt6phCvjdJjeuBt2zKs.AY3Xa8rQNUUmRl3VqGw8VHU8db3IZbYe5piWg2tCLkS2Lg
 jyIRVfZMvAYMLkFmElUk8JL_vBBLUHSl1QV_xj9Y3Nauzqzt5lHMCZquurG.pb0Lh7wQrVkk8ZbT
 zPlZ4OUXQs_wFeoXFrMNyrXUF0vJRJmYXnBNrJ02RCWK3278hQACBjgbZVoPJxomuB7RBpX1G0gk
 2QkfEZAl4WbXuK7Y2L7E5NUo7iC5oJ0PNTCV0fnoPELsp._DTdVPjrteA4G237mioPu2hMNlGW2i
 l8PcINYnMnl_S2C8.znmZCdJ6TFTiv1sHpM7rUL_3d14osUV4QdzCH0BUz4a.dlKu9YHBF0o2pCa
 m1mmS4z2zqoZNdo4AKqmv_ms1pmq9n62rqaE06OzauLOEqXclLCYgnMtqBL6NduuKbjmyKhl_OI0
 DdJQJMJRZyB5L.dK.tIgpzMAweBwv8QsrWiwLT1dn6k7zFS527F7szL1c7oYDqLbG2EeY14RWSCJ
 uUAuotN8SAS4Z05IenpmByV30nn6JGAxJTskNt6io9N4FSTvP1OCgwK4LODNv3cjf5UC6BkuRPOV
 h8HLL4wCi2obTxU4ccE7.HNm6Vy0WtkoPinRt.1BXtA8jIHQZyc0QYw98WKkd3sJA9ZcpDZ3Z0.a
 Gnd20kfYS1Mpv7Mtn0GEH0RDGL.f2U5tsQP0mRJfL3V0iKxuL5jNROGGC_GlOvIaS8MNuodpbQ6i
 _iAdg5o8jisVzFG6J6VSE4Tkw1JV_U4fqNP3l_xt_3GxCuPbYTUcQRwx2oCHrgaIFUVF7hk8GH0S
 TW2waoztNZOGlaETu_Vx_rmUNjyhQ0rfjP_u2XRfzNrzrmOr6wjW97LvXnZbssLZsegAqH8Xpc5j
 vm1j1QKh.zoDvX0EX1f5BoOIY2C6kuZSTr3UbgUzmHIkcrMjD65K04M5THPW2qPs36v01y4HjI.y
 VFU3cEXOvgkCEKbrqvcUlN3NvNUDJZqY_1lpFEN5qOMeTxE.I.6liJk0SrQME.LTy.DO_LcpM2hk
 71Twj
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 21:50:50 +0000
Received: by hermes--production-gq1-94b89944-jf4gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a1c5ce743bd02c1819336030f128fdb;
          Sat, 01 Oct 2022 21:50:49 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001212155.GA98793@www.zefox.net>
Date: Sat, 1 Oct 2022 14:50:48 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <20221001212155.GA98793@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mg14X2cB0z3Rch
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lJF45hlL;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.17 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.67)[-0.671];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 14:21, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 12:58:00PM -0700, Mark Millard wrote:
>> 
>> What you report for behavior below suggests that you got
>> an appropriate u-boot.bin in place.
>> 
> 
> That's a relief!
> 
>> 
>> Given the "no failures to find a boot device",
>> I suggest an experiment of (temporarily?)
>> reverting to the official rpi_arm64_fragment
>> (to disable the U-Boot logging) and seeing how
>> it behaves without the extra messages.
>> 
> 
> Done, using a copy of rpi_arm64_fragment from
> another FreeBSD box that's dated April 5th.
> I didn't think it'd be that old, hope not!
> 
> Out of 14 boot attempts, about 7 ended in loops.
> Only two shutdown -r now attempts succeeded. The
> transcipt is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
> 
> I'll resume experiments in the morning after checking email.

I had sent a note about that file still showing
debug output. The experiment needs to have
no debug output but to have the 3 mdelay(...)
calls in question in place. Anything else is
a different type of test.

So you can look in files generated to see if
the debug output had been avoided. (The
status of the mdelay's is less obvious.)


===
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct  1 23:59:53 2022
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 4Mg3xY424Rz4VBWP
	for ; Sun,  2 Oct 2022 00:00:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4Mg3xX1B17z3bcD
	for ; Sun,  2 Oct 2022 00:00:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664668797; bh=U0pill9WOYvru5NfPIJt4I8tUJDMu5q/RluBDb7PPPY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z1jOMzmmQJeEi7meqyKBQZ33hIWGs5g0XF3BfqLgSEhqXRkesQgSq2ppIMYEUpPawyeiXx3wkbiGZwvNJVNhjxvI58F5RwsyO651yAz3uvQnOctkckBJ/7BeCA707V+hNv5NhZ9HQnKanMSnPN2YQT0V53arwMnAeAZ+FEYxB/JGCfF/KcXk1zLhhAZ8OrCngvqFEBmxbIvVgXdfnUb22n6KZTx7Yz+DBxG+P7lZyTtrt3Epi8yrxja/gcktRzvSL2m9iCZCQ2K9wr3OIrtRPIo0qv86iXRizVCUifJJSH5AsstVZv5If82qf8oupPImwLJJ0qNyS3pAX5nuwzBFYg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664668797; bh=l9fHSTMuk6SNhKQZsJ0nZwfxG6oc5jhaaRGcZxvFDcJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AfxsG8BV8ajvLVajjKcuxiO4+9ObFozGTPDC3rX9+lC9J0/z0D4EnHIf6Jj8iPRfAlFpNn0zcF2dh89KbWqTHzRlw3JN4fWtgSQjuhR85NL7qY0Hz7CJZnhUwUiKB4tSvjGfThjbtZVNulR29ZvuynfUucqAMPa/LLnEk95rZ0ypnePI7pHThuuLK6N4W0xvdzpbHNjSWSP0vZd7S1SKWyccrOw/vTjNQmnUFGxTUvG9m0cHzzwyaT3xywukhA2NiwZNU4b/GuXG3uiFro8jnscXA5quFRte4hyN7WaCu8J/DEOgotjhD07rILK3NA2ZaRc4gTQGk3dRrKbBH+holQ==
X-YMail-OSG: Ez7cvxQVM1lDFIKRaLzpQUzk6ERHTF3fErSInK5Mwxv3MiyX7NTO9a1yrCR0dz0
 r6VPAfXcUQL9g5ygQu8K832mngVjfZTgGEvJAZApV0XOEXqkR8cRuDsDu_PpY.4If2s6kG6S2oEP
 sgx2EaE1RzJNKpdlW03nP4kQVyImjDEjs1Y8Y9cSU8qoBs9evXGsd408bZiowJ16GjL6Fif2PM4W
 2Ms8rUIegEAkTzUE74SdoGng4k8HWk1caFtV5CNJ3y_tlqueQzJOlL_A3hqq4Iud1MfDucUfjidw
 yRMp9cVfnlFCbjKUrZvULf1b4iV9TSXjjf93p708ME.A.xmpdNhZurLlVei_65LcJfyMfExW6AHQ
 jPMYM1oIfeSmEJXx1PV6MSA_5.0bbFEBmLk1S4eHyczZGDLjZ.IBbyyYUymUoBxGVH1lrY4zPYTj
 zI4SloXSCto7G7QnFIOfQ_j6GsiSwTRS6.bv2NvVfLtPTt8CrHrndoUwAYk8wD66ctexBAHW.J1A
 6l4EeFS0.KRmRcXepmazR53ARV5UgzDM9Id7kk1wa9L7xPlvJL_jaC_WfHnal0z9GDAIDowoeVgJ
 KCXKJnlTuRyUlzNKRIRpzqHuZP6Wq2H02l2Ce58.WIte6_.ZISW_rlwVg6wb6jLXAZPdAkmsXYlN
 kvrtP7Ue_IyEN762AkHP6v6C9jAYhRJV16pME7ee23HJTzmWetX2MbwbSwfQMKUXBEbj5xav9wti
 SLTuVlBmg2i5Ja_gXbGapsvVTu.2VTKR2ugSP5OV83IhoQE9UyGYkiZEav_6eOIUZJdtK7zmSBLp
 vW316Kj1mpFy.UawVeuEnT67L.FyUxmjTgPTQZy85Nxbqb6QnWJXtaRupQ7N68Pm2atbNcpH_93L
 _5VaHOAxqTaOzJH_ZjHAYVR0sPmI3E4ZS7M3yACmloYl.pLjMYvbodQVHPHavxWAhiEfmeEJS.TO
 rfNpk9s01egDquH.DjkTPNoRN86p.q8Ob_LQqy6ZgQU53Sdtip6eK2RbWGRxnqPqTobnR9N9e6TO
 lvJyAg0UGaFgDyfsaGzOlJKCrHmRz78PXQ7xJayyi93WZ20m5rTtWEkAWaLQbVzNPPnjfmsBiCoM
 WDJuollS_am13z0TiopFMOstFlqpJUP5M7zrp8VnN88Ofkh7gbcsUFSIYahrTHCGdZawU9OaT.Rw
 jlbTIHVt1LKN2i5BtmrcOYiOW7x3WdNyZbyra.TQA1z7Z8sZxifQp3NMkjLgmZQ_d468rNVEAW28
 kT7toaIhbeUnpQ3M4Ul36WDYl6.s2u09MZ0XbG9Ic9ZX5WOhjc7iQKfSSPV1BQhQCiRVctBoq0_T
 prv4UT0VVzeNTLEBcf7eG9xkAKf7wOIFFUkIt6MrbBPbHHT4xGi4XxMqWX3gQ_cT.osb30EFqTlt
 xGOVcIDZ0ti0mjkwlUHMZ9rbkp4Bp.l_46E3q86l_f2KvU9NDE5IQYqnaFNwpLAc27VbYtdxtCKe
 PsJMFTiwSkBrMAr_O9Ea4Falmg6uPJgdohx2450nLWL1uvaa43QF_yGdmZt5vVBiLHviSBN9mhaK
 8rrkcCnF2eRyWPtR.0eSzXKM2hy8ccm5Y2yjAkCLGxasaeI3fI3rtkaAhuQmaIYCbze7aGLgf.ON
 2zRlWJbuxeG6tExl.VVBa8XRj1jaMCEAxfc5Lu1FnWNWclvZH21vzit5gEWG5AmyaqMC869XjLM1
 3DSsCZjlERjUQHcrY7mAlv.0.biaj4Bbn9dSVc.5vU4r.F8vbtdRaOMnV8xtU4cMCcE807cI_lzS
 gfUOJtuh85t9cXMnKtQvjk5yG61zCbXtTyfn.Vqa4eVdyhgKEVqbwPWE.UGU_qZLaIpgXsEKy4JB
 fXTGLlC5fE4aT2TWc9FzWWlGcXgAeLmMEobsD9af0GSJ.zn8MpDJrHQw5yK0A60LaOkSbKmjAuUU
 0_beM_MNpxbPOOuN6LFYIGY8sAfLhpQ0ce0xurh5yuuF111nvCcUW08kL6kqUQBWo8fBroW2Zb59
 tEA2O_EJBuvkpgwmoDnZqM1g9DB9DRFmmpEl_vAS_Y74SkTKnXOidgWOC9jhy2q1FP18ZxlcJ3nl
 1JIaJw02fhxHVO8aNOrOz1pG48ysiMtsOx2cc7CVSX0pKiXesKWGg4JBMPWk8Tkwp.QThLrHNjGz
 0h5goyE6Wrd07WJND2ts8Pg8wytmniWc0_VMWQ2xnD4rxEhp9rBh3vzL6LfEARtzOKuaJYfkICfa
 fqfjd4e77qiccyQ9c4Ymo7p6.UV5QjJy7cFB7cxVycnctCD0aK0RH7ON2j3oNH6B6afUHSVCuTzL
 IpLCpmMR8UYoIroO3iSDgTlSpF5bX4kILMbUNULMYiu.Nu576b62v57aIOhvp6Tv.YgxoIIgOkje
 HXn5fiIxipmoY46GJ
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Oct 2022 23:59:57 +0000
Received: by hermes--production-gq1-94b89944-h245p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c189a02e8bf1b9d8c3936793582dd0c8;
          Sat, 01 Oct 2022 23:59:54 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221001212155.GA98793@www.zefox.net>
Date: Sat, 1 Oct 2022 16:59:53 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3302496D-A3C7-486B-9B26-92C82346EB98@yahoo.com>
References: <20220928234341.GA77046@www.zefox.net>
 <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <20221001212155.GA98793@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mg3xX1B17z3bcD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Z1jOMzmm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.995];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-1, at 14:21, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 12:58:00PM -0700, Mark Millard wrote:
>>=20
>> What you report for behavior below suggests that you got
>> an appropriate u-boot.bin in place.
>>=20
>=20
> That's a relief!
>=20
>>=20
>> Given the "no failures to find a boot device",
>> I suggest an experiment of (temporarily?)
>> reverting to the official rpi_arm64_fragment
>> (to disable the U-Boot logging) and seeing how
>> it behaves without the extra messages.
>>=20
>=20
> Done, using a copy of rpi_arm64_fragment from
> another FreeBSD box that's dated April 5th.
> I didn't think it'd be that old, hope not!

I'm confused. Something like:

# git -C /usr/ports/ restore =
sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment

should put back the official:

/usr/ports/sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment

content for use in a following build. (But, I'm
assuming that you use a git-based way of having
/usr/ports/ content managed.)

I'll note that the file has only one check-in, the
one where it was first added to that port. It is
from 2020-12-15. See:

=
https://cgit.freebsd.org/ports/log/sysutils/u-boot-rpi-arm64/files/rpi_arm=
64_fragment


> Out of 14 boot attempts, about 7 ended in loops.
> Only two shutdown -r now attempts succeeded. The
> transcipt is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>=20
> I'll resume experiments in the morning after checking email.
>=20

There were no examples of "0 Storage Device(s) found".
But such still needs testing without any U-Boot debug
output involved.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 18:20:49 2022
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 4MgXMn0NRqz4V5Dg;
	Sun,  2 Oct 2022 18:20:53 +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 4MgXMl2XwQz3MJt;
	Sun,  2 Oct 2022 18:20:51 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 292IKnCS002627
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 2 Oct 2022 11:20:49 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 292IKnGd002626;
	Sun, 2 Oct 2022 11:20:49 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 2 Oct 2022 11:20:49 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221002182049.GA2255@www.zefox.net>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@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: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
X-Rspamd-Queue-Id: 4MgXMl2XwQz3MJt
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
> 
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
> 
> still shows all the debug output. It did not
> avoid the timing changes.
> 
> You might need to not use either of:
> 
> patch-common_usb__hub.c
> patch-common_usb__storage.c
> 
> and to disable the LOG_DEBUG and DEBUG lines in:
> 
> patch-common_usb.c
> 
> via turning them into comments by adding // as
> indicated below:
> 
> +//#define LOG_DEBUG
> +//#define DEBUG
> 

I think the changes were successful, u-boot compiles and
runs. There's no extra output, and unfortunately only one 
successful reboot so far. Bus scanning seems quite slow.
Storage devices are rarely found on reset, but usb reset
does sometimes work. Run bootcmd_usb0 paused for minutes
at Device 0: and paused again after reporting ..current device.
No echo from the console, ctrl-C did nothing. 

The attempt sequence was
SRBSPRMRPRRPUPPRRUPUCUUC
where 
S is shutdown -r
R is reset of u-boot
U is usb reset
P is powercycle
M is stop at mountroot
C is run bootcmd_usb0

The console log is at
http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug

It now appears that the run bootcmd_usb0 rather reliably gets
stuck, with the disk LED on steadily (no activity). Maybe in
one of the loops seen earlier? 

Thanks again for all your help!

bob prohaska


From nobody Sun Oct  2 19:06:14 2022
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 4MgYN31jclz4V9Sy;
	Sun,  2 Oct 2022 19:06:11 +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 4MgYN23gf4z3Pwb;
	Sun,  2 Oct 2022 19:06:10 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 292J6E7h002792
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 2 Oct 2022 12:06:14 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 292J6EBP002791;
	Sun, 2 Oct 2022 12:06:14 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 2 Oct 2022 12:06:14 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221002190614.GA2704@www.zefox.net>
References: <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
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: <20221002182049.GA2255@www.zefox.net>
X-Rspamd-Queue-Id: 4MgYN23gf4z3Pwb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

An odd occurrence not seen before, perhaps because
I never waited long enough.

The console reported:

U-Boot 2022.04 (Oct 02 2022 - 09:46:36 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
Core:  69 devices, 10 uclasses, devicetree: board
MMC:   mmc@7e300000: 2
Loading Environment from FAT... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... error in inquiry
6 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select! : -110

Device 0: unknown device
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-b8-27-eb-ba-68-d5
Retrieving file: pxelinux.cfg/00000000
Retrieving file: pxelinux.cfg/0000000
Retrieving file: pxelinux.cfg/000000
Retrieving file: pxelinux.cfg/00000
Retrieving file: pxelinux.cfg/0000
Retrieving file: pxelinux.cfg/000
Retrieving file: pxelinux.cfg/00
Retrieving file: pxelinux.cfg/0
Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi
Retrieving file: pxelinux.cfg/default-arm-bcm283x
Retrieving file: pxelinux.cfg/default-arm
Retrieving file: pxelinux.cfg/default
Config file not found
U-Boot> usb reset
resetting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
U-Boot> run bootcmd_usb0

[a few seconds elapsed]

Device 0: [ few minutes] Vendor: SABRENT  Rev: 0214 Prod: 
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device

[tens of minutes elapsed]

** No partition table - usb 0 **
Couldn't find partition usb 0:1
U-Boot> 
U-Boot> 
U-Boot> 
U-Boot> 
U-Boot>     

I thought it was stuck, but apparently not.

It's still unbootable.

Not sure it's relevant, but certainly a surprise to me.

bob prohaska
 

From nobody Sun Oct  2 19:35:42 2022
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 4MgZ2D0gftz4ctGv
	for ; Sun,  2 Oct 2022 19:35:48 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4MgZ2C1y1Rz3RZ6
	for ; Sun,  2 Oct 2022 19:35:47 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x534.google.com with SMTP id a41so12031927edf.4
        for ; Sun, 02 Oct 2022 12:35:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=/J+Q/BVj+qJmWco20psMrCNXZrcsNeK6TQBwfyiZs+0=;
        b=Pr3GyAgSpfXFqujGJMp7kqinOG2k21keFwsw4zz300dyWQ3aOmdVTnVVZ0q1FdXk54
         UiOfruID1IPvcaovVmNRUT7pcLtFl/By60u3pPyE+1Kil534CXEWRS11kiK/QrISVIM2
         ayhvkwfeFV3zx2FU6QF2oyQmtaZfbpdRt0ABjS69dqg7QR3Lji9GuuIQJVAWi99y+65K
         0tEkirnufX59MDYNNdpQ54Hmz66sysfUYmDblPKjtQMO5akoOwdIW4Ylx0dEoXuVkiMN
         SjudTbZbwKqM7uYCIrN7yQPnTixxU7JG4BUZw3jCFxOU7mOIRZEnpHulKBqC26L93Zcb
         +O6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=/J+Q/BVj+qJmWco20psMrCNXZrcsNeK6TQBwfyiZs+0=;
        b=Kksua/+o3Imwy1+PfYS1c0BWPoomECM6ZwFI5X558OczShIzVgGGMDmpv0nEIoNnY5
         TZfz+U4sU3AFOv+M4evUKwn4riumGMV0YK08zqUb8O8TUdmJpalsAYiVmGoEud+sPXLs
         nkmbiVELeYJgFs0ucgmbtbdosJoJGJqYWPYgUkx5C0IjfnUfM4yR/AFKfcBO2L04gzbx
         owEDGVHZZ4bArpNwPrwiEeLIIiIKvCCdFAMOSnsGtzADLosPPr5hjFT101gJeGzgJ+Xt
         mpoiM9C58nkrfh2A6QwCsBSwcyd9zOEkyAsrzhYhrTCaQ7fgI2glh7/dW2TEq0SVvCK8
         YbXw==
X-Gm-Message-State: ACrzQf1S0xXkRPbal6BDhiE+MDEO8daoEIXVwyQrfmLMPL8+YzSPldmX
	fJGw6hP8Lfyau9aALBvfRgc=
X-Google-Smtp-Source: AMsMyM4IRSDtav9xkaip5DmTPNwlhk+lSg323xhq+p3Vrko8vd3E/XgwJ6IJx7KEvpignGw0Z7Zn/g==
X-Received: by 2002:a50:9344:0:b0:448:ce76:7c81 with SMTP id n4-20020a509344000000b00448ce767c81mr16263649eda.187.1664739344974;
        Sun, 02 Oct 2022 12:35:44 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-026-059.46.114.pool.telefonica.de. [46.114.26.59])
        by smtp.googlemail.com with ESMTPSA id r20-20020aa7c154000000b004582a37889csm5865292edp.16.2022.10.02.12.35.44
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 12:35:44 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sun, 2 Oct 2022 21:35:42 +0200
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20221002182049.GA2255@www.zefox.net>
Message-Id: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgZ2C1y1Rz3RZ6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=Pr3GyAgS;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 02.10.2022 um 20:20 schrieb bob prohaska :
>=20
> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>=20
>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>=20
>> still shows all the debug output. It did not
>> avoid the timing changes.
>>=20
>> You might need to not use either of:
>>=20
>> patch-common_usb__hub.c
>> patch-common_usb__storage.c
>>=20
>> and to disable the LOG_DEBUG and DEBUG lines in:
>>=20
>> patch-common_usb.c
>>=20
>> via turning them into comments by adding // as
>> indicated below:
>>=20
>> +//#define LOG_DEBUG
>> +//#define DEBUG
>>=20
>=20
> I think the changes were successful, u-boot compiles and
> runs. There's no extra output, and unfortunately only one=20
> successful reboot so far. Bus scanning seems quite slow.
> Storage devices are rarely found on reset, but usb reset
> does sometimes work. Run bootcmd_usb0 paused for minutes
> at Device 0: and paused again after reporting ..current device.
> No echo from the console, ctrl-C did nothing.=20
>=20
> The attempt sequence was
> SRBSPRMRPRRPUPPRRUPUCUUC
> where=20
> S is shutdown -r
> R is reset of u-boot
> U is usb reset
> P is powercycle
> M is stop at mountroot
> C is run bootcmd_usb0
>=20
> The console log is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>=20
> It now appears that the run bootcmd_usb0 rather reliably gets
> stuck, with the disk LED on steadily (no activity). Maybe in
> one of the loops seen earlier?=20
>=20
> Thanks again for all your help!
>=20
> bob prohaska
>=20


So if you now reapply the  #define DEBUG  patches(while keeping the =
mdelay-patch) and the reboot issues definitely went away
we have a typical so called Heisenbug, hopefully more or less  now a =
fixed issue.

Well, USB-boot problems on earlier Pi models( afaik all except the 4) =
are commonly known, from defective HW to power cycle issues we will find =
a lot of discussions on the WWW and we will see that even the =
debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C  did fix issues =
in some cases. Others applied RNG devices or external clock or even =
plugging a mouse fixed it( to change usb enumeration).

I think with the working u-boot.bin after 1500 successful reboots you =
can be sure it=E2=80=99s working =E2=80=A6.
just kidding=E2=80=A6 :-)


Regards

Klaus










From nobody Sun Oct  2 19:48:33 2022
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 4MgZK80Lxtz4cvbR
	for ; Sun,  2 Oct 2022 19:48:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4MgZK63yxQz3S2B
	for ; Sun,  2 Oct 2022 19:48:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740119; bh=/tyvSeK3WiBOs7u/rW0dhezNFn9lb2kEqvxWjNm77Jg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DzzPgd5XBOGQ0pR+wL7QF+zGhbPpZ0bteTJTHHPYwR/s1gUZnuzPLJNuFRSeu78xFvAQlKAR1gxTtKbRqyarG48BjdOJguWSO9zaeF1e39BzjwRbdAph/a82v6YjXjh+VP0ZMHlRw7t44J+rSn0drw3ynVtbZRTsECLpCX+x0O6SYsw1LR8QXwhdwNNLsNmWp86YGa9jfYsZ7tLi4b3daSHPw4DmvRHlxjSqjirscaf25ByvGC+VEl/T6XR1UYtvBGkjRZa6sY90wxff9BkvDgs2KIlz3yyrkOZhs4HhufbFAkg0To2cZvnp7J7mDWx1yfozCpDNDPl9zF8LJOp+ig==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740119; bh=QkZBiWHd4V3/beHKtV8/FbqCKr9vek70CDgFVxFdlkN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BcgcaBd9cWYsPjWGBmxteq6fMWyBqhrfESEUBO7qwPM2Ir46dfAHdhtLwMoWV6YS1o7tZ95Yz96UHH7eioIdAR2xFrCPYcZeFahWenFMKDdoo3AWO1HFeGaaL31jH6tjT+r2UzzXR+U/kqoge95Krrt/xHAhbnQqqQDJXsxUeIUECKyLIc1f4EfiUqIwsofbPsm6oKIQWFfp6VjXcnKmgEziOOqh7DsfGaaZvr2DmT9LkyQVqROGph+/mjquX8NuwgEzTC8SAp6mSRmk9Ri1j3jeNNpJSjUBJoIV2D1D23Z7tsiMg5x2ef4SUMHwKav6pQiCZfJxLudRYYHv8Mi/iA==
X-YMail-OSG: VLzFZDYVM1mAR77AjvRcA_Znl8tgMi1pjuf1uVwoGI2.QW5pdb3T4DSClP_zZBH
 kaCxnPDZQGr3K5X9SxrK3A8HT3vnpC7Vsxg2jhml4VVKk0xhz0CwN_CivPGxk6kUiqCsv5ncCpOm
 7vupn7n2jq0qLUgdlh.YdQiKAZ1ij3RdKLEy7iJzTuccy5zntNFj4mptndvMFgXzi7Ug1hyxUdGv
 ezvQ7bUP0QiqZGp.hgaMcrYpBAX0bCSw3UCKMALbwxPBYIthrLN1O3zmQMLOrELMwl6zlmUG5Oap
 MFLzKeXrct6XtsMnZDyRC_.iHuuLN_RM.JhN2O8vbYHijX5N5vcgFF2zPvDtAoQSAIDtLdF0vaMM
 PoEMu7FVCPVV5C53aetpEEUcjTRcoriXXlhkJO8hMFiBSoC2UippYUqsHxwg9pW7H1wGBVjqa2tQ
 Xq.WWEK3R3oo4kQIJGACcbni8N4jtUNEMrTDqtkj4yLTA6_L5ooo4cUasgAHcH_ncyO.BaFFA4bT
 QRSXN74A_2q.PP1xdxe0dJlCYW9llXFHS1McjlOnisLR_JNhiuWUc7IqLOF_6mlOKZuqSPyNbL3A
 Sc3Rd.XAIqW_EzM5Xj7dMOqEobVdvfdIKwya.XVPw6mP_DZNLnSQ.1HV22tK3WVFLQw8DnKmHG9O
 hzRJc9IAStddSYeSm2KTz0uJ_ENj.mhWqofpe86NTmiKy0g17y0gItiqbx7OjSjJjjAlXdjyjtMb
 BcG5vUBA99rBT6.J8U1BR..CYv5h4qabai9UWN9bM4S9nAQTUqmzoaqhK.ROhvCu7VEVTRU0HYGK
 _GVyfsoPGC.YseSxnvL4ZZ1rRo3yDi0WYxdYXQy5BxeHg.K9VjMhYCUDt1dqXQ.EgLBRmHH2A4Dd
 UPy50WoqtKJGcccwGRtLp09EmUp4kWzMXBqh1wqOJX3DeMGgXRniXgsNxfzSsHxtRIBn.k6YNgrp
 AE.KSUT7Fovy_Gwd6JZW7ks2jfqJxlJlnZZKTVeuvBEJvQ2Z.4At2ubTDigPiIdjbz3XX218eAE_
 _LhtTDJGJp_XydsW9dKUq1cgs8zo15HQ2qMKjVTcjBE7tbob5YCszxoacJwUhba8h8sK_FSB_.pm
 FhIcfsn4C4RHzCCjkhNApMSBlhpLj_hyDEDxkyt40.VgX4VjwEbI0.z72MhyiozHy18ppDtugOhM
 21Gg1HLwWLkKn361bRGhHTT0Ge225eBW9_Fn8teTyL0yHxgQ3pd4qNBDLOFEd.qI5W.YOpxokbfH
 wYP1Jn1jdQwNVcczy83a6xCfw3XKW6bmd2TpVdjYngO9RpA77nmcGoY6K3CWIHFzTxVDAoCL1VF5
 IBvWHuoJXpRA1S078ei.6bRVlCpaLuBqimEsG_pEzXqG8zkqM7FP8tYAej.L9fT8ZfWyLpa8hxip
 07kxPiZiugVPnOaUnBgZY.c._FDKgOTQA8da_lhsmEurXgO5wspzATHqdNHlly_Dtw10CNnp.HlC
 BipfxE.0zPkk1ggehLNH063B67EpEAElzw5qD061UT7K61W2IMvvCHRL3ug2zaHiBPKW5f3ANofD
 UZ.BT2Q2V9vvJjD6_ciYQ_WnfCFqzRx62xk.cBSLOsbmQoLTHZx7dvVOSgvROzteguEFjIC06dqq
 X3bGpdZPnNS48zQHTzumSKuDX2wU_3_ZUioF6Rg81YvJ9lqkQpjbMJjYS_4OQ_Lgg30Z1qexacNz
 C24ZBBZ_iIbZbvsYjEhzTBbihnzNdIkyuKjneZBcZ_yFdEPR9IKS1kmA.JWGGz1koGMeaS_ZqJDv
 CcPbH_p0qJl1taOtTY8wUt5fo3hau4q_rKOerCnzEGbCB9y5tNwWyq8o8IK.xYVf_W0Lf1.ANORe
 HDRG3gprWaQEEqZarLQOD5kKUrtrdsIE1nDmwvZdeWrR2g.191VT03mwgLUmMNmGQtTvBSF74.Wu
 4XLveVUQfUkj.0i5FUobq4SBcMH6xYI1kR_0ndGEmwhauGseJZ1sEXz.MvlxUgmaTlckw4YhW1uB
 W2atkkaZ.v_VvEK5Tiup0u8qUzi6LF9xd_5E0LNFmQErMs_kM3X_JAFkIJMH63t9jZZrHhOfFEyA
 YCcw4pqcIcogvpbdAbaZpbWOb5CMlQG_eCxD7ylgmk1nDWG9a7SewuoHdpzEQn8YHBfC5K.LOEfV
 rDfkx4zK2g.vMF3DGov8RjmkmM9QEeWnFom5eAlJTtaj1eG0EIYxKsq0PocMWYhill3cLtwZf7jW
 3U_v1tuzrUBjseuF681t2.2VaKYz15jCA.DeFmod2CAbCHLDEk32v0AMkID01Sk0lIuL8TgEqd3H
 OB80sFe8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 19:48:39 +0000
Received: by hermes--production-ne1-6944b4579f-t822l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 331916cd8482c9e935da24c1c8453286;
          Sun, 02 Oct 2022 19:48:35 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221002182049.GA2255@www.zefox.net>
Date: Sun, 2 Oct 2022 12:48:33 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgZK63yxQz3S2B
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=DzzPgd5X;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 11:20, bob prohaska  wrote:

> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>=20
>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>=20
>> still shows all the debug output. It did not
>> avoid the timing changes.
>>=20
>> You might need to not use either of:
>>=20
>> patch-common_usb__hub.c
>> patch-common_usb__storage.c
>>=20
>> and to disable the LOG_DEBUG and DEBUG lines in:
>>=20
>> patch-common_usb.c
>>=20
>> via turning them into comments by adding // as
>> indicated below:
>>=20
>> +//#define LOG_DEBUG
>> +//#define DEBUG
>>=20
>=20
> I think the changes were successful, u-boot compiles and
> runs. There's no extra output, and unfortunately only one=20
> successful reboot so far. Bus scanning seems quite slow.
> Storage devices are rarely found on reset, but usb reset
> does sometimes work. Run bootcmd_usb0 paused for minutes
> at Device 0: and paused again after reporting ..current device.
> No echo from the console, ctrl-C did nothing.=20
>=20
> The attempt sequence was
> SRBSPRMRPRRPUPPRRUPUCUUC
> where=20
> S is shutdown -r
> R is reset of u-boot
> U is usb reset
> P is powercycle
> M is stop at mountroot
> C is run bootcmd_usb0
>=20
> The console log is at
> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>=20
> It now appears that the run bootcmd_usb0 rather reliably gets
> stuck, with the disk LED on steadily (no activity). Maybe in
> one of the loops seen earlier?=20

Of 27 " Storage Device(s) found" notices:

18 are: "0 Storage Device(s) found".
 9 are: "1 Storage Device(s) found".

so the 3 mdelay(...) lines are far from sufficient for
that issue. I see no way to tell if some variation of
them (different delays and/or a subset of the 3) is
somehow necessary.

It would seem that some of the delays from the debug
output to the console were an essential part of the
prior lack of examples of "0 Storage Device(s) found".

I'm not worrying about what happens after " Storage
Device(s) found" so long as "0 Storage Device(s) found"
is still an issue for one or both of:

0x152d:0x0577
0x152d:0x0583

In part that is because, for all I know, the source of
the earlier problem might well also contribute to the
later problem(s), even when "1 Storage Device(s) found"
happens.

If the build had the adjusted mdelay and the 2 additional
mdelay calls in place, it is not obvious if they should
be kept or not.



Fedora 37 is in Beta currently and is supposed to be
final in late October or so. It is the first Fedora
version to officially support RPi4B's, now that it
has accelerated display support and the like.

Fedora (older and 37) uses U-Boot for how it boots
RPi*'s. If you had the resources, I'd suggest producing
Fedora-based media and seeing if it has the same sort of
U-Boot-stage problems in your device-types context.
(RaspiOS and Ubuntu do not use U-Boot last I knew. So
they do not make for good comparisons for the purpose
as far as I know.)



I'm going to provide notes below about how I produced the
patch-common_usb*.c files. The sysutils/u-boot-rpi-arm64
port did/does not already have patches for these files.

I build via poudriere, not via use of /wrkdirs/ . . . so I can use
/wrkdirs/ . . . as an area to look at source code without needing
to worry about building the port in there. Starting with a /wrkdirs
that did not contain a /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/
I did:

# make -C /usr/ports/sysutils/u-boot-rpi-arm64/ extract

to populate /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/ .

I then made copies of the sources that I was going to change,
adding a .orig suffix to the names of the copies. Showing the
resulting paths:

# find -s =
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/ -name =
'*.orig' -print
=
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us=
b.c.orig
=
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us=
b_hub.c.orig
=
/wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us=
b_storage.c.orig

The copies were made via:

# cd /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/
# cp -aRx common/usb.c         common/usb.c.orig
# cp -aRx common/usb_hub.c     common/usb_hub.c.orig
# cp -aRx common/usb_storage.c common/usb_storage.c.orig

(-aRx use is just habitual for me.)

I then made changes to the 3 common/usb*.c versions of those files,
editing not shown here.

After that I produced the patch files via:

# diff -u common/usb.c.orig common/usb.c         > =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb.c
# diff -u common/usb.c.orig common/usb_hub.c     > =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__hub.c
# diff -u common/usb.c.orig common/usb_storage.c > =
/usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__storage.c

Doing the diff from work/u-boot-2022.04/ with the common/ part of
the paths being explicit is important to the content produced in
te patch-* files.

The "_" vs. "__" use after  "patch-" is important in
the patch-* names:

"_"  is used where a "/"                  is in the original path.
"__" is used where just one "_" by itself is in the original path.

The FreeBSD ports infrastructure does the translations
to produce the parts of the final path needed.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 19:58:35 2022
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 4MgZXj3wGGz4cwWP
	for ; Sun,  2 Oct 2022 19:58:45 +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 4MgZXh4WpQz3Swj
	for ; Sun,  2 Oct 2022 19:58:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740723; bh=8R0T5tGjWzaecCwrg3ipYPIioXPMCO7BhGS509vZYz8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=W4NSs4Dh6DCkt4XjYDhvhLkIRT7q6596CdSr4JUZ36r5rmWaQnNNtvUKcSN7jmFaBghsmDIgLogUhkmkirZRQcl6P0Md3uTLAPCKAAeKRdNOuoV3QDXAl1K46naNi+Nsk5+PLh1tlz5uRdSl+p2NhKgwP2qHwuClX6rbLjVHWNTgxuLaW+S1YpF77PVaNdSJc80F76FYu9Kvtm+WJajDVTIVl2A89wsrkSdB/YbjS/QhPQrPHkglgPoEQUv26qWPk/Vble3ABG4vW2mGoTOJ/G7yofPP4xTDQtbqznWHFQqOwe7rKlrGWY3kh0wDdgqT74rou5Iao3jNOvk4bdKHPw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740723; bh=HO6paaLza11aSG2uO0xinCcpqfW0OgozYxIHuRbIRSB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IZTYWOrcm6j/f61dcIbGxRmmRenl9GdlxKclemdy9IobFYoFcUyck1lvJcKXbqRqPqdhFLk6F8U5KmE3Gz2T+geCaUCx8hV4dl/ix/ENG6DhYdKuR+GSzVb2HqDGjajLECNKHDAyoqyIepM8024788/1s+lbyHMauMCPcsm4e2OTEym9dUftoUUKvnaRCxxXQPvIgpZZ7guOGeFvl9pT0uOKhOHl+ap5V/hRuWEbUTcskGE1U6sneZgRpRPhlk1IStJhUU4vjB+WSVG3qCHYNb8I5yIKpvC6h1W2S/enfY1PVkfYfiQodJgRwe4D79FrJkXJm5ey1dHfz3YjeMH2tQ==
X-YMail-OSG: 2r0_6hoVM1lpZvt6YnNw5wLlsOwSDuUc5lq8GsHwROxqbhTAs7SLsCDHhgmSkVP
 MkNro6DcjG7zbRk9T9ClP8zGAdl4o0RCxxeoSda9sL6KfF.hQW6NIhaBHTshg5mNax6_Ouqji_Qw
 MxE1kgGr.U4bTu5zoj5NmZIYiih3YKWJL82ZtOGu0HqJCJUDUHBvdPLzY4yejD6OTj.sVpmEi4tf
 4UyMHlhw5m106iq46uwgkyEMbRejzz_JF1x8JrDGag8rblY5dMQI2SpmuhnaLCmfU1t.BD3nAthY
 fcLxz1yQYttHrU4kt_5Du2n7Eo_bNjHpF31CZn4bXUUZCyLFtIBrUpYL4zVcJUCfpKkVIsEmT3Bs
 QBNaikPv0eKm6tMMV8_igxka0yRENumjBrrI1m6hLCi5pXmhAW1QyifVcq9FPd6cfFagWTzSeN9O
 qo1G.BCawX783UEGkwKQqJBmrwKbUPQSqsLP6crZZ1jnPvun68_I_Q3DsU_ChYZdpPYgYyaIRzN0
 UsVVQ_bs0E3XOgCaaEEewW7082_585WahIdDr6H0B68n80f0C6HsU4QUJvhHTQAhH9LRbgiIjnau
 FToFUn4HALe7C8ZxFMpDpWVkgV4PxspeSZvH.0LabXGcUjve07Vvq517ReesFOajSN5VYTzdUwib
 Um6YbtzqVPNUB75aq8iQ2ra_N_JQ4boUxo2ZNZeEwrLEATctf1db9_3EJiInODNijNhs4CPz4TpI
 Q2jizyPy5Q60piC7hKx94uruUBnqjI5AmL3XgGaMSxMhkwEJ2iqFzP.4rpfxshlPKvgWSbOP1bH5
 dmIhQrfBgIXoYh.0rf1WbXTVb2neA_zyHAEf9yTbAEcKOHvypPwv9diuU_3k9rD2UmHk0vnFhb.g
 Gzs76o62avXuRhnpcN8PYEsthR0g..69SuXmQ3gawzyBcqz3Es8WJx1m81_8VEHVcelRs_M2X4Ur
 NP8VC32gRzxtzBdkg.eLW6cyz8Nu1Shj9WE0TZcjhO0H_MiptbjWsVa0RZsL8x3KSmTRnhHho3d7
 XRMZhxhKj6bOdiSL1LIU.ZCJs.2G0WfbZxLu5bdiPRV3ky50JuRaPd81s05tgTXKJhvfkOh71Xza
 oqVbbW0pz_jUO233LfAHvwYxE_OcbgtkwYVhOpKJqrqZEP_NVcRGKH.zrf7NrDfV29pCBuoANHnT
 ojwqloCXbk8ZwFrbMtCZLKe4xXZ7EiJoPseCOtFVvuns1gA6JTVe8.gn0YWkzzUWJS1mQkaRaSC5
 _teLzNqWUjRODP1gG6BeM45TxiHK8Xv9taNo1zUtLitV361JdM69lGRx9L.Nf5jms5TBACEwNpKJ
 J4UY959TB8MaOvIG1w7hM2W1.E7xAPAwZWxVRnWywXd5vQqHq6ZA.GLhaEBu0RdNzIIzsJfuGnvU
 SQJTo57x_bzf.9UfOZ8xfdc71WnxURYEK_6M2XjC1S9phRf_UE9cFcxieBQ6LK1Dmjct6yqcN1LY
 qaPkYt3KYKwUpawcJGmDO4B1a3GPrb8VM7S9xrYBvr2tEW0C9VDYseTXJM.UIr6HYgkj.oI6rTqs
 .a6hp4FaU1ap6kceXUcoHNW.BqP9xolBQcEgaJZHYwLrx7QH7gPSa8dd7vEAuXklaX3UjrdjRAN3
 LnY5zQoNrWhJTgrYrO533si33sLJlkD9Iie0rWM9MK2kLsZHbw8U5oBZJRUz4OroKCEn8kQizHPB
 q9f8oiHvbLfDIs9jntrSbXmLY2pR5CXr6Brq6KJxLqtFSey7HYo4zL03t6QGUbn2zKNq1_WgxAJS
 pLwnJNUo0p8E1UjIdoNYoG9CPU5CUjDTRf_35E5LQsJ3YNYr.arbDtNXHmgne8D2xtom1eEnnfRw
 wZ5wHh06xJ1RmA6aCFOIg9tXe8MR7bCZHEh9UXHoZ5V22u5Xza8z9yuf7sChAYyQ2cpAbKdzjoxh
 OyvGdPkQ4bauQ5KcKofWOqIWLvZMMsyLm2TFtho5VFOHFeOdfJWUIs94LrpVtxP4TP.bgueJwucg
 HKfufTthSpHkER3sVSNnO2W83NumED1.a7s42n5u15xmGWjL3fqih9SSLAN0ciQ_x5SZuQghO7hd
 r7.CmoV6ZGyHcQaNtL.38M0XIgV3y1Mbb8uj5uBQAd3McxUFedkueXUx6jsNP3UhhvQeRbbNioGb
 PMJcJ2AMtQvADOyLn6p__cmh4ulQNhEUDSnvUtLiKGFKf6BESLEH2xtes521BwmkcRRYJGXaYJaW
 em5z9XRq2d6EpfEwnXKesxvP8uOmj1L.BiXUHnY4XwAKiJ01NmD2fsVfqu9FStuSqMuui0BGB19y
 vgud6v5g-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 19:58:43 +0000
Received: by hermes--production-ne1-6944b4579f-75kjj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 387255e2e6f705807d02e0e2b83b21a3;
          Sun, 02 Oct 2022 19:58:37 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
Date: Sun, 2 Oct 2022 12:58:35 -0700
Cc: bob prohaska ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgZXh4WpQz3Swj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=W4NSs4Dh;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann =
 wrote:

> Am 02.10.2022 um 20:20 schrieb bob prohaska :
>>=20
>> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>>=20
>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>>=20
>>> still shows all the debug output. It did not
>>> avoid the timing changes.
>>>=20
>>> You might need to not use either of:
>>>=20
>>> patch-common_usb__hub.c
>>> patch-common_usb__storage.c
>>>=20
>>> and to disable the LOG_DEBUG and DEBUG lines in:
>>>=20
>>> patch-common_usb.c
>>>=20
>>> via turning them into comments by adding // as
>>> indicated below:
>>>=20
>>> +//#define LOG_DEBUG
>>> +//#define DEBUG
>>>=20
>>=20
>> I think the changes were successful, u-boot compiles and
>> runs. There's no extra output, and unfortunately only one=20
>> successful reboot so far. Bus scanning seems quite slow.
>> Storage devices are rarely found on reset, but usb reset
>> does sometimes work. Run bootcmd_usb0 paused for minutes
>> at Device 0: and paused again after reporting ..current device.
>> No echo from the console, ctrl-C did nothing.=20
>>=20
>> The attempt sequence was
>> SRBSPRMRPRRPUPPRRUPUCUUC
>> where=20
>> S is shutdown -r
>> R is reset of u-boot
>> U is usb reset
>> P is powercycle
>> M is stop at mountroot
>> C is run bootcmd_usb0
>>=20
>> The console log is at
>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>>=20
>> It now appears that the run bootcmd_usb0 rather reliably gets
>> stuck, with the disk LED on steadily (no activity). Maybe in
>> one of the loops seen earlier?=20
>>=20
>> Thanks again for all your help!
>>=20
>> bob prohaska
>>=20
>=20
>=20
> So if you now reapply the  #define DEBUG  patches(while keeping the =
mdelay-patch) and the reboot issues definitely went away
> we have a typical so called Heisenbug, hopefully more or less  now a =
fixed issue.

No. Bob has more than one problem: more problems observed
after "1 Storage Device(s) found". The DEBUG/mdelay
combination only seemed to cause the "1 Storage Device(s)
found" to be at least more reliable, not later stages.

It is not obvious if earlier activity contributes or not
to the problems observed after "1 Storage Device(s) found".

So far nothing has gotten near having things just work for
booting without manual intervention, multiple retries
being involved sometimes.

> Well, USB-boot problems on earlier Pi models( afaik all except the 4) =
are commonly known, from defective HW to power cycle issues we will find =
a lot of discussions on the WWW and we will see that even the =
debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C  did fix issues =
in some cases. Others applied RNG devices or external clock or even =
plugging a mouse fixed it( to change usb enumeration).
>=20
> I think with the working u-boot.bin after 1500 successful reboots you =
can be sure it=E2=80=99s working =E2=80=A6.
> just kidding=E2=80=A6 :-)
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 20:18:28 2022
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 4MgZzX6c5Jz4cyVp
	for ; Sun,  2 Oct 2022 20:18:32 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e])
	(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 4MgZzX0Jnfz3WT0
	for ; Sun,  2 Oct 2022 20:18:32 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52e.google.com with SMTP id s2so1523946edd.2
        for ; Sun, 02 Oct 2022 13:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=Kk2WyjxMpp7QbC083Fkkw96pv4SqyGAtYqQLFfvugzk=;
        b=bFmcov46bcLQeuk7bS5W/HFpRObRLWKOwkJrJxIOnSZkj8lZUgrZMNT3eoHL6I1yUu
         m0YZvlVT1Gc7GNRDxZTRxkFeY2zjUHmlfDre+en3w1GxXNBG63kUmIdhSnX1rLeC/KYU
         UqgTqqb+gIc7cnKSjMJ3q9SAbAY490FIsJtH15C4X00UxWcI2eFq3V/DY5gYMxcGN+xs
         N6wjVUjWZkE7FMEVEvfv2mRFRRzcNkUafM6zO7yJKn1eJyFnMfbvxygfgNAabE8zGGHs
         rNws5IK2JlaC8GrrGN0EqMmy/QzI+pNfTXFB5aj4EABtWvNNuZSCvk8m50rgoJgURqfF
         I/Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=Kk2WyjxMpp7QbC083Fkkw96pv4SqyGAtYqQLFfvugzk=;
        b=gWJDO0WCoWbIOTrn5y0neiTSspVlgGw+Hsk6aj/wHw63EDjAlc8XbluwlNWwL6pFy6
         avoTiAjoE3I2hqBqaNpTnpdXEKza3VqGz27QzbDo0cG2AEt18meNCbwmDPxaKh22U1j5
         crVHRa+frT+TYlMqmOgZr+D0q87EL+Bv2mjf5QcBVt8zGr9uEr5gkDlRlYRADzDykUi/
         2PsRnRp+CuNyxlBvFZC9H7jONRDxGM18c4M2nxUEwzaWq8BF6dbEDKVAyNwxUDY3H+nC
         O6JPfWeSrnAW/Ld6hEDls2Iyoc+mZhyN8+QriTiD57UkMFOqNgWzIO+4kydBI/IiCtMw
         kUkg==
X-Gm-Message-State: ACrzQf0at/3a+PmMCF6O3whLMD+An8HPUf9pYxOWkJGCPIxAP2ISnLd+
	gFt9KatIevjhyDE7nHMbNME=
X-Google-Smtp-Source: AMsMyM4B9asuTi4nkvogW2JYwDzvzxfBvosEe6iNrvfXCMUKPlQUuPGrfVJfc25TxBzh7ZlttGeSYA==
X-Received: by 2002:a05:6402:1014:b0:451:d2a1:236e with SMTP id c20-20020a056402101400b00451d2a1236emr16379579edu.212.1664741910799;
        Sun, 02 Oct 2022 13:18:30 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id ek12-20020a056402370c00b004587f9d3ce8sm5459868edb.56.2022.10.02.13.18.29
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 13:18:30 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sun, 2 Oct 2022 22:18:28 +0200
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org,
 bob prohaska 
In-Reply-To: <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgZzX0Jnfz3WT0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=bFmcov46;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 02.10.2022 um 21:58 schrieb Mark Millard :
>=20
> On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 02.10.2022 um 20:20 schrieb bob prohaska :
>>>=20
>>> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>>>=20
>>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>>>=20
>>>> still shows all the debug output. It did not
>>>> avoid the timing changes.
>>>>=20
>>>> You might need to not use either of:
>>>>=20
>>>> patch-common_usb__hub.c
>>>> patch-common_usb__storage.c
>>>>=20
>>>> and to disable the LOG_DEBUG and DEBUG lines in:
>>>>=20
>>>> patch-common_usb.c
>>>>=20
>>>> via turning them into comments by adding // as
>>>> indicated below:
>>>>=20
>>>> +//#define LOG_DEBUG
>>>> +//#define DEBUG
>>>>=20
>>>=20
>>> I think the changes were successful, u-boot compiles and
>>> runs. There's no extra output, and unfortunately only one=20
>>> successful reboot so far. Bus scanning seems quite slow.
>>> Storage devices are rarely found on reset, but usb reset
>>> does sometimes work. Run bootcmd_usb0 paused for minutes
>>> at Device 0: and paused again after reporting ..current device.
>>> No echo from the console, ctrl-C did nothing.=20
>>>=20
>>> The attempt sequence was
>>> SRBSPRMRPRRPUPPRRUPUCUUC
>>> where=20
>>> S is shutdown -r
>>> R is reset of u-boot
>>> U is usb reset
>>> P is powercycle
>>> M is stop at mountroot
>>> C is run bootcmd_usb0
>>>=20
>>> The console log is at
>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>>>=20
>>> It now appears that the run bootcmd_usb0 rather reliably gets
>>> stuck, with the disk LED on steadily (no activity). Maybe in
>>> one of the loops seen earlier?=20
>>>=20
>>> Thanks again for all your help!
>>>=20
>>> bob prohaska
>>>=20
>>=20
>>=20
>> So if you now reapply the  #define DEBUG  patches(while keeping the =
mdelay-patch) and the reboot issues definitely went away
>> we have a typical so called Heisenbug, hopefully more or less  now a =
fixed issue.
>=20
> No. Bob has more than one problem: more problems observed
> after "1 Storage Device(s) found". The DEBUG/mdelay
> combination only seemed to cause the "1 Storage Device(s)
> found" to be at least more reliable, not later stages.
>=20
> It is not obvious if earlier activity contributes or not
> to the problems observed after "1 Storage Device(s) found".
>=20
> So far nothing has gotten near having things just work for
> booting without manual intervention, multiple retries
> being involved sometimes.
>=20
>> Well, USB-boot problems on earlier Pi models( afaik all except the 4) =
are commonly known, from defective HW to power cycle issues we will find =
a lot of discussions on the WWW and we will see that even the =
debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C  did fix issues =
in some cases. Others applied RNG devices or external clock or even =
plugging a mouse fixed it( to change usb enumeration).
>>=20
>> I think with the working u-boot.bin after 1500 successful reboots you =
can be sure it=E2=80=99s working =E2=80=A6.
>> just kidding=E2=80=A6 :-)
>>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

hard to read and remember every log but I thought Bob wrote about aprox. =
30 successful reboots after the mdelay patch,
while of course that could be coincidence, who really knows what happens =
in this untrackable inconsistent behavior of the usb-boot?!

> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>=20
> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
> they do not make for good comparisons for the purpose
> as far as I know.)

RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =E2=80=
=A6
while possible Ubuntu(or others) have own u-boot patches ,
from guessing it seems more probable that they also will sometimes hang =
after (re)boot.

If I would want to keep such a device as an online server, like Bob =
does, for whatever reason I would=20
Implement something like an =E2=80=9EIPMI=E2=80=9C or simpler said:
An immediate console remote access after being warned by a script that =
the machine is offline.
But I would remove it from cluster if there are known Hardware problems.=20=



Regards

Klaus




From nobody Sun Oct  2 20:46:36 2022
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 4Mgbc167Jpz4d2vT
	for ; Sun,  2 Oct 2022 20:46:41 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533])
	(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 4Mgbc10nppz3bNc
	for ; Sun,  2 Oct 2022 20:46:41 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x533.google.com with SMTP id y8so12148325edc.10
        for ; Sun, 02 Oct 2022 13:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=d4xEMqtF+jzQG0Go0mJX8YlFBN146xaTM26gRsgPWzw=;
        b=HSf/D2B1aBFBm3qkZwe3v3R+KPKztETCebrBnSMM0Lz7oBgHdciNNwc/JDpwfXG19g
         r7UVcbeFirzSlQNCei1gKqCQu93YmbV9AVf+WgqI5Onj1bM+yDoP2cXgipiYvuKyXIGJ
         xCLcY/edicHxEYuvjD51JZ3mtrdcVnyP/ZbFxwY4gQU9NlOQB13DtKdVCtOau+BOv273
         Jnm33Q9ktSU6iKaJIIeAMNx2WVKEX6Kv4rudt9wrkUSu9Ov4JOO04UGxrR0iDPPwn9q6
         4lzr36uBWZDopQfemNXaZ1Xxb/pwQm2HltCcylmNLyunVzUrkpX7RnJu0eFc+MxgG/YO
         cpLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=d4xEMqtF+jzQG0Go0mJX8YlFBN146xaTM26gRsgPWzw=;
        b=cwNXQ2PFApWmwaP9HoJ2Ci17KpL+Ds6/Ly5V6nIIsfCvJKaH/+nkN1CDWo4qrG3/Uz
         gbkZps8aMHT41ccu19j1HEfPAzng3GqG2yyxhkirQI0RRuP4ESc2jsIPgtDNQsyDTgn4
         W49Lb4THVEFzRkL0Y56SG2yu1SOKzGIWTE3bjz6Tf8gmAUpzqHfQVtO1q7FZLGP++rLI
         ml8fdGzDhppCsM65Ved+rzA1inT8qXxjfvqXG3GXFB2HCETiomiYiAyxlJDgzWc+1r+o
         J/r3+2IMLLHjfPpYR3Pvrnml0MmnvPB6Ti8PKaLoL/8daFUwR8ODAdk7VdWXiJJab9y1
         EH7Q==
X-Gm-Message-State: ACrzQf1G0v4O04OYr8bv//ZNNM7rgMovAH6d9xFyIARKycmb7X/WfXs9
	5ANhq5vxGz5YbL0kX7gcvOA=
X-Google-Smtp-Source: AMsMyM5AzKwN8ZNVzczEozttLSxOX920ruxuejx8K665JZ/o5KE4B22Z+VTNv3W0zgRp5hkx0Rzb9A==
X-Received: by 2002:aa7:d392:0:b0:458:800a:c47 with SMTP id x18-20020aa7d392000000b00458800a0c47mr10880493edq.5.1664743599721;
        Sun, 02 Oct 2022 13:46:39 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id u15-20020a17090657cf00b007867dcd3f15sm4417979ejr.104.2022.10.02.13.46.38
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 13:46:39 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sun, 2 Oct 2022 22:46:36 +0200
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
To: Mark Millard ,
 freebsd-arm@freebsd.org,
 bob prohaska 
In-Reply-To: 
Message-Id: <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgbc10nppz3bNc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="HSf/D2B1";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 02.10.2022 um 22:18 schrieb Klaus K=C3=BCchemann =
:
>=20
>=20
>=20
>> Am 02.10.2022 um 21:58 schrieb Mark Millard :
>>=20
>> On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>> Am 02.10.2022 um 20:20 schrieb bob prohaska :
>>>>=20
>>>> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>>>>=20
>>>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>>>>=20
>>>>> still shows all the debug output. It did not
>>>>> avoid the timing changes.
>>>>>=20
>>>>> You might need to not use either of:
>>>>>=20
>>>>> patch-common_usb__hub.c
>>>>> patch-common_usb__storage.c
>>>>>=20
>>>>> and to disable the LOG_DEBUG and DEBUG lines in:
>>>>>=20
>>>>> patch-common_usb.c
>>>>>=20
>>>>> via turning them into comments by adding // as
>>>>> indicated below:
>>>>>=20
>>>>> +//#define LOG_DEBUG
>>>>> +//#define DEBUG
>>>>>=20
>>>>=20
>>>> I think the changes were successful, u-boot compiles and
>>>> runs. There's no extra output, and unfortunately only one=20
>>>> successful reboot so far. Bus scanning seems quite slow.
>>>> Storage devices are rarely found on reset, but usb reset
>>>> does sometimes work. Run bootcmd_usb0 paused for minutes
>>>> at Device 0: and paused again after reporting ..current device.
>>>> No echo from the console, ctrl-C did nothing.=20
>>>>=20
>>>> The attempt sequence was
>>>> SRBSPRMRPRRPUPPRRUPUCUUC
>>>> where=20
>>>> S is shutdown -r
>>>> R is reset of u-boot
>>>> U is usb reset
>>>> P is powercycle
>>>> M is stop at mountroot
>>>> C is run bootcmd_usb0
>>>>=20
>>>> The console log is at
>>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>>>>=20
>>>> It now appears that the run bootcmd_usb0 rather reliably gets
>>>> stuck, with the disk LED on steadily (no activity). Maybe in
>>>> one of the loops seen earlier?=20
>>>>=20
>>>> Thanks again for all your help!
>>>>=20
>>>> bob prohaska
>>>>=20
>>>=20
>>>=20
>>> So if you now reapply the  #define DEBUG  patches(while keeping the =
mdelay-patch) and the reboot issues definitely went away
>>> we have a typical so called Heisenbug, hopefully more or less  now a =
fixed issue.
>>=20
>> No. Bob has more than one problem: more problems observed
>> after "1 Storage Device(s) found". The DEBUG/mdelay
>> combination only seemed to cause the "1 Storage Device(s)
>> found" to be at least more reliable, not later stages.
>>=20
>> It is not obvious if earlier activity contributes or not
>> to the problems observed after "1 Storage Device(s) found".
>>=20
>> So far nothing has gotten near having things just work for
>> booting without manual intervention, multiple retries
>> being involved sometimes.
>>=20
>>> Well, USB-boot problems on earlier Pi models( afaik all except the =
4) are commonly known, from defective HW to power cycle issues we will =
find a lot of discussions on the WWW and we will see that even the =
debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C  did fix issues =
in some cases. Others applied RNG devices or external clock or even =
plugging a mouse fixed it( to change usb enumeration).
>>>=20
>>> I think with the working u-boot.bin after 1500 successful reboots =
you can be sure it=E2=80=99s working =E2=80=A6.
>>> just kidding=E2=80=A6 :-)
>>>=20
>>=20
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
> hard to read and remember every log but I thought Bob wrote about =
aprox. 30 successful reboots after the mdelay patch,
> while of course that could be coincidence, who really knows what =
happens in this untrackable inconsistent behavior of the usb-boot?!
>=20
>> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>>=20
>> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
>> they do not make for good comparisons for the purpose
>> as far as I know.)
>=20
> RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =
=E2=80=A6
> while possible Ubuntu(or others) have own u-boot patches ,
> from guessing it seems more probable that they also will sometimes =
hang after (re)boot.
>=20
> If I would want to keep such a device as an online server, like Bob =
does, for whatever reason I would=20
> Implement something like an =E2=80=9EIPMI=E2=80=9C or simpler said:
> An immediate console remote access after being warned by a script that =
the machine is offline.
> But I would remove it from cluster if there are known Hardware =
problems.=20
>=20
>=20
> Regards
>=20
> Klaus
>=20
>=20

=E2=80=A6 but of course, Mark, that is correct :
overwriting parts of the msdos-partition by linux ones could be the last =
resort to save something=E2=80=A6
but if linux had patched inside u-boot, as you did it for Bob, I would =
see other problems coming=E2=80=A6

Regards

Klaus


From nobody Sun Oct  2 21:00:23 2022
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 4Mgbvq5pCNz4d4NM
	for ; Sun,  2 Oct 2022 21:00:23 +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 4Mgbvq3nPvz3d6Y
	for ; Sun,  2 Oct 2022 21:00:23 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4Mgbvq2vDkz102B
	for ; Sun,  2 Oct 2022 21:00:23 +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 292L0Nel047828
	for ; Sun, 2 Oct 2022 21:00:23 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 292L0NRK047827
	for freebsd-arm@FreeBSD.org; Sun, 2 Oct 2022 21:00:23 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202210022100.292L0NRK047827@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, 2 Oct 2022 21:00:23 +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="16647444230.fA2f.45634"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664744423;
	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=xG3QnPYqY3odMcqVXQhs0rqseCZ9dl46VFxhB7jOKzk=;
	b=F4fs89Uvwy8mLMloeWE8ItMRWgGMy1j7VmYYv4tDE1doT58NXvE2I+02NtW6QOaZSvuLHF
	fAXNPfMSi6KUqoCCdJCBVQflBjj188hO4CSCEsiISL4HrkY2pwhc8Z3eU+1rjRew7dM9np
	RkWxT8VE+xgMupqYtG8sFyLX9Xbhmmi/0Y64BL8MfUdCvUbSipuPzOUa3X2pVD7/fM6mKr
	vYfucOa/kB/AzmLcYkftPadrSd9+XyyC9IiKrZhyOJ9YKtQcDXR1nJakc+qILlPw+5uIwG
	ju3ZYDXxqY5O5cT3YYmfrz2Ch6T+puig88QUwlRMn7sB/2+3n6w2BhtuPE20+Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664744423; a=rsa-sha256; cv=none;
	b=o+OIw/VQ5A2BMoK7Yp3tPp3rvyJQQjKriMigkJxKPzSieQknb1IACsAZcHNL9e/SButDDJ
	YdBsdu93wgNrtni/TtVHKbBf5Z5b/yLmnBS51yfKcQmfzrp0FgesbmUhvDEexwVw4u6afn
	Okv4pDoRXAQM93je8n+yn+r7VAccoMr0HXlVztfqnPLPtMWIfJ9F490N4DdbG1Bc1hnmq7
	P2pvbKO74EIUsCiPNRCK4VOoc2Vdooy6c3NJB1dGq6vuTUhSdCMRFdMchb1nptpSHoRXrr
	I+fKtC+NSOLWYRfFt8iBTar6oVQkxkCimUyMBUiUxhaDwo8JBYVVve2vpQ9rGQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16647444230.fA2f.45634
Date: Sun, 2 Oct 2022 21:00:23 +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.

--16647444230.fA2f.45634
Date: Sun, 2 Oct 2022 21:00:23 +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.


--16647444230.fA2f.45634--

From nobody Sun Oct  2 21:36:42 2022
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 4Mgcjq04kHz4ddCQ
	for ; Sun,  2 Oct 2022 21:36:47 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4Mgcjp0jhmz3kKS
	for ; Sun,  2 Oct 2022 21:36:46 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62d.google.com with SMTP id rk17so18673777ejb.1
        for ; Sun, 02 Oct 2022 14:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=D4KimtIVCoKe4gKELOpFJDe6KpLjYyG/hzrCwAvNPEU=;
        b=LNEQGyI1ew2I+Z1vp7fQzgcJdZcwlkQjF5VfbeC1v2cPSAd1ace9MTLXYtSQ6yJPHo
         ag4+baFCgJRNtJox2XiW1snY3JjkVsKKgkZVWs5ItQjjMTPAdaXdq7062G5pLG32S48c
         1GRY3zs4ZtMBVXhgEcJmsHiEA99+725Cv0wEfj8xFhbOhfQuU6sTNgpjTTBut1Qtt2Et
         JFeIl7Yb7wG3/Qab3JbI6/i4e3t5J2OnMcFfjkPVIQBmBIRZHf5jrIaRE0z1H3gKpH/x
         mgA/k6u5DIvmKdOSvT62jHd5k6jWay+P4RxjkM6ibS7ILLhA4BISLGmksMXoMXjBnVaf
         4MWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=D4KimtIVCoKe4gKELOpFJDe6KpLjYyG/hzrCwAvNPEU=;
        b=grlCz/EUXhqY6yi5X3kr82xtAONT6bFxFs01BGm2pHanY0/wRl7pCoromguooPLtN3
         E3KOzC2EShMTyBQ1fwhWdWZrxEIw6rUq5BXJTYATzGD6j8uyY6z0SbhuiugGpIOmDa9s
         MmoRVR4hsXrj9L6Hjdi3/MC5rJsKW2S4UIVsQNPw9/PkxdG28JvsX9XS2t04tlGwCkZP
         CilUOWFTOh9E3qpeyCSY3x/nMgWQgjHTi7rblIp4VRs+JCTfrjlcPUTKAKLbvREewC2W
         I9UV8iUQAhZImXmzHvLxWyHcK6SSo+dWgi5eIo7wwykybQz64eRk9HlYNL96p39RnxDK
         5fLA==
X-Gm-Message-State: ACrzQf3O24z1+b2lpcaLcJnFPX6wdZXHB/4nxxprvwW9omD5ejtDfJGR
	UWB58BUTDizAH1lwIfVlVKBQv0jw+x50pQ==
X-Google-Smtp-Source: AMsMyM49ldP5/ST7y4HBlWUjsCEcaVkxO3fZXJ3r08xAQud54pOT/y972zFl2Fj1zpY7rqgKa7f4eA==
X-Received: by 2002:a17:907:9807:b0:781:feee:f87c with SMTP id ji7-20020a170907980700b00781feeef87cmr13500058ejc.101.1664746604669;
        Sun, 02 Oct 2022 14:36:44 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id p6-20020aa7cc86000000b004574f4326b8sm6003024edt.30.2022.10.02.14.36.43
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 14:36:44 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Sun, 2 Oct 2022 23:36:42 +0200
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org,
 bob prohaska 
In-Reply-To: <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgcjp0jhmz3kKS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=LNEQGyI1;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,www.zefox.net];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 02.10.2022 um 22:46 schrieb Klaus K=C3=BCchemann =
:
>=20
>=20
>=20
>> Am 02.10.2022 um 22:18 schrieb Klaus K=C3=BCchemann =
:
>>=20
>>=20
>>=20
>>> Am 02.10.2022 um 21:58 schrieb Mark Millard :
>>>=20
>>> On 2022-Oct-2, at 12:35, Klaus K=C3=BCchemann =
 wrote:
>>>=20
>>>> Am 02.10.2022 um 20:20 schrieb bob prohaska :
>>>>>=20
>>>>> On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote:
>>>>>>=20
>>>>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment
>>>>>>=20
>>>>>> still shows all the debug output. It did not
>>>>>> avoid the timing changes.
>>>>>>=20
>>>>>> You might need to not use either of:
>>>>>>=20
>>>>>> patch-common_usb__hub.c
>>>>>> patch-common_usb__storage.c
>>>>>>=20
>>>>>> and to disable the LOG_DEBUG and DEBUG lines in:
>>>>>>=20
>>>>>> patch-common_usb.c
>>>>>>=20
>>>>>> via turning them into comments by adding // as
>>>>>> indicated below:
>>>>>>=20
>>>>>> +//#define LOG_DEBUG
>>>>>> +//#define DEBUG
>>>>>>=20
>>>>>=20
>>>>> I think the changes were successful, u-boot compiles and
>>>>> runs. There's no extra output, and unfortunately only one=20
>>>>> successful reboot so far. Bus scanning seems quite slow.
>>>>> Storage devices are rarely found on reset, but usb reset
>>>>> does sometimes work. Run bootcmd_usb0 paused for minutes
>>>>> at Device 0: and paused again after reporting ..current device.
>>>>> No echo from the console, ctrl-C did nothing.=20
>>>>>=20
>>>>> The attempt sequence was
>>>>> SRBSPRMRPRRPUPPRRUPUCUUC
>>>>> where=20
>>>>> S is shutdown -r
>>>>> R is reset of u-boot
>>>>> U is usb reset
>>>>> P is powercycle
>>>>> M is stop at mountroot
>>>>> C is run bootcmd_usb0
>>>>>=20
>>>>> The console log is at
>>>>> http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug
>>>>>=20
>>>>> It now appears that the run bootcmd_usb0 rather reliably gets
>>>>> stuck, with the disk LED on steadily (no activity). Maybe in
>>>>> one of the loops seen earlier?=20
>>>>>=20
>>>>> Thanks again for all your help!
>>>>>=20
>>>>> bob prohaska
>>>>>=20
>>>>=20
>>>>=20
>>>> So if you now reapply the  #define DEBUG  patches(while keeping the =
mdelay-patch) and the reboot issues definitely went away
>>>> we have a typical so called Heisenbug, hopefully more or less  now =
a fixed issue.
>>>=20
>>> No. Bob has more than one problem: more problems observed
>>> after "1 Storage Device(s) found". The DEBUG/mdelay
>>> combination only seemed to cause the "1 Storage Device(s)
>>> found" to be at least more reliable, not later stages.
>>>=20
>>> It is not obvious if earlier activity contributes or not
>>> to the problems observed after "1 Storage Device(s) found".
>>>=20
>>> So far nothing has gotten near having things just work for
>>> booting without manual intervention, multiple retries
>>> being involved sometimes.
>>>=20
>>>> Well, USB-boot problems on earlier Pi models( afaik all except the =
4) are commonly known, from defective HW to power cycle issues we will =
find a lot of discussions on the WWW and we will see that even the =
debug-message =E2=80=9Eis your USB cable bad?=E2=80=9C  did fix issues =
in some cases. Others applied RNG devices or external clock or even =
plugging a mouse fixed it( to change usb enumeration).
>>>>=20
>>>> I think with the working u-boot.bin after 1500 successful reboots =
you can be sure it=E2=80=99s working =E2=80=A6.
>>>> just kidding=E2=80=A6 :-)
>>>>=20
>>>=20
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>=20
>> hard to read and remember every log but I thought Bob wrote about =
aprox. 30 successful reboots after the mdelay patch,
>> while of course that could be coincidence, who really knows what =
happens in this untrackable inconsistent behavior of the usb-boot?!
>>=20
>>> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>>>=20
>>> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
>>> they do not make for good comparisons for the purpose
>>> as far as I know.)
>>=20
>> RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =
=E2=80=A6
>> while possible Ubuntu(or others) have own u-boot patches ,
>> from guessing it seems more probable that they also will sometimes =
hang after (re)boot.
>>=20
>> If I would want to keep such a device as an online server, like Bob =
does, for whatever reason I would=20
>> Implement something like an =E2=80=9EIPMI=E2=80=9C or simpler said:
>> An immediate console remote access after being warned by a script =
that the machine is offline.
>> But I would remove it from cluster if there are known Hardware =
problems.=20
>>=20
>>=20
>> Regards
>>=20
>> Klaus
>>=20
>>=20
>=20
> =E2=80=A6 but of course, Mark, that is correct :
> overwriting parts of the msdos-partition by linux ones could be the =
last resort to save something=E2=80=A6
> but if linux had patched inside u-boot, as you did it for Bob, I would =
see other problems coming=E2=80=A6
>=20
> Regards
>=20
> Klaus
>=20

Not debugging related, so off-topic:
Bob, if you care about remotely rebooting without losing access to the =
console:
You can plug a known functioning online machine(e.g. your Pi4) v ia GPIO =
directly to Pi 3b.
ssh into the Pi4 in this example  , then cu / minicom /xy into the 3b =
console and manually reboot the 3b
over the u-boot console if it hangs.

For unexpected 3b-crashes while uptime, as said, you could use a warning =
script or whatever.

Seems to be easier this way than continue hunting an untraceable bug   .

But (at least my) main intention was to come closer to the u-boot source =
code,

So many thanks to you,Mark ,giving so much POWER(and SPEED) to these =
things, great work!
/Bob knows what I mean with POWER & SPEED terminology :-)


Regards=20
Thanks=20

Klaus=20


=20




From nobody Sun Oct  2 21:43:42 2022
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 4Mgct01V6dz4dfCK
	for ; Sun,  2 Oct 2022 21:43:52 +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 4Mgcsz1JFhz3kbf
	for ; Sun,  2 Oct 2022 21:43:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664747029; bh=qrnKeksdIqyeQtiIvoGzoTqCK2CysGAwzpTgU15suFE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Aj3UMMrZYJH++IFEpb5MywhoJOnSLM96A1DxujCvecTT09jmBw9LiAXK3LvRkpishtw9THTWHRAI6osSjzNY5CenraJONsWvG7jRiXWUx6HDuxn9vg4ylro5odik56uRSV3PLqSXLVipoELqYZjWFPsPHugLZ2uX8ZoVsxmnJusw3+4SGaiLTBLw5q6HqkwH6Tbv2kHb9tgY2oAp8ygo89Th1ehHftS3PuBI9zfgOFQRkD6FkH7isjnjveAIeYtTyMQP6cCf0iT7pKtsEMxt0fQQ1ofAe3eMZGy0N4wzsdhNkj4fOmlcxz8MXAp2U7rDfxazw4QkMxrCEcghGLS/5A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664747029; bh=2aKZCXlVO27QZ0t8WbcFh/18ikdxm+PFlVwOowkldyN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LisSB84OtTOE0/AuZ63AWnrQnwR6pXwsLfIs05GkAERT5sLjOlYaksAJLnYOthfpv++fV5URU4GrMEYohBazcUREz6Gm5TTwOthuDFi+hTB2cAIKQJUpJ/cTZonCLCxOA0NkguRvzM+zC6g8krwK28eukXs3wLfD+35aqyKmV4GPewULnTclb0NT32pKnY7Pf+X+x2h5Qh6FvHRVx0lSnB24B4xCuUmfZwsUUYM4S6JNwDR2HBXINtC4O3Twq4U0Tv33E799+qpEp1OdxbhuKEFkKSPojSAa4nTSJuhoPIsDcHmvbFiB5lKwkeoH3DBKUuXhjpcovg1lC6M+638w1A==
X-YMail-OSG: 6GLHjR0VM1mkQeyu324QAIPB6wQIEYbJ3TzxKx0pJBdFkpLMvIsv5xnM7T493JE
 WBBd5Hwg_sULA16uaPGHheGvfW6E9Qla172Kq_YGT9Bz9fDzlyzmyeBEZIq4KvDzvlET1UG.EbwG
 vVDrvF18xLen5ZqXhOtrZTS9W143HQ7gpnPMv1IDd9QpvEAG831Kiv9NsxAmSv5kBsDv6n364L2h
 CwKE8oa_RDU2XXskJjzgQfL6ljahmjRUGq.2Q2Nrr_8CXjTLukUs6jKh0sqUCioJNuiL5m2Sxh1h
 jMB.SxMU4YeM628ngQ69IfdqaeSSIZs1H92boHS3SSwjWqAtwpsuZxa1tWdQC1eTkgMAzqO1WTP9
 5dpCMSBu.hX.n9F52Q4H6ZOWo8IloBLNNIANvr9ABoRBXxa37d1de22P3kwvrb18wWvqnR8Mmw7G
 PWTWzF.bvjoEE05vmn_QjMPMCaaEAR26RxVvsA70fQaog6NE3q95s9Lvecxav.o5FwQfVTiL3D16
 tlud8HysQmylXmCqEd4VZlOxqjtUcTeShS2T4RBFx0.zQeQvyx52G.pgqG_sJVpTG_RD3jnRkHW_
 xdY7hAobiP7KR.xtPIcg8rQqSJIMdvyNh_BadzepfMTZ5C7YEH.ckLKOy9EMzdcHfjlZO4PEIvhc
 YUCqnnQb0UtlNiau4p3KTnt.VJV03i5bQVe088PToHU7pWcl2qpl_KDflS.5yHtUNSWEYDiqi.Pq
 ra6amrr4jitSNDzy575HQ1hLEiKbgTmPC.WZX8SKMBK_ZEtRvM6ab46Rq4R92W7ZF92VqwakAAmy
 rQD7V3DgCu6A_BHQhbcwtM549pPB8tuLlZZTerBjyDoN.ISyuRYVTbmbbVeOE_aWFpqXBazPWAHA
 EnOKdSEJNpLnO6bnIQf9H6FYfL6irEzrYsy_O9u7wDO9bGqv0kXuRflCXXBkAfifr9T.txVEndsa
 BR4pAZP0Bjtc8Bv0xcetaRMRHPDvZO.QRa_sylutOqSUMj6YPdm9OChWhDw4JbEBcFs5eKL7bUqW
 t7ZKf7bSvz612EqyVJpMqzzNTPNDYB_cqql8gxwQXvUptmMYlQLEkRMuhq3oO3npfaYMG2OGhBxT
 j9enHGNX93F8tcfXJOyuLcgZp2gdkTnPOdLPQbCt3u4tqVYX_lzlLGtEQlPECyv7K6cnGil9qf5L
 g3ezYJhdK1q_b4nG7pbmQl.NIfyJ_yOeOo_E0soAlkGgu2kae1qKVSMIcsv.MW7jNo255CdkP1yZ
 Cc_HA3EAUtYTo2IPhrHYRR.o9E6MesklQsMDIl_bz1n_We51lnux6ex9kfnEjOrUC4a.rEa0Ig4U
 ADIpBjpTk0ZswQaTlfKEhaVmhS0cowFTYZ2FN5cqLAtC8vnIS5oru8l.ZJ4q_sFuGU4G8tML_pla
 U.UGC8CqCi.BKHwxx.mWEK9vbaCKE3vI7.Sbp9t5nD5IXKgjpW9EDFy3lAPoQT2GNzKTkQO8KhEt
 cwFynJTankyqWzLUQBCh2YxXY5VEcnHEb8H9DcbVSPyhLGM.ufx32Ti2szmIwnVb5KuPP_ZuK0N0
 io3W.XXUndTWJMXaaavStv5wSefkcUjtq6xygDSA1gDubUTPO6Qz_VQLIzblnSCzHBO.8_5ganDT
 syiesnQGqrNEynlMrkFyJdydtYTk6C1hNkfN9lgFzpT8cP05ptvy3wbPWXVtIEf7P_IqBnyIirrQ
 J2N378sDNwnMRa1llojiecD2Wck0WdKPRPjD8F9dKmWVcLio.dQZk56SuuHoA9C9UkAvPNwOJZZq
 zSUyd_qyO3I3owfql6OiFGARwE9r0EAWiN2qhoB8m5dTNoIclP.voKNXVmpsXMEZNPPWNnT9helL
 hoDnxib2nlZhOe6KNX2jdtoBasodm2yriYwHRu0MkPgKp6tJU.Y4N2X3WP7mUd1pLxnslM.AIFPb
 God8hZyJtUa8A8yw45ksGYS942P.GcMF.jUwyqGMNpics.yYO8W2tvNQ7fpcwADJ.LLKlZXEUmWJ
 bjeTysUQfd3pi5MTODPe98Xl3gVRk8r.PHgJpmdeXtVAggY60TWHOxWNMWBH9GFm3q1S_qmHGsoS
 SWHzsZY7ay5Oh5hFFK98NRMpSVTHtRUYEgWlCHVin_wxbMK8zQlcXiEjBSPBnFgKevcuylAbc2hW
 _07PArKK9GT5GHyheCkUSvfMqZ5O_wD8uMAAzLi9W9vPWqym6j6Hz3pONCfVAzYAywZk501tNbsm
 mO68iuA.Mn8aO_6iTumxkFZMX_s9mSWIedHCXAiYTnbvRXxUji50Ztr6WjOwG_zqOr.Zo8nWeQ5t
 Ohjvkik4-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 21:43:49 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-jjklf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dfa958577e6ad5429134e437bd7f6b61;
          Sun, 02 Oct 2022 21:43:45 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: 
Date: Sun, 2 Oct 2022 14:43:42 -0700
Cc: freebsd-arm@freebsd.org,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <29BC8014-45D9-4AAE-83CC-E27395573B44@yahoo.com>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgcsz1JFhz3kbf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Aj3UMMrZ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 13:18, Klaus K=C3=BCchemann =
 wrote:

> . . .
>=20
>> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>>=20
>> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
>> they do not make for good comparisons for the purpose
>> as far as I know.)
>=20
> RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =
=E2=80=A6
> while possible Ubuntu(or others) have own u-boot patches ,
> from guessing it seems more probable that they also will sometimes =
hang after (re)boot.

Sufficiently modern Ubuntu does not use U-Boot by
default, at least for server builds.

ubuntu-22.04.1-preinstalled-server-arm64+raspi.img
has:

# more /mnt/config.txt=20
[all]
kernel=3Dvmlinuz
. . .

where vmlinux is seen as:

/mnt/vmlinuz

No use of U-Boot: direct booting of vmlinux via
the RPi* firmware's ability to do so.

They do provide uboot_rpi_*.bin 's for folks that
want to change to use such:

/mnt/uboot_rpi_3.bin
/mnt/uboot_rpi_4.bin
/mnt/uboot_rpi_arm64.bin

But the supplied config.txt makes no mention of any
uboot*.bin and things have to be changed to cause
a uboot_rpi_*.bin to be involved.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 21:48:47 2022
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 4Mgczs2W8Yz4dfQv
	for ; Sun,  2 Oct 2022 21:48:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4Mgczr35wCz3lG2
	for ; Sun,  2 Oct 2022 21:48:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664747333; bh=2xzZHMQ5fyLb2MCX87h+HgvliGlXWidKqx0PCJwbFw4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eVMltVPe6BlllUi7LEIkfcIFXfVyNxxfjnyk/rKoMV68waiNAsTzc/Ns90bu7awXM9AF5yaqX/+iu3OFL9I6cHldTDAD4DRoK4XfZ0Nn1P46AGQhu93f8FAdf8Qg3Nb0xRJ/hlePFriFDR8xbCpKzyOM7izX+LcntoznkI+sTggN0iYT356/9iCWrpxjCwJdQby2XHU8NYYsAfTPALl/DQbli1udyWGSuFHaHfMYWTCA4F9ImNsqmQVQthjnbcioKjZv8vW7AN4zNXKCs3VU+2kT3YH9rsfRM4igQ6M8QPnG8lUTGbkdY4oTQbbNJv8duzNpmBzKvqS9VmpNZ/MFxg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664747333; bh=DnqZPTOeLYifTV0/ibfpUB9M2Xx1ZLRYUp/1qKkO409=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TOUQGIbGJ4UTbZY5B6AGb+/7W8d/r/FGaNKC04E2EVo2qDrjHoK19AG1lSTwHwyVbSVwVqyxylnWsh+lnFn1Cp4JJQEsBPw46PiY3bIieQw07UrD598r9qLg9D4hs468Ly2aoM5m/aV14EA5erFzQUNx/mqx22XQ8WBUMQK67dZp72qWtfSPNZCGxl3tjEMQee48OT1hGi6r26fHaSjftFous4R194ZLkOzCck/tBqZLqosv0D1cqN8tQ2fXto/L1Rn+zBDefvZVdQ1yPUaBY/lwdHSnBjTlNnKDeVrGBEQt3z/XfSOarSsELeyw8WvIPWfZjH3BJbvh0sv4qOBnuQ==
X-YMail-OSG: eR18S3kVM1lpjWEMkok8NAdleerWkJE9ONjYqw0vG0F2gkRt1nM_sDgxQxoWxXV
 pQMWiO0M_acNqLhaq5D0VVUyyroxDqZE70YZSRWjrhrqZ0qJ8msTo2uDjaM7dj99tVz1pZ53LDsN
 S.IVE72S6aWAbRtGBjxqjTyduqMnE6ArnzoFyO8ethT9sgik4wL1CJU.evhJpNE9QYtuG7kv5K1N
 Q6wr3cQW3KDW1A.gp353Y5rMMDIxSQfIwjboWiuRM9mzMOUHLQvlRTuEYxnA7wmQJJcDsrGkIX_5
 Od8OKumHYyJJTtIncCOxe9x7SCL0SRK1e_FXN3I5A8pX4tT7cCNTwMVslS79.GlXqY9ztbWXL6z2
 PO1xQXKX4QDcQBBHzSM6xkA9bKIs4uZmGiT0Cp7Idmls4cRqgTa3g_6zdZDtE5ZSFM7E8Pb9du5V
 afnzoopAgCmXCCV1kDAV4O.hdhifHJ19ndwBIqH7lNdtFuP7.kwfmES3.xBHWWvRJp6LpJO3ix9o
 tgLC8ao7757xwzuX.Ta8yhC0Xf6x1XDzM18mjDosplzb.1ZI20NeoBbPYuv542ssTetOxql8L0J6
 _4lYlg_SgpFRScNYEqPmCpxPaQHpQObD5CgcnoABZBNo_yoQindtFf9zRwqijJ2ZufmmWJQoKuNN
 VWXMArpQEPRHICCLNBn6jqYBNh5pcBE4mZdQ113hyAYES90IPMVvBb3b0skpVHLIlnm4msCuP00j
 gGeXjZvSu69Y03MaPL9U6MVJqp.FfnTcJ3nsRHx7.23hnK_p1gEcC_CAED3H1tfuQjL5S.Bz7C2Q
 4vHmbx9MOEzvBRfmy38lZCWO8i5oH20MPrDYNe6rb1l4mlLPiBrCYwMhbWpg4.3N8d2u2zKBfvHN
 UthCRnSjReOJdGWWmLpZbGjK2i_ZdIMmkHm68NNbfGPmFuiadlyHs3t9VKF86QbiYm9.RoYQO9fd
 3AX3Hns792BKbFmfGBuUeLyPKwNaLMs1HsORN25MSdMcPE9dLoLs5vo1_xPzRLow0qrTtdviZ4IX
 8n3ey.UsgQ4DTX3EYmEGn.Qc0ll7G5eVTH2FFKJJBM5WmeZITyaJ3IEaF0zubg1Dd_gb7gKRl9eT
 8OMBMsCkD2Hh84COX31lBgccAm7WCMo0T1wUfRDgJgixAo1kA6j0rLW.Iks5NDoDnAyPb89OevY4
 Lf1UOTdOHhwQKhiSWUkIyQuRioMjVzlT8szAS0b7SaYC.wdfpnflGmvx38btmezQDO998k2HJVaM
 MlKaPKqJGecAM2D3QB4MA9D3O5GK8Dko8G5wfGw7TbKx7dDZTWkRytOBYIkr4R4jVQggtk4SvySr
 aoSHqD79SfkPZVcI06DnmK2fJIL5Fpa5dpcmpMnLiMA1oDErNRg8Qd2q1XbpGUi_xj9eylO5ERjK
 Ovumg8j2DWqoVNAke4Y46qJcN2DBJG4kQOvEUSjyXWNx2xL9gM43456sBsCLuyw.98be8pYPHXs.
 1AKLhlADMDYnPLqynpTCzUUGjkfpuirNe0IsoewxP3L2yTPjHkgjEifisWkUTUKS8cU8f9souijs
 PQcoBcS9DlBdB3IJ4jmjW3XCpUKtkslbjhVumH7DsBIFTCD7ZdicH7_8KfFU4mCePyqUVk4TLMcB
 HvNaAtSRAb5qWonHyk8cQSDOFxfkJvYVXkQe.tqluqxKEOJPmFNse1q1DOLwAPlzao5ORninQRrh
 ihBx5HU3RwJWzxB6djULKnta2zJ8JFGVfR8f8i_UH8jYUocQ2Tvp770ct7BoG6yMmvDGwGeiTKi.
 e1KybD2TfoG4bHwcLXC4CJOLDWltdGENN5JDFYMQj0y2I3vuHKd9zPNNB9GveJU7oeOjMDicwMgA
 3bmuiXvK2RzideKYxduenp84j4czM9jNiP8qs3YVjz5awfJHvB0hejr4LJ6rneD8PMvPYPxhhGSe
 o4W74yrOeAFUoVrsjskimaxoAnohSsVEEjfyXpPcj0Y4DnlMrH72XNyRs.rs9BgAObjMn6hPhKHq
 gEvkiz5WpLEovsu16bkOEV8O.vE_ddD2CwEEMu0RZLaSIVefHK6eZRgl4tZB1MuK5iijLWOwGfGF
 JrMN5H4rzz07KHZqFqDW8E1ATpvRFQVFmCe19xAocApmWtRpC6wfK85xGdVGolqu1qHzBVbZ.HWz
 KgtehHJmtUKaVLaXhe6TqeFCc_lBomQHgtJYv6aT5hWYH3HZaJcpnqq7QXEDwx5hLvkfCizi6G1a
 YZffDBfdgD1Fz6T81QaOf.Q60fSx4IAo.rtnEFo9sVhSPNM00yEplsQTPGZN.aQCCjjfti36L8Tz
 qi2s27L0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 21:48:53 +0000
Received: by hermes--production-ne1-6944b4579f-bhhwb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 46835766ffd0d2e0c6e31d9be84e37d2;
          Sun, 02 Oct 2022 21:48:49 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <29BC8014-45D9-4AAE-83CC-E27395573B44@yahoo.com>
Date: Sun, 2 Oct 2022 14:48:47 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <29BC8014-45D9-4AAE-83CC-E27395573B44@yahoo.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgczr35wCz3lG2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=eVMltVPe;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 14:43, Mark Millard  wrote:

> On 2022-Oct-2, at 13:18, Klaus K=C3=BCchemann =
 wrote:
>=20
>> . . .
>>=20
>>> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>>>=20
>>> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
>>> they do not make for good comparisons for the purpose
>>> as far as I know.)
>>=20
>> RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =
=E2=80=A6
>> while possible Ubuntu(or others) have own u-boot patches ,
>> from guessing it seems more probable that they also will sometimes =
hang after (re)boot.
>=20
> Sufficiently modern Ubuntu does not use U-Boot by
> default, at least for server builds.
>=20
> ubuntu-22.04.1-preinstalled-server-arm64+raspi.img
> has:
>=20
> # more /mnt/config.txt=20
> [all]
> kernel=3Dvmlinuz
> . . .
>=20
> where vmlinux is seen as:
>=20
> /mnt/vmlinuz

I should have mentioned the naming convention that
is in use: vmlinuz is a compressed variant of vmlinux
as I remember the naming.

> No use of U-Boot: direct booting of vmlinux via
> the RPi* firmware's ability to do so.
>=20
> They do provide uboot_rpi_*.bin 's for folks that
> want to change to use such:
>=20
> /mnt/uboot_rpi_3.bin
> /mnt/uboot_rpi_4.bin
> /mnt/uboot_rpi_arm64.bin
>=20
> But the supplied config.txt makes no mention of any
> uboot*.bin and things have to be changed to cause
> a uboot_rpi_*.bin to be involved.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 22:06:30 2022
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 4MgdNH6MZNz4dh6b
	for ; Sun,  2 Oct 2022 22:06:39 +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 4MgdNH0cYHz3mJ8
	for ; Sun,  2 Oct 2022 22:06:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664748396; bh=IgHoxYYrsZHoDjjUJHSwum/4IASCXAnMHzY6ylfTxqE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iTy2Qt+SPYl77MpFCXAJ8rmGDmo55uDvfHE1H2twOGSZAx5TFEpx6EbqJasvVyRbrbM/K0FslWVlpdZMHtkR8qLu+nP2S787rThaP1U5DN4ZVmGuK0wo6U61yxQOK4KdZeptKHfrkp6eRuTJKXlbL58zKYfCWrj9VsQAJucnG6RfVYvkK59oX3i4fR3P3ZvbdF/eULo6dHI+rzbdUPLJRM2MDzzicOhfLytoUmxLWNSNskTXETGMhqVEDXjeBOerAII7whXbxEUORGSC9Bnf8UF073Rxv0RRHN854mX+JgSdC+tgZrvkzk9L7j9TYCXLmXgOfccgEmsNDVe7Sy8H4w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664748396; bh=Yv3M2H/+q17Id1A68sUaq8KQDqX3ZZ5ufgNA2sVSr4u=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F1mnXKjgfbHpOoc20bTNkco5mj2fH7lDUGpOi7XG5dSW3FU3JlER/CBr42AiNHkkWFgrhUHc68BF3J5olGSK/FYAichY9AFvWJg6NrbBIPBWW/u+yM+aJriDfVpQ2fOX0vutvOh4zqfBfzvnQySLvLagLmV4iecFneF+6ZfaXEWdm7BGNc0Gvy4xjfxs0QpMjjgoPCCIWQQqSPjnEw3FXtimNk8XU54cu6v37QvbvHlmlOCbe4REpe+znHQPksdMKWN9hF1ewFA4QxtyFmxdw6cSPKO1VefFa0jPpqNAQdkT6fY8MdECy4heUYsbvzqzZUOexNCQ7omuwvUKVYP7rQ==
X-YMail-OSG: 2fceihsVM1mgiwEW8UOMf4Ku8OkZv6wvO1kKxxLRJvgkmIyx6qNAnCYk8KBEjq4
 eLu9uG2QDGdxLGlGF0zt2rh0aF0YW06tVtuBG2P0JWv9gfvey_cc60V46A.pmxbzeIgg6fOfX3Qe
 VCdIKhdY1fffjiU3dlAe.ZKmyEOdP2UXWSQ9toqLT4J3V_I25L.YsNwk0rSKV8iX.dZNEWjFfFPr
 wor6dwNqHppC0YnoN7q59zx.dOLt2WGH1BRx.VJeyahLXd9zquygu5HwrrF6RJGnGfPtXNToDQn_
 Zf63mdsgeqzsGSQwddhpXXvDNqCdmxSzP76.iAChw49Y0b_SHZH9rG9To9rUuWJtk7cJKslRt6NH
 TKEKAQA274tSYngvl9gP7HHhKnH9hFr9l7ujeJE1vJg46Mbtv0kUawyrx7NHXjOe0BCFfadSJXDk
 oa8mkdQFMhZxry4_WSe.Y2ZWbIBHKV5quhHgB3z6sVdt3dfAHg8uONtB2ETcYKoofrBT_LDiLNAm
 chOmF_iuBrc58GAD0nonKfikgIxs3mQJqrQ6txtEc_aYG5PbZ7rdZ1aUodKTzxelCL5eS0oRdlI4
 k71p.P7Z5O1eszIRlW.e1iSY7VZjQevO.gStLELeJC.VAzlkCvCY4b.YYYF10FcYoN3P2bFdlSxE
 Z7wk5DHHMkZuBFCDt9M6cijtdPUSp4UxLf6IvfgMfNqYipIEABb.kur6aqTqEvo5E9Y.K8WHg9kj
 zaAneyQ10qoj_UbKTWuYdw3Bf6c7Bfu17PQ7p7WcHTi0YpSE5vdtg7N6hCge7hKJIqq2G1rk6w5X
 PEegzuLhvLSrdTaMdndKSHnIQUKulrbZL8Tu6yC5.TySrAbPMUicbT9YyBW07JlheuVcdJKRGetZ
 COg0PUSDmiqCSuAtG_nPrSRtwFZ.zAcGL6KbA7usKlf2w15mmnqa5qbJkMjqAFJAtMq0JQ7ZwrEE
 0D1dp7kDbrCXQeT5C5RcnzaFFwqAc6hhtaef9N5pvkCksKMHMcHCbOHD4sbTUuzGPKxyEDgjUK98
 mNG53BnNz4nD8FAVotvox2l7bYnXI06JuGg0a_T8OQeDwH4Mu0KKIpL6.jxEmD2aNPDiKI8VdPVj
 y9Vpy99_umChR4FDkC047R3kDc.mjuFKZFGPlDM657wN3j0AtrUUxKIbqoOKA4PBDDTpcYR._tDu
 cMwtayVRjHci4PS4u4ik62Ga_DBC86PnGqAFAbYmtAz_Hbt39iyHWr1o2.CltwmT8Y8EW7Ovew2_
 OIrHPbc9avbVo.jFtRhFhsmPITaH1TX2W4GYNmSDJfMY6ZIXktNSdKKnaLrTgU2.5VPSLzdjnu9M
 6wgkM.bc.KJYNSP2htD6ubjbvz8H9L.ewpYtNqpAwDcRDSx9hUd5BdPOP2qbYhdiM7.8AG7KZGRG
 ngQbkCbVquYPDUNaBd6tOHJft7yUGzYxDu4c9Y78JHW8YcCbSVquMXUXnuXMpeyJBY6NpxdFqz42
 kpbANaIUcEv9w9OBSBjJDosvKquomJ1J30P4uIh1r7BLMkPVcJXn0eQO52TYUFQydo79bWppeKDC
 zG16FIHaO77dyEp695vZ5OI.JYENO7eAYPZUH7NP.my.y1UJDdD2rNdjuoztvJn4.lZW2UPAYs6E
 FPTwavQttKEWxf2CvhEmwk3aGDOvw6l0tcfWmM5NB8S3AbMs2oRUwtzYUNbhsvyD8Lwa_crDYMXc
 dfG7dDbK.4kcT9Dz23FkX4cxNeDGhRLDWq2itH119sR9WYsLa0SsEuvSCu1TQ8l6Hsf87iH1Urzl
 .pdlrouO_7ivBdkfDQrlX52KtobcvERKMn.AXhM9gZWmMZ5Qm3BbPaVsZeMpMllTriSFZddqR6r5
 JxZ.GrZnEtqPkiIxRMvNpGDqozNbvOcDfdAX5UmkGhpd5mM12SoGdmrMLse3d5XgamZnLTE5Us4r
 gAxQd7zDihXQ0rNaUBn5p26tv5M98m0CyUtjHGCvlJ7i2Ue4HfgBdkU38LG9Zblfq_pQ0qxqlsir
 URyUbnHsAn1lJrsqCYaO524h5c_i_04Mj6cHMh89J4loBmX6Br5aH6oXICRq2XzoeXfgiGrQl0rO
 U6Who_mI7y1subWZbQorbMFlMITy_cQw1p9j84pTJb9fuL0LcnRkA8fPMwxA3NTr53rtWPVE6tQG
 QQSpuoHrHU1uPphdUTOWrZa4KsrQ6TMH3p1HnAtfkkG3b76Zis24VYj5NpbZQ7kWV83EQmUq9peM
 fLKKn3cIoxPztoCkiDxLd9x9XCXdqupm5nmVDszPw_xKu5sNI89RwpntqN5UEtOSEbvbE2dIeg.p
 3uACDwediRQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 22:06:36 +0000
Received: by hermes--production-ne1-6944b4579f-wdnx4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f69da4d37d578dc3e696df55274f3711;
          Sun, 02 Oct 2022 22:06:32 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com>
Date: Sun, 2 Oct 2022 15:06:30 -0700
Cc: freebsd-arm@freebsd.org,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <60EEB4B0-C474-4319-B404-4911B2495AAF@yahoo.com>
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <64C1085D-D3F8-45A3-80FB-4B88F81E480E@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgdNH0cYHz3mJ8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=iTy2Qt+S;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 13:46, Klaus K=C3=BCchemann =
 wrote:

> Am 02.10.2022 um 22:18 schrieb Klaus K=C3=BCchemann =
:
>> . . .
>=20
> =E2=80=A6 but of course, Mark, that is correct :
> overwriting parts of the msdos-partition by linux ones

I was not making such a suggestion. I expect that
Fedora would get the same problems. If Fedora did
not get the problems, that could get into finding
out what distinction(s) makes for the difference
in U-Boot behavior. (Not something I'm likely to
do.)

> could be the last resort to save something=E2=80=A6
> but if linux had patched inside u-boot, as you did it for Bob, I would =
see other problems coming=E2=80=A6
>=20

Of all things, I actually use my patched FreeBSD
U-Boot (usb_pgood_delay and such) on Fedora in
order for Fedora to manage to boot from my media:
Fedora's U-Boot build has the same problem with
the media type that FreeBSD's u-boot does.

So I only deal with building one U-Boot in one
environment. For my context, so far, things have
been compatible enough to get by with this. Not
that I'd recommend it as a general procedure.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  2 22:55:47 2022
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 4MgfT370Jpz4dn0c
	for ; Sun,  2 Oct 2022 22:55:51 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4MgfT3178Nz3pjh
	for ; Sun,  2 Oct 2022 22:55:51 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x62c.google.com with SMTP id b2so18866628eja.6
        for ; Sun, 02 Oct 2022 15:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=zSnh9gxEzfKJxx6HbW2XFs8hr3fibmu1grwnleG3UiY=;
        b=GnWwhgkvlnikfi6yzfr6FkCV1ejkj1B1ojnpwWpe5Ajc0prZSesWwTG9jhmw2geuxe
         9elMyFERie54HOXWA8ZxzCNQAtnujYTg5qiuwmEdjwVxNHRETVJ1MB2IPnWBA0OusqxA
         4fkXu87+6zQ+/0PRz7K7NmAXGAaBLeFDNZ8nfqr1xmDkXLAy787vN1WiY7k0CvJ8A0pz
         bWdNVE9HDF2ppr614rIptyHj8eiV2SAZaurPyTKxjvMPsK8RQ5Z4NT3A4ObskAYfn8iE
         kpryaYcESSQ3IXsaXQdrYxAcp5meLwBEWTa7qjbXiJweyzcCpAHr8qf5+K3zkWqrtDLU
         /RYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=zSnh9gxEzfKJxx6HbW2XFs8hr3fibmu1grwnleG3UiY=;
        b=TV+sQeMHEM6jxhFbpdeUK9jJPp4CxJN5abErHmK4IqHOv+QCipp73fsIfZJjKrAPsm
         sg96SgEPiJ6hJ1s45b+aYiDRfi3fVjH6Cyn5XpXys7BkORLfecPi8ay90tEwRI+7/ITV
         FMDQb4G0M3hTFkUazCqD1YxJ0Vdgts0uBDeESXqZwJk9kiWcIc1ABjkwNt9hpTY2Ml9Y
         vJhQPPQZLSKjSkiEG885qLLKNwZqqa2uiNQkOh9kaSkcQMXa4/7l6I6Ka3kbaSIDrj1j
         TQ9M08nwGR8FChkApXKJP68kSrhuXw6IwAxrnyW6i1fN4gEOMizgtLolyPbzIncT/bzT
         8tnQ==
X-Gm-Message-State: ACrzQf12kTN1HtjXqxyrMCGD+0dtECejpGmNwPrHrcWDzZVjZYIrmYzO
	qGGLjcqup2k8ZvoZUYKdZ8/l8iNGvP56cg==
X-Google-Smtp-Source: AMsMyM6/R3odyi4PYCASSdbyjOyHz7YN5U1DSD+jKtmSA2Hn+zqjB6+yP5RDuTTzNas+k3zHjUYGSw==
X-Received: by 2002:a17:906:fe46:b0:73d:939a:ec99 with SMTP id wz6-20020a170906fe4600b0073d939aec99mr13561942ejb.169.1664751349897;
        Sun, 02 Oct 2022 15:55:49 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id sb25-20020a1709076d9900b00781ea761407sm4459753ejc.161.2022.10.02.15.55.48
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 15:55:49 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 00:55:47 +0200
References: <20220929002131.GA77106@www.zefox.net>
 <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com>
 
 <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com>
 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <29BC8014-45D9-4AAE-83CC-E27395573B44@yahoo.com>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <98ED8DD7-7C4D-4F38-9B83-257C2825F8FD@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgfT3178Nz3pjh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=GnWwhgkv;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.87)[-0.873];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 02.10.2022 um 23:48 schrieb Mark Millard :
>=20
> On 2022-Oct-2, at 14:43, Mark Millard  wrote:
>=20
>> On 2022-Oct-2, at 13:18, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>> . . .
>>>=20
>>>> Am 02.10.2022 um 21:48 schrieb Mark Millard :
>>>>=20
>>>> (RaspiOS and Ubuntu do not use U-Boot last I knew. So
>>>> they do not make for good comparisons for the purpose
>>>> as far as I know.)
>>>=20
>>> RaspiOS doesn=E2=80=99t , Ubuntu(and others) use u-boot since years =
=E2=80=A6
>>> while possible Ubuntu(or others) have own u-boot patches ,
>>> from guessing it seems more probable that they also will sometimes =
hang after (re)boot.
>>=20
>> Sufficiently modern Ubuntu does not use U-Boot by
>> default, at least for server builds.
>>=20
>> ubuntu-22.04.1-preinstalled-server-arm64+raspi.img
>> has:
>>=20
>> # more /mnt/config.txt=20
>> [all]
>> kernel=3Dvmlinuz
>> . . .
>>=20
>> where vmlinux is seen as:
>>=20
>> /mnt/vmlinuz
>=20
> I should have mentioned the naming convention that
> is in use: vmlinuz is a compressed variant of vmlinux
> as I remember the naming.
>=20
>> No use of U-Boot: direct booting of vmlinux via
>> the RPi* firmware's ability to do so.
>>=20
>> They do provide uboot_rpi_*.bin 's for folks that
>> want to change to use such:
>>=20
>> /mnt/uboot_rpi_3.bin
>> /mnt/uboot_rpi_4.bin
>> /mnt/uboot_rpi_arm64.bin
>>=20
>> But the supplied config.txt makes no mention of any
>> uboot*.bin and things have to be changed to cause
>> a uboot_rpi_*.bin to be involved.
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com


Yeah, you=E2=80=99re right, according to their wiki @Pi3 they used =
u-boot as the default ,
but only for SD-card boot. To boot from USB they=20
indeed used bootcode.bin to boot vmlinuz.
So no option for fbsd to test with ubuntu-msdos for Pi3USB but perhaps =
other distros.

> Am 03.10.2022 um 00:06 schrieb Mark Millard :
>=20
> =E2=80=A6=E2=80=A6..
> Fedora=E2=80=99s U-Boot build has the same problem with
> the media type that FreeBSD's u-boot does.
>=20
> So I only deal with building one U-Boot in one
> environment. For my context, so far, things have
> been compatible enough to get by with this. Not
> that I'd recommend it as a general procedure.
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20


Thanks for info,that=E2=80=99s what I assumed that there=E2=80=99s the =
same behavior on linux Fedora or others with u-boot.
Having things compatible enough ,as you said , seems the only option =
here with Pi3USB,
Unfortunately because of that we will probably not succeed patching for =
the 3b , since we do not use bootcode.bin to boot directly into FreeBSD.
For simplicity I would use the setup with the 30 or so successful =
reboots and ensure=20
Remote access to the u-boot console of the 3b.

Thanks,=20

Regards

Klaus












From nobody Mon Oct  3 00:46:24 2022
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 4MghwY6dBRz4f052
	for ; Mon,  3 Oct 2022 00:46:21 +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 4MghwX6GZgz3xdc
	for ; Mon,  3 Oct 2022 00:46:20 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2930kOlB003662
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 2 Oct 2022 17:46:24 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2930kOSV003661;
	Sun, 2 Oct 2022 17:46:24 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 2 Oct 2022 17:46:24 -0700
From: bob prohaska 
To: Klaus K??chemann 
Cc: Mark Millard , freebsd-arm@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221003004624.GA3381@www.zefox.net>
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@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: 4MghwX6GZgz3xdc
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[googlemail.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
> 
> hard to read and remember every log but I thought Bob wrote about aprox. 30 successful reboots after the mdelay patch,

That is correct. Shortly afterward I tried a second usb-sata enclosure.

I didn't immediately notice a difference and though it didn't matter.
You comments served to make me think again.

> while of course that could be coincidence, who really knows what happens in this untrackable inconsistent behavior of the usb-boot?!

Unfortunately in this case, human inconsistency (my own, alas) was compounding at least
part of the trouble. 

The more troublesome bridge contains a JMS577 chip, the less troublesome JMS576.
https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.html
Contains a brief description, but I didn't see much quantitative information.

I've reverted the host to the less troublesome JMS576 and will try to 
reproduce some of the earlier results as a sanity check.

Thanks for rattling my cage!

bob prohaska
 


> 
> 
> 
> 

From nobody Mon Oct  3 01:28:58 2022
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 4Mgjst4zw8z4f4DK
	for ; Mon,  3 Oct 2022 01:29:06 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530])
	(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 4Mgjsr3btGz42NR
	for ; Mon,  3 Oct 2022 01:29:04 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x530.google.com with SMTP id u21so8434159edi.9
        for ; Sun, 02 Oct 2022 18:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=UYbjyoJYDReC/eOzyM1eEDBMXp5h0KrHII54LEHdni8=;
        b=I0AOn++MxjC6FLlru9hOLKiOeyKDz2iCxnmh9aFWPDEH9vohVYNmh+LWSAt19o4wZZ
         H+4IcxIft5Fz3Z5ixw6evxQ421FJxN3r46V3S05v/T66I4iCKiuRsL81t4QAlKkxSnHy
         14MSgwaEiT3oZY368S30ZvqJwnby97NOS7OGMtyyU4ninACnBUSGJuU5SRu5tDGrKDB4
         l3AGS/apb3HFACyG3z8avTk4Ql7kTFaQEUkZASO974Kj9+oQrd/CN6hqnKjNHvl+BHsS
         Jt7U373gbzNfzargnvyLEG2vXNrK0hKn62RHgefskf/fqLoebWHGBsOXVFEYmPWHFCqV
         Bzbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=UYbjyoJYDReC/eOzyM1eEDBMXp5h0KrHII54LEHdni8=;
        b=rRz+Pxixcp8hDf38akCUGH8LIADHKFJbcDuY/1S3hxY9hv8UeSA1CsOwjBzrAnrzV2
         DtoWhahM/XbBq++mSlFkbC/kOxYzwandK9gvl286JYFiRmhSmgw0M7YZWW8BSAHJo9ol
         y+cpZRRXWspUh8Wi0faF6AVstke1cc9wL494QtnPuY687QQy5kxsFSzfJwVJwg8ZosXe
         Tmf5XALEW0nJ/imfqjXEz765XS3a38BjHVbACS5CFMFgmwacaAQTvmQl/hMFJ+bL7vTp
         lkSEw62HaB+KkSamcLW/vrJ0AHROB/5mwXnBn0iR6H2jBvKQjnzjyv0vIQURhy+T2Pqx
         MTjg==
X-Gm-Message-State: ACrzQf1yjAfQkt3Jzwz2JKVzTo2I6uKUlORF12S+ekw/79xma1uP8akT
	hYAye97gTijdIvYFvGOrIIE=
X-Google-Smtp-Source: AMsMyM5MtV/yrxo7hbuQ9M5E16YhvufJNgMfJ0OFSPztuNt9QSa1/Xl9Kc4U+00C+0DCrjWbxm+Eow==
X-Received: by 2002:a05:6402:14c9:b0:459:1a5b:6c47 with SMTP id f9-20020a05640214c900b004591a5b6c47mr332985edx.426.1664760541918;
        Sun, 02 Oct 2022 18:29:01 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id s6-20020a170906bc4600b0078b03d57fa7sm1381602ejv.34.2022.10.02.18.29.00
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 18:29:01 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 03:28:58 +0200
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
To: bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20221003004624.GA3381@www.zefox.net>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgjsr3btGz42NR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=I0AOn++M;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 03.10.2022 um 02:46 schrieb bob prohaska :
>=20
> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
>>=20
>> hard to read and remember every log but I thought Bob wrote about =
aprox. 30 successful reboots after the mdelay patch,
>=20
> That is correct. Shortly afterward I tried a second usb-sata =
enclosure.
>=20
> I didn't immediately notice a difference and though it didn't matter.
> You comments served to make me think again.
>=20
>> while of course that could be coincidence, who really knows what =
happens in this untrackable inconsistent behavior of the usb-boot?!
>=20
> Unfortunately in this case, human inconsistency (my own, alas) was =
compounding at least
> part of the trouble.=20
>=20
> The more troublesome bridge contains a JMS577 chip, the less =
troublesome JMS576.
> =
https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.ht=
ml
> Contains a brief description, but I didn't see much quantitative =
information.
>=20
> I've reverted the host to the less troublesome JMS576 and will try to=20=

> reproduce some of the earlier results as a sanity check.
>=20
> Thanks for rattling my cage!
>=20
> bob prohaska

turns out that maybe you as a professional physicist are the one with =
the biggest chance to free the Pi3 boot behavior out of inconsistenteny =
:-)
Many years ago I sold tons of self modified power supplies for Mac =
machines, which enabled the FireWire functionality, I found out some =
tricks to solder some Cables , but I never knew exactly why it worked, I =
even didn=E2=80=99t use an oscillator or any measurement :-)
Some people in the web say that it=E2=80=99s the ethernet port on the =
USB hub of the Pi3 which stops to give 25MHZ boost to the USB port at =
boot,
They tricked it out by plugging RNG or oscillator or something like that =
,
No way for me as an electronics illiterate to give an appropriate answer =
what that does mean :-)
Sure you have more capability to test which JMS577 and JMS576  chip =
exactly gives what kind power(or Speed;-) to the Usb hub.

Best of course would be to get rid off external boot loaders like u-boot =
ans use bootcode.bin,
But that would be a software project little too big for us, I guess.


thanks

Regards


Klaus


From nobody Mon Oct  3 02:30:57 2022
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 4MglFR2x3fz4fBxn
	for ; Mon,  3 Oct 2022 02:31:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4MglFP1pM7z3Cwr
	for ; Mon,  3 Oct 2022 02:31:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664764262; bh=geRrdksSZDgButiT6QHQh9Rdk+1q6NsBpGIa5BnGEss=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NTtEpcs7mjIwCgXKpmEygnGRwPnreO7z1pLR3EZdLPMcRQR5HrE6WGBrQ/ZBwrdbFYjl+dwtdIdbv338QFhGS1eokC1xeJq5MYuzRRH0cd7IKeFaYshYFYs1kG6XxSYQYz03KP+UfOzflKHv5QEB6tyz5UsT5FGM7ockfFLYMYsm5bji2hQrT03gqE2M9WNAuG+KQlCjo1Lcghj2MYj2Cd9UJ6JTuVDlyrwfStCkTKpbHu/sKoPAgCD8JFVaw32RLw+XoUya0tAniZ/n4YqywyWtC4qDB3VfSSIMEjWpMsdQvMPRgBfTxYJ4yAboZAaT2uiNYPpAOivBGwb0iB7zgg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664764262; bh=JEq4bMIvX0eIXbDu6fRhpRAqfYkBUbkOO8wpN/LGUKy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l43xyzXiTrndVrOyN8D2s0lhOF+nI14dPvuiNBRcQZqJsWH4jRy1Bqnxc1Z+wa2pm5HrXTMTfU3Fug7wtV00ckShCda6E5BtlBzdsBuWpNZMWJpGclDa7a7lWBdXAD0dTJTe3WTvJkbwoBHZ208X9mjG5X9e5BG7qlx3z2Uz5G73WeDlE0teuGcASQ4dygj3JwQ9ZbYNwTo/ARMonWzzR+e0Y5a6etBHfuOfugUaR5KclkQ5YTMH+5YehuXL5kboVP1vx7AoUv5kJBlaf9RtPUsQJMD8ioM2k9inBOoprU4NUYvMaZVmpUVXnTYDw32kvYX50fwvvjqguRR3NkZ79A==
X-YMail-OSG: oCENkqIVM1mwvPXPfoRYPGEFH6E_qnRyuVuYTtp8rSuusA6CXbd7tggfkB0G6d9
 fZ3n2F2rslN8zW118axb2E9_hjs9W8vC3l_8iY1sNo1.XpQZzzbJdl3MCaEMAEGU1chhMATFcc3A
 S2CGvdSFfbxToL.WzV6Fe0b3KEBDMf37h0Xj_EZzTs.xzsf4tYfKU6LZk_Y1SUvNz2i9iplFhKow
 OsCkatjWGt0xvx8qEy1FUy7X4J6Az.nRVZ3ODqH4Qy8EYZOOSBBLs2.TxpFgYQZXGfGK505wMVbl
 ab7huD44N1jn_W6ONGXkUmyO8dbXLbaAFuRgOIXdcheG4UT5I9fv4jK5rrec3g621ZOEY21c1i49
 GdE7djrDKrQSHa4psw29Wx_zPhKSEEQo2rZ_A2Hey4tErY6ZcCV77APRvSJH5BmEl2ILTIqDL3lf
 ptEUD7QlaoTVf4ZHg.hb9HkWmgqGSFgbFQTSI9o6wu3oh4BS44TmaaMtplOVz7jEQh.e_VUOwTaA
 UKqMtxtpxTkadu9Q_eD6qVORBTpPe4xhuEAvsdWcHfn.Kmhox0it20P1iuTimni.c29R05Pa0ka0
 GLy8DZNPrbDM7qWfb1GvUzsJeCvwDJfgYKSuRpENyZGYOU9J2dTbGqRyVNWDk40.cJwzNGPfhppF
 7MlTK84PViHzbtoiE59SEJpLubgBGfylrfzHmTnIGu2GUgIQsT9qQ6Ycj9BK9g_8G6YCWkM18YPo
 yNkLQzrFTdPgfmKwq7YIg14EQXrTPO3SjvyvyW5tvNMOybgRb31.AQh9hxeBrTcfDGNehbKsRwit
 fU4Z1CQYzhpmhGr37es112KxpicxmCU430rfLRGhq9mboOaEsOOfeLbZskDy_61ohPAwFTbDSEbx
 UXTRTx2gURQ9z_6g_hZHec4LiDDNzBtRuybGXtx_AxcsHtwzXRYZiRfNDq8FolK1Jmm8FMaLoGwz
 gjvKWcRwPuqaXX0rZHQvPRJXaugH6CMW.3XK7dmaq1rVSPlSt7.cTiLZ_OF210A3RhubbpYV_f6y
 UOdQ175Zk6AK8ec7_U0pJ2.dDE12.fOmvdkcZ_nWbGnQaATOkfbB5A5F_w3aEQj0pVP6Dlxetp1M
 pMGTv3UX0Sso5hCDiTPBpLY.4x3hQr6tq7BuzQLThKKrBQJRj9wpPfd4UV4DBDhAYPYxh7XXEYv9
 djY_2jPsaDoTr1oQR8hupEeDBBi_FLsfUtPmqCNYwdbbxUf5WAfPQ9UCSKcHnkVoBki8nzD47_eo
 AJrTW9Ky5lIP502TaUebRFhIVaPc3X31L7IPhQBcqdju.jRM7gPJCggRKXUqeZpGLeAfb35OIHLx
 pd57DavSkTpUXB3S2E.PYztnEBZHRdev0BMmcEp3wjV_uAjr.KCyM0NZaBouJofvFg8pu8fqeigT
 fhP4prpfEndavob7robXOFYynkEb8aX6RaHedJNmG9nlBdrAa69TxVqX5wtQ.8lZdB3xRGHf1Oft
 8mKBKxXh3fl5SOPxjJXRVJ2UiWTqlUfaxNMwRdfAMMOJSfR8J6UNGL.DMH2UjTte9Dblgxza.MuM
 8BV.NgaXk7Z_H0qoJ7q8A5GuCk_YL7CK6e5VRl0menShHAF3BLfFpmqKBtJcRtig5KH5olqctN5J
 QDSiTW8sogLOuukYy4GXrPGAt8DkY2xs2RTnOC26X5tKAqoHXkU4hsuxd.97NR6iG4iGwDRoqYdq
 0gQHfVorTLiTequ8tQIUip4DWEcdwf3MkG14ElbBzSTddjLeqnRgck13rnqW.rZEnR41jyoqVa1E
 IjvHbCR1myErbqIIXrxVTA_p.t7IrKFSid4Aqdau571k3EoR5yqIKn2bylZfwIO8QJkEr9n89flG
 9NASJISsRlW8oCgTkSEjQprO4a4LS3olyzbq4HOXCJvzuh3rNvGASuEkBTdDSYtrfJjCaNy8uDTh
 XsKEm9MeepN3bHSPqZd_7c00X_TBO08JiRE3lBkkNdcpVLch8koFIxslYeU6OOLBZSehvfiblBZK
 eXIJ2B2g7jRtDPibhKTs4C5uKvoDkKA3I7vEQfIWjAmnlGEdvtcosY1pbnfkI.peFJKw9dgDeTAa
 ejauXR4qW22ZpbynDzoYg3Z4SJgyKWEWPJ3oWnm1hfDYPShA6oFOxXeuo4zpn53vYZRnygwQH5g9
 1VIBlRRbgJS9TZYG9OjBiIe4JXIiv830PYcmYqYFDrZek2sRFnzB0ragehDryd2spdESGajjJaTZ
 GAaFkZ.NBGZbNcPv8w9bkKy8z0CyU22O_UVuPEobUhpH8GwYhK6wzGCF.tnZ9C0MF.FMFpTwRy23
 8q4MT8qyHLA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Oct 2022 02:31:02 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-jf7ft (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fe3815006113e3b953e91e5944a6a382;
          Mon, 03 Oct 2022 02:30:59 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221003004624.GA3381@www.zefox.net>
Date: Sun, 2 Oct 2022 19:30:57 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MglFP1pM7z3Cwr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=NTtEpcs7;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-2, at 17:46, bob prohaska  wrote:

> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
>>=20
>> hard to read and remember every log but I thought Bob wrote about =
aprox. 30 successful reboots after the mdelay patch,
>=20
> That is correct. Shortly afterward I tried a second usb-sata =
enclosure.
>=20
> I didn't immediately notice a difference and though it didn't matter.
> You comments served to make me think again.
>=20
>> while of course that could be coincidence, who really knows what =
happens in this untrackable inconsistent behavior of the usb-boot?!
>=20
> Unfortunately in this case, human inconsistency (my own, alas) was =
compounding at least
> part of the trouble.=20
>=20
> The more troublesome bridge contains a JMS577 chip, the less =
troublesome JMS576.

I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (later).
I'm not aware of a 0x0576 example in the set at all.

(The JMS??? naming and the 0x0??? product ID's normally match for
the ??? part.)

> =
https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.ht=
ml
> Contains a brief description, but I didn't see much quantitative =
information.
>=20
> I've reverted the host to the less troublesome JMS576 and will try to=20=

> reproduce some of the earlier results as a sanity check.

I'll note that I've reverted my active environment back to
its normal content. I've not figured out a way to get
reasonable evidence, given the combinations we have observed.

I'll note that RPi3 EDK2 UEFI is not an option as far as I
know. I've never had it work for two things that I checked
up front:

A) microsd cards: Even pre-existing file names for msdosfs
   end up messed up.

B) Serial console: once multi-user (or so) starts it is
   garbage.

(I can ssh into the boot but I've not done much that way,
given the problems reported above.)

Another issue is that Device Tree is needed instead of
ACPI because the ACPI is non-standard [matching Microsoft].
(For RPi4B EDK2 I use UEFI/ACPI, it being based on the
standard. Some of the RPi4B's normally run under the
UEFI/ACPI environment.)

I retried RPi3B EDK2 today and the above is still the
status for it.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct  3 03:26:35 2022
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 4MgmTW5C7qz4fHj0
	for ; Mon,  3 Oct 2022 03:26:39 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630])
	(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 4MgmTV6tktz3Fxf
	for ; Mon,  3 Oct 2022 03:26:38 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x630.google.com with SMTP id sd10so19545311ejc.2
        for ; Sun, 02 Oct 2022 20:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=M2C0GmAqkMD5FYTEMNgNRmlMty/5bOvwxrS+c8yg2YA=;
        b=ca+41UrrG2IvZMUJ+Sw6dxKCAjeokCSVZGbGfaWe1qLBeElwRtdHEMnN1NjBuGu6nY
         7fkRlm0eW9sqG1PHLzdwuk+1QN1CrnkAKonRz7kMwtrR+cscJsat03tl2EIlPS8/ywKm
         F/KvXWhNvH2KOhdpZq2uNiX6Q9v5hMmvh5uk8VUM5Pkgpu0KaGu8wsntJrZIbirPAkYN
         6MIcoeVYY3SsGCgwyv4MFInQPJhnZVWVYguVjWN2eH4Vkcc5Jqoq+DYW3ksBeGH74KsG
         HcWPN0B6cQZWQ6AHaz8Og33Y/DB7RdNR6PMVZeGzTLCjLOBkgPXRwjdQpgLOHM3pot2M
         qJPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=M2C0GmAqkMD5FYTEMNgNRmlMty/5bOvwxrS+c8yg2YA=;
        b=ZF6ExNIx4SUrqvTU51sA7U+csio2uoAslXle8YndtZxzNZq9aZu/EhB2AOBwK/BL6G
         MMpp1UOqAbS23b6EDzvQWOK8BXAhym5bRH8j5sBFgZWmPyOLhVlFKW2Qx28NaG5rqUC/
         7nYK631kZx8pjlEnY39nHyT5PKFaIMdkKwtJSJ80guEa3+57Q8tf28sHY/qL5enNHiDB
         Luw/SBbV3EK6TiML9YNLhSFK+xIQZb5Ur3obuyFLp1ke5xEb2MfERf1N1krZ4wSB4g4e
         jCO7OJcew1oWHxvrDy+NBdMJzgsG671IUTV0t8jbX7blww8+F9TEfGf5UIKYvlzB5THC
         yXHQ==
X-Gm-Message-State: ACrzQf0hnQiiN0vmxkxgGbYklbxDVI3BE1uWdWfJ/a1zb0NljiWon1Xq
	ttNeVKn8fpWv7ux1ANtG8oT1cTTxF0wKWw==
X-Google-Smtp-Source: AMsMyM6e52/xnGZ+B1Uj0J+xKqowgAVU39ek50wJIvPcoEMf1gurgEDo8JBHdt1xjxLOBUv1Qy9glQ==
X-Received: by 2002:a17:906:fc6:b0:72f:d080:416 with SMTP id c6-20020a1709060fc600b0072fd0800416mr13835307ejk.1.1664767597875;
        Sun, 02 Oct 2022 20:26:37 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id e6-20020aa7d7c6000000b00451319a43dasm6493125eds.2.2022.10.02.20.26.36
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 20:26:37 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 05:26:35 +0200
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
To: Mark Millard ,
 bob prohaska ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgmTV6tktz3Fxf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=ca+41Urr;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 03.10.2022 um 04:30 schrieb Mark Millard :
>=20
> On 2022-Oct-2, at 17:46, bob prohaska  wrote:
>=20
>> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
>>>=20
>>> hard to read and remember every log but I thought Bob wrote about =
aprox. 30 successful reboots after the mdelay patch,
>>=20
>> That is correct. Shortly afterward I tried a second usb-sata =
enclosure.
>>=20
>> I didn't immediately notice a difference and though it didn't matter.
>> You comments served to make me think again.
>>=20
>>> while of course that could be coincidence, who really knows what =
happens in this untrackable inconsistent behavior of the usb-boot?!
>>=20
>> Unfortunately in this case, human inconsistency (my own, alas) was =
compounding at least
>> part of the trouble.=20
>>=20
>> The more troublesome bridge contains a JMS577 chip, the less =
troublesome JMS576.
>=20
> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (later).
> I'm not aware of a 0x0576 example in the set at all.
>=20
> (The JMS??? naming and the 0x0??? product ID's normally match for
> the ??? part.)
>=20
>> =
https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.ht=
ml
>> Contains a brief description, but I didn't see much quantitative =
information.
>>=20
>> I've reverted the host to the less troublesome JMS576 and will try to=20=

>> reproduce some of the earlier results as a sanity check.
>=20
> I'll note that I've reverted my active environment back to
> its normal content. I've not figured out a way to get
> reasonable evidence, given the combinations we have observed.
>=20
> I'll note that RPi3 EDK2 UEFI is not an option as far as I
> know. I've never had it work for two things that I checked
> up front:
>=20
> A) microsd cards: Even pre-existing file names for msdosfs
>   end up messed up.
>=20
> B) Serial console: once multi-user (or so) starts it is
>   garbage
>=20
> (I can ssh into the boot but I've not done much that way,
> given the problems reported above.)
>=20
> Another issue is that Device Tree is needed instead of
> ACPI because the ACPI is non-standard [matching Microsoft].
> (For RPi4B EDK2 I use UEFI/ACPI, it being based on the
> standard. Some of the RPi4B's normally run under the
> UEFI/ACPI environment.)
>=20
> I retried RPi3B EDK2 today and the above is still the
> status for it.
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

you can probably fix issue B)(MultiUserGarbage) by changing the baudrate =
on the fly=E2=80=A6
IIRC e.g. with picocom it was by pressing ctrl-k or so =E2=80=A6
But from past experience I also think that EDK2 is not the solution=E2=80=A6=



> Am 03.10.2022 um 04:10 schrieb bob prohaska :

> I'd like to see FreeBSD run well on readily available, inexpensive =
hardware. That. used to be an i386 PC clone. Soon it'll be something =
else. I hope some flavor of Pi. ..
> .. I'm just a squeaky wheel.

We squeaky wheels tend to use squeaky Operating Systems on squeaky =
hardware :-) Ha Ha..
For the Pi platform we would have to immediately begin developing =
drivers like Wifi, audio, perhaps graphics=20
to be an appropriate fbsd-client-setup.
Understanding bootloaders like here is a good starting point but if we =
are not willing to start the driver thing on our own,
Without the help of any fbsd-developer,
that will be the end of aarch64 cheap hardware for FreeBSD.
Instead a cheaper amd64 will do it(makes good progress but even amd is =
sometimes frustrating lacking features such as appropriate=20
Bluetooth audio or so).

Regards

Klaus






From nobody Mon Oct  3 03:40:34 2022
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 4Mgmnq6fbGz4fK4d
	for ; Mon,  3 Oct 2022 03:40:47 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(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 4Mgmnq0CPKz3Hrd
	for ; Mon,  3 Oct 2022 03:40:46 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ej1-x62e.google.com with SMTP id kg6so4185196ejc.9
        for ; Sun, 02 Oct 2022 20:40:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=QwZbQE4fiW9z0ms/yi3lWKV93iwh7NDGEEW/JKSPn4w=;
        b=rbxS4m/GxqvGYFCHYS+uqixmF+1Nda4M0/Qz89YhBMoHOF4xB/rnhjHI+HyVHtGjJK
         +3g9RNvxtnt5jSvZZcmwyi0MQJYAA557lesqRhI/0MuFgWC/YBfNrA3GOVUAx2zbmwlZ
         TYOpyRtbp/yE56H+Q9KmVVVi88nTeQcvgWIzCjZIli9je4Sp7IxLAWvkmpZvz7d5tu1v
         v+7n1wrc5KGStzqamb9fh9ZXa6e87PDXTQHrZGGVXQxS0Sqegg4Aq0Blx3/D1zDI/6+A
         z1GBSUie/yQxmB4q5QDTEvGw08F17VpbXNb83tGekBGIeBgtHkJvOC6w1bxh50I3aa1g
         h14w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=QwZbQE4fiW9z0ms/yi3lWKV93iwh7NDGEEW/JKSPn4w=;
        b=ONQLWA+ajKS7QsyFqLyTHBpGed9uKuwWuDI1lQSaaigMLL5CUUZzvkhX9CsutYKQOh
         asHxw7W1UinHS/vCWwn+25OsZzJ08iYuR/eXVfjOv4p5SX87sN3cCE8g1FmsFcya0lnA
         8h9LG2/+EBQHL/NmoKqORyEc39YS1oXH3qze0nXavwR1FPlLJRfPVi7fvtS7Rmv2ICcc
         rC48NqHhwa0dV1HOYO1GXzFVnsRlvCwRKs60KDXU6AKwbkjjUuoMVMtyb5zE2A4zZvN4
         2svT87/0OUQdwBthcSEvlTgTOtVL0oHqhSdeVSS7rTyJXNcGA8j4d2olfKUF6VcJ0AmG
         xtEg==
X-Gm-Message-State: ACrzQf3XWkduW5ivI1qtbi4elagMsx+nUgg5kj1itqRJ+UqomyEgbFZx
	e3SYP471IEXZJ32Bq8lkIpesgAP7oax1Q0n9wuGViQ==
X-Google-Smtp-Source: AMsMyM4N2Myp++AyAQjYQEC5tl2jT0KV1EosN0AsZO0scXxqchvo2C7T0zRFWELmbUeqb80fst/31gW7WO7JVPusKv8=
X-Received: by 2002:a17:907:e91:b0:782:607a:8dc9 with SMTP id
 ho17-20020a1709070e9100b00782607a8dc9mr14147025ejc.729.1664768445182; Sun, 02
 Oct 2022 20:40:45 -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: 
 <20221001174724.GA98055@www.zefox.net> 
 <20221001193033.GA98348@www.zefox.net> <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com> <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com> <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
  <20221003004624.GA3381@www.zefox.net>
  <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
In-Reply-To: <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
From: Warner Losh 
Date: Sun, 2 Oct 2022 21:40:34 -0600
Message-ID: 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
To: =?UTF-8?Q?Klaus_K=C3=BCchemann?= 
Cc: Mark Millard , bob prohaska , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000cf0c2705ea191b18"
X-Rspamd-Queue-Id: 4Mgmnq0CPKz3Hrd
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="rbxS4m/G";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62e) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[googlemail.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[yahoo.com,www.zefox.net,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000cf0c2705ea191b18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 2, 2022 at 9:26 PM Klaus K=C3=BCchemann 
wrote:

>
>
> > Am 03.10.2022 um 04:30 schrieb Mark Millard :
> >
> > On 2022-Oct-2, at 17:46, bob prohaska  wrote:
> >
> >> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
> >>>
> >>> hard to read and remember every log but I thought Bob wrote about
> aprox. 30 successful reboots after the mdelay patch,
> >>
> >> That is correct. Shortly afterward I tried a second usb-sata enclosure=
.
> >>
> >> I didn't immediately notice a difference and though it didn't matter.
> >> You comments served to make me think again.
> >>
> >>> while of course that could be coincidence, who really knows what
> happens in this untrackable inconsistent behavior of the usb-boot?!
> >>
> >> Unfortunately in this case, human inconsistency (my own, alas) was
> compounding at least
> >> part of the trouble.
> >>
> >> The more troublesome bridge contains a JMS577 chip, the less
> troublesome JMS576.
> >
> > I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (later).
> > I'm not aware of a 0x0576 example in the set at all.
> >
> > (The JMS??? naming and the 0x0??? product ID's normally match for
> > the ??? part.)
> >
> >>
> https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.h=
tml
> >> Contains a brief description, but I didn't see much quantitative
> information.
> >>
> >> I've reverted the host to the less troublesome JMS576 and will try to
> >> reproduce some of the earlier results as a sanity check.
> >
> > I'll note that I've reverted my active environment back to
> > its normal content. I've not figured out a way to get
> > reasonable evidence, given the combinations we have observed.
> >
> > I'll note that RPi3 EDK2 UEFI is not an option as far as I
> > know. I've never had it work for two things that I checked
> > up front:
> >
> > A) microsd cards: Even pre-existing file names for msdosfs
> >   end up messed up.
> >
> > B) Serial console: once multi-user (or so) starts it is
> >   garbage
> >
> > (I can ssh into the boot but I've not done much that way,
> > given the problems reported above.)
> >
> > Another issue is that Device Tree is needed instead of
> > ACPI because the ACPI is non-standard [matching Microsoft].
> > (For RPi4B EDK2 I use UEFI/ACPI, it being based on the
> > standard. Some of the RPi4B's normally run under the
> > UEFI/ACPI environment.)
> >
> > I retried RPi3B EDK2 today and the above is still the
> > status for it.
> >
> >
> > =3D=3D=3D
> > Mark Millard
> > marklmi at yahoo.com
>
> you can probably fix issue B)(MultiUserGarbage) by changing the baudrate
> on the fly=E2=80=A6
> IIRC e.g. with picocom it was by pressing ctrl-k or so =E2=80=A6
> But from past experience I also think that EDK2 is not the solution=E2=80=
=A6
>
>
> > Am 03.10.2022 um 04:10 schrieb bob prohaska :
>
> > I'd like to see FreeBSD run well on readily available, inexpensive
> hardware. That. used to be an i386 PC clone. Soon it'll be something else=
.
> I hope some flavor of Pi. ..
> > .. I'm just a squeaky wheel.
>
> We squeaky wheels tend to use squeaky Operating Systems on squeaky
> hardware :-) Ha Ha..
> For the Pi platform we would have to immediately begin developing drivers
> like Wifi, audio, perhaps graphics
> to be an appropriate fbsd-client-setup.
> Understanding bootloaders like here is a good starting point but if we ar=
e
> not willing to start the driver thing on our own,
> Without the help of any fbsd-developer,
> that will be the end of aarch64 cheap hardware for FreeBSD.
> Instead a cheaper amd64 will do it(makes good progress but even amd is
> sometimes frustrating lacking features such as appropriate
> Bluetooth audio or so).
>

The situation with rpi is more complex than the other arm64 boards that are
supported given the disparity in the availability
and timeliness of documentation for its parts and the difficulty, at least
in the past, to get proper support for people that tried
to make things better. It isn't helped by the hoops that u-boot has to jump
through to boot on this platform to be sure,
which is what you are running into here.

Warner

--000000000000cf0c2705ea191b18
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Oct 2, 2022 at 9:26 PM Klaus =
K=C3=BCchemann <maciphone2@=
googlemail.com> wrote:




> Am 03.10.2022 um 04:30 schrieb Mark Millard <marklmi@yahoo.com>:

> 

> On 2022-Oct-2, at 17:46, bob prohaska <fbsd@www.zefox.net> wrote:

> 

>> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:<=
br>
>>> 

>>> hard to read and remember every log but I thought Bob wrote ab=
out aprox. 30 successful reboots after the mdelay patch,

>> 

>> That is correct. Shortly afterward I tried a second usb-sata enclo=
sure.

>> 

>> I didn't immediately notice a difference and though it didn=
9;t matter.

>> You comments served to make me think again.

>> 

>>> while of course that could be coincidence, who really knows wh=
at happens in this untrackable inconsistent behavior of the usb-boot?!

>> 

>> Unfortunately in this case, human inconsistency (my own, alas) was=
 compounding at least

>> part of the trouble. 

>> 

>> The more troublesome bridge contains a JMS577 chip, the less troub=
lesome JMS576.

> 

> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (lat=
er).

> I'm not aware of a 0x0576 example in the set at all.

> 

> (The JMS??? naming and the 0x0??? product ID's normally match for<=
br>
> the ??? part.)

> 

>> https://pdf1.al=
ldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.html

>> Contains a brief description, but I didn't see much quantitati=
ve information.

>> 

>> I've reverted the host to the less troublesome JMS576 and will=
 try to 

>> reproduce some of the earlier results as a sanity check.

> 

> I'll note that I've reverted my active environment back to

> its normal content. I've not figured out a way to get

> reasonable evidence, given the combinations we have observed.

> 

> I'll note that RPi3 EDK2 UEFI is not an option as far as I

> know. I've never had it work for two things that I checked

> up front:

> 

> A) microsd cards: Even pre-existing file names for msdosfs

>=C2=A0 =C2=A0end up messed up.

> 

> B) Serial console: once multi-user (or so) starts it is

>=C2=A0 =C2=A0garbage

> 

> (I can ssh into the boot but I've not done much that way,

> given the problems reported above.)

> 

> Another issue is that Device Tree is needed instead of

> ACPI because the ACPI is non-standard [matching Microsoft].

> (For RPi4B EDK2 I use UEFI/ACPI, it being based on the

> standard. Some of the RPi4B's normally run under the

> UEFI/ACPI environment.)

> 

> I retried RPi3B EDK2 today and the above is still the

> status for it.

> 

> 

> =3D=3D=3D

> Mark Millard

> marklmi at yahoo.com



you can probably fix issue B)(MultiUserGarbage) by changing the baudrate on=
 the fly=E2=80=A6

IIRC e.g. with picocom it was by pressing ctrl-k or so =E2=80=A6

But from past experience I also think that EDK2 is not the solution=E2=80=
=A6





> Am 03.10.2022 um 04:10 schrieb bob prohaska <fbsd@www.zefox.net>:



> I'd like to see FreeBSD run well on readily available, inexpensive=
 hardware. That. used to be an i386 PC clone. Soon it'll be something e=
lse. I hope some flavor of Pi. ..

> .. I'm just a squeaky wheel.



We squeaky wheels tend to use squeaky Operating Systems on squeaky hardware=
 :-) Ha Ha..

For the Pi platform we would have to immediately begin developing drivers l=
ike Wifi, audio, perhaps graphics 

to be an appropriate fbsd-client-setup.

Understanding bootloaders like here is a good starting point but if we are =
not willing to start the driver thing on our own,

Without the help of any fbsd-developer,

that will be the end of aarch64 cheap hardware for FreeBSD.

Instead a cheaper amd64 will do it(makes good progress but even amd is some=
times frustrating lacking features such as appropriate 

Bluetooth audio or so).

The situation w=
ith rpi is more complex than the other arm64 boards that are supported give=
n the disparity in the availability
and timeliness of documentati=
on for its parts and the difficulty,=C2=A0at least in the past, to get prop=
er support for people that=C2=A0tried
to make=C2=A0things better.=
 It isn't helped by the hoops that u-boot has to jump through to boot o=
n this platform to be sure,
which is what you are running into he=
re.

Warner



--000000000000cf0c2705ea191b18--

From nobody Mon Oct  3 05:24:38 2022
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 4Mgq5l34FKz4V6G8
	for ; Mon,  3 Oct 2022 05:24:43 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 4Mgq5k38JLz3P8W
	for ; Mon,  3 Oct 2022 05:24:42 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x631.google.com with SMTP id qx23so1704746ejb.11
        for ; Sun, 02 Oct 2022 22:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=vlWDIuo4uD1n/Os5Xm8kGa1xUDnxLW9egiMigI/oFF4=;
        b=ApGWvrM1mafqrAGxWLNh5I/2OSUMkc7MsA9y7gmyId8AAKkbtrhv67coouCzQm7oCR
         ztSH5hf0h5InFsa1SMEX2rxmtu2NnB5pT88xiqi4Jk6eZ2M309IR6prdZohU8BduoDF5
         01Q/fJWcjsX/no9kVQ6Dn7rAgCTQ+wYa+mli3iOG0B2hHjsovM/ZC0sfXfFmTDxecsxe
         /aDAEQP0g+X0iK7pvXi/B+L9JjXaLgd/AUpQBrO4ZBBUjpCSek9lh1xCChpUv4B9oge8
         1hvSEszsVYRrte4iK+0u4vRug9wuWtqIdEKAAw4HRyzus1A4Nhr4Y0zAyNABrp0759CN
         5Zpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=vlWDIuo4uD1n/Os5Xm8kGa1xUDnxLW9egiMigI/oFF4=;
        b=7l5aUjmsrq0YASyDwnJl/CEbQxYh3pselMXdgrsfX9w8XNR5aJ8ytKYEkl4dqgbVTp
         5hH8s5a8yeRDJ9pJG5o6eVKCVqHlw5V4eIr2vR8Psg0JJ3TSe6OSdZ/Jx7D9heXZbHw+
         1YgN56zvdx0uUGiVes3o5het8zLChWC2EVJSaYBNqBuIf7gYbNOWe5JiQOO5aeSVJhCS
         Q92MxzxKrjS64vQbjJch3vVu1GgEDXUToLlvfLq/gY2iobVnSfVp7WqLRGQQwzBp2nnl
         lla8n4IwuhXQyAXqL9o8b2GxrFV8skdpYsQwH8/Y5U77HQr6dmVMFDiBpvKAFEhUta/5
         Y4+g==
X-Gm-Message-State: ACrzQf3035uy3FLTLteAxGxUVEn+xJ4/f6FlGyxcETXUr3d6lsUpzYqT
	rdh4KizyPe5GBzUW8zR/L1Q=
X-Google-Smtp-Source: AMsMyM4yFBC1M41iZiIsFycEgyw7If1FSq8PKowpF90gsRi/DjyeuXwhGNg40DH4Jl8PMqgcF/f6QA==
X-Received: by 2002:a17:907:2cd5:b0:77c:b9cb:bdac with SMTP id hg21-20020a1709072cd500b0077cb9cbbdacmr14207023ejc.265.1664774681005;
        Sun, 02 Oct 2022 22:24:41 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id j14-20020aa7ca4e000000b0045723aa48ccsm6558128edt.93.2022.10.02.22.24.40
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 02 Oct 2022 22:24:40 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 07:24:38 +0200
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
 
To: Warner Losh ,
 bob prohaska ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgq5k38JLz3P8W
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=ApGWvrM1;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.979];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[bsdimp.com,www.zefox.net,yahoo.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 03.10.2022 um 05:40 schrieb Warner Losh :
>=20
>=20
> ...
> The situation with rpi is more complex than the other arm64 boards =
that are supported given the disparity in the availability
> and timeliness of documentation for its parts and the difficulty, at =
least in the past, to get proper support for people that tried
> to make things better. It isn't helped by the hoops that u-boot has to =
jump through to boot on this platform to be sure,
> which is what you are running into here.
>=20
> Warner

Hi,

I had totally other plans in life but saw Mark here never giving up with =
the Pi, what is quite cool :-)
2 possibilities:
When you as an FreeBSD lead tell us: Start to get the best out of the =
Pi, start to come up with e.g. a first driver step,
than we should consider this u-boot - discussion as a lite warm up :-)
When you say: Give it up, I also will give up thinking about this =
device.
A while ago I saw a video discussion between you and Patrick Wildt about =
 the Wifi-driver he developed,
we could start there to port that driver , perhaps without using =
linuxkpi, just as an example.

Cannot speak for Mark&Bob but I think he/they also would be willing to =
work on better useful results for the Pi,
it would be too much hassle for me alone.

Thanks,

Regards

Klaus







From nobody Mon Oct  3 06:48:20 2022
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 4MgryW4gXNz4Y0H6
	for ; Mon,  3 Oct 2022 06:48:35 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from mail.kronometrix.org (mail.kronometrix.org [79.134.105.182])
	(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 "mail.kronometrix.org", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgryV34Mrz3VZF
	for ; Mon,  3 Oct 2022 06:48:34 +0000 (UTC)
	(envelope-from sparvu@kronometrix.org)
Received: from smtpclient.apple (176-93-235-61.bb.dnainternet.fi [176.93.235.61])
	(authenticated bits=0)
	by mail.kronometrix.org (8.17.1/8.16.1) with ESMTPSA id 2936mPMU047373
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
	for ; Mon, 3 Oct 2022 06:48:26 GMT
	(envelope-from sparvu@kronometrix.org)
X-Authentication-Warning: mail.kronometrix.org: Host 176-93-235-61.bb.dnainternet.fi [176.93.235.61] claimed to be smtpclient.apple
From: Stefan Parvu 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B9AEEB90-0D0E-4027-B22B-254A43954B65"
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 09:48:20 +0300
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
 
 
To: freebsd-arm 
In-Reply-To: 
Message-Id: <7ADC9ED8-8DE9-45F9-976B-4FD651FE62A0@kronometrix.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgryV34Mrz3VZF
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 79.134.105.182 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:16302, ipnet:79.134.96.0/19, country:FI];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_DN_ALL(0.00)[];
	DMARC_NA(0.00)[kronometrix.org];
	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)[];
	HAS_XAW(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_B9AEEB90-0D0E-4027-B22B-254A43954B65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> A while ago I saw a video discussion between you and Patrick Wildt =
about  the Wifi-driver he developed,
> we could start there to port that driver , perhaps without using =
linuxkpi, just as an example.

We need to have at least a functional Wifi driver for RBPI3/4. =
Networking is just a=20
basic requirement for many applications, IoT. The FBSD foundation could =
put more effort on
this part and support it.

There are kits available in Europe a bit more expensive but you can =
still find them. For businesses
RaspberryPI organization can help.

Stefan=

--Apple-Mail=_B9AEEB90-0D0E-4027-B22B-254A43954B65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


A while ago I saw a video =
discussion between you and Patrick Wildt about  the Wifi-driver he =
developed,
we could =
start there to port that driver , perhaps without using linuxkpi, just =
as an example.

We need to have at least a functional Wifi driver =
for RBPI3/4. Networking is just a 
basic requirement for =
many applications, IoT. The FBSD foundation could put more effort =
on
this part and support it.

There are kits available in Europe a bit more =
expensive but you can still find them. For =
businesses
RaspberryPI organization can help.

Stefan
=

--Apple-Mail=_B9AEEB90-0D0E-4027-B22B-254A43954B65--

From nobody Mon Oct  3 07:29:28 2022
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 4Mgssm65r7z4Y4kQ
	for ; Mon,  3 Oct 2022 07:29:32 +0000 (UTC)
	(envelope-from maciphone2@googlemail.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 4Mgssl4rR8z3Xxy
	for ; Mon,  3 Oct 2022 07:29:31 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x529.google.com with SMTP id y100so12820333ede.6
        for ; Mon, 03 Oct 2022 00:29:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date;
        bh=AIODhIdCLZzP6dSKkv7mhCXHv3hOIuSbYhT2xgJVk1Q=;
        b=eYGDUuQ/alo4BEc1t8buZMAmLWflSU5tbuq1sFy9/XHWb+7gN7E5WcDp9pkj+tThXt
         apFoj7rN31OxTDz9BxCgeVeMxjVX/gH22wYKQogDy4MgJVYmCzxokCngWlcO0PWAXORe
         hxHYo1pIYINYrI1SuKwX6OT79m2aog+FrAQeOZQjZwdNuyRPfO1ebppLm51CLW6/BT0j
         NH9Ksq3agqtI3ff5iINUMOMxi6ydNNs4JQItvTDBnE9RsXyWu1YkkMk1AMletvoVKupn
         yfiLxiZjwxdKjJo6c9mo39SprcdTWFkJ2KYyhfGv+OggbrSMjVogxiZOy+/6AFMmWoIu
         wzGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date;
        bh=AIODhIdCLZzP6dSKkv7mhCXHv3hOIuSbYhT2xgJVk1Q=;
        b=gt2me7Sd0w5Czrvxjf5AmnRHOmJT18c18+6L5mhvh4fmWKoyfHYV/b76eKOntoq/Fn
         dq49vdK87pdZE2bB5Qtvhy1JA4eWJ1/gU6t0Prgmdjx7iRhJ4Ivt3Zb4/vPI3iyCPJjE
         vYB6rQQfZWpH1iXCCfVEech3k+LvLpY6/YFKsTnASA2q5HHFLaDTs+pQAQe6Yyps7pcJ
         pVEhxuXJjQBiIaAKn2eARvZELqKZV3JI9+GDS5nHBSXmNIbpZy7+W5HoPG3DUN2+nMnB
         A55TjGUIx2cYMXmSYxRxvswoqIjqamE0zg43SAzwqzImL5EVCasurucrZA0jy+xJABQi
         Vj0g==
X-Gm-Message-State: ACrzQf20pJXL7HLjknHyOOdXHc8Es665Qips2s87Aj60bAZaJPLTyZE2
	kfNmNy0w/q0ufUk4EsL9xddRmyt7fnZJ0Q==
X-Google-Smtp-Source: AMsMyM5vrtdckwUZhWrD3AcwR+0uzhydMJkNhuE0cvs/3GaMinPjQMn5WB1qBGJ1YGajDHyEmJZsnw==
X-Received: by 2002:a05:6402:51d1:b0:451:e6a6:4919 with SMTP id r17-20020a05640251d100b00451e6a64919mr17650572edd.58.1664782170300;
        Mon, 03 Oct 2022 00:29:30 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-061-084.46.114.pool.telefonica.de. [46.114.61.84])
        by smtp.googlemail.com with ESMTPSA id c25-20020aa7c999000000b0045909e3c0c6sm1294786edt.71.2022.10.03.00.29.29
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 03 Oct 2022 00:29:29 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Date: Mon, 3 Oct 2022 09:29:28 +0200
References: 
 <20221001174724.GA98055@www.zefox.net>
 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com>
 
 
 <7ADC9ED8-8DE9-45F9-976B-4FD651FE62A0@kronometrix.org>
To: Stefan Parvu ,
 freebsd-arm@freebsd.org
In-Reply-To: <7ADC9ED8-8DE9-45F9-976B-4FD651FE62A0@kronometrix.org>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mgssl4rR8z3Xxy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="eYGDUuQ/";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


> Am 03.10.2022 um 08:48 schrieb Stefan Parvu :
>=20
>> A while ago I saw a video discussion between you and Patrick Wildt =
about  the Wifi-driver he developed,
>> we could start there to port that driver , perhaps without using =
linuxkpi, just as an example.
>=20
> We need to have at least a functional Wifi driver for RBPI3/4. =
Networking is just a=20
> basic requirement for many applications, IoT. The FBSD foundation =
could put more effort on
> this part and support it.
>=20
> There are kits available in Europe a bit more expensive but you can =
still find them. For businesses
> RaspberryPI organization can help.
>=20
> Stefan

Hi,

as far as I remember, the foundation paid some devs for the sdio =
implementation.
But they stopped developing the brcmfmac-Wifi-drivers for some unknown =
reason.
The last time I looked into it on the Pi : sdio didn=E2=80=99t work for =
a simple reason :=20
There was a missing overlay in config.txt .
That=E2=80=99s one of the reasons why e.g. Mark and me often take focus =
on=20
the msdos partitions environment, u-boot etc.
Sometimes discussions like this sound weird but all has to do with the =
other :-)
For now we should have sdio working on the Pi with the MMCCAM kernel.
OpenBSD used their standard SD-driver IIRC so the next step=20
would be to port parts of OpenBSD`s driver to the fbsd-sdio =E2=80=A6
somewhat superficially described but combine forces with some people =
here=20
We could have a good starting point to work on a driver, with or without =
the fbsd-foundation.
But there should be at least one FreeBSD developer who says:
Yes, that=E2=80=99s a good path to go if you guys can manage that =E2=80=A6=

I also think of IOT things like LoraWan and so on but having the onboard =
Wifi for brcmfmac should be a=20
good starting point, then BT and so on...but it's going to be a pretty =
dirty job :-)

Above Information without guarantee as I am not a FreeBSD member.


Regards

Klaus






From nobody Tue Oct  4 00:18:57 2022
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 4MhJGX5Zfdz4V8G2
	for ; Tue,  4 Oct 2022 00:19:00 +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 4MhJGW4H2Nz3bQX
	for ; Tue,  4 Oct 2022 00:18:59 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2940IvAr008193
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 3 Oct 2022 17:18:58 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2940IvuL008192;
	Mon, 3 Oct 2022 17:18:57 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 3 Oct 2022 17:18:57 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221004001857.GA7109@www.zefox.net>
References: 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
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: 4MhJGW4H2Nz3bQX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Oct 02, 2022 at 07:30:57PM -0700, Mark Millard wrote:
> On 2022-Oct-2, at 17:46, bob prohaska  wrote:
> 
> > 
> > The more troublesome bridge contains a JMS577 chip, the less troublesome JMS576.
> 
> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (later).
> I'm not aware of a 0x0576 example in the set at all.
> 
> (The JMS??? naming and the 0x0??? product ID's normally match for
> the ??? part.)
> 
On close inspection the enclosure recognized as  0x152d:0x583 
contains the JMS576 chip. That's the better-behaved one.

The enclosure recognized as 0x152d:0x0577 contains a JMS577 chip,
that's the worse-behaved unit. 

It looks like the first two EC-UASP enclosures purchased (which both 
work fine on RPi4's) report 152d:1561. They are clearly different, 
with crystal cans on the circuit boards.  

The two units we're fiddling with presently came much later, under 
the same product description.  


> 
> I'll note that I've reverted my active environment back to
> its normal content. I've not figured out a way to get
> reasonable evidence, given the combinations we have observed.

Understood. 
 
> I'll note that RPi3 EDK2 UEFI is not an option as far as I
> know. I've never had it work for two things that I checked
> up front:
> 

I take it that EDK2 is a tool for _writing_ bootloaders,
not a bootloader itself; is that correct? 

Thank you for all you help, I'm sorry it's turning
into such a snipe hunt.

bob prohaska


From nobody Tue Oct  4 01:24:07 2022
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 4MhKk66RTJz4cxJY
	for ; Tue,  4 Oct 2022 01:24:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MhKk54DmYz3hV8
	for ; Tue,  4 Oct 2022 01:24:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664846651; bh=MzXBLaLLW4O1vY79TB1kRmxof24u6PlmNzetk3DPDQI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Qt1FNYld2JafmF6qpUrtDskVRNO9HP75JQt8Ysvqr6AyAY8boxT/HNbQecz9/MyxizpiCeK6fPTiCqMloeR78d0FKQoZjrl4wQQmSuyf1DBM3kgQI5l4YCrpKSEGCV1AEZL/wEYKfFSQTogKFDm9/4PxCE6glcY7vJ71jyxmdG3JLL1pFblMaIw6GDhUm4R93KGr1uTjUdsBqpdU1HGNhRGWWLo2LE79oLhRgCWtXwUaEMVgeAcztm1mwqKLOqS7OX0lTUZj+BpgOccvC+s0g7B8vH0ANUQddhHMsOJ2BRhkaDE0y1tG0lJU+B8tXyqi89e2fWPV39SwfrYLL9cDTg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664846651; bh=J+pw5AbGwEQsPtwuqn/pzqUE5kcM8C8xDj2WyZbUNe6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mrAl6yFdnV1MsF3GldbNCFGNrMn977cdfRU3x1g9yO+P75BnDFPsDEs4Cd1wR0hueYvwHqvssNsRzhqTxdDxbEOYOr1/Kjs+LRBf+ZH9Ac+XJBXF8boF01Clie8cUqiM943lpsXa5HpjkkXye78rnliQOOw3f8vBXb7m/ZKB9025qDFobHqkaxuiHObZYMWJUfi6FPvtdbGYzW7KK0911xJhiPCJIx9GAyyOMiNgqNr816V3Wtmekxa+r7R3EQmWe5aI3fV6XW8Gni0Pgj7y5CQha6H6qb8CV02CfDBhoyWSEUs2CvTXDt2LO2IDPTdvELe1sTBEg3dZ3ttSyFSvqA==
X-YMail-OSG: e0Q6B1oVM1nsZxFc1exlmBLrCU7EKwIgsvwU_blVxrJnUOsh6DjaPYPRES2LXBI
 0kRXT4gM94hUD5Sv.uDGn1i27hXu2OY2nNlXY8hMnAFm0RDWc9YmtaTHKcmeZzdGmIPDsxwv.Zma
 _xSfxNDKzC0oSX1KoYfAF0rYKv5vLUBFVPI6H8OTDasoKleQEHGIMTk9ntjcPEP62A1QWk_Pnoca
 L8wY14f_yiBD90.U0etiGAwCj6maLYvbv6kyZAgg6sRL3htJxXtTWbKx8f.l0mkvZDcTWkEQWUNk
 Ri9QBkVMGDNOqEB0slqJs.6n2j0cVbB._NncD1ec.YdvKfmD87j27SIQdMNrjjvRJZiMhrPRGbUL
 M2CzEiEeOoqUGj2ltBGGuIf5nzsYvK9ExIcPvhv_8PLbiIGNvEx7e7KTYZGhQs4pFgiRyQLpBhio
 2eLJ1VV8pPaP21dcKop2M7vwJehK_abjGAWKxSk65MDK3Sd5e37VmDtLkgan9qYGU5h4YVYiu2Ju
 IFTfwxRd4sddY1lhpK0ZcdlXILtg5L.MLyD9fe1GWPteQvvbyFjoda3AnkopY_Fb0vG.dmZ39OPK
 dcfek0.PwtmsqzXHBr0iTugruJhRXtARf3ev.fu.NHKorlW5_gI7ZXyxkZV0MOa6LNJZzghJ9tP7
 J0ZTVBP5kP2p_DmMPkQmQfxOxD2UMIhpk8XG7V5Sk8JbbCgRekaLgo_Tte7vnQurKRSEb7crKLja
 gCwksIvves_iznqKDUhlnib27M6nzopbDtVc_sUiLjFAsMb4Baw2hHUctKuWMDVSO8R85s_BaRso
 IPZYLJAJTcQydQb26JaRUXlNwSguB0l4sKfC0yVXpKgvZ02gxxRV.LfV.F.JVgwb9F1UCp0W_wDU
 KGqgTNqadp.ql6Y1n9C0iUKYTqPTYLdRNOK1tSQJqxfd.4rueFP3PieMuXX2aobeW2ScA0MLD99b
 O.N2fnzandzTCW5Sj7fjFWMZFET3SszGe8bVU8s6S3uj1LOtmmf6vsP2.Qw03wd9QcSLY9o0Iuyo
 KSwUuMad2J7_y.9MNTAMfnBPpL5lk15jVJokbkoRTomkjL5Jn4TRY.kk3jkm8t0M2_ymhLag9CkR
 zhlvvm9OAzpICm7rDuu.ofK4UljrhAS0oS6WisOKI4a7wFRBY8bfpErEB7fI4rE6TgHQ8lxDShtA
 ngkqZxDISudWkjb6T5UJ3meZU6zRnJtfLitdUlndPWlIXRwukhbC2tCMWqhUij.lRrETuTnpqa9t
 sg22u4Ol1ZXoDBdU2_kf6vdX0__TQ7E9q56aijnT5ky.Ny3d6LLTxTkEUZ.2XxkChghipYZxcnKk
 8CtIh3iv4JoOwX_T3u6woBLe.MaN812rxJpYVJihTt0nMOO2yVJ53kxoJGqL9rA1aFhjLzBfc4bU
 WqWKLhiTK1Pp703KOiNqyGZXI1evNNd2I48qlqQDVgBOgYlUw26mF1qLKnOnXjSXnTd4ao3Qae8.
 w0phLVFAJEIphz15NKNZZ0._8ExytrQGiZ6hsShPwfV8ko97Fx4y5cI6qX.hVpi_PTPqBir9Ug7X
 L8RY9wd8Irq45vCmusLeiHIRdPxiUnaDxYT.lKpx45OFdRjFz.RwKIO_BVYZt1iRBydivtcpqqV4
 sjFoDivNG1fiZzlzBELcCvoNNEMjsfoviMSflyB1FdaiCi97JCEyR0WhRCNemyTLdZimQxlvFdLd
 a_MvqXenKQj3DwW7aSh0LO8lXw0JF6NNKF_QdKqcFwR9iZbaoWviT_FDrUWFJWmGB7zhNzUwrtc6
 CeKz7Bkcp0Of1oXuGjyiyjPfapjo9DQ6sXta3FKQUoHRkgepJj3fqwC2LrtngABTcA9UNhHuLc7Q
 5T4PnGQNqKFGQaoNRqFU9BbbsgnuAAO8K_LoKz3cyTyFFnnISFfKp2IrKSlmCPIQ2cWMiHbrJbsY
 EhLeAxHaxspIKjHZF0iPJP1jwrDuNb69FEVbUiIeQOc2A4M3q2QiWa0BHN9UqGtMIXbLf2Rtoc8f
 hos.X5WnnePFXd07K62VXB_lQ_asy6pz8wkMwdNIjyJikFGl2nUY636Wj_7te.ApElRGgDPt1Cuw
 Dw3h5Ri3jXmjfGfDmeWaOXL5st2OG8lWya8oZeTVi2hZNXLlyTsxVoC5RIa8xneg41M.xiDAaHeE
 LBmHhrUcQ9O_f5zwG6SB.3FX_SWfsALX.X8xCFTZ.RGc0JEYXRfQB5fi4W1QqVCP4sXzGJBr_jcx
 OwR0WAVOyKnxKgBhYjiUzQTmJhnglDpjhg8fxSbWAtLu5xYh9lNbjU6nDeZaNYw8LOHarrtfNXFd
 gu2oH0uA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Oct 2022 01:24:11 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-5vhqb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 576a51c2b7dcf55f214d692391e1f741;
          Tue, 04 Oct 2022 01:24: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221004001857.GA7109@www.zefox.net>
Date: Mon, 3 Oct 2022 18:24:07 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
References: 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MhKk54DmYz3hV8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Qt1FNYld;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	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.146: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.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-3, at 17:18, bob prohaska  wrote:

> On Sun, Oct 02, 2022 at 07:30:57PM -0700, Mark Millard wrote:
>> On 2022-Oct-2, at 17:46, bob prohaska  wrote:
>>=20
>>>=20
>>> The more troublesome bridge contains a JMS577 chip, the less =
troublesome JMS576.
>>=20
>> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 =
(later).
>> I'm not aware of a 0x0576 example in the set at all.
>>=20
>> (The JMS??? naming and the 0x0??? product ID's normally match for
>> the ??? part.)
>>=20
> On close inspection the enclosure recognized as  0x152d:0x583=20
> contains the JMS576 chip. That's the better-behaved one.

Is the JMS576 labeling actually on the chip? (Can you even
see the labeling on the chip?) Or is the JMS576 labeling
more like overall product marketing labeling?

0x0583 vs. 0x0576 leaves open the possibility of a bad
firmware revision in the part?

> The enclosure recognized as 0x152d:0x0577 contains a JMS577 chip,
> that's the worse-behaved unit.=20
>=20
> It looks like the first two EC-UASP enclosures purchased (which both=20=

> work fine on RPi4's) report 152d:1561. They are clearly different,=20
> with crystal cans on the circuit boards. =20

So there are 4 EC-UASP enclosures overall? Could you be so lucky
as to have (oldest EC-UASP's used on oldest RPi* family):

Both 0x152d:0x1561 work with the RPi3B's
and:
0x152d:0x0583 and 0x152d:0x0577 work with the RPi4B's?

(I'm not sure what all combinations have been tried.)

> The two units we're fiddling with presently came much later, under=20
> the same product description. =20

Ahh.

>> I'll note that I've reverted my active environment back to
>> its normal content. I've not figured out a way to get
>> reasonable evidence, given the combinations we have observed.
>=20
> Understood.=20
>=20
>> I'll note that RPi3 EDK2 UEFI is not an option as far as I
>> know. I've never had it work for two things that I checked
>> up front:
>>=20
>=20
> I take it that EDK2 is a tool for _writing_ bootloaders,
> not a bootloader itself; is that correct?=20

The team(s) that make EDK2 support the RPi3*'s and
RPi4*'s publish releases when they update EDK2. I
actively use a RPi4* EDK2 (UEFI/ACPI) on some=20
FreeBSD RPi4B's. (Other RPi4B's have the FreeBSD
U-Boot context instead.) But my usage context is
limited so what is supported via ACPI vs. not is
not significant for me. I also have patches involved
for this usage.

There is the FreeBSD port sysutils/edk2 with FLAVOR's
for rpi3 and rpi4 (and more). These do not track the
specific commits that those teams published based on,
using more recent materials generally.

Currently, building sysutils/edk2 is broken. My
submittal to make it build again has not been applied:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266404

I've no clue if the RPi3* EDK2 UEFI/DeviceTree problems
are just in FreeBSD or not. The EDK2 build supposedly
works with various Linux's when DeviceTree is selected
instead of ACPI. (The RPi3* UEFI/ACPI is Microsoft
specific, not standard --so not appropriate for *BSD or
Linux variants. Device Tree needs to be used.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct  4 08:25:17 2022
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 4MhW3m6hcnz4V5lT
	for ; Tue,  4 Oct 2022 08:25:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30])
	(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 4MhW3l6Py2z3CBS
	for ; Tue,  4 Oct 2022 08:25:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664871920; bh=UnFfARwjmJz4GXpME+pFyw/Tg5OL3uOPiNsnk/z5enc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EHVmF5UBfu3KNd218jxtubKNv0TfHfqGFUy0tK0A9J0L9xj4Y65YfY428GZcOD7+wOq78SsxRuSmTU+rB9nbKrWaXTBkct2ORCGvbGa5cHMPzn7HCqlrluASxt8VykjW9BB9H2AtaE+JL5M6YL418m6LwhwbKhUJMMMVmB27ODC5RVnc+CrKQaVRbg4Wgi7Ts3PEZl0JgrFUj0Zvd/ccFzCNx/3QNZAziLlDpp+p/SR/0rj9AqCtT953nvXB7pfTPv/+9vpDXJFluhUYb/GVxZloWFqQ4hN2BRdVTETpf2k8uaoSZWtmXp84KXMIRnA8hQ2hxLrc+iUcQ95iFrKgQw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664871920; bh=OR2UnzbPU7GsCaKiwy/aczmNIPOd85lI4iTgrszaINg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dcFHCSwwSuZsiRcfBFoPzk35zoQbJUR2mPeG5Kb2/maRahgIOyGbliFcrsWmI1q68zw7TZy9/H7QcuTSDM6cJ40/crdWYEwcpxW4d5wq6QBdHRc3FM3NcMHDQZFebSkRkuPuu4+9ml7j+SepLzSCKVMku4M6XWhstxxlyMyPjPJQBlIjB5uztGsnxuG5JTWj6Ez77QK3AQxF/qeeyKFeq41U2f38E67ijEJJsbi5McdygV0jKSJ0a3eeh/Fjzq3NPpmv8lh5g38gXTrRz5zlG4/OUuFF7lYyCiTdN5KZ9v02AdDS10mUCjxzez2QfEZK0XfpIkb571AAHvCNMydszA==
X-YMail-OSG: 5jZl2voVM1k0J4id1_Z8dakIBCU2EcgZnS14hjcGmxer6Hyw1rtyHzDnLfPvuDt
 GxSbUb4BYrKeDHh0gNorCbodEYfU87ooTAC_OsMhYyNXldjysLX4iy1UhESzl4vAm_DR4NBfjirk
 HhG2KArzw74J_5gxM8cczE1.Gjd.mDP0H1vLth9qbcGEovGH2lxezyPH1guqM6rSWRHwBjJ76aOr
 HKbI6T3Vt13TUm2k4AVZMJdjRuWEbgZDOfIwPFwbFkLAzHZAVqaVh8qiCQnYWrmUBEykBw4Y1qOu
 43E7UMk.N9Bh_QqFbtNrizJpNhcKJZ9R2mxv1Y1wtW.ZXtngxYCV9YFNp1HZP7D.n9H5hyUa61Vn
 udkjlrTQloBTHC6tCFHAwyY3GYP.Kb4qShaxKgIVg.tAQnMYRzTL9D0C1kdL2isoBohr9ZiuFRBu
 mf3yZNkmmxhAI1z6zMP7PMZ5L3gaJEzoaK4Nkw9dX5EwuhpbyFpRtoRV5Z_sZ12MqOEFYesf4IDK
 JxvXqCkqo6L6QZ9BE0KmsOX2n5N68KJ3gLSRTDFP6HcfaRyAjTvRNTmX6ulKRBBK4Tt00U97qP5u
 qrKqKtkmWk5AYVM8cziBenvMln2dDyjNRz_zTufY0Najp7HSF1dEHDTW37nzJCALG2L1iLI8xM8a
 .Zu_VJrurwfwJpKSkbsw_6udPXVKB2c6MNcIwq1J_elWSYoj3WEjkv4hSZLUr87niNqd1JiwRb3o
 0Gyk8y9avyGsh72w.KxrKiG81O7zb6sHd0Eijpb3wCsoJlmP8lkfdCiuThjgIu1D8nu8c2Oguc8h
 uuNziYwHSErxnnEbTGu.wDVIICUFoZsLBaZAcDE7YqkSzAKahRR6KdpnoziPqEjGdZdVm22cDFWf
 J5tg4u8Agg_UI9z2ijm_Slv8rgH46Jd7nafP4Sb0vC99VYVSZG28ODyc63YtrmEiI26L0rBMjUO9
 9.hUCy94OwLQMFu8ucH8.g0BkzFSGiZaT4ttn9uvtkNerXgBSFpvR5YiaibGZIm_3fc3us92Z8A1
 0UtFYPDdZ9wW_9kYfM8egypfxIrJ1gj56AVL183dXGWHaVe6QAjj57dAFpYGuzLmkkbyP_iVjhgU
 VvP7TYFtEK1hG5Qmhayqk4A0JQG7hX4qvw9neH6c2gClIVi6xiyT_JTr91L2fp.5cPwMaD250sfo
 teI.4MsVmmKWZR7OT_Ezeb3thIkpbfPldpUZxnkjdqdf9DLEnkO92RIwD2lN37LwuhgWstQNaHjH
 VP238plKSwh_5CWZweZnQfyBq9GOFBfBEjeuVNFNS69MRXaHoS0tr_ujpzo3tpioiA9pLu3Dsg3f
 HdLPqUZ5HrVk_joWqlsSlny6Bw6q2HTW3gPxeA4eoXNjelVZKy_gqwvOW2PSt2I0b83jEqnl4xLI
 8v65.AGDXQ4Lo4Vf0I4LsDX6QiW.27Q54Uib5lprxn3qOAb6m6tz8tcSprfxt0oTN0PAa6ZgGtSF
 8DsnFvuocLQIU_BuZBc8.eKpe4NsSBT0ZNJn9ppUHWBSh7mRYU295cOJn93oRDekzdDB6F3.3mYH
 pMzIYt_VhziXmeAtSCDmRqx.IN.X5mq2GUcsYqzLrquYYGYKvB8JlSY0ja1_6GxwdKmNh1srkAxz
 60N4r1NPIbG2VWciHEqNEuLa0qEGHY1KhqWv3b2TASB9sVpiPpIhvqUPHovrpoS09vHBsFBiWDJO
 FWPXxN.Qhcvid5cN8Og4hzC5OIcl9lzj5R1drd.aRHScVuWEgiTH9Modt4JBYXdIlhmwRXLTCSuy
 gJntdtCO0OCcQK9dcZPiGbsp4n4yi9CF27TUg7Ani9EvQLfdvD3ISV3y3Mn1fcY4.65zjj37J.xp
 aFtyWcS8rOijt7CGvTpXqtog3sfPCT5bimHuw2zGrezrvKi1g0GciFKnhv2codEV1oDm9oCvPQBe
 1VT6R9qyOKfEylprEN4fla7zIbD7zOei4rixZWxdrSjCi0evkvsJuA__IDGtEDXYjmW8RAcQiLwB
 4Q7FqzKC19ibNcwNGNL8OVNsEqJL9kFTjOK1iBceEjyexQJwZWLcZC4M7cTNB6b2pJjZ3oGxce6t
 lTCow0BOiAdbFRyaPrmFN9x_WyGQhWxlcN9hyYQoOwehr2M7bv55yPfOLM6TObBndUIPnZBhhjve
 tAezUxZ1X1q9tuAeBjsk8czLBdAM7yBlhSqxhAwIiRnE0uGyjWORWTnw4aI2vEtMux887coWYlQc
 tkVW1Obx6Xx0o4ra9VbHG610DrPLRxYuYU.1jRr.MHULqhip8WoAThPclzZQdMSKs.N4awB7w_F2
 b460-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Oct 2022 08:25:20 +0000
Received: by hermes--production-gq1-94b89944-5szfq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd7b9fb9c31a4796032812e733de92ac;
          Tue, 04 Oct 2022 08:25:17 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
Date: Tue, 4 Oct 2022 01:25:17 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
References: 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MhW3l6Py2z3CBS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=EHVmF5UB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

I found a configuration that gets the RPi3 EDK2 and FreeBSD
combination to have the serial console working. You can try
booting and operating via the RPi3 EDK2 UEFI materials.

However, microsd cards should still not be mounted/used from
a FreeBSD that has been booted via RPi3 EDK2. Bluetooth is
disabled as part of getting a working serial console.

I ended up with a RPi3 EDK2 microsd card for use in booting
that has:

# mount -onoatime -tmsdosfs /dev/da3s1 /mnt
# find /mnt -print
/mnt
/mnt/RPI_EFI.fd
/mnt/bootcode.bin
/mnt/config.txt
/mnt/fixup.dat
/mnt/start.elf
/mnt/Readme.md
/mnt/bcm2710-rpi-3-b-plus.dtb
/mnt/bcm2710-rpi-3-b.dtb
/mnt/bcm2710-rpi-cm3.dtb
/mnt/firmware
/mnt/firmware/Readme.txt
/mnt/firmware/brcmfmac43455-sdio.txt
/mnt/firmware/brcmfmac43455-sdio.bin
/mnt/firmware/brcmfmac43455-sdio.clm_blob
/mnt/firmware/LICENCE_bin+clm_blob.txt
/mnt/firmware/brcmfmac43430-sdio.clm_blob
/mnt/firmware/brcmfmac43430-sdio.txt
/mnt/firmware/brcmfmac43430-sdio.bin
/mnt/firmware/LICENSE_txt.txt
/mnt/overlays
/mnt/overlays/disable-bt.dtbo

All but the 2 "overlays" lines are based on the content of:

=
https://github.com/pftf/RPi3/releases/download/v1.37/RPi3_UEFI_Firmware_v1=
.37.zip

disable-bt.dtbo is a copy of one from a RPi* firmware
used for booting FreeBSD on RPi*s. It is not in the .zip
file.

I adjusted config.txt to indicate to use the disable-bt.dtbo :

# more /mnt/config.txt
arm_64bit=3D1
disable_commandline_tags=3D2
disable_overscan=3D1
enable_uart=3D1
uart_2ndstage=3D1
armstub=3DRPI_EFI.fd
device_tree_address=3D0x1f0000
device_tree_end=3D0x200000
#
# Local addition(s):
dtoverlay=3Ddisable-bt

(The file has a carriage returns at the end of each
line. Some editors show such characters as ^M .
The characters could be deleted if desired.)

I'll note that the firmware/* content is likely of
no use for FreeBSD at this point but I did not
remove it. It should be okay to not have it present.

I'll note that the output from "uart_2ndstage=3D1" does
not actually display during the boot sequence. (Sent
to the wrong internal UART, as if dtoverlay=3Ddisable-bt
had not been used, from what I understand.)

Using that microsd card in the RPi3B should try to
boot. The EFI prompt will timeout and continue to the
next stage (so far as it is successful, anyway). If
it all works, it will get to the "login: " prompt.
I'm not familiar with what the error reporting would
be like if it also has troubles with your equipment.

You hit the return key to explicitly continue at the
EFI prompt. The Escape key can be used instead to get
into the menu system for controlling the UEFI
settings.

If it gets far enough, the UEFI will try to find the
EFI/BOOT/* on your USB media's msdosfs. If found, it
will then load the FreeBSD loader and  then start it
--and things would then be back in familiar territory.


The above actually boots via a default setting that likely
should be replaced. The related menu/field nesting is:

Device Manager
    Raspberry Pi Configuration
        Advanced Configuration
            System Table Selection 

Picking just Devicetree instead, then saving, and then
exiting the nested menus via a sequence of Escape key
presses, until back to the initial display, one can
then select Reset and it will start over based on the
new setting. The save actually updates an area in the
RPI_EFI.fd file.

(The issue is that the ACPI information is odd:
Microsoft specific, not standard. So if the ACPI
information is used things are possibly not
complete/correct.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct  4 20:59:06 2022
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 4MhqnZ1290z4dhZT
	for ; Tue,  4 Oct 2022 20:59:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4MhqnY1Kkkz3G4r
	for ; Tue,  4 Oct 2022 20:59:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664917151; bh=xWHqxViBj7l+GOyIYZWPZ0qqT9cif7pZvpHTJ/ftwPE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ECQ8XK3QtgbQvAiGup8GzTArBONuvzvQGNuUUxTYiybL5fO646CRcDUVITwnZs1QfgYOFeH6tsvJ+tXpsuow8xo6cQ6/s8Db3syUKv41K/kQUAnfp3fm5vAZX3WdKXRxhgETLWPiTtspXWaDww9nGxVLURSh7RBUJlAr7W6Pi6Q6nwp9iaI1/gnOHS3XQsZC03HdCH6gtEDzcjQY2sGpHXXWE6X+28/+hJZNwouJVjsj7VSreEmcqEf+fiWQt6K9fEDD0Y7Wr1vF28Mt+sP4qbckV6i8qufHUTMI85HW20K4BlbSIHmFTNzJiFPhEvaZS1NWP7V2pD2uXMqED3nXCg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664917151; bh=JPCeXfeCZE3B/ZQ4mLvdNZ+uG5/34YDqv/5JvsfdT64=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BNK6yO/Zo4oTeGJdpO5QwMcYU/jQKsejsXl+ctcMrhc35KlTzFJv8JFz6QL9YUUtAuZr/dsECO9u/fCJPP463O8kwEqzU9WGzJN1ZFbG0jPV2C0hk0lJQ3hVTiV+iO9lwUnfiCj2lQj6gzuWXq1j9m9zfLU+zotkbPlpTOgSN2DK/xGi02e6uypVDrGv8xANpHYGVx0i4y1Q05hirFeMUuhhM3Yo9hKsCUoKNUVe8cZn35xbu743UupQOGjMud9ZGUOL+1viG9YreIngIyoBCWF+shvOJGygP4R3L/vRrzZpC6Ho8eGSAv7LrvHcY+kLd9xK50OXqw/9naDTIKzJuQ==
X-YMail-OSG: 0VX7jdcVM1k4K5I5RDo4HnYOIGkGJiYFIAgEXUg2Ru3pMRS9QWS_aSW1V9Ud5Pd
 Dw02aiBkck5nNoxNyBNvggU6bt7vTXz0VEG3tqo_jSVt5lDFg2sVq.gwf.dyZFgfR4Zmeu6FNYKB
 Ls4P_s8xMoryAT.aDoiTicEFG2lBIwozkROQG_asfhLjyloKFmoGjt56ajTfGghxq7VR9H8XEIOb
 .HqbKTczmiJCAYZktt8HGDYDQpwTnn1bVvopjXUrJyI25yj6jntgYRlhWMqD8z6.mg2IPzvdzXLO
 Dr.ioEfNnUhjq15TvRe4Yrw4deAhZbCd1Hs1v76bkGeaxNQmdEHeB8Lo51s4wO9psbQB2ialKud3
 YWh5BlnQ67nUD5m26NMlAsG02e4DFU9LrMnBssPV2hk84h6uAd7uEnYfoePdzy4Cnd6H8Tq9ROYi
 XKQvfua7C3EIGuzrGlMSTta2sYEK3PCYYAF9IUxkHCtxe6brQCW2Weq5a1pZld.8mjZPiCTBaH4f
 KDeoCw.PaNLlZgLMAa8uoBrm9sWlaEt04zYlYugPc.CLdnb5Cm8PcUO4O06MRGR71zv.bXZx.UCa
 VyHDJJCIkV5t0I2rkLXtj0AKsrT3Vt2T5Hr_hSjj0VOKk7ZYpufwtp_HiX7vCYw5ic_MKW85vqpF
 JKEaLEtpxDRjLB.MIZUg5ePpoJ9dNG0nQeiK80bK_WhjpjOZ1c._sQ_yJ3ga2L8EPhGDNxgYcQlR
 nn3a8._.mHNMhHfJx9.CEn3_ZzRzRezU74lO_5cOGbsTgQMqvpZxyFMz5Rw19vL0J02OuSo9iNOo
 v2kV2PXzK5bE4mgvALJIBEJrvpYyUBvsUeACmnWhnxnrBqf2bBNiTs13lBPeSXoXAsK2lNPJ9W3D
 PeaGnLS60RvNxmbqMKQwWFUHl1PEW0M.bIUNQPFPCfRKIa_cEUlfN1658HlSaApSqURc2Hvij7hY
 E8IYLXZ_3WBRK9iBvLjOj6rI6bBjCIIyKVyByXX.9saMWgDEa3sHcQnuRcuMcj837nP0uS5W9tNb
 vFfDyDOTRSYOsmuV0jA416M.RQdITuKRjC0a8xYQoRwi6NicS18aqfn72cZVnCFANyRkxrHtu7bL
 GRn9hfTZY9PWnYb0q3lrGwED6adnfrMqm1BbawDQyTRBvsK3x.50YnuV1Iz4CcCaNwIhvKXNlvG.
 IQ6fdhI9sBax9Kgqpk5IzNdC0VesiLmzco82099MMMBo_spHkCSpHOQ7SH46JYQR1I32Vq4k3hB1
 PSPJi1IqsDmHheQZ3fn_p0pLKEAH1abjtqklj_5Hw507.is85NmYYOHCIWlrNhtIoo_Qmo2SLMRI
 PCsumnVxK4RYwTLW4iAyy_82640b9O6Ll89BisKnXO_LMkFLnOgNI3pZ24tROTZqyIuZpiPMPjJS
 qA_L_bbR7XWNPuTNsEbuMKV3w5ewHSS66bpRNTMiTgBBkk4sNXRmYjjhbJhHEei8wg7r5ezGVJAC
 MbxAelBAd0PCyg0Flj3OSp9C9EDyGAl3hqkuT4OVKbqeEFtQ5bqqSMRBHV6pksiqcHb9jnYOupb8
 rTZEWBz3gGsfdIpmhY6F7TQD16yiOkqpWLYKVylnUy1yctm4MAUPKqutTUubwkFS65EXJqzLWugO
 lpNllsznMYBo.Vd.apOFLFnqInYTbwShN6X0eexsENahNGSD2tXcYoasIzmyE03JWd8Cc3X336h1
 3kIvfzMJF1JbawLhPngeQzarTU7HcPdkAXz05M7YfAi.De.ZLKt1IzjvkRb6nA8blKR9nKfpCOiC
 CjJ4q9oER7Ik6repEefI8ANxETya0KT8bff0D4lQ95UrNii.jA1L3yiPk5PIv0SZ.EXhSXqygXHs
 ivwZ_V3SyxQeQpOG4UFfb5EF_qx68_bQVk_sb173LY6z_TWmrtS4Eo.khKuZteIXkosIDK66oX13
 WV.QinzlKoXoOGuLcrbcG7i9r_DphdsWYtbF5XUI9OmzPiMp.ixROxE0ogjOrw.Y5_wn06PDBiBO
 QHYwNo.6krojLjAfI8qL3tyI1KIjCAmmGGbmAGnQENZegjks9dZKNbeIrsaS72XpRSi5doTDwW1Q
 m5K.F3.4CVOEOSyybjnB6yMCPTjFtICyiT.TeyiU.Oqsnvo.Bewir4_azO8kL69r596hOFJWE8ny
 pREBCrIgCBgAu.cPBpcN7bE9agcj0yqRaAzB02zw.y5eB.5RvzoetNkhC7EVG86gDLATFVkYU9Ll
 fyKT7GXXuAAda1tvjKYJmehOEDhOhFYQZU5kkqWYVaGwFjR95hpsJX6tUnW..tyryyoKZ9PwtSBz
 aDPeXMQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Oct 2022 20:59:11 +0000
Received: by hermes--production-gq1-94b89944-tv947 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e768ef29a56adf30a1d5d8aa217168df;
          Tue, 04 Oct 2022 20:59: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
Date: Tue, 4 Oct 2022 13:59:06 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <564843EB-2699-4742-B642-9D0DF57A9C96@yahoo.com>
References: 
 <20221001193033.GA98348@www.zefox.net>
 <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MhqnY1Kkkz3G4r
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ECQ8XK3Q;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-4, at 01:25, Mark Millard  wrote:

> I found a configuration that gets the RPi3 EDK2 and FreeBSD
> combination to have the serial console working. You can try
> booting and operating via the RPi3 EDK2 UEFI materials.
>=20
> However, microsd cards should still not be mounted/used from
> a FreeBSD that has been booted via RPi3 EDK2. Bluetooth is
> disabled as part of getting a working serial console.
>=20
> I ended up with a RPi3 EDK2 microsd card for use in booting
> that has:

I should have also shown the likes of
(USB microsd card reader/writer in use):

=3D>      63  61145025    da3  MBR  (29G)
        63      1985         - free -  (993K)
      2048  61143040  da3s1  fat32  (29G)

via the likes of:

# gpart add -i1 -b2048 -tfat32 da3

after the gpart create command.

A smaller slice/partition with newfs_msdos placing
fat16 ( so: -F16 on the command line instead of -F32 )
also worked for booting. But for the above I used:

# newfs_msdos -F32 /dev/da3s1

The detailed MBR type for the slice/partition set via
gpart does not seem to have to be an exact match for
16 vs. 32 in newfs_msdos but keeping them tracking is
probably a good idea.

> # mount -onoatime -tmsdosfs /dev/da3s1 /mnt
> # find /mnt -print
> /mnt
> /mnt/RPI_EFI.fd
> /mnt/bootcode.bin
> /mnt/config.txt
> /mnt/fixup.dat
> /mnt/start.elf
> /mnt/Readme.md
> /mnt/bcm2710-rpi-3-b-plus.dtb
> /mnt/bcm2710-rpi-3-b.dtb
> /mnt/bcm2710-rpi-cm3.dtb
> /mnt/firmware
> /mnt/firmware/Readme.txt
> /mnt/firmware/brcmfmac43455-sdio.txt
> /mnt/firmware/brcmfmac43455-sdio.bin
> /mnt/firmware/brcmfmac43455-sdio.clm_blob
> /mnt/firmware/LICENCE_bin+clm_blob.txt
> /mnt/firmware/brcmfmac43430-sdio.clm_blob
> /mnt/firmware/brcmfmac43430-sdio.txt
> /mnt/firmware/brcmfmac43430-sdio.bin
> /mnt/firmware/LICENSE_txt.txt
> /mnt/overlays
> /mnt/overlays/disable-bt.dtbo
>=20
> All but the 2 "overlays" lines are based on the content of:
>=20
> =
https://github.com/pftf/RPi3/releases/download/v1.37/RPi3_UEFI_Firmware_v1=
.37.zip
>=20
> disable-bt.dtbo is a copy of one from a RPi* firmware
> used for booting FreeBSD on RPi*s. It is not in the .zip
> file.
>=20
> I adjusted config.txt to indicate to use the disable-bt.dtbo :
>=20
> # more /mnt/config.txt
> arm_64bit=3D1
> disable_commandline_tags=3D2
> disable_overscan=3D1
> enable_uart=3D1
> uart_2ndstage=3D1
> armstub=3DRPI_EFI.fd
> device_tree_address=3D0x1f0000
> device_tree_end=3D0x200000
> #
> # Local addition(s):
> dtoverlay=3Ddisable-bt
>=20
> (The file has a carriage returns at the end of each
> line. Some editors show such characters as ^M .
> The characters could be deleted if desired.)
>=20
> I'll note that the firmware/* content is likely of
> no use for FreeBSD at this point but I did not
> remove it. It should be okay to not have it present.
>=20
> I'll note that the output from "uart_2ndstage=3D1" does
> not actually display during the boot sequence. (Sent
> to the wrong internal UART, as if dtoverlay=3Ddisable-bt
> had not been used, from what I understand.)
>=20
> Using that microsd card in the RPi3B should try to
> boot. The EFI prompt will timeout and continue to the
> next stage (so far as it is successful, anyway). If
> it all works, it will get to the "login: " prompt.
> I'm not familiar with what the error reporting would
> be like if it also has troubles with your equipment.
>=20
> You hit the return key to explicitly continue at the
> EFI prompt. The Escape key can be used instead to get
> into the menu system for controlling the UEFI
> settings.
>=20
> If it gets far enough, the UEFI will try to find the
> EFI/BOOT/* on your USB media's msdosfs. If found, it
> will then load the FreeBSD loader and  then start it
> --and things would then be back in familiar territory.
>=20
>=20
> The above actually boots via a default setting that likely
> should be replaced. The related menu/field nesting is:
>=20
> Device Manager
>    Raspberry Pi Configuration
>        Advanced Configuration
>            System Table Selection 
>=20
> Picking just Devicetree instead, then saving, and then
> exiting the nested menus via a sequence of Escape key
> presses, until back to the initial display, one can
> then select Reset and it will start over based on the
> new setting. The save actually updates an area in the
> RPI_EFI.fd file.
>=20
> (The issue is that the ACPI information is odd:
> Microsoft specific, not standard. So if the ACPI
> information is used things are possibly not
> complete/correct.)
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct  4 21:36:30 2022
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 4MhrcZ47bpz4dmVm
	for ; Tue,  4 Oct 2022 21:36:30 +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 4MhrcZ1vDlz3Kmq
	for ; Tue,  4 Oct 2022 21:36:30 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4MhrcZ0hBDzhFY
	for ; Tue,  4 Oct 2022 21:36:30 +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 294LaTC7056006
	for ; Tue, 4 Oct 2022 21:36:29 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 294LaTaX056005
	for freebsd-arm@FreeBSD.org; Tue, 4 Oct 2022 21:36:29 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 266657] Clearfog pro boot hang
Date: Tue, 04 Oct 2022 21:36:30 +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 Many People
X-Bugzilla-Who: trees@neti.ee
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: Works As Intended
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status resolution
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664919390;
	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=rBcbFWtLKGPN4m6jCIqyXmDwdeXSkAQ2LSIPHmsauOc=;
	b=nrq0+TASnaO0TzzQbj+y8Rf8XB9UFs00ItK+A3fzaiI6Jd1p3a1YkAxYRtgXhN7XThQJpH
	YmFXIoI+1snOgHGk2NDdB0IMNjP7g4p41thFYsRi1vCJBNor6RDF7eyTY7ecY+64XPHjaC
	G15TnSNqiJuol5jI5A68NTBAquFEEAuqXfgqu4cVd0dGFrl0khDwV+rEvtfl5E605ekkCv
	035dMrJLQZXLO1jctD4YrAAcRZtjUYWq/qqvZdzRLuWjcMrF44HZ7cxGCqkBdQp7/geItV
	WCpW1njm3zb6OfGdmaQjeuaQUjdwXyJBR4POrHTUwrjc/ahHW3z9WECVB4BvOw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664919390; a=rsa-sha256; cv=none;
	b=V82Sz2iTm82t+NIxyE0NTlgKvQnktqo0trF7GBP3AfVf6H6Xth63WRWcELoI5VVUFCD0TI
	CK2PAHfctYhte86D4VfGINU2Cx5iv1Bpv6kElEps9QbPKqT5e0LWDpZWvn42WALjIYIHut
	eD5pNVphobJSWCKwEI6EDW4j3cjpepEm/ExUq0QuPCvPgdzpdW/FMHKojk+2qBdJTqwJaw
	xbivxz2b03WQrUVVoZG56heCCQuH2oXWBuaJ1x7f9Gz6+EhvoTbdXdJwZ9aVdLKwE5aLWP
	VE4GSzzhNw/NRAFEf3FTl+kmnOY+QuSyj5JuVO18xKf98KNEkJzH96Z2PMrUPg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266657

Priit Trees  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |Works As Intended

--- Comment #2 from Priit Trees  ---
Hi,=20

Yes, The patch is worked. Thank you very much.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Oct  5 03:46:08 2022
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 4Mj0qC5hr2z4V19F;
	Wed,  5 Oct 2022 03:46: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 4Mj0q53Z7Sz3lXQ;
	Wed,  5 Oct 2022 03:46:09 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2953k8fp013304
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 4 Oct 2022 20:46:08 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2953k8Co013303;
	Tue, 4 Oct 2022 20:46:08 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 4 Oct 2022 20:46:08 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org,
        freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221005034608.GA12761@www.zefox.net>
References: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@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: <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
X-Rspamd-Queue-Id: 4Mj0q53Z7Sz3lXQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	BLOCKLISTDE_FAIL(0.00)[50.1.20.27:query timed out];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 04, 2022 at 01:25:17AM -0700, Mark Millard wrote:
> I found a configuration that gets the RPi3 EDK2 and FreeBSD
> combination to have the serial console working. You can try
> booting and operating via the RPi3 EDK2 UEFI materials.
> 

EDK2 boots the JMS576 enclosure rather reliably, 13 out
of 13 tries succeeded, with no failures.

It has more problems with the JMS577 enclosure, failing
mountroot, getting to multi-user twice out of six tries.
Maybe better to say six interventions from the keyboard.

But, seemingly no disk detection failures. I didn't see
anything that I recognized as an error message from EDK2.

 

Here's rather long copy-paste of the console:
-----------begin console output---------

Resetting system ... 



Raspberry Pi Bootcode
Read File: config.txt, 216
Read File: start.elf, 2967424 (bytes)
Read File: fixup.dat, 7216 (bytes)
MESS:00:00:01.135470:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.139825:0: brfs: File read: 216 bytes
MESS:00:00:01.197517:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.203683:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.210019:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.216356:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.222693:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.229030:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.235366:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.241703:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.248040:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.254377:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.260472:0: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.268103:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.272414:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.095665:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:02.103201:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.109130:0: *** Restart logging
MESS:00:00:02.113008:0: brfs: File read: 216 bytes
MESS:00:00:02.118466:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.125624:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.132482:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.139340:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.146197:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.153054:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.159913:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.166770:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.173628:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.180486:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.187101:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.193004:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.200797:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.207656:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.214512:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.221371:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.228229:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.235086:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.241944:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.248802:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.255660:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.262275:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.268145:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:02.276635:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:02.282330:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
MESS:00:00:02.303727:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:02.313078:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:02.317741:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x1f0000 size 0x7107
MESS:00:00:02.338301:0: brfs: File read: 28935 bytes
MESS:00:00:02.413991:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.418020:0: brfs: File read: 216 bytes
MESS:00:00:02.426024:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:02.446619:0: Loaded overlay 'disable-bt'
MESS:00:00:02.491185:0: brfs: File read: 1073 bytes
MESS:00:00:02.494726:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:03.054138:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:03.249078:0: brfs: File read: /mfs/sd/RPI_EFI.fd
MESS:00:00:03.252958:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000
MESS:00:00:03.258784:0: No compatible kernel found
MESS:00:00:03.263284:0: Device tree loaded to 0x1f0000 (size 0x75d8)
MESS:00:00:03.271038:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.277330:0: uart: Baud rate change done...
MESS:00:00:03.280764:0: uart: Baud rate change done...
MESS:00:00:03.286487:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.5(release):
NOTICE:  BL1: Built : 18:50:24, Jun 14 2021
NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082]
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.5(release):
NOTICE:  BL2: Built : 18:50:18, Jun 14 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 18:50:22, Jun 14 2021
UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 2021)










































ESC (setup), F1 (shell), ENTER (boot)......BdsDxe: No bootable option or device 
was found.
BdsDxe: Press any key to enter the Boot Manager Menu.

                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
 Raspberry Pi 3 Model B                                                         
 BCM2837 (ARM Cortex-A53)                            1.20 GHz                   
 UEFI Firmware v1.37                                 1024 MB RAM                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
   Select Language                              Reset                  
                                                                                
 > Device Manager                                                               
 > Boot Manager                                                                 
 > Boot Maintenance Manager                                                     
                                                                                
   Continue                                                                     
   Reset                                                                        
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                          =Select Entry                                 

Raspberry Pi Bootcode
Read File: config.txt, 216
Read File: start.elf, 2967424 (bytes)
Read File: fixup.dat, 7216 (bytes)
MESS:00:00:01.126618:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.130976:0: brfs: File read: 216 bytes
MESS:00:00:01.188663:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.194829:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.201165:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.207502:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.213839:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.220176:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.226513:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.232850:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.239186:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.245523:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.251619:0: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.259178:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.263487:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.086735:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:02.094272:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.100200:0: *** Restart logging
MESS:00:00:02.104078:0: brfs: File read: 216 bytes
MESS:00:00:02.109534:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.116697:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.123552:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.130410:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.137268:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.144125:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.150983:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.157840:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.164698:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.171556:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.178172:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.184074:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.191868:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.198726:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.205584:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.212440:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.219299:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.226157:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.233014:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.239872:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.246730:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.253345:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.259213:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:02.267705:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:02.273400:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
MESS:00:00:02.294801:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:02.304110:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:02.308773:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x1f0000 size 0x7107
MESS:00:00:02.329334:0: brfs: File read: 28935 bytes
MESS:00:00:02.404919:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.408948:0: brfs: File read: 216 bytes
MESS:00:00:02.416896:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:02.437491:0: Loaded overlay 'disable-bt'
MESS:00:00:02.482058:0: brfs: File read: 1073 bytes
MESS:00:00:02.485599:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:03.042457:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:03.237578:0: brfs: File read: /mfs/sd/RPI_EFI.fd
MESS:00:00:03.241459:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000
MESS:00:00:03.247285:0: No compatible kernel found
MESS:00:00:03.251784:0: Device tree loaded to 0x1f0000 (size 0x75d8)
MESS:00:00:03.259540:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.265831:0: uart: Baud rate change done...
MESS:00:00:03.269265:0: uart: Baud rate change done...
MESS:00:00:03.274986:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.5(release):
NOTICE:  BL1: Built : 18:50:24, Jun 14 2021
NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082]
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.5(release):
NOTICE:  BL2: Built : 18:50:18, Jun 14 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 18:50:22, Jun 14 2021
UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 2021)










































ESC (setup), F1 (shell), ENTER (boot)......









































Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk1p1:
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x33843000
   EFI version: 2.70
   EFI Firmware: https://github.com/pftf/RPi3 (rev 1.00)
   Console: efi (0x1000)
   Load Path: \EFI\BOOT\BOOTAA64.EFI
   Load Device: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1
,0x0)/USB(0x3,0x0)/HD(1,MBR,0xF4C26069,0x81F,0x18FA8)
   BootCurrent: 0002
   BootOrder: 0000 0001 0002[*]
   BootInfo Path: VenHw(58ABD787-F64D-4CA2-A034-B9AC2D5AD0CF)
Ignoring Boot0002: Only one DP found
Trying ESP: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1,0x0
)/USB(0x3,0x0)/HD(1,MBR,0xF4C26069,0x81F,0x18FA8)
Setting currdev to disk1p1:
Trying: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1,0x0)/US
B(0x3,0x0)/HD(2,MBR,0xF4C26069,0x197C7,0x746ED5E9)
Setting currdev to disk1p2:
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x8ae560 text=0x20576c data=0x1ab418 data=0x
0+0x2a9000 syms=[0x8+0x123228+0x8+0x146f0d]
Loading configured modules...
/boot/entropy size=0x1000
/boot/kernel/filemon.ko text=0x1574 text=0x272c data=0x500+0x20 syms=[0x8+0xcd8+
0x8+0x7c5]
/boot/kernel/umodem.ko text=0x2060 text=0x1330 data=0x6c8+0x10 syms=[0x8+0xee8+0
x8+0xb42]
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x249f text=0x3380 data=0x8a0+0x858 syms=[0x8+0x1188+0
x8+0xb19]
/etc/hostid size=0x25

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x35c27000.
EFI framebuffer information:
addr, size     0x3eaa9000, 0x151800
dimensions     720 x 480
stride         720
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance
Copyright (c) 1992-2021 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 13.1-STABLE #28 stable/13-5472eacf5: Sat Oct  1 04:04:29 PDT 2022
    root@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
VT(efifb): resolution 720x480
module firmware already present!
real memory  = 989626368 (943 MB)
avail memory = 937533440 (894 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
MAP 1d0000 mode 2 pages 32
MAP 339d0000 mode 2 pages 80
MAP 33a20000 mode 2 pages 256
MAP 37000000 mode 2 pages 400
MAP 37190000 mode 2 pages 592
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
lintc0:  mem 0x40000000-0x400000ff on simplebus0
intc0:  mem 0x7e00b200-0x7e00b3ff irq 39 on simplebus0
gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 6 on simplebus0
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
usb_nop_xceiv0:  on ofwbus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.000000s
bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on simplebus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 9 on simplebus0
uart0: console (115200,n,8,1)
sdhost_bcm0:  mem 0x7e202000-0x7e2020ff irq 10 on simplebus0
sdhost_bcm0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk.
mmc0:  on sdhost_bcm0
bcm283x_dwcotg0:  mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0
usbus1 on bcm283x_dwcotg0
bcm_dma0:  mem 0x7e007000-0x7e007eff irq 23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0
bcmwd0:  mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023 on simplebus0
bcmrng0:  mem 0x7e104000-0x7e10400f irq 40 on simplebus0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff irq 49 on simplebus0
mmc1:  on sdhci_bcm0
gpioc1:  on gpio1
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.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 720x480(720x480@0,0) 32bpp
fb0: fbswap: 1, pitch 2880, base 0x3eaa9000, screen_size 1382400
pmu0:  irq 0 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
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
mmcsd0: 32GB  at mmc0 50.0MHz/4bit/65535-block
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmc1: No compatible cards found on bus
bcm2835_cpufreq0: ARM 1200MHz, Core 250MHz, SDRAM 400MHz, Turbo ON
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <>
Trying to mount root from ufs:/dev/da0s2a [rw]...
 Instruction Set Attributes 2 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
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
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:ba:68:d5
Root mount waiting for: usbus1
ugen1.4:  at usbus1
uhub2 on uhub1
uhub2:  on usbus1
uhub2: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1
Root mount waiting for: usbus1
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)
Root mount waiting for: usbus1
Root mount waiting for: usbus1
usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR
Root mount waiting for: usbus1
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
ugen1.6:  at usbus1
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00 
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n DD564198838F9 detached
g_dev_taste: g_dev_taste(da0) failed to g_attach, error=6
(da0:umass-sim0:0:0:0): Periph destroyed
umass0: detached
mountroot: waiting for device /dev/da0s2a...
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)
Mounting from ufs:/dev/da0s2a failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/da0s2a
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8101
umass0:0:0: Attached to scbus0
ugen1.5:  at usbus1 (disconnected)
umass0: at uhub2, port 4, addr 5 (disconnected)
(da0:umass-sim0:0:0:0): got CAM status 0xa
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
umass0: detached
usb_alloc_device: set address 5 failed (USB_ERR_TIMEOUT, ignored)
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:0:0: Attached to scbus0
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2

panic: mountroot: unable to (re-)mount root.
cpuid = 1
time = 34
KDB: stack backtrace:
#0 0xffff0000004fb6d4 at kdb_backtrace+0x60
#1 0xffff0000004a6da0 at vpanic+0x13c
#2 0xffff0000004a6c60 at panic+0x44
#3 0xffff000000595ac4 at vfs_mountroot+0x1e18
#4 0xffff00000041ebc4 at start_init+0x28
#5 0xffff000000455dcc at fork_exit+0x88
#6 0xffff0000007e56f4 at fork_trampoline+0x14
Uptime: 34s
Resetting system ... 



Raspberry Pi Bootcode
Read File: config.txt, 216
Read File: start.elf, 2967424 (bytes)
Read File: fixup.dat, 7216 (bytes)
MESS:00:00:01.102818:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.107176:0: brfs: File read: 216 bytes
MESS:00:00:01.164875:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:01.171042:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:01.177377:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:01.183714:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:01.190051:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:01.196388:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:01.202725:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:01.209061:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:01.215398:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:01.221735:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:01.227831:0: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:01.235446:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:01.239756:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.063000:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:02.070535:0: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
MESS:00:00:02.076465:0: *** Restart logging
MESS:00:00:02.080342:0: brfs: File read: 216 bytes
MESS:00:00:02.085802:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.092959:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.099817:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.106675:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.113532:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.120390:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.127248:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.134105:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.140962:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.147820:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.154436:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.160339:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:02.168132:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:02.174991:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:02.181848:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:02.188706:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:02.195564:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:02.202421:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:02.209278:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:02.216137:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:02.222994:0: hdmi: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:02.229610:0: hdmi: HDMI0:EDID giving up on reading EDID block 0
MESS:00:00:02.235477:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:02.243970:0: HDMI0: hdmi_pixel_encoding: 162000000
MESS:00:00:02.249665:0: vec: vec_middleware_power_on: vec_base: 0x7e806000 rev-id 0x00002708 @ vec: 0x7e806100 @ 0x00000420 enc: 0x7e806060 @ 0x00000220 cgmsae: 0x7e80605c @ 0x00000000
MESS:00:00:02.271063:0: dtb_file 'bcm2710-rpi-3-b.dtb'
MESS:00:00:02.280447:0: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
MESS:00:00:02.285110:0: Loading 'bcm2710-rpi-3-b.dtb' to 0x1f0000 size 0x7107
MESS:00:00:02.305670:0: brfs: File read: 28935 bytes
MESS:00:00:02.381368:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:02.385397:0: brfs: File read: 216 bytes
MESS:00:00:02.393415:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:02.414010:0: Loaded overlay 'disable-bt'
MESS:00:00:02.458575:0: brfs: File read: 1073 bytes
MESS:00:00:02.462115:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:03.023262:0: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
MESS:00:00:03.218252:0: brfs: File read: /mfs/sd/RPI_EFI.fd
MESS:00:00:03.222132:0: Loading 'RPI_EFI.fd' to 0x0 size 0x1f0000
MESS:00:00:03.227957:0: No compatible kernel found
MESS:00:00:03.232458:0: Device tree loaded to 0x1f0000 (size 0x75d8)
MESS:00:00:03.240223:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.246515:0: uart: Baud rate change done...
MESS:00:00:03.249949:0: uart: Baud rate change done...
MESS:00:00:03.255665:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.5(release):
NOTICE:  BL1: Built : 18:50:24, Jun 14 2021
NOTICE:  rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082]
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.5(release):
NOTICE:  BL2: Built : 18:50:18, Jun 14 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.5(release):
NOTICE:  BL31: Built : 18:50:22, Jun 14 2021
UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 2021)










































ESC (setup), F1 (shell), ENTER (boot)......









































Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk1p1:
FreeBSD/arm64 EFI loader, Revision 1.1

   Command line arguments: loader.efi
   Image base: 0x33843000
   EFI version: 2.70
   EFI Firmware: https://github.com/pftf/RPi3 (rev 1.00)
   Console: efi (0x1000)
   Load Path: \EFI\BOOT\BOOTAA64.EFI
   Load Device: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1
,0x0)/USB(0x3,0x0)/HD(1,MBR,0xF4C26069,0x81F,0x18FA8)
   BootCurrent: 0002
   BootOrder: 0000 0001 0002[*]
   BootInfo Path: VenHw(58ABD787-F64D-4CA2-A034-B9AC2D5AD0CF)
Ignoring Boot0002: Only one DP found
Trying ESP: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1,0x0
)/USB(0x3,0x0)/HD(1,MBR,0xF4C26069,0x81F,0x18FA8)
Setting currdev to disk1p1:
Trying: VenHw(4BF1704C-03F4-46D5-BCA6-82FA580BADFD)/USB(0x0,0x0)/USB(0x1,0x0)/US
B(0x3,0x0)/HD(2,MBR,0xF4C26069,0x197C7,0x746ED5E9)
Setting currdev to disk1p2:
Loading /boot/defaults/loader.conf
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x2a8 text=0x8ae560 text=0x20576c data=0x1ab418 data=0x
0+0x2a9000 syms=[0x8+0x123228+0x8+0x146f0d]
Loading configured modules...
/etc/hostid size=0x25
/boot/kernel/filemon.ko text=0x1574 text=0x272c data=0x500+0x20 syms=[0x8+0xcd8+
0x8+0x7c5]
/boot/kernel/umodem.ko text=0x2060 text=0x1330 data=0x6c8+0x10 syms=[0x8+0xee8+0
x8+0xb42]
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x249f text=0x3380 data=0x8a0+0x858 syms=[0x8+0x1188+0
x8+0xb19]
/boot/entropy size=0x1000

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x35c27000.
EFI framebuffer information:
addr, size     0x3eaa9000, 0x151800
dimensions     720 x 480
stride         720
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
---<>---
WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance
Copyright (c) 1992-2021 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 13.1-STABLE #28 stable/13-5472eacf5: Sat Oct  1 04:04:29 PDT 2022
    root@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
VT(efifb): resolution 720x480
module firmware already present!
real memory  = 989626368 (943 MB)
avail memory = 937533440 (894 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
MAP 1d0000 mode 2 pages 32
MAP 339d0000 mode 2 pages 80
MAP 33a20000 mode 2 pages 256
MAP 37000000 mode 2 pages 400
MAP 37190000 mode 2 pages 592
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
bcm2835_firmware0:  on simplebus0
ofw_clkbus1:  on bcm2835_firmware0
psci0:  on ofwbus0
lintc0:  mem 0x40000000-0x400000ff on simplebus0
intc0:  mem 0x7e00b200-0x7e00b3ff irq 39 on simplebus0
gpio0:  mem 0x7e200000-0x7e2000b3 irq 7,8 on simplebus0
gpiobus0:  on gpio0
gpio1:  on bcm2835_firmware0
gpiobus1:  on gpio1
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 6 on simplebus0
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
usb_nop_xceiv0:  on ofwbus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.000000s
bcm2835_clkman0:  mem 0x7e101000-0x7e102fff on simplebus0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e2011ff irq 9 on simplebus0
uart0: console (115200,n,8,1)
sdhost_bcm0:  mem 0x7e202000-0x7e2020ff irq 10 on simplebus0
sdhost_bcm0-slot0: Hardware doesn't specify timeout clock frequency, setting BROKEN_TIMEOUT quirk.
mmc0:  on sdhost_bcm0
bcm283x_dwcotg0:  mem 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 21,22 on simplebus0
usbus1 on bcm283x_dwcotg0
bcm_dma0:  mem 0x7e007000-0x7e007eff irq 23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38 on simplebus0
bcmwd0:  mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023 on simplebus0
bcmrng0:  mem 0x7e104000-0x7e10400f irq 40 on simplebus0
sdhci_bcm0:  mem 0x7e300000-0x7e3000ff irq 49 on simplebus0
mmc1:  on sdhci_bcm0
gpioc1:  on gpio1
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.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 720x480(720x480@0,0) 32bpp
fb0: fbswap: 1, pitch 2880, base 0x3eaa9000, screen_size 1382400
pmu0:  irq 0 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
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
mmcsd0: 32GB  at mmc0 50.0MHz/4bit/65535-block
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmc1: No compatible cards found on bus
bcm2835_cpufreq0: ARM 1200MHz, Core 250MHz, SDRAM 400MHz, Turbo ON
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
 Instruction Set Attributes 0 = 
Trying to mount root from ufs:/dev/da0s2a [rw]...
 Instruction Set Attributes 1 = <>
 Instruction Set Attributes 2 = <>
         Processor Features 0 = 
         Processor Features 1 = <>
      Memory Model Features 0 = 
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = 
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = 
AArch32 Media and VFP Features 0 = 
AArch32 Media and VFP Features 1 = 
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
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:ba:68:d5
Root mount waiting for: usbus1
ugen1.4:  at usbus1
uhub2 on uhub1
uhub2:  on usbus1
uhub2: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
Root mount waiting for: usbus1
ugen1.5:  at usbus1
umass0 on uhub2
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
ugen1.6:  at usbus1
Root mount waiting for: da
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number DD564198838F9
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=0x2
Dual Console: Serial Primary, Video Secondary
Setting hostuuid: 30303030-3030-3030-3064-626136386435.
Setting hostid: 0x5cd40a6a.
warning: total configured swap (2097152 pages) exceeds maximum recommended amount (916632 pages).
warning: increase kern.maxswzone or reduce amount of swap.
Starting file system checks:
/dev/da0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s2a: clean, 615063 free (1415 frags, 76706 blocks, 0.2% fragmentation)
/dev/da0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s2d: clean, 221933849 free (156689 frags, 27722145 blocks, 0.1% fragmentation)
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/graphviz /usr/local/lib/perl5/5.32/mach/CORE
Setting hostname: pelorus.zefox.org.
Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
lo0: link state changed to UP
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP
Starting Network: lo0 ue0.
lo0: flags=8049 metric 0 mtu 16384
        options=680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21
ue0: flags=8843 metric 0 mtu 1500
        options=80009
        ether b8:27:eb:ba:68:d5
        inet 50.1.20.24 netmask 0xffffff00 broadcast 50.1.20.255
        media: Ethernet autoselect (100baseTX )
        status: active
        nd6 options=29
Starting devd.
Autoloading module: uftdi
uftdi0 on uhub1
uftdi0:  on usbus1
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add net default: gateway 50.1.20.1
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Updating /var/run/os-release done.
Creating and/or trimming log files.
Clearing /tmp (X related).
Updating motd:.
Starting syslogd.
Setting date via ntp.
 4 Oct 20:15:39 ntpdate[806]: step time server 165.140.142.118 offset +30244085.121417 sec
Starting powerd.
Mounting late filesystems:.
Performing sanity check on sshd configuration.
Starting sshd.
Starting cron.
Starting sendmail.
Starting sendmail_msp_queue.
Configuring vt: blanktime.
Performing sanity check on apache24 configuration:
Syntax OK
Starting apache24.
Starting background file system checks in 60 seconds.

Tue Oct  4 20:15:42 PDT 
FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)

login: root
Password:
Oct  4 20:15:57 pelorus login[933]: ROOT LOGIN (root) ON ttyu0
Last login: Tue Oct  4 20:11:59 on ttyu0
FreeBSD 13.1-STABLE #28 stable/13-5472eacf5: Sat Oct  1 04:04:29 PDT 2022     root@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
root@pelorus:~ # cd /usr/src
root@pelorus:/usr/src # git pull
remote: Enumerating objects: 79851, done.
remote: Counting objects: 100% (79851/79851), done.
remote: Compressing objects: 100% (19406/19406), done.
remote: Total 79382 (delta 61209), reused 76702 (delta 59557), pack-reused 0
Receiving objects: 100% (79382/79382), 47.48 MiB | 1.16 MiB/s, done.
Resolving deltas: 100% (61209/61209), completed with 412 local objects.
>From https://git.freebsd.org/src
   5472eacf5..5ec288b57  stable/13  -> origin/stable/13
Updating 5472eacf5..5ec288b57
Updating files: 100% (280/280), done.
Fast-forward
----end console output-------

At this point I decided to run an overnight buildworld/kernel
to see how the disk behaves under load.


> The above actually boots via a default setting that likely
> should be replaced. The related menu/field nesting is:
> 
> Device Manager
>     Raspberry Pi Configuration
>         Advanced Configuration
>             System Table Selection 
> 
> Picking just Devicetree instead, then saving, and then
> exiting the nested menus via a sequence of Escape key
> presses, until back to the initial display, one can
> then select Reset and it will start over based on the
> new setting. The save actually updates an area in the
> RPI_EFI.fd file.
> 

I'll try that after the new kernel/userland is installed.
Is it likely to affect the mountroot issue?

Thank you _very_ much!

bob prohaska


From nobody Wed Oct  5 06:27:00 2022
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 4Mj4Nw2m6Tz4cy27
	for ; Wed,  5 Oct 2022 06:27:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mj4Nv0s1Mz3wry
	for ; Wed,  5 Oct 2022 06:27:10 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664951227; bh=7DEPV7qV9GIonTnxWIAIg3ok1+KqFEkbHRb6NvCt+qU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kNPpTSGxdXticsy69DgYC4eeUIfDjLDUhqYH686BnQ6ZXC5MGM06sjPn5lqIeQE86Aq511rbz0FsoMoQ3f9vBCAokfQ5KrF/EC17s3MnmrweMbiLSvcoawWqr4p1w572FFdAmCpiy+nRPYMeRvd1x/VrAAftxc25MNxN6X9Y5pUXjqe0Hh3qM894EjJAweBkM4i6JRK7hefgsMEbM1OopwLp05u9Qt5mvbFJ8nJQU1PmGF4MaG2wGwlefF1DwxjHvWzUQTlSLcevAk7pA4uRiTm/qDZ29m0vczlZpY1J8lQvKyUfvZAQ6XvPdCJ4tEDKbqW/RK06TJOShgbXLwQVhg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664951227; bh=jIrnMDJBTAeIgg2H2dZgD51CmZnIMjAgzIza1WPUOWK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r2WbB7u7ZQk5WxGtElVswN8AAYFM2Spu49nbQeVDYlEj9lsZ6YPAv+IZ9vthjdS1r0WC4Ba/HWv+h/lJgVA9gC4xnLCYE3/DT3+V+NnpIbLMCPw0EL41jcZRT+PzFgKEZPJ05VAoqu0HvdV0PEoQw/erqiYDdXnDS+ZcxSpgqoRN7TCpVFL4kaq5+n24xuGGI+mMRtPlnVmBNy/R7uFo8LcJxgsWJQNedE8SBCHDVcfE1um2OkqtrpOpe4rzv7ksT07rtrNpC3B2UuHERlgAh11/IXOTuRua3buf5bnREOtrEXzzj3BnV5yRd3b8puojJPak/iYs1QhqzPzL/JnGIw==
X-YMail-OSG: bGU9hn8VM1mlApnFB0FwngAlVSKEVfAl.feBm5w6jIkKO7h9F9PUW_SaKcLUVxP
 B.Yyu8BDX0nFt3.3NGbR3rOYUDfk.ZMLpkZatAN9Zsp.z8jEHWeSdzJT13DLLTHyaDCnL1EWOq7c
 D0xgMz9L_CjAvIbqC.ZF_27oRFQraHoHZAvB9rf8M0isDjjsHYJMM6gKgs_91x.UBMXZy1p8QeGb
 oDgJYiaA0RpcRXEK1LqwM7TbkcXbmGuaix1bQUFQ6AAiOQ6siU2_wxmfEjCy6t5Sm5GtJzF.oK5l
 Cy4ModJN240.T.GhJ9qeFkGCRw.AmfY59lvDXj00ULKTZL8hEtUJwfFcqBy1l1xVqE4ZvX19yn9B
 F1KK9HcspxXLsK5gHFSfXcnfuu2n01x16WwxfUJdi0ofWKZx2KXqSY.5UUp7Wz1efMFhydmy9oL7
 kBqAK2y8TSsk4m9p6hvS5RWOu2EWhblLWzRNWSATkxiWvuwSotEDzm6Rz1CjiIok4Yy.oDV9DAlm
 CwxRdFuM9Np4pse7gTnCYnBxy.B98MGNiLkv_ZkwxCYNXeH0iCElRjJHWOoXtVIRuEKQXOqM0yho
 ipuvVh.ynN3sNmQR7TEB9vxBcausR66siDd2X.SsZqD6ohGwWnsxNKJgOxdXryFJGVhSwGq6QZwb
 e8Ps_wZWVtX28HhX5SWWGjI0T8mBb0OtjRl5CodZh0ACSLqc6uRbUK2kUK2g35NsSWjVAsvDvy1o
 feR6Q.C_8tbz9lC8M08Ye.AT0XUOHm78JaGAfBMVrzfZ_XsUU2CsMYeKf_jlmFAE0I6a9l2cb0kV
 DYqSnYpJb_Q50MXCHESp836dWpjzwWb4ALKnASHK3KqqqRah3IzjL7pbkiyFABjCKav3PrlxekNQ
 fiH0laqw6pIg8k94LSnvFeBe5Kk4MHio1wkbvbnF49YHZLepZlO5mif3RBCHtgDrs8QYTDs.U1Oz
 TWFaW490l1EWQvb9ETMevNI8FWOOTWGWj4ice2gGBl2DFpTtrR7RqId2GK6PM7X9G9VHHBdhz6Jf
 iKrolhQpp1TJX05eAV2Km36NSf0XGKzAlkHRlo.7kGnoD7LA2weeOhNk75Hie86EtGi7ZPSTiyLv
 VgNyshl1XHfDPJJshga2qXby47tHXhcvdZdmWcnJwQoDCiDPRnRM7yNLEot5XsfUrAZTWKeud50D
 zMR8xhfbn.59yCUBUa7Uga187KKSBSDwJaHyf_HEWTXeHSVwCF3ZKoLY.l.RGFzb6pzpOLSONjgs
 3JgpGNzYhqmfc1yvRxbZ0IHGELsJI3dVUs3wsf5zl3Sd0K6HkcGh0Rfl79r0iEc_gXGmeGHLiuax
 MYN6drcMpyI6YIq2A9L_sf_c2FgQvCURpL7FeSsg4yci1zNik2pL1yUKP2NwK8u0cBIHnEZsvpGj
 eynYvjiXzzYuns1v_2fVzlRqgYnk1f9y2VOGCWC.N4EbVo8yQSTpMJBpYpkp2izO7beT8q4bL1Ie
 F1WIcWyJ8GXWlKrxevTdWwEEByYzZ5biBCh9ovSeOVJjKzDfRn322fT3ZH3QjYUjkpocM.j0wA6V
 qWz6sY6KN7CUf8uCnk5Yq3NO.wPnVtV5H6ER4OSxCsyxA6zq8nNuX9CcA2y7Vw1bWjEbvdqoJi75
 M69Sq3O4j4SMDqfpSbzzkW16QMY04mnHHryzCnmTgIPc2JLiXJiH8CTuSke4mItWU.Y2wmqKS93o
 5Vt0pGxOMGQkYNta_Jp9OwvB5sPYkmJzwLWji.OOdRmyMXrQWnbQaQ7dL6t_YRcQ9bdzCI.Tl36O
 eb47n0M3lidy.Ir9TBz0JDrD5Jauz51kQ5_3SNqA_jEjJviAw4RZTrtZgo6r4bISRntBbTKv0uGm
 4yAqbRnt_LPsW.MZchBYR1fsPUBCiA.HHiFubuKpidUPt_4oRME3gX5notHizG6_pEmKwlBtdsMU
 DODSR2RAzOwPlsVQJnPcjakmHM6sa4whc8oQS35vSLUGOYtkzlZFa.47.6bFs_FKKzzPhBJOTllg
 IwoFsAkEzcf_T6cDWoBouFfI3U7MyS2CIOiZRUNJk1Hr.daF1Luyk4YQx8LiYYZPUlrtyPoYxE4q
 61X7FHCGzjRWb5sop.1sdTvEusT3MBSPUzWZggAwD6MgtL8t4ptgVCSa6QOYLbsge9WLRyQJa6h3
 eItbo9WUCQ98tgBayNxqPZr_CV_rzBxUaresO5x5kbZuardBVDxlMjTLGxeHFNhcM3qA.b9UstB0
 0P0aFZWKEwOvldlhZOGjIf7s2j6VgR945sqKca.bEoM5TOki1uMYq_wHkwsOVcghSu0tvg54dkgr
 e7bPs3A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 06:27:07 +0000
Received: by hermes--production-ne1-6944b4579f-p7xcb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5e8ff8d1c2a39bcfb0f5fbff9adf713f;
          Wed, 05 Oct 2022 06:27:02 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221005034608.GA12761@www.zefox.net>
Date: Tue, 4 Oct 2022 23:27:00 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
References: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mj4Nv0s1Mz3wry
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=kNPpTSGx;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.978];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-4, at 20:46, bob prohaska  wrote:

> On Tue, Oct 04, 2022 at 01:25:17AM -0700, Mark Millard wrote:
>> I found a configuration that gets the RPi3 EDK2 and FreeBSD
>> combination to have the serial console working. You can try
>> booting and operating via the RPi3 EDK2 UEFI materials.
>>=20
>=20
> EDK2 boots the JMS576 enclosure rather reliably, 13 out
> of 13 tries succeeded, with no failures.

Note: I prefer the 0x152d:0x0583 identification, just because
it is something I can see in the logs. As I remember, no
log ever shows a "576" from having the specific enclosure in
use.

> It has more problems with the JMS577 enclosure, failing
> mountroot, getting to multi-user twice out of six tries.
> Maybe better to say six interventions from the keyboard.

Well, at least having 0x152d:0x0583 work is a useful
improvement.

> But, seemingly no disk detection failures. I didn't see
> anything that I recognized as an error message from EDK2.
> . . .
> ESC (setup), F1 (shell), ENTER (boot)......BdsDxe: No bootable option =
or device=20
> was found.

That looks like a "no [successful] disk detection
failure" notice by EDK2 and is an example of a EDK2
error report, given that you know there should have
been bootable media accessible.

There is such a thing as a pre-built debug EDK2 build,
at least for RPi4 EDK2. If there is for RPi3 EDK2,
then we might be able to get more message text. But
it need not lead to avoiding the problem.

> BdsDxe: Press any key to enter the Boot Manager Menu.
> . . .
> UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 =
2021)
> . . .
> Consoles: EFI console =20
>    Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk1p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> . . .
> ---<>---
> . . .
> Root mount waiting for: usbus1
> ugen1.4:  at usbus1
> uhub2 on uhub1
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus1
> Root mount waiting for: usbus1
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
> usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

That is the FreeBSD kernel having a problem dealing with the
0x152d:0x0577 . We have seen this in your prior logs as well.

Note that U-Boot was not involved at any stage this time.
Adjusting U-Boot would be unlikely to prevent this from
happening. Nor is it likely that adjusting EDK2 could.
Looks like the FreeBSD kernel would have to manage to deal
with the issue via an error recovery handling. There is
no evidence to suggest being able to avoid the problem
occurring.

> . . .
> usbd_setup_device_desc: getting device descriptor at addr 5 failed, =
USB_ERR_IOERROR

Looks to be a consequence of the above.

> Root mount waiting for: usbus1
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  =
on usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number DD564198838F9
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
> ugen1.6:  at usbus1
> ugen1.5:  at usbus1 (disconnected)

Possibly another consequence? Or a new failure?
("addr 5" is, apparently, successfully referenced
a few lines above. So I'm guessing: new failure.)

> umass0: at uhub2, port 4, addr 5 (disconnected)
> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:   s/n DD564198838F9 detached
> g_dev_taste: g_dev_taste(da0) failed to g_attach, error=3D6

A consequence?

> (da0:umass-sim0:0:0:0): Periph destroyed
> umass0: detached
> mountroot: waiting for device /dev/da0s2a...
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
> usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)

Note that UQ_MSC_NO_TEST_UNIT_READY was nor reported
previously. Likely it indicates another failure lead
to the extra message --or a consequence based failure.

> usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
> usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

Like the earlier usbd_req_re_enumerate message.

Looks like the below has some of the same points
as the above sequence. I'll not comment.

> Mounting from ufs:/dev/da0s2a failed with error 19.
>=20
> Loader variables:
>  vfs.root.mountfrom=3Dufs:/dev/da0s2a
>  vfs.root.mountfrom.options=3Drw
>=20
> Manual root filesystem specification:
>  : [options]
>      Mount  using filesystem 
>      and with the specified (optional) option list.
>=20
>    eg. ufs:/dev/da0s1a
>        zfs:zroot/ROOT/default
>        cd9660:/dev/cd0 ro
>          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
>=20
>  ?               List valid disk boot devices
>  .               Yield 1 second (for background tasks)
>      Abort manual input
>=20
> mountroot> usbd_setup_device_desc: getting device descriptor at addr 5 =
failed, USB_ERR_IOERROR
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  =
on usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x8101
> umass0:0:0: Attached to scbus0
> ugen1.5:  at usbus1 (disconnected)
> umass0: at uhub2, port 4, addr 5 (disconnected)
> (da0:umass-sim0:0:0:0): got CAM status 0xa
> (da0:umass-sim0:0:0:0): fatal error, failed to attach to device
> umass0: detached
> usb_alloc_device: set address 5 failed (USB_ERR_TIMEOUT, ignored)
> ugen1.5:  at usbus1
> umass0 on uhub2
> umass0:  on usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0000
> umass0:0:0: Attached to scbus0
> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20
> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number DD564198838F9
> da0: 40.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2

I'm not sure if you did a:

    Abort manual input

here or not. If you did, the below is likely
not surprising.

> panic: mountroot: unable to (re-)mount root.
> cpuid =3D 1
> time =3D 34
> KDB: stack backtrace:
> #0 0xffff0000004fb6d4 at kdb_backtrace+0x60
> #1 0xffff0000004a6da0 at vpanic+0x13c
> #2 0xffff0000004a6c60 at panic+0x44
> #3 0xffff000000595ac4 at vfs_mountroot+0x1e18
> #4 0xffff00000041ebc4 at start_init+0x28
> #5 0xffff000000455dcc at fork_exit+0x88
> #6 0xffff0000007e56f4 at fork_trampoline+0x14
> Uptime: 34s
> Resetting system ...=20
>=20
>=20
>=20
> Raspberry Pi Bootcode
> . . .
> UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 =
2021)
> . . .
> ESC (setup), F1 (shell), ENTER (boot)......
> . . .
> Consoles: EFI console =20
>    Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk1p1:
> FreeBSD/arm64 EFI loader, Revision 1.1
> . . .
> ---<>---
> . . .
> Starting background file system checks in 60 seconds.
>=20
> Tue Oct  4 20:15:42 PDT=20
> FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
>=20
> login: root

No problem observed this time.

> . . .
>=20
> At this point I decided to run an overnight buildworld/kernel
> to see how the disk behaves under load.
>=20
>=20
>> The above actually boots via a default setting that likely
>> should be replaced. The related menu/field nesting is:
>>=20
>> Device Manager
>>    Raspberry Pi Configuration
>>        Advanced Configuration
>>            System Table Selection 
>>=20
>> Picking just Devicetree instead, then saving, and then
>> exiting the nested menus via a sequence of Escape key
>> presses, until back to the initial display, one can
>> then select Reset and it will start over based on the
>> new setting. The save actually updates an area in the
>> RPI_EFI.fd file.
>>=20
>=20
> I'll try that after the new kernel/userland is installed.
> Is it likely to affect the mountroot issue?

No. So far it seems that FreeBSD is managing to ignore
the ACPI and just use Devicetree. So it is more of a
"lets just be sure to avoid the potential problem"
issue.


On a possible issue: You have

ugen1.6:  at usbus1

plugged in.

My normal context has just the 1 USB3 NVMe
media, the Ethernet cable, serial console
connection, fan, and power plugged in. (I
ignore the microsd card slot here.) This
works fine. (I do not have a powered hub
involved.)

In in experiments I discovered that if I
plug in an example keyboard (that also
has a mouse plugged into it), it messes
up my ability to boot the RPi3 via, for
example, U-Boot.

It might be worth experimenting with
avoiding having more plugged in than:

Boot USB drive (I count your powered hub as part of this)
Ethernet cable
serial console connection
fan
power

and seeing if boots more often than your
normal configuration vs. not doing so.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Oct  5 16:00:31 2022
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 4MjK6Y0XTSz4V641
	for ; Wed,  5 Oct 2022 16:00:37 +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 4MjK6X25JQz3kRP
	for ; Wed,  5 Oct 2022 16:00:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664985634; bh=JPDAuGP3iVWU0fj6ck1zRYFMNpz8QrzZ6QbVtppUHYg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CrBNC2aSGkBQMhF67KOhFfc+cGBDmCCpykVkAhGfPKoYBYZYbE5G4U+4kJLVtkikXoF0K6V5yh7KU5iR5dOveJEfCY6H+Lekq5v2rhJ4sYKPJpHGyZn+eThX7VaLPZlChRyU4tkAHvhuXzkUKAF9SB75b2/oDUr367w7SZtaU0tR8biiQx572wnT1bud+Acbqzkox38daiW7TUmk7o+6GCNmptbOjS/vsOJzJnYf2lG2mjSln1O3mpD/mnU1JAyaY8d+2QfUnr+ZvlpEgh+2b9e2qiSmSPVsi98qj5KKPRFV1PRdfYCESJM156SEX8os81IdbFGNW0Ph2dkN1nOfdw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664985634; bh=0IofUzytcx0oCsvsgi4Xie4Fxn7v1RYlhpnJfBKF0/l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ui3yu10ToVJMzCVKGxLBmZ3XRv89CUKf1dZTvsToKT39yGhp5oGsfENMeSWSSBAeLe09l7Sw+TcaYmlTvK0k7ZHsYUf/Sove5wnvHHgNm41YKJKvhI0X3hAitCFDpOLxrGObUR39YJViq9EbBa+s41HMtFZABx278Fs8utgqhLiNj4X/NQfIrjL8fWh5llnHtvL6p+Zhm/Ym/HJO1eGFhPwMU9lc+H66DGul8bICmnAGIhiNpRCehM6areWMmvKD0QbWpRuIkzlfadc51u5MyjbQPYguK5aUS4I5zp0+fnVTiw8FhNlDnxJmOXQkyp2n6p8Yq/qAlMQ8PyGIjp8plA==
X-YMail-OSG: o7Uir4oVM1mCWVCl1RIK7yFZNGDymbQhkmU71kFV2F9Gfb6cDs7hPxio2uaDUcp
 InQn0VjiT4ii.pKTb66k6M55t5Zguk3SkENDLs9AaMv8YOPxJQJlw9UZUYead1paMUmNFEG0VN61
 0eyvWIAvhiEQV1zbA7Y6MVrwnSyV0KSwF3.GXal7Gd7OHuRR0woMtdwylSCMXf21hFwGTRsxHm2U
 xEp8Ca7N.W3B9YBXyrRhVHaiFS8nlxU2BRPN5UTaFdCXo0XfXMyBUoYkIpTmk6pvxzJNmEV1.rXy
 gPbx9Ra3D_p2f61Kp7XsothrDFJooJoZ9tYYhoO94b1AUA09QTBXFxPTcMBv.nh8516d8wnzZjJx
 Gf2yq8QLpOFyylTQlpSWM8IExm5vIfbONSTZuFJtGKdCZkWJ9h3NTFTtpfggu7V4yIXB2aweFbm_
 JO95t7jAHDRPrjDbmI_w_ne1wF133i54gGYCQ4EIDKdqVcaLo1_Ogps53TdUn1w1d.l2EAdF8wru
 mf1bGvjZZqCnTKM7Z20woPzqiOYD9qAGzAVjrox2APnJd4bi.av3znMbHyfDIfsRZD3tZfIt.iae
 BShlnBMbO1zItWusn340YXS0FHuycsLpXT1pXlCFaehfQyhI0zhytiKvl3RRFTjzkbrWhKH.9WvY
 vgwWfPCcRE43JD51oVOYbqPdQfv6YJdjDveKzatJ7Z4jH5VZAw4viqhORqb6t65UfLDFHmg28Xd5
 tZweN1LTpFlg73lzcmj2IZZVHsKfx.75mcQRlUKopr0hQAg2inRAOYuP5AwM6GDvdFtKYhQlAp_b
 KlTLAv_aWeqc96NpMfoJJOH3ovG0CS.JNCcSue02ir3wftlc3aElTIA8zmKUE0g6Lfscsr.9kyBc
 eth4cSdx7eQkBcAGWlq9kX_YHmCpH0SYalJQrEWldwo6XLGE9LippTW2tqC0E4ccBhgiji97vu5V
 7JBEMrKLlMiGI8LmNg0p7AA4wg2.iHjIkwtgPpagb9eiIecdARCPZutqVMqWeVqtA8W__Ivk15HJ
 n4L4p7UaI4ILdxPdm9xAB2eTZ9vhX_NitjSAwdCLzrPH4Sel0QRo9hNwyz_QHRMshPFFZ5Cenyqy
 Zp_PZ8Fc7lQYAUUf69o5_J_8cKwtOuGeMr0CvBdM9oGHwmpPeUUAZLJJaUIPoc2jtFWrzsJUIjcp
 8d6Fd9iDnLrIqQAezIuFdx4EvqPueUhQYC2qVZVKBsZ.2IuPrbP5MVBfnyJzB7vwNtrFJih9HWWa
 UFxixBin7IUtbgwAdCSdL7i5evPxgbith3bI609zXn3nmN7m.YSRIxiYZlLiYDHiIOOrMHU9flmZ
 4lX8jNhbWMKwHGDMSjZsl_hKlwRqsVcoZi5VaG6VNDFlcObXBUDf4YNHvz5JZYoxm_uPh084g1Sk
 z2WjsUeuauC9dGxB5TzzKp1Dwq7B9GwRx7ZBRIxiySGnXbID8OeewEc7P5rynZnEbNPvSvUVlG2U
 liI_6s8a4JcJdXf.XJLlpzQ9mUxabunI3CVahW5AdHoTzxwh8xb6QBl.1DIDyfh3aKFyBacexU8W
 RgiNq5QtE8VVk5_J4LOdpYY5Gxkd0K8KaKcw3LcP98tSYG3hMehtnZSViJrrF3mqguAsH9Hw3hZ_
 8qHJvaaHdAA2cQ3PgQQEzlW9bF71pkw4dVjCwT2mk79acx8br.tzM79g6pSgfa_7abbcRAK40lnR
 OJh82R7t.gCWNs9l3BfcZ4cptz5DHa9qx6.OqpeSdDi2y7iOmmZ_o1MFUFHfvsOk5kilwkDXpxaO
 cbisFrrzcVmlIu9xOgVKKT55bLmtQlCBGX.DSiHuCanK2gq5kBrLxK4cTj36VASQuZye38OBT_BU
 itaQLlQdjzgeJG_cNSQTcHlkkpDodhDOrTjCub4_zc6BhIhb.PCvoMRzAWxKgY4Fc9T9e_ED32M_
 xwFEep7rBi3YJD4fjtjfK4olnoSRMvCHB5WiGQ7l4s3BFrcO9xLrgqPe_Mec2d36Fo4qnA8dQYPw
 erh7AYGrMaqmtBRLCiPGxhEqUS3gXZgxNMt.rXQsw4EHad2qc_voXw9rHSKq2j7NGUDonw0_0R6v
 pWgWdDlelJOezcNbFM9mPgpPlMemQqUxaCjlFX5X9EniF8.QLwP9KFogkBUKbIUbXeFA.BOfgb2T
 B0oN9QbmrPK2wecv6BC2DT0O_gNp47O3zbLMwi74QtgKJgVuXsgktcbvjJ4QAwEzOPsS8ulbM9Db
 c6hRlpXxAW._.VQ0vkk8biFMZfwRvtmtbtQsOMINInPXkEr7tokM1OXnlwz4TMIZhhcTE73B_sx7
 aOA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 16:00:34 +0000
Received: by hermes--production-gq1-94b89944-5szfq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 76556f4a6986d063d9dc9e07a9c20526;
          Wed, 05 Oct 2022 16:00:32 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221005034608.GA12761@www.zefox.net>
Date: Wed, 5 Oct 2022 09:00:31 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <45C39108-22D0-4494-A6F2-B8BEDFCD089D@yahoo.com>
References: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MjK6X25JQz3kRP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CrBNC2aS;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-4, at 20:46, bob prohaska  wrote:

> . . .
> 
> At this point I decided to run an overnight buildworld/kernel
> to see how the disk behaves under load.
> 

I do not know if you normally use config.txt to control
the arm or any other frequencies in use (for your RPi3B
based build activities to take less time). If you
normally do, but have not for the EDK2 context, expect
potential time difference contributions from the lack
of control.

===
Mark Millard
marklmi at yahoo.com


From nobody Wed Oct  5 16:07:37 2022
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 4MjKGb3Qqtz4V6dY;
	Wed,  5 Oct 2022 16:07:35 +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 4MjKGZ2nVsz3l7g;
	Wed,  5 Oct 2022 16:07:34 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 295G7c19015315
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 5 Oct 2022 09:07:38 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 295G7ceU015314;
	Wed, 5 Oct 2022 09:07:38 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 5 Oct 2022 09:07:37 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm@freebsd.org, freebsd-uboot@freebsd.org
Subject: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
Message-ID: <20221005160737.GA15227@www.zefox.net>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@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: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
X-Rspamd-Queue-Id: 4MjKGZ2nVsz3l7g
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 04, 2022 at 11:27:00PM -0700, Mark Millard wrote:
> On 2022-Oct-4, at 20:46, bob prohaska  wrote:
> 
> > 
> > EDK2 boots the JMS576 enclosure rather reliably, 13 out
> > of 13 tries succeeded, with no failures.
> 
> Note: I prefer the 0x152d:0x0583 identification, just because
> it is something I can see in the logs. As I remember, no
> log ever shows a "576" from having the specific enclosure in
> use.
> 

I'll stick to calling the "good" enclosure 0x0583.



> > But, seemingly no disk detection failures. I didn't see
> > anything that I recognized as an error message from EDK2.
> > . . .
> > ESC (setup), F1 (shell), ENTER (boot)......BdsDxe: No bootable option or device 
> > was found.
> 
> That looks like a "no [successful] disk detection
> failure" notice by EDK2 and is an example of a EDK2
> error report, given that you know there should have
> been bootable media accessible.
> 

Indeed, I missed it.

> There is such a thing as a pre-built debug EDK2 build,
> at least for RPi4 EDK2. If there is for RPi3 EDK2,
> then we might be able to get more message text. But
> it need not lead to avoiding the problem.
> 

I gather you're suggesting that debugging delays in EDK2
might not have the same effect as debugging delays in u-boot?
Would it still be worth trying if available?

> 
> Note that U-Boot was not involved at any stage this time.

To my understanding u-boot isn't present, unless I made a
mistake. Are you suggesting something else?

> Adjusting U-Boot would be unlikely to prevent this from
> happening. Nor is it likely that adjusting EDK2 could.

Perhaps, but I don't understand the inference... yet.
AIUI, EDK2 discovers the parameters the kernel needs to
communicate with the disk and passes them to the kernel. 
Is this a distiction between reading the disk and writing?

> Looks like the FreeBSD kernel would have to manage to deal
> with the issue via an error recovery handling. There is
> no evidence to suggest being able to avoid the problem
> occurring.
> 
> > . . .
> > usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR
> 
> Looks to be a consequence of the above.
> 
> > Root mount waiting for: usbus1
> > ugen1.5:  at usbus1
> > umass0 on uhub2
> > umass0:  on usbus1
> > umass0:  SCSI over Bulk-Only; quirks = 0x8100
> > umass0:0:0: Attached to scbus0
> > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0:  Fixed Direct Access SPC-4 SCSI device
> > da0: Serial Number DD564198838F9
> > da0: 40.000MB/s transfers
> > da0: 953869MB (1953525168 512 byte sectors)
> > da0: quirks=0x2
> > ugen1.6:  at usbus1
> > ugen1.5:  at usbus1 (disconnected)
> 
> Possibly another consequence? Or a new failure?
> ("addr 5" is, apparently, successfully referenced
> a few lines above. So I'm guessing: new failure.)
> 
> > umass0: at uhub2, port 4, addr 5 (disconnected)
> > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00 
> > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain

The "...request completed with an error... line is rather familiar
and in the past has proved innocuous on Pi3 and I think Pi4, though
not seen recently.

> > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0:   s/n DD564198838F9 detached
> > g_dev_taste: g_dev_taste(da0) failed to g_attach, error=6
> 
> A consequence?
> 
> > (da0:umass-sim0:0:0:0): Periph destroyed
> > umass0: detached
> > mountroot: waiting for device /dev/da0s2a...
> > usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
> > usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_READY set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
> 
> Note that UQ_MSC_NO_TEST_UNIT_READY was nor reported
> previously. Likely it indicates another failure lead
> to the extra message --or a consequence based failure.
> 
> > usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
> > usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)
> 
> Like the earlier usbd_req_re_enumerate message.
> 
> Looks like the below has some of the same points
> as the above sequence. I'll not comment.
> 
> > Mounting from ufs:/dev/da0s2a failed with error 19.
> > 
> > Loader variables:
> >  vfs.root.mountfrom=ufs:/dev/da0s2a
> >  vfs.root.mountfrom.options=rw
> > 
> > Manual root filesystem specification:
> >  : [options]
> >      Mount  using filesystem 
> >      and with the specified (optional) option list.
> > 
> >    eg. ufs:/dev/da0s1a
> >        zfs:zroot/ROOT/default
> >        cd9660:/dev/cd0 ro
> >          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> > 
> >  ?               List valid disk boot devices
> >  .               Yield 1 second (for background tasks)
> >      Abort manual input
> > 
> > mountroot> usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR
> > ugen1.5:  at usbus1
> > umass0 on uhub2
> > umass0:  on usbus1
> > umass0:  SCSI over Bulk-Only; quirks = 0x8101
> > umass0:0:0: Attached to scbus0
> > ugen1.5:  at usbus1 (disconnected)
> > umass0: at uhub2, port 4, addr 5 (disconnected)
> > (da0:umass-sim0:0:0:0): got CAM status 0xa
> > (da0:umass-sim0:0:0:0): fatal error, failed to attach to device
> > umass0: detached
> > usb_alloc_device: set address 5 failed (USB_ERR_TIMEOUT, ignored)
> > ugen1.5:  at usbus1
> > umass0 on uhub2
> > umass0:  on usbus1
> > umass0:  SCSI over Bulk-Only; quirks = 0x0000
> > umass0:0:0: Attached to scbus0
> > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 
> > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> > (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0:  Fixed Direct Access SPC-4 SCSI device
> > da0: Serial Number DD564198838F9
> > da0: 40.000MB/s transfers
> > da0: 953869MB (1953525168 512 byte sectors)
> > da0: quirks=0x2
> 
> I'm not sure if you did a:
> 
>     Abort manual input
> 
> here or not. If you did, the below is likely
> not surprising.
> 

Yes, carriage return.

> > panic: mountroot: unable to (re-)mount root.
> > cpuid = 1
> > time = 34
> > KDB: stack backtrace:
> > #0 0xffff0000004fb6d4 at kdb_backtrace+0x60
> > #1 0xffff0000004a6da0 at vpanic+0x13c
> > #2 0xffff0000004a6c60 at panic+0x44
> > #3 0xffff000000595ac4 at vfs_mountroot+0x1e18
> > #4 0xffff00000041ebc4 at start_init+0x28
> > #5 0xffff000000455dcc at fork_exit+0x88
> > #6 0xffff0000007e56f4 at fork_trampoline+0x14
> > Uptime: 34s
> > Resetting system ... 
> > 
> > 
> > 
> > Raspberry Pi Bootcode
> > . . .
> > UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 2021)
> > . . .
> > ESC (setup), F1 (shell), ENTER (boot)......
> > . . .
> > Consoles: EFI console  
> >    Reading loader env vars from /efi/freebsd/loader.env
> > Setting currdev to disk1p1:
> > FreeBSD/arm64 EFI loader, Revision 1.1
> > . . .
> > ---<>---
> > . . .
> > Starting background file system checks in 60 seconds.
> > 
> > Tue Oct  4 20:15:42 PDT 
> > FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)
> > 
> > login: root
> 
> No problem observed this time.
> 
> > . . .
> 
> No. So far it seems that FreeBSD is managing to ignore
> the ACPI and just use Devicetree. So it is more of a
> "lets just be sure to avoid the potential problem"
> issue.
> 
> 
> On a possible issue: You have
> 
> ugen1.6:  at usbus1
> 
> plugged in.
> 
> My normal context has just the 1 USB3 NVMe
> media, the Ethernet cable, serial console
> connection, fan, and power plugged in. (I
> ignore the microsd card slot here.) This
> works fine. (I do not have a powered hub
> involved.)
> 
> In in experiments I discovered that if I
> plug in an example keyboard (that also
> has a mouse plugged into it), it messes
> up my ability to boot the RPi3 via, for
> example, U-Boot.
> 
> It might be worth experimenting with
> avoiding having more plugged in than:
> 
> Boot USB drive (I count your powered hub as part of this)
> Ethernet cable
> serial console connection
> fan
> power
> 
> and seeing if boots more often than your
> normal configuration vs. not doing so.
> 

I have made similar observations, but very long (years)
ago. Adding a hub and keyboard seemed to interfere with
boot. Can't remember if it was boot from USB or just 
USB-mounted /usr. There are still some anomalies if a
USB disk is plugged in to a running USB-rooted Pi host.
That seems undesirable, but maybe unavoidable. RasPiOS
has the same problem.

For now buildworld is still in the building libraries 
stage. At the moment it's swap-bound and showing ~750 
MB swap in use at 53% idle. No sign of disk problems
yet. Looks like moutroot is more delicate than I/O.

If there are any EDK2 boot options worth exploring
please indicate. I've seen the help menu but nothing
looks familiar.

Thanks for your continued help!

bob prohaska


From nobody Wed Oct  5 17:29:28 2022
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 4MjM5C17fSz4dfyx
	for ; Wed,  5 Oct 2022 17:29:35 +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 4MjM595l9Dz3xKm
	for ; Wed,  5 Oct 2022 17:29:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664990972; bh=ha24ULWjlVbizmonAwtH/rNxr2aPGs+5i1lYLi+hM10=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lqzD+z4tZX7eQkEBHTB9cyDFzkmm7cqISqZa0PGFVkXcCsXCmb4IOqA0K8uG6dSNg0RkvDXQhgoFqssdeXiDtEaVaZeGu8EygmIhkmZH5gZAXuio87yzJUAeFQ1aGkh3CQZuncnIhHbhVnIUpIUxYg4BMWJ83vZiNJRmxdvaijMh6qx31TPnLjTsr0qULHuKD840/8YqdzYOuvLNn4kpnx7kB0x0H3ZPRs30iOMsmXdyVOInTtCUbicRqnrYyNONP4b3bRK0DNCV8UsDke+gfZsmHr69/zWeBgIexpBEIVBdHG6oCT/y9DacFQ/4P9nwQwq3qVDgsUDgBBlGKIIwAw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664990972; bh=zkoCUTm+IbFq8JYxuSWn4yEmcS9UCglfcrFPL4fPzvf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NUXdo8ITVQmqBBbg8caideea1V+DGV7rjx5FIMLBsqMYOz1aCGzap49VA4GG9FyAUGCggy22fWUKrDvKIaUzm4kZ8OPt4WHy03WqsY9cfWqjTCmjhRWKoABn3glGAHtSS7kpUyByOZZUVmWLdhG9ZI7D3JkRxAPJD23vsvJX5TybYJLTpP1ZKMfw98GwxCCA9oC4CBIaOpaJSG+CbcZg1GViFdNBWO4aiauIXgQw1I7TPPau7Pyvv1wt8aUOct3la5YDHKeHNKPBh6yfO7fIB6PFIDBy4uiDG7ijcDl/Z1BryhIztM1pLxk0Qjb8qi8t2/BTZs2/nBIxxgN6MaV7lw==
X-YMail-OSG: cQsnI10VM1nN05j.K6BCEDotaxMlb_dlRbsp_N6mXSbKgyVzmHzD5W8HqcJAEGV
 aVx7.e7i8iB27Mlsm3WTMKPDMeoObH5not0mhjVFM8XwonC9BDpqjahpK9qkY8Qn1uFEwoX1KTw_
 KEhmV91NYa8hBRkjoVhSJYvfeL6_E4eTXqNqOBUNzJOylRCrOwKg.kXeZ2RH4j2sf631UBxBX0XP
 eLmQ3uh6NjAz38T6UsLpxculBiRmAffA1P5.h_xo9xNTmdX_5fE6Z57QIOQyXyNKEXVv9v0LyUTj
 c7_xA3SdI17FRdLiCFDY3uLWBVW3v4wCiF7xwOnedeC0ki6QZa3VAT0QH3MFSFx5CKjEAxSin.lC
 hhnYozcmyUzHxguDvGIxlam1afx1TYp_4tAzdP5oOWo4G3n1EHM5Dms3x0XVdViW9nf.jzkjTsIP
 QQ8I9xe3cf.xgsb3.kQ9s1nWtW7RGOgWG6WLQFxllpT1eEHiF_PnS96dnh1Zo6EJKkUbSNtNIO7f
 p4VtEZeBwpvScUTG97xmTGO.TsnzwfeJTbL4WlpCuWcvCH5EBCE7sC68tpVlGIqLQnbHKvFFdIhJ
 x3hz7OgxaxC4fg8X3wureBY9yRZR2vArBhomF_xnVSvLeZ89ZotcO_XBaJ42rxoQKLr3IQ5AXDCs
 XRLFq5Z_SxnNjnvS1AMcuSF65zCPB4vjolxSLagNUz0R6QYp_IM.8EG2Hux8GLy8C1YFnFwcN2sj
 tkFXhpLIGKhA4qSH57bmIkKnkLxdDbjcMfg2PE1jutC4IYTU1lcmRYdsWbDK70.i_dZ.2fAVhePZ
 L_5FauxOG8Vj72UNtKLFzJsZ8os3r0vn2qLt_k57dXjanmijuuGCN0q8FZ.MpWuPF4Fw1Qpm.wVp
 U70F2w96TB7p1azkTTQ.pkIHoQ8avhPFqKh3I.6jXuv3MlUWN0JHQ5OqfMxtY2LGPc2xGgwtItE5
 b4dLWZRrPsxNO3S55etq5wjIBGqnYWqiuh.7LTpxFTM2mNuQ4JuvsDYginCB.hWopNBHgp2v6PHr
 ydBle1zwfDYdoNkmFSAX.yrn2OUj2WUlZQCRP926kxyq.JAhsPX9Wrorjr7y9z3UXHfncpMAG68z
 xEDjzrCIDwpMFKlHnGLW_jyMWgT.ngmrR_vb3vqqTPMJ6PzqTNWM89N94C9pJjAGVErtqtkZWgTT
 Zp2GeMtehhcrDRUJjpCL8gEIuuEI49R8s_1iSjAJN77mFjYQxoJQfV6KvZcPgTQPexiZE6TUgi0a
 VWPKsv4kxd3YAcvsD6ajLywvFPtAHWtJo3Y0fo4H4sEyro1WSwq6s87pmYry7sb74JGMmGe.n0em
 IxHTFlI.vY.ufuJmvY8unScVdwb4FwwVNW2y.1R3D_PqCvAaeX3ehKF8HcS.K.a1A1w5wBw0E2OP
 pry1iAnsyhTLHHYD44pO3aqbNEptfblhjwY4Ma1.bD9iRXQvUaZRvmWJmGAHNAkQaLoO0fxF5w1q
 1gfwmOSCH._nXma0b5YayXFUoJpDrWpYXq6fkoPIywL8VpKwTRRJSiHpgUQIQWSBiBsvx0UFc7uq
 XwATMbCk02uhkhy08FZnbn1946KxhH2gxLIc.xj.QSTGiKrJobDF1LP8AvHZrvyNbbc4d78VY02e
 D.X3iZF5kIZ4ftQvR.jF28_TZtWtqzJ3ji.DkyQyP4zSnxWycHkopo4yPXaoAU8DWzEbg.MnciOL
 DCN0byfnF3XpGHzUsZeU7z812cem9kOuNW14q1EXqseFwtZxb_9l2V6W_4RWukHB4O7eYIbW7qky
 PnyHrqdMcn5St7SxLFx.ywhCcpmVXohBW.8wiwhCb0dFugrBDkJQMaoIfE19gRLJa364uNGtc98b
 BCOE3M2Vpcx0fQJyJIBoH.B4845iRQEG5qPo4_H4Ras8zgT1NPFrWroIBxuX7pqPKE6Xbmuq2kx6
 QPjOaOCECRw9l4M.nj7l_swn57G0lA2IEYKjT_zUvCEqIf6ziw_Lyuiblhsl9CTMLnp9MQt9GFHk
 6xBOXcIO4h0VYNPXrxtP54Oso1ha8Zjydg9MzKFwSvRekohD.QkBHsnPekzFRtPDr8i8PsgKiZFG
 o9ctqtvftVJLw.Rf3KWNXWT3a9SZJmRkFI.5pSw7HSnV7xupIcQ3SuOE3H6RsArPm5541ugpM2P2
 .95BiTLi6xLIgsXVp9Y1Lr6EZ3FWJwvmujdhdEI0KMH0DaVryIsdmINsfl3jjjiaBK1dGqrqBnGN
 uPIYJ2LRmqCQEe37wm8VaTXnfQK_hzGEYiyBqnxRWDRW3yif3v1CRL9WGdLmLRnTwESueGFZlHMR
 .j3g-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 17:29:32 +0000
Received: by hermes--production-gq1-94b89944-k82lp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d9bd95eae22e1be6ac0860b873e9c9cf;
          Wed, 05 Oct 2022 17:29: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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <20221005160737.GA15227@www.zefox.net>
Date: Wed, 5 Oct 2022 10:29:28 -0700
Cc: freebsd-arm@freebsd.org,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MjM595l9Dz3xKm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lqzD+z4t;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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.950];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-5, at 09:07, bob prohaska  wrote:

> . . .
>=20
>> There is such a thing as a pre-built debug EDK2 build,
>> at least for RPi4 EDK2. If there is for RPi3 EDK2,
>> then we might be able to get more message text. But
>> it need not lead to avoiding the problem.
>>=20
>=20
> I gather you're suggesting that debugging delays in EDK2
> might not have the same effect as debugging delays in u-boot?
> Would it still be worth trying if available?

They still would be problematical. But we did learn things
like that the root hub in the RPi3 was having odd behavior
via U-Boot --even if we did not find a solution to your
overall problem.

But, it turns out that the "build artifacts" for the official
RPi* EDK2 builds have an expiration duration. It has been
long enough since the EDK2 releases release that there is no
debug build artifact available now.

>>=20
>> Note that U-Boot was not involved at any stage this time.
>=20
> To my understanding u-boot isn't present, unless I made a
> mistake. Are you suggesting something else?

No: the point is that the problems are occurring when
U-Boot can not contribute to the problems. The problem
is in no way U-Boot specific.

>> Adjusting U-Boot would be unlikely to prevent this from
>> happening. Nor is it likely that adjusting EDK2 could.
>=20
> Perhaps, but I don't understand the inference... yet.
> AIUI, EDK2 discovers the parameters the kernel needs to
> communicate with the disk and passes them to the kernel.

The kernel uses the Device Tree handed over by either
U-Boot or EDK2. They in turn start from the 1 that is
handed by the RPi* firmware. That in turn starts from
.dtb's in the msdosfs. The RPi* firmware and U-Boot/EDK2
can make adjustments to the original .dtb material
to cover platform details not handled by the static
files in msdosfs.

(An example is the 8 GiByte variations with and without
the lower-3-GiByte DMA limitation: some address ranges
in the final Device Tree vary.)

The Device Tree does not reference the specific USB
devices plugged in. The FreeBSD kernel handles such on
its own. (Such is why it can boot world via USB3 on the
Rock64 but U-Boot and the FreeBSD loader do not deal
with the USB3 as things are.)

FreeBSD's kernel does its own binding and initializations
to the USB context(s).

> Is this a distiction between reading the disk and writing?

I was not referencing that distinction at all.

>> Looks like the FreeBSD kernel would have to manage to deal
>> with the issue via an error recovery handling. There is
>> no evidence to suggest being able to avoid the problem
>> occurring.
>>=20
>>> . . .
>>> usbd_setup_device_desc: getting device descriptor at addr 5 failed, =
USB_ERR_IOERROR
>>=20
>> Looks to be a consequence of the above.
>>=20
>>> Root mount waiting for: usbus1
>>> ugen1.5:  at usbus1
>>> umass0 on uhub2
>>> umass0:  =
on usbus1
>>> umass0:  SCSI over Bulk-Only; quirks =3D 0x8100
>>> umass0:0:0: Attached to scbus0
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number DD564198838F9
>>> da0: 40.000MB/s transfers
>>> da0: 953869MB (1953525168 512 byte sectors)
>>> da0: quirks=3D0x2
>>> ugen1.6:  at usbus1
>>> ugen1.5:  at usbus1 (disconnected)
>>=20
>> Possibly another consequence? Or a new failure?
>> ("addr 5" is, apparently, successfully referenced
>> a few lines above. So I'm guessing: new failure.)
>>=20
>>> umass0: at uhub2, port 4, addr 5 (disconnected)
>>> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00=20=

>>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
>>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
>=20
> The "...request completed with an error... line is rather familiar
> and in the past has proved innocuous on Pi3 and I think Pi4, though
> not seen recently.

In various past configurations, I've seen one such message
in the kernel's part of the boot sequence historically.
I treat it as normal for what FreeBSD does at this stage
for some types of RPi* --and that is why I did not comment
about it explicitly.

>>> . . .
>=20
> For now buildworld is still in the building libraries=20
> stage. At the moment it's swap-bound and showing ~750=20
> MB swap in use at 53% idle. No sign of disk problems
> yet. Looks like moutroot is more delicate than I/O.

The command sequences are not the same for normal
operation vs. binding time. For example, the kind of
activity that reports:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)

only happens at binding time. And the next message
is the first error report:

usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

There is no evidence that the 0x0577 is doing
anything odd for the normal-operation context:
No issue to be delicate relative to, for that
kind of context.

There is evidence that the 0x0577 does odd things
for some of the the binding time activities,
although the details relative to the status
relative to the standards is not clear.

I do not have the background to know from the
evidence that we have seen, just what violations
of the standard by the 0x0577 may be involved
vs. what incompletenesses in the FreeBSD binding
logic might be vs. both. Binding logic can not
reasonably be expected to handle arbitrary
violations of the standards --and the 0x0577
context might well be violating the standards.
But implementations of binding logic can be
incomplete relative to standard-conformant
devices as well. So: Unsure.

> If there are any EDK2 boot options worth exploring
> please indicate. I've seen the help menu but nothing
> looks familiar.

Nothing in EDK2 or U-Boot is likely to help with
avoiding the kernel getting the sequence:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

I'm also not aware of anything that would be relevant
to avoiding the:

BdsDxe: No bootable option or device was found.

during EDK2's activity.

I will note that FreeBSD likely has debugging
notices for the USB binding activities that could
be enabled, not that I know such would prove
useful.


Side note:

I got the following once over night:

Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Controller timeout
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Sys addr: 0x00000000 =
| Version:  0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Blk size: 0x00000200 =
| Blk cnt:  0x00000001
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Argument: 0x40510000 =
| Trn mode: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Present:  0x000b0000 =
| Host ctl: 0x00000002
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Power:    0x0000000f =
| Blk gap:  0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Wake-up:  0x00000000 =
| Clock:    0x00000107
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Timeout:  0x00000000 =
| Int stat: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Int enab: 0x00000000 =
| Sig enab: 0x01ff00fa
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: AC12 err: 0x00000000 =
| Host ctl2:0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Caps:     0x00000000 =
| Caps2:    0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Max curr: 0x00000000 =
| ADMA err: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: ADMA addr:0x00000000 =
| Slot int: 0x00000000
Oct  5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: =
=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
Oct  5 03:01:11 CA72_UFS kernel: mmcsd0: Error indicated: 1 Timeout

So, apparently, there can be occasional messages about
the microsd card slot for the RPi3 EDK2 context. I've
no clue why the messages were produced but I had removed
and put back the microsd card earlier in the day, without
rebooting between or after. Thus the message lines might
also happen for other types of booting, such as via
U-Boot, if I'd done similarly.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Oct  5 18:01:30 2022
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 4MjMpB4dCCz4dkPP
	for ; Wed,  5 Oct 2022 18:01:38 +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 4MjMp959dCz40DM
	for ; Wed,  5 Oct 2022 18:01:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664992895; bh=HFONtiojOK2tKNwU1xsCh21dygQcMJwhs7oxghLzNC4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CzIY03Brleqo+to1s+tBvvoaJkXFY4Z0G6tSKSZw8SyFHVmSpuJGpKYtnUL0ZVaqzzBjgikXju8IxH8hJBadTJ6JcSmCqGpugDdFN4ab1S+rQSR56OZ6+QkT5aYwk1mboXeIlw+x8be8bKSi+/eO8t3Ci2I97P4ZK06Sfz8VrDwbKwagbCVPPczaSWIPUonmppnzuutrgxIovj9KiUTnSGxElr/YRpBYAkBrmBMIzi7Mt7vJjCW3MaXh2UMpvIqlxOQ7l4vIKcdcTloc9/dBhEw2QqWOT94TbrIBJrwebbZMwnviWjCi+BPxksP55w4rhLpVPwv583Y2z02YTQVWBw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664992895; bh=LKatPzAm6090dIISxiEFgriZ6cUwPnFeMchXFnzc1n8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cSBpBcXqxubWRkc0Bv5Lwo0Hm1u2/zb4MNHZMZDHnttdCwnGPJzXqwVRRR1lfeg7yTkpb8YnQdo1SpIlrVZMhvWXslz2IubWhJS5vpsEOLJYXpKmkmuJljEjztrPgAGkAkwsG3y3PAEKzPVxOeMfQmq85j9cE78ovm4m09q3Nbx5/32DV9Yv2p674bXZnuPP0ezPhh121w51nvcJooAzxoFKENZ9vjLoDd1FoT88PfGt0U1TGupQFXm8a9ELviv1GJVtIxOeboL+OaNzhPDJ6M3wwSiZKOfbIEY0gQ260QknY7ICaQLLuzDsyJECyuLkTlerNEK6ymNlP2bOWXHLzQ==
X-YMail-OSG: mSYbauUVM1kbQnry5lINrW_Kwt4CmipSjUWQxxGOdJB87MCG7l4odtUukrJGdsi
 3UOnrRivXF7UbzWtEqDaHAJwDQTSVddMAXG5iLMJHxAyQsXKoh1cMaHrTgLiM0jUGoI8KhvGyZ7i
 b1lnisvaB30KHxCKO1BEqwomFAAPDYs1Ws6tcBG_zSRQn1RdE_2kCY7xZ0SeFhdjac7ZwSqYpDLL
 r14wWl_ENPdIczpZVpVRPQEFftgAVaE1vJWV7En_PLeTY9QfbnssjFIvxq2sl8b_XX_qw9qM.0Bf
 ynZVzwNYuEJS.OATi7l0raQa0wMJMlIqtYlOGlkkAMUt4GGNYWF_Q.uvjVPU8UjVMnT6.Qg53Lpy
 6aK8Y2_FuFK3Xw5clvqWhywkp_lW0kahBwp_jp0GvKA.AXNzsrh6eFqh.KzlXzPoGfLzsOdl2WlC
 NzUUM7kDtMqVycN1lVzclLEF00M5fqj7WVnxe.npMLjh.TRSa.e1Q0JuhY2cZ1fpCE6XK5X9fZXB
 eLggyGdxPke0taUyPTvyMCu2YgW9NAGhIQ1mF2DI2iX8OU5ausiw6eUc2aDqs4_JYzchm9t0zFu5
 lMHD1D4U0Rax1AR7orCBHs4E4ILod3mWWCzVJdgVphZqQOTc6x7SwNA2IhPo5b2CHfyhnZwmyx.l
 UI2KXjpMqw1HnukCYlkTNpFwbQqcDmZbAaEsTbroAneUSThcp.tRZYcVz5k_qoDvxWRPQ9fSLngI
 9S6EssgmOeGOrEg9HtHq3fZiX9bZPsGySaEN4._fpfulTDzkH4oS5m1FZA.e6tO3DITW.ZWATXoj
 tZgrlZVxNu2TcGwtkojq64Tm.hPxxIZLj.CvrFmh0RbvTzJUFCZJBbqmfHJv0.R.KukRQfJIIJ4s
 p6rZr4Yvg5IXoBZ05QsVO.eFVBh8b4z3_eBcvqXZdKgM10VK8IVr6rQDrTGHIK018Zz7GcYJN3uk
 o6.lHWhUd8bq.RgBhAc7RXIiEmTB8D8WFPdG4o4worZWatGfF1nHmRnnSPtLW.NvrgczLXrc.3DG
 6Grd9eBPSxQczKMFT6J54VsZYqODCFKjA._CYL4ustm27ivInz_TMO.0lCBJ6V3aJZ0FCLbAraC5
 u55f_0GTbwcBq2NlPF8Kl1Uy3a_hs9PfPMOGcugSHRmnNFJIWXwXeIn7lcJy2OeO_W6FMpSjXOEr
 zZQL5VcheAVgleKvosiZ0o9hJQP1m2vAcaAh7D.L69OxDN0zM.VStwZz82NOcSZ8Cdk61olaGagx
 cYr_b38j93Kvcoc.UNh4dBkFY.a5L2IqSG9dg49Kzz75DExk1Ee.5LvV_TdM.DpAnLIVQcynpQv5
 fEza1RumlkevYEGoW8Nqk2TYYlp.YXvCVi7JaurJ9EX0dnfiOz016dO0Ae5vhi3hCRQkn0fPXw8A
 T9PEG2kC3jEGTSP4yvEFAkJ7mqFtUl4nY88t5lpCP2m3dgCJMkxXSZkNqDOw8BUqxKVSTXB8adbY
 N0oukWlmVoAYMLMrMtc6_D0fAyr9XP0RwCcAf7bSRaE7obUWaf4zQeoUqY8w7vdWo.9aOrWIUZ0e
 H9Nz0hfAra17UH2Zo0D0qimthFKDK4NBvvAI44Mmv6aK3fxz_jaPai7.9GurDAW_Ag4cIzuTcEkm
 OTPwfwgw1aZWpJdnEGhZw8UqFYqA_Y06.vfV_KZCXPQyfmUAupxJcghHiUVFyZeHq2XCmRWTLRnb
 1MahxHmMPB1Cs2dWpj6lqDygB2bMxoJ3.BpN_hSU5WzRlSFF9D1cbemJ3PRQgwJjOkYc0WjUwSjy
 Uv7uZ8nnsDjz91O_vfGay5p2bheTb.Q3Gkq_hRPaDDOQN3jrPlpLFg3KGtXSiifESHgmh1C1y_pz
 JRzRblD3nf49c08xzohGK68ZrlYcb8llFTDUAiaJACLHHj0fSmTNQ8gWDwBCdMMwe3VjBEIOZAzU
 BSluF4QdMKcHtoIxMzDKhVOgHM98AOk3kVQK5R1s73eg0Z907kmiUWPdC2XFSRDC6B.Fs_ar0IDk
 .cjC.rNPhsslUXT_PfrdktnYMDcRR96zAUBKlUKyXpAg5g2pVgwG1u0IPHorkbP6XV_2NuNWSoIV
 6ka45H9o0WhXl1VK5BdjAGH09RI1D8Y1kCMt084w8rC81HCfT9KKVjbTTY1amG.SY36nB1YT9r0b
 8DNm3SVvLGbhB_gG2WkxqWxTzQ0gMiuJpajYj2LnkpNAqHlhGIHvIGeaPEPS1oYJya3KSv95.3cD
 YttLJTJotjo9DU8U3JDeVlQHFt9XiNwZHjjF0DKPFD2kSjZN5QLsbr02cDu8sLsMyskzbLwg8_py
 tx6geL8x.8a3hN8d98b9jIWLUyTf2TsS79ItwiNNr1UdMWcTNV4sc8CD_S4rW9rydhyNqyNiEQWk
 NBndDJFSDb_Q-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 18:01:35 +0000
Received: by hermes--production-ne1-6944b4579f-75kjj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a32550b9308427aa8f55391b11a8fa0a;
          Wed, 05 Oct 2022 18:01:33 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
Date: Wed, 5 Oct 2022 11:01:30 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MjMp959dCz40DM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CzIY03Br;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.16 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.66)[-0.663];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

FYI on a FreeBSD USB enumeration change in main [so: 14]:

From: Hans Petter Selasky 
Date: Wed, 05 Oct 2022 10:13:41 UTC=20
The branch main has been updated by hselasky:

URL: =
https://cgit.FreeBSD.org/src/commit/?id=3D55a3bd000d9799f431c207e359466484=
ac63c137

commit 55a3bd000d9799f431c207e359466484ac63c137
Author:     Hans Petter Selasky 
AuthorDate: 2022-06-09 13:15:49 +0000
Commit:     Hans Petter Selasky 
CommitDate: 2022-10-05 10:12:33 +0000

    usb(4): Make sure the enumeration thread doesn't loop too fast.
   =20
    MFC after:      1 week
    Sponsored by:   NVIDIA Networking
---
 sys/dev/usb/controller/usb_controller.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sys/dev/usb/controller/usb_controller.c =
b/sys/dev/usb/controller/usb_controller.c
index 0897af0492cb..959f54a4583f 100644
--- a/sys/dev/usb/controller/usb_controller.c
+++ b/sys/dev/usb/controller/usb_controller.c
@@ -414,6 +414,9 @@ usb_bus_explore(struct usb_proc_msg *pm)
 #if USB_HAVE_ROOT_MOUNT_HOLD
 	usb_root_mount_rel(bus);
 #endif
+
+	/* Nice the enumeration a bit, to avoid looping too fast. */
+	usb_pause_mtx(&bus->bus_mtx, USB_MS_TO_TICKS(16));
 }
=20

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Oct  6 02:38:23 2022
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 4MjbGP0PMzz4dhvX;
	Thu,  6 Oct 2022 02:38:21 +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 4MjbGN1GbVz3cpw;
	Thu,  6 Oct 2022 02:38:20 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2962cNRO016854
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 5 Oct 2022 19:38:24 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2962cNYO016853;
	Wed, 5 Oct 2022 19:38:23 -0700 (PDT)
	(envelope-from fbsd)
Date: Wed, 5 Oct 2022 19:38:23 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann , freebsd-arm@freebsd.org,
        freebsd-uboot@freebsd.org
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221006023823.GA16472@www.zefox.net>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@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: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
X-Rspamd-Queue-Id: 4MjbGN1GbVz3cpw
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.07 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.970];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[zefox.net];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 04, 2022 at 11:27:00PM -0700, Mark Millard wrote:
>
[big snip] 
> On a possible issue: You have
> 
> ugen1.6:  at usbus1
> 
> plugged in.
> 
[snip] 
> It might be worth experimenting with
> avoiding having more plugged in than:
> 
> Boot USB drive (I count your powered hub as part of this)
> Ethernet cable
> serial console connection
> fan
> power

The buildworld/kernel completed without issue and it seemed
to help. Immediately afterward the machine reached
S=shutdown, M=mountroot, F=disk detect fail, R=reset
 
SSMSSSSMSSSF
Next I set device tree only, per your instructions and it reached
RSFRFRFR so I tried ACPI only, reaching
FR so I put back DT+ACPI, with result
SMMRSSMSSSSSSSMFRS at which time I pulled out the FT232 usb-serial link.

That reached 
SSMSSSMSSMMMSSFFSFSSSFSSS

Looks to me like pulling the FT232 didn't help, DT+ACPI works better
than either alone.

35 shutdown -r
10 mountroot failures
9 disk detection failures

That's actually pretty good for the JMS577 enclosure. The world/kernel
upgrade to stable/13-5ec288b57: Wed Oct  5 16:55:43 PDT 2022 seems
to have been helpful (not sure why), omitting the FT232 didn't help
much, if at all. 

Compared to yesterday I'm tempted to call it progress.

One thing I forgot to mention:

The microSD formerly hosted a RasPiOS installation. I simply
cleaned out the DOS partition and installed the EDK2 files.
At one point during buildworld I ran gstat and saw reports
of zero activity for the microSD partitions. I didn't think
the kernel would even notice them. Is that to be expected?

Thanks for reading!

bob prohaska


From nobody Thu Oct  6 04:54:07 2022
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 4MjfHB6K1yz4dxhm
	for ; Thu,  6 Oct 2022 04:54:14 +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 4MjfH92fnMz3kQ3
	for ; Thu,  6 Oct 2022 04:54:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665032050; bh=DeCJhKQd0oAGRoP69VIMrPOaL2L55zwgBUPXg9Njuus=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=a30sqOTRsOu1FfVUEqJF5jTScIfjpi0i43AMgd9E4c8F0vfI7F9cTP+1f98H7V0q24qQ6U/m5QJCeb2vn90esHntbD/61MdqKBFAU3LX0VAhc/m3fITWhmofDavqHFMQgqG2Y4nr1FUll/qaI9Helt18xuJtr8V4cYpmlJNVD+ktqI7K+cEFPbTtgD0e9VlmbaveMz0c/dNB3rQ03Qp4VG1Z8j3Ztbv951M1Ck8qsHFdNnb8Aj2LPoLkCcdgB0tsJ11443bngBulHPkqSDm79Sa7WQXJ8aYWni7ujmY6EOqfjVVyBLqi+ycnRyfnSGez+s6BXs5wJ1CxJDAj/OrB4Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665032050; bh=giGiKNKATWjcWBHKusbmeaZVuQWtU09BDM/R5WF9qge=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tjdI6kjStE3OhQN2zGXrbhdBHJnSfcEEqan0rN015TbPtQOc4QXS7hc2eGGh56Gu5UHVSaYQuhQ6ux6jGp+OhaPBueyYnJuszFJKiRKTxKYqWBJJgPoFJ5HlT+qZfOUEUSEiILiu78/mU26On71HzGpWX+S4D7oYpCToJvYIj/sRUV7ouKrtKcc1p9ZZy49VqfHqmodmjbJ4LeEcWbxA1IwvqwyToecB88fp4p39VfvAFMLCN3Igs/yEGWq5rOBNoQdSU6kp0xqa2chCzU6gr+cqw7GPJI3qqh5VQvwP1QtHFdVuIkMYXClVmyVNij5HYASnpdlEDfMhI5zsm5Tq1Q==
X-YMail-OSG: 9QQdF5kVM1nG.ned.MKiLQLmsVAn1PU7GNtTYffkXIImqOgn6pPgMdY_E8d6gDY
 NdTp5ykcl87MtnM4kkBTXeVF.q3ZWPBwNuhylu20y05qop9Ws.jBgQxAFb4.ORjSl1K0ArBklWYA
 5W7w8dOT4J3gkrwFj1ypjNTTRI.Yf.exyhsWQ5SmQWeXTSDTkcZPTtatnnGnBamNWSppXPG7nsRe
 D6gDvCqK7G6X1kwg3nCzLWrEx4uES9VCsL9HIENnzF4k7DTbnd_wU_8VzSZQ4E.Yo4o81NW9J0W0
 7f_ZQwxGMPvsK6H6hbRoNuUP3.M8RP3KrUW1Cc1M1U_PxcJAK62qsdgcdvlu7gwFvWktALywgAJw
 d.4KGYkbZe8ixwFFs_wglKaxyzAOr2M0axsco_XiDA8iPNafcd0ef7r9OTNrRebbGO6sXx_AwkDh
 9nLF2UiFSUVqoMljLgqXb26IEE_KM4T8yWUvB12FigdwdsQ9bX03gYxr_ymuS39dHmJMb5A.JVpk
 dQ6Xt4fUd5O85NlYT9O7S3cHVcs.LENjVqAO9fdfeQ68fSCktQgrGCxHJmOGnm5m6nPCHktEdVOQ
 RR9zuxonZqLRVOYn6dgFow5Ciuu1KFQBjaymZN8GSIXcEgbK_AMbMRjmozkEWCb896hVJ86TkNCW
 yRzFUgsMDgL3Bu08vQdFGvnIMXukZ_SdLsJDImLrnxK.SGIAV3Viz1AQqhXnAduijTzUwSTCmJ5R
 8JVuiCIMIvDp2_X439HOLNT0Y3mbkMfO4hPxFdeGw_n9xYD5zdbTTv5DvFSAU6WJEQYqvNCLtwVX
 6L4ydmxXUodTuJKnhNIoOfdsj0eXhmRdOoqbECGuYVif6K6x0FuT2GV1Q2SO3gKDHcOmqAWR3YQO
 qwRoL7DH.Ki3_7KaEBLzpjOIpvnHuwgP.t37A9Dd.xV6QABjoPIG4j4NeHgioLepqAynzDercdcA
 phAq5nj6H_qI9pVrUEKZNgn1Sc21dtRgYOYAVmlavtjXD7b5HZ5JpyUchsBFyLWubflCuBnV1Nj1
 .ZpULFN1GhjbxFVlgs50Rm.vdj4rtSO63P5O_a8FQ9qywuh4o6Hlgg7eH4QhXZ_bSBJM_wGn48id
 2JcKf0xDNrFQI0.Gq2aSMx689j7h0SBpj9yJYWhPbKoa24laSy0ECIIOhGeDyiQfKVQ7RVPxEu1S
 RF_sFBTydKMdhT6YgMQkoht94FOi6CEssrPnhRIf2YuripSbrnPocrq5xm3kBIsGxXUROao24USm
 fHFY_Yq5RO_a7PkFg3zxg06grfGFXa9hLLQyxLeYlQFTMgargpU_TvmUTwI7la7BHGqGzYKwPdw6
 dYgHfodzyfSkN0POMBofFL_s4zop_hJpl54Y95rMps0YHtELl.mOTjJaWPdyFItL1_jiGVtbagcW
 Gkmu0amWGZVW8EvJEDxAAUbixY_nSYVjafYaZxzDxArOjSpdz3o0gia70Gyf9KFAKlJazoUxKHII
 sGzCkwfi0jlKNliBkaVx7F0di9WB1.2FOCCD50NLLHrYGmdx_IlBM3G5OR48POdWqzZ5.Kfu.D8X
 W8W_E4ZrBDHySvrvUkVHEbaSosPDZDhmXaZzOM6taggNRagapN7agnonIz5WOV8XOMPWr_P6l6GK
 AVEdOXAT.72B79lfy1p66_aW_g1Rtfo3LcKOg7ewJe8ZqwYrqKZR1CINnkLtaudPoA9iCneeEw2k
 5U_AvHjZOX2gKp_Yas2k_i72KXEDZAaoZ9Q5QG01v5Z4mNMFgYl1Fmap2Zdf.aUwo0dV09NQi8Nn
 dHDhVGNC6rq4ktyWY6RBfouMc7B5EmYBKyKjNlcjkQNFKx0mNVvJDqPr.dLWHlzj9YfpS.gQcM9S
 BRpta9pZm5EbWgktEDkkwHgoIHx63Z1U9pcPfwGiA4s.M7WkDOL2RyxwPtsFjnNjNq0auKsHW3.d
 H10wmsAFIR8aX3J4w4yEOUzhGeCH020DlaJOzYhv8qC8.sm70Pec7GVs4dgW1UUGNKlbMtiVECdb
 IJlp4XlNC74dbDgzIFAyuJl7aSY8OQFllKN42lGJdORVKxgniUGvgl79nz7Jm1rU4eoYwDD8i6Wc
 .2d2Du.B7em14kQqBu0l31gsa2N2O_L5jVAaqjmGHCS_b.uLEOWVoN2YiCWPgoaX5e4S6Ujqamv5
 nQYDrsTLLdHWspcAtqWKBHjtcVVfT2BPkYp2ouTv2OmprHZl2RZD4oW8jZX9iE3AISEGGkI0P_gs
 xfCGMP.RcgCcFsb63xpLLvJ0VfbZ2XjoH172lTdg6RSJKpp6_DikCc5E2ZpXzP5hJLzM0I8t5u31
 xs9cv
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Oct 2022 04:54:10 +0000
Received: by hermes--production-gq1-94b89944-h245p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d42fb247ff27dffd4c06a31d4e03b80f;
          Thu, 06 Oct 2022 04:54: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221006023823.GA16472@www.zefox.net>
Date: Wed, 5 Oct 2022 21:54:07 -0700
Cc: Klaus K??chemann ,
 freebsd-arm@freebsd.org,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <25C561B5-2690-43CF-9091-47B4DF9F1997@yahoo.com>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221006023823.GA16472@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MjfH92fnMz3kQ3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=a30sqOTR;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[4];
	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.68.32: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.68.32:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-5, at 19:38, bob prohaska  wrote:

> On Tue, Oct 04, 2022 at 11:27:00PM -0700, Mark Millard wrote:
>> 
> [big snip] 
>> On a possible issue: You have
>> 
>> ugen1.6:  at usbus1
>> 
>> plugged in.
>> 
> [snip] 
>> It might be worth experimenting with
>> avoiding having more plugged in than:
>> 
>> Boot USB drive (I count your powered hub as part of this)
>> Ethernet cable
>> serial console connection
>> fan
>> power
> 
> The buildworld/kernel completed without issue and it seemed
> to help. Immediately afterward the machine reached
> S=shutdown, M=mountroot, F=disk detect fail, R=reset
> 
> SSMSSSSMSSSF
> Next I set device tree only, per your instructions and it reached
> RSFRFRFR so I tried ACPI only, reaching
> FR so I put back DT+ACPI, with result
> SMMRSSMSSSSSSSMFRS at which time I pulled out the FT232 usb-serial link.
> 
> That reached 
> SSMSSSMSSMMMSSFFSFSSSFSSS
> 
> Looks to me like pulling the FT232 didn't help, DT+ACPI works better
> than either alone.
> 
> 35 shutdown -r
> 10 mountroot failures
> 9 disk detection failures

I did not get a total count match so I
worked it though. . .

ACPI+DT  (broken up for easier  counting):
SSMSS SSMSS SF                 (S: 9, M:2, F:1, R:0)
SMMRS SMSSS SSSSM FRS          (S:11, M:4, F:1, R:2)
SSMSS SMSSM MMSSF FSFSS SFSSS  (S:16, M:5, F:4, R:0)
So: 5*10+2+3 == 55

But: 35+10+9 == 54

Totaling:

S: 9+11+16 == 36
M: 2+ 4+ 5 == 11
F: 1+ 1+ 1 ==  6
R: 0+ 2+ 0 ==  2

36+11+6+2 == 30+10+(6+1+6+2) == 55

It looks like:

S:   shutdown -r
M:   mountroot failures
F+R: "disk detection failures"

(That last was not clear to me on its own.)

I'll note that I'd sent a note about a commit to main
that might change the FreeBSD kernel time-frame failures.
It shows a 1 week MFC for if things go well for it.

> That's actually pretty good for the JMS577 enclosure. The world/kernel
> upgrade to stable/13-5ec288b57: Wed Oct  5 16:55:43 PDT 2022 seems
> to have been helpful (not sure why), omitting the FT232 didn't help
> much, if at all. 
> 
> Compared to yesterday I'm tempted to call it progress.

There are two widely different stages getting
failures:

Pre-kernel (so: U-Boot or EDK2 --or even RPi* firmware)
Kernel

Thus, any overall solution still using the 0x0577
(if there is such) has fixes or work arounds in
multiple places/stages. Any that are just work
arounds that are not committed end up having to be
locally maintained to keep the 0x0577 "solved"
status.

The same sort of thing applies to incomplete
workarounds that just make the 0x0577 results
better but still sometimes failing.

There is still the question of if the 0x0577 is
well behaved (or much better behaved) on a RPi4B.
If it is, then enclosure swapping might be
relevant.

> One thing I forgot to mention:
> 
> The microSD formerly hosted a RasPiOS installation. I simply
> cleaned out the DOS partition and installed the EDK2 files.
> At one point during buildworld I ran gstat and saw reports
> of zero activity for the microSD partitions. I didn't think
> the kernel would even notice them. Is that to be expected?

gpart show shows all the partitions/slices. gstat
can fairly generally list what gpart shows --and
more. Device I/O to all partitions is possible,
even for partitions for which the contained file
system (if any) is not supported.

gstat with what options? The following are rather
different in what is listed:

# gstat -p  # (Physical/rank-1 providers, basically: devices)
# gstat     # (all providers, includes partition/slice naming based rows)
              (Note: GPT freebsd-zfs partitions do not show gpt/LABEL,
               at least if they are in use as boot partitions)
# gstat -pc # (Physical/rank-1 providers --and all the consumers)
# gstat -c  # (all providers and all consumers)

(Provider naming probably looks more familiar than
consumer naming.)

(The wording ignores screen-line-count limitations on
what can be displayed.)

===
Mark Millard
marklmi at yahoo.com


From nobody Thu Oct  6 06:45:38 2022
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 4Mjhlw1KB3z4f8W7
	for ; Thu,  6 Oct 2022 06:45:48 +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 4Mjhlv2R33z3sSj
	for ; Thu,  6 Oct 2022 06:45:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665038745; bh=QM5nvaX08cPETttBVVPNUplf1EFHM1iG+dLpyy+MKyY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Xky7OyaGZ/wR02849TZsPfniHy+t+surCqwKI+7jBdFY7kAXty49hJ5fz2OQ/6G2mFM8engNlTDqbC7mfwygQfhWTWC80vpJaR3uRoKFe5k+2lm+6WCsirPNz+7jEB3ymFdz88b1U3AP7/jE29URsU7zN4wf0e2V1tdA+Q97OXBqc2cvv0+eTS4SFNmMDrYqlPflKhCkgqrVQPKepA3P0rmeCDXPkITiMnaO8U+DKkL/ZMpRiFgZp6C2B2B6gd2FgS/A9koW+GenITD0bj5SICyQSTOEeSDGtrfnAdK/RyUM8cA7E0ii8WQwjFHGrv2ehQ2YVsNztAl2pNbZzi37mg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665038745; bh=qGwFnP/4R25aJ1xtog/zO5QxSqdVfDqXeMqvWjdAT2L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fR07pIHBC1f4olmf5UcqfeZaFMWKDWTlKHhlJuC9BwBTGJ9IT3EMGIQ6Av8LY+1CDdu+adG+PL8j4LlYNRtHkuhk5ySbDxcUmJISgMGgp0lMrHKAZRA5Uwx04mxGUrf1OHERg1Mo5QpkMYMkP5IcaRv8pxZGImNzpQwPwS2TG8Iw7Lbum1Q0zb2DLeXImwpVAiO8MJi2P1EapSw8dBlGJAQ8oBRHEhId9qLQCSuSTAuXZ7PVX90PF/KIAazkdB3nn6dEQpyBklkhoeOZMByYstKjo/dxhLjifTTde6wM4L3607hwa48W6d4rMCBu7l+AkYGW0SsI8NFO7Unwnmnt9g==
X-YMail-OSG: KY6UmlIVM1nPjffNY9mVi7.6fZipJui7FeeinBJ5Kymiy7.HupSltu8rJruKaTY
 iA2vLp5pVcJ6RK3PM1cEOIbKVbPac0m6VhR7qJVdpeUC8yT42GU2nAoDZcB_6jLGHlbGVNPo9HUG
 0OZCW0W4vmU6oXSSCjnGjLDnyT6NtUJpl5HfvDhq55P.GFYywYJtos1USRRVRDE8CNiTFfx9y3wc
 nqlLC54LCMnrGiu2JtAhdSUzeWymDRepki9S3INbv5q.4RtCrZlDVUiebqf43WuddzX9iMy0PTM3
 RW_82ERp0uu.ua035GZ4Kjo0_RXMxj6c1CgS8t_WkPIsETzmn1IZcLfYQQ8A_84fbVA2.QArnOZP
 KSIpxAOtAJmAtY71GtribPi8aq3kXx0_.vgt1UwVwjUjnzbYQSO3Bbwtv2tj5F5v44FVv14hoyLO
 mgzEpOU5VXceVMhZbHq_d2fmbGoH629o8.OPrWWVARX.Yg12EJZC7Yzj0OUXebcEVCi3ivHTzfLu
 501OywvhVDHevL86S4nlwiMta4Qag9e0Ae4KjOgwJPB.u5z4UoiTkN_Bjng0GS1CxcWEPzFhmmH5
 pU3vUUDu_0o7HaPXwv1ysGBscJysX3dIyxJ8KFeOElfqYEv92XCLk0eNzfiYRGzuPAuFFjfGvaKa
 ugkMrqrgVMgHhzGkwTLaCysuAfel0VgJcgSIAv.PmXlh7BAkBikCPyNMgoO3Q3vKyjZSEC6J5eWr
 f0fvDdK7sSkxT38vAKKb7o8iuSN..nZr40ed8sxPbETMFcLy5SgKwiBhqFdLl1m7huOcUtq5CLc.
 cU3G0coCQ688hkUbWLSsiYxubIyGgQ6UHfAYYdw_lp4qe3.6n7q0wxY9EcaZwmVjC_yBe4szPNVX
 hos3YPmyjRcdULqeTC.xKKPYWe4lnxsIHFHYAn2QjAAlgTJY5mTE7Ptz9T6wKkqQHl.F30HFLgVM
 YHu8TgAy_abaUEJk7gIXLKEL6nYtxnWaQSfL3TwDJgbVRMFrCwoSUL0rwLbPbZESzJlWHwMov_va
 GzBuFpjTRk_t3_9NRZe1L2uCNqw19DG8vp2ZxJtG2xhrYybBGqSnjcMjofFx1hu1S371XNO4yizr
 EV6bJiVia3gFWD2xOHgtltMK9_Vw9ISq4xCmgchXI6yku_hyU6_suV7t5V_a2kB9rC8AUD1lDOm8
 EoUNCxY2kV.hSyfgG88ZMbMgJ8ObyvdrVYbyiG9CS0NsMCYC6AlHkNVMJU3pD_6ktOy5zwBZwe8Q
 K_1GvoueRGAM.YbOb3qAYxWJfYxcfQyGJQCFBumKJ_DupaHepAsL1L8Tz_.ZzPgKk6fgVO2SsMnM
 wUa1K8EkeFRMyrWUk4sElFSVuzyZmx54lh98ShyMa9NYw9FgloMz5vZi7fqG5Da0ieOVdhJ0rmjy
 y7gkc_2oZ4apWLTY_7vRO0rE643rVXIwhlhEh0Y5PU4u6BahKsn12f6liW_C6fXVdH_QA3ZiXNQA
 Ct73L613LcS0z7beOv.6kfrcS0HQAPyCi1DbP92UChPhSr_zlk3sGDlVAYLpsjQu.PorCSlubK5F
 aWXBMKQ9pY3HMIL5sxHSqGBU5GTCqGlS00vvnpJrcjzvsQrIeDv3GeP0PuyOLQLlr7BCf0m5lPr7
 mlh7GA5ZaSg5yyRC6TDRg5PGWxkDBi92nzJvMG9n0q36sBtgxEXPNsWdyKHP7i11toKYQV2vkwY6
 RKCVXcj79CNxt3SFrDdiJIGZsuZHwBhiBgxx76f8dpIA392.TYUwOXY42WRPY5OGNzUQ5YVmm6Ta
 R4P3mnOoZOzCaZfpMTH4X6NDSxWX0Mgz8MZo5v1sDdWi1bffoLTj5YcgPgKim2dBdQTWHUk.rp0X
 mTW4s7BiE0Yx4aIfwIkMFtVgSTG4GbiHmtxZLWq.oAEbmYUEy.vRcVUn0Oqq07cUmMTRxIYb0KAl
 6aPN0KpNft_XpBCyPicybUq609IW4yhOVdo32IrtKlk8J2dcKfKlfs0m_gvpcYT31DOt423M.Sls
 WWuyLY.SS7BEFvCBAVU5pos_QhWltpZfv._u0bv.LlvlEwLOmCA4GsTnFMbxXQ9casBrxGMKFo78
 HmCMdX4YwTV2mX4ICFCUu2zp7hwV2K7gfsvIe.sEBC1CbCBTxzq9OSbmGrCtKhKiw0VdR_dlCiuI
 5TbFWAVFt1.N4PBe9dBMC1_sdd8JNx3.gJD5JMjPCzzgo3O0jrLtBSzMoOhTCO8MWzL5DY6HyzWH
 VTTE9.pRcEtOiIYQn.JvjEJAr6je9fO9rEMz3R_BZFIF2GwK2IXzlHgOk_mS1I7Cku2NaEiDGv0Z
 u5A--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Oct 2022 06:45:45 +0000
Received: by hermes--production-bf1-5fb9f4c8b8-jf7ft (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c07816dc88f05e156dd973b711d8bdbc;
          Thu, 06 Oct 2022 06:45:40 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
Date: Wed, 5 Oct 2022 23:45:38 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mjhlv2R33z3sSj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Xky7OyaG;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.44 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.939];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

I found evidence of a ACPI+DeviceTree  vs. just DeviceTree
difference via the boot -v output: note the #Pages of the
BootServicesData and the prior ConventionalMemory area.

ACPI+DeviceTree:

---<>---
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 =
compliance
                   Type     Physical      Virtual   #Pages Attr
. . .
      ACPIReclaimMemory 000033b20000 000000000000 00000010 WC WT WB=20
     ConventionalMemory 000033b30000 000000000000 00001213 WC WT WB=20
       BootServicesData 000034d43000 000000000000 00001ce1 WC WT WB=20
     ConventionalMemory 000036a24000 000000000000 000001d2 WC WT WB=20

Just DeviceTree:

---<>---
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 =
compliance
                   Type     Physical      Virtual   #Pages Attr
. . .
      ACPIReclaimMemory 000033b20000 000000000000 00000010 WC WT WB=20
     ConventionalMemory 000033b30000 000000000000 000011d0 WC WT WB=20
       BootServicesData 000034d00000 000000000000 00001d24 WC WT WB=20
     ConventionalMemory 000036a24000 000000000000 000001d2 WC WT WB=20

After that 6 lines were different for kernel output to the login
prompt:

A) The temperature line's reported figures varied a little.

B) Just DeviceTree got a:

(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
(probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain

sequence; ACPI+DeviceTree did not.

C) The /dev/gpt/CA72USBufs clean/free/frags line's figures were
   somewhat different.

D) The time line's figures (after the "Starting background file system
   checks in 60 seconds." line) was somewhat different.

That is it for boot -v output differences (non-debug build).

I've switched the RPi3 EDk2 microsd card to use ACPI+DeviceTree.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Oct  6 12:28:39 2022
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 4MjrMw00qXz4V5Tc
	for ; Thu,  6 Oct 2022 12:28:59 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4MjrMv6DKQz48Bl
	for ; Thu,  6 Oct 2022 12:28:59 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1665059339;
	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=3++92PnKuCkkAyKcumBQo0M0fagnf8miJJU96jbQ578=;
	b=h3IIy2OqeVYc2WOyabrncgW/Papl1lJpB7W9A4HeQBbz2q+76JT/fB1OWDT2VOapYRQ3I2
	2whPPFKTubKdxOdgWgrZuYMyzRhiFIaBYmx0vVdibhcLx0S2jmw9iqrRxaKdjkoCzp9ZxL
	VUYbaj5kLRtpzU40ZiD5pZcQouSC1GQVe/qmxMrd9+LANAtEwntAsS5z2m7IziuZ0rHtx1
	AjzlfLbUGCXATjuYYo/0rC9c7RvSFA9v47lqlQpOZKW3Nv4whubw50JNuxkUlRCjS5rMFe
	Ekk7B0a1XK4Etww4UGiEhYCIHc2i0bSvNYJ2MS1xkO56/TlWVXQuDllPaZHxeg==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MjrMv3jz2zXq1
	for ; Thu,  6 Oct 2022 12:28:59 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: <0a1ad5e6-794e-264d-b6fc-d4489049dbff@FreeBSD.org>
Date: Thu, 6 Oct 2022 14:28:39 +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:91.0) Gecko/20100101
 Thunderbird/91.13.0
To: freebsd-arm@FreeBSD.org
Content-Language: en-US
From: Jesper Schmitz Mouridsen 
Subject: Pinebook Pro does not have bt656-supply in dts.
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1665059339;
	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=3++92PnKuCkkAyKcumBQo0M0fagnf8miJJU96jbQ578=;
	b=EtcQLJ37kqjP/zMxUoakPAl1JsaJz6n+aojb3X6nQltHnnDkf6SjocAW0y35xXVd4dJnuG
	q1OoWKgoyvRKLimhhhqjebwhbGtSoj54jdDOVX+WZZqygG85oXe3sUf4hB3CHhIv/9szNM
	kpfm8erWIzGwK5Mb8yY6QogbbbszMUtABfoY6fQ1DRyLkcS3+f9ov7slD7RLLz6wwgZGSS
	TlLZPEcSA4gedM7/1eJnl7ZlAK62rlUNRpFbENjWlpZmCj6I4ur8prA+0IU17lmqlP8hrO
	ppHD6+RzeHgfXKBkJPjgqLr/2d3Ovco6vfBWvHwRHwvhY5wc7qUIGpsXw5RWHA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665059339; a=rsa-sha256; cv=none;
	b=c84UOaurCqfsQ+eInA81LBI/ngi/CDe4Ep6SpVfm0v+WPXl8ppnSbVCnC5ar8F3LpU6Hfc
	wwpPmmvPD6FwzTv4QzdcxJRLV4Lw4LuBtQEmguSPZMy8+J9epee9WL/svp0rk/D3uyu5Rt
	zoT5IommA8a5Xd8r1e0Pc3M1FEM0q4f6EaVKaHukkv4iEPHykcHyX26xf5Uidwda3+bqu6
	3HhxAvH7mb9+5IkmFRa0mvOtxewElTVSjntEiBdEvVRnQNe1+YpVR4xmTBtmte29r83xco
	WJd/5aHx0C0Qy5BeO+xNQzip+KmEJognsD2ntGOfe2D0Pgtn/wtprL1sJvJvEA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

So rk_iodomain fails with error 6 on the pinebook pro.


grep -lir bt656-supply /usr/src/sys/contrib/device-tree/src/arm64/rockchip/
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-khadas-edge.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-leez-p710.dts
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock960.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-puma.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-rockpro64.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-nanopi4.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock-pi-4.dts
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-firefly.dts
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-sapphire.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-orangepi.dts
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-gru-scarlet.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399pro-vmarc-som.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-hugsun-x99.dts
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-roc-pc.dtsi
/usr/src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-gru.dtsi.

Regards

/Jesper

From nobody Fri Oct  7 01:32:18 2022
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 4Mk9lt4pdJz4f00M
	for ; Fri,  7 Oct 2022 01:32:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mk9ls6FyNz476d
	for ; Fri,  7 Oct 2022 01:32:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665106343; bh=2eEjqISfC0ISwbaNlWEF++6HXH/9DrPQ60kjKQC44/8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=od8ApORlkh8IOYoA3+ZAF1kT2xXfXvl11m8fsouxgmtCcdPp5yOyVC+6fsEQ11qFNUxISIMScYKOOnNywxdd7jbhnStMAwH4JQxZ3OpLhd0ER6wAd4h0msEzX73Rt43gdeJib2CMKlqq9w5wL3H0dGXm7bdJPR11Ab/hk3UGEdc5hdyQ0emPxENV9fTfT5p0h1rztsxqFK08AwWNR4uR0y0X1WwjVEEFrCMcsBRUvwZC2lqkeRiIReMlTdJWs7QV8tyZH74+k90ezowI86hOUAK+DxiQ6tvVpTRAorW1hBYyK0+5JoZs8s9kTz1PBm1wq9XkPC/BIzQtNnJ3ZytY8w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665106343; bh=l/m77u5LeV/kifLG43Mh9DVEljjN5bnGVj8Nr8kmzTt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jLSfy8kbEEF9SYEUlrEGQmg8BQlBPd1vDvbAxIs02Zn1o3jdrCjhAiuWTla/V8u7ZsM3VGXd0mPToRZ7/dP6cDUfmKFgcpbzFVCJbLtrAMfsn8f3nvFaQF1pDLBeD8sX1ndktlOSVDsp9O+nthzCOkigLVkTiqVTHg2njmKvhFLa8aSFrsiJrDhxi2IJQzJTL4fqEpV4reRiGnups6+Myc30Wa6gM41vVYDTk8CLYSdo5PcW2zCPZoQhSyiVHh8e+QEiTF2VZg2Btx+aY/RMGRubtEFbSMlQn7VOgw0PNiIRrXajrb2kuU8zGwbKZ2cViebvmWNU0BEYf4nXlkvYBg==
X-YMail-OSG: ju6ja5MVM1mbDu7te17VUKt14wV7SljIuhZ4.izrlzeeWYueHWVaWZ_57MD6SvI
 TzrS_4lszU94sX9CFChC.EJeEytYgz6HwhEylnnUXClyG4sMUUG9hqBjThANqFfdUr4S96gQM9sC
 elO7OGR2E_0zD1KTXH7rGo_O0w_rH.63L4gVmr6RZvUMeKbaEGxwZRHRGxXmcw2qYLhCN3TFISwC
 rP8z55CliGmk7OxE61H4ZDEWKhqXTuTuQYkRoXEmP0iaOqao8uq0LKgN4Gi.5WmHEEHx03p6G.DZ
 QK1IJkUb3j3e0O7hQfWoRQxyHjYh4vC6CcSJTCi95PpPY7TTI3reoGwnrc3TvO6UMrxD79baSShr
 JZuoIsoa.4SmAzii4IduZANkN8AodshDDftIN595yLhpY2XEoNsxsWrGHAVOd8phIx7t5yw_qGmQ
 0GBJiM9Faz64yd_YUd1aEzTzRfFUvfUepTn9dGhuEG0v3tnv8Qo0og3WBm13Nbu3hTwvws0IXojQ
 S3JI7VuRlgDeo8Cd0ZAS8yD3PzViKP8D_SsOLmOKkT3K.m5IZ.euAXsUkZwbIWvqCRXWhfs0Jrgv
 1HtQW7rfeN9NkEsqVYV7X09luGF2TISaa7oO_hAC.ia0VY6B44_ZURZHvPs_Ut9mBO5lAfO.XVRJ
 fSeBsTD5L408H5P3p0GzrAlQ8YRa2ZeDvK_BpoyEHcDuQ6uhQKnG4DXzrx7WOee6hIaINzRyajvc
 J2.FAl1opmYsFrORWJTIxdHS75O3tdbIFQ58m1STNkJsE3_uZpe4PojcwtsgXtYgfW_198gCS4TG
 tPiEcTFijVPR7jpzHfnLdeRqgApdIArpLZ6owOiSuN20qH1omhyclIGhzue3NznSvBZA5g0d4GTp
 FMZn2RJgnU344.QFs.h3_dHzwufXBdhj_Y.QfNR8OEcRERKCILO.9Gv4GxO9_OXdp9MtCX0Ycqeg
 qFqRZXUNBMIIBRlfEZEylkeEPk.xrxzyYK1X6slq9dyJY7PAXDnLIxeEk7aNBcOoqeIVVEz.kFFw
 xJId9iRXcLocAKPsVJpcJhxDWz7t6nq7SbDLY2HnL0DckEDxdAlqOj740r3tngZ33_2YEbjbkm6L
 gxRv8gZ0TQhU824s4CfX_3zHmeoXSwa68J7jxW2hAf8_cT50TUxwDgU1hIUqJn5x2_8FfFD5AREL
 sk0tRB_NhlOdFszmfxDMj9ADpDRTnpC3Cknk6iUtWAgyuocsN3_ZZe.IIzqBswWG6amhN3a8wm.O
 e4o.vafgzHkW.O7cGhFSyChPZCihwsT..9n77qNl81eoE5cCFch.rbsDHMOxwoLvqC7Ocgxbo1hk
 tVcdsdaBh7g55kg7xGdQA2Her9sYUsVgkyocU_3rU91kLwZIoUyBz15FSoB_tIwKdg50KJAuDG1S
 95A995RlRn0Ouc9t.qcqvoL8xeJ35zwkc7LZiNdIKB7c6VWDX4xMXPsPfBsIjP47M8chNKTTvJaJ
 2xap8DZ2uZ9w04aFU4TlUTz_2xO.2lCFzNXH1.jSBKY1uitcfmJmzj4ElNdL6IORFccoso.pebbi
 hKq2jbBBQ_wa5Hs4Zhd47KUGehVCyYpRW5bx6d3Zd7Cyw_N5H38O2Shu9KwS3Ecsr1usmfDsN5NN
 q6MNT_FCLnumq9PZYvZvfCIZZkD3UjXqRTJaBj8BxI8sQ_Oaq8fhqrPBqaOZogpz.MVi19CWmszS
 Kum67qMtOFFJjvehqrWZNmi.4PrYPpqgwEA0qjNYPLABlj23QOsTvS2hUJG5D10DWpWFwNaZyKty
 YKWVncbnoZPy9EPhCIqdWKh.jsLeEAqRKcm7kEN3QdxjHMBKQC9pPvQhob4N5VyZ9ccLvkzBwHTy
 6dWfv4UWFX.vB6ETWKZcmhSmURI5Ffliok3o_1kmT622uXBvFB5Mt1zhYQQo5WHyp79MrZLVShfu
 O1Jhv9kk69nF56w8Ah1CSvO7RNakM_Val_WQJHVUKNvxihzu7Ah88pNYUSzq2tgnnEVx30w3DF4b
 wnn3vrn_.fdsKzN0kyuy9y7qj96.uqPSm5lPPLMU9KODshRbd5KhEB8IGPunBbQN_jx_5xOnqgTW
 SE858U4SyIO.lsfrXc64pBYzkMWiys4DpOIlxglbZ_Fy_ibfBhY_yeL6EVroGheoWBH5H4mfHlrK
 PpkLNz114N0tuRLRhuQTTXDHwQMxp0qMy1y4VcXqwnLpmO4BgXojgpME0hmNeYb22SSgqgTrR0Mn
 UuUIkk7a_zDwOvKgGgZ8uZXOJUmiXswM9sw7F1jfusrrjMwGberfPxKyIy2ISQUnv7k05TVrPkh9
 xm6MG24R34xj_YBGeUgAPLdn7K1ZhYssRUJuk_FpwDldASHHbiEafCniTWnEaABHhWzxjx2dq
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Oct 2022 01:32:23 +0000
Received: by hermes--production-gq1-94b89944-spdhm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e22d21516e153bab228785e317896721;
          Fri, 07 Oct 2022 01:32: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221004192707.GA11488@www.zefox.net>
Date: Thu, 6 Oct 2022 18:32:18 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: 7bit
Message-Id: <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
References: <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com>
 <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com>
 <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mk9ls6FyNz476d
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=od8ApORl;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.17 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.67)[-0.671];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-4, at 12:27, bob prohaska  wrote:

> On Mon, Oct 03, 2022 at 06:24:07PM -0700, Mark Millard wrote:
>> 
>> 0x0583 vs. 0x0576 leaves open the possibility of a bad
>> firmware revision in the part?
>> 
> There were hints of a firmware update from Sabrent long ago.
> It found nothing to update. Yesterday I looked again and 
> found a new date on the Downloads link but the same revision 
> number on the download. It is, however, named 
> "JMS583_FWUpdate_Utility..." which hints at some connection.  

When I go to the page for sabrent's firmware updater for the EC-UASP
and such:

https://downloads.sabrent.com/product/jmicron-enclosures-fw-update-tool/

the page title is: Jmicron Enclosures FW Update Tool
the file  name is: Jmicron FW Update Tool.zip
(downloads might end up wiht %20 where the spaces are)
and
the page reports: Last Updated May 18, 2022

Have you tried this updater?

===
Mark Millard
marklmi at yahoo.com


From nobody Fri Oct  7 02:21:21 2022
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 4MkBrN3pBMz4f3vC;
	Fri,  7 Oct 2022 02:21:24 +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 4MkBrM2kZNz4FLD;
	Fri,  7 Oct 2022 02:21:23 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2972LMFc022556
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 6 Oct 2022 19:21:22 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2972LMxS022555;
	Thu, 6 Oct 2022 19:21:22 -0700 (PDT)
	(envelope-from fbsd)
Date: Thu, 6 Oct 2022 19:21:21 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-uboot@freebsd.org, freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221007022121.GA22533@www.zefox.net>
References: <20221002182049.GA2255@www.zefox.net>
 <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@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: <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
X-Rspamd-Queue-Id: 4MkBrM2kZNz4FLD
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-uboot@freebsd.org,freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Oct 06, 2022 at 06:32:18PM -0700, Mark Millard wrote:
> 
> When I go to the page for sabrent's firmware updater for the EC-UASP
> and such:
> 
> https://downloads.sabrent.com/product/jmicron-enclosures-fw-update-tool/
> 
> the page title is: Jmicron Enclosures FW Update Tool
> the file  name is: Jmicron FW Update Tool.zip
> (downloads might end up wiht %20 where the spaces are)
> and
> the page reports: Last Updated May 18, 2022
> 
> Have you tried this updater?

Yes. This is the updater that didn't recognize 0x0583 and 
recognized 0x0577 as up to date. 

Next experiments will be to try a 0x0577 enclosure with 
Pi3 and Pi4 running -current with HPS's patch. Probably
tomorrow. 

Thanks for writing!

bob prohaska



From nobody Sun Oct  9 04:09:03 2022
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 4MlT7t11hpz4df2C;
	Sun,  9 Oct 2022 04:09:14 +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 4MlT7r64kNz41yJ;
	Sun,  9 Oct 2022 04:09:12 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 299494FQ001928
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 8 Oct 2022 21:09:04 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 299494K2001927;
	Sat, 8 Oct 2022 21:09:04 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 8 Oct 2022 21:09:03 -0700
From: bob prohaska 
To: bob prohaska 
Cc: freebsd-uboot@freebsd.org, freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221009040903.GA1584@www.zefox.net>
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net>
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: <20221007022121.GA22533@www.zefox.net>
X-Rspamd-Queue-Id: 4MlT7r64kNz41yJ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-uboot@freebsd.org,freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote:
> 
> Next experiments will be to try a 0x0577 enclosure with 
> Pi3 and Pi4 running -current with HPS's patch. Probably
> tomorrow. 
> 

So far it appears that the 0x0577 enclosures work without
trouble on Pi4 under both FreeBSD-current and RasPiOS. No
microSD, they just boot.

The two Pi3's in hand seem to behave very differently using
u-boot vs EDK2. The Pi3 running 13-stable worked better with
EDK2, the machine just updated to capture HPS's patch  fails
detection with EDK2, silently stopping after the ESC/boot/setup
option expires. Likely my fault, but haven't found it yet.

It does appear that the two Pi3's are somewhat different. They were
bought some time apart, but these are the two which shared a MAC 
address. Perhaps there are other anomalies. This is in addition
to the variety of usb-serial bridge used, JMS 561, 576 (583) or
578. 

Thanks for reading,

bob prohaska


 

> 

From nobody Sun Oct  9 06:05:56 2022
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 4MlWkh0WWFz4drq5
	for ; Sun,  9 Oct 2022 06:06:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4MlWkg1N38z46Yn
	for ; Sun,  9 Oct 2022 06:06:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665295561; bh=LFTtMxdIsEQ7yEP+J6oX3uBRc0EMCGPnWd2s0O4myaU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JU1kwDHOh9jYrzZyhINDApxABvYKcmAzt45ueM/qWPQKnH1gS783e4uqkAXpT/5AEeoGGNxrmYIxorfRPP9+zod1rWHjNRD5t6GUXeMpHzKgIO7JD1KqXuFfCMwW/i/9gkJlGqMKJdw6kC34q4IPdSL4WR1eeWY1ARORYxXiZ8jG744AI7+L9HNF5bPyo8GFKbUXHwaxB6oE6d5WdXcTqT/BSggmlEWys6fxVQsJdlm1pmW11ZePojB6vvrjAB++fF90cWwd09FPu/GwMn1zFPvhgtBFAs1mr0XKHSgOJpLdzSrk/EIcaXBwNhj8cEZZ0RMFh6StnWCUe/KZ38+Phw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665295561; bh=uwuibuLeZjQaJpMk0XwPwZMJOg1cWR9E1QRG9kJUV9w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TqmWqlPhoVZakSEfBdPa8Rz/u88zlpGNeqXOab1EfEBGzfUnM5fodHvhJITSWDmsodVnl0YyNOz/73GXH/H/5vr4jrzzl59aTE9L4i1bIyPtLmZzwLWdu0Fxr2o/9Li26LcKjcMBwBYF+Tbtxylh+exgs0cBS5fic8ufO0JF2IZFHXV8egILo6BxW9YsTzXBpbyUsTuIb5oXr5Or+lMKTh+rKflj4y3R9dYsMcI6cqHvHVPEW/n4Co3lOf9dz7OI0Onj3oXwvT/6eb5Ew3uCqklUdN1K9NumV4mOETIr9ZvnwqkBBy/HMPWHFjtm8UvcdKeExypyBMvZaGeJ/bclog==
X-YMail-OSG: yPGJ5tMVM1mpkH7RrcykzpQUVZsbKxz0tL6crAzQ2u1NnBVeN1OcJQWyEbqvK3p
 rI1km9EKMpdWNhzDn82CFpj3t3uQGrA84b_e4kaUdK.0PKfX4hJhFdOPGsA67QvRJnnpsv03u2ig
 AM95XFCXgZPnWfYIqHdYY2xYV7rNHq0Kkp5ph45ysZrrQJ34ehqPLMm.trBK0SckoFIZhFht7qL5
 XpcY6YG_Pdc5tGd5Z1vE9Vf4Y1lljUSOUCfim4F3bVlLcyL8_C7yPFkF_rQGUgRDDbfviUOizdDC
 iIvESiEnQNL7gHJbvQ9HLg1yc13YVmPXMckkhzbqdL_JoMIFyKRpdTWlFP.HFanG_0H7DUeF_ViS
 nj.NtrGEysYAq1h9Wdul7SHL9fP3tX87ZqjCj5A3oDVNKElv7kzADuZ_3AcMY6I_jVCUFD3xPZZA
 DdjOlWFjP0C9UG9L7nR4fn4Q4u0nMKJ28Vj9PbVuo5K8zyYoj0QLWXHZQ_fXeSl4yhFuXOE1hn1t
 DkO8Mf6uZyk9rKXCEFqPmGaTfXzGUhJbz458efshixDhUezQ_RaXc_M_Sh8hTkddHCLsgCgGJdLz
 0s37p4G.Hmza_Co8aguSPuUGH24obSuD0OANTkhRA8uOi1.TICXcKDk2ptsWS58gTV4mWWXftBfr
 z4SfZXeq5iA8WNfMIw6r0XstxNBx2hfzaol9WKZJiKpkXooOuFGgvKvsIiIYCliVtHln5G3g0w.z
 aHTHj2_jVPOKY91u3V2H_L.uoUuGSwPYgsZEiKA688S9QcatYba_g.lNOtUiE1L7jEIpuduaP6HI
 l.O7K_zkzoPv.m7GCwYfbIMmNxi80hNlUHNsGJ0sMMUKcKiim_9pY6.ekcHRCY0oq0A9MzlN16cH
 tUKf2c9L4gsqdC4AIwAFIALHssXqYyCOAR.nCm6Xk.E.mKe6mcY6tUggWil3vNbaKpBC2FmKBOMm
 7jkU7rYLPP134Cc4xrW4sdqkjkn3HKOtq2olZgnuR93gj7d1yTd7L6JYCGlwWi729wKS7r_rjYiv
 xSMGtfjQzvCPttjo2HWry2cDljCriq0enBYb46AeKt3PUROnYG6Dvi7itkPW.bkUNGNTm_smPKV8
 xrOF_rhG._v7XwO_ctbx3gM1qPSOMo5qdA3NPHhWDviFOV.sesn4.WJXgj.UHTHmmVHmXo8j7JkY
 9h3viZIfS89LR4HUiYOUcT2BnC3xCUI9c2wXP0bxSQ0xqxNK4y7Lqfh8WD55C_NMIMiTdhH4cSdm
 Yulb0UOq_P8JrBDLG.OIe0owq183VWHGFOs47R09bwn5NWbyjnBk8eYeKnpnXRqEgIs8oTXRn_fZ
 96lv_gM2kWV45z2lDzcSMPAaGAHi9n4lSYzuTls55WjlxK1dU5rltTwNwbS.lEQTrJJiRNNVLkdO
 cWkYkA.GUhTxETNPt5Nl.gfVZHTM.GH61GcW4grvpkRzB.RdjJDy9_mJoK.YzywrL.wUuLRD3vO6
 4RGA5YyHyyYiKGZrAt8TQdx13O6OF3IAmdGBk952cGLf6G_QOQQed_a2i63fempeBACdmYzEYQoX
 Z6HWAd2NQDPswoFB9eosRan22NkfBioNf4OhsF8lpC_Q6HTbGUFDHC0TNVZpYUDhLHUcu23f.UH5
 MW72zwwIa5LRyKwmL5ezhu4U221_jPcnAFc7l8NeCWfWdGh7OI5rkwBQreaxDvLONehlzUQLbSx3
 EJpBufXcmDUG2vo8J4SLj2u.hoT6zBUR_NhuhsAEwF71gEBM0IdP8a2DKSGMtC6yPM.WkVa1z7iG
 4Z3aXlmpetg80sO0oK34J7ANUXaLGHNdSSeJfiTyBp8kR7qxolR0SdTRLYYsKl0nd1fkd71GlZDs
 IDdlr1Cl8s5.vjYUbeG2tlw2uhajcDmnV.UfFdO6LqPBTJpIsSdYCZLl0C1zeLItinUxrRS7dIOR
 rKFc5_8kz93u0DX8r4JKW0rOxOT9odb12IxKny9_fsgWEP2qddo7NH2EY5IHDCw3ryMa2R5qNg2A
 wESupXkvbnhIQWf7xuTXaLH_JjOvY.D7Zyj66dGSNdAHBI7VMmRsg9GTuB3BWS4sLdryMg0vlzhP
 MNdPPjMPqOgoDmtizAqsF3TBypkgPnn6vc8MRPHuvP.yDbYoi8Q8oyQzQ89JbiJZAxw6f3FeAmgG
 g8LP_oe1135F2oEwxnYybHeHa4GyNPC7boei2t_6GIM72WbPztFlPUYGzQrGh8Gg47.hGQC__SZt
 PktfhhJevj.7.ihdEsJoIcn8FwGFLTA0T46UkFxMLY4ncHsfIlqerYma7TZkOtE8vAkb_6Md3diu
 _Og--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 9 Oct 2022 06:06:01 +0000
Received: by hermes--production-gq1-6ff8b45654-2vpd5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4620bc4a2d6a541996665b91d4111ab7;
          Sun, 09 Oct 2022 06:05:57 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221009040903.GA1584@www.zefox.net>
Date: Sat, 8 Oct 2022 23:05:56 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com>
 <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com>
 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MlWkg1N38z46Yn
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=JU1kwDHO;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.975];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-8, at 21:09, bob prohaska  wrote:

> On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote:
>> 
>> Next experiments will be to try a 0x0577 enclosure with 
>> Pi3 and Pi4 running -current with HPS's patch. Probably
>> tomorrow. 
>> 
> 
> So far it appears that the 0x0577 enclosures

So more than one of these 0x152d:0x0577 ? Do they all behave
similarly for the booting issues?

> work without
> trouble on Pi4 under both FreeBSD-current and RasPiOS. No
> microSD, they just boot.

That is with HPS's patch for FreeBSD's main, if I read this
correctly. In some respects some of the below is presuming
the context of the MFC to 13.1-STABLE and that the patch
would continue to work the same in that context.

As I remember you indicated that the 0x152d:0x0583 was being
well behaved with RPi3 EDK2, covering one RPi3B.

So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or
EDK2 or both)? Does that get you to each RPi3B having a
good context if you use a 0x152d:0x0577 on a RPi4B?

> The two Pi3's in hand seem to behave very differently using
> u-boot vs EDK2. The Pi3 running 13-stable worked better with
> EDK2, the machine just updated to capture HPS's patch

So this RPi3B is main [so: 14] now?

>  fails
> detection with EDK2, silently stopping after the ESC/boot/setup
> option expires.

The EDK2 stage? The FreeBSD loader stage? Log file(s)?

At the EDK2 stage, the FreeBSD kernel is not involved.
(The HPS patch is a kernel patch, if I understand right,
not a loader patch. So: the kernel not involved in this
failure if I read things right.)

At the EDK2 stage, finding, loading, and starting the
FreeBSD loader (on the same media that the FreeBSD kernel
is to be from, but in the msdosfs) is eventually involved.
No extra copies of the FreeBSD loader in any other msdosfs
should be present. I can not tell form the wording if the
FreeBSD loader was found, loaded, or started vs. if things
hung up before the FreeBSD loader was found.

> Likely my fault, but haven't found it yet.
> 
> It does appear that the two Pi3's are somewhat different. They were
> bought some time apart, but these are the two which shared a MAC 
> address. Perhaps there are other anomalies. This is in addition
> to the variety of usb-serial bridge used, JMS 561, 576 (583) or
> 578. 

I assume "usb-serial bridge" means USB-SATA-bridge.

I'm back to not being able to track logs vs. labeling. Is
the following right?

JMS561: 0x152d:0x1561     (how many of these?)
JMS576: 0x152d:0x0583     (how many of these?)
JMS578: 0x152d:0x0577 (?) (how many of these?)

I do not remember any log files with/for the 0x152d:0x1561 .
Nor do I remember any notes about if the 0x152d:0x1561 is
well behaved with any RPi3B.

I do not remember your reporting observing any boot-behavior
differences between your RPi3B, given the same U-Boot/EDK2,
FreeBSD loader, and FreeBSD kernel used on both. If there are
such, indicating which RPi3B for each test would be important.

Having differing U-Boot/EDK2's, FreeBSD loader's, or FreeBSD
kernel's that were involved in differing behavior is more likely
to follow the firmware/software combination, and not the RPi3B
when such are swapped. I do not know if you have done such
testing.

===
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct  9 21:00:08 2022
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 4MlvZK2KdXz4fWf5
	for ; Sun,  9 Oct 2022 21:00: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 4MlvZK0HHpz3hmX
	for ; Sun,  9 Oct 2022 21:00:09 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MlvZJ6W8hzPgx
	for ; Sun,  9 Oct 2022 21:00:08 +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 299L08VD093565
	for ; Sun, 9 Oct 2022 21:00:08 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 299L08F3093564
	for freebsd-arm@FreeBSD.org; Sun, 9 Oct 2022 21:00:08 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202210092100.299L08F3093564@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, 9 Oct 2022 21:00:08 +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="16653492083.Ceba05A9.92041"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1665349209;
	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=MHhq+TDGAQ3Dq76rVLT9jN9scgEW8JCZnDlpNF9HaUk=;
	b=lSFstxxcgaB+dajU3lrwACYYlm6YMwbE/cKle5zmqanTiSr7cV2AGE3+IGjA2X28y8+OIw
	FiugXI0Tgq0DDJgJfIJSjFnstqNEGbWF2gQedsHJ6olAJdvbAjcbTb67LNQscveqWqN8OT
	YiJ/uOAHlV0L/fY9/1Un7BeGCpgSCHMtLD9u29sAid6GMcSInWnXiLZ7cLPOO4fnyrv0Fa
	YIfO1WQf2BGM/ZbD1liemDUERuo0MnhiX4iMeSKofH1XbpmDv/lg86TcScAQKcalbhGjiq
	GvydsiMRe9I/n+Ql/gEd3xriDBAfeSANXjCEi3ht4KAgPal6SO2+txt7IDEuQA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665349209; a=rsa-sha256; cv=none;
	b=HYBTpdEP4gTa+2whijNx3m5r+byz5bxKKBbEer8qHztGwqZ1wDCTor2xAA8jsAX+gtk9KK
	4fgNSsdaGOcjSSg+2Swptzl2y9ZlK0nzsBj/gkKMT5SFDCKQ1nMBH1yQuQSQYeTaBGFn7o
	71mVi+hrEOrb5AlNVe+UMP30HoJfCwMSBVvnoSbSkch+IrJp/GLT1FYS+/My729xWCh+7/
	t0BzK3NyLFjX7XQWpJXqyiQDYtUumaBmsJGPNnRQfNrQb35gJtYXudAIrgxwROcQ5j3LNU
	SGWxDZWkXb54VsJ8nPJQPiXNUMlGS2J4uHLTYnF1V/Fr+KL+gBWevSW+kl+ncA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16653492083.Ceba05A9.92041
Date: Sun, 9 Oct 2022 21:00:08 +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.

--16653492083.Ceba05A9.92041
Date: Sun, 9 Oct 2022 21:00:08 +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.


--16653492083.Ceba05A9.92041--

From nobody Mon Oct 10 00:28:28 2022
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 4Mm0Bm6P91z4dx9f;
	Mon, 10 Oct 2022 00:28:32 +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 4Mm0Bl4gsCz40hW;
	Mon, 10 Oct 2022 00:28:31 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29A0STM5005912
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 9 Oct 2022 17:28:29 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29A0STBF005911;
	Sun, 9 Oct 2022 17:28:29 -0700 (PDT)
	(envelope-from fbsd)
Date: Sun, 9 Oct 2022 17:28:28 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-uboot@freebsd.org, freebsd-arm 
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
Message-ID: <20221010002828.GA4232@www.zefox.net>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net>
 <20221009040903.GA1584@www.zefox.net>
 
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: 4Mm0Bl4gsCz40hW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-uboot@freebsd.org,freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Oct 08, 2022 at 11:05:56PM -0700, Mark Millard wrote:
> On 2022-Oct-8, at 21:09, bob prohaska  wrote:
> 
> > On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote:
> >> 
> >> Next experiments will be to try a 0x0577 enclosure with 
> >> Pi3 and Pi4 running -current with HPS's patch. Probably
> >> tomorrow. 
> >> 
> > 
> > So far it appears that the 0x0577 enclosures
> 
> So more than one of these 0x152d:0x0577 ? Do they all behave
> similarly for the booting issues?

To the extent that the 0x0577 enclosures boot Pi4's under both
FreeBSD and RasPiOS, yes.  

> 
> That is with HPS's patch for FreeBSD's main, if I read this
> correctly. 

Yes, it is with HPS's patch, but since FreeBSD never had trouble
booting from USB at any point, it seems a side issue. 

> In some respects some of the below is presuming
> the context of the MFC to 13.1-STABLE and that the patch
> would continue to work the same in that context.
>

> As I remember you indicated that the 0x152d:0x0583 was being
> well behaved with RPi3 EDK2, covering one RPi3B.
>

Yes. 

> So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or
> EDK2 or both)? 

Works most of the time, but still requires manual intervention.

> Does that get you to each RPi3B having a
> good context if you use a 0x152d:0x0577 on a RPi4B?
> 
Sort of; The "good" Pi3 is using a 0X1561 enclosure with EDK2,
the other is using an ASMT adapter with bootcode.bin and timeout.

> 
> So this RPi3B is main [so: 14] now?

Yes, the "bad" Pi3.
> 
> >  fails
> > detection with EDK2, silently stopping after the ESC/boot/setup
> > option expires.
>

Yes.  
> The EDK2 stage? The FreeBSD loader stage? Log file(s)?
>
I'm still not confident that the second EDK2 boot microSD
was set up correctly. I found an error in config.txt, fixed it
and that didn't help. Could be more than one error, however. 
Basically it does not report "no disk" and delivers a blank
screen.

> At the EDK2 stage, the FreeBSD kernel is not involved.
> (The HPS patch is a kernel patch, if I understand right,
> not a loader patch. So: the kernel not involved in this
> failure if I read things right.)
> 
Understood.

> At the EDK2 stage, finding, loading, and starting the
> FreeBSD loader (on the same media that the FreeBSD kernel
> is to be from, but in the msdosfs) is eventually involved.
> No extra copies of the FreeBSD loader in any other msdosfs
> should be present. I can not tell form the wording if the
> FreeBSD loader was found, loaded, or started vs. if things
> hung up before the FreeBSD loader was found.

There were no extaneous files on the microSD card, but there 
was a full suite of MSDOS files on the USB disk. That didn't
cause problems on the first Pi3. On the second? Maybe...

> 
> I assume "usb-serial bridge" means USB-SATA-bridge.
> 
Yes, sorry. Not a typo, but a "braino"....

> I'm back to not being able to track logs vs. labeling. Is
> the following right?
> 
> JMS561: 0x152d:0x1561     (how many of these?)
Only one, used on a Pi4. No problems, so not reported
> JMS576: 0x152d:0x0583     (how many of these?)
Only one
> JMS578: 
One
> 0x152d:0x0577 (?) (how many of these?)
Two. 

> 
> I do not remember any log files with/for the 0x152d:0x1561 .
> Nor do I remember any notes about if the 0x152d:0x1561 is
> well behaved with any RPi3B.

It's decently behaved with the "good" Pi3, but fails disk discovery
maybe half the time. It's perhaps significant that both Pi3's were
early models that still required setting the OTP bit. Maybe the USB
firmware contains bugs. Once FreeBSD takes over, they don't bite.  

> I do not remember your reporting observing any boot-behavior
> differences between your RPi3B, given the same U-Boot/EDK2,
> FreeBSD loader, and FreeBSD kernel used on both. If there are
> such, indicating which RPi3B for each test would be important.
>
The first Pi3, once booted with a JMS bridge, has worked perfectly
The second Pi3 has so far booted only with the ASMT bridge. Once
booted either one works perfectly.  


> Having differing U-Boot/EDK2's, FreeBSD loader's, or FreeBSD
> kernel's that were involved in differing behavior is more likely
> to follow the firmware/software combination, and not the RPi3B
> when such are swapped. I do not know if you have done such
> testing.

Is it possible to boot ARMv7 on a Pi3 or Pi4? That would let me
set up a single SATA drive that could be tested on any host in
my collection with any candidate USB-SATA bridge. 

To some extent, ARMv7 was the original target system. I rather
got sidetracked by arm64. It isn't needed for present purposes, 
the memory demands of 64 bit are a real headache on 1GB hosts.
I was drawn to it by an expectation that FreeBSD support for 32
bit systems would atrophy. It hasn't, yet. 

Thanks for reading, and all your counsel!

bob prohaska
 



From nobody Mon Oct 10 02:29:52 2022
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 4Mm2tx2mRwz4f9nW
	for ; Mon, 10 Oct 2022 02:30:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mm2tw3Rpkz46FD
	for ; Mon, 10 Oct 2022 02:30:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665368998; bh=+jfBvstmTgNJNWgYPItxS4Lbv3laXTfNQxMdQCZtfMc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lQjBAke1czDSvQW4eSRs2pwi1oDjrWB/yn2fjWTf3Sv33HRPsqts9mj/Z7YCdpcR6jKJZjlPJTqBTmXUIHU7L35WOX4wqXg06sAimVdy/iuQiLtLI1oGFEMMy50syeHncqjdnMMRj0ecxPZHCF2LmUKA04b1cB1FfJjlzkaaE77zGmQKtKzaUATSR9FqFHK/WJ9VyV4fG7TKBYJCuQmfDNAsZAenGRdJXXnvn4jk1UMfi6cUnbeEEvag5m5GaKy76poh774rCha67tRT9aTCOMM95tMFz7PIL2p6uDZmp9eMXD5ByZo5AdbiCN+N0uor6cgaf3JPHmLkuPmaS4UfeA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665368998; bh=Byd65hmdm7gzoeR/1I/EMcuYlRNPoKfWFh9lQfeUnfX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jfCzpTqQFUsZoNaaFHfZtKKN//7nHTo+oXc38HsK/kQT+wrRSWFWMEIKdEhj4NLSp6Jdr+ViiSk0qKjvejBWDPX0Mx9XDu8p3KT7fnguunwXamUqZVHPZm2OCKEL8/SySAKwcvQa35vySjbZwtVQr1z05P3OSN/JyWkGUkXKJB4IiYskjEJPeiX1gdtXRopcUuQ28/YluOdCgi1S0bguBrqFmClpncqwIsbh1G7JZtK4gyTTA4cMDiO1jJ+dqazrmkVXNZ1nnDvll+5Bj67Okzi1kkXaIzI/CY0GETHn5YAcE+Glnjy5s3ufcNHmsNs7DGWNvQjmwoo8PMhzDNB9Rg==
X-YMail-OSG: xMycSVEVM1llnla8nzMZVpRe3PFpdU3IW6DPnpahnlaT9xCde9dY8JE3CXVXIo5
 0jNqG.RKdpNPbrCN_JZlPJkaeD1jSP4B_o1EJCyu6gsxCGr0lKO41EJMZRVLsBVx8vnFuvb1YuCm
 yNfTy4cPgT75GZYL1e5jyph9S8OFesdB7_TGSz9_OBOvUSnE2SHreiL2l6YCUGWWCTJZO2gTERC.
 otxtNZaH42XgOlbE4sFrSlhdOiEJiNot5iOrH5.zGILlM3Kkktowc4ddP9KXK5QBxAnbqLq0SaZh
 Ft02UqaNwKPv8w8I5u_66pNOXNDa.4JSpauS986KPVc3veAC_ZC7RrbHO6A8xVDkuD6ckuwKrIHk
 WRLcmKSGkcxTBiNAs8KsjCvSXo0E.HrZjhEpKsfwDbHB7mc9MAbBtV1il0EtWWDqKnqa4un3HW.T
 IM_9eemCpIBWCbxRtTGSapyPIwdkvrt.toc2fQRWVs6wMhCMuus7LiK04zAdWcsegDIWmttQUTMG
 6S6NRVXl7JkVi.5UvrdGp17SEajnKVBPJ5yIcupI9qYE4WYisshIyEQR562aiXzI2l5C2rZFRyMV
 hSgXN6DQi1ejMvqqjDoeJnroP_BKmubsdFRYsvlWJcwUQxd9HFwIobxTEK_6.b1hwsDfskbrmj7d
 GvnHheJqqsQ8eHvz45uVQSijAxJJG0wnkBAcJ6X05vOwHsZoujbaDYrsqovMuKCpQJkuOvgj5bmG
 5BKtIVTXHCbKrFmF0oIF0nTunAlqu8tmEKEfkkSgCcE54ZMwSucE7h0pxhYMb5abRnGRcKkDNZwb
 CQRiFaw2IbA.Irhi82FnhkMvnrjPmoQaMQgHJFxUbLZgHmixxtKyao.AblP_zvV023vCNr.6conx
 Lj.fkoZdPqO4Sj3ybwfDWDmch.Os1iP6_IWWRe4ruJDt7PbR.6pBbaKe9rPEk0Z0S2j6sIrOSpAS
 1ppDK5XZzji33NdsmU2rpFqMKTcn_4Qd0wnAt6hajNEtNg4VHfgVv7u682IPD2CZfid48troaVkB
 W9qNTy9e67TUbRKGhtw_gFHXTWAdquTi5jX3SL9YZ_3lYK.ecK8XZ6gh5CsUqO2FrWYc2m1obVYz
 kdAET0vDibAHd8gMMlVdnjbr3knAVaLq.6x5sQOUSyD.lsdDpgCLaE1wRWfopPDWdf4ijW_k0_ue
 enHAok4v6RN6FdiXLEtSV..2EzchOgMODi8XSh6RM68BYqSVO1_RAh.35HL9W5QtZ.JEH1i9F.IV
 4DbgxPelh7RC_OIA4Q75ugW0NlLGZQwxss2QCsmlZyvmjK5cR.xrHKa8_CofoNvlJ.7yNuIC1UEs
 fJRzu_Jv1NdONxZ4P_nkrU8g9G0_9ZMLZbwfSUUempBAvXFzj1bWCoTdmNHgtMcHILb7j6AA8nmR
 SJ_NgqRMNDdITSSaBH2C4Et.nXEYEPPLKfWE_ZGIZB1sDKit2G1iHeoNffyiqnvmN5j3T2B1BH2p
 jx.ohvOsXDu1tjvK1lvcT_rKlw97A9Ya3zrYVzfOyxjK70UO_VBZRd8owexGXacHnv7EtLnB4xaS
 bjLthadiJXGKR1yBJ._gfCdpSPJP5_sM4hSf91Gqa22W.iKF1SdnsnVgNHQn7DRbB.v_VKO63THo
 9jF7MTAyS2cELdsVYD1_P3ENSJ52G9laDjKbXBo9mzxrZHl_rKFZqfztRnwMviFG65eD4SlnmG2n
 3LrK1ukjqwPPV9jKXhygu2DjLj5aau6isCafqKLfeuzDGaCphLA37oSxwRbUq3h9BA9MgtBSHYse
 pDl8n_vdmEz2YAJPqRS6lFwXC9PUR_NupUi4Ww.CRuzTCabXXX3UWvt_nDca1xSIEW9ZqFP1T3Ff
 BZYxXNXW.rkaYyjZnwOCpgiKNqwG5lt3q7BtT7BS8hTqbtFWR2MjgmKbzyW22UocGwHQXO9tSmc7
 roVIBCPSUfjZerguqjb3cjm4x4GUWrTHn39zUkeeeZynFzDPH9W.yjgDDJXktSFjy0HOMs1IOLGH
 5eXoCIL1Ps7Nw3YtQL5.CmzyB7mz_F2L0wz0LK8u8R.Eq7xiaXkiNaoLq96lGBpR.9NAQN1ThOcx
 DQAufQTjLwHbFGQOCINxEnfwBNrW7YSmPp7UwyJfD941co5J9kOUlyUNr2MchC4K6pX5rmEoWYs3
 eN0UI7k765gFLl5qDsVlaofw.y4JlcmhPztdi22B7ztJG7US6vHlOMnJgbHTgezOHvG8ukrW6DF8
 Nyv0ohS63nZFI4zLucCif07NwBRN8DmrqQXmEDcwuVcz2DR6fLrY.T1bR572sOleEsB_3hFELieG
 DRiI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Oct 2022 02:29:58 +0000
Received: by hermes--production-ne1-54c586f8df-fmd55 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6f28759368a467b3b5afd9f429942037;
          Mon, 10 Oct 2022 02:29:54 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <20221010002828.GA4232@www.zefox.net>
Date: Sun, 9 Oct 2022 19:29:52 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
 
 <20221010002828.GA4232@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mm2tw3Rpkz46FD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lQjBAke1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.92)[-0.922];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-9, at 17:28, bob prohaska  wrote:

> On Sat, Oct 08, 2022 at 11:05:56PM -0700, Mark Millard wrote:
>> On 2022-Oct-8, at 21:09, bob prohaska  wrote:
>>=20
>>> On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote:
>>>>=20
>>>> Next experiments will be to try a 0x0577 enclosure with=20
>>>> Pi3 and Pi4 running -current with HPS's patch. Probably
>>>> tomorrow.=20
>>>>=20
>>>=20
>>> So far it appears that the 0x0577 enclosures
>>=20
>> So more than one of these 0x152d:0x0577 ? Do they all behave
>> similarly for the booting issues?
>=20
> To the extent that the 0x0577 enclosures boot Pi4's under both
> FreeBSD and RasPiOS, yes. =20
>=20
>>=20
>> That is with HPS's patch for FreeBSD's main, if I read this
>> correctly.=20
>=20
> Yes, it is with HPS's patch, but since FreeBSD never had trouble
> booting from USB at any point, it seems a side issue.=20

You provided pelorus_console.txt8_no_debug.txt where FreeBSD had
problems, reporting a mountroot failure. The start of that, with
some context, was:

Root mount waiting for: usbus1
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage =
device JMicron USB Mass Storage (0x152d:0x0577)
Root mount waiting for: usbus1
usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, =
ignored)

and progressed to:

Mounting from ufs:/dev/da0s2a failed with error 19.

pelorus_console.txt4_mountroot_failure.txt has 3 examples of such
mountroot failures from 3 separate boot attempts, also when
0x152d:0x0577 was in use.

So: Definitely not a side issue for FreeBSD for the
RPi3B/bridge/software involved in those 2 log files.

>> In some respects some of the below is presuming
>> the context of the MFC to 13.1-STABLE and that the patch
>> would continue to work the same in that context.
>>=20
>=20
>> As I remember you indicated that the 0x152d:0x0583 was being
>> well behaved with RPi3 EDK2, covering one RPi3B.
>>=20
>=20
> Yes.=20
>=20
>> So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or
>> EDK2 or both)?=20
>=20
> Works most of the time, but still requires manual intervention.

U-Boot? EDK2? Both? (Possibly answered by-example below.)
What stage(s)?  (Not answered below.)

>> Does that get you to each RPi3B having a
>> good context if you use a 0x152d:0x0577 on a RPi4B?
>>=20
> Sort of; The "good" Pi3 is using a 0X1561 enclosure with EDK2,

So this one still has the manual intervention required
sometimes? What stage(s)?

> the other is using an ASMT adapter with bootcode.bin and timeout.

U-Boot? EDK2? Is the combination reliable?

Note: The standard EDK2 related content includes a bootcode.bin in
with the other RPi* firmware --and so bootcode.bin is involved in
any normal EDK2 boot usage. (Adding timeout should not hurt and
might help for some boot media.)

>> So this RPi3B is main [so: 14] now?
>=20
> Yes, the "bad" Pi3.

Have any combinations involving this RPi3B worked overall?
Have all the combinations involving this RPi3B been tried?
If yes, which worked the best?

>>> fails
>>> detection with EDK2, silently stopping after the ESC/boot/setup
>>> option expires.
>>=20
>=20
> Yes. =20

The closest text above the "yes" is your text, not mine.
I'm unsure how to interpret this "yes".

>> The EDK2 stage? The FreeBSD loader stage? Log file(s)?
>>=20
> I'm still not confident that the second EDK2 boot microSD
> was set up correctly.

Any reason that it is not just an exact/complete copy of
the content of the original (working) EDK2 media, at least
for this stage of testing activity?

> I found an error in config.txt, fixed it
> and that didn't help. Could be more than one error, however.=20
> Basically it does not report "no disk" and delivers a blank
> screen.

The above might be worth a serial console log of the sequence.

>> At the EDK2 stage, the FreeBSD kernel is not involved.
>> (The HPS patch is a kernel patch, if I understand right,
>> not a loader patch. So: the kernel not involved in this
>> failure if I read things right.)
>>=20
> Understood.
>=20
>> At the EDK2 stage, finding, loading, and starting the
>> FreeBSD loader (on the same media that the FreeBSD kernel
>> is to be from, but in the msdosfs) is eventually involved.
>> No extra copies of the FreeBSD loader in any other msdosfs
>> should be present. I can not tell form the wording if the
>> FreeBSD loader was found, loaded, or started vs. if things
>> hung up before the FreeBSD loader was found.
>=20
> There were no extaneous files on the microSD card, but there=20
> was a full suite of MSDOS files on the USB disk. That didn't
> cause problems on the first Pi3. On the second? Maybe...

Extra files on the USB media should not hurt anything so
one as there is only one msdosfs with the FreeBSD boot
loader in its required path.

>> I assume "usb-serial bridge" means USB-SATA-bridge.
>>=20
> Yes, sorry. Not a typo, but a "braino"....
>=20
>> I'm back to not being able to track logs vs. labeling. Is
>> the following right?
>>=20
>> JMS561: 0x152d:0x1561     (how many of these?)
> Only one, used on a Pi4. No problems, so not reported

You now indicate manual intervention for a RPi3B (earlier
above).

>> JMS576: 0x152d:0x0583     (how many of these?)
> Only one
>> JMS578:=20
> One

So is the JMS578 a 0x152d:0x0578 ?

It seems to be another one for which I've not seen any logs.

>> 0x152d:0x0577 (?) (how many of these?)
> Two.=20
>=20
>>=20
>> I do not remember any log files with/for the 0x152d:0x1561 .
>> Nor do I remember any notes about if the 0x152d:0x1561 is
>> well behaved with any RPi3B.
>=20
> It's decently behaved with the "good" Pi3, but fails disk discovery
> maybe half the time.

U-Boot? EDK2? Both? What stage(s)?

(Disk discovery happens multiple times overall, including
it happening in FreeBSD.)

> It's perhaps significant that both Pi3's were
> early models that still required setting the OTP bit.

The one I have access to is that old.

(An editing error in recent years means the warranty bit is
set to indicates unsupported overclocking of the RPi3B.
But that happened long after any warranty applied.)

> Maybe the USB
> firmware contains bugs.

Pre-RPi4's, bootcode.bin on the microsd card's msdsofs (if present)
replaces the internal firmware for such.

> Once FreeBSD takes over, they don't bite. =20

Again, you have supplied logs showing FreeBSD mountroot errors.
FreeBSD is having troubles with disk discovery, at least when
0x152d:0x0577 is involved with one of the RPi3B.

>> I do not remember your reporting observing any boot-behavior
>> differences between your RPi3B, given the same U-Boot/EDK2,
>> FreeBSD loader, and FreeBSD kernel used on both. If there are
>> such, indicating which RPi3B for each test would be important.
>>=20
> The first Pi3, once booted with a JMS bridge, has worked perfectly
> The second Pi3 has so far booted only with the ASMT bridge.

U-Boot? EDK2? both?

I take it you use the term "booted" to mean that there were no
FreeBSD mountroot errors, despite mout root being a FreeBSD
activity with the kernel already running.

> Once
> booted either one works perfectly. =20

The kind of activity after mount root finishes does not do
a bunch of the types of activity done by mount root and
before.

>> Having differing U-Boot/EDK2's, FreeBSD loader's, or FreeBSD
>> kernel's that were involved in differing behavior is more likely
>> to follow the firmware/software combination, and not the RPi3B
>> when such are swapped. I do not know if you have done such
>> testing.
>=20
> Is it possible to boot ARMv7 on a Pi3 or Pi4?

There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
need to be in use U-Boot and the ARMv7 RPi* firmware files would
need to be present.

https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of
the BETA) is from this year. Prior to that the official support was
all ARMv7 or ARMv6 based.

> That would let me
> set up a single SATA drive that could be tested on any host in
> my collection with any candidate USB-SATA bridge.=20

As I understand, such could work. But I've not tested such
combinations. I doubt that those FreeBSD folks that developed
the RPi4B support did much testing of armv7 use then or since.

I'm not sure how much RAM would be put to use on a RPi4B with
more than 2 GiBytes of RAM.

> To some extent, ARMv7 was the original target system. I rather
> got sidetracked by arm64. It isn't needed for present purposes,=20
> the memory demands of 64 bit are a real headache on 1GB hosts.
> I was drawn to it by an expectation that FreeBSD support for 32
> bit systems would atrophy. It hasn't, yet.=20

It will be interesting to see how long FreeBSD keeps ARMv7 and
ARMv6 going. Fedora 37 (in BETA) dropped ARMv7, not having ARMv6
to drop as I understand. Fedora 37 is also the first Fedora to
officially support the RPi4B (and variants).


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 10 04:44:06 2022
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 4Mm5ss662Pz4fQn6
	for ; Mon, 10 Oct 2022 04:44:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4Mm5sr73m4z3KJd
	for ; Mon, 10 Oct 2022 04:44:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665377054; bh=hXRFCg3EyN6CuxfFhe+WXOoqYYxWX74V0f4DfOF02vI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GSIBk+AsSyBSKMH5MEJ/YQxSKaja6MYrywMq5APQooNl5dULsmq/6MtokyYHnl5TQW8fdX8VXwDYZ44CNcvgEEaDTg+5UQFBYQpDmASLM0HyJX6TYp/Lj2TPUm4LIVOEEPaWDMbmAbB0CYptsIcig0Y+CCGIB+Pcs/bAzvbVYxI0gcLRqje+wpqALE776ciQSQ3hsTcWqwULamlf31SzanMenOu1//63pIK+x27kY9+fnhO+yZsTHhdzEnuPOgs7N+FN2Hf0oqSYnwiGXrIw/bxeua4Weowu/kPzJSt6gL5G+kFXGz6wPC5GoSERVrCoROG0HPHk2gUUpe5xTk0OoA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665377054; bh=X/khcGn6BVoi1bu8cKJRfdPG3dKgWV5L2LZ6BBZMiQC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UdPjnD7Fd2BYJgaqbQ6wKON5MiVmHJVDqmiZbBLgCjZcX0FpGHiD4pYq2ks+jggxILAvUq5I/BCPo7XT8SRw6tJLW60ozCtTv06QMa2Q3KJhXPhHuH3Lk/tTc0dg319rJp1rce6yz7OVW7wIodruw8emsd/XJJgAC+P9byMHt+yE+EfZo0p7EAuHSqH4SDa0JzRBn/wyUWTgYzsrfukLFhL/qdxqXj2f25XLXvvANzf6fyXl29qSuZo5c8mMVJgySippXB5gM85i1wXkRF0t2/5evVJyIJYZfdBSZw+5VdBoFHMTHSMCE4h613IVUW6yyLb+05xWfZ0yoL+5YDV+Dg==
X-YMail-OSG: LWuAS6MVM1laBwa.x75Ab__OyDh7xQXinKhKVLUOYJEWCfuIxg7qOUtf_UJYdNN
 NvtWnleBejIiievezsqQ0FM7g5T_Cd8sB_hOCg99fVDHobCHYb.VLzMk1Xy3LXjfJqBXhVhd_PwF
 eRkCw1lLBS61yN32WLhXnsRl2S.y0J5u3keMUCMy69883yAoOOSaLRXteWHPnMS1TZ1MVKDL1FTJ
 lWVBjZTVI9fTD_6PeFikAKei4gwGWCR_Ytv7m0u0j8mOlBxJDXT.KdKEIZ3zwisIE5fSbCmE8.5M
 NaoGeYg2k_mNi6jDLmhWa684IYUsjQsKCw2vm.dSN4EETPpJ3VQUR4mzf59nPE4VO2Dw5nzsZ6QK
 MIwf092OlvH23urAbHIVOGGBoCWDYd0ujdN2LkBydN5LDHgCsqdN8MnsvJJopTu.Nu3F08syhqnD
 5PJHkxdOYkzbDLIbF_oZR5ycSG5CVth40lM4SIB9skL.P_10WRiQotlcBfx3lbsVqB6.284SXDQO
 bFBCUBq4kJPOOPs8EBHp8.gwe0kKTVrm7IFB4HG.0X70Xn_k5MvJ2m2JvZJ1iJj_09t2w350IMbU
 y8z7b_TnsmZsmxOoM2dkbNWl1VM6vivF8eEqu_Vd9asG3Zs7YNDPAeFmMKqfIIuF.T4Hs9xgm1WG
 OD.wGL.ZNIrAgol4w1x3EK8BncOwgwBKibxhDpFizwqdnkFoGPYAOK6MY1g2qiKaoYl89gFsZlVp
 tzG3qEkun0q.jAMh.asnQd.zfeH6oVCGpl2F6guuXlFD7J0Q57PRUPqlyF83qkkFZIja0AeLRg2q
 dqOWMHIo4D3WeUmiCPvnjXgtBSIV9h7eviQ6O2yxFS5_zm89JIeN_aJtCz8y5QO67EsjIbPGMdQO
 6sQm0LE1kQkDC9lxLGOCechFhF0YXfr321RPvW_5Y0BQLRw4OkClVSAPaaLygKArnGOiZBh2_gle
 fJIHTdGGf__STutgoXXuhkS.yqPBI_6M8XTqsrOsY2psGTU5EgS2O95OtF2AbhMKN6SmBeghsDxf
 sMBxN7yi2n.tOy73v.v69AXEZz6ZrwKGEyA86PxQqb2kK4K2lQvmJbbL5S0Ni94VFiXGaOH1pSWD
 Y1F3jfTp6epYXFWXAUG1Z1Uj1Dmm9aUri2lMdWpMcSeCatK_VNhly_xZyz6rv57aEefNWEdQFPSf
 OdW4iuTTrlooJp9ZsCauVZwm3vxp5fWoEiqJ4lf9nIath6_lbvEeycbKrMYMCuEM5tW_t.kGerkh
 N.wM0y.iS56u.3stkruM.dAPygxQqeM2qkQky69YNV9_0Q.MQ1rtUxHA7XHAX.A2_0.vPwU7q1yn
 Ko8YUhzDqKJA_Fu2hr6RnikIusmuFZzd8eBb7x4fo_1PIVrvQ5xxrLES2bbCgWmXbzLQkEZR6kc9
 E7WuYkrLKZIGfwbcC2csTCitrfeB9RQAKDOW6dFQ7PCwu.z9fGqD_kfJZx_0Blo5A.uk6pebBLjl
 7enp9cs1woyq7VJ5k9Z_rJr7pMde4lSvKpQPpiioySigTc1cJf_RTnu6pQODC26ri8UUZlc.bQ.D
 38Rb_ut_eQbpHhE3c7PnXVMfhN6XAVyBAulgH_P7enkl8TZyK3L1HW3suw9g0hwM_YWtQt4uHpr9
 VCempBO6kCR5ZeR2aYskXT1_ThT0EcDk5C20L8zbOLqKqujhFDoUFGvQ86slCTfZKcoq8Go9J9Mw
 z1UQG7ATkPFN2ibFbHTfOZsTfbE0twlV1e3K8ICn7wivMQMA.Bzay6Ob6L8FP8HfdF5GG8VLZXu3
 9z15NnvqKx06f3RjOtxld9dTwyb6Y_hmAYHkmVosWt3hdM1hzmW.Aa9ghMVh1cf_G85C9qqZ3UQS
 G_7qkkh41jBHeLsbKqH9UV0I8r6ayG0njIDVPjUTbTDfOm4_Nhp36lKq27KTxtu1ryikc3P1AGZ8
 .Ojaklhtr1zidYipzI8H1_OWq2wwAmZ1tjsruPGPpGepgTi125vKELBYz0d8ccgaAve8C1FxX7UI
 fSNIunrJnDaCLTZym_SMHjrZz2y0BefGUuYZmv.nTBbtj9.pi4l6c9NxY2i0tq7w4_pgsH1EsLTk
 PXLMOj4V2.AKrctnCgGT9oaWKJH9C5G2XxQ3xTVa4VB03ANhTezjoptgQsG6CBqYA7JPmLq1_Pfn
 p0ZgjtYnC0wNZCs1Dn3NoGNkv3Ijlf3WRZAXSRIA.xAreju27X2OX3M5ULsj1ma2WBvwt0s13BkC
 94G74lF6jJlcePksfFLlMNxfw96bDvjnzuaMJq7IOzefjFsA5psOl3sjWixLZCWhOCguUlJaGzhg
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Oct 2022 04:44:14 +0000
Received: by hermes--production-bf1-7777785b9-zv44p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 00347f27a5faa4d4d882c9e710f4fbc5;
          Mon, 10 Oct 2022 04:44: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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
Date: Sun, 9 Oct 2022 21:44:06 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
 
 <20221010002828.GA4232@www.zefox.net>
 <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mm5sr73m4z3KJd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=GSIBk+As;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.45 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.95)[-0.948];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-9, at 19:29, Mark Millard  wrote:

> On 2022-Oct-9, at 17:28, bob prohaska  wrote:
>> . . .
>> Is it possible to boot ARMv7 on a Pi3 or Pi4?
>=20
> There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
> need to be in use U-Boot and the ARMv7 RPi* firmware files would
> need to be present.
>=20
> https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of
> the BETA) is from this year. Prior to that the official support was
> all ARMv7 or ARMv6 based.
>=20
>> That would let me
>> set up a single SATA drive that could be tested on any host in
>> my collection with any candidate USB-SATA bridge.=20
>=20
> As I understand, such could work. But I've not tested such
> combinations. I doubt that those FreeBSD folks that developed
> the RPi4B support did much testing of armv7 use then or since.
>=20
> I'm not sure how much RAM would be put to use on a RPi4B with
> more than 2 GiBytes of RAM.

My experiments indicate that the armv7 u-boot ( u-boot-rpi2 )
does not deal with the RPi4B's USB:

U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000)

DRAM:  alloc space exhausted
947 MiB
RPI 4 Model B (0xd03114)
Core:  195 devices, 9 uclasses, devicetree: board
MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
Loading Environment from FAT... Card did not respond to voltage select! =
: -110
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0=20
Card did not respond to voltage select! : -110
MMC Device 1 not found
no mmc device at slot 1
MMC Device 2 not found
no mmc device at slot 2
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
. . .

Also, if I had a EtherNet dongle plugged in, it did not
even get that far. Note the "No ethernet found" as well
(no dongle present).

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 10 07:08:15 2022
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 4Mm94B1vdwz4dhQ6
	for ; Mon, 10 Oct 2022 07:08:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mm9486Rn8z3SQP
	for ; Mon, 10 Oct 2022 07:08:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665385703; bh=3jO0DkKDpBg53kMcjttZ1RGocGlBDfMKdPxbJdIX9mU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iu3JF4pgQc0Jpq1zygcEqxJbnixxY5/VV6t0aJ+XcnRsN+CpJhVmjn30zi8jS1FvEazKjTjRkTLvKSnRKA2hZtqFWZti3eZmHgQuGI2kPb9ossVNGjFPqUA4C6Ig9WSo26vBp2Zf/h8d1gjKuwflSxO93L7xHgjiLl4HwZhLgK/65MSje1AJqWFAHWHr/HKKXydOzJ4Jjh77LL57FzhBeFOO2n9+z6ntirhzsrkW6x26oXppbNtSzZaupoIYRJf9etHEIwmH8QHj7KW0dF3BqojOTd1uLUXSGcywr4tYAOsmXl+HPaelmiXq3dKn7pt83gXv7EyKF7JtEK/P+31DSQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665385703; bh=us5cPPY9GnzpawYmupfzzNqZ4AmUL8/vN91NlU7589M=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jbSwcDphTBNO2WianNI6OaWWePVwZZFuUDz3YIUK3X92Jk4cc7hHT15RMaB10lOCT93qJuWCR1F0TV/E5W2qDJ5r7ykEVBjttZzIBLQ4mvsKirNkbpWtnkLU2tyPTs6WyxlV0jJbBS2qq6TKBXOxN4nsPS0yVRgo1fIaQsMzK6/+bg2OzfESthExZ2/DPbyBPrfgglwhtaYve3IV4wHOgPyoybSA8QQItxamLVLX0mCv9wZEhbIVXhMAWPOkMQFHtYjK6Ao/PUve6sq/WAI9LC0qW+aTrl58j4Ui79qqT5Dl6ynmfNvkZSS9YXUdgqhzU4jWlvi4DXna67be+GlJDw==
X-YMail-OSG: NPrOAjAVM1mDKT2tnKwClTAZR.IyUpJvDnEPV46Hq9iwV38HfmC8hFOP0scXGg9
 mLDbx7pi1g18xGWZih7UygQhJlReNdltSGWOvijd0yGlNR.s.mhUcUNrLbu_Z6ajMzwRYcc2VA.C
 uZzMtPw5rJmkUaJ8txizXUVWoTeRCwtTmKx8E9zX5QK9imlLWuDN3U3bDwIHiMY8Bov7Tt_oW0bq
 0AfHPcsHa51mTdYAf.kh4kMZCW4JtopzIRqGkI5ndAljPKxlbvlL_wINm9pjrpEF4KqckuB6nznD
 r1wqOCaeCRbHzJWwIkkFEFDmgpB5IhePeolCZPuOkCzNEK_sGrJ.crdcyn5e.ZV4kL0kitREL7Sj
 9hdMOzpl0JHqNwdvSRTotsaC8QPc9CLyd8M_MqVKAMtbiLQsDBX6vd_TW37zjI2PBIi5g1R.gMAC
 Ic2RoFjEDD_F5NRlFNV0dbi9EzDO3_hvGdleI1BwVbFwuoSXbYZieQgeMdWLNiQj5AdBjT.rN2_B
 wkWdYvDlnvYU8QnMFwqhWICJSFNWN1XXf9La.nlEu6t3QcMd_7qpKoHu_V..sRPePgKU3XU_tBQb
 iamd7zTCIStg6LmCRnduJ0K8WeNBB_KdzRiymrsTXEsdgBtPrYx.B1FRCIjer08v9Q5cOc8_Iqrm
 d9oRtMachgTa4_gJQhGyuIPiFjzrtvM.z1d4Avqijt23cHBo3RQulAklyrWfEwwaQC3h4RWePyJl
 HM5CZMRk0TICv22_C_rHOthwUzGDexEktVubn6bFxQ65AVPWqxoGZyuShnC8n0tE9Bcwbo5qx_3L
 y9_Vtvd3IwdLK0NEvQ2ZtwNw.ik9vzgzzv58WQJDxTO594KuZZSOtUwrMSDH1lsyTGSKPYLbGt1V
 Hs0VAs.vcQd7EKcVpQlQQmLxcnXc0PxzAAdCSrmWQmGGsmDyuanQ_Kra5cAve.wDLwSfC7be8lBw
 e8JfaLRVMIeVHeVjJPhIO0xMkUJqMM1VYFQAFjZkQhFoixHApeNtblv142ySy_e5LmzpP97WCk4T
 Ciik0m_VNt5hj526BY5pcWJWlt34RX5XGK9HP9UjVTJ6ej21bjvUYkIuo2fuULB2iMPaGO62iGwC
 mY4nPEeNDutRspJI2PIwFHNbI.kit4g0REdfNTswxx4qRMwud8H9VyREDj8YxbB7HDeMDjPy0shI
 GSl9pDD60qnlWRMIDxFkCjrquBEtJD6xW8lLzjzqVJqJsZv5uVByed2WB3VvFzpbpIUk7AyeY2Fd
 0cocTENsvS5W580gJMEEt1kT7TUX6NU5vlbYiNTkfOYx3VrkCaoHffzvMvyJWK9qAazRIeDHbDLk
 .m5m9RR7yWUHmwpfEU8qGgfjBgvHAbC5_oejXsZXj1PhZ32SnpTz2c7zg2uFDihwTQ2g8RPiX3R0
 xpOLjyfDGcmLgNMThDUaHIRe9LexedsA886_Eu02_FgylcQAzCEa8uMPT4owcnN_wvj0uNaajBUy
 R4yqQRVVwRJ0.E6d_3RswWJH.TkuCCMvhUHbWCTAg46DfcCdq9alsvSkat9gYPOIL3BchgecU_ha
 mvRZ4Ul2Ag._WWwC9k59d5lHHzoneFZwN1ccaApWsJZu9hLkrCHUpFfAPQn6xLB7wZy9cnwmfwld
 C1E.ZEXbXsCAQAm5D4ssg2eYlViQ4X9a5M1Py5Bb0FgtxyY3hhWfegloR5iWO5eiQKB2TH_DgNVc
 e4CI38e.zJIwDFqxzS397VfztP_so98TvStVknabvT2IJtylcO0CtlRdyvLVx4RnoS0r_j.ii.3E
 BCsgD_rpKoQi9V5TUc24fwvBwoewPAiBF3pfHPpWuYvhvb4yRsYN4faVdf.HjQj0y5gUmljFpAmU
 muUmgY6e5a.6AvxUhdUV9sifPLI3eZjMtL0ERhgrATSnZROd1yEwXRYChTE0a8X2pAGBFva.B7xq
 1AD9uTfpw9P4CytWs09QkkXJpfNS.HrKNxJAS2S6zi48rXu8X41zIQjNbgOvTkhARgn3nQmuD_gb
 fI9x4qLjb6szZFHHAIoxuhhfmZX6IJ1SsYbxXXB6lgXaWBuRLlrdsmFYtWz1oyDnX_MZGPdkTWhw
 3LxaVVZwDuaj2cdwNJ5ALSrgULecgA36EFwvdNVvP4qtkiZzwnc3rz9JBZAH6vRx2Yu1lawuuSI3
 0kJReQuvlJ0R27sUt5oWS00x.052TM8ugq3y6GQ2aNum5OSm_rhZIwBKjk4.LdNll7p5IadHE1CB
 eihAs6leuPW_zrV6LrbdO5_fSda.FrFoijpDXY.GwF2HtrPuoEui09Me0jT96YNK8dzHUeHtSeSg
 eRQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Oct 2022 07:08:23 +0000
Received: by hermes--production-ne1-54c586f8df-9fhsr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d6b1f8b35ddf4b7686c5d1bb5b2d9aad;
          Mon, 10 Oct 2022 07:08:16 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com>
Date: Mon, 10 Oct 2022 00:08:15 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <376089E4-8450-4842-B24D-1D6334D504CC@yahoo.com>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
 
 <20221010002828.GA4232@www.zefox.net>
 <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
 <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mm9486Rn8z3SQP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=iu3JF4pg;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.968];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-9, at 21:44, Mark Millard  wrote:

> On 2022-Oct-9, at 19:29, Mark Millard  wrote:
>=20
>> On 2022-Oct-9, at 17:28, bob prohaska  wrote:
>>> . . .
>>> Is it possible to boot ARMv7 on a Pi3 or Pi4?
>>=20
>> There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
>> need to be in use U-Boot and the ARMv7 RPi* firmware files would
>> need to be present.
>>=20
>> https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of
>> the BETA) is from this year. Prior to that the official support was
>> all ARMv7 or ARMv6 based.
>>=20
>>> That would let me
>>> set up a single SATA drive that could be tested on any host in
>>> my collection with any candidate USB-SATA bridge.=20
>>=20
>> As I understand, such could work. But I've not tested such
>> combinations. I doubt that those FreeBSD folks that developed
>> the RPi4B support did much testing of armv7 use then or since.
>>=20
>> I'm not sure how much RAM would be put to use on a RPi4B with
>> more than 2 GiBytes of RAM.
>=20
> My experiments indicate that the armv7 u-boot ( u-boot-rpi2 )
> does not deal with the RPi4B's USB:
>=20
> U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000)
>=20
> DRAM:  alloc space exhausted
> 947 MiB
> RPI 4 Model B (0xd03114)
> Core:  195 devices, 9 uclasses, devicetree: board
> MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
> Loading Environment from FAT... Card did not respond to voltage =
select! : -110
> In:    serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> starting USB...
> No working controllers found
> Hit any key to stop autoboot:  0=20
> Card did not respond to voltage select! : -110
> MMC Device 1 not found
> no mmc device at slot 1
> MMC Device 2 not found
> no mmc device at slot 2
> starting USB...
> No working controllers found
> USB is stopped. Please issue 'usb start' first.
> starting USB...
> No working controllers found
> . . .
>=20
> Also, if I had a EtherNet dongle plugged in, it did not
> even get that far. Note the "No ethernet found" as well
> (no dongle present).
>=20

My experiments with:

A) An RPi2B v1.1 (so actual armv7)
and:
B) An RPi3B (so aarch64, but a pre-RPi4B design)

are incomplete but both work the same for as far
as I got them to go. I got them to:


. . .
Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x36a00200...
Kernel args: (null)


and there is no more output.

This means that the following all happened:

A) RPi* firmware got U-Boot started.
B) U-Boot got the FreeBSD loader started.
C) The FreeBSD loader got as far as those messages
   after loading the kernel.

Beyond that I do not know what is going on.

Still, unlike the RPi4B, the RPi3B looks to be handled
by the armv7 context (at least for as far as I got).


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 02:37:21 2022
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 4Mmg184kkqz4fbBV
	for ; Tue, 11 Oct 2022 02:37:32 +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 4Mmg171mZNz3pRl
	for ; Tue, 11 Oct 2022 02:37:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665455848; bh=MCTt4E0XpMFNyqhr3md5Z5QmrKqwCxIW04kRZJ3QQ50=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jIAh+JkbUPayfXItlLR9jgKj6mbkKJGTJFsgXro7xX+OAh8kKysIwJCNTYf9d+aNp7niAbznAYSMShB1w8kZm/UvEx1C9WlD5qgEpOIfGkZyCG+WzM5UmibaU/iNkTMiKPzaIdkT71nNadein4X9vxAlnqmFSru4rfB4dL6v7QjvpQ9sGQyzaLicBKkwgEj3yOInKjdler4qxyJdhvEcA1AT5/w4FXgvA3gemPylvbeLTbKfVfHNwVXfFTLstLMNMeDLPJ4B4mjfu9DSwI7zFFUImtE7ZZj93lYiTenzWlUFzYIjVkQLmcqbmP2XH3wc+6NhXmDrtuxHwH/kyT4KRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665455848; bh=SYcBstmZh8JNW7fPCW+2nBEX89PDo9ucIglXIGl2jqA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=d2/N51cYRi75kN1z3avnYEwGIaRRYRSRDB+12gsGwow5Kz4CtH/Z1pG4FerKVeJUoDK+NB6tWqj5+U1zraVp31ELrGPsLq9sZnkS5Mz8UsUiSL86YvyWRJNf9MxRZiRb0iJMcJfg1ab/7vaXbXLawhhr2cZieOUZc2MAQ+jSC3KGUX2HMbgxGpOUKYkkFnhotMM1Nyo3hShcwQwH01ebv+NuAr64X/VPcg0hAavujbBZUN7c7dR6H8gYfXwGJrJyYNWqZBeunMYXS/GxkJ6a9lmsPxEcGGArQv+7ljcZZbRM2Uo0le3dXkKfkUpd62sy6b2WpoBOCV5TfWr57T2eCg==
X-YMail-OSG: jy6CKzcVM1m.vTvpXq7E8pQ8LSkyPLrHbOtYxbOJB6UZgcDUSW0pcWqxdBt7o9Z
 jziVGBUFKce4tUNjScerti_2wEk9D.8VLI5i2tO0KB0BXbuZEM8thgnKzFpmusbYJS9L9rH4wzhg
 g4FVjNbIt9IkZzkHNTRCt3hUjLmCed_bxK7T1NnTNbIHujhztlm06yTzF6b_sOKWOM_iiVnSGSci
 3wd2bxyX3ejpXEU9FSpL43FtiQ0J8Heg4gYYtn6o0ptJk33v7vfIhLyqo8oBhbOwHpOVrY1lVXqF
 ta4DLEQ3azk5.MkbbjGpgBHcE6Zt8M3E5NjWXslF6MhsP7OrVr6oGqTAKZJUq7KNePMYCPsozz1Y
 TPIeDb9BpzOyxIdf10wKTViwowBAzkdQhG7pcMbrFj2P1UZc8ESDnjSGMtuTgsjd3NFpydjqI27w
 0gbEVhpIbD8KtsHH2ljSXPCipyUhzO8r1BLne9C6m5a7yZ1G1qzu6uTFGE7EC6OvGq71gi8GyDPM
 slyKVszI5xpTdCdJQ.YOwlj0ATKNeRwMHTcqXR6Z0L9Du1_utJdh5Wzz_hlcBWLK6cYQ_MFSOgWt
 2hR6w6klAHOaGK3AC1J1Q5M8gmJUiCf4LaUeFmP2H7zMuTfNJ37XtXqo9GXDZ2kyGEpdVUPZMJr0
 lyAEKLLjPBX3GsX41jHCZQy_BLJGh_FKg_gurutg9lebHAUA5XUztmyqiobetOdapNldwEuL_jpv
 bwtF.pocLdwq1KgIEvNiDhv3Bc0hDx19ACr9oVw5EdAFVb0espHYVmFR8dVEnttqTEayWkuDTJ8.
 atIm0rmQnHVrJFrvk64e39K38SzaI4CnlJco3fa8mH7._oAqRLy2QmdbxlUPAW0KYXrJ36Ar.KqD
 sEZcjyS8vDiTJd3sEeC8uwoj.anB7ZjId01wkLkjtl_J0i6hsCXUs17qPJ8amIfq2SwKiwfL23g5
 m4vh7rvli0cWHnCnEfrMaOSonVTsC.iBEw8imffyrudMkkX7_s7b7fXNRJU1aSl6HHP0sbKhxLaJ
 bwXuQKkvoX7ehaYnWvwo9Q_PsSXui6nph3PXCfWY10r1Qvipf9cls7Q_nvjuZPwUWH8LGbFTWMw0
 70C3n0r9zbGHEEfZbqL39BEQRaksWwVeRInD57FuaJ1gljxjDVg7CfyFNNeFJVsWvGVbRGHhc2g4
 EYrfRZ_KF0wOqmxYyrfHW4aZ6ojWAz5B0_jpvSct2YOlGZpJosdCoyE_ehaAT9MwnD.4ii22IIMU
 ElAWyj_p7gw.yVy_8x6rTvE6fyxQ5Vc7Jki8X9gBARILb9Ck9G6gFk8kwdosKbS49RgUl_xFVdrI
 giOQgdUoMk_GpZCKcjcm_9JxX7iKi8IJwZXrrsjP8CsWJO565qtRptr45CeNT2AxY8c8mYkgRIZu
 zd6bc5MSsDNJU.N550qax6vIlSG3r17Z2l4gkPXMfXXnp3cvfi1Z3ixalBd5TIUw9kIRDGh2gfPg
 sHaPxbw9uPiSA1bdXU1nYS5oabAuNMk7FsJZdEQRsM4t9ijRd_ja1PU.z4.HkHXb94fer_S1xw5B
 3Z64DE5UNq5Yc44c7Ty6tLovczlY3_TCRap.C8iIN24pJBFkpz66HHRpusb1BfTMZ.21q7.ktgyp
 Tg8Cthm6sCy.pMlAHCWQCHAECru0syQlvz35AkQ1gPmMR1t8_tkeQdoK.b.lMwPjo35ZtJ116rV0
 vADJZpgUPBG.kYMd3yw9sRRCC_FuwpbqQxWl3MkN1Df.ZK1G_FI3ACwGrb163uORFJmUvuNe36CH
 6H6m7yosQ8Qv9aeDnxgYyfZWoDvDy3RzF9oZcf0j9XQBC7vud_6mskBH9AP9qqnS11dzFHVKO26k
 GvcPQBdIQROy8BTlsSc3dkLhwUlE_i5LLerjz4D_gQnKKV45bHr_fH0kjhfol4bz834Pg.STK4.K
 mxQt7GxuvyhpsQXQuyi4JNosSWV6jDxl.TzSP24MuQBAJ_.04Atcp56aEiAtpll.1Tpma.bAZjq.
 mZI6TPMFttNNkRNG_bID.hg0jFbFqsSfmOnu9C7y2Slknpvq7Xa80K1cyq3WcxOASYTLYo0MZxKS
 S0_1nu_Hfb5cTNk_eFSx91Sb77RQYa5GPGlKOkj9SrrbI0Bn7wshppqQCboUHAb_8kFP4Kgh1C_B
 YL3MFoWB7bAPHHvMFCt1kDM45_kwJE.Y.kctRH1NTxqqg5N2d.IkzfdeHHBf51bhFs6iNsNQPwzS
 k17f3WIvh0aCWkFjqySScxDt1A09Ua0ONUlz.dJvBAruMW1CFXLn2Zt5qJfClQ8KWPqySOkHK6wz
 ZzQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 02:37:28 +0000
Received: by hermes--production-bf1-585bd66ffc-hkqwj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 54d7420a8f3725e92a4f125b5c79a295;
          Tue, 11 Oct 2022 02:37:24 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <376089E4-8450-4842-B24D-1D6334D504CC@yahoo.com>
Date: Mon, 10 Oct 2022 19:37:21 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3AA3A257-50DA-4896-84CF-1339AF7F3854@yahoo.com>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
 
 <20221010002828.GA4232@www.zefox.net>
 <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
 <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com>
 <376089E4-8450-4842-B24D-1D6334D504CC@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mmg171mZNz3pRl
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jIAh+Jkb;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]
X-ThisMailContainsUnwantedMimeParts: N

[Summary of armv7 experiments: it looks like the RPi2B v1.1 armv7
support is broken on FreeBSD's main [so: 14].]

On 2022-Oct-10, at 00:08, Mark Millard  wrote:

> On 2022-Oct-9, at 21:44, Mark Millard  wrote:
>=20
>> On 2022-Oct-9, at 19:29, Mark Millard  wrote:
>>=20
>>> On 2022-Oct-9, at 17:28, bob prohaska  wrote:
>>>> . . .
>>>> Is it possible to boot ARMv7 on a Pi3 or Pi4?
>>>=20
>>> There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
>>> need to be in use U-Boot and the ARMv7 RPi* firmware files would
>>> need to be present.
>>>=20
>>> https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of
>>> the BETA) is from this year. Prior to that the official support was
>>> all ARMv7 or ARMv6 based.
>>>=20
>>>> That would let me
>>>> set up a single SATA drive that could be tested on any host in
>>>> my collection with any candidate USB-SATA bridge.=20
>>>=20
>>> As I understand, such could work. But I've not tested such
>>> combinations. I doubt that those FreeBSD folks that developed
>>> the RPi4B support did much testing of armv7 use then or since.
>>>=20
>>> I'm not sure how much RAM would be put to use on a RPi4B with
>>> more than 2 GiBytes of RAM.
>>=20
>> My experiments indicate that the armv7 u-boot ( u-boot-rpi2 )
>> does not deal with the RPi4B's USB:
>>=20
>> U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000)
>>=20
>> DRAM:  alloc space exhausted
>> 947 MiB
>> RPI 4 Model B (0xd03114)
>> Core:  195 devices, 9 uclasses, devicetree: board
>> MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
>> Loading Environment from FAT... Card did not respond to voltage =
select! : -110
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> starting USB...
>> No working controllers found
>> Hit any key to stop autoboot:  0=20
>> Card did not respond to voltage select! : -110
>> MMC Device 1 not found
>> no mmc device at slot 1
>> MMC Device 2 not found
>> no mmc device at slot 2
>> starting USB...
>> No working controllers found
>> USB is stopped. Please issue 'usb start' first.
>> starting USB...
>> No working controllers found
>> . . .
>>=20
>> Also, if I had a EtherNet dongle plugged in, it did not
>> even get that far. Note the "No ethernet found" as well
>> (no dongle present).
>>=20
>=20
> My experiments with:
>=20
> A) An RPi2B v1.1 (so actual armv7)
> and:
> B) An RPi3B (so aarch64, but a pre-RPi4B design)
>=20
> are incomplete but both work the same for as far
> as I got them to go. I got them to:
>=20
>=20
> . . .
> Using DTB provided by EFI at 0x7ef6000.
> Kernel entry at 0x36a00200...
> Kernel args: (null)
>=20
>=20
> and there is no more output.
>=20
> This means that the following all happened:
>=20
> A) RPi* firmware got U-Boot started.
> B) U-Boot got the FreeBSD loader started.
> C) The FreeBSD loader got as far as those messages
>   after loading the kernel.
>=20
> Beyond that I do not know what is going on.
>=20
> Still, unlike the RPi4B, the RPi3B looks to be handled
> by the armv7 context (at least for as far as I got).
>=20
>=20

Well, I tried:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img

and I get the same sort of hangup on both the RPi2B v1.1 and the
RPi3B when booting with the FreeBSD loader, kernel, and world on
the USB media. I've tried 2 types of USB media, both got the same
result. (microsd card media is involved in the early stages.)

So I tried using just microsd card media produced with dd:

A) The RPi2B v1.1 hangs the same sort of way again.

There is no .dtb for the RPi3B unless added to the
microsd card. So adding it and trying:

B) The RPi3B hangs the same sort of way again.

So it looks like RPi2B v1.1 armv7 support is broken on FreeBSD.

As I remember, HPS's patch is not in place yet in stable/13 .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 03:04:48 2022
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 4Mmgcr1lT7z4dfG2
	for ; Tue, 11 Oct 2022 03:05:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mmgcq37qxz3qfY
	for ; Tue, 11 Oct 2022 03:04:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665457496; bh=zGUr0hHphsKQcX2eF6JfZfUKQxKgTmfLhTLkMTi8pIU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=Sg5ppiFLkPp0QskOR3b4fO7CQ2PVCxc7e3eWXGHo9VxU3q6gdRRo79ca931bo9IpitpAnuUX5LGKxwNTLLmBfeG74VQ0n0HnU6MNqjfWgk1I2JuDQMHQ9e5V3EjwgkRzOVLGWoNKtDoxJWmYFgzwiSqV75Gm9qS29ZXMupKcMFICS9otmhmK3LyIAXtCDQRrc6VcH+buZhaXuEqLvJo2j5Qt+LRTvwPcdt8R6boRgyJFKxUSIs1mT/y5wcMGKx8HEf/0P5i+GSUy0isUtvXDLw7jsTMtpIaPXorvdiWhUsU8pizFmHSUSotyen0ua6lSVvQcv1PkxvZjkDIh828eCw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665457496; bh=ZATQhtfzSngmfgrpjKrvXwRV0zDkj3us+We/kzyqqTo=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gs8u6vJq036doa1lFxgdgH4S8sIHueZKzi0WPQ/OUmsZ6HD0CxfuNckhVCB4pa7QiDyXSDoQVWs9MbNmWaSnnKDTf9dTxmbtHBUHaEVWU9/GZ8xTJnQxzxuoTi1Mnjb75dMlWy+zjl/TxQ812grz7ekq9RFQPC+k8R/EFivdDZUqbW3hBkl4AURCTogX+3Q/H6wsCrSoaTbsUUOItYD/8ZNIOG2GYK7+DZq9rsxIwibahWApWhYx9iTrz+GUt/UsYQOJ2tgstQw2yfSeATCwDvDV/GFGYuT/qvmGL5uyxwGk+RWyhb1rKWBTllrQSFh1upWIFUDU4sfwSn9yoqtcHg==
X-YMail-OSG: SeF3iY0VM1na39BrRHPkAvwVTwtGR8nqdAkmxPt2whcv4M9XWpgIQWZTFD.EmJZ
 UEqzHqFAeP8lJzXK2b2coX2ZHdEnkwhZMfbkXEyWc5FcmlkHPuvBiT.fbLzFXw1abf_aJP5E.EZF
 0fxuzQbaIkP_ddwvMbRt9chIIgz4QNifagqa0DAeCnTH46EeIENLEgiCoFh7Wf.UHuxhNA6i0xme
 AnwTxkkheoOQdo70hdDahwEOD.VgIEawcwBfJ2iA038N.AUQP0OFOc1BACaSrBus5lFixV7keIee
 zCFwgIyXtbeDxrKqf1fuYIUpgDZKVFziPIeRQClyLih7h6VHobgov9rIlb5t0EPEQ4Ebgm9RDvsz
 ooePtSXBZHcTwCATrNZDlHnLyqWDL.zAbJPfZ7DsvN2wtEro5wsX1_nAMhBEu1wVXZFxuGJkgDLk
 c5kV3YvvCteieZ7kUXCOPEN3qZmrQVr8PHIiWIfy9Aeaue9A7VnMZLwtK2GmzzjPvBPbFPIBRMOr
 PSugdjUvN7cEyHFCMe7oErBk1d5F08CkQeL_8lw6oH76zi1qMJ4uZGNmft4EhuhgiohaLbInqUgV
 p6Ap8pmlybYV0a12TSyNZX5HJ03cBxDHsG9tQZpV1OnMJBNTkoa3L7CC6w4bhzYS6.HhBvaG85Ga
 12vKnyrCt7X2RVBk9HUj8EeN6dsN9eL_5kI1p5XniUC6oiwEmWo6MZQs5GstOJSSa.aEn8w5_OB8
 9KZwBGRPXhPBynEPhAgZxaiDvY735zgg81eZLu6E2wlzEcIanRfdTYfLINCbmN1G2uB57zdvMsHG
 jdqGZk7zSfrV4zZZ5DrGj1AGxwd7sdYUfCV0ETdOCnJRA1sDA5EQmdxfpElu0Sd3F3kSV4jWA0Rf
 RlRYrPnupM.tqrc6Bl3qHR1XRQ8Yrct.kreVooJ1t_VfwBZIK8mG.gBxGOY24sz0VqZ2BCTeUbAc
 g._fh.BTMrPspCs3Ci3LeP6m7kbq_tOIkL69uJ06YS7ep9VAAksk7cnwAW1vUqLd5QhaGstreT13
 ZPlMm8vCuJr1niSABhKbukCOXEbBnouFG1Dd7.GqkhAmqPwiZet.yIuUL3H739Ss_02_Six6LfWH
 xtg3HV5kz15VlXftDZm5CXglSzmQnLaO7ruJVpmQe1MCqizrLUKnO7BjiwsGYdSP9P1dIj.o9Jb1
 VJFcfNNrez.mHgEoCFp3NzTCh_oRS3MUoNfjVU4KYRuBYm8laxJN3xcLghxb1KznhiSJhhL0HelG
 c8L9m217nvWCaJIcWOiwpAY9p7wms3DQGJBAzk_VrWHCcCGmjIv9XacoraEohihY_KU2DUGkJhWA
 9loS8L9EAqCreMKfOjq_U_7OBnsWpZf0e2jBwOUNv2fBDhRe_LAI1uue6sTtUWnnA7iXzv6P4aLT
 pwuFUqUVtOiYXmJE9rgS4XKfYZ5KwRJfPjuCW7H2JWxE0ekaB9HLzuNWH51hkMkWLlqisWVZCLWj
 k2ttiDC.HjnxsK8VPgXtZQNU3PzPg0WAcV3w0bzMogi7DfgPdqFvqtvRva7GcbkEtKEZekAVw4c8
 WJmYWOkkPe4K5kDLEdyDN1lTKZTA3NxEqCcE1WHITaYb4jDDWIUc6BTJcXiQ_7AVIvWBHjrmT.zR
 9z4ozDJwpXqmIyaXJsarvmxELEP5hjAnGSnJKgMMu8fBmJDES04EaDNBlz8kCLNiOYazrzG1qBgQ
 B.slf31f8oBsxCH09JopBp0ba5jfyrXc8V31XQbYyjfCa7Iak4ZiLkk9RJtTzMo8owRjSkbEG8JE
 NHPxbaScUHGtXCXZIjEPyAjyllpBBSYvqxOj7ngs536tZ9Kdu8tkueTYoxO3nMmeoWQsN.v4GvkO
 nbRKwj7UJc0h._Zp3gpbaqsaflpyUysW1l3.fMu2Tu9DU0DUlRvFQGRyt7dVp8mXZRP6mEBk_yXu
 p7zILO8ZDERQfs8usIqZ6KnFQsiGmYFQEHwIBlLZod9tkJUu86wq0MtnxdphdP0pqKfkZSbEl0oK
 ymwvGnZEcjhbUNl4fYMCYaTK.yKMq8fWANF4kdiEOKSdNMzKXoWgjRt528UtSbfeFn88WWG2J0ax
 I84QrPoQpFUNi5OY6T..gmZU5Hb.0zw9QCY1.7PgtwyprxN7wW.7KYvPalmaUtL8iP1NMWw5i.vq
 hrrl2Y1mshRYWo8q8UOXMFjHazQmdIqQ83yTQgAZhWuL0qhiqgRk9gD7ZBYQdSwgPaY.dlNtIByg
 hu6dQPMYwq.wJlJXN6oSigLizxrM6cwd.trU7FEGTtcsunPMv93tNPkuVu5bzYsd02URuKEDobsA
 d
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 03:04:56 +0000
Received: by hermes--production-bf1-585bd66ffc-cs9dv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d725bf1cd18bee90e9f9b5522e9e8574;
          Tue, 11 Oct 2022 03:04:50 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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 \(3696.120.41.1.1\))
Subject: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
Message-Id: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
Date: Mon, 10 Oct 2022 20:04:48 -0700
Cc: bob prohaska 
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Mmgcq37qxz3qfY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Sg5ppiFL;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N

I put:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img

on a microsd card via dd and tried to boot a RPi2 v1.1. it
hung up after:

Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x36a00200...
Kernel args: (null)

(A "-" might show in the next line.)

So I tried:

FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img

on the microsd card instead. It worked just fine. (Thus the
RPi2B v1.1 is not broken.)

I did this experiment because recent testing for other
reasons of somewhat older main vintages that I'd built
also showed such failures. This test shows official
builds also have the problem.

I've no clue how long this issue has been around. It
been a very long time since the RPi2B v1.1 had been
powered on.


Note: The arm-armv7-GENERICSD images include the RPi2B
v1.1 related RPi* firmware and u-boot, in addition to
an installed FreeBSD EFI loader and a kernel and a
world. Historically it was supposed to just work for
RPi2B v1.1's. 

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 03:59:59 2022
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 4MmhrT5Blyz4dlpv
	for ; Tue, 11 Oct 2022 04:00:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4MmhrS3xJQz3vqD
	for ; Tue, 11 Oct 2022 04:00:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665460807; bh=yjr2QSj52MuUX5jo5Os/alxWevDMi03DeDU9HqGecAc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=l5Ry1vj9G7p4CjEqx7JMEK9ovAtlRGBUEiaxD6Z8+ISKgTGOJz6lnwNxSeOduq0+kfEeAxe/SdURXAM2Dy6FwwvaiCBkhH0CKuw/MULgwtRUrui8kOehzzKoN+mdKLahtzkDfcd1xNY4OONpATQ1v+mBDXoh4/zcrGQqOiUeapeOO2QjQB1YX7204Q9VDV4U9Bq+YdXDpCG690bVm4KXqng9gp6AyJakjNuewuRlrBjBp5U3xM8ETL66e6YymEZ4dgHLk0RQU3js029VAsdizGYWVk49t9G0NwItt3LFAqwOw7pNk1IAd4+uunJ9ddNJrNbQQqwZ/DYJmutQOEBQxQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665460807; bh=GPZxtjNZPBh6848oJM/7oqWDtJgtqAIcH0FWdsmeTp4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=L/FYaXn66Zzf8QFKmWzf7J2TX+TX9pDd63muY+ckmzfi4YTK//rZ78yg+xt2HLzzAG/gXZixtohBwiKhCLvZOURzuHdWQgWhMBYFtGDdO/Ibvuvh1UQSdkCdRBsGcvApfRnMIaNzwOEbsFhn70VAp7VYxi0z8sgIM9ZiW39h2wbAn+oCitdhY9M5/1e1u8gCanxja+1CLJ6P6Zw6do2DdaDNAelkdEu0rq8hFA96w0VzYN0Zp0Ia7hpFyxZ0fzoezIpeIaJTeRa2jj4sLDudc2NtWhPBXFlZ81NgWWIXhbzo8XzsXSDp6pGf0fcNRx6ohvxv03mtKwF97GkjrzRjrA==
X-YMail-OSG: 5579rskVM1nIXUddK3IBYF_zSWH8t5OBT2zyWNul4VKD..KrRe3E52qFGLDXc4W
 M5lAZvQ.nScBrVC2LCyq.uaxVMTlqstzbNzd1XyfsCgaKPFo4.cbBQtdOzCqMo2e3zcB5EYGJTmD
 5odFe46.kDYd56Oavic144F99LpO81CwuK_DMQvE77pISspOtF4UkX72iRTX95ZuKNUjEwbjdtwO
 VRgojmy7FEoewSr.PCZalGv7Rsun0AQgfzLG.lC47yz6dOdauzm1oySLjgglcNM9kTFnGIjR46nG
 RvHLZg_Uu6GGLHHrRYy26VHaYvY9Bmd9bQ0.CRPvkv.KjVzwPHuKYlmugxTI8MH6A6DZNXwTmJhU
 nLu0y2MwUwuBDluRPkV.St4TS6Q8JAxAnghhliNneR63EoDQXx0JSeGuh6feKpTNeI_NVy8xjh05
 nBXbu3Q7JO4Fmf57FZw2i_qVCp6PhLJ81iK1T6uaWWSDz5dTyhZwuAmZluBlgVRRti1MGUCn8bcl
 h9hHmn4J9mxfmt5sz56sHfaV43lMP7EzipO9Jdq8nuq1hBad8IBaQ0K_uxU_Vy.kGJlaIJdMyjKO
 OqBYm4vbWpZx8TkuMw4Ft_D_lu70bYBftskiMrplg.RBDuqS1fnIlvFSD5ORrK5xluU358oMVSLI
 nFHABa9YUe5mxY4q6kX3i1pj4qje1zDvHkxzqRWSTtnOHCDKSq18FpCmqy79Z_LnZ2ZYtPFev3aA
 PU0MiS8irhqHOArI6jQncy4BbkC0dpEolymQPPCHYDRu_VaLjRwxq.PJjXZShgab5znd3wyhG54C
 RboYp60HgdnFFpjm67cucu3qoVEPcpPmqp8lJAz9ng7tnJifrBz.3L4fZJvymFS5w5bFI1Yq9jfc
 s0mi39MOar.SuvGPARkhpKtRewW2aLmFljQhIZby3rNcazDHuvKcdoKGuKiLMNjPXlRaC4SYdX2S
 kmBX5B5St0AAi37oQhuvdzik7iIgTDPDjKo9OiarcAxu3HUcj3hAu0TL02rZB21gCtUEwJ9EP.62
 6qw.SwRy5.WgLPrzHf4jtIY1FoV9EeTWfkwNcykFgLB6Jojp_emsBXDdA008M3_czran5nMY0QYG
 i4yeSyF4oLbhFWSVBnFviHjpwU8lL.ina09LydP0.nobMdcxFfby4g8UBtFenWQMYpiEfsND4dSr
 jdYsXWbUEGtyTZuWlMBQ35_BUCi96kquZdtVyAmwqJGqLgqCSIATwfezjoB7j_zppNQ2o1fRYRwS
 4h9.jJHQHZGiJbyMN85nwsAMTXZ7Z6ecgcw.Zq41V9J.N9AYiBuRl33G5LsDtI5vpc9PUPuSZhxi
 hC5B05QjIU6TXd7GU.MWk2c3GQ5x20WJ63wV6vw9JhnQ.0T4dzN4GfQWmSBotx5P8Y4DBmAoG5LO
 D3y.ewsI.817iNyxD5MI9zWMPUG6xYBVHvfcwJaPteZtSeP_QMESmOg2eGf4CDALwrFh043NPqIb
 aw945z0eCyjglzltJKCtBTCHsgvFMOu9PLnnN_vKEzQAkg_80dZsWjXxcMrZHrsf7vfenzqu3.hL
 iQ5QlwooU0UDT.oEqgZ.99NSz0EVi7ZUKfJ7GJxfs3Qmeut5mPllDVxnDrv87tl.nMylj22.a5t9
 L.XkwUIuQnm3nmOlaYV0Yz22.ELT_kMENdxPpneeQKJp4pGX6YXKCI51TGh7OnIZY6sGpeSee3FT
 0JEDG9DtHxVj62qcj7YYikLJpW605Kgt0E4bHIynywHUxT_q5Wc36V9bMKfgXH2GrlHMWgYFjvFT
 ganmw7fWWvPWCyhwfZR19MR_it_JRBOHI96bYePvN4hNxx32se5bTCbBm6jKBMyUmKvulAqhTdxL
 hk58EDWszwiLj_zdB37qyhpPKXIf8.97tUwYjAdQrMTlchCTctFqWiat2t0NMF2U_AJ68nyX7c6H
 RT09WbGS9cOW.SQqC8AlObvFpYUkpvRNeCmoFnLtgDz518GG90spcy2j7EhrgmziPG9WRKt8ZrUJ
 N2ypef4KpVTff.0awcd39tfBJVyZpy_YZiTj_2uX0mkBZB3LAK6dagTOGwXCWawgJJOGxef9Jn60
 SOXpZG3XVCD3lgqayVr.DQORoMKULj2wWVdaymN0HgRDcabZGLrMRTMEuVW_dYeixGRryvvHxMyx
 yTyfywq5.bHo_s6k.F4zoYHAcpaIHiEcFGbmcl4EPsUrRHFaKSBdRd8qTgWj0M.wSUZXL3gSvJw8
 08YhuDZzQdXCwIckqUy8WYVO9xGBpe1.NxnHN9Gtijg7dglo1jhSyrwP3vCzvDWvvYqOLfuoy1wF
 CiBw-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 04:00:07 +0000
Received: by hermes--production-ne1-5db649d989-tklgr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e237eb7b47da96b0bcc3cddf8c826d84;
          Tue, 11 Oct 2022 04:00:01 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
Date: Mon, 10 Oct 2022 20:59:59 -0700
Cc: bob prohaska ,
 Warner Losh 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MmhrS3xJQz3vqD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=l5Ry1vj9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.89)[-0.894];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-ThisMailContainsUnwantedMimeParts: N

[Summary: it looks to be FreeBSD main's EFI loader that is
at issue for armv7 RPi2B v1.1 booting not working.]

On 2022-Oct-10, at 20:04, Mark Millard  wrote:

> I put:
> 
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> 
> on a microsd card via dd and tried to boot a RPi2 v1.1. it
> hung up after:
> 
> Using DTB provided by EFI at 0x7ef6000.
> Kernel entry at 0x36a00200...
> Kernel args: (null)
> 
> (A "-" might show in the next line.)
> 
> So I tried:
> 
> FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
> 
> on the microsd card instead. It worked just fine. (Thus the
> RPi2B v1.1 is not broken.)
> 
> I did this experiment because recent testing for other
> reasons of somewhat older main vintages that I'd built
> also showed such failures. This test shows official
> builds also have the problem.
> 
> I've no clue how long this issue has been around. It
> been a very long time since the RPi2B v1.1 had been
> powered on.
> 
> 
> Note: The arm-armv7-GENERICSD images include the RPi2B
> v1.1 related RPi* firmware and u-boot, in addition to
> an installed FreeBSD EFI loader and a kernel and a
> world. Historically it was supposed to just work for
> RPi2B v1.1's. 

I mounted the main [so: 14] media to /mnt and
copied /mnt/EFI/BOOT/bootarm.efi to
/boot/msdos/EFI/BOOT/bootarm.efi .

The result makes the 13.1-STABLE media fail in
the same sort of manor as 14-CURRENT did.

So I tried an experiment going in the other
direction: copying 13.1-STABLE's
EFI/BOOT/bootarm.efi into a main [so: 14]
context that had been failing to boot.
It then boots fine.

main's armv7 EFI/BOOT/bootarm.efi is broken, at
least for RPi2B v1.1 systems.

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 04:08:47 2022
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 4Mmj2l115Yz4dmPB
	for ; Tue, 11 Oct 2022 04:09:03 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4Mmj2k0KRDz3w8x
	for ; Tue, 11 Oct 2022 04:09:01 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ej1-x62f.google.com with SMTP id qw20so28140082ejc.8
        for ; Mon, 10 Oct 2022 21:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=RhHVimv34iGT324XwdGPZFiAs1z8CGPAp34L8gAGuK0=;
        b=WVAsXw5fQ5My4TDpdlduUtYWn2HOhCPggCVyvLxwkZMcWiQVkaaTT1db41QjLupNql
         os/n0mA20i6t+K7JNHyoyVc3a7Rww2Lm2Xty0Ohycgt6DfYdu2PAFrHwkFoTjilHQoXH
         uchQ8UOO9kHnh38mitTnEwrhCIos3iNiHpIPVqPqiLQ5WpuuAg7/I7l6nOS3VQnRtlWM
         fG8YlVIHaPLV7+y4EXdaifbSGgtbpBJYFHoj8URn8J7Kd0+2hVeAr6wHRoe6O5xMwDLB
         Dmoj8phAGGfOYvGvOp82u6Sf2h5xfpve5o1SETNHI57GVawm88Wla1EXuwDNqwa1NuU4
         5tFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=RhHVimv34iGT324XwdGPZFiAs1z8CGPAp34L8gAGuK0=;
        b=v9xyEq1upmvLPv0/olfyEq00XThwmckzT+SWXrNShVUhIT6nI8+p57fF9ZmDiogpYK
         +Ec0kZUTJdFErkeNETorjD3wDd9ziP3C+s6K5KMM1uQScJWphD4JSwjSuZatN4E0Ra7/
         vhvs7TEr6hohaZw+bzqQ9LIba42mQi+RIMboffTbLx8XLJcQ5ohY+SVEDVHMtGrj5nBY
         ZKfWP6of56EXTYDzQOZxorwMsky+kR+isIAjwYcmabwQLuxzKwzw8NNsNPGxlmNSpT6k
         qzrVNj8JiwXIV+heDch1L4W94ACodeugPBgg0Kb8nlwqpU8/tAxRols6X7RUcTSBDAfw
         Sm4g==
X-Gm-Message-State: ACrzQf2L6IsCzW4VqqJ7LgAwbKqrDQSCVLF3dNZmz7cccVgcD+3FWolZ
	kzbMHyOjuJ+OFMx0hGxx0Gq1o/l7SqJCOVyGzXdpfg==
X-Google-Smtp-Source: AMsMyM6YV2MrbSejOp9rkZv1Xlma5qZ93gEo4fXYenTw9gR843nMqIi3uSn/JPvwUdpP7ANSgZkpk/vll56Cnxjt0wc=
X-Received: by 2002:a17:907:968b:b0:78d:c3cb:8b9b with SMTP id
 hd11-20020a170907968b00b0078dc3cb8b9bmr4816873ejc.252.1665461340066; Mon, 10
 Oct 2022 21:09:00 -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: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com> 
In-Reply-To: 
From: Warner Losh 
Date: Mon, 10 Oct 2022 22:08:47 -0600
Message-ID: 
Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
 is broken for RPi2 v1.1 (so: armv7)
To: Mark Millard 
Cc: freebsd-arm , bob prohaska 
Content-Type: multipart/alternative; boundary="0000000000008feced05eaba6f70"
X-Rspamd-Queue-Id: 4Mmj2k0KRDz3w8x
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=WVAsXw5f;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008feced05eaba6f70
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 10, 2022, 10:00 PM Mark Millard  wrote:

> [Summary: it looks to be FreeBSD main's EFI loader that is
> at issue for armv7 RPi2B v1.1 booting not working.]
>
> On 2022-Oct-10, at 20:04, Mark Millard  wrote:
>
> > I put:
> >
> > FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> >
> > on a microsd card via dd and tried to boot a RPi2 v1.1. it
> > hung up after:
> >
> > Using DTB provided by EFI at 0x7ef6000.
> > Kernel entry at 0x36a00200...
> > Kernel args: (null)
> >
> > (A "-" might show in the next line.)
> >
> > So I tried:
> >
> > FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
> >
> > on the microsd card instead. It worked just fine. (Thus the
> > RPi2B v1.1 is not broken.)
> >
> > I did this experiment because recent testing for other
> > reasons of somewhat older main vintages that I'd built
> > also showed such failures. This test shows official
> > builds also have the problem.
> >
> > I've no clue how long this issue has been around. It
> > been a very long time since the RPi2B v1.1 had been
> > powered on.
> >
> >
> > Note: The arm-armv7-GENERICSD images include the RPi2B
> > v1.1 related RPi* firmware and u-boot, in addition to
> > an installed FreeBSD EFI loader and a kernel and a
> > world. Historically it was supposed to just work for
> > RPi2B v1.1's.
>
> I mounted the main [so: 14] media to /mnt and
> copied /mnt/EFI/BOOT/bootarm.efi to
> /boot/msdos/EFI/BOOT/bootarm.efi .
>
> The result makes the 13.1-STABLE media fail in
> the same sort of manor as 14-CURRENT did.
>
> So I tried an experiment going in the other
> direction: copying 13.1-STABLE's
> EFI/BOOT/bootarm.efi into a main [so: 14]
> context that had been failing to boot.
> It then boots fine.
>
> main's armv7 EFI/BOOT/bootarm.efi is broken, at
> least for RPi2B v1.1 systems.
>

Can you write a brief summary so I can recreate?

And are you sure it's a booting issue and not a console issue?

I can't make heads or tails of this whole thread. I need something simple,
that's like 5 steps with version numbers.

Warner


===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--0000000000008feced05eaba6f70
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Oct 10, 2022, 10:00 PM Mark Millard <marklmi@yahoo.com> wrote:
[Summary: it looks to be FreeBSD main's EF=
I loader that is

at issue for armv7 RPi2B v1.1 booting not working.]



On 2022-Oct-10, at 20:04, Mark Millard <marklmi@yahoo.com> wrote:<=
br>


> I put:

> 

> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.i=
mg

> 

> on a microsd card via dd and tried to boot a RPi2 v1.1. it

> hung up after:

> 

> Using DTB provided by EFI at 0x7ef6000.

> Kernel entry at 0x36a00200...

> Kernel args: (null)

> 

> (A "-" might show in the next line.)

> 

> So I tried:

> 

> FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.im=
g

> 

> on the microsd card instead. It worked just fine. (Thus the

> RPi2B v1.1 is not broken.)

> 

> I did this experiment because recent testing for other

> reasons of somewhat older main vintages that I'd built

> also showed such failures. This test shows official

> builds also have the problem.

> 

> I've no clue how long this issue has been around. It

> been a very long time since the RPi2B v1.1 had been

> powered on.

> 

> 

> Note: The arm-armv7-GENERICSD images include the RPi2B

> v1.1 related RPi* firmware and u-boot, in addition to

> an installed FreeBSD EFI loader and a kernel and a

> world. Historically it was supposed to just work for

> RPi2B v1.1's. 



I mounted the main [so: 14] media to /mnt and

copied /mnt/EFI/BOOT/bootarm.efi to

/boot/msdos/EFI/BOOT/bootarm.efi .



The result makes the 13.1-STABLE media fail in

the same sort of manor as 14-CURRENT did.



So I tried an experiment going in the other

direction: copying 13.1-STABLE's

EFI/BOOT/bootarm.efi into a main [so: 14]

context that had been failing to boot.

It then boots fine.



main's armv7 EFI/BOOT/bootarm.efi is broken, at

least for RPi2B v1.1 systems.

Can you write a brief summary so I can recreat=
e?

And are you sure it&#=
39;s a booting issue and not a console issue?

I can't make heads or tails of this whole thread.=
 I need something simple, that's like 5 steps with version numbers.

Warner



=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--0000000000008feced05eaba6f70--

From nobody Tue Oct 11 05:50:07 2022
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 4MmlHX3Fwdz4dxxb
	for ; Tue, 11 Oct 2022 05:50:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4MmlHW3GQ1z4677
	for ; Tue, 11 Oct 2022 05:50:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665467413; bh=pQ/Rm1TbDzz0F/hvPKZHxFWQ5xCoLfz4mIUrOC1B+Io=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uiSipAtHnIzxamq5L5oIC3GPK+zkHlqnlOdZuIyhpxbWiqCSmtNZma6VehvsPD8IJj1SCL4FXYJ3JKUgvI5uyS59c6vyKBcUyJTsulgYxRg2h6oNvkXQxFbSbzaT3BFayZt43U3hjUc4zXh+rgB/a7j/nG6b65R+9YTWdiRwBGbOE9tL0JbwbnDzZFGi8UUzdqn+Ko3h5sQmHklgp6Avb1zybt3h36pufCo7v1uAUh/zaY3mTWjLnhoGATUmdxtPVL21W5WLXq5q9ppFB5SwYGPbOOBeB0mjBiMaBo4h1gdA94xxHjFu9SyTCxbmN4Aa4LCptrnNySObC+3Qt+8DgA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665467413; bh=GFQDCthW/Lh+x4M+t8OIT+u6VlIjqUK0XDCWoBA7u5O=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ayYwiWnL74njM4JXtia/MoZpUMN/8R4YC8w4xZzDTYgp9rhqmVMbSS2MSshltRneb6e+RBU2G2noJ11D7z3Aze7dTZULDUY+hXF6AEnsp9/94oOmTyqNRrwX1jV/C6GyCj28CD+Yu32tkoQg9hqgJNm01EJa8QTe6BxJsZjqtIhw/9GxvQJVyC8ppU/fDzsAiW3d7OCDGc31e4nJCKtszEwJ1HOThazBkEGG0mQAQrxUPGGh9ZB1fE8VwknK0wnfXM2cn3eqpvFM+Lo3IbKACUJcbicw6a8+iWzjnOSlXN1qOB+Yj3Oh+U/2qfsTJiush93qPUd1qWxmb4noy22KXg==
X-YMail-OSG: _FpJrkQVM1n4ROmvjm9ht2kTBycgp5RT.QT3yItRg_VazEe2R4D7ZcS.uRaxISa
 OGvcBoFMdyOHrkDqN7oeWtDD4Mzku9bMqQMIwcwttQXa_Lj7PwuzvNZpfPtUnksFTAg8BBiWnkup
 HFPoRduC7nyN7_yBgg.oxmGGPHucrM7BrARsD_YIBnQGp.tPc42fOX7TdjPnukMzvoHPYC8QTa9.
 tJptVBhwZHN3ROtGXBwKAd03Py_9P3zxilG4DxOYPy.ikbkQlLJJ10iXlI82MqFQziH9Brui1T6O
 eSoLo3dU15MlKNtPyCIkOFgXyaCqz1QhQihWFuuOPtn9tCBq8SeH7cMsJkFgrCEyqCwrYWzlqS0x
 XREDGjYW3rl9YqVLRqAp_WzWJxi0g4MPnKKwyAeWv0cBJqoFtmCVIcoSXoECX9j8qe0IrRW6Sbo6
 cR4Js87fvz5.3Rb.uPkebACSBQhBtso2qrdE_MiWKhDd0EKS8OleyhOTk8K46eLQCfG0KlGP.Eio
 QbSNJkwbcA57pfZqwEaI7xQQys8I6zsouXBc_KYOGQQCUV_y1FuqN3gmBvId7bCDgxbsO8pN.1kv
 A0lRYFVXC432anVSOIHRHHvyJUvTOIEbIpO_rSLk6Yw51ByGB1kyd8WEwQHrhgwLEnbWKQPE4VqL
 YutDD22PeIh9b6old2rrjeUwLUry1yiyMQYu9uYNuhfZ4.jIcDdZ1o7K_H2EySBRJHpzTXFRUBWx
 o8eD9dJk0tqGjjJ2JmpzFwHrcbVat613Iz1vEQ0i2VfhXneI9xRUUPYjApIZ9.UnlWgRD0U6oayI
 5Yh0y8jrIcXYIheV.ShGDwcQpsju_XPvPFsaQrRFzKedn0V6c4acgXNIMqBNac2DbH9DNdD8Ydkz
 wNM_3l2rse2E4H_3XiHiPZKIr7xwH3YglveZ_mmS9X8rXRHCXb3y43bz_jLa04jHkQVFgmuCk_so
 qY2gSfAGzBlKiphpS41F4J7zEARM3YkqX04fC3f_QLTX5h1oXXwwo4O7Qzdxceqfb5yoNgC67JKb
 fCZJpVRC7dcN0y4Jnni4AqbuAV3Ji3motYOe8Mgdu3QtZejIgZ7eY7j52dK6L86sLeHumzib.tpY
 Tw1ss1qL1t4Qr9hV6.GiO5KgXvS.I59LrV27NxZkO1zDEOGzVIiVnVAHfmVuRWy7RZarQS49W5XO
 PvJ1UW6KzXQXfZk08gELRmMqnQrtIeqlP_B9rLkZNKL.LiVbjS6yHbunWCQoXtBhAqV4zPZ4KHrg
 STPORpWLWBVO7.9MKUhk_hcL7tzjCePLNbreDbyMMjg7fJYvoBn5EHACNeGYH7xLzTrVHwkBIXwl
 tIgfoV53NZjWs_rQvrGVaEPmduEkXaa8bE0woKQWB7jkO4EzDu.8S2kRMTauNq1Wl1jvWBdYAYKi
 Du6rurjqjkoH4j8BaM7hExn4lHEsJD93f.387kQMSvH2HjuA40RVZLF9EGYs.UZjwddt1vSsFaXl
 lgWAz47H9IQuWbATCLkHPpzoSlIKDqjPW.qTOb9Owt0qfpge3QkDEduuJuOnvjZbn4WqHkvVjRO_
 dYR0aWc_qUc4I6TPuJVmsbdudZPj5qrGka9IZ1HzppYn._9EbqYFA1dRNo2ylJ6TYsq9wRYXZ_iv
 mj6.xHBh1EupGKWjOc3x_NmvTI1Dvt1qP7aktuKHNEkpveNipdfBOUZzYl86BHTEF.jSdhZc711Y
 ElVG7ih1eAMLOkF2h7fCpIVaB6QUMlvn3wfDpRhB5NAW347bEiklsGMQkk.rNyubWFoO7xI5vi2_
 oqcwWoArB4R4_L7WvQEn98hhgTa.yipWesgsB.jq_2ubPEypOnwvQSlKuGD8YId5WuezD6SQS69k
 nyNdCzN9210f565n2eEPx1uzKYHqr_mZRApa_ZB2I8..GGx2zDgZEaFNEWz8krog._DyRyFTO3FF
 os7bH8W3t2D25SvPt8OZSXVtOs43gHAzn6HVy.FegOSrMkEDHBT0pfsGJXyvsgQaA7UIy0IXg9y8
 6gJ9o39nnE9KbXgo9dOyiDW4yAnIjzPo6UQREHjEGCEGS5PDCYrsIQCM8.CKeJT01Kk3ipwDXK0d
 _I0HwFG4GWs6R6wQDPP5iv9896MJWHpftR02pT3WEM6StiFsilW2rLh5ubdiv5ahWuepsx4xs6hP
 5fzS8tbvNatOslF7aYIggAdEt5fV2qlaA3wpbvhqXaJEtNbvZ1_KYg8AZ7a3NH9YX74gwwfb421o
 A_F9WM2MP9_YnwVr8uVnfS0ovAAgEJlKVSrqVN6yu_V10kcNjshCx1lL97KQ0HG_2tOXljCSKpu5
 E
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 05:50:13 +0000
Received: by hermes--production-ne1-5db649d989-rdwc8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 79109e3134296a6433abcfb84f0ff88c;
          Tue, 11 Oct 2022 05:50: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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: 
Date: Mon, 10 Oct 2022 22:50:07 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MmlHW3GQ1z4677
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=uiSipAtH;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-10, at 21:08, Warner Losh  wrote:

> On Mon, Oct 10, 2022, 10:00 PM Mark Millard  wrote:
> [Summary: it looks to be FreeBSD main's EFI loader that is
> at issue for armv7 RPi2B v1.1 booting not working.]
>=20
> On 2022-Oct-10, at 20:04, Mark Millard  wrote:
>=20
> > I put:
> >=20
> > =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> >=20
> > on a microsd card via dd and tried to boot a RPi2 v1.1. it
> > hung up after:
> >=20
> > Using DTB provided by EFI at 0x7ef6000.
> > Kernel entry at 0x36a00200...
> > Kernel args: (null)
> >=20
> > (A "-" might show in the next line.)
> >=20
> > So I tried:
> >=20
> > =
FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
> >=20
> > on the microsd card instead. It worked just fine. (Thus the
> > RPi2B v1.1 is not broken.)
> >=20
> > I did this experiment because recent testing for other
> > reasons of somewhat older main vintages that I'd built
> > also showed such failures. This test shows official
> > builds also have the problem.
> >=20
> > I've no clue how long this issue has been around. It
> > been a very long time since the RPi2B v1.1 had been
> > powered on.
> >=20
> >=20
> > Note: The arm-armv7-GENERICSD images include the RPi2B
> > v1.1 related RPi* firmware and u-boot, in addition to
> > an installed FreeBSD EFI loader and a kernel and a
> > world. Historically it was supposed to just work for
> > RPi2B v1.1's.=20
>=20
> I mounted the main [so: 14] media to /mnt and
> copied /mnt/EFI/BOOT/bootarm.efi to
> /boot/msdos/EFI/BOOT/bootarm.efi .
>=20
> The result makes the 13.1-STABLE media fail in
> the same sort of manor as 14-CURRENT did.
>=20
> So I tried an experiment going in the other
> direction: copying 13.1-STABLE's
> EFI/BOOT/bootarm.efi into a main [so: 14]
> context that had been failing to boot.
> It then boots fine.
>=20
> main's armv7 EFI/BOOT/bootarm.efi is broken, at
> least for RPi2B v1.1 systems.
>=20
> Can you write a brief summary so I can recreate?

This is an independent report from the exchange
with Bob P. about his overall problems. This has
its own subject text. There is not much to this
specific report. Messages with other subjects
should be ignored for this issue. USB media is
not involved here: a microsd card is sufficient
to see the problem.

> And are you sure it's a booting issue and not a console issue?

No clue for your distinction. But, being serial console
based until ssh is possible for my context, I classify
serial-console-broken as a booting issue. (For example,
not being able to identify the DHCP address assigned
if it did make it that far.)

It may be that the snapshots need to be modified to deal
with EFI loader changes --instead of changes to the loader
needing to be made. I'm not trying to specify which.

> I can't make heads or tails of this whole thread. I need something =
simple, that's like 5 steps with version numbers.

The images listed in the above are the official snapshots.
I've no way to be more explicit than the file names of the
official snaphot images. The use of 20220930 (date) instead
of 20221007 for main's snapshot was an accident and I could
try the one with the more recent date if needed.

If you have RPi2B v1.1 (so: armv7) access, just try to boot:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img

via serial console usage, no video connection present. (I
did not try a video connection as that is not my type of
context.)

To make it work for that context, replace the EFI/BOOT/bootarm.efi
by the one from:

FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img

and then retry booting the result.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 06:13:48 2022
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 4Mmlps0rk9z4f105
	for ; Tue, 11 Oct 2022 06:13:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mmlpq6npSz49b6
	for ; Tue, 11 Oct 2022 06:13:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665468834; bh=W20HivK0FojZTqoAOYwsSqakVv6WCI1xi9nJkkMWEnM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gi5saW0dYpCvyvEgNjvNKZkVk/wwDRAk6c5lAPBNfDssvbltnuw2JVVjIEwEqFOZIGW9331NopE20LghvQFiYOW1SmY/gyqjJxGC5kpoOkgi99rvy7iG9+wo2V0QdBhRj3lLcOllE1lCElxfyo9kD0Agv+62uuwZRLu03M/UFADbqEZCWzKgU8kVJEi+SEHRPZZRK02gj9GI6OkHcc/V+92thP6xiTpoLE2f5o/1N7DWLk8SgRiR+aPKs49r4IFqXLElVDwZjGDjePl2QmRf3wCTIOOpBh+ftPdTsglI+BKk1vtw43rHXmIOAZn2jb4qHnBfDOzzSi2yqcVZCSoY1A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665468834; bh=HbKoSWAIbOAKjduGuJbnp5gU2wnhzPo493pXyL53Qin=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ALMDjFXmLcxckTHXXuwNxvAvGQ5HjXlt8+7xGax3suxFXou35Nc8rNN+sPZY5oULBEnW99KVtD9OEuQo7NTnG2XZAgckb1bBhBDyWxTunIbfKx42/gmB8zexA9oBJgZ8n00V3x+y0i1VA450C4pjjiTMsBXrWG8D/GOphEi+HNZAo5DTx+7KgKBy9UiTukTCI3dye0ZOGSesACpg6mj6R/f4X1rx0mQ11bJ5hZuyKVQdB3RjSRzgRnSjwL7iRO7/7HK6aEkqAtzV4uFG5/detCR4QHnDamNj6Ado6zGryZDUKPihmZUbeXqTOgHBcrHfXe3g+rdV9GLvdUYMz+FdoA==
X-YMail-OSG: 4tkno90VM1mkyuQ.0Mfv4_sI6eekDwzXtQhMP7sSxCkOVZsXmmJV_d2py3h520P
 vtPd2d7dmtUApBHtdI681x9xOFZaUkNu4BuJeovbXI4n52l2wSSknpQmV5g64SAPQFiBFtfd_Rnu
 BN9NTcUfiVbn6POtUL1Y1yt8DYveNJ0.DfohrSGAycWBZr4Orzgze7vDG4mbdg_5253kV01q6FBE
 BkdW1txrOjcHh00SjEoAbmdsXZ9LLmj7.9zwhmCnf7XkKDTqkKATPbD6lqij6RVH6esjd3tRFZte
 LDOPmWmsVyf6RegjG0dF.LXE6H4DQfKT0h.hAQw9qnccDuCXcSbuyxMCqHnX1jpxjZyo8ChuTY7L
 W8QJtTJkZF9ZSh8O2k5Xex6goTW2z_sYcrFE3ad1IzE64NdS4YExgfcaGzG6UUWEfPEikBXn_bO9
 Qo0nNZqLz_kBcjjQy79HQROdtnGeOU_OSzn.9tjWBd1397CGrYR4DZrY45YThVFYhx3VSgPvWsrC
 mL_cBq6H3.QgWJ0OeomWAeeO_YeWhJQ16z_3i1XmKYsLMocq9j55qeiaNUzkNfcUuEkSnzGOCgh6
 C7HT9_WoLOkCN8hnLzRH6Bthg5f80vfv50kTg7gzVHiLZ4tzp7.Lpn.RbMuq58asMRaRtsG5p.Pv
 g6rUkg0h28VDjn6hnvw_CY89ty19nndyf1krzKnqeHNe6KtLGzWKUTjeCEQ38QT3is27bn3X0O7z
 GPm8CCbGGoD8aGAZWH2LYrujElGP4Xqe5gZ07RMeWRpIFhvG8GfbvVFQl8XiXCIbo1qJbXRrjV.C
 7HurKlGUcDy7VcuCY_NNKJpqSlfkH5W4XexEmnDzIdI1w8ovYmfXS0APySqyJEzOOZzvNyWQUDtk
 a_dHmffF1hpixxrl0QUQk7XuEBL1uvQIJ82BwzuJX8ES5neAGTQ3ACoSXyvPpWMdPxYA977oWlLC
 WMlIsRmg7EXeYZh6qavzHdi.XXQdSIkfVVRorayosGx5pOfLi_Ex4euEBBouJclgB6KmkpCHk8lA
 O1wGQUpyZ7ZjKh1Xte1MORwx8k9Pa7EwUjOeQBNwtEHUwI7sClj792g3RsovBeupeNlKnB7o.34Z
 80JE9XMi1L3rrsQNwwA7S6lZrkWxUtiKaxmg156OT6ORLiaoD7.X.6gyXTgEdJb7gLKYCM6q_bER
 91PIzrJaJP_LG84IS8fWLkuHjPj2oEetXcL9dGrkEYSfVBZEcVBtflvPB1jwvpIZ5Y1gN4ksUA_u
 O_kho9ztJMt340UksNDRwOQsfuFGsIFPhXvYBeXn48q16GXPUcfXpFvGMhI5K_NYNnECe0PJajoF
 eWx2M5bQVo03ssrrkp5P0V3Bm92a_UEydYAGW17m8cuNGsSzkDGvJr97C3i663ugqBmdfsSoRr0Y
 eRYKHJA5B4a9B1XEFerjbvHErSmLdfp2nF8Hk.209XCZ2nxjlY3Y75IhiH9RbLck0xzr5bbfkbtp
 1WAzsiMfGLFmDEo0we53HdqZ3q9_Oh1OXIYQ509sVKbKVHHF.olpriZCshICF5H.yY.jjo_RknLJ
 0.pGCZyESt_eN5KU5apWDMBD27ofvZccNfaGQcD6BrF5uwIxN0BV0WG.jzTTic9HqB2JTQ_f5OoB
 RkZCKGuPo85iX2AdcXOmKP9e8.In.ghNZlj8shuLThsmXACSGeGoBr2DyvSwVNUbvLhrPC6umlvW
 fhrq_ESRIj4pLgnexmcXGid25gO4tS2sdpK0IPVGCp8evHzDVSaVFklws_IWiRXEOgLD6oRGUodg
 y4iR6Ur1zDhM.KgJxxO.IAvopyq3oRZ79sUr3F4rANKxhF0.uUhBJI1QZi6tNCpIVPPd_zcbXpaQ
 u5aF53xBSlNoG357lPdKB1yGm4yGoKTLcwuSPbZrN8qZ2aDMPoSnpO4WhEdSePJPk3xpTnpNsYVe
 ky3RAS2Q0atOlej0xe3TN.thQsKspvOzIYAviAj1sl0JBfGWjei_pxOWnaK8xCdd6voccl.4PoOw
 QOAeREqgSxjSTGwKwyc4JTI8us9ePnkhRcdLv1v6vDSFtjAzBhjXJ9Z90zH3fKNtsfwpbkmdqwOt
 4Q.6452UKZ9eGsi.irRDQA11Ee.qSuTHHPQwkoBMDSOQEs7h1lKRWtdfXebmR2zYN.lt7S6rbeBr
 W9TYEyuLargS16Y3k0zpsgtJhh4zWYDteqJkeJD79wo8WsDiNy.AJzpBQFSHj1YR9GASbBKQJLit
 d.qtPdpVN0UpSXx1jANxg4x0Tas9IhE2gZR4h6Itf.f8hLwUswR4jwsvs8nJrHc4bsDz1M5.3M4r
 3
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 06:13:54 +0000
Received: by hermes--production-gq1-75cfcccdb-rwsc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 25330bc66af6e59f0391167b29467360;
          Tue, 11 Oct 2022 06:13:49 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: 
Date: Mon, 10 Oct 2022 23:13:48 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mmlpq6npSz49b6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=gi5saW0d;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-10, at 22:50, Mark Millard  wrote:

> On 2022-Oct-10, at 21:08, Warner Losh  wrote:
>=20
>> On Mon, Oct 10, 2022, 10:00 PM Mark Millard  =
wrote:
>> [Summary: it looks to be FreeBSD main's EFI loader that is
>> at issue for armv7 RPi2B v1.1 booting not working.]
>>=20
>> On 2022-Oct-10, at 20:04, Mark Millard  wrote:
>>=20
>>> I put:
>>>=20
>>> =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>>>=20
>>> on a microsd card via dd and tried to boot a RPi2 v1.1. it
>>> hung up after:
>>>=20
>>> Using DTB provided by EFI at 0x7ef6000.
>>> Kernel entry at 0x36a00200...
>>> Kernel args: (null)
>>>=20
>>> (A "-" might show in the next line.)
>>>=20
>>> So I tried:
>>>=20
>>> =
FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
>>>=20
>>> on the microsd card instead. It worked just fine. (Thus the
>>> RPi2B v1.1 is not broken.)
>>>=20
>>> I did this experiment because recent testing for other
>>> reasons of somewhat older main vintages that I'd built
>>> also showed such failures. This test shows official
>>> builds also have the problem.
>>>=20
>>> I've no clue how long this issue has been around. It
>>> been a very long time since the RPi2B v1.1 had been
>>> powered on.
>>>=20
>>>=20
>>> Note: The arm-armv7-GENERICSD images include the RPi2B
>>> v1.1 related RPi* firmware and u-boot, in addition to
>>> an installed FreeBSD EFI loader and a kernel and a
>>> world. Historically it was supposed to just work for
>>> RPi2B v1.1's.=20
>>=20
>> I mounted the main [so: 14] media to /mnt and
>> copied /mnt/EFI/BOOT/bootarm.efi to
>> /boot/msdos/EFI/BOOT/bootarm.efi .
>>=20
>> The result makes the 13.1-STABLE media fail in
>> the same sort of manor as 14-CURRENT did.
>>=20
>> So I tried an experiment going in the other
>> direction: copying 13.1-STABLE's
>> EFI/BOOT/bootarm.efi into a main [so: 14]
>> context that had been failing to boot.
>> It then boots fine.
>>=20
>> main's armv7 EFI/BOOT/bootarm.efi is broken, at
>> least for RPi2B v1.1 systems.
>>=20
>> Can you write a brief summary so I can recreate?
>=20
> This is an independent report from the exchange
> with Bob P. about his overall problems. This has
> its own subject text. There is not much to this
> specific report. Messages with other subjects
> should be ignored for this issue. USB media is
> not involved here: a microsd card is sufficient
> to see the problem.
>=20
>> And are you sure it's a booting issue and not a console issue?
>=20
> No clue for your distinction. But, being serial console
> based until ssh is possible for my context, I classify
> serial-console-broken as a booting issue. (For example,
> not being able to identify the DHCP address assigned
> if it did make it that far.)
>=20
> It may be that the snapshots need to be modified to deal
> with EFI loader changes --instead of changes to the loader
> needing to be made. I'm not trying to specify which.
>=20
>> I can't make heads or tails of this whole thread. I need something =
simple, that's like 5 steps with version numbers.
>=20
> The images listed in the above are the official snapshots.
> I've no way to be more explicit than the file names of the
> official snaphot images. The use of 20220930 (date) instead
> of 20221007 for main's snapshot was an accident and I could
> try the one with the more recent date if needed.
>=20
> If you have RPi2B v1.1 (so: armv7) access, just try to boot:
>=20
> =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>=20
> via serial console usage, no video connection present. (I
> did not try a video connection as that is not my type of
> context.)
>=20
> To make it work for that context, replace the EFI/BOOT/bootarm.efi
> by the one from:
>=20
> =
FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
>=20
> and then retry booting the result.

I've tried the snapshot:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20221007-b05b1ecbef0-258483.img

and got the same boot failure when it is what is on the
microsd card (no EFI loader replacement).

I got access to a display and HDMI cable and tried booting
with it connected. The last text it displays matches the
last text on the serial console:

Using DTB provided by EFI at 0x7ef6000.
Kernel entry at 0x33800200...
Kernel args: (null)
-

(ignoring, possibly, the "-").


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 13:17:39 2022
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 4MmxD04jkdz4fjH4
	for ; Tue, 11 Oct 2022 13:17:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b])
	(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 4MmxD00CZYz3fyh
	for ; Tue, 11 Oct 2022 13:17:51 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x52b.google.com with SMTP id s2so20109729edd.2
        for ; Tue, 11 Oct 2022 06:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=vT2IZgNJFG0p1QgZ3Xi6y0P3jPy5yUUiCz6bkawUAI0=;
        b=rDaUwXIPuKowxJ+IbnVlGDUKTPhq9ZeMmT9lVHU/M49eUsvRYj2kxCyA76cESABrJ/
         kY226lHFKNfySGCNX4FNbh8OsrF/IJPQrirL3Q1v6jcwV/8xsvmcIbBl/g1ml5NkV6Wg
         wQ2QgcWLU20UiM90l8646BufRBbSQ9a/lAsvOH46uhfjGgrTbHyJyB0KD109j1iXVbdF
         ehPvA6bFh3MW9MEmyxHHaexNMhRIVCrpZVQYKt1t1+7ewr6oZjvXRoB0u6YoneJhR4mv
         Krob2ZOPxDfRZLLuoX0/O9iKw97j0NiJ+45tkpJeT0xMZlwOWhqT/bfb3UoZCNnQwzu/
         5y1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=vT2IZgNJFG0p1QgZ3Xi6y0P3jPy5yUUiCz6bkawUAI0=;
        b=LXxAXGuhQdI5GWU+wYE6aNmbkdrf3EJSvOPzXc7HZF7WmlGdtYFKjWYQyEZuiQZx4d
         aKXBUfGUggyvkMJEjNEIZyM4ifcDzxr0Noy+D9gswjiDkMqqCnkiEqz6iROZC3EIsRhM
         yIHfUvrWOojfxKpl1LvndPAiCwtHaalT54EQrWv1hmNRBZwxeamoY9AzI7p+6hgprK1d
         Kr6nzEEswxQ+5/398SDv7ezjqwLUzbLiC8QTbwnTxcpKlFzy00nWSJxibHE++WISiAaq
         i94s7Xdn5GprQ0ZHUEF46A54bIFHE5V38DSKLd5j7DiffW2jOpFiY/hPqOvcs5cO6pDR
         aUGw==
X-Gm-Message-State: ACrzQf0lyQLTStrcWTa1XxEvTbatJmTEdIM5GOEFXQP9dagFs1lt6J2o
	2KPVx3hjCuSroynfxYfcdpCDso3lVb85pRSFAeolIw==
X-Google-Smtp-Source: AMsMyM6+G1KupufOZUZ5xUVJh72PVdqcRNubxiBq24cxAAGLtUnp+CyJCRIeYjL/Klh5R4F9JEa/QgTjEg3LDa9Y6yg=
X-Received: by 2002:a05:6402:1d86:b0:457:e84:f0e with SMTP id
 dk6-20020a0564021d8600b004570e840f0emr22579714edb.241.1665494270476; Tue, 11
 Oct 2022 06:17:50 -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: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
  
 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 11 Oct 2022 07:17:39 -0600
Message-ID: 
Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
 is broken for RPi2 v1.1 (so: armv7)
To: Mark Millard 
Cc: freebsd-arm , bob prohaska 
Content-Type: multipart/alternative; boundary="0000000000005e164505eac21a65"
X-Rspamd-Queue-Id: 4MmxD00CZYz3fyh
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=rDaUwXIP;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52b) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000005e164505eac21a65
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 10, 2022 at 11:50 PM Mark Millard  wrote:

> On 2022-Oct-10, at 21:08, Warner Losh  wrote:
>
> > On Mon, Oct 10, 2022, 10:00 PM Mark Millard  wrote:
> > [Summary: it looks to be FreeBSD main's EFI loader that is
> > at issue for armv7 RPi2B v1.1 booting not working.]
> >
> > On 2022-Oct-10, at 20:04, Mark Millard  wrote:
> >
> > > I put:
> > >
> > >
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
> > >
> > > on a microsd card via dd and tried to boot a RPi2 v1.1. it
> > > hung up after:
> > >
> > > Using DTB provided by EFI at 0x7ef6000.
> > > Kernel entry at 0x36a00200...
> > > Kernel args: (null)
> > >
> > > (A "-" might show in the next line.)
> > >
> > > So I tried:
> > >
> > > FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
> > >
> > > on the microsd card instead. It worked just fine. (Thus the
> > > RPi2B v1.1 is not broken.)
> > >
> > > I did this experiment because recent testing for other
> > > reasons of somewhat older main vintages that I'd built
> > > also showed such failures. This test shows official
> > > builds also have the problem.
> > >
> > > I've no clue how long this issue has been around. It
> > > been a very long time since the RPi2B v1.1 had been
> > > powered on.
> > >
> > >
> > > Note: The arm-armv7-GENERICSD images include the RPi2B
> > > v1.1 related RPi* firmware and u-boot, in addition to
> > > an installed FreeBSD EFI loader and a kernel and a
> > > world. Historically it was supposed to just work for
> > > RPi2B v1.1's.
> >
> > I mounted the main [so: 14] media to /mnt and
> > copied /mnt/EFI/BOOT/bootarm.efi to
> > /boot/msdos/EFI/BOOT/bootarm.efi .
> >
> > The result makes the 13.1-STABLE media fail in
> > the same sort of manor as 14-CURRENT did.
> >
> > So I tried an experiment going in the other
> > direction: copying 13.1-STABLE's
> > EFI/BOOT/bootarm.efi into a main [so: 14]
> > context that had been failing to boot.
> > It then boots fine.
> >
> > main's armv7 EFI/BOOT/bootarm.efi is broken, at
> > least for RPi2B v1.1 systems.
> >
> > Can you write a brief summary so I can recreate?
>
> This is an independent report from the exchange
> with Bob P. about his overall problems. This has
> its own subject text. There is not much to this
> specific report. Messages with other subjects
> should be ignored for this issue. USB media is
> not involved here: a microsd card is sufficient
> to see the problem.
>
> > And are you sure it's a booting issue and not a console issue?
>
> No clue for your distinction. But, being serial console
> based until ssh is possible for my context, I classify
> serial-console-broken as a booting issue. (For example,
> not being able to identify the DHCP address assigned
> if it did make it that far.)
>

So it's not a booting issue (where the loader can't find the disk,
can't load the kernel or loads it such that it hangs), but a default
console issue. That's a lot easier for me to help solve.


> It may be that the snapshots need to be modified to deal
> with EFI loader channges --instead of changes to the loader
> needing to be made. I'm not trying to specify which.
>

Loader should likely change. There was what may have been
an unwise change to the default console a while ago and it's
taken this long to see the problem.


> > I can't make heads or tails of this whole thread. I need something
> simple, that's like 5 steps with version numbers.
>
> The images listed in the above are the official snapshots.
> I've no way to be more explicit than the file names of the
> official snaphot images. The use of 20220930 (date) instead
> of 20221007 for main's snapshot was an accident and I could
> try the one with the more recent date if needed.
>

The change was made in late August that I'm thinking of, so if you could
find a
snapshot from early August July that would be a useful data point:

commit df065f699f1ff819bb9607c44a6754275ab335ed
Author: Warner Losh 
Date:   Fri Aug 26 15:46:33 2022 -0600

    stand: More sensible defaults when ConOut is missing

I think this should be backed out and we should use a different hueristic
when we don't know.

If you have RPi2B v1.1 (so: armv7) access, just try to boot:
>
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>
> via serial console usage, no video connection present. (I
> did not try a video connection as that is not my type of
> context.)
>

I don't know if I can find that... I bought one or three years ago, so
there's a good
chance... if it isn't being my name server...  I'll see if I can recreate
it in qemu
as well, since I think it emulates RPi these days. I need armv7 for the
stand
test suite I'm writing...


> To make it work for that context, replace the EFI/BOOT/bootarm.efi
> by the one from:
>
> FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
>
> and then retry booting the result.
>

OK. That's a fairly clear set of instructions.  I'll try to work that into
my
schedule.

Warner

--0000000000005e164505eac21a65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 10, 2022 at 11:50 PM Mark=
 Millard <marklmi@yahoo.com>=
 wrote:
On 2022-=
Oct-10, at 21:08, Warner Losh <imp@bsdimp.com> wrote:



> On Mon, Oct 10, 2022, 10:00 PM Mark Millard <marklmi@yahoo.com> wrote:

> [Summary: it looks to be FreeBSD main's EFI loader that is

> at issue for armv7 RPi2B v1.1 booting not working.]

> 

> On 2022-Oct-10, at 20:04, Mark Millard <marklmi@yahoo.com> wrote:

> 

> > I put:

> > 

> > FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258=
315.img

> > 

> > on a microsd card via dd and tried to boot a RPi2 v1.1. it

> > hung up after:

> > 

> > Using DTB provided by EFI at 0x7ef6000.

> > Kernel entry at 0x36a00200...

> > Kernel args: (null)

> > 

> > (A "-" might show in the next line.)

> > 

> > So I tried:

> > 

> > FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-2526=
53.img

> > 

> > on the microsd card instead. It worked just fine. (Thus the

> > RPi2B v1.1 is not broken.)

> > 

> > I did this experiment because recent testing for other

> > reasons of somewhat older main vintages that I'd built

> > also showed such failures. This test shows official

> > builds also have the problem.

> > 

> > I've no clue how long this issue has been around. It

> > been a very long time since the RPi2B v1.1 had been

> > powered on.

> > 

> > 

> > Note: The arm-armv7-GENERICSD images include the RPi2B

> > v1.1 related RPi* firmware and u-boot, in addition to

> > an installed FreeBSD EFI loader and a kernel and a

> > world. Historically it was supposed to just work for

> > RPi2B v1.1's. 

> 

> I mounted the main [so: 14] media to /mnt and

> copied /mnt/EFI/BOOT/bootarm.efi to

> /boot/msdos/EFI/BOOT/bootarm.efi .

> 

> The result makes the 13.1-STABLE media fail in

> the same sort of manor as 14-CURRENT did.

> 

> So I tried an experiment going in the other

> direction: copying 13.1-STABLE's

> EFI/BOOT/bootarm.efi into a main [so: 14]

> context that had been failing to boot.

> It then boots fine.

> 

> main's armv7 EFI/BOOT/bootarm.efi is broken, at

> least for RPi2B v1.1 systems.

> 

> Can you write a brief summary so I can recreate?



This is an independent report from the exchange

with Bob P. about his overall problems. This has

its own subject text. There is not much to this

specific report. Messages with other subjects

should be ignored for this issue. USB media is

not involved here: a microsd card is sufficient

to see the problem.



> And are you sure it's a booting issue and not a console issue?



No clue for your distinction. But, being serial console

based until ssh is possible for my context, I classify

serial-console-broken as a booting issue. (For example,

not being able to identify the DHCP address assigned

if it did make it that far.)

So it'=
s not a booting issue (where the loader can't find the disk,
=
can't load the kernel or loads it such that it hangs), but a default
console issue. That's a lot easier for me to help solve.
<=
div>=C2=A0

It may be that the snapshots need to be modified to deal

with EFI loader channges --instead of changes to the loader

needing to be made. I'm not trying to specify which.

Loader should likely change. There was what may have been=

an unwise change to the default console a while ago and it's=

taken this long to see the problem.
=C2=A0

> I can't make heads or tails of this whole thread. I need something=
 simple, that's like 5 steps with version numbers.



The images listed in the above are the official snapshots.

I've no way to be more explicit than the file names of the

official snaphot images. The use of 20220930 (date) instead

of 20221007 for main's snapshot was an accident and I could

try the one with the more recent date if needed.

<=
/div>
The change was made in late August that I'm thinking of, so i=
f you could find a
snapshot from early August July that would be =
a useful data point:

commit df065f699f1ff819bb9607=
c44a6754275ab335ed
Author: Warner Losh <imp@FreeBSD.org>
Date: =
=C2=A0 Fri Aug 26 15:46:33 2022 -0600

=C2=A0 =C2=A0 stand: More sens=
ible defaults when ConOut is missing

I think t=
his should be backed out and we should use a different hueristic
=
when we don't know.

If you have RPi2B v1.1 (so: armv7) access, just try to b=
oot:



FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img


via serial console usage, no video connection present. (I

did not try a video connection as that is not my type of

context.)

I don't know if I can fin=
d that... I bought one or three years ago, so there's a good
=
chance... if it isn't being my name server...=C2=A0 I'll see if I c=
an recreate it in qemu
as well, since I think it emulates RPi the=
se days. I need armv7 for the stand
test suite I'm writing...=

=C2=A0

To make it work for that context, replace the EFI/BOOT/bootarm.efi

by the one from:



FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img



and then retry booting the result.

OK. =
That's a fairly clear set of instructions.=C2=A0 I'll try to work t=
hat into my
schedule.

Warner
=



--0000000000005e164505eac21a65--

From nobody Tue Oct 11 15:26:48 2022
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 4Mn04z1Ykhz4dhPq
	for ; Tue, 11 Oct 2022 15:26:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147])
	(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 4Mn04y0HRlz3skf
	for ; Tue, 11 Oct 2022 15:26:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665502015; bh=lV776yRUQoVgNStRoIz9tnXvGguILzITfIddKZtqiAk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pX0on88J5pNJvI0ZNcPebXM+xymyrZFti8bOalgHqjxkr2bjFzjxC5T1ePacnvn0+n05goFZ3oNtJ9Xwoc++O1Q3CTnzk/eIURz7LA0UP5V/H1zvGADKwbvlX9Zm/xgdUHszIHTLSY6tWUSNGRzXav2ESV5IJh1woeGmTqGgUIcJvVf5SD0uyYcqhREd+GQMaP8q08pL9tPjyyw0GAQGcfIj/aQm6WViR2in7/YiIfa+Fsfv5uiMavguriuejMGom7UvMYnGU9E0wgymWvGmuqKXge/HpPwxiFBx4mWd9lGd/D98PfNokEerIx990Gt79jxs+9HtQ2leb4qKkveUdA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665502015; bh=XfStAmZj3kOfJU9UECFUVz4WT8UsGCLEsfu8GjfZ7t8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Un8YFy1IjCuHscreEXPffQchj3B3U7a9n3u/+jeNhvDZLXUJYPbwk7VUq/Mv8vBlUcca8TUq62gxo/gcJZz/OlmJHBDqsseCqhmNG+RRnAHxeruArDmJYexM05NEd8J/Ec9uK7ciJLzzEFqNmU5of6QoaxqYtzcek+FuwkviZ5NWxro8+4f4Bd0qrz4erKdGF94RJO0D8IPKFIZ4KfLKwCUIH+/neCQIETpr91dQ04IZTpZvb99tDO9GFnqbVETSMay+ZzYp7QQ/TR2AQ8hNeJNHUjIoa3EM6hkDHNBu2H9N2KiwhN3Sa7Z/GC87C/kUe0mI20/nXGzIptjkt+J9Cg==
X-YMail-OSG: Om5zuMwVM1mCwX_TKOelHY2nUP0xrY14BBalwf7EuaZunzr0RFjyhpC4oknVJbm
 ISjHiIurUWnx9E81mzLFMMk76LansF07Q4avX7.8fQRbgp1eCenaayZI7MjCGTv4H0BeKulols.l
 u03HkinQDtOvgJlF9dpJ2tSkUP4y7HCDGOZfCtgxu911Sib0SMl16.fajTUiR5AXdDqYI12Ce2Sx
 dDyd.YdQ_q2FXYeVn6.WtBOrcy_wJXAEOti.XGYKwA4OiutAY290cdObJVTG0fozyRWxkOpF8n7Z
 S37dlT_N49Xsd9BTBDqDDAW.mzpwizqsThzW1Bu89oZHw3beKr1fNvGBxlxepZyGtsDmuXHZbMP8
 oDgH4OoWphIOJFl4I0XzqYMjjZhvTogzdN0HwP_UFGmYWEmlDLL0_PmUiBS17diMTl3eO_QW0mOt
 ZpqJaZjpHpDGSyn0hVpuuoLm.dCHE2lQDmgI103GyTaa5moViUHFjE49QnpGMGOiq6_F949dtMvW
 B0zJS29RkYohUVJ5gbsUUiCWP1gZ0nXo4shDRLpDwjA2wFsO6AuRz.VR8jsmJ5K36raGaMC3vPKP
 LRW1UnhtZVxIPRWjDZt8s4KVhWQP1d8JSv8i18yThi6RbhY7IO2EbAgCk.Y0BcxMblTtA.Coqgvq
 7Xu7X0XnoXwv3jyhr7gZ5b8sKiAQ4TD9sF7xqeC8VJEd3d6YjCFLK9UHE6bh.m_iYVkrcKgYrIwq
 ZxkI7Lwn2lCMBl1t2Hxl2yGawt_EZ0rTC6_WJqnhiBTw799AZ8Lq4BmgtbCT3MLVftm3S2RK7KHu
 3NJ174FuJVfSO3DW0br2Z41gU7okr1x0QJK3VxRq5LfVbTeJ4AjoAEakYy_b9Ud84SIATopP9jem
 4l2tP0ZuzhE.88VRTrggX47ewHaq9AA0ujCDRjIrvB.HgKpI_eWqFo0D8fj0JknvWPynxtAI.VdY
 OQ2NQnSWCOjVpTQIXnDdW9QEUEER42s0C.avLscGKdWdatlCn.DsuotLuuDeBpIFUvI0BKlWiI5H
 3dyzB9bzZHKFbnD_yZJPJliGx1TmF6ZTrr6LqoQfb0fer1ZzZ_M5y7Yt_cijX6dbSIhg.DnWMqVk
 J_zqURcKn00c.m4ebVPW75ahccxbZZHZDds0bV0_ybj1dyydo1kCLfDcvAuEAU6tkwLrtEHBLiZ6
 oKRsKxV_420eaGbAXx610A6krJ6etjPxRVRHUzMSkFcXFsGljZFym5xhCa4vJmC9Gyq3ZT4.yXG0
 wO4oXllJ3xoG2Ch41QvAjfasdQPeMUErJdqXrgTvhBEbC5edOvnb7n5MZYT1KJrfRQQNIliRgqzS
 HsY5eYbP79DBEYiN7A_IQwFWpEOwBWAPWgKfokztdWvOYQ2_spOnHy2qXwBoBiUJU4udrM4683d_
 3BOHXufK6T883jjew7SjBdMKrh1gKoOmzYpdZ_7aS3_3WkA5ftls7_pkuXarzlJr2UJneH5roiXD
 svKEEAjBc_0YxLCVudOFQdBOQmsXeAoWulpwRVmcrlrXHizAg6GL1P_bSlg8KWJcq15WsfcepC2a
 uplyk_I3szUrwWYbMnanrdppHCJTjC3E_fZY5IzTg3imWR.GRSggDueQJChtJcZv4_j9nXygmU0d
 RJMBxib0lnVZPtUVUvpQnOm97qap4uTOvgMxmzLJRJ3aCpznwXY4WVXD1JlOOTdTFVhi6lP9.qCO
 9Cn3NGvDtGyz7Ih3MFvZ1t2AJ0KHfjD4WgS048RGoW9cmqxj8yKVDHMOUaU9vdFBaewRyKnigzgO
 wiT5p.KCcjCqGTKpn6fKvxgH0u31L16pvsftirZsraCZBpEuy678uA9nlNW6ey81J29e92vpu6hQ
 AqWdlOjuqe3PqxR3uQZ5IL24E9L42wzupVcMTjSu5DVvkapKPuigbu_6rECQbHszTYuxzff8Jn07
 OkCWf.3wAR2i4jxbeqhfXCX4cgg4wroHDJIk1L9waT_VoFmZ4_GkYP901JTANRYQESk2w8YC7JO2
 yiczY9yXj1GpWCw7aCawSvAbUKrHSuTFqiIRjoWwt.CUQ1U_RP2toKgbF8ppYNQVNRYnGkjK24Wi
 35JJ3n.DCAXUQsxu2aKuKgDZTR3kIgZtnmPsdavkpy0iS553btRFQO4ntl7IK64SyWA4edpFfJJV
 fhNH4V.ESw.4T3mpjWFTjdaM0kzJbUp2Ahwr4gXlDK.b_57dZjsU9eZJG4N8CoP7houlki3xGKvt
 WQVOgTuTJRkhD8fN0q_TWMgNjwI8Z7EuQM7tTZaY_MEjHT1wrSCmWqq_z0IX1WVkweDNZF42MB_D
 Jz9ejH847J6oc375E81NaDUkSF3fpqzCOattRmi9AouOpX0lKed3SyMqzVOR_zSuOG9PcI5F64bu
 n8qUS2pG7UJf9JFq5OUT7i9XN8HbhSAAnBmSN69LtRw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 15:26:55 +0000
Received: by hermes--production-ne1-5db649d989-fgvgk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 76a9c7ae1adfe680aeb58ae9e9d285bc;
          Tue, 11 Oct 2022 15:26:50 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: 
Date: Tue, 11 Oct 2022 08:26:48 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn04y0HRlz3skf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=pX0on88J;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 06:17, Warner Losh  wrote:
>=20
> On Mon, Oct 10, 2022 at 11:50 PM Mark Millard  =
wrote:
> On 2022-Oct-10, at 21:08, Warner Losh  wrote:
>=20
> . . .
> > And are you sure it's a booting issue and not a console issue?
>=20
> No clue for your distinction. But, being serial console
> based until ssh is possible for my context, I classify
> serial-console-broken as a booting issue. (For example,
> not being able to identify the DHCP address assigned
> if it did make it that far.)
>=20
> So it's not a booting issue (where the loader can't find the disk,
> can't load the kernel or loads it such that it hangs), but a default
> console issue. That's a lot easier for me to help solve.
=20
I wrote separately later that I got a HDMI context set up and
both the serial and HDMI consoles stopped, showing the same
final text.

(I'm  not sure  that the final "-" lways shows up. But the HDMI
and serial displays do seem to always agree about it.)

> . . .
>=20
> The change was made in late August that I'm thinking of, so if you =
could find a
> snapshot from early August July that would be a useful data point:
>=20
> commit df065f699f1ff819bb9607c44a6754275ab335ed
> Author: Warner Losh 
> Date:   Fri Aug 26 15:46:33 2022 -0600
>=20
>     stand: More sensible defaults when ConOut is missing

I'll look at finding and trying some artifact build to extract a
armv7 EFI loader from. Available snapshot history does not
go back that far so far as I know.

But I may not be able to look into this immediately.

In main:

commit df065f699f1ff819bb9607c44a6754275ab335ed
Author:     Warner Losh 
AuthorDate: 2022-08-26 21:46:33 +0000
Commit:     Warner Losh 
CommitDate: 2022-08-27 04:17:56 +0000

It looks like the closest prior artifact is at:

=
https://artifact.ci.freebsd.org/snapshot/main/a358db5603702d5de5fd75f5bd16=
bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD
git: a358db560370 - main - socket(2): bring documentation up tp date =
Gleb Smirnoff

with date/time: 2022-Aug-26 16:26

So I expect to use that.

> I think this should be backed out and we should use a different =
hueristic
> when we don't know.
>=20
> If you have RPi2B v1.1 (so: armv7) access, just try to boot:
>=20
> =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>=20
> via serial console usage, no video connection present. (I
> did not try a video connection as that is not my type of
> context.)

Again: It turned out that serial+HDMI also shows the issue.

I also later reported that the snapshot with the date 20221007
also shows the issue. You do not need to use the 20220930 one.

> . . .
> OK. That's a fairly clear set of instructions.  I'll try to work that =
into my
> schedule.

Thanks.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 15:39:42 2022
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 4Mn0Ms4Sf3z4dkgd
	for ; Tue, 11 Oct 2022 15:39:53 +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 4Mn0Mr3wZxz3txM
	for ; Tue, 11 Oct 2022 15:39:52 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29BFdhq5012499
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 11 Oct 2022 08:39:43 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29BFdgxb012498;
	Tue, 11 Oct 2022 08:39:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 11 Oct 2022 08:39:42 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Warner Losh , freebsd-arm 
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)g
Message-ID: <20221011153942.GA12477@www.zefox.net>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@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: <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
X-Rspamd-Queue-Id: 4Mn0Mr3wZxz3txM
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 11, 2022 at 08:26:48AM -0700, Mark Millard wrote:
> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
> > 
> > On Mon, Oct 10, 2022 at 11:50 PM Mark Millard  wrote:
> > On 2022-Oct-10, at 21:08, Warner Losh  wrote:
> > 
> > . . .
> > > And are you sure it's a booting issue and not a console issue?
> > 
> > No clue for your distinction. But, being serial console
> > based until ssh is possible for my context, I classify
> > serial-console-broken as a booting issue. (For example,
> > not being able to identify the DHCP address assigned
> > if it did make it that far.)
> > 
> > So it's not a booting issue (where the loader can't find the disk,
> > can't load the kernel or loads it such that it hangs), but a default
> > console issue. That's a lot easier for me to help solve.
>  
> I wrote separately later that I got a HDMI context set up and
> both the serial and HDMI consoles stopped, showing the same
> final text.
> 
> (I'm  not sure  that the final "-" lways shows up. But the HDMI
> and serial displays do seem to always agree about it.)
> 
> > . . .
> > 
> > The change was made in late August that I'm thinking of, so if you could find a
> > snapshot from early August July that would be a useful data point:

My Pi2B reporting 

FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-2b766d5e5a: Mon Jul 11 01:38:59 PDT 2022     bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm

is presently running buildworld on -current dated October 9th. If I'm 
understanding this thread correctly, running installworld will result
in an ubootable system. 

Should I refrain from running installworld for the time being?

Thanks for reading!

bob prohaska

> 
> 

From nobody Tue Oct 11 15:54:54 2022
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 4Mn0jJ4Lq0z4dmyX
	for ; Tue, 11 Oct 2022 15:55:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mn0jH5mW9z3wjN
	for ; Tue, 11 Oct 2022 15:54:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665503697; bh=3yl7obi2zTErtP5gQ0P08GNB7FWiCoYwaFHhvgf9LmU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lKh7sdfc6cqESpWIOcZ4cqSWEQ7ZyKL8yUcdvrFoK8ZNANeVAqnvkVMCZSRhRTrRbeNltT1emztUYUBCxf6u+D4tFsE4SGVq9mgNMow+/mKrlSMm7yiKnm0b2XIYWzvqIEr+shrZqEEqJyPwkQaPnkebhQYidMA7b3gHrxJcR2/lQjLnd+GHlx7uJNSy53BSXf1pjhMEfqo5S+26nEgdywAHiupkAsqHqEEXT7PltKV4Dy0WNtxC14omV2GO7OdXKqiEERnNJWkUFk3eIrkW4OaaCfVQShdhMkjxNqY7ntImyhVD4k9/hlBdMMJw9Ou60wYSauA9F2XIXFg6BsqWOQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665503697; bh=RPSnaFvCW+Ti70uZmDM8tcWtFcEiTJMhaVKkiveGWP9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AjyuCOsAKOqhsJ+p6KjKUtdI5Ga3CzWcaT0pEanyiaZq3q66tiX7yA9LCn8dYH0tqQKfhK4gB2OwwylTadvVRhfOkWhvIS7hIUvk31pwg35/fMvC58XFPJM8Y9f8f3vvbre1I9vRMPbY/7HrzyyoxB88pMWvwY+Wz4Xyib1DozACkamkshRHm8HsFyOQomPadB5Sy1m+M1PpgxdZqKBzS4e9P03sGAMJhXUBp54NoPIn9fCtEKmNujV7rVIFyqnD3fegI+fus1lPlJ85DK7RHc9nzt73eHeiPvz8q1qDvGe8aGLMHfGehVKe8U5teJneNGfvAznGDm0PGqD6Ch7eOw==
X-YMail-OSG: YtAMRdQVM1leIIRHgWZsFx4I0Euqv8bRWGLmXVaZpgaFu0yBCtfsuGoIdrU26MR
 22xpZXrRE5d63CchcZunu3rpLZ8j4pniFpGVgChW0YUG0_oCCn2_mbCkD9AC3GsPSqU0VtQ0B1f9
 0bx9kkORfJ6qXQDi7DY9tWddXyD.xRwg_ki61BoAsgxGGYQKyR4EF2p59Xu4qcgDdcc1uHaGdjmV
 .c42sD8gAuWkEov.HZO.See1ubxfWU1_eU6y2PUDcrTAy59XiVbG81YycQZ2gHTx8MavwEgv1fah
 nLyOF6n4tEM4p9nPbfT6d68daVjnvoFinC9y5aDoB3aptM0FfxaaUM9EwsGAH9.eBi827DAA5uq4
 XG2CBMYnX7_l_LKNHkzdhxx4sfWEdsX1eNbEAvMC5bE3WSKmKMpyoskgVLgFRDcobdKUEwVNKqQt
 n_qeFiKRBVnT6qOWgWDLyYKHhGzPeBRYPchNtrGu_aQk9kcNhlSfgxb72uvuesoIlCgo3Pt5h9xn
 v2P7xmRgJZhVvF_qXhr38Rt_Tcb1ibDAUmgnyfCzUCB4Z1Z4Pkoog15HBy1uUG5u5hBkuG6B_mBN
 lKeUy1_HPWL3dTf4BEoTixW5vv5Twc7IZmWi6wKeitS_T7s0T2POYtxXYJM2EWLT2aqF_Qqy.MY3
 vZFBX.DK2UmzEcLQLGhEOODGke3gLdpFaG76ytlQEzeaLlwuZKYdUceHpjSZpUJXbZk93RXdRIUE
 1IIsxc9uOaVhmPwxr38kegq7h7IJtpq4K6Jju2KvqBfoJqBZMh_eSnv8HtjptGRPtcp4BCROAgKO
 BKeCeGxyN1JoNwbJ9UaJKltXRLeAWacUUg.OQi5Mik8nqCjOProcunP7zVCvs4QhCCSMjaWReEoy
 DLKdDf3w4eu_LdusnQx1HxZj.isYXfLngd8iyn17eJKcBH2pHwQZPo13cfx6PHvM83QbiRSlszDc
 Z_ys1B_0nco7Bm1ypMfI8pqFl4AKlsgEaHlwj5Ibjf_Ula.C6lEhIdsgboPSm.9L_JQddQ3OdptD
 OQuOj8jyx65VrubwFvQnSV9ZXPkKVuhnbc9M1xtNsAkbR6y4tn7gQCVh0DuyP0T1Xy_R_tvb_pM0
 lPKvG24uwoembKPEw9Tbi9KfsTpTpS2CI7fbcbWursobgbhJndaFOF.Mu4j5OHoH2YO_RoLh6.Vr
 9TfaRCFF_KVIM8cj58KCnz2Y5YC6PErY2YnFQWzepFbuPIV3qlFr2ixww.O.WqupaH.kVyCTYZqr
 jahFHAvAFNUFITPqhPOWYt0oJ1V_F_fU9GSidY3mMT2dMWTZTGkChJJGAhIFPWuxUZNZV.MZeIUg
 LBEOmXGi2F1KdBiAkKpn7.nBZpGwz9uTbTPhjg_SZ1hE50dyjVtnWK_1rstNAxNSOn7pu_A.A7Iq
 KJmM3MfGxzPdUljOr_Nc3fTylhkBkDrAHdMTpPAI2LOMkD.GfyUmBTLu0jyCH4U2ylmHev_it1Zv
 OlFzNrsfX_wk2K.nx2F1SeKjCgvtaE1eEgJ4Lg1BMYWziqC5J7o_zHx1WqAFaf1Il4.YdNp98KVI
 pxnUNXxxT0Gwg70xUN81ShMds3QTtLP2MbFftgDa31DYEsKp7fPipFerfz0eE63zqbFHvSFZzU2F
 DcvkeKBCts6IkEI0ptCVz.Z6UgGECh8vwleLIU5y9ZcNNcurSfIM0Ti6W4bhQqcPxhneWxpWiX_Z
 Wa_RvQ4qNI6L4OD56p3zrgcWUJ54n4QvkZSOh7kq8zgSm0q72R9ftEVdbCkX3RjDW4ACNNtRBc1a
 Fp4VUjJjG0Umg6BATSvSzVbr1x1vBXvy8As2A1OQHCFTfN0jzsIApCFf8GNmPMhBM4nC0n1F7ild
 _3RSp_5W0RFqJEwwVMc7Jgfy2mN3YCpUaHw55YgfxFJ6OfvQQb649UBntQ.AkS9l38RnayHtjb3v
 MPb3qLhWn2fWxTjKrTiClpt6Pnnu.eUSa8QA6_kzlk7m6YNc37IkiKHKtOPk8lBFY0yJ4657g7N7
 Kln1qinFjJaaqbyuLMARxie2ySdK92KRJzLtQwpilCkxd5tmRJOAQVhpz1.yzaVID0xe6SLJaq5s
 Iv.g18Wc1Phc9jM0klBqfgo0arqLvzyJIJg00WTFdn11myi_tccnWHK79pfZhcIm3YikrKxROg6p
 sjfm5cpOAkvsmL5p_8CaqVqwCfaAwe8G97YX3SJGGj4xDtG.wax.mNmO.l5gz2LKdMHfPAbapXz3
 p.QvTVjn2BcwOw7FJ1zYviOx1vxf1oHfkmUtkw4zB9tm8UiYZOPXORPAc6Xeq7MgjMFX3i_PanQo
 iV0s-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 15:54:57 +0000
Received: by hermes--production-ne1-5db649d989-57w6q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ce4274d41882f8be819a43c1222e5d46;
          Tue, 11 Oct 2022 15:54:56 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)g
From: Mark Millard 
In-Reply-To: <20221011153942.GA12477@www.zefox.net>
Date: Tue, 11 Oct 2022 08:54:54 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn0jH5mW9z3wjN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lKh7sdfc;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

[I'd keep Warner out of our exchanges: too higih of a
volume. So I've dropped Warner from the reply.]

On 2022-Oct-11, at 08:39, bob prohaska  wrote:

> On Tue, Oct 11, 2022 at 08:26:48AM -0700, Mark Millard wrote:
>> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
>>>=20
>>> On Mon, Oct 10, 2022 at 11:50 PM Mark Millard  =
wrote:
>>> On 2022-Oct-10, at 21:08, Warner Losh  wrote:
>>>=20
>>> . . .
>>>> And are you sure it's a booting issue and not a console issue?
>>>=20
>>> No clue for your distinction. But, being serial console
>>> based until ssh is possible for my context, I classify
>>> serial-console-broken as a booting issue. (For example,
>>> not being able to identify the DHCP address assigned
>>> if it did make it that far.)
>>>=20
>>> So it's not a booting issue (where the loader can't find the disk,
>>> can't load the kernel or loads it such that it hangs), but a default
>>> console issue. That's a lot easier for me to help solve.
>>=20
>> I wrote separately later that I got a HDMI context set up and
>> both the serial and HDMI consoles stopped, showing the same
>> final text.
>>=20
>> (I'm  not sure  that the final "-" lways shows up. But the HDMI
>> and serial displays do seem to always agree about it.)
>>=20
>>> . . .
>>>=20
>>> The change was made in late August that I'm thinking of, so if you =
could find a
>>> snapshot from early August July that would be a useful data point:
>=20
> My Pi2B reporting=20
>=20
> FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #12 =
main-2b766d5e5a: Mon Jul 11 01:38:59 PDT 2022     =
bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
>=20
> is presently running buildworld on -current dated October 9th. If I'm=20=

> understanding this thread correctly, running installworld will result
> in an ubootable system.=20
>=20
> Should I refrain from running installworld for the time being?
>=20

If you have a working EFI loader in the msdosfs, just do not
update it. installworld does not update the msdosfs.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 16:20:29 2022
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 4Mn1Gq4rckz4drjg
	for ; Tue, 11 Oct 2022 16:20:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mn1Gp6WT4z40Dp
	for ; Tue, 11 Oct 2022 16:20:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665505232; bh=PIhvrfDYOD0KFE6XeC5Y9Z7UaFe1kl1k5uE+RXzFdbo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XCTK21CjomKRXeP59dFiuozx7kKnbeQ6rsujpWlMWqBs+sdaEChfACq38Ovr2kM40Nc39Lz2y6N7sJjsZCbGuzA/KCkPoqWyvONPjVhdYLkgo4WfLHrVnT+xKDmCWO9ENuwUEwOXycYlOAEkoahBLhcSB/PifL6H0Atzkod/bbkWbZYhSsHYTb8Vf57v9pgXknmmu4oNFNSUKkUPyaTSeImq4KjDv+TGfgoQA4YyIEWfgzC5ILHK6zPPnoLqeE4uv1iAvTXVGWoRlbtuE/SOFW+RgbiZa8fvKMHByF6sDmSnFdojrBb0Zd7BI4SB95FSgwhZvgHWu519gDRek7XHng==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665505232; bh=JJX60yk18Xbw3aEzdorO2V56sWke/jkxgBCQ7Qg4oQZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eQIJ+l7a3UbmT9Z8PbQfRoRvgbMfVh40a3STuCNNe7o7zpvlNWgv8AUwcxr7kPYPjIhbC3tDE7yTS2Rs5eqv14yKINJ/oKjr9xkhQrqymS0XfK9+d8ern1FnRnV8ZdYlGJm/KPHht183PRhgRuCvPrlEuAAoUk3QxMHcp8yvHvrO45flvaTOqXf8SA8upg7H58Bvu0uSBSIU177hNF1PVyOp/9V855ZWF4E1hjB4bW/CI+1FxoP7cvDmMyJYxQ8eK41gq5G3jj4pKaZaenoky4ut3AKnTE++mCGsH8CVIfDphGMiSg6ILsfD/+NmK2ItVu1JYFGwEyhs8cwRUYXd+Q==
X-YMail-OSG: 5ZPGMgUVM1lYcVwfzbLmoBiyY9z7Ue9gFVNAerfh83LegZIbc4HCivwS44CD8XN
 j4K2wLYUbGEFQGN5hDPURWclwYM0ayPTEi3SFI.6GmlIDEQZETMv4YMQ7tnW6LFAtZWlTODX7Nos
 zfrNMv3G3lNN38gaYtdaZw2OEcanFkskQp8XTeaEvXcxgJeCWwTRP2IZqpJ9cUi6uwXPtdGiLjDw
 CxKPAxdlo5kwqZBuowHLvCXwF04EEd_U2OSg0kPyQoIfGbZLITBMxib4vbGDUvKW_ET_7ToslbwS
 3erm306nwtWVgpaoVVuubciUXfEs2ssvdHIf559KLH5_J7U7kZIRWPa7BY324VDqlQHpKKf92qJa
 qwHByEIsafGMVAl_AxwJpugasKMCeBr5W2Si5gOjoX1kb8Ghfr9OeTeohbFunQ8vGMicxYBpyR2t
 w3YZ3uSKwlmNoyx4glTA8c2HRYp8EePaavOVN2NjfdWsQV2Fbf10iRxr_qvmHt6M_axWsN69b_Fy
 XneeYvkasmxsDHGsGW9tXLEbZ1U4laV5xl40PXjIBV.Csi1uVQ2U8umfakgCTSu71snxablt9Xdr
 w7TS1lZCRyW4zVmE5wYkzyL5khPgod0NcAXZIzOJPfIHCoXK9IhSAHMjzjZk6vrcrk5yKURgaZxz
 onWFNTHUr7xnEmHHVZwA5J9cdBfCEcnn87hIC3KBR.1OdIQ1jShXXTMYs3xSp55Hyb1McNAGAr2X
 ksKRLxUkMdX5zpqiPEh_mvg.kuSJgv2.XjTV2CyAh5OzMsaI01x0ABCnO_9T59yVvJYexTQovsN8
 Phzk4EDFfRuUamyk3dUJpfvFbPTYgqteyhwNTPZfHLwtYjI0cpV8tnE6qqhi6vPHOQlRr9_LUj3X
 xHaE4H2WYlUn3bpCP1GK0lqxfrKGnS_ilCwNEePCmqIVhdB38kQ0DE_D.96nqS321vkDJRz2sUQ8
 f4tz8Oqrg7K1Yddf0UBHE8b38xEMmnHZcjztY2bqJIK0F1CIP1Rua7wxCzTCoSVlqyAkyD91gfPJ
 a6873caFZpWoRC4rFWmEGJ5UGVfyR_Ik9FuqoiE_knWYMSMUlCj3HwYzQlH.nx1bJW71QCg8.Tro
 qxo7_pao8Iqp7GL2KG7LAocqtge9iEI9jyXt8WLFMKz72pSXQpDzGVOQVMDJXDxSxbtZAS00FkYn
 QCgvFyzLkTCBRH0JHnSA43_FOldLje6Eiu6H9WeELI5x17yFYzFKiuWPN8W5fgJ0aFwsrs5AAPGp
 31DU1suh7d_1SKVUJWjgYHV5Vkti031FOGzZwPWd6QQQuHbQoH_6j.OxnDdfdxoo.6VAGAsFCK8E
 cA9V_jZTXvZqvNd00CV7M2WVhBFipRN4jMs6gbGXK8_Koo8aMS5fa2CK6Dl3qgmCwqe8BzNV6zxo
 PLJLget3UPnRDg830NYKjM_aygsCtTyRSUOy.0OgCVFbJPJ9kQfrnKy1TmmbZ5RrFLKDwfv64vDK
 V0cbFh6XpdBizFdXsfkXHX5ozfzHUQISjGzcJzW4.n.mQdwV3JuJKdsjUiCvVBzzSpEGuwAxDfE_
 FqB3ZSgG.skQYBzLSbxeTfKX5zvcT_kqlg0bqABvUqIAD0hdi0wDqjCqhYxjG8yWlxMnyrqf8Gdl
 gTwRmmZ50JupUjeWcZZovyK_x5Qo78nk0En5vH3H0vLWh2qxwVLqr9RDHaQuEwmbbM4mlHyBuPnt
 PNCL83C31A.YdWauyv82w_jV6RhNCvrDkd4wG0u8nX8rtsC2S1ADqVK_fWmxkezyCfv2Ja8PNGKF
 6T30ZRI1m0O72k8hcglu7dcuif3GqKOumB4yvh9jD_XwMykwFMJ7Qi8t7CxAg.k_YZXlT6zK4Yph
 GKnK95YcHhY5Xi4.8KT1jyb.DvA4izUAt6OKg73DWWg9ixBrPbSyG0ucQ4isUY4sKiOdrUd9s0HH
 BrdD7u4BRAyKtYC.qwYLKJOkRcSVpGmt5PYa5s88YyQZvbA4nMgDQ3e7PZpxnf6BfCA9N3bGFd7H
 NLc2jMRV_V96Lu5QtkRE1p2t0oR49vMYh3x5bq60hlrq1Yt1j3L7C170jNtl9m2BaSfAdDEvInn2
 H.QsbbV43ryu3r_FPwO4wRVfsDYU5PWT3RjSLnR8G7y5Ux7.v8TgEYg6yg2V7.CmKbBJdg8iPvvR
 DTnzcAjU9ZOfIqXKWfcQfi780wRDfuhVRFejgyibMPxZ.jcQ1q4RmnuxDLeePm.Ux2KuDStvPigS
 3y35_vAItF5L6Hv1Ptd.NMaBRZI8IZ8Xgrb146dmjfXgel0P0QjooA37FJ9y6J3JVptfZk21mDkr
 GfP3NRU6RRH37EnjmyIP53dctTGeZg2ARa.3oZY8GTfcDfu7ki9jM.CLzYUlwKMyV8saOVG2IJtk
 gPjEyjDn0k9vfmr6iSqJkVqmL243H71GMPf2W7Wr1ACxN
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 16:20:32 +0000
Received: by hermes--production-gq1-75cfcccdb-kcc9l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4c82b53e3d6cd902650cc5b717755ab6;
          Tue, 11 Oct 2022 16:20:30 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
Date: Tue, 11 Oct 2022 09:20:29 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn1Gp6WT4z40Dp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=XCTK21Cj;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

[Summary: Both somewhat before and just after your ConOut commit
work. I'll have to do a rough bisect with the available armv7
artifacts that are after those but before October.]

On 2022-Oct-11, at 08:26, Mark Millard  wrote:

> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
> . . .
>> . . .
>>=20
>> The change was made in late August that I'm thinking of, so if you =
could find a
>> snapshot from early August July that would be a useful data point:
>>=20
>> commit df065f699f1ff819bb9607c44a6754275ab335ed
>> Author: Warner Losh 
>> Date:   Fri Aug 26 15:46:33 2022 -0600
>>=20
>>    stand: More sensible defaults when ConOut is missing
>=20
> I'll look at finding and trying some artifact build to extract a
> armv7 EFI loader from. Available snapshot history does not
> go back that far so far as I know.
>=20
> But I may not be able to look into this immediately.
>=20
> In main:
>=20
> commit df065f699f1ff819bb9607c44a6754275ab335ed
> Author:     Warner Losh 
> AuthorDate: 2022-08-26 21:46:33 +0000
> Commit:     Warner Losh 
> CommitDate: 2022-08-27 04:17:56 +0000
>=20
> It looks like the closest prior artifact is at:
>=20
> =
https://artifact.ci.freebsd.org/snapshot/main/a358db5603702d5de5fd75f5bd16=
bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD
> git: a358db560370 - main - socket(2): bring documentation up tp date =
Gleb Smirnoff
>=20
> with date/time: 2022-Aug-26 16:26
>=20
> So I expect to use that.

Turns out that I had the time.

Use of the ./boot/loader.efi from a358db560370 substituted
into the failing main snapshot based microsd card worked
fine for both contexts:

A) Just serial console.
and:
B) Serial console and HDMI console at the same time.

I also tried the oldest artifact build with the loader change
in place:

=
https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea68c=
3be9c2ed50ce/arm/armv7/
git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner =
Losh
Date/time: 2022-Aug-27 05:12

This also worked for both (A) and (B).

So it looks like I'll be doing a rough bisect to find a
before/after pair. It might have some elapsed time to
finish.

>> I think this should be backed out and we should use a different =
hueristic
>> when we don't know.
>>=20
>> If you have RPi2B v1.1 (so: armv7) access, just try to boot:
>>=20
>> =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>>=20
>> via serial console usage, no video connection present. (I
>> did not try a video connection as that is not my type of
>> context.)
>=20
> Again: It turned out that serial+HDMI also shows the issue.
>=20
> I also later reported that the snapshot with the date 20221007
> also shows the issue. You do not need to use the 20220930 one.
>=20
>> . . .
>> OK. That's a fairly clear set of instructions.  I'll try to work that =
into my
>> schedule.
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 16:27:54 2022
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 4Mn1RQ1pFNz4dt9N
	for ; Tue, 11 Oct 2022 16:28:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(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 4Mn1RP3Fw5z41FV
	for ; Tue, 11 Oct 2022 16:28:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665505679; bh=PAQyWdn4TZGhWmHlLu8fH6RS8h137YCixm0aRVft60U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pk8+NvoeGMvwPVGCP2d/vs1rWOARcK0DNgGsma8XI1Ya5xjmARKuOGqHvlD0pokr7ZjOxjq2B8g97U6mRwglp79Ab2RJby3hEXbGFVkLqPKm5seHeHb79Zj6/yuNmUiz9Qi4HhKejfgZkSO615joXO1oJqT063CzKKWi1Z15Z/v506u/041sebHpx9+QhCnnO/ZElpV6SX9bYcPSBa42zUoG8Lmo9anVIUMGCCWhqB7HCQnFwQLoKosr7Hca63UFvEb9JFTsHSY4muARRbjJnF7p9Cvlu9nEq7a82pgjI6xF+qnqNN0p7udakJ/A/yf9eGA23hRo5wFyMHLUeXfrRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665505679; bh=9ZSsRCXHVlUcloXI1kEtgJSFyWwB0QogeMbPrJPk3sx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZVq7kM24Fdpo3LHmbl4lcaiioT0riHBOGwOjFQ+wSKHoCQbjpvG42CMOtKcYkgCfJ3odVGSmuS5kjX0dKDoJCS01HfGs7j4rlLi9BaH4HkRw5Pd+obS8W/Zc9McFTf0QjAP35i/S1ezko12n7kd8f2J2dMWWMfi+8w8J8GwJpgswyvFq3rxe/yviCWxMRNE1utZHUWD3tXymNh6nZMqjARu35ABPtvpvZOth8FnqwmVuy6fly6gl63uFtoWIXXREwcFF6AeMvkKN/x2rhN28cj5J9mwZF02rEoYxZjhKj07pzsWh0wGGWqPVvejGuiIjK0UOjjCXZ5LX1ZzQkrsV2Q==
X-YMail-OSG: 6oUiBd4VM1nQzm9C4cK.Sx7OMNw4SNIxAHphNS.0DFJRarBBmyt530mQ5YM6Oe8
 oJaXS8AZmlThUPAV.H.xVX1Ilb6.TFp8cETKCbV1SjiAe.Sdumhr_PcP1719vQloVpvwdngiIB.X
 axB6816t6tOtBOu5HpebmcJOhauseWZUA0Z8VJpUzegUx.yBOH0cT7wjXHxXdTjaE6bsRuEoZbxH
 YLISN_TKt4MQ.yS_JPNcZ2OWzeygCwAkQXE7zoaI4gCg9t8zMdG9q0sJXWUVALkjBPipzkFfUiq8
 Nd0jgD1cmfwtzoXoEmCnMr403Y_uvdjJ3inOjOoeERIUyuJ05tpPVG4K33q6VRvKcK0K8EAowsAK
 Gx7ZxCiZ1cIRNIy7d_2SpQm.LVhW.NxUOHEPMWFhpteUKlVFTJZiBBHekq9cBSFsHKvTtAKvpjjF
 E5L4gaerKF1GYsqpUmsfTuIPSOf.u5sw8zpB7MKAnWTeLoI_hJ2RkfRRndPgR337yDMmCCKiuEl9
 klHXboYRYHsRuyBF46CU9OMGqf.IZbptVXPOHAMd2wIBroW1F5oKsezGyYTEihSEaL7_Lra0O1AN
 5VnvwbTEdnvLYIOhJuTBWvmf_ednOvd4sl3FFEzcaWYUyd.kjzjk2DiImBPNiY24tlmrPNaDtq9R
 AOHTlRU79j9eiOH0rzadJ3U2KtT1GO.82uCp8tvMTCYBdmWLLQGL5ngUbTx6pfHpEmy.tInWVH.0
 SnkEd86xmetH4velG1RfafDcqvVU5jh.sy2VvRhQyjOD63nCHOB9cmIDsTZgCPh_96KJb_9CzXVn
 i_.RV38utgO4ueu_892byv6IMzUiWUct8DC523UO4iMsRR01L7kZPq7jw_D2xVrTTW_ZwQrFX1_b
 8QPf_IbFMYwUeUFatIRmt7SkRAkR.6._hFbUb7tVQfyuzk4TESjGeKtRWqmIIVWTFaIGcNrgx3FO
 ZURwOSnOEP1x0sOOgpJQUv9kfoCPegbn8rRpkyXi7AF0pna7b8SUkr3ZLJLcmf9UafEeD0Qj_h8T
 iUNLmNMUY6_fKvbxyUCEeyUhVqm4etl7_n1.qBt2eU48D9z8AL1g0DYofGCzHWfMvzCsjtyF1DTM
 uDSnCsSk3AiCFYtsLSVZSvHORtoE8y6ZzNomWyx608J3a4T.wgalBWt7UFkE3df_Mq0AcCytv63i
 HeVA7.EPYwP6OtXrewgl96PQ_RxXxdbc9Cw4Xvo8hLsdws1cNo325eqEEwlubQ4AYZgAK_aw4xrT
 pn77iXzWeZ.dnNPHcAlW91NPAAXnzTGioy3cirzjckDqGwDomRXh5i8ZpefFhFl_qYDA6clc04_Y
 bVeMRJ9l5m4r8Z_uEvN8t02S3c9wtZT8y0AxN0vdY7VwQUeu74QelaPK_NwyClws2xNC6qRsqoUb
 5MMUZWuh1WWeZ9MV3vmNMu5L08Kpa9A.gSEbqbrxQdDVZPwI1SxWBN2.EaCKBLLcQjJ9ZsCeHLeh
 OlP8N7qoz906xECWMEc.lHSypCUVn7qwifWr9iA0NZsCScUhSnx53NIu2BORQpOYDwCy8eem_8hq
 aPzkLTQ1oOwam8UwnFuEna9.SXNLf2.qzCYkEz5hdtFD0UKOthlrN3ephKgTNDqxO2V0f9R2LRMc
 8_p5QGyzpaqGyYBIZYbRLnOXRtjc2EGSpGSeBlOPcxRuYN16MNrb.seT9eY3XirB6uFUoUzSIBm1
 xTNd7BUhpFxzXmOa5TlJEQyFuDRFrzLfH68tfLO8q5L0FetDbCfAD6uOKpW8cuqqYuW.WqvTHSl6
 1M36A3E1H9y5ze9no4U6ZCIhRsaDbr2..vZbMogetva6iKTgKv2dulcTrcJxz_l3CZsA.LseGpo4
 J7UnlS0IcjAckNZ.vcVtAZM504LjE07I0HbEAdtXjZJBhPUfmWGWTSZwX6jZxyJXqjGBR3QckAKS
 WkWMl4DxYejiBw40JowlTfxVuZ4mcsSpt6O9dqGrr45JMrWz58JMV01Gd8nQRGrN3TicbQQosSu_
 BfSkvCFrJ9EewtnIZqZu6qypsVMNbdJkGPPeInHg6VbZt_U4yyVRpLaOCY1CGXZqpJOz7AhJff07
 4Cn049k_ucyDw6snA2Cy20RDhZFBfl5IDKPvuKLIoVMIxf_cyDxE4ljgutg2rImCwF1coCPtnFG_
 wDptHAJVbicZc2XjK_ekrjDlyb7QKhOtOU.cmMS3u.OXJzTTVoWwKXvZut57sOt3FwyPxTuzDD.4
 Ep_W_9czOK7aSxkbmFYufhwftkyqB9q9EkLDcxHvn_1gpJURtkADxlKsBKcIBOafpAzc2QnhfWsv
 KOoucug--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 16:27:59 +0000
Received: by hermes--production-bf1-585bd66ffc-wjj8r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e3cb5814bca7702e620181b09cc5778f;
          Tue, 11 Oct 2022 16:27:56 +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 \(3696.120.41.1.1\))
Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot
 it
From: Mark Millard 
In-Reply-To: <3AA3A257-50DA-4896-84CF-1339AF7F3854@yahoo.com>
Date: Tue, 11 Oct 2022 09:27:54 -0700
Cc: freebsd-uboot@freebsd.org,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <616CC0AF-C986-46F9-959C-1B11BE10649E@yahoo.com>
References: 
 <20221003004624.GA3381@www.zefox.net>
 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <20221004192707.GA11488@www.zefox.net>
 <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com>
 <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net>
 
 <20221010002828.GA4232@www.zefox.net>
 <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com>
 <79FC26F6-7023-473B-B59B-2A80D97572EF@yahoo.com>
 <376089E4-8450-4842-B24D-1D6334D504CC@yahoo.com>
 <3AA3A257-50DA-4896-84CF-1339AF7F3854@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn1RP3Fw5z41FV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=pk8+Nvoe;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

[This was composed yesterday but accidentally not sent.]

On 2022-Oct-10, at 19:37, Mark Millard  wrote:

> [Summary of armv7 experiments: it looks like the RPi2B v1.1 armv7
> support is broken on FreeBSD's main [so: 14].]

Turns out to be that main's EFI loader is the source of the
failure. Using the EFI loader from 13.1-STABLE instead works
just fine with the otherwise-main context.

> On 2022-Oct-10, at 00:08, Mark Millard  wrote:
>=20
>> On 2022-Oct-9, at 21:44, Mark Millard  wrote:
>>=20
>>> On 2022-Oct-9, at 19:29, Mark Millard  wrote:
>>>=20
>>>> On 2022-Oct-9, at 17:28, bob prohaska  wrote:
>>>>> . . .
>>>>> Is it possible to boot ARMv7 on a Pi3 or Pi4?
>>>>=20
>>>> There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
>>>> need to be in use U-Boot and the ARMv7 RPi* firmware files would
>>>> need to be present.
>>>>=20
>>>> https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end =
of
>>>> the BETA) is from this year. Prior to that the official support was
>>>> all ARMv7 or ARMv6 based.
>>>>=20
>>>>> That would let me
>>>>> set up a single SATA drive that could be tested on any host in
>>>>> my collection with any candidate USB-SATA bridge.=20
>>>>=20
>>>> As I understand, such could work. But I've not tested such
>>>> combinations. I doubt that those FreeBSD folks that developed
>>>> the RPi4B support did much testing of armv7 use then or since.
>>>>=20
>>>> I'm not sure how much RAM would be put to use on a RPi4B with
>>>> more than 2 GiBytes of RAM.
>>>=20
>>> My experiments indicate that the armv7 u-boot ( u-boot-rpi2 )
>>> does not deal with the RPi4B's USB:
>>>=20
>>> U-Boot 2022.04 (May 13 2022 - 23:52:35 +0000)
>>>=20
>>> DRAM:  alloc space exhausted
>>> 947 MiB
>>> RPI 4 Model B (0xd03114)
>>> Core:  195 devices, 9 uclasses, devicetree: board
>>> MMC:   mmc@7e300000: 3, emmc2@7e340000: 0
>>> Loading Environment from FAT... Card did not respond to voltage =
select! : -110
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Net:   No ethernet found.
>>> starting USB...
>>> No working controllers found
>>> Hit any key to stop autoboot:  0=20
>>> Card did not respond to voltage select! : -110
>>> MMC Device 1 not found
>>> no mmc device at slot 1
>>> MMC Device 2 not found
>>> no mmc device at slot 2
>>> starting USB...
>>> No working controllers found
>>> USB is stopped. Please issue 'usb start' first.
>>> starting USB...
>>> No working controllers found
>>> . . .
>>>=20
>>> Also, if I had a EtherNet dongle plugged in, it did not
>>> even get that far. Note the "No ethernet found" as well
>>> (no dongle present).
>>>=20
>>=20
>> My experiments with:
>>=20
>> A) An RPi2B v1.1 (so actual armv7)
>> and:
>> B) An RPi3B (so aarch64, but a pre-RPi4B design)
>>=20
>> are incomplete but both work the same for as far
>> as I got them to go. I got them to:
>>=20
>>=20
>> . . .
>> Using DTB provided by EFI at 0x7ef6000.
>> Kernel entry at 0x36a00200...
>> Kernel args: (null)
>>=20
>>=20
>> and there is no more output.
>>=20
>> This means that the following all happened:
>>=20
>> A) RPi* firmware got U-Boot started.
>> B) U-Boot got the FreeBSD loader started.
>> C) The FreeBSD loader got as far as those messages
>>  after loading the kernel.
>>=20
>> Beyond that I do not know what is going on.
>>=20
>> Still, unlike the RPi4B, the RPi3B looks to be handled
>> by the armv7 context (at least for as far as I got).
>>=20
>>=20
>=20
> Well, I tried:
>=20
> =
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
>=20
> and I get the same sort of hangup on both the RPi2B v1.1 and the
> RPi3B when booting with the FreeBSD loader, kernel, and world on
> the USB media. I've tried 2 types of USB media, both got the same
> result. (microsd card media is involved in the early stages.)
>=20
> So I tried using just microsd card media produced with dd:
>=20
> A) The RPi2B v1.1 hangs the same sort of way again.
>=20
> There is no .dtb for the RPi3B unless added to the
> microsd card. So adding it and trying:
>=20
> B) The RPi3B hangs the same sort of way again.
>=20
> So it looks like RPi2B v1.1 armv7 support is broken on FreeBSD.
>=20
> As I remember, HPS's patch is not in place yet in stable/13 .
>=20

So, armv7 FreeBSD main booting the RPi3B, other than the
EFI loader being from 13.1-stable . The FreeBSD EFI loader,
kernel, and world being on a USB3 NVMe SSD (used via a
USB2 port):

. . .
CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080)
CPU Features:=20
  Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, =
VMSAv7,
  PXN, LPAE, Coherent Walk
Optional instructions:=20
  SDIV/UDIV, UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:3 LoUIS:2
. . .
# uname -apKU # Note: Output line split manually for better readability
FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #48
main-n258174-89a2ef4d5226-dirty: Sat Sep 24 19:37:56 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a=
rmv7/sys/GENERIC-NODBG-CA7
arm armv7 1400070 1400070

So, while U-Boot prevents RPi4B's from booting via armv7 FreeBSD,
RPi3B's can boot okay (absent other FreeBSD issues, anyway).

The microsd card has all the required RPi* firmware ( including the
bcm2710-rpi-3-b.dtb ) and has u-boot.bin . The microsd card does not
have EFI/BOOT/bootarm.efi .

Note: For my media, u-boot.bin is my patched version, including
the Makefile needing the following to cause the patch file to
be used:

# git -C /usr/ports diff sysutils/u-boot-rpi2/
diff --git a/sysutils/u-boot-rpi2/Makefile =
b/sysutils/u-boot-rpi2/Makefile
index 90c4e4d91827..9eca905f87c6 100644
--- a/sysutils/u-boot-rpi2/Makefile
+++ b/sysutils/u-boot-rpi2/Makefile
@@ -1,5 +1,6 @@
 MASTERDIR=3D     ${.CURDIR}/../u-boot-master
=20
+EXTRA_PATCHES=3D ${.CURDIR}/files/
 PATCHFILES+=3D   939129/raw
=20
 WWW=3D           https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi

Also, I happen to use the RPi* firmware vintage:

# strings /boot/efi/start.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 18:17:07
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Aug  3 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 40787ee5905644f639a2a0f6e00ae12e517a2211 (clean)

(The most recent that my limited tests showed as FreeBSD handling
without crashing for the few models that I have access to, at
least back when I did those tests.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 17:15:48 2022
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 4Mn2Vb35wSz4f0xd
	for ; Tue, 11 Oct 2022 17:15:51 +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 4Mn2VZ2ynnz48st
	for ; Tue, 11 Oct 2022 17:15:50 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29BHFmf8012804
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 11 Oct 2022 10:15:49 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29BHFmVo012803;
	Tue, 11 Oct 2022 10:15:48 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 11 Oct 2022 10:15:48 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)g
Message-ID: <20221011171548.GA12624@www.zefox.net>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
 <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@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: <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
X-Rspamd-Queue-Id: 4Mn2VZ2ynnz48st
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 11, 2022 at 08:54:54AM -0700, Mark Millard wrote:
> [I'd keep Warner out of our exchanges: too higih of a
> volume. So I've dropped Warner from the reply.]
> 

Ok, thanks.

> On 2022-Oct-11, at 08:39, bob prohaska  wrote:
> 
> > 
> > My Pi2B reporting 
> > 
> > FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-2b766d5e5a: Mon Jul 11 01:38:59 PDT 2022     bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> > 
> > is presently running buildworld on -current dated October 9th. If I'm 
> > understanding this thread correctly, running installworld will result
> > in an ubootable system. 
> > 
> > Should I refrain from running installworld for the time being?
> > 
> 
> If you have a working EFI loader in the msdosfs, just do not
> update it. installworld does not update the msdosfs.
> 

I don't see a file by that name in /boot/msdos, but there is a
/boot/msdos/EFI/BOOT/bootarm.efi

It's surprisingly old:
root@www:/usr/src # ls -l /boot/msdos/EFI/BOOT/bootarm.efi
-rwxr-xr-x  1 root  wheel  674864 Jul  2  2020 /boot/msdos/EFI/BOOT/bootarm.efi

Is that the EFI loader referred to? If so I think it's safe. 

Thanks for reading,

bob prohaska
ps: Just for completeness, at the moment I have on microSD:

root@www:/usr/src # find /mnt
/mnt
/mnt/bootcode.bin [special usb-boot version]
/mnt/timeout
/mnt/unused
/mnt/unused/EFI
/mnt/unused/EFI/BOOT
/mnt/unused/EFI/BOOT/bootarm.efi
/mnt/unused/bcm2709-rpi-2-b.dtb
/mnt/unused/bootcode.bin
/mnt/unused/config.txt
/mnt/unused/dtb
/mnt/unused/dtb/allwinner
/mnt/unused/dtb/overlays
/mnt/unused/dtb/overlays/sun8i-a83t-sid.dtbo
/mnt/unused/dtb/overlays/sun8i-h3-i2c0.dtbo
/mnt/unused/dtb/overlays/spigen-rpi-b.dtbo
/mnt/unused/dtb/overlays/spigen-rpi2.dtbo
/mnt/unused/dtb/rockchip
/mnt/unused/dtb/sun4i-a10-cubieboard.dtb
/mnt/unused/dtb/sun4i-a10-olinuxino-lime.dtb
/mnt/unused/dtb/sun6i-a31s-sinovoip-bpi-m2.dtb
/mnt/unused/dtb/sun5i-a13-olinuxino.dtb
/mnt/unused/dtb/sun5i-r8-chip.dtb
/mnt/unused/dtb/sun7i-a20-bananapi.dtb
/mnt/unused/dtb/sun7i-a20-cubieboard2.dtb
/mnt/unused/dtb/sun7i-a20-lamobo-r1.dtb
/mnt/unused/dtb/sun7i-a20-olimex-som-evb.dtb
/mnt/unused/dtb/sun7i-a20-pcduino3.dtb
/mnt/unused/dtb/sun8i-a83t-bananapi-m3.dtb
/mnt/unused/dtb/sun8i-h2-plus-orangepi-r1.dtb
/mnt/unused/dtb/sun8i-h2-plus-orangepi-zero.dtb
/mnt/unused/dtb/sun8i-h3-nanopi-m1.dtb
/mnt/unused/dtb/sun8i-h3-nanopi-m1-plus.dtb
/mnt/unused/dtb/sun8i-h3-nanopi-neo.dtb
/mnt/unused/dtb/sun8i-h3-orangepi-one.dtb
/mnt/unused/dtb/sun8i-h3-orangepi-pc.dtb
/mnt/unused/dtb/sun8i-h3-orangepi-plus2e.dtb
/mnt/unused/dtb/cubieboard.dtb
/mnt/unused/dtb/olinuxino-lime.dtb
/mnt/unused/dtb/bananapim2.dtb
/mnt/unused/dtb/bananapi.dtb
/mnt/unused/dtb/cubieboard2.dtb
/mnt/unused/dtb/olimex-a20-som-evb.dtb
/mnt/unused/dtb/pcduino3.dtb
/mnt/unused/dtb/sinovoip-bpi-m3.dtb
/mnt/unused/dtb/sun8i-a83t-sinovoip-bpi-m3.dtb
/mnt/unused/dtb/am335x-bone.dtb
/mnt/unused/dtb/am335x-boneblack.dtb
/mnt/unused/dtb/am335x-boneblack-wireless.dtb
/mnt/unused/dtb/am335x-bonegreen.dtb
/mnt/unused/dtb/am335x-bonegreen-wireless.dtb
/mnt/unused/dtb/am335x-boneblue.dtb
/mnt/unused/dtb/am335x-pocketbeagle.dtb
/mnt/unused/dtb/ufw.dtb
/mnt/unused/dtb/imx6dl-cubox-i.dtb
/mnt/unused/dtb/imx6q-cubox-i.dtb
/mnt/unused/dtb/imx6dl-hummingboard.dtb
/mnt/unused/dtb/imx6q-hummingboard.dtb
/mnt/unused/dtb/imx6dl-nitrogen6x.dtb
/mnt/unused/dtb/imx6q-nitrogen6_max.dtb
/mnt/unused/dtb/imx6q-nitrogen6x.dtb
/mnt/unused/dtb/imx6qp-nitrogen6_max.dtb
/mnt/unused/dtb/imx6sx-nitrogen6sx.dtb
/mnt/unused/dtb/imx6dl-riotboard.dtb
/mnt/unused/dtb/imx6dl-wandboard.dtb
/mnt/unused/dtb/imx6dl-wandboard-revb1.dtb
/mnt/unused/dtb/imx6q-wandboard.dtb
/mnt/unused/dtb/imx6q-wandboard-revb1.dtb
/mnt/unused/dtb/tegra124-jetson-tk1-fbsd.dtb
/mnt/unused/dtb/omap4-duovero-parlor.dtb
/mnt/unused/dtb/omap4-panda.dtb
/mnt/unused/dtb/omap4-panda-es.dtb
/mnt/unused/dtb/zedboard.dtb
/mnt/unused/dtb/zybo.dtb
/mnt/unused/fixup.dat
/mnt/unused/fixup_cd.dat
/mnt/unused/fixup_db.dat
/mnt/unused/fixup_x.dat
/mnt/unused/overlays
/mnt/unused/overlays/mmc.dtbo
/mnt/unused/start.elf
/mnt/unused/start_cd.elf
/mnt/unused/start_db.elf
/mnt/unused/start_x.elf
/mnt/unused/u-boot.bin
/mnt/unused/ubldr.bin
/mnt/unused/bootcode.bin-e [not sure where that came from, likely a typo]

and in /boot/msdos is
root@www:/usr/src # find /boot/msdos
/boot/msdos
/boot/msdos/ubldr.bin
/boot/msdos/EFI
/boot/msdos/EFI/BOOT
/boot/msdos/EFI/BOOT/bootarm.efi
/boot/msdos/dtb
/boot/msdos/dtb/allwinner
/boot/msdos/dtb/overlays
/boot/msdos/dtb/overlays/sun8i-a83t-sid.dtbo
/boot/msdos/dtb/overlays/sun8i-h3-i2c0.dtbo
/boot/msdos/dtb/overlays/spigen-rpi-b.dtbo
/boot/msdos/dtb/overlays/spigen-rpi2.dtbo
/boot/msdos/dtb/rockchip
/boot/msdos/dtb/sun4i-a10-cubieboard.dtb
/boot/msdos/dtb/sun4i-a10-olinuxino-lime.dtb
/boot/msdos/dtb/sun6i-a31s-sinovoip-bpi-m2.dtb
/boot/msdos/dtb/sun5i-a13-olinuxino.dtb
/boot/msdos/dtb/sun5i-r8-chip.dtb
/boot/msdos/dtb/sun7i-a20-bananapi.dtb
/boot/msdos/dtb/sun7i-a20-cubieboard2.dtb
/boot/msdos/dtb/sun7i-a20-lamobo-r1.dtb
/boot/msdos/dtb/sun7i-a20-olimex-som-evb.dtb
/boot/msdos/dtb/sun7i-a20-pcduino3.dtb
/boot/msdos/dtb/sun8i-a83t-bananapi-m3.dtb
/boot/msdos/dtb/sun8i-h2-plus-orangepi-r1.dtb
/boot/msdos/dtb/sun8i-h2-plus-orangepi-zero.dtb
/boot/msdos/dtb/sun8i-h3-nanopi-m1.dtb
/boot/msdos/dtb/sun8i-h3-nanopi-m1-plus.dtb
/boot/msdos/dtb/sun8i-h3-nanopi-neo.dtb
/boot/msdos/dtb/sun8i-h3-orangepi-one.dtb
/boot/msdos/dtb/sun8i-h3-orangepi-pc.dtb
/boot/msdos/dtb/sun8i-h3-orangepi-plus2e.dtb
/boot/msdos/dtb/cubieboard.dtb
/boot/msdos/dtb/olinuxino-lime.dtb
/boot/msdos/dtb/bananapim2.dtb
/boot/msdos/dtb/bananapi.dtb
/boot/msdos/dtb/cubieboard2.dtb
/boot/msdos/dtb/olimex-a20-som-evb.dtb
/boot/msdos/dtb/pcduino3.dtb
/boot/msdos/dtb/sinovoip-bpi-m3.dtb
/boot/msdos/dtb/sun8i-a83t-sinovoip-bpi-m3.dtb
/boot/msdos/dtb/am335x-bone.dtb
/boot/msdos/dtb/am335x-boneblack.dtb
/boot/msdos/dtb/am335x-boneblack-wireless.dtb
/boot/msdos/dtb/am335x-bonegreen.dtb
/boot/msdos/dtb/am335x-bonegreen-wireless.dtb
/boot/msdos/dtb/am335x-boneblue.dtb
/boot/msdos/dtb/am335x-pocketbeagle.dtb
/boot/msdos/dtb/ufw.dtb
/boot/msdos/dtb/imx6dl-cubox-i.dtb
/boot/msdos/dtb/imx6q-cubox-i.dtb
/boot/msdos/dtb/imx6dl-hummingboard.dtb
/boot/msdos/dtb/imx6q-hummingboard.dtb
/boot/msdos/dtb/imx6dl-nitrogen6x.dtb
/boot/msdos/dtb/imx6q-nitrogen6_max.dtb
/boot/msdos/dtb/imx6q-nitrogen6x.dtb
/boot/msdos/dtb/imx6qp-nitrogen6_max.dtb
/boot/msdos/dtb/imx6sx-nitrogen6sx.dtb
/boot/msdos/dtb/imx6dl-riotboard.dtb
/boot/msdos/dtb/imx6dl-wandboard.dtb
/boot/msdos/dtb/imx6dl-wandboard-revb1.dtb
/boot/msdos/dtb/imx6q-wandboard.dtb
/boot/msdos/dtb/imx6q-wandboard-revb1.dtb
/boot/msdos/dtb/tegra124-jetson-tk1-fbsd.dtb
/boot/msdos/dtb/omap4-duovero-parlor.dtb
/boot/msdos/dtb/omap4-panda.dtb
/boot/msdos/dtb/omap4-panda-es.dtb
/boot/msdos/dtb/zedboard.dtb
/boot/msdos/dtb/zybo.dtb
/boot/msdos/u-boot.bin
/boot/msdos/bootcode.bin
/boot/msdos/config.txt
/boot/msdos/fixup.dat
/boot/msdos/fixup_cd.dat
/boot/msdos/fixup_db.dat
/boot/msdos/fixup_x.dat
/boot/msdos/start.elf
/boot/msdos/start_cd.elf
/boot/msdos/start_db.elf
/boot/msdos/start_x.elf
/boot/msdos/bcm2709-rpi-2-b.dtb
/boot/msdos/overlays
/boot/msdos/overlays/mmc.dtbo
/boot/msdos/timeout
/boot/msdos/bootcode.bin-e
/boot/msdos/System Volume Information
/boot/msdos/System Volume Information/WPSettings.dat
/boot/msdos/System Volume Information/IndexerVolumeGuid
root@www:/usr/src # 



From nobody Tue Oct 11 18:37:25 2022
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 4Mn4Jv1HjJz4f8p5
	for ; Tue, 11 Oct 2022 18:37:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4Mn4Js6H3sz3FLr
	for ; Tue, 11 Oct 2022 18:37:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665513451; bh=oEIA827STBxtq8LgFBsjnWTSzfCaiQxcjeXoQaNbZf4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YtXAKJFRv7RFk35+0N8v3PoLbEemP0QdN3ow39i6E3eZ2TIV8eLaCKOpYRXNO43IUK7JW8bEGhFEUQD00nYEo35lBnxjG0025L+Pqj2Th+XJM4QJaRAhY5U5DHIgxdkyD5HeSrQkjG6zfvWDj2BNQ75rI/rqvABGPPrSCwAyJl10QlQLUs6quvm3Ssr49PsHHh19nUWPb8l66JYJkynhABlLhUN0fKGXIIfQU2uV88y7xnf4Edy6VFTx7q1TI0YLxp/FLu9+9jhU7AyS8bHU6UyC+iAVqtlEe7hgZWhUtHNvIg38zIfj1DW9/zbnc9BYdznoLbyiSt0Qb97gbBWb2Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665513451; bh=GLpnXGAovXkQLDSeYCTSJcn+zmOhAmfiXQN+cM8guid=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Xk9TIzVBNUVp1Ta2eYauZLYdrw+OLAedoNYN6LMYgS9Muqxi+SofVIA8x4P9DhWdwT2WLR0Mh8qBVhhtROkDK5siPxInEpzlQVRb75ZIbLjt9367VcL/th+hozLniXs3jebX3OyC/0m/H8AnF4lBjKtOR2FkmDw+G8KR51tIdG8YOEELC53v21I7ZzWQMGDOqLIu+MYZNTAggjdrR81YXRG7eNhWZRduGbIg4bNAvN23hPe/b4XORJD7+uiAq87kkSzjXMjMpsRh4DTYcUDSdshkVRpZ7OY49rzUjx0wF4lpE2C2RNoSWB5Svdf2o2+bhhAIizkjmZpnvfqwypiL5g==
X-YMail-OSG: uBq0WjYVM1mrb45jQzfMZy0aLRQHGZI6Kiip9OUZ4wPPFy5mc7rjTjt.PZLVfI1
 m3d5ceAiyWgBrBVaRHwh9ZpNXmjn5hxlZdLrV0_e8gfF67lpJheC9l.uoJqb7QiJNyKcX6Q0Wn.5
 Rq8QXUutgj_ba1b8ptBA51KOqaP_NMvva8Vk4JatuytI2fMerrlC1cm8tR3oTiytb8F5f2w6n7KL
 WnIjDuGvV_kWlDgntjr3JE.rhAwHqow6omETrIn66SIuCTkqVJHsc.40v3MU.8InsXipmk02yEpa
 4NlCsblaorIqyFAcUjoKYDublIL_Jum7zDvI16lZFya3_HP9VRQpMXmbhMg_NRSMYQYGp7lFXxpi
 YLp7_QFp4tHuKQFdAnneCt8np6NPoHkwHJSf868mlOiDxccmV_RFGsElPXYK1BiZJG0.uwhtob7F
 ddH9yLgqLLvJlt8ukb5hK16Na42dGGxEv1Jl7t7CQmeFQ_n2HaKr9V646Thx5sTc.UHElyy9Xkf8
 819pugET3nWoFzY5O5sgDiSmJeynbZRnPfYY9KD3JHveZXbgfNqiHrcNcV9fb5rPltuBlyVbRKHG
 degQiPRMpVwYTstRcPFfy5YJHKyi1mhrf_Vtgfn39fopS5TScQpXqftKsdT6mHOyoI0wsP7I2kl5
 lzrxhgT3cP_edlvqwdsGJYOJIB_TP5FqVwBna7Y4KhXlO7dEbYRL8o9p7qVT9px.LMIfjFX5WM79
 aKezIUMpzpQod5yhxs3GEX_SrHWmmul5P2D_0ju7jWzFb2KfwvurCDEz28oPHCJcGSY_X6_5w6dF
 JzQ7QIQ2DMQWRbZ5f1dhXHDZarLAT2Ndw_Pt6h7gy6qvTDDHtjRo3cQkLjjJ3.msJfnjKGQGrxpU
 LQ.88uVzoWtZjqgtak5RUa2LjPP8m81KrapFWoJ7.FBFEexKK9BEmq4KO8ZXS9eUejXb4h9l5DVP
 zW.M5gF2pDL1B3p8K_q7AWvhhVbiOZzhJePZPujAbUVABaO8DxCWw_LfbGG5SAkn9y0W2TCDNTMh
 nXvKgEcrVIOlk0NQidVBrUgvA.yP_3m6QoF8Ap967gzdg5n21KTWPfzK_uZp.uHYUtl8bD3o0f7w
 N5F6HUogU46r0iAkQszYYqYbIy6P37a70SbuUYFmHxrdfIdDeJiIB5bxUdCM7oyKWT8u5U5z43jB
 s0kH_dW_nSiMDrDRlor9QdZhaGBqgrLPBQ8aJaAxMbcpHSp5SlWHUHz6W8PRf0PwnmrLpPBkUiPd
 _ZVf4q3eHbHlRivYNOhBbXlcyd2n9X0fFkJ.3yV_j.c2pZeHmhB8w9IDoHstNwdkmg120lhAAwyu
 dfqQtFYPCr3xB4EedjQjsJ7SCuuRmFAb9GsRIHLlF_7_xIUAeSADAQBz0_64_m1WplhBHzjtUTfa
 EMkUHyC3hTfrqS2r2mjAgDz1b0chE3sz50IwF5KXMaZhARZJW8AMGN35uEDR39cl5ka7TdnomAEY
 35X.OV9GAkqAYKSSCborJiCMJXGhOpojHbCp2x9.9ChT31F2jAAga.5JKA0dfBU2Yuu3Y2LM4UJ8
 N0ZFnztApWDDfq9iMImmhKovIXIhh06awGTmXcQ.jLdTbsTvWhyvE8Yg0NVVfVctnw.Q7dCgFhoU
 gggr3tvpg89ZSneElTEwfDG7P5IC5ts4SSYGrNW.sSb9F1aoPv1dVcTW.qi.lj4QRVgieiiaKSKH
 EF5F9mo4d8Ar6qjByGOzporAn2GbG3ujAYPFNKlup1vDECAoylc6X1pNr234EVdXonS8FyCeOU4r
 4SYKD0TU.L7rH_ATq_tQmsNCm6zRwWemvXkROZIrJziaAy_0AQf78tWqaPcDYZ3oJTYJ91ffWOJw
 3J5MP2H22r62gQLyu5AAwNe8VKmBjDMUDA3TOvlUZIEPEQO5jzkCGJBXlbhx3Cx6xq1MjSe4vtgK
 wgSf2A7Jb_vUbQkftccPOJP6rK8AoGxUnqqkbmOUiygrnNMnfVAOBrvSn48LTfAE61ssWVcDQFg2
 oHgsGnVR_IBwA9s57PNEb3WeQ.6KpIgCcGjtQoxdQdGGnqYlTUH9ouazwQ71wbCunuWj__yQOBw_
 L36T0hgOFq.KaIRV5m0KTyKL6RKH9X6lbJKineueAx.jSC4KPCdPyIb4XecivEfGapuip7rQIDtc
 oOWazqfCr4bWRfaqDMWBex08hFCUgQTx12fZOmzvUqC95qL721TJwBmEbyxSTIOFPaj_M8y5Wln1
 X6WpmSaT9VqHy4Rb.qKayAGXgIKajLnCtUdU.WVxI9D9kxGCMFNarApq441I4hQKzMu1cMDjS6y9
 z4YdjYDM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 18:37:31 +0000
Received: by hermes--production-bf1-585bd66ffc-wfsbg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 55f8546647682e76dff50ec6a1440398;
          Tue, 11 Oct 2022 18:37:27 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)g
From: Mark Millard 
In-Reply-To: <20221011171548.GA12624@www.zefox.net>
Date: Tue, 11 Oct 2022 11:37:25 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <09A32530-3701-49F1-9369-549FF1162520@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
 <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
 <20221011171548.GA12624@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn4Js6H3sz3FLr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=YtXAKJFR;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.08 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.58)[-0.581];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 10:15, bob prohaska  wrote:

> On Tue, Oct 11, 2022 at 08:54:54AM -0700, Mark Millard wrote:
>> [I'd keep Warner out of our exchanges: too higih of a
>> volume. So I've dropped Warner from the reply.]
>>=20
>=20
> Ok, thanks.
>=20
>> On 2022-Oct-11, at 08:39, bob prohaska  wrote:
>>=20
>>>=20
>>> My Pi2B reporting=20
>>>=20
>>> FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #12 =
main-2b766d5e5a: Mon Jul 11 01:38:59 PDT 2022     =
bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
>>>=20
>>> is presently running buildworld on -current dated October 9th. If =
I'm=20
>>> understanding this thread correctly, running installworld will =
result
>>> in an ubootable system.=20
>>>=20
>>> Should I refrain from running installworld for the time being?
>>>=20
>>=20
>> If you have a working EFI loader in the msdosfs, just do not
>> update it. installworld does not update the msdosfs.
>>=20
>=20
> I don't see a file by that name in /boot/msdos, but there is a
> /boot/msdos/EFI/BOOT/bootarm.efi

For the armv7, EFI/BOOT/bootarm.efi is the EFI loader,
a copy of a /boot/loader_lua.efi or /boot/loader.efi
( hard links or copies of each other in /boot/ ).

aarch64 has slightly different EFI/BOOT/boot*.efi
naming for its EFI loader.

> It's surprisingly old:
> root@www:/usr/src # ls -l /boot/msdos/EFI/BOOT/bootarm.efi
> -rwxr-xr-x  1 root  wheel  674864 Jul  2  2020 =
/boot/msdos/EFI/BOOT/bootarm.efi

EFI/BOOT/bootarm.efi is only updated when you go to the
trouble to update it. No standard procedure updates it.

It is fairly common that a EFI loader just works over a
long time but it can be important to update before
upgrading ZFS pools to have new features.

> Is that the EFI loader referred to? If so I think it's safe.=20

Yes. For now, just do not update EFI/BOOT/bootarm.efi .

> Thanks for reading,
>=20
> bob prohaska
> ps: Just for completeness, at the moment I have on microSD:

Actually the below is confusing. /boot/msdos
is supposed to be a mount point (empty directory)
at which the msdosfs can be mounted to make those
files show up there, despite being from a different
file system. (/boot/efi is similar and going forward
/boot/msdos will be a symbolic link to /boot/efi
as I understand. However, in the latest 14
snapshot it is messed up:

# ls -Tld /boot/msdos /boot/efi
drwxr-xr-x  1 root  wheel  16384 Jan  1 00:00:00 1980 /boot/efi
lrwxr-xr-x  1 root  wheel     51 Oct  7 10:36:20 2022 /boot/msdos -> =
/usr/obj/usr/src/arm.armv7/release/GENERIC/boot/efi

Without "df -m" and "gpart show -p" output I can
not tell what is what.

> root@www:/usr/src # find /mnt

What is mounted at /mnt ? Or is it not being used
as a mount point?

> /mnt
> /mnt/bootcode.bin [special usb-boot version]
> /mnt/timeout
> /mnt/unused
> /mnt/unused/EFI
> /mnt/unused/EFI/BOOT
> /mnt/unused/EFI/BOOT/bootarm.efi
> /mnt/unused/bcm2709-rpi-2-b.dtb
> /mnt/unused/bootcode.bin
> /mnt/unused/config.txt
> /mnt/unused/dtb
> /mnt/unused/dtb/allwinner
> /mnt/unused/dtb/overlays
> /mnt/unused/dtb/overlays/sun8i-a83t-sid.dtbo
> /mnt/unused/dtb/overlays/sun8i-h3-i2c0.dtbo
> /mnt/unused/dtb/overlays/spigen-rpi-b.dtbo
> /mnt/unused/dtb/overlays/spigen-rpi2.dtbo
> /mnt/unused/dtb/rockchip
> /mnt/unused/dtb/sun4i-a10-cubieboard.dtb
> /mnt/unused/dtb/sun4i-a10-olinuxino-lime.dtb
> /mnt/unused/dtb/sun6i-a31s-sinovoip-bpi-m2.dtb
> /mnt/unused/dtb/sun5i-a13-olinuxino.dtb
> /mnt/unused/dtb/sun5i-r8-chip.dtb
> /mnt/unused/dtb/sun7i-a20-bananapi.dtb
> /mnt/unused/dtb/sun7i-a20-cubieboard2.dtb
> /mnt/unused/dtb/sun7i-a20-lamobo-r1.dtb
> /mnt/unused/dtb/sun7i-a20-olimex-som-evb.dtb
> /mnt/unused/dtb/sun7i-a20-pcduino3.dtb
> /mnt/unused/dtb/sun8i-a83t-bananapi-m3.dtb
> /mnt/unused/dtb/sun8i-h2-plus-orangepi-r1.dtb
> /mnt/unused/dtb/sun8i-h2-plus-orangepi-zero.dtb
> /mnt/unused/dtb/sun8i-h3-nanopi-m1.dtb
> /mnt/unused/dtb/sun8i-h3-nanopi-m1-plus.dtb
> /mnt/unused/dtb/sun8i-h3-nanopi-neo.dtb
> /mnt/unused/dtb/sun8i-h3-orangepi-one.dtb
> /mnt/unused/dtb/sun8i-h3-orangepi-pc.dtb
> /mnt/unused/dtb/sun8i-h3-orangepi-plus2e.dtb
> /mnt/unused/dtb/cubieboard.dtb
> /mnt/unused/dtb/olinuxino-lime.dtb
> /mnt/unused/dtb/bananapim2.dtb
> /mnt/unused/dtb/bananapi.dtb
> /mnt/unused/dtb/cubieboard2.dtb
> /mnt/unused/dtb/olimex-a20-som-evb.dtb
> /mnt/unused/dtb/pcduino3.dtb
> /mnt/unused/dtb/sinovoip-bpi-m3.dtb
> /mnt/unused/dtb/sun8i-a83t-sinovoip-bpi-m3.dtb
> /mnt/unused/dtb/am335x-bone.dtb
> /mnt/unused/dtb/am335x-boneblack.dtb
> /mnt/unused/dtb/am335x-boneblack-wireless.dtb
> /mnt/unused/dtb/am335x-bonegreen.dtb
> /mnt/unused/dtb/am335x-bonegreen-wireless.dtb
> /mnt/unused/dtb/am335x-boneblue.dtb
> /mnt/unused/dtb/am335x-pocketbeagle.dtb
> /mnt/unused/dtb/ufw.dtb
> /mnt/unused/dtb/imx6dl-cubox-i.dtb
> /mnt/unused/dtb/imx6q-cubox-i.dtb
> /mnt/unused/dtb/imx6dl-hummingboard.dtb
> /mnt/unused/dtb/imx6q-hummingboard.dtb
> /mnt/unused/dtb/imx6dl-nitrogen6x.dtb
> /mnt/unused/dtb/imx6q-nitrogen6_max.dtb
> /mnt/unused/dtb/imx6q-nitrogen6x.dtb
> /mnt/unused/dtb/imx6qp-nitrogen6_max.dtb
> /mnt/unused/dtb/imx6sx-nitrogen6sx.dtb
> /mnt/unused/dtb/imx6dl-riotboard.dtb
> /mnt/unused/dtb/imx6dl-wandboard.dtb
> /mnt/unused/dtb/imx6dl-wandboard-revb1.dtb
> /mnt/unused/dtb/imx6q-wandboard.dtb
> /mnt/unused/dtb/imx6q-wandboard-revb1.dtb
> /mnt/unused/dtb/tegra124-jetson-tk1-fbsd.dtb
> /mnt/unused/dtb/omap4-duovero-parlor.dtb
> /mnt/unused/dtb/omap4-panda.dtb
> /mnt/unused/dtb/omap4-panda-es.dtb
> /mnt/unused/dtb/zedboard.dtb
> /mnt/unused/dtb/zybo.dtb
> /mnt/unused/fixup.dat
> /mnt/unused/fixup_cd.dat
> /mnt/unused/fixup_db.dat
> /mnt/unused/fixup_x.dat
> /mnt/unused/overlays
> /mnt/unused/overlays/mmc.dtbo
> /mnt/unused/start.elf
> /mnt/unused/start_cd.elf
> /mnt/unused/start_db.elf
> /mnt/unused/start_x.elf
> /mnt/unused/u-boot.bin
> /mnt/unused/ubldr.bin
> /mnt/unused/bootcode.bin-e [not sure where that came from, likely a =
typo]
>=20
> and in /boot/msdos is
> root@www:/usr/src # find /boot/msdos

What is mounted at /boot/msdos ? Or is it not being used
as a mount point?

> /boot/msdos
> /boot/msdos/ubldr.bin
> /boot/msdos/EFI
> /boot/msdos/EFI/BOOT
> /boot/msdos/EFI/BOOT/bootarm.efi
> /boot/msdos/dtb
> /boot/msdos/dtb/allwinner
> /boot/msdos/dtb/overlays
> /boot/msdos/dtb/overlays/sun8i-a83t-sid.dtbo
> /boot/msdos/dtb/overlays/sun8i-h3-i2c0.dtbo
> /boot/msdos/dtb/overlays/spigen-rpi-b.dtbo
> /boot/msdos/dtb/overlays/spigen-rpi2.dtbo
> /boot/msdos/dtb/rockchip
> /boot/msdos/dtb/sun4i-a10-cubieboard.dtb
> /boot/msdos/dtb/sun4i-a10-olinuxino-lime.dtb
> /boot/msdos/dtb/sun6i-a31s-sinovoip-bpi-m2.dtb
> /boot/msdos/dtb/sun5i-a13-olinuxino.dtb
> /boot/msdos/dtb/sun5i-r8-chip.dtb
> /boot/msdos/dtb/sun7i-a20-bananapi.dtb
> /boot/msdos/dtb/sun7i-a20-cubieboard2.dtb
> /boot/msdos/dtb/sun7i-a20-lamobo-r1.dtb
> /boot/msdos/dtb/sun7i-a20-olimex-som-evb.dtb
> /boot/msdos/dtb/sun7i-a20-pcduino3.dtb
> /boot/msdos/dtb/sun8i-a83t-bananapi-m3.dtb
> /boot/msdos/dtb/sun8i-h2-plus-orangepi-r1.dtb
> /boot/msdos/dtb/sun8i-h2-plus-orangepi-zero.dtb
> /boot/msdos/dtb/sun8i-h3-nanopi-m1.dtb
> /boot/msdos/dtb/sun8i-h3-nanopi-m1-plus.dtb
> /boot/msdos/dtb/sun8i-h3-nanopi-neo.dtb
> /boot/msdos/dtb/sun8i-h3-orangepi-one.dtb
> /boot/msdos/dtb/sun8i-h3-orangepi-pc.dtb
> /boot/msdos/dtb/sun8i-h3-orangepi-plus2e.dtb
> /boot/msdos/dtb/cubieboard.dtb
> /boot/msdos/dtb/olinuxino-lime.dtb
> /boot/msdos/dtb/bananapim2.dtb
> /boot/msdos/dtb/bananapi.dtb
> /boot/msdos/dtb/cubieboard2.dtb
> /boot/msdos/dtb/olimex-a20-som-evb.dtb
> /boot/msdos/dtb/pcduino3.dtb
> /boot/msdos/dtb/sinovoip-bpi-m3.dtb
> /boot/msdos/dtb/sun8i-a83t-sinovoip-bpi-m3.dtb
> /boot/msdos/dtb/am335x-bone.dtb
> /boot/msdos/dtb/am335x-boneblack.dtb
> /boot/msdos/dtb/am335x-boneblack-wireless.dtb
> /boot/msdos/dtb/am335x-bonegreen.dtb
> /boot/msdos/dtb/am335x-bonegreen-wireless.dtb
> /boot/msdos/dtb/am335x-boneblue.dtb
> /boot/msdos/dtb/am335x-pocketbeagle.dtb
> /boot/msdos/dtb/ufw.dtb
> /boot/msdos/dtb/imx6dl-cubox-i.dtb
> /boot/msdos/dtb/imx6q-cubox-i.dtb
> /boot/msdos/dtb/imx6dl-hummingboard.dtb
> /boot/msdos/dtb/imx6q-hummingboard.dtb
> /boot/msdos/dtb/imx6dl-nitrogen6x.dtb
> /boot/msdos/dtb/imx6q-nitrogen6_max.dtb
> /boot/msdos/dtb/imx6q-nitrogen6x.dtb
> /boot/msdos/dtb/imx6qp-nitrogen6_max.dtb
> /boot/msdos/dtb/imx6sx-nitrogen6sx.dtb
> /boot/msdos/dtb/imx6dl-riotboard.dtb
> /boot/msdos/dtb/imx6dl-wandboard.dtb
> /boot/msdos/dtb/imx6dl-wandboard-revb1.dtb
> /boot/msdos/dtb/imx6q-wandboard.dtb
> /boot/msdos/dtb/imx6q-wandboard-revb1.dtb
> /boot/msdos/dtb/tegra124-jetson-tk1-fbsd.dtb
> /boot/msdos/dtb/omap4-duovero-parlor.dtb
> /boot/msdos/dtb/omap4-panda.dtb
> /boot/msdos/dtb/omap4-panda-es.dtb
> /boot/msdos/dtb/zedboard.dtb
> /boot/msdos/dtb/zybo.dtb
> /boot/msdos/u-boot.bin
> /boot/msdos/bootcode.bin
> /boot/msdos/config.txt
> /boot/msdos/fixup.dat
> /boot/msdos/fixup_cd.dat
> /boot/msdos/fixup_db.dat
> /boot/msdos/fixup_x.dat
> /boot/msdos/start.elf
> /boot/msdos/start_cd.elf
> /boot/msdos/start_db.elf
> /boot/msdos/start_x.elf
> /boot/msdos/bcm2709-rpi-2-b.dtb
> /boot/msdos/overlays
> /boot/msdos/overlays/mmc.dtbo
> /boot/msdos/timeout
> /boot/msdos/bootcode.bin-e
> /boot/msdos/System Volume Information
> /boot/msdos/System Volume Information/WPSettings.dat
> /boot/msdos/System Volume Information/IndexerVolumeGuid
> root@www:/usr/src #=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 18:50:29 2022
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 4Mn4bv5Vfsz4fBcK
	for ; Tue, 11 Oct 2022 18:50:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4Mn4bv0QKNz3KTs
	for ; Tue, 11 Oct 2022 18:50:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665514233; bh=QxV7lJX3U6+D/iYPZIrYep1N0JxCl6F9EodSNOOP0SM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RtZ583xzWKtqXAR52dFzmejjr30xhIIYm3jIMyne7wIQ0xGDqsMZtzWsM5nhMDnpNDv8kwI44X8WRA/Q/V4cCYoAzVJ1cSMvp0wT93lhGzxJ87qzpFuoe6Il3otM6JUBBkYphUgTPrbt9zhpD70NJPn4a6bUAxpfUmRYg1Vu6LWCsBzjXW44mCrE0dO19mXECOonSmzFkev7OwTXsD/c198A9/HU6Dsf0cdrLPvxwKSukfxJJDxICgEaKWxXEpfXBjf91ezcsrQP6tC6yFeRFaqaxtUUUPHCDstoUck/ZOK9mP3JfUIiweCsrmELKn0Onl/JSpZLSN2o9ibD1mFzSA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665514233; bh=MSr1MWEO1MZDMosM908ORKdWGKvUxWcasr3N4VjMMY8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=egcsL1Zbbo+UXgWwwcoEQB5/6+W4UEmqlmsz7vtGtxKQCXawUo7+RuzGStm3K46vTjFCDzpgWYWrAiwcvcqXOUyreIKzyXtSnk0ZuK0+HSueS4tlSn2OP8uaMiqIJGZcsmwU8LGa+ndWkdEkZ/6gc7zwaIz081GwlMrBGF4ZKgrbSVLBOAHplu5tf+m4LIRmS/PdTWojgwQg3tg7FQYdm8Ep8qeJUM7s/6nrSlmKTD1bE/rC5iUn7jIroXSkyYns6gaDcdiO4IULJwfPgqdhvZYSvv7taDMqktl4HH4hNdM9zrERHoxRFOvvvgLZFwWXCBeruQAWHV9Hr14GpWAdkA==
X-YMail-OSG: aRadXcgVM1luxNc6GrmDYygpWiRLCbwrU5gEjH8EcfnmAOv7qYKgArbt9i180u7
 kfN8domEw5gssTNN5v5JJgkqOJoPMiXGtGRz21t_sFUYfC48I8o0a_sftLmVjFtqV8SyoQ5ZCvAG
 _6wqfarwUdTAKGa5jKVPVExAB12PptVcpFxgj_t2Pt6bvJcGiJbC2YKv7ZDW.R.tbM_TIgQkIg.O
 g5I023hjrE2ZdptB27KCg_7Q5hm60n6UEVs4BKHNehl3Jg4hnztXBVE2UJXcSG32zD.vDi0rgoaL
 FSW4cvwoykZcwrzM5SdBM9R80K8PnpmuIp81SlPwWA7Z_heFHRTXHrebTSHHcR1_k4S3qT3IKEBe
 3QuSqOQFOY66HIyVE34hhigK9tD8bFcUQVYHsQ8_kMr2IW3WLRjiW8UdsBMG_ThzwlQDiWAVUO.C
 WL3yiTEtgxGpmlXGj7zN0kNgqeTeqI.Po30ZLlLUcBbRGAiKfi9CadY9KfelLb5vIxPLQMRMVT9w
 AWZH71JpRBOeke43.T0K4vNglfQy14NxqtzgVkcJ0xq_xPEDUt8vRH0OVOrd87DhWM4Xoo3Udj3d
 _ZXPDSGvMTtfEpFsJ4J9MVW4sGkt2hl1mtHDpQk2i4Z2pB8AmqL2sBhCuu3RpzdAWAeQs.wY_w9U
 VLGzXKbkIAenoU9o2IwAXi1oHM3XUlgFB59e66yND4jr2x1svyVEIpGYqICH0cyCrz4sufnjk7jn
 HsCt5UBkrx6ZDvFzI6ZOYguCcU.RSh2iiZ0ptEc6ZmivqGmwrP8RvLxzfaXhFHwrPyEBbNxfYepE
 PszmQ9n_JGNLys481HwogOptsjyF7GAOkvSzPw__GCzgADwKNGqLuRbsbxYh0XTcLT2AavuNKnVz
 3EX6Nqd0aErmTQZsAmvVbSuvRqCbqoGOa8Jn9fvBZcD5NnoFnURhuLBOViYI9a9LHbCeAOT6mZPn
 jiNVzaUEGND2cSzsy58mBEOEkI3cS_ZyCI1nb2HpP1iFPMm3nI8bq6q7wqak9EifERH.sTpy1Ygk
 FX_UiM1uc2aM1p6C.ucMu6FZ1Tc_UpSzNXzPAVUtTRPtRX3VqedAqzX3WqIFGV.4OpR0fJZl7l.A
 tnbs3XxJm1ikGdD2j1nxKg65gZp591wN2SB2j9A3oAN1B1FsIEGocGsXxu_wVmvzP0mm8huqn3nB
 jObAsuSGJpHNdUPAE_5C7kDa7vCjfWx18oAHM8iqACFMuxyKwmB402B7gMIxJYCIyCcF_zR9T5kH
 dX7BiCwKPSjZt1NClttdNPoha00ILVyrLTJ3bhXNhL6DF4jiogPjh0vShscmLdg5JnjS3CPLSJfp
 hqtpm7RUd1JKXFdUsnuUcOJa6QK2ZQuK340aKCgV5wu519fFWV099bxLPIfTMwyWAxa5QXlFhCNT
 HgSCO.AGnt.NKDIPhLm8W3ltNGu1v3XoqmaTq0LbzSSk5.UEVxneSlGEJmYIglwXwuZnWK2HS1r8
 JoOhvo52YVVnZE4saXREwZ3MhlIejLakOcfcdaHhjuBIa8eNblaE9FNi7orjvuN3HdU8fOcL5Es7
 qxwv_s7dV7eDyQvHU9kjmmBT1.nxtsqkpIQJUFoebtnszfkkg4JVyoCF9PoWL00esD0tZeEuII6F
 3owvwMNVjTsB4X7Vzb657MrcV8FKAQ9Q6sAxmbXDIfllBkESpOLC0PGVq5Gs6r5Y_yEyHZ4kcZpi
 OlkcoKtk0gP21qIH9uMAI.timzKujeoP8oLW0YjR7OxdSp75gG1awLGHTWrz7ndVbyImlm85LdwK
 tRPA94.mlC2XZG3QbOYOGM.cPTREfl0z6mrpwtwALk7T49W4Zlz15g66StO5ZbN_w4Cyy02zyLEz
 7moa3qDuBENUp6bWHVNlTxdAkz_ywkA669lFxdAuB_Ie2jd2a4YbuRklm2k_QYFsGW1MHwKyEDR0
 .2WYo51j0DeUeIiY6ugPZl7FPCSNLiqMmLJAZ_1OXMcsH_PFEbZk6SL1LOUwLGK3JEm3O0aR_XMQ
 DZXTOIPIxf8X6YhqBR.9Bwrs6Zjle33s06.j9VCXUAmcHODHumCIKV6ViVfKGKWaTwQKNszTja9Y
 d_X60tQG59o9zzFJYpvIdjQOo9JBnQDucCI1oSnWqW65_PDZ7dVvrIJuiWX.8ndKJMIBOPwZUUUu
 b99uqRs8Z1H5kF874dCGGsHpJNxCAUMeF8HCHnqq5COO2Maqohi5ep6ukLtVOxiCrBiJl.awBAzi
 stz01Likja2Kkz5GR1dQLkGGyrk9bD0qTDkuXn20wBXC5bxXaKuBopVfj2Lvf7cT.bjSiYZ3BmOb
 PqjxOuY72Xfmq2zfrZnzCm0TiwuJKWuY9900i0ZFxNQoU_w94_iB8K6l.4DSiN3XIIM0ab7JCwyo
 LR8NROkMF9zlEmwgvKvy1AhB.32yF.8E2rGfRN3ZY_bO3kbS2
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Oct 2022 18:50:33 +0000
Received: by hermes--production-gq1-75cfcccdb-gdnml (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9aeca3cc41f48e7d4bd26f3638d304c4;
          Tue, 11 Oct 2022 18:50:30 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
Date: Tue, 11 Oct 2022 11:50:29 -0700
Cc: freebsd-arm ,
 bob prohaska 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mn4bv0QKNz3KTs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RtZ583xz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 09:20, Mark Millard  wrote:

> [Summary: Both somewhat before and just after your ConOut commit
> work. I'll have to do a rough bisect with the available armv7
> artifacts that are after those but before October.]
>=20
> On 2022-Oct-11, at 08:26, Mark Millard  wrote:
>=20
>> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
>> . . .
>>> . . .
>>>=20
>>> The change was made in late August that I'm thinking of, so if you =
could find a
>>> snapshot from early August July that would be a useful data point:
>>>=20
>>> commit df065f699f1ff819bb9607c44a6754275ab335ed
>>> Author: Warner Losh 
>>> Date:   Fri Aug 26 15:46:33 2022 -0600
>>>=20
>>>   stand: More sensible defaults when ConOut is missing
>>=20
>> I'll look at finding and trying some artifact build to extract a
>> armv7 EFI loader from. Available snapshot history does not
>> go back that far so far as I know.
>>=20
>> But I may not be able to look into this immediately.
>>=20
>> In main:
>>=20
>> commit df065f699f1ff819bb9607c44a6754275ab335ed
>> Author:     Warner Losh 
>> AuthorDate: 2022-08-26 21:46:33 +0000
>> Commit:     Warner Losh 
>> CommitDate: 2022-08-27 04:17:56 +0000
>>=20
>> It looks like the closest prior artifact is at:
>>=20
>> =
https://artifact.ci.freebsd.org/snapshot/main/a358db5603702d5de5fd75f5bd16=
bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD
>> git: a358db560370 - main - socket(2): bring documentation up tp date =
Gleb Smirnoff
>>=20
>> with date/time: 2022-Aug-26 16:26
>>=20
>> So I expect to use that.
>=20
> Turns out that I had the time.
>=20
> Use of the ./boot/loader.efi from a358db560370 substituted
> into the failing main snapshot based microsd card worked
> fine for both contexts:
>=20
> A) Just serial console.
> and:
> B) Serial console and HDMI console at the same time.
>=20
> I also tried the oldest artifact build with the loader change
> in place:
>=20
> =
https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea68c=
3be9c2ed50ce/arm/armv7/
> git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner =
Losh
> Date/time: 2022-Aug-27 05:12
>=20
> This also worked for both (A) and (B).
>=20
> So it looks like I'll be doing a rough bisect to find a
> before/after pair. It might have some elapsed time to
> finish.

The date/times encoded into the file names below
are those shown for base.txz . The overall artifact
directory date/time is somewhat later. The -good
vs. -bad suffix indicates the boot status.

# ls -C1d *
boot-2022-08-26-16-26-a358db560370-good
boot-2022-08-27-05-12-7ed3228323ef-good
boot-2022-09-12-18-30-c198adf39498-good
boot-2022-09-15-01-28-145a50dcda7a-good
boot-2022-09-16-14-26-b4174079576a-good
boot-2022-09-16-15-45-b44869cba1b3-good
boot-2022-09-16-18-02-dd2b9c296776-bad
boot-2022-09-16-20-51-30cfb3c8ee3d-bad
boot-2022-09-18-00-46-c3707bd3d658-bad

For:

boot-2022-09-16-15-45-b44869cba1b3-good
boot-2022-09-16-18-02-dd2b9c296776-bad

there are no armv7 artifacts available between.

The range is:

	=E2=80=A2 git: b44869cba1b3 - main - sound: add patch for Lenovo =
Legion 5 Intel Nuno Teixeira=20
	=E2=80=A2 git: a705c72f2142 - main - stand: use =
archsw.arch_copyin instead of i386_copyin Warner Losh=20
	=E2=80=A2 git: 4c670b53a000 - main - stand: use =
archsw.arch_copyin instead of direct call Warner Losh=20
	=E2=80=A2 git: 8b19d28d68a3 - main - stand: Create MOD_ALIGN =
macro and use it everywhere Warner Losh=20
	=E2=80=A2 git: bca9c87b6104 - main - stand: Create =
common/modinfo.h Warner Losh=20
	=E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move md_copymodules =
into modinfo.c and reduce copies Warner Losh=20
	=E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx macros =
from modinfo.h to .c Warner Losh=20
	=E2=80=A2 git: fc352701ff3a - main - stand: collapse all copies =
of *copyenv into md_copyenv Warner Losh=20
	=E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store to =
bi_kernelname Warner Losh=20
	=E2=80=A2 git: d43bcf62a218 - main - stand: Stop support booting =
4.x and earlier kernels Warner Losh=20
	=E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete =
fields in bootinfo with _was_ Warner Losh=20
	=E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader =
smaller by reducing size of bootinfo Warner Losh=20
	=E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo =
rather than have it be static Warner Losh=20
	=E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support =
swapping headers on powerpc. Warner Losh=20
	=E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge Warner =
Losh=20



Side note about /boot/msdos :

The Oct-07 snapshot of main [so: 14] has:

# ls -Tld /boot/msdos /boot/efi
drwxr-xr-x  1 root  wheel  16384 Jan  1 00:00:00 1980 /boot/efi
lrwxr-xr-x  1 root  wheel     51 Oct  7 10:36:20 2022 /boot/msdos -> =
/usr/obj/usr/src/arm.armv7/release/GENERIC/boot/efi

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 11 19:03:29 2022
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 4Mn4v303Vqz4fCm3
	for ; Tue, 11 Oct 2022 19:03:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4Mn4v20BwYz3MbP
	for ; Tue, 11 Oct 2022 19:03:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ej1-x634.google.com with SMTP id b2so33488852eja.6
        for ; Tue, 11 Oct 2022 12:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=+pfzdL6u56bSi5jLa8ifznmCWF1EnoF1nHYk0RHIDug=;
        b=0SxOMejthTwAGnG8IGoLs09emrh9gVzbCfWn0LMHDu2OEJ79N56TBKYANcXQ3gQg08
         PvMHVfyUUY83Xgl+CSAxd1dNeyM7cT5yNg/FLE1mRJP3+yh735UELa8upe0TpZQVKCfC
         ONOqspE/QK5vmpdXZU9MJkineFWSfsTrWWPC2EivO7GdxSFe8pRPHP1JasAMWqJiIrnS
         lzkPBYBfI88rq5Z8Y75I3GK27Nrxpn5KzleS5siZw1HqjsamlkahcT9CVQYQmsNBLRdH
         O15ZnH0JZckUe0TWT/2qJRHzm+JIfNVjB6lib//oJTnWGCRk9IYoU4IlMDjDBfWVLEVg
         J08w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=+pfzdL6u56bSi5jLa8ifznmCWF1EnoF1nHYk0RHIDug=;
        b=o86km+X4y0aWBZ9qg497ryH/DRGHSnXaHSB33y53ZfqxgwWBUAJTr2Yoky1pdMgxXQ
         3NJhma/znDZMhYNt8oeL/NNPsn7RGtU4AZUCvVBo14PUe5h/tnF+/PtHu1T+TnZH66am
         8Oq5l+wpCIb4J6w1kIfoceMEfiXCaL+jCRzjAfwGHZFnTsAXYgFZqqzy3TTeK020BFf4
         XVlEW4YwSm4V5PGeyP2fMR5YSN8wmscfmGprP6vfbnmzPPML8XuZ0Q6Aa4v/d3Bu/QO9
         Dz3nUHkvplnPTlCCwaaFqWNTrE1PTqAJOwruBDbmKV7puoMBnodRipttu2Mo4dEpyOuw
         jP7A==
X-Gm-Message-State: ACrzQf1q6bE44XR/HtqD8Wt1Y6bifqme7IQDo+6prbijkHmtSj7DVTCL
	tA9fCzy2E+4YORjMk6ixZEaGWSifBrTm6D6EXO6gAKHyIro=
X-Google-Smtp-Source: AMsMyM5AsNItwOYK2a56qSooKWu7vivK4zjkn0wmNZsgvCUiHGdvs3hvS0QOTz3IyYLlOlALfEzNSVWurswcwMpf6hc=
X-Received: by 2002:a17:907:969e:b0:782:6b92:6b1f with SMTP id
 hd30-20020a170907969e00b007826b926b1fmr19316075ejc.140.1665515020714; Tue, 11
 Oct 2022 12:03:40 -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: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
  
  
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com> <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
 <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
In-Reply-To: <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
From: Warner Losh 
Date: Tue, 11 Oct 2022 13:03:29 -0600
Message-ID: 
Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
 is broken for RPi2 v1.1 (so: armv7)
To: Mark Millard 
Cc: freebsd-arm , bob prohaska 
Content-Type: multipart/alternative; boundary="0000000000002daa3705eac6ef98"
X-Rspamd-Queue-Id: 4Mn4v20BwYz3MbP
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=0SxOMejt;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::634) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002daa3705eac6ef98
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 11, 2022 at 12:50 PM Mark Millard  wrote:

> On 2022-Oct-11, at 09:20, Mark Millard  wrote:
>
> > [Summary: Both somewhat before and just after your ConOut commit
> > work. I'll have to do a rough bisect with the available armv7
> > artifacts that are after those but before October.]
> >
> > On 2022-Oct-11, at 08:26, Mark Millard  wrote:
> >
> >> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
> >> . . .
> >>> . . .
> >>>
> >>> The change was made in late August that I'm thinking of, so if you
> could find a
> >>> snapshot from early August July that would be a useful data point:
> >>>
> >>> commit df065f699f1ff819bb9607c44a6754275ab335ed
> >>> Author: Warner Losh 
> >>> Date:   Fri Aug 26 15:46:33 2022 -0600
> >>>
> >>>   stand: More sensible defaults when ConOut is missing
> >>
> >> I'll look at finding and trying some artifact build to extract a
> >> armv7 EFI loader from. Available snapshot history does not
> >> go back that far so far as I know.
> >>
> >> But I may not be able to look into this immediately.
> >>
> >> In main:
> >>
> >> commit df065f699f1ff819bb9607c44a6754275ab335ed
> >> Author:     Warner Losh 
> >> AuthorDate: 2022-08-26 21:46:33 +0000
> >> Commit:     Warner Losh 
> >> CommitDate: 2022-08-27 04:17:56 +0000
> >>
> >> It looks like the closest prior artifact is at:
> >>
> >>
> https://artifact.ci.freebsd.org/snapshot/main/a358db5603702d5de5fd75f5bd1=
6bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD
> >> git: a358db560370 - main - socket(2): bring documentation up tp date
> Gleb Smirnoff
> >>
> >> with date/time: 2022-Aug-26 16:26
> >>
> >> So I expect to use that.
> >
> > Turns out that I had the time.
> >
> > Use of the ./boot/loader.efi from a358db560370 substituted
> > into the failing main snapshot based microsd card worked
> > fine for both contexts:
> >
> > A) Just serial console.
> > and:
> > B) Serial console and HDMI console at the same time.
> >
> > I also tried the oldest artifact build with the loader change
> > in place:
> >
> >
> https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea68=
c3be9c2ed50ce/arm/armv7/
> > git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner
> Losh
> > Date/time: 2022-Aug-27 05:12
> >
> > This also worked for both (A) and (B).
> >
> > So it looks like I'll be doing a rough bisect to find a
> > before/after pair. It might have some elapsed time to
> > finish.
>
> The date/times encoded into the file names below
> are those shown for base.txz . The overall artifact
> directory date/time is somewhat later. The -good
> vs. -bad suffix indicates the boot status.
>
> # ls -C1d *
> boot-2022-08-26-16-26-a358db560370-good
> boot-2022-08-27-05-12-7ed3228323ef-good
> boot-2022-09-12-18-30-c198adf39498-good
> boot-2022-09-15-01-28-145a50dcda7a-good
> boot-2022-09-16-14-26-b4174079576a-good
> boot-2022-09-16-15-45-b44869cba1b3-good
> boot-2022-09-16-18-02-dd2b9c296776-bad
> boot-2022-09-16-20-51-30cfb3c8ee3d-bad
> boot-2022-09-18-00-46-c3707bd3d658-bad
>
> For:
>
> boot-2022-09-16-15-45-b44869cba1b3-good
> boot-2022-09-16-18-02-dd2b9c296776-bad
>
> there are no armv7 artifacts available between.
>
> The range is:
>
>         =E2=80=A2 git: b44869cba1b3 - main - sound: add patch for Lenovo =
Legion 5
> Intel Nuno Teixeira
>         =E2=80=A2 git: a705c72f2142 - main - stand: use archsw.arch_copyi=
n instead
> of i386_copyin Warner Losh
>         =E2=80=A2 git: 4c670b53a000 - main - stand: use archsw.arch_copyi=
n instead
> of direct call Warner Losh
>         =E2=80=A2 git: 8b19d28d68a3 - main - stand: Create MOD_ALIGN macr=
o and use
> it everywhere Warner Losh
>         =E2=80=A2 git: bca9c87b6104 - main - stand: Create common/modinfo=
.h Warner
> Losh
>         =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move md_copymodules i=
nto
> modinfo.c and reduce copies Warner Losh
>         =E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx macros f=
rom
> modinfo.h to .c Warner Losh
>         =E2=80=A2 git: fc352701ff3a - main - stand: collapse all copies o=
f
> *copyenv into md_copyenv Warner Losh
>         =E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store to
> bi_kernelname Warner Losh
>         =E2=80=A2 git: d43bcf62a218 - main - stand: Stop support booting =
4.x and
> earlier kernels Warner Losh
>         =E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete fiel=
ds in
> bootinfo with _was_ Warner Losh
>         =E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader small=
er by
> reducing size of bootinfo Warner Losh
>         =E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo rat=
her than
> have it be static Warner Losh
>         =E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support swap=
ping
> headers on powerpc. Warner Losh
>         =E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge Warner L=
osh
>

Yea, I did a bunch of refactoring. I'm surprised that this produced a
change at all. Would be nice to
know which one of these caused the problems.


> Side note about /boot/msdos :
>
> The Oct-07 snapshot of main [so: 14] has:
>
> # ls -Tld /boot/msdos /boot/efi
> drwxr-xr-x  1 root  wheel  16384 Jan  1 00:00:00 1980 /boot/efi
> lrwxr-xr-x  1 root  wheel     51 Oct  7 10:36:20 2022 /boot/msdos ->
> /usr/obj/usr/src/arm.armv7/release/GENERIC/boot/efi
>

That's likely my fault, it should be a link to a plain 'efi' I'll prep a
fix.

Warner

--0000000000002daa3705eac6ef98
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Oct 11, 2022 at 12:50 PM Mark=
 Millard <marklmi@yahoo.com>=
 wrote:
On 2022-=
Oct-11, at 09:20, Mark Millard <marklmi@yahoo.com> wrote:



> [Summary: Both somewhat before and just after your ConOut commit

> work. I'll have to do a rough bisect with the available armv7

> artifacts that are after those but before October.]

> 

> On 2022-Oct-11, at 08:26, Mark Millard <marklmi@yahoo.com> wrote:

> 

>> On 2022-Oct-11, at 06:17, Warner Losh <imp@bsdimp.com> wrote:

>> . . .

>>> . . .

>>> 

>>> The change was made in late August that I'm thinking of, s=
o if you could find a

>>> snapshot from early August July that would be a useful data po=
int:

>>> 

>>> commit df065f699f1ff819bb9607c44a6754275ab335ed

>>> Author: Warner Losh <imp@FreeBSD.org>

>>> Date:=C2=A0 =C2=A0Fri Aug 26 15:46:33 2022 -0600

>>> 

>>>=C2=A0 =C2=A0stand: More sensible defaults when ConOut is missi=
ng

>> 

>> I'll look at finding and trying some artifact build to extract=
 a

>> armv7 EFI loader from. Available snapshot history does not

>> go back that far so far as I know.

>> 

>> But I may not be able to look into this immediately.

>> 

>> In main:

>> 

>> commit df065f699f1ff819bb9607c44a6754275ab335ed

>> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>

>> AuthorDate: 2022-08-26 21:46:33 +0000

>> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>

>> CommitDate: 2022-08-27 04:17:56 +0000

>> 

>> It looks like the closest prior artifact is at:

>> 

>> https://artifact.ci.freebsd.org/snapshot/main/a358db5=
603702d5de5fd75f5bd16bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD

>> git: a358db560370 - main - socket(2): bring documentation up tp da=
te Gleb Smirnoff

>> 

>> with date/time: 2022-Aug-26 16:26

>> 

>> So I expect to use that.

> 

> Turns out that I had the time.

> 

> Use of the ./boot/loader.efi from a358db560370 substituted

> into the failing main snapshot based microsd card worked

> fine for both contexts:

> 

> A) Just serial console.

> and:

> B) Serial console and HDMI console at the same time.

> 

> I also tried the oldest artifact build with the loader change

> in place:

> 

> https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea68=
c3be9c2ed50ce/arm/armv7/

> git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner=
 Losh

> Date/time: 2022-Aug-27 05:12

> 

> This also worked for both (A) and (B).

> 

> So it looks like I'll be doing a rough bisect to find a

> before/after pair. It might have some elapsed time to

> finish.



The date/times encoded into the file names below

are those shown for base.txz . The overall artifact

directory date/time is somewhat later. The -good

vs. -bad suffix indicates the boot status.



# ls -C1d *

boot-2022-08-26-16-26-a358db560370-good

boot-2022-08-27-05-12-7ed3228323ef-good

boot-2022-09-12-18-30-c198adf39498-good

boot-2022-09-15-01-28-145a50dcda7a-good

boot-2022-09-16-14-26-b4174079576a-good

boot-2022-09-16-15-45-b44869cba1b3-good

boot-2022-09-16-18-02-dd2b9c296776-bad

boot-2022-09-16-20-51-30cfb3c8ee3d-bad

boot-2022-09-18-00-46-c3707bd3d658-bad



For:



boot-2022-09-16-15-45-b44869cba1b3-good

boot-2022-09-16-18-02-dd2b9c296776-bad



there are no armv7 artifacts available between.



The range is:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: b44869cba1b3 - main - sound: add=
 patch for Lenovo Legion 5 Intel Nuno Teixeira 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: a705c72f2142 - main - stand: use=
 archsw.arch_copyin instead of i386_copyin Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 4c670b53a000 - main - stand: use=
 archsw.arch_copyin instead of direct call Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 8b19d28d68a3 - main - stand: Cre=
ate MOD_ALIGN macro and use it everywhere Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: bca9c87b6104 - main - stand: Cre=
ate common/modinfo.h Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Mov=
e md_copymodules into modinfo.c and reduce copies Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 2e6ed47a4609 - main - stand: Mov=
e MOD_xxx macros from modinfo.h to .c Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: fc352701ff3a - main - stand: col=
lapse all copies of *copyenv into md_copyenv Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: e895ab3fbdc1 - main - stand: Rem=
ove dead store to bi_kernelname Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: d43bcf62a218 - main - stand: Sto=
p support booting 4.x and earlier kernels Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 59b1d074280d - main - i386: Mark=
 the obsolete fields in bootinfo with _was_ Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 4134f677eb39 - main - i386: Make=
 boot loader smaller by reducing size of bootinfo Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 9758dd3de1cd - main - stand: All=
ocate bootinfo rather than have it be static Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: c0ecae78abbe - main - stand/elf:=
 Only support swapping headers on powerpc. Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: dd2b9c296776 - main - stand: fix=
 mismerge Warner Losh

Yea, I did a bunc=
h of refactoring. I'm surprised that this produced a change at all. Wou=
ld be nice to
know which one of these caused the problems.
<=
div>=C2=A0

Side note about /boot/msdos :



The Oct-07 snapshot of main [so: 14] has:



# ls -Tld /boot/msdos /boot/efi

drwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 16384 Jan=C2=A0 1 00:00:00 1980 /=
boot/efi

lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 =C2=A0 =C2=A051 Oct=C2=A0 7 10:36=
:20 2022 /boot/msdos -> /usr/obj/usr/src/arm.armv7/release/GENERIC/boot/=
efi

That's likely my fault, it shou=
ld be a link to a plain 'efi' I'll prep a fix.

Warner


--0000000000002daa3705eac6ef98--

From nobody Tue Oct 11 19:10:14 2022
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 4Mn52r2jqKz4fDXm
	for ; Tue, 11 Oct 2022 19:10:28 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4Mn52q2YtDz3Mr1
	for ; Tue, 11 Oct 2022 19:10:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ej1-x62c.google.com with SMTP id 13so33526398ejn.3
        for ; Tue, 11 Oct 2022 12:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=66gfnv+gKf2M+jF2rHgW1xvVsL8TgGf7C/iY9n7y2hM=;
        b=p2gpSWaffDqKIc1A5NyPPGewgdIygG0xTUjNHS3xCnnCkDUgSqDIWsv4EpiaIWugAV
         8y9MwDvzVMrjS19ESgUM5QVdT+ETgEupJG5SfmY528yh0rM+xWsdx+8x4EnpUBLeJgLk
         YUek92ZzP0zLEsacBGXxuud7VhXjR0kE2Enly9hvt+3kkztD4xJsuj3Js9S4e6EYkGT1
         zBiB9G/BcHQW42zDJpv/F+4QoXxR5cIhsObeAHUqOlVnvc+xnK0fBIR1r2JMsDMV0CYY
         eKj8rxplyE0K8urZOm4RkYlPXDTT6Vu+fcobmdGdZp8pMrT94V014XhccDoyXFYHZl26
         XIcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=66gfnv+gKf2M+jF2rHgW1xvVsL8TgGf7C/iY9n7y2hM=;
        b=vvjnNrFjN7Ya/NKUPbtZgtepXcV+VuP0rfnXHtFzgmUrlyJ6btUapOoA28b5kjNNe0
         Kj5dshH9ZsREapAj6RRoxMlxXzdKRF9L8xRwyqMIm+dDSD6UIw3t03DMjfA8CoELODs1
         avgjkX6LrjrfYK8jnDdVDQHE6TUWQCotHmhkIyE19dEe4+E3wGtf4dR+txoTOY6FtX1S
         yh0JOzRSDoPt50X5EiB/hiAt0q0S4JaUQgVO1NlbH/XxFUW5GZb0OWjtP+h2yAfx1ck1
         WD826LD+Re1CWINCYa7rBV5kPEHsU1Mo1m1YuR0o05VMVLXSw7GbMF7b7D3ZJoFOh3Ij
         o/sg==
X-Gm-Message-State: ACrzQf3RFuUkAzl0hANXtaw8EOFLP+/mGQ1SrF6+UVQB8di9FG9NBLW5
	gfAlkIFenoGXhUB7ZLg6Mm+ZBCG3QvJeoc1TQeNPfQ==
X-Google-Smtp-Source: AMsMyM4eQoNfUm1YGR5djYZwHt/G06J8uTTMmgnZIvUel1hdk/VOvaLA5sWzBHApCkzUSAxps5iAoK18ueY8roCYDhM=
X-Received: by 2002:a17:906:328c:b0:780:7574:ced2 with SMTP id
 12-20020a170906328c00b007807574ced2mr20010730ejw.634.1665515425967; Tue, 11
 Oct 2022 12:10:25 -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: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
  
  
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com> <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
 <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com> 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 11 Oct 2022 13:10:14 -0600
Message-ID: 
Subject: Re: FYI: FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img
 is broken for RPi2 v1.1 (so: armv7)
To: Mark Millard 
Cc: freebsd-arm , bob prohaska 
Content-Type: multipart/alternative; boundary="00000000000055495205eac70704"
X-Rspamd-Queue-Id: 4Mn52q2YtDz3Mr1
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=p2gpSWaf;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62c) smtp.mailfrom=wlosh@bsdimp.com
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000055495205eac70704
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 11, 2022 at 1:03 PM Warner Losh  wrote:

>
>
> On Tue, Oct 11, 2022 at 12:50 PM Mark Millard  wrote:
>
>> On 2022-Oct-11, at 09:20, Mark Millard  wrote:
>>
>> > [Summary: Both somewhat before and just after your ConOut commit
>> > work. I'll have to do a rough bisect with the available armv7
>> > artifacts that are after those but before October.]
>> >
>> > On 2022-Oct-11, at 08:26, Mark Millard  wrote:
>> >
>> >> On 2022-Oct-11, at 06:17, Warner Losh  wrote:
>> >> . . .
>> >>> . . .
>> >>>
>> >>> The change was made in late August that I'm thinking of, so if you
>> could find a
>> >>> snapshot from early August July that would be a useful data point:
>> >>>
>> >>> commit df065f699f1ff819bb9607c44a6754275ab335ed
>> >>> Author: Warner Losh 
>> >>> Date:   Fri Aug 26 15:46:33 2022 -0600
>> >>>
>> >>>   stand: More sensible defaults when ConOut is missing
>> >>
>> >> I'll look at finding and trying some artifact build to extract a
>> >> armv7 EFI loader from. Available snapshot history does not
>> >> go back that far so far as I know.
>> >>
>> >> But I may not be able to look into this immediately.
>> >>
>> >> In main:
>> >>
>> >> commit df065f699f1ff819bb9607c44a6754275ab335ed
>> >> Author:     Warner Losh 
>> >> AuthorDate: 2022-08-26 21:46:33 +0000
>> >> Commit:     Warner Losh 
>> >> CommitDate: 2022-08-27 04:17:56 +0000
>> >>
>> >> It looks like the closest prior artifact is at:
>> >>
>> >>
>> https://artifact.ci.freebsd.org/snapshot/main/a358db5603702d5de5fd75f5bd=
16bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD
>> >> git: a358db560370 - main - socket(2): bring documentation up tp date
>> Gleb Smirnoff
>> >>
>> >> with date/time: 2022-Aug-26 16:26
>> >>
>> >> So I expect to use that.
>> >
>> > Turns out that I had the time.
>> >
>> > Use of the ./boot/loader.efi from a358db560370 substituted
>> > into the failing main snapshot based microsd card worked
>> > fine for both contexts:
>> >
>> > A) Just serial console.
>> > and:
>> > B) Serial console and HDMI console at the same time.
>> >
>> > I also tried the oldest artifact build with the loader change
>> > in place:
>> >
>> >
>> https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea6=
8c3be9c2ed50ce/arm/armv7/
>> > git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner
>> Losh
>> > Date/time: 2022-Aug-27 05:12
>> >
>> > This also worked for both (A) and (B).
>> >
>> > So it looks like I'll be doing a rough bisect to find a
>> > before/after pair. It might have some elapsed time to
>> > finish.
>>
>> The date/times encoded into the file names below
>> are those shown for base.txz . The overall artifact
>> directory date/time is somewhat later. The -good
>> vs. -bad suffix indicates the boot status.
>>
>> # ls -C1d *
>> boot-2022-08-26-16-26-a358db560370-good
>> boot-2022-08-27-05-12-7ed3228323ef-good
>> boot-2022-09-12-18-30-c198adf39498-good
>> boot-2022-09-15-01-28-145a50dcda7a-good
>> boot-2022-09-16-14-26-b4174079576a-good
>> boot-2022-09-16-15-45-b44869cba1b3-good
>> boot-2022-09-16-18-02-dd2b9c296776-bad
>> boot-2022-09-16-20-51-30cfb3c8ee3d-bad
>> boot-2022-09-18-00-46-c3707bd3d658-bad
>>
>> For:
>>
>> boot-2022-09-16-15-45-b44869cba1b3-good
>> boot-2022-09-16-18-02-dd2b9c296776-bad
>>
>> there are no armv7 artifacts available between.
>>
>> The range is:
>>
>>         =E2=80=A2 git: b44869cba1b3 - main - sound: add patch for Lenovo=
 Legion 5
>> Intel Nuno Teixeira
>>         =E2=80=A2 git: a705c72f2142 - main - stand: use archsw.arch_copy=
in
>> instead of i386_copyin Warner Losh
>>         =E2=80=A2 git: 4c670b53a000 - main - stand: use archsw.arch_copy=
in
>> instead of direct call Warner Losh
>>         =E2=80=A2 git: 8b19d28d68a3 - main - stand: Create MOD_ALIGN mac=
ro and
>> use it everywhere Warner Losh
>>         =E2=80=A2 git: bca9c87b6104 - main - stand: Create common/modinf=
o.h
>> Warner Losh
>>         =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move md_copymodules =
into
>> modinfo.c and reduce copies Warner Losh
>>         =E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx macros =
from
>> modinfo.h to .c Warner Losh
>>         =E2=80=A2 git: fc352701ff3a - main - stand: collapse all copies =
of
>> *copyenv into md_copyenv Warner Losh
>>         =E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store to
>> bi_kernelname Warner Losh
>>         =E2=80=A2 git: d43bcf62a218 - main - stand: Stop support booting=
 4.x and
>> earlier kernels Warner Losh
>>         =E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete fie=
lds in
>> bootinfo with _was_ Warner Losh
>>         =E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader smal=
ler by
>> reducing size of bootinfo Warner Losh
>>         =E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo ra=
ther than
>> have it be static Warner Losh
>>         =E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support swa=
pping
>> headers on powerpc. Warner Losh
>>         =E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge Warner =
Losh
>>
>
> Yea, I did a bunch of refactoring. I'm surprised that this produced a
> change at all. Would be nice to
> know which one of these caused the problems.
>

None of the other platforms I tested on when I did the refactor had issue
or saw any kind of change. So
there may be other issues going on that also take out the boot console...


> Side note about /boot/msdos :
>>
>> The Oct-07 snapshot of main [so: 14] has:
>>
>> # ls -Tld /boot/msdos /boot/efi
>> drwxr-xr-x  1 root  wheel  16384 Jan  1 00:00:00 1980 /boot/efi
>> lrwxr-xr-x  1 root  wheel     51 Oct  7 10:36:20 2022 /boot/msdos ->
>> /usr/obj/usr/src/arm.armv7/release/GENERIC/boot/efi
>>
>
> That's likely my fault, it should be a link to a plain 'efi' I'll prep a
> fix.
>

I think this is the right fix:
https://reviews.freebsd.org/D36941
Please comment....

--00000000000055495205eac70704
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Oct 11, 2022 at 1:03 PM Warne=
r Losh <imp@bsdimp.com> wrote:<=
br>


On Tue, Oct 11, 2022 at 12:50 PM Mark Millard <marklmi@yahoo.com&g=
t; wrote:
On 202=
2-Oct-11, at 09:20, Mark Millard <marklmi@yahoo.com> wrote:



> [Summary: Both somewhat before and just after your ConOut commit

> work. I'll have to do a rough bisect with the available armv7

> artifacts that are after those but before October.]

> 

> On 2022-Oct-11, at 08:26, Mark Millard <marklmi@yahoo.com> wrote:

> 

>> On 2022-Oct-11, at 06:17, Warner Losh <imp@bsdimp.com> wrote:

>> . . .

>>> . . .

>>> 

>>> The change was made in late August that I'm thinking of, s=
o if you could find a

>>> snapshot from early August July that would be a useful data po=
int:

>>> 

>>> commit df065f699f1ff819bb9607c44a6754275ab335ed

>>> Author: Warner Losh <imp@FreeBSD.org>

>>> Date:=C2=A0 =C2=A0Fri Aug 26 15:46:33 2022 -0600

>>> 

>>>=C2=A0 =C2=A0stand: More sensible defaults when ConOut is missi=
ng

>> 

>> I'll look at finding and trying some artifact build to extract=
 a

>> armv7 EFI loader from. Available snapshot history does not

>> go back that far so far as I know.

>> 

>> But I may not be able to look into this immediately.

>> 

>> In main:

>> 

>> commit df065f699f1ff819bb9607c44a6754275ab335ed

>> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>

>> AuthorDate: 2022-08-26 21:46:33 +0000

>> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>

>> CommitDate: 2022-08-27 04:17:56 +0000

>> 

>> It looks like the closest prior artifact is at:

>> 

>> https://artifact.ci.freebsd.org/snapshot/main/a358db5=
603702d5de5fd75f5bd16bbf7c0ab673f/arm/armv7/?C=3DM&O=3DD

>> git: a358db560370 - main - socket(2): bring documentation up tp da=
te Gleb Smirnoff

>> 

>> with date/time: 2022-Aug-26 16:26

>> 

>> So I expect to use that.

> 

> Turns out that I had the time.

> 

> Use of the ./boot/loader.efi from a358db560370 substituted

> into the failing main snapshot based microsd card worked

> fine for both contexts:

> 

> A) Just serial console.

> and:

> B) Serial console and HDMI console at the same time.

> 

> I also tried the oldest artifact build with the loader change

> in place:

> 

> https://artifact.ci.freebsd.org/snapshot/main/7ed3228323ef4f9e3130603ea68=
c3be9c2ed50ce/arm/armv7/

> git: 7ed3228323ef - main - stand: Document that boot0 uses BIOS Warner=
 Losh

> Date/time: 2022-Aug-27 05:12

> 

> This also worked for both (A) and (B).

> 

> So it looks like I'll be doing a rough bisect to find a

> before/after pair. It might have some elapsed time to

> finish.



The date/times encoded into the file names below

are those shown for base.txz . The overall artifact

directory date/time is somewhat later. The -good

vs. -bad suffix indicates the boot status.



# ls -C1d *

boot-2022-08-26-16-26-a358db560370-good

boot-2022-08-27-05-12-7ed3228323ef-good

boot-2022-09-12-18-30-c198adf39498-good

boot-2022-09-15-01-28-145a50dcda7a-good

boot-2022-09-16-14-26-b4174079576a-good

boot-2022-09-16-15-45-b44869cba1b3-good

boot-2022-09-16-18-02-dd2b9c296776-bad

boot-2022-09-16-20-51-30cfb3c8ee3d-bad

boot-2022-09-18-00-46-c3707bd3d658-bad



For:



boot-2022-09-16-15-45-b44869cba1b3-good

boot-2022-09-16-18-02-dd2b9c296776-bad



there are no armv7 artifacts available between.



The range is:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: b44869cba1b3 - main - sound: add=
 patch for Lenovo Legion 5 Intel Nuno Teixeira 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: a705c72f2142 - main - stand: use=
 archsw.arch_copyin instead of i386_copyin Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 4c670b53a000 - main - stand: use=
 archsw.arch_copyin instead of direct call Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 8b19d28d68a3 - main - stand: Cre=
ate MOD_ALIGN macro and use it everywhere Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: bca9c87b6104 - main - stand: Cre=
ate common/modinfo.h Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Mov=
e md_copymodules into modinfo.c and reduce copies Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 2e6ed47a4609 - main - stand: Mov=
e MOD_xxx macros from modinfo.h to .c Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: fc352701ff3a - main - stand: col=
lapse all copies of *copyenv into md_copyenv Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: e895ab3fbdc1 - main - stand: Rem=
ove dead store to bi_kernelname Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: d43bcf62a218 - main - stand: Sto=
p support booting 4.x and earlier kernels Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 59b1d074280d - main - i386: Mark=
 the obsolete fields in bootinfo with _was_ Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 4134f677eb39 - main - i386: Make=
 boot loader smaller by reducing size of bootinfo Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: 9758dd3de1cd - main - stand: All=
ocate bootinfo rather than have it be static Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: c0ecae78abbe - main - stand/elf:=
 Only support swapping headers on powerpc. Warner Losh 

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 git: dd2b9c296776 - main - stand: fix=
 mismerge Warner Losh

Yea, I did a bunc=
h of refactoring. I'm surprised that this produced a change at all. Wou=
ld be nice to
know which one of these caused the problems.
<=
/div>

None of the other platforms I t=
ested on when I did the refactor had issue or saw any kind of change. So
there may be other issues going on that also take out the boot cons=
ole...
=C2=A0

Side note about /boot/msdos :



The Oct-07 snapshot of main [so: 14] has:



# ls -Tld /boot/msdos /boot/efi

drwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 16384 Jan=C2=A0 1 00:00:00 1980 /=
boot/efi

lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 =C2=A0 =C2=A051 Oct=C2=A0 7 10:36=
:20 2022 /boot/msdos -> /usr/obj/usr/src/arm.armv7/release/GENERIC/boot/=
efi

That's likely my fault, it shou=
ld be a link to a plain 'efi' I'll prep a fix.

I think this is the right fix:
Please comment....=C2=A0


--00000000000055495205eac70704--

From nobody Tue Oct 11 23:33:27 2022
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 4MnBtL5wlwz4dhq5
	for ; Tue, 11 Oct 2022 23:33:30 +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 4MnBtK6nRYz3g8F
	for ; Tue, 11 Oct 2022 23:33:29 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29BNXRPu013762
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 11 Oct 2022 16:33:28 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29BNXRZ2013761;
	Tue, 11 Oct 2022 16:33:27 -0700 (PDT)
	(envelope-from fbsd)
Date: Tue, 11 Oct 2022 16:33:27 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)g
Message-ID: <20221011233327.GA13708@www.zefox.net>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
 <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
 <20221011171548.GA12624@www.zefox.net>
 <09A32530-3701-49F1-9369-549FF1162520@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: <09A32530-3701-49F1-9369-549FF1162520@yahoo.com>
X-Rspamd-Queue-Id: 4MnBtK6nRYz3g8F
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	WWW_DOT_DOMAIN(0.50)[];
	MID_RHS_WWW(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[yahoo.com];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Oct 11, 2022 at 11:37:25AM -0700, Mark Millard wrote:
[snip] 
> Actually the below is confusing. /boot/msdos
> is supposed to be a mount point (empty directory)
> at which the msdosfs can be mounted to make those
> files show up there, despite being from a different
> file system. 

Apologies for the ambiguity!

/dev/da0s1 on /boot/msdos (msdosfs, local, noatime)
is the normal dos filesystem on the root USB device.
Normally it is mounted, IME.

/dev/mmcsd0s1 on /mnt (msdosfs, local)
was where I mounted the microSD DOS partition
so the contents could be listed. This is a Pi2 
so a DOS microSD card is required to boot from USB.
Normally /dev/mmcsd0s1 is not mounted when root
is booted from USB.

Mostly I wondered if files placed in an "unused" DOS
subdirectory could be hidden from the boot software.
It was a poor way to pose the question.

At the moment the armv7 PATA disk is updating. If it boots
the Pi2 successfully I'll try it on Pi3 and Pi4. If
that works I'll set up a SATA armv7 disk and test the
troublesome disk enclosures. 

Thank you!

bob prohaska

From nobody Wed Oct 12 02:55:06 2022
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 4MnHM83xCnz4f7J4
	for ; Wed, 12 Oct 2022 02:55:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4MnHM73gJwz4Gqx
	for ; Wed, 12 Oct 2022 02:55:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665543312; bh=Uk68s3+qpTKwVkSeh8wfIgnafEdNihenja4KETLHjRk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CB+J6SpKodMtb3N5uhFRa9RJ4pM0NFRIMRZNYoe2Up6CQwuGo43bid4QjOIC5DgtxURbocBrkf1vCjdkC6aACpwCGkury6NpjqzfAZ4xAoEfqtK18qWrXoLy8vJLFri9eyEyEKFzvuEvXWTLeSELjST4XnmFB77/G+USk7RST4NbQl8gCWPiw1YJg2M3enIZRr1k3MufCWvakpZek8sxDCR9Qr+ov1L2N9bvFc1HDjtSTrPEEr2QpuSNBQkYtrJaGVHXhqoCX4hdWmuTzjkGRMuHcHWH6QQBkSqw6pLKZ+FVQhCMecw2SsX5w3ML0pPUQb0GFbNZCLckUCyu4/eBJA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665543312; bh=uq0/iLt+KOqmU5EO5XiOFcZm62UImikt7xL9qSMLEid=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QBNEB8IDDTf64hWs9x88acdbI7uOFOOYDKFJj3xlvT15gjlpeY/DWZGtMiFJAO54GYepXr5pzvYFpDbl7WJ2SWDjSSf9wdCue7JiTZNz8C8oAnsGE9pLFMyfeKLnJRDA95inAgslZGI0GQWG7J4Qxi8ojsykppv0vQyg38VwNVCKd2m0P9Px5TXDb45aHttQ0/zbSJtXT63dyY7FzOoYfOZuaiuQb/lk7Gyn16yDkrx3KTN9QvRkkcLBGAJ7yD4Co5Z7dD4wVCK7HJLb/Lkgdu1DZR55quWaHbnioqv6BWclO+Ik1+5CwLnh/fFf2QEd8H+7Id8sC94OarUrPexFkA==
X-YMail-OSG: JdU7m_8VM1lGzfvBRVd5vBeftuVTxq_tNMEwRnkkegbPpP85TgsMkqhitpYT181
 yqRZuBZbBk2V8GaNmuRppBYvdHnRm3qyivOG6th3Nu06qTANVKVTNh34K9o_uhriwANM_08rOD7X
 Dh.qeMHT0KvQQ196NVHIIqjOpvcidGsaWJmRHhEjkpa65r9jB_uvOf8aJvmEXT8VPbOFESd9l7D9
 IwahQAfyKofViwmxw1o6ImM60eElD.8mK.JG45udbWYqDa72M6H.IY9hIg_7Qew6e_PQxZfmweLR
 uQfSHU_5TtLCKtDz1EjwR2X6tQb9k130Y4QBHLfYQoyIZEUWd8JN8XPC_IPc9HnHomtYu9KWVpNb
 iGmri8UmBLv7V8PU3umW60ywxk2XR3ZONtYpZABbznu6afiSVGJbwTEQfHlrgsrHll0t27h.viLB
 zWaxfOgj2VXMnpEIHUUxWbnFzquJHJ0DnIW9YpR8_k95W1dPRGmpYAev09Oq43cEPBCW5GAFJOrt
 16w7jSMdWehoDcuhIWY3kfyjsPvYW.3ly7Aq_CVJtWcrXYl9QXP28sEYeZswOb9e9YtA59CWGDx0
 S6ieNc3J.VH6.UkqzOLTIkGJqdiFC910Evd7BkRT94eHneXFHZM9qGp1Lj5bO.Wn3uKfJEjp9QF0
 .jrC.f4y_1ZsEXLq9O770.fCFwmk6FcdgY.If7xZUQ13e9qq_LK1hU8SSpslAZ_wFfylxao0Sl3U
 mOA2ZK.umKXl14zEi6IzOJ3hcZ.FlyWpSn9BBxM1wDpiK8n4BqdLlS.1yZ6iJ35dRrn26qbcUCAk
 Sj7IKAWz_Erk0L2YdFRVMRdP97kIPPSG6I4Z2Q5E.CMK_3s9EbKB_W0RDAPHp1tNTLZj_WhVg68f
 MdDRPtuZqZkwWXxog9P1VIpAaWWQRC6DcBg4XNU6aiuBZcWpPHN5gFVsTk7xhlc0F_ieHR2JoFLO
 gU_B.9d406CZP0d99tdXpHtdU4Hnfgos9fk5Su1SuBHE5EGrdLzI45szUnZ8Kx7uYxbp.L9vuuWl
 4leEHJ.NKFuGZLDYKA5MyYAHDYfjRw_AbpLF_TzDk_8qId2qyZ.IZ8drF1Ccnd662ny.H0vFWjHz
 ktQTcFQAJVZVmK1qsSyErodCPr2WKIsGZTbmVAMjTsp0cQHCKAf5984yJyUu2OQIBIx5XV9Yc1yq
 0UpsusDO.2Y60uhqHFAWXosjrCgiqZFvuFu0oDn4xRBYZ1Fza.TIp8uSyJEDVfxm3tX98taaU2_2
 k_EtNoH._kkQjnJVuNBNxl9l5jJCrk4SUw_1qqME5QFP_1_YaRM.YHlw1A9uD8NXdk4txXNx.aP4
 SCeKV8H_BLSQctrzDHO70dzO2AhUWyrfqpKOWGjjib8wB_A.OsGv7Qj194SQ2YbiyaxxhjbGzDbH
 zyGglNrRCMW7AQEP74eVF1d0kmHeza.lElwW9zet_DRUwZ5tyeB0YbUZMqizl4P4I6UPWBhd3qkg
 sUjHOlIXAGcCi.zQYhGrqy1wj8gRMMS5zi5JdJFJtXv4cFAULJtXnJgTWhm7DK3Lsrumqmr11lc0
 8lWd_YN_v_JpzEI73g6BlSQmWKhcjAlE.6bTNDMPgoFSiOLJfd41Ro0CcZkVl7o944Ln8lwZaAHh
 4pziPeFP4Pgs0xkApiFSJEQopvgFusk1zkpa8nbcY26ujmPUNrRUjitoQ1S8YMb0TWL22efjys8r
 Rk9oL70_TiZsvUDhQek0NnLv0Y1UDexom.KfS7ecAhtmYeD.G4LTugu5c_N6F1PmH3AARzApSYKj
 H.ZIdFROzoFdvcm9DxgqM4alB1dQW8BHZY8u3kbFPSjlQk1aBWTqGPVBMdmAHHL4igKgN2K8XPwM
 qWyouNnt7pF5qgRnJEJwTbK1MHipoUhMAn1swioD5Z.SBM08TMDfQveByJsKaN_wE7O2rUSWW6S9
 NDmty26nHQDoZe9lr9yJjTU32jYNzmcaBPKvn9l7KUGNwtZFWOJM7gNKwaz1Bu4ikdR2dOUHPPWh
 Ecm6EumM_1cl5moQwq86eBQ0R7xV0lh0N6o6pLrtpgDffjvSzop.S_fRJpCiDl7qECwciuIdKHEm
 K3WuPhilbecvIpxa4I9A7wV4B9WlBt_YVrV7Wg93OPWudhxaTD9xBVxLFPUXqJltBpfW1Vwodje1
 ljFJNhVo_Pqy1hb0sRQ3QpQ2ZsDmrh86CdaSMc7w.wpwhvTmvbLh5buNEx8ebsDRVWDYesSfb.7n
 cAgi.ltRuTvrPc9_rFYgBXCMQA8Kta7HCK3w09c.JHYN1gdzQ05WIUaLRrkxOMFuqauz5dKrKmas
 hZgXNuIw-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Oct 2022 02:55:12 +0000
Received: by hermes--production-bf1-585bd66ffc-s92cx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 30c91c7eed89856768b76a26de8f233f;
          Wed, 12 Oct 2022 02:55:09 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: 
Date: Tue, 11 Oct 2022 19:55:06 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A679278-69E0-4592-BFED-48ED8598C2F1@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
 <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MnHM73gJwz4Gqx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CB+J6SpK;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.46 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.959];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 12:10, Warner Losh  wrote:

> On Tue, Oct 11, 2022 at 1:03 PM Warner Losh  wrote:
>>=20
>>=20
>> On Tue, Oct 11, 2022 at 12:50 PM Mark Millard  =
wrote:
>> . . .
>>=20
>> For:
>>=20
>> boot-2022-09-16-15-45-b44869cba1b3-good
>> boot-2022-09-16-18-02-dd2b9c296776-bad
>>=20
>> there are no armv7 artifacts available between.
>>=20
>> The range is:
>>=20
>>         A) =E2=80=A2 git: b44869cba1b3 - main - sound: add patch for =
Lenovo Legion 5 Intel Nuno Teixeira=20
>>         B) =E2=80=A2 git: a705c72f2142 - main - stand: use =
archsw.arch_copyin instead of i386_copyin Warner Losh=20
>>         C) =E2=80=A2 git: 4c670b53a000 - main - stand: use =
archsw.arch_copyin instead of direct call Warner Losh=20
>>         D) =E2=80=A2 git: 8b19d28d68a3 - main - stand: Create =
MOD_ALIGN macro and use it everywhere Warner Losh=20
>>         E) =E2=80=A2 git: bca9c87b6104 - main - stand: Create =
common/modinfo.h Warner Losh=20
>>         F) =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move =
md_copymodules into modinfo.c and reduce copies Warner Losh=20
>>         G) =E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx =
macros from modinfo.h to .c Warner Losh=20
>>         H) =E2=80=A2 git: fc352701ff3a - main - stand: collapse all =
copies of *copyenv into md_copyenv Warner Losh=20
>>         =E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store =
to bi_kernelname Warner Losh=20
>>         =E2=80=A2 git: d43bcf62a218 - main - stand: Stop support =
booting 4.x and earlier kernels Warner Losh=20
>>         =E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete =
fields in bootinfo with _was_ Warner Losh=20
>>         =E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader =
smaller by reducing size of bootinfo Warner Losh=20
>>         =E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo =
rather than have it be static Warner Losh=20
>>         =E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support =
swapping headers on powerpc. Warner Losh=20
>>         =E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge =
Warner Losh
>>=20
> Yea, I did a bunch of refactoring. I'm surprised that this produced a =
change at all. Would be nice to
> know which one of these caused the problems.

5d1531d9d4e7 has the stand/common/metadata.c "align"
removal that the later dd2b9c296776 fixes as the
"mismerge". So it appears that most of the stages
would not build without adjustment for that.

So presume I've made the adjustment for any such
such cases below.

H) fc352701ff3a Bad
D) 8b19d28d68a3 Good
F) 5d1531d9d4e7 Bad
E) bca9c87b6104 Good

So the good -> bad back-to-back sequence pair is:

git: bca9c87b6104 - main - stand: Create common/modinfo.h Warner Los
git: 5d1531d9d4e7 - main - stand: Move md_copymodules into modinfo.c and =
reduce copies Warner Losh


Note: I cross build armv7 via aarch64 normally.
There is no "buildstand" analogous to buildworld
or buildkernel that takes TARGET and TARGET_ARCH
for cross builds. Thus I ended up with a full
buildworld to establish a context for the cross
builds.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Oct 12 23:15:01 2022
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 4MnpQj0FK5z4fJsl
	for ; Wed, 12 Oct 2022 23:15:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4MnpQg5VGgz45fk
	for ; Wed, 12 Oct 2022 23:15:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665616505; bh=wZazHK/V4PazocKuV1pW53qk4sFaE9fvNFNILAhDsxU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Tgll4CTnGWpGrkmk3QCg/FFlBrEw3aoShZq6IEtER5Z8BI6fNVs0qLDOxpQShTSlIZ/h9L3hMVXQXT1V2XwIXtJSnayoP2GnHzGdIvVEuKsoMN2n/Lye+VTZvBjXdIQAkIWH7QTzhpDtog4WTSUiM1QHxLcWHjSnYJ0O0OEFlvGxhMJ7by909FrCucISF6HEtOM257aBwiIvrIEX15JU7QEWlHCipIMUb682qqRygMgT0oUtlu1wfksmJ+Kk0Q206vODf65vIzvwbY5sgOcfP5yE1M2p8v5oLSn2gIwLATpo3TOmZZDTFo2igfTuL7LZiJgZLDAVPmR1Mq0llcw2Rg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665616505; bh=mkSJnQUoJvQx7Kar3pIvNhXuhOyxYQlaVsTaP+ZSs9L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ciTfDk4h8c76G9QQDCWX761LtWyYcZjuYgP8neXzPm5/1TyWw5+iOlkVrwuAgoHkGEX9ksV2H267zXraWuWyQEFDVKVEAcma1Zh75A0H0iiaIvBtluNyZYNx/nni/ZId7KVesAMNiNzMoZ6LbZ7kLvlG7YqfIHTahBQPBMyeQvHw2mTvoYCRKmVB/pVK6NeEcndyGXnv42zrx0hylJrapWELox65Fw7dBsU15JThVJDuQoXN/xjjWjdr9HRL3oEubjsI8j8qhditb/Nue0qfCBzKa+AHsrHi5lzF7ED8JJMcu6spDVHu7I3ZnDrEniynQSKIqdXkaq3c3CgbKXceGw==
X-YMail-OSG: DnQL9RMVM1kX2xKDHdI12HxaLSVZI3t1kgxC1OZFrCMYTb9NQhTCqUDIMSqUslU
 CnR8sn3tUvd7qanJmTriohVLI9ntxrFgIc7vVt_mbvLWX7e3ibKtMLDjmxs8LTQOZKtZo0GN8MFc
 aKLOKe0zxAHTP9kI5BL.3CMMC5zyl_Azfnkc_pXkVJAmWMnVVfVbJJ.6.DSo8rNqCxvt3.0zlbhG
 XPUHOVh_BvBYO3_l7Qd7B.JTiYOIsoADCsWlCHMlMYxu941U34XC8WPUEclTzgZ0GrSYwnT1fQKp
 Hyxyo8IhBFqaY3uEnZhyi6wx.JDYrVxDAfw0jcW2yuWxomVeUvUkW06L4EI3rUBCeTycsF9mAjrL
 7lShh16VvipvOsfxKt3QGVozoGA8N9R73gqMqdqoOljVCogG5tOwig2Om._2s.7m_WFVdSdKijfN
 vC2IVoiRkiTizo6KSFNmEP5T5YXcpxLFr1922jnOtWD_QX0gAi4m_Em6ecs0m7qypIAYLERJnnuS
 F1CyspwoUnhuwUPbI7u4ZL19BXQb.V1b8mBPcOobup1eYRM1LFwvd0SoVMLf83NO8mryB4r1dy53
 l_kkcnnEJxxb2akMInmOcOuMqz8nLfCupZUKnsubaOt145WuUlrq9szU07WE3TnHzHsJT1NwWSEg
 MPxXiKE_DVfQtzkOImyCY1eXjm_Lt3JeOvCWvE2lmS85oL9UMJxRRyxMyE.fz2UrbYoETylRA6MI
 VVNaUK.VJX7GnZpS8ncNCvthua5CZFDHFmHPU5njbsdqBCkjOnbmOhO64cFImy__7o9xg1OgaBzv
 4OaYr7y3skLzR9PRm94TaRL5GRXZeBD5pmEIrevwbQiHly71cE3JqZr6Dwr89ybgQsA2Rrly9vYn
 0FQkVI0PHawVwYHXl9wMnhKjWlSAaykOCNf1SOPxREvvH3ZvG4H4xPE8eSOxzOJo9WbnD_pxwJhV
 8Ft5gkuPhF0RjSKqleWjTTIsJYXpD9MRZsY1g09pKIgR8_2JZnq7qys5Di.MM7d6eUQeHQRjg2_U
 LPSVUQZMCM_tpwMglvWcT1F9m7idSPWQqqaNfLzmzwqJRTnYsnKRHuxfoHR4JJGHhhcuSf.BhQf0
 5JaUa2Z2ACQY2iXQOqWn8toJnEZVX2RTO5JQtQTkxftD3AmxHRFP36mWiooeQ5EPv2_rb9OihqU7
 UUAVSdLkkt24QU0OE5LJcfydC317ccU864WNM0ukwTZeTnOYPDXRzYsYdT0ehzvJw4etg_.8rLo9
 TElFNt3xnx6spSqIdDSL_7NB163.6FGH1Tk3l5adyApdydsBRnMuRq_CP6nSlBL51WjjmWlhzT6o
 jdGk6ZWOccdQTDXy6wEe.36Vf1ZaPJdqedcpYMGicQhgb.rwQtOSlE8MPEoIqNiBez83ehaddKZL
 hZ6ZH37JTEbwhJWr4KSRVcjmQEJBVEAp.m5EYMzBBLK2qI7UnLIx.PqNl9BSffgediUL.SL8GWkW
 7CKb2Txt2BuHDEK21riFsLXB0DdGWYfknrKofOsWebh9L.gXvYc9LUR96qwpLf.nIGWOsAU47EGf
 eTP8VQlnP8_OAlKdJrh8Gl84lyABXz_ooRvNaYnuP_ANhnxKduFREgOm0M8i5VB6cwWzCVOR8S2I
 8qaHFDEI6WHLroGMui1p4LF2NerywF4EsLPK.qXT5jJ4sLJPyNr01lRz69Kw1urlfd9ODzct66x1
 8iR9FVMYXvui2ygvTs1gOTnDEmr80QwR510tYNQ4Lwm2Bwd_9.pqbvaDjHu_d7OWxmEnnHt19fza
 6XQpAwWAwjCsewFh_WG09Z1B49.GBA1c9YqRmb8aqhwGA1Oid.yW9zNe_1OY5g0Nfzg5FEt2wxzH
 Vy9lEvnNIvaD3Ui5kysBdi59UtY46JUQO1cTf7lKEaHWuMHAoX5nvbf17KpqRYoOJMygjzw40Sn0
 sCcctJQrtjeJ93scDPO8mythGBzi975gm6_U_QAqqnsozEE5u80PSHXobRQFA.PqmKjckGVf1PvA
 I03l6RA62vB31f0nDpeBnQ8s2bJMF0PVvh9YWcUfY81X9doel308bouGIbg649qE39VQ_ukuar7R
 3.YpPMbBCHEC9vzp8cmirw6o_I..HLe6oAHMaoDgWj2yV9zOhcyoCgbMMa57CKBx72Oi8s_4PkXs
 smoA27QNVHPRr6oNO6fMwE2JRBlMe3wtPGQHklbyFNk9FVw5suN2pUX1Ae1ztxoYqUY7o55VCh0u
 a8xwDfTrFHKzseJV8NxnJaL0iTz6.t0gNrxA4HK609mKMFN86_d2FxTtfi3xiQqDpRyZci9jK25v
 09HBEw8bb3t1l5SzN3GXizw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Oct 2022 23:15:05 +0000
Received: by hermes--production-gq1-75cfcccdb-h6mn5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 09f14de3668397dc58ced4410e4093ee;
          Wed, 12 Oct 2022 23:15:02 +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 \(3696.120.41.1.1\))
Subject: How to armv7 boot both RPi2B v1.1 (bcm2709 --real armv7) and RPi3B
 (bcm2710 aarch64),  but not RPI4B (bcm2711 aarch64)
From: Mark Millard 
In-Reply-To: <20221011233327.GA13708@www.zefox.net>
Date: Wed, 12 Oct 2022 16:15:01 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9635B188-3F76-484A-8DFA-3C508E85B9D2@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
 <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
 <20221011171548.GA12624@www.zefox.net>
 <09A32530-3701-49F1-9369-549FF1162520@yahoo.com>
 <20221011233327.GA13708@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MnpQg5VGgz45fk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Tgll4CTn;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.11 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	NEURAL_HAM_MEDIUM(-0.61)[-0.611];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 16:33, bob prohaska  wrote:

> On Tue, Oct 11, 2022 at 11:37:25AM -0700, Mark Millard wrote:
> [snip]=20
>> Actually the below is confusing. /boot/msdos
>> is supposed to be a mount point (empty directory)
>> at which the msdosfs can be mounted to make those
>> files show up there, despite being from a different
>> file system.=20
>=20
> Apologies for the ambiguity!
>=20
> /dev/da0s1 on /boot/msdos (msdosfs, local, noatime)
> is the normal dos filesystem on the root USB device.
> Normally it is mounted, IME.
>=20
> /dev/mmcsd0s1 on /mnt (msdosfs, local)
> was where I mounted the microSD DOS partition
> so the contents could be listed. This is a Pi2=20
> so a DOS microSD card is required to boot from USB.
> Normally /dev/mmcsd0s1 is not mounted when root
> is booted from USB.
>=20
> Mostly I wondered if files placed in an "unused" DOS
> subdirectory could be hidden from the boot software.
> It was a poor way to pose the question.
>=20
> At the moment the armv7 PATA disk is updating. If it boots
> the Pi2 successfully I'll try it on Pi3 and Pi4. If
> that works I'll set up a SATA armv7 disk and test the
> troublesome disk enclosures.=20
>=20

Here is how I got armv7 going for booting both a
RPi2B v1.1 (so: Cortex-A7) and a RPi3B (so:
Cortex-A53). This will not get a RPi4B going.
Because of the EFI/BOOT/bootarm.efi issues with
main [so: 14], I used a 13.1-STABLE snapshot as
the basis for this.

FYI: the msdosfs snapshot content in:

FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img

looks like:

# mount -onoatime -tmsdosfs /dev/da0s1 /mnt
# ls -Tld /mnt/*
drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:48 2022 /mnt/EFI
-rwxr-xr-x  1 root  wheel   103876 Oct  7 03:29:26 2022 /mnt/MLO
-rwxr-xr-x  1 root  wheel    26745 Mar  3 13:29:56 2021 =
/mnt/bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    52456 Mar  3 13:29:56 2021 =
/mnt/bootcode.bin
-rwxr-xr-x  1 root  wheel       89 Oct  7 03:37:56 2022 /mnt/config.txt
drwxr-xr-x  1 root  wheel     8192 Oct  7 05:22:48 2022 /mnt/dtb
-rwxr-xr-x  1 root  wheel     7314 Mar  3 13:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 13:29:56 2021 =
/mnt/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:54 2022 /mnt/overlays
-rwxr-xr-x  1 root  wheel  2952960 Mar  3 13:29:56 2021 /mnt/start.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 13:29:56 2021 =
/mnt/start_cd.elf
-rwxr-xr-x  1 root  wheel  4794472 Mar  3 13:29:56 2021 =
/mnt/start_db.elf
-rwxr-xr-x  1 root  wheel  3704808 Mar  3 13:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x  1 root  wheel   504892 Oct  7 03:37:20 2022 /mnt/u-boot.bin
-rwxr-xr-x  1 root  wheel  1163404 Oct  7 03:29:26 2022 /mnt/u-boot.img
-r-xr-xr-x  1 root  wheel   462032 Oct  7 05:20:00 2022 /mnt/ubldr.bin

It does not have the timeout file that allows more time
for USB devices in particular contexts. But timeout
is only directly useful on microsd cards, in order to
allow binding to a wider range of USB boot devices.

It also does not have any of:

bcm2710-rpi-2-b.dtb
bcm2710-rpi-3-b-plus.dtb
bcm2710-rpi-3-b.dtb
bcm2710-rpi-cm3.dtb

Such would be needed for armv7 style booting of any of:

RPi2 v1.2
RPi3B+
RPi3B
Compute Module 3

(Again, the armv7 u-boot.bin does not handle the bcm2711*.dtb
related USB hardware, last I checked a RPi4B example anyway.
So I ignore that context here.)

It also has only:

# ls -Tld /mnt/overlays/*
-rwxr-xr-x  1 root  wheel  1221 Mar  3 13:29:56 2021 =
/mnt/overlays/mmc.dtbo

so it does not have:

disable-bt.dtbo
miniuart-bt.dtbo

for controlling which UART handles the serial console
on the likes of a RPi3B.

The u-boot.bin does not have an adjusted usb_pgood_delay .
(For some of the USB media that I have access to the
adjustment is important to booting. So my adjsutment will
be involved here.)

The following is being shown after booting an RPi2 v1.1
(so: a cortex-A7 form of armv7) based on what I adjusted
and used:

. . .
FreeBSD 13.1-STABLE #0 stable/13-n252653-d497b97e902: Fri Oct  7 =
05:01:41 UTC 2022
    root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC =
arm
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
VT: init without driver.
No PSCI/SMCCC call function found
CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000)
. . .
# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n252653-d497b97e902: Fri Oct  7 05:01:41 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm =
armv7 1301507 1301507

# gpart show -p
=3D>      63  62333889    mmcsd0  MBR  (30G)
        63      2016            - free -  (1.0M)
      2079    102312  mmcsd0s1  fat32lba  [active]  (50M)
    104391  62229561            - free -  (30G)

=3D>       63  468862065    da0  MBR  (224G)
         63       1985         - free -  (993K)
       2048     102400  da0s1  fat32lba  [active]  (50M)
     104448  468757680  da0s2  freebsd  (224G)

=3D>        0  468757680   da0s2  BSD  (224G)
          0        128          - free -  (64K)
        128  468757552  da0s2a  freebsd-ufs  (224G)

# more /etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/ufs/rootfs         /               ufs     rw              1       =
1
/dev/msdosfs/MSDOSBOOT  /boot/msdos     msdosfs rw,noatime      0       =
0
tmpfs                   /tmp            tmpfs   rw,mode=3D1777    0      =
 0

NOTE: /dev/msdosfs/MSDOSBOOT is in mmcsd0s1 in my context.
(So the USB msdosfs does not have the MSDOSBOOT label. Avoid
duplicate labels. Which you want mounts as /boot/msdos or
/boot/efi is up to you. Do not take the choices from this
example as important for such.)

# find /boot/msdos/ -print
/boot/msdos/
/boot/msdos/bootcode.bin
/boot/msdos/timeout

Note that I do include timeout in the microsd card's
msdosfs. I've USB media that will not boot otherwise
(necessary, but not sufficient by itself overall).

As for the USB media . . .

# mount -onoatime -tmsdosfs /dev/da0s1 /mnt
# ls -Tld /mnt/*
drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:48 2022 /mnt/EFI
-rwxr-xr-x  1 root  wheel   103876 Oct  7 03:29:26 2022 /mnt/MLO
-rwxr-xr-x  1 root  wheel    26745 Mar  3 13:29:56 2021 =
/mnt/bcm2709-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    26894 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-2-b.dtb
-rwxr-xr-x  1 root  wheel    29011 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x  1 root  wheel    28392 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-3-b.dtb
-rwxr-xr-x  1 root  wheel    26890 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-cm3.dtb
-rwxr-xr-x  1 root  wheel    52456 Mar  3 13:29:56 2021 =
/mnt/bootcode.bin
-rwxr-xr-x  1 root  wheel      207 Oct 10 06:05:20 2022 /mnt/config.txt
-rwxr-xr-x  1 root  wheel       89 Oct  7 03:37:56 2022 =
/mnt/config.txt.orig
drwxr-xr-x  1 root  wheel     8192 Oct  7 05:22:48 2022 /mnt/dtb
-rwxr-xr-x  1 root  wheel     7314 Mar  3 13:29:56 2021 /mnt/fixup.dat
-rwxr-xr-x  1 root  wheel     3187 Mar  3 13:29:56 2021 =
/mnt/fixup_cd.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_db.dat
-rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 /mnt/fixup_x.dat
drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:54 2022 /mnt/overlays
-rwxr-xr-x  1 root  wheel  2952960 Mar  3 13:29:56 2021 /mnt/start.elf
-rwxr-xr-x  1 root  wheel   793116 Mar  3 13:29:56 2021 =
/mnt/start_cd.elf
-rwxr-xr-x  1 root  wheel  4794472 Mar  3 13:29:56 2021 =
/mnt/start_db.elf
-rwxr-xr-x  1 root  wheel  3704808 Mar  3 13:29:56 2021 /mnt/start_x.elf
-rwxr-xr-x  1 root  wheel        0 Apr 24 10:58:58 2022 /mnt/timeout
-rwxr-xr-x  1 root  wheel   504932 Oct 10 05:17:40 2022 /mnt/u-boot.bin
-rwxr-xr-x  1 root  wheel   504892 Oct  7 03:37:20 2022 =
/mnt/u-boot.bin.orig
-rwxr-xr-x  1 root  wheel  1163404 Oct  7 03:29:26 2022 /mnt/u-boot.img
-r-xr-xr-x  1 root  wheel   462032 Oct  7 05:20:00 2022 /mnt/ubldr.bin

So I had added:

bcm2710-rpi-2-b.dtb
bcm2710-rpi-3-b-plus.dtb
bcm2710-rpi-3-b.dtb
bcm2710-rpi-cm3.dtb

and (not important on USB media but added anyway):

timeout

I used an updated config.txt:

# diff -u /mnt/config.txt.orig /mnt/config.txt
--- /mnt/config.txt.orig        2022-10-07 03:37:56.000000000 +0000
+++ /mnt/config.txt     2022-10-10 06:05:20.000000000 +0000
@@ -1,5 +1,13 @@
-init_uart_clock=3D3000000
+#init_uart_clock=3D3000000
 enable_uart=3D1
 kernel=3Du-boot.bin
 kernel7=3Du-boot.bin
 dtoverlay=3Dmmc
+#
+# Local additions:
+dtoverlay=3Ddisable-bt
+initial_turbo=3D60
+#uart_2ndstage=3D1
+#dtdebug=3D1
+gpu_mem_1024=3D32
+force_turbo=3D1

(Having config.txt on the microsd card's msdosfs will prevent
booting from USB media.)

I used a u-boot.bin that has my patch, including the
usb_pgood_delay adjustment.

I also added the 2 *-bt.dtbo files:

# ls -Tld /mnt/overlays/*
-rwxr-xr-x  1 root  wheel  1073 Mar  3 13:29:56 2021 =
/mnt/overlays/disable-bt.dtbo
-rwxr-xr-x  1 root  wheel  1819 Mar  3 13:29:56 2021 =
/mnt/overlays/miniuart-bt.dtbo
-rwxr-xr-x  1 root  wheel  1221 Mar  3 13:29:56 2021 =
/mnt/overlays/mmc.dtbo

I will note that, in this configuration, u-boot.bin
output is the first output to show up on the serial
console. This can take a bit to get that far so it
looks initially like nothing is happening but it is.
Be willing to wait a bit.

Moving the microsd card and USB media to the RPi3B and
attempting to boot worked just fine (but required
some of my changes reported above).

. . .
FreeBSD 13.1-STABLE #0 stable/13-n252653-d497b97e902: Fri Oct  7 =
05:01:41 UTC 2022
    root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC =
arm
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
VT: init without driver.
No PSCI/SMCCC call function found
CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080)
. . .
# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n252653-d497b97e902: Fri Oct  7 05:01:41 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm =
armv7 1301507 1301507

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Oct 13 05:28:41 2022
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 4Mnyjx2t1Hz4f49t
	for ; Thu, 13 Oct 2022 05:28:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mnyjv6hpdz3Zdf
	for ; Thu, 13 Oct 2022 05:28:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665638929; bh=h6Haj5btxBTTnA0fxwAuLKr2ygmKoeyAC37tx3f6148=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hO0TQd24WmOmhKZv1KoXmiLEJPn9RS3/+npSB4ISWildYePWD1IH0nQhntDXIFTdSm/TXb70OA4hzXbgcNknlB0tzIukYY3FYCbc0SyGPyRdsQVl8dlawHdrr8wBY1dXrGHKKa3uL/Ycc1KMxiIRpxQLgT7Z0xVPoV9BwXCbziLcO8D+aVhRDRo0CDHFhuvNb8lF48Y+8FNJeQkCMuOBaiENQ9keScn6d55KAaF6pfrElM6DlsB5uQLjY6jZ6Nwd52r2uDPcrSlhyvd07E9xo//5uewpX/sPimK6PTG1g1bMpIgjR9cOozrp5PyvYtyoI/hQgVf5jmSo8+zS5rj/DQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665638929; bh=AeIJhez3/prG2p6y2nAd6V5qtaXUhqkaOrTDNwH5/qq=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=T2+rNsUXqRoxF2z3r6+z6Q41WmzzElYfQ50X7XmRwuChVwqXj5gTG9I8By0YERn+uIrcPlfLu8sN1xTNLBR94TSjCox5Zp+fzkJPuKTfg7Rxm++V8WASm1/knKEuswcVUQZdIuwpAyjpLcsG+sKomwoTjZ3d6JMg7cPDW8C+/6UitRJV1LyBlXtSHsx82ncGreZGcRLxcNbZBR99AC3X94iUpvSOZuv8btzxKV7uKYUlWX5ZUydOSh6rRwyaeaWEztBpbFUlYCexHc/4hYlVsdZhPmSNTjDKopE/ssoRoz4vHhzoPHa1gJmkqaCHsBnFxKIXIADdjz5sOhjffjAJ1w==
X-YMail-OSG: Q4pT7U8VM1lZD2HTj0442Tk0odlKQf.nerLRQ2.FfNTS7xHC3PwwiIt9Z7i8Lb_
 FUzI_aEM1f3TLtN.lPVkjpCfBYxA4f6tn7GEykOmp1XkVswFv0Noto6Ri_8WRC6VcOVNAN2FaYaA
 9x.qQQyj8HdLD4b6bk78LiXp37kJACuanTIoD8tuEd3XGAWMVJFGy8LwRohaJxNqCaMEb2koqn32
 MIPPqJhlEusDMUwMKCQrqZxZpr9xImvh0KqWHv31yXZ0FIuo7YIBnEpt9zOmd390IH27059EaB7V
 OnYfz.GCSDN9TXK_ry_LLXw2gJSKm579GkTcC_Pte.i56bjPHjgcKegxD4EylCjv.WonD1kTdWl2
 6jJnXK2DqZrh0S8QD.3z4q_LK7YVBOT6vGtzYq0qqAnKetJwc77sKlCqd7hqiC.qgU4J3km08KDv
 dgMv9RJKBvdJTwZeAS0F5YCYp3P65yfNQDeK533SzderJBT1JVKkJFEwssKwWZ1Eg1C.6pCYVW6m
 qn9gwXBvEYry52238qko80nQRj7qrgFrC_tIEpf50gyutODsuDb31YQbEUFVtChTOaudb6V3BjFd
 Ksv1MEpQIdBcSmNMJdGlebf367SPP8KfbhjYSe.nxE6B2EQtNNNn9rrqgP3uoTlw5i3ddkcQPdlX
 HwPu.IL0VoquGOyJ2Fuf8PbmDOjoTMyJHDmR.5tAEkMD51wimLdRGymzT9Y8AmuKyL07X2kqdbqD
 8NGY5WFQaUsZ6MhhRHdDaJMoDGCdK7RXfzwwanvCGj0i4IXpTHTEXwfQaWu4N45KYrWsvAnTY0Ht
 6vIeAHKrPTEjc6bS9DywXq0s_nThV7N3Sx_4C74cw7o3alg73ZDwUwsByyuh2BVqSrzlNm7cGUCH
 iZYXGebJspUYj.PkdTjuM2t5.eJoCr1dwCFjYCxxmcTNpk1FHTfA2dLczzgpGQ5XIDdaVTOXO0pT
 _qpdet5fkYd2c81r9wcwzaVG07Mtzd0JIoSDnr2iU_60hfpJJqCwaz7NVojzhhja1xt9LureHjz1
 qKd.WDvCHKBHake1GmVQc19Rg.fWL6DvcnIOGilU85LF93R7naFMtifML6FGMeyYRvTA4X_1sYy_
 eJY.rHThrFfghCrbxHwQRHstwB5gSPMrFLd_9u.38JBuOaO8z1zaJkVZ_hMZ4aiKbPMlncd.lYcQ
 pMRmve9qaeAwRSFCIxSF9cCik6jah6UTE0Ekgd.cEqmgnp857FPRhrBVHjs396M7ucqDyIKbrCcT
 UdlADgIChpyparaaYge0_KPx8bCzIv3Ub.3PpEHwDUjyJHR6G4yO3GAqqYocyWjwjcBni5crKWV1
 h.vTYvZ6Oabj5P638EZrMzVVSgM2VTlkNGwNuxFORhV0Awn8ce8woMoiMvYgxP5gMwiOD7cX2_Hf
 OQKSaGvG1E__ALLfs2JrI6DzLIQ2RDz22SNUyA3iOF2Db3GvrnVyN1v0HeAXcumZtcsElZkGGUZt
 C03MzcQHme7HvTLt_InBU32IA_xr7RFw7UIqJuqn5kBXoeAHFUvZSCWAkFSA91wGolzoZk7jIT3n
 JRS8FmqtNvVI0PDIn8x95ZBrKFfHwGrLobHkdeEN3o3InOUxu162c_Pz1Yt1eDuP_b7cu9pB75mM
 Z8JtkRid45XXX.6UAH5edmuatEJJNt673HLh9vRmZ95O2_L82Fop9HEQIn23YAd5icsrkTGG57oc
 nT_pPeZSdsuBi92Q5i78fLKG020V8YIvY_DmPzYdGMXJm0BbTmHkE9fA1aPZ9vSsocyClGxoXQzg
 zQ80lGhXV37A8g0c0bmBk_jpGVhNtu1uPTp_o8jxomXS3NCSxwzTAr1RJ..fhDNHe0pi38aLepMC
 d3zVBazE8xg5jgkXE2IkIpmE9HSwc9AsB3RkOS6d98h.iBSeMMGEGtSvQralgPOt0varl5powll5
 3OairnYba.IHjAJxCrqof22b3sQEUg3VyCm7whM0gB75EZrmoiVBfZ1215Fq7R2HOKRuir0WnPWV
 A2iNKejp0V2i8pQKcSF679r5MDsPHnQt8H5U8uvVJja.mbwuSmVZ55aveMz816mpNSezZAXg_m8A
 c6oS0WQ3TrrhDYR3DzLTD7OQ2eyu1os8bBteYAnrMfallfgcd6mVddYV_L.tzTT._06Tp3tTB3wx
 h2G9iaPoESaO7Q66cpVEMiFw0OfIgUcjX12zdodFyfPBmO41.EbknldwnJOHbKVCGq.5LpLZ_z3y
 .bxobLGbnDP_E5RJiO1Ntpo4MnZhzy4X48aNXQEPI5IYa4Tk83VtNW14E3J8b4Ood.dDU0IXfB2F
 DMg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Oct 2022 05:28:49 +0000
Received: by hermes--production-bf1-585bd66ffc-gfghw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b6701a2b68fb6ae86f37009935544747;
          Thu, 13 Oct 2022 05:28:44 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: <6A679278-69E0-4592-BFED-48ED8598C2F1@yahoo.com>
Date: Wed, 12 Oct 2022 22:28:41 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BA96801-D70D-48EC-8DA9-F67C2826609A@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
 <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
 
 
 <6A679278-69E0-4592-BFED-48ED8598C2F1@yahoo.com>
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mnyjv6hpdz3Zdf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hO0TQd24;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.97)[-0.973];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-11, at 19:55, Mark Millard  wrote:

> On 2022-Oct-11, at 12:10, Warner Losh  wrote:
>=20
>> On Tue, Oct 11, 2022 at 1:03 PM Warner Losh  wrote:
>>>=20
>>>=20
>>> On Tue, Oct 11, 2022 at 12:50 PM Mark Millard  =
wrote:
>>> . . .
>>>=20
>>> For:
>>>=20
>>> boot-2022-09-16-15-45-b44869cba1b3-good
>>> boot-2022-09-16-18-02-dd2b9c296776-bad
>>>=20
>>> there are no armv7 artifacts available between.
>>>=20
>>> The range is:
>>>=20
>>>        A) =E2=80=A2 git: b44869cba1b3 - main - sound: add patch for =
Lenovo Legion 5 Intel Nuno Teixeira=20
>>>        B) =E2=80=A2 git: a705c72f2142 - main - stand: use =
archsw.arch_copyin instead of i386_copyin Warner Losh=20
>>>        C) =E2=80=A2 git: 4c670b53a000 - main - stand: use =
archsw.arch_copyin instead of direct call Warner Losh=20
>>>        D) =E2=80=A2 git: 8b19d28d68a3 - main - stand: Create =
MOD_ALIGN macro and use it everywhere Warner Losh=20
>>>        E) =E2=80=A2 git: bca9c87b6104 - main - stand: Create =
common/modinfo.h Warner Losh=20
>>>        F) =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move =
md_copymodules into modinfo.c and reduce copies Warner Losh=20
>>>        G) =E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx =
macros from modinfo.h to .c Warner Losh=20
>>>        H) =E2=80=A2 git: fc352701ff3a - main - stand: collapse all =
copies of *copyenv into md_copyenv Warner Losh=20
>>>        =E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store =
to bi_kernelname Warner Losh=20
>>>        =E2=80=A2 git: d43bcf62a218 - main - stand: Stop support =
booting 4.x and earlier kernels Warner Losh=20
>>>        =E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete =
fields in bootinfo with _was_ Warner Losh=20
>>>        =E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader =
smaller by reducing size of bootinfo Warner Losh=20
>>>        =E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo =
rather than have it be static Warner Losh=20
>>>        =E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support =
swapping headers on powerpc. Warner Losh=20
>>>        =E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge =
Warner Losh
>>>=20
>> Yea, I did a bunch of refactoring. I'm surprised that this produced a =
change at all. Would be nice to
>> know which one of these caused the problems.
>=20
> 5d1531d9d4e7 has the stand/common/metadata.c "align"
> removal that the later dd2b9c296776 fixes as the
> "mismerge". So it appears that most of the stages
> would not build without adjustment for that.
>=20
> So presume I've made the adjustment for any such
> such cases below.
>=20
> H) fc352701ff3a Bad
> D) 8b19d28d68a3 Good
> F) 5d1531d9d4e7 Bad
> E) bca9c87b6104 Good
>=20
> So the good -> bad back-to-back sequence pair is:
>=20
> git: bca9c87b6104 - main - stand: Create common/modinfo.h Warner Los
> git: 5d1531d9d4e7 - main - stand: Move md_copymodules into modinfo.c =
and reduce copies Warner Losh
>=20
>=20
> Note: I cross build armv7 via aarch64 normally.
> There is no "buildstand" analogous to buildworld
> or buildkernel that takes TARGET and TARGET_ARCH
> for cross builds. Thus I ended up with a full
> buildworld to establish a context for the cross
> builds.
>=20

I got another oddity to add to the evidence,
although it might just be a separate issue.

First off some context: With the additions to
the microsd card:

/boot/efi/bcm2710-rpi-2-b.dtb
/boot/efi/bcm2710-rpi-3-b-plus.dtb
/boot/efi/bcm2710-rpi-3-b.dtb
/boot/efi/bcm2710-rpi-cm3.dtb

I can have armv7 13.1-STABLE FreeBSD boot:

RPi2B v1.1 (The official support targets this.)
RPi2B v1.2 (not tested but I could)
RPi3B+     (no access to such)
RPi3B      (tested)
Computer Module 3 (no access to such)

(I recently sent out notes out that are for mostly USB
booting to match more closely Bob P.'s context. This
has some more involved to span the range and some
specifics of dealing with oddities of the media I have
access to show up in order for me to demonstrate
operation.)

Part of the point of 13.1-STABLE here is avoiding all
the recent EFI loader changes, not just one block of
them.

But for main [so: 14] and the same bca9c87b6104 based EFI
loader that I reported as working on the RPi2B v1.1, I get
differing behavior between:

RPi2B v1.1 (boots with serial console & HDMI output throughout)
vs.
RPi3B      (serial output stops and, when HDMO is connected,
            HDMI output keeps going)

For the RPi3B, the last serial console line output is:

Kernel args: (null)

By contrast, for RPi2B v1.1 with both the serial console and
the HDMI connected, both get console output, reaching the
login prompt. (I've not certified every line is present
on both. There could be differences for all I know.)

So, in this context, the RPi3B seems to hit the console
handling type of issue that you were originally expecting.

I originally looked into this in case the results meant
that you could use a bcm2710 based RPi* instead of a
bcm2709 based one for investigating the armv7-style-boot
with 5d1531d9d4e7 and later EFI loader problem(s), giving
you more options.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Oct 13 06:44:45 2022
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 4Mp0Pc1Wjfz4fDCc
	for ; Thu, 13 Oct 2022 06:44:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mp0Pb0nvCz3gb2
	for ; Thu, 13 Oct 2022 06:44:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665643489; bh=ZAIKzwcp3G81Z4whiAiuyPHkuczkcayvk5/g5zSFOrY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VWJJZ/sZGSCZpkAZ4RBwUHu3NbuNgsMvOngseK7yOwsBoKGJChjKfWQdiNc2epIhWHncykqrA7etrWn2kr2uPuocEizEjG50USrGZu/bxEbCtGgiX8dx2+gtdJRlefZzeZ32ptEF7+3LRrE4hWB1uO7YIFJ7d9ZHlo96MKOJ7DLt1b75qQs0vpJnjgbxwEHMPfYRb7+bPJmECh2cjYdsGB80PYApgEMUaaxzyIDD7vurswxiIZMI/hpqXHZ6l7TLylOQMhnwbDlcyv/y/fBTgTO9a/4+7e+3KIZAExdyXjZnz8LQD5h694Vo/VXkJfRnwa9W2e26g8wdAqvaan476w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665643489; bh=jQYfYdXq95qOFtf0RpXG/Y0TG76x8Xj0LmSG0brb0m3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HmBBmkQfMj7RxhjEUcMZ5nDhlvimhYxgrUbggtPO7afPl2zCsJtfHebucQE2wPwPGxFDjGA9A0mMO615WCsp2wRuUm1xMGPEp3Kpk5VVBS8TylQa6ogFG2qEpdicDEOji9ViTAPTuoop8JqUp48+LjwzUYEV6PWh014HPP7EMM8YWoefoY3BxqogqpaYNskzj84vEVt0lrt7TzXTzizkImkqNtWXqQ4Xrj0jXWl18WlfX+1rys6U7PeW4PAk5yXJqUqoNhScZ6CFUvwe0K9CdMLyzs2Ekgi7k0NeC2/NUEfPN0G+Lib9/19q/Lszoc7+5rwnpUld9m9c4aUp86WKsg==
X-YMail-OSG: XZjnafgVM1mShxehzEXl_XxtMH7QhdPg94vJT6f8t2OMKIEkWwAaMm9T68y42hk
 lmfNVZgptVQTL6linvgJAeFfvPcLIzf254IwPuJ1JcStgMmqo.vsXKLnJ59Q5wEcC4J76onpnuVF
 LkghE4GvDrxPMLmE7qnTFKEFxqMFJ9ZuNX8.llMdiYBXxDt81JfU28U_yVPZN5e0M7dAdVK5n1bw
 NTGLgxihX0K2My3Zm8ZquphMmSb5am_ddEEfuBLj.9sm_4AmNG6V5pr8YzIfKYwiPbdR6Ed7Xk5C
 EtqXP4IYeHuiKz.FCVs8zdd8clw.FSojXrc4wIK9xrOjGTA3TUabbSRux1c1NDdra7Ap_cWiBGDV
 ACgAAPUAAyQiyrzBrbdyf3GjhQvVqWf24Epucyf2UxUh7BSZm3jtNZRmdvIYq30ml8ga.kobv55d
 M5w5hFI_q.h.C4RRAZHEk_oylV0N.6cqXjoKn6pIjzc0EQiB20QkssgZPmbjTe8Fm1FS7LrN_f3E
 babwV5lKfJKq9IFZuISNd6WeJQZcyo6VLBLZkbogHIo5kRrzwAJBWI69VYK0QAyMseD.TqhF4v0X
 hDymKo1VwG3aGEfgBuwSTms_3iSHZKkJbBJ0F9iGJ.JL3WJAIB8_zWR5OPi8cF6ovaOlPVItAXHp
 va9kymI8G3kZp1Yd2NBJ5gUeCCkfVoXcfRDfn1kynoo7ltGiYW2Ew4mmcblYSrtSpwJ.ngGVDFFJ
 lgRockK7cs.y.mzB8dJgyGWUU.gvyjw8WktiNd9ec4qGa.uWyQVR8TOTG7WOJPicP4hZZH5KzAaG
 KKc81UqsmVyV45xXlXV.pVorm5TDnz4fgvvE1vxNcIpiKxgAG06ovBAOh6yADTUqIDr3WYK2wD.G
 HTG0benrH5b9OeIiA9hihYudaPrN5o.BdLsobeGmkz8r_5xAXn4rEZ4H8kkNVI5bnJWDZmEVCIkh
 BjRnz0mReme42UQ8CMZwU04cyIz2tE6SdmntcmYUHOu6dS8SskXMoIZh1EDzD2ksy0zozidIutJ9
 6sA2Y6QzFGIpkBzOpCxl_9olvwkmpsuqSC3xsan5rbZYSqZ02v1IWrAIEUTOaSru5AqgPu70wXi3
 RsVmZ0G8cmRctGs7njXcpZFOKdnIZieLlE6eBnbCCKFg10oJ6bUJstXl2kkob9v142qCHeJTgCPa
 oXpK2uo9SYCAwQ5pttVoFkBHgkd_WGhSDdwZOAdaJWqDKxddp.ASvV.NoxkBHiUTjmn.O6RL0g2F
 2cg9tX16tJpoSRpTmW9eFb0ajCdX_WJaIrwShHP0EXplkTCyHReg8YJdjI6G7RFA8cEIFShfGXue
 C0nEBqKyYMWh.G6d5eitJ2f0Io8jTDWSLXU1BHnrn8PvxrQqeFcQO_bUYDKc_EQPgesbGIwLU_dR
 w_J6PkZ6GVa9toprKN54Q.0l3aXX91RQTn9ZwVuHpbYPp3B6hA8tWoWeZgmoK5blwx83Ex5sZDgE
 VDRPeo3BS8pYtEkuEtRJw3DgQW7lA0mzuQ1s7IreHeSgC8UzDoeTNZstu_K539CXy5y15_kEmtX9
 UsPBh5iKoHA3u9tJZIQ2_.hvi1N_pmES5TFbb6tijLZcwF2UGqZf4wws5c8xX6sYhcHOTQ0Qq5xg
 c6xl2kMKrUjWJb8bksVcJCixTPtA2pa0v4Qd4ntI3CBtvDSoxXEp5H1M2Frhc8HGsXWs4CJrqhiy
 MPWgl2BEB5C1a6OvQm1WVFWsJ3e7z3fdbIJeFlJqzRpcmm_4eLUtsiwC9pCy0SiySS4Z1zxTriiF
 cDwSHebtAEpE.YL1N88WOrVepqCvvXl6_L9VGWG9rZvYzkfP_ZsTQkTzXrklCDmWPFFagOJgfeU3
 9A9ScW1CKer4cyfh5Qgxtbp4WD2pIQgyhdIhcc9wZFoOz12q4eVX8NNZD6REYHa3QdnGRO0qeLtz
 Q264u.NUSADW5v.ow7CJl8CMPETz4.DAtBNNLfXJc4_bNvw3COKoN10W1JpX2pnSTkn5EJ3jtnmt
 NTrUC92ExqQbfGBRY9d7.v8tj5U3rsifyysuwpm5ACa7ed7auYAe_9z.9UJA6X_RLx9D_C2Fp4jO
 4jY9bvs0HeBFAzJ6_1B97eNokkpdiAGiGhrVHct4CJIFtctM3B6daaN.qB6sX24yZEELwLZuHZSP
 rZqxiDUcpr0w_AHWy.HvcXV4b7C6SytYkyRAAguDfYLpHi1.LW8PGthJ9sNZQWI7n1DZkjXkVURT
 kqyuSrr76mbz3pVo4qdRmA40KOSD2JpqxGig3uUdn3dh5vsMlpTqrMLf5ITnUDoCC2dW53.xzxGG
 rclY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Oct 2022 06:44:49 +0000
Received: by hermes--production-ne1-5db649d989-bf48q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b88f873637eca2cc603b93177e989992;
          Thu, 13 Oct 2022 06:44:46 +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 \(3696.120.41.1.1\))
Subject: Re: FYI:
 FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20220930-42dc8696df5-258315.img is
 broken for RPi2 v1.1 (so: armv7)
From: Mark Millard 
In-Reply-To: <6BA96801-D70D-48EC-8DA9-F67C2826609A@yahoo.com>
Date: Wed, 12 Oct 2022 23:44:45 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <5B631C27-E68C-4F38-96B5-B311110A8F86@yahoo.com>
 <6EF84694-7CD7-4A9F-BF9C-DFFB52F557AD@yahoo.com>
 
 
 <6A679278-69E0-4592-BFED-48ED8598C2F1@yahoo.com>
 <6BA96801-D70D-48EC-8DA9-F67C2826609A@yahoo.com>
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mp0Pb0nvCz3gb2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="VWJJZ/sZ";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.92)[-0.920];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-12, at 22:28, Mark Millard  wrote:

> On 2022-Oct-11, at 19:55, Mark Millard  wrote:
>=20
>> On 2022-Oct-11, at 12:10, Warner Losh  wrote:
>>=20
>>> On Tue, Oct 11, 2022 at 1:03 PM Warner Losh  wrote:
>>>>=20
>>>>=20
>>>> On Tue, Oct 11, 2022 at 12:50 PM Mark Millard  =
wrote:
>>>> . . .
>>>>=20
>>>> For:
>>>>=20
>>>> boot-2022-09-16-15-45-b44869cba1b3-good
>>>> boot-2022-09-16-18-02-dd2b9c296776-bad
>>>>=20
>>>> there are no armv7 artifacts available between.
>>>>=20
>>>> The range is:
>>>>=20
>>>>       A) =E2=80=A2 git: b44869cba1b3 - main - sound: add patch for =
Lenovo Legion 5 Intel Nuno Teixeira=20
>>>>       B) =E2=80=A2 git: a705c72f2142 - main - stand: use =
archsw.arch_copyin instead of i386_copyin Warner Losh=20
>>>>       C) =E2=80=A2 git: 4c670b53a000 - main - stand: use =
archsw.arch_copyin instead of direct call Warner Losh=20
>>>>       D) =E2=80=A2 git: 8b19d28d68a3 - main - stand: Create =
MOD_ALIGN macro and use it everywhere Warner Losh=20
>>>>       E) =E2=80=A2 git: bca9c87b6104 - main - stand: Create =
common/modinfo.h Warner Losh=20
>>>>       F) =E2=80=A2 git: 5d1531d9d4e7 - main - stand: Move =
md_copymodules into modinfo.c and reduce copies Warner Losh=20
>>>>       G) =E2=80=A2 git: 2e6ed47a4609 - main - stand: Move MOD_xxx =
macros from modinfo.h to .c Warner Losh=20
>>>>       H) =E2=80=A2 git: fc352701ff3a - main - stand: collapse all =
copies of *copyenv into md_copyenv Warner Losh=20
>>>>       =E2=80=A2 git: e895ab3fbdc1 - main - stand: Remove dead store =
to bi_kernelname Warner Losh=20
>>>>       =E2=80=A2 git: d43bcf62a218 - main - stand: Stop support =
booting 4.x and earlier kernels Warner Losh=20
>>>>       =E2=80=A2 git: 59b1d074280d - main - i386: Mark the obsolete =
fields in bootinfo with _was_ Warner Losh=20
>>>>       =E2=80=A2 git: 4134f677eb39 - main - i386: Make boot loader =
smaller by reducing size of bootinfo Warner Losh=20
>>>>       =E2=80=A2 git: 9758dd3de1cd - main - stand: Allocate bootinfo =
rather than have it be static Warner Losh=20
>>>>       =E2=80=A2 git: c0ecae78abbe - main - stand/elf: Only support =
swapping headers on powerpc. Warner Losh=20
>>>>       =E2=80=A2 git: dd2b9c296776 - main - stand: fix mismerge =
Warner Losh
>>>>=20
>>> Yea, I did a bunch of refactoring. I'm surprised that this produced =
a change at all. Would be nice to
>>> know which one of these caused the problems.
>>=20
>> 5d1531d9d4e7 has the stand/common/metadata.c "align"
>> removal that the later dd2b9c296776 fixes as the
>> "mismerge". So it appears that most of the stages
>> would not build without adjustment for that.
>>=20
>> So presume I've made the adjustment for any such
>> such cases below.
>>=20
>> H) fc352701ff3a Bad
>> D) 8b19d28d68a3 Good
>> F) 5d1531d9d4e7 Bad
>> E) bca9c87b6104 Good
>>=20
>> So the good -> bad back-to-back sequence pair is:
>>=20
>> git: bca9c87b6104 - main - stand: Create common/modinfo.h Warner Los
>> git: 5d1531d9d4e7 - main - stand: Move md_copymodules into modinfo.c =
and reduce copies Warner Losh
>>=20
>>=20
>> Note: I cross build armv7 via aarch64 normally.
>> There is no "buildstand" analogous to buildworld
>> or buildkernel that takes TARGET and TARGET_ARCH
>> for cross builds. Thus I ended up with a full
>> buildworld to establish a context for the cross
>> builds.
>>=20
>=20
> I got another oddity to add to the evidence,
> although it might just be a separate issue.
>=20
> First off some context: With the additions to
> the microsd card:
>=20
> /boot/efi/bcm2710-rpi-2-b.dtb
> /boot/efi/bcm2710-rpi-3-b-plus.dtb
> /boot/efi/bcm2710-rpi-3-b.dtb
> /boot/efi/bcm2710-rpi-cm3.dtb
>=20
> I can have armv7 13.1-STABLE FreeBSD boot:
>=20
> RPi2B v1.1 (The official support targets this.)
> RPi2B v1.2 (not tested but I could)
> RPi3B+     (no access to such)
> RPi3B      (tested)
> Computer Module 3 (no access to such)
>=20
> (I recently sent out notes out that are for mostly USB
> booting to match more closely Bob P.'s context. This
> has some more involved to span the range and some
> specifics of dealing with oddities of the media I have
> access to show up in order for me to demonstrate
> operation.)
>=20
> Part of the point of 13.1-STABLE here is avoiding all
> the recent EFI loader changes, not just one block of
> them.
>=20
> But for main [so: 14] and the same bca9c87b6104 based EFI
> loader that I reported as working on the RPi2B v1.1, I get
> differing behavior between:
>=20
> RPi2B v1.1 (boots with serial console & HDMI output throughout)
> vs.
> RPi3B      (serial output stops and, when HDMO is connected,
>            HDMI output keeps going)
>=20
> For the RPi3B, the last serial console line output is:
>=20
> Kernel args: (null)
>=20
> By contrast, for RPi2B v1.1 with both the serial console and
> the HDMI connected, both get console output, reaching the
> login prompt. (I've not certified every line is present
> on both. There could be differences for all I know.)
>=20
> So, in this context, the RPi3B seems to hit the console
> handling type of issue that you were originally expecting.
>=20
> I originally looked into this in case the results meant
> that you could use a bcm2710 based RPi* instead of a
> bcm2709 based one for investigating the armv7-style-boot
> with 5d1531d9d4e7 and later EFI loader problem(s), giving
> you more options.
>=20

Adding 2 more files (only 1 necessary) and adjusting config.txt
I get both the serial console and the HDMI console not stopping
for the armv7 bca9c87b6104 EFI loader --on both the RPi3B and
the RPi2B v1.1 .

I added:

# ls -Tld /boot/efi/overlays/*-bt.dtbo
-rwxr-xr-x  1 root  wheel  1073 Mar  3 13:29:56 2021 =
/boot/efi/overlays/disable-bt.dtbo
-rwxr-xr-x  1 root  wheel  1819 Mar  3 13:29:56 2021 =
/boot/efi/overlays/miniuart-bt.dtbo

but am just using disable-bt.dtbo --via the updated config.txt :

# diff -u /boot/efi/config.txt.orig /boot/efi/config.txt
--- /boot/efi/config.txt.orig   2022-10-07 05:38:00.000000000 +0000
+++ /boot/efi/config.txt        2022-10-13 05:39:26.000000000 +0000
@@ -3,3 +3,6 @@
 kernel=3Du-boot.bin
 kernel7=3Du-boot.bin
 dtoverlay=3Dmmc
+#
+# Local addition(s):
+dtoverlay=3Ddisable-bt

This changes which UART is used for the serial console.
(As does the alternative *-bt.dtbo .)

So, in summary, to allow armv7 boots via the likes of a RPi3B
as well as a RPi2B v1.1 with the serial console and HDMI console
both operational (if connected) . . .

Based on microsd card media that are from the likes of:

FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20221007-b05b1ecbef0-258483.img

The changes are as follows.

For /boot/efi/EFI/BOOT/bootarm.efi , use the bca9c87b6104 EFI
loader from main [so: 14], not later.
(Other earlier ones/13.1-STABLE ones/etc. also would work.)

Add the files:

/boot/efi/bcm2710-rpi-2-b.dtb
/boot/efi/bcm2710-rpi-3-b-plus.dtb
/boot/efi/bcm2710-rpi-3-b.dtb
/boot/efi/bcm2710-rpi-cm3.dtb

Add at least one of:

/boot/efi/overlays/disable-bt.dtbo
/boot/efi/overlays/miniuart-bt.dtbo

Put one of those 2 to use via config.txt , such as via:

# diff -u /boot/efi/config.txt.orig /boot/efi/config.txt
--- /boot/efi/config.txt.orig   2022-10-07 05:38:00.000000000 +0000
+++ /boot/efi/config.txt        2022-10-13 05:39:26.000000000 +0000
@@ -3,3 +3,6 @@
 kernel=3Du-boot.bin
 kernel7=3Du-boot.bin
 dtoverlay=3Dmmc
+#
+# Local addition(s):
+dtoverlay=3Ddisable-bt

With this both the serial console and HDMI console should
work, each allowing a login.

This may suggest armv7 snapshot content changes in addition
to the EFI loader fixes for what is after bca9c87b6104 .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct 15 20:19:07 2022
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 4MqZNM0vT8z4ff3T
	for ; Sat, 15 Oct 2022 20:19:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4MqZNK6wQsz4Kk2
	for ; Sat, 15 Oct 2022 20:19:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665865151; bh=DdldsFRP0oQFOttE+5ycWvoufilQf2Kh05IvrETVIxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sYwZnyb+wuce/zhyIN6osuVCjcjRTnXYOMNsCzPnPl5udTY9gjkAEN/8pP5vlkzWM5OoqxE4hFgDoc3pgaNDmHDQy5aqickWhmpphWnGJIsRxuDdsm2DeKXYbVlnJ1X51ZJTPKYWvKl6ee41ek60Pn5LzmxkdYNI+sFhDSXcTbmqJkHAFc4E8jbIjR0FXkUWEUvWxH99+gd1P4hAYfsXNMb7XtxgrSyAwHGc3ureg81YxW3IayfdkkRCzhhSaCJ3Ab9STHS5lMPsTIQ+GE0GEXsmpZNGJGm8TDdRSG/QQEfT05M+vklq4gVgrrw+pEzgYM6mSBeTnIZBlZXi5rx7aQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665865151; bh=pgAq4fxr3lQnr3YCbw+z/uzhHQwsV537V2MgaXRZjlq=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mWx1z2fmNK61uY+8AaVfe5D4R/IsGF0yCZU2szYuDtanHs/ZEfhaKlvZZ3aE58isitKbQG6oAmtfwqZ84twQOYLIS1aiv5uT7WEL2bLXYjwqG+WZYqC/NIERd2KGxHRBbrsrBZEiB0KTOwH15mbQgwlkcBk9mhtps+2JGSxQoczMynOQKm0/+HVUtvebpM7tFuv24BoQNcPtIjg7X7PJNw1z/rBS9DEcZEOvN94ek4uekQWfzBTduMwsKMMrefPVAzPSE/L4vv0Q3s0WmqDShsu1rraTMTZA0pgrAgjOgpHeahiO94PQfgYphg05MoMsbt6vg360kZxf7qR9EhN18A==
X-YMail-OSG: 3SIf_eEVM1kz_gvlvWVwGwRBGrQm.4gNpCVqDd49bFUcUzcQsWz2uYZJNpNpiko
 09mkzAe640L87FjeqZkvq9Zj5XPL48LdBc6ZjgeM9YpYa4UfeqPDr6ZPFR6nEk2gsDPi.t6AXkqf
 ttUk2.gMd3gaV4a663kiIhpUVXbtR8unmISfcip3PQq53yrPkDlJRhyF_mIzl1Th6wqRNQM2YB.e
 kXyVhrOMcD5jPwbTZFNbKaQ2InWEoQKIwkqbCi6auA2YtkJbbw3ZErhTj768ks_MlEkiAe2uA_TI
 1PD1VA2Z5oiuIvmNeolEeviu65.pwM.T_k1EaEqDlfD7HXSyv98_3ZABNC7y9D4mbfM11xBLDxjf
 KjLthyduACJ1uYacxfCbp9avx5bRjY1AM3IoeKzMhQK5hPKK7w989hCwXwkfInJ2GmW8yu8SZsD7
 IZsnXAw_rzv6lwxXvNFFiOvV.jdqW0.kvPhP._KnktrGu8lqay45hVWSxV0Uh5gbwQ.IQNWkZ_OD
 zdsJ0rqRylELfSMpynKLpAnvnD4VYL7munfa3.7EEeDHfTbsMbIuwhiQatGSbVhgRlSKRl1JPurA
 tH3UvsoxkbNRJZHiYoYD1D1aGIGdaA24qRd8m7i2ZEQiCHqtH2plmWpKb0MscugSaiHV8ZK9SpWt
 wMqLfORRTrbtnHOu04DN85WSZNNUgiCvTcT2ZfqVgtjZ43qsP7IjRCOqMBexP9WfCgwxKm.i.Uq3
 CV0GQMfqt_.6QOdfJ1Ni.G3QZIyF.vNHx8eo5y8S2siIcGj0vBJuyq_K9chtzdAVKseFvaSBXflK
 61uByLyX94XxoRMPPo0j9VYvIqRKBxmevKyyQf57Q4ASaa07guNnTj_Qf3Nz6m0fA0Ahqipd64qA
 r4lhJ4FpQbdkNZuYFGFNdG4GwdqyBsIvarEdtC8hUjJnJVgXZK3W3eiDkYJXUgJB_Lhn76OhznmV
 e7iFuthXokvsIS8Ddp_x3Biv34JGgvoF4WvVMPWVnZb1sWZuhR6YAuW2NEyGVnSOAzgTANukYOIw
 PXV8BLEMm6glRfWaBQr2YiVGeR8CLXJFK6mOOKzpIUQEZ7wOSz0aAYaQFqXuUEKvwb9qNkNr_to3
 zRw4tkd50zz5zjccIk18LgRX58RZ7dY0u9qOAzsSe15DNztGKbKLOcx9nxZexv__zfKNQ6SUf_i2
 kKIzw7nGe0dP49T.nyegzEiwjZHnWO8WpcCHZeRrp2sCSADdBEiQXmo4fNKgOTF08XJ4ANlOdFlj
 OTY8UA_Df8JiqT4GgEqeaqUDHuzw5xY4W7hqV0pLnU2bRuFA0ulTzAQ17gPngcbor_u21NGAsmhC
 KTib1tXQwItWs_ydmfL0qAYIcHw1VNBvvIZV.vsV9iZXVPEZuP6w1v_3sVMftVYZKG4V0nLBvKtz
 Zu7LvtjKD8q.1rjvDLM4ewKMtRuzqNrSN310r4lhlxCRe52lPtyU8TFGEoM0UKfTFUTOysb4SQwO
 dgM.b5Kw5Ixp5H0D0Yv14K83IfvH04U7MKxXwEcf0znDNs8.9R4GtbKSgHaDDsufgYKX1rbKluwH
 P1XwsG0G6UmvTsa5OoEvy0v6dDwrfFs9vnf40noVffzbKyrkKmzZrIc9NpFv3_jSOmyA4phLT2QJ
 iShIqtR_QNzvK5nmGzIg8bDZltIDsUfHHBivOzd.PllyOr_rBVw.tkE.86r4I2tE6mamm91NbY0C
 _DYZYM8wxiLs9oMsJB2QfiICs5r7Iizc1ACfCjTnJFm4tkl1xE836ObPKiILq9hiGoCaW_bnwTs6
 9nE_PbcqxdquuinJSULIHR3qcnOfN1s4kmbDeVLQVNsPhlzvRTvNVeHuvxJO7nONUi6wSCp4c8tL
 h8pun.PZ.yCGLJoT4Q7miZlC0tyrWBPgwZRTdZfbrf6L923YCPa0I7DwQjVuBLqKIH0I63AkeKNs
 zQIdiH4M3AajIfd9z1Rf1Sr1ACr8J8I7WlRoH30Io.P6kIMpXJab03woHSjsyuSHYLhoVIPYudku
 4DUll2YWp07FhzClCRS_rVDJVhqSfRTdbmGJOyPW62h0HD7oSp0yi1XUuJIOMP4iKJMKBJ4kcnUC
 kPDTsJRmrBKlupI47dyj.be791fvj0oumNC4iuSQwP2Ngi_n__dIWrtfwShXyjAtA.Gv0tClYsjL
 XgBGe4FFcdaK9biEfWxs6nKV4bWceCwY6Zbd0tlJlyokwzrAXAggjDbXRbRyLxIxroLdqaFjljjj
 cR8WKW3RKimlw9xEocRkx3VB7ad5IiINwTGKHE3yRrmT9eBzGthMvVgW3ayh.IiUIx0zbotb_Soa
 UCwCmnlGmjcRty2gGWD8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Oct 2022 20:19:11 +0000
Received: by hermes--production-ne1-5db649d989-8c854 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3f4408f3f05da924b8488735744e6788;
          Sat, 15 Oct 2022 20:19: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 \(3696.120.41.1.1\))
Subject: Re: How to armv7 boot both RPi2B v1.1 (bcm2709 --real armv7) and
 RPi3B (bcm2710 aarch64),  but not RPI4B (bcm2711 aarch64)
From: Mark Millard 
In-Reply-To: <9635B188-3F76-484A-8DFA-3C508E85B9D2@yahoo.com>
Date: Sat, 15 Oct 2022 13:19:07 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E0CD516-FDB2-4379-B2B4-71091FEF35AE@yahoo.com>
References: <6B46F46A-2CAF-42C9-9A04-63567D7DB9B2@yahoo.com>
 
 
 
 
 <28D78C89-E195-4EF1-BB7B-E7F75060BDC7@yahoo.com>
 <20221011153942.GA12477@www.zefox.net>
 <639AB34E-DEC9-4FA8-8AAC-44604672AEBC@yahoo.com>
 <20221011171548.GA12624@www.zefox.net>
 <09A32530-3701-49F1-9369-549FF1162520@yahoo.com>
 <20221011233327.GA13708@www.zefox.net>
 <9635B188-3F76-484A-8DFA-3C508E85B9D2@yahoo.com>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MqZNK6wQsz4Kk2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=sYwZnyb+;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.46 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.96)[-0.962];
	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];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-12, at 16:15, Mark Millard  wrote:

> On 2022-Oct-11, at 16:33, bob prohaska  wrote:
>=20
>> On Tue, Oct 11, 2022 at 11:37:25AM -0700, Mark Millard wrote:
>> [snip]=20
>>> Actually the below is confusing. /boot/msdos
>>> is supposed to be a mount point (empty directory)
>>> at which the msdosfs can be mounted to make those
>>> files show up there, despite being from a different
>>> file system.=20
>>=20
>> Apologies for the ambiguity!
>>=20
>> /dev/da0s1 on /boot/msdos (msdosfs, local, noatime)
>> is the normal dos filesystem on the root USB device.
>> Normally it is mounted, IME.
>>=20
>> /dev/mmcsd0s1 on /mnt (msdosfs, local)
>> was where I mounted the microSD DOS partition
>> so the contents could be listed. This is a Pi2=20
>> so a DOS microSD card is required to boot from USB.
>> Normally /dev/mmcsd0s1 is not mounted when root
>> is booted from USB.
>>=20
>> Mostly I wondered if files placed in an "unused" DOS
>> subdirectory could be hidden from the boot software.
>> It was a poor way to pose the question.
>>=20
>> At the moment the armv7 PATA disk is updating. If it boots
>> the Pi2 successfully I'll try it on Pi3 and Pi4. If
>> that works I'll set up a SATA armv7 disk and test the
>> troublesome disk enclosures.=20
>>=20
>=20
> Here is how I got armv7 going for booting both a
> RPi2B v1.1 (so: Cortex-A7) and a RPi3B (so:
> Cortex-A53). This will not get a RPi4B going.
> Because of the EFI/BOOT/bootarm.efi issues with
> main [so: 14], I used a 13.1-STABLE snapshot as
> the basis for this.
>=20
> FYI: the msdosfs snapshot content in:
>=20
> =
FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20221007-d497b97e902-252653.img
>=20
> looks like:
>=20
> # mount -onoatime -tmsdosfs /dev/da0s1 /mnt
> # ls -Tld /mnt/*
> drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:48 2022 /mnt/EFI
> -rwxr-xr-x  1 root  wheel   103876 Oct  7 03:29:26 2022 /mnt/MLO
> -rwxr-xr-x  1 root  wheel    26745 Mar  3 13:29:56 2021 =
/mnt/bcm2709-rpi-2-b.dtb
> -rwxr-xr-x  1 root  wheel    52456 Mar  3 13:29:56 2021 =
/mnt/bootcode.bin
> -rwxr-xr-x  1 root  wheel       89 Oct  7 03:37:56 2022 =
/mnt/config.txt
> drwxr-xr-x  1 root  wheel     8192 Oct  7 05:22:48 2022 /mnt/dtb
> -rwxr-xr-x  1 root  wheel     7314 Mar  3 13:29:56 2021 /mnt/fixup.dat
> -rwxr-xr-x  1 root  wheel     3187 Mar  3 13:29:56 2021 =
/mnt/fixup_cd.dat
> -rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_db.dat
> -rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_x.dat
> drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:54 2022 /mnt/overlays
> -rwxr-xr-x  1 root  wheel  2952960 Mar  3 13:29:56 2021 /mnt/start.elf
> -rwxr-xr-x  1 root  wheel   793116 Mar  3 13:29:56 2021 =
/mnt/start_cd.elf
> -rwxr-xr-x  1 root  wheel  4794472 Mar  3 13:29:56 2021 =
/mnt/start_db.elf
> -rwxr-xr-x  1 root  wheel  3704808 Mar  3 13:29:56 2021 =
/mnt/start_x.elf
> -rwxr-xr-x  1 root  wheel   504892 Oct  7 03:37:20 2022 =
/mnt/u-boot.bin
> -rwxr-xr-x  1 root  wheel  1163404 Oct  7 03:29:26 2022 =
/mnt/u-boot.img
> -r-xr-xr-x  1 root  wheel   462032 Oct  7 05:20:00 2022 /mnt/ubldr.bin
>=20
> It does not have the timeout file that allows more time
> for USB devices in particular contexts. But timeout
> is only directly useful on microsd cards, in order to
> allow binding to a wider range of USB boot devices.
>=20
> It also does not have any of:
>=20
> bcm2710-rpi-2-b.dtb
> bcm2710-rpi-3-b-plus.dtb
> bcm2710-rpi-3-b.dtb
> bcm2710-rpi-cm3.dtb
>=20
> Such would be needed for armv7 style booting of any of:
>=20
> RPi2 v1.2
> RPi3B+
> RPi3B
> Compute Module 3
>=20
> (Again, the armv7 u-boot.bin does not handle the bcm2711*.dtb
> related USB hardware, last I checked a RPi4B example anyway.
> So I ignore that context here.)
>=20
> It also has only:
>=20
> # ls -Tld /mnt/overlays/*
> -rwxr-xr-x  1 root  wheel  1221 Mar  3 13:29:56 2021 =
/mnt/overlays/mmc.dtbo
>=20
> so it does not have:
>=20
> disable-bt.dtbo
> miniuart-bt.dtbo
>=20
> for controlling which UART handles the serial console
> on the likes of a RPi3B.
>=20
> The u-boot.bin does not have an adjusted usb_pgood_delay .
> (For some of the USB media that I have access to the
> adjustment is important to booting. So my adjsutment will
> be involved here.)
>=20
> The following is being shown after booting an RPi2 v1.1
> (so: a cortex-A7 form of armv7) based on what I adjusted
> and used:
>=20
> . . .
> FreeBSD 13.1-STABLE #0 stable/13-n252653-d497b97e902: Fri Oct  7 =
05:01:41 UTC 2022
>    root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC =
arm
> FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
> VT: init without driver.
> No PSCI/SMCCC call function found
> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000)
> . . .
> # uname -apKU
> FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n252653-d497b97e902: Fri Oct  7 05:01:41 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm =
armv7 1301507 1301507
>=20
> # gpart show -p
> =3D>      63  62333889    mmcsd0  MBR  (30G)
>        63      2016            - free -  (1.0M)
>      2079    102312  mmcsd0s1  fat32lba  [active]  (50M)
>    104391  62229561            - free -  (30G)
>=20
> =3D>       63  468862065    da0  MBR  (224G)
>         63       1985         - free -  (993K)
>       2048     102400  da0s1  fat32lba  [active]  (50M)
>     104448  468757680  da0s2  freebsd  (224G)
>=20
> =3D>        0  468757680   da0s2  BSD  (224G)
>          0        128          - free -  (64K)
>        128  468757552  da0s2a  freebsd-ufs  (224G)
>=20
> # more /etc/fstab
> # Custom /etc/fstab for FreeBSD embedded images
> /dev/ufs/rootfs         /               ufs     rw              1      =
 1
> /dev/msdosfs/MSDOSBOOT  /boot/msdos     msdosfs rw,noatime      0      =
 0
> tmpfs                   /tmp            tmpfs   rw,mode=3D1777    0    =
   0
>=20
> NOTE: /dev/msdosfs/MSDOSBOOT is in mmcsd0s1 in my context.
> (So the USB msdosfs does not have the MSDOSBOOT label. Avoid
> duplicate labels. Which you want mounts as /boot/msdos or
> /boot/efi is up to you. Do not take the choices from this
> example as important for such.)
>=20
> # find /boot/msdos/ -print
> /boot/msdos/
> /boot/msdos/bootcode.bin
> /boot/msdos/timeout
>=20
> Note that I do include timeout in the microsd card's
> msdosfs. I've USB media that will not boot otherwise
> (necessary, but not sufficient by itself overall).
>=20
> As for the USB media . . .
>=20
> # mount -onoatime -tmsdosfs /dev/da0s1 /mnt
> # ls -Tld /mnt/*
> drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:48 2022 /mnt/EFI
> -rwxr-xr-x  1 root  wheel   103876 Oct  7 03:29:26 2022 /mnt/MLO
> -rwxr-xr-x  1 root  wheel    26745 Mar  3 13:29:56 2021 =
/mnt/bcm2709-rpi-2-b.dtb
> -rwxr-xr-x  1 root  wheel    26894 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-2-b.dtb
> -rwxr-xr-x  1 root  wheel    29011 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-3-b-plus.dtb
> -rwxr-xr-x  1 root  wheel    28392 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-3-b.dtb
> -rwxr-xr-x  1 root  wheel    26890 Mar  3 13:29:56 2021 =
/mnt/bcm2710-rpi-cm3.dtb
> -rwxr-xr-x  1 root  wheel    52456 Mar  3 13:29:56 2021 =
/mnt/bootcode.bin
> -rwxr-xr-x  1 root  wheel      207 Oct 10 06:05:20 2022 =
/mnt/config.txt
> -rwxr-xr-x  1 root  wheel       89 Oct  7 03:37:56 2022 =
/mnt/config.txt.orig
> drwxr-xr-x  1 root  wheel     8192 Oct  7 05:22:48 2022 /mnt/dtb
> -rwxr-xr-x  1 root  wheel     7314 Mar  3 13:29:56 2021 /mnt/fixup.dat
> -rwxr-xr-x  1 root  wheel     3187 Mar  3 13:29:56 2021 =
/mnt/fixup_cd.dat
> -rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_db.dat
> -rwxr-xr-x  1 root  wheel    10298 Mar  3 13:29:56 2021 =
/mnt/fixup_x.dat
> drwxr-xr-x  1 root  wheel     4096 Oct  7 05:22:54 2022 /mnt/overlays
> -rwxr-xr-x  1 root  wheel  2952960 Mar  3 13:29:56 2021 /mnt/start.elf
> -rwxr-xr-x  1 root  wheel   793116 Mar  3 13:29:56 2021 =
/mnt/start_cd.elf
> -rwxr-xr-x  1 root  wheel  4794472 Mar  3 13:29:56 2021 =
/mnt/start_db.elf
> -rwxr-xr-x  1 root  wheel  3704808 Mar  3 13:29:56 2021 =
/mnt/start_x.elf
> -rwxr-xr-x  1 root  wheel        0 Apr 24 10:58:58 2022 /mnt/timeout
> -rwxr-xr-x  1 root  wheel   504932 Oct 10 05:17:40 2022 =
/mnt/u-boot.bin
> -rwxr-xr-x  1 root  wheel   504892 Oct  7 03:37:20 2022 =
/mnt/u-boot.bin.orig
> -rwxr-xr-x  1 root  wheel  1163404 Oct  7 03:29:26 2022 =
/mnt/u-boot.img
> -r-xr-xr-x  1 root  wheel   462032 Oct  7 05:20:00 2022 /mnt/ubldr.bin
>=20
> So I had added:
>=20
> bcm2710-rpi-2-b.dtb
> bcm2710-rpi-3-b-plus.dtb
> bcm2710-rpi-3-b.dtb
> bcm2710-rpi-cm3.dtb
>=20
> and (not important on USB media but added anyway):
>=20
> timeout
>=20
> I used an updated config.txt:
>=20
> # diff -u /mnt/config.txt.orig /mnt/config.txt
> --- /mnt/config.txt.orig        2022-10-07 03:37:56.000000000 +0000
> +++ /mnt/config.txt     2022-10-10 06:05:20.000000000 +0000
> @@ -1,5 +1,13 @@
> -init_uart_clock=3D3000000
> +#init_uart_clock=3D3000000
> enable_uart=3D1
> kernel=3Du-boot.bin
> kernel7=3Du-boot.bin
> dtoverlay=3Dmmc
> +#
> +# Local additions:
> +dtoverlay=3Ddisable-bt
> +initial_turbo=3D60
> +#uart_2ndstage=3D1
> +#dtdebug=3D1
> +gpu_mem_1024=3D32
> +force_turbo=3D1
>=20
> (Having config.txt on the microsd card's msdosfs will prevent
> booting from USB media.)
>=20
> I used a u-boot.bin that has my patch, including the
> usb_pgood_delay adjustment.
>=20
> I also added the 2 *-bt.dtbo files:
>=20
> # ls -Tld /mnt/overlays/*
> -rwxr-xr-x  1 root  wheel  1073 Mar  3 13:29:56 2021 =
/mnt/overlays/disable-bt.dtbo
> -rwxr-xr-x  1 root  wheel  1819 Mar  3 13:29:56 2021 =
/mnt/overlays/miniuart-bt.dtbo
> -rwxr-xr-x  1 root  wheel  1221 Mar  3 13:29:56 2021 =
/mnt/overlays/mmc.dtbo
>=20
> I will note that, in this configuration, u-boot.bin
> output is the first output to show up on the serial
> console. This can take a bit to get that far so it
> looks initially like nothing is happening but it is.
> Be willing to wait a bit.

Later below I've added notes about getting initial RPi*
firmware debug output.

> Moving the microsd card and USB media to the RPi3B and
> attempting to boot worked just fine (but required
> some of my changes reported above).
>=20
> . . .
> FreeBSD 13.1-STABLE #0 stable/13-n252653-d497b97e902: Fri Oct  7 =
05:01:41 UTC 2022
>    root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC =
arm
> FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
> VT: init without driver.
> No PSCI/SMCCC call function found
> CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080)
> . . .
> # uname -apKU
> FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n252653-d497b97e902: Fri Oct  7 05:01:41 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm =
armv7 1301507 1301507

Showing the differences needed for bootcode.bin to
cause basic serial console output from the RPi*
firmware (different mounting context than original
message):

# strings /boot/efi/bootcode.bin.orig | grep BOOT_UART=3D
BOOT_UART=3D0

# strings /boot/efi/bootcode.bin | grep BOOT_UART=3D
BOOT_UART=3D1

# cmp -x /boot/efi/bootcode.bin.orig /boot/efi/bootcode.bin
00009872 30 31

An in-place (no backup) update can be done with the likes of:

# sed -i '' -e 's@BOOT_UART=3D0@BOOT_UART=3D1@' /boot/efi/bootcode.bin

(linux typically has different -i notation requirements.)

This change makes it more obvious if there is any initial
progress or not, instead of waiting for U-Boot output to
show up.

With this much in place, the uart_2ndstage=3D1 and dtdebug=3D1
lines work when not commented out in config.txt :

# more /boot/efi/config.txt=20
#init_uart_clock=3D3000000
enable_uart=3D1
kernel=3Du-boot.bin
kernel7=3Du-boot.bin
dtoverlay=3Dmmc
#
# Local additions:
dtoverlay=3Ddisable-bt
initial_turbo=3D60
uart_2ndstage=3D1
dtdebug=3D1
gpu_mem_1024=3D32
force_turbo=3D1

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct 15 21:03:10 2022
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 4MqbMD3Mv3z4fjv1
	for ; Sat, 15 Oct 2022 21:03:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4MqbMC4jS9z3CqL
	for ; Sat, 15 Oct 2022 21:03:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665867797; bh=hyq3+MPwjMvrL/IlIrnl8a7vKn/arrOXxGAGUYdrixc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=YJsthstsyFTiMqJjq5Kdo5GqbV1KgPRvEpoqcoS4dYFvXweRw/LWqsLYpdl4dZMXGSr2oFYCp+FKaPUX1zLUYp9BCOob85QKZDSjgZl+vnZuS2OjuqGChtEP5BNZj+nx16dYqct7CsSuTJwnXT2Anlz582N7kXiKVGvi1uRqnNI2B/F5pjfjKgGTyfjEoeC4AnIUOEBiXPyhe+c4v8yiIn4f9T8F9mLWUYSBcfQHYEVI7P0/hzgD1JrEgBur8HL1Ih1ckM9bvYBAnIkfmyG0D4AeAcDdMC2/lB4/ASAfxqHJqHE95lZPGZuGm+3kWg/n9lanmLyaWbGHLKZATT/laQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665867797; bh=KvxOxCxGDiQRvdXNbA60vPxX8m6xIn62lXCRy5DWaLK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=oCVMqjPrwfR5omSYLMfy4x1jzQabpeRgw2klnc/R+5jZBobiXKYiHuOdh1jSybERVWo3DC0waHIEezSOPL1CTykI8JOTt+mumP9+Gou2cEPK72snLvcwZ0OdUXXgMNtb0fiB5PI9OFaTwphpySeDj9tnVYwxFtXgaupKMeHzS3v0of7Lb+yjQ460fs1B4Vb4fef2nRNX5KKwABDpHgdt1CrXshb/5V8/dGB5VmR0BzER9VTtj3mNWgXvcQyJFzkmVpWUDML6Ug/myPt8WdX9Yb/vGSL99t5pxjM69OXIcv81OCItsOXI3ZbIahcqu0GLCg9iJxMKTDy9zCIPPmE4Fg==
X-YMail-OSG: LisUsCUVM1no3W9syFFHk44Z18J.jUAgA0jUeVBA4y5bm8BJhlTTdDToJqEkkLb
 l8pERyyTf1ppE_V88FDnev3KFUFy5ygrXoi.XdjVWBzqsL90nbmDcuAmCyyYPO6SGkF9Xx9ZqPfV
 kKuj1xhIPOlWN91lf7xEo9Oe0e8vEO893NMOF.TLPlsqk.hD_xGj_d11XVnb9KaC4YSLlFTPuO_0
 fmR5JhThTQmg5YCV9dnvE3Sq6dQmbaYkRJnfTJpXEivP8zhg9.eKHVWC.yl0rALgPF.x5zxNEpNV
 ZvFg6J7CkGflEwSh2NP0_P2dOfIZ7cuGgLCYDj8xQGRBoU29Khf5ESFDBzGcJ4p1p7OFwyx7ojkA
 PsmQCToLTaooRrNp5o1c40emyU1ocQvK4LapGyquqVrx2NJJqbH.x6eXAoLWRU3sHgQhN4boGdsW
 556jcsLcTJwDV7YbRL0YE9BgliWU3ASKHRlvwsAIRQU8WqpzE0uLn2nQysjRoIzAoBQP0.amVjEi
 LpBOboocvC0N04PvlIVM_YuqTMuYXqbCsbteQg3C770c7qn4CQtG1MGX.2EQllrFApLWnTUHHKzf
 c816P3klb6_fza0VkyxN0pz535nlR6SljmIbJvs39WdlxeXu33DheSQ3jpVTSjA1CQTNpgp53UYu
 ttucC0pcYrd4BGmQhrmIxDi8ixEA4ef.pParHlpqjvodANiW6PCo1F8wVVUYJG4GwbEOQKlulkqw
 aAUAPdbdeSo4.S3BlWx4S1too3rt7jI34fz3IJomap91S5aawu0xsjw6AOtZSjPNGZVU7JRKw_KV
 uF8ipQXUBeKEP8a.ACwLAVWS.9E7ByVpHH01gYNfn0J6b0zyQmuQcCrv4S1rvJ7YHWzsUENl7f2G
 ZyQ2Btz50YGbiJPVTq_v4okS9XTvb416HG5DyWXRdDh3qwjHCeiLVoXaBzkwF2qAHnjU.btXZeAW
 HKf25C1fEa0lbQ76ZjSNmuh9BxxA5oNqtASzcmGCNmUSTbQ_btsnQLgMGFFTmb_z8mfD9S.YoX4p
 7U.X8MD3xZcoflOyPpYHKDQRn2EoBhGJbnKIUB_hYDXXP.0oZtVg.BkAFlH0le_ULGfZqqxhyMld
 h8hI7EGHckZIMIcQRRtFVdQ90LiXHJp7FGAwvnbIk0SFIffBbdwidj8cHeYweaxWpOYCquAGlqtU
 lS8HXQXHekpHXqEBmL7_1PEr6MAKtfN_3cDReDYbRXgSc4dNcovs7FOJ7pa9DKWlu8aD9UHa7B2T
 dCQEJFJQtzWVP9OXAMNZxSHdJgK7nHbqdvg7DeGW9qLX8f8GTvh72eMZ7o_OebIFgRc2bymhIN6r
 tC5wG1TWjyNRqmx2MecUOx7ZQFvrvhSVe5YpSuCit7o3xPTBhuBK.7j8zq08mCz6toqOF1BjZCT5
 ZXJAZtQMCcDGZOCZ07XMFfLzw6JGTfoxuIf5p.I9KenSVenU5_noqT69VEqbZYIx9.o9JfTlZRpc
 JYpZXS_06_qHpvFSepDmY98QdcnrkdYaQEYemcrHlNE6VNglGFWoWkjTHxuZbzYgC_kSyCCKn2QF
 b7b70WylFwdPdu0AP7n0PwlWrdQ0hWKfrGpN83H28DWjyacUZxyRLsH3HKIZ4CDmOaM763S3BVpL
 7iNBYGj7RxL.lGnUMSU7H4nKHU5zFeaTWzI0wG644G6klxJQlTCQr_3wrLGIqMdLPnIe2AJmbBjA
 .jc5IpxUnMp4PLFGX33dQ0jT2JekKJwtSnFVVvP5WYGKXa20JXfYMa1b22PgU8Nyr4Tp2QMTYiCD
 uJ6G8Ajw2xaPikxa1zyMY2qcRq6.0wrC6azaQMP5jSRqCI_XHddTz_2y_7jjHKE0BTZylzr1fuNa
 Wxrl5hxy7fXWDa1tdb0cwN3lzLJkk1A91SXMt9VoxVynapFvWFQf.fTmPPVtX6I1zAd0E4fKe00n
 9oJ90XG7Uk5VMAIhNNZ_wL4YEF6SkGIBcJaITFBnxc1IE7uSM4xxtjc7KYycAiDYGXm3wBnUEsHA
 zAKwtT8EZlAwjsPQ7KE1rY1ONXgqRF5j1_1rztnZbeY3td2M99svSb7KJfb4ZbUuByUpPJfbCFi5
 ngJHumXkUR9I_HODGVjibC4NAzcszgLhTTLzs57lA4wM0nUXb_XvSQuC75ieazfwpugMcFyM14MS
 Jeb.ne68eorPSTKOhFXmLOK8YEVk1YUcgiLBOPA9lFayVKLsOK7AFm1VOXtbmubzwj8ThlcaN3Od
 84S32ZUO9KgrzqTVVwiTPABNKITx_hkeXNikLWSrSYSpXCz1Xb6WGE9y7UQfD2jq8LqELDzOcrLx
 2CEw-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Oct 2022 21:03:17 +0000
Received: by hermes--production-bf1-585bd66ffc-hkqwj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d6d9675b6f7addf3bd4681610f1501fc;
          Sat, 15 Oct 2022 21:03:12 +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 \(3696.120.41.1.1\))
Subject: FYI: Example mountroot time boot-success (da0) vs. "shutdown -r now"
 mountroot time failure (pass0 for some reason)
Message-Id: <84A8686C-C7F3-4952-BF59-EAC0260D7403@yahoo.com>
Date: Sat, 15 Oct 2022 14:03:10 -0700
Cc: Hans Petter Selasky 
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <84A8686C-C7F3-4952-BF59-EAC0260D7403.ref@yahoo.com>
X-Rspamd-Queue-Id: 4MqbMC4jS9z3CqL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=YJsthsts;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.28 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.961];
	NEURAL_HAM_LONG(-0.82)[-0.817];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

In the below, look for da0 vs. pass0 :

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number S5K5NJ0R108412D
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2

vs.

pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
pass0: <  > Fixed Processor SCSI device
pass0: Serial Number S5K5NJ0R108412D
pass0: 40.000MB/s transfers
Mounting from ufs:/dev/gpt/BPIM3root failed with error 22; retrying for =
3 more seconds
Mounting from ufs:/dev/gpt/BPIM3root failed with error 22: Invalid =
fstype.

=46rom ---<>--- to the above show no differences
in the captured outputs, checked via a tool (BBEdit
on macOS). But I show more context below anyway.

Boot success:

---<>---
. . . (no differences) . . .
usbus1: 480Mbps High Speed USB v2.0
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmcsd0: 32GB  at mmc0 =
50.0MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 900MHz, Core 250MHz, SDRAM 450MHz, Turbo ON
Release APs
Trying to mount root from ufs:/dev/gpt/BPIM3root []...
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  =
on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1 CAM
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:5e:35:df
Root mount waiting for: CAM
Root mount waiting for: CAM
ugen1.4:  at usbus1
umass0 on uhub1
umass0:  on =
usbus1
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number S5K5NJ0R108412D
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2
. . .

"shutdown -r now" failure:

---<>---
. . . (no differences) . . .
usbus1: 480Mbps High Speed USB v2.0
ugen1.1:  at usbus1
uhub0 on usbus1
uhub0:  on usbus1
mmcsd0: 32GB  at mmc0 =
50.0MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 900MHz, Core 250MHz, SDRAM 450MHz, Turbo ON
Release APs
Trying to mount root from ufs:/dev/gpt/BPIM3root []...
uhub0: 1 port with 1 removable, self powered
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  =
on usbus1
uhub1: MTT enabled
Root mount waiting for: usbus1 CAM
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: Ethernet address: b8:27:eb:5e:35:df
Root mount waiting for: CAM
Root mount waiting for: CAM
ugen1.4:  at usbus1
umass0 on uhub1
umass0:  on =
usbus1
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
pass0: <  > Fixed Processor SCSI device
pass0: Serial Number S5K5NJ0R108412D
pass0: 40.000MB/s transfers
Mounting from ufs:/dev/gpt/BPIM3root failed with error 22; retrying for =
3 more seconds
Mounting from ufs:/dev/gpt/BPIM3root failed with error 22: Invalid =
fstype.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/gpt/BPIM3root

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> ?

=20
FYI for the example, output line split for readability:

# uname -apKU
FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #49
main-n258610-ba7319e9091b-dirty: Fri Oct 14 18:27:46 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a=
rmv7/sys/GENERIC-NODBG-CA7
arm armv7 1400072 1400072

Notes:

Technically, I strip an escape sequence that occurs a lot in
one chunk of the captured text and strip carriage returns as
well, to make the captures more readable before doing the
comparison. The captures span back into the RPi* firmware
output, not just the FreeBSD output.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct 16 07:00:01 2022
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 4Mqrbw4Zd0z4fY55
	for ; Sun, 16 Oct 2022 07:00:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.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 4Mqrbv6KWZz3xZk
	for ; Sun, 16 Oct 2022 07:00:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665903609; bh=G9FPilgDSezbSyj8Yootn4jEO7PnyJaW6vx1M3pCcyA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=MeMEXgsmQG9GrK6D65vFYxXTO3tvn4/ukOX4U4gwzJrj5fTLmicGYaxjKPxDxf9+l/bfFdw+7coqPN4/wBuGgRx4aqsOzaBgXcD9P4qCZ7YZPL1b+LVRHRv0ARicNfrUZgcM8yWb8WEntBmEdOQCZnI6FNnID8UhIr7+wDIhhXw6K1HAJ2cTtZZhYjqL3rFMJmsJHarWANJPrLTgqhapVu2SLXbVJR1OqV5UrQYwo/uA/pHUhjBy7IyHGSLCNN1R32j0BaBOvxneamUPbZo5lT7skrws484hD2wUWHauMC/Npab8eU/nEemfuuORHgAAahv2P012x3FgTd27NqrAEQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665903609; bh=yFh7xgIJwV6ZTOJCZ9w1FG413gFL8Tfvw5CfZJo0a8v=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=WgecToXRBM8whDNRdYSCMTzYl0BziCJrnkQccKpd6ln35svrkVyDk/pAQ1sHSMFsQhncTAnISpLLYJpi53FYOiELwWYiiOJFlO17ic89ku+Iwe3xc5Y7Rz8UqaJa20JenL34SGFxHOQPIdKhIXplGsjrjOSwfEEgkj6QFuuKgnXj8aYHc17Elwzkmhzlsrl8GUCsyQ3rKtYNm/HR2UYotglWXyTly+/RCKdhI3o+HdDxp/wBodeD4FCMuq9dxeWv8H98TxCLBQa8C0oHURkDZE520Y+USP/llP5jammZm0x7AMATJup1fJS0ybsjv98IWk9AiSnICuV+P2rdUY4+eg==
X-YMail-OSG: 4.dHzBgVM1nEpKIy_JBBbM.o1tS8IaI5LOvQpTLjbBkazbRBsol9wP8G1gv1Rl2
 sabSzaNpgohZVIlKzkIboDtk1yhthUGlvg4tVetqsWiN5dJyT4RhyI13ausi6TOPgX8LLWKUdpNO
 oi7ocF.CfSwiOk25RcKdg8cUzphVYQFIxA73fRXolwtHTFtO_RimFc16O2u5x7c105spzkggebhm
 JWP3CGjaosqaX_xOrSTh1YoRbUg28rbnV0XmBwl0HULCyA4dkD9_Gr1rnoWtWLYWN.t67SJ_vZNq
 1FDIn5N8KtiQDfdeunXGrilLmDJi2kp9hHJCzWLdDtJeN4CGOoQ.8VA9APp8QwwqtzGU1rXBcyiY
 lyayecyIQm9tr6rr0q7OayV1m3peY_Dd.OzfDy9JOYlvQNnggzuQ4vyytUsd9LjoXIudplbar1C_
 LoAjlP_GWZuukD5S2OEychqAFBytdpmqMs.4LL821JQQjzY7YkTcnn.U.O7jVEqIn8SXLMXvbwNB
 .7gPNpIN6qgfkfRbbCvW5LwW5l5bGrtixdpEF5JsQ3Ev73v_hcgL5IJbTSvGkBejgAxcic3CBsCr
 ug22LCODqvX0J2aO4dHI11kHsy80mVd9S9FW5kJjv3zm_vT_HXJ_7InbKz2ufZmgyhm.JO2onUcb
 UwZUH9EPXw8psWbiQrOak_6IVTLI7eH_0ha2Bl61vsG.ZPrnePVkTY2ww4qhz5jnrgxcrzk7y3wG
 Mgb_7gZ2UOCD4tH6Zy_SNEwiOZP25eQZcp_t__D4zEL.4nCALw6USE7Ck.oUR4hlN4PpsuPJWXpy
 jheLSW2XJcWPUB2bX.NvPDRxgZKP09b4fn0KaY8sscLANdkG6DYA76ieaCD4qgHOZyY2nWtaWj_w
 JBnkhlIAEh2KGufxeOsirJ2Phw2wa9kZKvcG3i0lcAlylkPX9apcRPJUryO4jdcdsg6zYffyPV7U
 i.kTDDcA0WWZ9V6ey6v_vWIiUz2ES.0GrrjYKaMuluj2Fi3RK9uMyw0PgpNh67UpQVCcUXAabbbE
 xpbDKgK3wgkEY84ttkjrMDcrSOzb9ToDL.Y3Kv5EzSWW9ZrTcdVgNmWLPz64iAw8xILrr50Pmjh.
 JEOiCnLRJ3mPapCn9oH6pCxxpVWfIekWnzq04.OTip1dsjcUULLaIygM2WbgLG8h6Fu.cIgLE07a
 CNYl0_JFgc7qGURXzk573Zno0bSUciK778W4ffWqeHYO.Hc_tC5pXZ5374VYt8aesftb6yJIVnLC
 KZyQ8t7uzW6EzJVJgFBia7yg_W51XKaUi6hDnTgLvTouVoKqyB_Inv6PGLfQB6Ry7iIoZN31Cwou
 Oqccrfh9OMOjeY3bHjKnU6oAfs4r9eG1FXfPV2CGxwxHjX.qII4v381m13zsfWzGPQ2ggRU10ILu
 qX1wNZPuSt7g98rC8C.vwcFH0np6.eW4moNZB1hWsMziWRg7lnS5jLIvy6JC1DTXQheTcKZKtvpa
 bX8fzGtuXImhG4TDKEzR4bcQbl9Bk1H2IPzE3B9RBnBgUaTXQHtpZW3cX1cU4OeZMZnYhkBoqzU8
 PytlQuBGIURHYxg9BxZZ2TTQHIrQ9lZdSDBX7tdl1taCzYk2vHqvhEkmibVAeHiAgrAb52DQ0oBs
 sheIXQKlaUPe6S0xoFQ3lj4sAvTxvVK5BjYr0wQ4u8nCLbjkR4rDxkkF57j86XEjfBi.P.dIH0fB
 kov7PL65cVRpgWPVOAPTUEg0Q8ulubxz3lOSk6ba9AwQ1AF7dCsKh4yVMRZzbcd49zI_6X4kdjRP
 jHcutaYZ1t9VnhWxlruHXeLpveliLQALlkHr0iwGRtb8aY6errvljM2toA51OPjj7BxlEOI1XBsw
 CJAmoGBn2FDGaLvN9YfBM0aWzuiK2pCI7NEpci9VKqCBmPky1hQGNJbW.vZemNWvRvQJ5e9l3gsF
 92E0VMXJvPsPpIQI7PtTtcMEirhrzXzVONFsqWn3NOsAdASe7rlySxAQbDdWrFc8UDZ9A_92XBnO
 HB958ZA54g81veCvUfJipRW4kwjnBot3qgMEg_fzRB2JofSoYzHbvEzIaIDLd1.TQrxYJtgoN0.7
 _w7N60N1MTWL5SgSBILldrJCzSv.ij8JDNJs5z8XFxCg.Q5ycwqX2MQZf5GeRtyepDHKc2BFgc5v
 sY_O4pJ4BOkFtZJgPJQouVhUhrcoFL0Xs1x2XNbVOzEOx2eQ8Es4c.YuvUFK5sU6GaqN_RVMkZql
 nTnZmdxAMf7kNyF28HO1kBwptT4274PgWTXXnsDkf_9wKNC.fO4rDIM2ZtI37
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Oct 2022 07:00:09 +0000
Received: by hermes--production-bf1-585bd66ffc-lv69x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a705bd18b24ad133cabe2aaf85d704d9;
          Sun, 16 Oct 2022 07:00:03 +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 \(3696.120.41.1.1\))
Subject: FYI: Rock64 USB3 port no longer works for main [so: 14]
Message-Id: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
Date: Sun, 16 Oct 2022 00:00:01 -0700
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Mqrbv6KWZz3xZk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MeMEXgsm;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.45 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.96)[-0.956];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Unfortunately, last I recorded the Rock64 console output
goes back to 2022-Apr --for an even older system build:

main-n252475-e76c0108990b-dirty

(a 2022-Jan-16 commit). The build with the observed USB3
problem is (the USB3 NVMe SSD booted on a RPi3B instead):

# uname -apKU
FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #46 =
main-n258610-ba7319e9091b-dirty: Fri Oct 14 16:35:36 PDT 2022     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400072 1400072

Note that some differences in boot-text reported below may
well be expected text. I do not have the context to evaluate
most text for good vs. bad. The differences avoid reporting
identical text and irrelevant minor variations.

Newer, failing context:

snps_dwc3_fdt0:  mem 0xff600000-0xff6fffff irq =
58 on rk_dwc30
snps_dwc3_fdt0: 64 bytes context size, 32-bit DMA
usbus4: trying to attach
usbus4 on snps_dwc3_fdt0

Older, working context:

xhci0:  mem 0xff600000-0xff6fffff irq 58 on =
rk_dwc30
xhci0: 64 bytes context size, 32-bit DMA
usbus4: trying to attach
usbus4 on xhci0

Later, a block that is the same for both:

ugen4.1:  at usbus4
uhub3 on usbus4
uhub3:  on =
usbus4


Later, a block only in the older working context:

Root mount waiting for: usbus4 CAM
ugen4.2:  at usbus4
umass0 on uhub3
umass0:  on =
usbus4
umass0:  SCSI over Bulk-Only; quirks =3D 0x0000
umass0:0:0: Attached to scbus0

Then both got:

Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM

But the failure then got:

Root mount waiting for: CAM
Root mount waiting for: CAM
Mounting from ufs:/dev/gpt/Rock64root failed with error 22; retrying for =
3 more seconds
Mounting from ufs:/dev/gpt/Rock64root failed with error 22: Invalid =
fstype.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/gpt/Rock64root

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot>=20


Booting from USB2 instead and later plugging a USB3 device
into the USB3 port gives no indication of activity (via the
activity light on the USB3 device).


With this, I have stopped maintaining an environment for the
Rock64. I will not be pursuing the above issue.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct 16 21:01:04 2022
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 4MrCG91qnVz4g4XT
	for ; Sun, 16 Oct 2022 21:01:05 +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 4MrCG86B8gz3QLj
	for ; Sun, 16 Oct 2022 21:01:04 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MrCG85Hqxzb4Q
	for ; Sun, 16 Oct 2022 21:01:04 +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 29GL14m5079730
	for ; Sun, 16 Oct 2022 21:01:04 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29GL14ai079729
	for freebsd-arm@FreeBSD.org; Sun, 16 Oct 2022 21:01:04 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202210162101.29GL14ai079729@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, 16 Oct 2022 21:01:04 +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="16659540645.A7e0AF.73213"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1665954064;
	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=26zkTQAMRDEzKPG1JW4X4+MDO5xhVpBuRnssZpjIIHU=;
	b=Q2eb3cmfQHCs5cme32q+y3YW7wzE2iMfV/fu9oMJureMSI8ds3Wa4mO8rEXtFN4K1g6wB9
	xtMkLXe0QO/ycYU/589QGENLvEovdb5nx8Pcov/IpmkMw5jett48qG0p4fCfGtu+2Y3TU9
	zdTDqIeM3hP66dlWEzESGJBpHNKZrs9PE94B7OJD4XGYPA82mAF3CuMT7m94n+oTUrFWGP
	fophbd5O9L/YO9MPm3DhgPVuyO9c4RBUKrj2BnC49LU2RXwQsex2sN0XlhUynN6ivUu2fZ
	a8B5t0So4uMCsvOID0BlfbfDwAd2wjDEz2/QDfPAmNCXAGamhSwJ3X/a96wJQA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665954064; a=rsa-sha256; cv=none;
	b=k98GO4ush4EEhMOTVhfOMGF7/YKgrsWSI5GauKrsEi2xrxgrkQuGGw7w6lrMHGR3ZhQfVW
	1amlsbgsdoWS8dMf4BYxH0DojNmaMmjMfLFw/RX+xLoicXU4EtiRcT27SN41AQeOXTApXL
	RGNWGCPkNTqVO6Kbidjden7ipl1ueHjBw8G47HuQ4OX4xhaksArXRgQXI6jLYUZmn9J+UX
	CmfC5uJueXMOqzR4pi54HviJmHiVMjdjWYtjCFz1IZlvFTF7vAjWiI94dKv7AoAcptHQGZ
	rFbQ/ygzGH42CUH+wduWG3Hi4B6G9dX0WFwufRaCPbobQsb6CjRloP0fhEZQ0Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16659540645.A7e0AF.73213
Date: Sun, 16 Oct 2022 21:01:04 +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.

--16659540645.A7e0AF.73213
Date: Sun, 16 Oct 2022 21:01:04 +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.


--16659540645.A7e0AF.73213--

From nobody Mon Oct 17 12:29:25 2022
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 4MrbsS3g6Sz4fmQL
	for ; Mon, 17 Oct 2022 12:29:32 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f])
	(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 4MrbsR6ZBrz45nQ
	for ; Mon, 17 Oct 2022 12:29:31 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: by mail-wm1-x32f.google.com with SMTP id n16-20020a05600c4f9000b003c17bf8ddecso9317365wmq.0
        for ; Mon, 17 Oct 2022 05:29:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=L/AyLgS13rrdcX0Gx1cV8CHtxfsoYW3YTWA/x+daLPw=;
        b=LXCzmJaWMQn6iBKNPuUefCliHFA+FilYU2TtvEjwaHTgIczlTNN2i1Y6kELxus3wYz
         pbdDXknkCq/G8NhVE9AoH4KWnTJLhYpNRGLyOe0Vjgib+FoFu10Q5QIEb902c3HXSwdv
         sZ9xvwTPzQm6ycfvAukNEF/8WZ9PUsZEiJBu6+ApGjMi2t9bLvQ/VLncYmh1vn/i/lpY
         b7AsCd8ZwHEEzwrPeowUXcFdFzMavS3UrxqA2+SOEQjZiG6F+B820Doj4KB5mykL+qE+
         HD/g5k1SAj+YcyR83OY8Mr5+mJbeTuZM8uYSy0oJJ6RJD0bXKF0GZxvvs4EfF3qwp8eB
         bing==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=L/AyLgS13rrdcX0Gx1cV8CHtxfsoYW3YTWA/x+daLPw=;
        b=etGuTZ7s/fqA+P14lQIUyi5eOF2bwuRr/vwHx4qPyu8kAzEazzBxMdnglYf3QjWJhr
         ipz2pd5Y9Q7cArz5t/B0LdFhEfj4CW4skb5R7Lvy/YOX7vk9OsjBKsXHEvaWq5IsqFQh
         KLZ8tHr+f6pR1iPiDkFaAH6W/KabxYV5EplVKlUS3kiAfqGFzd2QVPDAa6fyyzcMe7wf
         SeHr579cdK7VvGjyKVYU9lqyM6mLe7XvN0ncNqhDmoNbAVjhBBXv4wJdn+cQCI1plfYC
         1HGdqddAU7AJB8lBvXqGy84KnT9pusmpTaxy/x2mcnY/yrvQb7Pa6znDxkxSz84J4+LN
         BBCg==
X-Gm-Message-State: ACrzQf0a8VTNCgqDXdf/nJJ/tocP24gfBLPRwPX991RqJ5Y15QrQ4dzx
	besQApeceOIhOjJDwm6J70W75/uhgJE=
X-Google-Smtp-Source: AMsMyM7kzQn0NqH7p1oFX4g/PdwpakWabwgLrXkQZBRyBrd6KNzJHmHO0eH1ys4x9krWUgh0xBFrCA==
X-Received: by 2002:a05:600c:1e8b:b0:3c6:f6e5:c41d with SMTP id be11-20020a05600c1e8b00b003c6f6e5c41dmr3801358wmb.12.1666009770532;
        Mon, 17 Oct 2022 05:29:30 -0700 (PDT)
Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181])
        by smtp.gmail.com with ESMTPSA id n17-20020a05600c465100b003c65c9a36dfsm9671605wmo.48.2022.10.17.05.29.27
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 17 Oct 2022 05:29:28 -0700 (PDT)
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 14.0 \(3654.120.0.1.13\))
Subject: Re: sound on raspberry pi 4
From: Marco Devesas Campos 
In-Reply-To: <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
Date: Mon, 17 Oct 2022 13:29:25 +0100
Cc: Ronald Klop 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
To: Hans Petter Selasky ,
 Warner Losh ,
 freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MrbsR6ZBrz45nQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=LXCzmJaW;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of devesas.campos@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=devesas.campos@gmail.com
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)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Peeps,

Have yet to receive any comments =E2=80=94 let alone reviews =E2=80=94 =
on

	https://reviews.freebsd.org/D36431

The patch adds sound, and accel video support to 64bit pi-s;
it implements 32 bit compat; and fixes system stalls in the
existing code. Useful stuff, methinks, and a few people
on this list have atested to that.

So, please, anyone? Any =E2=80=94 any! =E2=80=94 feedback appreciated.

Marco


> On 3 Sep 2022, at 12:06, Marco Devesas Campos =
 wrote:
>=20
>>>=20
>>> On 9/1/22 10:27, Ronald Klop wrote:
>>>> On 9/1/22 10:02, Hans Petter Selasky wrote:
>>>>>=20
>>>>> Can you upload your patch to:
>>>>>=20
>>>>> reviews.freebsd.org - differential revision ?
>>>>>=20
>>>>>=20
>>>>> =E2=80=94HPS
>>>>=20
>=20
> Differential revision created
>=20
> https://reviews.freebsd.org/D36431
>=20
> with HPS and Warner (since he showed interest in the patch initially) =
as reviewers.=20
>=20
> Keen to hear from anyone who might be interested in the patch.
>=20
> Best,
> Marco
>=20
>=20
>=20


From nobody Mon Oct 17 12:50:49 2022
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 4MrcLn2CRBz4ftKp
	for ; Mon, 17 Oct 2022 12:51:29 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4MrcLm4lmCz3wjp
	for ; Mon, 17 Oct 2022 12:51:28 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: by mail-ej1-x634.google.com with SMTP id bj12so24592941ejb.13
        for ; Mon, 17 Oct 2022 05:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=sP4sDQP7weccSZ0OQ3oUZxjIutb03gEF5VFBN6iyJBs=;
        b=RV6TLHhyEWJDPbKOyiOBwoFv7p9E+SHDbDEVheOxAFcCjyKCSJKZhMG1gE/qvX+/J4
         g+UMvfUZIVmMbhVh7vICgF1fj4wH3D46oz9LGp5uuMmT4PjXkjc4A6ya+hWpwiCtKWwg
         TMXt5PlFeZxA99JizPCYEZNGLM/mCdDW0yjq9T0NZB15Zqb1VIyRvPA57/VYe/4vTwIj
         KAvPuRzviGH70fxW3VZWTn6qGJ3ohBdTdpqfFmTC2Ei435yxOOi0KdgFBiVF+iD57DBv
         6XYH2K0uhpGx+86V++NQU2VCTPG2pToB9D2FRowDD5/Ul9BBRQ5pYaKyYHLj9irHOJaZ
         1PgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=sP4sDQP7weccSZ0OQ3oUZxjIutb03gEF5VFBN6iyJBs=;
        b=Pta9T3RZBGQ4So9PBKLPfz8dTN+qwigyIKAFj5TqRzv2lTiZh+P72eLdmoDYi1sVfn
         KQ/5QhOqq8OcOV3y/XzjowfXiqO3ZttLSb30oT4xmyrEGRT1yYE8gbkx8zihJVUiXRcL
         yzle3gFqlWoI4AxRMFd0hLZeCQY87mIlU5rcRRbRnjic7dLOwR2nWCiFyDDBBCzSDbl0
         2suJFoRJSn4Erptad8fdkHLaQSjT36jkdypMVnKFN5xAmuBiJcybzaSSsmmKQK4cP2yR
         ylsTzcncdJL3mPK98VJOXQKSwi23ET6vF4BqAwlXZaK2a7FYZtiSsPwqNfmeBcDkcYfq
         AmZA==
X-Gm-Message-State: ACrzQf2OTNzahYzn0JX7aIWk/2svMctb7iVWO6zAgZoZZYBjH5iuoLT1
	3ZlKsbzravjxhznGGydIsIVHVbDoisO0o89wMdvzf65m9Kk8dg==
X-Google-Smtp-Source: AMsMyM7h4ZuQ7PKiiwjuqlMGTFVTIMMqN6hvxeO0DtrJt1Rz8SQB55Swi5iSkru7zYBu9454Rhx42FLlVTolJjrbNXk=
X-Received: by 2002:a17:906:fc6:b0:72f:d080:416 with SMTP id
 c6-20020a1709060fc600b0072fd0800416mr8628480ejk.1.1666011086947; Mon, 17 Oct
 2022 05:51:26 -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:  
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org> 
  <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com> 
In-Reply-To: 
From: Odhiambo Washington 
Date: Mon, 17 Oct 2022 15:50:49 +0300
Message-ID: 
Subject: Re: sound on raspberry pi 4
To: Marco Devesas Campos 
Cc: Hans Petter Selasky , Warner Losh , freebsd-arm@freebsd.org, 
	Ronald Klop 
Content-Type: multipart/alternative; boundary="00000000000007b50b05eb3a6f8d"
X-Rspamd-Queue-Id: 4MrcLm4lmCz3wjp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=RV6TLHhy;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of odhiambo@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=odhiambo@gmail.com
X-Spamd-Result: default: False [-2.48 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_FIVE(0.00)[5];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FREEMAIL_TO(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_DN_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000007b50b05eb3a6f8d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos <
devesas.campos@gmail.com> wrote:

> Peeps,
>
> Have yet to receive any comments =E2=80=94 let alone reviews =E2=80=94 on
>
>         https://reviews.freebsd.org/D36431
>
> The patch adds sound, and accel video support to 64bit pi-s;
> it implements 32 bit compat; and fixes system stalls in the
> existing code. Useful stuff, methinks, and a few people
> on this list have atested to that.
>
> So, please, anyone? Any =E2=80=94 any! =E2=80=94 feedback appreciated.
>
> Marco
>
>
Just curious. How do I test this?
I have a Pi3B+ which I have always wanted to run FreeBSD on, but then
getting FreeBSD Desktop is so much pain.
How would I test accel video and sound on a Pi without getting stressed
out? :-)

--=20
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-)

--00000000000007b50b05eb3a6f8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 17, 2022 at 3:29 PM Marco=
 Devesas Campos <devesas.cam=
pos@gmail.com> wrote:
Peeps,



Have yet to receive any comments =E2=80=94 let alone reviews =E2=80=94 on


=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://reviews.freebsd.org/D36431=




The patch adds sound, and accel video support to 64bit pi-s;

it implements 32 bit compat; and fixes system stalls in the

existing code. Useful stuff, methinks, and a few people

on this list have atested to that.



So, please, anyone? Any =E2=80=94 any! =E2=80=94 feedback appreciated.



Marco



Just curious. How do I tes=
t this?
I have a Pi3B+ which I have always wanted to run FreeBSD on, bu=
t then getting FreeBSD Desktop is so much pain.
How would I test =
accel video and sound on a Pi without getting stressed out? :-)

-- 
Best regards,
Odhiambo WASHINGTON,Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."=
;,=C2=A0egrep -v '^$|^.*#'=
=C2=A0=C2=AF\_(=E3=83=84)_/=C2=AF=C2=A0:-)


--00000000000007b50b05eb3a6f8d--

From nobody Mon Oct 17 13:16:32 2022
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 4Mrcwd0qVHz4fxLq
	for ; Mon, 17 Oct 2022 13:17:21 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [IPv6:2001:4b98:dc4:8::231])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrcwb6KlYz42ss
	for ; Mon, 17 Oct 2022 13:17:19 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: (Authenticated sender: valery@vslash.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 4E7FB10000A;
	Mon, 17 Oct 2022 13:17:12 +0000 (UTC)
Message-ID: 
Date: Mon, 17 Oct 2022 15:16:32 +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:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: sound on raspberry pi 4
Content-Language: en-US
To: Odhiambo Washington ,
 Marco Devesas Campos 
Cc: Hans Petter Selasky , Warner Losh ,
 freebsd-arm@freebsd.org, Ronald Klop 
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
 
 
From: Valery Seys 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mrcwb6KlYz42ss
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of valery@vslash.com designates 2001:4b98:dc4:8::231 as permitted sender) smtp.mailfrom=valery@vslash.com
X-Spamd-Result: default: False [-1.90 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::231:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[vslash.com];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Perhaps just look at the subject : "sound on raspberry pi 4", which is not a 
Pi3B+ I think,

BR,

VS


On 17/10/2022 14:50, Odhiambo Washington wrote:
> 
> 
> On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos  > wrote:
> 
>     Peeps,
> 
>     Have yet to receive any comments — let alone reviews — on
> 
>     https://reviews.freebsd.org/D36431 
> 
>     The patch adds sound, and accel video support to 64bit pi-s;
>     it implements 32 bit compat; and fixes system stalls in the
>     existing code. Useful stuff, methinks, and a few people
>     on this list have atested to that.
> 
>     So, please, anyone? Any — any! — feedback appreciated.
> 
>     Marco
> 
> 
> Just curious. How do I test this?
> I have a Pi3B+ which I have always wanted to run FreeBSD on, but then getting 
> FreeBSD Desktop is so much pain.
> How would I test accel video and sound on a Pi without getting stressed out? :-)
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

From nobody Mon Oct 17 13:24:53 2022
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 4Mrd6472c6z4fxyH
	for ; Mon, 17 Oct 2022 13:25:32 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4Mrd6405t5z441Y
	for ; Mon, 17 Oct 2022 13:25:32 +0000 (UTC)
	(envelope-from odhiambo@gmail.com)
Received: by mail-ej1-x634.google.com with SMTP id bj12so24823329ejb.13
        for ; Mon, 17 Oct 2022 06:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E2EKshbTChTtoxI+0PriaaBcpBQejj9ay1lUOrs67YM=;
        b=QJKb2xse0ZR3tY+0cv3QTJCSS42WTqzYtTLmL4gGS7vrf9daArIVdWzVsWTLrLGBpM
         LWKPbBSx6H/qzZblONOIZRZ7d6W/8zpw6iUfM6CMpbvw5ZbmRJFJUyvySc2w1PtIVZMe
         O6WmQ/QPGkCb/alHbLb1a5yFAOa0tFP10Mz63/easwW+qeKIAZU4GfG6XWiFBNrlLGtl
         VU1CTcpKR0cUeKCh/NAEz7XvnifvNoASA5iwAgoI9sfcW/f/ey6WJKe8AP1QypFWzCwZ
         hqNZA+b8f77OXvfCL0pUDZp1marKjr+9i+5P26qWjVBPhE0g05ElKs3IHuSp2RuKNL4w
         26wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=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=E2EKshbTChTtoxI+0PriaaBcpBQejj9ay1lUOrs67YM=;
        b=af8BrC980AAXhPRy6AuzRLY1MdqDHGkae2H5kxlGgL3KjUt0TRkrAJ+Wbj8z573gcq
         kVf/jbvU/K96B4v0O/8Laf2o6wbkMePOcSyW4gwBUY1KBfpHvZEKZ8KghoKoM4iS3iOU
         Az7M9vrc9Rt3DkJqCTskY3b8eyfO5YyPPRxLMsoqUA415pl3XTCqzu3hoEtsjUvdfcNU
         r1hMuI6he5pHaWZH8LBJ3zRiYcNpAX0Wy4W9RgdzOkH4H8JqyPde8U4iXrYmA1pUQFXm
         TcQnOGZ0Ep3KkkLvO0eAzvnz5POrIlwLwtZmYMRYdA0Z8gaMLwH22OtMRMBt9OnlB2OI
         /W+w==
X-Gm-Message-State: ACrzQf2eZAgIEd850kyoKmWNHgWEGmxP1ztlPM2LLTjCvQd5EHFBTASx
	0j2LKO94N/mxoX8Ylqm+LnpUTD5ZXmeVhLEfyYX0CuTfJrWNWw==
X-Google-Smtp-Source: AMsMyM6pFoZ8kTqGDrdwiq7Bi9CzIKus3ByOEuXinOxxJwYt8hSYgjErNVI1N7SFwNhB+OrUbyG5ZtbKQHgxsQ9Aj1w=
X-Received: by 2002:a17:906:fc6:b0:72f:d080:416 with SMTP id
 c6-20020a1709060fc600b0072fd0800416mr8753696ejk.1.1666013130167; Mon, 17 Oct
 2022 06:25:30 -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:  
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org> 
  <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com> 
  
In-Reply-To: 
From: Odhiambo Washington 
Date: Mon, 17 Oct 2022 16:24:53 +0300
Message-ID: 
Subject: Re: sound on raspberry pi 4
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d09cf005eb3ae82d"
X-Rspamd-Queue-Id: 4Mrd6405t5z441Y
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=QJKb2xse;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of odhiambo@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=odhiambo@gmail.com
X-Spamd-Result: default: False [-2.99 / 15.00];
	URI_COUNT_ODD(1.00)[7];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d09cf005eb3ae82d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oops!

But still, I thought that the same OS is used for Pi3B+, no?


On Mon, Oct 17, 2022 at 4:17 PM Valery Seys  wrote:

> Perhaps just look at the subject : "sound on raspberry pi 4", which is no=
t
> a
> Pi3B+ I think,
>
> BR,
>
> VS
>
>
> On 17/10/2022 14:50, Odhiambo Washington wrote:
> >
> >
> > On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos <
> devesas.campos@gmail.com
> > > wrote:
> >
> >     Peeps,
> >
> >     Have yet to receive any comments =E2=80=94 let alone reviews =E2=80=
=94 on
> >
> >     https://reviews.freebsd.org/D36431 <
> https://reviews.freebsd.org/D36431>
> >
> >     The patch adds sound, and accel video support to 64bit pi-s;
> >     it implements 32 bit compat; and fixes system stalls in the
> >     existing code. Useful stuff, methinks, and a few people
> >     on this list have atested to that.
> >
> >     So, please, anyone? Any =E2=80=94 any! =E2=80=94 feedback appreciat=
ed.
> >
> >     Marco
> >
> >
> > Just curious. How do I test this?
> > I have a Pi3B+ which I have always wanted to run FreeBSD on, but then
> getting
> > FreeBSD Desktop is so much pain.
> > How would I test accel video and sound on a Pi without getting stressed
> out? :-)
> >
> > --
> > Best regards,
> > Odhiambo WASHINGTON,
> > Nairobi,KE
> > +254 7 3200 0004/+254 7 2274 3223
> > "Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-)
>


--=20
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-)

--000000000000d09cf005eb3ae82d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Oops!

But still, I thought t=
hat the same OS is used for Pi3B+, no?


On Mon, Oct 17, 2022=
 at 4:17 PM Valery Seys <valery@vsl=
ash.com> wrote:
Perhaps just look at the subject : "sound on raspberry pi 4&quo=
t;, which is not a 

Pi3B+ I think,



BR,



VS





On 17/10/2022 14:50, Odhiambo Washington wrote:

> 

> 

> On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos <devesas.campos@gmail.com 

> <mailto:devesas.campos@gmail.com>> wrote:

> 

>=C2=A0 =C2=A0 =C2=A0Peeps,

> 

>=C2=A0 =C2=A0 =C2=A0Have yet to receive any comments =E2=80=94 let alon=
e reviews =E2=80=94 on

> 

>=C2=A0 =C2=A0 =C2=A0https://reviews.freebsd.org/D36431 &l=
t;https://reviews.freebsd.org/D36431>

> 

>=C2=A0 =C2=A0 =C2=A0The patch adds sound, and accel video support to 64=
bit pi-s;

>=C2=A0 =C2=A0 =C2=A0it implements 32 bit compat; and fixes system stall=
s in the

>=C2=A0 =C2=A0 =C2=A0existing code. Useful stuff, methinks, and a few pe=
ople

>=C2=A0 =C2=A0 =C2=A0on this list have atested to that.

> 

>=C2=A0 =C2=A0 =C2=A0So, please, anyone? Any =E2=80=94 any! =E2=80=94 fe=
edback appreciated.

> 

>=C2=A0 =C2=A0 =C2=A0Marco

> 

> 

> Just curious. How do I test this?

> I have a Pi3B+ which I have always wanted to run FreeBSD on, but then =
getting 

> FreeBSD Desktop is so much pain.

> How would I test accel video and sound on a Pi without getting stresse=
d out? :-)

> 

> -- 

> Best regards,

> Odhiambo WASHINGTON,

> Nairobi,KE

> +254 7 3200 0004/+254 7 2274 3223

> "Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=
=84)_/=C2=AF=C2=A0:-)




-- 
Best rega=
rds,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 =
3223
"Oh, the cruft.",=C2=A0egrep -v '^$|^.*#'=C2=A0=C2=AF\_(=E3=
=83=84)_/=C2=AF=C2=A0:-)


--000000000000d09cf005eb3ae82d--

From nobody Mon Oct 17 14:11:14 2022
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 4Mrf7J5nblz4g3P5
	for ; Mon, 17 Oct 2022 14:11:40 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrf7H68Rdz3DYR
	for ; Mon, 17 Oct 2022 14:11:39 +0000 (UTC)
	(envelope-from valery@vslash.com)
Received: (Authenticated sender: valery@vslash.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 3C9D7FF80B;
	Mon, 17 Oct 2022 14:11:36 +0000 (UTC)
Message-ID: 
Date: Mon, 17 Oct 2022 16:11:14 +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:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: sound on raspberry pi 4
Content-Language: en-US
To: Odhiambo Washington , freebsd-arm@freebsd.org
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
 
 
 
 
From: Valery Seys 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mrf7H68Rdz3DYR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of valery@vslash.com designates 2001:4b98:dc4:8::229 as permitted sender) smtp.mailfrom=valery@vslash.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64:c];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::229:from];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[vslash.com];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

* Raspberry Pi 4:
     Broadcom BCM2711, Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz

     From what I found on the net:
	A: The Pi4 still uses a PWM sound output similar to previous models. 
Therefore, don’t expect high quality sound from the onboard sound. A HiFiBerry 
sound card is still the right choice for optimal sound quality.


* Raspberry Pi 3B+:
     Broadcom BCM2837B0, Quad-core Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz

	https://forums.freebsd.org/threads/rpi-3b-sound-and-wifi.69297/
	Sound: sdio
	https://reviews.freebsd.org/D12467


Q: could you run MacOS-X.0 on an MacBookPro 2022 ? Still the same OS ...
A: ;o)

Do you need sound on a Rpi or any other SFF board ? Get a simple external USB 
sound system, really the better and easiest choice I think,

BR

V/



On 17/10/2022 15:24, Odhiambo Washington wrote:
> Oops!
> 
> But still, I thought that the same OS is used for Pi3B+, no?
> 
> 
> On Mon, Oct 17, 2022 at 4:17 PM Valery Seys  > wrote:
> 
>     Perhaps just look at the subject : "sound on raspberry pi 4", which is not a
>     Pi3B+ I think,
> 
>     BR,
> 
>     VS
> 
> 
>     On 17/10/2022 14:50, Odhiambo Washington wrote:
>      >
>      >
>      > On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos
>     
>      > >> wrote:
>      >
>      >     Peeps,
>      >
>      >     Have yet to receive any comments — let alone reviews — on
>      >
>      > https://reviews.freebsd.org/D36431 
>     >
>      >
>      >     The patch adds sound, and accel video support to 64bit pi-s;
>      >     it implements 32 bit compat; and fixes system stalls in the
>      >     existing code. Useful stuff, methinks, and a few people
>      >     on this list have atested to that.
>      >
>      >     So, please, anyone? Any — any! — feedback appreciated.
>      >
>      >     Marco
>      >
>      >
>      > Just curious. How do I test this?
>      > I have a Pi3B+ which I have always wanted to run FreeBSD on, but then
>     getting
>      > FreeBSD Desktop is so much pain.
>      > How would I test accel video and sound on a Pi without getting stressed
>     out? :-)
>      >
>      > --
>      > Best regards,
>      > Odhiambo WASHINGTON,
>      > Nairobi,KE
>      > +254 7 3200 0004/+254 7 2274 3223
>      > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
> 
> 
> 
> -- 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

From nobody Mon Oct 17 15:38:17 2022
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 4Mrh3L5tTqz4gDMm
	for ; Mon, 17 Oct 2022 15:38:22 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Mrh3K6s6Jz3Mxm
	for ; Mon, 17 Oct 2022 15:38:21 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.west.internal (Postfix) with ESMTP id 60D3B32001E9
	for ; Mon, 17 Oct 2022 11:38:20 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute4.internal (MEProxy); Mon, 17 Oct 2022 11:38:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm3; t=1666021099; x=1666107499; bh=81LyED8xBy
	hdxre3X+pcX8/ozkkIGEJ8CIs1nBnUlxg=; b=N5/e+OZcbUNQBRgKUkJ+v8W+Fo
	TzLPpIVdnaRBrktWkmcs/tLuodu0H++rN0DwD/KKs0gabaDev0tG+e3HN65SSX8g
	xbvnpq2NzP9v6c0l0ULCuDftQXU9HETMiNJZbjZzgLji5L2Kxyg4OxSrUG5uhvL6
	+Ak61/MieKwPr94SrDgRzwOwWi2eTujYZDkajSCwTLw1nu0ZOcpPQyU+axbxHe0v
	WSbT74w7fUt/u6Zb2VsUkr06EzeH7admNr5re+EmRS78JUdejEYlOYEuqCZWUP9B
	T3+AovAdhDPZbm6VsCcYT5T+0pJQbeQoxBmQnIOAIjIYN2jOLJOOVND9nhSw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1666021099; x=1666107499; bh=81LyED8xByhdxre3X+pcX8/ozkkI
	GEJ8CIs1nBnUlxg=; b=f1l1AP5+RTFXqDsBIRy2yxtcE+NgkwarbSvhkrhZyXER
	RGTAnyynE2OXxFj6tnQbCus++2Wsh64AMIos0E1+jRkfrE8clzPnjWwg4aRwYSf2
	ja4bo7aLO/eKJ10uNo9sW8PCuhKGhMx6J38snp4ftL0+y4ojoKFQ5rEyB5el/jNI
	s6e0Zm0k/NTvEwuGcvz/ulj46Jmh56pCNueycQsDZyp+yyX8Ssvv2s4DZi+6Dk+P
	RA4un06C22jASpkvszqyOncsV8la++SNO/1oYZdPScWjscEilumIiZNVo81ysny0
	lrM36I1nhUaLU7Eow7pNppxPw2HCX4Ve73Jd5UB6ZA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekledgleduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe
    ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
    vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 17 Oct 2022 11:38:19 -0400 (EDT)
Date: Mon, 17 Oct 2022 16:38:17 +0100
From: void 
To: freebsd-arm@freebsd.org
Subject: Re: sound on raspberry pi 4
Message-ID: 
Mail-Followup-To: freebsd-arm@freebsd.org
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.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; format=flowed
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Mrh3K6s6Jz3Mxm
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm3 header.b="N5/e+OZc";
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b=f1l1AP5+;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.24 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.62 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.52)[-0.519];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Oct 17, 2022 at 03:50:49PM +0300, Odhiambo Washington wrote:

>Just curious. How do I test this?
>I have a Pi3B+ which I have always wanted to run FreeBSD on, but then
>getting FreeBSD Desktop is so much pain.
>How would I test accel video and sound on a Pi without getting stressed
>out? :-)

I have this running on a rpi2b+ (v1.1 board, so 32-bit). I imagine it'd be 
much the same on rpi3b+

FreeBSD generic 13.1-RELEASE FreeBSD 13.1-RELEASE #0 n250148-fc952ac2212-dirty: 
Fri May 13 06:42:16 UTC 2022

generic kernel has this line added
device          vchiq                   # onboard sound

freebsd@generic:~ % sysctl -a | grep vchiq
dev.pcm.0.%parent: vchiq0
dev.vchiq.0.arm_log: 4
dev.vchiq.0.log: 4
dev.vchiq.0.%parent: simplebus0
dev.vchiq.0.%pnpinfo: name=mailbox@7e00b840 compat=brcm,bcm2836-vchiq
dev.vchiq.0.%location: 
dev.vchiq.0.%driver: vchiq
dev.vchiq.0.%desc: BCM2835 VCHIQ
dev.vchiq.%parent: 

the job of this rpi2b+ is internet radio. There's a single speaker attached to
the sound jack on the board. It uses mpv to play streams. Seems to work well.


From nobody Mon Oct 17 17:55:13 2022
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 4Mrl5Q6YkTz4b492
	for ; Mon, 17 Oct 2022 17:55:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(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 4Mrl5P3k2Kz3jMs
	for ; Mon, 17 Oct 2022 17:55:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666029318; bh=cj8f5Q6W7NLB+hNJnBoBjpVK9wyoAuSv+vhVP/Y1Jwo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=jiSv6FD9/BNX845gV45aLXgVnioWzAfoX2/ZbFeOYAkvafR5dMbYX2uke4C0RJtoq6pVA6xMG6uEPITKLl74AKNrlr0n+U6BzAaRGsyoVVWeCpwFya6uKx+O5fAlfdPzCTw/yOTbkXHEpu7gk2Q42xveLvSAvLYcQS9S4GUfclH86EudBg34v7QB/Je7aOfDfKkpuR+AIZmGAv/saxQ77WgTcagcQayJBiJpsOoqUwtOUxmN8AoRtJ5HvCP2D967vBW/aPcdbuocu8XnfWhQfZD4E8CD5R9FcfnYqskkDuDofPvFF8DlKHfOYLT8J/ZHBTo9UsYa5m+FbTlbeyFPmg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666029318; bh=LQsqI038UzG52FdJPRqv0zPrakNQmswkMKGBFqjkzSQ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=S/o0ZgJ07tRRI5F6MAYoAgZy+7a1VP5BWNlRqCYyEjfGrWCVlAJn41+3tWg0T3ltPXOUhR7n8dcl4UT85Il7CVE54fLhgu580ohExZygIzaTgkgBnMCKGJoLeUBkc2BwRie1e9XVGH/aLbR9oC7OIusXGLxKDvll4Ehq/Wnqtaghzukc2ZejSUUBzJbDnTXuq2ZCbzzQKmmunE4uCckrq5I0Bqa6HtKcBtSqdfWOnKns6I0cg6ENsnVOrZCY8EsUfcz1TboCn+rBCJhDBER6b6ySeEaJwbpOztbXVF6nJz5IH2IxWcwcLn3nVghWoWDgV5X5oFxwCf4EsTygPuKD3w==
X-YMail-OSG: aa6yAr0VM1mGv1_JfUyaAk4yLVh0P55TMeMi2hxt0W3wDl8ahG0LEmHOnxqfrsg
 wk2X02jMyInPK8QwhPRgDPvC8iCclBOyqWWk0sN6huZPjdWJuW6i4e_6oVwGomb.v11K_hIu6ZTY
 .156lk6ynGHKRAeWxarmlC0ofILxY2uAPL7whtnM9VGjDpY6VpGrpUQ1LCcL7NOx8MYYqtR4XG4H
 fpDaJpQOs5aEfTcF076dsZuIQLD9j2nPTkMZ0keVOAbKOIVrBz.Gfss9ICawbHn.rcLtBEeecKxC
 dlvwBpBMnuL8YtWjEWENUKKphz0omif4GSRFu2FHoj07_uM.WJ5EAozzSnM1UzCJ5W3rUR9R.ek1
 QqCrJPYWLBZsg8cThfxDK2CdT0ss9Q8gyUqiUhw9muQR2eMfsydeWtu1VrbQKX8bNSXHjS4KLOxY
 t5FxnycMDRAT_N4uC9F4I.TPxFwNCxUeGBzAwQWkrMSURwT8Xxvg6JzhDmCWER93J9GhCgr7ZpyF
 3M0PtKop13dN5OutF6y7xslZ3bazgYAkwpToohtF3l2PJVqDDPkNOQ2gRupc8fsgd5hga5VZuD23
 6o3R7yq8FfAghcJWiOtMAvtdVealV.iZSjoIkEiAjIfOV_u9XDI.hP3pSCTF3LP_RbDmMvrcMX4F
 Hxnx7QinH.Xfh3MC9CCSq8wLRvCpK61aHJ2u0CVXdXf_pBbeFGhwVEZKWBya3tUyOf5XJhukuvER
 15w2pCPhkdSiJ4967biRTdhAaaSCFaG531J3KtMfcN8ezRd3EkeyWxZmdEoLNYPFvtO0qGpGLQ9q
 lk1QF3E9HebS6fSt1qgX8baHdJDBDLOgf86xBBlfKK1I6f4i1ALKzjRti6XlyhPyQIkFlxAdfSDK
 kQ_3yaALqKHbN0nggYpFNpbNOiCjyMm8Mm2voBlbH5MqQTNDRNnIuG8QeGSltwCyRrgQdEgt4S77
 d12uInSwxdcKN.AxN8yWpFAobQpZtAUCxHWDZ3TSMsGX6S5z.58qd7.YN4PB5edwTzhbCEGQOdHn
 TNhuJLcWFi9rLEWsts5pJ2fRxkev5WFEZOlUl4Zrwulgfkep7Hr_CXgdAU7.dkQdcyKyVE_tp4so
 60TkdJWrjTifRsQwbJrW1FqrHu4S3GSdS6cK51hmwljfeJU_lyOSwSFn_VWi_.x6QdTgKG37n8ru
 F7avhv1bFw43SWKqIOgyM1KiERo52cAB9MQ5y4m8vlZ9hT3uzH72OAhkjwL66iWI0UG6zuXW48A3
 FuWvMa8kDiA4JnK1BYlJjooYHcbOMH07pTXlgI7CkioeLgK03UXH8wK2eeB.Xuij49a5Fq_VBejE
 mzg.muL0vQRip9cdekP.rpXExhGO78__J6QHebq8K.02BfqlpINIAcM__S0zbI99g8okK0XqONdz
 o10MF2dSFfnFcxA23ovObrPoPhHVlscWESlZXMXWlhQCBw3vjBFandP_KDEcF4G5XXz0lnWy.G63
 P3nFQ0mLnEmy6Q2.QGe0urgcBGe_NKvTxTiStGtCiw8YDnmukBOTRcIPGZTi9u.DH_jC5So.A3qW
 2ew6zfvNLKV7F8sJIfLiKlRh8YU4ntWWGIXqx724lZGypr5WLcWN9AdYDfgPpD94H.JXlxvUgrN8
 9aiPR0rq.NXPVlDnzv.HqDGJ1T7_U7algRsS.WQujxV_FZ_Xuct8_xjnJCMTohUCsjw2T9SIoXwp
 RtymypXnTjNGOe.4uU_qTUd7pzxn_0oRQiw499jOwV7B_4oWjFtL1gMBiUgAduH6Bf5ZuM.Bd73L
 J5s6WPSETPMpKBG5fDIJjoNTYeNxdJMOJh2IDdcdmWHai176bYQ4KaykUP5PcqXyJdqM50NTuQaO
 ohu0FI.GEilmZSQAiCs0iu88jglvRX4igbeNRfEKgBSxgavA7NWV3KC.DYpEIkurBDV.ReJuxo81
 cfbbLbr8kN3miYDEU5STqGwReAaCrQ2EST_p2iBAh3g25bWx0MeixOofyvNmFjxyQb8U_qXRAPgd
 .UaK1dRH.PP0KBedUqtZSDvoMQIcidpLy6gBYBqokkkKFKcl.B7BmoMd3FEUHhFn8y8sZ4OzjSUz
 w_gzB72qtFf0belkgsn9lVWK_unEagR5gT9U5nVO7DYo3s4vzO3NHvwA5flVg0Go13gaLmeiYXkL
 9yztT5tPEwJl.Ao8MLOixnkzZJJkltWOYyNrnbKCzyf7MW2YBwfnY97.ks3DjoKoyY__ri0pqDWy
 glt.q5CH_1jU3uZzFIJpEl9lB8kPl3q3kuB.rVP3vdX2jv6yIArzesgYd0.k5hAVy
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Oct 2022 17:55:18 +0000
Received: by hermes--production-ne1-5db649d989-57w6q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3782c65795a71ac10f5c3404c683a062;
          Mon, 17 Oct 2022 17:55:15 +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 \(3696.120.41.1.1\))
Subject: Snapshot stable/13-n252734-56533712694 and RPi4B: I had to add the
 likes of initial_turbo=60 to config.txt to boot from USB3
Message-Id: 
Date: Mon, 17 Oct 2022 10:55:13 -0700
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: 
X-Rspamd-Queue-Id: 4Mrl5P3k2Kz3jMs
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=jiSv6FD9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.68 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.98)[-0.983];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	NEURAL_HAM_SHORT(-0.19)[-0.193];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

After dd'ing:

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img

to the USB3 media attempting to boot from the media consistently
got (note the uhub_reattach_port USB_ERR_TIMEOUT lines):

. . .
Release APs...done
uhub0: 5 ports with 4 removable, self powered
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on =
usbus0
Root mount waiting for: usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
uhub_reattach_port: port 2 reset failed, error=3DUSB_ERR_TIMEOUT
uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2
ugen0.3:  at usbus0
ure0 on uhub0
ure0:  =
on usbus0
mountroot: waiting for device /dev/ufs/rootfs...
miibus1:  on ure0
rgephy0:  PHY 0 on miibus1
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
ue0:  on ure0
ue0: Ethernet address: ***REDACTED***
Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=3Drw

Manual root filesystem specification:
  : [options]
      Mount  using filesystem 
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
      Abort manual input

mountroot> ?

So I updated config.txt to (shown from after a
successful boot):

# more /boot/msdos/config.txt=20
[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
#
# Local addition that avoids USB3 SSD boot failures that look like:
#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
?
initial_turbo=3D60

That was in order to boot from USB3, no microsd card
involved. I've not tried to find an approximately-minimal
initial_turbo value. force_turbo=3D1 likely would also work,
as would other forms of clock rate controls in config.txt .

It appears that FreeBSD is sensitive to variations in the
clock rates during booting but the RPi* firmware can (and
does) vary relevant clock rates unless it is told not to in
some way (initial_turbo use here, there are other ways).
Something is needed to avoid timing out too soon.

Note: The media is not my USB3 media that requires the likes
of usb_pgood_delay for U-Boot in order for U-Boot to find the
device. An unmodified/default u-boot.bin works with the media
just fine. Only the later FreeBSD activity has a problem.

For reference, from the successful boot after the change:

. . .
Release APs...done
Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
uhub0: 5 ports with 4 removable, self powered
ugen0.2:  at usbus0
uhub1 on uhub0
uhub1:  on =
usbus0
Root mount waiting for: usbus0
uhub1: 4 ports with 4 removable, self powered
Root mount waiting for: usbus0
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen0.3:  at usbus0
umass0 on uhub0
umass0:  on usbus0
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2
ugen0.4:  at usbus0
ure0 on uhub0
ure0:  =
on usbus0
Warning: no time-of-day clock registered, system time will not be set =
accurately
Dual Console: Serial Primary, Video Secondary
miibus1:  on ure0
rgephy0:  PHY 0 on miibus1
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
ue0:  on ure0
ue0: Ethernet address: ***REDACTED***
Setting hostuuid: 30303031-3030-3030-3265-373238346338.
Setting hostid: 0xd2f9b0de.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 498385 free (1281 frags, 62138 blocks, 0.1% =
fragmentation)
. . .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 17 18:26:43 2022
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 4Mrlnj55mDz4f6tJ
	for ; Mon, 17 Oct 2022 18:26:49 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d])
	(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 4Mrlnh17T7z3ppG
	for ; Mon, 17 Oct 2022 18:26:48 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: by mail-wm1-x32d.google.com with SMTP id e18so9212064wmq.3
        for ; Mon, 17 Oct 2022 11:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=gXyCbfUwW05+QoppEOW7y7XDb7CtUddLcAS6PXt0bUc=;
        b=H6FGh50IxQ1LX+q9qgx8eR88AG7/fMjqVWcm+8rJHwena4o84Xvu/7NzL93NRZGveO
         ChofZuGeobrClD63pY8wTOKFGeCJY1W81A8vFOqNvhluWENaDKUEinS2/j/9728847pg
         IIQGtrOkVu5+sIr3uQKZXsFQzFI7/QdqvHxJNOUmD/yzwM4zl/LNeTv2YtztE7w2poRU
         8opuwXILrny3P5eAk3AgAHBU9mfZPSE2rax8h2cKUuCXxN7Ksbb8EIAI8D+xESyDQh3x
         pfhvBvwktZzTZh3qPVdvV4XE6m5HrXOUFgDZq3nlOcvvGi6XPfdormrzKgg0isXrDoJJ
         GRNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=gXyCbfUwW05+QoppEOW7y7XDb7CtUddLcAS6PXt0bUc=;
        b=B4tko2rtireBnsbLGN7FHNn4htaPLpreGpOgJ5sOEIg/79GWlnORg52nI8WWBUFA4r
         GX9HPDuEHLLHUyS4lm+QFV8r/qMXjaV/ZMVMjIGVSsQq/rg9pxO9Xn8LlMw9i9hstyKJ
         f4s31HKF/qUwsaEvzf4EoOBfvRGpNi+OTjURqBtS+g5eufLSnseFncrYuNLjafnoFTkp
         ATng2J/91lm9ovO8GGLuuFrXESAEZB8zgDNH/w55A5nmsoPDVzKrqJrXFPUq3FqfBTv/
         GRoZ6jzqI+njbkh7eqD4MUDt1UiTUdbvOdD6wmyMw9HlEesZ6VST2fEHQlRc9Z0F2j9w
         4Sjg==
X-Gm-Message-State: ACrzQf1viNwLz7A/AGXq0MPbzUa7F/4bF2jEhj0OY8XUl4KDl7DMp4EY
	fiRmS1xbvVxYHlXAJFHUPyY=
X-Google-Smtp-Source: AMsMyM59hAWOI0dIGPmrEYSa3/poGy61j4pJ2G7Zx3bWS29Sf5vM7i4fYXHaDmAqF231MsEGWEbxGQ==
X-Received: by 2002:a7b:cb92:0:b0:3c4:cf60:7a7 with SMTP id m18-20020a7bcb92000000b003c4cf6007a7mr8419481wmi.24.1666031206679;
        Mon, 17 Oct 2022 11:26:46 -0700 (PDT)
Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181])
        by smtp.gmail.com with ESMTPSA id l1-20020a5d4bc1000000b0022afe4fb459sm4207334wrt.51.2022.10.17.11.26.45
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 17 Oct 2022 11:26:45 -0700 (PDT)
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 14.0 \(3654.120.0.1.13\))
Subject: Re: sound on raspberry pi 4
From: Marco Devesas Campos 
In-Reply-To: 
Date: Mon, 17 Oct 2022 19:26:43 +0100
Cc: Hans Petter Selasky ,
 Warner Losh ,
 freebsd-arm@freebsd.org,
 Ronald Klop 
Content-Transfer-Encoding: quoted-printable
Message-Id: <94364306-B7EF-4B1A-866E-C2E566047DFE@gmail.com>
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
 
 
To: Odhiambo Washington 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Mrlnh17T7z3ppG
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=H6FGh50I;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of devesas.campos@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=devesas.campos@gmail.com
X-Spamd-Result: default: False [-3.44 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.945];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi Odhiambo, and List,

> On 17 Oct 2022, at 13:50, Odhiambo Washington  =
wrote:
>=20
>=20
> Just curious. How do I test this?
> I have a Pi3B+ which I have always wanted to run FreeBSD on, but then =
getting FreeBSD Desktop is so much pain.
> How would I test accel video and sound on a Pi without getting =
stressed out? :-)
>=20

Oooh boy, I don=E2=80=99t know about that not getting stressed out=E2=80=A6=


Anyway, the short answer to how you test this is: by using the 32bit =
compat mode.=20
(People with pi4s please read to the end).

64 bit pis can run 32 bit code, and (to simplify) the libraries that =
connect (via the driver)
to the hardware have not been updated to 64 bits.=20

If that hasn=E2=80=99t put you off, this is what i did to play video:

- build the kernel with vchiq support (the patch)

- I had an SD card with a 32 bit installation that had the rpi-userland, =
rpi-firmware and omxplayer packages. I hooked it up to the pi with a usb =
card reader and then used chroot
to go into the =E2=80=9C32bit world=E2=80=9D

# sudo chroot  /bin/sh

- We need to mount devfs first inside our impromptu jail

# mount -t devfs devfs /dev

- and=E2=80=A6 that=E2=80=99s it, we=E2=80=99re ready to play some video

# file `which omxplayer.bin`
/usr/local/bin/omxplayer.bin: ELF 32-bit LSB executable, ARM, EABI5 =
version 1 (FreeBSD), dynamically linked, interpreter =
/libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 13.0 (1300139), =
stripped

# omxplayer.bin /home/freebsd/f.mp4
Video codec omx-h264 width 464 height 272 profile 578 fps 25.000000
Audio codec aac channels 2 samplerate 48000 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0
V:PortSettingsChanged: 464x272@25.00 interlace:0 deinterlace:0 =
anaglyph:0 par:nan display:0 layer:0 alpha:255 aspectMode:0
Stopped at: 00:00:08
have a nice day ;)

I don=E2=80=99t think I=E2=80=99ve ever tried it but it should be doable =
to just download an existing arm
(v7?) image, mount it as a memory disk, and use that as a root system on =
which to install
the needed packages.
=20
The bad news: Pi4=E2=80=99s don=E2=80=99t have the 3d/2d acceleration =
drivers, so that=E2=80=99s out. Unfortunately
even omxplayer from ports is out since it uses openvg, the 2d =
acceleration framework, for
rendering subtitles =E2=80=94 and will crash on start even without them. =
However, If people get in
touch I can help them compile it on freebsd without subtitle support.

OpenGL applications work (again, on pi3/zero2) provided they worked on =
32 bits.
Unfortunately, iirc, lots of ports required mesa-libs which conflicted =
with the userland
(accelerated) drivers so there aren=E2=80=99t many examples around. Have =
only tested the
example from https://github.com/raspberrypi/firmware

Any doubts/problems do get in touch,
Marco





From nobody Mon Oct 17 18:27:26 2022
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 4MrlpT6VcWz4f6tL
	for ; Mon, 17 Oct 2022 18:27:29 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f])
	(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 4MrlpT1c92z3q8T
	for ; Mon, 17 Oct 2022 18:27:29 +0000 (UTC)
	(envelope-from devesas.campos@gmail.com)
Received: by mail-wr1-x42f.google.com with SMTP id r13so19728838wrj.11
        for ; Mon, 17 Oct 2022 11:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=We+RMfK/i75c0VQMxY8kLAgnK/aa30p7KkqgkrnXRug=;
        b=m/2bSKfhvJgNCIEhanWrvdq6bJmedpT4502eDCfxsSfqmtfb5tKvbvzdzkdVD+2uhQ
         YVldV8LLa6GCH+xUaUOIl3EdNYpBbMNcWRAMzGTa0tje0x4PFfeYKpoXynyYvz1NaBsg
         tXktIiJigATIwVQlswNh2jxU0cVArBi6m+EOKagNKg5U4AsG+Dr2tAqqDg6aktzjEx8x
         mYiBr2tqBs54Is/UqNVAnf0Hoxd6rq/YS0sA0p3BxZ+EeYSGKYaWF5Pa1PrHvsTmLDgs
         JeaeWWwwF2meMyIHF7fo25gmvjohqXbbXtr6cpzkbj2LM59FFIhuH2fpb79j5IsIXQ48
         CbdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=We+RMfK/i75c0VQMxY8kLAgnK/aa30p7KkqgkrnXRug=;
        b=uATVEJP30cd3rzKn+Z33M11NO02KHRgU80H/wchtdNCh5M3jDW1NEZRChSYK/7oPBq
         GuSbHk8gvEPRsS3N/pTY4YlgcfYnMrzJm+iO4lppkb8wmIbV2sIGq59gEkX1s7g51K66
         ZoM2u14e6H5G2XEQsJbAIlErv2BtTy/gc5sQKbLBRYl3l4RNTY8QZgyl4iVZgb5U52Kj
         edTWKnDUFXynPgm3rdG7KTJxkTB0sOYahyxywFjte7qxiJUMmcrKjl9h6Sr46KRr4y5a
         eGJIjFkHuj6j/tJNK5w6kkSRGwiysF8dzLhzKB91Xn9CeheJpIW8MX3wwmlA8Q9+L1ff
         fS+Q==
X-Gm-Message-State: ACrzQf02GHtw/ikv1Yr5HiRlsG4PYXK29gcT/Rg4NCac0KEclsGaXDl5
	LdCVNIUvJtzCaBlzCDtO4n4=
X-Google-Smtp-Source: AMsMyM45kjkuLtAdEwyO7vOI+23NKl940v38rxOSkLmD7BxYAexpq6rZZaOBW0dVcnWaAn9U3lsbxw==
X-Received: by 2002:a05:6000:1e03:b0:22e:3bf2:4685 with SMTP id bj3-20020a0560001e0300b0022e3bf24685mr6916068wrb.82.1666031248017;
        Mon, 17 Oct 2022 11:27:28 -0700 (PDT)
Received: from smtpclient.apple (a213-22-242-181.cpe.netcabo.pt. [213.22.242.181])
        by smtp.gmail.com with ESMTPSA id l1-20020a5d4bc1000000b0022afe4fb459sm4207334wrt.51.2022.10.17.11.27.26
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 17 Oct 2022 11:27:27 -0700 (PDT)
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 14.0 \(3654.120.0.1.13\))
Subject: Re: sound on raspberry pi 4
From: Marco Devesas Campos 
In-Reply-To: 
Date: Mon, 17 Oct 2022 19:27:26 +0100
Cc: Odhiambo Washington 
Content-Transfer-Encoding: quoted-printable
Message-Id: <14F9CA06-C2B1-4E9C-B370-9561F49FA7C9@gmail.com>
References: 
 
 <1e9994f4-39f9-5adf-2cb7-03c9981b424e@selasky.org>
 
 
 <9C8C18F4-43BA-4F1E-B683-7BD5AC513C8C@gmail.com>
 <948CD3ED-F501-431F-BE66-3DD51A8C9EF5@gmail.com>
 
 
 
 
 
To: Valery Seys ,
 freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MrlpT1c92z3q8T
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="m/2bSKfh";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of devesas.campos@gmail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=devesas.campos@gmail.com
X-Spamd-Result: default: False [-3.44 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.941];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

For clarity:

- the patch should work on all 32 and 64 bit pis and has been tested
on zero, zero2 (same as a 3b), and 4 boards;

- the sound subsystem the driver talks to outputs to both hdmi and pwm
(can be individually targeted), and you can get bit-perfect audio =
through
hdmi (then it=E2=80=99s a matter of what kind of DAC your =
screen/tv/amp-with-hdmi-input
has)

- i have the pwm output hooked up to an amp and proper speakers and,
while I can hear a difference, output quality is actually pretty decent, =
certainly
if you=E2=80=99re listening to compressed audio. And certainly fine for =
what I use it for
which is as a sharplay-sync receiver from my mac.

Also, if I understand correctly, boards such as the hifiberry connect =
via =E2=80=9Ci2s over pcm output", and, while there are drivers for some =
boards (eg sys/arm64/rockchip/rk_i2s.c) I can=E2=80=99t find the =
equivalent for the pi's bcm283*. (Happy to hear otherwise, here.)

Marco

> On 17 Oct 2022, at 15:11, Valery Seys  wrote:
>=20
> * Raspberry Pi 4:
>    Broadcom BCM2711, Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
>=20
>    =46rom what I found on the net:
> 	A: The Pi4 still uses a PWM sound output similar to previous =
models. Therefore, don=E2=80=99t expect high quality sound from the =
onboard sound. A HiFiBerry sound card is still the right choice for =
optimal sound quality.
>=20
>=20
> * Raspberry Pi 3B+:
>    Broadcom BCM2837B0, Quad-core Cortex-A53 (ARMv8) 64-bit SoC @ =
1.4GHz
>=20
> 	https://forums.freebsd.org/threads/rpi-3b-sound-and-wifi.69297/
> 	Sound: sdio
> 	https://reviews.freebsd.org/D12467
>=20
>=20
> Q: could you run MacOS-X.0 on an MacBookPro 2022 ? Still the same OS =
...
> A: ;o)
>=20
> Do you need sound on a Rpi or any other SFF board ? Get a simple =
external USB sound system, really the better and easiest choice I think,
>=20
> BR
>=20
> V/
>=20
>=20
>=20
> On 17/10/2022 15:24, Odhiambo Washington wrote:
>> Oops!
>> But still, I thought that the same OS is used for Pi3B+, no?
>> On Mon, Oct 17, 2022 at 4:17 PM Valery Seys > wrote:
>>    Perhaps just look at the subject : "sound on raspberry pi 4", =
which is not a
>>    Pi3B+ I think,
>>    BR,
>>    VS
>>    On 17/10/2022 14:50, Odhiambo Washington wrote:
>>     >
>>     >
>>     > On Mon, Oct 17, 2022 at 3:29 PM Marco Devesas Campos
>>    
>>     > >> wrote:
>>     >
>>     >     Peeps,
>>     >
>>     >     Have yet to receive any comments =E2=80=94 let alone =
reviews =E2=80=94 on
>>     >
>>     > https://reviews.freebsd.org/D36431 =

>>    >
>>     >
>>     >     The patch adds sound, and accel video support to 64bit =
pi-s;
>>     >     it implements 32 bit compat; and fixes system stalls in the
>>     >     existing code. Useful stuff, methinks, and a few people
>>     >     on this list have atested to that.
>>     >
>>     >     So, please, anyone? Any =E2=80=94 any! =E2=80=94 feedback =
appreciated.
>>     >
>>     >     Marco
>>     >
>>     >
>>     > Just curious. How do I test this?
>>     > I have a Pi3B+ which I have always wanted to run FreeBSD on, =
but then
>>    getting
>>     > FreeBSD Desktop is so much pain.
>>     > How would I test accel video and sound on a Pi without getting =
stressed
>>    out? :-)
>>     >
>>     > --
>>     > Best regards,
>>     > Odhiambo WASHINGTON,
>>     > Nairobi,KE
>>     > +254 7 3200 0004/+254 7 2274 3223
>>     > "Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF =
:-)
>> --=20
>> Best regards,
>> Odhiambo WASHINGTON,
>> Nairobi,KE
>> +254 7 3200 0004/+254 7 2274 3223
>> "Oh, the cruft.", egrep -v '^$|^.*#' =C2=AF\_(=E3=83=84)_/=C2=AF :-)
>=20


From nobody Mon Oct 17 19:30:40 2022
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 4MrnCW6Zd2z4fGKW
	for ; Mon, 17 Oct 2022 19:30:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4MrnCV3L0mz3wnq
	for ; Mon, 17 Oct 2022 19:30:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666035043; bh=/8KKEAjdSterY8uEoBo7od07vTjuK4A3LRUW8q6BH5E=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=CwEbkugye9yW/k1BJ+uazL3+/Qaf1oVnZiCDkgEoaUX0KquKnhkgIjyzPIwejF2/Fq+A9DZXYfEyksiSw+CtDHnsBwKUl9SeNxHbgiZGKGWJXhD+qr1aN+ikizv5y0OTNcaTnv8+DYEwGbCaUoU1jaEV/FI6KjgVney8gmzrrAhmF/tdlOtlDO89/65L04jAnlzYsEOcUO9A/GL7XY1DxOSMXU+hrbffQgkpWFaMxpY70CDTiPpgFi781E9Knu0yu6Jt3kQdg/S5BcFKBCrAfTL1J1nPAfDVBdwLUjFZHYOZGbFXzmCS08WVE5sHkoyuk5AymfJYx+p+sEpBTAOwOQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666035043; bh=TvJUc4KAKL/5rpx5P7D4Jy+HAL2KwKjgdp8rs76eFyf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=INFa4Tdm8JPM71rrbGDIaFVj9iuNM+rGuFvUIg+Hrq536qzLMVVQSPGtgkyo3PYe1Dvr708NO9qYz6Me7TPJ5NxsRTZWOor3/tATjCD+wwx1m2xc/dej6P0LJPHVBmAW9QlvYyjba1yDcGR6YqHZ4MoYPn9D+H41FQV2zbhcSKGeryDE/4APgSCq0t2USeLhsXb6sVxpDpIFk//MZKZIwQbSHOXIzC0molzXCSEglPYbcIbf7OBj4ascxaAlBfyzlwCibBdbrZOs9+ROquSMkoeGNrMJx0+rAlcWsnPHMEaQYsZARFQXqWN1V5ED2bmnHEs3EOsLfjlpmV308xMlyg==
X-YMail-OSG: YxHk0oIVM1nrXXo5pH3cmJjuX2h6N3V.l4Yic6IEd13T4j9P91kjaK.ClDb8HCc
 DIJGyI.AFYYrfkFdA_gczZlzHbzopm6y380WaqI8SWHntjYgnWfBBWp2E7ORF6CRWdM94i20MmEy
 IQ1M76WxkejgLw9mDAgh1Ox6WBU15Jerf.Gv8MvnRJNzRh2vX3bL3P5fJ9X9PyqjKx09w.Hndq4P
 0wHwmmMDbeDaw44sXQwbZ3tA8QeMIfV7to0m_GmShBfOh5fJbh8WW3EeisTYRbkXj_MOB6YLd1qp
 o4XmVDnNso7T.UXsim1sbWpfnpJl3sjM8xVKecCHW9GdtgBxFpxzQfq9CesldJNXI4rGxhdyZtSk
 ZOKUyJ7Jj7876LJBDFXZtMNzcSknA590zjY.oi0qYw4SeHFF40VapUxKlhFKiJzJJDWR2is7MBoe
 l1w5QLh9B5BVFj3umCMusWBYsfQl0Umz7o2q4hQQwU8BkWx5x0TgKHj6e7Fu6aVHgb6DGBjl2TQ3
 LoYKmVa8X8SJJA56Yj7XbTpZUUkmqn_BqoYwMCoDwavrXeGOCrhB4zqYlzuNqOzpchNlODEkcJnw
 I0g1Abt2xAh1rYj0xH19coVKyQrnneW8CWXVn1b.lRJ8Xs9eUmCUuHcvcxR6yNnEMJcxZPbBmuMU
 0dbS2z426L0bY9fy4F_44LHEHX8wUvhW8Xm7_b9d48OENY22JmrnoTzGCHLDh09bKuQsY1CMNCzt
 Wd0OpheP5yYNvwtzwowACNwvOwEnHqxHzNC4brU_LDQ7lq0w8ZWuSb2THv8fginjFedSvZ9Z8_bm
 jS6n0.sGLRHbAn.UVdma511GpG6WhXvmbf9MIFU7xLc5_.15ySMV4PeOpcpQ.rK37KZy476mqwew
 xR3SFquvtuTetBtkWOUJp1QnHHYsYPHEYQpW5h008QQ6yBjHjUzQNw7y_0uFlMcW9ZSeHBxPUGrX
 Aqs_6FqPQQANqFdF2q2LJnQDbVG6oVIOiEUsT0uwImbfj3qfW8OmiAFPVK_ozBE115kEA1.5Mu8J
 rHgK4igpWOt5Sbz62cJ4Ut4q9Xe1Qqdl_TajdSDkJKyVL77GNc1XQY6N5aqgn0.PL1OZaa8LkhGT
 yTA7JirrApv.SqEjPWam847poeHC.RtXqsSmdU8Iqh6zF7p3ZjUpH0TbtJHWIG63MVdOFgUu02yq
 fLeFYQ0z_cx39DyJSoillV3mMsO4lo6w2PJi.H2PTHshE0_OK4sCejbTfzHsjoTxc5_BUjMpZPw1
 yVgecNV2L0LIOzG0_5a26BVIAyJWaKe_B9Q.0xYfeOBJzJBk9ye.zHYoFjanXxrGkIZNk59tQamu
 8jrSDQtKL.sZtVi6G2CJ1jpO4IWHTE2cUqE3GuC51zmNbTGa2YsmZ5v.ulh.I78Zqx3QS2Wz1K2h
 P4Ji0rfIhr1IC9x4.cI4fpXRZ.dsl8pX5eQzDDal9QDwP4wCJu5RG9bdr8v.uPrD3ulY3gKs.QpP
 MtUCuI3I1zUEeb4PMP1v7X1egbHPxkgafqjZb4RX9ssvfuruu7UWK6dF9Yux.uez1sBegC6lf_OM
 wsVajkJDznL9leA3HlsuVMM.BrtsoSB796ENPW1vJKxDFvH6gdv80L08Vt9db72wd6wRoIa5rAfc
 .yzkM1zvzJPLBxJE53pMLpgM1qYZW4_VPKifts4B0E2Tg1c4tWX_Ws0baV6.jV0.DBVBStr4dE54
 1thpLvJeUFeJhNenWFXzR7kErb3sQDPdPqnGPBKgEwUhLqG_w4nlsykDr3pBwGCcrTV_xx6wc22m
 e3YI931JY4hxgHVaOB.7.T20idhmXUIQIN7U0cqrun14U1PlSGV4R_191kRjVCnZCkzmO9DkgWsh
 zuvoAMIlRWmclm0vn0IGnto1krcfZIAfs1ylQEvMhUAkh9VfGOcMUvBwrzFTgapY7WU2hSeytOxr
 e6uQknaV1BFB0dRBx1ftxYmi7SER2Wc7QjEPls.NbQpIjaGaW4FkNzjPxFYzx.NBpCllZ6H5DMYF
 Gz51Icd5YdnbB6TBVS3e0S.7F1M.jHIGkTqUEI9z8gx3y2KmA7lXDdiw_H8uLF80M7KZQ3NmRbFp
 zZutI8aXj4sfIqIiRSbp6h3TAxgR8r88zbpBldDOErxZBjGfdsD6XMPTyQXt8GzBBDjrOk01nNn0
 NAPHDYxJutgnVDjjxomMUVosVi.6fl32BSRggNjyU8bLpZ7TuDULCAPxpmGydL5_AzTCQbsi1Oh3
 xcxd7z7G3rfvR65s5eN68YVyfo.UGxFwpEJeaPAXA7oDC9WsSZ.O1RRz3UCx1oDLggO0Ty9djoes
 qA7E-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Oct 2022 19:30:43 +0000
Received: by hermes--production-ne1-5db649d989-rdwc8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 01a4db6ba04dd58f71c2be28868ead50;
          Mon, 17 Oct 2022 19:30:42 +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 \(3696.120.41.1.1\))
Subject: Snapshot stable/13-n252734-56533712694 first boot "gpart: arg0
 'ufs/rootfs': Invalid argument"; also, an alignment question . . .
Message-Id: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com>
Date: Mon, 17 Oct 2022 12:30:40 -0700
Cc: freebsd-arm ,
 Warner Losh 
To: Glen Barber 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <3DA3BC90-D234-4B37-9125-E7A70F16DD08.ref@yahoo.com>
X-Rspamd-Queue-Id: 4MrnCV3L0mz3wnq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CwEbkugy;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

[While the example is an aarch64 context, the issue should be
more general.]


Issue #0:

After dd'ing:

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img

to the USB3 media booting got a notice:

gpart: arg0 'ufs/rootfs': Invalid argument

Showing some context:

. . .
Setting hostuuid: 30303031-3030-3030-3265-373238346338.
Setting hostid: 0xd2f9b0de.
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 498385 free (1281 frags, 62138 blocks, 0.1% =
fragmentation)
Growing root partition to fill device
random: randomdev_wait_until_seeded unblock wait
random: randomdev_wait_until_seeded unblock wait
random: unblocking device.
GEOM_PART: da0s2 was automatically resized.
  Use `gpart commit da0s2` to save changes or `gpart undo da0s2` to =
revert them.
da0s2 resized
da0s2a resized
gpart: arg0 'ufs/rootfs': Invalid argument
super-block backups (for fsck_ffs -b #) at:
. . .=20

It looks like the line in question in /etc/rc.d/growfs is:

        gpart commit "$rootdev"

where the prior code:

        FSTYPE=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}')
        FSDEV=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}')
        case "$FSTYPE" in
        ufs)
                rootdev=3D${FSDEV#/dev/}
                ;;

assigned rootdev based on:

For FSTYPE:
# mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}'
ufs

For FSDEV:
# mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}'
/dev/ufs/rootfs

So: ufs/rootfs

I'd guess that the problem is that after the gpart resize -i . . .
activities the label ufs/rootfs is no longer effective for
gpart (until the growfs -y completes?).

Whatever the cause, gpart is rejecting the ufs/rootfs
notation.



Issue #1 (unsure of the intent, so checking):

# gpart show
=3D>       63  468862065  da0  MBR  (224G)
         63       1985       - free -  (993K)
       2048     102400    1  fat32lba  [active]  (50M)
     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  da0s2  BSD  (224G)
          0        128         - free -  (64K)
        128  468757552      1  freebsd-ufs  (224G)

Reviewing the alignments (one is differently
aligned than the others):

The first is good:

       2048     102400    1  fat32lba  [active]  (50M)

aligns to 512*2048 =3D=3D 1 MiByte.

The second is likely good:

     104448  468757680    2  freebsd  (224G)

aligns to 512*104448 =3D=3D 51 MiByte, so a 1 MiByte multiple
as the alignment.

But the 3rd is less aligned (the freebsd-ufs line):

     104448  468757680    2  freebsd  (224G)

=3D>        0  468757680  da0s2  BSD  (224G)
          0        128         - free -  (64K)
        128  468757552      1  freebsd-ufs  (224G)

aligns to 512*104448 + 512*128 but 512*128 is a
64 KiByte offset, so: 51 MiByte + 64 KiByte.

This is not 1 MiByte aligned but is 64 KiByte aligned.
Is that the intended alignment for the freebsd-ufs
area?

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 17 19:59:08 2022
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 4MrnrP22fkz4fKNt
	for ; Mon, 17 Oct 2022 19:59:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4MrnrN2Fzxz42Gy
	for ; Mon, 17 Oct 2022 19:59:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666036754; bh=PeES3TIX73F2byIurF1P3PkyFXcpP6/fYxuObvjyCLM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Lp5KG7Fv1hit8WdfmM7fxMP3cOuo04RgaS29yHMqArmiR6w5yghKQv1qiVoLuFBFvGTT0kTeGKWTi+iD4Y+TbbDpd7W0+3bvLh8/jx6NqutHpyIXvcv3pN53DmG9RAcYqKw+kvHVschego6Y+h7+fBiGqECpdL1HbWgE0UCb9k5yRoPRW9szquM8Q+oH7+SGziM1Undab/svrjLLMXytiwPIpVCwzzCeOv3yELP+mDgNVogRWlOjFhOtDyl4ZgSdoryxi+vUIwjf/OxH8RwrjtaIBDYhuekCihtv0kWOyZKZ10WKSTuRBXOizKPiuZ6jBq1xe6BogOUgdOqsujkJmQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666036754; bh=e6uo8wuTMpCQES6f7mcarm1BnGXUpZdIJrRNDZ97AO1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UtYjHQBHLpu1JJgGbORMuhbwWGKiWFAtjtBKEkqAr+DEX3VkRUkk3VV9vpvq+T45haPm91dm7iSLKqI38NOO/LaAF3zCQ4L0p02wFzg5KsG84iusZeqLHVDFOV0mizY24c8/KO6eLnYkaRjV3FehXF14QMZHQAthbvj2Z86EM8RzM0VbrM0i15qKkfQ0ROVTUbP9KfYivEFfjmBYP17mFEf8bWKMYGf5ZODpLM/lypMi3q4jm/Nxg301QkT7+JLmyJnLeeO+f1bxp5NXOUMxmjFuYEKH5rZbrZg1AFpv7IiCkzDghpm9/yNm++H2Ph/He1w3tZ7QIwq9C795OEnPQw==
X-YMail-OSG: GzZ8h5kVM1kDpnK7WzaC8P_W22wMfGFsuRChOeUlnDwZ9EE3TncG0_MpTHoMvV7
 Ade3InII5CjuXCN6Ob6t0An.2T8Z1WhkdgrX3nILmgNM37E50xDEkb2Urm7ONKCz0IWsFMrGu1Oj
 Aih_NWeAhmMfbLnRg.TLyPW7fCeaM2pjN90pwYEB_vZudopRQn7c1ykOLS0ufudhJMqsfvsluJ11
 Cgka_DCcllKn50vLH_xnFJ34GhDkNBxxHzvCUlUwXSAyItZORaSd9mnqaPh0Tr_XCUv1XuHNqToO
 EGVbDiGhi_FPoJ0c0Vx8.yjkg8xrVO3cTgDtrqNQqMH.9R6zybqR5jkILPzDWFgBstN0LjBB8Lf6
 mCwCLpLQx1IIqzApAImBTNqA2vsTrWInQirNFyBT15nXDcVHzlGie3ej9SKVcExBxd95HCBJucpT
 p6ZGKL6nD7j90O8dPlGz3M.SHqQH4fQ6xVyZ0Zajlvl85XvGNZY0mJPVpnWn2b_N2PCAlmT62iVM
 F7iG2xQLAINy.HAiNzBuFJUnhlbWV6b1e63OyB_L9evT02uwuiVMfUUhnkypMHyruxRupVrZU02g
 YHmgHtwzSFduw9B1e7QzuxZLI4ZZhytMJ75YkR3tTq0TBzN7hC96.sNBfB5nMv.G6MVuc_RVNGVn
 Yg12KrbZV0IluWFTrZqw27GzSSiycK31wepAClj_C_jwVmKCTW2V.FwlLAgfPRjJ1.xnPB9C9LiG
 GxVskSIxChoCSNSJwG.Snb4OQ_IWmwUMZKUSZ5W5M9NfHmLdEWTiGaWYaX5.aKPY0VFHy7hSe6V0
 gWaXj5JBIarVw3dohVHnWzY5X3DRij.txm.MmiUJw7MTSXW3TvW3lHCEEAiV0hpa6MolloHKnBN_
 JJauNp3vN6nRz3KxnP6zmaW_zh8zwxqrw49ALTfd7UIxnF1.oVqFQTzC8Poa01_euFQxpDn_O9A6
 2LlYY6mOJUPZsclz97gwejA4W915kd1xRE.0ai3u_em_ruKGeXU1BCaWHJp.9.e_qqSgQV9r2owN
 ko_QSeHj0vst8WXe0AxuZiHXQ5u54OQ3ZCGxmPrLb9Vof.yrYUL15JC51vy86ks6ANqgcdqHWy78
 xUi_05ZIHoBwlHaqxu5nYMOrtBa.qzJWVksERzIK.g6GbIC9ZihY4zD.aG0sAhQrkmd7YataTbYE
 Eic1WnZgg4JXu7FapblTfDxL1h1My_LQ8XtSGu1YFpaVNui8hG3CFaUpvftFqfMOAPnQZ.SoiY5R
 Jk3KrEQaRAZj6HSB5goVEb5lS9F7zBy8RonaLjvo.vmj24txnLx4nkBCiqdZwPMmRbOAFg8.H1Pz
 udLixe4m2U4G4eTvKgcHpylOuklh1.QTQHCRxM5TUleuG9yyPB5eIfZEhBXqBGfnHj_g20Vs6DrL
 2wI7RFicufnof4JySYVDuefpHHbiK3qnJVRnaEGWVWBX.IpQkRCwjX_NpSgbwIBOPcig4_nrs0mv
 3VdBeI_hVp3JTImrNUJZkcgRj3vpIT7Y6AzmupXe2QXT3eVZNwBlkHNAdvJB.4v.uiCiRIuZillL
 1oqp63mytaU_thXLfiHRwhMGrhHOlugx0WubmaZuu6vZno9Cp3gi5LMzyQ2Y2KZzGl6JOZllkaVV
 KRLPFosL4GSXDoIb30R4RdfJ.TNRJmfjE347ItAQGMMB8pfBVw.LDQKFG9QnS3F9bZ6mErrjBHxg
 vkRkfVSeknnmaiyWHpx3zVKj4km8ENfhRbYKYEmbPymWrE2J.xyBk_UU1OmhukR50o20MtwklVFJ
 9m1n0SbdPMT7qU7g39_B5NefE26L9JNe9G0zzb2ESTVRTBXSi6WFZao92AnAw0qSPb2piLJRKVcc
 e.PSKwJACzRc.coKAPwpayuyfBe7Bx4kdRyXEJ6a0pAvXlEccdR065JZKzU5NQAzbM3Q4bZE5LC8
 rY.ebeAR66SU7vMn7dmtApzG49o20kQNjdbIyDgGr3MCsWhS.lUr9CRJb.0IkEzOF8Jli5wd6o63
 lWDMRiIDSztD6tUVFTX3LbTJS.FSdpuaIb.gQqeDwrYUJVGXFQVF3nrOqmAXjF53RZzllxMO7IsT
 6DbzvYhsIP7Il2U_fX9a8fuaLyFJChGhN1zqGRZZG_M3R0Te83NG0Ak8nob87Af0aW8VGaDU5cwe
 sgAEoYGH7DKrbxfgHLNaF2AwhQLMNobJvExJ_0vMUPu1OQeeRJa2khFIybEVcdyIM5U9tRpt_WI4
 Y8w.JibWaABmdvjtQm_8.q8obvKYESskmS2Wd8sXjBAwV3xdWZUcq7Y7F7U71NGtjGe2JzjPvCuX
 DKc8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Oct 2022 19:59:14 +0000
Received: by hermes--production-ne1-5db649d989-tklgr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e5a9ba90d7ac906a70a62797b6c50c30;
          Mon, 17 Oct 2022 19:59: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 \(3696.120.41.1.1\))
Subject: Re: Snapshot stable/13-n252734-56533712694 first boot "gpart: arg0
 'ufs/rootfs': Invalid argument"; also, an alignment question . . .
From: Mark Millard 
In-Reply-To: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com>
Date: Mon, 17 Oct 2022 12:59:08 -0700
Cc: freebsd-arm ,
 Warner Losh 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2287A7D8-8866-4481-A8C7-072B2C380B0C@yahoo.com>
References: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com>
To: Glen Barber 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MrnrN2Fzxz42Gy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Lp5KG7Fv;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-17, at 12:30, Mark Millard  wrote:

> [While the example is an aarch64 context, the issue should be
> more general.]

The above was for issue #0.

> Issue #0:
>=20
> After dd'ing:
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img
>=20
> to the USB3 media booting got a notice:
>=20
> gpart: arg0 'ufs/rootfs': Invalid argument
>=20
> Showing some context:
>=20
> . . .
> Setting hostuuid: 30303031-3030-3030-3265-373238346338.
> Setting hostid: 0xd2f9b0de.
> Starting file system checks:
> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ufs/rootfs: clean, 498385 free (1281 frags, 62138 blocks, 0.1% =
fragmentation)
> Growing root partition to fill device
> random: randomdev_wait_until_seeded unblock wait
> random: randomdev_wait_until_seeded unblock wait
> random: unblocking device.
> GEOM_PART: da0s2 was automatically resized.
>  Use `gpart commit da0s2` to save changes or `gpart undo da0s2` to =
revert them.
> da0s2 resized
> da0s2a resized
> gpart: arg0 'ufs/rootfs': Invalid argument

Looks like main [so: 14] has this fixed in:

libexec/rc/rc.d/growfs

so it probably needs an MFC. Not a snapshot
handling specific issue, as it turns out.
[Glen might have been the wrong choice.]

> super-block backups (for fsck_ffs -b #) at:
> . . .=20
>=20
> It looks like the line in question in /etc/rc.d/growfs is:
>=20
>        gpart commit "$rootdev"
>=20
> where the prior code:
>=20
>        FSTYPE=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 =
}}')
>        FSDEV=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}')
>        case "$FSTYPE" in
>        ufs)
>                rootdev=3D${FSDEV#/dev/}
>                ;;
>=20
> assigned rootdev based on:
>=20
> For FSTYPE:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}'
> ufs
>=20
> For FSDEV:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}'
> /dev/ufs/rootfs
>=20
> So: ufs/rootfs
>=20
> I'd guess that the problem is that after the gpart resize -i . . .
> activities the label ufs/rootfs is no longer effective for
> gpart (until the growfs -y completes?).
>=20
> Whatever the cause, gpart is rejecting the ufs/rootfs
> notation.
>=20
>=20
>=20
> Issue #1 (unsure of the intent, so checking):
>=20
> # gpart show
> =3D>       63  468862065  da0  MBR  (224G)
>         63       1985       - free -  (993K)
>       2048     102400    1  fat32lba  [active]  (50M)
>     104448  468757680    2  freebsd  (224G)
>=20
> =3D>        0  468757680  da0s2  BSD  (224G)
>          0        128         - free -  (64K)
>        128  468757552      1  freebsd-ufs  (224G)
>=20
> Reviewing the alignments (one is differently
> aligned than the others):
>=20
> The first is good:
>=20
>       2048     102400    1  fat32lba  [active]  (50M)
>=20
> aligns to 512*2048 =3D=3D 1 MiByte.
>=20
> The second is likely good:
>=20
>     104448  468757680    2  freebsd  (224G)
>=20
> aligns to 512*104448 =3D=3D 51 MiByte, so a 1 MiByte multiple
> as the alignment.
>=20
> But the 3rd is less aligned (the freebsd-ufs line):
>=20
>     104448  468757680    2  freebsd  (224G)
>=20
> =3D>        0  468757680  da0s2  BSD  (224G)
>          0        128         - free -  (64K)
>        128  468757552      1  freebsd-ufs  (224G)
>=20
> aligns to 512*104448 + 512*128 but 512*128 is a
> 64 KiByte offset, so: 51 MiByte + 64 KiByte.
>=20
> This is not 1 MiByte aligned but is 64 KiByte aligned.
> Is that the intended alignment for the freebsd-ufs
> area?

I guess, a different way of going at the overall
issue #1 question is: If 64 KiByte alignment is
okay for the freebsd-ufs area, should the other
two also be using 64 KiByte alignment instead of
1 MiByte alignment?

What I'm checking on is the lack of uniformity.
I'm not really trying to be the one picking among
the various uniform alternatives if uniformity is
appropriate.

[Why I did not notice this lack of uniformity back
during the alignment investigation, I do not know.]

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 17 20:01:44 2022
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 4MrnvL217kz4fKt4
	for ; Mon, 17 Oct 2022 20:01:50 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(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 "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MrnvL1W3Vz42g2;
	Mon, 17 Oct 2022 20:01:50 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666036910;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=SYFOYCsYHZ9gq8uFqLDqpnSm0zgGG0e+iN0HQODG/uc=;
	b=yY4w4x1sZuzPdT98ppo2Cg8iCWCOk47SY2/JC58pcdK3FjZgyIAF0dVFD6nmg7xLIX4R7I
	X5NTsHw2iTAat5xpmpTjJ0yn0QMR4ujlNpwGYFW0wUbAyl7tNKRkc16kd0jUw6nThVMPW8
	cwuO36DlTc7c7hFfRpiFDAnBJjiMQjAuIx/7Vp7oiUaDns9L36Kdp3UhN/DpbgwwjBlVFr
	K0zUEMXz7ie1xxWNcn38c1hhcIRiWRPCHpDz++1IcMFnTaWGHGINp/tiMdLPPjkoKq5qr+
	eUohnkkDs4bQhWiMYwe/e9X+SoSOi8c/3AJJqR1nlr5mcUxI6kw2kUud++hd3A==
Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by freefall.freebsd.org (Postfix) with ESMTPS id CAB211093C;
	Mon, 17 Oct 2022 20:01:49 +0000 (UTC)
	(envelope-from gjb@freebsd.org)
Date: Mon, 17 Oct 2022 20:01:44 +0000
From: Glen Barber 
To: Mark Millard 
Cc: freebsd-arm , Warner Losh 
Subject: Re: Snapshot stable/13-n252734-56533712694 first boot "gpart: arg0
 'ufs/rootfs': Invalid argument"; also, an alignment question . . .
Message-ID: <20221017200144.GK30607@FreeBSD.org>
References: <3DA3BC90-D234-4B37-9125-E7A70F16DD08.ref@yahoo.com>
 <3DA3BC90-D234-4B37-9125-E7A70F16DD08@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: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="94oXV8jP6EZ84voN"
Content-Disposition: inline
In-Reply-To: <3DA3BC90-D234-4B37-9125-E7A70F16DD08@yahoo.com>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666036910;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=SYFOYCsYHZ9gq8uFqLDqpnSm0zgGG0e+iN0HQODG/uc=;
	b=Rsc/odqpq+MMyDMDQ8H60u+Nd9bF3W/c8q0DiutSRF5f3676WBCIkEgrV8CJzjiV1Yd/Vm
	RRqKbRBolTqHKxTYmzJVgMZRG+Rq4v5sh4HQjzmPFV9LvHg+r+a9XK3IhwlQgLisfnTO/C
	42YSpkFBfBF7vr91pcr+zfC6yJQlqnbgsUn/rTMgSd1TNM/fqCAbLq7c1cmJmQZ4NkF5UT
	JKud/iIHYBjx3cb8iOOFseWet3fWmK4+P5anrucJQkN+PYol/JxfM1WyP0lNK0vgAQfnby
	j7CPy5fZlmvaPgxZIeBXFdK90Ei3UUhK1pBLdwfpMgbURKI6XonIQcMwUHudmg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666036910; a=rsa-sha256; cv=none;
	b=jyQyqpgRSDgbL4DwUfcIQbXAI2X89FNtJNl9ojBrDveUY0zX2uDOOS7trLxnn5TMgC+xry
	Df/KIS8nZzwnGjfrdOmnTNomgPQG+XerDNLEhuM4+iyB9fdMEtXX+t1CLwytRm5yb4mT9n
	duivd+BpTHx21+UkywTxqqYtCxdEYR8KnINgoQV1VniG2+4EB6OSrgeXjob703aBL3i5ds
	eoupLH2x8vig1UGKlxLpTr7m1jkAuvqTG9+O/3dXvqkKb+Sk9YsOTgzJR5YcogtrIsP8QK
	6SacAp0ZpK18zN5FmTCKfTKxTrH33T4dr3XB/Hvd5yJ/FNMLakXEmUQILG29bQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--94oXV8jP6EZ84voN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2022 at 12:30:40PM -0700, Mark Millard wrote:
> [While the example is an aarch64 context, the issue should be
> more general.]
>=20
>=20
> Issue #0:
>=20
> After dd'ing:
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221014-56533712694-252734.img
>=20
> to the USB3 media booting got a notice:
>=20
> gpart: arg0 'ufs/rootfs': Invalid argument
>=20
> Showing some context:
>=20
> . . .
> Setting hostuuid: 30303031-3030-3030-3265-373238346338.
> Setting hostid: 0xd2f9b0de.
> Starting file system checks:
> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ufs/rootfs: clean, 498385 free (1281 frags, 62138 blocks, 0.1% fragm=
entation)
> Growing root partition to fill device
> random: randomdev_wait_until_seeded unblock wait
> random: randomdev_wait_until_seeded unblock wait
> random: unblocking device.
> GEOM_PART: da0s2 was automatically resized.
>   Use `gpart commit da0s2` to save changes or `gpart undo da0s2` to rever=
t them.
> da0s2 resized
> da0s2a resized
> gpart: arg0 'ufs/rootfs': Invalid argument
> super-block backups (for fsck_ffs -b #) at:
> . . .=20
>=20
> It looks like the line in question in /etc/rc.d/growfs is:
>=20
>         gpart commit "$rootdev"
>=20
> where the prior code:
>=20
>         FSTYPE=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}')
>         FSDEV=3D$(mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}')
>         case "$FSTYPE" in
>         ufs)
>                 rootdev=3D${FSDEV#/dev/}
>                 ;;
>=20
> assigned rootdev based on:
>=20
> For FSTYPE:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $3 }}'
> ufs
>=20
> For FSDEV:
> # mount -p | awk '{ if ( $2 =3D=3D "/") { print $1 }}'
> /dev/ufs/rootfs
>=20
> So: ufs/rootfs
>=20
> I'd guess that the problem is that after the gpart resize -i . . .
> activities the label ufs/rootfs is no longer effective for
> gpart (until the growfs -y completes?).
>=20
> Whatever the cause, gpart is rejecting the ufs/rootfs
> notation.
>=20
>=20
>=20
> Issue #1 (unsure of the intent, so checking):
>=20
> # gpart show
> =3D>       63  468862065  da0  MBR  (224G)
>          63       1985       - free -  (993K)
>        2048     102400    1  fat32lba  [active]  (50M)
>      104448  468757680    2  freebsd  (224G)
>=20
> =3D>        0  468757680  da0s2  BSD  (224G)
>           0        128         - free -  (64K)
>         128  468757552      1  freebsd-ufs  (224G)
>=20
> Reviewing the alignments (one is differently
> aligned than the others):
>=20
> The first is good:
>=20
>        2048     102400    1  fat32lba  [active]  (50M)
>=20
> aligns to 512*2048 =3D=3D 1 MiByte.
>=20
> The second is likely good:
>=20
>      104448  468757680    2  freebsd  (224G)
>=20
> aligns to 512*104448 =3D=3D 51 MiByte, so a 1 MiByte multiple
> as the alignment.
>=20
> But the 3rd is less aligned (the freebsd-ufs line):
>=20
>      104448  468757680    2  freebsd  (224G)
>=20
> =3D>        0  468757680  da0s2  BSD  (224G)
>           0        128         - free -  (64K)
>         128  468757552      1  freebsd-ufs  (224G)
>=20
> aligns to 512*104448 + 512*128 but 512*128 is a
> 64 KiByte offset, so: 51 MiByte + 64 KiByte.
>=20
> This is not 1 MiByte aligned but is 64 KiByte aligned.
> Is that the intended alignment for the freebsd-ufs
> area?
>=20

I am going to have to defer to our resident experts on this, to be
honest.

Glen


--94oXV8jP6EZ84voN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmNNtKEACgkQAxRYpUeP
4pNyuA//Yi4U4DaanQ+Cy0bjokWq4bTuWiElYWemOVE99ybgI7rF5s4mfwHc9Ut6
IN5t/WygnZqn6bUYzR/J2JBcbvFPmHeHxKEWZhcXj87OlOmnd1BVRgnKRoOlzgc/
zzmiL/LS1BjZ5VL1fQtUH21SaI5A+LDbW5t7PiwfGTDisROXo+N66mIM8XZeV3jM
QP7mOC4fkOKXBQIVz7wgCK99jti8RCWZn+Vw6/nks/OJmP/AzYXOKagYZug4bjBa
QUPZBRb6XHyIXmDT/m+A6hD3C9niPtfcqpvrGePf73MylMj7UCmKNhF+xc6Xm9Wa
Ox4Qu3WcxmCFBrQ55xsdOn2BVD+QwGPH0yLVwEvGoof1oSWy2R0VpjGz5G/76iYD
YN+CPC18wr/mxwnYegqH4qHeNY4KMcI62TxgT0VpRyuvw0wJkTPam/s5kW57MthF
hATlf0guQAnhiXUfy7gOHado8BRvizVHDbB+sn8JK9chGJstg5moUXs2Q8RjyMPb
Fpt/N4fPeg/cYzsrs3DC8U58D/vXNR5Cz0/TjuFxlJqR8ltGFXUA/XorEB6ogcZE
RC5nv+ZSN6W6zOn1grTY/5aqBufZLxSqDeTvo89DVpzEFvDhUozfpZCJm4MLbqaG
r11L9FThWGEoCH8yQwaQktmyffb8RETW+ddoMxPZsFnBzzeTTGw=
=wX0q
-----END PGP SIGNATURE-----

--94oXV8jP6EZ84voN--

From nobody Tue Oct 18 16:53:33 2022
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 4MsKgm259Bz4gCPm
	for ; Tue, 18 Oct 2022 16:53:40 +0000 (UTC)
	(envelope-from kp@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 4MsKgm1LJDz3Zs6;
	Tue, 18 Oct 2022 16:53:40 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666112020;
	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=4frahW08Evz+y5k0ZuzYFR+AibHT5Ys8rRSYJgOdWjI=;
	b=wSW4p+Pdzv3/w10PcHnVBdq1eNB5U1DdcbR8wnG4QeBASUPQhPWaD6dNdIT9XpxHLWEn3Y
	0hl5+yDUWc4PkBThOOwD15f1fJ8JpJ0t/DYR71QHDkPNW6Wir+zxcWMO7/hIi/vmlQktib
	C7hUnY9DVY2Kn/VQkZVqJMV6K4X08pIt+erZA1SzyR1/NoMutX5/jnCMmRp4bSftTcJ1lJ
	iw+ckvrGXfAo1l3bwy15qEN0seLYBgA21lCs9AxuZldFo5CuM9ToYAVKT7k6ddvEPbGrcT
	v4cLUJHN2ORfGCNaaVXHZmJ09FzitfWiQ8sf8/4ETU3iwQiBxVDh+iQQcs2KHQ==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(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 "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MsKgl6H9wz1ZRW;
	Tue, 18 Oct 2022 16:53:39 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 80BBF2EEB2;
	Tue, 18 Oct 2022 18:53:37 +0200 (CEST)
From: Kristof Provost 
To: freebsd-arm , Brooks Davis 
Subject: Running armv7 on aarch64
Date: Tue, 18 Oct 2022 18:53:33 +0200
X-Mailer: MailMate (1.14r5918)
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: multipart/alternative;
 boundary="=_MailMate_1613E232-936B-41AA-95D4-FA7ACBD60BA6_="
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666112020;
	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=4frahW08Evz+y5k0ZuzYFR+AibHT5Ys8rRSYJgOdWjI=;
	b=TQIC4EX9l7/Z+BA/1BnuV+C0/1bEQwXdMNt2N0ybTPtPXXiAQ17StNCSBOISE/VOtU1VKT
	Hz03pSjZnKh0aV7sWV45snfSS3ix94wLu03KRWrqpIp5pcf0Fcy6pKu+SZVTUlhTfNVuvY
	xlXi6L+iTXk6CkQ3BZ+S+csu7eAD2OEfzKPaZZzFo+GnGG4xaaLuxXA3gWsZWqiFjdfXaW
	81guo96ubgm8NqClfTYCatjy9tOyTHE7EVdBMqjXmn2h8t6gT1Ft6iblKyPRWzlKRpPIR5
	rJrGeT1lhT9owS0V8+yIxI+X1gLv0RyTJFajbO3hvAwJbiyYZbVNicekXIG6/A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666112020; a=rsa-sha256; cv=none;
	b=CrZp7HRoawTUCqf5FLdD94HjjRMZk258xAAQp1BFNz9q+jJp51ZMdk239GHaJpf8ujAA4i
	+nbNM82mCZ7bf9enZqLrdI7OUiMekl2641pMx1jLZwSN+oSESaxrNOa4AyV+am49LgmHcA
	UsmorZbz0tZxWXczQnGUr+rYmEL8wMnNzoqJ+qpqJRLe3jl8VT2o5NhvEGW7Fs6doPVJzS
	HWVQaojzcrNW8+Q1IUI6rTtfs++/ny8Rq4NV1Vb9vfgFgnl0U7zOSQSSMLzGafDM3261wJ
	BP6H5X81BIMrdjkDOdNzArr9EQ/Wx0wU5Tu8VTStuq+UEMW600aJL9nyzoFKsw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--=_MailMate_1613E232-936B-41AA-95D4-FA7ACBD60BA6_=
Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit

Hi,

I’ve recently discovered that I can no longer run an armv7 binary on 
my aarch64 FreeBSD machine.

	$ /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
	ELF binary type "9" not known.
	/bin/sh: 
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id: 
Exec format error
	$ file 
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
	/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id: 
ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically 
linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 
14.0 (1400066), stripped
	$ readelf -e 
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id

	File: 
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
	ELF Header:
	  Magic:   7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00
	  Class:                             ELF32
	  Data:                              2's complement, little endian
	  Version:                           1 (current)
	  OS/ABI:                            FreeBSD
	  ABI Version:                       0
	  Type:                              EXEC (Executable file)
	  Machine:                           ARM
	  Version:                           0x1
	  Entry point address:               0x20ef0
	  Start of program headers:          52 (bytes into file)
	  Start of section headers:          8912 (bytes into file)
	  Flags:                             0x5000400, Version5 EABI, VFP
	  Size of this header:               52 (bytes)
	  Size of program headers:           32 (bytes)
	  Number of program headers:         11
	  Size of section headers:           40 (bytes)
	  Number of section headers:         28
	  Section header string table index: 27

	Elf file type is EXEC (Executable file)
	Entry point 0x20ef0
	There are 11 program headers, starting at offset 52

	Program Headers:
	  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg 
Align
	  PHDR           0x000034 0x00010034 0x00010034 0x00160 0x00160 R   0x4
	  INTERP         0x000194 0x00010194 0x00010194 0x00015 0x00015 R   0x1
	      [Requesting program interpreter: /libexec/ld-elf.so.1]
	  LOAD           0x000000 0x00010000 0x00010000 0x00ccc 0x00ccc R   
0x10000
	  LOAD           0x000ccc 0x00020ccc 0x00020ccc 0x01294 0x01294 R E 
0x10000
	  LOAD           0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 RW  
0x10000
	  LOAD           0x002028 0x00042028 0x00042028 0x000a0 0x00138 RW  
0x10000
	  DYNAMIC        0x001f68 0x00031f68 0x00031f68 0x000c0 0x000c0 RW  0x4
	  GNU_RELRO      0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 R   0x1
	  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
	  NOTE           0x0001ac 0x000101ac 0x000101ac 0x00064 0x00064 R   0x4
	  ARM_EXIDX      0x00090c 0x0001090c 0x0001090c 0x00068 0x00068 R   0x4

	 Section to Segment mapping:
	  Segment Sections...
	   00
	   01     .interp
	   02     .interp .note.tag .dynsym .gnu.version .gnu.version_r 
.gnu.hash .hash .dynstr .rel.dyn .ARM.exidx .rel.plt .rodata .ARM.extab
	   03     .text .init .fini .plt
	   04     .jcr .init_array .dynamic
	   05     .data .got.plt .bss
	   06     .dynamic
	   07     .jcr .init_array .dynamic
	   08
	   09     .note.tag
	   10     .ARM.exidx
	There are 28 section headers, starting at offset 0x22d0:

	Section Headers:
	  [Nr] Name              Type            Addr     Off    Size   ES Flg 
Lk Inf Al
	  [ 0]                   NULL            00000000 000000 000000 00      
0   0  0
	  [ 1] .interp           PROGBITS        00010194 000194 000015 00   A  
0   0  1
	  [ 2] .note.tag         NOTE            000101ac 0001ac 000064 00   A  
0   0  4
	  [ 3] .dynsym           DYNSYM          00010210 000210 0002c0 10   A  
8   1  4
	  [ 4] .gnu.version      SUNW_versym     000104d0 0004d0 000058 02   A  
3   0  2
	  [ 5] .gnu.version_r    SUNW_verneed    00010528 000528 000050 00   A  
8   2  4
	  [ 6] .gnu.hash         GNU_HASH        00010578 000578 000030 00   A  
3   0  4
	  [ 7] .hash             HASH            000105a8 0005a8 000168 04   A  
3   0  4
	  [ 8] .dynstr           STRTAB          00010710 000710 0001e3 00   A  
0   0  1
	  [ 9] .rel.dyn          REL             000108f4 0008f4 000018 08  AI  
3   0  4
	  [10] .ARM.exidx        ARM_EXIDX       0001090c 00090c 000068 00   A 
14   0  4
	  [11] .rel.plt          REL             00010974 000974 000120 08  AI  
3  22  4
	  [12] .rodata           PROGBITS        00010a94 000a94 00021f 01 AMS  
0   0  1
	  [13] .ARM.extab        PROGBITS        00010cb4 000cb4 000018 00   A  
0   0  4
	  [14] .text             PROGBITS        00020ccc 000ccc 000ff0 00  AX  
0   0  4
	  [15] .init             PROGBITS        00021cc0 001cc0 000014 00  AX  
0   0 16
	  [16] .fini             PROGBITS        00021ce0 001ce0 000014 00  AX  
0   0 16
	  [17] .plt              PROGBITS        00021d00 001d00 000260 00  AX  
0   0 16
	  [18] .jcr              PROGBITS        00031f60 001f60 000004 00  WA  
0   0  4
	  [19] .init_array       INIT_ARRAY      00031f64 001f64 000004 00  WA  
0   0  4
	  [20] .dynamic          DYNAMIC         00031f68 001f68 0000c0 08  WA  
8   0  4
	  [21] .data             PROGBITS        00042028 002028 000004 00  WA  
0   0  4
	  [22] .got.plt          PROGBITS        0004202c 00202c 00009c 00  WA  
0   0  4
	  [23] .bss              NOBITS          00042100 0020c8 000060 00  WA  
0   0 64
	  [24] .comment          PROGBITS        00000000 0020c8 0000b6 01  MS  
0   0  1
	  [25] .ARM.attributes   ARM_ATTRIBUTES  00000000 00217e 000049 00      
0   0  1
	  [26] .gnu_debuglink    PROGBITS        00000000 0021c7 000010 00      
0   0  1
	  [27] .shstrtab         STRTAB          00000000 0021d7 0000f7 00      
0   0  1
	Key to Flags:
	  W (write), A (alloc), X (execute), M (merge), S (strings)
	  I (info), L (link order), G (group), x (unknown)
	  O (extra OS processing required) o (OS specific), p (processor 
specific)

It’s not quite clear to me how this is supposed to work (now). On 
amd64 there’s a separate /libexec/ld-elf32.so.1, which we don’t have 
on aarch64. Is it supposed to be built?

It’s broken on ab9293239c7d and e03b7883e97c at the very least.

—
Kristof
--=_MailMate_1613E232-936B-41AA-95D4-FA7ACBD60BA6_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable









Hi,


I=E2=80=99ve recently discovered that I can no longer run=
 an armv7 binary on my aarch64 FreeBSD machine.


$ =
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
ELF binary type "9" not known.
/bin/sh: /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin=
/id: Exec format error
$ file /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/i=
d
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id: ELF =
32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked=
, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD 14.0 (1400=
066), stripped
$ readelf -e /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr=
/bin/id

File: /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id=

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            FreeBSD
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x20ef0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          8912 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, VFP
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         11
  Size of section headers:           40 (bytes)
  Number of section headers:         28
  Section header string table index: 27

Elf file type is EXEC (Executable file)
Entry point 0x20ef0
There are 11 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align=

  PHDR           0x000034 0x00010034 0x00010034 0x00160 0x00160 R   0x4
  INTERP         0x000194 0x00010194 0x00010194 0x00015 0x00015 R   0x1
      [Requesting program interpreter: /libexec/ld-elf.so.1]
  LOAD           0x000000 0x00010000 0x00010000 0x00ccc 0x00ccc R   0x100=
00
  LOAD           0x000ccc 0x00020ccc 0x00020ccc 0x01294 0x01294 R E 0x100=
00
  LOAD           0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 RW  0x100=
00
  LOAD           0x002028 0x00042028 0x00042028 0x000a0 0x00138 RW  0x100=
00
  DYNAMIC        0x001f68 0x00031f68 0x00031f68 0x000c0 0x000c0 RW  0x4
  GNU_RELRO      0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 R   0x1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
  NOTE           0x0001ac 0x000101ac 0x000101ac 0x00064 0x00064 R   0x4
  ARM_EXIDX      0x00090c 0x0001090c 0x0001090c 0x00068 0x00068 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.tag .dynsym .gnu.version .gnu.version_r .gnu.hash=
 .hash .dynstr .rel.dyn .ARM.exidx .rel.plt .rodata .ARM.extab
   03     .text .init .fini .plt
   04     .jcr .init_array .dynamic
   05     .data .got.plt .bss
   06     .dynamic
   07     .jcr .init_array .dynamic
   08
   09     .note.tag
   10     .ARM.exidx
There are 28 section headers, starting at offset 0x22d0:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk=
 Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0=
   0  0
  [ 1] .interp           PROGBITS        00010194 000194 000015 00   A  0=
   0  1
  [ 2] .note.tag         NOTE            000101ac 0001ac 000064 00   A  0=
   0  4
  [ 3] .dynsym           DYNSYM          00010210 000210 0002c0 10   A  8=
   1  4
  [ 4] .gnu.version      SUNW_versym     000104d0 0004d0 000058 02   A  3=
   0  2
  [ 5] .gnu.version_r    SUNW_verneed    00010528 000528 000050 00   A  8=
   2  4
  [ 6] .gnu.hash         GNU_HASH        00010578 000578 000030 00   A  3=
   0  4
  [ 7] .hash             HASH            000105a8 0005a8 000168 04   A  3=
   0  4
  [ 8] .dynstr           STRTAB          00010710 000710 0001e3 00   A  0=
   0  1
  [ 9] .rel.dyn          REL             000108f4 0008f4 000018 08  AI  3=
   0  4
  [10] .ARM.exidx        ARM_EXIDX       0001090c 00090c 000068 00   A 14=
   0  4
  [11] .rel.plt          REL             00010974 000974 000120 08  AI  3=
  22  4
  [12] .rodata           PROGBITS        00010a94 000a94 00021f 01 AMS  0=
   0  1
  [13] .ARM.extab        PROGBITS        00010cb4 000cb4 000018 00   A  0=
   0  4
  [14] .text             PROGBITS        00020ccc 000ccc 000ff0 00  AX  0=
   0  4
  [15] .init             PROGBITS        00021cc0 001cc0 000014 00  AX  0=
   0 16
  [16] .fini             PROGBITS        00021ce0 001ce0 000014 00  AX  0=
   0 16
  [17] .plt              PROGBITS        00021d00 001d00 000260 00  AX  0=
   0 16
  [18] .jcr              PROGBITS        00031f60 001f60 000004 00  WA  0=
   0  4
  [19] .init_array       INIT_ARRAY      00031f64 001f64 000004 00  WA  0=
   0  4
  [20] .dynamic          DYNAMIC         00031f68 001f68 0000c0 08  WA  8=
   0  4
  [21] .data             PROGBITS        00042028 002028 000004 00  WA  0=
   0  4
  [22] .got.plt          PROGBITS        0004202c 00202c 00009c 00  WA  0=
   0  4
  [23] .bss              NOBITS          00042100 0020c8 000060 00  WA  0=
   0 64
  [24] .comment          PROGBITS        00000000 0020c8 0000b6 01  MS  0=
   0  1
  [25] .ARM.attributes   ARM_ATTRIBUTES  00000000 00217e 000049 00      0=
   0  1
  [26] .gnu_debuglink    PROGBITS        00000000 0021c7 000010 00      0=
   0  1
  [27] .shstrtab         STRTAB          00000000 0021d7 0000f7 00      0=
   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific=
)



It=E2=80=99s not quite clear to me how this is supposed t=
o work (now). On amd64 there=E2=80=99s a separate /libexec/ld-elf32.so.1,=
 which we don=E2=80=99t have on aarch64. Is it supposed to be built?


It=E2=80=99s broken on ab9293239c7d and e03b7883e97c at t=
he very least.


=E2=80=94

Kristof










--=_MailMate_1613E232-936B-41AA-95D4-FA7ACBD60BA6_=--

From nobody Tue Oct 18 17:38:41 2022
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 4MsLgr3xGwz4gHsD
	for ; Tue, 18 Oct 2022 17:38:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4MsLgq2nFZz3cr6
	for ; Tue, 18 Oct 2022 17:38:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666114725; bh=U6xpY4q7LSkJzZ9M1sa/XCKpMCdW3uOec3K2jyNwM8M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eu3XO6AROt1UVfUlIJFOv9MUSrX0Gs24IGoRh3BncZ64wp8DBRpYSoDTreAbshTP8jgbzpLfGM4sMoIM/dgzXaCluWUF9XfI8N3t1blEDbmwSQkMgwRIwVuqX14k5hWlWGr2Xqhj0uxc6z8CG0WdP6pbbRemFASniyI8+UkkrPsHupOd/7hLgDwod/I6DgCly5o0BpFtt0LbczNbVQWCfGt82gk0xl35z1xaeNvbnaeVVteo5NFXPjweusR49WpAvPhx981T8CWmz5d+WtPMfBFfaFQE93PFJrsqKUofmgrgWY38HRKJeVFrgo9PwyXSB4ZBi4dP1YIeWvIh3OEdKg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666114725; bh=8jmKM/WFZWojJgJP8wlrCoiJSbaofiNRIk0za67EmFr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bM4hS4X4VZU0krwTL99tn+j1qo09O5zlN442OnZVjznpRopswG+sJ9wPHi3DMgivkgaVu9pfT+azygmj0rL1yFiy0uPNF5TpYugW9PkyGVXLVEP+0UY7n6zVCufvv10ShvaHJ7D+S1NqHFHdCYhSUhPagEVM9ii3rv7+foGYzsx4d5G5otv0GDBCKVQMKheLoYR7+Kx4MdzhYMuFnyWQZh6EYvc1ijHFwdE8nsErsQfLSTVH9GamHuKWQRTKwxSYe7velDd3KwWt/9fii4GNvqVlz8X0B0tZF+Ccr3ex5bJMsMt/xjyIJ5JS3htcRmuhSsJVcFBZp9aAExD3lfW3hw==
X-YMail-OSG: G32cs_8VM1kfwkUwqFnVbe3vIl2Yjji7ymoEMcwCzzkOszpaZgLnAABcGHX3R5p
 3Ii9shBEqK5uxaRMkUNjyZsJLjcjxFXKFV8FTzU52FNYVjH07bj4aISIUBfLrMMTq2aOrEFSToIt
 Lxl8NEaqP7Rh9nTtpahCq8K.xWE94YUwuV5wdOMH7qFD5VOwn_mDw8j1rf6LEpO3wjbydSb1gM4R
 tP8T_4uYHRNleRC96WB3.v_VNkXQ_1VNODmpBT1UAtnSwhZfmtW33N6J.NrcC8FmVsTU8BjSLXPy
 dVX50QVB_8Q3ZU7O.biBoYRcBFe7otwx2PqapYDoOATHddG_3TFQ0ON4YVXYvqmFF7057msOlaL3
 c8QAMXvOIQl9xCTtCxbKrBrHe1N29oHsOHNKcfOcqFJOO2mvqB0tW8qXlu5KfDheNSFraAO5d8_i
 n0z8gX8LXtfB09XBWM8LbODERKmPU4cI4scyzgpAAE929MLrxp73yeq.1GvCjM8PBCy4xluUdvHy
 r4wkJlugSrxQ2hyMPDBA8loDiwP2mMctQGhEQBqvwyp1OrYJj3Rs3pAWnBfE2ICAquWucVKF4v_h
 ncSq8GFmnj2_l42HvjCuK5sXYW_7lZ2u_XhWw0AyOghiivjpCm.HMljQvrqzo1f8.IUjBdAL1XDm
 o__Jl0RLrj_EosckxdidY6kTReWQF4fseAntW7JYM.3KOyHn4T_s0_RT1Ih6ExyxrGOrpqkyC05G
 5a.l6_P59e0A2GztGHY54jaxsrTun3y412WtXqIbQ7ASNUaS3Mlg3T6OMEh39PrunDI53J0iUeMl
 zg5XM1P_eKb9e2D7uIOUY_JHOD5Ls2tIZgEy2h3uBdu30BU3EY3vM8ZsVltatY0GRsOSb_Gla9c8
 HJjlJd_GL5GH1wMFvHClmXcG2p_W3lbRPSmFR6Bnfqr5TUS_2VMBpsd8Rd.jm3N_vldBEoLCCzJd
 TgpeRbENS9F2u6NmnwTFri17PGFV5XH.oi_yC0erdBjTZxqVtgY614G9.mn5_wJlQuH6niHuk_vz
 qAIr1Nm0.2fU1Hineb3TtT.gJPSk1zm7KdqmoQI70uvhFXESy1OG_0AcQFN4.rIlFvx.Y7JNR3pv
 ECh0t.6L5lg1DQ4sROuIC07X3CBnOvpSfThpqoPlBriRbpIxuzJsh4iTroPq4wk7L3M3e5gqi0Sn
 D5dLuAeUhWn7hPvHC17dEJERRpSRqUXjy_gS_cknN8tLqHjo7_5G8mVQRO5D6rsbrFGcr1U7O3sD
 9Jug4jIP5DuLFZ3PY76rZcygT2ViB.ai1RztrRYa.b1opeHeX7cxnLhxO7waadgak_Cron5CJtMx
 KVwLVfD8MLlmvZR9E9LaVeU0owdd3NeGcr77jKYDcY8_IS416Svvr3n9IsLT3l2Ts8aDQ2JSd_8q
 uh1jQehsZWiHJfyfXRmt5TVi1X0o1Nk2i9IMaYgmr26McJYBxxdUkOpqvYKeYAvY2k8IwLTVYooD
 otf2nCpGeJuAW79lgTnZTno5F2Cdjbgq9uawZEAIqjCWFgZH2A83Egx2bkk5wkDf2FK7n7dZULOy
 pB2DPrr6D4cUzQY_Y_zSDD5PA3DWMs1j_hmj.4xJtqGXZYa1XqU6bd.aUCbse22rKA6SknsgJ_d0
 TeJQxL_fOd_xleDj4q0ckpoGaUxzeY2EReOa5OlDRU4Ikynf_kOAJZgZ8zOtwIEPYlr12Lm7XktJ
 o0s7qCqDfzW6.mQULEWK4pquAOuJyouFmEmiqpRU2utdIEswlPLhAyyVFC9.tTgAZQRgFE4cqGTG
 epS1lBG35HP7d.gqdnueMHBeIpwnEA3j1k7yuQS9ObCX7pgJxifHj7F0hUzHhMAR3NtEMleZxDs.
 lquFL.1ELZ3Y6AsTQcLfKwcg5HZXSf844RjVhzl2sFDMY5W4fMqXQhtfGirVaDffopcMZv_5ArA3
 99GrRYMyVTdkCxoTgL85rY2RWOVEA2gfLs6RoMHdegkGz0J5Us1K9oG3ysoJJoWaC.TLWeiB5_i6
 LisFOEKcJD5Svyccm8rl_SUp8ZwjCBJZvIhE8A.zUO_5wNEi4NjvazPLcsnCTxdWFCav1_Q4scAj
 oLpNYtCGIToPya_XFEJZ0n4S2r87JNaRtMB.PzPx3sn.ej0v1CxMY5yMnp5V1HAvedXI2l2Z2hE9
 VPnt03W4f1FByYjyAqE5tzJoGLLyiMM6xzo.qp5_Np4qBrQuXCT59zjLiEe5rSL8JMexoRxEe9O_
 cSVVfiorgITrIWCn9FD9561oichMPcLWTghow7qhdjN1yePyJBhptnMLDBxXCy_aDwYZkgWszr53
 4rQSE1dc-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Oct 2022 17:38:45 +0000
Received: by hermes--production-ne1-5db649d989-kp8mg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3d2c83cf779aec0a1e4010f17f44c2fe;
          Tue, 18 Oct 2022 17:38:43 +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 \(3696.120.41.1.1\))
Subject: Re: Running armv7 on aarch64
From: Mark Millard 
In-Reply-To: 
Date: Tue, 18 Oct 2022 10:38:41 -0700
Cc: freebsd-arm ,
 Brooks Davis 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CA3B1F4-46CB-4C75-8451-AF2CA4E9F74B@yahoo.com>
References: 
To: Kristof Provost 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MsLgq2nFZz3cr6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=eu3XO6AR;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-18, at 09:53, Kristof Provost  wrote:

> I=E2=80=99ve recently discovered that I can no longer run an armv7 =
binary on my aarch64 FreeBSD machine.
>=20
> $ /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
> ELF binary type "9" not known.
> /bin/sh: =
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id: =
Exec format error
> $ file =
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
> /usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id: =
ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically =
linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for FreeBSD =
14.0 (1400066), stripped
> $ readelf -e =
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
>=20
> File: =
/usr/local/poudriere/jails/pfSense_plus-devel-main_armv7/usr/bin/id
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            FreeBSD
>   ABI Version:                       0
>   Type:                              EXEC (Executable file)
>   Machine:                           ARM
>   Version:                           0x1
>   Entry point address:               0x20ef0
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          8912 (bytes into file)
>   Flags:                             0x5000400, Version5 EABI, VFP
>   Size of this header:               52 (bytes)
>   Size of program headers:           32 (bytes)
>   Number of program headers:         11
>   Size of section headers:           40 (bytes)
>   Number of section headers:         28
>   Section header string table index: 27
>=20
> Elf file type is EXEC (Executable file)
> Entry point 0x20ef0
> There are 11 program headers, starting at offset 52
>=20
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg =
Align
>   PHDR           0x000034 0x00010034 0x00010034 0x00160 0x00160 R   =
0x4
>   INTERP         0x000194 0x00010194 0x00010194 0x00015 0x00015 R   =
0x1
>       [Requesting program interpreter: /libexec/ld-elf.so.1]
>   LOAD           0x000000 0x00010000 0x00010000 0x00ccc 0x00ccc R   =
0x10000
>   LOAD           0x000ccc 0x00020ccc 0x00020ccc 0x01294 0x01294 R E =
0x10000
>   LOAD           0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 RW  =
0x10000
>   LOAD           0x002028 0x00042028 0x00042028 0x000a0 0x00138 RW  =
0x10000
>   DYNAMIC        0x001f68 0x00031f68 0x00031f68 0x000c0 0x000c0 RW  =
0x4
>   GNU_RELRO      0x001f60 0x00031f60 0x00031f60 0x000c8 0x000c8 R   =
0x1
>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
>   NOTE           0x0001ac 0x000101ac 0x000101ac 0x00064 0x00064 R   =
0x4
>   ARM_EXIDX      0x00090c 0x0001090c 0x0001090c 0x00068 0x00068 R   =
0x4
>=20
>  Section to Segment mapping:
>   Segment Sections...
>    00
>    01     .interp
>    02     .interp .note.tag .dynsym .gnu.version .gnu.version_r =
.gnu.hash .hash .dynstr .rel.dyn .ARM.exidx .rel.plt .rodata .ARM.extab
>    03     .text .init .fini .plt
>    04     .jcr .init_array .dynamic
>    05     .data .got.plt .bss
>    06     .dynamic
>    07     .jcr .init_array .dynamic
>    08
>    09     .note.tag
>    10     .ARM.exidx
> There are 28 section headers, starting at offset 0x22d0:
>=20
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg =
Lk Inf Al
>   [ 0]                   NULL            00000000 000000 000000 00     =
 0   0  0
>   [ 1] .interp           PROGBITS        00010194 000194 000015 00   A =
 0   0  1
>   [ 2] .note.tag         NOTE            000101ac 0001ac 000064 00   A =
 0   0  4
>   [ 3] .dynsym           DYNSYM          00010210 000210 0002c0 10   A =
 8   1  4
>   [ 4] .gnu.version      SUNW_versym     000104d0 0004d0 000058 02   A =
 3   0  2
>   [ 5] .gnu.version_r    SUNW_verneed    00010528 000528 000050 00   A =
 8   2  4
>   [ 6] .gnu.hash         GNU_HASH        00010578 000578 000030 00   A =
 3   0  4
>   [ 7] .hash             HASH            000105a8 0005a8 000168 04   A =
 3   0  4
>   [ 8] .dynstr           STRTAB          00010710 000710 0001e3 00   A =
 0   0  1
>   [ 9] .rel.dyn          REL             000108f4 0008f4 000018 08  AI =
 3   0  4
>   [10] .ARM.exidx        ARM_EXIDX       0001090c 00090c 000068 00   A =
14   0  4
>   [11] .rel.plt          REL             00010974 000974 000120 08  AI =
 3  22  4
>   [12] .rodata           PROGBITS        00010a94 000a94 00021f 01 AMS =
 0   0  1
>   [13] .ARM.extab        PROGBITS        00010cb4 000cb4 000018 00   A =
 0   0  4
>   [14] .text             PROGBITS        00020ccc 000ccc 000ff0 00  AX =
 0   0  4
>   [15] .init             PROGBITS        00021cc0 001cc0 000014 00  AX =
 0   0 16
>   [16] .fini             PROGBITS        00021ce0 001ce0 000014 00  AX =
 0   0 16
>   [17] .plt              PROGBITS        00021d00 001d00 000260 00  AX =
 0   0 16
>   [18] .jcr              PROGBITS        00031f60 001f60 000004 00  WA =
 0   0  4
>   [19] .init_array       INIT_ARRAY      00031f64 001f64 000004 00  WA =
 0   0  4
>   [20] .dynamic          DYNAMIC         00031f68 001f68 0000c0 08  WA =
 8   0  4
>   [21] .data             PROGBITS        00042028 002028 000004 00  WA =
 0   0  4
>   [22] .got.plt          PROGBITS        0004202c 00202c 00009c 00  WA =
 0   0  4
>   [23] .bss              NOBITS          00042100 0020c8 000060 00  WA =
 0   0 64
>   [24] .comment          PROGBITS        00000000 0020c8 0000b6 01  MS =
 0   0  1
>   [25] .ARM.attributes   ARM_ATTRIBUTES  00000000 00217e 000049 00     =
 0   0  1
>   [26] .gnu_debuglink    PROGBITS        00000000 0021c7 000010 00     =
 0   0  1
>   [27] .shstrtab         STRTAB          00000000 0021d7 0000f7 00     =
 0   0  1
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings)
>   I (info), L (link order), G (group), x (unknown)
>   O (extra OS processing required) o (OS specific), p (processor =
specific)
>=20
> It=E2=80=99s not quite clear to me how this is supposed to work (now). =
On amd64 there=E2=80=99s a separate /libexec/ld-elf32.so.1, which we =
don=E2=80=99t have on aarch64. Is it supposed to be built?
>=20
> It=E2=80=99s broken on ab9293239c7d and e03b7883e97c at the very =
least.

[I'm ignoring qemu, which I do not use. The below is from
a Cortex-A72 aarch64 context that can execute Cortex-A7
armv7 code as well. Have you been using qemu?]

Historically I've only been able to execute armv7 FreeBSD
code on aarch64 FreeBSD via using the likes of, say,
chroot'ing into an installed armv7 world in a directory
tree that I created for such. (I manually split some
liong-lineouptut for readabilty.)

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #63
main-n258610-ba7319e9091b-dirty: Fri Oct 14 14:29:14 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400072 1400072

# chroot /usr/obj/DESTDIRs/main-CA7-chroot/

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #63
main-n258610-ba7319e9091b-dirty: Fri Oct 14 14:29:14 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm armv7 1400072 1400072

# which date
/bin/date

# file /bin/date
/bin/date: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), =
dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for =
FreeBSD 14.0 (1400072), not stripped

# date
Tue Oct 18 17:28:13 UTC 2022


Direct execution attempts from an aarch64 world without such a
chroot (or equivalent for the purpose) to a armv7 world have
always produced the likes of:

# /usr/obj/DESTDIRs/main-CA7-chroot/bin/date
ELF interpreter /libexec/ld-elf.so.1 not found, error 8
Abort trap



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 18 18:18:03 2022
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 4MsMYB1cdPz4f7GK
	for ; Tue, 18 Oct 2022 18:18:06 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4MsMYB14b7z3fyJ;
	Tue, 18 Oct 2022 18:18:06 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666117086;
	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=5+NSGs1eFV3qIkt++hxTqwOspM5MIM5aXHJkkueQ244=;
	b=QcMcVuwZ9WV+tI6kKvm3PF4JBWQl0fYkoi9nEPK27R1kPCNqI6kgeH6xgnYYAYip1lyvuY
	MD0zRN6S3x03df/V2bnhdVPccKhr2VFvKzrj6bZX9uBPKjSeAgEAfKnHgX6E62lwNupsnF
	HS9iXSOr19nQR7bDG+PT3Y1YBuUpVeHG6uJxbZbdFNqxU89WRUVFNTdJWMrXmTAXslZl+z
	Oi55hBBVVf+sVa0kpnghuOohA7iuGZ8dpJ8EPQ6R8i7SXSzP1LqQ6k80Q0WnGtgEdLijgt
	ygggeqIGSv/zQV1pef9teI/pqkwxr/2shzlkpunUrvPhtPx4njcbRhmOm+MuOw==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(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 "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MsMY96NLhz1Z9Z;
	Tue, 18 Oct 2022 18:18:05 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 143E630023;
	Tue, 18 Oct 2022 20:18:04 +0200 (CEST)
From: Kristof Provost 
To: Mark Millard 
Cc: freebsd-arm , Brooks Davis 
Subject: Re: Running armv7 on aarch64
Date: Tue, 18 Oct 2022 20:18:03 +0200
X-Mailer: MailMate (1.14r5918)
Message-ID: 
In-Reply-To: <3CA3B1F4-46CB-4C75-8451-AF2CA4E9F74B@yahoo.com>
References: 
 <3CA3B1F4-46CB-4C75-8451-AF2CA4E9F74B@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: multipart/alternative;
 boundary="=_MailMate_B232686B-A96C-4E90-A8C5-9FD7370DC60A_="
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666117086;
	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=5+NSGs1eFV3qIkt++hxTqwOspM5MIM5aXHJkkueQ244=;
	b=kLc4iTd+veqKrkNEVIqLxR9oOWAIvreyxQeyRf1hLQbp9mi9qtIHnMx+dEHn1+veFBwcyq
	wYjKtrYwI1bZndQKGxnH6qmNGY55a9p+FQpwnEh4/wLE/CcV/t2i/kq9QkmiOJzBHZoFOV
	gQ8MlUmcqDkep2LYR8iqtLk1YXClUycomIDqSqCVvicXqgHRpsIVH8NnPUVSOUooawtfX1
	BW64OFCr9a+Gqz+mXGLJ3ibLUg+zE2i9j7mG+2Mr5Yjl6+T/+j7VJU1cCWmVfqxfaF07GV
	PELvmHaSEX61Emk1Dfz4zZDvfQGGHJmsHBS+Z3FgEbGOKbyjuSBy5IM3YVuJ6A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666117086; a=rsa-sha256; cv=none;
	b=DQS2MudZ1JVjCYA1i4jKe2dGjuVuebTN5Axf+2bB5aNLL1Q4b9QeUN1GGI8AVboXs5kJHA
	E/shKZni4G9e0Ou9Xy/vSvFDH8hs98cUamk8oO+5ZecdAEb9maiy7qFkTAWwgnf1qGT8L0
	ZEsFbhPXna4dXu3gecZ9X50QVpsiHxayAihrGNKGQWoroKpA1SqUnvHjtPskZ8lIw55Jk/
	ulnGaRrHEPtpW1bLQMhxX6AY7CP+/0zJOIhT5aa8VeyBO7kOgBwWT0k7FXXkEagU5mV9zB
	KQtM0cm1VWClIU4+LphsZ58mliq2UQAUrp9C/Tq64diGxra70FGdFunXA6Uc2g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--=_MailMate_B232686B-A96C-4E90-A8C5-9FD7370DC60A_=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 18 Oct 2022, at 19:38, Mark Millard wrote:
> On 2022-Oct-18, at 09:53, Kristof Provost  wrote:
>> It’s not quite clear to me how this is supposed to work (now). On 
>> amd64 there’s a separate /libexec/ld-elf32.so.1, which we don’t 
>> have on aarch64. Is it supposed to be built?
>>
>> It’s broken on ab9293239c7d and e03b7883e97c at the very least.
>
> [I'm ignoring qemu, which I do not use. The below is from
> a Cortex-A72 aarch64 context that can execute Cortex-A7
> armv7 code as well. Have you been using qemu?]
>
> Historically I've only been able to execute armv7 FreeBSD
> code on aarch64 FreeBSD via using the likes of, say,
> chroot'ing into an installed armv7 world in a directory
> tree that I created for such. (I manually split some
> liong-lineouptut for readabilty.)
>
Thanks for that!

That’s at least part of what I was missing. Long story short, I’m 
trying to build an armv7 image on an aarch64 machine, and having issues 
with poudriere. I figured I was going to simplify things by executing 
the armv7 binary directly (to debug), but that’s missing a few steps 
and had me chasing down the wrong track.

I can’t chroot into that armv7 jail, I still see errors like this:

	(kp@freebsd_current)  
/usr/local/poudriere/data/.m/main-pfSense_factory_ports_plus_devel/ref % 
sudo chroot .
	ELF binary type "9" not known.
	ELF binary type "9" not known.
	chroot: /bin/sh: Exec format error

But at least I think I’m looking in the correct direction now.

Best regards,
Kristof
--=_MailMate_B232686B-A96C-4E90-A8C5-9FD7370DC60A_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable









On 18 Oct 2022, at 19:38, Mark Millard wrote:


On 2022-Oct-18, at 09:53, Kristof P=
rovost <kp@FreeBSD.org> wrote:


It=E2=80=99s not quite clear to me how this is supposed to work (now)=
=2E On amd64 there=E2=80=99s a separate /libexec/ld-elf32.so.1, which we =
don=E2=80=99t have on aarch64. Is it supposed to be built?


It=E2=80=99s broken on ab9293239c7d and e03b7883e97c at t=
he very least.


[I'm ignoring qemu, which I do not use. The =
below is from


a Cortex-A72 aarch64 context that can execute Cortex-A7


armv7 code as well. Have you been using qemu?]


Historically I've only been able to execute armv7 FreeBSD=



code on aarch64 FreeBSD via using the likes of, say,


chroot'ing into an installed armv7 world in a directory


tree that I created for such. (I manually split some


liong-lineouptut for readabilty.)






Thanks for that!


That=E2=80=99s at least part of what I was missing. Long =
story short, I=E2=80=99m trying to build an armv7 image on an aarch64 mac=
hine, and having issues with poudriere. I figured I was going to simplify=
 things by executing the armv7 binary directly (to debug), but that=E2=80=
=99s missing a few steps and had me chasing down the wrong track.


I can=E2=80=99t chroot into that armv7 jail, I still see =
errors like this:


(k=
p@freebsd_current)  /usr/local/poudriere/data/.m/main-pfSense_factory_por=
ts_plus_devel/ref % sudo chroot .
ELF binary type "9" not known.
ELF binary type "9" not known.
chroot: /bin/sh: Exec format error



But at least I think I=E2=80=99m looking in the correct d=
irection now.


Best regards,

Kristof










--=_MailMate_B232686B-A96C-4E90-A8C5-9FD7370DC60A_=--

From nobody Tue Oct 18 18:36:40 2022
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 4MsMyn5XFRz4fB7q
	for ; Tue, 18 Oct 2022 18:36:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4MsMym3Xz8z3kFv
	for ; Tue, 18 Oct 2022 18:36:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666118206; bh=e+CXlWzI/6Y5In8Ju4wQpIi1iowZMA8lPhfcinjrV1c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NpuPMtXDckdmrl3ELRM0EYH6799sPOLLOK9WYZW7JgnoqCiWNwHgt5slmSMQe9FpzTBtRq/YgzpsZdP1zwJYVNjtmcdp15oP/HJ7FATDnQDG/k42Js8eqylXB65L7SeN/GOyxl+eAvfTHfrolNHMpgazeWwaOKd4inEQEM63hMshM5lsh5HwAsJlSX5HFbyxEIZLTvGBtU2M6uI3DVKZ8yb7r6CRMfAXRzgdg0AoXxn18yCapsQ6GRzSYMS6353ZcaefH7owGYXG6Yhck1xAaydSZ/m3X2dT22D9GzFhf1mHZ7PGAfyap4WMpTLoQRychj3SZbJ0LVG610Lx29rjsQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666118206; bh=gUfIjKnZ+oeixN+5zQvzlsVSa/uC2EVldcmpHpe1T0w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=be0j3BjeLDT0+1xY1wajsbkBzZswcHmj00E/GvUrAomQQq8viu5w6aOSfsTArV+BF0/Ke+Kff7OdYHST1M8H5+IKA0jAhfGwDvSodVkqwdIhOXjE034zk4U8GU7IAGB4EgzHeW+r3aFH1qCt0G3DFdK/v0qOSTuTrh7WxY9amv+eBXt9XObPMios0raLmT/LH/5HR0nkAy3v44lIEhQ2BoyBuKW28nlRo16QGYS0+xUvW1w0xVOT/kZrUDd/1WqWRchEQIYEjJ6tkyS1LlUSd634yy0YB3f3Xjs4qdMMnLBE/l74UPwfYLxnE15Dnh14xSWPaB7H4hiTFihxy/OvTw==
X-YMail-OSG: O1p8UqQVM1l4M0tcvbqLWrjOu74khlublV54Vef8N7W.O873zIWSk5Fxg1KP251
 f39cDydVHimit78KkY5.evsmCy7IMaYsRtFFwS.8yXQ5tgzSQlQq7KWyjnf9ERx4XJdfbQzydzcG
 lQdPbTlfZbSSnrSI3dMG3ZYXjyeLLyUnDV4yTNX1ws4_MhF4CDtut9vMFSt.iWwOStmEaTolfR4k
 ZOTL_qr_GyN3vxTG0CE3Crh41Y32IUiKFv86uwcLaV_8oZq.VlS_70Y44SFze4cf6Dyh7QbyOqZH
 xacPUVIh_0wxnoBbF3r3H6zIAnGUIUWN8fCSDMhyov2cmboDm0gnqmZLeK6eGfHGnc6HiXk81C79
 QT_0X07SUv_Mio1lBiP5xQJed4h.0d49YPVTmVzEgDUzHeVy97kzJ.Yypjvzm4MgUNIrWsF36Acr
 EQIWkZqHPUY8v1__Pv6QtxfGqZlRdnEc9Proe65uHwiQ.HqlYZmayP1uc.RCxoKlfzCFbR_H0Bqs
 7EabVnS30n46domb7iBh1hKa2xQwzCjNFJzq_qRl87AA51Gh0QCWgYvfgA61sIveI.a3UuKPR2LM
 3_.wEpmw0z80iHIunvUBOfcJgshb.IEWiJmy7yh0FLF83zDxcvluVmHCg9T0O90JMVxdrpEMvp3m
 UjZ3zzjVI4tI2NEEPbn39uqFHGns2NZARqdmS2QeZ1azfwVbRoOH3JG.DN1SbN0y2ePq7_0HzmsW
 hWWTbdaZbXWl.kyAjkSSz4umgEkFgWxPqf.RcvezRBsNhm4V.FM8YP7GEHy__XkExs8hSh4TeLFb
 bZewPniizAsMdYjYjr.M.EvbtzpHzcm8fbZVf.ZzqKscY0alWryq44XvPzoyBPDiJib1l5c0sdBC
 0zBYa.WO0V5oQtqCm1wXFJlvbWTOTXFChxrBHYUjkGJBPDP67jxj2zFw_PiqwtcX_ZuPVBAzCc3y
 cmO86awaF_G9Z_wgtWs74l6hpVKNxpzDT2mZ1.lXsZ.2ft8F1elJVOcI6JOmyteUett7SMddOeP0
 1Gd_y0r8JVxsjvmXpdJI2kAldr7pFwWeSy1SiI1UFdAX0ZVoflYXE._BTELTCrNE7jluONxVHrBe
 TEZPcij_XBnQMF2dTgUgDkjfnJDNY5SHUJZOGyFp7KznLIPTvz8Emkl5OcILTTIsdFd9QlrMJwNY
 K2cqEKyQLhipt6UgPTkqeNinTfJixUdxmDCuCyH3qk_7SQG_NRhI2.kEHffgFKQsZtC4VXY.6UED
 JbkBYrckT9kae84w48yW_OIfu8NPUveVzgYz7CXhdFYl.jYO10KRFeUp6v3aUFn5oWi1BZkCZIK.
 3lci1ZeK96behRs1EJ1AQW17N5DiWuDI3W6vXlLclC2TtDcxN2uOu9Wqa0V4.6O9BYqXvkYH0zkY
 UtWbvjJJtiGzH4OCAmQ.p6VR6EofrVho1wdRyL.Uz7ezzPOQHJwRufRHM5mVklizlbyU2AkMiMrJ
 lEOM6Hnr_PWnGpwiqs7kNk299WL4aL78lcWlEQFaZFJRi1y8D9N7j8mrPiiIzmk7132coIQ1Fwi2
 8CY4QOve8tT2ketVaoLxrHszfYNLNecaR3fdKz5sPkSN1kfXhEMmNCAgePMjLp_o102HaqUWbMw5
 DkayIUPO92uHen_VyFKmOdQWUFajQgMW7ba215Gn7qLzykZVyzJNXOHtQQeVmjlrSRCzkrD9ZJl5
 Lw17eTioX.CCxsJwvZyJULO_BSTpZVk7qQxQIXM1Q85ZkWpNTnKLJ86llREPPIYnMoBofR1JL_IS
 gMQfA0X9lARoF5BOVswO7pBTxecRxQC9rxHNjYMVQ2XjkLrnHKXPFo2fyqJrFyas9a8TssdTD7zX
 pIx.g5H4wjxRNcYaEwasIgOC4iPmv92U0Apt_PA4tSzD9CcctNsUOQGa73cS9wHPu.cIWdkZpAjL
 s2Axks5CGV4FrpLmSGKjXOfcYvHjDwpeqAFpjSW6nTenIIcySYsCafgDQV2QR21alhrL1FzlCPfO
 549MiGaigXLGXCtEbnwFZspWFgs4dtoSsrqwrc.hA6TjEsEIkJB9aPS280Vh55GKBUNH9g.glB9P
 wPZMpsFCmWIKQgxUiX6EhehuTc61rTcYx84z8ZkXilACJw_QoC5v3RNlV1oq1QL47V96ipFg.jBv
 bnwSUbnQn_0UWMvPzHhbT.bhdpTiyqG1wSu4jfqntgxCoWYSICrwuZ3dVVq2NFXP28NLv.xtefhP
 gC1mfEC2PnVOUcio0CW9xSLsqaCBVLdBt79I_iJXr8w64aiwFXFrJi7EpGR4jQycjlIe617go8Ma
 drLI-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Oct 2022 18:36:46 +0000
Received: by hermes--production-gq1-75cfcccdb-kcc9l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d6618b0693f89704dc1251b10e8e5879;
          Tue, 18 Oct 2022 18:36:41 +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 \(3696.120.41.1.1\))
Subject: Re: Running armv7 on aarch64
From: Mark Millard 
In-Reply-To: 
Date: Tue, 18 Oct 2022 11:36:40 -0700
Cc: freebsd-arm ,
 Brooks Davis 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C629ACD-5BDD-490C-B036-3889BECA6D54@yahoo.com>
References: 
 <3CA3B1F4-46CB-4C75-8451-AF2CA4E9F74B@yahoo.com>
 
To: Kristof Provost 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MsMym3Xz8z3kFv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=NpuPMtXD;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.968];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-18, at 11:18, Kristof Provost  wrote:

> On 18 Oct 2022, at 19:38, Mark Millard wrote:
>=20
> On 2022-Oct-18, at 09:53, Kristof Provost  wrote:
>=20
> It=E2=80=99s not quite clear to me how this is supposed to work (now). =
On amd64 there=E2=80=99s a separate /libexec/ld-elf32.so.1, which we =
don=E2=80=99t have on aarch64. Is it supposed to be built?
>=20
> It=E2=80=99s broken on ab9293239c7d and e03b7883e97c at the very =
least.
>=20
> [I'm ignoring qemu, which I do not use. The below is from=20
> a Cortex-A72 aarch64 context that can execute Cortex-A7=20
> armv7 code as well. Have you been using qemu?]
>=20
> Historically I've only been able to execute armv7 FreeBSD=20
> code on aarch64 FreeBSD via using the likes of, say,=20
> chroot'ing into an installed armv7 world in a directory=20
> tree that I created for such. (I manually split some=20
> liong-lineouptut for readabilty.)
>=20
>=20
> Thanks for that!
>=20
> That=E2=80=99s at least part of what I was missing. Long story short, =
I=E2=80=99m trying to build an armv7 image on an aarch64 machine, and =
having issues with poudriere. I figured I was going to simplify things =
by executing the armv7 binary directly (to debug), but that=E2=80=99s =
missing a few steps and had me chasing down the wrong track.
>=20
> I can=E2=80=99t chroot into that armv7 jail, I still see errors like =
this:
>=20
> (kp@freebsd_current)  =
/usr/local/poudriere/data/.m/main-pfSense_factory_ports_plus_devel/ref % =
sudo chroot .
> ELF binary type "9" not known.
> ELF binary type "9" not known.
> chroot: /bin/sh: Exec format error
>=20
> But at least I think I=E2=80=99m looking in the correct direction now.

Appropriately set up, poudriere's jails are like the chroot
example I used.

I do my armv7 port builds on a Cortex-A72 system via poudriere.
(No qemu use involved.)

# poudriere jail -jmain-CA7 -i
Jail name:         main-CA7
Jail version:      14.0-CURRENT
Jail arch:         arm.armv7
Jail method:       null
Jail mount:        /usr/obj/DESTDIRs/main-CA7-poud
Jail fs:          =20
Jail updated:      2021-06-27 17:58:33
Jail pkgbase:      disabled

/usr/obj/DESTDIRs/main-CA7-poud is analogous to my
prior armv7 world example.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 18 19:10:08 2022
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 4MsNjP44ZQz4fFfZ
	for ; Tue, 18 Oct 2022 19:10:17 +0000 (UTC)
	(envelope-from adami@seeitonthenet.com)
Received: from eve.seeitonthenet.com (seeitonthenet.com [82.69.4.216])
	(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 "seeitonthenet.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MsNjN4mPkz3n6H
	for ; Tue, 18 Oct 2022 19:10:16 +0000 (UTC)
	(envelope-from adami@seeitonthenet.com)
Received: from [192.168.1.106] (unknown [192.168.1.1])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by eve.seeitonthenet.com (Postfix) with ESMTPSA id 3399A1D672E
	for ; Tue, 18 Oct 2022 19:35:23 +0100 (BST)
Content-Type: multipart/mixed; boundary="------------YiYUZq579EkCqdAkzyDDVYcw"
Message-ID: <237cd521-1c3d-46b2-58dd-f975a5cb9b85@seeitonthenet.com>
Date: Tue, 18 Oct 2022 20:10:08 +0100
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 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.1
Reply-To: adami@seeitonthenet.com
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Adam Isherwood 
Subject: unsubscribe
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (eve.seeitonthenet.com [0.0.0.0]); Tue, 18 Oct 2022 19:35:23 +0100 (BST)
X-Rspamd-Queue-Id: 4MsNjN4mPkz3n6H
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of adami@seeitonthenet.com has no SPF policy when checking 82.69.4.216) smtp.mailfrom=adami@seeitonthenet.com
X-Spamd-Result: default: False [0.30 / 15.00];
	AUTH_NA(1.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	HFILTER_HELO_IP_A(1.00)[eve.seeitonthenet.com];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	HFILTER_HELO_NORES_A_OR_MX(0.30)[eve.seeitonthenet.com];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DMARC_NA(0.00)[seeitonthenet.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	HAS_REPLYTO(0.00)[adami@seeitonthenet.com];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_NONE(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:13037, ipnet:82.68.0.0/14, country:GB];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------YiYUZq579EkCqdAkzyDDVYcw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

unsubscribe

--------------YiYUZq579EkCqdAkzyDDVYcw
Content-Type: text/vcard; charset=UTF-8; name="adami.vcf"
Content-Disposition: attachment; filename="adami.vcf"
Content-Transfer-Encoding: base64

bnVsbA==

--------------YiYUZq579EkCqdAkzyDDVYcw--

From nobody Wed Oct 19 08:58:03 2022
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 4Msl4Z6SGCz4gLpf
	for ; Wed, 19 Oct 2022 08:58:06 +0000 (UTC)
	(envelope-from kp@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 4Msl4Z5xBQz47xQ;
	Wed, 19 Oct 2022 08:58:06 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666169886;
	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=wtjEehfu4L/f1W7Su1cY2/JowNNNRuTI0yjoUY2zqbU=;
	b=GBifgLCMVn9jeSGWHcsR8JAvWVCxi7bzQqByk3odsta41iutWVs4Uth/qKMw3SOpocjsc1
	A+70i2FSoRYfqDH0NCfwJlxyTei2tMNYomED/f3DN2wtaM5n8ifiONAY1nFJ5caExggNP0
	MzBQZjzXB4diG4+dtoE7tTs/ZqCSMxJeXgsK/dSwuzdN675gRbcd9sbv9aGOBAk6dvlswi
	kPOtxlVDciT5mZY5kLN9lkPBCC1VFlOnrx1floy2BDe89S5zIVG49SYmkfyRaZzredeRBU
	QZDZGhN231AloQSwj4aeuiKgPaBwbCcaUwVo9K1s9QTii01M8K98ntHzfOdodw==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(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 "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Msl4Z4D8cz1d4C;
	Wed, 19 Oct 2022 08:58:06 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id DFE3B30C33;
	Wed, 19 Oct 2022 10:58:04 +0200 (CEST)
From: Kristof Provost 
To: Mark Millard 
Cc: freebsd-arm , Brooks Davis 
Subject: Re: Running armv7 on aarch64
Date: Wed, 19 Oct 2022 10:58:03 +0200
X-Mailer: MailMate (1.14r5918)
Message-ID: 
In-Reply-To: 
References: 
 <3CA3B1F4-46CB-4C75-8451-AF2CA4E9F74B@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: quoted-printable
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666169886;
	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=wtjEehfu4L/f1W7Su1cY2/JowNNNRuTI0yjoUY2zqbU=;
	b=YL3wYQSyFxsgReg1EUi9Hqfo5gFLk6BQ0S4Y3xcsiqFKqYPTjR15izQG6HGQBAdU69o/ky
	F4AjMmWeSK3gS+5s5zjYWy5ILu0lkKdwPYBZWWt5+41iuPHZNFI1Gh2bEnBHFtDOEE4yrF
	QBi7qqV9AXZwP/iGd1sg4aGZx1kkDqv3f4wJcdS1hlToJUZTK9pu+HN1OgZCdQixREq717
	hQOxCElY1mYqia7lMeXnVnk3zr9Un7Q4Sxuftff/YUWPRddaPZxDckXkXazRZ4614IusPu
	nzKULovqGb6Qyw4tBBTt63lQvVH6JjWpM4Oq9/jI6fLo1rJPqWFvfFjy/n6ENw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666169886; a=rsa-sha256; cv=none;
	b=hD6NtDQQBxCSWLo9Auox7Tnp3iztP4Wym4E5TE+jSopvIeYp5yIDIYOk6l0zB/irX+/lGr
	W+P1pcS0adzhYOPnLYu7jYJmMiHYM+YIyk1VE4TSg/HcGZzujh5Y7+cO3ETlTvXA4/nqgh
	q+7tB7Ac0pUOyW3m4OxN7VUchTrhHVIUdzhjwL/ylhs1rkcc1MtVVQNv4vbsmbg1zSg88K
	jyrox1lTOSYGzIdfj5qforeIoXMOwXlCVT7CA4Z11n96I1CSKlc1QbG/jffIxoa/WDlv/i
	WkL/Au5CGGpjHm/xrmCGbcznxQHSovbBgVuuU+LiVD4C2/UvUt+U7MoDqyZKsw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 18 Oct 2022, at 20:18, Kristof Provost wrote:
> On 18 Oct 2022, at 19:38, Mark Millard wrote:
>> On 2022-Oct-18, at 09:53, Kristof Provost  wrote:
>>> It=E2=80=99s not quite clear to me how this is supposed to work (now)=
=2E On amd64 there=E2=80=99s a separate /libexec/ld-elf32.so.1, which we =
don=E2=80=99t have on aarch64. Is it supposed to be built?
>>>
>>> It=E2=80=99s broken on ab9293239c7d and e03b7883e97c at the very leas=
t.
>>
>> [I'm ignoring qemu, which I do not use. The below is from
>> a Cortex-A72 aarch64 context that can execute Cortex-A7
>> armv7 code as well. Have you been using qemu?]
>>
>> Historically I've only been able to execute armv7 FreeBSD
>> code on aarch64 FreeBSD via using the likes of, say,
>> chroot'ing into an installed armv7 world in a directory
>> tree that I created for such. (I manually split some
>> liong-lineouptut for readabilty.)
>>
> Thanks for that!
>
> That=E2=80=99s at least part of what I was missing. Long story short, I=
=E2=80=99m trying to build an armv7 image on an aarch64 machine, and havi=
ng issues with poudriere. I figured I was going to simplify things by exe=
cuting the armv7 binary directly (to debug), but that=E2=80=99s missing a=
 few steps and had me chasing down the wrong track.
>
> I can=E2=80=99t chroot into that armv7 jail, I still see errors like th=
is:
>
>     (kp@freebsd_current)  /usr/local/poudriere/data/.m/main-pfSense_fac=
tory_ports_plus_devel/ref % sudo chroot .
>     ELF binary type "9" not known.
>     ELF binary type "9" not known.
>     chroot: /bin/sh: Exec format error
>
> But at least I think I=E2=80=99m looking in the correct direction now.
>
For those playing along at home, I believe I now understand why the above=
 doesn=E2=80=99t work.
This is a VMWare Fusion VM (preview of 09/22), and it appears to no longe=
r support 32-bit arm.

FreeBSD refuses to start a 32-bit arm binary due to the check in elf32_ar=
m_abi_supported(). It reads the id_aa64pfr0_el1 special register, which d=
oesn=E2=80=99t indicate 32-bit support. It lists 0x1101000011111111 as a =
value now.

Simply removing the check allows the 32-bit binary to execute, but that c=
rashes the VM, so isn=E2=80=99t very useful.

Best regards,
Kristof

From nobody Fri Oct 21 17:51:42 2022
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 4MvBqT1hdgz4gKfL;
	Fri, 21 Oct 2022 17:51:49 +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 4MvBqS2nW0z49bW;
	Fri, 21 Oct 2022 17:51:48 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29LHpgcJ062571
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 21 Oct 2022 10:51:42 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29LHpgxK062570;
	Fri, 21 Oct 2022 10:51:42 -0700 (PDT)
	(envelope-from fbsd)
Date: Fri, 21 Oct 2022 10:51:42 -0700
From: bob prohaska 
To: Mark Millard 
Cc: freebsd-arm , freebsd-uboot@freebsd.org
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3,
 sees disk but won't boot it
Message-ID: <20221021175142.GA62386@www.zefox.net>
References: 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@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: 4MvBqS2nW0z49bW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-uboot@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


Mixed success has been obtained using EDK2 on a pair of Pi3
systems, one running 13-stable and one running -current. 

The 13-stable machine is at stable/13-ef2aa7753
The -current machine is at main-n258665-e03b7883e97c

The 13-stable machine boots reliably with an EDK2 microSD card
and will boot almost as reliably with no microSD card at all.
This seems true with both JMS561 and JMS578 usb-serial bridges.

The -current machine uses an ASMT bridge and is unresponsive
with either the EDK2 microSD or no microSD at all. It does boot
reliably using the "special bootcode.bin" file from the Pi foundation.
It appears to be the newer of the two Pi3's, having a non-latching
microSD receptacle. 
 
On balance EDK2 appears to be useful, or at least having some
promise. Bugzilla traffic suggests work is stalled, can it be
unstuck?

Thanks for reading,

bob prohaska
 
 


From nobody Fri Oct 21 19:53:47 2022
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 4MvFXR1lQTz4gdkp
	for ; Fri, 21 Oct 2022 19:53:59 +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 4MvFXP4cS5z3RGx
	for ; Fri, 21 Oct 2022 19:53:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666382035; bh=oVTrxdeoAkTJU13bw7CNxpmQmUXFyWYL+TiRGdQP3bk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TBsNSqLDvV9bTyy2b2KrH9apWMWqz1mn3v+2IzPsgi7du0TuRalJInIvxZIDd9fsuzIeO+IcRy2Cjde+48uT7Y9UPcwZwYOmZ7JBhy+dV5qDN3zm2r3pqVbqNBHMWHDOZPpkCNm+517TnQs27GWgDXW2l3bmEtJlFXE2XJYokTgly2uqudwUkKbFY63TgZGQDEjV+ljPXdjMMidZmxKWZR7AM25f9bp8QHm2dCO2WgKA8s0dhfO+kGRiBso/a2apnkAuk3jayEcnLzDkIex2ka9vQhRQ2Y1vzYGfjqHHlskHjKJIUnSi8FrKvvyk7sCIonFauB6qcp9N9eI/WUIFvQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666382035; bh=Wck8MkZqsrVAyKe8GvjocSWY6KhhL5KCWQO7r0qxZ+2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OTnpcsCVEpMCcnCfgSVrKy/mxKezzEmgmsXB3Ae+etxWNvZbYS7VPEC3Y8xIy1cIf9SAve7KUfTVIpDVtEYcy8Y8xHbLhwkI3IyonuttcwhhZjEdRqR3RojaHk6v3jFB901/HskUkJCTaTf1MWVxbaXlRbKfY8vfZu8dV9BoRTbE/BRSOUrVqNfssAacDiaqSVWjW07GF/UJQiH2nH+3zssSFYuNRw2f6i8MXjpopN/pkznkxIKZzWx7kGE+pKtLL7xfe2+kgFrELL2CtQnOgAruaPQlVYEz5WwRIYMIzgNYJ5O+Yn6j3GUx2yqPNIy8GFIQIZGYmQgMxOg6RiCR4A==
X-YMail-OSG: Vsfsj_sVM1mDyziuoMv.zx2qQNjB4ZUnSlwpGlfXv5.REpcN1QoJQnAg3IVH9Yu
 DloBr4_rwUQycBMy7Vj3p2jrZMBDlc440udcN_lTm65kxzJXroUGQIWP2I4OzFnENFHIz7adesUb
 lt4uAN9Sfqsu5_mjsa4LTLzOlYWKdr4pDki1_63hRSW5MLpsER4L122hc9tAmYDjjQ1QTyJdTwO5
 LLutZt2GLypRc9V0GKgZPUYnJq_UKEehBvMvptcjleeRw4nsWV8oIkthpbBRnfo5Sw3rWNjAaq6T
 9MMQvXQW5chzZdIT37GeGc.peq478AqQet2IsVmuO4ZvL2JxVQ0Fy.7HPLje2SLm2Yb8yNsvxcaH
 5Q6TK.1.Lg1dKyOEhhSOINq2B6Xrfl6uxDuj9tS_sh3Y9b3ssUQ7WZIqxY3XuLrjOdBEXb8rTs1v
 FInNT4.xgGdmZ0x0jxg2gauHNh5BIs42nXfO6P_tHuFRRTzPKtTB0_PAg7BOz2EyCk99SQ_tTDQY
 aIIQ0VU16_QpdEHmzpMq4nRuh.HPWxC71u1heozIG.L0KxMeV2q6iVHN7Ffa0RXFHHCLvTLtiaOI
 mkKA0tBdSI6uXomNWtBvb.WihtudhK5r37Y8qsiXdt1wjSubKiVWA8NYLULC9Xsx7OE2aOHZHeAf
 vi9PGsge.OWMa3XjTz2T0xlWW_6wcXGTQjX61jO97Khi5EDrNA.uElsGJuR21f8T4Gp1cqYS3ps7
 P4FFlEJLYEjXpjfpNUw3mnpJZoD5R4oqNEdVlOdRvF.lWyN62hBGy7DHEWZ8DA2Jhow_uLqgpV.N
 zXbqRetsV8f7vqwN32Dbg8IN.GN8bh8ZkzcNFKFoblEa1Lb6tjxSYycK_SQbNgZiDaw2ckWLW5.3
 3VjoEXr3NYWK6T_02dnf_K.kYdp0ZvB5gRbCj17_pudjQZtBEtI3D_elg8U1fVsIqQ3FfW2XKFs9
 ph8KMzdM17ZuyCtf6jq5XHegJor2CS6u0nsjJ2srdSb7Oz8hS2FXVdNaU_HG8t4F8F6MIWsHivmN
 qktkEYOVIjVCvnLdUiFb1mGGkO1dahSfgZ50ySdPTRNW13HfiFWcghr59mEKX3vDHFvekYetPhVc
 _LBAc3Q3jIIgsWBf4SGdE5dVxrp20HYV_9y5Fm5FDyNNsRhnrsHafoBJGLXfrqrJiT9lfb93SOkm
 3n.8uRrzZfr_oXKkBIM0mOMndX2W3YpU0oP3LdXW9YM_WrERBWsB73OY.7BPWsoeeQ7yydusbfVQ
 0SOSDDshuepXHACNty2uvs2UuM4x1l5wvQzaXClBiYZrK5_aBtoUUZJt9u0DOtFS9KkWPYsdxT9w
 jow0_LUFXuKJZ_k3UiCfM8IOMnbCphEsfseornjNSZfBSBQRno9D065dxpjnh5eJmmiNzK0QRBZ0
 IemMrGiZ4MZ.Bld7PNyhit.Ox_t.eyCMcPIFxBjg9AmhOXwlP5Kl7rNlD2qia_RL47z5RdxWUnhV
 b6JigpJE5YIZ5.aLz4P16H9VLUdX2JBOeP0mr_jHG9BBCmjWod6v..ZMxCpTT2Mu2CH1MyD9w849
 W0NHK2hWVVNCag3CXDWoVdmfBgYtzEegfNhwoX4FOdtaLgwkfsGhEKoieuW0EXnYW_vhbSXzNG.r
 XKK.gPooDi0qlEQOLVVRBAXsHb7BEuK1i9sVkaHlMzu7h5jLYMu.FrXKNfRdatQ6Y1vhK3sjE4Jn
 P1sy8Gy380XnDxXJw3HNZNIVuU9TUZEq34qhNpY8CAH6lLnYm_bIKpuQRO_nmcHPgpLnUinY9xtu
 uvLMGgx0Z57.z9DkrMvJrI3OukXloycH8tL_If668Hg9xlroFZ8k2JlpssaeH8iigpb.WoTEmZpA
 ueQn8f1H_Pc0tUCcZtzXDxWc9uItueKqeFYpfCppWQbrLnJn49phavsRdfJZ8iWlWsb4rp_66.zn
 5uXWiR2rAKa4ADoDqeLEPf8Z014tU_eY0mIkCwI8WwH_Pi_FNPPuYGemoszzkD6bbmhTdGhjqd00
 vFxUuX6TprRh9uB7Wn7L9SSphXjM8dnWF3Fv62YSpiqHBGdF_n76KqTNfWNqDszOMbmiMbUjusFw
 eTXOuc7c36_UP2SAudGRWXdn6DdJWUNLsLg5w0mXJRU8E4domdjeYPtA9ExR2EBes34vs7v0Zpo9
 bmKYF8k6iF4siLtBKvuwLYbdy18lRtfko93b8DXiuFBa2P538bVVzDt9pjGKkASaYP9H_5cxLlmp
 uFeCrHW3jH89MZpMBpvqcZRwadGkOHJVQi_uW4vpF85PAZhh9uGanrEZeGc1YgxKXMuaxnW4pMPe
 0
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Oct 2022 19:53:55 +0000
Received: by hermes--production-bf1-64dccd5d47-s4dvw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9ad4b8bb44faafddb9772161dd1180ad;
          Fri, 21 Oct 2022 19:53:50 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <20221021175142.GA62386@www.zefox.net>
Date: Fri, 21 Oct 2022 12:53:47 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MvFXP4cS5z3RGx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=TBsNSqLD;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-21, at 10:51, bob prohaska  wrote:

> Mixed success has been obtained using EDK2 on a pair of Pi3
> systems, one running 13-stable and one running -current. 
> 
> The 13-stable machine is at stable/13-ef2aa7753
> The -current machine is at main-n258665-e03b7883e97c
> 
> The 13-stable machine boots reliably with an EDK2 microSD card
> and will boot almost as reliably with no microSD card at all.
> This seems true with both JMS561 and JMS578 usb-serial bridges.
> 
> The -current machine uses an ASMT bridge and is unresponsive
> with either the EDK2 microSD or no microSD at all. It does boot
> reliably using the "special bootcode.bin" file from the Pi foundation.
> It appears to be the newer of the two Pi3's, having a non-latching
> microSD receptacle. 

Which context does the "need bootcode.bin" problem follow?

A) Where the ASMT bridge is used vs. not?
B) Which RPi3B is used vs. not?
C) Which OS version is used vs. not?
D) It gets messier to specify if combinations of 2 or more
   those need to be specified. I'll not list all the
   possibilities.

Does the newer RPi3B indicate that its USB booting has
been enabled? (You may need to use the likes of a
RaspiOS variant to check this.)

I'm confused about the "special bootcode.bin": bootcoce.bin
is a normal part of the RPi* firmware, just ignored by
RPi4B related RPi*'s that have an alternate means of doing
things. Is this the bootcode.bin in the standard RPi*
firmware releases? Some other version?

bootcode.bin always has more recent, bugfixed USB boot code
than a RPi3B has built in, as far as I know. The RPi3B's
do not have a supported means of updating what is built-in
for such functionality. bootcode.bin is used instead.


> On balance EDK2 appears to be useful, or at least having some
> promise.

I'm glad it seems to have helped. But there are things to
know.

Point #0: EDK2 versions and testedness

The only tested RPi3B EDK2 versions are the ones that the
developers release. They do not test EDK2 updates after
they make an EDK2 release, at least until they again work
on making a new RPi3B EDK2 release.

Similarly, they do not test using newer RPi* firmware than
they bundle. Only a small subset of the overall RPi*
firmware is in their RPI3B release. For example, a lack of
most of the overlays. They do have references to at least
using one overlay that they do not include, as I remember.
But use of any other overlays is untested/not-supported as
far as I can tell.

The same goes for the RPi4B related EDK2 releases vs. later
EDK2 updates vs. overlays and such.

The RPi3B vs. RPi4B EDK2 releases are not based on the same
vintage of EDK2 materials --or on the same vintage of RPi*
materials.

This means that using the FreeBSD port will not pick out
the release-matching EDK2 materials as are in the RPi3B
or RPI4B EDK2 releases. Also, the RPi* firmware has to be
separately supplied. Overall: an untested combination
results, a combination that is unsupported by the RPi3B EDK2
developers and the RPi4B EDK2 developers.

I've no clue if or how well the the port's builds might work.

Another issue is that some software that is upstream of
EDK2 tends to have problems staying inside the C language
definition and when this happens, EDK2 builds fail, despite
it not being EDK2's own code that needs the fix.

Point #1: RPi3B microsd slot use is messed up

In my RPi3B EDK2 related testing, trying to use a microsd
card in the RPi3B slot for such can corrupt the contents.
It does not even reliably lead to even correct file name
displays in ls output.

By contrast, using a USB reader/writer continued to work
just fine.

So just leave a RPi3B EDK2 microsd card in the slot
after booting.

I've no clue of the status for things like sound and such.

Point #2: RPi4B does not even start to use the microsd card

In my RPi4B EDK2 use, microsd card in the slot are not
supported --by being ignored as I remember.

By contrast, using a USB reader/writer continued to work
just fine.

So just leave a RPi4B EDK2 microsd card in the slot
after booting.

I've no clue of the status for things like sound and such.


> Bugzilla traffic suggests work is stalled, can it be
> unstuck?
> 

I expect that at some point that some variation on my
patches to allow the builds to at least complete will
be committed so the likes of aarch64 FreeBSD builds
become possible. (So long as EDK2+its-upstream stays
inside the language definition.)

But I do not know how useful builds are now when built
on amd64 or the like --that will also be true for the
aarch64 built ones. See the above "Point #0: EDK2
versions and testedness" notes.

It may end up being more effective to stick to
downloading and using releases made by the RPi3B EDK2
and RPi4B EDK2 folks if EDK2 is to be used for these
RPi* families.

===
Mark Millard
marklmi at yahoo.com


From nobody Fri Oct 21 20:21:59 2022
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 4MvG8v1zR7z4gjHW
	for ; Fri, 21 Oct 2022 20:22:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4MvG8t17WGz3TK9
	for ; Fri, 21 Oct 2022 20:22:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666383724; bh=xwcmgkR2N86rBBYriMbE+p7sI/4ucatOy4lYR8Lr2LM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qJwTd+vhj1gfdNKAHtPDVBlW6qZsVOvirjyeFbqBGn+DOYqjtcxztryMbpqBW0uffWuXjNJSyOXxnGLYuO9YnTVg6I/fLneuLfkfAcS16eKLFcqCg8KMobUITkEmK24fUa7N73PNtjTGVhTEsSbFzb408eVYJmq1qtKVvfL05IFvM943XMJzvZ0RaSW/Aew2jInwbB/zJQK2flrFu3CBSAxkYFMbKZMeSPScDTUcpr2i9ZgvF66Mpm57VgP5omNiNeS5A7620TigARi6xxLU0oWo2NC6/0l3mGhRrdVrQqgjoAumNtIMO+rCBhwynQB6w9vUvX17sNSN2/KVoKONoA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666383724; bh=6TlVrHlf5INDX6EexaxhkJNlAjRqa/MgPKrmTeJnD7j=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IuRYboCi8NpjyEe0bbPOTQf7T9UKdq8yt/YrbO4G+qMUTV9KR70Kw1CnaIfkjcfCas9ITkdmTyfRlrkTaVwFsScxr6Dx/4gxtObK6zpQ8FX4PDUhtU8hmmjaAmJQasKcIoUFrBDIhVi4jMyJtmyzWy3CRKMShn7Z9sy2DBRXSDooLQ660v2FzwSoVddcuED4eRrFphGtPCHZVt6zhi3+b1QvWJ72kGpeFZyjtfZxzxggvEWb98bLvyJdLOLpT0iqWTuwefNYIrksoTWRurNQIe56i2hNojnsvVtvvV+Fjs+Sh4IJuQli4WpUDI0t/zfFnL3qBZGiBZ5jOO8M5GMlkQ==
X-YMail-OSG: bY0dX1IVM1nJv5x.e6MvP9O2AnzCJdYsHFvhjasMMve0PDQ.PT2JuehSw7TO7vI
 LSSfsjPniPuPi0liL7UKVOxl5W_qJv9pqUVpd9lBhFgD3jeBuz3Z7LKA_JkJ6_RJjgyC1Kj34E_f
 UzN201N4ltb7_Px.3XsmozcYzdjXXPpHn6rIjjFc5N2NnSVI60t2KoyWr9kG2Q7PRnutSVJZtiEG
 OZ9.8Tey.CTn70f8dYrbukccFp.hWntwh_WwbmjnlMPZfSchNKy7.3g5GrXKujcKsk3wT5NFcA4W
 Jk3cS2H3HWndg89NbT0QOv5E7EXy9hquGfbYBoibEDIy3uh4ir8khyi0rI6HsNgMb8mZgNdssLdw
 fBUWLwPFI1T1KGECXyqDfb_m9Wafy.dMQq1yvcLbt9db46aawO.yLIINpzEQ1irR13XpA_PM6G2d
 NebeRw1KXtklUVRVkTdkUo7XQ8SsQkBgq1Vq7y9anraABYA25WECVOYPZgttBQNH8sa3BhVGIrSn
 gLiMrSa9VEOmJuMHUjIhVbWXCUxjNO3aO1kaAir101NvW9f40cnZH1oUxB42nRdccIqRFtugeoBg
 qnrwuDK.devOlxcROKgYEpCxahUIQcT_Q1kaMsap500jHE7_EraInsYiJ5GVDjChXNUtpCPIhAbF
 lwp1pyVY2M1oTHTk015vIv7zG7B_USv3qYz4FQjl44lBBXlwPyzsxltnEeWTUBotA_jdbZG9CWp4
 sax2oiQ_pFyGOEVfYaovNNoh5XHGl8dNva1cqmlY7UMOhLYd9aWYCsu.iwvaSz3MMqFzCx7xwuLP
 bAxpkG6zGwYB3QOsOF2ZfpJatD2H.ywpd.vXcKF8vZySTDb1hHUW1JIO4KQzRf5duxQHhEq1gGMi
 GcVx19N4.HkPVcc6O6BDl4O7HwBbsG9fVrE2sN.G0_3nglimtXA0x5IgbjOKFA9rmgrykg0G_PT0
 L17BRTD7VhHCy9hs.Y.0s06gxXL_0lVnx6Ds1XL4R6r1a23SU31C9CukMasIs7xWmsPWhC5VeorC
 U.91Bh7c0c0vR2mhNnd3n3F.dmL7Mn7V7k.dd.ehvqUUOMP83oGkcN4DBfC59n829JCDe0cO.elQ
 V3KSxP_obxChYMU4x1MnJxs.K.8uCCdzhyeHHgK106kTBZJHB9A1eIXd1cg6WQp8pnIlV2dN4Gw8
 B95uziOK7Jcg9f4I5.IntV8U99KpUeMv31Qf2MYUkp3aVl9YkgZWytlw_yJK2onwwb6HpkmFhAqu
 M.clxj.BJ5YeDdW1yoGAHNhJfVNKwM2I70961uJWWkh6rUbZeFQZIxdqYPdfgz6KWXeBA12HX4vJ
 pAisk5bYvOD1UU.NFjKoxRaKvxrnpCXE2mCvfE7PF8bj7JOLCL4wA0utDbBg7JUY.AoQZYljohDw
 D6q6tOmmPpSB_cJxiyobGpjZOHYoFv78Dfa5.lyd6hZsvph0yPGu.XfyOs.7GCy0x8ewU9egq0GS
 9X1hZp6mudrjctQ0bj2euxypSq3u9HnGesOx0bQLE9WSmyb4CxQZbgnKbXBg59PwEndXDTBC7_KC
 RAVamoSPBwPK_uJaI1xyLBoeHtMhYBpZ4eXUoQVxr5XMQyW0fHpJizx9OLXUg3.bB3p4YyeVdjCq
 G1fM_PE73D.x_JnFszLJ5BDmDXcE.pxyRSwFBJmx5obhRX3Z7h_8YpuUx5dc.PzZkDEyWkmyyoz3
 VMEUCmzpB3ZAu8RjCTTPaNyjjqcvhmNcUx.K6qjMElSUGM4NIgXtEfP.nu7l3DoPz1OwGCAnc_d7
 2FSvz41YX40ffEqd5cM_BqcQs5uLqRbQsb9SGaymJMvJlAGtLqoNclwQPSmWf3bNMul5hZbTc1m5
 w9j5gxLe_lWyCs6P3oKdVgdo9NvOmMxOBsKf6XQ6H00m9Z.zy_crpCcEPz4nrmFLJ.ndc9DW5QNc
 6kUnxF4JZy53xMLEwpX8XAQwHmpvRdGkMr2Ciy8PuksKTBGVpFdlYe1YKE7Wr9ltxS6p5kYw6AgO
 ZLgKnk6zWvdBygXXR6DmOpAtz.WNwO7NAPqicVBQJ7kQfvpvSpSw8xdkRfBVzSExv085XyWwWpZH
 PIFAQpdc5w_TBbHaEk.nCU3Xlu.9byoA37nG_honLS19dVOPmSbx.WWULdqdTcMbkZhjzxhP7iCc
 Ay.whhlHk3y2HpR27V5idxzNdtcWluhpkisdrcT4NcXJHbwLGBv.xwjCr8np38mtRzqoRTRuoXP1
 4pdcMsfGZY2lbtMrSjlk50Y8qN_ic3LDPJ1sR3__9XEPAnU1vPNamD.S1zpPQSp5lBpQS5Gd2SA-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Oct 2022 20:22:04 +0000
Received: by hermes--production-ne1-c47ffd5f5-8c2cz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8b1ab763c16993c9dc321b14f1e1c869;
          Fri, 21 Oct 2022 20:22:01 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: 
Date: Fri, 21 Oct 2022 13:21:59 -0700
Cc: freebsd-arm ,
 freebsd-uboot@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
References: 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MvG8t17WGz3TK9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qJwTd+vh;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-21, at 12:53, Mark Millard  wrote:

> On 2022-Oct-21, at 10:51, bob prohaska  wrote:
>=20
>> Mixed success has been obtained using EDK2 on a pair of Pi3
>> systems, one running 13-stable and one running -current.=20
>>=20
>> The 13-stable machine is at stable/13-ef2aa7753
>> The -current machine is at main-n258665-e03b7883e97c
>>=20
>> The 13-stable machine boots reliably with an EDK2 microSD card
>> and will boot almost as reliably with no microSD card at all.
>> This seems true with both JMS561 and JMS578 usb-serial bridges.
>>=20
>> The -current machine uses an ASMT bridge and is unresponsive
>> with either the EDK2 microSD or no microSD at all. It does boot
>> reliably using the "special bootcode.bin" file from the Pi =
foundation.
>> It appears to be the newer of the two Pi3's, having a non-latching
>> microSD receptacle.=20
>=20
> Which context does the "need bootcode.bin" problem follow?
>=20
> A) Where the ASMT bridge is used vs. not?
> B) Which RPi3B is used vs. not?
> C) Which OS version is used vs. not?
> D) It gets messier to specify if combinations of 2 or more
>   those need to be specified. I'll not list all the
>   possibilities.
>=20
> Does the newer RPi3B indicate that its USB booting has
> been enabled? (You may need to use the likes of a
> RaspiOS variant to check this.)
>=20
> I'm confused about the "special bootcode.bin": bootcoce.bin
> is a normal part of the RPi* firmware, just ignored by
> RPi4B related RPi*'s that have an alternate means of doing
> things. Is this the bootcode.bin in the standard RPi*
> firmware releases? Some other version?
>=20
> bootcode.bin always has more recent, bugfixed USB boot code
> than a RPi3B has built in, as far as I know. The RPi3B's
> do not have a supported means of updating what is built-in
> for such functionality. bootcode.bin is used instead.
>=20
>=20
>> On balance EDK2 appears to be useful, or at least having some
>> promise.
>=20
> I'm glad it seems to have helped. But there are things to
> know.
>=20
> Point #0: EDK2 versions and testedness
>=20
> The only tested RPi3B EDK2 versions are the ones that the
> developers release. They do not test EDK2 updates after
> they make an EDK2 release, at least until they again work
> on making a new RPi3B EDK2 release.
>=20
> Similarly, they do not test using newer RPi* firmware than
> they bundle. Only a small subset of the overall RPi*
> firmware is in their RPI3B release. For example, a lack of
> most of the overlays. They do have references to at least
> using one overlay that they do not include, as I remember.
> But use of any other overlays is untested/not-supported as
> far as I can tell.
>=20
> The same goes for the RPi4B related EDK2 releases vs. later
> EDK2 updates vs. overlays and such.
>=20
> The RPi3B vs. RPi4B EDK2 releases are not based on the same
> vintage of EDK2 materials --or on the same vintage of RPi*
> materials.
>=20
> This means that using the FreeBSD port will not pick out
> the release-matching EDK2 materials as are in the RPi3B
> or RPI4B EDK2 releases. Also, the RPi* firmware has to be
> separately supplied. Overall: an untested combination
> results, a combination that is unsupported by the RPi3B EDK2
> developers and the RPi4B EDK2 developers.
>=20
> I've no clue if or how well the the port's builds might work.
>=20
> Another issue is that some software that is upstream of
> EDK2 tends to have problems staying inside the C language
> definition and when this happens, EDK2 builds fail, despite
> it not being EDK2's own code that needs the fix.
>=20
> Point #1: RPi3B microsd slot use is messed up
>=20
> In my RPi3B EDK2 related testing, trying to use a microsd
> card in the RPi3B slot for such can corrupt the contents.
> It does not even reliably lead to even correct file name
> displays in ls output.
>=20
> By contrast, using a USB reader/writer continued to work
> just fine.
>=20
> So just leave a RPi3B EDK2 microsd card in the slot
> after booting.
>=20
> I've no clue of the status for things like sound and such.
>=20
> Point #2: RPi4B does not even start to use the microsd card
>=20
> In my RPi4B EDK2 use, microsd card in the slot are not
> supported --by being ignored as I remember.
>=20
> By contrast, using a USB reader/writer continued to work
> just fine.
>=20
> So just leave a RPi4B EDK2 microsd card in the slot
> after booting.
>=20
> I've no clue of the status for things like sound and such.
>=20
>=20
>> Bugzilla traffic suggests work is stalled, can it be
>> unstuck?
>>=20
>=20
> I expect that at some point that some variation on my
> patches to allow the builds to at least complete will
> be committed so the likes of aarch64 FreeBSD builds
> become possible. (So long as EDK2+its-upstream stays
> inside the language definition.)
>=20
> But I do not know how useful builds are now when built
> on amd64 or the like --that will also be true for the
> aarch64 built ones. See the above "Point #0: EDK2
> versions and testedness" notes.
>=20
> It may end up being more effective to stick to
> downloading and using releases made by the RPi3B EDK2
> and RPi4B EDK2 folks if EDK2 is to be used for these
> RPi* families.

Side note on what type of video interfaces are in use
for EDK2, at least for RPi4B EDK2 . . .

=46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835

QUOTE of jlinton
It looks fine on my RPI4+PFTF UEFI as well, although it
should be noted that it's running on the EFI framebuffer
in both DT and ACPI mode with that firmware.. This
shouldn't be unexpected. At some point, I will update
the DT with one that has the vc4 bindings.
END QUOTE

I do not know if RPi3B EDK2 also uses the EFI framebuffer
for its Device Tree vs. ACPI vs. both modes. EFI
framebuffer mode would likely be less performant.

I'll note that if RPi4+PFTF UEFI is updated for Device
Treee, that would not change RPi3+PFTF UEFI for
Device Tree.

(Fedora 37 was delayed by a failure to have RPi4B
HDMI output displayed past a given point in the boot
sequence. There was some question if some RPi3B
bugfix(es) had caused the RPi4B issue. Looks like
kernel-5.19.16-301.fc37 may end up being the
basis for the first Fedora release with official
RPi4B support, as its initial testing reports are
that video is working on both RPi4 and RPi3.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Oct 22 00:16:40 2022
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 4MvMMd3nkSz4g5TJ
	for ; Sat, 22 Oct 2022 00:16:45 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335])
	(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 4MvMMc10G5z3khG
	for ; Sat, 22 Oct 2022 00:16:44 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-wm1-x335.google.com with SMTP id o20-20020a05600c4fd400b003b4a516c479so3120523wmq.1
        for ; Fri, 21 Oct 2022 17:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LLKIhsmFvlE1pYmWEBQFfbgWSErlYPUF/mJkbC2N2Dg=;
        b=mX+RB7DcjZ5R+gkEFZCaDZROsJn+IhQlenGscDu1oU4Cxat+vZ24T8YYlpRrdjwS8J
         QVHv62/VJszBOSRqcGmsI3eZj+FRsw32XIHrJPEHyTKwz1nwg3OHSWDHjNb4i14nd2TR
         yWffgutAyi7R1dKzZVUvGarDM9uNrkmSleqEaujH7Cswb/Gc62mQLgLOuiJswS0DdLGN
         b6DjZ/uxKRhH9ntQ+LoK7I/YztT5BBoyLuf1X7R/BgcMWnbdt325/K7OUNeQOeWGiqy4
         5qqMPTmMszOvxxgH9hWuVlEYMbyIiozJmkhZQsfkzucjbhJVOEt4I142mP+61/2Ld88z
         dwEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=LLKIhsmFvlE1pYmWEBQFfbgWSErlYPUF/mJkbC2N2Dg=;
        b=UD9JL3t5blNZLnHTU/Q9u3R1417648t5HgyrCj15+VC6D3ZXgvNQ3rILeEXkqZxAMm
         YLRcu2LWM5q0kqUMHMTvJYR7YIN6odjdERXvJu+RYOI+2O0nSdsgLcOWojzR4BzHn/nO
         2oJ3z51Vl0OZfJeDG9HWTKBftcR85+Xpx3X9SWBTC1anP/EQAUsNcwEhSub3rhr5HIg8
         qi8/3VVuoHl3uPaoXw0P9jcOmhQ5OMEiCmlpL0uTZB+AWyI31BVRvtzZRgZ40TDHJK6i
         kQQB8xpEGK7nYbqEtlJbTUzE0GLxk4ADJy0g9BkdEwDT5oOopb3Bw+iKKE7I1X2r+Fsd
         Xoew==
X-Gm-Message-State: ACrzQf0WXea3DFvL5ebLEJF8TY9CPMUQtlW+v/qH50mgC1BCHu9loW/7
	0yhpzsD1HQVGiTc87am69snxQX0HQLY=
X-Google-Smtp-Source: AMsMyM7D7jA4ElZXk6ISIeD/vjenGfkKLiWWX5UcJmpav3l8eurYWbUSp2IoJz6GBRQY0QttPm1r0A==
X-Received: by 2002:a1c:2543:0:b0:3c6:b7bd:a474 with SMTP id l64-20020a1c2543000000b003c6b7bda474mr33865546wml.95.1666397802441;
        Fri, 21 Oct 2022 17:16:42 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-187-162.46.114.pool.telefonica.de. [46.114.187.162])
        by smtp.googlemail.com with ESMTPSA id l35-20020a05600c1d2300b003b477532e66sm11967085wms.2.2022.10.21.17.16.41
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 21 Oct 2022 17:16:42 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
Date: Sat, 22 Oct 2022 02:16:40 +0200
References: 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
Message-Id: <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MvMMc10G5z3khG
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=mX+RB7Dc;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.97)[-0.966];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N



> Am 21.10.2022 um 22:21 schrieb Mark Millard :
>=20
> On 2022-Oct-21, at 12:53, Mark Millard  wrote:
>=20
>> On 2022-Oct-21, at 10:51, bob prohaska  wrote:
>>=20
>>> Mixed success has been obtained using EDK2 on a pair of Pi3
>>> systems, one running 13-stable and one running -current.=20
>>>=20
>>> The 13-stable machine is at stable/13-ef2aa7753
>>> The -current machine is at main-n258665-e03b7883e97c
>>>=20
>>> The 13-stable machine boots reliably with an EDK2 microSD card
>>> and will boot almost as reliably with no microSD card at all.
>>> This seems true with both JMS561 and JMS578 usb-serial bridges.
>>>=20
>>> The -current machine uses an ASMT bridge and is unresponsive
>>> with either the EDK2 microSD or no microSD at all. It does boot
>>> reliably using the "special bootcode.bin" file from the Pi =
foundation.
>>> It appears to be the newer of the two Pi3's, having a non-latching
>>> microSD receptacle.=20
>>=20
>> Which context does the "need bootcode.bin" problem follow?
>>=20
>> A) Where the ASMT bridge is used vs. not?
>> B) Which RPi3B is used vs. not?
>> C) Which OS version is used vs. not?
>> D) It gets messier to specify if combinations of 2 or more
>>  those need to be specified. I'll not list all the
>>  possibilities.
>>=20
>> Does the newer RPi3B indicate that its USB booting has
>> been enabled? (You may need to use the likes of a
>> RaspiOS variant to check this.)
>>=20
>> I'm confused about the "special bootcode.bin": bootcoce.bin
>> is a normal part of the RPi* firmware, just ignored by
>> RPi4B related RPi*'s that have an alternate means of doing
>> things. Is this the bootcode.bin in the standard RPi*
>> firmware releases? Some other version?
>>=20
>> bootcode.bin always has more recent, bugfixed USB boot code
>> than a RPi3B has built in, as far as I know. The RPi3B's
>> do not have a supported means of updating what is built-in
>> for such functionality. bootcode.bin is used instead.
>>=20
>>=20
>>> On balance EDK2 appears to be useful, or at least having some
>>> promise.
>>=20
>> I'm glad it seems to have helped. But there are things to
>> know.
>>=20
>> Point #0: EDK2 versions and testedness
>>=20
>> The only tested RPi3B EDK2 versions are the ones that the
>> developers release. They do not test EDK2 updates after
>> they make an EDK2 release, at least until they again work
>> on making a new RPi3B EDK2 release.
>>=20
>> Similarly, they do not test using newer RPi* firmware than
>> they bundle. Only a small subset of the overall RPi*
>> firmware is in their RPI3B release. For example, a lack of
>> most of the overlays. They do have references to at least
>> using one overlay that they do not include, as I remember.
>> But use of any other overlays is untested/not-supported as
>> far as I can tell.
>>=20
>> The same goes for the RPi4B related EDK2 releases vs. later
>> EDK2 updates vs. overlays and such.
>>=20
>> The RPi3B vs. RPi4B EDK2 releases are not based on the same
>> vintage of EDK2 materials --or on the same vintage of RPi*
>> materials.
>>=20
>> This means that using the FreeBSD port will not pick out
>> the release-matching EDK2 materials as are in the RPi3B
>> or RPI4B EDK2 releases. Also, the RPi* firmware has to be
>> separately supplied. Overall: an untested combination
>> results, a combination that is unsupported by the RPi3B EDK2
>> developers and the RPi4B EDK2 developers.
>>=20
>> I've no clue if or how well the the port's builds might work.
>>=20
>> Another issue is that some software that is upstream of
>> EDK2 tends to have problems staying inside the C language
>> definition and when this happens, EDK2 builds fail, despite
>> it not being EDK2's own code that needs the fix.
>>=20
>> Point #1: RPi3B microsd slot use is messed up
>>=20
>> In my RPi3B EDK2 related testing, trying to use a microsd
>> card in the RPi3B slot for such can corrupt the contents.
>> It does not even reliably lead to even correct file name
>> displays in ls output.
>>=20
>> By contrast, using a USB reader/writer continued to work
>> just fine.
>>=20
>> So just leave a RPi3B EDK2 microsd card in the slot
>> after booting.
>>=20
>> I've no clue of the status for things like sound and such.
>>=20
>> Point #2: RPi4B does not even start to use the microsd card
>>=20
>> In my RPi4B EDK2 use, microsd card in the slot are not
>> supported --by being ignored as I remember.
>>=20
>> By contrast, using a USB reader/writer continued to work
>> just fine.
>>=20
>> So just leave a RPi4B EDK2 microsd card in the slot
>> after booting.
>>=20
>> I've no clue of the status for things like sound and such.
>>=20
>>=20
>>> Bugzilla traffic suggests work is stalled, can it be
>>> unstuck?
>>>=20
>>=20
>> I expect that at some point that some variation on my
>> patches to allow the builds to at least complete will
>> be committed so the likes of aarch64 FreeBSD builds
>> become possible. (So long as EDK2+its-upstream stays
>> inside the language definition.)
>>=20
>> But I do not know how useful builds are now when built
>> on amd64 or the like --that will also be true for the
>> aarch64 built ones. See the above "Point #0: EDK2
>> versions and testedness" notes.
>>=20
>> It may end up being more effective to stick to
>> downloading and using releases made by the RPi3B EDK2
>> and RPi4B EDK2 folks if EDK2 is to be used for these
>> RPi* families.
>=20
> Side note on what type of video interfaces are in use
> for EDK2, at least for RPi4B EDK2 . . .
>=20
> =46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835
>=20
> QUOTE of jlinton
> It looks fine on my RPI4+PFTF UEFI as well, although it
> should be noted that it's running on the EFI framebuffer
> in both DT and ACPI mode with that firmware.. This
> shouldn't be unexpected. At some point, I will update
> the DT with one that has the vc4 bindings.
> END QUOTE
>=20
> I do not know if RPi3B EDK2 also uses the EFI framebuffer
> for its Device Tree vs. ACPI vs. both modes. EFI
> framebuffer mode would likely be less performant.
>=20
> =E2=80=A6=E2=80=A6=E2=80=A6.

FreeBSD will always run it`s framebuffer driver as long as
there is no VC4 driver implemented in FreeBSD.
So there=E2=80=99s nothing to bind to VC4 in DT nor ACPI.

Regards

Klaus


From nobody Sat Oct 22 19:18:05 2022
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 4Mvrhh4HSnz4fZ0s
	for ; Sat, 22 Oct 2022 19:18:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4Mvrhg185jz4J3Q
	for ; Sat, 22 Oct 2022 19:18:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666466289; bh=+cA+7iMcofnXp1Nb/HS/CS2I8RBh540lYS0lWWUiD54=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T8r+0bEBQSk8WS06wfrsXxpf4HyM+kdaKLG6wKzOE3ry25FG5bnuaCOTm9KyGi2Ws0cfxoy8GpnGCov3HNFKPpGF1yciu5JIJRNknPAM7FXWWZZCCgJr2F37T5bwl/BkzvniKd8LLcD4oiJZpG0MhOnqb5IsbDAKHYIXzTVYO9hUMZFvQFx5fu1MXbBrgkJNAr3qiCy+vV3ubPulT5CYAQbmAJsdLqH8cd48BOkxicpEgwrfqCbdzqOVUhESpCZYxT2J7RDP9JEwHyhY3nWmtrP7g86XllfDWw/zAvu0H9QrcpqdLg8WICzCcxKh3MnmlUi7qzAcbr/s0cNpcNnWFw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666466289; bh=Ge014aem4PsS1XCkXNxmfYFgYJpC768Bb3ayP7OPYsp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uIL3RgweW394E32Y40rdJmAEQvSY0vuPhjhtL+YgK059ZUBAHvXRblBb9MluO6TJoyNiAinIMVFsvYibr8ICguZCHQtlUQ8RLD3XmWMscxoJ2dk8Z2KFFZX+uaqi+NpBRiooNLu3PCitN6V7OYpYwx7FS350iMxLNmWKw4Y4X0gmx0KP0ICDDqnAZKm09UUMnxihAeFxt74KJgsGIKPLqP2bBcUTWaCYpXSorq/fag0qBlz+txDzRkXdDGDDIvHGFBYVLaj+ASgNdlAXA26ofD4F/k2qc5mKNmoi+K5yF9aDsZZS21WVlRep4dzoXhJUf1mhGyhSqpBEq1kpWUSlaA==
X-YMail-OSG: n45g8C0VM1lpDinalW9BhZEcdDKmOYMZxWJKrDPPnTrZMYL.3ULIoDV7dHoA4vg
 Zf.XH3r0oQdkuW6GvA3hHLu972u0rebjccr76iqAhB9SVQoUcXgV4PGpNYPZD6.Z6t_esBFS948n
 qs.jM2bs_2l8dYWY5iWYoRBBEwS8UxW4Tea_BumLe6Jgvo1LmihvzSK5lOJ_qmF0itBU8sYZZfSp
 .zWGLqWbP32.YiDNoMUnaFo092rWpWwEWA3MX_EEVFQnSiGy7MyVbs77SHjWvkzUmnpbm6YSgiOI
 Oe.3eFV7BjCqY4jvzrGXBWVU1tPmGRTHE3toLrsJszKIiDg.LSEGekwN0XcR3SLsD5Hlxv8t4AYM
 AEA_hsQKKq7_JCREcnOneSfo_pgMtRhcg1IArfINf_j.zq.gkEQAzD3FUM0anMMMnWif8AtkRoYk
 DjXeRnyKT3.uirfP8nH6T7BqqvEfyjd.Ql8dvN0hYzG.ORecuiX5vPCwYo9OzO4SGkhgbgm.tMBB
 5GHikMvoCqeC572rU2oBlQTMkUJNyc0Bz9L_zGnnJXZayIr528BOlpG.kTW7ZarOIvVYE2PWpax5
 75IMUNSWBbd9TKKTD3ZpVtxNRTmHsIZVQnf45Y1OAFte3Q_XVZyPMdfoEfg3_BS02KEk66PzhzG4
 8BIdDPeOFs6SoPXyqV1tBF0Oec0gKykN2mKGtr7im02qqlpPVFG5HkXozUQ1CL6ve7riYIL4TmQ3
 5hjDzlAjLtw7Wt.5bkcWTkfsvMb8murmUzGFq0y3l2DHUkINy08wzYoWdQxiQ3CNbKVP8aC7TXIN
 HcdHzxOjkj45q4TCVCdd9Q5o9rQhwxOaQX2piBdscBkuVFGIiuTDTWrOl5lWTAEDDu2OzJzTOOXN
 7ybG0of52HtRnOeR4SHK9qVzPn4vTEknBcDnoAi0wP4ZcSH30R_s4UnKQJHC1W8ApQkMBBJmGvIt
 fFPvKnEx8moh3BlWaCMlIGAa6z32g.OpS3tRR3DmdT5tJq9nDJeC7FOXSYpfUnyJdCnOZ_lVPRR4
 st3dE3IZUrYXU_BdaTSwdNwFwTfeOA.rhMSFAsTrvRc1bPsbbqQloECuf4dNPbHbz98_dJzqiyGA
 3lzp5UOAzQIU3SWiT6jy6SLw7j.xTxxn3_XgAIUHWDwcBoOehBOonJ5qSf50m41QIHswYErCrIJx
 Y8HUTikCo2TlcPsP0KrlwBP2zuIQFCs0b7sjEv18PFs_O0JG08w1Lh9lxxZR1P64jUu7NtFk10dK
 eIp4NCrcIVolt.oh4sclA8GIWpQs_Evv9LjO1mTsDK5TaBoI59C13pMHmlw4s8cAz3KOxX6oyP74
 9OwXEFMWHMqfoevLWVwfMQ6svGi1x7JAqm81rq4uZCyPxyn2UmZvGqIfdEef.oU5QUsCH_nnp4do
 2HYZXlr.77RdOOyt4ddgmcNn_AaV2C3qGFb9BTrQP6a3vya0xxIPrLboinmx9VaIIAlSYjr9Pyj3
 YWaFe5XTvZHLENA.9SE09GIU1F9uEWnW74fw4mERr0YTM5zfOgiYZGoZGFTzyZVgQDdQ1YewTgbR
 tYxKmHq33YawErJogRUICpqPne563x26XBxEKoqj63cS5HbFOiWttriB7dd4SDklYEsj1U6wFA5a
 jUQbd1KhxwghRjOtZt3Eea.U6hx9RYijMnIT.2zmManp8UTS8y2mcQK5jv2T8QhRpsaDt4_VXQei
 1pF_u118XH_R2_lchb.AVHO5wbaQc3n6kMLq.KRfCZZ5WgsUrj1poKkVBKRoqS6QC4qPDu.KvFCm
 KOi4bhfl5Sj5mHs4ybpWhJ7Y_9KoanXgvviSHpjl317oahwAI5WqvS3DnhpW2AxtR4LF_BMvd230
 Gv5KQ4TiBcN4drTkSNF7F.edf6yCjZGocHVHyhYLNbja5Z_5qtw2EsTv3.h18rHuw_m4mQbLMg47
 zMO3O029NnKFAe2j0IBTl1_v0XQ6e_YEukyL.QPZz8K55oeoQESRkd5uT9nj7FBg5hRtT1EezjR1
 s_O8i8FxUkuL8CvjiPMwjJ2L0HikH2MAODLywdtew8A6gdUPu55O1UlWTM5Ty3HsMT5Ly.dwG0nT
 5HSmVcMG1.ltjcTesj94CvKY7EH0m8J.C0c7yx8nDJ9PLTQh_ICv8YnK2eW99StDGrW7gIhld7_R
 o1LR2mFCTzG5i3zNEE46RU1g5EZweyhRJZp5L34oTf4qihY49p_yBEoTLPtcN8HTsrSMPjZR9_fC
 TIwBubihm1zPc0tjpMe8P_1vE5AL16a.eceoEGSFYdj6fKoLoxgNcPXpGbhbbrl.Wv_CxnJX8x8G
 llsxMsow-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 22 Oct 2022 19:18:09 +0000
Received: by hermes--production-gq1-754cb59848-jk2dx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5dcc88b5c944778d452e6cfe97d482e6;
          Sat, 22 Oct 2022 19:18:06 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
Date: Sat, 22 Oct 2022 12:18:05 -0700
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
References: 
 <20221004001857.GA7109@www.zefox.net>
 <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com>
 <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com>
 <20221005034608.GA12761@www.zefox.net>
 <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= ,
 bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mvrhg185jz4J3Q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=T8r+0bEB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	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];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com,www.zefox.net];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-21, at 17:16, Klaus K=C3=BCchemann =
 wrote:

>> Am 21.10.2022 um 22:21 schrieb Mark Millard :
>>=20
>> On 2022-Oct-21, at 12:53, Mark Millard  wrote:
>>=20
>>> On 2022-Oct-21, at 10:51, bob prohaska  wrote:
>>>=20
>>>> Mixed success has been obtained using EDK2 on a pair of Pi3
>>>> systems, one running 13-stable and one running -current.=20
>>>>=20
>>>> The 13-stable machine is at stable/13-ef2aa7753
>>>> The -current machine is at main-n258665-e03b7883e97c
>>>>=20
>>>> The 13-stable machine boots reliably with an EDK2 microSD card
>>>> and will boot almost as reliably with no microSD card at all.
>>>> This seems true with both JMS561 and JMS578 usb-serial bridges.
>>>>=20
>>>> The -current machine uses an ASMT bridge and is unresponsive
>>>> with either the EDK2 microSD or no microSD at all. It does boot
>>>> reliably using the "special bootcode.bin" file from the Pi =
foundation.
>>>> It appears to be the newer of the two Pi3's, having a non-latching
>>>> microSD receptacle.=20
>>>=20
>>> Which context does the "need bootcode.bin" problem follow?
>>>=20
>>> A) Where the ASMT bridge is used vs. not?
>>> B) Which RPi3B is used vs. not?
>>> C) Which OS version is used vs. not?
>>> D) It gets messier to specify if combinations of 2 or more
>>> those need to be specified. I'll not list all the
>>> possibilities.
>>>=20
>>> Does the newer RPi3B indicate that its USB booting has
>>> been enabled? (You may need to use the likes of a
>>> RaspiOS variant to check this.)
>>>=20
>>> I'm confused about the "special bootcode.bin": bootcoce.bin
>>> is a normal part of the RPi* firmware, just ignored by
>>> RPi4B related RPi*'s that have an alternate means of doing
>>> things. Is this the bootcode.bin in the standard RPi*
>>> firmware releases? Some other version?
>>>=20
>>> bootcode.bin always has more recent, bugfixed USB boot code
>>> than a RPi3B has built in, as far as I know. The RPi3B's
>>> do not have a supported means of updating what is built-in
>>> for such functionality. bootcode.bin is used instead.
>>>=20
>>>=20
>>>> On balance EDK2 appears to be useful, or at least having some
>>>> promise.
>>>=20
>>> I'm glad it seems to have helped. But there are things to
>>> know.
>>>=20
>>> Point #0: EDK2 versions and testedness
>>>=20
>>> The only tested RPi3B EDK2 versions are the ones that the
>>> developers release. They do not test EDK2 updates after
>>> they make an EDK2 release, at least until they again work
>>> on making a new RPi3B EDK2 release.
>>>=20
>>> Similarly, they do not test using newer RPi* firmware than
>>> they bundle. Only a small subset of the overall RPi*
>>> firmware is in their RPI3B release. For example, a lack of
>>> most of the overlays. They do have references to at least
>>> using one overlay that they do not include, as I remember.
>>> But use of any other overlays is untested/not-supported as
>>> far as I can tell.
>>>=20
>>> The same goes for the RPi4B related EDK2 releases vs. later
>>> EDK2 updates vs. overlays and such.
>>>=20
>>> The RPi3B vs. RPi4B EDK2 releases are not based on the same
>>> vintage of EDK2 materials --or on the same vintage of RPi*
>>> materials.
>>>=20
>>> This means that using the FreeBSD port will not pick out
>>> the release-matching EDK2 materials as are in the RPi3B
>>> or RPI4B EDK2 releases. Also, the RPi* firmware has to be
>>> separately supplied. Overall: an untested combination
>>> results, a combination that is unsupported by the RPi3B EDK2
>>> developers and the RPi4B EDK2 developers.
>>>=20
>>> I've no clue if or how well the the port's builds might work.
>>>=20
>>> Another issue is that some software that is upstream of
>>> EDK2 tends to have problems staying inside the C language
>>> definition and when this happens, EDK2 builds fail, despite
>>> it not being EDK2's own code that needs the fix.
>>>=20
>>> Point #1: RPi3B microsd slot use is messed up
>>>=20
>>> In my RPi3B EDK2 related testing, trying to use a microsd
>>> card in the RPi3B slot for such can corrupt the contents.
>>> It does not even reliably lead to even correct file name
>>> displays in ls output.
>>>=20
>>> By contrast, using a USB reader/writer continued to work
>>> just fine.
>>>=20
>>> So just leave a RPi3B EDK2 microsd card in the slot
>>> after booting.
>>>=20
>>> I've no clue of the status for things like sound and such.
>>>=20
>>> Point #2: RPi4B does not even start to use the microsd card
>>>=20
>>> In my RPi4B EDK2 use, microsd card in the slot are not
>>> supported --by being ignored as I remember.
>>>=20
>>> By contrast, using a USB reader/writer continued to work
>>> just fine.
>>>=20
>>> So just leave a RPi4B EDK2 microsd card in the slot
>>> after booting.
>>>=20
>>> I've no clue of the status for things like sound and such.
>>>=20
>>>=20
>>>> Bugzilla traffic suggests work is stalled, can it be
>>>> unstuck?
>>>>=20
>>>=20
>>> I expect that at some point that some variation on my
>>> patches to allow the builds to at least complete will
>>> be committed so the likes of aarch64 FreeBSD builds
>>> become possible. (So long as EDK2+its-upstream stays
>>> inside the language definition.)
>>>=20
>>> But I do not know how useful builds are now when built
>>> on amd64 or the like --that will also be true for the
>>> aarch64 built ones. See the above "Point #0: EDK2
>>> versions and testedness" notes.
>>>=20
>>> It may end up being more effective to stick to
>>> downloading and using releases made by the RPi3B EDK2
>>> and RPi4B EDK2 folks if EDK2 is to be used for these
>>> RPi* families.
>>=20
>> Side note on what type of video interfaces are in use
>> for EDK2, at least for RPi4B EDK2 . . .
>>=20
>> =46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835
>>=20
>> QUOTE of jlinton
>> It looks fine on my RPI4+PFTF UEFI as well, although it
>> should be noted that it's running on the EFI framebuffer
>> in both DT and ACPI mode with that firmware.. This
>> shouldn't be unexpected. At some point, I will update
>> the DT with one that has the vc4 bindings.
>> END QUOTE
>>=20
>> I do not know if RPi3B EDK2 also uses the EFI framebuffer
>> for its Device Tree vs. ACPI vs. both modes. EFI
>> framebuffer mode would likely be less performant.
>>=20
>> =E2=80=A6=E2=80=A6=E2=80=A6.
>=20
> FreeBSD will always run it`s framebuffer driver as long as
> there is no VC4 driver implemented in FreeBSD.
> So there=E2=80=99s nothing to bind to VC4 in DT nor ACPI.

Not using more than console mode, other than rare tests
that more is minimally possible, I'd never checked the
detailed status of FreeBSD video drivers for the RPi*'s.

Thanks for the background information,
Mark


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct 23 06:00:19 2022
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 4Mw6xn26Q8z4gCcT
	for ; Sun, 23 Oct 2022 06:00:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30])
	(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 4Mw6xl4G5Tz3qPP
	for ; Sun, 23 Oct 2022 06:00:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666504825; bh=nM709V7PxCP95cLt4UNtoKhxZQEiNBrIpg7rhGCshA4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RhXCUqOz6ly0C75fLCt1oOfU40hlSi0Ehh4FFN4Qw5t48WAXgQEf3xPXJMyGDFvEbsMhmkT8vqHYG4yLtexuPL/KmJ3bNg7mQmFYkKjblYeFohgNlBwUv318Nc/fN1GavesVLioXkszIiHR8V3u5UdzPxjpDBVUH6+XcZ85ru8YY+pb5SkWiUcZhrldtSOx0aQRVc9PAiY26iM9ckCtJd0Qfhk8b5gxCPjGAiXZiP7vX0OVOaYOesPjR2/HSAq3/07Q8lKAKuzc74enfdKV78fNjkw7vuKdWtN8t6KvOVwv+7iVUriasTj0BHVFha1LW6uKuQET6etRVgzLgA1TEGA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666504825; bh=6pFc6NFUA7fDlrmiuo/3agUZVyfvnsKpA36ljzVEcBc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=aICCrG/Hnl0e0zK7bVYLZAodGT1x7ewDPdmR/W0UqGgQChxWq5LDKM+oNLFTKRgsr4ITMKad+DnZoU0GzREINAa7hXtINvz1ztZLLaFOC8UT6NUxzTAAHEn9tipCIhD4JXN6ARQO0NybmPRGtSkmYCKUr6oXtq1yxsT0V6WpeZBoVASIXFLybkUnplOMEYrDMp/1uZuJPywv02FUa/CqegPN3Lko+uApbDeNRKaV6TLYVX8NZlzPriclFN1nI0OUxS3/eAXdxt0rQxVOQtlMKv4PRGqHlX93t9vqjideHZvmTFnrkySmCicK0oKxlR0QpWVN0Nj2BrrfTMown8sP8g==
X-YMail-OSG: kdbi5PAVM1mBRSeNcGz.oLQKGxcwcFrycTK4k7wXRwYF_1kPZhx3s5SP6cdlV8_
 nzFrtW4NG6ZZ9jwTCX2TFPMc5mxvHlIqlI8hJOYB2Kp7KdtreFjvhbtPtNaTqJ4uSsPDFy6Par.V
 v1_v4.bbl0JP2tqBebcvXACjfnnpkfxHa9RKSnPrKfXtSLOlK87aLkwsoqTZNYmNSERgiG8K7_dk
 1P6wBbldson7l6dKAyY9el5xFmHg6pQV82w5vr_h5M2GoDwcDEQ2xTwGv59lFpcGSU.nAYy7q4EQ
 RJ0eMdiMd0OLOiVIyapgLy_5dkEm1.G_BB0dzcfBXtRmqH5cdWSeJCmJKLQJvvhaLdagk3WetSZL
 I0MXFmC39wdyBdwWfoXEsT2gP2IEvFv3x1NBy1FyOg184KMRHW515Z5t6x_HIfJKTt86j4Qr9KVC
 2NTpW4Ve_k6xfZ_UwTcyEXVrVgzJ9OxjkDUWMCzS6cG3Kshy1g9ig7szxlrJGkTF4erODw_jdYwH
 Bq3o6nHo1tclyxfvfWn3M4KE4ftBM6jr.HOGUsJckL7424xM4Z7lBrr28x3Gf98PcfCQZQuMMHxT
 .CEf7f71oSsHfhYvYOi5trvkqmlQpLZSecoI9dIjNOylqM6rGsW6INpnp7OHUSZFD59JKwieBZW5
 HueNLm2yO.tpBUr8xt81c7N1kvXcnJEZsXYgnVauiYKnOyTGc72SQXi4u8oSz25_nP_a_C1xE5on
 RrL29al8dVNpY.z3FxTMa99jMPDgopPhAiZHsldwipnz7DbcXnfBK0iv3rgB8Zs_.xh8iSkI4roZ
 ZFpyLWZ6fQV8OfhZ6rqpL4ovyXwf8uN7fliIDGrjcLf.9wfObqSJ6SWkToBuszH9dA_3acSMOtr1
 vky0kzqKTluN79UmO_.fR4tFj9_czBOy.v3hOL3mIvRAlxP13QdKdIWEDIY21NUHBkGHoh5Qcnx4
 HKWXdDd3kMwahfK.d3tK4plJllGhUF180vLrBZMRVhH6ca0LhSSuHynH1bzbGlJOaQ8kYrO3LbDY
 L2yYAdetVYRmklZdb7gPFDyYOGv..T6K_uLQri9o1cGGdUr9ypvhujSIWIXYX_FyUNSGRPTCU2Hw
 NKO92K2GECZmYOixVTfFJtkyOVUeF06pFvddHNM_wCYCTiKvsXvEUZZX9ZXHSUjlWt4gkQcOUJua
 OBmKzNNIDz2KqOm.tTvRIvmomRHWaGW0nMrGz_M2oPGAyu0AF8ddpMRCVl25Q2w4Opsd7SrtTqGC
 nbfeUPE19wBGKolNEEx9JES4tqHNQMTaAms5spfvyyvmAysrY1gHp8l2mg8ABa9VywuAIawUtCtj
 jQUbRpMfevhgXCAWNhZWSWvUdiSOUnGKuIlznPUCEohqKVcv2C4O22efP3GheHDs65V_RZqAHG0M
 MZzD0dJd9tk0fSbdFz0lSFTBOO6vpKR3eE.iyR1fN.83Rxl1fIl0SLIolLQgiFkVja2hIdRjWeWy
 SfKOCo8GNDSB3YeZlxJThE.Ja7Nbt0fxggeaZy6fglZXvyyeQITWw6Px88zfFcMHa3xpgViWWtgC
 wKsKOmKmPHoTvnFpek1KpQWClpfeP5orQgT_yrH1Fa1BUPret11impLGpnv_sjIg5sdgKbTqqV9q
 8un7AWx8otRi2mTJCs1eCE7FDGuHMuRWUwJttXBmLo9NZY78iMDbbPcVEYLzPFlytrBlXUYg6riU
 syCBGGhnuDdjhkPPMpYjPnbFcLR5hI56HCK.KzEsTGFHH2OQnvGsrDLWj5kDGY5ZIy8B_e1Y2mCw
 OMetSRHA1Usr901cROPEoRbeFLCST1HSqgY.OKEc66WQnixy6NtmSj0kQgZrLS4zvRc8SPCklboP
 qY2W9dO9mlImha1Rij3NDmNS9rjo6SJyf64lQs9DONHpFK5R8jPpMR77y2glAvrLKY1JPrU3.Py8
 gFTQpLSjKH1elp16bjHxJsX3WC6QupT6uR06OioiZst_GY_QY_GqNcSqXss35LMdvlJmvbvKmjuA
 wx.2MTtjndODZupO7NN.3xQysZ4BAfJTIOS28I1YOsCaew2CsvIpYy.V5snWPJSuoLnM3g4icX8R
 ysc.rxUfS_vsOy97DfpwdCnLSq9L_xWRtxaKHTN4HLtFIjTj36XrxmKR1asCewT.6KOpK44p0Anj
 0X6OJ0fJQC7n74.ESqvQaaR1C.3VTbWMtpq0Tbf4uIFJrAXN8qPOTfw7X30IplTNNCVepi9D1893
 25UevShNd4onVtpuMkPK0VcNlnUMMry_DxUuDr_sfxOvXUl.Krcp37PG9ai_TI1kgHATzLoDjZA-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Oct 2022 06:00:25 +0000
Received: by hermes--production-ne1-c47ffd5f5-cr29n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 40f47d1b3681537df2df62980dd32554;
          Sun, 23 Oct 2022 06:00:21 +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 \(3696.120.41.1.1\))
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
From: Mark Millard 
In-Reply-To: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
Date: Sat, 22 Oct 2022 23:00:19 -0700
Cc: Emmanuel Vadot 
Content-Transfer-Encoding: quoted-printable
Message-Id: <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mw6xl4G5Tz3qPP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RhXCUqOz;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Well, turns out that part of the "Import device-tree files
from Linux 5.14" is:

=
https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rock=
chip/rk3328-rock64.dts?id=3D5956d97f4b32

which has:

diff --git =
a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts =
b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
index 3bef1f39bc6e..1b0f7e4551ea 100644
--- a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
+++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
@@ -381,6 +381,11 @@
 	status =3D "okay";
 };
=20
+&usbdrd3 {
+	dr_mode =3D "host";
+	status =3D "okay";
+};
+
 &usb_host0_ehci {
 	status =3D "okay";
 };

usbdrd3 is for USB3, so "host" now has a sort of dtb change
in the interfacing for supporting host-mode USB3. The old:

/usr/main-src/sys/dts/arm64/overlays/rk3328-dwc3.dtso

has, in part:

        usbdrd3: usb@ff600000 {
                compatible =3D "rockchip,rk3328-dwc3";
                clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
                         <&cru ACLK_USB3OTG>;
                clock-names =3D "ref_clk", "suspend_clk",
                              "bus_clk";
                #address-cells =3D <2>;
                #size-cells =3D <2>;
                ranges;
                status =3D "okay";

                usbdrd_dwc3: dwc3@ff600000 {
                        compatible =3D "snps,dwc3";
                        reg =3D <0x0 0xff600000 0x0 0x100000>;
                        interrupts =3D ;
                        dr_mode =3D "host";
                        phy_type =3D "utmi_wide";
                        snps,dis_enblslpm_quirk;
                        snps,dis-u2-freeclk-exists-quirk;
                        snps,dis_u2_susphy_quirk;
                        snps,dis_u3_susphy_quirk;
                        snps,dis-del-phy-power-chg-quirk;
                        snps,dis-tx-ipgap-linecheck-quirk;
                        status =3D "okay";
                };
        };

which looks to me to likely now conflict with the below --given
the added "host" usage as of 5.14 reported above:

/usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328.dtsi

that, as of the 5.13 import, has:

        usbdrd3: usb@ff600000 {
                compatible =3D "rockchip,rk3328-dwc3", "snps,dwc3";
                reg =3D <0x0 0xff600000 0x0 0x100000>;
                interrupts =3D ;
                clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
                         <&cru ACLK_USB3OTG>;
                clock-names =3D "ref_clk", "suspend_clk",
                              "bus_clk";
                dr_mode =3D "otg";
                phy_type =3D "utmi_wide";
                snps,dis-del-phy-power-chg-quirk;
                snps,dis_enblslpm_quirk;
                snps,dis-tx-ipgap-linecheck-quirk;
                snps,dis-u2-freeclk-exists-quirk;
                snps,dis_u2_susphy_quirk;
                snps,dis_u3_susphy_quirk;
                status =3D "disabled";
        };

My guess would be that some kernel changes are required
in order to track this structural changes, not just
avoiding the old .dtbo . Testing showed that disabling
the load of the .dtbo was insufficient to fix things.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Oct 23 14:05:39 2022
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 4MwKjb3nBDz4gSXv
	for ; Sun, 23 Oct 2022 14:05:39 +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 4MwKjb1rnqz3ZMj
	for ; Sun, 23 Oct 2022 14:05:39 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4MwKjb0w6TzvgG
	for ; Sun, 23 Oct 2022 14:05:39 +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 29NE5dOK025487
	for ; Sun, 23 Oct 2022 14:05:39 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29NE5drv025486
	for freebsd-arm@FreeBSD.org; Sun, 23 Oct 2022 14:05:39 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 267292] Support Qualcomm Snapdragon 8cx Gen 3
Date: Sun, 23 Oct 2022 14:05:39 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: zoujiaqing@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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666533939;
	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=48XhOY3F94i9FO9eT4+ovxKyE4uq8Kt4x5YhAXG3egs=;
	b=O7O79KpOVKQInHBKS7JN6vTf199pIJc6Dxw+L+Bz0sKaFpcGhyDf/o5cQMlybhD0gzPL5D
	iWAiE4V8Mtris4jopy4s4KN7aPQpFMcN17Pc/TuKjuMBilfKHkK6xURRXUrr1yIgqYpu4N
	NIyxLAdWzgyUkW4qfW88/X4VqJdWkkQ+KoJ8QT5/Ci/4DcAB7P786u638pVLQ70K001cFd
	D/EI4umC9LKbEUattLNUq7Ac3njGUziuRkJaWC+PLRxexTFauXgCt2mr7PGI/Ame4ryeMx
	dCVRCp/6UVrz+FXQRane+1RS2Grz7MvJdQAt06WH44YOpTV3LVpTYiPeYFXPRw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666533939; a=rsa-sha256; cv=none;
	b=UAJLLNTPOlqY4FlSCERMBJ5Vx/VnTjTHq/MkS0AGNBzVFHeMdALV+RwAN8k9/riYZRGuoD
	rJAkxNXG6Yg1QenvAqdAC2g92zSFiuWniCQa6HrZ74lOeFiaGza3FScT1Wt1TH21p2Z6a7
	kZjMNzi1B+dy3zQu+HJDlbqNNN27Ft7McyrzCTlf+/HMzFMu13iDt81IH0a61M/3p5kIZy
	BKhhL9hgUoS4wtJSQfhva4wwQUi8ZFV1tIdY1SuS2ny25Nvv1YkJuyV6fQ+QaSpskTk7bs
	1o6fTreCho+6VjWMILGX30gSXPSB5XtpbP2mvCMMJM3TPkIVKiXb7ozssQPUzw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267292

            Bug ID: 267292
           Summary: Support Qualcomm Snapdragon 8cx Gen 3
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: zoujiaqing@gmail.com

Rounding out the exciting Arm enablement work in OpenBSD 7.2 is getting ini=
tial
support for the Lenovo ThinkPad X13s Arm laptop and other hardware making u=
se
of the high-end Qualcomm Snapdragon 8cx Gen 3 SoC.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Oct 23 21:00:22 2022
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 4MwVw70SXpz4gJ95
	for ; Sun, 23 Oct 2022 21:00:23 +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 4MwVw63Q8Kz3Cw7
	for ; Sun, 23 Oct 2022 21:00:22 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4MwVw62X7Mz11Hg
	for ; Sun, 23 Oct 2022 21:00:22 +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 29NL0Meh038440
	for ; Sun, 23 Oct 2022 21:00:22 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29NL0MmG038439
	for freebsd-arm@FreeBSD.org; Sun, 23 Oct 2022 21:00:22 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202210232100.29NL0MmG038439@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, 23 Oct 2022 21:00:22 +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="16665588223.AAbC02F4.36386"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666558822;
	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=XeEbLYHE3nYTPEXtoIgo7L+ORU3TI0Z5sPeJ5Rk5Aj0=;
	b=Rz56J8k6LnZ0WERf0fSqW3+354xh6Ll2Vc1J7nSewBIdiXQzijq5Xpy8q+9TAJQptXKzDi
	0g5jaK/jYmrkGYCflSkhxZQxHm5hXDYE2TeumDdCU1vvQpUYZ+pqt/tWK1w8zNYzOLR7OT
	RH9P2cHz9qCruIbK8agk+FIkcs2UCsFdr+jE4F0aHMl7JDjNjDrahSCzrQjZ/fdr+obvcb
	/CnMfAy8Mb2RHcipTdJ6zyDQcQckv69iCZI4BcuwvRuI1xYAACcYKvvuc1JkJuBKG1/0ct
	twMSoQYhpAAFU1cG9uCS8V3lJXnvIVtKpB+9Ab9SSbsBu/B7UnSOAiVelGKkew==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666558822; a=rsa-sha256; cv=none;
	b=oTRrgNtvYCZODBa8DBhffK0UozxyP68pIbdXvWTiAzSW11yw0ehNnpcXms8ojqw+IwLW11
	K/bGSZPVniY23/AvfZxqW+gMnTtRlq5TbcDhVj09nvoikrtTgIjSRxq6S34rBgANc+LXU9
	9VlUWBEPYIimAEHIJtWKgPOkrGApEG9/S5e4DH0CvheRnNnFc5ZmHGrPEcf/CkqVEBzBCr
	Csh7NEsaxC1BPk6iHzHP8GDt0n2deaPMs3wgXwhimZLnUzi/oaZYuwSZIoennSYU1bFI8J
	rAwq+imikZPBWTmlEG45Jrsg9O76wutd9TtvdfMc4JqnZ9kPdHvRUxM8fsWaOw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16665588223.AAbC02F4.36386
Date: Sun, 23 Oct 2022 21:00:22 +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.

--16665588223.AAbC02F4.36386
Date: Sun, 23 Oct 2022 21:00:22 +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.


--16665588223.AAbC02F4.36386--

From nobody Mon Oct 24 17:49:30 2022
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 4Mx2dX6ZWLz4gKXd
	for ; Mon, 24 Oct 2022 17:49:36 +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 4Mx2dW5QX1z3nXb
	for ; Mon, 24 Oct 2022 17:49:35 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29OHnUdt079414
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 24 Oct 2022 10:49:31 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29OHnURJ079413;
	Mon, 24 Oct 2022 10:49:30 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 24 Oct 2022 10:49:30 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann ,
        freebsd-arm 
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3,
 sees disk but won't boot it
Message-ID: <20221024174930.GA79381@www.zefox.net>
References: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@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: <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
X-Rspamd-Queue-Id: 4Mx2dW5QX1z3nXb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	RCPT_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'd like to thank both of you for the light you've shed on the
boot problems encountered with RPi. 

For the moment I'll go back to my original goal of getting
Pi2's to boot from the JMS-based usb-serial bridges presently
on-hand. Preliminary experiments using a JMS561 bridge and
a Pi2 using the version of bootcode.bin located at
https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin
[referring page https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#special-bootcode-bin-only-boot-mode]
seem to be promising under -current.

The interest I expressed in EDK2 appears to have been misguided,
or at least premature. I was hoping it might be a more tractable
replacement for u-boot, but it's equally inscrutable to an amateur.
Worse, only the macciatobin flavor builds under poudriere and
my attempts at a plain "make" build using FLAVOR=rpi3 have so far 
failed on the same host.

With my thanks,

bob prohaska
 

From nobody Mon Oct 24 18:50:11 2022
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 4Mx3zb28hTz4gSS4
	for ; Mon, 24 Oct 2022 18:50:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147])
	(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 4Mx3zZ0gZyz3vby
	for ; Mon, 24 Oct 2022 18:50:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666637416; bh=yqIM6KaTGnxIDWNUNzq4rtRMJojXU19+OsgzQn0pc6U=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=k2zE8MJ5/VaS8ZBYrh78HnJ4kOpN26m+XQp2GN9mVwNSP+RbcPEbi29y+oLNmOLkRsUKvhi9ga6nT/bmlQbF+qUR3WdP6jRrxecs2HWu/dRwUXIKr9YukcHTD7KEaFHiNqw4vGQlJMTWQmnxkTD9r0osKmjxDwgtNKa/V+27P4YXhmLsRlhdetK4sIVYyGHb2S939ROUxEbmKFErphh8CNe9AInPhQS4UTGgvLPEjucq78a2hHSj360CTvmlpQJMc4W3R8KPgHsDvqukCFVjjYpRog8npo28z/i82sqA2/GDOKaEp4tz2ydnFigOEOce3hsPQwzMzxE6iWOWWbfJEg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666637416; bh=Yi/oYFp3WDWaZNQ3CCzUXs2wdw7Gy9DuMTvfg42bhgk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sp8/x8DeiL2QoROnN2liI3dkZt7Ph5zUQG+mUqRWISModZFOOPv0uEgYFrRckYeTYfuptjWUllOmqneVEWOn0zFZGu4Ujz3mxxEp3t0ltW9joxDYLFxOfkgvmt3P6haOD8y8r+0pTbyJjDY3rXuBT5P/NOE79YumDL40hsNa2sXEA+DvLyjBfU5STqSfgPKgG6WsmjG+GQQ2nFe8kOnKjnuZafkbhT1+7Qozpnu2GeVCFWqsIFiSR87PVuVKuCPp/9g1R0nNY4pquXcTlxN7KKyE3CIj5ko/cNK/+fqFriPzktv6R0mKD1Pvm5wrUeuBQ7lPZKW/MYkEYBdUcXoAWA==
X-YMail-OSG: BoTZSBkVM1l1QTPPaIUb0m0nEl2yCygwLDVJLirA2Fn9kyWKKOhXrVdLyGDv6UB
 RSwtyU_K6GdybQbz3fqJJjrHn9bgcT_onZtTHxSgeW_fUF8ZMIY_0d0XhaVK.b3RyUiXS9bPrlQ4
 NqKxWGzYr3X.QSVZAJWaorYN.8acPW2wOp2PWWEqMApW4XMSQh68SO4SN5.jI6rK4Xqclg3PPvzc
 YH_MeDEkbk209TIBl0U5sbasVmr_HgarNBlhApYmAxZPZkDHD1O3sJTIsVJJCJU9o5Ze._dC8KzY
 Pfw34_T8SXBrGBcjp4nFACL1JJn62sYjybA3uVb_qi1MNGMFdVJ_0NsbSpN7nlStAqxJVRZkuaie
 0lYgFEjJAhKHk7C5RuTOFLdI47jkxfqsJTSK6FZOziDMhcOfXU94A1Xw60CbEOiTODdMfigUxKw5
 zEJwvDi0ykhSRVECiAc3oCruEQtTmSGO2pds2f3fShcEO4_eKNDq1j2DRQzn1iKspgFA3dgPE3gC
 ZTFCx6XrKf6ADpyY_TjHtlLNL.ubCy4bDlWWY8lnNfRU7kRM4_bLLp16nBaii__7w6KRiHHGFanZ
 lfgkB.K6hXuK3n3WZswA.AU3iaG0EVtZhafLW5HcohkRHJzjYAofL.ZGOFUtR4kuPNPQZHj2rQAL
 yjXo9HJDy0u2eD6wKHB1TNVg0tv9PoLTkgHZ8gJRb2RBseqP0z81sojLcLuRdYojcVd0Zj9QMddb
 B8lT99sbmOqy0WLFUJCKqo4bJUgMTT8LOtZGiwPKst9Qy6FBrWukXGsyS9VO1ZJpZNwarqjdRGzj
 k3gjMvNj7o7KBmu4eGDFej.IUmtqmdQf8jpkLpsIWY3Ma.Xl10Ochj2uEdw4bRbg96dQrdw6Tbl.
 RRCw9vugK1Onmei7KjzvM3LN5qD5weERHobPdRfQ1P1m_ETpdoPIwBZeMTBYJb5yONw0TgiJgE_p
 7IvrrhuQ8s45x7Q8VEv7M3mlbgupzyO7yhnkQkim.gW6lenuqupEpE5Wb1cDus004icfAIZfkkHO
 0P1E95soPyXLk.TZ2jRIkf.zepOHY4kth5rFTdsuG9oJmtdrNj8.2ZF0dSHcf4NGgHG_23PV2gIx
 atwZ6_Eg3t2czdhtF92Ew_38B0MFoczooJJswkA5NVIoInly.kIK2.czQF.Utcs5_JKLeYLZ7pUc
 fYWkh7qV0b7oH7LAUi7CUtkYzdwQjbfroG8N2bXCC1jaGxlXE4P7egW32IVfhIFwTeZ0RogDAPRL
 9fGPcXFOWLdMaz3BGE9FvDOO8YLrygr30h3t.KJNWmK6wn7jbv2RT.Cidr9PJhsVI1FZ2ls2ITsG
 xpHCBS0WlkHm4dQ3XAbwKcyc7Qi8r3DPLCvuYGUTAkibpGO3cue5EqIUQDdc4XNVdelwjGYwHYJF
 R1D0Hwc26CXE9F84M.1XLXU5W.P1wVM4J1cTDz.S6W0z6QwmFsRtvRyUzrG7MzLf8pAm5cbhJDOE
 IIGOdUOVTHyAdYBwEaiophamjNr7tR8WkvEC0JTwg891n9l1fNxzVJMqO8sQZ6OjDSN9QNVXnhLc
 PMPyPZACJbB9es96NlhC9MsUrzoxnHrdA07IisMKjEbAB9CkO56JuSdRIHyaSvwHB81I6BD.BCNE
 Bf6TDWys2Dv4on5zZMvN1e1HCPVwnU0vR6YAXn1qMfSneebIt4DkBJ8uXWau0vpt7ZheVdC57GeW
 WowU6xybMo83S2S_I6gR2FMvbjIjhnUl0Cm7.JJCV6EPEqr7j9Ori0cgDSGA0.CWlJmsN0NHr6_k
 SRdoyc2Vx4YHpLkEXDSJygxgdtx8olGHlbxjJoXd.uJqoo1EVrKHTPthSAHdGElarwOS5ll3NBkc
 jTSX38fGS9GqDXpHBrm8bteDzPGFazKwgMBkq04AFf4CCZ7IWMJstIIUCrNXbDZZU9yFw62qpITI
 zN9dEiEVM.W7EuSW.GzjXMYW.No9rXkOkuM2dKu6MA64qCGvki2EdkCi6FY4MsJzDjbefNwcCGpN
 iSdr4mBRDsgINsL6o3FmYnadbxViIzTynbUfsbQKURJpX0PDbkNdytKiV_.6xtfYR2Jh00Vg10z7
 JnzxyrXwZXmQpQ0zi0P4gW_sDtxobPMkHlsjEyPiFEcDPT5R5ociMJ0XQugP1JBTYgvw0Z70AvxN
 flzoM6CYVtkjdvNIhqTNK0mAim_SbslcHRX6hi5L9zl0r5LUYHYPW.MP_371TPWpKA9y_JQ4oDVQ
 X0fCqA_V7AtomSMlHFnkcmz1KeuzPJy1METuSf2GzKe_n8KOHn4O6DSi53LgBFxNx5Rw8YB3H
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Oct 2022 18:50:16 +0000
Received: by hermes--production-ne1-c47ffd5f5-cr29n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3872a0a96049c51b9c659f01347ff504;
          Mon, 24 Oct 2022 18:50:12 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <20221024174930.GA79381@www.zefox.net>
Date: Mon, 24 Oct 2022 11:50:11 -0700
Cc: Klaus K??chemann ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com>
 <20221005160737.GA15227@www.zefox.net>
 <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mx3zZ0gZyz3vby
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=k2zE8MJ5;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 66.163.184.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.184.147:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-24, at 10:49, bob prohaska  wrote:

> I'd like to thank both of you for the light you've shed on the
> boot problems encountered with RPi.=20
>=20
> For the moment I'll go back to my original goal of getting
> Pi2's to boot from the JMS-based usb-serial bridges presently
> on-hand. Preliminary experiments using a JMS561 bridge and
> a Pi2 using the version of bootcode.bin located at
> https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin
> [referring page =
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#spec=
ial-bootcode-bin-only-boot-mode]
> seem to be promising under -current.

bootcode.bin is only likely to help stages before
u-boot.bin starts. If it makes to to u-boot.bin
starting, bootcode.bin is then likely irrelevant
from then on.

In fact bootcoce.bin is what loads the start*.elf
that is used. If the start*.elf starts, bootcode.bin
is likely irrelevant past that point.

[The purpose of bootcode.bin is the special boot mode,
more recent versions having more adjustments. There is
no special version of bootcode.bin that I'm aware of.]

> The interest I expressed in EDK2 appears to have been misguided,
> or at least premature. I was hoping it might be a more tractable
> replacement for u-boot, but it's equally inscrutable to an amateur.

> Worse, only the macciatobin flavor builds under poudriere and
> my attempts at a plain "make" build using FLAVOR=3Drpi3 have so far=20
> failed on the same host.

Was this based on mina ports before vs. after:

QUOTE
author	Mark Millard 	2022-10-21 21:47:14 =
+0000
committer	Lorenzo Salvadore 	=
2022-10-21 22:00:03 +0000
commit	819bf69c15605e1e31998c91fb3fd02d5bc9fa0f (patch)
tree	eb19abc8a6fc47da2072bcd9847e3431c4c9ec93 /sysutils/edk2
parent	bf7a619316b5b24fe6a20df07881d7f2bce821d7 (diff)
download	ports-819bf69c15605e1e31998c91fb3fd02d5bc9fa0f.tar.gz
ports-819bf69c15605e1e31998c91fb3fd02d5bc9fa0f.zip
sysutils/edk2: Fix build on aarch64
Build on aarch64 was failing with the following error:

ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by
/usr/local/lib/gcc11/libstdc++.so.6 not found

Fix by using /usr/local/lib/gcc*/libgcc_s.so.1 instead.

While here, also define WWW variable.
END QUOTE

I'll note that quarterly did not get the update yet.

=
http://ampere3.nyi.freebsd.org/build.html?mastername=3D131arm64-default&bu=
ild=3D5bb856165324

shows sysutils/edk2@rpi4 as having successfully built:

=3D>> Building sysutils/edk2
build started at Mon Oct 24 00:09:06 UTC 2022
port directory: /usr/ports/sysutils/edk2
package name: edk2-rpi4-g202202_1
building for: FreeBSD 131arm64-default-job-04 13.1-RELEASE-p2 FreeBSD =
13.1-RELEASE-p2 arm64
maintained by: uboot@FreeBSD.org
Makefile ident:=20
Poudriere version: 3.2.8-21-g883afb07
Host OSVERSION: 1400063
Jail OSVERSION: 1301000
. . .
=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>  Building package for edk2-rpi4-g202202_1
=
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D>> Cleaning up wrkdir
=3D=3D=3D>  Cleaning for edk2-rpi4-g202202_1
build of sysutils/edk2@rpi4 | edk2-rpi4-g202202_1 ended at Mon Oct 24 =
00:16:06 UTC 2022
build time: 00:07:00

(So built under 13.1-RELEASE.)

It also shows sysutils/edk2@fvp has having built just
fine.

@rpi3 and the default build have not started building
yet. 4 flavors (bhve, xen, and 2 qemu variants) are
amd64 only and so are ignored.

(sysutils/uefi-edk2-bhyve-csm is something separate.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 24 19:35:02 2022
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 4Mx4zQ1wmWz4gYph
	for ; Mon, 24 Oct 2022 19:35:14 +0000 (UTC)
	(envelope-from johan@netsense.nl)
Received: from mail.netsense.nl (mail.netsense.nl [45.83.234.235])
	by mx1.freebsd.org (Postfix) with ESMTP id 4Mx4zN6hWfz41QB
	for ; Mon, 24 Oct 2022 19:35:12 +0000 (UTC)
	(envelope-from johan@netsense.nl)
Received: from localhost (localhost [127.0.0.1])
	by mail.netsense.nl (Postfix) with ESMTP id E38B92E9DA
	for ; Mon, 24 Oct 2022 21:35:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netsense.nl; s=mail;
	t=1666640105; bh=EHFJJMGd4TCscuDvsKyZ7XABLO934Af//F8DA52FRWI=;
	h=From:Subject:Date:To:From;
	b=LmGQOTl8iAUyifGpVx5DubarB4GrwhR6DKEFYSI2EnM5W0EuThVQHaUCHj7rSs3Wj
	 vg69Q8DONVJaSO+y560L0OiQlglqiG3Ptk8JKkGKU1q7ysudrR/ml/voGLEi3TODKH
	 JsSmp5h/A3/CypExk5L74vJANROwe7QBdIz14CjDVsRBwnzAoxam2HhoiciiodLjFU
	 tDBq2xaMz1AAj6fQqe0SIspx2PmfKJtGvcBKT4DINdH5HvAox820HP2e3nqurtrdch
	 vOXXNd+9/SLtKWFYBHFlcVPHHl7LyGLzFUpSOs4yw1kmJ7gnF3UfNGpzDFQJgzFcSy
	 chHX1kovVAuVQ==
X-Virus-Scanned: Debian amavisd-new at mail.netsense.nl
Received: from mail.netsense.nl ([127.0.0.1])
	by localhost (mail3.netsense.nl [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id pvPSnfpHv8rI for ;
	Mon, 24 Oct 2022 21:35:04 +0200 (CEST)
Received: from smtpclient.apple (unknown [IPv6:2a10:3781:18cd:1:2:3:4:201])
	by mail.netsense.nl (Postfix) with ESMTPSA id 2CC3C2E9D5
	for ; Mon, 24 Oct 2022 21:35:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netsense.nl; s=mail;
	t=1666640104; bh=EHFJJMGd4TCscuDvsKyZ7XABLO934Af//F8DA52FRWI=;
	h=From:Subject:Date:To:From;
	b=BDpjONONWLZj34lcl80GW8QGbh/VeU7D7IvS1NWdCrASG/2dfy2DyZdKiX05suTfC
	 vugHNeOzaLY+7219QjxCZFBbw13MXJ1dMLLWwBq160s1oclQMy3MumOIXuINUwMYT7
	 3VZelWj9kd1CtIAymmG4LtSqNx5V+wXspcllP778CksNYVXv8anV+5JoWK9LmZBeG5
	 cQDw/DvF6lq5vW/khaGw9rOMenGW2NJOlbbUJeCsBCgACQ8cE3I4cJu6N13BtK8Mkz
	 IGUw0HbVx20JORqmmEoYm27oa48GT/x5+NkO2TZchHBgAnHidro13kGS+1nYk6tFJi
	 EaRDFIZ4OwAPg==
From: Johan Henselmans 
Content-Type: multipart/signed;
	boundary="Apple-Mail=_AA828D83-8C02-41E5-848A-7A6769B0565B";
	protocol="application/pgp-signature";
	micalg=pgp-sha1
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 \(3696.120.41.1.1\))
Subject: BeagleBone uboot: BeagleBone Green Gateway not defined in uboot?
Message-Id: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
Date: Mon, 24 Oct 2022 21:35:02 +0200
To: freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mx4zN6hWfz41QB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=netsense.nl header.s=mail header.b=LmGQOTl8;
	dkim=pass header.d=netsense.nl header.s=mail header.b=BDpjONON;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of johan@netsense.nl designates 45.83.234.235 as permitted sender) smtp.mailfrom=johan@netsense.nl
X-Spamd-Result: default: False [-3.99 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[netsense.nl:s=mail];
	R_SPF_ALLOW(-0.20)[+ip4:45.83.234.235];
	RCVD_NO_TLS_LAST(0.10)[];
	FREEFALL_USER(0.00)[johan];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[netsense.nl];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:206238, ipnet:45.83.232.0/22, country:NL];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[netsense.nl:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_AA828D83-8C02-41E5-848A-7A6769B0565B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have tried to boot a Beaglebone Green Gateway via the current =
GenericSD.img.xz at =
https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAGES/13.0/FreeBS=
D-13.0-RELEASE-arm-armv7-GENERICSD.img.xz

The board booted, but it did not have anything functional in the sense =
of wland or ethernet.

So I installed (after putting the SD-card in a BeagleBone Green, which =
was able to find an ethernet port and a working internet connection) the =
beaglebone uboot:
=3D=3D=3D=3D=3D
pkg install sysutils/u-boot-beaglebone
=3D=3D=3D=3D=3D

That resulted in the message that there was no device tree:
=3D=3D=3D=3D=3D
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **
Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
Model: SeeedStudio BeagleBone Green Gateway:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 0 seconds
board_name=3D[A335BNLT] ...
board_rev=3D[GG1A] ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootarm.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC


No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!
=3D=3D=3D=3D=3D


How can I add a  device tree blob for the BeagleBone Green Gateway?



Kind Regards,
Johan Henselmans




--Apple-Mail=_AA828D83-8C02-41E5-848A-7A6769B0565B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSodLt4EnpKN6iAlsNa7fo9b51glAUCY1bo5wAKCRBa7fo9b51g
lKefAJ9hwgXxxRL7IUUBay0RNT4/kyMBbACaA1N+d7aPTunY3AvX5zwxUq8dZHM=
=EGul
-----END PGP SIGNATURE-----

--Apple-Mail=_AA828D83-8C02-41E5-848A-7A6769B0565B--

From nobody Mon Oct 24 21:05:11 2022
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 4Mx6zS31gJz4glp5
	for ; Mon, 24 Oct 2022 21:05:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-22.consmr.mail.ne1.yahoo.com (sonic306-22.consmr.mail.ne1.yahoo.com [66.163.189.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 4Mx6zQ0WcLz47Rm
	for ; Mon, 24 Oct 2022 21:05:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666645520; bh=Zc/k++H52gi9NPQcV8ZFts5vbgZ1z1HFqvrc1JHnlWE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pcjj1hcTVcVhWnbvouVjqHiSXTfM5u0gcByFVQVpT0c965u9kbEyqdhb0xkFSeZ5W50yQ+P7x1sSDw9a1NfmRSgPhpj1ZaP3oSsoCFtHBhl6PymrLs8XEOAENZy5ssDKtrTkWDFTfNYYA0WD0sdLDiZ0dpaMSBGFQodZAeMuexhrRNxvNynXDI4WwNIN3i8y56PISPJUfcBBwypGiwe6EeRrpL6nYHB/VKwRg5BKQThG2ajzP1+c8M/k/QkUsLbssQxS61+iQgSa45AF3hkj11mz1nyYbN7oiq8Jk8d80OmCwRDK4f+hWmkg8W5OW132yu80s59OenQ1J+Kfovx78Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666645520; bh=c1yj3SK2dMvsSc1FmCz+nO5A4U9g2ydhIMXBf/wT5D7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rp35JIakVV30Y+n73MRD/PREuO3gggc0ypLF6XEcD0LrtclE2qnM8UGHukEb9vGNodB1zXaGgSOFJ+K8o9DVMIkvkbtdQqlDwRRnQdaPLym3WwZp2rTI0aYGJPc6frIuXJNFRLXPxYpfI0adH8wimzOr6zaF35W5+pYBXhxsVrRwRtGCt+dQ8C7DfEAubzGpjjCqbhMD0PgKWbzEfJkJLlbCURgZIYovecRA8PDQO4M7LKirid44u29EI7pzbgV9jir1MbcajO70dNpnVf0hjiAeH8njZfJPEDXKluuQfjoFyrKXngj/9pToEYC7pELD77L5ITbuyRjvEQgk9wZFFg==
X-YMail-OSG: TenhxUMVM1kk9NVwB5gi0x1mqNsPxhR5MnGoq.ljALxNOexm9Omv24YbXlkXpxj
 4bjdQdBFc2hROhIWo8BUf1mD32hQ6EUIzgyB0EarQ65U7HaPJpgKwg.2cKKmlg1oFRJoYRC28dya
 fHiMz4a.AVJTSTS6J5.wwDldLKA0dkKiEJ6fufEWfmAuL4WxCcPhjsWAU3ArXLpqDnMGRGsEqh0F
 WBsuTaQtN0la9K3Z3JagOuYo6y6EI7t8eUnrRD3zGahA4WM5v9_WJDbBIATjvX_5wB9VR.yxOGtX
 cpu6rKJAQJ0XGZcQTA6SzVAOTcBv01OIX9fJJLR8p5rmukIOgPe6mfOdnVZLZ6DQrXC9WELdcLmW
 QtW_50jZ1_QcTVoZUNA7cRXsb3VenjEh0u.aHAMormWeiwNurOn9VtB_YyUygUdWZ6pXryhFlxPD
 oOJW74uOsQUKrIgnykgToXam_jCh33daO.RK4lquSQXWrg_Ho2gff9pspbHwuZ7KPpPVnOfO5Hpj
 zG.AoMEDrrGx7N5L3_jLO5_Ze9uDDUtB8ZGQEAFfIf8xoHSTCXjnIi999brvJGoZC1fDaop6nIpV
 zV3gvLwqowjLRj0V9CXtf2aVxJ6HwpEJ9fHbySzVGX9tdMM5WDnyEk2oypY13ljBGsWq_xVOZsp2
 wNNa9EPTNJpA2.PBXHXGlEnjFNqEZHTqFBGd3qjOWAz2yRXw7QNnyW5DtOOAt_9Qi0OWi48nYiep
 S5K5aQ7J0O3Ap1o4O8UvmVDJcBVMc1D.RIQih81TNzE6zkkuDp3jcFYC40bwC_afThC6XE5.EOg6
 7lzvh37OI5OXV08oHIiZQtTypcv3KZ0a5amarBLYCpvWUS8T6Ig339Cxutf0lUQtXreqvRbhuADl
 iu1WI_62enU3APhBwyQP6TvkK2S7VE7HzAAB4rqfVaFWK2z6itwB9J6EIziiqkOlAYEBcwUwOryQ
 fUckwd5e4tidG2GFtDetFkRhntjiai095bq0x6tLzlIgICyCZrjImCLfDA8udlow6fg8ZJ94bQJZ
 u5_HK7hsMxDdCWVKtSnoguhhY_tHiqL48oCQhez5OxC.NVc0l7BMdXSuo2ovLPJHRmCiGDzgtzOK
 aGDIYuG06Y8SdemNChPBpXrOb1dR4FVrlcgT_0dWl1G6I6.KyScQS711QBFEMOYf_LybnibmwwdU
 3Qb01Um4D5WtZgLIg18xgNrUXvY3vKByNbfOZ6Bgb5CESEW4adCgz_c2kBs3cMKcwgGezDlAQa0G
 PeTLMcbRe4xNoywbHLUZ3EIfuJqpt2NemeloNyXFjg1GIqOI4FkRxwa4oWpXiTnE5OJHZVYD82tS
 XQGMqgYS2wh7eaFSAefZ3rI6wOYVHnyzvcGhTbYTMPsNeoPB2xkKUXttzgxI6JXgdK5poCaNU9TF
 k2nr5DcjEXD85azuMVRKPwZU.hzOzIpwsJiJI6TQ.N9Q4CpsEyhfTBBP5zoC7B5l6V7MKh.AKlyw
 6s18SaAKJpIefwK1MC7Jwoi8G2YuAUlnsbt0yTFC2.7jmtLJjzfyMXJbK17iayaJaCNyGpLlfSXz
 9EzxufzfQ875AO3CBCdzOS4gbiTBShJaqYeRrZanfukB9Xj0KNUI6s5GcC7RTvp_CwkcOxOunVh_
 fd0xcyndF_HkvkyERIADnoiEYyGr9HWePkzrCQdstIyazYHrnT9_pybKN_2oSD3r1kt_tHZNcy1p
 VBywuOGIyKcbQNJnesLq2SPiqkSzUOEKSEjemI2asECY5GHNhaKcp9S99FmYtPqgwNfxPeiBVu3T
 DE5FfOUmd6ljDBt7.Rhl_jES8KCwE5a6B1I_Ta33n20N7jhEGrOZkqCpnfXRiAUp223fJle2kd94
 p01WjWZEOr75dxCc5yu2PG7XgpRDWI_tYr3r8tj53uDYONqmzR6T0fLTWk7t5clfWuxPxLTsHxdI
 0TT_U3PdvM9Pceq2AAdiLx1K5YJj.vVkI0NYRXkH4nWEbAJQAwLb8nKOJgvsPvOWBskVVOnzzLdi
 omJClM3MfwHCNq_Ttk63kJoAIkU2kUdxCMpLQPpuV8y6a0cVfUdSGaZXgBuYmM26uKUHucN5m83l
 5e0.vExZ2kSuazpIaNzdlcIDpOct6kiaNWGvgctwgdiSxv54kdVL0E9LFcEPrS91VOgfCLOsvwW1
 3cGmk7ZdI.yf_3IdSehMOzftVmPe5zMSUud3dKrhBsLqBgAf.pzpda0JUj3.0pwoq.cN7I9XpUJT
 3jBKerVk.BQLmb4RLd9Ut00NS3yP1cEP2DDrKp0DYP8o4Kw44iUErWsmZ2tpppcsWJtuBpxt2yQ-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Oct 2022 21:05:20 +0000
Received: by hermes--production-ne1-c47ffd5f5-8txkx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 89dc10127bf08241d5f8826953146c27;
          Mon, 24 Oct 2022 21:05:14 +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 \(3696.120.41.1.1\))
Subject: Re: BeagleBone uboot: BeagleBone Green Gateway not defined in uboot?
From: Mark Millard 
In-Reply-To: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
Date: Mon, 24 Oct 2022 14:05:11 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <467642CD-DF11-448C-AACA-43F7FB4DB572@yahoo.com>
References: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
To: Johan Henselmans 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mx6zQ0WcLz47Rm
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=pcjj1hcT;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 66.163.189.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.34 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.85)[-0.845];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.189.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.189.84:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-24, at 12:35, Johan Henselmans  wrote:

> I have tried to boot a Beaglebone Green Gateway via the current =
GenericSD.img.xz at =
https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAGES/13.0/FreeBS=
D-13.0-RELEASE-arm-armv7-GENERICSD.img.xz

You list 13.0-RELEASE 's image instead of 13.1-RELEASE 's image:

=
http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-=
RELEASE-arm-armv7-GENERICSD.img.xz

(I've no clue if it makes a difference.)

> The board booted, but it did not have anything functional in the sense =
of wland or ethernet.
>=20
> So I installed (after putting the SD-card in a BeagleBone Green, which =
was able to find an ethernet port and a working internet connection) the =
beaglebone uboot:
> =3D=3D=3D=3D=3D
> pkg install sysutils/u-boot-beaglebone
> =3D=3D=3D=3D=3D

pkg install sysutils/u-boot-beaglebone

only puts things in the likes of:

/usr/local/share/u-boot/u-boot-beaglebone/

/usr/local/share/u-boot/u-boot-beaglebone/ probably ended up
with a README or some such file name for the content shown
below.

# more /usr/ports/sysutils/u-boot-beaglebone/pkg-descr=20
U-Boot loader for BeagleBone and BeagleBone Black.

To install this bootloader, copy the files MLO and bb-uboot.img to the =
FAT
partition on an SD card or the eMMC.  Normally this is partition 1, but
different partitions can be set with U-Boot environment variables.

This version is patched so that:
 * API features are enabled.
 * A boot.scr (U-Boot scripts ) that loads ubldr.bin and execute it is =
included

For information about running FreeBSD on BeagleBone or BeagleBone Black, =
see
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone



You were not explicit. Did you do as described with MLO
and bb-uboot.img ?


> That resulted in the message that there was no device tree:
> =3D=3D=3D=3D=3D
> Loading Environment from EXT4...
> ** Unable to use mmc 0:1 for loading the env **
> Board: BeagleBone Black
>  not set. Validating first E-fuse MAC
> BeagleBone Black:
> Model: SeeedStudio BeagleBone Green Gateway:
> BeagleBone: cape eeprom: i2c_probe: 0x54:
> BeagleBone: cape eeprom: i2c_probe: 0x55:
> BeagleBone: cape eeprom: i2c_probe: 0x56:
> BeagleBone: cape eeprom: i2c_probe: 0x57:
> Net:   eth0: MII MODE
> cpsw, usb_ether
> Press SPACE to abort autoboot in 0 seconds
> board_name=3D[A335BNLT] ...
> board_rev=3D[GG1A] ...
> switch to partitions #0, OK
> mmc0 is current device
> SD/MMC found on device 0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootarm.efi
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>=20
> 
> No valid device tree blob found!
> WARNING! Trying to fire up the kernel, but no device tree blob found!
> =3D=3D=3D=3D=3D
>=20
>=20
> How can I add a  device tree blob for the BeagleBone Green Gateway?
>=20

Note: I've no experience with any BeagleBone variant.
My comments are rather generic.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 24 21:30:11 2022
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 4Mx7XC28VQz4gpW2
	for ; Mon, 24 Oct 2022 21:30:19 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-9.consmr.mail.ne1.yahoo.com (sonic307-9.consmr.mail.ne1.yahoo.com [66.163.190.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 4Mx7XB2QsXz3Brg
	for ; Mon, 24 Oct 2022 21:30:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666647017; bh=sh8bDu2rftf4kFDRKYqdwbO5Dr9Bp8tyUedgQIG3fkg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UaiPEsah1aVmJekOP7wR9OFE6z55i3nGESJmTeiWwXU/IBzzlAHZBNTPzzw28cuKzeugplCObj0iRozwhoaeCKNbIGXS2GdrGRW6mJFYEsTFOZMGjQ+dJbszWqRGIa5W7zx+fLmnFJStjhPcnIrwYpZYjKig/OqwNIZH8CgNiDSf8mCg09rFzIOSG/SUbQyKj8MQBdRqDBr0P7LiXi1Gx2xCbsIAGaPn2GrLacZ4Wf63FuaoAiOCi/qj+w7v+gnWensJVLnFuDd/+k3pKcnhJHZi+bfQ5uq7ikJ/gORYDQ54HjB4O6ShZDRzEZqf9bv62SF9FwkDXMi4cqEz3LZ+ug==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666647017; bh=8HyAvqJZbxUGtR2rwLp8IeRxTdCDfw8qpBoJ/zvbTs0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Hd7WfCweYrDXbbb7yw1Z8GgTIdh00GRwThLbKRDFJByVxP2qudlX1i0+VI51sN46nClxg+/Kd/62n8xmSu05AsmXg7bbLgbYDvf1dzg727kT02rKWYyuDzwt+wlL9MZvVJEiFZxN5dxkkd5tJDGDlT/O21k5NX3oi+W2gigikQ2afWGsme2ia5mAm+AzG6W/L8JPxULvksz4VItqDQZbuP/+ofJ13gEfJSzn54ewN616PE3hMP/XhYtHIDoi+qSwZ+aqFXpCq0KMFyeFh9jh3WDWOsM29sI6a3/aiyETlAnIIX+QcOUvE1DjMTE8Zme9ihwnpY+daVb4J92rxVotNA==
X-YMail-OSG: oaoGZaAVM1nn7twE1izXbeDIAVVpPbTXztfuIboHPrLUAsmK_Vemt7H3npOsw1P
 wq4vrUerwQ.PsrtuURBFLek4TVBu3uQvg7StT6206dJ96oZYPMiT9A.lgvteDNskNpWvtF26IeSS
 EfAqHSgHlqipsKjpY_in.X098_aKOjoU64D27F2j.8EkuFcJTUB3bR3hbtBy_5Aq1bff57t1BFzT
 xIApeLYWl2RTFGOHfwZUN1HuQ5yKfdan2JLvdfeCZJenGnq3KlTdDXKdCKoRmGe0Zlz4Hx3catWB
 q4NgbFNwVn2ZpO52RT2H2vRezZdUx3jSxFLxt58fZh1Ztb0QvxQfgWuKNW_9nOg.0Y6IPhg34kNw
 QntX2JQ0KUl5PfEA_EgbZFb2J57Q.hrAoTTlE0EQjbnUknwKKy610Rtha1GF4BxLg3FdNGn2s2Gb
 r2lciMUWyxXRcpdNc5ITORNJ9wtiePjHNTXwrILQmJL7H2.MaW3JcW42esmOjvDNtbeUub351nJj
 rVJ9yA15Tz4lnxJPhWxv0tXLhlSabQ2XL3G7Y4ju3GMy6zOH._iGk3rR8vxOu9F6q9_CLjTxbDIr
 WLN5ItjXI.9.lz57TOoLzvh9Tgwtc0szliGIG.HeKrqveP_IxCdJEZ2lTPFVCIsm7.5uNgGQQ56G
 q0UWA_N24VP4rCmPHo3fsXTR3mscSwfkOcK3l6Vcm_EOqN.0ngoIah3vOUD2chOCCv8QThdUHJZV
 5L.EuzuD2oq1uH3OTs5QNyIZfXOXqZjQPJp7uTkCBver96iGSrEJkD5cVQOnZJsjNmeggROsPTdT
 uoGI4fo2eo5K55gwuMah8OdHW95UhM.68LA8GqMOOs50ph2s4FKkfL1b_iWmazFdVGLeAH6_S.20
 xm2uYtvssfoah14hWQnlgYjjjROIoXSLuE41STIbpE8EPaoPwlPbkfiWOyjRs2POqmZHBQjTafWK
 ykrGE1dglZ46MDBHybiS1JeTNZUHU1YlqyhjpV3FXqWScqeBHYaCVf6XV361u1yz43Ao5imSyyuR
 K0zs5DL5gKHGxTBBBkJYXCu0dKuvVCRjeGQgSm73z6gI41ZdMfJp5rOMoE2yf2xe6dgzI6e4qfwg
 _ExNY2AXHVHZmQl.CKnsAqGjB85leknUlAVXDSK.B7gGkkb5ClX1iBtU4eggGL3ljrdMfbCsuYVn
 vNv1T2dSDuXsTMkmgUI2E.GuwiQrPe7Rw8UFsxNTolG8UYLHJiPY6Y909P6hyr7NNzYP918QHPJH
 Xima5uMgQhd9rlfeA5VAP6YEkpXK.eweRPqVc5BETLWTu5M_7Ju_49FaJL6yOYBE6o_2r29eEwTT
 8aMKFMbKC_wXAGcNmQe27FF7bmcMsb2D4Kxa_pwJ8LT7RbeGDsbxKMNgkhi0gCBWXiG1dMP7pP9g
 YVp..U7B9eUWRdY4TNb3ESsFVqC5Hcx6eSPsdbvvnygtOfHYhhMHsJxjqcOxNuqsGJ8Wii_cNX4W
 x2YMgVz6DI2IYEvD5.1dx_TO.a9RiNLA7zw6DteQoVwKiJf_9hLhDbm9OTy8Mh2h1aaDvxty3J1k
 QB83cwUjCLyd3q15QwmUDEFsfO8nMTC7KB07SlRxggZAbwKIjE0Oz9yqFrindFLxvuxdHnj5Dx5V
 gJabTQXp3clQ6Csbx1Ar2Yt04uz2E_YDb8o5wNIm5sfV787.A0uChGoDXGJ7kDU2h4Bfplw2MZq8
 OGjDqv8es5Edzb7Apor3ihtn4w4fW8peiMWsQMepmm3gk4yVgz0X8zWn5BweoG_3mldt818gcCBY
 C5YyxyPaRdIfR2lWT_96VmBOuoLYt37VOCZMEG_s2R5JQjIa8PplgFLS5MvVq3ol5GEWkAmU5SjE
 qXnKbFzyLFuHrMnDt3TH5vlzs36qfbda54IIBJ9UQaDMo5J.XrP_lUk0aU8VylaB6DSoD306b7jk
 FENvmT7kZCa0VjKTxhCqX641fm8FeLJ3HaQ97NFp9.H31sgk1fR38qxKWCgtycoPqCQPQiWA9p2V
 r68jTyKJ9ZqXm8EkCFEyTo3XIbXMBNqA4QsLwyi4nc6ewF8m.iI.gQu3EZpkEqME6AGWD4SBR5Ul
 QhIFHJB1QYgCudjFWWYxbZWWyBt4j8VC7T.ujo_xxC1v3YacHaPMs95oP4XdFVnscowqOEFoqB3T
 FUVqeUKUR7LaQ8XjqJsT9X2j28U3VdK2R6Q9QBVBL4tLUzk4e1WB51KmrpKOiJm.Q2yIV08KZWR_
 70dgFRWjufUcbOSblQTPqb5UiK3sEI7PWDS2rft5d.KWF6ySpCB6l3XYjiYBNSdhpvFM86stPdA-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Oct 2022 21:30:17 +0000
Received: by hermes--production-gq1-754cb59848-v9h2d (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5b41ee1f3bd7c4cac8eab738942fc16c;
          Mon, 24 Oct 2022 21:30:11 +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 \(3696.120.41.1.1\))
Subject: Re: BeagleBone uboot: BeagleBone Green Gateway not defined in uboot?
From: Mark Millard 
In-Reply-To: <467642CD-DF11-448C-AACA-43F7FB4DB572@yahoo.com>
Date: Mon, 24 Oct 2022 14:30:11 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <50347B94-0B6D-463C-9B87-499EBEA537D7@yahoo.com>
References: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
 <467642CD-DF11-448C-AACA-43F7FB4DB572@yahoo.com>
To: Johan Henselmans 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mx7XB2QsXz3Brg
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=UaiPEsah;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 66.163.190.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.46 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.96)[-0.962];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.190.32:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-24, at 14:05, Mark Millard  wrote:

> On 2022-Oct-24, at 12:35, Johan Henselmans  wrote:
>=20
>> I have tried to boot a Beaglebone Green Gateway via the current =
GenericSD.img.xz at =
https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAGES/13.0/FreeBS=
D-13.0-RELEASE-arm-armv7-GENERICSD.img.xz
>=20
> You list 13.0-RELEASE 's image instead of 13.1-RELEASE 's image:
>=20
> =
http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-=
RELEASE-arm-armv7-GENERICSD.img.xz
>=20
> (I've no clue if it makes a difference.)
>=20
>> The board booted, but it did not have anything functional in the =
sense of wland or ethernet.
>>=20
>> So I installed (after putting the SD-card in a BeagleBone Green, =
which was able to find an ethernet port and a working internet =
connection) the beaglebone uboot:
>> =3D=3D=3D=3D=3D
>> pkg install sysutils/u-boot-beaglebone
>> =3D=3D=3D=3D=3D
>=20
> pkg install sysutils/u-boot-beaglebone
>=20
> only puts things in the likes of:
>=20
> /usr/local/share/u-boot/u-boot-beaglebone/
>=20
> /usr/local/share/u-boot/u-boot-beaglebone/ probably ended up
> with a README or some such file name for the content shown
> below.
>=20
> # more /usr/ports/sysutils/u-boot-beaglebone/pkg-descr=20
> U-Boot loader for BeagleBone and BeagleBone Black.
>=20
> To install this bootloader, copy the files MLO and bb-uboot.img to the =
FAT
> partition on an SD card or the eMMC.  Normally this is partition 1, =
but
> different partitions can be set with U-Boot environment variables.
>=20
> This version is patched so that:
> * API features are enabled.
> * A boot.scr (U-Boot scripts ) that loads ubldr.bin and execute it is =
included
>=20
> For information about running FreeBSD on BeagleBone or BeagleBone =
Black, see
> https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
>=20
>=20
>=20
> You were not explicit. Did you do as described with MLO
> and bb-uboot.img ?
>=20
>=20
>> That resulted in the message that there was no device tree:
>> =3D=3D=3D=3D=3D
>> Loading Environment from EXT4...
>> ** Unable to use mmc 0:1 for loading the env **
>> Board: BeagleBone Black
>>  not set. Validating first E-fuse MAC
>> BeagleBone Black:
>> Model: SeeedStudio BeagleBone Green Gateway:
>> BeagleBone: cape eeprom: i2c_probe: 0x54:
>> BeagleBone: cape eeprom: i2c_probe: 0x55:
>> BeagleBone: cape eeprom: i2c_probe: 0x56:
>> BeagleBone: cape eeprom: i2c_probe: 0x57:
>> Net:   eth0: MII MODE
>> cpsw, usb_ether
>> Press SPACE to abort autoboot in 0 seconds
>> board_name=3D[A335BNLT] ...
>> board_rev=3D[GG1A] ...
>> switch to partitions #0, OK
>> mmc0 is current device
>> SD/MMC found on device 0
>> switch to partitions #0, OK
>> mmc0 is current device
>> Scanning mmc 0:1...
>> Found EFI removable media binary efi/boot/bootarm.efi
>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>=20
>> 
>> No valid device tree blob found!
>> WARNING! Trying to fire up the kernel, but no device tree blob found!
>> =3D=3D=3D=3D=3D
>>=20
>>=20
>> How can I add a  device tree blob for the BeagleBone Green Gateway?
>>=20
>=20
> Note: I've no experience with any BeagleBone variant.
> My comments are rather generic.
>=20

Hmm, I do not see am335x-bonegreen-gateway.dts in any
of the source code trees I've got for releng/13.0 ,
releng/13.1 , stable/13 , or main [so: 14] :

/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
=
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
=
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts

/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
=
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
=
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts

/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
=
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dts=

/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
=
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dts=

/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts

/usr/main-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
=
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dt=
s
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
=
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dt=
s
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts

Looks like you would have to establish am335x-bonegreen-gateway.dtb
another way as things are.

I also did not find am335x-bonegreen-gateway.dtb in:

https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts/

so it would likely be some time before it shows up there for FreeBSD
to later import.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 25 00:50:12 2022
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 4MxCys4YN6z4g5Cb
	for ; Tue, 25 Oct 2022 00:50: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 4MxCyr488nz3R9T
	for ; Tue, 25 Oct 2022 00:50:12 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 29P0oCCi080473
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 24 Oct 2022 17:50:13 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 29P0oC7u080472;
	Mon, 24 Oct 2022 17:50:12 -0700 (PDT)
	(envelope-from fbsd)
Date: Mon, 24 Oct 2022 17:50:12 -0700
From: bob prohaska 
To: Mark Millard 
Cc: Klaus K??chemann ,
        freebsd-arm 
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3,
 sees disk but won't boot it
Message-ID: <20221025005012.GA80394@www.zefox.net>
References: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
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: 4MxCyr488nz3R9T
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	RCPT_COUNT_THREE(0.00)[3];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:
> 
> bootcode.bin is only likely to help stages before
> u-boot.bin starts. If it makes to to u-boot.bin
> starting, bootcode.bin is then likely irrelevant
> from then on.
> 
> In fact bootcoce.bin is what loads the start*.elf
> that is used. If the start*.elf starts, bootcode.bin
> is likely irrelevant past that point.
> 
I've put the console output at
http://www.zefox.net/~fbsd/rpi2/20221024/boot_console
in case it's of interest. There are a surprising number
of what look like complaints/errors, but it boots anyway.

> 
> > The interest I expressed in EDK2 appears to have been misguided,
> > or at least premature. I was hoping it might be a more tractable
> > replacement for u-boot, but it's equally inscrutable to an amateur.
> 
> 
> Was this based on mina ports before vs. after:
> 
> QUOTE
> author	Mark Millard 	2022-10-21 21:47:14 +0000
> committer	Lorenzo Salvadore 	2022-10-21 22:00:03 +0000
> 

After. Before it failed in the expected way. After, it succeeded, but
built edk2 for macchiatobin that wasn't useful. I couldn't figure out
how to make poudriere attempt to build the needed rpi3 flavor and didn't
find a flavor for rpi2. This was on a Pi4 running -current. 

It's unclear to me if edk2 offers any advantage over u-boot, at least
when u-boot works. I think HPS's changes to usb probably did help, but
won't know for a while yet given the erratic nature of the troubles. 

Thanks for all your help!

bob prohaska


 

From nobody Tue Oct 25 03:32:17 2022
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 4MxHYz6Qhfz4gS1v
	for ; Tue, 25 Oct 2022 03:32:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4MxHYy5rwhz3f94
	for ; Tue, 25 Oct 2022 03:32:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666668740; bh=6Jqvt38KmqcjcTteRd53+HuWzEUSl+1366mHY4GBdCs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Hk6o+Hn3/kAvVF+5KfBY5bj7HbP9kqrOFSXuu3mDR0nscU4CuccfgZncuXTttOdTi09gyJLtH2MnQX9ZXEheQd+BgMiV5lTvLEr7Zf+hBMWm0HtUpu0aGbI5tvwJbFzjs62r2GIFO+c4j9yPy5wEInSpafCWo/+GN3T5F+b6OJnXcixAjdMNW5oQvxXzMaRqZ/hN89+nJ7JryeLSd5GPV1Pdk73I6iHFeQZ/FN9E+++aBADb0CDz7xFzpWEpphkERrAHnwogG8Y2mtchWHFGLp6sdudn5bOqmQndwKNUFe0O4ZVOI+zDSUNe8+3BtoudmiQZZLm/l96XEtIbb+zSfA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666668740; bh=7nGbB98PJcSjm811CtbqdLDa/i9FoKocRysbcJdAihB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=scnjgUxAxjL0JQGs2pWb7BbBHZUN1Hl1nm/+azC0pFnU7KswyYVOELqe6trbPEFMTFynpuXTzY9ZsE71Hb8IxyegnxSZFMuHb2zvw3fISRHyn1eOfMSZ5n49NUPo6PpEMnSqq2Byhw2512PdLuqHFemr+Xrug+4ocH5fJSiT+iPCxNr/TREpmLVdFqa7xitLDRT5sUQRZCKelFLDrhNB855KxvingCFJteMU3SHCYDQbB3SCutspqoQCVaPmU1Lqmj9bI4bz/B8iQsavtYlsxSBFLO5DYqwycrDG3MiSSFIGv/uVIiBY6wKLINHT4HEQgUuI6YR2JTFeJZhU4Ll4Jw==
X-YMail-OSG: WCCTuUcVM1mciabPhjHzqV6d3lzFUac9REvMJpdlNGd._noNqkWKuKGQQeow33u
 Zrt3RAP2a6M_ftGrPsQfMze27uREtLGWwBAwig5j7DFPUomWeWIvC.lrdUOHhX81q6J4AI4fN3u1
 nm8yrpva1GVPIW7W8lBP.S2pwDwXxDRz_xpwUon9a9ZKMfwotSbkKgmKOz96Kxvk6jlTQ2pAKqXQ
 NpYklK8BSu0lsYDwShV73MNmk_exPNugOlct4MWMx5e.BMRt0GfYMoc56eQQiY.l_HA3nmJUQP87
 Wct5hem3Zp2v9H3r5PJCkr0bG_.AixMKb_r2ky4ZLCGLQqR2TEx9KFxlS3dosRElW6FMs5JLIJUV
 W0EDSF4wZuSzYdJ3R_zTCScIJk.cpFSaq1zf0uiHpxr1Iy9_EkklzUdlUspkDMZ1Q_MeYvFbXPyZ
 IQi_92WI5OwW.V6ceY6F8uOtcggVMLunte5kPy2FEEKxSZERZE3BaOfiMR.Ib3hrjpQDj2WKNfFa
 JhiYME7zwfFukANmur0ULoDFw1uVO7D6Nkli9sMsHxsEwnWCvMMeE4NMfjDPxUlgGmaBkLNT7exb
 Pw1t6fKIRVUr78Jq7BiyGfEZKG5CWO6VonynyCsBMrg5jNhxnPr2PAlhMLOHcnPW34.smtM1buYo
 dH4javPe8XG6ae1ctJPnDTZOFv5vmtct9TvdhSr1O6pbQpdPOPSAt7mHOE_J8oGbmC1LqpANMzME
 PndndQW.wSGnG0jCrp6D6coIBFS7ZV1az9zUzBnmZqXXHzrjUPOrdQExoWA0h.jxMrvBsP_auo9W
 e53hNKoLXkk6Ocdmkcfj5aZLszwB15PmWfg_JSvXkfURGcuficqxCnAaEiqiwZAwaPd5qBmuZuQm
 IGfjQJuNZXgUF6yKrjaf3b2msL.zbCtmUKFuJT6gU2sLvaMis77ODXeemN9_e3FVatDAXz3p0ReD
 sVfHXs6L5ugn.kQ8SOW0NouytFvNIqX8SdPR6Z3sg_6Zc3bI32XGFrVlYw3IPzd7C_f6nqJZt641
 fXtIhGuXW3KCvBZz3f11JDB3bWRHHowyfBVfmhQAn.Uw19NBp1ms5RJG.VPdytxyHEvudalwwzdc
 jF8xIz6p_4B5SEXfP6MFcQK8PXu2Nnuhudb5sg.sha4oxv.PhnJ_1H7XhsRgzPzLxkckos9RediA
 JS.Zh6TkNu_i2SJBrr2wZKsCNH1Oj2okfWZy0b2z.f0F9oJ790_XNx7KUIA4rpGsX0x.8rRFFxwR
 FnxDFaGB0KJIhgbja7ZOfC9yQHgCbCP3DmL2JIlhi2qAVgWIk.F4lrBLrNIkTKL_HYjcqySCSQtH
 vcCWyhQ.63gtVA5mdGdqySpd_SssVzhKKS4eJ3aR0fESWaSOYd9wXmXDvwxLyqR0siT4RoTRx3to
 1ArIP7haVPrQ8N3r4B_HNasxjJ97mYWITqUEcB2xg0iPlqKSO6bPlAa2Ka5Wy5Zq3wxq5VlXzU_i
 OrP.nGIbAnFBWQlKC_HkPWy4EopsOxkbmaUbx83THNRZpdcMF.NHk39UVeNnhR6OejzRBB5qg3oF
 Pp8Xg.doFREC_YTnEZvVScg6.W6pHAh6.7AKAwxrxcSlZbihB2hEj8KSp_..IQW9YtidSdfsFEMk
 iZxMuyszNzCvqIfid2cABUHX_a9jadzHvKhBhfNHolcx3iAynCM2opXPm0tGkuXvvD.Rlbim3.1r
 q1chBFa.6Qegw.NF0YbpeShHc.Zzi0P8r578crp4L4XGs4gGK0esKCz7KBNq6MCeleVRN42qt4EX
 54kRTd2A7NE.JtNE2vuoswsdqb.gCoc8qI_eyIOGBtL6AkKbJGqrT_6ivhRRimXkEhAcDuCkqUXO
 _YcDAkooo3vf_HhtZ4DyrtF1a7hh7X0rcLXNA9kmZbclD9hOqME8sEAjKzk5uUYotpUtZRIjT26x
 Nf350K9q228pnoAbdBd2RsDjEP.PTBYP9rIqnsOkATe87Vq2B77kBYYb9iUGw5saSns4nEqxg5yb
 MmRuDi5zfVRszc1BYpZzdn3MbTEgQh5TRAvK8obDBgBatHSFGUt9hDUA1JMdSfXFvpiMROl1aqg4
 TVRUqNq_D_VcZuJlOW.3nd6RYPUt7V3q4Ox43G.atu2ZEoUbevS7jSWa8M2lbd5kPxlVIMpwm1yb
 8fCNMCoqpcuwPEBEcfKNkMSbRvnVrz8f.vai2iBPcEZONkEmK.jxhlymeLaGU7pjaXlHvMC35zrl
 QlqJikVakjquCm1pgO25jePCO7l9Lb5xEgAviWqUxAoLBoGk3OGtYaGswAtvZ7UZAd0iur0Mh8RI
 BIg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Oct 2022 03:32:20 +0000
Received: by hermes--production-gq1-754cb59848-v9h2d (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6df99cd53e913df2e6ac3f87158c192c;
          Tue, 25 Oct 2022 03:32:18 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: <20221025005012.GA80394@www.zefox.net>
Date: Mon, 24 Oct 2022 20:32:17 -0700
Cc: Klaus K??chemann ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
References: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
 <20221025005012.GA80394@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MxHYy5rwhz3f94
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Hk6o+Hn3;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-24, at 17:50, bob prohaska  wrote:

> On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:
>>=20
>> bootcode.bin is only likely to help stages before
>> u-boot.bin starts. If it makes to to u-boot.bin
>> starting, bootcode.bin is then likely irrelevant
>> from then on.
>>=20
>> In fact bootcoce.bin is what loads the start*.elf

Typo fix: bootcode.bin

>> that is used. If the start*.elf starts, bootcode.bin
>> is likely irrelevant past that point.
>>=20
> I've put the console output at
> http://www.zefox.net/~fbsd/rpi2/20221024/boot_console
> in case it's of interest.

It was a RPi2B v1.1 (Cortex-A7 form of armv7).

It was a U-Boot 2022.04 based boot sequence for
the U-Boot stage.

swapon: /dev/sdda0s2b: No such file or directory looks
like us has an incorrect "sd" between "/" and "da0s2b".

I've not seen/noticed the following before:

QUOTE
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib =
/usr/local/lib/compat/pkg /usr/local/lib/compat/pkg
Soft Float compatibility ldconfig path:
ldconfig: illegal option -- o
usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file =
...]
END QUOTE

But, to my knowledge, "Soft Float" is not in use any more
(by default, anyway). It might be that something is left
over from long ago? Looking, I see:

QUOTE
author	Warner Losh 	2022-01-07 05:34:18 +0000
committer	Warner Losh 	2022-01-07 05:34:18 =
+0000
commit	d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)
tree	14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e =
/libexec/rc/rc.d/ldconfig
parent	b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)
download	src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.tar.gz
src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip

libsoft: Remove runtime ldconfig support for libsoft

Remove the runtime support for running ldconfig at boot to cache lists
of libsoft libbraries.
END QUOTE

( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .)

Your /etc/rc.d/ldconfig script seems to have not been updated
by use of etcupdate or mergemaster or other such. (How much
else is also out of date? How much of what you have for /etc/
and the like goes back to 2022-Jan-07 or before?)

> There are a surprising number
> of what look like complaints/errors, but it boots anyway.
>=20
>>=20
>>> The interest I expressed in EDK2 appears to have been misguided,
>>> or at least premature. I was hoping it might be a more tractable
>>> replacement for u-boot, but it's equally inscrutable to an amateur.
>>=20
>>=20
>> Was this based on mina ports before vs. after:

Another wonderful typo of mine: "mina".

>> QUOTE
>> author	Mark Millard 	2022-10-21 =
21:47:14 +0000
>> committer	Lorenzo Salvadore 	=
2022-10-21 22:00:03 +0000
>>=20
>=20
> After. Before it failed in the expected way. After, it succeeded, but
> built edk2 for macchiatobin that wasn't useful. I couldn't figure out
> how to make poudriere attempt to build the needed rpi3 flavor

(The FLAVORS material below is more for providing
background in building flavored ports than for EDK2
specifically, but using EDK2 as the example . . .)

The sysutils/edk2/Makefile has:

FLAVORS=3D        macchiatobin fvp rpi3 rpi4 xen_x64 bhyve qemu_x64 =
qemu_i386

Being listed first, macchiatobin is the default flavor. To specify
a flavor explicitly on the poudriere bulk command, use notation
like one or more of the following on the command line:

sysutils/edk2@macchiatobin
sysutils/edk2@fvp
sysutils/edk2@rpi3
sysutils/edk2@rpi4

So the last 2 of those 4 are the ones that fit your
context. (The later ones in the FLAVORS list have:
ONLY_FOR_ARCHS=3Damd64 .)

Other than flavors handling . . .

I've commented before that I'm not aware of an
armv7 EDK2. So no coverage of an RPi2 v1.1 as
far as I know. ( Also known via any of its
dtb names, such as: bcm2709-rpi-2-b.dtb .
bcm2710-rpi-2-b.dtb is the v1.2 aarch64
variant.)

The RPi3 EDK2 only supplies the RPi* firmware that
it gets via curl when the official RPi3 pftf EDK2
( https://github.com/pftf/RPi3 ) related builds are done:

    - name: Download Raspberry Pi support files
      run: |
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/start.elf
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b.dt=
b
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b-pl=
us.dtb
        curl -O -L =
https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-cm3.dt=
b

(FreeBSD's port does not deal with such things at all.)

So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3
EDK2 would be well behaved with an appropriate vintage
bcm2710-rpi-2-b.dtb added or not. I've never tried
such.

I forgot to mention that the offical RPI4 pftf EDK2
( https://github.com/pftf/RPi4 ) related build has 2
patches to EDK2:

 - name: Patch EDK2 repositories
      run: |
        patch --binary -d edk2 -p1 -i =
../0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch
        patch --binary -d edk2-platforms -p1 -i =
../0002-Check-for-Boot-Discovery-Policy-change.patch

These would not be in the FreeBSD port's build.

FYI, for the RPi4 EDK2:

    - name: Download Raspberry Pi support files
      run: |
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.START_ELF_VERSION }}/boot/fixup4.dat
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.START_ELF_VERSION }}/boot/start4.elf
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION =
}}/boot/bcm2711-rpi-4-b.dtb
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION =
}}/boot/bcm2711-rpi-cm4.dtb
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION =
}}/boot/bcm2711-rpi-400.dtb
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION =
}}/boot/overlays/miniuart-bt.dtbo
        curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION =
}}/boot/overlays/upstream-pi4.dtbo
        mkdir overlays
        mv *.dtbo overlays

(I add and use disable-bt.stbo . They do mention its use in
some instructions someplace.)

> and didn't
> find a flavor for rpi2. This was on a Pi4 running -current.=20

I supplied notes about RPi2B's earlier, above.

> It's unclear to me if edk2 offers any advantage over u-boot, at least
> when u-boot works.

I only suggested EDK2 because U-Boot was not working
well and there might be a chance that EDK2 might work
better for for that stage in one or more of your
detailed contexts. (No claim that this would improve
FreeBSD kernel handling of any RPi*/bridge/drive
combinations --or the earlier RPi* firmware stage.)

If it does not work better for any, I'd suggeste avoiding
being outside the somewhat supported FreeBSD RPi* context:
avoid EDK2.

(I use both styles of booting, but I'm odd.)

I'll note that the main ports has updated U-Boot's
from 2022.04 to 2022.10 . No clue if you might see
behavioral changes for the U-Boot stage if you
update.

Also, Warner L. has checked in a fix for main FreeBSD's
EFI loader build ( in stand/efi/ ) for armv7(/armv6).
The next snapshot for armv7 main [so: 14] should have
it.

> I think HPS's changes to usb probably did help,

Good.

> but
> won't know for a while yet given the erratic nature of the troubles.=20=


Yep.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 25 04:52:51 2022
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 4MxKM63bCSz4gdCL
	for ; Tue, 25 Oct 2022 04:53:06 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4MxKM5350mz3kcX
	for ; Tue, 25 Oct 2022 04:53:05 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ej1-x62f.google.com with SMTP id b2so9689931eja.6
        for ; Mon, 24 Oct 2022 21:53:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=HXLvYBQDUxPWYAmZIQWGTR8xy0p+sBx9wGXvM08donk=;
        b=QeKPORm5vIRyV14J5KmPyVfP4rgiDQ2Fgp7B3X6+GaqSC1VFs7BFVyKnYugHCQUPC2
         JzQEqDNg+Dn2LN8cQ5R47t50P3UNXuPQrBI587XFjaAHQDoYLPYIhDewxTSacGcX7T7z
         gpYh622oKhtNzCTp9/7+ROfIOFeQ+7XIiyfnk1qC/29572y8Ceqs51J+YC4qhXjCamny
         nllE7Fa9/Sr5XuKlTqtb1FoJtDqYLf7q3t3HwkWxxsqLJ7shX/pfO3EGY2EfPWP0M6QG
         zBdIKgQGHletikwXpLjUxmI1xmC9/LOOGB2YPpdVMj0jtU4JQuSdGKrqQcu6EiEZpk5L
         X8JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=HXLvYBQDUxPWYAmZIQWGTR8xy0p+sBx9wGXvM08donk=;
        b=3oUhLvcg+vBfmVuurOr775saLHiXEmTp7xs/tWEBV9I+QXOHew5PTBNFp+orAao6vP
         Nkl/YtP1qEk+NO6F+0lOMl0k9vZ8HT6/3/DQl4uWGVTpTCP2qjt7LJTXzBauKYSRf8Nb
         D/0VWPwYZHzz6R+HaLOjCBDrOSbOGIWX5n00bp4X1Q2QYz1SID2yDcXEZIfz74c1AasM
         XQqE8CCd+9Zi/e8LNyVROr4RyXgTeTjmn4P3DDndeW+hlv2bC5+EVZmDgEHTPMpajyLm
         IIj2M7uPDEAiXEZQJDJiRmW4LyElVhUU/JoQMsaOQ1FSoxwrlPMbigUpn9PmaklepbD7
         sPUw==
X-Gm-Message-State: ACrzQf2Lwy20h04rKubh+bo7SbJCcV2cjRHTGVrQv6LHXB63D7jkPJRk
	IUscpGUuHHx7bp38vkrMcWm1OTxGC48MVPLYLTX2nQ==
X-Google-Smtp-Source: AMsMyM7E+P+Wa8dJpVmwIIzLxVIlXiMArbcz5bEYP7NnbwMr84UoILkDefii8qwgSDiIuocR3Zz/p7+g8JrjhPpvhG4=
X-Received: by 2002:a17:907:d02:b0:7a3:de36:b67 with SMTP id
 gn2-20020a1709070d0200b007a3de360b67mr10705814ejc.451.1666673582972; Mon, 24
 Oct 2022 21:53:02 -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: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com> 
 <20221021175142.GA62386@www.zefox.net> 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com> <20221024174930.GA79381@www.zefox.net>
  <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
In-Reply-To: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
From: Warner Losh 
Date: Mon, 24 Oct 2022 22:52:51 -0600
Message-ID: 
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
To: Mark Millard 
Cc: bob prohaska , "Klaus K??chemann" , 
	freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000deb6c305ebd4aece"
X-Rspamd-Queue-Id: 4MxKM5350mz3kcX
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=QeKPORm5;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FREEMAIL_CC(0.00)[www.zefox.net,googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000deb6c305ebd4aece
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 24, 2022 at 9:32 PM Mark Millard  wrote:

> On 2022-Oct-24, at 17:50, bob prohaska  wrote:
>
> > On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:
> >>
> >> bootcode.bin is only likely to help stages before
> >> u-boot.bin starts. If it makes to to u-boot.bin
> >> starting, bootcode.bin is then likely irrelevant
> >> from then on.
> >>
> >> In fact bootcoce.bin is what loads the start*.elf
>
> Typo fix: bootcode.bin
>
> >> that is used. If the start*.elf starts, bootcode.bin
> >> is likely irrelevant past that point.
> >>
> > I've put the console output at
> > http://www.zefox.net/~fbsd/rpi2/20221024/boot_console
> > in case it's of interest.
>
> It was a RPi2B v1.1 (Cortex-A7 form of armv7).
>
> It was a U-Boot 2022.04 based boot sequence for
> the U-Boot stage.
>
> swapon: /dev/sdda0s2b: No such file or directory looks
> like us has an incorrect "sd" between "/" and "da0s2b".
>
> I've not seen/noticed the following before:
>
> QUOTE
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
> /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg
> Soft Float compatibility ldconfig path:
> ldconfig: illegal option -- o
> usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file
> ...]
> END QUOTE
>
> But, to my knowledge, "Soft Float" is not in use any more
> (by default, anyway). It might be that something is left
> over from long ago? Looking, I see:
>

I was sure that all attempts to use it in FreeBSD 12+ had been removed....


> QUOTE
> author  Warner Losh    2022-01-07 05:34:18 +0000
> committer       Warner Losh    2022-01-07 05:34:18 +0000
> commit  d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)
> tree    14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e /libexec/rc/rc.d/ldconfig
> parent  b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)
> download        src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.tar.gz
> src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip
>
> libsoft: Remove runtime ldconfig support for libsoft
>
> Remove the runtime support for running ldconfig at boot to cache lists
> of libsoft libbraries.
> END QUOTE
>
> ( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .)
>
> Your /etc/rc.d/ldconfig script seems to have not been updated
> by use of etcupdate or mergemaster or other such. (How much
> else is also out of date? How much of what you have for /etc/
> and the like goes back to 2022-Jan-07 or before?)
>

Yea... that seems likely... Can you confirm that I've not messed up
a merge somewhere?


> > There are a surprising number
> > of what look like complaints/errors, but it boots anyway.
> >
> >>
> >>> The interest I expressed in EDK2 appears to have been misguided,
> >>> or at least premature. I was hoping it might be a more tractable
> >>> replacement for u-boot, but it's equally inscrutable to an amateur.
> >>
> >>
> >> Was this based on mina ports before vs. after:
>
> Another wonderful typo of mine: "mina".
>
> >> QUOTE
> >> author       Mark Millard  2022-10-21
> 21:47:14 +0000
> >> committer    Lorenzo Salvadore 
>  2022-10-21 22:00:03 +0000
> >>
> >
> > After. Before it failed in the expected way. After, it succeeded, but
> > built edk2 for macchiatobin that wasn't useful. I couldn't figure out
> > how to make poudriere attempt to build the needed rpi3 flavor
>
> (The FLAVORS material below is more for providing
> background in building flavored ports than for EDK2
> specifically, but using EDK2 as the example . . .)
>
> The sysutils/edk2/Makefile has:
>
> FLAVORS=        macchiatobin fvp rpi3 rpi4 xen_x64 bhyve qemu_x64 qemu_i386
>
> Being listed first, macchiatobin is the default flavor. To specify
> a flavor explicitly on the poudriere bulk command, use notation
> like one or more of the following on the command line:
>
> sysutils/edk2@macchiatobin
> sysutils/edk2@fvp
> sysutils/edk2@rpi3
> sysutils/edk2@rpi4
>
> So the last 2 of those 4 are the ones that fit your
> context. (The later ones in the FLAVORS list have:
> ONLY_FOR_ARCHS=amd64 .)
>
> Other than flavors handling . . .
>
> I've commented before that I'm not aware of an
> armv7 EDK2. So no coverage of an RPi2 v1.1 as
> far as I know. ( Also known via any of its
> dtb names, such as: bcm2709-rpi-2-b.dtb .
> bcm2710-rpi-2-b.dtb is the v1.2 aarch64
> variant.)
>

Yea, we get our UEFI support via u-boot there...

Warner



> The RPi3 EDK2 only supplies the RPi* firmware that
> it gets via curl when the official RPi3 pftf EDK2
> ( https://github.com/pftf/RPi3 ) related builds are done:
>
>     - name: Download Raspberry Pi support files
>       run: |
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/start.elf
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b.dtb
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-3-b-plus.dtb
>         curl -O -L
> https://github.com/raspberrypi/firmware/raw/master/boot/bcm2710-rpi-cm3.dtb
>
> (FreeBSD's port does not deal with such things at all.)
>
> So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3
> EDK2 would be well behaved with an appropriate vintage
> bcm2710-rpi-2-b.dtb added or not. I've never tried
> such.
>
> I forgot to mention that the offical RPI4 pftf EDK2
> ( https://github.com/pftf/RPi4 ) related build has 2
> patches to EDK2:
>
>  - name: Patch EDK2 repositories
>       run: |
>         patch --binary -d edk2 -p1 -i
> ../0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch
>         patch --binary -d edk2-platforms -p1 -i
> ../0002-Check-for-Boot-Discovery-Policy-change.patch
>
> These would not be in the FreeBSD port's build.
>
> FYI, for the RPi4 EDK2:
>
>     - name: Download Raspberry Pi support files
>       run: |
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{
> env.START_ELF_VERSION }}/boot/fixup4.dat
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{
> env.START_ELF_VERSION }}/boot/start4.elf
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION
> }}/boot/bcm2711-rpi-4-b.dtb
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION
> }}/boot/bcm2711-rpi-cm4.dtb
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTB_VERSION
> }}/boot/bcm2711-rpi-400.dtb
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION
> }}/boot/overlays/miniuart-bt.dtbo
>         curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ env.DTBO_VERSION
> }}/boot/overlays/upstream-pi4.dtbo
>         mkdir overlays
>         mv *.dtbo overlays
>
> (I add and use disable-bt.stbo . They do mention its use in
> some instructions someplace.)
>
> > and didn't
> > find a flavor for rpi2. This was on a Pi4 running -current.
>
> I supplied notes about RPi2B's earlier, above.
>
> > It's unclear to me if edk2 offers any advantage over u-boot, at least
> > when u-boot works.
>
> I only suggested EDK2 because U-Boot was not working
> well and there might be a chance that EDK2 might work
> better for for that stage in one or more of your
> detailed contexts. (No claim that this would improve
> FreeBSD kernel handling of any RPi*/bridge/drive
> combinations --or the earlier RPi* firmware stage.)
>
> If it does not work better for any, I'd suggeste avoiding
> being outside the somewhat supported FreeBSD RPi* context:
> avoid EDK2.
>
> (I use both styles of booting, but I'm odd.)
>
> I'll note that the main ports has updated U-Boot's
> from 2022.04 to 2022.10 . No clue if you might see
> behavioral changes for the U-Boot stage if you
> update.
>
> Also, Warner L. has checked in a fix for main FreeBSD's
> EFI loader build ( in stand/efi/ ) for armv7(/armv6).
> The next snapshot for armv7 main [so: 14] should have
> it.
>
> > I think HPS's changes to usb probably did help,
>
> Good.
>
> > but
> > won't know for a while yet given the erratic nature of the troubles.
>
> Yep.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--000000000000deb6c305ebd4aece
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 24, 2022 at 9:32 PM Mark =
Millard <marklmi@yahoo.com> =
wrote:
On 2022-O=
ct-24, at 17:50, bob prohaska <fbsd@www.zefox.net> wrote:



> On Mon, Oct 24, 2022 at 11:50:11AM -0700, Mark Millard wrote:

>> 

>> bootcode.bin is only likely to help stages before

>> u-boot.bin starts. If it makes to to u-boot.bin

>> starting, bootcode.bin is then likely irrelevant

>> from then on.

>> 

>> In fact bootcoce.bin is what loads the start*.elf



Typo fix: bootcode.bin



>> that is used. If the start*.elf starts, bootcode.bin

>> is likely irrelevant past that point.

>> 

> I've put the console output at

> http://www.zefox.net/~fbsd/rpi2/20221024/=
boot_console

> in case it's of interest.



It was a RPi2B v1.1 (Cortex-A7 form of armv7).



It was a U-Boot 2022.04 based boot sequence for

the U-Boot stage.



swapon: /dev/sdda0s2b: No such file or directory looks

like us has an incorrect "sd" between "/" and "da0=
s2b".



I've not seen/noticed the following before:



QUOTE

ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/=
lib/compat/pkg /usr/local/lib/compat/pkg

Soft Float compatibility ldconfig path:

ldconfig: illegal option -- o

usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file ...=
]

END QUOTE



But, to my knowledge, "Soft Float" is not in use any more

(by default, anyway). It might be that something is left

over from long ago? Looking, I see:

I w=
as sure that all attempts to use it in FreeBSD 12+ had been removed....
=C2=A0

QUOTE

author=C2=A0 Warner Losh <imp@FreeBSD.org>=C2=A0 =C2=A02022-01-07 05:=
34:18 +0000

committer=C2=A0 =C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>=C2=
=A0 =C2=A02022-01-07 05:34:18 +0000

commit=C2=A0 d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)

tree=C2=A0 =C2=A0 14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e /libexec/rc/rc.d=
/ldconfig

parent=C2=A0 b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)

download=C2=A0 =C2=A0 =C2=A0 =C2=A0 src-d418bc27e601ec6bba0506d0efb62eca5ed=
a5ab8.tar.gz

src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip



libsoft: Remove runtime ldconfig support for libsoft



Remove the runtime support for running ldconfig at boot to cache lists

of libsoft libbraries.

END QUOTE



( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig .)



Your /etc/rc.d/ldconfig script seems to have not been updated

by use of etcupdate or mergemaster or other such. (How much

else is also out of date? How much of what you have for /etc/

and the like goes back to 2022-Jan-07 or before?)

=

Yea... that seems likely... Can you confirm that I've not me=
ssed up
a merge somewhere?
=C2=A0

> There are a surprising number

> of what look like complaints/errors, but it boots anyway.

> 

>> 

>>> The interest I expressed in EDK2 appears to have been misguide=
d,

>>> or at least premature. I was hoping it might be a more tractab=
le

>>> replacement for u-boot, but it's equally inscrutable to an=
 amateur.

>> 

>> 

>> Was this based on mina ports before vs. after:



Another wonderful typo of mine: "mina".



>> QUOTE

>> author=C2=A0 =C2=A0 =C2=A0 =C2=A0Mark Millard <marklmi26-fbsd@yahoo.com&=
gt; 2022-10-21 21:47:14 +0000

>> committer=C2=A0 =C2=A0 Lorenzo Salvadore <salvadore@FreeBSD.org=
>=C2=A0 =C2=A0 =C2=A0 =C2=A02022-10-21 22:00:03 +0000

>> 

> 

> After. Before it failed in the expected way. After, it succeeded, but<=
br>
> built edk2 for macchiatobin that wasn't useful. I couldn't fig=
ure out

> how to make poudriere attempt to build the needed rpi3 flavor



(The FLAVORS material below is more for providing

background in building flavored ports than for EDK2

specifically, but using EDK2 as the example . . .)



The sysutils/edk2/Makefile has:



FLAVORS=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 macchiatobin fvp rpi3 rpi4 xen_x64 bh=
yve qemu_x64 qemu_i386



Being listed first, macchiatobin is the default flavor. To specify

a flavor explicitly on the poudriere bulk command, use notation

like one or more of the following on the command line:



sysutils/edk2@macchiatobin

sysutils/edk2@fvp

sysutils/edk2@rpi3

sysutils/edk2@rpi4



So the last 2 of those 4 are the ones that fit your

context. (The later ones in the FLAVORS list have:

ONLY_FOR_ARCHS=3Damd64 .)



Other than flavors handling . . .



I've commented before that I'm not aware of an

armv7 EDK2. So no coverage of an RPi2 v1.1 as

far as I know. ( Also known via any of its

dtb names, such as: bcm2709-rpi-2-b.dtb .

bcm2710-rpi-2-b.dtb is the v1.2 aarch64

variant.)

Yea, we get our UEFI support =
via u-boot there...

Warner

=C2=A0

The RPi3 EDK2 only supplies the RPi* firmware that

it gets via curl when the official RPi3 pftf EDK2

( https://github.com/pftf/RPi3 ) related builds are done:



=C2=A0 =C2=A0 - name: Download Raspberry Pi support files

=C2=A0 =C2=A0 =C2=A0 run: |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bootcode.bin=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/fixup.dat
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/start.elf
=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bcm27=
10-rpi-3-b.dtb

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/=
bcm2710-rpi-3-b-plus.dtb

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L https://github.com/raspberrypi/firmware/raw/master/boot/bcm27=
10-rpi-cm3.dtb



(FreeBSD's port does not deal with such things at all.)



So no bcm2710-rpi-2-b.dtb . I do not know if the RPi3

EDK2 would be well behaved with an appropriate vintage

bcm2710-rpi-2-b.dtb added or not. I've never tried

such.



I forgot to mention that the offical RPI4 pftf EDK2

( https://github.com/pftf/RPi4 ) related build has 2

patches to EDK2:



=C2=A0- name: Patch EDK2 repositories

=C2=A0 =C2=A0 =C2=A0 run: |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2 -p1 -i ../0001-MdeModule=
Pkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch

=C2=A0 =C2=A0 =C2=A0 =C2=A0 patch --binary -d edk2-platforms -p1 -i ../0002=
-Check-for-Boot-Discovery-Policy-change.patch



These would not be in the FreeBSD port's build.



FYI, for the RPi4 EDK2:



=C2=A0 =C2=A0 - name: Download Raspberry Pi support files

=C2=A0 =C2=A0 =C2=A0 run: |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.START_ELF_VERSION }}/boot/fixup4.dat

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.START_ELF_VERSION }}/boot/start4.elf

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.DTB_VERSION }}/boot/bcm2711-rpi-4-b.dtb

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.DTB_VERSION }}/boot/bcm2711-rpi-cm4.dtb

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.DTB_VERSION }}/boot/bcm2711-rpi-400.dtb

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.DTBO_VERSION }}/boot/overlays/miniuart-bt.dtbo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 curl -O -L ${{ env.RPI_FIRMWARE_URL }}/raw/${{ =
env.DTBO_VERSION }}/boot/overlays/upstream-pi4.dtbo

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mkdir overlays

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mv *.dtbo overlays



(I add and use disable-bt.stbo . They do mention its use in

some instructions someplace.)



> and didn't

> find a flavor for rpi2. This was on a Pi4 running -current. 



I supplied notes about RPi2B's earlier, above.



> It's unclear to me if edk2 offers any advantage over u-boot, at le=
ast

> when u-boot works.



I only suggested EDK2 because U-Boot was not working

well and there might be a chance that EDK2 might work

better for for that stage in one or more of your

detailed contexts. (No claim that this would improve

FreeBSD kernel handling of any RPi*/bridge/drive

combinations --or the earlier RPi* firmware stage.)



If it does not work better for any, I'd suggeste avoiding

being outside the somewhat supported FreeBSD RPi* context:

avoid EDK2.



(I use both styles of booting, but I'm odd.)



I'll note that the main ports has updated U-Boot's

from 2022.04 to 2022.10 . No clue if you might see

behavioral changes for the U-Boot stage if you

update.



Also, Warner L. has checked in a fix for main FreeBSD's

EFI loader build ( in stand/efi/ ) for armv7(/armv6).

The next snapshot for armv7 main [so: 14] should have

it.



> I think HPS's changes to usb probably did help,



Good.



> but

> won't know for a while yet given the erratic nature of the trouble=
s. 



Yep.





=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--000000000000deb6c305ebd4aece--

From nobody Tue Oct 25 07:25:13 2022
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 4MxNkt2Q0tz4ZnYq
	for ; Tue, 25 Oct 2022 07:25:26 +0000 (UTC)
	(envelope-from johan@netsense.nl)
Received: from mail.netsense.nl (mail.netsense.nl [45.83.234.235])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MxNks3J5jz3Bt3
	for ; Tue, 25 Oct 2022 07:25:25 +0000 (UTC)
	(envelope-from johan@netsense.nl)
Received: from localhost (localhost [127.0.0.1])
	by mail.netsense.nl (Postfix) with ESMTP id ACDD52F33D;
	Tue, 25 Oct 2022 09:25:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netsense.nl; s=mail;
	t=1666682716; bh=KzqEaivFFcaoI3pn1TV0TskKdQNIThYOyr4+vIG7oME=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
	b=Q6qAfYX4zgacw/fQrvoXLlMvgfe3pNLjnJhAmRWQspfkwS/ieINkc95pVg5YzM/lv
	 jcCFRt650xBx5m0QdHAcis5tssj066s5s2L+xKpNHCJ96Rwa9m6SWHbHNseiv66faZ
	 JfQmaR8e/jaIytmo6+hmIkDkiTBjXnqorE9aRiGLMatmY4KMvBDwK75vlU+KyQS5Wb
	 4xlrbR6TKS2TtC+QiEziGIeVnP6hcveO1VUM5qbwuSl0hEf84vophQnevmDbr74c/8
	 ZIEssguMdq+8QBkfFbMuN5GcCEjqxoemmbC2jVJtq2P/Qy+42YSzJQo3N3EagmW2N9
	 xs1grm4nfgAmA==
X-Virus-Scanned: Debian amavisd-new at mail.netsense.nl
Received: from mail.netsense.nl ([127.0.0.1])
	by localhost (mail3.netsense.nl [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 7i4OvkYaJ5Z5; Tue, 25 Oct 2022 09:25:14 +0200 (CEST)
Received: from smtpclient.apple (unknown [IPv6:2a10:3781:18cd:1:2:3:4:201])
	by mail.netsense.nl (Postfix) with ESMTPSA id 72DAD2F38E;
	Tue, 25 Oct 2022 09:25:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netsense.nl; s=mail;
	t=1666682714; bh=KzqEaivFFcaoI3pn1TV0TskKdQNIThYOyr4+vIG7oME=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
	b=I/BwfllcIRJsKOrFpCp8Mzb+0+TgsBqAFFNVQ2N8OH+wo9bG4rVyaRer9SVVL1AEr
	 kUg97suAxnGPecQA3XQOVCUtKczOlT4yHIatURoiJcZHYr3jwAZDEkhu6qfx4Qi9RU
	 Vcb08MViZoQPcKSsPgHvqUl3uodXULw7jhoB4GtADtHMVO2fM///W0qkuabFbJc2Jl
	 x2Gm+8RxWeKUpzoBFJgBL7Fdg9n5bQWukUPNFxmOdWUJRZOgskeTAD44jD5mc3emF3
	 MvC3ooh6dQUP6gvcgPiOnZFgev87gxwNoxZe6gK0DjeE2OPcLbPAhNcRkoSXXeulDZ
	 xNWD+HtshpLfg==
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1A0FD4BD-C46F-4AD8-8ABB-07EE0EDC2E97";
	protocol="application/pgp-signature";
	micalg=pgp-sha1
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 \(3696.120.41.1.1\))
Subject: Re: BeagleBone uboot: BeagleBone Green Gateway not defined in uboot?
From: Johan Henselmans 
In-Reply-To: <50347B94-0B6D-463C-9B87-499EBEA537D7@yahoo.com>
Date: Tue, 25 Oct 2022 09:25:13 +0200
Cc: freebsd-arm@freebsd.org
Message-Id: <1D4FD611-7420-4E52-9414-67F282DDA4C6@netsense.nl>
References: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
 <467642CD-DF11-448C-AACA-43F7FB4DB572@yahoo.com>
 <50347B94-0B6D-463C-9B87-499EBEA537D7@yahoo.com>
To: Mark Millard 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MxNks3J5jz3Bt3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=netsense.nl header.s=mail header.b=Q6qAfYX4;
	dkim=pass header.d=netsense.nl header.s=mail header.b="I/Bwfllc";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of johan@netsense.nl designates 45.83.234.235 as permitted sender) smtp.mailfrom=johan@netsense.nl
X-Spamd-Result: default: False [-4.00 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:45.83.234.235];
	R_DKIM_ALLOW(-0.20)[netsense.nl:s=mail];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEFALL_USER(0.00)[johan];
	DMARC_NA(0.00)[netsense.nl];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:206238, ipnet:45.83.232.0/22, country:NL];
	DKIM_TRACE(0.00)[netsense.nl:+];
	FREEMAIL_TO(0.00)[yahoo.com];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_1A0FD4BD-C46F-4AD8-8ABB-07EE0EDC2E97
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I made some comments in between on both mails.

> On 24 Oct 2022, at 23:30, Mark Millard  wrote:
>=20
> On 2022-Oct-24, at 14:05, Mark Millard  wrote:
>=20
>> On 2022-Oct-24, at 12:35, Johan Henselmans  wrote:
>>=20
>>> I have tried to boot a Beaglebone Green Gateway via the current =
GenericSD.img.xz at =
https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAGES/13.0/FreeBS=
D-13.0-RELEASE-arm-armv7-GENERICSD.img.xz
>>=20
>> You list 13.0-RELEASE 's image instead of 13.1-RELEASE 's image:
>>=20


Sorry, my mistake, the one I downloaded was 13.1, I copied the wrong =
link. Sorry for the confusion.

>> =
http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.1/FreeBSD-13.1-=
RELEASE-arm-armv7-GENERICSD.img.xz
>>=20
>> (I've no clue if it makes a difference.)
>>=20
>>> The board booted, but it did not have anything functional in the =
sense of wland or ethernet.
>>>=20
>>> So I installed (after putting the SD-card in a BeagleBone Green, =
which was able to find an ethernet port and a working internet =
connection) the beaglebone uboot:
>>> =3D=3D=3D=3D=3D
>>> pkg install sysutils/u-boot-beaglebone
>>> =3D=3D=3D=3D=3D
>>=20
>> pkg install sysutils/u-boot-beaglebone
>>=20
>> only puts things in the likes of:
>>=20
>> /usr/local/share/u-boot/u-boot-beaglebone/
>>=20
>> /usr/local/share/u-boot/u-boot-beaglebone/ probably ended up
>> with a README or some such file name for the content shown
>> below.
>>=20
>> # more /usr/ports/sysutils/u-boot-beaglebone/pkg-descr
>> U-Boot loader for BeagleBone and BeagleBone Black.
>>=20
>> To install this bootloader, copy the files MLO and bb-uboot.img to =
the FAT
>> partition on an SD card or the eMMC.  Normally this is partition 1, =
but
>> different partitions can be set with U-Boot environment variables.
>>=20
>> This version is patched so that:
>> * API features are enabled.
>> * A boot.scr (U-Boot scripts ) that loads ubldr.bin and execute it is =
included
>>=20
>> For information about running FreeBSD on BeagleBone or BeagleBone =
Black, see
>> https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
>>=20
>>=20
>>=20
>> You were not explicit. Did you do as described with MLO
>> and bb-uboot.img ?
>>=20


Yes I did. Only thing I did not know how to do was where to put the =
boot.scr that the READMe mentions.

That is why I reran the script on a Beaglebone, hoping that would =
install the script. Mind you, I am not a
pkg specialist. I do not know how to find out how this script is created =
and where it is supposed to put.
I looked in /usr/port/sysutils/u-boot-master and =
/usr/port/sysutils/u-boot-beaglebone, but could not understand
where this boot.scr was supposed to go


>>=20
>>> That resulted in the message that there was no device tree:
>>> =3D=3D=3D=3D=3D
>>> Loading Environment from EXT4...
>>> ** Unable to use mmc 0:1 for loading the env **
>>> Board: BeagleBone Black
>>>  not set. Validating first E-fuse MAC
>>> BeagleBone Black:
>>> Model: SeeedStudio BeagleBone Green Gateway:
>>> BeagleBone: cape eeprom: i2c_probe: 0x54:
>>> BeagleBone: cape eeprom: i2c_probe: 0x55:
>>> BeagleBone: cape eeprom: i2c_probe: 0x56:
>>> BeagleBone: cape eeprom: i2c_probe: 0x57:
>>> Net:   eth0: MII MODE
>>> cpsw, usb_ether
>>> Press SPACE to abort autoboot in 0 seconds
>>> board_name=3D[A335BNLT] ...
>>> board_rev=3D[GG1A] ...
>>> switch to partitions #0, OK
>>> mmc0 is current device
>>> SD/MMC found on device 0
>>> switch to partitions #0, OK
>>> mmc0 is current device
>>> Scanning mmc 0:1...
>>> Found EFI removable media binary efi/boot/bootarm.efi
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>>=20
>>> 
>>> No valid device tree blob found!
>>> WARNING! Trying to fire up the kernel, but no device tree blob =
found!
>>> =3D=3D=3D=3D=3D
>>>=20
>>>=20
>>> How can I add a  device tree blob for the BeagleBone Green Gateway?
>>>=20
>>=20
>> Note: I've no experience with any BeagleBone variant.
>> My comments are rather generic.
>>=20
>=20
> Hmm, I do not see am335x-bonegreen-gateway.dts in any
> of the source code trees I've got for releng/13.0 ,
> releng/13.1 , stable/13 , or main [so: 14] :
>=20
> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
> =
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
> =
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>=20
> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
> =
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
> =
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>=20
> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
> =
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dts=

> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
> =
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dts=

> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>=20
> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
> =
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dt=
s
> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
> =
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dt=
s
> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>=20
> Looks like you would have to establish am335x-bonegreen-gateway.dtb
> another way as things are.
>=20
> I also did not find am335x-bonegreen-gateway.dtb in:
>=20
> https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts/
>=20
> so it would likely be some time before it shows up there for FreeBSD
> to later import.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20
>=20

It seems the Beaglebne stuf is located at =
https://github.com/beagleboard/BeagleBoard-DeviceTrees/

There is a am335x-bonegreen-gateway.dts available over there. I don=E2=80=99=
t know why that stuff is not in torvalds tree.
I know that the debian version is created from =
https://github.com/RobertCNelson/omap-image-builder

So my question would be then revolve around: how can I add that version =
to FreeBSD arm? Is there some procedure
documented somehwere how I should do this?


Kind Regards,
Johan Henselmans




--Apple-Mail=_1A0FD4BD-C46F-4AD8-8ABB-07EE0EDC2E97
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSodLt4EnpKN6iAlsNa7fo9b51glAUCY1ePWQAKCRBa7fo9b51g
lNoeAJ0Uoa5+mwRozFu660ni2vprm+etHwCePHIdeYG58iVUEWTo6/fzuqrf7vc=
=pFAV
-----END PGP SIGNATURE-----

--Apple-Mail=_1A0FD4BD-C46F-4AD8-8ABB-07EE0EDC2E97--

From nobody Tue Oct 25 11:57:44 2022
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 4MxVnD46kQz4gFqd
	for ; Tue, 25 Oct 2022 11:57:52 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MxVnC4G8Xz3dcJ
	for ; Tue, 25 Oct 2022 11:57:51 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 25 Oct 2022 13:57:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1666699064;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=19NEi4K2WkVnwi8JRiiOcpRXpxzXA8OLHAW0aNWGw7U=;
	b=G7MgmeuPv0kLZMHHVqbvQuwuCA4fliMSbiGLBPhq4s2q4YfDGQYvWiO6dfBPRfCAQ46Xlr
	Gwq0yuT9PH4ZOuqKrh0jOQMiCtIItFXdqY/319WEpGSNSCpfgbUohhpqNpCphfUgGVU5qH
	SIHlzxns3NKEMlIk6/5VhtnFqAlrkgAL3L1dJImLGNl27JL0x13RV5F7dsU9TeOWIyOC8X
	yjUZQZLQFFO9YybIoVhcKxHvxtep9nOAzEqPWsEDvcgyxrMdoEb1OlxrYzNTQIcLO0uPrZ
	oK1vXGS1TC84pU1tRGwUqP+nOJ2Q6EFyNViqG+WC5/0tsWTetC7UCRPtyNP8Hw==
From: Ronald Klop 
To: freebsd-arm@freebsd.org
Message-ID: <108673236.151493.1666699064016@localhost>
Subject: wake-on-lan lost from rpi4 (works on rpi3)
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="----=_Part_151491_151081165.1666699063932"
X-Mailer: Realworks (628.35)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MxVnC4G8Xz3dcJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=G7MgmeuP;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_151491_151081165.1666699063932
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.
13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.
13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

Firewall ipfw does not indicate that it blocks anything.

RPI4 runs:
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

genet0: flags=8943 metric 0 mtu 1500
    options=68000b


RPI3 runs:
FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64

ue0: flags=8943 metric 0 mtu 1500
    options=80009


Does genet0 not support these packages?
What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?
genet0 does have a vlan configured connected to a bridge0 for some jails
vlan3: flags=8943 metric 0 mtu 1500
    options=80000
    groups: vlan
    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0

ue0 is itself connected to a bridge0

Regards,
Ronald.
 
------=_Part_151491_151081165.1666699063932
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,



When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.

13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505



When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.

13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505



Firewall ipfw does not indicate that it blocks anything.



RPI4 runs:

FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64



genet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>





RPI3 runs:

FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64



ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>





Does genet0 not support these packages?

What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?

genet0 does have a vlan configured connected to a bridge0 for some jails

vlan3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

    options=80000<LINKSTATE>

    groups: vlan

    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0



ue0 is itself connected to a bridge0



Regards,

Ronald.

 
------=_Part_151491_151081165.1666699063932--

From nobody Tue Oct 25 12:55:05 2022
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 4MxX3P6nWkz4fQh3
	for ; Tue, 25 Oct 2022 12:55:13 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MxX3N5HRbz3jp6
	for ; Tue, 25 Oct 2022 12:55:12 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 29PCt5Sn015686;
	Tue, 25 Oct 2022 07:55:06 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id +tKxNKncV2NEPQAA4+wvSQ
	(envelope-from ); Tue, 25 Oct 2022 07:55:05 -0500
From: Mike Karels 
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
Date: Tue, 25 Oct 2022 07:55:05 -0500
X-Mailer: MailMate (1.14r5921)
Message-ID: <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net>
In-Reply-To: <108673236.151493.1666699064016@localhost>
References: <108673236.151493.1666699064016@localhost>
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: 4MxX3N5HRbz3jp6
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_MISSING_CHARSET(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[karels.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 25 Oct 2022, at 6:57, Ronald Klop wrote:

> Hi,
>
> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ =
my NAS boots and tcpdump shows the following line on my rpi3 as well as o=
n my router.
> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00=
:21:70:46.6cda: ipx-#6cda 65505
>
> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4=
 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on =
my router.
> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00=
:21:70:46.6cda: ipx-#6cda 65505
>
> Firewall ipfw does not indicate that it blocks anything.
>
> RPI4 runs:
> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat=
 Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/rona=
ld/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
>
> genet0: flags=3D8943 me=
tric 0 mtu 1500
>    options=3D68000b
>
>
> RPI3 runs:
> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
>
> ue0: flags=3D8943 metri=
c 0 mtu 1500
>    options=3D80009
>
>
> Does genet0 not support these packages?
> What can prevent this packet to go on the ethernet while tcpdump still =
shows it is outgoing on the interface?
> genet0 does have a vlan configured connected to a bridge0 for some jail=
s
> vlan3: flags=3D8943 met=
ric 0 mtu 1500
>    options=3D80000
>    groups: vlan
>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
>
> ue0 is itself connected to a bridge0

Is the RPI3 also on a vlan and bridge?

Is the router (or switch) expecting the packet on the vlan?
If so, maybe you need to send on vlan3 rather than genet0.

The genet interface has some oddities about packet layouts;
that could be hitting here.  You could try disabling TCP TX
checksum offload: ifconfig genet0 -txcsum -txcsum6; that
simplifies some of the issues.

		Mike

> Regards,
> Ronald.

From nobody Tue Oct 25 14:13:46 2022
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 4MxYp759nMz4ftk1
	for ; Tue, 25 Oct 2022 14:13:51 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MxYp633ZXz3q5H
	for ; Tue, 25 Oct 2022 14:13:50 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 25 Oct 2022 16:13:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1666707228;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=vdOn7Ke5JS3UbuWKoT1ErWoY057ZKXn+Mcp6rqJabPw=;
	b=I7AFRlt+XVISjFMORcVfZSb4XsuVXbIqnK9w+Ior8C12WTyps5LXIl6CDfFd6g7PyXwguw
	e/BSWaufW+aXyb6pNE2eExdOQghqYgMdv3/SeeFqVWH5+jy3Wvx2HhDj0QSULZuiqgfrHn
	7RAdXda9G2K2KYGdBa+5QF9dHoVp6dYLMD5mh56MxKOi3mYAHIqViNRhc2+HSPiPFs2OAq
	TSy8WQQhaOhNbJIcveUdsmxDbeT4w2i4PoLmIJ/KqASmzWMmzvVrp9OA1lIFBznk8GLFDl
	6llkvJKXUGyFHcZ1ToCDum/F3cBl+stWGrIuo5m83f9bfoQlWGiz+KhRH3Mx6g==
From: Ronald Klop 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org
Message-ID: <1407175820.10534.1666707226593@localhost>
In-Reply-To: <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net>
References: <108673236.151493.1666699064016@localhost>
 <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net>
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
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="----=_Part_10533_55839858.1666707226554"
X-Mailer: Realworks (628.35)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MxYp633ZXz3q5H
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=I7AFRlt+;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_10533_55839858.1666707226554
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mike Karels 
Datum: dinsdag, 25 oktober 2022 14:55
Aan: Ronald Klop 
CC: freebsd-arm@freebsd.org
Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> 
> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
> 
> > Hi,
> >
> > When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.
> > 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> >
> > When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.
> > 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> >
> > Firewall ipfw does not indicate that it blocks anything.
> >
> > RPI4 runs:
> > FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
> >
> > genet0: flags=8943 metric 0 mtu 1500
> >    options=68000b
> >
> >
> > RPI3 runs:
> > FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
> >
> > ue0: flags=8943 metric 0 mtu 1500
> >    options=80009
> >
> >
> > Does genet0 not support these packages?
> > What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?
> > genet0 does have a vlan configured connected to a bridge0 for some jails
> > vlan3: flags=8943 metric 0 mtu 1500
> >    options=80000
> >    groups: vlan
> >    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
> >
> > ue0 is itself connected to a bridge0
> 
> Is the RPI3 also on a vlan and bridge?
> 
> Is the router (or switch) expecting the packet on the vlan?
> If so, maybe you need to send on vlan3 rather than genet0.
> 
> The genet interface has some oddities about packet layouts;
> that could be hitting here.  You could try disabling TCP TX
> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
> simplifies some of the issues.
> 
>         Mike
> 
> > Regards,
> > Ronald.


Hi,

Thanks for the hint. I experimented some further.

Disabling -txcsum -rxcsum didn't matter.

But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.

Looking at the driver I found this interesting peace of code.

static int
gen_parse_tx(struct mbuf *m, int csum_flags) {
...
        if (ether_type == ETHERTYPE_IP) {
                COPY(((struct ip *)p)->ip_hl << 2);
                offset += ((struct ip *)p)->ip_hl << 2;
        } else if (ether_type == ETHERTYPE_IPV6) {
                COPY(sizeof(struct ip6_hdr));
                offset += sizeof(struct ip6_hdr);
        } else {
                /*
                 * Unknown whether other cases require moving a header;
                 * ARP works without.
                 */
        }
...
}

There is also some code which handles EHTERTYPE_VLAN.

I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?


Regards,
Ronald.
 
------=_Part_10533_55839858.1666707226554
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Mike Karels <mike@karels.net>

Datum: dinsdag, 25 oktober 2022 14:55

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: freebsd-arm@freebsd.org

Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)







On 25 Oct 2022, at 6:57, Ronald Klop wrote:



> Hi,

>

> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.

> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

>

> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.

> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

>

> Firewall ipfw does not indicate that it blocks anything.

>

> RPI4 runs:

> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

>

> genet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

>    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

>

>

> RPI3 runs:

> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64

>

> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

>    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>

>

>

> Does genet0 not support these packages?

> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?

> genet0 does have a vlan configured connected to a bridge0 for some jails

> vlan3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

>    options=80000<LINKSTATE>

>    groups: vlan

>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0

>

> ue0 is itself connected to a bridge0



Is the RPI3 also on a vlan and bridge?



Is the router (or switch) expecting the packet on the vlan?

If so, maybe you need to send on vlan3 rather than genet0.



The genet interface has some oddities about packet layouts;

that could be hitting here.  You could try disabling TCP TX

checksum offload: ifconfig genet0 -txcsum -txcsum6; that

simplifies some of the issues.



        Mike



> Regards,

> Ronald.









Hi,



Thanks for the hint. I experimented some further.



Disabling -txcsum -rxcsum didn't matter.



But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.



Looking at the driver I found this interesting peace of code.



static int

gen_parse_tx(struct mbuf *m, int csum_flags) {

...

        if (ether_type == ETHERTYPE_IP) {

                COPY(((struct ip *)p)->ip_hl << 2);

                offset += ((struct ip *)p)->ip_hl << 2;

        } else if (ether_type == ETHERTYPE_IPV6) {

                COPY(sizeof(struct ip6_hdr));

                offset += sizeof(struct ip6_hdr);

        } else {

                /*

                 * Unknown whether other cases require moving a header;

                 * ARP works without.

                 */

        }

...

}



There is also some code which handles EHTERTYPE_VLAN.



I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?





Regards,

Ronald.

 
------=_Part_10533_55839858.1666707226554--

From nobody Tue Oct 25 15:22:38 2022
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 4MxbKZ43Z2z4g5mW
	for ; Tue, 25 Oct 2022 15:22:42 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MxbKY4W6Wz42V9
	for ; Tue, 25 Oct 2022 15:22:41 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 29PFMdLl016344;
	Tue, 25 Oct 2022 10:22:40 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id yP0ZHT//V2PWPwAA4+wvSQ
	(envelope-from ); Tue, 25 Oct 2022 10:22:39 -0500
From: Mike Karels 
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
Date: Tue, 25 Oct 2022 10:22:38 -0500
X-Mailer: MailMate (1.14r5921)
Message-ID: <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net>
In-Reply-To: <1407175820.10534.1666707226593@localhost>
References: <108673236.151493.1666699064016@localhost>
 <64FDF71E-B0B8-4625-833E-CCA62785DEB4@karels.net>
 <1407175820.10534.1666707226593@localhost>
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: 4MxbKY4W6Wz42V9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[karels.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 25 Oct 2022, at 9:13, Ronald Klop wrote:

> Van: Mike Karels 
> Datum: dinsdag, 25 oktober 2022 14:55
> Aan: Ronald Klop 
> CC: freebsd-arm@freebsd.org
> Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>>
>> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
>>
>>> Hi,
>>>
>>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B=
+ my NAS boots and tcpdump shows the following line on my rpi3 as well as=
 on my router.
>>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:=
00:21:70:46.6cda: ipx-#6cda 65505
>>>
>>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RP=
I4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* o=
n my router.
>>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:=
00:21:70:46.6cda: ipx-#6cda 65505
>>>
>>> Firewall ipfw does not indicate that it blocks anything.
>>>
>>> RPI4 runs:
>>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: S=
at Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ro=
nald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
>>>
>>> genet0: flags=3D8943 =
metric 0 mtu 1500
>>>    options=3D68000b
>>>
>>>
>>> RPI3 runs:
>>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
>>>
>>> ue0: flags=3D8943 met=
ric 0 mtu 1500
>>>    options=3D80009
>>>
>>>
>>> Does genet0 not support these packages?
>>> What can prevent this packet to go on the ethernet while tcpdump stil=
l shows it is outgoing on the interface?
>>> genet0 does have a vlan configured connected to a bridge0 for some ja=
ils
>>> vlan3: flags=3D8943 m=
etric 0 mtu 1500
>>>    options=3D80000
>>>    groups: vlan
>>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
>>>
>>> ue0 is itself connected to a bridge0
>>
>> Is the RPI3 also on a vlan and bridge?
>>
>> Is the router (or switch) expecting the packet on the vlan?
>> If so, maybe you need to send on vlan3 rather than genet0.
>>
>> The genet interface has some oddities about packet layouts;
>> that could be hitting here.  You could try disabling TCP TX
>> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
>> simplifies some of the issues.
>>
>>         Mike
>>
>>> Regards,
>>> Ronald.
>
>
> Hi,
>
> Thanks for the hint. I experimented some further.
>
> Disabling -txcsum -rxcsum didn't matter.

-rxcsum doesn=E2=80=99t matter, but you need to do -txcsum6 as well as
-txcsum.  (See the code that calls gen_parse_tx.)

> But when I use bridge0 or vlan3 as device then it goes into the wire bu=
t on the VLAN which is not where my NAS is which I want to boot.
>
> Looking at the driver I found this interesting peace of code.
>
> static int
> gen_parse_tx(struct mbuf *m, int csum_flags) {
> ...
>        if (ether_type =3D=3D ETHERTYPE_IP) {
>                COPY(((struct ip *)p)->ip_hl << 2);
>                offset +=3D ((struct ip *)p)->ip_hl << 2;
>        } else if (ether_type =3D=3D ETHERTYPE_IPV6) {
>                COPY(sizeof(struct ip6_hdr));
>                offset +=3D sizeof(struct ip6_hdr);
>        } else {
>                /*
>                 * Unknown whether other cases require moving a header;
>                 * ARP works without.
>                 */
>        }
> ...
> }
>
> There is also some code which handles EHTERTYPE_VLAN.
>
> I don't have time to start debugging this today. But would this ring a =
bell to anybody in connection to a wake-on-lan packet?

I ran some experiments with tx checksum disabled, and it seems to
matter.  I have a change for the last block you listed that might
help, but I haven=E2=80=99t tested it yet.

		Mike

> Regards,
> Ronald.

From nobody Tue Oct 25 16:11:54 2022
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 4MxcQN5fg6z4gCpf
	for ; Tue, 25 Oct 2022 16:11:56 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MxcQM6LF1z49Wh
	for ; Tue, 25 Oct 2022 16:11:55 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 29PGBsGq016682
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 25 Oct 2022 11:11:55 -0500 (CDT)
	(envelope-from mike@mail.karels.net)
Received: (from mike@localhost)
	by mail.karels.net (8.16.1/8.16.1/Submit) id 29PGBsbq016681;
	Tue, 25 Oct 2022 11:11:54 -0500 (CDT)
	(envelope-from mike)
Message-Id: <202210251611.29PGBsbq016681@mail.karels.net>
To: Ronald Klop 
cc: freebsd-arm@freebsd.org
From: Mike Karels 
Reply-to: mike@karels.net
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
In-reply-to: Your message of Tue, 25 Oct 2022 10:22:38 -0500.
             <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net>
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-ID: <16679.1666714314.1@mail.karels.net>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Oct 2022 11:11:54 -0500
X-Rspamd-Queue-Id: 4MxcQM6LF1z49Wh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net
X-Spamd-Result: default: False [-1.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	HAS_REPLYTO(0.00)[mike@karels.net];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[karels.net];
	FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]
X-ThisMailContainsUnwantedMimeParts: N

I wrote:
> On 25 Oct 2022, at 9:13, Ronald Klop wrote:

> > Van: Mike Karels 
> > Datum: dinsdag, 25 oktober 2022 14:55
> > Aan: Ronald Klop 
> > CC: freebsd-arm@freebsd.org
> > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> >>
> >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
> >>
> >>> Hi,
> >>>
> >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3=
B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as=
 on my router.
> >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da=
:00:21:70:46.6cda: ipx-#6cda 65505
> >>>
> >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my R=
PI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* o=
n my router.
> >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da=
:00:21:70:46.6cda: ipx-#6cda 65505
> >>>
> >>> Firewall ipfw does not indicate that it blocks anything.
> >>>
> >>> RPI4 runs:
> >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: =
Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ro=
nald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
> >>>
> >>> genet0: flags=3D8943=
 metric 0 mtu 1500
> >>>    options=3D68000b
> >>>
> >>>
> >>> RPI3 runs:
> >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
> >>>
> >>> ue0: flags=3D8943 me=
tric 0 mtu 1500
> >>>    options=3D80009
> >>>
> >>>
> >>> Does genet0 not support these packages?
> >>> What can prevent this packet to go on the ethernet while tcpdump sti=
ll shows it is outgoing on the interface?
> >>> genet0 does have a vlan configured connected to a bridge0 for some j=
ails
> >>> vlan3: flags=3D8943 =
metric 0 mtu 1500
> >>>    options=3D80000
> >>>    groups: vlan
> >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
> >>>
> >>> ue0 is itself connected to a bridge0
> >>
> >> Is the RPI3 also on a vlan and bridge?
> >>
> >> Is the router (or switch) expecting the packet on the vlan?
> >> If so, maybe you need to send on vlan3 rather than genet0.
> >>
> >> The genet interface has some oddities about packet layouts;
> >> that could be hitting here.  You could try disabling TCP TX
> >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
> >> simplifies some of the issues.
> >>
> >>         Mike
> >>
> >>> Regards,
> >>> Ronald.
> >
> >
> > Hi,
> >
> > Thanks for the hint. I experimented some further.
> >
> > Disabling -txcsum -rxcsum didn't matter.

> -rxcsum doesn't matter, but you need to do -txcsum6 as well as
> -txcsum.  (See the code that calls gen_parse_tx.)

> > But when I use bridge0 or vlan3 as device then it goes into the wire b=
ut on the VLAN which is not where my NAS is which I want to boot.
> >
> > Looking at the driver I found this interesting peace of code.
> >
> > static int
> > gen_parse_tx(struct mbuf *m, int csum_flags) {
> > ...
> >        if (ether_type =3D=3D ETHERTYPE_IP) {
> >                COPY(((struct ip *)p)->ip_hl << 2);
> >                offset +=3D ((struct ip *)p)->ip_hl << 2;
> >        } else if (ether_type =3D=3D ETHERTYPE_IPV6) {
> >                COPY(sizeof(struct ip6_hdr));
> >                offset +=3D sizeof(struct ip6_hdr);
> >        } else {
> >                /*
> >                 * Unknown whether other cases require moving a header;
> >                 * ARP works without.
> >                 */
> >        }
> > ...
> > }
> >
> > There is also some code which handles EHTERTYPE_VLAN.
> >
> > I don't have time to start debugging this today. But would this ring a=
 bell to anybody in connection to a wake-on-lan packet?

> I ran some experiments with tx checksum disabled, and it seems to
> matter.  I have a change for the last block you listed that might
> help, but I haven't tested it yet.

This patch seems to work:

diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/gene=
t/if_genet.c
index 327af8acbcdd..b7ab86e7931d 100644
--- a/sys/arm64/broadcom/genet/if_genet.c
+++ b/sys/arm64/broadcom/genet/if_genet.c
@@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)
 		 * Unknown whether other cases require moving a header;
 		 * ARP works without.
 		 */
+		COPY(min(gen_tx_hdr_min, m->m_len));
+		offset +=3D min(gen_tx_hdr_min, m->m_len);
 	}
 	return (offset);
 #undef COPY

It needs an updated comment, but should be testable.

		Mike

> > Regards,
> > Ronald.



From nobody Tue Oct 25 16:31:34 2022
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 4MxcsC20BYz4gGY6
	for ; Tue, 25 Oct 2022 16:31:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4Mxcs96QgYz4Gq8
	for ; Tue, 25 Oct 2022 16:31:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666715499; bh=ASWV+l639HFVC76jxizMQ4ZVQAz3bsbgvADZ++rg0N8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qNWVOLcEszaKCtNbSKNAL916MGX0EuXFnDptsMZ7wZmx4RWCsJp72e0qKjPoTHwaRwmv8qSZvG7kMkwTCejmG95wP9QZNjUIUOxMlNE2WAY333qdiXBj4W/NXL9iyQGdAXa3gPJE+ClbbqVHnE+cFH3H4EVtQkR2NUKIbIjx4L93HlXCBYfvh6u/EP0lDX7MfgBJaczMyxSvr6M0f61uYbKv0pvvQaTOVHus3CrhbSp0OzNPvamL2sfwBZ6QtXn2eEjOqPmSUHDHaikj2KdhIIyvQvHrJPYFaqTQnS79HViQOssUJRfiycl6EXF3bXNnlvNgx8+7vDbw3dc40qDxaw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666715499; bh=4YMQObkxl34o6yIBc9xfGphczyfM1T6WaFylyNxOvqz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Oa9+dlp0w+9sbxh59A1QPdrDdZI9iZoE60d7QQQScnQ9mxnKGQLsXaygr9/ZrRSG9jp67BjMkXC3bxwFlsjV83liPfX3bzrH8qnuiQsUxIrn3WYBLxHDUkXm/GgRa984kYW4jV47+KR76cBPKE1JfKKfdo2CUfTSaJ0QmO2mtK5FExK23GdrJRndDvxZyOzzb69Y5c5ZnibZ6KSozQEmyANbhPaCup7eBOI+gwRbncJYskcUvh759BOnfFN2tOAnZosBAvd7mjFXiXi0KhsgFL4tA/dRAYibpl2Md2oJit7oYCqhym8IYCTnNeLNjf5Nc6+ZXXG9zxHMH2OGa5cvhw==
X-YMail-OSG: 0EgXBtQVM1n8WntWe6FvQ0mYKLM2RGd9gAMTxpymWJciHpNt9b50iCorA_vyQMv
 XLBhe6ajN5AwdpvBMBaRh3HLQDkYU7QwSQ3tjRbJ4TcZm1UD3EmoWIJQwlzpDHY5XA9ZglT3x8jW
 WTlx6AFXJ6PBsPEMdxfDkfsDD3X.MyGZgANw4sc_DfTGf5tpUs2Z1fygedf1snYhzhrYTu3A4Wnf
 ilMSnDZIbYcSXnf43a8X4QLi2mWVXxJlJG8.3QSxTlC.Jn4oZZR0jqvT9XPzHuqT66eNoR.yBbeA
 z3WrCfO.2RGDvM6TUOBgybz_Ma6spJ1rg.iBOCfcXVVFN8JL_Kl_H8s4x.CEyRQIEJAOFMSHRhYY
 WRvdJE5d1Msa71V5E7jue1SIQMYLkiSCyvWYSTx49wYk5pdxmjAbIhioeg17jk2rGKZ.tffDa9y.
 GiOz9E10X.lc_L2STAstTM_wKVjO4hp1JsllJePWCdfIOFjlI4d.OnO5my_2uVzvcJBKsn.eMcJM
 ouDtVVjbD2HJxYk26gX8fU55Xj4KdUErKtreNmST0QV9UCO_z5MxkxhH_c_UoFLii3vawViSH.cT
 ZqACJHNHjX0E_MQJIrKLdTulxC.iEB9NafaT.q8NlM2heIo.J2MqeGKG14RXWXvS8DM1JeXe0xno
 w8cDEa6DfHyWVWrLA_J3wj2gYmCRIdPju_ZPFp0WtBQ.AAs56eGIOhbEfEFZWn9lq.R_V1_3eBz9
 9RNYfY23HN5SfXsFhN2CPAlYrZRogZyB9BAJpB9zVsPT4UHDOwt7.fkUBmDxG4BNEYbz48y2uJ_x
 prM14F8ChzS6v7Q7AwWIWLUpdsVR06E.xrklIZtcReMCw85C6fc3zlJ2WG9QyiCLzoWCwvsme.i_
 faIJRjk5mSb_mu1vhaAuDrp5fkmQWQun2q26oa33R6wWyv.XsV63h0VWM.yw5Kgvb6.U2vxDNqtM
 eJf3u6oYC0jh87vp_RAfRc4PI8g9PsixX8_tjXwlr7swyspZ_ijuyxX_2M48cBtIEpuHvMvICd1n
 f78re9X7.mPRW.W7zSU15et6QZbpdMnq1H9bLO6VYKXOaYaIQ2JS1eClr1_0S7mx0BDoot3YrDJR
 Jyhf9NsaHXxCP4HkzdGlaPhNS9mC7WD9I6BT3G5l_j5Sg43PAhSLP6mCOXjuYEPh8qCby.1msb5D
 8x4Nw3E5Bz86ok2tT9YR8LqpcGssJ503Mmrta7_dvurWjTQUddlvJCtjg71UmgIwNGD14AltVWrR
 6A82lMcGeCrr5jwEy5i_3Tertl8vvl4dP2cLcc8Menn5S9rJs.lon2j9W_5t.E2fcN2IFRFk8.LY
 UDeYkjM27mr.MoGDUbMthybPakPgFGlc_Lh3pQPvIBMsDU2Zqqi8k_BSzdQB5M0DuT55lbtpwxtK
 LH01Fzl3CIXz2CsFpaunY.SueJp1fCwYDCA47m7AQheuMn.tqL3jXc2dwtRcf1jElbp.tC_jTrhE
 ahaQEct9lGhJF5kBuka3rddsWRHeWN45B5vXO2oxb5.taIlBmMwITOuN53_UhhjnPJBm7GSP3XOG
 NAGtE1fnk3K4AyJcD9v6y2J7D864BojuL44UEA6bW5spTzzjWJowPnU156o3I2EuHPvSY6lgvVR.
 8.weMEDaBM33wbYcqmw7Qd3J2zaO_WpBD40K2KLKRgm_fHElMvsQqSIVvwgkevQ4eYakDxsjxNom
 _03c_qA.MBoyjKrg.mVtyCHkPmmFJ_doFkJJQihJT1f3xB4M4poZqH0UAT_udz7.q8YwK2NpfjUn
 ifseAAU7OLLMRN3cM54nT0bbNu58meIKS7CcS.mqSj62yseCNMWsaYIRBV7pgSLzz5wgRIEo_0VH
 2nDnpec.HGJ3amTdyB0zEnMrZWDNwb_LE07mw0y0cFgv6qOR2YSl6AznJiVgeV78TQx9rNKG5USm
 rz3Fcd_stWcdGXowhRrU4fV5juwtCn_WCEVJGvydT.qXkRumefs_2RxnRvGAL0C9SNZzs87glEQ3
 DEi85Y6u9TF8u4luVFEaPjCEN2U19RY7CQRmVhiiWqEZtDiUPnaGaJq3GWOPGl4ldy2vEaPcfG7b
 wCXvHmHcxH6BctSf6oc_DzhLMYQv2ud33J0Ju51tfUzgF6uYFmjBFItMcqCkJ7PYJwwgVsWEwuRE
 MTSE9cjW4LaNkG9pvXy_6oZMgeKAWyf9ftL6hc1ANwe4vxWx8P1ullvS0feiL_8exPTknL7xyNMM
 eta5MvQGbSFZbECoj7t1jlKVzGrFEgHwiCO8h6Ku7RIVrtaN.WYxLndkRTM_XU13h9S82gf7CbS1
 iGj8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Oct 2022 16:31:39 +0000
Received: by hermes--production-gq1-754cb59848-v9h2d (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a7a3b04456c112b4584f420aa6715dce;
          Tue, 25 Oct 2022 16:31:35 +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 \(3696.120.41.1.1\))
Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees
 disk but won't boot it
From: Mark Millard 
In-Reply-To: 
Date: Tue, 25 Oct 2022 09:31:34 -0700
Cc: bob prohaska ,
 Klaus K??chemann ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C132774-8FC5-4910-A2B2-AF83C72C44CC@yahoo.com>
References: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com>
 <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com>
 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
 <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mxcs96QgYz4Gq8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qNWVOLcE;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[www.zefox.net,googlemail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-24, at 21:52, Warner Losh  wrote:
>=20
> On Mon, Oct 24, 2022 at 9:32 PM Mark Millard  =
wrote:
> On 2022-Oct-24, at 17:50, bob prohaska  wrote:
>=20
> . . .
> >>=20
> > I've put the console output at
> > http://www.zefox.net/~fbsd/rpi2/20221024/boot_console
> > in case it's of interest.
>=20
> . . .
>=20
> I've not seen/noticed the following before:
>=20
> QUOTE
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib =
/usr/local/lib/compat/pkg /usr/local/lib/compat/pkg
> Soft Float compatibility ldconfig path:
> ldconfig: illegal option -- o
> usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | =
file ...]
> END QUOTE
>=20
> But, to my knowledge, "Soft Float" is not in use any more
> (by default, anyway). It might be that something is left
> over from long ago? Looking, I see:
>=20
> I was sure that all attempts to use it in FreeBSD 12+ had been =
removed....
> =20
> QUOTE
> author  Warner Losh    2022-01-07 05:34:18 +0000
> committer       Warner Losh    2022-01-07 05:34:18 =
+0000
> commit  d418bc27e601ec6bba0506d0efb62eca5eda5ab8 (patch)
> tree    14a7fb6ba93ab48d7e1c746a09e7d1d5de6f897e =
/libexec/rc/rc.d/ldconfig
> parent  b68d6892ba8aa14470e94a408b43ce4d8b1761da (diff)
> download        src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.tar.gz
> src-d418bc27e601ec6bba0506d0efb62eca5eda5ab8.zip
>=20
> libsoft: Remove runtime ldconfig support for libsoft
>=20
> Remove the runtime support for running ldconfig at boot to cache lists
> of libsoft libbraries.
> END QUOTE
>=20
> ( Note: /libexec/rc/rc.d/ldconfig is installed to /etc/rc.d/ldconfig =
.)
>=20
> Your /etc/rc.d/ldconfig script seems to have not been updated
> by use of etcupdate or mergemaster or other such. (How much
> else is also out of date? How much of what you have for /etc/
> and the like goes back to 2022-Jan-07 or before?)
>=20
> Yea... that seems likely... Can you confirm that I've not messed up
> a merge somewhere?
=20
I booted the RPi2B v1.1 that I have access to, using
(long output line split for readability):

# uname -apKU
FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #49
main-n258610-ba7319e9091b-dirty: Fri Oct 14 18:27:46 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a=
rmv7/sys/GENERIC-NODBG-CA7
arm armv7 1400072 1400072

(It also has a armv7 EFI loader from the closest artifact
build before the change that broke armv7 for that. I've
not yet updated to recent enough to have your fix.)

My updates track /etc/ changes via etcupdate in the scripts
I use (etcupdate since git). I do not get any of the lines:

Soft Float compatibility ldconfig path:
ldconfig: illegal option -- o
usage: ldconfig [-32] [-elf] [-Rimrv] [-f hints_file] [directory | file =
...]


I'll note that the man arch lists "soft" in some
places in the Floating Point table, just not for
armv7. Showing the ones that do list "soft":

   Floating Point
           Architecture    float, double    long double
           aarch64         hard             soft, quad precision
. . .
           mips            soft             identical to double
           mipsel          soft             identical to double
. . .
           mipsn32         soft             identical to double
           mips64          soft             identical to double
           mips64el        soft             identical to double
. . .
           riscv64sf       soft             soft, quad precision

aarch64 and riscv64sf would apply to main [so: 14] for
long double. But I'm unsure of any implications for "Soft
Float compatibility ldconfig path".

For reference:

# grep -i soft /etc/rc.d/ldconfig
#

# more /etc/rc.d/ldconfig=20
#!/bin/sh
#
# $FreeBSD$
#

# PROVIDE: ldconfig
# REQUIRE: FILESYSTEMS
# BEFORE:  DAEMON

. /etc/rc.subr

name=3D"ldconfig"
desc=3D"Configure the shared library cache"
ldconfig_command=3D"/sbin/ldconfig"
start_cmd=3D"ldconfig_start"
stop_cmd=3D":"

ldconfig_start()
{
        local _files _ins

        _ins=3D
        ldconfig=3D${ldconfig_command}
        checkyesno ldconfig_insecure && _ins=3D"-i"
        if [ -x "${ldconfig_command}" ]; then
                _LDC=3D"/lib /usr/lib"
                for i in ${ldconfig_local_dirs}; do
                        if [ -d "${i}" ]; then
                                _files=3D`find ${i} -type f`
                                if [ -n "${_files}" ]; then
                                        =
ldconfig_paths=3D"${ldconfig_paths} `cat ${_files} | sort -u`"
                                fi
                        fi
                done
                for i in ${ldconfig_paths} /etc/ld-elf.so.conf; do
                        if [ -r "${i}" ]; then
                                _LDC=3D"${_LDC} ${i}"
                        fi
                done
                startmsg 'ELF ldconfig path:' ${_LDC}
                ${ldconfig} -elf ${_ins} ${_LDC}

                machine_arch=3D$(sysctl -n hw.machine_arch)

                case ${machine_arch} in
                amd64|mips64|powerpc64)
                        for i in ${ldconfig_local32_dirs}; do
                                if [ -d "${i}" ]; then
                                        _files=3D`find ${i} -type f`
                                        if [ -n "${_files}" ]; then
                                                =
ldconfig32_paths=3D"${ldconfig32_paths} `cat ${_files} | sort -u`"
                                        fi
                                fi
                        done
                        _LDC=3D""
                        for i in ${ldconfig32_paths}; do
                                if [ -r "${i}" ]; then
                                        _LDC=3D"${_LDC} ${i}"
                                fi
                        done
                        startmsg '32-bit compatibility ldconfig path:' =
${_LDC}
                        ${ldconfig} -32 ${_ins} ${_LDC}
                        ;;
                esac

        fi
}

load_rc_config $name
run_rc_command "$1"

By contrast, =
https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ldconfig?h=3Dreleng/12.4=

still has the code:

		case `sysctl -n hw.machine_arch` in
		armv[67])
			for i in ${ldconfig_localsoft_dirs}; do
				if [ -d "${i}" ]; then
					_files=3D`find ${i} -type f`
					if [ -n "${_files}" ]; then
						=
ldconfigsoft_paths=3D"${ldconfigsoft_paths} `cat ${_files} | sort -u`"
					fi
				fi
			done
			_LDC=3D""
			for i in ${ldconfigsoft_paths}; do
				if [ -r "${i}" ]; then
					_LDC=3D"${_LDC} ${i}"
				fi
			done
			check_startmsgs &&
			    echo 'Soft Float compatibility ldconfig =
path:' ${_LDC}
			${ldconfig} -soft ${_ins} ${_LDC}
			;;
		esac

As does =
https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ldconfig?h=3Dreleng/13.1=
 .
As does =
https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/ldconfig?h=3Dstable/13 =
.

So it looks like only main [so: 14] has that code removed.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 25 18:00:45 2022
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 4Mxfr200h0z4gVY6
	for ; Tue, 25 Oct 2022 18:00:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4Mxfr10Pcwz3GgS
	for ; Tue, 25 Oct 2022 18:00:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666720847; bh=E8rnek2ipiq2TQ3HmdN5SLT+Q30V341CVOzbzfkNFQw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qpbG92PBL0Qy/mGLJ14BR7vffcLjqudwIgcDQKfaRzFlvZ50ke6gO8ArtpZ8TkGeTzsvdQhoHM5K1fvl0vQ7pAytmU55fnkq2KBFc4QH3T4/so0avMDt5qo4NaDB9LRpnxS1p3fXgJcR/PVIcSUaJTWTT6IK9sAjYdTmAFTKIX7a7j/IpCWY+VhrHJtKIFmlrJS6Kc9IvFvOTPZ2c3rEPelu93E0scg/fijWSpCwyl9H3ELDsMZTZcAZov/hG2l0gZNpVXkGiKrJYho8ocRiuNDYezzBP2uqFDtib3RdagwgVMWtwPDvfNfexcGXrjzJ6zu72f05TyUcYaNZA5Hj9A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666720847; bh=ftB9Nrt7EdU0qMUjKSftwReXt4PB0qaLkkxxVA0cy9f=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=h+1uGDWpGjG865FqZZORr8MW1UAihyCtRxDgZXeoZYnPFeMQo6EiIyOPg2YgQFlPmPZDOliooCuidvAqq4lZ8t2lSLWSP/Y/K+4FUHFAdSTwdes+ZjNu+2X5v2JWT0HR5ksC05RaS5cIAU4jIq6Xrwc264Oq754FGISpP4Oakwt9ZBWtM5n5YhEhq2YFdN6e5pR/EJY8RZ3lezy/Yr5FsCOXjj8bKd/mJesFjTPd1yjrFBMui0k5lEJGRQHlGPXBSZ/UdaqPZPBORNbhJrXNuIVzAvshtoVPXb2YH/W+slfGrrIl4sYux6pualgoRGc9mXqYMGC/GRp3wZZgxBW5Fg==
X-YMail-OSG: eLAqB5kVM1n_HDQwfrgrnLSqbLFH8fvqgiy3hp_q9K5g01HZMjbKj6G9iVEOCqF
 GcTCjOznbUIzc3acA6g8JCykDP61Ut7H3275g9FfcnHz0MtzdgxR7CtILOEX7LWxMdOq7LcSRVlj
 2oki_W2eOmQbuUK419tA_X.DhLrhL.QhKbha8KmY3aNTm.iF1_gxjuCkgnbWU8gySe_QNEPxJKbA
 z.rAd1cjZVYfdl0S0IqkBi_fcRNG2KtRWKVQEM.SLauEyQnZ8ybXiEBEanTtEdCYuryRl2Mqe6LT
 DeeZcxeRnBICzrv5B5MQ_S1O7ZToAYgVwS.8yETUZ1YRYy4.C6Ifcg_Y5NnG7pzI0Vz6kviHUWpx
 f_RMD4D9kjPx78O6cmhCcx8QBDDwgGRDfGX9KoPAIVK9LQlK4Lp.KNVk04R22W62h4i7JMMlfXzp
 IICWBMtKFQ9HgDr1GkclLlRsK3xJfehpYAV8qd1_2Sq_Izz2ne5g.SkkUI5OChtHhUvcPEwyfdIS
 YaYZgKl_gFF7zQkOneMPlQjTgEY3ne3wN5a3rRu_GDZsPkZ5yeQDjdWVciJU3IL3q3XS9muHb8qO
 WGz9_m.JlPY6l2jGiS65lpbmqUJgF5ngGMTwquYamQCYvve6aOr8W7dFjinxUnv.WK_GWzjS0ug_
 23VhAJeMrVpWf8e3AQRJAzDRWQ6IBpk1bHgT6vLVsPejlfLvfUatmzOQPWCkXO4i_4TmOOFaloBY
 5UrKucirVuCIiKxdaz2GQwCYQVErVT9dfrLwI1uAiRxf3Xpj7Nj81ByPJ74BaHoge5nSVR4rrH1z
 XKVQ5y.k4Twglol0PBPd.ZFk3wtAFWRcNS0Q1HQVtblsjvfEckwpXLgJ9Sb18NiK48GI3._K579V
 2HkONx42fB6FnavbtmS6hZnPDIdIFPd_A4Vhsd5A_O5XFmdgLVNzfrnOEizKBYaFh7nlT6neHk4v
 30bf26rBgbxlb3QYvbicaPn01XB5JontdUmpilbCg2IFhAwDLG6RNuR.Jg6f6.IEZY_06qrbcOIA
 uhISY.9_Qn90Y9TP8w0HBZVvX9CkEUELqArGi3aeCJl1S3TjhvlvoCWJSEfQjz.m9OwW4DPZS0YW
 cxaIcO.Ykrza0zh13yiyLXeQXbTGVQWnbq2BfeXgbUW0qXGMe7a.S7R_5OeNe7qI1QFtLJctJ0Rg
 b9YR8XsYOg2G8MsSTjurIH.J8XMKp9uMQOWHEUddw0HE7rFfIizT4pud3EdiVvdPCMxHA65wsqNf
 1f69OJ5Uk7vNVWoYypMyl9EilKFEMZB8lLn_FJ8pb7IZpDjJBJ8nMnVNKxJVz8S_2pWzTx4UM5z.
 ovOqhzmP5SzNEcbuA2IhLbAVxn4mh9dJ3jBK6ODDGu5r9QbEdchYScJukuT1J47jayd5JUD3RT4_
 vB3A.HCZlXjVk9EstlUPk3Yxz2Xta.f6cYkhixcUfv5kzLjDXSgNBKku56IV7B3QKZ4ZhHzcckgP
 rXVewGk_CZAhcArDOK0kfLLHnAVj7pNiw_KlvshEYldwcVxLK7trfrkAqFtzZxvF1NJ_SL7a4HVg
 cyqWZIf_eznPqdjGX8C__KHyxzixxtQ9Ln7SUQc3iGl5hOkwQH_vx8oAYXXFCOBnKMQRur7.URAU
 E3wh741BeTkuHEVnp9TNXP5W0tWND_cnNKrrT_tJet4a4pjShU0aVwUR8LHF4DHHA4BQZQdxyB4s
 8koho47_8.UjH0CXWfLg3ivHN18_t5DiO0MplLmeNm1HT0GaurvZgtgBthNtDuoo5HMJb7qaYKei
 uccA9aq6j8Pu3Rl6WpuLZTmyNAU99bM_DVRui8JdhllZbRovCuS5gt9jgVV4xuDSO2H8YsSwKMJc
 M0Vko4XVGKpyrZdQ0EUpDuiy_hCPIY4os0nUvCxbHDsQuxGhH62kyCamIBLkf9HKm2FIXp1XVcX.
 NeHrqSW2cRCr4UkXsfA.L704mjIJbexuOwDMLLaFkPMX9SYHdnqDi4lLUdkko3tKcUEnjVZkMY8g
 akWDqF9RcC3IgADMBB02Z.ZqpXN3jA2pqBJ1v4gt5BISRYFgc38wK24h7hPzFdSllRo_PSDlD8bY
 xGwalufHyAMNj.MRkZeGMOHY2Kf7zkcgfAFIZGEYPDD2HTH_XW0QMTIE7mnaQR2YqKbg6Dqp4DpU
 4UG50vaG16TrUIqrqwZBULYSRBE2V4HEkbePmN_KWQI6BEUJgMHdpf7JytCg8Bh5LX7AAUgpHnsM
 Tb3SWlkY9_tHTu_byHaV9VvaY.q.Kv9OuVCt9JMb06ZMvxs7Zx40tF9izKSVpmY.Tr8zMfplKu9a
 cKRU-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Oct 2022 18:00:47 +0000
Received: by hermes--production-gq1-754cb59848-m8kdv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fa95336dd427ff86d98caa5960953b21;
          Tue, 25 Oct 2022 18:00:46 +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 \(3696.120.41.1.1\))
Subject: Re: BeagleBone uboot: BeagleBone Green Gateway not defined in uboot?
From: Mark Millard 
In-Reply-To: <1D4FD611-7420-4E52-9414-67F282DDA4C6@netsense.nl>
Date: Tue, 25 Oct 2022 11:00:45 -0700
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <85E7A48D-89DB-49C5-B2A1-501CF7C125DE@yahoo.com>
References: <0EDDBAEA-CA91-4A64-BB93-BCB5D067BE00@netsense.nl>
 <467642CD-DF11-448C-AACA-43F7FB4DB572@yahoo.com>
 <50347B94-0B6D-463C-9B87-499EBEA537D7@yahoo.com>
 <1D4FD611-7420-4E52-9414-67F282DDA4C6@netsense.nl>
To: Johan Henselmans 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4Mxfr10Pcwz3GgS
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qpbG92PB;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.974];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-25, at 00:25, Johan Henselmans  wrote:

> I made some comments in between on both mails.
>=20
>>>=20
>>> . . .
>>>=20
>>> # more /usr/ports/sysutils/u-boot-beaglebone/pkg-descr
>>> U-Boot loader for BeagleBone and BeagleBone Black.
>>>=20
>>> To install this bootloader, copy the files MLO and bb-uboot.img to =
the FAT
>>> partition on an SD card or the eMMC.  Normally this is partition 1, =
but
>>> different partitions can be set with U-Boot environment variables.
>>>=20
>>> This version is patched so that:
>>> * API features are enabled.
>>> * A boot.scr (U-Boot scripts ) that loads ubldr.bin and execute it =
is included
>>>=20
>>> For information about running FreeBSD on BeagleBone or BeagleBone =
Black, see
>>> https://wiki.freebsd.org/FreeBSD/arm/BeagleBone

Looks like that should be(?): =
https://wiki.freebsd.org/arm/BeagleBoneBlack

>>> You were not explicit. Did you do as described with MLO
>>> and bb-uboot.img ?
>>>=20
>=20
>=20
> Yes I did. Only thing I did not know how to do was where to put the =
boot.scr that the READMe mentions.
>=20
> That is why I reran the script on a Beaglebone, hoping that would =
install the script. Mind you, I am not a
> pkg specialist. I do not know how to find out how this script is =
created and where it is supposed to put.
> I looked in /usr/port/sysutils/u-boot-master and =
/usr/port/sysutils/u-boot-beaglebone, but could not understand
> where this boot.scr was supposed to go

I'll note that FreeBSD 12 still has images for a beaglebone.
For example:

=
http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.4/FreeBSD-12.4=
-PRERELEASE-arm-armv7-BEAGLEBONE-20221014-r372617.img.xz

=46rom that you can see some of what goes where in the msdosfs
on the boot media, for example:

# mdconfig -u md0 -f =
~/FreeBSD-12.4-PRERELEASE-arm-armv7-BEAGLEBONE-20221014-r372617.img
# mount -onoatime -tmsdosfs /dev/md0s1 /mnt
# ls -Tld /mnt/*
drwxr-xr-x  1 root  wheel     4096 Oct 13 23:56:24 2022 /mnt/EFI
-rwxr-xr-x  1 root  wheel   103876 Oct 13 20:17:38 2022 /mnt/MLO
drwxr-xr-x  1 root  wheel     8192 Oct 13 23:56:24 2022 /mnt/dtb
-rwxr-xr-x  1 root  wheel  1163404 Oct 13 20:17:38 2022 /mnt/u-boot.img
-r-xr-xr-x  1 root  wheel   386104 Oct 13 23:47:42 2022 /mnt/ubldr.bin

This makes it look like bb-uboot.img is renamed during
the copy into the msdosfs, if it is ever named bb-uboot.img
anyway. (Again, I'm not familiar with any beaglebone
specifics.)

The lack of boot.scr is interesting. My expectation is
that boot.src goes in same directory with u-boot.img and
ubldr.bin : u-boot.img reads boot.scr and follows the
instructions that are there in order to load ubldr.bin .
Looking elsewhere for boot.scr would seem odd.

(But, I'll note that I know nothing of MLO or its
implications.)

I'll note that there is:

# find /mnt/ -print | grep am335x
/mnt/dtb/am335x-bone.dtb
/mnt/dtb/am335x-boneblack.dtb
/mnt/dtb/am335x-boneblack-wireless.dtb
/mnt/dtb/am335x-bonegreen.dtb
/mnt/dtb/am335x-bonegreen-wireless.dtb
/mnt/dtb/am335x-boneblue.dtb
/mnt/dtb/am335x-pocketbeagle.dtb

That suggests one place were the .dtb might need
to go. I've no clue if that is the only place
vs. needing a copy someplace in UFS/ZFS space for
FreeBSD to directly access.

>>>> That resulted in the message that there was no device tree:
>>>> =3D=3D=3D=3D=3D
>>>> Loading Environment from EXT4...
>>>> ** Unable to use mmc 0:1 for loading the env **
>>>> Board: BeagleBone Black
>>>>  not set. Validating first E-fuse MAC
>>>> BeagleBone Black:
>>>> Model: SeeedStudio BeagleBone Green Gateway:
>>>> BeagleBone: cape eeprom: i2c_probe: 0x54:
>>>> BeagleBone: cape eeprom: i2c_probe: 0x55:
>>>> BeagleBone: cape eeprom: i2c_probe: 0x56:
>>>> BeagleBone: cape eeprom: i2c_probe: 0x57:
>>>> Net:   eth0: MII MODE
>>>> cpsw, usb_ether
>>>> Press SPACE to abort autoboot in 0 seconds
>>>> board_name=3D[A335BNLT] ...
>>>> board_rev=3D[GG1A] ...
>>>> switch to partitions #0, OK
>>>> mmc0 is current device
>>>> SD/MMC found on device 0
>>>> switch to partitions #0, OK
>>>> mmc0 is current device
>>>> Scanning mmc 0:1...
>>>> Found EFI removable media binary efi/boot/bootarm.efi
>>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>>>=20
>>>> 
>>>> No valid device tree blob found!
>>>> WARNING! Trying to fire up the kernel, but no device tree blob =
found!
>>>> =3D=3D=3D=3D=3D
>>>>=20
>>>>=20
>>>> How can I add a  device tree blob for the BeagleBone Green Gateway?
>>>>=20
>>>=20
>>> Note: I've no experience with any BeagleBone variant.
>>> My comments are rather generic.
>>>=20
>>=20
>> Hmm, I do not see am335x-bonegreen-gateway.dts in any
>> of the source code trees I've got for releng/13.0 ,
>> releng/13.1 , stable/13 , or main [so: 14] :
>>=20
>> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
>> =
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
>> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
>> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
>> =
/usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
>> /usr/13_0R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>>=20
>> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
>> =
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.d=
ts
>> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
>> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
>> =
/usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.d=
ts
>> /usr/13_1R-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>>=20
>> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
>> =
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dts=

>> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
>> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
>> =
/usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dts=

>> /usr/13S-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>>=20
>> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-bone.dts
>> =
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack-wireless.dt=
s
>> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblack.dts
>> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-boneblue.dts
>> =
/usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen-wireless.dt=
s
>> /usr/main-src/sys/contrib/device-tree/src/arm/am335x-bonegreen.dts
>>=20
>> Looks like you would have to establish am335x-bonegreen-gateway.dtb
>> another way as things are.
>>=20
>> I also did not find am335x-bonegreen-gateway.dtb in:
>>=20
>> https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts/
>>=20
>> so it would likely be some time before it shows up there for FreeBSD
>> to later import.
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>=20
>>=20
>=20
> It seems the Beaglebne stuf is located at =
https://github.com/beagleboard/BeagleBoard-DeviceTrees/
>=20
> There is a am335x-bonegreen-gateway.dts available over there. I =
don=E2=80=99t know why that stuff is not in torvalds tree.
> I know that the debian version is created from =
https://github.com/RobertCNelson/omap-image-builder
>=20
> So my question would be then revolve around: how can I add that =
version to FreeBSD arm? Is there some procedure
> documented somehwere how I should do this?

I've no clue if anyone supporting code for armv7 on
FreeBSD would be willing to add and support .dts
files that do not come from importing from the
mainline linux tree (and any related files). They
might require a port instead, sort of like how RPi*
firmware is dealt with (including the .dtb files,
that happen to be used directly, not via dts
compiles).

The .dts history visible via:

=
https://github.com/beagleboard/BeagleBoard-DeviceTrees/commits/v4.19.x-ti-=
overlays/src/arm/am335x-bonegreen-gateway.dts

and shows that the .dts was last updated on 2021-Dec-23.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Oct 25 18:31:48 2022
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 4MxgWq3BQPz4gZX3
	for ; Tue, 25 Oct 2022 18:31:51 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4MxgWp2vq1z3M0r
	for ; Tue, 25 Oct 2022 18:31:50 +0000 (UTC)
	(envelope-from SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 25 Oct 2022 20:31:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1666722708;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=yMJ27P2+TFMb7qz0UvgK3fS2M4hL3s+g2XJeOVPImoA=;
	b=o7M+7rA4WrG1VqQRcoYdV7CFwvOc3YcVqt/30zR4AjXzRRSfq34UFts3kPCNxt+GerNAjp
	ZCvmWdbEVXrkAoIcoN+PmPrcQSDkcltFYdHsJjruTNwwxiObwX9suEmyD8kjXDcQEBw46A
	ogqGMCSca+GeTF+y1M6wV5PNmCLXd9UlplHpgtTu15lYSKVg7zYBn0EVrYwronaC7N6QPx
	1EIKlzx3YCSy8n2cCEEIj6o0IApYb5xXoE+IUlR2kgf6bc1eZbsX4C4Dp1Ve8v/iJyvCvl
	dZCXAvfLQlI5WVKL5jIF8r6YZQX8ylZ9G6cJmQhLKGQDYHW7xuucTzX/ARmkdQ==
From: Ronald Klop 
To: mike@karels.net
Cc: freebsd-arm@freebsd.org
Message-ID: <1539824734.231347.1666722708425@localhost>
In-Reply-To: <202210251611.29PGBsbq016681@mail.karels.net>
References: Your message of Tue, 25 Oct 2022 10:22:38 -0500.
             <676FFB6B-0D38-47D4-AED8-EA2D5F685F43@karels.net>
 <202210251611.29PGBsbq016681@mail.karels.net>
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
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="----=_Part_231346_1677104857.1666722708420"
X-Mailer: Realworks (628.35)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MxgWp2vq1z3M0r
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=o7M+7rA4;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.18 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=dp/f=22=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_231346_1677104857.1666722708420
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mike Karels 
Datum: dinsdag, 25 oktober 2022 18:11
Aan: Ronald Klop 
CC: freebsd-arm@freebsd.org
Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> 
> I wrote:
> > On 25 Oct 2022, at 9:13, Ronald Klop wrote:
> 
> > > Van: Mike Karels 
> > > Datum: dinsdag, 25 oktober 2022 14:55
> > > Aan: Ronald Klop 
> > > CC: freebsd-arm@freebsd.org
> > > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
> > >>
> > >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.
> > >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> > >>>
> > >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.
> > >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
> > >>>
> > >>> Firewall ipfw does not indicate that it blocks anything.
> > >>>
> > >>> RPI4 runs:
> > >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
> > >>>
> > >>> genet0: flags=8943 metric 0 mtu 1500
> > >>>    options=68000b
> > >>>
> > >>>
> > >>> RPI3 runs:
> > >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
> > >>>
> > >>> ue0: flags=8943 metric 0 mtu 1500
> > >>>    options=80009
> > >>>
> > >>>
> > >>> Does genet0 not support these packages?
> > >>> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?
> > >>> genet0 does have a vlan configured connected to a bridge0 for some jails
> > >>> vlan3: flags=8943 metric 0 mtu 1500
> > >>>    options=80000
> > >>>    groups: vlan
> > >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
> > >>>
> > >>> ue0 is itself connected to a bridge0
> > >>
> > >> Is the RPI3 also on a vlan and bridge?
> > >>
> > >> Is the router (or switch) expecting the packet on the vlan?
> > >> If so, maybe you need to send on vlan3 rather than genet0.
> > >>
> > >> The genet interface has some oddities about packet layouts;
> > >> that could be hitting here.  You could try disabling TCP TX
> > >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
> > >> simplifies some of the issues.
> > >>
> > >>         Mike
> > >>
> > >>> Regards,
> > >>> Ronald.
> > >
> > >
> > > Hi,
> > >
> > > Thanks for the hint. I experimented some further.
> > >
> > > Disabling -txcsum -rxcsum didn't matter.
> 
> > -rxcsum doesn't matter, but you need to do -txcsum6 as well as
> > -txcsum.  (See the code that calls gen_parse_tx.)
> 
> > > But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.
> > >
> > > Looking at the driver I found this interesting peace of code.
> > >
> > > static int
> > > gen_parse_tx(struct mbuf *m, int csum_flags) {
> > > ...
> > >        if (ether_type == ETHERTYPE_IP) {
> > >                COPY(((struct ip *)p)->ip_hl << 2);
> > >                offset += ((struct ip *)p)->ip_hl << 2;
> > >        } else if (ether_type == ETHERTYPE_IPV6) {
> > >                COPY(sizeof(struct ip6_hdr));
> > >                offset += sizeof(struct ip6_hdr);
> > >        } else {
> > >                /*
> > >                 * Unknown whether other cases require moving a header;
> > >                 * ARP works without.
> > >                 */
> > >        }
> > > ...
> > > }
> > >
> > > There is also some code which handles EHTERTYPE_VLAN.
> > >
> > > I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?
> 
> > I ran some experiments with tx checksum disabled, and it seems to
> > matter.  I have a change for the last block you listed that might
> > help, but I haven't tested it yet.
> 
> This patch seems to work:
> 
> diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c
> index 327af8acbcdd..b7ab86e7931d 100644
> --- a/sys/arm64/broadcom/genet/if_genet.c
> +++ b/sys/arm64/broadcom/genet/if_genet.c
> @@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)
>          * Unknown whether other cases require moving a header;
>          * ARP works without.
>          */
> +       COPY(min(gen_tx_hdr_min, m->m_len));
> +       offset += min(gen_tx_hdr_min, m->m_len);
>     }
>     return (offset);
>  #undef COPY
> 
> It needs an updated comment, but should be testable.
> 
>         Mike
> 
> > > Regards,
> > > Ronald.
> 
>  

Hi,

Thanks. Disabling both -txcsum and -txcsum6 works for me also.
I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.

Regards,
Ronald.
 
------=_Part_231346_1677104857.1666722708420
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Mike Karels <mike@karels.net>

Datum: dinsdag, 25 oktober 2022 18:11

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: freebsd-arm@freebsd.org

Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)







I wrote:

> On 25 Oct 2022, at 9:13, Ronald Klop wrote:



> > Van: Mike Karels <mike@karels.net>

> > Datum: dinsdag, 25 oktober 2022 14:55

> > Aan: Ronald Klop <ronald-lists@klop.ws>

> > CC: freebsd-arm@freebsd.org

> > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)

> >>

> >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:

> >>

> >>> Hi,

> >>>

> >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.

> >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

> >>>

> >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.

> >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

> >>>

> >>> Firewall ipfw does not indicate that it blocks anything.

> >>>

> >>> RPI4 runs:

> >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

> >>>

> >>> genet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

> >>>    options=68000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

> >>>

> >>>

> >>> RPI3 runs:

> >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64

> >>>

> >>> ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

> >>>    options=80009<RXCSUM,VLAN_MTU,LINKSTATE>

> >>>

> >>>

> >>> Does genet0 not support these packages?

> >>> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?

> >>> genet0 does have a vlan configured connected to a bridge0 for some jails

> >>> vlan3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

> >>>    options=80000<LINKSTATE>

> >>>    groups: vlan

> >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0

> >>>

> >>> ue0 is itself connected to a bridge0

> >>

> >> Is the RPI3 also on a vlan and bridge?

> >>

> >> Is the router (or switch) expecting the packet on the vlan?

> >> If so, maybe you need to send on vlan3 rather than genet0.

> >>

> >> The genet interface has some oddities about packet layouts;

> >> that could be hitting here.  You could try disabling TCP TX

> >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that

> >> simplifies some of the issues.

> >>

> >>         Mike

> >>

> >>> Regards,

> >>> Ronald.

> >

> >

> > Hi,

> >

> > Thanks for the hint. I experimented some further.

> >

> > Disabling -txcsum -rxcsum didn't matter.



> -rxcsum doesn't matter, but you need to do -txcsum6 as well as

> -txcsum.  (See the code that calls gen_parse_tx.)



> > But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.

> >

> > Looking at the driver I found this interesting peace of code.

> >

> > static int

> > gen_parse_tx(struct mbuf *m, int csum_flags) {

> > ...

> >        if (ether_type == ETHERTYPE_IP) {

> >                COPY(((struct ip *)p)->ip_hl << 2);

> >                offset += ((struct ip *)p)->ip_hl << 2;

> >        } else if (ether_type == ETHERTYPE_IPV6) {

> >                COPY(sizeof(struct ip6_hdr));

> >                offset += sizeof(struct ip6_hdr);

> >        } else {

> >                /*

> >                 * Unknown whether other cases require moving a header;

> >                 * ARP works without.

> >                 */

> >        }

> > ...

> > }

> >

> > There is also some code which handles EHTERTYPE_VLAN.

> >

> > I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?



> I ran some experiments with tx checksum disabled, and it seems to

> matter.  I have a change for the last block you listed that might

> help, but I haven't tested it yet.



This patch seems to work:



diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c

index 327af8acbcdd..b7ab86e7931d 100644

--- a/sys/arm64/broadcom/genet/if_genet.c

+++ b/sys/arm64/broadcom/genet/if_genet.c

@@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)

         * Unknown whether other cases require moving a header;

         * ARP works without.

         */

+       COPY(min(gen_tx_hdr_min, m->m_len));

+       offset += min(gen_tx_hdr_min, m->m_len);

    }

    return (offset);

 #undef COPY



It needs an updated comment, but should be testable.



        Mike



> > Regards,

> > Ronald.



 







Hi,



Thanks. Disabling both -txcsum and -txcsum6 works for me also.

I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.



Regards,

Ronald.

 
------=_Part_231346_1677104857.1666722708420--

From nobody Wed Oct 26 10:13:43 2022
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 4My4Qb71wLz4gdBH
	for ; Wed, 26 Oct 2022 10:13:43 +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 4My4Qb4K9zz3qpg
	for ; Wed, 26 Oct 2022 10:13:43 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4My4Qb36m4z1CcK
	for ; Wed, 26 Oct 2022 10:13:43 +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 29QADhfE055850
	for ; Wed, 26 Oct 2022 10:13:43 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29QADhjM055849
	for freebsd-arm@FreeBSD.org; Wed, 26 Oct 2022 10:13:43 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 267361] EINVAL accessing fpcsr for armv7 process on arm64
 kernel
Date: Wed, 26 Oct 2022 10:13:43 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: fuz@fuz.su
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666779223;
	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=NTiGHtaJgSuMs0IghxgbECieds99zo/AH+J2ixVWcm8=;
	b=txH++BaTBzbKzeOWmf1PU+1h+qdU5x3CKERO/lyODiylCAflAiAt9lE/fiNy/iK3dn5byc
	+Tkwic/ce3xn9rYZKiWFUD03tSvlAw92bP69Jjh66wIVG4zibBvC1UqJbhBq1/MwP8sJDl
	8ra9YTe35jgVFruxJs0m89AsBbrzJ/BtPnKfFEJ60mYlafT0UsGIUvZni0LoNtZqvMRaxV
	I9vUJY6YioAQFlhFNJcoDdtql+cqdTHM01+laVzvODY+DXJ+iutxURI9fbPCwQCxBY/1cO
	t9gleQBYKXohgyOah7GWnBsQcHdYkksxWZdLXHgojslsHP3dw5ffLq0PUwGTfw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666779223; a=rsa-sha256; cv=none;
	b=fMoX8XXmcjleMu3cju2RQR44jGNipOi//J9IWMjHubMg2DBq41dZ6kkQXY2HRePCdnISIN
	ZqtU87eCniUzZB9bJjjhC+FaLnmRuS0QBJy0fYX5GuRhTgm46hgmrlc+Q6o7eo9w0RQNWM
	2P9ZgC8um1akb++vMZdfhMMmulotjsoykAXHnggtT7IT691T1x6M4VKJuhhT9tc7vtBBjH
	EpGd00LtRaM5xvpJXAZDSlOMxKMTHoHxoXmLZs7CHMNeJ5zQz+wg0dWbJYJyiVudiDiXGV
	avOKWAi0UHRRDwtu7DFk/4fkD0vBt6vpmFLPeNqAbfSm9Tb8kSJxNoCqAP1RGQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267361

            Bug ID: 267361
           Summary: EINVAL accessing fpcsr for armv7 process on arm64
                    kernel
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: fuz@fuz.su

To reproduce: install devel/gdb from ports.  Then type

    gdb /usr/bin/true
    starti
    info registers

Expected output:

(gdb) info registers
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0xbfbfec9c          0xbfbfec9c
lr             0x20054380          537215872
pc             0x20054380          0x20054380 
cpsr           0x10                16
fpscr          0x2000000           33554432
tpidruro       

Actual output:

(gdb) info registers
r0             0xffffdb58          4294957912
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0xffffdb58          0xffffdb58
lr             0x40054380          1074086784
pc             0x40054380          0x40054380 
cpsr           0x10                16
Couldn't get registers: Invalid argument.

The "expected output" is from an armv7 system.  I have tested in an armv7
FreeBSD 13.1 jail on arm64 FreeBSD 13.1.  The gdb version is 12.1 from port=
s.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Oct 29 05:16:46 2022
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 4Mznhn5nRjz4h0PK
	for ; Sat, 29 Oct 2022 05:16:57 +0000 (UTC)
	(envelope-from SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4Mznhm2ZBcz3xkg
	for ; Sat, 29 Oct 2022 05:16:56 +0000 (UTC)
	(envelope-from SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl)
Date: Sat, 29 Oct 2022 07:16:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1667020608;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to; bh=sF9Os6WYsDuFRo9jOvlE690qWezpRBIPVWb9csUr+bc=;
	b=AyOWY05ynVs6W32L5NmLQjyw+lLk8ACx8oBGlBjD/AnSjuUQVI9plnH62J9TBgdLPqgJwt
	rq55mQ61UpITvJviEbN0+mCKSdZHU0FpJqoC54J31uPZlG9lXE7NsZsoRUpPiU8ELKl7gh
	iLJ0xE5IHNsmDzkFKJUnowMnD0+C52h06VKKRz0+/9SogvQC1mTvs5gx8hnFn6Z3xQ8e83
	sVYpqslBU0DOS+IqQkxGBxxltN1okPYRzxy5B3VkZKOmLgtc5fvd34PiRZ/OLKN0KfHC0+
	XrxOK9ix0B/AVARtysMfjUWzOnd424JG6MUQDdu2Or47rfjx46lbnuuZaB1J/A==
From: Ronald Klop 
To: mike@karels.net, freebsd-arm@freebsd.org
Message-ID: <2086140007.15494.1667020606677@localhost>
In-Reply-To: <1539824734.231347.1666722708425@localhost>
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
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="----=_Part_15493_225212243.1667020606673"
X-Mailer: Realworks (630.161)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4Mznhm2ZBcz3xkg
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=AyOWY05y;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-2.21 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	NEURAL_HAM_MEDIUM(-0.02)[-0.017];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=F8kh=26=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_15493_225212243.1667020606673
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Van: Ronald Klop 
Datum: 25 oktober 2022 20:32
Aan: mike@karels.net
CC: freebsd-arm@freebsd.org
Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)

> 
> 
> 
>  
> Van: Mike Karels 
> Datum: dinsdag, 25 oktober 2022 18:11
> Aan: Ronald Klop 
> CC: freebsd-arm@freebsd.org
> Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>> 
>> I wrote:
>> > On 25 Oct 2022, at 9:13, Ronald Klop wrote:
>> 
>> > > Van: Mike Karels 
>> > > Datum: dinsdag, 25 oktober 2022 14:55
>> > > Aan: Ronald Klop 
>> > > CC: freebsd-arm@freebsd.org
>> > > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>> > >>
>> > >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.
>> > >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
>> > >>>
>> > >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.
>> > >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505
>> > >>>
>> > >>> Firewall ipfw does not indicate that it blocks anything.
>> > >>>
>> > >>> RPI4 runs:
>> > >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
>> > >>>
>> > >>> genet0: flags=8943 metric 0 mtu 1500
>> > >>>    options=68000b
>> > >>>
>> > >>>
>> > >>> RPI3 runs:
>> > >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64
>> > >>>
>> > >>> ue0: flags=8943 metric 0 mtu 1500
>> > >>>    options=80009
>> > >>>
>> > >>>
>> > >>> Does genet0 not support these packages?
>> > >>> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?
>> > >>> genet0 does have a vlan configured connected to a bridge0 for some jails
>> > >>> vlan3: flags=8943 metric 0 mtu 1500
>> > >>>    options=80000
>> > >>>    groups: vlan
>> > >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
>> > >>>
>> > >>> ue0 is itself connected to a bridge0
>> > >>
>> > >> Is the RPI3 also on a vlan and bridge?
>> > >>
>> > >> Is the router (or switch) expecting the packet on the vlan?
>> > >> If so, maybe you need to send on vlan3 rather than genet0.
>> > >>
>> > >> The genet interface has some oddities about packet layouts;
>> > >> that could be hitting here.  You could try disabling TCP TX
>> > >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
>> > >> simplifies some of the issues.
>> > >>
>> > >>         Mike
>> > >>
>> > >>> Regards,
>> > >>> Ronald.
>> > >
>> > >
>> > > Hi,
>> > >
>> > > Thanks for the hint. I experimented some further.
>> > >
>> > > Disabling -txcsum -rxcsum didn't matter.
>> 
>> > -rxcsum doesn't matter, but you need to do -txcsum6 as well as
>> > -txcsum.  (See the code that calls gen_parse_tx.)
>> 
>> > > But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.
>> > >
>> > > Looking at the driver I found this interesting peace of code.
>> > >
>> > > static int
>> > > gen_parse_tx(struct mbuf *m, int csum_flags) {
>> > > ...
>> > >        if (ether_type == ETHERTYPE_IP) {
>> > >                COPY(((struct ip *)p)->ip_hl << 2);
>> > >                offset += ((struct ip *)p)->ip_hl << 2;
>> > >        } else if (ether_type == ETHERTYPE_IPV6) {
>> > >                COPY(sizeof(struct ip6_hdr));
>> > >                offset += sizeof(struct ip6_hdr);
>> > >        } else {
>> > >                /*
>> > >                 * Unknown whether other cases require moving a header;
>> > >                 * ARP works without.
>> > >                 */
>> > >        }
>> > > ...
>> > > }
>> > >
>> > > There is also some code which handles EHTERTYPE_VLAN.
>> > >
>> > > I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?
>> 
>> > I ran some experiments with tx checksum disabled, and it seems to
>> > matter.  I have a change for the last block you listed that might
>> > help, but I haven't tested it yet.
>> 
>> This patch seems to work:
>> 
>> diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c
>> index 327af8acbcdd..b7ab86e7931d 100644
>> --- a/sys/arm64/broadcom/genet/if_genet.c
>> +++ b/sys/arm64/broadcom/genet/if_genet.c
>> @@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)
>>          * Unknown whether other cases require moving a header;
>>          * ARP works without.
>>          */
>> +       COPY(min(gen_tx_hdr_min, m->m_len));
>> +       offset += min(gen_tx_hdr_min, m->m_len);
>>     }
>>     return (offset);
>>  #undef COPY
>> 
>> It needs an updated comment, but should be testable.
>> 
>>         Mike
>> 
>> > > Regards,
>> > > Ronald.
>> 
>>  
> 
> Hi,
> 
> Thanks. Disabling both -txcsum and -txcsum6 works for me also.
> I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.
> 
> Regards,
> Ronald.
>  


Hi,

Your patch works for me. I can send wake-on-lan packets now. Should I test other specific things also?

Regards,

Ronald. 
------=_Part_15493_225212243.1667020606673
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


Van: Ronald Klop <ronald-lists@klop.ws>
Datum: 25 oktober 2022 20:32
Aan: mike@karels.net
CC: freebsd-arm@freebsd.org
Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)





 

Van: Mike Karels 

Datum: dinsdag, 25 oktober 2022 18:11

Aan: Ronald Klop 

CC: freebsd-arm@freebsd.org

Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)







I wrote:

> On 25 Oct 2022, at 9:13, Ronald Klop wrote:



> > Van: Mike Karels 

> > Datum: dinsdag, 25 oktober 2022 14:55

> > Aan: Ronald Klop 

> > CC: freebsd-arm@freebsd.org

> > Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)

> >>

> >> On 25 Oct 2022, at 6:57, Ronald Klop wrote:

> >>

> >>> Hi,

> >>>

> >>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my RPI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as well as on my router.

> >>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

> >>>

> >>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on my RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *not* on my router.

> >>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c:da:00:21:70:46.6cda: ipx-#6cda 65505

> >>>

> >>> Firewall ipfw does not indicate that it blocks anything.

> >>>

> >>> RPI4 runs:

> >>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76cf: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

> >>>

> >>> genet0: flags=8943 metric 0 mtu 1500

> >>>    options=68000b

> >>>

> >>>

> >>> RPI3 runs:

> >>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm64

> >>>

> >>> ue0: flags=8943 metric 0 mtu 1500

> >>>    options=80009

> >>>

> >>>

> >>> Does genet0 not support these packages?

> >>> What can prevent this packet to go on the ethernet while tcpdump still shows it is outgoing on the interface?

> >>> genet0 does have a vlan configured connected to a bridge0 for some jails

> >>> vlan3: flags=8943 metric 0 mtu 1500

> >>>    options=80000

> >>>    groups: vlan

> >>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0

> >>>

> >>> ue0 is itself connected to a bridge0

> >>

> >> Is the RPI3 also on a vlan and bridge?

> >>

> >> Is the router (or switch) expecting the packet on the vlan?

> >> If so, maybe you need to send on vlan3 rather than genet0.

> >>

> >> The genet interface has some oddities about packet layouts;

> >> that could be hitting here.  You could try disabling TCP TX

> >> checksum offload: ifconfig genet0 -txcsum -txcsum6; that

> >> simplifies some of the issues.

> >>

> >>         Mike

> >>

> >>> Regards,

> >>> Ronald.

> >

> >

> > Hi,

> >

> > Thanks for the hint. I experimented some further.

> >

> > Disabling -txcsum -rxcsum didn't matter.



> -rxcsum doesn't matter, but you need to do -txcsum6 as well as

> -txcsum.  (See the code that calls gen_parse_tx.)



> > But when I use bridge0 or vlan3 as device then it goes into the wire but on the VLAN which is not where my NAS is which I want to boot.

> >

> > Looking at the driver I found this interesting peace of code.

> >

> > static int

> > gen_parse_tx(struct mbuf *m, int csum_flags) {

> > ...

> >        if (ether_type == ETHERTYPE_IP) {

> >                COPY(((struct ip *)p)->ip_hl << 2);

> >                offset += ((struct ip *)p)->ip_hl << 2;

> >        } else if (ether_type == ETHERTYPE_IPV6) {

> >                COPY(sizeof(struct ip6_hdr));

> >                offset += sizeof(struct ip6_hdr);

> >        } else {

> >                /*

> >                 * Unknown whether other cases require moving a header;

> >                 * ARP works without.

> >                 */

> >        }

> > ...

> > }

> >

> > There is also some code which handles EHTERTYPE_VLAN.

> >

> > I don't have time to start debugging this today. But would this ring a bell to anybody in connection to a wake-on-lan packet?



> I ran some experiments with tx checksum disabled, and it seems to

> matter.  I have a change for the last block you listed that might

> help, but I haven't tested it yet.



This patch seems to work:



diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom/genet/if_genet.c

index 327af8acbcdd..b7ab86e7931d 100644

--- a/sys/arm64/broadcom/genet/if_genet.c

+++ b/sys/arm64/broadcom/genet/if_genet.c

@@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)

         * Unknown whether other cases require moving a header;

         * ARP works without.

         */

+       COPY(min(gen_tx_hdr_min, m->m_len));

+       offset += min(gen_tx_hdr_min, m->m_len);

    }

    return (offset);

 #undef COPY



It needs an updated comment, but should be testable.



        Mike



> > Regards,

> > Ronald.



 







Hi,



Thanks. Disabling both -txcsum and -txcsum6 works for me also.

I can test your patch tommorow or on Thursday. I'm first testing a big mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 for some more hours.



Regards,

Ronald.

 






Hi,

Your patch works for me. I can send wake-on-lan packets now. Should I test other specific things also?

Regards,

Ronald. 

------=_Part_15493_225212243.1667020606673--

From nobody Sat Oct 29 12:19:40 2022
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 4Mzz4d2STbz4gw4X
	for ; Sat, 29 Oct 2022 12:19:45 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4Mzz4c3D4Fz3SnP
	for ; Sat, 29 Oct 2022 12:19:44 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 29TCJfB3039331;
	Sat, 29 Oct 2022 07:19:43 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id aJZQLF0aXWOhmQAA4+wvSQ
	(envelope-from ); Sat, 29 Oct 2022 07:19:41 -0500
From: Mike Karels 
To: Ronald Klop 
Cc: freebsd-arm@freebsd.org
Subject: Re: wake-on-lan lost from rpi4 (works on rpi3)
Date: Sat, 29 Oct 2022 07:19:40 -0500
X-Mailer: MailMate (1.14r5921)
Message-ID: <08463D8E-13F5-4EA2-A4F5-D2C45B90C0AA@karels.net>
In-Reply-To: <2086140007.15494.1667020606677@localhost>
References: <2086140007.15494.1667020606677@localhost>
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: 4Mzz4c3D4Fz3SnP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.17 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.966];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[karels.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 29 Oct 2022, at 0:16, Ronald Klop wrote:

> Van: Ronald Klop 
> Datum: 25 oktober 2022 20:32
> Aan: mike@karels.net
> CC: freebsd-arm@freebsd.org
> Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>
>>
>>
>>
>> Van: Mike Karels Datum: dinsdag, 25 oktober 2022 18:11
>> Aan: Ronald Klop CC: freebsd-arm@freebsd.org
>> Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>>>
>>> I wrote:
>>>> On 25 Oct 2022, at 9:13, Ronald Klop wrote:
>>>
>>>>> Van: Mike Karels > > Datum: dinsdag, 25 oktober 2022 14:55
>>>>> Aan: Ronald Klop > > CC: freebsd-arm@freebsd.org
>>>>> Onderwerp: Re: wake-on-lan lost from rpi4 (works on rpi3)
>>>>>>
>>>>>> On 25 Oct 2022, at 6:57, Ronald Klop wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> When I do "wake ue0 `cat /home/ronald/freenas.ethernet `" on my R=
PI3B+ my NAS boots and tcpdump shows the following line on my rpi3 as wel=
l as on my router.
>>>>>>> 13:39:44.344111 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c=
:da:00:21:70:46.6cda: ipx-#6cda 65505
>>>>>>>
>>>>>>> When I do "wake genet0 `cat /home/ronald/freenas.ethernet `" on m=
y RPI4 my NAS does not boot and tcpdump only show this on my rpi4 and *no=
t* on my router.
>>>>>>> 13:37:26.448251 IPX 00217046.6c:da:00:21:70:46.6cda > 00217046.6c=
:da:00:21:70:46.6cda: ipx-#6cda 65505
>>>>>>>
>>>>>>> Firewall ipfw does not indicate that it blocks anything.
>>>>>>>
>>>>>>> RPI4 runs:
>>>>>>> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-4f0c9b76c=
f: Sat Aug 13 23:59:19 CEST 2022     ronald@rpi4:/home/ronald/dev/obj/hom=
e/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64
>>>>>>>
>>>>>>> genet0: flags=3D8943 metric 0 mtu 1500
>>>>>>>    options=3D68000b
>>>>>>>
>>>>>>>
>>>>>>> RPI3 runs:
>>>>>>> FreeBSD rpi3 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC arm6=
4
>>>>>>>
>>>>>>> ue0: flags=3D8943 metric 0 mtu 1500
>>>>>>>    options=3D80009
>>>>>>>
>>>>>>>
>>>>>>> Does genet0 not support these packages?
>>>>>>> What can prevent this packet to go on the ethernet while tcpdump =
still shows it is outgoing on the interface?
>>>>>>> genet0 does have a vlan configured connected to a bridge0 for som=
e jails
>>>>>>> vlan3: flags=3D8943 metric 0 mtu 1500
>>>>>>>    options=3D80000
>>>>>>>    groups: vlan
>>>>>>>    vlan: 3 vlanproto: 802.1q vlanpcp: 0 parent interface: genet0
>>>>>>>
>>>>>>> ue0 is itself connected to a bridge0
>>>>>>
>>>>>> Is the RPI3 also on a vlan and bridge?
>>>>>>
>>>>>> Is the router (or switch) expecting the packet on the vlan?
>>>>>> If so, maybe you need to send on vlan3 rather than genet0.
>>>>>>
>>>>>> The genet interface has some oddities about packet layouts;
>>>>>> that could be hitting here.  You could try disabling TCP TX
>>>>>> checksum offload: ifconfig genet0 -txcsum -txcsum6; that
>>>>>> simplifies some of the issues.
>>>>>>
>>>>>>         Mike
>>>>>>
>>>>>>> Regards,
>>>>>>> Ronald.
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the hint. I experimented some further.
>>>>>
>>>>> Disabling -txcsum -rxcsum didn't matter.
>>>
>>>> -rxcsum doesn't matter, but you need to do -txcsum6 as well as
>>>> -txcsum.  (See the code that calls gen_parse_tx.)
>>>
>>>>> But when I use bridge0 or vlan3 as device then it goes into the wir=
e but on the VLAN which is not where my NAS is which I want to boot.
>>>>>
>>>>> Looking at the driver I found this interesting peace of code.
>>>>>
>>>>> static int
>>>>> gen_parse_tx(struct mbuf *m, int csum_flags) {
>>>>> ...
>>>>>        if (ether_type =3D=3D ETHERTYPE_IP) {
>>>>>                COPY(((struct ip *)p)->ip_hl << 2);
>>>>>                offset +=3D ((struct ip *)p)->ip_hl << 2;
>>>>>        } else if (ether_type =3D=3D ETHERTYPE_IPV6) {
>>>>>                COPY(sizeof(struct ip6_hdr));
>>>>>                offset +=3D sizeof(struct ip6_hdr);
>>>>>        } else {
>>>>>                /*
>>>>>                 * Unknown whether other cases require moving a head=
er;
>>>>>                 * ARP works without.
>>>>>                 */
>>>>>        }
>>>>> ...
>>>>> }
>>>>>
>>>>> There is also some code which handles EHTERTYPE_VLAN.
>>>>>
>>>>> I don't have time to start debugging this today. But would this rin=
g a bell to anybody in connection to a wake-on-lan packet?
>>>
>>>> I ran some experiments with tx checksum disabled, and it seems to
>>>> matter.  I have a change for the last block you listed that might
>>>> help, but I haven't tested it yet.
>>>
>>> This patch seems to work:
>>>
>>> diff --git a/sys/arm64/broadcom/genet/if_genet.c b/sys/arm64/broadcom=
/genet/if_genet.c
>>> index 327af8acbcdd..b7ab86e7931d 100644
>>> --- a/sys/arm64/broadcom/genet/if_genet.c
>>> +++ b/sys/arm64/broadcom/genet/if_genet.c
>>> @@ -1305,6 +1305,8 @@ gen_parse_tx(struct mbuf *m, int csum_flags)
>>>          * Unknown whether other cases require moving a header;
>>>          * ARP works without.
>>>          */
>>> +       COPY(min(gen_tx_hdr_min, m->m_len));
>>> +       offset +=3D min(gen_tx_hdr_min, m->m_len);
>>>     }
>>>     return (offset);
>>>  #undef COPY
>>>
>>> It needs an updated comment, but should be testable.
>>>
>>>         Mike
>>>
>>>>> Regards,
>>>>> Ronald.
>>>
>>>
>>
>> Hi,
>>
>> Thanks. Disabling both -txcsum and -txcsum6 works for me also.
>> I can test your patch tommorow or on Thursday. I'm first testing a big=
 mongodb 6.0 patch I hope to commit soon and this build occupies my rpi4 =
for some more hours.
>>
>> Regards,
>> Ronald.
>>
>
>
> Hi,
>
> Your patch works for me. I can send wake-on-lan packets now. Should I t=
est other specific things also?

The patch affects anything that is not IPv4 or IPv6, including ARP
(which seems to work).  Anything else that writes via BPF would take
the same path.  I=E2=80=99m not thinking of much, though.

I=E2=80=99ll go ahead and commit this.

		Mike

> Regards,
>
> Ronald.

From nobody Sun Oct 30 21:00:31 2022
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 4N0pb43ZZTz4gb0T
	for ; Sun, 30 Oct 2022 21:00:32 +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 4N0pb40RkHz3nYT
	for ; Sun, 30 Oct 2022 21:00:32 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4N0pb36gkPz196m
	for ; Sun, 30 Oct 2022 21:00:31 +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 29UL0Vjc008172
	for ; Sun, 30 Oct 2022 21:00:31 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29UL0V8o008171
	for freebsd-arm@FreeBSD.org; Sun, 30 Oct 2022 21:00:31 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202210302100.29UL0V8o008171@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, 30 Oct 2022 21:00:31 +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="16671636312.4b5F40FC.5939"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667163632;
	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=fSQtjWymmA8ubD5xN6raRLhqqwtNKpSISXEYQforgfs=;
	b=pJ4c/V+cV93WJ2QautwXzhuZ9igV8gqn2RAZ/SVTgNyv6a5OnsdJ3dYJoaBHXXm9RPkL5D
	w/coEr1j7E0HFiCP2EavjAagSlGUKNcuLvvIGft+MrgTNcbuBWC1k9q23Yg1QkswPYzek7
	/pmdTqLkV6TXs0Il4wty5JoPexKD5Czy1j5bxSUkg81jSRYFQjX/NQihMeK7/nr7cKusDT
	GOQgbtAx7S4VMrsDH+HyVJ5obheFyVmejybCceRqk71ngZjTxT0XTbB03uTweF9qk5VgCM
	wpWO29bsIV7zByBtylu/q3xbdJFYTrDjxElu6qyhyj+g8hDD3qgjqBGRomkULg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667163632; a=rsa-sha256; cv=none;
	b=xBsemP9joXteWhCFyJQket5FwRFm6vFB9RXRRx2EZdO5caVgOB58D29fcIqJzit7pVYhoL
	O2EcWHp1TrbWSWdwTW73faMZKbkmRgV1xlcrEJ73Z0lmAVYPt63qq2XiRJ4SwrLxIWZQtg
	6RIGXSzwLagQEj/8qYFB9GA6WP+4vXDsnP4zpycKLfOM3xkqJd2GKuiqSCnLHUSl1uPIci
	a0nudncCixqycjrD8JOjZcanqSHOb4TkoTc9khmmKcy8II6eLLaxO8JAtqxXPWG/9pBCUy
	ICId/gZkcUz6mJ0VuyMHI4usXdCRrIlM4sREQ8HGGbc6JbrItKrNE+xH5QiXiw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16671636312.4b5F40FC.5939
Date: Sun, 30 Oct 2022 21:00:31 +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.

--16671636312.4b5F40FC.5939
Date: Sun, 30 Oct 2022 21:00:31 +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.


--16671636312.4b5F40FC.5939--

From nobody Mon Oct 31 11:20:55 2022
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 4N19h23dcHz4fQx0
	for ; Mon, 31 Oct 2022 11:21:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147])
	(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 4N19h13KPsz4JwS
	for ; Mon, 31 Oct 2022 11:21:05 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667215263; bh=e/nJzfjSV5ok6NvkwmaWzDMz3SDtLzSarR3AtPOrc00=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ls006p9UWpHUBXxl87992n6k6X7KLxKFp/2dL9ylf6hnyebycdG6PT4AZtzOJVcKMpKLCW1Dg3Erx4vu3HegfhVXcN4uN8XXguVd1vnCzF2+sFu/cVDOKJ0PQTTT5YIrMJeHFSC+gSZGbhEW1RZ8s1qat9c0CFLz5mSCRkAMhe3RuRT6nhLIw8QRUBHOqfYH0uJD1tEZcn1025kq1AEphGUXTKqKjwX0gOnU9HxdAy0H1HMer9ZI9Tg3dp+RCQPD/4Hu3zAAiXB/WMAjP2t68yVnpPMGzpoxpjk/h+oFpDiyihBDSV8YpnidnuvhG2mP6OcxVb6C0KUGQcLeSLvREw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667215263; bh=HFhKmlGT782z6AaETIjTqVQoRAyrgqKl+MRkheDz6Zt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nGvwmFTPMmrb8G03w8o3EhgzCc3YLiJEVs90bG2q6mrlbAOgQGRy0OZem2hQLeaVvfWNPDwr+Ut2OjX39xNnM4C7jxZ7L7TJXnKV9DXao+hY0+RokywPeal+NmYrI4BXIgTMC/Uy1XG7ctN50hNvU0CBKA8HEqX+aZhHld+D1gKxAQutvjPk7uQxIOh5kBz1zrsCM1jB/Bfz8xqJgWamJcrB6tdGtc+TlZ2T4bgCWbtQCDRYSlVsleoqjQqGQoujsO9p6jAOfATMOd6P2+wmfYmMf5w6JSphsU42vlZoneQVNP4qWnI7V0/MOpZCg4WyZsqk/R8Uu65Opw3L1V5NRA==
X-YMail-OSG: WvecWyoVM1ls6lJq6vGWD_MvAGmZBkUtmfVtr0VuPgeRCj3yT_PHTyIpUNTfh5b
 JteBbqEOZgv..vuFvVPPJjjYBZMeu8sj9JY0yrY5sN4TiXOzOGcWk.k.uqoaPmh8IBWRxNQ7W7D3
 gn92xouxH2oSiaNHh0dMjPa6ZjCDIcuorkstikjPSHEveoOXo6RpWok6h6TWbo06MgnvjhVNkpF9
 pRF39W1sFcGb5D0Kp01ohUCtz1Qpa3zXmC23DStlBSqs7sFDMj.n7uT8pqG838ckTjXm6X96LRSM
 thk3HOdJ40ug1FFycJl3ZvaJ1x8wz.uFATI6xSkBTFNZGhyHgV.WVeM1EAnOP6v0BrSnb.T.pFxi
 ZIvqdoGhEda5VvOEOIdw5LNaFe_SCb9dEbBlYYWmFNfURNYvWymNZeC8y_4lK7E0xdRv5DSSDgFs
 RHsZT.Esl5prCFkKOLgx_X4kq1_37_ZaLF5KpqYnpvGgTsE0bS6oVAfARx9QT2_dE1B.7QYHKJeu
 WFAtCcaz6huudFvPwSUBN048Roz7HBNL9i.EeniCtLbbaUxPajv_dHW6_TV8AfjlzHaKBVOwGmQH
 7OoIM0hNDJr4U3JuZ527bEjtPXiuAaPq.7dR6f6zDa0dITjkze3aB8gfC7sJBS.PE4w0Ia0.FQ.t
 R5IJnAEhmQUy78uqO57sBJwhGwmbYEHB0zsCXm5A4PhQNDBsISNR8D881WEKta284KfIk55LksPk
 VqKT9icbeo9a2S1bep8JjOpq2IPDL6rQjSTfKIv2d41qYIE05APThdJuJj2uhEd8Ijj8ZA4TeYtH
 UDspKoNlJbJqq5bduGJDt7JaGtZ0S9XGgZFRozfhln0sog1iPF2gFr.EKLU6zBRsK559bu8bRG3.
 HDIw6fovg_dZgmdyYikqDvcYhjCQcpkgWCdgpt0DAiknrbG6sgbcCh5cGUc24siv_aDwLHDWWUOf
 CWKphIl8hguh8wbUTPNLNhJAK9l5GLE9WzgGciI_iuNIM_O0dmGtO2CNrjHs6f4FnAvFTzNse_K1
 tv1_ZMZhgjVp1Lm7UXLrA65ggMSjx_22Ni9Ga.WwNHZq0cHSzU0SOIg5ovls9fGfxoYKz8bYPpFR
 Fer5VUfXJxolSrsHhC3ii__.aS4d1M8tkijxvYw59BYrm29AExWzS.GQSMYaQcSqGZdC0Y391oiV
 Ec0bZecySSiL6ChDoQdGqFHuCnkgrfHGRZYHoeqbfzHPAb4uzd0N1fF0xCJR4MgjCvo93xFr4Tvv
 S770fxYmxn9uhuI_UjigVQlEq6Ab3MKFdOSqyvrUks9Wb4W.uaMw.hZzV5qz1a4s11K8UuP3.X0f
 _ARodG1MH0jcglBNLA68U8OOy15S0D8W0LjrWB2fGr0YcOITKfKDN1HrVAgmlwRVaxrKbFWlJpFn
 6LuFjQyqz5QP4jGN6kV64ZMaFPAQBXjKTPfspWOR_dmALtYUwKY8s_VHEAfFe.9JKZ4TwCyfCluB
 3mTrEx0fSz7VOr1sHMiLpua1h2W3VMMPmyeQn59uzNF9MxL26L9FqB75My.ztsOUP.MzQCUjBDbI
 4ardqn7HAYRLJzRYWrU3pHQ9OzK1lTFfZaAqw.oiWX35mV_yrDElL1ZFcorVw0CXLVqmR6gkOqDU
 POIszd.No.H096RzSHXH_ygAMZpjeWCr3zAdiDlDuOm.YQt5qPELvIavdmY4cIofb1.0YWydoMHx
 dUbMDxdd0WGa5QCeZOVJzwwZQEYNfuprmoUKtA8nENZ.oTI5_DwpspGM__BwAe1GzE4D4Gkw2jVF
 1dOlVujw6myc7ozx.HTHPUeFCunREZNi7ugZ5C49f6V3agdb0EHdMMVKJhA8uwJaWCwRHHN8MSUo
 Yi3VsKRVUZjW2UgbGag2ThH.4BILN2D2y47BI5NZDm0SzqJPSL.lJe4IrBzX8Tq0JhNfvH02q3lB
 QTLOlNm8rqeJiR_S8.DNI5sg_L1JRlLpN7PiRTjScGXsodkeUk090NB6YUijrPk.LiBVY4YU_FDB
 IcIjjUDInDfQgoH7ELliD.J70rtoU6cR7Eo25zRXMcvQ1Xo_nS4mhlRZH06ZUcI_lEwfD2ila6cc
 KsXH.d.412y4uQbzoKOR1n0M.a9b_xmKdkcDpW5S2mc2ZVXPTOhlQNpKBtKeQwH_oDxtirQanJp3
 BCwfnyxMR5XxAM3nSTAfg3GAHZONshRphRcRx1kwEE06i.S2RzxL3Es2s4hTjAjylKRAQmxUEsU9
 whP_S0Xip6tuBTE_RVUx3ePsw6QpJUkTj3_dOK8Isp3kpcTbCcTGy7M1_PydV7jlJn0WNsFZSMCA
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 Oct 2022 11:21:03 +0000
Received: by hermes--production-ne1-c47ffd5f5-4cgrq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0aab598650b64a30255452cd7c4baf24;
          Mon, 31 Oct 2022 11:20:57 +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 \(3696.120.41.1.1\))
Subject: Re: sysutils/rpi-firmware update
From: Mark Millard 
In-Reply-To: <82FEA78C-96BC-4B6B-AB90-2CF521250FA8@FreeBSD.org>
Date: Mon, 31 Oct 2022 04:20:55 -0700
Cc: "uboot@freebsd.org" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <82FEA78C-96BC-4B6B-AB90-2CF521250FA8@FreeBSD.org>
To: Juraj Lutter 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N19h13KPsz4JwS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Ls006p9U;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.05 / 15.00];
	NEURAL_HAM_SHORT(-0.92)[-0.923];
	NEURAL_HAM_MEDIUM(-0.87)[-0.874];
	NEURAL_HAM_LONG(-0.75)[-0.749];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-31, at 01:17, Juraj Lutter  wrote:

> what should be done to update sysutils/rpi-firmware to the recent =
version?
> I=E2=80=99ve tried to naively update the PORTVERSION but I=E2=80=99ve =
not been able to boot (I only tried one time) the RPI-4-B.

To my knowledge, no one is actively working on support of the
RPi* related code base in FreeBSD.

Until/unless someone works on correcting the FreeBSD kernel's
handling of the more modern .dtb material, the last
tagged-version of the RPi* firmware to be tolerated was (as
of when I last tested):

https://github.com/raspberrypi/firmware/releases/tag/1.20210805

After that the kernel dies with null pointer based accesses. See:

https://lists.freebsd.org/archives/freebsd-arm/2022-April/001302.html

(But the content was "as I explored", including making operator
errors later noticed and given correction reporting in the
overall sequence for the reporting.)

For reference, for tag/1.20210805 :

# strings /boot/efi/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 18:14:56
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Aug  3 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: 40787ee5905644f639a2a0f6e00ae12e517a2211 (clean)

When I tested, the observed failures were for:

firmware-1.20210831-fails
firmware-1.20210928-fails
firmware-1.20211007-fails
firmware-1.20211029-fails
firmware-1.20211118-fails
firmware-1.20220118-fails
firmware-1.20220120-fails
firmware-1.20220308-fails-non-kernels-same-as-1.20220120
firmware-1.20220308_buster-fails
firmware-1.20220328-fails
=
firmware-1.20220331-fails-non-kernels-same-as-firmware-1.20220328-but-for-=
bcm2711-dtb-files


It is  not clear what you are looking to make work observably
differently by updating just the RPi* firmware to more recent
than FreeBSD officially supports.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Oct 31 13:15:56 2022
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 4N1DDh1JFfz4gBrT;
	Mon, 31 Oct 2022 13:16:04 +0000 (UTC)
	(envelope-from otis@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 4N1DDh0XC9z3F8W;
	Mon, 31 Oct 2022 13:16:04 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667222164;
	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=L9iTP6eUXkKPvgDzWv7N5O4t6bZJus2uk4INRb0Qaq0=;
	b=SrYNAKTUrdYumDQZtlPRTQlBVow5lkWHP9LI0BMNB0vLMkBmEwK0ZSLUHpvL9cA4g1uqSK
	7O7BAl/pJ9/2CTmwpM+g7jth51CEPsIOBg6ExUjnA8xNP+kbT4VIvor0wwoOcIzZcFjQT4
	R37dBIAE6EzzrXm11NZC3lkNGm0Ag5zqlWqTUWu9wbwUtDtCRCS5PpLNl+eJU8EtEMJNjj
	Cdv9UI+AMBJ1rwqPye4rkuGkvb/9HwaGMLe8uo7ddGrSg6qRd06MpiswGwRl8PhOZOrv/E
	5eFEbiNR2wGcILB2XqpZn1hrpA704dxdPfQnTXvb0FmvnyDmjKSbkNP0pr80Gg==
Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N1DDg61hbzWPV;
	Mon, 31 Oct 2022 13:16:03 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtpclient.apple (unknown [217.73.28.193])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id 0B21E45D158;
	Mon, 31 Oct 2022 14:15:57 +0100 (CET)
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 \(3696.120.41.1.1\))
Subject: Re: sysutils/rpi-firmware update
From: Juraj Lutter 
In-Reply-To: 
Date: Mon, 31 Oct 2022 14:15:56 +0100
Cc: "uboot@freebsd.org" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A881278-6206-482D-97E4-BE15D7DCB298@FreeBSD.org>
References: <82FEA78C-96BC-4B6B-AB90-2CF521250FA8@FreeBSD.org>
 
To: Mark Millard 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667222164;
	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=L9iTP6eUXkKPvgDzWv7N5O4t6bZJus2uk4INRb0Qaq0=;
	b=t4EW1nFRJg4tUQdy9ZVEBhgIPOf2VXZOobizrSNEevkHt7JPs+f3e1NO6uxuGirPT2GX3V
	55dzIQxgpiMETsyPsWOzlHhPsLwpI1jEVsLkqzsb71Ij+RJz0NJCvmTyuqGvimMCAWS8yM
	zWkxOvw3voUQRAEBgdqP1yXum2ebGiNw3enik3Od7wTGwHb4cRIFohoOlDO9JaGJkpybkq
	b6ecXKIWnPsadJKfRKos5nscgyO1sMItVg6vOXVzr8dzPA4fXaadVK/1PyLgmjYb/FJQlm
	QJQFH3O/eEPdhDk8iuHBq7eTbvGNxutYtISsmivpAkUoDqm3ENuTPAH6S8MR6w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667222164; a=rsa-sha256; cv=none;
	b=WYsiN02XKPiBryQ+cY8WcEXN9FhNxVy/ISBmlsmtfJnVyA0znsS8OG97/QZ3aCvUDqUffK
	d8GGNkdke2IckWa6ufLs7r3JZVLskUrKd5LN7o+Fc0MSCczU9WEJQsVICdpNyQ7nbYOZhe
	k0LuYqT7NJQvILXb5p6/DhW7Y428T1Ktss12JuN/9AxJeYaX2JMXurWCw9cHRX+tK7iEiM
	OLCNdy9aj/Jzz1QRR4rrdtXzSs8DCVcSAc/axZlISmGlwhIKQfQ3bi+oLsGdKkrM7z33hZ
	zJtaeJUMFo42YaVcJPF9wDfVMHRCtbABznF2vbGBnIrw3rQHWE7aXiGx82ietw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



> On 31 Oct 2022, at 12:20, Mark Millard  wrote:
>=20
> On 2022-Oct-31, at 01:17, Juraj Lutter  wrote:
>=20
>> what should be done to update sysutils/rpi-firmware to the recent =
version?
>> I=E2=80=99ve tried to naively update the PORTVERSION but I=E2=80=99ve =
not been able to boot (I only tried one time) the RPI-4-B.
>=20
> To my knowledge, no one is actively working on support of the
> RPi* related code base in FreeBSD.
>=20

Good to know. Can I help somehow?

> It is  not clear what you are looking to make work observably
> differently by updating just the RPi* firmware to more recent
> than FreeBSD officially supports.
>=20

The problem I=E2=80=99m observing is: =
https://files.wilbury.net/s/A7jWesNiHQ7GM9e

My initial approach was to make use of DHT20 sensor that I=E2=80=99ve =
got.
It is an i2c-connected (compared to GPIO-connected DHT11/DHT22) sensor.

So one of the first things I did was to take i2c-sensor.dtbo from the
recent rpi-firmware ( There is no i2c-sensor in 20210805 version of =
firmware,
that=E2=80=99s why I took the recent version), decompiled dtbo to dts, =
added AHT10/AHT20
lines (similar to =
https://github.com/raspberrypi/linux/commit/c20376da5e61323410d1ffb076db1a=
e818ccbf59),
compiled back to dtbo, only to find out that the device is not =
recognized at all.

It did not appear even in devinfo.

So i=E2=80=99ve also added fragments for DHT10 and DHT20, then the =
devices at least appeared in
devinfo output (the device is seemingly marketed as AHT20 but present =
itself as DHT20 on the bus).

Then I=E2=80=99ve written a =E2=80=9Cstub=E2=80=9D driver, just to test =
whether it will at least probe and attach (and it did!) :-)

otis

=E2=80=94
Juraj Lutter
otis@FreeBSD.org


From nobody Mon Oct 31 15:36:01 2022
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 4N1HLH290yz4gVmH
	for ; Mon, 31 Oct 2022 15:36:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4N1HLG2Dklz3Vf8
	for ; Mon, 31 Oct 2022 15:36:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667230564; bh=72vBgYv8dQskazLlb1gk0b3KR4o4skaS60QEHtIldTE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p76J64YvyqdAm21N4XzrvD5nKfYnGqqXvnZWg30+sjL7+kgqNwP/CgLfUrpT4Ne2wBwTvGoIAcdpvvmnQWaRzWzn5Q4xT1gicBR8k3vVpTRigPAqBadpythR5xSbyIA3wo/kKHc/FRTZ9SrKOOgWVj4ngp9U3wE9i933xaCNkflg62iCVlag1HI2mRCQtvg0azQfeCIx9r7jwVfG31WdJnh0mbLG12ioEZnJa/o6B6cIKKLCJNxy7Uw2OH+uSwoOlozkFzp7+9ep3VBlhd3U73HQ3xuoD/uiOflKVKvS0jPI2OV/1hxfgtXvd9bEc0YfCoSov0uhMdAyTVCKSfprCQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667230564; bh=X+RauGE3+lfb/XPXHTCwuNodnIXW7PLZ7q01S8BCBI2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y8ZCDOlyYyH7K7kwHZYWTe7SuG4w/n4KsOu2EHTfYmRR3p1Rv6z2cXo10/cB7LZenu+2NfrnYzcUQkqU8jo/pMOKT/ZDKQsWkkJj4RcnHUdSZfBZFqBVvz53No3C/sVM1xAZkyxAqvAoxh+EKJwjOfoFB6ogQQTvXNvDYwf3PEQYhLYLru2ryUlaM5mav+2dLbJTPRjkHfZNfW9i/uUX/3louZmM8dtDXBgMddlOuF7tjPNP/UvUyGtli9OmhNmIo2xQ18l00th6h4c1Old79JUuLDlm/CqxvD+T9Y5mz1ouVMI0b6GpN6Y5VvMVHQ+RhP7044D1RPZUxBDQY6AGVg==
X-YMail-OSG: Ddzb04IVM1k41Oa.6JLuK0gJQk9y1pEFX34jFWR0KLPa2MPA_KcEGVJ9c1jhN9y
 DvvXeI_IL4ghB5lgZhB2bgfqOWhvyic_QMziXhLLIZY6bF6p6GEyfPKW4MLtMMP2G4ooqz4CrBD.
 Ck20U9BwhyJurOqLyOwvH2H8QhpEpoI7lQkHJA87oQSaJwOvkswn09oI1mJ5rQyfIV_0iGvXm7qK
 uP4Lfw7pTWtOqTDPUWIMCe6XOHLlMd5ySsdZRr32FjF4Af3A6_muCUiJV66MWETiyawOJjWU3ef5
 loTCRF3Xhiow_kOjPXUMM3vf1RQjAbU5qm5TaNsiPOAQJ8mwEHJlRMLVoEeo5MWJkGx.SWudqgTz
 VDmKcd1xxNeQbf9qXyxlywD79FIiwB8ejbFksJqLXNPPN0TClDXmZyEFt2Id1QnhVC4jTDNHIzq1
 j9pMGpwMQyyKjH9FIEp8E38bnKQH0qRyvDVhcq1DJifpWX36569pJoAlpLW8j0ktsnMGD8KISjzA
 90jmZhE.qHA_vnCk.ExFArC7fRWfd8HeLTMbqK_f8VIyp57p3fjAA_ZndCBYtckXapRXHcMoJ__Y
 d19A_EMqxCJbJ0cmqeuZi94VXv1h_El0EUUMDYequZr4wjfXykRZJ4Qc7R7LAp32g5H6EO14p5_H
 nrrWTU.SUUFqrpPc4nhECOMUOnW9OBIq6qRn1J44wW34xdVLYoevGOrxTDwuaWpIIRtbkn0gWcuh
 OJLJ4AJpI49RiMznStEYDdnpK_SWlNQvT9EUelRiDnN9woTkX9bfHVxBvSkGH_bzTUIXLjVbrClK
 GUVDVWjM5havzc1FGlKad7Flh_2z1eRjKi2S3u4px9ez4zlujRJWVl97nuqgwjyKbbcyw1vTYurE
 EpxzN8pnlansChiNvDFuPTHcwuwZbMTtmGrovxZsUc9X0hDUwdXTu6h9cJspHc6KnNpuWeAjcknp
 RzMk9WK4H4PfEE_OMu3qmj2Ie6SaC3hs.Jae9udA50TLPHcsBqI2I_2b8WJi_nA_SO7taYmgXOKK
 n1.7Of.MiKnqgQs584vrGDgeZ.0XJbOVo2k.5F.T_Z8jd_HuljB56wi7DQ1yNjN6B_cgmmdwnTGB
 dXntH8ptf_bCr.R3HGrCB6IVP55jzIOvSROXgXGArspm4bkCKMU6vV.pHC3bg8i1YN40IWJxTTXd
 5otDnz1HoUVusHaNzwIht.NcJo4.KXCDE7yPZXo_i0Io47bFWT8s8Di_CnagzhrbXIKuY.SrmlL8
 p6c.OfdJdCKM6SZgv7fz_.QsmS0I.y244xvY7.w47QL2_Yk_M2U5zI1_oEI4UVR.V3B4soAKMP6a
 EVIMmaZpMa6bgjOEPdYgOAKHXD3bvcxSbJYN9BQxiHdkOYuQW23j9_u7r.7aAs0QT_URLs7UxfoK
 _PBcfbMgHPqqG0uuvezwTzAyYaD0FSUhq1dtu2iyaLUBhwQ2vxpNrAfAWL8FrX1fClUXIgs.HEvc
 el8NmAXt7nOds38TeG2hviZjFFzzUTYT3efMMp.SFBf433Icfw0h9IedDeIpVyZNl0xCFUpdeFld
 y07shcF7y8tlTlJD.WrDW7x_yBZMAOMkbKzJYRBSLrA8WRTFDz5kJuUAi1c2vFP..vV.3xuL9TKp
 Ueuze3SIlbjPbXPQzAgiRbkQrpthBwF3q5wMdADH5w403O2ajYb7b_1HIf52mVsCCJahypy3mkxH
 PVMQAfF.KHk_isP6GF_fW0hU8rtlYG16itxe0iLp0l9.tHIJL8H0FemyMuEF.JW_3gnNd6xl3QI0
 OOJ2owXl03FHei.7jEJqnuOVH9_eY0C5SHH8s6YcUlMMBZZE7rH.LLgU5QJ_8r8OnKBQoGFSfclq
 rB7.JSVEQVwQ1QcyBbiFlJq6u3tttd_js9l.eSmckQRb7bqjo3nMbmZt_1w1xJ8rVcUO4.6TvGeo
 FMlUsZIhVUK3rfiBnZ2kKKRIzM4hQvAXt_.l3EegO46pt9xIeSBIzXjWLjd.3o9n43VCFpsCjWd6
 XoBgjLTn0CIw2929eQuZ85mFyk.mokHNXXTOlMpXnk2mQ22am0ZSGLas473WvluHyvAeGBY55HBB
 9cpH8cLvljnNZrXnboQPSWTv1G0mALilBjv9IVGXQIofQUeP.s529Uj_Ss_VONV0xojYRVe1cy1h
 fv0K.R06RfNK6RRh.aMeZUvWXXA_ac0DntaEJaxjinpDBRhACGmZw4wvUAdkQIC7oPGdDHLOLShy
 0Y.HC7z_o5P45_xmCboQIRxRQq9d3bzcP_xiA13ZC3PEMUhCIX7Ydyg8rbea.d3emFWjgnDfgliR
 tNA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 Oct 2022 15:36:04 +0000
Received: by hermes--production-ne1-c47ffd5f5-4cgrq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9fa824ca3499a3f9f6f46c8308ca8190;
          Mon, 31 Oct 2022 15:36:03 +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 \(3696.120.41.1.1\))
Subject: Re: sysutils/rpi-firmware update
From: Mark Millard 
In-Reply-To: <4A881278-6206-482D-97E4-BE15D7DCB298@FreeBSD.org>
Date: Mon, 31 Oct 2022 08:36:01 -0700
Cc: "uboot@freebsd.org" ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4693B4BF-4E8A-41BD-B5E1-6398A6BA3E43@yahoo.com>
References: <82FEA78C-96BC-4B6B-AB90-2CF521250FA8@FreeBSD.org>
 
 <4A881278-6206-482D-97E4-BE15D7DCB298@FreeBSD.org>
To: Juraj Lutter 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N1HLG2Dklz3Vf8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=p76J64Yv;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.99)[-0.987];
	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];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-31, at 06:15, Juraj Lutter  wrote:
>=20
> On 31 Oct 2022, at 12:20, Mark Millard  wrote:
>>=20
>> On 2022-Oct-31, at 01:17, Juraj Lutter  wrote:
>>=20
>>> what should be done to update sysutils/rpi-firmware to the recent =
version?
>>> I=E2=80=99ve tried to naively update the PORTVERSION but I=E2=80=99ve =
not been able to boot (I only tried one time) the RPI-4-B.
>>=20
>> To my knowledge, no one is actively working on support of the
>> RPi* related code base in FreeBSD.
>>=20
>=20
> Good to know. Can I help somehow?

Not a question I can answer.

>> It is  not clear what you are looking to make work observably
>> differently by updating just the RPi* firmware to more recent
>> than FreeBSD officially supports.
>>=20
>=20
> The problem I=E2=80=99m observing is: =
https://files.wilbury.net/s/A7jWesNiHQ7GM9e

FYI: from earlier of my 2022-APr messages about the .dtb handling:

https://lists.freebsd.org/archives/freebsd-arm/2022-April/001279.html

The tracebacks look similar to yours. Look like I misremembered
the panic text though. An example was:

panic: vm_fault failed: ffff000000862134

(not near the null pointer).

A failure was handling:

QUOTE
>                mmc@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007000 {
>                        compatible =3D "brcm,bcm2835-dma";
> . . .
>                mmcnr@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible =3D "brcm,bcm2711-dma";
END QUOTE

by doing bcm_dma_allocate before the bcm_dma_probe/bcm_dma_attach.

Earlier .dtb's had:

QUOTE
>                dma@7e007000 {
>                        compatible =3D "brcm,bcm2835-dma";
> . . .
>                mmc@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                mmcnr@7e300000 {
>                        compatible =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
>                dma@7e007b00 {
>                        compatible =3D "brcm,bcm2711-dma";
END QUOTE

which happens to have define-before-use order for what the kernel
does. As far as I could tell, .dtb's are not required to have
define-before-use order for such. So, if I got that right, the
kernel was supposed to handle the ordering.

You might have an option of making your own .dtb variant that
avoids the FreeBSD kernel mishandling: You might be able to
set up an always defined-before-use .dtb variant.

> My initial approach was to make use of DHT20 sensor that I=E2=80=99ve =
got.
> It is an i2c-connected (compared to GPIO-connected DHT11/DHT22) =
sensor.

Your activity here is well outside my knowledge base. But others
on the arm list likely have the background knowledge.

> So one of the first things I did was to take i2c-sensor.dtbo from the
> recent rpi-firmware ( There is no i2c-sensor in 20210805 version of =
firmware,
> that=E2=80=99s why I took the recent version), decompiled dtbo to dts, =
added AHT10/AHT20
> lines (similar to =
https://github.com/raspberrypi/linux/commit/c20376da5e61323410d1ffb076db1a=
e818ccbf59),
> compiled back to dtbo, only to find out that the device is not =
recognized at all.
>=20
> It did not appear even in devinfo.
>=20
> So i=E2=80=99ve also added fragments for DHT10 and DHT20, then the =
devices at least appeared in
> devinfo output (the device is seemingly marketed as AHT20 but present =
itself as DHT20 on the bus).
>=20
> Then I=E2=80=99ve written a =E2=80=9Cstub=E2=80=9D driver, just to =
test whether it will at least probe and attach (and it did!) :-)




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Nov  4 02:17:37 2022
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 4N3PRC6cxfz4gfK6
	for ; Fri,  4 Nov 2022 02:17:43 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4N3PRC09mQz3wng
	for ; Fri,  4 Nov 2022 02:17:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667528260; bh=RimAB+mHtiCNFLAxUyUwNUVYN5qTEXUXJEd+a09NVck=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=P3doSOsJAkPyGiSaLclG6rdepGcPmSyWngphgJu4g1ZJeAPBf2uafkUSLG7hP2fkMF+GEz8yZ23gkYkR3J0UndkDXchxEU2WGVSr55LBFzpwWA7+IuGyAPHZch9HK2tkepuC1l8FgxxeUT2kFHF2MGBEXxmBAIqcHGOEm4vYfK+DM3lCkpmUxG1hUB30YKyaTV6/qOfGfjjOexdErhRx2e6fkZfsz1MppH1FyZu49IYzqyAv/gB8g6orODis1sBRAU8nZtDDJ8L4uSucqfLMistgzIxoBifWiyJZo+oWbxii/WTFUzxuKBsUYble7SpHL50qAPCvuTfKycVt5aIzwQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667528260; bh=pPZ4Lnzl1j3IVW7p2NnC1h9Ov8Xg6aYwk/FfM362/HB=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nMT1S5R415+7Pq39wSdsCdZ25LRUh4T6isbi4BwzlUocCayRU5cbTjjy8hs5+Ryiy+eI3wcaVCMMEaAPG5wIfj/Qr2k9brPROe5Giq2CC0CecbeBs8FP3Idi0jUhO3qTAN6Qgj/qpklEbNEeYFPdaaH6bIZCiaesouqIBKST2cCTxbX6itO+PPASn+AbuGy9kZmoeIjFq91n2dki7a7gp2ZnZ4MoKd5hpJ6A+xilELxjqp+q/1MdW+hVz1BBBnVMnZfdBkZYYQyMorcM9BF+XJApvrmr+NUpdYeEz3xVteRFNUVkcnENJxoyIypikMVgNjmWdbHdmIibjYgVWIbyDQ==
X-YMail-OSG: gP4T_s0VM1kVGFPSRwUxJCFMZLSaM56PfQGWace.Yi6h.5G4.ASklrXBEmHFB58
 b0crjlmFI8HCu5FLVBKqkN3Dt2i3u_X09ocStkAgKD1lWLZp4_jj0bl0e4nUa6ba7XXzhaJBRSGM
 tjHl1dDxVjAEAdN4I3eYQbieAd_W7E53T6Z4iwf6vEx4cWj8QVzBY89olvDRnNljNAIpwo.vyLzu
 iBbG4qY9yvMFfWBAPTLExLaYGTMZ1a12dx067UUpj7l5WcocJgusnxVmpNeOoElgcdVBB5dxgFAE
 qM6Yx3yVZuo9BmLfrKQ6NP92WrSnvT835XSOO1qv50xbK..Ugu1cSJZSHE5AodmbaYmSsZ4jnxXq
 faTXbNDMnne4ARX7c6za6v9xXscUZa4gUfED4232l47Afsm8XtFsPgaHnV2DfbrhNX6QGgPMZpeM
 I4pGjVoR7QM5T3yi3CFAMy7nw5TBiyar2NW7.SF5C.G5drolvfDDzNVYRpnsm0TkPtlFUqKNLlld
 NLQY4juTg1bOzA4hisST2_mDvher59L6es6bJ5JQhp_l1c2CDHawt8lR7HXGA0PYtCZjUMDA9X6s
 NVlocMzY9kPy5.wXdd6GVJ_QTC9t3Gq627FP7C6NU5I_OKNZEgHMeeeIpFtmDcmAwHRIgob5yRo2
 eNLSEh.KyDsQWkhCCK192wMwCoAr8IMK3eBZmZPV3Fv5WN4YQnig25fb7stNValPSSPG9.2ptnkn
 npeaoQcEQLISov.03w4lSKL_V8M_gNg6918.LrLYQE68mOVg2trCPPIJJjoWuDPu7TA9Zn6YD92v
 dcIaVRByc5iFTdGYwviHBDqE7aYB1QqaMMLYvbVkL2rqJJAEPVbFA4kidaTBmh7WaGBAGxGAljc2
 iig4t17XFoKRTVsQ6CT0h8t7EXOzSWqoNzAfXDGezv9KuVRTAVcFJBEHGCHSp9Tm..vqkYGfDxw1
 nk7E1WsCM11SC9pqrC5948mifEO8GG5qEUWslHOJ1KiI3Ra58AyfKuZ8i_dlxtdeZxfQsL57bK9C
 RYsxs9425yRnU_pNfLY.zC2so1UBomjRIVZRVFnYYgZr8QtX1DEIDEINQzXLOfEyPV3Peey52rPH
 sWhGGGxNI7TrkPbDAvmowX3Jp7puZV8K_9T8VJyZBkDCSdnxEYbDZFQnTBDlNg.1vnI0pNT379Zv
 FBLa8dYb1gPKUQmZYzvCMT_pkE8o_CSPMtOFFIQe9e0JJGBYVajykPlIdRzgiQGpxol.pddeDOOS
 YxDl0p9Yz7mHsCXTJo5L42lTjtGHmXhktAlsWIAe3KBl9KC9IgYHcI0RNz_6jUeuDijL28lfD_NV
 YmCpcDE1mzK.Whlsousw04ZLzrTwc9NPHZq2fjKNL2AzQSzy8gW1vHhxibUub6.C94v4Caf3UI44
 5k8D470DIwrLk_Y0HdHGOwCufI4p5Jflt9Otz1FMSdj5SHC0SqZZuG9dIMh8_1bemZVSPeHFHc8o
 ge9NfiK_ewDItMzC.d_dI2uPHSyTZOvFJuZvizbEGTMHP.PgZRbgesSKWcFWcS5pOIgw32VWiqT0
 nOsLUa8GgfHpYGEqv.NBdWK4AmVHkO5dOpvWFSIH1OiB5KHkUZMTCGDLSgC3zuhRb0zATKNwRDE6
 t.0fuRb5868u.B3RXsg3LqOYsT58_qrPCkz5Bnq4VrMFKwUGwm_B5L.0.o3QyjTV4x6oncAn9OlG
 iaA0fG8l9Qyfib6gNk773N6YxuMvNMdzdb9Ml.bZ9hLZmQfsQFpggGns.CJr4dQccdGtdOazKae.
 y9Jw8vdhbH5Vz3.5JoCvRwx2GWJtamQYWBfBz.rz5gEZCcI1EP7OxtpEURESuc.XQfVvheTXOxJ2
 nX7GvRlzh7UeQvIZS18Lj3P0Flo56697M7TcYG5iBGSR7i0.Fc89J9TV.54A389YjxgDO9eOVF1G
 YDiULvK2kqz47SNUY5lnefsjrgUaS7iVUSXdN2t0TXxnZ0rSu81o2.LH8muXCipS.Q8_L4RyzOSV
 FQAYlq3BnWf7jrnxgNFZRdnf13SGNho3OtyRqIjxfiwV0AtaCj03LNLQqE3aQWIFKaavE1nNgroz
 kGMZ3RFZF2zUG__GFuhv6_SLkIgZauh0smqLFFyLj8Uygv4ueCdRlvwUrjU1C6MGAGJWy75cGHv3
 Sg_KvRxbBgpQ2JOMLG77LtArB2S9cTM7VgjAbBf.booibHTP8Dxtu60OnrJqElweZU6nFpH_fu0n
 atADTChGAa9NedKiLrqFh84EAPlfNjSOKOgaDqwu0ZdIEMhn5XSw1g2Prrku126jIy_pIna7qPCt
 U
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Nov 2022 02:17:40 +0000
Received: by hermes--production-ne1-6bcfb7fb87-tpscg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8b314d8ff9f9fbb0087921b8df330192;
          Fri, 04 Nov 2022 02:17:39 +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 \(3696.120.41.1.1\))
Subject: RE: FreeBSD Errata Notice FreeBSD-EN-22:23.vm (and related) could
 possibly use a note about updating the active loader
Message-Id: <97594499-BA34-4D86-AA67-615015B29AC2@yahoo.com>
Date: Thu, 3 Nov 2022 19:17:37 -0700
To: Glen Barber ,
 Warner Losh ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <97594499-BA34-4D86-AA67-615015B29AC2.ref@yahoo.com>
X-Rspamd-Queue-Id: 4N3PRC09mQz3wng
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=P3doSOsJ;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.35 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.85)[-0.847];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]
X-ThisMailContainsUnwantedMimeParts: N

FreeBSD Errata Notices  wrote on
Date: Tue, 01 Nov 2022 22:20:56 UTC :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> FreeBSD-EN-22:23.vm                                       Errata =
Notice
>                                                           The FreeBSD =
Project
>=20
> Topic:          Memory pages become unreclaimable
> . . .
> 1) To update your system via a binary patch:
>=20
> Systems running a RELEASE version of FreeBSD on the amd64, i386, or
> (on FreeBSD 13 and later) arm64 platforms can be updated via the
> freebsd-update(8) utility:
>=20
> # freebsd-update fetch
> # freebsd-update install
> # shutdown -r +5min "Installing errata update"
> . . .

A suggestion to put a copy of the potentially updated loader variant
of interest in place for actual use if desired might be a good idea.
As stands the binary update material gives no hint/reminder about
that step. (More than the binary update sequence might be appropriate,
it is just what I happened to do.)

As to why, my example went like . . .

# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update2.freebsd.org... =
done.
. . .
The following files will be updated as part of updating to
13.1-RELEASE-p3:
/bin/freebsd-version
/boot/kernel/cam.ko
/boot/kernel/kernel
/boot/kernel/kernel.bin
/boot/kernel/zfs.ko
/boot/loader.efi
/boot/loader_4th.efi
/boot/loader_lua.efi
/boot/loader_simp.efi
. . .

After the install and reboot:

# ls -Tld /boot/efi/EFI/BOOT/bootaa64.efi=20
-rwxr-xr-x  1 root  wheel  1262604 May 12 07:56:22 2022 =
/boot/efi/EFI/BOOT/bootaa64.efi
# ls -Tld /boot/loader.efi=20
-r-xr-xr-x  2 root  wheel  1262588 Nov  4 01:45:05 2022 /boot/loader.efi

Note:

My 13.1-RELEASE media is not just a dd of the full content
from FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz . I have
a swap partition and use GPT, not MBR, for example. Still,
I expect a fair variety of systems would not get automatic
use of the updated loader, whatever the details of the
13.1-RELEASE installation techniques that were originally
used.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Nov  4 19:31:51 2022
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 4N3rNZ2sCMz4hXB0
	for ; Fri,  4 Nov 2022 19:31:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4N3rNY0hQlz3fXf
	for ; Fri,  4 Nov 2022 19:31:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667590314; bh=fW7qfVb0fCegvYwU+yjiUNjFOtKBmFrqlfzydLNT5B8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Jn/FNCwyoD82Jp3h6NHY4ONhC4dwDtxQOk4j/Dvhb2uw+YUUQb3P6bg5J+BBzwGChkJ/qeFwq21KMPFpCemn2HWwcytDktEyiCFDjOgz3Y+c1gI3Q/lrt/MdKaVWZcEZBtZM9gISkB/YMTGmbZ0pAh9vmHg5oBmG4qJH2cO9Vb+pOey7iy3VRqSRIuR89cgMLPpigL4yyHHA+PfXlicsMk1X9seyfaVGMXdh2BWLUt6kv2IvYtD+g/XooTAF8UAZV1006BhKcs/hEe2B5BYxhLQwVk9vHuvoxYHTshujmFUeJKrYRCM7blW5zthuV9M4U+Z8o29aTwUaEqY+1Iz7ew==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667590314; bh=V3bu+956spPGMqdNKpwgnNftBlfvis4SN+Yf8MoskYq=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QZHWKhvDtG7m3Tj/Q/PSFfv/DKEQbygUKxSkxtOmgEMTy7GOqDfG8LyssWwxQQCsT/tQ3emZFIKw8lhXpt80ZZnEmDRra1A+PkA6RBC4mkZFsr3H+DxbClJ26R9nvVgs0ld88EJzYrmM90olhtvUVJIfxpszElD6M7qRMjOBjrBoWPp6ZieD99v26Rsiz++A0/0CAOzmJH1BvvuYGrxdCvbLMIFz/jEsBj7z++E/rX3Y/nM5YJ08v3OaG2sGnuzjwUyKTBS2zewKQOAG2JqYFeQUPYzXcYyVU0dR7dMx6eycg8vv5plhJlDzaP3UPMe5V3jW1FlvXKxUuYSMA1JrMA==
X-YMail-OSG: cPbrh4AVM1nE7HTGY3PtjsL8EEiYZpkIb4UNQy7J7pMvZhxxFi6jMj.npdb.qdK
 RBrOleH3Gpd5x4ODgjUaQSG8RsieBCzJmE0G_QfHFib2t_vxo0Gl1zk_AjAmJqev9VznQl1opjRZ
 6fLnqglScEBwI3eDmrMjhJhtA4ptl1qesU9a.mRZj6UaOHfTLvg2M9KzlebTCwuXfbwlIzYXRk4f
 PBA099FqHLB2tdWawRvgBzqJqucePJNcp9YBalu6uimEpLO640JfYPxDq4sa1YNINPelJDTudFGE
 74Q_bnuqIKPZSST1OggxltOrxaFKZCVfwSZHHVxEbu1TmsErdtYzDsklnY_40AYh07tVS3XDGdrd
 6ykvpGJxlpDmF_e7YgYu27oIcv87UDi85e4ttDSeuixCVxcdRg420BWsbSgz2aD1PCDFZAMLkm.R
 ubCgcLbb.HHGU.RlUyq9.M48iRLpbnzYRznjJjMg1wWKmsLQzfil1yZHUxTVI6dXTNT.6NPenmRn
 l4cwG1TxeYTVkuuHL3tNko6hzDdeanY5Gt5wMjLcqTbXpP5OoRD2aomHkxEnaGhpPFbV7Z615Ltd
 vwnXiMP6qdOmkj53ySst66nk4kStKZGazy9ZJvHPpgnt_3I9Gk9PiVKcz1.8UQb9HxjbKGiMM_FO
 H2SZGQE2NmqinD6QaziSJqeT5kwMGB1Tl56g6FqL_77ZujzcfZi8Azv5x9qkUpQzO4nhGqbUVttA
 d0HkKJ3lTtNTfSteUr0BOZhf80zqBsZyeBTRR8U7j0SQ3AqpHcuf7ZFddTmCvJHdaj5ZbX_khlys
 xgAgauS5KB6bvkJIBxmmdFxMBT2YOC_uEEVLl6sedmgWLPRt9WyS6QDIYBIUKSSzx1TTyjVjCasb
 OAv5XTAsaAYgJ8Ms8c3zI.lxpbfADjlyeHmmE_Ndrt4dV8LnDkYdH4I6GHURx8AeJdRjBIyDL2in
 8Bgsch7igFZY2TjfowmF6kx9Ofzfy_kYItp5OMKY2y7LbNS2LWXQ6N3XakU.PqaDI.b6I5l2dulN
 yX377pOLCfYnerZc8Cd5D4ANQUdhjufSPcxqe4X6tBr6tVq.Xe8exq.Q9cfgMM44h.GisCkhwezv
 fUbsAxWA4Y_szUYnpPeLHp.2lCl9rGFua2ON6hu1YCdv30R4hYI8M.G0PwSuVidnI1I6UNsi8zSd
 MY2rJMWNn2dn.PeK0MSLRJBRoHFnuFnSPoYPSmamlAlrBvBvgOoYiqmr0T2sJUjmK_MIxulgtsCK
 ZQgDaIhX30Lge1qWdNjZq6LAxZ3gp62XFoyCXMowSpReMY_C3dcQYQSA6IeDb9yYcciEvARvKtrJ
 3e0mI0tUHfhiYGfFjCk2WvdDW5ejP3w6CK.AFSQDgotuxqzwattocmck1knqZM92CJa_NUIqS_Lp
 z8GEVPNh2V80eBx9OGE4D4RrSZgPV_pPp8RYlaCz6IUee6JdhTnsBcoB5msexfgfSxk_zkb__Ihx
 7f.oJpAHr_2tL7ZXs2ewym.5BayRKTphfBP2WiKERpXOhFBLyMeX8h0Xw4WANUbWMYPjSYSnxUMT
 eH0DfgbjvT8knBanKnwSWQd46h_AQ89v0mx542IMUW88Unv4.so1fD_9IvY.31ScWWmdiweqC39A
 5ILHJeRY6ZJl2NptrukBXNBE9oJLg8v1vEW81IPyzOJartDfbdgPmyjxl6DtY.9RtDC5c26HqcNR
 XpR3Y55rGe64ut9UXlH4nNAikSWhxtm0R4Oet4rZvHQb_2m8iK7OCgDf1q3j6Eh4xrdlsG9r.Yr.
 s5EADoryEo8u2irDqCLTnJgv7KFGiriRxweycELim6bXGBD9G5gVboTa0tWB1kSig0gh7ZhISRA.
 M5fW6MddyPKqyrjSiAqH1rnQE7dDnegcaqPBhz5dSmkaTfiEIKfuGtbykknCoik2tTpVuPhpmgKW
 0mCBgvV7sfiM5aKyN_AtaC6dt93BAdknwfKPE86VVxuCkPaxYdGsYeRhKgYkw3MvbjAp9ZPtEFwT
 i57G_ZFhA7QWjYrvOxnYmh_7C9dMlGwrHMI9sAAt4nnvbyz7cG_qibSor4EpuROd8rd5eYSI6VmF
 wQxDqWOXhuUDkAlR_KHCS0H.297rKpyHnurAAHR5xuLukixzyFBlyced9G8JiNC7NnQ0CxFglw1b
 VR9PfbF0M0SYm_UwJu6SrsI4BvoiGLV1vmM9jMzEjb50ucoIm3xpKRPnXPWTVhLur3C0s_U9Htti
 y7.kALjtBo.NWDhsHb7u0dcUuQgD2tJWo_xsyfKzUukmlKj9f0fWTnh04xd5C
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Nov 2022 19:31:54 +0000
Received: by hermes--production-gq1-579bc4bddd-gwpsw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5d8cd76683ae8e1715048acbf0e2e771;
          Fri, 04 Nov 2022 19:31:51 +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 \(3696.120.41.1.1\))
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
Date: Fri, 4 Nov 2022 12:31:51 -0700
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
 <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
To: freebsd-arm 
In-Reply-To: <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N3rNY0hQlz3fXf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="Jn/FNCwy";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-22, at 23:00, Mark Millard  wrote:

> Well, turns out that part of the "Import device-tree files
> from Linux 5.14" is:
>=20
> =
https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rock=
chip/rk3328-rock64.dts?id=3D5956d97f4b32
>=20
> which has:
>=20
> diff --git =
a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts =
b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> index 3bef1f39bc6e..1b0f7e4551ea 100644
> --- a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> +++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> @@ -381,6 +381,11 @@
> 	status =3D "okay";
> };
>=20
> +&usbdrd3 {
> +	dr_mode =3D "host";
> +	status =3D "okay";
> +};
> +
> &usb_host0_ehci {
> 	status =3D "okay";
> };
>=20
> usbdrd3 is for USB3, so "host" now has a sort of dtb change
> in the interfacing for supporting host-mode USB3. The old:
>=20
> /usr/main-src/sys/dts/arm64/overlays/rk3328-dwc3.dtso
>=20
> has, in part:
>=20
>        usbdrd3: usb@ff600000 {
>                compatible =3D "rockchip,rk3328-dwc3";
>                clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
>                         <&cru ACLK_USB3OTG>;
>                clock-names =3D "ref_clk", "suspend_clk",
>                              "bus_clk";
>                #address-cells =3D <2>;
>                #size-cells =3D <2>;
>                ranges;
>                status =3D "okay";
>=20
>                usbdrd_dwc3: dwc3@ff600000 {
>                        compatible =3D "snps,dwc3";
>                        reg =3D <0x0 0xff600000 0x0 0x100000>;
>                        interrupts =3D ;
>                        dr_mode =3D "host";
>                        phy_type =3D "utmi_wide";
>                        snps,dis_enblslpm_quirk;
>                        snps,dis-u2-freeclk-exists-quirk;
>                        snps,dis_u2_susphy_quirk;
>                        snps,dis_u3_susphy_quirk;
>                        snps,dis-del-phy-power-chg-quirk;
>                        snps,dis-tx-ipgap-linecheck-quirk;
>                        status =3D "okay";
>                };
>        };
>=20
> which looks to me to likely now conflict with the below --given
> the added "host" usage as of 5.14 reported above:
>=20
> /usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328.dtsi
>=20
> that, as of the 5.13 import, has:
>=20
>        usbdrd3: usb@ff600000 {
>                compatible =3D "rockchip,rk3328-dwc3", "snps,dwc3";
>                reg =3D <0x0 0xff600000 0x0 0x100000>;
>                interrupts =3D ;
>                clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
>                         <&cru ACLK_USB3OTG>;
>                clock-names =3D "ref_clk", "suspend_clk",
>                              "bus_clk";
>                dr_mode =3D "otg";
>                phy_type =3D "utmi_wide";
>                snps,dis-del-phy-power-chg-quirk;
>                snps,dis_enblslpm_quirk;
>                snps,dis-tx-ipgap-linecheck-quirk;
>                snps,dis-u2-freeclk-exists-quirk;
>                snps,dis_u2_susphy_quirk;
>                snps,dis_u3_susphy_quirk;
>                status =3D "disabled";
>        };
>=20
> My guess would be that some kernel changes are required
> in order to track this structural changes, not just
> avoiding the old .dtbo . Testing showed that disabling
> the load of the .dtbo was insufficient to fix things.

FYI:

The mainline Linux commit that addeed usbdrd3 to
arch/arm64/boot/dts/rockchip/rk3328.dtsi is the
following from 2021-03-24:

=
https://github.com/torvalds/linux/commit/44dd5e2106dc2fd01697b539085818d1d=
1c58df0

The mainline Linux commit that added the enabling of
the USB3 host mode in
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
is the following from 2021-05-01:

=
https://github.com/torvalds/linux/commit/bbac8bd65f5402281cb7b0452c1c5f367=
387b459

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Nov  5 22:26:51 2022
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 4N4XCw25JHz4gbZk
	for ; Sat,  5 Nov 2022 22:26:52 +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 4N4XCv5nRFz40cT
	for ; Sat,  5 Nov 2022 22:26:51 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
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 4N4XCv4cvLzxvK
	for ; Sat,  5 Nov 2022 22:26:51 +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 2A5MQpwW064412
	for ; Sat, 5 Nov 2022 22:26:51 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2A5MQp65064411
	for freebsd-arm@FreeBSD.org; Sat, 5 Nov 2022 22:26:51 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 267580] 13.1-RELEASE and 13.1-STABLE not working on ROCK64
Date: Sat, 05 Nov 2022 22:26:51 +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: 13.1-STABLE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jwb@freebsd.org
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667687211;
	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=s2FV2QnO8eBK49RQ+l2haEAjMGrGkIzntoBEL4CQ+es=;
	b=dm7ip8VaoVsVzsDcGx0SBLrHQFFRCjKhocwaZYPVva4QgDB7kC33jlWc/9DzKttzr1JxPH
	8dk62cGhb2VzC4ubtoo4ZIIBcSBeyDopzx3q8B3e5SHIgWeJIv3sHusZAROq/jRNSQ52MU
	0ZbMeKDkqnwjlC3Bpe3lJonQcT6yljYi7MP0LpsujOMRGBhxPHmsdGHVa/+gMBcoqtT/aI
	hRSZpSjtiSZzkD7/T5phuArsy7ap/fHtTtUrw4uSWh1QKYJS1NRw0IYQd3LEJfqkCYrkBt
	Bjj73Bu9SRNdgKd0WxHs8K8J8HuzjwrTgaHSfYWned52bh4mkC4PhSj2t7dKhA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667687211; a=rsa-sha256; cv=none;
	b=XzqAWel8KRIpKfpRvOdx4f7EC4e/c+rUphTi5mA95yems3MGtJewqtW53bgE62HIlvkjLa
	C0G/QN/Jvm8s9wTASljOV7ce2jnP2CyWyFwthSHnAeCY5yRPNPaeIZ1u304y8I4hGMvf7k
	uuPex5p22JufbINuCDJMUuSohgClRTmI5thVy40DS1FmCCYKeXM/O7G8/ceIQ827+EuQEg
	rE5lCBUGdZrqumMenkXvzc+rkUXbCrGmCi2q7sNcoAaj1lTHtTnuGL5jkrpsruu41Aqx5Y
	cf+YPpv8XNhg6ns4ZrVtPPziI9I61/k6qd7bzejdPVCJHSB+CEkhI22KZPiU3w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267580

            Bug ID: 267580
           Summary: 13.1-RELEASE and 13.1-STABLE not working on ROCK64
           Product: Base System
           Version: 13.1-STABLE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jwb@freebsd.org

After running freebsd-update upgrade -r 13.1-RELEASE on my headless ROCK64,=
 I
was unable to reach it.  I tried reimaging my eMMC with 13.1-RELEASE and
13.1-STABLE, no luck.  I then reimaged with 13.0-RELEASE and it works fine
again.

This device is completely headless.  HDMI does not work and I don't have the
hardware for a serial console, so I cannot be certain whether it is not boo=
ting
or just not connecting to the network.

It's not a critical issue for me, but I'm available to work with someone who
might know how to fix it.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Nov  6 21:00:26 2022
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 4N56Fl3BCNz4h6Nl
	for ; Sun,  6 Nov 2022 21:00:27 +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 4N56Fl1G0Xz3DHd
	for ; Sun,  6 Nov 2022 21:00:27 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
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 4N56Fl0LytzbNt
	for ; Sun,  6 Nov 2022 21:00:27 +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 2A6L0QBA013136
	for ; Sun, 6 Nov 2022 21:00:26 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2A6L0QUd013134
	for freebsd-arm@FreeBSD.org; Sun, 6 Nov 2022 21:00:26 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202211062100.2A6L0QUd013134@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, 6 Nov 2022 21:00:26 +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="16677684262.09ADc8.10960"
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667768427;
	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=HabQSOtP5HlUGHTQSjdNn+KFey9uZWafVZZ5IyGKwHw=;
	b=DsR8Mb+zBdA2RKFkPC+3dQbjm2pH+2QhCChO3oU63DxIu3SlVObR0w/3QsCnXh6AejM9iG
	1ST4hRyQN8czKLit7CsNYOJ0esEiwwPGvu8L0O8WhERm/qstpeuadKsxzQafDh/Akv8B70
	Bt2ejzgK0H/HSXqb94NlmgkzeJuQQVM5Tq+zeWLoxE4xILux4VRwEKTnxVVJf8j16mjo0y
	fwFB7PMN3fpmoSGEXGuFwP1y7B+CLGP8dzzJV2ixjif/AiouOD2mjk9kC0w2zYWnXu+5hu
	hkUfkctZueEzw84MfxuVwMFpQGJMNZblYKfe8KL2/kbEfJlJNLgLALROHr03sA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667768427; a=rsa-sha256; cv=none;
	b=Ji8yD+MuPIrpH0YFAuy57J0xbi0eZQ0w5HPQi28/tBqGjc1Thj+1YFqIy2O4sFql5EeXZa
	gnEaCISPjIcJ5CkY9ion4WT1KL+CRfV88RvdJaVJnhNXZ4v25Ps5tUelwGl4JKGFvRlm18
	F9kGO3KPE6P1lHdJ6FQA/TS+O+yUT5iSJkDh8AWEWtmLuEb4jBZGcKrB3rCApDzXEWMDnh
	tBYJ2DgXGAjrKNEeXM7UBTOF42rUVQoFUl16YYuODMv5FeCgM6WKZocTiX7FjiIy/wjIN/
	YDseH4eKVI7r3XbwL8wy84TClr13HdFz2WL9928t59IZIqWKa1afzp5PKJH5oA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--16677684262.09ADc8.10960
Date: Sun, 6 Nov 2022 21:00:26 +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.

--16677684262.09ADc8.10960
Date: Sun, 6 Nov 2022 21:00:26 +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.


--16677684262.09ADc8.10960--

From nobody Mon Nov  7 04:46:06 2022
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 4N5JbN4Gr8z4gtF8
	for ; Mon,  7 Nov 2022 04:46:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4N5JbL6DPFz4P5v
	for ; Mon,  7 Nov 2022 04:46:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667796381; bh=T309y9MMcPKmjIUoW0HXDlyR4ZkwSD7fImlbt9leCSw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=mx+eyPrgkMEsQ+t8L7hF24Ua/Yrn98zzXTccvZZzuZubmx6Js1FNEkguk5Bg8yckdp4ky4OJqj07tB/A1p2gLlFq5Us7S/bauFS/3kJ/ibPyf8VJQV3Z300Dlws4IzL88lZfiK6NcTDSYtddqikUg7AJS6Vju3Vm7O6GvSYugyiTaSXD0+x/HNXERli2uVxz+SVfJpOnw9JPxVhsmYeuLWaEmhp5Sub1/qXEV0NuDZd0HGyQwwA52lIC0xOAoq3a5pc+XppsK56xDCVGfmUviZzdphmUB0jylhRq9AstUY1+CJbAOQtGt/vImrGVCS4hVm77lDfCeAm3ivR7mQinVg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667796381; bh=m6BQErnkrdJiOj/wgAxmyCsaIy/iGwBDWV6WlqhReUJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RNc6G+F7EMOGzcKttOMpOTdsOGbxS7IuIfehOU8X5DDDdWC/vAIRYhIpAUiqBusGzjFewJVsZ/4OtMxsQsHAPVeyVSzjnPT+5j4Kr9Mxb/XNQymkHegAGopeNo2cHkMn9w7vJIJ4W5wvnB+EOaWuF45ON04Gmyk+mspkYfc9xp5QKZvkt6o+Njs+QV2XUaHlEQh4cobAPovrfwIV/kSIYlO1oCyZ+hY84HV2JBIs5MS0dq33zA0ybGxN7xlkPFspqnZyc12fEzkyul+RRSqndbpowKnGxbjJc6PwC2V1+5Mu/aGJZLD8XWwUYg7jkO730WaJFCUh1uPinA3yfbyihQ==
X-YMail-OSG: 0MJmW5kVM1km5D6aMAsTGebr6g8eskOmemHtIRFaExb.LsGBof7fv1KeyUG5GUm
 WXZfnC5djN_2kmjCarr8csvedF_OosQzr1F5DbjmD3BIWnWPz5T_.7Ky1Phb6Sb.YY_VtxWhxeEu
 61PoPR_Q6pD.3ohV8.D0zb5fwEmFp3bOeqPhJdxSM_8ZY6uvWPEZmEQhGchuHCrki1HtMC9LxikO
 cPFTSUwZGDM6PiYnfBHcimSD_YXcV1agS4EWr35XLjwLWryBFZnwPZefpbCnLT1VS71F.HT6Wn0r
 8x8NV7d3a.p04tE4._UUqIWegE8LCXSLtJZhM.Ri1gLlGtnz7p.JDhMl1SexSAuuncUj2jpKsOW3
 tI5CHhNu_F8OEQcRLB.fNSXh6mU4w1HT5M9SQml1ttTJuF9yjBIxa24H28vDk9__ha02lAeSZZMY
 5hsGViBDXRip_tCzt9ZCNpId_5qjWhNHLR1SCoEK_VTTqoPVzHb6Sq8uTFysmZS8Nf_P4Rw2ZPc9
 DLOdwf7jwYGMxJRLTj1SD.B32Cnwbecf5IvO1KKqfmhouXWGOzc326XHnF1gT5PmYutPoHqZQxOD
 aOWHox1qMF79XweuLoXbHnP8zw8ua.BtJwmmQ8WxpBsALXw9eYmi1cFJveIhsNjF6sg5zfjHo1DP
 eNpp38NdGGRCAlv.W02zEpAKqStDuWD7Am7fRUEexZrl7ZIsgKjE9Bfv3Qm0nS_eiFK6upOstYCz
 HL0tjrTkJ2wiW29EOdtZUpPZjUlhjf4JcIuULOFVrOT6y3yQMOWBiNY_dvUlAqATB5G7Hj4_BhLy
 NvlEMAosfAjShMg02ur4zX_VpEpOLqE4svd0s9zCcGfWMN9yRgvh7n7ypcxvrZT9GA1AKEy5IVxn
 _C6CJm_d8kEBfMuJBPbaLpVKgmWCU.q1VDiZ0MLP0CThPgloCZgxygDuQgcc9riIQ6BMp7bU_nsB
 edl7jBt5me.YttblRifx4mr0z7WZX9Y6rNyfipA7_aQhFe_OYyQoxAn12GxKlMOZAiUyYKSM_F.9
 S4Mhf9DzJPKYbfNteR7AuvHMopCDnoJnyzLPjFxZQeZnT7TpFJPNokp51YrgrJiKtXbQMCty6WTR
 vtu5.KPC3xA0f3WI7TKMdSvdpG8TBCyhqS0qD1ABk97iDk46o9dVyxKhzeMlWh0culq0Hl.P8ZEg
 VTugk7d6oLRAv4_i518M.JP.grpzz59mJrGr_48MzGPuPX3qGo3In8pdvYASWyy6xUz22JeAzn0z
 6fQqi0kWr.TSdfa7NUXBbCdpRrMoEGofC6OaWxgOCyedoiM2iLWLSM3FNAlokFNsAE5SlLFRoKYh
 3wceI0Xc.xJTygb76zpwt_oIPqw.UH0C_v2MEGHV0QC84B8sfD_kE4Ow0ccErZYpVFFKpQRbg8Tn
 CmfjCQQ.g8KpZumeInuPoKN4kCGjH6SUvcS3SUcj.BSmJChjj8eFXt_TvejwFufdWgYgNOL3QV59
 TTaFxHO5pWZ.IG.fUb0a676DpQff0Hekt.lPphzztsjUfjj2j6BdfFV_v1OM3tuhKoDFLVQeatqV
 Me0Af24rQiibNPCE6eLhq0uDudRGXC5xXYWlCQGTNU0Dnxbs5JJI3c4mRWEB4qMUyYMT968Ioacl
 ydYmWN.ja52Cb1Q.FMgqZirUg0_SPYTPV1W0A_Vuc1_2nQ95M1GR8JXvhdNFmK9PlvywSA38K3WY
 giiNGUmkavhM7FiYUUVZsgJ_OJwppA7C5qf42HoEsTYwguRK21y81Tx9ZXa7BmMFS0s0sL3XssaD
 01xw3YyeSZQBTHld..XT_x8A9WoKt3WTkoJ1O5msjGE_0Y02cdpfGr40.4Z782H0EnKI0nK61sr1
 WMajSYNIsSrsh2t0BHuk1zE0Qr2wHQioRCv3Du.rk9lZPDRGQ_5Etqx3USgZiX.1GxBVPpbKZuoD
 ujnwQOhGLTNUJY7JHmfmHuPBaG8D5phDsWD0iadbW42LIyrLLyuaOPe8Hsws4rZYQ7s6CBTBI5S3
 vTmHIVJvoraxvdP8.MfsQLuk5hEaaqDHREOG4CC7BoYbDO5B_OMD6EKa8eOGVQOUC3itGJB9u0di
 rxUbMJUbGLX3oKetFL604O0dFMC5ZI5xqDORXKKCYVvRWqwTsGEOUtzAl2w77mNA7.u.bgK0ZD26
 uLSZUrznEBAMcW8UBy5fEXX4ZeX6w9tNWDEok4FQMzlF2YYDwdN2lAOMoqXgce24mWFcR5wfLcca
 _Akyc_VqaY2ynjLv.8Tduv13MZDdpZOF6iVk6gvdrtl240CLBCHcb3UGBo71dTHeviwJ9nD4W
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Nov 2022 04:46:21 +0000
Received: by hermes--production-ne1-6bcfb7fb87-2hzbf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d420946141098baaed3cf27995795237;
          Mon, 07 Nov 2022 04:46:18 +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.200.110.1.12\))
Subject: aarch64 main [so: 14] upgrade native boot message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
Message-Id: 
Date: Sun, 6 Nov 2022 20:46:06 -0800
To: freebsd-current ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Rspamd-Queue-Id: 4N5JbL6DPFz4P5v
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=mx+eyPrg;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.969];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

The upgrade was to (long output line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

This was a native FreeBSD boot on a HoneyComb, with hyperv not involved.

The sequencing of the message was:

. . .
Starting devd.
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Waiting 30s for the default route interface: ......(dpni0)
. . .

/usr/libexec/hyperv/ is empty:

# ls -Tla /usr/libexec/hyperv/
total 9
drwxr-xr-x   2 root  wheel   2 Apr  8 22:40:03 2021 .
drwxr-xr-x  10 root  wheel  68 Nov  6 20:31:00 2022 ..



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Nov  7 05:47:38 2022
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 4N5KyL6PK8z4h1hs
	for ; Mon,  7 Nov 2022 05:47:54 +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 4N5KyK1S6Dz3G5m
	for ; Mon,  7 Nov 2022 05:47:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667800071; bh=DfELz+aP2dtK2saus50P0XaMTTeNNjLCOkdF9urxVQs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=g8ADp3R9fvrIuOzSzA8CLXend7qwejwDKKH2BwWM3KlGRj3euWCfaypZRi0JJnELMCE/5KnWz2zohU3fMrjFxGLrxkAahBpJZFVzDt3SlFUIP+9y56mMgb/aHnjqKjxQ/Q1Ed6jHAit+XE0qFmiL89dNxhzyqF6+NJ0nSPJiXYgZwy1oNZLKDa4Orvvyjczvvm6eI+ek1263XlRgprDScqI1kcNHcmwiAS+JDcWMTNeV/m7hU+R2MfdYu5Dfj2MVtKJbd/p2s2uzho86XeXMsJ5XjOX51ZZ+9MeRD+JdU9jmFUpWgRfuWZ2aV0DSNuOhg20PsaJIyLPzHTD775OwUQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667800071; bh=f/QIfSk0kAdSUP1HlQlz5dkbL0k/mBzQbzL7KS65TMZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=okEYLu4UJ+uEWrcrH0Gw3sB7qBDuydpOYarqHW3MeXOqSokQ+5y1NYrUZACT4s9ENb3zLG5iYUbJ897fFOBRu9GyyNtaGyMZvhZGMIBC5Zn3u2yH18lzH0Q6dd8CvPw1xv69uLOfptsvJOjh2OIT/5j0dlEI6Pfe/582+uayf7Kbv+Pl1nKW55zJp0a997e2TgEpM2wfdppvyBhLEZzX2rE6EQtsRVdTvZwV9Q/uhc2gdzl/B2vDCRXIMWh0iHF35scKTged+aEiZHKElaafqmo0FwyORhId0U/+2KTvmdX2ylAGxWINbJRk0HUg0NGCxx6jRB21gXF+HdLuU+WIBQ==
X-YMail-OSG: lwzciOMVM1mhjK_FZ7rUcb_6CEGc.uSWD6JmmMDIHylzLY26OD0nM8sDVhthVtp
 cIfgtDOgMBr6yZKLg3S6SHoaysdS8E36mf7MT92yB7fLHVlAUw3Z9SkJ7tKCfqkcuIHW.pqSVbPg
 Pbrcro1VBBbhqbwBu66ZHBe_6Azg81q1_RA7Azod_E5CBw3hy7Skc4zvvruaFpkQ0BcBBNePNGQm
 JxWcnvZ.5d5kzgs8IDgArGiRVYM0Cma59WxaTPlHNC7rGzMxLwekGSiNi8_faS05.TvJ0M88PYYk
 b5dV3CfkgdYEHJiMzfBcpOSC_s1I0iRJ1OJKCJ6iK.DGVjzm8eDT_2Q3fLcEwPfZRZxyp1jeB2Yc
 NZherh0tZZPpXNS4irfq9fvGpd_uiIGeTy9mTjTY7mlgtGCjHrmtum_L5uTCFMuiv_DBZ.8R5bbx
 OS5QzOEaJ4y4RDrh.V1CCJ3N59sdLYG2kKOL3qtyxjeZq0p6lMAwjr0Q.810UghP4gK4sHRm2kak
 lasm9utnLuQu6X0SGfpBPbuuhGGQ9tSWQeMlGmDjaYYNd1XHQRoePP.LjPJaI0EKPuk8bx8RZZcg
 eYb6RaaPtFLhjuhj23G1bi9nwMkrV4EX8F_c6Lvf50n28rWZi2E3d6CuKMr82deMC52zMe1BCMP1
 yXY7iMQA6TOKQwYRwTtAWPX_uv7XlhDiQ4eOnh49VLN4HwXMKwmh3D4eOzCerxR6ZLWrVggPPma1
 NCkXKcL7slJ25uF0iKenWjfZ69zMqwpU04OQGxNsUahEP2gliW.9Yx_EIkfHtdS5Bw_eitbFCXf4
 Of3xM4.1tLKurfvxmoKQHQr5llcnbQnclDncISng0_QUw0vpWiBDZlzwqFxq7urY7HI6HInxj9m7
 M7dQbP0VN9gQK4Id4MLG_TUACv9W2ErznJEdwsOv7OCpLvD8E80GarQA8RUMcT8o4rz76llCf34.
 1vhPMBfarlTwoRO5ZVwxqm3nGQlnhsXE0ufLB6tZmpcZAVRwxJt_DmjGqLhfqDDQv9N9p2A0zQCj
 DVAbeV1MGZmr9RwdLCJQKhuJ.VjDjSxXZUJzRK6uMqEwDcGHOCMi5J.QS6ra7NAQvO5OaPw.MQCB
 TnVB_IXMjK9LZXrt7fxiKFXYDCBDNHmEr2cp2bxE4nO3K6nuLFL_zVCf.cPP90Vw1C.FhGOco1bR
 tnn8pFuF46dHoDV2e5uvxVEbIkZUPJuwmJ9BEVlQsoSDI6uz8cJ6_a.wm2BVA42uFtzbvdjUA2Kx
 75bg69NxhOCmq8bLHJhJAEanUeUzeEHf9BaO0omHMgRLeB3ShUiE9qRHa9PBV2wJshssLoZBtNZm
 4ZBjG_lw4Tsca2aQMet9eLJV8FxxWA3bOMetML9FWBYWhD8wn79sSIdoDLzWTgfQIs5DmTNriYu_
 swwRaIfxjySViBQ66L._cATzVKjmWyHc8tufHpvFPnngC8.NbrgekK8uE4DFPkSkIbfso8akyXLs
 51uAoHQRnuewLO89GnhVhoc9jiQRnxFiZAGqsyM44NqqQJYBsrIlUD.2P0yNYzrlF7AjeKFMhg4P
 lEF_9ZxgBYYkXVIZSyvmQBNXm8NQZFavMcQQmjNpsYu3_x0bmiKU8qDFhrRHs1ZPM9dSDscGPjAF
 V9EqajXYsyBZHex.Xq3fG_yTR.dz6aPqfQkuXMli5ZZvd9tUzKMaqdOlxZNhQnmWiLOtNii1VwB0
 MkpQh_rWyN41BvHGZsvvhmShMKIooUwWxyep.E87FCpJrFakiDUK8Ko_SgJX008BeQWvOWKE6.Zi
 Q23HqzOJSTKdogWnhuWLd6dfwkaF.XxmQ3_7P6yqEsftfzMwra64XiTvWJwOlSWgCV.CDPWonx47
 U9BTrTWAXgYHBaaUHclxvAgGaDT6uDJ3DmTlikzxyGJsnQfNscYWIFb8rjlZayLkG9OeEoIxvkBY
 .cvalpy39NAzN9H8HeCtMdvckyuEXFehsedXaFMfCtBrMT_lasJS0WdX.jVG0v0iJNY2HT45mcRH
 eeGc1K0twaid_drK5hGkx5sRi6zsmp3TKBSTnZnVZjLF_K0kNWwNVl6GlaM2yL.TMMK_0UJ_9M9N
 E2nZ3yl6Hnh3Z0JseCYs7VaFV5IUSsulAdfTuhy3BFBS666VZyRErLOx4cZlvswu2vQ9sTH2L.MU
 RGjFhrH1CuIp46FwQfFAAItR.gYLLX7TK4Qdcb2jYaaVO1NJzCFwN3T.jJH3ZTIYzxrbupsPkvId
 NGu6kpAgjomHXhiOfHsc1vPCpbWNLerQHeXXKUclC9YgTi_ZfLYVzmsZ4oCBK81h.9O_33a27S2o
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Nov 2022 05:47:51 +0000
Received: by hermes--production-bf1-5878955b5f-f7np2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 88e7308caa554a43cf8355c6fad28c9f;
          Mon, 07 Nov 2022 05:47:46 +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.200.110.1.12\))
Subject: FYI: A main-n259064-f83db6441a2f-dirty non-reproducing crash of
 system clang
Message-Id: 
Date: Sun, 6 Nov 2022 21:47:38 -0800
To: freebsd-current ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Rspamd-Queue-Id: 4N5KyK1S6Dz3G5m
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=g8ADp3R9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]
X-ThisMailContainsUnwantedMimeParts: N

This is after having upgraded to and booted into (long output
line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

I then started doing more builds and got the failure
indicated later. /var/log/messages and dmesg -a output
show no messages about the failure and no messages near
the time of the failure.

Unfortunately, the error did not reproduce via either:

A) The reproducer materials in /tmp/ .
or:
B) Restarting the build that failed.

Nor was a core file left behind to look at.

The system has been stable for a long time prior to this (hours,
days, weeks, months, . . .). The only new environmental thing
has been I've starting using dpni0 (via the new DPAA2 support)
instead of using an Ethernet dongle. This does not have a long
history yet but I had been using it since after my prior FreeBSD
update as well.

It was a -j16 buildworld that got the failure. The failure
messages look like:

. . .

PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and =
include the crash backtrace, preprocessed source, and associated run =
script.
Stack dump:
0. Program arguments: cc -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config -DNDEBUG -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable =
-mcpu=3Dcortex-a53 -Qunused-arguments =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o
. . .
#0 0x00000000038fa404 llvm::sys::PrintStackTrace(llvm::raw_ostream&, =
int) =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:1=
3
#1 0x00000000038f8720 llvm::sys::RunSignalHandlers() =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:98:18
#2 0x00000000038acb8c HandleCrash =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.c=
pp:79:5
#3 0x00000000038acb8c CrashRecoverySignalHandler(int) =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.c=
pp:392:51
#4 0x0000000089f2ba58 handle_signal =
/usr/main-src/lib/libthr/thread/thr_sig.c:0:3
cc: error: clang frontend command failed with exit code 139 (use -v to =
see invocation)
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
Target: aarch64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg:  ********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/lang-0c2772.c
cc: note: diagnostic msg: /tmp/lang-0c2772.sh
cc: note: diagnostic msg: =20
********************
*** [lang.o] Error code 139

make[3]: stopped in /usr/main-src/usr.sbin/config
.ERROR_TARGET=3D'lang.o'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm=
64.aarch64/tmp/obj-tools/usr.sbin/config/lang.o.meta'
.MAKE.LEVEL=3D'3'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose'
_ERROR_CMD=3D'cc  -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config  -DNDEBUG  -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable  =
-mcpu=3Dcortex-a53 -Qunused-arguments    =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o; ;'
.CURDIR=3D'/usr/main-src/usr.sbin/config'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/obj-tools/usr.sbin/config'
.TARGETS=3D'all'
DESTDIR=3D''
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220726'
=
PATH=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/mai=
n-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr=
/bin'
SRCTOP=3D'/usr/main-src'
=
OBJTOP=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64=
/tmp/obj-tools'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA53-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null =
/usr/main-src/usr.sbin/config/Makefile =
/usr/main-src/tools/build/mk/bsd.prog.mk =
/usr/main-src/tools/build/mk/Makefile.boot.pre =
/usr/main-src/share/mk/bsd.prog.mk /usr/main-src/share/mk/bsd.init.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/local.init.mk /usr/main-src/share/mk/src.init.mk =
/usr/main-src/usr.sbin/config/../Makefile.inc =
/usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk =
/usr/main-src/share/mk/bsd.sanitizer.mk =
/usr/main-src/share/mk/bsd.libnames.mk =
/usr/main-src/share/mk/src.libnames.mk =
/usr/main-src/share/mk/src.opts.mk /usr/main-src/share/mk/bsd.nls.mk =
/usr/main-src/share/mk/bsd.confs.mk /usr/main-src/share/mk/bsd.files.mk =
/usr/main-src/share/mk/bsd.dirs.mk /usr/main-src/share/mk/bsd.incs.mk =
/usr/main-src/share/mk/bsd.links.mk /usr/main-src/share/mk/bsd.dep.mk =
/usr/main-src/share/mk/bsd.clang-analyze.mk =
/usr/main-src/share/mk/bsd.obj.mk /usr/main-src/share/mk/bsd.subdir.mk =
/usr/main-src/share/mk/bsd.sys.mk =
/usr/main-src/tools/build/mk/Makefile.boot'
.PATH=3D'. /usr/main-src/usr.sbin/config'
1 error

make[3]: stopped in /usr/main-src/usr.sbin/config
.ERROR_TARGET=3D'lang.o'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm=
64.aarch64/tmp/obj-tools/usr.sbin/config/lang.o.meta'
.MAKE.LEVEL=3D'3'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose'
_ERROR_CMD=3D'cc  -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config  -DNDEBUG  -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable  =
-mcpu=3Dcortex-a53 -Qunused-arguments    =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o; ;'
.CURDIR=3D'/usr/main-src/usr.sbin/config'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/obj-tools/usr.sbin/config'
.TARGETS=3D'all'
DESTDIR=3D''
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220726'
=
PATH=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/mai=
n-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr=
/bin'
SRCTOP=3D'/usr/main-src'
=
OBJTOP=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64=
/tmp/obj-tools'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA53-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null =
/usr/main-src/usr.sbin/config/Makefile =
/usr/main-src/tools/build/mk/bsd.prog.mk =
/usr/main-src/tools/build/mk/Makefile.boot.pre =
/usr/main-src/share/mk/bsd.prog.mk /usr/main-src/share/mk/bsd.init.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/local.init.mk /usr/main-src/share/mk/src.init.mk =
/usr/main-src/usr.sbin/config/../Makefile.inc =
/usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk =
/usr/main-src/share/mk/bsd.sanitizer.mk =
/usr/main-src/share/mk/bsd.libnames.mk =
/usr/main-src/share/mk/src.libnames.mk =
/usr/main-src/share/mk/src.opts.mk /usr/main-src/share/mk/bsd.nls.mk =
/usr/main-src/share/mk/bsd.confs.mk /usr/main-src/share/mk/bsd.files.mk =
/usr/main-src/share/mk/bsd.dirs.mk /usr/main-src/share/mk/bsd.incs.mk =
/usr/main-src/share/mk/bsd.links.mk /usr/main-src/share/mk/bsd.dep.mk =
/usr/main-src/share/mk/bsd.clang-analyze.mk =
/usr/main-src/share/mk/bsd.obj.mk /usr/main-src/share/mk/bsd.subdir.mk =
/usr/main-src/share/mk/bsd.sys.mk =
/usr/main-src/tools/build/mk/Makefile.boot'
.PATH=3D'. /usr/main-src/usr.sbin/config'

make[2]: stopped in /usr/main-src

make[2]: stopped in /usr/main-src

make[2]: stopped in /usr/main-src
        6.42 real        26.37 user         5.47 sys

make[1]: stopped in /usr/main-src

make: stopped in /usr/main-src




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Nov  7 16:10:38 2022
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 4N5bmy38mGz4hKQD
	for ; Mon,  7 Nov 2022 16:10:42 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N5bmw73DGz3bS8;
	Mon,  7 Nov 2022 16:10:40 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 2A7GAc9N090049
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 7 Nov 2022 10:10:38 -0600 (CST)
	(envelope-from mike@mail.karels.net)
Received: (from mike@localhost)
	by mail.karels.net (8.16.1/8.16.1/Submit) id 2A7GAcHl090048;
	Mon, 7 Nov 2022 10:10:38 -0600 (CST)
	(envelope-from mike)
Message-Id: <202211071610.2A7GAcHl090048@mail.karels.net>
To: freebsd-arm@freebsd.org
cc: jmg@freebsd.org
From: Mike Karels 
Reply-to: mike@karels.net
Subject: adding swap when expanding root filesystem
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-ID: <90046.1667837438.1@mail.karels.net>
Date: Mon, 07 Nov 2022 10:10:38 -0600
X-Rspamd-Queue-Id: 4N5bmw73DGz3bS8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net
X-Spamd-Result: default: False [-1.68 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.977];
	FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	HAS_REPLYTO(0.00)[mike@karels.net];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	DMARC_NA(0.00)[karels.net];
	FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]
X-ThisMailContainsUnwantedMimeParts: N

This question is not really arm-specific, but I couldn't think of a better
mailing list for it.

There are peridic issues reported on small systems like Raspberry Pi
where people are running buildworld or poudriere and running out of
memory.  As the user gets no control over the disk layout when installing,
there is no option to add swap space on the install image.  I have added
swap space on a USB disk, but this is often not an option.  It occurred
to me that it might be reasonable to add swap space before expanding
the root filesystem if there is sufficient space.  I have a prototype,
and wondered if this is a good thing to do.  Granted, this will often
create swap on microSD, which is not optimal, but probably better than
nothing.

The current prototype creates a swap partition which is 1/10 of the disk
if the disk is at least 15 GB and the initial root partition is no more
than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
probably enable this by default, but provide a way to disable it via a
kenv variable and/or a variable in /etc/rc.conf.

Thoughts?

		Mike

From nobody Mon Nov  7 17:52:06 2022
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 4N5f24324vz4hWB7
	for ; Mon,  7 Nov 2022 17:52:12 +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 4N5f2313Hwz4NNH;
	Mon,  7 Nov 2022 17:52:11 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2A7Hq8eS053590
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 7 Nov 2022 09:52:09 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2A7Hq6Fs053589;
	Mon, 7 Nov 2022 09:52:06 -0800 (PST)
	(envelope-from fbsd)
Date: Mon, 7 Nov 2022 09:52:06 -0800
From: bob prohaska 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org, jmg@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221107175206.GA49113@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
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: <202211071610.2A7GAcHl090048@mail.karels.net>
X-Rspamd-Queue-Id: 4N5f2313Hwz4NNH
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_SOME(0.00)[];
	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];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> This question is not really arm-specific, but I couldn't think of a better
> mailing list for it.
> 
> There are peridic issues reported on small systems like Raspberry Pi
> where people are running buildworld or poudriere and running out of
> memory.  As the user gets no control over the disk layout when installing,
> there is no option to add swap space on the install image.  I have added
> swap space on a USB disk, but this is often not an option.  It occurred
> to me that it might be reasonable to add swap space before expanding
> the root filesystem if there is sufficient space.  I have a prototype,
> and wondered if this is a good thing to do.  Granted, this will often
> create swap on microSD, which is not optimal, but probably better than
> nothing.
> 
> The current prototype creates a swap partition which is 1/10 of the disk
> if the disk is at least 15 GB and the initial root partition is no more
> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> probably enable this by default, but provide a way to disable it via a
> kenv variable and/or a variable in /etc/rc.conf.
> 
> Thoughts?

For starters, is there any hope of making bsdinstall run from the 
microSD and installing FreeBSD via the traditional process on USB?
No need to limit to USB, but that's a useful option for RPi and one 
option for many more devices. That treats microSD like a boot 
floppy. 

I haven't looked at bsdinstall in a very long time, so maybe the
traditional installation process isn't as I remember it. ISTR it 
allowing selection of a boot device, a swap device and at least
one /usr device. Maybe I'm confusing it with Jordan Hubbard's 
installer. 

Thanks for reading, and apologies if I'm hopelessly out of date.

bob prohaska


From nobody Mon Nov  7 18:47:29 2022
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 4N5gFw6qJKz4hcth
	for ; Mon,  7 Nov 2022 18:47:32 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N5gFv5933z3NFN;
	Mon,  7 Nov 2022 18:47:31 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2A7IlTX7091358;
	Mon, 7 Nov 2022 12:47:29 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id urpIMMFSaWPcZAEA4+wvSQ
	(envelope-from ); Mon, 07 Nov 2022 12:47:29 -0600
From: Mike Karels 
To: bob prohaska 
Cc: freebsd-arm@freebsd.org, jmg@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Date: Mon, 07 Nov 2022 12:47:29 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
In-Reply-To: <20221107175206.GA49113@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
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-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 2A7IlTX7091358
X-Rspamd-Queue-Id: 4N5gFv5933z3NFN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.15 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.95)[-0.955];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[karels.net];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7 Nov 2022, at 11:52, bob prohaska wrote:

> On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
>> This question is not really arm-specific, but I couldn't think of a be=
tter
>> mailing list for it.
>>
>> There are peridic issues reported on small systems like Raspberry Pi
>> where people are running buildworld or poudriere and running out of
>> memory.  As the user gets no control over the disk layout when install=
ing,
>> there is no option to add swap space on the install image.  I have add=
ed
>> swap space on a USB disk, but this is often not an option.  It occurre=
d
>> to me that it might be reasonable to add swap space before expanding
>> the root filesystem if there is sufficient space.  I have a prototype,
>> and wondered if this is a good thing to do.  Granted, this will often
>> create swap on microSD, which is not optimal, but probably better than
>> nothing.
>>
>> The current prototype creates a swap partition which is 1/10 of the di=
sk
>> if the disk is at least 15 GB and the initial root partition is no mor=
e
>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
>> probably enable this by default, but provide a way to disable it via a
>> kenv variable and/or a variable in /etc/rc.conf.
>>
>> Thoughts?
>
> For starters, is there any hope of making bsdinstall run from the
> microSD and installing FreeBSD via the traditional process on USB?
> No need to limit to USB, but that's a useful option for RPi and one
> option for many more devices. That treats microSD like a boot
> floppy.

I think that=E2=80=99s a completely different problem.  I suspect that th=
is
is already possible, fetching packages over the net, but I don=E2=80=99t
know the incantation.  Ideally the packages would be local, but then
the image would be more like a CD-ROM.  It would be nice to have
a procedure documented though.

		Mike

> I haven't looked at bsdinstall in a very long time, so maybe the
> traditional installation process isn't as I remember it. ISTR it
> allowing selection of a boot device, a swap device and at least
> one /usr device. Maybe I'm confusing it with Jordan Hubbard's
> installer.
>
> Thanks for reading, and apologies if I'm hopelessly out of date.
>
> bob prohaska

From nobody Mon Nov  7 20:51:50 2022
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 4N5k1J6NBcz4gLpD
	for ; Mon,  7 Nov 2022 20:51:48 +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 4N5k1H3CzXz4MV7
	for ; Mon,  7 Nov 2022 20:51:47 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2A7KppFv054072
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 7 Nov 2022 12:51:51 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2A7KpoDE054071;
	Mon, 7 Nov 2022 12:51:50 -0800 (PST)
	(envelope-from fbsd)
Date: Mon, 7 Nov 2022 12:51:50 -0800
From: bob prohaska 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221107205150.GA53784@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
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: <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
X-Rspamd-Queue-Id: 4N5k1H3CzXz4MV7
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=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
X-Spamd-Result: default: False [-1.07 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	NEURAL_HAM_MEDIUM(-0.99)[-0.985];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Nov 07, 2022 at 12:47:29PM -0600, Mike Karels wrote:
> On 7 Nov 2022, at 11:52, bob prohaska wrote:
> 
> > On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
[snip]

> >> I have a prototype,
> >> and wondered if this is a good thing to do.  Granted, this will often
> >> create swap on microSD, which is not optimal, but probably better than
> >> nothing.
> >> 
[snip]

Definitely better than nothing. I think it's a good thing to do.

> >> The current prototype creates a swap partition which is 1/10 of the disk
> >> if the disk is at least 15 GB and the initial root partition is no more
> >> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> >> probably enable this by default, but provide a way to disable it via a
> >> kenv variable and/or a variable in /etc/rc.conf.
> >>
> >> Thoughts?
> >

"Yes, please!". I'd suggest 2-4x physical RAM rather than 1.5x,
simply because extra swap is harmless and microSD cards are 
amply large; 64GB was about the smallest readily available 
last time I looked. Now it's probably 128GB. 

It might be wise to add a warning about flash wearing out,
but it took a year of near-continuous buildworlds to kill
a 128GB microSD holding -current on a Pi3 with ~3 GB swap.

Anything done to make FreeBSD work better on Raspberry Pi
and competitors is worth a try. Running from microSD isn't
ideal but does work if used gently. It worked much better
under armv7. Between aarch64 and growth in compilers
working swap seems essential now, the more the better. 
 
> > For starters, is there any hope of making bsdinstall run from the
> > microSD and installing FreeBSD via the traditional process on USB?
[snip]
> 
> I think that???s a completely different problem.  I suspect that this
> is already possible, fetching packages over the net, but I don???t
> know the incantation.  Ideally the packages would be local, but then
> the image would be more like a CD-ROM.  It would be nice to have
> a procedure documented though.
>
Since there's a complete system on the microSD can't that be used
as the initial repository?

I agree it is a different problem in terms of implementation. 
If bsdinstall can format a boot device for Raspberry Pi I should 
give it a try.

Thanks for reading!

bob prohaska



From nobody Tue Nov  8 00:07:08 2022
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 4N5pM36kXzz4gnPb
	for ; Tue,  8 Nov 2022 00:07:27 +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 4N5pM26LxCz3GZQ
	for ; Tue,  8 Nov 2022 00:07:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667866044; bh=Yx0pM741GGa8zQ0Sji1lqt4gUyzZygljhgUVycW/Pnc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tPNlEz6K58P8zpJYoRaLstSztjuXd0PNg/LnXmu0qmE8++HQ3XhfrE1uyWLcCRcKtg12qwp4hIPKI5dUgvV/UHb6PE8HoOxarzCbfpxsIwrfVOyJRwYLIbYjXtM5yo8WqXLr1uqfcsrQWlxcRtuv+A/mjOPwi06Vl/XaSzhmLDDh5g5q8/wxKee1sGHoFqzGMdfPGUI/+JtrZdM4Sr4iFeCs++9S9ODyNfrQUCkEcbz1Ca7PFOFVOYl4vtqH9VEPbgQALxEFry0eCe57165j30th1Sky60kMraChCCSlmxL3etiniXo3JS1BjGDlqQTF1r1WbfGC/p1qAM7T2QhdHg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667866044; bh=waVaI2Hu02p08BZe+gDOay2nGQL5N+qfMHZx7CcKNlF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cs0QR2kEp2g5CKK4feAoelr2GtQ1/hzGbABLVvBjBzyHX+QZUAoMAfzMtXQlutgcy2O+oUyA+NU1MAlxyDJxSF8RLYYNahSXLfvaElBkIR9jCY7/0OrluggYzJkbq6AReXfQRz0uxGYxA72T9k1xj76DPnUGw5fYyVXlREO8cFdroHNX3tMIZ+VtKAslk8496CQ/0VKwtbDdJfrBmrereYYW6ZTJGgOsfkLFdE0TeE2KAClBB8tdyRXmd8VlMU2Fane8NjIR+mkkXDZDwkNv/KEsX1QNPVWePcxqFOKsVXkMGvv8FkGREDdV5abzrGQOoe85Khksy5QWpYeqCBD7eA==
X-YMail-OSG: G_vEmf0VM1kflx1IvyFCrmPKQ6ZdfHJNpgtSZGQGpnpEEMwrK2FhRRJForYnfNU
 5ybeoZYEow8cMSeog9DeM2WmjD2Q3lBYaTJO_uLblCfFTTbXA.tIzs0ZhsZQulsPBpKG_MvSSH6E
 tIkgCFHhJXiUyoHdcxs3J7seP.8YhpAB2Ik4x5zMfFAhWH_xrgrI3chCGsAw5bSEQtegP8QAjOf.
 r85UMmlFxLVI9Epw7ZJdmDt8JGW15FgmsdSIpJBuszrXbx9rUTQEaXKxOyBw2ceqeuZ4MQQNMhsb
 fM2QLSVCbJoLlx7N0tVphdllIadEKCIDteQFEhiAkffdVpkpiv50KvVgdLVesroy9TtIGYNmp.pH
 1YBbaBOhjEi2ZAy.rKw.M6ikdPlKIeFRxGO64mbwKPUk2ZijexM222jpJ32SOIDMBhJ0TGI5sWuq
 HPHh547TFSBdfC6GVD6JjY56ExTES9zWJ8S0jHoh3FQlxvKL.d2Art2WhFHNUJ2hKKIvBeeB1xFV
 uooInSO_qlsPxWq28kEq_uJuLao7OJrJJydej060dC04RqzEuzsLVKx8.7t0.VfRx774a1xV6S99
 SgATBWR4t054msU4JVSn7SXuQgSj5CDtAr4Uk5p3vpMe8FeQmE6w5IwDmlTPIeNvLJNTDuSK6F_O
 KYrx_CVAfBEiDGlkfXZl9TBRUUD4.fjk7ypwIwCo_.wQfooCIQTuNLQ9ppM6z_cvdRq5Dmli77C0
 ywIEMgY9Sa4se..5yedgI6CAB4yjDLPWawnDGsjyUjqxEBif7ZdLPa.8U0l7pnQUgpNsKY2KoDpc
 VQtc_gJiNvU7wPSyJRrMiZ5qAtgA_0OKA7IxEJ803GLbQM65V7W4QKyEIwBuAAw.zFkFl0rPBXIR
 mdwYoMbEDaeeOGrmyxb_YnD_9ihra.ScnoDhnkxGk7LGQwGgsDlfRJYbG9edo4TTOKpXIP6uwWZ6
 MaFqYhbG0Nzxg_SGMI_EFA90rCRkwYQMdaHnXDUMmpWR7tfiSlJHomXT2x8.p67LSEPhzja2sT6c
 5YIdTUK1WNrV0fxgfMiAlqcD3JjYfO8ukvS9T.VuTTNUQPTY8NDf36kcg_rSrpazvPpXH6rFM4aS
 xjSIXYD3IUFlKHqPra4SHP3aNga10ifL6cQblYKH6rtOrrtsx9zY_Od5gaDveyoZOotJzh27KUap
 KuiHe_m.sg5uaBAWT2uIxPcdXTpzUhAHJ_w3j0ryctA69jKPpy.UyIPQAN5g4I1UknTERYOa5n__
 fdA0dD6UXqrcE2SrsYsWNCE4ddvi2MhsVRObS4HD9BhlEqSAyHlvivsiaGKlk2y0Z_j40ycOXTz0
 565EC3UqMl9FeUhxl0M3JZNxnE2cUffUg9mVhZNIwjyQF32wX5GquNliw9fb2qNx44h1hT9Sc7sr
 9MnfNuTY.HJgAwxDQkTY8M3zKb_pxLQbklYh7s.Fk0ODLdPTy5YnFkq4cgd7TSlS8gq4SKi1GvWP
 s8RApmIWWnUXhHvaJZIi0vDMo320S2cFhiYmyluqz._tIqdrFRFqSM0sHQA4dEfs5fKpSvYHL.lI
 Yqud3y5aUKLjl.j_hzE1L2eYfoY7cLzNP4Vw4Zgd6RpJ_uNYJP1ks1g3TkxzU.9_Tr.l.lTkwkZ7
 IwXn4F06ZvDoggIvlXHkxFd2AQCAxYvm2F_NzN2S4STHBM9VXzhcj.r22.vsZYTpkj6rvV7y4hit
 T8HZTHA.kijkgZK6Of2DItroCp2ffmzlIy4KW5DQmwYajFeKqwb55FIcebsB7lYuzedC_vC0HGnu
 HMKJicr8t1XCwdszmLtr4A4jrVECWXp07gUsUbALDZx1FT63jWqZym9BxFZLTwfzlD6m99es84FN
 .dVRqeewd8tGrFXfslpuf.qaPrBAqegNWO1P4X5pfkPCSJI81eu2Lh3gz0vLjAfxfEbXUt53Oc6i
 CiXATMkneqAb57hrjMa9Q9MBvFNPGX87g2.T4GGLeud2DeIkX4XJRYVY0dDiTyfTJs15oWXbXPB.
 PtrP7y89U5KLhoz52PeQtJuLHXptEcRdc2ct.PWkq7TR.CP7LD_fjP4b6qVuB0QdFD1bVzx2Ig1w
 IaEhPgrnhViW6g4P85frENqmXK8bl_GY1KwpCvynQ97maRJskRukfkgp3WWIPbBedQ4P7NKuWKck
 QbldeGhDY0BNcJpzDZwgpdYdC2Wx0UCEJgsjST.5HPN2G8G15fXeQJEPE5H83lkqluuBL6T34uMK
 D7DrGRYq4Lovy7kcBZg7UDrFvM4RRZztOVJnYJozaso9i_0sNsjg5hrwc0OyWtbJGNjBU0c0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 00:07:24 +0000
Received: by hermes--production-bf1-5878955b5f-sffnj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eb642bc4096ef7b39bf29f9c7bc2bf1f;
          Tue, 08 Nov 2022 00:07:20 +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.200.110.1.12\))
Subject: Re: adding swap when expanding root filesystem
From: Mark Millard 
In-Reply-To: <20221107205150.GA53784@www.zefox.net>
Date: Mon, 7 Nov 2022 16:07:08 -0800
Cc: Mike Karels ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N5pM26LxCz3GZQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=tPNlEz6K;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
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(-0.90)[-0.905];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 7, 2022, at 12:51, bob prohaska  wrote:

> On Mon, Nov 07, 2022 at 12:47:29PM -0600, Mike Karels wrote:
>> On 7 Nov 2022, at 11:52, bob prohaska wrote:
>> 
>>> On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> [snip]
> 
>>>> I have a prototype,
>>>> and wondered if this is a good thing to do.  Granted, this will often
>>>> create swap on microSD, which is not optimal, but probably better than
>>>> nothing.
>>>> 
> [snip]
> 
> Definitely better than nothing. I think it's a good thing to do.
> 
>>>> The current prototype creates a swap partition which is 1/10 of the disk
>>>> if the disk is at least 15 GB and the initial root partition is no more
>>>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
>>>> probably enable this by default, but provide a way to disable it via a
>>>> kenv variable and/or a variable in /etc/rc.conf.
>>>> 
>>>> Thoughts?
>>> 
> 
> "Yes, please!". I'd suggest 2-4x physical RAM rather than 1.5x,
> simply because extra swap is harmless and microSD cards are 
> amply large; 64GB was about the smallest readily available 
> last time I looked. Now it's probably 128GB. 
> 
> It might be wise to add a warning about flash wearing out,
> but it took a year of near-continuous buildworlds to kill
> a 128GB microSD holding -current on a Pi3 with ~3 GB swap.
> 
> Anything done to make FreeBSD work better on Raspberry Pi
> and competitors is worth a try. Running from microSD isn't
> ideal but does work if used gently. It worked much better
> under armv7. Between aarch64 and growth in compilers
> working swap seems essential now, the more the better. 
> 
>>> For starters, is there any hope of making bsdinstall run from the
>>> microSD and installing FreeBSD via the traditional process on USB?
> [snip]
>> 
>> I think that???s a completely different problem.  I suspect that this
>> is already possible, fetching packages over the net, but I don???t
>> know the incantation.  Ideally the packages would be local, but then
>> the image would be more like a CD-ROM.  It would be nice to have
>> a procedure documented though.
>> 
> Since there's a complete system on the microSD can't that be used
> as the initial repository?
> 
> I agree it is a different problem in terms of implementation. 
> If bsdinstall can format a boot device for Raspberry Pi I should 
> give it a try.

Remember that bsdinstall does not deal with U-Boot
installation in general. Also the amount of space
U-Boot and the like takes varies. The Rock64 images
use a 16 MiByte space for its U-Boot and the like,
which are stored outside any file system. Most
do not require that much but I do not know if 16
MiBytes is the largest example around.

(Always reserving a large space may make layouts
more uniform --at the cost of not using part of
that space in many cases.)

Nor does bsdinstall deal with the likes of RPi*
firmware installation. (RPi*'s are not the only
examples of some material going in the msdosfs.
But some of those may also require U-Boot or
some such outside any file system.) RPi*'s also
have armstub8-gic.bin and armstub8.bin to deal
with (beyond what is strictly RPi* firmware).

As I remember there are systems with U-Boot/WhatEver
placement requirements that conflict with use of GPT:
MBR is used instead. There are also issues like some
RPi*'s not being able to boot from GPT unless
bootcode.bin is used. Even RPi4B's might have such
issues with an old enough EEPROM content (unsure).

As I remember, bsdinstall uses no installation target
specific information and requires user controlled
adjustments to make settings that would work for
the specific target environment. There would also be
separate steps outside bsdinstall. The dd and growfs
handling style is, in part, a way to avoid such
extra manual involvement and extra-knowledge
requirements.


===
Mark Millard
marklmi at yahoo.com


From nobody Tue Nov  8 00:50:14 2022
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 4N5qJf0QYmz4gsnv
	for ; Tue,  8 Nov 2022 00:50:26 +0000 (UTC)
	(envelope-from ehem@m5p.com)
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256)
	(Client CN "m5p.com", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5qJd0nbNz3P46
	for ; Tue,  8 Nov 2022 00:50:25 +0000 (UTC)
	(envelope-from ehem@m5p.com)
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
	by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2A80oENI002120
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 7 Nov 2022 19:50:20 -0500 (EST)
	(envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
	by m5p.com (8.16.1/8.15.2/Submit) id 2A80oEqI002119
	for freebsd-arm@freebsd.org; Mon, 7 Nov 2022 16:50:14 -0800 (PST)
	(envelope-from ehem)
Date: Mon, 7 Nov 2022 16:50:14 -0800
From: Elliott Mitchell 
To: freebsd-arm@freebsd.org
Subject: FreeBSD/ARM64 on Xen/ARM64
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=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.0 required=10.0 tests=KHOP_HELO_FCRDNS,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com
X-Rspamd-Queue-Id: 4N5qJd0nbNz3P46
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com
X-Spamd-Result: default: False [-3.24 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.979];
	NEURAL_HAM_MEDIUM(-0.96)[-0.963];
	R_SPF_ALLOW(-0.20)[+a:c];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[m5p.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	TAGGED_FROM(0.00)[freebsd]
X-ThisMailContainsUnwantedMimeParts: N

Personally, I think merely being able to boot FreeBSD and Linux on a
Raspberry PI 4B is boring.  What I want is to boot both FreeBSD and Linux
on a Raspberry PI 4B *at the same time*.  I've got it operational, though
it has only received light testing so far.

Since it is the way to present things:
https://gitlab.com/ehem/freebsd-src.git

The branches of note are "main", "submit", "phase1" and "phase2".  There
are some other branches distantly related to Xen.  Also note those
branches are different spots in a series, "submit" contains everything.

"main" is things which have presently been okayed in e-mail, but await
some testing on x86 by Roger Pau Monn.  A key item here is an interface
point for non-x86 interrupt implementations has been added.  With this no
more changes to common code should be needed.

"phase1" is a child of main.  This is 4 commits which are approved, but
3 may have committers and the 4th may become unnecessary.

"phase2" is a child of phase1.  This is roughly the approach Julien Grall
used for his proof of concept in 2015.  Rather a lot of work has been
done to clean things up and update to match the current FreeBSD.  All of
this needs approval, but it has been tested and it known to work (for me,
at least).

"submit" is a child of phase2.  This is a batch attempting to go after
some outstanding issues.  The situation for these is interesting, they
may be needed for context.


One outstanding issue is where/when to probe for Xen.  The presently
tested approach is to probe during the console probe.  The reason is
this is the first place where Xen's presence/absence needs to be known
(otherwise no console is available).

Roger Pau Monn dislikes the approach, but is okay with it.  As such I
would need suggestions for alternative probe places.  The constraints
are, this needs to be BEFORE the console probe, this needs to be AFTER
passed-in device-trees have been parsed.


When Julien Grall did his proof of concept he implemented it on top of
the kernel event interface.  This seems reasonable for 2015, but there
seems to be a chorus insisting upon reimplementing on top of INTRNG.

I've been taking some looks at INTRNG and I think I've finally run into
the documentation /I/ needed.  There is a major problem with INTRNG
though which needs fixing.

If reimplement on top of INTRNG, the straightforward implementation of
xen_arch_intr_release() would be to call intr_isrc_deregister().  If you
examine the source of intr_isrc_deregister() there is a major issue:

xen_arch_intr_release() ->
    intr_isrc_deregister() for non-IPI interrupts (common) ->
        isrc_release_counters() ->
            panic("%s: not implemented", __func__)

Actual hardware hot-plug interrupt controllers are pretty uncommon due to
their price.  For interrupt controllers implemented as software, hot-plug
is a cheap feature.  Xen's event channel is a software interrupt
implementation and interrupts being added or removed is routine.  As such
this is an absolute blocker.

I had been taking a look at fixing isrc_release_counters(), but that is
troublesome.  Any approach is going to involve substantial work in
several places.

A different approach came to mind while looking at this situation though.
isrc_release_counters() is the inverse of isrc_setup_counters().  If you
look, isrc_setup_counters() is actually pretty gross.  It is storing
equivalent values into isrc_index and isrc_count (they are readily
derived from each other).

When you look further, there is even more ugliness.  intrcnt_updatename()
simply copies data from ->isrc_event to intrnames.  Why is a redundant
copy of this data needed?

When you look at the other FreeBSD architectures near-identical ugliness
is present.  Always copying data to intrnames, then having duplicate
fields on the interrupt structures.


Well, "intrnames" and "intrcnt" were added in 2004.  As such due to being
around a long time there would be dozens, likely hundreds or even
thousands of uses if it was a crucial feature.

When I looked, what did I find?  In the FreeBSD kernel "intrnames" and
"intrcnt" are used in a grand total of 2 places.  First,
sys/kern/kern_intr.c uses them for the "hw.intrnames" and "hw.intrcnt"
sysctl()s.  Second, sys/kern/kern_clock.c uses them for the
watchdog_fire() function.

After 18 years there are a grand total of 2 uses.  Removing the uses
resulted in a net removal of more than 200 lines of source code.  This
has the characteristics of an albatross, not a valuable feature.  Likely
looked good in 2004, but now...


As such a blocking feature for use of INTRNG is D36610.  Is there a
reviewer in the house?  I'm guessing the initial reimplementation of
watchdog_fire() will need a different approach, but I'm wondering what
reviewers would prefer.

D36610 is the large batch near the tip of the "submit" branch.



Anything else for the portion between "phase1" and "phase2"?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



From nobody Tue Nov  8 04:38:17 2022
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 4N5wMZ1QNSz4hKcN
	for ; Tue,  8 Nov 2022 04:38:18 +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 4N5wMY1RwYz3rGB
	for ; Tue,  8 Nov 2022 04:38:17 +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.16.1/8.15.2) with ESMTPS id 2A84cI0D055637
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 7 Nov 2022 20:38:18 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2A84cH5O055636;
	Mon, 7 Nov 2022 20:38:17 -0800 (PST)
	(envelope-from fbsd)
Date: Mon, 7 Nov 2022 20:38:17 -0800
From: bob prohaska 
To: Mark Millard 
Cc: Mike Karels , freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221108043817.GA55121@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
 <09E80B35-0325-44E6-8191-55DCC79A51F1@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: <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com>
X-Rspamd-Queue-Id: 4N5wMY1RwYz3rGB
X-Spamd-Bar: -
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
> On Nov 7, 2022, at 12:51, bob prohaska  wrote:
> 
> > On Mon, Nov 07, 2022 at 12:47:29PM -0600, Mike Karels wrote:
> >> On 7 Nov 2022, at 11:52, bob prohaska wrote:
> >> 
> >>> On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> > [snip]
> > 
> >>>> I have a prototype,
> >>>> and wondered if this is a good thing to do.  Granted, this will often
> >>>> create swap on microSD, which is not optimal, but probably better than
> >>>> nothing.
> >>>> 
> > [snip]
> > 
> > Definitely better than nothing. I think it's a good thing to do.
> > 
> >>>> The current prototype creates a swap partition which is 1/10 of the disk
> >>>> if the disk is at least 15 GB and the initial root partition is no more
> >>>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> >>>> probably enable this by default, but provide a way to disable it via a
> >>>> kenv variable and/or a variable in /etc/rc.conf.
> >>>> 
> >>>> Thoughts?
> >>> 
> > 
> > "Yes, please!". I'd suggest 2-4x physical RAM rather than 1.5x,
> > simply because extra swap is harmless and microSD cards are 
> > amply large; 64GB was about the smallest readily available 
> > last time I looked. Now it's probably 128GB. 
> > 
> > It might be wise to add a warning about flash wearing out,
> > but it took a year of near-continuous buildworlds to kill
> > a 128GB microSD holding -current on a Pi3 with ~3 GB swap.
> > 
> > Anything done to make FreeBSD work better on Raspberry Pi
> > and competitors is worth a try. Running from microSD isn't
> > ideal but does work if used gently. It worked much better
> > under armv7. Between aarch64 and growth in compilers
> > working swap seems essential now, the more the better. 
> > 
> >>> For starters, is there any hope of making bsdinstall run from the
> >>> microSD and installing FreeBSD via the traditional process on USB?
> > [snip]
> >> 
> >> I think that???s a completely different problem.  I suspect that this
> >> is already possible, fetching packages over the net, but I don???t
> >> know the incantation.  Ideally the packages would be local, but then
> >> the image would be more like a CD-ROM.  It would be nice to have
> >> a procedure documented though.
> >> 
> > Since there's a complete system on the microSD can't that be used
> > as the initial repository?
> > 
> > I agree it is a different problem in terms of implementation. 
> > If bsdinstall can format a boot device for Raspberry Pi I should 
> > give it a try.
> 
> Remember that bsdinstall does not deal with U-Boot
> installation in general. 

Ok, I'll give up hope for now.
 
[snip]

> Also the amount of space
> U-Boot and the like takes varies. The Rock64 images
> use a 16 MiByte space for its U-Boot and the like,
> which are stored outside any file system. 

I'm not sure how anything can be stored "outside any
filesystem". Might it be better to say "in a private filesystem",
as in not known to the running kernel?

Is there any basic problem with automatically establishing a 
swap partition during a microSD card setup?  A trio of self-
hosted armv7 Pi2's with swap on microSD have been running 
happily for over two years as name, mail and webservers on 
64 GB cards. Admittely, aarch64 is a lot more swap-intensive, 
but a Pi3 ran for about a year on a 128 GB card before things 
started going wrong. That Pi3 was running buildworld
most of the time.

The Pi2's df outputs are now straddling 50% capacity without any 
cleanup, so it's probably time to think about upgrading the storage 
in some way. Treating microSD as a write-once medium isn't 
outrageous and it may be prudent for shingled mechnical disks. 
 
Configuring swap manually on a RPi microSD system is a very
considerable amount of work. Having it happen by default 
wastes at most a few percent of the card capacity. At this
point I can't see any reason to say it's a bad idea and
have some personal experience to suggest it's a good idea.

[bsdinstall limitations snipped]

It might be worth mentioning the /boot/loader.conf and 
/etc/sysctl.conf additions you've mentioned in other threads,
as adjuncts to having autoconfigured swap on microSD. They've
all been helpful in my experiments on RPi2 and RPi3. I think
they'd be constructive additions to the RPi images and perhaps
others.. 
 
Thanks for reading, and all your help!

bob prohaska


From nobody Tue Nov  8 07:05:16 2022
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 4N5zdV4Dklz4gbv2
	for ; Tue,  8 Nov 2022 07:05:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.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 4N5zdV1ShWz3N6N
	for ; Tue,  8 Nov 2022 07:05:34 +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=1667891131; bh=xFFB3k0xsqdsEG0Ha8iOvyOG3FnFY35r0h1LxEySYDo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uXFFwLnBPy3IdDQy3J6IAX/kvNnqU1urwMN7m6v4RvGb0jRuN8gMTJfVr00o8OBN8LZveTIR1xEUK+C6Xmyz063U4bIqJNnYkgd1GMGQPzNQkx2qDPuGTA2zJMwXzvJzG7RZq0y/UmkTayPKdbpvdXVF7oUvuPtNeZ4tfv4zVtzVPzYD8eRuaBvlNXVeiXOpvj6ks5GEooLdvyaQnOnipzW5HH6dWHMNJca9Tv1ja8sbU/inb0N823DLP1HfpoJBinGpkpm9TtAJG1RTqs7uGflJFRpC7vmJEkD9VXl5Qo2VDKe82TJwMo5SvrZFVrALkleBWx/7zVYNYnsX5bIshQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667891131; bh=X4GraUN4WzHumC504eIiLo+mXjE6vqGIEsQIvRjFxqj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WWie2NJL6PRHflqkJ5fJRMRoxkprmmm/HMs/CStk+TBcZs6QqJrWGU38/Clz3aaa0+b3K53EpNx2dckOZKEpZwO16w1oz6YHVkN06Nhedg8+acKbE1RroERIsXa7pZybsCnMAGu5ackKAhbu2KI5g68k9raRnPey9GpU1yDh7vEGVAGsRvsMCVeO8rJNEqcFpgrHckDJRPzv1NI7dulfSYXAJFCDlB/u/cli5RA3+d80YHR9hA3eYZYHl32lX8SZd16PVTsSHNrfCHRDzuTmXW5e4ateguUuZpi+yeYBZSJITnvbJxgkIoJhlh/E6hV7LUtzJUFbTJvWDEhXGs7T8g==
X-YMail-OSG: 16QeWGwVM1nRuDUoFLlX0NQXS8N4cbAfFAgQTxfWwDBZZjXlEv_1RMeoCWUw2jV
 tRzxEgiWfm4buGFhGb087I7gXk3TFno0QeLf0SE99qCkcMWft58O2AXM7isbr8XajokjRRlnRU_.
 o_sqigpCv4OhYUkF9xuBYlF93zxyCEMX7FpG5_Wk44Db1mPkq58oAbehw9Xl5_vppA8MAyY.rWdH
 BGoGogoYIAUrBjvmDoWRfsMOBc_YMb5bYJHIa.6BAVOctEOaCk37vNb1S96ubLg7eEvh1cjlagdC
 32V7caCeEYmIdzUvNn.8INwIqKl1Psyq8yXuuEZYeL7A5QRVntpeWo.LcL54CdKH7rkd1wlG2qjy
 ZIE6zUUkTBwD8OLK4FRwaXmYfM.bFPkVYqtS8F3B40zgY0_xGA.B_XzTqr5wKfUMo_LBXRMze0N6
 xXjkm5YOoNSR.mQs4DHP9OVU78KzI7U4DYzeyvVr815sX4wErdoz0EBpk8XIWAeZBOzD1jmM4HR9
 .9q_cNdhPRZOPrZJwmkX40akcULsEC6.UictIDLfU73ccaY4y5cFgNDfRrOTPCBcw8prZHBmnj.u
 jO6GMk09VuPHSef6qJvhVnr4X6JFm6TfAZz4NwAgIhoYPBb9s8tTHQsPSO0q5gAh8FdziQGSodoF
 wJTu4MuYFGL4szDu96aE93ArkSaun6fZhW8WmcDiRs_1Ck67tMgB1mwrNU0ND8CpqZYeWT.AiL2z
 iLeq2rBIDtyGCfcCzgmBdGF_gI7r5X9NWyPKp1KnIbGvyY9OnM7bU6OhBE_WnXL4KkrzXAyef3Dz
 WlbIxsLxPU0FxkiU__IE2tbCvRp6uO3fzJZ4nE0QS0UPYV9D6ibWjxbBhNikWxEgFoE5rSYURwaz
 2z21xxHa4wX9PTehS46rwz8ORhr1FX4Np268unFsY1RJdIUkWtyhNg9MX65ol4UkC7YFzYvc3d_H
 tpqXOQk077bjym9EqGU1Q9JqXpqenRAs_iD0jBS7YVbEhrlETeOFOl_Y97uJYAjbN_XP9NCtB88w
 HbuedevD1CZTgmiOaASJ6.uUgi63THIcyODI9CV3ZQfIEbJQJ5yLiUYSWXYX20XuKiB_Wj6zdTAK
 CPJL9iE_1o6pwgQzrtjRNmSLJu0hadFZdm2tAMKL0wv8YWyDAWvXhn8ZRxUdHEaPwUHqZ5i2MOe2
 YjAS22mrHhg51wvHLrIhAZQ.lMUbfwma0diCycFLbXMhgMx679.RB2yPeTdB4GXN.l8aRtuc.xnX
 OOdEK2Le7KP82juD5aF5W0.1aXrhrdMml34AkHTvA13ulgxjBDipHQ5P5_VgwZDsrmSU9P4zkyRj
 3q_5jYxT2I.N5H7ni4v2VGN2ILh5HCAVDnvvgc.Ph138_A4_L6FJJlSl5NOXgsp_Hwio2KS0RZb6
 1OfFLb240cGdhTKwMmsnxZASKGtVGBPcGh50rP50H4sG9ENbaWE8XUuDKnB3B7SjMF.u1j6FkiBM
 cyJFUrHGDkvxndzS7PwUZSj4RznZtBEAv6Qe2F4_l81SSQVM2OMg7ZPZytt8mQTY4EfDB246mczE
 Aez4QTHdoHDZp6aagdWWUqwJu1lCcJ46cg1I8nBs.hq6ncJlFsSxhfjIMppoOeQeGlAAPHLKgtmG
 JF5NW0uRcA7isFWwYu.CZLWP8U1RoMfd7nMHVqnpxeD48U6GiNNbsD9Cc0tQFbdV7M95.5AIU._x
 jE8nwNV9hzuzXI3S1z2krbsu5Qw7oCLEywMawtjzR8X2qVZ3gduMMcOH6HH7nd.cc8gbv7d09fcT
 t3vogENnwzCg5bzvSFGLsU.hKpKxJ1SyBongJe5m1igB3G08VJH1qDIBsdr7QyEHwB7DpMopW8lz
 8WzgFWafWFZ.vAz40GPFSJbzKD7lIxcPWtxr3.uH4PeioMGcVW_yjm5JQLVWgqYcurhqjZkunqsx
 RuqjNR14GvlywGmLJSGQ.bCxAZizwXC0Gr9kdtWsfBYVy_g5utPCADSDxHhrGrJzf7f_MhvUYlRk
 Ekne.9Uvuy8BpD2u.bsAteHu9TWjpv3h8yPZnWSf_Km3vYR2g9HQozMwN.lUkZZI1AHBOmRdHFGX
 ZRM215Qq.trV_YahHsioEPOntesIqFvqtN97DG2URYopLrGNPzJYXLWOwSQMqtNxJ8ETFFcpdhSC
 iRe_D1H6y4F728w5Mr1IhcPPw.TGMdqCCZZK3TMcLUQ5yd9pfYD.8g.vzl6JKhk_zcW5Nd0I.J9Z
 Z6al0o6QoyOaN78wOEsw5NhSfJS8kTs1AS5T6KM5HuGc6RsogXpNrNI0JupUEJ7HhfdhoyZi1W_p
 FCZY-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 07:05:31 +0000
Received: by hermes--production-ne1-6bcfb7fb87-5nqxg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b8b2113d8c56534af310daaa2c04471;
          Tue, 08 Nov 2022 07:05:28 +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.200.110.1.12\))
Subject: Re: adding swap when expanding root filesystem
From: Mark Millard 
In-Reply-To: <20221108043817.GA55121@www.zefox.net>
Date: Mon, 7 Nov 2022 23:05:16 -0800
Cc: Mike Karels ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
 <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com>
 <20221108043817.GA55121@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N5zdV1ShWz3N6N
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]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 7, 2022, at 20:38, bob prohaska  wrote:

> On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
>> On Nov 7, 2022, at 12:51, bob prohaska  wrote:
>>=20
>>> . . .
>=20
>> Also the amount of space
>> U-Boot and the like takes varies. The Rock64 images
>> use a 16 MiByte space for its U-Boot and the like,
>> which are stored outside any file system.=20
>=20
> I'm not sure how anything can be stored "outside any
> filesystem". Might it be better to say "in a private filesystem",
> as in not known to the running kernel?

Here are the instructions for putting U-Boot (and such)
on a Rick64:

# more /usr/local/share/u-boot/u-boot-rock64/README=20
U-Boot loader and related files for the Pine64 Rock64.

To install this bootloader on an sdcard just do:
dd if=3D/usr/local/share/u-boot/u-boot-rock64/idbloader.img =
of=3D/path/to/sdcarddevice seek=3D64 bs=3D512 conv=3Dsync
dd if=3D/usr/local/share/u-boot/u-boot-rock64/u-boot.itb =
of=3D/path/to/sdcarddevice seek=3D16384 bs=3D512 conv=3Dsync

idbloader.img and u-boot.itb are not file systems.
They are found by the exact position that they must
be put at, thus the seek=3D and bs=3D usage in the dd
commands above.

# file /usr/local/share/u-boot/u-boot-rock64/u-boot.itb
/usr/local/share/u-boot/u-boot-rock64/u-boot.itb: Device Tree Blob =
version 17, size=3D1184, boot CPU=3D0, string block size=3D131, DT =
structure block size=3D992

# file /usr/local/share/u-boot/u-boot-rock64/idbloader.img
/usr/local/share/u-boot/u-boot-rock64/idbloader.img: data

The content in those files are not representations of
file systems.

Here is what a gpart show -p indicates for an example
Rock64 media with idblooader and U-Boot on it via those
dd commands:

=3D>       63  244277185    da4  MBR  (116G)
         63      32705         - free -  (16M)
      32768     102312  da4s1  fat32lba  [active]  (50M)
     135080      28760         - free -  (14M)
     163840  241172480  da4s2  freebsd  (115G)
  241336320    2940928         - free -  (1.4G)

=3D>        0  241172480   da4s2  BSD  (115G)
          0  230686720  da4s2a  freebsd-ufs  (110G)
  230686720   10485760          - free -  (5.0G)

Note the:

         63      32705         - free -  (16M)

The 2 dd commands above put the content of idbloader.img
and of u-boot.itb into the so-called "free" space
indicated, at very particular positions.

> Is there any basic problem with automatically establishing a=20
> swap partition during a microSD card setup?  A trio of self-
> hosted armv7 Pi2's with swap on microSD have been running=20
> happily for over two years as name, mail and webservers on=20
> 64 GB cards. Admittely, aarch64 is a lot more swap-intensive,=20
> but a Pi3 ran for about a year on a 128 GB card before things=20
> started going wrong. That Pi3 was running buildworld
> most of the time.

Are you asking for someone to give such support
to each of the following contexts (ignoring
u-boot-master and u-boot-tools and the like
that also show up in the list)?

# ls -dC1 /usr/ports/sysutils/u-boot-*
/usr/ports/sysutils/u-boot-a13-olinuxino
/usr/ports/sysutils/u-boot-a64-olinuxino
/usr/ports/sysutils/u-boot-bananapi
/usr/ports/sysutils/u-boot-bananapim2
/usr/ports/sysutils/u-boot-beaglebone
/usr/ports/sysutils/u-boot-chip
/usr/ports/sysutils/u-boot-clearfog
/usr/ports/sysutils/u-boot-cubieboard
/usr/ports/sysutils/u-boot-cubieboard2
/usr/ports/sysutils/u-boot-cubox-hummingboard
/usr/ports/sysutils/u-boot-firefly-rk3399
/usr/ports/sysutils/u-boot-imx-serial-loader
/usr/ports/sysutils/u-boot-master
/usr/ports/sysutils/u-boot-nanopi-a64
/usr/ports/sysutils/u-boot-nanopi-m1plus
/usr/ports/sysutils/u-boot-nanopi-neo
/usr/ports/sysutils/u-boot-nanopi-neo-air
/usr/ports/sysutils/u-boot-nanopi-neo2
/usr/ports/sysutils/u-boot-nanopi-r4s
/usr/ports/sysutils/u-boot-olimex-a20-som-evb
/usr/ports/sysutils/u-boot-olinuxino-lime
/usr/ports/sysutils/u-boot-olinuxino-lime2
/usr/ports/sysutils/u-boot-olinuxino-lime2-emmc
/usr/ports/sysutils/u-boot-orangepi-one
/usr/ports/sysutils/u-boot-orangepi-pc
/usr/ports/sysutils/u-boot-orangepi-pc-plus
/usr/ports/sysutils/u-boot-orangepi-pc2
/usr/ports/sysutils/u-boot-orangepi-plus-2e
/usr/ports/sysutils/u-boot-orangepi-r1
/usr/ports/sysutils/u-boot-orangepi-zero
/usr/ports/sysutils/u-boot-orangepi-zero-plus
/usr/ports/sysutils/u-boot-pandaboard
/usr/ports/sysutils/u-boot-pcduino3
/usr/ports/sysutils/u-boot-pine-h64
/usr/ports/sysutils/u-boot-pine64
/usr/ports/sysutils/u-boot-pine64-lts
/usr/ports/sysutils/u-boot-pinebook
/usr/ports/sysutils/u-boot-pinebookpro
/usr/ports/sysutils/u-boot-qemu-arm
/usr/ports/sysutils/u-boot-qemu-arm64
/usr/ports/sysutils/u-boot-qemu-riscv64
/usr/ports/sysutils/u-boot-riotboard
/usr/ports/sysutils/u-boot-rock-pi-4
/usr/ports/sysutils/u-boot-rock64
/usr/ports/sysutils/u-boot-rockpro64
/usr/ports/sysutils/u-boot-rpi
/usr/ports/sysutils/u-boot-rpi-0-w
/usr/ports/sysutils/u-boot-rpi-arm64
/usr/ports/sysutils/u-boot-rpi2
/usr/ports/sysutils/u-boot-rpi3
/usr/ports/sysutils/u-boot-rpi3-32
/usr/ports/sysutils/u-boot-rpi4
/usr/ports/sysutils/u-boot-sifive-fu540
/usr/ports/sysutils/u-boot-sifive-fu740
/usr/ports/sysutils/u-boot-sinovoip-bpi-m3
/usr/ports/sysutils/u-boot-sopine
/usr/ports/sysutils/u-boot-sopine-spi
/usr/ports/sysutils/u-boot-tools
/usr/ports/sysutils/u-boot-utilite
/usr/ports/sysutils/u-boot-wandboard

Just all those that happen to have snapshots made these
days?:

13.1+ and 14.0:
armv6 RPI-B
armv7 GENERICSD
aarch64 GENERIC
aarch64 RPI
aarch64 PINE64
aarch64 PINE64-LTS
aarch64 PINEBOOK
aarch64 ROCK64
aarch64 ROCKPRO64
riscv64 GENERIC
riscv64 GENERICSD

12.4 (in process) :
armv6 RPI-B
armv7 BANANAPI
armv7 CUBIEBOARD
armv7 CUBIEBOARD2
armv7 CUBOX-HUMMINGBOARD
armv7 RPI2
armv7 WANDBOARD
armv7 GENERICSD
aarch64 GENERIC
aarch64 PINE64
aarch64 PINE64-LTS

A subset of those?

What fraction of what size user base actually does large
port builds and buildworld buildkernel or the like on
each of these [or otherwise needs swap space in order to
have enough memory space (not just RAM)]. If the
volunteer(s) that provide this context have no interest
in doing such activities on such hardware, how likely is
it that they are going to provide the more involved setup?

> . . .
>=20
> Configuring swap manually on a RPi microSD system is a very
> considerable amount of work.

That might contribute to what the volunteer(s) choose to do
or not do.

> Having it happen by default=20
> wastes at most a few percent of the card capacity.

Presuming large enough capacities. 3.5 GiBytes would be
more than 10% of 32 GiBytes, for example. What is the
distribution of media sizes for folks that do not do
large port builds or buildworld buildkernel on such
systems --but do use such systems in some way? What
fraction of the overall use of such systems is that
set of folks?

> At this
> point I can't see any reason to say it's a bad idea and
> have some personal experience to suggest it's a good idea.

Getting someone else to be interested in doing what
you would find useful can be a challenge. Nothing
about that requires that the idea be a bad idea.
There are far too many good ideas for various context(s)
to implement them all for all the spanned contexts.

> [bsdinstall limitations snipped]
>=20
> It might be worth mentioning the /boot/loader.conf and=20
> /etc/sysctl.conf additions you've mentioned in other threads,
> as adjuncts to having autoconfigured swap on microSD. They've
> all been helpful in my experiments on RPi2 and RPi3. I think
> they'd be constructive additions to the RPi images and perhaps
> others..=20
>=20

Mostly, these things go back to what we learned from markj
primarily (vm.pageout_oom_seq) and kib primarily
(vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming
that I remember which-for-what accurately. Using
vm.swap_enabled and vm.swap_idle_enabled to avoid a form
of losing communication with the system(s) when they are
using the swap/paging space is more recent.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Nov  8 07:15:48 2022
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 4N5zsM4pTPz4gd1X
	for ; Tue,  8 Nov 2022 07:15:51 +0000 (UTC)
	(envelope-from gbe@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 4N5zsM42Mwz3PPV;
	Tue,  8 Nov 2022 07:15:51 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667891751;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=Or51i8cs02hJr0iZUhoJW0+EdAXo1l2qDL0IjYkUm7Y=;
	b=pRRgz+24P6TScfM8qRl7rnfrIOZLieq3fFdtAu6GcNOTnvvbvWojwbAP23EgDX7VY8p3w8
	UjN4aa1b2ew+kJf7ts0dAXBOvsQnFTGzXOiM7Z1wts1qfLbtaIFsc4kUyQ8uJPHe8vdIXP
	6zNseuTznK5JSQ4sSTX0hNggQwmt0KnazvpnL59w8is73onDOeizUlqyWEUu/MdC4g61rK
	oJTlBX1NzA3acaIeWXHgwV2Tet2Dp7p7A+zswT00S6H10x+78/cSNTqO8m7le6zhe9F3xU
	MB+jeHo3PIyOgzph4i5DSXrtcfJXozuVEXNB6wHdermJf9J/gJTskJ0jX/PaiA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667891751; a=rsa-sha256; cv=none;
	b=fs0BoJwg7BDSvFSCo8oAdkgzGQ4Tw3eCMxLHdOswU0Lht5bFeqi6bUXhgiBirE+OveZ/YG
	AdbWDeus1fYmYaMv9nof/zbLlQGXs4iG00CX8zhWuGNFz7yY/up3R3f6uNpYQY6emNcEi0
	vpyvU597TlY1m19LpCwzDPRhpvJbmlmsEGGzf+PFz7OJHBkA/iqtQpMA7fsl3WDgyzp8H1
	XeNPXHNxXp9Ao6GoK/4r6qGhix51cc6FizR84VRM627hI67Sr2DRjrWj++Jbmf6bKHcni/
	yePdkxe/tHE4D/qw/D0JkEEcvWS1j/rXfy8LgXPXV1jEZOLOW4Ha0vLjeaz5oA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667891751;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=Or51i8cs02hJr0iZUhoJW0+EdAXo1l2qDL0IjYkUm7Y=;
	b=JpSrnlhAS4wGhYe1khqnhVJF+oDIPKZZLrKRJUdmov76KLzZWE29xcXvgnFOJGVjo1bwoh
	Tl6aMgXExTG+HgoOe+qDIKQNT4gp52LdzK6HPSfYoL9ncv+LpBpiGkDm/Ds8wUJELBfCZW
	yjHih72NlVB8fM3bD4UIAlYMCKN+L7/Si8qNTLHWAORtXF8+IhGKW1hdvIPnEjcQ1nPbL+
	d9rrb9V90DYGYMSzrJtG0562QyyBLBO1eW7q9XAcp+3Pw1iwzJpS4cvt1N9sSt/2osEC9h
	Tqceao+00i+gyiTHe+yL3f2vWI/69pwHAGmpW90yw6VUN+eXVBAq9RBye0pWXw==
Received: from localhost (p200300cb870da5a0f04891b19e02c4c8.dip0.t-ipconnect.de [IPv6:2003:cb:870d:a5a0:f048:91b1:9e02:c4c8])
	(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 did not present a certificate)
	(Authenticated sender: gbe)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N5zsL74lLznrj;
	Tue,  8 Nov 2022 07:15:50 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
Date: Tue, 8 Nov 2022 08:15:48 +0100
From: Gordon Bergling 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org, jmg@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: 
References: <202211071610.2A7GAcHl090048@mail.karels.net>
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/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="aelShEj1XRrBDTia"
Content-Disposition: inline
In-Reply-To: <202211071610.2A7GAcHl090048@mail.karels.net>
X-Url: 
X-Operating-System: FreeBSD 13.1-STABLE amd64
X-Host-Uptime: 8:08AM  up 3 days, 15:34, 3 users, load averages: 0.44, 0.30,
 0.24
X-ThisMailContainsUnwantedMimeParts: N


--aelShEj1XRrBDTia
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Mike,

On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> This question is not really arm-specific, but I couldn't think of a better
> mailing list for it.
>=20
> There are peridic issues reported on small systems like Raspberry Pi
> where people are running buildworld or poudriere and running out of
> memory.  As the user gets no control over the disk layout when installing,
> there is no option to add swap space on the install image.  I have added
> swap space on a USB disk, but this is often not an option.  It occurred
> to me that it might be reasonable to add swap space before expanding
> the root filesystem if there is sufficient space.  I have a prototype,
> and wondered if this is a good thing to do.  Granted, this will often
> create swap on microSD, which is not optimal, but probably better than
> nothing.
>=20
> The current prototype creates a swap partition which is 1/10 of the disk
> if the disk is at least 15 GB and the initial root partition is no more
> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> probably enable this by default, but provide a way to disable it via a
> kenv variable and/or a variable in /etc/rc.conf.
>=20
> Thoughts?
>=20
> 		Mike

That would be very welcomed addition. I personally ofter run into problems
when I try get a crash dump from my RPi4, since no dumpdev can be set
without a separate swap partion. An USB stick worked for I while, but it
just went dead at some point.

And the genet(4) driver doesn't support netdump(4).

--Gordon

--aelShEj1XRrBDTia
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmNqAiJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx
QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP
09ztxggAnCQ2fqydmfBO9VsiTHYNh4tSlJpK8LNL7sMh+mdhFakjZPQtlmt8+Nnc
xEqQpJ2xA/ceJtS5ROLRX/7VOVhUGBys0EjkyKnff+NgCCiK1pUMV37BzfMy6MiV
8eycQuCPfl2kOnXCCC9NUUvQawgM5lPwEyqInrXUQMjOsO/GDo/5yJ3xRioDLPE6
yIhgL1OjYxDuhXu2926gRUQ31FdRnj1GC3RYXc70xWhuesmb5ZwnqPcxjfeeZwpc
vhWBwK0lw4MJgRPa+tAKcctWuSMIXGLxT6OEBcT6MvwrF+ga9em+amKP7JlCJa9f
TUAquQuWw3AX9MEXL+jb4Jv54DKAwA==
=frm+
-----END PGP SIGNATURE-----

--aelShEj1XRrBDTia--

From nobody Tue Nov  8 09:28:00 2022
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 4N62pN5VxHz4hCCb
	for ; Tue,  8 Nov 2022 09:28:28 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a])
	(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 4N62pN0QFdz4D9Q;
	Tue,  8 Nov 2022 09:28:28 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=GxCiV3A4;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-yb1-xb2a.google.com with SMTP id 131so12297919ybl.3;
        Tue, 08 Nov 2022 01:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=cwmtjd/D01Ql/7h4FF9rK557odyry5foUwGNBlgK0ko=;
        b=GxCiV3A41Qpqdx+lDt1n9+tRIPrgwmaDaFQwaJySrkMo28qe4MfnDLAylQKLxL19Pb
         L553ALot8jw83rjPT9tEyi4RcXMmf5AqZLjJ49LaPauRIx+tBDC628sltaI6ezX7nX92
         O/nIqWBrziZF7V7YcZwzKn4NppcUMMVbI1ilP9q6N6esZnDhxrjw8Yc6oJ09vUTV2Spn
         LlPw139gaMscx1/ROVVFAWtNXJrjWCc4zb6Xc5Ml4ViiAk3WNbYpAcbNw+ddigwtm7ec
         kLVLqNYAG6MrN/SZjy6cVORJwtQm2xgTudS1Gghuvc9tuQR+xAB3AHEvzN0g9ImXsnVq
         Co4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=cwmtjd/D01Ql/7h4FF9rK557odyry5foUwGNBlgK0ko=;
        b=Do90T+hJnUSXHj3l4RojPsi3pTyl6ZCGVnCVH6PYcksNhFoyGCI1L1thBN57fcyCzn
         SKD/uGW5hpCgtTRb7xqD4+dckzyKzZICFE2WR8+25lUQCUgLVDKH3jKHRh5ewspQR6xL
         uoV4emvHoPflnVAK7/3Q0/dzrM4IN7cpydrvA3RUZkcKtu9rQgjp+8zmVudfWBRPAK20
         Oz34f9vID0gFpbmbb3GESFc8vjB0+eNgTRjrkq3jK9EIASjVSPBWlfmCVZ9alPhGMZCL
         Bq7Fs+ow4Dbd2qca2ietEpadSXMCdoAqf6UAb3toiTVO8G2PDZPL6ZNjDmSBh35y+f0B
         z+1g==
X-Gm-Message-State: ACrzQf3r7wtrzYwfHW1KuxNFzozaJzdL4JGdvU0tZzfenmNKXH6GicyN
	G2tFP+9p+UpmPJWcu3UmOglKypROROt/41oQqFqMib0i
X-Google-Smtp-Source: AMsMyM5S+5/1f3Y88gllD3PV9zZe+w2w/wG/ncoZj00OdNjPamxWsgQcrxiUyIkvjn+MT174zmI1+5AWVNY7SSHAiQ0=
X-Received: by 2002:a25:fb07:0:b0:6d1:a9c:3580 with SMTP id
 j7-20020a25fb07000000b006d10a9c3580mr28742076ybe.191.1667899706535; Tue, 08
 Nov 2022 01:28:26 -0800 (PST)
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: <202211071610.2A7GAcHl090048@mail.karels.net>
In-Reply-To: <202211071610.2A7GAcHl090048@mail.karels.net>
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 17:28:00 +0800
Message-ID: 
Subject: Re: adding swap when expanding root filesystem
To: mike@karels.net
Cc: freebsd-arm@freebsd.org, jmg@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000087735b05ecf229a8"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.93 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	NEURAL_HAM_MEDIUM(-0.95)[-0.947];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2a:from];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TAGGED_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4N62pN0QFdz4D9Q
X-ThisMailContainsUnwantedMimeParts: N

--00000000000087735b05ecf229a8
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 12:10 AM Mike Karels  wrote:

> This question is not really arm-specific, but I couldn't think of a better
> mailing list for it.
>
> There are peridic issues reported on small systems like Raspberry Pi
> where people are running buildworld or poudriere and running out of
> memory.  As the user gets no control over the disk layout when installing,
> there is no option to add swap space on the install image.  I have added
> swap space on a USB disk, but this is often not an option.  It occurred
> to me that it might be reasonable to add swap space before expanding
> the root filesystem if there is sufficient space.  I have a prototype,
> and wondered if this is a good thing to do.  Granted, this will often
> create swap on microSD, which is not optimal, but probably better than
> nothing.
>
> The current prototype creates a swap partition which is 1/10 of the disk
> if the disk is at least 15 GB and the initial root partition is no more
> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> probably enable this by default, but provide a way to disable it via a
> kenv variable and/or a variable in /etc/rc.conf.
>
> Thoughts?
>
>                 Mike
>

Hi Mike,

That's a pleasant to have as my current scenario belongs to this concern
using RPi 3B/4B as build machines.

Thanks and best regards,
Archimedes

--00000000000087735b05ecf229a8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 8, 2022 at 12:10 AM Mike =
Karels <mike@karels.net> wrote=
:
This question =
is not really arm-specific, but I couldn't think of a better

mailing list for it.



There are peridic issues reported on small systems like Raspberry Pi

where people are running buildworld or poudriere and running out of

memory.=C2=A0 As the user gets no control over the disk layout when install=
ing,

there is no option to add swap space on the install image.=C2=A0 I have add=
ed

swap space on a USB disk, but this is often not an option.=C2=A0 It occurre=
d

to me that it might be reasonable to add swap space before expanding

the root filesystem if there is sufficient space.=C2=A0 I have a prototype,=


and wondered if this is a good thing to do.=C2=A0 Granted, this will often<=
br>
create swap on microSD, which is not optimal, but probably better than

nothing.



The current prototype creates a swap partition which is 1/10 of the disk
if the disk is at least 15 GB and the initial root partition is no more

than 1/3 of the disk, but only up to 1.5x of physical memory.=C2=A0 I would=


probably enable this by default, but provide a way to disable it via a

kenv variable and/or a variable in /etc/rc.conf.



Thoughts?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike

Hi Mike,

That's a pleasa=
nt to have as my current scenario belongs to this concern using RPi 3B/4B a=
s build machines.

Thanks and best regards,
Archimedes 


--00000000000087735b05ecf229a8--

From nobody Tue Nov  8 09:53:59 2022
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 4N63N02QnLz4hJQk
	for ; Tue,  8 Nov 2022 09:54:08 +0000 (UTC)
	(envelope-from rb@gid.co.uk)
Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N63Mz2Vfnz437k
	for ; Tue,  8 Nov 2022 09:54:07 +0000 (UTC)
	(envelope-from rb@gid.co.uk)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk;
	dmarc=none
Received: from smtpclient.apple (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged))
	by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2A89rxAr006972;
	Tue, 8 Nov 2022 09:53:59 GMT
	(envelope-from rb@gid.co.uk)
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 \(3696.120.41.1.1\))
Subject: Re: adding swap when expanding root filesystem
From: Bob Bishop 
In-Reply-To: <20221107205150.GA53784@www.zefox.net>
Date: Tue, 8 Nov 2022 09:53:59 +0000
Cc: Mike Karels ,
        "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <48FF9D6B-1214-4BF8-99B9-D8961EBBD938@gid.co.uk>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+mx];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	R_DKIM_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[gid.co.uk];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4N63Mz2Vfnz437k
X-ThisMailContainsUnwantedMimeParts: N



> On 7 Nov 2022, at 20:51, bob prohaska  wrote:
>=20
> [pruned severely] It might be wise to add a warning about flash =
wearing out,
> but it took a year of near-continuous buildworlds to kill
> a 128GB microSD holding -current on a Pi3 with ~3 GB swap.

All flash media are definitely not created equal, the warning is a very =
good idea IMHO.

--
Bob Bishop
rb@gid.co.uk





From nobody Tue Nov  8 11:56:10 2022
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 4N665152slz4V318
	for ; Tue,  8 Nov 2022 11:56:21 +0000 (UTC)
	(envelope-from SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4N66502270z4GXP;
	Tue,  8 Nov 2022 11:56:20 +0000 (UTC)
	(envelope-from SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=MfE3KsAZ;
	spf=pass (mx1.freebsd.org: domain of "SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl";
	dmarc=pass (policy=quarantine) header.from=klop.ws
Date: Tue, 8 Nov 2022 12:56:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1667908571;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=XFumg3LgVfbGNPgFhc1S/u6V6/DE6/+zrb3J0pppd7o=;
	b=MfE3KsAZPL6N8XSQUTeD98cwA4toGiQTstomEBZQ/Ca8QNvplu31miblngIH2ELpRefhS3
	tiP8DJYLV4lXQiwgPnbwLZu78FsC9mG9M6o72VFeu1ue5GATW1mqZ9krMdeZHQohfPcRmY
	KFJqrxfQ5s9kzroT//1zrqCD6772JI8QXalC1jCsP8G/xEeonskLDZ5yuXJq+wuXvrBrmA
	q6IUcABYwdxW9kwDvviJ8bMptFu7utSTSgBPmopQIElmYvnIUlbHg4jutYXZDv2mhA3yxr
	Q/jMDRvTbGXmYZgUwg008AdWUNBSWr4qzWbjTYeJM2cbR0DEpbp8WfKx8h9tWQ==
From: Ronald Klop 
To: mike@karels.net
Cc: jmg@freebsd.org, freebsd-arm@freebsd.org
Message-ID: <95847460.127804.1667908570062@localhost>
In-Reply-To: <202211071610.2A7GAcHl090048@mail.karels.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
Subject: Re: adding swap when expanding root filesystem
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="----=_Part_127803_560799664.1667908570055"
X-Mailer: Realworks (630.39)
Importance: Normal
X-Priority: 3 (Normal)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.03 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.83)[-0.832];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=V@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	TAGGED_FROM(0.00)[t4=3I=klop.ws=ronald-lists];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_NONE(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=V@realworks.nl]
X-Rspamd-Queue-Id: 4N66502270z4GXP
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_127803_560799664.1667908570055
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Mike Karels 
Datum: maandag, 7 november 2022 17:10
Aan: freebsd-arm@freebsd.org
CC: jmg@freebsd.org
Onderwerp: adding swap when expanding root filesystem
> 
> This question is not really arm-specific, but I couldn't think of a better
> mailing list for it.
> 
> There are peridic issues reported on small systems like Raspberry Pi
> where people are running buildworld or poudriere and running out of
> memory.  As the user gets no control over the disk layout when installing,
> there is no option to add swap space on the install image.  I have added
> swap space on a USB disk, but this is often not an option.  It occurred
> to me that it might be reasonable to add swap space before expanding
> the root filesystem if there is sufficient space.  I have a prototype,
> and wondered if this is a good thing to do.  Granted, this will often
> create swap on microSD, which is not optimal, but probably better than
> nothing.
> 
> The current prototype creates a swap partition which is 1/10 of the disk
> if the disk is at least 15 GB and the initial root partition is no more
> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> probably enable this by default, but provide a way to disable it via a
> kenv variable and/or a variable in /etc/rc.conf.
> 
> Thoughts?
> 
>         Mike
>  


Hi,

Would you mind sharing your prototype?

Regards,
Ronald.

 
------=_Part_127803_560799664.1667908570055
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Mike Karels <mike@karels.net>

Datum: maandag, 7 november 2022 17:10

Aan: freebsd-arm@freebsd.org

CC: jmg@freebsd.org

Onderwerp: adding swap when expanding root filesystem







This question is not really arm-specific, but I couldn't think of a better

mailing list for it.



There are peridic issues reported on small systems like Raspberry Pi

where people are running buildworld or poudriere and running out of

memory.  As the user gets no control over the disk layout when installing,

there is no option to add swap space on the install image.  I have added

swap space on a USB disk, but this is often not an option.  It occurred

to me that it might be reasonable to add swap space before expanding

the root filesystem if there is sufficient space.  I have a prototype,

and wondered if this is a good thing to do.  Granted, this will often

create swap on microSD, which is not optimal, but probably better than

nothing.



The current prototype creates a swap partition which is 1/10 of the disk

if the disk is at least 15 GB and the initial root partition is no more

than 1/3 of the disk, but only up to 1.5x of physical memory.  I would

probably enable this by default, but provide a way to disable it via a

kenv variable and/or a variable in /etc/rc.conf.



Thoughts?



        Mike

 









Hi,



Would you mind sharing your prototype?



Regards,

Ronald.



 
------=_Part_127803_560799664.1667908570055--

From nobody Tue Nov  8 17:26:51 2022
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 4N6FQX4mhnz4Ydhj
	for ; Tue,  8 Nov 2022 17:27:00 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N6FQX1Tdlz49QM;
	Tue,  8 Nov 2022 17:27:00 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2A8HQpOU001426;
	Tue, 8 Nov 2022 11:26:52 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id sD+nH1uRamOQBQAA4+wvSQ
	(envelope-from ); Tue, 08 Nov 2022 11:26:51 -0600
From: Mike Karels 
To: Ronald Klop 
Cc: jmg@freebsd.org, freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Date: Tue, 08 Nov 2022 11:26:51 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <7DAEBB8E-6B50-453F-B858-5354FA19DE47@karels.net>
In-Reply-To: <95847460.127804.1667908570062@localhost>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <95847460.127804.1667908570062@localhost>
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-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 2A8HQpOU001426
X-Rspamd-Queue-Id: 4N6FQX1Tdlz49QM
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:209, ipnet:216.160.36.0/22, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On 8 Nov 2022, at 5:56, Ronald Klop wrote:

> Van: Mike Karels 
> Datum: maandag, 7 november 2022 17:10
> Aan: freebsd-arm@freebsd.org
> CC: jmg@freebsd.org
> Onderwerp: adding swap when expanding root filesystem
>>
>> This question is not really arm-specific, but I couldn't think of a be=
tter
>> mailing list for it.
>>
>> There are peridic issues reported on small systems like Raspberry Pi
>> where people are running buildworld or poudriere and running out of
>> memory.  As the user gets no control over the disk layout when install=
ing,
>> there is no option to add swap space on the install image.  I have add=
ed
>> swap space on a USB disk, but this is often not an option.  It occurre=
d
>> to me that it might be reasonable to add swap space before expanding
>> the root filesystem if there is sufficient space.  I have a prototype,
>> and wondered if this is a good thing to do.  Granted, this will often
>> create swap on microSD, which is not optimal, but probably better than
>> nothing.
>>
>> The current prototype creates a swap partition which is 1/10 of the di=
sk
>> if the disk is at least 15 GB and the initial root partition is no mor=
e
>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
>> probably enable this by default, but provide a way to disable it via a
>> kenv variable and/or a variable in /etc/rc.conf.
>>
>> Thoughts?
>>
>>         Mike
>>
>
>
> Hi,
>
> Would you mind sharing your prototype?

I=E2=80=99ll send you a pointer.  If anyone else wants to check it out, l=
et
me know.  It is full of debug prints still, and missing some required
changes.  It is somewhat tested with MBR, not with GPT.  If anyone
has a setup to test with GPT, I=E2=80=99d be grateful.  I haven=E2=80=99t=
 tested
with ZFS either, although that part shouldn=E2=80=99t require changes.

Responding to some earlier comments:

- The current limit on swap partition size is 1.5x physmem, as mentioned.
I am considering raising it, but I don=E2=80=99t think I want to go beyon=
d 2x.

- I am considering whether to allow the size to be overridden from kenv
and maybe /etc/rc.conf, including a value to disable.  Right now it is
possible to disable via kenv (untested).

- I agree that not everyone needs swap space; that=E2=80=99s true of =E2=80=
=9Cnormal=E2=80=9D
installs too, which pick a default but allow override with manual
partitioning.  My hope is that it=E2=80=99s a small enough amount that th=
e
default size isn=E2=80=99t too large a drop in root capacity.

		Mike

> Regards,
> Ronald.

From nobody Tue Nov  8 17:41:26 2022
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 4N6Fl95v4vz4V0CS
	for ; Tue,  8 Nov 2022 17:41:25 +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 4N6Fl92HrLz4DXW
	for ; Tue,  8 Nov 2022 17:41:25 +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.16.1/8.15.2) with ESMTPS id 2A8HfR5H060758
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 8 Nov 2022 09:41:27 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2A8HfREe060757;
	Tue, 8 Nov 2022 09:41:27 -0800 (PST)
	(envelope-from fbsd)
Date: Tue, 8 Nov 2022 09:41:26 -0800
From: bob prohaska 
To: Mark Millard 
Cc: Mike Karels , freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221108174126.GA60338@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
 <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com>
 <20221108043817.GA55121@www.zefox.net>
 <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@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: <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com>
X-Rspamd-Queue-Id: 4N6Fl92HrLz4DXW
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]
X-ThisMailContainsUnwantedMimeParts: N

[much snippage ensues, hope I've preserved enough context]

On Mon, Nov 07, 2022 at 11:05:16PM -0800, Mark Millard wrote:
> On Nov 7, 2022, at 20:38, bob prohaska  wrote:
> 
> > On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
> >> On Nov 7, 2022, at 12:51, bob prohaska  wrote:
> >> 
> >>> . . .
> > 
> >> Also the amount of space
> >> U-Boot and the like takes varies. The Rock64 images
> >> use a 16 MiByte space for its U-Boot and the like,
> >> which are stored outside any file system. 
> > 
> > I'm not sure how anything can be stored "outside any
> > filesystem". Might it be better to say "in a private filesystem",
> > as in not known to the running kernel?
>
 
> 
> The 2 dd commands above put the content of idbloader.img
> and of u-boot.itb into the so-called "free" space
> indicated, at very particular positions.
> 

If there's no guide to what's free vs in-use, there's no filesystem?
I see your point, but then the msdos partition is a filesystem. Thus,
at least on a Pi, nothing is outside the filesystem. The Rock64 case
resembles the boot blocks of a DOS boot disk. Am I reading right?
 
> > Is there any basic problem with automatically establishing a 
> > swap partition during a microSD card setup?  A trio of self-
> > hosted armv7 Pi2's with swap on microSD have been running 
> > happily for over two years as name, mail and webservers on 
> > 64 GB cards. Admittely, aarch64 is a lot more swap-intensive, 
> > but a Pi3 ran for about a year on a 128 GB card before things 
> > started going wrong. That Pi3 was running buildworld
> > most of the time.
> 
> Are you asking for someone to give such support
> to each of the following contexts (ignoring
> u-boot-master and u-boot-tools and the like
> that also show up in the list)?
> 
I'm a bit confused here, as the connection between 
u-boot and swap availability isn't obvious to me.

> # ls -dC1 /usr/ports/sysutils/u-boot-*
> /usr/ports/sysutils/u-boot-a13-olinuxino
> /usr/ports/sysutils/u-boot-a64-olinuxino
> /usr/ports/sysutils/u-boot-bananapi
> /usr/ports/sysutils/u-boot-bananapim2
> /usr/ports/sysutils/u-boot-beaglebone
[many more examples snipped]
> 
> What fraction of what size user base actually does large
> port builds and buildworld buildkernel or the like on
> each of these [or otherwise needs swap space in order to
> have enough memory space (not just RAM)]. If the
> volunteer(s) that provide this context have no interest
> in doing such activities on such hardware, how likely is
> it that they are going to provide the more involved setup?
> 

I simply don't know. Those with a loftier viewpoint probably do.
Projects like FreeBSD have to pick and choose what they support
and not all platforms are equal. I suppose one would seek to 
balance benefits, burdens and breakage. For something like
Raspberry Pi the benefits are obvious, breakage looks small.
Burden on the project is un-gaugeable by me. As one of the
cheapest SBCs the potential user base looks large, perhaps
the largest among the many competitors.

> > 
> > Configuring swap manually on a RPi microSD system is a very
> > considerable amount of work.
> 
> That might contribute to what the volunteer(s) choose to do
> or not do.

Perhaps that is what motivated the automatic swap creation idea.

> 
> > Having it happen by default 
> > wastes at most a few percent of the card capacity.
> 
> Presuming large enough capacities. 3.5 GiBytes would be
> more than 10% of 32 GiBytes, for example. What is the
> distribution of media sizes for folks that do not do
> large port builds or buildworld buildkernel on such
> systems --but do use such systems in some way? What
> fraction of the overall use of such systems is that
> set of folks?
>

The original proposal set a minimum amount of free space
on the card before attempting swap creation. That would 
seem to solve the problem, unless I'm missing something.  
As a practical matter 32GB is a small card, 128 readily
available and cheap, 1TB expensive and available. 

> > At this
> > point I can't see any reason to say it's a bad idea and
> > have some personal experience to suggest it's a good idea.
> 
> Getting someone else to be interested in doing what
> you would find useful can be a challenge. Nothing
> about that requires that the idea be a bad idea.

Did you mean "good idea"? If so I agree. "Good ideas"
for one are mere distractions for most.

> There are far too many good ideas for various context(s)
> to implement them all for all the spanned contexts.

Very true. That's why I suggest looking at benefits, breakage
and burden of support. Knowing that balance one can decide
if the user base is big enough to warrant adoption.  

> 
> > [bsdinstall limitations snipped]
> > 
> > It might be worth mentioning the /boot/loader.conf and 
> > /etc/sysctl.conf additions you've mentioned in other threads,
> > as adjuncts to having autoconfigured swap on microSD. They've
> > all been helpful in my experiments on RPi2 and RPi3. I think
> > they'd be constructive additions to the RPi images and perhaps
> > others.. 
> > 
> 
> Mostly, these things go back to what we learned from markj
> primarily (vm.pageout_oom_seq) and kib primarily
> (vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming
> that I remember which-for-what accurately. Using
> vm.swap_enabled and vm.swap_idle_enabled to avoid a form
> of losing communication with the system(s) when they are
> using the swap/paging space is more recent.
> 

I didn't catch on until you made the importance explcit. 
All apply to the constrained-memory situations in which 
automatic swap creation is likely to be important. It
might make sense to bundle the settings if practical.

Thanks for reading, and your insights!

bob prohaska


From nobody Tue Nov  8 19:06:37 2022
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 4N6Hdn3W8Dz4XFNL
	for ; Tue,  8 Nov 2022 19:06:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4N6Hdn0flKz4SsN
	for ; Tue,  8 Nov 2022 19:06: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=1667934410; bh=GedSb2NsewjZsjImkgZvrrH9W2d1hlA5UrXr3G1ve6s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZdxZPYVRmfkZuTWOZYG+BO4YtGfThrTircn3r71ZsqSKyrBv3fD/WZonMzfPIouEYWkcA4dSth+LUluknz5K3Idty+oqLiG5Z4XBAdizi2GLFY0XS9Yyse80gqmDKWY6Ma3WF9zOHj6R2b13HAVxXxUXVZo4mmxPcgkRN4q95iRbyoBQTA0ylrKQCXlRAfz5OaICsz6ubuVKCA7lemNXdTz1oVzgadaGIXqdQs9aRBILeUuTULXbdB0cj07cgxrmpCdMUPjnSIn1ApxHdvhkpw3JjwMMXwNWOWNJiHFyEjW2Rkb0rBUEYhk6ieXMuAcdI6FsxseGa69fRrhiPynCqQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667934410; bh=fL2aeqafHvUVZy07r1kZDMMfVLSxezjZUZEqgbd04Wl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uQ0KtHIHajH/WJYYBtTCee6Bc/rSf8ojQy+pFKtAwWOC6HL3aXq6/J0rX9vflybsIOebRHPxBbdPR3ik0kCehkpuNnHk3plqzjVtxCLe07uJN1OCQ57Yhh8eSFAapsSa8SBeBGKqp6VDUT4/4chrX840JpNFzwB9pGnEozDNmyHUYInoB2eHwfWKQ87nhPsG/iG2kVHWUqTfOfSkTRNX/3CcaMflHeZB+ykAJxptY4F4KudCh0Ve2Da6ZRDImxaWQkVm6RLVKbtSXiAEeRKanP8nB6v+jZtcggrYxcezG8zmHT2noY+ZiGUwoea4AYCGjZ2O79gs89Kofe2Ut8preA==
X-YMail-OSG: RdJ2yDYVM1k4tz6p6v4Gt6l_bZp0Gg9Lcw7FuAq7kSEAnabR34dQQUBy838D66O
 pzG6Y0JmGDcJ5xKE7HQCQESYBynJUVmEJDrWpBaFoFq0xTV5skerEFzzrV0nqNNGsSdv1g.aSWgL
 XWF3vILMGPmE7RYn7MJG9vEhXpmNG9FWNQWd_TkT7HVnMKOP3w8xTVe._KNa6w4RT2UQp8elHiPE
 h9j.sRhKjrSN7.Nd3eq2hs9zl4SfruS4CjwdbCKojG9yCoxL7brJZNQsqP78uA74STrlf9cjSABH
 M0WEaCD8jKje_Pet7mVcZWyCsv7zUIOhyUQyGfsDXqg8Y2k_sorBcc3LeHJlehCUpbRr_SbMQcXN
 mGqt0jX5WqCDn2KxHTn1Y8XWvZSG9iBpLWqRSHcJj0GAmFxSmWBpAqIdsCscPl1VNI2.vCQHrJ0X
 A4DnMSq4RrzWA.j_bI8SUfepaLYS7QZcaqv9RrSkh_XzMVGfbQV6OFvFPZZNUmgm88HpF3XsLjU7
 PInoCsaJMV6fE6oVJCWjOoJJGXA3lLTqy3WXEkuTfFYPko4aUmuk4dmwG.6De6ecD4Mp.k1jCfWI
 x6kT6aXImPjBrio2Or09pzP1HJvj5cad.o9KlVWR_tg3_1oVic917cdkbqjiZCHzlF.2eJ8aDVnl
 .MXkNdCVsp1npZLo9HiuwUktkp3cwBmg.7NaQ7ljMDAMdv4kut0QBhHwjOld_G4.2hsubwlcNOkO
 coHHYhWEnqqWL8yLZ.KzJYue.DxWgoFoQGGREPcsGfIQg1O7OdQ2Ln3VGyEmtdFQaDS26KkbKjDL
 qiAGDYL06meo6Ug7.CKtrkbhY7nAGpsOcGqqBuf4FB4wBOJ_g.mpzPCHGWOaTkRcoaU9dEJFt8uf
 qYAfQwHfgwRUWSIt4bEaj8oSORBs0nwVj4Q4cI5mSmriduExrRXdbcx4gCw5vMxsErGEye7djDAV
 cnILkzRb8aZjBzKfg_XU.Eb1N5AScW0fxmdFwvHt041T_zQ7ijbhaGNkuNnghMlIhkhN55dQePph
 aQl7tGVKiZ8MRVZnylazAOuNwwuN8Lwz.XVelpEHiCbXAFVC0An61msncF2xRzkqFfNUrdNGeNWB
 EfX0Vcb0rLt.w68yaCw9yIok8y.DFf1wR8IB1Idprj92NAbpL0HF.GPwKJNdk0q.3Swd6JjSIwz8
 wxju2YfnujQQ_.vQv9lPyztnZxzLDsiHPiQG_s2LTzFEPNx1dAwzy855YRl4v2IpookrWLyCmZOM
 RArcYg4IKz3fbv8jV6tYIN3B4jq9ITx7cO_bv9ePlsIIuHhiEEPGuvvAnerKVh9bhOyfQVRDsrXI
 WRScENSc9Qnap0woE5o.Wj3QiZoehnH0hvyhrsoMFu9_osMfMgf3UkhYlcWy1Z7RdC0z8zLAhXx.
 c6k3cgT.5l.GJWmB8.DnR8u1HZU5GHXZ7Iw4rzes6cIH0AAYeX1nxOoEQc4Z67bO8nrkznQumFc5
 AbN43bfo8vt7SJWyjXtfSLmW60CX.GJ59hcIexNKkbvh3497tlnsN1z18uLb8qvFixZGUkBjBKOS
 _RJwfwm4B2_9psmaW5SmdVM8k6dsi9IRPspXUeN5p_KoHLUnb0_UaEAw0UAZR4dIIXSio2g6Z1tF
 E2oUfeEmHWTTETQFjLzPGHpgvv.goohQbRpolZZJ_hUL04szvqeISrjk2GxkCnXffh2L2hlsdII4
 4TuyjzavOziKdJhy_MqGOBLjQa2Q0_ocbK0kfPVHlythVRJmJq5w9I.JejKsC7Ednojv8TZ.2_HO
 3oJPzcauxDBQNk1TwXL.0KWD5ss7ZmEKRSqBa0fWsEQP4GhqigGV0xENpg5lkwnISyKexP22YelR
 azo6wHbHvAJY487F7GMZFHOAHCBFPV8ydPRiv9Crsa1PavdGiKBQMD6QTnGZfCvGtIrhw.I5jMK3
 jkFALgHNWSxwiFZuQAj3naZYq002QVSa01Tj51aiN.xkyCWFYKm5N1Vy5uLyNGPrUyVAtUjZsxcD
 ctMVRTfd9N_JulGaaTR1evhHeuc6iJ0tgBYZ2O4HPVeILZhHmrgL642rJLMrsaSP2crr616Qnpke
 0iHur1sx.sHVBEUVmrvQ4XHJ9g3gdNrCgUKNH5CthBumFdUCuYT1JMaYX_2boyjBJUCamJ7dcn1w
 LPokckNsWPJmh6GbmPvX8eCjBnR2QpryhBFhxarnKSO_uuLc.40W7rzctVpbv8Mpwij3RgBsAaDr
 .tcpWOG1djZNRYwbbJEuUbGOT8t6Ko5HqSdkDFmRP.aYJf1HzzkPqZwEFEE.SSwf0NMlDnpb3WbX
 eX5FiXg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 19:06:50 +0000
Received: by hermes--production-gq1-579bc4bddd-6kwsn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5be59a664778f18de93b87b513e081f9;
          Tue, 08 Nov 2022 19:06:48 +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.200.110.1.12\))
Subject: Re: adding swap when expanding root filesystem
From: Mark Millard 
In-Reply-To: <20221108174126.GA60338@www.zefox.net>
Date: Tue, 8 Nov 2022 11:06:37 -0800
Cc: Mike Karels ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <981582E8-1CF3-46FE-B7CB-E3157205CE0A@yahoo.com>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
 <78C2FBC4-D2CE-44B0-9535-02C0EDECD10A@karels.net>
 <20221107205150.GA53784@www.zefox.net>
 <09E80B35-0325-44E6-8191-55DCC79A51F1@yahoo.com>
 <20221108043817.GA55121@www.zefox.net>
 <9BF0BEB8-6074-4607-BA1B-B3462C5CEA66@yahoo.com>
 <20221108174126.GA60338@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N6Hdn0flKz4SsN
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]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 8, 2022, at 09:41, bob prohaska  wrote:

> [much snippage ensues, hope I've preserved enough context]
> 
> On Mon, Nov 07, 2022 at 11:05:16PM -0800, Mark Millard wrote:
>> On Nov 7, 2022, at 20:38, bob prohaska  wrote:
>> 
>>> On Mon, Nov 07, 2022 at 04:07:08PM -0800, Mark Millard wrote:
>>>> On Nov 7, 2022, at 12:51, bob prohaska  wrote:
>>>> 
>>>>> . . .
>>> 
>>>> Also the amount of space
>>>> U-Boot and the like takes varies. The Rock64 images
>>>> use a 16 MiByte space for its U-Boot and the like,
>>>> which are stored outside any file system. 
>>> 
>>> I'm not sure how anything can be stored "outside any
>>> filesystem". Might it be better to say "in a private filesystem",
>>> as in not known to the running kernel?
>> 
> 
>> 
>> The 2 dd commands above put the content of idbloader.img
>> and of u-boot.itb into the so-called "free" space
>> indicated, at very particular positions.
>> 
> 
> If there's no guide to what's free vs in-use, there's no filesystem?
> I see your point, but then the msdos partition is a filesystem. Thus,
> at least on a Pi, nothing is outside the filesystem. The Rock64 case
> resembles the boot blocks of a DOS boot disk. Am I reading right?

The older RPi*'s are unusual in being just file system based.
(RPi4B's and the like have the EEPROM updatable as well but
are otherwise just file system based.)

DOS boot blocks were more standardized, if I understand right.

>>> Is there any basic problem with automatically establishing a 
>>> swap partition during a microSD card setup?  A trio of self-
>>> hosted armv7 Pi2's with swap on microSD have been running 
>>> happily for over two years as name, mail and webservers on 
>>> 64 GB cards. Admittely, aarch64 is a lot more swap-intensive, 
>>> but a Pi3 ran for about a year on a 128 GB card before things 
>>> started going wrong. That Pi3 was running buildworld
>>> most of the time.
>> 
>> Are you asking for someone to give such support
>> to each of the following contexts (ignoring
>> u-boot-master and u-boot-tools and the like
>> that also show up in the list)?
>> 
> I'm a bit confused here, as the connection between 
> u-boot and swap availability isn't obvious to me.

Are you after media that boots without being adjusted?
That would make the U-Boot issues (and more) part of
the overall activity of making media images available
for whatever range of devices you are after. One image
does not cover all those cases, possibly even if
U-Boot or such has to be manually added (presuming some
support of GPT anyway).

>> # ls -dC1 /usr/ports/sysutils/u-boot-*
>> /usr/ports/sysutils/u-boot-a13-olinuxino
>> /usr/ports/sysutils/u-boot-a64-olinuxino
>> /usr/ports/sysutils/u-boot-bananapi
>> /usr/ports/sysutils/u-boot-bananapim2
>> /usr/ports/sysutils/u-boot-beaglebone
> [many more examples snipped]
>> 
>> What fraction of what size user base actually does large
>> port builds and buildworld buildkernel or the like on
>> each of these [or otherwise needs swap space in order to
>> have enough memory space (not just RAM)]. If the
>> volunteer(s) that provide this context have no interest
>> in doing such activities on such hardware, how likely is
>> it that they are going to provide the more involved setup?
>> 
> 
> I simply don't know. Those with a loftier viewpoint probably do.
> Projects like FreeBSD have to pick and choose what they support
> and not all platforms are equal. I suppose one would seek to 
> balance benefits, burdens and breakage. For something like
> Raspberry Pi the benefits are obvious, breakage looks small.
> Burden on the project is un-gaugeable by me. As one of the
> cheapest SBCs the potential user base looks large, perhaps
> the largest among the many competitors.

You are already seeing the judgments in the support that is
available now vs. not. Part of this is the overall difficulty
of supporting the RPi*'s, making efforts in other areas for
them less likely. (And, are you really only asking for the
RPi*'s?)

Do not confuse the RPi* general market and the realtively tiny
RPi* with FreeBSD on it subset. Or, going the other way, the
size of the FreeBSD installation base overall vs. how much of
it is on RPi*'s. (It is less obvious to me for aarch64 RPi*
vs. other aarch64, for example.)

And then: The size of the set of those doing large builds
or other needs-swap-space activity on RPi3B class aarch64?

At some point, FreeBSD ends up with "beyond here is self
support".

>>> Configuring swap manually on a RPi microSD system is a very
>>> considerable amount of work.
>> 
>> That might contribute to what the volunteer(s) choose to do
>> or not do.
> 
> Perhaps that is what motivated the automatic swap creation idea.

But volunteers would be biased to avoiding dealing with
complication of providing the automatic swap creation
unless they had other reasons for doing so. Your
motivation to hope that someone implements such for you
and others and the implementor's motivations need not be
the same.

You can likely infer that the folks that would do such
activity have not found that it is a big deal for their
own activities. If it was, they likely would have
already provided such to support their own activities.

>> 
>>> Having it happen by default 
>>> wastes at most a few percent of the card capacity.
>> 
>> Presuming large enough capacities. 3.5 GiBytes would be
>> more than 10% of 32 GiBytes, for example. What is the
>> distribution of media sizes for folks that do not do
>> large port builds or buildworld buildkernel on such
>> systems --but do use such systems in some way? What
>> fraction of the overall use of such systems is that
>> set of folks?
>> 
> 
> The original proposal set a minimum amount of free space
> on the card before attempting swap creation. That would 
> seem to solve the problem, unless I'm missing something.  
> As a practical matter 32GB is a small card, 128 readily
> available and cheap, 1TB expensive and available. 

So growfs to less than the space available, then add a
swap slice/paritition, but with checks for "would not
fit well" and handling such cases?

>>> At this
>>> point I can't see any reason to say it's a bad idea and
>>> have some personal experience to suggest it's a good idea.
>> 
>> Getting someone else to be interested in doing what
>> you would find useful can be a challenge. Nothing
>> about that requires that the idea be a bad idea.
> 
> Did you mean "good idea"? If so I agree. "Good ideas"
> for one are mere distractions for most.

Just because you might not get someone interested does not
mean an idea is bad. That was the intention of the wording.

>> There are far too many good ideas for various context(s)
>> to implement them all for all the spanned contexts.
> 
> Very true. That's why I suggest looking at benefits, breakage
> and burden of support. Knowing that balance one can decide
> if the user base is big enough to warrant adoption.  

I think you are already seeing the relative priorities
people have judged in what has and has not been done.
Some of it is just "working in this area overall is too
painful compared to other things I can work on".

>>> [bsdinstall limitations snipped]
>>> 
>>> It might be worth mentioning the /boot/loader.conf and 
>>> /etc/sysctl.conf additions you've mentioned in other threads,
>>> as adjuncts to having autoconfigured swap on microSD. They've
>>> all been helpful in my experiments on RPi2 and RPi3. I think
>>> they'd be constructive additions to the RPi images and perhaps
>>> others.. 
>>> 
>> 
>> Mostly, these things go back to what we learned from markj
>> primarily (vm.pageout_oom_seq) and kib primarily
>> (vm.pfault_oom_attempts and vm.pfault_oom_wait), presuming
>> that I remember which-for-what accurately. Using
>> vm.swap_enabled and vm.swap_idle_enabled to avoid a form
>> of losing communication with the system(s) when they are
>> using the swap/paging space is more recent.
>> 
> 
> I didn't catch on until you made the importance explcit. 
> All apply to the constrained-memory situations in which 
> automatic swap creation is likely to be important. It
> might make sense to bundle the settings if practical.

So you are really after pre-supplied images configured
for "constrained-memory situations", at least on RPi*'s
with 1 GiByte of RAM, with updates as releng/*.* ,
stable/* , and main progress?

I'll remind that, as far as I know, no one is actively
working on RPi* support in the FreeBSD code. That is
why FreeBSD requires versions of RPi* firmware that are
over a year out of date, for example. So far as I know,
any new RPi* type of device requiring more recent
firmware would just not be supported at all. (I'm
not aware of important reasons for firmware updates
for what the firmware required now if new devices are
not considered. But others may be aware of reasons
for such.)

===
Mark Millard
marklmi at yahoo.com


From nobody Wed Nov  9 00:44:11 2022
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 4N6R7Y5xDKz4V6dw
	for ; Wed,  9 Nov 2022 00:44:41 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4N6R7Y0SJ5z3tSX
	for ; Wed,  9 Nov 2022 00:44:41 +0000 (UTC)
	(envelope-from void@f-m.fm)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm1 header.b=RCP0gY1Y;
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=NxPg1+qr;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.28 as permitted sender) smtp.mailfrom=void@f-m.fm;
	dmarc=pass (policy=none) header.from=f-m.fm
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
	by mailout.nyi.internal (Postfix) with ESMTP id 11C345C0126
	for ; Tue,  8 Nov 2022 19:44:40 -0500 (EST)
Received: from imap46 ([10.202.2.96])
  by compute3.internal (MEProxy); Tue, 08 Nov 2022 19:44:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm1; t=1667954680; x=1668041080; bh=7BJZch5yLF
	XUblv98tKkS9PvKOdM4Qgtbrv/3oLMbhs=; b=RCP0gY1YjMCN9VK48sZTO/Ek9O
	hfgX6pUQmElszZl2dJptVc5QAqijcfKmMw8Uj3Wc4Vcb1XHCJxEqBYkI4Mi3r17X
	3Hm0FkqgMlE3jRHvcvf/Bw4zXISjVm9c9EWscHLvGSB5WCFFJGKYorKUHvVETS4+
	B93nTPxJm8LXEa71oi20z3Qo3P2uqF2bxsUL9NLRBiEHdkcfv9FMRJu2eFMF6kab
	BdSvlKBeTU8kBHqGBHfZtsu6daHA/H5meABV49Zgiz6vGhALpGrhn+ZQzPomA+kN
	4ZrJbiW9mIH+ESfWRxF69gsfyBMeA+Z1dNFHQm/BT+x3Ko8JeZt+EhjjBlgw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1667954680; x=1668041080; bh=7BJZch5yLFXUblv98tKkS9PvKOdM
	4Qgtbrv/3oLMbhs=; b=NxPg1+qr8Q55lX3I+BTZv013JueEQz04kYoE3xKxKL4t
	2Q5V+geL9zfF6frG+JZwAU4jkIYp/PSsQvBHJpzBYTEj4z5WmHO8EXrIoMP6FrFz
	HkFE/R3/yQiqAzEcMVp3oS/7peqQo9ylYdVCwURUeqosg13WmQ8CQfTjRWlDSzL8
	PjMWfH5L4qunetKrTxct8KR2FRXnUaBrZRmKawNJDVc4RPN+SHL9dC+nR+8gIOMK
	0/q7ztixanp7gxVQsWeaptzzKpGJ93o6BkE4oF/cuLDRAwuz5FOYHlQGw6zWItcu
	9gPWl0ZSQfBiwhMRcthiSaZUERj7ccK+5VlfeT85Sg==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedugddvhecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre
    dtreertdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepieeiheeutdduieekudeikedvffeggfefvedvfeehffeguddthedttedvhf
    evkefhnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id D35C02A20080; Tue,  8 Nov 2022 19:44:39 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
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
Message-Id: <98dab79d-ad47-409b-b3a5-cef19bb925ac@app.fastmail.com>
In-Reply-To: <20221107175206.GA49113@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
Date: Wed, 09 Nov 2022 00:44:11 +0000
From: void 
To: freebsd-arm 
Subject: Re: adding swap when expanding root filesystem
Content-Type: text/plain
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.69 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.28:from];
	XM_UA_NO_VERSION(0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4N6R7Y0SJ5z3tSX
X-ThisMailContainsUnwantedMimeParts: N

Hi Bob,

Have you considered building nanobsd https://docs.freebsd.org/en/articles/nanobsd/ 
(/usr/src/tools/tools/nanobsd) from either a pi4 or pi4 machine?

Seems designed for microSD devices and highly configurable.

I've not tried it yet though.
--

From nobody Wed Nov  9 00:45:41 2022
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 4N6R973wP5z4V6fG
	for ; Wed,  9 Nov 2022 00:46:03 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6R963vRcz3tqp
	for ; Wed,  9 Nov 2022 00:46:02 +0000 (UTC)
	(envelope-from void@f-m.fm)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm1 header.b=Tdyxu5wc;
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=N7J4BG7j;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.28 as permitted sender) smtp.mailfrom=void@f-m.fm;
	dmarc=pass (policy=none) header.from=f-m.fm
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
	by mailout.nyi.internal (Postfix) with ESMTP id 3F9365C0116
	for ; Tue,  8 Nov 2022 19:46:02 -0500 (EST)
Received: from imap46 ([10.202.2.96])
  by compute3.internal (MEProxy); Tue, 08 Nov 2022 19:46:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm1; t=1667954762; x=1668041162; bh=H4uTPiP0pZ
	XmKvvTrqkOhx8i9pRtn/aBxh2tRwZAJMI=; b=Tdyxu5wc12JYx0qUXdiqxi7Wif
	YNXSEIqVPAtfKy+gHjl8dMgmex2vyCnuUlkzCHPTvsgm0mfwjLZ69drPZWxCZjYR
	fJQUf8qI0Zyrkq2K0u9CGVa44sAcN5s/vCHtsRa3UCqxU3j2HsvvrhqDdRvN7zUS
	jqLoVwKo2I0ncQtBtrtWhG/7t0ev1TnJ15s/iCl/m6KtNkLYQyimcheeoqDdb4TA
	Xm7p6yD2ybx+6sl6TCJozmvgbnjWJW2Cl78M5xh+NV4hRHn6cnfT5ghe4cDLogAQ
	PYEl6xK5UwFYEi7iKx5L5Yn9+f1TFiocS4VuMBM0e12CAtUsNuuB7F1+vivw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1667954762; x=1668041162; bh=H4uTPiP0pZXmKvvTrqkOhx8i9pRt
	n/aBxh2tRwZAJMI=; b=N7J4BG7jmBxNJWxEmXlc/EWbq6Yfi5AA0SwR6i4v4sX2
	uE0OtM00CWZLHG4OKrYBLfvw17jR6rjzYW3JO4+D7F8GX5pGyILiuBMU8qSXMHkJ
	XAM2NYxLQxxBbkC2U1hgeBdf20RWNO2gT9bNAY5jaRFPUF+vsln7yqGSTI51WOBQ
	dNursyNSExNOUGPfEy7pW9aV9RQ8FaN756dzTOTrIZ0iUKKm/X51eRrYoe7WEj+D
	rvs00zAUEQ8y1RQ/ZjKr3IG4DB50/cJmL1LrtMPSW1P6v/tT4yLR6qeY8gAtkLR2
	jBaArtU2qXwb0wLtD3HjmpY3vPIdKIMAQg5Jp6Py3A==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedugddviecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre
    dtreertdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepieetvdeuhedthedtvdfhuefhveehvdeiledvieffheevleehgeefudelje
    dukedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
    vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id 124392A20080; Tue,  8 Nov 2022 19:46:02 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
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
Message-Id: <15909ea4-99dc-46b8-bdcb-6283290b16be@app.fastmail.com>
In-Reply-To: <20221107175206.GA49113@www.zefox.net>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221107175206.GA49113@www.zefox.net>
Date: Wed, 09 Nov 2022 00:45:41 +0000
From: void 
To: freebsd-arm 
Subject: Re: adding swap when expanding root filesystem
Content-Type: text/plain
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.62 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.93)[-0.934];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28:c];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.28:from];
	XM_UA_NO_VERSION(0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4N6R963vRcz3tqp
X-ThisMailContainsUnwantedMimeParts: N

(whoops I meant pi3 or pi4)

From nobody Wed Nov  9 03:48:11 2022
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 4N6WCc4Dj5z4YftJ
	for ; Wed,  9 Nov 2022 03:48:28 +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 4N6WCb3XsCz4FsJ
	for ; Wed,  9 Nov 2022 03:48:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=oWg7D9iE;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 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=1667965705; bh=jjLGUO2VyiVyS35XverdXNTwj310LoDg0yeKEn2kwc4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=oWg7D9iE7NRG+Hqm+po5dwjbYDgM0WeNSA0EjeikoHQRI3vV4Sgwas2W6sOTI4OLDYM819c0jiRgvL8Tdku6qON/0MLYa+1U5rDugH1UcV8oap0qJaQMsDTHo9i/a3vqYesWJ8ABBIGpHVC7geKKl5OMpqhDjBh/CUKd3MEgqHMBr48nE1gQMxK8fKNBoxS1imywtUssRx3cmp+MNKdn/wlU/khdKjr172l/dw7sG0PZb+G/H8CHhRq5nFq7K0rjAK7XZGfBKseVFMgE1GXycsnjblykoN9HpsBVLwH08aZhO7NStGPLCYNsdBw4+su/0LS4+c3AoAwCJdkmDUFUEg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667965705; bh=6Lffr1UbMNoR4UMMjO+iZ1+MUWsB4gUNE9tno3VCHz/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kNYth7arLRuc7wnD9BEqyNMjI8jtOnXdUZfJZL4f0hIMxYTquMr2VpZS8FN0D87Z0HQHPab82Yed7MsXiVi5YvZHUCuLoVtes/HAOQii82ayRQ3CFFK8PvA09tF74jnE9BfTWVkuS8KJh0WYQF3qbxKiVJuaepBRXk1NsCxMn3pinvRldDfHMVOT0AO5UaTTJnClGZSv3uXIh6UeXjc76q44+MKxG9f5qzQzAx/nQNuptZpYdL1LmjrWER8s4VClyrTyjoOwfUgBkf8p91KCqMYH7Aq0kogB/5k73evSqbFaw6EVWsNECF/hDG2qlHylhy7Qd1tt72MYr0lS13qYjg==
X-YMail-OSG: REU_R0UVM1n_H5vlMU.GAzTMai7GqVY5UrrE0gglKdJiUZr6Ait31GIQOax5JAx
 9HUqhVA1zCxe2WtsmhvQ7ca.ZRWimrcL0vU_xG50hrR0ZwfZ.HxpwK10idp45_X8YzMVQIjhk8tw
 .fnw5RRPnkG0JQUI2ezK7E1saSSICpKEiGxpIScg.yW7s1YJXSVrEtg2mrpuMhTFVwdAcwmPaUGP
 xEpmU_05LQuDwboAOkoSjBXTaDyLfm9pb1LqEPSkV87FKmstHxbc99Jr4_3veOr3_G.qUMh4tcq3
 zV7iQXDx3Ci6fqdyrP1NvKHsYRj1WR4WQrl1B2YstRajBso4k2dz_.9kYrghGm9lp5TwPFyGa7ln
 1.8TVg9Z73vi7Qx8IKLfG42oRLw2JbtZHGul7di5Xpscp7ZYOXgQIi1Hgk7iv7GxwAY7Im08iyWW
 2vI0GhugBdjxGx4OkBntSwcIZaihsZWK6.zxjVd601gScV70TXFhc8oDyRq8pHWlJcRh7iOVmylc
 Cen4xCDxAbcDsab2mJJumLm0lBUuxbVwoKT3iHCbAoOFku1Q.oajdf2tr996p5T_dG4iygu_dTvo
 39mV4RHHI8zdi2h0AR32aL_.11mYS95RKzLN9wuAQ0ZCn6f_1Jgn7ZegvSs3QbLL0V_gyAnU429M
 AKbL5WCkyq_mWXImcMqgzW2S5bsJMxDz4oYp9D0ilUJTMJK9bAw6NH9VFY5qxhyuU2IHZbbt3aZ2
 mIqOb3X5_gziQw0JuF3SQhaXwuYU9drvgONgES.nCugVBcnAnh._qB6NY07Rx7XfjD1ewpsxA3a5
 gyC47KLjtIgySehIO83VcRXX1oadfwLUk4gOQMuLkWYos61mPDcTNLC7J5ZIuZNTQ30aGakT2o4R
 jbBbBV1igLoFoqWLF9uFQnEcH2LRg6K1dtLDsVmPKCNREjcppoHIoIRPF7jbIMQN9VZ43qFbVwYZ
 9kgsMF5xMot1lymun4gSyg8UNdKcbBv36n4HkqsmpZ3TLhfHkgn.TUJq.jzbWBRRtZEHre_9UR8m
 VfVe6pfnJF6xnTnvmUr7vaMFTCbCqz4.e6DcQ9Ge.sEilBvuk5JlucE.u0KjgfZZq69llNTGPX_Z
 iwb9CLd3s5aKl49Xo0KiSH651U5THAN5gtBx57_MQNHmls6dau.2ZbdSMU_e5n0AKn0.HYtH6c9f
 QgAH88Y45i_NqDmoKo7vZFena4nwn3J0uogWze6JwVqGTIZb6wmmQQcbmqRZ8D9wi2.JkSJZmlcO
 2s7JMJdSKQZvFIXd7F.UCwCCJTL6A2n43ljj.vfTPVm9KTOrRbTtHRL_L4.lwI7exq2A_kponJlR
 6m8hlSG9FVYTtkmEQ.xmi0Lop9F1lpNKv3aImvdyjU8Rezy6k1PFjL29WU8AuCaYtXHFFSFBqtwI
 IvXDaRRZk_39cIIAMCO.lCf1oYbAJmYVSAkMhPDBhhcHVnKgxUfuyuQRC5NWrLqhtICTrvrl3oIh
 41OWB92bIU9E2nMDoslLUkmQKFttu4QLxX.LzpaC6iumAoZdluxycsPqaLJx79Bn4Ii7eLs0mCw4
 bhyt2TieuW6OOQU8SJvTj_JWs0yYMcnQav7IaI0w7sArSLODrBfTed6JT26Ybr7DOpPFbmG0QJvv
 29ttxyh7kZ_DB_GROzZjndwuCtatxCfKlE.kQzh83s_PwiAMJfo5ARq67dBTYyDpZvmSGf1bZYFF
 wzstfgtRk9p0R7_0IoMaJutWjtZy.phJlRgpKi4Zalwx8QDuTTbWHtPFWfjM8DzLde4gA5OpxbQo
 KeHQ5ZdRZOIeczv7auQg.XqdXSd8ZpPbHGdsuXa.lPR6HDsS9LkoOEIsKLVfBGcwAqtFi2e4mKpX
 8r8pabxDlAMC5kJZVan59VVs9DSuFnrRYq7mlZIrh5EhQKKZ3nKWCVRHZCFhlVTnSC62irG7gBYJ
 1XvnlZ21cTKZ3QvxJ2odI9ECvdUVR.vJ1cB7nwrfFi3MGgL.qIykxPQtp07IgcWmrhw5GdyvdvKU
 _an0i67ice.LjqP6fgraupFNkPCmSpbfPXBbjFo7_ALeyfOLSsSqa7KxNTmOY0P3VcgDXiKV8Enm
 XSbAk4BbI_IoINlN5j8IFQ19rjEdrlWGOsPJ_EcWihMPOVGr5uySSaTp05agY03NDYFrh.PfVuvO
 DvONGfmgdQjaGQB0SBCfiAswtOCzRuze9Qx1Y7dVsTfS2svsZ5zt3OyLdfxteQdsJgRWr1NVCnDQ
 Knd5RBZNxfVFrf5.d4ZEiWYHraLxzDCmaOk6EHhU0GEU4JPpYY_AdNno88qJAIlFuC8tTiXQ.Cq0
 bHP6YsZchnQgUCg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 03:48:25 +0000
Received: by hermes--production-gq1-579bc4bddd-kbwws (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 80af72f89e5b652ed5ac6a937921449f;
          Wed, 09 Nov 2022 03:48:21 +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.200.110.1.12\))
Subject: An example of installing the 13.1-RELEASE image for aarch64 RPI* but
 with a swap partition: steps to follow
Message-Id: <0DEAD006-BF16-4D5F-B6D1-3B0F1A4D6D0A@yahoo.com>
Date: Tue, 8 Nov 2022 19:48:11 -0800
Cc: Mike Karels 
To: bob prohaska ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <0DEAD006-BF16-4D5F-B6D1-3B0F1A4D6D0A.ref@yahoo.com>
X-Spamd-Bar: ---
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.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]
X-Rspamd-Queue-Id: 4N6WCb3XsCz4FsJ
X-ThisMailContainsUnwantedMimeParts: N

Note: Some details below are MBR specific (matching the original image)
Note: I have included frequent "gpart show" or "gpart show -p" commands =
and output.

To get started I put the image on a 32 GiByte microsd card:

# dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da4 bs=3D1m=
 conv=3Dfsync,sync status=3Dprogress

After it finished . . .

Boot to the microsd card, stopping in the loader to boot in
a way that stops before the growfs but allows adjusting things:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds... =20

Type '?' for a list of commands, 'help' for more detailed help.
OK boot -s
. . .
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # gpart show=20
=3D>      63  62333889  mmcsd0  MBR  (30G)
        63      2016          - free -  (1.0M)
      2079    102312       1  fat32lba  [active]  (50M)
    104391   6187041       2  freebsd  (3.0G)
   6291432  56042520          - free -  (27G)

=3D>      0  6187041  mmcsd0s2  BSD  (3.0G)
        0       57            - free -  (29K)
       57  6186880         1  freebsd-ufs  (2.9G)
  6186937      104            - free -  (52K)

=3D>      63  62333889  diskid/DISK-D8900C35  MBR  (30G)
        63      2016                        - free -  (1.0M)
      2079    102312                     1  fat32lba  [active]  (50M)
    104391   6187041                     2  freebsd  (3.0G)
   6291432  56042520                        - free -  (27G)

=3D>      0  6187041  diskid/DISK-D8900C35s2  BSD  (3.0G)
        0       57                          - free -  (29K)
       57  6186880                       1  freebsd-ufs  (2.9G)
  6186937      104                          - free -  (52K)

# ls -Tld /dev/ufs/*
crw-r-----  1 root  operator  0x5e Nov  4 04:48:18 2022 /dev/ufs/rootfs

root@:/ # gpart resize -i2 /dev/mmcsd0
GEOM_PART: mmcsd0s2 was automatically resized.
  Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` =
to revert them.
mmcsd0s2 resized

root@:/ # gpart commit mmcsd0s2
root@:/ # gpart show
=3D>      63  62333889  mmcsd0  MBR  (30G)
        63      2016          - free -  (1.0M)
      2079    102312       1  fat32lba  [active]  (50M)
    104391  62228537       2  freebsd  (30G)
  62332928      1024          - free -  (512K)

=3D>       0  62228537  mmcsd0s2  BSD  (30G)
         0        57            - free -  (29K)
        57   6186880         1  freebsd-ufs  (2.9G)
   6186937  56041600            - free -  (27G)

=3D>      63  62333889  diskid/DISK-D8900C35  MBR  (30G)
        63      2016                        - free -  (1.0M)
      2079    102312                     1  fat32lba  [active]  (50M)
    104391  62228537                     2  freebsd  (30G)
  62332928      1024                        - free -  (512K)

=3D>       0  62228537  diskid/DISK-D8900C35s2  BSD  (30G)
         0        57                          - free -  (29K)
        57   6186880                       1  freebsd-ufs  (2.9G)
   6186937  56041600                          - free -  (27G)


root@:/ # # Ballpark: 3.0G + 27G - 3.5G =3D=3D 26.5G =3D=3D 26.5*1024*M =
=3D=3D 27136M

root@:/ # gpart resize -i1 -s27136M /dev/mmcsd0s2
mmcsd0s2a resized
root@:/ # # gpart show -p
=3D>      63  62333889    mmcsd0  MBR  (30G)
        63      2016            - free -  (1.0M)
      2079    102312  mmcsd0s1  fat32lba  [active]  (50M)
    104391  62228537  mmcsd0s2  freebsd  (30G)
  62332928      1024            - free -  (512K)

=3D>       0  62228537   mmcsd0s2  BSD  (30G)
         0        57             - free -  (29K)
        57  55574528  mmcsd0s2a  freebsd-ufs  (27G)
  55574585   6653952             - free -  (3.2G)

=3D>      63  62333889    diskid/DISK-D8900C35  MBR  (30G)
        63      2016                          - free -  (1.0M)
      2079    102312  diskid/DISK-D8900C35s1  fat32lba  [active]  (50M)
    104391  62228537  diskid/DISK-D8900C35s2  freebsd  (30G)
  62332928      1024                          - free -  (512K)

=3D>       0  62228537   diskid/DISK-D8900C35s2  BSD  (30G)
         0        57                           - free -  (29K)
        57  55574528  diskid/DISK-D8900C35s2a  freebsd-ufs  (27G)
  55574585   6653952                           - free -  (3.2G)

root@:/ # gpart add -tfreebsd-swap /dev/mmcsd0s2
mmcsd0s2b added
root@:/ # gpart show -p
=3D>      63  62333889    mmcsd0  MBR  (30G)
        63      2016            - free -  (1.0M)
      2079    102312  mmcsd0s1  fat32lba  [active]  (50M)
    104391  62228537  mmcsd0s2  freebsd  (30G)
  62332928      1024            - free -  (512K)

=3D>       0  62228537   mmcsd0s2  BSD  (30G)
         0        57             - free -  (29K)
        57  55574528  mmcsd0s2a  freebsd-ufs  (27G)
  55574585      2048             - free -  (1.0M)
  55576633   6651904  mmcsd0s2b  freebsd-swap  (3.2G)

=3D>      63  62333889    diskid/DISK-D8900C35  MBR  (30G)
        63      2016                          - free -  (1.0M)
      2079    102312  diskid/DISK-D8900C35s1  fat32lba  [active]  (50M)
    104391  62228537  diskid/DISK-D8900C35s2  freebsd  (30G)
  62332928      1024                          - free -  (512K)

=3D>       0  62228537   diskid/DISK-D8900C35s2  BSD  (30G)
         0        57                           - free -  (29K)
        57  55574528  diskid/DISK-D8900C35s2a  freebsd-ufs  (27G)
  55574585      2048                           - free -  (1.0M)
  55576633   6651904  diskid/DISK-D8900C35s2b  freebsd-swap  (3.2G)

root@:/ # exit
Setting hostuuid: . . .
Setting hostid: . . .
Fast boot: skipping disk checks.
Growing root partition to fill device
mmcsd0s2 resized
mmcsd0s2a resized
gpart: arg0 'ufs/rootfs': Invalid argument
super-block backups (for fsck_ffs -b #) at:
. . .

root@generic:~ # df -m
Filesystem             1M-blocks Used Avail Capacity  Mounted on
/dev/ufs/rootfs            26273 2834 21336    12%    /
devfs                          0    0     0   100%    /dev
/dev/msdosfs/MSDOSBOOT        49   24    25    49%    /boot/msdos
tmpfs                       7663    0  7663     0%    /tmp

root@generic:~ # ls -Tld /dev/ufs/*
crw-r-----  1 root  operator  0x5e Nov  4 05:08:54 2022 /dev/ufs/rootfs

root@generic:~ # echo "/dev/mmcsd0s2b	none	swap	sw	0	=
0" >> /etc/fstab
root@generic:~ # swapon -a
swapon: adding /dev/mmcsd0s2b as swap device
root@generic:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/mmcsd0s2b    3325952        0  3325952     0%

root@generic:~ # more /etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/ufs/rootfs         /               ufs     rw              1       =
1
/dev/msdosfs/MSDOSBOOT  /boot/msdos     msdosfs rw,noatime      0       =
0
tmpfs                   /tmp            tmpfs   rw,mode=3D1777    0      =
 0
/dev/mmcsd0s2b          none            swap    sw              0       =
0

I've not done anything above to use a label instead of the
hard coded /dev/mmcsd0s2b reference. So this would not
boot nicely via a USB reader instead of the microsd card
slot being used: different device name. So . . .

root@generic:~ # glabel label -v swapspace /dev/mmcsd0s2b
Metadata value stored on /dev/mmcsd0s2b.
Done.

root@generic:~ # vi /etc/fstab
root@generic:~ # more /etc/fstab
# Custom /etc/fstab for FreeBSD embedded images
/dev/ufs/rootfs         /               ufs     rw              1       =
1
/dev/msdosfs/MSDOSBOOT  /boot/msdos     msdosfs rw,noatime      0       =
0
tmpfs                   /tmp            tmpfs   rw,mode=3D1777    0      =
 0
/dev/label/swapspace    none            swap    sw              0       =
0

root@generic:~ # shutdown -r now
. . .

root@generic:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/label/swapspace   3325948        0  3325948     0%


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Nov  9 23:07:40 2022
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 4N70y72ylJz4dWwL
	for ; Wed,  9 Nov 2022 23:08:31 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N70xy4wPHz3H0V;
	Wed,  9 Nov 2022 23:08:20 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net;
	dmarc=none
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 2A9N7etK003383;
	Wed, 9 Nov 2022 15:07:40 -0800 (PST)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 2A9N7eDW003382;
	Wed, 9 Nov 2022 15:07:40 -0800 (PST)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202211092307.2A9N7eDW003382@gndrsh.dnsmgr.net>
Subject: Re: adding swap when expanding root filesystem
In-Reply-To: 
To: Gordon Bergling 
Date: Wed, 9 Nov 2022 15:07:40 -0800 (PST)
CC: Mike Karels , freebsd-arm@FreeBSD.org, jmg@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Spamd-Bar: -
X-Spamd-Result: default: False [-1.86 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.76)[-0.760];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[dnsmgr.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4N70xy4wPHz3H0V
X-ThisMailContainsUnwantedMimeParts: N

-- Start of PGP signed section.
> Hi Mike,
> 
> On Mon, Nov 07, 2022 at 10:10:38AM -0600, Mike Karels wrote:
> > This question is not really arm-specific, but I couldn't think of a better
> > mailing list for it.
> > 
> > There are peridic issues reported on small systems like Raspberry Pi
> > where people are running buildworld or poudriere and running out of
> > memory.  As the user gets no control over the disk layout when installing,
> > there is no option to add swap space on the install image.  I have added
> > swap space on a USB disk, but this is often not an option.  It occurred
> > to me that it might be reasonable to add swap space before expanding
> > the root filesystem if there is sufficient space.  I have a prototype,
> > and wondered if this is a good thing to do.  Granted, this will often
> > create swap on microSD, which is not optimal, but probably better than
> > nothing.
> > 
> > The current prototype creates a swap partition which is 1/10 of the disk
> > if the disk is at least 15 GB and the initial root partition is no more
> > than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> > probably enable this by default, but provide a way to disable it via a
> > kenv variable and/or a variable in /etc/rc.conf.
> > 
> > Thoughts?
> > 
> > 		Mike
> 
> That would be very welcomed addition. I personally ofter run into problems
> when I try get a crash dump from my RPi4, since no dumpdev can be set
> without a separate swap partion. An USB stick worked for I while, but it
> just went dead at some point.

+1 please.

> 
> And the genet(4) driver doesn't support netdump(4).
> 
> --Gordon
-- End of PGP section, PGP failed!

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Sun Nov 13 21:00:40 2022
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 4N9Pwn5hKrz4h6dD
	for ; Sun, 13 Nov 2022 21:00:41 +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 4N9Pwn1LhNz4Qgd
	for ; Sun, 13 Nov 2022 21:00:41 +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=1668373241;
	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=kvzB8AdxPPm+8tJpbD9Ag04CN2FmlIPXDn1nMKc07H4=;
	b=uMLKfCe60SulYn3tZijkg3SLyGVBQ55895UQ1mqi5e5rdpRNQCBlJ0+4eE3/UOQfwbokrG
	JpP4sPSESXG/1xjD/qCLQEgGvLUTYNrje4qgMCrDRP4xBCZDTAjT6ib1Fk8hFWqscqppSE
	XcfXyeXbGKg4rebZM5LsvH07udi4wGAiYyRZtP4cFFmDwxGjhn6MITMWcgvDLAsLKQFGlF
	FHVlsjfHFzPOY6VnjXzDyvpSVe4XQtW5Y7S6vBRPVLwNERda5bWmEvP7H++ABAtHwivBUS
	Y3j4cLEmsw8GzVla+yzQZZ89mriF/ezVNlZ7ZyPl9SDx/JSRqklEDbZkHfmzIg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668373241; a=rsa-sha256; cv=none;
	b=Xsn79i1QHzHUIETq1vRg5wwE7Ks8Ms2+JQvBmtKu3yZpiw0EpvJ0hbkjKEVAVib9VLYZiE
	vP3FnN31JmtyIUpxhL3YyVI7hrC2MoeF8i4tmOz5f4pRUj6GRESwyCRjhfWH5y8LBCSKgf
	Wh6NOI9E8O7ojA3mOQeKJB0gickl5DWb2QZ+l17qq61o4iUtIzCH8m7d2IrViFOBHE4SqO
	TdLkJTro+TET/D8VEY+0p8vz2QwMVsFUcieaz28RPK4psKIT3MnYNy7pk9vQZ++9Sl7pin
	fRRmxfKJpyeBAIv65NyG1ydiPeA7dcghleTb1btmy9+KS5ZsU7uAlHWTo/lEbg==
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 4N9Pwn0QKGzGfv
	for ; Sun, 13 Nov 2022 21:00:41 +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 2ADL0eCH057854
	for ; Sun, 13 Nov 2022 21:00:40 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2ADL0eIL057853
	for freebsd-arm@FreeBSD.org; Sun, 13 Nov 2022 21:00:40 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202211132100.2ADL0eIL057853@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 Nov 2022 21:00:40 +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="16683732403.cF5e.54999"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16683732403.cF5e.54999
Date: Sun, 13 Nov 2022 21:00:40 +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.

--16683732403.cF5e.54999
Date: Sun, 13 Nov 2022 21:00:40 +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.


--16683732403.cF5e.54999--

From nobody Mon Nov 14 20:53:53 2022
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 4NB1kf68XQz4dL18
	for ; Mon, 14 Nov 2022 20:54:02 +0000 (UTC)
	(envelope-from SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4NB1kd4L2Cz3Qh8;
	Mon, 14 Nov 2022 20:54:01 +0000 (UTC)
	(envelope-from SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=Hu9+Cve0;
	spf=pass (mx1.freebsd.org: domain of "SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl";
	dmarc=pass (policy=quarantine) header.from=klop.ws
Date: Mon, 14 Nov 2022 21:53:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1668459234;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=aVBE4Rd/+cVvTigJ1j4ihtYXKhqxsTtA8Bz85/YHyzs=;
	b=Hu9+Cve0KABV5f9ezLJl07zYVB/q3TySlt+TeSohdMuaBsrKwLtTnjiQGdsWqqAI9LA2gv
	fIidaEvBHi4G3A+pwqoVCjAyEMKako7/3GOR1igwwpv+86Hl8p5mIzvFaH69U58l+ZVcdI
	1rAhWFWVEiOzLR+QvPdb/4JnlKuZpgLJa5YDfOSDJT1tA9vmAAAlALiRyhvwhQMm9CbKdJ
	4FHbmTA+ayQlorV1OMzVHh0RQOs9WxawDD39Qrz+uHVgFKubxMS5yGbGmKBeKm4N2nrKoK
	czwCMnQ0BHjT6X9/Niyg+aTbjgVo7lXuFhhF9ejABUhKzGKpUtye8m0BWMqzJQ==
From: Ronald Klop 
To: freebsd-arm@FreeBSD.org, Andrew Turner 
Message-ID: <1331707040.259440.1668459233836@localhost>
Subject: lsof crashes in Arm Optimized Routines
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="----=_Part_259439_111495440.1668459233759"
X-Mailer: Realworks (631.42)
Importance: Normal
X-Priority: 3 (Normal)
X-Spamd-Result: default: False [-1.20 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	TO_DN_SOME(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=xB1X=3O=klop.ws=ronald-lists@realworks.nl]
X-Rspamd-Queue-Id: 4NB1kd4L2Cz3Qh8
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_259439_111495440.1668459233759
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267760 : Segmentation fault in lsof.
Program received signal SIGSEGV, Segmentation fault.                                                                              
Invalid permissions for mapped object.                                                                                            
memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:175                              
175             stp     D_l, D_h, [dst, 64]!
I also remembered this change: https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=1 about Arm Optimized Routines.

Could this be related? What can I do to help debug this?

Regards,

Ronald.
 
------=_Part_259439_111495440.1668459233759
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,



See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267760 : Segmentation fault in lsof.

Program received signal SIGSEGV, Segmentation fault.                                                                              
Invalid permissions for mapped object.                                                                                            
memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:175                              
175             stp     D_l, D_h, [dst, 64]!



I also remembered this change: https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=1 about Arm Optimized Routines.



Could this be related? What can I do to help debug this?



Regards,



Ronald.

 
------=_Part_259439_111495440.1668459233759--

From nobody Tue Nov 15 04:53:12 2022
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 4NBDMc2Bqdz4fcSl
	for ; Tue, 15 Nov 2022 04:53:16 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from nmtao101.oxsus-vadesecure.net (mta-131a.oxsus-vadesecure.net [135.148.117.228])
	(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 4NBDMZ6nqBz3CQs
	for ; Tue, 15 Nov 2022 04:53:14 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=LgV+2MF2;
	spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.228 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com
DKIM-Signature: v=1; a=rsa-sha256; bh=iyrL1WM4Pu4Yc86Bqoq81Cn++KVHwbPeYcipXm
 faIbA=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to:
 subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:
 in-reply-to:references:list-id:list-help:list-unsubscribe:
 list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1;
 t=1668487994; x=1669092794; b=LgV+2MF2WMc1xX0Ya3HH1XcwlFKcP8zaNJnqU1NIm
 DyKBOqYQIHOvmAeyvUF8Q+idZJOp+K69PkpvlHYPKTh/VYxhRgpSvp1BdJnrNF5JKCf0aOf
 mr1OZrJZ8XF7wG0DM7T+/+fRICulJbBWJAyPNn05BAAYCannI4DxfAbv6+qkqYgYK4FBN7u
 k1kcyAXT9payYtGilDTqaP7ZOv0hRTz5g0dJFiBHtaMHJLDhWkH+SZ9JQwH9UhwDOf2ZKUN
 p9Y7WmcG5RPnQDqdeln34CiGYVzsm4rsLNabW2hqm15REhA/LcMkN86P2glONLLuyiLnRzI
 iJDRo8ZkD+8kWtzqg==
Received: from proxy-3.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149])
 by oxsus1nmtao01p.internal.vadesecure.com with ngmta
 id dcc83411-1727a8fd6fa008ca; Tue, 15 Nov 2022 04:53:13 +0000
Content-Type: multipart/alternative;
 boundary="------------qIUto3ZAEvrcJk2UgIR1Qxc9"
Message-ID: <227fa369-af8b-f2ec-33e3-305327464392@thegalacticzoo.com>
Date: Mon, 14 Nov 2022 20:53:12 -0800
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.2.2
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Fred Finster 
Subject: versionsort@FSBD_1.7 missing symbol in libinput_drv.so module for
 ARM64
X-Spamd-Result: default: False [-1.99 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine];
	R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1];
	R_SPF_ALLOW(-0.20)[+ip4:135.148.117.228];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NBDMZ6nqBz3CQs
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------qIUto3ZAEvrcJk2UgIR1Qxc9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

FreeBSD 14.0-CURRENT is a changing, constantly modified. Sometimes it 
breaks.  Those who use 14.0-CURRENT, must also be able to fix it.

Yes,  I heard from previous mentions by "Sir Dice" about NOT trusting 
the -CURRENT version to be stable

https://ghostbsd-arm64.blogspot.com/2022/11/libinput-module-error-fbsd17-not-found.html 


My written blogpost with many details about missing symbol 
"versionsort@FBSD_1.7" causing libinput.so to NOT LOAD.

So, this is a reminder note to others, you might find a missing symbol 
"versionsort@FBSD_1.7"  when running programs on the kernel.


  For me, the problem arose when trying to start a DESKTOP ENVIRONMENT 
(DE)  on an recently updated FreeBSD 14.0 Raspberry Pi 4B with 8 GB ram. 
This left me locked out from keyboard and mouse input when the MATE 
desktop and tested with the XFCE4 desktop where run  with "startx" using 
contents of file   ~/.xinitrc [exec mate-session]  or [exec xfce4-session].

With that missing module "libinput_drv.so", no USB keyboard and USB 
mouse inputs to control the desktop.  'Alt-Ctl-F2' to switch desktops, 
does not work either!

The kernel is still running, so logging in with SSH works fine. If you 
have SSH enable before running 'startx' that breaks the keyboard input,  
This allowed me to view a log file "less /var/log/Xorg.0.log"   I share 
these 3 lines below:

[  3730.546] (II) Loading /usr/local/lib/xorg/modules/input/libinput_drv.so

[  3730.553] (EE) Failed to load 
/usr/local/lib/xorg/modules/input/libinput_drv.so: 
/usr/local/lib/libinput.so.10: Undefined symbol "versionsort@FBSD_1.7"

[  3730.553] (EE) Failed to load module "libinput" (loader failed, 0)


Question,  How to get updates happening for other packages that depend 
on this specific file /usr/local/lib/libinput.so.10 ?  I think this file 
has been updated from FBSD_1.6 to FBSD_1.7, but the FreeBSD 14.0-CURRENT 
kernel needs to also be updated to provide that dynamic link to 
versionsort@FBSD_1.7

Well back to testing. Do you have suggestions for using "ldd" command to 
find which software module provides that dynamic link resource? Do you 
have other suggestions and methods to repair my little problem?

Since this is not a release,   I cannot use  "freebsd-update fetch 
install". I use the following 2 lines for updating current software:

pkg update

pkg upgrade

Waiting for some time ( hours or days ),  I think this missing symbol problem will fix itself, when using pkg update, pkg upgrade.
or update the kernel software with git:

su -
cd /usr/src


      One-off, 2021-03-02,  Use this line to update  freebsd code to
      current state

|git -C /usr/src pull --ff-only --unshallow|

time make buildkernel KERNCONF=GENERIC-VCHIQ
time make installkernel KERNCONF=GENERIC-VCHIQ

I also now running to update all my software modules to latest version:
time make buildworld KERNCONF=GENERIC-VCHIQ

-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144

--------------qIUto3ZAEvrcJk2UgIR1Qxc9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
FreeBSD 14.0-CURRENT is a changing, constantly modified.  
      Sometimes it breaks.  Those who use 14.0-CURRENT, must also be
      able to fix it.

    
Yes,  I heard from previous mentions by "Sir Dice" about NOT
      trusting the -CURRENT version to be stable

    
https://ghostbsd-arm64.blogspot.com/2022/11/libinput-module-error-fbsd17-not-found.html 
      

    

    
My written blogpost with many details about missing symbol
      "versionsort@FBSD_1.7" causing libinput.so to NOT LOAD.

    

    
So, this is a reminder note to others, you might find a missing
      symbol  "versionsort@FBSD_1.7"  when running programs on the
      kernel.  

    

    
 

    

    
 For me, the problem arose when trying to start a DESKTOP
      ENVIRONMENT (DE)  on an recently updated FreeBSD 14.0 Raspberry Pi
      4B with 8 GB ram. This left me locked out from keyboard and mouse
      input when the MATE desktop and tested with the XFCE4 desktop 
      where run  with "startx" using contents of file   ~/.xinitrc 
      [exec mate-session]  or [exec xfce4-session].    

    

    
With that missing module "libinput_drv.so", no USB keyboard and
      USB mouse inputs to control the desktop.  'Alt-Ctl-F2' to switch
      desktops, does not work either!

    
The kernel is still running, so logging in with SSH works fine. 
      If you have SSH enable before running 'startx' that breaks the
      keyboard input,  This allowed me to view a log file "less
      /var/log/Xorg.0.log"   I share these 3 lines below:      

    

    
[  3730.546] (II)
      Loading /usr/local/lib/xorg/modules/input/libinput_drv.so

    
[  3730.553] (EE) Failed
      to load /usr/local/lib/xorg/modules/input/libinput_drv.so:
      /usr/local/lib/libinput.so.10: Undefined symbol
      "versionsort@FBSD_1.7"

    
[  3730.553] (EE) Failed
      to load module "libinput" (loader failed, 0)

    


    

    
Question,  How to get
      updates happening for other packages that depend on this specific
      file /usr/local/lib/libinput.so.10 ?  I think this file has been
      updated from FBSD_1.6 to FBSD_1.7, but the FreeBSD 14.0-CURRENT
      kernel needs to also be updated to provide that dynamic link to
      versionsort@FBSD_1.7

    
Well back to testing. 
      Do you have suggestions for using "ldd" command to find which
      software module provides that dynamic link resource? Do you have
      other suggestions and methods to repair my little problem?

    

    
Since this is
        not a release,   I cannot use  "freebsd-update fetch install".  
        I use the following 2 lines for updating current software:

      

    
pkg update

    
pkg upgrade

      

    

    
Waiting for some time ( hours or days ),  I think this missing symbol problem will fix itself, when using pkg update, pkg upgrade.
or update the kernel software with git:

su -
cd /usr/src


    
One-off, 2021-03-02,  Use this line to update  freebsd
      code to current state

    
git
        -C /usr/src pull --ff-only --unshallow

    
time make buildkernel KERNCONF=GENERIC-VCHIQ
time make installkernel KERNCONF=GENERIC-VCHIQ

I also now running to update all my software modules to latest version:
time make buildworld KERNCONF=GENERIC-VCHIQ

-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144

  


--------------qIUto3ZAEvrcJk2UgIR1Qxc9--

From nobody Tue Nov 15 11:33:18 2022
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 4NBPFF4nxBz4hj7W
	for ; Tue, 15 Nov 2022 11:33:21 +0000 (UTC)
	(envelope-from SRS0=AIF2=3P=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4NBPFD6MjHz4GJm;
	Tue, 15 Nov 2022 11:33:20 +0000 (UTC)
	(envelope-from SRS0=AIF2=3P=klop.ws=ronald-lists@realworks.nl)
Authentication-Results: mx1.freebsd.org;
	none
Date: Tue, 15 Nov 2022 12:33:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1668511998;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=2VlH+PnYdXzuMYlGCLoXr+HD69ugknOOxWt32laLTt8=;
	b=i50osQwwj45MUyrnpaz0RGvtPPRylnAuQIMybjxNKAMI3pLfkZ4JdJXubxBdyEn38ZIfp9
	efDIIXQJGR9vD4LEbZE2K9tGxNzuHuqbNj0FXP79nE6Y+LJ6bAdGz8A8bvK99dROgx+och
	07s4jXdbar79AMLIb6u9BRxGL0N6B/m/KfvKt5D9H1dTR2SeNzM8h/FAlhO1y6BUWqIWku
	jEY3Gnuyfu7PVwO/q7yKcXTdBmsNQCMRLiZIaSpzuKdNizxAchitQggLgY1K6DfbWRSxU2
	gZ8inGXN93bxWXHobdfnfLykJcyPGddAb9rQwUFtiaB+NAtw3+hDCPxPHJjZ8Q==
From: Ronald Klop 
To: Ronald Klop 
Cc: freebsd-arm@FreeBSD.org, Andrew Turner 
Message-ID: <490902644.115954.1668511998644@localhost>
In-Reply-To: <1331707040.259440.1668459233836@localhost>
References: <1331707040.259440.1668459233836@localhost>
Subject: Re: lsof crashes in Arm Optimized Routines
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="----=_Part_115952_782226044.1668511998567"
X-Mailer: Realworks (631.42)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4NBPFD6MjHz4GJm
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_115952_782226044.1668511998567
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sorry for the noise.

But I cannot reproduce this today. I can scroll back in my terminal and see the command and error from yesterday, but running the same again just works.

Regards and happy hacking,
Ronald.

 
Van: Ronald Klop 
Datum: maandag, 14 november 2022 21:53
Aan: freebsd-arm@FreeBSD.org, Andrew Turner 
Onderwerp: lsof crashes in Arm Optimized Routines
> 
> Hi,
> 
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267760 : Segmentation fault in lsof.
> Program received signal SIGSEGV, Segmentation fault.                                                                              
> Invalid permissions for mapped object.                                                                                            
> memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:175                              
> 175             stp     D_l, D_h, [dst, 64]!
> I also remembered this change: https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=1 about Arm Optimized Routines.
> 
> Could this be related? What can I do to help debug this?
> 
> Regards,
> 
> Ronald.
>  

------=_Part_115952_782226044.1668511998567
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry for the noise.



But I cannot reproduce this today. I can scroll back in my terminal and see the command and error from yesterday, but running the same again just works.



Regards and happy hacking,

Ronald.



 

Van: Ronald Klop <ronald-lists@klop.ws>

Datum: maandag, 14 november 2022 21:53

Aan: freebsd-arm@FreeBSD.org, Andrew Turner <andrew@FreeBSD.org>

Onderwerp: lsof crashes in Arm Optimized Routines









Hi,



See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267760 : Segmentation fault in lsof.


Program received signal SIGSEGV, Segmentation fault.                                                                              
Invalid permissions for mapped object.                                                                                            
memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:175                              
175             stp     D_l, D_h, [dst, 64]!



I also remembered this change: https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=1 about Arm Optimized Routines.



Could this be related? What can I do to help debug this?



Regards,



Ronald.

 







------=_Part_115952_782226044.1668511998567--

From nobody Tue Nov 15 13:05:22 2022
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 4NBRHg18jnz4dBQS
	for ; Tue, 15 Nov 2022 13:05:35 +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 4NBRHd6pDZz3Dcl
	for ; Tue, 15 Nov 2022 13:05:33 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=FvhUOuXg;
	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=1668517526;
	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=h0C6gvBORBRNxb9nNlDQpgQFjzjXObX8lZoyXaS1BCs=;
	b=FvhUOuXgIzjLTrDTG/TV3Cfsq+Qh941frjU4fF+a2yQNmY47Z78W8qYyhRR8bUP6Xgvqa6
	wR97Pd4yLagUMgA0iq6TVXmZVEFzNJQLc2tgb38WBMqh4cvyWitfk9g7b5VxURDdWataO4
	KNlAzqhYcexlmeUHesNjz7Cox6C6M9s=
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 db5b438e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 15 Nov 2022 13:05:26 +0000 (UTC)
Date: Tue, 15 Nov 2022 14:05:22 +0100
From: Emmanuel Vadot 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
Message-Id: <20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
In-Reply-To: 
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
	<665C125A-3E2B-408F-8F6E-B2D23237F06A@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-Spamd-Result: default: False [-1.50 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	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];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[manu];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bidouilliste.com:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NBRHd6pDZz3Dcl
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 4 Nov 2022 12:31:51 -0700
Mark Millard  wrote:

> On 2022-Oct-22, at 23:00, Mark Millard  wrote:
> 
> > Well, turns out that part of the "Import device-tree files
> > from Linux 5.14" is:
> > 
> > https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts?id=5956d97f4b32
> > 
> > which has:
> > 
> > diff --git a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> > index 3bef1f39bc6e..1b0f7e4551ea 100644
> > --- a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> > +++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> > @@ -381,6 +381,11 @@
> > 	status = "okay";
> > };
> > 
> > +&usbdrd3 {
> > +	dr_mode = "host";
> > +	status = "okay";
> > +};
> > +
> > &usb_host0_ehci {
> > 	status = "okay";
> > };
> > 
> > usbdrd3 is for USB3, so "host" now has a sort of dtb change
> > in the interfacing for supporting host-mode USB3. The old:
> > 
> > /usr/main-src/sys/dts/arm64/overlays/rk3328-dwc3.dtso
> > 
> > has, in part:
> > 
> >        usbdrd3: usb@ff600000 {
> >                compatible = "rockchip,rk3328-dwc3";
> >                clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
> >                         <&cru ACLK_USB3OTG>;
> >                clock-names = "ref_clk", "suspend_clk",
> >                              "bus_clk";
> >                #address-cells = <2>;
> >                #size-cells = <2>;
> >                ranges;
> >                status = "okay";
> > 
> >                usbdrd_dwc3: dwc3@ff600000 {
> >                        compatible = "snps,dwc3";
> >                        reg = <0x0 0xff600000 0x0 0x100000>;
> >                        interrupts = ;
> >                        dr_mode = "host";
> >                        phy_type = "utmi_wide";
> >                        snps,dis_enblslpm_quirk;
> >                        snps,dis-u2-freeclk-exists-quirk;
> >                        snps,dis_u2_susphy_quirk;
> >                        snps,dis_u3_susphy_quirk;
> >                        snps,dis-del-phy-power-chg-quirk;
> >                        snps,dis-tx-ipgap-linecheck-quirk;
> >                        status = "okay";
> >                };
> >        };
> > 
> > which looks to me to likely now conflict with the below --given
> > the added "host" usage as of 5.14 reported above:
> > 
> > /usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328.dtsi
> > 
> > that, as of the 5.13 import, has:
> > 
> >        usbdrd3: usb@ff600000 {
> >                compatible = "rockchip,rk3328-dwc3", "snps,dwc3";
> >                reg = <0x0 0xff600000 0x0 0x100000>;
> >                interrupts = ;
> >                clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
> >                         <&cru ACLK_USB3OTG>;
> >                clock-names = "ref_clk", "suspend_clk",
> >                              "bus_clk";
> >                dr_mode = "otg";
> >                phy_type = "utmi_wide";
> >                snps,dis-del-phy-power-chg-quirk;
> >                snps,dis_enblslpm_quirk;
> >                snps,dis-tx-ipgap-linecheck-quirk;
> >                snps,dis-u2-freeclk-exists-quirk;
> >                snps,dis_u2_susphy_quirk;
> >                snps,dis_u3_susphy_quirk;
> >                status = "disabled";
> >        };
> > 
> > My guess would be that some kernel changes are required
> > in order to track this structural changes, not just
> > avoiding the old .dtbo . Testing showed that disabling
> > the load of the .dtbo was insufficient to fix things.
> 
> FYI:
> 
> The mainline Linux commit that addeed usbdrd3 to
> arch/arm64/boot/dts/rockchip/rk3328.dtsi is the
> following from 2021-03-24:
> 
> https://github.com/torvalds/linux/commit/44dd5e2106dc2fd01697b539085818d1d1c58df0
> 
> The mainline Linux commit that added the enabling of
> the USB3 host mode in
> arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> is the following from 2021-05-01:
> 
> https://github.com/torvalds/linux/commit/bbac8bd65f5402281cb7b0452c1c5f367387b459
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

 Hi Mark,

 See https://reviews.freebsd.org/D37392 (and child reviews) for a fix.
 This was indeed the import of the new DTS files that caused the first
problem (there is no glue node in rk3328.dtsi like in other SoCs or
like our overlay). The other commit responsible for breaking USB3
support was the addition to RK356x SoC, the check was bad for when to
force USB2.

 Cheers,

-- 
Emmanuel Vadot  

From nobody Tue Nov 15 15:59:23 2022
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 4NBW8C2MQWz4h5wN
	for ; Tue, 15 Nov 2022 15:59:23 +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 4NBW8C1FgJz3n8m
	for ; Tue, 15 Nov 2022 15:59:23 +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=1668527963;
	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=TCrmM2lksJMpjLa7VOhkrMZ/YP5I98Hk8gZZj95zdXI=;
	b=mC/urWT916HO2I3Hw7LMXmiawBeIJPgCq+hGDtEyUCHZ54pkx3xFGfvJrS7s/XHDpRFiZJ
	WoFVmS91ssxxcwbnjBl5FCgjJScJDEp6S9/NKKSXUvv99+Z8so1rPhGZpguN9/XtmzfMCN
	NnOp0FUUpDIkiaey2wZUyQcFQSWqgXDCIL7ddj+lYzs3Wv0R7ln2DpkXGjsPAVPQvC8T3O
	VUXxTHRUkky6DkUQNJ8IAyn9rUEVt9gpzKsDTCiWtwXuouMKmJju56Cz+aaJLNqULrmDGR
	LGX1uMRbsYWM6/u7K5QdFf73Cwkdv+637FsqxQ0KAOFYwRbJPxVDHWKsIE4M9g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668527963; a=rsa-sha256; cv=none;
	b=bRa6gcnjmZJafFXZWYMMfhH4YMAJ5PeqBSms1XExs4+DrZRL5/e/H5e6a6PPDIZSvhAMYF
	UcVxdN6tpvH1saLAxlFFnjrcfaNe7FN5/FB7TjTXXPVMAVMf+qIQ1PvJKcf+zisvJlQ9NA
	dK+ElPmxERYuDp+ot5ZAf4CgHEYFZMOgBfap/MUyJIzAs4O5v9NEK4kqmMA/qkzWJ5dQEq
	d6YzCIHEm7s5AW3T371z8XbhRV34KBKCz8PTz4VJhamuFSxXC7YGzZR2l3mc9RJ705c5Kw
	FuseGWllQta8dEImKX0nN9h6Gr/vVFYywVqieUDrDIuSQGVeExs0AXC3WgJpTw==
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 4NBW8C0425zSbd
	for ; Tue, 15 Nov 2022 15:59:23 +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 2AFFxMh8074829
	for ; Tue, 15 Nov 2022 15:59:22 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2AFFxMne074828
	for freebsd-arm@FreeBSD.org; Tue, 15 Nov 2022 15:59:22 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 267788] Go testsuite fails in armv7 jail on arm64 host, but not
 on armv7 host
Date: Tue, 15 Nov 2022 15:59:23 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: fuz@fuz.su
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
 bug_file_loc op_sys bug_status bug_severity priority component assigned_to
 reporter cc
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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267788

            Bug ID: 267788
           Summary: Go testsuite fails in armv7 jail on arm64 host, but
                    not on armv7 host
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm64
               URL: https://github.com/golang/go/issues/56729
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: fuz@fuz.su
                CC: cognet@FreeBSD.org, dmgk@freebsd.org

Running the Go 1.19.3 test suite (all.bash in the Go distribution) in an ar=
mv7
jail
on arm64 FreeBSD 13.1 (RPi 4B), I get weird test suite failures.  The same
failures do not occur when testing natively on an armv7 machine (RPi 2B) wi=
th
the same OS version.

Could this be a kernel bug?

--- FAIL: TestDCT (0.06s)
    dct_test.go:78: i=3D35: FDCT
        src
        {
                0x0000, 0x0000, 0x0000, 0x00a6, 0x0000, 0x0000, 0x0064, 0x0=
000,=20
                0x00f4, 0x0000, 0x0044, 0x0046, 0x00ed, 0x0072, 0x0000, 0x0=
000,=20
                0x0000, 0x0000, 0x0096, 0x0000, 0x0000, 0x0000, 0x0038, 0x0=
000,=20
                0x0000, 0x0062, 0x0000, 0x00d3, 0x004e, 0x0000, 0x004b, 0x0=
000,=20
                0x00d0, 0x0000, 0x0000, 0x0000, 0x0000, 0x002b, 0x0000, 0x0=
000,=20
                0x0000, 0x00ec, 0x006a, 0x0023, 0x0000, 0x004b, 0x0063, 0x0=
000,=20
                0x002e, 0x0000, 0x0000, 0x0000, 0x0000, 0x001d, 0x0000, 0x0=
000,=20
                0x0000, 0x0086, 0x0000, 0x0000, 0x00b2, 0x0000, 0x000c, 0x0=
0a4,=20
        }
        got
        {
                0xebd8, 0x0292, 0xfee1, 0x0118, 0x00f2, 0x005c, 0xfe31, 0x0=
052,=20
                0x00fd, 0x00ad, 0xfce9, 0x00fd, 0x01b4, 0x051e, 0x00fc, 0x0=
0a6,=20
                0x0051, 0xfd6f, 0xff67, 0xffe6, 0x022c, 0xfdc6, 0xffb9, 0x0=
106,=20
                0xff7e, 0x0169, 0x0154, 0x013d, 0xfdaf, 0x0298, 0xff94, 0xf=
d54,=20
                0xff9e, 0xfe51, 0x000c, 0xfef1, 0x034c, 0x0071, 0xfcdf, 0xf=
dca,=20
                0xfc5a, 0xfdfe, 0xfdfe, 0xfbda, 0xfdc4, 0x02fc, 0xfd01, 0xf=
d2c,=20
                0xffd4, 0xfea3, 0x007d, 0xfab7, 0xfa7c, 0xfee3, 0xfdb5, 0xf=
fb1,=20
                0xfb03, 0xffc9, 0x02ee, 0x00a8, 0x004f, 0x0262, 0x041b, 0x0=
19a,=20
        }
        want
        {
                0xebd9, 0x0292, 0xfee2, 0x0117, 0x00f2, 0x005c, 0xfe32, 0x0=
052,=20
                0x00fd, 0x00ad, 0xfcea, 0x00fd, 0x01b4, 0x051e, 0x00fc, 0x0=
0a5,=20
                0x0051, 0xfd70, 0xff67, 0xffe7, 0x022c, 0xfdc7, 0xffba, 0x0=
106,=20
                0xff7f, 0x0169, 0x0154, 0x013d, 0xfdb0, 0x0297, 0xff95, 0xf=
d56,=20
                0xff9f, 0xfe52, 0x000c, 0xfef2, 0x034c, 0x0071, 0xfcdf, 0xf=
dcb,=20
                0xfc5b, 0xfdff, 0xfdff, 0xfbdb, 0xfdc5, 0x02fc, 0xfd03, 0xf=
d2d,=20
                0xffd5, 0xfea4, 0xffa3, 0xfab8, 0xfa7d, 0xfee4, 0xfdb7, 0xf=
fb2,=20
                0xfb04, 0xffc9, 0x02ee, 0x00a8, 0x004f, 0x0262, 0x041b, 0x0=
19a,=20
        }
FAIL
FAIL    image/jpeg      26.861s
--- FAIL: TestMUDTracking (0.18s)
    mud_test.go:82: inverse(30) =3D 0.5591381724253374, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5586624103885134, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5469651579616419, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5466046095998363, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5433567836763477, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.532762368527474, not =E2=88=88 [0.277=
34375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5300878709399219, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5170200550184978, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5170200550184978, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5170200550184978, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5107044797157085, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5072570054458773, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5060522326208803, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5060522326208803, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5039603713275813, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.5039244467792984, not =E2=88=88 [0.27=
734375,
0.2783203125)
    mud_test.go:82: inverse(30) =3D 0.4934037493992722, not =E2=88=88 [0.27=
734375,
0.2783203125)
FAIL
FAIL    internal/trace  0.359s
stddev NaN !=3D 73.90083445627211 (allowed error 0.0072168783648703235,
0.005773502691896259)
stddev NaN !=3D 73.90083445627211 (allowed error 0.0072168783648703235,
0.005773502691896259)
stddev NaN !=3D 73.90083445627211 (allowed error 0.0072168783648703235,
0.005773502691896259)
--- FAIL: TestReadUniformity (0.27s)
    rand_test.go:395: stddev NaN !=3D 73.90083445627211 (allowed error
0.0072168783648703235, 0.005773502691896259)
    rand_test.go:395: stddev NaN !=3D 73.90083445627211 (allowed error
0.0072168783648703235, 0.005773502691896259)
    rand_test.go:395: stddev NaN !=3D 73.90083445627211 (allowed error
0.0072168783648703235, 0.005773502691896259)
FAIL
FAIL    math/rand       0.815s
(...)
FAIL    net/http        1080.370s
2022/11/14 14:11:46 http: TLS handshake error from 217.197.83.6:54231: remo=
te
error: tls: bad certificate
2022/11/14 14:11:46 http: TLS handshake error from 217.197.83.6:54238: read=
 tcp
217.197.83.6:54237->217.19
7.83.6:54238: use of closed network connection
--- FAIL: TestServer (0.26s)
    --- FAIL: TestServer/NewTLSServer (0.10s)
        --- FAIL: TestServer/NewTLSServer/ServerClient (0.09s)
            server_test.go:154: Get "https://217.197.83.6:54230": x509:
certificate is valid for 127.0.0.1
, ::1, not 217.197.83.6
    --- FAIL: TestServer/NewTLSServerManual (0.09s)
        --- FAIL: TestServer/NewTLSServerManual/ServerClient (0.09s)
            server_test.go:154: Get "https://217.197.83.6:54237": x509:
certificate is valid for 127.0.0.1
, ::1, not 217.197.83.6
2022/11/14 14:11:46 http: TLS handshake error from 217.197.83.6:54249: remo=
te
error: tls: bad certificate
--- FAIL: TestTLSServerWithHTTP2 (0.13s)
    --- FAIL: TestTLSServerWithHTTP2/http2 (0.12s)
        server_test.go:287: Failed to make request: Get
"https://217.197.83.6:54248": x509: certificate is
 valid for 127.0.0.1, ::1, not 217.197.83.6
2022/11/14 14:11:47 Get "https://217.197.83.6:54256": x509: certificate is
valid for 127.0.0.1, ::1, not 2
17.197.83.6
FAIL    net/http/httptest       0.902s

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Tue Nov 15 21:03:45 2022
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 4NBdvk3C4Tz4hlVj
	for ; Tue, 15 Nov 2022 21:04:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(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 4NBdvj6mTnz4Yhl
	for ; Tue, 15 Nov 2022 21:04:01 +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=1668546238; bh=b0BPngv9XtTF4aLGW0Ror9ZSadkKONnUtJPGDzIgCAI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pG4bs7EmI6M3PZld5zGPD3nZKKNA5lPSUjrk61rtPWTxCkqJ6E74SEmtWMMafHY3CrMKNxfxfUQIW8UA1FcuJDGjoXhQSftrASHyzbKIQqic0FDVtFv5L/k9GMAuA0t6Zrc+RQvMD7oSEsXzIn+UsBCFO2mCSaU3ii+sezJMlDc823x2TzRFxOpLvHJwFl5WIqrpQtgWF3MkvBMrYJ21PXhkZ7yHnWa2Pp8IyWL9d2LWV1HyGbfg91XE9yUX140qYiY2kTsM6Xpp3NmxM4R3IJ2IKAumz7RK8E2Yzmj1owYxpMNcYr+PC/KGVzJwNZlI9Uw1OU4Klrilw4MQqzMeQQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668546238; bh=hrn3+BjcCWwj7n31OSToYQgVBjnpMEE7Wb3BB0BLG9F=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bxnvTtQSaMDmy+ATpJ8F0W5PFgQ8NyT0YrrOybpwDqVAc5keNkahMsK/Cc7u1rf+Vt7hjgD2zYzrTeDLjIxV8XRJYsru4O/cqPfAQT7/zbfe9hbRU6wKCUVwtSGM2ctet6GsKIdHwZLQxaxfvdZ2l/S0XkKAJFlwMyuwTI68cwsOBsXgtt5QikH6hBcyHo8paSclIQqCPlaNTI6P5pbmI1tNY0k2Mnm2MS1iyOyrw60j4X6RgmYszFvltAGuSDN3eNwQce7Cdtkpp7I3VTkdG5Rb6aY+yMfeUmIDvZUBYo8UIBU+A4c63tpijlGb1M67N5mBy9W3zCcx5PAdltz2nQ==
X-YMail-OSG: 1J1MqbsVM1kMCiwtslBAv.M8F8OLKIeloptl8t8W6LsSjXnTVOTvdwpYhdMBjp3
 9Yy_r7EeNZiv8W5dmuc_pnDSIB4_3WIojqoNvIh_sDePuusV30IFPhfFbNgEYrMbXc0DxEj4eUc9
 ASpu1txxSbmfvV9cZSP8_QknXnU_7mImNL7C8wsL3tLoRTMQtZ9cqH9CX_6ckUW85FdzFMqYu5H.
 ZIL56JbWC4UUn6B5QCfa5mKLF9cSs2qSxMiGaC5po2RUQ1SiUE4ymLIkYJwlbet.KjeHxQ_G7ZnR
 3wDVQ3ZigWgX6hpCZRO28CB527b8i9Ge.H3xZi91vA5nTe3vSNrbzflXMgZxqrAbhQWYJ_pwFXvO
 b6PMJeZMbSzD_5q1DLQoDQ3rS1BBTDlZaZ_adNrCl8ji82nC90KoZmXPwhPf6_eivdTrIdG5.nYg
 WLexlVRZuMkgDDHjUfdX0a1qMYE8egcu1pmH8n9fFLNjtUPWJsN38JHnpSvvg8u2dk9bjJFAorue
 ngPds14rH1pESoH2PTtDlDv_Fpn8fhiNPcT9CrzrwEbVhfkoOQ3l15TC.KDShc23JGIRavFEB3PA
 _U4aFmWFYhj0cvKFBC5CnBalo.j6amEbaNOfWGELf_Ry7.6XJEwh9R9HeXCgFV7KGmJy.KBo767C
 W_t38L34.2CVFjgXR2ktx4ZFi55N5zPKt1cJUua2SrisJI7DnnPLOuI2C2ecurjExpqu6.N9c5bV
 Rnb9mEVHTz4tfAce6JerefZDHK.2_dv_DWcXUyxyjHVPpobclYB3ySmd6KYR9NMaEIZPWnWL5lcd
 Ke1YOJuoIHe4cpJKNLiC2_45IAFMcNReGvb2S7zgghSEocjuAdlDOgqPlNZXXIg.eZ64xcVD4Kc1
 kdyx8g1KEUw9GQwDl4DSU56A5nMXADylVNu0H4XkcAqdkPsWifCUQFqZF7OOtSIB8yPFZBNr2xY9
 oDz3QuSbjWtXv2o6pzjqQlivI5EcyqzFdsqXysR9eO_HvgjJNWvqFnzu9yn0lNx6BbyD_QbrWQG6
 GHraplZ0uvP0XiFOyYM0JXC.OETgH0wIDr3oOPip9mqctYH2rpeVe1kEob9ntXtxIqhiVzk4ozLO
 ITutlp.rQmnjCDUZNthr_5_1lOr13lrwPT830FcVpdtbQ8uMbrgRbPfyK._9YVMg5crOG6n8KPmc
 apcAuCfb6yS28wllQqNqOusJbwz6hftlmLkzGfHSbVqIouQvRRQ5hhH92.FHzSVvnsNuRz79ViJm
 tsAN._27ZhoEOKoyKVL1ZCXH.z7wKcrFYamRZFYSx1XiwgS2zQ4XzkXEmSkxaDdbOKZhlok5vlpb
 UdxvLV3bu8A3oa.X8097UbqSfx0f8PBfepXNHpodyYctPxnwjlzrV9BoZFsb9Zty2qlmWsNDdldm
 1qrZykG_Ryic_R2NvuIl3Z_5ryi6b0kM5tpAgA28TMT5sUKHylGn65cXkdhB7y4vlYZkd_2Tm5KQ
 QkUSC1hczxupkiD0Y_NPKSHziaLqstDXO0hum.WfV40iD6RVod0PnPF.BgFNEUTs1v_yrI8MwM58
 DEDUE24bsX4ggluOGbgJ.2SJhn8UXOdeiavRmwVi34V3IOF1vcIL1ok_KguujVvlxjnUSzR42M2l
 zQGlYwXssupTp4X3uo_3CUEvA6lzuWnoikq7TRQvyqSWb1wbbUWyo5lV4zpHd4nY2EXfGwhm2p.o
 K2KWQqlTEcu1flJKbgx30PDOH2GgmheFC1N3QrBtcNRdKisn4i5QAs4PtqRCGoWr9p20lLnQJjM9
 AOC5XbYkEjnjY1GHZrvuUuCOH4EVSyFBu78acatNpdNPw40.BnbEQynLIUJRD1M7vG_hkX_arUnn
 te1XkAHJ8oTE_wkbTV7QvFbHJhTsyOfDz6K_VVN8BYwufpGekGUI0.VemM_j0E3idRLGewDT6L2l
 6Yez_jwohUIpASmOn4goSSXFprqDmUX74JTxLiO8d8XBEaipJayvGFrBdlRsljn.VjzPSUPTzH4j
 S3fxfziWnkGvrbNA3MhphlfccR.NZuXEgdzW4uwY9WxodjyyRHxgn9v0B6mGkGKVl1XGvqJvEQ9n
 6IwveT4WGbhIyD9J6WczaX.P_1lwUAvDARZdkycKIP_nL1_QGCGMJkECFuxCOyzwni9KISjx.21m
 QAr5BpiGBy8gOF2.u7OLnUnQPyxrj0_1sL63rL36k5v7zLHhCgYJlRG80jFAn09pwSjB9.uPM1Sp
 9LZUmBThK1Xu84e7VDDx7FsVbE6J4gm0kx09NLtTGG0v8JAFWXdJGj_qV92T81X3wMDqoscCa1Gv
 GAw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Nov 2022 21:03:58 +0000
Received: by hermes--production-gq1-579bc4bddd-56gsn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1160cb9aa9fdd54d9394dc7791c21e82;
          Tue, 15 Nov 2022 21:03:56 +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.200.110.1.12\))
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
From: Mark Millard 
In-Reply-To: <20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
Date: Tue, 15 Nov 2022 13:03:45 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <041B0111-7D71-4FBF-B661-E03F2CCD7D9A@yahoo.com>
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
 <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
 
 <20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
To: Emmanuel Vadot 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NBdvj6mTnz4Yhl
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Nov 15, 2022, at 05:05, Emmanuel Vadot  wrote:

> On Fri, 4 Nov 2022 12:31:51 -0700
> Mark Millard  wrote:
>=20
>> On 2022-Oct-22, at 23:00, Mark Millard  wrote:
>>=20
>>> Well, turns out that part of the "Import device-tree files
>>> from Linux 5.14" is:
>>>=20
>>> =
https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rock=
chip/rk3328-rock64.dts?id=3D5956d97f4b32
>>>=20
>>> which has:
>>>=20
>>> diff --git =
a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts =
b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
>>> index 3bef1f39bc6e..1b0f7e4551ea 100644
>>> --- a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
>>> +++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
>>> @@ -381,6 +381,11 @@
>>> status =3D "okay";
>>> };
>>>=20
>>> +&usbdrd3 {
>>> + dr_mode =3D "host";
>>> + status =3D "okay";
>>> +};
>>> +
>>> &usb_host0_ehci {
>>> status =3D "okay";
>>> };
>>>=20
>>> usbdrd3 is for USB3, so "host" now has a sort of dtb change
>>> in the interfacing for supporting host-mode USB3. The old:
>>>=20
>>> /usr/main-src/sys/dts/arm64/overlays/rk3328-dwc3.dtso
>>>=20
>>> has, in part:
>>>=20
>>>       usbdrd3: usb@ff600000 {
>>>               compatible =3D "rockchip,rk3328-dwc3";
>>>               clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
>>>                        <&cru ACLK_USB3OTG>;
>>>               clock-names =3D "ref_clk", "suspend_clk",
>>>                             "bus_clk";
>>>               #address-cells =3D <2>;
>>>               #size-cells =3D <2>;
>>>               ranges;
>>>               status =3D "okay";
>>>=20
>>>               usbdrd_dwc3: dwc3@ff600000 {
>>>                       compatible =3D "snps,dwc3";
>>>                       reg =3D <0x0 0xff600000 0x0 0x100000>;
>>>                       interrupts =3D ;
>>>                       dr_mode =3D "host";
>>>                       phy_type =3D "utmi_wide";
>>>                       snps,dis_enblslpm_quirk;
>>>                       snps,dis-u2-freeclk-exists-quirk;
>>>                       snps,dis_u2_susphy_quirk;
>>>                       snps,dis_u3_susphy_quirk;
>>>                       snps,dis-del-phy-power-chg-quirk;
>>>                       snps,dis-tx-ipgap-linecheck-quirk;
>>>                       status =3D "okay";
>>>               };
>>>       };
>>>=20
>>> which looks to me to likely now conflict with the below --given
>>> the added "host" usage as of 5.14 reported above:
>>>=20
>>> /usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328.dtsi
>>>=20
>>> that, as of the 5.13 import, has:
>>>=20
>>>       usbdrd3: usb@ff600000 {
>>>               compatible =3D "rockchip,rk3328-dwc3", "snps,dwc3";
>>>               reg =3D <0x0 0xff600000 0x0 0x100000>;
>>>               interrupts =3D ;
>>>               clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
>>>                        <&cru ACLK_USB3OTG>;
>>>               clock-names =3D "ref_clk", "suspend_clk",
>>>                             "bus_clk";
>>>               dr_mode =3D "otg";
>>>               phy_type =3D "utmi_wide";
>>>               snps,dis-del-phy-power-chg-quirk;
>>>               snps,dis_enblslpm_quirk;
>>>               snps,dis-tx-ipgap-linecheck-quirk;
>>>               snps,dis-u2-freeclk-exists-quirk;
>>>               snps,dis_u2_susphy_quirk;
>>>               snps,dis_u3_susphy_quirk;
>>>               status =3D "disabled";
>>>       };
>>>=20
>>> My guess would be that some kernel changes are required
>>> in order to track this structural changes, not just
>>> avoiding the old .dtbo . Testing showed that disabling
>>> the load of the .dtbo was insufficient to fix things.
>>=20
>> FYI:
>>=20
>> The mainline Linux commit that addeed usbdrd3 to
>> arch/arm64/boot/dts/rockchip/rk3328.dtsi is the
>> following from 2021-03-24:
>>=20
>> =
https://github.com/torvalds/linux/commit/44dd5e2106dc2fd01697b539085818d1d=
1c58df0
>>=20
>> The mainline Linux commit that added the enabling of
>> the USB3 host mode in
>> arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
>> is the following from 2021-05-01:
>>=20
>> =
https://github.com/torvalds/linux/commit/bbac8bd65f5402281cb7b0452c1c5f367=
387b459
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>=20
>>=20
>=20
> Hi Mark,
>=20
> See https://reviews.freebsd.org/D37392 (and child reviews) for a fix.
> This was indeed the import of the new DTS files that caused the first
> problem (there is no glue node in rk3328.dtsi like in other SoCs or
> like our overlay). The other commit responsible for breaking USB3
> support was the addition to RK356x SoC, the check was bad for when to
> force USB2.

Thanks.

I applied the diff and the 2 child diff's and rebuilt and
installed, including updating the kernel on the e.MMC that
is historically used to mount the rootfs on USB3 when the
USB3 drive is plugged in there. (U-boot does not handle
the USB context I want.)

Unfortunately, the kernel still only manages to find the
rootfs when plugged into USB2 instead of USB3.

I do not see any references to dwc3 in the console log.
There are references to EHCI and OHCI but not XHCI.
There is:

usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0

but nothing for the USB3 rate.

I do have the old rk3328-dwc3.dtbo reference commented out
in /boot/loader.conf :

#fdt_overlays=3D"rk3328-dwc3.dtbo"

The context was (long output line split for readability):

# uname -apKU
FreeBSD RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #48
main-n259064-f83db6441a2f-dirty: Tue Nov 15 10:19:44 PST 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53
arm64 aarch64 1400073 1400073

(Shown from a USB2 based boot.)

The Console output from ---<>--- on for the failure was:

---<>---
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 =
compliance
Copyright (c) 1992-2022 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-CURRENT #48 main-n259064-f83db6441a2f-dirty: Tue Nov 15 =
10:19:44 PST 2022
    =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA53 arm64
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
VT: init without driver.
module firmware already present!
real memory  =3D 4276092928 (4078 MB)
avail memory =3D 4145885184 (3953 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
MAP fbf17000 mode 2 pages 1
MAP fbf1b000 mode 2 pages 1
MAP fbf1d000 mode 2 pages 2
MAP fbf20000 mode 2 pages 4
MAP fef30000 mode 2 pages 16
kbd0 at kbdmux0
ofwbus0: 
clk_fixed0:  on ofwbus0
rk_grf0:  mem 0xff100000-0xff100fff on =
ofwbus0
rk3328_cru0:  mem =
0xff440000-0xff440fff on ofwbus0
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
Cannot set frequency for clk: aclk_bus_pre_c, error: 34
rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
Cannot set frequency for clk: aclk_peri_pre, error: 34
rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9
clk_fixed1:  on ofwbus0
regfix0:  on ofwbus0
regfix1:  on ofwbus0
regfix2:  on ofwbus0
regfix3:  on ofwbus0
simple_mfd0:  mem =
0xff450000-0xff45ffff on ofwbus0
psci0:  on ofwbus0
gic0:  mem =
0xff811000-0xff811fff,0xff812000-0xff813fff,0xff814000-0xff815fff,0xff8160=
00-0xff817fff irq 52 on ofwbus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 160
rk_pinctrl0:  on ofwbus0
gpio0:  mem 0xff210000-0xff2100ff irq 53 =
on rk_pinctrl0
gpiobus0:  on gpio0
gpio1:  mem 0xff220000-0xff2200ff irq 54 =
on rk_pinctrl0
gpiobus1:  on gpio1
gpio2:  mem 0xff230000-0xff2300ff irq 55 =
on rk_pinctrl0
gpiobus2:  on gpio2
gpio3:  mem 0xff240000-0xff2400ff irq 56 =
on rk_pinctrl0
gpiobus3:  on gpio3
rk_i2c0:  mem 0xff160000-0xff160fff irq 16 on ofwbus0
iicbus0:  on rk_i2c0
rk805_pmu0:  at addr 0x30 irq 57 on iicbus0
generic_timer0:  irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
rk_tsadc0:  mem 0xff250000-0xff2500ff irq =
24 on ofwbus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
cpufreq_dt0:  on cpu0
cpufreq_dt0: Found cpu-supply
cpu1:  on cpulist0
cpufreq_dt1:  on cpu1
cpufreq_dt1: Found cpu-supply
cpu2:  on cpulist0
cpufreq_dt2:  on cpu2
cpufreq_dt2: Found cpu-supply
cpu3:  on cpulist0
cpufreq_dt3:  on cpu3
cpufreq_dt3: Found cpu-supply
pcm0:  on ofwbus0
pmu0:  irq 0,1,2,3 on ofwbus0
pcm1:  on ofwbus0
i2s0:  mem 0xff000000-0xff000fff irq 8 on ofwbus0
Cannot set frequency for clk: xin12m, error: 34
Cannot set frequency for clk: xin12m, error: 34
i2s1:  mem 0xff010000-0xff010fff irq 9 on ofwbus0
Cannot set frequency for clk: clkin_i2s1, error: 34
Cannot set frequency for clk: xin12m, error: 34
uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on ofwbus0
uart0: console (1500000,n,8,1)
iic0:  on iicbus0
spi0:  mem 0xff190000-0xff190fff irq 19 on ofwbus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
rockchip_dwmmc0:  mem 0xff500000-0xff503fff irq 43 on ofwbus0
rockchip_dwmmc0: Hardware version ID is 270a
rockchip_dwmmc1:  mem 0xff520000-0xff523fff irq 45 on ofwbus0
rockchip_dwmmc1: Hardware version ID is 270a
mmc0:  on rockchip_dwmmc1
dwc0:  mem 0xff540000-0xff54ffff =
irq 46 on ofwbus0
miibus0:  on dwc0
rgephy0:  PHY 0 on =
miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
rgephy1:  PHY 1 on =
miibus0
rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
1000baseT-FDX, 1000baseT-FDX-master, auto
dwc0: Ethernet address: d2:64:d7:54:db:8c
ehci0:  mem 0xff5c0000-0xff5cffff irq 48 on =
ofwbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
ohci0:  mem 0xff5d0000-0xff5dffff irq 49 on =
ofwbus0
usbus1 on ohci0
dwcotg0:  mem =
0xff580000-0xff5bffff irq 51 on ofwbus0
usbus3 on dwcotg0
gpioc0:  on gpio0
gpioc1:  on gpio1
gpioc2:  on gpio2
gpioc3:  on gpio3
gpioled0:  on ofwbus0
gpioled0:  failed to map pin
gpioled0:  failed to map pin
pcm2:  on ofwbus0
armv8crypto0: 
Timecounters tick every 1.000 msec
rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s
pcm0: no driver attached to codec node
pcm1: no driver attached to codec node
usbus0: 480Mbps High Speed USB v2.0
usbus1: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub0 on usbus0
uhub0:  on =
usbus0
ugen3.1:  at usbus3
uhub1 on usbus3
uhub1:  on usbus3
ugen1.1:  at usbus1
uhub2 on usbus1
uhub2:  on =
usbus1
mmcsd0: 125GB  at =
mmc0 52.0MHz/8bit/1016-block
mmcsd0boot0: 4MB partition 1 at mmcsd0
mmcsd0boot1: 4MB partition 2 at mmcsd0
mmcsd0rpmb: 4MB partition 3 at mmcsd0
pcm2: no driver attached to cpu node
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
                   Cache Type =3D <64 byte D-cacheline,64 byte =
I-cacheline,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
Unresolved linked clock found: hdmi_phy
Unresolved linked clock found: usb480m_phy
Trying to mount root from ufs:/dev/gpt/Rock64root []...
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Mounting from ufs:/dev/gpt/Rock64root failed with error 22; retrying for =
3 more seconds
Mounting from ufs:/dev/gpt/Rock64root failed with error 22: Invalid =
fstype.


For reference for the patching I applied (whitespace
details may not be preserved):

# git -C /usr/main-src/ diff sys/dev/usb/controller/ sys/arm64/rockchip/
diff --git a/sys/arm64/rockchip/rk_dwc3.c b/sys/arm64/rockchip/rk_dwc3.c
index 8582f7a86999..645a1cffbd95 100644
--- a/sys/arm64/rockchip/rk_dwc3.c
+++ b/sys/arm64/rockchip/rk_dwc3.c
@@ -54,12 +54,10 @@ __FBSDID("$FreeBSD$");
 #include 
   enum rk_dwc3_type {
-       RK3328 =3D 1,
-       RK3399,
+       RK3399 =3D 1,
 };
   static struct ofw_compat_data compat_data[] =3D {
-       { "rockchip,rk3328-dwc3",       RK3328 },
        { "rockchip,rk3399-dwc3",       RK3399 },
        { NULL,                         0 }
 };
diff --git a/sys/dev/usb/controller/dwc3.c =
b/sys/dev/usb/controller/dwc3.c
index 2e8f868bc47b..40405927685e 100644
--- a/sys/dev/usb/controller/dwc3.c
+++ b/sys/dev/usb/controller/dwc3.c
@@ -86,6 +86,14 @@ struct snps_dwc3_softc {
        bus_space_tag_t         bst;
        bus_space_handle_t      bsh;
        uint32_t                snpsid;
+       uint32_t                snpsversion;
+       uint32_t                snpsrevision;
+       uint32_t                snpsversion_type;
+#ifdef FDT
+       clk_t                   clk_ref;
+       clk_t                   clk_suspend;
+       clk_t                   clk_bus;
+#endif
 };
   #define        DWC3_WRITE(_sc, _off, _val)             \
@@ -384,8 +392,31 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        sc->bsh =3D rman_get_bushandle(sc->mem_res);
          sc->snpsid =3D DWC3_READ(sc, DWC3_GSNPSID);
-       if (bootverbose)
-               device_printf(sc->dev, "snps id: %#012x\n", sc->snpsid);
+       sc->snpsversion =3D DWC3_VERSION(sc->snpsid);
+       sc->snpsrevision =3D DWC3_REVISION(sc->snpsid);
+       if (sc->snpsversion =3D=3D DWC3_1_IP_ID ||
+           sc->snpsversion =3D=3D DWC3_2_IP_ID) {
+               sc->snpsrevision =3D DWC3_READ(sc, DWC3_1_VER_NUMBER);
+               sc->snpsversion_type =3D DWC3_READ(sc, DWC3_1_VER_TYPE);
+       }
+       if (bootverbose) {
+               switch (sc->snpsversion) {
+               case DWC3_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3 (%x =
%x)\n",
+                           sc->snpsversion, sc->snpsrevision);
+                       break;
+               case DWC3_1_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3.1 (%x =
%x %x)\n",
+                           sc->snpsversion, sc->snpsrevision,
+                           sc->snpsversion_type);
+                       break;
+               case DWC3_2_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3.2 (%x =
%x %x)\n",
+                           sc->snpsversion, sc->snpsrevision,
+                           sc->snpsversion_type);
+                       break;
+               }
+       }
 #ifdef DWC3_DEBUG
        snps_dwc3_dump_ctrlparams(sc);
 #endif
@@ -394,9 +425,32 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        if (!is_fdt)
                goto skip_phys;
  -       /* Get the phys */
        node =3D ofw_bus_get_node(dev);
  +       /* Get the clocks if any */
+       if (ofw_bus_is_compatible(dev, "rockchip,rk3328-dwc3") =3D=3D 1) =
{
+               if (clk_get_by_ofw_name(dev, node, "ref_clk", =
&sc->clk_ref) !=3D 0)
+                       device_printf(dev, "Cannot get ref_clk\n");
+               if (clk_get_by_ofw_name(dev, node, "suspend_clk", =
&sc->clk_suspend) !=3D 0)
+                       device_printf(dev, "Cannot get suspend_clk\n");
+               if (clk_get_by_ofw_name(dev, node, "bus_clk", =
&sc->clk_bus) !=3D 0)
+                       device_printf(dev, "Cannot get bus_clk\n");
+       }
+
+       if (sc->clk_ref !=3D NULL) {
+               if (clk_enable(sc->clk_ref) !=3D 0)
+                       device_printf(dev, "Cannot enable ref_clk\n");
+       }
+       if (sc->clk_suspend !=3D NULL) {
+               if (clk_enable(sc->clk_suspend) !=3D 0)
+                       device_printf(dev, "Cannot enable =
suspend_clk\n");
+       }
+       if (sc->clk_bus !=3D NULL) {
+               if (clk_enable(sc->clk_bus) !=3D 0)
+                       device_printf(dev, "Cannot enable bus_clk\n");
+       }
+
+       /* Get the phys */
        usb2_phy =3D usb3_phy =3D NULL;
        error =3D phy_get_by_ofw_name(dev, node, "usb2-phy", &usb2_phy);
        if (error =3D=3D 0 && usb2_phy !=3D NULL)
@@ -427,6 +481,16 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        snsp_dwc3_dump_regs(sc, "Post XHCI init");
 #endif
  +#ifdef FDT
+       if (error) {
+               if (sc->clk_ref !=3D NULL)
+                       clk_disable(sc->clk_ref);
+               if (sc->clk_suspend !=3D NULL)
+                       clk_disable(sc->clk_suspend);
+               if (sc->clk_bus !=3D NULL)
+                       clk_disable(sc->clk_bus);
+       }
+#endif
        return (error);
 }
  diff --git a/sys/dev/usb/controller/dwc3.h =
b/sys/dev/usb/controller/dwc3.h
index 21a87a1917ee..c69672072209 100644
--- a/sys/dev/usb/controller/dwc3.h
+++ b/sys/dev/usb/controller/dwc3.h
@@ -31,6 +31,15 @@
 #ifndef _DWC3_H_
 #define        _DWC3_H_
  +#define        DWC3_IP_ID              0x5533
+#define        DWC3_1_IP_ID            0x3331
+#define        DWC3_2_IP_ID            0x3332
+
+#define        DWC3_VERSION_MASK       0xFFFF0000
+#define        DWC3_REVISION_MASK      0xFFFF
+#define        DWC3_VERSION(x)         (((x) & DWC3_VERSION_MASK) >> =
16)
+#define        DWC3_REVISION(x)        ((x) & DWC3_REVISION_MASK)
+
 #define        DWC3_GSBUSCFG0          0xc100
 #define        DWC3_GSBUSCFG1          0xc104
 #define        DWC3_GTXTHRCFG          0xc108
@@ -80,6 +89,9 @@
 #define        DWC3_GPRTBIMAP_HSLO     0xc180
 #define        DWC3_GPRTBIMAP_FSLO     0xc188
  +#define        DWC3_1_VER_NUMBER       0xc1a0
+#define        DWC3_1_VER_TYPE         0xc1a4
+
 #define        DWC3_GUSB2PHYCFG0       0xc200
 #define         DWC3_GUSB2PHYCFG0_PHYSOFTRST           (1 << 31)
 #define         DWC3_GUSB2PHYCFG0_U2_FREECLK_EXISTS    (1 << 30)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Nov 15 21:12:36 2022
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 4NBf5k5GJlz4hm5y
	for ; Tue, 15 Nov 2022 21:12:42 +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 4NBf5k12BQz4ZLL
	for ; Tue, 15 Nov 2022 21:12:42 +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=1668546760;
	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=rt+9xBZ/PxledRI8P3v1ErhUSpp3RXRL/DKnzu28wTM=;
	b=RHChxpTqhZqYwdZPALx6k+8fst01WamTehRMwbWGGAOJk6ay+QUwupbWr9RN2hOFuPcaDT
	1IKtwTCsDNgSOLFxbaxMgTD4lXQtH953KGDLIE3Ordxg8w4UO6npQBCRKbk8fGf/Ldu69M
	FdAn+rNC9dLuUsUavUr8MFg4RT6AcgY=
Received: from amy.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 79629b5a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 15 Nov 2022 21:12:39 +0000 (UTC)
Date: Tue, 15 Nov 2022 22:12:36 +0100
From: Emmanuel Vadot 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
Message-Id: <20221115221236.6c93f74861e2e58f3aa5a2e9@bidouilliste.com>
In-Reply-To: <041B0111-7D71-4FBF-B661-E03F2CCD7D9A@yahoo.com>
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
	<665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
	
	<20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
	<041B0111-7D71-4FBF-B661-E03F2CCD7D9A@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: 4NBf5k12BQz4ZLL
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 15 Nov 2022 13:03:45 -0800
Mark Millard  wrote:

> On Nov 15, 2022, at 05:05, Emmanuel Vadot  wrote:
> 
> > On Fri, 4 Nov 2022 12:31:51 -0700
> > Mark Millard  wrote:
> > 
> >> On 2022-Oct-22, at 23:00, Mark Millard  wrote:
> >> 
> >>> Well, turns out that part of the "Import device-tree files
> >>> from Linux 5.14" is:
> >>> 
> >>> https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts?id=5956d97f4b32
> >>> 
> >>> which has:
> >>> 
> >>> diff --git a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> >>> index 3bef1f39bc6e..1b0f7e4551ea 100644
> >>> --- a/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> >>> +++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts
> >>> @@ -381,6 +381,11 @@
> >>> status = "okay";
> >>> };
> >>> 
> >>> +&usbdrd3 {
> >>> + dr_mode = "host";
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> &usb_host0_ehci {
> >>> status = "okay";
> >>> };
> >>> 
> >>> usbdrd3 is for USB3, so "host" now has a sort of dtb change
> >>> in the interfacing for supporting host-mode USB3. The old:
> >>> 
> >>> /usr/main-src/sys/dts/arm64/overlays/rk3328-dwc3.dtso
> >>> 
> >>> has, in part:
> >>> 
> >>>       usbdrd3: usb@ff600000 {
> >>>               compatible = "rockchip,rk3328-dwc3";
> >>>               clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
> >>>                        <&cru ACLK_USB3OTG>;
> >>>               clock-names = "ref_clk", "suspend_clk",
> >>>                             "bus_clk";
> >>>               #address-cells = <2>;
> >>>               #size-cells = <2>;
> >>>               ranges;
> >>>               status = "okay";
> >>> 
> >>>               usbdrd_dwc3: dwc3@ff600000 {
> >>>                       compatible = "snps,dwc3";
> >>>                       reg = <0x0 0xff600000 0x0 0x100000>;
> >>>                       interrupts = ;
> >>>                       dr_mode = "host";
> >>>                       phy_type = "utmi_wide";
> >>>                       snps,dis_enblslpm_quirk;
> >>>                       snps,dis-u2-freeclk-exists-quirk;
> >>>                       snps,dis_u2_susphy_quirk;
> >>>                       snps,dis_u3_susphy_quirk;
> >>>                       snps,dis-del-phy-power-chg-quirk;
> >>>                       snps,dis-tx-ipgap-linecheck-quirk;
> >>>                       status = "okay";
> >>>               };
> >>>       };
> >>> 
> >>> which looks to me to likely now conflict with the below --given
> >>> the added "host" usage as of 5.14 reported above:
> >>> 
> >>> /usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328.dtsi
> >>> 
> >>> that, as of the 5.13 import, has:
> >>> 
> >>>       usbdrd3: usb@ff600000 {
> >>>               compatible = "rockchip,rk3328-dwc3", "snps,dwc3";
> >>>               reg = <0x0 0xff600000 0x0 0x100000>;
> >>>               interrupts = ;
> >>>               clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
> >>>                        <&cru ACLK_USB3OTG>;
> >>>               clock-names = "ref_clk", "suspend_clk",
> >>>                             "bus_clk";
> >>>               dr_mode = "otg";
> >>>               phy_type = "utmi_wide";
> >>>               snps,dis-del-phy-power-chg-quirk;
> >>>               snps,dis_enblslpm_quirk;
> >>>               snps,dis-tx-ipgap-linecheck-quirk;
> >>>               snps,dis-u2-freeclk-exists-quirk;
> >>>               snps,dis_u2_susphy_quirk;
> >>>               snps,dis_u3_susphy_quirk;
> >>>               status = "disabled";
> >>>       };
> >>> 
> >>> My guess would be that some kernel changes are required
> >>> in order to track this structural changes, not just
> >>> avoiding the old .dtbo . Testing showed that disabling
> >>> the load of the .dtbo was insufficient to fix things.
> >> 
> >> FYI:
> >> 
> >> The mainline Linux commit that addeed usbdrd3 to
> >> arch/arm64/boot/dts/rockchip/rk3328.dtsi is the
> >> following from 2021-03-24:
> >> 
> >> https://github.com/torvalds/linux/commit/44dd5e2106dc2fd01697b539085818d1d1c58df0
> >> 
> >> The mainline Linux commit that added the enabling of
> >> the USB3 host mode in
> >> arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> >> is the following from 2021-05-01:
> >> 
> >> https://github.com/torvalds/linux/commit/bbac8bd65f5402281cb7b0452c1c5f367387b459
> >> 
> >> ===
> >> Mark Millard
> >> marklmi at yahoo.com
> >> 
> >> 
> > 
> > Hi Mark,
> > 
> > See https://reviews.freebsd.org/D37392 (and child reviews) for a fix.
> > This was indeed the import of the new DTS files that caused the first
> > problem (there is no glue node in rk3328.dtsi like in other SoCs or
> > like our overlay). The other commit responsible for breaking USB3
> > support was the addition to RK356x SoC, the check was bad for when to
> > force USB2.
> 
> Thanks.
> 
> I applied the diff and the 2 child diff's and rebuilt and
> installed, including updating the kernel on the e.MMC that
> is historically used to mount the rootfs on USB3 when the
> USB3 drive is plugged in there. (U-boot does not handle
> the USB context I want.)
> 
> Unfortunately, the kernel still only manages to find the
> rootfs when plugged into USB2 instead of USB3.
> 
> I do not see any references to dwc3 in the console log.
> There are references to EHCI and OHCI but not XHCI.
> There is:
> 
> usbus0: 480Mbps High Speed USB v2.0
> usbus1: 12Mbps Full Speed USB v1.0
> usbus3: 480Mbps High Speed USB v2.0
> 
> but nothing for the USB3 rate.
> 
> I do have the old rk3328-dwc3.dtbo reference commented out
> in /boot/loader.conf :
> 
> #fdt_overlays="rk3328-dwc3.dtbo"
> 
> The context was (long output line split for readability):
> 
> # uname -apKU
> FreeBSD RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #48
> main-n259064-f83db6441a2f-dirty: Tue Nov 15 10:19:44 PST 2022
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA53
> arm64 aarch64 1400073 1400073
> 
> (Shown from a USB2 based boot.)
> 
> The Console output from ---<>--- on for the failure was:
> 
> ---<>---
> 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 compliance
> Copyright (c) 1992-2022 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-CURRENT #48 main-n259064-f83db6441a2f-dirty: Tue Nov 15 10:19:44 PST 2022
>     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA53 arm64
> FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
> VT: init without driver.
> module firmware already present!
> real memory  = 4276092928 (4078 MB)
> avail memory = 4145885184 (3953 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
> MAP fbf17000 mode 2 pages 1
> MAP fbf1b000 mode 2 pages 1
> MAP fbf1d000 mode 2 pages 2
> MAP fbf20000 mode 2 pages 4
> MAP fef30000 mode 2 pages 16
> kbd0 at kbdmux0
> ofwbus0: 
> clk_fixed0:  on ofwbus0
> rk_grf0:  mem 0xff100000-0xff100fff on ofwbus0
> rk3328_cru0:  mem 0xff440000-0xff440fff on ofwbus0
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> Cannot set frequency for clk: aclk_bus_pre_c, error: 34
> rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> Cannot set frequency for clk: aclk_peri_pre, error: 34
> rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9
> clk_fixed1:  on ofwbus0
> regfix0:  on ofwbus0
> regfix1:  on ofwbus0
> regfix2:  on ofwbus0
> regfix3:  on ofwbus0
> simple_mfd0:  mem 0xff450000-0xff45ffff on ofwbus0
> psci0:  on ofwbus0
> gic0:  mem 0xff811000-0xff811fff,0xff812000-0xff813fff,0xff814000-0xff815fff,0xff816000-0xff817fff irq 52 on ofwbus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 160
> rk_pinctrl0:  on ofwbus0
> gpio0:  mem 0xff210000-0xff2100ff irq 53 on rk_pinctrl0
> gpiobus0:  on gpio0
> gpio1:  mem 0xff220000-0xff2200ff irq 54 on rk_pinctrl0
> gpiobus1:  on gpio1
> gpio2:  mem 0xff230000-0xff2300ff irq 55 on rk_pinctrl0
> gpiobus2:  on gpio2
> gpio3:  mem 0xff240000-0xff2400ff irq 56 on rk_pinctrl0
> gpiobus3:  on gpio3
> rk_i2c0:  mem 0xff160000-0xff160fff irq 16 on ofwbus0
> iicbus0:  on rk_i2c0
> rk805_pmu0:  at addr 0x30 irq 57 on iicbus0
> generic_timer0:  irq 4,5,6,7 on ofwbus0
> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000
> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000
> rk_tsadc0:  mem 0xff250000-0xff2500ff irq 24 on ofwbus0
> cpulist0:  on ofwbus0
> cpu0:  on cpulist0
> cpufreq_dt0:  on cpu0
> cpufreq_dt0: Found cpu-supply
> cpu1:  on cpulist0
> cpufreq_dt1:  on cpu1
> cpufreq_dt1: Found cpu-supply
> cpu2:  on cpulist0
> cpufreq_dt2:  on cpu2
> cpufreq_dt2: Found cpu-supply
> cpu3:  on cpulist0
> cpufreq_dt3:  on cpu3
> cpufreq_dt3: Found cpu-supply
> pcm0:  on ofwbus0
> pmu0:  irq 0,1,2,3 on ofwbus0
> pcm1:  on ofwbus0
> i2s0:  mem 0xff000000-0xff000fff irq 8 on ofwbus0
> Cannot set frequency for clk: xin12m, error: 34
> Cannot set frequency for clk: xin12m, error: 34
> i2s1:  mem 0xff010000-0xff010fff irq 9 on ofwbus0
> Cannot set frequency for clk: clkin_i2s1, error: 34
> Cannot set frequency for clk: xin12m, error: 34
> uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on ofwbus0
> uart0: console (1500000,n,8,1)
> iic0:  on iicbus0
> spi0:  mem 0xff190000-0xff190fff irq 19 on ofwbus0
> spibus0:  on spi0
> spibus0:  at cs 0 mode 0
> rockchip_dwmmc0:  mem 0xff500000-0xff503fff irq 43 on ofwbus0
> rockchip_dwmmc0: Hardware version ID is 270a
> rockchip_dwmmc1:  mem 0xff520000-0xff523fff irq 45 on ofwbus0
> rockchip_dwmmc1: Hardware version ID is 270a
> mmc0:  on rockchip_dwmmc1
> dwc0:  mem 0xff540000-0xff54ffff irq 46 on ofwbus0
> miibus0:  on dwc0
> rgephy0:  PHY 0 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
> rgephy1:  PHY 1 on miibus0
> rgephy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
> dwc0: Ethernet address: d2:64:d7:54:db:8c
> ehci0:  mem 0xff5c0000-0xff5cffff irq 48 on ofwbus0
> usbus0: EHCI version 1.0
> usbus0 on ehci0
> ohci0:  mem 0xff5d0000-0xff5dffff irq 49 on ofwbus0
> usbus1 on ohci0
> dwcotg0:  mem 0xff580000-0xff5bffff irq 51 on ofwbus0
> usbus3 on dwcotg0
> gpioc0:  on gpio0
> gpioc1:  on gpio1
> gpioc2:  on gpio2
> gpioc3:  on gpio3
> gpioled0:  on ofwbus0
> gpioled0:  failed to map pin
> gpioled0:  failed to map pin
> pcm2:  on ofwbus0
> armv8crypto0: 
> Timecounters tick every 1.000 msec
> rk805_pmu0: registered as a time-of-day clock, resolution 1.000000s
> pcm0: no driver attached to codec node
> pcm1: no driver attached to codec node
> usbus0: 480Mbps High Speed USB v2.0
> usbus1: 12Mbps Full Speed USB v1.0
> usbus3: 480Mbps High Speed USB v2.0
> ugen0.1:  at usbus0
> uhub0 on usbus0
> uhub0:  on usbus0
> ugen3.1:  at usbus3
> uhub1 on usbus3
> uhub1:  on usbus3
> ugen1.1:  at usbus1
> uhub2 on usbus1
> uhub2:  on usbus1
> mmcsd0: 125GB  at mmc0 52.0MHz/8bit/1016-block
> mmcsd0boot0: 4MB partition 1 at mmcsd0
> mmcsd0boot1: 4MB partition 2 at mmcsd0
> mmcsd0rpmb: 4MB partition 3 at mmcsd0
> pcm2: no driver attached to cpu node
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>                    Cache Type = <64 byte D-cacheline,64 byte I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG>
>  Instruction Set Attributes 0 = 
>  Instruction Set Attributes 1 = <>
>  Instruction Set Attributes 2 = <>
>          Processor Features 0 = 
>          Processor Features 1 = <>
>       Memory Model Features 0 = 
>       Memory Model Features 1 = <8bit VMID>
>       Memory Model Features 2 = <32bit CCIDX,48bit VA>
>              Debug Features 0 = 
>              Debug Features 1 = <>
>          Auxiliary Features 0 = <>
>          Auxiliary Features 1 = <>
> AArch32 Instruction Set Attributes 5 = 
> AArch32 Media and VFP Features 0 = 
> AArch32 Media and VFP Features 1 = 
> 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
> Unresolved linked clock found: hdmi_phy
> Unresolved linked clock found: usb480m_phy
> Trying to mount root from ufs:/dev/gpt/Rock64root []...
> uhub2: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> uhub0: 1 port with 1 removable, self powered
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Root mount waiting for: CAM
> Mounting from ufs:/dev/gpt/Rock64root failed with error 22; retrying for 3 more seconds
> Mounting from ufs:/dev/gpt/Rock64root failed with error 22: Invalid fstype.
> 
> 
> For reference for the patching I applied (whitespace
> details may not be preserved):
> 
> # git -C /usr/main-src/ diff sys/dev/usb/controller/ sys/arm64/rockchip/
> diff --git a/sys/arm64/rockchip/rk_dwc3.c b/sys/arm64/rockchip/rk_dwc3.c
> index 8582f7a86999..645a1cffbd95 100644
> --- a/sys/arm64/rockchip/rk_dwc3.c
> +++ b/sys/arm64/rockchip/rk_dwc3.c
> @@ -54,12 +54,10 @@ __FBSDID("$FreeBSD$");
>  #include 
>    enum rk_dwc3_type {
> -       RK3328 = 1,
> -       RK3399,
> +       RK3399 = 1,
>  };
>    static struct ofw_compat_data compat_data[] = {
> -       { "rockchip,rk3328-dwc3",       RK3328 },
>         { "rockchip,rk3399-dwc3",       RK3399 },
>         { NULL,                         0 }
>  };
> diff --git a/sys/dev/usb/controller/dwc3.c b/sys/dev/usb/controller/dwc3.c
> index 2e8f868bc47b..40405927685e 100644
> --- a/sys/dev/usb/controller/dwc3.c
> +++ b/sys/dev/usb/controller/dwc3.c
> @@ -86,6 +86,14 @@ struct snps_dwc3_softc {
>         bus_space_tag_t         bst;
>         bus_space_handle_t      bsh;
>         uint32_t                snpsid;
> +       uint32_t                snpsversion;
> +       uint32_t                snpsrevision;
> +       uint32_t                snpsversion_type;
> +#ifdef FDT
> +       clk_t                   clk_ref;
> +       clk_t                   clk_suspend;
> +       clk_t                   clk_bus;
> +#endif
>  };
>    #define        DWC3_WRITE(_sc, _off, _val)             \
> @@ -384,8 +392,31 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
>         sc->bsh = rman_get_bushandle(sc->mem_res);
>           sc->snpsid = DWC3_READ(sc, DWC3_GSNPSID);
> -       if (bootverbose)
> -               device_printf(sc->dev, "snps id: %#012x\n", sc->snpsid);
> +       sc->snpsversion = DWC3_VERSION(sc->snpsid);
> +       sc->snpsrevision = DWC3_REVISION(sc->snpsid);
> +       if (sc->snpsversion == DWC3_1_IP_ID ||
> +           sc->snpsversion == DWC3_2_IP_ID) {
> +               sc->snpsrevision = DWC3_READ(sc, DWC3_1_VER_NUMBER);
> +               sc->snpsversion_type = DWC3_READ(sc, DWC3_1_VER_TYPE);
> +       }
> +       if (bootverbose) {
> +               switch (sc->snpsversion) {
> +               case DWC3_IP_ID:
> +                       device_printf(sc->dev, "SNPS Version: DWC3 (%x %x)\n",
> +                           sc->snpsversion, sc->snpsrevision);
> +                       break;
> +               case DWC3_1_IP_ID:
> +                       device_printf(sc->dev, "SNPS Version: DWC3.1 (%x %x %x)\n",
> +                           sc->snpsversion, sc->snpsrevision,
> +                           sc->snpsversion_type);
> +                       break;
> +               case DWC3_2_IP_ID:
> +                       device_printf(sc->dev, "SNPS Version: DWC3.2 (%x %x %x)\n",
> +                           sc->snpsversion, sc->snpsrevision,
> +                           sc->snpsversion_type);
> +                       break;
> +               }
> +       }
>  #ifdef DWC3_DEBUG
>         snps_dwc3_dump_ctrlparams(sc);
>  #endif
> @@ -394,9 +425,32 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
>         if (!is_fdt)
>                 goto skip_phys;
>   -       /* Get the phys */
>         node = ofw_bus_get_node(dev);
>   +       /* Get the clocks if any */
> +       if (ofw_bus_is_compatible(dev, "rockchip,rk3328-dwc3") == 1) {
> +               if (clk_get_by_ofw_name(dev, node, "ref_clk", &sc->clk_ref) != 0)
> +                       device_printf(dev, "Cannot get ref_clk\n");
> +               if (clk_get_by_ofw_name(dev, node, "suspend_clk", &sc->clk_suspend) != 0)
> +                       device_printf(dev, "Cannot get suspend_clk\n");
> +               if (clk_get_by_ofw_name(dev, node, "bus_clk", &sc->clk_bus) != 0)
> +                       device_printf(dev, "Cannot get bus_clk\n");
> +       }
> +
> +       if (sc->clk_ref != NULL) {
> +               if (clk_enable(sc->clk_ref) != 0)
> +                       device_printf(dev, "Cannot enable ref_clk\n");
> +       }
> +       if (sc->clk_suspend != NULL) {
> +               if (clk_enable(sc->clk_suspend) != 0)
> +                       device_printf(dev, "Cannot enable suspend_clk\n");
> +       }
> +       if (sc->clk_bus != NULL) {
> +               if (clk_enable(sc->clk_bus) != 0)
> +                       device_printf(dev, "Cannot enable bus_clk\n");
> +       }
> +
> +       /* Get the phys */
>         usb2_phy = usb3_phy = NULL;
>         error = phy_get_by_ofw_name(dev, node, "usb2-phy", &usb2_phy);
>         if (error == 0 && usb2_phy != NULL)
> @@ -427,6 +481,16 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
>         snsp_dwc3_dump_regs(sc, "Post XHCI init");
>  #endif
>   +#ifdef FDT
> +       if (error) {
> +               if (sc->clk_ref != NULL)
> +                       clk_disable(sc->clk_ref);
> +               if (sc->clk_suspend != NULL)
> +                       clk_disable(sc->clk_suspend);
> +               if (sc->clk_bus != NULL)
> +                       clk_disable(sc->clk_bus);
> +       }
> +#endif
>         return (error);
>  }
>   diff --git a/sys/dev/usb/controller/dwc3.h b/sys/dev/usb/controller/dwc3.h
> index 21a87a1917ee..c69672072209 100644
> --- a/sys/dev/usb/controller/dwc3.h
> +++ b/sys/dev/usb/controller/dwc3.h
> @@ -31,6 +31,15 @@
>  #ifndef _DWC3_H_
>  #define        _DWC3_H_
>   +#define        DWC3_IP_ID              0x5533
> +#define        DWC3_1_IP_ID            0x3331
> +#define        DWC3_2_IP_ID            0x3332
> +
> +#define        DWC3_VERSION_MASK       0xFFFF0000
> +#define        DWC3_REVISION_MASK      0xFFFF
> +#define        DWC3_VERSION(x)         (((x) & DWC3_VERSION_MASK) >> 16)
> +#define        DWC3_REVISION(x)        ((x) & DWC3_REVISION_MASK)
> +
>  #define        DWC3_GSBUSCFG0          0xc100
>  #define        DWC3_GSBUSCFG1          0xc104
>  #define        DWC3_GTXTHRCFG          0xc108
> @@ -80,6 +89,9 @@
>  #define        DWC3_GPRTBIMAP_HSLO     0xc180
>  #define        DWC3_GPRTBIMAP_FSLO     0xc188
>   +#define        DWC3_1_VER_NUMBER       0xc1a0
> +#define        DWC3_1_VER_TYPE         0xc1a4
> +
>  #define        DWC3_GUSB2PHYCFG0       0xc200
>  #define         DWC3_GUSB2PHYCFG0_PHYSOFTRST           (1 << 31)
>  #define         DWC3_GUSB2PHYCFG0_U2_FREECLK_EXISTS    (1 << 30)
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 

 Looks like you're missing https://reviews.freebsd.org/D37394

-- 
Emmanuel Vadot  

From nobody Tue Nov 15 23:06:24 2022
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 4NBhdJ3gFGz4dKZJ
	for ; Tue, 15 Nov 2022 23:06:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4NBhdJ0FCLz3Ksc
	for ; Tue, 15 Nov 2022 23:06:43 +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=1668553602; bh=aZr/PPgWt5Izdv0zLU7JG+Xr95g1vfJdPmlHHq1jlGw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BsYnDsPA+UiRAmN07FpO02tIhxRusEp8yqpI/PGPXwMHZEgsLXjW5PkDxyWA0iJqqNnXQGHPtN0G3RWA/Afg75PyeWcbClYkyeLNFV4oKi5F5pKxNAiw2GCsVXCbL4jSycm1ftbVqiTq2Uq+GtlK88xL4qBVzDJKYldx7KPEZmtmdV0hr/ez5O0zOKJniXYGr0VDE/r8JvuDztWvz3thbdhHsTgDEkoIYACc2d5qEpxOGybhNCseW8E9WOZQnz52P0jOhFyO222hi5hT5CLTpX/PvI0srtuiMX050rJnXRgA3gENe4Q0525RwA5bp8yJnDYrU9qI2ejRJ2kx8FmDzg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668553602; bh=u6KB6cixLOliqdtDiOp0sSYPN/DguJ19GKvgqL/0Q+L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EKi4s3YP7lf9zPD9KAzRo62yizFYrQWVO9lgiIoKzVTrhO8ip80vU1iNM3PzH50+9CjZ+vSPy2ESmiVbTf2MuAjpXTb74lyDkgCa6RA/JkAtw55Q2zLqjh1lz4jSR70rhgMfr7BaJws3OMVLmjKhB37Chg9p2/sqQ5s8sSWwCWwb0/LK6os+wye8OPZ8QUWOGexoCKXZy5QqGzosBczhc4i7j54PnaWxsBb450780299iI/1giQO6LDv+tM5IaNFjVFVrUy8xoXutgwnBe4fR28Nv8tJVhHO2jH/NgcIJ0GxSDqLqNFFzyMlbSaSoXPD1hBCcVBwiyYhFtvFQoH7ag==
X-YMail-OSG: Zlsi83wVM1n4uKxp_SjFvdtEFgsD0Y6Vt70EAL30jmnkenR.Q1_OSRIxr.lcJ_Z
 lCba_Ukj8lbL3MtrpVUM1FHdSmnzuFRJ5QIqVbxAILnEnEJt4FNuVZnkfdnnCeFE7k3cQlPGfXIN
 G5pFh3OqH31ajC2Dv6IdRn1Gsm3HnNp02wIR7CdNkjWnpfT1u6Q5Zwwa1gYVg.n9720lkdbSrbc7
 1GHqzY83iiGPNFq81Sx2oYB_5epNCfdXHDLddmD7aMQ6Xbyb6yAJOncnymBtc2TkI3UikbQFOHu.
 .RNGWUxyTtrRZwuaVBfV9gUa8U.xbjnm_vNja2SL4lBR4eFbcSr.j9BX6gHWzkIizaPuhgYbmmWI
 nItSmLd7HORidTvJPPgMjCncI06wCFX4DQx3WyJtSw.PW3k1NjxEZPTtgL0hY_H1VhK5ptkFG._w
 M9tYSR4a4E89iKwYKk8Ax0fskATYsFNTgdvEjWn9FtrzhVRelNWqzjYcPkmv1GV6eefV2FkykvUB
 1PaGAe1pMekO5gGC3PyC8V4.U0y4ZkkoDfJid2KEft_k3Ttf2OukIWMZklnt1eGE6fDePJOVnj1M
 .D5ozbxUYAZkRzprYBBQdxAevpsCKKqi2UogNL2rJADZDc24mkjOpjo6LOgPIk98nPa31skqzzQ_
 xX.ewJxEXwJLSNPj14H_bw.NQk.tZByg2nF3nvt6s.w5x1TOL1avKRMtL9MH6baculNBhfehV5eo
 6xocdRY1bXrmrq0Bhklcea8U5LrPrpkwHJEZ84QSkSoZ2zcjLEky_Qgkkt7tj8Tf1coW01AlWuDr
 uiCpyx3.ua6b2JMchPQXhAh0hpAR_3k5npxnbHCRVgSJCSGYKEEsSta24qGqcvSiaBkn1hRvXXtt
 mmOOc1shw3xTm7IXPUz4GH8SlAiv6vuH7z3JGnqWPmWal6_CBWtrvPu2r1ORBHBkOvKrtu6wcK2Z
 cpzl.MtDKYmg1c.d_OBycvsWqimA5vXYNjOdd1Fg8tRv0jEEs7IpkunuDibje_EeNc1MFnznBX9_
 nW_e6AkHKwc8NiX0V0hYcKV.Y8DX2P1XMa_V11EK2JjpujHpauPOm61onZ4KbPywRDGbLutGBtDP
 RsucktRko_Pj.h.EbT2hV9WZmWTYGrzsmR2bTLFmHoA.HPShxygxE.P_PdKGPa7DTqDsOnSOdaL8
 zlgIuqq75c03eVYakf8W91VPszR7EPAx81IXP2HB7fLTTMCpttbCTsqOT9pP5HNjOuj5CUc2rZjM
 KWDeejeWzs1PXKfjv9xNa8UJXFAS_a.kgjm_JkI2o4WBjkwc8C8gMJ5zPQDSctVevDlEu7xbK09K
 uJUcXmzaVy6tbB6ttCuWFS1BguyLwDPEH07MJFltEvWiaqardXlwblLWy9LCuws1Z6HCIqdfj8.n
 .hu91qagSDD4.KcTee.skdp6dTd5N09tca45J0PVBxya078dRjyC__ipOBkd7MEiWIekLXyQa.90
 zCTntadQqmCrM8hs_1CPQn.2OXc1P74V1XbjG5Odk7TzO4VAgTEbmZjkYkwrofAFJiDZuShmlXJN
 dxDk1A9DydaW_J3nNmgn8zsVBu9hNtbIxtKlCw57f.vto8jps9NG0cWhnB6ZmyG.Z2G8Kp3qcY35
 ygjWSiFcipLghb5GVgJh6dC7dXIkYuUFnyojaF3xp8J0lPRTzHVDK_yYARomcq7Z6.MipUKgbyDE
 2qLGXRrpOdmAA7iB6WdYvjN312LdYiTn79ISIicZ8azXI5TxYvt0bOxcO8Qsb2O1Yxwu4fJMqci4
 v0yIdOasvH_ZbBTDd2ACC65pPAPTB3jb43vXCYbgm9pRYeaSCjEilVTJ99P_XdBfg3kpTe8X5iu6
 dcZSpKavmCg0ReMQK7yPPlDxug_TKhVlav8Us9hZygu1PXjZ4ODRsN0U6qUMiCiVqntXvQMWSsnf
 Uaiqo1V1IS5KUdus6j2hIBuLNiWSG.WzoE8jeSyD.43qV5w2dXPrO5Bf4IDYJ4Sz3_Jg1bzIV4E1
 mmWQvzG8j1ANMP_4Id9sV0FxFHCZUna9NUHNJdIXYqPKvJIItU6Eq7nl3OqtjoesQKJraicvIMhn
 0o1Ls5SNkA4DJKXdTEdyByQZ90DoTro2gZE3xF3_tteKzhGdiAX9fUAPG4auHgw.tlWbYUfx4dHF
 _nZxWptnv6kAyRKVTAfoccm2HO2k0OIh7getrEIMFT2FRYNcZnyuNMMmFKdI46tnffr9pDnqt2YA
 mIk.j9VmW82vOEvMi5jczmXiKw2Bg95JxiceU55zxBSiL5xUlOFhimXn7P0sGQzXX8W2TyNBPZiT
 p
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Nov 2022 23:06:42 +0000
Received: by hermes--production-bf1-5878955b5f-pzkd6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1986155e279fadc8debd680359835dc3;
          Tue, 15 Nov 2022 23:06:37 +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.200.110.1.12\))
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
From: Mark Millard 
In-Reply-To: <20221115221236.6c93f74861e2e58f3aa5a2e9@bidouilliste.com>
Date: Tue, 15 Nov 2022 15:06:24 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
 <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
 
 <20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
 <041B0111-7D71-4FBF-B661-E03F2CCD7D9A@yahoo.com>
 <20221115221236.6c93f74861e2e58f3aa5a2e9@bidouilliste.com>
To: Emmanuel Vadot 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NBhdJ0FCLz3Ksc
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Nov 15, 2022, at 13:12, Emmanuel Vadot  wrote:

> On Tue, 15 Nov 2022 13:03:45 -0800
> Mark Millard  wrote:
>=20
>> On Nov 15, 2022, at 05:05, Emmanuel Vadot  =
wrote:
>>=20
>>> On Fri, 4 Nov 2022 12:31:51 -0700
>>> Mark Millard  wrote:
>>>=20
>>>> On 2022-Oct-22, at 23:00, Mark Millard  wrote:
>>>>=20
>>>>> Well, turns out that part of the "Import device-tree files
>>>>> from Linux 5.14" is:
>>>>>=20
>>>>> =
https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rock=
chip/rk3328-rock64.dts?id=3D5956d97f4b32
>>>>>=20
>>>>> which has:
>>>>> . . .
>>>>=20
>>>>=20
>>>=20
>>> Hi Mark,
>>>=20
>>> See https://reviews.freebsd.org/D37392 (and child reviews) for a =
fix.
>>> This was indeed the import of the new DTS files that caused the =
first
>>> problem (there is no glue node in rk3328.dtsi like in other SoCs or
>>> like our overlay). The other commit responsible for breaking USB3
>>> support was the addition to RK356x SoC, the check was bad for when =
to
>>> force USB2.
>>=20
>> Thanks.
>>=20
>> I applied the diff and the 2 child diff's and rebuilt and
>> installed, including updating the kernel on the e.MMC that
>> is historically used to mount the rootfs on USB3 when the
>> USB3 drive is plugged in there. (U-boot does not handle
>> the USB context I want.)
>>=20
>> . . .
>>=20
>>=20
>=20
> Looks like you're missing https://reviews.freebsd.org/D37394

Hopefully this time I have all the childern, grandchildern, etc.
Sorry for the screwup.

But the behavior observed is unchanged in this attempt.

A diff of the console output of booting via USB2 this time
vs. the prior report's USB3 failure log reveals no differences
between the latter part of the block of:

clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
Cannot get frequency for clk: hdmi_phy, error: 9

and the later:

Trying to mount root from ufs:/dev/gpt/Rock64root []...
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered

No DWC3, XHCI, etc.

But a boot -v does report:

ofwbus0:  mem 0xff600000-0xff6fffff irq 50 compat =
rockchip,rk3328-xhci (no driver attached)

Note the "xhci" instead of "dwc3".

The overall list of no driver notices that do not mention "disabled" is
listed below. It does reference a "rockchip,rk3328-usb2phy" as well as
the above.

ofwbus0:  compat operating-points-v2 (no driver attached)
ofwbus0:  compat rockchip,display-subsystem (no =
driver attached)
ofwbus0:  mem 0xff030000-0xff030fff irq 11 compat =
rockchip,rk3328-spdif (no driver attached)
ofwbus0:  mem 0xff040000-0xff040fff disabled compat =
rockchip,pdm (no driver attached)
rk_grf0:  mem 0xff100000-0xff100fff compat =
rockchip,rk3328-io-voltage-domain (no driver attached)
rk_grf0:  mem 0xff100000-0xff100fff compat =
rockchip,rk3328-grf-gpio (no driver attached)
rk_grf0:  mem 0xff100000-0xff100fff compat =
rockchip,rk3328-power-controller (no driver attached)
rk_grf0:  mem 0xff100000-0xff100fff compat =
syscon-reboot-mode (no driver attached)
ofwbus0:  mem 0xff1a0000-0xff1a00ff irq 20 compat =
rockchip,rk3328-wdt (no driver attached)
ofwbus0:  mem 0xff1f0000-0xff1f3fff irq 22,23 compat =
arm,pl330 (no driver attached)
ofwbus0:  mem 0xff260000-0xff26004f compat =
rockchip,rk3328-efuse (no driver attached)
ofwbus0:  mem 0xff300000-0xff33ffff irq =
26,27,28,29,30,31,32 compat rockchip,rk3328-mali (no driver attached)
ofwbus0:  mem 0xff350000-0xff3507ff irq 35 compat =
rockchip,rk3328-vpu (no driver attached)
ofwbus0:  mem 0xff350800-0xff35083f irq 36 compat =
rockchip,iommu (no driver attached)
ofwbus0:  mem 0xff370000-0xff373efb irq 38 compat =
rockchip,rk3328-vop (no driver attached)
ofwbus0:  mem 0xff373f00-0xff373fff irq 39 compat =
rockchip,iommu (no driver attached)
ofwbus0:  mem 0xff3c0000-0xff3dffff irq 40,41 compat =
rockchip,rk3328-dw-hdmi (no driver attached)
ofwbus0:  mem 0xff410000-0xff410fff compat =
rockchip,rk3328-codec (no driver attached)
ofwbus0:  mem 0xff430000-0xff43ffff irq 42 compat =
rockchip,rk3328-hdmi-phy (no driver attached)
simple_mfd0:  mem 0-0xff44ffff,0-0xffff compat =
rockchip,rk3328-usb2phy (no driver attached)
ofwbus0:  mem 0xff600000-0xff6fffff irq 50 compat =
rockchip,rk3328-xhci (no driver attached)
ofwbus0:  compat gpio-ir-receiver (no driver attached)
ofwbus0:  compat linux,spdif-dit (no driver attached)
ofwbus0:  mem =
0xff400000-0xff400fff,0xff780000-0xff782fff,0xff100000-0xff100fff,0xff4400=
00-0xff440fff,0xff720000-0xff720fff,0xff798000-0xff798fff compat =
rockchip,rk3328-dmc (no driver attached)
ofwbus0:  compat u-boot,sysinfo-smbios (no driver attached)
pcm0: no driver attached to codec node
pcm1: no driver attached to codec node
pcm2: no driver attached to cpu node



For reference:

# git -C /usr/main-src/ diff sys/dev/usb/controller/ sys/arm64/rockchip/ =
sys/dts/ sys/modules/
diff --git a/sys/arm64/rockchip/rk_dwc3.c b/sys/arm64/rockchip/rk_dwc3.c
index 8582f7a86999..645a1cffbd95 100644
--- a/sys/arm64/rockchip/rk_dwc3.c
+++ b/sys/arm64/rockchip/rk_dwc3.c
@@ -54,12 +54,10 @@ __FBSDID("$FreeBSD$");
 #include 
=20
 enum rk_dwc3_type {
-       RK3328 =3D 1,
-       RK3399,
+       RK3399 =3D 1,
 };
=20
 static struct ofw_compat_data compat_data[] =3D {
-       { "rockchip,rk3328-dwc3",       RK3328 },
        { "rockchip,rk3399-dwc3",       RK3399 },
        { NULL,                         0 }
 };
diff --git a/sys/dev/usb/controller/dwc3.c =
b/sys/dev/usb/controller/dwc3.c
index 2e8f868bc47b..d5e3b3f50a9d 100644
--- a/sys/dev/usb/controller/dwc3.c
+++ b/sys/dev/usb/controller/dwc3.c
@@ -86,6 +86,14 @@ struct snps_dwc3_softc {
        bus_space_tag_t         bst;
        bus_space_handle_t      bsh;
        uint32_t                snpsid;
+       uint32_t                snpsversion;
+       uint32_t                snpsrevision;
+       uint32_t                snpsversion_type;
+#ifdef FDT
+       clk_t                   clk_ref;
+       clk_t                   clk_suspend;
+       clk_t                   clk_bus;
+#endif
 };
=20
 #define        DWC3_WRITE(_sc, _off, _val)             \
@@ -384,8 +392,31 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        sc->bsh =3D rman_get_bushandle(sc->mem_res);
=20
        sc->snpsid =3D DWC3_READ(sc, DWC3_GSNPSID);
-       if (bootverbose)
-               device_printf(sc->dev, "snps id: %#012x\n", sc->snpsid);
+       sc->snpsversion =3D DWC3_VERSION(sc->snpsid);
+       sc->snpsrevision =3D DWC3_REVISION(sc->snpsid);
+       if (sc->snpsversion =3D=3D DWC3_1_IP_ID ||
+           sc->snpsversion =3D=3D DWC3_2_IP_ID) {
+               sc->snpsrevision =3D DWC3_READ(sc, DWC3_1_VER_NUMBER);
+               sc->snpsversion_type =3D DWC3_READ(sc, DWC3_1_VER_TYPE);
+       }
+       if (bootverbose) {
+               switch (sc->snpsversion) {
+               case DWC3_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3 (%x =
%x)\n",
+                           sc->snpsversion, sc->snpsrevision);
+                       break;
+               case DWC3_1_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3.1 (%x =
%x %x)\n",
+                           sc->snpsversion, sc->snpsrevision,
+                           sc->snpsversion_type);
+                       break;
+               case DWC3_2_IP_ID:
+                       device_printf(sc->dev, "SNPS Version: DWC3.2 (%x =
%x %x)\n",
+                           sc->snpsversion, sc->snpsrevision,
+                           sc->snpsversion_type);
+                       break;
+               }
+       }
 #ifdef DWC3_DEBUG
        snps_dwc3_dump_ctrlparams(sc);
 #endif
@@ -394,9 +425,32 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        if (!is_fdt)
                goto skip_phys;
=20
-       /* Get the phys */
        node =3D ofw_bus_get_node(dev);
=20
+       /* Get the clocks if any */
+       if (ofw_bus_is_compatible(dev, "rockchip,rk3328-dwc3") =3D=3D 1) =
{
+               if (clk_get_by_ofw_name(dev, node, "ref_clk", =
&sc->clk_ref) !=3D 0)
+                       device_printf(dev, "Cannot get ref_clk\n");
+               if (clk_get_by_ofw_name(dev, node, "suspend_clk", =
&sc->clk_suspend) !=3D 0)
+                       device_printf(dev, "Cannot get suspend_clk\n");
+               if (clk_get_by_ofw_name(dev, node, "bus_clk", =
&sc->clk_bus) !=3D 0)
+                       device_printf(dev, "Cannot get bus_clk\n");
+       }
+
+       if (sc->clk_ref !=3D NULL) {
+               if (clk_enable(sc->clk_ref) !=3D 0)
+                       device_printf(dev, "Cannot enable ref_clk\n");
+       }
+       if (sc->clk_suspend !=3D NULL) {
+               if (clk_enable(sc->clk_suspend) !=3D 0)
+                       device_printf(dev, "Cannot enable =
suspend_clk\n");
+       }
+       if (sc->clk_bus !=3D NULL) {
+               if (clk_enable(sc->clk_bus) !=3D 0)
+                       device_printf(dev, "Cannot enable bus_clk\n");
+       }
+
+       /* Get the phys */
        usb2_phy =3D usb3_phy =3D NULL;
        error =3D phy_get_by_ofw_name(dev, node, "usb2-phy", &usb2_phy);
        if (error =3D=3D 0 && usb2_phy !=3D NULL)
@@ -404,12 +458,19 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        error =3D phy_get_by_ofw_name(dev, node, "usb3-phy", &usb3_phy);
        if (error =3D=3D 0 && usb3_phy !=3D NULL)
                phy_enable(usb3_phy);
-       else {
-               reg =3D DWC3_READ(sc, DWC3_GUCTL1);
-               if (bootverbose)
-                       device_printf(dev, "Forcing USB2 clock only\n");
-               reg |=3D DWC3_GUCTL1_DEV_FORCE_20_CLK_FOR_30_CLK;
-               DWC3_WRITE(sc, DWC3_GUCTL1, reg);
+       if (sc->snpsversion =3D=3D DWC3_IP_ID) {
+               if (sc->snpsrevision >=3D 0x290A) {
+                       uint32_t hwparams3;
+
+                       hwparams3 =3D DWC3_READ(sc, DWC3_GHWPARAMS3);
+                       if (DWC3_HWPARAMS3_SSPHY(hwparams3) =3D=3D =
DWC3_HWPARAMS3_SSPHY_DISABLE) {
+                               reg =3D DWC3_READ(sc, DWC3_GUCTL1);
+                               if (bootverbose)
+                                       device_printf(dev, "Forcing USB2 =
clock only\n");
+                               reg |=3D =
DWC3_GUCTL1_DEV_FORCE_20_CLK_FOR_30_CLK;
+                               DWC3_WRITE(sc, DWC3_GUCTL1, reg);
+                       }
+               }
        }
        snps_dwc3_configure_phy(sc, node);
 skip_phys:
@@ -427,6 +488,16 @@ snps_dwc3_common_attach(device_t dev, bool is_fdt)
        snsp_dwc3_dump_regs(sc, "Post XHCI init");
 #endif
=20
+#ifdef FDT
+       if (error) {
+               if (sc->clk_ref !=3D NULL)
+                       clk_disable(sc->clk_ref);
+               if (sc->clk_suspend !=3D NULL)
+                       clk_disable(sc->clk_suspend);
+               if (sc->clk_bus !=3D NULL)
+                       clk_disable(sc->clk_bus);
+       }
+#endif
        return (error);
 }
=20
diff --git a/sys/dev/usb/controller/dwc3.h =
b/sys/dev/usb/controller/dwc3.h
index 21a87a1917ee..fd61d1129df3 100644
--- a/sys/dev/usb/controller/dwc3.h
+++ b/sys/dev/usb/controller/dwc3.h
@@ -31,6 +31,15 @@
 #ifndef _DWC3_H_
 #define        _DWC3_H_
=20
+#define        DWC3_IP_ID              0x5533
+#define        DWC3_1_IP_ID            0x3331
+#define        DWC3_2_IP_ID            0x3332
+
+#define        DWC3_VERSION_MASK       0xFFFF0000
+#define        DWC3_REVISION_MASK      0xFFFF
+#define        DWC3_VERSION(x)         (((x) & DWC3_VERSION_MASK) >> =
16)
+#define        DWC3_REVISION(x)        ((x) & DWC3_REVISION_MASK)
+
 #define        DWC3_GSBUSCFG0          0xc100
 #define        DWC3_GSBUSCFG1          0xc104
 #define        DWC3_GTXTHRCFG          0xc108
@@ -80,6 +89,9 @@
 #define        DWC3_GPRTBIMAP_HSLO     0xc180
 #define        DWC3_GPRTBIMAP_FSLO     0xc188
=20
+#define        DWC3_1_VER_NUMBER       0xc1a0
+#define        DWC3_1_VER_TYPE         0xc1a4
+
 #define        DWC3_GUSB2PHYCFG0       0xc200
 #define         DWC3_GUSB2PHYCFG0_PHYSOFTRST           (1 << 31)
 #define         DWC3_GUSB2PHYCFG0_U2_FREECLK_EXISTS    (1 << 30)
@@ -98,6 +110,11 @@
 #define         DWC3_GUSB3PIPECTL0_DELAYP1TRANS        (1 << 18)
 #define         DWC3_GUSB3PIPECTL0_SUSPENDUSB3         (1 << 17)
=20
+#define        DWC3_HWPARAMS3_SSPHY(x)                 (x & 0x3)
+#define         DWC3_HWPARAMS3_SSPHY_DISABLE           0
+#define         DWC3_HWPARAMS3_SSPHY_GEN1              1
+#define         DWC3_HWPARAMS3_SSPHY_GEN2              2
+
 #define        DWC3_GTXFIFOSIZ(x)      (0xc300 + 0x4 * (x))
 #define        DWC3_GRXFIFOSIZ(x)      (0xc380 + 0x4 * (x))
 #define        DWC3_GEVNTADRLO0                0xc400
diff --git a/sys/dts/arm64/overlays/rk3328-dwc3.dtso =
b/sys/dts/arm64/overlays/rk3328-dwc3.dtso
deleted file mode 100644
index bade60b60d57..000000000000
--- a/sys/dts/arm64/overlays/rk3328-dwc3.dtso
+++ /dev/null
@@ -1,39 +0,0 @@
-/dts-v1/;
-/plugin/;
-
-#include 
-#include 
-#include 
-
-/ {
-       compatible =3D "rockchip,rk3328";
-};
-
-&{/} {
-       usbdrd3: usb@ff600000 {
-               compatible =3D "rockchip,rk3328-dwc3";
-               clocks =3D <&cru SCLK_USB3OTG_REF>, <&cru =
SCLK_USB3OTG_SUSPEND>,
-                        <&cru ACLK_USB3OTG>;
-               clock-names =3D "ref_clk", "suspend_clk",
-                             "bus_clk";
-               #address-cells =3D <2>;
-               #size-cells =3D <2>;
-               ranges;
-               status =3D "okay";
-
-               usbdrd_dwc3: dwc3@ff600000 {
-                       compatible =3D "snps,dwc3";
-                       reg =3D <0x0 0xff600000 0x0 0x100000>;
-                       interrupts =3D ;
-                       dr_mode =3D "host";
-                       phy_type =3D "utmi_wide";
-                       snps,dis_enblslpm_quirk;
-                       snps,dis-u2-freeclk-exists-quirk;
-                       snps,dis_u2_susphy_quirk;
-                       snps,dis_u3_susphy_quirk;
-                       snps,dis-del-phy-power-chg-quirk;
-                       snps,dis-tx-ipgap-linecheck-quirk;
-                       status =3D "okay";
-               };
-       };
-};
diff --git a/sys/modules/dtb/rockchip/Makefile =
b/sys/modules/dtb/rockchip/Makefile
index 1e0c6a2d4362..4f4a21f51a39 100644
--- a/sys/modules/dtb/rockchip/Makefile
+++ b/sys/modules/dtb/rockchip/Makefile
@@ -22,7 +22,6 @@ DTS=3D  \
 DTSO=3D  rk3328-analog-sound.dtso \
        rk3328-i2c0.dtso \
        rk3328-uart1.dtso \
-       rk3328-dwc3.dtso \
        rk3399-mmc0-disable.dtso \
        rk3399-mmc1-disable.dtso \
        rk3399-sdhci-disable.dtso

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Nov 16 10:33:53 2022
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 4NBztJ17ylz4hWhs
	for ; Wed, 16 Nov 2022 10:34:00 +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 4NBztH4Sbnz41gg
	for ; Wed, 16 Nov 2022 10:33:59 +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=1668594837;
	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=exIiiE3hpZX4nUoXX9DDCuhAtlT/yxWispuc9dT5NwE=;
	b=LmwA7rorfqNj9DkD8F6ty3nvxzqafPTKuiHNRZLbf38yuEsyZ0N09JW/fWsPYUUDEtN9+a
	IyTYUiNqw9VihlsZZNhlorv7nidAB9fpiHMqxVVc2V0zV38cLpbBS2+o3Ovog3DA4uE2ou
	aqkbODQtTH9ZWiRgW7SX7p+zeTs7MSU=
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 d95361a2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Wed, 16 Nov 2022 10:33:57 +0000 (UTC)
Date: Wed, 16 Nov 2022 11:33:53 +0100
From: Emmanuel Vadot 
To: Mark Millard 
Cc: freebsd-arm 
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
Message-Id: <20221116113353.247b6c024076a99c6e941588@bidouilliste.com>
In-Reply-To: 
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
	<665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
	
	<20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
	<041B0111-7D71-4FBF-B661-E03F2CCD7D9A@yahoo.com>
	<20221115221236.6c93f74861e2e58f3aa5a2e9@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: 4NBztH4Sbnz41gg
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 15 Nov 2022 15:06:24 -0800
Mark Millard  wrote:

> On Nov 15, 2022, at 13:12, Emmanuel Vadot  wrote:
> 
> > On Tue, 15 Nov 2022 13:03:45 -0800
> > Mark Millard  wrote:
> > 
> >> On Nov 15, 2022, at 05:05, Emmanuel Vadot  wrote:
> >> 
> >>> On Fri, 4 Nov 2022 12:31:51 -0700
> >>> Mark Millard  wrote:
> >>> 
> >>>> On 2022-Oct-22, at 23:00, Mark Millard  wrote:
> >>>> 
> >>>>> Well, turns out that part of the "Import device-tree files
> >>>>> from Linux 5.14" is:
> >>>>> 
> >>>>> https://cgit.freebsd.org/src/commit/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock64.dts?id=5956d97f4b32
> >>>>> 
> >>>>> which has:
> >>>>> . . .
> >>>> 
> >>>> 
> >>> 
> >>> Hi Mark,
> >>> 
> >>> See https://reviews.freebsd.org/D37392 (and child reviews) for a fix.
> >>> This was indeed the import of the new DTS files that caused the first
> >>> problem (there is no glue node in rk3328.dtsi like in other SoCs or
> >>> like our overlay). The other commit responsible for breaking USB3
> >>> support was the addition to RK356x SoC, the check was bad for when to
> >>> force USB2.
> >> 
> >> Thanks.
> >> 
> >> I applied the diff and the 2 child diff's and rebuilt and
> >> installed, including updating the kernel on the e.MMC that
> >> is historically used to mount the rootfs on USB3 when the
> >> USB3 drive is plugged in there. (U-boot does not handle
> >> the USB context I want.)
> >> 
> >> . . .
> >> 
> >> 
> > 
> > Looks like you're missing https://reviews.freebsd.org/D37394
> 
> Hopefully this time I have all the childern, grandchildern, etc.
> Sorry for the screwup.
> 
> But the behavior observed is unchanged in this attempt.
> 
> A diff of the console output of booting via USB2 this time
> vs. the prior report's USB3 failure log reveals no differences
> between the latter part of the block of:
> 
> clknode_link_recalc: Attempt to use unresolved linked clock: hdmi_phy
> Cannot get frequency for clk: hdmi_phy, error: 9

 That's not related.

> and the later:
> 
> Trying to mount root from ufs:/dev/gpt/Rock64root []...
> uhub2: 1 port with 1 removable, self powered
> uhub1: 1 port with 1 removable, self powered
> uhub0: 1 port with 1 removable, self powered
> 
> No DWC3, XHCI, etc.
> 
> But a boot -v does report:
> 
> ofwbus0:  mem 0xff600000-0xff6fffff irq 50 compat rockchip,rk3328-xhci (no driver attached)
> 
> Note the "xhci" instead of "dwc3".

 There is no such thing as rockchip,rk3328-xhci in our dts but there is
one in the embbeded u-boot one, you likely don't have a correct DTB on
the msdos partition.

 Cheers,

-- 
Emmanuel Vadot  

From nobody Wed Nov 16 17:38:14 2022
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 4NC9J85M6Cz4h84v
	for ; Wed, 16 Nov 2022 17:38:32 +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 4NC9J82Vddz3N8x
	for ; Wed, 16 Nov 2022 17:38:32 +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=1668620309; bh=f2Bh9dp66ZWvOod3ztQujbTCCURIIPrS2wCG+lVnoeM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ArrTXxpKrLEk9r9eVpz9iMGwr/avSAEYkFRRqHjGWgaGCdbIzer8jU8PqPEm7EC4YD+ceYJz6+sBm4TS/ehW1jfNj4lS1pa5fOPZTFeHcoqOWo35GbCmH1fz4Ye8p8u5a7Ccq2ddA955mEeTkk3SuzhDeRH7MrGm81yzdPMBn6ft00F2GX30dj40jVVSkNnjtaMeQDMbj/fGL5UeiF+CC/tNwH7IpxMMo6ddgeFP6fKA4/gfwn5nOwtIDg7RWFXEs0Ha9ac0j2J9MWpvWy7q4yjYRkY1fUFJhnb2ag4yHy+mCnk9igbIF4Q2x4IiTBhKYp/gBUVcwxsU6UPPMVMymA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668620309; bh=Y8KP0cwig5NY5mtBcU7jyjpkfGN88hfeva6L6o7eMVR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OQfJeUEd9MM1qVB8ga1Rm0c/OdOMBY9rYtTDlNHB78lTWfirTlbXqYLvIYyEsNIsbKkmm1CVv2TM5uqSOwKiabtS1mmC3zoYdVGiiBXZ8L5flmQYvQ3pYaJUeUz8VQFuadn3pwFMJ/94qlrHYFDJhmwzWOJDMk5DxUHKbP2Mot+NeJ7aOpDGYEMeos5EaPBolLGskBEmRpRYFt1Ue0cCRui+yakJhOI1cdbJhSH7kIipVoA+tRFExHEXeEXfWLisAgGxfir9EVe1Mqt0XXrXj+5Qi4Bq2NY4oCrzyT6iyrhFqWG/nljJmP50DXJFjTn8Q2Cz/aI+wTIxeWobWQIfBw==
X-YMail-OSG: fDqm4ngVM1kE8dSHhrG1VvsXp3ssoZBN8PoYG9qTkFOHcJLVYSsQgfKv_vMhmBg
 KHqIZHLhdQ1ytofX00uAtK3RjEVPnImfUg3WG1nuXH..JvJxeNQR2pFblE5FEFySqWHyok1tn8Rq
 iLDOig6xP9ctMy5z__JzZHbu_MEjyNUCzV__Xu3fdW7ux1VV.zOGChsqybWNIkVeRmm52tVwplQW
 LZd6qPNamOGgABtnEs5EUDTD4cRyFBkANbUSEj7NqoHflGYfX93MTl8NIBgwiGbKfF4aAHqysbbL
 NW6auJBx.SFxLkIMEKqK8qwtPxNY6bwZCkuexAtoQ.hvwjMwRCCPGddQdJvceUOfvxEI0gTjBW9H
 FyxCgKDGsSFUsnIDyn0S9q5Nuo9o6P5JRQs4IopSLaAaCKcpk7oIlPHTmNM5k9fieO4xziPoklKQ
 N8rcls0SSI8F_GgOrCMrDpPeuiLoWzLfUEwPmQ2.hrlkNe3ekytyXvjiWxUNZRzqEP5uf9FZYX.O
 wd.1GFihegnvKi1oIKb._jOYjFEC2O.pL2QM_1f_77wIrfaAIngJidWwCp.goDUZqmsW7yI_x38C
 .dK1pyk2v2mb6_cMPYvpU5epDcp.Jv6_LQuAOUZrRpl6GLo57oMu4edV8IVV1hg.Pukn34oLUe7_
 NEa2yrEPYwjOaxT2qsNeTF6oNnN0kVFeB5oUttMKMxzmoZFiNnfl18OZmSpek3iJFIFgn4VWXki6
 gfZvFfKydvB5FcfYC0gs3i6by8ipRMmQprWUTXGu7cK1hkq5OUnOmA.tT7QLLnWHApVL1LkC3tYv
 dH10w8MXwubS6q7mnE39905Qgs4g3NrU30o7PqDTBk8_NQyF.AoH2uxotEEtxZcXWNnhvbMxEPsz
 6mixCcNZYmpCTuIsYrLy4zdFy4uTnHejq8lbulLJ4oqaGlpJsSIcosikjNE.HOR_OaWB3_Y.xH_C
 9HZ4J811Pyl5QUoLG0LrmSqrjvhVfOVAg3R.AAa5usAZGvjmLAzTx6agJHMCsZdBMaDQ6JOyZ2_D
 uXmTLsiEcEnrQieLI1wIzwJ.vbGDCFnp4WJlqlTLv5NTx224QgH2M2ylkra5kpJ3uArUwd5W_gkL
 mJDHUtso2jpkomtdLyxNxUYpbW0dn7FKwcJnxYckJT_MPI9N5A.e7ejM3nT_4uiEcxszs5iHOiVN
 AGefjR.d1IgwaMZXsHsn0pOzX18gfvmTi41WRZ_JppNOyPI5g0Ws54K9aSmXH7AxGdNgWtNien0P
 ZzU5rwzo9sHMO55rke9fvZNvNT_DQl_4HLZNA7SQc8wyAD1CJOWlrsGGN_xWe1HbrhDTd0ODQ4l6
 NPe5tRJECXqSvJMjQEGEzkcedTS2CgrkZA00LQGVMim2JOr0QzSyFL3L_fJCMoyVsJKhAoWocKJf
 2OZSe7JBbVqJJBIjFhc7dJnSdKSxSZlvtiU19Z8LlBRA2YekNpzNXg7vea8JSlXU07d31enIzhwQ
 mMj9CmZTVjEwQiZi2E_DEK0dAl4K4Ws.oH1KzN85O7ombtPw5_zL1iJXT_NTljAlEr3Hd4eVPyl6
 YBXw1.afjUth8QX.aMlOz1ORvzeLeOQy1o9UvtioQOenfXmSVEEmwS1JQUjPHXYKcpzfPcx_yjgT
 qqACgqfnTkp3QLEBJIOKDhy6s0m5CMriFXUfeydyq3eEcQNmd5Rj0a7fTMzUGAsKO7iuIxs3cVcl
 jBoJDN3IGh4JISWlABR.nyhE3Bt8h1mQWeMxezFbMGwmlq54PzJ0PzCuIGqBesKxqG2X0RJ5wB6m
 fOiKA0BNZFutSGqwhZ8DKgKaJox6mauMQGXNzIU13HtIf.aVktSC1pHezqulmSEjl32X34E6B77.
 kuoc6gaABCXFPiazcuxmDr6n2kucqEwObe6ecLWHj7KmkonldruE5iFAXZsAOe470M.U4RB9Oql5
 9zJ4euZJkyjZInq8YMEfFoaH0L_JphRvRW3RSdWQF1T1WAqyPsssZn5A.1gcTs84et.mRxDMhQ7U
 OVU.1OIimkFBa2zS7_X4ccad6hA19WWHj.ePbeMJ6g5B8zKLqRZnOxhxztz2KYVaunxZdpqIZCIR
 HckKH6D4pWZKwCbJ5USDrp.u0MBp8iof46zFGtv9P93gZ73N.dLFRkRpM_BpFztabXjpu.jNBq0M
 3P7hViZHqiG08CudMXitAsBnhoAwvAjHlvGEwtJDx77nsGyQjczSC32Ni.YqE56RLage9OIXWnLM
 3DDkL212k1SlZ8sOpY1B7XihmMJCgN0oXPTBm.5.rerxYmA2dpF.bSJFcWSaGwBmYxY2xjoPJAVP
 G
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Nov 2022 17:38:29 +0000
Received: by hermes--production-bf1-5878955b5f-dvp8b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5aa99ceacf2e3ff7d0a29daefd0e070a;
          Wed, 16 Nov 2022 17:38:26 +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.200.110.1.12\))
Subject: Re: FYI: Rock64 USB3 port no longer works for main [so: 14] (looks
 like dtb changes invalidating use of the old .dtbo and needing kernel
 changes)
From: Mark Millard 
In-Reply-To: <20221116113353.247b6c024076a99c6e941588@bidouilliste.com>
Date: Wed, 16 Nov 2022 09:38:14 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <561F6277-2C68-403E-BC1B-9194498888F9@yahoo.com>
References: <8A639ABB-D8CC-47D6-A106-A5E2463E7AEE@yahoo.com>
 <665C125A-3E2B-408F-8F6E-B2D23237F06A@yahoo.com>
 
 <20221115140522.f94fa1cb62131b6591a073f0@bidouilliste.com>
 <041B0111-7D71-4FBF-B661-E03F2CCD7D9A@yahoo.com>
 <20221115221236.6c93f74861e2e58f3aa5a2e9@bidouilliste.com>
 
 <20221116113353.247b6c024076a99c6e941588@bidouilliste.com>
To: Emmanuel Vadot 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NC9J82Vddz3N8x
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Nov 16, 2022, at 02:33, Emmanuel Vadot  wrote:

> On Tue, 15 Nov 2022 15:06:24 -0800
> Mark Millard  wrote:
>=20
>> On Nov 15, 2022, at 13:12, Emmanuel Vadot  =
wrote:
>> . . . .
>>=20
>> But a boot -v does report:
>>=20
>> ofwbus0:  mem 0xff600000-0xff6fffff irq 50 compat =
rockchip,rk3328-xhci (no driver attached)
>>=20
>> Note the "xhci" instead of "dwc3".
>=20
> There is no such thing as rockchip,rk3328-xhci in our dts but there is
> one in the embbeded u-boot one, you likely don't have a correct DTB on
> the msdos partition.

Yesterday was definitely not one of my better days. Sure
enough, the file was out of place --and the FreeBSD
warning was present as well. Sorry for taking your time.

I now have booted with root (world) on the USB3 port:

usbus4: 5.0Gbps Super Speed USB v3.0
ugen4.1:  at usbus4
uhub0 on usbus4
uhub0:  on =
usbus4
. . .
ugen4.2:  at usbus4
umass0 on uhub0
umass0:  =
on usbus4
umass0:  SCSI over Bulk-Only; quirks =3D 0x0000
umass0:0:0: Attached to scbus0
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2

Back to normal. Thanks!


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Nov 18 00:57:20 2022
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 4NCz0K5lx1z4hhD0
	for ; Fri, 18 Nov 2022 00:57:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4NCz0J42w1z3n1y
	for ; Fri, 18 Nov 2022 00:57:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=Tpvj11iy;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1668733053; bh=j49B6NyJ7hA/OjdneemCTBiqsTyPDKkg9yjM+UiSaMs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Tpvj11iyLsYBLMmXF/bYBNQppIaoGYkA/F4PlOFBfzqOzbLoVHbglKvYobVH992KCfoa5LeM+CYDyY2+UDQH+yZTiso6g0U1um3kJ8V5CBw59hcU43vOdcwrllgaR+upPFHywcqAhFNB97fri/YVX6Fb2b0AvbN2SLZKZ0GMKApWdMpjJbT8ow0xoPOzTTOw+NZGYFNB+kDslVLvWC0iS4fWwoS8U8x2aQCDZlzCvRaYIN6BwfWSbNoGmjSy0d97LqjEYmCJwkgZzKXLYd6vEOoOUmcYFmREWFxtBe1bb034R/fRrXy03wURqB/jPzN6eat8OiBSKpBMkzDQeQ5EbQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668733053; bh=yzABQXGrkoRdGLHvwe6nHDt5JgujI3Ci+Z2DbnJOdxR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r9mSZDsdCvhkNQXuDTlGJv4/ys5EazA+OCsb8aZkHW9ToJdMpqk8VVjU1DaBOI3d0ME9hwplxMx1ot+pPih6cP9WJdiZ0P8RrG5rJ1qR12yoy+wKQa/7JvS+Slo9XYD2eDNUSazQWAJgF+uPSy9Vi9YxMpHRiEVHYkf6Nf/8ZFVtSEVKT4AGv+x4B6tiZCGqJvhJtCkpDN0v0d1AF3fa1Bvt4XUCNW7Shr7F0NBbbyNql2rRYrl+RUa0vlq2EYJFLE/qrUXa/cUX0mQ7isBCEQZTy6SKetnQ/Axh/qAbCuAl5KS9Y+2Ru0I2yd8XquWC4RnrtQ7+jiZi7nTP3VCfwg==
X-YMail-OSG: EdsvIJkVM1lMExzLlI7dfR51uKym0soW3CCZ8y6s7pI.oqarMbKSf12HgMFUNUc
 U5URp4MaieB98O0dSzhsNeu3a74FuXbaoYw3nWeeiXEZw1y5SpSwMzdyLf2hT8iKZsw9Kxgjbzfd
 00c5PkikyPCWupfMJI7V7v0G03mXp0oKx1jY_y_PMgvwwoKf15B9_kibSl4csRn8jhouXP8f7czz
 MRCiy49Kk5IsFVp.FOdygst2qt6dlQzxNUqb3R2r2K71cdjQ_Y97W3Ny36mN0NLOOQTKHeoB_DFE
 oMojP4wt9lTxiaxtuWbMepwY5abxZS5RImskD1ODBLU0bM.x7RcJgZ3GP8WqhY2FG1hGbxA3HXRU
 3hRa7GZINl__3qu5l1bP0Z1Q0yEpKtnbDjY4CKOQcjS8MoIxKq._7zfp._BBGLaI0JlKuKBREyuC
 MjHE_zurh72lX73n8vOtMBl6cliEOV9C5rDu7gKCPZYn.1nwDsS1rbzSrtpo6rKvSp7cKfIi090f
 yvTPT3WA5v1cBAqxSlrPuHE4levy6.ZnzGcWvtUHi.EqPbJdm95LLmx_bKv7rJF9MseBYKCCQfBI
 raf5VE25ZipT3rGzeECCBu5Y73QFE_oWAKph8trozzIusZr39E2qyv_djIUdmmWojN9ouuSp.LVZ
 4lf8MaQfHy3umpVWa8pzkAwFHBb2Y0XORVf1hnzAypHO2E0b.KIHObGOE9J7neZxDJOYrPIbNUqz
 UaEbAmDT4IXLIJSA2Q_MPJrfaX0kj4xMrUsFp6ibl7ccOhHrKEe3evSpSurErxjInCwpGsnR_eH1
 Xwi0_qPdtJhie.0o_7pkA0456opuD7AUbqU7nMtv4ciM75GDlILzfSfqTQ7MHaeNTbu5maEU686i
 SyX9qcI6_vwv8kZaJ0xE_r0iRKpGrh.Jd.fyvwk86vedXCvJ8kMQMeDcZqZKyhbElCvCCeR7Uibe
 qRxGw.Xs92ig0yTdxaV39ucozqJw.2Wc6H7zMVSliGyz6YZsdayHxC_M_ouGR2YKNUewKc5jvVLg
 uW5GZQY8wxzXUu2Oplz5hDRUMoI7LgpSaS.p1yWVP0jgo6Z6JJvnltXM6sKVbeVhpfyOLSi9Qcvd
 l5g8jsRUEwO4nGbKuWWL43I_4tkywImwJGmVyMCCgGgzUDw6tKg_VaWAD1jD.ejBS16VVbWLpX3n
 zbjdky3KaGOwYwohtmJHH8txq8ZVIIOd9gCXXfQs8mhmM5Z0zWo2ib564_rCz.tCkkPskNwK2uAF
 x_U_5_fsf9RfNGZZLpponqLMpqLFng3wsc_W9gAv1MQyFriiWHxbQ8ws.6oxQIBGQrHJTMn1trp0
 _PC6b5.MqOy8NIv7iamltHKctS8N_jaRgEfoEFtPakPx.c2Xkb4g91_uCIv.IIhOk5xgpFM5.B7j
 XVsygQZtw1Ner1nAvskTTEnJ6ohA1L6opFxXWUJEJ.fwHFA81D9Pr3w6Twu1lD7UUrBqdgezEqSs
 fhX6S7f4aXrAmlmS8xQrNFSfAfNfz_PGfDEK77m_bLBio6V6OEqnt1mYdym70kX.MC6pm0R4sX_o
 8KA11lqfru9IGbwZxe8eQ4VK0yy0esJ7MLPErrCoHkt_E0hkerH2BS2oufRHEId.XcIa5zXPp7Nj
 8Tb.rGmX9SyKjQZdprCKN6qCHojt.HkDgls0oIA1OoGwASMcsogS8V22wzhQXgnHzsniQgprLfA.
 iAleEyr46W11y57e8_laGzp3OyCGx9fmaMhPlD32K7ocVdv8J0Yd1eB6HTgyBwbrhoyVSIvvsu4.
 xkQLTLoOFqVAwuFcVNRkf8FBRDnPiEuW70R5WXSMjXzQ7CyxRh0Sj7JF_U8oeIyB3E78Wy7YMSUM
 rgn02hnOdeBLILWz42DUUD2chuJfyoIqe3EAiIXq..sKZ97QOpmpMjh1JtmTrXf899L.4zQAbfEr
 qhRNefIJPzMa5aMGJWfJbKCsX3LeG3lq859uVL1vXw.y44Y4pShXkdoA3CTktIEy4mNseoPzfFV8
 CjL8nLaf8UtMnVvKe5qxNWK6uqQE.RCqD3.jK93naTG9ixHNeXMjHaV3vJmOCKcDtX11icY6ATe1
 6gCM_JXpFFcF_mHoPqv7x0lXKfDJjPC05mfeFey_ktd7w3DvJ2tqMAtwaU3_ka_8UEpZcSpryk7b
 LFZey5WtmsQaWaNSkrXulx4mzk7ecKC82DJvz.ME16VbnWefh.73xDlzEF9xO1YCnFML88L0q4nj
 giR_2baTihs.gG3mV8Snqpj9_g4DZ2b7885JULY_gBoYaMMQO6fLgWSMmXD3WiO0as0PqpcM6Efe
 f
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 18 Nov 2022 00:57:33 +0000
Received: by hermes--production-bf1-5878955b5f-h4zdf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8036e422bcdeb31cf3b98279f7d3c1ea;
          Fri, 18 Nov 2022 00:57:32 +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.200.110.1.12\))
Subject: Re: lsof crashes in Arm Optimized Routines
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <490902644.115954.1668511998644@localhost>
Date: Thu, 17 Nov 2022 16:57:20 -0800
Cc: "freebsd-arm@freebsd.org" ,
 Andrew Turner 
Content-Transfer-Encoding: quoted-printable
Message-Id: <690511F4-25A6-41E8-A75A-FFE80C352DFA@yahoo.com>
References: <1331707040.259440.1668459233836@localhost>
 <490902644.115954.1668511998644@localhost>
To: Ronald Klop 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-2.97 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	NEURAL_HAM_SHORT(-0.47)[-0.469];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-Rspamd-Queue-Id: 4NCz0J42w1z3n1y
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

> On Nov 15, 2022, at 03:33, Ronald Klop  wrote:
>=20
> Sorry for the noise.
>=20
> But I cannot reproduce this today. I can scroll back in my terminal =
and see the command and error from yesterday, but running the same again =
just works.

FYI:=20

I do not have specifics any more, but I'll note that I've seen
such lsof behavior of failing at one time and later working
without any installed updates to it or the system between. I
rarely use lsof and, so, this was not recently.

I've no clue how to cause the failure(s) to show up. I've no
clue how common the issue is. But, over time, it is not just
you.

>=20
> Van: Ronald Klop 
> Datum: maandag, 14 november 2022 21:53
> Aan: freebsd-arm@FreeBSD.org, Andrew Turner 
> Onderwerp: lsof crashes in Arm Optimized Routines
> Hi,
>=20
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267760 : =
Segmentation fault in lsof. Program received signal SIGSEGV, =
Segmentation fault.=20
> Invalid permissions for mapped object.=20
> memcpy () at =
/home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64=
/memcpy.S:175=20
> 175 stp D_l, D_h, [dst, 64]!
>=20
> I also remembered this change: =
https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=3D=
1 about Arm Optimized Routines.
>=20
> Could this be related? What can I do to help debug this?
>=20


 =20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Nov 18 01:03:49 2022
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 4NCz7g0nMHz4hjHT
	for ; Fri, 18 Nov 2022 01:03:59 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NCz7d6p3wz3p4W
	for ; Fri, 18 Nov 2022 01:03:57 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com;
	dmarc=none
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 2AI13oaG063758
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Thu, 17 Nov 2022 17:03:50 -0800 (PST)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 2AI13nah063755;
	Thu, 17 Nov 2022 17:03:49 -0800 (PST)
	(envelope-from jmg)
Date: Thu, 17 Nov 2022 17:03:49 -0800
From: John-Mark Gurney 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221118010348.GG3414@funkthat.com>
Mail-Followup-To: Mike Karels , freebsd-arm@freebsd.org
References: <202211071610.2A7GAcHl090048@mail.karels.net>
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: <202211071610.2A7GAcHl090048@mail.karels.net>
X-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 17 Nov 2022 17:03:50 -0800 (PST)
X-Spamd-Result: default: False [-1.75 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.95)[-0.954];
	FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com];
	FREEFALL_USER(0.00)[jmg];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[funkthat.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NCz7d6p3wz3p4W
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

Mike Karels wrote this message on Mon, Nov 07, 2022 at 10:10 -0600:
> This question is not really arm-specific, but I couldn't think of a better
> mailing list for it.
> 
> There are peridic issues reported on small systems like Raspberry Pi
> where people are running buildworld or poudriere and running out of
> memory.  As the user gets no control over the disk layout when installing,
> there is no option to add swap space on the install image.  I have added
> swap space on a USB disk, but this is often not an option.  It occurred
> to me that it might be reasonable to add swap space before expanding
> the root filesystem if there is sufficient space.  I have a prototype,

So, if you boot to single user mode, before growfs runs on first boot,
you can manually add a swap partition at the end of the disk.

You'll need to gpart recover the disk first, so that the gpt (iirc)
covers the remaining disk, and then add a swap partition at the end.
This'll take a bit of math, but isn't too hard.

> and wondered if this is a good thing to do.  Granted, this will often
> create swap on microSD, which is not optimal, but probably better than
> nothing.

The other option is to use a swap file as outlined in the handbook:
https://docs.freebsd.org/en/books/handbook/config/#create-swapfile

> The current prototype creates a swap partition which is 1/10 of the disk
> if the disk is at least 15 GB and the initial root partition is no more
> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> probably enable this by default, but provide a way to disable it via a
> kenv variable and/or a variable in /etc/rc.conf.

I would like to see the ability to drop a file on the FAT file system
so that the system can be configured at first boot w/o requiring someone
to either boot to single user mode, or have a FreeBSD system.  This isn't
too hard, as I have a review already open for it:
https://reviews.freebsd.org/D26713

It makes use of cpercival's cloud init, but slightly modified so it looks
on the fat file system that most arm images have.

with this, it wouldn't be too hard to gin up some commands to automatically
add the swap partition on first boot, but until something like this is
done, it has to be done manually.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From nobody Fri Nov 18 15:45:26 2022
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 4NDLht6dlPz4hjP5
	for ; Fri, 18 Nov 2022 15:45:34 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NDLht39lzz3xSB
	for ; Fri, 18 Nov 2022 15:45:34 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2AIFjRQ5057892;
	Fri, 18 Nov 2022 09:45:27 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id ZoEDD5eod2Mi4gAA4+wvSQ
	(envelope-from ); Fri, 18 Nov 2022 09:45:27 -0600
From: Mike Karels 
To: John-Mark Gurney 
Cc: freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Date: Fri, 18 Nov 2022 09:45:26 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <21BE16D1-0E58-4771-B6DD-7B2EAC6665C5@karels.net>
In-Reply-To: <20221118010348.GG3414@funkthat.com>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221118010348.GG3414@funkthat.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-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 2AIFjRQ5057892
X-Rspamd-Queue-Id: 4NDLht39lzz3xSB
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 17 Nov 2022, at 19:03, John-Mark Gurney wrote:

> Mike Karels wrote this message on Mon, Nov 07, 2022 at 10:10 -0600:
>> This question is not really arm-specific, but I couldn't think of a be=
tter
>> mailing list for it.
>>
>> There are peridic issues reported on small systems like Raspberry Pi
>> where people are running buildworld or poudriere and running out of
>> memory.  As the user gets no control over the disk layout when install=
ing,
>> there is no option to add swap space on the install image.  I have add=
ed
>> swap space on a USB disk, but this is often not an option.  It occurre=
d
>> to me that it might be reasonable to add swap space before expanding
>> the root filesystem if there is sufficient space.  I have a prototype,
>
> So, if you boot to single user mode, before growfs runs on first boot,
> you can manually add a swap partition at the end of the disk.
>
> You'll need to gpart recover the disk first, so that the gpt (iirc)
> covers the remaining disk, and then add a swap partition at the end.
> This'll take a bit of math, but isn't too hard.

Right, that=E2=80=99s what my prototype does (as part of the growfs scrip=
t).

>> and wondered if this is a good thing to do.  Granted, this will often
>> create swap on microSD, which is not optimal, but probably better than
>> nothing.
>
> The other option is to use a swap file as outlined in the handbook:
> https://docs.freebsd.org/en/books/handbook/config/#create-swapfile
>
>> The current prototype creates a swap partition which is 1/10 of the di=
sk
>> if the disk is at least 15 GB and the initial root partition is no mor=
e
>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
>> probably enable this by default, but provide a way to disable it via a
>> kenv variable and/or a variable in /etc/rc.conf.
>
> I would like to see the ability to drop a file on the FAT file system
> so that the system can be configured at first boot w/o requiring someon=
e
> to either boot to single user mode, or have a FreeBSD system.  This isn=
't
> too hard, as I have a review already open for it:
> https://reviews.freebsd.org/D26713
>
> It makes use of cpercival's cloud init, but slightly modified so it loo=
ks
> on the fat file system that most arm images have.
>
> with this, it wouldn't be too hard to gin up some commands to automatic=
ally
> add the swap partition on first boot, but until something like this is
> done, it has to be done manually.

I like the config script idea, but it runs after the root file system is
mounted read/write, and growfs runs before that.  Meanwhile, I have added
the ability to suppress swap space, or set its size, via either /etc/rc.c=
onf
or kernel environment.  I will probably have something ready for review s=
oon.
Meanwhile, if anyone wants to test (especially on GPT), let me know.

		Mike

> --=20
>   John-Mark Gurney				Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."

From nobody Fri Nov 18 22:45:10 2022
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 4NDX160WfVz4hYrD
	for ; Fri, 18 Nov 2022 22:45:14 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NDX153jHFz4FDt
	for ; Fri, 18 Nov 2022 22:45:13 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 2AIMjBGh061026
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Fri, 18 Nov 2022 14:45:11 -0800 (PST)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 2AIMjATs061020;
	Fri, 18 Nov 2022 14:45:10 -0800 (PST)
	(envelope-from jmg)
Date: Fri, 18 Nov 2022 14:45:10 -0800
From: John-Mark Gurney 
To: Mike Karels 
Cc: freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Message-ID: <20221118224510.GI3414@funkthat.com>
Mail-Followup-To: Mike Karels , freebsd-arm@freebsd.org
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221118010348.GG3414@funkthat.com>
 <21BE16D1-0E58-4771-B6DD-7B2EAC6665C5@karels.net>
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: <21BE16D1-0E58-4771-B6DD-7B2EAC6665C5@karels.net>
X-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 18 Nov 2022 14:45:11 -0800 (PST)
X-Rspamd-Queue-Id: 4NDX153jHFz4FDt
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Mike Karels wrote this message on Fri, Nov 18, 2022 at 09:45 -0600:
> On 17 Nov 2022, at 19:03, John-Mark Gurney wrote:
> 
> > Mike Karels wrote this message on Mon, Nov 07, 2022 at 10:10 -0600:
> >> This question is not really arm-specific, but I couldn't think of a better
> >> mailing list for it.
> >>
> >> There are peridic issues reported on small systems like Raspberry Pi
> >> where people are running buildworld or poudriere and running out of
> >> memory.  As the user gets no control over the disk layout when installing,
> >> there is no option to add swap space on the install image.  I have added
> >> swap space on a USB disk, but this is often not an option.  It occurred
> >> to me that it might be reasonable to add swap space before expanding
> >> the root filesystem if there is sufficient space.  I have a prototype,
> >
> > So, if you boot to single user mode, before growfs runs on first boot,
> > you can manually add a swap partition at the end of the disk.
> >
> > You'll need to gpart recover the disk first, so that the gpt (iirc)
> > covers the remaining disk, and then add a swap partition at the end.
> > This'll take a bit of math, but isn't too hard.
> 
> Right, that???s what my prototype does (as part of the growfs script).
> 
> >> and wondered if this is a good thing to do.  Granted, this will often
> >> create swap on microSD, which is not optimal, but probably better than
> >> nothing.
> >
> > The other option is to use a swap file as outlined in the handbook:
> > https://docs.freebsd.org/en/books/handbook/config/#create-swapfile
> >
> >> The current prototype creates a swap partition which is 1/10 of the disk
> >> if the disk is at least 15 GB and the initial root partition is no more
> >> than 1/3 of the disk, but only up to 1.5x of physical memory.  I would
> >> probably enable this by default, but provide a way to disable it via a
> >> kenv variable and/or a variable in /etc/rc.conf.
> >
> > I would like to see the ability to drop a file on the FAT file system
> > so that the system can be configured at first boot w/o requiring someone
> > to either boot to single user mode, or have a FreeBSD system.  This isn't
> > too hard, as I have a review already open for it:
> > https://reviews.freebsd.org/D26713
> >
> > It makes use of cpercival's cloud init, but slightly modified so it looks
> > on the fat file system that most arm images have.
> >
> > with this, it wouldn't be too hard to gin up some commands to automatically
> > add the swap partition on first boot, but until something like this is
> > done, it has to be done manually.
> 
> I like the config script idea, but it runs after the root file system is
> mounted read/write, and growfs runs before that.  Meanwhile, I have added
> the ability to suppress swap space, or set its size, via either /etc/rc.conf
> or kernel environment.  I will probably have something ready for review soon.
> Meanwhile, if anyone wants to test (especially on GPT), let me know.

It looks like growfs can run on read-write UFS filesystems, or at least that's
what the man page implies:

CAVEATS
     When expanding a file system mounted read-write, any writes to that file
     system will be temporarily	suspended until	the expansion is finished.

I haven't tried it though.

https://www.freebsd.org/cgi/man.cgi?query=growfs&apropos=0&sektion=0&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From nobody Sat Nov 19 13:48:44 2022
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 4NDw3f4Y7sz4hqqT
	for ; Sat, 19 Nov 2022 13:48:46 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NDw3f0qjHz3QFb
	for ; Sat, 19 Nov 2022 13:48:46 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2AJDmiuS062793;
	Sat, 19 Nov 2022 07:48:45 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id HamEL7zeeGNH9QAA4+wvSQ
	(envelope-from ); Sat, 19 Nov 2022 07:48:44 -0600
From: Mike Karels 
To: John-Mark Gurney 
Cc: freebsd-arm@freebsd.org
Subject: Re: adding swap when expanding root filesystem
Date: Sat, 19 Nov 2022 07:48:44 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: 
In-Reply-To: <20221118224510.GI3414@funkthat.com>
References: <202211071610.2A7GAcHl090048@mail.karels.net>
 <20221118010348.GG3414@funkthat.com>
 <21BE16D1-0E58-4771-B6DD-7B2EAC6665C5@karels.net>
 <20221118224510.GI3414@funkthat.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: 4NDw3f0qjHz3QFb
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 18 Nov 2022, at 16:45, John-Mark Gurney wrote:

> Mike Karels wrote this message on Fri, Nov 18, 2022 at 09:45 -0600:
>> On 17 Nov 2022, at 19:03, John-Mark Gurney wrote:
>>
>>> Mike Karels wrote this message on Mon, Nov 07, 2022 at 10:10 -0600:
>>>> This question is not really arm-specific, but I couldn't think of a =
better
>>>> mailing list for it.
>>>>
>>>> There are peridic issues reported on small systems like Raspberry Pi=

>>>> where people are running buildworld or poudriere and running out of
>>>> memory.  As the user gets no control over the disk layout when insta=
lling,
>>>> there is no option to add swap space on the install image.  I have a=
dded
>>>> swap space on a USB disk, but this is often not an option.  It occur=
red
>>>> to me that it might be reasonable to add swap space before expanding=

>>>> the root filesystem if there is sufficient space.  I have a prototyp=
e,
>>>
>>> So, if you boot to single user mode, before growfs runs on first boot=
,
>>> you can manually add a swap partition at the end of the disk.
>>>
>>> You'll need to gpart recover the disk first, so that the gpt (iirc)
>>> covers the remaining disk, and then add a swap partition at the end.
>>> This'll take a bit of math, but isn't too hard.
>>
>> Right, that???s what my prototype does (as part of the growfs script).=

>>
>>>> and wondered if this is a good thing to do.  Granted, this will ofte=
n
>>>> create swap on microSD, which is not optimal, but probably better th=
an
>>>> nothing.
>>>
>>> The other option is to use a swap file as outlined in the handbook:
>>> https://docs.freebsd.org/en/books/handbook/config/#create-swapfile
>>>
>>>> The current prototype creates a swap partition which is 1/10 of the =
disk
>>>> if the disk is at least 15 GB and the initial root partition is no m=
ore
>>>> than 1/3 of the disk, but only up to 1.5x of physical memory.  I wou=
ld
>>>> probably enable this by default, but provide a way to disable it via=
 a
>>>> kenv variable and/or a variable in /etc/rc.conf.
>>>
>>> I would like to see the ability to drop a file on the FAT file system=

>>> so that the system can be configured at first boot w/o requiring some=
one
>>> to either boot to single user mode, or have a FreeBSD system.  This i=
sn't
>>> too hard, as I have a review already open for it:
>>> https://reviews.freebsd.org/D26713
>>>
>>> It makes use of cpercival's cloud init, but slightly modified so it l=
ooks
>>> on the fat file system that most arm images have.
>>>
>>> with this, it wouldn't be too hard to gin up some commands to automat=
ically
>>> add the swap partition on first boot, but until something like this i=
s
>>> done, it has to be done manually.
>>
>> I like the config script idea, but it runs after the root file system =
is
>> mounted read/write, and growfs runs before that.  Meanwhile, I have ad=
ded
>> the ability to suppress swap space, or set its size, via either /etc/r=
c.conf
>> or kernel environment.  I will probably have something ready for revie=
w soon.
>> Meanwhile, if anyone wants to test (especially on GPT), let me know.
>
> It looks like growfs can run on read-write UFS filesystems, or at least=
 that's
> what the man page implies:
>
> CAVEATS
>      When expanding a file system mounted read-write, any writes to tha=
t file
>      system will be temporarily	suspended until	the expansion is finish=
ed.
>
> I haven't tried it though.
>
> https://www.freebsd.org/cgi/man.cgi?query=3Dgrowfs&apropos=3D0&sektion=3D=
0&manpath=3DFreeBSD+13.1-RELEASE+and+Ports&arch=3Ddefault&format=3Dhtml

Although that is true, and I have used it, it seems better to do the grow=
fs
step before root is read/write.  As the comment added to the growfs scrip=
t
says, =E2=80=9CWe need to run early, because there might be not enough fr=
ee space
on rootfs for the boot to succeed=E2=80=9D.  (Comment added when =E2=80=9C=
BEFORE: root=E2=80=9D was
added.)  I don=E2=80=99t see any significant advantage in using the confi=
g script
that would outweigh this, although the fstab entry could be added at the
same time.

I have run into a small snag with adding a dump device.  We don=E2=80=99t=
 currently
have =E2=80=98dumpdev=3D=E2=80=9CAUTO=E2=80=9D=E2=80=99 in rc.conf for th=
e arm images.  We could add it when
building, or I could add it when modifying the fstab (in that case, only
when adding a swap partition).  Also, this step runs well after the dumpo=
n
script.  I suppose I can just do =E2=80=9Cdumpon -a=E2=80=9D again if add=
ing to fstab.

		Mike

> -- =

>   John-Mark Gurney				Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."

From nobody Sun Nov 20 21:00:35 2022
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 4NFjbS3N3gz4hGJZ
	for ; Sun, 20 Nov 2022 21:00:36 +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 4NFjbS0HgYz3CJg
	for ; Sun, 20 Nov 2022 21:00:36 +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=1668978036;
	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=74U2iwRIngY1T5eBAiAMFFbA9CJCph33aNkQV09YAQw=;
	b=QljZIeaSzC27TUiH+oFwBlqiL+ropdAPJmyxMuPI0MH+z5+FQJfTKLI8ezrXJ7lNSzjEym
	E5POdjrrXFBmr9kcEi9HJReG49Qf3MIE5aZXdeOEW0kYk2rAQRQSMnQIA2NmwnyPQrm2Q4
	eIq7/2UX6Jq+b3RKflv1f0bgVukTr/s/lNv9NF5SGh7tl0E07vvCsUdZC+w5si0WpD7SU7
	GnDCE79Oajg2aXhac9I+hY1kKKSsui6Qi30uqffWmMCYkEgzvvU9ZSgXBPpAhgIqlzQgWb
	GfoC3YlmP1ozbun1tZ4JoreNA3hp9f1X6tz7kLGipXtdGfEEL3t2MgW30wm6og==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668978036; a=rsa-sha256; cv=none;
	b=wb+lUaNhu35Q06cp/DELKrg5gB5f7+rlUmD8ktM4Dx8Tbty+W3or3ZWthYcwl1M+spoWzZ
	c2A2w8l1oMuNMBoetFZPhydwd+5wj0oh0+V23qPRbJAyM+IoG6qWzAaFf4fSXzIEk5IDft
	R7hdu1fxf8StCAmwhQ4SyDN+HLG9MWJkUn31DB0VHZ2Mmmwjb3TCzB2CxnS2dKSBhWQN4x
	GfGO8uTL94OeAw8Fp3eoRcx6hJRi05oVlzpiG9vQf6fOh9tLLOaVc7+7l0a2olJJtTbZHL
	+9FYWhI5QPWDBbR+cN/7auJd8QS7hMJTtsTLYLgQkZua5+SgzjSM6msSBjXYjg==
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 4NFjbR6B3dzdTF
	for ; Sun, 20 Nov 2022 21:00:35 +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 2AKL0Zv7064905
	for ; Sun, 20 Nov 2022 21:00:35 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2AKL0Z7A064904
	for freebsd-arm@FreeBSD.org; Sun, 20 Nov 2022 21:00:35 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202211202100.2AKL0Z7A064904@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, 20 Nov 2022 21:00:35 +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="16689780357.BFf2c.61250"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16689780357.BFf2c.61250
Date: Sun, 20 Nov 2022 21:00:35 +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.

--16689780357.BFf2c.61250
Date: Sun, 20 Nov 2022 21:00:35 +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.


--16689780357.BFf2c.61250--

From nobody Tue Nov 22 19:13:27 2022
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 4NGv6x5kB6z4hMSB
	for ; Tue, 22 Nov 2022 19:13:29 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NGv6w5WYCz3trf
	for ; Tue, 22 Nov 2022 19:13:28 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net;
	dmarc=none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 2AMJDRCm079263
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Tue, 22 Nov 2022 13:13:27 -0600 (CST)
	(envelope-from mike@mail.karels.net)
Received: (from mike@localhost)
	by mail.karels.net (8.16.1/8.16.1/Submit) id 2AMJDRL6079262;
	Tue, 22 Nov 2022 13:13:27 -0600 (CST)
	(envelope-from mike)
Message-Id: <202211221913.2AMJDRL6079262@mail.karels.net>
To: freebsd-arm@freebsd.org
From: Mike Karels 
Reply-to: mike@karels.net
Subject: Re: adding swap when expanding root filesystem
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-ID: <79260.1669144407.1@mail.karels.net>
Date: Tue, 22 Nov 2022 13:13:27 -0600
X-Spamd-Result: default: False [-0.70 / 15.00];
	FAKE_REPLY(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[karels.net];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[mike];
	HAS_REPLYTO(0.00)[mike@karels.net];
	FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	R_SPF_NA(0.00)[no SPF record]
X-Rspamd-Queue-Id: 4NGv6w5WYCz3trf
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

I seem to have the changes to add swap while expanding the root file
system working fairly well, and I have them in review.  I added some
reviewers, but others are welcome.  I'm interested in feedback on the
defaults, the strategy, and the implementation.

The reviews:

growfs script		https://reviews.freebsd.org/D37462
growfs_fstab helper	https://reviews.freebsd.org/D37463
rc.conf default		https://reviews.freebsd.org/D37464
documentation		https://reviews.freebsd.org/D37465

Thanks for any feedback!

		Mike

From nobody Wed Nov 23 03:08:47 2022
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 4NH5gf6Jtpz4hN2L
	for ; Wed, 23 Nov 2022 03:09:02 +0000 (UTC)
	(envelope-from ehem@m5p.com)
Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256)
	(Client CN "m5p.com", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NH5gd5SSkz3m78
	for ; Wed, 23 Nov 2022 03:09:01 +0000 (UTC)
	(envelope-from ehem@m5p.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com;
	dmarc=none
Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7])
	by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2AN38lbj017452
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Tue, 22 Nov 2022 22:08:53 -0500 (EST)
	(envelope-from ehem@m5p.com)
Received: (from ehem@localhost)
	by m5p.com (8.16.1/8.15.2/Submit) id 2AN38lAa017451
	for freebsd-arm@freebsd.org; Tue, 22 Nov 2022 19:08:47 -0800 (PST)
	(envelope-from ehem)
Date: Tue, 22 Nov 2022 19:08:47 -0800
From: Elliott Mitchell 
To: freebsd-arm@freebsd.org
Subject: Re: FreeBSD/ARM64 on Xen/ARM64
Message-ID: 
References: 
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-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[m5p.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_DN_NONE(0.00)[];
	TAGGED_FROM(0.00)[freebsd]
X-Rspamd-Queue-Id: 4NH5gd5SSkz3m78
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

So I really need someone with a commit bit for ARM64.  Then it is onto
reviewing a bunch of pieces for this project.  As this is simply a
non-commercial project I'm relying on community review time...

One piece of news.  I've finally gotten this operational on top of
INTRNG.  Previously I'd merely been crossing my fingers everything could
be adapted, but now it is finally confirmed.

Since the common interface point has been agreed on, I now urgently need
someone from the ARM64 side of FreeBSD.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include  O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



From nobody Wed Nov 23 18:07:42 2022
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 4NHTcs6LmLz4hx90
	for ; Wed, 23 Nov 2022 18:07:57 +0000 (UTC)
	(envelope-from shedatc@gmail.com)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f])
	(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 4NHTcr36cKz3hH3
	for ; Wed, 23 Nov 2022 18:07:56 +0000 (UTC)
	(envelope-from shedatc@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=exxFl2sn;
	spf=pass (mx1.freebsd.org: domain of shedatc@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=shedatc@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x102f.google.com with SMTP id ci10so10326488pjb.1
        for ; Wed, 23 Nov 2022 10:07:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=sZgNVZJd9O+5xuBoeAggBHiSjHQWk3eGOjH7XjnOfy4=;
        b=exxFl2sncE5Om0P5ctN8XJRMptkUuBQIw6H7HAf8yjKwpcMtr5Aoofvwe08NyHbdLB
         7F7qoVOEI+XwWwie6l2P4gioTLtUd17MRrl/aJO5hVbbHAMjM2jx5ybnwXqBo2onA4rb
         DjsuGuD5pfttaUVDL7a3vNKvX/HzdsaPKjXIPdCCDbd7XpGi64QMEvNt2jWRhZXDU5C3
         w336ef9Op4/+J1DR57elByXFoHyYaRu2f07rLV1oEBagNb+7TsKawpqOoEJmt4JxRDUc
         YIT+ILpjMG/gVRLHEf1jKY04wB7RPjx8+5/CP6KWb31Dx+71l35/Q4kpq9Sc/s06TdNp
         B28Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sZgNVZJd9O+5xuBoeAggBHiSjHQWk3eGOjH7XjnOfy4=;
        b=sPuqQ7X//gxnBa+Y40w1edVAx7kf+fGFf3fOiryMbJwJpRutz31W3QaX+iRS04rOiN
         e5cYQV921GBG6U2CArcBKfXLKijfMtWpqcqF5rV4szQQddO29hhlm8LuKi9wS9gTbF0d
         Q7LMek4/JWc8Rrphk/AtfSpb7u5SG3inBPwRyofcbFUPp5951YAZJB3d2AXfdLmOi415
         yGeTQVCqgEGnI788uk8z2vF2UzUl7x1AvRQmemjwWeuINX+iP/Z1vwUFC0tz9ITs3kbx
         fdzjhitIOp8wI9Fco4UoUCEzM5xA5G2N0gKmp/2S/Uw62WUxR9O35T2qtRyyB8Ec5LMH
         rV8w==
X-Gm-Message-State: ANoB5pnrqBKt7gDa7Q3otsvEfe3saKYXbetjBT4y3J60O87pOEvmGvA2
	5zCp8Z3UeG+3yoZt4MB97O342QmH3o6jinTr2kwomo/K
X-Google-Smtp-Source: AA0mqf4HoT5fEbOAKh1A3N/5MBCnTods3P/QUWHovTycKC9Jq4SbFbZ2vlBUcX17DXCkNOnjfOr/WciBe4CjXrzBOT8=
X-Received: by 2002:a17:903:300c:b0:186:aed3:3ab7 with SMTP id
 o12-20020a170903300c00b00186aed33ab7mr10210049pla.88.1669226874862; Wed, 23
 Nov 2022 10:07:54 -0800 (PST)
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
From: Sheda 
Date: Wed, 23 Nov 2022 19:07:42 +0100
Message-ID: 
Subject: unsubscribe
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000ed108905ee272a28"
X-Spamd-Result: default: False [-3.74 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.74)[-0.738];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102f:from];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4NHTcr36cKz3hH3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ed108905ee272a28
Content-Type: text/plain; charset="UTF-8"



--000000000000ed108905ee272a28
Content-Type: text/html; charset="UTF-8"




--000000000000ed108905ee272a28--

From nobody Fri Nov 25 23:18:34 2022
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 4NJrQv06Fgz4hjXH
	for ; Fri, 25 Nov 2022 23:19:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4NJrQs5rLPz3kgN
	for ; Fri, 25 Nov 2022 23:19:01 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=cKPngNY4;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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=1669418319; bh=9lraywGoE+gb7NyHj1FC2by4qny/6XJy8Yz9GfiR4Lg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=cKPngNY4dStuCuJxsLUniono3Ipx61JfdAhwiae5RuNhCKy2TeNBS5D7uKcQtHEeIVHVWmXIq/kpf6qyXjZQtWDwKnYCrB8AWVbTAGZ7WvpXIA7TOtwZbzKwfwisgCUqXIIb72INi5UafnetZP6dQuCXJwLCxNu2i1z0zIb+SI1S6V4z4aiAedMZ8F0g4vP0ox9zh81oceFq5fJN92huCyrwWdZbnwFK0IxrFdf7z1FczWDOtZw8mTeZuoNefYovk7UVUjUy6W4qTPGUCOkFyXG9S60zKLl6ZW0fl/w/+ExBYi86BSHooHXG9M9Hb5woCsHh4iVbzK4llxCNGfIpjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669418319; bh=o9Pkn+0wFfyyr/e35LJ1Ux+eM0kJzvlUZ8loxt69ow6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HbE/puShxAGWruIjmSQs/dNQhdnt5GJXy2bq+eR7Xue6f3cx9KfXmBjMvWvYliSSucH93PDLiT8Ukx6SQqPDfJUjYFbHXPh22W5EEVBMGFZleSymtpa5+Vl23Ul8bGJIqPwv+LhJ81PX55HHh6gIx5uIqv2/zU1lKUjUGH33Bo2NadqfwsoH2cSsHfQsWRAUydoM7YokBdRHACPOIM4LZWr5vRlIBCV38z4VMSKvBans6uCrisvFrI9q/S/4EX4fvi96zYToDkl8BayYj2oUFfZBTdg/7xPj0J7zaQX8hVplHq7vcvaki1v5DXrBUpYMCnNF/T7rZbBNURvXrbfnSA==
X-YMail-OSG: J_M2DMAVM1kHrfvCxmtVu6fDqe9l_A9OdUE8Rigu4odvX_YlqRBOT8R0rImVJe6
 KxD.uPxaWBu2f3STYhaCNrc_bfhVcnhVw47cTxpqw7AWuEdNkCchw.qCrWPk3vuMoQ4dPkAFham4
 ri8QHe1Vghlq5sGJjN4gwTxCPr9Nu07SszuFEhvjD3k1xHtfrHnTSUgQJfL6LXrYbYiAXTq3SgtV
 bTkz_puoTdYV9U1BIG53LKkVDYe4IJa379vQkVLGwL0gHr6om9rGxbyCyNoZecwgqIANKiFghZTo
 BtCXrMuRLW1KoMDzUKidMgLom9FvmhhLKetFiNPS6_ReumA1Ga_Iienwa3Dr_j5gwOgj_vkS7IyA
 svyDuh1PLzeCkyWekNe1SMXw7.ROKwcRh1Eev35usw2UAggi96tJ1bEgNUXgx3ErYeyLQxDN6lhX
 McU.Kj_6d14RU0jgtNFBXvLIa0k4tzBE9OUgQKPfdyGliE26wzpoKyxvujrxHwj.gV7jFMwhGemB
 ci6WTE90WJntUg.yZCuKYF7L5gDAl17xC5Bffh8rXRP5YKqNyJqYEzxRxZuCSOTwFT14wg5T8gvW
 eUQNHHGxk4wy7jSN_Y3SYvPFj0wrMp0nDm3mA9WHBzBaKtFjTA_0KhRV074DHwbBbnGmmuE8gK7P
 WcD6rksTrc6T.O8VLxs8s7uo9yoI9GY_llC.krPyVbEb1DmMi0_MRWZR1Zx75bQsyJVG2UKdegIJ
 DALNMzQuAZGT0Y1tXudGITUrnCuE38rDg1EX54tjgi4_gBCgfAdLHJgRRxxZ1ODfVTLukO1X0tmp
 jsEZx8dTIdbe1szrl9hibtPGMEAzSQK9wxQis2cGebFVCki7Cz2JjZtRQS0FtomTTDDfZl2RhxlY
 uF5gT_U3K.xzxH_eEIjhIrRju5VKKYUsgpP13pWuNEwndr7fo4InR.e88pG_5djqN0pKHd0i7ts8
 A6.au6xdrNrgxbkI7GwJGc4waOKJ_gjzqfXJuo6fTpupUtKpidg2qGpWBT7Ap48jSPLDOPZO6TIS
 0kjSIyqxJ1_z7PZ0ShRV.hVLEFVphH5DhcWW8fja0wB2h.uF4qD7KxASGovYBuoJE8t9HM1UmWRf
 vcpzxDaSgsV2IQgnd7ORguzUcEO5fmn1Py6en599FlbBUgZumuhvnk8CrvxLynJWnfQkD9AJThVH
 ciwnpH8OfH7PZ27YmRcdsVwruAkmbfTQEhl17kO5lwFRP4ksh6LkwpWMT5feKWH8a4dFAbrpfOD.
 Tdf2G2OwwHm8EDatluasttobxca2ScfxABVHrbtRFXjGdtTm9HRW_Y4T1_0yX2UpPrlHpqAPUsnB
 bk3F0IXd6b.cWwkil0t_hJeKAK48hXQoS1U4gcqANeBqYpkeUGGe3jjCfnOBlfGOmMSiipcdUXbt
 1Ev.ZxpjKeRJatnNCoOrKA2RVXMKJ4XOsoFi8p9B12.gDIpWusgvVf3tnpwu.zvmkB0qonpzjIo1
 qdX5wzY_2lDMnhp3osSHFgZVmbQv3Veks4xtszHmKXq8h.zYmKmeDKaY3A1laBK8PJMc6DnjW1EH
 jSPC1tnd5UIJvqpRYQNI_5Gsg.jLg26FgnAs9q4pDu4RtDkRDMD4.qxd4oZykf0JiT1TvavfOP2G
 WEdMzvnuNILIETOh6EbULFJHRjPVl1ozotMkRkfLJjC3QSDTYqbNwNQ4P5vnXCvHP9oJF1Gz2kyD
 athHa8bikP27YVzV3znss5bx6oUy2rmFsYcgv.rHeLG5IUnDDdCT_Tv.xjg2pKFhZmrw_p7eG7fL
 3IfRkSoYxMXYSh2KadxUJPS1ReGCQqmoZ6_pRcMdH2QQU0cra3TPjKiPdyP.U0Nil0uAKM7fWtty
 cErJSGR8QMh0rTHGr28NV.MM8VFx1NUTrsX3s10JA_5gjTAecrK3BhOLxvVVaFJh14BltNy0FBHy
 XbuBX19V73TVc1hfj4ZATGU5qsIJzvfnf.T2yiFzaQldATCvHMiHxaDGdv8fe5lg5uHPa5B_jwy9
 k0_DQRHsomNZgrtwddwbd_VcRz972exkLkLqccXW9ttdjWx8dJDsw5p.rL_IAs4FgTe0.4GWDHHF
 qYp9JZH_T9ZDDqHPSZyBirJMsLJVOPjyTrPY8opDATmlEBGjWAC2rghIUHjBPM.rRqKXTvgrprVa
 yj0Ro49.xxf8QkFZvfZjKtHrcxa9S3SfYxAaLdNZOFOUryFklaihpmt7SBsWwJZHLjrHbL9skXrN
 ScuMsgZvvUYp528ALNkj6t7inXPnqy3DgL6ZNZQD2FQbQ4S1Ut0YA8vV_oxOxdQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 25 Nov 2022 23:18:39 +0000
Received: by hermes--production-bf1-5878955b5f-n7x8p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5d8c1cdda37ca393576ca51d9e67048f;
          Fri, 25 Nov 2022 23:18:37 +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 11.5 \(3445.9.7\))
Subject: FYI: Example RPi4B 8GiByte "B0T" (3 GiByte limitation) vs. 8 GiByte
 "C0T" device tree differences
Message-Id: <4B293977-1D57-42AD-8031-5821A2E0698C@yahoo.com>
Date: Fri, 25 Nov 2022 15:18:34 -0800
To: freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3445.9.7)
References: <4B293977-1D57-42AD-8031-5821A2E0698C.ref@yahoo.com>
X-Spamd-Result: default: False [-3.09 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.86)[-0.860];
	NEURAL_HAM_SHORT(-0.73)[-0.726];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	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)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-Rspamd-Queue-Id: 4NJrQs5rLPz3kgN
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

I=E2=80=99ve now got access to a RPi4B with a =E2=80=9CC0T=E2=80=9D =
part, an 8 GiByte one. It is a Rev 1.5
as well, the only such that I=E2=80=99ve access to. (There are such =
things as Rev 1.4 =E2=80=9CC0T=E2=80=9D
RPi4B=E2=80=99s as I understand.) Showing various differences vs. the =
old Rev 1.4 8 GiByte
RPi4B:

-       model =3D "Raspberry Pi 4 Model B Rev 1.4";
+       model =3D "Raspberry Pi 4 Model B Rev 1.5=E2=80=9D;
. . .
        system {
-               linux,serial =3D <0x10000000 REDACTED>;
-               linux,revision =3D <0x00d03114>;
+               linux,serial =3D <0x10000000 REDACTED>;
+               linux,revision =3D <0x00d03115>;
        };
. . .
        emmc2bus {
                compatible =3D "simple-bus";
                #address-cells =3D <0x00000002>;
                #size-cells =3D <0x00000001>;
                ranges =3D <0x00000000 0x7e000000 0x00000000 0xfe000000 =
0x01800000>;
-               dma-ranges =3D <0x00000000 0xc0000000 0x00000000 =
0x00000000 0x40000000>;
+               dma-ranges =3D <0x00000000 0x00000000 0x00000000 =
0x00000000 0xfc000000>;
. . .
                pcie@7d500000 {
-                       compatible =3D "brcm,bcm2711-pcie";
+                       compatible =3D "brcm,bcm2711-pcie", =
"brcm,bcm7445-pcie";
. . .
-                       dma-ranges =3D <0x02000000 0x00000004 0x00000000 =
0x00000000 0x00000000 0x00000000 0xc0000000>;
+                       dma-ranges =3D <0x02000000 0x00000004 0x00000000 =
0x00000000 0x00000000 0x00000002 0x00000000>;
. . .

I ignored ethernet addresses, serial numbers, and the like.

I had updated the RPi4B's to have the same EEPROM image =
defaults/critical
vintage in order to make things more comparable (2022-Apr content =
vintage).
For reference:

                bootloader {
                        version =3D =
"507b2360eb46af23c05844b289dc5ae4ecfc3cca";
                        capabilities =3D <0x0000007f>;
-                       update-timestamp =3D <0x6381074a>;
+                       update-timestamp =3D <0x6380a03c>;
                        build-timestamp =3D <0x6267c85c>;
                };

Notes:

I get the information via a sequence that involves booting and looking
at the likes of the text:

Using DTB provided by EFI at 0x7ef0000.

(FYI: prior to the 1st boot this area is not filled in. So a reboot is =
involved
in preparing it for availability at U-Boot time. It survives.)

After that I "shutdown -r now=E2=80=9D and stop it in U-Boot and use (in =
this case):

U-Boot> fdt addr 0x7ef0000
U-Boot> fdt print
/ {
. . .

I record the serial console=E2=80=99s output for later reference.

Doing this for both RPi4B types, allows me to use diff like utilities.

As I understand, this sequence is showing the device tree as it was =
given
to the FreeBSD kernel, not some earlier stage. (The RPi* firmware makes
adjustments before handing information over to U-Boot. U-Boot might do
similarly before handling information over to the FreeBSD loader. That
loader might before handing the above over to the kernel.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com=

From nobody Sat Nov 26 10:44:19 2022
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 4NK7fN2Rbjz4j6wq
	for ; Sat, 26 Nov 2022 10:45:00 +0000 (UTC)
	(envelope-from mats@exmandato.se)
Received: from mailout.mellstrand.net (mailout.mellstrand.net [IPv6:2001:2040:4:1::52])
	(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 "mailout.mellstrand.net", Issuer "ZeroSSL RSA Domain Secure Site CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NK7fL5Kqwz3GFk
	for ; Sat, 26 Nov 2022 10:44:58 +0000 (UTC)
	(envelope-from mats@exmandato.se)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=exmandato.se header.s=mailout header.b=EgA2wnsm;
	spf=pass (mx1.freebsd.org: domain of mats@exmandato.se designates 2001:2040:4:1::52 as permitted sender) smtp.mailfrom=mats@exmandato.se;
	dmarc=pass (policy=reject) header.from=exmandato.se
Received: by mailout.mellstrand.net Sat, 26 Nov 2022 11:44:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=exmandato.se;
	s=mailout; t=1669459478;
	bh=BuVNwoH7zyF18+4YiBdlhwydWvo4+uBMp9dcn/wilGU=;
	h=From:Subject:Date:To;
	b=EgA2wnsmuqbRqS2VOGd//KW+ULJ6l9gCwTXh5E7GgANLOoYgFe996YlXjePDokbYW
	 saTyPBa/RysjZ6FjCjq4F4LEpmpcl46uPWJ4EDlehKbQGm0FcnU8VgrelzX8HKszNg
	 wsPFYJ/7m0C3YhpFBdA6Ags5tVza1C7xImlfph60wrCwe7AKApDtJCPwirwc7F/kJ9
	 3uEmE5qh3kjEy9xOtzfaiHG2rCxg+AyQ/a8ehuSWeaVEuATPVCGEIr1bFDRDIj5qv3
	 7ba37UEg1lEf6tlBr+eXGyw31MyqvvkOnQ3DiSIa9JsXwHcFrXKpcS/CuZxykOnYnD
	 dTMmNPnqQFBDg==
From: Mats Mellstrand 
Content-Type: multipart/signed;
	boundary="Apple-Mail=_C3A9A09C-CBF3-4A9A-86F2-288247EEFAA4";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
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: Kernel panic when using ndp
Message-Id: <78AB907B-0CA8-4D59-A5FF-B8EEF709E7BD@exmandato.se>
Date: Sat, 26 Nov 2022 11:44:19 +0100
To: freebsd-arm@freebsd.org
X-Spamd-Result: default: False [-5.57 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.972];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[exmandato.se,reject];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[exmandato.se:s=mailout];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:3301, ipnet:2001:2040::/32, country:SE];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[exmandato.se:+];
	HAS_ATTACHMENT(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NK7fL5Kqwz3GFk
X-Spamd-Bar: -----
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_C3A9A09C-CBF3-4A9A-86F2-288247EEFAA4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi

When trying to register a proxy  for a ndp entry I received the folloing


Hardware: RPI 4
Memory: 7.84 G
CPU: ARM Cortex-A72
Disk: 108G
OS-version: 13.1-RELEASE-p2


(xxxx:yyyy replaced)

# ndp -s xxxx:yyyy:4::2 dc:a6:32:ed:36:f8 proxy
panic: stack overflow detected; backtrace may be corrupted
cpuid = 2
time = 1669397205
KDB: stack backtrace:
#0 0xffff00000051646c at kdb_backtrace+0x60
#1 0xffff0000004c24c0 at vpanic+0x174
#2 0xffff0000004c2348 at panic+0x44
#3 0xffff0000004fb178 at __stack_chk_fail+0x10
#4 0xffff000000626da4 at handle_rtm_get+0x23c
#5 0xffff000000626954 at route_output+0xbbc
Uptime: 19m46s
Resetting system ...
PM_RSTS: 0x00000020


What am I doing wrong?


/mm

--Apple-Mail=_C3A9A09C-CBF3-4A9A-86F2-288247EEFAA4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEDr+9RcE612tpmSJHQ/tbBFhN7RsFAmOB7gMACgkQQ/tbBFhN
7RtrMBAAio2iw97lrifAbNSVrCGxfbBOqmG1guE2hxGfgIvx0n4M9++Uidyj7Ckn
mh1F9n+T1D/daV09zudAdnJCWkOqnt1j4IE1/oL8xzeO3ff8tG9pjXais99qqs8L
nMdidKzB5DkOWqGH0ltdQwUanrL0+cVWXMbsgm6EodbjF1LalXrF6ctT0Q9zVWUe
tfxiQ3SunPNHVVhuWO3PXyqtJKRNbl1sEx7Sv0REntspqM74a7O8myQ1+mMVeLn8
GTm/kmPTjXBeLV9wVZCGNUKUyPcZ+po95RW/piPI+Sr19hNkQtVhEzrulEef2Gie
zKAELfVMDzmY7ev7nrrStOpAXzldMsm7yCQL/5oFlr9VOmJUJJJ6355+D1cih9aJ
UJ6FJiUhh4um8S0dFCloSC0Uz267u41RT5SG6wWoi27nFCa5O6SqhVcG/+ypYQpa
xmH+1HClt8lyX+8zbcHwvCd27NwkT49e4SbWRUbeAo6dxD/JYOfhdRGVUf6NxTOL
3z9g8x/1pSFXhBlu++gZVso87ahUMFV1KmMSQwJu727rA2rD2dV+UHKHVP1o0o8d
jeeBZp0s55qhTmqJCckIQoh48f+0by4vbR5zo4kWb1eEofK4mQFN/K3m+Vq/Yk3q
ZZSMSA8jClieRRbkq22d+MWYlTbjgRM5CHqrH5594Ys6JyVvYgg=
=GsSu
-----END PGP SIGNATURE-----

--Apple-Mail=_C3A9A09C-CBF3-4A9A-86F2-288247EEFAA4--

From nobody Sun Nov 27 09:07:43 2022
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 4NKjRs6wtQz4jZ2Z
	for ; Sun, 27 Nov 2022 09:07:53 +0000 (UTC)
	(envelope-from SRS0=E1NC=33=klop.ws=ronald-lists@realworks.nl)
Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4NKjRs4VrQz4Fg3
	for ; Sun, 27 Nov 2022 09:07:53 +0000 (UTC)
	(envelope-from SRS0=E1NC=33=klop.ws=ronald-lists@realworks.nl)
Authentication-Results: mx1.freebsd.org;
	none
Date: Sun, 27 Nov 2022 10:07:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1669540063;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=tXPOtfttAiDY7BU/DnokY/wqDbA7ppGHT93QoxcSYCE=;
	b=ZFV74pA8fpgwSFtW4jqwJMm6rjrcvET5RAMGFXWv90HPF2Sn+i3nEiakR1XfgyfWXu2nIb
	LqSLNeuXqMgyveJB1Yd1ef/7j0WbSHXtPUiLAMThCD68gDl/E6dOrsXS2UdL42X4brtgSX
	I6VT4yWzfUN+wckaSwXl+DoWr2g9Z28r4wxEhNm04EkZ3vvsKaWc/0sZF/g8WZMtPAGy8y
	dJstW7pqkakqhM/heu+yRjwVIyrZIhd8dRcIKvMR7SAimj6ebJBBHsIEWyYj08x1is/JVd
	NVNDU5/ZxfTC1UkoGmw21U1OTYkzr1zffINRT0pCEv4tX9vNLaXWniG/ipTDHA==
From: Ronald Klop 
To: Mats Mellstrand 
Cc: freebsd-arm@freebsd.org
Message-ID: <731301167.81.1669540063306@mailrelay>
In-Reply-To: <78AB907B-0CA8-4D59-A5FF-B8EEF709E7BD@exmandato.se>
References: <78AB907B-0CA8-4D59-A5FF-B8EEF709E7BD@exmandato.se>
Subject: Re: Kernel panic when using ndp
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="----=_Part_80_1973039979.1669540062965"
X-Mailer: Realworks (635.634)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4NKjRs4VrQz4Fg3
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_80_1973039979.1669540062965
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Van: Mats Mellstrand 
Datum: zaterdag, 26 november 2022 11:44
Aan: freebsd-arm@freebsd.org
Onderwerp: Kernel panic when using ndp
>=20
> Hi
>=20
> When trying to register a proxy  for a ndp entry I received the folloing
>=20
>=20
> Hardware: RPI 4
> Memory: 7.84 G
> CPU: ARM Cortex-A72
> Disk: 108G
> OS-version: 13.1-RELEASE-p2
>=20
>=20
> (xxxx:yyyy replaced)
>=20
> # ndp -s xxxx:yyyy:4::2 dc:a6:32:ed:36:f8 proxy
> panic: stack overflow detected; backtrace may be corrupted
> cpuid =3D 2
> time =3D 1669397205
> KDB: stack backtrace:
> #0 0xffff00000051646c at kdb_backtrace+0x60
> #1 0xffff0000004c24c0 at vpanic+0x174
> #2 0xffff0000004c2348 at panic+0x44
> #3 0xffff0000004fb178 at __stack_chk_fail+0x10
> #4 0xffff000000626da4 at handle_rtm_get+0x23c
> #5 0xffff000000626954 at route_output+0xbbc
> Uptime: 19m46s
> Resetting system ...
> PM_RSTS: 0x00000020
>=20
>=20
> What am I doing wrong?
>=20
>=20
> /mm
>=20
>=20
>=20
> =C3=82=20

Hi,

Maybe somebody in freebsd-net@ has some insights in this.

Ronald.
=C3=82=20
------=_Part_80_1973039979.1669540062965
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




Van: Mats Mellstrand <mats@exmandato.se>

Datum: zaterdag, 26 november 2022 11:44

Aan: freebsd-arm@freebsd.org

Onderwerp: Kernel panic when using ndp









Hi



When trying to register a proxy  for a ndp entry I received the folloi=
ng





Hardware: RPI 4

Memory: 7.84 G

CPU: ARM Cortex-A72

Disk: 108G

OS-version: 13.1-RELEASE-p2





(xxxx:yyyy replaced)



# ndp -s xxxx:yyyy:4::2 dc:a6:32:ed:36:f8 proxy

panic: stack overflow detected; backtrace may be corrupted

cpuid =3D 2

time =3D 1669397205

KDB: stack backtrace:

#0 0xffff00000051646c at kdb_backtrace+0x60

#1 0xffff0000004c24c0 at vpanic+0x174

#2 0xffff0000004c2348 at panic+0x44

#3 0xffff0000004fb178 at __stack_chk_fail+0x10

#4 0xffff000000626da4 at handle_rtm_get+0x23c

#5 0xffff000000626954 at route_output+0xbbc

Uptime: 19m46s

Resetting system ...

PM_RSTS: 0x00000020





What am I doing wrong?





/mm





=C3=82 









Hi,



Maybe somebody in freebsd-net@ has some insights in this.



Ronald.

=C3=82 
------=_Part_80_1973039979.1669540062965--

From nobody Sun Nov 27 21:00:28 2022
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 4NL1G468xKz4hmqJ
	for ; Sun, 27 Nov 2022 21:00:28 +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 4NL1G43c0kz3F9x
	for ; Sun, 27 Nov 2022 21:00:28 +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=1669582828;
	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=5XuIZGv88eCkjDnPr4uSd72DNtcCkYdGKXCmUy+L8wo=;
	b=KcYa0PYJuCCKJ28kpBD8mUTSX17uphBNYxuj8Nst74J/Mq8S8J40u+nZxhwLmPYj71uN3d
	ek8VnbQ2jUp+frKre9PaqqLa3I8kwnQ/7SAQtOdhGi+zNannMJfba6sj1AHYSDncfZfp78
	9vauPTiJZlfgUP2bvla0ivX39nENr5/LjBa0YDqZ7r7M5J5u7mb9IuUHr063esshreirV1
	Cx2FD2IK8iLPViBGsTffvyCmoDyvYLBi5+2aaqdIle6ovagRtcUaizo3d9S9Fq8NX8Nuoi
	Ux2ZdJo39gO9zQeuguZYA+Ky0p+uJc1VFUo0pvBh/+Xr+lyleWxziq3cMwYAmg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669582828; a=rsa-sha256; cv=none;
	b=U0J0JOLdMclKyCNWDLPtol4N+5+BVArcCzH52B7UVkZy5zERhg1C1eL8wQBEX9QA0iCR0G
	P9RCCUgDur2hpud2IKWxhplLGSKCJijaDXu+sxkyUFCGoasnT481aAfGQhO+pKHiTLLRFb
	0BmvmaNPHmmxvM17g1mmOy+dZEV6eIVIE6uMo3FUcehyk6uMEhByb0kwdBOHElSmHMHewL
	SlN50LCpZFS1f9pXKe+BzBDd6SrsATRz46mUIluj1/2agmqVZGna9ia2NUb5rokhoh8mOM
	u4epP/4CXM4LAUl3YtmykZBcx4lEghwfPepfzLKt2g1v5HgOiQDxxhZ5GOJgZA==
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 4NL1G42kT3z1BJ0
	for ; Sun, 27 Nov 2022 21:00:28 +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 2ARL0SC9042336
	for ; Sun, 27 Nov 2022 21:00:28 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2ARL0SY6042335
	for freebsd-arm@FreeBSD.org; Sun, 27 Nov 2022 21:00:28 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202211272100.2ARL0SY6042335@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, 27 Nov 2022 21:00:28 +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="16695828281.Cf3aC8a6.40312"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16695828281.Cf3aC8a6.40312
Date: Sun, 27 Nov 2022 21:00:28 +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  

1 problems total for which you should take action.

--16695828281.Cf3aC8a6.40312
Date: Sun, 27 Nov 2022 21:00:28 +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 

1 problems total for which you should take action.


--16695828281.Cf3aC8a6.40312--

From nobody Tue Nov 29 06:37:12 2022
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 4NLt1S3Fr6z4hxhF
	for ; Tue, 29 Nov 2022 06:37:32 +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 4NLt1R2WZMz3Hm1
	for ; Tue, 29 Nov 2022 06:37:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=UPvgevrb;
	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=1669703848; bh=orbS+L9jVqHLKNOrNomHmkwMcI3thu0urCD9TAkLjDI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=UPvgevrbfWN4EqdxtGdV3WBR1pfHXXjiqixzP33RP/TmUf9OQTuCx3wFeAm4h85+OGdLsMH8n4vuBQ03ZvASVLlEjDgLdUbBKTphvpjP6nyX6g98CXYsnyv6VKlW6onig0gokCKANn5e7aR9iLfIv4gL6OvCWZIhuYreDCq0Z4CY4I1jmx8qewknt8JIuBpvGZy1RH015AYOYoCvLClTLZoVNRx8POjID/aelTEo5oT29BaDhmRLuLMPJM5LfELu6O35mYO9CSYS3ilgQsAMM5bk7H6Pr6+dKeidM9xp3K2Eo25uxd2u6ZpnoZaKxAtBbEAaY+8+GYGoCbbALj1DeA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669703848; bh=wRAD9RSWMj+rCenE12zziLRjc8JRgGoqLijayOBjB9P=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Q3KZeroAna1t6nYO1ZfjJnQ8RUjoPmJjor50yAzxcdz8DdAfRDH2rz2EZpyJ9Mw8yIpCFmuMbEfAUdz5eNmWAmQ3xGwCHxz9o8zBr8O4Iwd4Gzu/Xf3fVTm89Q0heK8MyVH0q5N2l+LlAeHLrGrW9wi/5nLQApmA29iffSQDv/+2i0In7PD+rd7dAsV3tmahvO8dl40XnjBxnmMTlCYWzos7Iqw7IVli47PRgKLoX6oVX0VRPKgzVRX7IONfsrXvfTsvwjNFaGNAe1LySfxFiLCzgfwyzvT9Tjop2z7Pq0MeWz7N0rRY+u0Go4+eTkG6f9uak7Fy4/C8HwW2IjOwEg==
X-YMail-OSG: aYEWtpgVM1ki5TWX8HzWjbmOON3QUGgFJCDXXVj7AnQfwWFJTpHZDdQADvTY0dK
 8ago0ZwvdLzbjkeJEe39CwkHr2NNTNunUOPQaVNIsvfJDCdV165oFHmd3om6lxqumTI3qbRlZkDR
 ZqQYxUbOSRgr9Pcc_F26.U8aAihJ1pRdb34RD8u7mimwabR19QeKXKpKo9A4Z3LC_ud2q.ahMgky
 ttf3binreuPLqJUjl8h1okSwBWGhAlkm5_By27HVw4ClLtbATVCRxRQ6PQbENup5iqorimWgJKU8
 xPTL45jSVdrRDHGpF1Begyym2yQ6vy9tgGMMj1HH5Ft9Ve0vnk7jX6SmxTamKbu2PjSTmtQGSiXa
 hKx0XX6alNTovncj8ZewvqmNQ8Ai5s6jY0WlIccPIVBwJ3tQnvwArXZXz1Yz_i_3qsuMMF4ZkhzS
 aRR7fmTjrS9CyBwIPzXJ.NEdrpgavmMRzmtk0H0xZadEd7yzmAEwoy5lqMkDTX2IKZ5aJkoRu5lF
 kRFCUpYdrj6_BJRlVchJ5BMYFJUZuuzWQJ5UoggKrvzJiChLyniHbeCxHrpjOQrYof3cbZaCTQsE
 E_BZ8DnSlHShWM.Jc1h.2AkiSSkWTMQ38PJfzwH3cRS_UP5OqejfQt9J0diUvKvxVp5t2bCsZd2j
 nuwNZ1a3WSjxkF52IOqCbfxNQ0Mhgc8QcP5qpiEgPbrr.EBp_IuQ3LCcAf9sUSeQLfYwrId1ikno
 1IktaNxKNJ4Vo8eMWwKiL8ni6zleiKkGrCsq7jrNGdv.gKBUPT0quQVlAYzJ1IWIt1VZ0nP4p9hD
 swTUa4eoxew7G1XPdbVbNk8m_wkoH80jNBEOZVB7UW4f3MYtIMOBuC_NqkQKu4z1dMkLzhci56.5
 MwUocjhFD_UCKeckc0G.YJvTZk1fl1vOyGRs5kfv2KWYhWBxaaXZfhoCtIXjvYg8bRiXMWOzEmLd
 JCBBcaVl.GYTzvU1.id0j8.kkWZjt8k.2UUFb1eQVQs_eH4j.uwtOrdaPfwAbHV4ydKkSalIgDlT
 aID_ALCKO0Hu1wA2HZx6aMh1mn5GE.bdPmEHN7B85XPXgbFtjefTVqIYwVXwZqj9kQQFzLCtGgKm
 pHzGlIr_rQyKBZOqYxi69cfYTLurKpVeqAmnPD7YRnJJG318lbVh2jRMhqVilyIIJlh6TEsqp0bp
 0Kton8M_4EEsLEAlGJ4DNPhZ5tZHpMYa1.Gm3ryPRHoXJNvH4wKEXkyy50sirpCnTv1qa9aG79gY
 L1ufcDSqpBtWieT6xvJWU0kCt3sWL2yyAvzEIfSR8ORSK.KQtqdEt9Hv1G2gloZpyIIXWW98dDes
 ONuGqHPKwSRyI5TVgina0JkV16ck5QWlgvO8R553R2f3gkBxqcO.WRmZ7i98neHGitjmaPjD8hE8
 gdSrFn030ZHxVsUM9i31QTfgWrDFicpgvR09tcDlnZG8JZAFjcKzxeC_S_lQVyvXraodeXH9.2nB
 KNCLlQ2.01ifGT_L7FDOQcrhfddpfvShNHEccuSevEhAQHy8jenq.9qQsTrIV3Ex.js3o279_oJe
 Sc5K65_7CqsmFx6Gy.X9zNghATIVwpUSUXSfrHG.pCffeimEsuomhgInVj9EAvrD68Q4EzCYIGEr
 Lr29e4MEDXN_VI13i5e7AYv7GB_52WNEazDil.PwGJcbMOOlh23lm4p46sicQjpKrJ7gxdFP2qM_
 7w3QfIQYe6QI2Xz6IH8FCzHsa5PSSF4NVCUjjwENwpmGL0Udzyn2tE1qRYE8vbob1urFQ_aUm_3V
 oEkj8hCAsjVcfklut2Vcx7v25PZT1whudXZLf5HaubbxT9vFecjqlAX9mQ7w.aKBfz4K9X8EQaSK
 4bKrPG1zbTkFg_.wHTE6W8Zpb4NwV17N9PcgzUoW7m1d1VBMzcnav00s8lZtUZROztpKWXM8nrtB
 e1ROZEdiSboQStiCkZdrBvAg.huX1KE_oYys9SRVIRnTJfDSPL838Asf38WKU7NMhLCUm1w7WwWB
 asDK8aHTgN8iNx5563VFDr6ABctfHIpRjHG_MEAfmtT7zIfKgdmKhsH4TPEYCBD1aEHeeGq9.Dt8
 ZW8mV_NnS1FYzbFMwPwDFOEYuATpJ2SemXeYya0I_ojUPtBmqaxDCNLIVmvBGK5kzCU.nZ5U.4Uz
 Sucl418LqooO4kCEubD3qEZy_Z0hZJ4ZTdTbEssBGaDwTSuXAmtaamoZnQAFJRVCQjmB6YkgtBg8
 1fHEpgWOq5q0lDxGk7VzlzTztH_asRpQ6gydlW75zcBK5XewCOaxN4HCn7Zribg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Nov 2022 06:37:28 +0000
Received: by hermes--production-bf1-5878955b5f-f7np2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 32900e2692ead9f7324803bed4c53123;
          Tue, 29 Nov 2022 06:37:24 +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.200.110.1.12\))
Subject: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file test
 for UEFI/ACPI contexts: fails far worse than past B0T testing did
Message-Id: 
Date: Mon, 28 Nov 2022 22:37:12 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Spamd-Result: default: False [-2.90 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	NEURAL_HAM_SHORT(-0.40)[-0.403];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]
X-Rspamd-Queue-Id: 4NLt1R2WZMz3Hm1
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

FreeBSD has never updated the ACPI support to deal with
the DMA limitations of the B0T RPi4B parts, here the
xhci related limitation to the lower 3 GiBytes. This was
a test do see what a C0T RPi4B ends up with for behavior
based on the not-adjusted code.

Boot media prepared on a HoneyComb with snapshot (long line split
for readability):

FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 =
03:36:16 UTC 2022
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC

(so, not my build). But I replaced the U-Boot/RPi*-firmware
material with the material for ACPI use (via
/pftf/RPi4/releases/download/v1.33/RPi4_UEFI_Firmware_v1.33.zip
and my usual adjustments):

# ls -Tlat /mnt/
total 4401
drwxr-xr-x   1 root  wheel     4096 Nov 28 21:17:26 2022 =
normal_material_moved_here
-rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 config.txt
-rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 =
config.txt.uefi_m_m_fbsd
drwxr-xr-x   1 root  wheel     4096 Jun 28 20:47:10 2022 EFI
drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 firmware
drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 overlays
-rwxr-xr-x   1 root  wheel    51543 Mar  7 09:06:24 2022 =
bcm2711-rpi-4-b.dtb
-rwxr-xr-x   1 root  wheel    51675 Mar  7 09:06:24 2022 =
bcm2711-rpi-400.dtb
-rwxr-xr-x   1 root  wheel    52128 Mar  7 09:06:24 2022 =
bcm2711-rpi-cm4.dtb
-rwxr-xr-x   1 root  wheel  2241376 Mar  7 09:06:24 2022 start4.elf
-rwxr-xr-x   1 root  wheel     5352 Mar  7 09:06:22 2022 fixup4.dat
drwxr-xr-x  58 root  wheel       65 Mar  7 09:04:04 2022 ..
-rwxr-xr-x   1 root  wheel  2031616 Mar  7 09:03:46 2022 RPI_EFI.fd
-rwxr-xr-x   1 root  wheel     5067 Mar  7 08:57:38 2022 Readme.md
-rwxr-xr-x   1 root  wheel      230 Mar  7 08:57:38 2022 =
config.txt.uefi_rpi4_orig
-rwxr-xr-x   1 root  wheel        0 Sep 13 14:15:28 2020 timeout
drwxr-xr-x   1 root  wheel    16384 Dec 31 16:00:00 1979 .

Also I had put in place for the duplicate and diff/cmp
test use the large file in the below:

# ls -Tlat
total 27064356
drwxr-xr-x   2 root  wheel          512 Nov 29 05:23:24 2022 .
-rw-------   1 root  wheel         1498 Nov 29 05:23:24 2022 .sh_history
-rw-------   1 root  wheel          163 Nov 29 04:12:52 2022 .history
-rw-r--r--   1 root  wheel         1191 Nov 29 04:11:02 2022 .shrc
-rw-r--r--   1 root  wheel  27707039744 Nov 28 19:11:23 2022 =
larger-than-RAM.tar
-rw-r--r--   1 root  wheel          328 Nov 23 04:07:48 2022 .login
-rw-r--r--   2 root  wheel         1023 Nov 23 04:07:48 2022 .cshrc
-rw-r--r--   2 root  wheel          507 Nov 23 04:07:48 2022 .profile
-rw-r--r--   1 root  wheel           80 Nov 23 04:07:38 2022 .k5login
drwxr-xr-x  20 root  wheel          512 Mar  7 17:03:52 2022 ..

Then I booted it on the C0T RPi4B and did the test after
logging in. The result was:

# cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5
xhci_interrupt: host system error
xhci_interrupt: host controller halted
xhci_interrupt: host system error
xhci0: Resetting controller
uhub1: at usbus1, port 1, addr 1 (disconnected)
ugen1.2:  at usbus1 (disconnected)
uhub2: at uhub1, port 1, addr 1 (disconnected)
uhub2: detached
ugen1.3:  at usbus1 (disconnected)
umass0: at uhub1, port 2, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 95 8a 40 00 08 00 00=20
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n 000000000014 detached
g_vfs_done():ufs/rootfs[WRITE(offset=3D65094778880, =
length=3D1048576)]error =3D 6
UFS: forcibly unmounting /dev/ufs/rootfs from /
g_vfs_done():ufs/rootfs[WRITE(offset=3D65095827456, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65096876032, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65097924608, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65098973184, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65100021760, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65101070336, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65102118912, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65103167488, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65104216064, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65105264640, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65106313216, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65107361792, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65108410368, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65109458944, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65110507520, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65111556096, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65112604672, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65113653248, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65114701824, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65115750400, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65116798976, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65117847552, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65118896128, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65119944704, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65120993280, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65122041856, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65123090432, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65124139008, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65125187584, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65126236160, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65127284736, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65128333312, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65129381888, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65130430464, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65131479040, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65132527616, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65133576192, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65134624768, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65135673344, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65136721920, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65137770496, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65138819072, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65139867648, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65140916224, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65141964800, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65143013376, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65144061952, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65145110528, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65146159104, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65147207680, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65148256256, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65149304832, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65150353408, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65151401984, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65152450560, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65153499136, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65154547712, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65155596288, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65156644864, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65157693440, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65158742016, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65159790592, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65160839168, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65161887744, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65162936320, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[READ(offset=3D80762896384, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D655818752, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1311309824, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1311342592, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1311539200, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1314488320, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806696448, length=3D28672)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D56380817408, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D57691996160, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D58347585536, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60314353664, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D61625532416, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D62281121792, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D62936711168, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D63592300544, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D64247889920, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D64903479296, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65086849024, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65087897600, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65088946176, length=3D589824)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D65093730304, =
length=3D1048576)]error =3D 6
larger-than-RAM.tar: Device not configured
pid 668 (sh), jid 0, uid 0: exited on signal 4
pid 365 (devd), jid 0, uid 0: exited on signal 4
(da0:umass-sim0:0:0:0): Periph destroyed
pid 667 (login), jid 0, uid 0: exited on signal 4
umass0: detached
uhub1: detached
uhub1 on usbus1
uhub1:  on =
usbus1
uhub1: 5 ports with 4 removable, self powered
ugen1.2:  at usbus1
uhub2 on uhub1
uhub2:  on =
usbus1
uhub2: 4 ports with 4 removable, self powered
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.3:  at usbus1
umass0 on uhub1
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2
pid 637 (cron), jid 0, uid 0: exited on signal 4


That was all the output before things were hung up.

The old B0T testing got some corrupted blocks in=20
the file copy(ies) in such testing but ran to
completion. But I've not run such tests in some
time.

I may see if my currently somewhat older but patched
kernel has problems as well for C0T RPi4B's, presuming=20
ufficient world compatibility to leave the rest alone.
(I've never had problems with the patched kernel
versions on the B0T RPi4B's.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Nov 29 07:35:36 2022
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 4NLvJn2PnPz4j5wD
	for ; Tue, 29 Nov 2022 07:35:53 +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 4NLvJm03kBz3Pwm
	for ; Tue, 29 Nov 2022 07:35:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="U5jd/uxT";
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 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=1669707350; bh=CnySrWRfoVoH0swi375HLQmNUYU4cRBDuPwDZXUcajQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=U5jd/uxTD/iPIWx7L0waNjXHi5Nji2DXG1rvffjUVaD0FtfzRcUQv7v30+ezFXypGeL4i0vDS1UB3awzMHO7VrrQEJU/9MoTfGukbaoTbZyMtNLeMqTBK4UEK+FbowPmePy3rNfjvb864lePmN91Z+9RprQfc69wEXoRRZDVkoOhPyENdJ6KNCshhKY9jwseUAtfIzctrUrcFDWhjt+FzWxAAvZqy0a/2yeJhOfijah/AR8PTGMUAfdNAR8VOWH7s+XWh6ToO1Aheb8cZDKnvTtIeszCEWrLPSXaedpRf4qXokoeGSsN4ptN1rALBZee/LpTQycCSBcx4VjGqCxoMQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669707350; bh=G0ub+bO9hhpx9HCP6GrUIlgCV8IFdhOXfPEnEWfCgKZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FCLFDIlW3e/TEpGiUSET/6JYQk9kCCj9W5SH2SXIWGjk0ZZMGVElJaJ07gxDkHDgp5v9OhNRuPfmmt62pJIR96VYXet0IUGlzeuRsLx1XtCndxlBBpah6eb/dkWc0LMn706bV9KyG49RXcBMH+w0ymL6h8lUf/anBtiEscTIuwkPrIncDMPUNMgDej7wG4xKF8rI9yVZ7IhBAZDVMvsSuCkOabMqXr1nJrst53gFMc868Xq4B+CCslplfE9HswGS0Ha4UI0h7ca3vE0fRVi0IfSsIfL06D37FSZc83Gb8CLBolmmpJ1LVOHInisRm7Lf/0g3jZ23GZ2bOz/SamuVFg==
X-YMail-OSG: 6y_9VTcVM1nlvoqr.tSKH00DsoeKjjkXGy7DsifZcE40YOOSTMWWvny51Iwa8ns
 1i_e6DJtHE3at0Ruv1nlTEU8DOK.sae8Zz0N8CECDa1P5szxxnnsjbuoJKndpd.prIYewh7pFjsX
 ayxhJ6DrUrVZZEO4i_RtbLJviukg2tY1WOO_ytDbko93LYKWG_N9n8pzjGjkHHaROzKrfkUIWPmo
 1Y4CtjCFJgC6F5G6wqjwpcGcz1DXFGyxBpYJYzkWY0vqGWuy4aG5R7GK1s_JPgztM4jnr0QyVwIQ
 CaB_bA5eRnu9nCXbKP_STO7686xS6zeQXTK4iPm2wRp16L73zW_3bQskDfUkJ2DqH3xX5.zjdh4F
 9rVbT4PvuJ8aeDbOh_7rzFbtInC0fL02MB8HXtnaETBdoSQkoqn3ZtUPFvsWhv4dXJOE5kfZ7Oib
 X779_KQ.HyDqYukwp92Bn4GBLKoFzeMOEIeCGFY3zlXJ0_wgC2ItLkejF5_KVISFLCEoCuxvzoiw
 e9.B16Slx4dV.UYv.okj_aN3_li05UcioYenEKbQi9.27JjfAV7Y82czfdT6kDUo6cgtkSiJ0hyb
 8NmbNvf8NNnhhJVipdXiUWMkodGHXSIYLc4OlXZAPeQnVUNHg5q81m1wsqooqn412Hottrd90f5_
 J6VoW4RzsIaC6k8G58XnvaxPV1jBVlB1.D2Mc7ihYwP1AmiGrmGlXP7jv5zMQZqAZZGP2qzJ.DtC
 vum.biawzh5oqNxoLeWRK2KCJViIKJYCAUqAGkgnrRpg5rIxh3kB9AzM.cUGbPNdlfqZhhb06CuM
 MKKJXkJFNVI5GjFsU9TOEseQlgc5LyRa1bMYScXBAXOoWHXR0J9c7a4nG5mnqYneTEmFo15jm7.w
 o1mBJ8qLKEco5Agb5fP8VCKk0k8jGygqvyg3CyGMWX3_MdVUJ9RNTnmwSF2rfl5z5QBaYKOl5Sga
 pCwYIkp.RIm4GJhZWR8X4.6zCyQ.T6lqQXTFcSWUq6fiSwVQ8Nn.IBDZp6VUcTjaXnzrm_xqldzK
 AIlshQe0kJ6CNxLxpeLZk.NTqqu2AFe0NGIH7lWZ3nkZ6LLIm470HAUoSquxisHO6d3TUusBeKpO
 Sym2gTeLnocB_fYbp5EGmnQiEY77jhB0NUdmPVLJKMr36YiyXvru33P.G59fwGFgt58aSIIDRPar
 MJ4WDjApH3i3cogClAlzSDcEWXArQpsA8gSNt4yXWO4GioKZjhKJTt.doT2hZLF5YUU8vcF23BS7
 87FuFJ8KSPMaZZj3s8zON3Zc9gyBjx9UgUSzR.8zpT4mONJbNai_PukhUc9bH9CUP937BbCHHU_a
 GPKLfSYb9vEhIIMjZ4__Pymbzgi3Bqw1QZoLU6Cg7zykh_plly1Uqi6OX_WwxVZDRV7cWH1_2hue
 9nI1Iov434Msk4bRB58F6UhEjl292gpukG8w9qucDqM.ltenhJIR3QdfKEKHiNAl_HcJkb.PwPsY
 1rkMXtCwnr9PuXiy2lNrCuTct8Pxv8y6aYjI_KTZdUTGyU6PKjA0Y6vNVpYQzFoq64kvvF6XG2Th
 r2iNHiI8JzgjHYwpBTzUe0hOODBDmHnbSDjTXK8k.jO392uRIzYvKj_mO1zlZ..amBuM.1ZV_psR
 Bas1ukLcIk2kGiq3BtULwa56.OFCsAeV1f_iC5JyaQk7.OKg9D6zEYz9dtwVPcicNWNHKXhTcePk
 Qp43ZsvyzVQJ.ag4eOJ2vHcgf8kyP6zPH3tKryA.44vJcJSh0z9isQlnYNfm0AoY4_1EiwUl4vaH
 YhClyz2mdkfDpM0tlX7r62bMUxDKE.WgyPXOkaPK1OsAhkBzH0u8528s0iziA_ghv61ROufxkDDX
 habsoaN3neMTXktHXFvnT.I35wLP2AmW0..Ox2nY7LEDCX_mqt39f3DH1JwB0msxPkgp6dLZVf9y
 JzTw8aMlsHKCSIVKkPlsKVsTaDMvxLHysPXgDtICtsykvwmZ_6MrhJVVc8D2OfmVUZMBQWw.jwKK
 RgVjobqLr4oZgGWUyzgS7ZYI9Y6Q.djNN5tK6t_L9zZvm808_9d5MEW4deqYXxjjwTRhzvP5CgoW
 Uaedtff1c8eYhgbVHzJ4pXJBxC4kNhnCfrfXALHRU.FdvICUmX98jT9O3sRElvON.s4w.mabXbZS
 xuVvMxR.sAWR39_nVTQLxnCCRu_NPeWxV02_vbbPuAa8zq1AydmLs1Vdw3dRWXtscRCdkyxdOyck
 3u0DZgJohOSiQy89q2ZREOni41zVXbJLWtuDZt08bpROIOlpYJIeAUU1E3wBX
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Nov 2022 07:35:50 +0000
Received: by hermes--production-gq1-579bc4bddd-hw848 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8979be254a2533da616f223e6b6fcdab;
          Tue, 29 Nov 2022 07:35:47 +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.200.110.1.12\))
Subject: Re: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file
 test for UEFI/ACPI contexts: fails far worse than past B0T testing did
Date: Mon, 28 Nov 2022 23:35:36 -0800
References: 
To: freebsd-arm 
In-Reply-To: 
Message-Id: <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NLvJm03kBz3Pwm
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

[Summary: using a kernel with my historical patching
did not avoid such failures.]

On Nov 28, 2022, at 22:37, Mark Millard  wrote:

> FreeBSD has never updated the ACPI support to deal with
> the DMA limitations of the B0T RPi4B parts, here the
> xhci related limitation to the lower 3 GiBytes. This was
> a test do see what a C0T RPi4B ends up with for behavior
> based on the not-adjusted code.
>=20
> Boot media prepared on a HoneyComb with snapshot (long line split
> for readability):
>=20
> FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 =
03:36:16 UTC 2022
> =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
>=20
> (so, not my build). But I replaced the U-Boot/RPi*-firmware
> material with the material for ACPI use (via
> /pftf/RPi4/releases/download/v1.33/RPi4_UEFI_Firmware_v1.33.zip
> and my usual adjustments):
>=20
> # ls -Tlat /mnt/
> total 4401
> drwxr-xr-x   1 root  wheel     4096 Nov 28 21:17:26 2022 =
normal_material_moved_here
> -rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 config.txt
> -rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 =
config.txt.uefi_m_m_fbsd
> drwxr-xr-x   1 root  wheel     4096 Jun 28 20:47:10 2022 EFI
> drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 firmware
> drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 overlays
> -rwxr-xr-x   1 root  wheel    51543 Mar  7 09:06:24 2022 =
bcm2711-rpi-4-b.dtb
> -rwxr-xr-x   1 root  wheel    51675 Mar  7 09:06:24 2022 =
bcm2711-rpi-400.dtb
> -rwxr-xr-x   1 root  wheel    52128 Mar  7 09:06:24 2022 =
bcm2711-rpi-cm4.dtb
> -rwxr-xr-x   1 root  wheel  2241376 Mar  7 09:06:24 2022 start4.elf
> -rwxr-xr-x   1 root  wheel     5352 Mar  7 09:06:22 2022 fixup4.dat
> drwxr-xr-x  58 root  wheel       65 Mar  7 09:04:04 2022 ..
> -rwxr-xr-x   1 root  wheel  2031616 Mar  7 09:03:46 2022 RPI_EFI.fd
> -rwxr-xr-x   1 root  wheel     5067 Mar  7 08:57:38 2022 Readme.md
> -rwxr-xr-x   1 root  wheel      230 Mar  7 08:57:38 2022 =
config.txt.uefi_rpi4_orig
> -rwxr-xr-x   1 root  wheel        0 Sep 13 14:15:28 2020 timeout
> drwxr-xr-x   1 root  wheel    16384 Dec 31 16:00:00 1979 .
>=20
> Also I had put in place for the duplicate and diff/cmp
> test use the large file in the below:
>=20
> # ls -Tlat
> total 27064356
> drwxr-xr-x   2 root  wheel          512 Nov 29 05:23:24 2022 .
> -rw-------   1 root  wheel         1498 Nov 29 05:23:24 2022 =
.sh_history
> -rw-------   1 root  wheel          163 Nov 29 04:12:52 2022 .history
> -rw-r--r--   1 root  wheel         1191 Nov 29 04:11:02 2022 .shrc
> -rw-r--r--   1 root  wheel  27707039744 Nov 28 19:11:23 2022 =
larger-than-RAM.tar
> -rw-r--r--   1 root  wheel          328 Nov 23 04:07:48 2022 .login
> -rw-r--r--   2 root  wheel         1023 Nov 23 04:07:48 2022 .cshrc
> -rw-r--r--   2 root  wheel          507 Nov 23 04:07:48 2022 .profile
> -rw-r--r--   1 root  wheel           80 Nov 23 04:07:38 2022 .k5login
> drwxr-xr-x  20 root  wheel          512 Mar  7 17:03:52 2022 ..
>=20
> Then I booted it on the C0T RPi4B and did the test after
> logging in. The result was:
>=20
> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5
> xhci_interrupt: host system error
> xhci_interrupt: host controller halted
> xhci_interrupt: host system error
> xhci0: Resetting controller
> uhub1: at usbus1, port 1, addr 1 (disconnected)
> ugen1.2:  at usbus1 (disconnected)
> uhub2: at uhub1, port 1, addr 1 (disconnected)
> uhub2: detached
> ugen1.3:  at usbus1 (disconnected)
> umass0: at uhub1, port 2, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 95 8a 40 00 08 00 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:   s/n 000000000014 detached
> g_vfs_done():ufs/rootfs[WRITE(offset=3D65094778880, =
length=3D1048576)]error =3D 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=3D65095827456, =
length=3D1048576)]error =3D 6
> . . .
> g_vfs_done():ufs/rootfs[WRITE(offset=3D65088946176, =
length=3D589824)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D65093730304, =
length=3D1048576)]error =3D 6
> larger-than-RAM.tar: Device not configured
> pid 668 (sh), jid 0, uid 0: exited on signal 4
> pid 365 (devd), jid 0, uid 0: exited on signal 4
> (da0:umass-sim0:0:0:0): Periph destroyed
> pid 667 (login), jid 0, uid 0: exited on signal 4
> umass0: detached
> uhub1: detached
> uhub1 on usbus1
> uhub1:  on =
usbus1
> uhub1: 5 ports with 4 removable, self powered
> ugen1.2:  at usbus1
> uhub2 on uhub1
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.3:  at usbus1
> umass0 on uhub1
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number ***REDACTED***
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
> pid 637 (cron), jid 0, uid 0: exited on signal 4
>=20
>=20
> That was all the output before things were hung up.
>=20
> The old B0T testing got some corrupted blocks in=20
> the file copy(ies) in such testing but ran to
> completion. But I've not run such tests in some
> time.
>=20
> I may see if my currently somewhat older but patched
> kernel has problems as well for C0T RPi4B's, presuming=20
> ufficient world compatibility to leave the rest alone.
> (I've never had problems with the patched kernel
> versions on the B0T RPi4B's.)

This is for the older but patched kernel, as reported
in:

# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #43 =
stable/13-n252944-e52aaa644ce1-dirty: Mon Nov  7 09:55:56 PST 2022     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1301509 1301509

Same sort of result using a "C0T" RPi4B:

# cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5
xhci_interrupt: host system error
xhci0: Resetting controller
uhub0: at usbus1, port 1, addr 1 (disconnected)
ugen1.2:  at usbus1 (disconnected)
uhub2: at uhub0, port 1, addr 1 (disconnected)
uhub2: detached
ugen1.3:  at usbus1 (disconnected)
umass0: at uhub0, port 3, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 0e ee 40 00 08 00 00=20
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n 000000000014 detached
g_vfs_done():ufs/rootfs[WRITE(offset=3D60578037760, =
length=3D1048576)]error =3D 6
UFS: forcibly unmounting /dev/ufs/rootfs from /
g_vfs_done():ufs/rootfs[WRITE(offset=3D60579086336, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60580134912, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60581183488, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60582232064, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60583280640, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60584329216, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60585377792, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60586426368, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60587474944, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[READ(offset=3D76881494016, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806729216, length=3D12288)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60576989184, =
length=3D1048576)]error =3D 6
larger-than-RAM.tar: Device not configured
pid 658 (sh), jid 0, uid 0: exited on signal 4
(da0:umass-sim0:0:0:0): Periph destroyed
pid 355 (devd), jid 0, uid 0: exited on signal 4
umass0: detached
pid 657 (login), jid 0, uid 0: exited on signal 4
uhub0: detached
uhub0 on usbus1
uhub0:  on =
usbus1
uhub0: 5 ports with 4 removable, self powered
ugen1.2:  at usbus1
uhub2 on uhub0
uhub2:  on =
usbus1
uhub2: 4 ports with 4 removable, self powered
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.3:  at usbus1
umass0 on uhub0
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2
pid 627 (cron), jid 0, uid 0: exited on signal 4



So, after a fsck_ffs -y via the HoneyComb, trying
on a "B0T" RPi4B got:

# cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_B0T_Rev_1.4
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 93, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 94, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 96, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 97, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 98, cgp: 0x0 !=3D =
bp: 0x849f8490
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 100, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 101, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 102, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 103, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 104, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 105, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 106, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 108, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 109, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 110, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 111, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 112, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 113, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 114, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 115, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 116, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 117, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 118, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 119, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 120, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 121, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 122, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 124, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 125, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 126, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 127, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 128, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 129, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 130, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 131, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 132, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 133, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 134, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 135, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 136, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 137, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 138, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 139, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 140, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 141, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 142, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 143, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 144, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 145, cgp: 0x0 !=3D =
bp: 0xe67a9e2c
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 146, cgp: 0x0 !=3D =
bp: 0x2d282352
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 147, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 148, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 149, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 150, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 151, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 152, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 153, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 154, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 156, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 157, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 158, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 159, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 160, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 161, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 162, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 163, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 164, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 165, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 166, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 167, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 168, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 169, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 170, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 171, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 172, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 173, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 174, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 175, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 176, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 177, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 178, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 179, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 180, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 181, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 182, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 184, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 185, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 186, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 187, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 188, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 189, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 190, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 191, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 192, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 193, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 194, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 195, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 196, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 197, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 198, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 199, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 200, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 201, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 202, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 203, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 204, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 205, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 206, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 207, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 208, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 209, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 210, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 211, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 212, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 213, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 214, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 215, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 216, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 217, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 218, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 220, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 221, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 222, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 223, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 224, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 225, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 226, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 227, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 228, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 229, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 230, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 231, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 232, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 233, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 234, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 235, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 237, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 238, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 239, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 240, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 241, cgp: 0x0 !=3D =
bp: 0x959e70c5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 242, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 243, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 244, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 245, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 246, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 247, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 248, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 249, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 250, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 251, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 252, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 253, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 254, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 255, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 256, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 257, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 258, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 259, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 260, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 261, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 262, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 263, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 264, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 265, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 266, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 267, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 268, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 269, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 270, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 271, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 272, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 273, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 274, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 275, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 276, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 277, cgp: 0x0 !=3D =
bp: 0x8a4cc1df
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 278, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 279, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 280, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 281, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 282, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 283, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 284, cgp: 0x0 !=3D =
bp: 0x6dc9a8a5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 285, cgp: 0x0 !=3D =
bp: 0xa1c0c2f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 286, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 287, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 288, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 289, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 290, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 291, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 292, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 293, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 93, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 94, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 96, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 97, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 98, cgp: 0x0 !=3D =
bp: 0x849f8490
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 100, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 101, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 102, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 103, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 104, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 105, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 106, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 108, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 109, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 110, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 111, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 112, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 113, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 114, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 115, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 116, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 117, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 118, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 119, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 120, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 121, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 122, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 124, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 125, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 126, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 127, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 128, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 129, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 130, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 131, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 132, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 133, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 134, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 135, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 136, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 137, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 138, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 139, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 140, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 141, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 142, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 143, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 144, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 145, cgp: 0x0 !=3D =
bp: 0xe67a9e2c
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 146, cgp: 0x0 !=3D =
bp: 0x2d282352
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 147, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 148, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 149, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 150, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 151, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 152, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 153, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 154, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 156, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 157, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 158, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 159, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 160, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 161, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 162, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 163, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 164, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 165, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 166, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 167, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 168, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 169, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 170, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 171, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 172, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 173, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 174, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 175, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 176, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 177, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 178, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 179, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 180, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 181, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 182, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 184, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 185, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 186, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 187, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 188, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 189, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 190, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 191, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 192, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 193, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 194, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 195, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 196, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 197, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 198, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 199, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 200, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 201, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 202, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 203, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 204, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 205, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 206, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 207, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 208, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 209, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 210, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 211, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 212, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 213, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 214, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 215, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 216, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 217, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 218, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 220, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 221, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 222, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 223, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 224, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 225, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 226, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 227, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 228, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 229, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 230, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 231, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 232, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 233, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 234, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 235, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 237, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 238, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 239, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 240, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 241, cgp: 0x0 !=3D =
bp: 0x959e70c5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 242, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 243, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 244, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 245, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 246, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 247, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 248, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 249, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 250, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 251, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 252, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 253, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 254, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 255, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 256, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 257, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 258, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 259, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 260, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 261, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 262, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 263, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 264, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 265, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 266, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 267, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 268, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 269, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 270, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 271, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 272, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 273, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 274, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 275, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 276, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 277, cgp: 0x0 !=3D =
bp: 0x8a4cc1df
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 278, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 279, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 280, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 281, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 282, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 283, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 284, cgp: 0x0 !=3D =
bp: 0x6dc9a8a5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 285, cgp: 0x0 !=3D =
bp: 0xa1c0c2f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 286, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 287, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 288, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 289, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 290, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 291, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 292, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 293, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 93, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 94, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 96, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 97, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 98, cgp: 0x0 !=3D =
bp: 0x849f8490
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 100, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 101, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 102, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 103, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 104, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 105, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 106, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 108, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 109, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 110, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 111, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 112, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 113, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 114, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 115, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 116, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 117, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 118, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 119, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 120, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 121, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 122, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 124, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 125, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 126, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 127, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 128, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 129, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 130, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 131, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 132, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 133, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 134, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 135, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 136, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 137, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 138, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 139, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 140, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 141, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 142, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 143, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 144, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 145, cgp: 0x0 !=3D =
bp: 0xe67a9e2c
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 146, cgp: 0x0 !=3D =
bp: 0x2d282352
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 147, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 148, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 149, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 150, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 151, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 152, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 153, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 154, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 156, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 157, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 158, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 159, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 160, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 161, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 162, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 163, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 164, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 165, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 166, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 167, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 168, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 169, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 170, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 171, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 172, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 173, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 174, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 175, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 176, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 177, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 178, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 179, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 180, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 181, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 182, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 184, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 185, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 186, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 187, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 188, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 189, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 190, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 191, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 192, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 193, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 194, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 195, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 196, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 197, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 198, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 199, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 200, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 201, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 202, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 203, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 204, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 205, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 206, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 207, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 208, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 209, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 210, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 211, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 212, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 213, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 214, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 215, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 216, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 217, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 218, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 220, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 221, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 222, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 223, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 224, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 225, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 226, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 227, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 228, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 229, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 230, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 231, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 232, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 233, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 234, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 235, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 237, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 238, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 239, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 240, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 241, cgp: 0x0 !=3D =
bp: 0x959e70c5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 242, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 243, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 244, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 245, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 246, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 247, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 248, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 249, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 250, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 251, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 252, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 253, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 254, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 255, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 256, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 257, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 258, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 259, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 260, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 261, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 262, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 263, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 264, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 265, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 266, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 267, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 268, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 269, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 270, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 271, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 272, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 273, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 274, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 275, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 276, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 277, cgp: 0x0 !=3D =
bp: 0x8a4cc1df
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 278, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 279, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 280, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 281, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 282, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 283, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 284, cgp: 0x0 !=3D =
bp: 0x6dc9a8a5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 285, cgp: 0x0 !=3D =
bp: 0xa1c0c2f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 286, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 287, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 288, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 289, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 290, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 291, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 292, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 293, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 93, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 94, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 95, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 96, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 97, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 98, cgp: 0x0 !=3D =
bp: 0x849f8490
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 100, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 101, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 102, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 103, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 104, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 105, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 106, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 108, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 109, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 110, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 111, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 112, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 113, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 114, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 115, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 116, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 117, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 118, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 119, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 120, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 121, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 122, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 124, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 125, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 126, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 127, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 128, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 129, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 130, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 131, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 132, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 133, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 134, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 135, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 136, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 137, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 138, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 139, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 140, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 141, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 142, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 143, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 144, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 145, cgp: 0x0 !=3D =
bp: 0xe67a9e2c
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 146, cgp: 0x0 !=3D =
bp: 0x2d282352
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 147, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 148, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 149, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 150, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 151, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 152, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 153, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 154, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 156, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 157, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 158, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 159, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 160, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 161, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 162, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 163, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 164, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 165, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 166, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 167, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 168, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 169, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 170, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 171, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 172, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 173, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 174, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 175, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 176, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 177, cgp: 0x0 !=3D =
bp: 0x8b9e9592
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 178, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 179, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 180, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 181, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 182, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 184, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 185, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 186, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 187, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 188, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 189, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 190, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 191, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 192, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 193, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 194, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 195, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 196, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 197, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 198, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 199, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 200, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 201, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 202, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 203, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 204, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 205, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 206, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 207, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 208, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 209, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 210, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 211, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 212, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 213, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 214, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 215, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 216, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 217, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 218, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 220, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 221, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 222, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 223, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 224, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 225, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 226, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 227, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 228, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 229, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 230, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 231, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 232, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 233, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 234, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 235, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 237, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 238, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 239, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 240, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 241, cgp: 0x0 !=3D =
bp: 0x959e70c5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 242, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 243, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 244, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 245, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 246, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 247, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 248, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 249, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 250, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 251, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 252, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 253, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 254, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 255, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 256, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 257, cgp: 0x0 !=3D =
bp: 0x75e15800
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 258, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 259, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 260, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 261, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 262, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 263, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 264, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 265, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 266, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 267, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 268, cgp: 0x0 !=3D =
bp: 0xf7b8c5a1
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 269, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 270, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 271, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 272, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 273, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 274, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 275, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 276, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 277, cgp: 0x0 !=3D =
bp: 0x8a4cc1df
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 278, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 279, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 280, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 281, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 282, cgp: 0x0 !=3D =
bp: 0x109fbc9f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 283, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 284, cgp: 0x0 !=3D =
bp: 0x6dc9a8a5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 285, cgp: 0x0 !=3D =
bp: 0xa1c0c2f
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 286, cgp: 0x0 !=3D =
bp: 0xa4392c28
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 287, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 288, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 289, cgp: 0x0 !=3D =
bp: 0xf71ad5e5
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 290, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 291, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 292, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 293, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 295, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 296, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 298, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 302, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 310, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 326, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 358, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 55, cgp: 0xffffffff =
!=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 72, cgp: 0xffffffff =
!=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 297, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 298, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 299, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 300, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 301, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 302, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 303, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 304, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 305, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 306, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 307, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 308, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 309, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 310, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 311, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 312, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 313, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 314, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 315, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 316, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 317, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 318, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 319, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 320, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 321, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 322, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 323, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 324, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 325, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 326, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 327, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 328, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 329, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 330, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 331, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 332, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 333, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 334, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 335, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 336, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 337, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 338, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 339, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 340, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 341, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 342, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 343, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 344, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 345, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 346, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D =
bp: 0x43bc4552
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 348, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 349, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 350, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 351, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 352, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 353, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 354, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 355, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 356, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 357, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 358, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 359, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 360, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 361, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 362, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 363, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 364, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 365, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 366, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 1, cgp: 0xffffffff =
!=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 295, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 296, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 297, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 298, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 299, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 300, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 301, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 302, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 303, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 304, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 305, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 306, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 307, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 308, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 309, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 310, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 311, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 312, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 313, cgp: =
0xffffffff !=3D bp: 0x544dd2da
UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 314, cgp: =
0xffffffff !=3D bp: 0x544dd2da
xhci_interrupt: host system error
xhci0: Resetting controller
uhub1: at usbus1, port 1, addr 1 (disconnected)
ugen1.2:  at usbus1 (disconnected)
uhub2: at uhub1, port 1, addr 1 (disconnected)
uhub2: detached
ugen1.3:  at usbus1 (disconnected)
umass0: at uhub1, port 2, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 16 84 d7 00 00 08 00 00=20
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n 000000000014 detached
g_vfs_done():ufs/rootfs[WRITE(offset=3D193383432192, =
length=3D1048576)]error =3D 6
UFS: forcibly unmounting /dev/ufs/rootfs from /
g_vfs_done():ufs/rootfs[WRITE(offset=3D193384480768, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193385529344, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193386577920, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193387626496, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193388675072, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193389723648, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193390772224, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193391820800, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193392869376, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193393917952, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193394966528, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193396015104, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193397063680, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193398112256, =
length=3D753664)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346174976, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346207744, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346240512, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346273280, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346306048, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1346338816, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1671835648, length=3D4096)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806696448, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806827520, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806860288, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1807908864, length=3D425984)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1808367616, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1809416192, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1810464768, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1811513344, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1812561920, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1813610496, length=3D1048576)]error=
 =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1814659072, length=3D950272)]error =
=3D 6
g_vfs_done():ufs/rootfs[READ(offset=3D78798159872, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193332412416, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193333460992, =
length=3D688128)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D193382383616, =
length=3D1048576)]error =3D 6
larger-than-RAM.tar: Device not configured
pid 658 (sh), jid 0, uid 0: exited on signal 4
pid 355 (devd), jid 0, uid 0: exited on signal 4
(da0:umass-sim0:0:0:0): Periph destroyed
pid 657 (login), jid 0, uid 0: exited on signal 4
umass0: detached
uhub1: detached
uhub1 on usbus1
uhub1:  on =
usbus1
uhub1: 5 ports with 4 removable, self powered
ugen1.2:  at usbus1
uhub2 on uhub1
uhub2:  on =
usbus1
uhub2: 4 ports with 4 removable, self powered
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.3:  at usbus1
umass0 on uhub1
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2
pid 627 (cron), jid 0, uid 0: exited on signal 4


The attempted fsck_ffs -y via teh HoneyComb got:

# fsck_ffs -y /dev/da0s2a
** /dev/da0s2a
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
UFS2 cylinder group 2 failed: cgp->cg_ckhash ("4294967295") !=3D =
calchash ("1414386394")
UFS2 cylinder group 2 failed: cg_chkmagic(cgp) ("0") =3D=3D 0 ("0")
UFS2 cylinder group 2 failed: cgp->cg_cgx ("4294967295") !=3D cg ("2")
UFS2 cylinder group 2 failed: cgp->cg_ndblk ("4294967295") > =
sblock.fs_fpg ("160056")
UFS2 cylinder group 2 failed: cgp->cg_niblk ("4294967295") !=3D =
sblock.fs_ipg ("80128")
UFS2 cylinder group 2 failed: cgp->cg_initediblk ("4294967295") > =
sblock.fs_ipg ("80128")
CYLINDER GROUP 2: INTEGRITY CHECK FAILED
UNEXPECTED SOFT UPDATE INCONSISTENCY

REBUILD CYLINDER GROUP? yes

INCORRECT BLOCK COUNT I=3D172606 (1136576 should be 262976)
CORRECT? yes

INODE 172606: FILE SIZE 581730304 BEYOND END OF ALLOCATED FILE, SIZE =
SHOULD BE 134610944
ADJUST? yes

CYLINDER GROUP 2: FOUND 12416 VALID INODES
UFS2 cylinder group 86 failed: cgp->cg_ckhash ("4294967295") !=3D =
calchash ("1414386394")
UFS2 cylinder group 86 failed: cg_chkmagic(cgp) ("0") =3D=3D 0 ("0")
UFS2 cylinder group 86 failed: cgp->cg_cgx ("4294967295") !=3D cg ("86")
UFS2 cylinder group 86 failed: cgp->cg_ndblk ("4294967295") > =
sblock.fs_fpg ("160056")
UFS2 cylinder group 86 failed: cgp->cg_niblk ("4294967295") !=3D =
sblock.fs_ipg ("80128")
UFS2 cylinder group 86 failed: cgp->cg_initediblk ("4294967295") > =
sblock.fs_ipg ("80128")
CYLINDER GROUP 86: INTEGRITY CHECK FAILED
UNEXPECTED SOFT UPDATE INCONSISTENCY

REBUILD CYLINDER GROUP? yes

INODE CHECK-HASH FAILED I=3D6891264  OWNER=3D1746441326 MODE=3D146121
SIZE=3D10103763192184260801 MTIME=3D??? ?? ??:?? ????=20
FIX? yes

BAD FILE SIZE
UNEXPECTED SOFT UPDATE INCONSISTENCY
 I=3D6891264  OWNER=3D1746441326 MODE=3D146121
SIZE=3D10103763192184260801 MTIME=3D??? ?? ??:?? ????=20
CLEAR? yes

INODE CHECK-HASH FAILED I=3D6891265  OWNER=3D2967366544 MODE=3D22404
SIZE=3D6465710959960971806 MTIME=3D??? ?? ??:?? ????=20
FIX? yes

BAD FILE SIZE
UNEXPECTED SOFT UPDATE INCONSISTENCY
 I=3D6891265  OWNER=3D2967366544 MODE=3D22404
SIZE=3D6465710959960971806 MTIME=3D??? ?? ??:?? ????=20
CLEAR? yes

INODE CHECK-HASH FAILED I=3D6891266  OWNER=3D3055313325 MODE=3D55724
SIZE=3D11494838078614539290 MTIME=3D??? ?? ??:?? ????=20

. . .

(The list of reports is massive and growing. I'll be regenerating
the media content, starting with a dd.)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Nov 29 11:56:25 2022
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 4NM15m0J03z4hdx4
	for ; Tue, 29 Nov 2022 11:56:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30])
	(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 4NM15k2Mfqz42dT
	for ; Tue, 29 Nov 2022 11:56:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=SqcU9cc1;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 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=1669722999; bh=fk+xVeqU1ttKy37ZiGt4mHs1Kd6mu8czRnDJ6TSZgIo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=SqcU9cc1gX344VRMPZDCyrXBQhM1VJOvTWivDisjsSgKq3yyl+IRAAjPXJ3o9zpcuT0YACqzJZhNwJkGmQqTMTYV++uwDtINX7OajIYNKtyeWy4d92ty8662mNeII9LRqQDpGWTZNuwfOZZCbWaEZ/BEFmbnm5VjZNgbuSbUXqDookAKqTrYhBFm8iLQ4aXhLnqIczIV0cUPjKF//gRFR8wa5QjmH1jOeNc6tcdryHC0JIEEmZ1zuGNGggI+stDq8BcdbsJXBgSrf3BeTBLSL8i+TNeb+UhWKlLXB6gQY4FOoL3ZI0lUZGbVFVlQQtTpgpFqAyK30FOGcLy5M7u42w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669722999; bh=CTq+sNgUTnmsilxQlJk+eNrOWfzu2l+TflbKSTfDyJX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=khYSMojd+DVedi90tl2DXWf0DDQ2ndJrDwYc3RSJLUhFBEJWAWAgeHMGEzqtjCM1TLkCF1EiDfJRFS7xRddREubztJ133Oxe2jUiPAUkkmrAekOjtRU9OXB9E2lwbWcgwkBntPfwqnvVsgglXTlGj8iv8cO5+V/DL+ObIRtpXUuVKy/QQ4CyvRpY69HwRcmwR8TxkltXZBNoWrh+/zCujMhNGHhnp+0+5f2PEs5t5FMPbylgFyhHa2MsA74j8MmR/7YNF5LZy/l5ouij/Nyf1jUoYKShJUXT4Z7s0S26fGjIH3saEUUX5Kgut4IfwXq1dp/OsUfCD0AzXgWbqyn7dA==
X-YMail-OSG: Jzow7bEVM1kxahaFz4YmbVE5Eb.oyQePEuSHKgLnysLXmvXGS.KYQHT9OoGi4FJ
 oA76Oqdxov3W3TgQWJ3Sp4azdMpOYnNiGXsZ.Uot2C9uAgAMACG1MOC5D.mZpkpGqbIw9IKJSAEm
 i.JfmeUkIelYe.G7BaYWE_xwvB0FCs01GDsD3ylYBCwLe0u5dmncHpoeIYZnReZu2ZRXdK3Zun6B
 qjPC21IAnMGArOaLK9fX0ELf5GfSfJWaeido8asSptGRcPCsFiVO3yoXOLaIyxtOzLIGY52hZ779
 SikhQJ.Qp_TX5aEibsRxROSyTh7vxT_v6CEqLkp5eV14XatlxidC9uMIx9UJ16bHVvjsVGINrEOM
 CnRiaJFBGJ928.8A1Dozcjug4tywPE1HQnvPJf9o7HxBR20zi3I5ujLJV5oBmydGcy_GWtt_LOKh
 .XSsHWXisEa1AeKqgEvzGqPL48lxmwn6lsohwwe_.EgxPBja24Ug1HmrIFJ0512hW7Qek3Mu1xsh
 V42crjWVbkfV56A8ni10eHkZ4Onb30.f5ItEaksOoY1FPBUSXP6gOGr6ds2vYEwvCtnKRm9VidbY
 GB8JUMw54b_qmYNcbPdw_T7aphHv4rmMjFJ9OaoDXLxXymgU6GayCgWqw6vTzLM7Igdwtf3y2fhS
 Qz0seKIauzvVW9nupi9qjCgmA49Ar9Ehd4u7Ccd5WwxEKN0m4bUP5CXy.Dqp64QhmiQjosTRbkNx
 DRzT8N3YDs067J1Da6PHWNqC75SN.9xq.y4bjHtRTdBXDLbnTQfXX5u58zRaRkaLGkY2Xq2Y0IpL
 pFXoMWvdnqBfSzKZvDuRtUdjAII1MOlbnHPe.SOQQd4qPOd3Euor_uqQ0CMJlM.RmgOnozPx_dZh
 XC4butibaYIQDAzgunVrKRY0PgBLJDMwwl4F.bhJ.IxnoTG.bnTkAvX4mcpJ1XSpqc6zjor42Ew1
 KajUq8wdeOTzBGlyvSijNa47vTHBcL_2xQqcLDtanbcm7X9fEPf9VJrDrXnGqtvzFI50X8fGNJkA
 6fEV3..xks0pBAH53L9Rz7Zu98amLfvUFjNv4oc4yo.dhsGMf6cGi4k2ginFqS7I1UBp_JCouQL9
 GaGTKaYuQ5jeheIwIyLRBI1Jd8BSiNsccKImnd.9BWJ0t5Amu2212oLDI9vQYTj..74CCvUVM7t3
 A0GPgVRB0NTvGoQ6RZy20Rw6ZyJJDbn2WQpiH0U.gbWtf0RPE6Kjqy2XAlt.hYhd67bkZ0_PdV22
 SYD54nIhktHv4bIChA0juAWsjiHo2sSjzj2MMHtO_LULP1Uk9SzaVls21jyshF0rQ6AtBNdFNm5M
 WVr15wHRCFPniUF8hgjxGW3VU2fwiDzohgfQNk6M2Ms6fpg3NLc9a46qEvg8BDdbh8PV264KTURa
 7nxjQk0rt7aWebnqRHAx4Et8CT_M3LGCycyZY3LuPXMfcvY6t.wC.CVfmgNzUCh980ETgza4LyjY
 JOPHv35Di8SfSLkIVyhx8Umtrer2ZJQg455Lf87HqnHJVxh7cOihIy_HHpoDryUrY2v_utivpTt1
 bWviu6shKmowesMCnAVpHPmf7M.mvnoJr9bhZGBU.SrWMoTszS36aBa..JcTlNtS2_EC4qdL1sHc
 S4X595N_kjb7I3CUy51AzDjsMHTS5LHLdswPXu17Z2hhpzaTt.Mo3PEX8FbzG2EljdXfM5E_8P9K
 bN_7r1lVwxvxLIGL3odP7gKRE0R10ravp_DLtTYC2WTpBZx9RqY9DLgWNcDqwz0VEDVFu.bkZXnB
 _8HzP.TVDx2st5qa73bjvNUEbVOfhTh.3dYnt2NEjV1PQJSYaCU0K9Pyi1CoupMqMnH3X9OxtChS
 OflmqkkNSqP_H1.q1cV0F9h8qLx64bPU3OEt_WQuPQTjs_OVKywJsfyfeU2btGuBexrG7InlpQLo
 tAgDS5mKymP.DSB0zFbexvv54kCWP85HM6YQ5d9lcn2EKPbKYJiaRt_CA9vGcQUm2TRpPQrpxLk.
 JUSG9pACQTLnzIcOmyVPRIM6_6ah3Bn3xnZlKI014Azy.UdHjJIyv54yj17cGz.R4HjWeksuhego
 cV7d.BFKBNls9QyPpF27eRt2WqQq0QlbDIUUcSq6bGG.Qxp3uegCtz0i4xIouvPy7CSYdqi4ocO.
 UWaWrH0GaoTl4TByr5t4E7y_Srho3w8fLAxDZdYDmQt4sWHju2mJnMzMswkEuJUtLKIgmgmHVFb1
 DwBVqR6g6fSpuC9H1GEIQbGVSi1KxbD416sHSoUabDc6kajhc94U8hLe8IOD4yA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Nov 2022 11:56:39 +0000
Received: by hermes--production-gq1-579bc4bddd-4x2tb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12f1efbcc0eefbec8897899611c7e577;
          Tue, 29 Nov 2022 11:56:36 +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.200.110.1.12\))
Subject: Re: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file
 test for UEFI/ACPI contexts: fails far worse than past B0T testing did
Date: Tue, 29 Nov 2022 03:56:25 -0800
References: 
 <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com>
To: freebsd-arm 
In-Reply-To: <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com>
Message-Id: <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	NEURAL_HAM_SHORT(-0.98)[-0.977];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NM15k2Mfqz42dT
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Nov 28, 2022, at 23:35, Mark Millard  wrote:

> [Summary: using a kernel with my historical patching
> did not avoid such failures.]
>=20
> On Nov 28, 2022, at 22:37, Mark Millard  wrote:
>=20
>> FreeBSD has never updated the ACPI support to deal with
>> the DMA limitations of the B0T RPi4B parts, here the
>> xhci related limitation to the lower 3 GiBytes. This was
>> a test do see what a C0T RPi4B ends up with for behavior
>> based on the not-adjusted code.
>>=20
>> Boot media prepared on a HoneyComb with snapshot (long line split
>> for readability):
>>=20
>> FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 =
03:36:16 UTC 2022
>> =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
>>=20
>> (so, not my build). But I replaced the U-Boot/RPi*-firmware
>> material with the material for ACPI use (via
>> /pftf/RPi4/releases/download/v1.33/RPi4_UEFI_Firmware_v1.33.zip
>> and my usual adjustments):
>>=20
>> # ls -Tlat /mnt/
>> total 4401
>> drwxr-xr-x   1 root  wheel     4096 Nov 28 21:17:26 2022 =
normal_material_moved_here
>> -rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 config.txt
>> -rwxr-xr-x   1 root  wheel      952 Sep 28 10:24:32 2022 =
config.txt.uefi_m_m_fbsd
>> drwxr-xr-x   1 root  wheel     4096 Jun 28 20:47:10 2022 EFI
>> drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 firmware
>> drwxr-xr-x   1 root  wheel     4096 Apr  4 00:51:20 2022 overlays
>> -rwxr-xr-x   1 root  wheel    51543 Mar  7 09:06:24 2022 =
bcm2711-rpi-4-b.dtb
>> -rwxr-xr-x   1 root  wheel    51675 Mar  7 09:06:24 2022 =
bcm2711-rpi-400.dtb
>> -rwxr-xr-x   1 root  wheel    52128 Mar  7 09:06:24 2022 =
bcm2711-rpi-cm4.dtb
>> -rwxr-xr-x   1 root  wheel  2241376 Mar  7 09:06:24 2022 start4.elf
>> -rwxr-xr-x   1 root  wheel     5352 Mar  7 09:06:22 2022 fixup4.dat
>> drwxr-xr-x  58 root  wheel       65 Mar  7 09:04:04 2022 ..
>> -rwxr-xr-x   1 root  wheel  2031616 Mar  7 09:03:46 2022 RPI_EFI.fd
>> -rwxr-xr-x   1 root  wheel     5067 Mar  7 08:57:38 2022 Readme.md
>> -rwxr-xr-x   1 root  wheel      230 Mar  7 08:57:38 2022 =
config.txt.uefi_rpi4_orig
>> -rwxr-xr-x   1 root  wheel        0 Sep 13 14:15:28 2020 timeout
>> drwxr-xr-x   1 root  wheel    16384 Dec 31 16:00:00 1979 .
>>=20
>> Also I had put in place for the duplicate and diff/cmp
>> test use the large file in the below:
>>=20
>> # ls -Tlat
>> total 27064356
>> drwxr-xr-x   2 root  wheel          512 Nov 29 05:23:24 2022 .
>> -rw-------   1 root  wheel         1498 Nov 29 05:23:24 2022 =
.sh_history
>> -rw-------   1 root  wheel          163 Nov 29 04:12:52 2022 .history
>> -rw-r--r--   1 root  wheel         1191 Nov 29 04:11:02 2022 .shrc
>> -rw-r--r--   1 root  wheel  27707039744 Nov 28 19:11:23 2022 =
larger-than-RAM.tar
>> -rw-r--r--   1 root  wheel          328 Nov 23 04:07:48 2022 .login
>> -rw-r--r--   2 root  wheel         1023 Nov 23 04:07:48 2022 .cshrc
>> -rw-r--r--   2 root  wheel          507 Nov 23 04:07:48 2022 .profile
>> -rw-r--r--   1 root  wheel           80 Nov 23 04:07:38 2022 .k5login
>> drwxr-xr-x  20 root  wheel          512 Mar  7 17:03:52 2022 ..
>>=20
>> Then I booted it on the C0T RPi4B and did the test after
>> logging in. The result was:
>>=20
>> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5
>> xhci_interrupt: host system error
>> xhci_interrupt: host controller halted
>> xhci_interrupt: host system error
>> xhci0: Resetting controller
>> uhub1: at usbus1, port 1, addr 1 (disconnected)
>> ugen1.2:  at usbus1 (disconnected)
>> uhub2: at uhub1, port 1, addr 1 (disconnected)
>> uhub2: detached
>> ugen1.3:  at usbus1 (disconnected)
>> umass0: at uhub1, port 2, addr 2 (disconnected)
>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 95 8a 40 00 08 00 00=20=

>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0:   s/n 000000000014 detached
>> g_vfs_done():ufs/rootfs[WRITE(offset=3D65094778880, =
length=3D1048576)]error =3D 6
>> UFS: forcibly unmounting /dev/ufs/rootfs from /
>> g_vfs_done():ufs/rootfs[WRITE(offset=3D65095827456, =
length=3D1048576)]error =3D 6
>> . . .
>> g_vfs_done():ufs/rootfs[WRITE(offset=3D65088946176, =
length=3D589824)]error =3D 6
>> g_vfs_done():ufs/rootfs[WRITE(offset=3D65093730304, =
length=3D1048576)]error =3D 6
>> larger-than-RAM.tar: Device not configured
>> pid 668 (sh), jid 0, uid 0: exited on signal 4
>> pid 365 (devd), jid 0, uid 0: exited on signal 4
>> (da0:umass-sim0:0:0:0): Periph destroyed
>> pid 667 (login), jid 0, uid 0: exited on signal 4
>> umass0: detached
>> uhub1: detached
>> uhub1 on usbus1
>> uhub1:  on =
usbus1
>> uhub1: 5 ports with 4 removable, self powered
>> ugen1.2:  at usbus1
>> uhub2 on uhub1
>> uhub2:  =
on usbus1
>> uhub2: 4 ports with 4 removable, self powered
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
>> ugen1.3:  at usbus1
>> umass0 on uhub1
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>> umass0:0:0: Attached to scbus0
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number ***REDACTED***
>> da0: 400.000MB/s transfers
>> da0: 228936MB (468862128 512 byte sectors)
>> da0: quirks=3D0x2
>> pid 637 (cron), jid 0, uid 0: exited on signal 4
>>=20
>>=20
>> That was all the output before things were hung up.
>>=20
>> The old B0T testing got some corrupted blocks in=20
>> the file copy(ies) in such testing but ran to
>> completion. But I've not run such tests in some
>> time.
>>=20
>> I may see if my currently somewhat older but patched
>> kernel has problems as well for C0T RPi4B's, presuming=20
>> ufficient world compatibility to leave the rest alone.
>> (I've never had problems with the patched kernel
>> versions on the B0T RPi4B's.)
>=20
> This is for the older but patched kernel, as reported
> in:
>=20
> # uname -apKU
> FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #43 =
stable/13-n252944-e52aaa644ce1-dirty: Mon Nov  7 09:55:56 PST 2022     =
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.=
aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1301509 1301509
>=20
> Same sort of result using a "C0T" RPi4B:
>=20
> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5
> xhci_interrupt: host system error
> xhci0: Resetting controller
> uhub0: at usbus1, port 1, addr 1 (disconnected)
> ugen1.2:  at usbus1 (disconnected)
> uhub2: at uhub0, port 1, addr 1 (disconnected)
> uhub2: detached
> ugen1.3:  at usbus1 (disconnected)
> umass0: at uhub0, port 3, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 0e ee 40 00 08 00 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:   s/n 000000000014 detached
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60578037760, =
length=3D1048576)]error =3D 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60579086336, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60580134912, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60581183488, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60582232064, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60583280640, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60584329216, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60585377792, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60586426368, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60587474944, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[READ(offset=3D76881494016, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806729216, length=3D12288)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60576989184, =
length=3D1048576)]error =3D 6
> larger-than-RAM.tar: Device not configured
> pid 658 (sh), jid 0, uid 0: exited on signal 4
> (da0:umass-sim0:0:0:0): Periph destroyed
> pid 355 (devd), jid 0, uid 0: exited on signal 4
> umass0: detached
> pid 657 (login), jid 0, uid 0: exited on signal 4
> uhub0: detached
> uhub0 on usbus1
> uhub0:  on =
usbus1
> uhub0: 5 ports with 4 removable, self powered
> ugen1.2:  at usbus1
> uhub2 on uhub0
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.3:  at usbus1
> umass0 on uhub0
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number ***REDACTED***
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
> pid 627 (cron), jid 0, uid 0: exited on signal 4
>=20
>=20
>=20
> So, after a fsck_ffs -y via the HoneyComb, trying
> on a "B0T" RPi4B got:
>=20
> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_RPi4B_B0T_Rev_1.4
> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D =
bp: 0x43bc4552
> . . .
> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 314, cgp: =
0xffffffff !=3D bp: 0x544dd2da

Even my patched-kernel + world from the same build
(no vintage mismatch) get such error messages when
mixed with UEFI/ACPI, even on a "B0T" RPi4B that
I've historically used.

Most of my historical use of UEFI/ACPI has been with ZFS
instead of UFS and with main instead of 13.1-STABLE,
unlike here for both, and most of it was before the added
cylinder related tests.

Looks like the cylinder tests may help detect some types
of I/O problems, possibly now exposing problems that were
silent before.

Looks like RPi4B EDK2 UEFI/ACPI should be avoided at this
point. I've reverted my use back to being U-Boot based.

> xhci_interrupt: host system error
> xhci0: Resetting controller
> uhub1: at usbus1, port 1, addr 1 (disconnected)
> ugen1.2:  at usbus1 (disconnected)
> uhub2: at uhub1, port 1, addr 1 (disconnected)
> uhub2: detached
> ugen1.3:  at usbus1 (disconnected)
> umass0: at uhub1, port 2, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 16 84 d7 00 00 08 00 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:   s/n 000000000014 detached
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193383432192, =
length=3D1048576)]error =3D 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193384480768, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193385529344, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193386577920, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193387626496, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193388675072, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193389723648, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193390772224, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193391820800, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193392869376, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193393917952, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193394966528, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193396015104, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193397063680, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193398112256, =
length=3D753664)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346174976, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346207744, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346240512, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346273280, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346306048, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1346338816, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1671835648, length=3D4096)]error =
=3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806696448, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806827520, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806860288, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1807908864, =
length=3D425984)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1808367616, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1809416192, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1810464768, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1811513344, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1812561920, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1813610496, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1814659072, =
length=3D950272)]error =3D 6
> g_vfs_done():ufs/rootfs[READ(offset=3D78798159872, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193332412416, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193333460992, =
length=3D688128)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D193382383616, =
length=3D1048576)]error =3D 6
> larger-than-RAM.tar: Device not configured
> pid 658 (sh), jid 0, uid 0: exited on signal 4
> pid 355 (devd), jid 0, uid 0: exited on signal 4
> (da0:umass-sim0:0:0:0): Periph destroyed
> pid 657 (login), jid 0, uid 0: exited on signal 4
> umass0: detached
> uhub1: detached
> uhub1 on usbus1
> uhub1:  on =
usbus1
> uhub1: 5 ports with 4 removable, self powered
> ugen1.2:  at usbus1
> uhub2 on uhub1
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.3:  at usbus1
> umass0 on uhub1
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number ***REDACTED***
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
> pid 627 (cron), jid 0, uid 0: exited on signal 4
>=20
>=20
> The attempted fsck_ffs -y via teh HoneyComb got:
>=20
> # fsck_ffs -y /dev/da0s2a
> ** /dev/da0s2a
> ** Last Mounted on /
> ** Phase 1 - Check Blocks and Sizes
> UFS2 cylinder group 2 failed: cgp->cg_ckhash ("4294967295") !=3D =
calchash ("1414386394")
> UFS2 cylinder group 2 failed: cg_chkmagic(cgp) ("0") =3D=3D 0 ("0")
> UFS2 cylinder group 2 failed: cgp->cg_cgx ("4294967295") !=3D cg ("2")
> UFS2 cylinder group 2 failed: cgp->cg_ndblk ("4294967295") > =
sblock.fs_fpg ("160056")
> UFS2 cylinder group 2 failed: cgp->cg_niblk ("4294967295") !=3D =
sblock.fs_ipg ("80128")
> UFS2 cylinder group 2 failed: cgp->cg_initediblk ("4294967295") > =
sblock.fs_ipg ("80128")
> CYLINDER GROUP 2: INTEGRITY CHECK FAILED
> UNEXPECTED SOFT UPDATE INCONSISTENCY
>=20
> REBUILD CYLINDER GROUP? yes
>=20
> INCORRECT BLOCK COUNT I=3D172606 (1136576 should be 262976)
> CORRECT? yes
>=20
> INODE 172606: FILE SIZE 581730304 BEYOND END OF ALLOCATED FILE, SIZE =
SHOULD BE 134610944
> ADJUST? yes
>=20
> CYLINDER GROUP 2: FOUND 12416 VALID INODES
> UFS2 cylinder group 86 failed: cgp->cg_ckhash ("4294967295") !=3D =
calchash ("1414386394")
> UFS2 cylinder group 86 failed: cg_chkmagic(cgp) ("0") =3D=3D 0 ("0")
> UFS2 cylinder group 86 failed: cgp->cg_cgx ("4294967295") !=3D cg =
("86")
> UFS2 cylinder group 86 failed: cgp->cg_ndblk ("4294967295") > =
sblock.fs_fpg ("160056")
> UFS2 cylinder group 86 failed: cgp->cg_niblk ("4294967295") !=3D =
sblock.fs_ipg ("80128")
> UFS2 cylinder group 86 failed: cgp->cg_initediblk ("4294967295") > =
sblock.fs_ipg ("80128")
> CYLINDER GROUP 86: INTEGRITY CHECK FAILED
> UNEXPECTED SOFT UPDATE INCONSISTENCY
>=20
> REBUILD CYLINDER GROUP? yes
>=20
> INODE CHECK-HASH FAILED I=3D6891264  OWNER=3D1746441326 MODE=3D146121
> SIZE=3D10103763192184260801 MTIME=3D??? ?? ??:?? ????=20
> FIX? yes
>=20
> BAD FILE SIZE
> UNEXPECTED SOFT UPDATE INCONSISTENCY
> I=3D6891264  OWNER=3D1746441326 MODE=3D146121
> SIZE=3D10103763192184260801 MTIME=3D??? ?? ??:?? ????=20
> CLEAR? yes
>=20
> INODE CHECK-HASH FAILED I=3D6891265  OWNER=3D2967366544 MODE=3D22404
> SIZE=3D6465710959960971806 MTIME=3D??? ?? ??:?? ????=20
> FIX? yes
>=20
> BAD FILE SIZE
> UNEXPECTED SOFT UPDATE INCONSISTENCY
> I=3D6891265  OWNER=3D2967366544 MODE=3D22404
> SIZE=3D6465710959960971806 MTIME=3D??? ?? ??:?? ????=20
> CLEAR? yes
>=20
> INODE CHECK-HASH FAILED I=3D6891266  OWNER=3D3055313325 MODE=3D55724
> SIZE=3D11494838078614539290 MTIME=3D??? ?? ??:?? ????=20
>=20
> . . .
>=20
> (The list of reports is massive and growing. I'll be regenerating
> the media content, starting with a dd.)
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Nov 30 04:05:58 2022
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 4NMQcY31qGz4jYMv
	for ; Wed, 30 Nov 2022 04:06:21 +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 4NMQcX3v5Gz3pW8
	for ; Wed, 30 Nov 2022 04:06:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lbzRfzsM;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 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=1669781175; bh=oGgqeONnv6g77QqCgkvZFfnaqwhwBzWY+24YABi12iI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lbzRfzsMdsYA4uYGZOvxlTM+OLbpmE3RHwpl0STGorZXMu7+ycE1MKDrLrABnkNt6As3aArgoKfwD0YC357v4LleURbNFUp8TAJFMtOiepPNcgIZcpWX+/tBAnlQYY5HAjlBbRXKskO08extvF7klR00o5NYJBu1Rk6GeeJEjjcGtGmhLFuIf6kux6IHiZw2Re3xEt+1Id9NVM/z4GH82O1svIyMcA2i+9cZDqAJamQoOYZyFvPHaZzsU+HLFHIYyB+NPPbuLL/8vM79TRVaMWQsON21dH/KSccz5tUul0rpuOTOhWci/AgB2AK2Kli3sX4Xatq3h8Xf8ZWX6mCHeQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669781175; bh=jV2uh2VGMqpUoWF8zyMVKnsV2Wvxj8bGMhD73mHHwPf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MU+MknOJSDiktlFCIKTn0jm/yXaEgFoVVHNPexvMX57EWlWBJpBQ00fMn6QoVJmRUrTvhZOSHOg+T3za443CD70e2QGnhp48MIkFS8o5Z8Ex/N9AlRLmUje3+BnZ7m522mlENXi4lebpzpGpNcTf7i9O5IcSMn+uDCsFSiKXDZGS7hjUNC2/IqCL5xjz/YRfQHtQ7oUyxbyakZxLmu9k4j9LDT+VJ7LWFwpJLjXIpePsgiRNp0v8riAHYNoMDZnmBsjNnItsnAKL/355HjCTOVTPRQx3crbGqMkybY7S/e/cl+Behv0iEpRX7yGWk8+uSXa9uybEohqXV+is7BKLqQ==
X-YMail-OSG: EjrDvgAVM1moCUrswg1gVPQTl1J.Izs01kPs0S347Gmol5JEnGT7nsjUN.zmz45
 PWK958s9G1kzwVvuvkhh4pV1a4PxubJ_zdUtS4zhgT_vEGy2T4cN01NX91dVwoLKUjKrHjQAfqLQ
 Js6WOIppvjIgNijBt1c7HuU43vJ1NE3vwRqqVVRGCxCSoxNFZVEXGVLvMmH2vMr0FpsBPYvC2XTW
 1earigibVYcQPnhkO2EC5ocldHbWddJWSNHJZqZZYsHoiYNSxLYgSK2axgNFQgEAyHI9el69eleF
 z_nyZdCpsa233JNyPODI.9gh3UITw6Hvn095mMArzJVvN6medG_xqc5GFJWRzBufLQLp3jhnt8H_
 YInTV8kQj5jPudI_eiNE9bcGMaNOC6VGlEfZ92m0p36mV7oIhMatDyhxNF0k.mMzbTy44shPEC0r
 2sgrWJZ9R3PzdcTeqBWC.t6SII61jCFjUzsH4btP7P8ojYr839pNmEcJa8J6sXEmdCA1TZ8aTIPF
 wDCw4exCSL.sluPdQTcGM_Elwdki0idEn3lXThCaVfIAvFfShezG8IlrSWybqyHVDpNnPRxcjWFI
 yApcCm8NZrVgq9POp4kYR1Z1VC3s1j6h6pERFgJl6xkEllLUYj8m50fQPcLAz67zcTzT0UdCalIN
 _PKifwGAB7F9DjI6wJ9iOfyr.2mtS98XQiFD3YgOKOyA7XRCMjhYO2cvf9LlTh6_uIXvKgaCgsSL
 edSzOVgJrqWm7t1GCIF4LCEXXM4AmwY8SUrL.ohZ9RU7i5FBNOVSs75ZlYKfxxXdiBKmQL4Di.bf
 qd1Cfmi4bkjeByYsmTaVi62zL.7AOx6uxxAai8NdV.i3snvtD0.bex1.cO3.sZ4nMPTSMK2spvms
 aJ6zYbTikGeCSfOTs6MmnzzE_IL.Ls3l4e87zrFilOENTUZYVR0QMp7vx2lYCc4ETPpXpGKGN2zD
 .MjNl6GlAhCLoli9aptPNCVY.JLkSaf5vwdul0ZL5CCpYAcpobu1NZI3cd4B_XW6GekyKUEiMdLQ
 Z_f54UqeHk7ITp_wsYI6MumdxJk8lirv9ILPA2poECK7XIJb3ZXGiwCvth9Dwr_OsIptYO4txZaX
 IHyaje7Vmj1vF_WKkqC7V5mNnjs8lAWiwGQ5gcYO21ux7mqLT_TyBc8XU5b1LQNLlVIBEoqwwRr2
 WEEZCy2caEPMKOTxGPdmCNtRZlgjkh_rZdQbe3VvmR4BObmbJBMxBRT5a6iWH9i86joPFAspyRcz
 hEU4sbVA1xJe9whKzjjQyllcDBYoRSQa4VH_sJLI_OBYCFRhqwIt6y8FitX37fC5GZp8qy0rk1QT
 8u5NSKgY9BdiTscbJlOeqr.BWP8hWk2Pla9fKq5lMTkRgoMvXG9uPjDu7ZtW.o_aWOA4rvwtTzLG
 PwfAmB6obV66d5XINRCJPN_vV0iiAXdCIMzA8xgSmGRPXMePtx3EXpgHyFEdo7w1X6IlY7zlIBTy
 Gf71RhodFgXK7kXX3u7vyJzqhnCPusY_M6vA..bu328O2zxpdbWlr8.Xu.mAzfGvZNc2Le31c7A.
 5AdBPRqekL9n8mmogEYGBlEOkhrkxwsR1qxaUDtYUZJDkXdMHGdA4rlk6mFthm2I35cdReboTfob
 YxMtnd5YB.4MSmG2Bf6Dox8Rcgj1Jsh5j3XnnlVfE91lC4HkC7rHcxBhNMzsuS7gilq0rtu9I9Sv
 FtK69BUFUz6T1SjniSw3h6KrccL8IrXcBufy4lB2MQ7cE3JOonz9PTyiiXLNT8Mn15Q.5iK2S2SK
 ihy9Cu2rgdZ69pBd.M2f9XleQNrBPmbPMOQy9ulRx4Bi8osuwHZEdsKraN15DUd.C2Ofqt4OS08r
 6JsZpjt7MtjgyEJf_GnUmIo.ZTvwZXnRODDoEYI3HwKUWzXFZvFk7gyajS6bzbgM7fiakk8ritr_
 Ve5KfFDXksjtgeucsKdpuch2QCsYX_5fwC5RU1ozuiIQOBWqfTxQVO7J5BmIPimhfd2BKCxdQ7Vb
 EuMGYPYdUOPbJy2xMnFZUVOO.odzVw_v5YqGVwpYeHDPeJGdr6hww0V_ki8GiJ.Prl69yUwzbnOb
 EWGrPEliZbrz4YkByMeoFr4PtIIlWeGopoPDrVGBzXKEwzx8uHMgMwlqIMet45TOHiR79l70y87M
 zNXi7T0eWuyDSvHiSNPLM_itbDuHI4K2llU7qxuXR3ikhIHOXodK0L4JOmP2bOUwGwJ1SYImPya8
 _n1G4Fa78nnxARaiCsC_UxQ6.wth3lgWGap8GFhO7ZpewOQNTL1RfN0NoTZH7afM8NerTO8Rm1_e
 Y
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Nov 2022 04:06:15 +0000
Received: by hermes--production-bf1-5878955b5f-sffnj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 78b1369be2a065e2ef8855055a5f962e;
          Wed, 30 Nov 2022 04:06: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.200.110.1.12\))
Subject: Re: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file
 test for UEFI/ACPI contexts: fails far worse than past B0T testing did
From: Mark Millard 
In-Reply-To: <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com>
Date: Tue, 29 Nov 2022 20:05:58 -0800
Cc: "mckusick@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com>
 <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
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];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]
X-Rspamd-Queue-Id: 4NMQcX3v5Gz3pW8
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Two things. First:

It turns out that I misremembered: Only my normal main [so: 14]
builds have the patching of sys/dev/acpica/acpi.c at this point.
Thus I have not yet actually tested anything with the patching
related to ACPI XHCI DMA handling.

There is still a chance that the "cylinder checksum failed"
messages would be eliminated by such patching. (This may make
my request for information from mckusick@ related to "cylinder
checksum failed" messages not so important.)

(My other builds do have some patching of
sys/arm/broadcom/bcm2835/bcm2838_pci.c and
sys/arm/broadcom/bcm2835/bcm2838_xhci.c that my main also has.
That is appearently what I was misremembering the details of.)


Second:

As a cross-check, I again set up the USB3 SSD media based on:

FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221123-b51ee7ac252c-253133.img

with a (in this case):

-rw-r--r--   1 root  wheel  27706924032 Nov 29 22:16:51 2022 =
larger-than-RAM.tar

added. I then used it to boot a 16 GiByte MACCHIATObin Double Shot
that is EDK2 UEFI/ACPI based and tried:

# cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
# diff larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
# fsck_ffs /
** /dev/ufs/rootfs (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
25613 files, 14286816 used, 42464044 free (996 frags, 5307881 blocks, =
0.0% fragmentation)

So: it worked fine.

Thus, it does appear that the 2 problems (as shown by
messages):

A) "cylinder checksum failed" messages ("B0T" RPi4B's only?)
and:
B) the message sequences like (both "C0T" and "B0T" RPi4B's):

xhci_interrupt: host system error
xhci0: Resetting controller
uhub0: at usbus1, port 1, addr 1 (disconnected)
ugen1.2:  at usbus1 (disconnected)
uhub2: at uhub0, port 1, addr 1 (disconnected)
uhub2: detached
ugen1.3:  at usbus1 (disconnected)
umass0: at uhub0, port 3, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 0e ee 40 00 08 00 00=20
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:   s/n 000000000014 detached
g_vfs_done():ufs/rootfs[WRITE(offset=3D60578037760, =
length=3D1048576)]error =3D 6
UFS: forcibly unmounting /dev/ufs/rootfs from /
g_vfs_done():ufs/rootfs[WRITE(offset=3D60579086336, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60580134912, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60581183488, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60582232064, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60583280640, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60584329216, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60585377792, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60586426368, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60587474944, =
length=3D1048576)]error =3D 6
g_vfs_done():ufs/rootfs[READ(offset=3D76881494016, length=3D32768)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D1806729216, length=3D12288)]error =
=3D 6
g_vfs_done():ufs/rootfs[WRITE(offset=3D60576989184, =
length=3D1048576)]error =3D 6
larger-than-RAM.tar: Device not configured
pid 658 (sh), jid 0, uid 0: exited on signal 4
(da0:umass-sim0:0:0:0): Periph destroyed
pid 355 (devd), jid 0, uid 0: exited on signal 4
umass0: detached
pid 657 (login), jid 0, uid 0: exited on signal 4
uhub0: detached
uhub0 on usbus1
uhub0:  on =
usbus1
uhub0: 5 ports with 4 removable, self powered
ugen1.2:  at usbus1
uhub2 on uhub0
uhub2:  on =
usbus1
uhub2: 4 ports with 4 removable, self powered
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.3:  at usbus1
umass0 on uhub0
umass0:  on usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number ***REDACTED***
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2
pid 627 (cron), jid 0, uid 0: exited on signal 4

are both tied to issues more specific to aspects that RPi4B's
have involved but that various other EDK2 UEFI/ACPI's do not
present to the FreeBSD kernel. (That wording may be
incomplete for the possibilities but should be suggestive.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Nov 30 08:35:25 2022
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 4NMXbK6lCJz4jHg5
	for ; Wed, 30 Nov 2022 08:35:41 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30])
	(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 4NMXbJ72PCz4CZw
	for ; Wed, 30 Nov 2022 08:35:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=UG07Or02;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 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=1669797337; bh=+tAKCj7XcIITj9dF4nC+oiURNflMjcatEgqGPhnlzV4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UG07Or02tCbZAjPcp8EkOfdnszKlFdtrl+20sHvdrxGdt62PK2pLfSJmv8881Yo3PLPimB+3HT4eW3jaey3VmXDPciLUIeCsuWSLWQItxWiKIt/TEcgLjMUpymxx64RiQsYMhtlz1rUU/3YPRkL/5KsiUgOttzsE7cPNdpL71aSsCxq//xgKX62+oxncEjuMnt9KfNn8p55xJ+m5aJ1yBVKu1fN7HpULheiJAB/P8wS7q+eGcxzdIvIDu9sJWpyLsRTXiMMynT/mYP08gGmc2/g3En9MGbg9YaYLCqNIr2E4/yTn/0j4HbUoytHCutl16nsVeqwhki2aLPZTJDpqOg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669797337; bh=Lk/uQS8pCOz/PkD9FHXZbdGREHnM0Guo78DLDWqK8dU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SlvQi3aesEG/xbkw6jeAy2UK9T7hd0S3cpsxTqDK3ch4XkSaC7qOk49lA+vWH8EjTNE0DPQxSs5/pZ66CE4KZjKYoPaBJHkiv14RGIfsFOpjo6OLPV8vZbs0P+kddaqRGOBKvh5IOLsH+LzXSLzx0Z/kJog5xpy1YXQejZbnKmsAWIw84hrJdTRiTnBHPVMdEykGQgJ5SjZAuF5wPHIkjzQfIjQjpqeFaqKDYIM1gXzHxxD5ahLwkpGaOU2m1WNeC3OI3cYzEFKAxDCjJmcpn5FUplC5wz3zU+w9zsOEDVmyMLP0VNMo4Oo6aLpxI7eLhDT7rSLwi2EIBnmFxOqamg==
X-YMail-OSG: 2Q94J0UVM1lv484HtjBnSN9QKujsxkMRl6NI1VIZzUE1zWEWqKcHNH0iYu8U4na
 XNquEYAflIq_TSpZpcBa9NNwGPyLz.96vWnPnoGFYbr7dfl.B4YIf3UCD8S7J075hYW2RArMhbdU
 gGcOVC.nnLKwecSLvvEfphq9_oTUS_UIrn.IIbMD5jHguorn1a1GrqTAbc9xn9fRkLjnZ00X_1IR
 VHyGEhBtDJzSXuXIjkEKLiU7H7kHg1Z3hznxBEOOQi1pAF6rjaDwTS9e_.1GkrEimdlsdtbIJpml
 zcJTn.SRLNCHNf7bsGKVdty9gaJYVucsgraeL5uIQ8OeYDCjUIAr78TyXjBEzt_oSZGQzoMkrQlj
 nz7E7YyXMKFS_j.JOvVeTfXtAQK0W2rRUn6ooKygDBpMzp5mEZ3xcF0cnb1_9WNj7MbtwSWirINw
 WiEGV7Wb4ETdDyAVZGBJA7id_kdgKTlWoXGb5MIDFg9w0knJfz..Le967KEpcPs_FoqoQ1ksYfji
 sqapIPGIcC5s0yboeIeblXNL9KOLhKqRdQcgffqvgpGN719t0KHlT02A5aEvoI0cb945Hlmg_QLl
 hYTMhzd4UtBdfAsFJaAQ3cByeBL52fX6RBspoCvkE6lgt6lWsnutU4loShi2To1TilPUECKBKO70
 3A7XgAM.X.c752e7lRuxKf6FnjmKqKnnzNZjf9nr0xZ2I0skJ6qTfbsUAJNnWtd1Sus_XAq8YaX8
 gPzG7HEQDqX7uKuryaArl1DSb1ExlEd3ebD4_z5q0uJAADe9z6zxelhOL5wEUifsuUH3uUSbHDbr
 mbNh_UX1sKAyIZkRYTrO3wDf0QgjijCm4evggnNUF_g2Ik.ymwJk.5eIOZbH83Jo_JgcZ8itN2HI
 IrkAR9Bin4udYhbz71fsqZbu2ojnCV2uCseyvTaNPJbllF0SRMM5zEES4ErUBlVRDWuzw0Kg1pFi
 pvBEdAqvQPrsRGzOl_Y6p3C2rAqdexEUbTIEcZWJRBBMVuhbEOy0SV9ugTJM83_VT6CfdPrnczv7
 3DkbfRVYbnd1UJxnkJbKvdpkY3uL1QJDUQVswptpZ75WJJT1Fgikbvob8hUaHXBZ4BFnXeefzS2K
 mv0uexkIhN5Fl9nO9Hh.eQyaj9Q7m0LAPAHe3GjVj1Ei0Rwk4b1PoSI7dZgd.87Jpy3kyqdX4jMO
 ypVh_raS73xNH1XVPeUJsDJNx0dSrBkdUhoLrOjLJj1Xrur3enXeSjrH4d9fY4gJU6srfm8Prnsf
 JDc3gwjKJuaU5AI3U3o9RdZltP4npZCc7nhwkZvMQORGHb16LLZeJvny5vbvBD4lHjWwFuN9YGQy
 Fwin1Te9eq3qSAodI3PtLCmkAQ67N3vfkgB7cK4PYpbyc9u7kn4R0gS8kFdDBk6_euhQHQ7hdLqJ
 6H9BMMjAbG4tsWYOidXjyXv8.CO6uOPFLdS1elVwjRoP59yhajpuRajfawpKLE7vyevRGsyAdU9J
 wxnSjxfTFa8xE6zKOuvhW.834lqPXXf3rfqy9IXDaaH5_wTLw_Z_2BOVROWZUiJsuIiHVWvb10Z3
 z6s6.mIPjdAF8yLLn07EcNiGOyaXiHbNz.1ERMLfHszqcu75lc.7J6x1thMv2DtV0AZYTZAu.ikY
 eOjMLqSa.HolkWN1qLFSylw50qsS0F9xH2RvK6qFxUEcojXqI7PARYgPkdVcPkXpyQXKpy8HZQOz
 9mL4M7Mh.tp4a9tkNUyg4tRP5uVm4pnTd7oOtuDbdOxoQT2mqbHWeEFnGEjKi0y3VUFSs22ObOz_
 LLauNUcFxmmC9X_qCihchJ1JEX7.2PqcM2mM6SXz4MoxVx80n6Mdqfk7IMlO25Wef2Lb89D1izKl
 cvYm6X23tLOUBSH_7etu1Zyt5vRBvIy_r8HboPSVaGd2hm0sxWqLkofLgGqPCINrc2RFU_Xx9V.M
 6XZNv6oFI5LfjEPjvfJNZrhNvBg1IXd5aE1KEpgh985Mc9TAVEKE9.agp4DWMM0RDb3UL1zmUxP2
 C7etwVUda1k22hjbLVLr.nlX3OhRxi1j_UvGEpgkL5n9hFiVOxkxGK9ueRP.0lTIvK9.TePyIsPw
 GoX3KVFKPmHWJKJX_jZJ17mI97GUK6g1CtMDVG48PRjs5tn8X3w5H9jQEiBE5P6nGLkF4gV27zBJ
 XuseWt3wUXUHzMtL6DHV8EhYTPilzMnyivvo2KOAtkQ1Lf9ughbUeTL7Lwc6WUJLMnqLR6qEpvkK
 idUVPQKl6io1vZfUPOJmzfCRogWpHkIvkdbUz_KeVQBJd0GxoKHdrgvPstR3Nwlcerx5YqNU9nw-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 30 Nov 2022 08:35:37 +0000
Received: by hermes--production-gq1-579bc4bddd-x7lwx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fee9741600c71020a22f52a9bb0dba11;
          Wed, 30 Nov 2022 08:35: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.200.110.1.12\))
Subject: Re: RPi4B "C0T" (Rev 1.5) part and the duplicate/diff/cmp huge file
 test for UEFI/ACPI contexts: fails far worse than past B0T testing did
From: Mark Millard 
In-Reply-To: 
Date: Wed, 30 Nov 2022 00:35:25 -0800
Cc: "mckusick@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <7FA46F01-BD48-4C19-B7D4-E75855A44670@yahoo.com>
 <5D850BDB-92D2-4234-AAB0-6B930542C585@yahoo.com>
 
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.11 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.61)[-0.607];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NMXbJ72PCz4CZw
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

[Summary: With the patching for handling the ACPI DMA
information also in the kernel, booting UEFI/ACPI style
13.1-STABLE works with the USB3 SSD just fine.]

On Nov 29, 2022, at 20:05, Mark Millard  wrote:

> Two things. First:
>=20
> It turns out that I misremembered: Only my normal main [so: 14]
> builds have the patching of sys/dev/acpica/acpi.c at this point.
> Thus I have not yet actually tested anything with the patching
> related to ACPI XHCI DMA handling.
>=20
> There is still a chance that the "cylinder checksum failed"
> messages would be eliminated by such patching. (This may make
> my request for information from mckusick@ related to "cylinder
> checksum failed" messages not so important.)

Now that my builds of 13.1-STABLE actually are based on
source that has the ACPI DMA information handling code
for XHCI added, sure enough the "cylinder checksum failed"
messages are gone when I test with my kernel build. So
those checks are useful cross checks on media I/O for UFS
being appropriate.

The diff of the original and copy of the large file found
no differences.

> (My other builds do have some patching of
> sys/arm/broadcom/bcm2835/bcm2838_pci.c and
> sys/arm/broadcom/bcm2835/bcm2838_xhci.c that my main also has.
> That is appearently what I was misremembering the details of.)
>=20
>=20
> Second:
>=20
> As a cross-check, I again set up the USB3 SSD media based on:
>=20
> FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221123-b51ee7ac252c-253133.img
>=20
> with a (in this case):
>=20
> -rw-r--r--   1 root  wheel  27706924032 Nov 29 22:16:51 2022 =
larger-than-RAM.tar
>=20
> added. I then used it to boot a 16 GiByte MACCHIATObin Double Shot
> that is EDK2 UEFI/ACPI based and tried:
>=20
> # cp -aRx larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
> # diff larger-than-RAM.tar =
larger-than-RAM.tar.copied_via_MACCHITObinDoubleShot
> # fsck_ffs /
> ** /dev/ufs/rootfs (NO WRITE)
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 25613 files, 14286816 used, 42464044 free (996 frags, 5307881 blocks, =
0.0% fragmentation)
>=20
> So: it worked fine.
>=20
> Thus, it does appear that the 2 problems (as shown by
> messages):
>=20
> A) "cylinder checksum failed" messages ("B0T" RPi4B's only?)

Now known to be a ACPI DMA description handling problem
that would need to be fixed to support the "B0T" RPi4B's
XHCI.

> and:
> B) the message sequences like (both "C0T" and "B0T" RPi4B's):

For the "B0T" and "C0T" RPi4B's, no such message sequence
occurred with the ACPI DMA information handling patching
present.

> xhci_interrupt: host system error
> xhci0: Resetting controller
> uhub0: at usbus1, port 1, addr 1 (disconnected)
> ugen1.2:  at usbus1 (disconnected)
> uhub2: at uhub0, port 1, addr 1 (disconnected)
> uhub2: detached
> ugen1.3:  at usbus1 (disconnected)
> umass0: at uhub0, port 3, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 07 0e ee 40 00 08 00 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:   s/n 000000000014 detached
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60578037760, =
length=3D1048576)]error =3D 6
> UFS: forcibly unmounting /dev/ufs/rootfs from /
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60579086336, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60580134912, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60581183488, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60582232064, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60583280640, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60584329216, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60585377792, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60586426368, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60587474944, =
length=3D1048576)]error =3D 6
> g_vfs_done():ufs/rootfs[READ(offset=3D76881494016, length=3D32768)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D1806729216, length=3D12288)]error=
 =3D 6
> g_vfs_done():ufs/rootfs[WRITE(offset=3D60576989184, =
length=3D1048576)]error =3D 6
> larger-than-RAM.tar: Device not configured
> pid 658 (sh), jid 0, uid 0: exited on signal 4
> (da0:umass-sim0:0:0:0): Periph destroyed
> pid 355 (devd), jid 0, uid 0: exited on signal 4
> umass0: detached
> pid 657 (login), jid 0, uid 0: exited on signal 4
> uhub0: detached
> uhub0 on usbus1
> uhub0:  on =
usbus1
> uhub0: 5 ports with 4 removable, self powered
> ugen1.2:  at usbus1
> uhub2 on uhub0
> uhub2:  on =
usbus1
> uhub2: 4 ports with 4 removable, self powered
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.3:  at usbus1
> umass0 on uhub0
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number ***REDACTED***
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
> pid 627 (cron), jid 0, uid 0: exited on signal 4
>=20
> are both tied to issues more specific to aspects that RPi4B's
> have involved but that various other EDK2 UEFI/ACPI's do not
> present to the FreeBSD kernel. (That wording may be
> incomplete for the possibilities but should be suggestive.)
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Dec  2 23:34:24 2022
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 4NP8Rw6gFRz4jg5n
	for ; Fri,  2 Dec 2022 23:34:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4NP8Rv5Y8cz4Yxp
	for ; Fri,  2 Dec 2022 23:34:51 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=SFWvxBMg;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.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=1670024088; bh=ARh77kr9UTEjmy7gNZ+9bgK6u5oQ3snnQcLdpnWbJ24=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SFWvxBMgHpgIl8KEENY2H4fSRXByNJxWYLktPyZLRCAKitPp94OKXmxkuTPABffx56tfs/HoLkyE6jy/DaVnLDyGd8z5jHz3A4ijjAanLWmaDYnBGKwsLc4rK/v6NWbgA9tMJ1zwqrcMB4hnNMlxqgjwPofdszbRbfmmZldv58z0p0vsBkKKtvoxz9q/PYLSOGWO2r3kt1iM9dKxOdwmfgT4MKw6q1A8HlfEITgda+ZxkgfFohOf+H8FAKNHviTFRa+9zQTsKWIm08ijOB93PPQ3O8d7kRldWTY7z1+lsJqUEcdp89w1mC2kdLv6bPYohU+6wRIxzzVEKaKrqny4/A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670024088; bh=z3TFDX0oFmXHc8btBHgNrnxaNdtZozQnt1itqdMfDOp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kXY31ELuUWdcx8oSTAaW++ri5Dq5aYChqUla5mnhRymniptNrz6liNog7aH4W17vBISOR73jbMWjKJ714aOjjWobjjWujhqPcM/WjbRTsJ6J57FLpzwA1Up665MkahTYSHxOEkiuCOhW+HWN/vP8D4uOhWg0R/ovZK3wtUinbYHXbLdZm33Oqv/JwTMRsM8I8TFaZTsZ6/VL67z4NdZ6ZcG/RvF+iUtLYgLbN1GSoiGsPA7zvUzWCORo0MPcob9mUKuUT3WmQvJvHr1Vikx+77M88///7oDHKKFv1wzRtJdgtN5PvmoxVQaX/vgpJU+fKuGPhaXMQhOW3CLTx9f5Iw==
X-YMail-OSG: G_0DpPwVM1nMF8FabBaLpndkbfjc0NjOY.cI7VSh7UoSze2E.e6hxbllDX_4Krl
 KTH2D100HHYQ8N1SNAZCSXw8rxcs1UmoBWYzquV7cwejq3lMd3iwWZkHm19YExv_cv1BUu93fdwr
 B9BPMk9OzCRFxgvhE3v2uDqZW82jCG2i3vvCl4hkePiYHCEg3xwvGfxf0lUByZSp62tHrImxjaFe
 DlVH2x9brt5E7oFHFH6j8ZG313DVZgzlLYG0I3JMK9JLqeV8fv1twBXy0STGtobvIqdGffb1OdrH
 Mggb5JdDCY3NPqG93p1XlntLIgIR.nEpPOGj4OzmAOS4MvaAorUYww5tSXkclArJXKDQyWcRv6wh
 .wIuu5OYeC3KU9pc3KCcz1IJgesuZg4HHp.JNKKB9Vgu9NCpgcTUR1KxtrC2nTM1Rp.Hopox4dOC
 uqgzQTjt0Io3XqB5ZJXWaYZuS8RTv6pTNiDXy3W0Hwqo1BSp1UTJO04OJp.tQq1iUOuLp43iPt1D
 XVkdj.APj_g2DiqSYEamSellYliZr8yIVpPQwO33THrPnF8vHerXUJJUJcpiM0JHp2NJSvkg0IFM
 uvgNis9CqhJUX6.g.4I0hSNdG4BOPeHY.AkO3VAWODq3LQxg35lmYMdZmGiqtkqZTknjRRkvx1ex
 HIoUIDSgBivYYha6BVAF37fr4nfYdSxGwfoUpxQVkYWTc.Xi6JEJlpEImIX4gVRTE0UbT.X5QlMI
 5zky0yAam1MbTJdIi_qSzvxp6yto604Sm.H3VqqNNSdAy6gTC6WmC7pRHjHOwDGRR7EhN6EpjpSN
 AsFEND2JM1PtC2c5j7r2fFkJAcw.xT4XxkS_1wtm3vxrpEq2uZ47P6EZwQTGGu4B1cfG8P9ZLhSH
 Fm9WdF2NEVSyOyb6uv9R5f0UUDt8EZ8V8RumE2FEZhyKERixqMvT5ekFnWssBqGceNiZOyINcqxX
 SQSd6lyExU44Tv9vsnVKDb1EjMQqyU7GvRM8fXQOjkdXide.FPxWCLfYAXJfHetHFIh6FQQ0pPys
 SaJmrXqCU.T2zCAEDBBql6p3LrjtGlzSKZcYv_lSIKTJEJCKB7MwWxWZDZrlasa8WbBdsn69zK.R
 _yTzJ7H_VcZtLzrGUY.bq5xQVE6hTZKeLxQfNioswcDZehSb2l5iTZVhc6.K_li7M1Wbo6bDwl16
 D2lOBwO31zMGmGAGTYGsvM9l5RyEGAtZiQ05JKGsRTuTkEwknhvhnSysR_69QUoncsx39J7u3qmp
 vpi7KSMhHZ6JffLFjS5c7fzGVZ3KU4l0HRkz9tTUiLpxXR0S0Rh_a7uyc5eBCrq28m7KAQmszQf5
 Y47Kzy6JV7sH005FmhaqQ.vnU7kdtu_Cg_ZDvlUqd.ko5oUet9FeD3xLSLxXYbKqyPKYuq6_3w_p
 NMgw.Aw0gh1kvBRQThjdsUf8xCFkK6YiG81c.HG4c74gzorIxMDYGM7VG5qQccKqf1onsi_qZe.9
 Sqn9hjPGPou58cgOy1suHuCkbif.UkxlJ4g7_bEXsAKrYPlhLb7qg0sx2twPw3O_iKX949SD3tQU
 FUUbxo_oqJBALFBdCRttL1nFFaomIBhSU2MCToTMZ8uE7eVaPl3obrxWxME3rl14G8_1PEys9CWi
 D8B25sYQqoiEuTM03HAAZDtAsVjndcLqINZDeJAVoU4Gm5A3CeOmnW2O6nzxPMkQLpKtFXGYVfii
 6ncBcVdxrFmov9.2bdFnbaDJt0NoqU_d1INFh3TgSYeVgKbvRR3SXonm8.H9T_r6t8z5jiv1PsIH
 IS319BQf1oUTcw6oY1AylMHXHXyjmIDthxlN8CZjjTTneU.kaZj3iOwfjdkkVdYBVKpQdqULyzxn
 piW5fC9SRwd6QTTKIUOMrXBb.zweEXKMxvJRxRuvVeDExDaT7L8kx8O7ITQlf4HH3ImEmlP0W4zr
 OnLUPRs.lXo2mZQopSXN70ECaS2FWTelPIYaLmUjZu11vYtjOZsesmgFhmjpQyRkOw_3ReAFR_.I
 16LkeCmqV670Ijwd7aRQKuOxvbnCNWVjNDhQm2P6PGbhlxXL3qCpzwpRJsp4DZ.iKNcHTG58NoPX
 x5nJzOX53aYrRkaT61I2LPgdPq1RZPIl8jAHscfsj0M7CG_4YsmJ67EBVyJ0r0j7xPsayXYkgleE
 .24DsXwFowB2r2HecSZF1DiiczGP15HBcrsXjLKhI0yikU3btm36WrQHgepEM6HY87URFaN3dBmC
 amWgMHj2O2fr2FzueNEHkeMqvFtw7E.54boD9QC.lOFcYFf9S8yXoOzWadQtEiiuZJAgHnabwSMk
 E
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 2 Dec 2022 23:34:48 +0000
Received: by hermes--production-bf1-5458f64d4-2b7vw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a2add2a49fb2038e614f303f4cefd114;
          Fri, 02 Dec 2022 23:34:42 +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.200.110.1.12\))
Subject: Does the RPi* DMA code in the kernel handle the distinctions between
 the 3 kinds of DMA engines?
Message-Id: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119@yahoo.com>
Date: Fri, 2 Dec 2022 15:34:24 -0800
To: freebsd-arm ,
 FreeBSD Hackers 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119.ref@yahoo.com>
X-Spamd-Result: default: False [-1.12 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_SPAM_SHORT(0.37)[0.374];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]
X-Rspamd-Queue-Id: 4NP8Rv5Y8cz4Yxp
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

Does the RPi* DMA code in the kernel handle the distinctions between
the 3 kinds of DMA engines?

The engine types are named:

DMA engine	(30-bit DMA addressing: 1 GiByte, 256-bit burst space)

DMA lite engine (only 128 bit burst space,
		no YLENGTH, TDMODE, S_STRIDE, D_STRIDE registsers,
		only 16 bits for DMA length (?_TXFR_LEN XLENGTH),
		no SRC_IGNORE or DEST_IGNORE modes,
		only about half the bandwidth of type DMA,
		uses ENABLE Regsiter 31:28 "PAGELITE" instead of
                27:24 "PAGE" to control the "1G SDRAM ram page" used)

DMA4 engine	(not the same as dma4 of specific engines dma0..dma15;
		different register map offset pattern after ??_CB,
		more register map offsets than the other DMA types,
		40 address bits with 40:32 in ??_SRCI/??_DESTI 7:0,
		??_CB bits 31:0 are for Control Block Address 36:5,
		higher performance via "uncoupled read/write design",
		write burst capable,
		directly accesses the BCM2711 35-bit address bus
		so bypasses the paginging registers that are used
		for types DMA and DMA lite)

The specific instances of engines (channels) have types:

dma0 ..dma6 : Always type DMA (so far?)
dma7 ..dma10: Always type DMA lite (so far?)
dma11..dma14: Not the same for BCM2711:
		For BCM2711, type DMA4
		Otherwise, type DMA lite (so far?)

BCM2711 specific note:
dma11 "is additionally able to access the PCIe interface".

For reference, the live device tree for the BCM2711 has
(examples from an 8 GiByte RPi4B):

		dma@7e007000 {
			compatible =3D "brcm,bcm2835-dma";
			reg =3D <0x7e007000 0x00000b00>;
			interrupts =3D <0x00000000 0x00000050 0x00000004 =
0x00000000 0x00000051 0x00000004 0x00000000 0x00000052 0x00000004 =
0x00000000 0x00000053 0x00000004 0x00000000 0x00000054 0x00000004 =
0x00000000 0x00000055 0x00000004 0x00000000 0x00000056 0x00000004 =
0x00000000 0x00000057 0x00000004 0x00000000 0x00000057 0x00000004 =
0x00000000 0x00000058 0x00000004 0x00000000 0x00000058 0x00000004>;
			interrupt-names =3D "dma0", "dma1", "dma2", =
"dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10";
			#dma-cells =3D <0x00000001>;
			brcm,dma-channel-mask =3D <0x000007f5>;
			phandle =3D <0x0000000b>;
		};
. . .
		dma@7e007b00 {
			compatible =3D "brcm,bcm2711-dma";
			reg =3D <0x00000000 0x7e007b00 0x00000000 =
0x00000400>;
			interrupts =3D <0x00000000 0x00000059 0x00000004 =
0x00000000 0x0000005a 0x00000004 0x00000000 0x0000005b 0x00000004 =
0x00000000 0x0000005c 0x00000004>;
			interrupt-names =3D "dma11", "dma12", "dma13", =
"dma14";
			#dma-cells =3D <0x00000001>;
			brcm,dma-channel-mask =3D <0x00003000>;
			phandle =3D <0x00000040>;
		};

Note: dma15 "is exclusively used by the VPU" and I ignore it here.

I ask, in part, because of:

#define    BCM_DMA_CH_MAX          12

that is used via the likes of:

struct bcm_dma_ch sc_dma_ch[BCM_DMA_CH_MAX];

and:

for (i =3D 0; i < BCM_DMA_CH_MAX; i++) {

But the BCM2711 only has 0..10 defined for brcm,bcm2835-dma
in its device live device tree, although brcm,dma-channel-mask
allows avoiding what is missing. 11..14 are defined in
brcm,bcm2711-dma instead --but the code makes no use of it,
given the brcm,bcm2835-dma's brcm,dma-channel-mask.

But/also, the brcm,bcm2835-dma's brcm,dma-channel-mask includes
examples of both "DMA engine" and "DMA lite engine", so still
leading to some distinctions that should be made.

So far, I've not been able to identify code/data making any
distinctions for the likes of dma7..dma14 beyond what
brcm,dma-channel-mask completely avoids.


Note:	So far as I can tell, the PCIe bus-mastering that is
	associated with the XHCI in the BCM2711 is separate
	from the above.

	The "B0T" BCM2711 parts have a 3 GiByte limitation just
	for this PCIe bus-mastering(/XHCI) and the "C0T" BCM2711
	parts no longer are limited to a subset of the available
	RAM for PCIe bus-mastering(/XHCI). Examples from 8 GiByte
	RPi4B's:

		dma-ranges =3D <0x02000000 0x00000004 0x00000000 =
0x00000000 0x00000000 0x00000000 0xc0000000>;
	vs.
		dma-ranges =3D <0x02000000 0x00000004 0x00000000 =
0x00000000 0x00000000 0x00000002 0x00000000>;

	So, XHCI related bounce buffering could be avoided on=20
	"C0T" parts.

	For BCM2711 "B0T" vs. "C0T" there is also emmc2bus with:

		dma-ranges =3D <0x00000000 0xc0000000 0x00000000 =
0x00000000 0x40000000>;
		(so: matching the soc dma-ranges, other than the #of =
cells for holding the 1st addr)
	vs.
		dma-ranges =3D <0x00000000 0x00000000 0x00000000 =
0x00000000 0xfc000000>;
		(so not matching the soc dma-ranges)

	emmc2bus contains:

		emmc2@7e340000 {
			compatible =3D "brcm,bcm2711-emmc2";
			. . .

	which looks to mean that the dma_ranges for brcm,bcm2711-emmc2
	changed to not match the soc dma-ranges. I've not noticed any
	code/data that would track this change.

	I do not know the implications of the difference for
	what FreeBSD's code does --or if FreeBSD ever tries to
	use the brcm,bcm2711-emmc2 .

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec  4 21:00:49 2022
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 4NQJxF59rXz4jXsL
	for ; Sun,  4 Dec 2022 21:00:49 +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 4NQJxF2zD8z3vbB
	for ; Sun,  4 Dec 2022 21:00:49 +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=1670187649;
	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=9RgYAniqxHlEZ9C8GVPaEwOVK0v1SGrbRuaVYxvUiyg=;
	b=sD799Fa6WAyVT9jb77QXVoWOJSqbRN83HKOmJJ0rJvHH6penW0miszPr9ytbwQUzvcA/Jm
	diCbwadmUBLE+DQTi+4sB3zEgtVVZwcxj/FGOH9odIpIli4r/tC92TFE+nh1leB1EEqSmc
	BFEPwyMBcQU1HTZqI3JbtkL8WhGBJZlZvkJp9EinyVNxxaulxaR3I9qHbvaDxNKwEuw7qS
	5I6Ogy4xdSuDuRx51y/V7/3nZCP/i5cflTXFDQniGpcsC6l0gInHEWG1n1vujfQ34DwPES
	nmSvKvtFvwMKxG+DzC9AMdttW1HX0J50pmA3gsUgfK126q4b8YP4oDJmDjVqog==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670187649; a=rsa-sha256; cv=none;
	b=UQXO79Q8W76Gr8W/ydNbOAReJvIlbBH6ytHH8QuksRA/d8TNzhZcYGGtosfX8Q9y0MeP0B
	cxofQjdCQ9Q+MzNfoaW4+teCIvSHHALD/DoHvuY3e0f332zmSqMcFmmrjmEPkjJ9cmLYi5
	FdZ/KHPCKXLUt2ma+KkGlaSRHOzJIUHLPIS0byN8JwXQh++IbJxvLQZ7M6peiDJ7fqfXkP
	sFalaRVBwXf002bQKQr7jeAMWT7XG21il9UGj9QKx62UDUfYpLN+RX6fucl4+mqUEXVHSI
	58aMeokES7L5iKZc2OO6BXLrJJf4vtd3TNZ067RcPwBrT4ZmsPEnrS8N1ZLOpg==
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 4NQJxF25KkzXmk
	for ; Sun,  4 Dec 2022 21:00:49 +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 2B4L0ndl020485
	for ; Sun, 4 Dec 2022 21:00:49 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2B4L0nED020484
	for freebsd-arm@FreeBSD.org; Sun, 4 Dec 2022 21:00:49 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202212042100.2B4L0nED020484@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, 4 Dec 2022 21:00:49 +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="16701876492.F1da75cEe.16947"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16701876492.F1da75cEe.16947
Date: Sun, 4 Dec 2022 21:00:49 +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.

--16701876492.F1da75cEe.16947
Date: Sun, 4 Dec 2022 21:00:49 +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.


--16701876492.F1da75cEe.16947--

From nobody Mon Dec  5 17:40:39 2022
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 4NQrS60lxDz4kFZj
	for ; Mon,  5 Dec 2022 17:40:54 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e])
	(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 4NQrS50qBLz4HJG
	for ; Mon,  5 Dec 2022 17:40:53 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=T63uj0Sx;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x102e.google.com with SMTP id o1-20020a17090a678100b00219cf69e5f0so3588382pjj.2
        for ; Mon, 05 Dec 2022 09:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:reply-to:mime-version:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ctL8xjVEry7m6QRlCzny5LYpJAi/oTgk081Ao5BRqfw=;
        b=T63uj0SxAy3678gRQwHE43MezUutRcSH3GxMaLq6AHXna64i/OkaGEH9+DquqC8oNA
         uTNEFYJtD8myrTaxDSCXHeHSCNEEvhVBz2+GoCjtqjPCc29gy+L5KWBfOpWEf4aLWikQ
         qDy9x48AnNvcmIzzByRggrDzfshyiMTW4Ye2Fmp3R+MUZ8b8f17SX+mLVWEt3ec+QIXz
         1HLJvJyFmKOcbw/YpqDBiEqcGOKbb9WlX1/5NR6K99gedaPLKGpPUX8ne5CVUXqKMDJu
         3WSc114YQSpAJxPk+cIulCd3NSdjA0Wh0mFvKlgX6rnPZoBXS+l4cST1TKR2lt2MDlnv
         w82w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:reply-to:mime-version
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=ctL8xjVEry7m6QRlCzny5LYpJAi/oTgk081Ao5BRqfw=;
        b=U6d4AtbYIIWUymY/GLkk8FJ3m55zNZxfuLg0VLvOfQEonvljRkOMvz7MxC1W4TsJZF
         w72e29UTa/OePe/Un1UCE5cfGzW4uEwFTtFx2jNlg41/kQLsGVqeXqFjx3wjrfqPVRK0
         Zc1c3wEa5xTaQynnkroS6lGAbUDU5HfSe+T42c/vPOj65OKnjwz3rOmxQ+cWo68R+20U
         A3pRZAxdFxcuVm/5esIEDhMiJyZEwQ29lwbsAy5nhfUZX5EhoDrtgj7Q7bTX59vzHG3C
         bCH0WNRoIMBJ75No6FOqZUQHdg6dWwNjKXPUJX/TQBBfppnD1ico8CjXlE9+i5EyTgYF
         1AIg==
X-Gm-Message-State: ANoB5pnQ30LagGTWAI3HjUM8HSqzq/gK4EULVDlsts9SO/LaycigXvyz
	Stt8O0i1oatlNo7ObElUdMUU0cJpL6FScrgidM/0/8C2LNM=
X-Google-Smtp-Source: AA0mqf5TXB7obEKpq3uNUp+WJ0wYx0XatO4/rpBACOlzssKWxuIvnF8wCZsgA6xuDB9gh/JGNcfTda4X2eUYdLyVdGM=
X-Received: by 2002:a17:902:f78c:b0:186:8c13:50b3 with SMTP id
 q12-20020a170902f78c00b001868c1350b3mr65544532pln.153.1670262051211; Mon, 05
 Dec 2022 09:40:51 -0800 (PST)
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
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Tue, 6 Dec 2022 02:40:39 +0900
Message-ID: 
Subject: Succeeded to boot on Lenovo Yoga C630
To: freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-3.34 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.964];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_LONG(-0.38)[-0.378];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[freebsd];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NQrS50qBLz4HJG
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I cannot find the original mail in my mailbox, but it is continued
from this mail.
https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-boot-on-lenovo-yoga-c630

FreeBSD's bootaa64.efi that is distributed officially does not boot on
Lenovo Yoga C630.
OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged
OpenBSD's start.S and ldscript.arm64.
boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.

It seems that probing on serial console freezes the loader.
Commenting out serialconsole made the loader_lua.efi to boot the kernel.
And then, the kernel stopped and complained that it cannot find the
device tree blob.

So my questions are:
1. Can I disable loader from probing comconsole by some configuration?
(without tweaking the source.)
2. How should I make the loader or kernel to find the dtb file?

Thank you.

Hiroo Ono

From nobody Mon Dec  5 18:49:40 2022
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 4NQszp4nB4z4jBS0
	for ; Mon,  5 Dec 2022 18:49:58 +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 4NQszm4w53z3CNZ
	for ; Mon,  5 Dec 2022 18:49:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=idsBWUj5;
	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=1670266194; bh=S53UpGtoLWmfXpkG4IINswH09SKzeHMqzig3PKxpI70=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=idsBWUj5TGBRJxef6jVA2JxJN77tCuY8wJsPEtupYToqTeRavtYKNK088CaukclDab6Cg5TNlNXklZs1Suk1MedZCxGhrZOn66+LwW5JegZi8Ou8QFGXjFhdEzBQCNT09kCYa0FW1wdTjNrNxf/Yl4dMfNW4HYkGzwIKTMInonxEy1xF7/CDSBMJ297v2Dj9VY1U35zbXhM/VoYqOs/NeRC+spfI/EeNfYhhSa85fi5sZpgxbVMXmiLs9lZSgwtJ4otww2dW+Uq0xuczoVBbpEf2hcUo+X6UTELOWxJP6fPOEPpVdjFfSPdf3qmvfGpRNP+ywb+wsJEPkFmyf3AgDA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670266194; bh=15i8g08rwOCQX5xCgzMpDy7rvvq2Pi2o6Bz2UhqEoAL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Awx8ywJqUMCi+QqPuyDwSCjgSBzaUu/UbNfSf85/+CE+0T6hhSSkpRuYbdhinteIVUxHpqArEsxzCJRNYB49KWYayuXVQyA+tu+8w3nnbBgSSQbmNKVpPX6we+X1+TgnNss9E0tGfyyZ+oXreIaopk27W1yiWNahytIXPumIlhRBMc/XIwDt3voA34fKGxFy0N7x+jBk4wvS14w+knVUaiQ4wz9b7qYzNofUFd1/9S2HzxVmdK/ANcLwAiGPuIfeAaNfvQYfnF77ja70JbB6I11r9VAzdTHwTs+qsUHrnNgPmxfAylX117S12He/RX8aceDc8b8ZI5jraQJRJPVuZQ==
X-YMail-OSG: PfLkMFgVM1nLjP088.dKi1eE6Zhz5e_c7dFy6oSaYUFx2w4Kq9_Lp8q4421e5WC
 4dVVOzhMgvNa2viTsUjtbJmeKArbXvmORlFmE9D0MovCHlXdVFxVrtR42Tm6aLYZcd0qjihPTI6o
 cjXYgpnyVqjcMN6qqTbd.SR5Fuz0uabNlR96Q6CNo2BobSGwT3im9rsdIEBO6cHn395QYi9l.qTd
 4tdrMcWBEwX7ZSNx5qMjGxq2tf1J9PyWpaWBp7F9HGAA595sXFlJSI_4Gt0eXBl2mwYBPFH9eX4J
 PvF3HCKKoKPNc7k7bt.DPb3ygkdyr0bDsx2ZeUW1sQhlxqfwpltfmG38yyi5h2W4wcmJyjOvFYvt
 wemnKlUyWKJgHI.Xy8sGuRbnObtzeIP3wNCtKL9CciC43fQOUpGx26IOSeGe3PaVhI.EuPy4u21y
 VEVu.t8xAQMIfkBJxahcOKFKC0Rxf679HlihtPpGqVGNoVBMZ5_5x2hRDqyH9AzOa6oGyqrsnj4B
 Wbyvidv7AjyifvsGO7OwXn_sQzseFusvlz4cSj5SNsmKDZmS.4_i6c6GXEFDHw57tcp7lknX77Ez
 XeR2xEY_r2Uhd8UFnbpS9n6SP40DQJryLau0tU5eI134ikTRrNK6QoLJrEE_4_eCGehMDNVEHn87
 SdfrxMppxjT7nkiy_qbpMPcGmnhaVaduL9Q5O_b0xGD7IGvBGQu3UcbdEpF1qDyfrML8khte8G8H
 QT8cRPJUt0SRUZNfRWJK7XEFC5vB0MNAls8Jobz97Zs5TlutT0FO2fU5hjrWPUKx5kvAlhKVfDHP
 ph4r6Ne0iabawUenCayRLY4MBhr8GHeaKIOLXB.Y6fy3Vbnf2n8EDi4ck4IbxyDISFk6miSYIcQa
 8WHkvbF3C2dFJz8KXAMaq5DxK3GSteneKLELWG9ux0Sh8OKWMK7DAvy2uj55btbIrKPcap3mYfnH
 u1FZuAVg_oVx56FhhQVM0nRDuDBbNvM719OW5cZPUIOSF1VFrkUYjOi4pNSrlMghkcDUBdW12ZXW
 POd7kOOwNeTOtcBaSFXccv97Z3ARVCQNfBgjgSSrhhGsVY9oOJqHi.tTWKdIufop9HPx5iFrEoHa
 9djX1zcAndZPRyAw52U.Gzgq0FWmQXKO3.2O4WsOzuRe8QaBtuPr7oYEsHCLoAkkSS_nZ00wr_FW
 EQrdmLJqESbvl7O80OQk8eEwJ44KJzyCiDoH_4PdOktT5Vw0nMlgXaC19lpUNeMUvqXAk6Wp5ba5
 Jn0EGErB0UB57gTLpS.WzG4L9QCUXCSSUTFf67vr6zSL8I5VZUPPJwgi9QE7dbaTgNNTeL4vNRiy
 vffXdO9e41Cd3_eWKFdERp7UgkohwdmsWxdvsuBNLpswvoVcbOjcMkaIk3aAsXGpEvSW1dmwIVMO
 6yIjc1lZwaSC7FvoZtpL3nuMvqdJiItyxD1uAvqcFBZM_YNVCIsSIrkRj6BaVxHsqQ444rBHkvgU
 DekiuQWFfYiHeC_NpzWEDR_erGYTEIaPsh5CK6dZcbcPDuU2oiUCagOmhLgxzCPjfZAnfZKqWR_O
 brqHJIXh62MAzCgFOZz6rH1_yRmqPzM.vcemTabqHtECDeQTJCkfcIKL8lBZXdma6s8owtdX1C8W
 nvHeZA2qc8CrnkilqgSSW1WHiL6VHcWo9EWw3Ydgc3q2hIGqgO3NngzVmPU0fv9XNBid8JeDVL4g
 5grOFSetITILq.RE5sFtKu140x_CDupfx4DD8HA_qz0MhSUZaGb5ZwxCJky.moNtHQ22H5N2zOPV
 NBQ64grdcJeR2mZmpQJK3cq5QoLAYla2GUr2blEB1J9ysV0NQFAQ_EQV9bLUinogb1sTHyPa_BEf
 Wh2txj90S11StuO5h2iMTA8FY5JrnL1jnFo6VJHUSG4FcXGwrCllUTo0ukJ0mRtZ1svm8pD6e.E.
 W22TRuVpp1lkvxZNeHIBBiUxA34TfnQUKU8HL_JmVBXFYvutaeYrUGmPyV2rISpmw2t4B.GB9Ggi
 c4DXLvFoC7tCmIWaoIGdUTaCPETx4U56s3hQaLJoQomC5vlM8xQQDNzInPDQDEIfO36n4K11IkNH
 694qWISu3lmcUhyq12xODcAf8Z4cmO4bbVS_c.I_o9oq3ifNWmNJ56wCOF52.W8dVrhlENq.3Qjy
 Zq8GlPfHXIaZLWQn3Ld2OGA8CfXQPUH8oiX0YlyY5ep0QftH5vPK7VF30ERyYiq2ziu5tfo_Kaez
 Mes5Aci0NS9f2lkOG1PG0xRavZMShU1_W8Vx5qPI_brIdMIq3ZBFjV7ZiKoB_zpWLWCPgkkbZy0n
 y
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Dec 2022 18:49:54 +0000
Received: by hermes--production-ne1-7b69748c4d-mpl4q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b47a18837df8284a9eb3ae47ecb4d5c9;
          Mon, 05 Dec 2022 18:49:52 +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.200.110.1.12\))
Subject: Re: Succeeded to boot on Lenovo Yoga C630
From: Mark Millard 
In-Reply-To: 
Date: Mon, 5 Dec 2022 10:49:40 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: hiroo.ono+freebsd@gmail.com
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.985];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[freebsd];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NQszm4w53z3CNZ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Dec 5, 2022, at 09:40, Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F)=
  wrote:

> I cannot find the original mail in my mailbox, but it is continued
> from this mail.
> =
https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-boot-=
on-lenovo-yoga-c630
>=20
> FreeBSD's bootaa64.efi that is distributed officially does not boot on
> Lenovo Yoga C630.
> OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged
> OpenBSD's start.S and ldscript.arm64.
> boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.
>=20
> It seems that probing on serial console freezes the loader.
> Commenting out serialconsole made the loader_lua.efi to boot the =
kernel.
> And then, the kernel stopped and complained that it cannot find the
> device tree blob.
>=20
> So my questions are:
> 1. Can I disable loader from probing comconsole by some configuration?
> (without tweaking the source.)
> 2. How should I make the loader or kernel to find the dtb file?

The following might be involved in your context.

The following is from a successful boot of a HoneyComb via
UEFI/ACPI (not device tree) via an old log file that I
have around. Note the first two lines.

. . .
No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!
EFI framebuffer information:
addr, size     0x0, 0x0
dimensions     0 x 0
stride         0
masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
---<>---
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2022 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-CURRENT #59 main-n256584-5bc926af9fd1-dirty: Wed Jul  6 =
18:10:52 PDT 2022
. . .
Starting background file system checks in 60 seconds.
Sun Jul 17 14:50:56 PDT=20
FreeBSD/arm64 (CA72_16Gp_ZFS) (ttyu0)

login:=20
. . .

Such also happens for stable/13, releng/13.* based installations
as well --and likely others too.

ACPI booting does not use Device Tree information but the messages
are output anyway about the lack. Only if you know that the context
is a Device Tree style of boot are the messages actually reporting
a problem.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Dec  5 21:11:06 2022
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 4NQx7v4wXmz4jYc6
	for ; Mon,  5 Dec 2022 21:12:11 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4NQx7t6zwdz3qdh
	for ; Mon,  5 Dec 2022 21:12:10 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=SQ6oFnwI;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x62f.google.com with SMTP id gu23so1492625ejb.10
        for ; Mon, 05 Dec 2022 13:12:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=7vlnNZ0N+S4kJuD6cENk53/MZJZTcthWdRALpRir2z4=;
        b=SQ6oFnwIK2TmEasgOFUcMYPyxlQd/1cGAty81I20UoRiWhOqG9olZ1fBod7lxkwsop
         pWoJ4v2s+babl2BwvsFqDtG4Vw0Ix4rQ4kXgLGW7DZYMv20yg5GxChduGg3yH7FbQSSh
         Kg8K/WLVB3YKmMfsLFLyGLW1yOOeDUht2fwDJqUrq4ut3LObo8QHyRngSPk6SX4G6DH8
         SkVQz9XvJLa4fyquTgaiIMt44Mcxhr+JU2LPH37opP7vy4AxWY8LL0R7OPDhqH8r5VQh
         vBm/DRtbt+OKSAasfgZyZAMLmo3wyiVZBAnM5XFNZ3z+ANDM/z/WlKUflH9Xym/FyPi2
         0LWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=7vlnNZ0N+S4kJuD6cENk53/MZJZTcthWdRALpRir2z4=;
        b=Ponn3Y4SEo7y94h73j9GvBbeuckQFAFZoxtEUC6oVJq01GKCw6bj+qedFwXq6LhVCf
         qWtrATbxFYtk/6jk41+dcShsYFjLFXzGChqUEkT0ELjqEra3cHhYN84bRgi/0x45nSNP
         jfUJkHppYvqvRGVqssNYelGrFbLmUXU1ta6Q8hEY/dftujqBXUxwj9vIvkcx5Oc61W7F
         FIQu5ueUzbSZqFQKuJYMmgiSO1/hafxjeZv+i92ZsVUoEz2Xi0rKK9IyBIGlJnGTSE3F
         umQoKp65TLiVyhSUrPf7jKYsnUpY0n4uj3MN3/rLS0Jf5iYT85IO0Xf0DTvgIyOTs/Oy
         gorA==
X-Gm-Message-State: ANoB5plZBQiw89n1PB1AUNBlZhMmKGxHGij1EgJHnfDjO4335s9TTM0s
	KYvKXffOp0Mcgn/OfbdsXJgRKAdurPMzklB5QDRr2g==
X-Google-Smtp-Source: AA0mqf7H0xpfbQ7YMqlorzG1cftc1894J0hsI4HvrwFMa0aUvyfH5/jTkBXYxlqfPV0+z7BHNeo1JmzP35EVuRXMiMA=
X-Received: by 2002:a17:906:29c3:b0:7c0:e0db:f136 with SMTP id
 y3-20020a17090629c300b007c0e0dbf136mr7895951eje.333.1670274728660; Mon, 05
 Dec 2022 13:12:08 -0800 (PST)
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: Mon, 5 Dec 2022 14:11:06 -0700
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000e12dfa05ef1b23a9"
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.998];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NQx7t6zwdz3qdh
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e12dfa05ef1b23a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 5, 2022, 10:40 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=
=9F) 
wrote:

> Hello,
>
> I cannot find the original mail in my mailbox, but it is continued
> from this mail.
>
> https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-boot=
-on-lenovo-yoga-c630
>
> FreeBSD's bootaa64.efi that is distributed officially does not boot on
> Lenovo Yoga C630.
> OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged
> OpenBSD's start.S and ldscript.arm64.
> boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.
>
> It seems that probing on serial console freezes the loader.
> Commenting out serialconsole made the loader_lua.efi to boot the kernel.
> And then, the kernel stopped and complained that it cannot find the
> device tree blob.
>
> So my questions are:
> 1. Can I disable loader from probing comconsole by some configuration?
> (without tweaking the source.)
> 2. How should I make the loader or kernel to find the dtb file?
>

There are some BIOSes that hate our serial code. So far it has just been in
the cloud. But I'd just disable serial to confirm it's the same problem.

Also, the kernel is weird with both DTB and ACPI right now. You have to
pick one and it defaults to dtb... and I have systems that require manually
setting this to ACPI.

Warner

Thank you.
>
> Hiroo Ono
>
>

--000000000000e12dfa05ef1b23a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 5, 2022, 10:40 AM Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
Hello,



I cannot find the original mail in my mailbox, but it is continued

from this mail.

https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-bo=
ot-on-lenovo-yoga-c630



FreeBSD's bootaa64.efi that is distributed officially does not boot on<=
br>
Lenovo Yoga C630.

OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged

OpenBSD's start.S and ldscript.arm64.

boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.



It seems that probing on serial console freezes the loader.

Commenting out serialconsole made the loader_lua.efi to boot the kernel.
And then, the kernel stopped and complained that it cannot find the

device tree blob.



So my questions are:

1. Can I disable loader from probing comconsole by some configuration?

(without tweaking the source.)

2. How should I make the loader or kernel to find the dtb file?

There are so=
me BIOSes that hate our serial code. So far it has just been in the cloud. =
But I'd just disable serial to confirm it's the same problem.
=


Also, the kernel is weird wit=
h both DTB and ACPI right now. You have to pick one and it defaults to dtb.=
.. and I have systems that require manually setting this to ACPI.

Warner=C2=A0


Thank you.



Hiroo Ono






--000000000000e12dfa05ef1b23a9--

From nobody Mon Dec  5 22:09:04 2022
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 4NQyPv415Yz4jjVy
	for ; Mon,  5 Dec 2022 22:09:23 +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 4NQyPv16hBz3wDv
	for ; Mon,  5 Dec 2022 22:09:23 +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=1670278160; bh=iTno9TcNsxm8jYR//5dfP1r9/dTfJeMbYZwjQfr2hgU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TMe4p8UaplsFLlp7NsFhF2+c8ZOvlyS97S+R+hAWRiUM5hN7sEbN+jrO4bk+SDnVNr04HD4QTzDStKy+wyWY+ByFXxzrLzz3VAwjhrSUaiC1gZic7fxilEVaPs9cgpm6HoqI8Hh6ARawzd/tiQMqYO04hyBxo0UHIwi6giBpXFA9ozZrZ0lAOMJ0kCgzO1pPYwdlNL2iPNgybntY9HRCd3VsqKQcv7Bs9/uC9e3mIyk5rsSjB/IVz1CXIfhhvC6p5zoJz4VlKseP4v1qz/hWM/5Z2UkZLXPD59Fg7wNcLlxUL+RUqfElBG8LQMZAu/Icv8Nz8/QansyerkFJZklfzg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670278160; bh=jYkP5+TRB6zKnIhi3iDO6Z2nHi/AHVA3GojO4dlPE8X=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=da2VDpVsJSvg/tmmoSCgINHkgX6J8sDg7meIEPVD92GnxZeFeznsQ/13DhCHlfT5Ez63HNJFTYB2yLMAoOdrDkAkamZ3ohlQ//tud3mRBoV+5vPWrwUDgVVaOL4OGstZfpOSOxD686LJpbYNhFHuo4AWqnifmQGpyokHCuG5XRYYuHtQz7+IPiri9dB4Kp/8OeQKj3stu7eWMQGZorRI2cd/qosAJTlFcYGifjUHTOsAH2MVl/GkyJ/uHgTDGr+kBBcKOYnVsGkiS/ynvIY2RRJFgFDKJ1VHA9U4boVjeZJ1wcmYPPA4I9LDJcHOknjYjY1SgOC3ObJ31HViKNVJfQ==
X-YMail-OSG: E5RFMUcVM1ntIH6aNuRxmCc79tjQY2Pj9G2tiXaUBzNCZyotJjK5cGlsJ0xhuUu
 bk45GIK8j6MSNYLcxGx9DaLmiobYLxXjYMHOyaZ0Ksu8AfkrJPHhvkPbIDRFMhHrMWSgMK2sKeX4
 7EifzEN9o7kvvBRfJ8mncqVZncHt9._E0D5C5GL_onwCZZcmX9C5sUttdDyThe2JhsyoCIxOzx85
 f2UIvBRfoRh2HOFUf1Cyh68TXkk3iU9WviTdwmuzIFUuSY2osHzKzDzrSSiwEbZ4mHTYDcbXBOnq
 PB2nR5wmqg4GX_7JFS4flJ8oTCITBzwu8tYaFEt2P6ryJxr.jaWP8POwDwimNG1RKeQQRBiL8nyw
 PoKSNiiGfi520IkNAGeej4b5A7nzp0E6XcXb4n8xXyryF6CYBUlB6TaaJwrqSii5xG5ldGYjn3R1
 iKmavJKg0xOUVpbWSfkeLjQtcE7xjhSRh0nrMBdkwDFjk7wcOCSs_X72PLAHIUV11lbWR_A1AH6d
 JxdSrw3bsx23135TuNLtoXcwJh6dsf7k9bTQvrQyQrvGvY7e67t_YrWkjeJf0PZ_i3azRRbXNbaA
 I5Uezvqak80Yf57WhClWCS5cheD9h8zxXqwRpTLTI.JJt9vOg0YuD0rjVtQHg4LE7aw8mzYi0K4v
 24N.wy6XXwrsAWRLhuzC6SOgCT6d7vlkzXW6K67oMGU2X.cYbFZtnZ1AsCOoIyVZejGp_C9p6sXi
 gv1wKWUc8wlGKa6.6rLKOG4soJutCtPZp9KYspWun4MasjZQKJulaoS8l3yHNh0zuFQ9I4gOS5Ko
 tF4VuWfYlgQJAKQZJ8EYUCC1tDTbo7EaoxKb_y6rQ10w9IQbyoL7MzaBpdiG5Llpbeyer9pOte9v
 IFRYzL0tECnIAv1NlTyIcezkMyDVaH60FuMaiZfGxjBbGnie93uLqQkyBahlFpod5TxiC_Wy.SMU
 JqVhSU.hItET9IHqeuBMK9s5VZ3u49LpFMM8yO95on.kNeWrQF7XdSBJWDSYV_EWvCz2IVWd9.VR
 .iTwlMxECsF.8eK49UqsSAAN43yxu2gB93xZS0b5rjyFv4EbjAqQIO6PWQ0tBfia2NLLcJNT9zjq
 Lw0pj7gsaR8nd9EllJmXSOePahKx5Gqwv8EYBzildNk0MK2DMMtlBF4pD4DAcGEtBPEecv1arrC0
 bGfWCb4eM28LqY46ddi0iGcvim516UFTZh6bkZZLGd8thg0Bwy0tlnenjBpjLx4PKLvydaho0Bf9
 jui1RICLdRRYv8jUHXheVr1huuOhg0zbBxEkk1MirBTNTgIqDYEagzs3eyya.UQvNETA6rMA8wcd
 HFvvQTeqfijbz7aGlpVdkYs70QRaanhlKm4HttmN_2rg72L9u46emoUJrQLRTQ831iY9quGvidyk
 S9tMeAXiYut_o7PICzMDrRZpfVhfd8p8K.eKNSMxfCZhUmXvizq2PYEixCdXXQDul8Dhra.8JglX
 8Zo9f1J7FAdBYXHyri5phDYS5kADs_1FB9PlBHULIb5pvcELZnRyJ2S5ShPA0sohOEIXkJpzkw6G
 9FWjvaAd_2j1cZC8mLaKzFSobB1KzUL0QX.DrrilSH_KoiM5qoznFcYbRxPouZOWC5wQgkhPSEx.
 S0Jw7btYm1suySn91owCGJ8qJ0bQkdoHXILOxTPe_eSoqiaUisH8MzXupuHXwax2NmroGpzfRkCO
 aKAvMpcf7aq2LrVWGZquVfN34pA0otXQAdXBgjha4lLXJnbfNCgXD.aSXgxl6R4nvJpbAezAAo0O
 MdWSqufHXNhvkDimTMyWcwLWSbC79SIN4bIQtVC.6MTPVijy8hcUeM3pcftrS_yaM0U8BrO3CCNP
 DVrtSsi34hV1PJhiulhfJ.Spnt1zlIjV3gMUVmpml5Po3enAekSkFgHRyxzw9nDWZx4mXdFdjyoe
 vArKmjGx28uHtCsTEXlYjgWH2g0PEiwqOv9lhXYg_hmjgA7C.FWqhpNutRE9D6vcq0WKOsKGypUU
 oQUK_8zYoAsTC2NzMLceEk_PW.gwSWgE5_6UNrym3uLtZW9AFL4uKUmGyLKDxfSIgl5SgvjKK5oQ
 9VUFBcGjZr1WY4PhQpQftZ6_sQ4vL0wDSv5nK7ZACkxTVzeZeFVGseu26kS0ULMG.Te.lteEiXkH
 4e.SNt2HtdvashI13pHyWdHTz0M4cPgq2cc6wg7oa3Hff7jC7BZIxL11UqxFL3CpZF64Jh7qXZgR
 nS2.QeY5dhux9nSGEHoSwVYwtcoLG2ooOM0E2p26wHZ4Mtvm2_Wkm2XlBaDqNKeMgARTTmTerPw-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Dec 2022 22:09:20 +0000
Received: by hermes--production-bf1-5458f64d4-97x65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 974482cd8202c0a5a7aa4b3b109ccfe0;
          Mon, 05 Dec 2022 22:09:17 +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.200.110.1.12\))
Subject: Re: Succeeded to boot on Lenovo Yoga C630
From: Mark Millard 
In-Reply-To: 
Date: Mon, 5 Dec 2022 14:09:04 -0800
Cc: "freebsd-arm@freebsd.org" ,
 Warner Losh 
Content-Transfer-Encoding: quoted-printable
Message-Id: <36C6E8E6-4324-43B6-B0BA-C70C9ED981CE@yahoo.com>
References: 
 
To: hiroo.ono+freebsd@gmail.com
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NQyPv16hBz3wDv
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_RCPT(0.00)[freebsd];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 5, 2022, at 13:11, Warner Losh  wrote:

> On Mon, Dec 5, 2022, 10:40 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=
=9F)  wrote:
>> Hello,
>>=20
>> I cannot find the original mail in my mailbox, but it is continued
>> from this mail.
>> =
https://freebsd-arm.freebsd.narkive.com/dBBAi0yX/loader-efi-does-not-boot-=
on-lenovo-yoga-c630
>>=20
>> FreeBSD's bootaa64.efi that is distributed officially does not boot =
on
>> Lenovo Yoga C630.
>> OpenBSD 7.2's bootaa64.efi booted fine on Yoga C630, so I merged
>> OpenBSD's start.S and ldscript.arm64.
>> boot1.efi booted fine, but loader_lua.efi still needed to be tweaked.
>>=20
>> It seems that probing on serial console freezes the loader.
>> Commenting out serialconsole made the loader_lua.efi to boot the =
kernel.
>> And then, the kernel stopped and complained that it cannot find the
>> device tree blob.
>>=20
>> So my questions are:
>> 1. Can I disable loader from probing comconsole by some =
configuration?
>> (without tweaking the source.)
>> 2. How should I make the loader or kernel to find the dtb file?
>=20
> There are some BIOSes that hate our serial code. So far it has just =
been in the cloud. But I'd just disable serial to confirm it's the same =
problem.
>=20
> Also, the kernel is weird with both DTB and ACPI right now. You have =
to pick one and it defaults to dtb... and I have systems that require =
manually setting this to ACPI.
>=20

I'll note that if one gets to the boot loader prompt, one can
try following loader command to figure out the ACPI vs. FDT
(Device Tree) type of boot, at least in many cases:

OK configuration
. . .
  ACPI 2.0 Table at 0xef830018
  . . .

vs. (output compare/contrast):

OK configuration
. . .
  FDT Table at 0x7ef0000
  . . .

Although, it is possible to have an environment that
provides with the ACPI Table and the FDT Table. In that
case, what is being used requires more information than
just configuration output.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec  6 02:51:36 2022
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 4NR4gp2MhJz4jRsJ
	for ; Tue,  6 Dec 2022 02:51:50 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e])
	(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 4NR4gn4lDkz3D8T
	for ; Tue,  6 Dec 2022 02:51:49 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Ag+CDewP;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b2e as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-yb1-xb2e.google.com with SMTP id o127so16954320yba.5
        for ; Mon, 05 Dec 2022 18:51:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=D2HO9qnQ3ubY+KwxFgbrkcGnGqKlkieAL3lJTK5bOvI=;
        b=Ag+CDewP7R+B1Tj0oMsO+hsQB6AaiGcLphsL6ZeXWz6tcN32iZIlQQJFSnvRrkTetg
         vk2wEKBqOaTxRJ+/aeKN6YnBTvZhUMlak4MgQbcGi0eS2NUMsRD0IDEFWUEB+qz566bg
         pOQIyolR/QG53fOQKAilFcw6rLPx9F/fVWGBykPUWwEwlznjcDI4K/pt1nNEbMYWfVKi
         gG0qiFMoV+GgX02mMIY869eToh+shPLExIgwUgRXfgSxF4GucILwnFdwK2gSZSQCBHZH
         7sDeCEX66XwAkRBXMPU/P7ot3WbXNAJophAE0ELLoPpLPYzvtFhxiOYm7xKaXVPV36Ih
         XVlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=D2HO9qnQ3ubY+KwxFgbrkcGnGqKlkieAL3lJTK5bOvI=;
        b=aJLdDCct8Cz9BlIDiDEJN1Cen2nMWf9YYZ+OyYjDbLa/iTQNmTDN9JV63BEsrXvuis
         I7msE+Pjhsv+WT9IfVFiOM8pmPdeXYlZ+vvX1gfMcPS+pgaB5QssndwnWHzUO9Ncuz91
         cnq0XY2ngmUyDcOfRJH3S2C/7z7TyKKF2pHNlRMqoNqwdm70HkxS3RzI96x2/xntUtOc
         xpU/d/Vv3soZesmxshON0juyrl2hJJVzsdAiDBQnUEZnuTDJPzD6v20jgq+0hRdceisr
         9wBTZS6U02Gn2pLQw/GMt6sVw0Bq8YgPrFZHhkWQSzBcQHyS8+io7JuQ6JpwidpaHJOU
         fqnA==
X-Gm-Message-State: ANoB5pn8c71YFFRrLjuvDu0YYXUWTGmVWSdarjtKTezkvBoImUtBn/iM
	6WIYz+3Qt63lVu35v6X3Od0bigUGTBT9E09oRqGCAtRu
X-Google-Smtp-Source: AA0mqf6CNc6PluKfYCkFvNJy37CboOimoT72DmyCbMf9cz1a1qQYJPkEmNfUnJL6DCQY3IaeM4TUDtiRgv6WF2vCEQA=
X-Received: by 2002:a25:70c4:0:b0:6ee:d8b:747e with SMTP id
 l187-20020a2570c4000000b006ee0d8b747emr60919623ybc.523.1670295107898; Mon, 05
 Dec 2022 18:51:47 -0800 (PST)
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
From: Archimedes Gaviola 
Date: Tue, 6 Dec 2022 10:51:36 +0800
Message-ID: 
Subject: Raspberry Pi 3B loader.efi and bootaa64.efi
To: freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000093935f05ef1fe2a4"
X-Spamd-Result: default: False [-3.69 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.69)[-0.694];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2e:from];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NR4gn4lDkz3D8T
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--00000000000093935f05ef1fe2a4
Content-Type: text/plain; charset="UTF-8"

Hi,

Is there any difference between /boot/loader.efi and
/boot/msdos/EFI/BOOT/bootaa64.efi? I have successfully created an RPi 3B
image from scratch but I just copied the bootaa64.efi from my build machine
to the image and it booted successfully. Lately I found out that when
/boot/loader.efi is copied and renamed as
/boot/msdos/EFI/BOOT/bootaa64.efi, it will boot successfully as well.

Thanks and best regards,
Archimedes
-- 
Archimedes Gaviola

--00000000000093935f05ef1fe2a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Is there any difference be=
tween /boot/loader.efi and /boot/msdos/EFI/BOOT/bootaa64.efi? I have succes=
sfully created an RPi 3B image from scratch but I just copied the bootaa64.=
efi from my build machine to the image and it booted successfully. Lately I=
 found out that when /boot/loader.efi is copied and renamed as /boot/msdos/=
EFI/BOOT/bootaa64.efi, it will boot successfully as well.

Thanks and=C2=A0best regards,
Archimedes
-- 
Archimedes Gaviola


--00000000000093935f05ef1fe2a4--

From nobody Tue Dec  6 02:56:38 2022
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 4NR4nd2kBBz4jSYn
	for ; Tue,  6 Dec 2022 02:56:53 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4NR4nc20FVz3DWD
	for ; Tue,  6 Dec 2022 02:56:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=N4iPjUnV;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::629) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x629.google.com with SMTP id n20so3129157ejh.0
        for ; Mon, 05 Dec 2022 18:56:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=6OVz0unwkPYSsHMoS82NA85HZX5AO6PgXIMaLBftHx8=;
        b=N4iPjUnVYoJza561SbTi8AkFLJJQvSq2FRdx8d1WWxtAiudyqzG11CVQyAFrpc48eu
         OL3ByjWHGdcVmJn1DtOYVDH66a7+JPcALJb0TwuMiddWQUrKoLFeGPhbq1bDKjphOquJ
         M7c2m1HCajI3jdiGJ9abwKioaUPthosojkZxuhtFsITUXPlkr+L7/FSub0Y7hts4iurJ
         a4POEwcbyjfdOq/15WL/ktzy+rg45ytRA+yeBgv6ITezxoEQprJtGMmk5IN2/8mAyHWY
         7ZR4auogk/GqRcL22rFRTce4QqpoA43W8+afvm2FjC7FVVzI3Fs479Qp939DvvikZnGZ
         Od+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=6OVz0unwkPYSsHMoS82NA85HZX5AO6PgXIMaLBftHx8=;
        b=coFMx24yihcOPL+8RfNqSM3qltlTEH2vbpQ487l6BKvRHNcJn//iGmlTcl6nzMfhwy
         7/ZPuQOKmH+G9A+MUNPgzOrlEyYf18UlC5b6WvmOkjoWZEpMCfWJN73cLJV2rBPmOICQ
         yCEghslcFb8GjO0FySpDpmTWxP4yZ229FdEVZxkS51zYbBF5l0FvitPIL1jXKzI/AZ2Z
         kv4i1ZquXzVN9IZl4Y6MQE26MeaXWFnvuC0/Hh7ERnml3eqoisPsmighG4Btg9ckk9xR
         c27nOUKQQ6T4TF3b4D+UKmVhhIDM/6xDPFtwdaTxsDXzw5XL8jvCAfigIjQDsax9LCVF
         NXAA==
X-Gm-Message-State: ANoB5pm/5qb/glPrNVvw17+Rxj5QGY9fV7ADNc1kzQy5Y8Xy1jW5F+M9
	eZRQ8MnEbMOPoXuHwhghfBnJVA+rAuQNfQIPX4g5C71rkdmNZg==
X-Google-Smtp-Source: AA0mqf7OAyGQu8Yj+uDNBke6eyqE+NoRr39GFhkMU1NMMXiFVKO89QNqIiLb1Vb+pDyT2tHhrCIWoLwxbOGD8Q+IGkQ=
X-Received: by 2002:a17:906:29c3:b0:7c0:e0db:f136 with SMTP id
 y3-20020a17090629c300b007c0e0dbf136mr8539305eje.333.1670295410237; Mon, 05
 Dec 2022 18:56:50 -0800 (PST)
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: Mon, 5 Dec 2022 19:56:38 -0700
Message-ID: 
Subject: Re: Raspberry Pi 3B loader.efi and bootaa64.efi
To: Archimedes Gaviola 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000098f80205ef1ff455"
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.995];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[gmail.com];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TAGGED_RCPT(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NR4nc20FVz3DWD
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--00000000000098f80205ef1ff455
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 5, 2022, 7:51 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

> Hi,
>
> Is there any difference between /boot/loader.efi and
> /boot/msdos/EFI/BOOT/bootaa64.efi? I have successfully created an RPi 3B
> image from scratch but I just copied the bootaa64.efi from my build machine
> to the image and it booted successfully. Lately I found out that when
> /boot/loader.efi is copied and renamed as
> /boot/msdos/EFI/BOOT/bootaa64.efi, it will boot successfully as well.
>


Typically they are the same thing.

Warner

> Thanks and best regards,
> Archimedes
> --
> Archimedes Gaviola
>

--00000000000098f80205ef1ff455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 5, 2022, 7:51 PM Archimedes Gaviola <archimedes.gaviola@gmail.com<=
/a>> wrote:
Hi,

Is there any difference between /boot/loader.e=
fi and /boot/msdos/EFI/BOOT/bootaa64.efi? I have successfully created an RP=
i 3B image from scratch but I just copied the bootaa64.efi from my build ma=
chine to the image and it booted successfully. Lately I found out that when=
 /boot/loader.efi is copied and renamed as /boot/msdos/EFI/BOOT/bootaa64.ef=
i, it will boot successfully as well.


Typicall=
y they are the same thing.

Warner=C2=A0
Thanks and=C2=A0best regards,
=

Archimedes
-- 
Archimedes Gaviola




--00000000000098f80205ef1ff455--

From nobody Tue Dec  6 03:35:31 2022
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 4NR5fS04RXz4jYdH
	for ; Tue,  6 Dec 2022 03:35:44 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32])
	(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 4NR5fR4G0bz3GkG
	for ; Tue,  6 Dec 2022 03:35:43 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yb1-xb32.google.com with SMTP id d131so13665357ybh.4
        for ; Mon, 05 Dec 2022 19:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=fxKlpi4AAxlGBCIa0+Lh/zZOQm8ylquzkkdmfEoYb9s=;
        b=kkr7nj+BYR/C0fU1qTSDAom0qMVjGsgMu5nil2SR8nB89BzcZB35B4Nxw045o9ZNY6
         rS65lrKldwhyd4bUG8PMsvYUkfqcwxHBLM2jRsjSkKBhOKEU8WWSEno8/YiRcDDlzidc
         HqMckxT1wY0R1JOIiL600O8KJGh1MWi4xXtb2+8HuYhBbL/TferMzrennnBDRj7hQ2xQ
         IkC8XrXL0v+4rxICPyy1qhoI6aCdJ929CQjRlODh+z7w+YfOSlbh01Ezk6XYutr63liR
         YTQDgBqxqNuvBnC13WialALOMUA1TlHaX/LKPJDymbwShFZvPjJMJNhOIDyDAO0mk+rX
         YKAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=fxKlpi4AAxlGBCIa0+Lh/zZOQm8ylquzkkdmfEoYb9s=;
        b=WDPaJMJY1fU14G5AxHar5l0Z2I6sc4EYJSRPAP7iyDqZx9CWMiwqS4a8kYzkGe2aDZ
         BC5Vv+s94Fui2ye2vs4Hs4SSjSyNN00zcnGOapKhw0/D3dA9e2Wi4V8f0Zzv9wpaOBgB
         T0VoKLP49egqD3/h45AkaNeM8nMnKQfhGTgcKvbL0Y6JOW1b7jIMxMfbsXFyEI281bC+
         09Bip3tY1b1kHjsf1wCYotCejDiUqWVaI/rKV0qS1yvvYDOyxIQSQtjh8M3LhYVMA/lF
         +Wr5ed6v5VVJeSGOR5fGDQPts2oia5PQFzR9Z8IzgyWgrzuIm9WzlFTTr7Hk3jv1di1y
         drcA==
X-Gm-Message-State: ANoB5pkS9Hju4g46UmSrTcZbjNAQZrQip7Ap9HPUND5U/9Ghz2HScX8T
	30kypjU36UD6HaRRGzwkumXcmS0LDXzDpu4E4Yo=
X-Google-Smtp-Source: AA0mqf7U98zksXycYhVZBc6GbWcYE7FwXWiL7N66BwkuHMqp+qcsOO6xMNAy6cTmSDa56Z3ZRX7zC6IxbuQt9QbiTgA=
X-Received: by 2002:a25:24c3:0:b0:6cd:3a43:cd47 with SMTP id
 k186-20020a2524c3000000b006cd3a43cd47mr61316369ybk.428.1670297742619; Mon, 05
 Dec 2022 19:35:42 -0800 (PST)
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: Archimedes Gaviola 
Date: Tue, 6 Dec 2022 11:35:31 +0800
Message-ID: 
Subject: Re: Raspberry Pi 3B loader.efi and bootaa64.efi
To: Warner Losh 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000009e3a7305ef207f78"
X-Rspamd-Queue-Id: 4NR5fR4G0bz3GkG
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009e3a7305ef207f78
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 6, 2022 at 10:56 AM Warner Losh  wrote:

>
>
> On Mon, Dec 5, 2022, 7:51 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>> Hi,
>>
>> Is there any difference between /boot/loader.efi and
>> /boot/msdos/EFI/BOOT/bootaa64.efi? I have successfully created an RPi 3B
>> image from scratch but I just copied the bootaa64.efi from my build machine
>> to the image and it booted successfully. Lately I found out that when
>> /boot/loader.efi is copied and renamed as
>> /boot/msdos/EFI/BOOT/bootaa64.efi, it will boot successfully as well.
>>
>
>
> Typically they are the same thing.
>

Hi Warner,

Thanks for your response and confirmation! At least this time I will use
the loader.efi as my source for bootaa64.efi everytime I build an image.

Thanks and best regards,
Archimedes


> Warner
>
>> Thanks and best regards,
>> Archimedes
>> --
>> Archimedes Gaviola
>>
> --
Archimedes Gaviola

--0000000000009e3a7305ef207f78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Dec 6, 2022 at 10:56 AM Warner Losh <imp@bsdimp.com> wrote:


On Mon, Dec 5, 2022, 7:51 PM Archime=
des Gaviola <archimedes.gaviola@gmail.com> wrote:
Hi,

Is there a=
ny difference between /boot/loader.efi and /boot/msdos/EFI/BOOT/bootaa64.ef=
i? I have successfully created an RPi 3B image from scratch but I just copi=
ed the bootaa64.efi from my build machine to the image and it booted succes=
sfully. Lately I found out that when /boot/loader.efi is copied and renamed=
 as /boot/msdos/EFI/BOOT/bootaa64.efi, it will boot successfully as well.

=

Typically they are the same thing.
<=
/blockquote>

Hi Warner,
<=
div dir=3D"auto">
Thanks for your response and c=
onfirmation! At least this time I will use the loader.efi as my source for =
bootaa64.efi everytime I build an image.

<=
div dir=3D"auto">Thanks and=C2=A0best regards,
Archi=
medes


Warner=C2=A0
Thanks=
 and=C2=A0best regards,
Archimedes
-- 
Archimedes Gaviola




-- 
Archimedes Gaviola


--0000000000009e3a7305ef207f78--

From nobody Tue Dec  6 06:26:13 2022
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 4NR9RY2qFMz4jy6q
	for ; Tue,  6 Dec 2022 06:26:33 +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 4NR9RX0BNlz3qD3
	for ; Tue,  6 Dec 2022 06:26:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=llkHlFnf;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 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=1670307989; bh=S+bNiy0vQmkNexJ6frgfrjSTVl25Hmc1rt3Lbm7Fabs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=llkHlFnfXA9BfrPjrXd7VGCIpSiH+kRo01TV2G8UPyBREy11ckwBbjdDNYaPOAcnwASpG35LViONlcFRCR3Mrh2rLviRd3qr7G6FdOXv+2b/IuZqUB60YTwvisVvcaOTBsSUdKFYhxJp8zS4wt5E8/nfYC/aURVMU49L66l2ya7BXoU+wdl4BIR1trafWhWQsrKuQVFRqWU6IXJEuArUI2sjeUmAKjtUYWraennHrCL15UovXxvwYgbK2fXvfmKPrTw0rNixFwNMTekcsNGwevCk9S6D6ziCmO05fqEuIEVnB72dQ3j8MhOKMbOI87FDcNQdzXGZv8W9KrEAajincw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670307989; bh=HtIYylgI2YUZDTwRfzEVpPjQEAxeviHk5ZZmjU8hz5s=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=i9QL/zv5WtMfnYP85zjXY/vl8AsDAsOOj5Qe+/v8mctUkpvk6twS6+MEhroxquBrzPa9YA2lqtQpQS++gud+E9L+liKqpWWE31UW2NrcZgELp60umJ9sNgtR5F2tzRLg9wVwMxKpyodvdaj0FI98rU9IT8MqdNd2szsW0hJgC8GDW2k8fH0n22ObKsYoMR7QzMcW0bxzDMjsa8tIoi3eDvmI22DmyfdumlDHIqzY148Bx67aW2xnlEU9zT6Bb4m6J87999GUbvkj064NxFG1alN6/o3anvykKI66XMt1vM0Dwvyy1yioE1CTJtgLg8WDygqYaerS1zRMcU+W6ZDYgg==
X-YMail-OSG: bD8RfIkVM1khdByz53A1tYmq47O29k8XPtZBTEsVvyIz0kxAwTh.5QKFLXABrb_
 bGCiQD4eHuNkmzkmPg9McCvn32ZM3vtt_KtAT9pdiGG1IJIPhNXqzwp_PpLacUOwUtWq4zBZwttS
 XxPLqogXPEcAZEOvv2APt928PU9ItmcBlfw_inRwsFkj5yS6xt7G.Z_oKLDH5Fgl4iHpQ4e_.imV
 0TU0dn4XP1kCdsC9aTmcZjxgU0xg99n0BnGftVn2z5HK5nuEMvq5TvDQvpepuo8xVuG28CyB2ZCI
 fKfhFdhOQx_fGo8o4ZbdtDhZSBKYU_ld9JGCLYI58N9v6.roauU9HAzSQPidoazEk.XzkRRh56mu
 gjCPKkS8w9yL1NQDkxP.c2m28afpz6P9QElpm6rF.hMh_OGHqveld9hdw8PL5utovk1PkFRGK9Td
 aV5g2ONmg4ISCQHxbtim3LVfe7YWDADeqvUzPzXRc0puDU7T37yto8LrQPW1PGlq9CiQErLhRCjC
 a1o5ti_wSYXWoJ1PWNXK2Jd6Z9O7pGHG3B1Mjuzpzr8quCuiWV9ujJs_Lv3IHaRrHYAa6ju3rlAN
 VKkEfXXgQBwBBEV_oMNklgpSGKtNFQyEIFMlK6mw.gs3rQHretGb5Jt.CPgtsf5TDIHN61MDYCVx
 uwr2TpbR_zO9JuwgV0_Ekv67DQgQU5aF7BTmCb4lf68q6xO7EmwYvi4_yNlprJzvsxM8RoNsxOA2
 ekXFaoKlDYfuMkRcsdAQyoVmMWDAOGHDir8s6UeRJMUkMfYN.Icvhzcu2uMP54poPDAWa2j75g7s
 xkHAKFE4.AAcuTwjcH0iwHwyRknL_aaWVAEUQ8A4nap1riEbVsMKuLTlfqb.LeNqXM4Vj.oxUqXK
 8bNDJCypWVt91O4brPnT4HyOfF3SypQwLrMnslKUk4ybNjljDoylJ7aOb4idJl1UQuKhSpz1t5dI
 5gjcdpeVyDj0dg6g76aXttKCiudE.AAS2JkmyYgmleRP7_1ReQZud.SU0qfmz3y601m1bFwecy46
 hxtFNOZz3rrULIW0tSqtjeVfWgU8NmRLrBHSNaR6e4INlE6RrXQbXk1KyO6f_LnvCBlUvSLbu2qv
 w71whSmXM7mKf_n4ODFxh0yqSoXSjB5w.dS0d9jvK.fmLaNTa7mJWS1xSzMLm2zkGOy66XSceUhA
 S2h.Arwdv9bFrHbgbDLiqTnFICQi4wlHlsufDPQFFZ5KZnzmYvWiHWMKntHYuZx8pgkKtjaWmZGn
 XqC20YIxIl0m26_kSiaRopCxLHXIcwC1OwDPQcFnt_CoET52uteqic6yDDJp6CBuPth3roJzmeiv
 F7X4kx29DfItj8CvQMJeyd8Er2PKhCydqDC6cNAkKzRmwddyRFCeWxIi9ptcT6RjOKWRaOibGgdh
 vzF9Q5p7KNCK5XP5blRMxY5KZ0S7y1EVuRCZtZHH63fHhUbepeHh87Fgimesw7ogOHmDSTAl_Oif
 rLIzxOLjqKVDgOLSU4.r1LvQuG16CU9g91nGva6RoLNJdG5T0Ur2kNLyUB1KhIrzPIgMl01Z1lem
 8z9Om.QcPiSM2UVNcxSpe9dBHZ7yHlp94Bet_eBwY5IZ5q9tAbmrJ39d9J0Hmf_PRU4fN471KXpC
 6_EsQDEwPkmv70MOm1TYkrOpzfnj6rAO0w0HuIeYg4pcdHZgxqyo2rjk7Ndv6f3JG5HydAJzqkMo
 _OttSqeoGJS0zWFqMfabljLzEtL.D7PRrNQRmpDpqFAXASutZVOWbPurYpxJcWVx.8tA0_EbpVgr
 DO1qGYh17O.ObT6dWr40.3MjHGhmogXNj7O4ipcUYGHy1foOiCrtbfd7PX7G2.6zBh1mU_bC_0e2
 ub7sCR3fhk52NCRZTNsZJhPf7knwaAXa5rvEu8tgwIrBLvnMtUTMIR0Vwuev2jp4OBGQeYz3dHW8
 trJ5RuSDTk3LsmIuFaSHsJCp1yEO0iggFgAuyFgFxUnm71PZ4QTbjypDqfQt09pTWr7njOfiKYRB
 x.hKVB_WfoX69Bqgx9h_D6dvxmiayzgOZRvt8J4X0vKgR6O6IcdTh9fr69p6dKh6vyfJ7Fdcu_P1
 V8zuPObEfOuBI2vxc1zQopCT_uDkukTXFTaKnrSJxkTcrwr93njf7y4t7fUoNNXFKQp39QYzS4_u
 jHzmM_HW0_aJ1EzogP1hggkUY6F8ZyU8kGHNNy8ZNHiXrxx_Kovgl03qx4V8rP10fQP4Uyj8jJ5a
 T4Z4Xi6mvE7ubm0c6Bztzh0Zq1g3uUaUxYK90yhpa3jEsfYiPKo31_q4AqOo3
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Dec 2022 06:26:29 +0000
Received: by hermes--production-bf1-5458f64d4-2b7vw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c90b6610944517685913038ce3bd59fc;
          Tue, 06 Dec 2022 06:26:25 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: "man acpi" vs. arm64: still claims ACPI is not supported
Message-Id: 
Date: Mon, 5 Dec 2022 22:26:13 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Spamd-Result: default: False [-3.44 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.94)[-0.940];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NR9RX0BNlz3qD3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

man acpi reports:

COMPATIBILITY
     ACPI is only found and supported on i386/ia32 and amd64.

No mention of arm64/aarch64 .

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec  6 14:59:30 2022
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 4NRNqh0S3Pz4jsN4
	for ; Tue,  6 Dec 2022 14:59:44 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d])
	(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 4NRNqg45qzz3sMQ
	for ; Tue,  6 Dec 2022 14:59:43 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pl1-x62d.google.com with SMTP id y17so14172250plp.3
        for ; Tue, 06 Dec 2022 06:59:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=cEgvRyONh53zQkqp7T6dBEs+vAXtrdxckdERlUNMYxU=;
        b=SvZss7mIeWNao7yleXUhi0uf7Jji1OzMiClFlllPQcpKNu6dRPVN+lyc8N8qmrJSsb
         zJpIUJYtqZTuzh19zwAGkuzBWIaks5DQiyUPrBNJDjpYwo5wfWVzV2IGZGzz9mgo81l9
         H43WVGzLTx6aa7GOrRteIlYlb2uobrKtOYMdcZQDKnkt60SXs7HQQ+2Q9oEk4RRUCR2a
         CZpl28cnObhxp2nvgQ+TW3pkmktjoqOI9RhPQgxe/CLh6NYhmeAA2D0FbbSGnLl3fQLj
         ErI9WxApNxngWemMXRhscuEmD4gR2U+pcDUXffnfPuARgClBTR3W6V8HSz6IYMA074ss
         3N1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=cEgvRyONh53zQkqp7T6dBEs+vAXtrdxckdERlUNMYxU=;
        b=scaoqNC5b+2Qyi6wE86Lj4KpFsSTcB1il54n9LvsObzJNEzVjyBa86SNSW9ux7aV6h
         u3bPFklDTzTGATeNqrns9hgR9r8gJGGKpPnAi+kO6y+enCvs0c+LjSkT+Xb8NqeNf8Fx
         ADsOgGxVXINDocr14f2dnwbOJI2+FrogjZen0QMwSYlbjfaMF5mu6iSWGyR7gWZUbiLB
         WUILXlHl2Z8dBwcZn0WUKG2PdOzXbYt5sR5tK29sEQk+2Sx369eu9Uc2Zx42TE11qoO1
         gq2/+YdDv9RtkSAJHdp73FUudCfQKwb6Ed7sSw1Lo3PXxHshHbf6R+46YrlenvUkOAqH
         0Aqw==
X-Gm-Message-State: ANoB5pmipxzu1hJUNNcE0JKVlWYeAM7XAxjePKlFz7RWNHGV4d0HXt7N
	dsEaniDz7s63f2FdV2m9ReKFGM/sND50BMws7ykGAiOy
X-Google-Smtp-Source: AA0mqf7bLaFvL8a1bW/g3rng4IY79xCv5hArogGCrcppkMVVek8OztiI58kejH/3/r+3Lc6PQmnK15g/hwz/VqRoLNo=
X-Received: by 2002:a17:902:7049:b0:189:e07f:933d with SMTP id
 h9-20020a170902704900b00189e07f933dmr7208093plt.7.1670338782299; Tue, 06 Dec
 2022 06:59:42 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Tue, 6 Dec 2022 23:59:30 +0900
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: Mark Millard 
Cc: freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4NRNqg45qzz3sMQ
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[freebsd]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Thank you.

2022=E5=B9=B412=E6=9C=886=E6=97=A5(=E7=81=AB) 3:49 Mark Millard :

> The following might be involved in your context.
>
> The following is from a successful boot of a HoneyComb via
> UEFI/ACPI (not device tree) via an old log file that I
> have around. Note the first two lines.
>
> . . .
> No valid device tree blob found!
> WARNING! Trying to fire up the kernel, but no device tree blob found!
> EFI framebuffer information:
> addr, size     0x0, 0x0
> dimensions     0 x 0
> stride         0
> masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
> ---<>---
> GDB: no debug ports present
> KDB: debugger backends: ddb

OK, I (and the subject) was wrong. The loader boots, and show
following log at last:

Loading kernel...
/boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea]
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!
EFI framebuffer information
addr, size        0x80400000, 0x7e9000
dimensions     1920 x 1080
stride             1920
masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

and it stops here. No "<>" line is displayed.
So, it seems that the kernel is loaded but could not be started.

> . . .
>
> Such also happens for stable/13, releng/13.* based installations
> as well --and likely others too.
>
> ACPI booting does not use Device Tree information but the messages
> are output anyway about the lack. Only if you know that the context
> is a Device Tree style of boot are the messages actually reporting
> a problem.
>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>

From nobody Tue Dec  6 16:17:52 2022
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 4NRQZ53tkZz4k2lw
	for ; Tue,  6 Dec 2022 16:18:05 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b])
	(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 4NRQZ46GQRz454Y
	for ; Tue,  6 Dec 2022 16:18:04 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=7QgGeucx;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62b) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x62b.google.com with SMTP id qk9so7461927ejc.3
        for ; Tue, 06 Dec 2022 08:18:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Tqf2Hopp2k3nm74Mwo/yswfeBYdvzBHGWMp/QqxAU5A=;
        b=7QgGeucxILP84gc7+e2vaN+ntCmVtWG5nB/3V+oodj6K4dK7PXC6pglUHu2dzYVF46
         zXMIZHInEPiBbHVfW4ZLvpRzHllLtR6jM1AfRjJB4D5ykaUohmbCBHKBoCJQ7+hw/JT1
         08rXNwhXKX27i91zFJNEH0aKH5+fHfdq6kE2C2SlndKrrJWoZN7lWbLiodO2o7heWr08
         O+Z1pZQC5VDt9Kz1OJt+fVS03rIOzkdO+TRZXZkFudHoR/crbYFORAWshugLbVhTWmVQ
         oRyGZEr0RpzMf+snlm7Fr/OLDM1CRRCQrHYByvhADvN8AiDoSCke9EsfHW1GrTjfsE4k
         AKcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=Tqf2Hopp2k3nm74Mwo/yswfeBYdvzBHGWMp/QqxAU5A=;
        b=mBqGwNoauhN5euKDp8XSSXZA7JKmOf9zbxY07f1QJXiNyl28JH2EoA+BJ8RY3KigSk
         w/x8wCYaSw3te6jCT6/nw52uzBysJzIBpr6SQUc64fq5gip0avIlptrB2jptTldzflk4
         CdrydqyRY9EEigqHWJQ4T/BZIOJL2Df4NCjo7E/RCikbH44UMFvZlmdtf3wVJfH+Hky+
         KBvkHU0F0x6O8iwdl6pvYD/wfk36Z40sJlJ72Q8R6mIOU82ZDFnfR55AypdmTl1qy84M
         difuIAHGQ5tSbCcppn2zO0KmZdr1MCqNNndysp16/OfXcgFUm6sRDq/DtNFToFqZYEYo
         wJEA==
X-Gm-Message-State: ANoB5pmROWYpAmL5y8KRO7EibDyHRqYx+fT86UtjdLg27TQn+wX2vHkb
	XCrYzhRTi8kthULGD76PHc4i4p1Djk2ccENedpFpFA==
X-Google-Smtp-Source: AA0mqf5vTJjoDCKz2jfX0zfAFubrBXdYRdeaTNt0dnx7tHq+HTO75cC9nl+7aEJ+UAH/oh/MoqQcpBv+hTwr1N5ULUE=
X-Received: by 2002:a17:907:98ed:b0:7c0:e7a6:cd2d with SMTP id
 ke13-20020a17090798ed00b007c0e7a6cd2dmr9328391ejc.317.1670343483394; Tue, 06
 Dec 2022 08:18:03 -0800 (PST)
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, 6 Dec 2022 09:17:52 -0700
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000fb226005ef2b25ef"
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];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NRQZ46GQRz454Y
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000fb226005ef2b25ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=
=9F) 
wrote:

> Thank you.
>
> 2022=E5=B9=B412=E6=9C=886=E6=97=A5(=E7=81=AB) 3:49 Mark Millard :
>
> > The following might be involved in your context.
> >
> > The following is from a successful boot of a HoneyComb via
> > UEFI/ACPI (not device tree) via an old log file that I
> > have around. Note the first two lines.
> >
> > . . .
> > No valid device tree blob found!
> > WARNING! Trying to fire up the kernel, but no device tree blob found!
> > EFI framebuffer information:
> > addr, size     0x0, 0x0
> > dimensions     0 x 0
> > stride         0
> > masks          0x00000000, 0x00000000, 0x00000000, 0x00000000
> > ---<>---
> > GDB: no debug ports present
> > KDB: debugger backends: ddb
>
> OK, I (and the subject) was wrong. The loader boots, and show
> following log at last:
>
> Loading kernel...
> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea]
> Loading configured modules...
> can't find '/boot/entropy'
> can't find '/etc/hostid'
> No valid device tree blob found!
> WARNING! Trying to fire up the kernel, but no device tree blob found!
> EFI framebuffer information
> addr, size        0x80400000, 0x7e9000
> dimensions     1920 x 1080
> stride             1920
> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>
> and it stops here. No "<>" line is displayed.
> So, it seems that the kernel is loaded but could not be started.


There are several causes of this.

Most likely is that the console is setup to go somewhere else. Though if
you are on the video display and getting that framebuffer output, it won't
not go there w/o some setting to override (say to force serial).

Next most likely is that FreeBSD doesn't cope well with having both FDT and
ACPI information available. But since not DTB is being passed in (per that
message) that's not likely at play here.

Finally, the loader passes a large number of tables, etc to the kernel.
It's quite possible that, for reasons still unknown, that data is wrong or
if standard conforming not expected by the kernel. this leads to a crash
before we've setup the console in the kernel which looks a lot like a hang.

Warner



> > . . .
> >
> > Such also happens for stable/13, releng/13.* based installations
> > as well --and likely others too.
> >
> > ACPI booting does not use Device Tree information but the messages
> > are output anyway about the lack. Only if you know that the context
> > is a Device Tree style of boot are the messages actually reporting
> > a problem.
> >
> >
> > =3D=3D=3D
> > Mark Millard
> > marklmi at yahoo.com
> >
>
>

--000000000000fb226005ef2b25ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Dec 6, 2022 at 7:59 AM Hiroo =
Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
Thank you.



2022=E5=B9=B412=E6=9C=886=E6=97=A5(=E7=81=AB) 3:49 Mark Millard <marklmi@yahoo.com>:<=
br>


> The following might be involved in your context.

>

> The following is from a successful boot of a HoneyComb via

> UEFI/ACPI (not device tree) via an old log file that I

> have around. Note the first two lines.

>

> . . .

> No valid device tree blob found!

> WARNING! Trying to fire up the kernel, but no device tree blob found!<=
br>
> EFI framebuffer information:

> addr, size=C2=A0 =C2=A0 =C2=A00x0, 0x0

> dimensions=C2=A0 =C2=A0 =C2=A00 x 0

> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00

> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00000000, 0x00000000, 0x0000=
0000, 0x00000000

> ---<<BOOT>>---

> GDB: no debug ports present

> KDB: debugger backends: ddb



OK, I (and the subject) was wrong. The loader boots, and show

following log at last:



Loading kernel...

/boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac

data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea]

Loading configured modules...

can't find '/boot/entropy'

can't find '/etc/hostid'

No valid device tree blob found!

WARNING! Trying to fire up the kernel, but no device tree blob found!

EFI framebuffer information

addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80400000, 0x7e9000

dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080

stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01920

masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00ff0000, 0x0000ff00, 0x00=
0000ff, 0xff000000



and it stops here. No "<<BOOT>>" line is displayed.
So, it seems that the kernel is loaded but could not be started.

There are several causes of this.

Most likely is that the console is setup to go somewhere else. Though=
 if you are on the video display and getting that framebuffer output, it wo=
n't not go there w/o some setting to override (say to force serial).

Next most likely is that FreeBSD doesn't cope we=
ll with having both FDT and ACPI information available. But since not DTB i=
s being passed in (per that message) that's not likely at play here.

Finally, the loader passes a large number of tables,=
 etc to the kernel. It's quite possible that, for reasons still unknown=
, that data is wrong or if standard conforming not expected by the kernel. =
this leads to a crash before we've setup the console in the kernel whic=
h looks a lot like a hang.

Warner

=C2=A0
>=
 . . .

>

> Such also happens for stable/13, releng/13.* based installations

> as well --and likely others too.

>

> ACPI booting does not use Device Tree information but the messages

> are output anyway about the lack. Only if you know that the context
> is a Device Tree style of boot are the messages actually reporting

> a problem.

>

>

> =3D=3D=3D

> Mark Millard

> marklmi at yahoo.com

>






--000000000000fb226005ef2b25ef--

From nobody Tue Dec  6 16:56:14 2022
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 4NRRQC4B4Xz4jNYm
	for ; Tue,  6 Dec 2022 16:56:19 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Received: from mx.sdf.org (mx.sdf.org [205.166.94.24])
	(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.sdf.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NRRQB1HHcz4CX3
	for ; Tue,  6 Dec 2022 16:56:18 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of adr@SDF.ORG designates 205.166.94.24 as permitted sender) smtp.mailfrom=adr@SDF.ORG;
	dmarc=pass (policy=none) header.from=sdf.org
Received: from sdf.org (IDENT:adr@sdf.org [205.166.94.16])
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2B6GuG4e029420
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO)
	for ; Tue, 6 Dec 2022 16:56:16 GMT
Received: from localhost (adr@localhost)
	by sdf.org (8.15.2/8.12.8/Submit) with ESMTP id 2B6GuFol019146
	for ; Tue, 6 Dec 2022 16:56:15 GMT
Date: Tue, 6 Dec 2022 16:56:14 +0000 (UTC)
From: adr 
To: freebsd-arm@freebsd.org
Subject: FreeBSD on RPI4 B 8G rev 1.4
Message-ID: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
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 [-3.79 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	DMARC_POLICY_ALLOW(-0.50)[sdf.org,none];
	R_SPF_ALLOW(-0.20)[+ip4:205.166.94.0/24:c];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NRRQB1HHcz4CX3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I'm giving a try again to freebsd in arm (I'd problems before)
looking principally for system stability and a reasonable state of
the ports tree, something I can't find anymore in other BSDs, at
least with arm.

I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can
run this board no matter of using 13 release, stable or current
is with the EDK2 uefi firmware, in acpi mode only, and only with
the ram limit. I didn't expect this limitation after reading the
wiki. The xhci dma bug has been corrected in netbsd and openbsd.
Could someone share the state of this issue in freebsd? Also with
acpi the ethernet interface is not detected, I'm using RTL8152/3
usb cards.

I'm impressed with the performance (without overclocking the cpu),
really impressed. And the usb subsystem looks more stable. I had
problems in the past (and in the present with other bsds), like the
system crashing when attaching or detaching some devices.

Apart from the loss of ram and the inconvenience of not be able to
use the ethernet interface, I'm feeling very comfortable right
know.

Regards,
adr.

From nobody Tue Dec  6 18:40:36 2022
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 4NRTks508Vz4jcc2
	for ; Tue,  6 Dec 2022 18:40:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4NRTks2Q5Gz4P7C
	for ; Tue,  6 Dec 2022 18:40: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=1670352052; bh=lZ9RsHcP+KEHPjubku9HrTl2QAM18BkdNLdX5A8sRvo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ei7WGqyir4Mm3mPEL3WKkfRM4tf5fZWxDH7VoFMiIg9yDvobhQMca4sRBN7S4cq+7sFquY8E7aRXb7vFh5uSGjlWq4LTezvN8uEV/QHrc3TmYb1ktpVoX4a3nJw1EL6PeQvI6Ag2r88zOdeoyjJJtauMKYwYbNBMgMSeYI8sHGGQmYXj00Y9PUJZJdxUlEwWXg6ZyxZUpq4NhqzhIDQ2r8FVnAQ5mdLh05lD7wl7ZGgScascjO1dfuyoy7b3r2XTtnAgxRP3uKPqkhoKkDd5XtXjpuOSij85ELdx9y03Ie6itfjye29+NAthAA5vWgNR7F+67XaeVP/6UXl3sRdgRA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670352052; bh=1kldmtaXbDyNSMY2mlWjkSej97MQtbO2Vpu7VbDzTWV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PfgthbRVatwDhUDavFn2w08Rcz9vsPU3GF7/4IjXadY6gf0eccNSyG9vmf5XdblV7WIOC6n0nXl6NCnqvnV9n46yuVNBA84zLVklupuuiBdM9+Z6maUNR/XIGtUd7voXYG7Wb7q181UY+qTYuGLTbrQ96mLwdJ1nYsvJfW648D6yBpK3CHpPVxItV58bkdoo5pob0NchNVto0FQlkVyUdZsKmozsiHVxzixMhgFqwOMHNayPbJdVE0pZmiUXH7bNfUqG/P0h7Qjk3FfXrq8+hH/+y/7WWSa61m+iz1VrLsA3ivWVtT5gH8TpRMWVAyQnrMlehzNnFd1Zz5c4KK/19w==
X-YMail-OSG: 4QQ8hpoVM1k579gGtcbrqcZHLyZYa26XiaSbObkTMXjPOcozjNNbbw0jYQeuz7J
 UCMeSrdWgfEXATbP.yRdqJilueteRRN26f6U5WDHN.4dw9ifIhmu4gpsmK.0GK7moznU4KDOf8YF
 1sfrK1iuQDPnc2PteTP0wXL0yFMD0avHG5fCOTpmkk5pfE7hgevRt74pt5pPg2wKbA.JnhWzJ4UO
 FApL98eBXjzDyamPDnwqHSJrfyOcV00cEWTkpAcXNMSrz6Q8G7qRz_Buffs3I49UBEuhMOVCMt7E
 1eNY.MRXUE6naxB.B3D_vdxQJrR9eVfvMQWSUF21p0eLax9Q_Nlz.M5.qT32m.E1lkGpzXC8x.km
 Zs5G9i22CDavOZCIsvfRUMIGV0cK8Itz15k0Z27ew2eMj6LcX6N87wzlRkxki.Kx4NuUNE5d9ErR
 AVLfpesZkH_hzoVO.qsCCA7V5KBVTr7rB1wy0GeJv.bP9PNqpMwEpLPplpgnH.U1bVp77kir8JvC
 Be2TLFVOFMGSAak.vrSBGYnThTpZKjaFqO3JRdopAX1YtEW0tvUCwlh2HlY64_y70oGlNQB9CLK.
 yv0bxlyKQ3f1U8ouotihDms4PYgzR32gIt3Y4Qit8IXQbcILDgP0Jgathdmj9z3Ty_JoIl5Nprd.
 s3hhhXLpebr5tO8JeR0nK16xNWwJIUeVa5Yav.opWUwuExA76sHueMOiAeOH.K409yPyY4VjghVN
 jlt1f2OwM_xW4Wj5xiDDa.mmg9QvlJFICCM7tQGJQ1_CDOtnKjSMcm8hQgpT0cFnCUmFdGQ6Zd.u
 ODQkuhBtIjcHvWXt1yK60laJZQToj7P0h1u_y0F2k.QPKf82U2AZkFteI6AlWvD76qGarsBo5haE
 BqTm9GpaZibY0sxVsWwuRUe._.hcQYTzc3Kk_oYtHKog0nHARqRPlucnJdfaMm9KflAWie..e4wq
 odDD7I4iVuOtW2zikuK_IVjG9WQRPsJh0mJlwMvzxgP1m6UwAB43ds5Z4VuEuGDfaFVI79tFZBR9
 7Lghaw.xt5UV6_9QYK32JbbvpSco.heYG3pxYOdrIk3xhlFGC91e2SHNTwPhtY6ENc04No.Oaf1X
 yDxiCwvyPFDwgJWwpPpM7ujbb7806VbSXtxmdYIoK6Ph9uGCGCz3Ad9l.hvyQkqxGmtpqfoShga0
 k4Hsif04ZhB.JJyyd3sA6J4mClfK6QUtJmz3MCcP1NO.DntCQYJc35zQd_vpY0TaEMlnHOKmOatT
 bgdfMaxBIoeMJxMXmZZ5mL7sOFcb8cQK4xxMM3kTxeaBokzavs_7.LgU_5u1ZtOu5BKizTeRSRtu
 c26UGEnw9iPUrZuJah4oCtxAt3ll3AoRMIVzw6ke_eM0WLjyvx_m8Z2X8UGkSYPP_7u3qTrmJQSN
 ZQpDlAWpKRFBrf7VdlmZBhLc2ILUSzhM5I3KgbCpgXj7dEX56Jhi6ubo_F9zEc1ctpNWrn1_Ooal
 5kh_Oau6gnoST3i6onQcVTag.KRmf.5kv7q_6Gia4IDnO9Ueir4KsP6MBHOJNRr7RPfX9r9vYpXl
 mYROWOEO8wGOYLoeXgsG10mzFf_8AT5C5a9J8c9aNMl48LEwvLse9gT1uNx2TxJEwUAfbm0r4e3b
 kukKLT36hhrYti_dhP.s5xFLRHd9jntD0TDddLJNOui.wDelbxbwX0ojy3.oImZVnOcw3sZLU1tD
 HLDGiRqEpHJo6xQ7o_hE5YCVs8EOCC1skz8VtnjJTj3MyYftBbJnB0TckpQBzrBx08s3EpiCNqm0
 _U5LN4X_dvYv4DuFYFy86xP.unqpZjcH6nq0LDYNi0srwbf2wOR3wTKsWrXv6.8TB6JsvXdtz4Wv
 RWjrdbCWU4wHX6vZyw12z3EW_jRC_cU255jpq3K4nXNW7mcxMn_fMep0b6TWkypMWma3L0TTA0W2
 Yn.Tr94oi4yNr9dmAzOJo3Nx8WpoDEYEJa_Ms1UWk5tvBHasZeSnRm1Zo_kEt_EhKMCMUTsoq_0v
 IIlbaMLtpaG9tkChfHeKz0.4vJ3LxSVJytT3UME05a4lLmFcmv_uSE6bL8YeG3x70RF9akeFIHT2
 OLCf0NsNqt94gDVCrMXjx6vFeqe4BUkrcADQAtgukwgC7e_3dWj0uw5dcyO3BH.dMjrTyib2BK_1
 8KOk3aOd_Ga.kEPJM8j0E_viOpBeNGIVQx858k9jQRtP88pL246KfQm72cLm1aopQ4IFRyzc7WcD
 oY.QXyXpOdGgHF2WBqgjAB26LmBVPSe0KmmgGM6XzDmZHwg2Ctm_c.sa9.dj1p1Zn1kONLs.iRU5
 EWg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Dec 2022 18:40:52 +0000
Received: by hermes--production-gq1-d898c4779-4ndbh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ef2dfc38259307e04135ca905abfec6;
          Tue, 06 Dec 2022 18:40:46 +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.200.110.1.12\))
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
From: Mark Millard 
In-Reply-To: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
Date: Tue, 6 Dec 2022 10:40:36 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
To: adr 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NRTks2Q5Gz4P7C
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 6, 2022, at 08:56, adr  wrote:

> I'm giving a try again to freebsd in arm (I'd problems before)
> looking principally for system stability and a reasonable state of
> the ports tree, something I can't find anymore in other BSDs, at
> least with arm.
> 
> I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can
> run this board no matter of using 13 release, stable or current
> is with the EDK2 uefi firmware, in acpi mode only, and only with
> the ram limit.

I assume this means you run into some sort of failure(s) in some
kind(s) of contexts. But you do not describe the contexts and
their kinds of failures. If you want help, describe the context
and symptoms for the failure.

Given the lack of background information, my notes below may
reference things that do not apply to your context: general
notes.

One issue is that you can not use modern RPi* firmware. You
should use the RPi* firmware that is in the ports tree. The
official FreeBSD build materials are based on that. (I tend
to use something somewhat newer but I self support such and
did my own testing.) The FreeBSD kernel mishandles the modern
Device Tree content ordering, leading to a crash.

Note: PCIe is internally involved with the XHCI (USB3) hardware.
This explains the references to PCIe below.

I use both FDT and ACPI style booting of various Rev 1.4 "B0T"
8 GiByte RPi4B's without using a 3 GiByte mode. ("B0T" is from
the end of an ID printed on top of the SOC. "C0T" ones no
longer have the bad wrapper logic around the PCIe block. But
FDT based FreeBSD support does not treat "C0T" parts any
differently. "C0T" work just as well that way.)

For FDT based booting, I've had no problems testing/using
official build FreeBSD materials for releng/13.* , stable/13 ,
or main [so: 14]. (But I also sometimes run with a patch that
assigns a different highest DMA address to use with the PCIe.
Both ranges work for what I've been doing. NetBSD vs. OpenBSD
varies the address range used as well, last I knew.)

For ACPI, FreeBSD does not have the handling of limited address
range for PCIe bus mastering in the "B0T" parts. This can be
tested via duplicating huge files in 8 GiByte mode (such
as, significantly bigger than RAM) --and if that completes
comparing the files. The fairly recent UFS valdiation code added
tends to catch problems during the copy. Previously it was
silently corrupting some data. I have a patch to the sources
that I use to deal with making ACPI respect the "B0T"
limitation: ACPI does provide the information. So my ACPI use
is with 8 GiBytes --but via my self support for the issue.

WARNING: the huge file testing can corrupt the file system
beyond repair when FreeBSD is not using a correctly limited
address range. Test only media that it is okay to reinitialize
to see if a combination of materials is working!

(It turns out that, like FreeBSD's kernel, the ACPI
implementation always indicates a configuration valid for the
"B0T" DMA addressing limitation, even on "C0T" parts. Again,
"C0T" works fine that way.)

Note: the emmc2bus in the "B0T" parts also have a addressing
limitation that is not in the "C0T" parts. I've not yet done
any testing for this.

> I didn't expect this limitation after reading the
> wiki. The xhci dma bug has been corrected in netbsd and openbsd.
> Could someone share the state of this issue in freebsd? Also with
> acpi the ethernet interface is not detected, I'm using RTL8152/3
> usb cards.

FreeBSD has no ACPI drivers that cover the built-in Ethernet.
To my knowledge, the FreeBSD folks that used to work on the
RPi* support never claimed any ACPI support: only the
port U-Boot's FDT --and only with the versions of RPi*
firmware that have in the ports tree a the time.

The same sort of thing applies to trying to use microsd cards
in the built-in slot from FreeBSD after ACPI booting: no ACPI
drivers that cover the context.

The normal U-Boot FDT configuration has both of these working.

Use of ACPI is historically: strictly self-support.


> I'm impressed with the performance (without overclocking the cpu),
> really impressed. And the usb subsystem looks more stable. I had
> problems in the past (and in the present with other bsds), like the
> system crashing when attaching or detaching some devices.
> 
> Apart from the loss of ram and the inconvenience of not be able to
> use the ethernet interface, I'm feeling very comfortable right
> know.

Glad it is working okay for your context.

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec  6 20:25:36 2022
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 4NRX3k5nDkz4jqgS
	for ; Tue,  6 Dec 2022 20:25:38 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Received: from mx.sdf.org (mx.sdf.org [205.166.94.24])
	(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.sdf.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NRX3k3D64z4XsW
	for ; Tue,  6 Dec 2022 20:25:38 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Authentication-Results: mx1.freebsd.org;
	none
Received: from sdf.org (IDENT:adr@sdf.org [205.166.94.16])
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2B6KPabK008729
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
	Tue, 6 Dec 2022 20:25:36 GMT
Received: from localhost (adr@localhost)
	by sdf.org (8.15.2/8.12.8/Submit) with ESMTP id 2B6KPaeN026594;
	Tue, 6 Dec 2022 20:25:36 GMT
Date: Tue, 6 Dec 2022 20:25:36 +0000 (UTC)
From: adr 
To: Mark Millard 
cc: freebsd-arm@freebsd.org
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
In-Reply-To: <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com>
Message-ID: <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> <047DB634-2D87-402D-A65C-A4F517E042BD@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; format=flowed
X-Rspamd-Queue-Id: 4NRX3k3D64z4XsW
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 6 Dec 2022, Mark Millard wrote:
>> I'm giving a try again to freebsd in arm (I'd problems before)
>> looking principally for system stability and a reasonable state of
>> the ports tree, something I can't find anymore in other BSDs, at
>> least with arm.
>>
>> I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can
>> run this board no matter of using 13 release, stable or current
>> is with the EDK2 uefi firmware, in acpi mode only, and only with
>> the ram limit.
>
> I assume this means you run into some sort of failure(s) in some
> kind(s) of contexts. But you do not describe the contexts and
> their kinds of failures.

Yes, I could be more specific. When I said "the only way
I can run..."  I mean the official images don't even boot.

The errors differ but they were related to xhci I think.  I'll make
some test with the u-boot in ports, but after reading your experience
with other rev 1.4 boards I wonder if this could be related with
the eeprom firmware, if this is even possible.

The xhci|pci dma bug on the 2711B0 is well known, and if it is not
dealt with, you know the hell that is coming specially if your root
file system is in a usb device. Also ufs+su+j seems to have a funny
way to recover states with zeroed files, but that's another
discussion.

> If you want help, describe the context and symptoms for the failure.

Just take it as a report... to the list.

Regard,
adr.

From nobody Tue Dec  6 21:32:21 2022
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 4NRYY472mLz4k05G
	for ; Tue,  6 Dec 2022 21:32:40 +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 4NRYY44QP2z3CRk
	for ; Tue,  6 Dec 2022 21:32:40 +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=1670362358; bh=/cN4mK5i67xhBJgd+4XnOIYDEsAgWjH7BQlIGNkVsAU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XtHQVukedh8p8CprVG9WQrNrF2ATUkXh3EXJUbWMqqTgno5TzvaejPgLgyL5mGJJP24YOex1inrH/5wkhgVq6cQTwloUE7bv0wJM9eAD7enpBBnbjU8fJ0oAA/NVQGTdvVYOvPYy8M+j7JCfKd3iBDRCAFS5Y6vUP2jnQUmFmHIPgo+NCBEUWwh51V0ik9bbMfUBdORPHDePyUh4X8DdlgzPDC49HJPIzKs5LNdJ+Y83+y3EXbRz/3dviIi9c3xh7kk2oRtUmQhv5iOQJh2CsRbgQU+iLVp6YGvgNr/74quOnrHp0il8umLFUVQOiiqdAkuiWSaeytGOu26ByW/d2w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670362358; bh=lMSU+Ye8YriV9EDwJwShhJUDJR2N7dpR7/1NjEchHSw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ktn7HwXWlKmixhTWV8x6oqVKT9qmZkUlcLTKi7nIOx5gFnyvQqhVxXruaaBsQ306k3YVO3JTcwE5S3KZB3z3TWTuPfY3bTlCc+WVXHYmWRkZvd8S3e5UOC/IPe0596myepRomLnQiI93EsxHuyj1Jd2pda1CRdpktXJ6TfdDeV0GzQfxNygDfRiOpaeIvg/CKHupWFbNk4GrNQKEhYy+0Vbr7vQNT3/oVNIT+gXHaJHfSNfEHy+p5g0GnnN03cyiZ4mrexsS3zu+T1ksKrRf8+NrkzIx1M0Wb2TiEiivX+VQqPH8EhApsoZRPK3w0mtXGLsbdeO5C3Y2918dvPrdhw==
X-YMail-OSG: lfOgLmMVM1n__2.R6gdXnzVgPKHtmQTk7bnJ8dMG86gxI.lt8Eb4FuFNAMRXNbj
 ck5k4Nv9v9pL3EMk_PxB4emYXhUOF6daGx8Vhf7e5k4jSm.1mya.0FYKdozO8nzNLtZWneETNXY0
 mPf1h5AMf14qA7QZ5asTkR7_vnzFugPgBu...uwkE5dHJjId_tltJZpYqe0ITVgy55LKdY0WJ.Dm
 F6QyMeYuwCwM77d22DutyEGFX1JJiA1wqrNqAq9_CkYyGjVvsyf41t8ySZQ99K59A0fh_EsRrOyL
 NusSrK4757n8o5EIdXsO6uO_ZloMb.EKzdjH_..4StEuadpHiT3ziYQTY5TiAkmKnknS0TeZvADm
 DoZd0NkJaZ7_qVWE_0FbCPHtCl9c1zLFHoN.T_WeEYh0aVJrq19Di13piJyIM7YJjF.I8RHq4jt0
 PYhADD8n_yOZ4.uD7Vo8szTjPRZKC_GUVkxz78ObxPcowenskOJqrLwb8X7JYfXszK6gkavsX1Fj
 ZkPh_EnSfRNXEuNZVQk6oU23b1w1LM6WzXa.t9PJBUUl580kQ1WbbKxgHANYOc3FBB8tJXZmTHFg
 7GDnvIpVo_SQhhdXSQ8inj470TcH6Lfyr651SiIM_gnm_NSszGE1mLoUCgWfdMaa2Luy5Wpon8zz
 lofFcdXVIyCvKk3ZP9S71x6wmj1Ic0H.mf_8wmhPsIhbzK5pIdPqJLss7gvzSwAWfYHEq6Vrwb74
 Q1emb3ute.AA4zfz1f4FjotLFr1Jo7BAzSDjSsBolK9n3LP57nkk1SpoVlHYP.cqIatMAgUf6Cb7
 Z_HAcLDRKEIuzcVBJJmQpMjkHSN5y5o2SyfiH2OqfgKeUwegzqORLImS8dBgY5RtVvTtC1C1KWp3
 4sw2SGaJLo90N2ZTykEUwrU_tkFGCeYkxEjFBD6.D7ArB_UP6uWfxv5jNSfG_8un46mcTEVvBGxl
 98IAho4YmJu_E3LK4QnKiQTOFd6XHOlbcXGgyca5I8N4yfoVtLqkAtNGCNQlo5OAH5tGz8JL7NQx
 hrac56FrYToPYXmBScm.avZ03A43Hp9TQyD8udky4h_opF7Vm.M0H5eUm5cwLcvQxJDrn2s_Fx5O
 iUsBN2DwB597gtHhCfhztMg35nGIIFOY3aGNQMBsxu3pLF.iPGX7Rt9aQCVGWntZX12X1vYGdYgU
 XIg42Cd6pW6pkIpFREB3gnNXbzk5Vh2296lUmCstwv_0yhT6KyU93rVsTCbQsgXBrXqiTjoIo4LD
 _TCHuzjAwcYdIxifZ_Hpsh5fOmbeICZrV5pgE.ma1INp7wAs4mgepAanyQiu.fxun8JqmRkeLHjY
 RUVY2kt6vKiLYF2jMTkNNsFf2FZtmg32nQMWqaw5UdWHqvrt5a3xSduRXBTL6VkPgrA9Ox4ZoKY_
 AEijiG.QQmLKEQZqwVC2VPc7tvl.SyBJWW_7uhXnd31Z6nLUHlvkBNn3lzi4nPTwFqj1Wt7A1XYx
 DZDdA3RUE74dMQQ.vPjwQGmSXALl.dquOuPIVV0OskFWFEUaZcrxR9K6uG_zH.8PPF1PEBv9twkU
 4YuT14Qchj3LY1AYJuh452BjFNG7DT4tcz5pE5aW5oe2PACC.rbLMKxFsi8NSCNlFhG6RIuo.Ktp
 R7ILcvNKgEYhHMYEJV.IbVwOokJWX4CKjAk8tAzmCh3lrOg9AyDnPVnfh7iTTvC5CnuvbN4Vs4I8
 4Zyy.8Zh_qXV0ojTV1CD8sALyrpxP3LXgVz005SI6W7y1BvcJ7kfmvscvD1Bu65kH6cvPMoozX4B
 jVKMCZ64gfDNWWa7ewQdqEo_3bnVB3XB61fqSe9xYpEmOOK9LtDl4939ku45ohgVPJKYfXjV8nd.
 88OA17X7DQQTVY7Ampp3e8Nb7ZfP37tdDy8f2pCWXiNsS41Tjsskm1wKBMcFiVguXiDvf00zf0JG
 u0d_7RXWlejTnfuGgLQnmLzCVd51W5wBIy73cQA_woMBrxunQMaz9g6L39iivswRlTJ7ggDSMy7g
 JfwU2AuJ_bJ8u50SXhZNNfyTNP1DiVpEH.U1KCmjFxmCmLQ2qWwkefx7uvEEV3g6Pet_vNrm7e2F
 BWGkrOBapAZmaCSyYHCYaO5WWg595t55KE9MJqNvoL_LNJj43na7suiMdlqnHGGTDhMORLtOzbX.
 c8BkwMbfHJ_qkMI.nJ8GvNSKX1BXPm.84y0n9Fy1LXcBLZDZBqC774Rd9AcF0Cz4sD9195qWAtB5
 M4VNbCmTZ9Dl8asLp96nuZlJQtwM5PRHcu4yNu0k0FZhYfbAq_4dok5ILBayPy3474RD0IjIw_F8
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Dec 2022 21:32:38 +0000
Received: by hermes--production-bf1-5458f64d4-tg4jl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 511bc93ba47b35a93102c298fbf0422c;
          Tue, 06 Dec 2022 21:32:34 +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.200.110.1.12\))
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
From: Mark Millard 
In-Reply-To: <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
Date: Tue, 6 Dec 2022 13:32:21 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A1481BE-7312-4912-A353-F2CF71B20060@yahoo.com>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
 <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com>
 <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
To: adr 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NRYY44QP2z3CRk
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 6, 2022, at 12:25, adr  wrote:

> On Tue, 6 Dec 2022, Mark Millard wrote:
>>> I'm giving a try again to freebsd in arm (I'd problems before)
>>> looking principally for system stability and a reasonable state of
>>> the ports tree, something I can't find anymore in other BSDs, at
>>> least with arm.
>>>=20
>>> I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can
>>> run this board no matter of using 13 release, stable or current
>>> is with the EDK2 uefi firmware, in acpi mode only, and only with
>>> the ram limit.
>>=20
>> I assume this means you run into some sort of failure(s) in some
>> kind(s) of contexts. But you do not describe the contexts and
>> their kinds of failures.
>=20
> Yes, I could be more specific. When I said "the only way
> I can run..."  I mean the official images don't even boot.

How? Fails at what point? I have USB3 NVMe based boot media
that that fail to be found in U-Boot. I build and use a patched
U-Boot that provides a usb_pgood_delay value of 2000 that
is sufficient to allow that media to boot. As near as I can
tell, the media requires more time for something than the
USB3 standards indicate. The usb_pgood_delay value happens
to give it more time in U-Boot in a sufficient manor. (There
may be other, more appropriate settings for all I know.)

But, again, without your reporting the likes of the serial
console text leading up to the failure, I've no clue if
this is relevant to your context vs. not.

(The ACPI booting works with the USB NVMe based media just
fine, no adjustments to the internals of EDK2.)

(I have other USB3 SSD based media that do not require the
usb_pgood_delay assignment. But I use the same U-Boot for
them all --where I use U-Boot.)


> The errors differ but they were related to xhci I think.  I'll make
> some test with the u-boot in ports, but after reading your experience
> with other rev 1.4 boards I wonder if this could be related with
> the eeprom firmware, if this is even possible.

I currently use rpi-boot-eeprom-recovery-2022-04-26-vl805-000138a1 ,
which is one of the official releases listed at:

https://github.com/raspberrypi/rpi-eeprom/releases

There is a newer release listed as of yesterday:

rpi-boot-eeprom-recovery-2022-11-25-vl805-000138a1

I've not tried it.

I use RaspiOS64 (my abbreviation of their naming) to deal
with such EEPROM updates, not FreeBSD.

> The xhci|pci dma bug on the 2711B0 is well known, and if it is not
> dealt with, you know the hell that is coming specially if your root
> file system is in a usb device.

All my normal boot media for booting FreeBSD on the RPi4B's
(4 GiByte and 8 GiByte) the are USB3 media. I do not use a
microsd card for booting such at all. The whole/only UFS or
ZFS file system normally used is on that media.

Again, I've only seen the > 3 GiByte problem via a FreeBSD
not patched for ACPI DMA range handling but that was being
used in an ACPI context. (Wording ignores the time frame of
original effort to handle the > 3 GiByte issue via u-Boot
FDT style booting.)

(The patch supporting ACPI use is actually someone else's
that failed in my testing [the huge file duplication tests]
and I later figured out what the issue was and how to adjust
it.)

> Also ufs+su+j seems to have a funny
> way to recover states with zeroed files, but that's another
> discussion.

For UFS I use UFS+SU (no J). Other boot media uses ZFS (for
bectl use, not redundancy).

I'll note that:

git: 78f412987605 - main - Enable taking snapshots on UFS/FFS =
filesystems using journaled soft updates.

is only as of 2022-Nov-13. See:

=
https://lists.freebsd.org/archives/dev-commits-src-main/2022-November/0109=
19.html

>> If you want help, describe the context and symptoms for the failure.
>=20
> Just take it as a report... to the list.
>=20

Well, even if you were not after help, I can not tell if you have
found a different problem than I've ever seen. There is no way
for me to know, given what has been reported vs. not. (I've
definitely seen a variety of boot failures over different stages
on the RPi4B's in a varienty of U-Boot and ACPI based booting.)

I was surprised at the reference to standard FreeBSD builds
(or other port U-Boot based contexts) failing to boot (presuming
it got past U-Boot finding the USB boot media after its reset
of the bus).

The U-Boot context surprise, mixed with lack of being able to tell
if something new to me was being reported, lead to my sending out
the notes.

Even for ACPI, I would expect it to boot without the 3 GiByte
limit. But other forms of testing would show the context to be
bad [e.g., the huge file duplication tests].


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Dec  7 19:21:43 2022
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 4NS6bh6DMBz4jcYr
	for ; Wed,  7 Dec 2022 19:21:52 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Received: from mx.sdf.org (mx.sdf.org [205.166.94.24])
	(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.sdf.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NS6bh0Qrsz3JvP
	for ; Wed,  7 Dec 2022 19:21:51 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of adr@SDF.ORG designates 205.166.94.24 as permitted sender) smtp.mailfrom=adr@SDF.ORG;
	dmarc=pass (policy=none) header.from=sdf.org
Received: from sdf.org (IDENT:adr@sdf.org [205.166.94.16])
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2B7JLhx7003133
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
	Wed, 7 Dec 2022 19:21:44 GMT
Received: from localhost (adr@localhost)
	by sdf.org (8.15.2/8.12.8/Submit) with ESMTP id 2B7JLhsL011249;
	Wed, 7 Dec 2022 19:21:43 GMT
Date: Wed, 7 Dec 2022 19:21:43 +0000 (UTC)
From: adr 
To: Mark Millard 
cc: freebsd-arm@freebsd.org
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
In-Reply-To: <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
Message-ID: <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com> <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
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 [-3.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[sdf.org,none];
	R_SPF_ALLOW(-0.20)[+ip4:205.166.94.0/24];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[yahoo.com];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NS6bh0Qrsz3JvP
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 6 Dec 2022, adr wrote:
> Yes, I could be more specific. When I said "the only way
> I can run..."  I mean the official images don't even boot.
>
> The errors differ but they were related to xhci I think.  I'll make
> some test with the u-boot in ports, but after reading your experience
> with other rev 1.4 boards I wonder if this could be related with
> the eeprom firmware, if this is even possible.

It was a usb hub with sd card reader. There was no card there,
u-boot choked trying to read it. Yes, how silly of me.

I would appreciate if someone share his/her experience with 13.1
release, stable and current. It's there any advantage of using
stable|current at this moment?

Regards,
adr.

From nobody Wed Dec  7 20:52:08 2022
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 4NS8c61Qpsz4jpWG
	for ; Wed,  7 Dec 2022 20:52:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4NS8c566hjz3nbL
	for ; Wed,  7 Dec 2022 20:52:21 +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=1670446340; bh=NKWnCVeadCCmEHCO05hPhIg4ek60P4LApL6zx+7boMQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gZRMJ1OD49V778N3OW2YTwWtdagjf4KvV5ZyGD38Ys56GIg4w7mBs7GNVvv2E/+pOHspVa8nUJbLa1PDlLb42DqTzVE5kA0Mq1LxB8TkoCVewIZseTYBJMeDI9uGshWGm6piPp+d8gIQoSYOBF264xZZpkmTy+Qh0c8od/5loa2uoZ27TV333VnCvGA54xrcZ6QPX3lVCedxLKGHL9HpbwJSUhE3GuVkuuc2E/Uc50fs7EVDHiIZLywnuQn7uPvcaH/nnBI9wsj5bKYcMoGXGJjLMbyzENLf8+MCLwBv5Nxi8o/Ay5C9B68yeK7Eu+B/g1mQJ6XeCIUXC837SwqI7g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670446340; bh=hRaHkIW6xkl7nKnaILQc46xwiNi86gNOQ8HXMYHINCE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=DFduVeAZqgP2fv6hJXySi2lpb9ionbXrYRW8+/6hsSAIZ6qQbJ8OH4wGip+r93dEGQpyREpCQNM5pgPcji8NM6mbK4/hkrorAnIp4uimjzHApWBPd4r13oygyOb0yzWAVq+rfdJBfOsjEz2mY4A3QYvJOeYWuFDrn3LyGqdBXvpBUGMJ44C48afGSsf+2COSvyyLGEx/nRNsbM/Rgr51Bz7CKrBktNdIQtq05A6q7xmBZdKCUdlpmtU/qe/c/gkdy7e+yjsWPwEN4Zk7OIU523fB4gzXQGmY9uyVWT1m7XkruAU49HVO73CcRZ0qqgbJgJCPg3Mn7/mRN438HJSaxg==
X-YMail-OSG: hddig7QVM1nTThtWYpIUI64O38uNiwdJHOybPsGOI_Ye1rktto0YkJWvdjxju4e
 p0.X8Rcj.PbTu3lbLS3oidHVald7GWGEGMBV4uoWOt.BLv_xvINN3LFTct0UlmfxUTHLj6v2dLeX
 E_BbtCaAJLiKLfPFG5MO_Oue9EktFMmYzjboz3KWWOdiWjWwCJNYGtwMOIoPyGfbAzGO.1SKyW_B
 aOIKJ91qqrFcN5tjcoU8IJPA.tjf3L6MAuxOMMB8kHyPftP.EMYVrCjLB_tlJJv6XV0Y17Dh1LdQ
 zWPQvpwe1vaE3EQsV_.kdcGbw4nOdWoseaYwUzl3sVPx.mr0.Z.HRBdGhgFu9jxRRAptyTVf1LAP
 K_1EBUt9N27UhlHcgSDKq.DgUAyApDZiM4MqlGxQAm8X4sRa.h8LnKa9HJ_DDfgq31Pj_N_.T_is
 qWtmLTJw8_oIEYqlWdSPCCoI9zTROrtffskD2uemn0aNrrjYTHkKEaNcu4CeDr6TQM.yvvYVkka8
 bBP2vcPfStfv3xGQP.9J_.V5LAr5M6tJDsM7PjCoVrrZWjWz2wOosSAYmg.encsGNMovk7DmnSCl
 aJhJIGX5ECCQgoSw1Fpe3qWz3Oz5sSJV7uZtMMNJWQBfTdCkRJcc6MgVQdEivCFD1WQ03EoRoeUV
 R7u2m2Jiq8WpUcZS1u1a31DE2GaqWbsQp7tiPtTv_yMXuuxNTUTCGSoOnk4Az2FUyJ1.QvOCdwMY
 xjWnBsP5Z5w3RL17h18j97CLRqDCKe.61kPlg6m1f2rPDVyC783_Ja8ReEoitkhlxyTU.qB5Hv2R
 vo4.AEXkTgRoTjR7m6n088JI4am8nuHG3O2CjZts1aWdhoDLYUW_GUiaxS3m22pBkv8AOPi3983.
 z1FuRUoB1gUZfh4Uxvi0dutkEUJeWchHAJGFPYIiQ0QWwWH6ECXQV5unFRv6Em3zNfHZQlXhoByA
 pCon.VXpss_Wn3zF9Yh4Ceok.DKiX5UhQWJZbpG5Mo3oVS5R7uujJVqp9SwwpVYWRWw6V5RjlI0t
 0I6nnA_mTYz7Y_Wx_160Ctz8AA.QuhQGmlcOjSXVHKMzDIwAfnpIaxvEINRIAn0fQOHKw57D3Q5A
 682SlrlL2fYKfX2rsJe8ABN_eLVSc6W04V0GawswcM65KkzUyAe17nffvn2w68D.GwajgHX7lns5
 Nn7pZ0Y1v88SEQIYsU34MNBF5aP4w9I480r3CcLYZ6SVxmV5n9GC2kvXzgWF2a1XqaRKOVAcnv0z
 gzNWSO8IP.Ob1j4PyqxVslyHoZSWCGoTqFnLbGeWKEJSRejFaB8z8asYL2IsOOJWMLRvVBMYH.oT
 4bGN_1HNyATtZ1T5km64Sa49Hd6rc2IQ5YAyWS5vpvkxekNr.4AmuDo7uJh8RduZRJgKg88vvvLi
 0Lu2P4KEwKhbw4aLY4WoJfDCPIXLUv2.3cdImlGnNN9F4vd02kpOrYA9WYlqOxN1QICh1IbUK7od
 IUrbVb4DdtX3eKnqAxxM0kRUNK87EOMEWAqURTXOqyE3ZjbOiHBll50q._fIhm23UlZGr9NWWzWE
 7ATRF4mQ9U9bZeSKkJ0oLyayD5WmlgBLOVu2d0cWCbJgamRiOgRD7Juw40qoxTs7ymgl4EF6.qbg
 II.d6YHwlDEgbUsxBZr38mLxhgpl1fB_fvmrDF.k5Z6SmLH3Hq6Hnt9EqUlR3Vo2juI3x_Wo5t9s
 3gMldnO2rxyJsxYcajoBoJNy9uDntfhgO4RVFOVmVeXbzcfj_anBj6DPCJ2jV1VXydHz6jqkrsQZ
 IAzDlMf6yCyVkhxIrD7slrsYcpxZ_EB5oSc8OtJaDcyFqyAYo5FkQNfBBtfBiBQzRZpEJqGA6i.A
 mcgFg7jy.8oenIcGtDeokuc1ztTpgt1MTf2eB4kpJctbs_p51.P6l5xt0L18QLkGp9I5UwzsV80X
 xkkmHAlUwRl59CV2tNJURTDcUP4b3j.7_0NM4Iqk6UdIX9pe1aZ6IxvqiConur4P_mcA5xdvw0ue
 3QHECDD6gz0ZjJo_GqZpeLs9NKs27.aAq8EQIOOrIt3tUw6LeHPESvXC9S2THSaG7KD_0Q7fTtHd
 VpVmujG5UfEaetNAT8JVgsisroMlN70KPXop_hve0_npV4ltgRJPME.TiLaJXpKnMLAEPWdQDYOm
 25Zrt4wfeqgavWOxzfIXi0WCMIuMhg7YDxfxVMmiYqSGJqdonOf0fL.ox9cizOKymUTIGum.wlAV
 MjJahEEPlik4roDuej1olcY7BGiIE30cxScJtDP091ZLioaRbnyAoIBCX7hFvELVGJeQQzeR74P_
 3
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Dec 2022 20:52:20 +0000
Received: by hermes--production-gq1-d898c4779-wpm62 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6562da319f8bb89683893d9a55fa2aea;
          Wed, 07 Dec 2022 20:52: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.200.110.1.12\))
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
From: Mark Millard 
In-Reply-To: <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
Date: Wed, 7 Dec 2022 12:52:08 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: 7bit
Message-Id: <35EF99CB-ECA2-4F93-9CC3-6528820321D5@yahoo.com>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
 <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com>
 <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
 <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
To: adr 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NS8c566hjz3nbL
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 7, 2022, at 11:21, adr  wrote:

> On Tue, 6 Dec 2022, adr wrote:
>> Yes, I could be more specific. When I said "the only way
>> I can run..."  I mean the official images don't even boot.
>> 
>> The errors differ but they were related to xhci I think.  I'll make
>> some test with the u-boot in ports, but after reading your experience
>> with other rev 1.4 boards I wonder if this could be related with
>> the eeprom firmware, if this is even possible.
> 
> It was a usb hub with sd card reader. There was no card there,
> u-boot choked trying to read it. Yes, how silly of me.

FYI:

U-Boot has problems with individual USB devices (one USB
port in use) that have multiple LUN's in the device that
are populated with storage media. Having media in more
than one slot of a multi-media reader is an example.

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441 . It has
the subject:

U-Boot build for Raspberry Pi 3B and 4B (arm64) does not boot
from MicroSD card slot when >1 USB storage devices are present

The issue has been demonstrated on Linux systems that use U-Boot
as well. It is not FreeBSD specific at all. Similarly, I've
demonstrated it on both RPi4B's and a Rock64: not platoform
specific either. It appears to just be a property of how U-Boot
works things days.

Another earlier example was reported in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253983

Subject:
RPI4 boot fails when geekworm x829 is attached over USB

(Mistakenly classified as "closed fixed"). This was not a
multimedia reader type of context but still involved the
multiple storage media via one USB port kind of context,
so LUN's involved. It was Comment #42 before I'd managed
to duplicate the problem (via finally trying a multi-media
reader with multiple storage media plugged in).

> I would appreciate if someone share his/her experience with 13.1
> release, stable and current. It's there any advantage of using
> stable|current at this moment?

One big issue is how much self-support and tracking of
status of a branch is reasonable for you? Is doing your
own builds from source and installs of them reasonable?
Is the time for building from source going to be
tolerable, including when large time-consuming subsets
or full rebuilds are needed?

It is messy to update an existing install from a snapshot
or from artifacts.ci materials (the only forms of prebuilt
stable/13 or main [so: 14] material available). These are
normally build-from-source and install-update for updating
once the initial install is in place.

No builds are required for progressing from 13.1-RELEASE
to 13.1-RELEASE-p?? and eventually to 13.2-RELEASE and
the like.

Without having a clue what the range of intended usage
is, I'm not sure what other aspects would always be
significantly involved in driving the choice of which to
use. My context is rather limited in its range of use,
so I'm not likely to have as much to contribute as various
other folks.

For reference, for weekly snapshots and for artificat.ci
snapshots there are:

http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm64/
and:
https://artifact.ci.freebsd.org/snapshot/



===
Mark Millard
marklmi at yahoo.com


From nobody Wed Dec  7 21:05:28 2022
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 4NS8vV2qq8z4jqkk
	for ; Wed,  7 Dec 2022 21:05:42 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Received: from ns4.genyosha.net (ns4.genyosha.net [50.53.250.75])
	(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 "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NS8vT6lktz3q3r
	for ; Wed,  7 Dec 2022 21:05:41 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from dragon.home.genyosha.net (ops.genyosha.net [50.53.250.77])
	by ns4.genyosha.net (8.16.1/8.16.1) with ESMTPS id 2B7L5X9m037123
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Wed, 7 Dec 2022 13:05:34 -0800 (PST)
	(envelope-from sr@genyosha.net)
Received: from dragon.home.genyosha.net (localhost [127.0.0.1])
	by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 2B7L5SLs007624;
	Wed, 7 Dec 2022 13:05:28 -0800
Received: (from sr@localhost)
	by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 2B7L5Sxb007623;
	Wed, 7 Dec 2022 13:05:28 -0800
Date: Wed, 7 Dec 2022 13:05:28 -0800
From: Steve Rikli 
To: adr 
Cc: freebsd-arm@freebsd.org
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
Message-ID: 
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG>
 <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com>
 <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
 <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
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: <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG>
X-Greylist: inspected by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Wed, 07 Dec 2022 13:05:35 -0800 (PST) for IP:'50.53.250.77' DOMAIN:'ops.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:''
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Wed, 07 Dec 2022 13:05:35 -0800 (PST)
X-Rspamd-Queue-Id: 4NS8vT6lktz3q3r
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:20055, ipnet:50.53.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Dec 07, 2022 at 07:21:43PM +0000, adr wrote:
> 
> It was a usb hub with sd card reader. There was no card there,
> u-boot choked trying to read it. Yes, how silly of me.
> 
> I would appreciate if someone share his/her experience with 13.1
> release, stable and current. It's there any advantage of using
> stable|current at this moment?

I'm running 13.1-STABLE on a rpi4 8GB, and it has been almost uneventful.

It was originally installed using the 13.1 -RPI.img via 'dd' as per the
install notes; I've been keeping it updated from src since then.  I do
miss the 'bsdinstall' method and being able to control the installation
choices a bit more, but it's not a huge problem.

No manual changes to uboot or similar.

I'm using a regular microSDXC for sysdisk, I may switch to USB at some
point but so far so good.

I'd like to re-partition the sysdisk, either via reinstall with my own
img or adjusting things post-'dd'; haven't sorted out what I want, or
exactly what method, yet. Ideas and suggestions welcome.

Since I plan to use it as a small DNS etc. server I don't miss the wifi
NIC not being supported yet. Later on I might care more.

The only somewhat interesting thing about it that comes to mind is I'm
running the rpi4 headless using a GPIO "Serial Hat" for rs323 console;
for those who might be interested it's this:

  https://www.pishop.us/product/serial-hat-rs232/

There are other similar solutions, I chose this one for simplicity and
cost and finding a case with cutouts that match up well enough. This
allows me to console my rpi4 the same way I do my FreeBSD NUC's and
other PC's which also have rs232 COM ports.

I'd prefer a nicer (and maybe aluminum?) case, but finding something
taller for hats, as well as having the extra cutout(s) I want now and
down the road, has been scarce pickings so far.

Overall for the rpi4 and FreeBSD it has been a painless install and
pretty seemless operation for me. I look forward to getting another
one at some point when they're more readily available.

Cheers,
sr.

From nobody Wed Dec  7 21:42:24 2022
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 4NS9kF4NMkz4jvZX
	for ; Wed,  7 Dec 2022 21:42:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147])
	(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 4NS9kD4S39z3vps
	for ; Wed,  7 Dec 2022 21:42:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=GitM+0bf;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 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=1670449362; bh=lZq2+/+6CEjGzdHchUUJHZp1nf1dJ04iaVcLRbNvrn8=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=GitM+0bfJ23Bu+xA7oNjsNydGovZSDFQ3pkSkmWQU8tSwBl9dcjexljx205l58U0bL27cklpBnJtmd8TcKZOKUVav7+eP9CO2JH62WlwqoQmQS4Js3XWTmmskW1XOtDgxPQdC3u8L5sgl0SrW6F2bQlyxxexMDD0TnTspFSStF0DF9TMY4p6cbhqvO8IzZdFOMh2icnFn9kKF2C8rmpJwVpbg8r7hYHTo9qW6NXJldVtPrpPgRWXbj0C5r5J3gsF7zBOy6mpk6conSB5hYV+h8ES654WrwoLJEqiQsQnXMvs5tHvZeNcACYgeJxGEuKSWqJtes5ZYsr97OZqYdxdcQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670449362; bh=sSrOW6tHQZw+ZS9f2tw8E8s2zxZ5z8tAUtkMOZp2ZMZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FQ7PVoyLKgXizdgslZqhD8A5nzSAx9MjY7uF/07FCo6kK4Kc5Xd2uYxZqDI4BrnhHjIsUyo1xjm2Z79F8ZtxgxsSNjSubCvuIbBp/RoRCgRTZGQKYePut5KMbEnzru+Ulgn1ultaLYNPG5ConmfvutITCh52If78qFKZfswbiLGOH9m1gtX1JTWSw2BU7wubO+x3l7L+jZyshqN/N7YwWIK62AlRkL8/FcfODCJBAjQykRjvlDbFUFFMyhMY1rc7OUTEb/2eZkXSBd7NkPXqDNZXd2hhOxbSfnHwPgEGn60sjj3ZFhwhKR1qyTmtdMqjShmA9BF/lKD+osqHPXqj2A==
X-YMail-OSG: oOlFPF0VM1mkzTOEbwZtjCZDuTy_I0LL_rpjEp6dic7Dm8hX3N87VzMw_djmrf.
 Iaqfn62SExIRqPrrZO8y8v3DGGaFa6wVG0AQ__DZGWn30p4.rK5HefN53yiC7ijEz6iSO0ETqoN7
 JQDz8m5rXr8au.FhEivMjxv9eXo2tVulQD3aYR6cy5U5O.HL2iZ31EUTdizD59XGnam.h4bYcFWD
 4Cu2Ci190ydmuyKVP0YTJqAt5wi.2IZPE1pCwUGq2E442HatLlqMUnbIJxldUFhbNi9amzIcTeLJ
 swNB_Nr38jBgdsw1MdifDyEpsDkiJQnoovkgMWqfC.md52Li1OkvO0Kx4Qgb1VASAjEyqVHFyJRH
 JZ0jUUUNeK2CF3cx8l02mJISLCqJuD6mShnCkJ0PzVYTW0WsQqFIfa6W4Kxgs_KbWK2WzR6e1QOm
 TvgT0pvdJmRW.J7y40eYIoH_lJjL9stLT7qW390ZqY5D0frogJfpVT0fbunvvaIReGboUd0izKJE
 wqqUyHBe5brDwNnur.omT3sGiB7LXZfacntaJJAi8XlrFTibNM.5zQI3wdIjvh4WM.zyxG1zSsdX
 ItMuwpl13EqtZ4n1BWGwHMgmT6BXQ7BATwP8ZibUYdArtMD_kr581.mNS5aMcE1.2BjMQ9ah.rTo
 2dDOtlS8D0z8XgdRvECzrGl_29nwXhwGX9dMN1sWwH3bYbKQijG4yA6vdA9tRZnGl4UaAkB480ra
 sBYfQekdoynE6_ZXwCC.U7T4Yy0L83SFRBpObzsVWF4ICqwbJL70_39Qkl6s90irQYy0WDQ5P4Ev
 IhMM874i3A9AOJLei7.2nryPZriDDpGiHZz2lD.DnvvIggc8D57JCTYrsS7A1yXqkOWCheJi59nn
 j4arzL5Tj3mDYqY8.PeohdAHoXERUQb4I.J.80zfpZlZadKPiiy.i0sy3POgGN4VMjiegH3rDO0m
 aMq_D_EKeyiaMILUp9FoYnFFbQURCvqotzvBxzZF0mO5BmMVVkZvidjVFTaqcYqEuhQDfZuyiDUW
 5S3arsN3qb2owAYbWn8hx0Yx0PcJIOFwztQN3OHpnLCOmDbsq2wzLi76bnvXKePi854Yc1UUh_yo
 Ip_LDq76TWKLiZjFOhnPoT_PD_gjw2cYMKWWJSN1FVTrX3oYpfiL0yshpxeaugV8n7Xsb7q.hZhs
 .0VNxGrVqmPSXuyokeGpu2JycE7BRM75TX1vDWajBhHM9Pxf6Dd4cU7OTsq872tclbUMWQFVDh17
 9WDzV3kxK5YCFJCJjB8GBB1E2c.sTXqo9rUbv7mNoUOyFs23x6aB1XiDJcJdyuVYeF49XX2pP1f.
 fVo3kpHjtTLoDBqj5xMFAau3t.Pc8bMve9y8kKhPXQXam6PbHLMkF28J4eJcsCYbOj11YnP6Yyrl
 MoqP.g2fKcUf1SMs7RZiW2GXAri3eZKWFNWDqYDrHDXIWp59fvG_jeI1EDHwA4hic6OmRIlUJ8lQ
 3SOqIGYb1eZdf_apGJnCeSC9IsDK7ohYtI8zj5Yxl2zyfklhJfSg91EWkuJ81jxYnJndcbBFjhpX
 dqzEegjrQIpFDxgNhOjDsBRoRbuH_5VuHfvKw_50PVr4T6Wxjph6ciUJyi1MqE9a20LS2NSn545Z
 yDFYRKZDlvT5xJ95bgDYnJHwiDr3_WwbVkQVnWjbzrqWa8txeW_pfd4fPUMtSkRPZTTSBX6gU3le
 v9zkEsN62_.ilvMSciuN8lVg6mcI0JVQkbEUfiVKfPGbXK6S54i_kClA4_SV43SFxHyPUn.Vlind
 AAFakuIhJE.GJgUlMQq6Qd4V3m3VsKkwcU_xyStVYb0GuaT7uPZcD7s.O_fgKfbeODKRIIEYB7.s
 CQjIwepUuoMEWqAAsF87FNcKr_MBEE6TpM6JNCJP9eJGvEafvUWhG9_.hHUSJp4tbSLQ7XId4U39
 nnzbxyMgHJ8dHDXbKgcSFlx3p63lCVkr7EywutGbRerZHwd3GRvvnwdm6gSXgZePzpPwnTFpqTUO
 qsd7S7IcigP4Nodyf.6rZe4AM0PJoHdqOwGCWB10YcSNV.GUUSWHvGhnc5ZlE95sPiS2NYlD5Wfi
 B0O.VR8cSzVZECPpvvRFYYxkYYRfFEmzb1h9py_FIe8IzaC4wDfP..FeQAFMcHGmD9mhVL12mtYe
 rvypLOH6QyXf_mb2kkTfRPcREas4PMoyEbUVUuEAFHzmo9lm04ZeSvDerlE_t.0tBD6crtyF9H9i
 Yn9cku4KB7ckJ6JfEC6C1Yjte8siN0jf3Fa6V_Y6wwxCJJkuT5LvINiNTeXPbOmM6wNlQuVw0f1w
 BLek-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Dec 2022 21:42:42 +0000
Received: by hermes--production-ne1-7b69748c4d-kwzvj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 02bdea0e3b1d6f54655dbe7fa386c183;
          Wed, 07 Dec 2022 21:42:36 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: A possibly unintended consequence of the kernel's alloc_bounce_zone
 implementation?
Message-Id: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F@yahoo.com>
Date: Wed, 7 Dec 2022 13:42:24 -0800
Cc: freebsd-arm 
To: FreeBSD Hackers 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F.ref@yahoo.com>
X-Spamd-Result: default: False [-2.43 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.93)[-0.931];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]
X-Rspamd-Queue-Id: 4NS9kD4S39z3vps
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

I was doing some exploratory investigation of getting a "C0T"
RPi4B that does not have the PCIe block wrapper logic messed
up --in order to avoid much of the bounce zone usage that adds
to the challenged memory/RAM-caching subsystem involved. I
ended up noticing an odd property of the alloc_bounce_zone
implementation when I tried to have a larger hw.busdma zone
show up. (This was before trying to get beyond 4 GiBytes.)

To simplify the description below, I use examples of extreme
conditions that are simple to describe.

A)	Presume that the sequence of calls to alloc_bounce_zone
	never had an incompatible alignment. (dmat->lowaddr is
	the point here.)

B)	Concentrate on two ordering properties across the calls:

B1)	The various dmat->lowaddr arrive in a strictly
	decreasing order
vs.
B2)	The various dmat->lowaddr arrive in increasing order

(B1) will produce a hw.busdma zone for each distinct value of
dmat->lowaddr .

(B2) will produce one hw.busdma zone with the smallest
dmat->lowaddr being used for all the bounce activity.
(The smallest could potentially be rather small.)

It turned out that the RPi4B basically had its smallest
dmat->lowaddr in the 2nd alloc_bounce_zone call so all
later alloc_bounce_zone calls used that zone. (The actual
size was relevant to me only because of the investigation
involved.) This wording is slightly simplified from the
actual context but should be suggestive enough.

(I changed ">=" to "==" for my investigative activity,
making the results be more like (B1), but independent of
dmat->lowaddr arrival order. The zone order ends up being
a permutation of (B1)'s order.)

Are there any consequence of (B1) vs. (B2) big enough to
make the existing implementation somewhat of a problem?
Since (B1) can happen anyway (so: is a valid result),
should the order dependency of alloc_bounce_zone's
behavior be removed to avoid (B2) type results?


===
Mark Millard
marklmi at yahoo.com


From nobody Wed Dec  7 23:21:08 2022
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 4NSCw15J0Tz4k6sJ
	for ; Wed,  7 Dec 2022 23:21:21 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a])
	(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 4NSCw118kBz469N
	for ; Wed,  7 Dec 2022 23:21:21 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=VZzfOUPE;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::102a as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x102a.google.com with SMTP id u15-20020a17090a3fcf00b002191825cf02so3226548pjm.2
        for ; Wed, 07 Dec 2022 15:21:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=iY0zNg9Qf9F4/u34ojZdK7ba3EAd9JYFakqbIi+Pz2E=;
        b=VZzfOUPEOfufozbJUIPjVTL3+33Ugzmf93Ypijc7PHc+0bwBo/x0I+7YjCPBQOV1cP
         t/nZ/k+31e1vessyM1SM6Rkr2PzmJ2DPT72Ch4dAb4arRK+15y+84Oxr2YJWWVdGqwTW
         dw9HuU8PBXfnO4eVOe4zQYdIcrC7zdwPLyk5tUETfPIk5iyDFTP/nyF7NW9XGN0+bK7w
         BQCged88XTBx71YHcLn2lttTqMeMyo9VxUWgaCkAL115B9zlmxhpVu+xc741g/+J38xV
         4Uau19WJStLtHYDMqAfl5f4m5ytaLX9KVOWfyLr3xc+tKNpaEU5IWzqNgDMPubf3eGto
         TujQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=iY0zNg9Qf9F4/u34ojZdK7ba3EAd9JYFakqbIi+Pz2E=;
        b=ug7jTmrGEcOTlqF94BtgY7DkKFhgV0HEbmQTYBaCro4vlCCtQykWkDIGBVXWZonRfl
         AlS1WKgVGI2jGMBX5GNXO0XNp2K9iiUJbQmKTf6jfI1MLz0FeKfVNk15iNZLcVawiuaW
         FPCj15b9I1P/kw3qNSQIOIQ1OkTZMHPJY0SrtSX4Wyf2NzZj78QLlSV1+LAJBDeSxNnT
         kGS1iAlxarM1a4VZ5KPonBr0gQ3KonmYx/7lR4klMrEqpPprbtBnS1J+ry9mMbNfRaok
         TctxUYimf+u1rSAXGYOwZ35qxn1votNyhLfgKzm9mHb0CuHc2QYDAWTkY58QEFCs9XQK
         1FqQ==
X-Gm-Message-State: ANoB5pk5/apwknDxUNPow38Nuaa8e/vdRG0Mkv9ATP6y+xuCuKzyYenl
	Zt1qCh+kqt7/KIxJnGIBGaOB2YBr8yvXDpz51BQ=
X-Google-Smtp-Source: AA0mqf6MDmjItsgezqlApLeY+9VKjVy18P/i+Nl6CMxm7D5Vvt4W1tDmcADiEh92bAmgRbXJUFpEPJdZzzcK2Hopal0=
X-Received: by 2002:a17:902:f78c:b0:186:8c13:50b3 with SMTP id
 q12-20020a170902f78c00b001868c1350b3mr75788840pln.153.1670455279694; Wed, 07
 Dec 2022 15:21:19 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Thu, 8 Dec 2022 08:21:08 +0900
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-3.22 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_SHORT(-0.22)[-0.222];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NSCw118kBz469N
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
>
>
>
> On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F)  wrote:

>> OK, I (and the subject) was wrong. The loader boots, and show
>> following log at last:
>>
>> Loading kernel...
>> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
>> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea]
>> Loading configured modules...
>> can't find '/boot/entropy'
>> can't find '/etc/hostid'
>> No valid device tree blob found!
>> WARNING! Trying to fire up the kernel, but no device tree blob found!
>> EFI framebuffer information
>> addr, size        0x80400000, 0x7e9000
>> dimensions     1920 x 1080
>> stride             1920
>> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>>
>> and it stops here. No "<>" line is displayed.
>> So, it seems that the kernel is loaded but could not be started.
>
>
> There are several causes of this.
>
> Most likely is that the console is setup to go somewhere else. Though if =
you are on the video display and getting that framebuffer output, it won't =
not go there w/o some setting to override (say to force serial).

In the loader, when comconsole->c_init() is called for the second
time, the function does not return. (I commented out comconsole to
make the loader work, but it is rather brutal and is not a proper
solution).
But the function parse_uefi_con_out() in stand/efi/loader/main.c
always returns RB_SERIAL, so the loader tries to use the serial
console.
If a similar thing happens with the kernel, it may be stopping at
serial console initialization.

> Next most likely is that FreeBSD doesn't cope well with having both FDT a=
nd ACPI information available. But since not DTB is being passed in (per th=
at message) that's not likely at play here.

I managed to load the dtb file and the boot process stopped at the
same point. The problem is not here?

> Finally, the loader passes a large number of tables, etc to the kernel. I=
t's quite possible that, for reasons still unknown, that data is wrong or i=
f standard conforming not expected by the kernel. this leads to a crash bef=
ore we've setup the console in the kernel which looks a lot like a hang.
>
> Warner
>
>
>>
>> > . . .
>> >
>> > Such also happens for stable/13, releng/13.* based installations
>> > as well --and likely others too.
>> >
>> > ACPI booting does not use Device Tree information but the messages
>> > are output anyway about the lack. Only if you know that the context
>> > is a Device Tree style of boot are the messages actually reporting
>> > a problem.
>> >
>> >
>> > =3D=3D=3D
>> > Mark Millard
>> > marklmi at yahoo.com
>> >
>>

From nobody Thu Dec  8 01:18:57 2022
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 4NSGWm74Bwz4kMm0
	for ; Thu,  8 Dec 2022 01:19:00 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Received: from mx.sdf.org (mx.sdf.org [205.166.94.24])
	(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.sdf.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NSGWm3vS6z4Qw5
	for ; Thu,  8 Dec 2022 01:19:00 +0000 (UTC)
	(envelope-from adr@SDF.ORG)
Authentication-Results: mx1.freebsd.org;
	none
Received: from sdf.org (IDENT:adr@sdf.org [205.166.94.16])
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2B81IwIv000188
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO);
	Thu, 8 Dec 2022 01:18:58 GMT
Received: from localhost (adr@localhost)
	by sdf.org (8.15.2/8.12.8/Submit) with ESMTP id 2B81IvYc004224;
	Thu, 8 Dec 2022 01:18:58 GMT
Date: Thu, 8 Dec 2022 01:18:57 +0000 (UTC)
From: adr 
To: Steve Rikli 
cc: freebsd-arm@freebsd.org
Subject: Re: FreeBSD on RPI4 B 8G rev 1.4
In-Reply-To: 
Message-ID: <8148b26b-31b2-9dc2-ea94-8a893602849@SDF.ORG>
References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com> <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG> <5f1ba830-60e-407d-c09f-d75ab0946ca6@SDF.ORG> 
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-Rspamd-Queue-Id: 4NSGWm3vS6z4Qw5
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:14361, ipnet:205.166.94.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Thanks Mark and Steve, I think that I'll stick to releases by now.

From nobody Thu Dec  8 18:18:45 2022
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 4NSj8h2V3vz4k5dx
	for ; Thu,  8 Dec 2022 18:19:00 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633])
	(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 4NSj8f4F62z4Gx0
	for ; Thu,  8 Dec 2022 18:18:57 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=os0KLKjP;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::633) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x633.google.com with SMTP id bj12so5922736ejb.13
        for ; Thu, 08 Dec 2022 10:18:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=KFQUhafm0EcNZwgxKBH8VFNqUc+fkLZRs0wbNrx28Hw=;
        b=os0KLKjP1dzVxZIuHOdkaDEBQWo94pBWmkjs9jpp3EYwE6DNatHBVHA8PRkd7ooqyz
         00MuqClvEDEVOIZDqyTrosJNB0K44o1xRw8wZWmIsSxkQdosNdddMggY3XRa8XzutcTt
         nMJYLeemlXAx4J5kzpeDx73K3a7J/fZ5fWFExast84naPRV3MOAUbhwKKanXHI4fF++B
         fkZiAE3qQ5gkCNREXlbrE96fO0BD/Q+QIXq9pzCB0ePZ3FNaWNnKIBkBbPAVpLnyaENX
         fx9s2AXKNhfMJLln6CWEzwgDJiiJsVAWxL5Pzarb62dO0nvavWSr01y6grT1cw1f4u2d
         pBhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=KFQUhafm0EcNZwgxKBH8VFNqUc+fkLZRs0wbNrx28Hw=;
        b=cNy54DKspFlFZ+LIyOStAirfxYsGu3ey28xtuLqh7zLHsyS34OqnY3nYRyRIRF+joH
         lZYLuvCbRrYH0nPSHUExRtHXZZNe3mNy/WJo33zAVfPY12cnz8D9jxs+mkMJNT5mwV4M
         F6me2qfpcEG50u1keolIeH0T8EZEPNzoT5a5V+BkPd8aycoXiCpL7kJIy8O7rdRLz0yX
         xJ3DafsIYbT/T3XpOCt5xOYldL8DGg826um7WqKNcP4G8OL0nVs1kIEfGRhIT0+Ao1O/
         vLKe7sXCh7ZKQEq0rp+01Bjbz8KxTnqWnVKkar0Mr6ftuI/SjVDfPnmU6/vd/xf0SDMi
         hHkA==
X-Gm-Message-State: ANoB5pmU88M+i0W45SprvB5THFM5EkG+A72HkQNp8ZPdupBMeViuZHZn
	RzsSUHY8q/EFoTP4hAZ2n97BWIsob0Cc5IxCrqwBXdbydFnlmflc
X-Google-Smtp-Source: AA0mqf5LSbdzpZ/IgQl++p+Zs9gweBb7WYPY5DrcP4yuSQRD1WmZxnW7fkYMydpHjjYmTQSZgtdcRuSh7MwvEI2+wgk=
X-Received: by 2002:a17:906:29c3:b0:7c0:e0db:f136 with SMTP id
 y3-20020a17090629c300b007c0e0dbf136mr16127707eje.333.1670523535985; Thu, 08
 Dec 2022 10:18:55 -0800 (PST)
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: Thu, 8 Dec 2022 11:18:45 -0700
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f39fbc05ef5511ed"
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)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NSj8f4F62z4Gx0
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f39fbc05ef5511ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=
=9F) 
wrote:

> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
> >
> >
> >
> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
>
> >> OK, I (and the subject) was wrong. The loader boots, and show
> >> following log at last:
> >>
> >> Loading kernel...
> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea]
> >> Loading configured modules...
> >> can't find '/boot/entropy'
> >> can't find '/etc/hostid'
> >> No valid device tree blob found!
> >> WARNING! Trying to fire up the kernel, but no device tree blob found!
> >> EFI framebuffer information
> >> addr, size        0x80400000, 0x7e9000
> >> dimensions     1920 x 1080
> >> stride             1920
> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> >>
> >> and it stops here. No "<>" line is displayed.
> >> So, it seems that the kernel is loaded but could not be started.
> >
> >
> > There are several causes of this.
> >
> > Most likely is that the console is setup to go somewhere else. Though i=
f
> you are on the video display and getting that framebuffer output, it won'=
t
> not go there w/o some setting to override (say to force serial).
>
> In the loader, when comconsole->c_init() is called for the second
> time, the function does not return. (I commented out comconsole to
> make the loader work, but it is rather brutal and is not a proper
> solution).
> But the function parse_uefi_con_out() in stand/efi/loader/main.c
> always returns RB_SERIAL, so the loader tries to use the serial
> console.
>

I wonder why that is. Is this -current or -stable? I have a rather large
backlog of MFC-able loader changes. If it is with stable, then it makes
sense: I fixed a bug where parse_uefi_con_out would return serial if
'8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now we
return Video console if we fine evidence there's a video console.

Now, why it fails the second time, I don't know.


> If a similar thing happens with the kernel, it may be stopping at
> serial console initialization.
>

The kernel doesn't use the EFI routines to initialize the serial console.
But if the kernel is being told the wrong console, then it could also be
booting just fine or almost fine and hitting some bug later.


> > Next most likely is that FreeBSD doesn't cope well with having both FDT
> and ACPI information available. But since not DTB is being passed in (per
> that message) that's not likely at play here.
>
> I managed to load the dtb file and the boot process stopped at the
> same point. The problem is not here?
>

Yea, I don't think so.

Warner


> > Finally, the loader passes a large number of tables, etc to the kernel.
> It's quite possible that, for reasons still unknown, that data is wrong o=
r
> if standard conforming not expected by the kernel. this leads to a crash
> before we've setup the console in the kernel which looks a lot like a han=
g.
> >
> > Warner
> >
> >
> >>
> >> > . . .
> >> >
> >> > Such also happens for stable/13, releng/13.* based installations
> >> > as well --and likely others too.
> >> >
> >> > ACPI booting does not use Device Tree information but the messages
> >> > are output anyway about the lack. Only if you know that the context
> >> > is a Device Tree style of boot are the messages actually reporting
> >> > a problem.
> >> >
> >> >
> >> > =3D=3D=3D
> >> > Mark Millard
> >> > marklmi at yahoo.com
> >> >
> >>
>

--000000000000f39fbc05ef5511ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Dec 7, 2022 at 4:21 PM Hiroo =
Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
2022=E5=B9=B412=E6=9C=887=
=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh <imp@bsdimp.com>:

>

>

>

> On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:



>> OK, I (and the subject) was wrong. The loader boots, and show

>> following log at last:

>>

>> Loading kernel...

>> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
>> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x143=
9ea]

>> Loading configured modules...

>> can't find '/boot/entropy'

>> can't find '/etc/hostid'

>> No valid device tree blob found!

>> WARNING! Trying to fire up the kernel, but no device tree blob fou=
nd!

>> EFI framebuffer information

>> addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80400000, 0x7e9000

>> dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080

>> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01920

>> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00ff0000, 0x0000f=
f00, 0x000000ff, 0xff000000

>>

>> and it stops here. No "<<BOOT>>" line is dis=
played.

>> So, it seems that the kernel is loaded but could not be started.
>

>

> There are several causes of this.

>

> Most likely is that the console is setup to go somewhere else. Though =
if you are on the video display and getting that framebuffer output, it won=
't not go there w/o some setting to override (say to force serial).



In the loader, when comconsole->c_init() is called for the second

time, the function does not return. (I commented out comconsole to

make the loader work, but it is rather brutal and is not a proper

solution).

But the function parse_uefi_con_out() in stand/efi/loader/main.c

always returns RB_SERIAL, so the loader tries to use the serial

console.

I wonder why that is. Is this =
-current or -stable? I have a rather large backlog of MFC-able loader chang=
es. If it is with stable, then it makes sense: I fixed a bug where parse_ue=
fi_con_out would return serial if '8be4df61-93ca-11d2-aa0d-00e098032b8c=
-ConOut' was unset. Is it set?=C2=A0 Now we return Video console if we =
fine evidence there's a video console.

Now, wh=
y it fails the second time, I don't know.
=C2=A0

If a similar thing happens with the kernel, it may be stopping at

serial console initialization.

The kern=
el doesn't use the EFI routines to initialize the serial console. But i=
f the kernel is being told the wrong console, then it could also be booting=
 just fine or almost fine and hitting some bug later.
=C2=A0

> Next most likely is that FreeBSD doesn't cope well with having bot=
h FDT and ACPI information available. But since not DTB is being passed in =
(per that message) that's not likely at play here.



I managed to load the dtb file and the boot process stopped at the

same point. The problem is not here?

Ye=
a, I don't think so.

Warner
=C2=A0

> Finally, the loader passes a large number of tables, etc to the kernel=
. It's quite possible that, for reasons still unknown, that data is wro=
ng or if standard conforming not expected by the kernel. this leads to a cr=
ash before we've setup the console in the kernel which looks a lot like=
 a hang.

>

> Warner

>

>

>>

>> > . . .

>> >

>> > Such also happens for stable/13, releng/13.* based installati=
ons

>> > as well --and likely others too.

>> >

>> > ACPI booting does not use Device Tree information but the mes=
sages

>> > are output anyway about the lack. Only if you know that the c=
ontext

>> > is a Device Tree style of boot are the messages actually repo=
rting

>> > a problem.

>> >

>> >

>> > =3D=3D=3D

>> > Mark Millard

>> > marklmi at yahoo.com

>> >

>>




--000000000000f39fbc05ef5511ed--

From nobody Fri Dec  9 00:25:10 2022
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 4NSsHS4s5Bz4jtXf
	for ; Fri,  9 Dec 2022 00:25:24 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434])
	(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 4NSsHS2wQ7z3xfM
	for ; Fri,  9 Dec 2022 00:25:24 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pf1-x434.google.com with SMTP id 65so2560068pfx.9
        for ; Thu, 08 Dec 2022 16:25:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=5FS/8vO4EvHe16L/caWWL+q+9XuyA6qr6/SXMlVejUo=;
        b=H2b+WSWZ5WRxZfpgKT8p/GJ42IJYAryHUQfZRQsK6iUEaPh4D19bGOGGOgFXXbY5bA
         yHMhaHSZcN9RZrXPlo4/DQPyQvdPdO+fh3Ix1LSey7KhBSGyWkNKNUv+D4zD7Vc9h90n
         VUYh46kiWFb/7F7UM8+aBfWQ9ohjzYtKgzO2ivsjWC7v2PKsbkk4pYlWzlnSgITaNjB9
         Siu043PQ/p+43H8EdwVuLXCMjTLWw8p64n+RJ6OaJVdJCbhgehtscYalejtVa1m65YJ7
         WoMJfekxlGuo6GbIzGqShHOS3CeysyrXTGflNy1YCqDGhm3iZf1WybJzFFevBCKcXFV8
         D/Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=5FS/8vO4EvHe16L/caWWL+q+9XuyA6qr6/SXMlVejUo=;
        b=SHv2VkFb3m6QzPoLEpOENIfdfu6QTSIY6TDOL+AbCWvaTpqKdKwroJ2I4vEnwf7asF
         KseBo4B69KA7BVVgDkAOUZ8lwPqlqBQQvoe1MY5Kp/5Ty/RrAL6i3fObBLEejr9mIPBi
         P9yluY6+Q5S65IHJJiaMYtnd7o2gEHo2Z0M2ONY7amEoNKhXZL6h4r5MaJr7VFvSki8F
         gDDMYk4jsMcN23LVNcyBYovEyNSesJzQykCGD0DTyU4u1dQ8gLfe/fOtjZOElhWoCH4Z
         r3NgyhPJxAz8jPwW62BVt2mXpQlj4W0+W0OjONLMaC0D9bKUs9wFQdWcNxOaraeQA4dQ
         wj1w==
X-Gm-Message-State: ANoB5pl4cwmA8cuMFh2v+ToL32VTH+1pikSaiPBnxNP4ZlSqaX7c+W5y
	KRBXUPOM62i/gQD3vLwsphrJ+sDZxDAPTIe9pqM=
X-Google-Smtp-Source: AA0mqf6+3O5xWelCIbR+UHwB4b37Xa/E1OkbjN05qQXG97iNRid0cIp4OeiTk1C4c/Vqs4u98ysQHJ+7w5yLoygS+Vo=
X-Received: by 2002:a63:f453:0:b0:478:d3a8:6ba5 with SMTP id
 p19-20020a63f453000000b00478d3a86ba5mr12672090pgk.619.1670545522461; Thu, 08
 Dec 2022 16:25:22 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Fri, 9 Dec 2022 09:25:10 +0900
Message-ID: 
Subject: Re: Succeeded to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4NSsHS2wQ7z3xfM
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[freebsd]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
>
>
>
> On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F)  wrote:
>>
>> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
>> >
>> >
>> >
>> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F)  wrote:
>>
>> >> OK, I (and the subject) was wrong. The loader boots, and show
>> >> following log at last:
>> >>
>> >> Loading kernel...
>> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
>> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439ea=
]
>> >> Loading configured modules...
>> >> can't find '/boot/entropy'
>> >> can't find '/etc/hostid'
>> >> No valid device tree blob found!
>> >> WARNING! Trying to fire up the kernel, but no device tree blob found!
>> >> EFI framebuffer information
>> >> addr, size        0x80400000, 0x7e9000
>> >> dimensions     1920 x 1080
>> >> stride             1920
>> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>> >>
>> >> and it stops here. No "<>" line is displayed.
>> >> So, it seems that the kernel is loaded but could not be started.
>> >
>> >
>> > There are several causes of this.
>> >
>> > Most likely is that the console is setup to go somewhere else. Though =
if you are on the video display and getting that framebuffer output, it won=
't not go there w/o some setting to override (say to force serial).
>>
>> In the loader, when comconsole->c_init() is called for the second
>> time, the function does not return. (I commented out comconsole to
>> make the loader work, but it is rather brutal and is not a proper
>> solution).
>> But the function parse_uefi_con_out() in stand/efi/loader/main.c
>> always returns RB_SERIAL, so the loader tries to use the serial
>> console.
>
>
> I wonder why that is. Is this -current or -stable? I have a rather large =
backlog of MFC-able loader changes. If it is with stable, then it makes sen=
se: I fixed a bug where parse_uefi_con_out would return serial if '8be4df61=
-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now we return V=
ideo console if we fine evidence there's a video console.

It is stable/13.
I tried 14-current, and the same change to loader was needed (merging
OpenBSD's start.S and ldscript.arm64, and commenting out comconsole).
Even with these change, the console defaults to serial, so I changed
parse_uefi_con_out() to always return 0.
Still, it stops at the same point. The kernel does not seem to boot.

Running efi-show from the loader prompt did not show
'8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
The variable name containing 'ConOut' were:

global NV,BS,RS ConOut =3D
VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-0482-=
27D14ED47D72)/Uart(115200,8,N,1)
global NV,BS,RS ConOutDev =3D
VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-0482-=
27D14ED47D72)/Uart(115200,8,N,1)

> Now, why it fails the second time, I don't know.
>
>>
>> If a similar thing happens with the kernel, it may be stopping at
>> serial console initialization.
>
>
> The kernel doesn't use the EFI routines to initialize the serial console.=
 But if the kernel is being told the wrong console, then it could also be b=
ooting just fine or almost fine and hitting some bug later.
>
>>
>> > Next most likely is that FreeBSD doesn't cope well with having both FD=
T and ACPI information available. But since not DTB is being passed in (per=
 that message) that's not likely at play here.
>>
>> I managed to load the dtb file and the boot process stopped at the
>> same point. The problem is not here?
>
>
> Yea, I don't think so.
>
> Warner
>
>>
>> > Finally, the loader passes a large number of tables, etc to the kernel=
. It's quite possible that, for reasons still unknown, that data is wrong o=
r if standard conforming not expected by the kernel. this leads to a crash =
before we've setup the console in the kernel which looks a lot like a hang.
>> >
>> > Warner
>> >
>> >
>> >>
>> >> > . . .
>> >> >
>> >> > Such also happens for stable/13, releng/13.* based installations
>> >> > as well --and likely others too.
>> >> >
>> >> > ACPI booting does not use Device Tree information but the messages
>> >> > are output anyway about the lack. Only if you know that the context
>> >> > is a Device Tree style of boot are the messages actually reporting
>> >> > a problem.
>> >> >
>> >> >
>> >> > =3D=3D=3D
>> >> > Mark Millard
>> >> > marklmi at yahoo.com
>> >> >
>> >>

From nobody Sun Dec 11 21:00:51 2022
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 4NVcc363FZz4kQSQ
	for ; Sun, 11 Dec 2022 21:00:51 +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 4NVcc33xXcz42Z9
	for ; Sun, 11 Dec 2022 21:00:51 +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=1670792451;
	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=RzyFveXLLHhNhNl/4uIPTDkoAmIfnTVgFiUuFlTqYQo=;
	b=Xw8DVEaCcygC2nXWdutq7P8wg369so03hUekgOjGN824+fsWUiQQasLI4zu6Q7NiUkXEy+
	prFtCgdc7MW9NOjOmR4qNd5BEZAsA8eYukJ1v/e9CufpmDdHYQ5/W3R0bZGZjZN/pUgjYP
	0+s++GholfTcAQVQ+BGeT9RNsy+rf0HBKUDYJyn3d9qDcAXp3Nuzu0INqQwVDuSomX3+ft
	Brl8fkmJLskNH0qFUypcjNPcKw0vT/Sn84HLiIKJeohqDBySB9PHRPmfL0w3syFQJr5WkX
	MgEfNzhPkHsEFAA7monrqS1Rrn5ysRjn3LM/KOv+AHOX++6AkFrRNp6VGlcFCw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670792451; a=rsa-sha256; cv=none;
	b=yu9oAEkNv+6C8FJiwvU8qJJxKPNUPxXtRb8S3XWaAe36tQkM1XifsnwmLBh7o8KIaBKrAD
	K0VarjO0zSS8EMgdYT6UbIYZw1GGL5NtI/U32OtNZMxk0UcGj+8F7YB12BhEFnf39ynqaF
	ksRhIwbw5He+2NpmjGVIv0UKPSTykolKXeM4weIhbggeKZZPrjY0GsdkBsPeirGbqKVy2G
	llgQsTYm5mxzYxGhKgdyMiseoO0N95aO/iyVbzHyFx7kR5ejogeGy/DbpcWEVyFNHpvvpb
	tqOjBEhb4VerkA8qeVaXN2BWlZqpkBY7cYsLNwFYWW1lOdi9VO00HaJnsGzxxQ==
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 4NVcc32tsYz18FM
	for ; Sun, 11 Dec 2022 21:00:51 +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 2BBL0pT7032841
	for ; Sun, 11 Dec 2022 21:00:51 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BBL0pqB032835
	for freebsd-arm@FreeBSD.org; Sun, 11 Dec 2022 21:00:51 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202212112100.2BBL0pqB032835@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, 11 Dec 2022 21:00:51 +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="16707924511.B7eEcA767.27513"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16707924511.B7eEcA767.27513
Date: Sun, 11 Dec 2022 21:00:51 +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.

--16707924511.B7eEcA767.27513
Date: Sun, 11 Dec 2022 21:00:51 +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.


--16707924511.B7eEcA767.27513--

From nobody Mon Dec 12 06:58:41 2022
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 4NVstC6X7zz4k5kY
	for ; Mon, 12 Dec 2022 06:58:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4NVstB43BPz3NL0
	for ; Mon, 12 Dec 2022 06:58:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=nkIabM+7;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 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=1670828336; bh=xhQgxu57C9iBn9Lajd/5H3MotiUP/SnUa4gNmLWzCgs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nkIabM+7LY9wZvi+1ApYaaYNFaEB+FrsdVnr9emvNdr4qm/phD6hWIBtwgagK3zHfRGFBI3qj3l7PISnkTt20aoIFGdQWdvlYZVDRTE+aHP+u4/XrP8rbqZVtzr6EVO9e3MMZB+kTtArLR6zzsVfZlFCO7ve2fzkEHqfSAxVVGVS4bjglrM+UqkaD5EXRr51dARrGhI0leJ5NJCE8mFBuZwTIZIJdfnJhKGux8uGaepcBZj3tXGIPOmzJXToyLQ/quEvnJLyehdfpRzzaKMT8UbcmKFcUXUudWqGe8lxoqRYQcVQJo0YL7BODychYwHItRBAqmQ2pmyVIWHKM3gSGA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670828336; bh=Ncfy2IUxIhE0p1og9qf4nVo3eLfIeyaowNEc9AGDvSV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KBxrAnMM2i+nARhHNeiruFQXslG/bVwHLnnvT8amXvg6fACLblUtcnVXQKc+4CPmEQPB/PCfZk1g1LOBO5K8g+1jL2i4IrA03A3UJ/D38gztMyaVHuDrJgXkKHOKCITDZJIsUSyEokrQfyowpAu3DTiql2s9LhbXO8xaALdLdIamhTheQON8oBE8/YALZAhv/ru1fIUqo3xXlXuLwkadR8/hqpIn3wjExBnrFSv3aTYxLWIOLzFKzgonzAOocbLKZIfeslQc9KyZ4NQQnwrjzvEs196tDZUN5ko2Oh9Za0n/guTAN7x/7WczdOryL2iMQmRjJPvEhrcW3byqR3SxdQ==
X-YMail-OSG: vN2oSs8VM1n0eb1r.mNBD5vio1SQUZ7pB2R5d7IgvBMpyvPREqx3TAQouUU4LbU
 3Z2uOuHTc3FVMOSjJPKEFl9WtmkI7ICr0qQwR5f9mCecAPZxUqZWttykuG0jjFm3GEPQUTKkRaqa
 nFzHTUjvOlWWrdN0t9Pt2.HotiyBXsdlAocEA8iihPgxOxzqWMWri0NmqYzKjcY9X3JgVSjSSSdV
 hn7LYmcbAtOzQp0fyQV5NGcyrSb6wW8wThmUmXosRa10oNPQFl6RQqr9wLJZAj43XmSrcnn06FC7
 ocug6JrSDPvA0ztIvLKwSFYZJNhN8NRt8F8JZMCwRzz3xUJNT6Qs7y1N96uW61VpADwMW7KSEDYf
 _4QUD9gfWWCdPwdec90IAdI6rdlDZkVnQWA3q7mPWEPmhJyIow0yveT7aYPSaJ_2vWKrkaIXLIea
 JgFGMDUasvFX80At8pkM8T3tw9UdDVZv.eJeMfiY81RNU.kHgXA88ZjJEF7MJIQQGEEzdAMV1q9C
 7AGjtcCrZhimC1NIJkhSY103k57KJfEun2lGA2wAE8I_ybByktn4RzgFkAcsoAZxNs4vxPtFKCwQ
 lIHmO3q.kkiWpGtA3VQnhEfaeNgMdq1L.k1Im88ihz7YFUtsGbYfHyWJvDMXRA1NbYE9YE6e4AJP
 7r6TX3iR76asQzIqqU5QdO0d0pdbeqy_dhT_mmbmwXf4euP7sNV55z88SRhwJo4oZLft0kCQqDnL
 nvYW.Ywh8qVsGV1U2DZkmK8V1DOCBPSFVaR1mnuh_zJRMa9LcTdF1gmrfvVxaQeEJruXUwQSh6LK
 wGCx1gawR2krJT_ijGtK3txiyC2_JkpGmz3UA2UsBSUCM.5d0iLZm0SNCdaIkOPfc7Dgl9AI3YUv
 gjDpOkLzrOJVcNUljBHqs_OosvtYla8lhydqf9LTleK4uIz9dGi1EDYHAiJkjKH3efRMH_prUB3n
 WHn_5q1KeyW3Xt7rYm68bEU54fl1wmjtyUT955OXDMVW3IzKuRbQ2ie1stqYhea4i_EMFcPNCKLY
 CTxkusQ2N5dUOY9CSyUBxWA7enXjHavb2.zg5VXMcifzTNSkCz7YyCYBjJP1sF_jg_O71YQW6Iqj
 JnBfaycam4w5EiD9HQ_qusqhi6A.lya7lgvdoODqbY54aTK2MJUPR.R4BMg5QYf_mrczPuJfNtm2
 08LxjTo2Zu4CiYu1A7t8g6z4LJgFTg0IoHJJlpcQGtU3thMeouMCqJh8iRzI79krbT3yX88Odj1g
 W.1VfPwalPRKwMRIUDjRtUqR.tVrK9XrkG1jGoGc5ObWakYu84opVgHWYzJB5Xt6o5OPNfHEt7Z9
 aykwXOlL7PDc41UEVtia.tARXW7WB7XJnRJdnXnu.8u5VmdcXrsm21ngRnxVYVspBeRspB.TfhN2
 8slf0uAglAfB9WLxGOoFGknBxfBhGc_X.oESxQ4hSOqF92WPArW0bHZKiBKQ9VhIR4S35aYbP.06
 RjnQJePqRrx8U0d3B2rz3usrS7Inof054BAIzCafsNz0UNwkqokrsIbpUAAKNTJrcV6Z7BufGgTM
 W6au3mce0itjzH9lpQ.QAm.4P4bGSplnOGVJ0WF7k4FbJpoVQZBdhSN2_kR6USUtd8lBGcjFTtkQ
 q0cScDl5qMCkTZqnYHmZHuC7Dh.5RWs8I2FXKMeyPDkvv9Zs3grSkAwGrgG3N3BZoC0EPyl7CnlM
 SqFOonxNbMPL4ECOo6v8vIRA1aHph0s6aaFwc7djlbAeLjNTshmErKqrIwJ6lDQAwbAZrqe8aX8K
 GkvDmo6epZToqte4hHYvHFoPQynuEtbi..iSMTr7UoHjpfVdWUU.vYQJcvHsG63bB.ILvC4_HUAe
 3pA7Yn1ukVsqZ5WlLVVsHfzAADGAiXM1JG0A06.hmJSJmuT9Zgo4c7UbcpVlmKkwzGoqFZcLmamZ
 v7WZvSsOpNGJSKb.F0vCjaayXzMkDuHlwNE1g8b0o7BCK5VjszWL2YY81qN925sRQNtnUNo10dEo
 rVDKcAmnGqrF2rZ.Z00Z7k2Z40i1N6Sheflo06pMd9X2yyKwp3ZzkvKSVh6XFmWBB0fMICdintn_
 9jOfMgLCW9U4j7clSHFMrUcLoqGaob2vefo1bIyG87AAtFY6SsuKHen6kpACBVsjVi63nBkwyqjI
 ZkosgnG5JdXZmbmfKnQlYKtFR5ihhDMEiwe0bHYnA6WoDUCLpjDLxcnijQtqzeVMyb1NL.QaQOen
 QoHp7BFHVkXAbsDr9.AmqIfWn7CT__wvuxy0l.gJr9JfbeS4fCib8ycjFTsWEcmJWiJE5GHGj5g-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Dec 2022 06:58:56 +0000
Received: by hermes--production-gq1-d898c4779-nnvpg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID abd28a8f8a5cac9f9c91860a825f70b8;
          Mon, 12 Dec 2022 06:58:52 +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.200.110.1.12\))
Subject: dpaa2_mc_acpi.o build failure with ACPI_DEBUG option? (sources are
 back as of 2022-11-06, unfortunately)
Message-Id: <56937725-3C96-43C0-812B-4676FD3EF26E@yahoo.com>
Date: Sun, 11 Dec 2022 22:58:41 -0800
To: freebsd-arm ,
 freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <56937725-3C96-43C0-812B-4676FD3EF26E.ref@yahoo.com>
X-Spamd-Result: default: False [-3.34 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.84)[-0.840];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NVstB43BPz3NL0
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--- dpaa2_mc_acpi.o ---
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: implicit =
declaration of function 'AcpiUtTrace' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
        ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
        ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:5: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
    ^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of =
undeclared identifier '_AcpiModuleName'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
                 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:39: note: =
expanded from macro 'ACPI_DEBUG_PARAMETERS'
    __LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
                                      ^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of =
undeclared identifier '_COMPONENT'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
                 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:56: note: =
expanded from macro 'ACPI_DEBUG_PARAMETERS'
    __LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
                                                       ^

But this is for source that is somewhat over a month old:

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor =
changes due to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +0000
n259064 (--first-parent --count for merge-base)


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Dec 12 20:39:43 2022
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 4NWD564y7Vz4Y5Mh
	for ; Mon, 12 Dec 2022 20:39:38 +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 4NWD552NgPz4FDS
	for ; Mon, 12 Dec 2022 20:39:37 +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.16.1/8.15.2) with ESMTPS id 2BCKdhag064514
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 12 Dec 2022 12:39:44 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2BCKdhb0064513;
	Mon, 12 Dec 2022 12:39:43 -0800 (PST)
	(envelope-from fbsd)
Date: Mon, 12 Dec 2022 12:39:43 -0800
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: /usr/src/Makefile.inc1 typo?
Message-ID: <20221212203943.GA64277@www.zefox.net>
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.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NWD552NgPz4FDS
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

It looks like there might be a typo (or nomenclature change)
in armv7.

Last attempt at installkernel stopped with 
make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7
but when I again tried to run buildworld it stopped with 

root@www:/usr/src # more *.log
--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7.

make[1]: stopped in /usr/src
.ERROR_TARGET=''
.ERROR_META_FILE=''
.MAKE.LEVEL='1'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/armv7.armv7'
.TARGETS='buildworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='armv7'
MACHINE_ARCH='armv7'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20220726'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/armv7.armv7'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/src.tools.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.endian.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk'
.PATH='. /usr/src'

make: stopped in /usr/src

Without understanding much of what I'm seeing, it looks as if
a colon (:) was seen when a period (.) was expected. 

This is on a Pi2 running 
FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #26 main-52f2b03877: Sun Dec  4 21:25:04 PST 2022     bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm

The system uses a usb-sata bridge to a mechanical hard disk for /.
 

Thanks for reading, any suggestions appreciated!

bob prohaska


From nobody Mon Dec 12 21:20:57 2022
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 4NWF0z5yTmz4jZKV
	for ; Mon, 12 Dec 2022 21:21:07 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20])
	(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 ECDSA (P-384) client-digest SHA384)
	(Client CN "mail.bsd4all.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NWF0y057gz4Llh
	for ; Mon, 12 Dec 2022 21:21:06 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gojira.at header.s=mail202005 header.b=2my6xhy+;
	spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at;
	dmarc=none
Date: Mon, 12 Dec 2022 22:20:57 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at;
	s=mail202005; t=1670880058;
	bh=vBWeZOPFW+jeSEk23PWbT3+HrpneT4DYYt6whtDyziM=;
	h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type;
	b=2my6xhy+quq9fXGSxQ4CNPlmV37Sqt8oHf8DpxXYvbzrRZJCqPyhMKiGRfhi1fj/U
	 nS51HBBDCX1JH720x33OW2SSM29NVtXyprdM1pTsY4DYm0iCzVzfZLwTXCoFlEKDC4
	 aOzMEzI+xFfhKgfjaWOq63E7+70QsDD5xouwHHyfRHFG81mGS9CvRMvJ3E31U7mbJZ
	 S3N0aApqdRnlpg95VKWeookQj3rpXiyHxRj6AeDjiKOzKiFrLa/maKNrcvwADgHd/W
	 88TthKndNpkGjY2MxByzvjyq9noUZKZHZgxnwpofW3M2HZdx/vKyFI0+0qftSzITnV
	 NS5lRYsUK8u4g==
Message-ID: <87zgbstj2e.wl-herbert@gojira.at>
From: "Herbert J. Skuhra" 
To: freebsd-arm@freebsd.org
Subject: Re: /usr/src/Makefile.inc1 typo?
In-Reply-To: <20221212203943.GA64277@www.zefox.net>
References: <20221212203943.GA64277@www.zefox.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.0 Mule/6.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 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Spamd-Result: default: False [-1.43 / 15.00];
	MID_CONTAINS_FROM(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.93)[-0.934];
	R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20];
	R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gojira.at:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[gojira.at];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]
X-Rspamd-Queue-Id: 4NWF0y057gz4Llh
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 12 Dec 2022 21:39:43 +0100, bob prohaska wrote:
> 
> It looks like there might be a typo (or nomenclature change)
> in armv7.
> 
> Last attempt at installkernel stopped with 
> make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7
> but when I again tried to run buildworld it stopped with 
> 
> root@www:/usr/src # more *.log
> --- buildworld ---
> make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7.
> 
> make[1]: stopped in /usr/src
> .ERROR_TARGET=''
> .ERROR_META_FILE=''
> .MAKE.LEVEL='1'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='.PHONY'
> .CURDIR='/usr/src'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/armv7.armv7'
> .TARGETS='buildworld'
> DESTDIR=''
> LD_LIBRARY_PATH=''
> MACHINE='armv7'
> MACHINE_ARCH='armv7'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20220726'
> PATH='/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src/armv7.armv7'
> .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/src.tools.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.endian.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk'
> .PATH='. /usr/src'
> 
> make: stopped in /usr/src

This is caused by

https://cgit.freebsd.org/src/commit/?id=83bf6ab568293e325f437342cdb87a626353e27c

Already reverted in:

https://cgit.freebsd.org/src/commit/?id=85dd853236149dd029d5c065efce0e802f9c1e9a

--
Herbert

From nobody Mon Dec 12 21:21:33 2022
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 4NWF1p1km1z4jZdv
	for ; Mon, 12 Dec 2022 21:21:50 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.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 4NWF1n6Ml3z4MsB
	for ; Mon, 12 Dec 2022 21:21: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=1670880107; bh=N/HKA4o5LO4lnWcvHw2FCm5dXYD11kr6hVPzs7XjJic=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T/2qsQ8Mw67PxS+du0JF2ZPFcW/EHrY0hp2VIMlfcFAlI6nhKvkmehXsbqTf1QXmH3SQhrTggFURjilW3HivHe2LsCE5yKWDnH3XAzpmq9wdAUpK3ylORGYsHAN7XWZfaipon3FxKuIyZWRZQNt+9Hm4V6F3lI4lh9jusVOwd/w6iofvVoLN4rXpYK96xtZK7VpTFD2e7XizMhv+QSJgKSmFgPPLMke+Q7iALgkCsxYnMyNcVMch7NnOySG4vaduCMIRvVwK+9UTms5ozvtVEwjUkzfT1R8wWVlIEC2wk+n/3Eo4P4z5xNVe+++ZzgHOzz64DiIySUxTGhaeymI1tA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670880107; bh=CvmVZVuOKK0xtfccY2DqnF9gD72P+Vk8CGGhDwETIRk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TJDFw3EXo3HwyIcgHgsI05ECBprUKG27fV2FhvJ8BgticDdsPHVTzY2GQbQomup5l2sWBk8qfIIBwkWqic1T3sQ0ltOdbITnLWKx89YZ3vUbA5wlIvJFOOY36iMeBIidiO+IgSQ9BmHWvmW8xcD1ZgC0M0Q//ALJ0TRhFeTQBWLxSj7C60WaHgKkorWPhQ8HqvIl6+u7ynnISL979HRWfco/YrhXc6792T8f8j2T8VmHwjbLgLphs3Bhrag3xnYNS8tzk1J8hcUj31niEQDsS5P8LBhI+Edl+8pOhS/EBxhrXJygAafe495/BGNFGRrIquCWQ0bmHq9Ka0ecpfD9QQ==
X-YMail-OSG: JgvjxVwVM1mYcZOBeA2Mpi_1z5OAxpRJZ8euPIqwueizGkucSxxcQcFO5jhK..z
 o2n0KppMsa8ZGeEO7UYhfgxar1C9ab.2ti8Bo9ziUKlf.55Q6601RXNF4ejGGXpcv70KHcicF.Km
 IBW7EKWa3dXr8YT.EC4JdmfKj_U3oJjQQ2aWdSFQOe7GtK0u_1X9OXPkXB2Sgmxi4PLnAC0ZXjh_
 I.biqsnbUj2aQc261yEwmNC2e3txk95FEuulQME7cAIVdpwCOb7lNRtVxwnzzFBzkg.YO54pOZaA
 V87efxJgNcdaakfz3a8zHLV7KCyp8tqwGwFcSEayZ2UzZTLlJ9zfCPt5YP2MqsdXK3hy5DyFX9Hw
 EQ6AUwNN8jFxLLI5gtIP7wfNjBqpiU90dwY2Om.3IjLQy8f_jR.7trMmDOpC0EA2HhHnR.5mWf1M
 BrDS.CA8cPUZTpp0T.dlsX3u_BbVfodpchrqa9xsro9_RqiWGMM0hY_GQ_u_eu6OBBExeORfakmb
 M7wtKA9VJmPgH0P_oeHW16BqblghoRkJf9NfLF78Phvc_G9pW5Q9a_KKPawAEMxk2iHS8uiyEtB0
 IbCTP2_JDUiQzX99aqtbgAZGo5lXaoFRRoppKSYriOlNu5E9BXt9weJQfZARTWgmchEn6cZMlrNg
 2z7c5EfyFhz34jq6zAhwYoSAKcLK8iRvwUkVepxz.wjJMpbXQCOx4m7ardEdcQBTiIV.B4OGtjOC
 jkorQ2yXU.rwkk.J9z4Qm2.lkrgVLhj9AV_4GQsPII67hb6DYDYZi3PHYXMzHIpUC4A_AwMkyB.E
 jiUlFmu_iPZGJBm8ATtuIHu1LyQjp303Gg3vNtnoIM5G9jSRUTNorCFz5f3Bj.U_24QeYhF7.p1O
 rQZZugduT9dBvOOIrQNhehLjLi98HHrwAsktwuH3V4AxoG6nfHrAcqxo51HlxRKMXjqlV95Y99VN
 spayKFeRxuiVGFdWRQJgkyrueX1p34nuBSezpJ.tJ8dnRqYM9KqTmTWChvCTKuofM_k49UN1iW.A
 5eC93CC_labPot7PES1C0h__AzyQ8Zv5VJld5.GYlgyBKpfUwpC8cG8cF1PzF.KcNHLlFDCqJTFX
 lZsRUXHpTVG0LfBQZ9jHE6olOeTuYmab.mkmp5teja0QMmdcKq_G0BX3d8JpluifUMhFlW5OIp_h
 7OuYbEI.8FO3zcTb6GFarYjSP.T0I.TDtM2ZmuwRYJ_YSOOC5w.52XAiwH155fMRShHB6pZx2.4r
 Ax2_YEskhxM6Jo25WNJAz6SsMszkdIXwShega5HmYeCMIRCKTwEdVNifhiuiRP2S8cNOVI1RGMw5
 1eZAWH0vH8iZpxXySBTr4aprn3EemYdPgwUIDL5SgzuvpRni2qmQO5KEYMoiB1sA4CrJZLFO7nGI
 eTJgDxqiJ8b6EX0oOTdUBCYMVPXu0mnV9dkt5E.FCJmnhFgDkAhlHFT53n69T8lPSXAIDNJX21kh
 OLBHXcm.1.NbFfmsMNPiu8qW.wDZ99tlm1t3TYRR5bwikyO4yllh.yIhPD74Pn8akI2C.xRo4lmp
 jI.r5djW40KZXSDZNbaOerqo.NCugBYYoEiJ1bNbrIsax9nyZ5lobmJtLSbRTaX7mSxnTL4EO5I1
 8V6QsL8nl0cOsjX7N0on7AUJdrUv3ojHArAUWQhPFoeTSzqWN.qO6W.NX0rrDRA_TadW6LZ0_vnm
 fT0H3rsvTXMIxJqndWosdEJPe0GqZiNQRxsbcVR9o583LzmSsRX2m2zPZ.CsrxiteXIKWmkgQjVT
 3YPbld6IvJMNS8mP37W8VzGkJB_T23rTb27APuQxAtSNXHKnp1._MZbyu_tMzJT.QubHhtZaTiql
 sKykhqgid39JF0Soa0gYVDuAD5OEHFkRgzAjptIYNtSexSFhgmQsRwW5f2sQpOU.WAvhiyjyyByb
 en8GweLlOGlad.d.DHHPCr.R4vAk_9nxR4gzjTeZeKv5sNvWCwnkpbVwIQwo_oXKkCqHXTz03.P4
 VZmVu1xsAV63j2kFbAB1v6vvC2TT51P5U7G6WMVLp8iwh4Qb3tM5MZR4IrFgBbW0r3w7KwaBEgLf
 RyNl_WbLOwBls8I6z393zaxttRZNXQdw62QBbI3DnqryfIhFvJ0ClbSMh1ptSMAT.5vygDYa5E2M
 KxQkjk3W3BsMWLL8yakkoGHIuNfbpcKoW9fjeBxkBImSLm9DPLMareXnVXut0HYVqa9uhFEnrwE1
 HQap34qrE.tQYMxO3Tnvg2ADB3.jLXUp7WY6yqwqDBPagOVmZf1r0Vw9fq9z8_NyJJZKpxyWVOIA
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Dec 2022 21:21:47 +0000
Received: by hermes--production-bf1-5458f64d4-tg4jl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fe226157fb241321fdd7f60c50c08a7e;
          Mon, 12 Dec 2022 21:21:45 +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.200.110.1.12\))
Subject: Re: /usr/src/Makefile.inc1 typo?
From: Mark Millard 
In-Reply-To: <20221212203943.GA64277@www.zefox.net>
Date: Mon, 12 Dec 2022 13:21:33 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E46C762-1409-4977-977A-37D01EB65784@yahoo.com>
References: <20221212203943.GA64277@www.zefox.net>
To: bob prohaska 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4NWF1n6Ml3z4MsB
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 12, 2022, at 12:39, bob prohaska  wrote:

> It looks like there might be a typo (or nomenclature change)
> in armv7.
>=20
> Last attempt at installkernel stopped with=20
> make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7
> . . .

You suffer from bad timing relative to main's [so: 14's]:

Sun, 11 Dec 2022
   . . .
    =E2=80=A2 git: 83bf6ab56829 - main - uname: switch machine to =
HW_MACHINE_ARCH Piotr Kubaj=20
. . .
Mon, 12 Dec 2022
   . . .
    =E2=80=A2 git: 85dd85323614 - main - Revert "uname: switch machine =
to HW_MACHINE_ARCH" Piotr Kubaj=20
    =E2=80=A2 Re: git: 83bf6ab56829 - main - uname: switch machine to =
HW_MACHINE_ARCH Piotr Kubaj
. . .

Having a system built from a source tree from between the 2
commits one ends up with a broken default native build
environment with complaints about "target NAME:NAME" when the
correct naming for the context has 2 distinct names, such as
arm and armv7 in your context. (That need not be the only
complaint.)

It may be that explicitly listing TARGET=3Darm TARGET_ARCH=3Darmv7
on either the make command line(s) or in the environment(s)
might allow a valid build from the messed up context. (But
such is untested.) I've no clue if a full rebuild-from-scratch
might be needed. If it works, you would likely need to be
explicit, even for installkernel and installworld, not just
for building.

The build(s) should be based on source that does not contain
the 83bf6ab56829 change.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 13 00:40:11 2022
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 4NWKQw4QtLz4kFd8
	for ; Tue, 13 Dec 2022 00:40:24 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629])
	(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 4NWKQw1lh0z3PYB
	for ; Tue, 13 Dec 2022 00:40:24 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x629.google.com with SMTP id vv4so32732915ejc.2
        for ; Mon, 12 Dec 2022 16:40:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=HkL88LDjMfIX1SzOWsSO4MCVTNeY6hZkZWKuDso0hgA=;
        b=OEC8MsohIAQBoXgkhQ5VdBfEpHcl2Uzahw9VSvPcMFs8UzUoa1Uxo+3JGxP9kic1RR
         tb82ZC10IzYNeLStpWUjJvoyui4bwnbr9UkgxbKcWqZQm/X5cbeVmuWOCX0qY7YH2Cd3
         TsfDUF0Ear1rvahE+rpfpZgaFQdwzxZKGONyJ7LHpCOO248r1+BOR8ciW10pSkfE8fJs
         6DeqScQoh5dSSD4Aq1fQYpYnFG2P9o/0Sj8G/bHnQ/GPBGkbjO3iWoNy1l53vGp0dpor
         +u6NjlMzKbPsgOW45cJleRVfsA678b0Tkca0+9RsqkvwtKoHaW2sOSgj45Pdjyg+/OTT
         Tu5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=HkL88LDjMfIX1SzOWsSO4MCVTNeY6hZkZWKuDso0hgA=;
        b=usGF4OpJzz+ofxy7mr95HjN3odKZqTl1Lcem1cOG+Lz17OshZwCj7QPFZz397klISU
         zLHGmL6mMEINMp4cATXGkrjRWKTyk8ltpFuakqqnGeMr4Dr2cTwZeL9477bujTpL6pf9
         jh1+wmRVhwABb+dxkOT2UEi6gv15qJVaj9mZuaN62SqRkUqCQTWakats2OCSrFDdj6+d
         hjZmB878/1YZKVMiiqIb4wS4hZXtamNODHYu1qvjnsr8G4Vv0hnyf4qU351a1haHPCZ2
         dMdPlNhZ+pGL6fyYZKu29rQeHtKAduFY7AAU7XTXr09s3QpST+QDFyta72K8hJ12O6k8
         jL5Q==
X-Gm-Message-State: ANoB5pmPrR444y/84bAYVEFPQQT5XsTZxA5/tylfcA63J4TAdvg20KYD
	zcyoFCil/RcplzodPatWnnXMuIU5aBb3LoHb9JzxZbwIwFJZOw==
X-Google-Smtp-Source: AA0mqf4pmsI0fMstPN4h16fEmKEhD28vPfgWdVYrnVU3pLSQRP8SMrQLSrSzFRZxJ1CMw/6N3LKe1FNQavyrZW1TzFc=
X-Received: by 2002:a17:907:98ed:b0:7c0:e7a6:cd2d with SMTP id
 ke13-20020a17090798ed00b007c0e7a6cd2dmr15837884ejc.317.1670892022738; Mon, 12
 Dec 2022 16:40:22 -0800 (PST)
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: <20221212203943.GA64277@www.zefox.net> <6E46C762-1409-4977-977A-37D01EB65784@yahoo.com>
In-Reply-To: <6E46C762-1409-4977-977A-37D01EB65784@yahoo.com>
From: Warner Losh 
Date: Mon, 12 Dec 2022 17:40:11 -0700
Message-ID: 
Subject: Re: /usr/src/Makefile.inc1 typo?
To: Mark Millard 
Cc: bob prohaska , "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000079501a05efaadd8d"
X-Rspamd-Queue-Id: 4NWKQw1lh0z3PYB
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000079501a05efaadd8d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 12, 2022, 2:21 PM Mark Millard  wrote:

> On Dec 12, 2022, at 12:39, bob prohaska  wrote:
>
> > It looks like there might be a typo (or nomenclature change)
> > in armv7.
> >
> > Last attempt at installkernel stopped with
> > make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7
> > . . .
>
> You suffer from bad timing relative to main's [so: 14's]:
>
> Sun, 11 Dec 2022
>    . . .
>     =E2=80=A2 git: 83bf6ab56829 - main - uname: switch machine to HW_MACH=
INE_ARCH
> Piotr Kubaj
> . . .
> Mon, 12 Dec 2022
>    . . .
>     =E2=80=A2 git: 85dd85323614 - main - Revert "uname: switch machine to
> HW_MACHINE_ARCH" Piotr Kubaj
>     =E2=80=A2 Re: git: 83bf6ab56829 - main - uname: switch machine to
> HW_MACHINE_ARCH Piotr Kubaj
> . . .
>
> Having a system built from a source tree from between the 2
> commits one ends up with a broken default native build
> environment with complaints about "target NAME:NAME" when the
> correct naming for the context has 2 distinct names, such as
> arm and armv7 in your context. (That need not be the only
> complaint.)
>
> It may be that explicitly listing TARGET=3Darm TARGET_ARCH=3Darmv7
> on either the make command line(s) or in the environment(s)
> might allow a valid build from the messed up context. (But
> such is untested.) I've no clue if a full rebuild-from-scratch
> might be needed. If it works, you would likely need to be
> explicit, even for installkernel and installworld, not just
> for building.
>

Libc is all that's needed. Use "make MACHINE=3Darm" though maybe it's a
general workaround.

Warner

The build(s) should be based on source that does not contain
> the 83bf6ab56829 change.
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>
>

--00000000000079501a05efaadd8d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 12, 2022, 2:21 PM Mark Millard <marklmi@yahoo.com> wrote:
On Dec 12, 2022, at 12:39, bob prohaska <fbs=
d@www.zefox.net> wrote:



> It looks like there might be a typo (or nomenclature change)

> in armv7.

> 

> Last attempt at installkernel stopped with 

> make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target a=
rmv7:armv7

> . . .



You suffer from bad timing relative to main's [so: 14's]:



Sun, 11 Dec 2022

=C2=A0 =C2=A0. . .

=C2=A0 =C2=A0 =E2=80=A2 git: 83bf6ab56829 - main - uname: switch machine to=
 HW_MACHINE_ARCH Piotr Kubaj 

. . .

Mon, 12 Dec 2022

=C2=A0 =C2=A0. . .

=C2=A0 =C2=A0 =E2=80=A2 git: 85dd85323614 - main - Revert "uname: swit=
ch machine to HW_MACHINE_ARCH" Piotr Kubaj 

=C2=A0 =C2=A0 =E2=80=A2 Re: git: 83bf6ab56829 - main - uname: switch machin=
e to HW_MACHINE_ARCH Piotr Kubaj

. . .



Having a system built from a source tree from between the 2

commits one ends up with a broken default native build

environment with complaints about "target NAME:NAME" when the

correct naming for the context has 2 distinct names, such as

arm and armv7 in your context. (That need not be the only

complaint.)



It may be that explicitly listing TARGET=3Darm TARGET_ARCH=3Darmv7

on either the make command line(s) or in the environment(s)

might allow a valid build from the messed up context. (But

such is untested.) I've no clue if a full rebuild-from-scratch

might be needed. If it works, you would likely need to be

explicit, even for installkernel and installworld, not just

for building.

Libc is all that's needed. Use "make MACHINE=3Darm&qu=
ot; though maybe it's a general workaround.

=

Warner


The build(s) should be based on source that does not contain

the 83bf6ab56829 change.



=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--00000000000079501a05efaadd8d--

From nobody Tue Dec 13 01:31:45 2022
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 4NWLYz3xmNz4kMQJ
	for ; Tue, 13 Dec 2022 01:31:35 +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 4NWLYy4Dq5z3kRJ
	for ; Tue, 13 Dec 2022 01:31:34 +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.16.1/8.15.2) with ESMTPS id 2BD1Vktv066705
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 12 Dec 2022 17:31:46 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2BD1VjV3066704;
	Mon, 12 Dec 2022 17:31:45 -0800 (PST)
	(envelope-from fbsd)
Date: Mon, 12 Dec 2022 17:31:45 -0800
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Re: /usr/src/Makefile.inc1 typo?
Message-ID: <20221213013145.GA66502@www.zefox.net>
References: <20221212203943.GA64277@www.zefox.net>
 <6E46C762-1409-4977-977A-37D01EB65784@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-Spamd-Result: default: False [-0.06 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.96)[-0.960];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NWLYy4Dq5z3kRJ
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Dec 12, 2022 at 05:40:11PM -0700, Warner Losh wrote:
> On Mon, Dec 12, 2022, 2:21 PM Mark Millard  wrote:
> 
> > On Dec 12, 2022, at 12:39, bob prohaska  wrote:
> >
> > > It looks like there might be a typo (or nomenclature change)
> > > in armv7.
> > >
> > > Last attempt at installkernel stopped with
> > > make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target armv7:armv7
> > > . . .
> >
> > You suffer from bad timing relative to main's [so: 14's]:

8-)

> >
> > Sun, 11 Dec 2022
> >    . . .
> >     ??? git: 83bf6ab56829 - main - uname: switch machine to HW_MACHINE_ARCH
> > Piotr Kubaj
> > . . .
> > Mon, 12 Dec 2022
> >    . . .
> >     ??? git: 85dd85323614 - main - Revert "uname: switch machine to
> > HW_MACHINE_ARCH" Piotr Kubaj
> >     ??? Re: git: 83bf6ab56829 - main - uname: switch machine to
> > HW_MACHINE_ARCH Piotr Kubaj
> > . . .
> >
> > Having a system built from a source tree from between the 2
> > commits one ends up with a broken default native build
> > environment with complaints about "target NAME:NAME" when the
> > correct naming for the context has 2 distinct names, such as
> > arm and armv7 in your context. (That need not be the only
> > complaint.)
> >
> > It may be that explicitly listing TARGET=arm TARGET_ARCH=armv7
> > on either the make command line(s) or in the environment(s)
> > might allow a valid build from the messed up context. (But
> > such is untested.) I've no clue if a full rebuild-from-scratch
> > might be needed. If it works, you would likely need to be
> > explicit, even for installkernel and installworld, not just
> > for building.
> >

Adding TARGET=arm TARGET_ARCH=armv7 to the build command line didn't
help. Removing /usr/obj/usr/ didn't help either. 

> Libc is all that's needed. Use "make MACHINE=arm" though maybe it's a
> general workaround.
> 

Maybe I overdid with rm /usr/obj/ but adding MACHINE=arm
to the make command seems to have got buildworld unstuck. It'll
take a couple of days to find out for sure 8-)

Many thanks to all who replied!

bob prohaska


From nobody Tue Dec 13 01:36:42 2022
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 4NWLh75Sqyz4kN45
	for ; Tue, 13 Dec 2022 01:36:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4NWLh74ZYMz3l0D
	for ; Tue, 13 Dec 2022 01:36:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62f.google.com with SMTP id x22so32948528ejs.11
        for ; Mon, 12 Dec 2022 17:36:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=let/Mrk96xpKxsjMRjBYrGQXsBx7e+Kz7fiibjKeKyk=;
        b=7yh8WnkHxT4MXKYhZTKN6583zeg2pG/VFuFjGJqbW7UpuIf5JBQZ3TP6BbQ9Nk1hLt
         MjrLKgpa5VmJgL675q7GLqRmlXcpH1hP/Hj75It/4gQkFHgOiU8w443PpVYLHo79T8BU
         WRwC60VggOyS8x7gPZlYSyiknBZpFhm/tDqoGA3N0nUpa2iQ8UzllbGWCZvfa2C8xq2g
         M9J4Y8OqgkTYp1P9+h1k+bRI7TexlwE/+2X/2yPGkXAIsGIFo8qsY40AL9iHawT9dZgX
         s469IpKOgecN9Vx8NkKRMEe0VeJCxap2YVfHAcgwR7NKvoY2fLBYuDpFfqvZGzouu0d0
         +FAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=let/Mrk96xpKxsjMRjBYrGQXsBx7e+Kz7fiibjKeKyk=;
        b=Lyxb3vdWJ8eN95j7JI+McVeYoh+GuRPBFd8gYHFW80TkUwpm44dK+IFWBljBLksgNl
         RFs1AiNe2o5tv5rARhDi7iIDKmYR8cp3rMOKXAixmhm1a+w2cP2K96huCODtTB/BQaSM
         pIg0UVZby4UQVjnmjz0SZQKCOYtO2LYIoi21o6CkUBKx1tJt5mwQ5baY5dxujio+3d1a
         EThCwvVnDiuWHmbAuC8xQENOCqn7c5vGC/xQyArDT+TSuh5ZCGsF7uH1Ezk5wSeAYnrs
         pSjMwEizy0LM72r2049HqRAF0Ib4/qLQniWNYDB6gbT6zuZdf/GTE4x8iBgFnK5d9tlg
         3vsA==
X-Gm-Message-State: ANoB5pn596QVwTLJo64YkitWXSkiCvNnQGxgBO21rJKgHb0pmVbNFezO
	hBuveXtIxu504TP9lHezo5oH8Ji1hTFYO359aJPZgjFJ/EJvwg==
X-Google-Smtp-Source: AA0mqf72JCevdHalTjce7FXtSGFn0u7tTcM+mnHSqdlEmR+bmW3tbOLSfWaN4wBRGe7+R+QBdrhFjM2t7yBJ2wsOKkM=
X-Received: by 2002:a17:906:49a:b0:7b9:631b:7dfb with SMTP id
 f26-20020a170906049a00b007b9631b7dfbmr245445eja.32.1670895414186; Mon, 12 Dec
 2022 17:36:54 -0800 (PST)
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: <20221212203943.GA64277@www.zefox.net> <6E46C762-1409-4977-977A-37D01EB65784@yahoo.com>
  <20221213013145.GA66502@www.zefox.net>
In-Reply-To: <20221213013145.GA66502@www.zefox.net>
From: Warner Losh 
Date: Mon, 12 Dec 2022 18:36:42 -0700
Message-ID: 
Subject: Re: /usr/src/Makefile.inc1 typo?
To: bob prohaska 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="0000000000009eac8505efaba7f4"
X-Rspamd-Queue-Id: 4NWLh74ZYMz3l0D
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009eac8505efaba7f4
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 12, 2022, 6:31 PM bob prohaska  wrote:

> On Mon, Dec 12, 2022 at 05:40:11PM -0700, Warner Losh wrote:
> > On Mon, Dec 12, 2022, 2:21 PM Mark Millard  wrote:
> >
> > > On Dec 12, 2022, at 12:39, bob prohaska  wrote:
> > >
> > > > It looks like there might be a typo (or nomenclature change)
> > > > in armv7.
> > > >
> > > > Last attempt at installkernel stopped with
> > > > make[1]: "/usr/src/Makefile.inc1" line 163: Unknown target
> armv7:armv7
> > > > . . .
> > >
> > > You suffer from bad timing relative to main's [so: 14's]:
>
> 8-)
>
> > >
> > > Sun, 11 Dec 2022
> > >    . . .
> > >     ??? git: 83bf6ab56829 - main - uname: switch machine to
> HW_MACHINE_ARCH
> > > Piotr Kubaj
> > > . . .
> > > Mon, 12 Dec 2022
> > >    . . .
> > >     ??? git: 85dd85323614 - main - Revert "uname: switch machine to
> > > HW_MACHINE_ARCH" Piotr Kubaj
> > >     ??? Re: git: 83bf6ab56829 - main - uname: switch machine to
> > > HW_MACHINE_ARCH Piotr Kubaj
> > > . . .
> > >
> > > Having a system built from a source tree from between the 2
> > > commits one ends up with a broken default native build
> > > environment with complaints about "target NAME:NAME" when the
> > > correct naming for the context has 2 distinct names, such as
> > > arm and armv7 in your context. (That need not be the only
> > > complaint.)
> > >
> > > It may be that explicitly listing TARGET=arm TARGET_ARCH=armv7
> > > on either the make command line(s) or in the environment(s)
> > > might allow a valid build from the messed up context. (But
> > > such is untested.) I've no clue if a full rebuild-from-scratch
> > > might be needed. If it works, you would likely need to be
> > > explicit, even for installkernel and installworld, not just
> > > for building.
> > >
>
> Adding TARGET=arm TARGET_ARCH=armv7 to the build command line didn't
> help. Removing /usr/obj/usr/ didn't help either.
>
> > Libc is all that's needed. Use "make MACHINE=arm" though maybe it's a
> > general workaround.
> >
>
> Maybe I overdid with rm /usr/obj/ but adding MACHINE=arm
> to the make command seems to have got buildworld unstuck. It'll
> take a couple of days to find out for sure 8-)
>

Yes. Make(1) only sets MACHINE if it's not in the environment or the
command line.

Warner


Many thanks to all who replied!
>
> bob prohaska
>
>
>

--0000000000009eac8505efaba7f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 12, 2022, 6:31 PM bob prohaska <fbsd@www.zefox.net> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On Mon, Dec 12, 2022 at 05:40:11PM -0700, War=
ner Losh wrote:

> On Mon, Dec 12, 2022, 2:21 PM Mark Millard <marklmi@yahoo.com>=
; wrote:

> 

> > On Dec 12, 2022, at 12:39, bob prohaska <fbsd@www.zefox.net> wrote:

> >

> > > It looks like there might be a typo (or nomenclature change)=


> > > in armv7.

> > >

> > > Last attempt at installkernel stopped with

> > > make[1]: "/usr/src/Makefile.inc1" line 163: Unknow=
n target armv7:armv7

> > > . . .

> >

> > You suffer from bad timing relative to main's [so: 14's]:=




8-)



> >

> > Sun, 11 Dec 2022

> >=C2=A0 =C2=A0 . . .

> >=C2=A0 =C2=A0 =C2=A0??? git: 83bf6ab56829 - main - uname: switch m=
achine to HW_MACHINE_ARCH

> > Piotr Kubaj

> > . . .

> > Mon, 12 Dec 2022

> >=C2=A0 =C2=A0 . . .

> >=C2=A0 =C2=A0 =C2=A0??? git: 85dd85323614 - main - Revert "un=
ame: switch machine to

> > HW_MACHINE_ARCH" Piotr Kubaj

> >=C2=A0 =C2=A0 =C2=A0??? Re: git: 83bf6ab56829 - main - uname: swit=
ch machine to

> > HW_MACHINE_ARCH Piotr Kubaj

> > . . .

> >

> > Having a system built from a source tree from between the 2

> > commits one ends up with a broken default native build

> > environment with complaints about "target NAME:NAME" wh=
en the

> > correct naming for the context has 2 distinct names, such as

> > arm and armv7 in your context. (That need not be the only

> > complaint.)

> >

> > It may be that explicitly listing TARGET=3Darm TARGET_ARCH=3Darmv=
7

> > on either the make command line(s) or in the environment(s)

> > might allow a valid build from the messed up context. (But

> > such is untested.) I've no clue if a full rebuild-from-scratc=
h

> > might be needed. If it works, you would likely need to be

> > explicit, even for installkernel and installworld, not just

> > for building.

> >



Adding TARGET=3Darm TARGET_ARCH=3Darmv7 to the build command line didn'=
t

help. Removing /usr/obj/usr/ didn't help either. 



> Libc is all that's needed. Use "make MACHINE=3Darm" thou=
gh maybe it's a

> general workaround.

> 



Maybe I overdid with rm /usr/obj/ but adding MACHINE=3Darm

to the make command seems to have got buildworld unstuck. It'll

take a couple of days to find out for sure 8-)
=


Yes. Make(1) only sets MACHIN=
E if it's not in the environment or the command line.

Warner=C2=A0

<=
/div>


Many thanks to all who replied!



bob prohaska








--0000000000009eac8505efaba7f4--

From nobody Tue Dec 13 06:58:04 2022
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 4NWTpm6Vpsz4kKfn
	for ; Tue, 13 Dec 2022 06:58:08 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from nmtao102.oxsus-vadesecure.net (mta-132b.oxsus-vadesecure.net [135.148.117.231])
	(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 4NWTpm0Pcnz4JPH
	for ; Tue, 13 Dec 2022 06:58:07 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=E2CJmupb;
	spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.231 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com
DKIM-Signature: v=1; a=rsa-sha256; bh=haogOl/4N4IjC5YwCAnRPaQ14O2nbCsHG+4VuA
 ho3Hc=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to:
 subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:
 in-reply-to:references:list-id:list-help:list-unsubscribe:
 list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1;
 t=1670914687; x=1671519487; b=E2CJmupb9hzVRmo7gCwNF5BSN6x3Zq6Tt1tLrHkSH
 ZONYxt5R07mbXGBbulCXSwpQwNUYy0kfmtkouQ5U5nGOtVqqR+vnAZbukV+hpjPSJ/nP7HJ
 /MPxr0tlBz0iIKS1zUDidOza+JLOY3g3cTU+6T5lAquB3x10bS1NqqfR14frLgTdRvAAvce
 Y7zM03s8+B/NNuPy9djMhnYEysLK51DOhuhTjle2zkOeEKFe5qaZBRvWHlHOJqj5y+vOffg
 x9sUb2uzz2af+DVtU1eyPQuadCpR/JtOvO65i8QPN7NeCosN1CdMUsG128wEfSLyt4KquEm
 Vs9jjEfJIrmIST4nQ==
Received: from proxy-13.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149])
 by oxsus1nmtao02p.internal.vadesecure.com with ngmta
 id 74c23bec-1730480dc4835aa2; Tue, 13 Dec 2022 06:58:06 +0000
Content-Type: multipart/alternative;
 boundary="------------UgHk0r8kR0fpCk2KzPP7oZFq"
Message-ID: <076925bf-b95c-9d34-6685-8293c5449e4f@thegalacticzoo.com>
Date: Mon, 12 Dec 2022 22:58:04 -0800
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.2.2
Content-Language: en-US
To: peter.hutterer@who-t.net, alan.coopersmith@oracle.com,
 daniel@fooishbar.org
From: Fred Finster 
Subject: libinput_drv.so , libinput.so.10.13.0 fail to build for ARM64 FreeBSD
 14.0-CURRENT source tree, versionsort() function declaration problem
Cc: fredfinster58@gmail.com, freebsd-arm@freebsd.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine];
	R_SPF_ALLOW(-0.20)[+ip4:135.148.117.231];
	R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[135.148.117.231:from];
	DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	TO_DN_NONE(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-Rspamd-Queue-Id: 4NWTpm0Pcnz4JPH
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------UgHk0r8kR0fpCk2KzPP7oZFq
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Xorg maintainers,  I apologize for throwing so much information 
over the wall to point out a simple issue of broken software for

versionsort()  function, that is an update to file 
/usr/src/lib/libc/gen/scandir.c

My inexperience, gets me close to a solution, yet "No Cigar" for the answer.

I tried to learn much on my own and figure out where the fault is, 
before asking you.  I am sure it will be a missing line or a missing 
define somewhere easy to see, with your experience in the Xorg files.

I was using FreeBSD 14.0-CURRENT software and pkgs.    "pkg update"  
"pkg upgrade"    At somepoint,  "startx"  would show a desktop 
environment, yet no keyboad or mouse input was received.  SSH 
fred@192.168.1.7 into the raspberry pi 4B and displaying 
/var/log/Xorg.0.log showed a failure of libinput_drv.so

[ 3730.553] (EE) Failed to load 
/usr/local/lib/xorg/modules/input/libinput_drv.so: 
/usr/local/lib/libinput.so.10: Undefined symbol "versionsort@FBSD_1.7"

I thought patiently waiting, someone else will find and fix this 
problem, and then a pkg update pkg upgrade sequence will pull in the fix 
and the desktop will work again.
So today,  I searched, grepped, read, tested building 
/usr/ports/x11/libinput  and still have not got a solution except to 
comment out the single line 1062 in quirks.c file. Built and then 
another test file  tools/libinput-record.c is broken.
So at your own pace and time, take a look an update  the ARM64 source 
tree to fix this broken use of  versionsort() function.

Thank you,

Fred Finster


 From Xorg Maintainers doc
xinput
P:      Peter Hutterer
M: peter.hutterer@who-t.net
L: xorg-devel@lists.x.org
W: https://gitlab.freedesktop.org/xorg/app/xinput
S:      Maintained

xf86-input-keyboard
P:      Alan Coopersmith
M: alan.coopersmith@oracle.com
L: xorg-devel@lists.x.org
W: https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard
S:      Maintained

xf86-input-mouse
P:      Alan Coopersmith
M: alan.coopersmith@oracle.com
L: xorg-devel@lists.x.org
W: https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse
S:      Maintained

Input subsystem
P:      Daniel Stone
M: daniel@fooishbar.org
P:      Peter Hutterer
M: peter.hutterer@who-t.net
L: xorg-devel@lists.x.org
W: https://wiki.x.org
S:      Maintained, being overhauled
S:      Please contact Daniel or Peter if you're planning to work on this

HERE I POSTED all the information I could find to fix my own problem.  
Alas, I am not experienced enough to solve this 'versionsort' missing 
error on my blog post here below.
https://ghostbsd-arm64.blogspot.com/2022/11/libinput-module-error-fbsd17-not-found.html

I can see 'versionsort' defined in with file 
/usr/src/lib/libc/gen/scandir.c   and  /usr/src/include/dirent.h

is ___BSD_VISIBLE defined??





libinput.so.10.13.0 is broken,  from updating software portsnap fetch 
update;  Then building /usr/ports/x11/libinput and having an issue with 
versionsort() function being defined
Is that a broken "for ARM64 source code tree" with #define __BSD_VISIBLE 
1 and #define __POSIX_VISIBLE 200809


Okay,  I do see below, that I mixed grep source with my GhostBSD 
fredTC93-pc x86_64 and my Raspberry Pi 4B Fred_RasPi4B ARM64:

WHY in file /usr/src/include/dirent.h  is there not a matching 
declaration line for versionsort()  ?
I see that updated software November 13, 2022 has versionsort() declared 
at line /usr/src/include/dirent.h:111:int

fred@fredTC93-pc /u/src> grep -in sort ./include/dirent.h ./sys/sys/dirent.
./include/dirent.h:107:intalphasort(const struct dirent **, const struct 
dirent **);

root@Fred_RasPi4B:/usr/src/include # grep -in sort 
/usr/src/include/dirent.h /usr/src/sys/sys/dirent.h
/usr/src/include/dirent.h:107:int     alphasort(const struct dirent **, 
const struct dirent **);
/usr/src/include/dirent.h:111:int     versionsort(const struct dirent 
**, const struct dirent **);


fred@fredTC93-pc /u/src> cd /usr/ports/x11
fred@fredTC93-pc /u/p/x11> grep -inr scandir *
evtest/files/patch-evtest.c:16:-ndev = scandir(DEV_INPUT_EVENT, 
&namelist, is_event_device, versionsort);
evtest/files/patch-evtest.c:17:+ndev = scandir(DEV_INPUT_EVENT, 
&namelist, is_event_device, alphasort);
fred@fredTC93-pc /u/p/x11>

LIKE:
./include/dirent.h:108:int versionsort(const struct dirent **, const 
struct dirent **);




root@Fred_RasPi4B:/usr/ports/x11/libinput # grep -inr versionsort *
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build:114:if 
cc.has_header_symbol('dirent.h', 'versionsort', prefix : prefix)
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build:115: 
config_h.set('HAVE_VERSIONSORT', '1')
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/quirks/README.md:22:Data 
files are read in versionsort order, read order determines how values
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:31:#if 
!defined(HAVE_VERSIONSORT) || defined(TEST_VERSIONSORT)
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:67:#ifndef 
HAVE_VERSIONSORT
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:75:versionsort(const 
struct dirent **a, const struct dirent **b)
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/quirks.c:42:#include 
"libinput-versionsort.h"
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/quirks.c:1092: 
ndev = scandir(data_path, &namelist, is_data_file, versionsort);
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/litest.c:1487: 
            versionsort);
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/test-utils.c:39:#define 
TEST_VERSIONSORT
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/test-utils.c:40:#include 
"libinput-versionsort.h"
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:46:#include 
"libinput-versionsort.h"
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:1881: 
ndev = scandir("/dev/input", &namelist, is_event_node, versionsort);
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:1943: 
ndev = scandir("/dev/input", &namelist, is_event_node, versionsort);
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build.orig:114:if 
cc.has_header_symbol('dirent.h', 'versionsort', prefix : prefix)
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build.orig:115: 
config_h.set('HAVE_VERSIONSORT', '1')
Binary file 
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-private/coredata.dat 
matches


root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-logs 
# grep -inr versionsort *
meson-log.txt:323:            #ifndef versionsort
meson-log.txt:324:                versionsort;
meson-log.txt:332:                versionsort;
meson-log.txt:336:Header "dirent.h" has symbol "versionsort" : YES
root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-logs 
#


root@Fred_RasPi4B:/usr/src/lib/libc/gen # ls -l scandir*
-rw-r--r--  1 root  wheel  5018 Nov 13 00:36 scandir-compat11.c
-rw-r--r--  1 root  wheel  5306 Nov 13 00:36 scandir.3
-rw-r--r--  1 root  wheel  5965 Nov 13 00:36 scandir.c
-rw-r--r--  1 root  wheel  1416 Aug  5 12:24 scandir_b.c


partial file  /usr/src/lib/libc/gen/scandir.c
#ifndef _KERNEL

__BEGIN_DECLS
#if __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 700
int      alphasort(const struct dirent **, const struct dirent **);
int      dirfd(DIR *);
#endif
#if __BSD_VISIBLE
int      versionsort(const struct dirent **, const struct dirent **);
DIR     *__opendir2(const char *, int);
int      fdclosedir(DIR *);
ssize_t  getdents(int, char *, size_t);
ssize_t  getdirentries(int, char *, size_t, off_t *);
#endif
DIR     *opendir(const char *);
DIR     *fdopendir(int);
struct dirent *
          readdir(DIR *);
#if __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 500
int      readdir_r(DIR *, struct dirent *, struct dirent **);
#endif
void     rewinddir(DIR *);
#if __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 700
int      scandir(const char *, struct dirent ***,
             int (*)(const struct dirent *), int (*)(const struct dirent **,
             const struct dirent **));
#ifdef __BLOCKS__
int      scandir_b(const char *, struct dirent ***,
             int (^)(const struct dirent *),
             int (^)(const struct dirent **, const struct dirent **));
#endif
#endif
#if __BSD_VISIBLE
int      scandirat(int, const char *, struct dirent ***,
             int (*)(const struct dirent *), int (*)(const struct dirent **,
             const struct dirent **));
#endif
#if __XSI_VISIBLE
void     seekdir(DIR *, long);
long     telldir(DIR *);
#endif
int      closedir(DIR *);
__END_DECLS

#endif /* !_KERNEL */

#endif /* !_DIRENT_H_ */




~~~~~~~~~~EOF~~~~~~~~

root@Fred_RasPi4B:/usr/ports/x11/libinput # make clean
===>  Cleaning for ninja-1.11.1,2
===>  Cleaning for pkgconf-1.8.0_1,1
===>  Cleaning for libinput-1.22.0


root@Fred_RasPi4B:/usr/ports/x11/libinput # make -dn
===>  Building for libinput-1.22.0
[  3% 1/32] cc  -o libinput.so.10.13.0 
libinput.so.10.13.0.p/src_filter.c.o 
libinput.so.10.13.0.p/src_filter-flat.c.o 
libinput.so.10.13.0.p/src_filter-low-dpi.c.o 
libinput.so.10.13.0.p/src_filter-mouse.c.o 
libinput.so.10.13.0.p/src_filter-touchpad.c.o 
libinput.so.10.13.0.p/src_filter-touchpad-flat.c.o 
libinput.so.10.13.0.p/src_filter-touchpad-x230.c.o 
libinput.so.10.13.0.p/src_filter-tablet.c.o 
libinput.so.10.13.0.p/src_filter-trackpoint.c.o 
libinput.so.10.13.0.p/src_filter-trackpoint-flat.c.o 
libinput.so.10.13.0.p/src_libinput.c.o 
libinput.so.10.13.0.p/src_libinput-private-config.c.o 
libinput.so.10.13.0.p/src_evdev.c.o 
libinput.so.10.13.0.p/src_evdev-debounce.c.o 
libinput.so.10.13.0.p/src_evdev-fallback.c.o 
libinput.so.10.13.0.p/src_evdev-totem.c.o 
libinput.so.10.13.0.p/src_evdev-middle-button.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-tap.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-thumb.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-buttons.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-edge-scroll.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-gestures.c.o 
libinput.so.10.13.0.p/src_evdev-tablet.c.o 
libinput.so.10.13.0.p/src_evdev-tablet-pad.c.o 
libinput.so.10.13.0.p/src_evdev-tablet-pad-leds.c.o 
libinput.so.10.13.0.p/src_evdev-wheel.c.o 
libinput.so.10.13.0.p/src_path-seat.c.o 
libinput.so.10.13.0.p/src_udev-seat.c.o 
libinput.so.10.13.0.p/src_timer.c.o -Wl,--as-needed -Wl,--no-undefined 
-Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,libinput.so.10 
-fstack-protector-strong -O2 -pipe -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include 
-Wl,-rpath,/usr/local/lib -Wl,-rpath-link,/usr/local/lib 
liblibinput-util.a libquirks.a 
-Wl,--version-script,/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput.sym 
/usr/local/lib/libmtdev.so /usr/local/lib/libudev.so 
/usr/local/lib/libevdev.so /usr/local/lib/libepoll-shim.so -lrt -lm 
/usr/local/lib/libwacom.so -Wl,--end-group
FAILED: libinput.so.10.13.0
cc  -o libinput.so.10.13.0 libinput.so.10.13.0.p/src_filter.c.o 
libinput.so.10.13.0.p/src_filter-flat.c.o 
libinput.so.10.13.0.p/src_filter-low-dpi.c.o 
libinput.so.10.13.0.p/src_filter-mouse.c.o 
libinput.so.10.13.0.p/src_filter-touchpad.c.o 
libinput.so.10.13.0.p/src_filter-touchpad-flat.c.o 
libinput.so.10.13.0.p/src_filter-touchpad-x230.c.o 
libinput.so.10.13.0.p/src_filter-tablet.c.o 
libinput.so.10.13.0.p/src_filter-trackpoint.c.o 
libinput.so.10.13.0.p/src_filter-trackpoint-flat.c.o 
libinput.so.10.13.0.p/src_libinput.c.o 
libinput.so.10.13.0.p/src_libinput-private-config.c.o 
libinput.so.10.13.0.p/src_evdev.c.o 
libinput.so.10.13.0.p/src_evdev-debounce.c.o 
libinput.so.10.13.0.p/src_evdev-fallback.c.o 
libinput.so.10.13.0.p/src_evdev-totem.c.o 
libinput.so.10.13.0.p/src_evdev-middle-button.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-tap.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-thumb.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-buttons.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-edge-scroll.c.o 
libinput.so.10.13.0.p/src_evdev-mt-touchpad-gestures.c.o 
libinput.so.10.13.0.p/src_evdev-tablet.c.o 
libinput.so.10.13.0.p/src_evdev-tablet-pad.c.o 
libinput.so.10.13.0.p/src_evdev-tablet-pad-leds.c.o 
libinput.so.10.13.0.p/src_evdev-wheel.c.o 
libinput.so.10.13.0.p/src_path-seat.c.o 
libinput.so.10.13.0.p/src_udev-seat.c.o 
libinput.so.10.13.0.p/src_timer.c.o -Wl,--as-needed -Wl,--no-undefined 
-Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,libinput.so.10 
-fstack-protector-strong -O2 -pipe -fstack-protector-strong -isystem 
/usr/local/include -fno-strict-aliasing -isystem /usr/local/include 
-Wl,-rpath,/usr/local/lib -Wl,-rpath-link,/usr/local/lib 
liblibinput-util.a libquirks.a 
-Wl,--version-script,/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput.sym 
/usr/local/lib/libmtdev.so /usr/local/lib/libudev.so 
/usr/local/lib/libevdev.so /usr/local/lib/libepoll-shim.so -lrt -lm 
/usr/local/lib/libwacom.so -Wl,--end-group
ld: error: undefined symbol: versionsort
 >>> referenced by quirks.c
 >>> libquirks.a.p/src_quirks.c.o:(quirks_init_subsystem) in archive 
libquirks.a
 >>> referenced by quirks.c
 >>> libquirks.a.p/src_quirks.c.o:(quirks_init_subsystem) in archive 
libquirks.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/libinput
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/libinput
root@Fred_RasPi4B:/usr/ports/x11/libinput #

root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools 
# grep -in versionsort *
libinput-record.c:46:#include "libinput-versionsort.h"
libinput-record.c:1881:    ndev = scandir("/dev/input", &namelist, 
is_event_node, versionsort);
libinput-record.c:1943:    ndev = scandir("/dev/input", &namelist, 
is_event_node, versionsort);

-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144

--------------UgHk0r8kR0fpCk2KzPP7oZFq
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    

      
Hello Xorg maintainers,  I apologize for throwing so much
        information over the wall to point out a simple issue of broken
        software for

      


      

      
versionsort()  function, that is an update to file
        /usr/src/lib/libc/gen/scandir.c

      


      

      
My inexperience, gets me close to a solution, yet "No Cigar"
        for the answer.

      

      


      

      
I tried to learn much on my own and figure out where the
        fault is, before asking you.  I am sure it will be a missing
        line or a missing define somewhere easy to see, with your
        experience in the Xorg files.

      

      


      

      
      


        [ 
          3730.553] (EE) Failed to load
          /usr/local/lib/xorg/modules/input/libinput_drv.so:
          /usr/local/lib/libinput.so.10: Undefined symbol
          "versionsort@FBSD_1.7"

      


        

      
I thought patiently waiting, someone else will find and fix
        this problem, and then a pkg update pkg upgrade sequence will
        pull in the fix and the desktop will work again.

      
So today,  I searched, grepped, read, tested building 
        /usr/ports/x11/libinput  and still have not got a solution
        except to comment out the single line 1062 in quirks.c file. 
        Built and then another test file  tools/libinput-record.c is
        broken.

      
So at your own pace and time, take a look an update  the
        ARM64 source tree to fix this broken use of  versionsort()
        function.

      

      


      

      
Thank you,

      


      

      
Fred Finster

      


      

      


      

      
From Xorg Maintainers doc

      

      
xinput

      
P:      Peter Hutterer

      
      
      
      
S:      Maintained

      


      

    

    

      
xf86-input-keyboard

      
P:      Alan Coopersmith

      
      
      
      
S:      Maintained

    

    


    

    

      
xf86-input-mouse

      
P:      Alan Coopersmith

      
      
      
      
S:      Maintained

    

    


    

    
Input subsystem

      P:      Daniel Stone

      M:      daniel@fooishbar.org

      P:      Peter Hutterer

      M:      peter.hutterer@who-t.net

      L:      xorg-devel@lists.x.org

      W:      https://wiki.x.org

      S:      Maintained, being overhauled

      S:      Please contact Daniel or Peter if you're planning to work
      on this

      

      HERE I POSTED all the information I could find to fix my own
      problem.  Alas, I am not experienced enough to solve this
      'versionsort' missing error on my blog post here below.

    
    


    

    
I can see 'versionsort' defined in with file 
      /usr/src/lib/libc/gen/scandir.c   and  /usr/src/include/dirent.h

    

    
is ___BSD_VISIBLE defined??

    

    


    

    


    

    


    

    


    

    
libinput.so.10.13.0 is broken,  from updating software portsnap
      fetch update;  Then building /usr/ports/x11/libinput and having an
      issue with versionsort() function being defined

    
Is that a broken "for ARM64 source code tree" with #define
      __BSD_VISIBLE 1 and #define __POSIX_VISIBLE 200809

    
 

    

    


    

    
Okay,  I do see below, that I mixed grep source with my
      GhostBSD fredTC93-pc x86_64 and my Raspberry Pi 4B Fred_RasPi4B
      ARM64:

    

    


    

    

      

        
WHY in file /usr/src/include/dirent.h  is there not a
          matching declaration line for versionsort()  ? 

        

        
I see that updated software November 13, 2022 has
          versionsort() declared at line /usr/src/include/dirent.h:111:int

        

        


        

        
fred@fredTC93-pc /u/src> grep -in sort 
          ./include/dirent.h ./sys/sys/dirent.

        
./include/dirent.h:107:int	 alphasort(const
          struct dirent **, const struct dirent **);

      

      


      

      
root@Fred_RasPi4B:/usr/src/include # grep -in sort
        /usr/src/include/dirent.h /usr/src/sys/sys/dirent.h

        /usr/src/include/dirent.h:107:int     alphasort(const struct
        dirent **, const struct dirent **);

        /usr/src/include/dirent.h:111:int     versionsort(const struct
        dirent **, const struct dirent **);

        

      

      


      

      
fred@fredTC93-pc /u/src> cd /usr/ports/x11

      
fred@fredTC93-pc /u/p/x11> grep -inr scandir *

      
evtest/files/patch-evtest.c:16:-	ndev
        = scandir(DEV_INPUT_EVENT, &namelist, is_event_device,
        versionsort);

      
evtest/files/patch-evtest.c:17:+	ndev
        = scandir(DEV_INPUT_EVENT, &namelist, is_event_device,
        alphasort);

      
fred@fredTC93-pc /u/p/x11> 

      


      

      
LIKE:

      

        
./include/dirent.h:108:int	 versionsort(const
          struct dirent **, const struct dirent **);

        


        

      

      


        


          

        

      

      
root@Fred_RasPi4B:/usr/ports/x11/libinput # grep -inr
        versionsort *

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build:114:if
        cc.has_header_symbol('dirent.h', 'versionsort', prefix : prefix)

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build:115:   
        config_h.set('HAVE_VERSIONSORT', '1')

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/quirks/README.md:22:Data
        files are read in versionsort order, read order determines how
        values

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:31:#if
        !defined(HAVE_VERSIONSORT) || defined(TEST_VERSIONSORT)

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:67:#ifndef
        HAVE_VERSIONSORT

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput-versionsort.h:75:versionsort(const
        struct dirent **a, const struct dirent **b)

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/quirks.c:42:#include
        "libinput-versionsort.h"

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/quirks.c:1092:   
        ndev = scandir(data_path, &namelist, is_data_file,
        versionsort);

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/litest.c:1487:   
                   versionsort);

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/test-utils.c:39:#define 
        TEST_VERSIONSORT

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/test/test-utils.c:40:#include
        "libinput-versionsort.h"

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:46:#include
        "libinput-versionsort.h"

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:1881:   
        ndev = scandir("/dev/input", &namelist, is_event_node,
        versionsort);

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools/libinput-record.c:1943:   
        ndev = scandir("/dev/input", &namelist, is_event_node,
        versionsort);

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build.orig:114:if
        cc.has_header_symbol('dirent.h', 'versionsort', prefix : prefix)

work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/meson.build.orig:115:   
        config_h.set('HAVE_VERSIONSORT', '1')

        Binary file
work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-private/coredata.dat
        matches

      

    

    


    

    
root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-logs
      # grep -inr versionsort *

      meson-log.txt:323:            #ifndef versionsort

      meson-log.txt:324:                versionsort;

      meson-log.txt:332:                versionsort;

      meson-log.txt:336:Header "dirent.h" has symbol "versionsort" : YES
      

root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/_build/meson-logs
      # 

      

      


      

      
root@Fred_RasPi4B:/usr/src/lib/libc/gen # ls -l scandir*

        -rw-r--r--  1 root  wheel  5018 Nov 13 00:36 scandir-compat11.c

        -rw-r--r--  1 root  wheel  5306 Nov 13 00:36 scandir.3

        -rw-r--r--  1 root  wheel  5965 Nov 13 00:36 scandir.c

        -rw-r--r--  1 root  wheel  1416 Aug  5 12:24 scandir_b.c

        

      

    

    


    

    
partial file  /usr/src/lib/libc/gen/scandir.c

    
#ifndef _KERNEL

      

      __BEGIN_DECLS

      #if __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 700

      int      alphasort(const struct dirent **, const struct dirent
      **);

      int      dirfd(DIR *);

      #endif

      #if __BSD_VISIBLE

      int      versionsort(const struct dirent **, const struct dirent
      **);

      DIR     *__opendir2(const char *, int);

      int      fdclosedir(DIR *);

      ssize_t  getdents(int, char *, size_t);

      ssize_t  getdirentries(int, char *, size_t, off_t *);

      #endif

      DIR     *opendir(const char *);

      DIR     *fdopendir(int);

      struct dirent *

               readdir(DIR *);

      #if __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 500

      int      readdir_r(DIR *, struct dirent *, struct dirent **);

      #endif

      void     rewinddir(DIR *);

      #if __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 700

      int      scandir(const char *, struct dirent ***,

                  int (*)(const struct dirent *), int (*)(const struct
      dirent **,

                  const struct dirent **));

      #ifdef __BLOCKS__

      int      scandir_b(const char *, struct dirent ***,

                  int (^)(const struct dirent *),

                  int (^)(const struct dirent **, const struct dirent
      **));

      #endif

      #endif

      #if __BSD_VISIBLE

      int      scandirat(int, const char *, struct dirent ***,

                  int (*)(const struct dirent *), int (*)(const struct
      dirent **,

                  const struct dirent **));

      #endif

      #if __XSI_VISIBLE

      void     seekdir(DIR *, long);

      long     telldir(DIR *);

      #endif

      int      closedir(DIR *);

      __END_DECLS

      

      #endif /* !_KERNEL */

      

      #endif /* !_DIRENT_H_ */

    

    


    

    


    

    


    

    


    

    
~~~~~~~~~~EOF~~~~~~~~

    


    

    
root@Fred_RasPi4B:/usr/ports/x11/libinput # make clean

      ===>  Cleaning for ninja-1.11.1,2

      ===>  Cleaning for pkgconf-1.8.0_1,1

      ===>  Cleaning for libinput-1.22.0

    

    


    

    


    

    
root@Fred_RasPi4B:/usr/ports/x11/libinput # make -dn

      ===>  Building for libinput-1.22.0

      [  3% 1/32] cc  -o libinput.so.10.13.0
      libinput.so.10.13.0.p/src_filter.c.o
      libinput.so.10.13.0.p/src_filter-flat.c.o
      libinput.so.10.13.0.p/src_filter-low-dpi.c.o
      libinput.so.10.13.0.p/src_filter-mouse.c.o
      libinput.so.10.13.0.p/src_filter-touchpad.c.o
      libinput.so.10.13.0.p/src_filter-touchpad-flat.c.o
      libinput.so.10.13.0.p/src_filter-touchpad-x230.c.o
      libinput.so.10.13.0.p/src_filter-tablet.c.o
      libinput.so.10.13.0.p/src_filter-trackpoint.c.o
      libinput.so.10.13.0.p/src_filter-trackpoint-flat.c.o
      libinput.so.10.13.0.p/src_libinput.c.o
      libinput.so.10.13.0.p/src_libinput-private-config.c.o
      libinput.so.10.13.0.p/src_evdev.c.o
      libinput.so.10.13.0.p/src_evdev-debounce.c.o
      libinput.so.10.13.0.p/src_evdev-fallback.c.o
      libinput.so.10.13.0.p/src_evdev-totem.c.o
      libinput.so.10.13.0.p/src_evdev-middle-button.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-tap.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-thumb.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-buttons.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-edge-scroll.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-gestures.c.o
      libinput.so.10.13.0.p/src_evdev-tablet.c.o
      libinput.so.10.13.0.p/src_evdev-tablet-pad.c.o
      libinput.so.10.13.0.p/src_evdev-tablet-pad-leds.c.o
      libinput.so.10.13.0.p/src_evdev-wheel.c.o
      libinput.so.10.13.0.p/src_path-seat.c.o
      libinput.so.10.13.0.p/src_udev-seat.c.o
      libinput.so.10.13.0.p/src_timer.c.o -Wl,--as-needed
      -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group
      -Wl,-soname,libinput.so.10 -fstack-protector-strong -O2 -pipe
      -fstack-protector-strong -isystem /usr/local/include
      -fno-strict-aliasing -isystem /usr/local/include
      -Wl,-rpath,/usr/local/lib -Wl,-rpath-link,/usr/local/lib
      liblibinput-util.a libquirks.a
-Wl,--version-script,/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput.sym
      /usr/local/lib/libmtdev.so /usr/local/lib/libudev.so
      /usr/local/lib/libevdev.so /usr/local/lib/libepoll-shim.so -lrt
      -lm /usr/local/lib/libwacom.so -Wl,--end-group

      FAILED: libinput.so.10.13.0 

      cc  -o libinput.so.10.13.0 libinput.so.10.13.0.p/src_filter.c.o
      libinput.so.10.13.0.p/src_filter-flat.c.o
      libinput.so.10.13.0.p/src_filter-low-dpi.c.o
      libinput.so.10.13.0.p/src_filter-mouse.c.o
      libinput.so.10.13.0.p/src_filter-touchpad.c.o
      libinput.so.10.13.0.p/src_filter-touchpad-flat.c.o
      libinput.so.10.13.0.p/src_filter-touchpad-x230.c.o
      libinput.so.10.13.0.p/src_filter-tablet.c.o
      libinput.so.10.13.0.p/src_filter-trackpoint.c.o
      libinput.so.10.13.0.p/src_filter-trackpoint-flat.c.o
      libinput.so.10.13.0.p/src_libinput.c.o
      libinput.so.10.13.0.p/src_libinput-private-config.c.o
      libinput.so.10.13.0.p/src_evdev.c.o
      libinput.so.10.13.0.p/src_evdev-debounce.c.o
      libinput.so.10.13.0.p/src_evdev-fallback.c.o
      libinput.so.10.13.0.p/src_evdev-totem.c.o
      libinput.so.10.13.0.p/src_evdev-middle-button.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-tap.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-thumb.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-buttons.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-edge-scroll.c.o
      libinput.so.10.13.0.p/src_evdev-mt-touchpad-gestures.c.o
      libinput.so.10.13.0.p/src_evdev-tablet.c.o
      libinput.so.10.13.0.p/src_evdev-tablet-pad.c.o
      libinput.so.10.13.0.p/src_evdev-tablet-pad-leds.c.o
      libinput.so.10.13.0.p/src_evdev-wheel.c.o
      libinput.so.10.13.0.p/src_path-seat.c.o
      libinput.so.10.13.0.p/src_udev-seat.c.o
      libinput.so.10.13.0.p/src_timer.c.o -Wl,--as-needed
      -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group
      -Wl,-soname,libinput.so.10 -fstack-protector-strong -O2 -pipe
      -fstack-protector-strong -isystem /usr/local/include
      -fno-strict-aliasing -isystem /usr/local/include
      -Wl,-rpath,/usr/local/lib -Wl,-rpath-link,/usr/local/lib
      liblibinput-util.a libquirks.a
-Wl,--version-script,/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/src/libinput.sym
      /usr/local/lib/libmtdev.so /usr/local/lib/libudev.so
      /usr/local/lib/libevdev.so /usr/local/lib/libepoll-shim.so -lrt
      -lm /usr/local/lib/libwacom.so -Wl,--end-group

      ld: error: undefined symbol: versionsort

      >>> referenced by quirks.c

      >>>              
      libquirks.a.p/src_quirks.c.o:(quirks_init_subsystem) in archive
      libquirks.a

      >>> referenced by quirks.c

      >>>              
      libquirks.a.p/src_quirks.c.o:(quirks_init_subsystem) in archive
      libquirks.a

      cc: error: linker command failed with exit code 1 (use -v to see
      invocation)

      ninja: build stopped: subcommand failed.

      *** Error code 1

      

      Stop.

      make[1]: stopped in /usr/ports/x11/libinput

      *** Error code 1

      

      Stop.

      make: stopped in /usr/ports/x11/libinput

      root@Fred_RasPi4B:/usr/ports/x11/libinput # 

    

    


    

    
root@Fred_RasPi4B:/usr/ports/x11/libinput/work/libinput-fc59e574e050c502c9a3adefacf97babf3d09c7a/tools
      # grep -in versionsort *

      libinput-record.c:46:#include "libinput-versionsort.h"

      libinput-record.c:1881:    ndev = scandir("/dev/input",
      &namelist, is_event_node, versionsort);

      libinput-record.c:1943:    ndev = scandir("/dev/input",
      &namelist, is_event_node, versionsort);

    

    


    

    

    
-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144

  


--------------UgHk0r8kR0fpCk2KzPP7oZFq--

From nobody Tue Dec 13 10:35:32 2022
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 4NWZdh6Cbfz4klXW
	for ; Tue, 13 Dec 2022 10:35:36 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from nmtao102.oxsus-vadesecure.net (mta-132a.oxsus-vadesecure.net [135.148.117.230])
	(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 4NWZdg6B1Mz4lPH
	for ; Tue, 13 Dec 2022 10:35:35 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=gajH8rRg;
	spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.230 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com
DKIM-Signature: v=1; a=rsa-sha256; bh=SQ0XeyRExuxg7NVEbg9VRV+GvXfLBktW+JHJwz
 X62zc=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to:
 subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:
 in-reply-to:references:list-id:list-help:list-unsubscribe:
 list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1;
 t=1670927734; x=1671532534; b=gajH8rRgwvVYATrdLJlTYdP6nMJmn03GMMDOI2ieo
 fZZ8ManmW7acEQH0/2GvB+GSat40FZq/Rz3EMy6mXup7AzN+kPLcfT+/1iMHUe7mKFcTpsq
 JMY4NFK+2Uex19jnKx6iKDI6YP+7Wg4xghp87aNTfHfOGuDIYeioaq7JCHL/xxpTQvkW/20
 iMIz/xakq/aGdadSo3w3SrxnIi32egTg9Gkq7gL1qPlOxB59RAt1I37ZQKM92JF1gPJph/e
 FE7asKt/UH61Z6kF8yPzPp+Ls0VbeykDLXTevvcNUB3qZMz9X7ExIzZIyWdsvT59acc8ZRk
 ax7iYauWYuv/gFYBg==
Received: from proxy-6.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149])
 by oxsus1nmtao02p.internal.vadesecure.com with ngmta
 id a78aa2c8-173053ebbd7bedae; Tue, 13 Dec 2022 10:35:34 +0000
Message-ID: <495e2068-bdfe-f8f7-34cc-de7b44f25c1a@thegalacticzoo.com>
Date: Tue, 13 Dec 2022 02:35:32 -0800
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.2.2
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Fred Finster 
Subject: Desktop Environments, MATE, XFCE4 anyone else running a desktop
 environment on their ARM64 sbc with FreeBSD 14.0-CURRENT?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-2.98 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.976];
	DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine];
	R_SPF_ALLOW(-0.20)[+ip4:135.148.117.230];
	R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[135.148.117.230:from];
	DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NWZdg6B1Mz4lPH
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hello Fellow FreeBSD-arm users,

just wondering if anyone else is enjoying a desktop environment on their 
ARM64 sbc running FreeBSD 13.0-STABLE or 13.1-RELENG or 14.0-CURRENT?  
MATE or XFCE4? other Desktop Environment?

I was enjoying MATE desktop environment on my Raspberry Pi 4B with 8 gb 
ram, using hardware I bought almost 2 years ago in January 2021 from 
Vilros.com  .

https://forums.raspberrypi.com/viewtopic.php?t=343233
(Solved), HDMI audio sound output through TV speakers Freebsd 13 or 14 
plus VCHIQ audio patch file

This  wiki.radxa.com/rock5   SBC hardware looks promising.  Is there any 
FreeBSD O/S support for that hardware for the RK3588 8 cpu board?  too 
new to know, until someone buys one hardware board and tries booting 
FreeBSD-ARM64.?

https://ameridroid.com/collections/rock5-model-b

https://wiki.radxa.com/Rock5

pkg update ;  pkg upgrade   broke my desktop environment from being 
usable.  versionsort() function was undefined somehow in the updated 
software.    Well, I learned to ssh into the Raspi4B via the ethernet 
cable and that is working fine for building and testing software with a 
single screen.

Audio_Patch for VCHIQ, So nice to listen to YouTube videos on your SBC 
computer.  What can I do to review and help move that patch to be part 
of the source code?

https://reviews.freebsd.org/D36431   I am reading this now. Doing my 
part to move FreeBSD source forward.

Wishing you a pleasant week FreeBSD-arm user, in your use of FreeBSD on 
Armv7 or Armv8a.  Bob P  is doing his testing, too! Good Job Bob.



-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144
https://GhostBSD-ARM64.blogspot.com
https://ghostbsd.org


From nobody Tue Dec 13 12:17:50 2022
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 4NWcvk6TpZz4kwkY
	for ; Tue, 13 Dec 2022 12:17:54 +0000 (UTC)
	(envelope-from quelrond@gmail.com)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334])
	(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 4NWcvk3QqXz3M4M
	for ; Tue, 13 Dec 2022 12:17:54 +0000 (UTC)
	(envelope-from quelrond@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-wm1-x334.google.com with SMTP id ay2-20020a05600c1e0200b003d22e3e796dso2069061wmb.0
        for ; Tue, 13 Dec 2022 04:17:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=cLzxdmjVXD/mQVGg2RrJiiF9gVNwlrWep4hNyY1rahI=;
        b=auBBhmcrTpe2/L2R2UYRyFfP83y9PqmgVw8B2fan+ZUDP08N/HFy8stqL1IAIQ2x3S
         IqsFGnHzq6Ny30AuVyLxUnkxIdll1KcX01qXhieGfCLueBrraamOIuVZVqlwk2faPIlL
         FWmeyrRPnwJFr82YKbsadWJHi+3YJiekMK/8lZxqZsD4SbANCdWIhAsDTl4aWqYpDMH5
         AOYpCXQQ1MPkygB7Q0CIQmYlZjxwJL3WniG8IloCxUdNe8I6n0x7M6dFA95IF0Zwtz3u
         ymi2uqkF57GApAwvtAeF18lFc6J6tF515uI0oA8jmVW6KR2DX0NwJuxqImS3U0/ozI8V
         m5NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cLzxdmjVXD/mQVGg2RrJiiF9gVNwlrWep4hNyY1rahI=;
        b=7qL8gAWWnuVmSeIUPK0ZpnkHfvwQxmXpYnGdbaEDRzx+k0coSG/bgPex8TNmrThiKA
         m+n96OTNt/XGN1rrz326JLu0JpIXmAmNx78vhgez9LWDoFiqLdfKkiZIn3CuW73cxwJd
         YA53YqwkBnEMWxH2YeTzzNCGlTcxKeOSRXfUYdEmVSlqBWZgO/XTHWShpwoUM21lt4GC
         XltfViEzcLl2fR0UEY1CDz0i8r9bNvdIPAd+DET5ghFcQOHJKfaPmlCeiZ8yAz3uWLKe
         /B73Y0gg4YzW+l0Ofnu2v0bSZy7araH2IX7suk3PXctMpVwQ3ll9ikz++MPanGoWQz0W
         GqLQ==
X-Gm-Message-State: ANoB5pk4gsEX3TbPeJUUi28g2dvFlciHEdLpEcJl0Os9JoU3sE0eRMBV
	vrPVKNSi1at7BkGrl0JGkv6aTsA21t0=
X-Google-Smtp-Source: AA0mqf435gJy4fAER42Iyhj3hUIEzQLKf3ec8wybmfniZQxR64OLH8LTOUGIdHZPV2H4hfYxSs7hnw==
X-Received: by 2002:a05:600c:4e91:b0:3d1:dc6f:b1a4 with SMTP id f17-20020a05600c4e9100b003d1dc6fb1a4mr19467600wmq.5.1670933872160;
        Tue, 13 Dec 2022 04:17:52 -0800 (PST)
Received: from [192.168.211.51] (85-31-109-70.netw.fr. [85.31.109.70])
        by smtp.gmail.com with ESMTPSA id n22-20020a05600c3b9600b003cfd0bd8c0asm14000004wms.30.2022.12.13.04.17.51
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 13 Dec 2022 04:17:51 -0800 (PST)
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 11.5 \(3445.9.7\))
Subject: Re: Desktop Environments, MATE, XFCE4 anyone else running a desktop
 environment on their ARM64 sbc with FreeBSD 14.0-CURRENT?
From: Quelrond Q 
In-Reply-To: <495e2068-bdfe-f8f7-34cc-de7b44f25c1a@thegalacticzoo.com>
Date: Tue, 13 Dec 2022 13:17:50 +0100
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C5D101E-BFB8-4E69-B7F4-42B0096852CA@gmail.com>
References: <495e2068-bdfe-f8f7-34cc-de7b44f25c1a@thegalacticzoo.com>
To: Fred Finster 
X-Mailer: Apple Mail (2.3445.9.7)
X-Rspamd-Queue-Id: 4NWcvk3QqXz3M4M
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Hello,

Enlightenment installed from package worked perfectly on RPi4 with 4GB =
de RAM on FreeBSD 13.

Peter=20

> Le 13 d=C3=A9c. 2022 =C3=A0 11:35, Fred Finster =
 a =C3=A9crit :
>=20
> Hello Fellow FreeBSD-arm users,
>=20
> just wondering if anyone else is enjoying a desktop environment on =
their ARM64 sbc running FreeBSD 13.0-STABLE or 13.1-RELENG or =
14.0-CURRENT?  MATE or XFCE4? other Desktop Environment?
>=20
> I was enjoying MATE desktop environment on my Raspberry Pi 4B with 8 =
gb ram, using hardware I bought almost 2 years ago in January 2021 from =
Vilros.com  .
>=20
> https://forums.raspberrypi.com/viewtopic.php?t=3D343233
> (Solved), HDMI audio sound output through TV speakers Freebsd 13 or 14 =
plus VCHIQ audio patch file
>=20
> This  wiki.radxa.com/rock5   SBC hardware looks promising.  Is there =
any FreeBSD O/S support for that hardware for the RK3588 8 cpu board?  =
too new to know, until someone buys one hardware board and tries booting =
FreeBSD-ARM64.?
>=20
> https://ameridroid.com/collections/rock5-model-b
>=20
> https://wiki.radxa.com/Rock5
>=20
> pkg update ;  pkg upgrade   broke my desktop environment from being =
usable.  versionsort() function was undefined somehow in the updated =
software.    Well, I learned to ssh into the Raspi4B via the ethernet =
cable and that is working fine for building and testing software with a =
single screen.
>=20
> Audio_Patch for VCHIQ, So nice to listen to YouTube videos on your SBC =
computer.  What can I do to review and help move that patch to be part =
of the source code?
>=20
> https://reviews.freebsd.org/D36431   I am reading this now. Doing my =
part to move FreeBSD source forward.
>=20
> Wishing you a pleasant week FreeBSD-arm user, in your use of FreeBSD =
on Armv7 or Armv8a.  Bob P  is doing his testing, too! Good Job Bob.
>=20
>=20
>=20
> --=20
> Fred  Finster
> fred@thegalacticzoo.com
> +1 971-718-9144
> https://GhostBSD-ARM64.blogspot.com
> https://ghostbsd.org
>=20
>=20


From nobody Tue Dec 13 18:48:02 2022
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 4NWnZF5vSWz4kVJ7
	for ; Tue, 13 Dec 2022 18:48:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4NWnZD24Vmz4HJN
	for ; Tue, 13 Dec 2022 18:48:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=XJ4wC1xJ;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 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=1670957297; bh=bI0TBIjLECVPOlBVmMRMkR4ps33dJ3H3JWUv/qfddGg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=XJ4wC1xJpSrDo2RMtN010aMRMrzpJNiZaIZ929i7e0qXalJXKBUIrkbT4EDmYy7MpU+fUKFJbPGTsqvw8L9HnhUKfxavUJvfIfkzcD/0PFs+wZHtARVOE8VMLhAWZVtoxxdOo69EJua6cLIcpS6BMKKyqehoGUxwecDGURXgLbXQ/XdnTEXotvXYFasDxmulYUufc/R6q+VwajFyCtv620SoOdNxALBKsCm99ShkFubyTVe+H2N0SYfwN1h43AXSMbNRoqzgWo0qqeaD6ZlWwq0cSuUOILJQxjWRW29TBAbkX8Lmg14TzMYQQTvwNW3ENroXtCKOHrjDJsCiIGGjEw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670957297; bh=B7ZmizZQYr66f2UAqI6Q9PExzLJ0Vac6HeBx7P50yMR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Me/jtrD86gkcAsaljOAHjRX5ZkLj+hwbR27W08FctXBQnlGitB1Irzg7mGPG47LuPBtxwdq5C5pgHKmcvMJ0PZAh+AMPAaa4qnUdCVxjIY5dzTtryx0/CCfs33dYDO+uxxOGpc4CgRGglMP9uV9FEk/y4dxx/YHB2qmQIuw5ni7Dz19SGGttMahh+fDw3EiP7cJYuGUFeh40ANV0wbamrbjBKnhyMbHahOGt5I+6Y+2p5vL0VaholshamP4Y4489igVKIPwpM4HgQUXWNUUkMZ0IY8GeZHexzieO3ORgLDeAc5pen0PdNH361HM+RgK3rK0xPru9X+LVph4AOi+4MA==
X-YMail-OSG: LXb55QQVM1lsmBBe1R9LoFLGAiHkP6UK9dlkyeuil6WkKSuPxlvsCBKC0wYHgvt
 YeUYDLgDs3Sapzldnc8O3SXlPX.I6Fq1wDN4H76102IAhiOWcjbrc6Ayljqo74pNrZrslKsDbmFh
 egjPG4RdnA800G2nfkCMc4qEtD3lfcBpB4iA8uQL2W0.LvgYbO65AOG3YJM37R0NXnk09OjxP8dh
 HzpAVgazJOVmo_SS42YeXTA08nUFM1jiBqNAyTlM6FOsL95Xax6kMbB1wcpBYmqq5FqPe0RAhnmo
 tUI1b3lHMMhyyFtO0_0tSg2euvQGhwlbYxZlGeYqjyA91QXpqbuioFQS8Au9Y7QIe11F7FDvycRN
 vjWZlLAGDMzrdonVL9K86gLYWpzAjifC3_0FWh4vy6Xa4GFtsFXlogR0wx5hY2wdBjY0ZNdk7pK0
 GJwM0BU2FZVCMKWgyzjbquk6t7r_Vu_jC1LRb7MeqwxuL433PwVohSsR30DsRiKYPiMfBUgd.iom
 hAdkcSzCIV1iAYrCbbV2WonkseIewGQDSnErZM.NfzFGb_xpYZmx67ytA5K4cJeBepWV.SJESmUs
 JxTIDH273ALutj9NNSOcRW9NNWDhECSRBkCrM.yUHWyBApci_U6kOOGGGzKVaLkLcYYGtoLwzvLM
 uYFBCiKkAPrERemhKavj3duWCz4FxKTSsrU2sLR4RbI62XHtY.WNXAeig1.Swbijf0ekjTTZsUCA
 Cw2q8akjtGOhCy0rm3htuoAgV4spReGQKd9QFF9UZBQo.F04Z4ZjVNTdcgBakwUU4ggJhLeD5JwQ
 q2NC6cGDCQAKSTVNhJUpDdXgwMtl3slmkuDpui1uRCp3_Kd03yUHlUKqykOFDeghbCUInuDIY1IJ
 RXO2FmoHFbB9xsYlj4Yd00WqpCVaEVDiSb12_Fp0ZFyFbcUO9MbzahpLL_LiFssq29htnrHQe_Oc
 fnyui35PdlGTDvN5YEl7Ii10dRQqW0Epz.gKvsM1g9H7sqFDM_2QZl7pWbW_jy0WkpnWr2.UKU5H
 3fXsKFoHMtrqRZY3SrYq3DZY8oBB1svGcfJ9fX8W11v0lr1V0UB.XpWcUkhcfwVySeni4wBba_kw
 s.OtWhCACv0qSwlvmLch_2b3.fGDSRBnVmjt38HWR4XQgczs3R19_liumUWYHume2JqVSCSssziY
 _EWKuNctWMae5vq0bVx_6MOAMXNhXNta0fmZHFEz7wlL.jBZz0we0YGzaHy2s0gyUtA27wXZSKhN
 JC_zKoWHDPpGUVRRXYsX4gmHcediyL30TRVPfW5DYeONFrGl8eTsWrK5wA9bJCR5.FwxOK8_oJzg
 pjWvAeWR3Xh2goMfYnjxPs.b3ldGrF_ujbPefrw02.zLbW7LIuikI1lTde6.U9gTLxk5wF1tThpZ
 t1vugSmi0xIQ1aG_75meq4uR1IyRp7PQHKBpkXS7giP2sUGfRpxP5mDac_bObFqLV8HTDxLFdgiU
 el2i9SO5XUQjgyzyaWqRMVIu4.OJvO0onEDfwkCNU3m5G1ZHWSXPXg4flWDgf_0_zNST0OIifKDk
 YztTVNJvFD38N2zlsPER_3XwUhtlocTbox6HjERV80LiKxIkP6dBt44pIGRaGlcvAWXmYNjxApjj
 jvfy5ENQOi64X3HlLvB8T1nzrXqEJrXZqGst14o9BXQFWz9.bz6p26O2uRXNdp6KF3Jk7QXjEOUz
 0wD0XvZJ6XheBK3DSmXuEaW9HIYMCYGxOEWAM0HHbEWlpI3O4qOD64YxOS3q2ifoAf0lqD_Kpuss
 tklxjDtHcs0H9HjdFj7FEHbpxAiTtdIVfmmRN7mJK4BI90zL_jPzFcqNMzwZfTGlsukG3ayxIgRv
 cqE7R0yHUoD38t9XysN.SSTAet.plFbN0.eneFHjEX7bCbTEXd8.26KfSIIqsOVOCR6vDaUFc3PS
 V0QQwO7swJKEU89Qom.3tQn84yKVlMO91yq7GV08D1tfmugqSH_QzeJ9z.4Llr91dac32HufJPlk
 FPWUmM4jo.bo2itDKyYRSde1p.5U1g2fkGNr6FXjcTP9iuFt3sms8rviwwMJLgQ5VEqhm.KVTMoW
 GUqNlQhJkAY7Fs4dkkMTND2mhNZoc98haUJ.tog6zwrYWw36RAhX_F269ib9E5edZ9SLeZF5EMQl
 NB5T04mIJMW5MHQaF.C1TASjIMhgaLOKvw6Pq1.j3biQ2vUEGidCTTO3pajyTC9hx7wbFVuhT7GV
 rI3NKT6oJB8DQQVyQH46QaSG2Nv0lFFljGrFmd9QmKiiheqyd2gGHs1xIDKA-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Dec 2022 18:48:17 +0000
Received: by hermes--production-ne1-7b69748c4d-mpl4q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9f528e0022ee18d591f36b4a887e820f;
          Tue, 13 Dec 2022 18:48:14 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed (just a reference to
 the new message on freebsd-arch)
Message-Id: <59E6F239-10E1-4958-87BA-49960C7C146E@yahoo.com>
Date: Tue, 13 Dec 2022 10:48:02 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <59E6F239-10E1-4958-87BA-49960C7C146E.ref@yahoo.com>
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	NEURAL_HAM_LONG(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NWnZD24Vmz4HJN
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

FYI: The old 2021-Oct-28 message related to armv6 removal
sequencing/timing has a new follow up finally:

https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html

(Nothing about this changes the armv7 status.)

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 13 18:57:42 2022
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 4NWnnG65ttz4kW4l
	for ; Tue, 13 Dec 2022 18:57:54 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
	(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 4NWnnG3yV2z4JMG
	for ; Tue, 13 Dec 2022 18:57:54 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x532.google.com with SMTP id v8so19165015edi.3
        for ; Tue, 13 Dec 2022 10:57:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=rEX3c7NvMbUAtcx2ATVq+jGoevzH15GQtFQfIUgfF2A=;
        b=d3fJ4B+gLcS9VSmuR54KmE9auW9Bl4QOTabqdo1svcsDN8pJUyGNMsF6Camubmyzfa
         yg4RKSQ5cxWTavDgDDc1uAdYigQ5KUwcbEMIe69rfg7laeI9sXrgSKRou5ku62HULxAi
         OTCwnNvrAugIPQa6W5ENxPB9DYNA5qy3YEOX2rCfuLDeZKQdBCeTrUiHF8L7//e+HFcB
         npK+L77HKSq4woW+EVqL0vwoLhfZMvjnZiggNAwcPbPJeyfuU8mJxaw7FzDt6xW/1DJs
         h8bnN04c79GZAEI87/HDgPfBbfSD4sL9VabyMPmFwZLzOVSSCPUawSBtmGWyEeSbZ1rt
         3mdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=rEX3c7NvMbUAtcx2ATVq+jGoevzH15GQtFQfIUgfF2A=;
        b=71/KKphzOYgTIKORI6vpDUUAJ7rZxZbPoJPIj7toWmJTF7yU3Nto15NrqAHtbD2THA
         8XPFppj5yE3627mT2o4EMPoRPe8UtUdE1hUZTx0jDiHn+uvmzNyDZsKDZ1Wm5dZ9V/K/
         FZDOs/Wjp00hdw1hZ7hSs6I4ynr5M62H3Pk/9HZW/nXz3tjb0iZD6LObPRIorlJxy+ni
         X4vX2R+5CQlhClNLKEWltXRfBinwdmuzHZQ/8o0r4s86qG6UokAC68z/GHtwUKrQzsMY
         dZY3/c3yyRv9TrlKD3fa1C5J9nc+SU4DTGwHJEO1OwxGd7gxnKkgc8PK77jfqvD8cU2c
         SCWw==
X-Gm-Message-State: ANoB5pkzo6pQlgwkrjmAMwV7o1BYjIkuEzQ1wTfDLGTMtSWfgNjVVbqh
	DPz+J+Yg+LcZSIPgpkwJyr1kXhTbmpvPktzrnqKA54Nk07zB4Q==
X-Google-Smtp-Source: AA0mqf7B4Nz893vA8RM+FBqgWatcQboSiFY4P1MSNbjdv3m60V8h8AxFnHvfTcmifCes35o5S4ShPoRA87KcmVwp5fY=
X-Received: by 2002:a05:6402:360a:b0:469:f59f:352e with SMTP id
 el10-20020a056402360a00b00469f59f352emr65780344edb.241.1670957873292; Tue, 13
 Dec 2022 10:57:53 -0800 (PST)
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: <59E6F239-10E1-4958-87BA-49960C7C146E.ref@yahoo.com> <59E6F239-10E1-4958-87BA-49960C7C146E@yahoo.com>
In-Reply-To: <59E6F239-10E1-4958-87BA-49960C7C146E@yahoo.com>
From: Warner Losh 
Date: Tue, 13 Dec 2022 11:57:42 -0700
Message-ID: 
Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed (just a reference to
 the new message on freebsd-arch)
To: Mark Millard 
Cc: freebsd-arm 
Content-Type: multipart/alternative; boundary="00000000000078f74c05efba32ce"
X-Rspamd-Queue-Id: 4NWnnG3yV2z4JMG
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000078f74c05efba32ce
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 13, 2022 at 11:48 AM Mark Millard  wrote:

> FYI: The old 2021-Oct-28 message related to armv6 removal
> sequencing/timing has a new follow up finally:
>
> https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html
>
> (Nothing about this changes the armv7 status.)
>

Nope.

tl;dr: armv6 packages will stop, we'll stop doing -current armv6 snapshots,
we'll move armv6 to
an 'extra' architecture in universe for stable/14. post stable/14 we'll
tear down support for armv6
in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 of
them also mention armv7,
and the vast majority of them mark things as broken in some way (though
there are exceptions).

Warner

--00000000000078f74c05efba32ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Dec 13, 2022 at 11:48 AM Mark=
 Millard <marklmi@yahoo.com>=
 wrote:
FYI: The=
 old 2021-Oct-28 message related to armv6 removal

sequencing/timing has a new follow up finally:



https://lists.freebsd.org/a=
rchives/freebsd-arch/2022-December/000313.html



(Nothing about this changes the armv7 status.)

Nope.

tl;dr: armv6 packages will stop, we&=
#39;ll stop doing -current armv6 snapshots, we'll move armv6 to
an 'extra' architecture in universe for stable/14. post stable/1=
4 we'll tear down support for armv6
in base and later in port=
s. Ports mention armv6 ~500 times, maybe 1/4 of them also mention armv7,
and the vast majority of them mark things as broken in some way (th=
ough there are exceptions).

Warner

<=
/div>


--00000000000078f74c05efba32ce--

From nobody Tue Dec 13 20:28:56 2022
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 4NWqp632Y8z4khXw
	for ; Tue, 13 Dec 2022 20:28:46 +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 4NWqp524DXz3Klp
	for ; Tue, 13 Dec 2022 20:28:45 +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.16.1/8.15.2) with ESMTPS id 2BDKSvSg074476
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 13 Dec 2022 12:28:57 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2BDKSv2h074475;
	Tue, 13 Dec 2022 12:28:57 -0800 (PST)
	(envelope-from fbsd)
Date: Tue, 13 Dec 2022 12:28:56 -0800
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed (just a reference
 to the new message on freebsd-arch)
Message-ID: <20221213202856.GA73930@www.zefox.net>
References: <59E6F239-10E1-4958-87BA-49960C7C146E.ref@yahoo.com>
 <59E6F239-10E1-4958-87BA-49960C7C146E@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-Spamd-Result: default: False [-0.95 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.85)[-0.854];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NWqp524DXz3Klp
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Dec 13, 2022 at 11:57:42AM -0700, Warner Losh wrote:
> On Tue, Dec 13, 2022 at 11:48 AM Mark Millard  wrote:
> 
> > FYI: The old 2021-Oct-28 message related to armv6 removal
> > sequencing/timing has a new follow up finally:
> >
> > https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html
> >
> > (Nothing about this changes the armv7 status.)
> >
> 
> Nope.
> 
> tl;dr: armv6 packages will stop, we'll stop doing -current armv6 snapshots,
> we'll move armv6 to
> an 'extra' architecture in universe for stable/14. post stable/14 we'll
> tear down support for armv6
> in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 of
> them also mention armv7,
> and the vast majority of them mark things as broken in some way (though
> there are exceptions).

Apologies if I'm belaboring the obvious, but does that imply armv7
support will go on as now for the near future?

Thanks for reading,

bob prohaska


From nobody Tue Dec 13 20:41:37 2022
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 4NWr592RJhz4kjlL
	for ; Tue, 13 Dec 2022 20:41:49 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632])
	(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 4NWr59205Rz3NQC
	for ; Tue, 13 Dec 2022 20:41:49 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x632.google.com with SMTP id vv4so39641739ejc.2
        for ; Tue, 13 Dec 2022 12:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=oZxnnj8RGbAJvNEC2y5ZSRI8glelGrpHvGwIsS/C7vo=;
        b=wszek/WM+xpGnXofnIfbA88y4EFLnQBg99YO8C7jsc3nQK736if8F3HsFg174PP/BF
         f25cv0HZbQkr148GF24Wm6hoVkn16DW7RViUSWrdvSXjGVPBBujNcUiKt6IctqhnqHQ+
         hXfxV9grM5cce/l75s0E18oA5RfuKFZmPOQaIYkeH4teChEainkSonZliq9nTxnv3sod
         eu9JVFBt2WZdxcMwxVfXgPFKLPVsGzNR6VJ/kB/0qz6pNKoUrTUn2pwq43cVg+anqA/0
         gafX95sJUVeZ4gV/oCBhEixJUzYhozE/ZlMg0ZnN2aYr9clHXGzA0o8FlUR0FYVwEdZp
         DRMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=oZxnnj8RGbAJvNEC2y5ZSRI8glelGrpHvGwIsS/C7vo=;
        b=1orEHFfmwaBLfgqp67RZwRyf9eMrk6eIgHfxCoY7x00MMORwKhN7lGYyruVf9ma4p7
         h1nssoFxBQEiHc8U8W+TqK5xURFwhe5bCOjYGliIgOUjJ0h7TMZj4AW3LPIb6K7BmniF
         AE8mLE0O4KMbE6w6fbsbZGT2ppQciSiM4BVRPAnlbRgGCzPwNQhN2P7eLyMlbxUVpWoa
         SSXkJYW+y+P0dG5rTUlVnvgW8g5XIfuURCE03Ck6u1DEIfG1zB7wlTnawLEheNbayAxw
         UOG9bjFuWT+MkYIXZ5sv1+8bhs6+GEFOU9K5vFrRyhaiMv5G9uXEcVQJIZOSRzE/pzt8
         Rb3w==
X-Gm-Message-State: ANoB5pkR+0fsFHOCfhJZlbR+sILru0r3YwAN/f96fZGX3AplRP2ujcjv
	Kxh/oICRaB38q7b5EKZaTKp8JKVfAzjn/osQewBSLZP+5kypiQ==
X-Google-Smtp-Source: AA0mqf4QP4Cekl6K2sd0RkznCEUHr0LrRAc+RRdWcfnPVsj6V9pBzrFYf5/UCluZtrZupRt0QFa0lAiEqGInfQL4tUU=
X-Received: by 2002:a17:906:29c3:b0:7c0:e0db:f136 with SMTP id
 y3-20020a17090629c300b007c0e0dbf136mr17702701eje.333.1670964108118; Tue, 13
 Dec 2022 12:41:48 -0800 (PST)
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: <59E6F239-10E1-4958-87BA-49960C7C146E.ref@yahoo.com>
 <59E6F239-10E1-4958-87BA-49960C7C146E@yahoo.com> 
 <20221213202856.GA73930@www.zefox.net>
In-Reply-To: <20221213202856.GA73930@www.zefox.net>
From: Warner Losh 
Date: Tue, 13 Dec 2022 13:41:37 -0700
Message-ID: 
Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed (just a reference to
 the new message on freebsd-arch)
To: bob prohaska 
Cc: "freebsd-arm@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000018db9f05efbba60b"
X-Rspamd-Queue-Id: 4NWr59205Rz3NQC
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000018db9f05efbba60b
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 13, 2022, 1:28 PM bob prohaska  wrote:

> On Tue, Dec 13, 2022 at 11:57:42AM -0700, Warner Losh wrote:
> > On Tue, Dec 13, 2022 at 11:48 AM Mark Millard  wrote:
> >
> > > FYI: The old 2021-Oct-28 message related to armv6 removal
> > > sequencing/timing has a new follow up finally:
> > >
> > >
> https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html
> > >
> > > (Nothing about this changes the armv7 status.)
> > >
> >
> > Nope.
> >
> > tl;dr: armv6 packages will stop, we'll stop doing -current armv6
> snapshots,
> > we'll move armv6 to
> > an 'extra' architecture in universe for stable/14. post stable/14 we'll
> > tear down support for armv6
> > in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 of
> > them also mention armv7,
> > and the vast majority of them mark things as broken in some way (though
> > there are exceptions).
>
> Apologies if I'm belaboring the obvious, but does that imply armv7
> support will go on as now for the near future?
>

Correct.  No changes to armv7 support are planned. It's better maintained
than armv6 and has a much wider reach. It's still relevant...

Warner

Thanks for reading,
>
> bob prohaska
>
>
>

--00000000000018db9f05efbba60b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Dec 13, 2022, 1:28 PM bob prohaska <fbsd@www.zefox.net> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On Tue, Dec 13, 2022 at 11:57:42AM -0700, War=
ner Losh wrote:

> On Tue, Dec 13, 2022 at 11:48 AM Mark Millard <marklmi@yahoo.com=
> wrote:

> 

> > FYI: The old 2021-Oct-28 message related to armv6 removal

> > sequencing/timing has a new follow up finally:

> >

> > https:=
//lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html

> >

> > (Nothing about this changes the armv7 status.)

> >

> 

> Nope.

> 

> tl;dr: armv6 packages will stop, we'll stop doing -current armv6 s=
napshots,

> we'll move armv6 to

> an 'extra' architecture in universe for stable/14. post stable=
/14 we'll

> tear down support for armv6

> in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 =
of

> them also mention armv7,

> and the vast majority of them mark things as broken in some way (thoug=
h

> there are exceptions).



Apologies if I'm belaboring the obvious, but does that imply armv7

support will go on as now for the near future?
=


Correct.=C2=A0 No changes to =
armv7 support are planned. It's better maintained than armv6 and has a =
much wider reach. It's still relevant...

Warner


Thanks for reading,



bob prohaska








--00000000000018db9f05efbba60b--

From nobody Tue Dec 13 23:24:24 2022
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 4NWvhv38Drz4k5QF
	for ; Tue, 13 Dec 2022 23:24:31 +0000 (UTC)
	(envelope-from Victor.Weinstein@microchip.com)
Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.microchip.iphmx.com", Issuer "*.microchip.iphmx.com" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NWvhs644wz3w6r
	for ; Tue, 13 Dec 2022 23:24:29 +0000 (UTC)
	(envelope-from Victor.Weinstein@microchip.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microchip.com header.s=mchp header.b=igvcqO6v;
	dkim=pass header.d=microchiptechnology.onmicrosoft.com header.s=selector2-microchiptechnology-onmicrosoft-com header.b=FRhNLXUH;
	spf=pass (mx1.freebsd.org: domain of Victor.Weinstein@microchip.com designates 68.232.153.233 as permitted sender) smtp.mailfrom=Victor.Weinstein@microchip.com;
	dmarc=pass (policy=quarantine) header.from=microchip.com;
	arc=pass ("microsoft.com:s=arcselector9901:i=1")
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp;
  t=1670973869; x=1702509869;
  h=from:to:subject:date:message-id:mime-version;
  bh=JBs/R6njcDHBvQ9jtOguhUv43ORbR+GOiCWLzJUYASU=;
  b=igvcqO6vKoExFGvC8mTSYYrqh6Bvvp7JIlyMrn0RiJTOKdGqcTNrN+65
   qIMKHeFVWYVA+2xMM3u/cF6oaX/qdRqdMkBsGDACeulOyFZCvnqVmwOzt
   QmilrLfLwd5aNgTj8nEd59yPrZz2kQ0HOTNHh91NdzpG2Jgd070LrDrdC
   udbAYQtYjHoPnBrc0EapZbvl+ld3sXUGnu3aldHZsCjnBbkMyqTtuzvHQ
   Kk+4H5DOcVltm3H3yqOh85pQ73fJQnRA0O2l/2kpiGGL3sMS8F0cu1NwI
   DrtZhD+v4lQBNZd3Yb53LmlyylLdxfCuGjEIQT4zH0wUHHgAZBXjZ4LPv
   w==;
X-IronPort-AV: E=Sophos;i="5.96,242,1665471600"; 
   d="scan'208,217";a="203908522"
Received: from unknown (HELO email.microchip.com) ([170.129.1.10])
  by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 13 Dec 2022 16:24:26 -0700
Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by
 chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.16; Tue, 13 Dec 2022 16:24:26 -0700
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (10.10.215.89) by
 email.microchip.com (10.10.87.151) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.16 via Frontend Transport; Tue, 13 Dec 2022 16:24:26 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MiKWjgoSvE3FPVO1YGhrJtlOrZYNxpeKRE497+/NFjMto6o/z8+XOKj31kh03ZFpnTKCzbApmdCMZB6B/YtY8KnhOwV9wxfrto1p84WlRR+qakOWfKt8iti9enhJeT/lO/f5OuZO1eLeYsrrjt2CJ+GiyIJxlTk851WfAe76/pz7LmQyA8BSbo3OIIU0SfRoVyijHAm2O6vHnPJFAoq8ZRSakov3uJZhlezQeepHzQGOdiJLheBVIByfi3qoYOW8Fwcw+l5bpawwXQWnL3DaEaBfk6lMcMyZDrfHQQfKxjKfvGo9cbNkVIS0RRIKF5TO9GqfTQORBAF7Ie3oV3mFBQ==
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=JBs/R6njcDHBvQ9jtOguhUv43ORbR+GOiCWLzJUYASU=;
 b=kUPSYdemQecGfcDEVG5l4L6OD/N3fKk+RE9m5CDtgrh5lShVpkumcSOhmpPoekgEz9MD6Qko0t7Njpu0dJ0s45TWfiNYvqTJsTQqtPmpIagDlfpWA5aFIr/unOL+cmrGPRmZnUNM+QbrYp9WPghi000dVgLwjdEfsZle87TOVs3PaoUOkiLe0qtLR51w4jmr6DFROjEwmP+K4yFcisXdkHPd1yjX2TXaSol005/Zf2Yw6nlRDdbAwcToOldCZM128MoxXYHpQWuagKd1uMDHg0lHcid4dmxhqpB92cyv149uYqoAKO3qqgGBIBl4KPejc6VQqqba45twQj/JLnoayg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=microchip.com; dmarc=pass action=none
 header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=microchiptechnology.onmicrosoft.com;
 s=selector2-microchiptechnology-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=JBs/R6njcDHBvQ9jtOguhUv43ORbR+GOiCWLzJUYASU=;
 b=FRhNLXUHbdwen+wiN6zWMlP4a/S9c2R8HitB/wsOR78PKGFtj6qVt7hsYYsfTcX0TTij8lIvs4ivLBtVH6h1JxNTNSdKuR7kqY0RpSK5vQ9TWV2dX+1wHRAMB4Y28nZgbM8F39qZHW3cjoPiBvs2EesyNq8q4Rwqk2nBgy6VlLk=
Received: from CY4PR11MB0070.namprd11.prod.outlook.com (2603:10b6:910:78::16)
 by BN9PR11MB5513.namprd11.prod.outlook.com (2603:10b6:408:102::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.19; Tue, 13 Dec
 2022 23:24:24 +0000
Received: from CY4PR11MB0070.namprd11.prod.outlook.com
 ([fe80::16d6:fbe8:e0ae:32e2]) by CY4PR11MB0070.namprd11.prod.outlook.com
 ([fe80::16d6:fbe8:e0ae:32e2%7]) with mapi id 15.20.5880.019; Tue, 13 Dec 2022
 23:24:24 +0000
From: 
To: 
Subject: FreeBSD support for Nitrogen 8M Plus SOM and EVK carrier board
Thread-Topic: FreeBSD support for Nitrogen 8M Plus SOM and EVK carrier board
Thread-Index: AQHZD0jNrvYCCH2FIky9A6pGAJ1Euw==
Date: Tue, 13 Dec 2022 23:24:24 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CY4PR11MB0070:EE_|BN9PR11MB5513:EE_
x-ms-office365-filtering-correlation-id: ec34554b-0761-402a-2295-08dadd612bd6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ni6MDoeYSfyq6SoSrJbiZ2fMnD19XKszt9cs/y2kGFZiUewM0lG971lXuHqZI92SYolpWf7S7ZcrAtMxePFocKRlZ2rA1XElOKGIpYAz8+lU6W2w9v547O4Yrm430TDuR7c389Msl18aA+UY+lIV3KuiVHwbbGcoKXMQwmxfssYQD0tyviXoMUWgw2Z54w/M8GZxLkhpQa2YBCSFipDoYOvCEFudaR7M4Btts6YQbbHdB/ESNBykgnn7L+FbhITS3g4W3OgtV0kLbDFnOUtdtMm7OUXTeYVoqPLMFkTVHnv2lDJpGeioWQdsX7i1HhpV7qWVx5tjgXiEe3Hh/P/vN94DTn0OctlFktOEu7CeJSaX4nDcnGtv+YTmtO0iQcD143uEAJrUQKg+On/7/AYasxkO9nCWwBtwJv2EIb0wiI8dlNXEy5uzODDMs/HtGTG+hXYen1cEn/vMmOfcE6nqIs+c3JZZkKk8rko1wFZ3SXcgdgtFuUI2R9qxXnLqmvL8k64qqVVNs53rODDkPQxk6UxwwymX1aDwy7aAo/UOaYPy00ID1746z6PnH1iieYfgYJQmH4p1dhmwbxusb/EMU4IfFCTC1eCh1chkBtSe9R7oeVWbbgnqNRoAWgDvJAAihCjJExR/MfjSsnI7BPDmrtm2RCR2upb08ofuV6TfGWwUBNSh4tt8VikAmc+zStCko5I771f95CzP28JI4V8H7OaEP+Df5lWtffw3z2nGE1Q=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CY4PR11MB0070.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(366004)(396003)(346002)(376002)(39860400002)(136003)(451199015)(91956017)(66946007)(66556008)(76116006)(66446008)(66476007)(6506007)(8676002)(64756008)(186003)(5660300002)(38070700005)(52536014)(71200400001)(83380400001)(8936002)(7696005)(6916009)(86362001)(966005)(478600001)(41300700001)(26005)(33656002)(316002)(9686003)(166002)(2906002)(55016003)(19627405001)(122000001)(38100700002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VkkycXorWjZNTWw4b3F1d1pxYjdwVzRkeUVUS3NrY3RTV21DdnJ3bUg3NVAx?=
 =?utf-8?B?eEkzRnRLbU5yRlRKSm4zaTQvd3N4bUNuTTkvR25XSlpMRjBoUTAyT2o0S3VY?=
 =?utf-8?B?aEJPWm42dVFTVnJYekRkKzFjeGxzWE5YeitrUm5Ta3QrSXlaemNrS25PeTZO?=
 =?utf-8?B?V0Nac0t4cGVqc0w0a0txV0pic2JLKzVXSmViYXFBOERYNU4xR3lVYU5kSmZx?=
 =?utf-8?B?WSt4ZzJZMUdOWlpYcDRHNE4wS3NBTG1zUVI1RlpaVnEzaFJaOVpKL1Z2UGFW?=
 =?utf-8?B?WWVmZElTYWZid0ZxMHJTS3hUZ3ZwdFJQYTdZNjk0dldUdjd1UzZMaiszQ09m?=
 =?utf-8?B?S3lYRy9obkJpcGE2Mit1TzdRaUxKc2FpamtoU2xiTFFlK2t4QzI2MjRTZkwr?=
 =?utf-8?B?ZDRzL25pUzg3ZHlVSmNmdy9BanJjbWl1eXVFV0g0elN1Ykx1V2NWQUNZaFNT?=
 =?utf-8?B?VmgyRVJ0RW5xY0JNSlovdTBzUGhNMEdoZHM1SWlzTGdMN1hQeUJYOTRqTnJH?=
 =?utf-8?B?RXlnQWpoclF5dW5Zc0hIbHB5OHhDWG5ka0pva2s0K2lQc0RwZWg0cnBKVUt5?=
 =?utf-8?B?aEt5SXlZakJaS09hb3BxR2thR1UyZnJ2OHdiYkJCTlFPenNVbTZIK1lNSUFE?=
 =?utf-8?B?dW8rT0xHakxFM0lPc2xXL2oyNVVTNWJGR29ybkNYbHhoS29SM2w3WG8wRjhN?=
 =?utf-8?B?aU1HUDJ1aHRIbk5wQ2ZWMEtrekNMa2JrMWZiUjdJSjUwVXV1RDZyRWlhbUds?=
 =?utf-8?B?M2xIbVJxWUNqV2tPQ3hGZjcxcmU0N05wM284dkowUjQ1a3Z4UnV5ZE9wdS9Y?=
 =?utf-8?B?VE5xdnVwRVdOV0lsQnlyMmRvNjRZb3pMV2ZGQWVvMm16eEk5eDZzejdPTXV1?=
 =?utf-8?B?YUVOWFM0c1E3UmhPaVkzN0JFSEUvUTgxZUhpSHE5T1VJRzJjMW1FV255ajYv?=
 =?utf-8?B?RFRiMVA1TGd3V2RITktVSGhVNFlSRG44Y3NtWGRTamJtTFVRY0NnOTdzNVJj?=
 =?utf-8?B?WENqNWxJQVpnTG1mMVdVNFRVNTVIdDI0V0c2SGVxUkhlV3BzNHpaWGFnS1Bm?=
 =?utf-8?B?Rnl6SzZRaUkzdVBzaXZ4Z1NBL01mMWt2dTcva0hHQnFXNWtaMXp5V1NKMHZt?=
 =?utf-8?B?UHQzUXordUJUWjcweWhCZzg5QkNUUTJCbHVxbkgzN29ZWjhoNElONmFNODRK?=
 =?utf-8?B?NzVIVU85RG4zTUU0QU5ZUjNLN2FMU2JCd3B1bGhvdlc1ZTgvZHYya0g0REpn?=
 =?utf-8?B?QVVXbHdKNTZ0MS9uL1FFbHN2L1dKUVRZMUcrM3pHQ2NndC9hdDdNaEI2Y0E2?=
 =?utf-8?B?ZFF0eWJZNVFERDRlL2ZvNktMK2tUOFZIcU9Pd0Z3bEhXNTVpS2c1RGg2Ryt0?=
 =?utf-8?B?c3V2ZVRwU3RiRmtwaTRLUDUzczNSeVBmcSttT0t3RVBmbjEva1BqQU14cG0z?=
 =?utf-8?B?eWVJak1BQml4dzZEUk84RGJpQ2xXRkRLVDI0RnpjYm11b2ppSytpTy8yUHUz?=
 =?utf-8?B?bXhCcS9oTkRUSnkwREhQaUFpZ0ltaW1qdldjdUhXVDUwQ21ldTV1dmFvNUhK?=
 =?utf-8?B?NFFHb0pjdjVXUEJadG5HTTJSaHNFRG9tZWFOeHFzYkE3UnZZZEZvZGhHREtE?=
 =?utf-8?B?cE8wN1YrVmZoMjdlV0FyYWx6NFV6VlBpWUJ1L09yQVhSWnozVER1cHN0U2px?=
 =?utf-8?B?bTBJVGo1alMxbU0veHNmMGNSWmxRSHIzUEJxc3dVT2VUeFdKKzZHSU5TandL?=
 =?utf-8?B?NTRZRG9oeVhVNEZndW1lNytIT2RMNlZZL0x2T3hXSzk0RHZlcjFRV2dvaGNt?=
 =?utf-8?B?bFpOb2FXU0czakZWMnV5cmpHQ3RZd082L3M4QVAya2xEeE5EeGEvS1lRd2hQ?=
 =?utf-8?B?TFZWb0lBbGZzM0Vtdi8rbnFwRWZyR0s3RnVTM3RzcDBRWDhsM0R0S0Nrc2tV?=
 =?utf-8?B?RDQzZHp6T1B4M2FoZklibjJrL2hlTXN1ZlVIanVNc3FQdVQvMnpoRzBjdlhh?=
 =?utf-8?B?eFVVdHpleWphM0JTeGQ4dGl6VWxJb09kSXoyU1ZQditiUnYwUzZZbm5yOGdQ?=
 =?utf-8?B?OGZ1MDIwVUJhdDlNMTkrSTU2ZTN4YldsR0dBZXBxc21mOE0rOTcwZmQrRC8v?=
 =?utf-8?B?ZE5ENm9GL01XTjRUVlpobTN6K2tuZlVlR0NmeDRKR2JlUndmbTNOUHh3T00y?=
 =?utf-8?B?Umc9PQ==?=
Content-Type: multipart/alternative;
	boundary="_000_CY4PR11MB00702C74C0D9E857E15B0FB296E39CY4PR11MB0070namp_"
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: CY4PR11MB0070.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ec34554b-0761-402a-2295-08dadd612bd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2022 23:24:24.2897
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dEhGREFKI1CwKBEI+hW9HFWChMoiBNS2kzgUPGLqaJuTJWSkBXfpHJ1QdNLPwGfJSrX3ZKGAN2g0IxJTTNHoGnBz/QQl8WJ5W7s0mC5Z5xQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5513
X-Spamd-Result: default: False [-5.60 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[microchip.com,quarantine];
	RCVD_IN_DNSWL_MED(-0.20)[68.232.153.233:from];
	R_DKIM_ALLOW(-0.20)[microchip.com:s=mchp,microchiptechnology.onmicrosoft.com:s=selector2-microchiptechnology-onmicrosoft-com];
	R_SPF_ALLOW(-0.20)[+exists:68.232.153.233.spf.microchip.iphmx.com];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:16417, ipnet:68.232.153.0/24, country:US];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_FIVE(0.00)[6];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FROM_NO_DN(0.00)[];
	DKIM_TRACE(0.00)[microchip.com:+,microchiptechnology.onmicrosoft.com:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[68.232.153.233:from]
X-Rspamd-Queue-Id: 4NWvhs644wz3w6r
X-Spamd-Bar: -----
X-ThisMailContainsUnwantedMimeParts: N

--_000_CY4PR11MB00702C74C0D9E857E15B0FB296E39CY4PR11MB0070namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8sDQoNCkkgaGF2ZSBhIEJvdW5kYXJ5IGRldmljZXMgTml0cm9nZW4gOE0gUGx1cyBTT00g
aW5zdGFsbGVkIG9uIGEgTml0cm9nZW4gOE0gUGx1cyBFVksgY2FycmllciBib2FyZCwgYW5kIEkg
d291bGQgbGlrZSB0byBnZXQgRnJlZUJTRCBydW5uaW5nIG9uIHRoaXMgc3lzdGVtLiAgSXQgYXBw
ZWFycyB0aGF0IHRoZXJlIGlzIHN1cHBvcnQgZm9yIHRoZSBpbXg4IHByb2Nlc3NvciBpbiB0aGUg
RnJlZUJTRCBzb3VyY2UgdHJlZSwgZS5nLg0KDQoiY29tbWl04oCC4oCC4oCC4oCC4oCC4oCCOTRi
YzIxMTdiNGFkYWY3MTAxY2M0MTJmNDI3N2U1ODEyYWQ2MWFlMiAocGF0Y2gpDQpBZGQgaS5NWCA4
TSBRdWFkIHN1cHBvcnQNCi0gQWRkIENDTSBkcml2ZXIgYW5kIGNsb2NrcyBpbXBsZW1lbnRhdGlv
bnMgZm9yIGkuTVggOE0NCi0gQWRkIEdQQyBkcml2ZXIgZm9yIGlNWDgNCi0gQWRkIGNsb2NrIHRy
ZWUgZm9yIGkuTVggOE0gUXVhZA0KLSBBZGQgY2xvY2tzIHN1cHBvcnQgYW5kIG5ldyBjb21wYXQg
c3RyaW5ncyAod2hlcmUgcmVxdWlyZWQpIGZvciBleGlzdGluZyBpLk1YIDYgVUFSVCwgSTJDLCBh
bmQgR1BJTyBkcml2ZXJzDQotIEVuYWJsZSBhYXJjaDY0LWNvbXBhdGlibGUgZHJpdmVycyBmb3Jt
IGkuTVggNiBpbiBhcm02NCBHRU5FUklDIGtlcm5lbCBjb25maWcNCi0gQWRkIGR0Yi9pbXg4IGtl
cm5lbCBtb2R1bGUgd2l0aCBEVEJzIGZvciBOaXRyb2dlbjhNIGFuZCBpTVg4TVEgRVZLDQoNCldp
dGggdGhpcyBwYXRjaCBib3RoIE5pdHJvZ2VuOE0gYW5kIGlNWDhNUSBFVksgYm9vdCB3aXRoIE5G
UyByb290IHVwIHRvIG11bHRpdXNlciBsb2dpbiBwcm9tcHQiDQoNCmFuZCBpbiB1LWJvb3QNCmh0
dHBzOi8vZ2l0aHViLmNvbS9lZHdpbmxhaWt0Yy9pTVg4L2Jsb2IvbWFzdGVyL3Vib290L1JFQURN
RQ0KDQppTVg4L1JFQURNRSBhdCBtYXN0ZXIgwrcgZWR3aW5sYWlrdGMvaU1YOCDCtyBHaXRIdWIN
CmlNWDhtcS1ldmsgYm9hcmQsIHVib290LCBrZXJuZWwsIGJ1c3lib3ggY29tYmluYXRpb24gLSBp
TVg4L1JFQURNRSBhdCBtYXN0ZXIgwrcgZWR3aW5sYWlrdGMvaU1YOA0KZ2l0aHViLmNvbQ0K7pyR
DQoNCkkgZm91bmQgdGhlIGZvbGxvd2luZyBhYXJjaDY0IEZyZWVCU0QxMyBpbWFnZXMgZnRwIHNp
dGUgd2hpY2ggZG9lc24ndCBleHBsaWNpdGx5IGlkZW50aWZ5IGEgZGlzayBpbWFnZSBmb3IgdGhl
IGlteDggcHJvY2Vzc29yICh0aG91Z2ggcGVyaGFwcyB0aGUgOg0KaHR0cHM6Ly9kb3dubG9hZC5m
cmVlYnNkLm9yZy9mdHAvcmVsZWFzZXMvYXJtNjQvYWFyY2g2NC9JU08tSU1BR0VTLzEzLjEvDQpJ
bmRleCBvZiAvZnRwL3JlbGVhc2VzL2FybTY0L2FhcmNoNjQvSVNPLUlNQUdFUy8xMy4xLyAtIEZy
ZWVCU0Q8aHR0cHM6Ly9kb3dubG9hZC5mcmVlYnNkLm9yZy9mdHAvcmVsZWFzZXMvYXJtNjQvYWFy
Y2g2NC9JU08tSU1BR0VTLzEzLjEvPg0KRmlsZSBOYW1lIOKGkyBGaWxlIFNpemUg4oaTIERhdGUg
4oaTIDsgUGFyZW50IGRpcmVjdG9yeS8tLUNIRUNLU1VNLlNIQTI1Ni1GcmVlQlNELTEzLjEtUkVM
RUFTRS1hcm02NC1hYXJjaDY0OiAxMjUxOiAyMDIyLU1heS0xMiAxMTowNTogQ0hFQ0tTVU0uU0hB
MjU2LUZyZWVCU0QtMTMuMS1SRUxFQVNFLWFybTY0LWFhcmNoNjQtUElORTY0DQpkb3dubG9hZC5m
cmVlYnNkLm9yZw0KSSBhbHNvIGZvdW5kIGEgd2lraS5mcmVlYnNkLm9yZyBzaXRlIGZvciB0aGUg
UmFzcGJlcnJ5IFBpICh3aGljaCBhbHNvIHJlZmVycyB0byB0aGUgYWFyY2g2NCBmdHAgcmVsZWFz
ZSBzaXRlKToNCmh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9hcm0vUmFzcGJlcnJ5JTIwUGkNCg0K
Q2FuIGFueW9uZSBwb2ludCBtZSB0byBvciBwcm92aWRlIG1lIHdpdGggaW5mb3JtYXRpb24gb24g
aW5zdGFsbGluZyBhbmQgYm9vdGluZyBhIHN1aXRhYmxlIGRpc2sgaW1hZ2U/DQoNClRoYW5rcyBm
b3IgeW91ciBoZWxwLA0KVmljdG9yDQo=

--_000_CY4PR11MB00702C74C0D9E857E15B0FB296E39CY4PR11MB0070namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9
ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImVsZW1lbnRUb1Byb29m
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNh
bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu
ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5IZWxs
byw8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJlbGVtZW50VG9Qcm9vZiI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NTUsIDI1NSwgMjU1KTsiIGNsYXNzPSJDb250ZW50UGFzdGVkMCBlbGVtZW50VG9Qcm9vZiI+PGJy
Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iZWxlbWVudFRvUHJvb2YiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io
MjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iQ29udGVudFBhc3RlZDAgZWxlbWVudFRvUHJvb2YiPkkg
aGF2ZSBhIEJvdW5kYXJ5IGRldmljZXMgTml0cm9nZW4gOE0gUGx1cyBTT00gaW5zdGFsbGVkDQog
b24gYSBOaXRyb2dlbiA4TSBQbHVzIEVWSyBjYXJyaWVyIGJvYXJkLCBhbmQgSSB3b3VsZCBsaWtl
IHRvIGdldCBGcmVlQlNEIHJ1bm5pbmcgb24gdGhpcyBzeXN0ZW0uICZuYnNwO0l0IGFwcGVhcnMg
dGhhdCB0aGVyZSBpcyBzdXBwb3J0IGZvciB0aGUgaW14OCBwcm9jZXNzb3IgaW4gdGhlIEZyZWVC
U0Qgc291cmNlIHRyZWUsIGUuZy4NCjxkaXY+PGJyIGNsYXNzPSJDb250ZW50UGFzdGVkMCI+DQo8
L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj4mcXVvdDtjb21taXTigILigILigILi
gILigILigII5NGJjMjExN2I0YWRhZjcxMDFjYzQxMmY0Mjc3ZTU4MTJhZDYxYWUyIChwYXRjaCk8
L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5BZGQgaS5NWCA4TSBRdWFkIHN1cHBv
cnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj4tIEFkZCBDQ00gZHJpdmVyIGFu
ZCBjbG9ja3MgaW1wbGVtZW50YXRpb25zIGZvciBpLk1YIDhNPC9kaXY+DQo8ZGl2IGNsYXNzPSJD
b250ZW50UGFzdGVkMCI+LSBBZGQgR1BDIGRyaXZlciBmb3IgaU1YODwvZGl2Pg0KPGRpdiBjbGFz
cz0iQ29udGVudFBhc3RlZDAiPi0gQWRkIGNsb2NrIHRyZWUgZm9yIGkuTVggOE0gUXVhZDwvZGl2
Pg0KPGRpdiBjbGFzcz0iQ29udGVudFBhc3RlZDAiPi0gQWRkIGNsb2NrcyBzdXBwb3J0IGFuZCBu
ZXcgY29tcGF0IHN0cmluZ3MgKHdoZXJlIHJlcXVpcmVkKSBmb3IgZXhpc3RpbmcgaS5NWCA2IFVB
UlQsIEkyQywgYW5kIEdQSU8gZHJpdmVyczwvZGl2Pg0KPGRpdiBjbGFzcz0iQ29udGVudFBhc3Rl
ZDAiPi0gRW5hYmxlIGFhcmNoNjQtY29tcGF0aWJsZSBkcml2ZXJzIGZvcm0gaS5NWCA2IGluIGFy
bTY0IEdFTkVSSUMga2VybmVsIGNvbmZpZzwvZGl2Pg0KPGRpdiBjbGFzcz0iQ29udGVudFBhc3Rl
ZDAiPi0gQWRkIGR0Yi9pbXg4IGtlcm5lbCBtb2R1bGUgd2l0aCBEVEJzIGZvciBOaXRyb2dlbjhN
IGFuZCBpTVg4TVEgRVZLPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iQ29udGVudFBhc3RlZDAiPg0K
PC9kaXY+DQo8ZGl2IGNsYXNzPSJDb250ZW50UGFzdGVkMCI+V2l0aCB0aGlzIHBhdGNoIGJvdGgg
Tml0cm9nZW44TSBhbmQgaU1YOE1RIEVWSyBib290IHdpdGggTkZTIHJvb3QgdXAgdG8gbXVsdGl1
c2VyIGxvZ2luIHByb21wdCZxdW90OzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IkNvbnRlbnRQYXN0
ZWQwIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iQ29udGVudFBhc3RlZDAiPmFuZCBpbiB1LWJvb3Q8
L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5odHRwczovL2dpdGh1Yi5jb20vZWR3
aW5sYWlrdGMvaU1YOC9ibG9iL21hc3Rlci91Ym9vdC9SRUFETUU8L2Rpdj4NCjxkaXY+PGJyIGNs
YXNzPSJDb250ZW50UGFzdGVkMCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQw
Ij5pTVg4L1JFQURNRSBhdCBtYXN0ZXIgwrcgZWR3aW5sYWlrdGMvaU1YOCDCtyBHaXRIdWI8L2Rp
dj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5pTVg4bXEtZXZrIGJvYXJkLCB1Ym9vdCwg
a2VybmVsLCBidXN5Ym94IGNvbWJpbmF0aW9uIC0gaU1YOC9SRUFETUUgYXQgbWFzdGVyIMK3IGVk
d2lubGFpa3RjL2lNWDg8L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5naXRodWIu
Y29tPC9kaXY+DQo8ZGl2IGNsYXNzPSJDb250ZW50UGFzdGVkMCI+7pyRPC9kaXY+DQo8ZGl2Pjxi
ciBjbGFzcz0iQ29udGVudFBhc3RlZDAiPg0KPC9kaXY+DQo8ZGl2PkkgZm91bmQgdGhlIGZvbGxv
d2luZyBhYXJjaDY0IEZyZWVCU0QxMyBpbWFnZXMgZnRwIHNpdGUgd2hpY2ggZG9lc24ndCBleHBs
aWNpdGx5IGlkZW50aWZ5IGEgZGlzayBpbWFnZSBmb3IgdGhlIGlteDggcHJvY2Vzc29yICh0aG91
Z2ggcGVyaGFwcyB0aGUgOjwvZGl2Pg0KPGRpdiBjbGFzcz0iQ29udGVudFBhc3RlZDEiPjxhIGhy
ZWY9Imh0dHBzOi8vZG93bmxvYWQuZnJlZWJzZC5vcmcvZnRwL3JlbGVhc2VzL2FybTY0L2FhcmNo
NjQvSVNPLUlNQUdFUy8xMy4xLyIgaWQ9IkxQbG5rT1dBTGlua1ByZXZpZXciPmh0dHBzOi8vZG93
bmxvYWQuZnJlZWJzZC5vcmcvZnRwL3JlbGVhc2VzL2FybTY0L2FhcmNoNjQvSVNPLUlNQUdFUy8x
My4xLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9Il9FbnRpdHkgX0VUeXBlX09XQUxpbmtQcmV2aWV3
IF9FSWRfT1dBTGlua1ByZXZpZXcgX0VSZWFkb25seV8xIj4NCjxkaXYgaWQ9IkxQQm9yZGVyX0dU
YUhSMGNITTZMeTlrYjNkdWJHOWhaQzVtY21WbFluTmtMbTl5Wnk5bWRIQXZjbVZzWldGelpYTXZZ
WEp0TmpRdllXRnlZMmcyTkM5SlUwOHRTVTFCUjBWVEx6RXpMakV2IiBjbGFzcz0iTFBCb3JkZXI1
MjY2NTQiIHN0eWxlPSJ3aWR0aDogMTAwJTsgbWFyZ2luLXRvcDogMTZweDsgbWFyZ2luLWJvdHRv
bTogMTZweDsgcG9zaXRpb246IHJlbGF0aXZlOyBtYXgtd2lkdGg6IDgwMHB4OyBtaW4td2lkdGg6
IDQyNHB4OyI+DQo8dGFibGUgaWQ9IkxQQ29udGFpbmVyNTI2NjU0IiByb2xlPSJwcmVzZW50YXRp
b24iIHN0eWxlPSJwYWRkaW5nOiAxMnB4IDM2cHggMTJweCAxMnB4OyB3aWR0aDogMTAwJTsgYm9y
ZGVyLXdpZHRoOiAxcHg7IGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogcmdiKDIw
MCwgMjAwLCAyMDApOyBib3JkZXItcmFkaXVzOiAycHg7Ij4NCjx0Ym9keT4NCjx0ciB2YWxpZ249
InRvcCIgc3R5bGU9ImJvcmRlci1zcGFjaW5nOiAwcHg7Ij4NCjx0ZCBzdHlsZT0id2lkdGg6IDEw
MCU7Ij4NCjxkaXYgaWQ9IkxQVGl0bGU1MjY2NTQiIHN0eWxlPSJmb250LXNpemU6IDIxcHg7IGZv
bnQtd2VpZ2h0OiAzMDA7IG1hcmdpbi1yaWdodDogOHB4OyBmb250LWZhbWlseTogd2Zfc2Vnb2Ut
dWlfbGlnaHQsICZxdW90O1NlZ29lIFVJIExpZ2h0JnF1b3Q7LCAmcXVvdDtTZWdvZSBXUCBMaWdo
dCZxdW90OywgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O1NlZ29lIFdQJnF1b3Q7LCBUYWhv
bWEsIEFyaWFsLCBzYW5zLXNlcmlmOyBtYXJnaW4tYm90dG9tOiAxMnB4OyI+DQo8YSB0YXJnZXQ9
Il9ibGFuayIgaWQ9IkxQVXJsQW5jaG9yNTI2NjU0IiBocmVmPSJodHRwczovL2Rvd25sb2FkLmZy
ZWVic2Qub3JnL2Z0cC9yZWxlYXNlcy9hcm02NC9hYXJjaDY0L0lTTy1JTUFHRVMvMTMuMS8iIHN0
eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiB2YXIoLS10aGVtZVByaW1hcnkpOyIg
ZGF0YS1sb29wc3R5bGU9ImxpbmsiPkluZGV4IG9mIC9mdHAvcmVsZWFzZXMvYXJtNjQvYWFyY2g2
NC9JU08tSU1BR0VTLzEzLjEvDQogLSBGcmVlQlNEPC9hPjwvZGl2Pg0KPGRpdiBpZD0iTFBEZXNj
cmlwdGlvbjUyNjY1NCIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgbWF4LWhlaWdodDogMTAwcHg7
IGNvbG9yOiByZ2IoMTAyLCAxMDIsIDEwMik7IGZvbnQtZmFtaWx5OiB3Zl9zZWdvZS11aV9ub3Jt
YWwsICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAmcXVvdDtTZWdvZSBXUCZxdW90OywgVGFob21hLCBB
cmlhbCwgc2Fucy1zZXJpZjsgbWFyZ2luLWJvdHRvbTogMTJweDsgbWFyZ2luLXJpZ2h0OiA4cHg7
IG92ZXJmbG93OiBoaWRkZW47Ij4NCkZpbGUgTmFtZSDihpMgRmlsZSBTaXplIOKGkyBEYXRlIOKG
kyA7IFBhcmVudCBkaXJlY3RvcnkvLS1DSEVDS1NVTS5TSEEyNTYtRnJlZUJTRC0xMy4xLVJFTEVB
U0UtYXJtNjQtYWFyY2g2NDogMTI1MTogMjAyMi1NYXktMTIgMTE6MDU6IENIRUNLU1VNLlNIQTI1
Ni1GcmVlQlNELTEzLjEtUkVMRUFTRS1hcm02NC1hYXJjaDY0LVBJTkU2NDwvZGl2Pg0KPGRpdiBp
ZD0iTFBNZXRhZGF0YTUyNjY1NCIgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC13ZWlnaHQ6
IDQwMDsgY29sb3I6IHJnYigxNjYsIDE2NiwgMTY2KTsgZm9udC1mYW1pbHk6IHdmX3NlZ29lLXVp
X25vcm1hbCwgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O1NlZ29lIFdQJnF1b3Q7LCBUYWhv
bWEsIEFyaWFsLCBzYW5zLXNlcmlmOyI+DQpkb3dubG9hZC5mcmVlYnNkLm9yZzwvZGl2Pg0KPC90
ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC9kaXY+DQpJIGFsc28gZm91
bmQgYSB3aWtpLmZyZWVic2Qub3JnIHNpdGUgZm9yIHRoZSBSYXNwYmVycnkgUGkgKHdoaWNoIGFs
c28gcmVmZXJzIHRvIHRoZSBhYXJjaDY0IGZ0cCByZWxlYXNlIHNpdGUpOjwvc3Bhbj48L2Rpdj4N
CjxkaXYgY2xhc3M9ImVsZW1lbnRUb1Byb29mIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENh
bGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29s
b3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIg
Y2xhc3M9IkNvbnRlbnRQYXN0ZWQwIGVsZW1lbnRUb1Byb29mIENvbnRlbnRQYXN0ZWQyIj48YSBo
cmVmPSJodHRwczovL3dpa2kuZnJlZWJzZC5vcmcvYXJtL1Jhc3BiZXJyeSUyMFBpIiBpZD0iTFBs
bms5MzQ5NjQiPmh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9hcm0vUmFzcGJlcnJ5JTIwUGk8L2E+
PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iZWxlbWVudFRvUHJvb2YiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z
aXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1
LCAyNTUsIDI1NSk7IiBjbGFzcz0iQ29udGVudFBhc3RlZDAgZWxlbWVudFRvUHJvb2YgQ29udGVu
dFBhc3RlZDIiPjxicj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5DYW4gYW55b25lIHBv
aW50IG1lIHRvIG9yIHByb3ZpZGUgbWUgd2l0aCBpbmZvcm1hdGlvbiBvbiBpbnN0YWxsaW5nIGFu
ZCBib290aW5nIGEgc3VpdGFibGUgZGlzayBpbWFnZT88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSJD
b250ZW50UGFzdGVkMCI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkNvbnRlbnRQYXN0ZWQwIj5UaGFu
a3MgZm9yIHlvdXIgaGVscCw8L2Rpdj4NClZpY3Rvcjxicj4NCjwvc3Bhbj48L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_CY4PR11MB00702C74C0D9E857E15B0FB296E39CY4PR11MB0070namp_--

From nobody Wed Dec 14 06:45:14 2022
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 4NX5Tl4S6Vz4l24H
	for ; Wed, 14 Dec 2022 06:45:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 4NX5Tk5QHDz3l6G
	for ; Wed, 14 Dec 2022 06:45:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=W9k7vulW;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.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=1671000328; bh=0+M0uj6RT+op36ymfCjGON/IoSTA3+ln3wwL+p3Z7ns=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=W9k7vulWTGoHAebRh8XvT57NVsdX4vBtBhqrJw/aLxMvCGWniVNt5CM7SbcpPlWZv3bASI14bCAkGrk+8meV+A048mPWkmyBIlXygBQyDr1Oa9mr28wsuqCWbijXVSKirZWcbjKf7Qb2pe/BqqYGq1FpccWzD8v+IX71Eoc9mn6iDyfQqkTPMVG6NsesQWEUcjJF4CzpdtYh6hH6qGg7zFgwyzFSRZIGN4GVj69zz9FahtOlnLBg8VUHSJyRUlW5vvA0Crx/YdNAfFdrHSiC2//O3UZ60jkJ5qFXc6TJnz7xcO/VZ9lDAhoYzjOOnwKViqsZl7aOG4bbASY2qKu3bQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671000328; bh=VbfWuo4TmssOjEJA3LXdhaHLFuXEuVsZsdtm4KJCNyJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RBMeeoc4oQi5NuxaYnrmy+SCxx+Yg7JRvv7Txcz2/1UBI/6yW2ix54CCRDGnAEheHK3X8G/XxZWV/PMqMwYpkyZpS7vEUZNXA0XoalS5ceCNkPQe+nIIeHDzgVHGJlkR0BHwlZb3iyhJIEI8mTMH/r06Aqc6ukLvJZPgo74O/GepQ9QjPfks6/utDJIy10mbdEEO48J49uqkwBakRXNXAfPFvK7e4X0ef1oF1P/qXOGNgPu3HNu5pcrzUt7DavLTO1ZPAlskqgwgGbD9aorP6Y9/OPMrFLAi+smUs2rx6qQ9LWyr4c4cv54CXN5MRFFirSssFikCjg+qYiXSWoWsdw==
X-YMail-OSG: CL1U7LUVM1kKWcTDqvjnccurlqMhfVwvTdmAqivP5fEm82nCVE3AtqJYVGHa364
 VAj6.JC3cNMimeNTNUKGJChBmu_pX0rCYL.IzBl_pnqyv4dE0HRXLDhZpDL6FDvKZws5PJL93U1O
 QfWXJigN78SwljNu4uSDNZnjhx3Ickn0ytNrJa8DEViZCN4BsbwsYFu5ujQ7cPgSwQozwt6ms6gv
 W4chOvmR4iPF3QspSBVAMreLp4jRhrSwoLH.qDk1qZzXowGhvN6S7xu3umbMxNfOkh5Je9jJtEWX
 _SaUQ8JzngLenlBrJnifJlfWcpQ_7ebTJ1BL9B.mky04Zm6c._ZCZV1I1bkHrGbqevqB3oPbvJWl
 wQ5DRh4V5DOPKGGOE6jvJrq7pkD82BaKdSgE6oc4JtLMWWU77yBHvCsjaQGGMtub9D561fMUzu71
 lknhb47CTgxaR8PHHSqZNfhxDr_B6IZutSmd_B6HrlPY4pVlBLFfjyyoLsZ2gvbJB0hx9O98Up1h
 rIl6cFvJjzkrfRfe2u0ppYa5ZgOQQS6uU6et147c6EmVRUPPKzs.h2ZB7zRVqp53d4nILNctyHBQ
 epwuIiEgqU4CFI7Ba.El1usynlMBG1gnao4WUa3MNig0yXvUt8Ou6AdOg5RGnhDkPAHg2KI.zCpJ
 ig8iwwJ.ByJHN55.EevCXy6dQfq5yIeDv.5P0QQhtffrjSmu4tLqQMsYnmLprdwIqndxhidUrUil
 bHAzWni0zlDrlQfBzNz6eBdzxVwBOg76NzL._k.WgFyctQSyasRkqJa12jNenI7_QHcqnUUoKmpa
 tDEnGhMRlt9MxOIWsxBd8jYxZRlCnslGIJ9GeWQS566Ay0wedKLhsAbeQiP26iGSrB3oPYWwsG_r
 g1aTW2yCtvKo9LOLETaehH4c2nve9K1pkjGy5EsezwU.BdUd4PKSbTpPi.k5EexZXrKM8Pe0jLNP
 vFrONR1r2ngTy51XJRCF75dfTitq5XnASzLZDY9HcrHBvO7A8M1j98XG.GQiZC_hS_BzAhANldhC
 pOBszxsGkDlykHd7QnYOfleIJLmwwNgF3_ooFrLTME76rYDoOHWHAmTKHChCoBpwDaLnjz2mDaV0
 PgvdAMrA5z5GWs7vMlrMnZEkUkGFlb6XZm46uHXqxh.ySe.p3RZtQab2elBxAV7a8Nj7FG4onwDH
 ZHbPZkCA_gccTOurES_iT2yS9888KvvPnbu8JuXrWTZBUcCRo8MevDYEEELNu6alqL.30_Omrsg4
 OW7yHjzyTtg0gTZUIVs0eYs.M7fA7ttf2pcHMWTeIDYI3JOTFvGIb_eVnQSI1g2HD15VgkqGz.RS
 q2ZYj7qRr32_vfKiwJ.ED5OppnoIlnpjFao0QUiH6TpQGh5PHViwQE48th6s9vWXk_J8CxHOu4b8
 fKRs04fEskCevciKQG0CDRlljgxmzh2klpWCKEBFVEXMnzdjz0uv6f5g65iby3XQRAFM0TlXIF3O
 1LAtxb40GZPEyuhjlyRzj63kFZngX5BpZpfXHYIvaqwLL_vYPFR33YGe8RGGWvEcjY5lj1KlsMkE
 aQbpVg_VsH4M9x7n588gP8WtmpSOPzoR0Ri4Oi7I1bWockDEcqGJQfDKGL0WD3GliqQp9k0Z12zk
 .cM51u1vkd73x.biKsdb1QhESTQBKkwX7Mxg_mPupSGXVRP3Y1Ansb0cFi7hpwfgu945KgBL2Y6d
 _uXtYxcM8gfHcAQ1bEa1MCkZRVf3YvvIkAVr8Lm.4KRJ0_Nt9R2jLv55Y2JQ7a6XdfO9cdbUWR1A
 YOkrbq844szL2jiNsnVXrz2.5uVy98aX8zvmtemvDRytdcGwNT.BGapKCPUz5EFYkDr.MMxOJhql
 X0bgPeBlz.00KmsDkEG9V_U2UB8ITCFLxZsXudSrNuYI8kQfkLvC6FZZP7dKeh0bQphkEon0RFu2
 SxemOBfv9zXXBRob.WWJaOdYOAjORs82XqpE4Zg2RBKP4mILPM849grvpC5Djb0273ogX_5roQ8P
 2dZMrjyZJsrjpmTRItutU5y6_zgiiXksVgilYHzwS9qrAAmH.XJqHEnMWTrd4PBSXN40BJ9K1rUc
 OFUKQmzfq1a68lrRajsiPBx_IdV6oYSpx.02m1ALADPkyfrVBwjKrVYIIcCnqyOIfsc3e9CGFbfV
 Mutw7jhs3no6x9TyznkHeU5hY8OBIVHj9AcS7AJK5qR5IfM_W9zN4GZfShYNR2S5m048PSQoFKWk
 nrjn_zZGJcGk888bdzkXMQXKfHXpdsGYUYjovlxUZhTfTfCpVdYtjwU34jvtp4MTMmjSUDNOQ
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Dec 2022 06:45:28 +0000
Received: by hermes--production-gq1-d898c4779-kmgvg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3c7fe901b0250bd508d3f87207f029e5;
          Wed, 14 Dec 2022 06:45:25 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: armv6/armv7/aarch64 vs. FreeBSD images (retitled from an arch reply,
 moving to freebsd-arm list)
Message-Id: 
Date: Tue, 13 Dec 2022 22:45:14 -0800
To: jhs@berklix.com,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Spamd-Result: default: False [-3.38 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.88)[-0.885];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]
X-Rspamd-Queue-Id: 4NX5Tk5QHDz3l6G
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Julian H. Stacey  wrote on
Date: Wed, 14 Dec 2022 02:22:10 UTC :

> Hi, Reference:
>> From: Mark Millard 
>> Date: Tue, 13 Dec 2022 15:52:16 -0800
> 
> . . . 
> 
> Extending wordings associated with each Pi dd image, would be very
> welcome, to specificaly list all hardware version of a Pi each image
> of v6, v7, aarch64, the image should boot.

For FreeBSD support, a U-Boot build that is
compatible is needed. U-Boot is via ports, with
only a few preassembled combinations of U-Boot
variant and FreeBSD produced officially.
(Statements not limited to RPi*'s.) U-Boot
materials are not part of FreeBSD but are
used (even: needed) by FreeBSD.

The RPi* firmware has a similar status: it is a
port: rpi-firmware . It is not part of FreeBSD
itself. A combination of RPi* firmware, U-Boot
varient, and FreeBSD are needed overall.

(The RPi* firmware can adjust some of the 
Device Tree before handing things over to U-Boot.
U-Boot can adjust/add more before handing that
off to the FreeBSD loader. FreeBSD does not
handle all valid Device Trees from what I can
tell --and this limits what range of RPi*
firmware that FreeBSD avoids crashing with.)

What armv6/armv7/aarch64 RPi's there are/have-been,
no matter if a RPi*-firmware/U-Boot/FreeBSD combination
has been shown to work or not:
(I freely use my own abbreviations of official naming.)

armv6 (BCM2835/BCM2708):
	RPiA, RPiB, RPiA+, RPiB+,
	CM, RPiZero v1.2, RPiZero v1.3, RPiZeroW
	(Note: https://www.raspberrypi.com/products/ does
	not list any of these as EOL yet. CM3 and CM1
	are listed as "in production but not recommended
	for new designs".)

	FreeBSD image name pattern: *-arm-armv6-RPI-B*
	(and no others)

	No one may have evidence of the support status
	for each armv6 above. I've no evidence for
	any of them from anything like modern times.

	The port rpi-firmware has the files below
	(and more) in a vintage that matches
	with FreeBSD's implementation of the FDT
	(Device Tree) handling:

	bcm2708-rpi-b-plus.dtb
	bcm2708-rpi-b-rev1.dtb
	bcm2708-rpi-b.dtb
	bcm2708-rpi-cm.dtb
	bcm2708-rpi-zero-w.dtb
	bcm2708-rpi-zero.dtb

Note: I do not know how to classify the RP2040 Dual-core Cortex-M0+
processor parts: they are armv6-M (M is for: microcontroller). So
I did not list: RPiPico, RPiPicoW, or RP2040. No *.dtb name
suggests which would support any of them.

armv7 (BCM2836/BCM2709):
	RPi2B <= v1.1, CM2
	(Note: https://www.raspberrypi.com/products/ list
	it as "in production but not recommended for new
	designs".)

	FreeBSD image name pattern:		*-arm-armv6-RPI-B*
	12.* FreeBSD image name pattern:	*-arm-armv7-RPI2*
	13.*+ FreeBSD image name pattern:	*-arm-armv7-GENERICSD*
	(All should work for RPi2B <= v1.1 .)
	(No others)

	Note:	*-arm-armv7-GENERICSD* is basically a rename of
		*-arm-armv7-RPI2* (relative to RPi* issues).

	I've no clue if anyone has CM2 evidence.

	The port rpi-firmware has the file below
	(and more) in a vintage that matches
	with FreeBSD's implementation of the FDT
	(Device Tree) handling:

	bcm2709-rpi-2-b.dtb

	The port rpi-firmware does not supply the file:

	bcm2709-rpi-cm2.dtb

	So the CM2 is missing something likely essential.
	(But the *.dtb need not be sufficient by itself.)
	(The file goes back to 2018-Mar-22 for its first
	commit on github.)

aarch64 (BCM2837/BCM2710 family):
	RPi2B v1.2, RPi3A+, RPi3B, RPi3B+, 
	CM3, CM3Lite, CM3+, CM3+Lite, RPiZero2,
	(BCM2710A1):
	RPiZero2W,
	(BCM2711 family):
	RPi4B, CM4, CM4Lite, CM4S, RPi400
	(Note: https://www.raspberrypi.com/products/ does
	not list any of these as EOL yet. Nor any as
	not recommended for new designs.)

Note: aarch64 RPi*'s can boot via RapsiOS 32-bit or RaspiOS64.
(I've no clue if FreeBSD can do similarly for the BCM2711 family
but it has handled BCM2837/BCM2710 contexts used as armv7
historically.) ("RaspiOS" is my abbreviation.) In part this is a
U-Boot issue. RaspiOS and RaspiOS64 do not use U-Boot. U-Boot
could potentially block FreeBSD from operating for a 32-bit
addressing OS variant.

	FreeBSD image name pattern:		*-arm-armv6-RPI-B*
	12.* FreeBSD image name pattern:	*-arm-armv7-RPI2*
	13.*+ FreeBSD image name pattern:	*-arm-armv7-GENERICSD*
	12.* FreeBSD image name pattern:	*-arm64-aarch64-RPI3*
	13.*+ FreeBSD image name pattern:	*-arm64-aarch64-RPI*

	Note:	*-arm-armv7-GENERICSD* is basically a rename of
		*-arm-armv7-RPI2* (relative to RPi* issues).

	Note:	*-arm64-aarch64-RPI* is basically a rename of
		*-arm64-aarch64-RPI3* (relative tp RPi* issues).

	No one may have evidence of the support status
	for each aarch64 above. I have some evidence
	only for RPi2B v1.2, RPi3B, some RPi4B. (All
	work for *-arm64-aarch64-RPI* last I checked.)

	The port rpi-firmware has the files below
	(and more) in a vintage that matches
	with FreeBSD's implementation of the FDT
	(Device Tree) handling:

	bcm2710-rpi-2-b.dtb
	bcm2710-rpi-3-b-plus.dtb
	bcm2710-rpi-3-b.dtb
	bcm2710-rpi-cm3.dtb
	bcm2711-rpi-4-b.dtb
	bcm2711-rpi-400.dtb
	bcm2711-rpi-cm4.dtb

	The port rpi-firmware does not supply the files:

	bcm2710-rpi-zero-2-w.dtb
	bcm2710-rpi-zero-2.dtb
	bcm2711-rpi-cm4s.dtb

	So the RPiZero2, RPiZero2W, and CM4S are missing
	something likely essential. (But the *.dtb need
	not be sufficient by itself.)

> As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused
> which image is for which version of Pi hardware.

The  RPi3B+ should be able to use any of:

FreeBSD image name pattern:		*-arm-armv6-RPI-B*
12.* FreeBSD image name pattern:	*-arm-armv7-RPI2*
13.* FreeBSD image name pattern:	*-arm-armv7-GENERICSD*
12.* FreeBSD image name pattern:	*-arm64-aarch64-RPI3*
13.* FreeBSD image name pattern:	*-arm64-aarch64-RPI*

But I've no evidence of my own of the actual results.
(No access to such a part.)

The *-arm64-aarch64-* ones are a more complete match
to the hardware: for example supporting 64-bit
addressing instead of 32-bit.

> I previously had some kind of a 3B, & now have a "Pi 3 Model B+",
> but have not got beyond booting images, starting to customise /etc/
> & then it crashes yet again, needing yet another dd, & repeat,
> Being certain one is using the right image would be nice.

This does not sound normal at all. I expect something more
specific to your context is involved.

> My notes: http://www.berklix.org/~jhs/pi/#images

I'll look at the notes separately, possibly not tonight.


===
Mark Millard
marklmi at yahoo.com


From nobody Wed Dec 14 08:41:13 2022
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 4NX83Z2ZqMz4jpc5
	for ; Wed, 14 Dec 2022 08:41:30 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30])
	(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 4NX83Y2BgQz3sx4
	for ; Wed, 14 Dec 2022 08:41:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="dotONM/h";
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 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=1671007287; bh=wWtILOelNJISwd9agIQs4g8eQ0CVWsAVfWvBrkEnk0k=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=dotONM/hBTO0r7UPAmBfyILv0h0byKv4LlTzUztcSpJJQotCl1yDiNu0tZkRheKJnEHZYHgaMI0PB8kffojl/tTogXJ8RMpBQTSJrUMG+JUXBAWiKLE2JmvHPtUsdeOvMj0TPIor4rsdJnpg7aVzqeBeqOtS2ctzVxxx13xQq6/27rGFgpNkU9OKwa6X/MpJTBQFJ2Hgskbt0PfnLJ+J7dkNbSFIJbpvhOK6D/3JvP0NcV4aFe0VvMU+2HtsJV6G5Oe3ZKnY6d+6dvzQ+zAB19CAOU9WA8vC9lRKdzxlR2NZnOMC9asL5HAZJNV9TghfqgOk4w+K0u0nhi70tRi44Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671007287; bh=vpC9hC9A73IkGKeCRg1O9KJkQqJVr9NBSz3expmWsBu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=sBEUpS4U4I75mL7QFiW6vpwrZoUF6ByK0UvB2lQEa5tOkDV868s35b+oE7tcS0MGhL1pLvF3gMO7HqqMd36wvbRU1rT4JVih9iQ5E8EeR0BsJGBEtVMRrGGsDbLNzH29CHNDN9m9IJ8rsDr+7QMiK5b0n9XmyVRlfZPQy+VTxawo0AH7UBRh/meDRTqeQIuy8vgnDAVPj1AFqFb2b5qLv/o18fVpMjK5uGS1MVCsMH2JoHpotkLxGZtCtg+a6ZjraSrAxzkvLzk4cfClLiKl7ZymvjfkY7XMVIrepRc1rEXSjwHpek2uCT2+471X7A1a5954DPCOEseAp36Rjq7amg==
X-YMail-OSG: MNVIe5MVM1ndqDwsZghjhle3zNbp15VKVUwFGmrRMPtiU9t7yS0g_1T76fGNrre
 7IvZrX7xsyR0GatgBKe.1jjfaQDfm42H31ziMYI8dFT4Rlx78XMO8lSOd.8R.weNPnzcd2QA7r1x
 m1UNdBAyzeE7ypn_cXsnKmcmH0prfFUGiE5EWsc8hc0Na_RnfMqAWjGRuSqEIYpFKwsBLRs5Bca2
 3AI0at93qTZawZW1XnZlR0hxyVtNO0wl9_mbgdFzQErk8OrpQKVfnP0Np3Oi1AzccFqGmTrgzGle
 hL9mhGefWYI3fnPABxccijrMU8HOVZoGclEBuN8hKEMY3EZC.Yjk4fvaeeZ_iq0Dj.wMbBXiq7Hq
 IEFUlYkdImloK.a2qZQ5NBgAMnpQU56sey8VUPwTZLwZ28MGwZBtSUeJkoa_NoK37D8sq2V1lNNx
 iBPu2Rmuc93H0fiVRjC8Jkh7d.MxDwGJ6AwFN4k0Qtqs8DjX5k.RH4.pDsC34W3a9lzpAe0DEmH0
 2HnV54iKpP3dAAqaw7x7mFOvzX142UvBDVN3v5Bnf5aKK7od6id5E8u05rLjYOijgowNYdIfnbsg
 xURdxEXwK2JXOpMh02CKVi_FcwYXdoxQTgTnm5MpDdqYOYpVm96Bi01o4hltXbMLUmbLNEYK4ePQ
 LLMav.drHj4ZVOkPuRq.g30baCqMghD40DWwD3V8CM7bK43Svic9aqZRS0Hl2bA5oyJ9afDx.llX
 MJBIX5H2NO_Uv6smfojo4bRSkEDk6CatuNXYfgfWq.w56PJAw1eybXkrRbkVIN1qPqk8zJeU8ir1
 SdVbDi1QNPKcPhrNQ4FLBTmqrYKJRreqkWkN5PZDv4EHEp1sQAbKzGQlHAKy2QwHckX.QXdrs2RQ
 L_5XK.DqRDmFmZYRRYsrYPzZnpmyM8FLw7MEqPOYF9qedShAFXtE2VtU5zFo8S7LCdlkFU4IcmHV
 52dBNAylFtqBMVMpCOln369e3EKOECfhtL6tSdjcKTNbTqUzDyfkRa_uw_qB9DRFwXrr4Ex2pK5a
 j4AL03yfDyqzHfBgiLq39byazOxPnVgSgisgAxD5R_K49leL.68FRaq_4p9ULDAzLnwX4tGucKX0
 7pJB0kbcE27fObRa1A0iebyanrSt7Knvng_CSZJQlyRLUjjW7vJWJlzjNc_J_1qKuqOc7BXZKyFy
 4sUCQVREZ_3an3nhilYZbv7H65Hswc6YGLbIvrjWHHDP.GYmLVI9uJSVwvif7ApU2IOLgcxKoFLg
 zE.NHFoZIXRAFM.Ym0dnSRfHwMa.M9NOQUzuKIfE2Vd39VHerJKe472tf7leYBqUE0mf6t7oIzxd
 5QDqODOxQE3Zggaq1qCc9xG0KbNo3PhVq3BIqqaAGhW16GGJyLdFYBVQnCi4Pz5uWkqZv1GPyViS
 vYodERpNEoQyz7ShVwoM9Ihxu0ufarw44.LN_TFlQWGC6n4OK0iPeaQM_2ArWrCnyHV5no9JUFmt
 vOJFjIq3GAZetRNoRyQE3Ma85loK8CucdKbMof0c6J2hPhk2lxKwtthA0t0BXfzEt3f5rc.YfQvb
 EQlCP9YQpbWjz2leFBtnStPQs8NGFiww1Gtl_ZFiLYeiLjveaKgLkVtvnttFnbBScC6j_tuMf2E5
 K_0ATRbv92E5A0X4sZ6XQkxcIFsbaAnXqBh1eWXaiT6_JG2KWbjzQp0bFR0vHAKq1mWAZGx_gQle
 .tcteEA9PKfZkng41ucz6LwCwzMi8l8hHdHXZPuSMKYk.EW3fLK7g1Yjs4XjSq4xzeqFDEAmvtu4
 ILEclYdWeA932nbA6bB.I2hlURHRVC5t1Pw_tgA7WOxe7ynFV8KunM7LBB9DHXwPC.ZyuKvfJt56
 KE1RvByGHxs4aF4RfzJvHUAw9SPe2Lw48vxfepwjqXLSwifMjNTLERmmzQwliB_3gEi0IAdbzUtN
 E24QxB55b9dIl7g4vibXgIFieu6ViSk8b6Ic9a.VmrT_xSo4oXkPPE1cqPWnEFvv4DbqQaO34vh4
 TM1cCmrl1dMkxc9VIsDSjWozZDv0tFIzGKWy2W106WtErJZ_uCwfBxp6.tPUX0X7jL9H4fK530bb
 p1A3MG8lwKL9KwpgxFeTULwsIo9C1_yF1mk5SMQHwmxSApaShpc4uyQyJ0bwRKT3T1BTz_JxN8MY
 r2K3lX64izLHBzIXineQSiH3mLZ5V9kOlTjC0BoHt1ABQWDq9pdQFImoxYG4WjEP.V1S0EFPExiS
 jqAQVval9LKNHMP90b5IuupsES1.qXFKvjZQkILOeFtbjcVkm_S6idKKTfbPw5eeGDpUpLSOS5g-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Dec 2022 08:41:27 +0000
Received: by hermes--production-bf1-5458f64d4-97x65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c3d783a96b9733a063d13dcb7e931fc8;
          Wed, 14 Dec 2022 08:41:25 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: Re: armv6/armv7/aarch64 vs. FreeBSD images (retitled from an arch
 reply, moving to freebsd-arm list)
Date: Wed, 14 Dec 2022 00:41:13 -0800
References: 
To: jhs@berklix.com,
 freebsd-arm 
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NX83Y2BgQz3sx4
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Dec 13, 2022, at 22:45, Mark Millard  wrote:

> Julian H. Stacey  wrote on
> Date: Wed, 14 Dec 2022 02:22:10 UTC :
> 
>> . . .
> 
>> I previously had some kind of a 3B, & now have a "Pi 3 Model B+",
>> but have not got beyond booting images, starting to customise /etc/
>> & then it crashes yet again, needing yet another dd, & repeat,
>> Being certain one is using the right image would be nice.
> 
> This does not sound normal at all. I expect something more
> specific to your context is involved.
> 
>> My notes: http://www.berklix.org/~jhs/pi/#images
> 
> I'll look at the notes separately, possibly not tonight.
> 

Note: I presume use of an aarch64 FreeBSD, not armv7
or armv6. Otherwise some things would be different
below, such as via tighter constraints on swap space
sizes for 1 GiByte of RAM.

Quoting http://www.berklix.org/~jhs/pi/#images :

QUOTE
  pid 17 (sh), jid @, uid 8, was killed: failed to reclain menory
END QUOTE

This is the FreeBSD kernel complaining about the configuration
not well matching the RPi3B+ workload. In essence, it was unable
to achieve it targeted minimum amount of free RAM in the sort of
time frame (really: effort) it is configured for. Depending on
what you do, the FreeBSD defaults do not work well for 1 GiByte
of RAM. Swap space alone is insufficient because FreeBSD does
not swap out processes that stay runnable. Just one process that
stays runnable using a working set that is as large as the fits
RAM for overall operation will lead to such "failed to reclaim
memory" kills.

But, if you are getting this, you will almost certainly need
a non-trivial swap space anyway.

I have a starting point to recommend, configuring some
settings. As I've no detailed clue for your context,
I'll just provide the general description.


A) I recommend a swap space something like shown in
the below (from gpart show output):

=>        40  1953525088  da0  GPT  (932G)
          40      532480    1  efi  (260M)
      532520        2008       - free -  (1.0M)
      534528     7340032    2  freebsd-swap  (3.5G)
. . .
    67643392  1740636160    5  freebsd-ufs  (830G)
  1808279552   145245576       - free -  (69G)

This size (3.5 GiBytes or so) is somewhat below
were FreeBSD starts to complain about potential
mistuning from a large swap space, given the 1
GiByte of RAM. (I boot the same boot media on a
variety of machines and have other swap partitions
to match up with RAM sizes. But I omitted showing
them.)

It is easy to have things like buildworld or
building ports end up with individual processes
that are temporarily bigger than the 1 GiByte RAM.
Getting multiple cores going can also lead to
not fitting and needing to page.

I'll note that I normally use USB3 NVMe media that
also works with USB2 ports. My alternate is USB3
SSD media that works with USB2 ports. I avoid
spinning rust and microsd cards. This limits what
I can usefully comment on for some aspects of
configuration related to the alternatives.


B) /boot/loader.conf content:

#
# Delay when persistent low free RAM leads to
# Out Of Memory killing of processes:
vm.pageout_oom_seq=120
#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
vm.pfault_oom_attempts=-1
#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes (showing defaults at the time):
#vm.pfault_oom_attempts= 3
#vm.pfault_oom_wait= 10
# (The multiplication is the total but there
# are other potential tradoffs in the factors
# multiplied, even for nearly the same total.)

If use of vm.pfault_oom_attempts=-1 is going to
be inappropriate, I do not have background with
figuring out a good combination of settings for
vm.pfault_oom_attempts and vm.pfault_oom_wait .

I'll note that vm.pageout_oom_seq is not a time
--more like how many insufficient tries to
reclaim RAM happen in sequence before an OOM
kill is started (effort). 120 is 10 times the
default. While nothing disables such criteria,
larger figures can be used if needed. (I've
never had to but others have.)


C) /etc/sysctl.conf content:

#
# Together this pair avoids swapping out the process kernel stacks.
# This avoids one way for processes for interacting with the system
# from ending up being hung-up.
vm.swap_enabled=0
vm.swap_idle_enabled=0


D) I strictly avoid having tmpfs complete for RAM
in this kind of context. tmpfs use just makes
avoiding "failed to reclaim memory" more difficult
to avoid. (As various folks have run into despite
having vastly more RAM than an RPi3B+.) So my
/usr/local/etc/poudriere.conf has:

USE_TMPFS=no

There are examples, like building rust, where
anything but "no" or "data" leads to huge 10
GiByte+ tmpfs spaces for poudriere's build
activity. Not a good match to an RPi3B+ .


That is it for the recommendations of a starting
point configuration.

With such measures, I've been able to have poudriere
with -j4 but also using ALLOW_MAKE_JOBS= without using
the likes of MAKE_JOBS_NUMBER limiting it. (So the
load average could be around 16 a fair amount of the
time but still not get "failed to reclaim memory"
kills.)

Note: I'm not claiming above that -j4 is the best
setting to use from, say, a elapsed time point of
view for my poudriere bulk activity.

I'll not volunteer anyone specific, but there are
folks that have reported using RPi3B+'s on the lists,
mostly via asking some question related to system
operation. So you might be able to ask for
information from anyone that really has an RPi3B+
in use, possibly describing the context that gives
rise to the question(s).

===
Mark Millard
marklmi at yahoo.com


From nobody Fri Dec 16 00:24:15 2022
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 4NY8x15wB2z4jcvK
	for ; Fri, 16 Dec 2022 00:24:21 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from nmtao202.oxsus-vadesecure.net (mta-232b.oxsus-vadesecure.net [15.204.3.7])
	(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 4NY8x01ykhz4Xlw
	for ; Fri, 16 Dec 2022 00:24:20 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=lqrxx4yh;
	spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.7 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com
DKIM-Signature: v=1; a=rsa-sha256; bh=2SdYMVHRZMhX+g5e43sKQhSjv6WENFSrEyVLlc
 Wh090=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to:
 subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:
 in-reply-to:references:list-id:list-help:list-unsubscribe:
 list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1;
 t=1671150258; x=1671755058; b=lqrxx4yhitBJe2IWgsK0a6HUCLhdBErUv2Rryc1/W
 IrtTIbufH2pOnWR/vucWN0gEEkV4ooBpKrLdhMwv4L6osf2OT8i6765wt84j8oIkDAvAw8L
 USYbCSA1CxuyoPf1nNfREc7YHW2//pOJrpiruofTPDAzRDx2Rup8lepoTqjL71KXhDTWIba
 1qdsbZLeD1yWZmbRT7sGUp6Pr5D6qOfZz9mAPhtiyyzcnTwXrSgU0DifqKNbO6rGJEOlvlx
 TPUkDNPlT7NQ4o1iao5XdTsKEFsyAJEYxVHpMzbUyEWyb6391qEKQVhHELe8r1uDw9VkYMw
 2kzU2cSN2v4b9HYLQ==
Received: from proxy-18.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149])
 by oxsus2nmtao02p.internal.vadesecure.com with ngmta
 id f795e2f4-17311e4e0d7828af; Fri, 16 Dec 2022 00:24:18 +0000
Message-ID: <4fde8709-6826-95cb-10dd-0893df5c9f4f@thegalacticzoo.com>
Date: Thu, 15 Dec 2022 16:24:15 -0800
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.2.2
Content-Language: en-US
To: freebsd-arm@freebsd.org, Victor.Weinstein@microchip.com
Cc: fredfinster58@gmail.com
From: Fred Finster 
Subject: Would like to help you, Victor, with building FreeBSD 13.0 for
 Nitrogen8m ARM64 imx8 board
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-4.00 / 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)[thegalacticzoo.com,quarantine];
	R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1];
	R_SPF_ALLOW(-0.20)[+ip4:15.204.3.7];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com]
X-Rspamd-Queue-Id: 4NY8x01ykhz4Xlw
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

 From Posted FreeBSD-arm mailing list

https://lists.freebsd.org/archives/freebsd-arm/2022-December/002094.html

Hello Victor,

I am just a FreeBSD user,  I have experience creating an FreeBSD disk 
image and a kernel image for Raspberry Pi 4B /w 8GB.  Give me a call  +1 
971-718-9144 Anytime till 10pm PST would be fine.

https://ghostbsd-arm64.blogspot.com/2022/09/freebsd-140-compiling-kernel-for.html 


Yes,  I don't have the specific information for the MX imx8 Nitrogen 
Board, yet I believe I can help you with the details of building a 
booting kernel and creating a disk image.  Which kind of disk type do 
you wish to boot from?  USB Flash Disk,  USB 2.0 or 3.0 External case 
with a SATA SSD or Hard drive inside?  Or other type like NVMe, or SD 
card.   I assume UEFI  GPT partitioned disk.

Here is  a telegram group  ARM Open-Source (I am owner of this group)  
you are welcome to ask/post questions,  share information pictures 
https://t.me/+ST6N61pnu3Di8zgk .  If you prefer to be anonymous with 
your activities, then just email me here.

Look forward to helping you, Victor.  What development platform do you 
use?   t.me/GhostBSD/download  "latest" version.  Write to a USB Flash 
drive stick.  Boot the live image ( needs 4GB of dram memory).   Add a 
SSD 500GB, usb external or internal SATA or Nvme.   You will have GUI 
MATE desktop on a GhostBSD.org ( downstream of FreeBSD kernel sources).

I  want to see FreeBSD running on your imx8 Nitrogen hardware. Will be 
reading the links you shared in your post.

Respectfully

Fred

-- 

Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144
https://GhostBSD-ARM64.blogspot.com
https://ghostbsd.org


-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144
https://GhostBSD-ARM64.blogspot.com
https://ghostbsd.org


From nobody Fri Dec 16 00:26:30 2022
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 4NY8zs2d77z4jclf
	for ; Fri, 16 Dec 2022 00:26:49 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4NY8zq6nHsz4YFZ
	for ; Fri, 16 Dec 2022 00:26:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=CmimbpYC;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 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=1671150406; bh=BjEVVyk2auN+8O6hn2cTvLGDv5+o3IKOwYqLaQMendQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=CmimbpYCzcHkyo59as6hIbfxTAG8rC3gtwXC+W0hqG/K6WHpO2pW8cZxE+37lOApPHkdakeQvoPTXqClJsebBzkWo9FEwKKTNObgDAUVtWlYql2Acdc5VnMEoDOR01oFnZUVBi2o7OdiRq6X+1wYlHj/cBS46ZtAuzdHhMGhhmmW+PS/lYqF4khGivNk5zbBjTH84oJwbKkaF5pV+WpAFcyMnzkzZZhIt0cpDbhSaY5itzK/kA1Exh93Zo1BnWR67K5184YZ1PGVHRqtSgk2vm7CydSR2U/o6+z7uoBxv08sp1IIdPJh/QEWDks1o4O+ksKAhiMTpoh9U6TvuwIG8Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671150406; bh=gjobIiE99kQPNv/JR1JNGEpee7eWdetZRZHtSrZeYE6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QSl9d3oczvYiRCqNiuP6TjnXEDLsFdLE+sBEI0faBDQXWPa5FFvcxC++hRfkVcN0QQlpcB3QdsYNN7u78x6rtEX2XopRGiBG64C8aMguGia6M5EbznJPP/XJvQbgRSvbCOHEIrtR3ysbKurqg59E70XuL+rZe4s3DQfY2wVciuDOmn2RNFNxdmFCa3r2ZwNIUxjEDcBBedvd/8sBul6cBWfpcXLhgW1S1vPaHxeq7m769lzmg4aa7/15G8A/h3Ufo7qOooAUQiM3Dy2wkR4on/ToMwXWGXsksfO5hKJFIw0H56D1gG8NrSjiQsZy8G1AcrqpzeDru23QRu6w1bkAEg==
X-YMail-OSG: WbZWB6kVM1mL.xX0ZTXWAng17qC_xd1jLuFzGzfXcJmyo677xYASUdlRW7lWnyK
 503cOtf6SAU5u657PcP984EAT5wqxVHMLWUoV2e5XaHt__vyETWp6Lkl6U03.EB69SXYtxLLTQvx
 nDzkFfJn1R791nyGaGjvbSVFHcYz4.N2z_BEqg6BukXiNC55_gjAFK5ZSLF7iDOyerC5mA_0LV2h
 SuNB7iSNcX0zjvay.xcpQayHvBDtR6X9wFHvAYqUh1KxUwsA9cap8OvlyMM0SHqRbAlQapoF8IiM
 1we1ehblgMda.Bd7ctd5bbhzTA3mjUceKv0cqhb73nRnITIo0lvRddXdU0MHAHX6W6m_2jIKuvLJ
 MqEngWpDjyrQ0E7zzcWlb4lZ8YocIBWpVnzxsBm9Rm9EMWJfPuDLQGDYfcGGnLlrh6FPYA4eX6hD
 Fj0HhXLtPIFxf7AcgwD4hQWHNIuizNanMVLAlPzqlwbxCFfQML7vl9diKll1lVX.NlOdNDyrgiPg
 l6f_BfkufucZWfW89N7pVQpDNnkn885ZNtmw6lf5qnhH6fWI0MIqDVFFESiFLrikrvFAdL8bzgnw
 BcrHjHwe0BKfAvGqYN9cWkRCt2jxIgmQ44x2YXEz13xZQ1DVXzLTGhsgn2EvTfJVx3EBl.ejLnjS
 TRAL8f8eCUnLyBBBj7d0QReFCaYOIiQ9A6ZrDYQIAJDOsSPipjF6GtjOfy4DAHcuz5.V41zYE1M9
 Zne.V3eONJItXVYDl.wKSQCm1x.Tx7ygrOIFxBWEtkzIArwfFhk0aUwQAkBr7IT0OjYBMfoRSphu
 d6VRBgFewjgWIZogjcdhXkCqM36lmncgVwfId5CzW0ZIQ2szlu4G0BWKo.eBaSd_zRc0ji1jqOK2
 89z_WNshtHquEao6NzV5HMB.6IT6lZYTDR_5txwiWfkpxs466FvShNWWA5.kGskUsPJKDXht4I1P
 rF488TnzbhzJQ.3XXH.7mHu05ngZaLOtR3QgcXIg.D9ZZpPXRX2ct60Q1.2uqasvfv5kOAqkaJJd
 tbRCPXG5ctZ2r94_e0zNkNEZ_vjMe5NBBzcDjV9plU2cxT5GMbxYbXxuYudHX17DXzMbDSYcImNf
 jiJmkmUh.thPJBD.2MbFHrgwdsa2DsrtPWspWeY7osrf.QkqOKUZwZWeCGIcjg_fLrJl5zF7A.JP
 dx4nJ_yWusUkDtYnR.5gdyJrFWXdI5CauTCUXExQr1Qs_tf46VMDtJWEZrjjceaa3d3wqUskAE_H
 zIllt_OE4.e3ryknhIqXxmUisD5S7Nec9qrDlbx14QpY7AGNagL2RjGZnw1vUPO_Jlyvfo3bjtCu
 gnaNUzlodpoblj6JodnQivVXy2tHOqKAVCmexab9AJHvXT9d0ikTcCLnUW094mHjbr.z1AYk2Ovp
 YetvvgNb0GdjlHYDrkY9V4JBqGHLwtzlKoNfThDn0TOABktLJOtaJ7GJ03iTt9K52.P6nSG2kGKl
 fJ6qy512aKg38Hb87wGJu0jcPmgG.f3l7PTeCLvFWuq6wzwNnZ.U85_QmEOqzUB8uqyYDrHme4eF
 lsOWAQ1wEQAM5XflP.8nj3ah6bXRGoTO_JtPO5ywbrf4hXLFwtOt8LXUiep18EOKiGHNPXNf1C2.
 wZEIKWXO4VPlmADurO52404JcCUYv_eLQCmta._B2QsJgur3jPgdfcBcZOSCAG5Z8RqCcpYBB9VY
 w6e1fQBVV.KcmYrRtFB9TbBE9XEsnTZFbPYS2l7byZw5EjkrHfueKd0Ev84lMI4gTML8qNhN9kaL
 0jv7AJ7C_mMqihxZcBeB_peP8rhQ_yL_nY0bWhqAZgN0eyXgRsN6pUQv4UxicJ.PzBpQU1dB2hOC
 0w7qPSpnDlCnFcklTrCcrDj7z5EyDfa0QjthC9FEoiYO2b51o4yOJQZ8fEn4A1m4dmReUahJ_cSa
 LoWru_PtR0z_Lq_OZ3llgA_dnYOcMgh7ENi8LMudyJg10cVsdk2YIM_3WnYJPDb4Y61QZDEuv2NU
 OPzLevPaiFvl8dbHR4R2zGHYKt_tCbvxlEkU_Lme7GmFqwmlJXdoI9tqfsfTLMgkWu0xGGSGqgK0
 zKDipRfDqrUVGhZBtmGJAmBDa1oMKsslxz8BVGmk1VKe9Bm9QwYiOaF7tobU4Gz6Cv1MeObhPWH6
 pnm84VeI3lmWEC2O3ieRfNhJZLSQjUh0miC2l9nmv.eSWN4yMF.271P7a1kAHzJHZOnOiAOqIfq5
 JD6u2x3BOtRygoM_8cHE3UT0qvAL3bo8j2wm1GjLF3qAWCeQnzPUNlcjpDO2UA0OQLDoKMGWQu0x
 r.Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Dec 2022 00:26:46 +0000
Received: by hermes--production-gq1-d898c4779-4ndbh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID faccd2cbf2de17518198ab35d1ed9a53;
          Fri, 16 Dec 2022 00:26:41 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
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.200.110.1.12\))
Subject: Re: armv6/armv7/aarch64 vs. FreeBSD images (retitled from an arch
 reply, moving to freebsd-arm list)
Date: Thu, 15 Dec 2022 16:26:30 -0800
References: 
To: jhs@berklix.com,
 freebsd-arm 
In-Reply-To: 
Message-Id: <995C856D-B030-48C6-B369-26A8E7233379@yahoo.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.41 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.91)[-0.905];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NY8zq6nHsz4YFZ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Dec 13, 2022, at 22:45, Mark Millard  wrote:

> Julian H. Stacey  wrote on
> Date: Wed, 14 Dec 2022 02:22:10 UTC :
> 
>> Hi, Reference:
>>> From: Mark Millard 
>>> Date: Tue, 13 Dec 2022 15:52:16 -0800
>> 
>> . . . 
>> 
>> Extending wordings associated with each Pi dd image, would be very
>> welcome, to specificaly list all hardware version of a Pi each image
>> of v6, v7, aarch64, the image should boot.
> 
> For FreeBSD support, a U-Boot build that is
> compatible is needed. U-Boot is via ports, with
> only a few preassembled combinations of U-Boot
> variant and FreeBSD produced officially.
> (Statements not limited to RPi*'s.) U-Boot
> materials are not part of FreeBSD but are
> used (even: needed) by FreeBSD.
> 
> The RPi* firmware has a similar status: it is a
> port: rpi-firmware . It is not part of FreeBSD
> itself. A combination of RPi* firmware, U-Boot
> varient, and FreeBSD are needed overall.
> 
> (The RPi* firmware can adjust some of the 
> Device Tree before handing things over to U-Boot.
> U-Boot can adjust/add more before handing that
> off to the FreeBSD loader. FreeBSD does not
> handle all valid Device Trees from what I can
> tell --and this limits what range of RPi*
> firmware that FreeBSD avoids crashing with.)
> 
> What armv6/armv7/aarch64 RPi's there are/have-been,
> no matter if a RPi*-firmware/U-Boot/FreeBSD combination
> has been shown to work or not:
> (I freely use my own abbreviations of official naming.)
> 
> armv6 (BCM2835/BCM2708):
> RPiA, RPiB, RPiA+, RPiB+,
> CM, RPiZero v1.2, RPiZero v1.3, RPiZeroW
> (Note: https://www.raspberrypi.com/products/ does
> not list any of these as EOL yet. CM3 and CM1
> are listed as "in production but not recommended
> for new designs".)
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> (and no others)
> 
> No one may have evidence of the support status
> for each armv6 above. I've no evidence for
> any of them from anything like modern times.
> 
> The port rpi-firmware has the files below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2708-rpi-b-plus.dtb
> bcm2708-rpi-b-rev1.dtb
> bcm2708-rpi-b.dtb
> bcm2708-rpi-cm.dtb
> bcm2708-rpi-zero-w.dtb
> bcm2708-rpi-zero.dtb
> 
> Note: I do not know how to classify the RP2040 Dual-core Cortex-M0+
> processor parts: they are armv6-M (M is for: microcontroller). So
> I did not list: RPiPico, RPiPicoW, or RP2040. No *.dtb name
> suggests which would support any of them.
> 
> armv7 (BCM2836/BCM2709):
> RPi2B <= v1.1, CM2
> (Note: https://www.raspberrypi.com/products/ list
> it as "in production but not recommended for new
> designs".)
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.*+ FreeBSD image name pattern: *-arm-armv7-GENERICSD*
> (All should work for RPi2B <= v1.1 .)
> (No others)
> 
> Note: *-arm-armv7-GENERICSD* is basically a rename of
> *-arm-armv7-RPI2* (relative to RPi* issues).
> 
> I've no clue if anyone has CM2 evidence.
> 
> The port rpi-firmware has the file below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2709-rpi-2-b.dtb
> 
> The port rpi-firmware does not supply the file:
> 
> bcm2709-rpi-cm2.dtb
> 
> So the CM2 is missing something likely essential.
> (But the *.dtb need not be sufficient by itself.)
> (The file goes back to 2018-Mar-22 for its first
> commit on github.)
> 
> aarch64 (BCM2837/BCM2710 family):
> RPi2B v1.2, RPi3A+, RPi3B, RPi3B+, 
> CM3, CM3Lite, CM3+, CM3+Lite, RPiZero2,
> (BCM2710A1):
> RPiZero2W,
> (BCM2711 family):
> RPi4B, CM4, CM4Lite, CM4S, RPi400
> (Note: https://www.raspberrypi.com/products/ does
> not list any of these as EOL yet. Nor any as
> not recommended for new designs.)
> 
> Note: aarch64 RPi*'s can boot via RapsiOS 32-bit or RaspiOS64.
> (I've no clue if FreeBSD can do similarly for the BCM2711 family
> but it has handled BCM2837/BCM2710 contexts used as armv7
> historically.) ("RaspiOS" is my abbreviation.) In part this is a
> U-Boot issue. RaspiOS and RaspiOS64 do not use U-Boot. U-Boot
> could potentially block FreeBSD from operating for a 32-bit
> addressing OS variant.

I tried using the USB3 FreeBSD media I have for booting both
a RPi2B v1.1 (native armv7) and a OrangePi+2ed by plugging it
into a RPi4B:

U-Boot 2022.10 (Oct 21 2022 - 01:23:47 +0000)

DRAM:  947 MiB
RPI 4 Model B (0xd03115)
Core:  200 devices, 12 uclasses, devicetree: board
. . .
Net:   No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot:  0 
Card did not respond to voltage select! : -110
MMC Device 1 not found
no mmc device at slot 1
MMC Device 2 not found
no mmc device at slot 2
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
. . .
starting USB...
No working controllers found
No ethernet found.
No ethernet found.
U-Boot> 

So U-Boot is not set up to deal with the
RPi4B's differing USB hardware. It did not
make it to the FreeBSD loader. 

Thus, effectively, the BCM2711 family is
limited to aarch64 FreeBSD.

> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.*+ FreeBSD image name pattern: *-arm-armv7-GENERICSD*

The above 3 are not appropriate for the BCM2711
based family.

> 12.* FreeBSD image name pattern: *-arm64-aarch64-RPI3*
> 13.*+ FreeBSD image name pattern: *-arm64-aarch64-RPI*
> 
> Note: *-arm-armv7-GENERICSD* is basically a rename of
> *-arm-armv7-RPI2* (relative to RPi* issues).
> 
> Note: *-arm64-aarch64-RPI* is basically a rename of
> *-arm64-aarch64-RPI3* (relative tp RPi* issues).
> 
> No one may have evidence of the support status
> for each aarch64 above. I have some evidence
> only for RPi2B v1.2, RPi3B, some RPi4B. (All
> work for *-arm64-aarch64-RPI* last I checked.)
> 
> The port rpi-firmware has the files below
> (and more) in a vintage that matches
> with FreeBSD's implementation of the FDT
> (Device Tree) handling:
> 
> bcm2710-rpi-2-b.dtb
> bcm2710-rpi-3-b-plus.dtb
> bcm2710-rpi-3-b.dtb
> bcm2710-rpi-cm3.dtb
> bcm2711-rpi-4-b.dtb
> bcm2711-rpi-400.dtb
> bcm2711-rpi-cm4.dtb
> 
> The port rpi-firmware does not supply the files:
> 
> bcm2710-rpi-zero-2-w.dtb
> bcm2710-rpi-zero-2.dtb
> bcm2711-rpi-cm4s.dtb
> 
> So the RPiZero2, RPiZero2W, and CM4S are missing
> something likely essential. (But the *.dtb need
> not be sufficient by itself.)
> 
>> As a newbie to Raspberry Pi (but not FreeBSD) I have long been confused
>> which image is for which version of Pi hardware.
> 
> The  RPi3B+ should be able to use any of:
> 
> FreeBSD image name pattern: *-arm-armv6-RPI-B*
> 12.* FreeBSD image name pattern: *-arm-armv7-RPI2*
> 13.* FreeBSD image name pattern: *-arm-armv7-GENERICSD*
> 12.* FreeBSD image name pattern: *-arm64-aarch64-RPI3*
> 13.* FreeBSD image name pattern: *-arm64-aarch64-RPI*
> 
> But I've no evidence of my own of the actual results.
> (No access to such a part.)
> 
> The *-arm64-aarch64-* ones are a more complete match
> to the hardware: for example supporting 64-bit
> addressing instead of 32-bit.
> 
>> I previously had some kind of a 3B, & now have a "Pi 3 Model B+",
>> but have not got beyond booting images, starting to customise /etc/
>> & then it crashes yet again, needing yet another dd, & repeat,
>> Being certain one is using the right image would be nice.
> 
> This does not sound normal at all. I expect something more
> specific to your context is involved.
> 
>> My notes: http://www.berklix.org/~jhs/pi/#images
> 
> I'll look at the notes separately, possibly not tonight.




===
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 18 11:31:01 2022
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 4NZgdc215hzt0Sx
	for ; Sun, 18 Dec 2022 11:31:16 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029])
	(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 4NZgdb05FYz3jVN
	for ; Sun, 18 Dec 2022 11:31:15 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=abSJynl3;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x1029.google.com with SMTP id u5so6514913pjy.5
        for ; Sun, 18 Dec 2022 03:31:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=E2sy6h94J4kBBATzpOr99wydn/rzPNwmtx8+48p+QSI=;
        b=abSJynl38eAgVOV4LSWiIoxoWw/6qMoNoYeUmPO8pn7mCH0jKmzO7/1a27R8UQPyey
         JGO5TiTaMn5HhlMoJO8XsF8IY/N/WxK5FmnBCfy9hvQHUsH1SDa+CDVr2yDwROGs5W4L
         quJ9ck1Vf1yLoeyBxx6viVukPkA83S3sb8ns0XzPTC/9SYBzugemt7wbITpBrrHC5Hrb
         LxMapdZJa6gPIoAzl9t+mTJ1izHhgqYS3yuH6n0ZlS2k+37jmwF2V215XAX/+LSzvGJ9
         ogtSJ02L/pISy4N12fNT1Nw7P+z85gFPVCyGbXpeFRHKHLuuZFfike7/evmhYF+q87S1
         QBlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E2sy6h94J4kBBATzpOr99wydn/rzPNwmtx8+48p+QSI=;
        b=iXcpZDFR6tqd/kSSszQuhPbr82K9JuLqf6tFVPJfdLAubriML96TZKLPh5Kg8QWP4a
         FPP2bMP0t+O1XctIi22YGK929aS2ICp8iXdUYuJYTp1hbC301cyapRFES7FM2EBBWL3U
         EnwQStp9pYlGTyEB2piQP043UlmLLVfblxdgQtB08bXwLZk9ccNqODM1CcKLjSQXlXGQ
         k/3S0qkk9BnYv5SLK9rhYA6tu2PCjywfphnQ8TjrSPrsxLCXklqsCoKtwCeQZyhpRD4a
         ptOgK2gwtTrqutvlPdlK++bUIduS+iC1sXJ6NBRVaxDp5CwdCK2XJWYDUhQ8Dm5Gr3jU
         zUNQ==
X-Gm-Message-State: ANoB5pmj2tKfv2ncaQNW94PQTK92dA7I48IBl5qiu1PbLRJtubOo5+4o
	+W1bvXrE4ltMQ5L19Bp5cgnHTa44xS7jcSByEggLaNZVtKE=
X-Google-Smtp-Source: AA0mqf4aijNUYoVU2GSF1gdUiI2phJNQxU66vjpE4maZSFT/wV0fm8+m4cIfceWsxnkAe5lKvjeRtLAhNqaVP9xMK6g=
X-Received: by 2002:a17:902:f78c:b0:186:8c13:50b3 with SMTP id
 q12-20020a170902f78c00b001868c1350b3mr80357621pln.153.1671363073399; Sun, 18
 Dec 2022 03:31:13 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sun, 18 Dec 2022 20:31:01 +0900
Message-ID: 
Subject: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-3.08 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	NEURAL_HAM_SHORT(-0.08)[-0.078];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-Rspamd-Queue-Id: 4NZgdb05FYz3jVN
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I investigated a little more.
I thought it was the kernel that did not run, but still it did not get
through the loader.

The loader freezed in efi_do_vmap(), so I needed to add
efi_disable_vmap=3D"YES" in loader.conf.
At last, in elf64_exec, it tried to run (*entry)(modulep) where the
address entry is calculated from ehdr->e_entry by efi_translate() in
stand/efi/loader/copy.c. There,
ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
but I modified a little) and
stage_offset was 0x10000b33e0000.
The sum of two which efi_translate() returns is 0x100000000b3400000.
It overflows uint64_t and becomes 0xb3400000.

Currently, I do not understand well what the functions in
stand/efi/loader/copy.c do, and do not know how to workaround this
problem.

2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) :
>
> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
> >
> >
> >
> > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F)  wrote:
> >>
> >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
> >> >
> >> >
> >> >
> >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F)  wrote:
> >>
> >> >> OK, I (and the subject) was wrong. The loader boots, and show
> >> >> following log at last:
> >> >>
> >> >> Loading kernel...
> >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
> >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1439=
ea]
> >> >> Loading configured modules...
> >> >> can't find '/boot/entropy'
> >> >> can't find '/etc/hostid'
> >> >> No valid device tree blob found!
> >> >> WARNING! Trying to fire up the kernel, but no device tree blob foun=
d!
> >> >> EFI framebuffer information
> >> >> addr, size        0x80400000, 0x7e9000
> >> >> dimensions     1920 x 1080
> >> >> stride             1920
> >> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> >> >>
> >> >> and it stops here. No "<>" line is displayed.
> >> >> So, it seems that the kernel is loaded but could not be started.
> >> >
> >> >
> >> > There are several causes of this.
> >> >
> >> > Most likely is that the console is setup to go somewhere else. Thoug=
h if you are on the video display and getting that framebuffer output, it w=
on't not go there w/o some setting to override (say to force serial).
> >>
> >> In the loader, when comconsole->c_init() is called for the second
> >> time, the function does not return. (I commented out comconsole to
> >> make the loader work, but it is rather brutal and is not a proper
> >> solution).
> >> But the function parse_uefi_con_out() in stand/efi/loader/main.c
> >> always returns RB_SERIAL, so the loader tries to use the serial
> >> console.
> >
> >
> > I wonder why that is. Is this -current or -stable? I have a rather larg=
e backlog of MFC-able loader changes. If it is with stable, then it makes s=
ense: I fixed a bug where parse_uefi_con_out would return serial if '8be4df=
61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now we return=
 Video console if we fine evidence there's a video console.
>
> It is stable/13.
> I tried 14-current, and the same change to loader was needed (merging
> OpenBSD's start.S and ldscript.arm64, and commenting out comconsole).
> Even with these change, the console defaults to serial, so I changed
> parse_uefi_con_out() to always return 0.
> Still, it stops at the same point. The kernel does not seem to boot.
>
> Running efi-show from the loader prompt did not show
> '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
> The variable name containing 'ConOut' were:
>
> global NV,BS,RS ConOut =3D
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
> global NV,BS,RS ConOutDev =3D
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
>
> > Now, why it fails the second time, I don't know.
> >
> >>
> >> If a similar thing happens with the kernel, it may be stopping at
> >> serial console initialization.
> >
> >
> > The kernel doesn't use the EFI routines to initialize the serial consol=
e. But if the kernel is being told the wrong console, then it could also be=
 booting just fine or almost fine and hitting some bug later.
> >
> >>
> >> > Next most likely is that FreeBSD doesn't cope well with having both =
FDT and ACPI information available. But since not DTB is being passed in (p=
er that message) that's not likely at play here.
> >>
> >> I managed to load the dtb file and the boot process stopped at the
> >> same point. The problem is not here?
> >
> >
> > Yea, I don't think so.
> >
> > Warner
> >
> >>
> >> > Finally, the loader passes a large number of tables, etc to the kern=
el. It's quite possible that, for reasons still unknown, that data is wrong=
 or if standard conforming not expected by the kernel. this leads to a cras=
h before we've setup the console in the kernel which looks a lot like a han=
g.
> >> >
> >> > Warner
> >> >
> >> >
> >> >>
> >> >> > . . .
> >> >> >
> >> >> > Such also happens for stable/13, releng/13.* based installations
> >> >> > as well --and likely others too.
> >> >> >
> >> >> > ACPI booting does not use Device Tree information but the message=
s
> >> >> > are output anyway about the lack. Only if you know that the conte=
xt
> >> >> > is a Device Tree style of boot are the messages actually reportin=
g
> >> >> > a problem.
> >> >> >
> >> >> >
> >> >> > =3D=3D=3D
> >> >> > Mark Millard
> >> >> > marklmi at yahoo.com
> >> >> >
> >> >>

From nobody Sun Dec 18 19:10:45 2022
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 4NZsr91JgczswgM
	for ; Sun, 18 Dec 2022 19:11:05 +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 4NZsr726Vwz3Hkc
	for ; Sun, 18 Dec 2022 19:11:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="tJ2/qIfK";
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 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=1671390660; bh=WqzZ8P+kElKLruSlxvAsvI8EUJrHIPr7GCUvQcWXitE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=tJ2/qIfKnbq64Kh7VnE7xP25z1U9uqv2NX606VNg3enJPlrnym/hWPs74ERrtQS5lK4Vy1vV2j8D3zH/95uByyWFwTqfUFvixKAJS35XjLjhmUPQ7JSowdtrCQXOD1umDK3DS8/2Fp/T9MFntfl0+FSJEnIIFNoaN804789yPytvaW5zWnqDQFIgkteYT595lL1Q8W8E9MHWbUOM3BKMCdq2hZO3ry8EE6zpjuW5m2BVVpP7HBd/8TiJSuOhD9TFlwB6l/hpFYHubr6kcD1vtGjNaen3h7DkSS04u7/btEFDeCwkHTzuzo1KF0+C9aHdlsyv5/C9vE6MTYlIK3Y+EQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671390660; bh=vIJtL/ZTu8js3hKqv51w6GKF3FAJIKPWs776Xu7K/dG=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=dRz1HgVMb8qIMO1GFDqJDEsQ0l/emaxBxSQhTz9SXfysubWNQCUiXaaRwN6iPbOxfP9lBdfgYnacnkMNPvaoIRozc1CHDOIIUZSdn9Nt2xDKC2kdLln+4nQpEXZnvmDhIVpKte9cPoeKf0UdW8MJ+uKhnhWScuekTmiRHHLb10xwkk503zAL/b2hLRFgDjQHU076anqEhdu94geX5WC7xAweMG4/hYB/ehgUejkEfNDp2pF9ZNrSsPvbkAuhhzMoOCEotQqT2EvdBFoGbCFp/8q+KSF7utBBErhE8SfHTzxeQI9llUrYkcW4HMUZrPrLAJZ/P0EF26z9rk1d6arZFw==
X-YMail-OSG: WXDI4pEVM1mzNjAeiHITvIJ8dVW4WOikqWGNmPFhGCTFuIqrs8RSJPDC3W2wW_.
 OLOFT.JcVZslrkUwv_ETjVcoceWD4cgmF6KRZzmOePIg1kf6lpgJWx94lrPAwYLRhhIt2E7gwESe
 bf1QJ982OasGq._SNEJUj_H9.BUAL0EbXRnr.6osw2h1ngxrgbm4d65GTs0fKgycdaG_jeLdPSoF
 rk505eXmAv_z7AJMsiu0FUgFnI3RhXjXYPUf6hVranXdM78xEXDScmlYJt4WKBkd4sqgMUafNtce
 irqQfoYGRlOor4L_kbnAXYNgwxqvUCe5dQyUz.35nH4tGb5C7NJJJuMOcZwuBLL16I9JNhZ4JgKF
 3QPMubkg8rTozj5dSMXoPkAmRmWq0jNXA.Z41S7GgLvUpjCgdKVHrm2Ga7WsydlCaGUiaHfjB7eY
 fshUXR7EN4e6r0D31B9BMw82m6ywzw88ObMOLf.t3Iqe.ySda0R7xG7RejAFStTQ9fFVIJzBmdt1
 .HWmLPBZDFmxTfydvtjFZgA7jZcpnK.6vq1riXJhsnWTsQI.JELnkDZkhKzGYl87_c.W4Yn0_9nr
 VR_0nBT3xc847JlahyaDjqSd.gjaH3HeM6p8TZYuKSQkoufIh_Z5GKkZGxZhBgDXvdRjXmkmqGN.
 zyyxQwjGCmVG_FaodBgLkXBxvm4cfGEUzrgvUTSK1LOF2vPHzwY401utTfNGdLLZ97OrX9VesVeF
 KWnMa5an.7hc2b0ofBXBsgLc.dtGoDLWN8Ye_osxqbyIe0tKIyekjuJTJeh8lYr7ypm0C4uI4Qvv
 E0gAiGXWZtzI0m8753_NiJJujRx6t00xJGKnhO1E2ltVLlwHiLgVhQve3nGDVREdXbDLGimmdt6L
 cJxqKLQLr9RYPrwp0CcLIRGx.b4IJJpB0Vql11q5DeTM59xN.I9HMRb4CBt3.ty_4tq2TgT_ZDHH
 Gs88FqN4QRQ5IBhh5xktgWgUqo_iNXn9kqTJTGo3Kc39mjrSLOECwCGr0hmy5SyfhrbOf6NMr31W
 s0XRT4gVu6FDWAHPd1OR.7ZOQrCw9fNlSh6NgjoKr3kdw6WuYeep4pNB60rck5eTfcEogApRORAX
 .OhuVq6Ay1eAHM_SZ7LZQCkAkPe2rJviAnfedYC_zmvLoCIbW7EKTg8brhDXGjJsGOo9REfhznwm
 AXRAd0dO.iU7ktyRqbGNcz4tyiy17DVVCKOwLTWpVB5OOapFfq.ttajrR3Pxgy5MfZBCHspNFqqH
 RdZ7BtDI5x0HV23u_.gd7D96JhtkKi8skVC_JZAElgmQlNb_PB13XNaf3zM8SN0msjl5Hvr7Uuft
 k_9df.u.o.Yv.ob88Xq9VRA7.tljWEsorboUudsZJCn6Iee3XFg.x4wudZcPKLDMuOg2VZ3D.BQI
 PuliA4c1l9_sUQ2SZJMZF9EOpmLcwExKiTW4tD9JjUrvk1dthSr2BkcYDg8ZIoZcgAOnE8tONsw6
 dE7DD_rNNXS9cNDmsxyZtNmgl4.k7c5MnwQISdf789GqTttf.aIdUlKxWP1cXQz51TmS_t0nhBdY
 4WJxSiE5biQFJkQNskdX7ytt6fWYaTZIjI.Pkla5EopQl4rYrKj8LCSqO7SaWhbsGIdG9uIPGaOI
 u56vCf7sXHajb3Q7wxeNLiV5jfCYgv1FMH1HFrHm2LK9gkTI1ngPRHHAxiQp0tZKe.qDD6zIhREL
 9JU2AP3wvFMi39EeHtYYQePCI4BfZ0pdHUfQdBm1wu4k75BEHV21b3pMEmNu2HWN5REGKuLs0hg6
 nKGLDR6jmNqr6KB3uffQvHnkfIznFgJwI6JVygL_Yu0O9cvOSysR9QpQ.WTrA9INVmKXIAaBr1is
 ajxXxXuJSs5rlTEQYFgTNp.OC0qcjNyRsAr48zgbntMKs31JbcfV2ZQgDwFyJkN9sAsBqGQvtNix
 TiDyQ4nK2FfIcBVV0eMboKL8IhzL.atbI3Zu.WznH1IryhNFjI31KJA6FAvWskWz7UdQMBuy8xu4
 0WDgEFY21bhnau8sRn84WlNbXxJ6pOjp2bwtXyngmwlnp.3d0tYsaw7BekiQFb9LxtsZ1XjDQU57
 O1cFIcDl2av.nbVJLsAeqP6SXW1K5Xm9e5imDa14du2cY64xzqJ.07chycDmaPIYz9_NwvmJjD.J
 Z8ivsBeaRt2fm.1hgQ.feCWtX5p3Z0l6AVe5u9PW9mq9Vff3C0IVxATiIcgqwToaC8cqtIZohRc2
 5pTEaNR4vjYxUuh9TSCh7.mHZIXqs4OH9IsIzMiG7JVwWFzKW3Re3czfwaK2dVuM-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Dec 2022 19:11:00 +0000
Received: by hermes--production-ne1-7b69748c4d-7hwnr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f5f6c49f7d75e3c4fe4c0ce493dbe8ad;
          Sun, 18 Dec 2022 19:10:57 +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.200.110.1.12\))
Subject: RPi4B boot -v "pci0: failed to allocate bus number" and
 "device_attach: pci0 attach returned 6"; more
Message-Id: <7DDD8F49-B02C-484B-B92F-D894502B46DA@yahoo.com>
Date: Sun, 18 Dec 2022 11:10:45 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <7DDD8F49-B02C-484B-B92F-D894502B46DA.ref@yahoo.com>
X-Spamd-Result: default: False [-3.45 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.95)[-0.951];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NZsr726Vwz3Hkc
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

For reference, the example context used is
(long line output split for readability):

# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0
stable/13-n253133-b51ee7ac252c: Wed Nov 23 03:36:16 UTC 2022
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64 aarch64 1301509 1301509

(So: not my build.)

=46rom the boot -v capture:

pcib0:  mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0:  PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: Bus is not cache-coherent
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
pci1:  on pcib0
pci1: domain=3D0, physical bus=3D0
found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00
        domain=3D0, bus=3D0, slot=3D0, func=3D0
        class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0
        cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
        lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
        intpin=3Da, irq=3D0
        powerspec 3  supports D0 D3  current D0
        secbus=3D1, subbus=3D1
pcib1:  irq 91 at device 0.0 on pci1
pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
pcib1:   domain            0
pcib1:   secondary bus     1
pcib1:   subordinate bus   1
pcib1:   memory decode     0xc0000000-0xc00fffff
pci2:  on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci2
pci2: domain=3D0, physical bus=3D1
found-> vendor=3D0x1106, dev=3D0x3483, revid=3D0x01
        domain=3D0, bus=3D1, slot=3D0, func=3D0
        class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0
        cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
        lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
        intpin=3Da, irq=3D0
        powerspec 3  supports D0 D3  current D0
        MSI supports 4 messages, 64 bit
        map[10]: type Memory, range 64, base 0, size 12, memory disabled
pcib1: slot 0 INTA is routed to irq 92
bcm_xhci0:  irq 92 at =
device 0.0 on pci2
bcm_xhci0: note: xhci firmware not found.
bcm_xhci0: note: installing xhci firmware.
bcm_xhci0: note: xhci firmware detected; firmware is revision 138a1.
pcib1: allocated memory range (0xc0000000-0xc0000fff) for rid 10 of =
bcm_xhci0
bcm_xhci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xc0000000
bcm_xhci0: 32 bytes context size, 64-bit DMA
bcm_xhci0: attempting to allocate 1 MSI vectors (4 supported)
bcm_xhci0: using IRQ 93 for MSI
bcm_xhci0: MSI enabled
bcm_xhci0: (New XHCI DeviceId=3D0x34831106)
usbus0 on bcm_xhci0
bcm_xhci0: usbpf: Attached
bcm_xhci0: note: switched to 32-bit DMA.
pci0:  on pcib0
pci0: failed to allocate bus number
device_attach: pci0 attach returned 6

In order to get more directly comparable output, I tried
using lspci port and use of lspci on raspiOS64 (my
abbreviation) and fedora 37.

raspiOS64:

# lspci -v
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge =
(rev 10) (prog-if 00 [Normal decode])
        Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0
        Flags: bus master, fast devsel, latency 0
        Bus: primary=3D00, secondary=3D01, subordinate=3D01, =
sec-latency=3D0
        I/O behind bridge: 00000000-00000fff [size=3D4K]
        Memory behind bridge: c0000000-c00fffff [size=3D1M]
        Prefetchable memory behind bridge: [disabled]
        Capabilities: [48] Power Management version 3
        Capabilities: [ac] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [180] Vendor Specific Information: ID=3D0000 Rev=3D0=
 Len=3D028 
        Capabilities: [240] L1 PM Substates

01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host =
Controller (rev 01) (prog-if 30 [XHCI])
        Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller
        Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
        Flags: bus master, fast devsel, latency 0, IRQ 63
        Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K]
        Capabilities: [80] Power Management version 3
        Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+
        Capabilities: [c4] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Kernel driver in use: xhci_hcd

fedora:

# lspci -v
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge =
(rev 20) (prog-if 00 [Normal decode])
        Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0
        Flags: bus master, fast devsel, latency 0, IRQ 36
        Bus: primary=3D00, secondary=3D01, subordinate=3D01, =
sec-latency=3D0
        Memory behind bridge: 00000000-000fffff [size=3D1M] [32-bit]
        Prefetchable memory behind bridge: [disabled] [64-bit]
        Capabilities: [48] Power Management version 3
        Capabilities: [ac] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [180] Vendor Specific Information: ID=3D0000 Rev=3D0=
 Len=3D028 
        Capabilities: [240] L1 PM Substates
        Kernel driver in use: pcieport

01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller (rev 01) (prog-if 30 [XHCI])
        Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller
        Device tree node: =
/sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0/usb@0,0
        Flags: bus master, fast devsel, latency 0, IRQ 38
        Memory at 600000000 (64-bit, non-prefetchable) [size=3D4K]
        Capabilities: [80] Power Management version 3
        Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+
        Capabilities: [c4] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Kernel driver in use: xhci_hcd

(00:00.0's "Memory behind bridge" displayed based on
different spaces, unfortunately. Not as uniform as I
was intending. Still. . .)

FreeBSD:

# lspci -v
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge =
(prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 91
        Bus: primary=3D00, secondary=3D01, subordinate=3D01, =
sec-latency=3D0
        I/O behind bridge: 0000-0fff [size=3D4K] [16-bit]
        Memory behind bridge: c0000000-c00fffff [size=3D1M] [32-bit]
        Prefetchable memory behind bridge: [disabled] [64-bit]
        Capabilities: [48] Power Management version 3
        Capabilities: [ac] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [180] Vendor Specific Information: ID=3D0000 Rev=3D0=
 Len=3D028 
        Capabilities: [240] L1 PM Substates

01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller (rev 01) (prog-if 30 [XHCI])
        Subsystem: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 =
Controller
        Flags: bus master, fast devsel, latency 0, IRQ 92
        Memory at c0000000 (64-bit, non-prefetchable)
        Capabilities: [80] Power Management version 3
        Capabilities: [90] MSI: Enable+ Count=3D1/4 Maskable- 64bit+
        Capabilities: [c4] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting

Note the 01:00.0's "Memory at": c0000000 vs. 600000000 for
the two linux exmaples. (Also: No size shown for FreeBSD.)

According to "PhilE Raspberry Pi Engineer & Forum Moderator" at:

=
https://forums.raspberrypi.com/viewtopic.php?t=3D288902&sid=3D792675eb2c65=
13e936b1cd9fe385a038&start=3D75

QUOTE
It's worth stating a few facts:
(1) The PCIe controller in BCM2711 has a single outbound window. This =
means that all addresses for PCIe devices have to be mapped in a single =
block, such that the spacing in PCIe space matches the spacing in host =
physical address space.
(2) The size of the outbound window must be a power of two, and the base =
address of the outbound window must be aligned to that size.
END QUOTE

According to bcm2711-peripherals.pdf figure 1 the standard
placement of PCIe space is 0x600000000..0x7ffffffff (avoiding
overlaps with anything else in any space).

For reference, the live Device Tree for the FreeBSD context
has for pcie@7d500000 :

			ranges =3D <0x02000000 0x00000000 0xc0000000 =
0x00000006 0x00000000 0x00000000 0x40000000>;

The "0x00000006 0x00000000" part agrees with that "figure 1".
(More recent vintages agree for that part as well.)

I'm far from expert for such things but the 01:00.0 having
"Memory at c0000000 (64-bit, non-prefetchable)" looks
risky for PCI'e outbound memory mapping due to overlaps
having potential consequences.


An additional note of something that might be involved:

The RPi* firmware version that FreeBSD uses still has:

		pcie@7d500000 {
. . .
			pci@1,0 {
. . .
				usb@1,0 {
. . .

but modern firmware (such as in the raspiOS64 and
fedora I used) has:

                pcie@7d500000 {
. . .
                        pci@0,0 {
. . .
                                usb@0,0 {
. . .

I do not know if that is somehow related to
what I'm reporting or not.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 18 20:33:23 2022
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 4NZvgQ6gQRzt6p5
	for ; Sun, 18 Dec 2022 20:33:38 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530])
	(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 4NZvgQ2DLTz3jgy
	for ; Sun, 18 Dec 2022 20:33:38 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=yh3AW78r;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::530) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ed1-x530.google.com with SMTP id i9so10429785edj.4
        for ; Sun, 18 Dec 2022 12:33:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=UBpF85ub17VQVtaNAXTKD3qcztxM40Srt5Ypk/kueEw=;
        b=yh3AW78r7CNujpJYc1OLc4iIPU8O0jultOBIsSnF2BJY5Ehzbl14OhJ6OBQmElZ63n
         sbS+8Upvv2xYJDS7HqD/9W9xEVeRaKYm8HgeJH7O1nwD47SptH0U1dtZjN+EDOXsi3il
         Inrzq7v5ZpWbJBJAA0O754CWSBDC9wrPj/eE7RltubsqxaPiunj/L2ln3uArru3q0rOg
         23dtrukAYf2IX2MkinHrU28+XdA+b2mTHpG4siomI9VyMITwb8GqSqH14XAVw9aexpok
         iw7mVsjvnqdLeEcMhm2J3m1yJqXgtED1kzaXC7r1AssTaCf4GVw8Cp511hznDa7ma2N1
         qx6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=UBpF85ub17VQVtaNAXTKD3qcztxM40Srt5Ypk/kueEw=;
        b=NTNuYHIEBMjuHPTobij/PrMqDBwSO6A7kdWgxgdUgU93M5awT1wQRQPwi9RE2bxRX1
         nhyG1RsuGN2kovBbodVac/5mxVZepsbBFE9AKs+H4REZPMCstHxNDfi27KkhWSiuJu/v
         VbZ7gYIq/bMUOhXI0U/9krmNCnFgiljKj9XJnLn2IEiQY/XHugvufCqG1qrgftAXSYni
         hiiZLY2qKZmIPemykuESG/3JzdHIzD4vo2/uuzACnC3TXadUxi5NK2k6zMT0qkU7EOO4
         urzHL8FBDJ3uQprptbIoYeiwRRmv8s3CAZL+J+Uh/IOsSUF/lfVAdbMlnbS7zpgVgV+p
         jUqA==
X-Gm-Message-State: AFqh2kq93ZaHCVjnQ5YaKLXdFbX0AWqLmUc9CmfzeY2f8iKo60cFulwx
	DoAERpPVPesA7bGhDTfB5Ou2YdJLclEdBXEd/8yyLHJdFQ7xjT0h
X-Google-Smtp-Source: AMrXdXuSB/Kd4Iq2ijBATtEITPxjr55jimQpZd0psowO3rB18pgH4mXGJv/xUNj3cr44hIibIRrvV3STk8OA1Qg2AEg=
X-Received: by 2002:a05:6402:2203:b0:472:c7fe:4754 with SMTP id
 cq3-20020a056402220300b00472c7fe4754mr2095140edb.173.1671395615093; Sun, 18
 Dec 2022 12:33:35 -0800 (PST)
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: Sun, 18 Dec 2022 13:33:23 -0700
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000eac9fb05f0201de7"
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.994];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NZvgQ2DLTz3jgy
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000eac9fb05f0201de7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F) <
hiroo.ono+freebsd@gmail.com> wrote:

> Hello,
>
> I investigated a little more.
> I thought it was the kernel that did not run, but still it did not get
> through the loader.
>

Keep at it...


> The loader freezed in efi_do_vmap(), so I needed to add
> efi_disable_vmap=3D"YES" in loader.conf.
>

No. The code for this needs to be fixed...  More on that in a second...


> At last, in elf64_exec, it tried to run (*entry)(modulep) where the
> address entry is calculated from ehdr->e_entry by efi_translate() in
> stand/efi/loader/copy.c. There,
> ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
> but I modified a little) and
> stage_offset was 0x10000b33e0000.
> The sum of two which efi_translate() returns is 0x100000000b3400000.
> It overflows uint64_t and becomes 0xb3400000.
>

Yea, I think this is wrong.


> Currently, I do not understand well what the functions in
> stand/efi/loader/copy.c do, and do not know how to workaround this
> problem.
>

So there's two things going on here. First is that on arm64 we should
*NEVER* copy the
kernel. It loads at a specific address and we jump to where it loaded in
RAM (in your case,
I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernbase is
0xffff000000000000
so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you
suggest). The kernel
code that's there should do some tricks to find out where it was loaded,
turn on the MMU and
then jump to the VA to continue starting up the kernel. The arm64 kernel is
linked with a VA. Old amd64
kernels expected to start at a fixed physical address, but the UEFI spec
allows memory to be mapped anywhere
which means it was recently switched to create a page table in the boot
loader, then jump to the right
VA, and use the page table to find what PA that is and use that to
bootstrap the pmap. This works great on
amd64, but sometimes goes astray on arm64 (though the way it does for you
doesn't make sense
to me). The amd64 code used to start at a PA, and that's what the 'copy'
routine is supposed to do:
copy the kernel down that fixed address and jump to it. I don't think we'll
ever want that on arm64, though,
and that might also be getting in your way (thought I'm doing this from
memory w/o careful study of
the code because it's fresh in my mind due to getting arm64 working with
linuxboot).

Also, vmap *MUST* be called in the boot loader. The trouble is, it assumes
VA =3D=3D PA, but that's not
strictly true. If you boot via LinuxBoot, for example, it has a memory
mapping that's not VA =3D=3D PA so
at least some parts of the kernel fail their VA =3D=3D PA asserts. the vmap
code in the loader currently
blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the VA f=
rom
entry from the table from
the get memory map call is 0. Today it blindly overwrites it. You might try
changing that, and removing
the bit in the kernel that checks for VA =3D=3D PA and bails out if there's=
 a
mismatch. Here's the patch I'm
temporarily using until I have the time to do more than a quick,
superficial analysis of the issue:

diff --git a/sys/arm64/arm64/efirt_machdep.c
b/sys/arm64/arm64/efirt_machdep.c
index 727c9c37f94d..075174d164d8 100644
--- a/sys/arm64/arm64/efirt_machdep.c
+++ b/sys/arm64/arm64/efirt_machdep.c
@@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, int
descsz)
                        continue;
                if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {
                        if (bootverbose)
-                               printf("EFI Runtime entry %d is mapped\n",
i);
-                       goto fail;
+                               printf("EFI Runtime entry %d is mapped PA
%#lx VA %#lx\n", i, p->md_phys, p->md_virt);
+//                     goto fail;
                }
                if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
                        if (bootverbose)

clearly, not suitable for upstreaming, eh? And I have about 2 dozen commits
in my queue ahead of that
one that need refinement, review and upstreaming before I jump into this
issue. It will be after the first
of the year at least before I'll look at it since I just started my
year-end vacation...

Warner


> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
> >
> > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
> > >
> > >
> > >
> > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> > >>
> > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> > >>
> > >> >> OK, I (and the subject) was wrong. The loader boots, and show
> > >> >> following log at last:
> > >> >>
> > >> >> Loading kernel...
> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x14=
39ea]
> > >> >> Loading configured modules...
> > >> >> can't find '/boot/entropy'
> > >> >> can't find '/etc/hostid'
> > >> >> No valid device tree blob found!
> > >> >> WARNING! Trying to fire up the kernel, but no device tree blob
> found!
> > >> >> EFI framebuffer information
> > >> >> addr, size        0x80400000, 0x7e9000
> > >> >> dimensions     1920 x 1080
> > >> >> stride             1920
> > >> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> > >> >>
> > >> >> and it stops here. No "<>" line is displayed.
> > >> >> So, it seems that the kernel is loaded but could not be started.
> > >> >
> > >> >
> > >> > There are several causes of this.
> > >> >
> > >> > Most likely is that the console is setup to go somewhere else.
> Though if you are on the video display and getting that framebuffer outpu=
t,
> it won't not go there w/o some setting to override (say to force serial).
> > >>
> > >> In the loader, when comconsole->c_init() is called for the second
> > >> time, the function does not return. (I commented out comconsole to
> > >> make the loader work, but it is rather brutal and is not a proper
> > >> solution).
> > >> But the function parse_uefi_con_out() in stand/efi/loader/main.c
> > >> always returns RB_SERIAL, so the loader tries to use the serial
> > >> console.
> > >
> > >
> > > I wonder why that is. Is this -current or -stable? I have a rather
> large backlog of MFC-able loader changes. If it is with stable, then it
> makes sense: I fixed a bug where parse_uefi_con_out would return serial i=
f
> '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now =
we
> return Video console if we fine evidence there's a video console.
> >
> > It is stable/13.
> > I tried 14-current, and the same change to loader was needed (merging
> > OpenBSD's start.S and ldscript.arm64, and commenting out comconsole).
> > Even with these change, the console defaults to serial, so I changed
> > parse_uefi_con_out() to always return 0.
> > Still, it stops at the same point. The kernel does not seem to boot.
> >
> > Running efi-show from the loader prompt did not show
> > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
> > The variable name containing 'ConOut' were:
> >
> > global NV,BS,RS ConOut =3D
> >
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
> > global NV,BS,RS ConOutDev =3D
> >
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
> >
> > > Now, why it fails the second time, I don't know.
> > >
> > >>
> > >> If a similar thing happens with the kernel, it may be stopping at
> > >> serial console initialization.
> > >
> > >
> > > The kernel doesn't use the EFI routines to initialize the serial
> console. But if the kernel is being told the wrong console, then it could
> also be booting just fine or almost fine and hitting some bug later.
> > >
> > >>
> > >> > Next most likely is that FreeBSD doesn't cope well with having bot=
h
> FDT and ACPI information available. But since not DTB is being passed in
> (per that message) that's not likely at play here.
> > >>
> > >> I managed to load the dtb file and the boot process stopped at the
> > >> same point. The problem is not here?
> > >
> > >
> > > Yea, I don't think so.
> > >
> > > Warner
> > >
> > >>
> > >> > Finally, the loader passes a large number of tables, etc to the
> kernel. It's quite possible that, for reasons still unknown, that data is
> wrong or if standard conforming not expected by the kernel. this leads to=
 a
> crash before we've setup the console in the kernel which looks a lot like=
 a
> hang.
> > >> >
> > >> > Warner
> > >> >
> > >> >
> > >> >>
> > >> >> > . . .
> > >> >> >
> > >> >> > Such also happens for stable/13, releng/13.* based installation=
s
> > >> >> > as well --and likely others too.
> > >> >> >
> > >> >> > ACPI booting does not use Device Tree information but the
> messages
> > >> >> > are output anyway about the lack. Only if you know that the
> context
> > >> >> > is a Device Tree style of boot are the messages actually
> reporting
> > >> >> > a problem.
> > >> >> >
> > >> >> >
> > >> >> > =3D=3D=3D
> > >> >> > Mark Millard
> > >> >> > marklmi at yahoo.com
> > >> >> >
> > >> >>
>

--000000000000eac9fb05f0201de7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Dec 18, 2022 at 4:31 AM Hiroo=
 Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Hello,



I investigated a little more.

I thought it was the kernel that did not run, but still it did not get

through the loader.

Keep at it...
=

=C2=A0

The loader freezed in efi_do_vmap(), so I needed to add

efi_disable_vmap=3D"YES" in loader.conf.
No. The code for this needs to be fixed...=C2=A0 More on that i=
n a second...
=C2=A0

At last, in elf64_exec, it tried to run (*entry)(modulep) where the

address entry is calculated from ehdr->e_entry by efi_translate() in

stand/efi/loader/copy.c. There,

ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,

but I modified a little) and

stage_offset was 0x10000b33e0000.

The sum of two which efi_translate() returns is 0x100000000b3400000.

It overflows uint64_t and becomes 0xb3400000.

Yea, I think this is wrong.
=C2=A0

Currently, I do not understand well what the functions in

stand/efi/loader/copy.c do, and do not know how to workaround this

problem.

So there's two things goin=
g on here. First is that on arm64 we should *NEVER* copy the
kern=
el. It loads at a specific address and we jump to where it loaded in RAM (i=
n your case,
I think it should be stage_offset=C2=A0+ (ehdr->e=
_entry - KERNBASE). Kernbase is 0xffff000000000000
so we should j=
ump to 0x10000brre0000=C2=A0+ 0x20000 (or maybe 0x800 is you suggest). The =
kernel
code that's there should do some tricks to find out wh=
ere it was loaded, turn on the MMU and
then jump to the VA to con=
tinue starting up the kernel. The arm64 kernel is linked with a VA. Old amd=
64
kernels expected to start at a fixed physical address, but the=
 UEFI spec allows memory to be mapped anywhere
which means it was=
 recently switched to create a page table in the boot loader, then jump to =
the right
VA, and use the page table to find what PA that is and =
use that to bootstrap the pmap. This works great on
amd64, but so=
metimes goes astray on arm64 (though the way it does for you doesn't ma=
ke sense
to me). The amd64 code used to start at a PA, and that&#=
39;s what the 'copy' routine is supposed to do:
copy the =
kernel down that fixed address and jump to it. I don't think we'll =
ever want that on arm64, though,
and that might also be getting i=
n your way (thought I'm doing this from memory w/o careful study of
the code because it's fresh in my mind due to getting arm64 work=
ing with linuxboot).

Also, vmap *MUST* be called i=
n the boot loader. The trouble is, it assumes VA =3D=3D PA, but that's =
not
strictly true. If you boot via LinuxBoot, for example, it has=
 a memory mapping that's not VA =3D=3D PA so
at least some pa=
rts of the kernel fail their VA =3D=3D PA asserts. the vmap code in the loa=
der currently
blindly assumes VA =3D=3D PA, but it should, IMHO, =
only do that if the VA from entry from the table from
the get mem=
ory map call is 0. Today it blindly overwrites it. You might try changing t=
hat, and removing
the bit in the kernel that checks for VA =3D=3D=
 PA and bails out if there's a mismatch. Here's the patch I'm
temporarily using until I have the time to do more than a quick, s=
uperficial analysis of the issue:

diff --git a/sys=
/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_machdep.c
index 727=
c9c37f94d..075174d164d8 100644
--- a/sys/arm64/arm64/efirt_machdep.c
=
+++ b/sys/arm64/arm64/efirt_machdep.c
@@ -193,8 +193,8 @@ efi_create_1t1=
_map(struct efi_md *map, int ndesc, int descsz)
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p->md_virt !=
=3D 0 && p->md_virt !=3D p->md_phys) {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (boot=
verbose)
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("EFI Runtime entr=
y %d is mapped\n", i);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto fail;
+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 printf("EFI Runtime entry %d is mapped PA %#lx VA %#lx\n",=
 i, p->md_phys, p->md_virt);
+// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto fail;
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (bootverbose)

clearly, not suita=
ble for upstreaming, eh? And I have about 2 dozen commits in my queue ahead=
 of that
one that need refinement, review and upstreaming before =
I jump into this issue. It will be after the first
of the year at=
 least before I'll look at it since I just started my year-end vacation=
...

Warner
=C2=A0

2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:

>

> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh <imp@bsdimp.com>:
> >

> >

> >

> > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=
=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:

> >>

> >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Los=
h <imp@bsdimp.com>:

> >> >

> >> >

> >> >

> >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:

> >>

> >> >> OK, I (and the subject) was wrong. The loader boots,=
 and show

> >> >> following log at last:

> >> >>

> >> >> Loading kernel...

> >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 tex=
t=3D0x1f97ac

> >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11=
f6a0+0x8+0x1439ea]

> >> >> Loading configured modules...

> >> >> can't find '/boot/entropy'

> >> >> can't find '/etc/hostid'

> >> >> No valid device tree blob found!

> >> >> WARNING! Trying to fire up the kernel, but no device=
 tree blob found!

> >> >> EFI framebuffer information

> >> >> addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x80400000, 0x=
7e9000

> >> >> dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080

> >> >> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A01920

> >> >> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x00f=
f0000, 0x0000ff00, 0x000000ff, 0xff000000

> >> >>

> >> >> and it stops here. No "<<BOOT>>&quo=
t; line is displayed.

> >> >> So, it seems that the kernel is loaded but could not=
 be started.

> >> >

> >> >

> >> > There are several causes of this.

> >> >

> >> > Most likely is that the console is setup to go somewhere=
 else. Though if you are on the video display and getting that framebuffer =
output, it won't not go there w/o some setting to override (say to forc=
e serial).

> >>

> >> In the loader, when comconsole->c_init() is called for the=
 second

> >> time, the function does not return. (I commented out comconso=
le to

> >> make the loader work, but it is rather brutal and is not a pr=
oper

> >> solution).

> >> But the function parse_uefi_con_out() in stand/efi/loader/mai=
n.c

> >> always returns RB_SERIAL, so the loader tries to use the seri=
al

> >> console.

> >

> >

> > I wonder why that is. Is this -current or -stable? I have a rathe=
r large backlog of MFC-able loader changes. If it is with stable, then it m=
akes sense: I fixed a bug where parse_uefi_con_out would return serial if &=
#39;8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?=
=C2=A0 Now we return Video console if we fine evidence there's a video =
console.

>

> It is stable/13.

> I tried 14-current, and the same change to loader was needed (merging<=
br>
> OpenBSD's start.S and ldscript.arm64, and commenting out comconsol=
e).

> Even with these change, the console defaults to serial, so I changed
> parse_uefi_con_out() to always return 0.

> Still, it stops at the same point. The kernel does not seem to boot.
>

> Running efi-show from the loader prompt did not show

> '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'

> The variable name containing 'ConOut' were:

>

> global NV,BS,RS ConOut =3D

> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-=
0482-27D14ED47D72)/Uart(115200,8,N,1)

> global NV,BS,RS ConOutDev =3D

> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-=
0482-27D14ED47D72)/Uart(115200,8,N,1)

>

> > Now, why it fails the second time, I don't know.

> >

> >>

> >> If a similar thing happens with the kernel, it may be stoppin=
g at

> >> serial console initialization.

> >

> >

> > The kernel doesn't use the EFI routines to initialize the ser=
ial console. But if the kernel is being told the wrong console, then it cou=
ld also be booting just fine or almost fine and hitting some bug later.

> >

> >>

> >> > Next most likely is that FreeBSD doesn't cope well w=
ith having both FDT and ACPI information available. But since not DTB is be=
ing passed in (per that message) that's not likely at play here.

> >>

> >> I managed to load the dtb file and the boot process stopped a=
t the

> >> same point. The problem is not here?

> >

> >

> > Yea, I don't think so.

> >

> > Warner

> >

> >>

> >> > Finally, the loader passes a large number of tables, etc=
 to the kernel. It's quite possible that, for reasons still unknown, th=
at data is wrong or if standard conforming not expected by the kernel. this=
 leads to a crash before we've setup the console in the kernel which lo=
oks a lot like a hang.

> >> >

> >> > Warner

> >> >

> >> >

> >> >>

> >> >> > . . .

> >> >> >

> >> >> > Such also happens for stable/13, releng/13.* ba=
sed installations

> >> >> > as well --and likely others too.

> >> >> >

> >> >> > ACPI booting does not use Device Tree informati=
on but the messages

> >> >> > are output anyway about the lack. Only if you k=
now that the context

> >> >> > is a Device Tree style of boot are the messages=
 actually reporting

> >> >> > a problem.

> >> >> >

> >> >> >

> >> >> > =3D=3D=3D

> >> >> > Mark Millard

> >> >> > marklmi at yahoo.com

> >> >> >

> >> >>




--000000000000eac9fb05f0201de7--

From nobody Sun Dec 18 21:00:58 2022
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 4NZwGz1Kwzz1Fxpp
	for ; Sun, 18 Dec 2022 21:00:59 +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 4NZwGy6DgSz3q4b
	for ; Sun, 18 Dec 2022 21: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=1671397258;
	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=0wUqKJpeCtog8NB8CoiZpfRcM6sapEggmEyERaPCSOk=;
	b=Uxgnl+uQD7jb8ozB4oEyM62txZuazjnncwH+BlgLK2JepgaLNzPsJ0VUx93KeG0GVlesp2
	eNrLYJRBDFNt9owlPz5CNrBgBwTirxWy3MA7X4zvHkJfexTnQqhm4K/r+04wWeMZ5mRXa6
	asyubbxgeRSsCDWBbpfEfvzggicn8DOBVgS/pLOvbcYMWW1L/Ox+nsyGTh/kCBCpur781E
	l4kh9+JzcjtFxibp3+TPF4Dj+slICnyXJlKKwonx19JFORTI+DCg4kfkEoL2KbRGqNqIyn
	WP7XkawI5AI4PwnFsUZXzOEEx9QPuEe8Z6x4tMhWMaR0r1PD9MrTcgagMDGxXQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671397258; a=rsa-sha256; cv=none;
	b=gM1s/02AQtHyVmg2W1bjK69qzMt+UpwS5CqqG8w7HLsj/D9Lyr1UEbco9Mg33AaZ/Urp9x
	2MP861YQlbCo7HwSZxJFdTtBGyMY3xCF1EdICbjHdmWrghReWV+xj1Fn/IPwk5yChS+h2m
	noBJm8Z7hktjKcQnI056D6+FxIKFk6GA12MhpJb3ZkLh6SNr6crudkuQBvsdM7jlp6this
	lF1I2Xfmu0wcQpuzYQFaSKgc/MPMofEQoqg4JHiDltZk8uLxFMet/5AfjgIfxTviGOaGyY
	ZUBooi50EzS4FT0FXfobAe0oPDNRxJClnlpH22q03MDHMU+LTqowHoiRIE7btw==
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 4NZwGy5LkqzVsH
	for ; Sun, 18 Dec 2022 21: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 2BIL0wpb090769
	for ; Sun, 18 Dec 2022 21:00:58 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BIL0wVm090768
	for freebsd-arm@FreeBSD.org; Sun, 18 Dec 2022 21:00:58 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202212182100.2BIL0wVm090768@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, 18 Dec 2022 21:00:58 +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="16713972581.6dDC9F.86272"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16713972581.6dDC9F.86272
Date: Sun, 18 Dec 2022 21:00:58 +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.

--16713972581.6dDC9F.86272
Date: Sun, 18 Dec 2022 21:00:58 +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.


--16713972581.6dDC9F.86272--

From nobody Thu Dec 22 23:36:00 2022
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 4NdRX109hkz1H139
	for ; Thu, 22 Dec 2022 23:36:01 +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 4NdRX04QWgz40sH
	for ; Thu, 22 Dec 2022 23:36:00 +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=1671752160;
	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=wn8CuL4B5xR03i2w0ndmDgpQMxpNR1ys7jpEsSVQd18=;
	b=uP6k+OOieiBu6Iv/Y2RVGlBivs7oAvloYrJe2qzkgI9AsRKkt60MycFui/RyUA+3M3bbD+
	r80yLJQngy6dLUSi/2fk17azo6QRUsuIuZZwxD0b5oMQutW0Sv/Bsq6E5n4fIOgkiWSan9
	M30O/8AAAqHBVu+2i7FTZalYo+EOaKc4Xu0wdGMmlWY9np+dqwd6/1Ldj8nS6/NzPyXSmY
	aNYHL4oKHhBrqfPiVfOK9mHmJzAIowgvf8tOenFrUqvLVC3SliLMBSIGvGwr7ufMr0rGNU
	CVWMSo3q+zRmwhWTtApXq2uROm/Hyv9kD/94TgM+YZ1ETj9L98zYVrUhiv4Xtg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671752160; a=rsa-sha256; cv=none;
	b=qjmQUcBlJrOVXuFG7QTPNGJ/vEm2ALmoMTzT9QtPAHTzsRane0ywcGKcvFPA67eiNNvWTG
	iwsJ4ekt4BF14RHsB7welCCJfOzp5eMVCsvzmOukZC5F9j4OGkrN7KatNFRyWSAmlC9W/E
	vSB3j1Wu9NHr0uDX1DNKukiJCrhppB0WbADEsDFTJDi9MMWfEbUXpskUfnmU0uajJbvJUk
	eIjW63BtVnIY5zrStixSY0mXYcaiDWUz9XU/+OpeUJobLsHw7ybzdIgwaoEGmA39y6aPmO
	e6X3TqpJOVsn2SaoqAxUnkBrYfLzls64RvNDII1tDLed8Na/4S6OGA5mfAKEsA==
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 4NdRX03Vb8z1C4m
	for ; Thu, 22 Dec 2022 23:36:00 +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 2BMNa0GZ016688
	for ; Thu, 22 Dec 2022 23:36:00 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BMNa0Xo016686
	for freebsd-arm@FreeBSD.org; Thu, 22 Dec 2022 23:36:00 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 268521] [PATCH] arm64 libc: fix longjmp with 0 value
Date: Thu, 22 Dec 2022 23:36:00 +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: Unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Many People
X-Bugzilla-Who: alois+freebsd@aloisklink.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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268521

            Bug ID: 268521
           Summary: [PATCH] arm64 libc: fix longjmp with 0 value
           Product: Base System
           Version: Unspecified
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: alois+freebsd@aloisklink.com

Created attachment 238981
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D238981&action=
=3Dedit
`git format-patch` patch file

On arm64/aarch64, calling `longjmp(x, 0);` makes `setjmp(x)` return 0,
which normally causes an infinite loop, and is against the ISO C
standard for setjmp/longjmp. Instead, using a value of 0 should
make `setjmp` return 1:

> The `longjmp` function cannot cause the `setjmp` macro to return the
> value 0; if `val` is 0, the `setjmp` macro returns the value 1.
>
> _Taken from =C2=A77.13.2.1.4 of the C99 spec_

This has already been reported in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255320, but the contrib=
uting
docs weren't clear on what to do if I had a patch for an already existing
problem report, so I thought I'd make another problem report so it has
`[PATCH]` in the name.

My commit is also available on GitHub
https://github.com/aloisklink/freebsd-src/tree/fix-longjmp-with-0-val

I also have a patch that adds tests for `longjmp(x, 0)` at
https://github.com/aloisklink/freebsd-src/commit/007af6a46677b143f9544fd30e=
30a1b9f1048ae6
However, since there might be a few architectures that suffer from this bug,
I'm not 100% sure if this okay to merge. I'll make a new PR for it.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Dec 24 00:48:57 2022
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 4Nf55z2b1Zz1H2bX
	for ; Sat, 24 Dec 2022 00:49:11 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e])
	(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 4Nf55y1Yq4z3Gk6
	for ; Sat, 24 Dec 2022 00:49:10 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=aiSOop0M;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x102e.google.com with SMTP id c8-20020a17090a4d0800b00225c3614161so2953345pjg.5
        for ; Fri, 23 Dec 2022 16:49:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=m4sbKfepo/kRXQdeXYMf6i9Mn5unKF7LMqiWThnvW9E=;
        b=aiSOop0MgmK0NPDpvMSBt2U2LXCK9SP7sPvtzwEXYHIP4jJ+ynAa6W1Jh3uMNLyXvu
         KTQEzn28n57ZHbRbJ/4DQrox5MDCh6Nx6SkPW/SGhm/It/4w/F/lWcmkIBDvBBmnZRS5
         CUd6YjaeQKVmz9qd95pQd2EzOiKstiO+Z3bkArypqq9Ffa4UN5GHPxXGZzL3gaAihExR
         S8fDKNJmqVw8vBg/lUV+ZGXvPFRR0rZkvdZPzxIZu+RB3mXCQmZwWH10xxVdRd7zwP06
         bIfiAZ1rQnRwSE+56kAcTlYjr+7BLqwUv292oKBwV4N17rfN5VtVJAYt4mvgzSXLw5Jx
         TFDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=m4sbKfepo/kRXQdeXYMf6i9Mn5unKF7LMqiWThnvW9E=;
        b=Nv6AqY6HnGw+So1ytIcp8ORdGHkh++nEH8rrqA8+/U868JiKbNLzpDxJZpKLnspuTp
         Iywkcs1DOu7nGaIKUIa/bNQPsd8GiG+HXDvIIgtwgyAVWP/M5SriY6RjQYGhUhVe/pLp
         87lE2wrnv0KiYKt1jQU+Oyo/pf/oeLHJE/nbj53TwrP0MHwB2l2RkYSNoNpFYhF2M91n
         Rg/R5YLNZg0MPp2tpnHrk1LgeSe6XBr3JAfhHSTO19v7Oiid0Cs8448kwvRI+486j2UF
         uUJUWGkbT3LFs7szG7kTrylZzV4zSfoS/zKwc2eqQVAH0YNIm6ueDS6OI/tYaxEo67vA
         adoQ==
X-Gm-Message-State: AFqh2krPvB/hrAjlwJNjqFs8zVwNecAKTYk/uvZ7qYUpKeZ9iy0gzgnf
	ZGv+8tWHUSQuE0g1x9tDPPAJ/kfC7Ji4/H7x+fk=
X-Google-Smtp-Source: AMrXdXv/LXD2XaqOE0HyAaUdH6UysPyKJx1qhR8bZnZ4xER5l5WQ1EfiH8428of84NSoMo6M/qVFTlGZ72caRSt7qfs=
X-Received: by 2002:a17:90a:d50c:b0:219:8b1b:bcfa with SMTP id
 t12-20020a17090ad50c00b002198b1bbcfamr1063077pju.235.1671842948623; Fri, 23
 Dec 2022 16:49:08 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sat, 24 Dec 2022 09:48:57 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-3.74 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_LONG(-0.75)[-0.748];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-Rspamd-Queue-Id: 4Nf55y1Yq4z3Gk6
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

The current status of FreeBSD 14-current on Lenovo Yoga C630 is as follows:

 1) Merging from OpenBSD's loader code made the loader boot apart from
3 points (#2 to 4 ).
 2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
(might be C630 specific)
 3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
affect other snapdragon systems like Microsoft Arm Developer Kit)
 4) The kernel is kicked but does not start.

1) is quite straightforward. What needs to be changed is
stand/efi/loader/arch/arm64/start.S.
For 2), I do not know what to do. Currently, I commented out
comconsole from struct console *consoles[] in stand/efi/loader/conf.c
as a workaround. Maybe, I should write a fault handler that helps
returning from the fault.
3), I dumped each memory map's VirtualStart and PhysicalStart. All
VirtualStart were 0. So overwriting VirutalStart by the value of
PhysicalStart and running SetVirtualAddressMap should work. But in
reality, it doesn't.
  OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to
have abandoned it for arm64 in 2019.
    https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=
=3D4e46c2a956215482418d7b315749fb1b6c6bc224
  Maybe, we also can avoid SetVirtualAddressMap (by
efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should change
the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to do
so).
About 4), I am completely confused. In elf64_exec in
stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel
was loaded is calculated as:
    entry =3D efi_translate(ehdr->e_entry);  // which becomes 0xb340000
and later kicked as:
    (*entry)(modulep);
I wrote that this calculation is doubtful, but it was right. I dumped
the data at the address 0xb340000 and compared it with the output of
objdump -D loader_lua.syms. It turned out that it matched with the
kernel's _start code in locore.S.
Putting some code that jumps to loader's ImageBase address at the
start of kernel's _start did not change anything, so I judged that the
kernel is not started at all.
The excerpt of the loader's memmap command output is as follows:
    Type           Physical           Virtual              #Pages     Attr
    LoaderData 0000b33ea000  000000000000  00000000  UC WC WT WB WP RP XP
    LoaderCode 0000bb909000  000000000000  000000d1 UC WC WT WB WP RP XP
>From this output, I wonder if the memory attributes on Yoga C630 is
properly implemented, but as XP (exec protect) bit is on, I tried to
set it off by DXE services' SetMemoryAttributes() (with a lot of
transcription from the standards...).It succeeded, but the kernel
still did not run.

>From this tweet:
https://twitter.com/canadianbryan/status/1598053941270679552 and its
replies, the Microsoft Arm Developer Kit seems to have similar
problem, so if somebody succeeded to run FreeBSD on it, please share
the information how to do it.

2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh :

>
>
>
> On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F)  wrote:
>>
>> Hello,
>>
>> I investigated a little more.
>> I thought it was the kernel that did not run, but still it did not get
>> through the loader.
>
>
> Keep at it...
>
>>
>> The loader freezed in efi_do_vmap(), so I needed to add
>> efi_disable_vmap=3D"YES" in loader.conf.
>
>
> No. The code for this needs to be fixed...  More on that in a second...
>
>>
>> At last, in elf64_exec, it tried to run (*entry)(modulep) where the
>> address entry is calculated from ehdr->e_entry by efi_translate() in
>> stand/efi/loader/copy.c. There,
>> ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
>> but I modified a little) and
>> stage_offset was 0x10000b33e0000.
>> The sum of two which efi_translate() returns is 0x100000000b3400000.
>> It overflows uint64_t and becomes 0xb3400000.
>
>
> Yea, I think this is wrong.
>
>>
>> Currently, I do not understand well what the functions in
>> stand/efi/loader/copy.c do, and do not know how to workaround this
>> problem.
>
>
> So there's two things going on here. First is that on arm64 we should *NE=
VER* copy the
> kernel. It loads at a specific address and we jump to where it loaded in =
RAM (in your case,
> I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernbase =
is 0xffff000000000000
> so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you sug=
gest). The kernel
> code that's there should do some tricks to find out where it was loaded, =
turn on the MMU and
> then jump to the VA to continue starting up the kernel. The arm64 kernel =
is linked with a VA. Old amd64
> kernels expected to start at a fixed physical address, but the UEFI spec =
allows memory to be mapped anywhere
> which means it was recently switched to create a page table in the boot l=
oader, then jump to the right
> VA, and use the page table to find what PA that is and use that to bootst=
rap the pmap. This works great on
> amd64, but sometimes goes astray on arm64 (though the way it does for you=
 doesn't make sense
> to me). The amd64 code used to start at a PA, and that's what the 'copy' =
routine is supposed to do:
> copy the kernel down that fixed address and jump to it. I don't think we'=
ll ever want that on arm64, though,
> and that might also be getting in your way (thought I'm doing this from m=
emory w/o careful study of
> the code because it's fresh in my mind due to getting arm64 working with =
linuxboot).
>
> Also, vmap *MUST* be called in the boot loader. The trouble is, it assume=
s VA =3D=3D PA, but that's not
> strictly true. If you boot via LinuxBoot, for example, it has a memory ma=
pping that's not VA =3D=3D PA so
> at least some parts of the kernel fail their VA =3D=3D PA asserts. the vm=
ap code in the loader currently
> blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the VA=
 from entry from the table from
> the get memory map call is 0. Today it blindly overwrites it. You might t=
ry changing that, and removing
> the bit in the kernel that checks for VA =3D=3D PA and bails out if there=
's a mismatch. Here's the patch I'm
> temporarily using until I have the time to do more than a quick, superfic=
ial analysis of the issue:
>
> diff --git a/sys/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_mach=
dep.c
> index 727c9c37f94d..075174d164d8 100644
> --- a/sys/arm64/arm64/efirt_machdep.c
> +++ b/sys/arm64/arm64/efirt_machdep.c
> @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, int=
 descsz)
>                         continue;
>                 if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {
>                         if (bootverbose)
> -                               printf("EFI Runtime entry %d is mapped\n"=
, i);
> -                       goto fail;
> +                               printf("EFI Runtime entry %d is mapped PA=
 %#lx VA %#lx\n", i, p->md_phys, p->md_virt);
> +//                     goto fail;
>                 }
>                 if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
>                         if (bootverbose)
>
> clearly, not suitable for upstreaming, eh? And I have about 2 dozen commi=
ts in my queue ahead of that
> one that need refinement, review and upstreaming before I jump into this =
issue. It will be after the first
> of the year at least before I'll look at it since I just started my year-=
end vacation...
>
> Warner
>
>>
>> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
>> >
>> > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
>> > >
>> > >
>> > >
>> > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F)  wrote:
>> > >>
>> > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=
=AF=9B=E7=94=9F)  wrote:
>> > >>
>> > >> >> OK, I (and the subject) was wrong. The loader boots, and show
>> > >> >> following log at last:
>> > >> >>
>> > >> >> Loading kernel...
>> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97ac
>> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0x1=
439ea]
>> > >> >> Loading configured modules...
>> > >> >> can't find '/boot/entropy'
>> > >> >> can't find '/etc/hostid'
>> > >> >> No valid device tree blob found!
>> > >> >> WARNING! Trying to fire up the kernel, but no device tree blob f=
ound!
>> > >> >> EFI framebuffer information
>> > >> >> addr, size        0x80400000, 0x7e9000
>> > >> >> dimensions     1920 x 1080
>> > >> >> stride             1920
>> > >> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>> > >> >>
>> > >> >> and it stops here. No "<>" line is displayed.
>> > >> >> So, it seems that the kernel is loaded but could not be started.
>> > >> >
>> > >> >
>> > >> > There are several causes of this.
>> > >> >
>> > >> > Most likely is that the console is setup to go somewhere else. Th=
ough if you are on the video display and getting that framebuffer output, i=
t won't not go there w/o some setting to override (say to force serial).
>> > >>
>> > >> In the loader, when comconsole->c_init() is called for the second
>> > >> time, the function does not return. (I commented out comconsole to
>> > >> make the loader work, but it is rather brutal and is not a proper
>> > >> solution).
>> > >> But the function parse_uefi_con_out() in stand/efi/loader/main.c
>> > >> always returns RB_SERIAL, so the loader tries to use the serial
>> > >> console.
>> > >
>> > >
>> > > I wonder why that is. Is this -current or -stable? I have a rather l=
arge backlog of MFC-able loader changes. If it is with stable, then it make=
s sense: I fixed a bug where parse_uefi_con_out would return serial if '8be=
4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now we ret=
urn Video console if we fine evidence there's a video console.
>> >
>> > It is stable/13.
>> > I tried 14-current, and the same change to loader was needed (merging
>> > OpenBSD's start.S and ldscript.arm64, and commenting out comconsole).
>> > Even with these change, the console defaults to serial, so I changed
>> > parse_uefi_con_out() to always return 0.
>> > Still, it stops at the same point. The kernel does not seem to boot.
>> >
>> > Running efi-show from the loader prompt did not show
>> > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
>> > The variable name containing 'ConOut' were:
>> >
>> > global NV,BS,RS ConOut =3D
>> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-=
0482-27D14ED47D72)/Uart(115200,8,N,1)
>> > global NV,BS,RS ConOutDev =3D
>> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-=
0482-27D14ED47D72)/Uart(115200,8,N,1)
>> >
>> > > Now, why it fails the second time, I don't know.
>> > >
>> > >>
>> > >> If a similar thing happens with the kernel, it may be stopping at
>> > >> serial console initialization.
>> > >
>> > >
>> > > The kernel doesn't use the EFI routines to initialize the serial con=
sole. But if the kernel is being told the wrong console, then it could also=
 be booting just fine or almost fine and hitting some bug later.
>> > >
>> > >>
>> > >> > Next most likely is that FreeBSD doesn't cope well with having bo=
th FDT and ACPI information available. But since not DTB is being passed in=
 (per that message) that's not likely at play here.
>> > >>
>> > >> I managed to load the dtb file and the boot process stopped at the
>> > >> same point. The problem is not here?
>> > >
>> > >
>> > > Yea, I don't think so.
>> > >
>> > > Warner
>> > >
>> > >>
>> > >> > Finally, the loader passes a large number of tables, etc to the k=
ernel. It's quite possible that, for reasons still unknown, that data is wr=
ong or if standard conforming not expected by the kernel. this leads to a c=
rash before we've setup the console in the kernel which looks a lot like a =
hang.
>> > >> >
>> > >> > Warner
>> > >> >
>> > >> >
>> > >> >>
>> > >> >> > . . .
>> > >> >> >
>> > >> >> > Such also happens for stable/13, releng/13.* based installatio=
ns
>> > >> >> > as well --and likely others too.
>> > >> >> >
>> > >> >> > ACPI booting does not use Device Tree information but the mess=
ages
>> > >> >> > are output anyway about the lack. Only if you know that the co=
ntext
>> > >> >> > is a Device Tree style of boot are the messages actually repor=
ting
>> > >> >> > a problem.
>> > >> >> >
>> > >> >> >
>> > >> >> > =3D=3D=3D
>> > >> >> > Mark Millard
>> > >> >> > marklmi at yahoo.com
>> > >> >> >
>> > >> >>

From nobody Sat Dec 24 01:03:07 2022
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 4Nf5QK0WWvz1H4bj
	for ; Sat, 24 Dec 2022 01:03:21 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
	(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 4Nf5QJ1QJ7z3JT2
	for ; Sat, 24 Dec 2022 01:03:20 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=nCxqt2zT;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::532) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ed1-x532.google.com with SMTP id q15so7404621edb.1
        for ; Fri, 23 Dec 2022 17:03:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=8ix29Dywhtk3KwjKzsgmPOLMrVmzKq2lyZHXkJrDpwc=;
        b=nCxqt2zT3oUm9apO6wnSZCbZhfQRxdU+0OVf5XfgHKMp7GQmN/V0yIxYODY/ReLaeG
         2s+yCpW2JpDRZr/hoAWUrkO3U0mT/CQkh13PpEVzW9eRZD0hJJpIaSnvlyD90Zdx9+oR
         bynKvjtSt9Gc03rqmvtD+99UzpQe/LsRvZrF98bqnh5H5m8Wm35L89IUxRw2Fv5WGWNY
         IUcG1Hv8NAf4t/orI8hhKl5lf5ISdSb7M90+wzz2qlOSMeSGy1C733BL53mV9m3xvv+Y
         FTuPOIcZD5eTP7pyJFR8DRLlUAbnwdvIqOz2eN5zEgjpYV6sPbRaH81SIWQI6bTmfSBC
         8Rhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=8ix29Dywhtk3KwjKzsgmPOLMrVmzKq2lyZHXkJrDpwc=;
        b=cwFMIx1aqZcHHupDodjeex4FP0wnA+zeylHMKdSA8iNq4wg0Hf+MyDKncHOSzvJKyB
         xot0aDUhuFXMtPjVy0++SfXgQOIx2rrjiVVZf//AV0pk8jk/Z3+DVsobwsVAUETAa7sW
         MrrKDUA45PgtwfFVrucOYPODUI76YVsVo3Z2e3XEkdjBnU8VJFcmFRBC+V437cooTgWd
         TAGh/w9vuy+BhXUjnbN/hR3esNTFxsW1qgD1nskSg5O1cbtf5RpsBKSyJxrIiYP7EJzi
         El+q2Pkh9WKH9pz9Nxfd38Q+Yj8VeDDNdJ5pNe9yDKbBzKIi1SeqBAdVLsJ3oCgMTQjh
         sOVA==
X-Gm-Message-State: AFqh2kqEcObhMTnbah+RLxc8z6h3eDaoTfBWfxIZIC7df6YvbRuCFMMI
	pFU3QqBobI2beaN8YkZo5iLPdHIcf6WUj6xC0xnDvQ==
X-Google-Smtp-Source: AMrXdXvDSy+VUqDjtpi4+MNciGwenhxJSaNjr+hP0iGAHwgjb3fJB+QtCMkM5VC0yRWwLAbAU3PpU4G85IMgBAJN500=
X-Received: by 2002:a05:6402:b18:b0:46b:1396:e132 with SMTP id
 bm24-20020a0564020b1800b0046b1396e132mr1336403edb.421.1671843798239; Fri, 23
 Dec 2022 17:03:18 -0800 (PST)
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: Fri, 23 Dec 2022 18:03:07 -0700
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000b6dfee05f0887747"
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4Nf5QJ1QJ7z3JT2
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b6dfee05f0887747
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F) <
hiroo.ono+freebsd@gmail.com> wrote:

> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as follow=
s:
>
>  1) Merging from OpenBSD's loader code made the loader boot apart from
> 3 points (#2 to 4 ).
>  2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
> (might be C630 specific)
>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
> affect other snapdragon systems like Microsoft Arm Developer Kit)
>  4) The kernel is kicked but does not start.
>
> 1) is quite straightforward. What needs to be changed is
> stand/efi/loader/arch/arm64/start.S.
>

Can you share what needs to be done? To my eye, we don't need any changes,
so it would be good to know what you've had to do exactly.


> For 2), I do not know what to do. Currently, I commented out
> comconsole from struct console *consoles[] in stand/efi/loader/conf.c
> as a workaround. Maybe, I should write a fault handler that helps
> returning from the fault.
>

There were problems with this with HyperV on aarch64 too.

Something like
diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiserialio.=
c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/stand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@ -261,11 +261,11 @@ comc_probe(struct console *sc)
                if (comc_port =3D=3D NULL)
                        return;
        }
-       comc_port->baudrate =3D COMSPEED;
+       comc_port->baudrate =3D 0;
        comc_port->ioaddr =3D 0;                  /* default port */
-       comc_port->databits =3D 8;                /* 8,n,1 */
-       comc_port->parity =3D NoParity;           /* 8,n,1 */
-       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
+       comc_port->databits =3D 0;                /* 8,n,1 */
+       comc_port->parity =3D 0;          /* 8,n,1 */
+       comc_port->stopbits =3D 0;        /* 8,n,1 */
        comc_port->ignore_cd =3D 1;               /* ignore cd */
        comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on */
        comc_port->sio =3D NULL;

was needed.  Possibly the following would be better:

diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiserialio.=
c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/stand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@ -494,8 +494,7 @@ comc_setup(void)
                return (false);

        status =3D comc_port->sio->SetAttributes(comc_port->sio,
-           comc_port->baudrate, 0, 0, comc_port->parity,
-           comc_port->databits, comc_port->stopbits);
+           0, 0, 0, 0, 0, 0);
        if (EFI_ERROR(status))
                return (false);



> 3), I dumped each memory map's VirtualStart and PhysicalStart. All
> VirtualStart were 0. So overwriting VirutalStart by the value of
> PhysicalStart and running SetVirtualAddressMap should work. But in
> reality, it doesn't.
>   OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to
> have abandoned it for arm64 in 2019.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=3D=
4e46c2a956215482418d7b315749fb1b6c6bc224
>   Maybe, we also can avoid SetVirtualAddressMap (by
> efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should change
> the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to do
> so).
>

FreeBSD tends to prefer this... Our kernel needs to cope with cases where
it has
been called (many kexec environments provide PA !=3D VA virtual mappings th=
at
we
can't change).


> About 4), I am completely confused. In elf64_exec in
> stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel
> was loaded is calculated as:
>     entry =3D efi_translate(ehdr->e_entry);  // which becomes 0xb340000
> and later kicked as:
>     (*entry)(modulep);
> I wrote that this calculation is doubtful, but it was right. I dumped
> the data at the address 0xb340000 and compared it with the output of
> objdump -D loader_lua.syms. It turned out that it matched with the
> kernel's _start code in locore.S.
> Putting some code that jumps to loader's ImageBase address at the
> start of kernel's _start did not change anything, so I judged that the
> kernel is not started at all.
> The excerpt of the loader's memmap command output is as follows:
>     Type           Physical           Virtual              #Pages     Att=
r
>     LoaderData 0000b33ea000  000000000000  00000000  UC WC WT WB WP RP XP
>     LoaderCode 0000bb909000  000000000000  000000d1 UC WC WT WB WP RP XP
> From this output, I wonder if the memory attributes on Yoga C630 is
> properly implemented, but as XP (exec protect) bit is on, I tried to
> set it off by DXE services' SetMemoryAttributes() (with a lot of
> transcription from the standards...).It succeeded, but the kernel
> still did not run.
>
> From this tweet:
> https://twitter.com/canadianbryan/status/1598053941270679552 and its
> replies, the Microsoft Arm Developer Kit seems to have similar
> problem, so if somebody succeeded to run FreeBSD on it, please share
> the information how to do it.
>

I run other arm64 machines w/o issue with the current code. I've not heard
from Allan
for his changes, nor seen any reviews come through...

Where can one buy one of these systems. It seems just odd-ball enough that
I can
justify picking one up for work...

Warner


> 2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh :
>
> >
> >
> >
> > On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> I investigated a little more.
> >> I thought it was the kernel that did not run, but still it did not get
> >> through the loader.
> >
> >
> > Keep at it...
> >
> >>
> >> The loader freezed in efi_do_vmap(), so I needed to add
> >> efi_disable_vmap=3D"YES" in loader.conf.
> >
> >
> > No. The code for this needs to be fixed...  More on that in a second...
> >
> >>
> >> At last, in elf64_exec, it tried to run (*entry)(modulep) where the
> >> address entry is calculated from ehdr->e_entry by efi_translate() in
> >> stand/efi/loader/copy.c. There,
> >> ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
> >> but I modified a little) and
> >> stage_offset was 0x10000b33e0000.
> >> The sum of two which efi_translate() returns is 0x100000000b3400000.
> >> It overflows uint64_t and becomes 0xb3400000.
> >
> >
> > Yea, I think this is wrong.
> >
> >>
> >> Currently, I do not understand well what the functions in
> >> stand/efi/loader/copy.c do, and do not know how to workaround this
> >> problem.
> >
> >
> > So there's two things going on here. First is that on arm64 we should
> *NEVER* copy the
> > kernel. It loads at a specific address and we jump to where it loaded i=
n
> RAM (in your case,
> > I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernbas=
e
> is 0xffff000000000000
> > so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you
> suggest). The kernel
> > code that's there should do some tricks to find out where it was loaded=
,
> turn on the MMU and
> > then jump to the VA to continue starting up the kernel. The arm64 kerne=
l
> is linked with a VA. Old amd64
> > kernels expected to start at a fixed physical address, but the UEFI spe=
c
> allows memory to be mapped anywhere
> > which means it was recently switched to create a page table in the boot
> loader, then jump to the right
> > VA, and use the page table to find what PA that is and use that to
> bootstrap the pmap. This works great on
> > amd64, but sometimes goes astray on arm64 (though the way it does for
> you doesn't make sense
> > to me). The amd64 code used to start at a PA, and that's what the 'copy=
'
> routine is supposed to do:
> > copy the kernel down that fixed address and jump to it. I don't think
> we'll ever want that on arm64, though,
> > and that might also be getting in your way (thought I'm doing this from
> memory w/o careful study of
> > the code because it's fresh in my mind due to getting arm64 working wit=
h
> linuxboot).
> >
> > Also, vmap *MUST* be called in the boot loader. The trouble is, it
> assumes VA =3D=3D PA, but that's not
> > strictly true. If you boot via LinuxBoot, for example, it has a memory
> mapping that's not VA =3D=3D PA so
> > at least some parts of the kernel fail their VA =3D=3D PA asserts. the =
vmap
> code in the loader currently
> > blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the =
VA
> from entry from the table from
> > the get memory map call is 0. Today it blindly overwrites it. You might
> try changing that, and removing
> > the bit in the kernel that checks for VA =3D=3D PA and bails out if the=
re's
> a mismatch. Here's the patch I'm
> > temporarily using until I have the time to do more than a quick,
> superficial analysis of the issue:
> >
> > diff --git a/sys/arm64/arm64/efirt_machdep.c
> b/sys/arm64/arm64/efirt_machdep.c
> > index 727c9c37f94d..075174d164d8 100644
> > --- a/sys/arm64/arm64/efirt_machdep.c
> > +++ b/sys/arm64/arm64/efirt_machdep.c
> > @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc,
> int descsz)
> >                         continue;
> >                 if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {
> >                         if (bootverbose)
> > -                               printf("EFI Runtime entry %d is
> mapped\n", i);
> > -                       goto fail;
> > +                               printf("EFI Runtime entry %d is mapped
> PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt);
> > +//                     goto fail;
> >                 }
> >                 if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
> >                         if (bootverbose)
> >
> > clearly, not suitable for upstreaming, eh? And I have about 2 dozen
> commits in my queue ahead of that
> > one that need refinement, review and upstreaming before I jump into thi=
s
> issue. It will be after the first
> > of the year at least before I'll look at it since I just started my
> year-end vacation...
> >
> > Warner
> >
> >>
> >> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=
=8F=E9=87=8E=E5=AF=9B=E7=94=9F) :
> >> >
> >> > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> >> > >>
> >> > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh :
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=
=AF=9B=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> >> > >>
> >> > >> >> OK, I (and the subject) was wrong. The loader boots, and show
> >> > >> >> following log at last:
> >> > >> >>
> >> > >> >> Loading kernel...
> >> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f97=
ac
> >> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+0=
x1439ea]
> >> > >> >> Loading configured modules...
> >> > >> >> can't find '/boot/entropy'
> >> > >> >> can't find '/etc/hostid'
> >> > >> >> No valid device tree blob found!
> >> > >> >> WARNING! Trying to fire up the kernel, but no device tree blob
> found!
> >> > >> >> EFI framebuffer information
> >> > >> >> addr, size        0x80400000, 0x7e9000
> >> > >> >> dimensions     1920 x 1080
> >> > >> >> stride             1920
> >> > >> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff00000=
0
> >> > >> >>
> >> > >> >> and it stops here. No "<>" line is displayed.
> >> > >> >> So, it seems that the kernel is loaded but could not be starte=
d.
> >> > >> >
> >> > >> >
> >> > >> > There are several causes of this.
> >> > >> >
> >> > >> > Most likely is that the console is setup to go somewhere else.
> Though if you are on the video display and getting that framebuffer outpu=
t,
> it won't not go there w/o some setting to override (say to force serial).
> >> > >>
> >> > >> In the loader, when comconsole->c_init() is called for the second
> >> > >> time, the function does not return. (I commented out comconsole t=
o
> >> > >> make the loader work, but it is rather brutal and is not a proper
> >> > >> solution).
> >> > >> But the function parse_uefi_con_out() in stand/efi/loader/main.c
> >> > >> always returns RB_SERIAL, so the loader tries to use the serial
> >> > >> console.
> >> > >
> >> > >
> >> > > I wonder why that is. Is this -current or -stable? I have a rather
> large backlog of MFC-able loader changes. If it is with stable, then it
> makes sense: I fixed a bug where parse_uefi_con_out would return serial i=
f
> '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now =
we
> return Video console if we fine evidence there's a video console.
> >> >
> >> > It is stable/13.
> >> > I tried 14-current, and the same change to loader was needed (mergin=
g
> >> > OpenBSD's start.S and ldscript.arm64, and commenting out comconsole)=
.
> >> > Even with these change, the console defaults to serial, so I changed
> >> > parse_uefi_con_out() to always return 0.
> >> > Still, it stops at the same point. The kernel does not seem to boot.
> >> >
> >> > Running efi-show from the loader prompt did not show
> >> > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
> >> > The variable name containing 'ConOut' were:
> >> >
> >> > global NV,BS,RS ConOut =3D
> >> >
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
> >> > global NV,BS,RS ConOutDev =3D
> >> >
> VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43BD-048=
2-27D14ED47D72)/Uart(115200,8,N,1)
> >> >
> >> > > Now, why it fails the second time, I don't know.
> >> > >
> >> > >>
> >> > >> If a similar thing happens with the kernel, it may be stopping at
> >> > >> serial console initialization.
> >> > >
> >> > >
> >> > > The kernel doesn't use the EFI routines to initialize the serial
> console. But if the kernel is being told the wrong console, then it could
> also be booting just fine or almost fine and hitting some bug later.
> >> > >
> >> > >>
> >> > >> > Next most likely is that FreeBSD doesn't cope well with having
> both FDT and ACPI information available. But since not DTB is being passe=
d
> in (per that message) that's not likely at play here.
> >> > >>
> >> > >> I managed to load the dtb file and the boot process stopped at th=
e
> >> > >> same point. The problem is not here?
> >> > >
> >> > >
> >> > > Yea, I don't think so.
> >> > >
> >> > > Warner
> >> > >
> >> > >>
> >> > >> > Finally, the loader passes a large number of tables, etc to the
> kernel. It's quite possible that, for reasons still unknown, that data is
> wrong or if standard conforming not expected by the kernel. this leads to=
 a
> crash before we've setup the console in the kernel which looks a lot like=
 a
> hang.
> >> > >> >
> >> > >> > Warner
> >> > >> >
> >> > >> >
> >> > >> >>
> >> > >> >> > . . .
> >> > >> >> >
> >> > >> >> > Such also happens for stable/13, releng/13.* based
> installations
> >> > >> >> > as well --and likely others too.
> >> > >> >> >
> >> > >> >> > ACPI booting does not use Device Tree information but the
> messages
> >> > >> >> > are output anyway about the lack. Only if you know that the
> context
> >> > >> >> > is a Device Tree style of boot are the messages actually
> reporting
> >> > >> >> > a problem.
> >> > >> >> >
> >> > >> >> >
> >> > >> >> > =3D=3D=3D
> >> > >> >> > Mark Millard
> >> > >> >> > marklmi at yahoo.com
> >> > >> >> >
> >> > >> >>
>

--000000000000b6dfee05f0887747
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Dec 23, 2022 at 5:49 PM Hiroo=
 Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">The current status of Free=
BSD 14-current on Lenovo Yoga C630 is as follows:



=C2=A01) Merging from OpenBSD's loader code made the loader boot apart =
from

3 points (#2 to 4 ).

=C2=A02) when comconsole->c_init() runs the 2nd time, it seems to freeze=
.

(might be C630 specific)

=C2=A03) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also

affect other snapdragon systems like Microsoft Arm Developer Kit)

=C2=A04) The kernel is kicked but does not start.



1) is quite straightforward. What needs to be changed is

stand/efi/loader/arch/arm64/start.S.

Ca=
n you share what needs to be done? To my eye, we don't need any changes=
, so it would be good to know what you've had to do exactly.
=
=C2=A0

For 2), I do not know what to do. Currently, I commented out

comconsole from struct console *consoles[] in stand/efi/loader/conf.c

as a workaround. Maybe, I should write a fault handler that helps

returning from the fault.

There were pr=
oblems with this with HyperV on aarch64 too.

Somet=
hing like
diff --git a/stand/efi/loader/efiserialio.c b/stand/efi=
/loader/efiserialio.c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/s=
tand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@=
 -261,11 +261,11 @@ comc_probe(struct console *sc)
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (comc_port =3D=3D NULL)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r=
eturn;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
- =C2=A0 =C2=A0 =C2=A0 comc_port=
->baudrate =3D COMSPEED;
+ =C2=A0 =C2=A0 =C2=A0 comc_port->baudrat=
e =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->ioaddr =3D 0; =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* default port */- =C2=A0 =C2=A0 =C2=A0 comc_port->databits =3D 8; =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */
- =C2=A0 =C2=A0 =C2=A0 co=
mc_port->parity =3D NoParity; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,=
1 */
- =C2=A0 =C2=A0 =C2=A0 comc_port->stopbits =3D OneStopBit; =C2=
=A0 =C2=A0 =C2=A0 /* 8,n,1 */
+ =C2=A0 =C2=A0 =C2=A0 comc_port->datab=
its =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 =
*/
+ =C2=A0 =C2=A0 =C2=A0 comc_port->parity =3D 0; =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0/* 8,n,1 */
+ =C2=A0 =C2=A0 =C2=A0 comc_port->stopbi=
ts =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 comc_port->ignore_cd =3D 1; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 /* ignore cd */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->=
rtsdtr_off =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* rts-dt=
r is on */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->sio =3D NULL;

was needed.=C2=A0 Possibly the following would be b=
etter:

diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loa=
der/efiserialio.c
index 8b3f8e83e0b3..54ee39096685 100644
--- a/stand=
/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@=
@ -494,8 +494,7 @@ comc_setup(void)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 return (false);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 sta=
tus =3D comc_port->sio->SetAttributes(comc_port->sio,
- =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->baudrate, 0, 0, comc_port->par=
ity,
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 comc_port->databits, comc_p=
ort->stopbits);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0, 0, 0, 0, 0, 0=
);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (EFI_ERROR(status))
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (false);
=C2=A0

3), I dumped each memory map's VirtualStart and PhysicalStart. All

VirtualStart were 0. So overwriting VirutalStart by the value of

PhysicalStart and running SetVirtualAddressMap should work. But in

reality, it doesn't.

=C2=A0 OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to<=
br>
have abandoned it for arm64 in 2019.

=C2=A0 =C2=A0 https://git.kernel.org/pub/scm/linux/kernel/git/=
tip/tip.git/commit/?id=3D4e46c2a956215482418d7b315749fb1b6c6bc224

=C2=A0 Maybe, we also can avoid SetVirtualAddressMap (by

efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should =
change

the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to do
so).

FreeBSD tends to prefer this... Ou=
r kernel needs to cope with cases where it has
been called (many =
kexec environments provide PA !=3D VA virtual mappings that we
ca=
n't change).
=C2=A0

About 4), I am completely confused. In elf64_exec in

stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel

was loaded is calculated as:

=C2=A0 =C2=A0 entry =3D efi_translate(ehdr->e_entry);=C2=A0 // which bec=
omes 0xb340000

and later kicked as:

=C2=A0 =C2=A0 (*entry)(modulep);

I wrote that this calculation is doubtful, but it was right. I dumped

the data at the address 0xb340000 and compared it with the output of

objdump -D loader_lua.syms. It turned out that it matched with the

kernel's _start code in locore.S.

Putting some code that jumps to loader's ImageBase address at the

start of kernel's _start did not change anything, so I judged that the<=
br>
kernel is not started at all.

The excerpt of the loader's memmap command output is as follows:

=C2=A0 =C2=A0 Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Physical=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Virtual=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 #Pages=C2=A0 =C2=A0 =C2=A0Attr

=C2=A0 =C2=A0 LoaderData 0000b33ea000=C2=A0 000000000000=C2=A0 00000000=C2=
=A0 UC WC WT WB WP RP XP

=C2=A0 =C2=A0 LoaderCode 0000bb909000=C2=A0 000000000000=C2=A0 000000d1 UC =
WC WT WB WP RP XP

>From this output, I wonder if the memory attributes on Yoga C630 is

properly implemented, but as XP (exec protect) bit is on, I tried to

set it off by DXE services' SetMemoryAttributes() (with a lot of

transcription from the standards...).It succeeded, but the kernel

still did not run.



>From this tweet:

https://twitter.com/canadianbryan/status=
/1598053941270679552 and its

replies, the Microsoft Arm Developer Kit seems to have similar

problem, so if somebody succeeded to run FreeBSD on it, please share

the information how to do it.

I run oth=
er arm64 machines w/o issue with the current code. I've not heard from =
Allan
for his changes, nor seen any reviews come through...
=


Where can one buy one of these systems.=C2=A0It seems j=
ust odd-ball enough that I can
justify picking one up for work...=


Warner
=C2=A0

2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh <imp@bsdimp.com>:



>

>

>

> On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:

>>

>> Hello,

>>

>> I investigated a little more.

>> I thought it was the kernel that did not run, but still it did not=
 get

>> through the loader.

>

>

> Keep at it...

>

>>

>> The loader freezed in efi_do_vmap(), so I needed to add

>> efi_disable_vmap=3D"YES" in loader.conf.

>

>

> No. The code for this needs to be fixed...=C2=A0 More on that in a sec=
ond...

>

>>

>> At last, in elf64_exec, it tried to run (*entry)(modulep) where th=
e

>> address entry is calculated from ehdr->e_entry by efi_translate=
() in

>> stand/efi/loader/copy.c. There,

>> ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000=
800,

>> but I modified a little) and

>> stage_offset was 0x10000b33e0000.

>> The sum of two which efi_translate() returns is 0x100000000b340000=
0.

>> It overflows uint64_t and becomes 0xb3400000.

>

>

> Yea, I think this is wrong.

>

>>

>> Currently, I do not understand well what the functions in

>> stand/efi/loader/copy.c do, and do not know how to workaround this=


>> problem.

>

>

> So there's two things going on here. First is that on arm64 we sho=
uld *NEVER* copy the

> kernel. It loads at a specific address and we jump to where it loaded =
in RAM (in your case,

> I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Ker=
nbase is 0xffff000000000000

> so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you =
suggest). The kernel

> code that's there should do some tricks to find out where it was l=
oaded, turn on the MMU and

> then jump to the VA to continue starting up the kernel. The arm64 kern=
el is linked with a VA. Old amd64

> kernels expected to start at a fixed physical address, but the UEFI sp=
ec allows memory to be mapped anywhere

> which means it was recently switched to create a page table in the boo=
t loader, then jump to the right

> VA, and use the page table to find what PA that is and use that to boo=
tstrap the pmap. This works great on

> amd64, but sometimes goes astray on arm64 (though the way it does for =
you doesn't make sense

> to me). The amd64 code used to start at a PA, and that's what the =
'copy' routine is supposed to do:

> copy the kernel down that fixed address and jump to it. I don't th=
ink we'll ever want that on arm64, though,

> and that might also be getting in your way (thought I'm doing this=
 from memory w/o careful study of

> the code because it's fresh in my mind due to getting arm64 workin=
g with linuxboot).

>

> Also, vmap *MUST* be called in the boot loader. The trouble is, it ass=
umes VA =3D=3D PA, but that's not

> strictly true. If you boot via LinuxBoot, for example, it has a memory=
 mapping that's not VA =3D=3D PA so

> at least some parts of the kernel fail their VA =3D=3D PA asserts. the=
 vmap code in the loader currently

> blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the=
 VA from entry from the table from

> the get memory map call is 0. Today it blindly overwrites it. You migh=
t try changing that, and removing

> the bit in the kernel that checks for VA =3D=3D PA and bails out if th=
ere's a mismatch. Here's the patch I'm

> temporarily using until I have the time to do more than a quick, super=
ficial analysis of the issue:

>

> diff --git a/sys/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_m=
achdep.c

> index 727c9c37f94d..075174d164d8 100644

> --- a/sys/arm64/arm64/efirt_machdep.c

> +++ b/sys/arm64/arm64/efirt_machdep.c

> @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, =
int descsz)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0continue;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (p->=
;md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0if (bootverbose)

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("EFI Runtime entry %d=
 is mapped\n", i);

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0goto fail;

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("EFI Runtime entry %d=
 is mapped PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt);

> +//=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0goto fail;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ((p-&g=
t;md_phys & EFI_PAGE_MASK) !=3D 0) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0if (bootverbose)

>

> clearly, not suitable for upstreaming, eh? And I have about 2 dozen co=
mmits in my queue ahead of that

> one that need refinement, review and upstreaming before I jump into th=
is issue. It will be after the first

> of the year at least before I'll look at it since I just started m=
y year-end vacation...

>

> Warner

>

>>

>> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=
=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:

>> >

>> > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Los=
h <imp@bsdimp.com>:

>> > >

>> > >

>> > >

>> > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:

>> > >>

>> > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 W=
arner Losh <imp@bsdi=
mp.com>:

>> > >> >

>> > >> >

>> > >> >

>> > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=
=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
>> > >>

>> > >> >> OK, I (and the subject) was wrong. The load=
er boots, and show

>> > >> >> following log at last:

>> > >> >>

>> > >> >> Loading kernel...

>> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8=
bcbf0 text=3D0x1f97ac

>> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D=
[0x8+0x11f6a0+0x8+0x1439ea]

>> > >> >> Loading configured modules...

>> > >> >> can't find '/boot/entropy'

>> > >> >> can't find '/etc/hostid'

>> > >> >> No valid device tree blob found!

>> > >> >> WARNING! Trying to fire up the kernel, but =
no device tree blob found!

>> > >> >> EFI framebuffer information

>> > >> >> addr, size=C2=A0 =C2=A0 =C2=A0 =C2=A0 0x804=
00000, 0x7e9000

>> > >> >> dimensions=C2=A0 =C2=A0 =C2=A01920 x 1080
>> > >> >> stride=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A01920

>> > >> >> masks=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

>> > >> >>

>> > >> >> and it stops here. No "<<BOOT>=
;>" line is displayed.

>> > >> >> So, it seems that the kernel is loaded but =
could not be started.

>> > >> >

>> > >> >

>> > >> > There are several causes of this.

>> > >> >

>> > >> > Most likely is that the console is setup to go =
somewhere else. Though if you are on the video display and getting that fra=
mebuffer output, it won't not go there w/o some setting to override (sa=
y to force serial).

>> > >>

>> > >> In the loader, when comconsole->c_init() is calle=
d for the second

>> > >> time, the function does not return. (I commented out=
 comconsole to

>> > >> make the loader work, but it is rather brutal and is=
 not a proper

>> > >> solution).

>> > >> But the function parse_uefi_con_out() in stand/efi/l=
oader/main.c

>> > >> always returns RB_SERIAL, so the loader tries to use=
 the serial

>> > >> console.

>> > >

>> > >

>> > > I wonder why that is. Is this -current or -stable? I hav=
e a rather large backlog of MFC-able loader changes. If it is with stable, =
then it makes sense: I fixed a bug where parse_uefi_con_out would return se=
rial if '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is=
 it set?=C2=A0 Now we return Video console if we fine evidence there's =
a video console.

>> >

>> > It is stable/13.

>> > I tried 14-current, and the same change to loader was needed =
(merging

>> > OpenBSD's start.S and ldscript.arm64, and commenting out =
comconsole).

>> > Even with these change, the console defaults to serial, so I =
changed

>> > parse_uefi_con_out() to always return 0.

>> > Still, it stops at the same point. The kernel does not seem t=
o boot.

>> >

>> > Running efi-show from the loader prompt did not show

>> > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'

>> > The variable name containing 'ConOut' were:

>> >

>> > global NV,BS,RS ConOut =3D

>> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0=
EEC-43BD-0482-27D14ED47D72)/Uart(115200,8,N,1)

>> > global NV,BS,RS ConOutDev =3D

>> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0=
EEC-43BD-0482-27D14ED47D72)/Uart(115200,8,N,1)

>> >

>> > > Now, why it fails the second time, I don't know.

>> > >

>> > >>

>> > >> If a similar thing happens with the kernel, it may b=
e stopping at

>> > >> serial console initialization.

>> > >

>> > >

>> > > The kernel doesn't use the EFI routines to initializ=
e the serial console. But if the kernel is being told the wrong console, th=
en it could also be booting just fine or almost fine and hitting some bug l=
ater.

>> > >

>> > >>

>> > >> > Next most likely is that FreeBSD doesn't co=
pe well with having both FDT and ACPI information available. But since not =
DTB is being passed in (per that message) that's not likely at play her=
e.

>> > >>

>> > >> I managed to load the dtb file and the boot process =
stopped at the

>> > >> same point. The problem is not here?

>> > >

>> > >

>> > > Yea, I don't think so.

>> > >

>> > > Warner

>> > >

>> > >>

>> > >> > Finally, the loader passes a large number of ta=
bles, etc to the kernel. It's quite possible that, for reasons still un=
known, that data is wrong or if standard conforming not expected by the ker=
nel. this leads to a crash before we've setup the console in the kernel=
 which looks a lot like a hang.

>> > >> >

>> > >> > Warner

>> > >> >

>> > >> >

>> > >> >>

>> > >> >> > . . .

>> > >> >> >

>> > >> >> > Such also happens for stable/13, relen=
g/13.* based installations

>> > >> >> > as well --and likely others too.

>> > >> >> >

>> > >> >> > ACPI booting does not use Device Tree =
information but the messages

>> > >> >> > are output anyway about the lack. Only=
 if you know that the context

>> > >> >> > is a Device Tree style of boot are the=
 messages actually reporting

>> > >> >> > a problem.

>> > >> >> >

>> > >> >> >

>> > >> >> > =3D=3D=3D

>> > >> >> > Mark Millard

>> > >> >> > marklmi at yahoo.com

>> > >> >> >

>> > >> >>




--000000000000b6dfee05f0887747--

From nobody Sat Dec 24 01:35:12 2022
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 4Nf67M1jPFz1H8qH
	for ; Sat, 24 Dec 2022 01:35:27 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034])
	(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 4Nf67L6dSxz3NKY
	for ; Sat, 24 Dec 2022 01:35:26 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pj1-x1034.google.com with SMTP id k88-20020a17090a4ce100b00219d0b857bcso6357847pjh.1
        for ; Fri, 23 Dec 2022 17:35:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=jUtdl5/NmzVyAz4FcFp5mikkTbjxkQsr4BDaqJ5A7yo=;
        b=FOhfMGW1XuUYFjDsG56k4DNbM/j4us6MGCWqtBQQ5HjQ4uk/helmrTGO5w0brrZ4s3
         dikmSHrhD9EPx8qI4Nl7X9UQNPmUtipICopTXwlaQUnCLFekpla5Hp8SyI9pz7rYqOEC
         6+OIqcYe6u4ZJ+Rhxx04X02QP106ibJvQ/ZnOr4IWaYENG6wL97QsfdGA4ivdZQBUVGk
         p9m+oCsjvcScFUisIGIEB33fbK/31vDleUfXij7epJ9IxvlicN3svsA4OKXALd3Y4mrA
         d36iE456afPowUtgE9nohspUqthan/b9PbRka/mHeeg6u0sMDdizPCDH5O11ytMoGs8h
         5J4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jUtdl5/NmzVyAz4FcFp5mikkTbjxkQsr4BDaqJ5A7yo=;
        b=04ASNRtz0OxxpkIozC5HZbwMgpMA/W6KblB4PCebemUDECWvdQrzSr3mxwrZegrymI
         y+jjsQfck3wwz6wC7UWEsG9aQ1oyZbuySETqYY5w6hBdjdn1n5uHLJXtp9sKn48AOBE1
         kCf9rps+Rvvqw/qPTAG2JEjDdG7tEVoxikyfiLHv6jNylfKLlNSCzJEK6N/5HPWXolDT
         QQtcKOIdGlLAm/HO09WlM/G7x7+9z8sc3x4YFDwXUGp1lPBFH+ChZAIxd6l7U+64oMIE
         so9VCZyu9oex2O221JPC0wEpvRDEl9JWZUnNIYQMMOMO1xeqg3qg+Wy0/PLPQb/kGNII
         rFUA==
X-Gm-Message-State: AFqh2krK+inXlprF3ctGzienyDLR6mZ8ct1Qy6WhJp2Hg2s6eExmjGrC
	0aMcpaCIkqhDAG/SNustsySnh3MDnAJLxPHbz6Y=
X-Google-Smtp-Source: AMrXdXufLfC0nQa/1yYBcR1blnJszAk5r1ODiQmzCH6H21LRJ2RKIkjg+vxS1K0xROmLr52WeOsBQuY0VuaXBBGkYhQ=
X-Received: by 2002:a17:903:2616:b0:189:e07f:933d with SMTP id
 jd22-20020a170903261600b00189e07f933dmr785071plb.7.1671845724481; Fri, 23 Dec
 2022 17:35:24 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sat, 24 Dec 2022 10:35:12 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/mixed; boundary="00000000000087029a05f088ea55"
X-Rspamd-Queue-Id: 4Nf67L6dSxz3NKY
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[freebsd]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000087029a05f088ea55
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I run other arm64 machines w/o issue with the current code.

Yes, Qualcomm's snapdragon is weird. I saw Linux people complain about
it somewhere... Wanted to know  before I bought this Yoga C630.

2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
>
>
>
> On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F)  wrote:
>>
>> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as follo=
ws:
>>
>>  1) Merging from OpenBSD's loader code made the loader boot apart from
>> 3 points (#2 to 4 ).
>>  2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
>> (might be C630 specific)
>>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
>> affect other snapdragon systems like Microsoft Arm Developer Kit)
>>  4) The kernel is kicked but does not start.
>>
>> 1) is quite straightforward. What needs to be changed is
>> stand/efi/loader/arch/arm64/start.S.
>
>
> Can you share what needs to be done? To my eye, we don't need any changes=
, so it would be good to know what you've had to do exactly.

Attached is the diff to start.S. There are 3 points.
1) The loader has to be aligned to 4kb.
2) Proper characteristic value should be in the PE header.
3) .text and .data segment have to be separate.

It is from OpenBSD:
https://github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efiboot/sta=
rt.S

>> For 2), I do not know what to do. Currently, I commented out
>> comconsole from struct console *consoles[] in stand/efi/loader/conf.c
>> as a workaround. Maybe, I should write a fault handler that helps
>> returning from the fault.
>
>
> There were problems with this with HyperV on aarch64 too.
>
> Something like
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
>                 if (comc_port =3D=3D NULL)
>                         return;
>         }
> -       comc_port->baudrate =3D COMSPEED;
> +       comc_port->baudrate =3D 0;
>         comc_port->ioaddr =3D 0;                  /* default port */
> -       comc_port->databits =3D 8;                /* 8,n,1 */
> -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> +       comc_port->databits =3D 0;                /* 8,n,1 */
> +       comc_port->parity =3D 0;          /* 8,n,1 */
> +       comc_port->stopbits =3D 0;        /* 8,n,1 */
>         comc_port->ignore_cd =3D 1;               /* ignore cd */
>         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on */
>         comc_port->sio =3D NULL;
>
> was needed.  Possibly the following would be better:
>
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -494,8 +494,7 @@ comc_setup(void)
>                 return (false);
>
>         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> -           comc_port->baudrate, 0, 0, comc_port->parity,
> -           comc_port->databits, comc_port->stopbits);
> +           0, 0, 0, 0, 0, 0);
>         if (EFI_ERROR(status))
>                 return (false);
>
>
>>
>> 3), I dumped each memory map's VirtualStart and PhysicalStart. All
>> VirtualStart were 0. So overwriting VirutalStart by the value of
>> PhysicalStart and running SetVirtualAddressMap should work. But in
>> reality, it doesn't.
>>   OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to
>> have abandoned it for arm64 in 2019.
>>     https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?=
id=3D4e46c2a956215482418d7b315749fb1b6c6bc224
>>   Maybe, we also can avoid SetVirtualAddressMap (by
>> efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should change
>> the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to d=
o
>> so).
>
>
> FreeBSD tends to prefer this... Our kernel needs to cope with cases where=
 it has
> been called (many kexec environments provide PA !=3D VA virtual mappings =
that we
> can't change).
>
>>
>> About 4), I am completely confused. In elf64_exec in
>> stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel
>> was loaded is calculated as:
>>     entry =3D efi_translate(ehdr->e_entry);  // which becomes 0xb340000
>> and later kicked as:
>>     (*entry)(modulep);
>> I wrote that this calculation is doubtful, but it was right. I dumped
>> the data at the address 0xb340000 and compared it with the output of
>> objdump -D loader_lua.syms. It turned out that it matched with the
>> kernel's _start code in locore.S.
>> Putting some code that jumps to loader's ImageBase address at the
>> start of kernel's _start did not change anything, so I judged that the
>> kernel is not started at all.
>> The excerpt of the loader's memmap command output is as follows:
>>     Type           Physical           Virtual              #Pages     At=
tr
>>     LoaderData 0000b33ea000  000000000000  00000000  UC WC WT WB WP RP X=
P
>>     LoaderCode 0000bb909000  000000000000  000000d1 UC WC WT WB WP RP XP
>> From this output, I wonder if the memory attributes on Yoga C630 is
>> properly implemented, but as XP (exec protect) bit is on, I tried to
>> set it off by DXE services' SetMemoryAttributes() (with a lot of
>> transcription from the standards...).It succeeded, but the kernel
>> still did not run.
>>
>> From this tweet:
>> https://twitter.com/canadianbryan/status/1598053941270679552 and its
>> replies, the Microsoft Arm Developer Kit seems to have similar
>> problem, so if somebody succeeded to run FreeBSD on it, please share
>> the information how to do it.
>
>
> I run other arm64 machines w/o issue with the current code. I've not hear=
d from Allan
> for his changes, nor seen any reviews come through...
>
> Where can one buy one of these systems. It seems just odd-ball enough tha=
t I can
> justify picking one up for work...
>
> Warner
>
>>
>> 2022=E5=B9=B412=E6=9C=8819=E6=97=A5(=E6=9C=88) 5:33 Warner Losh :
>>
>> >
>> >
>> >
>> > On Sun, Dec 18, 2022 at 4:31 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F)  wrote:
>> >>
>> >> Hello,
>> >>
>> >> I investigated a little more.
>> >> I thought it was the kernel that did not run, but still it did not ge=
t
>> >> through the loader.
>> >
>> >
>> > Keep at it...
>> >
>> >>
>> >> The loader freezed in efi_do_vmap(), so I needed to add
>> >> efi_disable_vmap=3D"YES" in loader.conf.
>> >
>> >
>> > No. The code for this needs to be fixed...  More on that in a second..=
.
>> >
>> >>
>> >> At last, in elf64_exec, it tried to run (*entry)(modulep) where the
>> >> address entry is calculated from ehdr->e_entry by efi_translate() in
>> >> stand/efi/loader/copy.c. There,
>> >> ehdr->e_entry was 0xffff000000020000 (should be 0xffff000000000800,
>> >> but I modified a little) and
>> >> stage_offset was 0x10000b33e0000.
>> >> The sum of two which efi_translate() returns is 0x100000000b3400000.
>> >> It overflows uint64_t and becomes 0xb3400000.
>> >
>> >
>> > Yea, I think this is wrong.
>> >
>> >>
>> >> Currently, I do not understand well what the functions in
>> >> stand/efi/loader/copy.c do, and do not know how to workaround this
>> >> problem.
>> >
>> >
>> > So there's two things going on here. First is that on arm64 we should =
*NEVER* copy the
>> > kernel. It loads at a specific address and we jump to where it loaded =
in RAM (in your case,
>> > I think it should be stage_offset + (ehdr->e_entry - KERNBASE). Kernba=
se is 0xffff000000000000
>> > so we should jump to 0x10000brre0000 + 0x20000 (or maybe 0x800 is you =
suggest). The kernel
>> > code that's there should do some tricks to find out where it was loade=
d, turn on the MMU and
>> > then jump to the VA to continue starting up the kernel. The arm64 kern=
el is linked with a VA. Old amd64
>> > kernels expected to start at a fixed physical address, but the UEFI sp=
ec allows memory to be mapped anywhere
>> > which means it was recently switched to create a page table in the boo=
t loader, then jump to the right
>> > VA, and use the page table to find what PA that is and use that to boo=
tstrap the pmap. This works great on
>> > amd64, but sometimes goes astray on arm64 (though the way it does for =
you doesn't make sense
>> > to me). The amd64 code used to start at a PA, and that's what the 'cop=
y' routine is supposed to do:
>> > copy the kernel down that fixed address and jump to it. I don't think =
we'll ever want that on arm64, though,
>> > and that might also be getting in your way (thought I'm doing this fro=
m memory w/o careful study of
>> > the code because it's fresh in my mind due to getting arm64 working wi=
th linuxboot).
>> >
>> > Also, vmap *MUST* be called in the boot loader. The trouble is, it ass=
umes VA =3D=3D PA, but that's not
>> > strictly true. If you boot via LinuxBoot, for example, it has a memory=
 mapping that's not VA =3D=3D PA so
>> > at least some parts of the kernel fail their VA =3D=3D PA asserts. the=
 vmap code in the loader currently
>> > blindly assumes VA =3D=3D PA, but it should, IMHO, only do that if the=
 VA from entry from the table from
>> > the get memory map call is 0. Today it blindly overwrites it. You migh=
t try changing that, and removing
>> > the bit in the kernel that checks for VA =3D=3D PA and bails out if th=
ere's a mismatch. Here's the patch I'm
>> > temporarily using until I have the time to do more than a quick, super=
ficial analysis of the issue:
>> >
>> > diff --git a/sys/arm64/arm64/efirt_machdep.c b/sys/arm64/arm64/efirt_m=
achdep.c
>> > index 727c9c37f94d..075174d164d8 100644
>> > --- a/sys/arm64/arm64/efirt_machdep.c
>> > +++ b/sys/arm64/arm64/efirt_machdep.c
>> > @@ -193,8 +193,8 @@ efi_create_1t1_map(struct efi_md *map, int ndesc, =
int descsz)
>> >                         continue;
>> >                 if (p->md_virt !=3D 0 && p->md_virt !=3D p->md_phys) {
>> >                         if (bootverbose)
>> > -                               printf("EFI Runtime entry %d is mapped=
\n", i);
>> > -                       goto fail;
>> > +                               printf("EFI Runtime entry %d is mapped=
 PA %#lx VA %#lx\n", i, p->md_phys, p->md_virt);
>> > +//                     goto fail;
>> >                 }
>> >                 if ((p->md_phys & EFI_PAGE_MASK) !=3D 0) {
>> >                         if (bootverbose)
>> >
>> > clearly, not suitable for upstreaming, eh? And I have about 2 dozen co=
mmits in my queue ahead of that
>> > one that need refinement, review and upstreaming before I jump into th=
is issue. It will be after the first
>> > of the year at least before I'll look at it since I just started my ye=
ar-end vacation...
>> >
>> > Warner
>> >
>> >>
>> >> 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 9:25 Hiroo Ono (=E5=B0=
=8F=E9=87=8E=E5=AF=9B=E7=94=9F) :
>> >> >
>> >> > 2022=E5=B9=B412=E6=9C=889=E6=97=A5(=E9=87=91) 3:19 Warner Losh :
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Wed, Dec 7, 2022 at 4:21 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=
=AF=9B=E7=94=9F)  wrote:
>> >> > >>
>> >> > >> 2022=E5=B9=B412=E6=9C=887=E6=97=A5(=E6=B0=B4) 1:18 Warner Losh <=
imp@bsdimp.com>:
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > On Tue, Dec 6, 2022 at 7:59 AM Hiroo Ono (=E5=B0=8F=E9=87=8E=
=E5=AF=9B=E7=94=9F)  wrote:
>> >> > >>
>> >> > >> >> OK, I (and the subject) was wrong. The loader boots, and show
>> >> > >> >> following log at last:
>> >> > >> >>
>> >> > >> >> Loading kernel...
>> >> > >> >> /boot/kernel/kernel text=3D0x2a8 text=3D0x8bcbf0 text=3D0x1f9=
7ac
>> >> > >> >> data=3D0x1a6ac0 data=3D0x0+0x381000 syms=3D[0x8+0x11f6a0+0x8+=
0x1439ea]
>> >> > >> >> Loading configured modules...
>> >> > >> >> can't find '/boot/entropy'
>> >> > >> >> can't find '/etc/hostid'
>> >> > >> >> No valid device tree blob found!
>> >> > >> >> WARNING! Trying to fire up the kernel, but no device tree blo=
b found!
>> >> > >> >> EFI framebuffer information
>> >> > >> >> addr, size        0x80400000, 0x7e9000
>> >> > >> >> dimensions     1920 x 1080
>> >> > >> >> stride             1920
>> >> > >> >> masks            0x00ff0000, 0x0000ff00, 0x000000ff, 0xff0000=
00
>> >> > >> >>
>> >> > >> >> and it stops here. No "<>" line is displayed.
>> >> > >> >> So, it seems that the kernel is loaded but could not be start=
ed.
>> >> > >> >
>> >> > >> >
>> >> > >> > There are several causes of this.
>> >> > >> >
>> >> > >> > Most likely is that the console is setup to go somewhere else.=
 Though if you are on the video display and getting that framebuffer output=
, it won't not go there w/o some setting to override (say to force serial).
>> >> > >>
>> >> > >> In the loader, when comconsole->c_init() is called for the secon=
d
>> >> > >> time, the function does not return. (I commented out comconsole =
to
>> >> > >> make the loader work, but it is rather brutal and is not a prope=
r
>> >> > >> solution).
>> >> > >> But the function parse_uefi_con_out() in stand/efi/loader/main.c
>> >> > >> always returns RB_SERIAL, so the loader tries to use the serial
>> >> > >> console.
>> >> > >
>> >> > >
>> >> > > I wonder why that is. Is this -current or -stable? I have a rathe=
r large backlog of MFC-able loader changes. If it is with stable, then it m=
akes sense: I fixed a bug where parse_uefi_con_out would return serial if '=
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut' was unset. Is it set?  Now we =
return Video console if we fine evidence there's a video console.
>> >> >
>> >> > It is stable/13.
>> >> > I tried 14-current, and the same change to loader was needed (mergi=
ng
>> >> > OpenBSD's start.S and ldscript.arm64, and commenting out comconsole=
).
>> >> > Even with these change, the console defaults to serial, so I change=
d
>> >> > parse_uefi_con_out() to always return 0.
>> >> > Still, it stops at the same point. The kernel does not seem to boot=
.
>> >> >
>> >> > Running efi-show from the loader prompt did not show
>> >> > '8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut'
>> >> > The variable name containing 'ConOut' were:
>> >> >
>> >> > global NV,BS,RS ConOut =3D
>> >> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43=
BD-0482-27D14ED47D72)/Uart(115200,8,N,1)
>> >> > global NV,BS,RS ConOutDev =3D
>> >> > VenHw(9042A9DE-23DC-4A38-96FB-7ADED080516A),/VenHw(857A8741-0EEC-43=
BD-0482-27D14ED47D72)/Uart(115200,8,N,1)
>> >> >
>> >> > > Now, why it fails the second time, I don't know.
>> >> > >
>> >> > >>
>> >> > >> If a similar thing happens with the kernel, it may be stopping a=
t
>> >> > >> serial console initialization.
>> >> > >
>> >> > >
>> >> > > The kernel doesn't use the EFI routines to initialize the serial =
console. But if the kernel is being told the wrong console, then it could a=
lso be booting just fine or almost fine and hitting some bug later.
>> >> > >
>> >> > >>
>> >> > >> > Next most likely is that FreeBSD doesn't cope well with having=
 both FDT and ACPI information available. But since not DTB is being passed=
 in (per that message) that's not likely at play here.
>> >> > >>
>> >> > >> I managed to load the dtb file and the boot process stopped at t=
he
>> >> > >> same point. The problem is not here?
>> >> > >
>> >> > >
>> >> > > Yea, I don't think so.
>> >> > >
>> >> > > Warner
>> >> > >
>> >> > >>
>> >> > >> > Finally, the loader passes a large number of tables, etc to th=
e kernel. It's quite possible that, for reasons still unknown, that data is=
 wrong or if standard conforming not expected by the kernel. this leads to =
a crash before we've setup the console in the kernel which looks a lot like=
 a hang.
>> >> > >> >
>> >> > >> > Warner
>> >> > >> >
>> >> > >> >
>> >> > >> >>
>> >> > >> >> > . . .
>> >> > >> >> >
>> >> > >> >> > Such also happens for stable/13, releng/13.* based installa=
tions
>> >> > >> >> > as well --and likely others too.
>> >> > >> >> >
>> >> > >> >> > ACPI booting does not use Device Tree information but the m=
essages
>> >> > >> >> > are output anyway about the lack. Only if you know that the=
 context
>> >> > >> >> > is a Device Tree style of boot are the messages actually re=
porting
>> >> > >> >> > a problem.
>> >> > >> >> >
>> >> > >> >> >
>> >> > >> >> > =3D=3D=3D
>> >> > >> >> > Mark Millard
>> >> > >> >> > marklmi at yahoo.com
>> >> > >> >> >
>> >> > >> >>

--00000000000087029a05f088ea55
Content-Type: text/plain; charset="US-ASCII"; name="stand_startS.diff.txt"
Content-Disposition: attachment; filename="stand_startS.diff.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_lc19k5g40

ZGlmZiAtLWdpdCBhL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9zdGFydC5TIGIvc3RhbmQv
ZWZpL2xvYWRlci9hcmNoL2FybTY0L3N0YXJ0LlMKaW5kZXggNjc1ZDRlMTUzZjM2Li4zN2UxMTdk
Njc5YTAgMTAwNjQ0Ci0tLSBhL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9zdGFydC5TCisr
KyBiL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9zdGFydC5TCkBAIC0zOSw2ICszOSw3IEBA
CiAjZGVmaW5lCUlNQUdFX1NDTl9NRU1fRElTQ0FSREFCTEUJMHgwMjAwMDAwMAogI2RlZmluZQlJ
TUFHRV9TQ05fTUVNX0VYRUNVVEUJCTB4MjAwMDAwMDAKICNkZWZpbmUJSU1BR0VfU0NOX01FTV9S
RUFECQkweDQwMDAwMDAwCisjZGVmaW5lCUlNQUdFX1NDTl9NRU1fV1JJVEUJCTB4ODAwMDAwMDAK
IAogCS5zZWN0aW9uIC5wZWhlYWRlciwiYSIKIGVmaV9zdGFydDoKQEAgLTU1LDI3ICs1NiwyNyBA
QCBwZV9zaWc6CiAJLnNob3J0CTAKIGNvZmZfaGVhZDoKIAkuc2hvcnQJSU1BR0VfRklMRV9NQUNI
SU5FX0FSTTY0CS8qIEFBcmNoNjQgZmlsZSAqLwotCS5zaG9ydAkyCQkJCS8qIDIgU2VjdGlvbnMg
Ki8KKwkuc2hvcnQJMwkJCQkvKiAyIFNlY3Rpb25zICovCiAJLmxvbmcJMAkJCQkvKiBUaW1lc3Rh
bXAgKi8KIAkubG9uZwkwCQkJCS8qIE5vIHN5bWJvbCB0YWJsZSAqLwogCS5sb25nCTAJCQkJLyog
Tm8gc3ltYm9scyAqLwogCS5zaG9ydAlzZWN0aW9uX3RhYmxlIC0gb3B0aW9uYWxfaGVhZGVyCS8q
IE9wdGlvbmFsIGhlYWRlciBzaXplICovCi0JLnNob3J0CTAJLyogQ2hhcmFjdGVyaXN0aWNzIFRP
RE86IEZpbGwgaW4gKi8KKwkuc2hvcnQJMHgwMjA2CQkJCS8qIENoYXJhY3RlcmlzdGljcyAqLwog
CiBvcHRpb25hbF9oZWFkZXI6CiAJLnNob3J0CTB4MDIwYgkJCQkvKiBQRTMyKyAoNjQtYml0IGFk
ZHJlc3NpbmcpICovCiAJLmJ5dGUJMAkJCQkvKiBNYWpvciBsaW5rZXIgdmVyc2lvbiAqLwogCS5i
eXRlCTAJCQkJLyogTWlub3IgbGlua2VyIHZlcnNpb24gKi8KLQkubG9uZwlfZWRhdGEgLSBfZW5k
X2hlYWRlcgkJLyogQ29kZSBzaXplICovCi0JLmxvbmcJMAkJCQkvKiBObyBpbml0aWFsaXplZCBk
YXRhICovCisJLmxvbmcJX2V0ZXh0IC0gX2VuZF9oZWFkZXIJCS8qIENvZGUgc2l6ZSAqLworCS5s
b25nCV9fZGF0YV9zaXplCQkJLyogTm8gaW5pdGlhbGl6ZWQgZGF0YSAqLwogCS5sb25nCTAJCQkJ
LyogTm8gdW5pbml0aWFsaXplZCBkYXRhICovCiAJLmxvbmcJX3N0YXJ0IC0gZWZpX3N0YXJ0CQkv
KiBFbnRyeSBwb2ludCAqLwogCS5sb25nCV9lbmRfaGVhZGVyIC0gZWZpX3N0YXJ0CQkvKiBTdGFy
dCBvZiBjb2RlICovCiAKIG9wdGlvbmFsX3dpbmRvd3NfaGVhZGVyOgogCS5xdWFkCTAJCQkJLyog
SW1hZ2UgYmFzZSAqLwotCS5sb25nCTMyCQkJCS8qIFNlY3Rpb24gQWxpZ25tZW50ICovCi0JLmxv
bmcJOAkJCQkvKiBGaWxlIGFsaWdubWVudCAqLworCS5sb25nCTQwOTYJCQkJLyogU2VjdGlvbiBB
bGlnbm1lbnQgKi8KKwkubG9uZwk1MTIJCQkJLyogRmlsZSBhbGlnbm1lbnQgKi8KIAkuc2hvcnQJ
MAkJCQkvKiBNYWpvciBPUyB2ZXJzaW9uICovCiAJLnNob3J0CTAJCQkJLyogTWlub3IgT1MgdmVy
c2lvbiAqLwogCS5zaG9ydAkwCQkJCS8qIE1ham9yIGltYWdlIHZlcnNpb24gKi8KQEAgLTEyNCw5
ICsxMjUsOSBAQCBzZWN0aW9uX3RhYmxlOgogCS5ieXRlCTAKIAkuYnl0ZQkwCiAJLmJ5dGUJMAkJ
CQkvKiBQYWQgdG8gOCBieXRlcyAqLwotCS5sb25nCV9lZGF0YSAtIF9lbmRfaGVhZGVyCQkvKiBW
aXJ0dWFsIHNpemUgKi8KKwkubG9uZwlfZXRleHQgLSBfZW5kX2hlYWRlcgkJLyogVmlydHVhbCBz
aXplICovCiAJLmxvbmcJX2VuZF9oZWFkZXIgLSBlZmlfc3RhcnQJCS8qIFZpcnR1YWwgYWRkcmVz
cyAqLwotCS5sb25nCV9lZGF0YSAtIF9lbmRfaGVhZGVyCQkvKiBTaXplIG9mIHJhdyBkYXRhICov
CisJLmxvbmcJX2V0ZXh0IC0gX2VuZF9oZWFkZXIJCS8qIFNpemUgb2YgcmF3IGRhdGEgKi8KIAku
bG9uZwlfZW5kX2hlYWRlciAtIGVmaV9zdGFydAkJLyogUG9pbnRlciB0byByYXcgZGF0YSAqLwog
CS5sb25nCTAJCQkJLyogUG9pbnRlciB0byByZWxvY2F0aW9ucyAqLwogCS5sb25nCTAJCQkJLyog
UG9pbnRlciB0byBsaW5lIG51bWJlcnMgKi8KQEAgLTEzNCw2ICsxMzUsMjQgQEAgc2VjdGlvbl90
YWJsZToKIAkuc2hvcnQJMAkJCQkvKiBOdW1iZXIgb2YgbGluZSBudW1iZXJzICovCiAJLmxvbmcJ
KElNQUdFX1NDTl9DTlRfQ09ERSB8IElNQUdFX1NDTl9NRU1fRVhFQ1VURSB8IFwKIAkJIElNQUdF
X1NDTl9NRU1fUkVBRCkJCS8qIENoYXJhY3RlcmlzdGljcyAqLworCisJLyogVGhlIGNvbnRlbnRz
IG9mIHRoZSBsb2FkZXIgKi8KKwkuYXNjaWkJIi5kYXRhIgorCS5ieXRlCTAKKwkuYnl0ZQkwCisJ
LmJ5dGUJMAkJCQkvKiBQYWQgdG8gOCBieXRlcyAqLworCS5sb25nCV9fZGF0YV9zaXplCQkJLyog
VmlydHVhbCBzaXplICovCisJLmxvbmcJX19kYXRhX3N0YXJ0IC0gZWZpX3N0YXJ0CS8qIFZpcnR1
YWwgYWRkcmVzcyAqLworCS5sb25nCV9fZGF0YV9zaXplCQkJLyogU2l6ZSBvZiByYXcgZGF0YSAq
LworCS5sb25nCV9fZGF0YV9zdGFydCAtIGVmaV9zdGFydAkvKiBQb2ludGVyIHRvIHJhdyBkYXRh
ICovCisJLmxvbmcJMAkJCQkvKiBQb2ludGVyIHRvIHJlbG9jYXRpb25zICovCisJLmxvbmcJMAkJ
CQkvKiBQb2ludGVyIHRvIGxpbmUgbnVtYmVycyAqLworCS5zaG9ydAkwCQkJCS8qIE51bWJlciBv
ZiByZWxvY2F0aW9ucyAqLworCS5zaG9ydAkwCQkJCS8qIE51bWJlciBvZiBsaW5lIG51bWJlcnMg
Ki8KKwkubG9uZwkoSU1BR0VfU0NOX0NOVF9JTklUSUFMSVpFRF9EQVRBIHwgSU1BR0VfU0NOX01F
TV9SRUFEIHwgXAorCQkgSU1BR0VfU0NOX01FTV9XUklURSkJCS8qIENoYXJhY3RlcmlzdGljcyAq
LworCisJLmFsaWduCTEyCiBfZW5kX2hlYWRlcjoKIAogCS50ZXh0CkBAIC0xODUsMyArMjA0LDYg
QEAgaW5pdHN0YWNrOgogCS5zcGFjZQkoNjQgKiAxMDI0KQogaW5pdHN0YWNrX2VuZDoKICNlbmRp
ZgorCisJLmRhdGEKKwkuYWxpZ24JNAo=
--00000000000087029a05f088ea55--

From nobody Sat Dec 24 13:11:30 2022
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 4NfPZm402tz1LqVS
	for ; Sat, 24 Dec 2022 13:11:44 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630])
	(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 4NfPZl5lqrz4Mhj
	for ; Sat, 24 Dec 2022 13:11:43 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Q9WNgEOU;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pl1-x630.google.com with SMTP id d7so7184629pll.9
        for ; Sat, 24 Dec 2022 05:11:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=hX/dRxKz1LwuyA5V/TbUeuj753BmlFUQ89+05nbqv5s=;
        b=Q9WNgEOUtIa/NHx6GtW7ff4DMAw6Bnjtba111mMyW2n7sE1aU9qbVWB8DYCz5GyMOY
         HE1C41FPfhWJ9nRLg6UTmWP6tnDCKwtE8fQIUhalCdrVvP47DHODM3b/OJxxj3ge2sVL
         S26U7r3jOaWYSKWxiUjEAkO7kz6zDv85pVAZOAZM+ecic68dZ4O0/IwnzmmBrnla+vPn
         pDe/c9eKqXn5m8u0KV+rCfgIbKWvHSqksnyWZhvtHP6j3evaW+b78V+6CqMr+ptFXzeG
         6YdmV2dNQ0YMvt61Zb4peG49yTnAaXEvNbtE2BCA6yxnwCaSgHd8mvZtnpmk4YFI98X0
         byYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=hX/dRxKz1LwuyA5V/TbUeuj753BmlFUQ89+05nbqv5s=;
        b=de9F72ngF1LzMmJjaNU7tl9H1LJf9C738kHiM60/svJKKx0m8b54SE5N+qycAcanCR
         LXxO4biOOkaOx59jQfziJO5aZ/yPYJhr+1AQfHfjSHEY/JeNrcl+0vTPx7L/ERKth/qi
         meXB+K2Xdd3YFmJrSGfcCpjl/kPoJCKfxXaytiGdHDACOHXhyWMAY/N2JTD9U0v/r95R
         1r88yEvjrYqpRIkZ6QwQEos4OsLRWB9uN6x1Ws9CXY8fzYA9MgMNXZpaD+H5C6yf4pS1
         6UIsce3/0HqMzFi36rR/P+QgeYNX++ijE0RsQfB8EkFChzbaXT/fEfGqbrPIH7vl0OJR
         lOmg==
X-Gm-Message-State: AFqh2kqGvKKTbctUvZ8EBSDZaLQ3oAe4VUj5tV4fZk6Kv8KLDY9/CBbd
	pFMt3ZAO5KpvcomMxrMw1KAIFGz9sxjb2XBIatU=
X-Google-Smtp-Source: AMrXdXtiFLMc/lfJiQv1verkGMV0y/YCueW0XUmplyy+CdcoLF2OJvFa4XZMz35gGHDUK6S0YvB/hG6qphJ2O6erCQU=
X-Received: by 2002:a17:903:2616:b0:189:e07f:933d with SMTP id
 jd22-20020a170903261600b00189e07f933dmr869400plb.7.1671887502582; Sat, 24 Dec
 2022 05:11:42 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sat, 24 Dec 2022 22:11:30 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/mixed; boundary="000000000000b2a68705f092a4bc"
X-Spamd-Result: default: False [-1.25 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_SPAM_SHORT(0.65)[0.653];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::630:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-Rspamd-Queue-Id: 4NfPZl5lqrz4Mhj
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b2a68705f092a4bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:35 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
>
> > I run other arm64 machines w/o issue with the current code.
>
> Yes, Qualcomm's snapdragon is weird. I saw Linux people complain about
> it somewhere... Wanted to know  before I bought this Yoga C630.
>
> 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
> >
> >
> >
> > On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=
=E7=94=9F)  wrote:
> >>
> >> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as fol=
lows:
> >>
> >>  1) Merging from OpenBSD's loader code made the loader boot apart from
> >> 3 points (#2 to 4 ).
> >>  2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
> >> (might be C630 specific)
> >>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
> >> affect other snapdragon systems like Microsoft Arm Developer Kit)
> >>  4) The kernel is kicked but does not start.
> >>
> >> 1) is quite straightforward. What needs to be changed is
> >> stand/efi/loader/arch/arm64/start.S.
> >
> >
> > Can you share what needs to be done? To my eye, we don't need any chang=
es, so it would be good to know what you've had to do exactly.
>
> Attached is the diff to start.S. There are 3 points.
> 1) The loader has to be aligned to 4kb.
> 2) Proper characteristic value should be in the PE header.
> 3) .text and .data segment have to be separate.
>
> It is from OpenBSD:
> https://github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efiboot/s=
tart.S

Sorry patch to ldscript.arm64 was missing.
I am going to test your serial patch now.


> >> For 2), I do not know what to do. Currently, I commented out
> >> comconsole from struct console *consoles[] in stand/efi/loader/conf.c
> >> as a workaround. Maybe, I should write a fault handler that helps
> >> returning from the fault.
> >
> >
> > There were problems with this with HyperV on aarch64 too.
> >
> > Something like
> > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseria=
lio.c
> > index 8b3f8e83e0b3..54ee39096685 100644
> > --- a/stand/efi/loader/efiserialio.c
> > +++ b/stand/efi/loader/efiserialio.c
> > @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> >                 if (comc_port =3D=3D NULL)
> >                         return;
> >         }
> > -       comc_port->baudrate =3D COMSPEED;
> > +       comc_port->baudrate =3D 0;
> >         comc_port->ioaddr =3D 0;                  /* default port */
> > -       comc_port->databits =3D 8;                /* 8,n,1 */
> > -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> > -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> > +       comc_port->databits =3D 0;                /* 8,n,1 */
> > +       comc_port->parity =3D 0;          /* 8,n,1 */
> > +       comc_port->stopbits =3D 0;        /* 8,n,1 */
> >         comc_port->ignore_cd =3D 1;               /* ignore cd */
> >         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on */
> >         comc_port->sio =3D NULL;
> >
> > was needed.  Possibly the following would be better:
> >
> > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseria=
lio.c
> > index 8b3f8e83e0b3..54ee39096685 100644
> > --- a/stand/efi/loader/efiserialio.c
> > +++ b/stand/efi/loader/efiserialio.c
> > @@ -494,8 +494,7 @@ comc_setup(void)
> >                 return (false);
> >
> >         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> > -           comc_port->baudrate, 0, 0, comc_port->parity,
> > -           comc_port->databits, comc_port->stopbits);
> > +           0, 0, 0, 0, 0, 0);
> >         if (EFI_ERROR(status))
> >                 return (false);
> >

--000000000000b2a68705f092a4bc
Content-Type: text/plain; charset="US-ASCII"; name="stand_ldscript.diff.txt"
Content-Disposition: attachment; filename="stand_ldscript.diff.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_lc1ym6580

ZGlmZiAtLWdpdCBhL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9sZHNjcmlwdC5hcm02NCBi
L3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9sZHNjcmlwdC5hcm02NAppbmRleCBkMGVkMzIw
YTMxOWMuLjhhYmY0MTA0MjczZSAxMDA2NDQKLS0tIGEvc3RhbmQvZWZpL2xvYWRlci9hcmNoL2Fy
bTY0L2xkc2NyaXB0LmFybTY0CisrKyBiL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9sZHNj
cmlwdC5hcm02NApAQCAtMTYsNyArMTYsOSBAQCBTRUNUSU9OUwogICAgICooLmdudS53YXJuaW5n
KQogICAgICooLnBsdCkKICAgfSA9MHhENDIwMDAwMAotICAuID0gQUxJR04oMTYpOworICAuID0g
QUxJR04oNDA5Nik7CisgIF9ldGV4dCA9IC47CisgIF9fZGF0YV9zdGFydCA9IC47CiAgIC5kYXRh
CQk6IHsKICAgICAqKC5yb2RhdGEgLnJvZGF0YS4qIC5nbnUubGlua29uY2Uuci4qKQogICAgICoo
LnJvZGF0YTEpCkBAIC03NywxMCArNzksMTEgQEAgU0VDVElPTlMKICAgLnJlbG9jCTogeyAqKC5y
ZWxvYykgfQogICAuID0gQUxJR04oMTYpOwogICAuZHluc3ltCTogeyAqKC5keW5zeW0pIH0KKyAg
LmR5bnN0cgk6IHsgKiguZHluc3RyKSB9CiAgIF9lZGF0YSA9IC47CisgIF9fZGF0YV9zaXplID0g
LiAtIF9fZGF0YV9zdGFydDsKIAogICAvKiBVbnVzZWQgc2VjdGlvbnMgKi8KICAgLmludGVycAk6
IHsgKiguaW50ZXJwKSB9Ci0gIC5keW5zdHIJOiB7ICooLmR5bnN0cikgfQogICAuaGFzaAkJOiB7
ICooLmhhc2gpIH0KIH0K
--000000000000b2a68705f092a4bc--

From nobody Sat Dec 24 13:18:45 2022
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 4NfPl71Cx7z1LrH8
	for ; Sat, 24 Dec 2022 13:18:59 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c])
	(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 4NfPl61mx7z4PFL
	for ; Sat, 24 Dec 2022 13:18:58 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=jHx+4MTf;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::42c as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pf1-x42c.google.com with SMTP id y21so2679978pfo.7
        for ; Sat, 24 Dec 2022 05:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=wxro9DP1e/6QOa04HtOKAD/3SYigt4hzG3U5xmyD/Wk=;
        b=jHx+4MTfGLqghXyohjCYHfKivtvhDd57roIGB08erKb4fKHxTjCcceqBi52xS+FPt6
         Vt3XSbSAe4EeXqE3oXCMLXvHT0mfSzlFdFKFgrIfA80wKVDL4SvXuWr2S8LWQZTLq4qr
         0uNOTwTg4ghErUXpATyrUO4UUxwz7egZSdCnd4snBFjvDVTPOGTbihaB1P+yaQO3HUo8
         edFmv/U53WJ7VDRO9GJaxN9uZIFX4rZxLkH0x0KDitid2HP8IV8FyMIr7LRLbDqx59jm
         53jyBBTxGKX6grQhPVqKM0X+JB62eYtiurBmyFURcF/2jHynZ7ErbT5qbPoeeFtwpQP7
         229w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wxro9DP1e/6QOa04HtOKAD/3SYigt4hzG3U5xmyD/Wk=;
        b=VWNa5O69PXQgMMiVly5weQQ3PvzdWxT37WlTHGAQYcEMjTQ3IChWlJXga0luIOEPHf
         CV65h4Rj0mdIXqxYOZa8WNp1N0A3pFm3Z9RJ/eRmw3BiFx7tVX8C5MMfT9A+7DDFoUNE
         9Z73IOCFa4g9ZFHXvrTHa9HvymbKYN8xyqfNY+cAg38L+GL5uL97LTFy/AKGquSpG2e/
         JVNpNcLfwUyAQUD1xrqNpyLKv/R/MWgzYuPi7RcBPMh0KglSNhxlh+iIG6vUPwlo+mi0
         OCN8gwdFjduCGC8/yJF2YhsB3Qq31KzErkXT2G9lhd5fHYchNBb2UuuTcM/AcO/RQD1E
         ZDPw==
X-Gm-Message-State: AFqh2kqONsSSIOGcBg26583oiZlWpJfDQw6cfEgDKDIqD6EB88pm/UGd
	Ko1kCMdvd0A8Ng4OVO0RYtP+JZeh4C6EPAY/zdxupW75
X-Google-Smtp-Source: AMrXdXvg4Mj8YRNfN6DZzbAlXtYdqu6MPUCvNXmlE/5jXlcEFJ7h76SVGrWXcxYHh/GH7TebzRgpSyF1O6bNz3XYfw8=
X-Received: by 2002:a63:f503:0:b0:478:9809:cf15 with SMTP id
 w3-20020a63f503000000b004789809cf15mr412104pgh.12.1671887936555; Sat, 24 Dec
 2022 05:18:56 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sat, 24 Dec 2022 22:18:45 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/mixed; boundary="00000000000090433705f092be5b"
X-Spamd-Result: default: False [-1.25 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_SPAM_SHORT(0.65)[0.650];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42c:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-Rspamd-Queue-Id: 4NfPl61mx7z4PFL
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

--00000000000090433705f092be5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry again.
The patch is needed for
* stand/efi/loader/arch/arm64/start.S
* stand/efi/loader/arch/arm64/ldscript.arm64
* stand/efi/loader/Makefile

I forgot the last one. I remade the patch for three.

2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:11 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
>
> 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:35 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
> >
> > > I run other arm64 machines w/o issue with the current code.
> >
> > Yes, Qualcomm's snapdragon is weird. I saw Linux people complain about
> > it somewhere... Wanted to know  before I bought this Yoga C630.
> >
> > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
> > >
> > >
> > >
> > > On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F)  wrote:
> > >>
> > >> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as f=
ollows:
> > >>
> > >>  1) Merging from OpenBSD's loader code made the loader boot apart fr=
om
> > >> 3 points (#2 to 4 ).
> > >>  2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
> > >> (might be C630 specific)
> > >>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
> > >> affect other snapdragon systems like Microsoft Arm Developer Kit)
> > >>  4) The kernel is kicked but does not start.
> > >>
> > >> 1) is quite straightforward. What needs to be changed is
> > >> stand/efi/loader/arch/arm64/start.S.
> > >
> > >
> > > Can you share what needs to be done? To my eye, we don't need any cha=
nges, so it would be good to know what you've had to do exactly.
> >
> > Attached is the diff to start.S. There are 3 points.
> > 1) The loader has to be aligned to 4kb.
> > 2) Proper characteristic value should be in the PE header.
> > 3) .text and .data segment have to be separate.
> >
> > It is from OpenBSD:
> > https://github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efiboot=
/start.S
>
> Sorry patch to ldscript.arm64 was missing.
> I am going to test your serial patch now.
>
>
> > >> For 2), I do not know what to do. Currently, I commented out
> > >> comconsole from struct console *consoles[] in stand/efi/loader/conf.=
c
> > >> as a workaround. Maybe, I should write a fault handler that helps
> > >> returning from the fault.
> > >
> > >
> > > There were problems with this with HyperV on aarch64 too.
> > >
> > > Something like
> > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiser=
ialio.c
> > > index 8b3f8e83e0b3..54ee39096685 100644
> > > --- a/stand/efi/loader/efiserialio.c
> > > +++ b/stand/efi/loader/efiserialio.c
> > > @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> > >                 if (comc_port =3D=3D NULL)
> > >                         return;
> > >         }
> > > -       comc_port->baudrate =3D COMSPEED;
> > > +       comc_port->baudrate =3D 0;
> > >         comc_port->ioaddr =3D 0;                  /* default port */
> > > -       comc_port->databits =3D 8;                /* 8,n,1 */
> > > -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> > > -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> > > +       comc_port->databits =3D 0;                /* 8,n,1 */
> > > +       comc_port->parity =3D 0;          /* 8,n,1 */
> > > +       comc_port->stopbits =3D 0;        /* 8,n,1 */
> > >         comc_port->ignore_cd =3D 1;               /* ignore cd */
> > >         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on */
> > >         comc_port->sio =3D NULL;
> > >
> > > was needed.  Possibly the following would be better:
> > >
> > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiser=
ialio.c
> > > index 8b3f8e83e0b3..54ee39096685 100644
> > > --- a/stand/efi/loader/efiserialio.c
> > > +++ b/stand/efi/loader/efiserialio.c
> > > @@ -494,8 +494,7 @@ comc_setup(void)
> > >                 return (false);
> > >
> > >         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> > > -           comc_port->baudrate, 0, 0, comc_port->parity,
> > > -           comc_port->databits, comc_port->stopbits);
> > > +           0, 0, 0, 0, 0, 0);
> > >         if (EFI_ERROR(status))
> > >                 return (false);
> > >

--00000000000090433705f092be5b
Content-Type: text/plain; charset="US-ASCII"; name="stand.diff.txt"
Content-Disposition: attachment; filename="stand.diff.txt"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: f_lc1ywa5p0

ZGlmZiAtLWdpdCBhL3N0YW5kL2VmaS9sb2FkZXIvTWFrZWZpbGUgYi9zdGFuZC9lZmkvbG9hZGVy
L01ha2VmaWxlCmluZGV4IDJhYWJhNGZiYjM3Ny4uNDQ4M2Y1MjRlNDNhIDEwMDY0NAotLS0gYS9z
dGFuZC9lZmkvbG9hZGVyL01ha2VmaWxlCisrKyBiL3N0YW5kL2VmaS9sb2FkZXIvTWFrZWZpbGUK
QEAgLTExNCw4ICsxMTQsOSBAQCAke0xPQURFUn0uZWZpOiAke1BST0d9CiAJZmkKIAlTT1VSQ0Vf
REFURV9FUE9DSD0ke1NPVVJDRV9EQVRFX0VQT0NIfSBcCiAJJHtPQkpDT1BZfSAtaiAucGVoZWFk
ZXIgLWogLnRleHQgLWogLnNkYXRhIC1qIC5kYXRhIFwKLQkJLWogLmR5bmFtaWMgLWogLmR5bnN5
bSAtaiAucmVsLmR5biBcCi0JCS1qIC5yZWxhLmR5biAtaiAucmVsb2MgLWogLmVoX2ZyYW1lIC1q
IHNldF9YY29tbWFuZF9zZXQgXAorCQktaiAuZHluYW1pYyAtaiAuZHluc3ltIC1qIC5keW5zdHIg
LWogLnJlbCAtaiAucmVsLmR5biBcCisJCS1qIC5yZWxhIC1qIC5yZWxhLmR5biAtaiAucmVsb2Mg
LWogLmVoX2ZyYW1lIFwKKwkJLWogc2V0X1hjb21tYW5kX3NldCBcCiAJCS1qIHNldF9YZmljbF9j
b21waWxlX3NldCBcCiAJCS0tb3V0cHV0LXRhcmdldD0ke0VGSV9UQVJHRVR9ICR7LkFMTFNSQ30g
JHsuVEFSR0VUfQogCmRpZmYgLS1naXQgYS9zdGFuZC9lZmkvbG9hZGVyL2FyY2gvYXJtNjQvbGRz
Y3JpcHQuYXJtNjQgYi9zdGFuZC9lZmkvbG9hZGVyL2FyY2gvYXJtNjQvbGRzY3JpcHQuYXJtNjQK
aW5kZXggZDBlZDMyMGEzMTljLi44YWJmNDEwNDI3M2UgMTAwNjQ0Ci0tLSBhL3N0YW5kL2VmaS9s
b2FkZXIvYXJjaC9hcm02NC9sZHNjcmlwdC5hcm02NAorKysgYi9zdGFuZC9lZmkvbG9hZGVyL2Fy
Y2gvYXJtNjQvbGRzY3JpcHQuYXJtNjQKQEAgLTE2LDcgKzE2LDkgQEAgU0VDVElPTlMKICAgICAq
KC5nbnUud2FybmluZykKICAgICAqKC5wbHQpCiAgIH0gPTB4RDQyMDAwMDAKLSAgLiA9IEFMSUdO
KDE2KTsKKyAgLiA9IEFMSUdOKDQwOTYpOworICBfZXRleHQgPSAuOworICBfX2RhdGFfc3RhcnQg
PSAuOwogICAuZGF0YQkJOiB7CiAgICAgKigucm9kYXRhIC5yb2RhdGEuKiAuZ251LmxpbmtvbmNl
LnIuKikKICAgICAqKC5yb2RhdGExKQpAQCAtNzcsMTAgKzc5LDExIEBAIFNFQ1RJT05TCiAgIC5y
ZWxvYwk6IHsgKigucmVsb2MpIH0KICAgLiA9IEFMSUdOKDE2KTsKICAgLmR5bnN5bQk6IHsgKigu
ZHluc3ltKSB9CisgIC5keW5zdHIJOiB7ICooLmR5bnN0cikgfQogICBfZWRhdGEgPSAuOworICBf
X2RhdGFfc2l6ZSA9IC4gLSBfX2RhdGFfc3RhcnQ7CiAKICAgLyogVW51c2VkIHNlY3Rpb25zICov
CiAgIC5pbnRlcnAJOiB7ICooLmludGVycCkgfQotICAuZHluc3RyCTogeyAqKC5keW5zdHIpIH0K
ICAgLmhhc2gJCTogeyAqKC5oYXNoKSB9CiB9CmRpZmYgLS1naXQgYS9zdGFuZC9lZmkvbG9hZGVy
L2FyY2gvYXJtNjQvc3RhcnQuUyBiL3N0YW5kL2VmaS9sb2FkZXIvYXJjaC9hcm02NC9zdGFydC5T
CmluZGV4IDY3NWQ0ZTE1M2YzNi4uMzdlMTE3ZDY3OWEwIDEwMDY0NAotLS0gYS9zdGFuZC9lZmkv
bG9hZGVyL2FyY2gvYXJtNjQvc3RhcnQuUworKysgYi9zdGFuZC9lZmkvbG9hZGVyL2FyY2gvYXJt
NjQvc3RhcnQuUwpAQCAtMzksNiArMzksNyBAQAogI2RlZmluZQlJTUFHRV9TQ05fTUVNX0RJU0NB
UkRBQkxFCTB4MDIwMDAwMDAKICNkZWZpbmUJSU1BR0VfU0NOX01FTV9FWEVDVVRFCQkweDIwMDAw
MDAwCiAjZGVmaW5lCUlNQUdFX1NDTl9NRU1fUkVBRAkJMHg0MDAwMDAwMAorI2RlZmluZQlJTUFH
RV9TQ05fTUVNX1dSSVRFCQkweDgwMDAwMDAwCiAKIAkuc2VjdGlvbiAucGVoZWFkZXIsImEiCiBl
Zmlfc3RhcnQ6CkBAIC01NSwyNyArNTYsMjcgQEAgcGVfc2lnOgogCS5zaG9ydAkwCiBjb2ZmX2hl
YWQ6CiAJLnNob3J0CUlNQUdFX0ZJTEVfTUFDSElORV9BUk02NAkvKiBBQXJjaDY0IGZpbGUgKi8K
LQkuc2hvcnQJMgkJCQkvKiAyIFNlY3Rpb25zICovCisJLnNob3J0CTMJCQkJLyogMiBTZWN0aW9u
cyAqLwogCS5sb25nCTAJCQkJLyogVGltZXN0YW1wICovCiAJLmxvbmcJMAkJCQkvKiBObyBzeW1i
b2wgdGFibGUgKi8KIAkubG9uZwkwCQkJCS8qIE5vIHN5bWJvbHMgKi8KIAkuc2hvcnQJc2VjdGlv
bl90YWJsZSAtIG9wdGlvbmFsX2hlYWRlcgkvKiBPcHRpb25hbCBoZWFkZXIgc2l6ZSAqLwotCS5z
aG9ydAkwCS8qIENoYXJhY3RlcmlzdGljcyBUT0RPOiBGaWxsIGluICovCisJLnNob3J0CTB4MDIw
NgkJCQkvKiBDaGFyYWN0ZXJpc3RpY3MgKi8KIAogb3B0aW9uYWxfaGVhZGVyOgogCS5zaG9ydAkw
eDAyMGIJCQkJLyogUEUzMisgKDY0LWJpdCBhZGRyZXNzaW5nKSAqLwogCS5ieXRlCTAJCQkJLyog
TWFqb3IgbGlua2VyIHZlcnNpb24gKi8KIAkuYnl0ZQkwCQkJCS8qIE1pbm9yIGxpbmtlciB2ZXJz
aW9uICovCi0JLmxvbmcJX2VkYXRhIC0gX2VuZF9oZWFkZXIJCS8qIENvZGUgc2l6ZSAqLwotCS5s
b25nCTAJCQkJLyogTm8gaW5pdGlhbGl6ZWQgZGF0YSAqLworCS5sb25nCV9ldGV4dCAtIF9lbmRf
aGVhZGVyCQkvKiBDb2RlIHNpemUgKi8KKwkubG9uZwlfX2RhdGFfc2l6ZQkJCS8qIE5vIGluaXRp
YWxpemVkIGRhdGEgKi8KIAkubG9uZwkwCQkJCS8qIE5vIHVuaW5pdGlhbGl6ZWQgZGF0YSAqLwog
CS5sb25nCV9zdGFydCAtIGVmaV9zdGFydAkJLyogRW50cnkgcG9pbnQgKi8KIAkubG9uZwlfZW5k
X2hlYWRlciAtIGVmaV9zdGFydAkJLyogU3RhcnQgb2YgY29kZSAqLwogCiBvcHRpb25hbF93aW5k
b3dzX2hlYWRlcjoKIAkucXVhZAkwCQkJCS8qIEltYWdlIGJhc2UgKi8KLQkubG9uZwkzMgkJCQkv
KiBTZWN0aW9uIEFsaWdubWVudCAqLwotCS5sb25nCTgJCQkJLyogRmlsZSBhbGlnbm1lbnQgKi8K
KwkubG9uZwk0MDk2CQkJCS8qIFNlY3Rpb24gQWxpZ25tZW50ICovCisJLmxvbmcJNTEyCQkJCS8q
IEZpbGUgYWxpZ25tZW50ICovCiAJLnNob3J0CTAJCQkJLyogTWFqb3IgT1MgdmVyc2lvbiAqLwog
CS5zaG9ydAkwCQkJCS8qIE1pbm9yIE9TIHZlcnNpb24gKi8KIAkuc2hvcnQJMAkJCQkvKiBNYWpv
ciBpbWFnZSB2ZXJzaW9uICovCkBAIC0xMjQsOSArMTI1LDkgQEAgc2VjdGlvbl90YWJsZToKIAku
Ynl0ZQkwCiAJLmJ5dGUJMAogCS5ieXRlCTAJCQkJLyogUGFkIHRvIDggYnl0ZXMgKi8KLQkubG9u
ZwlfZWRhdGEgLSBfZW5kX2hlYWRlcgkJLyogVmlydHVhbCBzaXplICovCisJLmxvbmcJX2V0ZXh0
IC0gX2VuZF9oZWFkZXIJCS8qIFZpcnR1YWwgc2l6ZSAqLwogCS5sb25nCV9lbmRfaGVhZGVyIC0g
ZWZpX3N0YXJ0CQkvKiBWaXJ0dWFsIGFkZHJlc3MgKi8KLQkubG9uZwlfZWRhdGEgLSBfZW5kX2hl
YWRlcgkJLyogU2l6ZSBvZiByYXcgZGF0YSAqLworCS5sb25nCV9ldGV4dCAtIF9lbmRfaGVhZGVy
CQkvKiBTaXplIG9mIHJhdyBkYXRhICovCiAJLmxvbmcJX2VuZF9oZWFkZXIgLSBlZmlfc3RhcnQJ
CS8qIFBvaW50ZXIgdG8gcmF3IGRhdGEgKi8KIAkubG9uZwkwCQkJCS8qIFBvaW50ZXIgdG8gcmVs
b2NhdGlvbnMgKi8KIAkubG9uZwkwCQkJCS8qIFBvaW50ZXIgdG8gbGluZSBudW1iZXJzICovCkBA
IC0xMzQsNiArMTM1LDI0IEBAIHNlY3Rpb25fdGFibGU6CiAJLnNob3J0CTAJCQkJLyogTnVtYmVy
IG9mIGxpbmUgbnVtYmVycyAqLwogCS5sb25nCShJTUFHRV9TQ05fQ05UX0NPREUgfCBJTUFHRV9T
Q05fTUVNX0VYRUNVVEUgfCBcCiAJCSBJTUFHRV9TQ05fTUVNX1JFQUQpCQkvKiBDaGFyYWN0ZXJp
c3RpY3MgKi8KKworCS8qIFRoZSBjb250ZW50cyBvZiB0aGUgbG9hZGVyICovCisJLmFzY2lpCSIu
ZGF0YSIKKwkuYnl0ZQkwCisJLmJ5dGUJMAorCS5ieXRlCTAJCQkJLyogUGFkIHRvIDggYnl0ZXMg
Ki8KKwkubG9uZwlfX2RhdGFfc2l6ZQkJCS8qIFZpcnR1YWwgc2l6ZSAqLworCS5sb25nCV9fZGF0
YV9zdGFydCAtIGVmaV9zdGFydAkvKiBWaXJ0dWFsIGFkZHJlc3MgKi8KKwkubG9uZwlfX2RhdGFf
c2l6ZQkJCS8qIFNpemUgb2YgcmF3IGRhdGEgKi8KKwkubG9uZwlfX2RhdGFfc3RhcnQgLSBlZmlf
c3RhcnQJLyogUG9pbnRlciB0byByYXcgZGF0YSAqLworCS5sb25nCTAJCQkJLyogUG9pbnRlciB0
byByZWxvY2F0aW9ucyAqLworCS5sb25nCTAJCQkJLyogUG9pbnRlciB0byBsaW5lIG51bWJlcnMg
Ki8KKwkuc2hvcnQJMAkJCQkvKiBOdW1iZXIgb2YgcmVsb2NhdGlvbnMgKi8KKwkuc2hvcnQJMAkJ
CQkvKiBOdW1iZXIgb2YgbGluZSBudW1iZXJzICovCisJLmxvbmcJKElNQUdFX1NDTl9DTlRfSU5J
VElBTElaRURfREFUQSB8IElNQUdFX1NDTl9NRU1fUkVBRCB8IFwKKwkJIElNQUdFX1NDTl9NRU1f
V1JJVEUpCQkvKiBDaGFyYWN0ZXJpc3RpY3MgKi8KKworCS5hbGlnbgkxMgogX2VuZF9oZWFkZXI6
CiAKIAkudGV4dApAQCAtMTg1LDMgKzIwNCw2IEBAIGluaXRzdGFjazoKIAkuc3BhY2UJKDY0ICog
MTAyNCkKIGluaXRzdGFja19lbmQ6CiAjZW5kaWYKKworCS5kYXRhCisJLmFsaWduCTQK
--00000000000090433705f092be5b--

From nobody Sun Dec 25 01:46:37 2022
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 4NfkL34Ntvz1HWX4
	for ; Sun, 25 Dec 2022 01:46:51 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531])
	(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 4NfkL253Q1z3kNx
	for ; Sun, 25 Dec 2022 01:46:50 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Uz6r3uOm;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pg1-x531.google.com with SMTP id w37so5453690pga.5
        for ; Sat, 24 Dec 2022 17:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=77nlnj/tAB57RxkJkNRQgDB3y6BKB+yRtHiuToYxJyA=;
        b=Uz6r3uOmvnMs1nuz62cjNtLPpmiSlqq59JGk6uazkaafrRvr/Qf7BRfL8ZloKqK0uv
         QQXiUp5N3Ez1tZ+8c2gh8IfZDVG+7c05BwAoD8juqbsM0knPZyKsXqkI8tMOcz+QJkE8
         NhbiaO4zTuruQD2pbnmbKIZLeww7pI99oo7PcTZss4sPRTO378s/MJglU6HdfbN44g7R
         sopojHjZY9Neg/ZqubaFfZVF0W9tJFoqbzwv05bcp7Uzi34XtxhVv8ttWSCYOyIIFISY
         DAUpcDvwzLquYBEpWAoFRWVsKLpyNSbW+iIm502+YYdaztrQNEzKxrRrzznNQHtoRVDJ
         GlvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=77nlnj/tAB57RxkJkNRQgDB3y6BKB+yRtHiuToYxJyA=;
        b=Vs6KBOkBEgUpETsfq4kwUXcVD3Ys54SyGg55DjYWK44cTU6Fmwltp6b+3MQ28qnARi
         MZQhc58qI6EZyGfpxHFYGJE0zFQhO++hwGoejXExVx8f08vIpbBr86p9iCGo2PUCWdvR
         m7Ct2DOh9a7LYibWyFrJhY4GbcPKIjTP3wuTTw6KIuGpTHp0jmESXz9abxdysRRh/a6G
         1iai1ZBFyUhG/NLu0iLcRM+DMkgxOZ60PPeB33v3TG3s7/892XSfKrLf+m5uBrtAZjQ3
         /ELDzt8HPlJHdvDhE3k2ZzlADfUNTfPPJz35MGtKlQ3mmSiT4ITiAdjfyJCJWcAoJKDM
         1T+A==
X-Gm-Message-State: AFqh2kodnoA7mYwtjFiUms+6pFHeri9b3BkdTj1LpjtVjs9FIL1Fpkt5
	/vbmBnuJvGII1KcecjCT9AYlNNTUPCtZMwpeFUHYntOXUuA=
X-Google-Smtp-Source: AMrXdXu0NXlAOG2TTRgo40RV2CnQ+LFQtXFhjSzyZptS9yW8vD1vpIVzhvtR8NGbupVDqtsw82Ge7DKKHUy1jhBLF1w=
X-Received: by 2002:aa7:9202:0:b0:574:5c9e:c1f2 with SMTP id
 2-20020aa79202000000b005745c9ec1f2mr1095680pfo.52.1671932809323; Sat, 24 Dec
 2022 17:46:49 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sun, 25 Dec 2022 10:46:37 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-3.39 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.78)[-0.783];
	NEURAL_HAM_SHORT(-0.60)[-0.605];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::531:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NfkL253Q1z3kNx
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
>
>
>
> On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F)  wrote:
>>
>> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as follo=
ws:
>>
>>  1) Merging from OpenBSD's loader code made the loader boot apart from
>> 3 points (#2 to 4 ).
>>  2) when comconsole->c_init() runs the 2nd time, it seems to freeze.
>> (might be C630 specific)
>>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
>> affect other snapdragon systems like Microsoft Arm Developer Kit)
>>  4) The kernel is kicked but does not start.
>>
>> 1) is quite straightforward. What needs to be changed is
>> stand/efi/loader/arch/arm64/start.S.
>
>
> Can you share what needs to be done? To my eye, we don't need any changes=
, so it would be good to know what you've had to do exactly.
>
>>
>> For 2), I do not know what to do. Currently, I commented out
>> comconsole from struct console *consoles[] in stand/efi/loader/conf.c
>> as a workaround. Maybe, I should write a fault handler that helps
>> returning from the fault.
>
>
> There were problems with this with HyperV on aarch64 too.
>
> Something like
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
>                 if (comc_port =3D=3D NULL)
>                         return;
>         }
> -       comc_port->baudrate =3D COMSPEED;
> +       comc_port->baudrate =3D 0;
>         comc_port->ioaddr =3D 0;                  /* default port */
> -       comc_port->databits =3D 8;                /* 8,n,1 */
> -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> +       comc_port->databits =3D 0;                /* 8,n,1 */
> +       comc_port->parity =3D 0;          /* 8,n,1 */
> +       comc_port->stopbits =3D 0;        /* 8,n,1 */
>         comc_port->ignore_cd =3D 1;               /* ignore cd */
>         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on */
>         comc_port->sio =3D NULL;
>
> was needed.  Possibly the following would be better:
>
> diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efiseriali=
o.c
> index 8b3f8e83e0b3..54ee39096685 100644
> --- a/stand/efi/loader/efiserialio.c
> +++ b/stand/efi/loader/efiserialio.c
> @@ -494,8 +494,7 @@ comc_setup(void)
>                 return (false);
>
>         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> -           comc_port->baudrate, 0, 0, comc_port->parity,
> -           comc_port->databits, comc_port->stopbits);
> +           0, 0, 0, 0, 0, 0);
>         if (EFI_ERROR(status))
>                 return (false);

Following change could avoid freeze in comconsole->c_init().
----------
--- a/stand/efi/loader/efiserialio.c
+++ b/stand/efi/loader/efiserialio.c
@@ -467,8 +467,10 @@ comc_speed_set(struct env_var *ev, int flags,
const void *value)
        if (comc_parse_intval(value, &speed) !=3D CMD_OK)
                return (CMD_ERROR);

-       comc_port->baudrate =3D speed;
-       (void) comc_setup();
+       if (comc_port->baudrate !=3D speed) {
+               comc_port->baudrate =3D speed;
+               (void) comc_setup();
+       }

        env_setenv(ev->ev_name, flags | EV_NOHOOK, value, NULL, NULL);
----------

comc_speed_set sets new speed to comc_port->baudrate and calls comc_setup()=
.
But if the new value of comc_port->baudrate is same as the previous
one, comc_setup() freezes at
    status =3D comc_port->sio->GetControl(comc_port->sio, &control);

Now, the remaining problem is that the kernel does not start.
Linux and OpenBSD run on the machine, so there should be a solution...

>> 3), I dumped each memory map's VirtualStart and PhysicalStart. All
>> VirtualStart were 0. So overwriting VirutalStart by the value of
>> PhysicalStart and running SetVirtualAddressMap should work. But in
>> reality, it doesn't.
>>   OpenBSD does not use SetVirtualAddress for arm64 and Linux seems to
>> have abandoned it for arm64 in 2019.
>>     https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?=
id=3D4e46c2a956215482418d7b315749fb1b6c6bc224
>>   Maybe, we also can avoid SetVirtualAddressMap (by
>> efi_disable_vmap=3D"YES"). In this case, (as you wrote) I should change
>> the kernel to treat VA=3D=3DPA if VirtualStart is 0. (OpenBSD seems to d=
o
>> so).
>
>
> FreeBSD tends to prefer this... Our kernel needs to cope with cases where=
 it has
> been called (many kexec environments provide PA !=3D VA virtual mappings =
that we
> can't change).
>
>>
>> About 4), I am completely confused. In elf64_exec in
>> stand/efi/loader/arch/arm64/exec.c, the memory address that the kernel
>> was loaded is calculated as:
>>     entry =3D efi_translate(ehdr->e_entry);  // which becomes 0xb340000
>> and later kicked as:
>>     (*entry)(modulep);
>> I wrote that this calculation is doubtful, but it was right. I dumped
>> the data at the address 0xb340000 and compared it with the output of
>> objdump -D loader_lua.syms. It turned out that it matched with the
>> kernel's _start code in locore.S.
>> Putting some code that jumps to loader's ImageBase address at the
>> start of kernel's _start did not change anything, so I judged that the
>> kernel is not started at all.
>> The excerpt of the loader's memmap command output is as follows:
>>     Type           Physical           Virtual              #Pages     At=
tr
>>     LoaderData 0000b33ea000  000000000000  00000000  UC WC WT WB WP RP X=
P
>>     LoaderCode 0000bb909000  000000000000  000000d1 UC WC WT WB WP RP XP
>> From this output, I wonder if the memory attributes on Yoga C630 is
>> properly implemented, but as XP (exec protect) bit is on, I tried to
>> set it off by DXE services' SetMemoryAttributes() (with a lot of
>> transcription from the standards...).It succeeded, but the kernel
>> still did not run.
>>
>> From this tweet:
>> https://twitter.com/canadianbryan/status/1598053941270679552 and its
>> replies, the Microsoft Arm Developer Kit seems to have similar
>> problem, so if somebody succeeded to run FreeBSD on it, please share
>> the information how to do it.
>
>
> I run other arm64 machines w/o issue with the current code. I've not hear=
d from Allan
> for his changes, nor seen any reviews come through...
>
> Where can one buy one of these systems. It seems just odd-ball enough tha=
t I can
> justify picking one up for work...

Currently, a Snapdragon system easy to purchase is the Microsoft Arm
Developer Kit, I suppose. It is about $600.
For laptops, Qualcomm has a list:
https://www.qualcomm.com/products/application/mobile-computing/laptop-devic=
e-finder

> Warner

From nobody Sun Dec 25 02:55:10 2022
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 4Nfls72rKhz1HwWS
	for ; Sun, 25 Dec 2022 02:55:23 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431])
	(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 4Nfls65Mm3z3sjF
	for ; Sun, 25 Dec 2022 02:55:22 +0000 (UTC)
	(envelope-from hiroo.ono@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=dmI4yhOM;
	spf=pass (mx1.freebsd.org: domain of hiroo.ono@gmail.com designates 2607:f8b0:4864:20::431 as permitted sender) smtp.mailfrom=hiroo.ono@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pf1-x431.google.com with SMTP id c7so5522545pfc.12
        for ; Sat, 24 Dec 2022 18:55:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=ZU0OVwnYeccp0t9WoxmDgpzCkursM/mY30INCDNwlGw=;
        b=dmI4yhOMG0hSunTZbZMFREVGK1q+/lUenxGQh08cbTwKwSHaeaZDjgNj5eMUlBVvq8
         +YIT+kefkKW90B9WHUpROl3miHhPkJ2b7ptOOvCmJnG5T388BFy/NcKmh8tXq7TqH6Y6
         AUp2rVoiwf2bo3DQcBc029lVQF9icarWIAIJ1uxkZr+KuisYO7BmjME4LJHo0WemO+jq
         hTbZoW6CP1jkOR3+HOukdamGGhFdo+v//f/Dz+5BZfYIgGTHy17RWvUZqPr94YyS7559
         Q7sojKR/DoSemXyPz3U8w0P632PZaBi+rpoAlfhQVVfhdrCkis/FgNaXg+trSpgranaM
         Z/KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :reply-to:in-reply-to:references:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=ZU0OVwnYeccp0t9WoxmDgpzCkursM/mY30INCDNwlGw=;
        b=tDDqVgmpVadV63KJTLHbMjdB28FDSCLFWqGBb9a0ph74czuQSUvW+4ov7cCTDiOaZX
         QqPmRaQX8ZqKgvCCzDdOYMriFFWcWSbrGNWCkR/5vfkqdnHOjbKTnH155CrzShfNthst
         xkpLWhU0u6onp1GBman+tqIz+bn/hsgZ+AXJvkt07aqT/VvLDztqs0lEgWCJgDx6wJiH
         ouGNQH/xQWo52U4am+jENYiJa8Sov4qNp6kVSoqXJzIEiTFv0Edw2AsEQynD2uQybWKC
         k/AS5BfJxakMk8QSZtM866G5y3EyTrsuU2Xw5AojRPRDAaDJwBV8YiUsvvSFc3Y4WjKz
         w8/A==
X-Gm-Message-State: AFqh2koEwlGmjPlqAVACj3IS4fEBxP6epFioYwwjyQDKsHnfNPokHnqR
	vwqy1nFj6RnwqWLSO+Ekxw1l6BOkIwWjq+vlSOmnD079mIc=
X-Google-Smtp-Source: AMrXdXuDYlsfgm6uX4zjXwmbcnva2XT8/TL/X2BGTztoXG7UTdr0smtVKEF7j53hPBWtjm1uKFs119XvL4jQ+W1zDHU=
X-Received: by 2002:a63:571d:0:b0:478:d3a8:6ba5 with SMTP id
 l29-20020a63571d000000b00478d3a86ba5mr649631pgb.619.1671936921467; Sat, 24
 Dec 2022 18:55:21 -0800 (PST)
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: 
Reply-To: hiroo.ono+freebsd@gmail.com
From: =?UTF-8?B?SGlyb28gT25vICjlsI/ph47lr5vnlJ8p?= 
Date: Sun, 25 Dec 2022 11:55:10 +0900
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: Warner Losh 
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-2.31 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.85)[-0.848];
	NEURAL_SPAM_SHORT(0.54)[0.536];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_REPLYTO(0.00)[hiroo.ono+freebsd@gmail.com];
	FREEMAIL_REPLYTO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::431:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	TAGGED_FROM(0.00)[freebsd];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]
X-Rspamd-Queue-Id: 4Nfls65Mm3z3sjF
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Equivalent change by Allan Jude is under review.
https://reviews.freebsd.org/D37766

I have already tried this change, but it did not succeeded for me.
https://reviews.freebsd.org/D37765

2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:18 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
>
> Sorry again.
> The patch is needed for
> * stand/efi/loader/arch/arm64/start.S
> * stand/efi/loader/arch/arm64/ldscript.arm64
> * stand/efi/loader/Makefile
>
> I forgot the last one. I remade the patch for three.
>
> 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:11 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
> >
> > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:35 Hiroo Ono (=E5=B0=
=8F=E9=87=8E=E5=AF=9B=E7=94=9F) :
> > >
> > > > I run other arm64 machines w/o issue with the current code.
> > >
> > > Yes, Qualcomm's snapdragon is weird. I saw Linux people complain abou=
t
> > > it somewhere... Wanted to know  before I bought this Yoga C630.
> > >
> > > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
> > > >
> > > >
> > > >
> > > > On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=
=9B=E7=94=9F)  wrote:
> > > >>
> > > >> The current status of FreeBSD 14-current on Lenovo Yoga C630 is as=
 follows:
> > > >>
> > > >>  1) Merging from OpenBSD's loader code made the loader boot apart =
from
> > > >> 3 points (#2 to 4 ).
> > > >>  2) when comconsole->c_init() runs the 2nd time, it seems to freez=
e.
> > > >> (might be C630 specific)
> > > >>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
> > > >> affect other snapdragon systems like Microsoft Arm Developer Kit)
> > > >>  4) The kernel is kicked but does not start.
> > > >>
> > > >> 1) is quite straightforward. What needs to be changed is
> > > >> stand/efi/loader/arch/arm64/start.S.
> > > >
> > > >
> > > > Can you share what needs to be done? To my eye, we don't need any c=
hanges, so it would be good to know what you've had to do exactly.
> > >
> > > Attached is the diff to start.S. There are 3 points.
> > > 1) The loader has to be aligned to 4kb.
> > > 2) Proper characteristic value should be in the PE header.
> > > 3) .text and .data segment have to be separate.
> > >
> > > It is from OpenBSD:
> > > https://github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efibo=
ot/start.S
> >
> > Sorry patch to ldscript.arm64 was missing.
> > I am going to test your serial patch now.
> >
> >
> > > >> For 2), I do not know what to do. Currently, I commented out
> > > >> comconsole from struct console *consoles[] in stand/efi/loader/con=
f.c
> > > >> as a workaround. Maybe, I should write a fault handler that helps
> > > >> returning from the fault.
> > > >
> > > >
> > > > There were problems with this with HyperV on aarch64 too.
> > > >
> > > > Something like
> > > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efis=
erialio.c
> > > > index 8b3f8e83e0b3..54ee39096685 100644
> > > > --- a/stand/efi/loader/efiserialio.c
> > > > +++ b/stand/efi/loader/efiserialio.c
> > > > @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> > > >                 if (comc_port =3D=3D NULL)
> > > >                         return;
> > > >         }
> > > > -       comc_port->baudrate =3D COMSPEED;
> > > > +       comc_port->baudrate =3D 0;
> > > >         comc_port->ioaddr =3D 0;                  /* default port *=
/
> > > > -       comc_port->databits =3D 8;                /* 8,n,1 */
> > > > -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> > > > -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> > > > +       comc_port->databits =3D 0;                /* 8,n,1 */
> > > > +       comc_port->parity =3D 0;          /* 8,n,1 */
> > > > +       comc_port->stopbits =3D 0;        /* 8,n,1 */
> > > >         comc_port->ignore_cd =3D 1;               /* ignore cd */
> > > >         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is on =
*/
> > > >         comc_port->sio =3D NULL;
> > > >
> > > > was needed.  Possibly the following would be better:
> > > >
> > > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi/loader/efis=
erialio.c
> > > > index 8b3f8e83e0b3..54ee39096685 100644
> > > > --- a/stand/efi/loader/efiserialio.c
> > > > +++ b/stand/efi/loader/efiserialio.c
> > > > @@ -494,8 +494,7 @@ comc_setup(void)
> > > >                 return (false);
> > > >
> > > >         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> > > > -           comc_port->baudrate, 0, 0, comc_port->parity,
> > > > -           comc_port->databits, comc_port->stopbits);
> > > > +           0, 0, 0, 0, 0, 0);
> > > >         if (EFI_ERROR(status))
> > > >                 return (false);
> > > >

From nobody Sun Dec 25 03:15:43 2022
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 4NfmJv6wWZz1J0GK
	for ; Sun, 25 Dec 2022 03:15:59 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.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 4NfmJt4tzPz3w13
	for ; Sun, 25 Dec 2022 03:15:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="SA9QFj/D";
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 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=1671938156; bh=tW2j8CnDPeAGkayjXj1c8HvBS0XEqwTMOD/x/cyznMg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SA9QFj/D6l4xowsKCoeLJhW2Cwt3xsQhNtvBwt+TyqZGg3cIFcta+p8QMk6vF821K8NP8IqRxQ+P6ktJBs1SJ3LnLZBzMrjiOMHgb5t8K9mwfQdMPoGFEuJ4wfwFHVMurETrVt/6+uJsd0aqeHTl/6FK0H6yqDfVtwuyKNO9b9C9pvbYXcrxTSHLHw5nsb8EyzF7miOCJK1nK9CRPPWAlCyWo2Tp4v5ITqh71sUXZp+1mt6/4rM85mF6DMIXiW2EiZ9EMS2cvtPOa0nOPoI1IOLEBQFeIBgpbQFOOVT4erTGsg4oIe35cNmbk1VJLe/EWzglJvA1Z3CSyp/9HhXrfg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671938156; bh=st4WIr/QemW1d9HLIj/aEyppqqekkAnJQJMyDDN72nb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=H0hdK5JiyZjpSCd6ZnGq803UT9MEjYhqASF+nO1mtMNBjmqXXqvnndgXBLdavxKbgz4Gj7vmE6N5ASL1qh+oJJOP0N9iwEAJg2q8PxtQREsexbd0MiIJqLJjn+mttDdvzD/rBBD5wA0/cnuziUef3x2BmU13OjoxK4M46ptslbDCKYR9jtSPERA5Rf36Hl0xQK+gEOwcViFth6CLqJ2DK/Wh4A22wUKHDJHH1UyJtfF84UGwpOdQ2O57MG3D7B6YAZOkajUJ2u9hdiqI+aRSRQ/S+bkv73HkkZg+132ZGddFRSBz2S/6enbYQ2VIETB7MyVRN8iWsYmfjEMFDxZpLA==
X-YMail-OSG: azTER9kVM1mywro46pkp6QiFRrp5N.AwZa7_F1XVXd.dkRbc1ctfDOrgvufdyoH
 DVciuEFA_lFDUVV0HB5b4sqBWxeOEMq6H79MM2VzeVWJ3DeUx67l9WQdoI_W5jVZeMLNrDmsQVX5
 jz3wWQdBK6..3DcGfvCg1xi5e65Gvt2t6qUyMPiX5sqRiTC0SxJdClL9p26tDQEisikt6NMtUMLD
 5HuNTMKlody.Va7CWbO1_y.ZtVSMTGE9NntkO_u5GvqbsroqH1_SJLcILJxuWAEMZ8xxnuMeaOB.
 NKgF8GDgseL8SvoccelvDUOvihrVSt31Uttg5FeOe4y5lfqE9MVV.JgGEfxDMpXufHfX4cJgeKtd
 KSA2yQy5rK24ycXVUCiirGKveehX04O1XcB0OQZekWdHgiI14wiDN_GESQy0vcnVQsmTnaU2ZNuH
 HvELpkexd_OpZy.GdnZSiFkF7bMtmUaILwn56cN9rqKyZUnnwenJ.BmRUUSeg6altXwvb9FTuOOs
 xzxk89NaI_kyj5gqAX7kVjywfH9lpeDu2Do9AWlCCXUvg5fei_zxGLcJYaoTU5CI1VJjEjDHBSql
 xEkXluCkvFKZhOk.6M1zXLmH5muTv070YrfczraCCK7LNHE7rrE1p_ELeP8pQykgXT4036j8grNB
 fohXxvxuL7Ds2QTtLfOgRhmjrfPh931LQN32TGXzNdK7MmUXGtSAXFNzthe74PNRgX9GLIgcJnhR
 Aqw44WJwIz3O7fWg7FuUOydkVRG5N7V3oDnMQPICzQsVnUUQkEFmzwS8EkMan30sbeojqj_DNClu
 3zihS6ejo7ZlWw3N4rF.AP4vMEh1hSxmKfpqWpbDdjJd6WlOnBBwHIid4BIroI5ueI8j1EzF4rCE
 x0GzvSOhkWYcyovIZ0JwN9GyEMa8tAhY7_iQx_H.vOQEBMOgl7ao70o3dO5JwAyEil4OhMNsYhxp
 ACXY3k4ks9zYGLjpmJree56Sy8Hn.7lmaFE.rZnn7cdUZtaoSWvJQ_fC94uxwf32gy_aO0wyao5G
 VnsUwxZGkr8mdIqWhrizLYStIqoIPWrJTBbLCyGLhCIjAjz.dmfemz7Nj1qcHvJ3OV7mTPEImbi3
 3Ck8P6ZAf5RDqx7frofTjDpQ1RFnloSbGp9WDdWwHfvxRFA5lIGQBNhJsSUluUT0B3tBvZKoEM5_
 SJv788TgGYum8BhDhzAoDuHgPQ1UqH3IRNrVeMlJj6yjtc37xkZBB4vGdtnwEMNZsVfTc8KvA9r_
 YD_2a5vk8AI.E7ieVIR1hqW1tOCOlN2pYUc9Dta.ei1uznjrucvFOg55_dUS6BRuJuNOf2TBLOmm
 ljZLksbCE9eRFFXu5yhTiyeAF61fpdMEmQmn2eRf64i7F9YVVvHi54ItKfFl.0gSzz0cA9Hdc5Rd
 pLKAjRK3EMP.VJVQD5EVgSDHrgRBkoOa9mflwObUHgbqO4o7AttqCS6MlDn8ZbpwYIwEcj901Bel
 D07k30IDBWaqjQAcCHV2iv3TMqMoWNpF0x5H5CWyQNXAfW1d35FMnMwDHVH4iUs8UgzHuTAKpz13
 ZkCNSlDyhzO4tmlMOjPImk6_w0eT9eL1Bgv.UTS8Gr2nUKMHpVpuupXhpSVpR9fEyT2_0yY1JZ8k
 EU1xP2uklY8DE165YBUyYF83jHQf3aZV2.zy6s3ZcaoK.IP5KMfpz6vRpeqSz79K3aGCokG2jpRS
 D0fa4RjCH8eurFAsRhJbn2KP3R9Rw41LH3xbW6cWHWVUH6vUHH7fXH4YD.BD1hWti612M5OLGFq0
 xuebN6bwTCCVcgtJlvGoeuSQLXxSkrNdsdpPaCjSozqrn2GPKtfN3UukdXekHXdiIhGEPgg9T2vp
 BzYXddgbK6KXjgXIAGWBlSrYGDmBbHADy6Ex3aIxWwTPAeBLEgWe5o5NfPCJqf3gU9cBk7ioEUJZ
 xYpzKLrTS4eiPb337d9ICE.ix6JzuZ3u70E3lgub2fsRwf2Ll86C0IB4nQj2WoTKK7STTdM3OXfT
 9VYvvdt6ynrnjlHuPjZX516f7DH4WmggZvJKF4NuJ7ZooYJ.YgjKb4DkZZFG5mc4yj6raAm1W9VA
 JdA4GcnARwnmNgfrZqNtVznYR8dT7lr5tlyY0k0l4s7gsS0yjM8KM6Tvar8Z8yjZdwyUdc7g4LRQ
 PC1kgMLU0sojm11XDWWmnL0PWmOzYCH5EjK.sin8OjzqdMtvMMbJMUS8G6OwpAyRKWhkOcJsQGzo
 wtyKUBlYEgWXWKqZNtg_kSBx8tYsXBlVOuBhMGkmQsNlt_2D5UGa7MslSFrTW
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 03:15:56 +0000
Received: by hermes--production-bf1-5458f64d4-tg4jl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4b5a8f5d8f9e5f2e2ee2eb1adb9d9270;
          Sun, 25 Dec 2022 03:15:55 +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.300.101.1.3\))
Subject: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware
Message-Id: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
Date: Sat, 24 Dec 2022 19:15:43 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: <9C037D3F-A440-4708-993D-117F313691BB.ref@yahoo.com>
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.87)[-0.867];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]
X-Rspamd-Queue-Id: 4NfmJt4tzPz3w13
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
BUS_PASS_ORDER_MIDDLE and the like and they allow being
sure that the brcm,bcm2835-dma related setup has been done
before any use of it is made, despite the order in the
Device Tree: use an earlier pass for brcm,bcm2835-dma
related attach. This avoids the kernel crashing during
boot.

The example context used below has: serial console with
USB3 SSD boot media (not requiring a usb_pgood_delay
setting), booting a stable/13. The RPI4B is a C0T one (no
3 GiByte limitation, for example: the PCIe wrapper logic
has been corrected).

stable/13's source code changes ( similarly for
releng/13.1 ):

diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
index cab8639bb607..d8b49acfe332 100644
--- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
@@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
=20
 static devclass_t bcm_dma_devclass;
=20
-DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, 0, =
0);
+EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
+    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
 MODULE_VERSION(bcm_dma, 1);


For reference, a 13S snapshot with my kernel build replacing
the snapshot's kernel, was booted with:

# strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 11:09:05
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Oct 26 2022
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee (clean)

There are new things present that FreeBSD reports
but ignores, producing messages like:

clk_fixed4:  disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.
device_attach: clk_fixed4 attach returned 6

over and over during part of the boot. It seems to
retry as it goes and thus produce so many messages.

There was also:

fb0:  on simplebus0
fb0: changing fb bpp from 0 to 24
mbox0: mbox response error
fb0: bcm2835_mbox_fb_init failed, err=3D5
device_attach: fb0 attach returned 6

genet0 is working.

I've not checked if the microsd card slot can be used.

I used the normal FreeBSD U-Boot since I was not booting
the NVM3 media that requires extra time (usb_pgood_delay
would be assigned in my own U-Boot builds).

For reference, I used my typical sort of config.txt :

# more /boot/msdos/config.txt
[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

#
[all]
#
# Local addition that avoids USB3 SSD boot failures that look like:
#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port =
?
initial_turbo=3D60
# U-Boot that has, for example, a built-in usb_pgood_delay assignment
# for a media specific issue added:
#kernel=3Du-boot.bin.2022.10.arm64
#
# Local additions:
enable_uart=3D1
uart_2ndstage=3D1
dtdebug=3D1
disable_commandline_tags=3D1
disable_overscan=3D1
#gpu_mem_1024=3D32
#
#program_usb_boot_mode=3D1
#program_usb_boot_timeout=3D1

# Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
# That would make the below inappropriate for such contexts.
[pi4]
# Locally avoid hdmi_safe's dislay scaling:
hdmi_safe=3D0
#
armstub=3Darmstub8-gic.bin
#
# Local additions:
over_voltage=3D6
arm_freq=3D2000
sdram_freq_min=3D3200
force_turbo=3D1
#
#total_mem=3D1024
#total_mem=3D991
[all]

[pi3]=20
armstub=3Darmstub8.bin
dtoverlay=3Dpwm
audio_pwm_mode=3D0
[all]


As for main [so: 14], the devclass_t use is gone, thus
the source code changes are:

diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
index 5f9ecb0b7981..83c4c493a66b 100644
--- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
@@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
        sizeof(struct bcm_dma_softc),
 };
=20
-DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
+EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
+    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
 MODULE_VERSION(bcm_dma, 1);


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 25 04:10:26 2022
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 4NfnX22YQVz1J6r5
	for ; Sun, 25 Dec 2022 04:10:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d])
	(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 4NfnX057gHz42PF
	for ; Sun, 25 Dec 2022 04:10:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=z+5uvfCG;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52d) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ed1-x52d.google.com with SMTP id m19so12032588edj.8
        for ; Sat, 24 Dec 2022 20:10:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=2vdKjnd8T8QpQexBVJxmn6wKH5ypH9R4mfEitCQ1+7Y=;
        b=z+5uvfCGnOOOyZvWKbmoDYgJ9V7tzECOqRkeRIMVJkSK5DunztrECW1ayd3c+aLVNJ
         TZIxQ5MpaV4yHoKN/+3VO+0Ta4SwDCWMlY3WzE5urE2/mv+19DGCwo2N9zDj4oYcPA3y
         542cfoibpDS0AllgrlpOhpYFUW2/7vAnsbcBmP0EDl7LN4y5vo/KmS5umAUVi7WHNKPz
         IBe/u/j48S4bTxCB7Tl1femr9yyPisYKApTDPmyIk6wPPrYTtCIA2dVxUS1T1Os9gwsD
         X80vAOkkLihr3iBVSQGFDzGt2UOlNLyKcsqwF1J0Aw/1m3rLMF5BBGs0BR1Yb0yQcmGI
         Js5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=2vdKjnd8T8QpQexBVJxmn6wKH5ypH9R4mfEitCQ1+7Y=;
        b=M124wYzid+KhIB3ZSmbvZTlI7uoL/PCPrg9J0vshVvxo7Os14p54KNIHy1Hq2cPaeD
         txUjtXkWFTnUyFApl5fOSKThBPbJ9t3/kbJWacFiawu6xFids+QFJiZydLXNuMTt9uHp
         wrGQQRVZNlcIwcww3WUdt+D92uNXCTKKXcQ56mpUCqfz+Oj52er9DqZh32DGb/p98bAD
         aPYRQ2ZRZjsPbGGJnFBH2DjjWMQxwB0RMZI1Edx4cNF+9wp25Jb7xZBM8eKkOPjYlhd7
         9LAsdO4Hz1eyoIr6Hisgbkbc7EDqaPemYbzd8nJlEKv/gLQ2sl7Dcn2q8VYUdlgtWLSb
         KQ8Q==
X-Gm-Message-State: AFqh2koWCwAZv+auoav4g8t7+urVDJ7JK9Nq8A+VB77Dt0xvTI23Fv5O
	iTWbtmmQ1GsQ5IY8LXQBbC5rKW44WlcRgqLQY5HC9Q==
X-Google-Smtp-Source: AMrXdXt2r6I5dfoDUfBOuMD+Mdwj+soKe8eAvRstgsEDztxc1DXbSrIWW6TX1Q+VcGEOu2Qj/ZrnOeyxhIznG+RqJY4=
X-Received: by 2002:a05:6402:d55:b0:482:ca5f:17ff with SMTP id
 ec21-20020a0564020d5500b00482ca5f17ffmr535018edb.136.1671941437851; Sat, 24
 Dec 2022 20:10:37 -0800 (PST)
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: Sat, 24 Dec 2022 21:10:26 -0700
Message-ID: 
Subject: Re: Still did not succeed to boot on Lenovo Yoga C630
To: hiroo.ono+freebsd@gmail.com
Cc: Mark Millard , freebsd-arm@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000007d1f2f05f09f33c0"
X-Spamd-Result: default: False [-2.96 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.96)[-0.960];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TAGGED_RCPT(0.00)[freebsd];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NfnX057gHz42PF
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007d1f2f05f09f33c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 24, 2022 at 7:55 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=
=94=9F) <
hiroo.ono+freebsd@gmail.com> wrote:

> Equivalent change by Allan Jude is under review.
> https://reviews.freebsd.org/D37766


Yea, this just changes the heap we use to be code pages, not data pages...
But the loader allocates its pages for the kernel, etc in copy.c. I'm not
surprised
this didn't work.

I have already tried this change, but it did not succeeded for me.
> https://reviews.freebsd.org/D37765


Yea, this looks somewhat like what you shared with me :)

I wonder if it's worth climbing the hill to get -target
aarch64-unknown-uefi working for clang and fixing our build to use it...
The current pecoff header stuff is a bit hackish, as this issue is pointing
out...

Warner


>
> 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:18 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) :
> >
> > Sorry again.
> > The patch is needed for
> > * stand/efi/loader/arch/arm64/start.S
> > * stand/efi/loader/arch/arm64/ldscript.arm64
> > * stand/efi/loader/Makefile
> >
> > I forgot the last one. I remade the patch for three.
> >
> > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:11 Hiroo Ono (=E5=B0=
=8F=E9=87=8E=E5=AF=9B=E7=94=9F) :
> > >
> > > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:35 Hiroo Ono (=E5=
=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) :
> > > >
> > > > > I run other arm64 machines w/o issue with the current code.
> > > >
> > > > Yes, Qualcomm's snapdragon is weird. I saw Linux people complain
> about
> > > > it somewhere... Wanted to know  before I bought this Yoga C630.
> > > >
> > > > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner Losh :
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=
=AF=9B=E7=94=9F) <
> hiroo.ono+freebsd@gmail.com> wrote:
> > > > >>
> > > > >> The current status of FreeBSD 14-current on Lenovo Yoga C630 is
> as follows:
> > > > >>
> > > > >>  1) Merging from OpenBSD's loader code made the loader boot apar=
t
> from
> > > > >> 3 points (#2 to 4 ).
> > > > >>  2) when comconsole->c_init() runs the 2nd time, it seems to
> freeze.
> > > > >> (might be C630 specific)
> > > > >>  3) SetVirtualAddressMap() in efi_do_vmap() freezes. (might also
> > > > >> affect other snapdragon systems like Microsoft Arm Developer Kit=
)
> > > > >>  4) The kernel is kicked but does not start.
> > > > >>
> > > > >> 1) is quite straightforward. What needs to be changed is
> > > > >> stand/efi/loader/arch/arm64/start.S.
> > > > >
> > > > >
> > > > > Can you share what needs to be done? To my eye, we don't need any
> changes, so it would be good to know what you've had to do exactly.
> > > >
> > > > Attached is the diff to start.S. There are 3 points.
> > > > 1) The loader has to be aligned to 4kb.
> > > > 2) Proper characteristic value should be in the PE header.
> > > > 3) .text and .data segment have to be separate.
> > > >
> > > > It is from OpenBSD:
> > > >
> https://github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efiboot/s=
tart.S
> > >
> > > Sorry patch to ldscript.arm64 was missing.
> > > I am going to test your serial patch now.
> > >
> > >
> > > > >> For 2), I do not know what to do. Currently, I commented out
> > > > >> comconsole from struct console *consoles[] in
> stand/efi/loader/conf.c
> > > > >> as a workaround. Maybe, I should write a fault handler that help=
s
> > > > >> returning from the fault.
> > > > >
> > > > >
> > > > > There were problems with this with HyperV on aarch64 too.
> > > > >
> > > > > Something like
> > > > > diff --git a/stand/efi/loader/efiserialio.c
> b/stand/efi/loader/efiserialio.c
> > > > > index 8b3f8e83e0b3..54ee39096685 100644
> > > > > --- a/stand/efi/loader/efiserialio.c
> > > > > +++ b/stand/efi/loader/efiserialio.c
> > > > > @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> > > > >                 if (comc_port =3D=3D NULL)
> > > > >                         return;
> > > > >         }
> > > > > -       comc_port->baudrate =3D COMSPEED;
> > > > > +       comc_port->baudrate =3D 0;
> > > > >         comc_port->ioaddr =3D 0;                  /* default port=
 */
> > > > > -       comc_port->databits =3D 8;                /* 8,n,1 */
> > > > > -       comc_port->parity =3D NoParity;           /* 8,n,1 */
> > > > > -       comc_port->stopbits =3D OneStopBit;       /* 8,n,1 */
> > > > > +       comc_port->databits =3D 0;                /* 8,n,1 */
> > > > > +       comc_port->parity =3D 0;          /* 8,n,1 */
> > > > > +       comc_port->stopbits =3D 0;        /* 8,n,1 */
> > > > >         comc_port->ignore_cd =3D 1;               /* ignore cd */
> > > > >         comc_port->rtsdtr_off =3D 0;              /* rts-dtr is o=
n */
> > > > >         comc_port->sio =3D NULL;
> > > > >
> > > > > was needed.  Possibly the following would be better:
> > > > >
> > > > > diff --git a/stand/efi/loader/efiserialio.c
> b/stand/efi/loader/efiserialio.c
> > > > > index 8b3f8e83e0b3..54ee39096685 100644
> > > > > --- a/stand/efi/loader/efiserialio.c
> > > > > +++ b/stand/efi/loader/efiserialio.c
> > > > > @@ -494,8 +494,7 @@ comc_setup(void)
> > > > >                 return (false);
> > > > >
> > > > >         status =3D comc_port->sio->SetAttributes(comc_port->sio,
> > > > > -           comc_port->baudrate, 0, 0, comc_port->parity,
> > > > > -           comc_port->databits, comc_port->stopbits);
> > > > > +           0, 0, 0, 0, 0, 0);
> > > > >         if (EFI_ERROR(status))
> > > > >                 return (false);
> > > > >
>

--0000000000007d1f2f05f09f33c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Dec 24, 2022 at 7:55 PM Hiroo=
 Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Equivalent change by Allan=
 Jude is under review.

https://reviews.freebsd.org/D37766

=

Yea, this just changes the heap we use to be code pages, not data page=
s...=C2=A0
But the loader allocates its pages for the kernel, etc=
 in copy.c. I'm not surprised
this didn't work.


I have already tried this change, but it did not succeeded for me.

https://reviews.freebsd.org/D37765

=

Yea, this looks somewhat like what=C2=A0you shared with me :)

I wonder if it's worth climbing the hill to get -targe=
t aarch64-unknown-uefi working for clang and fixing our build to use it... =
The current pecoff header stuff is a bit hackish, as this issue is pointing=
 out...

Warner
=C2=A0


2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:18 Hiroo Ono (=E5=B0=8F=
=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:

>

> Sorry again.

> The patch is needed for

> * stand/efi/loader/arch/arm64/start.S

> * stand/efi/loader/arch/arm64/ldscript.arm64

> * stand/efi/loader/Makefile

>

> I forgot the last one. I remade the patch for three.

>

> 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 22:11 Hiroo Ono (=E5=B0=
=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:

> >

> > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:35 Hiroo Ono (=
=E5=B0=8F=E9=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com>:

> > >

> > > > I run other arm64 machines w/o issue with the current c=
ode.

> > >

> > > Yes, Qualcomm's snapdragon is weird. I saw Linux people =
complain about

> > > it somewhere... Wanted to know=C2=A0 before I bought this Yo=
ga C630.

> > >

> > > 2022=E5=B9=B412=E6=9C=8824=E6=97=A5(=E5=9C=9F) 10:03 Warner =
Losh <imp@bsdimp.com=
>:

> > > >

> > > >

> > > >

> > > > On Fri, Dec 23, 2022 at 5:49 PM Hiroo Ono (=E5=B0=8F=E9=
=87=8E=E5=AF=9B=E7=94=9F) <hiroo.ono+freebsd@gmail.com> wrote:

> > > >>

> > > >> The current status of FreeBSD 14-current on Lenovo =
Yoga C630 is as follows:

> > > >>

> > > >>=C2=A0 1) Merging from OpenBSD's loader code mad=
e the loader boot apart from

> > > >> 3 points (#2 to 4 ).

> > > >>=C2=A0 2) when comconsole->c_init() runs the 2nd =
time, it seems to freeze.

> > > >> (might be C630 specific)

> > > >>=C2=A0 3) SetVirtualAddressMap() in efi_do_vmap() fr=
eezes. (might also

> > > >> affect other snapdragon systems like Microsoft Arm =
Developer Kit)

> > > >>=C2=A0 4) The kernel is kicked but does not start.
> > > >>

> > > >> 1) is quite straightforward. What needs to be chang=
ed is

> > > >> stand/efi/loader/arch/arm64/start.S.

> > > >

> > > >

> > > > Can you share what needs to be done? To my eye, we don&=
#39;t need any changes, so it would be good to know what you've had to =
do exactly.

> > >

> > > Attached is the diff to start.S. There are 3 points.

> > > 1) The loader has to be aligned to 4kb.

> > > 2) Proper characteristic value should be in the PE header.
> > > 3) .text and .data segment have to be separate.

> > >

> > > It is from OpenBSD:

> > > https:=
//github.com/openbsd/src/blob/master/sys/arch/arm64/stand/efiboot/start.S

> >

> > Sorry patch to ldscript.arm64 was missing.

> > I am going to test your serial patch now.

> >

> >

> > > >> For 2), I do not know what to do. Currently, I comm=
ented out

> > > >> comconsole from struct console *consoles[] in stand=
/efi/loader/conf.c

> > > >> as a workaround. Maybe, I should write a fault hand=
ler that helps

> > > >> returning from the fault.

> > > >

> > > >

> > > > There were problems with this with HyperV on aarch64 to=
o.

> > > >

> > > > Something like

> > > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi=
/loader/efiserialio.c

> > > > index 8b3f8e83e0b3..54ee39096685 100644

> > > > --- a/stand/efi/loader/efiserialio.c

> > > > +++ b/stand/efi/loader/efiserialio.c

> > > > @@ -261,11 +261,11 @@ comc_probe(struct console *sc)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0if (comc_port =3D=3D NULL)

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->baudrate =3D =
COMSPEED;

> > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->baudrate =3D =
0;

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->ioaddr =
=3D 0;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* def=
ault port */

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->databits =3D =
8;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,1 */

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->parity =3D No=
Parity;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->stopbits =3D =
OneStopBit;=C2=A0 =C2=A0 =C2=A0 =C2=A0/* 8,n,1 */

> > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->databits =3D =
0;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,1 */

> > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->parity =3D 0;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,1 */

> > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->stopbits =3D =
0;=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 8,n,1 */

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->ignore_c=
d =3D 1;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* ignore cd=
 */

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->rtsdtr_o=
ff =3D 0;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* rts-dtr is on =
*/

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->sio =3D =
NULL;

> > > >

> > > > was needed.=C2=A0 Possibly the following would be bette=
r:

> > > >

> > > > diff --git a/stand/efi/loader/efiserialio.c b/stand/efi=
/loader/efiserialio.c

> > > > index 8b3f8e83e0b3..54ee39096685 100644

> > > > --- a/stand/efi/loader/efiserialio.c

> > > > +++ b/stand/efi/loader/efiserialio.c

> > > > @@ -494,8 +494,7 @@ comc_setup(void)

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0return (false);

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0status =3D comc_port-&=
gt;sio->SetAttributes(comc_port->sio,

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->=
;baudrate, 0, 0, comc_port->parity,

> > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comc_port->=
;databits, comc_port->stopbits);

> > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00, 0, 0, 0, 0=
, 0);

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (EFI_ERROR(status))=


> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0return (false);

> > > >




--0000000000007d1f2f05f09f33c0--

From nobody Sun Dec 25 04:14:57 2022
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 4NfndJ1XWtz1J7Pb
	for ; Sun, 25 Dec 2022 04:15:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4NfndH0Lqgz43KN
	for ; Sun, 25 Dec 2022 04:15:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=qrjLbKr1;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 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=1671941712; bh=cnuXyIKry6xsDPTIF6+oVzjtVld3LFbL2E4lnkU+iu8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=qrjLbKr1RbTmKrzB3F5YvDg7YH7vQVLYBdc/6C0TIyYBCpWZOlwzxZqbFzmtTWOvambbwTN9teNNRVZtDtxa5OEQHyKs+dNhXNff2El44mRnOtST/HwlWoav5iagnp9P48yKlHkzvdS8krZjMrG2n3MxbGK2aUsH0PlENL6k3lUlKxpPdj4qObyk6PX/tXAyj/q7nq8D81BhVKlWrJncoBkArPs3RW3BsNJhQaU+J2AwLxiai/EAE8PlENt27dE79BGXGAWjjXtwTAFXty/2Iv+vxWZitUPbMxuEhJQSX2j4PfegONGj8w/2nzyrpigJ1dgeJT4xAF8H5US1daLymA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671941712; bh=ma8Bq8qpTyser0NriqPuJvnxEsztYypyGgL5hLZls3r=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CTBqQKFpLPmj6laeMa6QdRmn9lH3u/JmKuAs9n7MQpwDd/CZr+mPLONhrufw4ZxVYYLfulAmrHixHkGRbciFpykd2k0VKTJlxrQjryNp/gNDKVcA6hNXl1OSgGDQjEf/sbPn9KbK3YvEjW3AcOa4wNRq9STbSIm/QyQkwGKZFB9hHofHG+pBNamYU5nZTz1PAI0dCK1HP7psaq0mb4SNkj5uLs3XrzInXX7yaNVkmAwKea4vBC++p42Anks5vlUhS7GUrhPbW0L/wCPGco/H9UxTKaAWDzgeLL43+Ta6QpUqFcOrADd7cKZFRVmMKa2bNEeJ/0uI7e7GCdQW3VrDwg==
X-YMail-OSG: r0VnUpAVM1mASvevjjQj4cWc4Um386zx3vvfLAKtme2hxsJIorojOTg77iPLCC4
 5QcDGlXw_68iY6h99AnKyMve80tS.yIAJF9nz9iATINlxQXkiLnbBTjWWpHNHA3_PodOo5aFJ8HT
 QjYWvhytW2653Vw5EitKl09PrZbsnQP2Kom83i9JmfTYLwllJmN.SVV3ObFPhRL1lCf5Y_a.bKky
 zynFdYscbQ2.q1Hg3bBGme75xrw_Prg0YmOjMI_DIo0rTckiam9ombdENu9Ku95by9f6Z19Q3Uag
 .6wovNXLxMXQb6SP6TzYhOSzRFZgFzIOyaRq7iQpIu4uQUOi2Pk8RSAB0vNGHO9Qw5QzF5iMxPB8
 DeegT8KSYsEwEZb.snCM6LijJ7jGfxVB17oA1we05F1nqnyfVLNRTHDqi6R7Xiay_9_Vfe.C5vFP
 oiHEcbXi1f0.GkeFRk8Yi4GBWsCzxBqDeEU987mQNAIkxsQccTg8N1V_vd9zLScQZt.jSHdKRKsD
 mlRWwV63ZoAs7d_MHxi1VJN22T81KmO6yV13HmWAA17L6swNaiXkmCapbNvUS2VnhOkQycVT3NwV
 eIoLKCFA5itrlLVG1xiTjLmLFqP0r4r5rattI0fO0NO7a2DZ9MYI3rt5QT4rdCsxynq6TSl6846G
 482UQXFUM2Ecw_6MoScbDVfLGWYuswAV6gTMmxaS07BjfbC0TWGyTL8W4WGFHqQwlFkIHrB0Xak1
 9hoWJqfsfqGrqDGi.u_7XOFLRSpIO.WKJu6ThNQ4Ht._txP8dgT4PQ1spgH0t8Cddzl8rXbvjywW
 E9tquJQg2aiV9eWazklNVoSUsBy0BUzZfnnUH7x4BjegGoZo6DZcxpqqhWcTTUpcgiBEVQHcimKy
 R_pKYTFgtzezL_WPT7HRJnH0WakckEWJRVLPnANEUr20pvp2LxaTsgpjQq8vwimBEd42KhSA1uTK
 vF7R6.pfBGNlylwZ1xG9RGB6J9.S2iOzXmvWL_K_R659QmF1E9Ll_qHAjWoMI88sUxF.sWt1jgzG
 cms8yD0rh58bG8KZwjsFqNyDJRMdXy9wS4RrD2wMsgRNKACyIlTmmUiZ6UDWTOIKS.YEZno2NGcV
 ifkmPzwe_KEJldZ8AAfpAhVhoitPNrurl1lPM1TxK__CqlUJpe4FhwJb0EwdWe5cfnF2pp2pwutG
 4xroeQC3skqj8orFwBtQXwAVgrrdhMqPGaSH6Yw_VwxCGhwNsaOsYIBeOd4Yw4s0D_NNpvMgjbMb
 Qklq7TDiYi6S4VinDzRFscBxDoiGqvS1x0COnJrWXLRiVQBwGN.dTOUaxyYqb98xyj4zUwq19Wke
 sppxOgqOLHL5.T0VgJp4l90j1RvoWXDafJqrqliVSKDOBNWFnte3I8blYCp5VRLO3M7dYGgkF0Sa
 9yxvwS9FbvaFz_grP7qIAvhda8dCcm1j01fQTwCdOgBFfPG672EwMd.7l38AYo3pJkSQPfsUdQku
 179k3UUXMXT.V.8xKY8j5uTORV.LylWCvjBbGulxnetkDBkY6WMNPtjibNglliKOjsh8Cpwo8JOc
 sbtz_YMYAmNtwTQmvm21Ne3vki1Cj8SoVM06Z.UE5e7JyaCJzAKhrT.xYfeTklZQKQ8OV3fQpkg3
 5ANuoybw5XYHpYV03nWNjfBs4_hmFiXcp63ThuUNjhci.zVi99nsgO09rsa14pz53E8OfUO0llpo
 ZTkRjLSoxsc_CXDzM_LMzEP8cDHcmJC9I46NK90gtXc..iRNJeJoVVeadOq9cKZOAxqxj2H0kKAK
 k_qATO7WFELi1mAzcajTkjq2P8n.EsWmmawg2gfyqCr7mQoqxTRkJ1wn6DBzJFOprN6z7vsvNB_.
 LGiIZ.7A4KT03Qg3hmhQ43Q8z7r8wfSPsX5rnaDEkpBVaZ9VFOrW9lln.RWnMEPep0bZdnaf3UVC
 cVrXLiZjvRUNZH1NF7k6FGbiBbwQ.ZCJzCvZ2XyIioT6YpjqEsYEMT2MhWHDpOzh4M1KN_mna.Hi
 _VdZmnsFoc7iGwFTB4R7qlawMlyOmueDlNtHQmzx82Rxh9cO3F4GfqqNYyIH4mWZdep8QXv_Sq2n
 6HOZbfkJpnTeRjFtMkja25WyrgXXPp8aIlxUzvDFZ7u3abiq7imhQ.rciq.638013AqQ5jLJ2o4_
 1UFbUK4UxZwLPm6iVZN2m8YGG5AqR1uF8ZVyTqvvaX7AKhTwykTTPapafg9RRIusyxMUtBsnbkHU
 zj3DSD2DOCZu8UOxuW2dzc2SEyJ4PVmVNeeV5cdttE5dFhYIDlHXdQoL3JpSX
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 04:15:12 +0000
Received: by hermes--production-ne1-7b69748c4d-xhmc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10683588f6f521ac42872efcd0c24e05;
          Sun, 25 Dec 2022 04:15:09 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sat, 24 Dec 2022 20:14:57 -0800
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
To: freebsd-arm 
In-Reply-To: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
Message-Id: <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-3.46 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.96)[-0.957];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]
X-Rspamd-Queue-Id: 4NfndH0Lqgz43KN
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Dec 24, 2022, at 19:15, Mark Millard  wrote:

> I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
> BUS_PASS_ORDER_MIDDLE and the like and they allow being
> sure that the brcm,bcm2835-dma related setup has been done
> before any use of it is made, despite the order in the
> Device Tree: use an earlier pass for brcm,bcm2835-dma
> related attach. This avoids the kernel crashing during
> boot.
>=20
> The example context used below has: serial console with
> USB3 SSD boot media (not requiring a usb_pgood_delay
> setting), booting a stable/13. The RPI4B is a C0T one (no
> 3 GiByte limitation, for example: the PCIe wrapper logic
> has been corrected).
>=20
> stable/13's source code changes ( similarly for
> releng/13.1 ):
>=20
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index cab8639bb607..d8b49acfe332 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>=20
> static devclass_t bcm_dma_devclass;
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
> +    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
> MODULE_VERSION(bcm_dma, 1);
>=20
>=20
> For reference, a 13S snapshot with my kernel build replacing
> the snapshot's kernel, was booted with:
>=20
> # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
> VC_BUILD_ID_USER: dom
> VC_BUILD_ID_TIME: 11:09:05
> VC_BUILD_ID_VARIANT: start
> VC_BUILD_ID_TIME: Oct 26 2022
> VC_BUILD_ID_BRANCH: bcm2711_2
> VC_BUILD_ID_HOSTNAME: buildbot
> VC_BUILD_ID_PLATFORM: raspberrypi_linux
> VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee (clean)
>=20
> There are new things present that FreeBSD reports
> but ignores, producing messages like:
>=20
> clk_fixed4:  disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.
> device_attach: clk_fixed4 attach returned 6
>=20
> over and over during part of the boot. It seems to
> retry as it goes and thus produce so many messages.
>=20
> There was also:
>=20
> fb0:  on simplebus0
> fb0: changing fb bpp from 0 to 24
> mbox0: mbox response error
> fb0: bcm2835_mbox_fb_init failed, err=3D5
> device_attach: fb0 attach returned 6
>=20
> genet0 is working.
>=20
> I've not checked if the microsd card slot can be used.
>=20
> I used the normal FreeBSD U-Boot since I was not booting
> the NVM3 media that requires extra time (usb_pgood_delay
> would be assigned in my own U-Boot builds).
>=20
> For reference, I used my typical sort of config.txt :
>=20
> # more /boot/msdos/config.txt
> [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
>=20
> [pi4]
> hdmi_safe=3D1
> armstub=3Darmstub8-gic.bin
>=20
> #
> [all]
> #
> # Local addition that avoids USB3 SSD boot failures that look like:
> #   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
> initial_turbo=3D60
> # U-Boot that has, for example, a built-in usb_pgood_delay assignment
> # for a media specific issue added:
> #kernel=3Du-boot.bin.2022.10.arm64
> #
> # Local additions:
> enable_uart=3D1
> uart_2ndstage=3D1
> dtdebug=3D1
> disable_commandline_tags=3D1
> disable_overscan=3D1
> #gpu_mem_1024=3D32
> #
> #program_usb_boot_mode=3D1
> #program_usb_boot_timeout=3D1
>=20
> # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
> # That would make the below inappropriate for such contexts.
> [pi4]
> # Locally avoid hdmi_safe's dislay scaling:
> hdmi_safe=3D0
> #
> armstub=3Darmstub8-gic.bin
> #
> # Local additions:
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> force_turbo=3D1
> #
> #total_mem=3D1024
> #total_mem=3D991
> [all]
>=20
> [pi3]=20
> armstub=3Darmstub8.bin
> dtoverlay=3Dpwm
> audio_pwm_mode=3D0
> [all]
>=20
>=20
> As for main [so: 14], the devclass_t use is gone, thus
> the source code changes are:
>=20
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index 5f9ecb0b7981..83c4c493a66b 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>        sizeof(struct bcm_dma_softc),
> };
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
> +    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
> MODULE_VERSION(bcm_dma, 1);
>=20
>=20

I should note that the above is not likely to be
the most appropriate in detail. The boot reports:

# dmesg -a | grep bcm_dma0
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
bcm_dma0: cannot allocate interrupt
device_attach: bcm_dma0 attach returned 6
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
bcm_dma0: cannot allocate interrupt
device_attach: bcm_dma0 attach returned 6
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
bcm_dma0: cannot allocate interrupt
device_attach: bcm_dma0 attach returned 6
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
bcm_dma0: cannot allocate interrupt
device_attach: bcm_dma0 attach returned 6
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0

where that last (working) one has the message
context:

gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0

So something involving BUS_PASS_INTERRUPT or later
(but before, say, BUS_PASS_SUPPORTDEV) may be more
appropriate. Possibly:

BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE

(so after gic0).


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 25 10:43:03 2022
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 4NfyDs4FF4z1HZBf
	for ; Sun, 25 Dec 2022 10:43:09 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Received: from nmtao202.oxsus-vadesecure.net (mta-232b.oxsus-vadesecure.net [15.204.3.7])
	(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 4NfyDr3qD0z3qh7
	for ; Sun, 25 Dec 2022 10:43:08 +0000 (UTC)
	(envelope-from fred@thegalacticzoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=VtX3jAz1;
	spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.7 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com;
	dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com
DKIM-Signature: v=1; a=rsa-sha256; bh=eS8SAr8bRqur3dgsPY0eWewE3pkikINFJNepn2
 oNaX4=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to:
 subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:
 in-reply-to:references:list-id:list-help:list-unsubscribe:
 list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1;
 t=1671964986; x=1672569786; b=VtX3jAz1LmtZhyDRXUoctalMlwkLX9CzPSlyfWxNh
 jsPss3TcN172nhuUsu3OA45DuAKA/3ShC0QR5037pxana3QvUIwQkcmGdAsynUhrxbqEw+e
 eahmpWr2kM6jm0z78GEJF0g3nDNG5KlC6pgC5qQQbLizpud6WgCbZeLQhtSU17mxPI+0mAX
 i7PnZkebJo1Ge63slbVXrJGCfiDrvZGFtiWMQbr/PMkO4fdPzsL66yRFxCnop3W4ItMspbH
 rgASkuRTBhO9HUttlz2EEL20nj5KScDDNF/WZ5a54kmEZBauc3qWQG03v6Kh73Lr0FWfKuO
 VLg5dqJPfhsbwsUbw==
Received: from proxy-18.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149])
 by oxsus2nmtao02p.internal.vadesecure.com with ngmta
 id e99854de-1734034bbb20fe93; Sun, 25 Dec 2022 10:43:06 +0000
Message-ID: <5fbe3c21-8e74-c9bb-f489-d74e5bc55e9b@thegalacticzoo.com>
Date: Sun, 25 Dec 2022 02:43:03 -0800
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.2.2
Content-Language: en-US
To: freebsd-arm@freebsd.org
From: Fred Finster 
Subject: I Posted first Review about file scandir.c /usr/src/lib/libc/gen
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine];
	R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1];
	R_SPF_ALLOW(-0.20)[+ip4:15.204.3.7];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NfyDr3qD0z3qh7
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

https://reviews.freebsd.org/rG27e60668bf29

Related files:

/usr/local/include/dirent.h

/usr/local/include/cdefs.h

/usr/src/lib/libc/gen/scandir.c   versionsort  is located inside a 
#ifndef  scandir_b  #endif section.   What happens if I_AM_SCANDIR_B  is 
DEFINED? No versionsort() function is created ?

Line #163   #ifndef I_AM_SCANDIR_B

Line #195-200  int versionsort()

Line #209  #endif


/usr/ports/x11/libinput    'make install clean' breaks because of error: 
   versionsort  undefined


This all happened, when  I used  pkg update ; pkg upgrade  on FreeBSD 
14.0-CURRENT  from my Raspberry Pi 4B.

Now running  'startx'  prints an XFCE4 desktop, but  file 
libinput.so.10.13.0 errored out when loading, because of missing 
versionsort symbol undefined

So my usb keyboard and usb mouse no longer work.  No input is coming in. 
   Is anybody using Desktop Environments like MATE or XFCE4 and have  
this same problem of no keyboard or mouse input? Can you update your 
ports for the ARM64 aarch64 FreeBSD.  portsnap fetch update  ;  cd 
/usr/ports/x11/libinput;  make install clean Does that make run without 
errors?


nm -D /usr/local/lib/libinput.so.10     Do you find a symbol 
versionsort  undefined ? Capitol U

                  U versionsort




Quelrond Q is running Desktop Environment Enlightenment 
https://lists.freebsd.org/archives/freebsd-arm/2022-December/002089.html

Hello,

Enlightenment installed from package worked perfectly on RPi4 with 4GB de RAM on FreeBSD 13.

Peter

Are others available to test this out on your system?

URL reference:

https://ghostbsd-arm64.blogspot.com/2022/11/libinput-module-error-fbsd17-not-found.html




-- 
Fred  Finster
fred@thegalacticzoo.com
+1 971-718-9144
https://GhostBSD-ARM64.blogspot.com
https://ghostbsd.org


From nobody Sun Dec 25 16:37:52 2022
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 4Ng66M6h0mz20k64
	for ; Sun, 25 Dec 2022 16:38:03 +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 4Ng66L4z34z4X5W
	for ; Sun, 25 Dec 2022 16:38:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=gtNjS7xP;
	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=1671986281; bh=o2eqYsnqE3ib3Jxd0JHm6phoNUmIbd8f9PV0LDCWbQA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=gtNjS7xPNIa3TeAl0Rqos2ewT7xhBMvuLYrnyJRsKFOZhYVbETmKLkWxALFmMLS08ffQ++NGaz0kCEV0LLlulO6FeWNWMJ/By/+e/R416xRzkNd1/WpNJT34umAG23X5c3MdKFvz1wxkKMZGghdV7ajOqdd4u6a/JcaKWrMBkFEukV8fFjdDMGAEjaaTn53jfEKudzuEF5ghwUX/yY5y9VieCKH8mMdtBnfrC3fn4EBn74Jaznx9DfUisVEoKBAuKzbKTwb1/AW/0i4+u8XnhVviy27l8cAtf+vM+KRHcqbtfuGqsS8HWov3FWw1j+JCtvtZw+E5W+gvKCYRL+J+5w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671986281; bh=oU0axPVQusdTiiYuyvAD6PvCELptszkPiTI2LOG70N7=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=o5DLsVWKob5RH4GCS89FogwxlFW8j1GksFLYFjD/WjNde5LLDD3cvK52LZTnJpv0tgwlYY+pM+gqVnsmEhr9D7OdQT+YQgsMzMMuZIHPSr/c9x4eT6+ld9HdDlKYcEPcjy1mlPrz5DAqy96//DZCrLuxCiSZTQbKm9ueGEkjuB80VTB5MD975Sd3EdPBOT2V0Ubq8VfzgDicTK7QOY/MrQyIiPzslAZJc4dGfDtZg5+mRkKedEtgC2Z2n9DBSC6SG2/ERHFG7QwaBNc8aJbssXLRnKn6mS0wL34Up57BruTjKodvtFncrFZeeTFxQh7ircA3ObF1KcBGKIooCznFLQ==
X-YMail-OSG: JmTvFAMVM1lMHDAHi4ygvpOUH2ZxNjDK3HGOGi0MMlIvL8f2_jvoR880IySEuCa
 wAiGKVQAnq.B4vX__rpCHLlvlhNlW8aRi3FHsy0EpueYApTz6uAFPo_tr2Fb59ZOTMfE_k0Ef1Ue
 qQHyt.S.sQa8ax79F6z_bPiUVEY41jBolahLhjkd5aFfV2bC2yzLbqo.jdZnOEH3L.R1ClBepw_N
 KxFbXofNdzPhKljkwIXTabAP94_c7TMvBddiN2J_vpmQAQ4.ltnFG0JP7zHDNFfWMufgQWShP8Ea
 hBZtLD6oQMbxpOCpI00xo5qKVAlzrgagZoUKrX0pgZ6nF9cThf_BmUUg9w9LYS9l5UeZHZYfbh7V
 mX_ceqps.FsEhhb16yKeo1pGzsjGIasGgM0q0.EiQcC7UyFSb2ZvFYfRsrdgPH_.zcRvpJuxOGw0
 IKgMERM5hMVBHykxBjg1C1VY2c5eQcNVs2wr3q17k94DWGbKGISnPykr3Z0PFxTRoKkurC.WgoZ2
 ZOCGFPPrvWfi10yQKE0PQfC17TAvkdpR8Z3u7GJl8dDGxBsOepuzxNNk6gCxKUNj5hZ6LUM0OY4k
 1Z76gJmVOajJ.HXKCfjAKEFEEQQCuF_6jO_.9PXdEAiHqbXeRydTpwHge1ye_iKjcvXNYMdWkDdr
 iCblfIgBxE04aPjthbY8h2t_.Js2NOOQ7mJEkVr4VjB0Lo.Ncg5WIiDB_PyTK_ZfkRpgEk._HyA.
 xyuGFW.U.hza_NQjYjsPacXtSktdOb96UcJsQP6pYUObZxb3bJfKILr_nYwnIOlfV_XgO05lmMWs
 XJLH7XHSHQfHvNJaoQX0KaDpGQclVgr9ktCyD.afV2d40FHFObFilJ9mMw.JzgW6x05nJ5LmxXON
 41fKeVhMIJ8kHzpYFkE0HNPQ20KaECy6xIhGvKaznirBM9Ic37HaA07WMBAnZwz.hDQRtDkXzXBa
 sjiWT2n..HjPVVvJTkRl5Bd.mv.vn1Xcbf5gHQOHZVDayk8gm95a8ziEv60LpAyT3wtb5ijKWi4p
 91Z4QwjlcJBQ.IT4oUfCuio09TgQgQDbcR.uvrLH.t.2gIG.3OWai5yYvpHfy6Q6bfNk97jPmhVo
 LsOqK.Hdl6XlIXJzcQD6tlsj0NvNxvpmoqZdb4dkDg5.k1tBHsjpq8YbDi8swgerJ4rKvhYYnxcQ
 7fkQViOIdBZMBKjDmA.wgJXo86lkGj6V_fUCkan0kPVcPl8NZBVby17F8PhKNw_7zYd.d_ZVI9AK
 Fpr9zxmKwgAv86N3MoMyfKqgfQeUbrKJ3kPkX5r77bU90qpNLKYAuSWjVMq9X6O2Yh_Nshv1ZAdg
 V3V0WXr4kTijw6vImKGfijVfM2.oddHkzb9qWwLkvq09Eyks27uZU2L40ZijZOhBAXYe6UFamB6J
 NIZFcP_XPGcax5ieCD5U4wKeoy748bkb8Yvjync5gFvWcVvP3NIP6ZqRJIj4gVqCBVXjqO6UI4Vj
 yF9ZVrBR6zNaJEpIHrQi_K3mkX9IG3N9FvCkamZPDaN0_tD7e1G44XFyZ9VztCS4gcr_hSsohvzf
 5bZ6vithaKquMt6k.pcHXO0kPjo2I5D1.suvf3LPO9eEyEfgVJQcCrO_.cDhgr8ZzT4ieFa__N2C
 qm3maUWfA24S8LQitsmhMuccZIp_cTwFuAgh.f00W7TsJNLYSY7pC9aI9OKjWL0CkppFCqzLfD2h
 nlrQ4eR6NuhXVpZD6afDCopdUZp0OOFiIop5VbmQmjsb3RKNm072iLq7f61VCV5rGUz0dFbRrj8F
 UTFxZ6zDXFrROq.sbQhSWdrfPAR2aK3NYeR_vS_X5sKFJYI9p4qewsWLPKJ.pZUApKiOb4ibQSmo
 hSIp_LYBqLKd6qKMTXZnBb4zqPhNg4GHCAn0ASG6btn7h3KJNKDIl5252GZeg4SoUU2pyUe2uY68
 YojoDw0ZGwAbzcnp0k0orIQnWma_KAluIsYiICLMw.z.9D_JsRMKpsFkqR6fWklEoHFSQlfgMnkl
 wL9O6Pf9Gzp09gOCtbKNf4NXhF5Kh3qLcuZihXs66EEeV5SCQoFNsMUXH6tVaMm_oaLABtDm0YOt
 K_YX2AEG5_0izEddksTDRHI4bYtDM4i_DUXCLGJCLe2_DH9P7yMzF14ZTI5nlyzvttHke10GxWd4
 lnHZMELxCE3G6ncedSduBOAScyNdZIKQmkYLbfX8dcfJb_lhnDG.24ybUJPzUugWirQGLzsjP903
 yZoiHkT9j2O0mh.wMRjARWuohdlejpAOP10KNdDnT57ApTs.cIt6Wu1YwSfz6
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 16:38:01 +0000
Received: by hermes--production-bf1-5458f64d4-kkg2s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ae584a7e4e7adf60e9c2eec3aacf3ce4;
          Sun, 25 Dec 2022 16:37:56 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sun, 25 Dec 2022 08:37:52 -0800
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
To: freebsd-arm 
In-Reply-To: <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.979];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Ng66L4z34z4X5W
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Dec 24, 2022, at 20:14, Mark Millard  wrote:

> On Dec 24, 2022, at 19:15, Mark Millard  wrote:
>=20
>> I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
>> BUS_PASS_ORDER_MIDDLE and the like and they allow being
>> sure that the brcm,bcm2835-dma related setup has been done
>> before any use of it is made, despite the order in the
>> Device Tree: use an earlier pass for brcm,bcm2835-dma
>> related attach. This avoids the kernel crashing during
>> boot.
>>=20
>> The example context used below has: serial console with
>> USB3 SSD boot media (not requiring a usb_pgood_delay
>> setting), booting a stable/13. The RPI4B is a C0T one (no
>> 3 GiByte limitation, for example: the PCIe wrapper logic
>> has been corrected).
>>=20
>> stable/13's source code changes ( similarly for
>> releng/13.1 ):
>>=20
>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> index cab8639bb607..d8b49acfe332 100644
>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>=20
>> static devclass_t bcm_dma_devclass;
>>=20
>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>> +    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>> MODULE_VERSION(bcm_dma, 1);
>>=20
>>=20
>> For reference, a 13S snapshot with my kernel build replacing
>> the snapshot's kernel, was booted with:
>>=20
>> # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
>> VC_BUILD_ID_USER: dom
>> VC_BUILD_ID_TIME: 11:09:05
>> VC_BUILD_ID_VARIANT: start
>> VC_BUILD_ID_TIME: Oct 26 2022
>> VC_BUILD_ID_BRANCH: bcm2711_2
>> VC_BUILD_ID_HOSTNAME: buildbot
>> VC_BUILD_ID_PLATFORM: raspberrypi_linux
>> VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee (clean)
>>=20
>> There are new things present that FreeBSD reports
>> but ignores, producing messages like:
>>=20
>> clk_fixed4:  disabled on ofwbus0
>> clk_fixed4: Cannot FDT parameters.
>> device_attach: clk_fixed4 attach returned 6
>>=20
>> over and over during part of the boot. It seems to
>> retry as it goes and thus produce so many messages.
>>=20
>> There was also:
>>=20
>> fb0:  on simplebus0
>> fb0: changing fb bpp from 0 to 24
>> mbox0: mbox response error
>> fb0: bcm2835_mbox_fb_init failed, err=3D5
>> device_attach: fb0 attach returned 6
>>=20
>> genet0 is working.
>>=20
>> I've not checked if the microsd card slot can be used.
>>=20
>> I used the normal FreeBSD U-Boot since I was not booting
>> the NVM3 media that requires extra time (usb_pgood_delay
>> would be assigned in my own U-Boot builds).
>>=20
>> For reference, I used my typical sort of config.txt :
>>=20
>> # more /boot/msdos/config.txt
>> [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
>>=20
>> [pi4]
>> hdmi_safe=3D1
>> armstub=3Darmstub8-gic.bin
>>=20
>> #
>> [all]
>> #
>> # Local addition that avoids USB3 SSD boot failures that look like:
>> #   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
>> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
>> initial_turbo=3D60
>> # U-Boot that has, for example, a built-in usb_pgood_delay assignment
>> # for a media specific issue added:
>> #kernel=3Du-boot.bin.2022.10.arm64
>> #
>> # Local additions:
>> enable_uart=3D1
>> uart_2ndstage=3D1
>> dtdebug=3D1
>> disable_commandline_tags=3D1
>> disable_overscan=3D1
>> #gpu_mem_1024=3D32
>> #
>> #program_usb_boot_mode=3D1
>> #program_usb_boot_timeout=3D1
>>=20
>> # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
>> # That would make the below inappropriate for such contexts.
>> [pi4]
>> # Locally avoid hdmi_safe's dislay scaling:
>> hdmi_safe=3D0
>> #
>> armstub=3Darmstub8-gic.bin
>> #
>> # Local additions:
>> over_voltage=3D6
>> arm_freq=3D2000
>> sdram_freq_min=3D3200
>> force_turbo=3D1
>> #
>> #total_mem=3D1024
>> #total_mem=3D991
>> [all]
>>=20
>> [pi3]=20
>> armstub=3Darmstub8.bin
>> dtoverlay=3Dpwm
>> audio_pwm_mode=3D0
>> [all]
>>=20
>>=20
>> As for main [so: 14], the devclass_t use is gone, thus
>> the source code changes are:
>>=20
>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> index 5f9ecb0b7981..83c4c493a66b 100644
>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>       sizeof(struct bcm_dma_softc),
>> };
>>=20
>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>> +    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>> MODULE_VERSION(bcm_dma, 1);
>>=20
>>=20
>=20
> I should note that the above is not likely to be
> the most appropriate in detail. The boot reports:
>=20
> # dmesg -a | grep bcm_dma0
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
> bcm_dma0: cannot allocate interrupt
> device_attach: bcm_dma0 attach returned 6
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
> bcm_dma0: cannot allocate interrupt
> device_attach: bcm_dma0 attach returned 6
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
> bcm_dma0: cannot allocate interrupt
> device_attach: bcm_dma0 attach returned 6
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
> bcm_dma0: cannot allocate interrupt
> device_attach: bcm_dma0 attach returned 6
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>=20
> where that last (working) one has the message
> context:
>=20
> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>=20
> So something involving BUS_PASS_INTERRUPT or later
> (but before, say, BUS_PASS_SUPPORTDEV) may be more
> appropriate. Possibly:
>=20
> BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE
>=20
> (so after gic0).
>=20
>=20

So, I'm now using . . .
(leading whitespace possibly not accurately preserved)


stable/13's source code changes are ( similarly for
releng/13.1 ):

# git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
index cab8639bb607..6d521d6dcace 100644
--- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
@@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
 =20
  static devclass_t bcm_dma_devclass;
 =20
-DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, 0, =
0);
+EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
+    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
  MODULE_VERSION(bcm_dma, 1);


main's [so: 14's] source code changes are:

# git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
index 5f9ecb0b7981..d901447df1e9 100644
--- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
+++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
@@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
         sizeof(struct bcm_dma_softc),
  };
 =20
-DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
+EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
+    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
  MODULE_VERSION(bcm_dma, 1);

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 25 21:00:43 2022
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 4NgCxS1kLWz1HZ6l
	for ; Sun, 25 Dec 2022 21:00:44 +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 4NgCxR6KNJz3sr4
	for ; Sun, 25 Dec 2022 21:00:43 +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=1672002043;
	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=/vc+W4aWbY2jyQ6XQvhSH84VDizrmGrMQLkHY4a4nX4=;
	b=vgX4JD5lsxOnek+1nfGmP6bxrDLAcA0d0/P1f8ERrs0mGMPm/qd/PtKIA5iPxq9Fi6dEPJ
	9g9AqVMbeAZVWPD7aGVimqVagAxzzMm666j/ZQCmNt2cPZz2Uu/X7rc28O+htqWRIx8sda
	Vf05ubghzEBVp/fqvRlw/Wj/aWu1BujJ/74c2O6Iy6vNlfnqLYAsQffN0uR93O3035qgpK
	6akWZeIIwom0ikDNdN8eTwDF61AvgtDZISvFY7NtDD7P2e2xqhgQeLGSZxSRcJZKaYUL7+
	WN+YJyqc5pMs18236lFYnPccEQh9JFMiXMzp61gORyDAD5+6ADf77zers1zFNA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672002043; a=rsa-sha256; cv=none;
	b=uX7+qI3nxUSUyu75tO/2UyUZxU0qHDmsplzTCmr9qRrSuHle/fMLA++k4KE34Q7pn76wMi
	cjB/s8FELwwH543ZYgUgqZ+ga4Ytm45JvMdpQAZ422KD9nKCgzL+9QsTdm4ABlhoBFUAaH
	KoG138usZtoPtCIjL6sRl0rhhVzSxGQNuNHiqHQxQRjYL5FN8PQcKa+0nfrsI2vPua8kvo
	11kIemKZ+6c3Jjbpy8sg9or8F7xdy1JvEwoBxew5tVbm8FMA1CSsx4fvQ4ux6yWp2E4pvS
	euRkCbdSQ4NUQofS67iobC2WP1eJInllLQuRdTVLz3TN5R+e96HX7GIYTy2F4Q==
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 4NgCxR4kFBz15bH
	for ; Sun, 25 Dec 2022 21:00:43 +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 2BPL0h8I004961
	for ; Sun, 25 Dec 2022 21:00:43 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BPL0hIr004960
	for freebsd-arm@FreeBSD.org; Sun, 25 Dec 2022 21:00:43 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202212252100.2BPL0hIr004960@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, 25 Dec 2022 21:00:43 +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="16720020431.DEdb1.729"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16720020431.DEdb1.729
Date: Sun, 25 Dec 2022 21:00:43 +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.

--16720020431.DEdb1.729
Date: Sun, 25 Dec 2022 21:00:43 +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.


--16720020431.DEdb1.729--

From nobody Sun Dec 25 23:28:38 2022
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 4NgHDP5K2Xz1Lg89
	for ; Sun, 25 Dec 2022 23:28:53 +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 4NgHDN2yWWz4KsN
	for ; Sun, 25 Dec 2022 23:28:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=COZDMyCn;
	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=1672010930; bh=Em+YSFOu6p5hjWga+Uh4r29GSZUyiZBRHSD+YZLCyT4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=COZDMyCnCRC4UIlCP1gN+otoWjIWrjPWNJjtJhSTU7e0HY9ciWbjTVvNzzC1gDLFbeHljeP5IGVEQy1G46iwJX/HTnjxBlvHK3NWIra2V/1zDxYdhVIEdlIwWwDLqQFuKtClZOO9y2Aj28UaMdyM4Op3Gt8tehd1MCHIrtVavYmQXMMO0SDTWNi+ghojvwPtfzF9+vrEtOVTfmeY4x/2WL4gMldS+Ty4dOKZnPww2KBHPE2Umq3ohQgk1Vn8hCs4iCLdFggLbxslQEbBFHm5KmcqN/Qq3YRSyHGJlR3S1kW+tPvcU+ctYvs+fnGPKeclX22dTNGb7e/VhjJtRqR5Bw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672010930; bh=zjeXx8uT6lE2tGK3r/oUdTIpw/YDo0lfdaqtEo+r+oK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GW+bJrEWG9b4xuCne4peqF8UbUZ9H2dmNjkMKGfSxHohvmoeIQaYzvzJisIf+NXaFjXBq8y3NF/jsG11hkuXWKkGSp8696076vyuzei1oK4ACcKqaZIjaTBe48uDk89QKc0+YgJAmxM84WOFwL76rOxjYtlkcgTORN6ZcsEMOnqMcBY02eU86oL2gBqfYMw/sOt+0jqToEm7u+AhO739xpBZByRdYDL05UtxqGRQjkRgUYb05oPzzoPDb1XhZEhJmNN0Lnau3qhReYBL+KtYj2BNkZ9MCXzIKb3ZkyQ2/+nqI1tpGPL0+frnqxXXYx0JzL1iFXv8w/6PgqH+xXPlgQ==
X-YMail-OSG: 3NXPc3YVM1nABw_9kLWOgmto7gmUroKXTNREAM3AvgYhp1VbcRtVQLT98zEnfg4
 4jUukz00DYX8zc0pFbQnwWT12OfrC8x0nraXgAeuVUFCz.AtJFMqmU8ARICaBnZTWYGFixvjUm4G
 7OOehqe7apDXqMKqJs.9ZMRrs17wherAFHk_SWhqquQ3AmtyJKIoULKTrseKClvKJz42Do.p_SpY
 ZbbCSkxqK0wOKB9vn_GHa.UEbADfvccfpY_Q.BSgYR0weySrm.CYICUO8ujOVeVpPlS6Sq7qW_00
 o_5gtJK3hbOwcXl6S5JZRBDbFfGLgEfS_Mzwt.C2YY.Ov.dDj7.3Odok9.q1lcvlz.0KAIR8W056
 zx47lyAEksvRav4EUiac_broRNAVq.DBp0vcmVZCV.3fuQ7pqM3BLaHg3LlQLw64LJfORoK559cO
 7xvkR02CO.OCJfK8RXY.R6HfXmIA6sQKdkAQHkrFIm5h42uuZfa42w8ZEvbFzP3i0wBNkEVFnrLi
 UKYJRsh37bSgOD8U.qpRxnubbwWjxy1fRxRqNnSMe0vEla_FYXtXF1alpM1ru8Rqe7qOvDFuqMkr
 4MuQlQm2ux6LkKe9ogR03W1Ka.GrZ5MmRiufYEd6jEBfVgFBYwWgdzxMq4CaxDNirk1lK_ecE9mV
 fS9xT3PzLps_nnkjBUY40XovrCsPZvBkBa5t650BS1WRTaEto7lVUp56.G.Asg77gFylmg9NYmCE
 VQn8ecPXPPPGeK3TGlxSVzHcEaYe_BA0VIq.LOwsWM6NLxT9zO.7x9FDuX9vYXyx7gk7VfjSiPyG
 aVbnN99Bm2qPreKbH55aqkDSSTzw.e2xBaj5uyyzE2WNxluyCy4yOzfNO1iKpxZlhM1N5x0GpKwO
 vQa4tRQ_C0Re6k9N5QWPz.w2EdiqzukTkRKWaxVVEidBUKgIKFpbAcmxA2JdUrxyNM.Jxex0_1TX
 l.HeHCs24LRSJ6ypVn1cCuuD5D8XB1CHwwBTfDMvZK55WVuJqECw4I4n4Okb23q210pENR.kYTah
 Ze.2a0QUxwfaHLepBoAMm6f4MjXxppxbbEFAbP6FEVeCU9bnFLKD4hNKYm1R0XKAugKbn6mKAIiI
 zbAEdztz4H71s5OajfZ2CNoo4lrx7bcESc1TfjwQvTxlw20kaRm29jIaLeLPyDLQfCcDaR9XVJu4
 5J0GjQ_q18bU13q6GMcojvo3WUsZGHCXH0uNnTnIfwkZJ8CG2O020OWx5ZgbeW3mYloOXB_P76cL
 _Hkxyi.WwJz7UTN8eMN_YOIEl2vLuzCL1ESKx47I36JWTa9JXZdM19iNiIswLfXDWobxsDjZEmuu
 q_h3yW4YrR6wghz_acw9K_lm8Ft7clRCRwv0lKXstSiI2H6gMy8bxy_hCINVmlW1Z5TqzYJTyJdd
 cn5rjQSwhbSuUL8Wj4pZ0TdgzjQ.O9txl_MdKhexepKQBf2dzzjtKqHDGJtw8_dKXYFs1fU1btfw
 XzD0d9xMgZLBGfANIl0KNIViuwPmk7rUSb6haTdQlIdFXMTnbwZd5xruvm5e2NHHgcNvENjIAGSe
 AU2rhSFVdG4DPCVzfwIHxH_CBrVmpA8my4vDz37EW1WlLi.W.sTYWWXGyGxZ9y.CokyrSFXX_eBO
 gNq.JaENypL_qCp.BWf3Fv2N8uJP6drJsoepGj.B4W1lFV_0Me02.TcbX1Kc88XsG1rL.4._EBWj
 vhkuk.6MMH0j1ILh44KFEifgpkv9IsPvUWFbZulTnzud0e7tG.eVnuGVxTKFgnw72DPCld4hRXxv
 _tYVtxbUflZ5DwsZHf1QULzOPVeS6LrVpVwRj8Jg6avnxLBLznQx1pLVgVbIBEMiUI4ovEL36vW0
 rDPaGVGGtn7Ba56d9fOaKB0UaBlux03WyyX7rtFF4X8NQCHFqpu_ghkpExWAdUmUpZVmRn1QwKW1
 QDaYsgNV7oucoeS9CWGcqBJ1lZlZ268oCtpsTcIsHnSH51QCKvNwejlR8nsP_fs3J7_twdUFXayo
 M5.G29xf5ZkzzF5HFLSdySkrETYXdOKM6Ysk3G7uiBnY7wmSgdGQlhGA8njaN9_mBcGar5uXTwYo
 ALrFIoWl5F0IvQYs04J9fHU_t4Smxx6ylTHK1w76_Z4fabMm_lUY79.KAQakRRq.adM_d27rjgIK
 iGYYRa5fXXU800IDlK9yoWFjGT7WC_G_8L2DY8g6M8WqIcIY8PEldPcWQ5jrz18PODBGByvQ4vax
 DaYHx6UP7VUs9gdQ0L8Giuowjk5LCRS0oooub8Q.Fu_Ofb4krAaXnUQbIncL3vANpNU3wot8L2ek
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 23:28:50 +0000
Received: by hermes--production-gq1-d898c4779-wpm62 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51a9335efac85295b6afc7ab901b2c11;
          Sun, 25 Dec 2022 23:28:49 +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.300.101.1.3\))
Subject: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
Message-Id: 
Date: Sun, 25 Dec 2022 15:28:38 -0800
Cc: freebsd-arm 
To: freebsd-current 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NgHDN2yWWz4KsN
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

=46rom the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
system:

. . .
Starting devd.
genet0: link state changed to UP
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Starting dhclient.
. . .

This seems to be from /etc/devd/hyperv.conf :

notify 10 {
        match "system"          "ETHERNET";
        match "type"            "IFATTACH";
        action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
};

For reference:

# ls -Tla /usr/libexec/hyperv/
total 8
drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..

I do not know if the error might have lead to skipping some
other activities or not.

Note:

This is from a test where I'd 1st side stepped a syntax problem
in /etc/rc.d/growfs in the snapshot to try to see if the growfs
otherwise worked.

# uname -apKU  # long output line split for reability
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64 aarch64 1400076 1400076

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Dec 25 23:55:30 2022
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 4NgHqM6qBYz1Lksg
	for ; Sun, 25 Dec 2022 23:55:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4NgHqM4VJ2z4PsZ
	for ; Sun, 25 Dec 2022 23:55:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x52f.google.com with SMTP id b88so6646848edf.6
        for ; Sun, 25 Dec 2022 15:55:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ddq7biMjkEHbjOp/GIOt3/6DEeCXpL+Kl8dJdU9OZ2w=;
        b=gFnVHtY6EQRvgQNSmGCzsV/zZKsi9U2kBulTG7V7Y82bB2Vzzv/RjNT6xbM/I5CjpD
         Wya5+jXaSdjmyHpSlV/erT70UmfiQN0dYNhcPzTPV9I5PsWAIGOh2RobrlqPSW70/+ti
         G1tecD7K2icqIUW7MeZHxV7TNza2OS/c6IQ4lpYSo7g4ROKeBsjHhO6tTttP+rFDPysm
         /yZ+TGuRZHtbMaLCIATq/oC7FILmMLCdPG+8+bWURYf7/BwPNbIJxDwgrx3Q60qCTIiW
         fCv6ZD0AWOREwF4KcRxOrrKZsoOmrXFD38+8g/p6LmijrCpazeJuVJAFmPLmjmFZbARV
         IsQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=ddq7biMjkEHbjOp/GIOt3/6DEeCXpL+Kl8dJdU9OZ2w=;
        b=OmN4gWl/3IwBqmJ5b2tcCfXbEZXME/R/DpkPfoxT8RDkM1vv5mT1Oi9vMVXLxV31Ar
         TLbBoMis3/ZGpUNJqg0xl1fWEe4M/2uazqkOWGJrpZ0qqbiiGohCjpUDNaLJRiuskTP3
         KuDFmnQ4NvuWfNOuoExpKM5OTRpp3yvTBeCsCT3IHSWkDndgMB+wy4H4cYiWcshUVqLU
         FPe/+wHRPwxa61hoBMVCwHP1t73U0YaqszxtYO2kcPqBrIKPUHk/Hxv75jvDSx0V9iJP
         L+2kC5lrxUKmyDB4RYWJROgtII0tateZzS2wxCkPS9odCGPUtx0B3sLt4SVoGl4eQEZD
         ONXA==
X-Gm-Message-State: AFqh2kp8zp8Cn3lMTkXnTS9U3S//dc3wpYwCp1mGtQba8DukHv/R6RY7
	463fZgLtICM8gtedQ/mVxKodr4OGhNoziv+jqRaFhw==
X-Google-Smtp-Source: AMrXdXv2QLNj++QRh+gYtQhGNy1sMjIFJB+7IZyROcf7mEU2qB+dwiNBvRZbKcUJ1PRjDLzARsFhYW+DYj8tWlLT0w0=
X-Received: by 2002:a05:6402:3205:b0:469:f59f:352e with SMTP id
 g5-20020a056402320500b00469f59f352emr1321136eda.241.1672012541474; Sun, 25
 Dec 2022 15:55:41 -0800 (PST)
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: Sun, 25 Dec 2022 16:55:30 -0700
Message-ID: 
Subject: Re: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
To: Mark Millard 
Cc: freebsd-current , freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000984fc105f0afc157"
X-Rspamd-Queue-Id: 4NgHqM4VJ2z4PsZ
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000984fc105f0afc157
Content-Type: text/plain; charset="UTF-8"

Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus
if MACHINE_ARCH == "amd64" somewhere.

Warner

On Sun, Dec 25, 2022, 4:28 PM Mark Millard  wrote:

> From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>
> . . .
> Starting devd.
> genet0: link state changed to UP
> sh: /usr/libexec/hyperv/hyperv_vfattach: not found
> Starting dhclient.
> . . .
>
> This seems to be from /etc/devd/hyperv.conf :
>
> notify 10 {
>         match "system"          "ETHERNET";
>         match "type"            "IFATTACH";
>         action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
> };
>
> For reference:
>
> # ls -Tla /usr/libexec/hyperv/
> total 8
> drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
> drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..
>
> I do not know if the error might have lead to skipping some
> other activities or not.
>
> Note:
>
> This is from a test where I'd 1st side stepped a syntax problem
> in /etc/rc.d/growfs in the snapshot to try to see if the growfs
> otherwise worked.
>
> # uname -apKU  # long output line split for reability
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64 aarch64 1400076 1400076
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--000000000000984fc105f0afc157
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Most likely MK_HYPERV is defaulting to no for aarch64? Or=
 there is a bogus if MACHINE_ARCH =3D=3D "amd64" somewhere.

Warner

On Sun, Dec 25, 2022, 4=
:28 PM Mark Millard <marklmi@yahoo.=
com> wrote:
From the Dec 24 =
main [so: 14] snaphot for an aarch64 RPi*

system:



. . .

Starting devd.

genet0: link state changed to UP

sh: /usr/libexec/hyperv/hyperv_vfattach: not found

Starting dhclient.

. . .



This seems to be from /etc/devd/hyperv.conf :



notify 10 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 match "system"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "ETHERNET";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 match "type"=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "IFATTACH";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 action "/usr/libexec/hyperv/hyperv_vfattac=
h $subsystem 0";

};



For reference:



# ls -Tla /usr/libexec/hyperv/

total 8

drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A0512 Dec 24 06:30:06 2=
022 .

drwxr-xr-x=C2=A0 10 root=C2=A0 wheel=C2=A0 1536 Dec 24 06:49:40 2022 ..



I do not know if the error might have lead to skipping some

other activities or not.



Note:



This is from a test where I'd 1st side stepped a syntax problem

in /etc/rc.d/growfs in the snapshot to try to see if the growfs

otherwise worked.



# uname -apKU=C2=A0 # long output line split for reability

FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0

main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022

root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC

arm64 aarch64 1400076 1400076



=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--000000000000984fc105f0afc157--

From nobody Mon Dec 26 01:23:22 2022
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 4NgKmr41cpz1HGF7
	for ; Mon, 26 Dec 2022 01:23:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4NgKmr17wvz3M77
	for ; Mon, 26 Dec 2022 01:23:40 +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=1672017818; bh=Ae2waz8ZF+dQ/6qylM/+6wPQxnmrpn0i1GFMGQLH1n8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p46ekyY5ZaoWNfhquVE6+GEQzrhiVrn2NKEPeug5l5TqhHts8S9m7yftOiloLtVj2YYOI65CgQ18oUl2Naony3C2E8mVIiNCdkY56wdKhpv67jRYKxYMjB53AxWudiEmQzhgP2y8KNOTMjBc0k5UPkIwhWRV8hIXSnfcheo05D8HDaiqJqIagHFw87LOitz7EDBj+ayqNeG7YDQk1vmc/hiOOQoLiIEU63pCVenEbWw2UWIQSaaZOa1d9Yi7FU3H+z8yEP4ox3LKrZpa131xqNPO1Y8wngepxepp+eXZ6/mD8sfH8/hisIBocnmBe88wrJj5atZq4Xt6XBnKDSzNFg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672017818; bh=9XKVhp7MxXzO7Y5pOm6azNyFPycvDIj3mwx4WOUotSA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BQY2yVlga2rkGSnpD+b1/aiYAkRnTPn3dHSyd0GEGVutNlgccqy006TSFgOY3h1B+nWA1YEFywHSX8oaYX4FhZVGenTGBh3lJwwahhLboKLCqh+zZkJc2srZhszuxXPm0wxVr9XBGkp9NAdHyEJLBqP3xhEoOVitykC+5kFC3SWEO9eDy44ht4sCgBJX2jc6WeWYjFCWppk+ll1+/sSB/MMnCydQfv7RceIa7PoyZ3QejAiu1WQpLFE6m2Hp2unE6VGIsWUHlBVWOco/KTIiXhi1AHXhhtzkufHwfyMgU6YsOp/d6X2TatIvmF/umaMVqtFe41w2hOczKOwGkoo+yA==
X-YMail-OSG: PBUQtgcVM1nvhxivt2a93APtatJXG1bnbNSdAVnrLKiZAyVZQaJQfP7nrP8VTuX
 BdpYiCtfJyrd_RvuhWdEHyDygtcXdRnRZeSGQJvhanNpnyordBElS7UjhhHWKxNjN9jpAcjUPejB
 Ly96R0IcwD1RRCTSzNa3CHUk9puqJ5YRVy.uiUVMdZuw13dBdPSnQFvF5jt5F8UtQfPQkXbAJq1d
 pn5ncX85jkI4k85WzU00VtfUb8gw6b53tTykWf7W0r7RGvLejmAqEKY9B_T6AP6jNICE3ZvDIT1k
 JNLD0mRGu7CkpBxZkcznsW_g6eZMSth1vTuiEdxRugTGiXSzMhJXdtJ8QbEzDyUfWrtfdb2APJzK
 8jj_jEejjo4yBQhnQLS1nJt.7QsrokbBO7D8MEltKB3ei7gb2iXe1xNDPXH9l5sTA.mSHKS_vL6t
 FZEGHkP7Gs0G4sowcxLUttIjK__zUTEC890b5JMYvLWL5TDY3ZiKCsR_G76gADmFIDbu5kvBt.rN
 aMtMhTP2ngvtdUnX9ggWiu4uTv3u_XcI4iE9pxOIOek3vRSKNsL7J6v1JwA7U5adXqCM3ZCk6SoR
 RHI8_RlL970eu.kqsmJuJPCpXJuPjTmz7JMEgkLWYTRvLmrXh6ioKF5sQYeXiV0tbrnZkV3aBvdp
 4eeraUg2uX7MFaSjKvnDozEPCc68zWqpAzZe_T6pw._qTZ.eXQF9atGqKg1l7lpCoVbj5tk1zZ4o
 JWBs_M8NaSq5AHc93DddIkzNSF3alLE7KsO00maMeToNrVKBIDZQj_4SqJvB6Tlwyg9_B3NSeIWu
 a0FWvDsv.vpXTW7S0Vgef9lDFigGLsuEmjelPA6.5M4nAXiZziQarpIYtuyUDuooOpSeWxTUCv_4
 5De034Q5r00d7sTNRVYBvg_0yeY8z2VEljH8aYjUNZX4nAPoEHl_u0Cx0efdwh.FwtwxYbSbZ3nc
 AwfSaoeyeRXXBKspv0SxoxZ5R0e4l2US0R0LLfY_VJBXJG0VnKGJpUdfmy8jLC7X1I_mqmUKmD43
 LPodTFKUFPhDinUjRHZ9CRXBNeTxroGiBiABUTVOZKVDflMZr_L0.usNicKdZoKjGpXVujjEQBkF
 elwZvpjOcvlDzWJ7ZT1z.QdEczKRMQ2FqQhYVX6KWqVDrb53lHFYL0qcPLcyjijzDeIt6bwSfM6B
 m64iTXb8riKPhjN..fcMHXbI22ZYNNCtrrSCMbMD8H.2Vht91YOD_atMvZX6T3JIrll2XmHitoi3
 knmz1RBJtMwQg5.do9n.K0LRdX3t4NuNeGXs8yQAk83qs2XRw3Jf7wZiGPh_K3LmNsTZ0dw_oWby
 kTOCpKk59HOQyjxB7_nYSBqZ_1utx0UOOvuVKDB7G6hMP0ncomIX749bfc0ROx3deZpcJizRdFFW
 dsBjWj8l558Tgeehj8DTx4xWkKv8wpAarJ3FT2.aQfAswNQyWn2Tw3fSVxG4ipwV.Kk0PDVsDnEB
 HfnDjRzb.PglETebfuYZvsF8Nu8evhtLkt1nW4Nz2J_7Zzm5nCgMOaFp6CvM0rHq5BiZN9yOf765
 ni6RUWKmVBVxGHIHWIINHnQrGyRgOG2uumAzqAdn3CXEwTcWdHc5398b3KMyhf7xbHIPxd1nFklJ
 N1VEfYADRt6lNv5rOipLILeMRON7w8TinPhWZsC.1lXSioUU9FdXh0EcMH3ga_prvavbIhsbRkZS
 cR5.gy3zXLxI5Wzk.VpKZjn0lAA1S.kZDtBmjqeR18cKTG.csjZlFwWsLxMh.yEBBDk07AgYMCQH
 AodGdcZfo9K4U4zFxoS36HPbYCPtqsAtEmty1qM7JgedqaSXGSauNPvjjEykAA7cPNxJ3ZUJ8Ajl
 IRPTH5RbZgeKnfeSOOW9_OsXnTbggNMSPbS.AdPgIG6PfvAHmGKesk3VevH9uVgKhX6.vQYekC_e
 nf3nBIww2qc1upAQ88H8nyzWC2FC4J9nFsTy0DkFUYZDEoTTEXAdjJBsZ.6OY0onNxWN60zIBU5L
 KF4PGq26vWhLu8ZYSgW0k.tvf5GLqvXM_St0eKAisc0bbncu9rZwFZpHiR9clHBZwon7ieewLiKR
 j8Gx2.fQXarXZUXUD3FArsGxraXs60zh8sIjPynDLQ_yPRmfvVZclTIIpIYWhv8XSr3k2FupehBL
 qX8Xz9EiyRk8mnkhGup.VdV0.CH0sdQ45ePMgy_B0VkthCAAFuGa43Qpi_Jgf3OENeu8XmXI9dmv
 2hvTude5x5qxINT.gsX5YQ6nk4E5CNTi9LkokYpwfNZfjEee6akcb2qFVPDMjVye0IfxKbeVAU58
 A
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Dec 2022 01:23:38 +0000
Received: by hermes--production-gq1-d898c4779-9jfqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e52595520abca9777e47cd8c14d51972;
          Mon, 26 Dec 2022 01:23:33 +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.300.101.1.3\))
Subject: Re: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
From: Mark Millard 
In-Reply-To: 
Date: Sun, 25 Dec 2022 17:23:22 -0800
Cc: freebsd-current ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NgKmr17wvz3M77
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



On Dec 25, 2022, at 15:55, Warner Losh  wrote:

> Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a =
bogus if MACHINE_ARCH =3D=3D "amd64" somewhere.

Well, seems more is missing for aarch64 if devd hyperv is to be enabled:

# grep -r MK_HYPERV /usr/main-src/ | more
/usr/main-src/sbin/devd/Makefile:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/libexec/Makefile.i386:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/libexec/Makefile.amd64:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/usr.sbin/Makefile.amd64:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/usr.sbin/Makefile.i386:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/lib/libc/x86/sys/Makefile.inc:.if ${MACHINE_CPUARCH} =3D=3D =
"amd64" && ${MK_HYPERV} !=3D "no"
/usr/main-src/tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_HYPERV} =
=3D=3D no

(The below is based on cgit.freebsd.org  in =
case my source tree
vintage is problematical.)

There is no libexec/Makefile.aarch64 or libexec/Makefile.arm64 .

For reference, libexec/Makefile.amd64 example:

# $FreeBSD$

.if ${MK_HYPERV} !=3D "no"
SUBDIR+=3D hyperv
.endif


There is a usr.sbin/Makefile.aarch64 but it makes no
mention of hyperv:

# $FreeBSD$

.if ${MK_ACPI} !=3D "no"
SUBDIR+=3D acpi
.endif
SUBDIR+=3D ofwdump


By contrast usr.sbin/Makefile.amd64 (for example) contains:

. . .
.if ${MK_HYPERV} !=3D "no"
SUBDIR+=3D hyperv
.endif
. . .

I do not find an aarch64 equivalent of
lib/libc/x86/sys/Makefile.inc 's:

. . .
.if ${MACHINE_CPUARCH} =3D=3D "amd64" && ${MK_HYPERV} !=3D "no"
CFLAGS+=3D -DWANT_HYPERV
.endif
. . .


> Warner
>=20
> On Sun, Dec 25, 2022, 4:28 PM Mark Millard  wrote:
> =46rom the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>=20
> . . .
> Starting devd.
> genet0: link state changed to UP
> sh: /usr/libexec/hyperv/hyperv_vfattach: not found
> Starting dhclient.
> . . .
>=20
> This seems to be from /etc/devd/hyperv.conf :
>=20
> notify 10 {
>         match "system"          "ETHERNET";
>         match "type"            "IFATTACH";
>         action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
> };
>=20
> For reference:
>=20
> # ls -Tla /usr/libexec/hyperv/
> total 8
> drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
> drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..
>=20
> I do not know if the error might have lead to skipping some
> other activities or not.
>=20
> Note:
>=20
> This is from a test where I'd 1st side stepped a syntax problem
> in /etc/rc.d/growfs in the snapshot to try to see if the growfs
> otherwise worked.
>=20
> # uname -apKU  # long output line split for reability
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
> =
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64 aarch64 1400076 1400076
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 27 03:54:57 2022
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 4Nh15K5j9yz1LgbC
	for ; Tue, 27 Dec 2022 03:55:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4Nh15J3NVvz3nvk
	for ; Tue, 27 Dec 2022 03:55:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=LvWYnPSm;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 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=1672113313; bh=AV4sxJW03eL3GuLcaC48+nZD6+5ZD+LP7e5lJP5YRdU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=LvWYnPSmEpCwqZzvGN/MhfLlbDOtnlNRso5DOnKPV44ie2CcXLuviuVOSLfAhpBs6YL/LK0xFROpx/wBnZ9fJsZ09CPZ3Jr/+2uAsVE3DnOLGMR9dj9TABXorJsfcjOTGt+zx0yjxhTo6PMQxKwAESBbpxE74Z5zKqex5W7LvI62acFhwfnVMhQMaB9xhlHhTxtKXTcC2K0rAQpRPthQ3aEzaRH0vYdOQg0J44Kz4YAYJeNGcsrWjvrOLyCcrU+O5TzDHDbMenX5dPXi8OgU86dxTfPXvO4bb5o7mYmw0A/aNk4xYNn7Lmo6CKjF4CUZwcOZTJIBjYpj1KbSA9HIGg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672113313; bh=H+H3u6TdLkUKTRYKTGSQZqu53t15TpQoYy8zfMxJDay=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KeocbQvY+gN899DxZ5mWvNwuhicDa3sEnvnhPTEr9gzlqC1lglZZ8ZoP5Kzy3qI8+XypgVL/rYQbL3ylARksrGsRamSQh5/g84yfMqDsQqcXSKeLGmsXRo0pxcKbsrztDaVmmUObB/l/1bQSZ0uEowfSw70AHGsUzDhJ/Dscc+13azC9E3Wj6rSMP78OP2NKccMA2QJJ6aSzHurKepcDiU4GX7JrXe5NfFGWKp2JEpuRv1AmGT4alkZJWpKj2K6hZBGhiSQBP8MZ8wxCnA/d9/X12fs7jK5HuKB62e2fVtdxZx0dusol60kkf4gNQqNprkEVMJlkxlH3G+CrwOB6lA==
X-YMail-OSG: H21SoT4VM1mO1rXFmij8Ua_xG6ibk.mDo6uD8W9lzc3AdB.eHebP9vV2K.yY5fC
 V6XUObX5nV514NViq6smZ0aigjD05xulZfWAwxWy84xhK6uXumTZOOoxLvawYoYHQnR0w05X2Aza
 jt_bMYnFu82Uw2bextknGR4sAHEI.QE8Ree6P85i1tZTGnq35YSLZKNVBvFxQ7a86g.SoeneVsK7
 TkchjRrcMRmFqnPsJxaRsi32dzqxUCLmRQawvYlFqhmXFAWsE7bkAHtjRZDkbdwcFQ50VsQLPTDY
 a305fwBP8VLxh8BNAAhVEvxaGcx3j4LvewQuwJgvJucErG6zVWSqgs19odC04yurXe3dwIYtMIq9
 KoaOnU00w5m1y5jLtyRwgJxIdGSef7AFbpocnL11cJzwiL7VndeU.5I6v9cG27ytRBCznAdm3IiM
 hPbPNJ4e0C5EI4tixkWZG_ZCpOiu8VLJNG.mHxMxArrOdtM9bdkln5mEr2aEsx69tI3z1m_ygEmF
 i7Ju9zyvkdu1d5ewjlAVTFdUurIkav6YtfzMoI7HS_VgMO1rt3VlpLglQ8j_af247IRu.OEjuCdz
 obDFBJDXFyaIep8ZA_WaE76ahuriWVS4HBpVsvcHZ95jhT6HbZ5kTwN4UAcjdp5lbnagB9aWpsJ8
 Tm6HUjNz_fNRxi2nGbApJOb49EjsS0wAXiTXfCyHTHX40_vjVM5z1KnKUrpWptAvvTmfStlAFm42
 JhlacDPRZlM0eehlyKlfKksXYlYjgP8.s0sOOeZVHv9LiEo3m4VgK33y9_m4eGi5Q8ZGllJEQfz5
 Qd3XxgJfKAJHX9IJw3bh9mPgyNLWBuyj2cgBFjaTLecKushJA3yXCvJPTVJjh2nW9gXOLaf4iR..
 AjTbsJuJ5vmsXkRUo0DyUfHJJHGgMtH_AP3.9.1Kh9ewpfSX7DcuY9vdHNZ.IOI38ei4FRFpXaed
 qKmVAlntNWaswWdspOiQN8NObJrIBWeoAi83L2QwGtbCrluaREcy5RsBjnRnyfDkYs0VbYtHPgHU
 VBxG_AiKF._Eqx7kCP_1yItjpIcSpvpUAmaLNQBQ_rtTPDwmDx4xFsG82QAymDc0u6XxowoB2dyB
 oLDc1MfkYOTBoXB1I01K2cZ_F8zYvwGd_b7TZrecmZOzDQ9v6lRPhbMrvA4NNdy0Qt1DypFhCiw0
 jOJl4D1qOREyWqyiMHSEZPC2WmctCVUw3MFnG8YSMFDs0DyqHzngVMgYYNq3DPuPBlJyNqTLMgrv
 sDXNGhhmPpHrncjg7nXujsFY12YDNq.Erg0vTqqihtN1dMH8kotZ9.KxLcyIL1sJnE57_dlmjfiF
 B3ZK3VQ58EgLMuR20WJo6S346vRBMsYY8Fqjo_hoDeDPGYEsvjfzBIaXx4mRjjkFXg.iGmm5J_eL
 BC757hKcOJfLJMlywdUgWIZqqlm5G7tIHJdwIBBmfalsOYoIoLYQbLmDTY8oEnyRwHPZi2AmUuVe
 qOPzXzyI2UEDWstPXbTwKmGwOnA6N9atWSU1N1f2CNK.U_vUvz.OAexeGljWSEZiesc6lEV54vnX
 iYbih1UKkWQrqGm96Yc8BuT6JYMHTuY5y1079McgvNIF9qhpvvpYp9xmniFIfm7asGSGuRpbspdB
 1IPpVcpUh8SuWXiUbE.1KFC.0Q8EShiGdgSgAXGW1eORQSk3IbaO9.IcokgGwJv37Ji7S1fNkFW7
 AemtqyiwjlG6WEyB.pJf4hbiZB4dltC4DDWfFGJX6ZA8XGxrxJCji0byCte6pdDSJf1XjgBbyJdd
 uCflGjMEsgoPxug4aZE69qzf71znBh9mzUp.JoR3vZ9uC_skdi_fqmm7sMVLSYilI7hj49phht6.
 6AMK73b.D8oKuVmDssDzrwsL4O4EGvwk9cCv18ETD9Sjd85HJmM0XScF1P5wpXDTuVakAo81IjZK
 7nZbXprScqiqKpu5R1es3WNF._4Uwo9GtKUJVuw7_PYcwok0dv1UmsBbaHrehs.UJ6AOxjEyRrp_
 XsnhV2A0fZCAe0rAfeI91izIvlFMhovcYqvD.q967VX.3GnbYNmpiLQjWEOxFM_ZFepb0FgrFYy8
 N2aTES_SDeFJaDPmU9fz_HL06ogm9hUf2noiFIEFQLl7CCrLpjbRuOmFSAWsZqcCAKwDcwcmvhJZ
 8r2C1YK_bvpaSP7_ZRaleWHGJ63slq99eKmlao9PPT5dBZr7iwcJkjBHYZ8..BP48skh0OKB.EGE
 OLBYx3DD62PNKjAqsjxyg7LUJJIAHRSHM4H_8LaIZ0Qcbd26zesISqvSaaxsG5iCXcNFk3SsXdrZ
 niVIcCh_XsQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 03:55:13 +0000
Received: by hermes--production-bf1-5458f64d4-kkg2s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b27c0c01835962e0954ab5edfe5b1dcb;
          Tue, 27 Dec 2022 03:55:10 +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.300.101.1.3\))
Subject: RE: ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds
 reads (Should  it have been MFC'd?)
Message-Id: 
Date: Mon, 26 Dec 2022 19:54:57 -0800
Cc: freebsd-arm 
To: "jrtc27@freebsd.org" ,
 freebsd-current ,
 FreeBSD-STABLE Mailing List 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
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.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-Rspamd-Queue-Id: 4Nh15J3NVvz3nvk
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Should the following have been MFC'd? (I ran into this while
looking to see why I see a boot message oddity on 13.* that
I do not see on main [so: 14]. There was a time when main
also produced the odd messages. But I'm not  claiming that
this is what makes the difference. The oddity was observed
on aarch64 RPi4B's.)

author Jessica Clarke 2022-01-15 19:03:53 +0000
committer Jessica Clarke 2022-01-15 19:03:53 +0000
commit 4e3a43905e3ff7b9fcf228022f05d636f79c4b42 (patch)
tree b6be66e54604bb2c1fbdfde27bf8a6644e04fd05
parent 3266a0c5d5abe8dd14de8478edec3e878e4a1c0b (diff)
download src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.tar.gz
          src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.zip

ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds reads

We do not include sys/rman.h and so machine/resource.h ends up not being =
included by the time pci_private.h is included. This means PCI_RES_BUS =
is never defined, and so the sc_bus member of pci_softc is not present =
when compiling ofw_pci, resulting in the wrong softc size being passed =
to DEFINE_CLASS_1 and thus any attempts by pci(4) to access that member =
are out-of-bounds reads or writes.

This is pretty fragile; arguably pci_private.h should be including =
sys/rman.h, but this is the minimal needed change to fix the bug whilst =
maintaining the status quo.

Found by: CHERI
Reported by: andrew=20


Diffstat
-rw-r--r-- sys/dev/ofw/ofw_pci.c 1
1 files changed, 1 insertions, 0 deletions

diff --git a/sys/dev/ofw/ofw_pci.c b/sys/dev/ofw/ofw_pci.c
index 7f7aad379ddc..4bd6ccd64420 100644
--- a/sys/dev/ofw/ofw_pci.c
+++ b/sys/dev/ofw/ofw_pci.c
@@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$");
  #include 
  #include 
  #include 
+#include 
 =20
  #include 
  #include 




(Note: leading whitespace might not be preserved.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 27 04:21:27 2022
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 4Nh1gs1VP9z1LlGl
	for ; Tue, 27 Dec 2022 04:21:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4Nh1gr2qVlz3tSY
	for ; Tue, 27 Dec 2022 04:21:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=PyflGyDQ;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 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=1672114902; bh=OO+RdfmwNO2UJG4xMFLyjjw5i+YqSt0w2siKzgQikbU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PyflGyDQ+ahvQo02jGk0PQt3qK8jnm7zEeShiFuVnWcUStfk0ycteKGglKgLpp+FQv/Hfi7zw9btBzzoLqT74/xlGO33w6hyfUy/ODl0dY5q1IyUH5k3wiFVIVlSEB3JTLPF7vtqEb2CDmJN0On1ZJHBusQlszHAxyR5PCsOcwEL5VHqo7fiacSBkiKiY34Lqn/1W6FCEHrRDMepDYLJbhvrzzON9YQj84bg+TS10BV++dqhzDhkgbmYNGph0muIXpoo7geYIxYniAuyRdKdoXtMfVfOU0jZM8JD2r4Xlh1rUzUmXxk7ZFQDFepaSY27TDl8Ne2s5r7R8JXVgRE9Sg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672114902; bh=6OBysDaPFPBYjrnorSerAOcMKScDU2BrWzoy/MPguoi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HeQ73Hev1kKsE3ndFbuLZf3cNRZzDNSxK1NIYTYtMLbQ28odYzfNso6OqeXb43nK7la8Ue8JsVf2PILGYGRos+u6Q3fEIPhp1/fyCkp2LfmLqQSuIs+u8Qgj2ePv1dLMuIhSFsj+HzGMHKnA4i6dxfkt5dQnbt9nfrEDjuhefqwdtgIrg0DSy8zWrqVWdXwx+6FGZNG8PPccyywa/9X9QXwt59d2kS3BMLpm8rUFHp/6Ae7WdthunaWEn/ZtfsFKmoLMXkTeGY23kF9WfD1sDu7Y7A4NQ19sK1P733b3RIPSdFTGjqxAh+3IA0vuMbTls9PvEfz3xa8Z1IPwx3JYGw==
X-YMail-OSG: BT4c6fYVM1mmrJ4mMmrZwMTOiEDN1RBK.gDiDSF2lo5TfDR8RcHMkhr2mzfp148
 xiyvFlFdYLQIPuUzNcOAU6wBGVJEOTJrS8K3LOeUJx5VqOu9DFjWy3fKKtgO8OtZMQFTaDdrvVEt
 gH0A3Rv5VbDRSfmxsQ9nv891xmwaglE96XxVAOSR7Fu1xOnXQGH68L05BCSxB_VrrakPhnDZ_.p6
 r63l6TilNoIItsVw59ZuX4NZVa711dTN6oBvZiR7O55T8SzelS5alaLhOEwXk_3cBxJl2bLNwE.F
 2XvPyI2PzNtJnbNWCaDzsf8Lt5xcX8qnNX850o7eO.cQgceHFhHYpH35QsCCxS3Ld_PoXaH39aUO
 YmdtA_dnmoKjfT6S1HmvoS4vx1xYf8Bt7wOOlPhWp7k9e.k3i0kuD3QA7C.rIdhknJDiGPqI.vT0
 rAFldIADyu3UdaU8TXv6GnxaQA10xSw8NKNwiWOXz3SGgOIEen6WNPzYo8BG8AoQhRux4t4.C9n.
 0v8Fb6X02HZW_5eWUjsUKWoqmS3fzrkEHaAfho72MAh0QUntk_rUfzrq.BIHMMIWnN8TlCcl1QDV
 nnBhXe2I55UGG8kUmVqzFGjYJS1R450t7wmFIJeH3pXiX1uOVlvtylkrLVe5osZXdFdLo2LNRBkf
 t.RnKHNMeruflYGx9Ds7EygeFhhu0EyDyZTVSejvD9b1LU7lcRMyMjaZB4wfLG2zoQP4m616VZtN
 kKSWzSqjJGR3iNbYqXyqS.miFZiDfBy4cnTsXzbul8e3NdAAl.5IL_0PKPd6e3hrn7Hr42x1cD8R
 ipYgGpdX.iKSq9goe116EDsIXm643EfXbw8CN3.yjh0j9B_4kajWprVXZSMU1aoqOcqk5mtTI_Zm
 zv5LBDB_MMjuug1FY8Vqfblkd2BuU6FZSOkxfPhFLvzhOAjNmAX4OWkFIkHjhGMo923FwVJoOXDm
 ScVAZ0spv8UjkglIWKWW11te9Hx69xZ1Sc7kXKYIkfXYVidfWiBhDfwJX7vgbyDLO4vwEGnA1bkK
 Dp3KYdRXvfRbKXRyobPgdJHk4g6VVg_dA13a8fsLX46cIgrcXPXPNFnd2_Ag9DGeLcZ2uaOd1iLS
 pNBfBb67pbZrSu.4rY24f5zH6N0Fvwqh1SEkzTxV1MqZVCmN6GEQn0OTzc2PDLL4Erz7L.ge.zkT
 us.CUtaffIGQntkGdXIAAJcRHUn9eYT_j2_NCfpNiBvCR.uAchcv9hODMuHEXeV3UhhMwbF_2t57
 wrgULBdcVMo4V3cVi56KdV3HraRiC3P9itIYL8YA0FtGfUeSAd8gYXQewhAyDJZPHS.A98_q3NuP
 dkPjTVgXVVL8t8Iqlm3Yjn2SF25e1C8RAFvXj3TOXIipfLMBCxjbIGxDcilWy98pIC8YJYY9Xh3n
 KDUvPe41KJ5Us9IBudBdP5EbNmZOTJ2MF0Gf56VG_RJVBoTCjDYp4tF_01BvmNxj9fIYaeCHLH4W
 LhXDTI9wXG8ejzTY2mt_Id9q8Q1ijp5Tm9lkyU3A02GHmSes4exCFtgNWXya1.OrM80WQquzYwaB
 Rc7lbn.NMk7NiccsAKD8dWeLG12vZIPrT2sXX7eKTAEpP6Spe4HFVd7kgfs7luopvL7t_Zpw9JGk
 .yAx1cKP.abIjxe_Xa9vrgto0LveHDe2CwlT.4igorG3S_3Xjw4IkrrxGHCQH1myut3nRDjmTk4Z
 KVVtsku4Q18z9AptehWaOcI.80sTn1_IQnfj79UxvcB66MnNeW5E0mhI6A.KH7cqI9nj5fIbhMBg
 IUSM2O9gY0C5tydQQMC_Klen5VQX33SqNfwEKVyAWW.v7hs5LcgRQ4t9nLiJgYr4s4Tm8cy8DiLC
 7WcKnB9LQi2r88pv7nwGQQbEB6euBvmOoTrUYC0oCQ7EdOcxWvEPjlUiiPRlim5zO6sRkgRFWKCW
 BKid4fTrgEAbqYvHmgElFtp5W2zl7l1OHMqhiz.c.7lPiQOycOwiuDRC2gMqgvxPXGhpk8ZcC0mT
 nJybhbvoX7avhh0Mwf2Yk3nlkimkjVu0s._Epz_5iG7_aknzr9UC5iBYK_mn2rFqat6217GgKYrY
 QAAM7zCEgMME0tJoEn2c7AM8OM9Ysva.6UdxtHkwcPJqMY_YkpyOY7JZLgkhu7PkMXZH.zJOhuXi
 m.wb_3YDyFY6xQ.LB8haBNwpeepN4GE.U4u7ZzpWyTnLdkaTrwiFZ3QTZQbZOZIYttUi.Y_d3Ice
 _QNLwT30ts1YhAA0wgjybC.JTuTd5NHe5ImuKsHOL3n9s9JJK8IAWiM8ot606FFtkIRR32NBx7yA
 ZflIpFn8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 04:21:42 +0000
Received: by hermes--production-bf1-5458f64d4-46wzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a79607a9a26acb1091b4051c31df28a;
          Tue, 27 Dec 2022 04:21:39 +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.300.101.1.3\))
Subject: Re: ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds
 reads (Should  it have been MFC'd?)
From: Mark Millard 
In-Reply-To: 
Date: Mon, 26 Dec 2022 20:21:27 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "jrtc27@freebsd.org" ,
 freebsd-current ,
 FreeBSD-STABLE Mailing List 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-1.54 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_SPAM_SHORT(0.96)[0.955];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Nh1gr2qVlz3tSY
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Dec 26, 2022, at 19:54, Mark Millard  wrote:

> Should the following have been MFC'd? (I ran into this while
> looking to see why I see a boot message oddity on 13.* that
> I do not see on main [so: 14]. There was a time when main
> also produced the odd messages. But I'm not  claiming that
> this is what makes the difference. The oddity was observed
> on aarch64 RPi4B's.)
>=20

Never mind. I got myself confused over the history. 13.* does
not have the file at all.

> author Jessica Clarke 2022-01-15 19:03:53 +0000
> committer Jessica Clarke 2022-01-15 19:03:53 +0000
> commit 4e3a43905e3ff7b9fcf228022f05d636f79c4b42 (patch)
> tree b6be66e54604bb2c1fbdfde27bf8a6644e04fd05
> parent 3266a0c5d5abe8dd14de8478edec3e878e4a1c0b (diff)
> download src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.tar.gz
>          src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.zip
>=20
> ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds =
reads
>=20
> We do not include sys/rman.h and so machine/resource.h ends up not =
being included by the time pci_private.h is included. This means =
PCI_RES_BUS is never defined, and so the sc_bus member of pci_softc is =
not present when compiling ofw_pci, resulting in the wrong softc size =
being passed to DEFINE_CLASS_1 and thus any attempts by pci(4) to access =
that member are out-of-bounds reads or writes.
>=20
> This is pretty fragile; arguably pci_private.h should be including =
sys/rman.h, but this is the minimal needed change to fix the bug whilst =
maintaining the status quo.
>=20
> Found by: CHERI
> Reported by: andrew=20
>=20
>=20
> Diffstat
> -rw-r--r-- sys/dev/ofw/ofw_pci.c 1
> 1 files changed, 1 insertions, 0 deletions
>=20
> diff --git a/sys/dev/ofw/ofw_pci.c b/sys/dev/ofw/ofw_pci.c
> index 7f7aad379ddc..4bd6ccd64420 100644
> --- a/sys/dev/ofw/ofw_pci.c
> +++ b/sys/dev/ofw/ofw_pci.c
> @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#include 
>=20
>  #include 
>  #include 
>=20
>=20
>=20
>=20
> (Note: leading whitespace might not be preserved.)




=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 27 18:26:29 2022
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 4NhNQw1xrsz2kv6P
	for ; Tue, 27 Dec 2022 18:26:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4NhNQv0VNWz45dH
	for ; Tue, 27 Dec 2022 18:26:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=feVsQd8c;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 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=1672165605; bh=JQw0BUpLCE9E4p0a1iJz7OyJ1gLxdl/GG0Y5whHGZHo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=feVsQd8cM5Ei5cEV1WbJxxz9LduECLsnpJZgeNMLhcMTu9jDbvyDPRoytIR0MiKZ81XkK/Iqq2CVO4xOoRKgse8i/5fDmkxdaKBGKhFy1Yd+geL5xwfpnQInN7wQ5Jgc+6DSuRBCtArBhEMVyzwVn2L3uLmbvD8vvNvSOCit3QbnBgodd467EpYpvVc6pRJoDqEBYgBcv3x3y9jcobctcBKQXJOOl/1kxJ86BrKhY4cqXqLKYLllJCH8EMS0/bHn9gBnTVtv6LzhKzBm1b14WDaqFbXsdXGbmsqol5Xs4luTWsuVn++jZduKGQy9VRPSlz2UPDXhT6qtf0NX2wiu0Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672165605; bh=V0oEEuuuqD2o0WmDbobiW0kE/oeBRdIxsK1zCtqvM0d=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ogcnbJ363C1u64uJPzImzeacCKReRdZZ2w7hr50udhlyA64PW1JwVogfsUPI24Is69E0oo3os2s9kWYA4HUSJlno/ELaWVOZiBwJ1NgklHAOr6/UlsVAaBStAXraidvMdbQ/p8mAClByJ8Do5bLrbL55gHaEz9x2TBe8xsyFlzvwsNX+qdk1CYl3edLVhtD4Km6ZBlnwGwAqp3lwEbnF8CG2gILk9nYSVhimXGeydwNrsXZ67m/4K07fHb8YFph9fNJ9+gWNNIke1rQL3SDyATbQDXeIeCY/EULcwHVouSzv1a6aLP8AFOOTtWnuGvJZY6fJFHwYcDY7jPpwpNiySA==
X-YMail-OSG: MdWNR2cVM1nVh4katJvojcotnLDox0K6rF88PVu2uU_xZ0ypXUgCye3112qw_mZ
 F5.3ihIkGf0LNTpONG3oTuRXQwr35ZvlgrhExUhrDGuic5maHEeuiGfzYPfNRnV4lnRADJ9i8k4W
 pMn80VHvnDr9dhhQCXA817OqIVnzSjK1PY1me7NMryvxqeB3w_wTb2zvm1A4fs_WKgSv8M3fxQjj
 Z.8wzpA.BmTW4uUzJA8tOEwEi2__YNqJwfoRoVwZgIM.2BArGqx9lvnVH19iLcc5w_9qTFyaX3pq
 MR8DiulVyKtl5SKQ.Li8omMx0In.5RpMVRrhEmKYqaTY5kTwcYnYofNUyIV.yxAICHqt.Dzgu8q0
 y.NA6pFxEcI8Bai4tucvf_UWIbtqslpE8qCUVQpdRoHN3HEKv_Hq3dF5soCRFQIVgFQhwcACltgD
 iBUiZmr1dZjREmnUU3aawwe5RfPe5C2hqp0l4uPXI_i6wEYw6H2uEj.bxlNj8LHV0bZCZCI0YCTz
 VaBH24SsXVrtfvI4Zn9CNvRt6KkqPyzzJYpcObldBxmtliuSwniAZUNeAyYCOkdDV2ZzwUo6pQue
 msRQdR6EDNklzlLCUhfwCfOkOKKBU2oqtKvfmto7rNZob49E5u6PgfNJW45Zqw2vS0vcEp4mR7up
 8YEHlmo72MdnArm8CF1D04J4sammMC6.KWJ.AesHSC2J9weSMGHrvGmnFS10dmsmPLuX4BWJx5yE
 Ho3ZeDVb96rRjxCFMIFKviZwUzQAM5N99TRbxIWsrBxY5eAD8wZLEbMya1r.JrgH4s5I9OeN9sET
 m1jHc_iPmcAdx2hEoTNV3EQHq_3qo58CEN2GPrVbhX4DUci_YZYPQbq.jBD58xy8qbG5mwTPCVzo
 BpZJCb3LUk9XOku4P2dMpDOahqLZxuLKGppoWlhc.W0Z0iitPLcklsjNn3NxYoLHNX6CRJfSzeBx
 AzWPWzqUDaWJ.1Z5xuU61ug_gqa_714pRXGPIfju4h2wFMABq6IEw1LVqIUCLE.U.6BReuP7GnMm
 eb_XLMX.yI_Mmtf5cbnIrn8M5_Gt0Go96lUFSkidGDimlpvVbKB4V5Cgh29GCTEIPOQ0ghaLA6Ok
 5NspxE.RFUq84YnsSM12KwGER7tdZoByRk0X3KCStJqjl.QATgXn2RurGycpZbr8Ma4WNGgZJ6PF
 bSvLqmBGt4JmwbhcbXm6wh665n3SSiKL67mf4hi89wi7h4TntlK94ewaBeARJt8lHAB8knK32YXC
 0QJXz99nH5.vM0FODXvw81LSuttIJKrC41uR3.okQ6ipAupPlxIWkp7ky_0xtJ73yZvcADD5Mzi6
 NlTc7KrpuEqYMqRLmPb84i.QtnT1BmXuyaU1q3lDjjAyXHDlVWrR7WmzTK_2uU.jn6ms5qZw7qOh
 4PXKt0ex5ToeWvOLGZaW37XEputXYWrNjjZaZWuG8CWb7PKL5OBOpB_OJGs1OuqNqQQZkQkPWO4M
 E10.4mQ5599qSMumYdRAIYJcpzkzwTGcJHvBekYsEFC7k50OMiVo2By7NycrIKRfiS6HBXmekPWZ
 MeAlv7zjiohgnM43PYsgC4iaqHRG2RrPlNh57qvZvtsDyY_kyMGuYebRuAsFQEdw846oxcJE9.pE
 JDkonqXJQfMj8J61MmrPPQNIMdy2.9OMkiPqs9ZDwC5FCs1bRxR0FD_YkezhMtrNclMxpfbXIX3y
 KvojVQI83C61PNL50kySBqMD.ZcQeyIHIOz0ndjrdfraVT9iEw9OH6onaZJ92IbOVcfspuNOUGUF
 tKFhx9sMMpFw09JHsjZ0GZezL3WmnGy7SAhrzlZdqd4NfEItTpD1_jFUr40AwYbx0.ams5FU6EQS
 kvQwmCIk6GC5SUTeMrDVfMN8_3ztdObeKFfnH0Ifq3mK6aYCnz.MY5dYGiWcDOucpiz64g.LPXny
 GepvgMZn4d5.x.3C5eXOvgiTOqvbuBaGumEn6C9UL8aMyvbcFNB8._g1GHajgCDhpsmPO_hinWfA
 ls.ZVDjEbaNC9YZ49mpRoqneQ3Ob_YkKlj6_p_3Kb9d15WyFqRRXiBJbzgps7iYh2HRUaOZYQoH8
 KrghpKLwTw55RxwymbQuBAXUp331fPRvhIrTXWQmNJqPGKWp0MTWhkOkjknAw4.qaQgTKD0sRu1_
 _ZBBZcUk8SiYVM27fxoR58WSM61QlXQ6Bm.tuzN.Rxmk520yWA5ciWVS0sMNlCeHNKHD.xfKs21k
 .XYiNNazDtKLuyH52QEcAfhzGnMj0E55t9tGNZKOC8kae.LBVS_6eFTf9eVsKuw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 18:26:45 +0000
Received: by hermes--production-ne1-7b69748c4d-bmdl9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3e86c5d742eb7ee7ed1ce61a8fa0352c;
          Tue, 27 Dec 2022 18:26:41 +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.300.101.1.3\))
Subject: RPi4B's: 13.* boot "'failed to allocate bus number" message vs.
 main's [so: 14's] lack of such, also related Device Tree content
Message-Id: <2837F65C-9812-4A78-855E-7B6FAB8936B8@yahoo.com>
Date: Tue, 27 Dec 2022 10:26:29 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: <2837F65C-9812-4A78-855E-7B6FAB8936B8.ref@yahoo.com>
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.971];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NhNQv0VNWz45dH
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n253304-461210143fbb: Fri Dec 23 23:25:49 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64 aarch64 1301510 1301510

boot -v output (to give more context):

. . .
pcib0:  mem =
0x7d500000-0x7d50930f irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0:  PCI addr: 0xc0000000, CPU addr: 0x600000000, Size: 0x40000000
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0:  PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
pcib0: Bus is not cache-coherent
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
pci1:  on pcib0
pci1: domain=3D0, physical bus=3D0
found-> vendor=3D0x14e4, dev=3D0x2711, revid=3D0x00
        domain=3D0, bus=3D0, slot=3D0, func=3D0
        class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0
        cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
        lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
        intpin=3Da, irq=3D0
        powerspec 3  supports D0 D3  current D0
        secbus=3D1, subbus=3D1
pcib1:  irq 91 at device 0.0 on pci1
pcib0: rman_reserve_resource: start=3D0xc0000000, end=3D0xc00fffff, =
count=3D0x100000
pcib1:   domain            0
pcib1:   secondary bus     1
pcib1:   subordinate bus   1
pcib1:   memory decode     0xc0000000-0xc00fffff
pci2:  on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci2
pci2: domain=3D0, physical bus=3D1
found-> vendor=3D0x1106, dev=3D0x3483, revid=3D0x01
        domain=3D0, bus=3D1, slot=3D0, func=3D0
        class=3D0c-03-30, hdrtype=3D0x00, mfdev=3D0
        cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords)
        lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 =
ns)
        intpin=3Da, irq=3D0
        powerspec 3  supports D0 D3  current D0
        MSI supports 4 messages, 64 bit
        map[10]: type Memory, range 64, base 0, size 12, memory disabled
pcib1: slot 0 INTA is routed to irq 92
bcm_xhci0:  irq 92 at =
device 0.0 on pci2
bcm_xhci0: note: xhci firmware not found.
bcm_xhci0: note: installing xhci firmware.
bcm_xhci0: note: xhci firmware detected; firmware is revision 138a1.
pcib1: allocated memory range (0xc0000000-0xc0000fff) for rid 10 of =
bcm_xhci0
bcm_xhci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xc0000000
bcm_xhci0: 32 bytes context size, 64-bit DMA
bcm_xhci0: attempting to allocate 1 MSI vectors (4 supported)
bcm_xhci0: using IRQ 93 for MSI
bcm_xhci0: MSI enabled
bcm_xhci0: (New XHCI DeviceId=3D0x34831106)
usbus0 on bcm_xhci0
bcm_xhci0: usbpf: Attached
bcm_xhci0: note: switched to 32-bit DMA.
pci0:  on pcib0
pci0: failed to allocate bus number
device_attach: pci0 attach returned 6
genet0:  mem 0x7d580000-0x7d58ffff irq 82,83 on =
simplebus2
. . .


But this goes back to releng/13.0 (and, likely, beyond),
including in main after stable/13 .

Higlighting what is different vs. main . . .

First note pci1: vs. pci0: (and main's "OFW") in . . .

pcib0: Bus is not cache-coherent
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
pci1:  on pcib0
pci1: domain=3D0, physical bus=3D0
vs.
pcib0: Bus is not cache-coherent
pcib0: hardware identifies as revision 0x304.
pcib0: note: reported link speed is 5.0 GT/s.
pci0:  on pcib0
pci0: domain=3D0, physical bus=3D0

Again, later . . .

pcib1:  irq 91 at device 0.0 on pci1
vs.
pcib1:  irq 91 at device 0.0 on pci0

Note pci2 vs pci1 later (and, again main has "OFW") . . .

pci2:  on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci2
pci2: domain=3D0, physical bus=3D1
vs.
pci1:  on pcib1
pcib1: allocated bus range (1-1) for rid 0 of pci1
pci1: domain=3D0, physical bus=3D1

Again, later . . .

bcm_xhci0:  irq 92 at =
device 0.0 on pci2
vs.
bcm_xhci0:  irq 92 at =
device 0.0 on pci1

Finally the error report vs. not . . ..

bcm_xhci0: note: switched to 32-bit DMA.
pci0:  on pcib0
pci0: failed to allocate bus number
device_attach: pci0 attach returned 6
genet0:  mem 0x7d580000-0x7d58ffff irq 82,83 on =
simplebus2
vs.
bcm_xhci0: note: switched to 32-bit DMA.
genet0:  mem 0x7d580000-0x7d58ffff irq 82,83 on =
simplebus2


The rest of main's output text for the block I first quoted
is the same.


An FYI about later RPi* firmware updates and the .dts/.dtb
content that is related (two separate changes). . .

=
https://github.com/raspberrypi/linux/commit/13dbc954b3c9a9de0ad5b7279e8d3b=
708d31068b

reports (2021-Oct-12):

QUOTE
ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address formatting

dtbs_check currently complains that:

arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning
(pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format
error, expected "0,0"

Unsurprisingly pci@0,0 is the right address, as illustrated by its reg
property:

    &pcie0 {
	    pci@0,0 {
		    /*
		     * As defined in the IEEE Std 1275-1994 document,
		     * reg is a five-cell address encoded as (phys.hi
		     * phys.mid phys.lo size.hi size.lo). phys.hi
		     * should contain the device's BDF as 0b00000000
		     * bbbbbbbb dddddfff 00000000. The other cells
		     * should be zero.
		     */
		    reg =3D <0 0 0 0 0>;
	    };
    };

The device is clearly 0. So fix it.

Also add a missing 'device_type =3D "pci"'.

Fixes: 258f92d ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring 
Reviewed-by: Rob Herring 
Link: =
https://lore.kernel.org/r/20210831125843.1233488-1-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne 
END QUOTE

The diff shows (leading whitespace possibly
not preserved):


&pcie0 {
-	pci@1,0 {
+	pci@0,0 {
+	device_type =3D "pci";
 	#address-cells =3D <3>;
 	#size-cells =3D <2>;
 	ranges;

There is also (same day):

=
https://github.com/raspberrypi/linux/commit/3f32472854614d6f53b09b4812372d=
ba9fc5c7de

that reports:

QUOTE
ARM: dts: bcm2711-rpi-4-b: Fix usb's unit address

The unit address is supposed to represent ','. Which
are both 0 for RPi4b's XHCI controller. On top of that although
OpenFirmware states bus number goes in the high part of the last reg
parameter, FDT doesn't seem to care for it[1], so remove it.

[1] =
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210830103909=
.323356-1-nsaenzju@redhat.com/#24414633
Fixes: 258f92d ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring 
Reviewed-by: Rob Herring 
Link: =
https://lore.kernel.org/r/20210831125843.1233488-2-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne 
END QUOTE

The diff shows (leading whitespace possibly
not preserved):

 	reg =3D <0 0 0 0 0>;
=20
-	usb@1,0 {
-		reg =3D <0x10000 0 0 0 0>;
+		usb@0,0 {
+		reg =3D <0 0 0 0 0>;
 		resets =3D <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
 	};
 };


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Dec 27 20:31:56 2022
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 4NhRCf48yLz1HbyG
	for ; Tue, 27 Dec 2022 20:32:14 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4NhRCd2gDZz4PYd
	for ; Tue, 27 Dec 2022 20:32:13 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=cViwslOG;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 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=1672173129; bh=XU3VUvrseopfEUZ7lB1rac7ZAndIoHbYs0s06TD8cdo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=cViwslOG8FvFVyflte57jydS8nbmqjJ2oYVmMKRhkRNneqPs4psFewwb9M+4WMos0TKHywQN8lC0iQNpKpLjywDg5axTxAiPFdgsarqtAnz+tNkJp1+BHnHAKWn4CY/SqmcHJ5TQWNR/KzPZVGuHmObugVfaQG3tQU/BPEKcQfZ963t5kcOmlc5WnusnbZhi9BcISdADIcRyW7/K2M8oYYjW58cBX5CsfItIYnImfRZbo2bmrsI1fsMY/6RDskix0nB3FGIVUMCfm2la+IBigbnBO1m8wgcdY0HPYioKR8fUbINuKhQlIWiLa6+jGIVOaXlR6YNNoqv8R1gQjUebYA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672173129; bh=w0yMqPPOcFS/vg3FmloWmj4TWkHi+4rbnUm3UgFvfu5=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NJllIH39QulLTsGbtcSbnIPlH0MuZ80fby5tb8/R8MWIujhdbiKkA8lfQ3R1YWI31jcxyijXRBsKG2Tdgzvpv6S8Bru2HEZLhWQdhFzkaBoBuzCrxBlyVvDZlMhhLyUPnB4VGgPWYda5PIUltqp6RJ321AYNESSJOQ4FO96zxqER/v3ZsKBEScBYDzNz8NyCoNEhjKQan00zgmBcwIUDZo9JnLXieH3idXQOemFAhnK98jV/d8w5tEdZ8B8+lu+OZI5Yk9lO2jVgTc3jOepUtj6W11wC2UxQG7v84kbocG+NY3LcqbMM1yBUkqd12vqg7vxt6T+V7o5e3s1pFyT/aw==
X-YMail-OSG: SXvKIXUVM1moI2RT_tDGcPa0V4LiphzmLlysmFIqAcmxF0NJkK2IhY5qT8rvavI
 Y0.okFxoRGrbNGOzzXUAHtFRjrEz7p.dpGH69fc0bEGufyoCukW4qovR8TNZjFtVP697_VHWxYD.
 jdvGSH2hi51LvohGXI7fZuPvSnuB.YPXqiIUbYBSUNkRVU4r6n9MqFQfmcS_whsAT9uQl12Awoio
 4MOqmelfiLLpB95rKTLY0MTxTP0ubKrEAINJ2fWHThLgLD1T.8G1.Sj8Dwy4hNyQ2cfpvOx7kjOg
 uCQjcMnAac5Ajp7dr9Mhm_umq.KnnDiSuHkWvVAj7rrh_ypIke95I7hphAhUCahC3NJ_qqHbS.RJ
 KNs1d_TmCq6n_sciHqKq5UWqvsngcJHdAdFH4BaDnSw0_xuvhSQ2WcMPPn06.c3Zb_OmyU2LL5J2
 6scmNjSkxolVHEr_XbFAqKhxfhOwkGqX5YoGfPl69jfPNGeWFchDTQVDIZsofPv27JAfi9xXhCHt
 2vprksvMYiob139OXYJXynjZsHb.VV5Q1SWarL.bI0BmIVNnTCFy_pw7yUbY6GtZ36WXbXvPliZf
 dsee0lIwieL7WOo2NDNy2Mv2F6xtkImzEMWUcxBLU.JELGjnJ_NOrsaXGMMRBd4.fFC57e_prYDB
 4DmmsiPO4mlpMIwqbuVhDOPUKJEun.pGzzr1zEUT2GUFjhGJqZfCFwEXjSHoVhbMaEl0A2q2f5ty
 lALHK45GuO3zM3_FGk79gkmDJ9y5cy9cvIJhevLJgTKTFOtC1nmCEXlUg0pdO.qhLBJz_A9Htn5D
 6MVtMzOhDr7itWoVimt9GbPAfBfIv1HwvZ1xpiVy_QeSLtP3LCjFaSxi0aayh_6M1xyWJjBetyrr
 WKJ5P.HqZg3pG.KX3tnULx9g2oRHfHX8tH18HES0K_OVLJohgIpK0_SWCmi8NVhpnqktAYRBc0jw
 SHFYa_qNASlOODx2x54ejgJz7Lq2moEiJcbYAazX66S_kmyFFRfIQKIr7834O3EWDpFc.EdTyuZl
 pqA37haJBR_ikHG_z7Fy7xXF6Kp2MKbQCJC17GcOQerV2j7SVZngQsi7EoS1NxiMYf_dmTvWc.vY
 RCsPee1HE2V8DTr5isKstK6aao5_VSqXhHqhFDQDhpTDRDbyn1z3GRiWz2r3dsLMNf.nFkoR6ObW
 Wvql7Gxkjx522HxIqTRHgngCq5F8w6FsYCAdm1EPQqtLD0pkOyt_Dp..EqSxfjoYOcY_DoiMd7rL
 i5r_fm46DvnWF.NSzGVhN3u.lh6KAEZ5TLuykiS_lArfzrv5UmW3JDIJjmZQQod5qLyq.zwk.tIl
 vlJqlpHAV6eZzxynlwhocrKfbSDqeRI7OKmqYualcFneZr__fHNGqE0khSTo3nMdb_Bj.Vaz1AOn
 NYc6WZt20SaUv8yJsa4537rr94.nyBgiaFTGLpbA7aPAp8NqUfjmuYHRrY6lk.Wq6YkoD_fyJb8w
 eyKKq5XAXBbQQBx5_RFCElna36LgzDz6r7FMlcIMhYfzLQ1TySP5zRhpm8tJN0C8W9plwLgW_Ypq
 M5_1smJw5XaFtc_hrAsEpIZ0bzMyRQofthK9i72_S1mpBKDn1.4NFInKmvUrvfdDM.yZqyf2URru
 OMeqe7iZBnNOz7QMgaNDUVS4KGdJ67GYVQmghSxMLDTCAHZghrywp.JYkisaZf5M6qXFkhVviTyZ
 GEAlVTYxMrhhqkrtTh3f7RNu0uM1.GCzJ8q8knBTHzil3LC3LHVGkH0mVm.kd3s3vRiQMlhDnv4p
 ousiBf3jsFtqSEp6iWWSbJhTCKkRWZ6xFHhWkw9H0pANh3HfYTd8RbjDbBrant1QtLIuF9NZkGky
 hixtw72sQdNTpJbHoeuniPKGR7klBopcNNKfsW9He_uCdFPaRfRml33YshkIdrLwOq2LHwJFRq9t
 PCwKxBxLv5pQvK4IcBQNWosAemRx3LbSmKOZFvkLA_q_LPnyY2RTdNzokZ1nNESvu4YWmkr7e1TH
 q0EkiwDs5wy1tQjFRd2W53IYZnCy6UsE2etUgkitgU0TnlbR9FK_4QtpK1mSowPIdNl.UtNvsBQh
 qRqZyCZYCEwnj3jjFhR32inY50AXXYoehaPaf_gI9L9xM4nvQLMaUW_CPTMCCO8ncYzt2hRVUedl
 1aL5fvPIBkvR7vQr9bLfsjTNed6.I9FfkD1LNlAzBDxzJAHjBUBaeTkCZLxD5e8VxFSipNiTrI7p
 I8vQZ8teInZ2bWof_m8nrVqgVwrfu678goQYio1EOjzWb8IdCZrpTeLE6w0Q-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 20:32:09 +0000
Received: by hermes--production-gq1-d898c4779-tqz7n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID da129cd794327e86f7956dae441c2a56;
          Tue, 27 Dec 2022 20:32:07 +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.300.101.1.3\))
Subject: RPi4B: booting USB3 SSD media vs. config.txt in FreeBSD snapshot
 builds (and relelase builds): avoiding error=USB_ERR_TIMEOUT
Message-Id: 
Date: Tue, 27 Dec 2022 12:31:56 -0800
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NhRCd2gDZz4PYd
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is about "no microsd cards involved" booting of USB3
SSD media on RPI4B's.

For some time I've had to edit the default config.txt that FreeBSD uses
or booting USB3 SSDs fails.

(Leading whitespace possibly not preserved:)

# diff -u99 /boot/msdos/config.txt.orig /boot/msdos/config.txt
--- /boot/msdos/config.txt.orig 2022-12-23 22:17:48.000000000 +0000
+++ /boot/msdos/config.txt      2022-12-27 17:22:08.000000000 +0000
@@ -1,11 +1,16 @@
  [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
 =20
  [pi4]
  hdmi_safe=3D1
  armstub=3Darmstub8-gic.bin
+#
+# Local addition that avoids USB3 SSD boot failures that look like:
+#   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
+#   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
+initial_turbo=3D60

The latest example is from an experiment with:

# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n253304-461210143fbb: Fri Dec 23 23:25:49 UTC 2022     =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64 aarch64 1301510 1301510

that was otherwise unchanged. But this has been going
on for some time.

Given what makes it go from timeout to working, it
suggests sensitivity to variations in clock rate
that initial_turbo=3D60 (or analogous) avoids. (I've
not tried to find an estimate of the minimum time
figure that could be used.)

FYI: the context happens to be serial console, no
HDMI connection.

It may be that the EEPROM vintage is involved in the
variability. (Old enough ones might not have the
variability?) But the EEPROM vintage may not be
relevant, I do not know. I normally track:

https://github.com/raspberrypi/rpi-eeprom/releases

So I'm currently using RPI4B's with EEPROM content
based on:

rpi-boot-eeprom-recovery-2022-12-07-vl805-000138a1

materials. But, again, the issue is older. I do not
have a first-failure time frame, however.

Given the history and the boot failures, it looks to
me like an initial_turbo assignment in the default
FreeBSD rpi firmware port's config.txt would be
appropriate. (Presumes no one deals with avoiding
there being a frequency-variation sensitivity in the
first place. I've not managed to identify where any
sensitivities happen to be.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Wed Dec 28 22:42:33 2022
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 4Nj63q4lJKz2cDVK
	for ; Wed, 28 Dec 2022 22:42:47 +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" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nj63p5Jdgz3JWn
	for ; Wed, 28 Dec 2022 22:42:46 +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 3536B8D4A169
	for ; Wed, 28 Dec 2022 22:42:36 +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 0A0D65C3A833
	for ; Wed, 28 Dec 2022 22:42:36 +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 qcnzRxw3BY87 for ;
	Wed, 28 Dec 2022 22:42:34 +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 948CE5C3A830
	for ; Wed, 28 Dec 2022 22:42:34 +0000 (UTC)
Date: Wed, 28 Dec 2022 22:42:33 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm 
Subject: rpi3b+ ue0 too late to be configured on boot?
Message-ID: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
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 [-2.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[zabbadoz.net];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+]
X-Rspamd-Queue-Id: 4Nj63p5Jdgz3JWn
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hi,

does anyone else have the problem on latest main that the ue0 on an
rpi3b+ doesn't show up in time for the rc netif to configure it (or at
least it looks like)?

While during boot USB seems to need a wait-delay now, which it hadn't in
the last years for me?

------------------------------------------------------------------------
...
Feeding entropy: .
ELF ldconfig path: /lib /usr/lib
ugen1.2:  at usbus1
uhub1 on uhub0
uhub1:  on usbus1
uhub1: MTT enabled
lo0: link state changed to UP
uhub1: 5 ports with 4 removable, self powered
ugen1.3:  at usbus1
smsc0 on uhub1
smsc0:  on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0:  on smsc0
smscphy0:  PHY 1 on miibus0
smscphy0: OUI 0x00800f, model 0x000c, rev. 3
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0:  on smsc0
ue0: bpf attached
ue0: Ethernet address: xx:xx:xx:xx:xx:xx
Starting Network: lo0.
lo0: flags=8049 metric 0 mtu 16384
...
------------------------------------------------------------------------

If running manually after boot (again) it all works fine?

# sh /etc/rc.d/netif start ue0
smsc0: chip 0xec00, rev. 0002
Starting Network: ue0.
ue0: flags=8843 metric 0 mtu 1500
...



Not that it should matter - this is with https://github.com/pftf/RPi3/releases/tag/v1.38

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Thu Dec 29 02:37:44 2022
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 4NjCGx1C8tz2kynN
	for ; Thu, 29 Dec 2022 02:37:45 +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 4NjCGw6STVz44rM
	for ; Thu, 29 Dec 2022 02:37:44 +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=1672281464;
	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=Wr4VwlkCs45utn0SjY9/2VUQqiEg3lQdLfNml5ktmKc=;
	b=kVitssvlC1CzZ3aPLOh8zOKX460jStDfnZf5/fOUR5lgFJzCAZYGDVrRryvnWo0A+dAEyy
	z2YyGjCYtTdunkfiAYc9x4u1GUDDxPIj/fYJBYVuT3eeznZ4KdKUPhpugCVtvUh+Hnh0dn
	36Up2yq/tO/dyV8V0JIFc8lttGC0dqhx8FKdRbxLXGji/WQhRCCVPcV8FkVakm2gCSwtGV
	1D/VHU8b/07k27q1KJKWPgS/qq+qfAhQyadX0AFCL6x+vJ6xmkBAK9buWNoHAi1R99X70A
	TRmwGKvxmA8hDX0T6lH5nTVdVOtpgh8JQrt3JYB6ALZ2nPGX6dsMKFhyHkJkJA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672281464; a=rsa-sha256; cv=none;
	b=tGXJ3rNSe2U7pc56fKmIrv0VBbQNeAY1sOLXLVyQyAKI30kE77PmYbiTCZhyrsjeT7k0IJ
	pt+67LkOmnscX6P0xQl3NIt1ElQeHcs3pAsHz+a6kRNQRE0DGuX8gvzskHEH2Gy79mukyF
	KhgVXWOetneKQp9R7n2lYRpSd3XO4wlQoE35r5RIv8gLGQaUm9912D1ExzPe8d0umDEN1S
	DMea3B8TFsj967hCV1kAH6YUHWnPmq9v6Z0Ixqe0lqjji154mEII63KJg/V40AVGQjDzzU
	WoLPkJb3WhymFzDYjDEh80PeXJMXUIOeqbr9MrPIidYdGty/s6Ls6LMTfgXRRw==
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 4NjCGw5WlYz1Bsd
	for ; Thu, 29 Dec 2022 02:37:44 +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 2BT2bibB067715
	for ; Thu, 29 Dec 2022 02:37:44 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BT2biFD067713
	for freebsd-arm@FreeBSD.org; Thu, 29 Dec 2022 02:37:44 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 268630] FreeBSD-13.1 fails to boot on raspberry pi and the
 U-boot saveenv command does not work
Date: Thu, 29 Dec 2022 02:37:44 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jjrushford@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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268630

            Bug ID: 268630
           Summary: FreeBSD-13.1 fails to boot on raspberry pi and the
                    U-boot saveenv command does not work
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jjrushford@gmail.com

I have an issue trying to boot FreeBSD 13.1-RELEASE on a Raspberry Pi Model=
 3B+
and the same issue on a Raspberry pi 4.  I'm using the
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img written to an SD card.  On boot =
up,
it stops at the U-boot prompt and does not proceed until I enter the command
"boot".  I wish to auto boot FreeBSD without having to intervene with the
"boot" command at the U-boot prompt.  I'm told that if I set "bootdelay=3D0=
" at
the U-boot prompt and then save it, that this will solve the issue and so t=
hat
FreeBSD boots up when power is supplied.  I've tried to set bootdelay=3D0 a=
t the
U-boot prompt using:

setenv bootdelay 0
saveenv

the "saveenv" fails to write the change to flash though with an error.  Oth=
er
people I've discussed this with on the freebsd forums have said that the
"saveenv" command fails for them as well and they are unable to save change=
s.

So there are basically two issues that I have:

1) FreeBSD-13.1-RELEASE does not boot up when power is supplied, the boot
sequence stops at the U-boot prompt.
2) The U-boot "saveenv" command fails to write changes to flash

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Dec 29 02:38:21 2022
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 4NjCHd6yYBz2kywt
	for ; Thu, 29 Dec 2022 02:38:21 +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 4NjCHd2pmmz4574
	for ; Thu, 29 Dec 2022 02:38:21 +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=1672281501;
	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=nIdlZKlM/m8+ii7ePzekuwwMIUYbyyVtLuqZ1GonmiM=;
	b=RegnRXvbCARB2aH+7bGcBtX4ooKTuWopeO7EwkG+16LIovwWVQHLZ+No+5CMVZVgDmkCcc
	y7mJS/vPqi1c3doJxqS6fYNZkJ715ramWK/witRb8w/z2gjekfgyTaONEtqYVan1dGpOjM
	cSz5R3NC0ABpdRWwOd1khViR8axV7zCy8RR93dNuRKNQ4FsmrdCQZ82KCaiZihc6eYw3VH
	iZ1beQLXopRsrka4T295powYbsAMaN+YwqoLeJX0eBZATLrmazF9eew46Db+hlBchPf0yn
	3TAQg6wuLDJWSTRcG9ujwjArcVzq5COxzCRTt/Khvga0rgWLcFwAShNZPcXkkg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672281501; a=rsa-sha256; cv=none;
	b=fndzpoCoN8bGps5APsmKLNdjRTlH2cpwyi8LoOg1PtzK1/mr13NIGb72fONgW4uyJA4Rn4
	6FHgEq0vNVcBMZp1hV1PmB+bQGV1bjN9lQ2wrq+wLOmAsYiEufgFa+JDIryX/+5q9xW+Hd
	Q+AZ+AL4pRYGIJf4xdfcsYWj7pHUWtAH3QIdRncfbcrol4Lu81jM4KveuPyZGdsi+SOf+m
	Pl6LeNGspNWHg6wsIUvv+v+73g9nl5cXc56jlFLa2bd/n/RjxxCKdhZ+B/y1eJ8pTFfbLN
	GW/J8l9YFJ2ZlPwJ1crmohdPMOcNOQCbp3NlZDafSQFhF1Ppi9VKGG6ULKsFVg==
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 4NjCHd1tTCz1Bgd
	for ; Thu, 29 Dec 2022 02:38:21 +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 2BT2cL8p067987
	for ; Thu, 29 Dec 2022 02:38:21 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BT2cLOq067986
	for freebsd-arm@FreeBSD.org; Thu, 29 Dec 2022 02:38:21 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 268631] FreeBSD-13.1 fails to boot on raspberry pi and the
 U-boot saveenv command does not work
Date: Thu, 29 Dec 2022 02:38:21 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jjrushford@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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268631

            Bug ID: 268631
           Summary: FreeBSD-13.1 fails to boot on raspberry pi and the
                    U-boot saveenv command does not work
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: jjrushford@gmail.com

I have an issue trying to boot FreeBSD 13.1-RELEASE on a Raspberry Pi Model=
 3B+
and the same issue on a Raspberry pi 4.  I'm using the
FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img written to an SD card.  On boot =
up,
it stops at the U-boot prompt and does not proceed until I enter the command
"boot".  I wish to auto boot FreeBSD without having to intervene with the
"boot" command at the U-boot prompt.  I'm told that if I set "bootdelay=3D0=
" at
the U-boot prompt and then save it, that this will solve the issue and so t=
hat
FreeBSD boots up when power is supplied.  I've tried to set bootdelay=3D0 a=
t the
U-boot prompt using:

setenv bootdelay 0
saveenv

the "saveenv" fails to write the change to flash though with an error.  Oth=
er
people I've discussed this with on the freebsd forums have said that the
"saveenv" command fails for them as well and they are unable to save change=
s.

So there are basically two issues that I have:

1) FreeBSD-13.1-RELEASE does not boot up when power is supplied, the boot
sequence stops at the U-boot prompt.
2) The U-boot "saveenv" command fails to write changes to flash

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Dec 29 05:30:34 2022
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 4NjH6L5HXKz1Lm3L
	for ; Thu, 29 Dec 2022 05:30:34 +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 4NjH6K6x4pz4MP2
	for ; Thu, 29 Dec 2022 05:30:33 +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=1672291834;
	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=4iibmP2KMQMCMhwC7/tW4GWg4uIVu0edKD+6HcQjGZ4=;
	b=wAY4QBwCf83wbLev1pjgAJugQ4znqkj+SDU9c0pLmOIIct8JMpS+/6KQ838UHCQZiTRnlu
	nFlOzIWyC/NPx6kfR8UPoJi1pgtGMXxDYwGtC+ZPJdlP7APijRj40VevJk72QWUfsoOzC/
	S4YXENUogA0j9oiHCIEgcnDwaW4cjyi61CmDFOXkqBWSvlTB+snBHnWSD9fRbKNT2CxWDo
	EzCbce+mzzm/+qvlE5spJuHNeoL5WeV/vn3RmLQ1M3WKoBSAPheAjOdM0obSEaP/7CbtIF
	t2j3HN6hwsTctYprNsFQa6avvqlefrA0Ec/XRICDXeLCkugQyBiGiQoufZy8bg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672291834; a=rsa-sha256; cv=none;
	b=rnDA//an721wOSrEjDNL5weOvMgOdC4F5tWFWCpHLn8PEXL9idvNU3e4srNxuyhIQMWVXB
	Wd7UFplN01aXy22SxqD6U+mb4gbSuVz+Y6y4p+A0gGiS5o5GeCYr0dMT4pmzn/lrMVZQqE
	G9tgeYf1UImvbU0uSGmyEaYjpEs3Lx/IUx02dit3n3OBAFCqQO61VJt2IIj4BxMVr6ivRv
	a+SEgxwoVeC3CBMyaQKADeLPGTLJ/at2qsaudECavc1VqYLO7RakDymW9DqO+6fJtmC3Tb
	y+alXgDdn8KrnibdMaHezuZO2QAtvO3n+AT0ebSftYKBNOXUXvVDxsKKNzkZgg==
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 4NjH6K5zZJzH9g
	for ; Thu, 29 Dec 2022 05:30:33 +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 2BT5UXWF021955
	for ; Thu, 29 Dec 2022 05:30:33 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BT5UXHl021954
	for freebsd-arm@FreeBSD.org; Thu, 29 Dec 2022 05:30:33 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 268631] FreeBSD-13.1 fails to boot on raspberry pi and the
 U-boot saveenv command does not work
Date: Thu, 29 Dec 2022 05:30:34 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: lwhsu@FreeBSD.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status resolution cc
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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268631

Li-Wen Hsu  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |DUPLICATE
                 CC|                            |lwhsu@FreeBSD.org

--- Comment #1 from Li-Wen Hsu  ---


*** This bug has been marked as a duplicate of bug 268630 ***

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Dec 29 19:39:36 2022
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 4Njdy86pN5z2l3yS
	for ; Thu, 29 Dec 2022 19:39:44 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4Njdy84NT6z3M7h
	for ; Thu, 29 Dec 2022 19:39:44 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2BTJdbIo071983;
	Thu, 29 Dec 2022 13:39:38 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id sHgjH/nsrWMtGQEA4+wvSQ
	(envelope-from ); Thu, 29 Dec 2022 13:39:37 -0600
From: Mike Karels 
To: "Bjoern A. Zeeb" 
Cc: freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
Date: Thu, 29 Dec 2022 13:39:36 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
In-Reply-To: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
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: 4Njdy84NT6z3M7h
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote:

> Hi,
>
> does anyone else have the problem on latest main that the ue0 on an
> rpi3b+ doesn't show up in time for the rc netif to configure it (or at
> least it looks like)?

I don=E2=80=99t see that problem.  I tried the 12/24 snapshot of main on =
an
RPi3B+, and ue0 configured via DHCP on the initial boot, and on a reboot.=


I did have problems with the HDMI console, some of which are new; I will
follow up on that separately.  Specifically, USB keyboard input didn=E2=80=
=99t
work to the loader, and I didn=E2=80=99t see console output from user-lev=
el
startup until I disabled boot_multicons and boot_serial.  The second
problem is relatively new.

		Mike

> While during boot USB seems to need a wait-delay now, which it hadn't i=
n
> the last years for me?
>
> -----------------------------------------------------------------------=
-
> ...
> Feeding entropy: .
> ELF ldconfig path: /lib /usr/lib
> ugen1.2:  at usbus1
> uhub1 on uhub0
> uhub1: =
 on usbus1
> uhub1: MTT enabled
> lo0: link state changed to UP
> uhub1: 5 ports with 4 removable, self powered
> ugen1.3:  at usbus1
> smsc0 on uhub1
> smsc0:  on usbus1
> smsc0: chip 0xec00, rev. 0002
> miibus0:  on smsc0
> smscphy0:  PHY 1 on miibus0
> smscphy0: OUI 0x00800f, model 0x000c, rev. 3
> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ue0:  on smsc0
> ue0: bpf attached
> ue0: Ethernet address: xx:xx:xx:xx:xx:xx
> Starting Network: lo0.
> lo0: flags=3D8049 metric 0 mtu 16384
> ...
> -----------------------------------------------------------------------=
-
>
> If running manually after boot (again) it all works fine?
>
> # sh /etc/rc.d/netif start ue0
> smsc0: chip 0xec00, rev. 0002
> Starting Network: ue0.
> ue0: flags=3D8843 metric 0 mtu =
1500
> ...
>
>
>
> Not that it should matter - this is with https://github.com/pftf/RPi3/r=
eleases/tag/v1.38
>
> /bz
>
> -- =

> Bjoern A. Zeeb                                                     r15:=
7

From nobody Thu Dec 29 20:38:20 2022
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 4NjgGB2FzCz2lCPM
	for ; Thu, 29 Dec 2022 20:38:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147])
	(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 4NjgG95KVvz3hfl
	for ; Thu, 29 Dec 2022 20:38:41 +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=1672346319; bh=UO88P1wNtuswq8ADnEJnoxrVeJPMQ3++KM8DLc2Ra0I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nBuIy2NF9cosd7JgP3lBReL+NkOeY6wuu1mTXGuNHgIl2CErc9CL2kMGIJ/Ofj2Y7TfcmRm+uuT4Xv8uuFIWj+PZi+38ccWvR8NWWb9gd2UQhxzvcLbZv4Nqx3XWfEE2EKxouafE7CGT75zsTv2rWq92GNm1SHpuEW9LJM/R5vqPLKvMk0rholELCM0IgaINGVcmSLBCYvqxcst5b5op0pxGQKmwLdirQsVXcRfhcgRkU8BpQkxMSxWVEB5msSnlUbjtgP6Sa8L/zV/JBuiEsNmIUWj2ObjbNJmpmDJCvZQHV0jM3goxpmkBZWB6zzHt0oYWyD0rla+oDXuXXlRuDA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672346319; bh=qGNEWoY7J8UK+kLqSWId69GwT2H7bu9p5I7u5nrQJrs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kmnqxMi7eR04W1mj1qoFxaiwaJdOq93hHiJZ0Ezc1IJBsaZsrAnLDPIXGvQSrkLfmpENNjajtjIVdF8/JZjDvGGKcX22ACGjUM87NiQE+bXW1RIVypDKMS3zq5AARrIzfuHG12o7TCeaLH80qCW11BdNmHVWGb/IrfX8l5Gre86bV++IY8qcdym0PvS0V/sWqOrW14VQlC8zmfbFVXcc9W2Ew5bPXihVLS6bavfXH4yqacPwVB5es4rgMdiDoo5hJtR7ZhZINLESBKkihshELPOIbUddosPJmINK01gkDGeB6DUM/flX3/gJeAxTSWeCVI/6pdrFKtgpbn+qkFxtrg==
X-YMail-OSG: U_dpBxcVM1kJEXU8OoSf9jpj_3fn9hp32P5vR5Dp7dgCndd1KnZGXUZjg04aVtx
 vA2zU14KSanzjezIutnHPLH5PY7jvGZ5bC.5HhlsJGw8FfkdI_41FSk6S3_3jljeXui_A_uQI9TZ
 FNBBs8edmc7xbMzYMxVOd8SSjjZsOVxYyuwShl_x9TkboAHZDRLi9x0mc1_GSn69OcT2bsOS.inI
 XXKk_XwWxt9c5aypQD1oyg5_q8UR3zDuhRfm4ijh7KxOeUPEs9m68xcKoJpmJfeCw1PV2NUIIscT
 5xxaU7aRabUSHTUBtAYq_SnzVpu.O5EMPpQTbW8JlENc5g93FoMqiW1F.ecvPR2mnyLmcsul7jUB
 HyD2O0vUpRu7OIMzeGgIMbgi_3ooulk0yAFplH8RikMx3pKvgxicp2.lMsBBR_b3zOZTCIsqdDzg
 3ZAwldzbVMNJqtIPL4bylq_VowW55CZ36W0u5FmONxhvMiO.mrR9O195CCFEViU7Sq5XqcpoMPyL
 Nps6kwu2AHOvjb1Cmdqbnkx0IBg2YUQRXx74r6GZBkdjZBFjvBzk5u9b9KbdcYfcuBwnfPeTmAsx
 5tyzAs6SsmESWw.BkGDy15372tWtitkCoJvCD6phjO.3KNIJU9XdphaRmWsGcAdHsG8SkB8ogtqH
 ngqS6jG7stHSJkVInHQB_K.bvFkg_bEnhXokLLDoijpAGfljCePFGVDsYFcm68F9gFpJkM7MRuY.
 MSRs4XfA2nrQ.ECU3vLSvKea_0rirBVq578o_f5oBRJEBCKJNc6dBj68h3YNN37NtZN6sE7Te5zn
 nRvehUreykcJDiS1JHxQEC6jWx25JHC05K_5cxsHcTnJFlwxZyTyr39trcASVAaClbEN63rD.oHL
 CPf_mJbzcfNtTt1hJjpUJqXBu.AYffQ6S.0Z0urKE5CLAaZ18cXiIOEShAZCdbl5iRVwjBW0a_Pt
 L2.GB28stMu_i5OEh.iuyGPLjBFXvJ5vzjlfRNKtteDKOLnzmH5mlb5IBHcT7m5fNANwJJD4rD.8
 IOu1PHMmlQvS8dQvbMmsbMVX.YEK6GY2qmbazQxtML_6vi66Phf6DcPKiX2_jr2UyygV69JGHQtX
 bhgOMo8vtvXVEnTaclmm_8OBs3mkXINqdkoGR7wPHsFRu7z9qA0thK2OyhTZUQqzE8.yVdAylWos
 sYtjyYmyo.1Ysbr6F.rHi036GHqFA2OeRMHK1Py91UHCqCEihR4KCmIVHf9HO0aUmKNy2Vv8Q8kB
 E7HuSre8gHt9dtU5jces6FHkpENmSuLG1Y.mCwH65lesYGc66lOXADVzXb1CTKxS8Xg2NxpSu_z4
 S3IDedB5R40BkqDtFK3kFqv.fn0rKK6CtLKQQYKK6a1Kt9NUcTlsCa4uNzSIOYHoCjXlBo8CAFRu
 QoMTx0djfq5j1mxiEYVoYga0A.6K2FmfnQDHX_lx4bOxyPxMRSebQa3FxsF14fafllUcMPwng87G
 ZgmKr30mF6ikqDvOVfw7BkFT5rggdMSzDRLS8Ulh08uHnzfFePSdxWJnw.YBpIHs3DbBhVEczlvD
 entFIp6V2nAHFwv9a1OrDhjCqFqbrcrJCBiRYONonE6Qixsw8PEGNVtmw0lEgieKuBbAw7g.4hnE
 _bIR9iE2jpaSJRKk1_oOvNHe.zrypohiVbRE.hsqnNO7rawVdGOxTO_g8R6Scq8TTUq9a_x4f0dZ
 5GD4MZrUUl951Q9Lcx5U77if2t6W87MVzGTxk9lcrMlEC53VxdG5r6fQz3GYy4NhnN4yZIv_ZxCR
 rz6DqJMP75EpGheARc5BynMstvq11WNC1p9LjAlkBTSxJIMO4PCy1jxSp0DiU6_SfDJWfcl3c.mM
 hgskHsvHTBBU0U3FjF1_yxJIwqzd.YWneFXHpHGqmbbxLhX_JSaZ8gKD3OM0LdqYMtzCgM8QMcTa
 fdBGHfFkSROwNt1jZItT_xx_h3kF5F4YIroBsPlvbjK9TjpLuYJGF.0DVT7PLyv5l_CaEgfOweGy
 L3vfsgnYQvfUlZ22czcKNEN37rp5w7QAMtTFwLclFJZ6VZVPB1Dh4dBlBG7wFYUfJEm0S7yUgkl2
 alSXhu8fJvN0pPwBrc0JpTf0vmE.jJ2l9hscH1fk4fPMxspEyj7gYWE0kZeNeu26UeNyBx2wi8Ks
 288t1uo24.vQ9UQiFDepRkJ2DRt4n5UTv5vuWHzXjaegFeZFtv9aMdGDsoGCFhKh1vOyDcwBCK.a
 7QoFRffcNjtMi1vdoRpLqAUOwPrtiH3ogUN2clSY_41YP8yqCHS4mmzW.mx.BDACJVEpYi96bivB
 MmZ7SUDMD
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Dec 2022 20:38:39 +0000
Received: by hermes--production-bf1-5458f64d4-2b7vw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cff4e634a8158beb14140f71bf157374;
          Thu, 29 Dec 2022 20:38:33 +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.300.101.1.3\))
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
From: Mark Millard 
In-Reply-To: <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
Date: Thu, 29 Dec 2022 12:38:20 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
To: Mike Karels ,
 "Bjoern A. Zeeb" 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NjgG95KVvz3hfl
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


On Dec 29, 2022, at 11:39, Mike Karels  wrote:

> On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote:
>=20
>> Hi,
>>=20
>> does anyone else have the problem on latest main that the ue0 on an
>> rpi3b+ doesn't show up in time for the rc netif to configure it (or =
at
>> least it looks like)?
>=20
> I don=E2=80=99t see that problem.  I tried the 12/24 snapshot of main =
on an
> RPi3B+, and ue0 configured via DHCP on the initial boot, and on a =
reboot.

Are you also using EDK2's UEFI via the boot materials from:

https://github.com/pftf/RPi3/releases/tag/v1.38

instead of the using the normal FreeBSD ports used in official
builds (the RPi firmware and a U-Boot)? The "pfpt" RPi3 materials
include both RPi* firmware and the EDK2 based material.

Bjoern did not report enough information for the configuration
of that EDK2 based context to replicate his boot context in a
test.

I'll note that the intructions for that EDK2 variant indicate
that linux should not use ACPI but instead should use the
Device Tree. As I remember, the ACPI is documented somewhere
to follow some non-standard Microsoft specifics. (The RPi4
"pfpt" does not have the same issue.) Some related quotes
from https://github.com/pftf/RPi3 are:

QUOTE
With recent Linux installs, please assure that the
firmware is running in DT mode, either via
"Device Manager"->"Raspberry Pi Configuration"
->"Advanced Configuration"->"System Table Selection"
or the Linux/Grub command line with "acpi=3Doff".
END QUOTE

> I did have problems with the HDMI console, some of which are new; I =
will
> follow up on that separately.  Specifically, USB keyboard input =
didn=E2=80=99t
> work to the loader, and I didn=E2=80=99t see console output from =
user-level
> startup until I disabled boot_multicons and boot_serial.  The second
> problem is relatively new.
>=20
> Mike
>=20
>> While during boot USB seems to need a wait-delay now, which it hadn't =
in
>> the last years for me?
>>=20
>> =
------------------------------------------------------------------------
>> ...
>> Feeding entropy: .
>> ELF ldconfig path: /lib /usr/lib
>> ugen1.2:  at usbus1
>> uhub1 on uhub0
>> uhub1:  on usbus1
>> uhub1: MTT enabled
>> lo0: link state changed to UP
>> uhub1: 5 ports with 4 removable, self powered
>> ugen1.3:  at usbus1
>> smsc0 on uhub1
>> smsc0:  on =
usbus1
>> smsc0: chip 0xec00, rev. 0002
>> miibus0:  on smsc0
>> smscphy0:  PHY 1 on miibus0
>> smscphy0: OUI 0x00800f, model 0x000c, rev. 3
>> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0:  on smsc0
>> ue0: bpf attached
>> ue0: Ethernet address: xx:xx:xx:xx:xx:xx
>> Starting Network: lo0.
>> lo0: flags=3D8049 metric 0 mtu 16384
>> ...
>> =
------------------------------------------------------------------------
>>=20
>> If running manually after boot (again) it all works fine?
>>=20
>> # sh /etc/rc.d/netif start ue0
>> smsc0: chip 0xec00, rev. 0002
>> Starting Network: ue0.
>> ue0: flags=3D8843 metric 0 =
mtu 1500
>> ...
>>=20
>>=20
>>=20
>> Not that it should matter - this is with =
https://github.com/pftf/RPi3/releases/tag/v1.38
>>=20
>> /bz
>>=20
>> --=20
>> Bjoern A. Zeeb                                                     =
r15:7
>=20

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Dec 29 20:51:17 2022
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 4NjgXn5Xh2z2lDqM
	for ; Thu, 29 Dec 2022 20:51:21 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NjgXn3Q0cz3k2Q
	for ; Thu, 29 Dec 2022 20:51:21 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2BTKpKbJ072678;
	Thu, 29 Dec 2022 14:51:20 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.10] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id nj34DMj9rWPkGwEA4+wvSQ
	(envelope-from ); Thu, 29 Dec 2022 14:51:20 -0600
From: "Mike Karels" 
To: "Mark Millard" 
Cc: "Bjoern A. Zeeb" ,
        freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
Date: Thu, 29 Dec 2022 14:51:17 -0600
X-Mailer: MailMate (1.13.2r5673)
Message-ID: 
In-Reply-To: <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
 <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@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"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 2BTKpKbJ072678
X-Rspamd-Queue-Id: 4NjgXn3Q0cz3k2Q
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


On 29 Dec 2022, at 14:38, Mark Millard wrote:

> On Dec 29, 2022, at 11:39, Mike Karels  wrote:
>
>> On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote:
>>
>>> Hi,
>>>
>>> does anyone else have the problem on latest main that the ue0 on an
>>> rpi3b+ doesn't show up in time for the rc netif to configure it (or=20
>>> at
>>> least it looks like)?
>>
>> I don=E2=80=99t see that problem.  I tried the 12/24 snapshot of main =
on an
>> RPi3B+, and ue0 configured via DHCP on the initial boot, and on a=20
>> reboot.
>
> Are you also using EDK2's UEFI via the boot materials from:
>
> https://github.com/pftf/RPi3/releases/tag/v1.38
>
> instead of the using the normal FreeBSD ports used in official
> builds (the RPi firmware and a U-Boot)? The "pfpt" RPi3 materials
> include both RPi* firmware and the EDK2 based material.

No, this was the unmodified snapshot with the standard boot files
(and thus not UEFI).

		Mike

> Bjoern did not report enough information for the configuration
> of that EDK2 based context to replicate his boot context in a
> test.
>
> I'll note that the intructions for that EDK2 variant indicate
> that linux should not use ACPI but instead should use the
> Device Tree. As I remember, the ACPI is documented somewhere
> to follow some non-standard Microsoft specifics. (The RPi4
> "pfpt" does not have the same issue.) Some related quotes
> from https://github.com/pftf/RPi3 are:
>
> QUOTE
> With recent Linux installs, please assure that the
> firmware is running in DT mode, either via
> "Device Manager"->"Raspberry Pi Configuration"
> ->"Advanced Configuration"->"System Table Selection"
> or the Linux/Grub command line with "acpi=3Doff".
> END QUOTE
>
>> I did have problems with the HDMI console, some of which are new; I=20
>> will
>> follow up on that separately.  Specifically, USB keyboard input=20
>> didn=E2=80=99t
>> work to the loader, and I didn=E2=80=99t see console output from user-=
level
>> startup until I disabled boot_multicons and boot_serial.  The second
>> problem is relatively new.
>>
>> Mike
>>
>>> While during boot USB seems to need a wait-delay now, which it=20
>>> hadn't in
>>> the last years for me?
>>>
>>> ---------------------------------------------------------------------=
---
>>> ...
>>> Feeding entropy: .
>>> ELF ldconfig path: /lib /usr/lib
>>> ugen1.2:  at usbus1
>>> uhub1 on uhub0
>>> uhub1: >> 2> on usbus1
>>> uhub1: MTT enabled
>>> lo0: link state changed to UP
>>> uhub1: 5 ports with 4 removable, self powered
>>> ugen1.3:  at usbus1
>>> smsc0 on uhub1
>>> smsc0:  on=20
>>> usbus1
>>> smsc0: chip 0xec00, rev. 0002
>>> miibus0:  on smsc0
>>> smscphy0:  PHY 1 on miibus0
>>> smscphy0: OUI 0x00800f, model 0x000c, rev. 3
>>> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>>> ue0:  on smsc0
>>> ue0: bpf attached
>>> ue0: Ethernet address: xx:xx:xx:xx:xx:xx
>>> Starting Network: lo0.
>>> lo0: flags=3D8049 metric 0 mtu 16384
>>> ...
>>> ---------------------------------------------------------------------=
---
>>>
>>> If running manually after boot (again) it all works fine?
>>>
>>> # sh /etc/rc.d/netif start ue0
>>> smsc0: chip 0xec00, rev. 0002
>>> Starting Network: ue0.
>>> ue0: flags=3D8843 metric 0 mt=
u=20
>>> 1500
>>> ...
>>>
>>>
>>>
>>> Not that it should matter - this is with=20
>>> https://github.com/pftf/RPi3/releases/tag/v1.38
>>>
>>> /bz
>>>
>>> --=20
>>> Bjoern A. Zeeb                                                    =20
>>> r15:7
>>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com

From nobody Thu Dec 29 21:01:15 2022
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 4NjgmY3v8Pz2lGCn
	for ; Thu, 29 Dec 2022 21:01:33 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 4NjgmX0SK3z3mBP
	for ; Thu, 29 Dec 2022 21:01:31 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=NLuI1hlY;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.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=1672347689; bh=W9tPogRIhfsnBgJ4Z1wFnM3m5LnK+VYURy7238Riz8Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NLuI1hlYzeQJYVjVrBQIUEX3ub7bTGqdvQecaw6NDZoJQ3SVeURkgbvLZNYFomlfrjIcULyUwoggE1vTE/MF07VTXSyzJM5hpVpeC2G4YXo6rpyitQURR24UXL+V1i6LnJrvOzTAfhK3+Ni7EMhQS+20Tl6yenn4SOsmsf/cJN9ptbjDos5z4i7kjxbOPf0/+Pnj335ZyoOgpFhx7nUOn4J3jShrqqtGkKml1I5048qeRMkfLwrhU/YRUDg6lQ7eIkaHZAKwonXABHHYL01DYC3X/nX/SQBZDafB0plUFlXxP3i72MqSUQYXqIVhWiQwxd5+oLuQwWIe70InRu9cqg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672347689; bh=0MN3VqRX6DpIlF7D4gTRnMzHipAnUyqEc3WQFggls0l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=duWPfEPQq9BUO5rX8XMm5gGv9wtgqY619FoeNGr/gG8IyE0mTRXthqDNCrBPZxkFJjCLjvKSZIXzo1dbI9L2vNrIYsWYZ08hy5s/Bz+fwqLyxdBk43yhQ/Lkn80Xu16SuYbj34xr0lCJbjWrc7quzIQy0JAOP5CM95qHIWEw8Goo5l2B+ujl/18yRItaqmmFw05j6yHliuRtu7wp80phV5gOl+bTtV4SSOv+Af0mu9Yxju8k+B+u2W1xJAYZKdAqtAKkk7OkK1S8w9F6Lce0ZZTYWdgp7Av1rfJM6g/jtzd3tnYby8+ebhnqr83NPxfYdPKGtOnxu+cOviOPYBd04g==
X-YMail-OSG: .fphdzcVM1l6fy4oVy5a06ZyWraLwGH61rfZ4B6rWJVKSnmme8E_W2vUCWmeWyW
 RbWEpL4Cq73AeocJdtEyBt.JS5Tv.XdoD3OYelleajTM_NnFvz.b1suelqZa7bnvtC0s6eMvPqJG
 heAvB2jUvUMHLcR36IqwK9J3r1zZSUhBahpOu7dXn3pCBXGzGLpgnWJGDxdE9Uhfm270QUzEP6Az
 sGKDUITZk84KZSqJRjdMRR8Oh.3FduP4zJwG78unMIS3P2JoAncSpNMWJ6kHo8c.Ol8_CKU7yYhr
 jD_j5ByH8zP3GHE1XaLhu9aR0A4hHEz3SCDCfABNjG4J7RihhyTDjbml1.0J1XO5anNJ3jayZlN5
 kDBZ89RMVUX61sNUPNx7P.pLUbtaqp9v9TU4LEIxBT2hB5vmFXUafnbAGPAm1q_nztmaLsShAxlm
 uxawmUlfX3yQQBFlhVG8LYxAe6o3y8_O55n03p_N6QGPrpk9W40K3inqpzLAGl9zCuQkR33s.fPu
 ohJaWHrjuUbiCrZ.LwpewVS3OuKzmcr12fZBc5DAuDiPQyGZ2ta3vTjmNxcGPCGufOnRcmy_ss3Y
 97uRg0AHoqgsv04JUbOnV8EaG8i3aldzMv2Sf_fTzb_W3CsT.iqMF39cz0kgf5r5OaeGk0zYeZbN
 2BaiR8CKE_OHjChHh05Nq6lJwOR.qxm4mWtK089swioR7fO1.qXqm0NFJunyVrwxjbU8mlscR9JX
 b4VT7aeuBlZtHmKfQyxAMg3XEV46e0g9mEWckIAB9Iywj0IwVL3FfVaVncoQqZaAqzq.EFFz4wmG
 gpjMr9XzzwT1xFWn7nVy9LJOXPU3PVkpt4Z9Qbof5rt58hVP5AC7VW2wkud4jHt5Ux7w91.nQQGE
 UOUfvsgIwnx.zCH4zf4HVCirT5USSc42cKMzjdJCJMrLnvWiljaCzMYvtNs7sgpABd.MkCa01_HG
 kvG7EI0zvmoPNmvGlu2YlQaPUjTd4EbXjR4PvpD.BDDMmjYjCdiyY9eIzKeON4T8er6dK9IFHLCY
 rsMlB_6Z4ZgLbJPqHi4Hnudwu20PcXA6jfhyCA7UqZiFekUqTxLvpFH2J.iBBq8IzT5Jr.n4XpL7
 H9C6thljKWRrc3w8h4DVZcDQy.WH76_5_tlz4soURUUUMJtNXGMIeTLK6N4dVbWwPrkzgPZWPiC0
 MAdNPmmIe8OJXt2B4pi8zLHQzCfTyCKpij8CuK9gahBqG5B0cjLIk2wtJUggUXuM3dgLgf2m..pj
 9V3BV1CAUGdJ.PKv5cnAqtBxWKIQcq0ZvZxzKk1JKwJiC1BH.gebPXRJZp5RYgbTo_NAmvKgTowC
 WlTvG_mYfh1IHbFMD5n_UdUJHnWs5ZNneKJ4v6g1AXvhsq2HqbTh1x.UyEX_9MNQGUT0FzPXUVUy
 sweOH9GP8dOkoM2EQYu2w.Nbl8HgbFkMzMerDEnsgaPb.6L7JYZ__2lgWkTbgNP.5iPlFmGURV6B
 r5nYjLHEPBUH2kDQ.32Lxb5A7IkzlG0NnhHKacL7TelkZ5isL0oSz7rFZ85lKCeCgdYMdf0zxOgY
 TPEzEVFc2ew0ZgoJ3m16ghqYljc0FB3lahULq5G5PEmqcSkTibz6P1DAmOEVH1NvX2l_ja3_oAtj
 vFf4JZbXZXCrX59JwiNIp8SmAay5DciNxtpmDILsehqmJNrxQ99qVZeJMI_5O760sNPFgs36OO5v
 dghNWS5_P3DMDma93XC5yFAhBIrPqrEb3UpiFCVk1p5N_40DGtUkzHn7G8HRSO5u4zdAdO.GOb1c
 KsTG93J9geG9t6NPyUID73IVpUHioGfehUGF1.1fhu07RIyaziUf2yrJDdXQ_K66kMPi.KPuauYh
 dwNRfl.bDhd.vBRH_AmTcBG3U3t3bcbBT24yatns29PpfrksKSLc1nY_rCtwOL1H60Mgv4gPTtCU
 4.SWedH1b_jiCp1GOmo_OHCrpO5Mss6jbmC8FCVSiGRqLg3W8jjlzXnJt67dvfq4pVG2ue37.e.I
 Drsxtd9TPspsV.xfV2scmidfky7NsiEPyGY._YLVSshxKj.96kZRezSeHYXTcuwArKjAc6uqhVzi
 VGwrUvtDA7smzDhveBthBeeu5BMmGrVHzlwU0SHXyRS1PdF6lH1uXGYL6eqyBpQLBBLEL1yEyvQJ
 xVER4bk1C7zPusG1nDq4qV75r_fggHct0yNJj2CmeadyucsVaM9u5fR69mFoAdLrOln2pKNotYFe
 .qcaS0hJNZyJIviv1sP.mr76t4hgQ7PWYCGx7OF19SkKKpwm.Fhr2wPHaTvCqijyw8CcmE4IGMAy
 KZQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Dec 2022 21:01:29 +0000
Received: by hermes--production-bf1-5458f64d4-x4bxm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e416c4cede44aab416edf42880819dcd;
          Thu, 29 Dec 2022 21:01:27 +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.300.101.1.3\))
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
From: Mark Millard 
In-Reply-To: <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
Date: Thu, 29 Dec 2022 13:01:15 -0800
Cc: "Bjoern A. Zeeb" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9254A30E-B974-4DFD-B428-D1037BDDF1AB@yahoo.com>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
 <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
To: freebsd-arm 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-0.66 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	NEURAL_SPAM_MEDIUM(0.83)[0.829];
	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];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NjgmX0SK3z3mBP
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

On Dec 29, 2022, at 12:38, Mark Millard  wrote:

> On Dec 29, 2022, at 11:39, Mike Karels  wrote:
>=20
>> On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote:
>>=20
>>> Hi,
>>>=20
>>> does anyone else have the problem on latest main that the ue0 on an
>>> rpi3b+ doesn't show up in time for the rc netif to configure it (or =
at
>>> least it looks like)?
>>=20
>> I don=E2=80=99t see that problem.  I tried the 12/24 snapshot of main =
on an
>> RPi3B+, and ue0 configured via DHCP on the initial boot, and on a =
reboot.
>=20
> Are you also using EDK2's UEFI via the boot materials from:
>=20
> https://github.com/pftf/RPi3/releases/tag/v1.38
>=20
> instead of the using the normal FreeBSD ports used in official
> builds (the RPi firmware and a U-Boot)? The "pfpt" RPi3 materials
> include both RPi* firmware and the EDK2 based material.
>=20
> Bjoern did not report enough information for the configuration
> of that EDK2 based context to replicate his boot context in a
> test.
>=20
> I'll note that the intructions for that EDK2 variant indicate
> that linux should not use ACPI but instead should use the
> Device Tree. As I remember, the ACPI is documented somewhere
> to follow some non-standard Microsoft specifics. (The RPi4
> "pfpt" does not have the same issue.) Some related quotes
> from https://github.com/pftf/RPi3 are:
>=20
> QUOTE
> With recent Linux installs, please assure that the
> firmware is running in DT mode, either via
> "Device Manager"->"Raspberry Pi Configuration"
> ->"Advanced Configuration"->"System Table Selection"
> or the Linux/Grub command line with "acpi=3Doff".
> END QUOTE
>=20

I found the text about not being ACPI compliant:

=
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Raspberry=
Pi/RPi3

reports:

QUOTE
ACPI

. . .

Note that the ACPI tables were derived or copied from
the MS-IoT one. This means that they are not truly ACPI
compliant, especially when it comes to their descriptors,
and therefore not suitable for Linux environments. If
you want to use a Linux HLOS, you are encouraged tp
install a kernel that relies on Device Tree rather than
ACPI.
END QUOTE

>> I did have problems with the HDMI console, some of which are new; I =
will
>> follow up on that separately.  Specifically, USB keyboard input =
didn=E2=80=99t
>> work to the loader, and I didn=E2=80=99t see console output from =
user-level
>> startup until I disabled boot_multicons and boot_serial.  The second
>> problem is relatively new.
>>=20
>> Mike
>>=20
>>> While during boot USB seems to need a wait-delay now, which it =
hadn't in
>>> the last years for me?
>>>=20
>>> =
------------------------------------------------------------------------
>>> ...
>>> Feeding entropy: .
>>> ELF ldconfig path: /lib /usr/lib
>>> ugen1.2:  at usbus1
>>> uhub1 on uhub0
>>> uhub1:  on usbus1
>>> uhub1: MTT enabled
>>> lo0: link state changed to UP
>>> uhub1: 5 ports with 4 removable, self powered
>>> ugen1.3:  at usbus1
>>> smsc0 on uhub1
>>> smsc0:  on =
usbus1
>>> smsc0: chip 0xec00, rev. 0002
>>> miibus0:  on smsc0
>>> smscphy0:  PHY 1 on miibus0
>>> smscphy0: OUI 0x00800f, model 0x000c, rev. 3
>>> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>>> ue0:  on smsc0
>>> ue0: bpf attached
>>> ue0: Ethernet address: xx:xx:xx:xx:xx:xx
>>> Starting Network: lo0.
>>> lo0: flags=3D8049 metric 0 mtu 16384
>>> ...
>>> =
------------------------------------------------------------------------
>>>=20
>>> If running manually after boot (again) it all works fine?
>>>=20
>>> # sh /etc/rc.d/netif start ue0
>>> smsc0: chip 0xec00, rev. 0002
>>> Starting Network: ue0.
>>> ue0: flags=3D8843 metric 0 =
mtu 1500
>>> ...
>>>=20
>>>=20
>>>=20
>>> Not that it should matter - this is with =
https://github.com/pftf/RPi3/releases/tag/v1.38
>>>=20
>>> /bz
>>>=20
>>> --=20
>>> Bjoern A. Zeeb                                                     =
r15:7
>>=20
>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Dec 30 22:03:34 2022
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 4NkK5y6rZYz2nV4C
	for ; Fri, 30 Dec 2022 22:03:50 +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" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NkK5x3drSz3qLd
	for ; Fri, 30 Dec 2022 22:03:49 +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 12EC08D4A169;
	Fri, 30 Dec 2022 22:03:39 +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 5B2A75C3A833;
	Fri, 30 Dec 2022 22:03:39 +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 sBAavw0KQBf7; Fri, 30 Dec 2022 22:03:37 +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 AE6C45C3A830;
	Fri, 30 Dec 2022 22:03:35 +0000 (UTC)
Date: Fri, 30 Dec 2022 22:03:34 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Mark Millard 
cc: Mike Karels , freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
In-Reply-To: <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
Message-ID: 
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg> <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net> <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
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 [-2.27 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.97)[-0.973];
	R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	FREEMAIL_TO(0.00)[yahoo.com];
	TO_DN_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[zabbadoz.net];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+]
X-Rspamd-Queue-Id: 4NkK5x3drSz3qLd
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 29 Dec 2022, Mark Millard wrote:

> Bjoern did not report enough information for the configuration
> of that EDK2 based context to replicate his boot context in a
> test.

Sorry, I applied the config.txt change from the open pull request there
where I left a comment a year or so ago.  I was running with the
previous version quite fine.

I did disable ACPI for a change in the setup.  No idea how that would be
persistent.

I used to run with the previous version but loader now panics on that so I
found the fairly recent new one.

I also have my own kernel admittingly; same builds on years because I
run them with a memory disk.

The GE switch port are on auto but given this is USB device attaching
time it seem that shouldn't make the huge difference (and I checked that
it wa on an auto-port before and so is my other one).

In either way, @mike, does your boot indiciate that ue0 is setup during
the first netif run or is devd doing it later for you and it'd be there
by the time you login)?  Just checking before I'll put it onto the TODO
list to one day dig deeper.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Fri Dec 30 22:16:38 2022
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 4NkKNs6Kllz1LfgX
	for ; Fri, 30 Dec 2022 22:16:45 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NkKNs3sWgz3r4J
	for ; Fri, 30 Dec 2022 22:16:45 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2BUMGdWi091666;
	Fri, 30 Dec 2022 16:16:39 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id Ou7VF0djr2MQZgEA4+wvSQ
	(envelope-from ); Fri, 30 Dec 2022 16:16:39 -0600
From: Mike Karels 
To: "Bjoern A. Zeeb" 
Cc: Mark Millard , freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
Date: Fri, 30 Dec 2022 16:16:38 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <4AF80D6A-B421-4D1D-ADEA-5F4439A74E43@karels.net>
In-Reply-To: 
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
 <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@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: quoted-printable
X-Rspamd-Queue-Id: 4NkKNs3sWgz3r4J
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 30 Dec 2022, at 16:03, Bjoern A. Zeeb wrote:

> On Thu, 29 Dec 2022, Mark Millard wrote:
>
>> Bjoern did not report enough information for the configuration
>> of that EDK2 based context to replicate his boot context in a
>> test.
>
> Sorry, I applied the config.txt change from the open pull request there=

> where I left a comment a year or so ago.  I was running with the
> previous version quite fine.
>
> I did disable ACPI for a change in the setup.  No idea how that would b=
e
> persistent.
>
> I used to run with the previous version but loader now panics on that s=
o I
> found the fairly recent new one.
>
> I also have my own kernel admittingly; same builds on years because I
> run them with a memory disk.
>
> The GE switch port are on auto but given this is USB device attaching
> time it seem that shouldn't make the huge difference (and I checked tha=
t
> it wa on an auto-port before and so is my other one).
>
> In either way, @mike, does your boot indiciate that ue0 is setup during=

> the first netif run or is devd doing it later for you and it'd be there=

> by the time you login)?  Just checking before I'll put it onto the TODO=

> list to one day dig deeper.

I think it was at the normal time (netif), according to the console
output.  I=E2=80=99ll double-check later.

		Mike

> /bz
>
> -- =

> Bjoern A. Zeeb                                                     r15:=
7

From nobody Sat Dec 31 00:29:10 2022
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 4NkNKf5JTVz2krp7
	for ; Sat, 31 Dec 2022 00:29:10 +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 4NkNKf2nXLz42DY
	for ; Sat, 31 Dec 2022 00:29:10 +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=1672446550;
	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=Qo2WlxJoylJlQPalzOYfvVQTqMRwfAHvz7g3OjW+pyE=;
	b=xbDbmMGbYaMADD6k7dE/r+PSKluQoqwuZgibM+NQHucUyLRaegYzffo/DJK88YMO9x7l8b
	y2qussOvxkfXQ9y/3uZecncLGtiTsfrnT+vfxtry0mcLBIcj8+TSP8+VV7mgRTvzJxFlRW
	UVt6BVtnqJ5Mcp6E6/ATsDk53uXc76TSYyvKO3mcVIUc/LsO/MTuYbVZ78fareb1thlmuv
	p4AFMyR2sg2mWrk5r2qD3nXI07ncwmvhn6A/cz9xZq2w/i2HDbz6ze9iHOcK/Mronlj25c
	yXCAD1+uZYdyXnq6FobY69ranbzTyqZJ6RBFSjKhsWYvGVkYSl3MvHirZDfbkA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672446550; a=rsa-sha256; cv=none;
	b=Gtvwa7VMjKy7V05PmlHKk4d6VtoH/OHpHsTdDMqWtml222DFaeTh5phh70E6Q8SwdUSHki
	KT0rGUFYq4CoHq1QM9gn6Am2L6w1IyCA8rMrzDsxMrIqJFCdIBniMFVk6uZ18GagjOdEa2
	QfNXeBETLHZ2A5zGCO8tjkFdbLuFKD8deboUAPaEAh21BfBaMKEdPsmuy/C71gZ8opr8ic
	3SMokH5gLwhaShutj+t0NBW9N/fEvhmFnR+vjzQUw3umaT4Q+fAQP5yoXV5iSUrCA+Ibwi
	5S5RjnM1qQ1+6TWQKVM0bt7pjG/oTGMkGma8Y9Nkd9S4q0hhGidK+Wq6sFTXzQ==
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 4NkNKf1s2PzSrv
	for ; Sat, 31 Dec 2022 00:29:10 +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 2BV0TAZ2018464
	for ; Sat, 31 Dec 2022 00:29:10 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2BV0TAVi018462
	for freebsd-arm@FreeBSD.org; Sat, 31 Dec 2022 00:29:10 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 268660] RPI4 8GB floating issue - booting failed from USB HDD
 connected on SupTronics X825 board
Date: Sat, 31 Dec 2022 00:29:10 +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: 13.1-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: k.musorin@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
X-ThisMailContainsUnwantedMimeParts: N

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268660

            Bug ID: 268660
           Summary: RPI4 8GB floating issue - booting failed from USB HDD
                    connected on SupTronics X825 board
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: k.musorin@gmail.com

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sat Dec 31 04:17:28 2022
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 4NkTPK1yzpz2lQLn
	for ; Sat, 31 Dec 2022 04:17:41 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	(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 4NkTPJ6h45z3FdJ
	for ; Sat, 31 Dec 2022 04:17:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x534.google.com with SMTP id u28so28037114edd.10
        for ; Fri, 30 Dec 2022 20:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=u7Fi4iagUvhKtpecuDSW934MexVwOe7s+UNncvAs+KU=;
        b=B54mlkGNJkM8lR89mNg1gbbde46RQOV7zdBlmTmQwhIAjPKZeM1HHZKOyVhU62OmfM
         F0YkAj2N0mv0NYY2pMKPh52sCUQkQMcLFGnQukv4awAnXZEBL1I4B/zwwv6alF+sQ4Vx
         Q+dEdHax6NFzhGO1ZVaEkbK5ehkzOr5UffSbcOgGgeZA40BK2Lll6mPqQqz4uK/HEVM3
         te8XG4g3vbdo6MDquvDiVoPBeIaC6yOW8j4of8o2t8Jgf1KwB2Hxznwd5fMWVIbzxn6Q
         qUJdgIswNGmc/72ssQ4bJs/994EEVjIIs0dqnd8jyt5wUR4auML5Hh8iprmtPmJ0BTBO
         KCgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=u7Fi4iagUvhKtpecuDSW934MexVwOe7s+UNncvAs+KU=;
        b=Gu7h8HRknKdy9zV5O0ERvLjNN3nXZm31Sci9HK7EN5xft9SqJowPaNm2yT1Wvyp492
         KLAiHtqAfiAT0L0Obhf69gYXMffWMaAHJ1/6lOryBHEIxc46sr1ItlGJKv6hpgnGaH2q
         kx8o5o5FUWPnnLtl4FBNXK6/PuwZBq97gbF9gxrc0RdZVY0bqqR78GfTnFkgRlLgQPnG
         DlF7kS7llkwJeIpAdIs4ObjPEMJ2L0y/mzYfFBgC7D9ToF/PwivrZURYdDRWxla3rw92
         GajLE/moCvnnXWiYTa9eIjx+WRIJV2Aqz1VgtH/ld79o2xe5wSxDsmH+gZu5uvA+QyBB
         xZsQ==
X-Gm-Message-State: AFqh2kp6MrGfYD5bU66MkT8s74Ko5K0B27jIDbMilE6YPgxhYDJWzdM7
	/lgQv7IdF/+XnumMAgUw1/WBzkg+3MRPgPf+hUiJBw==
X-Google-Smtp-Source: AMrXdXvI9bEz4ilsYhDc5CGxAghfl62ixzpsz2OXZ9nf5QLhFCzoR5+6kbBo6c4+jPuuGjdRLDNOhFCHWJtS/oR76fY=
X-Received: by 2002:a05:6402:2985:b0:486:ecf1:b6fb with SMTP id
 eq5-20020a056402298500b00486ecf1b6fbmr1641665edb.48.1672460259584; Fri, 30
 Dec 2022 20:17:39 -0800 (PST)
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: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net> <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
 
In-Reply-To: 
From: Warner Losh 
Date: Fri, 30 Dec 2022 21:17:28 -0700
Message-ID: 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
To: "Bjoern A. Zeeb" 
Cc: Mark Millard , Mike Karels , 
	freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000ac863d05f117ff42"
X-Rspamd-Queue-Id: 4NkTPJ6h45z3FdJ
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ac863d05f117ff42
Content-Type: text/plain; charset="UTF-8"

On Fri, Dec 30, 2022, 3:03 PM Bjoern A. Zeeb 
wrote:

> On Thu, 29 Dec 2022, Mark Millard wrote:
>
> > Bjoern did not report enough information for the configuration
> > of that EDK2 based context to replicate his boot context in a
> > test.
>
> Sorry, I applied the config.txt change from the open pull request there
> where I left a comment a year or so ago.  I was running with the
> previous version quite fine.
>
> I did disable ACPI for a change in the setup.  No idea how that would be
> persistent.
>
> I used to run with the previous version but loader now panics on that so I
> found the fairly recent new one.
>
> I also have my own kernel admittingly; same builds on years because I
> run them with a memory disk.
>
> The GE switch port are on auto but given this is USB device attaching
> time it seem that shouldn't make the huge difference (and I checked that
> it wa on an auto-port before and so is my other one).
>
> In either way, @mike, does your boot indiciate that ue0 is setup during
> the first netif run or is devd doing it later for you and it'd be there
> by the time you login)?  Just checking before I'll put it onto the TODO
> list to one day dig deeper.
>

In the mean time you can add ue to re regular expression for removable
devices, you might be able to use devd to configure them when they become
available using the now lamely named pccard_ether...

We likely should add a wait usb command to rc since that would solve a lot
of issues with zfs startup racing umass discovery.

Warner

/bz
>
> --
> Bjoern A. Zeeb                                                     r15:7
>
>

--000000000000ac863d05f117ff42
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Dec 30, 2022, 3:03 PM Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net=
> wrote:
On Thu, 29 Dec 2022=
, Mark Millard wrote:



> Bjoern did not report enough information for the configuration

> of that EDK2 based context to replicate his boot context in a

> test.



Sorry, I applied the config.txt change from the open pull request there

where I left a comment a year or so ago.=C2=A0 I was running with the

previous version quite fine.



I did disable ACPI for a change in the setup.=C2=A0 No idea how that would =
be

persistent.



I used to run with the previous version but loader now panics on that so I<=
br>
found the fairly recent new one.



I also have my own kernel admittingly; same builds on years because I

run them with a memory disk.



The GE switch port are on auto but given this is USB device attaching

time it seem that shouldn't make the huge difference (and I checked tha=
t

it wa on an auto-port before and so is my other one).



In either way, @mike, does your boot indiciate that ue0 is setup during

the first netif run or is devd doing it later for you and it'd be there=


by the time you login)?=C2=A0 Just checking before I'll put it onto the=
 TODO

list to one day dig deeper.
<=
br>
In the mean time you can add ue to re regular ex=
pression for removable devices, you might be able to use devd to configure =
them when they become available using the now lamely named pccard_ether...<=
/div>

We likely should add a w=
ait usb command to rc since that would solve a lot of issues with zfs start=
up racing umass discovery.=C2=A0

Warner


/bz



-- 

Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7






--000000000000ac863d05f117ff42--

From nobody Sun Jan  1 12:49: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 4NlJjB0b6Hz2nWpB
	for ; Sun,  1 Jan 2023 12:49:18 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smtpq4.tb.mail.iss.as9143.net (smtpq4.tb.mail.iss.as9143.net [212.54.42.167])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NlJj860wkz47mf
	for ; Sun,  1 Jan 2023 12:49:16 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 212.54.42.167 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws;
	dmarc=pass (policy=quarantine) header.from=klop.ws
Received: from [212.54.42.105] (helo=smtp1.tb.mail.iss.as9143.net)
	by smtpq4.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	(envelope-from )
	id 1pBxm5-0000t7-H4
	for freebsd-arm@freebsd.org; Sun, 01 Jan 2023 13:49:13 +0100
Received: from [192.168.1.109] ([84.105.120.103])
	by smtp1.tb.mail.iss.as9143.net with ESMTPA
	id Bxm4pysYp96ZOBxm5pCClR; Sun, 01 Jan 2023 13:49:13 +0100
X-Env-Mailfrom: ronald-lists@klop.ws
X-Env-Rcptto: freebsd-arm@freebsd.org
X-SourceIP: 84.105.120.103
X-CNFS-Analysis: v=2.4 cv=R/rFW/dX c=1 sm=1 tr=0 ts=63b18149 cx=a_exe
 a=XM3BzkzqYrJMy9Upcw2wOA==:117 a=XM3BzkzqYrJMy9Upcw2wOA==:17
 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=0EyHQldr3sIA:10
 a=T8hboYP3AAAA:8 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=dGt58QBZTcB6PLfxPeAA:9
 a=QEXdDO2ut3YA:10 a=3Xhr1e3L9Km7VwPPQCJS:22 a=IjZwj45LgO3ly-622nXo:22
X-Authenticated-Sender: emnvandam@casema.nl
Message-ID: 
Date: Sun, 1 Jan 2023 13:49:12 +0100
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.6.1
Subject: Re: lsof crashes in Arm Optimized Routines
To: Mark Millard 
Cc: "freebsd-arm@freebsd.org" ,
 Andrew Turner 
References: <1331707040.259440.1668459233836@localhost>
 <490902644.115954.1668511998644@localhost>
 <690511F4-25A6-41E8-A75A-FFE80C352DFA@yahoo.com>
Content-Language: en-US
From: Ronald Klop 
In-Reply-To: <690511F4-25A6-41E8-A75A-FFE80C352DFA@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfGMg7mKgtYpM8l76ssDWRu/dXgK2fmmwOFEDkWsE8K8YJSqF+Ni1hKJn9PEZZpIRFW1nc11JvTuC0nt9Equ5Jlez4YxS7SkmV/LDv7zx1W4ZgZRIKp9b
 myPzpAQ3rCLmHx/e+o0IiZijRFIasoaBeKiW33id7MBDPtbShFsZfKQogzxH912F885N+YgQ3iyi7++YWEDBO+dJYdcxx73bDQP3GzN+UMhY2Y+7lEjuvWGd
 BFmrwyMMKVAT8DxUGVC5Sg==
X-Spamd-Result: default: False [-3.72 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.82)[-0.824];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	R_SPF_ALLOW(-0.20)[+ip4:212.54.32.0/19];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[212.54.42.167:from];
	RCVD_IN_DNSWL_NONE(0.00)[212.54.42.105:received];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	HAS_X_AS(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL];
	R_DKIM_NA(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[212.54.42.167:from]
X-Rspamd-Queue-Id: 4NlJj860wkz47mf
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 11/18/22 01:57, Mark Millard wrote:
>> On Nov 15, 2022, at 03:33, Ronald Klop  wrote:
>>
>> Sorry for the noise.
>>
>> But I cannot reproduce this today. I can scroll back in my terminal and see the command and error from yesterday, but running the same again just works.
> 
> FYI:
> 
> I do not have specifics any more, but I'll note that I've seen
> such lsof behavior of failing at one time and later working
> without any installed updates to it or the system between. I
> rarely use lsof and, so, this was not recently.
> 
> I've no clue how to cause the failure(s) to show up. I've no
> clue how common the issue is. But, over time, it is not just
> you.
> 
>>
>> Van: Ronald Klop 
>> Datum: maandag, 14 november 2022 21:53
>> Aan: freebsd-arm@FreeBSD.org, Andrew Turner 
>> Onderwerp: lsof crashes in Arm Optimized Routines
>> Hi,
>>
>> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267760 : Segmentation fault in lsof. Program received signal SIGSEGV, Segmentation fault.
>> Invalid permissions for mapped object.
>> memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:175
>> 175 stp D_l, D_h, [dst, 64]!
>>
>> I also remembered this change: https://cgit.freebsd.org/src/log/contrib/arm-optimized-routines?showmsg=1 about Arm Optimized Routines.
>>
>> Could this be related? What can I do to help debug this?
>>
> 
> 
>    
> ===
> Mark Millard
> marklmi at yahoo.com
> 


I'm having this issue again.

No debugging symbols found in lsof)
(gdb) run
Starting program: /usr/local/sbin/lsof

Program received signal SIGSEGV, Segmentation fault.
Invalid permissions for mapped object.
memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:171
bt
171             stp     B_l, B_h, [dst, 32]
(gdb) bt
#0  memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/string/aarch64/memcpy.S:171
#1  0x0000000000218be4 in ?? ()
#2  0x0000000400000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


Some output of "truss -o /tmp/lsof.txt lsof":

__sysctl("kern.proc.filedesc.1",4,0x0,0x80ba06f0,0x0,0) = 0 (0x0)
__sysctl("kern.proc.filedesc.1",4,0x851d6000,0x80ba06f0,0x0,0) = 0 (0x0)
__sysctl("kern.proc.filedesc.385",4,0x0,0x80ba06f0,0x0,0) = 0 (0x0)
__sysctl("kern.proc.filedesc.385",4,0x8516ec00,0x80ba06f0,0x0,0) = 0 (0x0)
__sysctl("kern.proc.filedesc.97537",4,0x0,0x80ba06f0,0x0,0) = 0 (0x0)
__sysctl("kern.proc.filedesc.97537",4,0x8516ec00,0x80ba06f0,0x0,0) = 0 (0x0)
statfs("/data/jails/jail13/_root/home/root/dev/workspace/FreeBSD-Ports-13/_root/usr/local/poudriere/data/.m/freebsd13-custom/04/bin/sh",{ fstypename=nullfs,mntonname=/data/jails/jail13/_root/home,mntfromname=/data/jails/_home,fsid=3cff022929000000 }) = 0 (0x0)
statfs("/data/jails/jail13/_root",{ fstypename=nullfs,mntonname=/data/jails/jail13/_root,mntfromname=/data/jails/freebsd13,fsid=37ff022929000000 }) = 0 (0x0)
statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/local/poudriere/data/.m/freebsd13-custom/04/bin/sh",0x80b9ef40) ERR#2 'No such file or directory'
statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/local/poudriere/data/.m/freebsd13-custom/04/wrkdirs/usr/ports/devel/cmake-core/work/cmake-3.24.3/Source",0x80b9ef40) ERR#2 'No such file or directory'
statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/local/poudriere/data/.m/freebsd13-custom/04",0x80b9ef40) ERR#2 'No such file or directory'
statfs("/data/jails/freebsd13ovt",0x80b9ef40)    ERR#2 'No such file or directory'
SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=36 addr=0x80ba1000
process killed, signal = 11 (core dumped)


I'm surprised that the path names in the truss output are corrupted: _home3root should be _home/root.

NB: I'm using lsof while running poudriere in a jail in a Jenkins agent.

Regards,
Ronald.


From nobody Sun Jan  1 16:45:22 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 4NlPxc6ZfKz2lBSY
	for ; Sun,  1 Jan 2023 16:45:24 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1])
	(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 "fuz.su", Issuer "fuz.su" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NlPxc2n6yz3HZH
	for ; Sun,  1 Jan 2023 16:45:24 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su;
	dmarc=none
Received: from fuz.su (localhost [127.0.0.1])
	by fuz.su (8.16.1/8.16.1) with ESMTPS id 301GjMKD076107
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sun, 1 Jan 2023 16:45:23 GMT
	(envelope-from fuz@fuz.su)
Received: (from fuz@localhost)
	by fuz.su (8.16.1/8.16.1/Submit) id 301GjMIC076106
	for freebsd-arm@freebsd.org; Sun, 1 Jan 2023 17:45:22 +0100 (CET)
	(envelope-from fuz)
Date: Sun, 1 Jan 2023 17:45:22 +0100
From: Robert Clausecker 
To: freebsd-arm@freebsd.org
Subject: Volterra Dev Kit Updates
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 [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:c];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	DMARC_NA(0.00)[fuz.su];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NlPxc2n6yz3HZH
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Greetings and happy new year!

Got around to do some debugging on the Volterra Dev Kit today.
Allan Jude had previously patched up the boot loader a little so
it gets to the point where it shows you the menu and lets you
type in commands.  The last known state of affairs was "boot loader
gets to the point where it boots the kernel, but kernel hangs
without any further output."

My tests are based on 89ffac3b with D37765, D37766, and D47767
applied.

It seems that the boot loader is still wonky; there's radio
silence from the kernel because it doesn't actually boot!

Some printf() debugging later, I noticed that the boot loader
hangs in bi_load_efi_data(), specifically in the BS->GetMemoryMap()
loop.  I've added some printf() calls therein and now it no longer
hangs -.-  ketas in #bsdmips suggested that there migth be some
sort of race condition going on.

Anyway, we are then greeted with an "ExitBootServices error 2"
but the boot continues.  It finally jumps into the kernel, but
there is an immediate fault at the entry point:

Synchronous Exeption at 0x0000000C7C000800

Looks like the whole memory management is still wonky.  With just
a random guess, could it be that the loader tries to map the kernel
W+X to be able to load and then execute it, which the EFI
implementation doesn't like, just like it didn't like that with the
boot loader itself?

I'll try to continue to investigate, but unfortunately I know very
little about this stuff.

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From nobody Sun Jan  1 17:13: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 4NlQYt72V5z2lGyh
	for ; Sun,  1 Jan 2023 17:13:22 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1])
	(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 "fuz.su", Issuer "fuz.su" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NlQYt19Zdz3MG3
	for ; Sun,  1 Jan 2023 17:13:22 +0000 (UTC)
	(envelope-from fuz@fuz.su)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su;
	dmarc=none
Received: from fuz.su (localhost [127.0.0.1])
	by fuz.su (8.16.1/8.16.1) with ESMTPS id 301HDKOW076248
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sun, 1 Jan 2023 17:13:20 GMT
	(envelope-from fuz@fuz.su)
Received: (from fuz@localhost)
	by fuz.su (8.16.1/8.16.1/Submit) id 301HDKmg076247
	for freebsd-arm@freebsd.org; Sun, 1 Jan 2023 18:13:20 +0100 (CET)
	(envelope-from fuz)
Date: Sun, 1 Jan 2023 18:13:20 +0100
From: Robert Clausecker 
To: freebsd-arm@freebsd.org
Subject: Re: Volterra Dev Kit Updates
Message-ID: 
References: 
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-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+a];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	DMARC_NA(0.00)[fuz.su];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NlQYt19Zdz3MG3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Further update:

_andy_t_ from #bsdmips suggested to replace all instances of
EfiLoaderData in stand/efi/loader/copy.c with EfiLoaderCode.
With this change, there is no longer a synchronous exception,
the boot just hangs completely after entering the kernel.

Yours,
Robert Clausecker

Am Sun, Jan 01, 2023 at 05:45:22PM +0100 schrieb Robert Clausecker:
> Greetings and happy new year!
> 
> Got around to do some debugging on the Volterra Dev Kit today.
> Allan Jude had previously patched up the boot loader a little so
> it gets to the point where it shows you the menu and lets you
> type in commands.  The last known state of affairs was "boot loader
> gets to the point where it boots the kernel, but kernel hangs
> without any further output."
> 
> My tests are based on 89ffac3b with D37765, D37766, and D47767
> applied.
> 
> It seems that the boot loader is still wonky; there's radio
> silence from the kernel because it doesn't actually boot!
> 
> Some printf() debugging later, I noticed that the boot loader
> hangs in bi_load_efi_data(), specifically in the BS->GetMemoryMap()
> loop.  I've added some printf() calls therein and now it no longer
> hangs -.-  ketas in #bsdmips suggested that there migth be some
> sort of race condition going on.
> 
> Anyway, we are then greeted with an "ExitBootServices error 2"
> but the boot continues.  It finally jumps into the kernel, but
> there is an immediate fault at the entry point:
> 
> Synchronous Exeption at 0x0000000C7C000800
> 
> Looks like the whole memory management is still wonky.  With just
> a random guess, could it be that the loader tries to map the kernel
> W+X to be able to load and then execute it, which the EFI
> implementation doesn't like, just like it didn't like that with the
> boot loader itself?
> 
> I'll try to continue to investigate, but unfortunately I know very
> little about this stuff.
> 
> Yours,
> Robert Clausecker
> 
> -- 
> ()  ascii ribbon campaign - for an 8-bit clean world 
> /\  - against html email  - against proprietary attachments
> 

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

From nobody Sun Jan  1 17: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 4NlQxh6S7mz2lK56
	for ; Sun,  1 Jan 2023 17:30:32 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58])
	(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 4NlQxh17mkz3Nl8
	for ; Sun,  1 Jan 2023 17:30:31 +0000 (UTC)
	(envelope-from jfc@mit.edu)
Authentication-Results: mx1.freebsd.org;
	none
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17])
	by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 301HUSN6020354;
	Sun, 1 Jan 2023 12:30:29 -0500
Received: from oc11expo22.exchange.mit.edu (18.9.4.84) by
 oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id
 15.0.1497.38; Sun, 1 Jan 2023 12:29:29 -0500
Received: from oc11exhyb5.exchange.mit.edu (18.9.1.110) by
 oc11expo22.exchange.mit.edu (18.9.4.84) with Microsoft SMTP Server (TLS) id
 15.0.1497.42; Sun, 1 Jan 2023 12:30:28 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174)
 by oc11exhyb5.exchange.mit.edu (18.9.1.110) with Microsoft SMTP Server (TLS)
 id 15.0.1497.42 via Frontend Transport; Sun, 1 Jan 2023 12:30:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Dc9Rjs9NzGpzB5RMzBPWBHwywGVEUTuVsg++zcDn68sI2KcEUbW7MBJ46/Mw+0OAjLrxgce63dXBIg4PykeeOxsFPDgsxZWXYB4wf2DKA60Y4JXuoIDUxUYXCaOKnRhEfAhEw2KqUlpkrcBcWMOJ/bBRBIOMHshFXnOu7PXFKV+3sHIfUZKShZT1ICoNgqwBPER/3QQGGqXtIzDonmgM6QAsMGQnTcpVJAIFKFWiIFUzW1hIgMxUdAsYdY353lnrs/OgE3aY79m1FI2+P1RcEfgtOS4j9fGyLX9wE30sEommwRtyCzdeE4S56+KewlGfaVJRRqaFzaRn/83UoqRVoQ==
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=FgFbfxFQWuHfmAklxwFk5JYy/tnwfcSLsGMQXNOGwE4=;
 b=OYSvHkbIJ8aJB+sDJxMRyY0XP/hKZ4eGMSrtHug0I/aJQX5MgmXumsobI9Yc9ovdMvtkwLl5MhX2VjatHRVMcd+V+HCGlWXi5CsyxDkzvwHLPZgGwQGNLw8tiNwfM3dsStoGm9B/6HOqUedNm1n6PD+L/5NdwBsmnXWFIOXeyX9FDQshaQWfaAK7VqoQDekCmS+0nSU5Ht811NcXLHS4TwLKXO16cPL9O/nxMgvOIHuFYvGPk5ohOrnwcL++dRRmS0iDzVBQILXH+imHLbY27qlW08WN4F6Iecf0HvEiNIbr/CX/dnnYxF2XsdeS/PG1TTOUB93qkw+/lAxRta2YIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass
 header.d=mit.edu; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=FgFbfxFQWuHfmAklxwFk5JYy/tnwfcSLsGMQXNOGwE4=;
 b=NTy0aAl7wthCVsuvBiiPIdTl+rdrITJnti9aOuDKE9GKXGlIic17IYxfvJ7LdHrI5+xx0aU6yBfkSt/VHHmPWgtJ0VOLfs8SPyJFQNfWmjMbH9WZEnYiGmKeNPLiHCXx9mBazt28tlr5N35C+xGUIFuKr87oDoZ6N2F86DJMeg4=
Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by
 CY1PR01MB2201.prod.exchangelabs.com (2a01:111:e400:c616::9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5944.16; Sun, 1 Jan 2023 17:30:26 +0000
Received: from DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::b8dd:4b3b:3d80:500b]) by DS7PR01MB7712.prod.exchangelabs.com
 ([fe80::b8dd:4b3b:3d80:500b%8]) with mapi id 15.20.5944.019; Sun, 1 Jan 2023
 17:30:26 +0000
From: John F Carr 
To: Ronald Klop 
CC: Mark Millard ,
        "freebsd-arm@freebsd.org"
	,
        Andrew Turner 
Subject: Re: lsof crashes in Arm Optimized Routines
Thread-Topic: lsof crashes in Arm Optimized Routines
Thread-Index: AQHZHd+B9l8QgVYiMEOVgUWRe9Xnf66J0ayA
Date: Sun, 1 Jan 2023 17:30:25 +0000
Message-ID: 
References: <1331707040.259440.1668459233836@localhost>
 <490902644.115954.1668511998644@localhost>
 <690511F4-25A6-41E8-A75A-FFE80C352DFA@yahoo.com>
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|CY1PR01MB2201:EE_
x-ms-office365-filtering-correlation-id: c76c162a-1338-433a-d764-08daec1dde86
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PhwziLDvGOpJrz4m9Zg2vP76TswitaZoQnIsiR8glTlVMWoxE0TIu95ojg3U42N41ktExo12EcDsY5cMWEUHb8EDGajd7fnMWxaBbZNuQhR+3yV/rgO2xnqZHjv4kSuDsK+6WEAlmJplQLAtOtONOz2Jl8AiHl7JvFyMvjGO3+jKPGyk+xHcFdBtwn6+upSfZOwJpsSOs+9DPQCzHTsL5wDzDXZlhhhEkQNOKnh4/aTytLs9YOzRcfKPYPO5B27VhNlSjYvPlgadOTHvOEeVIYM93TPv/ibObydBMzZqLFWvf6+VKsxbHoN9remlYk1NttteU7cs25gSXbrufPiLYjmBJhoNHmrHh2ystnESalYCmTcyE4DDvEAoZTXvqJ2uHHqJnj9aArBk+Y+CfXk/gjBi728SG/0RxPJO736j7t2gszTBn43RD4tpo1ImZ7dhhWqa+WzOVt7S42UT50TbUXaJESPUyxcONZkeK/Xcqk5jR7JvBh6b3lZXaOEY/+AGHFtp/fIG/O3YzVkTj6E1L3mIFeSD4A/+yLiIO51GdPBJnCIfLleQ5IfIf9LII8M5PzDaIIJRoyrHvOvnsWF3HgfixmSQS3cj3cM2SN07MDLaihh560qtOK6BQnyuDUuqCQLaVZWT1M5R9Q99ZvKDmiozS2V2OGlV2LkoMxEvGU/RF8r2BJnu2ldXvACu/kcsWIlKbQFZRiq6WeNR+iKcaDbCIqj+1nX4MfurI+OdCtespWFz/5yUGzUyAu/HObT+
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(451199015)(38070700005)(478600001)(6506007)(6916009)(6486002)(966005)(33656002)(54906003)(36756003)(2616005)(75432002)(53546011)(86362001)(41300700001)(2906002)(26005)(38100700002)(71200400001)(786003)(186003)(6512007)(316002)(83380400001)(5660300002)(8936002)(91956017)(122000001)(66446008)(8676002)(66946007)(64756008)(66556008)(66476007)(76116006)(4326008)(22166003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KG52Cb5UCfiwGoWv37hfwPwLdAu255daN+8MKQ0AXB+UT6ZvDV7upaEoh3F/?=
 =?us-ascii?Q?S4Ts/H3hv1Lng6KRFnqZ9wHgxCaV1/MNAow+6ZeU1572WSCvN5jVL2emwFOq?=
 =?us-ascii?Q?/O9sFInjvEPwal7LsCYxJroixG8dO3JDuZhHolWPIoDlwMNEBcvzWKUI3ehz?=
 =?us-ascii?Q?PkHARjCiFCduS6an7kK0nsmDoPFeXKlGLjiYnTSe5GXLvmVdoT/lqXlar6bD?=
 =?us-ascii?Q?7mMEbquRgAyFrhK32eipEcBke7D0s29W86JPny4r7aqgb75Uy74WfwB5bxYX?=
 =?us-ascii?Q?swKdE0xswdX0tTZ7QUca96s4RnClqFPPx5uR7SE/Q+zLhxPE82mJQrQPQscU?=
 =?us-ascii?Q?JzPsGBa5iMcWSDVMJ2+fMMZzeWWMjjZ/fBqgX9M3y867Tr0joH7nYEQU0PXE?=
 =?us-ascii?Q?Kc97qunS/+RHosHWV4mL6QKRS3SK/538BGgLxHbUlToq9bYp3uxRlbu57BYj?=
 =?us-ascii?Q?evuOzWT0U9DBHeiJ8gWO35YmlqRmqajJ7xJopOyJAnXGOygMi1awCak5qCvk?=
 =?us-ascii?Q?lFmCW1poIsK9j6VBAwlB+2MmIQLrzohE6KupJxmhl0RWhHLHCOdKC20Hj6mk?=
 =?us-ascii?Q?25Z2oiYrNJo3b6JNmJA/D4ihcnWneEDs/TVNvt4ZUD8v7tTDZWOBkBHECtNv?=
 =?us-ascii?Q?13tlAX6oxHHE59mSU5gNqrs/Um4vahdAZu8er4JRsx6yx5ECakzjPVLIemJk?=
 =?us-ascii?Q?I4745Utg25Kds7JfEGa8jGjGDPOAE0QU9vEXSyhQCKi6Y5mMUVrpj3X2kJB1?=
 =?us-ascii?Q?jpZ5OtFLwmkJW3bX95d5epI7kZYxrks07xMwY5obqDh0zYjvVKeQxlonuOZs?=
 =?us-ascii?Q?7/fq/oWgm1pGQ8B5dF6OIcMWrzKWU4L8SX4S8sHb0SkfflGFLTsl/cXSlvSY?=
 =?us-ascii?Q?Bd0wppbt+XQlv+Em9l7rZnCNqxneixsQ8LuSSYqdtopPVM8x3XFpSpeuOyNn?=
 =?us-ascii?Q?iuMb5wgMm/Ea7YvcZpPMfbDy0b5uVAEOHiiNSWAVJirWcrqOtcb2RClU2WhA?=
 =?us-ascii?Q?mg1PXQOK3Ukm8FQ1t+cf41Ok32FcJFisfmlxrq8+IA2t1HkWN0gh6RjCHWRH?=
 =?us-ascii?Q?aoBKrqKaSPcsuGsLTerIM6L2v7hKzdWuQ9i5zUbQXXBCPwR6DbFo5MB9bm2y?=
 =?us-ascii?Q?rvdNaISc9SQxZYPsY5vJZBM1pC474ZKYRxrfRI5Pnbpj+0linxWDu8ytP9oY?=
 =?us-ascii?Q?n88eRk0D+YyQeh2k7VKmq90YU/ZzrOW0JxC3k/PsoJ6blpSc/0o0TiTwBar6?=
 =?us-ascii?Q?/xwpcs9HnKjanWOrZ5hSpR7a1SU8BmirGVTLgwkDWk4JeNtPGQgkyoVaJrUJ?=
 =?us-ascii?Q?K299NoNqLY3TNMSY9HS9znHvOP/H99v14im5OXepYVrGUixmLlm7jR45mjT1?=
 =?us-ascii?Q?CKvyXcrQwB0/5KevnG9LotBjzNrtcd4ALWFa61pfum0X79nQ1LzziDx4gLCO?=
 =?us-ascii?Q?2vyuXiTSW+8578Qtu1lPUEP3/Y9+xw5AcBtYBx6F1jEDA7zQllSG3uPXcWRL?=
 =?us-ascii?Q?PjIa0uf1TLYbGiBeK/7pIAkPtjDscCUmJU+aRcm8bAzRp7tzyOjnp4fBF1wm?=
 =?us-ascii?Q?r5cT25byZMhT9LMj9xs=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: DS7PR01MB7712.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c76c162a-1338-433a-d764-08daec1dde86
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2023 17:30:25.7776
 (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: 0IYJfg2Ie3LiJKe9WP4vDiBQs05XwAsv5SXxDpcD/Fb56gd8nLDBzqdaS5T1VCYY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB2201
X-OriginatorOrg: mit.edu
X-Rspamd-Queue-Id: 4NlQxh17mkz3Nl8
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


> On Jan 1, 2023, at 07:49, Ronald Klop  wrote:
>=20
> On 11/18/22 01:57, Mark Millard wrote:
>>> On Nov 15, 2022, at 03:33, Ronald Klop  wrote:
>>>=20
>>> Sorry for the noise.
>>>=20
>>> But I cannot reproduce this today. I can scroll back in my terminal and=
 see the command and error from yesterday, but running the same again just =
works.
>> FYI:
>> I do not have specifics any more, but I'll note that I've seen
>> such lsof behavior of failing at one time and later working
>> without any installed updates to it or the system between. I
>> rarely use lsof and, so, this was not recently.
>> I've no clue how to cause the failure(s) to show up. I've no
>> clue how common the issue is. But, over time, it is not just
>> you.
>>>=20
>>> Van: Ronald Klop 
>>> Datum: maandag, 14 november 2022 21:53
>>> Aan: freebsd-arm@FreeBSD.org, Andrew Turner 
>>> Onderwerp: lsof crashes in Arm Optimized Routines
>>> Hi,
>>>=20
>>> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267760 : Segmen=
tation fault in lsof. Program received signal SIGSEGV, Segmentation fault.
>>> Invalid permissions for mapped object.
>>> memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routine=
s/string/aarch64/memcpy.S:175
>>> 175 stp D_l, D_h, [dst, 64]!
>>>=20
>>> I also remembered this change: https://cgit.freebsd.org/src/log/contrib=
/arm-optimized-routines?showmsg=3D1 about Arm Optimized Routines.
>>>=20
>>> Could this be related? What can I do to help debug this?
>>>=20
>>   =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
>=20
> I'm having this issue again.
>=20
> No debugging symbols found in lsof)
> (gdb) run
> Starting program: /usr/local/sbin/lsof
>=20
> Program received signal SIGSEGV, Segmentation fault.
> Invalid permissions for mapped object.
> memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routines/=
string/aarch64/memcpy.S:171
> bt
> 171             stp     B_l, B_h, [dst, 32]
> (gdb) bt
> #0  memcpy () at /home/ronald/dev/freebsd/src/contrib/arm-optimized-routi=
nes/string/aarch64/memcpy.S:171
> #1  0x0000000000218be4 in ?? ()
> #2  0x0000000400000000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?=
)
> (gdb)
>=20
>=20
> Some output of "truss -o /tmp/lsof.txt lsof":
>=20
> __sysctl("kern.proc.filedesc.1",4,0x0,0x80ba06f0,0x0,0) =3D 0 (0x0)
> __sysctl("kern.proc.filedesc.1",4,0x851d6000,0x80ba06f0,0x0,0) =3D 0 (0x0=
)
> __sysctl("kern.proc.filedesc.385",4,0x0,0x80ba06f0,0x0,0) =3D 0 (0x0)
> __sysctl("kern.proc.filedesc.385",4,0x8516ec00,0x80ba06f0,0x0,0) =3D 0 (0=
x0)
> __sysctl("kern.proc.filedesc.97537",4,0x0,0x80ba06f0,0x0,0) =3D 0 (0x0)
> __sysctl("kern.proc.filedesc.97537",4,0x8516ec00,0x80ba06f0,0x0,0) =3D 0 =
(0x0)
> statfs("/data/jails/jail13/_root/home/root/dev/workspace/FreeBSD-Ports-13=
/_root/usr/local/poudriere/data/.m/freebsd13-custom/04/bin/sh",{ fstypename=
=3Dnullfs,mntonname=3D/data/jails/jail13/_root/home,mntfromname=3D/data/jai=
ls/_home,fsid=3D3cff022929000000 }) =3D 0 (0x0)
> statfs("/data/jails/jail13/_root",{ fstypename=3Dnullfs,mntonname=3D/data=
/jails/jail13/_root,mntfromname=3D/data/jails/freebsd13,fsid=3D37ff02292900=
0000 }) =3D 0 (0x0)
> statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/l=
ocal/poudriere/data/.m/freebsd13-custom/04/bin/sh",0x80b9ef40) ERR#2 'No su=
ch file or directory'
> statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/l=
ocal/poudriere/data/.m/freebsd13-custom/04/wrkdirs/usr/ports/devel/cmake-co=
re/work/cmake-3.24.3/Source",0x80b9ef40) ERR#2 'No such file or directory'
> statfs("/data/jails/_home3root/dev/workspace/FreeBSD-Ports-13/_root/usr/l=
ocal/poudriere/data/.m/freebsd13-custom/04",0x80b9ef40) ERR#2 'No such file=
 or directory'
> statfs("/data/jails/freebsd13ovt",0x80b9ef40)    ERR#2 'No such file or d=
irectory'
> SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR trapno=3D36 addr=3D0x80ba1000
> process killed, signal =3D 11 (core dumped)
>=20
>=20
> I'm surprised that the path names in the truss output are corrupted: _hom=
e3root should be _home/root.
>=20
> NB: I'm using lsof while running poudriere in a jail in a Jenkins agent.
>=20
> Regards,
> Ronald.
>=20
>=20

I think this is a bug in lsof and the optimized memcpy routine is doing wha=
t it is asked to do, copy into a block of memory that the caller does not h=
ave write access to.  The faulting data address 0x80ba1000 is at the start =
of a page.  The faulting instruction address is in the middle of a block of=
 code that writes to successively increasing addresses.  The destination po=
inter passed to memcpy must be valid or the function would have crashed ear=
lier.  But the end address is out of bounds, meaning the size is wrong.  If=
 you can get the program in a debugger again, or you can find a core file, =
check the value of register x2 ("count" in assembly code).  If that is huge=
 then you have an uninitialized or otherwise invalid third argument to memc=
py.

In a jail system calls to determine the current filesystem behave different=
ly.  The odd path names may be symptoms of jail-induced confusion.



From nobody Sun Jan  1 19:56:56 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 4NlVBp3Xbvz2ngZf
	for ; Sun,  1 Jan 2023 19:57:06 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NlVBm5WtMz3qC7
	for ; Sun,  1 Jan 2023 19:57:04 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net;
	dmarc=none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 301Juvu3002014;
	Sun, 1 Jan 2023 13:56:57 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id ct1wConlsWPcBwAA4+wvSQ
	(envelope-from ); Sun, 01 Jan 2023 13:56:57 -0600
From: Mike Karels 
To: "Bjoern A. Zeeb" 
Cc: Mark Millard , freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
Date: Sun, 01 Jan 2023 13:56:56 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: 
In-Reply-To: <4AF80D6A-B421-4D1D-ADEA-5F4439A74E43@karels.net>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg>
 <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net>
 <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
 
 <4AF80D6A-B421-4D1D-ADEA-5F4439A74E43@karels.net>
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-Spamd-Result: default: False [-2.19 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[mike];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[karels.net];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NlVBm5WtMz3qC7
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

On 30 Dec 2022, at 16:16, Mike Karels wrote:

> On 30 Dec 2022, at 16:03, Bjoern A. Zeeb wrote:
>
>> On Thu, 29 Dec 2022, Mark Millard wrote:
>>
>>> Bjoern did not report enough information for the configuration
>>> of that EDK2 based context to replicate his boot context in a
>>> test.
>>
>> Sorry, I applied the config.txt change from the open pull request ther=
e
>> where I left a comment a year or so ago.  I was running with the
>> previous version quite fine.
>>
>> I did disable ACPI for a change in the setup.  No idea how that would =
be
>> persistent.
>>
>> I used to run with the previous version but loader now panics on that =
so I
>> found the fairly recent new one.
>>
>> I also have my own kernel admittingly; same builds on years because I
>> run them with a memory disk.
>>
>> The GE switch port are on auto but given this is USB device attaching
>> time it seem that shouldn't make the huge difference (and I checked th=
at
>> it wa on an auto-port before and so is my other one).
>>
>> In either way, @mike, does your boot indiciate that ue0 is setup durin=
g
>> the first netif run or is devd doing it later for you and it'd be ther=
e
>> by the time you login)?  Just checking before I'll put it onto the TOD=
O
>> list to one day dig deeper.
>
> I think it was at the normal time (netif), according to the console
> output.  I=E2=80=99ll double-check later.

Yes, ue0 was detected before devd started.  However, this happened after
root_hold_wait (in /etc/rc.subr, called from mountcritlocal) printed
=E2=80=9CWaiting 30s for the root mount holders: usbus1=E2=80=9D, after w=
hich uhub1,
ue0 and other things configured after a very short delay.

		Mike
>
>> /bz
>>
>> -- =

>> Bjoern A. Zeeb                                                     r15=
:7

From nobody Sun Jan  1 21:00: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 4NlWbc5cX6z2nsDV
	for ; Sun,  1 Jan 2023 21:00:12 +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 4NlWbc3Rlmz40MX
	for ; Sun,  1 Jan 2023 21:00:12 +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=1672606812;
	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=/flLA/H+Ltiy2zk5KkDoaqb7vnNqL05K2UNT/E6Xsz8=;
	b=d0JENlr3oQsN8XxRutJNT8F7OS8bawonuLD1bgZFn6xjmdYLjJ8y0M1ZxcMmLv2loGzlGX
	6bjH5prqtcX+oB89QnPo+QtACTa5SS5WYBm3WJJ8Plc258/np0aPArbTDm418lw8LLpMRp
	53JewyBpmkmpAKEOCF5DwR8PlPf8Wo2IAYAtVSvPOCeCBSwn9HeZ7Ofas8PqLC5G3RuxX3
	dpNN34xa8p7xlujwGQXaRmd9TMR9F2M6rn54bgtT/x7tzOXrjinkbPkAgO0JabmVRQi2lt
	RQb4XHsk2m+lq0gTc6g0xeG9Mh1/lMCnq6fgcWtUrOT6RG0+1C4N6CfwgFJsXw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672606812; a=rsa-sha256; cv=none;
	b=H8MrLS41HQ5Jw5GIFdwj0VL4uoUu7gUdQUiiEyuQgjUGi+KrYVbJEhjgxpC1fLaCCtLfzY
	oQWZ2QatbLkI2odyF8VeY6aIut0RPJykxfsv6+OucbXQg/M9IE5h6xoLv84wLo8pg3+D+o
	TdAFIipZgrrAj2BNdx5D3TSw6mpWxugkgdfGKMOAmVpnkBL6JTjexkhXwz7uoAlETN3VhA
	rSklUCc2k8z404c28JwRPRd/Dx04k2pVQxwJpWhkS+v605rFycKATZRZi3ptVXm+ZcxSza
	4ySxVuNJ/IfSvMbH8oUr8RG7D0z9j32OHBzElIapuDUUjE/PHL4zduimycOrdg==
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 4NlWbc2WtszhYk
	for ; Sun,  1 Jan 2023 21:00:12 +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 301L0Cw6072470
	for ; Sun, 1 Jan 2023 21:00:12 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 301L0C8U072469
	for freebsd-arm@FreeBSD.org; Sun, 1 Jan 2023 21:00:12 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202301012100.301L0C8U072469@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, 1 Jan 2023 21:00:12 +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="16726068120.DDCe.70717"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16726068120.DDCe.70717
Date: Sun, 1 Jan 2023 21:00:12 +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.

--16726068120.DDCe.70717
Date: Sun, 1 Jan 2023 21:00:12 +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.


--16726068120.DDCe.70717--

From nobody Mon Jan  2 00:36:06 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 4NlcP23FWqz1Lnfx
	for ; Mon,  2 Jan 2023 00:36:22 +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" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NlcP16fhkz4Kvd
	for ; Mon,  2 Jan 2023 00:36:21 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
	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 315B68D4A212;
	Mon,  2 Jan 2023 00:36:10 +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 A64F65C3A833;
	Mon,  2 Jan 2023 00:36:09 +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 GNo5fqh3ojeo; Mon,  2 Jan 2023 00:36:08 +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 E7C055C3A830;
	Mon,  2 Jan 2023 00:36:07 +0000 (UTC)
Date: Mon, 2 Jan 2023 00:36:06 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Mike Karels 
cc: freebsd-arm 
Subject: Re: rpi3b+ ue0 too late to be configured on boot?
In-Reply-To: 
Message-ID: <7p42r328-n9q1-s7sq-rn8r-q670612qqr0@yvfgf.mnoonqbm.arg>
References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg> <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net> <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>  <4AF80D6A-B421-4D1D-ADEA-5F4439A74E43@karels.net>
 
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: multipart/mixed; boundary="1098556516-1241415322-1672619767=:27118"
X-Rspamd-Queue-Id: 4NlcP16fhkz4Kvd
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1098556516-1241415322-1672619767=:27118
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 1 Jan 2023, Mike Karels wrote:

> On 30 Dec 2022, at 16:16, Mike Karels wrote:
>
>> On 30 Dec 2022, at 16:03, Bjoern A. Zeeb wrote:
>>
>>> On Thu, 29 Dec 2022, Mark Millard wrote:
>>>
>>>> Bjoern did not report enough information for the configuration
>>>> of that EDK2 based context to replicate his boot context in a
>>>> test.
>>>
>>> Sorry, I applied the config.txt change from the open pull request there
>>> where I left a comment a year or so ago.  I was running with the
>>> previous version quite fine.
>>>
>>> I did disable ACPI for a change in the setup.  No idea how that would be
>>> persistent.
>>>
>>> I used to run with the previous version but loader now panics on that so I
>>> found the fairly recent new one.
>>>
>>> I also have my own kernel admittingly; same builds on years because I
>>> run them with a memory disk.
>>>
>>> The GE switch port are on auto but given this is USB device attaching
>>> time it seem that shouldn't make the huge difference (and I checked that
>>> it wa on an auto-port before and so is my other one).
>>>
>>> In either way, @mike, does your boot indiciate that ue0 is setup during
>>> the first netif run or is devd doing it later for you and it'd be there
>>> by the time you login)?  Just checking before I'll put it onto the TODO
>>> list to one day dig deeper.
>>
>> I think it was at the normal time (netif), according to the console
>> output.  I’ll double-check later.
>
> Yes, ue0 was detected before devd started.  However, this happened after
> root_hold_wait (in /etc/rc.subr, called from mountcritlocal) printed
> “Waiting 30s for the root mount holders: usbus1”, after which uhub1,
> ue0 and other things configured after a very short delay.

Thanks a lot Mike for checking again!  This may be the clue.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7
--1098556516-1241415322-1672619767=:27118--

From nobody Thu Jan  5 05:18:49 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 4NnZWP0T15z2pLTG
	for ; Thu,  5 Jan 2023 05:18:41 +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 4NnZWM3mNrz4J2t
	for ; Thu,  5 Jan 2023 05:18:39 +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.16.1/8.15.2) with ESMTPS id 3055IoAG005658
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 4 Jan 2023 21:18:50 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 3055IoNX005657;
	Wed, 4 Jan 2023 21:18:50 -0800 (PST)
	(envelope-from fbsd)
Date: Wed, 4 Jan 2023 21:18:49 -0800
From: bob prohaska 
To: freebsd-arm@freebsd.org
Cc: bob prohaska 
Subject: Named reporting  port in use on 12.4-STABLE r372838 GENERIC arm
Message-ID: <20230105051849.GA5563@www.zefox.net>
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 [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NnZWM3mNrz4J2t
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

After an upgrade to 12.4-STABLE r372838 GENERIC arm on a Pi2 (armv7)
BIND 9.16.1 (Stable Release)   fails on start with
Jan  4 20:41:25 ns1 named[973]: creating TCP socket: address in use
Jan  4 20:41:25 ns1 syslogd: last message repeated 2 times
Jan  4 20:41:25 ns1 named[973]: unable to listen on any configured interfaces
Jan  4 20:41:25 ns1 named[973]: loading configuration: failure
Jan  4 20:41:25 ns1 named[973]: exiting (due to fatal error)

Apart from the OS upgrade nothing was changed and it had been
working flawlessly for about six months. Re-using the old kernel
didn't fix it, has something in userland changed? A slave machine
updated yesterday without trouble so I thought it was safe to 
update the master.

Thanks for reading, any hints appreciated!

bob prohaska


From nobody Thu Jan  5 14:22: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 4NnpZ35NC1z2qvWF
	for ; Thu,  5 Jan 2023 14:21:47 +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 4NnpZ2505Gz3s9f
	for ; Thu,  5 Jan 2023 14:21:46 +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.16.1/8.15.2) with ESMTPS id 305EM3kp011638
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 5 Jan 2023 06:22:03 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 305EM3Qf011637;
	Thu, 5 Jan 2023 06:22:03 -0800 (PST)
	(envelope-from fbsd)
Date: Thu, 5 Jan 2023 06:22:03 -0800
From: bob prohaska 
To: John F Carr 
Cc: freebsd-arm@freebsd.org
Subject: Re: Named reporting  port in use on 12.4-STABLE r372838 GENERIC arm
Message-ID: <20230105142203.GA11502@www.zefox.net>
References: <20230105051849.GA5563@www.zefox.net>
 <8072B9BF-71E4-4385-8426-1808D72AD47E@mit.edu>
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: <8072B9BF-71E4-4385-8426-1808D72AD47E@mit.edu>
X-Spamd-Result: default: False [-1.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NnpZ2505Gz3s9f
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jan 05, 2023 at 09:19:58AM +0000, John F Carr wrote:
> Do you have both unbound and named enabled?
> 

Certainly not intentionally, and seemingly not at all:

root@ns1:/usr/ports # ps -aux | grep -i unbound
root  7597   0.0  0.2  4788  1884  0  S+   05:44      0:00.01 grep -i unbound

while /etc/defaults/rc.conf contains

local_unbound_enable="NO"       # Local caching resolver
local_unbound_tls="NO"          # Use DNS over TLS

with no reference to unbound in /etc/rc.conf .

Perhaps the error message was spurious, though it certainly
seemed that named wasn't working immediately after reboot
last night when tested with nslookup. Rndc status now reports
the server is up and running, nslookup gets answers.

Named seems to be working, at least for now. Maybe I'm somehow
starting named twice and only noticed the fact yesterday.

Thanks for writing!

bob prohaska






> > On Jan 5, 2023, at 00:18, bob prohaska  wrote:
> > 
> > After an upgrade to 12.4-STABLE r372838 GENERIC arm on a Pi2 (armv7)
> > BIND 9.16.1 (Stable Release)   fails on start with
> > Jan  4 20:41:25 ns1 named[973]: creating TCP socket: address in use
> > Jan  4 20:41:25 ns1 syslogd: last message repeated 2 times
> > Jan  4 20:41:25 ns1 named[973]: unable to listen on any configured interfaces
> > Jan  4 20:41:25 ns1 named[973]: loading configuration: failure
> > Jan  4 20:41:25 ns1 named[973]: exiting (due to fatal error)
> > 
> > Apart from the OS upgrade nothing was changed and it had been
> > working flawlessly for about six months. Re-using the old kernel
> > didn't fix it, has something in userland changed? A slave machine
> > updated yesterday without trouble so I thought it was safe to 
> > update the master.
> > 
> > Thanks for reading, any hints appreciated!
> > 
> > bob prohaska
> > 
> > 
> 
> 

From nobody Thu Jan  5 16:11: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 4Nns0f02hqz2rB61
	for ; Thu,  5 Jan 2023 16:11:30 +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 4Nns0c2jlcz467F
	for ; Thu,  5 Jan 2023 16:11:28 +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 828FB8D4A171
	for ; Thu,  5 Jan 2023 16:11:20 +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 B9B935C3A830
	for ; Thu,  5 Jan 2023 16:11:19 +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 rAeXNGY3OMwq for ;
	Thu,  5 Jan 2023 16:11:18 +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 958A45C3A876
	for ; Thu,  5 Jan 2023 16:11:18 +0000 (UTC)
Date: Thu, 5 Jan 2023 16:11:18 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm@freebsd.org
Subject: panic: vm_fault failed: %lx error 1 (from arm64::data_abort)
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 [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[zabbadoz.net];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4Nns0c2jlcz467F
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi,

on an unattended console after updating the machine (previious builds were Dec 23) did not come back up.
I have a few last lines.

  esr:   96000004
panic: vm_fault failed:  error 1
cpuid = 0
time = 1
KDB: stack backtrace:
..
data_abort()
..
--- exception, esr 0x96000004
thread_init()
keg_alloc_slap()
zone_import()
cache_alloc()
cace_alloc_retry()
thread_alloc()
fork()
kproc_create()
audit_worker_init()
mi_startup()
virtdone()


-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Thu Jan  5 16:37: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 4NnsZx0lqwz2lJjn
	for ; Thu,  5 Jan 2023 16:37:45 +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 4NnsZw3NgRz49Lm
	for ; Thu,  5 Jan 2023 16:37:44 +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 039B98D4A171
	for ; Thu,  5 Jan 2023 16:37:42 +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 742335C3A830
	for ; Thu,  5 Jan 2023 16:37:42 +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 JqYPX_ckUQm1 for ;
	Thu,  5 Jan 2023 16:37:41 +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 8EDCB5C3A876
	for ; Thu,  5 Jan 2023 16:37:41 +0000 (UTC)
Date: Thu, 5 Jan 2023 16:37:41 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm@freebsd.org
Subject: (RPi) db> reboot -> cpu_reset failed
Message-ID: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
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 [-3.15 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.85)[-0.850];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131:c];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DMARC_NA(0.00)[zabbadoz.net];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NnsZw3NgRz49Lm
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi,

given I currently find myself debugging more PIs again, what is needed
to be able to reset from the db> prompt?

Currently I get "cpu_reset failed" when trying.

Needing remote hands or an OOB PDU to cycle the PI is not satisfying.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Thu Jan  5 18:01: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 4NnvRX2T9Wz2nlwP
	for ; Thu,  5 Jan 2023 18:01:28 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4NnvRX0PfZz4L9d
	for ; Thu,  5 Jan 2023 18:01:28 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62d.google.com with SMTP id u19so91777277ejm.8
        for ; Thu, 05 Jan 2023 10:01:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gmuU1wWk/8hnb6zGr1q6P7+B2xSo5uVUT/ZPAqxe5us=;
        b=mnyG9cMkbPP8b33MZXg9iemc4btHBgnVxH3hobpg09JT/I9O11tTkCrHMRSaZberYV
         k2/ZhD2ntwkLz+GknWoggV5XC4kE5KpyKiigGYgCGWgii8bkXqTjmU3O/QMX2Gexr+KP
         RWpTPd3uEV3Wawrdctc/kHMFZSXlRvaWgPU/x3VO9gutyJPKTQBfRKcV0N7S9GrUqC0W
         Ua7E7ESPnWcT2E2o8PhsgtFWoqEkVuA1PNcLRCNnJjW/5VW0CnIffEa4ozsdJ3s4QdZn
         IJ3J89DNetcT45Vgu9S4Zqt4pTbdd1SlZC1hgsZrppdza/TkVtlcQXcONrOITlGNQYRH
         hUFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=gmuU1wWk/8hnb6zGr1q6P7+B2xSo5uVUT/ZPAqxe5us=;
        b=3B5G0gSczFrNuWBiSkhIJ+1ch5hDASzhCWuuI31UALQEUF+aTJge9/Z2eRauuYE8Qc
         ymQTHbdhxlQZz13FjlNDUa5ibFgL7/TuIuCNG+d1dH64l88LyfEgKo89MIPGmw9XDEDA
         u8x+J1Ltxzt8c9noPUT1/bZGH4GAqHi1jR4042CgFbAC2bh3lXyNdE5vsYPdkfhbVK2r
         PMOfFhE3b153UB9t5Szb58kHwEcY457r/ZI3SZbwCk75GW3dd6zZFmqCMQLSWm7NJW4I
         6JV67W3L+Vj97n47kosrp3azmrVQaqxDWU8uilLtCOy/QOI8WeuODDa0yXsGhq+iEx6A
         imEQ==
X-Gm-Message-State: AFqh2kplzsaD3hnVqy26/ZqOv7BkcN1Cwc0H6et9ls/py5CafU5QFgXF
	x7zT4xjmOUiK4vTcMIFaHWHfh6/NhHw=
X-Google-Smtp-Source: AMrXdXtAJcF+PNUHhaM538YO8tgskQGswa4ZUcG9qphHeOjwhBmQnlSGLa9EcvhKxiWM2drgUpQTLA==
X-Received: by 2002:a17:906:260e:b0:7c1:9046:878a with SMTP id h14-20020a170906260e00b007c19046878amr44705468ejc.38.1672941684793;
        Thu, 05 Jan 2023 10:01:24 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-061-228.46.114.pool.telefonica.de. [46.114.61.228])
        by smtp.googlemail.com with ESMTPSA id r7-20020a170906280700b007b27aefc578sm16628192ejc.126.2023.01.05.10.01.22
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 05 Jan 2023 10:01:23 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Thu, 5 Jan 2023 19:01:11 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
To: "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
In-Reply-To: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
Message-Id: 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NnvRX0PfZz4L9d
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> Am 05.01.2023 um 17:37 schrieb Bjoern A. Zeeb =
:
>=20
> Hi,
>=20
> given I currently find myself debugging more PIs again, what is needed
> to be able to reset from the db> prompt?
>=20
> Currently I get "cpu_reset failed" when trying.
>=20
> Needing remote hands or an OOB PDU to cycle the PI is not satisfying.
>=20
> /bz
>=20
> --=20
> Bjoern A. Zeeb                                                     =
r15:7
>=20


you even cannot be sure to reach the ddb prompt at panic, like here :

--
..
KDB: stack backtrace:
..
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s
--
..and good night Pi ..

halt/resume of CPU is more promising by setting up a JTAG controller.

-
Regards
K.


From nobody Thu Jan  5 19:32: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 4NnxTP6kgvz2p1BC
	for ; Thu,  5 Jan 2023 19:33:13 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(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 4NnxTP2Gb0z3HXN
	for ; Thu,  5 Jan 2023 19:33:13 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=IDW5UKx8;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=maciphone2@googlemail.com;
	dmarc=pass (policy=quarantine) header.from=googlemail.com
Received: by mail-ed1-x52a.google.com with SMTP id v30so2834624edb.9
        for ; Thu, 05 Jan 2023 11:33:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=GJ6GuNACnE7ipzfYrr3UoNMGBWruOMsyKDxlhm3RMiE=;
        b=IDW5UKx8DRzoSnzcZp1btrQF/Ly4U+Re9CYicjy5aXySWJdTDt+7jkMJGT+BpxLrrN
         38rMOEjljtLdt0XSvYSOs2FCDeJZL+SiraA6viI4LeCLfeT6ONdsKr+yv5tTXvM040LQ
         izY5h/4/UvWNtbOvtcui9eGik74csPaGncnFk6mnK4946BAKbPhudGdE4fcIWaUzYe6z
         vH0AWO7J7R4C2gIroHuTvqHWPy4zU7yaadv/Donv9jET8oMwAIa0IshejG3uJQxVmXLP
         FlvRFjcAVmSIY7sTmUsjvG2k8uTS2PZTPaqTsqPUehtl5mwI2UQDhtoGHSzJwZvKkiXC
         6Hcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=GJ6GuNACnE7ipzfYrr3UoNMGBWruOMsyKDxlhm3RMiE=;
        b=H85K7J3CQg0Q511zUrWtwWAnFqc7pDenPj6rHCBD3wcKmkb8rWgfhHoQPOnkoU2HrL
         Ngxn/1jE0yeVl6z8R9PdiSE/PRi+Pc5Y2nildyysRcgx1TizVRSBzVnuhRNjI9P8gTdw
         fFSQztumCXsX5+VTZZL2LZI+m/yuI9Sjf82GE9EVoslKgsJBpW+0QLhRcX87PIZYTCo8
         LDl8QkXeeYkhIrYMmO52VmXSVLhPhxan7zVkhA+lGPQLuZCjyiO4x9/YwwRblhCDGIFb
         8/9H4AwGrw9QchPRSIetPdlOM4UYg6t4mOfemt0qPLBUUUbW2PQXW/hAG6rZF4NM3UPr
         lPSw==
X-Gm-Message-State: AFqh2kpvM+Tn1zaGKYheANpAaZj6XgKDhcyWnytAk8HWzOw8CDYBJrIm
	I+vbWxxB+ir/QVomB4Ag+mPMlyC4FaI=
X-Google-Smtp-Source: AMrXdXu/zO1WmBX0Qf4TblyfUsMFMZecwMtR7zm+SozMPARaMOPUDXKsfjLUt9RbvCzh0kbbkUY6Cg==
X-Received: by 2002:aa7:d484:0:b0:468:ccfb:7201 with SMTP id b4-20020aa7d484000000b00468ccfb7201mr43171209edr.17.1672947190497;
        Thu, 05 Jan 2023 11:33:10 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-061-228.46.114.pool.telefonica.de. [46.114.61.228])
        by smtp.googlemail.com with ESMTPSA id r17-20020aa7d591000000b004847513929csm13480248edq.72.2023.01.05.11.33.09
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 05 Jan 2023 11:33:10 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Thu, 5 Jan 2023 20:32:58 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
To: "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-2.77 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.89)[-0.893];
	R_MIXED_CHARSET(0.63)[subject];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NnxTP2Gb0z3HXN
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hi Bj=C3=B6rn,
( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some =
time..)

yes that was a  "live=E2=80=9C boot example from today of the cm4(on =
orig. I/O-board),
it hangs while initializing sdhci, while the boot partition is living on =
the emmc :
=E2=80=94

sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
Fatal data abort:
  x0:         ffffffff
  x1: ffff00000092b404
  x2:                0
  x3:                6
  x4: ffff000000fdf77c
  x5: ffff000000fdf72c
  x6:          4000000
  x7:          4000000
  x8: ffff000000dfb6a0
  x9:               20
 x10:                0
 x11:                1
 x12:  300000000006e65
 x13:   fefefefeff0100
 x14:               1d
 x15:                0
 x16:                0
 x17:                0
 x18: ffff000000fdf7e0
 x19:         ffffffff
 x20:                0
 x21: ffff000000bad000
 x22: ffff000000bad000
 x23: ffffa00000f8f038
 x24: ffff00000091b5b2
 x25: ffff0000008dfc9c
 x26: ffff0000009436b6
 x27: ffffa00000f8b140
 x28:         32000000
 x29: ffff000000fdf7e0
  sp: ffff000000fdf7e0
  lr: ffff000000868040
 elr: ffff0000008620d4
spsr:         a00000c5
 far:               20
 esr:         96000004
panic: vm_fault failed: ffff0000008620d4
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
#0 0xffff000000516458 at kdb_backtrace+0x60
#1 0xffff0000004c24ac at vpanic+0x174
#2 0xffff0000004c2334 at panic+0x44
#3 0xffff0000007f48c0 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086803c at bcm_sdhci_attach+0x314
#6 0xffff00000086803c at bcm_sdhci_attach+0x314
#7 0xffff000000502428 at device_attach+0x3fc
#8 0xffff000000504514 at bus_generic_new_pass+0x120
#9 0xffff0000005044a4 at bus_generic_new_pass+0xb0
#10 0xffff0000005044a4 at bus_generic_new_pass+0xb0
#11 0xffff0000005044a4 at bus_generic_new_pass+0xb0
#12 0xffff0000005065f4 at root_bus_configure+0x40
#13 0xffff000000439ee8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78
Uptime: 1s

=E2=80=94

Regards
K.



> Am 05.01.2023 um 19:48 schrieb Bjoern A. Zeeb =
:
>=20
> On Thu, 5 Jan 2023, Klaus K=C3=BCchemann wrote:
>=20
> Hi Klaus,
>=20
>>> Am 05.01.2023 um 17:37 schrieb Bjoern A. Zeeb =
:
>>>=20
>>> Hi,
>>>=20
>>> given I currently find myself debugging more PIs again, what is =
needed
>>> to be able to reset from the db> prompt?
>>>=20
>>> Currently I get "cpu_reset failed" when trying.
>>>=20
>>> Needing remote hands or an OOB PDU to cycle the PI is not =
satisfying.
>>>=20
>>> /bz
>>>=20
>>> --
>>> Bjoern A. Zeeb                                                     =
r15:7
>>>=20
>>=20
>>=20
>> you even cannot be sure to reach the ddb prompt at panic, like here :
>>=20
>> --
>> ..
>> KDB: stack backtrace:
>> ..
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>> --
>> ..and good night Pi ..
>>=20
>> halt/resume of CPU is more promising by setting up a JTAG controller.
>=20
> does this mean you are running into the issue at boot as well or was
> that just a (made up) example?
>=20
> --=20
> Bjoern A. Zeeb                                                     =
r15:7



From nobody Thu Jan  5 20:21:53 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 4NnyYh1YSkz2p703
	for ; Thu,  5 Jan 2023 20:22:00 +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 4NnyYf5rsrz3MZ5
	for ; Thu,  5 Jan 2023 20:21:58 +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 CA0698D4A142
	for ; Thu,  5 Jan 2023 20:21:56 +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 4ABAD5C3A833
	for ; Thu,  5 Jan 2023 20:21:56 +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 WmHfdXISWHDx for ;
	Thu,  5 Jan 2023 20:21:54 +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 752305C3A830
	for ; Thu,  5 Jan 2023 20:21:54 +0000 (UTC)
Date: Thu, 5 Jan 2023 20:21:53 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm@freebsd.org
Subject: Re: panic: vm_fault failed: %lx error 1 (from arm64::data_abort)
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 [-3.29 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[zabbadoz.net];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NnyYf5rsrz3MZ5
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:

Hi,

> on an unattended console after updating the machine (previious builds were 
> Dec 23) did not come back up.
> I have a few last lines.
>
> esr:   96000004
> panic: vm_fault failed:  error 1
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> ..
> data_abort()
> ..
> --- exception, esr 0x96000004
> thread_init()
> keg_alloc_slap()
> zone_import()
> cache_alloc()
> cace_alloc_retry()
> thread_alloc()
> fork()
> kproc_create()
> audit_worker_init()
> mi_startup()
> virtdone()

Follow-up, got a serial console hooked up and a kernel as of an hour ago
or so:

...
hostuuid: using 00000000-0000-0000-0000-000000000000
ULE: setup cpu 0
ULE: setup cpu 1
ULE: setup cpu 2
ULE: setup cpu 3
Fatal data abort:
   x0: ffffa000008c1d80
   x1:                0
   x2:                2
   x3:                3
   x4:              203
   x5:                0
   x6: ffffffffffffffff
   x7:             2001
   x8: ffff000000ee5000 (dump_encrypted_write.buf + f54)
   x9:                0
  x10: ffffa00000845be0
  x11:                2
  x12: ffff00004041dd98 (fuse_mtx + 3c276888)
  x13:   20000000000040
  x14:           42c000
  x15:                1
  x16:                c
  x17:            4082a
  x18: ffff000000fcf6a0 (initstack + 36a0)
  x19: ffff00004082b000 (fuse_mtx + 3c683af0)
  x20:                0
  x21: ffff00004082b000 (fuse_mtx + 3c683af0)
  x22:                2
  x23:                0
  x24: ffff00004082d000 (fuse_mtx + 3c685af0)
  x25:                0
  x26: ffff000000c73000 (sdta_vfs_vop_vop_spare4_return1 + 18)
  x27:                2
  x28:                1
  x29: ffff000000fcf6a0 (initstack + 36a0)
   sp: ffff000000fcf6a0
   lr: ffff0000004cdff8 (thread_init + 98)
  elr: ffff0000004ce004 (thread_init + a4)
spsr:         600000c5
  far:               40
  esr:         96000004
panic: vm_fault failed: ffff0000004ce004 error 1
cpuid = 0
time = 1
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+0x308
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
thread_init() at thread_init+0xa4
keg_alloc_slab() at keg_alloc_slab+0x24c
zone_import() at zone_import+0xe0
cache_alloc() at cache_alloc+0x32c
cache_alloc_retry() at cache_alloc_retry+0x2c
thread_alloc() at thread_alloc+0x38
fork1() at fork1+0x348
kproc_create() at kproc_create+0x78
audit_worker_init() at audit_worker_init+0x44
mi_startup() at mi_startup+0x200
virtdone() at virtdone+0x6c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x44: undefined       f900027f
db> show reg
spsr        0xf2000000600000c5
x0                        0x12
x1                         0xa
x2                           0
x3                         0xa
x4          0xffff0000007f5c10  generic_bs_w_4
x5                        0x50
x6          0xffff00000051244c  kvprintf+0x470
x7                        0xd5
x8                         0x1
x9          0x49a2d892bc05a0b1
x10         0xffff000000ebd000  null_gdb_dbgport+0x20
x11         0xfefefefefefefeff
x12         0xffff000000000a63  create_pagetables+0x3b
x13             0xfefefeff0100
x14                          0
x15                          0
x16                          0
x17                          0
x18         0xffff000000fcf310  initstack+0x3310
x19         0xffff000000f16000  kdb_why
x20         0xffff000000ee3f70  vpanic.buf
x21         0xffff000000ec0cc0  thread0_st
x22                          0
x23         0xffff000000ee4000  vpanic.buf+0x90
x24                        0x1
x25         0xffff000000fcfaa0  initstack+0x3aa0
x26         0xffff000000c73000  sdta_vfs_vop_vop_spare4_return1+0x18
x27                        0x2
x28                        0x1
x29         0xffff000000fcf310  initstack+0x3310
lr          0xffff00000050b0c4  kdb_enter+0x40
elr         0xffff00000050b0c8  kdb_enter+0x44
sp          0xffff000000fcf310  initstack+0x3310
kdb_enter+0x44: undefined       f900027f


-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Thu Jan  5 20:23:32 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 4NnybW4blPz2p7Ff
	for ; Thu,  5 Jan 2023 20:23:35 +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 4NnybW3CyQz3N6f
	for ; Thu,  5 Jan 2023 20:23:35 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
	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 5227B8D4A142;
	Thu,  5 Jan 2023 20:23:34 +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 09A6A5C3A833;
	Thu,  5 Jan 2023 20:23:34 +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 1XS84srKZAPw; Thu,  5 Jan 2023 20:23:32 +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 79B1E5C3A830;
	Thu,  5 Jan 2023 20:23:32 +0000 (UTC)
Date: Thu, 5 Jan 2023 20:23:32 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: =?UTF-8?Q?Klaus_K=C3=BCchemann?= 
cc: freebsd-arm@freebsd.org
Subject: Re: (RPi) db> reboot -> cpu_reset failed
In-Reply-To: <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
Message-ID: <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>   <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
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: multipart/mixed; boundary="1098556516-1840519658-1672950212=:27118"
X-Rspamd-Queue-Id: 4NnybW3CyQz3N6f
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1098556516-1840519658-1672950212=:27118
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 5 Jan 2023, Klaus Küchemann wrote:

> Hi Björn,
> ( ..I had a JTAG setup on the PI, but didn’t use it for some time..)
>
> yes that was a  "live“ boot example from today of the cm4(on orig. I/O-board),
> it hangs while initializing sdhci, while the boot partition is living on the emmc :
> —

Ok, I am just wondering given reboot works fine why reset in db>
wouldn't.  Given you have JTAG setup you can probably debug a lot better
than me but also you seem to have a different problem ...  too many
problems too short time *sigh*


>> Am 05.01.2023 um 19:48 schrieb Bjoern A. Zeeb :
>>
>> On Thu, 5 Jan 2023, Klaus Küchemann wrote:
>>
>> Hi Klaus,
>>
>>>> Am 05.01.2023 um 17:37 schrieb Bjoern A. Zeeb :
>>>>
>>>> Hi,
>>>>
>>>> given I currently find myself debugging more PIs again, what is needed
>>>> to be able to reset from the db> prompt?
>>>>
>>>> Currently I get "cpu_reset failed" when trying.
>>>>
>>>> Needing remote hands or an OOB PDU to cycle the PI is not satisfying.
>>>>
>>>> /bz
>>>>
>>>> --
>>>> Bjoern A. Zeeb                                                     r15:7
>>>>
>>>
>>>
>>> you even cannot be sure to reach the ddb prompt at panic, like here :
>>>
>>> --
>>> ..
>>> KDB: stack backtrace:
>>> ..
>>> #14 0xffff0000000008b4 at virtdone+0x78
>>> Uptime: 1s
>>> --
>>> ..and good night Pi ..
>>>
>>> halt/resume of CPU is more promising by setting up a JTAG controller.
>>
>> does this mean you are running into the issue at boot as well or was
>> that just a (made up) example?
>>
>> --
>> Bjoern A. Zeeb                                                     r15:7
>
>
>
>

-- 
Bjoern A. Zeeb                                                     r15:7
--1098556516-1840519658-1672950212=:27118--

From nobody Thu Jan  5 20:43: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 4Nnz3M2LGDz2p98f
	for ; Thu,  5 Jan 2023 20:44:15 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4Nnz3L5Gygz3PgP
	for ; Thu,  5 Jan 2023 20:44:14 +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=1672951452; bh=waY3RqVNY5WXEIRqqK2OKPyCDzQjgBymhE4E4rmPJ/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=n263ZLOyQvTJvPwRRFV//MMYPQ6hy9Ib2HX/FpiDvYtcgb6DlulYSxwFvgK1I5WprbzymofINgjamMCVv60iBRlIk99iTv4hnk28P5ujmzuk7gdg3hgbZyu4Nny1LNjCqgQEZqh07c58obJRXu8SC8d2C9lhepp91jjM9dXJvzh4rPRHr27HFPLxDAxuh3IoNySdh17blWMHV6w7ul5rPOiC5YphIj+h2OeAQ/MXNMJU+IjqOH7/fzbERDremngxKTbhNSmrzTYVDGHgv1uDbZJQh/ovabYf9qweejvZBTXBQ1jpbH2MHWXnarMmpnPsHncoCVXWU7i6jN7K56+axA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672951452; bh=q/rSudK5q+1bOCbc+kAqL3TXaGjPlweCA7EGyGmvg1o=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pO3agtArX7amm6Dk/kmJ/ic+msDM6RhVNrBrytm+MivEBrSKirYbg0V1a87K/OKxEHgk2cmGnAdYFWoO9Rn4gsOEox1Cy3UdP9HhQce/BVY2RgD3u4UNG2HMYFf9HP331W/t8zgiOPeg+FSjaY0y5Or5HySg0jmhaRLstpdjl1vEZeqHi/DeOWdCuIE6FHb3mNpGlg3UaOvWalNCWOjX32QUzOKU7BJKHXbl7zbcvLICmLifoDxpXCUnlnZJBDrz3OF5WRbpql2DSVVUMYBilS16WSak/uUNNdjkQjjDzPNuOEDO9BF02bg0i+f96bWdr//qnzEvJci4pFfIfhGCvw==
X-YMail-OSG: NztgrTUVM1k4OscybCLTT08HBtmx3YPBcho1V9W8HwvPKKq2TqY9RexCN14aNHF
 XekPM5FBr4kWMS8fuwTORXhb02OC_8jHHasvooKr6bqYQtPAZKMVgIoyAC8MCANzVDaBfhlMKLHo
 UnvpUbwLnPdaOrizvwXaleF2X4xos_g2ydmJ_YrxsAYAXOL3d2H25csrii4ZgTSk3.mf3Jqq6PWG
 iBLRxAuAz2zQbAcw0C1pzZcY8M9acgqxayyHfpbKziysSj6.kEwR65CDFbLe23UNdBij_0ojFxjs
 ugh.iJha1CkoUQDpOTUTcofWSv9Gk4tbcqUdFfwhch96g0mtbRDRGWQfAEgV3Gla..CJipJje8uE
 FlZGT30Q1YG6sXVUc2YAYOKJjeQQM89f2w.NTKCvmvcrrWi8wHWh.ugJohIxC.BIH_7Rn0obh.IG
 HqPPqIVTCQU1jqJNbQUoWnoPO3tWPphLzzh3XZdrU.aHd4YbeOgajhEV6XvNBNDEQ9t9TR9MBJuR
 uTngUOB3rasofoIcN9COpcKaUxMeOc4xKI2uernHYXD3IxxIwLXbQ7iriA7zRtpPwmygwtiW8hs7
 iyygVJNm8GU6qyh2ZIz6QnEHMCy1LtZmdjIbpMfpIdUILTEYaLxyM_BhrLCIlRLlL4kJ0kt8zWvk
 WCOajmAE2Z4GPRxk2gpeITkrq1nqunztAVZkZJXL5vLm4j6mAYT8LMHOMG2jq1JHlqB0FhBjXbk_
 t8KcO2joa_fcjKmfzae0RQ0MYj2zb530jM_2OLfhje5jxrPU6sXUs9ZEaetT1OfTmzUZh2ETHoNb
 DE7Ezo9GrIyGzVgwBZR22WWmcHDAXlCHqPu6NykWMUhJmS7Lo2MV9TsgOuDs2GHVqzqhkC6XhMoH
 SvsqOprt19FNpBmCJWmZQbwX1Ij9vKWHYccwGAWN7zl.d5o5Yw8qte2L5K618X5Av_MUcc74nlcU
 sidiJoL.JIkMq8ht7h0PJsT_eixlAL47uBSdN.5RiD3SyP5rLYRWOWGpoD_VSaPQQFqozlDVW.W5
 CGDZ8IQQfZtPiIhPbdjS.Jk8LceK_Va1XCcfdRp4CAGOZMTDzijI3duoWE.v8mApnadTjlHnUdbX
 hV0LyYzFpTqJ0ywD5vEjBfZoQ3hNLf3_X2DYIj823F7jSSRH5dalHycOqMWungrTi_x9NsrnxXY7
 FGPgEvDHuISQsFhIkI7Bu14X5w4mlOjgyjdNd.G_IZeE4eKafauttcLwj9ewT7d2YQzcWSF_pSvB
 20bACgGMpZUMFGbgoYTU38x2D7aM0ABfQVHQnIuSTuSAEeoRyW6dMmGm6UOOiVY9x9kg7NMaIiBV
 mGvYGJw9Zu4oD9Z2hBg3RZtx0zAWJnhnETaoDRhMeYbHCb3eW8AJVrYE_2vtN.uMJDJXfDTskp_b
 h.NUVCu5s8zyFpvQ_8QjkZku.GFXumkokUfYpMGyWWMy521QfBK3440iTKp2wT52GJSk4xmHStli
 lFkAXVx8OXdeLIHgTpZukC5eoT5zq3uhshgOm9kx0rXKQFLugX302MIVuW9FpeN0TCElsG0wJEJ_
 hkIN6_.H4JKfm728KZSthocwPLcuqUyvsKEwpatKauOH1h1vFTlM6ReEv9cZDfqPRcBPg3ifkTbu
 EbRZeLWhdkj20Sn668IeqLN.r_wrjAeSUSc8MikaPYhDC92WfE.Y53bsqSXMI16ReShtZk28u4Ne
 G8uO1PFhu4yAJF0hACSQdeQYNQJTCqEc8d7ehe7oGY11O1L8WzVheIy10ntBD5aIWtOwTysxXUvp
 J_K3sT3Hm9e31v9ymSGuLoYpwTLj6hi7_AAjx6DJos5Vy9falUlJiO.6tUqgSVoZjSllw44Ktoxs
 rDVMHkSOYZSxrFL.i3S0SNFdqY3XhKIoijzX00VFiGIpwk_Ptc4Hg27XHYc.qSQ1zLelOB3WCYyC
 ceR0_4HG7SIw.zhCigsBTxariMq__N3YpoSfK_msbFbZA1IPvuoabAXVSMTaTcyLoGDeohcxCdQG
 t9dGM.oDbXJZY7JEovvAoJn1jw3XDow6ONu3eXFWA2pUkf589RPlDw.GzBA127tBLs57Mf6S8BwT
 HGbbHGYUm2UVWM19Tckbuv4pQrzSRfKLtcf.1GfkagOsrlx9qmZiuuySedkObO.tOtKnkFmbJc7B
 rdeu_yfYskoYBuUbzMA_591twWa7dz2MKvGVgFWRLOcT4Pi8tiR2gGSukv5bARgZJON.62TnpiG.
 n2hNHgD0ZcWrJUXLxnUQLO3SCEQArq4mjH4rUCKiXsUdrtRF1hNJ66kMi5_dmME_.A5FCGH3FxQ-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 5 Jan 2023 20:44:12 +0000
Received: by hermes--production-gq1-d898c4779-ffgf5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID abc27045f60bc1f6004ae428f0076c36;
          Thu, 05 Jan 2023 20:44:08 +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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash]
From: Mark Millard 
In-Reply-To: <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
Date: Thu, 5 Jan 2023 12:43:58 -0800
Cc: "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Nnz3L5Gygz3PgP
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 5, 2023, at 11:32, Klaus K=C3=BCchemann =
 wrote:

> Hi Bj=C3=B6rn,
> ( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some =
time..)
>=20
> yes that was a  "live=E2=80=9C boot example from today of the cm4(on =
orig. I/O-board),
> it hangs while initializing sdhci, while the boot partition is living =
on the emmc :
> =E2=80=94
>=20
> sdhci_bcm0:  mem 0x7e300000-0x7e3000ff =
irq 24 on simplebus0
> Fatal data abort:
>  x0:         ffffffff
>  x1: ffff00000092b404
>  x2:                0
>  x3:                6
>  x4: ffff000000fdf77c
>  x5: ffff000000fdf72c
>  x6:          4000000
>  x7:          4000000
>  x8: ffff000000dfb6a0
>  x9:               20
> x10:                0
> x11:                1
> x12:  300000000006e65
> x13:   fefefefeff0100
> x14:               1d
> x15:                0
> x16:                0
> x17:                0
> x18: ffff000000fdf7e0
> x19:         ffffffff
> x20:                0
> x21: ffff000000bad000
> x22: ffff000000bad000
> x23: ffffa00000f8f038
> x24: ffff00000091b5b2
> x25: ffff0000008dfc9c
> x26: ffff0000009436b6
> x27: ffffa00000f8b140
> x28:         32000000
> x29: ffff000000fdf7e0
>  sp: ffff000000fdf7e0
>  lr: ffff000000868040
> elr: ffff0000008620d4
> spsr:         a00000c5
> far:               20
> esr:         96000004
> panic: vm_fault failed: ffff0000008620d4
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> #0 0xffff000000516458 at kdb_backtrace+0x60
> #1 0xffff0000004c24ac at vpanic+0x174
> #2 0xffff0000004c2334 at panic+0x44
> #3 0xffff0000007f48c0 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086803c at bcm_sdhci_attach+0x314
> #6 0xffff00000086803c at bcm_sdhci_attach+0x314
> #7 0xffff000000502428 at device_attach+0x3fc
> #8 0xffff000000504514 at bus_generic_new_pass+0x120
> #9 0xffff0000005044a4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005044a4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005044a4 at bus_generic_new_pass+0xb0
> #12 0xffff0000005065f4 at root_bus_configure+0x40
> #13 0xffff000000439ee8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
> Uptime: 1s
>=20

You are using modern enough RPI* firmware that the FreeBSD
kernel does not tolerate it. Same sort of backtrace as I
reported back in 2022-Apr when I explored what RPi*
firmware releases avoided kernel crashes on RPi4B's,
such as:

KDB: stack backtrace:
#0 0xffff000000516268 at kdb_backtrace+0x60
#1 0xffff0000004c22bc at vpanic+0x174
#2 0xffff0000004c2144 at panic+0x44
#3 0xffff0000007f4928 at data_abort+0x204
#4 0xffff0000007d5010 at handle_el1h_sync+0x10
#5 0xffff00000086809c at bcm_sdhci_attach+0x314
#6 0xffff00000086809c at bcm_sdhci_attach+0x314
#7 0xffff000000502238 at device_attach+0x3fc
#8 0xffff000000504324 at bus_generic_new_pass+0x120
#9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
#12 0xffff000000506404 at root_bus_configure+0x40
#13 0xffff000000439cf8 at mi_startup+0x11c
#14 0xffff0000000008b4 at virtdone+0x78

In:

https://lists.freebsd.org/archives/freebsd-arm/2022-December/002115.html

I reported what I'm experimenting with (2nd version) for 13.1 and
main for allowing modern RPi* firmware. It basically leads to
bcm_dma being set up earlier so it is available for reference in
the bcm_sdhci_attach activity.

If you build your own kernel with the type of patching that
I report, the specific crash should disappear and booting
with modern RPi* firmware seems to have worked for me so
far on the machines I've done the experimenting on.

Expect more messages caused by new things in the .dtb files
that the kernel does not support but keeps rechecking during
boot. Sort of a noisy form of otherwise-ignored.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Jan  5 22:57: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 4Np21J2KDDz2pTS0
	for ; Thu,  5 Jan 2023 22:57:40 +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 4Np21H45vWz3qs4
	for ; Thu,  5 Jan 2023 22:57:39 +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 933BE8D4A142
	for ; Thu,  5 Jan 2023 22:57:37 +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 45C2B5C3A833
	for ; Thu,  5 Jan 2023 22:57:37 +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 WZUn1iE9tAeu for ;
	Thu,  5 Jan 2023 22:57:35 +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 53F895C3A830
	for ; Thu,  5 Jan 2023 22:57:35 +0000 (UTC)
Date: Thu, 5 Jan 2023 22:57:34 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: freebsd-arm@freebsd.org
Subject: Re: panic: vm_fault failed: %lx error 1 (from arm64::data_abort)
In-Reply-To: 
Message-ID: <90oq9666-s818-ons1-1333-629opssq237n@mnoonqbm.arg>
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 [-3.27 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.972];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[zabbadoz.net];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4Np21H45vWz3qs4
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:

> On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:
>
> Hi,
>
>> on an unattended console after updating the machine (previious builds were 
>> Dec 23) did not come back up.
>> I have a few last lines.
>> 
>> esr:   96000004
>> panic: vm_fault failed:  error 1
>> cpuid = 0
>> time = 1
>> KDB: stack backtrace:
>> ..
>> data_abort()
>> ..
>> --- exception, esr 0x96000004
>> thread_init()
>> keg_alloc_slap()
>> zone_import()
>> cache_alloc()
>> cace_alloc_retry()
>> thread_alloc()
>> fork()
>> kproc_create()
>> audit_worker_init()
>> mi_startup()
>> virtdone()
>
> Follow-up, got a serial console hooked up and a kernel as of an hour ago
> or so:

And as another data point:  6fd6a0e342fbfb8513ae56105cf0f85f55c6276e
(Dec 23) does boot still just fine; did a rebuild with all the same
local changes, same kernel modules loaded, ... same loader installed
(not changed with the dowgrade), same firmware, ...

I'll try to bisect the next days unless someone can spot any other
commit I may have missed which could cause this.

/bz


> ...
> hostuuid: using 00000000-0000-0000-0000-000000000000
> ULE: setup cpu 0
> ULE: setup cpu 1
> ULE: setup cpu 2
> ULE: setup cpu 3
> Fatal data abort:
>  x0: ffffa000008c1d80
>  x1:                0
>  x2:                2
>  x3:                3
>  x4:              203
>  x5:                0
>  x6: ffffffffffffffff
>  x7:             2001
>  x8: ffff000000ee5000 (dump_encrypted_write.buf + f54)
>  x9:                0
> x10: ffffa00000845be0
> x11:                2
> x12: ffff00004041dd98 (fuse_mtx + 3c276888)
> x13:   20000000000040
> x14:           42c000
> x15:                1
> x16:                c
> x17:            4082a
> x18: ffff000000fcf6a0 (initstack + 36a0)
> x19: ffff00004082b000 (fuse_mtx + 3c683af0)
> x20:                0
> x21: ffff00004082b000 (fuse_mtx + 3c683af0)
> x22:                2
> x23:                0
> x24: ffff00004082d000 (fuse_mtx + 3c685af0)
> x25:                0
> x26: ffff000000c73000 (sdta_vfs_vop_vop_spare4_return1 + 18)
> x27:                2
> x28:                1
> x29: ffff000000fcf6a0 (initstack + 36a0)
>  sp: ffff000000fcf6a0
>  lr: ffff0000004cdff8 (thread_init + 98)
> elr: ffff0000004ce004 (thread_init + a4)
> spsr:         600000c5
> far:               40
> esr:         96000004
> panic: vm_fault failed: ffff0000004ce004 error 1
> cpuid = 0
> time = 1
> 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+0x308
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> thread_init() at thread_init+0xa4
> keg_alloc_slab() at keg_alloc_slab+0x24c
> zone_import() at zone_import+0xe0
> cache_alloc() at cache_alloc+0x32c
> cache_alloc_retry() at cache_alloc_retry+0x2c
> thread_alloc() at thread_alloc+0x38
> fork1() at fork1+0x348
> kproc_create() at kproc_create+0x78
> audit_worker_init() at audit_worker_init+0x44
> mi_startup() at mi_startup+0x200
> virtdone() at virtdone+0x6c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x44: undefined       f900027f
> db> show reg
> spsr        0xf2000000600000c5
> x0                        0x12
> x1                         0xa
> x2                           0
> x3                         0xa
> x4          0xffff0000007f5c10  generic_bs_w_4
> x5                        0x50
> x6          0xffff00000051244c  kvprintf+0x470
> x7                        0xd5
> x8                         0x1
> x9          0x49a2d892bc05a0b1
> x10         0xffff000000ebd000  null_gdb_dbgport+0x20
> x11         0xfefefefefefefeff
> x12         0xffff000000000a63  create_pagetables+0x3b
> x13             0xfefefeff0100
> x14                          0
> x15                          0
> x16                          0
> x17                          0
> x18         0xffff000000fcf310  initstack+0x3310
> x19         0xffff000000f16000  kdb_why
> x20         0xffff000000ee3f70  vpanic.buf
> x21         0xffff000000ec0cc0  thread0_st
> x22                          0
> x23         0xffff000000ee4000  vpanic.buf+0x90
> x24                        0x1
> x25         0xffff000000fcfaa0  initstack+0x3aa0
> x26         0xffff000000c73000  sdta_vfs_vop_vop_spare4_return1+0x18
> x27                        0x2
> x28                        0x1
> x29         0xffff000000fcf310  initstack+0x3310
> lr          0xffff00000050b0c4  kdb_enter+0x40
> elr         0xffff00000050b0c8  kdb_enter+0x44
> sp          0xffff000000fcf310  initstack+0x3310
> kdb_enter+0x44: undefined       f900027f
>
>
>

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Fri Jan  6 03:58: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 4Np8hD1SBTz2pQNR
	for ; Fri,  6 Jan 2023 03:58:20 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.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 4Np8hB6J27z4Lqy
	for ; Fri,  6 Jan 2023 03:58:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=lB1OE3gB;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 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=1672977497; bh=LafsfJKyxqGN5bjZN4TibdqCP91UUueOuKjHHQjWUC0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=lB1OE3gBV7fvmKi1uyMtG6UKwBtwlv6bLTIFZCYd2cpVNsdcbyRS8bvRo6Utjxa+kMzzZtLXIybQA0nUbqIzr56fuka/27tvc7ovy3dYAk5SFORXzvdTK1YwjotqVW2OpvBqoYjwx2YDqnj+2M+4yvkK8jR29GHAJB+pmTmng2G8MWNvUKMTVA3cEjGx0G3PPbFMY46DApboMWx1BwEqePsR5sBoeyWZGug0nzQQul7fvDuws634UbyVNK75twLuezCzctthtSulASbMv4Oo9dbJs42vYoOvpoz/r20HoqURDXfOpKYEQk+FYj5aAvrnZAPHs52qYGhWCau7AgXS0A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672977497; bh=IafZEzbCxeiaT+PFiOfc7k3OB89d761jI9RGRXaLtDU=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=PNo2iiY1IZlsju1Ixa7zA9HCkOK5SLBYMoyiV4AEUou+3DDZ+h/lSvfJfloEURuaiXFdupa+xCiXZ7uPAPBhWmnOnywhIBaGeMLCGMzoQtkVotknqaWgk0S5vkkyOG7z4+/1b6rY1+ZJ/Oj8zlM9sa3ncs3Eqa7VGXWx2OrprGbTf5/ljPD+jWnOOvhPOBI1Xn3a47X+muHt/mBdgiksSDaApmJvctK14OB3H9kFag4azK82K4axd3k1A+XzspFeYjxXWY0+K5HMwvWAokPxD67nSxtQMovlyeZcjPVV6z3Xp445ef2gIxqaYcKti7i1Jyl0RdgKvzyOW5Iqa44g0A==
X-YMail-OSG: BaJGlxEVM1liHf2RP3wnt.F4qMplsuQrVTvE4viZFSJVvox0yPniVv4UBLKuwUv
 ZkFl8grFKMogmL7Z6T8u_DMGUBm.8h.zcX8FgbQc.wKafaLi4JWVqNf.lrZhYZf3Ybk75fN3W_CU
 h0OaJLFtcdedpDP5hVtuce91Xy_NHqymrj7M3sF9DyyRB833HS5ibth.5479KemY.vHtLqMlhf90
 sg5VkJqPwzP1sQCvFLS_FpZV_j0cEUBZReFmfKm0FUJdiqw0E.iCuKTqc7DB2ClUNxy9qg7OBeK9
 9g8_NnW7BBDVxwgWOzLhUs1r2yHhxoa7QxLkyT6MjQ2qOhnI3RR8JADGyBmB2iM_ngqRH_xclybG
 5bPMymezEr0vOIGC8ebHZF8wVyPzxTMOO2NRW3Vysgqxs_bm6INToyTYPtS2ROj786q4YimAyLL2
 z5JPwlCoUDVp7kiBkdtNR2unWxdLAJCEElrqaSnvEZGsVeyh2e7gQLJ4Qs5_Sz0egH_xiUlKiDOk
 Co4tKpdvZBdcrtzyHeXNNW_8qUMSxN5P19fd74ik.PEKUuv1bhTEwb0zAMmp0e1012dlw8Qi2p8T
 hRbmJOiz3139k.qqaru9HkTHfgR_TtZl713gj0W0TeXCBzKTHzwe8oLDRpFe8BeMFH2IOXdfSjxZ
 Ji4701waxpP_dNTvF1gRFH7_U00XrRlJiasTASKDy_39W9Db_LdnSWiu5NpyvWqxIF_gMMss8Azn
 7Ci_IXWyz5aYol.vu6NFu5JhZXuDwxs.hmDgAXiabAvzfOGgb9TzfBuanvygI7plAVuRmkuhwUOq
 _xKD_6Lr4DVssZlJKNFdQkf84fHfeV80JHZQoqkxQaHTNVzRzB9WgzTxE2Vq8z0BMK5N2zzze483
 4IA.jM09l4xe11B5AqdYU3AmwoRk5klBl_1l1PT8T1I2_Xqc.t9ERoXyyOYMS62xk6yZpVhBg0uh
 z.DhAAL8FYaQeh9a1NAOgNSddMWemYbGBNy9VbVynUnHpyfudlX6cxr3WvZ4X6tdMMrPcAIxYbbM
 XAFlE0G9RGYuxr076hoQcs5EWP5aIp8aP1xTn2vZhGNbHNuapUjfXIDvTa28LpH1SjWWYP1ME.3a
 JShF4vetEun8f59WpsRFfoj7k4L2ZkQc0sPlgxBkIByI8asXlPBvvVTnu8gepl_RwwLluHtvGP67
 s_MXDtaeRc2jcyGG9V7izTPnj2G0ixrlNSa04J.TMik1aufemjqFt3ILdB7l60U.h1DA97_NPnX7
 ZaABPO877f4EZK7bdNN1qP7Rfwh9gALTAhvrbmRrw_HDvRABXBdn_.VHaJcLoDW5yeCGcdtlwRsY
 ZKYWxJDxFxiXXVi8.0ZBfG1CQN47nodMBO4DMHZ6y7XmY8sTnWyE9lbHs46ajQrpxUdAtpbxkzsU
 RA6Kx82JqvMjUl2sonX4l6FnKv.VOdw4N9jaeraK_y1eddkSKBfC1hvG_4VdCRCeQMhEVDNqGNrx
 znZCfcckp85HAUxOne83g5_rRGeX6OEQjzwH45kxjSrhS9Zco4DRymWNwRgn0AjDgEddA8wjEmtP
 5mdZGBc73qrKcNSKRjh9W_tSkAudVfwLDl5xZ1ZEF.iHfjhlTT.Weq92Czwlq_Hye2DyL8O9vMdx
 O0M0lla39puG5qYV6p.wT6HktPreaxOcLOT5UQH1ikIn22vZPeu_qmAg6vXRgTWMSvifKUe43Xxl
 8iyfwVlAwJrRTP4s6FYBbHlfc3BAJpxJGYzs1HsrVLBbFT1FAPNxO9JnTX.zU5yguCRc7.XwMNO1
 vfpYiO8tGgOovy7zi1tR7weBg6qjRcYnaCSZsYiHniK_Qv.XuN1sJp4FD02bUs5xbbBq8fS7dXwL
 CP29Y1abW1V9ij5oKurlkkQj4YtC5n9eISDuqeu5sRPEfLUq75gHX4nLwIIyOg8Jlnpd1YZs26C4
 fvlaUN4RrVrIWFxTH7SqxBCHhCg41tMNp8LviW8POTb_mBt9e39kMRhcjEtYzDz2Ithf0ix14ngf
 J_Phz1_ClYVazK7ag1lGRDiFXKeJ1Z3vJmtIWZLNb4FkPlGZ2aYz6m_NMvvMqbmIA8xpb_yL37se
 ivmsQBJBp5FFGqwZn2cxT9yMCx.LMnClk7lcPi.xnoEd12qYkyeWA2fQ5MFuk4asmxycjpxRRC4i
 CBYK_lvD5YDSEIQkDqFWRfrthDSX186BHCVMn8WSwk.fOx311XN7NBR2wCNyuyUkP.iTvvjKuIPj
 AZIDJkraSqQHRtPTydrZE0kJyPD150yhUucReGEqI9vCZ4ewkgIip2xPjbW6nlhOG6czCIsRV
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 6 Jan 2023 03:58:17 +0000
Received: by hermes--production-ne1-7b69748c4d-55l5b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f9dac93065fa284687d28c050b8ddb02;
          Fri, 06 Jan 2023 03:58:15 +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.300.101.1.3\))
Subject: Re: panic: vm_fault failed: %lx error 1 (from arm64::data_abort)
Date: Thu, 5 Jan 2023 19:58:03 -0800
References: <03ED0C15-F2D0-4BCD-BB79-05680AE6C459@yahoo.com>
To: "Bjoern A. Zeeb" ,
 freebsd-arm 
In-Reply-To: <03ED0C15-F2D0-4BCD-BB79-05680AE6C459@yahoo.com>
Message-Id: <8755AE91-CC27-4D73-855B-38FB384EE0C1@yahoo.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
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.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Np8hB6J27z4Lqy
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

[Just adding the missing Email address so it goes to the list.]

On Jan 5, 2023, at 19:56, Mark Millard  wrote:

Bjoern A. Zeeb  wrote on
Date: Thu, 05 Jan 2023 22:57:34 UTC :

> On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:
>=20
>> On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:
>>=20
>> Hi,
>>=20
>>> on an unattended console after updating the machine (previious =
builds were=20
>>> Dec 23) did not come back up.
>>> I have a few last lines.
>>>=20
>>> esr: 96000004
>>> panic: vm_fault failed:  error 1
>>> cpuid =3D 0
>>> time =3D 1
>>> KDB: stack backtrace:
>>> ..
>>> data_abort()
>>> ..
>>> --- exception, esr 0x96000004
>>> thread_init()
>>> keg_alloc_slap()
>>> zone_import()
>>> cache_alloc()
>>> cace_alloc_retry()
>>> thread_alloc()
>>> fork()
>>> kproc_create()
>>> audit_worker_init()
>>> mi_startup()
>>> virtdone()
>>=20
>> Follow-up, got a serial console hooked up and a kernel as of an hour =
ago
>> or so:
>=20
> And as another data point: 6fd6a0e342fbfb8513ae56105cf0f85f55c6276e
> (Dec 23) does boot still just fine; did a rebuild with all the same
> local changes, same kernel modules loaded, ... same loader installed
> (not changed with the dowgrade), same firmware, ...
>=20
> I'll try to bisect the next days unless someone can spot any other
> commit I may have missed which could cause this.

As a contrast, I've dd'd to microsd card media and booted:

=
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230101-231d75568f16-259905.img.xz=
 =


231d75568f16 is from:

   =E2=80=A2 Sat, 31 Dec 2022
      . . .
       =E2=80=A2 git: 231d75568f16 - main - Move INVLPG to =
pmap_quick_enter_page() from pmap_quick_remove_page(). Konstantin =
Belousov

So: the last listed for 2022-Dec-31.

I've booted on a couple of RPi4B's ("C0T" and "B0T" 8 GiByte
ones as I remember). No boot crashes or such. You might want
to test if such crashes in your context. If it does not, then
something more specific to your environment is involved.

I sometimes do rough/partial kernel "bisect" via materials from:

https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD

without having to build. For one, if I get a replication then my
personal builds are not the source of whatever problem I'm
looking into at the time. Otherwise . . .


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jan  6 04:41:36 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 4Np9fT71ypz2qlfZ
	for ; Fri,  6 Jan 2023 04:41:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 4Np9fT4gTYz4Pty
	for ; Fri,  6 Jan 2023 04:41:53 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62c.google.com with SMTP id vm8so1241310ejc.2
        for ; Thu, 05 Jan 2023 20:41:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=niUKx2f8W+UBjI//J/2wulydmSH0nmA28qC/Us2RoKg=;
        b=UlSNkWEZtndy772mfogtLQ2fNKU38OqPYi9RfKglGDArBRu3uxKrnizLE2esStUaRh
         CNczhq5W9G1/fXM2/U0KFfZS7/Wcjf/FXQkkfidxlDI+oplLNx2hLoQD4F4RcQ7RhzBq
         k+RvwhFTAnpGjH1EmzW/ucxJjeNjsuScXIU+VDT2kjcQZdQDkJLaHpvW3eMykazeld+q
         aKdp4j+tkAdMABwrT7fc/3WJNomsmkw6GtYPJtfv3EHUG6a4vwiPd61Ty7pVgsaZ0ulN
         5QdJjISjHBy82YOgAHNSh+SokkKMujiEsfMElNh5KrrGkzPXzLQbe31EZP0yXyJfTtDW
         TOEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=niUKx2f8W+UBjI//J/2wulydmSH0nmA28qC/Us2RoKg=;
        b=eZbB5LwV5u8/SetHUfO5LI8BxHc/8E77ei97gRebLD1rLeJHB8Iza3SqyCUtXsbfBr
         FINlWMv0IBkVHD4FRS/tqYixbeX7gbLnHyDS88M9QOvXmgWcgcSQpVPUVJ4if/pMg0nY
         T1nQTawYBGTe8uWEstJmRvyN1I4CuHGdcBf/vVVMHaHE4fspib+/pfPgDbgwoDKW0pHJ
         +7sfmPkfHDEaEv7ZzbhBth5C8b8x1jzAXwHOoLdRWlJvgIowjdbnjsSMQXSzwniCQ2HN
         GDMDbfx/cHF4y0zrkYDNmGHuQkXPQpQ4N2Si0TFFtrJVsbTlBFQ/oxZdMsVTuLC4LyW1
         RI+g==
X-Gm-Message-State: AFqh2kq5Dr1nE3cJx76yAwsLGBXrSnxHn60TFCNWjP1yVj+DuTvmYtvQ
	2X/NgLR0ElQuGKBMCl6qvYA=
X-Google-Smtp-Source: AMrXdXusVw1QpDiWSDTa6iZ+6tiQrughuaEQeqSmjJmwRX6bHs3VTAW0g4P9+9VsjNZclTsMl32tYQ==
X-Received: by 2002:a17:906:3c18:b0:7ba:9b49:53d4 with SMTP id h24-20020a1709063c1800b007ba9b4953d4mr44466620ejg.71.1672980109403;
        Thu, 05 Jan 2023 20:41:49 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-061-228.46.114.pool.telefonica.de. [46.114.61.228])
        by smtp.googlemail.com with ESMTPSA id g10-20020a17090604ca00b007aef930360asm29277eja.59.2023.01.05.20.41.48
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 05 Jan 2023 20:41:48 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash]
Date: Fri, 6 Jan 2023 05:41:36 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com>
To: Mark Millard ,
 "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
In-Reply-To: <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com>
Message-Id: <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Np9fT4gTYz4Pty
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Mark, thanks for the detailed hints !

I will investigate in that firmware issues/your suggested patch,=20
and will report back later.

Regards

K.


> Am 05.01.2023 um 21:43 schrieb Mark Millard :
>=20
> On Jan 5, 2023, at 11:32, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Hi Bj=C3=B6rn,
>> ( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some =
time..)
>>=20
>> yes that was a  "live=E2=80=9C boot example from today of the cm4(on =
orig. I/O-board),
>> it hangs while initializing sdhci, while the boot partition is living =
on the emmc :
>> =E2=80=94
>>=20
>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>> Fatal data abort:
>> x0:         ffffffff
>> x1: ffff00000092b404
>> x2:                0
>> x3:                6
>> x4: ffff000000fdf77c
>> x5: ffff000000fdf72c
>> x6:          4000000
>> x7:          4000000
>> x8: ffff000000dfb6a0
>> x9:               20
>> x10:                0
>> x11:                1
>> x12:  300000000006e65
>> x13:   fefefefeff0100
>> x14:               1d
>> x15:                0
>> x16:                0
>> x17:                0
>> x18: ffff000000fdf7e0
>> x19:         ffffffff
>> x20:                0
>> x21: ffff000000bad000
>> x22: ffff000000bad000
>> x23: ffffa00000f8f038
>> x24: ffff00000091b5b2
>> x25: ffff0000008dfc9c
>> x26: ffff0000009436b6
>> x27: ffffa00000f8b140
>> x28:         32000000
>> x29: ffff000000fdf7e0
>> sp: ffff000000fdf7e0
>> lr: ffff000000868040
>> elr: ffff0000008620d4
>> spsr:         a00000c5
>> far:               20
>> esr:         96000004
>> panic: vm_fault failed: ffff0000008620d4
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> #0 0xffff000000516458 at kdb_backtrace+0x60
>> #1 0xffff0000004c24ac at vpanic+0x174
>> #2 0xffff0000004c2334 at panic+0x44
>> #3 0xffff0000007f48c0 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086803c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086803c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502428 at device_attach+0x3fc
>> #8 0xffff000000504514 at bus_generic_new_pass+0x120
>> #9 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>> #12 0xffff0000005065f4 at root_bus_configure+0x40
>> #13 0xffff000000439ee8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>> Uptime: 1s
>>=20
>=20
> You are using modern enough RPI* firmware that the FreeBSD
> kernel does not tolerate it. Same sort of backtrace as I
> reported back in 2022-Apr when I explored what RPi*
> firmware releases avoided kernel crashes on RPi4B's,
> such as:
>=20
> KDB: stack backtrace:
> #0 0xffff000000516268 at kdb_backtrace+0x60
> #1 0xffff0000004c22bc at vpanic+0x174
> #2 0xffff0000004c2144 at panic+0x44
> #3 0xffff0000007f4928 at data_abort+0x204
> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
> #7 0xffff000000502238 at device_attach+0x3fc
> #8 0xffff000000504324 at bus_generic_new_pass+0x120
> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
> #12 0xffff000000506404 at root_bus_configure+0x40
> #13 0xffff000000439cf8 at mi_startup+0x11c
> #14 0xffff0000000008b4 at virtdone+0x78
>=20
> In:
>=20
> =
https://lists.freebsd.org/archives/freebsd-arm/2022-December/002115.html
>=20
> I reported what I'm experimenting with (2nd version) for 13.1 and
> main for allowing modern RPi* firmware. It basically leads to
> bcm_dma being set up earlier so it is available for reference in
> the bcm_sdhci_attach activity.
>=20
> If you build your own kernel with the type of patching that
> I report, the specific crash should disappear and booting
> with modern RPi* firmware seems to have worked for me so
> far on the machines I've done the experimenting on.
>=20
> Expect more messages caused by new things in the .dtb files
> that the kernel does not support but keeps rechecking during
> boot. Sort of a noisy form of otherwise-ignored.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com



From nobody Fri Jan  6 05:42: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 4NpC143g8Hz2qv18
	for ; Fri,  6 Jan 2023 05:43:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4NpC1415mRz3Fbx
	for ; Fri,  6 Jan 2023 05:43:04 +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=1672983782; bh=rUS6DmyHBMhxJaN0U/DPfspNT9C3T5fevM2p1rofmH4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nVuz0yR/Xp4wFpqCW5IPBMc5CbPOgxiDBHvmiz2Izu+UggU9vHemSzGq+MNv1J3yWa5mgJhwY74imd57R6IVZVh5UJX7Pds889wxFSVQtqYNdTjV8s1cks3VYJC2e9isAAbr9SVuW8rbMItgjgbN/XXNcqZ53mfgaOKFLciHWwplcP3UM0giRK4umJrVKjsNh4eeXHE4I5ezd1dq0VplH8YrytA5j5DCc24u9Oni7lCSGcupj5JY2Sm5wz4PxsUi3uAgAf002TxLOV9enjIKY5DztPib9QpfaQXRIGJG6Au7pVbAz6pad6LELWHMCNk3Mrgbke8krNInmgduIJUsjA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672983782; bh=wK59ETemTPZx8zq4H5qiu4fkpFHPqYTo/I2ElkJZMMX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oBu46QFFw+38B8qYfVfMuCTELQvvdrwhnLf3GAc6drKMV6bluFI14i7PnCXtykll5lZtEKSS24iMC90alECnd0qxq2oUUMII0dEFMynDpXEzRjE6c5EJDwSf0T11O6SJr/wU7cZdEAtA6wDPTXf36USy50Spmn3QFa8BmgnzbvQ3v7+2IBBpfahJIWynM353VQn12oyMp0d6fSAE/UTwrc6B8MTPVRfypgG2Fi6asBHC1+JBCxHqSEP0cOj7HyB2+Tnp4VITijT8Fe6AiRMUvqOkd0q/PFh/9NV7YXaiq2D9DQ6mATT8Yyfs1yjwgtWjrcWBVEeBFAgVipEniaRt8g==
X-YMail-OSG: Dxrxs2AVM1lfdaUAitEH4IW12m_LGyUGY.yHr4TU5BIDCncopXDR6YifNEXw0_a
 W8T0T7kfV.su_JQCYT4BgSPDE7nHpOfD.1oZ0HxfWu.xxXPU3M8DkZmZrPBo8kyVXP_DmCxQ6vUA
 _9n79AgCBY1i5n_qa3yY.3j3X0imkbG4T83zHH1oOF5cRhLyiLg0yZUPH.hifshRYliuDYAJc5nO
 pc7Ky0t49dQhMknIrDRFatipaIXYbVeNMCCifC.FI2ZjiY5og6q__HaGYTQY_x4pAu8pdHMKsYY0
 UDKIoXp9RpQS50fFuhxBplGfmHhD1vgJ5eNUDrGJzc1OCUuZMiRR0DbsiVMXM7d9bjYP21ZfExJb
 N9cbKDGew6TTBJaXeWjJ5V0I_qPldhkV_OkbahscNCfsHuAf9wqN.b6SwoRm5QMtsQDMykYsMv4a
 qDLo_MOH9homrDDelMCN13CvN.fjW8vQH8YNvoYXmc81bJRs0KCL4tlJhJHIzNmatXpNBOjTk3qM
 vauT1g1CC20tciI8ydzMoBmiD9bj4yZdNecVE6IIdxZnkx7DVrz._rDeyiBrpuvrCUICfEnot1Ud
 5GZxY55KZrev6pIiyR_h.dwlYM4Oyf.gT32cSc7Epvy6b_AIUWgNiV4mDyE7ybqu2LNSu3PqHzYP
 sEDGjVc_XcF68cppqvxUb4S48iAvgF.ZTibhWSuIxsuqsEJcK_xRWr73BEDL1.kigvuOiZe1iUjR
 IgoHlth6t0zOhHfYooHMXkPAWf5wLxqpe_2WAIwez0rwlQG79mbKzXQ2r67E8cg79meqGDiDo3ov
 _Q_WvyWpEaDT342UJPo9iLA87F5z9aeZyG.xKkKDQQtyoYMBF0kW2zFDQP4XJ.jPs6.G9WHA8.rH
 Favr7MjwBtpMNGqtC2LfBy1Oqf8OYLHR1_UKWQRRP68plIELbSO4phTAOYrmAw4vo9IgsgColMAy
 HTl0CKBMAfoYX_hw9rJzgLQYcIA77_a5u_2r1SxARgU_tBsZObqGYEs1w6IE_pG061OldcHTFrEO
 TonXnv.JVBCxQPQJWpu9oAMvKb4HpePOBblsaGjb6zLEdEEJkJj7MOtrsygxNC9iPfbvBNXtcBbx
 jcalh_K8LgWGI0Llcaqqf24nP8U4JzAh_b.yMVy5oukZQyc_fM5VlFliOepVtt_FgWjssNpQX6fr
 iIBr9GlkQP6_ZbTtieQGRQrwj8gRB0asTt02SkFXk.AbTu4qokn8f2ff.Oa.kxNc2p9.yyWsfyhL
 OW.1i1zCV1yqir.fKAmmQtjd17Vf9oQh6ArBGRpErP6E3_yAsLdQA48aEJ6NPIED1S.hF18RStti
 YFIVqvkfCeWyCm59fxECzN13TFH01pomNdI9YE464y5tIoD2QL.XZpWu520WZglaedemWp1hhfbZ
 XJ0fRl3xtew4D2zDsGarNR6MR42o6JBuvxFugSenK6yKCVUbDz8S_DRDHylJG9gMEsp2HaljqqrF
 wudodGAZbLlUkfzwn79XIO1dJeZp9hxQauA_4w4rGHiKpBtYH2f4v8sn1HHdplUz37VgYDIyOfCw
 P6rmx7WALeHOPYWrQnyscHyfxv7YdLQ1rzThtODCf7Z9Grgoo_h7uTCUiVyYgWNts9ZLTr40V4t7
 RYXCrX5aNYuk8l.MKyNSgVKT80MNW_xlT92By7jiN3I.vCPoY5Ec.STpTcnqE73vge85e09bWr1l
 dCC33DuaxxIIKqHeR5NwULNpiHymLiGT02fncwfNVPKjgd_SMAM.5wBK2cb6rKUK9p1wbT1UIDYD
 poziS2eDYg5M7mKaCguUIXnGUrBNgNvv5UbRtDMGfxBCRN6VTIk6OmpDk.3zmsLG0MDqP8FQrh5k
 vVuJUSJFMgOIgYD8i8BDVmnct3agjp6FRO887kaQyNt6XXsYifC0kOL_Q9a4manhjKohpm3WV81U
 4utsaUzLpXQeqN6_1rL9Thq2SN1fedgfDS2acAXNhTxxnetxc7VrfMyR6KuTQFt7gXGVDTKQcTPr
 P_G2T.vE4jaMZN1xh9v64c0bx1I27RvZ.u295cQyclfFjAaCqId.nStGIAqQd7.U8iq9ea8TKf_5
 x63oikAg2smWDd6VjntFffPCBx8tOebkZqQeoAJ1xiAFc2qNVzA_8LCzZYmZXHjzZ.2KEp0QG84Z
 N2L6sSHG462QUEKNzDcGYI.HOMTNigk75ijts6NR8ETZIAZKOSzh_3ZFHKrffJD.94lBzNWJhldi
 qIIRLKxbD0bPbxSr1ofzrmJLxz1gG5HN6fB34lywefFox1_g9dPlV1fb2mIDlUHiwFICCY26m
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 6 Jan 2023 05:43:02 +0000
Received: by hermes--production-bf1-5458f64d4-bl5tb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bb262324b3b5300c821ce6bd72a4ccbb;
          Fri, 06 Jan 2023 05:43:01 +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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed [Klus's crash]
From: Mark Millard 
In-Reply-To: <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.com>
Date: Thu, 5 Jan 2023 21:42:48 -0800
Cc: "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <894C0DAA-A199-434A-A5D7-C4BB1FBC5BEC@yahoo.com>
 <650C4A06-1205-489A-B69A-0BB657F1C0E5@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NpC1415mRz3Fbx
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 5, 2023, at 20:41, Klaus K=C3=BCchemann =
 wrote:

> Mark, thanks for the detailed hints !
>=20
> I will investigate in that firmware issues/your suggested patch,=20
> and will report back later.
>=20
> Regards
>=20
> K.

FYI: the crashing without the patch is tied to variations
in the ordering of the material in the .dtb files. If bcm_dma
is not set up in an earlier pass in the kernel, the modern
ordering in some .dtb files ends up with a "used before
defined" sequencing. Thus the move of bcm_dma to an earlier
pass via the patching --so that bcm_dma is then always ready
in time for its 1st use.


>> Am 05.01.2023 um 21:43 schrieb Mark Millard :
>>=20
>> On Jan 5, 2023, at 11:32, Klaus K=C3=BCchemann =
 wrote:
>>=20
>>> Hi Bj=C3=B6rn,
>>> ( ..I had a JTAG setup on the PI, but didn=E2=80=99t use it for some =
time..)
>>>=20
>>> yes that was a  "live=E2=80=9C boot example from today of the cm4(on =
orig. I/O-board),
>>> it hangs while initializing sdhci, while the boot partition is =
living on the emmc :
>>> =E2=80=94
>>>=20
>>> sdhci_bcm0:  mem =
0x7e300000-0x7e3000ff irq 24 on simplebus0
>>> Fatal data abort:
>>> x0:         ffffffff
>>> x1: ffff00000092b404
>>> x2:                0
>>> x3:                6
>>> x4: ffff000000fdf77c
>>> x5: ffff000000fdf72c
>>> x6:          4000000
>>> x7:          4000000
>>> x8: ffff000000dfb6a0
>>> x9:               20
>>> x10:                0
>>> x11:                1
>>> x12:  300000000006e65
>>> x13:   fefefefeff0100
>>> x14:               1d
>>> x15:                0
>>> x16:                0
>>> x17:                0
>>> x18: ffff000000fdf7e0
>>> x19:         ffffffff
>>> x20:                0
>>> x21: ffff000000bad000
>>> x22: ffff000000bad000
>>> x23: ffffa00000f8f038
>>> x24: ffff00000091b5b2
>>> x25: ffff0000008dfc9c
>>> x26: ffff0000009436b6
>>> x27: ffffa00000f8b140
>>> x28:         32000000
>>> x29: ffff000000fdf7e0
>>> sp: ffff000000fdf7e0
>>> lr: ffff000000868040
>>> elr: ffff0000008620d4
>>> spsr:         a00000c5
>>> far:               20
>>> esr:         96000004
>>> panic: vm_fault failed: ffff0000008620d4
>>> cpuid =3D 0
>>> time =3D 1
>>> KDB: stack backtrace:
>>> #0 0xffff000000516458 at kdb_backtrace+0x60
>>> #1 0xffff0000004c24ac at vpanic+0x174
>>> #2 0xffff0000004c2334 at panic+0x44
>>> #3 0xffff0000007f48c0 at data_abort+0x204
>>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>>> #5 0xffff00000086803c at bcm_sdhci_attach+0x314
>>> #6 0xffff00000086803c at bcm_sdhci_attach+0x314
>>> #7 0xffff000000502428 at device_attach+0x3fc
>>> #8 0xffff000000504514 at bus_generic_new_pass+0x120
>>> #9 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>>> #10 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>>> #11 0xffff0000005044a4 at bus_generic_new_pass+0xb0
>>> #12 0xffff0000005065f4 at root_bus_configure+0x40
>>> #13 0xffff000000439ee8 at mi_startup+0x11c
>>> #14 0xffff0000000008b4 at virtdone+0x78
>>> Uptime: 1s
>>>=20
>>=20
>> You are using modern enough RPI* firmware that the FreeBSD
>> kernel does not tolerate it. Same sort of backtrace as I
>> reported back in 2022-Apr when I explored what RPi*
>> firmware releases avoided kernel crashes on RPi4B's,
>> such as:
>>=20
>> KDB: stack backtrace:
>> #0 0xffff000000516268 at kdb_backtrace+0x60
>> #1 0xffff0000004c22bc at vpanic+0x174
>> #2 0xffff0000004c2144 at panic+0x44
>> #3 0xffff0000007f4928 at data_abort+0x204
>> #4 0xffff0000007d5010 at handle_el1h_sync+0x10
>> #5 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #6 0xffff00000086809c at bcm_sdhci_attach+0x314
>> #7 0xffff000000502238 at device_attach+0x3fc
>> #8 0xffff000000504324 at bus_generic_new_pass+0x120
>> #9 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #10 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #11 0xffff0000005042b4 at bus_generic_new_pass+0xb0
>> #12 0xffff000000506404 at root_bus_configure+0x40
>> #13 0xffff000000439cf8 at mi_startup+0x11c
>> #14 0xffff0000000008b4 at virtdone+0x78
>>=20
>> In:
>>=20
>> =
https://lists.freebsd.org/archives/freebsd-arm/2022-December/002115.html
>>=20
>> I reported what I'm experimenting with (2nd version) for 13.1 and
>> main for allowing modern RPi* firmware. It basically leads to
>> bcm_dma being set up earlier so it is available for reference in
>> the bcm_sdhci_attach activity.
>>=20
>> If you build your own kernel with the type of patching that
>> I report, the specific crash should disappear and booting
>> with modern RPi* firmware seems to have worked for me so
>> far on the machines I've done the experimenting on.
>>=20
>> Expect more messages caused by new things in the .dtb files
>> that the kernel does not support but keeps rechecking during
>> boot. Sort of a noisy form of otherwise-ignored.
>>=20

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Fri Jan  6 19:42:22 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 4NpYdm74mvz2pJ3f
	for ; Fri,  6 Jan 2023 19:42:36 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632])
	(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 4NpYdm4R2zz3kr9
	for ; Fri,  6 Jan 2023 19:42:36 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x632.google.com with SMTP id ud5so5781507ejc.4
        for ; Fri, 06 Jan 2023 11:42:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=711+V4+aHlm2mogv2h5vEfNlUvVQV/Qdt8Ll9KLJHQM=;
        b=IJ7HSOHLiTONuic15KSQMS05cK3zD2mwfAHbCbg8n4BgfUmX7q0DFmjzootH5WDmfL
         nWYgXGb35JohaJF1PY16e1cXDEU0KARuQIH5EeKconTZxvgVkKXf2+CuDVRkbs8FRXCb
         DaXYL7NcD0W889g58JV/tk+WLf2m9PKeG+NNHD2WmcTqmZyuzUf+uF64PzBUVzuMxJIA
         qpaYou1fjUUATl79ix8xXPS7SHXGEPW8qE7N+O5J7HvSsNbw2YZ1ptUWTAB2k0XyUFvL
         qEwnaD6rYOz3Y1TYw4YnStryi0i40VQoqZO8uC+6zw8MqmGl7rBC3b7te51jR36lg81j
         GwvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=711+V4+aHlm2mogv2h5vEfNlUvVQV/Qdt8Ll9KLJHQM=;
        b=OcTIzkPYLMrtVXY0pZ5IWL0sWOfYrWknYjx9a1ePnGj6J2HUV2P92ZC+xML+DGC05J
         X1xAn5Q0TIye6FPt2rPkoxpO2i19gGfcNP+uNOQG/iLiP411KyO3Z2mh4L+8nSaPCZrD
         j/zfnV9OqrL0IdHS9hQ/tLV/XTxYX8ZqW+NR7nm5ij06EjyOFVkG72LrN6KoxAZB48u0
         apHHrVWw5yfwFnvyVU0ZShcPpjgKfShkM3dzSp5702oOSXKUvqmB8U025UW+F2AUCWWE
         aFJAbS8jxhA+U7FduuMJYTqC2JfCeYS0fkyxswQhnPaplLuThijaidT/l/Q0SWO818rV
         Ptrg==
X-Gm-Message-State: AFqh2krsWXvU+rkp/B2+ZEFY0uOPxz3MjLinykhJV9Pc+Vna2ZdujFQZ
	X5VsX7h4NqAP7Vh3iCFmjDSFmT768Po=
X-Google-Smtp-Source: AMrXdXt5yMvLrqPzQBMo8CdZqfs0xFivXV+9iDlM0umahtuZHzMxxy3h661XydYIfUR5v8AG8NIcwA==
X-Received: by 2002:a17:906:3ad7:b0:7c1:6e53:dd02 with SMTP id z23-20020a1709063ad700b007c16e53dd02mr54368120ejd.64.1673034155332;
        Fri, 06 Jan 2023 11:42:35 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-028-121.46.114.pool.telefonica.de. [46.114.28.121])
        by smtp.googlemail.com with ESMTPSA id g11-20020a170906538b00b007c16e083b01sm682178ejo.9.2023.01.06.11.42.34
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 06 Jan 2023 11:42:34 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Fri, 6 Jan 2023 20:42:22 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
To: "Bjoern A. Zeeb" ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
Message-Id: <89448094-E164-41BE-BD90-96EA6F766311@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NpYdm4R2zz3kr9
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Hi Bj=C3=B6rn,

just to not mix up all the chaotic RPI issues in this thread ,=20
I only answer the requested issue here :   ( RPi) db> reboot -> =
cpu_reset failed)

first of all I can confirm the boot crash with an untouched 14-current =
download,
yes it ends up at the db>  prompt ( for me on the cm4 while  <> )

And this is how I was able to reboot from the db>  prompt  instead of =
typing =E2=80=9Areboot' or =E2=80=9Areset'  :


db> continue

machine then reboots as expected .

Regards

K.


> Am 05.01.2023 um 21:23 schrieb Bjoern A. Zeeb =
:
>=20
> On Thu, 5 Jan 2023, Klaus K=C3=BCchemann wrote:=E2=80=A6=E2=80=A6
> .
>=20
> Ok, I am just wondering given reboot works fine why reset in db>
> wouldn't.  Given you have JTAG setup you can probably debug a lot =
better
> than me but also you seem to have a different problem ...  too many
> problems too short time *sigh*
>> =E2=80=A6=E2=80=A6...
>=20
> --=20
> Bjoern A. Zeeb                                                     =
r15:7



From nobody Sat Jan  7 05:19:43 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 4NppS11sbnz2qnh8
	for ; Sat,  7 Jan 2023 05:20:01 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329])
	(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 4NppS00wkcz3Lhs
	for ; Sat,  7 Jan 2023 05:20:00 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=UWwiSm9W;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::329 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com;
	dmarc=pass (policy=quarantine) header.from=googlemail.com
Received: by mail-wm1-x329.google.com with SMTP id m26-20020a05600c3b1a00b003d9811fcaafso2428919wms.5
        for ; Fri, 06 Jan 2023 21:20:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=SI6gIOcPX1K2wCn2sY5yDbrZkOQwCrNOlc0vg2NyXAc=;
        b=UWwiSm9W7e2mdZ1dLsSWuZbosSPixHG0PVIG3/TK2F0++k5X2ILsVysxihh2Jz3hgz
         JwGyE8NpoHQ2EL9Pm06Xbzxt0jxMbXD1dCQJOrM6ZWBC3y/OCVYZS5jQKi62tjgD3ebM
         +3ts2IBKrQKrtrlM3ZYRbIdSW49pCaarR74vnSfJ7HMVpz2r1UH8z2abbw4eQ4muuFp5
         TTLlFMMTvp2HwZ6qgRtArpI0Yz1PUfqSxPzBM/LgkT/ruzuYziExw4DumT8BtdbVPaYr
         IMYepa7Zo8wdOvHD97Q3TQPfMmuoVd9imjPO/+75Qaqo+3MpQ3hWMprOY6z2aCdd+ZQW
         oqfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=SI6gIOcPX1K2wCn2sY5yDbrZkOQwCrNOlc0vg2NyXAc=;
        b=pBnDUROiCqYWy1s6eJyYa50DMi3fwCO20kBIJatVciCvAfDoxv5Z/mYmAC9/Q22lHV
         7Nwe2VCyQNflWXOn9lEGP0t9Gjh+6YqvN2SkQwRNkcHTaBze7SXAtg/tjYz/Xcc1uQPo
         GE2J/vJoMb0Eqy5Fm0D36E/1re8ghLuzo73RXPxOO//hnrmcThdT0IkwpNg7pVR9RI5O
         Sfucuzmn5isZdKmbqEXrez7zgJhyd2qKnqXaB9yqt4unEMPLATYJIP0/U+1UoAfvn4/I
         VVob84joaT+LKr5xVeP9Lsf9sSWelqmxM5EtnbOGgZ5JlNYVmekneULw/I85MJq6C/iZ
         QOIQ==
X-Gm-Message-State: AFqh2kqQgiPV80or5d05XxjpUvnEvdyvWdSA0TknCdWty9YKh9Mr+oko
	P4vnUoiD1uv/zdnKanTGGKe0FGOto0s=
X-Google-Smtp-Source: AMrXdXsKneDT+I3d/ii9WAHTSPhvn0i10W3HmExA4Vru7idE+8hyajXFjlrEkUX814RqcOvRxv7fkQ==
X-Received: by 2002:a05:600c:358a:b0:3cf:8d51:1622 with SMTP id p10-20020a05600c358a00b003cf8d511622mr41563987wmq.1.1673068798792;
        Fri, 06 Jan 2023 21:19:58 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-028-121.46.114.pool.telefonica.de. [46.114.28.121])
        by smtp.googlemail.com with ESMTPSA id q1-20020a1ce901000000b003b3307fb98fsm3762767wmc.24.2023.01.06.21.19.57
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 06 Jan 2023 21:19:58 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Sat, 7 Jan 2023 06:19:43 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 <89448094-E164-41BE-BD90-96EA6F766311@googlemail.com>
 <20230106202742.GA24285@www.zefox.net>
To: bob prohaska ,
 "Bjoern A. Zeeb" ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <20230106202742.GA24285@www.zefox.net>
Message-Id: <335E77B6-0B47-41D7-89C7-C75838C9FFD7@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-2.87 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_MIXED_CHARSET(0.63)[subject];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::329:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[www.zefox.net,lists.zabbadoz.net,yahoo.com,freebsd.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NppS00wkcz3Lhs
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N



> Am 06.01.2023 um 21:27 schrieb bob prohaska :
>=20
> On Fri, Jan 06, 2023 at 08:42:22PM +0100, Klaus K??chemann wrote:
>>=20
>> db> continue
>>=20
>> machine then reboots as expected .
>>=20
>=20
> Useful discovery. It never crossed my mind to try it 8-(
>=20
> Thanks for writing!
>=20
> bob prohaska
>=20

..while I fear that Bj=C3=B6rn could reach the  =E2=80=9E Uptime: 1s =E2=80=
=9E  (CPU halt)
even with this command,=20
depends on the issue itself..


Regards

K.


From nobody Sat Jan  7 05:50: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 4Npq6w6hk5z2qs7P
	for ; Sat,  7 Jan 2023 05:50:16 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c])
	(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 4Npq6v4w1vz3NPW
	for ; Sat,  7 Jan 2023 05:50:15 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=VdPtga7E;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=maciphone2@googlemail.com;
	dmarc=pass (policy=quarantine) header.from=googlemail.com
Received: by mail-wm1-x32c.google.com with SMTP id m26-20020a05600c3b1a00b003d9811fcaafso2450108wms.5
        for ; Fri, 06 Jan 2023 21:50:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zlHsOb9vlqh5T8scIHgJ5vpv0LZQaG9Cc+Klh1XmJ+E=;
        b=VdPtga7EiOTB3fxqjjvRoVaVyel93bAvOJbtDehK2vp6FgwxxOojCcL+n6jsPHWc+P
         /WBXL7bp/9YCOI8SdoG5jgISIQVxkE5FZgtFRrfWT94sLOyh7wBj5IF0/E28sr47Bcn7
         jd0u1pSVvmMeS2Qi4Vu4kzYjUsHrxpAKITuGGxU9RFWQgCCJBtVaM0euuyJlRqwv3L2Q
         uoFlnZhP0RXKjiKYwAoiKSMMWV24EwRKAQI3p95udlovcaIbLyKm0VfnEXc/eA5cZOFy
         NeUajU35wWV0LwhJEkrLRJgvLq8Aodf9dEaLT7G1p1HOFLQRds+K1h2yDDjUwCDbn4nn
         GnMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=zlHsOb9vlqh5T8scIHgJ5vpv0LZQaG9Cc+Klh1XmJ+E=;
        b=K0JBY+cnn1nXbC0gFsgJpVvwla6H1NsPgop8Q4zniWETp+mO79YKgoszW3KEsLSDwg
         vG9VvcwqxVehk+R/YClJfpo4KN4+FrrAiwiNNdbsnJmivZiew+hITqxJmKXhe5ys+23J
         9I77rzclNRtfJiuPWk3q3DDMq2Wi4SGSSstGRtBDIfYxGCXl/SAH0agoWG6KcgNKwvmI
         rUMDrsjfxiylAr415uWvZoK2rsPy4tKchLx6zWCJbf5V1frfClj/TIxZrcbN2exNoaxB
         mLVlEbKc23zinNXaBsCNe88pxIEmqcbbjIcmZ+NsAh7zodV8IEQ+VqswvJ32Ch70rzs3
         vc8Q==
X-Gm-Message-State: AFqh2kpc0geHvtMOOoaR2TvXWAj5yzARN8jaxC03vvQCWkdL3FDFpoeP
	FWfx4+95DFQ3U95UZXnT0qg=
X-Google-Smtp-Source: AMrXdXutLqw00WLmfmGiXCt5s2wlXKcPLQ4+T2VWoC79C7LEdn6hGT0fMdfBu0+QwhP7+MfOQ7l9QQ==
X-Received: by 2002:a05:600c:34c2:b0:3cf:7397:c768 with SMTP id d2-20020a05600c34c200b003cf7397c768mr40717362wmq.30.1673070614173;
        Fri, 06 Jan 2023 21:50:14 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-028-121.46.114.pool.telefonica.de. [46.114.28.121])
        by smtp.googlemail.com with ESMTPSA id m17-20020a05600c3b1100b003cfbbd54178sm16192134wms.2.2023.01.06.21.50.13
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 06 Jan 2023 21:50:13 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: panic: vm_fault failed: %lx error 1 (from arm64::data_abort)
Date: Sat, 7 Jan 2023 06:50:01 +0100
References: 
 
 <90oq9666-s818-ons1-1333-629opssq237n@mnoonqbm.arg>
To: "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org,
 Mark Millard 
In-Reply-To: <90oq9666-s818-ons1-1333-629opssq237n@mnoonqbm.arg>
Message-Id: <290A85D0-1497-428B-99C7-7E4714D66989@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[lists.zabbadoz.net,freebsd.org,yahoo.com];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Npq6v4w1vz3NPW
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

well, just to confirm Mark=E2=80=99s estimation that it=E2=80=99s =
possibly not a kernel issue :

apart from all that hills to climb to get it to boot(without any kernel =
patch or kernel revert):
 I got it on  both RPi4B( =E2=80=9EB0T=E2=80=9C-device) &  =
CM4(=E2=80=9EC0T=E2=80=9C-device, afaik) with the latest 14current from =
tonight..
while on the CM4 it was a requirement to unload modules at boot (or for =
persistence disabling devmatch),
so for Bj=C3=B6rn I would suggest to unload (all) modules out of the =
loader  (as an idea for the first try) ...
<<<<
U-Boot 2022.10 (Jan 01 2023 - 06:34:49 +0000)

DRAM:  7.9 GiB
RPI Compute Module 4 (0xd03140)
=E2=80=A6.=E2=80=94(netboot) : ------
root@:~ # uname -a
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #23 =
main-n259963-da303f5fd4ee: Sat Jan  7 01:16:32 CET 2023     =
root@fbsdr5pro:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64
---

<<<<
U-Boot 2022.10 (Jan 01 2023 - 06:34:49 +0000)

DRAM:  7.9 GiB
RPI 4 Model B (0xd03114)root
=E2=80=A6.=E2=80=94(netboot) : ------
root@:~ # uname -a
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #23 =
main-n259963-da303f5fd4ee: Sat Jan  7 01:16:32 CET 2023     =
root@fbsdr5pro:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64
---

Regards

K.

> Am 05.01.2023 um 23:57 schrieb Bjoern A. Zeeb =
:
>=20
> On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:
>=20
>> On Thu, 5 Jan 2023, Bjoern A. Zeeb wrote:
>>=20
>> Hi,
>>=20
>>> on an unattended console after updating the machine (previious =
builds were Dec 23) did not come back up.
>>> I have a few last lines.
>>> esr:   96000004
>>> panic: vm_fault failed:  error 1
>>> cpuid =3D 0
>>> time =3D 1
>>> KDB: stack backtrace:
>>> ..
>>> data_abort()
>>> ..
>>> --- exception, esr 0x96000004
>>> thread_init()
>>> keg_alloc_slap()
>>> zone_import()
>>> cache_alloc()
>>> cace_alloc_retry()
>>> thread_alloc()
>>> fork()
>>> kproc_create()
>>> audit_worker_init()
>>> mi_startup()
>>> virtdone()
>>=20
>> Follow-up, got a serial console hooked up and a kernel as of an hour =
ago
>> or so:
>=20
> And as another data point:  6fd6a0e342fbfb8513ae56105cf0f85f55c6276e
> (Dec 23) does boot still just fine; did a rebuild with all the same
> local changes, same kernel modules loaded, ... same loader installed
> (not changed with the dowgrade), same firmware, ...
>=20
> I'll try to bisect the next days unless someone can spot any other
> commit I may have missed which could cause this.
>=20
> /bz
>=20
>=20
>> ...
>> hostuuid: using 00000000-0000-0000-0000-000000000000
>> ULE: setup cpu 0
>> ULE: setup cpu 1
>> ULE: setup cpu 2
>> ULE: setup cpu 3
>> Fatal data abort:
>> x0: ffffa000008c1d80
>> x1:                0
>> x2:                2
>> x3:                3
>> x4:              203
>> x5:                0
>> x6: ffffffffffffffff
>> x7:             2001
>> x8: ffff000000ee5000 (dump_encrypted_write.buf + f54)
>> x9:                0
>> x10: ffffa00000845be0
>> x11:                2
>> x12: ffff00004041dd98 (fuse_mtx + 3c276888)
>> x13:   20000000000040
>> x14:           42c000
>> x15:                1
>> x16:                c
>> x17:            4082a
>> x18: ffff000000fcf6a0 (initstack + 36a0)
>> x19: ffff00004082b000 (fuse_mtx + 3c683af0)
>> x20:                0
>> x21: ffff00004082b000 (fuse_mtx + 3c683af0)
>> x22:                2
>> x23:                0
>> x24: ffff00004082d000 (fuse_mtx + 3c685af0)
>> x25:                0
>> x26: ffff000000c73000 (sdta_vfs_vop_vop_spare4_return1 + 18)
>> x27:                2
>> x28:                1
>> x29: ffff000000fcf6a0 (initstack + 36a0)
>> sp: ffff000000fcf6a0
>> lr: ffff0000004cdff8 (thread_init + 98)
>> elr: ffff0000004ce004 (thread_init + a4)
>> spsr:         600000c5
>> far:               40
>> esr:         96000004
>> panic: vm_fault failed: ffff0000004ce004 error 1
>> cpuid =3D 0
>> time =3D 1
>> 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+0x308
>> handle_el1h_sync() at handle_el1h_sync+0x10
>> --- exception, esr 0x96000004
>> thread_init() at thread_init+0xa4
>> keg_alloc_slab() at keg_alloc_slab+0x24c
>> zone_import() at zone_import+0xe0
>> cache_alloc() at cache_alloc+0x32c
>> cache_alloc_retry() at cache_alloc_retry+0x2c
>> thread_alloc() at thread_alloc+0x38
>> fork1() at fork1+0x348
>> kproc_create() at kproc_create+0x78
>> audit_worker_init() at audit_worker_init+0x44
>> mi_startup() at mi_startup+0x200
>> virtdone() at virtdone+0x6c
>> KDB: enter: panic
>> [ thread pid 0 tid 100000 ]
>> Stopped at      kdb_enter+0x44: undefined       f900027f
>> db> show reg
>> spsr        0xf2000000600000c5
>> x0                        0x12
>> x1                         0xa
>> x2                           0
>> x3                         0xa
>> x4          0xffff0000007f5c10  generic_bs_w_4
>> x5                        0x50
>> x6          0xffff00000051244c  kvprintf+0x470
>> x7                        0xd5
>> x8                         0x1
>> x9          0x49a2d892bc05a0b1
>> x10         0xffff000000ebd000  null_gdb_dbgport+0x20
>> x11         0xfefefefefefefeff
>> x12         0xffff000000000a63  create_pagetables+0x3b
>> x13             0xfefefeff0100
>> x14                          0
>> x15                          0
>> x16                          0
>> x17                          0
>> x18         0xffff000000fcf310  initstack+0x3310
>> x19         0xffff000000f16000  kdb_why
>> x20         0xffff000000ee3f70  vpanic.buf
>> x21         0xffff000000ec0cc0  thread0_st
>> x22                          0
>> x23         0xffff000000ee4000  vpanic.buf+0x90
>> x24                        0x1
>> x25         0xffff000000fcfaa0  initstack+0x3aa0
>> x26         0xffff000000c73000  sdta_vfs_vop_vop_spare4_return1+0x18
>> x27                        0x2
>> x28                        0x1
>> x29         0xffff000000fcf310  initstack+0x3310
>> lr          0xffff00000050b0c4  kdb_enter+0x40
>> elr         0xffff00000050b0c8  kdb_enter+0x44
>> sp          0xffff000000fcf310  initstack+0x3310
>> kdb_enter+0x44: undefined       f900027f
>>=20
>>=20
>>=20
>=20
> --=20
> Bjoern A. Zeeb                                                     =
r15:7




> Am 06.01.2023 um 04:58 schrieb Mark Millard :
>=20
> As a contrast, I've dd'd to microsd card media and booted:
>=20
> =
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230101-231d75568f16-259905.img.xz=
 =

>=20
> 231d75568f16 is from:
>=20
>   =E2=80=A2 Sat, 31 Dec 2022
>      . . .
>       =E2=80=A2 git: 231d75568f16 - main - Move INVLPG to =
pmap_quick_enter_page() from pmap_quick_remove_page(). Konstantin =
Belousov
>=20
> So: the last listed for 2022-Dec-31.
>=20
> I've booted on a couple of RPi4B's ("C0T" and "B0T" 8 GiByte
> ones as I remember). No boot crashes or such. You might want
> to test if such crashes in your context. If it does not, then
> something more specific to your environment is involved.
>=20
> I sometimes do rough/partial kernel "bisect" via materials from:
>=20
> https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD
>=20
> without having to build. For one, if I get a replication then my
> personal builds are not the source of whatever problem I'm
> looking into at the time. Otherwise . . .
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20
>=20

From nobody Sat Jan  7 08:37: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 4Nptrk0ZYPz2sFNJ
	for ; Sat,  7 Jan 2023 08:38:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d])
	(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 4Nptrh5HPxz3qvn
	for ; Sat,  7 Jan 2023 08:38:12 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="F3ACMhP/";
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=maciphone2@googlemail.com;
	dmarc=pass (policy=quarantine) header.from=googlemail.com
Received: by mail-wm1-x32d.google.com with SMTP id k22-20020a05600c1c9600b003d1ee3a6289so2599998wms.2
        for ; Sat, 07 Jan 2023 00:38:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=6HG9DngKCIgIgjwi8jK7M/RGXmkTjsc4OKkfNZ9D88Q=;
        b=F3ACMhP/EiUEEVGtIIculguUjE0wgQb62eVKWTcCH8nhBM6TJPnghp6LOE2z6Yl/Nx
         WIfXxJ3A7uSF5+tTWzOly2FX+NFD2zruhI2GS+SxldPGohRKsljP6L4VwPnGpRbpqSe3
         4NsZpbtoxBAHGOU992qwoXjpv0wniTytSmSDOgdGKn9A4sABYx39bdpzdhEfhJFjhQNV
         h90nJyBIY/CgcG22a0qZIRXwQfIqw2onRTSmGKqa0s9wC28AdQJ9MFPhpJLcYHdIIqJb
         I2HMPLwQKRHH7tnyFXADnvpMzzv4IB63yqFxI8KGcBl1/mKMXDnG0Krf4ajFlknAxpvU
         jaXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6HG9DngKCIgIgjwi8jK7M/RGXmkTjsc4OKkfNZ9D88Q=;
        b=Sgu+wCR9Sv3ajcgTWrs3WIS7XgV0E0/+jvoJJV3uPQKJO85W8lLqTpHqaq1SjSKfSv
         h3hFYZLetB51pQbiI1zVM0fNYrytc5ak5zW8k/AoawvFSyfi30RfdceCjQhG2zByr3WJ
         J226i37nhuu9YvttRK32Fi5QNKUNSVc//hoAs9RBpIdTN76Kx3CHqsQES7mWXpvNbRSM
         HRugH4Vj7h2lOgROAkVaukQNGAJrwmHG7Fd+fS7bdfZHR53aSh+ET5WYw3y7NLhAAgZc
         kS4AsgVUffS5uHWLCXzweZBGDicq+ZaXirjDEPpEIsk+Gt4p1enuqnxPt+iaMatuok6d
         KUIQ==
X-Gm-Message-State: AFqh2kokJB8LODcu5Zg24N/ZVGAf2c+WHdZ57lq7V4sQf/oi/m1zkw0a
	zbrRK2HxeD8NchlsR2iKaxhAeFSUsUk=
X-Google-Smtp-Source: AMrXdXt7gm6Vm0gCF7DKDvbYGzr57nr44f3FgWm5Xlm2bTFbOEtM4mPhsHKEqf/tMZ7UvZQwo5dUsA==
X-Received: by 2002:a05:600c:4e09:b0:3d4:5741:af9b with SMTP id b9-20020a05600c4e0900b003d45741af9bmr45159846wmq.0.1673080689904;
        Sat, 07 Jan 2023 00:38:09 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-028-121.46.114.pool.telefonica.de. [46.114.28.121])
        by smtp.googlemail.com with ESMTPSA id j30-20020a05600c1c1e00b003cfa80443a0sm4994531wms.35.2023.01.07.00.38.08
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 07 Jan 2023 00:38:09 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sat, 7 Jan 2023 09:37:55 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Nptrh5HPxz3qvn
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi Mark,

`ve tested your "early_dma=E2=80=9C patch now on the CM4(not tested on =
the 4b)=E2=80=A6
true, it can boot the latest firmware but after investigating in =
what=E2=80=99s new=20
in bcm2711-rpi-cm4.dtb I guess new features are mainly  related to CPU =
(L2-) caches features ,
That=E2=80=99s why we get things like : "clk_fixed4:  =
disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.=E2=80=9C ...
so I think we currently won=E2=80=99t benefit much of the new firmware.

I had a little hope that an earlier dma could shine a bit more light on =
bugs like this :=20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260131

But a tiny little hope can=E2=80=99t of course fix bugs :-) , so I think =
we have to focus more on fixing existing bugs and=20
Adding device drivers(of course the ToDo-list is not news but still the =
truth;-)

Thanks for taking attention the current firmware things, always worth to =
take a look into.


Regards

K.

> Am 25.12.2022 um 17:37 schrieb Mark Millard :
>=20
> On Dec 24, 2022, at 20:14, Mark Millard  wrote:
>=20
>> On Dec 24, 2022, at 19:15, Mark Millard  wrote:
>>=20
>>> I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
>>> BUS_PASS_ORDER_MIDDLE and the like and they allow being
>>> sure that the brcm,bcm2835-dma related setup has been done
>>> before any use of it is made, despite the order in the
>>> Device Tree: use an earlier pass for brcm,bcm2835-dma
>>> related attach. This avoids the kernel crashing during
>>> boot.
>>>=20
>>> The example context used below has: serial console with
>>> USB3 SSD boot media (not requiring a usb_pgood_delay
>>> setting), booting a stable/13. The RPI4B is a C0T one (no
>>> 3 GiByte limitation, for example: the PCIe wrapper logic
>>> has been corrected).
>>>=20
>>> stable/13's source code changes ( similarly for
>>> releng/13.1 ):
>>>=20
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index cab8639bb607..d8b49acfe332 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>=20
>>> static devclass_t bcm_dma_devclass;
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>> +    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>>>=20
>>> For reference, a 13S snapshot with my kernel build replacing
>>> the snapshot's kernel, was booted with:
>>>=20
>>> # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
>>> VC_BUILD_ID_USER: dom
>>> VC_BUILD_ID_TIME: 11:09:05
>>> VC_BUILD_ID_VARIANT: start
>>> VC_BUILD_ID_TIME: Oct 26 2022
>>> VC_BUILD_ID_BRANCH: bcm2711_2
>>> VC_BUILD_ID_HOSTNAME: buildbot
>>> VC_BUILD_ID_PLATFORM: raspberrypi_linux
>>> VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee =
(clean)
>>>=20
>>> There are new things present that FreeBSD reports
>>> but ignores, producing messages like:
>>>=20
>>> clk_fixed4:  disabled on ofwbus0
>>> clk_fixed4: Cannot FDT parameters.
>>> device_attach: clk_fixed4 attach returned 6
>>>=20
>>> over and over during part of the boot. It seems to
>>> retry as it goes and thus produce so many messages.
>>>=20
>>> There was also:
>>>=20
>>> fb0:  on simplebus0
>>> fb0: changing fb bpp from 0 to 24
>>> mbox0: mbox response error
>>> fb0: bcm2835_mbox_fb_init failed, err=3D5
>>> device_attach: fb0 attach returned 6
>>>=20
>>> genet0 is working.
>>>=20
>>> I've not checked if the microsd card slot can be used.
>>>=20
>>> I used the normal FreeBSD U-Boot since I was not booting
>>> the NVM3 media that requires extra time (usb_pgood_delay
>>> would be assigned in my own U-Boot builds).
>>>=20
>>> For reference, I used my typical sort of config.txt :
>>>=20
>>> # more /boot/msdos/config.txt
>>> [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
>>>=20
>>> [pi4]
>>> hdmi_safe=3D1
>>> armstub=3Darmstub8-gic.bin
>>>=20
>>> #
>>> [all]
>>> #
>>> # Local addition that avoids USB3 SSD boot failures that look like:
>>> #   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
>>> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
>>> initial_turbo=3D60
>>> # U-Boot that has, for example, a built-in usb_pgood_delay =
assignment
>>> # for a media specific issue added:
>>> #kernel=3Du-boot.bin.2022.10.arm64
>>> #
>>> # Local additions:
>>> enable_uart=3D1
>>> uart_2ndstage=3D1
>>> dtdebug=3D1
>>> disable_commandline_tags=3D1
>>> disable_overscan=3D1
>>> #gpu_mem_1024=3D32
>>> #
>>> #program_usb_boot_mode=3D1
>>> #program_usb_boot_timeout=3D1
>>>=20
>>> # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
>>> # That would make the below inappropriate for such contexts.
>>> [pi4]
>>> # Locally avoid hdmi_safe's dislay scaling:
>>> hdmi_safe=3D0
>>> #
>>> armstub=3Darmstub8-gic.bin
>>> #
>>> # Local additions:
>>> over_voltage=3D6
>>> arm_freq=3D2000
>>> sdram_freq_min=3D3200
>>> force_turbo=3D1
>>> #
>>> #total_mem=3D1024
>>> #total_mem=3D991
>>> [all]
>>>=20
>>> [pi3]=20
>>> armstub=3Darmstub8.bin
>>> dtoverlay=3Dpwm
>>> audio_pwm_mode=3D0
>>> [all]
>>>=20
>>>=20
>>> As for main [so: 14], the devclass_t use is gone, thus
>>> the source code changes are:
>>>=20
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index 5f9ecb0b7981..83c4c493a66b 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>      sizeof(struct bcm_dma_softc),
>>> };
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>> +    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>>>=20
>>=20
>> I should note that the above is not likely to be
>> the most appropriate in detail. The boot reports:
>>=20
>> # dmesg -a | grep bcm_dma0
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>=20
>> where that last (working) one has the message
>> context:
>>=20
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>=20
>> So something involving BUS_PASS_INTERRUPT or later
>> (but before, say, BUS_PASS_SUPPORTDEV) may be more
>> appropriate. Possibly:
>>=20
>> BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE
>>=20
>> (so after gic0).
>>=20
>>=20
>=20
> So, I'm now using . . .
> (leading whitespace possibly not accurately preserved)
>=20
>=20
> stable/13's source code changes are ( similarly for
> releng/13.1 ):
>=20
> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index cab8639bb607..6d521d6dcace 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>=20
>  static devclass_t bcm_dma_devclass;
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>  MODULE_VERSION(bcm_dma, 1);
>=20
>=20
> main's [so: 14's] source code changes are:
>=20
> # git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index 5f9ecb0b7981..d901447df1e9 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>         sizeof(struct bcm_dma_softc),
>  };
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>  MODULE_VERSION(bcm_dma, 1);
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com



From nobody Sat Jan  7 08:37: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 4Nptrk534sz2sFR4
	for ; Sat,  7 Jan 2023 08:38:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b])
	(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 4Nptrh71Mdz3qpS
	for ; Sat,  7 Jan 2023 08:38:12 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="F3ACMhP/";
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=maciphone2@googlemail.com;
	dmarc=pass (policy=quarantine) header.from=googlemail.com
Received: by mail-wm1-x32b.google.com with SMTP id fm16-20020a05600c0c1000b003d96fb976efso5099536wmb.3
        for ; Sat, 07 Jan 2023 00:38:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=6HG9DngKCIgIgjwi8jK7M/RGXmkTjsc4OKkfNZ9D88Q=;
        b=F3ACMhP/EiUEEVGtIIculguUjE0wgQb62eVKWTcCH8nhBM6TJPnghp6LOE2z6Yl/Nx
         WIfXxJ3A7uSF5+tTWzOly2FX+NFD2zruhI2GS+SxldPGohRKsljP6L4VwPnGpRbpqSe3
         4NsZpbtoxBAHGOU992qwoXjpv0wniTytSmSDOgdGKn9A4sABYx39bdpzdhEfhJFjhQNV
         h90nJyBIY/CgcG22a0qZIRXwQfIqw2onRTSmGKqa0s9wC28AdQJ9MFPhpJLcYHdIIqJb
         I2HMPLwQKRHH7tnyFXADnvpMzzv4IB63yqFxI8KGcBl1/mKMXDnG0Krf4ajFlknAxpvU
         jaXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=6HG9DngKCIgIgjwi8jK7M/RGXmkTjsc4OKkfNZ9D88Q=;
        b=f1bjOrbC7x9yupGdOLMvfvVbwBSVzLKM6PX59FBDtsEKT5GPy1bvnh6j50c+8tyXoT
         xMQA5dfmJ40ZVwNgwYQGzW5TLJ9XOY7Lpg6pDgDm0zCW2jWfB0bvu+InJRkwB/5MX7XF
         QR4kdpR5oEC0/ovNtjN9kp7DIgiitKO56dut2A8/pftqUgFdvfKVzhrT95WJrwsH20MU
         n0X8J4c0AtAqdLyE59QP41tZcV5TIaWrWvar3JJdrh4ejBvvkafOyB22kO6g/NYYWiVM
         5c+4CFc+iftxNVj0LYdsTY95dDshdNaqqfcy/gGTtz7qWD9WYJxFlrTXNFog444tUED9
         3Ceg==
X-Gm-Message-State: AFqh2koFPgCpfEAwrxQXnTpqHWp77wQtZktxybNsH5+4ukcJVH/p6Qtm
	kWZZLM7Fd7MWtotE/FPnMZ6wuaq6KOo=
X-Google-Smtp-Source: AMrXdXuoAa319g23FY/WxliQLhxltgAOMdkJovY5g0UC14ZUA3zIoCjfa/tnZyfF+j4zOy0PMwzabg==
X-Received: by 2002:a05:600c:a4d:b0:3cf:6e78:e2ca with SMTP id c13-20020a05600c0a4d00b003cf6e78e2camr45084749wmq.5.1673080690750;
        Sat, 07 Jan 2023 00:38:10 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-028-121.46.114.pool.telefonica.de. [46.114.28.121])
        by smtp.googlemail.com with ESMTPSA id p9-20020a05600c358900b003cffd3c3d6csm4913684wmq.12.2023.01.07.00.38.09
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 07 Jan 2023 00:38:10 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sat, 7 Jan 2023 09:37:55 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
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)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4Nptrh71Mdz3qpS
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi Mark,

`ve tested your "early_dma=E2=80=9C patch now on the CM4(not tested on =
the 4b)=E2=80=A6
true, it can boot the latest firmware but after investigating in =
what=E2=80=99s new=20
in bcm2711-rpi-cm4.dtb I guess new features are mainly  related to CPU =
(L2-) caches features ,
That=E2=80=99s why we get things like : "clk_fixed4:  =
disabled on ofwbus0
clk_fixed4: Cannot FDT parameters.=E2=80=9C ...
so I think we currently won=E2=80=99t benefit much of the new firmware.

I had a little hope that an earlier dma could shine a bit more light on =
bugs like this :=20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260131

But a tiny little hope can=E2=80=99t of course fix bugs :-) , so I think =
we have to focus more on fixing existing bugs and=20
Adding device drivers(of course the ToDo-list is not news but still the =
truth;-)

Thanks for taking attention the current firmware things, always worth to =
take a look into.


Regards

K.

> Am 25.12.2022 um 17:37 schrieb Mark Millard :
>=20
> On Dec 24, 2022, at 20:14, Mark Millard  wrote:
>=20
>> On Dec 24, 2022, at 19:15, Mark Millard  wrote:
>>=20
>>> I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
>>> BUS_PASS_ORDER_MIDDLE and the like and they allow being
>>> sure that the brcm,bcm2835-dma related setup has been done
>>> before any use of it is made, despite the order in the
>>> Device Tree: use an earlier pass for brcm,bcm2835-dma
>>> related attach. This avoids the kernel crashing during
>>> boot.
>>>=20
>>> The example context used below has: serial console with
>>> USB3 SSD boot media (not requiring a usb_pgood_delay
>>> setting), booting a stable/13. The RPI4B is a C0T one (no
>>> 3 GiByte limitation, for example: the PCIe wrapper logic
>>> has been corrected).
>>>=20
>>> stable/13's source code changes ( similarly for
>>> releng/13.1 ):
>>>=20
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index cab8639bb607..d8b49acfe332 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>=20
>>> static devclass_t bcm_dma_devclass;
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>> +    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>>>=20
>>> For reference, a 13S snapshot with my kernel build replacing
>>> the snapshot's kernel, was booted with:
>>>=20
>>> # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
>>> VC_BUILD_ID_USER: dom
>>> VC_BUILD_ID_TIME: 11:09:05
>>> VC_BUILD_ID_VARIANT: start
>>> VC_BUILD_ID_TIME: Oct 26 2022
>>> VC_BUILD_ID_BRANCH: bcm2711_2
>>> VC_BUILD_ID_HOSTNAME: buildbot
>>> VC_BUILD_ID_PLATFORM: raspberrypi_linux
>>> VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee =
(clean)
>>>=20
>>> There are new things present that FreeBSD reports
>>> but ignores, producing messages like:
>>>=20
>>> clk_fixed4:  disabled on ofwbus0
>>> clk_fixed4: Cannot FDT parameters.
>>> device_attach: clk_fixed4 attach returned 6
>>>=20
>>> over and over during part of the boot. It seems to
>>> retry as it goes and thus produce so many messages.
>>>=20
>>> There was also:
>>>=20
>>> fb0:  on simplebus0
>>> fb0: changing fb bpp from 0 to 24
>>> mbox0: mbox response error
>>> fb0: bcm2835_mbox_fb_init failed, err=3D5
>>> device_attach: fb0 attach returned 6
>>>=20
>>> genet0 is working.
>>>=20
>>> I've not checked if the microsd card slot can be used.
>>>=20
>>> I used the normal FreeBSD U-Boot since I was not booting
>>> the NVM3 media that requires extra time (usb_pgood_delay
>>> would be assigned in my own U-Boot builds).
>>>=20
>>> For reference, I used my typical sort of config.txt :
>>>=20
>>> # more /boot/msdos/config.txt
>>> [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
>>>=20
>>> [pi4]
>>> hdmi_safe=3D1
>>> armstub=3Darmstub8-gic.bin
>>>=20
>>> #
>>> [all]
>>> #
>>> # Local addition that avoids USB3 SSD boot failures that look like:
>>> #   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
>>> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
>>> initial_turbo=3D60
>>> # U-Boot that has, for example, a built-in usb_pgood_delay =
assignment
>>> # for a media specific issue added:
>>> #kernel=3Du-boot.bin.2022.10.arm64
>>> #
>>> # Local additions:
>>> enable_uart=3D1
>>> uart_2ndstage=3D1
>>> dtdebug=3D1
>>> disable_commandline_tags=3D1
>>> disable_overscan=3D1
>>> #gpu_mem_1024=3D32
>>> #
>>> #program_usb_boot_mode=3D1
>>> #program_usb_boot_timeout=3D1
>>>=20
>>> # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
>>> # That would make the below inappropriate for such contexts.
>>> [pi4]
>>> # Locally avoid hdmi_safe's dislay scaling:
>>> hdmi_safe=3D0
>>> #
>>> armstub=3Darmstub8-gic.bin
>>> #
>>> # Local additions:
>>> over_voltage=3D6
>>> arm_freq=3D2000
>>> sdram_freq_min=3D3200
>>> force_turbo=3D1
>>> #
>>> #total_mem=3D1024
>>> #total_mem=3D991
>>> [all]
>>>=20
>>> [pi3]=20
>>> armstub=3Darmstub8.bin
>>> dtoverlay=3Dpwm
>>> audio_pwm_mode=3D0
>>> [all]
>>>=20
>>>=20
>>> As for main [so: 14], the devclass_t use is gone, thus
>>> the source code changes are:
>>>=20
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index 5f9ecb0b7981..83c4c493a66b 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>      sizeof(struct bcm_dma_softc),
>>> };
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>> +    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>>>=20
>>=20
>> I should note that the above is not likely to be
>> the most appropriate in detail. The boot reports:
>>=20
>> # dmesg -a | grep bcm_dma0
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>> bcm_dma0: cannot allocate interrupt
>> device_attach: bcm_dma0 attach returned 6
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>=20
>> where that last (working) one has the message
>> context:
>>=20
>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>=20
>> So something involving BUS_PASS_INTERRUPT or later
>> (but before, say, BUS_PASS_SUPPORTDEV) may be more
>> appropriate. Possibly:
>>=20
>> BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE
>>=20
>> (so after gic0).
>>=20
>>=20
>=20
> So, I'm now using . . .
> (leading whitespace possibly not accurately preserved)
>=20
>=20
> stable/13's source code changes are ( similarly for
> releng/13.1 ):
>=20
> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index cab8639bb607..6d521d6dcace 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>=20
>  static devclass_t bcm_dma_devclass;
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>  MODULE_VERSION(bcm_dma, 1);
>=20
>=20
> main's [so: 14's] source code changes are:
>=20
> # git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> index 5f9ecb0b7981..d901447df1e9 100644
> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>         sizeof(struct bcm_dma_softc),
>  };
>=20
> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>  MODULE_VERSION(bcm_dma, 1);
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com



From nobody Sat Jan  7 10:18: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 4Npx4v0G3Qz2sRMQ
	for ; Sat,  7 Jan 2023 10:18:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.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 4Npx4t49Zdz40rl
	for ; Sat,  7 Jan 2023 10:18:54 +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=1673086732; bh=x5tL49TmrhPXFTAe+l40GUaMBxz+Mr7Ls+g4TJyNNks=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oLlX25pBSVVtJGzxZhSljmM7S1V3H3BC8AmenCAmKKInG4gZS39Uyz5a/173VBs3fWGi8ml5eAcTmo34J73BisIWjSFnHu4+U/kKzqRoPMOalYgpfCcZdvCPlC0pT3Ejcj9dFtVzuzfe/VxfgBhtupsqnmIOqesP0/yWzB4BD/1+WHdR05yb5+FveknwB3mjs5UhxfCT6KRjCgN1GM/Auub+5Ffiqy+oborDaCz9JA8ahOdXfoeFG/NzlCgfiiwNpSEMvRTJBI91xz4JaLgQt4/EN5ZjmGE0AVaj/Kd5711E9gpAXHCMjF5CW6RZaBGElQ5wh5u7ck0jvutExeLoPg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673086732; bh=VVMEgeoVFBbQb1psNztMTwJRyBZDNs316dF+c1ctdeb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IJNEh63vdtNg9Iq+TSA5IvDU/nKQ0+pkGwwhDkMzwdeKE81GqfXx2mmt6kQ1Zri+jSBki0/EiusJBqLKAK2GQT+NQjbb+JW2l9L+ZNFUqYuVJyVWJdb2okwQWHXh/ubCfannbw9TAMOGJrvl55nn4VLgjdAo8ZkRzEZNFAPCncPHbr6rXRfRF0D/XmX8wnc1BDIBu3/jKOjhiyuAe8OCG0ijLvO+cTaJRMo+MOeJkGR2dj+Y0NgAZJEllrht2svdvX4KkP+IGPXPamVPQu4tNPkQOAa7nSQawlr1SB7f+0B8NzslozQcfUocyhcNpBbzZXz6sCFtFmCC/Qab04mQRQ==
X-YMail-OSG: bS9UbFsVM1mhYikjmK55gm63mh7RV9YkXCD8XtVbRctYnFQuzfLghEdZdzTv8SW
 OAJgtvp5Ey4JR62Qyu3PE.9OjJV4hcLl9E2TNC2L189DEcbYmjaJ_mreLOuHFVQFtDVwVzP5ijtq
 BtrbyZXbGTrsyeieF1RWjgqr6jiwpuGWi_6mxvJ4NHq5cqH8J6LGZvp_QE8YZ0H9r.sd84lg1meg
 uG15CjsgOUo3g96p.ckCU2vY2B1bZTBkTSxh.EleAjo18gu9aNWX78_nK_mSvjmgmfMIC4cDK7Ep
 QxIHz_eUZfqt.hPboo0iqUXH61sWayVzpsvWGumKGX9asrxDIL83FSku4xkxyUkpiVNYcs_Wu95c
 ZpJ7KShqmSczjCPEmIX514pYF01CfalVq5QxoYW9ae2iHWIWenIsTiBiULmZYiYGdJNAAfT94odj
 O.axuE4HTNQdpIHqyPylDxguVgnBeMtXU42qAED4AkZRCjTRmbwz3mVEbaIdAbj5iN8ZSI4PgcgK
 P9wtSGeZmSCbsXPoOjrIewHd73F0C5H772z4QMDP_Bx7DN3uMVpCbTXGn5eLOwfcAKl4pnvfWO7s
 ub9lsXF7JveBJ2jjtADH5laEVo.CJoWrn_n1_Jm3MiWTfZLP.6shLnY2a1ZOC4I6ur47yZ9jmPHL
 7G9XjOagJG86vJG7yTKxeHHR7zLKMx6tNYe1hhZWOh10Wzhi.HCPcX0Q6Z8HHFtoNPBKUF2fYVYA
 H24ViuytS5jP4tPMDJHc.2cKEJ3_U6IK2ZfCi_yizy3X60lzK3CxoUPqaTNzdUzAQXRnAIYd11vb
 OefseXF7uOLxIDwuwZl5rIhQYYFSvuEhcOj4XeeRoxrekxWzZ3kTjnW6TAdIuv38elxztMQ92xMt
 vCY1XFNtH_surkmqudoAfFAsxeMbcBZOy2NKWIL1ku1YchI4yl5h7nSFxAjHfJve1h9YHlYHH8O5
 jnojBj1AtOCpfsTfbAi7y6W_MQ5R.1OfIP8Safkx6Zwdvt8TufdGQU1dTSB22aR3h40VAqt2aJEl
 MQnUXHJDNy0YCQA16KxqY9vYT6J.tufKOVoykTxFxnqK6LLink_B1cX6h6MKnImvkqsOpP.bLfmt
 SzimuRPcZJMmV2zU90UhSEvHoblbRDuUe0o_W94zTVGVxiS3XPd0SZJLmHy9POXjk1Rdu6TXGtkE
 fA54z5f.qjtrB9VexTqUL2Is3BYdbyLhMdbf4JfEXUr7CcuO8HbRQFcANFGSSLkY3lLheK2IhZG2
 0Hl88z2rNI6Yjme64OwesBHDaGgKhGyvsXmF6zROwmSkDCskr6CqT82WqHxTZUn_Don7.jr40hdD
 yHo4X0J1uDO3VaJXNLGP6Zu1Z.A5SkBN4Y51MXiwnXAtt8evjzKNylD5Fpfo3d.kviJIqIO9Yho.
 I.N7VUYO8iZ41OkJsQD6q7VYwrVqKdOBF9WAjDcljc.dU4j2E3pNKk8rERALrCHUV.uxeqLMT3eI
 rIO3gMCOje0bWV.80VNRZE4wsT_Hk_rGKr888yrP50hNILBP7ywF7txHFtkapwz30fGcfi5Ohpup
 vCU0jT6lfV9mmxnXUO4VMo_iqCaJcQui2kezSP0fd841fgVcove3MEQQWWKviBzrD474vMu_iYJm
 GKkFcnNd2r1J9bKrfYjf1KD6RlgX1HlFw37.mVkKkkYXnNuSVko0ih4GnyNTOwz9d237RSgNcbqq
 nek0HR6Q0bPPcjRgIHxuxRkkIXGmqO0zQTlgqp9k8J_13bMdCdSaoaZzAfVx3TVUfzeg5pOjoOnL
 yHY_xk26jbmX4B2Yg8tXV7Jt9IzpqP3iUYtFk8eHe2ekSGQ3_1AJmGnR.pe3X8HfOuZtcy7gTjAW
 x1aQUtYE_UAcCuX.uWvxA4SdIuIxKakvg5ED2tlsIWXct0Fz0PXcu5rll3pwVYt2PH2tBXwqrGgp
 wy58WKlfpexGSeCiWEDr1GgELK.ijHwUTy2pWeM0mzS1BOuf7iNx7xMp5CKEiwSmT9SnaG1AASAk
 m3weWv4C.zVzuKHEEuulolXwAkpywdTKafPkh8D.qwfV6Gc5fXv4xSaBpQgZfeE4uXzty_gcNRA1
 A3pKRW495v.Tk0jllH.nU2x.crW5OCv4S2qhAYpHHMsJojjVgU5EV980uHMlL5RLEnPp.KRe.KAg
 eFE_cWe8bb0aSWx.sNzsO5lW6J_rnU1Z7YUT9EYaf4LtZp0GB1XFwu4Zw6CQj88vwJSn8zSoLzBi
 zMoM8ZODi8NAJ_Ss8exLz2uS3o5QM4dsVllHZhhzWGscSbiB8uxB8WenatJxOx1wZfuDeh2Cg
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 7 Jan 2023 10:18:52 +0000
Received: by hermes--production-ne1-7b69748c4d-7hwnr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 815e910cbfd1024f33064bc7658413ba;
          Sat, 07 Jan 2023 10:18:48 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
From: Mark Millard 
In-Reply-To: <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
Date: Sat, 7 Jan 2023 02:18:37 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Npx4t49Zdz40rl
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



On Jan 7, 2023, at 00:37, Klaus K=C3=BCchemann =
 wrote:

Hi Mark,

> `ve tested your "early_dma=E2=80=9C patch now on the CM4(not tested on =
the 4b)=E2=80=A6
> true, it can boot the latest firmware but after investigating in =
what=E2=80=99s new=20
> in bcm2711-rpi-cm4.dtb I guess new features are mainly  related to CPU =
(L2-) caches features ,
> That=E2=80=99s why we get things like : "clk_fixed4:  =
disabled on ofwbus0
> clk_fixed4: Cannot FDT parameters.=E2=80=9C ...
> so I think we currently won=E2=80=99t benefit much of the new =
firmware.

But being able to boot with the firmware should make it
easier to deal with investigating other things related
to more modern firmware. Also, it avoids running into
the specific type of crash and having to figure out what
is going on for it: one less problem to wade through.

In fact, the modern firmware corrects mistakes in the
.dtb's relative to the RPi4B PCIe description. For a long
time different parts of the information were inconsistent
with each other. But various OS's (including FreeBSD)
ignore parts of the Device Tree information and do their
own thing independent of parts of the Device Tree
information present. This allowed various things to work
even when ignoring things was not a deliberate way to
avoid the inconsistency(s).

FreeBSD may well have hardcoded RPi4B specifics that would
be wrong for a CM4. But it is still better to target
getting the CM4 going via using the corrected Device Tree
information via targeting a more recent RPi* firmware
vintage that has the fixed information --instead of
targeting the old vintage with the known mistakes in the
Device Tree.

> I had a little hope that an earlier dma could shine a bit more light =
on bugs like this :=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260131

The only BCM2711's that I've access to are RPi4B's so I do
not see such problems. I've no clue about them.

> But a tiny little hope can=E2=80=99t of course fix bugs :-) , so I =
think we have to focus more on fixing existing bugs and=20
> Adding device drivers(of course the ToDo-list is not news but still =
the truth;-)
>=20
> Thanks for taking attention the current firmware things, always worth =
to take a look into.

Thanks for testing that the bcm_dma related patching
applies to avoiding the specific crash type in more
than my particular contexts.

This weekend I'm trying to upgrade all the RPi4B boot
media that I use to be using modern RPi* firmware
(without boot crashes) as part of a general round of
updating the FreeBSD version things are based on.
(Also: RPi3B, RPi2B Rev 1.2, and [armv7] RPi2B Rev 1.1
boot media.)

> Regards
>=20
> K.
>=20
>> Am 25.12.2022 um 17:37 schrieb Mark Millard :
>>=20
>> On Dec 24, 2022, at 20:14, Mark Millard  wrote:
>>=20
>>> On Dec 24, 2022, at 19:15, Mark Millard  wrote:
>>>=20
>>>> I finally ran into EARLY_DRIVER_MODULE, BUS_PASS_RESOURCE,
>>>> BUS_PASS_ORDER_MIDDLE and the like and they allow being
>>>> sure that the brcm,bcm2835-dma related setup has been done
>>>> before any use of it is made, despite the order in the
>>>> Device Tree: use an earlier pass for brcm,bcm2835-dma
>>>> related attach. This avoids the kernel crashing during
>>>> boot.
>>>>=20
>>>> The example context used below has: serial console with
>>>> USB3 SSD boot media (not requiring a usb_pgood_delay
>>>> setting), booting a stable/13. The RPI4B is a C0T one (no
>>>> 3 GiByte limitation, for example: the PCIe wrapper logic
>>>> has been corrected).
>>>>=20
>>>> stable/13's source code changes ( similarly for
>>>> releng/13.1 ):
>>>>=20
>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> index cab8639bb607..d8b49acfe332 100644
>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>>=20
>>>> static devclass_t bcm_dma_devclass;
>>>>=20
>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass, 0, 0);
>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>>> +    0, 0, BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>>> MODULE_VERSION(bcm_dma, 1);
>>>>=20
>>>>=20
>>>> For reference, a 13S snapshot with my kernel build replacing
>>>> the snapshot's kernel, was booted with:
>>>>=20
>>>> # strings /boot/msdos/start4.elf | grep VC_BUILD_ID_
>>>> VC_BUILD_ID_USER: dom
>>>> VC_BUILD_ID_TIME: 11:09:05
>>>> VC_BUILD_ID_VARIANT: start
>>>> VC_BUILD_ID_TIME: Oct 26 2022
>>>> VC_BUILD_ID_BRANCH: bcm2711_2
>>>> VC_BUILD_ID_HOSTNAME: buildbot
>>>> VC_BUILD_ID_PLATFORM: raspberrypi_linux
>>>> VC_BUILD_ID_VERSION: c72ad6b26ff40c91ef776b847436094ee63fabee =
(clean)
>>>>=20
>>>> There are new things present that FreeBSD reports
>>>> but ignores, producing messages like:
>>>>=20
>>>> clk_fixed4:  disabled on ofwbus0
>>>> clk_fixed4: Cannot FDT parameters.
>>>> device_attach: clk_fixed4 attach returned 6
>>>>=20
>>>> over and over during part of the boot. It seems to
>>>> retry as it goes and thus produce so many messages.
>>>>=20
>>>> There was also:
>>>>=20
>>>> fb0:  on simplebus0
>>>> fb0: changing fb bpp from 0 to 24
>>>> mbox0: mbox response error
>>>> fb0: bcm2835_mbox_fb_init failed, err=3D5
>>>> device_attach: fb0 attach returned 6
>>>>=20
>>>> genet0 is working.
>>>>=20
>>>> I've not checked if the microsd card slot can be used.
>>>>=20
>>>> I used the normal FreeBSD U-Boot since I was not booting
>>>> the NVM3 media that requires extra time (usb_pgood_delay
>>>> would be assigned in my own U-Boot builds).
>>>>=20
>>>> For reference, I used my typical sort of config.txt :
>>>>=20
>>>> # more /boot/msdos/config.txt
>>>> [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
>>>>=20
>>>> [pi4]
>>>> hdmi_safe=3D1
>>>> armstub=3Darmstub8-gic.bin
>>>>=20
>>>> #
>>>> [all]
>>>> #
>>>> # Local addition that avoids USB3 SSD boot failures that look like:
>>>> #   uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT
>>>> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling =
port ?
>>>> initial_turbo=3D60
>>>> # U-Boot that has, for example, a built-in usb_pgood_delay =
assignment
>>>> # for a media specific issue added:
>>>> #kernel=3Du-boot.bin.2022.10.arm64
>>>> #
>>>> # Local additions:
>>>> enable_uart=3D1
>>>> uart_2ndstage=3D1
>>>> dtdebug=3D1
>>>> disable_commandline_tags=3D1
>>>> disable_overscan=3D1
>>>> #gpu_mem_1024=3D32
>>>> #
>>>> #program_usb_boot_mode=3D1
>>>> #program_usb_boot_timeout=3D1
>>>>=20
>>>> # Old RPi3's/RPi2Bv1.2's may ignore [pi4] and the like.
>>>> # That would make the below inappropriate for such contexts.
>>>> [pi4]
>>>> # Locally avoid hdmi_safe's dislay scaling:
>>>> hdmi_safe=3D0
>>>> #
>>>> armstub=3Darmstub8-gic.bin
>>>> #
>>>> # Local additions:
>>>> over_voltage=3D6
>>>> arm_freq=3D2000
>>>> sdram_freq_min=3D3200
>>>> force_turbo=3D1
>>>> #
>>>> #total_mem=3D1024
>>>> #total_mem=3D991
>>>> [all]
>>>>=20
>>>> [pi3]=20
>>>> armstub=3Darmstub8.bin
>>>> dtoverlay=3Dpwm
>>>> audio_pwm_mode=3D0
>>>> [all]
>>>>=20
>>>>=20
>>>> As for main [so: 14], the devclass_t use is gone, thus
>>>> the source code changes are:
>>>>=20
>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> index 5f9ecb0b7981..83c4c493a66b 100644
>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>>     sizeof(struct bcm_dma_softc),
>>>> };
>>>>=20
>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>>> +    BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
>>>> MODULE_VERSION(bcm_dma, 1);
>>>>=20
>>>>=20
>>>=20
>>> I should note that the above is not likely to be
>>> the most appropriate in detail. The boot reports:
>>>=20
>>> # dmesg -a | grep bcm_dma0
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>> bcm_dma0: cannot allocate interrupt
>>> device_attach: bcm_dma0 attach returned 6
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>> bcm_dma0: cannot allocate interrupt
>>> device_attach: bcm_dma0 attach returned 6
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>> bcm_dma0: cannot allocate interrupt
>>> device_attach: bcm_dma0 attach returned 6
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>> bcm_dma0: cannot allocate interrupt
>>> device_attach: bcm_dma0 attach returned 6
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>>=20
>>> where that last (working) one has the message
>>> context:
>>>=20
>>> gic0:  mem =
0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x400460=
00-0x40047fff irq 30 on simplebus0
>>> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
>>> bcm_dma0:  mem 0x7e007000-0x7e007aff irq =
31,32,33,34,35,36,37,38,39,40,41 on simplebus0
>>>=20
>>> So something involving BUS_PASS_INTERRUPT or later
>>> (but before, say, BUS_PASS_SUPPORTDEV) may be more
>>> appropriate. Possibly:
>>>=20
>>> BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE
>>>=20
>>> (so after gic0).
>>>=20
>>>=20
>>=20
>> So, I'm now using . . .
>> (leading whitespace possibly not accurately preserved)
>>=20
>>=20
>> stable/13's source code changes are ( similarly for
>> releng/13.1 ):
>>=20
>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> index cab8639bb607..6d521d6dcace 100644
>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>=20
>> static devclass_t bcm_dma_devclass;
>>=20
>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>> MODULE_VERSION(bcm_dma, 1);
>>=20
>>=20
>> main's [so: 14's] source code changes are:
>>=20
>> # git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> index 5f9ecb0b7981..d901447df1e9 100644
>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>        sizeof(struct bcm_dma_softc),
>> };
>>=20
>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>> MODULE_VERSION(bcm_dma, 1);
>>=20


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jan  7 14:53:32 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 4Nq3BC38Bhz2qmHZ
	for ; Sat,  7 Jan 2023 14:53:55 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2110.outbound.protection.outlook.com [40.107.255.110])
	(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 4Nq3B959vfz4KVV;
	Sat,  7 Jan 2023 14:53:53 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b=P48MA+pq;
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.255.110 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com;
	dmarc=pass (policy=reject) header.from=microsoft.com;
	arc=pass ("microsoft.com:s=arcselector9901:i=1")
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=DzwggE137qBk9NbKP+r4/Zot8LEmAmz2PDZj5DuhuxYE4Ll1G5UkZj1qPmxxWBMvKdvrzLkwVL1yMh9k6fS+dYpdTriSHouYmkv4IMJOBsmoGoSsjxdiMcX9KhqshAlXyFRYP0w29wW3i/kw2UQJQZHePcacR9/tmqDw8dheJnPA1hvvv3R+VP/JC/LZSrmPU1m+59XWubYzfTg2V/FiejZ8f+ESMCSWCzupZP63+AXOOsSa/zBVA1vBcTdKOLZFlMAlZ8wYBADcg6vMcEN6gzisEOSYQ0Nkz5sxdwjnbgtlFZtNpUtn2vaai1+8jr/veqlcVOg7yenKS8W7ytZpEw==
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=6NUgHlS8mwl6l7DvPfsM8eMxoW69Hx0Q/iHf2IyEh1s=;
 b=G8K6ISGsrw6SXysHzLF96z9QKmUcPwQN/di4aQjymXK2d/Bf0GGHh5erJeKK9yQye2PY5yIodUYk8eXUNuSMg8wnAWpOVg1rt7gI+46BLJlHdyCCktciSoooTKZwPSpoghFm720iQT/doirL+JQgVh8oz7mtFaxFdpMJLiuG1HvnTHTjp7Qxm8c3ROef1HBOQ6R9EfeHmo0OVcEud6CwaxKLTsvZyTaALoE4F205sLVHQXogowKglCar3QgBhdnH34jfvlflWv+JM07WkOv3ptqz9M81ARYne9Rz0MCKHqOVpNZIPay1niBC8c6xf6WvhKWe4HOf1fIdM8BamUCqUA==
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=6NUgHlS8mwl6l7DvPfsM8eMxoW69Hx0Q/iHf2IyEh1s=;
 b=P48MA+pqPxTzr0A5I2AAX5eUmhN60tluZIylEHX/Zle+m//bzn4brAYJ6qAlhj78oL/iDZoyktk2tUnL69sCwnc9sGHng5sXq+tAV6GQpn19mWtCcWxhihFkqNy6l7wI3d/nUYzVLK0jMc+T6j4zpR75bsW9UzgbETT0FCpQd+U=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by SI2P153MB0637.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fc::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.4; Sat, 7 Jan
 2023 14:53:32 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290%5]) with mapi id 15.20.6002.009; Sat, 7 Jan 2023
 14:53:32 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , Li-Wen Hsu
	
CC: Wei Hu 
Subject: MSI  CPU affinity for ARM64
Thread-Topic: MSI  CPU affinity for ARM64
Thread-Index: Adkio8F3khe3N5kdTvWiOLlk332lhA==
Date: Sat, 7 Jan 2023 14:53:32 +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=db4a32ba-f893-40d3-8ebf-516da4c3f48c;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-01-07T14:23:14Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0637:EE_
x-ms-office365-filtering-correlation-id: 5c0e51d8-1283-4467-705b-08daf0bef239
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 fF0Aa3kgSWrZZodvbpRBsfTQNUFrgoND1ClePOuk7Ih8qJb69MrUl6CcWswp3JjhR5dICbHoqWhxqQWBx+K7Le0It37o5qnaw1ud2ZuTW93BYVQMrDj7oUrvJykaHNSCBnMJvXtMaQspi7jvJyiyUygOB2uDzW1Ty26FtXX14g18G/0DEKeAUliT5xjE55zUCSant86zbZJYpwuVJc1psVzHMQ6w1Iu+5wlQN6VAJZ0PWBAzwCa1OnyI6Fryg9r/BZA6jsmvgA1DfcMedIIeZD1WS2mivva1kazllnmEBkq6mdApVu8F79Rmwmr3ck+NIe+A89pxP/EUV4Y+5Oqn1hexJQiGRuas7guhEzt12JfZ6wrcndqdMNiFxvbhLUCxnIwySJwtVnHEId1lvkH3MvSOOLqDUUMKUx1W3y79E51MkE7KP8tqPR9TqCvr3cewXaRchzDXpAFEOfMrNwjRA91tZdlLV9T2cl9CpfhcqNpiwuisMJGm2XAbtQnx4KjNyeIYXU+vGXyv9R+vnPeej3z7fGxzeq8LDImSCQjiWGsneJGQbox7sIoNYCWgVolYKR+q830pckSOCpWg4C9Bdd71f3YgakSiu03b9Cx5i76EwgnA7cjtZg+bX+BiSnuQIyfepX9FEsz/bndekmem1knl8QLE0uC1FSgL6Ps5YeorYPKQ3VyXZ15Ud0j0i2GzF2smbWDFFu7mN/GNYps2jwITwPDuVZ/6E7PSibbVJuXD9RLMEMT+VFXZaZFPHyHi
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(376002)(346002)(366004)(396003)(39860400002)(451199015)(71200400001)(9686003)(186003)(66946007)(6506007)(10290500003)(38100700002)(110136005)(478600001)(7696005)(316002)(107886003)(66446008)(4326008)(450100002)(41300700001)(64756008)(76116006)(66476007)(8676002)(5660300002)(8936002)(2906002)(52536014)(82960400001)(4744005)(66556008)(122000001)(38070700005)(82950400001)(8990500004)(55016003)(33656002)(86362001);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?AUvWQHRUf+bi/iSLk4SwYBrAyEMw4FePD/OkP0XsGnEBm92Q+z3MoF0a+iF7?=
 =?us-ascii?Q?YXPfh49DmubBFvCg8rnu/N2qSR3iNE3wPq7r2xhRLbNP42d8xHvLXFkkRcgU?=
 =?us-ascii?Q?D0p8h97wrktwD/KdLuEXa62VmamZi0p3wWc6cJIeLE4SUHpnek2kDgEXk8HH?=
 =?us-ascii?Q?VnZ5Yw6N3TI1z4TuRze39uI6pBjIsFPzGZxQnxQsApzBb7A1fAQWrV0RWmEf?=
 =?us-ascii?Q?Y+Xg68LULPoeNy1Xpu3qxXAvsNepf8UeADhXrN+oFg5DIMkV9HNzjTQQ6CaT?=
 =?us-ascii?Q?sYSwLQeWo6PeFwErDkiCKH28WNgO7J/DBq0ee+MRBYjMjrmN7sGl81zDgVX3?=
 =?us-ascii?Q?vXkMNhkx0499ljnIH+5DLlYARWxBF+fTPhnJyvkDyRjH4j76I8NGML9jo/C9?=
 =?us-ascii?Q?NfHOciF7nCISlIxdwMZKeAlPGE8S3bJ8lHz1QPKzWsOB5N2dX+ILa4XfdEmJ?=
 =?us-ascii?Q?Q/IHARb+Dbem0ybd9R1OY8rrtysqnOxMsAq/mJrjehuT5BdPZHzwqQFIvdrs?=
 =?us-ascii?Q?1Rvcadnmr7XS0cpnz2VnBRvxgJgoIx3hU/7lXHrS9cvSB0H1K8TOvLb2/LqC?=
 =?us-ascii?Q?vr13Vdjw7B6cwSejn64iltR0qE1/G9SDqlUWfu+jCwzJMip4g2pGfe/evhmp?=
 =?us-ascii?Q?12jKrf187AaBXoWCC4Nbh3yWy+xrLbsLsQgD4Acs44e1umUI1zGGRSq+hMHk?=
 =?us-ascii?Q?+Wqo7Rp1JstMOqhFxP5hXSzKC7Q+Ubr0yisguOzJoM8dbOUxLQOBVAt4ir6/?=
 =?us-ascii?Q?wjNohJEb8eHV+2DQrfWv+ys+Y3A346NiHW89SLc4zFFuE6H0CGao1N4XJc76?=
 =?us-ascii?Q?CyAxlWP69rPAHnpDyksNCSDdPgoZq/mlPS6DLFGNfxByO50ZtN3fjm43Tapx?=
 =?us-ascii?Q?91k1+8WBzZcFeum5KwWxaKLzQSUF+yOj7Nf2IjCc1KCfOOTFU/k9R53Tqvat?=
 =?us-ascii?Q?jMGQm/FwfxPZm7fKOdVqjQO/uHakZeH3XScFqWwXM68d3MiNxG4U4B+z+mly?=
 =?us-ascii?Q?bKCrgZUcfVGO75Up/brGXH9H0U+md0Mabl41lzbsCfspnnz+pKWiKA+Oge8z?=
 =?us-ascii?Q?o1nGMWxJCKCNiuhqI2mcJtHLWNIoVVUNxssnk7ZxulT/zoXCbuPbIZ8oHo7H?=
 =?us-ascii?Q?93UMrYPWJ/6w91EFpU5T8pudZ45+JK5XU4ZcTjLUQTlyG3wNJTM1YQXHjC2r?=
 =?us-ascii?Q?hKDaquCzf3YGHD1826kOcLn8jWvR0X5s8nEvhKPR17rm2N1UTnmZaLLTr/mM?=
 =?us-ascii?Q?HD5+vyEae85/7dZY+uTxvlh4NzSgZLvWYxvR4Dff/5JjZo0RPgeLIUz8Vxhf?=
 =?us-ascii?Q?c/nkdJyD7IjwbgAnPbylbJPTsyexOlw6mYhyyvbZX9qcI3OU5ZC09/l9Rfpw?=
 =?us-ascii?Q?ZHwITdcLBmvd0R+ku1+jvydfblYFffdc9z1PScGjVQEF1WbQrj6FC7arzWNy?=
 =?us-ascii?Q?y4Aje6BKR1MvJOkvw/BXPTDw88AErxMDSyqClzDxXqfR4YbA7FSJK1sE79K8?=
 =?us-ascii?Q?nZwkSgIUnvzI4ozXE8r2Zi+2nooGGhZ750hNy+EZMUCaph6SlIIr8LJybSS6?=
 =?us-ascii?Q?duYzhoXuiybEyj+8d/yCUwvSndXGOE0vFyhu4kAu?=
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0e51d8-1283-4467-705b-08daf0bef239
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2023 14:53:32.4024
 (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: f57PCHzq5G5j+4CaqyhOzDOzLceYUvL3vUKssuKihPB50yKRMY5AdRk5QkPQEGvCNvJ9hwreyRrAsiKtKJgnZYsBY3EfwX6HEDC/2HKxl/M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0637
X-Spamd-Result: default: False [-10.00 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.255.110:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.255.110:from];
	DKIM_TRACE(0.00)[microsoft.com:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-Rspamd-Queue-Id: 4Nq3B959vfz4KVV
X-Spamd-Bar: ---------
X-ThisMailContainsUnwantedMimeParts: N

Hi,
I am trying to understand how we can find the target CPU for  MSI in ARM64.
When looking at gic_v3 code I can see following:
gic_v3_bind_intr( ) does mapping to next incremental CPU but gic_v3_dist_in=
it( ) does setup boot cpu
as the target CPU for MSI interrupts.

If I need to find the CPU bound with a particular MSI interrupt, how we can=
 do that?

Also is there a way get the the CPU id from the CPU affinity in ARM?

Thanks & Regards,=20
Souradeep

From nobody Sat Jan  7 18:07:16 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 4Nq7Td0lkLz2rCW9
	for ; Sat,  7 Jan 2023 18:07:33 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 4Nq7Tc4P5cz3Nhd
	for ; Sat,  7 Jan 2023 18:07:32 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x631.google.com with SMTP id fc4so10345735ejc.12
        for ; Sat, 07 Jan 2023 10:07:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=v024224RRfv3G8vOkJ6NiDyAB/90bt4RJ8ZWVd3bsg8=;
        b=XR+5HzfDHS4DGMTYtWiAshgtsgLYC6aP8lGOm0sXraxDeC0zC8sSGXpWCn9wK7ZPrV
         1/FUu5WaKgVcUbPBVSHAyRKfn5+tJNAVBOoEoSmS4nW+I+gMinlW43oHL/MyrGjRH4br
         dPF7wbRCl3W2bv51SKlSdM/4jUz4wSqy8/so7IDZ0D0jRldh79XFyPh1gGMJsm58j8Je
         s6BAykLfO+D4xWkwqOE8NSduQhvlP+6WcFisgqRG+lY5oatGX590dyJ476d6JDTYqbOk
         8xUZXdlnvBmglnYDITEJk7BU5+6CJJ71PX271vNEzqeti2CeAu9kTHzvf3fj9I5Aq7kt
         NXMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=v024224RRfv3G8vOkJ6NiDyAB/90bt4RJ8ZWVd3bsg8=;
        b=egow4vi8pTG9tcR/KnN3h6RfhKRnR42Yxd0bKpQfSUnWp9ooMEqHL1cFQyy8/mXihg
         bCE9+o1DjZuwqO3rIESsTYJEvskBFhmagpfF1voMQ6i0qgqJRToVlX/9UrBhZEAx+8KK
         cszac/QrPm8GfPuUGXLe6DMXMseczBV7HRoIEc8Q2WoZA4z8/GYW6dS/9dj9YpJW0YTY
         f6PUe7xlmLftXNJPppOdNPblO7ri6mw4F5fKCkMcv/rtzBkIHPmSJNsQgpum18g2qHGQ
         0E/QuNUUup8G2zDhZY5kkGlN7fUslqCHwYyDOK6DkBF5vYOazVqyrRwaCGDELCu2Tp7W
         vqJA==
X-Gm-Message-State: AFqh2kroMKO1zDQRLnNUq7v1MiIKWJp4p6XqEvd3RtXu0HSscqAo6t2e
	g5dM3SKOp3RVo20TjD5Rw7MGyaGdzwQ=
X-Google-Smtp-Source: AMrXdXt8uvzvGOszw3Gwm5mP5OdW51a26J0YeigrMXJqhkheWKVECEge7f7TVuPl2RCyCjjIL45kNg==
X-Received: by 2002:a17:907:c99d:b0:7c0:d88b:1695 with SMTP id uj29-20020a170907c99d00b007c0d88b1695mr42403413ejc.55.1673114849749;
        Sat, 07 Jan 2023 10:07:29 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-060-191.46.114.pool.telefonica.de. [46.114.60.191])
        by smtp.googlemail.com with ESMTPSA id f5-20020a170906824500b0084d06963e6bsm1645736ejx.89.2023.01.07.10.07.28
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 07 Jan 2023 10:07:29 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sat, 7 Jan 2023 19:07:16 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Nq7Tc4P5cz3Nhd
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>=20
> ...In fact, the modern firmware corrects mistakes in the
> .dtb's relative to the RPi4B PCIe description. =E2=80=A6.

just a short estimation for now...
there is far too much to say and report on the firmware/u-boot and =
specially its targeting linux kernel, so I'll just refer to your above  =
snippet :
In such cases I presume that hacking the .dts files on a per device =
basis should do the trick instead of following the upstream =
=E2=80=9Eblindly=E2=80=9C because if you fix 1 thing by merging the =
upstream you=E2=80=99ll perhaps import the next problem from the =
upstream.
There were cases when even OLDER firmware was better than new versions,
so I would always focus on working fbsd(img.xz) releases on a per device =
basis=E2=80=A6
or you would have to test EVERY embedded device and all (perhaps =
fixed)bug reports would have been worthless when you import=20
the next problem=E2=80=A6 also you will not want confusing dmesg`s =
filled up with messages of linux featured drivers which do not exist in =
FreeBSD
=E2=80=A6 but of course:

If you can fix a relevant issue of an existing driver(like the pcie on =
4b) , please give your device-hack in phabricator review,=20
but also please be warned of =E2=80=9Enew features=E2=80=9C in =
fw-releases which taget linux(or even only raspbian) instead of fbsd=E2=80=
=A6
..just my few cents..

thanks again for all your effort ,

Regards

K.






From nobody Sat Jan  7 20:33: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 4NqBk93Chrz2p3vN
	for ; Sat,  7 Jan 2023 20:33:37 +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 4NqBk86jsqz3rDZ
	for ; Sat,  7 Jan 2023 20:33:36 +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=1673123615; bh=I9O8pqec/eYwmOb1UDT33ygBMaNUfnb5trLozMs06/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DFUnPEtS1Ggh3a9qREVsH8WOVG7iVqDqfKgcdTxh9FiduP+/drqKwQlC1HPW9cFBDo4ALeHpYAVVyiMdE2RXqOofHuPHTp65vIHJ37syhjc2hTSYhVFTIodz96e88Zm36ReW3sk57msd4DLx0o6XkJAO/XOwJB8cdvwCImQ65fDWw8gPFgVrvpbIL6+2U+nok1irauH2R7ytHEzrR2dZfk/xfO+4cVV3gQnHrg+UK8zFCL1FqBvF1zevUF0DxuRP+vw8LjhY79Tmic4kSwqCPTmFUioQZcUJ4xQm6X6dxBJHiS+vunJPh4p1CsMQQJtJ6bpS4s6ZPT8G6H9MIGkTwg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673123615; bh=1TOV3k5Ch5dk6L53wIM1zM5xlwIYfs276nrZIhkvgas=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NVg4COKVzcanAmu2w61TzyQS5xhodltcuMXwoZEU5SHCRtgGzDdcGbZIW+jQ/TH+RYNU5sU/M4SXjg8z8RKyxXpTgSJDu4okJTjCMBvuuWVn5KdRInANtEQLun2EvAViAl8/9PVpYG/mUvSVSTSOGb3bqEToFYopnOSDHxVmMAf4cVUrcvbh8DJftvuR7It2yjgoWjodtZifRu/PIaAKb4OIf2W3b/aeb4nCXVoy1wiIiSP+noZNEdPHqzQIaDTD3v9wdWJj4xpHpq02PSVGYoTCbhIMInw24Y3RqztaRpJAnfx/5MQQkZ1sjGC+9NBgKZJBJabCY6lKHVWh+2UomQ==
X-YMail-OSG: 7mrus7EVM1lOZNA3CEe4GvtaGpnZYiiCS10F9lS4TFD.4tBwoTZn3UG7rtVNjHV
 zKJdaaVu9gVzQwyG0Is1qQka32lY_LVFzm0Pj50BMsJwJF1btYvM6M55dTc7eAZkZ0F_nsQfSUGA
 ZOPBehdMa0wWyHuJEYrYqp1CAAI7NJ9ggNJZlYBgIn0_pGVeN21mHclhkTs6yc9cTXwEacX0TXPv
 r2KI7sArUMlTn0QlZpmckktnXibVEbgP5eHq_YSrYMxlRTkYoVrrMW6BXCC_NOKOoGg3aWfN85L_
 Xkwq.KM.B5lL9l.GN74GMnt7lMtOKMSW0i_j.JWlfygE3ELf0KeJ_ReOchQaPjJ_edth8FaxaQiJ
 hGjNkhA1td5w3Soe8lyihsb.bPQB8IwB8.JsmxFg0Jx5RswGpj8j1IOjyurvJZMqvWQFzdRAyGKd
 I_9arH60ImJe0pnp7b_bS737wspNCWLfNY5fQ9A0S0TMhvSmAfKbrdIUcGBR5.GN2XFpDYkd40Ty
 cD.3goy8H9uemdE_0zAmqJFEH52ONgIYw1I6Jgxvh_3_s82BkCt3_rhSN469bRJQKkPmmQC.DzRe
 dccc.1f9_zZlxvHvnyxLq4kFtYcfWaVbSwQY8_6ybqrYgXeSE241cBWP1adM9EsAIzky108ZFaIn
 CLTRMiTKYFaKnYZwgllBd8cAu64SNooDVSezasS1n5zJ33Ui10P15P703qi41HjTj_0Py9l6VEjP
 ad3uChR0SgEGte0916Igr68AMOsYGuZsyMkNWXFzmfyzRpi2Z8CJwP_ZFlmQZkqQwLsRf6uYL0hU
 73DFj98H.7XXNcljIq1wLNP6lsAyPVvxJzcW07YLRxlJPa0qwKnf1BN5_95x9GoWNxGYQ.Ith_oa
 TTBubULfwsVguNRgeeVZnE_F_fxn2rd69JAXRCuRy9RNGwHwcocg5eWWj2WB5t59tC3FKYgQza7B
 GFsAkNGhJs0lX0N1erOY6Ln4kuLOuTpn8vFF.wylZaZA3paehp5xzVf37T767k_3nrabmq6umz4b
 mvB6HZisUKXabQMaSFLIA9XQXvCj4utXzIhFYzC8uRJ_UrfTa7qryMu9LkVM5eR4A.MNKb2p__Y4
 iHbAcxDBAQAKlXvu4x8X.urXa_RxbPG8Q5Ybkr_Reh27.aitnXCMo_OGA5zKsUxO5TGnZn2OvlkP
 R7M8L_0TmDuwVXpW1sd2WLnKA4Hm2yZvV_sN9eodumFNygrjetX1rUAlstQS6M975.iAJaZJQEAl
 LoYuNATmr5pzyAvpjDuaSCe6eYMQqhSBNTTki24h4WOxsifQFm0wGxTLf_Ew4AlfBEsuS1s9wcEK
 3G1_tEyCst6kZAjqIgLEvUZ1jlNOv3lKAVsvemK_mqg4Dn.cAE8dNAu1vG44f8DyG9At_qqOS2T8
 yDE.jZQ0hqJk2vJ48a4cRogPQK9smcRBSIUmy4UotoeA1vAZmkVgCRQtSiz0YYf4cS9uXxd7Nv7Q
 7CAY1Q6xkI46nX7hAEbk7_qNTdki0pbrb93eFuP464QZPB9T88qwB4.LomSHtrUn2Ar9pP47Pb1.
 C4cBO27eAf8MHUCBrA3MikByxG7U1eF9ALHA_O3yviFmA_59GQYV.f.ak2yj_c7bTZoleyGgWlFP
 y.5xNn333yb25u8jfyPS6x.xKQ6pVRa.tcQ0p1wtmwr5pFOhWXVShngp99qh4OYWVvb1lLwldnS.
 yGsLjcZnC.4v_87ovpaWueERrsK5uQVnHjnkdL09r.95zp.ZopxtL94AAX0C2H8DBNZCXbcQsjV4
 LK7hQulXgtrd7OYjoOlR4x7kRSTztx2KNTUJlmc2fAUqNyovZYUX73V57OrNNgxSvADY60IePbOE
 R2dY_3GOc7jNVwEJXWJm8xll0MnVBAVWq6cDSZBlG4PbXiwrMlMHbLv4XO10DwRX9UWYabcYOtEO
 1z65O796Mf7tWzC2DTa5wJ5gB7cBt8EIGXQOO6j6bjS4BKWD1JCscjLSlzCZwTV9wHb44js0iR.R
 A9FGa8JOc5nr31LT5P1udOmG2VdCnM2g4KCtWxtO7xMQCNeATrIuh.vuPCnSeCILahzxliJ3PbWA
 iaLXcx9S3LhXRmGJaBdCF.s4BtoNaIdkg_qIuM9q2q1RbNpqibGGcg993QST.CMLw7fwB0LMoclA
 rzgv2O2DXebkto_gASvBm3L90wvP7VvMRX71glM0lKE3cyeWDjuuEM81nFE5d71DaB1WWViL5IQ7
 MQFZOo3JArFoYse9k9LcValz2nqdzB6KI6jo1_V8cP82F5UA9gqi9v5PiZtPAuxbYnsNfjwdLm4E
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 7 Jan 2023 20:33:35 +0000
Received: by hermes--production-bf1-5458f64d4-kq8fm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 139bc9d500173296327b66ddf2d39a51;
          Sat, 07 Jan 2023 20:33:31 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
From: Mark Millard 
In-Reply-To: <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com>
Date: Sat, 7 Jan 2023 12:33:18 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E36A955-9B22-4D54-9EEB-B74FCB5B67FB@yahoo.com>
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqBk86jsqz3rDZ
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 7, 2023, at 10:07, Klaus K=C3=BCchemann =
 wrote:

> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>>=20
>> ...In fact, the modern firmware corrects mistakes in the
>> .dtb's relative to the RPi4B PCIe description. =E2=80=A6.
>=20
> just a short estimation for now...
> there is far too much to say and report on the firmware/u-boot and =
specially its targeting linux kernel, so I'll just refer to your above  =
snippet :
> In such cases I presume that hacking the .dts files on a per device =
basis should do the trick instead of following the upstream =
=E2=80=9Eblindly=E2=80=9C because if you fix 1 thing by merging the =
upstream you=E2=80=99ll perhaps import the next problem from the =
upstream.

I'm not aware that FreeBSD maintains patched or replaced
versions of any .dt* source files for any device (beyond
being able to identify that it is from files that FreeBSD
imported). Everything is from an upstream, as far as I
know. As far as I know, all such are designed for some
linux kernel, mostly for mainline. The RPi* .dtb's used
used as binary files may be the only non-mainline=20
examples.

> There were cases when even OLDER firmware was better than new =
versions,

That probably happens more for the RPi*'s than most others
but may not be unique to RPI*'s.

There are also examples of importing mainline .dt*'s that
lead to FreeBSD failures for non-RPi*'s. I've had examples
of such (Rock64 and OrangePi+2ed in more modern times).
But it normally means a later adjustment of the FreeBSD
kernel to support the updated Device Tree established
upstream. In all my examples, eventually FreeBSD started
working again after the kernel was updated to track the
upstream .dt* changes.

FreeBSD depends on folks using devices to report when the
*.dt* source updates break things for some device(s). There
is no general up front work to make sure all the updated
*.dt*'s work with the FreeBSD kernel that used to work
before the update.

> so I would always focus on working fbsd(img.xz) releases on a per =
device basis=E2=80=A6
> or you would have to test EVERY embedded device and all (perhaps =
fixed)bug reports would have been worthless when you import=20
> the next problem=E2=80=A6 also you will not want confusing dmesg`s =
filled up with messages of linux featured drivers which do not exist in =
FreeBSD

Avoiding a crash for a valid Device Tree (even if not
otherwise supported) is not the same as choosing to use
the Device Tree that otherwise gets the crash. One can
still use the historical one.

> =E2=80=A6 but of course:
>=20
> If you can fix a relevant issue of an existing driver(like the pcie on =
4b) , please give your device-hack in phabricator review,=20

If I end up concluding that the patching is safe enough
to submit, I'd not propose any change to the RPi*
firmware version that FreeBSD uses.

I have to use more recent firmware to test the patch is
doing as intended. That is not the same as saying FreeBSD
should change the RPi* firmware version it uses.

I view the patching as fixing an example kernel defect of
incorrect general structure for handling of a Device Tree
resource initialization. (It is normal for various Device
Tree resources to need to be initialized early for other
Device Tree content to put to use as far as I can tell.)
The older Device Trees happen to accidentally have a
non-required ordering that happened to accidentally
initialize bcm_dma first. In other words, I do not
consider the patching a hack, even if someone ends up
pointing to something I could have done better than
the patching I'm testing.

> but also please be warned of =E2=80=9Enew features=E2=80=9C in =
fw-releases which taget linux(or even only raspbian) instead of fbsd=E2=80=
=A6
> ..just my few cents..

Again, I've not proposed updating the RPi* firmware
vintage that FreeBSD uses. I may propose the kernel
change to avoid the bcm_dma related crash when anyone
happens to try newer RPi* firmware for any reason.


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sat Jan  7 18:58: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 4NqGC349BRz2pNTF
	for ; Sat,  7 Jan 2023 23:10:23 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f])
	(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 4NqGC33fF8z425f
	for ; Sat,  7 Jan 2023 23:10:23 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62f.google.com with SMTP id u19so11349243ejm.8
        for ; Sat, 07 Jan 2023 15:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=omShni4RNwVJqfH2T4nTNPGbue2kVgWvciIDiYdmK1I=;
        b=KguWSc1pS6xxfUwh03C9pSLCuuZaKdfN3HtRC3Yz5M0FOt+76r17uWKbSnRqicgoeC
         g7OurAVbhlUzMryCxw01NDpV6qMApvgOXChUjlL7sEWwLIMKVwruPGxulrlujXmsYFB1
         VSTv3Nejx6itppCtKzFIimVyRjqf91c72EJ+9P1vx9IOlw5K4HoD9DgWfiYNigh/sxbv
         EmOMMdNcoPHllgdAL19xfTLDWGUUxL5PLX39Q0Pawb9XRNoT1lwQuu2GQFW0ZLq4M9N3
         Uz88bXBWX2/MCvTsNH2mjFRfHMXnpSjih069Eukn+42ajBK4gA1Dj8+9YFX/bkUF91z/
         nC7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=omShni4RNwVJqfH2T4nTNPGbue2kVgWvciIDiYdmK1I=;
        b=YkfZErJPXql5gplx9P/orbs3dNBdXQXg6KCd7weIoSMMjqC3vuhLtB1isryihIJQbp
         61PXNNVuLk8M/QRmfecxhxLWKX6nYX0zuAzEM04BnPNFdxAFy+II+2so5kddOY0a8jIj
         Lbh5cQIm4npaS18aA+9BNBvsXQ+y5Q9DRPUzDK5Ostq443NAISe9ePlYmSgjwxH2ENeV
         ySXTjYVjdoJKC8pJEP7lxGP8FoH08P7FUxXJYvy4hsxVy/oR+bhhWMX3GPDVy9a9eCFL
         5F7eVopwWn2RjOZyvpwdnCHi+0sXNJrs2DjmyE83Jb7POq0rbaCSGqqwitmDRL2nC3W9
         iTZA==
X-Gm-Message-State: AFqh2krTV67NIzr0VJ6+Q6LWoOgWjn5n1ss6ZSOqJmTrHu9coM5ebnMf
	ULQ3fw7ve4PbhT+epvzGTWs=
X-Google-Smtp-Source: AMrXdXuA7GcN1L79ncmnbvpURlOB8fne7gn35ur0gQAJLi8t8OQ/J6LenD8EtDeIjE0rSWjEeslDtA==
X-Received: by 2002:a17:907:a0d6:b0:7d3:c516:6ef4 with SMTP id hw22-20020a170907a0d600b007d3c5166ef4mr67291584ejc.20.1673133022403;
        Sat, 07 Jan 2023 15:10:22 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-060-191.46.114.pool.telefonica.de. [46.114.60.191])
        by smtp.googlemail.com with ESMTPSA id l10-20020a1709063d2a00b0084767d40f0dsm1868699ejf.115.2023.01.07.15.10.21
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 07 Jan 2023 15:10:21 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sat, 7 Jan 2023 19:58:55 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqGC33fF8z425f
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>=20
>=20
> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
...
>>>=20
>>>=20
>>> stable/13's source code changes are ( similarly for
>>> releng/13.1 ):
>>>=20
>>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index cab8639bb607..6d521d6dcace 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>=20
>>> static devclass_t bcm_dma_devclass;
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, bcm_dma_devclass, =
0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>>>=20
>>> main's [so: 14's] source code changes are:
>>>=20
>>> # git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> index 5f9ecb0b7981..d901447df1e9 100644
>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>       sizeof(struct bcm_dma_softc),
>>> };
>>>=20
>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>> MODULE_VERSION(bcm_dma, 1);
>>>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20


=E2=80=A6=E2=80=A6.on the other hand : if your =
EARLY_DRIVER_MODULE(bcm_dma=E2=80=A6 doesn=E2=80=99t do anything wrong,
you could give it in phabricator review, why not?!..


Regards

K.=20=

From nobody Sun Jan  8 00:59: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 4NqJdS5knGz2qsKN
	for ; Sun,  8 Jan 2023 00:59:56 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4NqJdS2RBZz4Ctq
	for ; Sun,  8 Jan 2023 00:59: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=1673139594; bh=1yE6LAHn7r2F9aLmfrJUM4Ei3Zcd43eFGHSfliExK34=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S4P/hjCflQX2/4KlJ+A9rKF5ujT5ouqPECYMVPlpCVkqyiYVftjGJIXjI8jHH8xKJ8CJRGH1ZuoPB4JkMFyL+QIC9p0/ORVBdERdF5omdKG3kCLXOK49+xWJ6xn4l5OoQJR7kE9gmwwG35QWwmGSLZFonqaC0C5awA//8BcXI1EcxoLhZflYdHJjqLqxar75Ntn1BWPTqBRXImkV1Bl+D1p+u9Q2xq0S1Y6oa6sBnPBZ3L/lxLhU8xQ4c7Ef2VPIVD7zg6K6McmboNLZMvGiF0GLdvucJrCN/H9ym6uynDFbtZsPyJ059tlsrwS3Z8uecZ7r6fyGrXVHHiujHJ/7SA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673139594; bh=qsyJDA+skhkFysN7IJ7UGAtyX8qcfqdDROJOUxQM4Jy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=V5BlamoSrmV2y4NVJVQcDXP0mYVDIfuCAMi50NSNfxz0re9LFPq4kfsvkB0BJgTtlSP0C96b54CKvu+zuKP2iGd1PkF6V1kjAHzp4ZTTG83f8W7YdfAiomtYTktfl8XYgjAGW7ixIoNOlZ/FKceijEhPVELB2/m9aLZkjzx2l1LiS2sLSa9HOONFtOt91dfyzDkYJtIUCvAZYl+pWIcKb766Te+1eymrcwR2PJh8qyrLjBhkebZygj+yXrkaGILuuwMXLuXkwzjs8a1xKnbYL41ypQ3uV3/u2dPvwHk32qBA5uTyRPh+JI9Na+hIbTKvHiSslTuoXjlhToWleGjgAg==
X-YMail-OSG: S1bFucoVM1lP6pLyPHFEAiyZefSvHZ5Wq51aYNGbo19lQXGx3ngBm1PAbp9vwG4
 JXwfWB6VIl.vnVGSC1ZeLTSi54BEmmqe1C8mXk.STRQLEJfh6KfQDI62Apg_TzeJ5925TxHkxVa4
 rJq9cSovbZ9QGz7uIWkx0QJzq16y6t1j9NdaV87mQ3ZbjWtpzNafe8IV5BKAuZW__kTR3YXUEV8O
 nDs5GWBo.4ZwJXwt15cUGR_Bfm4YckRsUjpdlzuBs.shB4tlk1ohd6cGfgW9BHbVkVH6bebPVxsW
 awuA62wuk3ZPNcvYK8qwItKWT2hmc7vxkibOaQOcljNd0OlKgLiGOclaJ_tFjxFwF83MSFFrBkEq
 6szaWENa7JEd_.GIEVYg4DomBWclKzgPrQqomgp0x4qoiEvs1kOGm4N9uETUG.iMtv_Dm_69H5m7
 9ltw6W5Ed1NqCcLzu8jM19MkxOeNiJfHZX3KexehrXSNcfZY513VfzbCsojq7FJQxqLpn_xv4Q2V
 HSSh0tqUXkS5ZXy8JMjF_UADlM3gZkDomadmGuMIwSh1P14YE8h7sAvxSUCQaiqmCo4BlcwDOA4P
 qhv.qxSpS5gnvPoJshHu6sD12dsSaGhXA52c7ZseG9sS6Ix5wIzBTjGq9nSyw9XWBWFKLbTEirZ_
 3OosEf2TN7UeCLCGJpiMTy.FpA9CFuBE9Ppz3AltsLVsYRbl8bk1NNBQKkUOptgxQXyoAH07FJ8W
 fpEAOkhkO5UE9ZHqmNY6I.c1pkGShk6i821BQ7Tevo6JhEaEP94HNLg0MHIZBrR3oE39vkBo5KIJ
 BSwfSoYnJa5Zd6Nw79usFOTQvfKrsxmDeDZ55B29KvCrGaW0UFZOdX2NOVziVHGGrA6t5025Wb44
 qRhNtwV2PRqCWDdkb.aSpbJDcbOI8goG9FJGjta1__OhnA1sw7lLFVHojhNewchq5Jl2_41gCShG
 .zkEaKZTemSu4IGY15ojyjwE6SMO94gTULMpSBELXHlRLDycRFDwseJN0xw9bBdK0Fes0Jak8.rU
 PgbxONYqx413dT_icu2IXafL3hmRy1HEy7tWO0qyLxZU_2TwI06xhVmEPS4bXIx2Ef40Sy7kW.ji
 44FOHW8uhfV8rwHX6mfMZCdVcRIV0PCBoXuDKLt5D8jvZzAlPGP7CIj83toP24rTcDGm0zRye4Lb
 hChNxMTq5hJ5pev1waNEkaN.sL9nzMaob2Nua3.SEwfxA9whePZ4UxnQtY8zrybVcQy1nM9XrajH
 loOimjmYtWuJGH25DY0YJ056VCm.uQEYMDqEDhqOER6LUDA895dHmol3Zj1vvS12KAfVzEiJgEOI
 2oQiHr872502T842CiPe0dezlocu0lX6YXhY21gXua9mzoe8cyTYPUlVTdIryZbE2MmAlkFFMyHz
 3JPdwb_kCrs9pgZxluY5BgUUwvyTvDkTUBCKMzOrcAHDFIu2jU.EBQ.x0tn6TPEgiyiAdv42mWRa
 Nvp0jRGi0tj8SCvbKmPHJyCHFW8mxvvIp1EJzx8B.XkfLirxsQdwJHg9tVj5ZhdFutwv02FvVP96
 PZuDXCqM_VMOl5vY.QwntDaAiT7evh_Z793J6QXSIrPZ1qgL.EzxiE.MbrpiAj_mH0mFzWctdkoy
 KAehBcCR3cYUO9aSCvXwQQAQomcDyUVRFZLZQI5rn4HooMtAR1frlBBPD10eiMd84Kiw1hm4Qw3n
 dh17sRmZqzfD.VDJKu8HqiDounxrMsP_N_nUrDedrOk0eepNka9KP6AcrRTuFnumTVrnSmeaR2kv
 4911V1yjvkseB7uONrXqPqoU5Tm0YUFhLkeIFXW3loOtJMY4ZQFCtg7xbhJlgei6Fcw0WGUaO3oO
 yYsxE9LJJkggWcRFQchWlSximG0aPoYxiAlGCzKXBvq03PfXIuh0eYOhFcky0e_CTOA4sLB_Gvz7
 6QM37tUh68PY77OmEn2Pesw6mkPPoTEo.Kz2WBvGOvKsdlIGoqE9LGLaBtuyjGFK57PL9zYwroSj
 9eiecuneP5xtKI8v20AjQ9C6oA7_3W8TVKT7dmVygyAU3B594zpVzl4kcnEGOo39ePJ71nYSGbcF
 LkdodUtK1xtWILdB6.bd.MH4rY1tTh8STTOwm8nQbMGjrnoW_74I7pjfXS.i3PQEwdfCRmUijZPE
 PRIm04VEK_OJLoHqeZSoCgqlLXXckUTk_VA3DmcsfwcxWkPeaPSbOG02rJcrAYCXUAbnCWRYcI5D
 rD24qhv1o5L1jBKCJguBzmaq.qtbFg8_wYkpXY3ENQb_q3NNDu1FjBHEQitOt.jiTvOCeORQH5w-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Jan 2023 00:59:54 +0000
Received: by hermes--production-gq1-d898c4779-nnvpg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7ea711b08cdcd29ed7ad74503476384f;
          Sun, 08 Jan 2023 00:59:51 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
From: Mark Millard 
In-Reply-To: 
Date: Sat, 7 Jan 2023 16:59:41 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqJdS2RBZz4Ctq
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 7, 2023, at 10:58, Klaus K=C3=BCchemann =
 wrote:

>=20
>> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>>=20
>>=20
>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
...
>>>>=20
>>>>=20
>>>> stable/13's source code changes are ( similarly for
>>>> releng/13.1 ):
>>>>=20
>>>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> index cab8639bb607..6d521d6dcace 100644
>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>>=20
>>>> static devclass_t bcm_dma_devclass;
>>>>=20
>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass, 0, 0);
>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>>> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>> MODULE_VERSION(bcm_dma, 1);
>>>>=20
>>>>=20
>>>> main's [so: 14's] source code changes are:
>>>>=20
>>>> # git -C /usr/main-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> index 5f9ecb0b7981..d901447df1e9 100644
>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>>      sizeof(struct bcm_dma_softc),
>>>> };
>>>>=20
>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>>> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>> MODULE_VERSION(bcm_dma, 1);
>>>>=20
>>=20
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>>=20
>=20
>=20
> =E2=80=A6=E2=80=A6.on the other hand : if your =
EARLY_DRIVER_MODULE(bcm_dma=E2=80=A6 doesn=E2=80=99t do anything wrong,
> you could give it in phabricator review, why not?!..

Yep, once I've better evidence from the RPi*'s that I have
access to.

I'll note that no vintages of the following .dtb files are
in the current sysutils/rpi-firmware port:

bcm2709-rpi-cm2.dtb
bcm2710-rpi-zero-2-w.dtb
bcm2710-rpi-zero-2.dtb
bcm2711-rpi-cm4s.dtb

I've no direct evidence of if any vintage of any of these
would end up hitting the bcm_dma issue or not. But I expect
that the EARLY_DRIVER_MODULE related patching would avoid
(just!) that specific crash problem if it would otherwise
would occur.

There is:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261147

reporting the absence of bcm2710-rpi-zero-2-w.dtb . So
someone might want to experiment with more recent RPi*
firmware, possibly even to develop some level of support
for bcm2710-rpi-zero-2-w.dtb (live Device Tree possibly
adjusted by the RPi* firmware) --if changes are needed.

The .dtb vintage and the RPi* start*.efi and the like
vintages are not necessarily fully independent. Mixing
and matching could be a problem, independent of any
additional FreeBSD kernel-related issues. (It is another
example of the poor level of documentation for the RPi*
context.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jan  8 04:01: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 4NqNgC5tjDz2p2dG
	for ; Sun,  8 Jan 2023 04:01:43 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c])
	(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 4NqNgC39Blz4PKW
	for ; Sun,  8 Jan 2023 04:01:43 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x52c.google.com with SMTP id i15so7761566edf.2
        for ; Sat, 07 Jan 2023 20:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=NM5D1EoYPUUzvvPbp/QJFGMA078jFhJQiyV6nAhX6fg=;
        b=YwIyeFIDtCTJGx0up4jLi3naj/xKLITAC7un0WZ35XcCLTa5yd1HTrCGzgBsi7P4SR
         zG/QCkAj10tYc4FdXyINGeJt2l/nMZDgaanUAP7EQtFzhbgkVbQrrOitLhvBsrNvm9cC
         fxTv/P3xz1s2xmIX3O0WsFfrNvKQ9kVRdi3v046vHgg4Gbz0OVK9ra3tyHrrLSLYumEs
         Hob605izDAcojp5p+YANkboixfyjiktXybWjvxYjF5RltVTMvHMptCW5m1sQxro9nhpL
         LBnR8tRWzOdMqqafWC0/hbrrsTdyFPuzgpzYjg1ghGddENKnBhJqnED3Wd+EGAhfAp7V
         JkAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=NM5D1EoYPUUzvvPbp/QJFGMA078jFhJQiyV6nAhX6fg=;
        b=inMWzOiCNrdXLJbgBOpYJsX1LOMOyMDPqKPTGcPWHiZnvuZo2L9iFUa35gDjT7TTb2
         I8na3SqKMc5Yw8L4bl53P9dKGxh4moM+RlO3lz2S8VV1NVrxSzN1yKjOxB+c7mBMbOeI
         cySjBQExBDdn3UqN9oTYV9b2aU/q9h034Bt5CH4eX7BpMo1dmcp9phv/GhfwgiQF4taH
         bQQFt4Izx/U8zb9HIj7um/w68gDMboD0ilsqNRY7ae+/yFiM9T0HgqPRKtj7VX68q5rF
         PZM4cP1UfLe4K/NKSIuI1uZg1iG/AbISl5fwOFy4NH9pZ6SZge2AIjzq8hn3HO23tIXZ
         j9hA==
X-Gm-Message-State: AFqh2kpMUPAUhbmiH4fBXUf36tmRQsQtoxW/0A2iAjjqiYJCFt5Agr/Z
	5qvdCbqXAhU9U0bXb7pjWmE=
X-Google-Smtp-Source: AMrXdXvdT44J2sHVNK46zV5/EKS9+X4QLV/g3g1cOpFXeQc8kZTPHJi3I9B/03k5ylh+SwsZR0/m9A==
X-Received: by 2002:aa7:d04e:0:b0:45c:835b:ac4d with SMTP id n14-20020aa7d04e000000b0045c835bac4dmr52351870edo.8.1673150500314;
        Sat, 07 Jan 2023 20:01:40 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-060-191.46.114.pool.telefonica.de. [46.114.60.191])
        by smtp.googlemail.com with ESMTPSA id d26-20020a50f69a000000b0046c7c3755a7sm2133374edn.17.2023.01.07.20.01.39
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 07 Jan 2023 20:01:39 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sun, 8 Jan 2023 05:01:27 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
Message-Id: <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqNgC39Blz4PKW
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


> Am 25.12.2022 um 04:15 schrieb Mark Millard :
>=20
> The example context used below has: serial console with
> USB3 SSD boot media (not requiring a usb_pgood_delay
> setting), booting a stable/13. The RPI4B is a C0T one (no
> 3 GiByte limitation, for example: the PCIe wrapper logic
> has been corrected).

O.K., Mark, I=C2=B4ve tried  to read your 4b-related reports of the last =
period more closely..=20
And now I=E2=80=99m a bit confused :
I tried now :
<>
on USB3 SSD media 4b B0T - device directly from a current img.xz and =
couldn=E2=80=99t determine any problems with bcm_dma or pcie,

I don=E2=80=99t own a 4b C0T, just the C0T CM4, where my pcie-bug-report =
stays unpatched since 1 year,
It needs an extended JTAG- investigation, it cannot be fixed by =
firmware, it has to happen in the driver logic.
The CM4 is my personal problem, it=E2=80=99s not a supported device (has =
also devmatch issues on booting),
but I can live with that on working emmc& working genet0..
The 4b(including C0T) is a supported device(is it?) and=20
 if I understand you right :
Your 4b C0T crashes (at least sometimes) by failing in dma-computation.
And you have a valid fix for the 4b C0T ? =E2=80=A6
While I unfortunately cannot test 4b C0T, it=20
sounds that if you can fix it, it=E2=80=99s a must have fix for that =
device?
Side note:  have you tried fixing pcie@7d500000 : in the dts without =
changing start4.elf and the likes?
Is that 4b C0T bug based on start4.elf  or the dts or whatever?

For my devices the EARLY_DRIVER_ would do nothing but spam dmesg with =
new firmware, it can=E2=80=99t fix dma on the CM4 and=20
Is not needed for the 4b B0T...

but is your 4b C0T fix based on your EARLY_DRIVER_MODULE -patch, even  =
without touching any firmware?
If so, you have to give it to Phabricator ;-)



Thanks for your effort,
Regards

K.






> Am 08.01.2023 um 01:59 schrieb Mark Millard :
>>=20
>>=20
>>=20
> Am 25.12.2022 um 04:15 schrieb Mark Millard :
>=20
> The example context used below has: serial console with
> USB3 SSD boot media (not requiring a usb_pgood_delay
> setting), booting a stable/13. The RPI4B is a C0T one (no
> 3 GiByte limitation, for example: the PCIe wrapper logic
> has been corrected).
>=20
> On Jan 7, 2023, at 10:58, Klaus K=C3=BCchemann =
 wrote:
>=20
>>=20
>>> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>>>=20
>>>=20
>>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
...
>>>>>=20
>>>>>=20
>>>>> stable/13's source code changes are ( similarly for
>>>>> releng/13.1 ):
>>>>>=20
>>>>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> index cab8639bb607..6d521d6dcace 100644
>>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>>>=20
>>>>> static devclass_t bcm_dma_devclass;
>>>>>=20
>>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass, 0, 0);
>>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>>>> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>>> MODULE_VERSION(bcm_dma, 1);
>>>>>=20
>>>>>=20
>>>>> main's [so: 14's] source code changes are:
>>>>>=20
>>>>> # git -C /usr/main-src/ diff =
sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> index 5f9ecb0b7981..d901447df1e9 100644
>>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>>>     sizeof(struct bcm_dma_softc),
>>>>> };
>>>>>=20
>>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>>>> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>>> MODULE_VERSION(bcm_dma, 1);
>>>>>=20
>>>=20
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>>=20
>>=20
>>=20
>> =E2=80=A6=E2=80=A6.on the other hand : if your =
EARLY_DRIVER_MODULE(bcm_dma=E2=80=A6 doesn=E2=80=99t do anything wrong,
>> you could give it in phabricator review, why not?!..
>=20
> Yep, once I've better evidence from the RPi*'s that I have
> access to.
>=20
> I'll note that no vintages of the following .dtb files are
> in the current sysutils/rpi-firmware port:
>=20
> bcm2709-rpi-cm2.dtb
> bcm2710-rpi-zero-2-w.dtb
> bcm2710-rpi-zero-2.dtb
> bcm2711-rpi-cm4s.dtb
>=20
> I've no direct evidence of if any vintage of any of these
> would end up hitting the bcm_dma issue or not. But I expect
> that the EARLY_DRIVER_MODULE related patching would avoid
> (just!) that specific crash problem if it would otherwise
> would occur.
>=20
> There is:
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261147
>=20
> reporting the absence of bcm2710-rpi-zero-2-w.dtb . So
> someone might want to experiment with more recent RPi*
> firmware, possibly even to develop some level of support
> for bcm2710-rpi-zero-2-w.dtb (live Device Tree possibly
> adjusted by the RPi* firmware) --if changes are needed.
>=20
> The .dtb vintage and the RPi* start*.efi and the like
> vintages are not necessarily fully independent. Mixing
> and matching could be a problem, independent of any
> additional FreeBSD kernel-related issues. (It is another
> example of the poor level of documentation for the RPi*
> context.)
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com



From nobody Sun Jan  8 08:26: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 4NqVYT1t7Mz2qp4Q
	for ; Sun,  8 Jan 2023 08:27:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.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 4NqVYS3Cm0z4k49
	for ; Sun,  8 Jan 2023 08:27:08 +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=1673166425; bh=ZF94J6Wuw6SUufzjvxVWjUmmHZnJKAiqKSXjblkACqs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rDJD5vtZ6Nyx5nRqoddbw4Z1J4CfGw6bMxONP5lVoGU+l+My8/eicgzrvNjWVkO2J/eB9qDZ79hYn+9RSO6gdAtdqcsprrG8NOM4j2bbIlM10LXSwfmlvPSK6I/jDq5+3mqBjNx6m1xaMXRrCjP/k/G5fy+//ZYUBg4ewBjwk+5Dl1lTrtpEKlOTyR4NTkmF/sRPUX0qBQJDoJV7357CiKssC6LDRmP5GHfFDbq3UqfdTC3eJi4sVpEhTo8JTvUHPhbWt9BlyK2sie3BMWThloTjHdjGb68DPcE5Lz0pGVVVgX9ck82mI35KEH7ROkkS90C7M0+NcPxeSUmZZfPVYg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673166425; bh=jvwO0UYI1LuF8OVLESQspzVdC5j6z17xHbMGCjUSG3L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EABYAtdCmGUigLIxxZNVwAX5dKOiH9X1LHpUZTY8gi0hKUF9Wsnn+csN2g+ANtVzByMe9i3Wm6BKsqR1Ik2dsT1ohTOXr2Wo4WktF+YLmOWlzkEWfQgeWkQuyYWIk2/b/En6NHgVst8XG1rB+VmlSk30IlI4i+GtxL00gWKBP4dZuu2u5WvXNuY7DcqvDkgq4JTJznlvROSd4fpxXk5Ap5Ycv7E23OALj5AFtK52ygZepRyvcy8oLmQ13kkA8P6AROfAlG2o4wvMnktvwUy9Tc1rXclApPFcLuEcs5rcYMp39p3tUvZh3uKZ6ljU84cTf+a81XLaRBXtVZMovn7gbQ==
X-YMail-OSG: pjhBJZAVM1kC_MOBfqSXdkX2MKzQz9qe0Y8qtRF4TbseN6USh3Utrb.1nCs0fHt
 WLIbA03_bKJp8ZZgu_WldVAUOjZsPFUWpcEpDClgQKX9piIV1iQeTuAwDK5pfHoZWTKDZJN6iOQH
 nE_CWDc6YpMoQu.jVqxAO9YQ.KzYGsA_QBE4QXlK71T7YhmhdHeFY1vdMiMxxvoRxEemNlLXPJrY
 T_V8j4fTaJGo6Kom5gyLgZlr71ex9Sy_fgHlRetUL5kbRKR08Qe3k0ZBSjthcVXmMUmgxALiZ7_M
 j8Tg.z1pSITrlFv7VGgzunr8bLGfai2uqHCoyhzmkfO5iCejKLHi8lMGsWGWs8MX6VuEV2t3thwP
 .7NADM8SyJnInMhlYiyfnAVpaedmE73fE2BrEd9JHPx.8j18rbXukDtTu0JUGjJH_muWVHk7Me1D
 KZZ9D_jIitP6FfrRkROq7KVTy6EM2WtisJkuLuszk7nw9j8X2jnbU35gKRY7QeyMw2uPxw23q9of
 6wOhkbmzfv6Jd7N9vlzEKw64EP4cVM7ojGgmJs8JgMMJd3ZznFB6_BwNuttTT947K0FUPdVNbCww
 3OrY0fZjki_hg9PD5kRn4RfUqyi.QiEtX7X_K82P5vzAWGUTPrYX6Mfm3.FTKdA3AtZpLkpFJtzs
 jvw_.yD5vjB0p1E81IEMa81j6rMGjY_3dl_X3GecqpxJrw7xHzuJyPHyW1uUum4m4_GGSzpKfD6z
 7GnUSZLE2OxqmPUqU1ajex6LBe0qexdXdbkvkWoQeK9mwhkpRlwJU.7SI0FXHIVy67Pp5u39t4ii
 mXghkSGTihSD57rnHZ08oUoa9kXo3knwp6CoGohVIifzkAOypV52iZGNjUYBQhM_pzDAk4dVKNeI
 .caDERo9a5jcoJZ6znLVqzTYzRVRWKiVkF0pxMNR1PNTpNK9m.MfRaQdGmey7tWWAAUCbHM_0ZTT
 StfX6VCKRW6nIfuRJDOT8FAAwUHZivM7zbvZYtfFhp6b4CleNjEgFhzb.yWrl1BZHaG1f2AbOgqA
 bCDqNwirhR6ObZPZzwxjvqrfk8YApeAfnod5vId7b8iXM71nHTASvUvhXGAC2R60Pxna.kUwHAS7
 oI5YJTkURl2NL0cYcBYivyX9DJ1qaB0AAAcP93XUP5dsesGW3BEpwedFub2pid8T2eixoJ6qd1Id
 hZx81rrcVoD3GyAWiBfLwVsXLWBgPDXaV3VWcyJx_Lxpt0IZHyuY90voKba_iEPD3b1AVevD9do8
 MdlcVD3N0MjHz.ZQb0sBQhpfVtwIZ_jGPmFmgYkPZgPuLbS3IsBmqs0C4CbgA8OwuHpTp9TecbpL
 f0OzZRk3_6LMRFstEOY6.57otB2.Hl6IFwEqGl1D8.CqFyws5c_rnSVRiindVQQKk2LI0nNHLWCE
 f2QmkCHr4FaXJIJcDymMr.DIezMzd1CQ4Cy_RT_EnnIrEA7QHcG3cDlXVyF9.Vr33gHbD9xEySY8
 cqhGxwhNiUxh.bwFkYZznNhNbjfSzXas5l3OEiCaXoGVPqLAxrpzEV9c3hQkV_EytSXKYVm4kMJo
 pczsw3P7bqL8KoOifEMm_UP3j8Q0ArjJhgGBEAyg8S0XGHWAuSnve4aWTLpPb3VBWOIwXHvrPias
 xVhqVvhJxWqRFMUCCXGLUiQgk3MNDTkZSaJYakBj6edKFScSnE4w43.eI1fqp8xTcflTOk5N8KWU
 inLLThvD6uvD55MAh315WQuk2hSfxwFhB1xT5L.pEypxfBMrt8Tlz9A5yNwR_KA2tTF.DCLdVlm9
 hSxQF3Okk57QdQd3JxnTYtmdHIshm3lHk1qdBaw0ITNaqMNq9nujBCvXt2yRxHQN7c4g8M1VI1tQ
 YDdlMSDdYw4uKfuUsC7jiGKdc.rppugOTHsdRKBQGIMKmZG_vR4a3D4CYBBt2B7b5xLRBO2j2.9E
 F13409k_1rb1Z2YailDmg1HdLSLd89qf8eFjBk77J5lLRe9V0RFYSoMY.TTW3KvVwRCzpcjW1zqB
 f9ktZcHb4R6nnfUPzjwEBRop5SJm3wlBb2yQ0OuBsrM4mBP.KqeYCv9TE08Zm2kvZWcp1_alhRa1
 1fATXlD7FE01OkEsnNykZIb960UJy.Iiu.e30TODHTo6RgMu_nGRRTuU8PtXqQxtu92Zzejf71of
 TizgrKG3aMaoANEikIUdZv2aLiFqZjldt7aqFlyOizCbhS3.d8P7YcCq9LCsyNbB3Qv6oOqTaPbn
 sBQzWx7sWSyJwPc.ZLpVAGRKhgTpTfA81ByqEZ0S1D7uVpUDxwG3BcqIcaGsVops9hG2msU7WJSo
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Jan 2023 08:27:05 +0000
Received: by hermes--production-bf1-5458f64d4-p2fqs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6d8bbeb5fe0ea5c254b378f7811cd476;
          Sun, 08 Jan 2023 08:27:00 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
From: Mark Millard 
In-Reply-To: <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
Date: Sun, 8 Jan 2023 00:26:48 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqVYS3Cm0z4k49
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 7, 2023, at 20:01, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 25.12.2022 um 04:15 schrieb Mark Millard :
>>=20
>> The example context used below has: serial console with
>> USB3 SSD boot media (not requiring a usb_pgood_delay
>> setting), booting a stable/13. The RPI4B is a C0T one (no
>> 3 GiByte limitation, for example: the PCIe wrapper logic
>> has been corrected).
>=20
> O.K., Mark, I=C2=B4ve tried  to read your 4b-related reports of the =
last period more closely..=20
> And now I=E2=80=99m a bit confused :
> I tried now :
> <>
> on USB3 SSD media 4b B0T - device directly from a current img.xz and =
couldn=E2=80=99t determine any problems with bcm_dma or pcie,

I think you are confusing a failed experimental change
with normal-software's operation --and the experimental
change only applied to "C0T" parts. C0T RPi4B parts
should not normally need bounce buffer activity. But I
failed to make that work in my earlier experiment.

(The "C0T" parts can do bounce buffer activity just fine
but teh activity has the overall performance consequences
when there is sustained bouncing.)

You do not have my failed experimental code, so you
could not test what I originally tested --even if you had
a "C0T" RPi4B context available.

> I don=E2=80=99t own a 4b C0T, just the C0T CM4, where my =
pcie-bug-report stays unpatched since 1 year,
> It needs an extended JTAG- investigation, it cannot be fixed by =
firmware, it has to happen in the driver logic.
> The CM4 is my personal problem, it=E2=80=99s not a supported device =
(has also devmatch issues on booting),
> but I can live with that on working emmc& working genet0..

I'll note that for snapshot generation there is in:

https://cgit.freebsd.org/src/tree/release/arm64/RPI.conf

the text:

DTB_DIR=3D"/usr/local/share/rpi-firmware"
DTB=3D"bcm2710-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb =
bcm2710-rpi-cm3.dtb bcm2711-rpi-4-b.dtb"

As near as I can tell, that is the list of what, at one
time, was considered supported (tested?) for aarch64
RPi*'s. No CM4.

> The 4b(including C0T) is a supported device(is it?) and=20
> if I understand you right :
> Your 4b C0T crashes (at least sometimes) by failing in =
dma-computation.

You are confusing standard-code use with experimental
code changes being used, changes related to avoiding
unnecessary bounce buffering for "C0T" parts.

> And you have a valid fix for the 4b C0T ? =E2=80=A6

I've no clue why my experiment failed. I did want to
check if it would fail with modern RPi* firmware (and
the matching .dtb files). But that, in turn, requires
avoiding the crash for more modern RPi* firmware. Such
crash avoidance could be useful to other folks as well
(for other purposes than mine).

> While I unfortunately cannot test 4b C0T, it=20
> sounds that if you can fix it, it=E2=80=99s a must have fix for that =
device?

The standard code for RPi4B's that does the bounce
buffering does not have the problem that my experiment
had --on any RPi4B that I've tested. I was trying to
see what some performance was like without bounce
buffering being significantly involved but never got
such to work reliably.

> Side note:  have you tried fixing pcie@7d500000 : in the dts without =
changing start4.elf and the likes?
> Is that 4b C0T bug based on start4.elf  or the dts or whatever?

I've no clue what lead to the failure of my experiment.
Most likely my own mistakes of some kind, given my
ignorance of various things. But, that leaves me
exploring based on not much understanding of what is
likely to prove useful to explore, at least for now.

> For my devices the EARLY_DRIVER_ would do nothing but spam dmesg with =
new firmware, it can=E2=80=99t fix dma on the CM4 and=20
> Is not needed for the 4b B0T...

An RPi4B with EARLY_DRIVER_ + sysutils/rpi-firmware
does not produce the "spam" messages and does not
crash.

An RPi4B with EARLY_DRIVER_ + sufficiently-newer
firmware does produce the "spam" messages --because
it did not crash first.

An RPi4B without EARLY_DRIVER_ but with
sufficiently-newer-firmware crashes instead --before
it would have generated the many "spam" messages.

The difference relative to "spam" messages is the
differing live Device Tree content.

> but is your 4b C0T fix based on your EARLY_DRIVER_MODULE -patch, even  =
without touching any firmware?
> If so, you have to give it to Phabricator ;-)

I have no fix for my failed experiment. I'm still
exploring to see what sorts of things might have
contributed to the failure.

Other folks may have other reasons to want to experiment
with more modern firmware. aarch64 or armv7 devices not
covered in the snaphots (or even in systutils/rpi-firmware)
could be examples that might be involved. Some devices
might post-date the sysutils/rpi-firmware content. I
listed 4 kinds that sysutils/rpi-firmware does not have
.dtb files for. None of the 4 are considered supported
at this stage, so far as I know. But someone might work
on making one of them somewhat supported. Such a person
might like to avoid dealing with the
bcm_dma-lack-of-initialization related crashes.

> Am 08.01.2023 um 01:59 schrieb Mark Millard :
>>=20
>>=20
>>=20
> Am 25.12.2022 um 04:15 schrieb Mark Millard :
>=20
> The example context used below has: serial console with
> USB3 SSD boot media (not requiring a usb_pgood_delay
> setting), booting a stable/13. The RPI4B is a C0T one (no
> 3 GiByte limitation, for example: the PCIe wrapper logic
> has been corrected).
>=20
> On Jan 7, 2023, at 10:58, Klaus K=C3=BCchemann =
 wrote:
>=20
>>=20
>>> Am 07.01.2023 um 11:18 schrieb Mark Millard :
>>>=20
>>>=20
>>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
...
>>>>>=20
>>>>>=20
>>>>> stable/13's source code changes are ( similarly for
>>>>> releng/13.1 ):
>>>>>=20
>>>>> # git -C /usr/13S-src/ diff sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> index cab8639bb607..6d521d6dcace 100644
>>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> @@ -766,5 +766,6 @@ static driver_t bcm_dma_driver =3D {
>>>>>=20
>>>>> static devclass_t bcm_dma_devclass;
>>>>>=20
>>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass, 0, 0);
>>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, =
bcm_dma_devclass,
>>>>> +    0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>>> MODULE_VERSION(bcm_dma, 1);
>>>>>=20
>>>>>=20
>>>>> main's [so: 14's] source code changes are:
>>>>>=20
>>>>> # git -C /usr/main-src/ diff =
sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> diff --git a/sys/arm/broadcom/bcm2835/bcm2835_dma.c =
b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> index 5f9ecb0b7981..d901447df1e9 100644
>>>>> --- a/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> +++ b/sys/arm/broadcom/bcm2835/bcm2835_dma.c
>>>>> @@ -764,5 +764,6 @@ static driver_t bcm_dma_driver =3D {
>>>>>    sizeof(struct bcm_dma_softc),
>>>>> };
>>>>>=20
>>>>> -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0);
>>>>> +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0,
>>>>> +    BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LATE);
>>>>> MODULE_VERSION(bcm_dma, 1);
>>>>>=20
>>>=20
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>>=20
>>=20
>>=20
>> =E2=80=A6=E2=80=A6.on the other hand : if your =
EARLY_DRIVER_MODULE(bcm_dma=E2=80=A6 doesn=E2=80=99t do anything wrong,
>> you could give it in phabricator review, why not?!..
>=20
> Yep, once I've better evidence from the RPi*'s that I have
> access to.
>=20
> I'll note that no vintages of the following .dtb files are
> in the current sysutils/rpi-firmware port:
>=20
> bcm2709-rpi-cm2.dtb
> bcm2710-rpi-zero-2-w.dtb
> bcm2710-rpi-zero-2.dtb
> bcm2711-rpi-cm4s.dtb
>=20
> I've no direct evidence of if any vintage of any of these
> would end up hitting the bcm_dma issue or not. But I expect
> that the EARLY_DRIVER_MODULE related patching would avoid
> (just!) that specific crash problem if it would otherwise
> would occur.
>=20
> There is:
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261147
>=20
> reporting the absence of bcm2710-rpi-zero-2-w.dtb . So
> someone might want to experiment with more recent RPi*
> firmware, possibly even to develop some level of support
> for bcm2710-rpi-zero-2-w.dtb (live Device Tree possibly
> adjusted by the RPi* firmware) --if changes are needed.
>=20
> The .dtb vintage and the RPi* start*.efi and the like
> vintages are not necessarily fully independent. Mixing
> and matching could be a problem, independent of any
> additional FreeBSD kernel-related issues. (It is another
> example of the poor level of documentation for the RPi*
> context.)



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Sun Jan  8 17:57:32 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 4NqlCt3qJ7z2qlMp
	for ; Sun,  8 Jan 2023 17:57:46 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4NqlCt042Vz4Fvf
	for ; Sun,  8 Jan 2023 17:57:45 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x52f.google.com with SMTP id r26so9413697edc.5
        for ; Sun, 08 Jan 2023 09:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=5Ae/apReVmzIimtAvyDZb5iHKzU9nYfPDM/cHfoaMsw=;
        b=lq3bGwrz7cLUesz3EITXUoRt8OkNAreuDRzE9Z5fv68Tfllrr11rTZxKkLcIQjwGuI
         yzxGwwl5nwUjy+wjIR2tWBvnzOEvoZb9BMT5qS6uaWp1BiupglfM2QYc0qkUUKdyHrg6
         D2Cb52TjwUOm26/F/Xo/0GDJCYH/Q+q4Z2vWnwRyBdZywhLStPCLMqJDhGLDY2krvnwj
         YCVJJm8Mb7koIvXweJmCGReb3ZHpiZgnuTFTB3eWzfXuUxzi+5Z8YwnV4Kj7HTBmQWir
         SELUCSoEItU/I/cmy1rhmMw75u9O8hfzctdsl1gVxhilSisJIlN3UbVSHMLMl7Hq6PQg
         czTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5Ae/apReVmzIimtAvyDZb5iHKzU9nYfPDM/cHfoaMsw=;
        b=b4Q/SNAYXas1JAThjmph+wdotYV5evGQma5ZuTW1mLT18uL9LR2Cnt/sjPUPezkwm1
         hH9A+A8da6RsRoFyn0/LrnxnDTpCbpC1E5HefSi8sTyksjbRS223AYZ3pdWuNzt84+4+
         tUorDZQpfpS/R3KMGJsSpktwLCLHhdmblOqVd4Il7Gth7aO90lFzcuYWZYL9IY8hk6Dj
         SD/5MCopW0DZgKNa6dyyif+kSA28GgBDFpFDP/wAa63tdoZ57xoyp2x3Y/nvxovViP39
         dUb+s8DF9sMZDSYhJ214epkZhcYcuGZJOetwDhQmM40dQ4Lcqr++XCVGH/N3P/jiWOa7
         XwfQ==
X-Gm-Message-State: AFqh2kopxzDjOM/+ex7sIJaAZZau3CIOZXK/lWA1JpyYoXHUltdXVihH
	AHbba2/MgyrURcLbqL2nsNVsEq2SufA=
X-Google-Smtp-Source: AMrXdXtNh6cGv1MA7gC9YJCJResGgycBlNVYK7nVZ8C5xTEp5ozopJ+QCq0wYsbGAOJDKpQArfdi9Q==
X-Received: by 2002:aa7:c6c2:0:b0:46c:6bdc:4116 with SMTP id b2-20020aa7c6c2000000b0046c6bdc4116mr51528992eds.33.1673200664649;
        Sun, 08 Jan 2023 09:57:44 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-188-092.46.114.pool.telefonica.de. [46.114.188.92])
        by smtp.googlemail.com with ESMTPSA id f9-20020a056402068900b0048999d127e0sm2750937edy.86.2023.01.08.09.57.43
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 08 Jan 2023 09:57:44 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Sun, 8 Jan 2023 18:57:32 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
 
To: Mark Millard ,
 "Bjoern A. Zeeb" ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqlCt042Vz4Fvf
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


> Am 08.01.2023 um 09:26 schrieb Mark Millard :
>=20
>  I=E2=80=A6=E2=80=A6
...
> listed 4 kinds that sysutils/rpi-firmware does not have
> .dtb files for. None of the 4 are considered supported
> at this stage, so far as I know. But someone might work
> on making one of them somewhat supported. Such a person
> might like to avoid dealing with the
> bcm_dma-lack-of-initialization related crashes. =E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6...

Thanks, Mark for detailed clarification=20

I think that's about what I expected in terms of the decision if=20
touching the firmware-upstream makes sense or not .
I guess it doesn=E2=80=99t make sense (for now) .=20
For the cm4 I can say that =E2=80=9A unload=E2=80=98 of modules in =
loader or for persistence disabling =E2=80=9Adevmatch' in rc.conf
will get the machine to boot, newer FW not needed and it would spam =
dmesg with unsupported features(for now)..
No clue what the devmatch does in =E2=80=9Epre=E2=80=9C-boot because =
=E2=80=9Estarting devd=E2=80=9C seems to do the job short before the =
root login..
So for now of course unsupported machine type(while not bad once =
booted), since pcie is buggy(and that=E2=80=99s a seeminglybig task to =
fix that).

What wasn=E2=80=99t clear for me is whether crashes like those from =
Bj=C3=B6rn Zeeb have any relation to firmware/u-boot/eeprom,
but reading closer I guess he=E2=80=99s probably using an unsupported =
bootloader that could cause problems,
What was also unclear for me is if there=E2=80=99s a similar boot issue =
as with CM4 on the 4bC0T,
Thanks for clarifying that there isn=E2=80=99t such an issue on 4bC0T.

of course, it is important to examine all of this on a regular basis ,
 thanks for that effort!

Regards

K.







From nobody Sun Jan  8 18:32: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 4Nqm052H52z2qpnN
	for ; Sun,  8 Jan 2023 18:32:37 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 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 4Nqm051dv3z4J60;
	Sun,  8 Jan 2023 18:32:37 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1673202757;
	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=svzMYw3KTncTx9wUrpb187KQX5+g5UqV6loGVBcggnY=;
	b=NXcGwkfmTKx90w4oG7CW61KC5tjGZ/zN8s2av7r83LISsaoli+5imcjVXe8Ia/fOcH3d3d
	bEYC6DEUOGwVL21R9qsm79fbGwmcI3Li4+Ay88kMaY38aCw88W2prJe2C9m7JMejhO3EEY
	Z+tBVFCnHMR6dqYLbG8KBiUkBYZmnGw0evHCvEdpUCCVgVodKZGmiJN9Ywzke5t3VugDpF
	ud+MQWnB8f2xI/wfCt2RLIPKnhEqlLjk8yY6xO0mzr+7vOXbX4vd5u5n3ogeKakElABq84
	emAmdy0et2wXMfuAQIXVQ2X2mNcRQU3ySMAqwACf9VW3Dvp6PhE/fg55PMJZMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1673202757;
	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=svzMYw3KTncTx9wUrpb187KQX5+g5UqV6loGVBcggnY=;
	b=NEYNhlvf9DEE/xwb1Wxm+pelxeJZhEb1UVnUyhPxep/QCoCqSftk78yZXqumDVHGU+K/0V
	FfUNAjdq5JGsK256hLOv4A8gfZWxUeceqRgbDw2XwxO3FaZB8KltXI06BT2OK07DPUQsJ3
	U9oQnjNl1ZZF51RCeVoiSG03geLBGJkZjRzFXBuZAM5wI+ut0nQETacWO/FH87me8Lid5a
	s4NlYgPM0EfOdcNlwoEmJL3R4iF+WubPAkdcdpYyQPMuCFoIrk1GBz5nQq0F9AdL+dLXIq
	b2IQM7pRdBCu9CoPftsAhfaglnmmhNi9uCWIS7QGPrX9jD+sLwk+71tPNZXvSQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673202757; a=rsa-sha256; cv=none;
	b=Zfvrpk5tjm/8RgG55/FSf7226FodKyIgGtsDwpP702ReTj+0wqT9Zn7qTTGoW7XSx28Db0
	5t5y7yuz6aWeRcXVcV1sEdRmQo5Imnm8J34Ma+NJRJi+aAOwCXXWOr700sHdYDa0FFvoFO
	4pDtQtVMNJaOPfdwur2hkWh54od0OK/2DSEwA2lG+nksSEPypsFKnf3YzuRhGKJ74ytFJw
	3GQraEfiDeQSwOzry7qZ49Ymc6GnjX7jR9rTYbfbJAg09EyhShNM4Dvq/wW/4mHI8xFC/e
	NbJK06H4eG1g3qPWyFchoXLEnxjhNbZKR40DSMw4MzmU/1piT/xuJCimlusdAA==
Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127])
	(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: mhorne)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Nqm046lPxz19Kr;
	Sun,  8 Jan 2023 18:32:36 +0000 (UTC)
	(envelope-from mhorne@freebsd.org)
Message-ID: 
Date: Sun, 8 Jan 2023 14:32:34 -0400
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.6.1
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Content-Language: en-CA
To: "Bjoern A. Zeeb" 
Cc: freebsd-arm@freebsd.org
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
From: Mitchell Horne 
In-Reply-To: <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ThisMailContainsUnwantedMimeParts: N



On 1/5/23 16:23, Bjoern A. Zeeb wrote:
> On Thu, 5 Jan 2023, Klaus Küchemann wrote:
> 
>> Hi Björn,
>> ( ..I had a JTAG setup on the PI, but didn’t use it for some time..)
>>
>> yes that was a  "live“ boot example from today of the cm4(on orig. 
>> I/O-board),
>> it hangs while initializing sdhci, while the boot partition is living 
>> on the emmc :
>> —
> 
> Ok, I am just wondering given reboot works fine why reset in db>
> wouldn't.  Given you have JTAG setup you can probably debug a lot better
> than me but also you seem to have a different problem ...  too many
> problems too short time *sigh*
> 
> 

The reason for the difference in behaviour here is that the ddb reset 
command doesn't execute the full list of registered shutdown handlers, 
it just calls cpu_reset() directly. For whatever reason your combination 
of RPI hw+fw doesn't support the PSCI shutdown interface, so cpu_reset() 
fails. I am guessing that it is the bcm2835_watchdog driver that handles 
the normal reboot.

I think it should be just fine to execute such handlers from ddb reset, 
so you can try my patch: https://reviews.freebsd.org/D37981

Cheers,
Mitchell

From nobody Sun Jan  8 21:01: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 4NqqHN0b1Sz2r7Yf
	for ; Sun,  8 Jan 2023 21:01:04 +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 4NqqHM3xpbz3JtV
	for ; Sun,  8 Jan 2023 21:01:03 +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=1673211663;
	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=DevYL9SdKWQHKhMmh04MX3KI1TJaNtqy3rWs8PZ0KOE=;
	b=mY14C5RzqPpFRhvs3h6Yp9tFAXBlvEfVIad/X84awOTlkQ9DVf/HdT5SOJm0zwcUQdZsS/
	sI8bcZYl0O0F5034MocRyk3Jn7olr8CeyBFGZ0DbjNJAZ8YjIQ8EWhdHuhVhOhEM58M+ay
	Iml9ef0vMuVDEKfU6FpBHQcjJ7RYfk9UL/CEZYI8otHfi7jj4MlZlCcNQaBEzYExXl1G7Z
	i/5XiBoAA/a+RcVD3iZzp+l1zqNBra1jZaYNwvNoXPhaeDa2LEVYFXtOH1NIgexlLdr0q6
	5jjiLhoRjvRyuXs5usOAd9jJwugTJWoepLAyw6IPRhhdrsCJQZl2Vg7LXwJ4AA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673211663; a=rsa-sha256; cv=none;
	b=QJnxWjC6hI8voVn1Fl8XyRxdKdITzxc+6Bb8DXGTaugOd/s+ZANo+eohwVDw9vMEXOpUQH
	lEcpT6yE8b/M/HFOCdfSjWB4ierN1Nwp85nuhUwZAQqEKM69Em9UdYoNeEYUrFr5Rot80R
	kyKYZW5Nf47ns9wPKR3X1dZS97x5J6kZkB/h0LEWzh8//QWzUeE/0LIO7Ww1hMUo3fROdg
	tlNqHN2b3dGwKBsa18O6Rg8XHcCTrJhAROrrCT+pq6FZ2+OWJFeYj1VB1e66ke1rECYP7w
	+Mogp3kAiVEgPknbdpv8Nl0HOmDMTbDxt9ymZsQoeYclfhnJBDxHoUJZ5NnB8w==
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 4NqqHM33Ngz131T
	for ; Sun,  8 Jan 2023 21:01:03 +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 308L137s093024
	for ; Sun, 8 Jan 2023 21:01:03 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 308L13pC093023
	for freebsd-arm@FreeBSD.org; Sun, 8 Jan 2023 21:01:03 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202301082101.308L13pC093023@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, 8 Jan 2023 21:01:03 +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="16732116632.bBce.88098"
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N


--16732116632.bBce.88098
Date: Sun, 8 Jan 2023 21:01:03 +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.

--16732116632.bBce.88098
Date: Sun, 8 Jan 2023 21:01:03 +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.


--16732116632.bBce.88098--

From nobody Sun Jan  8 23:27: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 4NqtX83jp0z2p0rx
	for ; Sun,  8 Jan 2023 23:27:20 +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 4NqtX774Mrz3mnl
	for ; Sun,  8 Jan 2023 23:27:19 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
	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 1604B8D4A17C;
	Sun,  8 Jan 2023 23:27:11 +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 2E4785C3A833;
	Sun,  8 Jan 2023 23:27:11 +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 vMm1vQXPUHsi; Sun,  8 Jan 2023 23:27:10 +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 056C95C3A830;
	Sun,  8 Jan 2023 23:27:09 +0000 (UTC)
Date: Sun, 8 Jan 2023 23:27:09 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: =?UTF-8?Q?Klaus_K=C3=BCchemann?= 
cc: freebsd-arm@freebsd.org
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
In-Reply-To: <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
Message-ID: <3s6qq325-4091-s554-rqr3-3q5661ro55p8@yvfgf.mnoonqbm.arg>
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>  <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com> 
  <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com> <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com> 
 <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
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: multipart/mixed; boundary="1098556516-292770529-1673220430=:27118"
X-Rspamd-Queue-Id: 4NqtX774Mrz3mnl
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1098556516-292770529-1673220430=:27118
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 8 Jan 2023, Klaus Küchemann wrote:

> What wasn’t clear for me is whether crashes like those from Björn Zeeb have any relation to firmware/u-boot/eeprom,
> but reading closer I guess he’s probably using an unsupported bootloader that could cause problems,

I wouldn't call it "unsupported" just "non-default" but I am also on an RPi3B+ and not on a 4.

-- 
Bjoern A. Zeeb                                                     r15:7
--1098556516-292770529-1673220430=:27118--

From nobody Sun Jan  8 23:28:53 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 4NqtZ13Hjkz2p0s9
	for ; Sun,  8 Jan 2023 23:28:57 +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 4NqtZ12SNBz3nCf;
	Sun,  8 Jan 2023 23:28:57 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
	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 F39678D4A17C;
	Sun,  8 Jan 2023 23:28:55 +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 67E6E5C3A833;
	Sun,  8 Jan 2023 23:28:55 +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 SLW7XBU0ZJ3u; Sun,  8 Jan 2023 23:28:54 +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 19E9D5C3A830;
	Sun,  8 Jan 2023 23:28:54 +0000 (UTC)
Date: Sun, 8 Jan 2023 23:28:53 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Mitchell Horne 
cc: freebsd-arm@freebsd.org
Subject: Re: (RPi) db> reboot -> cpu_reset failed
In-Reply-To: 
Message-ID: <8q86s05q-1s10-s85s-7qpp-84oq5q79114n@yvfgf.mnoonqbm.arg>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>   <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com> <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
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: multipart/mixed; boundary="1098556516-10291134-1673220534=:27118"
X-Rspamd-Queue-Id: 4NqtZ12SNBz3nCf
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1098556516-10291134-1673220534=:27118
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 8 Jan 2023, Mitchell Horne wrote:

Hi Mitchell,

> On 1/5/23 16:23, Bjoern A. Zeeb wrote:
>> On Thu, 5 Jan 2023, Klaus Küchemann wrote:
>> 
>>> Hi Björn,
>>> ( ..I had a JTAG setup on the PI, but didn’t use it for some time..)
>>> 
>>> yes that was a  "live“ boot example from today of the cm4(on orig. 
>>> I/O-board),
>>> it hangs while initializing sdhci, while the boot partition is living on 
>>> the emmc :
>>> —
>> 
>> Ok, I am just wondering given reboot works fine why reset in db>
>> wouldn't.  Given you have JTAG setup you can probably debug a lot better
>> than me but also you seem to have a different problem ...  too many
>> problems too short time *sigh*
>> 
>> 
>
> The reason for the difference in behaviour here is that the ddb reset command 
> doesn't execute the full list of registered shutdown handlers, it just calls 
> cpu_reset() directly. For whatever reason your combination of RPI hw+fw 
> doesn't support the PSCI shutdown interface, so cpu_reset() fails. I am 
> guessing that it is the bcm2835_watchdog driver that handles the normal 
> reboot.

Hmm interesting.


> I think it should be just fine to execute such handlers from ddb reset, so 
> you can try my patch: https://reviews.freebsd.org/D37981

Thanks for that;  I followed-up there.


/bz

-- 
Bjoern A. Zeeb                                                     r15:7
--1098556516-10291134-1673220534=:27118--

From nobody Sun Jan  8 23:41: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 4Nqtrm0MSrz2p2HB
	for ; Sun,  8 Jan 2023 23:41:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(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 4Nqtrl356Cz3pR9
	for ; Sun,  8 Jan 2023 23:41:43 +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=1673221301; bh=SQbkikBBxtN9dzBsgmSZFBxlsxVGTBfIViG1eWcrl4g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=o6Xoag+4JpNkNTIfVemn6mG+6gUQgOpnspskiiCNRT4pzXu2rqowm98F35LWzRyZ88k5pKcE6g6dD8CkUNAR5s+5xx3a6gzkTP2fHRroG6UC/4c0BT9TKtaEFCz4RoFxmlHOxEVizdRteAMymPe9g5pT7LPbG43iN9XoEHC5vvm8Dxf8czaCfnVj1USXZErmMr3rIcuiCaVm60H3X2ajKq9Gc6YRUNyv2+9uI1wRmQm67nGD1BaK7bP7kbWKYWlcmBsPLJF9UqgH4GQVqQO2Gx0WI+w95YkEbG8lPaGbyF5Ajc0vfSnuL/COo3tbhkW98X31BSiGrRv7SWfe6bGBPQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673221301; bh=dD986UpbH9jDrLd0Ek9/zA6SdjkWpKgNokFiTrImXIi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VSG8oSGoVmgfS4oU5FcA9JLvDkTMHQnGpnX5YnorOkRkmeXhi2iHW+FxsgEhfDQwn3JS35pktvMU12SlTtyjwgoo5FXB8aSn0r5DqN1DNppJGihAtU/5EZh3is+5DZCblAIHdRjqr6O4Hl6OHJjhDkl2btT+YH2kiD2Ah8IWqxRBdupkuTyZX3bTI8Yh6O3k1g4vfeuRO75nBiG4ztnUhg83/AbpJk2sVykuueGU2z50TVK3mIKr1cAQHwUVX3CSpVYeCJN/Z8NpYlxdr0NyAa8OViTsgVTgiHLm85eH8MsB9TBeFZlOp2NSeDC3vYfxMBN+elbed6BU+S4Jje8TAw==
X-YMail-OSG: ZfpvE6wVM1nsyj32HgUVRqwr85RC_QGOZNupXTMAiriLmQv01M6bKocWB6kWI6H
 47bGm45oarK5tiRzjCCRiiPr7nxSXukndDvmafBpldykfwf2V03tU77QH6iTwzZCKKu8PfWWqsJ7
 DNkCTfoAASK6l84zALRC9_qXj1JY7YKoAS.yv9KzvP2rQ0O_CUEmplOXJagMBj.dwwX4TS4E72fA
 bbJiqu5ew327_ZOqrJc1snoIO55.bfMZtRR_49Je9RH0etX4SkhUk8VGpNVJa9vhE_dD2BAQZKeX
 w.SZEGC_TinHEoyTmYUlnD9fLag.BcHpcSVE3L1hvosEfg_z.rBXtCM0uBj0PQ3Fc3DTOl9zEvFo
 MBTBxr6KxUdN5Rvu4gLbFVbcYXH1ttWHNTaNwgX._xpTZCFp8dEgm5MBJ6fXDvSBxc56UluGPIot
 bYk_aL6ahyA79SAxrzo83wtJYePskfA4CdEGSpPBP1YRMNYsZBczH94ss1JmdMZvIFTeG2yHq09L
 DxA8wiE.DVog7rjew9OeWMaeZ9N8ztNU5LWhDkhq5LFLd5rG7uI2xn.cOtuUL2giBLWT0hXvSyEo
 OiexX_PnGIteacKOpGLHf86XHJCni1rq5uor9hvS6VqCJhfCntl52Eh5AM5QtFv2DbzcsM8picnl
 vWjzqh4FL8kc3AROtGT3Y7e5nyv3tF4XL9zDdLKzrAzgfEAsiN.bMOx_8UHKupdp8efM7eX7.EFq
 sXrKnujeCzY.WtLp.VE9ssmQieQjoUYl5.bvkzMlUd.w7s.aeKCcVo33IdE6gNf849pLoaCFsbVs
 RmG4Oc_eiSXT2Cc4oGWIcUTWRow9w.WQZ6l.o9J0VWFN_Eunw0ACS_f9LKzyzVd2Ulco_qZ.RZCw
 rf4VjY9JZylRjtDs2Ee_Z6R796fLIfRJZtszwPec1LmCxfB2ew.n90q7VC1RaKc5ieM_rbxicijI
 fhv_uSCd8lKWK4cxcjirSgaQz4RQByfnNe3NcmK9fcD7lX685E8isynXU1feazRGOFjSudIcAQLV
 rdHfRTKbcVFostMS443oIIU32kYin4nZ18g_VbdvzHy.SxM29nGOxhJO6TQ6uBmLViOUhl72kBv5
 FQ0JG32UnQpx6pAj0QOYTl9f4jxZHiQBNN85qYWlUfsC4XhjYQDuKeIEMmC2AxDahpKVIJIcvg.7
 19QPWSmC_uXT7bipZTtogl2YCCDG90GuKqAoKO4.LR7tVix_Sf_C4ltLVZZiL..B6WsnUOcVCbdx
 slVaoFOwZsIlsW9S__vOAK0ZKKfJM1VuZhFK5utLwd6TFNjh1EWNlTJhQ4hZ0rmAxhL3oI9ZKoeH
 GkaRxypg5wl_cA3tUMzA4S7pvlglx5s7L3S4pMwNsyUbgLe1AxvzDCP7hE6zAsWH6746e1OG4iny
 6ImLlr6jrq61YbBBusZpJJEqbKRhKrKWuzgOIN_CrIeOs80l1i4wlOGnyZHnoqS_lQ.wXBqeN3gZ
 y_S8tQ_xPWVVAK789hlf9kwGnX64L19zvDFzEdNQKhX_yuKTjnqkz00z2j5OWIsM0HWdjrP7ypr_
 XiT17Hu7ExnDK7On_61Reua.BugchcnsbwUU2MKz2pKRiq.JtxDZKn7cVI2Zhlbs803bCHc3eqt5
 PwmEQ769DxyNRFkgHQ1w3e.rkW8IPEBerbufw.ZQvGdJf2sG.IjMKZeOQQCNsSGGY3R.RKns7d2T
 h9dsG8nTrPDRTQ1ZgWrJKXo34off16nn.nk7r_1_hA.rNWJlk9DO..gOCNtG5ddKljcUzqbawXYj
 uLNa6gZwpy5jQyP83GBd9plfQjYlpwnlshNhM0Fmwb1vnkQ_PLMypNyBMenHWVK98Lx6euKgGIgP
 qmuu4nYcDKr2j6NLILVF5XhUwf3o.UEOS0zi1mPOyftUraTQdv.8xKa8Eb1AYf1mvjkqw3NGO_Bo
 D6.9ksjbSjRhVYaVoxcmqITub.Jj5LppgVCYYLFVVE64ew_zg0mGzTigNcMD7a4cyTKBR1aix7Gj
 srIC2.vXu9Gm4zjhj.LxzdhELXPGsMlH60ZvmlpmIMRQWaDe0u4SkJekmThPziV2kxXtICyiJGL1
 xgTZPjIRKV1DOrLKUTX8RrBSlT0Yu9jvx5cs3OO.k58G5m0GSAeLKxXfnRRWLjH4W6mzxzDAigcZ
 w0oEprZmmv46vEeioCgW6IhwLCuE_dwc00TCwuCjHLZ.SmfjtqPryLG.b.jUydltHyIlQE.5rrzs
 g4l1jtHYeRMCTPutvY848.8Le4Reuy1_GbZULA.nBSr1HK2HV1SNcHseU.ZQ3hCBZIhRDwUs-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Jan 2023 23:41:41 +0000
Received: by hermes--production-bf1-5458f64d4-kq8fm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cb332b93730a1de6f88cbb7105cbe820;
          Sun, 08 Jan 2023 23:41:40 +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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
From: Mark Millard 
In-Reply-To: <3s6qq325-4091-s554-rqr3-3q5661ro55p8@yvfgf.mnoonqbm.arg>
Date: Sun, 8 Jan 2023 15:41:27 -0800
Cc: =?utf-8?Q?Klaus_K=C3=BCchemann?= ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AA82D68-B571-4D88-831E-605A83B48A04@yahoo.com>
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
 
 <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
 <3s6qq325-4091-s554-rqr3-3q5661ro55p8@yvfgf.mnoonqbm.arg>
To: "Bjoern A. Zeeb" 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Nqtrl356Cz3pR9
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 8, 2023, at 15:27, Bjoern A. Zeeb =
 wrote:

> On Sun, 8 Jan 2023, Klaus K=C3=BCchemann wrote:
>=20
>> What wasn=E2=80=99t clear for me is whether crashes like those from =
Bj=C3=B6rn Zeeb have any relation to firmware/u-boot/eeprom,
>> but reading closer I guess he=E2=80=99s probably using an unsupported =
bootloader that could cause problems,
>=20
> I wouldn't call it "unsupported" just "non-default" but I am also on =
an RPi3B+ and not on a 4.

Just an FYI . . .

All the following need the patching in order to use
sufficiently modern RPi* firmware (and the involved
live Device Trees). I only list what I've tested
(what I've access to):

"C0T" 8 GiByte Rev1.5 RPi4B
"B0T" 8 GiByte Rev1.4 and 4 GiByte Rev1.1 RPI4Bs
RPi3B
RPi2B v1.2
RPi2B v1.1 (so: armv7)

I expect that the issue is far more general then that.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jan  9 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 4NqxQ45Z7Hz2pGDC
	for ; Mon,  9 Jan 2023 01:37:16 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 4NqxQ43Wkgz3xR7
	for ; Mon,  9 Jan 2023 01:37:16 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62a.google.com with SMTP id ss4so9326847ejb.11
        for ; Sun, 08 Jan 2023 17:37:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=nZEUiMPs+qzKk3S0yTq19g4hjOR8wVAoWsYlxik0A3w=;
        b=WxAVgrxucPSgogusCwGI2Yv2CpJjwM9UGuNUi7SK0K7rhVKICy3sCEi5jw3oav1XL+
         JHMLic3eWJd+bEq1BZc8S8HB9uYouWsxigzEW/C+DJInA0a13lGqRbrVZqrogXN8HEFx
         J+Xgdair0foRSL0zFeKG/zDNI9XxU1PNT/VmEtxIi+adehGLPGWuXiw/jyMkqjYlIcmt
         Ml7Bnq9mdhEVqFC2gBRbfB6S7Wab4pqQlMiq3tA6Eyvg2s47KDTAkCdN8roVaGwsKZYa
         q2VnHBpnIecgz0j39fEo2Mbizhbmg03VcO+VImmmu53CVZvsVaiilOO2aQDKLMpjxC9Y
         2Aqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=nZEUiMPs+qzKk3S0yTq19g4hjOR8wVAoWsYlxik0A3w=;
        b=34Lc+J6jA76tr9ZwkXrEd7Tu4YtFQGrQslnu7rT3ZvTBZBzBOyp9iFXpcTKrHEof/T
         Wg3VfZPc0UYf+c5AHOnsSPSe47VkL55qS0rLriDJXYqmFouY87b02Th1zARp8rIIaZwL
         dSx2UGM+8rHs68dNBTx4BukZWseSlHt/oypoP4xKiFyVtiyaf5zxMr8Da+AYAsL21a3S
         sdjzDzs9MdQ/PLY1FLGTs8ldd9+/kESis54cPXRmS0dETIFhIMKgfizCgz4wQXhW/puJ
         3XT0XudJqRkULbwJXinpBPPtWgKL0T5GtPQQS5rC/NTBVD8vHjnOrB/aDdbiMQ5fOmNU
         WRLA==
X-Gm-Message-State: AFqh2kpk3l/NeIW8+xknsBgEWhSElyXaCetkQ6/mDvBYMkxjEM9c3atO
	yJyztKP7F2VwfzKlEtRUNR8=
X-Google-Smtp-Source: AMrXdXvUh/krfJ+s8+kXpwiP+hI/hGNd29awzqB4qJN+Fn9hLhsvoJbve6q5PJCFPZ7Bsr5EQnUxNA==
X-Received: by 2002:a17:906:9613:b0:84d:465f:d2f9 with SMTP id s19-20020a170906961300b0084d465fd2f9mr1997264ejx.67.1673228234709;
        Sun, 08 Jan 2023 17:37:14 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-188-092.46.114.pool.telefonica.de. [46.114.188.92])
        by smtp.googlemail.com with ESMTPSA id gc20-20020a1709072b1400b007c09da0d773sm3131989ejc.100.2023.01.08.17.37.13
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 08 Jan 2023 17:37:13 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi*
 firmware
Date: Mon, 9 Jan 2023 02:37:02 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
 
 <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
 <3s6qq325-4091-s554-rqr3-3q5661ro55p8@yvfgf.mnoonqbm.arg>
To: "Bjoern A. Zeeb" ,
 Mark Millard ,
 freebsd-arm@freebsd.org
In-Reply-To: <3s6qq325-4091-s554-rqr3-3q5661ro55p8@yvfgf.mnoonqbm.arg>
Message-Id: 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NqxQ43Wkgz3xR7
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> Am 09.01.2023 um 00:27 schrieb Bjoern A. Zeeb =
:
>=20
> On Sun, 8 Jan 2023, Klaus K=C3=BCchemann wrote:
>=20
>> What wasn=E2=80=99t clear for me is whether crashes like those from =
Bj=C3=B6rn Zeeb have any relation to firmware/u-boot/eeprom,
>> but reading closer I guess he=E2=80=99s probably using an unsupported =
bootloader that could cause problems,
>=20
> I wouldn't call it "unsupported" just "non-default" but I am also on =
an RPi3B+ and not on a 4.
>=20
> --=20
> Bjoern A. Zeeb                                                     =
r15:7


In=20
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268630=20
we  fixed a boot issue on the 3b+ by a backup of older firmware I =
offered for download.
No clue if it could also help for your boot issue and whether it=E2=80=99s=
 relevant for edk II,=20
perhaps worth a try.

Regards

K.=20

From nobody Mon Jan  9 07:13:50 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 4Nr4tY0HP5z2p1Zd;
	Mon,  9 Jan 2023 07:13:57 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from HK2P15301CU002-vft-obe.outbound.protection.outlook.com (mail-eastasiaazon11020026.outbound.protection.outlook.com [52.101.128.26])
	(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 4Nr4tW4GsXz4Kxy;
	Mon,  9 Jan 2023 07:13:55 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=microsoft.com header.s=selector2 header.b="ZiPPN0/e";
	spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.26 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com;
	dmarc=pass (policy=reject) header.from=microsoft.com;
	arc=pass ("microsoft.com:s=arcselector9901:i=1")
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=gKNlbeF/ugwOxwr8+U8jNxpeNAfRc7JqzDxakl4/80Np4U9hUySDLZ1/hd9wC+YofpDe5+eQKijgBoRwr21AeyZXOooH36IXY2IV8vq+G4el+f+5e7oZ9o1tW6S7Y2lJUy9H7QT8QboJtNYfE/G1lUBJouoYEx3Cly5jjFB5cw1jSnMqGCAJe8PyVzB0iB5tOj3iGVNStrUfY9bACAMZ5gYxG0th0bEFTdZF9WL1CYeAz42WZlTZ9HVlIOuWGzI+qb/xcxpB/KVyeFF2HxH2h5KTZOBd3apw1IpMe80+4ksDv108k9O+kU/T0ekcU5CrDBRJAVMAL2ZBTa6n34Qa+Q==
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=6ZWm7ElTEGxO6vzKr4R85Nr0OMsGd6apeiuJGZtjtI4=;
 b=cYr0txk9O4pRDFXbEMjNAugP09/2HgLxGqeVxlrPixNFOD4fxJOhHEttJjRG/Mm5leFOCYeOYTvqKLwoON3n+kL5GL/rcSzE+XtDYahYPc8QG6BG9N/BXOJ/Wmxmm3wN7qFWMEd3J9F7mOD8QoNH9i+7+nsBN4aPucSkALdXgL60F2FF00UpME+veDljQSRl+TkgLT8LDq7vLFFICsU18GIlyLJ0SaVapUi9nunxvH/FuNNdm2UtmAVBFCXqc8LY/6t2fEjwldHc0xGidKFhFmcsnRxNCdoBNYdv7o6qu/T0LsowymCzioMmvSHcuAK8pdXZ1usE3RrTREqQVjmprQ==
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=6ZWm7ElTEGxO6vzKr4R85Nr0OMsGd6apeiuJGZtjtI4=;
 b=ZiPPN0/ek+g+VlBZdsMzDhKLFpzan5+ioKmAan7xMvOfBDXghyCAaadNg6wJRS1xK8yAkA0vJyFv/U9rRcpf6bYB03t3kWJDbDrFyzUhsgzrI2Y+VMiakw//fP0a1/o7sZlsiO2kL9toAzMVR74/tkclIZSlaKtowR1jdtknOKI=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by PSAP153MB0422.APCP153.PROD.OUTLOOK.COM (2603:1096:301:38::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6023.3; Mon, 9 Jan
 2023 07:13:50 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290%5]) with mapi id 15.20.6023.003; Mon, 9 Jan 2023
 07:13:50 +0000
From: Souradeep Chakrabarti 
To: "freebsd-arm@FreeBSD.org" , Li-Wen Hsu
	, Warner Losh ,
	"freebsd-hackers@FreeBSD.org" 
CC: Wei Hu 
Subject: RE: MSI  CPU affinity for ARM64
Thread-Topic: MSI  CPU affinity for ARM64
Thread-Index: Adkio8F3khe3N5kdTvWiOLlk332lhABVhZLg
Date: Mon, 9 Jan 2023 07:13:50 +0000
Message-ID:
 
References:
 
In-Reply-To:
 
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=db4a32ba-f893-40d3-8ebf-516da4c3f48c;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-01-07T14:23:14Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PSAP153MB0536:EE_|PSAP153MB0422:EE_
x-ms-office365-filtering-correlation-id: 61d64e9d-209b-45f2-3264-08daf2110ed1
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 UrXKFAxpmS0fC4BKJVaEXnJ6k8q54/Qp/yj68PxKKtmQExaiLwHHgbslvwYc9XkLfWT9NuESJPjd3/dhjuOFZMwsZUNZoCzhtXmRj+SrAzpMwslxULXHsLsXb6Dx6g61hNIsKSnd+SZxr5krX7TMVwiITi1XzPmF2V5eBD98bYq88gitkWvdAtWqPqzGzpZ39tIPTaOZNH+9e6eLNJGopuSLZWm8IEnEuUJKPQBIHgmw51LliegWtTCQvsKlcpsMHrg7NTZ9rPLQRQJrUZr6WKvenBaK8iGomZjQYbZEKNDhkrt+nS1wuBlrnasfcjGETvB83gBiV+fnaCLgTpZbzaIDaHAC9I3EVRjmRxdAazgV6OBaHOPTErpQ4uTHS0T8dca094XhaFTinhKzaUAotYrVDerlZntJCvA9W1TSK233GKybIw6Ittw2fnzSzFIAoFgonbmMSvtFyCEjtYp2ugEo7s8eOb0UktDEYt5Mfuu6Y15qXV3576LSdDEypvNAZ2TRfhR+iwcQTaJ0EJUC5Tz3HyzN7zu/MRLgdDsgNQ+2QtOSLI0LFVn09ZL8ADtC6BTfhANIWXTlGTU1lkscjY/uog54y+xf3qTim0RabZ9SRL8R5H84QeNfERFUje7diyHTQaobnkJUdAIRfTCALdIhVSR1d9VqZVr9rpG0BetTu/wenw4RqKzlMnjndC0QBD2B0c7vRTbczQy9jCWMhZp+fJLDI+DWMbKf4ElBsHMM+DV9c+tKvpXxPfwbT/WL
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(451199015)(86362001)(110136005)(41300700001)(10290500003)(83380400001)(66446008)(76116006)(66946007)(66476007)(8676002)(4326008)(64756008)(66556008)(82950400001)(82960400001)(38100700002)(122000001)(33656002)(38070700005)(26005)(7696005)(6506007)(53546011)(107886003)(186003)(71200400001)(478600001)(2906002)(8936002)(316002)(52536014)(5660300002)(55016003)(8990500004)(9686003)(4744005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?We1+kX8aN2xXKbjil0Tsf7lAyFDbv9xQUq7xPo5QNF7e6E12xZTp6gMUDodB?=
 =?us-ascii?Q?pmA8Gr0lrsNGo821mIMfqw6/ZtAfNQBP6h2nwWcfGnsRnJmxCqhSUmV72bPH?=
 =?us-ascii?Q?ojpqx2AQzp20mtKHs6cshUI0iUoYUbVkAvqz/03nBHiUx2LppxtlOSzOoMsV?=
 =?us-ascii?Q?aSTectAw1pSRYL33cYx9JtlMied6MJec6S+WRT/lEYf6csBtzpNNz7+TRQIK?=
 =?us-ascii?Q?gE/3f/RELwlnwxtRtGCtixyS+bUt7S1C69lcFjvBKEf1DXVacyeDiC+IkQXL?=
 =?us-ascii?Q?/gnk89YOPI8tVv7Fi3D0JItfe5+IPcK+WQknCUe9nu8rO1Wf8uJ7tDvJtVDA?=
 =?us-ascii?Q?mY4a8eLgyEQEvAIX54Z78r9wbNYIF81w7UbDic3SkvCcg6QVQxtI4HcQvAdU?=
 =?us-ascii?Q?SfBDJZcgCaf3Fjv6pFFTrLQIJ866z4ZHh6qU7R77PB+w/j8I/xm1QXFNaUSk?=
 =?us-ascii?Q?sSrmLyKsLU8fVA4b00l8RYAUbE9yZk4y9MaZKliFbMWPfD1YgFzcAZ7X1Fsi?=
 =?us-ascii?Q?6VDzxa8Y+keoAiPbXDear39oEGBAzG7SVuzrtIZ/7I2HCyKGbf1B8/FPkM//?=
 =?us-ascii?Q?jccgy93lNe8nnlKhzuEsWmc4MCsbpv4KfuqARic9Akenhip/3qLml46ncw7Z?=
 =?us-ascii?Q?b2dtoXFKJoQ+IEVIK7F1GE6BvlhrYpnZH8jjcQWW3AEOo4D3ZVIEZJ6VZQaL?=
 =?us-ascii?Q?ygX4P1GxTuxq/a0eGyWdOh3Vyv1xhB/qkKq0TUA8Wybjnm9i7rSV1usXhLjl?=
 =?us-ascii?Q?smBTU9kQuzkLkNkVMrzG1/OYGTCbo7QScjBX127P63yxSW6XJPb7mtxusk3G?=
 =?us-ascii?Q?LHbFMGJt0HVxxPg1U/SsIEo6zbSSZjQks8aWa0ytX7niAFUnqrLa1asdCr51?=
 =?us-ascii?Q?RD8/qc1TSbhUpuKrKx/gcuyMo4bGwW2XZVUq23y6LBs8590VxsueoAa84ItW?=
 =?us-ascii?Q?GQf3mJTgcKHJHVm1M2IdcLv7XqSqY4SuqWw3f3WQ1/J/uNIHPVKwQP1XLKQQ?=
 =?us-ascii?Q?AwOOODKN40FHOoxM3CwqvzZs9OMhZu9RqQNoH5i4ARiE+izTMOGQDRQfrQYz?=
 =?us-ascii?Q?gpUGfmxojGLtXT4URYtBEnrCRcrr2wAKQ8WFQhnRO5HCLy6hnmGodBX8AXrz?=
 =?us-ascii?Q?FdWWOHd74Zciqom4Fx6rYWDpv96IIR1+VM3986B67aBRl5MR/jHu6cl4yrET?=
 =?us-ascii?Q?Vpxow5jZv+I89PP1iHcbxGkL+Fkq2lKerlqHEvCEBMdA6kyxbejdokeV2EbK?=
 =?us-ascii?Q?4g7231cGaeiu8+UtJjAckYEHNnx+LEYrSu8jbgr2iViapZAPwJQHUkDCX3H5?=
 =?us-ascii?Q?Z8A8x4yno0QELwM5dnJwRmnwmBmRZJNZGL58v69kGkz1pzEYFP8ReugQiPJA?=
 =?us-ascii?Q?fYVQxTlC/0l4k3wWyHb2Tw+Sk4D34PG8q1qsWvap1dxZCZ9E1Q3Rp5cl181r?=
 =?us-ascii?Q?zn1t9D7FlVHyA1T+EohqIHYeTKIx89QK8pSpPwwgUDdzWnua/Awf6JhMlnj/?=
 =?us-ascii?Q?JvMCIUxVNcjUlMNIB9mBkznt6CBivb6YmkFR?=
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 61d64e9d-209b-45f2-3264-08daf2110ed1
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2023 07:13:50.3146
 (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: 2Pc+nIMOBkITKBXL3q+ylIYT0cI0D0TJ4OYXW6XrLG68B9VPF0QrTtpyZIc+UKmya6LQlU7hXZy2tpEtE9LlGzWwVlMctRJCkb2ZAYdbwFY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0422
X-Spamd-Result: default: False [-10.00 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+];
	DWL_DNSWL_MED(-2.00)[microsoft.com:dkim];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	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];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	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.26:from];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[5];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-Rspamd-Queue-Id: 4Nr4tW4GsXz4Kxy
X-Spamd-Bar: ---------
X-ThisMailContainsUnwantedMimeParts: N




> -----Original Message-----
> From: Souradeep Chakrabarti
> Sent: Saturday, January 7, 2023 8:24 PM
> To: freebsd-arm@FreeBSD.org; Li-Wen Hsu 
> Cc: Wei Hu 
> Subject: MSI CPU affinity for ARM64
>=20
> Hi,
> I am trying to understand how we can find the target CPU for  MSI in ARM6=
4.
> When looking at gic_v3 code I can see following:
> gic_v3_bind_intr( ) does mapping to next incremental CPU but gic_v3_dist_=
init( )
> does setup boot cpu as the target CPU for MSI interrupts.
>=20
> If I need to find the CPU bound with a particular MSI interrupt, how we c=
an do that?
>=20
> Also is there a way get the the CPU id from the CPU affinity in ARM?
>=20
> Thanks & Regards,
> Souradeep
[Souradeep]=20
Adding FreeBSD Hackers on the mail thread.

From nobody Mon Jan  9 08:15: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 4Nr6FV3vXFz2p7dK
	for ; Mon,  9 Jan 2023 08:15:26 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 4Nr6FV0bs9z4QCl;
	Mon,  9 Jan 2023 08:15:26 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62d.google.com with SMTP id gh17so18082240ejb.6;
        Mon, 09 Jan 2023 00:15:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Vmrqb5e7Sindjr/oT+9TVODdBpQRLe5WWGMz4Se9vHQ=;
        b=XQGsWPwmX3RHdFb0V/vaVVdZFlU9mKLUpG9rsFAgtQJMKwy/32/3zkG4GKieV6rzfw
         ofNkrAtQ/SyqRzlpMdMeaU0Z3rYIl4L848IERYo5141GEdPsMilByXFD1qxPwZ8HBDsR
         xpJLMHKcZU0pl0d8JqcviIE9eAPAyrusLmuMLnM9tF/3l+zEWbCeVadK9IXn5PnI4E2e
         JD3Q0JndHhGG3PDbQMQOJQHuXxBqgsz3dgucYC8cfaDTJpdAEgWzWljRZORRD0OihGrx
         sGt0Vj51d3DY1sYoRNWmu132nsna0k5xjqu49AVOvt0Njnf38cMGb7tzXPd70tx2ptoD
         tXvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=Vmrqb5e7Sindjr/oT+9TVODdBpQRLe5WWGMz4Se9vHQ=;
        b=asHibdfYkCNVp3rOpY84pNPJyOlKb77QdPoizwPOI7gTitNVsFpoKzLTXuJLvpm0rQ
         4p0XzKTQP6P2hxSni/6h9avIQJCEa7EBcuuq2+65RjYeeFzqiZKJ6ZkzjTsg22APuHSn
         Me0JcZ20j7LyyPo8+jO/PZhoV0dhTzYbHtZgIwQRSyjD51jlFV0LrfV5j8u7EtGcD5aD
         lh5nt7BEpbXS96G4PsOjlXsugBJ+AMZaYpYeysdjsbNQkQzXAVJFgyh/eWExnpsfJzs5
         clFNXnxo4XzPalhlXyNpDfS1nz5H9Ko5/qUU8eZO31xZRtshvTod52nm4PVA9gbBZdqK
         y6PA==
X-Gm-Message-State: AFqh2kp5Q6x4C91CAI+jXDLYob+tyHAKXb6Q1MMYU1WOn0ceYo5XolgU
	qXVWzyXxfi37/xPJjZlT/QueJ76uoy8=
X-Google-Smtp-Source: AMrXdXusKlqYfAKaTbn5ANH1OND1YvUdxXdEL8I0katQUKwaA3O6MQlAM77cm84GTHisFTzXYTCBBw==
X-Received: by 2002:a17:907:7676:b0:7c1:5b5e:4d86 with SMTP id kk22-20020a170907767600b007c15b5e4d86mr55474600ejc.36.1673252123759;
        Mon, 09 Jan 2023 00:15:23 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-188-092.46.114.pool.telefonica.de. [46.114.188.92])
        by smtp.googlemail.com with ESMTPSA id l6-20020a170906078600b0084d381d0528sm2206811ejc.180.2023.01.09.00.15.22
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 09 Jan 2023 00:15:23 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Mon, 9 Jan 2023 09:15:11 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
To: Mitchell Horne ,
 freebsd-arm@freebsd.org
In-Reply-To: 
Message-Id: <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Nr6FV0bs9z4QCl
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Hi Mitchell ,

`ve tested D37981 on a Pi4b,=20
sorry but it had no effect,
not on the booted machine and not when intentionally provoked crashing =
in early boot up( no changed behavior in reset) .

I never see :
<>
(except, of course when entering directly by : sysctl debug.kdb.enter=3D1)=


=46rom the booted system( so you see that the new tunable is compiled =
in) :
=E2=80=94
root@:~ # sysctl debug.ddb.full_reboot=3D1
debug.ddb.full_reboot: 1 -> 1
root@:~ # root@:~ # sysctl debug.kdb.panic=3D1
=E2=80=A6.
KDB: enter: panic
[ thread pid 1056 tid 100128 ]
Stopped at      kdb_enter+0x44: undefined       f900827f
db>=20
--

root@:~ # sysctl debug.ddb.full_reboot=3D0
debug.ddb.full_reboot: 1 -> 0
root@:~ # sysctl debug.kdb.panic=3D1
...
KDB: enter: panic
[ thread pid 1057 tid 100092 ]
Stopped at      kdb_enter+0x44: undefined       f900827f
db>=20
=E2=80=94


but perhaps I have overlooked something

Regards

K.



> Am 08.01.2023 um 19:32 schrieb Mitchell Horne :
>=20
> =E2=80=A6=E2=80=A6.
>=20
> The reason for the difference in behaviour here is that the ddb reset =
command doesn't execute the full list of registered shutdown handlers, =
it just calls cpu_reset() directly. For whatever reason your combination =
of RPI hw+fw doesn't support the PSCI shutdown interface, so cpu_reset() =
fails. I am guessing that it is the bcm2835_watchdog driver that handles =
the normal reboot.
>=20
> I think it should be just fine to execute such handlers from ddb =
reset, so you can try my patch: https://reviews.freebsd.org/D37981
>=20
> Cheers,
> Mitchell
>=20


From nobody Mon Jan  9 11:44:14 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 4NrBtc2Mmyz2qpj4
	for ; Mon,  9 Jan 2023 11:44:24 +0000 (UTC)
	(envelope-from bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz)
Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NrBtZ6Y4rz3R41
	for ; Mon,  9 Jan 2023 11:44:22 +0000 (UTC)
	(envelope-from bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz)
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b=wVpgc5sE;
	dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=ft0WRwPP;
	spf=pass (mx1.freebsd.org: domain of "bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz" designates 103.2.142.68 as permitted sender) smtp.mailfrom="bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz";
	dmarc=pass (policy=none) header.from=fubar.geek.nz
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=smtpservice.net; s=mgy720.a1-4.dyn; x=1673265562; h=Feedback-ID:
	X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender:
	List-Unsubscribe; bh=3wMXBYp0yx6mW70cKcceRhjAkMgNj/MoX5gflWY8K+w=; b=wVpgc5sE
	wKvXiMa30qTj/o/yFncH4UvZ7JPBp+hE0dIOUOfbEI7xkU13SrWI/PExnwgsrQ9UBb1Al18gyQ3al
	4ytqQGMACpZcOYjGyR/dIFmPdBeFyCPpKXn5uKJcYrOLWLYjx9+WPBLcvlD9SgiRFOUFaTDt78qS5
	nKdpdwgCXxY8cBCHLZbgRHLHhB3HQJpuGZoCOY0DSD9aBYcxGVix7EL4AailA5Z7izRZiRDUX3nOg
	iN8eSw+VLrctP/Zb08BoB3WmnM83cNkajzlU3GcyLnucXQOKPpH0q1vTAO0kGn0+j9uVgZdYvpQi7
	EIpv7hTyo5525UJgQsZrVce3tw==;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz;
 i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1673264662; h=from : subject
 : to : message-id : date;
 bh=3wMXBYp0yx6mW70cKcceRhjAkMgNj/MoX5gflWY8K+w=;
 b=ft0WRwPPn/c5eFAu9sSBwMIPRBKm0w3DFqeY4+xXNG7gMVYzQFRbdt2t16xw1QWhFESGl
 E3Uk/2FtkPmS+P18LbaxVgQyeExUhgH3KDDZclj4RrBot0vZqEIeXg7Aal4qF099OpxxFuR
 fBdFte6pxjLPU7oyWWmIQrx2CC8szokcmv/IRZeqrl9xScxAUFMx3nqMuZ9d5HSqWxp+jDN
 BhA0OaYtbCSjV6v3Jmvs+OGlZTBqG/Btc1AbL90316QMD/vBYogDNxMikWdT32faCMiff+E
 aNBpLMLHjeiN4PafejzmkfASPvwSV47TeGHphdL/5TOnMx9rRvu88wF1Sr6w==
Received: from [10.139.162.187] (helo=SmtpCorp) by smtpcorp.com with esmtpsa
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.94.2-S2G) (envelope-from )
 id 1pEqZe-qt4B5D-Sa; Mon, 09 Jan 2023 11:44:18 +0000
Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz)
 by smtpcorp.com with esmtpsa
 (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96-S2G) (envelope-from )
 id 1pEqZe-4XaBIa-29; Mon, 09 Jan 2023 11:44:18 +0000
Received: from smtpclient.apple
 (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235])
 by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 55FA62AFB8;
 Mon,  9 Jan 2023 11:44:15 +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 \(3696.120.41.1.1\))
Subject: Re: MSI  CPU affinity for ARM64
From: Andrew Turner 
In-Reply-To: 
Date: Mon, 9 Jan 2023 11:44:14 +0000
Cc: "freebsd-arm@FreeBSD.org" ,
 Li-Wen Hsu , Wei Hu 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Souradeep Chakrabarti 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Smtpcorp-Track: 1pEqZ-4baUma29.Iy4TtA8uS7cVG
Feedback-ID: 790814m:790814amQcrys:790814slHL3ZvFbV
X-Report-Abuse: Please forward a copy of this message, including all headers,
 to 
X-Spamd-Result: default: False [-3.90 / 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)[fubar.geek.nz,none];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz];
	RCVD_IN_DNSWL_MED(-0.20)[103.2.142.68:from];
	R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22];
	R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=s790814];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_DKIM_PERMFAIL(0.00)[smtpservice.net:s=mgy720.a1-4.dyn];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_MIXED(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.5is6c55d30=7ivc0wbbqwow=y0om3pasoh@em790814.fubar.geek.nz];
	RCVD_COUNT_THREE(0.00)[4];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[smtpservice.net:~,fubar.geek.nz:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[103.2.142.68:from];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NrBtZ6Y4rz3R41
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hello Souradeep,

In what driver do you need to query the CPU affinity? In the GICv3 =
driver you can read the set of CPUs from isrc->isrc_cpu. In other =
drivers it appears to be more difficult.

Andrew

> On 7 Jan 2023, at 14:53, Souradeep Chakrabarti =
 wrote:
>=20
> Hi,
> I am trying to understand how we can find the target CPU for  MSI in =
ARM64.
> When looking at gic_v3 code I can see following:
> gic_v3_bind_intr( ) does mapping to next incremental CPU but =
gic_v3_dist_init( ) does setup boot cpu
> as the target CPU for MSI interrupts.
>=20
> If I need to find the CPU bound with a particular MSI interrupt, how =
we can do that?
>=20
> Also is there a way get the the CPU id from the CPU affinity in ARM?
>=20
> Thanks & Regards,=20
> Souradeep
>=20


From nobody Mon Jan  9 15:24: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 4NrHmB1LvMz2sJVN
	for ; Mon,  9 Jan 2023 15:24:10 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Received: from HK2P15301CU002-vft-obe.outbound.protection.outlook.com (mail-eastasiaazon11020021.outbound.protection.outlook.com [52.101.128.21])
	(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 4NrHm94q3pz3wC4;
	Mon,  9 Jan 2023 15:24:09 +0000 (UTC)
	(envelope-from schakrabarti@microsoft.com)
Authentication-Results: mx1.freebsd.org;
	none
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ioxuZacrbdr+Mk6nTiyTqLHKRJrUbGBg6flRBEZYjS8w100hw/7o2/aDtEyoo6XbwsDLmaO7bXfZnqr2q1uw3qkv8Km7wwRqNNOk5qXYsR5upBbZftxSgYUK29rs74aDgN711973Pf+aYReW/P0tpaW5u1n0MKGMWYz3LlBn50Yc/Vc9mAZY+fERUe1EK2kfj8/0hei2YwpAZW2yjQwjRxpV0ixQSegsPCnyVDEdWQCC7QSePMiwTPwai1HiBW2IvWUod3C0qq0kmri8tVnlO+j0LMfFi0ym/LTi85pLcgk0BPViVNuwTvF5+EdLcU4PZV1Y9m2DGHL0Az01TzkYJw==
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=ELDWDrXVZCuEIMRggfUw4Yjz39PrrhRWk3rM3fo9aTQ=;
 b=dHiPHM8aVAXAr1QacxbcIHp2c0knd/zzZq4VcseLPCXV6AGzGMb4Ffxq+2HjQuDUno3GHZOHX6zNN5Q+7CNxyR4ZP1hdWyJxqdS/bbS4hvHe5Kolar8kRwxWvxLnCtCDPosRrUfjUJNIOyosg4ubxQ/fzElKkSk3JzUlZ+cGgW0MiYLAUQPJGz1V6ltWBTMfHar+F6zx//I9DZb/F0bPXgyvhYPm2Fx6XkSFWVQ0lShntTLujAv8bD/Xd9F8gkBVAwMH5HD/nchM2vPoNcek7q23RADGZWWFZyc1CT8djeulyOfKUgqLk4Zqgbw5/ce+AKM+ur2ij+NovcyroyQpoQ==
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=ELDWDrXVZCuEIMRggfUw4Yjz39PrrhRWk3rM3fo9aTQ=;
 b=R6gvU4CU4BwdMme0brfHqezPybrP1QVVI6japFgbC0rD9wgYwcoHIHdO/Lgm5/5wKjf0LKOj6F11FZi+3iwQFprX5QGE92OR1bgvt0ZrivjHfvFrPJp5o9zvxbzTzcnRh1VtKO9RaqB5FuO7+WBDLrjctli3LF6ZoDH6LLNQp8E=
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14)
 by TYZP153MB0413.APCP153.PROD.OUTLOOK.COM (2603:1096:400:2e::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6023.3; Mon, 9 Jan
 2023 15:24:04 +0000
Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
 ([fe80::9cbf:40b9:40ce:290%5]) with mapi id 15.20.6023.003; Mon, 9 Jan 2023
 15:24:04 +0000
From: Souradeep Chakrabarti 
To: Andrew Turner 
CC: "freebsd-arm@FreeBSD.org" , Li-Wen Hsu
	, Wei Hu 
Subject: RE: [EXTERNAL] Re: MSI  CPU affinity for ARM64
Thread-Topic: [EXTERNAL] Re: MSI  CPU affinity for ARM64
Thread-Index: Adkio8F3khe3N5kdTvWiOLlk332lhABe/DwAAAAgSnA=
Date: Mon, 9 Jan 2023 15:24:03 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
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=e60a41b1-6b9d-4e21-8b05-0163f91ff934;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-01-09T11:47:50Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PSAP153MB0536:EE_|TYZP153MB0413:EE_
x-ms-office365-filtering-correlation-id: aff743d1-11fa-4208-68f1-08daf2558aa6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 ZD1uuMLC6kY8VFjINKUDuQRn4sBW+w+KvBw+yLce5cAs9iZKjxAzswG8tl58tHCjNrYzAxlpW6yjOZvF0BNQTRZbFPEka6VbutCV/sg/efamwoeRL5f9Z+zqBXbwZrhBhvVJr3Brzc1i8CFR9tP/baoLLOkx2PfLqqXEOUSOeWeFx0n8RZ0WtI9j/mTtcD0fetQNQ6yUamMEYqSVUTftmL0WnjfRrGVJICn725VvxJtRzfOhtvV21vAh6vGfLh4W9bVkS1nJn8o0d4PZ4SaowR3iC3366RFiS7067eDPoH+aK90LyoYvbHPet8WEowTly9mpFM+GRWK4ToWz/Erl4s4duqmIXymortCr8Yoa9anrnPjZoAI72PDnis68CdZKscXPhC+FAvsNt/bi1RrKvpaV8KQcOOebCBvuCWq1dpuNgyud71Fa6QKNA+Yc2D/M+ECEMlCZlJMjz/aDTGxodxaWHaJxu5PEc6Iztgbr/a6Xl6u8mlGfBNdtTRM97PrDD+ZCLIuS0LWdJtKd2uwSunfJPD154cizU2tpRX1w8dzq68YOQoDZGTwMLF7yK1Vk34yK+/i9fi1EbBCL5EsmJLcJJ3j7w2YlIroAw9NKhuAhg+3Hju6KYmGIa6QKirfsUA8IgLb2/mf3yzwA4Ku+nx8LB9Dae6lG297MxarwhVISTIBH4FWAiidoIsyw9itxZr/KHzKRvsYzlv82X/ZOzWqHT/jKoj4IkUn2McEr+N5rZHML513toJzPYmNG14VY
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(39860400002)(376002)(346002)(366004)(396003)(451199015)(478600001)(82960400001)(82950400001)(54906003)(86362001)(66476007)(38100700002)(122000001)(66446008)(5660300002)(38070700005)(66946007)(76116006)(4326008)(8676002)(66556008)(64756008)(8936002)(316002)(41300700001)(52536014)(71200400001)(7696005)(8990500004)(83380400001)(33656002)(2906002)(10290500003)(53546011)(6916009)(6506007)(186003)(9686003)(107886003)(55016003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?5uNwK0bJ+c69DBIZCduFAvqhGXS6Ein4BTND2U4bBBVuL3tWQeYppmbCHBrh?=
 =?us-ascii?Q?HZ6zmppW/LYm1ergUwn3d4YDqMPS9xyq1NDz8DwtgIWXYg0RSMvyQ3c0ZOJc?=
 =?us-ascii?Q?jqr5OCfC91HGZdebR4PpPO8ppi8bTotTLnjRFEqbQxCwNTwec0T5pLR3q7Cj?=
 =?us-ascii?Q?wL2MrWH4+LPqphsB4wLn6tn49u0a+OLSCuS1h6s5Ox+ENp4dCNp5ACEL61Al?=
 =?us-ascii?Q?wyio77lefGXQrtwU9DH7pbv0MVreU7j8EZit5T8bTSjNmqN2FoV16bD599qJ?=
 =?us-ascii?Q?96kffTOUUVdbJxljRCGw3uX6/VI1gznPA+mACJ1aWnmtLXc1Sz7vl1XVcQZ8?=
 =?us-ascii?Q?U+nQHQG626VKBEtDaUKTy36Zjf8HuOTbVo+1QmijvvMJDLLLx+PzknPwsCpW?=
 =?us-ascii?Q?BkDpnj5QaxwU3auuA42fbSw/5r3ekcH9q0py5K8sx2cWwcfMdt1uXNNJiMeo?=
 =?us-ascii?Q?usL+KN70hLpMcSOydGRvFMIxz+YywkDIa4Uc4M65iCRjcMULipTAoL8O4wIE?=
 =?us-ascii?Q?4pLRil6K1+ei5PHi37DANWorYsmTtawpVuZJBhS7TiF5XhXPyHAFEpAc0Gxj?=
 =?us-ascii?Q?6My2AP2DHRrg63FNegRuLOxrbFjs9NI8wXn6U5HfHDFmWKOdOALrp2nuGCsT?=
 =?us-ascii?Q?qUPLPyzA8gv7HlQcy9f55XATYVTbkYjXVLpL7WLVhKPFyfmUFBgo0wsEvg1V?=
 =?us-ascii?Q?O2nu1i16dAgPm2BPZGPIfE1Hmmi7IEFz+/5Ju2ZpGOgOiNvgh0dPB/izzzRs?=
 =?us-ascii?Q?wbmvSPrP41sLmaxmKS2fHQqF2dirss8zGYuXT1eSvgfKlHlaO2vF1VjtI9Jp?=
 =?us-ascii?Q?SKfL/dpwRyKxMvP+tsXTarSN6bWPEsth3vJA4HKArhDpHBDHGqsKULbZ/sYe?=
 =?us-ascii?Q?FGJyVeGgQe/A9zOIGEs8PWc8Glwlq6wCgGduioVz+PbhXqqclqkaWkIPaiNk?=
 =?us-ascii?Q?HzUSrCbymGyx9vTzDVQPFrvPnB48agiIxuG3aEIYMnuNdlvuHLAQeHPJDCxV?=
 =?us-ascii?Q?iOq2M5tdVBSmUuO+ewcaJQwY4ha0ShETSFDCN8jQ4LQH7eW3DdqidShJvR57?=
 =?us-ascii?Q?vgnVKYE7mSPpcM8twBlG41h3IBtNxTbyrEhbl3CKxbzbN3cvODXAk03TAKsr?=
 =?us-ascii?Q?sgczTZ4vLxqy7CE8Z+hAp4SQsLLYxp6rCxCHIuGLzfejcZ8Mwo/ERQxWMZTQ?=
 =?us-ascii?Q?VN5ofXYwWH6kmcuKzD/bXP6Qs1aMxG/zMDiYlgXnDBnvCusjv7NNszmQRGy0?=
 =?us-ascii?Q?YZie7NoYdC4ZXC6vic1Sdv4jPYFZB/wEQMW2NgfU3ulESD/mor3Otc9U4cji?=
 =?us-ascii?Q?uWfXVXRapwG0mFkLHpZNAbzctTMtYWN4sFv/b4C1SiuP+P4xph4Wi2X9K7xN?=
 =?us-ascii?Q?WGe6W2iJ+xMvZvK5C4KmE3qI6RwVWzWYtQ3R+4tAPTG5EeXbT9QY1hGn9Kqe?=
 =?us-ascii?Q?2ZND9rQ64OEF/kakC2RWk1o5au28PEm9fmKTKvWMrg0ye86buQimUOC3EeBc?=
 =?us-ascii?Q?8UH8mmzQDYVmPpShN7jm+8NwY89toODS+Q2ODBmQpAG3zgjs0Mx8NPtnW03j?=
 =?us-ascii?Q?3PH3Illx40JMrLJ/btK7eqSehH9u9jJ80t2oe/w6?=
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: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: aff743d1-11fa-4208-68f1-08daf2558aa6
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2023 15:24:03.8493
 (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: JY+e76CpVAt2a2FyJYd/LSLQUWFrJl+HLQWJzKUJYkvZY5SszZS/QPdteydzVACJxTuMktvahaybLXT2BDLphpD7ADHJHgoo8x2mAX0C7Qk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0413
X-Rspamd-Queue-Id: 4NrHm94q3pz3wC4
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N




> -----Original Message-----
> From: Andrew Turner 
> Sent: Monday, January 9, 2023 5:14 PM
> To: Souradeep Chakrabarti 
> Cc: freebsd-arm@FreeBSD.org; Li-Wen Hsu ; Wei Hu
> 
> Subject: [EXTERNAL] Re: MSI CPU affinity for ARM64
>=20
> Hello Souradeep,
>=20
> In what driver do you need to query the CPU affinity? In the GICv3 driver=
 you can
> read the set of CPUs from isrc->isrc_cpu. In other drivers it appears to =
be more
> difficult.
>=20
> Andrew
[Souradeep]=20
I am trying to get the CPU id from vmbus_pcib driver.
I need to find for the MSI interrupt, what is the CPUid.
>=20
> > On 7 Jan 2023, at 14:53, Souradeep Chakrabarti 
> wrote:
> >
> > Hi,
> > I am trying to understand how we can find the target CPU for  MSI in AR=
M64.
> > When looking at gic_v3 code I can see following:
> > gic_v3_bind_intr( ) does mapping to next incremental CPU but
> > gic_v3_dist_init( ) does setup boot cpu as the target CPU for MSI inter=
rupts.
> >
> > If I need to find the CPU bound with a particular MSI interrupt, how we=
 can do
> that?
> >
> > Also is there a way get the the CPU id from the CPU affinity in ARM?
> >
> > Thanks & Regards,
> > Souradeep
> >


From nobody Mon Jan  9 16: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 4NrK2J3QS2z2sQKr
	for ; Mon,  9 Jan 2023 16:21:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30])
	(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 4NrK2J0xfBz435L
	for ; Mon,  9 Jan 2023 16:21: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=1673281285; bh=QDvebZ/mMh96afztYXHm9nfrVqX84MR6QtDG3ohnIB4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ls1e6l/hot3fsarywRc766lyrChr34zY5BNYnB/n1rwYmaPr848N7j/dlMRCzwnTuu2h3iSipOsa5jRZzLTHy9NThyEA9aR20QUu9RRrZXUdotCdgSP0LpAfRuWDqouGMYSi7GIdDZIyK68Y3w20YTIV4D1QMp0okThsYx9aFO1NZnkTqr+ApD7pYfN/cdWdiE/jiHvz3qvuZX4Bs/Ji0fG9jXa+6LGetDldlySIR7lljzYM6Z1aSRo5UTw3ZeYYbvcW1rQPv5gzD8CajjLBg77pVGNsKSb9OB1uVXc40c/nUoSygTBs7y19F3g6EU2wLu0esv0fxY+FiIYy/kgICg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673281285; bh=nvgps5zpwVG+g0g10thHgU5mkFlkJvIUb7mxajZaNT4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tUVVpjisvEftxGjRXG8dCa6T3EvvL1ugmsyo5vQ3nMZkA/IGp+VntWfxCREdEAaNZvLH/JukJfC1ik4UNfe1cTJLbZyg1g2IlnyCzFNEovK7OKf8DZ9+kULZcSdIWrxbAiD/yswjsmnhQk6LifcTyAZK3KHbnjmaB/IapD0CUaMN4QjIl4n04rvalLrPfGeJ6xdw1FkaL4K19R66Qz4vjr04pMv8iXxbRFw40iFJldXY0WyfyMlJXgHy7QGSnLhoufu6rlCSL+8DsTh5GyZxfjkmPboohh0LBqG65zWdcR31gU+G0/2fscro3u2K8dPk1NkBzjHV4eHLdvFE96F94A==
X-YMail-OSG: 1BGzQPUVM1k2Qi9j7vx6MHl2MLP8FLQpM2nxWEoDsy2JImGSvcAi9rChbkoC1F5
 ph.Hfr2u2bHQybFjNj1IbOkOPzqa4UR8L2rBPG3.PMBoXUQS1PVWHsRx7LjNJZZYSJkn1hxUIQL9
 qh8FfiUQlAAL8NFc2Pyn7DgpDkS7fGWQ7ncDpsJDSImX7_4Tnx9Lqt4aBicEwKj7Qzn0.LJOVlxY
 9TkQfCIsPIOT1bfHbsaFRNlsHbv9wYbW1iL4wTRXfBJAuhzGgs7S9W.sixgMjzmw_GFf5O7Hj6Iv
 jnaFQMfKcQLWNdx8j1VE54t5kiY0JZxhhSkN5tOYL1C9SLvtKZ1XN_h6Y9gOR3P.hxb.zuPANFSz
 r1e0yU3peJqSGV6fGGtUX0h6ZPEcuMVUUX5u89yBTjqdPTGdNi73QgwAmS6FIs3qJrDbTWwtK5PD
 eqs.2Atk_oLtzy2bL4I4iLhCAQga4yz5ClZqrLAsHPLjrhjFQ2PgP5VOTxLvPErVt7aG.ZrX4Eme
 qaYkN4Amx7cVltMfGImt2SbGKbCG80jLvFXu82hnswWn_.uvU2jMaMs53ohQDYlsMjpELWRisy4g
 GlmcTnLQAS.1Zj3HQ4EOA5hhfQ5ZEg.G5M5PLjGYKOcIBKHNqxjEd2S7aKca_LxOLxPK.pqcScGp
 w5VB3SOh7oFD085ZHaKy7Vc0hsaLhp9sd5tnHBUrcXBYv08OgMtk4YH6eBv0oQ3OF_YxlL23ZXUI
 JVNibvmyyrtHwDO5xO.CIttk_CAXww.Am7demKVdTbqEKNIsESQ_VRH8pqUgbJqne79qVAluL90g
 MJKsJTa0w1.InZjdhu20b.2Csmaa89bHfP5mfNaOFcekt.ZoYKjbhd7tHhLqKlBhZVNAOrgGILlw
 Rvci.3UFXCy5MhZHZb2fPVsnRezmlz_oKF3b0_uOsftDO5Ie8ehBCz3zLwAXfr_l1B0q.yQJGCjP
 2W99IvKXOWNHehKhT_FuXPIRpHiwj0ILS.ukx3JbmsHSpvlu_SIfsPhmPcPzuv7qDK5n.Fww9Bck
 GccraENiJMiHzbxeVO3x7VlBK9wCU93IjXahHeGWY8N84yuTmS8bAaUsrE8xoFTdKoRu_wngI.7v
 CTHK4C9saH6_Iy06ICFKGQ1e9155hb66GXHqQC8w5VmKN1wYaJlwVV83Vw4VFAqXdeixEdliSfL8
 fw4hKpYXqBaOhQ5ca90tOcpPHDoSCfNzd2EFmorfv0B.VGB4JOpMdlh9ndqgL8R7hWuhMvDDGNat
 ij7oQ28chXnNfHyttGbeYaJKWPzqYu.MaXFfG_HlAwnW2nQOcRf02vsGJWQnsjbInT1LZzOEWQGY
 TjwpTTPMh_u3E3m1RlNVcK8wNz09BSbv.n8aPUKGohShQEJ720oBXogHRKVoaCy5QdrhRSoBU.9B
 M8FPngBOaf.eGfzzzOHKa2T.GdibP0cOERwfuoi92T7nZ2cqGde4sN4ckOsAgkNXUNrr5a4Ap3vF
 xyXu7QnSPOuLybQu_bIjp8Ujucd1Bqo.NFi2tklAN5xmXCmc_7fI7iaqq0XHuuk8mRzJe3lxCFrN
 FDA7M8JYSaGthThOM5qRXslidKVCDLeEqKJszZqKi6ATB3XJCYyA_8uuJWm_nA.TItYNlxlhdmAp
 qW8oY3BXWLowVxsQ8yaIATfD_TBY5j2tpQVhWVG2UUMXqQOpjX1ZuN0Td0psVuEzyu5MZnF3B8Xv
 xpLUecwMmDceaZf6nOumPDlK1JIAca3y.Cq2AWECkij2AP611VAdoiER1i6AySlU7L_XP6AqbEgC
 mjb0fsNBbUIFy1pGkdHwJLapjHWoPqk1i6jrr0eseHq7Cin2s80KgJdSWuKljvo3aMvY8HqI44ik
 4IIW3F_DKtXRXqgGc_HYKRQMhq8djVGyEHZjpFn3cXQavCejZY6vhG34bkk29cNOef6C5kcAUqb5
 Ph1M8JTgbY0BeShrVoMf.sVO_WvzCpNidbp_1vTGRGRUOwdiJ1aGpT7PVX8Wbg_5D9LPAcvEMFaH
 EBFVGEsxXjCW5RqFAYHYj3XPJWn66IQ05LOuAblgynQFZxLaKqTmbGsa3fYFnGNYn2EwncH92oBy
 BMpA1jWatk28A2EYpphPFHez8n62Vjlny7LKdmgcqSKOQ6cOkUBv_XXS0CIuXJtmdxGJQtwVOB_Y
 IDQVWUKrcZUDTO1ZzRuC2Xk5bNzvXHkNXzzk6gDI.BRFRC9ljEA3EOa5BbLOzG7nq2gv4UZEdB_.
 dgXqSKg.XsPMzrJlSTaT62ByUqL4dEmxruUSZv1Gbxftfh3bgQLYuUPH0r.P3X00kk1XTIgu7FZA
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jan 2023 16:21:25 +0000
Received: by hermes--production-ne1-7b69748c4d-brw6v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d8fc4c0787d97eca99379cb4cfe63579;
          Mon, 09 Jan 2023 16:21:20 +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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
From: Mark Millard 
In-Reply-To: <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
Date: Mon, 9 Jan 2023 08:21:09 -0800
Cc: Mitchell Horne ,
 freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EAD00FA-22AE-4BE8-98B1-BEBB3848C486@yahoo.com>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
 <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NrK2J0xfBz435L
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 9, 2023, at 00:15, Klaus K=C3=BCchemann =
 wrote:

> `ve tested D37981 on a Pi4b,=20
> sorry but it had no effect,
> not on the booted machine and not when intentionally provoked crashing =
in early boot up( no changed behavior in reset) .
>=20
> I never see :
> <>
> (except, of course when entering directly by : sysctl =
debug.kdb.enter=3D1)

I think you misinterpreted:

QUOTE
We get some new console output with this change:
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter
[ thread pid 812 tid 100118 ]
Stopped at kdb_trap+0x448: sd zero,0(s1)
db> reset
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Uptime: 1m51s
END QUOTE

I expect the new output text was only the text after the "reset"
command:

QUOTE
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Uptime: 1m51s
END QUOTE

I also expect that the text:

QUOTE
debug.kdb.enter: 0KDB: enter: sysctl debug.kdb.enter
END QUOTE

was just from how db> was entered to make the example and
other ways of entering db> that historically did not put
out such a line still would not put out such a line.


> =46rom the booted system( so you see that the new tunable is compiled =
in) :
> =E2=80=94
> root@:~ # sysctl debug.ddb.full_reboot=3D1
> debug.ddb.full_reboot: 1 -> 1
> root@:~ # root@:~ # sysctl debug.kdb.panic=3D1
> =E2=80=A6.
> KDB: enter: panic
> [ thread pid 1056 tid 100128 ]
> Stopped at      kdb_enter+0x44: undefined       f900827f
> db>=20
> --
>=20
> root@:~ # sysctl debug.ddb.full_reboot=3D0
> debug.ddb.full_reboot: 1 -> 0
> root@:~ # sysctl debug.kdb.panic=3D1
> ...
> KDB: enter: panic
> [ thread pid 1057 tid 100092 ]
> Stopped at      kdb_enter+0x44: undefined       f900827f
> db>=20
> =E2=80=94






> Am 08.01.2023 um 19:32 schrieb Mitchell Horne :
>=20
> =E2=80=A6=E2=80=A6.
>=20
> The reason for the difference in behaviour here is that the ddb reset =
command doesn't execute the full list of registered shutdown handlers, =
it just calls cpu_reset() directly. For whatever reason your combination =
of RPI hw+fw doesn't support the PSCI shutdown interface, so cpu_reset() =
fails. I am guessing that it is the bcm2835_watchdog driver that handles =
the normal reboot.
>=20
> I think it should be just fine to execute such handlers from ddb =
reset, so you can try my patch: https://reviews.freebsd.org/D37981
>=20
> Cheers,
> Mitchell
>=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jan  9 16:49:16 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 4NrKfW6tpYz2p1kD
	for ; Mon,  9 Jan 2023 16:49:23 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NrKfV5stXz46gr
	for ; Mon,  9 Jan 2023 16:49:22 +0000 (UTC)
	(envelope-from mike@mail.karels.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net;
	dmarc=none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 309GnGPb055260
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 9 Jan 2023 10:49:16 -0600 (CST)
	(envelope-from mike@mail.karels.net)
Received: (from mike@localhost)
	by mail.karels.net (8.16.1/8.16.1/Submit) id 309GnGi1055259;
	Mon, 9 Jan 2023 10:49:16 -0600 (CST)
	(envelope-from mike)
Message-Id: <202301091649.309GnGi1055259@mail.karels.net>
To: freebsd-arm@freebsd.org
From: Mike Karels 
Reply-to: mike@karels.net
Subject: BeagleBone Black does not boot -current (DTB incompatibility?)
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-ID: <55257.1673282956.1@mail.karels.net>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 Jan 2023 10:49:16 -0600
X-Spamd-Result: default: False [-1.70 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[karels.net];
	FREEFALL_USER(0.00)[mike];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	HAS_REPLYTO(0.00)[mike@karels.net];
	SUBJECT_HAS_QUESTION(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	R_SPF_NA(0.00)[no SPF record]
X-Rspamd-Queue-Id: 4NrKfV5stXz46gr
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

The last couple of snapshots of -current fail to boot on BeagleBone
Black (armv7 GENERICSD).  I have no idea how long this has been failing.
(13.1 runs.)

It appears that a malloc from ti_sysc_attach or ti_sysc_attach_clocks
is passing a size of 0, which maybe could happen if the FDT has a "clocks"
node but no clocks are found.  The console output including backtrace is
below.

I replaced the dtb directory with the one from 13.1, and the system boots
and seems to run.  I don't know my way around the armv7 DTS files, but
I'm happy to investigate if someone can point me in the right direction.

		Mike

...
No PSCI/SMCCC call function found
Texas Instruments AM335x Processor, Revision ES2.1
arc4random: WARNING: initial seeding bypassed the cryptographic random dev=
ice because it was not yet seeded and the knob 'bypass_before_seeding' was=
 enabled.
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: 
ti_sysc0:  on ofwbus0
panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
cpuid =3D 0
time =3D 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
	 pc =3D 0xc05d793c  lr =3D 0xc007a9ec (db_trace_self_wrapper+0x30)
	 sp =3D 0xc0f14a98  fp =3D 0xc0f14bb0
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
	 pc =3D 0xc007a9ec  lr =3D 0xc02e8880 (vpanic+0x140)
	 sp =3D 0xc0f14bb8  fp =3D 0xc0f14bd8
	 r4 =3D 0x00000100  r5 =3D 0x00000000
	 r6 =3D 0xc07395ef  r7 =3D 0xc0afb960
vpanic() at vpanic+0x140
	 pc =3D 0xc02e8880  lr =3D 0xc02e8660 (dump_savectx)
	 sp =3D 0xc0f14be0  fp =3D 0xc0f14be4
	 r4 =3D 0x00000000  r5 =3D 0xc20e0000
	 r6 =3D 0x00000000  r7 =3D 0xc0f14c50
	 r8 =3D 0xc0b6db00  r9 =3D 0x00000002
	r10 =3D 0xc0f14c2c
dump_savectx() at dump_savectx
	 pc =3D 0xc02e8660  lr =3D 0xc0358e14 (vmem_xalloc)
	 sp =3D 0xc0f14bec  fp =3D 0xc0f14c20
vmem_xalloc() at vmem_xalloc
	 pc =3D 0xc0358e14  lr =3D 0xc059dae4 (kmem_malloc_domainset+0x9c)
	 sp =3D 0xc0f14c28  fp =3D 0xc0f14c70
	 r4 =3D 0xc0048cf4  r5 =3D 0xc0e0d108
	 r6 =3D 0xc0f14c18  r7 =3D 0x00000000
	 r8 =3D 0xc20e0000  r9 =3D 0x00000000
	r10 =3D 0xc0f14c50
kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
	 pc =3D 0xc059dae4  lr =3D 0xc02c1b3c (malloc_large+0x2c)
	 sp =3D 0xc0f14c78  fp =3D 0xc0f14c88
	 r4 =3D 0xc08f5864  r5 =3D 0x00000dbc
	 r6 =3D 0x00000000  r7 =3D 0x00000002
	 r8 =3D 0x00000dbc  r9 =3D 0xc07a4919
	r10 =3D 0xc27506c0
malloc_large() at malloc_large+0x2c
	 pc =3D 0xc02c1b3c  lr =3D 0xc06ad75c (ti_sysc_attach+0x19c)
	 sp =3D 0xc0f14c90  fp =3D 0xc0f14cd0
	 r4 =3D 0xd00d3e00  r5 =3D 0x00000dbc
	 r6 =3D 0xffffffff  r7 =3D 0xd00d3e28
ti_sysc_attach() at ti_sysc_attach+0x19c
	 pc =3D 0xc06ad75c  lr =3D 0xc032873c (device_attach+0x4f0)
	 sp =3D 0xc0f14cd8  fp =3D 0xc0f14d20
	 r4 =3D 0xc2757d80  r5 =3D 0xc2758200
	 r6 =3D 0x2eb77a5c  r7 =3D 0x00000000
	 r8 =3D 0xc0b72564  r9 =3D 0xc078651d
	r10 =3D 0xc27506c0
device_attach() at device_attach+0x4f0
	 pc =3D 0xc032873c  lr =3D 0xc03281b0 (device_probe_and_attach+0x8c)
	 sp =3D 0xc0f14d28  fp =3D 0xc0f14d40
	 r4 =3D 0xc2757d80  r5 =3D 0xc276da80
	 r6 =3D 0x5e4a6f28  r7 =3D 0xffffffff
	 r8 =3D 0x00000000  r9 =3D 0x00000000
	r10 =3D 0xc27508e0
device_probe_and_attach() at device_probe_and_attach+0x8c
	 pc =3D 0xc03281b0  lr =3D 0xc0329bb8 (bus_generic_attach+0x1c)
	 sp =3D 0xc0f14d48  fp =3D 0xc0f14d50
	 r4 =3D 0xc2757d80  r5 =3D 0x00000000
	 r6 =3D 0xc0f14d60 r10 =3D 0xc27508e0
bus_generic_attach() at bus_generic_attach+0x1c
	 pc =3D 0xc0329bb8  lr =3D 0xc00e4ce0 (ofwbus_attach+0x138)
	 sp =3D 0xc0f14d58  fp =3D 0xc0f14d90
	 r4 =3D 0xc2758200 r10 =3D 0xc27508e0
ofwbus_attach() at ofwbus_attach+0x138
	 pc =3D 0xc00e4ce0  lr =3D 0xc032873c (device_attach+0x4f0)
	 sp =3D 0xc0f14d98  fp =3D 0xc0f14de0
	 r4 =3D 0xc2758200  r5 =3D 0xc2758300
	 r6 =3D 0x2e0a372a  r7 =3D 0x00000000
	 r8 =3D 0xc0b72564  r9 =3D 0xc078651d
device_attach() at device_attach+0x4f0
	 pc =3D 0xc032873c  lr =3D 0xc03281b0 (device_probe_and_attach+0x8c)
	 sp =3D 0xc0f14de8  fp =3D 0xc0f14e00
	 r4 =3D 0xc2758200  r5 =3D 0xc276da80
	 r6 =3D 0x5e4a6f28  r7 =3D 0x00000000
	 r8 =3D 0xc0b094ac  r9 =3D 0xc0b094b0
	r10 =3D 0xc0aeb014
device_probe_and_attach() at device_probe_and_attach+0x8c
	 pc =3D 0xc03281b0  lr =3D 0xc032a62c (bus_generic_new_pass+0xb4)
	 sp =3D 0xc0f14e08  fp =3D 0xc0f14e20
	 r4 =3D 0xc2758200  r5 =3D 0xc08eb898
	 r6 =3D 0xc08c602c r10 =3D 0xc0aeb014
bus_generic_new_pass() at bus_generic_new_pass+0xb4
	 pc =3D 0xc032a62c  lr =3D 0xc032a678 (bus_generic_new_pass+0x100)
	 sp =3D 0xc0f14e28  fp =3D 0xc0f14e40
	 r4 =3D 0xc2758300  r5 =3D 0xc08eb898
	 r6 =3D 0xc2759680  r7 =3D 0x00000000
	 r8 =3D 0xc0b094ac r10 =3D 0xc0aeb014
bus_generic_new_pass() at bus_generic_new_pass+0x100
	 pc =3D 0xc032a678  lr =3D 0xc03256b8 (bus_set_pass+0x54)
	 sp =3D 0xc0f14e48  fp =3D 0xc0f14e60
	 r4 =3D 0x7fffffff  r5 =3D 0xc08eb898
	 r6 =3D 0xc2759680  r7 =3D 0xc274f6c0
	 r8 =3D 0xc0b094ac r10 =3D 0xc0aeb014
bus_set_pass() at bus_set_pass+0x54
	 pc =3D 0xc03256b8  lr =3D 0xc0271788 (mi_startup+0x2b0)
	 sp =3D 0xc0f14e68  fp =3D 0xc0f14e90
	 r4 =3D 0xc0aeb018  r5 =3D 0x0fffffff
	 r6 =3D 0xc27a3348  r7 =3D 0xc08bf85c
	 r8 =3D 0x00000000  r9 =3D 0x03800000
mi_startup() at mi_startup+0x2b0
	 pc =3D 0xc0271788  lr =3D 0xc0000344 (btext+0x144)
	 sp =3D 0xc0f14e98  fp =3D 0x00000000
	 r4 =3D 0xc0000480  r5 =3D 0xc0ba8000
	 r6 =3D 0x00000005  r7 =3D 0x00c52078
	 r8 =3D 0xc0e25000  r9 =3D 0x9cf00168
	r10 =3D 0x00000000
btext() at btext+0x144
	 pc =3D 0xc0000344  lr =3D 0xc0000344 (btext+0x144)
	 sp =3D 0xc0f14e98  fp =3D 0x00000000
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!

From nobody Mon Jan  9 18:08: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 4NrMPv31dMz2pBHk
	for ; Mon,  9 Jan 2023 18:08:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30])
	(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 4NrMPv049Rz4HdD
	for ; Mon,  9 Jan 2023 18:08:34 +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=1673287712; bh=JhXYF6ZY/DWXFRNn67B79lE3oBBzal+VWNIcG6p6zDQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WuQbLOGehBUxC5UTdYsuS9LVzh+zZ6sceouX+fa8yklkvqphTwl8jzBfyPeJKaX9oXsri+z2eFxty6BY4ecfsrPiqMmMRVp6qtSN5Qb/q3Q5XOoaChxIMnok5UPj9A/zH+F4gTiPl+2Ufi5saIrywGe8WxBaPwv4IuZa3nq+nr7bw9pZkXqO1fTQPUKDEZsLnBCXiNRmG3l1/Bj2d1uV8NGb5ZUxDko0ZO308wbIYa9etZQwO3JCSHn6RuYju0ugbTp5oxEJ5h+WX66zt9/7RQ3V4es0Wdh+78ov8bMML6+qBykr+2DXqtIHQlj6jidQOLXqmitS3q3j4/6s2zyAKQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673287712; bh=nTcQNxE1sd7mw+Cr9AvKU7XNR//R1QqAb2GaYpQsyoG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kqku8TOrPhPUmB2ObEPljghnBSx3X1fwT2csPKZl4d24pQ/cNBjeZOwBNK3M3CPBu4lxCAZUXiGgKQz5AmJTB0SrDwtz9y2A5HtQ3iAb8J9T6oMfOf13P5FGrv9zGPPbLzvVdlVt2sOa4WVwKKAPcCKTcjwVRHf1Pj/4MYX51DgUssYeNWzVaIrnVEFGvK9OJx3wkxNJQGpIlXjDL3uYUpJPtGISApNiEis7ql9cQV1+qRIEbimu6Bo3hqDhGosQzThhP5C08jM3wiBrt9oiAYmOd19zZfFFxI6Z0UHD4h+DIgauE6PRvKblo7iqC4ICxmlS4k+q2Du7n6wgr3WynA==
X-YMail-OSG: xECOE9EVM1nDTRLI5gIdSWFz29Bgd0Yw3AYO6nDcMnQ_t4OEUYI2nXt8H9iCSrD
 y_VQkQaXHBstraHVsAhhwmARaj_IKmVuV6fwCyB708VTAJmXXbRhggT7xCZrqkPP2H9ILBRhumhr
 Z4O_Sl4SmG2jsf0KdYjiGTWi6mVVXsPwPiVcEHKGrDfsbrZ7OhWntAxC4_0VfvwfimWpyff3Wmt0
 0_kJ2C.BjKp80MCLzUpyedC4Sws2lqeHXZv73SX3qyPxECQInieDVPJweWIBErUHbWUH8bXWzQOn
 7A9ZAAnk.CD7l_cb_eFslIZQymyQ0NdiGj8FVszxpEQy54dTXCNR567Kv0pvcOwNa900gg97M3RY
 04_asb1Di9Ug8RQW3lSPgPWRP1JL6u5iAa5e3oyC.FTf8vn744FZwH4RXKZ27aWifb3sxTUG_Qyx
 EYcS7sSnWsAsOlIAGefBiSAE3Sq0GMutWhCp6O9KXMY6xmOyn.iD_KkeO.qI_gCUqQjctTfmji2u
 moF94Zo3ACNihtmDE.us2OaM1t9UqD4mu7.Ng5Sq3aNky2XQHDSKjmmpyCLFUAnOddQQ3S__eHYp
 OD8cLxqOaXfBVLmTV69nE82wjm0eIok.Mst7fWYRRURv4JY5iwWKQIHWfAWdz7KZcC205a6Fo5pW
 Bg.Oqv.Ws2Eh_7FzLQtTLrGRjB2nLPqGyPYGgLHHWD4iH3qatjmsGzx1FuHqdgOaqBkbOwJBLtEw
 LvD._kViUfTvW2ah.39bITu0l8WISkHIUS2xANi_3aADz2P0BH2Rc0r.yxD3j3XyXFkWfU_z_48X
 OKCHLCAGs9B2RfkJSTiqAZtRRChOKZXU8qMzTJ8Yn3Ofy.UVmKUGY2w4Fla7alLSFV3Y.mKUSKA6
 0gJ4oEEtGlBcOzsEE5ShfpYrZrht2ZbOkN.9M.e7JSbZMG4zh5YQGAJ9mZKlf12kcXhleMN_reTV
 S3UPZnnOcdev6uVJvglVYt2PWfl0O68UMkwuSx9ELKEHISSd0.1CArl8_Si68fPdXw7F3Pxti92X
 8Grh0d8A6U22aFrymcFwEmMPP2qppl_Kyjfhf5JF6YGpGr.PwcY0sIAKpHcKgtBpED3Q7._pSscE
 J2f1mOpLIiSrbS8WTWcRZQ0VvgkM1Ionpmept4OPeGzmPQ3wKNfPOIm3R6PehMBXEEhX9Eu5yFAF
 1TrX6r39cRGdPdlIJRiOVwPRtJcz3QBn.KtMftHP50xBngndLkpKDwVOl3xSuLF_Z83sv6vDKXdh
 axymJmMQMuuO9UOqmqy7rBWYOYWlVyO8_WvHdhWrizslvFD9BeGW_4qwJYkzG505aIeOwrzzNRGb
 XCfS0HBE95JoC4Lb52iEvhCnGUIlMf4MHQK4kJLG.AzmSJRk0bL3HJSr_f8Q9azwIBIf_9H0FN_F
 vUGOKsGlW0QBT1ubjO7BA84ouxa6W_KHxXMuqad4CD7sYWD7y03.V4w66MRceasT.7Fpg75y4zgi
 zs.jHPICnGObJDx2XzTeb_Qtqt11y3s1i_dxP3o7296.e1U6XiI0P32weSF88lBbNNF__McJify_
 6XLgURhyVfgXlJ3D2DDAbIF4qt6CveLjv70A0U2L_GIHHYom0nN4M3_7zQs5ROj9MU2JydZw67lr
 klriXiak6dqVjUgL4CkvcYOnFZO8FeZWOQF1y6tQevLvtSVpWvLCPf4x06OL2Red296ykVs7JwNj
 OiazeYbEPu1K4VdmxKJltPOwqEJmf3UBXRQC8pW2XVq36OeFO5nsbcckRQnKhbkSA0VzrwTgPH1v
 YY_2YSH1iqmNWNlR53qPDWP4rShKMxvXCGOF22cRSwR1Q2zwVdxuDInGcfqWB.lBcAo8EUIUqqPt
 D_mCzMl7GwPlTD6kFdWTg2W2VJ5sfrYXD3xfB1tumOr7Pi3lM_MIoRhMEy7GHjj1hmsDhR6lBqda
 oHh2W23an5mTqcQNPNncQrULq5B.xlZ4lROOwhTFfizghqs3pOjsLg03pCExwZDvwnDg8FgabxSZ
 IEU6NDVpX6nfU6EOgd7TU7fCcGJRp6eyzneYCyWZ2_YG_LCRLMOraybwWKr.8.sQMCZBOATXfD5m
 HrGKL24854XsPWeHl.rqEndRPVPq7a7Mi7Nza2t5n_ilzSN5kzSFiK9GJBuOvTl44Y86Spudz2WL
 PyTgli8btQUAg9U7kCWLUOpdotLTZMp6N9p1HqFemq4jRlnJdjLH9KYd8kpkdc6XLxrNt4B0aqd2
 zLC1LsT5c9wXJ9nKxqAE1HtfN1G77uz6erMf4qeQgBn7jnCrT5n5jC4v8b41IIW2q5Aw47uQIidM
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jan 2023 18:08:32 +0000
Received: by hermes--production-ne1-7b69748c4d-g8q5j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d80df0da0ec52d783362db2a583ab15e;
          Mon, 09 Jan 2023 18:08:30 +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.300.101.1.3\))
Subject: Re: BeagleBone Black does not boot -current (DTB incompatibility?)
From: Mark Millard 
In-Reply-To: <202301091649.309GnGi1055259@mail.karels.net>
Date: Mon, 9 Jan 2023 10:08:18 -0800
Cc: freebsd-arm@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202301091649.309GnGi1055259@mail.karels.net>
To: mike@karels.net
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NrMPv049Rz4HdD
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 9, 2023, at 08:49, Mike Karels  wrote:

> The last couple of snapshots of -current fail to boot on BeagleBone
> Black (armv7 GENERICSD).  I have no idea how long this has been =
failing.
> (13.1 runs.)
>=20
> It appears that a malloc from ti_sysc_attach or ti_sysc_attach_clocks
> is passing a size of 0, which maybe could happen if the FDT has a =
"clocks"
> node but no clocks are found.  The console output including backtrace =
is
> below.
>=20
> I replaced the dtb directory with the one from 13.1, and the system =
boots
> and seems to run.  I don't know my way around the armv7 DTS files, but
> I'm happy to investigate if someone can point me in the right =
direction.
>=20
> Mike
>=20
> ...
> . . .
>=20

I mounted based on:

FreeBSD-13.1-STABLE-arm-armv7-GENERICSD-20230107-1149f0ec2b18-253362.img

doing:

# mount -onoatime -tmsdosfs /dev/da0s1 /mnt
# dtc -o am335x-boneblack-13.1.dts -O dts -I dtb -s =
/mnt/dtb/am335x-boneblack.dtb

to generate a sorted, overall .dts source.

I then dismounted and did similarly for based on:

=
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230107-11b5b9e8a520-259967.img

generating a sorted, overall .dts source via:

# dtc -o am335x-boneblack-main.dts -O dts -I dtb -s =
/mnt/dtb/am335x-boneblack.dtb

(The -s sorts for making the source produced more useful for
diff activity.)

Then:

# diff -u am335x-boneblack-*.dts | more

but the diff was rather large. So:

# diff -u am335x-boneblack-*.dts | grep "^-" | wc
     933    4250   36379

# diff -u am335x-boneblack-*.dts | grep "^+" | wc
    1318    5774   50377

13.1 (and stable/13) are back at something like linux 5.9=20
for .dt* source but main [so: 14] is at linux 6.0 now, the
11th import after 13.1 if I counted right.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jan  9 19:13: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 4NrNsN0Vzhz2pKYJ
	for ; Mon,  9 Jan 2023 19:14:00 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f])
	(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 4NrNsM6sHbz4Q0j;
	Mon,  9 Jan 2023 19:13:59 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x52f.google.com with SMTP id s5so14018261edc.12;
        Mon, 09 Jan 2023 11:13:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=r22at9/yYw0FAj3jkgmaIT+DWRg0xnogSbDiSSx6JnE=;
        b=GskJIE/RDf7OMugVGz5yuzdjXLJIYW8rLn7UEB5NMpjKeyflAfCD3mCvZUdZX0bQxK
         7mCOe5kOfwdQ2g5hwj6QV2DB2VIxUL/IVdj/uPx8KhNlOIHtyTvEXcQRVmaC3ncOnAL4
         hXmWOMuqGfctHZycAvqUOuNpKzS5KKlKogiphNk9RZ5rx4zXw277m00gYffKXT8E4i+R
         FQAQF+kMrC510oPM8nsdnb4jnFRA//4Qh0EUU2bCBMkPSRLsjZg/0N7tcBYLERCBS26/
         ATYhcY0C1kcIilA7FNlAwtmeTSEEuVeCO7bFMKwojZJGrd57cDQ6rfPs8+7Ztd8vkdwQ
         EiVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=r22at9/yYw0FAj3jkgmaIT+DWRg0xnogSbDiSSx6JnE=;
        b=viXxgoqv3AIXWQPrS+QPAZjOolRkrsC6EwaaHFde0JM+feEBoKOmnxaJTxZvsSgkBo
         hWsg6eTELYagzUrJJjCW61Q2VjTk6auvAKp3285h0a2ToqSd7FKJktY0/muub8mil6Lg
         kfbchNyNtl8chg5Dlyiy8y1KtmDk/cVuxVrQ/Hli7sM05dODC2pVC/zhNHrOPOcFi9TV
         gjhybosKPZtPc+18jQfQ+Ye1lk6tjiZkzeEQoRglp6uSD1tGFn4vAs2LWhuvXbbmDY7Q
         MdnqHKUAAOMXSfzAIfuQF1tOmcqAK7t2a1DVsLDyHgg3YXmVt1qa7uQyrNZxblkZxy4s
         b6mg==
X-Gm-Message-State: AFqh2kpONJWjfzgUhCSFiEL/ht+Y3OabLm9HunFIHXRt8AZi2S+DWq6s
	OrIvxvrdogd/DF2AEFW04+oc1VoawCo=
X-Google-Smtp-Source: AMrXdXsJfxFNZ5tcppK3vuZjoDTVx7GhnDSSyttlLLMz05UjNbjrGseGs/Sb4cjnnygP9YJcj7AVWQ==
X-Received: by 2002:a05:6402:1c95:b0:48b:a29f:4bef with SMTP id cy21-20020a0564021c9500b0048ba29f4befmr29794439edb.6.1673291638764;
        Mon, 09 Jan 2023 11:13:58 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-061-069.46.114.pool.telefonica.de. [46.114.61.69])
        by smtp.googlemail.com with ESMTPSA id a3-20020aa7cf03000000b0049019b48373sm4059321edy.85.2023.01.09.11.13.57
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 09 Jan 2023 11:13:57 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
Date: Mon, 9 Jan 2023 20:13:45 +0100
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
 <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
 <2EAD00FA-22AE-4BE8-98B1-BEBB3848C486@yahoo.com>
To: Mark Millard ,
 Mitchell Horne ,
 freebsd-arm@freebsd.org,
 "Bjoern A. Zeeb" 
In-Reply-To: <2EAD00FA-22AE-4BE8-98B1-BEBB3848C486@yahoo.com>
Message-Id: <38B9AB9D-BDA8-4186-AEA7-6F63530FCC68@googlemail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NrNsM6sHbz4Q0j
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> Am 09.01.2023 um 17:21 schrieb Mark Millard :
> =E2=80=A6
> ..
>=20
> I expect the new output text was only the text after the "reset"
> command:
>=20
> QUOTE
> Waiting (max 60 seconds) for system process `vnlru' to stop... done
> Uptime: 1m51s
> END QUOTE
> =E2=80=A6.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com


Mark, I also don`t see the new expected output text=E2=80=A6
do you see any effect , have you tested on an RPI?,
I would be very happy if I=E2=80=99m mistaken and if it would work..
-
O.K., now tested the new  Diff 114868  of D37981,
Also no effect to =E2=80=9Areset=E2=80=98  by an provocated early boot =
panic=E2=80=A6

I think you`ll need a real hardware debugger to e.g. track the issue =
that the software debugger  can=E2=80=99t=20
execute shutdown_reset(NULL, howto);  safely in early boot stage without =
calling the bcm2835_watchdog directly :-),
and you would need it anyway for board bringup issues..
Afaik that=E2=80=99s normal on embedded

Please consider this only as a test report, not as a scientific =
statement,
I don`t have any knowledge of db_command.c=20

Regards

K.






From nobody Mon Jan  9 19:45: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 4NrPZC4DkRz2pPBK
	for ; Mon,  9 Jan 2023 19:45:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.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 4NrPZC1FdBz4TYb
	for ; Mon,  9 Jan 2023 19:45:54 +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=1673293553; bh=0kULpciVxykmmSzIpv4tXtVt8/h4zviz4Iqh11YgIa4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fbv/CJMP9GAzoVeg4ehLKFaB/ucMxL/FiSaCVwoSF0REQd9KmwkQttFLBRMXj4SWRkIkQdJJrTyzsHf+1OyztiFzG9Nt1AYQzKpUQ+uOTxXv3c9mrriZ+lROpWZtpYTymurMneu9qQc9vzPLaloBILDJwlXeVC86mHYB4H6iU96RT4mcjzHZU59R/2b61DFBOSG+rq0VHFJV1O20o7U5ximR7i44uvqD8xv8qS1ZcTu86fgo/Y27dwF4b5kW+a1beolDUzjeLGi61eGCV6xCdcXFGZnRqzYk2FSRy9xmomm2NDFNLYpPiYsCVWPXFRUpxffB3EVbdx+BKu295O4fSQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673293553; bh=YuEFOHuEqiL942weQ1nKTb/IOOE4c54eQBK/gB0SWZg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IJtNjAaYFQLjLr/hTjkmo3Mtsoz7sB8VrLi/gjVmBZRe9gmEqBwhXBRPjaWlSwE5XE0B+2reE9mBTxTKmR41WgITtwikkEmHdnTdgNepLn1Ri6xU9prHlCtbSjj7KAzCIGL6RLRpSVFeElI6oeAzKFerIo4+AX/iLEZlUTBEUPXvEn91ZaPEGW509llj4le20SbZFj+x9P+RUYcloRgZTfgI2nO04jP4axpi1gyTB8NwFapMV193icEVF4PYtDfBKytpSGQuCOVfDVuMBy9lM+EOgdXzd2FjtzitUnl+Uzh7OtWfX6ckWLTcKYMgUN4VknvV6zuklO1snAu52OtakQ==
X-YMail-OSG: CyiRpPIVM1lkM7HAy5BfXjZG1UFftpjL4HBYKaDmMM_aKcG37cDWslG2kQofjAX
 43F9unB1MlEVp0F7CisldsyBPc9I_24Aj.ueJpY9qGed.Y7nDGKUnlpM94hTOoS27uaJyVnuhcYk
 Cdz2EbVflQywR3TWK7zKYGaVbiqx_8I.8BnR1GI1Gh.fJ8zkg.sWdG0gVLsdGhvvik2k5x9wElFk
 vL81L5f8qfmpl5dB78nqZgvIGLOoZ0F_kGsYRR99r5fe0rTnK3FyEM4Zxi_V6jy80dJRxkKXVJ.G
 duW.xqhC6aAS4tFpJ.f0HRJAnaPUADureVKjp0wE4NC4p9DxBS33fFlY_lSk6pmxWxzLgNMchreB
 QqZ6IwAtcphMyPKxZs4Pdc6T60FgIJpYhkm5tpy1rHq2eFrEj_8lmHDmtElsU3XRWL_dA8Fd6gAJ
 EHC156LMBLT4Sd5VRukyhQFeKGbAWET0diYjzHwWg_KcfnSPgrEeE22jj57xO8SEi37zx5aGhEBW
 RObympTqerjICOEvp0EJ44e0gGHbcMfzi1G8MFtu_SsCU4pi.n.QVsdJ2S7lKE2w4K_81wpOxZqw
 MEpf375yMZwMLYZnGLqSGOM.2BMqaFqL_mTTRdrT_9JTb0l0H7nIn9HVnP47DUZpINBOSUck6oFy
 6uOREB.wjyeuou3MOSxAIKkbADJ46OqEN_b5xxMdvb_LQIK5vXMBHv_CXw9xYkn5NRV1aLHLZshI
 X0N.eHuglndrV2zdtLpT9nlrpPjnz.6x7jVAr4rA._uJNbEOljrna8IjRD7w4bpDrXpjZ9I5Ge98
 n2dKumBkTA.s8qZSlxCR00dZ6xpUlAjMIwrS_1HwmGESNtzCOur_O9q__RM2HByJ7nKBBYJko8Mq
 JQKgQcOprV4LwARj_BjfBchV8OHCdfaHQuyURgYpkUgptV9WFs6sMKe4AtO7So0jUH79FbuGhIMK
 rwv1OgQlQQhljca7wPHPAQ1LOZNrVG2KdnGWfqo24xFkShqfEfMnWq6AmMS3Q3YN6XqzpI7U3idf
 gRj2gBVWLml2Can22KuI7Skn1bKl_L2gQ8iA6lqElz2LvCd5NDCRPxhZSjBYQnOUW3SXqM.DqhLD
 Vdl8h9b2oyYaWKfprq4nZ6FhSLH1Lebtzy8UFOqpNgya530TUsv.IVGiNtyFMUAQHzseAQpMK5Gv
 fONrlP9g0ZeD.kizSeLtoRvUxH8GNqQ04sNo_O5AMr2s6LekIE1GPKVsQGLqybbIaIB4NERsHkjY
 Ilab_GV0FKowfqnMBdsqx2JoUQhUEILUwbi4lJnAeclR1O1QE0TyEfVQVQgLmDx_apAsa9mjFJnD
 xhnNm4vdvfxMhOVKpaFkVstCzsnotMoFLVyuNnV2zgdfe3GD1R8yE03Cr9yeF73SSi.W7ScqIeys
 qu6q2U7XbuHIEG3qJ3hTghDcj0_T.IK.kFVVH.iA_t50YpsUOkMz.4AiwUqaLxlnG.basP2RmjGm
 GCxdea5_OwOsbv0btNPs9bzQpMLa7HrM2Wo.bePPdE1ULsdvvjZ7gQp5nFdJ_EDkFeSTLPjyVwrM
 crNmxTDTbwM5I1N1mZ2w7VEF1CtNPgLtF_sMp.YiJ.a3LnFuQuq4XeU1mI3slE9ZZJvRQNSlqDOi
 aVq4DQvtgEO4q9T2TaHfdxRzM3ubMIh1BxaJbHThgY6IE58awjrros4XXxqUwGvM9zR3h.TWYmL0
 V2Pb6VHPM8GYjDzbggJ3k6PBnIf0ph0GilBxrI4xd4LXuDxdcI5BRnAszALSesJRitW52YPxut6H
 J8LEgR7v7n_SG0x6Ld8cVRH_xVtB4lJvPwp54ECACQq3QMjwu7VRzl6O3LWL0tH6.R9ORhQ98__J
 XWrg8mD4dBHZk3v3GsSoVR0p4LctZ2Q49yl2syRBLwC6NP8Va0zvkiKDfqx.uYPqn3lYuN80ieWK
 dUgJ4hfFdJOg76yYdUYbhSBEqcHkNVFAlryICG7jJvo1du81QHd_jG_iIdGDu2wnnWB0KElQ.v6I
 RR6ZH8BjhmBV0mKHdzX9Uers.tw1ju9b4V2SKYCXy5dJzL59_t4jvokjGbtrvx6rMnTSPda6dcTf
 ZF.zlDkq6.r1G7nt4q.KNN9U_Hof_jZOKuRs07hM4OEOA6A6FLvhSsRoJ08bn6Ax3bxvfdmWZZ6E
 3ymFLDAfBHevAlEDCxzxVCk9AJSwyZad4OPO2oVMdPPD26LuhBtOSlmRY5vcgyuh1tgRPKxHtCrM
 7mz4wtd.EQ0NMesgyNh8fAopfCu9v_yXgCJ370VLeRWWW2yRj7SZiryGO5c.VfZLCAuRiUMoCq9h
 VZg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jan 2023 19:45:53 +0000
Received: by hermes--production-ne1-7b69748c4d-brw6v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2875c388d385fe4989ba8ec9d301b808;
          Mon, 09 Jan 2023 19:45:49 +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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
From: Mark Millard 
In-Reply-To: <38B9AB9D-BDA8-4186-AEA7-6F63530FCC68@googlemail.com>
Date: Mon, 9 Jan 2023 11:45:37 -0800
Cc: Mitchell Horne ,
 freebsd-arm ,
 "Bjoern A. Zeeb" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FB2DA46-7BED-46BA-905D-DEAA33E9E1E8@yahoo.com>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
 <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
 <2EAD00FA-22AE-4BE8-98B1-BEBB3848C486@yahoo.com>
 <38B9AB9D-BDA8-4186-AEA7-6F63530FCC68@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NrPZC1FdBz4TYb
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 9, 2023, at 11:13, Klaus K=C3=BCchemann =
 wrote:

> Am 09.01.2023 um 17:21 schrieb Mark Millard :
>> =E2=80=A6
>> ..
>>=20
>> I expect the new output text was only the text after the "reset"
>> command:
>>=20
>> QUOTE
>> Waiting (max 60 seconds) for system process `vnlru' to stop... done
>> Uptime: 1m51s
>> END QUOTE
>> =E2=80=A6.
>>=20
>> =3D=3D=3D
>> Mark Millard
>> marklmi at yahoo.com
>=20
>=20
> Mark, I also don`t see the new expected output text=E2=80=A6
> do you see any effect , have you tested on an RPI?,

I've only been reading along, not testing the patches.
(For one, my normal environment has its own patches
involved, making for a unclean test environment if
used.)

> I would be very happy if I=E2=80=99m mistaken and if it would work..
> -
> O.K., now tested the new  Diff 114868  of D37981,
> Also no effect to =E2=80=9Areset=E2=80=98  by an provocated early boot =
panic=E2=80=A6
>=20
> I think you`ll need a real hardware debugger to e.g. track the issue =
that the software debugger  can=E2=80=99t=20
> execute shutdown_reset(NULL, howto);

I have no access to such.

> safely in early boot stage without calling the bcm2835_watchdog =
directly :-),
> and you would need it anyway for board bringup issues..
> Afaik that=E2=80=99s normal on embedded
>=20
> Please consider this only as a test report, not as a scientific =
statement,
> I don`t have any knowledge of db_command.c=20



=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jan  9 20:36:28 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 4NrQhv6MNdz2qkt8
	for ; Mon,  9 Jan 2023 20:36:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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 4NrQht6VHdz4YYj
	for ; Mon,  9 Jan 2023 20:36:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MuVnNSR+;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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=1673296604; bh=kSp8+Ismh4DqOnZFzNOCKuodVydv7apBE2prJHrzxNM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MuVnNSR+jtRROQH5axoWpx+OLySrzp3h4A+Jxb61IRhAVfsm1MV5GKl8Vbyy+Fz/KWDS63SFfDvEZDPM9vdP6M4RwE5D2tj0dSmvxDHPYvMpI7LE4sZcX8yOLNecNsbhxAZjBwXYRK/PnhQzagHRXBqMijGPrb5oJD5qu9NLsRZ0qKjvGKzojvWgXs0dMLO/1SEimZotE3pSbS3M62FibWCAtXmbuE8VwLfW1yN8wx2fqeaHTAuBX0Tdn8ROo2cW8XSaDWmGW4Q0wM/fSK3E+Umz84fMywzyCj5AQMS9fFHJeuuJocVSSeWBF2lfdOrD/80ckqei06efduRGSQxtBw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673296604; bh=Cd3fAOJPaotSiROJDUNCAUmcvSfWf5neqfxPul8v5zx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Oq8QYyHKjNgP6xJoF5vXxQfYlB13wPsHyQ+uHc12Jz1CfW1BLEEGqyXfDOz/BbBCPpa4iqnGfMEzSqmwUliwtbstuj0jbqCWutPZofRLBJ2BHgzyK5g1Q9OY0g+Uc7LpWtuz1usMylz2AzJo+Co961SkBUVPxaYOQsocjMmzJfv4e+9eCSny2N4CAVDVontRd+JPOhCRlSoo/Fvr0LeUe2wHbFrc+MdY1wz3Pa6Na9rjqs/Ia3XJNiV6Vu4mXvVXI8JCLyUBCZA6mjxJekIJCOnZhwO1wuR7MuYUi0MxNn4+/YfkFaTUlswRI1D2FqaahKw48zClTRkNt6p0c4qLJA==
X-YMail-OSG: _M2t8PEVM1narnUjf11X2LSpyjYbVrBilIpb3ZSmHoqcGGHto.NSSTv8pMs7M1X
 nko.3zeQl_DxqrmzyuC3d4LzCdlGJjQv0EPVebYdjbbvvkKLFXRtNVEyh3g_.pL13bYD.ORgi__x
 h9uO1PSPr18w_bXEmdd3XZ8CDv5iWRs3nF3KHexzhOZHPHH7E4GuA7a6AvhATzhjkC44hUEXT3PC
 R9PHNzp9.b8mC.ZOBc8pFKdJHjG_mSZYhEvpcmIJQYXfvn0W.DpTw1lXfPXIRw2yV4MkNDSTzf6J
 IiS0yB5v89E_jOYB58hTZ06XI2IJbaH9m6X3yZWztuaj2zxmVeyBQH_LYj7.sMnHClUHH6mE0eUR
 iAr9DE1wc9clbK58JA.b.ac0Bdd37g4tkTG9aHJyV2Hi0jxlH62lejC5D9RvGnPcZj.2_8oYPnzg
 TcNPmN8Oz6x7yg7bFBLyoI_ayW7A24Hva0ABDPh9qZq1IrS5.t_LBMjjSjm1DGU6J32InyZ1dqV8
 UJNqf75OazD_WvKBLKBPURO0ClXaTbe8fTZFsljtU0ewRTfFbA66K1FYWXYIwWlCf6HrjbC7pcef
 lSTdsUIMMprN2Vg0uW1ZI.O97aEZgC.Tido7bsVdRMwv5sXTvmFkgxkHr.cNYMdweOFeckIzuzJI
 eszNFEgVtx5ZLjYN3A4Tkx2qwF9qKTrp42y06B.tKAMqIhh3VQR2Zdi5XM_1R2u4YB5CAepynLIk
 tG5nkI5nOafvh7cuIUyD3pgPCm00r58r0J3N5KYEUxx2NsQwtoT5bck6ezZAll1UiV_bK7pJcC_Q
 5KdTCBObAmoJb4ES7GKKAgHYLxQPADmMPhiICZdWNIrYHdCsg7f.1PG2OHiuXbjAc8xBjQcDr8Gl
 mD084xdeBpgleaAuOK6lBVno7tHMlqqOWjs17ClHTXiT1bU8xXmT0cMRzS8DKGvdDaVGiyuH_MZK
 SG6Dcc5Tx2BkTa11uWsaTzgspABm6sjfDbPAZ7Ia9IOlK4UWDCcm0IHS637dTGpmntIxg9vSM_s3
 px2S5iRKDIC4YX43.OGo31vC4e8GmfyiQqqODnsD9TlkBwuAGMl90hNoKzQKLJVLsOIUaaE5uoxz
 JXYcmQWTQtyGzBoye8ZWPK0HdVd2zR_La9zoBYaJFurOPrl7LzJYLUyoitMP8r8PcKXXkJEljB8L
 ILGXIRa_CoZIVXgXThTGeSIkpK_YFxCwwbwYz3zLQB9p8zsCVhBxSi.I77PI.OQXRLVr_CLzx_K6
 m.ySjcdPsFDBrsIPEAHMssGUjjcqVmfFzAKdS2YU8sx2.VxByDXvhuaMIvVcBBVmSIyGw60O9SyB
 h60OXfIMblbylh1Y_.lzaFyhun_jMl4ZrNiPNr6J_7y7q6.QUDyEoNqDiBlR7AEByk0FW2nI0DIl
 NXAQZZgOPYRgOa3OGE1.mE0ogkJPl1YxkoRhufknf_PHg_XNvLrcehvh2hNLmkbjQEEgOw5EP3jh
 WrbHk7Hq9DPy_mOKw6cLDxOqBPEuL6YYwYC4ly2fqzkaDlwjgdn_S2Hi0kHqtdiySkIc1huMIgl5
 Jcq.Jzf6lJ_o1Mbcj_zWk07Voh3gLoTw9CTNt9qODJcvWkvmMyTidACt_82qFQly4SWcy.PforOJ
 jkW7Y5EyGGvxFCL_sajzl1ei.cugVqZSylHhoPsrgx6TgqTKp6js1Mv8FP7Y5smvsJGaRCqbcA3r
 COF5MRSzqVnBaoOcVQ0.0ZmRtXWrHyNpuBHqHiaqoCOnmM0AFOmvD27DbAVL_u4fRnzSbA6jZdWr
 1xl96SajksuG1wlD4y8Vd8w4fjOUvcaNTgUBULpQO1k0h74krq1H53FkAIeMATkSLG3Ur4fxWOGl
 DhHxDaAKlEWPMYY_P9Q0nZHK1bVQ.Www3PCp0Z.q.xsddd_w1Jb27k6ExaqkeNwsJhKmfpf22f9w
 nhTv3pQfC6OqLbu5V3Erl2v3yDi8CylzLYDXE6Pf8kfNDXkZPSe0OVEiCg6k4TmgNIz0PbrtjUJc
 Yuhvy42yU6l_8yej4gDJjg3v8KYRgJSLvoJXd5l0r54K4MQBgIqdjk3TvLD0BESarxqHF7M7o.5K
 Akv_JRgG98j5RuwJY0W6osgDb1tmKGA3K9zKAMHrHvJSzcSsDj.FcxM6QjOsBUhMVJYXcYEr91Rw
 xtO2YpR0Y.gFv8OFJwHS.UxCsent08Fn.5alJGXNfo8P0wmcvYJio0HXZm2Y9kdJGYQ2QqIglKfC
 g8eQ.OWe0bYRmKSDrhMkKt2y9DIQWVNX2kwNLgqA3lU6Hnz61x9pV1_loFWswr32l.KQiTkNT0PW
 95g--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Jan 2023 20:36:44 +0000
Received: by hermes--production-ne1-7b69748c4d-brw6v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ff5aaa9795c17f006863cd8be3b769ca;
          Mon, 09 Jan 2023 20:36:40 +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.300.101.1.3\))
Subject: Re: (RPi) db> reboot -> cpu_reset failed
From: Mark Millard 
In-Reply-To: <2FB2DA46-7BED-46BA-905D-DEAA33E9E1E8@yahoo.com>
Date: Mon, 9 Jan 2023 12:36:28 -0800
Cc: Mitchell Horne ,
 freebsd-arm ,
 "Bjoern A. Zeeb" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <718AAC84-353A-4187-A6F1-57CB2AE644E0@yahoo.com>
References: <29q7q878-091-r17n-8r3n-o3n68p3646@mnoonqbm.arg>
 
 
 <38B92299-2776-476D-A81F-7C8EB4D59A13@googlemail.com>
 <8o4s9914-sq84-90pq-no3o-59r18n5on14@yvfgf.mnoonqbm.arg>
 
 <5A57DF73-FEC0-41C9-96D2-A4EED7695EEF@googlemail.com>
 <2EAD00FA-22AE-4BE8-98B1-BEBB3848C486@yahoo.com>
 <38B9AB9D-BDA8-4186-AEA7-6F63530FCC68@googlemail.com>
 <2FB2DA46-7BED-46BA-905D-DEAA33E9E1E8@yahoo.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[googlemail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NrQht6VHdz4YYj
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Jan 9, 2023, at 11:45, Mark Millard  wrote:

> On Jan 9, 2023, at 11:13, Klaus K=C3=BCchemann =
 wrote:
>=20
>> Am 09.01.2023 um 17:21 schrieb Mark Millard :
>>> =E2=80=A6
>>> ..
>>>=20
>>> I expect the new output text was only the text after the "reset"
>>> command:
>>>=20
>>> QUOTE
>>> Waiting (max 60 seconds) for system process `vnlru' to stop... done
>>> Uptime: 1m51s
>>> END QUOTE
>>> =E2=80=A6.
>>>=20
>>> =3D=3D=3D
>>> Mark Millard
>>> marklmi at yahoo.com
>>=20
>>=20
>> Mark, I also don`t see the new expected output text=E2=80=A6
>> do you see any effect , have you tested on an RPI?,
>=20
> I've only been reading along, not testing the patches.
> (For one, my normal environment has its own patches
> involved, making for a unclean test environment if
> used.)
>=20
>> I would be very happy if I=E2=80=99m mistaken and if it would work..
>> -
>> O.K., now tested the new  Diff 114868  of D37981,
>> Also no effect to =E2=80=9Areset=E2=80=98  by an provocated early =
boot panic=E2=80=A6
>>=20
>> I think you`ll need a real hardware debugger to e.g. track the issue =
that the software debugger  can=E2=80=99t=20
>> execute shutdown_reset(NULL, howto);
>=20
> I have no access to such.
>=20
>> safely in early boot stage without calling the bcm2835_watchdog =
directly :-),
>> and you would need it anyway for board bringup issues..
>> Afaik that=E2=80=99s normal on embedded
>>=20
>> Please consider this only as a test report, not as a scientific =
statement,
>> I don`t have any knowledge of db_command.c=20


Given the BOOTTRACE(...) usage that I see, having:

kern.boottrace.enabled=3D1

in /boot/loader.conf (or set via the loader?) might
prove interesting during the reboot attempt from
the db> prompt.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Mon Jan  9 20:43: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 4NrQs40qxHz2qlG0
	for ; Mon,  9 Jan 2023 20:43:52 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130])
	(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 4NrQs30tr3z4ZTZ
	for ; Mon,  9 Jan 2023 20:43:51 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=R4b9LcZl;
	spf=pass (mx1.freebsd.org: domain of jjrushford@gmail.com designates 2607:f8b0:4864:20::130 as permitted sender) smtp.mailfrom=jjrushford@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-il1-x130.google.com with SMTP id o8so5476636ilo.1
        for ; Mon, 09 Jan 2023 12:43:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:date:message-id:subject:mime-version:content-transfer-encoding
         :from:from:to:cc:subject:date:message-id:reply-to;
        bh=FGLm38/Oz71TLgf1dogOzbVU1e1rc45fS37TjGMys3Y=;
        b=R4b9LcZlWU11qQCJPeoXecDe1gXiD4S4tK8cfklo+RJMNnKoiC6a4RcEP3/lqK6swJ
         sOrpLmyLCgOHR5NAhbLz9UdUTNmJYwZWYsiWQxRTAzARvAh6sRUfhmSkqPzk5YxicqX6
         zbXH0txegYbg2Y7VB88ruQ9aYf1p+xd8M2wRTiT+oOdQk3YaKs1iU82a0daWUpn6Dcps
         jcSIdAUZakRsWSXhjaOwuplrX0gJJWBmZfCfzqEjzZdP/QHkr2r2kdYMz0KZxUh7tBYD
         c3bTEKsfR1cbI3/EyRb+yXBWeYKWCS195XVPJLb1NiJGbzofiodVX1I+cMQycf0Bdsxp
         gXmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:date:message-id:subject:mime-version:content-transfer-encoding
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=FGLm38/Oz71TLgf1dogOzbVU1e1rc45fS37TjGMys3Y=;
        b=aXR5a/es0qBZzR24GU2Ujkatq/DybD6iqPF0/djnEi8VOEnnuZBbJpjD4wHGglSQ3b
         EYd3dZO60f7IdsMnONgtNvrt8L4QB1Ap9ceU6m+1j2t0BK+DZwTjvSLL9+i6HSwwEt4B
         9Xf0mE8v9O1N5QLcgWyOin1Yy5p3uhA6bbqZeSt21v5iT9GKP+CP7CvWkN/8WJMG3AGu
         l1FcrmfQZECRrbkV2OU9rRSvOZVOsTAEZWCjzsUkrVIvUkn7ZXCF7C1Hd+uwDalnw7xQ
         0339277gKJ0AS8e3cYk7PGZHkczXMPt5EkgY7RLx6Xm7/yksG+ehw5sL7lNxzbrD/Dsi
         V1FA==
X-Gm-Message-State: AFqh2krIjXQpYN7BakDT5A+brr5F1C0CQGNGF2BKPH3CXosUHQAjAe8A
	MqCiDbzc3wFamgAwZ3tGNr2oTyh4P7A=
X-Google-Smtp-Source: AMrXdXuaAcHdhsuv5bohvaa/AL2OdxjdspOhGgvoGZUQEX7mZgjNfaSAXL7IIjJt7u4p8rO291Yk7A==
X-Received: by 2002:a92:2c0d:0:b0:30b:e56f:f2f7 with SMTP id t13-20020a922c0d000000b0030be56ff2f7mr48826761ile.24.1673297029620;
        Mon, 09 Jan 2023 12:43:49 -0800 (PST)
Received: from smtpclient.apple ([2601:280:587f:87d0:fd8d:7a9e:180e:7182])
        by smtp.gmail.com with ESMTPSA id g20-20020a92c7d4000000b0030c661606eesm3070627ilk.63.2023.01.09.12.43.48
        for 
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 09 Jan 2023 12:43:49 -0800 (PST)
From: John Rushford 
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.200.110.1.12\))
Subject: Pi 4 serial ports
Message-Id: 
Date: Mon, 9 Jan 2023 13:43:37 -0700
To: "freebsd-arm@freebsd.org" 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
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)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::130:from];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NrQs30tr3z4ZTZ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Greetings,

I=E2=80=99m running FreeBSD 13.1-RELEASE on a raspberry pi 4b rev 1.4.  =
The pi 4 has 4 UART ports available but as far as I can tell, FreeBSD =
13.1 only supports 1 of them.
I would like to use one of the other UART ports to wire an adafruit GPS =
breakout too.  I tried using the UART0 port but when I wire the GPS =
breakout to it,=20
I run into boot issues with u-boot and console logging.  I know that in =
other OS=E2=80=99s such as raspian or ubuntu, you are able to enable the =
additional UARTS in config.txt.
Thinking that FreeBSD might support this I tried adding =
=E2=80=9Cdtoverlay=3Duartx=E2=80=9D where x is 0 to 3 but I=E2=80=99m =
not seeing in any kernel logging that these ports were enabled and
I don=E2=80=99t see any additional ttyu=E2=80=99s in the dev tree.

So my question, does FreeBSD support these additional UARTS and if so, =
how do I enable them so that I may use one for the GPS breakout?

Thanks
John=

From nobody Tue Jan 10 02:15: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 4NrZCX5PtSz2p2c7
	for ; Tue, 10 Jan 2023 02:15:20 +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 4NrZCW01xjz3kbD
	for ; Tue, 10 Jan 2023 02:15:18 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RpdYyGhU;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 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=1673316916; bh=1LrSn+SV5ff4EJa7VnKJEH0IGaxl+lw1N5jE96z2OvM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RpdYyGhUVNvLWfze7TCmma/Ga+TP3QJCQUR8Wj0DNtJs31eOyPn+Osz2JdG+dIXmxlAlCYueKsh2ulCLOnQXAH7DsYlg+uuyoIHdQxHsv7kxd1xCN8b0FqrxQWlYTnQy/kADjXKyh4qeTfZtnlVxrKCqyGP63b7W854uF3tzgHLHbqNeC6CmoVvhj7eFqTzOk2RSgFlmKBjBLXNElUwKD+c4SxZaDEamFqOX8kcC/bc07rYgW9a6TEjW+1vL4k/RIellSv+1TqF8+CaidedSPCJgga+a/8qwl+Lm/E7AGDRGWpgfTFSE/pK2JY1U6cN1UFptLKj4ktW6I1y3S6l++A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673316916; bh=hJ/X4P+cgf9koNzdLAbrHkPeubBJz/KJrri1LxDIAVk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=S5Zbii+3IzYl8TtW8exWHEWuRqEkWbbzCj4+J/EkdI91mVYaj5XDSGcg3CfHU3L4Zp/2uEy5VKk29RtOML60x9LOE9v9AM7CSvZFh2oshIyfCuLhlrloRMOs7zul/gkbfyyu9r474Mohs1J0H7+E+LV2XG0ak9uCv4oPrCTtsI6GAWDGNanj1JpR3Dk27eKVJvn1LuxTqNQIDCiehhso+KvgCAjmZj4m1Psd8R6DivTitPbTYHXhblHHytYRIvyeu+/PRecJzwt/WDBFia7j+iamKyPPZBDuz3N+gVLnBio7eXgZVZ2T0k/0XHFwzJ09Uxk30vBEo2feiwpwvk2EYw==
X-YMail-OSG: TjyFX7YVM1nakdw92r9GWxDXCihojGIqO71Jk8XsdGteHx7VfoKPURk67R6GvCr
 RDuCXDTvG3IqhZF.HC4EKklBTUeXFzC.NGKaoC.G0DMTsBhApa4beoGHBau_C3KHhoJif2YI1ee7
 FbHJ0yeyT8kkx15U1nDxi7n6vQNh6yoWsDLrlSeo7Yshia6arX0T2KjVX4gW5H1WdFgvSKkKWbcs
 iPoPndQtWnXDLHkEWtLx.VDR7iv0DSiwkl3cOW_xJttLUCQV4z1W74x_9xYcYqzwUyQVmrweG3hV
 2cZ4QaUwiiHPtnM6JeibdqRNNGOchOE8bQ9NqDDsgO077aMEjuZ_xl_NxTT1C3zWeUKVE3aWIuRn
 PtYk5jJgeU7qyzwCFqpnGfgOccQpmAqZoYlkpzPGHrvkSXRlCCMzxbEj9SXOMwvGBg9gVlmX2b8J
 ADGIlukqx9.iqnW6aCzocPTb1tLrknnkzY3bu9q4LGO70jD_GMCxi6allfeT3olWzsr6hKH4OYkn
 P9KRUkwjwk.__h97M39mWTpASZyEQEXCiI3JVtpqnN5rxlhtioLzWECxo_Z3zHHjU02XCqBZkyGy
 2q2O548_Ef.rRu1jUXuHMkhpC05Xx07My.N9P7KK.jN6MBfHTi3AQJXBjDktJ_NWlxk10s7Q6SJv
 BlV2vEhALtrH46pxV_BmKkYyAO9YAumXhGI8lsYXM832aXtb0_likN.L5S2it7d56Rq2aRgGYUtX
 r4NEFPml5kF71PV.peCFNoqRz1h16Pzk83RNm.sHNrR_KwiY_SNqpIcoou2TonMj5aBNtTzc235.
 ze2Xw3UPG9F2tIK_6qMODoydnJchHGuoa2FTPYeNS82ZXnei69ToNYnCGn4W_uvAzlOfhIJ9bD8r
 iCF7w4aOF9nJ6_EmkkmWihJOMnHnAeKpq9iCRCm2S907oP_vZcLxEqavzOAHFfE8YUeshXPFNco_
 G.4EJLvfwK.IbrJ4p3ZTMpckXo1ErR9g4dnMaIhqgjaUU7_oxhPd33hV9sGc6KoAbMm2sHlQ8KJc
 h5NICyLbpgyA8aV5_KLaO99UQK5pFyzHmbiKIIYcp.epNO3S3o2UD4KeZ6DKxzNzKecHBAuK6YsI
 l3H099xDbO0pPkyb5Qq3Fd7gwwfaeWOydTUexN_EkX2j43ZkudfNcZu9NdFS2cd.kR9ShbkBInrB
 iq0IQNDqwTZow_3tnpRz5PTK_Z820DRKD2lNowASDje6d_CpkuuIJp_dwV7NKQuChr4PI1S04N5v
 J6XWcMYktPJk1x7xSw18KuszTMtDpGvyunVgl1ZSxzfl21Oom5qVv7mEJEi4zmhVLPUwmcxJ2cdg
 tayYk62pbyun.Djoxvf8tV51rq701DHv9rZAyIzj1NlGmcQt52RXb_0V3UPF4Ls7N43DIKoI8kn8
 dOv2ht5RzWozSPP1uldb6oGxxO4tyYUehcQ1o14534qCRbg5P4f.F9Khafwnc2yUYPy6zLYBVqCV
 PwtvIRZK2YeZ9SicqV0P8uizXN5xjUc70XfsEt74gCNrA22bv92Givy8TrJAOmPzOAha5DaK2gZT
 lDhB5bcicKlqSCMz8JIF2wncIqtohmJ5I8T_sY8_0GZA50.oLyuWV7bzGFSH1uMMTomQ5HYG7XDm
 eMY_Yi85WJCv0MbXzjapBRolkIxxwEhIE27IRuEshbJeVb67hg3fqIu9SeawjC0sBAYcHNU7Sii.
 YZojcU24YzQzR4E9_0dsvQFQQbnfjseDYBqoEzyctb5Vu7PjJoZOO3qt5nz.e0N1qoDDfjTJ5xeq
 wyFCDo1VTBC97b4fLhc4Xy.IM_I3kZtnLnSZx66NMi0M3NSPXlBVmkL1vUePouLCnCIQLLFujXdT
 r7d32n98xcGNLHYTKMJU9hQggqfUTIqbMe6UHLd1R97BZMcMM860MBS3od0uEhrOfgIuMA_6sbu5
 icO9pfA6HktkVemsHw04jEltdMEWpnVLWccpHBABT6hc_8cSD6YS875QqlDzkdkrj52skyix6Skc
 dESRj32T8RdqBvDBfw6wxy2307h2PPBNRmZAxVTspVMdtVfllPjNxw3MY9sNcPneAch7BDyCdR5p
 mQXLQvcJBvpaFuSZKBXcKhOrArmdxtDA8N9L6lc9XNWoN0JaatVJ_ML6XJdZEnnkuEk4vLxeq_0N
 HWypXMIhkm14mEK9H7ki1gU80GN8srQOHMrpA0RJWQiknb6mIWSHeGbdpS7dTjmQx5PDwQj.xFUb
 lOfp1qyUGCYQXQO3QY878quVhe0rLBMM1cejJz6n8eZwuthpp8DyefxGj4t1dumqtZCFNjC9qlg-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Jan 2023 02:15:16 +0000
Received: by hermes--production-bf1-5458f64d4-s52fb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d209166b3e2311b2bb49937a61729489;
          Tue, 10 Jan 2023 02:15:14 +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.300.101.1.3\))
Subject: FreeBSD and CM4: use pftf/RPi4 (the EDK2 implementation)?
From: Mark Millard 
In-Reply-To: <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
Date: Mon, 9 Jan 2023 18:15:02 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: 7bit
Message-Id: <56924C76-58FE-4164-8832-441665E3C11E@yahoo.com>
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
 
 <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-2.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	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];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[googlemail.com];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]
X-Rspamd-Queue-Id: 4NrZCW01xjz3kbD
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

You may have an alternative for the CM4, not that I know the
details of the status.

The firmware from https://github.com/pftf/RPi4/releases/tag/v1.34

includes bcm2711-rpi-cm4.dtb --and they only bother to include
.dtb files for what they support in EDK2. (But there is still
the questions of just what the support spans.)

So, if it turned out that UEFI/ACPI from EDK2 would
happen to be useful, it might avoid incomplete/inaccurate
Device Tree handling for the CM4 in teh FreeBSD kernel,
at least for some issues.

But there is also the possibility of incomplete/inaccurate
UEFI/ACPI handling in FreeBSD's kernel in ways that would
be important to you. But it is separate code in the FreeBSD
kernel generally so what works vs. not may well be different
from Device Tree based booting.

I'll note that the crash that I worked out how to avoid is
Device Tree boot-style specific. Any crash for UEFI/ACPI
would be separate, if any exists.

But if you try UEFI/DeviceTree then the firmware vintage
issue might be involved in that case.

Just something to possibly explore for/with your CM4.

===
Mark Millard
marklmi at yahoo.com


From nobody Tue Jan 10 03:54:38 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 4NrcQQ2p6Wz2pFjY
	for ; Tue, 10 Jan 2023 03:54:54 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135])
	(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 4NrcQP2CGjz3qyW
	for ; Tue, 10 Jan 2023 03:54:53 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=WJBY2zJR;
	spf=pass (mx1.freebsd.org: domain of jjrushford@gmail.com designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=jjrushford@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-il1-x135.google.com with SMTP id h26so5880577ila.11
        for ; Mon, 09 Jan 2023 19:54:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=qnGPLZ0qjFT6utRQgc6O4vD29RAtMwy8FEAuXjX0w/Q=;
        b=WJBY2zJRSJBjCDF+HUhFosbLaEgU69DME9s5/nolknDh/h1Pmx2DiBp2KNSZok+nzb
         ZpjFGBmJV4DPiyH2Ha7SjM/cBZpQx414Z7h0+iUS22OdXtComrvS8SNXRiH+a8pRB/Tf
         LFQRJvDBhg/GMzimS7XxpIfBDZ+YrpKlsEnoMA4Xa4oF26RRx1bh/anufER8C00a0Zl5
         1aLtzjyHe9V2iy87oAB9qsNJ8euksra+5REhzismPVDCegh5z/l8+KEl44ecK3tuZ2EC
         aJ5lP+bpWS1pbsrafZEUW6MJQ8dZWqRjpIpKga6+jFOkgn4frlCSvdaf+L2Vo3w4TWpP
         ng/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=qnGPLZ0qjFT6utRQgc6O4vD29RAtMwy8FEAuXjX0w/Q=;
        b=PMTH1d3fyuox9u5alcX/mDrKmAAVMLb0xWr24P7j/u8X8vPo44BUANk5sZBCS3sI48
         Ysnvs86iKBBAUu/T7lPmYYXoewad0mDO+JOOOTWdGFUhRoLnD06vtd3zLJ1U+vMVsf0N
         jjry8LUYnYWRT1CtmZi+XbUaWer+hMeFfpabD9dw3LtiUSQxLnHIvDf3f8iU4jPFjjBC
         28RbIFSQxtSHU89sDOCa+JmhyCVO80pYeUzy2Ejf2vd5DZs+15nW4Jr9kL8EsRIfLKDq
         UVT43ued4PxbN3Yu8dsAclDb+Lm3nUmc2DoPQg56h+1YFncfsNGRyw21VflhHJNSaZ23
         RTsg==
X-Gm-Message-State: AFqh2krXTqYq+4DJOIER2o7HLrdAbK9+tvikA+wbZB/MQDjOOXHBqbA3
	wyf6arP3ydxirnsf0S+0WRpMbVZqBfc=
X-Google-Smtp-Source: AMrXdXvjasi21ZHIFyjcNQ5bGTXnTiFa9288iXFAQDRJ6uPg7j4QXH1BgyxVwQt/PpvvDsonwakG3Q==
X-Received: by 2002:a92:cc92:0:b0:2ff:f702:e446 with SMTP id x18-20020a92cc92000000b002fff702e446mr42083333ilo.13.1673322891095;
        Mon, 09 Jan 2023 19:54:51 -0800 (PST)
Received: from smtpclient.apple ([2601:280:587f:87d0:fd8d:7a9e:180e:7182])
        by smtp.gmail.com with ESMTPSA id r10-20020a92d44a000000b0030314a7f039sm2740159ilm.10.2023.01.09.19.54.50
        for 
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 09 Jan 2023 19:54:50 -0800 (PST)
From: John Rushford 
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.200.110.1.12\))
Subject: Re: Pi 4 serial ports
Date: Mon, 9 Jan 2023 20:54:38 -0700
References: 
To: "freebsd-arm@freebsd.org" 
In-Reply-To: 
Message-Id: <3225E237-1F0E-4FA2-92C0-D683B8114F64@gmail.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
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)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]
X-Rspamd-Queue-Id: 4NrcQP2CGjz3qyW
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is all new to me and after some digging, I=E2=80=99m currently =
trying to put together a rk3328-uart2.dtso that I can compile to an =
overlay file so as to enable uart2

John

> On Jan 9, 2023, at 1:43 PM, John Rushford  =
wrote:
>=20
> Greetings,
>=20
> I=E2=80=99m running FreeBSD 13.1-RELEASE on a raspberry pi 4b rev 1.4. =
 The pi 4 has 4 UART ports available but as far as I can tell, FreeBSD =
13.1 only supports 1 of them.
> I would like to use one of the other UART ports to wire an adafruit =
GPS breakout too.  I tried using the UART0 port but when I wire the GPS =
breakout to it,=20
> I run into boot issues with u-boot and console logging.  I know that =
in other OS=E2=80=99s such as raspian or ubuntu, you are able to enable =
the additional UARTS in config.txt.
> Thinking that FreeBSD might support this I tried adding =
=E2=80=9Cdtoverlay=3Duartx=E2=80=9D where x is 0 to 3 but I=E2=80=99m =
not seeing in any kernel logging that these ports were enabled and
> I don=E2=80=99t see any additional ttyu=E2=80=99s in the dev tree.
>=20
> So my question, does FreeBSD support these additional UARTS and if so, =
how do I enable them so that I may use one for the GPS breakout?
>=20
> Thanks
> John


From nobody Tue Jan 10 04: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 4NrddP5c8Kz2pMb1
	for ; Tue, 10 Jan 2023 04:49:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4NrddP2zV2z3w09
	for ; Tue, 10 Jan 2023 04:49:29 +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=1673326167; bh=HZSmQQ1x52m8PPgsxDY1++/IyMEh7tPKyRZXWpZFBTo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RhqUms0LA6KDXUkGTryRey10I2FQLPNWi90EsUu1d97RmUxSwAkXv2AykGnRVayZ2ddoL96Nv7CF6lfD+UqzgztRdrtK3qf8ywFJg1li6Qz+ynamhab+ieXQC8nkZo2SxfeT1BJS855xgSBC2IFQ2b+Mcw8lw0PzpcXGNY5EzLiFtlvvQRA7EGdUrhmpnCPlCBCQ65eT1E2Y6mhRR5TmsPCBouMUL8VRX9VfiOh/K9cLBDR4zxmA94X6eW3MXyIGamIsz5MfURE0qdrmqSmTeA8pNeB+uOAiOeEvCiI0diFdPcKTWCgfFcoBYryBCBqNepd2q4sxWoi2dSM/DSgHpg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673326167; bh=bxK8YTdJC2bO2t33QMYPQS02FEYVFx3IB2bxfAq1lEp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=na9g6b28rR2nHRBQ9FppLgt9m0OvmzJYRtfBZEoV3iZVeDcPubSM676zKtWBvTnR4WpJaTgeBk85xuTxH9qKhujjrpGHhyjYGwDTtC2XV8TKo/0sh2N0dIOsneFwAOnC41DUCG17q9QCuYxjww8bvXiUCZ1AuFX45TBXy8y9vnpI11VzXiuDLPf1cBBRlAkztIZMpYyVXu58MqjWhyCE4/uh8755OUANZ4ny49rasO3k2WNhTi9p3nN2ml4XURfqzA5Sd1p7d+F7x5AfgVBxkJ6ihXS4nITMrcpr+sS5A4aG7vkg0nPMRJAi2MnKr+zBWlkt3aG+fXTD6yWjF4gSEw==
X-YMail-OSG: sklAPpUVM1kit9e4JnUhwElg0r27HkN9vL7ewjV_zDixc_8Z1.0BwSWD59I4_l1
 niys0Zczs6a4HwOvPXNh63VSpcIDCh_hVbZWJs7VJ3vu4OWwHuEge7XRqMIYORoF8gd8031YvEbe
 wS9kziLnfIGftrHL7XBCLzv22JmOJBjZr2PIzUTMQKOXuexUtuRMf6eoj3wLM35XFOnkngM8SSqD
 iJixB0SMaaqTkdSL1MI6G6SuL_Z0o3PkDKaR_2PVnNQtPpZqmgGPvCVBUsARTqVeGlcKTV81vPnd
 ph9Jm0kBg75KB2rRllsRVo8Ho4APgyv9cbM6CTYxtTTtU9OIf0U9lwRYqouGtyi9K9yySxDyoqLL
 NOtGkj8cfqC2AVrxq2SYL2iR8KfRvRVE9SDR_TT_1S07PZrAbnfNbgIkDXpHd2FQAM75bpNkeHnR
 UduP8DSNlQGLyorR4z0RPTQ1laVLe5S8KOOi.HivzN.GxVlPnnSE.HbeWEu6MMXqKEKUJ40DSk4g
 1dYVPJ8sdWPsNZKVkBDdUoD5r06gAwX8ZBwW1gh.iZQz6F16s1Nl2pTCtNx1e4Oeoc78XpZa2hlY
 rrmikIgtHPaKacOQD8Lbwg2TVOERiIYOD1NROBrxBkaSTSD2eDhVvi7MpI9ZI6pMvpjJlvSCEp7Z
 HicxIpoS7wdrWfS_QckNFc0rdshUJeO34HHRcX8DITVv8wr2mhLyPhjOmR4eFfXJiKhAmMkeprld
 7hFuIdCRmqH3q8M6szDEA6EQZ25aSY2bEC5qI94WjJeG12Y4K5RN0a_yLoQfQQBi8nZJF.t2SEsj
 lEYI5WJzLV10GUE10c.fLu0ToL1Sbpmyo7VOTm_695LB9vWiBvNYbjxEoCSUYBefr0kYRWHajEQh
 ULslJZMd3r6RDTAcdR4E4hHoZoiM3PgfVjZU1qvFVjwS6c3gS51M9DF6iN50T5TZ_SklpWvZeKFh
 BIZc83BoEWcPO2rhH0vkIXtUF4XBu6Ystql0m_HItTdnA3_OQvFXoH2TSjCUm8_oIrONcHBcjxYZ
 5kS3_KyB2B1lircKADjNzW_5a2N6qfHx30ywPq6uqEk.b94sN.B3L.LEpxjBSAY0mrdR4rjoHjFY
 ofMTTThP7nO9QbfSuzwiEdwr7AkG4ad.fuDT21hC_2DcDKXA0l5dof4WttjuC46566d0MZgPO9zF
 re8C.uxX6HwI.SsjUolSpmdvLgRCPDCjF.5NTJDzzSReWmmAjlMvhrH049GgdZeUhK7XT7J0aXBg
 8uFqmKdM9FZyTEY9QA3zSG4BFGphvfV1dYqXhBGb1nCnWFYmgU8HuMcMSXwFt4JovTXbECjkzhDb
 EvYQAP7TpTmboisXANvpB7tSMt7ezgAiQ0Rb69YSV7e6N8DTm5ZZtnCoRQvyo3MR6_yENfT_avIp
 DXDvQdCciAjZX.4jF9TGiLuAdWnbE6jWCjn79h2ObWP3raLXCTw97f6HIPMG0_HQkjfu.CLmvP0k
 .v.gBxcPGZt6teZVqzuruGEL7gSPYQxmKfviNBgF33kDXk0MrqWY7UYpuUvK2e5iCn_EAEtl9xxW
 Rqhvaj8ZLgb4iuvDD296u7cj_eMEfjvsMDMuyd1l.0T0RJlPSR9Pu9NEg4UpCnSBKzG8d8v15v7p
 jHuY0Wv8eQC.2GXDONGucDnuN9NB5j2L0XrGG46jZCBltlb5nl4dvpJT3bHUZsVh_CjZMBNjsjr9
 iYT6F8hg29WFJg94KEF80U7jEVW.bgyznijwReuqgMFWhz_OkqAdcUNUj2OdeDSc_X_zTP9wBBD0
 B0xKMtvdZleEHR5lQ5WH8sePjvubiMfVh.kSEnv32CE.zz6G1dC94kpQNoc0CeXcJ8lSe_4x7esL
 ao_cucSAgrQdjVuVMYKFuEOnD6IDxYMXXCm0WNdmZksDlxpHXgq5sgxN9a3sLzxkGh3BduBhJ8A1
 kkloA6tgsGOtqMZY85a1wbXo1_jBanmaT0NcHKMcGUHH1RVavDauX_UzTkvIPAIHZAOHTPavcW8z
 DHnuPdc7H0zP2TNa4HAyghJjI41Q6t69iYnpEJDl8.FN3nG3oTm4yZgWAgB37GYBIYu.dYIlz3t9
 p7qwCqpDoG84Y.6tGaAJXSdlp5ElP6c9GfEwpcxhAGjW8Ur_5dLQmp3VFiED3tLLFvByEzaWvL7N
 2xAUoVCIRRAZ.6GzDSzXvLbvXLOAWr6qbqlJFtWFcnqcuIsKBbDGfx.pOKSJlJhkYls.g5yqay2A
 C0ZQQBKHcBOKtPOc6lzwXJC3bP1OroykPFbLnmJV2_qW8wam3hk.MOhb99O0a_kNV.1re0DPU
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Jan 2023 04:49:27 +0000
Received: by hermes--production-ne1-7b69748c4d-drrwg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7315653d39ee2bab446cf115d8426040;
          Tue, 10 Jan 2023 04:49:22 +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.300.101.1.3\))
Subject: Re: Pi 4 serial ports
From: Mark Millard 
In-Reply-To: <3225E237-1F0E-4FA2-92C0-D683B8114F64@gmail.com>
Date: Mon, 9 Jan 2023 20:49:10 -0800
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <3225E237-1F0E-4FA2-92C0-D683B8114F64@gmail.com>
To: John Rushford 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NrddP2zV2z3w09
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 9, 2023, at 19:54, John Rushford  wrote:

> This is all new to me and after some digging, I=E2=80=99m currently =
trying to put together a rk3328-uart2.dtso that I can compile to an =
overlay file so as to enable uart2

I'm confused. A rk3328 is a rockchip part not involved in/for
RPi*'s (broadcom parts). Examples of .dtb files for products
using the rk3328 parts are:

/boot/efi/dtb/rockchip/rk3328-rock64.dtb
/boot/efi/dtb/rockchip/rk3328-nanopi-r2s.dtb
/boot/efi/dtb/rockchip/rk3328-rock-pi-e.dtb

.dtbo files for a rk3328 are not usable for RPi*'s
generally (ever?).

Are you now using a rk3328 based part instead of a
RPi* ?

> John
>=20
>> On Jan 9, 2023, at 1:43 PM, John Rushford  =
wrote:
>>=20
>> Greetings,
>>=20
>> I=E2=80=99m running FreeBSD 13.1-RELEASE on a raspberry pi 4b rev =
1.4.  The pi 4 has 4 UART ports available but as far as I can tell, =
FreeBSD 13.1 only supports 1 of them.
>> I would like to use one of the other UART ports to wire an adafruit =
GPS breakout too.  I tried using the UART0 port but when I wire the GPS =
breakout to it,=20
>> I run into boot issues with u-boot and console logging.  I know that =
in other OS=E2=80=99s such as raspian or ubuntu, you are able to enable =
the additional UARTS in config.txt.
>> Thinking that FreeBSD might support this I tried adding =
=E2=80=9Cdtoverlay=3Duartx=E2=80=9D where x is 0 to 3 but I=E2=80=99m =
not seeing in any kernel logging that these ports were enabled and
>> I don=E2=80=99t see any additional ttyu=E2=80=99s in the dev tree.
>>=20
>> So my question, does FreeBSD support these additional UARTS and if =
so, how do I enable them so that I may use one for the GPS breakout?
>>=20
>> Thanks
>> John


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Tue Jan 10 07:21:42 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 4Nrj1H10Psz2qwj7
	for ; Tue, 10 Jan 2023 07:21:55 +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 4Nrj1G3HL8z4D2S;
	Tue, 10 Jan 2023 07:21:53 +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=1673335306;
	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=Q5rknkwPH2kt7anoxIkVQrMNG2gOSZl4ZS28yIZC2LA=;
	b=YHRH+1OEGkWx2OwD3+NOfPipNccC66eWYQ5eH5WhNNNWg6dsESpuiYeUd5llQzU0VfC6xR
	xMzPhzj0PuZmC1KCvabzbY7YXqNwIu/hj/MPd5eokbJ1y4G7kpMMphmXN6oElbE3ky9ARn
	XM7hV2sc077ijV+1bSqoclGRF86Z35M=
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 9dff67c3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 10 Jan 2023 07:21:46 +0000 (UTC)
Date: Tue, 10 Jan 2023 08:21:42 +0100
From: Emmanuel Vadot 
To: mike@karels.net
Cc: freebsd-arm@freebsd.org, oh@freebsd.org
Subject: Re: BeagleBone Black does not boot -current (DTB incompatibility?)
Message-Id: <20230110082142.447b78bf587edbda8355b0a4@bidouilliste.com>
In-Reply-To: <202301091649.309GnGi1055259@mail.karels.net>
References: <202301091649.309GnGi1055259@mail.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: 4Nrj1G3HL8z4D2S
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


 Hi Mike,

On Mon, 09 Jan 2023 10:49:16 -0600
Mike Karels  wrote:

> The last couple of snapshots of -current fail to boot on BeagleBone
> Black (armv7 GENERICSD).  I have no idea how long this has been failing.
> (13.1 runs.)
> 
> It appears that a malloc from ti_sysc_attach or ti_sysc_attach_clocks
> is passing a size of 0, which maybe could happen if the FDT has a "clocks"
> node but no clocks are found.  The console output including backtrace is
> below.
> 
> I replaced the dtb directory with the one from 13.1, and the system boots
> and seems to run.  I don't know my way around the armv7 DTS files, but
> I'm happy to investigate if someone can point me in the right direction.
> 
> 		Mike
> 
> ...
> No PSCI/SMCCC call function found
> Texas Instruments AM335x Processor, Revision ES2.1
> arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled.
> random: entropy device external interface
> kbd0 at kbdmux0
> ofwbus0: 
> ti_sysc0:  on ofwbus0
> panic: Assertion size > 0 failed at /usr/src/sys/kern/subr_vmem.c:1332
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> 	 pc = 0xc05d793c  lr = 0xc007a9ec (db_trace_self_wrapper+0x30)
> 	 sp = 0xc0f14a98  fp = 0xc0f14bb0
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> 	 pc = 0xc007a9ec  lr = 0xc02e8880 (vpanic+0x140)
> 	 sp = 0xc0f14bb8  fp = 0xc0f14bd8
> 	 r4 = 0x00000100  r5 = 0x00000000
> 	 r6 = 0xc07395ef  r7 = 0xc0afb960
> vpanic() at vpanic+0x140
> 	 pc = 0xc02e8880  lr = 0xc02e8660 (dump_savectx)
> 	 sp = 0xc0f14be0  fp = 0xc0f14be4
> 	 r4 = 0x00000000  r5 = 0xc20e0000
> 	 r6 = 0x00000000  r7 = 0xc0f14c50
> 	 r8 = 0xc0b6db00  r9 = 0x00000002
> 	r10 = 0xc0f14c2c
> dump_savectx() at dump_savectx
> 	 pc = 0xc02e8660  lr = 0xc0358e14 (vmem_xalloc)
> 	 sp = 0xc0f14bec  fp = 0xc0f14c20
> vmem_xalloc() at vmem_xalloc
> 	 pc = 0xc0358e14  lr = 0xc059dae4 (kmem_malloc_domainset+0x9c)
> 	 sp = 0xc0f14c28  fp = 0xc0f14c70
> 	 r4 = 0xc0048cf4  r5 = 0xc0e0d108
> 	 r6 = 0xc0f14c18  r7 = 0x00000000
> 	 r8 = 0xc20e0000  r9 = 0x00000000
> 	r10 = 0xc0f14c50
> kmem_malloc_domainset() at kmem_malloc_domainset+0x9c
> 	 pc = 0xc059dae4  lr = 0xc02c1b3c (malloc_large+0x2c)
> 	 sp = 0xc0f14c78  fp = 0xc0f14c88
> 	 r4 = 0xc08f5864  r5 = 0x00000dbc
> 	 r6 = 0x00000000  r7 = 0x00000002
> 	 r8 = 0x00000dbc  r9 = 0xc07a4919
> 	r10 = 0xc27506c0
> malloc_large() at malloc_large+0x2c
> 	 pc = 0xc02c1b3c  lr = 0xc06ad75c (ti_sysc_attach+0x19c)
> 	 sp = 0xc0f14c90  fp = 0xc0f14cd0
> 	 r4 = 0xd00d3e00  r5 = 0x00000dbc
> 	 r6 = 0xffffffff  r7 = 0xd00d3e28
> ti_sysc_attach() at ti_sysc_attach+0x19c
> 	 pc = 0xc06ad75c  lr = 0xc032873c (device_attach+0x4f0)
> 	 sp = 0xc0f14cd8  fp = 0xc0f14d20
> 	 r4 = 0xc2757d80  r5 = 0xc2758200
> 	 r6 = 0x2eb77a5c  r7 = 0x00000000
> 	 r8 = 0xc0b72564  r9 = 0xc078651d
> 	r10 = 0xc27506c0
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032873c  lr = 0xc03281b0 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14d28  fp = 0xc0f14d40
> 	 r4 = 0xc2757d80  r5 = 0xc276da80
> 	 r6 = 0x5e4a6f28  r7 = 0xffffffff
> 	 r8 = 0x00000000  r9 = 0x00000000
> 	r10 = 0xc27508e0
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc03281b0  lr = 0xc0329bb8 (bus_generic_attach+0x1c)
> 	 sp = 0xc0f14d48  fp = 0xc0f14d50
> 	 r4 = 0xc2757d80  r5 = 0x00000000
> 	 r6 = 0xc0f14d60 r10 = 0xc27508e0
> bus_generic_attach() at bus_generic_attach+0x1c
> 	 pc = 0xc0329bb8  lr = 0xc00e4ce0 (ofwbus_attach+0x138)
> 	 sp = 0xc0f14d58  fp = 0xc0f14d90
> 	 r4 = 0xc2758200 r10 = 0xc27508e0
> ofwbus_attach() at ofwbus_attach+0x138
> 	 pc = 0xc00e4ce0  lr = 0xc032873c (device_attach+0x4f0)
> 	 sp = 0xc0f14d98  fp = 0xc0f14de0
> 	 r4 = 0xc2758200  r5 = 0xc2758300
> 	 r6 = 0x2e0a372a  r7 = 0x00000000
> 	 r8 = 0xc0b72564  r9 = 0xc078651d
> device_attach() at device_attach+0x4f0
> 	 pc = 0xc032873c  lr = 0xc03281b0 (device_probe_and_attach+0x8c)
> 	 sp = 0xc0f14de8  fp = 0xc0f14e00
> 	 r4 = 0xc2758200  r5 = 0xc276da80
> 	 r6 = 0x5e4a6f28  r7 = 0x00000000
> 	 r8 = 0xc0b094ac  r9 = 0xc0b094b0
> 	r10 = 0xc0aeb014
> device_probe_and_attach() at device_probe_and_attach+0x8c
> 	 pc = 0xc03281b0  lr = 0xc032a62c (bus_generic_new_pass+0xb4)
> 	 sp = 0xc0f14e08  fp = 0xc0f14e20
> 	 r4 = 0xc2758200  r5 = 0xc08eb898
> 	 r6 = 0xc08c602c r10 = 0xc0aeb014
> bus_generic_new_pass() at bus_generic_new_pass+0xb4
> 	 pc = 0xc032a62c  lr = 0xc032a678 (bus_generic_new_pass+0x100)
> 	 sp = 0xc0f14e28  fp = 0xc0f14e40
> 	 r4 = 0xc2758300  r5 = 0xc08eb898
> 	 r6 = 0xc2759680  r7 = 0x00000000
> 	 r8 = 0xc0b094ac r10 = 0xc0aeb014
> bus_generic_new_pass() at bus_generic_new_pass+0x100
> 	 pc = 0xc032a678  lr = 0xc03256b8 (bus_set_pass+0x54)
> 	 sp = 0xc0f14e48  fp = 0xc0f14e60
> 	 r4 = 0x7fffffff  r5 = 0xc08eb898
> 	 r6 = 0xc2759680  r7 = 0xc274f6c0
> 	 r8 = 0xc0b094ac r10 = 0xc0aeb014
> bus_set_pass() at bus_set_pass+0x54
> 	 pc = 0xc03256b8  lr = 0xc0271788 (mi_startup+0x2b0)
> 	 sp = 0xc0f14e68  fp = 0xc0f14e90
> 	 r4 = 0xc0aeb018  r5 = 0x0fffffff
> 	 r6 = 0xc27a3348  r7 = 0xc08bf85c
> 	 r8 = 0x00000000  r9 = 0x03800000
> mi_startup() at mi_startup+0x2b0
> 	 pc = 0xc0271788  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> 	 r4 = 0xc0000480  r5 = 0xc0ba8000
> 	 r6 = 0x00000005  r7 = 0x00c52078
> 	 r8 = 0xc0e25000  r9 = 0x9cf00168
> 	r10 = 0x00000000
> btext() at btext+0x144
> 	 pc = 0xc0000344  lr = 0xc0000344 (btext+0x144)
> 	 sp = 0xc0f14e98  fp = 0x00000000
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
> 

 Unfortunatly TI is very good at breaking DTB compatibility at each
Linux update.
 It's been a while (maybe 4-5 years) since we've had breakage at each
update because they just don't care about downstream users.
 Some times it's easy to fix (just changing a compatible) but most of
the time they change so much that we require some new driver or other
things like that.
 CC Oskar who's been fixing some of the stuff.

 Cheers,

-- 
Emmanuel Vadot  

From nobody Tue Jan 10 07:35: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 4NrjJp5rvdz2qyG8
	for ; Tue, 10 Jan 2023 07:35:22 +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 4NrjJp3qbhz4F4X
	for ; Tue, 10 Jan 2023 07:35:22 +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=1673336121;
	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=AtjK3JKhotWv9iqOci8TyV7QOnoc48ACDYEYdCFnKNg=;
	b=dNKCHH+qUn5xWZJT/l3lIp8CROrKMbG3pEGQQrNTcz2io4qWHglguvMBRJgjH4LXobwss6
	R1xBS0Ce0+6fk6L0zMa0oIH3IT17cSpziKT+zPX89IDAABrfTDLoS607+/+2Bg6w0Dinfq
	doLKl+zqQIjJBLQhyV9lEy7SUOfYIIc=
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 1bfcfff8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 10 Jan 2023 07:35:20 +0000 (UTC)
Date: Tue, 10 Jan 2023 08:35:20 +0100
From: Emmanuel Vadot 
To: John Rushford 
Cc: "freebsd-arm@freebsd.org" 
Subject: Re: Pi 4 serial ports
Message-Id: <20230110083520.4b284ec89da2c7cd8a1c8fa7@bidouilliste.com>
In-Reply-To: 
References: 
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-Rspamd-Queue-Id: 4NrjJp3qbhz4F4X
X-Spamd-Bar: ----
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]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


 Hi John,

On Mon, 9 Jan 2023 13:43:37 -0700
John Rushford  wrote:

> Greetings,
>=20
> I?m running FreeBSD 13.1-RELEASE on a raspberry pi 4b rev 1.4.  The pi 4 =
has 4 UART ports available but as far as I can tell, FreeBSD 13.1 only supp=
orts 1 of them.
> I would like to use one of the other UART ports to wire an adafruit GPS b=
reakout too.  I tried using the UART0 port but when I wire the GPS breakout=
 to it,=20
> I run into boot issues with u-boot and console logging.  I know that in o=
ther OS?s such as raspian or ubuntu, you are able to enable the additional =
UARTS in config.txt.
> Thinking that FreeBSD might support this I tried adding ?dtoverlay=3Duart=
x? where x is 0 to 3 but I?m not seeing in any kernel logging that these po=
rts were enabled and
> I don?t see any additional ttyu?s in the dev tree.
>=20
> So my question, does FreeBSD support these additional UARTS and if so, ho=
w do I enable them so that I may use one for the GPS breakout?
>=20
> Thanks
> John

 In the rpi-firmware package there is some uartXX.dtbo
 By looking at them those overlays are there for enabling the other
uart port.
 Just put the ones you want to use on the FAT partition of your sdcard
in the /overlays/ directory and add in config.txt "dtoverlay=3DuartXXX"

 Cheers,

--=20
Emmanuel Vadot  

From nobody Tue Jan 10 09:49: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 4NrmHg2zWkz2p2VT
	for ; Tue, 10 Jan 2023 09:49:35 +0000 (UTC)
	(envelope-from bT.7i6f7j5d30=ha8y5gqb0sxa=wzk96x5ewo@em790814.fubar.geek.nz)
Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68])
	(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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NrmHg1J7Nz4QLm
	for ; Tue, 10 Jan 2023 09:49:34 +0000 (UTC)
	(envelope-from bT.7i6f7j5d30=ha8y5gqb0sxa=wzk96x5ewo@em790814.fubar.geek.nz)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=smtpservice.net; s=mgy720.a1-4.dyn; x=1673345074; h=Feedback-ID:
	X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender:
	List-Unsubscribe; bh=c7/Phlvu5/ryozThrocG3lJottaq4Eo/733kyf2kEow=; b=rXj+shGg
	eLQhe8RnYOyVKqUiwvhwK9ffVSp7ItFVYCwPzNuRMHrAZhOz4Zb0crgN9KSAIlmaUKx57u4W/7Mfs
	631jBdEyT6Yl9fhvEDc7I4lS5V2rrB4O8m4sEvXhbH85PjwxvJQ8/JLu9gmgZB/tK9Fgg18uC+pIX
	kUKF/EYxta0KO6mJwyEkbLKKc/HcP1jod/EtVRfqqa+xvHZZWzhkhLO5g5TiEfVDKoMEJK+Tc3Nu5
	Zhm/Qo1O8ymmdyKM+lSfNOg6sBTR2cBZtjt/B2AlFcUDxhkLNhmF7OkWE66otzyT5H1jGZVo5OwIz
	2ZIH1KtpOA5b/F+nd6qSuhhppQ==;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz;
 i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1673344174; h=from : subject
 : to : message-id : date;
 bh=c7/Phlvu5/ryozThrocG3lJottaq4Eo/733kyf2kEow=;
 b=ZY4q8tOsn2mvF1/2XX5QYQE4Cs+X7cSHfMcx5Ggnop/jwQZfLJ1eQWAU+KWx9TO9XoXlc
 uJcom9PCUDD835ioxxYB7ZZhCrTJeejHi9hP53qFU7qfv3UdPy03DVbc0E7Pz3yyzf/jwzA
 WmOtb5Ize2qFUHS+G5DdFTIaDiD4l3kCB6w4NKT2IPE7qLkBWgsKk9M8xgTJi1SUvL8CuZu
 kWbuzMzLy3A4XFkVWHzIG+QsFp4kwVKzzHpkbM/lNHClzERa2BBKkyMb15GvalBzKzEW4+5
 DC11PyDzLBT/Zh8X7YljPdfhywYKMM/jHwLCe7dRHNwopFq0iabNUhyWoarA==
Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.94.2-S2G) (envelope-from )
 id 1pFBG7-qt4Klj-Hx; Tue, 10 Jan 2023 09:49:31 +0000
Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz)
 by smtpcorp.com with esmtpsa
 (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96-S2G) (envelope-from )
 id 1pFBG7-9EFa7W-15; Tue, 10 Jan 2023 09:49:31 +0000
Received: from smtpclient.apple
 (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235])
 by morbo.fubar.geek.nz (Postfix) with ESMTPSA id B54D62B60E;
 Tue, 10 Jan 2023 09:49:27 +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 \(3696.120.41.1.1\))
Subject: Re: [EXTERNAL] MSI  CPU affinity for ARM64
From: Andrew Turner 
In-Reply-To: 
Date: Tue, 10 Jan 2023 09:49:27 +0000
Cc: "freebsd-arm@FreeBSD.org" ,
 Li-Wen Hsu , Wei Hu 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1125C96F-0621-4B62-9E94-742E28F6FA7A@fubar.geek.nz>
References: 
 
 
To: Souradeep Chakrabarti 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Smtpcorp-Track: 1pFUG79EFa7W15.v-SqsSW1ojMGr
Feedback-ID: 790814m:790814amQcrys:790814sMXO6gYsSB
X-Report-Abuse: Please forward a copy of this message, including all headers,
 to 
X-Rspamd-Queue-Id: 4NrmHg1J7Nz4QLm
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> On 9 Jan 2023, at 15:24, Souradeep Chakrabarti =
 wrote:
>=20
>=20
>=20
>=20
>> -----Original Message-----
>> From: Andrew Turner 
>> Sent: Monday, January 9, 2023 5:14 PM
>> To: Souradeep Chakrabarti 
>> Cc: freebsd-arm@FreeBSD.org; Li-Wen Hsu ; Wei Hu
>> 
>> Subject: [EXTERNAL] Re: MSI CPU affinity for ARM64
>>=20
>> Hello Souradeep,
>>=20
>> In what driver do you need to query the CPU affinity? In the GICv3 =
driver you can
>> read the set of CPUs from isrc->isrc_cpu. In other drivers it appears =
to be more
>> difficult.
>>=20
>> Andrew
> [Souradeep]=20
> I am trying to get the CPU id from vmbus_pcib driver.
> I need to find for the MSI interrupt, what is the CPUid.

If the MSI is for a child of vmbus_pcib you might be able to get this by =
implementing the bus_bind_intr method, however I don=E2=80=99t think =
you=E2=80=99ll see the default CPU assignment.

Why do you need the CPU ID in the vmbus_pcib driver? It=E2=80=99s stored =
in struct intr_event which could be found by adding a bus_setup_intr =
method that extracts it from the cookie passed back to the driver. This =
does require the driver to know the type for the cookie. On arm64 it =
should be a struct intr_handler that contains a pointer to a struct =
intr_event that has either the CPU the interrupt is assigned to or =
NOCPU. Having said that I=E2=80=99m not sure how safe it is to assume =
the cookie is a pointer to the intr_handler.

Andrew=

From nobody Tue Jan 10 11:05: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 4Nrnz405btz2pByM
	for ; Tue, 10 Jan 2023 11:05:20 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 4Nrnz35NWsz3JJv
	for ; Tue, 10 Jan 2023 11:05:19 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x634.google.com with SMTP id gh17so27629870ejb.6
        for ; Tue, 10 Jan 2023 03:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:from:to:cc:subject:date:message-id
         :reply-to;
        bh=5LLnVkipFzKL9Z79mPQVntduYDpCqE0KWUhHcgiau2A=;
        b=K7Cuwp8iSEpSsG20KQthRD8F/iq0NZakQTCGSIbtJJjU6Mxpw39cPwZSMYzspaRhZF
         olptDFK8X0WiAdEri2MWTRrWpQqLPsAVQSFk1AzuOT9whg8xPCG2w1FcTnyGjGoQgqmk
         c672+hj7UvGXf+qrnlgMeMo9GmmeOgKg1WrevnQrxUKCDPNaWy8x/ISB1wzZ2xHKYuqx
         CxXUv5Ifr6ghTYLWcKwPdYeuttdTJ5Tf7k9l6+0J455NUQExiK/5aI/UOrqnzrDJLAnq
         zshuwo7005I9ez16IX57iMjNVU3oi5EVIQMfrzuqNii2LMLUNgwR8VwF1dJEghuhbyVB
         j5DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=message-id:in-reply-to:to:references:date:subject:mime-version
         :content-transfer-encoding:from:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5LLnVkipFzKL9Z79mPQVntduYDpCqE0KWUhHcgiau2A=;
        b=FcVSb0YQIv2MkgbvndhtvXhCHoCos0QN3F6InPq05/UAlwp5va6skeJzJGCs6Pb4XC
         lLCKLZ2h/qGdNJVK8NXkXxmyUx5f0icdTOPSFEPEstevVyPMnG1Akxz3TRa5wFKq/UWU
         O+mdLPoxCiD4SJNMR3sn/6BN4OUCBTDzBuJqMRr/rbLyl1haXmoIlME/iOlQVxAgb3Jc
         XEYhCPpB9Gyj6LO9LptSoEp2v6KwOGa7b08uSXeGhLRFmN1hoSW3k6SIoH8IqF9eg6f2
         r9i5FsuYdIR5nrP2jlPcbQmEp3fSsm52aVKHi2orXkyair44c9rRSeAKS3wXZrFop5KT
         8MQw==
X-Gm-Message-State: AFqh2krxvdQbAvZS8xRw6kND2jFpl0UiM7DEG0KXQx8C/IJNMDUqKwgB
	JSjEn4tYh8RsO/bOB31TJmDRp/ocZ0g=
X-Google-Smtp-Source: AMrXdXulWc5YaCuPXJ0pw9SFEQLNLnXdVhnNffwvb8lLKFl7rr7nlpfC49vvKrXwORZoyGVH2xbXnA==
X-Received: by 2002:a17:906:fad5:b0:847:410:ecf0 with SMTP id lu21-20020a170906fad500b008470410ecf0mr58865837ejb.20.1673348718381;
        Tue, 10 Jan 2023 03:05:18 -0800 (PST)
Received: from smtpclient.apple (dynamic-046-114-061-069.46.114.pool.telefonica.de. [46.114.61.69])
        by smtp.googlemail.com with ESMTPSA id k23-20020a17090632d700b00837ac146a53sm4794327ejk.23.2023.01.10.03.05.17
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 10 Jan 2023 03:05:17 -0800 (PST)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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.300.101.1.3\))
Subject: Re: FreeBSD and CM4: use pftf/RPi4 (the EDK2 implementation)?
Date: Tue, 10 Jan 2023 12:05:05 +0100
References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com>
 <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com>
 
 <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com>
 
 
 <217ACD33-A466-4A01-AD36-5D4A0C1B3CF0@yahoo.com>
 <3BE72ED7-8787-45E8-8341-FE9CF4CFB84F@googlemail.com>
 
 <1EE321BB-6738-4931-BA75-4675C0D297E2@googlemail.com>
 <56924C76-58FE-4164-8832-441665E3C11E@yahoo.com>
To: Mark Millard ,
 freebsd-arm@freebsd.org,
 Robert Crowston 
In-Reply-To: <56924C76-58FE-4164-8832-441665E3C11E@yahoo.com>
Message-Id: 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4Nrnz35NWsz3JJv
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Hi Mark,

for the CM4 FreeBSD edkII would be the same as with the =
firmware-upstream:
you fix one thing and import the next dysfunctionality :-)
Currently in fbsd the CM4 is working like the 4b,=20
except that the pcie-driver(which wouldn`t have edkII ACPI-logic inside)=20=

fails.=20
The story is longer and in the end of it I can say:
It would need a dedicated Developer with very deep knowledge=20
of very complex things.. and I sometimes saw others temporarily failing =
on other platforms
 who have that knowledge..
The way to go, as far as I can estimate, is to fix the memory =
computation in the pcie -driver,
to say it in simple words while that task is not simple ;-)=E2=80=A6.

Regards

K.
=20
> Am 10.01.2023 um 03:15 schrieb Mark Millard :
>=20
> You may have an alternative for the CM4, not that I know the
> details of the status.
>=20
> The firmware from https://github.com/pftf/RPi4/releases/tag/v1.34
>=20
> includes bcm2711-rpi-cm4.dtb --and they only bother to include
> .dtb files for what they support in EDK2. (But there is still
> the questions of just what the support spans.)
>=20
> So, if it turned out that UEFI/ACPI from EDK2 would
> happen to be useful, it might avoid incomplete/inaccurate
> Device Tree handling for the CM4 in teh FreeBSD kernel,
> at least for some issues.
>=20
> But there is also the possibility of incomplete/inaccurate
> UEFI/ACPI handling in FreeBSD's kernel in ways that would
> be important to you. But it is separate code in the FreeBSD
> kernel generally so what works vs. not may well be different
> from Device Tree based booting.
>=20
> I'll note that the crash that I worked out how to avoid is
> Device Tree boot-style specific. Any crash for UEFI/ACPI
> would be separate, if any exists.
>=20
> But if you try UEFI/DeviceTree then the firmware vintage
> issue might be involved in that case.
>=20
> Just something to possibly explore for/with your CM4.
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20


From nobody Tue Jan 10 18:19: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 4Nrzc43hV2z2sMbF
	for ; Tue, 10 Jan 2023 18:19:32 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129])
	(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 4Nrzc40Nnbz49Br
	for ; Tue, 10 Jan 2023 18:19:32 +0000 (UTC)
	(envelope-from jjrushford@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-il1-x129.google.com with SMTP id a3so873513ilp.6
        for ; Tue, 10 Jan 2023 10:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=XKtyIJ0TKEc0Ptib76sBxMeSCsGqZxTrOEGHz5Fj+gA=;
        b=QOKTI/d3RNXZtf28VlgOR3KObmqpzKyMeqnYdYUoxIe+0bxlguYwxzn90Cj2pyQfhD
         cDIAxoAmbAoO+QHSaOqRjc8XhSaT5OJrxRTFa5zCw2ejTIedefKu64//F+oqbUSXCA6s
         +LmhcpYQMOAy0jZHwMBYRnEfRqY7+d1wTqf3kSxa49laxuLpxw6D1XUOu5OzRcW6vWWW
         qZ+NSXgKLsJV9z1WQxYBHuYmF/AgDw2vPm5iVJQUa6CJ+/+0+5l2opBKUozSOsE6fIl/
         w9xzc/APkG01nGVrC/MGBC5oTYwT6YcPE5+tMj9RC3cAkLZAuXkDdDoQxvUnUOdWai+0
         URFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=XKtyIJ0TKEc0Ptib76sBxMeSCsGqZxTrOEGHz5Fj+gA=;
        b=ow2DBlZYGKzsOW5nK/fCcY+QCaxEMCYys/irn9EwI0ROjpAIhyuO8EEA+H2QD9IPJZ
         QwYNs17OxsZmMW7FVtLMj+Ecj+MvTTzBWUpWjuX/7yJy3kynZYoeKP+WD9zhPvyfYys6
         3RE0dP6+u5cjP2/gRpfHfPm3H3m628jer1UPQAsL26HSzuZBBth19LVqlLTCVQ9CFthS
         Xx0s5/RHJKsffn1UBjNCPaJZfVK81b1NPmDVlUdTI3pzQZNZNcJ4hfLvW3c+43mI3p1+
         C/sha17TxcdMhbBdL+gJ0V9RM/UvCHtKWEDF7nVcLZIoYnZYYH6aORYl3r7pwH+qlVDu
         bJnA==
X-Gm-Message-State: AFqh2kqSihG/C3wJDy57F6hAB450d966D0dNRQQHbfrMioFpYGv951wz
	7Xw8uupngAkgBJHTWBNkvFXtLUScNOg=
X-Google-Smtp-Source: AMrXdXu1Xn4Cm3pK/Zc8wD+jOY7I1dpq1Xfp/6sHjE7FPrJR/6aspRBbi3DY0o/Gqdwr88TmoXR1+A==
X-Received: by 2002:a92:d1c1:0:b0:30d:899f:aed4 with SMTP id u1-20020a92d1c1000000b0030d899faed4mr12919858ilg.21.1673374771034;
        Tue, 10 Jan 2023 10:19:31 -0800 (PST)
Received: from smtpclient.apple ([2601:280:587f:87d0:fd8d:7a9e:180e:7182])
        by smtp.gmail.com with ESMTPSA id h1-20020a92d081000000b00302a9c9b4bfsm3722918ilh.44.2023.01.10.10.19.30
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 10 Jan 2023 10:19:30 -0800 (PST)
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.200.110.1.12\))
Subject: Re: Pi 4 serial ports
From: John Rushford 
In-Reply-To: <20230110083520.4b284ec89da2c7cd8a1c8fa7@bidouilliste.com>
Date: Tue, 10 Jan 2023 11:19:19 -0700
Cc: "freebsd-arm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20230110083520.4b284ec89da2c7cd8a1c8fa7@bidouilliste.com>
To: Emmanuel Vadot 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4Nrzc40Nnbz49Br
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Emmanuel,

Thank you very much!  I=E2=80=99m new to FreeBSD on pi and I guess I was =
making this way to difficult.
I built the rpi-firmware port and copied/enabled the uart dtb=E2=80=99s =
for the uart I wish to use. =20
I rebooted and I now see the port in the kernel messages and the ttyu in =
the dev tree. =20
Next I=E2=80=99ll break out my soldering iron and wire up the GPS =
breakout and get it working hopefully.

Cheers
John

> On Jan 10, 2023, at 12:35 AM, Emmanuel Vadot  =
wrote:
>=20
>=20
> Hi John,
>=20
> On Mon, 9 Jan 2023 13:43:37 -0700
> John Rushford  wrote:
>=20
>> Greetings,
>>=20
>> I?m running FreeBSD 13.1-RELEASE on a raspberry pi 4b rev 1.4.  The =
pi 4 has 4 UART ports available but as far as I can tell, FreeBSD 13.1 =
only supports 1 of them.
>> I would like to use one of the other UART ports to wire an adafruit =
GPS breakout too.  I tried using the UART0 port but when I wire the GPS =
breakout to it,=20
>> I run into boot issues with u-boot and console logging.  I know that =
in other OS?s such as raspian or ubuntu, you are able to enable the =
additional UARTS in config.txt.
>> Thinking that FreeBSD might support this I tried adding =
?dtoverlay=3Duartx? where x is 0 to 3 but I?m not seeing in any kernel =
logging that these ports were enabled and
>> I don?t see any additional ttyu?s in the dev tree.
>>=20
>> So my question, does FreeBSD support these additional UARTS and if =
so, how do I enable them so that I may use one for the GPS breakout?
>>=20
>> Thanks
>> John
>=20
> In the rpi-firmware package there is some uartXX.dtbo
> By looking at them those overlays are there for enabling the other
> uart port.
> Just put the ones you want to use on the FAT partition of your sdcard
> in the /overlays/ directory and add in config.txt "dtoverlay=3DuartXXX"
>=20
> Cheers,
>=20
> --=20
> Emmanuel Vadot